From likepeng@huawei.com Sun Dec 2 18:25:32 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F57521F895B for ; Sun, 2 Dec 2012 18:25:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NSJ+wVnNq66q for ; Sun, 2 Dec 2012 18:25:31 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id E9F1C21F8953 for ; Sun, 2 Dec 2012 18:25:30 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AMC60763; Mon, 03 Dec 2012 02:25:28 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 3 Dec 2012 02:25:03 +0000 Received: from SZXEML403-HUB.china.huawei.com (10.82.67.35) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 3 Dec 2012 10:25:26 +0800 Received: from SZXEML525-MBS.china.huawei.com ([169.254.8.152]) by szxeml403-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.003; Mon, 3 Dec 2012 10:25:21 +0800 From: Likepeng To: Carsten Bormann , "core@ietf.org WG" Thread-Topic: [core] Call for consensus: Should we switch out the option encoding? Thread-Index: AQHNzwRwa8xCxGNGoki5euexedi3jJgGQteg Date: Mon, 3 Dec 2012 02:25:19 +0000 Message-ID: <34966E97BE8AD64EAE9D3D6E4DEE36F21ED9A054@szxeml525-mbs.china.huawei.com> References: <55877B3AFB359744BA0F2140E36F52B514D26D1F@MBX10.d.ethz.ch> <5DC25716-A8E1-4FC7-B932-3079CFB703C4@tzi.org> <55877B3AFB359744BA0F2140E36F52B514D26E8B@MBX10.d.ethz.ch> <46A1DF3F04371240B504290A071B4DB63C877351@szxeml509-mbx> <9160F42C-566E-445C-BF13-F57B6F67C740@tzi.org> <50DEDC36-8397-413C-B6FD-7B2BE5D1207B@tzi.org> <3DDE1B3C-CBF4-4773-A3C2-AA61856B270C@sensinode.com> <9FCF6E24-CE7C-4E26-887A-0918369C992D@tzi.org> <6AF38EAF-DB60-4D6F-AE99-5226034917DB@intec.ugent.be> <51803EE3-A997-4DA4-A918-83B0B5B82996@tzi.org> In-Reply-To: <51803EE3-A997-4DA4-A918-83B0B5B82996@tzi.org> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.110.103] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [core] Call for consensus: Should we switch out the option encoding? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 03 Dec 2012 02:25:32 -0000 PkRvIHdlIGFzIGEgV0cgaGF2ZSBjb25zZW5zdXMgdG8gbWFrZSB0aGlzIGNoYW5nZSBhdCB0aGlz IHRpbWU/DQoNCkkgc3VwcG9ydCB0aGlzIGNoYW5nZS4NCg0KPldoZXRoZXIgeW91IGFuc3dlciB5 ZXMgb3Igbm8sIGl0IHdvdWxkIGJlIHVzZWZ1bCB0byBhZGQgYSBsaW5lIG9yIHNvIG9mIHRleHQg aW5kaWNhdGluZyB3aGF0IG1vdGl2YXRlcyB5b3VyIGRlY2lzaW9uLg0KDQpJdCBpcyBzaW1wbGVy IHRoYW4gdGhlIHByZXZpb3VzIGRlc2lnbi4NCg0KVGhhbmtzLA0KS2luZCBSZWdhcmRzDQpLZXBl bmcgDQoNCi0tLS0t6YKu5Lu25Y6f5Lu2LS0tLS0NCuWPkeS7tuS6ujogY29yZS1ib3VuY2VzQGll dGYub3JnIFttYWlsdG86Y29yZS1ib3VuY2VzQGlldGYub3JnXSDku6PooaggQ2Fyc3RlbiBCb3Jt YW5uDQrlj5HpgIHml7bpl7Q6IDIwMTLlubQxMeaciDMw5pelIDIyOjEwDQrmlLbku7bkuro6IGNv cmVAaWV0Zi5vcmcgV0cNCuS4u+mimDogW2NvcmVdIENhbGwgZm9yIGNvbnNlbnN1czogU2hvdWxk IHdlIHN3aXRjaCBvdXQgdGhlIG9wdGlvbiBlbmNvZGluZz8NCg0KT24gTm92IDMwLCAyMDEyLCBh dCAxNDo0OCwgS2xhdXMgSGFydGtlIDxoYXJ0a2VAdHppLm9yZz4gd3JvdGU6DQoNCj4gPG5ldy1m b3JtYXQtMDQudHh0Pg0KDQpUaGFua3MsIEtsYXVzLiAgDQpUaGlzIHZlcnNpb24gZG9lc24ndCBj b250YWluIGFsbCB0aGUgZWRpdG9yaWFsIGZpeGVzIHRoYXQgd2VyZSBkaXNjdXNzZWQgb24gdGhl IGxpc3QsIGJ1dCB0aGVzZSBjYW4gYmUgZG9uZSBpbiBwYXJhbGxlbCB0byBtYWtpbmcgdGhlIGRl Y2lzaW9uLg0KDQpOb3JtYWxseSwgd2UgZG8gbWlub3IgdGVjaG5pY2FsIGRlY2lzaW9ucyBieSBo YXZpbmcgYSBkaXNjdXNzaW9uIGFuZCB0aGVuIHNpbXBseSBwdXR0aW5nIGluIHRoZSBuZXcgdGV4 dCBpbnRvIHRoZSBuZXh0IHJldmlzaW9uIG9mIGEgV0cgZHJhZnQuDQpIb3dldmVyLCB0aGlzIGlz IGFub3RoZXIgYnJlYWtpbmcgY2hhbmdlLCBhbmQgYWx0aG91Z2ggdGhlIElFVEYgcHJvY2VzcyBk b2VzIGFsbG93IHVzIHRvIG1ha2UgYnJlYWtpbmcgY2hhbmdlcyBhcyBtdWNoIGFzIHdlIHdhbnQs IHJlYWxpdHkgZG9lc24ndCAtLSB3ZSBzaG91bGQgb25seSBtYWtlIHRoZW0gaWYgdGhlIGJlbmVm aXRzIHJlYWxseSBqdXN0aWZ5IHRoZSBjb3N0IG9mIGNoYW5naW5nIG91dCBhbGwgdG9vbHMgKGlu Y2x1ZGluZyB0aGUgV2lyZVNoYXJrIHRoYXQgeW91IHByb2JhYmx5IGFscmVhZHkgaGF2ZSBpbnN0 YWxsZWQgZXZlbiBpZiB5b3UgZG9uJ3Qga25vdyBpdCksIHRlbXBvcmFyaWx5IHBhcnRpdGlvbmlu ZyB0aGUgaW50ZXJvcCB0ZXN0aW5nIHdvcmxkIGludG8gdGhlIGxhZ2dhcmRzIGFuZCB0aGUgcmFk aWNhbHMsIG1ha2luZyBwcmV2aW91cyBwY2FwIGZpbGVzIGxlc3MgdXNlZnVsIGZvciBmdXR1cmUg dGVzdHMgZXRjLg0KDQpPdGhlciBtZXNzYWdlcyBoYXZlIGRpc2N1c3NlZCB0aGUgcXVhbnRpZmlh YmxlIGFuZCBub3Qgc28gcXVhbnRpZmlhYmxlIGFkdmFudGFnZXMgKGFuZCBkaXNhZHZhbnRhZ2Vz KSBvZiB0aGUgbmV3IHByb3Bvc2FsLg0KSSB0aGluayBJIGNhbiBhbHJlYWR5IHN0YXRlIGNvbnNl bnN1cyB0aGF0IHRoZSBuZXcgcHJvcG9zYWwgaXMgc2ltcGxlciwgd2hpY2ggZml0cyB0aGUgZ29h bHMgb2YgdGhlIFdHIHdlbGwuDQoNClNvIG15IHF1ZXN0aW9uIHRvIHRoZSBXRyBpcyBub3c6ICBE byB3ZSBhcyBhIFdHIGhhdmUgY29uc2Vuc3VzIHRvIG1ha2UgdGhpcyBjaGFuZ2UgYXQgdGhpcyB0 aW1lPw0KV2hldGhlciB5b3UgYW5zd2VyIHllcyBvciBubywgaXQgd291bGQgYmUgdXNlZnVsIHRv IGFkZCBhIGxpbmUgb3Igc28gb2YgdGV4dCBpbmRpY2F0aW5nIHdoYXQgbW90aXZhdGVzIHlvdXIg ZGVjaXNpb24uDQoNCkluIG9yZGVyIG5vdCB0byBsb3NlIHRpbWUsIHBsZWFzZSBzZW5kIGluIHlv dXIgcmVwbGllcyAod2l0aCB0aGlzIHN1YmplY3QpIHRvIHRoaXMgbWFpbGluZyBsaXN0IGJ5DQoN CgktPiAgMjAxMi0xMi0wNSwgMjM6NTkgVVRDLg0KDQpUaGlzIHdpbGwgZW5hYmxlIHVzIHRvIGFu bm91bmNlIGEgZGVjaXNpb24gKGFuZCwgSSBob3BlLCBnZXQgY29hcC0xMyBwdWJsaXNoZWQpIHJp Z2h0IG9uIFNpbnRlcmtsYWFzLg0KDQpHcsO8w59lLCBDYXJzdGVuDQoNCl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpjb3JlIG1haWxpbmcgbGlzdA0KY29y ZUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jb3JlDQo= From likepeng@huawei.com Sun Dec 2 18:40:37 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F27B21F8942 for ; Sun, 2 Dec 2012 18:40:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CDHIsKitEqHc for ; Sun, 2 Dec 2012 18:40:36 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id C518721F8932 for ; Sun, 2 Dec 2012 18:40:35 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ANK52544; Mon, 03 Dec 2012 02:40:34 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 3 Dec 2012 02:40:08 +0000 Received: from SZXEML404-HUB.china.huawei.com (10.82.67.59) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 3 Dec 2012 02:40:31 +0000 Received: from SZXEML525-MBS.china.huawei.com ([169.254.8.152]) by szxeml404-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.003; Mon, 3 Dec 2012 10:40:26 +0800 From: Likepeng To: Carsten Bormann , Klaus Hartke Thread-Topic: [core] CoAP jump mechanism Thread-Index: Ac3HLwlCd1JVVU2UQ3a8ARAWHlZt1v//n0CAgAAN4QD//WsngIAFSw8AgAA0FgCAAA8FgIAACwEAgAALIoCAABFBAIAACNYAgABEwoCAAQE2gIAB6p2AgABUb4CAAHHwgP/zMM0w Date: Mon, 3 Dec 2012 02:40:25 +0000 Message-ID: <34966E97BE8AD64EAE9D3D6E4DEE36F21ED9A077@szxeml525-mbs.china.huawei.com> References: <55877B3AFB359744BA0F2140E36F52B514D26D1F@MBX10.d.ethz.ch> <5DC25716-A8E1-4FC7-B932-3079CFB703C4@tzi.org> <55877B3AFB359744BA0F2140E36F52B514D26E8B@MBX10.d.ethz.ch> <46A1DF3F04371240B504290A071B4DB63C877351@szxeml509-mbx> <9160F42C-566E-445C-BF13-F57B6F67C740@tzi.org> <50DEDC36-8397-413C-B6FD-7B2BE5D1207B@tzi.org> <3DDE1B3C-CBF4-4773-A3C2-AA61856B270C@sensinode.com> <9FCF6E24-CE7C-4E26-887A-0918369C992D@tzi.org> In-Reply-To: <9FCF6E24-CE7C-4E26-887A-0918369C992D@tzi.org> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.110.103] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "core@ietf.org WG" Subject: Re: [core] CoAP jump mechanism X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 03 Dec 2012 02:40:37 -0000 PkluIHRyYW5zcG9ydHMgd2l0aG91dCBhIGxlbmd0aCBpbmRpY2F0aW9uLCB3ZSBjb3VsZCB1c2Ug MHhGMCBldGMuIGZvciBhIHBheWxvYWQgc2l6ZSBpbmRpY2F0aW9uIGxhdGVyLCB1c2luZyB0aGUg c2FtZSBlbmNvZGluZyBmb3IgdGhlIHNlY29uZCBuaWJibGUgYXMgZm9yIHRoZSBvcHRpb24gbGVu Z3RoLiAgMHhGIGFzIGEgbGVuZ3RoIG5pYmJsZSB0aGVuIGp1c3QgbWVhbnMgImluZGVmaW5pdGUg bGVuZ3RoIiwgaS5lLiB1bnRpbCB0aGUgZW5kIG9mIHRoZSBQRFUuDQoNCkkgdGhpbmsgaXQgaXMg YmV0dGVyIHRvIHVzZSBhbiBPcHRpb24gdG8gaW5kaWNhdGUgdGhlIHBheWxvYWQgbGVuZ3RoLCBp bnN0ZWFkIG9mIHVzaW5nIEtsYXVzIGVuY29kaW5nIG1ldGhvZCBmb3IgdGhpcy4gQlRXLCBJIGFt IGluIGZhdm9yIG9mIHVzaW5nIEtsYXVzIGVuY29kaW5nIGZvciB0aGUgb3B0aW9ucywgYXMgSSBp bmRpY2F0ZWQgaW4gYSBzZXBhcmF0ZSBlbWFpbC4gDQoNClJlYXNvbiBpcyB0aGF0LCBwYXlsb2Fk IGxlbmd0aCBpcyBhbiBvcHRpb25hbCBmZWF0dXJlLCBhbmQgaW4gbW9zdCBvZiB0aGUgY2FzZXMs IGl0IGlzIG5vdCBuZWNlc3NhcnkgdG8gYmUgaW5kaWNhdGVkLiBJZiB3ZSB1c2UgZW5jb2Rpbmcg bWV0aG9kLCBldmVyeSBpbXBsZW1lbnRhdGlvbiBuZWVkcyB0byBzdXBwb3J0IHRoaXMgZW5jb2Rp bmcgZm9yIHRoZSBwYXlsb2FkLCBub3Qgb25seSBmb3IgdGhlIG9wdGlvbnMuIElmIHdlIHVzZSBh biBPcHRpb24gZm9yIHRoaXMsIGl0IGlzIG9wdGlvbmFsLCBhbmQgaXQgY2FuIGJlIG9wdGlvbmFs bHkgaW1wbGVtZW50ZWQgd2hlcmUgbmVjZXNzYXJ5Lg0KDQpIZXJlIHdhcyBteSBwcm9wb3NhbCBm b3IgdGhlIHBheWxvYWQtbGVuZ3RoIG9wdGlvbjoNCmh0dHA6Ly90b29scy5pZXRmLm9yZy9pZC9k cmFmdC1saS1jb3JlLWNvYXAtcGF5bG9hZC1sZW5ndGgtb3B0aW9uLTAwLnR4dA0KDQpUaGFua3Ms DQpLaW5kIFJlZ2FyZHMNCktlcGVuZw0KLS0tLS3pgq7ku7bljp/ku7YtLS0tLQ0K5Y+R5Lu25Lq6 OiBjb3JlLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpjb3JlLWJvdW5jZXNAaWV0Zi5vcmddIOS7 o+ihqCBDYXJzdGVuIEJvcm1hbm4NCuWPkemAgeaXtumXtDogMjAxMuW5tDEx5pyIMjXml6UgMTQ6 NDkNCuaUtuS7tuS6ujogS2xhdXMgSGFydGtlDQrmioTpgIE6IGNvcmVAaWV0Zi5vcmcgV0cNCuS4 u+mimDogUmU6IFtjb3JlXSBDb0FQIGp1bXAgbWVjaGFuaXNtDQoNCk9uIE5vdiAyNSwgMjAxMiwg YXQgMDE6MDAsIEtsYXVzIEhhcnRrZSA8aGFydGtlQHR6aS5vcmc+IHdyb3RlOg0KDQo+ICogTW9y ZSBmYW5jeSBhcnR3b3JrLg0KDQpJIGxpa2VkIHRoZSBvbGQgdmVyc2lvbiAoMzIgYml0cyBpbiBh IHJvdykgYmV0dGVyLg0KKFRoZSBvbmUtYnl0ZS1wZXIgcm93IGZvcm1hdCBpcyBmaW5lIGZvciB0 aGUgb3B0aW9uLikNCg0KVGVybWlub2xvZ2ljYWxseSwgSSdkIHN0aWNrIHdpdGggYSBmaXhlZCA0 LWJ5dGUgaGVhZGVyLCB3aGljaCBpcyBmb2xsb3dlZCBieSB0aGUgVG9rZW4gdmFsdWUsIGlmIGFu eS4NCg0KKiogVGVjaG5pY2FsIGNvbW1lbnRzOg0KDQpXaGF0IGhhcHBlbmVkIHRvIDgtYnl0ZSBU b2tlbnM/DQpJcyB0aGF0IGFuIGludGVudGlvbmFsIGNoYW5nZT8NCg0KRG8gdXNlIDB4RkYgZm9y IHRoZSBwYXlsb2FkIG1hcmtlci4NCihJbiB0cmFuc3BvcnRzIHdpdGhvdXQgYSBsZW5ndGggaW5k aWNhdGlvbiwgd2UgY291bGQgdXNlIDB4RjAgZXRjLiBmb3IgYSBwYXlsb2FkIHNpemUgaW5kaWNh dGlvbiBsYXRlciwgdXNpbmcgdGhlIHNhbWUgZW5jb2RpbmcgZm9yIHRoZSBzZWNvbmQgbmliYmxl IGFzIGZvciB0aGUgb3B0aW9uIGxlbmd0aC4gIDB4RiBhcyBhIGxlbmd0aCBuaWJibGUgdGhlbiBq dXN0IG1lYW5zICJpbmRlZmluaXRlIGxlbmd0aCIsIGkuZS4gdW50aWwgdGhlIGVuZCBvZiB0aGUg UERVLikNCg0KIlJlc2VydmVkIGZvciBmdXR1cmUgdXNlIiBkb2VzIG5vdCBtZWFuIGFueXRoaW5n IHdpdGggcmVzcGVjdCB0byBwYWNrZXQgcHJvY2Vzc2luZyBydWxlcy4NCi0+IE1VU1QgYmUgc2Vu dCBhcyAwLiAgTVVTVCBiZSBwcm9jZXNzZWQgYXMgYW4gZW5jb2RpbmcgZXJyb3IgdW5sZXNzIHJl Y2VpdmVkIGFzIDAuICANCihBZ2FpbiB3aXRoIHMvMC8xNS8gbGF0ZXIpLg0KDQpHcsO8w59lLCBD YXJzdGVuDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQpjb3JlIG1haWxpbmcgbGlzdA0KY29yZUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9jb3JlDQo= From yusuke.doi@toshiba.co.jp Sun Dec 2 22:43:29 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 428D421F857E for ; Sun, 2 Dec 2012 22:43:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.089 X-Spam-Level: X-Spam-Status: No, score=-4.089 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xZGQL1deVupA for ; Sun, 2 Dec 2012 22:43:28 -0800 (PST) Received: from imx2.toshiba.co.jp (inet-tsb5.toshiba.co.jp [202.33.96.24]) by ietfa.amsl.com (Postfix) with ESMTP id 7E78521F84F8 for ; Sun, 2 Dec 2012 22:43:28 -0800 (PST) Received: from arc1.toshiba.co.jp ([133.199.194.235]) by imx2.toshiba.co.jp with ESMTP id qB36hROk024736 for ; Mon, 3 Dec 2012 15:43:27 +0900 (JST) Received: (from root@localhost) by arc1.toshiba.co.jp id qB36hQ53013705 for core@ietf.org; Mon, 3 Dec 2012 15:43:26 +0900 (JST) Received: from unknown [133.199.192.144] by arc1.toshiba.co.jp with ESMTP id RAA13696; Mon, 3 Dec 2012 15:43:26 +0900 Received: from mx.toshiba.co.jp (localhost [127.0.0.1]) by ovp2.toshiba.co.jp with ESMTP id qB36hQWV028089 for ; Mon, 3 Dec 2012 15:43:26 +0900 (JST) Received: from spiffy21.isl.rdc.toshiba.co.jp by toshiba.co.jp id qB36hPSk022555; Mon, 3 Dec 2012 15:43:26 +0900 (JST) Received: from [10.0.2.15] (ncg-dhcp91.isl.rdc.toshiba.co.jp [133.196.16.91]) by spiffy21.isl.rdc.toshiba.co.jp (Postfix) with ESMTP id C667097CDA; Mon, 3 Dec 2012 15:43:25 +0900 (JST) Message-ID: <50BC4A0E.8060205@toshiba.co.jp> Date: Mon, 03 Dec 2012 15:43:26 +0900 From: Yusuke DOI User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:12.0) Gecko/20120420 Thunderbird/12.0 MIME-Version: 1.0 To: Carine Bournez References: <20121129100041.GA14246@jay.w3.org> In-Reply-To: <20121129100041.GA14246@jay.w3.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: core@ietf.org Subject: Re: [core] W3C EXI WG review of IETF CoRE WG Internet Drafts X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 03 Dec 2012 06:43:29 -0000 Because I'm hearing none, let me continue a bit. If it requires some discussion on Content Encoding, let's move it to apps-discuss. (2012/11/29 19:00), Carine Bournez wrote: > We believe that the choice of a content-type parameter is a good one > (as long as it does get implemented effectively by endpoints). However, > the cleanest way would be still to use a content-encoding mechanism > rather than a separate content-type indicating that EXI is used. So > instead of: > > 'Accept: application/example-exi;sv=1.4' > > we suggest: > > 'Accept: application/example;sv=1.4' > 'Accept-encoding: exi' However, content-encoding EXI for schema-informed EXI is not accepted in IETF (so far). This is simple because just saying 'EXI' does not help to understand the contents. Schema-informed EXI requires schema information. In this case, the content type 'example-exi' could be just an 'example'. Anyway, the spec of the content type defines the encoding+schema. > For the schema versioning concern mentioned in section 2.1, we interpeted > the text (in the light of the core-parameter-option I-D ) as > "schemaId will be sent as a content-type parameter". > We want to highlight the fact that in practice the idea of using a > 'Major.Minor' version number might not be needed. For minor changes to the > schema, it may be interesting to use the deviation capabilities of the > EXI processors, rather than offering a new schema for the content-type > and deploy the change on a lot of endpoints. It would be easier to > advise users to change the schema (to be negotiated) only when really > necessary, i.e. format changes enable measurable performance improvements. It seems to me that the argument is orthogonal to the schema versioning issue and I believe it should be up to protocol/schema designer's decision. The use case in my mind is to ship new version of products with a new schema without breaking interoperability. Personally I don't think I would try to update the schema of previous lines of products. // Yusuke DOI From cabo@tzi.org Mon Dec 3 00:27:20 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 928CD21F85C8 for ; Mon, 3 Dec 2012 00:27:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OdWng1RWvMyO for ; Mon, 3 Dec 2012 00:27:19 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id C083921F858B for ; Mon, 3 Dec 2012 00:27:18 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id qB38R92p008961; Mon, 3 Dec 2012 09:27:09 +0100 (CET) Received: from [192.168.217.105] (p5489190C.dip.t-dialin.net [84.137.25.12]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 71ACDE45; Mon, 3 Dec 2012 09:27:09 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: <20121129100041.GA14246@jay.w3.org> Date: Mon, 3 Dec 2012 09:27:08 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <1560E310-E8D0-43F9-A4EE-30CC62723F35@tzi.org> References: <20121129100041.GA14246@jay.w3.org> To: Carine Bournez X-Mailer: Apple Mail (2.1499) Cc: core@ietf.org Subject: Re: [core] W3C EXI WG review of IETF CoRE WG Internet Drafts X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 03 Dec 2012 08:27:20 -0000 On Nov 29, 2012, at 11:00, Carine Bournez wrote: > We believe that the choice of a content-type parameter is a good one > (as long as it does get implemented effectively by endpoints). = However,=20 > the cleanest way would be still to use a content-encoding mechanism=20 > rather than a separate content-type indicating that EXI is used. So > instead of: >=20 > 'Accept: application/example-exi;sv=3D1.4' >=20 > we suggest: >=20 > 'Accept: application/example;sv=3D1.4' > 'Accept-encoding: exi' Carine, thank you for your input. One piece of background that seems to be important here: In CoAP, we do not separately deal in media-types and content-codings, = on the basis that few constrained nodes will have that level of = flexibility. Instead, we have a concept of content-format, which essentially is the = cross-product of the two, i.e., a number given to each desirable = combination: One content-format implies one media-type and one = content-coding, as well as a specific setting of all media-type = parameters. A CoAP Accept Option specifies an acceptable content-format, i.e. a = combination of media-type, parameters, and content-coding. The CoAP Content-Format Option specifies the media-type, parameters, and = the content-coding of the representation enclosed. (We confusingly continued calling that option "Content-Type" for a = while; this was recently fixed.) So while what you are saying would be possible on the HTTP side (as = Yusuke said, considering exi as a content-coding in the schema-informed = case is controversial), on the CoAP side it's all multiplied out and = therefore practically doesn't make a difference. My view of Yusuke's draft is that it is essentially exploring what part = of the picture cannot be factored into this single number because that = disables the recognition of structure needed e.g. for version number = arithmetic, and how to encode that information separately from the = Content-Format Option. Gr=FC=DFe, Carsten From floris.vandenabeele@intec.ugent.be Mon Dec 3 07:29:29 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 188E021F85B1 for ; Mon, 3 Dec 2012 07:29:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tOFRe-YtS4Hi for ; Mon, 3 Dec 2012 07:29:28 -0800 (PST) Received: from smtp3.ugent.be (smtp3.ugent.be [157.193.49.127]) by ietfa.amsl.com (Postfix) with ESMTP id 3624F21F845B for ; Mon, 3 Dec 2012 07:29:27 -0800 (PST) Received: from localhost (mcheck2.ugent.be [157.193.49.249]) by smtp3.ugent.be (Postfix) with ESMTP id C6B6BC299 for ; Mon, 3 Dec 2012 16:29:26 +0100 (CET) X-Virus-Scanned: by UGent DICT Received: from smtp3.ugent.be ([157.193.49.127]) by localhost (mcheck2.UGent.be [157.193.43.11]) (amavisd-new, port 10024) with ESMTP id tkOvGtt_g21M for ; Mon, 3 Dec 2012 16:29:26 +0100 (CET) Received: from mail2.intec.ugent.be (mail2.intec.ugent.be [157.193.214.245]) by smtp3.ugent.be (Postfix) with ESMTP id 49932C28E for ; Mon, 3 Dec 2012 16:29:26 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mail2.intec.ugent.be (Postfix) with ESMTP id 20FB01F for ; Mon, 3 Dec 2012 16:29:26 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at intec.ugent.be Received: from mail2.intec.ugent.be ([127.0.0.1]) by localhost (mail2.intec.ugent.be [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ULWgIfPJwGCC for ; Mon, 3 Dec 2012 16:29:26 +0100 (CET) Received: from [157.193.135.223] (dhcp-zdpt-223.intec.ugent.be [157.193.135.223]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: fvdabeele) by mail2.intec.ugent.be (Postfix) with ESMTPSA id 117631E for ; Mon, 3 Dec 2012 16:29:25 +0100 (CET) Message-ID: <50BCC555.1050607@intec.ugent.be> Date: Mon, 03 Dec 2012 16:29:25 +0100 From: Floris Van den Abeele User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: "core@ietf.org WG" References: <55877B3AFB359744BA0F2140E36F52B514D26D1F@MBX10.d.ethz.ch> <50DEDC36-8397-413C-B6FD-7B2BE5D1207B@tzi.org> <3DDE1B3C-CBF4-4773-A3C2-AA61856B270C@sensinode.com> <9FCF6E24-CE7C-4E26-887A-0918369C992D@tzi.org> <6AF38EAF-DB60-4D6F-AE99-5226034917DB@intec.ugent.be> <51803EE3-A997-4DA4-A918-83B0B5B82996@tzi.org> <34966E97BE8AD64EAE9D3D6E4DEE36F21ED9A054@szxeml525-mbs.china.huawei.com> In-Reply-To: <34966E97BE8AD64EAE9D3D6E4DEE36F21ED9A054@szxeml525-mbs.china.huawei.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Miltered: at jchkm1 with ID 50BCC556.003 by Joe's j-chkmail (http://helpdesk.ugent.be/email/)! X-j-chkmail-Enveloppe: 50BCC556.003 from mail2.intec.ugent.be/mail2.intec.ugent.be/157.193.214.245/mail2.intec.ugent.be/ X-j-chkmail-Score: MSGID : 50BCC556.003 on smtp3.ugent.be : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham Subject: Re: [core] Call for consensus: Should we switch out the option encoding? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 03 Dec 2012 15:29:29 -0000 +1, because it increases uniformity when encoding 'large' values. For those eager to update & test their implementations, I've setup a publicly reachable test server with v13 available @ coap://[2001:6a8:1d80:200::4]. It has been tested versus two other v13 implementations so far. Regards, Floris On 03-12-12 03:25, Likepeng wrote: >> Do we as a WG have consensus to make this change at this time? > I support this change. > >> Whether you answer yes or no, it would be useful to add a line or so of text indicating what motivates your decision. > It is simpler than the previous design. > > Thanks, > Kind Regards > Kepeng > > -----邮件原件----- > 发件人: core-bounces@ietf.org [mailto:core-bounces@ietf.org] 代表 Carsten Bormann > 发送时间: 2012年11月30日 22:10 > 收件人: core@ietf.org WG > 主题: [core] Call for consensus: Should we switch out the option encoding? > > On Nov 30, 2012, at 14:48, Klaus Hartke wrote: > >> > Thanks, Klaus. > This version doesn't contain all the editorial fixes that were discussed on the list, but these can be done in parallel to making the decision. > > Normally, we do minor technical decisions by having a discussion and then simply putting in the new text into the next revision of a WG draft. > However, this is another breaking change, and although the IETF process does allow us to make breaking changes as much as we want, reality doesn't -- we should only make them if the benefits really justify the cost of changing out all tools (including the WireShark that you probably already have installed even if you don't know it), temporarily partitioning the interop testing world into the laggards and the radicals, making previous pcap files less useful for future tests etc. > > Other messages have discussed the quantifiable and not so quantifiable advantages (and disadvantages) of the new proposal. > I think I can already state consensus that the new proposal is simpler, which fits the goals of the WG well. > > So my question to the WG is now: Do we as a WG have consensus to make this change at this time? > Whether you answer yes or no, it would be useful to add a line or so of text indicating what motivates your decision. > > In order not to lose time, please send in your replies (with this subject) to this mailing list by > > -> 2012-12-05, 23:59 UTC. > > This will enable us to announce a decision (and, I hope, get coap-13 published) right on Sinterklaas. > > Grüße, Carsten > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From mab@comnets.uni-bremen.de Mon Dec 3 07:49:59 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D830721F8625 for ; Mon, 3 Dec 2012 07:49:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Km3f2CuDPX6p for ; Mon, 3 Dec 2012 07:49:58 -0800 (PST) Received: from bugs.comnets.uni-bremen.de (bugs.comnets.uni-bremen.de [IPv6:2001:638:708:1155::1]) by ietfa.amsl.com (Postfix) with ESMTP id BEA3821F85C8 for ; Mon, 3 Dec 2012 07:49:57 -0800 (PST) Received: from shelbyville.comnets.uni-bremen.de (shelbyville [10.10.155.50]) by bugs.comnets.uni-bremen.de (Postfix) with ESMTPS id AE95CD404C4 for ; Mon, 3 Dec 2012 16:49:56 +0100 (CET) From: Markus Becker Organization: Comnets, University Bremen To: core@ietf.org Date: Mon, 3 Dec 2012 16:49:53 +0100 User-Agent: KMail/1.13.7 (Linux/3.5-trunk-686-pae; KDE/4.8.4; i686; ; ) References: <55877B3AFB359744BA0F2140E36F52B514D26D1F@MBX10.d.ethz.ch> <51803EE3-A997-4DA4-A918-83B0B5B82996@tzi.org> In-Reply-To: <51803EE3-A997-4DA4-A918-83B0B5B82996@tzi.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-Id: <201212031649.53723.mab@comnets.uni-bremen.de> Subject: Re: [core] Call for consensus: Should we switch out the option encoding? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 03 Dec 2012 15:49:59 -0000 I am in favor of the new encoding. Motivation: * Simpler and smaller code size. * I haven't uploaded coap-12 to TinyOS upstream. And since they are switchi= ng=20 to git, I have another excuse to wait with the upload for coap-13. Markus [..] > So my question to the WG is now: Do we as a WG have consensus to make th= is > change at this time? Whether you answer yes or no, it would be useful to > add a line or so of text indicating what motivates your decision. >=20 > In order not to lose time, please send in your replies (with this subject) > to this mailing list by >=20 > -> 2012-12-05, 23:59 UTC. >=20 > This will enable us to announce a decision (and, I hope, get coap-13 > published) right on Sinterklaas. >=20 > Gr=FC=DFe, Carsten >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core =2D----------------------------------------------- | Dipl.-Ing. Markus Becker | Communication Networks | TZI - Center for Computing Technologies | University Bremen | Germany =2D----------------------------------------------- | web: http://www.comnets.uni-bremen.de/~mab/ | mailto: mab@comnets.uni-bremen.de | telephone: +49 421 218 62379 | building: NW1 room: N2260 =2D----------------------------------------------- From jeroen.hoebeke@intec.ugent.be Mon Dec 3 08:22:51 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F46621F8879 for ; Mon, 3 Dec 2012 08:22:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pGND6H99lx4y for ; Mon, 3 Dec 2012 08:22:48 -0800 (PST) Received: from smtp2.ugent.be (smtp2.ugent.be [157.193.49.126]) by ietfa.amsl.com (Postfix) with ESMTP id 5007021F8877 for ; Mon, 3 Dec 2012 08:22:48 -0800 (PST) Received: from localhost (mcheck2.ugent.be [157.193.49.249]) by smtp2.ugent.be (Postfix) with ESMTP id 21B5712C247; Mon, 3 Dec 2012 17:22:47 +0100 (CET) X-Virus-Scanned: by UGent DICT Received: from smtp2.ugent.be ([157.193.49.126]) by localhost (mcheck2.UGent.be [157.193.43.11]) (amavisd-new, port 10024) with ESMTP id 0oo3iAM_YDIu; Mon, 3 Dec 2012 17:22:46 +0100 (CET) Received: from [192.168.123.5] (78-23-55-58.access.telenet.be [78.23.55.58]) (Authenticated sender: jjhoebek) by smtp2.ugent.be (Postfix) with ESMTPSA id 67AE012C379; Mon, 3 Dec 2012 17:22:46 +0100 (CET) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Jeroen Hoebeke In-Reply-To: <51803EE3-A997-4DA4-A918-83B0B5B82996@tzi.org> Date: Mon, 3 Dec 2012 17:22:46 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <924E3A0B-4133-4590-842D-4FA3513C669C@intec.ugent.be> References: <55877B3AFB359744BA0F2140E36F52B514D26D1F@MBX10.d.ethz.ch> <5DC25716-A8E1-4FC7-B932-3079CFB703C4@tzi.org> <55877B3AFB359744BA0F2140E36F52B514D26E8B@MBX10.d.ethz.ch> <46A1DF3F04371240B504290A071B4DB63C877351@szxeml509-mbx> <9160F42C-566E-445C-BF13-F57B6F67C740@tzi.org> <50DEDC36-8397-413C-B6FD-7B2BE5D1207B@tzi.org> <3DDE1B3C-CBF4-4773-A3C2-AA61856B270C@sensinode.com> <9FCF6E24-CE7C-4E26-887A-0918369C992D@tzi.org> <6AF38EAF-DB60-4D6F-AE99-5226034917DB@intec.ugent.be> <51803EE3-A997-4DA4-A918-83B0B5B82996@tzi.org> To: "core@ietf.org WG" X-Mailer: Apple Mail (2.1499) X-Miltered: at jchkm3 with ID 50BCD1D6.000 by Joe's j-chkmail (http://helpdesk.ugent.be/email/)! X-j-chkmail-Enveloppe: 50BCD1D6.000 from 78-23-55-58.access.telenet.be/78-23-55-58.access.telenet.be/78.23.55.58/[192.168.123.5]/ X-j-chkmail-Score: MSGID : 50BCD1D6.000 on smtp2.ugent.be : j-chkmail score : X : R=. U=. O=## B=0.000 -> S=0.166 X-j-chkmail-Status: Ham Subject: Re: [core] Call for consensus: Should we switch out the option encoding? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 03 Dec 2012 16:22:51 -0000 +1 for the new encoding. Motivation: - simplicity in design: uniform solution for option delta and option = length encoding makes the protocol cleaner and easier to understand - although a breaking change, the implementation is not hard at all (as = experienced last week during the plugtest) On 30 Nov 2012, at 15:09, Carsten Bormann wrote: > So my question to the WG is now: Do we as a WG have consensus to make = this change at this time? > Whether you answer yes or no, it would be useful to add a line or so = of text indicating what motivates your decision. >=20 > In order not to lose time, please send in your replies (with this = subject) to this mailing list by >=20 > -> 2012-12-05, 23:59 UTC. >=20 > This will enable us to announce a decision (and, I hope, get coap-13 = published) right on Sinterklaas. >=20 > Gr=FC=DFe, Carsten >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From Akbar.Rahman@InterDigital.com Mon Dec 3 08:43:05 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D246021F86A4 for ; Mon, 3 Dec 2012 08:43:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P-dwCCL486HN for ; Mon, 3 Dec 2012 08:43:05 -0800 (PST) Received: from smtp-out1.interdigital.com (smtp-out1.interdigital.com [64.208.228.135]) by ietfa.amsl.com (Postfix) with ESMTP id 1968F21F85C8 for ; Mon, 3 Dec 2012 08:43:05 -0800 (PST) Received: from SAM.InterDigital.com ([10.30.2.11]) by smtp-out1.interdigital.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 3 Dec 2012 11:43:03 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 3 Dec 2012 11:43:02 -0500 Message-ID: In-Reply-To: <51803EE3-A997-4DA4-A918-83B0B5B82996@tzi.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [core] Call for consensus: Should we switch out the option encoding? Thread-Index: Ac3PBG+9lxL/732BRj2l05L4t3xBjACb610w References: <55877B3AFB359744BA0F2140E36F52B514D26D1F@MBX10.d.ethz.ch><5DC25716-A8E1-4FC7-B932-3079CFB703C4@tzi.org><55877B3AFB359744BA0F2140E36F52B514D26E8B@MBX10.d.ethz.ch><46A1DF3F04371240B504290A071B4DB63C877351@szxeml509-mbx><9160F42C-566E-445C-BF13-F57B6F67C740@tzi.org><50DEDC36-8397-413C-B6FD-7B2BE5D1207B@tzi.org><3DDE1B3C-CBF4-4773-A3C2-AA61856B270C@sensinode.com><9FCF6E24-CE7C-4E26-887A-0918369C992D@tzi.org><6AF 38EAF-DB60-4 D6F-AE99-5226034917DB@intec.ugent.be> <51803EE3-A997-4DA4-A918-83B0B5B82996@tzi.org> From: "Rahman, Akbar" To: "Carsten Bormann" , X-OriginalArrivalTime: 03 Dec 2012 16:43:03.0747 (UTC) FILETIME=[43804130:01CDD175] Subject: Re: [core] Call for consensus: Should we switch out the option encoding? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 03 Dec 2012 16:43:06 -0000 +1 for support of the change to Klaus' new encoding proposal. =20 Motivation: >From a technical standpoint we are in favor even though it will result = in some rework of our current implementation. Klaus' proposal is = simpler than the current mechanism which seems unnecessarily complex and = prone to error. =20 /Akbar -----Original Message----- From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of = Carsten Bormann Sent: Friday, November 30, 2012 9:10 AM To: core@ietf.org WG Subject: [core] Call for consensus: Should we switch out the option = encoding? On Nov 30, 2012, at 14:48, Klaus Hartke wrote: > Thanks, Klaus. =20 This version doesn't contain all the editorial fixes that were discussed = on the list, but these can be done in parallel to making the decision. Normally, we do minor technical decisions by having a discussion and = then simply putting in the new text into the next revision of a WG = draft. However, this is another breaking change, and although the IETF process = does allow us to make breaking changes as much as we want, reality = doesn't -- we should only make them if the benefits really justify the = cost of changing out all tools (including the WireShark that you = probably already have installed even if you don't know it), temporarily = partitioning the interop testing world into the laggards and the = radicals, making previous pcap files less useful for future tests etc. Other messages have discussed the quantifiable and not so quantifiable = advantages (and disadvantages) of the new proposal. I think I can already state consensus that the new proposal is simpler, = which fits the goals of the WG well. So my question to the WG is now: Do we as a WG have consensus to make = this change at this time? Whether you answer yes or no, it would be useful to add a line or so of = text indicating what motivates your decision. In order not to lose time, please send in your replies (with this = subject) to this mailing list by -> 2012-12-05, 23:59 UTC. This will enable us to announce a decision (and, I hope, get coap-13 = published) right on Sinterklaas. Gr=FC=DFe, Carsten _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core From trac+core@trac.tools.ietf.org Mon Dec 3 08:45:30 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0133121F889D for ; Mon, 3 Dec 2012 08:45:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GeZ9GOQX8bDv for ; Mon, 3 Dec 2012 08:45:29 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 60BDD21F8879 for ; Mon, 3 Dec 2012 08:45:29 -0800 (PST) Received: from localhost ([127.0.0.1]:34776 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1TfZ8s-0005ba-9i; Mon, 03 Dec 2012 17:45:14 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "core issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-core-coap@tools.ietf.org, cabo@tzi.org X-Trac-Project: core Date: Mon, 03 Dec 2012 16:45:14 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/264 Message-ID: <051.67502ba5c047d87e31961ad044f22cef@trac.tools.ietf.org> X-Trac-Ticket-ID: 264 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-core-coap@tools.ietf.org, cabo@tzi.org, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: brian@skyfoundry.com, cabo@tzi.org, hartke@tzi.org, zach@sensinode.com Resent-Message-Id: <20121203164529.60BDD21F8879@ietfa.amsl.com> Resent-Date: Mon, 3 Dec 2012 08:45:29 -0800 (PST) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: [core] #264: Content-Format of error responses X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Reply-To: trac+core@trac.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 16:45:30 -0000 #264: Content-Format of error responses Klaus Hartke notes: Section 5.5.2 The Content-Format Option MUST NOT be included by the sender and MUST be treated like an unrecognized option by the recipient. For future extensibility (HATEOAS) and to reduce variability it might be better if the format of the representation of an error was determined by the Content-Format Option like the format of any other representation. Require the inclusion of a Content-Format Option with a value indicating a human-readable diagnostic message (i.e., text/plain or some new media type). Comment (Carsten Bormann): Originally, the assumption was that on error messages, some developer- readable (as opposed to human-readable) messages would suffice that were essentially assumed to be in Content-Format 0 (text/plain; charset=UTF-8). It is useful to retain this diagnostic capability, which was originally meant to solve the same problem the "reason phrase" solves on an HTTP status line. However, even error messages may want to guide the application state on the client. So, not being able to supply a representation that, e.g., provides alternate links to be used by the application, is a significant limitation from a full REST model. If we want to enable sending a content-format for this, defaulting to ct=0 just for error messages sounds wrong, but maybe could be justified. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core-coap@tools.ietf.org cabo@tzi.org | Status: new Type: other | Milestone: post-WGLC-1 technical | Version: coap-12 Priority: minor | Keywords: Component: coap | Severity: In WG Last | Call | -------------------------+------------------------------------------------- Ticket URL: core From cabo@tzi.org Mon Dec 3 08:51:46 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC90321F84F5 for ; Mon, 3 Dec 2012 08:51:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XU4M-HfB6mki for ; Mon, 3 Dec 2012 08:51:46 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 1E48121F8464 for ; Mon, 3 Dec 2012 08:51:45 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id qB3Gpcpn014676; Mon, 3 Dec 2012 17:51:38 +0100 (CET) Received: from [192.168.217.105] (p54893544.dip.t-dialin.net [84.137.53.68]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 57F32345; Mon, 3 Dec 2012 17:51:38 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: <50BCC555.1050607@intec.ugent.be> Date: Mon, 3 Dec 2012 17:51:37 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <55877B3AFB359744BA0F2140E36F52B514D26D1F@MBX10.d.ethz.ch> <50DEDC36-8397-413C-B6FD-7B2BE5D1207B@tzi.org> <3DDE1B3C-CBF4-4773-A3C2-AA61856B270C@sensinode.com> <9FCF6E24-CE7C-4E26-887A-0918369C992D@tzi.org> <6AF38EAF-DB60-4D6F-AE99-5226034917DB@intec.ugent.be> <51803EE3-A997-4DA4-A918-83B0B5B82996@tzi.org> <34966E97BE8AD64EAE9D3D6E4DEE36F21ED9A054@szxeml525-mbs.china.huawei.com> <50BCC555.105 0607@intec.ugent.be> To: Floris Van den Abeele X-Mailer: Apple Mail (2.1499) Cc: "core@ietf.org WG" Subject: Re: [core] Call for consensus: Should we switch out the option encoding? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 03 Dec 2012 16:51:47 -0000 On Dec 3, 2012, at 16:29, Floris Van den Abeele = wrote: > I've setup a publicly reachable test server with v13 available @ = coap://[2001:6a8:1d80:200::4]. It has been tested versus two other v13 = implementations so far. Good idea! Given today's spate of positive responses, http://coap.me (the client) = and coap://coap.me (the server) are now on "Klaus encoding", too. (And they, as we already tested at the plugtest, do interoperate with = your implementation: http://coap.me/crawl/coap://[2001:6a8:1d80:200::4] .) Gr=FC=DFe, Carsten From trac+core@trac.tools.ietf.org Mon Dec 3 09:25:25 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76C4921F8805 for ; Mon, 3 Dec 2012 09:25:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LZWeKiTaYaXf for ; Mon, 3 Dec 2012 09:25:24 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 95B4D21F87EB for ; Mon, 3 Dec 2012 09:25:24 -0800 (PST) Received: from localhost ([127.0.0.1]:37452 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1TfZlQ-0002kn-4i; Mon, 03 Dec 2012 18:25:04 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "core issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-core-coap@tools.ietf.org, cabo@tzi.org X-Trac-Project: core Date: Mon, 03 Dec 2012 17:25:03 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/265 Message-ID: <051.1861a7035d5cf50ce2b561301512103a@trac.tools.ietf.org> X-Trac-Ticket-ID: 265 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-core-coap@tools.ietf.org, cabo@tzi.org, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: brian@skyfoundry.com, cabo@tzi.org, hartke@tzi.org, zach@sensinode.com Resent-Message-Id: <20121203172524.95B4D21F87EB@ietfa.amsl.com> Resent-Date: Mon, 3 Dec 2012 09:25:24 -0800 (PST) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: [core] #265: ETag Option in responses other than 2.05 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Reply-To: trac+core@trac.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 17:25:25 -0000 #265: ETag Option in responses other than 2.05 Klaus Hartke notes: Section 5.10.7: The ETag Option in a response provides the current value of the entity-tag for the enclosed representation of the target resource. In other words, the ETag Option must not be included in responses other than 2.05 (Content), because no other response type transfers the representation of the target resource. However, Section 5.9.1.3 says on the 2.03 (Valid) response type: Related to HTTP 304 "Not Modified", but only used to indicate that the response identified by the entity-tag identified by the included ETag Option is valid. Accordingly, the response MUST include an ETag Option. So Section 5.10.7 should be updated to reflect that. Furthermore, the ETSI CoAP Plugtest 2 test specification (v009b) contains the following step: Server sends response containing: * Code = 68 (2.04 Changed) * Option type = ETag * Option value = an arbitrary ETag value which differs from the ETag sent in step 3 So the test specification is wrong according to Section 5.10.7, but it might be more useful to extend the draft with ETag Options in 2.04 (Changed) responses than fix the test specification. Comment (Carsten Bormann): In httpbis, this was recently addressed in ticket 330: http://trac.tools.ietf.org/wg/httpbis/trac/ticket/330 See also: http://trac.tools.ietf.org/wg/httpbis/trac/changeset/1571 This Changeset 1571 to httpbis part 3 introduced a new term from part 4: selected representation. Part 2 has: 8.2. Selected Representation Header Fields We use the term "selected representation" to refer to the the current representation of a target resource that would have been selected in a successful response if the same request had used the method GET and excluded any conditional request header fields. (If you are as confused by the restructuring of HTTP into "parts" as I am, you are in good company.) It also defines ETag as a header field (the HTTP name for what we call "Option") for metadata about the selected representation, which might differ from the representation included in the message for responses to some state-changing methods. I believe the CoRE WG should do the same, which makes clear what the ETag in 2.03 means. (We also could probably benefit from a more operable definition of what the selected representation is in our context.) The CoRE WG then could (or could not) go ahead and allow ETag in 2.04 and 2.01 (not quite so sure about 2.02 :-). We should discuss the use cases that would benefit from this. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core-coap@tools.ietf.org cabo@tzi.org | Status: new Type: other | Milestone: post-WGLC-1 technical | Version: coap-12 Priority: major | Keywords: Component: coap | Severity: In WG Last | Call | -------------------------+------------------------------------------------- Ticket URL: core From trac+core@trac.tools.ietf.org Mon Dec 3 11:10:03 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1947F21F8863 for ; Mon, 3 Dec 2012 11:10:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1QFa6kDQ3i6D for ; Mon, 3 Dec 2012 11:10:02 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 64A5E21F8876 for ; Mon, 3 Dec 2012 11:10:01 -0800 (PST) Received: from localhost ([127.0.0.1]:44771 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1TfbOl-0007AY-Hz; Mon, 03 Dec 2012 20:09:47 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "core issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: cabo@tzi.org, tho@koanlogic.com X-Trac-Project: core Date: Mon, 03 Dec 2012 19:09:47 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/259#comment:2 Message-ID: <066.e75e02f5cdb462472581ff0b5d2c7d64@trac.tools.ietf.org> References: <051.b150c522197456646133cd1bca831535@trac.tools.ietf.org> X-Trac-Ticket-ID: 259 In-Reply-To: <051.b150c522197456646133cd1bca831535@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: cabo@tzi.org, tho@koanlogic.com, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: Re: [core] #259: Standardize a workaround for HTTP library limitations in talking to forward HTTP-COAP cross-proxies? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Reply-To: trac+core@trac.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 19:10:03 -0000 #259: Standardize a workaround for HTTP library limitations in talking to forward HTTP-COAP cross-proxies? Changes (by cabo@tzi.org): * owner: draft-ietf-core-coap@tools.ietf.org => cabo@tzi.org * status: new => assigned Comment: It now seems pretty clear that we should go for a separate specification for a reverse-proxy convention for HTTP-CoAP mapping. So, to prepare for this, I propose to add the following text (from "However") to the end of the introduction to section 10. HTTP-CoAP Proxying: Enables HTTP clients to access resources on CoAP servers through an intermediary. This is initiated by specifying a "coap" or "coaps" URI in the Request-Line of an HTTP request to an HTTP-CoAP proxy. Either way, only the Request/ Response model of CoAP is mapped to HTTP. The underlying model of confirmable or non-confirmable messages, etc., is invisible and MUST have no effect on a proxy function. The following sections describe the handling of requests to a forward-proxy. Reverse proxies are not specified as the proxy function is transparent to the client with the proxy acting as if it was the origin server. However, similar considerations apply to reverse-proxies as to forward-proxies, and there generally will be an expectation that reverse-proxies operate in a similar way forward- proxies would. As an implementation note, HTTP client libraries may make it hard to operate an HTTP-CoAP forward proxy by not providing a way to put a CoAP URI on the HTTP Request-Line; reverse-proxying may therefore lead to wider applicability of a proxy. A separate specification may define a convention for URIs operating such a HTTP- CoAP reverse proxy. -- -----------------------------+--------------------------- Reporter: cabo@tzi.org | Owner: cabo@tzi.org Type: other technical | Status: assigned Priority: minor | Milestone: post-WGLC-1 Component: coap | Version: coap-09 Severity: In WG Last Call | Resolution: Keywords: | -----------------------------+--------------------------- Ticket URL: core From Akbar.Rahman@InterDigital.com Mon Dec 3 13:12:10 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8049D21F8928 for ; Mon, 3 Dec 2012 13:12:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.301, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_43=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id daXxdP4TQnCS for ; Mon, 3 Dec 2012 13:12:09 -0800 (PST) Received: from smtp-out1.interdigital.com (smtp-out1.interdigital.com [64.208.228.135]) by ietfa.amsl.com (Postfix) with ESMTP id 5690721F891F for ; Mon, 3 Dec 2012 13:12:09 -0800 (PST) Received: from SAM.InterDigital.com ([10.30.2.11]) by smtp-out1.interdigital.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 3 Dec 2012 16:12:08 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CDD19A.DA6D4993" Date: Mon, 3 Dec 2012 16:12:08 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [core] Should DNS usage of CoAP implementations favor SRV? Thread-Index: Ac3PC5oEL5Ve5dZfQ9Gcnw9P5kj1+gCjaOHA References: <5E28C76D-5E80-4EA0-9A9F-A8A930552099@tzi.org> From: "Rahman, Akbar" To: "Kerry Lynn" , "Carsten Bormann" , "core" X-OriginalArrivalTime: 03 Dec 2012 21:12:08.0219 (UTC) FILETIME=[DA5B2EB0:01CDD19A] Subject: Re: [core] Should DNS usage of CoAP implementations favor SRV? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 03 Dec 2012 21:12:10 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CDD19A.DA6D4993 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I agree that Kerry & company had several I-Ds that did do design work = into the relationship between CoAP and DNS. In fact, the Groupcomm I-D = currently references some of these ideas for any appraoch beyond raw = multicast IP manipulation: =20 http://tools.ietf.org/html/draft-ietf-core-groupcomm-03#page-5 =20 =20 So we need to decide as a WG if we want to support this approach or not. =20 =20 Regards, =20 =20 Akbar =20 From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of = Kerry Lynn Sent: Friday, November 30, 2012 10:01 AM To: Carsten Bormann; core Subject: Re: [core] Should DNS usage of CoAP implementations favor SRV? =20 On Fri, Nov 30, 2012 at 5:02 AM, Carsten Bormann wrote: CoAP is deliberately not tying itself to DNS in any major way. That is a good thing, as many CoAP deployments won't use DNS. But it also means we have never put any design work into the = relationship between CoAP and DNS. =20 Peter, Anders, and I put out several CoRE drafts detailing how DNS could = be used to advantage in networks of CoAP nodes. These have all expired but = for http://tools.ietf.org/html/draft-lynn-core-discovery-mapping-02.txt as = it became clear to us that there was not much support for these ideas within the = group. I am keeping the discovery-mapping I-D active because of its possible = applicability in mixed populations of SEP 2.0 devices where XML, HTTP, and DNS are the baseline and it's expected that CoAP may find applicability. In that = environment, we have extended DNS-SD/mDNS to discover REST function sets within a set of servers and the discovery-mapping I-D describes how to achieve = semantic equivalence in the search down to that level of granularity using either = DNS-SD/ mDNS or Core resource discovery. I hope to find a home for the SEP 2.0 DNS-SD/mDNS extensions discussion = in the MDNSEXT WG when it is chartered. One thing I'm no longer sure about after this week's plugtest is that, = for those areas of application where DNS *is* appropriate, we should = just blindly continue the way HTTP uses the DNS. That has pretty much been an accident, and there never has been a = chance to retrofit something more sensible the way that MX was retrofit = for mail. We may not have to invent anything new, though, because SRV has now = been around a dozen of years. Is it time to put it to good use? Cullen has suggested in the WGLC = comments that we do that. =20 Cullen proposed an excellent scheme (literally) in http://tools.ietf.org/html/draft-jennings-http-srv in which he suggested = http+srv could be used to advantage to bind a dynamic socket as well as an IP = address to an HTTP server location. Peter, Anders, and I developed this concept for CoAP in http://tools.ietf.org/html/draft-vanderstok-core-dna where, in = particular, it will be necessary to dynamically assign ports in the IPHC compressible range and = then discover this binding post-facto. Before this, Angelo & Co. described how coap+srv could be used in = HTTP-to- CoAP mapping across a proxy where, one on side, the "host" production = names a host record and on the other an SRV RR (which binds host & port). If yes, we should specify how SRV is used with CoAP. _coap._udp? This is the conventional way that DNS-SD/mDNS names SRV/TXT records. I believe we'd also want to deploy PTR and TXT records in addition to SRV = RRs to allow for wildcard and resource discovery, respectively. In = practice, searching for PTR RRs named _coap._udp is too general; you'd want to constrain the = search by using subtypes, e.g. light._sub._coap._udp. The discovery-mapping draft is a good starting point but it needs work. = I hope it can at least stimulate some discussion on this topic. Regards, -K- (Note that this doesn't need to be part of the base spec, as the base = spec is not tied to DNS.) We most likely shouldn't go NAPTR, unlike, say, RFC 3263 does for SIP. What is the right way to use DTLS with SRV? =20 (The related implementation issue that Klaus already brought up because = it occurs with AAAA as well: What is the best way to "try to connect" (RFC 2782) to choose one out = of multiple alternatives? "coap ping" was discovered as one way to aid this selection.) =09 Gr=FC=DFe, Carsten =09 _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core =20 ------_=_NextPart_001_01CDD19A.DA6D4993 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

I agree that Kerry & company had several I-Ds that did do design = work into the relationship between CoAP and DNS.=A0 In fact, the = Groupcomm I-D currently references some of these ideas for any appraoch = beyond raw multicast IP manipulation:

 

h= ttp://tools.ietf.org/html/draft-ietf-core-groupcomm-03#page-5

 

 

So we need to decide as a WG if we want to support this approach or = not.

 

 

Regards,

 

 

Akbar

 

From:= = core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of = Kerry Lynn
Sent: Friday, November 30, 2012 10:01 = AM
To: Carsten Bormann; core
Subject: Re: [core] = Should DNS usage of CoAP implementations favor = SRV?

 

On Fri, Nov = 30, 2012 at 5:02 AM, Carsten Bormann <cabo@tzi.org> = wrote:

CoAP is deliberately not tying itself to = DNS in any major way.
That is a good thing, as many CoAP deployments = won't use DNS.
But it also means we have never put any design work = into the relationship between CoAP and = DNS.

<kel> =

Peter, Anders, and I put out several CoRE = drafts detailing how DNS could be
used to advantage in networks of = CoAP nodes.  These have all expired but for
http://tools.ietf.org/html/draft-lynn-core-discovery-mapping-02.txt as it became
clear to us that there was not much support for these = ideas within the group.

I am keeping the discovery-mapping I-D = active because of its possible applicability
in mixed populations of = SEP 2.0 devices where XML, HTTP, and DNS are the
baseline and it's = expected that CoAP may find applicability.  In that = environment,
we have extended DNS-SD/mDNS to discover REST function = sets within a set
of servers and the discovery-mapping I-D describes = how to achieve semantic
equivalence in the search down to that level = of granularity using either DNS-SD/
mDNS or Core resource = discovery.

I hope to find a home for the SEP 2.0 DNS-SD/mDNS = extensions discussion in
the MDNSEXT WG when it is = chartered.
</kel>

One thing I'm no longer sure about after = this week's plugtest is that, for those areas of application where DNS = *is* appropriate, we should just blindly continue the way HTTP uses the = DNS.
That has pretty much been an accident, and there never has been = a chance to retrofit something more sensible the way that MX was = retrofit for mail.
We may not have to invent anything new, though, = because SRV has now been around a dozen of years.
Is it time to put = it to good use?  Cullen has suggested in the WGLC comments that we = do that.

Cullen proposed an = excellent scheme (literally) in
http://tools.= ietf.org/html/draft-jennings-http-srv in which he suggested = http+srv
could be used to advantage to bind a dynamic socket as well = as an IP address
to an HTTP server location.

Peter, Anders, = and I developed this concept for CoAP in
http://tool= s.ietf.org/html/draft-vanderstok-core-dna where, in particular, it = will be
necessary to dynamically assign ports in the IPHC = compressible range and then
discover this binding = post-facto.

Before this, Angelo & Co. described how coap+srv = could be used in HTTP-to-
CoAP mapping across a proxy where, one on = side, the "host" production names
a host record and on the = other an SRV RR (which binds host & = port).
</kel>

If yes, = we should specify how SRV is used with CoAP. =  _coap._udp?


<kel>
This is the = conventional way that DNS-SD/mDNS names SRV/TXT records.  = I
believe we'd also want to deploy PTR and TXT records in addition to = SRV RRs
to allow for wildcard and resource discovery, = respectively.  In practice, searching
for PTR RRs named = _coap._udp is too general; you'd want to constrain the search
by = using subtypes, e.g. light._sub._coap._udp.

The discovery-mapping = draft is a good starting point but it needs work.  I hope
it can = at least stimulate some discussion on this topic.

Regards, = -K-
</kel>

(Note = that this doesn't need to be part of the base spec, as the base spec is = not tied to DNS.)
We most likely shouldn't go NAPTR, unlike, say, RFC = 3263 does for SIP.
What is the right way to use DTLS with = SRV?
 

(The = related implementation issue that Klaus already brought up because it = occurs with AAAA as well:
What is the best way to "try to = connect" (RFC 2782) to choose one out of multiple = alternatives?
"coap ping" was discovered as one way to aid = this selection.)

Gr=FC=DFe, = Carsten

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

 

------_=_NextPart_001_01CDD19A.DA6D4993-- From tho@koanlogic.com Mon Dec 3 13:56:23 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E972821F858B for ; Mon, 3 Dec 2012 13:56:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GQ6LO5H1kJnf for ; Mon, 3 Dec 2012 13:56:23 -0800 (PST) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2920F21F8574 for ; Mon, 3 Dec 2012 13:56:22 -0800 (PST) Received: by mail-la0-f44.google.com with SMTP id d3so2754617lah.31 for ; Mon, 03 Dec 2012 13:56:21 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=4gzdkx98LSyUpCySr/8gdHkuz08R0////UG0oHsRQTc=; b=ViwGUg8RF0U+RbcWCAnERpBOdO5ui0R0MU7PanqPodNH5gr3CW3VMar/X4DPWg5dQ4 LchjKQ1mTpkh1xhdQmxrIV8pP87GfOjv+fnjYd3RU9ljFcWprXYJzEfOxIYT0gnPGHkJ jRSHO/72cRUn/DbuY5S7HCSmmtYKKo6jJtJLJ660FUYe9lDH25gafY/i2VO9JcQ9hxmq 9RfqkCXTO/VHYSgmHd2lGeYiaYNSZMtrBuPtaazPmwcJEoJgB5yWQMb7GCW55cRP5oZn n9Obgz/qcFG2dLg2f5gu5c4Ldy9tUSQ4D9ZOsG+YGdCUmx03ISzL63TPR0ApEs8wk1i1 Uy3Q== MIME-Version: 1.0 Received: by 10.112.11.34 with SMTP id n2mr4893153lbb.100.1354571781716; Mon, 03 Dec 2012 13:56:21 -0800 (PST) Received: by 10.114.2.195 with HTTP; Mon, 3 Dec 2012 13:56:21 -0800 (PST) X-Originating-IP: [86.0.176.63] In-Reply-To: References: <5E28C76D-5E80-4EA0-9A9F-A8A930552099@tzi.org> Date: Mon, 3 Dec 2012 22:56:21 +0100 Message-ID: From: Thomas Fossati To: "Rahman, Akbar" Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQlZieoKxZkkNfdjtaUVNXVuvWtyXauh3pDJnS8yydpvtuWTRh3XY3aMOag5W+mpvKSZxtAx Cc: core Subject: Re: [core] Should DNS usage of CoAP implementations favor SRV? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 03 Dec 2012 21:56:24 -0000 On Mon, Dec 3, 2012 at 10:12 PM, Rahman, Akbar wrote: > I agree that Kerry & company had several I-Ds that did do design work into > the relationship between CoAP and DNS. Especially the DNA I-D is of outstanding quality. I guess it'd be great to use it as the starting point for any further WG activity on the topic. From anqing_ietf@sina.com Tue Dec 4 03:07:01 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE14521F86F8 for ; Tue, 4 Dec 2012 03:07:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nDZUhu2PDn3f for ; Tue, 4 Dec 2012 03:07:01 -0800 (PST) Received: from mail2-189.sinamail.sina.com.cn (mail2-189.sinamail.sina.com.cn [60.28.2.189]) by ietfa.amsl.com (Postfix) with ESMTP id 7576621F85D5 for ; Tue, 4 Dec 2012 03:06:59 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap4JAKU/KE+sEMkW/3poAIFfnD6BNpM4jH8IhkqFDoELBIZOjg+KNg Received: from unknown (HELO webmail.sinamail.sina.com.cn) ([172.16.201.22]) by irtj11-91.sinamail.sina.com.cn with ESMTP; 04 Dec 2012 19:06:56 +0800 Received: by webmail.sinamail.sina.com.cn (Postfix, from userid 80) id 3AED840544; Tue, 4 Dec 2012 19:06:56 +0800 (CST) Date: Tue, 04 Dec 2012 19:06:56 +0800 Received: from anqing_ietf@sina.com([202.43.150.187]) by m0.mail.sina.com.cn via HTTP; Tue, 04 Dec 2012 19:06:56 +0800 (CST) From: To: "core" MIME-Version: 1.0 X-Priority: 3 X-MessageID: 1354619216.222.9610 X-Originating-IP: [172.16.201.22] X-Mailer: Sina WebMail 4.0 Content-Type: multipart/alternative; boundary="=-sinamail_alt_b8c753f226bf9b8895f43dd620ed6fe7" Message-Id: <20121204110656.3AED840544@webmail.sinamail.sina.com.cn> Subject: Re: [core] Call for consensus: Should we switch out the option encoding? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: anqing_ietf@sina.com List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Dec 2012 11:07:01 -0000 --=-sinamail_alt_b8c753f226bf9b8895f43dd620ed6fe7 Content-Type: text/plain; charset=GBK Content-Transfer-Encoding: base64 Content-Disposition: inline IEdvb2QgaWRlYSEgSSBzdHJvbmdseSBhZ3JlZSBvZiBjaGFuZ2luZyB0aGUgb3B0aW9uIGVuY29k aW5nIHRvIHRoZQ0Kb25lIHByb3Bvc2VkIGJ5IEtsYXVzLg== --=-sinamail_alt_b8c753f226bf9b8895f43dd620ed6fe7 Content-Type: text/html; charset=GBK Content-Transfer-Encoding: base64 Content-Disposition: inline PGRpdj4mbmJzcDtHb29kIGlkZWEhIEkgc3Ryb25nbHkgYWdyZWUgb2YgY2hhbmdpbmcgdGhlIG9w dGlvbiBlbmNvZGluZyB0byB0aGUNCm9uZSBwcm9wb3NlZCBieSBLbGF1cy48L2Rpdj4= --=-sinamail_alt_b8c753f226bf9b8895f43dd620ed6fe7-- From szymon.sasin@sensinode.com Tue Dec 4 03:12:02 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61C5B21F866F for ; Tue, 4 Dec 2012 03:12:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EeNjdlO8Qcr1 for ; Tue, 4 Dec 2012 03:12:01 -0800 (PST) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id 5D91E21F8629 for ; Tue, 4 Dec 2012 03:11:53 -0800 (PST) Received: from [192.168.0.231] (85-23-200-242.co.dnainternet.fi [85.23.200.242]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.8/8.13.4) with ESMTP id qB4BBmUg003891 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 4 Dec 2012 13:11:50 +0200 Message-ID: <50BDDA74.7090206@sensinode.com> Date: Tue, 04 Dec 2012 13:11:48 +0200 From: Szymon Sasin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121029 Thunderbird/16.0.2 MIME-Version: 1.0 To: core@ietf.org References: <55877B3AFB359744BA0F2140E36F52B514D26D1F@MBX10.d.ethz.ch> <9160F42C-566E-445C-BF13-F57B6F67C740@tzi.org> <50DEDC36-8397-413C-B6FD-7B2BE5D1207B@tzi.org> <3DDE1B3C-CBF4-4773-A3C2-AA61856B270C@sensinode.com> <9FCF6E24-CE7C-4E26-887A-0918369C992D@tzi.org> <6AF38EAF-DB60-4D6F-AE99-5226034917DB@intec.ugent.be> <51803EE3-A997-4DA4-A918-83B0B5B82996@tzi.org> In-Reply-To: <51803EE3-A997-4DA4-A918-83B0B5B82996@tzi.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [core] Call for consensus: Should we switch out the option encoding? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 04 Dec 2012 11:12:02 -0000 +1 It's simpler and less error prone. Szymon Sasin Sensinode On 30.11.2012 16:09, Carsten Bormann wrote: > On Nov 30, 2012, at 14:48, Klaus Hartke wrote: > >> > Thanks, Klaus. > This version doesn't contain all the editorial fixes that were discussed on the list, but these can be done in parallel to making the decision. > > Normally, we do minor technical decisions by having a discussion and then simply putting in the new text into the next revision of a WG draft. > However, this is another breaking change, and although the IETF process does allow us to make breaking changes as much as we want, reality doesn't -- we should only make them if the benefits really justify the cost of changing out all tools (including the WireShark that you probably already have installed even if you don't know it), temporarily partitioning the interop testing world into the laggards and the radicals, making previous pcap files less useful for future tests etc. > > Other messages have discussed the quantifiable and not so quantifiable advantages (and disadvantages) of the new proposal. > I think I can already state consensus that the new proposal is simpler, which fits the goals of the WG well. > > So my question to the WG is now: Do we as a WG have consensus to make this change at this time? > Whether you answer yes or no, it would be useful to add a line or so of text indicating what motivates your decision. > > In order not to lose time, please send in your replies (with this subject) to this mailing list by > > -> 2012-12-05, 23:59 UTC. > > This will enable us to announce a decision (and, I hope, get coap-13 published) right on Sinterklaas. > > Gre, Carsten > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From trac+core@trac.tools.ietf.org Tue Dec 4 03:48:50 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D66A921F875E for ; Tue, 4 Dec 2012 03:48:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AkqCeJAUwL-m for ; Tue, 4 Dec 2012 03:48:50 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 50A5121F8617 for ; Tue, 4 Dec 2012 03:48:49 -0800 (PST) Received: from localhost ([127.0.0.1]:56410 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1TfqzN-00062t-0k; Tue, 04 Dec 2012 12:48:37 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "core issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: cabo@tzi.org, zach@sensinode.com X-Trac-Project: core Date: Tue, 04 Dec 2012 11:48:37 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/215#comment:4 Message-ID: <066.da1046a569f660449d039807ef99a4d5@trac.tools.ietf.org> References: <051.45ee7476d5dde81710e3ef0e9dc7fb7f@trac.tools.ietf.org> X-Trac-Ticket-ID: 215 In-Reply-To: <051.45ee7476d5dde81710e3ef0e9dc7fb7f@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: cabo@tzi.org, zach@sensinode.com, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: Re: [core] #215: editorial issues around Congestion Control X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Reply-To: trac+core@trac.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Dec 2012 11:48:50 -0000 #215: editorial issues around Congestion Control Changes (by cabo@tzi.org): * status: new => closed * resolution: => fixed Comment: While we are still eagerly waiting for research that will underlie the definition of advanced congestion control schemes, section 4.7 of coap-12 is pretty solid as a basic congestion avoidance mechanism. It appears nothing more is needed in the base document. Therefore, I'm closing the ticket now. -- -----------------------------+--------------------------- Reporter: cabo@tzi.org | Owner: cabo@tzi.org Type: editorial | Status: closed Priority: major | Milestone: post-WGLC-1 Component: coap | Version: coap-09 Severity: In WG Last Call | Resolution: fixed Keywords: | -----------------------------+--------------------------- Ticket URL: core From zach@sensinode.com Tue Dec 4 07:08:48 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EADF521F8AA2 for ; Tue, 4 Dec 2012 07:08:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aVvD2dJWcXf2 for ; Tue, 4 Dec 2012 07:08:46 -0800 (PST) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id 0BE3321F8AF9 for ; Tue, 4 Dec 2012 07:08:45 -0800 (PST) Received: from [192.168.0.116] (85-23-200-242.co.dnainternet.fi [85.23.200.242]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.8/8.13.4) with ESMTP id qB4F8htu027089; Tue, 4 Dec 2012 17:08:43 +0200 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Zach Shelby In-Reply-To: <51803EE3-A997-4DA4-A918-83B0B5B82996@tzi.org> Date: Tue, 4 Dec 2012 17:09:01 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <48F934D1-EDCE-40B2-8F85-DF4EA87DD469@sensinode.com> References: <55877B3AFB359744BA0F2140E36F52B514D26D1F@MBX10.d.ethz.ch> <5DC25716-A8E1-4FC7-B932-3079CFB703C4@tzi.org> <55877B3AFB359744BA0F2140E36F52B514D26E8B@MBX10.d.ethz.ch> <46A1DF3F04371240B504290A071B4DB63C877351@szxeml509-mbx> <9160F42C-566E-445C-BF13-F57B6F67C740@tzi.org> <50DEDC36-8397-413C-B6FD-7B2BE5D1207B@tzi.org> <3DDE1B3C-CBF4-4773-A3C2-AA61856B270C@sensinode.com> <9FCF6E24-CE7C-4E26-887A-0918369C992D@tzi.org> <6AF38EAF-DB60-4D6F-AE99-5226034917DB@intec.ugent.be> <51803EE3-A997-4DA4-A918-83B0B5B82996@tzi.org> To: Carsten Bormann X-Mailer: Apple Mail (2.1084) Cc: "core@ietf.org WG" Subject: Re: [core] Call for consensus: Should we switch out the option encoding? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 04 Dec 2012 15:08:48 -0000 On Nov 30, 2012, at 4:09 PM, Carsten Bormann wrote: > So my question to the WG is now: Do we as a WG have consensus to make = this change at this time? > Whether you answer yes or no, it would be useful to add a line or so = of text indicating what motivates your decision. >=20 > In order not to lose time, please send in your replies (with this = subject) to this mailing list by >=20 > -> 2012-12-05, 23:59 UTC. >=20 > This will enable us to announce a decision (and, I hope, get coap-13 = published) right on Sinterklaas. I support this change as both a document author and an individual = participant. This simplifies both reading and implementing the = specification, optimizes the most constrained implementations, and = reduces the chances for interoperability problems in the future.=20 Zach --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://www.sensinode.com @SensinodeIoT Mobile: +358 40 7796297 Twitter: @zach_shelby LinkedIn: http://fi.linkedin.com/in/zachshelby 6LoWPAN Book: http://6lowpan.net From pete.st.pierre@oracle.com Tue Dec 4 08:17:23 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32C9021F86D2 for ; Tue, 4 Dec 2012 08:17:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gfLAnMAH3kqm for ; Tue, 4 Dec 2012 08:17:21 -0800 (PST) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id BF33721F86CC for ; Tue, 4 Dec 2012 08:17:21 -0800 (PST) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by aserp1040.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id qB4GHKe5008197 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 4 Dec 2012 16:17:21 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id qB4GHKOE013108 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 4 Dec 2012 16:17:20 GMT Received: from abhmt114.oracle.com (abhmt114.oracle.com [141.146.116.66]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id qB4GHJiw027571; Tue, 4 Dec 2012 10:17:19 -0600 Received: from [192.168.1.154] (/99.57.137.67) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 04 Dec 2012 08:17:19 -0800 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: "Pete St. Pierre" In-Reply-To: <48F934D1-EDCE-40B2-8F85-DF4EA87DD469@sensinode.com> Date: Tue, 4 Dec 2012 08:17:18 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <55877B3AFB359744BA0F2140E36F52B514D26D1F@MBX10.d.ethz.ch> <5DC25716-A8E1-4FC7-B932-3079CFB703C4@tzi.org> <55877B3AFB359744BA0F2140E36F52B514D26E8B@MBX10.d.ethz.ch> <46A1DF3F04371240B504290A071B4DB63C877351@szxeml509-mbx> <9160F42C-566E-445C-BF13-F57B6F67C740@tzi.org> <50DEDC36-8397-413C-B6FD-7B2BE5D1207B@tzi.org> <3DDE1B3C-CBF4-4773-A3C2-AA61856B270C@sensinode.com> <9FCF6E24-CE7C-4E26-887A-0918369C992D@tzi.org> <6AF38EAF-DB60-4D6F-AE99-5226034917DB@intec.ugent.be> <51803EE3-A997-4DA4-A918-83B0B5B82996@tzi.org> <48F934D1-EDCE-40B2-8F85-DF4EA87DD469@sensinode.com> To: "core@ietf.org WG" X-Mailer: Apple Mail (2.1278) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Subject: Re: [core] Call for consensus: Should we switch out the option encoding? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 04 Dec 2012 16:17:23 -0000 +1 As a very early implementer (-05 days), I very much prefer the mechanism = being proposed. ...Pete -- Pete St. Pierre Pete.St.Pierre@oracle.com On Dec 4, 2012, at 7:09 AM, Zach Shelby wrote: > On Nov 30, 2012, at 4:09 PM, Carsten Bormann wrote: >=20 >> So my question to the WG is now: Do we as a WG have consensus to = make this change at this time? >> Whether you answer yes or no, it would be useful to add a line or so = of text indicating what motivates your decision. >>=20 >> In order not to lose time, please send in your replies (with this = subject) to this mailing list by >>=20 >> -> 2012-12-05, 23:59 UTC. >>=20 >> This will enable us to announce a decision (and, I hope, get coap-13 = published) right on Sinterklaas. >=20 > I support this change as both a document author and an individual = participant. This simplifies both reading and implementing the = specification, optimizes the most constrained implementations, and = reduces the chances for interoperability problems in the future.=20 >=20 > Zach >=20 > --=20 > Zach Shelby, Chief Nerd, Sensinode Ltd. > http://www.sensinode.com @SensinodeIoT > Mobile: +358 40 7796297 > Twitter: @zach_shelby > LinkedIn: http://fi.linkedin.com/in/zachshelby > 6LoWPAN Book: http://6lowpan.net >=20 >=20 >=20 >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From kovatsch@inf.ethz.ch Tue Dec 4 11:21:45 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F22F21F851C for ; Tue, 4 Dec 2012 11:21:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3k4WkK6R9lpm for ; Tue, 4 Dec 2012 11:21:45 -0800 (PST) Received: from edge10.ethz.ch (edge10.ethz.ch [82.130.75.186]) by ietfa.amsl.com (Postfix) with ESMTP id 9F28C21F8530 for ; Tue, 4 Dec 2012 11:21:40 -0800 (PST) Received: from CAS20.d.ethz.ch (172.31.51.110) by edge10.ethz.ch (82.130.75.186) with Microsoft SMTP Server (TLS) id 14.2.298.4; Tue, 4 Dec 2012 20:21:32 +0100 Received: from MBX10.d.ethz.ch ([fe80::6d7b:f3da:a5b1:c9e9]) by CAS20.d.ethz.ch ([fe80::2cd8:4907:7776:c56d%10]) with mapi id 14.02.0298.004; Tue, 4 Dec 2012 20:21:34 +0100 From: "Kovatsch Matthias" To: "core@ietf.org" Thread-Topic: [core] Call for consensus: Should we switch out the option encoding? Thread-Index: AQHN0hA178Gm0E7azkqfVbfROXUmS5gJAjxQ Date: Tue, 4 Dec 2012 19:21:33 +0000 Message-ID: <55877B3AFB359744BA0F2140E36F52B514D3EF89@MBX10.d.ethz.ch> References: <55877B3AFB359744BA0F2140E36F52B514D26D1F@MBX10.d.ethz.ch> <9160F42C-566E-445C-BF13-F57B6F67C740@tzi.org> <50DEDC36-8397-413C-B6FD-7B2BE5D1207B@tzi.org> <3DDE1B3C-CBF4-4773-A3C2-AA61856B270C@sensinode.com> <9FCF6E24-CE7C-4E26-887A-0918369C992D@tzi.org> <6AF38EAF-DB60-4D6F-AE99-5226034917DB@intec.ugent.be> <51803EE3-A997-4DA4-A918-83B0B5B82996@tzi.org> <50BDDA74.7090206@sensinode.com> In-Reply-To: <50BDDA74.7090206@sensinode.com> Accept-Language: en-US, de-CH Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.132.130.253] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [core] Call for consensus: Should we switch out the option encoding? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 04 Dec 2012 19:21:45 -0000 +1 for Klaus-encoding. And some new data from updating Erbium, here for WinAVR 20100110 4.3.3: text data bss dec hex filename 7046 140 6 7192 1c18 er-coap-12.o text data bss dec hex filename 6700 140 6 6846 1abe er-coap-klaus.o Here the new encoding saves 346 bytes of ROM and round about 25 SLoC. And I like the beauty of a uniform scheme. Ciao Matthias From wasilak@gmail.com Tue Dec 4 12:10:54 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 766D421F8CAF for ; Tue, 4 Dec 2012 12:10:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yO6ByaZtIs1h for ; Tue, 4 Dec 2012 12:10:54 -0800 (PST) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id D63DD21F8CC2 for ; Tue, 4 Dec 2012 12:10:53 -0800 (PST) Received: by mail-ob0-f172.google.com with SMTP id za17so4652519obc.31 for ; Tue, 04 Dec 2012 12:10:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=NVlPNfrqIX+R8MHwoUZRHgn9RhMwJp65rui7KT+KM0s=; b=fFuRIzx8oE7EO03Ql7LQoHEzB8bTO0qgWY6+mhGjBk7ECXEvKX/fO1hRBRqdhrmXDW R+uVbT8sDJMUGdNEsgV7cjIogFFDKELe88lPpHIhLCoyN/B1J8ZCBG0bub09Qg9yAUW8 Y685Zaz6pETABAzLMJgpv2UzdheUw8xhlZfoBW6yCxKywo/M/1kjkFvhi3FuwO1KtFAK VJkgaGoF8lOxEL0BZBlPGFCAzSYpA+t05prGu6zEjWONJgo0AmPVNqP6vm0SbBmBnR5Y 2YJigFvvMqXaKxGMrA1lDpEtRffci5D0Qq+OI7f7L5FhFjrU9GSDcXlmusMis4pxQmwx 8hbg== MIME-Version: 1.0 Received: by 10.182.245.20 with SMTP id xk20mr8809328obc.89.1354651844708; Tue, 04 Dec 2012 12:10:44 -0800 (PST) Received: by 10.60.161.179 with HTTP; Tue, 4 Dec 2012 12:10:44 -0800 (PST) In-Reply-To: <55877B3AFB359744BA0F2140E36F52B514D3EF89@MBX10.d.ethz.ch> References: <55877B3AFB359744BA0F2140E36F52B514D26D1F@MBX10.d.ethz.ch> <9160F42C-566E-445C-BF13-F57B6F67C740@tzi.org> <50DEDC36-8397-413C-B6FD-7B2BE5D1207B@tzi.org> <3DDE1B3C-CBF4-4773-A3C2-AA61856B270C@sensinode.com> <9FCF6E24-CE7C-4E26-887A-0918369C992D@tzi.org> <6AF38EAF-DB60-4D6F-AE99-5226034917DB@intec.ugent.be> <51803EE3-A997-4DA4-A918-83B0B5B82996@tzi.org> <50BDDA74.7090206@sensinode.com> <55877B3AFB359744BA0F2140E36F52B514D3EF89@MBX10.d.ethz.ch> Date: Tue, 4 Dec 2012 21:10:44 +0100 Message-ID: From: Maciej Wasilak To: "core@ietf.org" Content-Type: multipart/alternative; boundary=14dae93b608eff88d504d00c75f4 Subject: Re: [core] Call for consensus: Should we switch out the option encoding? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 04 Dec 2012 20:10:54 -0000 --14dae93b608eff88d504d00c75f4 Content-Type: text/plain; charset=UTF-8 +1 (also early implementer) - both code and unit tests are much simpler with new version. Best Regards Maciej 2012/12/4 Kovatsch Matthias > +1 for Klaus-encoding. > > And some new data from updating Erbium, here for WinAVR 20100110 4.3.3: > > text data bss dec hex filename > 7046 140 6 7192 1c18 er-coap-12.o > > text data bss dec hex filename > 6700 140 6 6846 1abe er-coap-klaus.o > > Here the new encoding saves 346 bytes of ROM and round about 25 SLoC. > And I like the beauty of a uniform scheme. > > Ciao > Matthias > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > --14dae93b608eff88d504d00c75f4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable +1 (also early implementer) - both code and unit tests are much simpler wit= h new version.

Best Regards
Maciej
2012/12/4 Kovatsch Matthias = <kovatsch@inf.= ethz.ch>
+1 for Klaus-encoding.

And some new data from updating Erbium, here for WinAVR 20100110 4.3.3:

=C2=A0 =C2=A0text =C2=A0 =C2=A0data =C2=A0 =C2=A0 bss =C2=A0 =C2=A0 dec =C2= =A0 =C2=A0 hex filename
=C2=A0 =C2=A07046 =C2=A0 =C2=A0 140 =C2=A0 =C2=A0 =C2=A0 6 =C2=A0 =C2=A0719= 2 =C2=A0 =C2=A01c18 er-coap-12.o

=C2=A0 =C2=A0text =C2=A0 =C2=A0data =C2=A0 =C2=A0 bss =C2=A0 =C2=A0 dec =C2= =A0 =C2=A0 hex filename
=C2=A0 =C2=A06700 =C2=A0 =C2=A0 140 =C2=A0 =C2=A0 =C2=A0 6 =C2=A0 =C2=A0684= 6 =C2=A0 =C2=A01abe er-coap-klaus.o

Here the new encoding saves 346 bytes of ROM and round about 25 SLoC.
And I like the beauty of a uniform scheme.

Ciao
Matthias

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

--14dae93b608eff88d504d00c75f4-- From kovatsch@inf.ethz.ch Tue Dec 4 12:20:02 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68E3621F8BA3 for ; Tue, 4 Dec 2012 12:20:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c3zkWj2B73DD for ; Tue, 4 Dec 2012 12:20:02 -0800 (PST) Received: from edge10.ethz.ch (edge10.ethz.ch [82.130.75.186]) by ietfa.amsl.com (Postfix) with ESMTP id 746AF21F8BA0 for ; Tue, 4 Dec 2012 12:20:01 -0800 (PST) Received: from CAS10.d.ethz.ch (172.31.38.210) by edge10.ethz.ch (82.130.75.186) with Microsoft SMTP Server (TLS) id 14.2.298.4; Tue, 4 Dec 2012 21:19:56 +0100 Received: from MBX10.d.ethz.ch ([fe80::6d7b:f3da:a5b1:c9e9]) by CAS10.d.ethz.ch ([fe80::cce:fc66:7b56:a06a%10]) with mapi id 14.02.0298.004; Tue, 4 Dec 2012 21:19:58 +0100 From: "Kovatsch Matthias" To: "core@ietf.org" Thread-Topic: [core] Call for consensus: Should we switch out the option encoding? Thread-Index: AQHN0hA178Gm0E7azkqfVbfROXUmS5gJAjxQgAAS/0A= Date: Tue, 4 Dec 2012 20:19:57 +0000 Message-ID: <55877B3AFB359744BA0F2140E36F52B514D3F085@MBX10.d.ethz.ch> References: <55877B3AFB359744BA0F2140E36F52B514D26D1F@MBX10.d.ethz.ch> <9160F42C-566E-445C-BF13-F57B6F67C740@tzi.org> <50DEDC36-8397-413C-B6FD-7B2BE5D1207B@tzi.org> <3DDE1B3C-CBF4-4773-A3C2-AA61856B270C@sensinode.com> <9FCF6E24-CE7C-4E26-887A-0918369C992D@tzi.org> <6AF38EAF-DB60-4D6F-AE99-5226034917DB@intec.ugent.be> <51803EE3-A997-4DA4-A918-83B0B5B82996@tzi.org> <50BDDA74.7090206@sensinode.com> Accept-Language: en-US, de-CH Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.132.130.253] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [core] Call for consensus: Should we switch out the option encoding? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 04 Dec 2012 20:20:02 -0000 Okay, a small bug disallowing to encode longer lengths allowed for an incre= dible optimization. But after fixing this, it is still 262 saved bytes of ROM (just to have cor= rect numbers on the list): text data bss dec hex filename 6784 140 6 6930 1b12 er-coap-klaus.o Ciao Matthias > -----Original Message----- > From: Kovatsch Matthias > Sent: Dienstag, 4. Dezember 2012 20:22 > To: core@ietf.org > Subject: RE: [core] Call for consensus: Should we switch out the option > encoding? >=20 > +1 for Klaus-encoding. >=20 > And some new data from updating Erbium, here for WinAVR 20100110 4.3.3: >=20 > text data bss dec hex filename > 7046 140 6 7192 1c18 er-coap-12.o >=20 > text data bss dec hex filename > 6700 140 6 6846 1abe er-coap-klaus.o >=20 > Here the new encoding saves 346 bytes of ROM and round about 25 SLoC. > And I like the beauty of a uniform scheme. >=20 > Ciao > Matthias From cabo@tzi.org Tue Dec 4 22:54:41 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A69721F8BF8 for ; Tue, 4 Dec 2012 22:54:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QyPhnnBHGvma for ; Tue, 4 Dec 2012 22:54:40 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 374EA21F8BCF for ; Tue, 4 Dec 2012 22:54:39 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id qB56sVgR020625 for ; Wed, 5 Dec 2012 07:54:31 +0100 (CET) Received: from [192.168.217.117] (p54892CA5.dip.t-dialin.net [84.137.44.165]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id E5BAAC34; Wed, 5 Dec 2012 07:54:30 +0100 (CET) From: Carsten Bormann Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Wed, 5 Dec 2012 07:54:30 +0100 To: "core@ietf.org WG" Message-Id: Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) Subject: [core] Preliminary feedback from ETSI CoAP#2 plugtest X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 05 Dec 2012 06:54:41 -0000 ETSI was kind enough to provide some quick feedback from the CoAP#2 = plugtest that took place in Sophia Antipolis last week. I have put up the preliminary overview slides at: http://svn.tools.ietf.org/svn/wg/core/Preliminary-Results-CoAP%232.pdf As usual for an industrial interoperability testing event, the details = are under NDA, but let me just summarize this as a pretty good success. We managed to get 60 pairings (different clients with different servers) = tested, and got some 97.8 % of the test cases run to be interoperable. More directly influencing the work of this WG, there also have been some = technical observations. The preliminary write-up is at: = http://svn.tools.ietf.org/svn/wg/core/Preliminary-Technical-feedback-from-= CoAP%232-Plugtest.pdf As in the above: Please excuse any errors in this -- the emphasis was on = speed of feedback, not on editorial perfection. One item that became obvious in the testing was already picked up in = Ticket #265: http://trac.tools.ietf.org/wg/core/trac/ticket/265 Please have a look at the ETSI feedback document for some more technical = background. I haven't seen any feedback on #265 beyond the hallway discussions = during the plug test. I think it is obvious that the text about 2.03 needs to be clarified. It is also pretty clear that we want to follow HTTPbis' lead about = defining the term "selected representation". Whether we want to allow ETag on 2.01, 2.02*), 2.04 maybe can be = debated, but it seems to me this wouldn't impose any increased = complexity on implementations: Servers are in no way obliged to send = these ETags (and certainly shouldn't be), and clients can ignore them. So there seems to be little negative impact from allowing the ETags. Finally, we may want to allow an ETag even on an error response such as = 4.12; this may need a bit more discussion. The other item highlighted in the technical feedback document is about = the choice between confirmable and non-confirmable Observe = notifications. This may lead to some clarifications in Observe. More = directly influencing the impending WGLC on the core CoAP specification, = we maybe should reconfirm whether section 5.2.3 does say all that it = needs to say. Many thanks to the plugtest participants, and particularly to Laurent = Velez for organizing the event and documenting its results so quickly! Gr=FC=DFe, Carsten *) Yes, deleting a resource can make a default representation spring = back, so for consistency we should allow ETags even there.= From trac+core@trac.tools.ietf.org Wed Dec 5 11:01:33 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1C2621F869C for ; Wed, 5 Dec 2012 11:01:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yx9Wuf39qEQE for ; Wed, 5 Dec 2012 11:01:33 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 7578321F84F8 for ; Wed, 5 Dec 2012 11:01:27 -0800 (PST) Received: from localhost ([127.0.0.1]:49963 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1TgKDW-0005o4-1H; Wed, 05 Dec 2012 20:01:10 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "core issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-core-coap@tools.ietf.org, cabo@tzi.org X-Trac-Project: core Date: Wed, 05 Dec 2012 19:01:09 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: /ticket/256#comment:1 Message-ID: <072.e18cf530761b2a7223eda987badc7c6e@trac.tools.ietf.org> References: <057.a275d4eab7b92af3040f5be8e8fd5844@trac.tools.ietf.org> X-Trac-Ticket-ID: 256 In-Reply-To: <057.a275d4eab7b92af3040f5be8e8fd5844@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-core-coap@tools.ietf.org, cabo@tzi.org, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: brian@skyfoundry.com, cabo@tzi.org, hartke@tzi.org, zach@sensinode.com Resent-Message-Id: <20121205190127.7578321F84F8@ietfa.amsl.com> Resent-Date: Wed, 5 Dec 2012 11:01:27 -0800 (PST) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: Re: [core] #256: Caching text needs to be updated X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Reply-To: trac+core@trac.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2012 19:01:33 -0000 #256: Caching text needs to be updated Changes (by cabo@tzi.org): * status: new => closed * resolution: => fixed Comment: Fixed in [1087]: Fix #256 -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core- zach@sensinode.com | coap@tools.ietf.org Type: editorial | Status: closed Priority: minor | Milestone: post-WGLC-1 Component: coap | Version: coap-12 Severity: In WG Last | Resolution: fixed Call | Keywords: | -------------------------+------------------------------------------------- Ticket URL: core From trac+core@trac.tools.ietf.org Wed Dec 5 11:09:25 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FFD021F8C5C for ; Wed, 5 Dec 2012 11:09:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6C3rKwnX43dD for ; Wed, 5 Dec 2012 11:09:24 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 800B021F8C3F for ; Wed, 5 Dec 2012 11:09:24 -0800 (PST) Received: from localhost ([127.0.0.1]:50862 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1TgKLH-0002Gm-UI; Wed, 05 Dec 2012 20:09:11 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "core issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-core-coap@tools.ietf.org, cabo@tzi.org X-Trac-Project: core Date: Wed, 05 Dec 2012 19:09:11 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: /ticket/254#comment:1 Message-ID: <072.9d02b90c94167e14bd8f520da6eacc99@trac.tools.ietf.org> References: <057.ec774322b67c4c328255575fa02402bb@trac.tools.ietf.org> X-Trac-Ticket-ID: 254 In-Reply-To: <057.ec774322b67c4c328255575fa02402bb@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-core-coap@tools.ietf.org, cabo@tzi.org, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: brian@skyfoundry.com, cabo@tzi.org, hartke@tzi.org, zach@sensinode.com Resent-Message-Id: <20121205190924.800B021F8C3F@ietfa.amsl.com> Resent-Date: Wed, 5 Dec 2012 11:09:24 -0800 (PST) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: Re: [core] #254: Max-Age MUST IMPLEMENT for proxies X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Reply-To: trac+core@trac.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2012 19:09:25 -0000 #254: Max-Age MUST IMPLEMENT for proxies Changes (by cabo@tzi.org): * status: new => closed * resolution: => fixed Comment: Fixed in [1088]: Fix #254 -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core- zach@sensinode.com | coap@tools.ietf.org Type: other | Status: closed technical | Milestone: post-WGLC-1 Priority: minor | Version: coap-12 Component: coap | Resolution: fixed Severity: In WG Last | Call | Keywords: | -------------------------+------------------------------------------------- Ticket URL: core From andrewmcgr@gmail.com Wed Dec 5 16:07:28 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8900C21F8CDD for ; Wed, 5 Dec 2012 16:07:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hB-AyrYGXkAb for ; Wed, 5 Dec 2012 16:07:23 -0800 (PST) Received: from mail-da0-f44.google.com (mail-da0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5A9E921F8965 for ; Wed, 5 Dec 2012 16:07:20 -0800 (PST) Received: by mail-da0-f44.google.com with SMTP id z20so2375236dae.31 for ; Wed, 05 Dec 2012 16:07:20 -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 :content-transfer-encoding:message-id:references:to:x-mailer; bh=3u/gyCK6Pbflmr2DWg0bRNyka+6hDhjI0UTDdIypPKs=; b=vxntXaptqJ0E43hoL7svrqWxPWJR022j9W5oOl9UG2TxBRxQDnitGJD9k7WOoJGiYt trAA5KlsuWAQbPN3vH+l7w2wSN4pMIhpiVAIYhrtMpsV6N9JhaLOaHKo0vH8nMoKL5vR 0PaHxjxGHYV37cwJK+GmDh7+6cmkCxhSXO9oiGo8QcORFBMKAlEepLAnMm/jhF2DXh4q 7D7pBMhti/PRekY8ILo7JhHE3fOeRuyKF3jTETf/hbIBdBB3jv8o+HKdlJtrNhkyZh+K FduUmFLLapL9C9HVoduZCn6jKWnOr8w6ZyWBWIuk7D+08fQIJWPMygMUlCFst4Ha1fUt /3EQ== Received: by 10.68.252.4 with SMTP id zo4mr643979pbc.126.1354752440039; Wed, 05 Dec 2012 16:07:20 -0800 (PST) Received: from ?IPv6:2406:e000:316:24:bc94:799e:5db:e756? ([2406:e000:316:24:bc94:799e:5db:e756]) by mx.google.com with ESMTPS id d9sm3509300paw.33.2012.12.05.16.07.17 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 05 Dec 2012 16:07:19 -0800 (PST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Andrew McGregor In-Reply-To: <51803EE3-A997-4DA4-A918-83B0B5B82996@tzi.org> Date: Thu, 6 Dec 2012 13:07:07 +1300 Content-Transfer-Encoding: quoted-printable Message-Id: <174DFB85-EACD-46CA-8032-5E5AA84CD3E2@gmail.com> References: <55877B3AFB359744BA0F2140E36F52B514D26D1F@MBX10.d.ethz.ch> <5DC25716-A8E1-4FC7-B932-3079CFB703C4@tzi.org> <55877B3AFB359744BA0F2140E36F52B514D26E8B@MBX10.d.ethz.ch> <46A1DF3F04371240B504290A071B4DB63C877351@szxeml509-mbx> <9160F42C-566E-445C-BF13-F57B6F67C740@tzi.org> <50DEDC36-8397-413C-B6FD-7B2BE5D1207B@tzi.org> <3DDE1B3C-CBF4-4773-A3C2-AA61856B270C@sensinode.com> <9FCF6E24-CE7C-4E26-887A-0918369C992D@tzi.org> <6AF38EAF-DB60-4D6F-AE99-5226034917DB@intec.ugent.be> <51803EE3-A997-4DA4-A918-83B0B5B82996@tzi.org> To: Carsten Bormann X-Mailer: Apple Mail (2.1499) Cc: "core@ietf.org WG" Subject: Re: [core] Call for consensus: Should we switch out the option encoding? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 06 Dec 2012 00:07:28 -0000 The consensus call window has now passed. We have clear support for making the change, and no disagreement. Therefore, the chairs request the draft authors to integrate Klaus's = proposal and make the necessary changes to the text. Thanks, Andrew On 1/12/2012, at 3:09 AM, Carsten Bormann wrote: > On Nov 30, 2012, at 14:48, Klaus Hartke wrote: >=20 >> >=20 > Thanks, Klaus. =20 > This version doesn't contain all the editorial fixes that were = discussed on the list, but these can be done in parallel to making the = decision. >=20 > Normally, we do minor technical decisions by having a discussion and = then simply putting in the new text into the next revision of a WG = draft. > However, this is another breaking change, and although the IETF = process does allow us to make breaking changes as much as we want, = reality doesn't -- we should only make them if the benefits really = justify the cost of changing out all tools (including the WireShark that = you probably already have installed even if you don't know it), = temporarily partitioning the interop testing world into the laggards and = the radicals, making previous pcap files less useful for future tests = etc. >=20 > Other messages have discussed the quantifiable and not so quantifiable = advantages (and disadvantages) of the new proposal. > I think I can already state consensus that the new proposal is = simpler, which fits the goals of the WG well. >=20 > So my question to the WG is now: Do we as a WG have consensus to make = this change at this time? > Whether you answer yes or no, it would be useful to add a line or so = of text indicating what motivates your decision. >=20 > In order not to lose time, please send in your replies (with this = subject) to this mailing list by >=20 > -> 2012-12-05, 23:59 UTC. >=20 > This will enable us to announce a decision (and, I hope, get coap-13 = published) right on Sinterklaas. >=20 > Gr=FC=DFe, Carsten >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core From trac+core@trac.tools.ietf.org Wed Dec 5 16:14:41 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB3C221F8AB4 for ; Wed, 5 Dec 2012 16:14:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HNIlMKxSKH-Z for ; Wed, 5 Dec 2012 16:14:41 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 33ED421F871A for ; Wed, 5 Dec 2012 16:14:40 -0800 (PST) Received: from localhost ([127.0.0.1]:43805 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1TgP6i-0001oj-Ph; Thu, 06 Dec 2012 01:14:28 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "core issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: cabo@tzi.org, tho@koanlogic.com X-Trac-Project: core Date: Thu, 06 Dec 2012 00:14:28 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/259#comment:3 Message-ID: <066.0194930588ae89d2c30a346bb97fcd77@trac.tools.ietf.org> References: <051.b150c522197456646133cd1bca831535@trac.tools.ietf.org> X-Trac-Ticket-ID: 259 In-Reply-To: <051.b150c522197456646133cd1bca831535@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: cabo@tzi.org, tho@koanlogic.com, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: Re: [core] #259: Standardize a workaround for HTTP library limitations in talking to forward HTTP-COAP cross-proxies? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Reply-To: trac+core@trac.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2012 00:14:41 -0000 #259: Standardize a workaround for HTTP library limitations in talking to forward HTTP-COAP cross-proxies? Changes (by cabo@tzi.org): * status: assigned => closed * resolution: => fixed Comment: Fixed in coap-13 in combination with draft-bormann-core-cross-reverse- convention-00.txt -- -----------------------------+--------------------------- Reporter: cabo@tzi.org | Owner: cabo@tzi.org Type: other technical | Status: closed Priority: minor | Milestone: post-WGLC-1 Component: coap | Version: coap-09 Severity: In WG Last Call | Resolution: fixed Keywords: | -----------------------------+--------------------------- Ticket URL: core From trac+core@trac.tools.ietf.org Wed Dec 5 16:18:14 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06AC221F8765 for ; Wed, 5 Dec 2012 16:18:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bo8zqUgLVMXV for ; Wed, 5 Dec 2012 16:18:13 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 73DBC21F874D for ; Wed, 5 Dec 2012 16:18:13 -0800 (PST) Received: from localhost ([127.0.0.1]:43981 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1TgPAJ-0007Ef-Pq; Thu, 06 Dec 2012 01:18:11 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "core issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: cabo@tzi.org, tho@koanlogic.com X-Trac-Project: core Date: Thu, 06 Dec 2012 00:18:11 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: /ticket/259#comment:4 Message-ID: <066.529e3a273248e81a6bc490787eff3e6f@trac.tools.ietf.org> References: <051.b150c522197456646133cd1bca831535@trac.tools.ietf.org> X-Trac-Ticket-ID: 259 In-Reply-To: <051.b150c522197456646133cd1bca831535@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: cabo@tzi.org, tho@koanlogic.com, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: Re: [core] #259: Standardize a workaround for HTTP library limitations in talking to forward HTTP-COAP cross-proxies? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Reply-To: trac+core@trac.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2012 00:18:14 -0000 #259: Standardize a workaround for HTTP library limitations in talking to forward HTTP-COAP cross-proxies? Comment (by cabo@tzi.org): Fixed in [1095]: Provide a reference to a placeholder I-D in order to close #259. -- -----------------------------+--------------------------- Reporter: cabo@tzi.org | Owner: cabo@tzi.org Type: other technical | Status: closed Priority: minor | Milestone: post-WGLC-1 Component: coap | Version: coap-09 Severity: In WG Last Call | Resolution: fixed Keywords: | -----------------------------+--------------------------- Ticket URL: core From cabo@tzi.org Wed Dec 5 16:55:35 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0191D21F8BCB for ; Wed, 5 Dec 2012 16:55:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W7kSMaz1-5or for ; Wed, 5 Dec 2012 16:55:34 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 303F621F8BC9 for ; Wed, 5 Dec 2012 16:55:33 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id qB60tNng000709 for ; Thu, 6 Dec 2012 01:55:23 +0100 (CET) Received: from [192.168.217.105] (p5489215B.dip.t-dialin.net [84.137.33.91]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 6C9912EC; Thu, 6 Dec 2012 01:55:23 +0100 (CET) From: Carsten Bormann Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Thu, 6 Dec 2012 01:55:22 +0100 To: "core@ietf.org WG" Message-Id: <6B66FABC-3BE3-488D-B8ED-AC41C8CFB68E@tzi.org> Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) Subject: [core] Closing out remaining tickets for core-coap X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 06 Dec 2012 00:55:35 -0000 We need to clear out the remaining tickets open on core-coap. There has been little recent discussion. =20 This is understandable as they are mostly rather inconsequential in the = big picture of things, but we need to make decisions for coap-13. Obviously, all these decisions will then be subject to the next = Working-Group last-call, but I'd like to go in there with some = well-thought-out input. #262: I expect that we'll split out IPsec as described in the ticket. (I just did something similar for #259, by the way). #265: This turns out to be more editorial work than I thought. I do expect that we will go with enabling the use of ETag in all = responses where a good rule can be made to explain what representation = is meant. #247: Go with Internetwork Control Block and link-local/site-local, see https://www.ietf.org/mail-archive/web/core/current/msg03801.html #255: It is probably premature to define this when at the same time we = have said that CoAP isn't tied to DNS at all. Whatever we do here will be taken apart and put together again by = security people who are likely thinking in DNS terms. Catch-22. Input would be welcome. #257: as proposed #260: as discussed in Atlanta #261: ongoing, but there will be some 60+ SHOULDs remaining. Many of = these do actually define the reasons for potential exceptions. Many others are in somewhat more flexible parts of the document, e.g. in = the cross-proxying section. So I think this order of magnitude is = justifiable. #263: I'd rather replace 8.2.2 with a "for further study". We don't = know how to do this properly right now. #264: How about defining a "diagnostic payload" as that in an error = message that has payload but no Content-Format? So if a server does want to provide some HATEOAS payload for an error = response, it will need to put in a Content-Format. Content-Format would remain optional for 2.xx responses. Please shout if any of this is the wrong way to go. Gr=FC=DFe, Carsten From trac+core@trac.tools.ietf.org Thu Dec 6 00:51:26 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E34D721F859A for ; Thu, 6 Dec 2012 00:51:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fow2qTzRSUoq for ; Thu, 6 Dec 2012 00:51:26 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id F004C21F857B for ; Thu, 6 Dec 2012 00:51:25 -0800 (PST) Received: from localhost ([127.0.0.1]:51445 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1TgXAb-0001mt-28; Thu, 06 Dec 2012 09:51:01 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "core issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-core-coap@tools.ietf.org, esko.dijk@philips.com X-Trac-Project: core Date: Thu, 06 Dec 2012 08:51:00 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/257#comment:1 Message-ID: <066.32862bf7912d8eff946341eb2c21cd50@trac.tools.ietf.org> References: <051.bfa8620fef2432adf8e7cc19532dcb39@trac.tools.ietf.org> X-Trac-Ticket-ID: 257 In-Reply-To: <051.bfa8620fef2432adf8e7cc19532dcb39@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-core-coap@tools.ietf.org, esko.dijk@philips.com, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: brian@skyfoundry.com, cabo@tzi.org, hartke@tzi.org, zach@sensinode.com Resent-Message-Id: <20121206085125.F004C21F857B@ietfa.amsl.com> Resent-Date: Thu, 6 Dec 2012 00:51:25 -0800 (PST) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: Re: [core] #257: URI references and multicast requests X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Reply-To: trac+core@trac.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2012 08:51:27 -0000 #257: URI references and multicast requests Comment (by esko.dijk@philips.com): This will not work if the multicast request was sent via a proxy (instead of the client sending directly). (Am I correct?) A solution may be tied to the solution for ticket #263. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core- cabo@tzi.org | coap@tools.ietf.org Type: other | Status: new technical | Milestone: post-WGLC-1 Priority: minor | Version: coap-11 Component: coap | Resolution: Severity: In WG Last | Call | Keywords: | -------------------------+------------------------------------------------- Ticket URL: core From esko.dijk@philips.com Thu Dec 6 01:12:38 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 922F821F8667 for ; Thu, 6 Dec 2012 01:12:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bpC8Fsgd6sNR for ; Thu, 6 Dec 2012 01:12:37 -0800 (PST) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe001.messaging.microsoft.com [216.32.181.181]) by ietfa.amsl.com (Postfix) with ESMTP id E505A21F8660 for ; Thu, 6 Dec 2012 01:12:36 -0800 (PST) Received: from mail70-ch1-R.bigfish.com (10.43.68.249) by CH1EHSOBE013.bigfish.com (10.43.70.63) with Microsoft SMTP Server id 14.1.225.23; Thu, 6 Dec 2012 09:12:35 +0000 Received: from mail70-ch1 (localhost [127.0.0.1]) by mail70-ch1-R.bigfish.com (Postfix) with ESMTP id E14CE48026A; Thu, 6 Dec 2012 09:12:35 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.55.7.222; KIP:(null); UIP:(null); IPV:NLI; H:mail.philips.com; RD:none; EFVD:NLI X-SpamScore: -10 X-BigFish: VPS-10(zz217bI15d6O9251Jc85fhzz1de0h1202h1d1ah1d2ahzz18c673hz2dh2a8h668h839hd25hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh15d0h162dh1631h1155h) Received: from mail70-ch1 (localhost.localdomain [127.0.0.1]) by mail70-ch1 (MessageSwitch) id 1354785153545545_18417; Thu, 6 Dec 2012 09:12:33 +0000 (UTC) Received: from CH1EHSMHS038.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.253]) by mail70-ch1.bigfish.com (Postfix) with ESMTP id 814CB800B5; Thu, 6 Dec 2012 09:12:33 +0000 (UTC) Received: from mail.philips.com (157.55.7.222) by CH1EHSMHS038.bigfish.com (10.43.69.247) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 6 Dec 2012 09:12:31 +0000 Received: from 011-DB3MMR1-013.MGDPHG.emi.philips.com (10.128.28.97) by 011-DB3MMR1-006.MGDPHG.emi.philips.com (10.128.28.56) with Microsoft SMTP Server (TLS) id 14.2.318.3; Thu, 6 Dec 2012 09:12:31 +0000 Received: from 011-DB3MPN2-082.MGDPHG.emi.philips.com ([169.254.2.225]) by 011-DB3MMR1-013.MGDPHG.emi.philips.com ([10.128.28.97]) with mapi id 14.02.0318.003; Thu, 6 Dec 2012 09:12:30 +0000 From: "Dijk, Esko" To: "core@ietf.org WG" , Carsten Bormann Thread-Topic: #264: Content-Format of error responses Thread-Index: Ac3TkdFQGCQyc/HsRyGfc9lCS+JZFA== Date: Thu, 6 Dec 2012 09:12:30 +0000 Message-ID: <031DD135F9160444ABBE3B0C36CED618B36BC3@011-DB3MPN2-082.MGDPHG.emi.philips.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [194.171.252.103] Content-Type: multipart/alternative; boundary="_000_031DD135F9160444ABBE3B0C36CED618B36BC3011DB3MPN2082MGDP_" MIME-Version: 1.0 X-OriginatorOrg: philips.com Subject: [core] #264: Content-Format of error responses X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 06 Dec 2012 09:12:38 -0000 --_000_031DD135F9160444ABBE3B0C36CED618B36BC3011DB3MPN2082MGDP_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Carsten, > #264: How about defining a "diagnostic payload" as that in an error messa= ge that has payload but no Content-Format? > So if a server does want to provide some HATEOAS payload for an error res= ponse, it will need to put in a Content-Format. > Content-Format would remain optional for 2.xx responses. Agree with a "diagnostic payload" to replace "diagnostic message" (sec 5.5.= 2). I assume any 2.xx, 4.xx or 5.xx response could use such a diagnostic pa= yload then? (With exception of 2.05 - and maybe some others too?) I also assume that we should state then that an implementation SHOULD NOT r= eturn a payload with Content-Format option value 0, if it actually intends = this as diagnostic payload. (Rather than as an 'HATEOAS related response pa= yload') regards Esko ________________________________ The information contained in this message may be confidential and legally p= rotected under applicable law. The message is intended solely for the addre= ssee(s). If you are not the intended recipient, you are hereby notified tha= t any use, forwarding, dissemination, or reproduction of this message is st= rictly prohibited and may be unlawful. If you are not the intended recipien= t, please contact the sender by return e-mail and destroy all copies of the= original message. --_000_031DD135F9160444ABBE3B0C36CED618B36BC3011DB3MPN2082MGDP_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Carsten,

 

> #264: How about defining a "diagnostic = payload" as that in an error message that has payload but no Content-F= ormat?

> So if a server does want to provide some HAT= EOAS payload for an error response, it will need to put in a Content-Format= .

> Content-Format would remain optional for 2.x= x responses.

 

Agree with a “diagnostic payload” to = replace “diagnostic message” (sec 5.5.2). I assume any 2.xx, 4.= xx or 5.xx response could use such a diagnostic payload then? (With excepti= on of 2.05 – and maybe some others too?)

 

I also assume that we should state then that an i= mplementation SHOULD NOT return a payload with Content-Format option value = 0, if it actually intends this as diagnostic payload. (Rather than as an 'H= ATEOAS related response payload’)

   

regards

Esko


The information contained in= this message may be confidential and legally protected under applicable la= w. The message is intended solely for the addressee(s). If you are not the = intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message i= s strictly prohibited and may be unlawful. If you are not the intended reci= pient, please contact the sender by return e-mail and destroy all copies of= the original message.
 --_000_031DD135F9160444ABBE3B0C36CED618B36BC3011DB3MPN2082MGDP_-- From cabo@tzi.org Thu Dec 6 01:25:18 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F2C021F857A for ; Thu, 6 Dec 2012 01:25:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P4IP3iieW7m8 for ; Thu, 6 Dec 2012 01:25:17 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 2F14A21F8558 for ; Thu, 6 Dec 2012 01:25:16 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id qB69P9rQ015326; Thu, 6 Dec 2012 10:25:09 +0100 (CET) Received: from [192.168.217.105] (p5489215B.dip.t-dialin.net [84.137.33.91]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 1B2BC3DB; Thu, 6 Dec 2012 10:25:09 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Content-Type: text/plain; charset=windows-1252 From: Carsten Bormann In-Reply-To: <031DD135F9160444ABBE3B0C36CED618B36BC3@011-DB3MPN2-082.MGDPHG.emi.philips.com> Date: Thu, 6 Dec 2012 10:25:07 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <031DD135F9160444ABBE3B0C36CED618B36BC3@011-DB3MPN2-082.MGDPHG.emi.philips.com> To: "Dijk, Esko" X-Mailer: Apple Mail (2.1499) Cc: "core@ietf.org WG" Subject: Re: [core] #264: Content-Format of error responses X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 06 Dec 2012 09:25:18 -0000 On Dec 6, 2012, at 10:12, "Dijk, Esko" wrote: > Agree with a =93diagnostic payload=94 to replace =93diagnostic = message=94 (sec 5.5.2). I assume any 2.xx, 4.xx or 5.xx response could = use such a diagnostic payload then? (With exception of 2.05 =96 and = maybe some others too?) In coap-12, diagnostic payloads are only available for error responses = (4.xx, 5.xx). Do we want to change that? People seem to like being able to serve 2.05 with indeterminate = Content-Format. Reinterpreting success response payloads as diagnostic = in the absence of Content-Format might be more consistent, but might = also be surprising. So what I was proposing was strictly for error responses. > I also assume that we should state then that an implementation SHOULD = NOT return a payload with Content-Format option value 0, if it actually = intends this as diagnostic payload. (Rather than as an 'HATEOAS related = response payload=92) Exactly. Gr=FC=DFe, Carsten From esko.dijk@philips.com Thu Dec 6 01:31:02 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF17421F85E3 for ; Thu, 6 Dec 2012 01:31:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eAnvXr2p96X5 for ; Thu, 6 Dec 2012 01:31:01 -0800 (PST) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe002.messaging.microsoft.com [216.32.180.185]) by ietfa.amsl.com (Postfix) with ESMTP id 60F2121F85DA for ; Thu, 6 Dec 2012 01:31:00 -0800 (PST) Received: from mail51-co1-R.bigfish.com (10.243.78.234) by CO1EHSOBE008.bigfish.com (10.243.66.71) with Microsoft SMTP Server id 14.1.225.23; Thu, 6 Dec 2012 09:31:00 +0000 Received: from mail51-co1 (localhost [127.0.0.1]) by mail51-co1-R.bigfish.com (Postfix) with ESMTP id 37FDDA802F6; Thu, 6 Dec 2012 09:31:00 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.55.7.222; KIP:(null); UIP:(null); IPV:NLI; H:mail.philips.com; RD:none; EFVD:NLI X-SpamScore: -32 X-BigFish: VPS-32(zz217bI98dI15d6O9251Jc89bhd6eah542Izz1de0h1202h1d1ah1d2ahzz1033IL8275bh8275dhz2dh2a8h668h839h947hd25hf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1155h) Received: from mail51-co1 (localhost.localdomain [127.0.0.1]) by mail51-co1 (MessageSwitch) id 1354786258333228_31719; Thu, 6 Dec 2012 09:30:58 +0000 (UTC) Received: from CO1EHSMHS016.bigfish.com (unknown [10.243.78.229]) by mail51-co1.bigfish.com (Postfix) with ESMTP id 44864C80072; Thu, 6 Dec 2012 09:30:58 +0000 (UTC) Received: from mail.philips.com (157.55.7.222) by CO1EHSMHS016.bigfish.com (10.243.66.26) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 6 Dec 2012 09:30:54 +0000 Received: from 011-DB3MPN2-082.MGDPHG.emi.philips.com ([169.254.2.225]) by 011-DB3MMR1-011.MGDPHG.emi.philips.com ([10.128.28.50]) with mapi id 14.02.0318.003; Thu, 6 Dec 2012 09:30:20 +0000 From: "Dijk, Esko" To: Carsten Bormann Thread-Topic: #264: Content-Format of error responses Thread-Index: Ac3TkdFQGCQyc/HsRyGfc9lCS+JZFAAAcNGAAAAdGgA= Date: Thu, 6 Dec 2012 09:30:20 +0000 Message-ID: <031DD135F9160444ABBE3B0C36CED618B36BED@011-DB3MPN2-082.MGDPHG.emi.philips.com> References: <031DD135F9160444ABBE3B0C36CED618B36BC3@011-DB3MPN2-082.MGDPHG.emi.philips.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [194.171.252.103] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: philips.com Cc: "core@ietf.org WG" Subject: Re: [core] #264: Content-Format of error responses X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 06 Dec 2012 09:31:02 -0000 > In coap-12, diagnostic payloads are only available for error responses (4= .xx, 5.xx). Do we want to change that? Not a strong opinion on that. For 2.xx responses it seems a server can still return a text string with a = message and add Content-Format 0, as a "representation of the action result= ". So this would be a kind of diagnostic message in disguise. Esko -----Original Message----- From: Carsten Bormann [mailto:cabo@tzi.org] Sent: Thursday 6 December 2012 10:25 To: Dijk, Esko Cc: core@ietf.org WG Subject: Re: #264: Content-Format of error responses On Dec 6, 2012, at 10:12, "Dijk, Esko" wrote: > Agree with a "diagnostic payload" to replace "diagnostic message" (sec 5.= 5.2). I assume any 2.xx, 4.xx or 5.xx response could use such a diagnostic = payload then? (With exception of 2.05 - and maybe some others too?) In coap-12, diagnostic payloads are only available for error responses (4.x= x, 5.xx). Do we want to change that? People seem to like being able to serve 2.05 with indeterminate Content-For= mat. Reinterpreting success response payloads as diagnostic in the absence= of Content-Format might be more consistent, but might also be surprising. So what I was proposing was strictly for error responses. > I also assume that we should state then that an implementation SHOULD NOT= return a payload with Content-Format option value 0, if it actually intend= s this as diagnostic payload. (Rather than as an 'HATEOAS related response = payload') Exactly. Gr=FC=DFe, Carsten ________________________________ The information contained in this message may be confidential and legally p= rotected under applicable law. The message is intended solely for the addre= ssee(s). If you are not the intended recipient, you are hereby notified tha= t any use, forwarding, dissemination, or reproduction of this message is st= rictly prohibited and may be unlawful. If you are not the intended recipien= t, please contact the sender by return e-mail and destroy all copies of the= original message. From cabo@tzi.org Thu Dec 6 01:43:03 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9396A21F865C for ; Thu, 6 Dec 2012 01:43:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m5HpSd+jI+RV for ; Thu, 6 Dec 2012 01:43:02 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 6583F21F84F8 for ; Thu, 6 Dec 2012 01:43:02 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id qB69glqd025271; Thu, 6 Dec 2012 10:42:47 +0100 (CET) Received: from [192.168.217.105] (p5489215B.dip.t-dialin.net [84.137.33.91]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 82716406; Thu, 6 Dec 2012 10:42:46 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: <066.32862bf7912d8eff946341eb2c21cd50@trac.tools.ietf.org> Date: Thu, 6 Dec 2012 10:42:45 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <8BDDB35D-02C9-400B-A36B-82A7DE249861@tzi.org> References: <051.bfa8620fef2432adf8e7cc19532dcb39@trac.tools.ietf.org> <066.32862bf7912d8eff946341eb2c21cd50@trac.tools.ietf.org> To: trac+core@grenache.tools.ietf.org X-Mailer: Apple Mail (2.1499) Cc: draft-ietf-core-coap@tools.ietf.org, core@ietf.org Subject: Re: [core] #257: URI references and multicast requests X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 06 Dec 2012 09:43:03 -0000 On Dec 6, 2012, at 09:51, "core issue tracker" = wrote: > This (reinterpreting the base URI with the responding endpoint address as = authority) > will not work if the multicast request was sent via a proxy (instead > of the client sending directly). (Am I correct?) > A solution may be tied to the solution for ticket #263. As I said, I don't think we can solve 263 without adding machinery. Too few people seem to be working on this specific use case -- it will = be hard to ensure that any machinery we come up with is good machinery. Your observation also is an instance of a more general problem: A = reverse-proxy that is forwarding representations with embedded URIs = needs to make sure that these are valid on its client side. This is, in = general, impossible without knowledge of (and an implementation of a URI = rewriter for) the specific Content-Format. In the Web we are generally solving this by having origin servers = already put in globally useful URIs. That would work here, too. This can be done by using full URIs with globally useful authorities, or = relative URIs (generally with relative-paths) where there is a good hope = that even after reverse-proxying these still work. The latter clearly = doesn't work for proxying to multicast unless the origin endpoint = information is somehow passed (a Base-URI response option?); the former = does. Gr=FC=DFe, Carsten From trac+core@trac.tools.ietf.org Thu Dec 6 05:53:35 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D1A821F8751 for ; Thu, 6 Dec 2012 05:53:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z0epSrlUw2yy for ; Thu, 6 Dec 2012 05:53:35 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id D740421F873C for ; Thu, 6 Dec 2012 05:53:34 -0800 (PST) Received: from localhost ([127.0.0.1]:44076 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1Tgbt8-0003Ob-F2; Thu, 06 Dec 2012 14:53:18 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "core issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-core-coap@tools.ietf.org, cabo@tzi.org X-Trac-Project: core Date: Thu, 06 Dec 2012 13:53:18 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: /ticket/264#comment:1 Message-ID: <066.af49a65e67645a96827e9d9faec11e5e@trac.tools.ietf.org> References: <051.67502ba5c047d87e31961ad044f22cef@trac.tools.ietf.org> X-Trac-Ticket-ID: 264 In-Reply-To: <051.67502ba5c047d87e31961ad044f22cef@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-core-coap@tools.ietf.org, cabo@tzi.org, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: brian@skyfoundry.com, cabo@tzi.org, hartke@tzi.org, zach@sensinode.com Resent-Message-Id: <20121206135334.D740421F873C@ietfa.amsl.com> Resent-Date: Thu, 6 Dec 2012 05:53:34 -0800 (PST) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: Re: [core] #264: Content-Format of error responses X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Reply-To: trac+core@trac.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2012 13:53:35 -0000 #264: Content-Format of error responses Changes (by cabo@tzi.org): * status: new => closed * resolution: => fixed Comment: Fixed in [1097]: close #264 as discussed -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core- cabo@tzi.org | coap@tools.ietf.org Type: other | Status: closed technical | Milestone: post-WGLC-1 Priority: minor | Version: coap-12 Component: coap | Resolution: fixed Severity: In WG Last | Call | Keywords: | -------------------------+------------------------------------------------- Ticket URL: core From hartke@tzi.org Thu Dec 6 06:29:01 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 995E921F8731 for ; Thu, 6 Dec 2012 06:29:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.127 X-Spam-Level: X-Spam-Status: No, score=-3.127 tagged_above=-999 required=5 tests=[AWL=2.500, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LPsyqcj2xZtD for ; Thu, 6 Dec 2012 06:29:01 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id D659B21F86AC for ; Thu, 6 Dec 2012 06:29:00 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id qB6ESqmg010274 for ; Thu, 6 Dec 2012 15:28:54 +0100 (CET) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id F3EEB6BF for ; Thu, 6 Dec 2012 15:28:51 +0100 (CET) Received: by mail-pa0-f44.google.com with SMTP id hz11so4313183pad.31 for ; Thu, 06 Dec 2012 06:28:50 -0800 (PST) Received: by 10.68.234.100 with SMTP id ud4mr6304367pbc.82.1354804130013; Thu, 06 Dec 2012 06:28:50 -0800 (PST) MIME-Version: 1.0 Received: by 10.68.75.75 with HTTP; Thu, 6 Dec 2012 06:28:29 -0800 (PST) In-Reply-To: <031DD135F9160444ABBE3B0C36CED618B36BC3@011-DB3MPN2-082.MGDPHG.emi.philips.com> References: <031DD135F9160444ABBE3B0C36CED618B36BC3@011-DB3MPN2-082.MGDPHG.emi.philips.com> From: Klaus Hartke Date: Thu, 6 Dec 2012 16:28:29 +0200 Message-ID: To: "core@ietf.org WG" Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [core] #264: Content-Format of error responses X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 06 Dec 2012 14:29:01 -0000 Carsten Bormann wrote: > #264: How about defining a "diagnostic payload" as that in an error > message that has payload but no Content-Format? There are three types of representations that a response can transport: * the representation of a resource state, * the representation of the successful outcome of an action, and * the representation of an error. So "diagnostic payload" is the wrong term here. coap-12 makes a special case for error responses in that these actually do not transport a representation like any other response type does, but a special "diagnostic message" with no option for other formats. The ticket is simply about removing that special case and transport a representation like all other responses. The question is how to specify the content format of that representation. For other representations types, this is done by using the Content-Format Option, where an absent option means that the implementation needs out-of-band information to correctly interpret the data. The format of representations of errors should do the same, although I guess it would be acceptable here to default an absent Content-Format Option to "text/coap-diagnostic-message" or something like that. Klaus From carine@jay.w3.org Thu Dec 6 06:43:13 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E3E921F8731 for ; Thu, 6 Dec 2012 06:43:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NnHiNaf2Oyb0 for ; Thu, 6 Dec 2012 06:43:12 -0800 (PST) Received: from jay.w3.org (ssh.w3.org [128.30.52.60]) by ietfa.amsl.com (Postfix) with ESMTP id 9A13821F8722 for ; Thu, 6 Dec 2012 06:43:11 -0800 (PST) Received: from carine by jay.w3.org with local (Exim 4.69) (envelope-from ) id 1TgcfM-0002vA-0h; Thu, 06 Dec 2012 09:43:08 -0500 Date: Thu, 6 Dec 2012 09:43:08 -0500 From: Carine Bournez To: Carsten Bormann Message-ID: <20121206144307.GD13496@jay.w3.org> References: <20121129100041.GA14246@jay.w3.org> <1560E310-E8D0-43F9-A4EE-30CC62723F35@tzi.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1560E310-E8D0-43F9-A4EE-30CC62723F35@tzi.org> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: core@ietf.org Subject: Re: [core] W3C EXI WG review of IETF CoRE WG Internet Drafts X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 06 Dec 2012 14:43:13 -0000 Hi, On Mon, Dec 03, 2012 at 09:27:08AM +0100, Carsten Bormann wrote: > > the cleanest way would be still to use a content-encoding mechanism > > rather than a separate content-type indicating that EXI is used. So > > instead of: > > > > 'Accept: application/example-exi;sv=1.4' > > > > we suggest: > > > > 'Accept: application/example;sv=1.4' > > 'Accept-encoding: exi' > > Carine, > > thank you for your input. > One piece of background that seems to be important here: > > In CoAP, we do not separately deal in media-types and content-codings, on the basis that few constrained nodes will have that level of flexibility. > Instead, we have a concept of content-format, which essentially is the cross-product of the two, i.e., a number given to each desirable combination: One content-format implies one media-type and one content-coding, as well as a specific setting of all media-type parameters. > > A CoAP Accept Option specifies an acceptable content-format, i.e. a combination of media-type, parameters, and content-coding. > The CoAP Content-Format Option specifies the media-type, parameters, and the content-coding of the representation enclosed. > (We confusingly continued calling that option "Content-Type" for a while; this was recently fixed.) > > So while what you are saying would be possible on the HTTP side (as Yusuke said, considering exi as a content-coding in the schema-informed case is controversial), on the CoAP side it's all multiplied out and therefore practically doesn't make a difference. The draft that the EXI Working Group reviewed had only negotiation techniques in terms of HTTP Content-Type, it seems. If you have some draft written in terms of Content-Format explaining the different cases (with EXI encoding, with textual XML or other encoding...) in terms of a single Content-Format concept, we may review and send comments. We understand that full flexibility with various HTTP headers and parameters may not be desirable in certain use cases (we also work on an EXI Profile for devices with limited resources) and for a number of these cases we abstained from defining all the details so that EXI users can choose what suits best their use cases (e.g. out-of-band schema negotiation.) -- Carine Bournez -+- W3C Europe From cabo@tzi.org Thu Dec 6 06:47:00 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2194621F86DD for ; Thu, 6 Dec 2012 06:47:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G35WIJjK51Sq for ; Thu, 6 Dec 2012 06:46:59 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 45C2521F86D5 for ; Thu, 6 Dec 2012 06:46:59 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id qB6Ekq4g019926 for ; Thu, 6 Dec 2012 15:46:52 +0100 (CET) Received: from [192.168.217.105] (p54892141.dip.t-dialin.net [84.137.33.65]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id B3A656FD; Thu, 6 Dec 2012 15:46:51 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: Date: Thu, 6 Dec 2012 15:46:50 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <79066ED0-E339-4BF6-9F8D-4C22AA2E0C39@tzi.org> References: <031DD135F9160444ABBE3B0C36CED618B36BC3@011-DB3MPN2-082.MGDPHG.emi.philips.com> To: Klaus Hartke X-Mailer: Apple Mail (2.1499) Cc: "core@ietf.org WG" Subject: Re: [core] #264: Content-Format of error responses X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 06 Dec 2012 14:47:00 -0000 On Dec 6, 2012, at 15:28, Klaus Hartke wrote: > Carsten Bormann wrote: >> #264: How about defining a "diagnostic payload" as that in an error >> message that has payload but no Content-Format? >=20 > There are three types of representations that a response can = transport: >=20 > * the representation of a resource state, > * the representation of the successful outcome of an action, and > * the representation of an error. HTTP also has the status line. We are trying to mirror that one here. This is not a representation. It does not have a media-type. > coap-12 makes a special case for error responses in that these > actually do not transport a representation like any other response > type does, but a special "diagnostic message" with no option for other > formats. The ticket is simply about removing that special case and > transport a representation like all other responses. Yes, I think we just discussed that, and came up with the solution in = the SVN now. > The question is how to specify the content format of that > representation. For other representations types, this is done by using > the Content-Format Option, where an absent option means that the > implementation needs out-of-band information to correctly interpret > the data. The format of representations of errors should do the same, > although I guess it would be acceptable here to default an absent > Content-Format Option to "text/coap-diagnostic-message" or something > like that. That would be doing exactly the same thing, except that it would treat = the status line information as a representation. Whether that is a good thing or not has been the bike-shedding behind = this ticket. I personally believe that it is a good thing to keep status-line type = information in the bowels of an implementation and not hand it up as a = representation. There won't be any HATEOAS links in a status-line. Gr=FC=DFe, Carsten From hartke@tzi.org Thu Dec 6 06:51:40 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA45021F8534 for ; Thu, 6 Dec 2012 06:51:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.96 X-Spam-Level: X-Spam-Status: No, score=-3.96 tagged_above=-999 required=5 tests=[AWL=1.667, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T5fX8kz9bypH for ; Thu, 6 Dec 2012 06:51:40 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id DC94E21F8530 for ; Thu, 6 Dec 2012 06:51:39 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id qB6EpWJ9022959 for ; Thu, 6 Dec 2012 15:51:32 +0100 (CET) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 69A81701 for ; Thu, 6 Dec 2012 15:51:32 +0100 (CET) Received: by mail-pa0-f44.google.com with SMTP id hz11so4326031pad.31 for ; Thu, 06 Dec 2012 06:51:30 -0800 (PST) Received: by 10.68.239.99 with SMTP id vr3mr6357016pbc.154.1354805490561; Thu, 06 Dec 2012 06:51:30 -0800 (PST) MIME-Version: 1.0 Received: by 10.68.75.75 with HTTP; Thu, 6 Dec 2012 06:51:10 -0800 (PST) In-Reply-To: <79066ED0-E339-4BF6-9F8D-4C22AA2E0C39@tzi.org> References: <031DD135F9160444ABBE3B0C36CED618B36BC3@011-DB3MPN2-082.MGDPHG.emi.philips.com> <79066ED0-E339-4BF6-9F8D-4C22AA2E0C39@tzi.org> From: Klaus Hartke Date: Thu, 6 Dec 2012 16:51:10 +0200 Message-ID: To: "core@ietf.org WG" Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [core] #264: Content-Format of error responses X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 06 Dec 2012 14:51:40 -0000 Carsten Bormann wrote: > I personally believe that it is a good thing to keep status-line type information in the bowels of an implementation and not hand it up as a representation. There won't be any HATEOAS links in a status-line. Decide, then, if you want a status line or an error representation. If status line, that's the diagnostic message we have right now in coap-12. If error representation, call it error representation and specify its media type. Klaus From cabo@tzi.org Thu Dec 6 06:59:59 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCF8021F8696 for ; Thu, 6 Dec 2012 06:59:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WtSxmRk58hFp for ; Thu, 6 Dec 2012 06:59:59 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id F06CC21F867C for ; Thu, 6 Dec 2012 06:59:58 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id qB6ExpZn025293 for ; Thu, 6 Dec 2012 15:59:52 +0100 (CET) Received: from [192.168.217.105] (p54892141.dip.t-dialin.net [84.137.33.65]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 84663710; Thu, 6 Dec 2012 15:59:51 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: Date: Thu, 6 Dec 2012 15:59:50 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <031DD135F9160444ABBE3B0C36CED618B36BC3@011-DB3MPN2-082.MGDPHG.emi.philips.com> <79066ED0-E339-4BF6-9F8D-4C22AA2E0C39@tzi.org> To: Klaus Hartke X-Mailer: Apple Mail (2.1499) Cc: "core@ietf.org WG" Subject: Re: [core] #264: Content-Format of error responses X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 06 Dec 2012 14:59:59 -0000 On Dec 6, 2012, at 15:51, Klaus Hartke wrote: > Carsten Bormann wrote: >> I personally believe that it is a good thing to keep status-line type = information in the bowels of an implementation and not hand it up as a = representation. There won't be any HATEOAS links in a status-line. >=20 > Decide, then, if you want a status line or an error representation. If > status line, that's the diagnostic message we have right now in > coap-12. If error representation, call it error representation and > specify its media type. The current text in the SVN contains one outcome of that decision. It solves #264 (enabling HATEOAS for errors), but keeps the = "status-line" type information for errors free of media-types. Actually, the server implementer can decide whether it wants to provide = a status-line type indication (most useful for 4.02 and friends) or a = real error representation (most useful for, say, 4.01, 4.03, ...), = simply by not including a Content-Format in the first case and including = a Content-Format option in the second case. It can't do both, but that will be rarely needed. =20 It also can't send an indeterminate Content-Format for an error = representation. Both limitations seem OK to me. The conceptual purity index is below 1.0, though, I admit. Gr=FC=DFe, Carsten From hartke@tzi.org Thu Dec 6 07:09:56 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EC6321F8703 for ; Thu, 6 Dec 2012 07:09:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.377 X-Spam-Level: X-Spam-Status: No, score=-4.377 tagged_above=-999 required=5 tests=[AWL=1.250, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VpYpuDWg4L0j for ; Thu, 6 Dec 2012 07:09:55 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 46EB121F86FF for ; Thu, 6 Dec 2012 07:09:55 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id qB6F9mPM000988 for ; Thu, 6 Dec 2012 16:09:48 +0100 (CET) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id A50DD729 for ; Thu, 6 Dec 2012 16:09:47 +0100 (CET) Received: by mail-pb0-f44.google.com with SMTP id uo1so4375514pbc.31 for ; Thu, 06 Dec 2012 07:09:45 -0800 (PST) Received: by 10.66.89.9 with SMTP id bk9mr4675784pab.67.1354806585824; Thu, 06 Dec 2012 07:09:45 -0800 (PST) MIME-Version: 1.0 Received: by 10.68.75.75 with HTTP; Thu, 6 Dec 2012 07:09:25 -0800 (PST) In-Reply-To: References: <031DD135F9160444ABBE3B0C36CED618B36BC3@011-DB3MPN2-082.MGDPHG.emi.philips.com> <79066ED0-E339-4BF6-9F8D-4C22AA2E0C39@tzi.org> From: Klaus Hartke Date: Thu, 6 Dec 2012 17:09:25 +0200 Message-ID: To: "core@ietf.org WG" Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [core] #264: Content-Format of error responses X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 06 Dec 2012 15:09:56 -0000 Carsten Bormann wrote: > Klaus Hartke wrote: >> Decide, then, if you want a status line or an error representation. If >> status line, that's the diagnostic message we have right now in >> coap-12. If error representation, call it error representation and >> specify its media type. > > The current text in the SVN contains one outcome of that decision. > It solves #264 (enabling HATEOAS for errors), but keeps the "status-line" type information for errors free of media-types. > Actually, the server implementer can decide So, basically, you couldn't decide and now there are both options in the draft, conflated into a "diagnostic payload" that is sometimes a status line and sometimes an error representation with a media type... I'm not sure if this is an improvement over coap-12. Klaus From cabo@tzi.org Thu Dec 6 07:18:52 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2B1921F86FD for ; Thu, 6 Dec 2012 07:18:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rvDVtK1Tj3R4 for ; Thu, 6 Dec 2012 07:18:52 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 1863821F86D8 for ; Thu, 6 Dec 2012 07:18:51 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id qB6FIj8h005806 for ; Thu, 6 Dec 2012 16:18:45 +0100 (CET) Received: from [192.168.217.105] (p54892141.dip.t-dialin.net [84.137.33.65]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id C7DFD736; Thu, 6 Dec 2012 16:18:44 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: Date: Thu, 6 Dec 2012 16:18:43 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <031DD135F9160444ABBE3B0C36CED618B36BC3@011-DB3MPN2-082.MGDPHG.emi.philips.com> <79066ED0-E339-4BF6-9F8D-4C22AA2E0C39@tzi.org> To: Klaus Hartke X-Mailer: Apple Mail (2.1499) Cc: "core@ietf.org WG" Subject: Re: [core] #264: Content-Format of error responses X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 06 Dec 2012 15:18:52 -0000 On Dec 6, 2012, at 16:09, Klaus Hartke wrote: > So, basically, you couldn't decide and now there are both options in > the draft, conflated into a "diagnostic payload" that is sometimes a > status line and sometimes an error representation with a media type... Well, that's not what the text in the SVN says. Please read it. If there is a need for editorial improvements, let's take that offline. Gr=FC=DFe, Carsten From trac+core@trac.tools.ietf.org Thu Dec 6 07:28:53 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C18FE21F8756 for ; Thu, 6 Dec 2012 07:28:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1st9KSEJJbn4 for ; Thu, 6 Dec 2012 07:28:53 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 3C6CF21F8697 for ; Thu, 6 Dec 2012 07:28:52 -0800 (PST) Received: from localhost ([127.0.0.1]:50723 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1TgdNQ-0000jZ-OT; Thu, 06 Dec 2012 16:28:40 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "core issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: zach@sensinode.com, cabo@tzi.org X-Trac-Project: core Date: Thu, 06 Dec 2012 15:28:40 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: /ticket/260#comment:1 Message-ID: <072.4dd828d9fca05dd48faf2f40631541a5@trac.tools.ietf.org> References: <057.29d11a717740777bc743bea492a89bf9@trac.tools.ietf.org> X-Trac-Ticket-ID: 260 In-Reply-To: <057.29d11a717740777bc743bea492a89bf9@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: zach@sensinode.com, cabo@tzi.org, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: Re: [core] #260: IANA Policy Review X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Reply-To: trac+core@trac.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2012 15:28:53 -0000 #260: IANA Policy Review Changes (by cabo@tzi.org): * status: new => closed * resolution: => fixed Comment: Fixed in [1099]: Close #262. Close #247. Close #260 (for now). -- --------------------------------+--------------------------------- Reporter: zach@sensinode.com | Owner: zach@sensinode.com Type: task | Status: closed Priority: minor | Milestone: post-WGLC-1 Component: coap | Version: coap-12 Severity: - | Resolution: fixed Keywords: | --------------------------------+--------------------------------- Ticket URL: core From trac+core@trac.tools.ietf.org Thu Dec 6 07:28:54 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E3F621F8697 for ; Thu, 6 Dec 2012 07:28:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KF0SETpuXbEE for ; Thu, 6 Dec 2012 07:28:53 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 97B4421F869C for ; Thu, 6 Dec 2012 07:28:53 -0800 (PST) Received: from localhost ([127.0.0.1]:50721 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1TgdNQ-0000gV-KC; Thu, 06 Dec 2012 16:28:40 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "core issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-core-coap@tools.ietf.org, cabo@tzi.org X-Trac-Project: core Date: Thu, 06 Dec 2012 15:28:40 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: /ticket/262#comment:1 Message-ID: <066.6ca114b03272bfcfda723037dc882842@trac.tools.ietf.org> References: <051.722e5df3abf1190252374b63910bdfae@trac.tools.ietf.org> X-Trac-Ticket-ID: 262 In-Reply-To: <051.722e5df3abf1190252374b63910bdfae@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-core-coap@tools.ietf.org, cabo@tzi.org, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: brian@skyfoundry.com, cabo@tzi.org, hartke@tzi.org, zach@sensinode.com Resent-Message-Id: <20121206152853.97B4421F869C@ietfa.amsl.com> Resent-Date: Thu, 6 Dec 2012 07:28:53 -0800 (PST) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: Re: [core] #262: Split out IPsec details into a separate draft X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Reply-To: trac+core@trac.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2012 15:28:54 -0000 #262: Split out IPsec details into a separate draft Changes (by cabo@tzi.org): * status: new => closed * resolution: => fixed Comment: Fixed in [1099]: Close #262. Close #247. Close #260 (for now). -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core- cabo@tzi.org | coap@tools.ietf.org Type: other | Status: closed technical | Milestone: post-WGLC-1 Priority: major | Version: coap-12 Component: coap | Resolution: fixed Severity: In WG Last | Call | Keywords: | -------------------------+------------------------------------------------- Ticket URL: core From trac+core@trac.tools.ietf.org Thu Dec 6 07:28:56 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A206821F879E for ; Thu, 6 Dec 2012 07:28:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mwkBwuLb5bYq for ; Thu, 6 Dec 2012 07:28:56 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 1C64821F8796 for ; Thu, 6 Dec 2012 07:28:56 -0800 (PST) Received: from localhost ([127.0.0.1]:50722 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1TgdNQ-0000im-N9; Thu, 06 Dec 2012 16:28:40 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "core issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-core-coap@tools.ietf.org, esko.dijk@philips.com, zach@sensinode.com, cabo@tzi.org X-Trac-Project: core Date: Thu, 06 Dec 2012 15:28:40 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: /ticket/247#comment:6 Message-ID: <075.d6de0a60446cb7072afd7f16d5f1f131@trac.tools.ietf.org> References: <060.165feff053c11cfa0d65de452eb53ed9@trac.tools.ietf.org> X-Trac-Ticket-ID: 247 In-Reply-To: <060.165feff053c11cfa0d65de452eb53ed9@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-core-coap@tools.ietf.org, esko.dijk@philips.com, zach@sensinode.com, cabo@tzi.org, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: brian@skyfoundry.com, cabo@tzi.org, hartke@tzi.org, zach@sensinode.com Resent-Message-Id: <20121206152856.1C64821F8796@ietfa.amsl.com> Resent-Date: Thu, 6 Dec 2012 07:28:56 -0800 (PST) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: Re: [core] #247: Scalability questions IANA review for IPv6/IPv4 multicast address request X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Reply-To: trac+core@trac.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2012 15:28:56 -0000 #247: Scalability questions IANA review for IPv6/IPv4 multicast address request Changes (by cabo@tzi.org): * status: new => closed * resolution: => fixed Comment: Fixed in [1099]: Close #262. Close #247. Close #260 (for now). -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core- esko.dijk@philips.com | coap@tools.ietf.org Type: protocol | Status: closed defect | Milestone: post-WGLC-1 Priority: minor | Version: Component: coap | Resolution: fixed Severity: - | Keywords: | -------------------------+------------------------------------------------- Ticket URL: core From trac+core@trac.tools.ietf.org Thu Dec 6 07:45:05 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5ED6221F878D for ; Thu, 6 Dec 2012 07:45:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MORee0o-0-X5 for ; Thu, 6 Dec 2012 07:45:05 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id C782221F878C for ; Thu, 6 Dec 2012 07:45:04 -0800 (PST) Received: from localhost ([127.0.0.1]:51717 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1Tgdd8-0003RQ-0d; Thu, 06 Dec 2012 16:44:54 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "core issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: zach@sensinode.com, cabo@tzi.org X-Trac-Project: core Date: Thu, 06 Dec 2012 15:44:53 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: /ticket/261#comment:1 Message-ID: <072.ee5a37b9a743a75319cb82a7dd7d4251@trac.tools.ietf.org> References: <057.11b9a385ad96122a62f1e35a84bb4cd5@trac.tools.ietf.org> X-Trac-Ticket-ID: 261 In-Reply-To: <057.11b9a385ad96122a62f1e35a84bb4cd5@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: zach@sensinode.com, cabo@tzi.org, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: Re: [core] #261: SHOULD Review X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Reply-To: trac+core@trac.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2012 15:45:05 -0000 #261: SHOULD Review Changes (by cabo@tzi.org): * status: new => closed * resolution: => fixed Comment: Fixed in [1100]: Close #261 (for now). -- --------------------------------+--------------------------------- Reporter: zach@sensinode.com | Owner: zach@sensinode.com Type: task | Status: closed Priority: minor | Milestone: post-WGLC-1 Component: coap | Version: coap-12 Severity: - | Resolution: fixed Keywords: | --------------------------------+--------------------------------- Ticket URL: core From cabo@tzi.org Thu Dec 6 08:45:00 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30B2121F873C for ; Thu, 6 Dec 2012 08:45:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gYqWEBE6nuil for ; Thu, 6 Dec 2012 08:44:59 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 2611421F86EA for ; Thu, 6 Dec 2012 08:44:58 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id qB6GinRb021872 for ; Thu, 6 Dec 2012 17:44:50 +0100 (CET) Received: from [192.168.217.105] (p54892141.dip.t-dialin.net [84.137.33.65]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id D6A377D9; Thu, 6 Dec 2012 17:44:48 +0100 (CET) From: Carsten Bormann Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Thu, 6 Dec 2012 17:44:47 +0100 To: "core@ietf.org WG" Message-Id: <3EA14C54-BC7F-4606-BB06-5307C8BAE9AF@tzi.org> Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) Subject: [core] Combining Proxy-Uri with Uri-* X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 06 Dec 2012 16:45:00 -0000 One comment that we never properly ticketized was this from Cullen = Jennings: > When I am using a proxy and sending it a COAP URL, I find it totally = lame that I have to send it in a totally different option than if I was = not using a proxy. I think we should change this unless there is some = really good reasons for doing it. Even when using a HTTP URI, I'd rather = just add a scheme than use proxy-URI. [http://www.ietf.org/mail-archive/web/core/current/msg03072.html] I completely agree that "lame" is the correct technical term here. I have checked in a proposed solution (added at the end of 5.10.2 = Proxy-Uri): As a special case to simplify some proxy clients, the absolute-URI can be constructed from the Uri-* options. When the Proxy-Uri Option only contains a scheme name followed by a colon, the absolute-URI is constructed as follows: A CoAP URI is constructed from the Uri-* options as defined in Section 6.5. In the resulting URI, the initial scheme and the following colon are then replaced by the content of the Proxy-Uri Option. Those who actually do forward proxies: would that work for you? (Variants of this have been discussed on many hallways. Going the whole = way and defining the interactions of any subset of the Uri-* options = with Proxy-Uri is leading to lots of unneeded complexity. This seems to = be the best way to keep clients simple. Very little additional work for = proxies.) Gr=FC=DFe, Carsten From cabo@tzi.org Thu Dec 6 09:05:00 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9798721F873C for ; Thu, 6 Dec 2012 09:04:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3yi5bkjic90T for ; Thu, 6 Dec 2012 09:04:59 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 195CF21F876B for ; Thu, 6 Dec 2012 09:04:57 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id qB6H4nxh001716 for ; Thu, 6 Dec 2012 18:04:50 +0100 (CET) Received: from [192.168.217.105] (p54892141.dip.t-dialin.net [84.137.33.65]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 9F90E7EF; Thu, 6 Dec 2012 18:04:49 +0100 (CET) From: Carsten Bormann Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Thu, 6 Dec 2012 18:04:47 +0100 To: "core@ietf.org WG" Message-Id: <9A9AE80A-37C2-493F-ADDF-B36055F2A010@tzi.org> Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) Subject: [core] Precedence of errors (4.12 Precondition Failed) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 06 Dec 2012 17:05:00 -0000 HTTP says about If-Match/If-None-Match: If the request would, without the If-Match header field, result in anything other than a 2xx or 412 status, then the If-Match header MUST be ignored. ... If the request would, without the If-None-Match header field, result in anything other than a 2xx or 304 status, then the If-None-Match header MUST be ignored. So far, we have mirrored that. But nobody seems to know why. In constrained implementations, this may be a significant burden. Cullen commented earlier: > The 2nd from last paragraph suggest all other error take precedence = over 4.12. This is very hard to implement in some cases. I would remove = this. Many systems will want to check and reject based on pre-conditions = before doing all the other things that might cause an error. [http://www.ietf.org/mail-archive/web/core/current/msg03072.html] So I have relaxed this into a MAY. If the request would, without the conditional request options, result in anything other than a 2.xx or 4.12 response code, then any conditional request options MAY be ignored. I'm aware that this impacts any attempt to do a fully compliant HTTP = proxy. Comments appreciated. Gr=FC=DFe, Carsten From trac+core@trac.tools.ietf.org Thu Dec 6 09:15:33 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B14B821F86A6 for ; Thu, 6 Dec 2012 09:15:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LbCGPNyXrnK9 for ; Thu, 6 Dec 2012 09:15:33 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 2995721F869C for ; Thu, 6 Dec 2012 09:15:33 -0800 (PST) Received: from localhost ([127.0.0.1]:58616 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1Tgf2d-000814-5t; Thu, 06 Dec 2012 18:15:19 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "core issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: zach@sensinode.com, cabo@tzi.org X-Trac-Project: core Date: Thu, 06 Dec 2012 17:15:16 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: /ticket/255#comment:2 Message-ID: <072.2a70bed72563131fa2d435816fba64e8@trac.tools.ietf.org> References: <057.2ba8550a3f0f2269f9c67df979775e71@trac.tools.ietf.org> X-Trac-Ticket-ID: 255 In-Reply-To: <057.2ba8550a3f0f2269f9c67df979775e71@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: zach@sensinode.com, cabo@tzi.org, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: core@ietf.org Subject: Re: [core] #255: Authority Name issues with SNI and X.509 certificate X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Reply-To: trac+core@trac.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2012 17:15:33 -0000 #255: Authority Name issues with SNI and X.509 certificate Changes (by cabo@tzi.org): * status: new => closed * resolution: => fixed Comment: Fixed in [1107]: Clarify the intent of 9.1.3.3. This isn't solving all the problems listed in #255, but should suffice to close #255 for now. The certificate part of this is a good candidate to move it into a separate draft. -- --------------------------------+--------------------------------- Reporter: zach@sensinode.com | Owner: zach@sensinode.com Type: other technical | Status: closed Priority: minor | Milestone: post-WGLC-1 Component: coap | Version: coap-12 Severity: In WG Last Call | Resolution: fixed Keywords: | --------------------------------+--------------------------------- Ticket URL: core From trac+core@trac.tools.ietf.org Thu Dec 6 09:38:57 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4280421F87C1 for ; Thu, 6 Dec 2012 09:38:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tXmA+pus-NKL for ; Thu, 6 Dec 2012 09:38:56 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id A05AA21F8799 for ; Thu, 6 Dec 2012 09:38:55 -0800 (PST) Received: from localhost ([127.0.0.1]:60142 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1TgfPF-0002CP-4M; Thu, 06 Dec 2012 18:38:41 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "core issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-core-coap@tools.ietf.org, hartke@tzi.org, cabo@tzi.org X-Trac-Project: core Date: Thu, 06 Dec 2012 17:38:41 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: /ticket/263#comment:2 Message-ID: <075.5d34d25bcd3d22f090d1a3b7c4f5995f@trac.tools.ietf.org> References: <060.b950e43a348efde2c0bfd3eb012039d3@trac.tools.ietf.org> X-Trac-Ticket-ID: 263 In-Reply-To: <060.b950e43a348efde2c0bfd3eb012039d3@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-core-coap@tools.ietf.org, hartke@tzi.org, cabo@tzi.org, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: brian@skyfoundry.com, cabo@tzi.org, hartke@tzi.org, zach@sensinode.com Resent-Message-Id: <20121206173856.A05AA21F8799@ietfa.amsl.com> Resent-Date: Thu, 6 Dec 2012 09:38:55 -0800 (PST) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: Re: [core] #263: Proxied responses to multicast request can't be distinguished by client X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Reply-To: trac+core@trac.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2012 17:38:57 -0000 #263: Proxied responses to multicast request can't be distinguished by client Changes (by cabo@tzi.org): * status: new => closed * resolution: => fixed Comment: Fixed in [1108]: Fix #257. Close #263 by referring to coap-misc. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core- esko.dijk@philips.com | coap@tools.ietf.org Type: protocol | Status: closed defect | Milestone: post-WGLC-1 Priority: minor | Version: coap-12 Component: coap | Resolution: fixed Severity: - | Keywords: | -------------------------+------------------------------------------------- Ticket URL: core From trac+core@trac.tools.ietf.org Thu Dec 6 09:39:01 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9149321F87D8 for ; Thu, 6 Dec 2012 09:39:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JXTUhTzY+Flr for ; Thu, 6 Dec 2012 09:39:01 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id F186221F87D7 for ; Thu, 6 Dec 2012 09:39:00 -0800 (PST) Received: from localhost ([127.0.0.1]:60143 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1TgfPF-0002E0-6W; Thu, 06 Dec 2012 18:38:42 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "core issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-core-coap@tools.ietf.org, esko.dijk@philips.com, cabo@tzi.org X-Trac-Project: core Date: Thu, 06 Dec 2012 17:38:41 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: /ticket/257#comment:3 Message-ID: <066.6ed682fb7a6ce5297b4ca731882e5a61@trac.tools.ietf.org> References: <051.bfa8620fef2432adf8e7cc19532dcb39@trac.tools.ietf.org> X-Trac-Ticket-ID: 257 In-Reply-To: <051.bfa8620fef2432adf8e7cc19532dcb39@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-core-coap@tools.ietf.org, esko.dijk@philips.com, cabo@tzi.org, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: brian@skyfoundry.com, cabo@tzi.org, hartke@tzi.org, zach@sensinode.com Resent-Message-Id: <20121206173900.F186221F87D7@ietfa.amsl.com> Resent-Date: Thu, 6 Dec 2012 09:39:00 -0800 (PST) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: Re: [core] #257: URI references and multicast requests X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Reply-To: trac+core@trac.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2012 17:39:01 -0000 #257: URI references and multicast requests Changes (by cabo@tzi.org): * status: new => closed * resolution: => fixed Comment: Fixed in [1108]: Fix #257. Close #263 by referring to coap-misc. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core- cabo@tzi.org | coap@tools.ietf.org Type: other | Status: closed technical | Milestone: post-WGLC-1 Priority: minor | Version: coap-11 Component: coap | Resolution: fixed Severity: In WG Last | Call | Keywords: | -------------------------+------------------------------------------------- Ticket URL: core From trac+core@trac.tools.ietf.org Thu Dec 6 09:52:27 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECBF321F86FE for ; Thu, 6 Dec 2012 09:52:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CkoU0iLMJulZ for ; Thu, 6 Dec 2012 09:52:27 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 614D621F86B3 for ; Thu, 6 Dec 2012 09:52:27 -0800 (PST) Received: from localhost ([127.0.0.1]:33065 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1TgfcD-0002OS-9C; Thu, 06 Dec 2012 18:52:05 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "core issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-core-groupcomm@tools.ietf.org, cabo@tzi.org X-Trac-Project: core Date: Thu, 06 Dec 2012 17:52:05 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/252#comment:1 Message-ID: <075.b2f6b4bbad73e749c32463142055f312@trac.tools.ietf.org> References: <060.21265d28244400dba1ada3082dcb036a@trac.tools.ietf.org> X-Trac-Ticket-ID: 252 In-Reply-To: <060.21265d28244400dba1ada3082dcb036a@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-core-groupcomm@tools.ietf.org, cabo@tzi.org, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: akbar.rahman@interdigital.com, esko.dijk@philips.com Resent-Message-Id: <20121206175227.614D621F86B3@ietfa.amsl.com> Resent-Date: Thu, 6 Dec 2012 09:52:27 -0800 (PST) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: Re: [core] #252: Conflicting security requirements in groupcomm/core-coap X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Reply-To: trac+core@trac.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2012 17:52:28 -0000 #252: Conflicting security requirements in groupcomm/core-coap Comment (by cabo@tzi.org): There is some additional wording in coap-13, svn [1100]. This does not solve the problem, but describes what can be done at this point. Leaving this open so additional work can be done in groupcomm. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core- esko.dijk@philips.com | groupcomm@tools.ietf.org Type: protocol | Status: new defect | Milestone: Priority: major | Version: Component: groupcomm | Resolution: Severity: Active WG | Document | Keywords: | -------------------------+------------------------------------------------- Ticket URL: core From zach@sensinode.com Thu Dec 6 11:06:47 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1F2B21F861E for ; Thu, 6 Dec 2012 11:06:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pUNHm2PIjSGU for ; Thu, 6 Dec 2012 11:06:46 -0800 (PST) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id C922921F860D for ; Thu, 6 Dec 2012 11:06:45 -0800 (PST) Received: from [192.168.1.104] (188-67-91-55.bb.dnainternet.fi [188.67.91.55]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.8/8.13.4) with ESMTP id qB6J6fTs001177; Thu, 6 Dec 2012 21:06:41 +0200 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Zach Shelby In-Reply-To: <3EA14C54-BC7F-4606-BB06-5307C8BAE9AF@tzi.org> Date: Thu, 6 Dec 2012 21:07:00 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <7E04A71A-BCB9-46F7-AED8-5C50012344C2@sensinode.com> References: <3EA14C54-BC7F-4606-BB06-5307C8BAE9AF@tzi.org> To: Carsten Bormann X-Mailer: Apple Mail (2.1084) Cc: "core@ietf.org WG" Subject: Re: [core] Combining Proxy-Uri with Uri-* X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 06 Dec 2012 19:06:47 -0000 On Dec 6, 2012, at 6:44 PM, Carsten Bormann wrote: > One comment that we never properly ticketized was this from Cullen = Jennings: >=20 >> When I am using a proxy and sending it a COAP URL, I find it totally = lame that I have to send it in a totally different option than if I was = not using a proxy. I think we should change this unless there is some = really good reasons for doing it. Even when using a HTTP URI, I'd rather = just add a scheme than use proxy-URI. >=20 > [http://www.ietf.org/mail-archive/web/core/current/msg03072.html] >=20 > I completely agree that "lame" is the correct technical term here. >=20 > I have checked in a proposed solution (added at the end of 5.10.2 = Proxy-Uri): >=20 > As a special case to simplify some proxy clients, the absolute-URI > can be constructed from the Uri-* options. When the Proxy-Uri = Option > only contains a scheme name followed by a colon, the absolute-URI is > constructed as follows: A CoAP URI is constructed from the Uri-* > options as defined in Section 6.5. In the resulting URI, the = initial > scheme and the following colon are then replaced by the content of > the Proxy-Uri Option. >=20 > Those who actually do forward proxies: would that work for you? I have no problems with making this less "lame", but we can't have = several ways of doing this. Let's do this in only one way (your new = proposed way): Rename Proxy-Uri to Proxy-Scheme, which contains the scheme of the = request URI. The Uri-* options are then always used to encode the rest = of the request URI.=20 Zach=20 >=20 > (Variants of this have been discussed on many hallways. Going the = whole way and defining the interactions of any subset of the Uri-* = options with Proxy-Uri is leading to lots of unneeded complexity. This = seems to be the best way to keep clients simple. Very little additional = work for proxies.) >=20 > Gr=FC=DFe, Carsten >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://www.sensinode.com @SensinodeIoT Mobile: +358 40 7796297 Twitter: @zach_shelby LinkedIn: http://fi.linkedin.com/in/zachshelby 6LoWPAN Book: http://6lowpan.net From trac+core@trac.tools.ietf.org Thu Dec 6 11:07:24 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5D4421F875B for ; Thu, 6 Dec 2012 11:07:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qX5ZoW6qkO4a for ; Thu, 6 Dec 2012 11:07:24 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 66BF621F861E for ; Thu, 6 Dec 2012 11:07:23 -0800 (PST) Received: from localhost ([127.0.0.1]:38633 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1Tggmp-0001TL-Fq; Thu, 06 Dec 2012 20:07:07 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "core issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-core-coap@tools.ietf.org, cabo@tzi.org X-Trac-Project: core Date: Thu, 06 Dec 2012 19:07:07 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: /ticket/265#comment:1 Message-ID: <066.154faa35572643c1a7eeea17b1c20dac@trac.tools.ietf.org> References: <051.1861a7035d5cf50ce2b561301512103a@trac.tools.ietf.org> X-Trac-Ticket-ID: 265 In-Reply-To: <051.1861a7035d5cf50ce2b561301512103a@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-core-coap@tools.ietf.org, cabo@tzi.org, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: brian@skyfoundry.com, cabo@tzi.org, hartke@tzi.org, zach@sensinode.com Resent-Message-Id: <20121206190724.66BF621F861E@ietfa.amsl.com> Resent-Date: Thu, 6 Dec 2012 11:07:23 -0800 (PST) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: Re: [core] #265: ETag Option in responses other than 2.05 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Reply-To: trac+core@trac.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2012 19:07:25 -0000 #265: ETag Option in responses other than 2.05 Changes (by cabo@tzi.org): * status: new => closed * resolution: => fixed Comment: Fixed in [1109]: Close #265 -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core- cabo@tzi.org | coap@tools.ietf.org Type: other | Status: closed technical | Milestone: post-WGLC-1 Priority: major | Version: coap-12 Component: coap | Resolution: fixed Severity: In WG Last | Call | Keywords: | -------------------------+------------------------------------------------- Ticket URL: core From internet-drafts@ietf.org Thu Dec 6 13:01:34 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1712321F8919; Thu, 6 Dec 2012 13:01:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.529 X-Spam-Level: X-Spam-Status: No, score=-102.529 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X138dLrQxmYg; Thu, 6 Dec 2012 13:01:33 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B08521F896C; Thu, 6 Dec 2012 13:01:33 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.36 Message-ID: <20121206210133.21872.94567.idtracker@ietfa.amsl.com> Date: Thu, 06 Dec 2012 13:01:33 -0800 Cc: core@ietf.org Subject: [core] I-D Action: draft-ietf-core-coap-13.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 06 Dec 2012 21:01:34 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Constrained RESTful Environments Working = Group of the IETF. Title : Constrained Application Protocol (CoAP) Author(s) : Zach Shelby Klaus Hartke Carsten Bormann Brian Frank Filename : draft-ietf-core-coap-13.txt Pages : 109 Date : 2012-12-06 Abstract: The Constrained Application Protocol (CoAP) is a specialized web transfer protocol for use with constrained nodes and constrained (e.g., low-power, lossy) networks. The nodes often have 8-bit microcontrollers with small amounts of ROM and RAM, while constrained networks such as 6LoWPAN often have high packet error rates and a typical throughput of 10s of kbit/s. The protocol is designed for machine-to-machine (M2M) applications such as smart energy and building automation. CoAP provides a request/response interaction model between application endpoints, supports built-in discovery of services and resources, and includes key concepts of the Web such as URIs and Internet media types. CoAP easily interfaces with HTTP for integration with the Web while meeting specialized requirements such as multicast support, very low overhead and simplicity for constrained environments. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-coap There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-core-coap-13 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-core-coap-13 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From cabo@tzi.org Thu Dec 6 13:12:23 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9577821F8853 for ; Thu, 6 Dec 2012 13:12:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v7Pn-u6ZVSCX for ; Thu, 6 Dec 2012 13:12:22 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 48B6C21F882D for ; Thu, 6 Dec 2012 13:12:21 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id qB6LCFFr015290 for ; Thu, 6 Dec 2012 22:12:15 +0100 (CET) Received: from [192.168.217.105] (p54892141.dip.t-dialin.net [84.137.33.65]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 9D55589C; Thu, 6 Dec 2012 22:12:15 +0100 (CET) From: Carsten Bormann Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Thu, 6 Dec 2012 22:12:14 +0100 To: "core@ietf.org WG" Message-Id: Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) Subject: [core] coap-13 (the Sinterklaas edition) ready for consumption X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 06 Dec 2012 21:12:23 -0000 As you have may seen from the many tracker e-mails, the authors took the = feedback we got from last week's second ETSI CoAP plugtest and finished = draft-ietf-core-coap-13, which can be found at: http://tools.ietf.org/html/draft-ietf-core-coap-13 View the differences from -12 at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-core-coap-13 This has the new option encoding, as well as numerous minimal changes = that attempt to cover the remaining comments and the ETSI feedback = without going overboard. We believe this now finishes the phase where we incorporated the = numerous comments from the first WGLC. We could always do more editorial work or add more nice-to-haves, but = there is a law of diminishing returns. We promised to do the second WGLC of core-coap in December, and this is = the input to that. Since I'm a co-author, I'll wait for my esteemed co-chair to issue the = WGLC. Gr=FC=DFe, Carsten From andrewmcgr@gmail.com Fri Dec 7 01:15:20 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B968321F87D9 for ; Fri, 7 Dec 2012 01:15:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DgEDbuEszMwk for ; Fri, 7 Dec 2012 01:15:20 -0800 (PST) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3C7D921F87D1 for ; Fri, 7 Dec 2012 01:15:20 -0800 (PST) Received: by mail-pa0-f44.google.com with SMTP id hz11so331588pad.31 for ; Fri, 07 Dec 2012 01:15:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:date:message-id :cc:to:mime-version:x-mailer; bh=YNtWmBVPt/jLXXxYeEcmGlXdYBQ4FuBd4izMPmjkjmM=; b=q3rc0NfLKkRXZQfLQoKWd5MQuec5M51A4Qa4/iNfVZWDwDLxd7pw+BQlw7drdY4B6a ZKVL90AlGYrCzYPmZKeyOqLD+z2Mh93dnBmywlZn4aqtKK7SAVvnAHgRBbu2PBnQsj++ LGiS2F8hTQJ/Q9cXtNtjp4siF9Jbqx+JJnpQ6Cgq5eGefVknhl1LxUK92YKkjS5OI661 QV68fbywMG+8BcL2nB5nU/oGwoXOFAMagUYu6vDGDV/hl7k8y7xtU9mAt1nRC8Gm4W59 9X6Oc5wRAN1QLaK8dmKYE9gAEuSnh685QJZV27+sav50G1pD8DScCAXUI8U48zC+IekU cvVA== Received: by 10.68.239.9 with SMTP id vo9mr14167319pbc.83.1354871719895; Fri, 07 Dec 2012 01:15:19 -0800 (PST) Received: from ?IPv6:2406:e000:63ad:1:79a4:85fe:3fa5:e625? ([2406:e000:63ad:1:79a4:85fe:3fa5:e625]) by mx.google.com with ESMTPS id uk9sm6376513pbc.63.2012.12.07.01.15.17 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 07 Dec 2012 01:15:19 -0800 (PST) From: Andrew McGregor Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 7 Dec 2012 22:15:11 +1300 Message-Id: <41DAE62B-4E16-413A-B3ED-A7ADF03DB973@gmail.com> To: "core@ietf.org WG" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) Subject: [core] WGLC for draft-ietf-core-coap-13 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 07 Dec 2012 09:15:20 -0000 This is a last call for comments from the working group on = draft-ietf-core-coap-13, which can be found at: http://tools.ietf.org/html/draft-ietf-core-coap-13 View the differences from -12 at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-core-coap-13 We believe this now completes the incorporation of the numerous comments = from the first WGLC. Last call will close 23:59 UTC on Friday, 21 December 2012. Thanks, Andrew and Carsten= From tho@koanlogic.com Fri Dec 7 02:49:16 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FC3F21F8742 for ; Fri, 7 Dec 2012 02:49:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nQl2pc0FQM7t for ; Fri, 7 Dec 2012 02:49:16 -0800 (PST) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id A284521F8695 for ; Fri, 7 Dec 2012 02:49:15 -0800 (PST) Received: by mail-lb0-f172.google.com with SMTP id y2so336968lbk.31 for ; Fri, 07 Dec 2012 02:49:14 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:content-type:x-gm-message-state; bh=IKOCvlbSIr9uiNEX8WJTdgLDg23NXp6KmHU/HHQYUzI=; b=jedWu1KOkGdigq67zl4bXTH3iNhc1YauSe1SJPqlu/9TVV+lWx7VrDqInoennnCGQM mmV5OEHJUvsu8ekXJnNx5jwnMSJizbn3D49l/F3CV4Madf3iKeJ/xjxFzQKXpT3c67QM eZLz+P1V8pGiFIBpKdlT2EUZO3grDA1uiXevaVO/+0nEZ7jjV2MdGPBt+6FabdpFt3dB nVZBM1EpB+Mf8R8FEJBIivyPF2D5IrUDPARs+goCgtMbPB5v4TltHSdZrBBXMeENnE/u 1uyJdyQef6fLXbrErxSS/7Deksrvcmf7/tU8PKZN2FKcDEV9SK82jhaMFA7bHeC5OyjS xC8A== MIME-Version: 1.0 Received: by 10.152.46.161 with SMTP id w1mr4996765lam.27.1354877354407; Fri, 07 Dec 2012 02:49:14 -0800 (PST) Received: by 10.114.29.10 with HTTP; Fri, 7 Dec 2012 02:49:14 -0800 (PST) X-Originating-IP: [81.134.152.4] In-Reply-To: <072.2a70bed72563131fa2d435816fba64e8@trac.tools.ietf.org> References: <057.2ba8550a3f0f2269f9c67df979775e71@trac.tools.ietf.org> <072.2a70bed72563131fa2d435816fba64e8@trac.tools.ietf.org> Date: Fri, 7 Dec 2012 10:49:14 +0000 Message-ID: From: Thomas Fossati To: core@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQmV8QiMlY9EymQ8H+Yj8d6XCxB4YLH6AQmwzcSnY2U/UdeTWtatXZKz2d5gQXwuo213C2Vx Subject: Re: [core] #255: Authority Name issues with SNI and X.509 certificate X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 07 Dec 2012 10:49:16 -0000 On Thu, Dec 6, 2012 at 5:15 PM, core issue tracker wrote: > Clarify the intent of 9.1.3.3. > This isn't solving all the problems listed in #255, but should suffice > to close #255 for now. > The certificate part of this is a good candidate to move it into a > separate draft. Quick question: how is the suggested EUI64 going to fit into the "host" URI production ? From zach@sensinode.com Fri Dec 7 03:10:52 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5134E21F892A for ; Fri, 7 Dec 2012 03:10:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uCMf0TSFoJPq for ; Fri, 7 Dec 2012 03:10:51 -0800 (PST) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id 5622221F8635 for ; Fri, 7 Dec 2012 03:10:50 -0800 (PST) Received: from [10.128.9.122] (line-21396.dyn.kponet.fi [213.145.192.6]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.8/8.13.4) with ESMTP id qB7BAlHp023341; Fri, 7 Dec 2012 13:10:48 +0200 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Zach Shelby In-Reply-To: Date: Fri, 7 Dec 2012 13:11:07 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <4034ECC2-DB03-4A90-96F2-852AFEC120DF@sensinode.com> References: <057.2ba8550a3f0f2269f9c67df979775e71@trac.tools.ietf.org> <072.2a70bed72563131fa2d435816fba64e8@trac.tools.ietf.org> To: Thomas Fossati X-Mailer: Apple Mail (2.1084) Cc: core@ietf.org Subject: Re: [core] #255: Authority Name issues with SNI and X.509 certificate X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 07 Dec 2012 11:10:52 -0000 Hi, On Dec 7, 2012, at 12:49 PM, Thomas Fossati wrote: > On Thu, Dec 6, 2012 at 5:15 PM, core issue tracker > wrote: >> Clarify the intent of 9.1.3.3. >> This isn't solving all the problems listed in #255, but should = suffice >> to close #255 for now. >> The certificate part of this is a good candidate to move it into a >> separate draft. >=20 > Quick question: how is the suggested EUI64 going to fit into the > "host" URI production ? That is not the intention.=20 Instead, what the text is (trying) to say is that constrained endpoints = in CoRE often times don't have a DNS based host name (which would be the = host URI production) to use in a Certificate, and in those cases use a = stable application layer identifier such as an EUI64 as the authority = name in a certificate. Such an identifier is not part of the URI = production. Then it goes on to say that this identifier is included in = the Subject CN field of the X.509 and how it is used for verification.=20= We will still need do more editorial work on that section.=20 Zach=20 --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://www.sensinode.com @SensinodeIoT Mobile: +358 40 7796297 Twitter: @zach_shelby LinkedIn: http://fi.linkedin.com/in/zachshelby 6LoWPAN Book: http://6lowpan.net From cabo@tzi.org Fri Dec 7 03:32:00 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A105C21F853A for ; Fri, 7 Dec 2012 03:32:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NDgemlGgoHwq for ; Fri, 7 Dec 2012 03:32:00 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 9A8F221F8534 for ; Fri, 7 Dec 2012 03:31:59 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id qB7BVoOb006977; Fri, 7 Dec 2012 12:31:50 +0100 (CET) Received: from [10.0.1.2] (reingewinn.informatik.uni-bremen.de [134.102.218.123]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 20634B37; Fri, 7 Dec 2012 12:31:50 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: <4034ECC2-DB03-4A90-96F2-852AFEC120DF@sensinode.com> Date: Fri, 7 Dec 2012 12:31:49 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <2EED6C7B-2959-4D76-9B0C-D9F4CFDCE3DE@tzi.org> References: <057.2ba8550a3f0f2269f9c67df979775e71@trac.tools.ietf.org> <072.2a70bed72563131fa2d435816fba64e8@trac.tools.ietf.org> <4034ECC2-DB03-4A90-96F2-852AFEC120DF@sensinode.com> To: Zach Shelby X-Mailer: Apple Mail (2.1499) Cc: core@ietf.org Subject: Re: [core] #255: Authority Name issues with SNI and X.509 certificate X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 07 Dec 2012 11:32:00 -0000 On Dec 7, 2012, at 12:11, Zach Shelby wrote: > We will still need do more editorial work on that section.=20 Indeed. I wonder whether we should be doing what I wrote in the commit = comment: Extract the cert-based section and develop it on a separate axis. =20 It will be more unstable than the base document until we have found all = the right places to connect to and caused any necessary updates. To Thomas' question: If you need to fit it into DNS, one way to put an = EUI-64 into a DNS context is to do, say, a base32 encode of the = identifier and use it as a DNS label. In a DNS-based system, it's up to the provisioning mechanisms to come up = with these names, so there may not even be a need to standardize such a = mapping. For more general applications, draft-farrell-decade-ni is a good source = of (URI-based) names (too bad that it will be stuck in the RFC editor = queue for another year or so). It is the lack of clarity about the range of provisioning mechanisms = that cause us most of the trouble here. Reminds me that I still have a SOLACE draft to write... Gr=FC=DFe, Carsten From tho@koanlogic.com Fri Dec 7 04:27:42 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D99DF21F8613 for ; Fri, 7 Dec 2012 04:27:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id icl8-hDFSuTx for ; Fri, 7 Dec 2012 04:27:42 -0800 (PST) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9CCB421F85E3 for ; Fri, 7 Dec 2012 04:27:41 -0800 (PST) Received: by mail-lb0-f172.google.com with SMTP id y2so412805lbk.31 for ; Fri, 07 Dec 2012 04:27:40 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=XmyLSf0kJVw+2UzCnN38rtQWgI4Cmqe47j1eEiw6fek=; b=OIy45f9bV2hNetzM+Gd/B7foGHP4xU3XTV+bagowrzcz/4QI/fEgddlAbcKOiETy1X u8pmT/0aoyVmXVnjXUSMIWqEhBu9GQG+e2gdGS71zHmUYJ3TorVwkLfz04f3vMbZPEpr cnVp8T2364N6ijhkmzrmYsUVuk1dGrf7XsLniREt9P2vMgMJ33WmfrD0niWD0pP3zJ+I iFvFfxRxazEsM60G9MHIEIF75U08qVANL+0ahzEQ/RpYAOv0FcOoJ4bAMeQ6qNPvwmOz 3EGhpJVLRCTmn7wKjioaHPb8C923gSinH6UoOfGjX+ICxT+KeS45dVqwyZGRM7WeEi21 FSbw== MIME-Version: 1.0 Received: by 10.112.103.202 with SMTP id fy10mr2442057lbb.13.1354883260411; Fri, 07 Dec 2012 04:27:40 -0800 (PST) Received: by 10.114.29.10 with HTTP; Fri, 7 Dec 2012 04:27:40 -0800 (PST) X-Originating-IP: [81.134.152.4] In-Reply-To: <2EED6C7B-2959-4D76-9B0C-D9F4CFDCE3DE@tzi.org> References: <057.2ba8550a3f0f2269f9c67df979775e71@trac.tools.ietf.org> <072.2a70bed72563131fa2d435816fba64e8@trac.tools.ietf.org> <4034ECC2-DB03-4A90-96F2-852AFEC120DF@sensinode.com> <2EED6C7B-2959-4D76-9B0C-D9F4CFDCE3DE@tzi.org> Date: Fri, 7 Dec 2012 12:27:40 +0000 Message-ID: From: Thomas Fossati To: Carsten Bormann Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQmwpcB7z5DkLx0cUf1HtS1kLbDL3LO49vXEj4JEfB2YaYcGHYAaGbbwMJsne1Rxw+mVKpx1 Cc: core@ietf.org Subject: Re: [core] #255: Authority Name issues with SNI and X.509 certificate X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 07 Dec 2012 12:27:43 -0000 On Fri, Dec 7, 2012 at 11:31 AM, Carsten Bormann wrote: > Indeed. I wonder whether we should be doing what I wrote in the commit comment: > Extract the cert-based section and develop it on a separate axis. > It will be more unstable than the base document until we have found all the right places to connect to and caused any necessary updates. Fully agree with Carsten here. I think this part is not mature enough to be included into the main spec. From zach@sensinode.com Fri Dec 7 11:04:52 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B759B21F8925 for ; Fri, 7 Dec 2012 11:04:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PmOKOZiE4Epl for ; Fri, 7 Dec 2012 11:04:51 -0800 (PST) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id 8A84021F875E for ; Fri, 7 Dec 2012 11:04:51 -0800 (PST) Received: from [192.168.1.103] (87-93-75-138.bb.dnainternet.fi [87.93.75.138]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.8/8.13.4) with ESMTP id qB7J4lIO032436; Fri, 7 Dec 2012 21:04:47 +0200 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Zach Shelby In-Reply-To: Date: Fri, 7 Dec 2012 21:05:06 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <8E36EB37-E474-4DC7-9CC6-D8C5AE7DEA4E@sensinode.com> References: <057.2ba8550a3f0f2269f9c67df979775e71@trac.tools.ietf.org> <072.2a70bed72563131fa2d435816fba64e8@trac.tools.ietf.org> <4034ECC2-DB03-4A90-96F2-852AFEC120DF@sensinode.com> <2EED6C7B-2959-4D76-9B0C-D9F4CFDCE3DE@tzi.org> To: Thomas Fossati X-Mailer: Apple Mail (2.1084) Cc: core@ietf.org Subject: Re: [core] #255: Authority Name issues with SNI and X.509 certificate X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 07 Dec 2012 19:04:52 -0000 On Dec 7, 2012, at 2:27 PM, Thomas Fossati wrote: > On Fri, Dec 7, 2012 at 11:31 AM, Carsten Bormann wrote: >> Indeed. I wonder whether we should be doing what I wrote in the = commit comment: >> Extract the cert-based section and develop it on a separate axis. >> It will be more unstable than the base document until we have found = all the right places to connect to and caused any necessary updates. >=20 > Fully agree with Carsten here. I think this part is not mature enough > to be included into the main spec. As long as this is not required by the IESG security folks for = completeness, then I would have no problem doing that. =20 I would point out that the way a CoAP client making a request to a = coaps:// URI and then verifying that the authority it thinks it is = talking to using SubjectAltName is standard practice. This should be = left in the specification. The part that is new is describing how to carry other application layer = identifiers in the X.509 and then how to verify those (EUI-64, RD = endpoint name etc.). For this it would be useful to have a separate = specification.=20 Zach --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://www.sensinode.com @SensinodeIoT Mobile: +358 40 7796297 Twitter: @zach_shelby LinkedIn: http://fi.linkedin.com/in/zachshelby 6LoWPAN Book: http://6lowpan.net From tho@koanlogic.com Fri Dec 7 12:17:36 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C22A21F87E9 for ; Fri, 7 Dec 2012 12:17:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lwNpneLCxbUJ for ; Fri, 7 Dec 2012 12:17:35 -0800 (PST) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 71F7221F8742 for ; Fri, 7 Dec 2012 12:17:34 -0800 (PST) Received: by mail-lb0-f172.google.com with SMTP id y2so780260lbk.31 for ; Fri, 07 Dec 2012 12:17:34 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=M4Fh3BmnyXrjJTq+VkrJ43CKdnkWzSFbyvLsveDEA5g=; b=ApQK8fO3kybmlj9BUsTwMxW9uiSlrPr8Xbo/ElHBHDHByR3lFZuY+Zg+uIHo07fxES QZCYLXY2ykZitj/wQw9HlEUyYoXx5GWkXH47YFzwy0jXxHy5lDvCzBtXTFiDXqDU9Cy0 GlPNofBncfi/+Io34YGaLejlKDlfAWvNmUAIFXcnMLWoBjaOQVFu+adI0CD+7wkjiCw3 xgrQb60glIWJbVfJzzd6mZqiZnW35txCi4c+lz8sgNEnKpU1X+E7TBWTMYCzJzDdBTlu H3G3b7pwBNdTewYpgHlpG4EWNC6by4ebxat/bXy/K7Nl/s4B2NKRFP2aD2FWANx0ic86 l5kA== MIME-Version: 1.0 Received: by 10.112.25.168 with SMTP id d8mr3015078lbg.62.1354911453912; Fri, 07 Dec 2012 12:17:33 -0800 (PST) Received: by 10.114.29.10 with HTTP; Fri, 7 Dec 2012 12:17:33 -0800 (PST) X-Originating-IP: [86.0.176.63] In-Reply-To: <8E36EB37-E474-4DC7-9CC6-D8C5AE7DEA4E@sensinode.com> References: <057.2ba8550a3f0f2269f9c67df979775e71@trac.tools.ietf.org> <072.2a70bed72563131fa2d435816fba64e8@trac.tools.ietf.org> <4034ECC2-DB03-4A90-96F2-852AFEC120DF@sensinode.com> <2EED6C7B-2959-4D76-9B0C-D9F4CFDCE3DE@tzi.org> <8E36EB37-E474-4DC7-9CC6-D8C5AE7DEA4E@sensinode.com> Date: Fri, 7 Dec 2012 20:17:33 +0000 Message-ID: From: Thomas Fossati To: Zach Shelby Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQkxHD1Xw+uzVOZjwcsUwLBGkoObNfqKIrlz/lrXAZSPvSkANIbIzlOaVyyaxLogHvv5j3F9 Cc: core@ietf.org Subject: Re: [core] #255: Authority Name issues with SNI and X.509 certificate X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 07 Dec 2012 20:17:36 -0000 On Fri, Dec 7, 2012 at 7:05 PM, Zach Shelby wrote: > I would point out that the way a CoAP client making a request to a coaps:// URI and then verifying that the authority it thinks it is talking to using SubjectAltName is standard practice. This should be left in the specification. Right. Another quick question: current text (-13) has rules just for subjectAltName of type URI. What should be the behaviour in case of a DNS name ? > The part that is new is describing how to carry other application layer identifiers in the X.509 and then how to verify those (EUI-64, RD endpoint name etc.). For this it would be useful to have a separate specification. Yep. There we could define an OtherName format that is suitable for that kind of identifiers, and perhaps update 6066 with a companion NameType for SNI. From zach@sensinode.com Fri Dec 7 12:32:36 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 006B821F8614 for ; Fri, 7 Dec 2012 12:32:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3452HIHUk4Gc for ; Fri, 7 Dec 2012 12:32:35 -0800 (PST) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id DD28221F85F5 for ; Fri, 7 Dec 2012 12:32:34 -0800 (PST) Received: from [192.168.1.103] (87-93-75-138.bb.dnainternet.fi [87.93.75.138]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.8/8.13.4) with ESMTP id qB7KWVUr012915; Fri, 7 Dec 2012 22:32:31 +0200 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Zach Shelby In-Reply-To: Date: Fri, 7 Dec 2012 22:32:50 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <30A1368F-2EEB-46AF-A1EF-021C8CB988E6@sensinode.com> References: <057.2ba8550a3f0f2269f9c67df979775e71@trac.tools.ietf.org> <072.2a70bed72563131fa2d435816fba64e8@trac.tools.ietf.org> <4034ECC2-DB03-4A90-96F2-852AFEC120DF@sensinode.com> <2EED6C7B-2959-4D76-9B0C-D9F4CFDCE3DE@tzi.org> <8E36EB37-E474-4DC7-9CC6-D8C5AE7DEA4E@sensinode.com> To: Thomas Fossati X-Mailer: Apple Mail (2.1084) Cc: "core@ietf.org WG" Subject: Re: [core] #255: Authority Name issues with SNI and X.509 certificate X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 07 Dec 2012 20:32:36 -0000 On Dec 7, 2012, at 10:17 PM, Thomas Fossati wrote: > On Fri, Dec 7, 2012 at 7:05 PM, Zach Shelby = wrote: >> I would point out that the way a CoAP client making a request to a = coaps:// URI and then verifying that the authority it thinks it is = talking to using SubjectAltName is standard practice. This should be = left in the specification. >=20 > Right. >=20 > Another quick question: current text (-13) has rules just for > subjectAltName of type URI. What should be the behaviour in case of a > DNS name ? Good eye. That text is still not correct, as I don't see any reason why = type URI would be useful here. Instead, we should simply define the use = of type DNS as defined in RFC 6025. We also still leave the hole open = for using CN if no SubjectAltName exists. I think we should require the = use of SubjectAltName for CoAPS, with the use of the DNS type (and/or = optionally IP type) as recommended in = http://tools.ietf.org/html/rfc6125#section-4. I don't see a reason to = define the use of either URI or SRV for CoAPS - neither does HTTPS.=20 Looks like we already identified the first WGLC comment :-) Do others = agree we should clarify this as described (of course needs work on = actual text)? >> The part that is new is describing how to carry other application = layer identifiers in the X.509 and then how to verify those (EUI-64, RD = endpoint name etc.). For this it would be useful to have a separate = specification. >=20 > Yep. There we could define an OtherName format that is suitable for > that kind of identifiers, and perhaps update 6066 with a companion > NameType for SNI. Exactly. And using otherName requires us to request our own OID for the = purpose, and that will probably need its own specification. Requesting a = new NameType is an interesting idea, a longer route but maybe the right = thing in the long term. We probably need to talk to the PKIX folks. Zach --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://www.sensinode.com @SensinodeIoT Mobile: +358 40 7796297 Twitter: @zach_shelby LinkedIn: http://fi.linkedin.com/in/zachshelby 6LoWPAN Book: http://6lowpan.net From tho@koanlogic.com Sat Dec 8 13:31:28 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1389B21F8AC5 for ; Sat, 8 Dec 2012 13:31:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SJpo3FnaBsYT for ; Sat, 8 Dec 2012 13:31:27 -0800 (PST) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 001CE21F8AC1 for ; Sat, 8 Dec 2012 13:31:26 -0800 (PST) Received: by mail-la0-f44.google.com with SMTP id d3so1241076lah.31 for ; Sat, 08 Dec 2012 13:31:25 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding:x-gm-message-state; bh=rfzfXg68Q2X2WkEJE0sxbK3hb5uyKinV1x3etDZQX64=; b=nEaHiC9s6Cw+QVEKHJ3BmbqHele4IvpXD+0x+VGe7GEuRnuosyPLNJo9gpkDD98COj cr6NewfVGvLn1zi+BSylPtk5oGFSN6G6nG+tCjjlzgfUVSadzBz6Ez/G1yLMAlHyXMoR ZEHwyetKZduqiaDSQIbS+fPDVpQszTpuqwE5ACu0uRSzx5D68JLB3QRPOTFMEFnoAQiY H7Rrt4X1gMa8/JWd4PdfugEE47mZM24l7OOndKPCLbgezthCarI7p0enjSerDMnyOU7Y 9fuDVuxe21klGM8SlT0cdoUoYGSTugdewR6zNjiSfodsPTY2cUxWZv3tlttgYRWvkC8y jAnA== MIME-Version: 1.0 Received: by 10.152.125.237 with SMTP id mt13mr9188821lab.45.1355002285485; Sat, 08 Dec 2012 13:31:25 -0800 (PST) Received: by 10.114.29.10 with HTTP; Sat, 8 Dec 2012 13:31:25 -0800 (PST) X-Originating-IP: [79.55.100.48] In-Reply-To: <30A1368F-2EEB-46AF-A1EF-021C8CB988E6@sensinode.com> References: <057.2ba8550a3f0f2269f9c67df979775e71@trac.tools.ietf.org> <072.2a70bed72563131fa2d435816fba64e8@trac.tools.ietf.org> <4034ECC2-DB03-4A90-96F2-852AFEC120DF@sensinode.com> <2EED6C7B-2959-4D76-9B0C-D9F4CFDCE3DE@tzi.org> <8E36EB37-E474-4DC7-9CC6-D8C5AE7DEA4E@sensinode.com> <30A1368F-2EEB-46AF-A1EF-021C8CB988E6@sensinode.com> Date: Sat, 8 Dec 2012 21:31:25 +0000 Message-ID: From: Thomas Fossati To: Zach Shelby Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQnYtoNRBZjS5O+YNRUJLjct8AMP/IABaAtHGHUhpH/7w80TeKWVVNoL56crV6mXfdS0nPIk Cc: "core@ietf.org WG" Subject: Re: [core] #255: Authority Name issues with SNI and X.509 certificate X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Dec 2012 21:31:28 -0000 On Fri, Dec 7, 2012 at 8:32 PM, Zach Shelby wrote: > Good eye. That text is still not correct, as I don't see any reason why t= ype URI would be useful here. Instead, we should simply define the use of t= ype DNS as defined in RFC 6025. We also still leave the hole open for using= CN if no SubjectAltName exists. I think we should require the use of Subje= ctAltName for CoAPS, with the use of the DNS type (and/or optionally IP typ= e) as recommended in http://tools.ietf.org/html/rfc6125#section-4. I don't = see a reason to define the use of either URI or SRV for CoAPS - neither doe= s HTTPS. Zach, let me recap to check whether I got your idea correctly: (a) require SubjectAltName with dNSName (b) allow a dNSName in CN as a fall back Is that what you mean ? If so, I'd support it, as I think it's the kind of choice that would provide us with a reasonable playground for implementations, and at the same time would let CoAP-base go smoothly through WGLC and IESG. (I think that allowing a SubjectAltName with iPAddress in CoAP-base has the same problem as EUI-64 or other kind of non-DNS identifiers for SNI. So, I'd left this up to be defined in the "coaps/cert" draft.) >> Yep. There we could define an OtherName format that is suitable for >> that kind of identifiers, and perhaps update 6066 with a companion >> NameType for SNI. > > Exactly. And using otherName requires us to request our own OID for the p= urpose, and that will probably need its own specification. Requesting a new= NameType is an interesting idea, a longer route but maybe the right thing = in the long term. We probably need to talk to the PKIX folks. I'm not familiar with the process, but couldn't we just bundle the two requests in to the same doc ? From zach@sensinode.com Sun Dec 9 04:17:39 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADC1421F8BDA for ; Sun, 9 Dec 2012 04:17:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jmlRTg5ZwiOo for ; Sun, 9 Dec 2012 04:17:38 -0800 (PST) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id 6944F21F8934 for ; Sun, 9 Dec 2012 04:17:37 -0800 (PST) Received: from [192.168.1.103] (87-95-62-146.bb.dnainternet.fi [87.95.62.146]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.8/8.13.4) with ESMTP id qB9CHYPw021815; Sun, 9 Dec 2012 14:17:34 +0200 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Zach Shelby In-Reply-To: Date: Sun, 9 Dec 2012 14:17:53 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <74B788F4-C0F0-45FA-AD48-3A54EFF85D45@sensinode.com> References: <057.2ba8550a3f0f2269f9c67df979775e71@trac.tools.ietf.org> <072.2a70bed72563131fa2d435816fba64e8@trac.tools.ietf.org> <4034ECC2-DB03-4A90-96F2-852AFEC120DF@sensinode.com> <2EED6C7B-2959-4D76-9B0C-D9F4CFDCE3DE@tzi.org> <8E36EB37-E474-4DC7-9CC6-D8C5AE7DEA4E@sensinode.com> <30A1368F-2EEB-46AF-A1EF-021C8CB988E6@sensinode.com> To: Thomas Fossati X-Mailer: Apple Mail (2.1084) Cc: "core@ietf.org WG" Subject: Re: [core] #255: Authority Name issues with SNI and X.509 certificate X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 09 Dec 2012 12:17:39 -0000 On Dec 8, 2012, at 11:31 PM, Thomas Fossati wrote: > On Fri, Dec 7, 2012 at 8:32 PM, Zach Shelby = wrote: >> Good eye. That text is still not correct, as I don't see any reason = why type URI would be useful here. Instead, we should simply define the = use of type DNS as defined in RFC 6025. We also still leave the hole = open for using CN if no SubjectAltName exists. I think we should require = the use of SubjectAltName for CoAPS, with the use of the DNS type = (and/or optionally IP type) as recommended in = http://tools.ietf.org/html/rfc6125#section-4. I don't see a reason to = define the use of either URI or SRV for CoAPS - neither does HTTPS. >=20 > Zach, let me recap to check whether I got your idea correctly: > (a) require SubjectAltName with dNSName > (b) allow a dNSName in CN as a fall back Isn't the general trend in PKIX the depreciation for this use of CN? If = that is not the case, then happy to keep it as a backup. (c) allow SubjectAltName with iPAddress in addition to dNSName Constrained CoAP endpoints will not make heavy use of DNS names in URIs = (which requires DNS resolution), thus the dNSName (or CN) alone are not = useful for verifying the Certificate of who you are doing a DTLS = handshake with. In cases where an IP address is used in the URI (the = common case) then the iPAddress field should be used for verification. = Obviously the iPAddress needs to be optional in a Certificate as it is = only practical on endpoints with a stable IP address (for example a = backend Resource Directory). > Is that what you mean ? If so, I'd support it, as I think it's the > kind of choice that would provide us with a reasonable playground for > implementations, and at the same time would let CoAP-base go smoothly > through WGLC and IESG. Agreed, that should be our goal. > (I think that allowing a SubjectAltName with iPAddress in CoAP-base > has the same problem as EUI-64 or other kind of non-DNS identifiers > for SNI. So, I'd left this up to be defined in the "coaps/cert" > draft.) The use of iPAddress is well defined, and in current use today. As it = doesn't require any new specification work or identifier requests, thus = it should go in the base spec. Especially as this will be a common case = of verification.=20 >>> Yep. There we could define an OtherName format that is suitable for >>> that kind of identifiers, and perhaps update 6066 with a companion >>> NameType for SNI. >>=20 >> Exactly. And using otherName requires us to request our own OID for = the purpose, and that will probably need its own specification. = Requesting a new NameType is an interesting idea, a longer route but = maybe the right thing in the long term. We probably need to talk to the = PKIX folks. >=20 > I'm not familiar with the process, but couldn't we just bundle the two > requests in to the same doc ? I would rather not have multiple ways of doing this. We should either = decide to go for otherName with OIDs, or a new field like nameType. But = yes, the request should be part of that doc either way. Looks like we = need a volunteer to start writing a new I-D on the use of application = identifiers in X.509v3 Certificates for CoRE. Anyone? Zach --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://www.sensinode.com @SensinodeIoT Mobile: +358 40 7796297 Twitter: @zach_shelby LinkedIn: http://fi.linkedin.com/in/zachshelby 6LoWPAN Book: http://6lowpan.net From trac+core@trac.tools.ietf.org Mon Dec 10 04:59:34 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCD6021F8E5B for ; Mon, 10 Dec 2012 04:59:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uzt0JVRGg1Go for ; Mon, 10 Dec 2012 04:59:34 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 112F421F8D6F for ; Mon, 10 Dec 2012 04:59:33 -0800 (PST) Received: from localhost ([127.0.0.1]:35259 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1Ti2x5-0006uX-Ex; Mon, 10 Dec 2012 13:59:19 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "core issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-core-groupcomm@tools.ietf.org, esko.dijk@philips.com X-Trac-Project: core Date: Mon, 10 Dec 2012 12:59:19 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/266 Message-ID: <060.7de3ddd23edb8884ed9d72e8d12fcdcb@trac.tools.ietf.org> X-Trac-Ticket-ID: 266 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-core-groupcomm@tools.ietf.org, esko.dijk@philips.com, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: akbar.rahman@interdigital.com, esko.dijk@philips.com Resent-Message-Id: <20121210125934.112F421F8D6F@ietfa.amsl.com> Resent-Date: Mon, 10 Dec 2012 04:59:33 -0800 (PST) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: [core] #266: Remove section 2.3 (Potential Solutions for Group Communications) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Reply-To: trac+core@trac.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Dec 2012 12:59:34 -0000 #266: Remove section 2.3 (Potential Solutions for Group Communications) To remove section 2.3 (Potential Solutions for Group Communications) as it is purely background information. Section to be moved to draft-dijk-core- groupcomm-misc. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core- esko.dijk@philips.com | groupcomm@tools.ietf.org Type: task | Status: new Priority: minor | Milestone: Component: groupcomm | Version: Severity: - | Keywords: -------------------------+------------------------------------------------- Ticket URL: core From trac+core@trac.tools.ietf.org Mon Dec 10 05:04:08 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2649421F8E6C for ; Mon, 10 Dec 2012 05:04:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6BUFq7cqgDfW for ; Mon, 10 Dec 2012 05:04:07 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 9161F21F8E65 for ; Mon, 10 Dec 2012 05:04:07 -0800 (PST) Received: from localhost ([127.0.0.1]:35900 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1Ti31g-0007dp-0l; Mon, 10 Dec 2012 14:04:04 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "core issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-core-groupcomm@tools.ietf.org, esko.dijk@philips.com X-Trac-Project: core Date: Mon, 10 Dec 2012 13:04:03 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/267 Message-ID: <060.b17c5f6aeaebaf980758deeb31370eb6@trac.tools.ietf.org> X-Trac-Ticket-ID: 267 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-core-groupcomm@tools.ietf.org, esko.dijk@philips.com, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: akbar.rahman@interdigital.com, esko.dijk@philips.com Resent-Message-Id: <20121210130407.9161F21F8E65@ietfa.amsl.com> Resent-Date: Mon, 10 Dec 2012 05:04:07 -0800 (PST) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: [core] #267: To remove Appendix B (CoAP-Observe Alternative to Group Communications) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Reply-To: trac+core@trac.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Dec 2012 13:04:08 -0000 #267: To remove Appendix B (CoAP-Observe Alternative to Group Communications) To remove Appendix B (CoAP-Observe Alternative to Group Communications) as it is as an alternative to the IP Multicast based solution. The IP multicast based solution is intended to be the only focus of this I-D. This appendix to be moved to draft-dijk-core-groupcomm-misc. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core- esko.dijk@philips.com | groupcomm@tools.ietf.org Type: task | Status: new Priority: minor | Milestone: Component: groupcomm | Version: Severity: - | Keywords: -------------------------+------------------------------------------------- Ticket URL: core From trac+core@trac.tools.ietf.org Mon Dec 10 05:07:39 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56FD021F8E79 for ; Mon, 10 Dec 2012 05:07:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MZM0fDG6MecU for ; Mon, 10 Dec 2012 05:07:37 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id BFD3F21F8E32 for ; Mon, 10 Dec 2012 05:07:37 -0800 (PST) Received: from localhost ([127.0.0.1]:36191 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1Ti34v-0007dH-FO; Mon, 10 Dec 2012 14:07:25 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "core issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-core-groupcomm@tools.ietf.org, esko.dijk@philips.com X-Trac-Project: core Date: Mon, 10 Dec 2012 13:07:25 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://etherpad.tools.ietf.org/wg/core/trac/ticket/268 Message-ID: <060.41d11bcf9b7217f89a4f805a946b95e4@trac.tools.ietf.org> X-Trac-Ticket-ID: 268 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-core-groupcomm@tools.ietf.org, esko.dijk@philips.com, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: akbar.rahman@interdigital.com, esko.dijk@philips.com Resent-Message-Id: <20121210130737.BFD3F21F8E32@ietfa.amsl.com> Resent-Date: Mon, 10 Dec 2012 05:07:37 -0800 (PST) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: [core] #268: To remove current section 8 (Conclusions) text X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Reply-To: trac+core@trac.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Dec 2012 13:07:39 -0000 #268: To remove current section 8 (Conclusions) text Because the focus of the I-D is now no longer on analyzing IP multicast vs other approaches, this conclusions section has become redundant. The current text (stating the choice for IP multicast) will be removed. (It may be replaced by other text in the conclusions section that summarizes the content/findings of the current I-D.) -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core- esko.dijk@philips.com | groupcomm@tools.ietf.org Type: task | Status: new Priority: minor | Milestone: Component: groupcomm | Version: Severity: - | Keywords: -------------------------+------------------------------------------------- Ticket URL: core From trac+core@trac.tools.ietf.org Mon Dec 10 05:18:24 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8944921F8D23 for ; Mon, 10 Dec 2012 05:18:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IdCh6CF+OOgy for ; Mon, 10 Dec 2012 05:18:20 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id B8EC621F8CDF for ; Mon, 10 Dec 2012 05:18:20 -0800 (PST) Received: from localhost ([127.0.0.1]:36877 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1Ti3FE-0007pD-Bu; Mon, 10 Dec 2012 14:18:04 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "core issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-core-groupcomm@tools.ietf.org, esko.dijk@philips.com X-Trac-Project: core Date: Mon, 10 Dec 2012 13:18:04 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/269 Message-ID: <060.8ab7b5fefbf91c487b2e2fb81b566755@trac.tools.ietf.org> X-Trac-Ticket-ID: 269 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-core-groupcomm@tools.ietf.org, esko.dijk@philips.com, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: akbar.rahman@interdigital.com, esko.dijk@philips.com Resent-Message-Id: <20121210131820.B8EC621F8CDF@ietfa.amsl.com> Resent-Date: Mon, 10 Dec 2012 05:18:20 -0800 (PST) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: [core] #269: Simplify light switch use case and conform better to current practice X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Reply-To: trac+core@trac.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Dec 2012 13:18:24 -0000 #269: Simplify light switch use case and conform better to current practice Based on last WG meeting discussions and input; it is proposed to simplify the lighting use case and conform better to current/expected practice in LLNs. Specifically: 1. Use a simpler alternative to MLD (as MLD is currently not designed to operate in LLN environments; nor expected to be used in typical LLN deployments). MLD will still be listed as an option along with others. The simpler alternative is preconfiguration in 6LBRs what multicast traffic is filtered and which not. 2. Light switch will CoAP multicast directly (not via Proxy) to make the basic case more clear. (Using proxy is an optional extension of the basic use case.) 3. Explain how the light switch deals with dropped packets. Current solution envisaged is that lights do not send CoAP responses to multicast. Light switch relies on routing (e.g. MPL/Trickle-multicast for LLNs) for reliable-enough delivery. 4. Remove the DNS resolution step in the basic use case. Using DNS is optional and should be presented as such. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core- esko.dijk@philips.com | groupcomm@tools.ietf.org Type: task | Status: new Priority: major | Milestone: Component: groupcomm | Version: Severity: - | Keywords: -------------------------+------------------------------------------------- Ticket URL: core From tho@koanlogic.com Mon Dec 10 05:50:57 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EEDC21F8E26 for ; Mon, 10 Dec 2012 05:50:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fIkoOjZEUX4H for ; Mon, 10 Dec 2012 05:50:56 -0800 (PST) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4941221F8E25 for ; Mon, 10 Dec 2012 05:50:55 -0800 (PST) Received: by mail-lb0-f172.google.com with SMTP id y2so2250950lbk.31 for ; Mon, 10 Dec 2012 05:50:55 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:date:message-id:subject:from:to:cc :content-type:x-gm-message-state; bh=nLRLf2GdYu3GAjh8T5IwTvxtGSUDkZs9FGRe8Kp/DVk=; b=EjDfU1Tw4Q/iN7B9AjCrxH8oO41xJCiqc5x21nA5BYK8W7R1ekOb132/W1iPfIEqa6 AZO5Dtuwr7F1XeF99zoPD+6xPVU9mwg2qfvye6tYg/V4kZJjyTLyN+msSxLdV8DOM4YE pELmZWxpu5XIRtyUT62n7aK9FIFK7LZRRM3uR1Aht0XCgaJQgCNHal3QWesZgBr8XXU5 AoC3TW4/1HTecc59OYfeGsR0yj09MZ9aOSOCO4IBEMtH9IWfVKQyxav0/m4pB8r8fj6b TeBYzA3sIb06ThMgduOKGHzTdtjWSzKfaWj7zJ6EB4oI4PdC5flto8uVHi5oYtmjvXDD q7IA== MIME-Version: 1.0 Received: by 10.112.49.99 with SMTP id t3mr5865928lbn.52.1355147454890; Mon, 10 Dec 2012 05:50:54 -0800 (PST) Received: by 10.114.29.10 with HTTP; Mon, 10 Dec 2012 05:50:54 -0800 (PST) X-Originating-IP: [81.134.152.4] Date: Mon, 10 Dec 2012 13:50:54 +0000 Message-ID: From: Thomas Fossati To: Zach Shelby Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQkwLSI1N6Vba8dvEYT/xlUMbgvhpt0WWTqnVHlDXeuEKwbnEDd3+kA4F8yit/VwxCuFItZT Cc: "core@ietf.org WG" Subject: [core] CoAP certificate Id's scope (was: Re: #255: Authority Name issues with SNI and X.509 certificate) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 10 Dec 2012 13:50:57 -0000 > Looks like we need a volunteer to start writing a new I-D on the use of application identifiers in X.509v3 Certificates for CoRE. Anyone? I'd volunteer for the task, but it's not clear to me what the scope of this doc would be (and it seems to me that it has the potential to become pretty wide). The base need is to define some _stable_ identifier to be associated to the certificates that CoAP nodes pass around for the sake of authenticating each other. (Because we've decided to go with the PKIX model, which implies a trusted third party issuing the identity proofs, the stability attribute of the identifier is key to avoid that a new certificate is issued each time the identifier moves -- an unbearable cost, both operational and financial.) And we seem to have to handle two slightly different kind of identifiers: (a) those used for server identities, whose expressiveness should be able to match (only) the served URIs; (b) those used for requesting identities (clients), which should be able to identify a node as a requesting application: using the node name (EUI-64, DNS name), and optionally a source port. On top of that, we'd probably need a companion syntax to express identifiers when used for authority selection in SNI, because current SNI syntax is tailored for the DNS name scenario only. So, what types of identifiers are there, and which of those could be used for (a) and (b) ? At least: (1) DNS names: common practice, but need DNS which is not mandated in CoAP base (maybe a problem?); (2) EUI-64: same as (1) for non DNS deployments, but need another entity for resolving (RD?); (3) IP addresses: a poor fallback for (1) and (2) that is subject to renumbering, dynamic addressing, etc. -- clearly too fragile to be considered as a source of stable identities; (4) URIs: nonsensical for (b), but perfect for (a) modulo the possibility to provide the whole subset of URIs served by the CoAP end-point in a single (regular) expression. My feeling is that we should: - definitely avoid (3); and - probably require (4) for servers; and - require (2) or (1) for clients, depending on the availability of DNS. Further point to think carefully about is the fact that we probably want to express URI authorities with names like (2) (i.e. with non regname/IPaddr syntax), and so we may need to extend the syntax of coap/coaps URIs with the ABNF that is able to express them. Enough material for the cert draft :-) From trac+core@trac.tools.ietf.org Mon Dec 10 07:59:22 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1524821F84F5 for ; Mon, 10 Dec 2012 07:59:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F+LoKF-D5iA4 for ; Mon, 10 Dec 2012 07:59:21 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 9358521F8466 for ; Mon, 10 Dec 2012 07:59:17 -0800 (PST) Received: from localhost ([127.0.0.1]:47979 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1Ti5l5-0000Db-F5; Mon, 10 Dec 2012 16:59:07 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "core issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-core-groupcomm@tools.ietf.org, esko.dijk@philips.com X-Trac-Project: core Date: Mon, 10 Dec 2012 15:59:07 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/270 Message-ID: <060.4d32ad6bbe014b849584fa7214427f14@trac.tools.ietf.org> X-Trac-Ticket-ID: 270 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-core-groupcomm@tools.ietf.org, esko.dijk@philips.com, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: akbar.rahman@interdigital.com, esko.dijk@philips.com Resent-Message-Id: <20121210155917.9358521F8466@ietfa.amsl.com> Resent-Date: Mon, 10 Dec 2012 07:59:17 -0800 (PST) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: [core] #270: Remove section 3.7 CoAP Multicast and HTTP Unicast Interworking X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Reply-To: trac+core@trac.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Dec 2012 15:59:22 -0000 #270: Remove section 3.7 CoAP Multicast and HTTP Unicast Interworking To remove section 3.7 CoAP Multicast and HTTP Unicast Interworking. This topic is not essential to the basic CoAP multicast based group communication on which we want to focus this I-D. It will be parked for the time being into draft-dijk-core-groupcomm-misc because this topic is currently also out of scope for draft-castellani-core-http-mapping. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core- esko.dijk@philips.com | groupcomm@tools.ietf.org Type: task | Status: new Priority: major | Milestone: Component: groupcomm | Version: Severity: - | Keywords: -------------------------+------------------------------------------------- Ticket URL: core From cabo@tzi.org Mon Dec 10 12:18:57 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08D9921F8641 for ; Mon, 10 Dec 2012 12:18:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IW9sAF8dB9+W for ; Mon, 10 Dec 2012 12:18:56 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 3D3CF21F863B for ; Mon, 10 Dec 2012 12:18:55 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id qBAKImUK012242 for ; Mon, 10 Dec 2012 21:18:48 +0100 (CET) Received: from [192.168.217.117] (p54893F07.dip.t-dialin.net [84.137.63.7]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 1A0CE6DA; Mon, 10 Dec 2012 21:18:48 +0100 (CET) From: Carsten Bormann Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Mon, 10 Dec 2012 21:18:47 +0100 To: "core@ietf.org WG" Message-Id: <4C4535AB-A859-4284-8667-EE664EE481F6@tzi.org> Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) Subject: [core] Tokens -- opaque or maybe better uint? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 10 Dec 2012 20:18:57 -0000 Offline, I have been asked whether people are happy with the way token = values are currently handled. Right now, you have to store a length *and* a value of up to 8 bytes. I.e. there are 2**64+2**56+2**48+2**40+2**32+2**24+2**16+2**8+1 =3D = 0x10101010101010101 =3D 18519084246547628289 token values. One alternative would be to treat tokens like a uint, i.e. make leading = zero bytes insignificant (and SHOULD NOT send). You could still continue to store length and bytes if that helps your = code (e.g., in echoing back a token in a stateless server), but you = could also zero-extend the token and just store 8 bytes. The total token space would drop from = 2**64+2**56+2**48+2**40+2**32+2**24+2**16+2**8+1 to just 2**64 =3D = 18446744073709551616 =3D 0x10000000000000000, so you could store it in a = 64-bit long (or long long on C with ILP32 data model). Personally, I really don't care that much either way, so I wouldn't make = the change, but since I also already had the thought that a uint might = simplify this, I thought I might want to relay my offline input. Again, = there should be a good reason to make any change at this point, but the = breakage might be limited. (If we do this, we probably also want to think about ETags, the only = other opaque structure we have, which also happens to be up to 8-byte.) Gr=FC=DFe, Carsten From zach@sensinode.com Mon Dec 10 14:12:22 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F62321F8630 for ; Mon, 10 Dec 2012 14:12:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bsp9lAgmY7rr for ; Mon, 10 Dec 2012 14:12:21 -0800 (PST) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id F234921F86BE for ; Mon, 10 Dec 2012 14:12:20 -0800 (PST) Received: from [10.25.86.142] ([62.237.237.210]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.8/8.13.4) with ESMTP id qBAMCHEB019643; Tue, 11 Dec 2012 00:12:17 +0200 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Zach Shelby In-Reply-To: <4C4535AB-A859-4284-8667-EE664EE481F6@tzi.org> Date: Tue, 11 Dec 2012 00:12:38 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <9B37AD47-C90F-4CBB-AC15-37910F61317F@sensinode.com> References: <4C4535AB-A859-4284-8667-EE664EE481F6@tzi.org> To: Carsten Bormann X-Mailer: Apple Mail (2.1084) Cc: "core@ietf.org WG" Subject: Re: [core] Tokens -- opaque or maybe better uint? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 10 Dec 2012 22:12:22 -0000 No, I really don't think we want to do this. First of all, who has a = constrained device that can conveniently store a 64-bit long? Secondly, = we have spent a lot of time reinforcing that Token and ETag MUST be = treated as opaque. Changing that now is just confusing, not to mention = the breaking change. And regarding the storage of Tokens, I don't = understand where the unhappiness is coming from. As a server you are = just echoing that back (which is even easier now in coap-13) and in a = client you decide whether to use a Token in the first place. Even with = Observations, you can decide how many to support at one time.=20 Zach On Dec 10, 2012, at 10:18 PM, Carsten Bormann wrote: > Offline, I have been asked whether people are happy with the way token = values are currently handled. > Right now, you have to store a length *and* a value of up to 8 bytes. > I.e. there are 2**64+2**56+2**48+2**40+2**32+2**24+2**16+2**8+1 =3D = 0x10101010101010101 =3D 18519084246547628289 token values. >=20 > One alternative would be to treat tokens like a uint, i.e. make = leading zero bytes insignificant (and SHOULD NOT send). > You could still continue to store length and bytes if that helps your = code (e.g., in echoing back a token in a stateless server), but you = could also zero-extend the token and just store 8 bytes. > The total token space would drop from = 2**64+2**56+2**48+2**40+2**32+2**24+2**16+2**8+1 to just 2**64 =3D = 18446744073709551616 =3D 0x10000000000000000, so you could store it in a = 64-bit long (or long long on C with ILP32 data model). >=20 > Personally, I really don't care that much either way, so I wouldn't = make the change, but since I also already had the thought that a uint = might simplify this, I thought I might want to relay my offline input. = Again, there should be a good reason to make any change at this point, = but the breakage might be limited. >=20 > (If we do this, we probably also want to think about ETags, the only = other opaque structure we have, which also happens to be up to 8-byte.) >=20 > Gr=FC=DFe, Carsten >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://www.sensinode.com @SensinodeIoT Mobile: +358 40 7796297 Twitter: @zach_shelby LinkedIn: http://fi.linkedin.com/in/zachshelby 6LoWPAN Book: http://6lowpan.net From Bert.Greevenbosch@huawei.com Mon Dec 10 17:21:20 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C5F821F8718 for ; Mon, 10 Dec 2012 17:21:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rlZZU1hPix0r for ; Mon, 10 Dec 2012 17:21:19 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 978F621F8717 for ; Mon, 10 Dec 2012 17:21:17 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AMJ08338; Tue, 11 Dec 2012 01:21:16 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 11 Dec 2012 01:20:30 +0000 Received: from SZXEML420-HUB.china.huawei.com (10.82.67.159) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 11 Dec 2012 01:21:15 +0000 Received: from SZXEML509-MBX.china.huawei.com ([10.82.67.37]) by szxeml420-hub.china.huawei.com ([10.82.67.159]) with mapi id 14.01.0323.003; Tue, 11 Dec 2012 09:21:13 +0800 From: Bert Greevenbosch To: Zach Shelby , Carsten Bormann Thread-Topic: [core] Tokens -- opaque or maybe better uint? Thread-Index: AQHN1xOZgWqoflmIoUi831KQDb4lSpgSEqoAgAC2kWA= Date: Tue, 11 Dec 2012 01:21:11 +0000 Message-ID: <46A1DF3F04371240B504290A071B4DB63CB1550F@szxeml509-mbx> References: <4C4535AB-A859-4284-8667-EE664EE481F6@tzi.org> <9B37AD47-C90F-4CBB-AC15-37910F61317F@sensinode.com> In-Reply-To: <9B37AD47-C90F-4CBB-AC15-37910F61317F@sensinode.com> Accept-Language: en-GB, zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.110.143] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "core@ietf.org WG" Subject: Re: [core] Tokens -- opaque or maybe better uint? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 11 Dec 2012 01:21:20 -0000 I agree with Zach. If we added integer semantics to the token, we would sti= ll need a token length indication, so it doesn't safe bits in the message. The only advantage of the integer interpretation would be that you could do= native integer comparisons, but given the possible large size of the token= and small sizes of the registers this seems not feasible. On architectures= that don't support large integers, it would boil down to doing a string co= mparison but with extra code for omission of possible leading zeros. Comparing and copying opaque strings is easy enough. Best regards, Bert -----Original Message----- From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Zac= h Shelby Sent: 11 December 2012 06:13 To: Carsten Bormann Cc: core@ietf.org WG Subject: Re: [core] Tokens -- opaque or maybe better uint? No, I really don't think we want to do this. First of all, who has a constr= ained device that can conveniently store a 64-bit long? Secondly, we have s= pent a lot of time reinforcing that Token and ETag MUST be treated as opaqu= e. Changing that now is just confusing, not to mention the breaking change.= And regarding the storage of Tokens, I don't understand where the unhappin= ess is coming from. As a server you are just echoing that back (which is ev= en easier now in coap-13) and in a client you decide whether to use a Token= in the first place. Even with Observations, you can decide how many to sup= port at one time.=20 Zach On Dec 10, 2012, at 10:18 PM, Carsten Bormann wrote: > Offline, I have been asked whether people are happy with the way token va= lues are currently handled. > Right now, you have to store a length *and* a value of up to 8 bytes. > I.e. there are 2**64+2**56+2**48+2**40+2**32+2**24+2**16+2**8+1 =3D 0x101= 01010101010101 =3D 18519084246547628289 token values. >=20 > One alternative would be to treat tokens like a uint, i.e. make leading z= ero bytes insignificant (and SHOULD NOT send). > You could still continue to store length and bytes if that helps your cod= e (e.g., in echoing back a token in a stateless server), but you could also= zero-extend the token and just store 8 bytes. > The total token space would drop from 2**64+2**56+2**48+2**40+2**32+2**24= +2**16+2**8+1 to just 2**64 =3D 18446744073709551616 =3D 0x1000000000000000= 0, so you could store it in a 64-bit long (or long long on C with ILP32 dat= a model). >=20 > Personally, I really don't care that much either way, so I wouldn't make = the change, but since I also already had the thought that a uint might simp= lify this, I thought I might want to relay my offline input. Again, there = should be a good reason to make any change at this point, but the breakage = might be limited. >=20 > (If we do this, we probably also want to think about ETags, the only othe= r opaque structure we have, which also happens to be up to 8-byte.) >=20 > Gr=FC=DFe, Carsten >=20 > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://www.sensinode.com @SensinodeIoT Mobile: +358 40 7796297 Twitter: @zach_shelby LinkedIn: http://fi.linkedin.com/in/zachshelby 6LoWPAN Book: http://6lowpan.net _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core From esko.dijk@philips.com Mon Dec 10 22:57:25 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2DA821F860B for ; Mon, 10 Dec 2012 22:57:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.099 X-Spam-Level: X-Spam-Status: No, score=-5.099 tagged_above=-999 required=5 tests=[AWL=1.500, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QUCkXv4dsP6f for ; Mon, 10 Dec 2012 22:57:24 -0800 (PST) Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe001.messaging.microsoft.com [207.46.163.24]) by ietfa.amsl.com (Postfix) with ESMTP id D1AA321F860A for ; Mon, 10 Dec 2012 22:57:23 -0800 (PST) Received: from mail2-co9-R.bigfish.com (10.236.132.232) by CO9EHSOBE024.bigfish.com (10.236.130.87) with Microsoft SMTP Server id 14.1.225.23; Tue, 11 Dec 2012 06:57:22 +0000 Received: from mail2-co9 (localhost [127.0.0.1]) by mail2-co9-R.bigfish.com (Postfix) with ESMTP id A89B22601AF; Tue, 11 Dec 2012 06:57:22 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.55.7.222; KIP:(null); UIP:(null); IPV:NLI; H:mail.philips.com; RD:none; EFVD:NLI X-SpamScore: -34 X-BigFish: VPS-34(zz217bI98dI15d6O9371I9251Jc89bhd6eah542I1432Izz1de0h1202h1e76h1d1ah1d2ahzz8275ch1033IL17326ah8275bh8275dhz2dh2a8h668h839h947hd25hf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h1155h) Received: from mail2-co9 (localhost.localdomain [127.0.0.1]) by mail2-co9 (MessageSwitch) id 1355209040110169_17410; Tue, 11 Dec 2012 06:57:20 +0000 (UTC) Received: from CO9EHSMHS018.bigfish.com (unknown [10.236.132.227]) by mail2-co9.bigfish.com (Postfix) with ESMTP id 0C799100066; Tue, 11 Dec 2012 06:57:20 +0000 (UTC) Received: from mail.philips.com (157.55.7.222) by CO9EHSMHS018.bigfish.com (10.236.130.28) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 11 Dec 2012 06:57:20 +0000 Received: from 011-DB3MPN2-082.MGDPHG.emi.philips.com ([169.254.2.225]) by 011-DB3MMR1-001.MGDPHG.emi.philips.com ([10.128.28.51]) with mapi id 14.02.0318.003; Tue, 11 Dec 2012 06:55:51 +0000 From: "Dijk, Esko" To: Zach Shelby , Carsten Bormann Thread-Topic: [core] Combining Proxy-Uri with Uri-* Thread-Index: AQHN09EMOBJrY1k8Tkii6WyACpXfMJgMIhoAgAcOaZA= Date: Tue, 11 Dec 2012 06:55:50 +0000 Message-ID: <031DD135F9160444ABBE3B0C36CED618B38295@011-DB3MPN2-082.MGDPHG.emi.philips.com> References: <3EA14C54-BC7F-4606-BB06-5307C8BAE9AF@tzi.org> <7E04A71A-BCB9-46F7-AED8-5C50012344C2@sensinode.com> In-Reply-To: <7E04A71A-BCB9-46F7-AED8-5C50012344C2@sensinode.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [62.140.132.94] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: philips.com Cc: "core@ietf.org WG" Subject: Re: [core] Combining Proxy-Uri with Uri-* X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 11 Dec 2012 06:57:25 -0000 > I have no problems with making this less "lame", but we can't have severa= l ways of doing this. Let's do this in only one way (your new proposed way)= : +1 for having one way to do this instead of two. Unless there are reasons to keep a single option Proxy-URI - are there any? regards, Esko -----Original Message----- From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Zac= h Shelby Sent: Thursday 6 December 2012 20:07 To: Carsten Bormann Cc: core@ietf.org WG Subject: Re: [core] Combining Proxy-Uri with Uri-* On Dec 6, 2012, at 6:44 PM, Carsten Bormann wrote: > One comment that we never properly ticketized was this from Cullen Jennin= gs: > >> When I am using a proxy and sending it a COAP URL, I find it totally lam= e that I have to send it in a totally different option than if I was not us= ing a proxy. I think we should change this unless there is some really good= reasons for doing it. Even when using a HTTP URI, I'd rather just add a sc= heme than use proxy-URI. > > [http://www.ietf.org/mail-archive/web/core/current/msg03072.html] > > I completely agree that "lame" is the correct technical term here. > > I have checked in a proposed solution (added at the end of 5.10.2 Proxy-U= ri): > > As a special case to simplify some proxy clients, the absolute-URI > can be constructed from the Uri-* options. When the Proxy-Uri Option > only contains a scheme name followed by a colon, the absolute-URI is > constructed as follows: A CoAP URI is constructed from the Uri-* > options as defined in Section 6.5. In the resulting URI, the initial > scheme and the following colon are then replaced by the content of > the Proxy-Uri Option. > > Those who actually do forward proxies: would that work for you? I have no problems with making this less "lame", but we can't have several = ways of doing this. Let's do this in only one way (your new proposed way): Rename Proxy-Uri to Proxy-Scheme, which contains the scheme of the request = URI. The Uri-* options are then always used to encode the rest of the reque= st URI. Zach > > (Variants of this have been discussed on many hallways. Going the whole = way and defining the interactions of any subset of the Uri-* options with P= roxy-Uri is leading to lots of unneeded complexity. This seems to be the b= est way to keep clients simple. Very little additional work for proxies.) > > Gr=FC=DFe, Carsten > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core -- Zach Shelby, Chief Nerd, Sensinode Ltd. http://www.sensinode.com @SensinodeIoT Mobile: +358 40 7796297 Twitter: @zach_shelby LinkedIn: http://fi.linkedin.com/in/zachshelby 6LoWPAN Book: http://6lowpan.net _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core ________________________________ The information contained in this message may be confidential and legally p= rotected under applicable law. The message is intended solely for the addre= ssee(s). If you are not the intended recipient, you are hereby notified tha= t any use, forwarding, dissemination, or reproduction of this message is st= rictly prohibited and may be unlawful. If you are not the intended recipien= t, please contact the sender by return e-mail and destroy all copies of the= original message. From kovatsch@inf.ethz.ch Tue Dec 11 05:20:36 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D60821F86A4 for ; Tue, 11 Dec 2012 05:20:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0UjzdS1NSqjZ for ; Tue, 11 Dec 2012 05:20:35 -0800 (PST) Received: from edge10.ethz.ch (edge10.ethz.ch [82.130.75.186]) by ietfa.amsl.com (Postfix) with ESMTP id EA8EF21F8784 for ; Tue, 11 Dec 2012 05:20:32 -0800 (PST) Received: from CAS20.d.ethz.ch (172.31.51.110) by edge10.ethz.ch (82.130.75.186) with Microsoft SMTP Server (TLS) id 14.2.298.4; Tue, 11 Dec 2012 14:20:25 +0100 Received: from MBX10.d.ethz.ch ([fe80::6d7b:f3da:a5b1:c9e9]) by CAS20.d.ethz.ch ([fe80::2cd8:4907:7776:c56d%10]) with mapi id 14.02.0298.004; Tue, 11 Dec 2012 14:20:27 +0100 From: "Kovatsch Matthias" To: Bert Greevenbosch , Zach Shelby , Carsten Bormann Thread-Topic: [core] Tokens -- opaque or maybe better uint? Thread-Index: AQHN1xOhc62FIL0IMU2YkqphQibxSpgSiAIAgAA0roCAANhMwA== Date: Tue, 11 Dec 2012 13:20:25 +0000 Message-ID: <55877B3AFB359744BA0F2140E36F52B514D49900@MBX10.d.ethz.ch> References: <4C4535AB-A859-4284-8667-EE664EE481F6@tzi.org> <9B37AD47-C90F-4CBB-AC15-37910F61317F@sensinode.com> <46A1DF3F04371240B504290A071B4DB63CB1550F@szxeml509-mbx> In-Reply-To: <46A1DF3F04371240B504290A071B4DB63CB1550F@szxeml509-mbx> Accept-Language: en-US, de-CH Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.132.130.253] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "core@ietf.org WG" Subject: Re: [core] Tokens -- opaque or maybe better uint? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 11 Dec 2012 13:20:36 -0000 I would also keep Tokens opaque, as constrained devices usually cannot hand= le 64-bit ints easily. Same for ETags to preserve full freedom on how the values are created. Ciao Matthias =20 From Akbar.Rahman@InterDigital.com Tue Dec 11 05:36:56 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 144B121F87AC for ; Tue, 11 Dec 2012 05:36:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5N-dnUujoz2M for ; Tue, 11 Dec 2012 05:36:53 -0800 (PST) Received: from smtp-out1.interdigital.com (smtp-out1.interdigital.com [64.208.228.135]) by ietfa.amsl.com (Postfix) with ESMTP id 6179921F879E for ; Tue, 11 Dec 2012 05:36:51 -0800 (PST) Received: from SAM.InterDigital.com ([10.30.2.11]) by smtp-out1.interdigital.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 11 Dec 2012 08:36:50 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 11 Dec 2012 08:36:49 -0500 Message-ID: In-Reply-To: <55877B3AFB359744BA0F2140E36F52B514D49900@MBX10.d.ethz.ch> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [core] Tokens -- opaque or maybe better uint? Thread-Index: AQHN1xOhc62FIL0IMU2YkqphQibxSpgSiAIAgAA0roCAANhMwIAABTLw References: <4C4535AB-A859-4284-8667-EE664EE481F6@tzi.org><9B37AD47-C90F-4CBB-AC15-37910F61317F@sensinode.com><46A1DF3F04371240B504290A071B4DB63CB1550F@szxeml509-mbx> <55877B3AFB359744BA0F2140E36F52B514D49900@MBX10.d.ethz.ch> From: "Rahman, Akbar" To: "Kovatsch Matthias" , "Bert Greevenbosch" , "Zach Shelby" , "Carsten Bormann" X-OriginalArrivalTime: 11 Dec 2012 13:36:50.0164 (UTC) FILETIME=[92D4CB40:01CDD7A4] Cc: core@ietf.org Subject: Re: [core] Tokens -- opaque or maybe better uint? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 11 Dec 2012 13:36:56 -0000 +1 for keeping tokens opaque=20 (and hopefully we are not all missing something profound that Carsten wanted to convey with his initial proposal ...) /Akbar -----Original Message----- From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Kovatsch Matthias Sent: Tuesday, December 11, 2012 8:20 AM To: Bert Greevenbosch; Zach Shelby; Carsten Bormann Cc: core@ietf.org WG Subject: Re: [core] Tokens -- opaque or maybe better uint? I would also keep Tokens opaque, as constrained devices usually cannot handle 64-bit ints easily. Same for ETags to preserve full freedom on how the values are created. Ciao Matthias =20 _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core From cabo@tzi.org Tue Dec 11 05:40:11 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E1B621F84C4 for ; Tue, 11 Dec 2012 05:40:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LCf9xupjrbnX for ; Tue, 11 Dec 2012 05:40:10 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 86E3321F845E for ; Tue, 11 Dec 2012 05:40:10 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id qBBDe2JW016550 for ; Tue, 11 Dec 2012 14:40:02 +0100 (CET) Received: from [10.0.1.2] (reingewinn.informatik.uni-bremen.de [134.102.218.123]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id B66E7AB1; Tue, 11 Dec 2012 14:40:02 +0100 (CET) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Carsten Bormann In-Reply-To: <4C4535AB-A859-4284-8667-EE664EE481F6@tzi.org> Date: Tue, 11 Dec 2012 14:40:02 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4C4535AB-A859-4284-8667-EE664EE481F6@tzi.org> To: "core@ietf.org WG" X-Mailer: Apple Mail (2.1499) Subject: Re: [core] Tokens -- opaque or maybe better uint? X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 11 Dec 2012 13:40:11 -0000 OK, my summary is that there is a lot of agreement with continuing to = handle Token values (and ETags) as opaque. Thank you all for reconfirming this! Gr=FC=DFe, Carsten From trac+core@trac.tools.ietf.org Tue Dec 11 06:14:20 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B7F221F8778 for ; Tue, 11 Dec 2012 06:14:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mlYoB-pkWE00 for ; Tue, 11 Dec 2012 06:14:20 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id D9DAB21F8776 for ; Tue, 11 Dec 2012 06:14:19 -0800 (PST) Received: from localhost ([127.0.0.1]:53093 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1TiQaz-0003kd-6n; Tue, 11 Dec 2012 15:14:05 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "core issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-core-groupcomm@tools.ietf.org, esko.dijk@philips.com X-Trac-Project: core Date: Tue, 11 Dec 2012 14:14:05 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/271 Message-ID: <060.098bc8881df48568161fdd11a361f525@trac.tools.ietf.org> X-Trac-Ticket-ID: 271 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-core-groupcomm@tools.ietf.org, esko.dijk@philips.com, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: akbar.rahman@interdigital.com, esko.dijk@philips.com Resent-Message-Id: <20121211141419.D9DAB21F8776@ietfa.amsl.com> Resent-Date: Tue, 11 Dec 2012 06:14:19 -0800 (PST) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: [core] #271: Review groupcomm requirements language X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Reply-To: trac+core@trac.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2012 14:14:20 -0000 #271: Review groupcomm requirements language Groupcomm I-D contains requirements language: the use of this should be reviewed. Argument pro: requirements language helps to ensure a uniform, predictable use of CoAP group communication. Implementations can choose to comply to the (optional) guidelines of this I-D. Argument against: informational RFC hence no normative requirements should be posed. If requirements language is kept, then each use of MAY/MUST etc. should be reviewed. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core- esko.dijk@philips.com | groupcomm@tools.ietf.org Type: task | Status: new Priority: major | Milestone: Component: groupcomm | Version: Severity: - | Keywords: -------------------------+------------------------------------------------- Ticket URL: core From barryleiba@gmail.com Sun Dec 16 16:28:33 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6B9D21F84F8 for ; Sun, 16 Dec 2012 16:28:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.043 X-Spam-Level: X-Spam-Status: No, score=-103.043 tagged_above=-999 required=5 tests=[AWL=-0.066, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G85DIBjyboIU for ; Sun, 16 Dec 2012 16:28:32 -0800 (PST) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 37F3721F8496 for ; Sun, 16 Dec 2012 16:28:32 -0800 (PST) Received: by mail-vb0-f44.google.com with SMTP id fc26so6395806vbb.31 for ; Sun, 16 Dec 2012 16:28:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=WbUrwg77ApKo9XsrSe6nGHRzQrMKNxJolw9CkTxRWVY=; b=mYbUa4f2Bor12eMXYQGCYPSh7KUIs5d38npeL01IK3l0UyRu5DY7taXVC/401xW6MA BvPx/mngy/uo/ivN1sq2+Dbueg8/4MbFErMiIa4bBX/ISWCIy+k+lyzKvoXVR8dR4njP WqxMjgp2fNza1udSkUvyKBe6qHe/QXbytQU7ZI9lKpLp6N1jtizJMvQhoVpvHVfo1NZ6 CClO08sPhMGYAsFR4Pi5e9zs2qzuAZb0X/2XZw0MeYQVp8F8BVMIHQVplt5AxazsRhdk yoLzM7cUpK4rFywj77HlPSboLBc9cFtYLGzWSB1UKxyfW1/PS9rx1d+TiBkW4ZGABXRf l2pg== MIME-Version: 1.0 Received: by 10.52.98.98 with SMTP id eh2mr17932721vdb.64.1355704111471; Sun, 16 Dec 2012 16:28:31 -0800 (PST) Sender: barryleiba@gmail.com Received: by 10.58.28.231 with HTTP; Sun, 16 Dec 2012 16:28:30 -0800 (PST) Date: Sun, 16 Dec 2012 19:28:30 -0500 X-Google-Sender-Auth: 0QuPx8uRWHLu_9HjGj5gPT8yWNE Message-ID: From: Barry Leiba To: draft-ietf-core-coap@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1 Cc: core WG Subject: [core] AD review of draft-ietf-core-coap, part 1 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 17 Dec 2012 00:28:33 -0000 I've started my AD review of draft-ietf-core-coap during its working group last call. With a lot of other things to review, it's not going as quickly as I'd like... but I want to stress that this is due to my workload, and is NOT the fault of the document, which is excellently written. Well done, everyone. So far, I've gotten through the end of Section 5.7.3, and am about to start on Section 5.8. I wanted to post what I have so far, so the authors can have those comments now and anyone who has reactions to them can reply. General: Please check for consistency in capitalization of "Non-Confirmable". You have a mixture of "Non-Confirmable" and "Non-confirmable", even within the same paragraph in places, as well as a few instances of "non-confirmable". Check for "Confirmable" vs "confirmable" also (and "Acknowledgment" and "Reset"). Also look for "Message ID" vs "message-ID" (capitalization and hyphenation). I think you need quite a few more forward references than you have. In general, if you talk about something that hasn't been explained and won't be for some while, there should be a forward reference for it. For example, in Section 5.7.3 you say that reverse proxies need to be careful about how they handle the ETag option, and you go into some bit of detail. But the ETag option is not explained until 5.10.6. A forward reference would be useful. Look around for these, and figure that extra references aren't bad, but missing ones can leave readers wondering. -- Sec 3.2 -- string: A Unicode string which is encoded using UTF-8 [RFC3629] in Net-Unicode form [RFC5198]. I don't think you need to mention 3629 at all, and you certainly don't need it as a normative reference. 5198 covers everything you need, and can serve as your reference for UTF-8. It has, itself, a reference to 3629. This also applies to Section 5.5.2. In Section 6.4, you can also take out the reference to 3629 (3986 also has one, if anyone needs it). -- Sec 4.3 -- You have four types of messages: Confirmable, Non-Confirmable, Ack, and Reset. Here you make it clear what to do with Non-Confirmable messages: "A Non-confirmable message MUST NOT be acknowledged by the recipient." It's clear that Ack and Reset messages are different message types -- they are neither Confirmable nor Non-Confirmable... but you require that implementors infer that they, too, are not acknowledged. It would probably be useful to make that explicit, probably by adding a short paragraph to the end of Section 4.3, thus: Acknowledgment and Reset messages are different types of messages, distinct from both Confirmable and Non-Confirmable messages. They are treated similarly to Non-Confirmable messages in that they MUST NOT themselves be acknowledged by the recipient. -- Sec 4.4 -- The initial variable value should be randomozed... Why? -- Sec 4.8.1 -- I'm always cautious about using "below", because people aren't always sure which things "below" are relevant. For "(see discussion below)" and "(see below)" in the last two paragraphs, I'd say, "(see Section 4.8.2)". ensure the adjusted value is also available to all the endpoints in communicating with which these adjusted values are to be used. This is hyper-silly application of the non-rule rubbish that we shouldn't oughta end sentences with prepositions (http://en.wikipedia.org/wiki/List_of_common_English_usage_misconceptions). It's terribly hard to follow. I say throw it out. Take it away. What are you waiting for? That is, just say "to all the endpoints that these adjusted values are to be used to communicate with." -- Sec 4.8.2 -- In the formula for EXCHANGE_LIFETIME, would it not be good to substitute in MAX_TRANSMIT_SPAN instead of the first line, especially because you say in the text that that value is included? That will also make it easier to see how it compares with NON_LIFETIME. -- Sec 5.2 -- After receiving and interpreting a request, a server responds with a CoAP response, which is matched to the request by means of a client- generated token. This is probably a good place to make clear what the difference is between Message ID and Token: that the Ack of the request is matched to the request by Message ID, but the response to the request is matched to the request by the Token. In cases where the response is separate from the Ack (see 5.2.2) or where there is no Ack (see 5.2.3), this is an important distinction. Some text along those lines. No? NEW After receiving and interpreting a request, a server responds with a CoAP response, which is matched to the request by means of a client- generated token, a Message ID (see Section 4.4). END The upper three bits of the 8-bit Response Code number define the class of response. The lower five bits do not have any categorization role; they give additional detail to the overall class (Figure 9). There are 3 classes: I suggest moving the paragraph a couple of paragraphs down -- the one that begins "As a human readable notation" -- up to here, so the documentation format is explained before it's used. I also suggest that that paragraph is a bit wordier than necessary. Maybe this?: NEW The upper three bits of the 8-bit Response Code number define the class of response. The lower five bits do not have any categorization role; they give additional detail to the overall class (Figure 9). The response code is documented in the format "c.xx", where "c" is the class represented as an integer, and "xx" is the detail represented as a two-digit integer. For example, for the response code "10000011" (defined as "Forbidden"), "c" is "100" and "xx" is "00011", and the code is written as "4.03". There are 3 classes: END Responses can be sent in multiple ways, which are defined below. As with Section 4.8.1 on "below": here I'd say, "Responses can be sent in multiple ways, which are defined in the following subsections." -- Sec 5.2.1 -- The response is returned in the Acknowledgement message independent of whether the response indicates success or failure. In effect, the response is piggy-backed on the Acknowledgement message, so no separate message is required to both acknowledge that the request was received and return the response. The second sentence feels convoluted, trying to say the same thing too many times. Maybe this is better?: NEW The response is returned in the Acknowledgement message independent of whether the response indicates success or failure. In effect, the response is piggy-backed on the Acknowledgement message, and no separate message is required to return the response. END -- Sec 5.2.2 -- Nit: Responses to requests carried in a Non-Confirmable message are always sent separately (as there is no Acknowledgement message). Match the numbers right: NEW-1 Responses to requests carried in Non-Confirmable messages are always sent separately (as there are no Acknowledgement messages). ...or... NEW-2 The response to a request carried in a Non-Confirmable message is always sent separately (as there is no Acknowledgement message). END there is no underlying transport protocol that could be instructed to run a keep-alive mechanism, the requester MAY want to set up a timeout that is unrelated to CoAP's retransmission timers in case the server is destroyed or otherwise unable to send the response.) This doesn't feel like a proper 2119 MAY (the "may want to" construction is one clue). I would lower-case it. An exchange is separate by definition when the Acknowledgement to the Confirmable request is an empty message. The Acknowledgement to the Confirmable response MUST also be an empty message, i.e. one that carries neither a request nor a response. However, a server MUST stop retransmitting its response on any matching Acknowledgement (silently ignoring any response code or payload) or Reset message. I'm a little confused at what this is trying to tell me. Is this giving one possible scenario, or is this telling me definitively how to detect that the server is separating the response from the ack? I think it's the latter, but that's not how it seems to read. If that's what you mean, how about this?: NEW When the server chooses to use a separate response, it sends the Acknowledgement to the Confirmable request as an empty message. If the server then sends a Confirmable response, the client's Acknowledgement to that response MUST also be an empty message, (one that carries neither a request nor a response). The server MUST stop retransmitting its response on any matching Acknowledgement (silently ignoring any response code or payload) or Reset message. END I think I might also move this up above the implementation note. -- Sec 5.2.3 -- Isn't the second sentence really saying something more general, beyond what this section is for?: that any endpoint at any time MUST be prepared to receive either a Confirmable or Non-Confirmable response to either a Confirmable or Non-Confirmable request. In other words, whether a response is or is not Confirmable can be unrelated to whether the request was Confirmable or not. Should that be said somewhere above, somewhere in Section 4, as a more general statement? -- Sec 5.3 -- An endpoint receiving a token it did not generate MUST treat it as opaque and make no assumptions about its format. I'd say "make no assumptions about its *content*. This also applies to Section 5.10.6. -- Sec 5.3.2 -- Is it true, and is it worth mentioning, that the determination and matching of endpoint identifiers is specific to the underlying transport and is out of scope for this specification? The reason I ask is that I want it to be clear that, while for UDP this is done by comparing the IP addresses and ports of the endpoints as given in the transport headers, it might be done differently in a system that, for example, identifies an endpoint through means other than IP address. Along that line: In case a message carrying a response is unexpected (i.e. the client is not waiting for a response at the endpoint addressed and/or with the given token), the response is rejected (Section 4.2, Section 4.3). NEW In case a message carrying a response is unexpected (the client is not waiting for a response from the identified endpoint and/or with the given token), the response is rejected (Section 4.2, Section 4.3). END -- Sec 5.4.2 -- In addition, for options that are marked Safe to Forward, the option indicates whether it is intended to be part of the Cache-Key in a request (NoCacheKey is not all set) or not (NoCacheKey is set). "NoCacheKey is not all set" seems a little convoluted, especially because NoCacheKey hasn't been introduced or explained yet. Maybe this is better?: NEW In addition, for options that are marked Safe to Forward, the option indicates whether it is intended to be part of the Cache-Key in a request (some of the NoCacheKey bits are 0) or not (all NoCacheKey bits are 1; see Section 5.4.6). END As I look ahead, I see that there is nowhere an explanation of why there are three bits to represent NoCacheKey. Why is that? (Both: why are there three bits to represent it, *and* why is it not explained in the document?) -- Section 5.4.5 -- The definition of an option MAY specify the option to be repeatable. An option that is repeatable MAY be included one or more times in a message. An option that is not repeatable MUST NOT be included more than once in a message. The first MAY should not be a 2119 key word (it's talking about what's in this document, not about the protocol). I'd change it to, "The definitions of some options specify that those options are repeatable." -- Section 5.5.1 -- For responses indicating a client or server error, the payload is considered a representation of the result of the requested action only if a Content-Format Option is given. In the absence of this option, the payload is a Diagnostic Payload ({{diagnostic-message- payload}}). What's that at the end? -- Section 5.7.3 -- In processing the response, a reverse-proxy has to be careful about namespacing the ETag option. "Namespace" as a verb? Hm. I'm sure I don't know what "namespacing the ETag option" means. Can you try re-wording? --------------------- That's all for now. I'll post again, starting with Section 5.8, after I get another chunk done. Barry, responsible AD From barryleiba.mailing.lists@gmail.com Sun Dec 16 19:48:41 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9394721F88B5 for ; Sun, 16 Dec 2012 19:48:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.042 X-Spam-Level: X-Spam-Status: No, score=-103.042 tagged_above=-999 required=5 tests=[AWL=-0.066, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JGD4lIrGypTW for ; Sun, 16 Dec 2012 19:48:41 -0800 (PST) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id C482221F88A9 for ; Sun, 16 Dec 2012 19:48:40 -0800 (PST) Received: by mail-lb0-f172.google.com with SMTP id y2so4254509lbk.31 for ; Sun, 16 Dec 2012 19:48:39 -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 :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=QAKwTjXp/lT33kWOdyN0hdO7uLqDnXhDiYa2Ry5l3nA=; b=H+p+MB1D8BOrPo+AdqC75ZKZMvlmYIxU1vwYTHjVAtlOLCF0zX83Vd4Q/0LIVdMX6M mhjM3oIllmAr/RoAStmD2f/aaiOy/rquz6UCNPLyyUN3/j+g0Qb1CydNDehJecv6uwy1 G3XE282WUyPJN0tDoZwNb4OE1xWUWNh6aCD0LNHuFCpeL4LTFKyfP2GZOGHASKWshE5d J8sgcqmhka6aMv3myFUHujTINYaym7mI+WT+HW1o5b1zL9LSpm7N234bK3akRNjnlD0e AktWojaUsqn0QsZCzYP0UmMSgglzvvwbhz4jseaNwhPFlFCD0cj7DfDp4yLWIZ+4gXit MWGg== MIME-Version: 1.0 Received: by 10.152.112.36 with SMTP id in4mr9644764lab.35.1355716119781; Sun, 16 Dec 2012 19:48:39 -0800 (PST) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.112.12.166 with HTTP; Sun, 16 Dec 2012 19:48:39 -0800 (PST) In-Reply-To: References: Date: Sun, 16 Dec 2012 22:48:39 -0500 X-Google-Sender-Auth: sEq4fo3wwKp8cyoO4ek4ws41v1k Message-ID: From: Barry Leiba To: Barry Leiba Content-Type: multipart/alternative; boundary=f46d0408d6d9bc619504d104412b Cc: "draft-ietf-core-coap@tools.ietf.org" , core WG Subject: Re: [core] AD review of draft-ietf-core-coap, part 1 X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 17 Dec 2012 03:48:41 -0000 --f46d0408d6d9bc619504d104412b Content-Type: text/plain; charset=ISO-8859-1 Just noticed an error in my posted review: > NEW > After receiving and interpreting a request, a server responds with a > CoAP response, which is matched to the request by means of a client- > generated token, a Message ID (see Section 4.4). > END That was spurious junk that got left in there from when I was playing with some text earlier. Please trash it, and don't let it confuse anything. Barry --f46d0408d6d9bc619504d104412b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Just noticed an error in my posted review:

>=A0NEW=
>=A0 =A0After receiving and interpreting a request, a server respond= s with a
>=A0 =A0CoAP response, which is matched to the request by means of a cli= ent-
>=A0 =A0generated token, a Message ID (see Section 4.4).
>= =A0END

That was spurious junk t= hat got left in there from when I was playing with some text earlier. =A0Pl= ease trash it, and don't let it confuse anything.

Barry
--f46d0408d6d9bc619504d104412b-- From stokcons@xs4all.nl Tue Dec 18 03:06:30 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93D7921F871F for ; Tue, 18 Dec 2012 03:06:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.096 X-Spam-Level: X-Spam-Status: No, score=0.096 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, J_CHICKENPOX_64=0.6, J_CHICKENPOX_74=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wDUltr8FMyEr for ; Tue, 18 Dec 2012 03:06:27 -0800 (PST) Received: from smtp-vbr9.xs4all.nl (smtp-vbr9.xs4all.nl [194.109.24.29]) by ietfa.amsl.com (Postfix) with ESMTP id 116A021F871D for ; Tue, 18 Dec 2012 03:06:26 -0800 (PST) Received: from roundcube.xs4all.nl (roundcube4.xs4all.net [194.109.20.200]) by smtp-vbr9.xs4all.nl (8.13.8/8.13.8) with ESMTP id qBIB5tjD036153; Tue, 18 Dec 2012 12:05:55 +0100 (CET) (envelope-from stokcons@xs4all.nl) Received: from a82-95-140-48.adsl.xs4all.nl ([82.95.140.48]) by roundcube.xs4all.nl with HTTP (HTTP/1.1 POST); Tue, 18 Dec 2012 12:05:54 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Tue, 18 Dec 2012 12:05:54 +0100 From: peter van der Stok To: akbar rahman , esko dijk , Core Organization: vanderstok consultancy Mail-Reply-To: Message-ID: X-Sender: stokcons@xs4all.nl (TFaGD/BfoLbKQgORJsQCXWWoOTPvxrMw) User-Agent: XS4ALL Webmail X-Virus-Scanned: by XS4ALL Virus Scanner Subject: [core] group-comm comments X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: consultancy@vanderstok.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Dec 2012 11:06:30 -0000 Hi Akbar and Esko, I had promised to review, comment the group comm draft. Below the commented text. I have not gone very detailed with my comments. I hope that it is clear from my comments that a reorganization of the draft and a review of the uses cases are necessary to get a clearer picture of the feasibility of group comm in the context of Coap. Especialy difficult to understand for me were: - the use case network configuration - the forming and enabling of groups - use of responses Hope this helps. Greetings, peter _____________________________________________________________________________________________________ Abstract CoAP is a RESTful transfer protocol for constrained devices. It is anticipated that constrained devices will often naturally operate in groups (e.g. in a building automation scenario all lights in a given room may need to be switched on/off as a group). This document defines how the CoAP protocol should be used in a group communication context. An approach for using CoAP on top of IP multicast is detailed for both constrained and un-constrained networks. Also, various use /s causes /s cases/ and corresponding protocol flows are provided to illustrate important concepts. Finally, guidance is provided for deployment in various network topologies. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on April 22, 2013. Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of Rahman & Dijk Expires April 22, 2013 [Page 1] Internet-Draft Group Communication for CoAP October 2012 publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 1. Conventions and Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. This document assumes readers are familiar with the terms and concepts that are used in [I-D.ietf-core-coap]. In addition, this document defines the following terminology: Group Communication A source node sends a single message which is delivered to multiple destination nodes, where all destinations are identified to belong to a specific group. The source node may /remove or may not be part of the group. The underlying mechanism for group communication is assumed to be multicast based. /remove The network where the group communication takes place can be either a constrained or a regular (un-constrained) network/ /comment not sure about the meaning and consequences Multicast Sending a message to multiple destination nodes /s simultaneously./ /s with one network invocation / There are various options to implement multicast including layer 2 (Media Access Control) or layer 3 (IP) mechanisms. IP Multicast A specific multicast solution based on the use of IP multicast addresses as defined in "IANA Guidelines for IPv4 Multicast Address Assignments" [RFC5771] and "IP Version 6 Addressing Architecture" [RFC4291]. Low power and Lossy Network (LLN) Low power and Lossy Network (LLN): A type of constrained network where the devices are interconnected by a variety of low power, lossy links such as IEEE 802.15.4, Bluetooth, WiFi, wired or low power power-line communication links. 2. Introduction 2.1. Background The Constrained Application Protocol (CoAP) is an application protocol (analogous to HTTP) for resource constrained devices operating in an IP network [I-D.ietf-core-coap]. Constrained devices can be large in number, but are often highly correlated to each other (e.g. by type or location). For example, all the light switches in a building may belong to one group and all the thermostats may belong to another group. Groups may be composed by function. For example, Rahman & Dijk Expires April 22, 2013 [Page 3] Internet-Draft Group Communication for CoAP October 2012 the group "all lights in building one" may consist of the groups "all lights on floor one of building one", "all lights on floor two of building one", etc. Groups may be preconfigured /add before deployment or dynamically formed /add during operation . If information needs to be sent to or received from a group of devices, group communication mechanisms can improve efficiency and latency of communication and reduce bandwidth requirements for a given application. HTTP does not support any equivalent functionality to CoAP group communication. 2.2. Scope In this draft, we address the issues related to CoAP group communication in detail, with use cases, recommended approaches and analysis of the impact to the CoAP protocol and to implementations. /add the use of group communication for mDNS is out of scope. The guiding principle is to apply wherever possible existing IETF protocols to achieve group communication functionality. In many cases the contribution of this document lies in explaining how existing mechanisms may be used to /remove together fulfill CoAP group communication needs for specific use cases. 2.3. Potential Solutions for Group Communication The classic concept of group /s communications /s communication is that of a single source distributing content to multiple destination recipients that are all part of a group. Before content can be distributed, there is a separate process to form the group. The source may be either a member or non-member of the group. Group communication solutions have evolved from "bottom" to "top", i.e., from layer 2 (Media Access Control broadcast/multicast) and layer 3 (IP multicast) to application layer group communication, also referred to as application layer multicast. A study published in 2005 [Lao05] identified new solutions in the "middle" (referred to as overlay multicast) that utilize an infrastructure based on proxies. Each of these classes of solutions may be compared [Lao05] using metrics such as link stress and level of host complexity [Banerjee01]. The results show for a realistic internet topology that IP Multicast is the most resource-efficient, with the downside being that it requires /s the most /s more organizational effort to deploy in the infrastructure. IP Multicast is the solution adopted by this draft for CoAP group communication. 3. CoAP Group Communication Based On IP Multicast Rahman & Dijk Expires April 22, 2013 [Page 4] Internet-Draft Group Communication for CoAP October 2012 3.1. IP Multicast Background IP Multicast routing protocols have been evolving for decades, resulting in proposed standards such as Protocol Independent Multicast - Sparse Mode (PIM-SM) [RFC4601]. Yet, due to various technical and marketing reasons, IP Multicast routing is not widely deployed on the general Internet. However, IP Multicast is very popular in specific deployments such as in enterprise networks (e.g. for video conferencing), smart home networks (e.g. UPnP/mDNS) and carrier IPTV deployments. The packet economy and minimal host complexity of IP multicast make it attractive for group communication in constrained environments. Therefore IP multicast is the recommended underlying mechanism for CoAP group communication, and the approach assumed in this document. To achieve IP multicast beyond a subnet, an IP multicast routing protocol needs to be active on routers. The RPL protocol [RFC6550] for example is able to route multicast traffic in constrained LLNs. While PIM-SM [RFC4601] is often used for multicast routing in un- constrained networks. IP multicast can also be run in a Link-Local (LL) scope. This means that there is no routing involved and an IP multicast message is only received /s on the network /s over the link on which it was sent. 3.2. CoAP Group Definition and Naming A group is defined as a set of CoAP endpoints, where each endpoint is configured to receive a multicast CoAP request that is sent to the group's associated IP multicast address. The group MAY have more than one associated IP multicast address. An endpoint MAY be a member of multiple groups. Group membership of an endpoint MAY dynamically change over time. The group MAY be identified by a Group Name ([I-D.vanderstok-core-dna]) which is defined as a prefix string of a Group FQDN. The Group FQDN can be uniquely mapped to a site- local or global multicast IP address via DNS resolution. A CoAP multicast request that addresses a group includes a Group URI as the request URI. A Group URI has the scheme 'coap' and includes in the authority part either a group IP address /add + optional port or a hostname /add + optional port that can be resolved to the group IP address (e.g., a Group Name or Group FQDN). Group URIs MUST follow the URI syntax [RFC3986]. A CoAP /s node /s end-point becomes a group member by listening for CoAP messages on the group's IP multicast address, assuming the default CoAP UDP port. Note that a non-default UDP port MAY be specified for the group; in which case implementers MUST ensure that all group members are configured to use this same port. Rahman & Dijk Expires April 22, 2013 [Page 5] Internet-Draft Group Communication for CoAP October 2012 Examples of hierarchical group naming (and scoping) for a building control application are shown below. URI authority Targeted group all.bldg6.example.com "all nodes in building 6" all.west.bldg6.example.com "all nodes in west wing, building 6" all.floor1.west.bldg6.examp... "all nodes in floor 1, west wing, building 6" all.bu036.floor1.west.bldg6... "all nodes in office bu036, floor1, west wing, building 6" Reverse mapping (from IP multicast address to group FQDN) is supported using the reverse DNS resolution technique ([I-D.vanderstok-core-dna]). 3.3. Group Discovery and Member Discovery CoAP defines a resource discovery capability, but does not yet specify how to discover groups (e.g. find a group to join or send a multicast message to) or to discover members of a group (e.g. to address selected group members by unicast). These topics are elaborated in more detail in [I-D.vanderstok-core-dna] including examples for using DNS-SD and CoRE Resource Directory. 3.3.1. DNS-SD DNS-based Service Discovery [I-D.cheshire-dnsext-dns-sd] defines a conventional way to configure DNS PTR, SRV, and TXT records to enable enumeration of services, such as services offered by CoAP nodes, or enumeration of all CoAP nodes, within specified subdomains. A service is specified by a name of the form .., where the service type for CoAP nodes is _coap._udp and the domain is a DNS domain name that identifies a group as in the examples above. For each CoAP end-point in a group, a PTR record with the name _coap._udp and/or a PTR record with the name _coap._udp. is defined and it points to an SRV record having the .. name. All CoAP nodes in a given subdomain may be enumerated by sending a query for PTR records named _coap._udp to the authoritative DNS server for that zone. A list of SRV records is returned. Each SRV record contains the port and host name (AAAA record) of a CoAP node. The IP address of the node is obtained by resolving the host name. DNS-SD also specifies an optional TXT record, having the same name as the SRV record, which can contain "key=value" attributes. This can be used to store information about the device, e.g. schema=DALI, type=switch, group=lighting.bldg6, etc. Rahman & Dijk Expires April 22, 2013 [Page 6] Internet-Draft Group Communication for CoAP October 2012 Another feature of DNS-SD is the ability to specify service subtypes using PTR records. For example, one could represent all the CoAP groups in a subdomain by PTR records with the name _group._sub._coap._udp or alternatively _group._sub._coap._udp.. 3.3.2. CoRE Resource Directory CoRE Resource Directory [I-D.shelby-core-resource-directory] defines the concept of a Resource Directory (RD) server where CoAP servers can register their resources offered and CoAP clients can discover these resources by querying the RD server. RD syntax can be mapped to DNS-SD syntax and vice versa [I-D.lynn-core-discovery-mapping], such that the above approach can be reused for group discovery and group member discovery. /remove Specifically, the Domain (d) parameter can be set to the group URI by an end-point registering to the RD. If an end-point wants to join multiple groups, it has to repeat the registration process for each group it wants to join. /end remove /comment d parameter semantics not clear 3.4. Group Resource Manipulation Group communications SHALL only be used for idempotent methods (i.e. CoAP GET, PUT, DELETE). The CoAP messages that are sent via multicast SHALL be Non-Confirmable. A unicast response per server MAY be sent back to answer the group request (e.g. response "2.05 Content" to a group GET request) taking into account the congestion control rules defined in [I-D.ietf-core-coap]. The unicast responses may be a mixture of success (e.g. 2.05 Content) and failure (e.g. 4.04 Not Found) codes depending on the individual server processing result. Group communications SHALL NOT be used for non-idempotent methods (i.e. CoAP POST). This is because not all group members are guaranteed to receive the multicast request, and the sender can not readily find out which group members did not receive it. All nodes in a given group SHOULD receive the same request /remove with high probability. /comment I don't see where probability comes in. This will not be the case if there is diversity in the authority port (i.e. a diversity of dynamic port addresses across the group) or if the targeted resource is located at different paths on different nodes. Therefore, some measures must be present to ensure uniformity in port number and resource names/locations within a group. This document proposes the following measures: Rahman & Dijk Expires April 22, 2013 [Page 7] Internet-Draft Group Communication for CoAP October 2012 o All CoAP multicast requests MUST be sent either to the default CoAP UDP port (i.e. default Uri-Port as defined in [I-D.ietf-core-coap]), or to a port number obtained via a service discovery lookup operation as a valid CoAP port for the targeted multicast group. o All CoAP multicast requests SHOULD operate only on URIs (links) which were /s retreived /s retrieved either from a "/.well-known/core" lookup on at least one group member node, or from an equivalent service discovery lookup which returns either the resources supported by all group members or resources supported by one particular group member. /comment so setting a multicast address in a source at installation is forbidden? 3.5. Configuring Group Membership In Endpoints In some use cases, the group membership of endpoints needs to be configurable after the network has been deployed. Example use cases can be found in building control: a commissioning tool determines to which groups a light or sensor node belongs, and writes this information to all nodes, which can subsequently join the correct group. To achieve smoother interoperability between nodes/endpoints from different manufacturers, it is proposed here to define an OPTIONAL standardized RESTful means of configuring CoAP endpoints with relevant group information. CoAP endpoints implementing this mechanism MUST support a discoverable "Group Configuration" resource of resource type (rt) [RFC6690] "core.gp". This resource (and perhaps its sub-resources, TBD) are used to manage group membership. Three design options for this mechanism are presented here as a placeholder (TBD). Design 1: use CoRE link format payloads to communicate group membership to endpoints. (TBD Not clear how this should be realized.) /comment, not clear what you mean either. Remove design 1 in this state Design 2: use a JSON type resource. For example, a GET on the "core.gp" resource returns a JSON array of group objects. Req: GET /gp Res: 2.05 Content (Content-Format: application/json) [ { "n": "Room-A-Lights.floor1.west.bldg6.example.com", "ip": "ff05::4200:f7fe:ed37:14ca" } ] where "n" defines the Group FQDN and "ip" defines the associated multicast IP address. As a next example, the same endpoint can be Rahman & Dijk Expires April 22, 2013 [Page 8] Internet-Draft Group Communication for CoAP October 2012 added to another group by a POST on the resource with a JSON group object: Req: POST /gp (Content-Format: application/json) { "n": "floor1.west.bldg6.example.com", "ip": "ff05::4200:f7fe:ed37:14cb" } Res: 2.04 Changed Design 3: define named sub-resources, each sub-resource representing a group membership. The payload of the sub-resource may be JSON or a simple pre-defined format. Or alternatively, information is provided via POST with query parameters. /comment are these mutually exclusive designs? /comment design 2 without JSON is als possible /comment design with SRV and TXt records is also possible /comment there are 2 ways: (1) the node queries to which group it belongs /comment (2) an instalation tools instructs the node to which groups it belongs /comment not clear in text that this choice exists or that a choice was made. 3.6. Congestion Control Multicast CoAP requests may result in a multitude of replies from different nodes, potentially causing congestion. Therefore sending multicast /s requests /s replies should be conservatively controlled. The base CoAP draft [I-D.ietf-core-coap] reduces multicast-specific congestion risks through the following measures: o A server MAY choose not to respond to a multicast request if there's nothing useful to respond (e.g. error or empty response). o A server SHOULD limit the support for multicast requests to specific resources where multicast operation is required. o A multicast request MUST be Non-Confirmable. /comment what about the reply? o A server does not respond immediately to a multicast request, but SHOULD first wait for a time that is randomly picked within a predetermined time interval called the Leisure. o A server SHOULD NOT accept multicast requests that can not be authenticated. /comment invoking as many certificates? Additional guidelines to reduce congestion risks are: o A server in an LLN should only support multicast GET for resources that are small, e.g. /remove for an LLN that could mean the payload of the response fits into a single link-layer frame. o A server can minimize the payload length in response to a multicast GET on "/.well-known/core" by using hierarchy in arranging link descriptions for the response. An example of this is given in Section 5 of [RFC6690]. Rahman & Dijk Expires April 22, 2013 [Page 9] Internet-Draft Group Communication for CoAP October 2012 o Preferably IP multicast with link-local scope should be used, rather than global or site-local. o The Hop Limit field in the IPv6 packet should be chosen as low as possible (if the CoAP/IP stack allows setting of this value. TBD - discuss whether this guideline is relevant/realistic in CoAP context) 3.7. CoAP Multicast and HTTP Unicast Interworking /comment a reference will suffice CoAP supports operation over UDP multicast, while HTTP does not. For use cases where it is required that CoAP group communication is initiated from an HTTP end-point, it would be advantageous if the HTTP-CoAP Proxy supports mapping of HTTP unicast to CoAP group communication based on IP multicast. /remove One possible way of operation /remove of such HTTP-CoAP Proxy is illustrated in Figure 1. Note that this topic is covered in more detail in [I-D.castellani-core-advanced-http-mapping]. /remove CoAP Mcast CoAP Mcast HTTP-CoAP HTTP Node 1 Rtr1 Node 2 Rtr2 Proxy Node 3 | | | | | | |MLD REQUEST | | | | |(Join Group X) | | | | |--LL-->| | | | | | | |MLD REQUEST | | | | |(Join Group X) | | | | |--LL-->| | | | | | | | HTTP REQUEST | | | | | | (URI to | | | | | | unicast addr) | | | | | |< -----------------| | | | | | | | | | Resolve HTTP Request-Line URI | | | | to Group X multicast address | | | | | | | | CoAP REQUEST (to multicast addr)| | |< ------<---------<-------<------| | | | | | | | | | | | | (optional) CoAP RESPONSE(s) | | | |-------------->| | |-----------------|-------------->| Aggregated | | | | HTTP RESPONSE | | | |------------------>| | | | | Rahman & Dijk Expires April 22, 2013 [Page 10] Internet-Draft Group Communication for CoAP October 2012 Figure 1: CoAP Multicast and HTTP Unicast Interworking Note that Figure 1 illustrates the case of IP multicast as the underlying group communications mechanism. MLD denotes the Multicast Listener Discovery protocol ([RFC3810], Appendix A) and LL denotes a Link-Local multicast. A key point in Figure 1 is that the incoming HTTP Request (from node 3) will carry a Host request-header field that resolves in the general Internet to the proxy node. At the proxy node, this hostname and/or the Request-Line URI will then possibly be mapped (as detailed in [I-D.castellani-core-http-mapping]) and again resolved (with the CoAP scheme) to an IP multicast address. This may be accomplished, for example, by using DNS or DNS-SD (Section 3.3). The proxy node will then IP multicast the CoAP Request (corresponding to the received HTTP Request) via multicast routers to the appropriate nodes (i.e. nodes 1 and 2). In terms of the HTTP Response, Figure 1 illustrates that it will be generated by the proxy node based on aggregated responses of the CoAP nodes and sent back to the client in the general Internet that sent the HTTP Request (i.e. node 1). In [I-D.castellani-core-advanced-http-mapping] the HTTP Response that the Proxy may use to aggregate multiple CoAP responses is described in more detail. So in terms of overall operation, the CoAP proxy can be considered to be a "non-transparent" proxy according to [RFC2616]. Specifically, [RFC2616] states that a "non-transparent proxy is a proxy that modifies the request or response in order to provide some added service to the user agent, such as group annotation services, media type transformation, protocol reduction or anonymity filtering." An alternative to the above is using a Forward Proxy. In this case, the CoAP request URI is carried in the HTTP Request-Line (as defined in [I-D.ietf-core-coap] Section 10.2) in a HTTP request sent to the IP address of the Proxy. /end remove 4. Use Cases and Corresponding Protocol Flows 4.1. Introduction The use of CoAP group communication is shown in the context of the following use cases and corresponding protocol flows: o Discovery of Resource Directory: discovering the local CoRE RD which contains links (URIs) to resources stored on other servers [RFC6690]. Rahman & Dijk Expires April 22, 2013 [Page 11] Internet-Draft Group Communication for CoAP October 2012 o Lighting Control: synchronous operation of a group of 6LoWPAN [RFC4944] IPv6-connected lights o Parameter Update: updating parameters/settings simultaneously in a large group of devices in a building/campus control ([I-D.vanderstok-core-bc]) application --- TBD / comment I suggest to remove Firmware Update and Groups status report /comment the ones above are difficult enough, and I doubt that simultaneity /comment (motivation of multicast) is involved here o Firmware Update: efficiently updating firmware simultaneously in a large group of devices in a building/campus control ([I-D.vanderstok-core-bc]) application --- TBD suggests a multicast extension of core-block. o Group Status Report: requesting status information or event reports from a group of devices in a building/campus control application --- TBD, may require reliable group communication to be feasible. 4.2. Network Configuration We assume the following network configuration for all the use cases as shown in Figure 2: /comment the configurations frighten me /comment from completeness considerations I can imagine even more complex ones /comment It might be useful if the practical impossibility of some configurations is high lighted o A large room (Room-A) with three lights (Light-1, Light-2, Light-3) controlled by a Light Switch. The devices are organized into two 6LoWPAN subnets. /comment one subnet is enough for me /remove o Light-1 and the Light Switch are connected to a router (Rtr-1) which is also a CoAP Proxy, a CoAP Resource Directory (RD) and a 6LoWPAN Border Router (6LBR). o Light-2 and the Light-3 are connected to another router (Rtr-2) which is also a CoAP Proxy, a CoAP RD and a 6LBR. o The routers are connected to an IPv6 network backbone which is also multicast enabled. In the general case, this means the network backbone and 6LBRs support a PIM based multicast routing protocol, and MLD for forming groups. In a limited case, if the network backbone is one link, then the routers only have to support MLD-snooping (Appendix A) for the following use cases to work. /end remove /comment I can imagine that an central control is present on the backbone /comment switch or sensor send unicast to central control /comment central control sends multicast to multicast group within single lowpan Rahman & Dijk Expires April 22, 2013 [Page 12] Internet-Draft Group Communication for CoAP October 2012 Network Backbone | ################################################ | # Room-A # | # ********************** # | # ** LoWPAN-1 (subnet-1) ** # | # * * # | # * +----------+ * # | # * | Light |-------+ * # | # * | Switch | | * # | # * +----------+ +---------+ * # | # * | Rtr-1 |-----------------------------| # * +---------+ * # | # * +----------+ | * # | # * | Light-1 |--------+ * # | # * +----------+ * # | # * * # | # ** ** # | # ********************** # | # # | # # | # ********************** # | # ** LoWPAN-2 (subnet-2) ** # | # * * # | # * +----------+ * # | # * | Light-2 |-------+ * # | # * | | | * # | # * +----------+ +---------+ * # | # * | Rtr-2 |-----------------------------| # * +---------+ * # | # * +----------+ | * # | # * | Light-3 |--------+ * # | # * +----------+ * # | # * * # | # ** ** # | # ********************** # | # # | ################################################# | | +--------+ | | DNS |------------------| | Server | +--------+ Figure 2: Network Topology of a Large Room (Room-A) Rahman & Dijk Expires April 22, 2013 [Page 13] Internet-Draft Group Communication for CoAP October 2012 4.3. Discovery of Resource Directory The protocol flow for discovery of a RD for the given network (of Figure 2) is shown in Figure 3: o The fixture for Light-2 is installed and powered on for the first time. o Light-2 will then search for the local RD (RD-2) by sending out a GET request (with the "/.well-known/core?rt=core.rd" request URI) to the site-local "All CoAP Nodes" address. In this case, the site is assumed to include all nodes in the subnet. o This multicast message will then go to each node in subnet-2. However, only Rtr-2 (RD-2) will respond because the GET is qualified by the query string "?rt=core.rd". o Note that the flow is shown only for Light-2 for clarity. Similar flows will happen for Light-1, Light-3 and the Light Switch when they are first powered on. The RD may also be discovered by other means such as by assuming a default location (e.g. on a 6LBR), using DHCP, anycast address, etc. However, these approaches do not invoke CoAP group communication so are not further discussed here. For other discovery use cases such as discovering local CoAP servers, services or resources group communication can be used in a similar fashion as in the above use case. Both Link-Local (LL) and site- local discovery are possible this way. /comment the RD discovery will be more complex when there is a router between light-2 and switch /comment Via which RD will light switch discover light-2? /comment additional reason to remove router from the multicast configuration Rahman & Dijk Expires April 22, 2013 [Page 14] Internet-Draft Group Communication for CoAP October 2012 Light Rtr-1 Rtr-2 Network Light-1 Light-2 Light-3 Switch (RD-1) (RD-2) Backbone | | | | | | | | | | | | | | ********************************** | | | * Light-2 is installed * | | | * and powers on for first time * | | | ********************************** | | | | | | | | | | | | | | | | | | | COAP NON (GET | | | | /.well-known/core?rt=core.rd) | | | |--------->-------------------------------->| | | | | | | | | | | | | | | | | | | | | | | | | COAP NON (2.05 Content | | | | ;rt="core.rd";ins="Primary") | | | |<------------------------------------------| | | | | | | | | Figure 3: Resource Directory Discovery via Multicast Message 4.4. Lighting Control /comment I am confused about the use of protocols /comment MLD is used to form groups, correct? /comment but that was already done by enabling the MC address in the lights (point 2) /comment There are several ways to set up groups, pointing them out and when to use them would be an asset. The protocol flow for a building automation lighting control scenario for the network (Figure 2) is shown in sequence in Figure 4, Figure 5, and Figure 6. We assume the following steps occur before the illustrated flow: o 1) Startup phase: 6LoWPANs are formed. IPv6 addresses assigned to all devices. The CoAP network is formed. o 2) Commissioning phase (by applications): The IP multicast address of the group (Room-A-Lights) has been /s set /s enable in all the Lights. The URI of the group (Room-A-Lights) has been /s set /s resolved in the Light Switch. o 3) The indicated MLD Report messages are link-local multicast. In each LoWPAN, it is assumed that a multicast routing/forwarding protocol in 6LRs will then propagate the Join information contained in the MLD Report over multiple hops to the 6LBR. /comment Don't see the need Rahman & Dijk Expires April 22, 2013 [Page 15] Internet-Draft Group Communication for CoAP October 2012 Light Rtr-1 Rtr-2 Network Light-1 Light-2 Light-3 Switch (CoAP (CoAP Backbone | | | | Proxy) Proxy) | | | | | | | | | | | | | | | | MLD Report: Join | | | | | | Group (Room-A-Lights) | | | | |---LL------------------------------------->| | | | | | | |MLD Report: Join | | | | | |Group (Room-A-Lights)| | | | | |---LL--------------->| | | | | | | | | | MLD Report: Join | | | | | | Group (Room-A-Lights) | | | | |---LL------------------------------------->| | | | | | | | | | | | MLD Report: Join | | | | | | Group (Room-A-Lights) | | | | |---LL-------------------------->| | | | | | | | | | | | | |MLD Report: Join | | | | | |Group (Room-A-Lights)| | | | | | |---LL---->| | | | | | | | | | | | | | | Figure 4: Joining Lighting Groups Using MLD /comment possibly remove from text, or do separate section on use of MLD /comment anyway separating commissioning from operation in separate sections is a good idea. /comment the proxies are a complication in the picture not elaborated in the text. /comment the subject of proxies is another one, to be treated elsewhere. /comment also for proxies the do's and don't's from a simple performance perspective will be interesting Rahman & Dijk Expires April 22, 2013 [Page 16] Internet-Draft Group Communication for CoAP October 2012 Light Rtr-1 Rtr-2 Network Light-1 Light-2 Light-3 Switch (CoAP (CoAP Backbone | | | | Proxy) Proxy) | | | | | | | | | | *********************** | | | | * User flips on * | | | | * light switch to * | | | | * turn on all the * | | | | * lights in Room A * | | | | *********************** | | | | | | | | | | | | | | | | | | | COAP NON (PUT | | | | | | Proxy-URI | | | | | | URI for Room-A-Lights | | | | Payload=turn on lights) | | | | |--------->| | | | | | | | | | | | | | | | | | | | | Request DNS resolution of | | | | | URI for Room-A-Lights | | | | | |-------------------->| | | | | | | | | | | | | | | | | | | DNS returns: AAAA | | | | | Group (Room-A-Lights) | | | | | IPv6 multicast address | | | | | |<--------------------| | | | | | | | | | | | | | | | | | COAP NON (Put | | | | | URI Path | | | | | Payload=turn on lights)| | | | | Destination IP Address = | | | | | IP multicast address | | | | | for Group (Room-A-Lights)| | | | | Originating IP Address = | | | | | RTR-1 | | | | | |-------------------->| |<------------------------------------------| | | | | | | | | | | | | | | |<---------| | |<---------|<-------------------------------| | | | | | | | | | | | | | | | Figure 5: Sending Lighting Control Multicast Message Rahman & Dijk Expires April 22, 2013 [Page 17] Internet-Draft Group Communication for CoAP October 2012 Light Rtr-1 Rtr-2 Network Light-1 Light-2 Light-3 Switch (CoAP (CoAP Backbone | | | | Proxy) Proxy) | | | | | | | | *********************** | | | | * Lights in Room-A * | | | | * turn on (nearly * | | | | * simultaneously) * | | | | *********************** | | | | | | | | | | | | | | | | | | | COAP NON (2.04 Changed) | | | | |------------------------------------------>| | | | | | | | | | | | | | | | | | COAP NON (2.04 Changed) | | | | |------------------------------->| | | | | | | | | | | | | | | | | | | COAP NON (5.00 Internal Server Error) | | | |-------------------->| | | | | | | | | | | | | ****************************** | | | | * Rtr-1 as CoAP Proxy * | | | | * | sends the individual * | | | | * | responses back to * | | | | * v originator * | | | | ****************************** | | | | | | | | | | | COAP NON (2.04 Changed) | | | | | |<---------| | | | | | | | | | | | | COAP NON (2.04 Changed) | | | | | |<---------| | | | | | | | | | | | | COAP NON (5.00 Internal Server Error) | | | | |<---------| | | | | | | | | | Figure 6: Sending Lighting Control Response to Multicast Message NOTE: In the last step of Figure 6, Rtr-1 acting as CoAP proxy, returns multiple individual CoAP responses to the client. Each response echoes the Token of the client's request. The client can identify the original source of each response by ...TBD. /comment WHY are the multicast destinations sending back results? /comment I thought that you wanted MC messages to be non confirmable /comment sending responses seems to contradict this . /comment please remove sending back of responses. /comment one may assume that the MC algorithm within the lowpan is reliable (all destinations receive the message) /comment anyway MPL comes close enough to the reliability requirement given a specifiable range of configurations ___________________________________________________________________________________________________________________________ -- Peter van der Stok mailto: consultancy@vanderstok.org www: www.vanderstok.org tel NL: +31(0)492474673 F: +33(0)966015248 From trac+core@trac.tools.ietf.org Wed Dec 19 02:39:54 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2A9321F874E for ; Wed, 19 Dec 2012 02:39:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oj5OcIseAxUR for ; Wed, 19 Dec 2012 02:39:51 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id 08BAA21F86C1 for ; Wed, 19 Dec 2012 02:39:49 -0800 (PST) Received: from localhost ([127.0.0.1]:38965 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1TlH3x-00048p-Ep; Wed, 19 Dec 2012 11:39:45 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "core issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-core-groupcomm@tools.ietf.org, esko.dijk@philips.com X-Trac-Project: core Date: Wed, 19 Dec 2012 10:39:45 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/272 Message-ID: <060.e22050c25e6695b44ba9a92bbe2d195f@trac.tools.ietf.org> X-Trac-Ticket-ID: 272 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-core-groupcomm@tools.ietf.org, esko.dijk@philips.com, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: akbar.rahman@interdigital.com, esko.dijk@philips.com Resent-Message-Id: <20121219103951.08BAA21F86C1@ietfa.amsl.com> Resent-Date: Wed, 19 Dec 2012 02:39:49 -0800 (PST) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: [core] #272: Indicate that use of DNS is optional X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Reply-To: trac+core@trac.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2012 10:39:55 -0000 #272: Indicate that use of DNS is optional Indicate that use of DNS is optional, as discussed during WG meeting. Basic operation (e.g. often applied in LLN case) will be applications generating CoAP URIs which contain IP multicast literal addresses, instead of symbolic hostnames. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core- esko.dijk@philips.com | groupcomm@tools.ietf.org Type: task | Status: new Priority: minor | Milestone: Component: groupcomm | Version: Severity: - | Keywords: -------------------------+------------------------------------------------- Ticket URL: core From trac+core@trac.tools.ietf.org Wed Dec 19 02:43:35 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBFB421F84F5 for ; Wed, 19 Dec 2012 02:43:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uv-6Ef8ebGJM for ; Wed, 19 Dec 2012 02:43:35 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id A4ED021F84E9 for ; Wed, 19 Dec 2012 02:43:31 -0800 (PST) Received: from localhost ([127.0.0.1]:39334 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1TlH7a-0002fr-9G; Wed, 19 Dec 2012 11:43:30 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "core issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-core-groupcomm@tools.ietf.org, esko.dijk@philips.com X-Trac-Project: core Date: Wed, 19 Dec 2012 10:43:30 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/269#comment:1 Message-ID: <075.7b6f956b9a3c9d15c875a07eee5485bb@trac.tools.ietf.org> References: <060.8ab7b5fefbf91c487b2e2fb81b566755@trac.tools.ietf.org> X-Trac-Ticket-ID: 269 In-Reply-To: <060.8ab7b5fefbf91c487b2e2fb81b566755@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-core-groupcomm@tools.ietf.org, esko.dijk@philips.com, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: akbar.rahman@interdigital.com, esko.dijk@philips.com Resent-Message-Id: <20121219104332.A4ED021F84E9@ietfa.amsl.com> Resent-Date: Wed, 19 Dec 2012 02:43:31 -0800 (PST) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: Re: [core] #269: Simplify light switch use case and conform better to current practice X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Reply-To: trac+core@trac.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2012 10:43:35 -0000 #269: Simplify light switch use case and conform better to current practice Changes (by esko.dijk@philips.com): * status: new => closed * resolution: => fixed Comment: Done in upcoming groupcomm-04 -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core- esko.dijk@philips.com | groupcomm@tools.ietf.org Type: task | Status: closed Priority: major | Milestone: Component: groupcomm | Version: Severity: - | Resolution: fixed Keywords: | -------------------------+------------------------------------------------- Ticket URL: core From trac+core@trac.tools.ietf.org Wed Dec 19 02:44:04 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD4C321F84F5 for ; Wed, 19 Dec 2012 02:44:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xs2suyO9xjYo for ; Wed, 19 Dec 2012 02:44:04 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id E459721F8790 for ; Wed, 19 Dec 2012 02:44:03 -0800 (PST) Received: from localhost ([127.0.0.1]:39355 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1TlH84-0005j3-En; Wed, 19 Dec 2012 11:44:00 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "core issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-core-groupcomm@tools.ietf.org, esko.dijk@philips.com X-Trac-Project: core Date: Wed, 19 Dec 2012 10:44:00 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/270#comment:1 Message-ID: <075.c87b6d138f29670fecb95a02684d0488@trac.tools.ietf.org> References: <060.4d32ad6bbe014b849584fa7214427f14@trac.tools.ietf.org> X-Trac-Ticket-ID: 270 In-Reply-To: <060.4d32ad6bbe014b849584fa7214427f14@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-core-groupcomm@tools.ietf.org, esko.dijk@philips.com, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: akbar.rahman@interdigital.com, esko.dijk@philips.com Resent-Message-Id: <20121219104403.E459721F8790@ietfa.amsl.com> Resent-Date: Wed, 19 Dec 2012 02:44:03 -0800 (PST) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: Re: [core] #270: Remove section 3.7 CoAP Multicast and HTTP Unicast Interworking X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Reply-To: trac+core@trac.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2012 10:44:04 -0000 #270: Remove section 3.7 CoAP Multicast and HTTP Unicast Interworking Changes (by esko.dijk@philips.com): * priority: major => minor * status: new => closed * resolution: => fixed Comment: Done in upcoming groupcomm-04 -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core- esko.dijk@philips.com | groupcomm@tools.ietf.org Type: task | Status: closed Priority: minor | Milestone: Component: groupcomm | Version: Severity: - | Resolution: fixed Keywords: | -------------------------+------------------------------------------------- Ticket URL: core From trac+core@trac.tools.ietf.org Wed Dec 19 02:44:31 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26EAE21F87F2 for ; Wed, 19 Dec 2012 02:44:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C6PtKJoIKBRI for ; Wed, 19 Dec 2012 02:44:30 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id 980F521F8519 for ; Wed, 19 Dec 2012 02:44:30 -0800 (PST) Received: from localhost ([127.0.0.1]:39401 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1TlH8W-0006wi-It; Wed, 19 Dec 2012 11:44:28 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "core issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-core-groupcomm@tools.ietf.org, esko.dijk@philips.com X-Trac-Project: core Date: Wed, 19 Dec 2012 10:44:28 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/267#comment:1 Message-ID: <075.4fef139d5184c81efbf51b4548992978@trac.tools.ietf.org> References: <060.b17c5f6aeaebaf980758deeb31370eb6@trac.tools.ietf.org> X-Trac-Ticket-ID: 267 In-Reply-To: <060.b17c5f6aeaebaf980758deeb31370eb6@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-core-groupcomm@tools.ietf.org, esko.dijk@philips.com, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: akbar.rahman@interdigital.com, esko.dijk@philips.com Resent-Message-Id: <20121219104430.980F521F8519@ietfa.amsl.com> Resent-Date: Wed, 19 Dec 2012 02:44:30 -0800 (PST) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: Re: [core] #267: To remove Appendix B (CoAP-Observe Alternative to Group Communications) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Reply-To: trac+core@trac.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2012 10:44:31 -0000 #267: To remove Appendix B (CoAP-Observe Alternative to Group Communications) Changes (by esko.dijk@philips.com): * status: new => closed * resolution: => fixed Comment: Done in upcoming groupcomm-04 -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core- esko.dijk@philips.com | groupcomm@tools.ietf.org Type: task | Status: closed Priority: minor | Milestone: Component: groupcomm | Version: Severity: - | Resolution: fixed Keywords: | -------------------------+------------------------------------------------- Ticket URL: core From trac+core@trac.tools.ietf.org Wed Dec 19 02:44:56 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84CB921F8790 for ; Wed, 19 Dec 2012 02:44:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sd+SP0LNmqCm for ; Wed, 19 Dec 2012 02:44:56 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id EA19221F8519 for ; Wed, 19 Dec 2012 02:44:55 -0800 (PST) Received: from localhost ([127.0.0.1]:39407 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1TlH8v-00060X-PZ; Wed, 19 Dec 2012 11:44:53 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "core issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-core-groupcomm@tools.ietf.org, esko.dijk@philips.com X-Trac-Project: core Date: Wed, 19 Dec 2012 10:44:53 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/266#comment:1 Message-ID: <075.8071aff60b1bbfc410330a77e8db42c8@trac.tools.ietf.org> References: <060.7de3ddd23edb8884ed9d72e8d12fcdcb@trac.tools.ietf.org> X-Trac-Ticket-ID: 266 In-Reply-To: <060.7de3ddd23edb8884ed9d72e8d12fcdcb@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-core-groupcomm@tools.ietf.org, esko.dijk@philips.com, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: akbar.rahman@interdigital.com, esko.dijk@philips.com Resent-Message-Id: <20121219104455.EA19221F8519@ietfa.amsl.com> Resent-Date: Wed, 19 Dec 2012 02:44:55 -0800 (PST) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: Re: [core] #266: Remove section 2.3 (Potential Solutions for Group Communications) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Reply-To: trac+core@trac.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2012 10:44:56 -0000 #266: Remove section 2.3 (Potential Solutions for Group Communications) Changes (by esko.dijk@philips.com): * status: new => closed * resolution: => fixed Comment: Done in upcoming groupcomm-04 -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core- esko.dijk@philips.com | groupcomm@tools.ietf.org Type: task | Status: closed Priority: minor | Milestone: Component: groupcomm | Version: Severity: - | Resolution: fixed Keywords: | -------------------------+------------------------------------------------- Ticket URL: core From trac+core@trac.tools.ietf.org Wed Dec 19 02:45:16 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0B4C21F894D for ; Wed, 19 Dec 2012 02:45:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id osMBwsuGvld1 for ; Wed, 19 Dec 2012 02:45:16 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id 1441121F87F2 for ; Wed, 19 Dec 2012 02:45:16 -0800 (PST) Received: from localhost ([127.0.0.1]:39449 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1TlH9G-00024q-1u; Wed, 19 Dec 2012 11:45:14 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "core issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-core-groupcomm@tools.ietf.org, esko.dijk@philips.com X-Trac-Project: core Date: Wed, 19 Dec 2012 10:45:14 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/268#comment:1 Message-ID: <075.b1f1fccc7e055b5f8c0e7fbe99db0ba9@trac.tools.ietf.org> References: <060.41d11bcf9b7217f89a4f805a946b95e4@trac.tools.ietf.org> X-Trac-Ticket-ID: 268 In-Reply-To: <060.41d11bcf9b7217f89a4f805a946b95e4@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-core-groupcomm@tools.ietf.org, esko.dijk@philips.com, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: akbar.rahman@interdigital.com, esko.dijk@philips.com Resent-Message-Id: <20121219104516.1441121F87F2@ietfa.amsl.com> Resent-Date: Wed, 19 Dec 2012 02:45:16 -0800 (PST) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: Re: [core] #268: To remove current section 8 (Conclusions) text X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Reply-To: trac+core@trac.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2012 10:45:16 -0000 #268: To remove current section 8 (Conclusions) text Changes (by esko.dijk@philips.com): * status: new => closed * resolution: => fixed Comment: Done in upcoming groupcomm-04 -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core- esko.dijk@philips.com | groupcomm@tools.ietf.org Type: task | Status: closed Priority: minor | Milestone: Component: groupcomm | Version: Severity: - | Resolution: fixed Keywords: | -------------------------+------------------------------------------------- Ticket URL: core From trac+core@trac.tools.ietf.org Wed Dec 19 02:46:09 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F268921F87C7 for ; Wed, 19 Dec 2012 02:46:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vwfaIx4gyAWK for ; Wed, 19 Dec 2012 02:46:08 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id 63E8321F8790 for ; Wed, 19 Dec 2012 02:46:08 -0800 (PST) Received: from localhost ([127.0.0.1]:39487 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1TlHA6-0001lI-FU; Wed, 19 Dec 2012 11:46:06 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "core issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-core-groupcomm@tools.ietf.org, esko.dijk@philips.com X-Trac-Project: core Date: Wed, 19 Dec 2012 10:46:06 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/272#comment:1 Message-ID: <075.65accfe1de03a8e8503709666313eccb@trac.tools.ietf.org> References: <060.e22050c25e6695b44ba9a92bbe2d195f@trac.tools.ietf.org> X-Trac-Ticket-ID: 272 In-Reply-To: <060.e22050c25e6695b44ba9a92bbe2d195f@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-core-groupcomm@tools.ietf.org, esko.dijk@philips.com, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: akbar.rahman@interdigital.com, esko.dijk@philips.com Resent-Message-Id: <20121219104608.63E8321F8790@ietfa.amsl.com> Resent-Date: Wed, 19 Dec 2012 02:46:08 -0800 (PST) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: Re: [core] #272: Indicate that use of DNS is optional X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Reply-To: trac+core@trac.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2012 10:46:09 -0000 #272: Indicate that use of DNS is optional Changes (by esko.dijk@philips.com): * status: new => closed * resolution: => fixed Comment: Done in upcoming groupcomm-04 -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core- esko.dijk@philips.com | groupcomm@tools.ietf.org Type: task | Status: closed Priority: minor | Milestone: Component: groupcomm | Version: Severity: - | Resolution: fixed Keywords: | -------------------------+------------------------------------------------- Ticket URL: core From esko.dijk@philips.com Wed Dec 19 05:24:51 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38BF521F8AE7 for ; Wed, 19 Dec 2012 05:24:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=x tagged_above=-999 required=5 tests=[] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ID4ZzqIou-Oz for ; Wed, 19 Dec 2012 05:24:51 -0800 (PST) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe002.messaging.microsoft.com [216.32.180.12]) by ietfa.amsl.com (Postfix) with ESMTP id CEC0F21F87B1 for ; Wed, 19 Dec 2012 05:24:49 -0800 (PST) Received: from mail234-va3-R.bigfish.com (10.7.14.242) by VA3EHSOBE009.bigfish.com (10.7.40.29) with Microsoft SMTP Server id 14.1.225.23; Wed, 19 Dec 2012 13:24:48 +0000 Received: from mail234-va3 (localhost [127.0.0.1]) by mail234-va3-R.bigfish.com (Postfix) with ESMTP id C35C67C0175; Wed, 19 Dec 2012 13:24:48 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.55.7.222; KIP:(null); UIP:(null); IPV:NLI; H:mail.philips.com; RD:none; EFVD:NLI X-SpamScore: 0 X-BigFish: VPS0(zzzz1de0h1202h1e76h1d1ah1d2ahzzz2dh2a8h668h839hd25hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh15d0h162dh1631h1758h1155h) Received: from mail234-va3 (localhost.localdomain [127.0.0.1]) by mail234-va3 (MessageSwitch) id 1355923485850673_21954; Wed, 19 Dec 2012 13:24:45 +0000 (UTC) Received: from VA3EHSMHS004.bigfish.com (unknown [10.7.14.254]) by mail234-va3.bigfish.com (Postfix) with ESMTP id C6B5C380074; Wed, 19 Dec 2012 13:24:45 +0000 (UTC) Received: from mail.philips.com (157.55.7.222) by VA3EHSMHS004.bigfish.com (10.7.99.14) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 19 Dec 2012 13:24:44 +0000 Received: from 011-DB3MPN2-082.MGDPHG.emi.philips.com ([169.254.2.225]) by 011-DB3MMR1-008.MGDPHG.emi.philips.com ([10.128.28.47]) with mapi id 14.02.0318.003; Wed, 19 Dec 2012 13:24:42 +0000 From: "Dijk, Esko" To: "consultancy@vanderstok.org" , akbar rahman , Core Thread-Topic: group-comm comments Thread-Index: AQHN3Q/EamfaSRtiukaKyou8LL6fj5ggEhMA Date: Wed, 19 Dec 2012 13:24:42 +0000 Message-ID: <031DD135F9160444ABBE3B0C36CED618B39574@011-DB3MPN2-082.MGDPHG.emi.philips.com> References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.138.224.32] Content-Type: multipart/alternative; boundary="_000_031DD135F9160444ABBE3B0C36CED618B39574011DB3MPN2082MGDP_" MIME-Version: 1.0 X-OriginatorOrg: philips.com Subject: Re: [core] group-comm comments X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 19 Dec 2012 13:24:51 -0000 --_000_031DD135F9160444ABBE3B0C36CED618B39574011DB3MPN2082MGDP_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgUGV0ZXIsDQoNCnN0aWxsIGEgZmFpciBudW1iZXIgb2YgY29tbWVudHMhIEkgd291bGQgYWdy ZWUgd2l0aCBtb3N0LiBCZWxvdyBJIGhhdmUgc2VsZWN0ZWQgc29tZSB3aGljaCB3ZSBzaG91bGQg ZGlzY3VzcyBmdXJ0aGVyLCBvciBvbmVzIEkgZG9u4oCZdCBhZ3JlZSB3aXRoOg0KDQoNCg0KMS4g IEdyb3VwIGNvbW11bmljYXRpb24gZGVmaW5pdGlvbiAtPg0KV2h5IGNhbid0IGEgc291cmNlIG5v ZGUgYmUgcGFydCBvZiB0aGUgZ3JvdXAgdGhhdCBpdCBzZW5kcyB0bz8gRS5nLiBjb21iaW5lZCBz ZW5zb3IrbHVtaW5haXJlIHVzZSBjYXNlLiBUaGUgSVAgc3RhY2sgd291bGQgZGVsaXZlciBzZW50 IG11bHRpY2FzdCBDb0FQIHJlcXVlc3RzIGFsc28gdG8gdGhlIGxvY2FsIGFwcGxpY2F0aW9uIGlm IGl0IGlzIHN1YnNjcmliZWQgdG8gdGhlIG11bHRpY2FzdCBJUCBhZGRyZXNzLg0KDQoyLiAgSSBk b27igJl0IHNlZSB3aHkgd2Ugc2hvdWxkIGFkZCDigJx0aGUgdXNlIG9mIGdyb3VwIGNvbW11bmlj YXRpb24gZm9yIG1ETlMgaXMgb3V0IG9mIHNjb3BlLuKAnSAtPg0KbUROUyBvYnZpb3VzbHkgaXMg bm90IENvQVAsIGFuZCB0aGUgZG9jdW1lbnQgc2hvdWxkIGRlZmluZSB0aGUgc2NvcGUgYW55d2F5 IGNsZWFybHkgYXMgQ29BUCBncm91cCBjb21tdW5pY2F0aW9uLiBTbyB3ZSBkb27igJl0IGhhdmUg dG8gbGlzdCBhbnkgb3RoZXIgcHJvdG9jb2xzIHRoYW4gQ29BUC4NCg0KMy4gIOKAnHNvIHNldHRp bmcgYSBtdWx0aWNhc3QgYWRkcmVzcyBpbiBhIHNvdXJjZSBhdCBpbnN0YWxsYXRpb24gaXMgZm9y YmlkZGVuP+KAnSAtPg0KTm8sIHRoYXQgc2hvdWxkIG5vdCBiZSBmb3JiaWRkZW4gOikgIEl0IHNo b3VsZCBhbHNvIGJlIHBvc3NpYmxlIHRvIHNldCBhIENvQVAgcGF0aCBhbmQvb3IgcG9ydCBhdCBp bnN0YWxsYXRpb24gdGltZS4gVGhhdCBtZWFucyB0aGUgdHdvIHByZXNlbnRlZCBtZWFzdXJlcyBo YXZlIHRvIGNoYW5nZSBvciBiZSByZW1vdmVkLg0KDQo0LiAg4oCcdGhlcmUgYXJlIDIgd2F5czog KDEpIHRoZSBub2RlIHF1ZXJpZXMgdG8gd2hpY2ggZ3JvdXAgaXQgYmVsb25ncyBvciAoMikgYW4g aW5zdGFsYXRpb24gdG9vbHMgaW5zdHJ1Y3RzIHRoZSBub2RlIHRvIHdoaWNoIGdyb3Vwc+KAnSAt Pg0KR29vZCBwb2ludC4gKDIpIGhhcyBiZWVuIGNob3NlbiBiZWNhdXNlIGl0IHdvcmtzIHdpdGhv dXQgcmVseWluZyBvbiBhIHNlcnZpY2UgdG8gcXVlcnkgKGUuZy4gRE5TIG9yIFJEKS4gSXMgdGhh dCBzdWZmaWNpZW50IGFyZ3VtZW50YXRpb24/IFRoZSBtZWNoYW5pc20gaXMgb3B0aW9uYWwgaW4g YW55IGNhc2Ugc28gaXQgZG9lcyBub3QgYmxvY2sgb3RoZXJzIGZyb20gZGVmaW5pbmcgYSBETlMg b3IgUkQgdmFyaWFudC4NCg0KNS4gIOKAnC9zIHJlcXVlc3RzIC9zIHJlcGxpZXPigJ0gLT4NCm11 bHRpY2FzdCByZXBsaWVzIChpZiB5b3UgbWVhbiByZXNwb25zZXMpIGRvIG5vdCBleGlzdCBpbiBD b0FQLiBJdOKAmXMgYWJvdXQgcmVxdWVzdHMgdGhhdCBzaG91bGQgYmUgY2FyZWZ1bGx5IGNvbnRy b2xsZWQgc2luY2UgdGhleSBnZW5lcmF0ZSB1bmljYXN0IHJlc3BvbnNlcy4NCg0KNi4gIOKAnC9j b21tZW50IHdoYXQgYWJvdXQgdGhlIHJlcGx5P+KAnSAtPg0KYmFzZWQgb24gY29yZS1jb2FwIOKA nElmIHRoZSByZXF1ZXN0IG1lc3NhZ2UgaXMgTm9uLWNvbmZpcm1hYmxlLCB0aGVuIHRoZSByZXNw b25zZSBTSE9VTEQgYmUgcmV0dXJuZWQgaW4gYSBOb24tY29uZmlybWFibGUgbWVzc2FnZSBhcyB3 ZWxsLuKAnSAuIERvIHlvdSB0aGluayB3ZSBzaG91bGQgcXVvdGUgdGhpcyBmcm9tIHRoZSBjb3Jl LWNvYXAgc3BlYz8NCg0KNy4gIOKAnC9jb21tZW50IGludm9raW5nIGFzIG1hbnkgY2VydGlmaWNh dGVzP+KAnSAtPg0KY29yZS1jb2FwLTEzIG5vdyBsb29zZW5zIHRoZSBjb25jZXB0IG9mIGF1dGhl bnRpY2F0aW9uIHRvIGFsc28gaW5jbHVkZSBvdGhlciBtZWFzdXJlcywgbm90IG5lZWRpbmcgY2Vy dGlmaWNhdGVzLg0KDQo4LiAgTmV0d29yayBjb25maWd1cmF0aW9uOiAyIHN1Ym5ldHMgdnMgMSAt Pg0KbWF5YmUgYSBvbmUtc3VibmV0IGNvbmZpZ3VyYXRpb24gaXMgd29ydGggYWRkaW5nPyAgSGVy ZSBhbiBvdmVydmlldyBvZiBwcmVzZW50L2Fic2VudCB1c2UgY2FzZXM6DQoNCi0gTGluay1sb2Nh bCBDb0FQIG11bHRpY2FzdCB3aXRoIHJlc3BvbnNlczogUHJlc2VudCwgQXBwZW5kaXggQSBvZiBj b3JlLWNvYXANCi0gU2l0ZS1sb2NhbCBDb0FQIG11bHRpY2FzdCwgc2luZ2xlIHN1Ym5ldDogPG1p c3Npbmc+DQotIFNpdGUtbG9jYWwgQ29BUCBtdWx0aWNhc3QsIG11bHRpIHN1Ym5ldCwgd2l0aCBv ciB3aXRob3V0IHJlc3BvbnNlcyAoaW4gdGhlIG5ldyAtMDQgZ3JvdXBjb21tKTogUHJlc2VudA0K LSBHbG9iYWwgICAgIENvQVAgbXVsdGljYXN0LCBzaW5nbGUgb3IgbXVsdGkgc3VibmV0LCB3aXRo IG9yIHdpdGhvdXQgcmVzcG9uc2VzOiA8bWlzc2luZz4gLyBkZXBlbmRlbmN5IG9uIElBTkEgSVB2 NiBhbGxvY2F0aW9uDQotIGFueSBjb25maWd1cmF0aW9ucyB3aXRoIGEgY2VudHJhbCBjb250cm9s bGVyIG9uIHRoZSBiYWNrYm9uZSBtdWx0aWNhc3Rpbmc6IDxtaXNzaW5nPg0KDQoNCjkuICDigJxJ dCBtaWdodCBiZSB1c2VmdWwgaWYgdGhlIHByYWN0aWNhbCBpbXBvc3NpYmlsaXR5IG9mIHNvbWUg Y29uZmlndXJhdGlvbnMgaXMgaGlnaCBsaWdodGVk4oCdIC0+DQphbnkgdGhvdWdodHMsIHdoaWNo IHdvdWxkIGJlIGltcG9zc2libGU/DQoNCjEwLuKAnHRoZSBSRCBkaXNjb3Zlcnkgd2lsbCBiZSBt b3JlIGNvbXBsZXggd2hlbiB0aGVyZSBpcyBhIHJvdXRlciBiZXR3ZWVuIGxpZ2h0LTIgYW5kIHN3 aXRjaOKAnSAtPg0KeWVzLCB0aGVyZSBhcmUgaXNzdWVzIGluIFJEL2Rpc2NvdmVyeSBlc3BlY2lh bGx5IHdoZW4gbW9yZSB0aGFuIG9uZSBpcyBwcmVzZW50IGluIGEgbmV0d29yay4NCg0KMTEu4oCc YWRkaXRpb25hbCByZWFzb24gdG8gcmVtb3ZlIHJvdXRlciBmcm9tIHRoZSBtdWx0aWNhc3QgY29u ZmlndXJhdGlvbuKAnS0+DQpobW0sIEkgdGhpbmsgdGhhdCB3ZSBzaG91bGQgb3B0IGZvciBoYXZp bmcgYSBzaW5nbGUgUkQgaW4gdGhlIHN5c3RlbSB0byBhdm9pZCBjb21wbGV4aXR5LiBSb3V0ZXJz IGFyZSBvay4gKE9uZSBvZiBvdXIgZ29hbHMgaXMgdG8gZGVmaW5lIGhvdyBDb0FQIGdyb3VwY29t bSB3b3JrcyBldmVuIGFjcm9zcyByb3V0ZXJzKQ0KDQoxMi7igJxNTEQgaXMgdXNlZCB0byBmb3Jt IGdyb3VwcywgY29ycmVjdD8gYnV0IHRoYXQgd2FzIGFscmVhZHkgZG9uZSBieSBlbmFibGluZyB0 aGUgTUMgYWRkcmVzcyBpbiB0aGUgbGlnaHRzIChwb2ludCAyKeKAnSAtPg0KU3RlcCAxIGlzIHB1 dHRpbmcgdGhlIE1DIGFkZHJlc3MgaW4gdGhlIGxpZ2h0cywgdGhlbiBzdGVwIDIgaXMgdGhlIExp Z2h0cyB1c2UgTUxEIHRvICphZHZlcnRpemUqIHRoaXMgYWRkcmVzcyB0byBhbnkgTUxELWVuYWJs ZWQgUm91dGVycyBwcmVzZW50IGxpbmstbG9jYWwuDQpTbyBNTEQgaXMgbm90IGEgY29tbWlzc2lv bmluZy10aW1lIHByb3RvY29sIGJ1dCBydW5zIGFsbCB0aGUgdGltZSBkdXJpbmcgb3BlcmF0aW9u Lg0KTm90ZSB0aGF0IGluIGdyb3VwY29tbSAtMDQgd2Ugd2lsbCByZW1vdmUgTUxEIGluIHRoZSBi YXNpYyB1c2UgY2FzZSBhbmQgcHJlc2VudCBpdCBhcyBhbiBvcHRpb24gbGF0ZXIuDQoNCg0KDQox My7igJxXSFkgYXJlIHRoZSBtdWx0aWNhc3QgZGVzdGluYXRpb25zIHNlbmRpbmcgYmFjayByZXN1 bHRzP+KAnSAtPg0Kd2UgcmVtb3ZlIHJlc3BvbnNlcyBpbiB0aGUgbmV3IC0wNCBncm91cGNvbW0u IFRoZXkgYXJlIHByZXNlbnRlZCBhcyBhbiBvcHRpb25hbCB0aGluZyB0aGF0IHNlcnZlcnMgY2Fu IGRvLg0KQ29BUCBzZXJ2ZXJzIG5vcm1hbGx5IE1VU1QgcmVzcG9uZCB0byBhIHJlcXVlc3Qgd2l0 aCBhIHJlc3BvbnNlIChjb3JlLWNvYXAtMTMpIGJ1dCBhbiBleGNlcHRpb24gaXMgbm93IG1hZGUg Zm9yIG11bHRpY2FzdCB3aGVyZSBhIHNlcnZlciBNQVkgY2hvb3NlIG5vdCB0by4gVGhpcyBjaG9p Y2UgaXMgY29tcGxldGVseSBpbmRlcGVuZGVudCBmcm9tIGNvbmZpcm1hYmxlL25vbi1jb25maXJt YWJsZS4gTm9uLWNvbmZpcm1hYmxlIG9ubHkgbWVhbnMgdGhhdCBhbiBBQ0sgbXVzdCBub3QgYmUg c2VudC4gQW5kIGFuIEFDSyBpcyBzb21ldGhpbmcgZGlmZmVyZW50IGZyb20gYSBDb0FQIHJlc3Bv bnNlLg0KQWdyZWUgdGhhdCBhIHByb3RvY29sIGxpa2UgTVBMIGNvbWVzIHZlcnkgY2xvc2UgdG8g 4oCYcmVsaWFibGUgbXVsdGljYXN04oCZLg0KDQoNCg0KRXNrbw0KDQoNCg0KDQoNCg0KLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IHBldGVyIHZhbiBkZXIgU3RvayBbbWFpbHRvOnN0 b2tjb25zQHhzNGFsbC5ubF0NClNlbnQ6IFR1ZXNkYXkgMTggRGVjZW1iZXIgMjAxMiAxMjowNg0K VG86IGFrYmFyIHJhaG1hbjsgRGlqaywgRXNrbzsgQ29yZQ0KU3ViamVjdDogZ3JvdXAtY29tbSBj b21tZW50cw0KDQoNCg0KDQoNCkhpIEFrYmFyIGFuZCBFc2tvLA0KDQoNCg0KSSBoYWQgcHJvbWlz ZWQgdG8gcmV2aWV3LCBjb21tZW50IHRoZSBncm91cCBjb21tIGRyYWZ0Lg0KDQpCZWxvdyB0aGUg Y29tbWVudGVkIHRleHQuDQoNCg0KDQpJIGhhdmUgbm90IGdvbmUgdmVyeSBkZXRhaWxlZCB3aXRo IG15IGNvbW1lbnRzLiBJIGhvcGUgdGhhdCBpdCBpcyBjbGVhciBmcm9tICBteSBjb21tZW50cyB0 aGF0IGEgcmVvcmdhbml6YXRpb24gb2YgdGhlIGRyYWZ0IGFuZCBhIHJldmlldyBvZiB0aGUgdXNl cyBjYXNlcyBhcmUgbmVjZXNzYXJ5IHRvIGdldCBhIGNsZWFyZXIgcGljdHVyZSBvZiB0aGUgZmVh c2liaWxpdHkgb2YgZ3JvdXAgY29tbSBpbiB0aGUgY29udGV4dCBvZiBDb2FwLg0KDQoNCg0KRXNw ZWNpYWx5IGRpZmZpY3VsdCB0byB1bmRlcnN0YW5kIGZvciBtZSB3ZXJlOg0KDQoNCg0KLSB0aGUg dXNlIGNhc2UgbmV0d29yayBjb25maWd1cmF0aW9uDQoNCi0gdGhlIGZvcm1pbmcgYW5kIGVuYWJs aW5nIG9mIGdyb3Vwcw0KDQotIHVzZSBvZiByZXNwb25zZXMNCg0KDQoNCkhvcGUgdGhpcyBoZWxw cy4NCg0KDQoNCkdyZWV0aW5ncywNCg0KDQoNCnBldGVyDQoNCg0KDQpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpBYnN0cmFjdA0KDQoNCg0KICAgIENvQVAg aXMgYSBSRVNUZnVsIHRyYW5zZmVyIHByb3RvY29sIGZvciBjb25zdHJhaW5lZCBkZXZpY2VzLiAg SXQgaXMNCg0KICAgIGFudGljaXBhdGVkIHRoYXQgY29uc3RyYWluZWQgZGV2aWNlcyB3aWxsIG9m dGVuIG5hdHVyYWxseSBvcGVyYXRlIGluDQoNCiAgICBncm91cHMgKGUuZy4gaW4gYSBidWlsZGlu ZyBhdXRvbWF0aW9uIHNjZW5hcmlvIGFsbCBsaWdodHMgaW4gYSBnaXZlbg0KDQogICAgcm9vbSBt YXkgbmVlZCB0byBiZSBzd2l0Y2hlZCBvbi9vZmYgYXMgYSBncm91cCkuICBUaGlzIGRvY3VtZW50 DQoNCiAgICBkZWZpbmVzIGhvdyB0aGUgQ29BUCBwcm90b2NvbCBzaG91bGQgYmUgdXNlZCBpbiBh IGdyb3VwIGNvbW11bmljYXRpb24NCg0KICAgIGNvbnRleHQuICBBbiBhcHByb2FjaCBmb3IgdXNp bmcgQ29BUCBvbiB0b3Agb2YgSVAgbXVsdGljYXN0IGlzDQoNCiAgICBkZXRhaWxlZCBmb3IgYm90 aCBjb25zdHJhaW5lZCBhbmQgdW4tY29uc3RyYWluZWQgbmV0d29ya3MuICBBbHNvLA0KDQogICAg dmFyaW91cyB1c2UNCg0KL3MgY2F1c2VzIC9zIGNhc2VzLw0KDQogICAgYW5kIGNvcnJlc3BvbmRp bmcgcHJvdG9jb2wgZmxvd3MgYXJlIHByb3ZpZGVkIHRvDQoNCiAgICBpbGx1c3RyYXRlIGltcG9y dGFudCBjb25jZXB0cy4gIEZpbmFsbHksIGd1aWRhbmNlIGlzIHByb3ZpZGVkIGZvcg0KDQogICAg ZGVwbG95bWVudCBpbiB2YXJpb3VzIG5ldHdvcmsgdG9wb2xvZ2llcy4NCg0KDQoNClN0YXR1cyBv ZiB0aGlzIE1lbW8NCg0KDQoNCiAgICBUaGlzIEludGVybmV0LURyYWZ0IGlzIHN1Ym1pdHRlZCBp biBmdWxsIGNvbmZvcm1hbmNlIHdpdGggdGhlDQoNCiAgICBwcm92aXNpb25zIG9mIEJDUCA3OCBh bmQgQkNQIDc5Lg0KDQoNCg0KICAgIEludGVybmV0LURyYWZ0cyBhcmUgd29ya2luZyBkb2N1bWVu dHMgb2YgdGhlIEludGVybmV0IEVuZ2luZWVyaW5nDQoNCiAgICBUYXNrIEZvcmNlIChJRVRGKS4g IE5vdGUgdGhhdCBvdGhlciBncm91cHMgbWF5IGFsc28gZGlzdHJpYnV0ZQ0KDQogICAgd29ya2lu ZyBkb2N1bWVudHMgYXMgSW50ZXJuZXQtRHJhZnRzLiAgVGhlIGxpc3Qgb2YgY3VycmVudCBJbnRl cm5ldC0NCg0KICAgIERyYWZ0cyBpcyBhdCBodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZHJh ZnRzL2N1cnJlbnQvLg0KDQoNCg0KICAgIEludGVybmV0LURyYWZ0cyBhcmUgZHJhZnQgZG9jdW1l bnRzIHZhbGlkIGZvciBhIG1heGltdW0gb2Ygc2l4IG1vbnRocw0KDQogICAgYW5kIG1heSBiZSB1 cGRhdGVkLCByZXBsYWNlZCwgb3Igb2Jzb2xldGVkIGJ5IG90aGVyIGRvY3VtZW50cyBhdCBhbnkN Cg0KICAgIHRpbWUuICBJdCBpcyBpbmFwcHJvcHJpYXRlIHRvIHVzZSBJbnRlcm5ldC1EcmFmdHMg YXMgcmVmZXJlbmNlDQoNCiAgICBtYXRlcmlhbCBvciB0byBjaXRlIHRoZW0gb3RoZXIgdGhhbiBh cyAid29yayBpbiBwcm9ncmVzcy4iDQoNCg0KDQogICAgVGhpcyBJbnRlcm5ldC1EcmFmdCB3aWxs IGV4cGlyZSBvbiBBcHJpbCAyMiwgMjAxMy4NCg0KDQoNCkNvcHlyaWdodCBOb3RpY2UNCg0KDQoN CiAgICBDb3B5cmlnaHQgKGMpIDIwMTIgSUVURiBUcnVzdCBhbmQgdGhlIHBlcnNvbnMgaWRlbnRp ZmllZCBhcyB0aGUNCg0KICAgIGRvY3VtZW50IGF1dGhvcnMuICBBbGwgcmlnaHRzIHJlc2VydmVk Lg0KDQoNCg0KICAgIFRoaXMgZG9jdW1lbnQgaXMgc3ViamVjdCB0byBCQ1AgNzggYW5kIHRoZSBJ RVRGIFRydXN0J3MgTGVnYWwNCg0KICAgIFByb3Zpc2lvbnMgUmVsYXRpbmcgdG8gSUVURiBEb2N1 bWVudHMNCg0KICAgIChodHRwOi8vdHJ1c3RlZS5pZXRmLm9yZy9saWNlbnNlLWluZm8pIGluIGVm ZmVjdCBvbiB0aGUgZGF0ZSBvZg0KDQoNCg0KDQoNCg0KDQpSYWhtYW4gJiBEaWprICAgICAgICAg ICAgRXhwaXJlcyBBcHJpbCAyMiwgMjAxMyAgICAgICAgICAgICAgICAgW1BhZ2UNCg0KMV0NCg0K DQoNCg0KSW50ZXJuZXQtRHJhZnQgICAgICAgIEdyb3VwIENvbW11bmljYXRpb24gZm9yIENvQVAg ICAgICAgICAgT2N0b2Jlcg0KDQoyMDEyDQoNCg0KDQoNCg0KICAgIHB1YmxpY2F0aW9uIG9mIHRo aXMgZG9jdW1lbnQuICBQbGVhc2UgcmV2aWV3IHRoZXNlIGRvY3VtZW50cw0KDQogICAgY2FyZWZ1 bGx5LCBhcyB0aGV5IGRlc2NyaWJlIHlvdXIgcmlnaHRzIGFuZCByZXN0cmljdGlvbnMgd2l0aCBy ZXNwZWN0DQoNCiAgICB0byB0aGlzIGRvY3VtZW50LiAgQ29kZSBDb21wb25lbnRzIGV4dHJhY3Rl ZCBmcm9tIHRoaXMgZG9jdW1lbnQgbXVzdA0KDQogICAgaW5jbHVkZSBTaW1wbGlmaWVkIEJTRCBM aWNlbnNlIHRleHQgYXMgZGVzY3JpYmVkIGluIFNlY3Rpb24gNC5lIG9mDQoNCiAgICB0aGUgVHJ1 c3QgTGVnYWwgUHJvdmlzaW9ucyBhbmQgYXJlIHByb3ZpZGVkIHdpdGhvdXQgd2FycmFudHkgYXMN Cg0KICAgIGRlc2NyaWJlZCBpbiB0aGUgU2ltcGxpZmllZCBCU0QgTGljZW5zZS4NCg0KDQoNCg0K DQoxLiAgQ29udmVudGlvbnMgYW5kIFRlcm1pbm9sb2d5DQoNCg0KDQogICAgVGhlIGtleSB3b3Jk cyAiTVVTVCIsICJNVVNUIE5PVCIsICJSRVFVSVJFRCIsICJTSEFMTCIsICJTSEFMTCBOT1QiLA0K DQogICAgIlNIT1VMRCIsICJTSE9VTEQgTk9UIiwgIlJFQ09NTUVOREVEIiwgIk1BWSIsIGFuZCAi T1BUSU9OQUwiIGluIHRoaXMNCg0KICAgIGRvY3VtZW50IGFyZSB0byBiZSBpbnRlcnByZXRlZCBh cyBkZXNjcmliZWQgaW4gW1JGQzIxMTldLg0KDQoNCg0KICAgIFRoaXMgZG9jdW1lbnQgYXNzdW1l cyByZWFkZXJzIGFyZSBmYW1pbGlhciB3aXRoIHRoZSB0ZXJtcyBhbmQNCg0KICAgIGNvbmNlcHRz IHRoYXQgYXJlIHVzZWQgaW4gW0ktRC5pZXRmLWNvcmUtY29hcF0uICBJbiBhZGRpdGlvbiwgdGhp cw0KDQogICAgZG9jdW1lbnQgZGVmaW5lcyB0aGUgZm9sbG93aW5nIHRlcm1pbm9sb2d5Og0KDQoN Cg0KICAgIEdyb3VwIENvbW11bmljYXRpb24NCg0KICAgICAgIEEgc291cmNlIG5vZGUgc2VuZHMg YSBzaW5nbGUgbWVzc2FnZSB3aGljaCBpcyBkZWxpdmVyZWQgdG8NCg0KICAgICAgIG11bHRpcGxl IGRlc3RpbmF0aW9uIG5vZGVzLCB3aGVyZSBhbGwgZGVzdGluYXRpb25zIGFyZSBpZGVudGlmaWVk DQoNCiAgICAgICB0byBiZWxvbmcgdG8gYSBzcGVjaWZpYyBncm91cC4gIFRoZSBzb3VyY2Ugbm9k ZSBtYXkNCg0KL3JlbW92ZSBvciBtYXkgbm90DQoNCiAgICAgICBiZQ0KDQogICAgICAgcGFydCBv ZiB0aGUgZ3JvdXAuICBUaGUgdW5kZXJseWluZyBtZWNoYW5pc20gZm9yIGdyb3VwDQoNCiAgICAg ICBjb21tdW5pY2F0aW9uIGlzIGFzc3VtZWQgdG8gYmUgbXVsdGljYXN0IGJhc2VkLg0KDQovcmVt b3ZlDQoNCiAgICAgIFRoZSBuZXR3b3JrIHdoZXJlDQoNCiAgICAgICB0aGUgZ3JvdXAgY29tbXVu aWNhdGlvbiB0YWtlcyBwbGFjZSBjYW4gYmUgZWl0aGVyIGEgY29uc3RyYWluZWQNCg0Kb3INCg0K ICAgICAgIGEgcmVndWxhciAodW4tY29uc3RyYWluZWQpIG5ldHdvcmsvDQoNCi9jb21tZW50IG5v dCBzdXJlIGFib3V0IHRoZSBtZWFuaW5nIGFuZCBjb25zZXF1ZW5jZXMNCg0KDQoNCiAgICBNdWx0 aWNhc3QNCg0KICAgICAgIFNlbmRpbmcgYSBtZXNzYWdlIHRvIG11bHRpcGxlIGRlc3RpbmF0aW9u IG5vZGVzDQoNCi9zIHNpbXVsdGFuZW91c2x5Li8NCg0KL3Mgd2l0aCBvbmUgbmV0d29yayBpbnZv Y2F0aW9uIC8NCg0KDQoNCiAgICAgICBUaGVyZSBhcmUgdmFyaW91cyBvcHRpb25zIHRvIGltcGxl bWVudCBtdWx0aWNhc3QgaW5jbHVkaW5nIGxheWVyDQoNCjINCg0KICAgICAgIChNZWRpYSBBY2Nl c3MgQ29udHJvbCkgb3IgbGF5ZXIgMyAoSVApIG1lY2hhbmlzbXMuDQoNCg0KDQogICAgSVAgTXVs dGljYXN0DQoNCiAgICAgICBBIHNwZWNpZmljIG11bHRpY2FzdCBzb2x1dGlvbiBiYXNlZCBvbiB0 aGUgdXNlIG9mIElQIG11bHRpY2FzdA0KDQogICAgICAgYWRkcmVzc2VzIGFzIGRlZmluZWQgaW4g IklBTkEgR3VpZGVsaW5lcyBmb3IgSVB2NCBNdWx0aWNhc3QNCg0KICAgICAgIEFkZHJlc3MgQXNz aWdubWVudHMiIFtSRkM1NzcxXSBhbmQgIklQIFZlcnNpb24gNiBBZGRyZXNzaW5nDQoNCiAgICAg ICBBcmNoaXRlY3R1cmUiIFtSRkM0MjkxXS4NCg0KDQoNCiAgICBMb3cgcG93ZXIgYW5kIExvc3N5 IE5ldHdvcmsgKExMTikNCg0KICAgICAgIExvdyBwb3dlciBhbmQgTG9zc3kgTmV0d29yayAoTExO KTogQSB0eXBlIG9mIGNvbnN0cmFpbmVkIG5ldHdvcmsNCg0KICAgICAgIHdoZXJlIHRoZSBkZXZp Y2VzIGFyZSBpbnRlcmNvbm5lY3RlZCBieSBhIHZhcmlldHkgb2YgbG93IHBvd2VyLA0KDQogICAg ICAgbG9zc3kgbGlua3Mgc3VjaCBhcyBJRUVFIDgwMi4xNS40LCBCbHVldG9vdGgsDQoNCjxub3Qg c28gY29uc3RyYWluZWQ+IFdpRmksIHdpcmVkIDwvPg0KDQogICAgICBvciBsb3cNCg0KICAgICAg IHBvd2VyIHBvd2VyLWxpbmUgY29tbXVuaWNhdGlvbiBsaW5rcy4NCg0KDQoNCg0KDQoyLiAgSW50 cm9kdWN0aW9uDQoNCg0KDQoyLjEuICBCYWNrZ3JvdW5kDQoNCg0KDQogICAgVGhlIENvbnN0cmFp bmVkIEFwcGxpY2F0aW9uIFByb3RvY29sIChDb0FQKSBpcyBhbiBhcHBsaWNhdGlvbg0KDQogICAg cHJvdG9jb2wgKGFuYWxvZ291cyB0byBIVFRQKSBmb3IgcmVzb3VyY2UgY29uc3RyYWluZWQgZGV2 aWNlcw0KDQogICAgb3BlcmF0aW5nIGluIGFuIElQIG5ldHdvcmsgW0ktRC5pZXRmLWNvcmUtY29h cF0uICBDb25zdHJhaW5lZA0KDQpkZXZpY2VzDQoNCiAgICBjYW4gYmUgbGFyZ2UgaW4gbnVtYmVy LCBidXQgYXJlIG9mdGVuIGhpZ2hseSBjb3JyZWxhdGVkIHRvIGVhY2gNCg0Kb3RoZXINCg0KICAg IChlLmcuIGJ5IHR5cGUgb3IgbG9jYXRpb24pLiAgRm9yIGV4YW1wbGUsIGFsbCB0aGUgbGlnaHQg c3dpdGNoZXMgaW4NCg0KYQ0KDQogICAgYnVpbGRpbmcgbWF5IGJlbG9uZyB0byBvbmUgZ3JvdXAg YW5kIGFsbCB0aGUgdGhlcm1vc3RhdHMgbWF5IGJlbG9uZw0KDQogICAgdG8gYW5vdGhlciBncm91 cC4gIEdyb3VwcyBtYXkgYmUgY29tcG9zZWQgYnkgZnVuY3Rpb24uICBGb3IgZXhhbXBsZSwNCg0K DQoNCg0KDQoNCg0KUmFobWFuICYgRGlqayAgICAgICAgICAgIEV4cGlyZXMgQXByaWwgMjIsIDIw MTMgICAgICAgICAgICAgICAgIFtQYWdlDQoNCjNdDQoNCg0KDQoNCkludGVybmV0LURyYWZ0ICAg ICAgICBHcm91cCBDb21tdW5pY2F0aW9uIGZvciBDb0FQICAgICAgICAgIE9jdG9iZXINCg0KMjAx Mg0KDQoNCg0KDQoNCiAgICB0aGUgZ3JvdXAgImFsbCBsaWdodHMgaW4gYnVpbGRpbmcgb25lIiBt YXkgY29uc2lzdCBvZiB0aGUgZ3JvdXBzDQoNCiJhbGwNCg0KICAgIGxpZ2h0cyBvbiBmbG9vciBv bmUgb2YgYnVpbGRpbmcgb25lIiwgImFsbCBsaWdodHMgb24gZmxvb3IgdHdvIG9mDQoNCiAgICBi dWlsZGluZyBvbmUiLCBldGMuICBHcm91cHMgbWF5IGJlIHByZWNvbmZpZ3VyZWQNCg0KL2FkZCBi ZWZvcmUgZGVwbG95bWVudA0KDQogICAgIG9yIGR5bmFtaWNhbGx5DQoNCiAgICBmb3JtZWQNCg0K L2FkZCBkdXJpbmcgb3BlcmF0aW9uDQoNCiAgIC4gIElmIGluZm9ybWF0aW9uIG5lZWRzIHRvIGJl IHNlbnQgdG8gb3IgcmVjZWl2ZWQgZnJvbSBhIGdyb3VwDQoNCiAgICBvZiBkZXZpY2VzLCBncm91 cCBjb21tdW5pY2F0aW9uIG1lY2hhbmlzbXMgY2FuIGltcHJvdmUgZWZmaWNpZW5jeQ0KDQphbmQN Cg0KICAgIGxhdGVuY3kgb2YgY29tbXVuaWNhdGlvbiBhbmQgcmVkdWNlIGJhbmR3aWR0aCByZXF1 aXJlbWVudHMgZm9yIGENCg0KICAgIGdpdmVuIGFwcGxpY2F0aW9uLiAgSFRUUCBkb2VzIG5vdCBz dXBwb3J0IGFueSBlcXVpdmFsZW50DQoNCiAgICBmdW5jdGlvbmFsaXR5IHRvIENvQVAgZ3JvdXAg Y29tbXVuaWNhdGlvbi4NCg0KDQoNCjIuMi4gIFNjb3BlDQoNCg0KDQogICAgSW4gdGhpcyBkcmFm dCwgd2UgYWRkcmVzcyB0aGUgaXNzdWVzIHJlbGF0ZWQgdG8gQ29BUCBncm91cA0KDQogICAgY29t bXVuaWNhdGlvbiBpbiBkZXRhaWwsIHdpdGggdXNlIGNhc2VzLCByZWNvbW1lbmRlZCBhcHByb2Fj aGVzIGFuZA0KDQogICAgYW5hbHlzaXMgb2YgdGhlIGltcGFjdCB0byB0aGUgQ29BUCBwcm90b2Nv bCBhbmQgdG8gaW1wbGVtZW50YXRpb25zLg0KDQovYWRkIHRoZSB1c2Ugb2YgZ3JvdXAgY29tbXVu aWNhdGlvbiBmb3IgbUROUyBpcyBvdXQgb2Ygc2NvcGUuDQoNCiAgICBUaGUgZ3VpZGluZyBwcmlu Y2lwbGUgaXMgdG8gYXBwbHkgd2hlcmV2ZXIgcG9zc2libGUgZXhpc3RpbmcgSUVURg0KDQogICAg cHJvdG9jb2xzIHRvIGFjaGlldmUgZ3JvdXAgY29tbXVuaWNhdGlvbiBmdW5jdGlvbmFsaXR5LiAg SW4gbWFueQ0KDQogICAgY2FzZXMgdGhlIGNvbnRyaWJ1dGlvbiBvZiB0aGlzIGRvY3VtZW50IGxp ZXMgaW4gZXhwbGFpbmluZyBob3cNCg0KICAgIGV4aXN0aW5nIG1lY2hhbmlzbXMgbWF5IGJlIHVz ZWQgdG8NCg0KL3JlbW92ZSB0b2dldGhlcg0KDQogICAgZnVsZmlsbCBDb0FQIGdyb3VwDQoNCiAg ICBjb21tdW5pY2F0aW9uIG5lZWRzIGZvciBzcGVjaWZpYyB1c2UgY2FzZXMuDQoNCg0KDQoyLjMu ICBQb3RlbnRpYWwgU29sdXRpb25zIGZvciBHcm91cCBDb21tdW5pY2F0aW9uDQoNCg0KDQogICAg VGhlIGNsYXNzaWMgY29uY2VwdCBvZiBncm91cA0KDQovcyBjb21tdW5pY2F0aW9ucyAvcyBjb21t dW5pY2F0aW9uDQoNCiAgICBpcyB0aGF0IG9mIGEgc2luZ2xlDQoNCiAgICBzb3VyY2UgZGlzdHJp YnV0aW5nIGNvbnRlbnQgdG8gbXVsdGlwbGUgZGVzdGluYXRpb24gcmVjaXBpZW50cyB0aGF0DQoN CiAgICBhcmUgYWxsIHBhcnQgb2YgYSBncm91cC4gIEJlZm9yZSBjb250ZW50IGNhbiBiZSBkaXN0 cmlidXRlZCwgdGhlcmUNCg0KaXMNCg0KICAgIGEgc2VwYXJhdGUgcHJvY2VzcyB0byBmb3JtIHRo ZSBncm91cC4gIFRoZSBzb3VyY2UgbWF5IGJlIGVpdGhlciBhDQoNCiAgICBtZW1iZXIgb3Igbm9u LW1lbWJlciBvZiB0aGUgZ3JvdXAuDQoNCg0KDQogICAgR3JvdXAgY29tbXVuaWNhdGlvbiBzb2x1 dGlvbnMgaGF2ZSBldm9sdmVkIGZyb20gImJvdHRvbSIgdG8gInRvcCIsDQoNCiAgICBpLmUuLCBm cm9tIGxheWVyIDIgKE1lZGlhIEFjY2VzcyBDb250cm9sIGJyb2FkY2FzdC9tdWx0aWNhc3QpIGFu ZA0KDQogICAgbGF5ZXIgMyAoSVAgbXVsdGljYXN0KSB0byBhcHBsaWNhdGlvbiBsYXllciBncm91 cCBjb21tdW5pY2F0aW9uLA0KDQphbHNvDQoNCiAgICByZWZlcnJlZCB0byBhcyBhcHBsaWNhdGlv biBsYXllciBtdWx0aWNhc3QuICBBIHN0dWR5IHB1Ymxpc2hlZCBpbg0KDQogICAgMjAwNSBbTGFv MDVdIGlkZW50aWZpZWQgbmV3IHNvbHV0aW9ucyBpbiB0aGUgIm1pZGRsZSIgKHJlZmVycmVkIHRv DQoNCmFzDQoNCiAgICBvdmVybGF5IG11bHRpY2FzdCkgdGhhdCB1dGlsaXplIGFuIGluZnJhc3Ry dWN0dXJlIGJhc2VkIG9uIHByb3hpZXMuDQoNCg0KDQogICAgRWFjaCBvZiB0aGVzZSBjbGFzc2Vz IG9mIHNvbHV0aW9ucyBtYXkgYmUgY29tcGFyZWQgW0xhbzA1XSB1c2luZw0KDQogICAgbWV0cmlj cyBzdWNoIGFzIGxpbmsgc3RyZXNzIGFuZCBsZXZlbCBvZiBob3N0IGNvbXBsZXhpdHkNCg0KICAg IFtCYW5lcmplZTAxXS4gIFRoZSByZXN1bHRzIHNob3cgZm9yIGEgcmVhbGlzdGljIGludGVybmV0 IHRvcG9sb2d5DQoNCiAgICB0aGF0IElQIE11bHRpY2FzdCBpcyB0aGUgbW9zdCByZXNvdXJjZS1l ZmZpY2llbnQsIHdpdGggdGhlIGRvd25zaWRlDQoNCiAgICBiZWluZyB0aGF0IGl0IHJlcXVpcmVz DQoNCi9zIHRoZSBtb3N0IC9zIG1vcmUgb3JnYW5pemF0aW9uYWwNCg0KICAgIGVmZm9ydCB0byBk ZXBsb3kgaW4gdGhlDQoNCiAgICBpbmZyYXN0cnVjdHVyZS4gIElQIE11bHRpY2FzdCBpcyB0aGUg c29sdXRpb24gYWRvcHRlZCBieSB0aGlzIGRyYWZ0DQoNCiAgICBmb3IgQ29BUCBncm91cCBjb21t dW5pY2F0aW9uLg0KDQoNCg0KDQoNCjMuICBDb0FQIEdyb3VwIENvbW11bmljYXRpb24gQmFzZWQg T24gSVAgTXVsdGljYXN0DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNClJhaG1hbiAmIERpamsg ICAgICAgICAgICBFeHBpcmVzIEFwcmlsIDIyLCAyMDEzICAgICAgICAgICAgICAgICBbUGFnZQ0K DQo0XQ0KDQoNCg0KDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgR3JvdXAgQ29tbXVuaWNhdGlvbiBm b3IgQ29BUCAgICAgICAgICBPY3RvYmVyDQoNCjIwMTINCg0KDQoNCg0KDQozLjEuICBJUCBNdWx0 aWNhc3QgQmFja2dyb3VuZA0KDQoNCg0KICAgIElQIE11bHRpY2FzdCByb3V0aW5nIHByb3RvY29s cyBoYXZlIGJlZW4gZXZvbHZpbmcgZm9yIGRlY2FkZXMsDQoNCiAgICByZXN1bHRpbmcgaW4gcHJv cG9zZWQgc3RhbmRhcmRzIHN1Y2ggYXMgUHJvdG9jb2wgSW5kZXBlbmRlbnQNCg0KICAgIE11bHRp Y2FzdCAtIFNwYXJzZSBNb2RlIChQSU0tU00pIFtSRkM0NjAxXS4gIFlldCwgZHVlIHRvIHZhcmlv dXMNCg0KICAgIHRlY2huaWNhbCBhbmQgbWFya2V0aW5nIHJlYXNvbnMsIElQIE11bHRpY2FzdCBy b3V0aW5nIGlzIG5vdCB3aWRlbHkNCg0KICAgIGRlcGxveWVkIG9uIHRoZSBnZW5lcmFsIEludGVy bmV0LiAgSG93ZXZlciwgSVAgTXVsdGljYXN0IGlzIHZlcnkNCg0KICAgIHBvcHVsYXIgaW4gc3Bl Y2lmaWMgZGVwbG95bWVudHMgc3VjaCBhcyBpbiBlbnRlcnByaXNlIG5ldHdvcmtzIChlLmcuDQoN CiAgICBmb3IgdmlkZW8gY29uZmVyZW5jaW5nKSwgc21hcnQgaG9tZSBuZXR3b3JrcyAoZS5nLiAg VVBuUC9tRE5TKSBhbmQNCg0KICAgIGNhcnJpZXIgSVBUViBkZXBsb3ltZW50cy4gIFRoZSBwYWNr ZXQgZWNvbm9teSBhbmQgbWluaW1hbCBob3N0DQoNCiAgICBjb21wbGV4aXR5IG9mIElQIG11bHRp Y2FzdCBtYWtlIGl0IGF0dHJhY3RpdmUgZm9yIGdyb3VwDQoNCmNvbW11bmljYXRpb24NCg0KICAg IGluIGNvbnN0cmFpbmVkIGVudmlyb25tZW50cy4gIFRoZXJlZm9yZSBJUCBtdWx0aWNhc3QgaXMg dGhlDQoNCiAgICByZWNvbW1lbmRlZCB1bmRlcmx5aW5nIG1lY2hhbmlzbSBmb3IgQ29BUCBncm91 cCBjb21tdW5pY2F0aW9uLCBhbmQNCg0KICAgIHRoZSBhcHByb2FjaCBhc3N1bWVkIGluIHRoaXMg ZG9jdW1lbnQuDQoNCg0KDQogICAgVG8gYWNoaWV2ZSBJUCBtdWx0aWNhc3QgYmV5b25kIGEgc3Vi bmV0LCBhbiBJUCBtdWx0aWNhc3Qgcm91dGluZw0KDQogICAgcHJvdG9jb2wgbmVlZHMgdG8gYmUg YWN0aXZlIG9uIHJvdXRlcnMuICBUaGUgUlBMIHByb3RvY29sIFtSRkM2NTUwXQ0KDQogICAgZm9y IGV4YW1wbGUgaXMgYWJsZSB0byByb3V0ZSBtdWx0aWNhc3QgdHJhZmZpYyBpbiBjb25zdHJhaW5l ZCBMTE5zLg0KDQogICAgV2hpbGUgUElNLVNNIFtSRkM0NjAxXSBpcyBvZnRlbiB1c2VkIGZvciBt dWx0aWNhc3Qgcm91dGluZyBpbiB1bi0NCg0KICAgIGNvbnN0cmFpbmVkIG5ldHdvcmtzLg0KDQoN Cg0KICAgIElQIG11bHRpY2FzdCBjYW4gYWxzbyBiZSBydW4gaW4gYSBMaW5rLUxvY2FsIChMTCkg c2NvcGUuICBUaGlzIG1lYW5zDQoNCiAgICB0aGF0IHRoZXJlIGlzIG5vIHJvdXRpbmcgaW52b2x2 ZWQgYW5kIGFuIElQIG11bHRpY2FzdCBtZXNzYWdlIGlzDQoNCm9ubHkNCg0KICAgIHJlY2VpdmVk DQoNCi9zIG9uIHRoZSBuZXR3b3JrIC9zIG92ZXIgdGhlDQoNCiAgICAgbGluayBvbiB3aGljaCBp dCB3YXMgc2VudC4NCg0KDQoNCjMuMi4gIENvQVAgR3JvdXAgRGVmaW5pdGlvbiBhbmQgTmFtaW5n DQoNCg0KDQogICAgQSBncm91cCBpcyBkZWZpbmVkIGFzIGEgc2V0IG9mIENvQVAgZW5kcG9pbnRz LCB3aGVyZSBlYWNoIGVuZHBvaW50DQoNCmlzDQoNCiAgICBjb25maWd1cmVkIHRvIHJlY2VpdmUg YSBtdWx0aWNhc3QgQ29BUCByZXF1ZXN0IHRoYXQgaXMgc2VudCB0byB0aGUNCg0KICAgIGdyb3Vw J3MgYXNzb2NpYXRlZCBJUCBtdWx0aWNhc3QgYWRkcmVzcy4gIFRoZSBncm91cCBNQVkgaGF2ZSBt b3JlDQoNCiAgICB0aGFuIG9uZSBhc3NvY2lhdGVkIElQIG11bHRpY2FzdCBhZGRyZXNzLiAgQW4g ZW5kcG9pbnQgTUFZIGJlIGENCg0KICAgIG1lbWJlciBvZiBtdWx0aXBsZSBncm91cHMuICBHcm91 cCBtZW1iZXJzaGlwIG9mIGFuIGVuZHBvaW50IE1BWQ0KDQogICAgZHluYW1pY2FsbHkgY2hhbmdl IG92ZXIgdGltZS4gIFRoZSBncm91cCBNQVkgYmUgaWRlbnRpZmllZCBieSBhDQoNCkdyb3VwDQoN CiAgICBOYW1lIChbSS1ELnZhbmRlcnN0b2stY29yZS1kbmFdKSB3aGljaCBpcyBkZWZpbmVkIGFz IGEgcHJlZml4IHN0cmluZw0KDQogICAgb2YgYSBHcm91cCBGUUROLiAgVGhlIEdyb3VwIEZRRE4g Y2FuIGJlIHVuaXF1ZWx5IG1hcHBlZCB0byBhIHNpdGUtDQoNCiAgICBsb2NhbCBvciBnbG9iYWwg bXVsdGljYXN0IElQIGFkZHJlc3MgdmlhIEROUyByZXNvbHV0aW9uLg0KDQoNCg0KICAgIEEgQ29B UCBtdWx0aWNhc3QgcmVxdWVzdCB0aGF0IGFkZHJlc3NlcyBhIGdyb3VwIGluY2x1ZGVzIGEgR3Jv dXAgVVJJDQoNCiAgICBhcyB0aGUgcmVxdWVzdCBVUkkuICBBIEdyb3VwIFVSSSBoYXMgdGhlIHNj aGVtZSAnY29hcCcgYW5kIGluY2x1ZGVzDQoNCiAgICBpbiB0aGUgYXV0aG9yaXR5IHBhcnQgZWl0 aGVyIGEgZ3JvdXAgSVAgYWRkcmVzcw0KDQovYWRkICsgb3B0aW9uYWwgcG9ydA0KDQogICAgIG9y IGEgaG9zdG5hbWUNCg0KL2FkZCArIG9wdGlvbmFsIHBvcnQNCg0KICAgIHRoYXQNCg0KICAgIGNh biBiZSByZXNvbHZlZCB0byB0aGUgZ3JvdXAgSVAgYWRkcmVzcyAoZS5nLiwgYSBHcm91cCBOYW1l IG9yIEdyb3VwDQoNCiAgICBGUUROKS4gIEdyb3VwIFVSSXMgTVVTVCBmb2xsb3cgdGhlIFVSSSBz eW50YXggW1JGQzM5ODZdLg0KDQoNCg0KICAgIEEgQ29BUA0KDQovcyBub2RlIC9zIGVuZC1wb2lu dA0KDQogICAgYmVjb21lcyBhIGdyb3VwIG1lbWJlciBieSBsaXN0ZW5pbmcgZm9yIENvQVAgbWVz c2FnZXMgb24NCg0KICAgIHRoZSBncm91cCdzIElQIG11bHRpY2FzdCBhZGRyZXNzLCBhc3N1bWlu ZyB0aGUgZGVmYXVsdCBDb0FQIFVEUA0KDQpwb3J0Lg0KDQogICAgTm90ZSB0aGF0IGEgbm9uLWRl ZmF1bHQgVURQIHBvcnQgTUFZIGJlIHNwZWNpZmllZCBmb3IgdGhlIGdyb3VwOyBpbg0KDQogICAg d2hpY2ggY2FzZSBpbXBsZW1lbnRlcnMgTVVTVCBlbnN1cmUgdGhhdCBhbGwgZ3JvdXAgbWVtYmVy cyBhcmUNCg0KICAgIGNvbmZpZ3VyZWQgdG8gdXNlIHRoaXMgc2FtZSBwb3J0Lg0KDQoNCg0KDQoN Cg0KDQpSYWhtYW4gJiBEaWprICAgICAgICAgICAgRXhwaXJlcyBBcHJpbCAyMiwgMjAxMyAgICAg ICAgICAgICAgICAgW1BhZ2UNCg0KNV0NCg0KDQoNCg0KSW50ZXJuZXQtRHJhZnQgICAgICAgIEdy b3VwIENvbW11bmljYXRpb24gZm9yIENvQVAgICAgICAgICAgT2N0b2Jlcg0KDQoyMDEyDQoNCg0K DQoNCg0KICAgIEV4YW1wbGVzIG9mIGhpZXJhcmNoaWNhbCBncm91cCBuYW1pbmcgKGFuZCBzY29w aW5nKSBmb3IgYSBidWlsZGluZw0KDQogICAgY29udHJvbCBhcHBsaWNhdGlvbiBhcmUgc2hvd24g YmVsb3cuDQoNCg0KDQogICAgICBVUkkgYXV0aG9yaXR5ICAgICAgICAgICAgICAgICAgVGFyZ2V0 ZWQgZ3JvdXANCg0KICAgICAgYWxsLmJsZGc2LmV4YW1wbGUuY29tICAgICAgICAgICJhbGwgbm9k ZXMgaW4gYnVpbGRpbmcgNiINCg0KICAgICAgYWxsLndlc3QuYmxkZzYuZXhhbXBsZS5jb20gICAg ICJhbGwgbm9kZXMgaW4gd2VzdCB3aW5nLCBidWlsZGluZw0KDQo2Ig0KDQogICAgICBhbGwuZmxv b3IxLndlc3QuYmxkZzYuZXhhbXAuLi4gImFsbCBub2RlcyBpbiBmbG9vciAxLCB3ZXN0IHdpbmcs DQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgYnVpbGRpbmcgNiINCg0K ICAgICAgYWxsLmJ1MDM2LmZsb29yMS53ZXN0LmJsZGc2Li4uICJhbGwgbm9kZXMgaW4gb2ZmaWNl IGJ1MDM2LCBmbG9vcjEsDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg d2VzdCB3aW5nLCBidWlsZGluZyA2Ig0KDQoNCg0KICAgIFJldmVyc2UgbWFwcGluZyAoZnJvbSBJ UCBtdWx0aWNhc3QgYWRkcmVzcyB0byBncm91cCBGUUROKSBpcw0KDQogICAgc3VwcG9ydGVkIHVz aW5nIHRoZSByZXZlcnNlIEROUyByZXNvbHV0aW9uIHRlY2huaXF1ZQ0KDQogICAgKFtJLUQudmFu ZGVyc3Rvay1jb3JlLWRuYV0pLg0KDQoNCg0KMy4zLiAgR3JvdXAgRGlzY292ZXJ5IGFuZCBNZW1i ZXIgRGlzY292ZXJ5DQoNCg0KDQogICAgQ29BUCBkZWZpbmVzIGEgcmVzb3VyY2UgZGlzY292ZXJ5 IGNhcGFiaWxpdHksIGJ1dCBkb2VzIG5vdCB5ZXQNCg0KICAgIHNwZWNpZnkgaG93IHRvIGRpc2Nv dmVyIGdyb3VwcyAoZS5nLiBmaW5kIGEgZ3JvdXAgdG8gam9pbiBvciBzZW5kIGENCg0KICAgIG11 bHRpY2FzdCBtZXNzYWdlIHRvKSBvciB0byBkaXNjb3ZlciBtZW1iZXJzIG9mIGEgZ3JvdXAgKGUu Zy4gdG8NCg0KICAgIGFkZHJlc3Mgc2VsZWN0ZWQgZ3JvdXAgbWVtYmVycyBieSB1bmljYXN0KS4g IFRoZXNlIHRvcGljcyBhcmUNCg0KICAgIGVsYWJvcmF0ZWQgaW4gbW9yZSBkZXRhaWwgaW4gW0kt RC52YW5kZXJzdG9rLWNvcmUtZG5hXSBpbmNsdWRpbmcNCg0KICAgIGV4YW1wbGVzIGZvciB1c2lu ZyBETlMtU0QgYW5kIENvUkUgUmVzb3VyY2UgRGlyZWN0b3J5Lg0KDQoNCg0KMy4zLjEuICBETlMt U0QNCg0KDQoNCiAgICBETlMtYmFzZWQgU2VydmljZSBEaXNjb3ZlcnkgW0ktRC5jaGVzaGlyZS1k bnNleHQtZG5zLXNkXSBkZWZpbmVzIGENCg0KICAgIGNvbnZlbnRpb25hbCB3YXkgdG8gY29uZmln dXJlIEROUyBQVFIsIFNSViwgYW5kIFRYVCByZWNvcmRzIHRvDQoNCmVuYWJsZQ0KDQogICAgZW51 bWVyYXRpb24gb2Ygc2VydmljZXMsIHN1Y2ggYXMgc2VydmljZXMgb2ZmZXJlZCBieSBDb0FQIG5v ZGVzLCBvcg0KDQogICAgZW51bWVyYXRpb24gb2YgYWxsIENvQVAgbm9kZXMsIHdpdGhpbiBzcGVj aWZpZWQgc3ViZG9tYWlucy4gIEENCg0KICAgIHNlcnZpY2UgaXMgc3BlY2lmaWVkIGJ5IGEgbmFt ZSBvZiB0aGUgZm9ybQ0KDQogICAgPEluc3RhbmNlPi48U2VydmljZVR5cGU+LjxEb21haW4+LCB3 aGVyZSB0aGUgc2VydmljZSB0eXBlIGZvciBDb0FQDQoNCiAgICBub2RlcyBpcyBfY29hcC5fdWRw IGFuZCB0aGUgZG9tYWluIGlzIGEgRE5TIGRvbWFpbiBuYW1lIHRoYXQNCg0KICAgIGlkZW50aWZp ZXMgYSBncm91cCBhcyBpbiB0aGUgZXhhbXBsZXMgYWJvdmUuICBGb3IgZWFjaCBDb0FQDQoNCmVu ZC1wb2ludA0KDQogICAgaW4gYSBncm91cCwgYSBQVFIgcmVjb3JkIHdpdGggdGhlIG5hbWUgX2Nv YXAuX3VkcCBhbmQvb3IgYSBQVFINCg0KcmVjb3JkDQoNCiAgICB3aXRoIHRoZSBuYW1lIF9jb2Fw Ll91ZHAuPERvbWFpbj4gaXMgZGVmaW5lZCBhbmQgaXQgcG9pbnRzIHRvIGFuIFNSVg0KDQogICAg cmVjb3JkIGhhdmluZyB0aGUgPEluc3RhbmNlPi48U2VydmljZVR5cGU+LjxEb21haW4+IG5hbWUu DQoNCg0KDQogICAgQWxsIENvQVAgbm9kZXMgaW4gYSBnaXZlbiBzdWJkb21haW4gbWF5IGJlIGVu dW1lcmF0ZWQgYnkgc2VuZGluZyBhDQoNCiAgICBxdWVyeSBmb3IgUFRSIHJlY29yZHMgbmFtZWQg X2NvYXAuX3VkcCB0byB0aGUgYXV0aG9yaXRhdGl2ZSBETlMNCg0KICAgIHNlcnZlciBmb3IgdGhh dCB6b25lLiAgQSBsaXN0IG9mIFNSViByZWNvcmRzIGlzIHJldHVybmVkLiAgRWFjaCBTUlYNCg0K ICAgIHJlY29yZCBjb250YWlucyB0aGUgcG9ydCBhbmQgaG9zdCBuYW1lIChBQUFBIHJlY29yZCkg b2YgYSBDb0FQIG5vZGUuDQoNCiAgICBUaGUgSVAgYWRkcmVzcyBvZiB0aGUgbm9kZSBpcyBvYnRh aW5lZCBieSByZXNvbHZpbmcgdGhlIGhvc3QgbmFtZS4NCg0KICAgIEROUy1TRCBhbHNvIHNwZWNp ZmllcyBhbiBvcHRpb25hbCBUWFQgcmVjb3JkLCBoYXZpbmcgdGhlIHNhbWUgbmFtZQ0KDQphcw0K DQogICAgdGhlIFNSViByZWNvcmQsIHdoaWNoIGNhbiBjb250YWluICJrZXk9dmFsdWUiIGF0dHJp YnV0ZXMuICBUaGlzIGNhbg0KDQogICAgYmUgdXNlZCB0byBzdG9yZSBpbmZvcm1hdGlvbiBhYm91 dCB0aGUgZGV2aWNlLCBlLmcuIHNjaGVtYT1EQUxJLA0KDQogICAgdHlwZT1zd2l0Y2gsIGdyb3Vw PWxpZ2h0aW5nLmJsZGc2LCBldGMuDQoNCg0KDQoNCg0KDQoNCg0KDQpSYWhtYW4gJiBEaWprICAg ICAgICAgICAgRXhwaXJlcyBBcHJpbCAyMiwgMjAxMyAgICAgICAgICAgICAgICAgW1BhZ2UNCg0K Nl0NCg0KDQoNCg0KSW50ZXJuZXQtRHJhZnQgICAgICAgIEdyb3VwIENvbW11bmljYXRpb24gZm9y IENvQVAgICAgICAgICAgT2N0b2Jlcg0KDQoyMDEyDQoNCg0KDQoNCg0KICAgIEFub3RoZXIgZmVh dHVyZSBvZiBETlMtU0QgaXMgdGhlIGFiaWxpdHkgdG8gc3BlY2lmeSBzZXJ2aWNlIHN1YnR5cGVz DQoNCiAgICB1c2luZyBQVFIgcmVjb3Jkcy4gIEZvciBleGFtcGxlLCBvbmUgY291bGQgcmVwcmVz ZW50IGFsbCB0aGUgQ29BUA0KDQogICAgZ3JvdXBzIGluIGEgc3ViZG9tYWluIGJ5IFBUUiByZWNv cmRzIHdpdGggdGhlIG5hbWUNCg0KICAgIF9ncm91cC5fc3ViLl9jb2FwLl91ZHAgb3IgYWx0ZXJu YXRpdmVseQ0KDQogICAgX2dyb3VwLl9zdWIuX2NvYXAuX3VkcC48RG9tYWluPi4NCg0KDQoNCjMu My4yLiAgQ29SRSBSZXNvdXJjZSBEaXJlY3RvcnkNCg0KDQoNCiAgICBDb1JFIFJlc291cmNlIERp cmVjdG9yeSBbSS1ELnNoZWxieS1jb3JlLXJlc291cmNlLWRpcmVjdG9yeV0gZGVmaW5lcw0KDQog ICAgdGhlIGNvbmNlcHQgb2YgYSBSZXNvdXJjZSBEaXJlY3RvcnkgKFJEKSBzZXJ2ZXIgd2hlcmUg Q29BUCBzZXJ2ZXJzDQoNCiAgICBjYW4gcmVnaXN0ZXIgdGhlaXIgcmVzb3VyY2VzIG9mZmVyZWQg YW5kIENvQVAgY2xpZW50cyBjYW4gZGlzY292ZXINCg0KICAgIHRoZXNlIHJlc291cmNlcyBieSBx dWVyeWluZyB0aGUgUkQgc2VydmVyLiAgUkQgc3ludGF4IGNhbiBiZSBtYXBwZWQNCg0KICAgIHRv IEROUy1TRCBzeW50YXggYW5kIHZpY2UgdmVyc2EgW0ktRC5seW5uLWNvcmUtZGlzY292ZXJ5LW1h cHBpbmddLA0KDQogICAgc3VjaCB0aGF0IHRoZSBhYm92ZSBhcHByb2FjaCBjYW4gYmUgcmV1c2Vk IGZvciBncm91cCBkaXNjb3ZlcnkgYW5kDQoNCiAgICBncm91cCBtZW1iZXIgZGlzY292ZXJ5Lg0K DQoNCg0KICAvcmVtb3ZlICBTcGVjaWZpY2FsbHksIHRoZSBEb21haW4gKGQpIHBhcmFtZXRlciBj YW4gYmUgc2V0IHRvIHRoZQ0KDQpncm91cCBVUkkgYnkNCg0KICAgIGFuIGVuZC1wb2ludCByZWdp c3RlcmluZyB0byB0aGUgUkQuICBJZiBhbiBlbmQtcG9pbnQgd2FudHMgdG8gam9pbg0KDQogICAg bXVsdGlwbGUgZ3JvdXBzLCBpdCBoYXMgdG8gcmVwZWF0IHRoZSByZWdpc3RyYXRpb24gcHJvY2Vz cyBmb3IgZWFjaA0KDQogICAgZ3JvdXAgaXQgd2FudHMgdG8gam9pbi4NCg0KL2VuZCByZW1vdmUN Cg0KL2NvbW1lbnQgZCBwYXJhbWV0ZXIgc2VtYW50aWNzIG5vdCBjbGVhcg0KDQoNCg0KMy40LiAg R3JvdXAgUmVzb3VyY2UgTWFuaXB1bGF0aW9uDQoNCg0KDQogICAgR3JvdXAgY29tbXVuaWNhdGlv bnMgU0hBTEwgb25seSBiZSB1c2VkIGZvciBpZGVtcG90ZW50IG1ldGhvZHMgKGkuZS4NCg0KICAg IENvQVAgR0VULCBQVVQsIERFTEVURSkuICBUaGUgQ29BUCBtZXNzYWdlcyB0aGF0IGFyZSBzZW50 IHZpYQ0KDQogICAgbXVsdGljYXN0IFNIQUxMIGJlIE5vbi1Db25maXJtYWJsZS4NCg0KDQoNCiAg ICBBIHVuaWNhc3QgcmVzcG9uc2UgcGVyIHNlcnZlciBNQVkgYmUgc2VudCBiYWNrIHRvIGFuc3dl ciB0aGUgZ3JvdXANCg0KICAgIHJlcXVlc3QgKGUuZy4gcmVzcG9uc2UgIjIuMDUgQ29udGVudCIg dG8gYSBncm91cCBHRVQgcmVxdWVzdCkgdGFraW5nDQoNCiAgICBpbnRvIGFjY291bnQgdGhlIGNv bmdlc3Rpb24gY29udHJvbCBydWxlcyBkZWZpbmVkIGluDQoNCiAgICBbSS1ELmlldGYtY29yZS1j b2FwXS4gIFRoZSB1bmljYXN0IHJlc3BvbnNlcyBtYXkgYmUgYSBtaXh0dXJlIG9mDQoNCiAgICBz dWNjZXNzIChlLmcuIDIuMDUgQ29udGVudCkgYW5kIGZhaWx1cmUgKGUuZy4gNC4wNCBOb3QgRm91 bmQpIGNvZGVzDQoNCiAgICBkZXBlbmRpbmcgb24gdGhlIGluZGl2aWR1YWwgc2VydmVyIHByb2Nl c3NpbmcgcmVzdWx0Lg0KDQoNCg0KICAgIEdyb3VwIGNvbW11bmljYXRpb25zIFNIQUxMIE5PVCBi ZSB1c2VkIGZvciBub24taWRlbXBvdGVudCBtZXRob2RzDQoNCiAgICAoaS5lLiAgQ29BUCBQT1NU KS4gIFRoaXMgaXMgYmVjYXVzZSBub3QgYWxsIGdyb3VwIG1lbWJlcnMgYXJlDQoNCiAgICBndWFy YW50ZWVkIHRvIHJlY2VpdmUgdGhlIG11bHRpY2FzdCByZXF1ZXN0LCBhbmQgdGhlIHNlbmRlciBj YW4gbm90DQoNCiAgICByZWFkaWx5IGZpbmQgb3V0IHdoaWNoIGdyb3VwIG1lbWJlcnMgZGlkIG5v dCByZWNlaXZlIGl0Lg0KDQoNCg0KICAgIEFsbCBub2RlcyBpbiBhIGdpdmVuIGdyb3VwIFNIT1VM RCByZWNlaXZlIHRoZSBzYW1lIHJlcXVlc3QNCg0KL3JlbW92ZSB3aXRoIGhpZ2ggcHJvYmFiaWxp dHkuDQoNCi9jb21tZW50IEkgZG9uJ3Qgc2VlIHdoZXJlIHByb2JhYmlsaXR5IGNvbWVzIGluLg0K DQogICAgVGhpcyB3aWxsIG5vdCBiZSB0aGUgY2FzZSBpZiB0aGVyZSBpcyBkaXZlcnNpdHkgaW4g dGhlDQoNCiAgICBhdXRob3JpdHkgcG9ydCAoaS5lLiBhIGRpdmVyc2l0eSBvZiBkeW5hbWljIHBv cnQgYWRkcmVzc2VzIGFjcm9zcw0KDQp0aGUNCg0KICAgIGdyb3VwKSBvciBpZiB0aGUgdGFyZ2V0 ZWQgcmVzb3VyY2UgaXMgbG9jYXRlZCBhdCBkaWZmZXJlbnQgcGF0aHMgb24NCg0KICAgIGRpZmZl cmVudCBub2Rlcy4NCg0KDQoNCiAgICBUaGVyZWZvcmUsIHNvbWUgbWVhc3VyZXMgbXVzdCBiZSBw cmVzZW50IHRvIGVuc3VyZSB1bmlmb3JtaXR5IGluDQoNCnBvcnQNCg0KICAgIG51bWJlciBhbmQg cmVzb3VyY2UgbmFtZXMvbG9jYXRpb25zIHdpdGhpbiBhIGdyb3VwLiAgVGhpcyBkb2N1bWVudA0K DQogICAgcHJvcG9zZXMgdGhlIGZvbGxvd2luZyBtZWFzdXJlczoNCg0KDQoNCg0KDQoNCg0KUmFo bWFuICYgRGlqayAgICAgICAgICAgIEV4cGlyZXMgQXByaWwgMjIsIDIwMTMgICAgICAgICAgICAg ICAgIFtQYWdlDQoNCjddDQoNCg0KDQoNCkludGVybmV0LURyYWZ0ICAgICAgICBHcm91cCBDb21t dW5pY2F0aW9uIGZvciBDb0FQICAgICAgICAgIE9jdG9iZXINCg0KMjAxMg0KDQoNCg0KDQoNCiAg ICBvICBBbGwgQ29BUCBtdWx0aWNhc3QgcmVxdWVzdHMgTVVTVCBiZSBzZW50IGVpdGhlciB0byB0 aGUgZGVmYXVsdA0KDQogICAgICAgQ29BUCBVRFAgcG9ydCAoaS5lLiBkZWZhdWx0IFVyaS1Qb3J0 IGFzIGRlZmluZWQgaW4NCg0KICAgICAgIFtJLUQuaWV0Zi1jb3JlLWNvYXBdKSwgb3IgdG8gYSBw b3J0IG51bWJlciBvYnRhaW5lZCB2aWEgYSBzZXJ2aWNlDQoNCiAgICAgICBkaXNjb3ZlcnkgbG9v a3VwIG9wZXJhdGlvbiBhcyBhIHZhbGlkIENvQVAgcG9ydCBmb3IgdGhlIHRhcmdldGVkDQoNCiAg ICAgICBtdWx0aWNhc3QgZ3JvdXAuDQoNCg0KDQogICAgbyAgQWxsIENvQVAgbXVsdGljYXN0IHJl cXVlc3RzIFNIT1VMRCBvcGVyYXRlIG9ubHkgb24gVVJJcyAobGlua3MpDQoNCiAgICAgICB3aGlj aCB3ZXJlDQoNCi9zIHJldHJlaXZlZCAvcyByZXRyaWV2ZWQNCg0KICAgICAgIGVpdGhlciBmcm9t IGEgIi8ud2VsbC1rbm93bi9jb3JlIiBsb29rdXAgb24NCg0KICAgICAgIGF0IGxlYXN0IG9uZSBn cm91cCBtZW1iZXIgbm9kZSwgb3IgZnJvbSBhbiBlcXVpdmFsZW50IHNlcnZpY2UNCg0KICAgICAg IGRpc2NvdmVyeSBsb29rdXAgd2hpY2ggcmV0dXJucyBlaXRoZXIgdGhlIHJlc291cmNlcyBzdXBw b3J0ZWQgYnkNCg0KICAgICAgIGFsbCBncm91cCBtZW1iZXJzIG9yIHJlc291cmNlcyBzdXBwb3J0 ZWQgYnkgb25lIHBhcnRpY3VsYXIgZ3JvdXANCg0KICAgICAgIG1lbWJlci4NCg0KL2NvbW1lbnQg c28gc2V0dGluZyBhIG11bHRpY2FzdCBhZGRyZXNzIGluIGEgc291cmNlIGF0IGluc3RhbGxhdGlv biBpcw0KDQpmb3JiaWRkZW4/DQoNCg0KDQoNCg0KMy41LiAgQ29uZmlndXJpbmcgR3JvdXAgTWVt YmVyc2hpcCBJbiBFbmRwb2ludHMNCg0KDQoNCiAgICBJbiBzb21lIHVzZSBjYXNlcywgdGhlIGdy b3VwIG1lbWJlcnNoaXAgb2YgZW5kcG9pbnRzIG5lZWRzIHRvIGJlDQoNCiAgICBjb25maWd1cmFi bGUgYWZ0ZXIgdGhlIG5ldHdvcmsgaGFzIGJlZW4gZGVwbG95ZWQuICBFeGFtcGxlIHVzZSBjYXNl cw0KDQogICAgY2FuIGJlIGZvdW5kIGluIGJ1aWxkaW5nIGNvbnRyb2w6IGEgY29tbWlzc2lvbmlu ZyB0b29sIGRldGVybWluZXMgdG8NCg0KICAgIHdoaWNoIGdyb3VwcyBhIGxpZ2h0IG9yIHNlbnNv ciBub2RlIGJlbG9uZ3MsIGFuZCB3cml0ZXMgdGhpcw0KDQogICAgaW5mb3JtYXRpb24gdG8gYWxs IG5vZGVzLCB3aGljaCBjYW4gc3Vic2VxdWVudGx5IGpvaW4gdGhlIGNvcnJlY3QNCg0KICAgIGdy b3VwLg0KDQoNCg0KICAgIFRvIGFjaGlldmUgc21vb3RoZXIgaW50ZXJvcGVyYWJpbGl0eSBiZXR3 ZWVuIG5vZGVzL2VuZHBvaW50cyBmcm9tDQoNCiAgICBkaWZmZXJlbnQgbWFudWZhY3R1cmVycywg aXQgaXMgcHJvcG9zZWQgaGVyZSB0byBkZWZpbmUgYW4gT1BUSU9OQUwNCg0KICAgIHN0YW5kYXJk aXplZCBSRVNUZnVsIG1lYW5zIG9mIGNvbmZpZ3VyaW5nIENvQVAgZW5kcG9pbnRzIHdpdGgNCg0K ICAgIHJlbGV2YW50IGdyb3VwIGluZm9ybWF0aW9uLg0KDQoNCg0KICAgIENvQVAgZW5kcG9pbnRz IGltcGxlbWVudGluZyB0aGlzIG1lY2hhbmlzbSBNVVNUIHN1cHBvcnQgYQ0KDQogICAgZGlzY292 ZXJhYmxlICJHcm91cCBDb25maWd1cmF0aW9uIiByZXNvdXJjZSBvZiByZXNvdXJjZSB0eXBlIChy dCkNCg0KICAgIFtSRkM2NjkwXSAiY29yZS5ncCIuICBUaGlzIHJlc291cmNlIChhbmQgcGVyaGFw cyBpdHMgc3ViLXJlc291cmNlcywNCg0KICAgIFRCRCkgYXJlIHVzZWQgdG8gbWFuYWdlIGdyb3Vw IG1lbWJlcnNoaXAuICBUaHJlZSBkZXNpZ24gb3B0aW9ucyBmb3INCg0KICAgIHRoaXMgbWVjaGFu aXNtIGFyZSBwcmVzZW50ZWQgaGVyZSBhcyBhIHBsYWNlaG9sZGVyIChUQkQpLg0KDQoNCg0KICAg IERlc2lnbiAxOiB1c2UgQ29SRSBsaW5rIGZvcm1hdCBwYXlsb2FkcyB0byBjb21tdW5pY2F0ZSBn cm91cA0KDQogICAgbWVtYmVyc2hpcCB0byBlbmRwb2ludHMuICAoVEJEIE5vdCBjbGVhciBob3cg dGhpcyBzaG91bGQgYmUNCg0KICAgIHJlYWxpemVkLikNCg0KL2NvbW1lbnQsIG5vdCBjbGVhciB3 aGF0IHlvdSBtZWFuIGVpdGhlci4gUmVtb3ZlIGRlc2lnbiAxIGluIHRoaXMgc3RhdGUNCg0KDQoN CiAgICBEZXNpZ24gMjogdXNlIGEgSlNPTiB0eXBlIHJlc291cmNlLiAgRm9yIGV4YW1wbGUsIGEg R0VUIG9uIHRoZQ0KDQogICAgImNvcmUuZ3AiIHJlc291cmNlIHJldHVybnMgYSBKU09OIGFycmF5 IG9mIGdyb3VwIG9iamVjdHMuDQoNCg0KDQogICAgICAgUmVxOiBHRVQgL2dwDQoNCiAgICAgICBS ZXM6IDIuMDUgQ29udGVudCAoQ29udGVudC1Gb3JtYXQ6IGFwcGxpY2F0aW9uL2pzb24pDQoNCiAg ICAgICBbIHsgIm4iOiAiUm9vbS1BLUxpZ2h0cy5mbG9vcjEud2VzdC5ibGRnNi5leGFtcGxlLmNv bSIsDQoNCiAgICAgICAgICAgImlwIjogImZmMDU6OjQyMDA6ZjdmZTplZDM3OjE0Y2EiIH0NCg0K ICAgICAgIF0NCg0KDQoNCiAgICB3aGVyZSAibiIgZGVmaW5lcyB0aGUgR3JvdXAgRlFETiBhbmQg ImlwIiBkZWZpbmVzIHRoZSBhc3NvY2lhdGVkDQoNCiAgICBtdWx0aWNhc3QgSVAgYWRkcmVzcy4g IEFzIGEgbmV4dCBleGFtcGxlLCB0aGUgc2FtZSBlbmRwb2ludCBjYW4gYmUNCg0KDQoNCg0KDQoN Cg0KUmFobWFuICYgRGlqayAgICAgICAgICAgIEV4cGlyZXMgQXByaWwgMjIsIDIwMTMgICAgICAg ICAgICAgICAgIFtQYWdlDQoNCjhdDQoNCg0KDQoNCkludGVybmV0LURyYWZ0ICAgICAgICBHcm91 cCBDb21tdW5pY2F0aW9uIGZvciBDb0FQICAgICAgICAgIE9jdG9iZXINCg0KMjAxMg0KDQoNCg0K DQoNCiAgICBhZGRlZCB0byBhbm90aGVyIGdyb3VwIGJ5IGEgUE9TVCBvbiB0aGUgcmVzb3VyY2Ug d2l0aCBhIEpTT04gZ3JvdXANCg0KICAgIG9iamVjdDoNCg0KDQoNCiAgICAgICBSZXE6IFBPU1Qg L2dwIChDb250ZW50LUZvcm1hdDogYXBwbGljYXRpb24vanNvbikNCg0KICAgICAgIHsgIm4iOiAi Zmxvb3IxLndlc3QuYmxkZzYuZXhhbXBsZS5jb20iLA0KDQogICAgICAgICAiaXAiOiAiZmYwNTo6 NDIwMDpmN2ZlOmVkMzc6MTRjYiIgfQ0KDQogICAgICAgUmVzOiAyLjA0IENoYW5nZWQNCg0KDQoN CiAgICBEZXNpZ24gMzogZGVmaW5lIG5hbWVkIHN1Yi1yZXNvdXJjZXMsIGVhY2ggc3ViLXJlc291 cmNlIHJlcHJlc2VudGluZw0KDQogICAgYSBncm91cCBtZW1iZXJzaGlwLiAgVGhlIHBheWxvYWQg b2YgdGhlIHN1Yi1yZXNvdXJjZSBtYXkgYmUgSlNPTiBvcg0KDQphDQoNCiAgICBzaW1wbGUgcHJl LWRlZmluZWQgZm9ybWF0LiAgT3IgYWx0ZXJuYXRpdmVseSwgaW5mb3JtYXRpb24gaXMNCg0KcHJv dmlkZWQNCg0KICAgIHZpYSBQT1NUIHdpdGggcXVlcnkgcGFyYW1ldGVycy4NCg0KDQoNCi9jb21t ZW50IGFyZSB0aGVzZSBtdXR1YWxseSBleGNsdXNpdmUgZGVzaWducz8NCg0KL2NvbW1lbnQgZGVz aWduIDIgd2l0aG91dCBKU09OIGlzIGFscyBwb3NzaWJsZQ0KDQovY29tbWVudCBkZXNpZ24gd2l0 aCBTUlYgYW5kIFRYdCByZWNvcmRzIGlzIGFsc28gcG9zc2libGUNCg0KL2NvbW1lbnQgdGhlcmUg YXJlIDIgd2F5czogKDEpIHRoZSBub2RlIHF1ZXJpZXMgdG8gd2hpY2ggZ3JvdXAgaXQNCg0KYmVs b25ncw0KDQovY29tbWVudCAgKDIpIGFuIGluc3RhbGF0aW9uIHRvb2xzIGluc3RydWN0cyB0aGUg bm9kZSB0byB3aGljaCBncm91cHMNCg0KaXQgYmVsb25ncw0KDQovY29tbWVudCBub3QgY2xlYXIg aW4gdGV4dCB0aGF0IHRoaXMgY2hvaWNlIGV4aXN0cyBvciB0aGF0IGEgY2hvaWNlIHdhcw0KDQpt YWRlLg0KDQoNCg0KMy42LiAgQ29uZ2VzdGlvbiBDb250cm9sDQoNCg0KDQogICAgTXVsdGljYXN0 IENvQVAgcmVxdWVzdHMgbWF5IHJlc3VsdCBpbiBhIG11bHRpdHVkZSBvZiByZXBsaWVzIGZyb20N Cg0KICAgIGRpZmZlcmVudCBub2RlcywgcG90ZW50aWFsbHkgY2F1c2luZyBjb25nZXN0aW9uLiAg VGhlcmVmb3JlIHNlbmRpbmcNCg0KICAgIG11bHRpY2FzdA0KDQovcyByZXF1ZXN0cyAvcyByZXBs aWVzDQoNCiAgICAgc2hvdWxkIGJlIGNvbnNlcnZhdGl2ZWx5IGNvbnRyb2xsZWQuDQoNCg0KDQog ICAgVGhlIGJhc2UgQ29BUCBkcmFmdCBbSS1ELmlldGYtY29yZS1jb2FwXSByZWR1Y2VzIG11bHRp Y2FzdC1zcGVjaWZpYw0KDQogICAgY29uZ2VzdGlvbiByaXNrcyB0aHJvdWdoIHRoZSBmb2xsb3dp bmcgbWVhc3VyZXM6DQoNCg0KDQogICAgbyAgQSBzZXJ2ZXIgTUFZIGNob29zZSBub3QgdG8gcmVz cG9uZCB0byBhIG11bHRpY2FzdCByZXF1ZXN0IGlmDQoNCiAgICAgICB0aGVyZSdzIG5vdGhpbmcg dXNlZnVsIHRvIHJlc3BvbmQgKGUuZy4gZXJyb3Igb3IgZW1wdHkgcmVzcG9uc2UpLg0KDQoNCg0K ICAgIG8gIEEgc2VydmVyIFNIT1VMRCBsaW1pdCB0aGUgc3VwcG9ydCBmb3IgbXVsdGljYXN0IHJl cXVlc3RzIHRvDQoNCiAgICAgICBzcGVjaWZpYyByZXNvdXJjZXMgd2hlcmUgbXVsdGljYXN0IG9w ZXJhdGlvbiBpcyByZXF1aXJlZC4NCg0KDQoNCiAgICBvICBBIG11bHRpY2FzdCByZXF1ZXN0IE1V U1QgYmUgTm9uLUNvbmZpcm1hYmxlLg0KDQovY29tbWVudCB3aGF0IGFib3V0IHRoZSByZXBseT8N Cg0KDQoNCiAgICBvICBBIHNlcnZlciBkb2VzIG5vdCByZXNwb25kIGltbWVkaWF0ZWx5IHRvIGEg bXVsdGljYXN0IHJlcXVlc3QsIGJ1dA0KDQogICAgICAgU0hPVUxEIGZpcnN0IHdhaXQgZm9yIGEg dGltZSB0aGF0IGlzIHJhbmRvbWx5IHBpY2tlZCB3aXRoaW4gYQ0KDQogICAgICAgcHJlZGV0ZXJt aW5lZCB0aW1lIGludGVydmFsIGNhbGxlZCB0aGUgTGVpc3VyZS4NCg0KDQoNCiAgICBvICBBIHNl cnZlciBTSE9VTEQgTk9UIGFjY2VwdCBtdWx0aWNhc3QgcmVxdWVzdHMgdGhhdCBjYW4gbm90IGJl DQoNCiAgICAgICBhdXRoZW50aWNhdGVkLg0KDQovY29tbWVudCBpbnZva2luZyBhcyBtYW55IGNl cnRpZmljYXRlcz8NCg0KDQoNCiAgICBBZGRpdGlvbmFsIGd1aWRlbGluZXMgdG8gcmVkdWNlIGNv bmdlc3Rpb24gcmlza3MgYXJlOg0KDQoNCg0KICAgIG8gIEEgc2VydmVyIGluIGFuIExMTiBzaG91 bGQgb25seSBzdXBwb3J0IG11bHRpY2FzdCBHRVQgZm9yDQoNCnJlc291cmNlcw0KDQogICAgICAg dGhhdCBhcmUgc21hbGwsIGUuZy4NCg0KL3JlbW92ZSBmb3IgYW4gTExOIHRoYXQgY291bGQgbWVh bg0KDQogICAgICAgdGhlIHBheWxvYWQgb2YgdGhlDQoNCiAgICAgICByZXNwb25zZSBmaXRzIGlu dG8gYSBzaW5nbGUgbGluay1sYXllciBmcmFtZS4NCg0KDQoNCiAgICBvICBBIHNlcnZlciBjYW4g bWluaW1pemUgdGhlIHBheWxvYWQgbGVuZ3RoIGluIHJlc3BvbnNlIHRvIGENCg0KICAgICAgIG11 bHRpY2FzdCBHRVQgb24gIi8ud2VsbC1rbm93bi9jb3JlIiBieSB1c2luZyBoaWVyYXJjaHkgaW4N Cg0KICAgICAgIGFycmFuZ2luZyBsaW5rIGRlc2NyaXB0aW9ucyBmb3IgdGhlIHJlc3BvbnNlLiAg QW4gZXhhbXBsZSBvZiB0aGlzDQoNCiAgICAgICBpcyBnaXZlbiBpbiBTZWN0aW9uIDUgb2YgW1JG QzY2OTBdLg0KDQoNCg0KDQoNCg0KDQoNCg0KUmFobWFuICYgRGlqayAgICAgICAgICAgIEV4cGly ZXMgQXByaWwgMjIsIDIwMTMgICAgICAgICAgICAgICAgIFtQYWdlDQoNCjldDQoNCg0KDQoNCklu dGVybmV0LURyYWZ0ICAgICAgICBHcm91cCBDb21tdW5pY2F0aW9uIGZvciBDb0FQICAgICAgICAg IE9jdG9iZXINCg0KMjAxMg0KDQoNCg0KDQoNCiAgICBvICBQcmVmZXJhYmx5IElQIG11bHRpY2Fz dCB3aXRoIGxpbmstbG9jYWwgc2NvcGUgc2hvdWxkIGJlIHVzZWQsDQoNCiAgICAgICByYXRoZXIg dGhhbiBnbG9iYWwgb3Igc2l0ZS1sb2NhbC4NCg0KDQoNCiAgICBvICBUaGUgSG9wIExpbWl0IGZp ZWxkIGluIHRoZSBJUHY2IHBhY2tldCBzaG91bGQgYmUgY2hvc2VuIGFzIGxvdyBhcw0KDQogICAg ICAgcG9zc2libGUgKGlmIHRoZSBDb0FQL0lQIHN0YWNrIGFsbG93cyBzZXR0aW5nIG9mIHRoaXMg dmFsdWUuICBUQkQNCg0KICAgICAgIC0gZGlzY3VzcyB3aGV0aGVyIHRoaXMgZ3VpZGVsaW5lIGlz IHJlbGV2YW50L3JlYWxpc3RpYyBpbiBDb0FQDQoNCiAgICAgICBjb250ZXh0KQ0KDQoNCg0KMy43 LiAgQ29BUCBNdWx0aWNhc3QgYW5kIEhUVFAgVW5pY2FzdCBJbnRlcndvcmtpbmcNCg0KDQoNCi9j b21tZW50IGEgcmVmZXJlbmNlIHdpbGwgc3VmZmljZQ0KDQoNCg0KICAgIENvQVAgc3VwcG9ydHMg b3BlcmF0aW9uIG92ZXIgVURQIG11bHRpY2FzdCwgd2hpbGUgSFRUUCBkb2VzIG5vdC4NCg0KRm9y DQoNCiAgICB1c2UgY2FzZXMgd2hlcmUgaXQgaXMgcmVxdWlyZWQgdGhhdCBDb0FQIGdyb3VwIGNv bW11bmljYXRpb24gaXMNCg0KICAgIGluaXRpYXRlZCBmcm9tIGFuIEhUVFAgZW5kLXBvaW50LCBp dCB3b3VsZCBiZSBhZHZhbnRhZ2VvdXMgaWYgdGhlDQoNCiAgICBIVFRQLUNvQVAgUHJveHkgc3Vw cG9ydHMgbWFwcGluZyBvZiBIVFRQIHVuaWNhc3QgdG8gQ29BUCBncm91cA0KDQogICAgY29tbXVu aWNhdGlvbiBiYXNlZCBvbiBJUCBtdWx0aWNhc3QuDQoNCi9yZW1vdmUgT25lIHBvc3NpYmxlIHdh eSBvZiBvcGVyYXRpb24NCg0KL3JlbW92ZSAgICBvZiBzdWNoIEhUVFAtQ29BUCBQcm94eSBpcyBp bGx1c3RyYXRlZCBpbiBGaWd1cmUgMS4NCg0KICAgIE5vdGUgdGhhdCB0aGlzDQoNCiAgICB0b3Bp YyBpcyBjb3ZlcmVkIGluIG1vcmUgZGV0YWlsIGluDQoNCiAgICBbSS1ELmNhc3RlbGxhbmktY29y ZS1hZHZhbmNlZC1odHRwLW1hcHBpbmddLg0KDQoNCg0KL3JlbW92ZQ0KDQoNCg0KDQoNCiAgICAg ICAgICAgIENvQVAgICAgTWNhc3QgICAgQ29BUCAgICBNY2FzdCAgIEhUVFAtQ29BUCAgICAgICAg ICAgSFRUUA0KDQogICAgICAgICAgIE5vZGUgMSAgIFJ0cjEgICAgTm9kZSAyICAgIFJ0cjIgICAg UHJveHkgICAgICAgICAgICAgTm9kZSAzDQoNCiAgICAgICAgICAgICB8ICAgICAgIHwgICAgICAg ICB8ICAgICAgIHwgICAgICAgfCAgICAgICAgICAgICAgICAgICB8DQoNCiAgICAgICAgICAgICB8 TUxEIFJFUVVFU1QgICAgICB8ICAgICAgIHwgICAgICAgfCAgICAgICAgICAgICAgICAgICB8DQoN CiAgICAgICAgICAgICB8KEpvaW4gR3JvdXAgWCkgICB8ICAgICAgIHwgICAgICAgfCAgICAgICAg ICAgICAgICAgICB8DQoNCiAgICAgICAgICAgICB8LS1MTC0tPnwgICAgICAgICB8ICAgICAgIHwg ICAgICAgfCAgICAgICAgICAgICAgICAgICB8DQoNCiAgICAgICAgICAgICB8ICAgICAgIHwgICAg ICAgICB8TUxEIFJFUVVFU1QgICAgfCAgICAgICAgICAgICAgICAgICB8DQoNCiAgICAgICAgICAg ICB8ICAgICAgIHwgICAgICAgICB8KEpvaW4gR3JvdXAgWCkgfCAgICAgICAgICAgICAgICAgICB8 DQoNCiAgICAgICAgICAgICB8ICAgICAgIHwgICAgICAgICB8LS1MTC0tPnwgICAgICAgfCAgICAg ICAgICAgICAgICAgICB8DQoNCiAgICAgICAgICAgICB8ICAgICAgIHwgICAgICAgICB8ICAgICAg IHwgICAgICAgfCAgSFRUUCBSRVFVRVNUICAgICB8DQoNCiAgICAgICAgICAgICB8ICAgICAgIHwg ICAgICAgICB8ICAgICAgIHwgICAgICAgfCAgICAoVVJJIHRvICAgICAgICB8DQoNCiAgICAgICAg ICAgICB8ICAgICAgIHwgICAgICAgICB8ICAgICAgIHwgICAgICAgfCAgIHVuaWNhc3QgYWRkcikg ICB8DQoNCiAgICAgICAgICAgICB8ICAgICAgIHwgICAgICAgICB8ICAgICAgIHwgICAgICAgfDwg LS0tLS0tLS0tLS0tLS0tLS18DQoNCiAgICAgICAgICAgICB8ICAgICAgIHwgICAgICAgICB8ICAg ICAgIHwgICAgICAgfCAgICAgICAgICAgICAgICAgICB8DQoNCiAgICAgICAgICAgICB8ICAgICAg IHwgICAgICAgICB8ICAgUmVzb2x2ZSBIVFRQIFJlcXVlc3QtTGluZSBVUkkgICB8DQoNCiAgICAg ICAgICAgICB8ICAgICAgIHwgICAgICAgICB8ICAgdG8gR3JvdXAgWCBtdWx0aWNhc3QgYWRkcmVz cyAgICB8DQoNCiAgICAgICAgICAgICB8ICAgICAgIHwgICAgICAgICB8ICAgICAgIHwgICAgICAg fCAgICAgICAgICAgICAgICAgICB8DQoNCiAgICAgICAgICAgICB8IENvQVAgUkVRVUVTVCAodG8g bXVsdGljYXN0IGFkZHIpfCAgICAgICAgICAgICAgICAgICB8DQoNCiAgICAgICAgICAgICB8PCAt LS0tLS08LS0tLS0tLS0tPC0tLS0tLS08LS0tLS0tfCAgICAgICAgICAgICAgICAgICB8DQoNCiAg ICAgICAgICAgICB8ICAgICAgIHwgICAgICAgICB8ICAgICAgIHwgICAgICAgfCAgICAgICAgICAg ICAgICAgICB8DQoNCiAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAg ICAgfCAgICAgICAgICAgICAgICAgICB8DQoNCiAgICAgICAgICAgICB8ICAgICAob3B0aW9uYWwp IENvQVAgUkVTUE9OU0UocykgfCAgICAgICAgICAgICAgICAgICB8DQoNCiAgICAgICAgICAgICB8 ICAgICAgICAgICAgICAgICB8LS0tLS0tLS0tLS0tLS0+fCAgICAgICAgICAgICAgICAgICB8DQoN CiAgICAgICAgICAgICB8LS0tLS0tLS0tLS0tLS0tLS18LS0tLS0tLS0tLS0tLS0+fCAgIEFnZ3Jl Z2F0ZWQgICAgICB8DQoNCiAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICB8ICAgICAgICAg ICAgICAgfCAgSFRUUCBSRVNQT05TRSAgICB8DQoNCiAgICAgICAgICAgICB8ICAgICAgICAgICAg ICAgICB8ICAgICAgICAgICAgICAgfC0tLS0tLS0tLS0tLS0tLS0tLT58DQoNCiAgICAgICAgICAg ICB8ICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICB8 DQoNCg0KDQoNCg0KDQoNCg0KDQpSYWhtYW4gJiBEaWprICAgICAgICAgICAgRXhwaXJlcyBBcHJp bCAyMiwgMjAxMyAgICAgICAgICAgICAgICBbUGFnZQ0KDQoxMF0NCg0KDQoNCg0KSW50ZXJuZXQt RHJhZnQgICAgICAgIEdyb3VwIENvbW11bmljYXRpb24gZm9yIENvQVAgICAgICAgICAgT2N0b2Jl cg0KDQoyMDEyDQoNCg0KDQoNCg0KICAgICAgICAgICBGaWd1cmUgMTogQ29BUCBNdWx0aWNhc3Qg YW5kIEhUVFAgVW5pY2FzdCBJbnRlcndvcmtpbmcNCg0KDQoNCiAgICBOb3RlIHRoYXQgRmlndXJl IDEgaWxsdXN0cmF0ZXMgdGhlIGNhc2Ugb2YgSVAgbXVsdGljYXN0IGFzIHRoZQ0KDQogICAgdW5k ZXJseWluZyBncm91cCBjb21tdW5pY2F0aW9ucyBtZWNoYW5pc20uICBNTEQgZGVub3RlcyB0aGUN Cg0KTXVsdGljYXN0DQoNCiAgICBMaXN0ZW5lciBEaXNjb3ZlcnkgcHJvdG9jb2wgKFtSRkMzODEw XSwgQXBwZW5kaXggQSkgYW5kIExMIGRlbm90ZXMgYQ0KDQogICAgTGluay1Mb2NhbCBtdWx0aWNh c3QuDQoNCg0KDQogICAgQSBrZXkgcG9pbnQgaW4gRmlndXJlIDEgaXMgdGhhdCB0aGUgaW5jb21p bmcgSFRUUCBSZXF1ZXN0IChmcm9tIG5vZGUNCg0KICAgIDMpIHdpbGwgY2FycnkgYSBIb3N0IHJl cXVlc3QtaGVhZGVyIGZpZWxkIHRoYXQgcmVzb2x2ZXMgaW4gdGhlDQoNCiAgICBnZW5lcmFsIElu dGVybmV0IHRvIHRoZSBwcm94eSBub2RlLiAgQXQgdGhlIHByb3h5IG5vZGUsIHRoaXMNCg0KaG9z dG5hbWUNCg0KICAgIGFuZC9vciB0aGUgUmVxdWVzdC1MaW5lIFVSSSB3aWxsIHRoZW4gcG9zc2li bHkgYmUgbWFwcGVkIChhcw0KDQpkZXRhaWxlZA0KDQogICAgaW4gW0ktRC5jYXN0ZWxsYW5pLWNv cmUtaHR0cC1tYXBwaW5nXSkgYW5kIGFnYWluIHJlc29sdmVkICh3aXRoIHRoZQ0KDQogICAgQ29B UCBzY2hlbWUpIHRvIGFuIElQIG11bHRpY2FzdCBhZGRyZXNzLiAgVGhpcyBtYXkgYmUgYWNjb21w bGlzaGVkLA0KDQogICAgZm9yIGV4YW1wbGUsIGJ5IHVzaW5nIEROUyBvciBETlMtU0QgKFNlY3Rp b24gMy4zKS4gIFRoZSBwcm94eSBub2RlDQoNCiAgICB3aWxsIHRoZW4gSVAgbXVsdGljYXN0IHRo ZSBDb0FQIFJlcXVlc3QgKGNvcnJlc3BvbmRpbmcgdG8gdGhlDQoNCiAgICByZWNlaXZlZCBIVFRQ IFJlcXVlc3QpIHZpYSBtdWx0aWNhc3Qgcm91dGVycyB0byB0aGUgYXBwcm9wcmlhdGUNCg0Kbm9k ZXMNCg0KICAgIChpLmUuIG5vZGVzIDEgYW5kIDIpLg0KDQoNCg0KICAgIEluIHRlcm1zIG9mIHRo ZSBIVFRQIFJlc3BvbnNlLCBGaWd1cmUgMSBpbGx1c3RyYXRlcyB0aGF0IGl0IHdpbGwgYmUNCg0K ICAgIGdlbmVyYXRlZCBieSB0aGUgcHJveHkgbm9kZSBiYXNlZCBvbiBhZ2dyZWdhdGVkIHJlc3Bv bnNlcyBvZiB0aGUNCg0KQ29BUA0KDQogICAgbm9kZXMgYW5kIHNlbnQgYmFjayB0byB0aGUgY2xp ZW50IGluIHRoZSBnZW5lcmFsIEludGVybmV0IHRoYXQgc2VudA0KDQogICAgdGhlIEhUVFAgUmVx dWVzdCAoaS5lLiBub2RlIDEpLiAgSW4NCg0KICAgIFtJLUQuY2FzdGVsbGFuaS1jb3JlLWFkdmFu Y2VkLWh0dHAtbWFwcGluZ10gdGhlIEhUVFAgUmVzcG9uc2UgdGhhdA0KDQogICAgdGhlIFByb3h5 IG1heSB1c2UgdG8gYWdncmVnYXRlIG11bHRpcGxlIENvQVAgcmVzcG9uc2VzIGlzIGRlc2NyaWJl ZA0KDQogICAgaW4gbW9yZSBkZXRhaWwuICBTbyBpbiB0ZXJtcyBvZiBvdmVyYWxsIG9wZXJhdGlv biwgdGhlIENvQVAgcHJveHkNCg0KY2FuDQoNCiAgICBiZSBjb25zaWRlcmVkIHRvIGJlIGEgIm5v bi10cmFuc3BhcmVudCIgcHJveHkgYWNjb3JkaW5nIHRvDQoNCltSRkMyNjE2XS4NCg0KICAgIFNw ZWNpZmljYWxseSwgW1JGQzI2MTZdIHN0YXRlcyB0aGF0IGEgIm5vbi10cmFuc3BhcmVudCBwcm94 eSBpcyBhDQoNCiAgICBwcm94eSB0aGF0IG1vZGlmaWVzIHRoZSByZXF1ZXN0IG9yIHJlc3BvbnNl IGluIG9yZGVyIHRvIHByb3ZpZGUgc29tZQ0KDQogICAgYWRkZWQgc2VydmljZSB0byB0aGUgdXNl ciBhZ2VudCwgc3VjaCBhcyBncm91cCBhbm5vdGF0aW9uIHNlcnZpY2VzLA0KDQogICAgbWVkaWEg dHlwZSB0cmFuc2Zvcm1hdGlvbiwgcHJvdG9jb2wgcmVkdWN0aW9uIG9yIGFub255bWl0eQ0KDQog ICAgZmlsdGVyaW5nLiINCg0KDQoNCiAgICBBbiBhbHRlcm5hdGl2ZSB0byB0aGUgYWJvdmUgaXMg dXNpbmcgYSBGb3J3YXJkIFByb3h5LiAgSW4gdGhpcyBjYXNlLA0KDQogICAgdGhlIENvQVAgcmVx dWVzdCBVUkkgaXMgY2FycmllZCBpbiB0aGUgSFRUUCBSZXF1ZXN0LUxpbmUgKGFzIGRlZmluZWQN Cg0KICAgIGluIFtJLUQuaWV0Zi1jb3JlLWNvYXBdIFNlY3Rpb24gMTAuMikgaW4gYSBIVFRQIHJl cXVlc3Qgc2VudCB0byB0aGUNCg0KICAgIElQIGFkZHJlc3Mgb2YgdGhlIFByb3h5Lg0KDQoNCg0K L2VuZCByZW1vdmUNCg0KDQoNCg0KDQo0LiAgVXNlIENhc2VzIGFuZCBDb3JyZXNwb25kaW5nIFBy b3RvY29sIEZsb3dzDQoNCg0KDQo0LjEuICBJbnRyb2R1Y3Rpb24NCg0KDQoNCiAgICBUaGUgdXNl IG9mIENvQVAgZ3JvdXAgY29tbXVuaWNhdGlvbiBpcyBzaG93biBpbiB0aGUgY29udGV4dCBvZiB0 aGUNCg0KICAgIGZvbGxvd2luZyB1c2UgY2FzZXMgYW5kIGNvcnJlc3BvbmRpbmcgcHJvdG9jb2wg Zmxvd3M6DQoNCg0KDQogICAgbyAgRGlzY292ZXJ5IG9mIFJlc291cmNlIERpcmVjdG9yeTogZGlz Y292ZXJpbmcgdGhlIGxvY2FsIENvUkUgUkQNCg0KICAgICAgIHdoaWNoIGNvbnRhaW5zIGxpbmtz IChVUklzKSB0byByZXNvdXJjZXMgc3RvcmVkIG9uIG90aGVyIHNlcnZlcnMNCg0KICAgICAgIFtS RkM2NjkwXS4NCg0KDQoNCg0KDQoNCg0KUmFobWFuICYgRGlqayAgICAgICAgICAgIEV4cGlyZXMg QXByaWwgMjIsIDIwMTMgICAgICAgICAgICAgICAgW1BhZ2UNCg0KMTFdDQoNCg0KDQoNCkludGVy bmV0LURyYWZ0ICAgICAgICBHcm91cCBDb21tdW5pY2F0aW9uIGZvciBDb0FQICAgICAgICAgIE9j dG9iZXINCg0KMjAxMg0KDQoNCg0KDQoNCiAgICBvICBMaWdodGluZyBDb250cm9sOiBzeW5jaHJv bm91cyBvcGVyYXRpb24gb2YgYSBncm91cCBvZiA2TG9XUEFODQoNCiAgICAgICBbUkZDNDk0NF0g SVB2Ni1jb25uZWN0ZWQgbGlnaHRzDQoNCg0KDQogICAgbyAgUGFyYW1ldGVyIFVwZGF0ZTogdXBk YXRpbmcgcGFyYW1ldGVycy9zZXR0aW5ncyBzaW11bHRhbmVvdXNseSBpbg0KDQphDQoNCiAgICAg ICBsYXJnZSBncm91cCBvZiBkZXZpY2VzIGluIGEgYnVpbGRpbmcvY2FtcHVzIGNvbnRyb2wNCg0K ICAgICAgIChbSS1ELnZhbmRlcnN0b2stY29yZS1iY10pIGFwcGxpY2F0aW9uIC0tLSBUQkQNCg0K DQoNCi8gY29tbWVudCBJIHN1Z2dlc3QgdG8gcmVtb3ZlIEZpcm13YXJlIFVwZGF0ZSBhbmQgR3Jv dXBzIHN0YXR1cyByZXBvcnQNCg0KL2NvbW1lbnQgdGhlIG9uZXMgYWJvdmUgYXJlIGRpZmZpY3Vs dCBlbm91Z2gsIGFuZCBJIGRvdWJ0IHRoYXQNCg0Kc2ltdWx0YW5laXR5DQoNCi9jb21tZW50ICht b3RpdmF0aW9uIG9mIG11bHRpY2FzdCkgaXMgaW52b2x2ZWQgaGVyZQ0KDQoNCg0KDQoNCiAgICBv ICBGaXJtd2FyZSBVcGRhdGU6IGVmZmljaWVudGx5IHVwZGF0aW5nIGZpcm13YXJlIHNpbXVsdGFu ZW91c2x5IGluDQoNCmENCg0KICAgICAgIGxhcmdlIGdyb3VwIG9mIGRldmljZXMgaW4gYSBidWls ZGluZy9jYW1wdXMgY29udHJvbA0KDQogICAgICAgKFtJLUQudmFuZGVyc3Rvay1jb3JlLWJjXSkg YXBwbGljYXRpb24gLS0tIFRCRCBzdWdnZXN0cyBhDQoNCiAgICAgICBtdWx0aWNhc3QgZXh0ZW5z aW9uIG9mIGNvcmUtYmxvY2suDQoNCg0KDQogICAgbyAgR3JvdXAgU3RhdHVzIFJlcG9ydDogcmVx dWVzdGluZyBzdGF0dXMgaW5mb3JtYXRpb24gb3IgZXZlbnQNCg0KICAgICAgIHJlcG9ydHMgZnJv bSBhIGdyb3VwIG9mIGRldmljZXMgaW4gYSBidWlsZGluZy9jYW1wdXMgY29udHJvbA0KDQogICAg ICAgYXBwbGljYXRpb24gLS0tIFRCRCwgbWF5IHJlcXVpcmUgcmVsaWFibGUgZ3JvdXAgY29tbXVu aWNhdGlvbiB0bw0KDQogICAgICAgYmUgZmVhc2libGUuDQoNCg0KDQo0LjIuICBOZXR3b3JrIENv bmZpZ3VyYXRpb24NCg0KDQoNCiAgICBXZSBhc3N1bWUgdGhlIGZvbGxvd2luZyBuZXR3b3JrIGNv bmZpZ3VyYXRpb24gZm9yIGFsbCB0aGUgdXNlIGNhc2VzDQoNCiAgICBhcyBzaG93biBpbiBGaWd1 cmUgMjoNCg0KL2NvbW1lbnQgdGhlIGNvbmZpZ3VyYXRpb25zIGZyaWdodGVuIG1lDQoNCi9jb21t ZW50IGZyb20gY29tcGxldGVuZXNzIGNvbnNpZGVyYXRpb25zIEkgY2FuIGltYWdpbmUgZXZlbiBt b3JlDQoNCmNvbXBsZXggb25lcw0KDQovY29tbWVudCBJdCBtaWdodCBiZSB1c2VmdWwgaWYgdGhl IHByYWN0aWNhbCBpbXBvc3NpYmlsaXR5IG9mIHNvbWUNCg0KY29uZmlndXJhdGlvbnMgaXMgaGln aCBsaWdodGVkDQoNCg0KDQoNCg0KICAgIG8gIEEgbGFyZ2Ugcm9vbSAoUm9vbS1BKSB3aXRoIHRo cmVlIGxpZ2h0cyAoTGlnaHQtMSwgTGlnaHQtMiwNCg0KICAgICAgIExpZ2h0LTMpIGNvbnRyb2xs ZWQgYnkgYSBMaWdodCBTd2l0Y2guICBUaGUgZGV2aWNlcyBhcmUgb3JnYW5pemVkDQoNCiAgICAg ICBpbnRvIHR3byA2TG9XUEFOIHN1Ym5ldHMuDQoNCi9jb21tZW50IG9uZSBzdWJuZXQgaXMgZW5v dWdoIGZvciBtZQ0KDQoNCg0KL3JlbW92ZQ0KDQoNCg0KICAgIG8gIExpZ2h0LTEgYW5kIHRoZSBM aWdodCBTd2l0Y2ggYXJlIGNvbm5lY3RlZCB0byBhIHJvdXRlciAoUnRyLTEpDQoNCiAgICAgICB3 aGljaCBpcyBhbHNvIGEgQ29BUCBQcm94eSwgYSBDb0FQIFJlc291cmNlIERpcmVjdG9yeSAoUkQp IGFuZCBhDQoNCiAgICAgICA2TG9XUEFOIEJvcmRlciBSb3V0ZXIgKDZMQlIpLg0KDQoNCg0KICAg IG8gIExpZ2h0LTIgYW5kIHRoZSBMaWdodC0zIGFyZSBjb25uZWN0ZWQgdG8gYW5vdGhlciByb3V0 ZXIgKFJ0ci0yKQ0KDQogICAgICAgd2hpY2ggaXMgYWxzbyBhIENvQVAgUHJveHksIGEgQ29BUCBS RCBhbmQgYSA2TEJSLg0KDQoNCg0KICAgIG8gIFRoZSByb3V0ZXJzIGFyZSBjb25uZWN0ZWQgdG8g YW4gSVB2NiBuZXR3b3JrIGJhY2tib25lIHdoaWNoIGlzDQoNCiAgICAgICBhbHNvIG11bHRpY2Fz dCBlbmFibGVkLiAgSW4gdGhlIGdlbmVyYWwgY2FzZSwgdGhpcyBtZWFucyB0aGUNCg0KICAgICAg IG5ldHdvcmsgYmFja2JvbmUgYW5kIDZMQlJzIHN1cHBvcnQgYSBQSU0gYmFzZWQgbXVsdGljYXN0 IHJvdXRpbmcNCg0KICAgICAgIHByb3RvY29sLCBhbmQgTUxEIGZvciBmb3JtaW5nIGdyb3Vwcy4g IEluIGEgbGltaXRlZCBjYXNlLCBpZiB0aGUNCg0KICAgICAgIG5ldHdvcmsgYmFja2JvbmUgaXMg b25lIGxpbmssIHRoZW4gdGhlIHJvdXRlcnMgb25seSBoYXZlIHRvDQoNCiAgICAgICBzdXBwb3J0 IE1MRC1zbm9vcGluZyAoQXBwZW5kaXggQSkgZm9yIHRoZSBmb2xsb3dpbmcgdXNlIGNhc2VzIHRv DQoNCiAgICAgICB3b3JrLg0KDQoNCg0KDQoNCi9lbmQgcmVtb3ZlDQoNCg0KDQovY29tbWVudCBJ IGNhbiBpbWFnaW5lIHRoYXQgYW4gY2VudHJhbCBjb250cm9sIGlzIHByZXNlbnQgb24gdGhlDQoN CmJhY2tib25lDQoNCi9jb21tZW50IHN3aXRjaCBvciBzZW5zb3Igc2VuZCB1bmljYXN0IHRvIGNl bnRyYWwgY29udHJvbA0KDQovY29tbWVudCBjZW50cmFsIGNvbnRyb2wgc2VuZHMgbXVsdGljYXN0 IHRvIG11bHRpY2FzdCBncm91cCB3aXRoaW4NCg0Kc2luZ2xlIGxvd3Bhbg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNClJhaG1hbiAmIERpamsgICAgICAgICAgICBFeHBpcmVzIEFw cmlsIDIyLCAyMDEzICAgICAgICAgICAgICAgIFtQYWdlDQoNCjEyXQ0KDQoNCg0KDQpJbnRlcm5l dC1EcmFmdCAgICAgICAgR3JvdXAgQ29tbXVuaWNhdGlvbiBmb3IgQ29BUCAgICAgICAgICBPY3Rv YmVyDQoNCjIwMTINCg0KDQoNCg0KDQoNCg0KTmV0d29yaw0KDQoNCg0KQmFja2JvbmUNCg0KDQoN CnwNCg0KICAgICAgICMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIw0KDQp8DQoNCiAgICAgICAjICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgUm9vbS1BICMNCg0KfA0KDQogICAgICAgIyAgICAgICAgICoqKioqKioqKioqKioqKioqKioq KiogICAgICAgICAgICAgICAjDQoNCnwNCg0KICAgICAgICMgICAgICAgKiogIExvV1BBTi0xIChz dWJuZXQtMSkgKiogICAgICAgICAgICAgIw0KDQp8DQoNCiAgICAgICAjICAgICAqICAgICAgICAg ICAgICAgICAgICAgICAgICAgICogICAgICAgICAgICMNCg0KfA0KDQogICAgICAgIyAgICAqICAg ICArLS0tLS0tLS0tLSsgICAgICAgICAgICAgKiAgICAgICAgICAjDQoNCnwNCg0KICAgICAgICMg ICAqICAgICAgfCAgTGlnaHQgICB8LS0tLS0tLSsgICAgICAqICAgICAgICAgIw0KDQp8DQoNCiAg ICAgICAjICAqICAgICAgIHwgIFN3aXRjaCAgfCAgICAgICB8ICAgICAgICogICAgICAgICMNCg0K fA0KDQogICAgICAgIyAgKiAgICAgICArLS0tLS0tLS0tLSsgICstLS0tLS0tLS0rICAqICAgICAg ICAjDQoNCnwNCg0KICAgICAgICMgICogICAgICAgICAgICAgICAgICAgICB8ICBSdHItMQ0KDQp8 LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS18DQoNCiAgICAgICAjICAqICAgICAgICAgICAg ICAgICAgICAgKy0tLS0tLS0tLSsgICogICAgICAgICMNCg0KfA0KDQogICAgICAgIyAgKiAgICAg ICArLS0tLS0tLS0tLSsgICAgICAgIHwgICAgICAqICAgICAgICAjDQoNCnwNCg0KICAgICAgICMg ICAqICAgICAgfCAgTGlnaHQtMSB8LS0tLS0tLS0rICAgICAqICAgICAgICAgIw0KDQp8DQoNCiAg ICAgICAjICAgICogICAgICstLS0tLS0tLS0tKyAgICAgICAgICAgICAqICAgICAgICAgICMNCg0K fA0KDQogICAgICAgIyAgICAgKiAgICAgICAgICAgICAgICAgICAgICAgICAgICAqICAgICAgICAg ICAjDQoNCnwNCg0KICAgICAgICMgICAgICAgKiogICAgICAgICAgICAgICAgICAgICAgKiogICAg ICAgICAgICAgIw0KDQp8DQoNCiAgICAgICAjICAgICAgICAgKioqKioqKioqKioqKioqKioqKioq KiAgICAgICAgICAgICAgICMNCg0KfA0KDQogICAgICAgIyAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAjDQoNCnwNCg0KICAgICAgICMgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIw0KDQp8DQoNCiAgICAgICAjICAgICAgICAq KioqKioqKioqKioqKioqKioqKioqICAgICAgICAgICAgICAgICMNCg0KfA0KDQogICAgICAgIyAg ICAgICAqKiAgTG9XUEFOLTIgKHN1Ym5ldC0yKSAqKiAgICAgICAgICAgICAjDQoNCnwNCg0KICAg ICAgICMgICAgICogICAgICAgICAgICAgICAgICAgICAgICAgICAgKiAgICAgICAgICAgIw0KDQp8 DQoNCiAgICAgICAjICAgICogICAgICstLS0tLS0tLS0tKyAgICAgICAgICAgICAqICAgICAgICAg ICMNCg0KfA0KDQogICAgICAgIyAgICogICAgICB8ICBMaWdodC0yIHwtLS0tLS0tKyAgICAgICog ICAgICAgICAjDQoNCnwNCg0KICAgICAgICMgICogICAgICAgfCAgICAgICAgICB8ICAgICAgIHwg ICAgICAgKiAgICAgICAgIw0KDQp8DQoNCiAgICAgICAjICAqICAgICAgICstLS0tLS0tLS0tKyAg Ky0tLS0tLS0tLSsgICogICAgICAgICMNCg0KfA0KDQogICAgICAgIyAgKiAgICAgICAgICAgICAg ICAgICAgIHwgIFJ0ci0yDQoNCnwtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLXwNCg0KICAg ICAgICMgICogICAgICAgICAgICAgICAgICAgICArLS0tLS0tLS0tKyAgKiAgICAgICAgIw0KDQp8 DQoNCiAgICAgICAjICAqICAgICAgICstLS0tLS0tLS0tKyAgICAgICAgfCAgICAgICogICAgICAg ICMNCg0KfA0KDQogICAgICAgIyAgICogICAgICB8ICBMaWdodC0zIHwtLS0tLS0tLSsgICAgICog ICAgICAgICAjDQoNCnwNCg0KICAgICAgICMgICAgKiAgICAgKy0tLS0tLS0tLS0rICAgICAgICAg ICAgICogICAgICAgICAgIw0KDQp8DQoNCiAgICAgICAjICAgICAqICAgICAgICAgICAgICAgICAg ICAgICAgICAgICogICAgICAgICAgICMNCg0KfA0KDQogICAgICAgIyAgICAgICAqKiAgICAgICAg ICAgICAgICAgICAgICAqKiAgICAgICAgICAgICAjDQoNCnwNCg0KICAgICAgICMgICAgICAgICAq KioqKioqKioqKioqKioqKioqKioqICAgICAgICAgICAgICAgIw0KDQp8DQoNCiAgICAgICAjICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICMNCg0KfA0KDQogICAg ICAjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjDQoNCnwN Cg0KDQoNCnwNCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAr LS0tLS0tLS0rDQoNCnwNCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICB8ICBETlMNCg0KfC0tLS0tLS0tLS0tLS0tLS0tLXwNCg0KICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICB8IFNlcnZlciB8DQoNCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgKy0tLS0tLS0tKw0KDQoNCg0KDQoNCiAgICAgICAg ICAgICBGaWd1cmUgMjogTmV0d29yayBUb3BvbG9neSBvZiBhIExhcmdlIFJvb20gKFJvb20tQSkN Cg0KDQoNCg0KDQoNCg0KDQoNClJhaG1hbiAmIERpamsgICAgICAgICAgICBFeHBpcmVzIEFwcmls IDIyLCAyMDEzICAgICAgICAgICAgICAgIFtQYWdlDQoNCjEzXQ0KDQoNCg0KDQpJbnRlcm5ldC1E cmFmdCAgICAgICAgR3JvdXAgQ29tbXVuaWNhdGlvbiBmb3IgQ29BUCAgICAgICAgICBPY3RvYmVy DQoNCjIwMTINCg0KDQoNCg0KDQo0LjMuICBEaXNjb3Zlcnkgb2YgUmVzb3VyY2UgRGlyZWN0b3J5 DQoNCg0KDQogICAgVGhlIHByb3RvY29sIGZsb3cgZm9yIGRpc2NvdmVyeSBvZiBhIFJEIGZvciB0 aGUgZ2l2ZW4gbmV0d29yayAob2YNCg0KICAgIEZpZ3VyZSAyKSBpcyBzaG93biBpbiBGaWd1cmUg MzoNCg0KDQoNCiAgICBvICBUaGUgZml4dHVyZSBmb3IgTGlnaHQtMiBpcyBpbnN0YWxsZWQgYW5k IHBvd2VyZWQgb24gZm9yIHRoZSBmaXJzdA0KDQogICAgICAgdGltZS4NCg0KDQoNCiAgICBvICBM aWdodC0yIHdpbGwgdGhlbiBzZWFyY2ggZm9yIHRoZSBsb2NhbCBSRCAoUkQtMikgYnkgc2VuZGlu ZyBvdXQgYQ0KDQogICAgICAgR0VUIHJlcXVlc3QgKHdpdGggdGhlICIvLndlbGwta25vd24vY29y ZT9ydD1jb3JlLnJkIiByZXF1ZXN0IFVSSSkNCg0KICAgICAgIHRvIHRoZSBzaXRlLWxvY2FsICJB bGwgQ29BUCBOb2RlcyIgYWRkcmVzcy4gIEluIHRoaXMgY2FzZSwgdGhlDQoNCiAgICAgICBzaXRl IGlzIGFzc3VtZWQgdG8gaW5jbHVkZSBhbGwgbm9kZXMgaW4gdGhlIHN1Ym5ldC4NCg0KDQoNCiAg ICBvICBUaGlzIG11bHRpY2FzdCBtZXNzYWdlIHdpbGwgdGhlbiBnbyB0byBlYWNoIG5vZGUgaW4g c3VibmV0LTIuDQoNCiAgICAgICBIb3dldmVyLCBvbmx5IFJ0ci0yIChSRC0yKSB3aWxsIHJlc3Bv bmQgYmVjYXVzZSB0aGUgR0VUIGlzDQoNCiAgICAgICBxdWFsaWZpZWQgYnkgdGhlIHF1ZXJ5IHN0 cmluZyAiP3J0PWNvcmUucmQiLg0KDQoNCg0KICAgIG8gIE5vdGUgdGhhdCB0aGUgZmxvdyBpcyBz aG93biBvbmx5IGZvciBMaWdodC0yIGZvciBjbGFyaXR5Lg0KDQpTaW1pbGFyDQoNCiAgICAgICBm bG93cyB3aWxsIGhhcHBlbiBmb3IgTGlnaHQtMSwgTGlnaHQtMyBhbmQgdGhlIExpZ2h0IFN3aXRj aCB3aGVuDQoNCiAgICAgICB0aGV5IGFyZSBmaXJzdCBwb3dlcmVkIG9uLg0KDQoNCg0KICAgIFRo ZSBSRCBtYXkgYWxzbyBiZSBkaXNjb3ZlcmVkIGJ5IG90aGVyIG1lYW5zIHN1Y2ggYXMgYnkgYXNz dW1pbmcgYQ0KDQogICAgZGVmYXVsdCBsb2NhdGlvbiAoZS5nLiBvbiBhIDZMQlIpLCB1c2luZyBE SENQLCBhbnljYXN0IGFkZHJlc3MsIGV0Yy4NCg0KICAgIEhvd2V2ZXIsIHRoZXNlIGFwcHJvYWNo ZXMgZG8gbm90IGludm9rZSBDb0FQIGdyb3VwIGNvbW11bmljYXRpb24gc28NCg0KICAgIGFyZSBu b3QgZnVydGhlciBkaXNjdXNzZWQgaGVyZS4NCg0KDQoNCiAgICBGb3Igb3RoZXIgZGlzY292ZXJ5 IHVzZSBjYXNlcyBzdWNoIGFzIGRpc2NvdmVyaW5nIGxvY2FsIENvQVANCg0Kc2VydmVycywNCg0K ICAgIHNlcnZpY2VzIG9yIHJlc291cmNlcyBncm91cCBjb21tdW5pY2F0aW9uIGNhbiBiZSB1c2Vk IGluIGEgc2ltaWxhcg0KDQogICAgZmFzaGlvbiBhcyBpbiB0aGUgYWJvdmUgdXNlIGNhc2UuICBC b3RoIExpbmstTG9jYWwgKExMKSBhbmQgc2l0ZS0NCg0KICAgIGxvY2FsIGRpc2NvdmVyeSBhcmUg cG9zc2libGUgdGhpcyB3YXkuDQoNCg0KDQovY29tbWVudCB0aGUgUkQgZGlzY292ZXJ5IHdpbGwg YmUgbW9yZSBjb21wbGV4IHdoZW4gdGhlcmUgaXMgYSByb3V0ZXINCg0KYmV0d2VlbiBsaWdodC0y IGFuZCBzd2l0Y2gNCg0KL2NvbW1lbnQgVmlhIHdoaWNoIFJEIHdpbGwgbGlnaHQgc3dpdGNoIGRp c2NvdmVyIGxpZ2h0LTI/DQoNCi9jb21tZW50IGFkZGl0aW9uYWwgcmVhc29uIHRvIHJlbW92ZSBy b3V0ZXIgZnJvbSB0aGUgbXVsdGljYXN0DQoNCmNvbmZpZ3VyYXRpb24NCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KUmFobWFuICYgRGlqayAgICAgICAgICAgIEV4cGlyZXMgQXByaWwgMjIs IDIwMTMgICAgICAgICAgICAgICAgW1BhZ2UNCg0KMTRdDQoNCg0KDQoNCkludGVybmV0LURyYWZ0 ICAgICAgICBHcm91cCBDb21tdW5pY2F0aW9uIGZvciBDb0FQICAgICAgICAgIE9jdG9iZXINCg0K MjAxMg0KDQoNCg0KDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBMaWdo dCAgICAgIFJ0ci0xICAgICBSdHItMg0KDQpOZXR3b3JrDQoNCiAgICBMaWdodC0xICAgTGlnaHQt MiAgICBMaWdodC0zICAgICBTd2l0Y2ggICAgKFJELTEpICAgIChSRC0yKQ0KDQpCYWNrYm9uZQ0K DQogICAgIHwgICAgICAgICAgfCAgICAgICAgICB8ICAgICAgICAgIHwgICAgICAgICAgfCAgICAg ICAgICB8ICAgICAgICAgIHwNCg0KICAgICB8ICAgICAgICAgIHwgICAgICAgICAgfCAgICAgICAg ICB8ICAgICAgICAgIHwgICAgICAgICAgfCAgICAgICAgICB8DQoNCiAgICAgKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKiAgICAgICAgICB8ICAgICAgICAgIHwgICAgICAgICAgfA0K DQogICAgICogICBMaWdodC0yIGlzIGluc3RhbGxlZCAgICAgICAgICogICAgICAgICAgfCAgICAg ICAgICB8ICAgICAgICAgIHwNCg0KICAgICAqICAgYW5kIHBvd2VycyBvbiBmb3IgZmlyc3QgdGlt ZSAqICAgICAgICAgIHwgICAgICAgICAgfCAgICAgICAgICB8DQoNCiAgICAgKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKiAgICAgICAgICB8ICAgICAgICAgIHwgICAgICAgICAgfA0K DQogICAgIHwgICAgICAgICAgfCAgICAgICAgICB8ICAgICAgICAgIHwgICAgICAgICAgfCAgICAg ICAgICB8ICAgICAgICAgIHwNCg0KICAgICB8ICAgICAgICAgIHwgICAgICAgICAgfCAgICAgICAg ICB8ICAgICAgICAgIHwgICAgICAgICAgfCAgICAgICAgICB8DQoNCiAgICAgfCAgICAgICAgICB8 IENPQVAgTk9OIChHRVQgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgfA0K DQogICAgIHwgICAgICAgICAgfCAgICAgICAgICAgLy53ZWxsLWtub3duL2NvcmU/cnQ9Y29yZS5y ZCkgICB8ICAgICAgICAgIHwNCg0KICAgICB8ICAgICAgICAgIHwtLS0tLS0tLS0+LS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0+fCAgICAgICAgICB8DQoNCiAgICAgfCAgICAgICAgICB8 ICAgICAgICAgIHwgICAgICAgICAgfCAgICAgICAgICB8ICAgICAgICAgIHwgICAgICAgICAgfA0K DQogICAgIHwgICAgICAgICAgfCAgICAgICAgICB8ICAgICAgICAgIHwgICAgICAgICAgfCAgICAg ICAgICB8ICAgICAgICAgIHwNCg0KICAgICB8ICAgICAgICAgIHwgICAgICAgICAgfCAgICAgICAg ICB8ICAgICAgICAgIHwgICAgICAgICAgfCAgICAgICAgICB8DQoNCiAgICAgfCAgICAgICAgICB8 IENPQVAgTk9OICgyLjA1IENvbnRlbnQgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgfA0K DQogICAgIHwgICAgICAgICAgfCAgICAgICAgIDwvcmQ+O3J0PSJjb3JlLnJkIjtpbnM9IlByaW1h cnkiKSB8ICAgICAgICAgIHwNCg0KICAgICB8ICAgICAgICAgIHw8LS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tfCAgICAgICAgICB8DQoNCiAgICAgfCAgICAgICAgICB8 ICAgICAgICAgIHwgICAgICAgICAgfCAgICAgICAgICB8ICAgICAgICAgIHwgICAgICAgICAgfA0K DQoNCg0KDQoNCg0KDQogICAgICAgIEZpZ3VyZSAzOiBSZXNvdXJjZSBEaXJlY3RvcnkgRGlzY292 ZXJ5IHZpYSBNdWx0aWNhc3QgTWVzc2FnZQ0KDQoNCg0KNC40LiAgTGlnaHRpbmcgQ29udHJvbA0K DQoNCg0KL2NvbW1lbnQgSSBhbSBjb25mdXNlZCBhYm91dCB0aGUgdXNlIG9mIHByb3RvY29scw0K DQovY29tbWVudCBNTEQgaXMgdXNlZCB0byBmb3JtIGdyb3VwcywgY29ycmVjdD8NCg0KL2NvbW1l bnQgYnV0IHRoYXQgd2FzIGFscmVhZHkgZG9uZSBieSBlbmFibGluZyB0aGUgTUMgYWRkcmVzcyBp biB0aGUNCg0KbGlnaHRzIChwb2ludCAyKQ0KDQovY29tbWVudCBUaGVyZSBhcmUgc2V2ZXJhbCB3 YXlzIHRvIHNldCB1cCBncm91cHMsIHBvaW50aW5nIHRoZW0gb3V0IGFuZA0KDQp3aGVuIHRvIHVz ZSB0aGVtIHdvdWxkIGJlIGFuIGFzc2V0Lg0KDQoNCg0KICAgIFRoZSBwcm90b2NvbCBmbG93IGZv ciBhIGJ1aWxkaW5nIGF1dG9tYXRpb24gbGlnaHRpbmcgY29udHJvbA0KDQpzY2VuYXJpbw0KDQog ICAgZm9yIHRoZSBuZXR3b3JrIChGaWd1cmUgMikgaXMgc2hvd24gaW4gc2VxdWVuY2UgaW4gRmln dXJlIDQsDQoNCiAgICBGaWd1cmUgNSwgYW5kIEZpZ3VyZSA2LiAgV2UgYXNzdW1lIHRoZSBmb2xs b3dpbmcgc3RlcHMgb2NjdXIgYmVmb3JlDQoNCiAgICB0aGUgaWxsdXN0cmF0ZWQgZmxvdzoNCg0K DQoNCiAgICBvICAxKSBTdGFydHVwIHBoYXNlOiA2TG9XUEFOcyBhcmUgZm9ybWVkLiAgSVB2NiBh ZGRyZXNzZXMgYXNzaWduZWQNCg0KdG8NCg0KICAgICAgIGFsbCBkZXZpY2VzLiAgVGhlIENvQVAg bmV0d29yayBpcyBmb3JtZWQuDQoNCg0KDQogICAgbyAgMikgQ29tbWlzc2lvbmluZyBwaGFzZSAo YnkgYXBwbGljYXRpb25zKTogVGhlIElQIG11bHRpY2FzdA0KDQphZGRyZXNzDQoNCiAgICAgICBv ZiB0aGUgZ3JvdXAgKFJvb20tQS1MaWdodHMpIGhhcyBiZWVuDQoNCi9zIHNldCAvcyBlbmFibGUN Cg0KICAgICAgIGluIGFsbCB0aGUgTGlnaHRzLiAgVGhlDQoNCiAgICAgICBVUkkgb2YgdGhlIGdy b3VwIChSb29tLUEtTGlnaHRzKSBoYXMgYmVlbg0KDQovcyBzZXQgL3MgcmVzb2x2ZWQNCg0KICAg ICAgIGluIHRoZSBMaWdodCBTd2l0Y2guDQoNCg0KDQogICAgbyAgMykgVGhlIGluZGljYXRlZCBN TEQgUmVwb3J0IG1lc3NhZ2VzIGFyZSBsaW5rLWxvY2FsIG11bHRpY2FzdC4NCg0KSW4NCg0KICAg ICAgIGVhY2ggTG9XUEFOLCBpdCBpcyBhc3N1bWVkIHRoYXQgYSBtdWx0aWNhc3Qgcm91dGluZy9m b3J3YXJkaW5nDQoNCiAgICAgICBwcm90b2NvbCBpbiA2TFJzIHdpbGwgdGhlbiBwcm9wYWdhdGUg dGhlIEpvaW4gaW5mb3JtYXRpb24NCg0KICAgICAgIGNvbnRhaW5lZCBpbiB0aGUgTUxEIFJlcG9y dCBvdmVyIG11bHRpcGxlIGhvcHMgdG8gdGhlIDZMQlIuDQoNCg0KDQovY29tbWVudCBEb24ndCBz ZWUgdGhlIG5lZWQNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KUmFobWFuICYgRGlqayAgICAg ICAgICAgIEV4cGlyZXMgQXByaWwgMjIsIDIwMTMgICAgICAgICAgICAgICAgW1BhZ2UNCg0KMTVd DQoNCg0KDQoNCkludGVybmV0LURyYWZ0ICAgICAgICBHcm91cCBDb21tdW5pY2F0aW9uIGZvciBD b0FQICAgICAgICAgIE9jdG9iZXINCg0KMjAxMg0KDQoNCg0KDQoNCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICBMaWdodCAgICAgIFJ0ci0xICAgICBSdHItMg0KDQpOZXR3b3Jr DQoNCiAgICBMaWdodC0xICAgTGlnaHQtMiAgICBMaWdodC0zICAgICBTd2l0Y2ggICAgKENvQVAg ICAgIChDb0FQDQoNCkJhY2tib25lDQoNCiAgICAgfCAgICAgICAgICB8ICAgICAgICAgIHwgICAg ICAgICAgfCAgICAgICAgIFByb3h5KSAgICBQcm94eSkgICAgICAgfA0KDQogICAgIHwgICAgICAg ICAgfCAgICAgICAgICB8ICAgICAgICAgIHwgICAgICAgICAgfCAgICAgICAgICB8ICAgICAgICAg IHwNCg0KICAgICB8ICAgICAgICAgIHwgICAgICAgICAgfCAgICAgICAgICB8ICAgICAgICAgIHwg ICAgICAgICAgfCAgICAgICAgICB8DQoNCiAgICAgfCBNTEQgUmVwb3J0OiBKb2luICAgIHwgICAg ICAgICAgfCAgICAgICAgICB8ICAgICAgICAgIHwgICAgICAgICAgfA0KDQogICAgIHwgR3JvdXAg KFJvb20tQS1MaWdodHMpICAgICAgICAgIHwgICAgICAgICAgfCAgICAgICAgICB8ICAgICAgICAg IHwNCg0KICAgICB8LS0tTEwtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPnwg ICAgICAgICAgfCAgICAgICAgICB8DQoNCiAgICAgfCAgICAgICAgICB8ICAgICAgICAgIHwgICAg ICAgICAgfCAgICAgICAgICB8TUxEIFJlcG9ydDogSm9pbiAgICAgfA0KDQogICAgIHwgICAgICAg ICAgfCAgICAgICAgICB8ICAgICAgICAgIHwgICAgICAgICAgfEdyb3VwIChSb29tLUEtTGlnaHRz KXwNCg0KICAgICB8ICAgICAgICAgIHwgICAgICAgICAgfCAgICAgICAgICB8ICAgICAgICAgIHwt LS1MTC0tLS0tLS0tLS0tLS0tLT58DQoNCiAgICAgfCAgICAgICAgICB8ICAgICAgICAgIHwgICAg ICAgICAgfCAgICAgICAgICB8ICAgICAgICAgIHwgICAgICAgICAgfA0KDQogICAgIHwgICAgICAg ICAgfCBNTEQgUmVwb3J0OiBKb2luICAgIHwgICAgICAgICAgfCAgICAgICAgICB8ICAgICAgICAg IHwNCg0KICAgICB8ICAgICAgICAgIHwgR3JvdXAgKFJvb20tQS1MaWdodHMpICAgICAgICAgIHwg ICAgICAgICAgfCAgICAgICAgICB8DQoNCiAgICAgfCAgICAgICAgICB8LS0tTEwtLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPnwgICAgICAgICAgfA0KDQogICAgIHwgICAgICAg ICAgfCAgICAgICAgICB8ICAgICAgICAgIHwgICAgICAgICAgfCAgICAgICAgICB8ICAgICAgICAg IHwNCg0KICAgICB8ICAgICAgICAgIHwgICAgICAgICAgfCBNTEQgUmVwb3J0OiBKb2luICAgIHwg ICAgICAgICAgfCAgICAgICAgICB8DQoNCiAgICAgfCAgICAgICAgICB8ICAgICAgICAgIHwgR3Jv dXAgKFJvb20tQS1MaWdodHMpICAgICAgICAgIHwgICAgICAgICAgfA0KDQogICAgfCAgICAgICAg ICB8ICAgICAgICAgIHwtLS1MTC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPnwgICAgICAgICAg fA0KDQogICAgIHwgICAgICAgICAgfCAgICAgICAgICB8ICAgICAgICAgIHwgICAgICAgICAgfCAg ICAgICAgICB8ICAgICAgICAgIHwNCg0KICAgICB8ICAgICAgICAgIHwgICAgICAgICAgfCAgICAg ICAgICB8ICAgICAgICAgIHxNTEQgUmVwb3J0OiBKb2luICAgICB8DQoNCiAgICAgfCAgICAgICAg ICB8ICAgICAgICAgIHwgICAgICAgICAgfCAgICAgICAgICB8R3JvdXAgKFJvb20tQS1MaWdodHMp fA0KDQogICAgIHwgICAgICAgICAgfCAgICAgICAgICB8ICAgICAgICAgIHwgICAgICAgICAgfCAg ICAgICAgICB8LS0tTEwtLS0tPnwNCg0KICAgICB8ICAgICAgICAgIHwgICAgICAgICAgfCAgICAg ICAgICB8ICAgICAgICAgIHwgICAgICAgICAgfCAgICAgICAgICB8DQoNCiAgICAgfCAgICAgICAg ICB8ICAgICAgICAgIHwgICAgICAgICAgfCAgICAgICAgICB8ICAgICAgICAgIHwgICAgICAgICAg fA0KDQoNCg0KDQoNCiAgICAgICAgICAgICAgICAgRmlndXJlIDQ6IEpvaW5pbmcgTGlnaHRpbmcg R3JvdXBzIFVzaW5nIE1MRA0KDQoNCg0KL2NvbW1lbnQgcG9zc2libHkgcmVtb3ZlIGZyb20gdGV4 dCwgb3IgZG8gc2VwYXJhdGUgc2VjdGlvbiBvbiB1c2Ugb2YNCg0KTUxEDQoNCi9jb21tZW50IGFu eXdheSBzZXBhcmF0aW5nIGNvbW1pc3Npb25pbmcgZnJvbSBvcGVyYXRpb24gaW4gc2VwYXJhdGUN Cg0Kc2VjdGlvbnMgaXMgYSBnb29kIGlkZWEuDQoNCg0KDQovY29tbWVudCB0aGUgcHJveGllcyBh cmUgYSBjb21wbGljYXRpb24gaW4gdGhlIHBpY3R1cmUgbm90IGVsYWJvcmF0ZWQNCg0KaW4gdGhl IHRleHQuDQoNCi9jb21tZW50IHRoZSBzdWJqZWN0IG9mIHByb3hpZXMgaXMgYW5vdGhlciBvbmUs IHRvIGJlIHRyZWF0ZWQNCg0KZWxzZXdoZXJlLg0KDQovY29tbWVudCBhbHNvIGZvciBwcm94aWVz IHRoZSBkbydzIGFuZCBkb24ndCdzIGZyb20gYSBzaW1wbGUNCg0KcGVyZm9ybWFuY2UgcGVyc3Bl Y3RpdmUgd2lsbCBiZSBpbnRlcmVzdGluZw0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNClJhaG1hbiAmIERpamsgICAgICAgICAgICBFeHBpcmVzIEFwcmlsIDIyLCAyMDEzICAg ICAgICAgICAgICAgIFtQYWdlDQoNCjE2XQ0KDQoNCg0KDQpJbnRlcm5ldC1EcmFmdCAgICAgICAg R3JvdXAgQ29tbXVuaWNhdGlvbiBmb3IgQ29BUCAgICAgICAgICBPY3RvYmVyDQoNCjIwMTINCg0K DQoNCg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgTGlnaHQgICAgICBS dHItMSAgICAgUnRyLTINCg0KTmV0d29yaw0KDQogICAgTGlnaHQtMSAgIExpZ2h0LTIgICAgTGln aHQtMyAgICAgU3dpdGNoICAgIChDb0FQICAgICAoQ29BUA0KDQpCYWNrYm9uZQ0KDQogICAgIHwg ICAgICAgICAgfCAgICAgICAgICB8ICAgICAgICAgIHwgICAgICAgICBQcm94eSkgICAgUHJveHkp ICAgICAgIHwNCg0KICAgICB8ICAgICAgICAgIHwgICAgICAgICAgfCAgICAgICAgICB8ICAgICAg ICAgIHwgICAgICAgICAgfCAgICAgICAgICB8DQoNCiAgICAgfCAgICAgICAgICB8ICAgICAgICAg ICoqKioqKioqKioqKioqKioqKioqKioqICAgICAgICAgIHwgICAgICAgICAgfA0KDQogICAgIHwg ICAgICAgICAgfCAgICAgICAgICAqICAgVXNlciBmbGlwcyBvbiAgICAgKiAgICAgICAgICB8ICAg ICAgICAgIHwNCg0KICAgICB8ICAgICAgICAgIHwgICAgICAgICAgKiAgIGxpZ2h0IHN3aXRjaCB0 byAgICogICAgICAgICAgfCAgICAgICAgICB8DQoNCiAgICAgfCAgICAgICAgICB8ICAgICAgICAg ICogICB0dXJuIG9uIGFsbCB0aGUgICAqICAgICAgICAgIHwgICAgICAgICAgfA0KDQogICAgIHwg ICAgICAgICAgfCAgICAgICAgICAqICAgbGlnaHRzIGluIFJvb20gQSAgKiAgICAgICAgICB8ICAg ICAgICAgIHwNCg0KICAgICB8ICAgICAgICAgIHwgICAgICAgICAgKioqKioqKioqKioqKioqKioq KioqKiogICAgICAgICAgfCAgICAgICAgICB8DQoNCiAgICAgfCAgICAgICAgICB8ICAgICAgICAg IHwgICAgICAgICAgfCAgICAgICAgICB8ICAgICAgICAgIHwgICAgICAgICAgfA0KDQogICAgIHwg ICAgICAgICAgfCAgICAgICAgICB8ICAgICAgICAgIHwgICAgICAgICAgfCAgICAgICAgICB8ICAg ICAgICAgIHwNCg0KICAgICB8ICAgICAgICAgIHwgICAgICAgICAgfCBDT0FQIE5PTiAoUFVUICAg ICAgIHwgICAgICAgICAgfCAgICAgICAgICB8DQoNCiAgICAgfCAgICAgICAgICB8ICAgICAgICAg IHwgICAgICAgICAgIFByb3h5LVVSSSB8ICAgICAgICAgIHwgICAgICAgICAgfA0KDQogICAgIHwg ICAgICAgICAgfCAgICAgICAgICB8ICAgICAgICAgICBVUkkgZm9yIFJvb20tQS1MaWdodHMgICAg ICAgICAgIHwNCg0KICAgICB8ICAgICAgICAgIHwgICAgICAgICAgfCAgICAgICAgICAgUGF5bG9h ZD10dXJuIG9uIGxpZ2h0cykgICAgICAgICB8DQoNCiAgICAgfCAgICAgICAgICB8ICAgICAgICAg IHwgICAgICAgICAgfC0tLS0tLS0tLT58ICAgICAgICAgIHwgICAgICAgICAgfA0KDQogICAgIHwg ICAgICAgICAgfCAgICAgICAgICB8ICAgICAgICAgIHwgICAgICAgICAgfCAgICAgICAgICB8ICAg ICAgICAgIHwNCg0KICAgICB8ICAgICAgICAgIHwgICAgICAgICAgfCAgICAgICAgICB8ICAgICAg ICAgIHwgICAgICAgICAgfCAgICAgICAgICB8DQoNCiAgICAgfCAgICAgICAgICB8ICAgICAgICAg IHwgICAgICAgICAgfCAgICAgUmVxdWVzdCBETlMgcmVzb2x1dGlvbiBvZiAgfA0KDQogICAgIHwg ICAgICAgICAgfCAgICAgICAgICB8ICAgICAgICAgIHwgICAgIFVSSSBmb3IgUm9vbS1BLUxpZ2h0 cyAgICAgIHwNCg0KICAgICB8ICAgICAgICAgIHwgICAgICAgICAgfCAgICAgICAgICB8ICAgICAg ICAgIHwtLS0tLS0tLS0tLS0tLS0tLS0tLT58DQoNCiAgICB8ICAgICAgICAgIHwgICAgICAgICAg fCAgICAgICAgICB8ICAgICAgICAgIHwgICAgICAgICAgfCAgICAgICAgICB8DQoNCiAgICAgfCAg ICAgICAgICB8ICAgICAgICAgIHwgICAgICAgICAgfCAgICAgICAgICB8ICAgICAgICAgIHwgICAg ICAgICAgfA0KDQogICAgIHwgICAgICAgICAgfCAgICAgICAgICB8ICAgICAgICAgIHwgICAgIERO UyByZXR1cm5zOiBBQUFBICAgICAgICAgIHwNCg0KICAgICB8ICAgICAgICAgIHwgICAgICAgICAg fCAgICAgICAgICB8ICAgICBHcm91cCAoUm9vbS1BLUxpZ2h0cykgICAgICB8DQoNCiAgICAgfCAg ICAgICAgICB8ICAgICAgICAgIHwgICAgICAgICAgfCAgICAgSVB2NiBtdWx0aWNhc3QgYWRkcmVz cyAgICAgfA0KDQogICAgIHwgICAgICAgICAgfCAgICAgICAgICB8ICAgICAgICAgIHwgICAgICAg ICAgfDwtLS0tLS0tLS0tLS0tLS0tLS0tLXwNCg0KICAgICB8ICAgICAgICAgIHwgICAgICAgICAg fCAgICAgICAgICB8ICAgICAgICAgIHwgICAgICAgICAgfCAgICAgICAgICB8DQoNCiAgICAgfCAg ICAgICAgICB8ICAgICAgICAgIHwgICAgICAgICAgfCAgICAgICAgICB8ICAgICAgICAgIHwgICAg ICAgICAgfA0KDQogICAgIHwgICAgICAgICAgfCAgICAgICAgICB8ICAgICAgICAgIENPQVAgTk9O IChQdXQgICAgICAgICAgICAgICAgICAgIHwNCg0KICAgICB8ICAgICAgICAgIHwgICAgICAgICAg fCAgICAgICAgICB8ICAgICAgICAgVVJJIFBhdGggICAgICAgICAgICAgICB8DQoNCiAgICB8ICAg ICAgICAgIHwgICAgICAgICAgfCAgICAgICAgICB8ICAgICAgICAgUGF5bG9hZD10dXJuIG9uIGxp Z2h0cyl8DQoNCiAgICAgfCAgICAgICAgICB8ICAgICAgICAgIHwgICAgICAgICAgfCAgICBEZXN0 aW5hdGlvbiBJUCBBZGRyZXNzID0gICAgfA0KDQogICAgIHwgICAgICAgICAgfCAgICAgICAgICB8 ICAgICAgICAgIHwgICAgICAgSVAgbXVsdGljYXN0IGFkZHJlc3MgICAgIHwNCg0KICAgICB8ICAg ICAgICAgIHwgICAgICAgICAgfCAgICAgICAgICB8ICAgICAgIGZvciBHcm91cCAoUm9vbS1BLUxp Z2h0cyl8DQoNCiAgICAgfCAgICAgICAgICB8ICAgICAgICAgIHwgICAgICAgICAgfCAgICBPcmln aW5hdGluZyBJUCBBZGRyZXNzID0gICAgfA0KDQogICAgIHwgICAgICAgICAgfCAgICAgICAgICB8 ICAgICAgICAgIHwgICAgICAgIFJUUi0xICAgICAgICAgICAgICAgICAgIHwNCg0KICAgICB8ICAg ICAgICAgIHwgICAgICAgICAgfCAgICAgICAgICB8ICAgICAgICAgIHwtLS0tLS0tLS0tLS0tLS0t LS0tLT58DQoNCiAgICAgfDwtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS18ICAgICAgICAgIHwgICAgICAgICAgfA0KDQogICAgIHwgICAgICAgICAgfCAgICAgICAgICB8 ICAgICAgICAgIHwgICAgICAgICAgfCAgICAgICAgICB8ICAgICAgICAgIHwNCg0KICAgICB8ICAg ICAgICAgIHwgICAgICAgICAgfCAgICAgICAgICB8ICAgICAgICAgIHwgICAgICAgICAgfDwtLS0t LS0tLS18DQoNCiAgICAgfCAgICAgICAgICB8PC0tLS0tLS0tLXw8LS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLXwgICAgICAgICAgfA0KDQogICAgIHwgICAgICAgICAgfCAgICAgICAgICB8 ICAgICAgICAgIHwgICAgICAgICAgfCAgICAgICAgICB8ICAgICAgICAgIHwNCg0KICAgICB8ICAg ICAgICAgIHwgICAgICAgICAgfCAgICAgICAgICB8ICAgICAgICAgIHwgICAgICAgICAgfCAgICAg ICAgICB8DQoNCg0KDQoNCg0KICAgICAgICAgICAgRmlndXJlIDU6IFNlbmRpbmcgTGlnaHRpbmcg Q29udHJvbCBNdWx0aWNhc3QgTWVzc2FnZQ0KDQoNCg0KDQoNCg0KDQpSYWhtYW4gJiBEaWprICAg ICAgICAgICAgRXhwaXJlcyBBcHJpbCAyMiwgMjAxMyAgICAgICAgICAgICAgICBbUGFnZQ0KDQox N10NCg0KDQoNCg0KSW50ZXJuZXQtRHJhZnQgICAgICAgIEdyb3VwIENvbW11bmljYXRpb24gZm9y IENvQVAgICAgICAgICAgT2N0b2Jlcg0KDQoyMDEyDQoNCg0KDQoNCg0KICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIExpZ2h0ICAgICAgUnRyLTEgICAgIFJ0ci0yDQoNCk5ldHdv cmsNCg0KICAgIExpZ2h0LTEgICBMaWdodC0yICAgIExpZ2h0LTMgICAgIFN3aXRjaCAgICAoQ29B UCAgICAgKENvQVANCg0KQmFja2JvbmUNCg0KICAgICB8ICAgICAgICAgIHwgICAgICAgICAgfCAg ICAgICAgICB8ICAgICAgICAgUHJveHkpICAgIFByb3h5KSAgICAgICB8DQoNCiAgICAgfCAgICAg ICAgICB8ICAgICAgICAgIHwgICAgICAgICAgfCAgICAgICAgICB8ICAgICAgICAgIHwgICAgICAg ICAgfA0KDQogICAgICoqKioqKioqKioqKioqKioqKioqKioqICAgICAgICAgIHwgICAgICAgICAg fCAgICAgICAgICB8ICAgICAgICAgIHwNCg0KICAgICAqICAgTGlnaHRzIGluIFJvb20tQSAgKiAg ICAgICAgICB8ICAgICAgICAgIHwgICAgICAgICAgfCAgICAgICAgICB8DQoNCiAgICAgKiAgIHR1 cm4gb24gKG5lYXJseSAgICogICAgICAgICAgfCAgICAgICAgICB8ICAgICAgICAgIHwgICAgICAg ICAgfA0KDQogICAgICogICBzaW11bHRhbmVvdXNseSkgICAqICAgICAgICAgIHwgICAgICAgICAg fCAgICAgICAgICB8ICAgICAgICAgIHwNCg0KICAgICAqKioqKioqKioqKioqKioqKioqKioqKiAg ICAgICAgICB8ICAgICAgICAgIHwgICAgICAgICAgfCAgICAgICAgICB8DQoNCiAgICAgfCAgICAg ICAgICB8ICAgICAgICAgIHwgICAgICAgICAgfCAgICAgICAgICB8ICAgICAgICAgIHwgICAgICAg ICAgfA0KDQogICAgIHwgICAgICAgICAgfCAgICAgICAgICB8ICAgICAgICAgIHwgICAgICAgICAg fCAgICAgICAgICB8ICAgICAgICAgIHwNCg0KICAgICB8ICAgICBDT0FQIE5PTiAoMi4wNCBDaGFu Z2VkKSAgICB8ICAgICAgICAgIHwgICAgICAgICAgfCAgICAgICAgICB8DQoNCiAgICAgfC0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLT58ICAgICAgICAgIHwgICAgICAg ICAgfA0KDQogICAgIHwgICAgICAgICAgfCAgICAgICAgICB8ICAgICAgICAgIHwgICAgICAgICAg fCAgICAgICAgICB8ICAgICAgICAgIHwNCg0KICAgICB8ICAgICAgICAgIHwgICAgICAgICAgfCAg ICAgICAgICB8ICAgICAgICAgIHwgICAgICAgICAgfCAgICAgICAgICB8DQoNCiAgICAgfCAgICAg ICAgICBDT0FQIE5PTiAoMi4wNCBDaGFuZ2VkKSAgICAgICAgICB8ICAgICAgICAgIHwgICAgICAg ICAgfA0KDQogICAgIHwgICAgICAgICAgfC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0+ fCAgICAgICAgICB8ICAgICAgICAgIHwNCg0KICAgICB8ICAgICAgICAgIHwgICAgICAgICAgfCAg ICAgICAgICB8ICAgICAgICAgIHwgICAgICAgICAgfCAgICAgICAgICB8DQoNCiAgICAgfCAgICAg ICAgICB8ICAgICAgICAgIHwgICAgICAgICAgfCAgICAgICAgICB8ICAgICAgICAgIHwgICAgICAg ICAgfA0KDQogICAgIHwgICAgICAgICAgfCAgICAgICAgQ09BUCBOT04gKDUuMDAgSW50ZXJuYWwg U2VydmVyIEVycm9yKSAgICAgICAgIHwNCg0KICAgICB8ICAgICAgICAgIHwgICAgICAgICAgfC0t LS0tLS0tLS0tLS0tLS0tLS0tPnwgICAgICAgICAgfCAgICAgICAgICB8DQoNCiAgICAgfCAgICAg ICAgICB8ICAgICAgICAgIHwgICAgICAgICAgfCAgICAgICAgICB8ICAgICAgICAgIHwgICAgICAg ICAgfA0KDQogICAgIHwgICAgICAgICAgfCAgICAgICAgICB8ICAgICAgICAgICoqKioqKioqKioq KioqKioqKioqKioqKioqKioqKiAgIHwNCg0KICAgICB8ICAgICAgICAgIHwgICAgICAgICAgfCAg ICAgICAgICAqICAgICAgUnRyLTEgYXMgQ29BUCBQcm94eSAgICogICB8DQoNCiAgICAgfCAgICAg ICAgICB8ICAgICAgICAgIHwgICAgICAgICAgKiAgfCAgIHNlbmRzIHRoZSBpbmRpdmlkdWFsICAq ICAgfA0KDQogICAgIHwgICAgICAgICAgfCAgICAgICAgICB8ICAgICAgICAgICogIHwgICByZXNw b25zZXMgYmFjayB0byAgICAgKiAgIHwNCg0KICAgICB8ICAgICAgICAgIHwgICAgICAgICAgfCAg ICAgICAgICAqICB2ICAgb3JpZ2luYXRvciAgICAgICAgICAgICogICB8DQoNCiAgICAgfCAgICAg ICAgICB8ICAgICAgICAgIHwgICAgICAgICAgKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq ICAgfA0KDQogICAgIHwgICAgICAgICAgfCAgICAgICAgICB8ICAgICAgICAgIHwgICAgICAgICAg fCAgICAgICAgICB8ICAgICAgICAgIHwNCg0KICAgIHwgICAgICAgICAgfCAgICAgICAgICB8ICAg IENPQVAgTk9OICgyLjA0IENoYW5nZWQpICAgICB8ICAgICAgICAgIHwNCg0KICAgICB8ICAgICAg ICAgIHwgICAgICAgICAgfCAgICAgICAgICB8PC0tLS0tLS0tLXwgICAgICAgICAgfCAgICAgICAg ICB8DQoNCiAgICAgfCAgICAgICAgICB8ICAgICAgICAgIHwgICAgICAgICAgfCAgICAgICAgICB8 ICAgICAgICAgIHwgICAgICAgICAgfA0KDQogICAgIHwgICAgICAgICAgfCAgICAgICAgICB8ICAg IENPQVAgTk9OICgyLjA0IENoYW5nZWQpICAgICB8ICAgICAgICAgIHwNCg0KICAgICB8ICAgICAg ICAgIHwgICAgICAgICAgfCAgICAgICAgICB8PC0tLS0tLS0tLXwgICAgICAgICAgfCAgICAgICAg ICB8DQoNCiAgICAgfCAgICAgICAgICB8ICAgICAgICAgIHwgICAgICAgICAgfCAgICAgICAgICB8 ICAgICAgICAgIHwgICAgICAgICAgfA0KDQogICAgIHwgICAgICAgICAgfCAgICAgICAgICB8ICAg IENPQVAgTk9OICg1LjAwIEludGVybmFsIFNlcnZlciBFcnJvcikgIHwNCg0KICAgICB8ICAgICAg ICAgIHwgICAgICAgICAgfCAgICAgICAgICB8PC0tLS0tLS0tLXwgICAgICAgICAgfCAgICAgICAg ICB8DQoNCiAgICAgfCAgICAgICAgICB8ICAgICAgICAgIHwgICAgICAgICAgfCAgICAgICAgICB8 ICAgICAgICAgIHwgICAgICAgICAgfA0KDQoNCg0KDQoNCiAgICAgIEZpZ3VyZSA2OiBTZW5kaW5n IExpZ2h0aW5nIENvbnRyb2wgUmVzcG9uc2UgdG8gTXVsdGljYXN0IE1lc3NhZ2UNCg0KDQoNCiAg ICBOT1RFOiBJbiB0aGUgbGFzdCBzdGVwIG9mIEZpZ3VyZSA2LCBSdHItMSBhY3RpbmcgYXMgQ29B UCBwcm94eSwNCg0KICAgIHJldHVybnMgbXVsdGlwbGUgaW5kaXZpZHVhbCBDb0FQIHJlc3BvbnNl cyB0byB0aGUgY2xpZW50LiAgRWFjaA0KDQogICAgcmVzcG9uc2UgZWNob2VzIHRoZSBUb2tlbiBv ZiB0aGUgY2xpZW50J3MgcmVxdWVzdC4gIFRoZSBjbGllbnQgY2FuDQoNCiAgICBpZGVudGlmeSB0 aGUgb3JpZ2luYWwgc291cmNlIG9mIGVhY2ggcmVzcG9uc2UgYnkgLi4uVEJELg0KDQoNCg0KDQoN Ci9jb21tZW50IFdIWSBhcmUgdGhlIG11bHRpY2FzdCBkZXN0aW5hdGlvbnMgc2VuZGluZyBiYWNr IHJlc3VsdHM/DQoNCi9jb21tZW50IEkgdGhvdWdodCB0aGF0IHlvdSB3YW50ZWQgTUMgbWVzc2Fn ZXMgdG8gYmUgbm9uIGNvbmZpcm1hYmxlDQoNCi9jb21tZW50IHNlbmRpbmcgcmVzcG9uc2VzIHNl ZW1zIHRvIGNvbnRyYWRpY3QgdGhpcyAuDQoNCi9jb21tZW50IHBsZWFzZSByZW1vdmUgc2VuZGlu ZyBiYWNrIG9mIHJlc3BvbnNlcy4NCg0KL2NvbW1lbnQgb25lIG1heSBhc3N1bWUgdGhhdCB0aGUg TUMgYWxnb3JpdGhtIHdpdGhpbiB0aGUgbG93cGFuIGlzDQoNCnJlbGlhYmxlIChhbGwgZGVzdGlu YXRpb25zIHJlY2VpdmUgdGhlIG1lc3NhZ2UpDQoNCi9jb21tZW50IGFueXdheSBNUEwgY29tZXMg Y2xvc2UgZW5vdWdoIHRvIHRoZSByZWxpYWJpbGl0eSByZXF1aXJlbWVudA0KDQpnaXZlbiBhIHNw ZWNpZmlhYmxlIHJhbmdlIG9mIGNvbmZpZ3VyYXRpb25zDQoNCg0KDQpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KLS0N Cg0KUGV0ZXIgdmFuIGRlciBTdG9rDQoNCm1haWx0bzogY29uc3VsdGFuY3lAdmFuZGVyc3Rvay5v cmc8bWFpbHRvOmNvbnN1bHRhbmN5QHZhbmRlcnN0b2sub3JnPg0KDQp3d3c6IHd3dy52YW5kZXJz dG9rLm9yZzxodHRwOi8vd3d3LnZhbmRlcnN0b2sub3JnPg0KDQp0ZWwgTkw6ICszMSgwKTQ5MjQ3 NDY3MyAgICAgRjogKzMzKDApOTY2MDE1MjQ4DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQpUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgbWVzc2FnZSBtYXkgYmUg Y29uZmlkZW50aWFsIGFuZCBsZWdhbGx5IHByb3RlY3RlZCB1bmRlciBhcHBsaWNhYmxlIGxhdy4g VGhlIG1lc3NhZ2UgaXMgaW50ZW5kZWQgc29sZWx5IGZvciB0aGUgYWRkcmVzc2VlKHMpLiBJZiB5 b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCB5b3UgYXJlIGhlcmVieSBub3RpZmll ZCB0aGF0IGFueSB1c2UsIGZvcndhcmRpbmcsIGRpc3NlbWluYXRpb24sIG9yIHJlcHJvZHVjdGlv biBvZiB0aGlzIG1lc3NhZ2UgaXMgc3RyaWN0bHkgcHJvaGliaXRlZCBhbmQgbWF5IGJlIHVubGF3 ZnVsLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2UgY29udGFj dCB0aGUgc2VuZGVyIGJ5IHJldHVybiBlLW1haWwgYW5kIGRlc3Ryb3kgYWxsIGNvcGllcyBvZiB0 aGUgb3JpZ2luYWwgbWVzc2FnZS4NCg== --_000_031DD135F9160444ABBE3B0C36CED618B39574011DB3MPN2082MGDP_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxzdHlsZT4NCjwhLS0NCkBmb250LWZhY2UNCgl7 Zm9udC1mYW1pbHk6Q2FsaWJyaX0NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q29uc29sYXN9 DQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207 DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIn0NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7 Y29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lfQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe2NvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lfQ0KcC5Nc29QbGFpblRleHQsIGxpLk1zb1BsYWluVGV4dCwgZGl2Lk1zb1BsYWlu VGV4dA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6 MTAuNXB0Ow0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzfQ0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5N c29MaXN0UGFyYWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFncmFwaA0KCXttYXJnaW4tdG9wOjBjbTsN CgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1hcmdpbi1ib3R0b206MGNtOw0KCW1hcmdpbi1sZWZ0OjM2 LjBwdDsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250 LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYifQ0Kc3Bhbi5QbGFpblRleHRDaGFyDQoJe2Zv bnQtZmFtaWx5OkNvbnNvbGFzfQ0KLk1zb0NocERlZmF1bHQNCgl7fQ0KQHBhZ2UgV29yZFNlY3Rp b24xDQoJe21hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHR9DQpkaXYuV29yZFNlY3Rp b24xDQoJe30NCm9sDQoJe21hcmdpbi1ib3R0b206MGNtfQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTow Y219DQotLT4NCjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1 ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+SGkgUGV0ZXIsPC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+c3RpbGwgYSBmYWlyIG51bWJlciBvZiBjb21tZW50cyEg SSB3b3VsZCBhZ3JlZSB3aXRoIG1vc3QuIEJlbG93IEkgaGF2ZSBzZWxlY3RlZCBzb21lIHdoaWNo IHdlIHNob3VsZCBkaXNjdXNzIGZ1cnRoZXIsIG9yIG9uZXMgSSBkb27igJl0IGFncmVlIHdpdGg6 PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+ Jm5ic3A7PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2 LjBwdDsgdGV4dC1pbmRlbnQ6LTE4LjBwdCI+PHNwYW4gc3R5bGU9IiI+MS48c3BhbiBzdHlsZT0i Zm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOw0KPC9zcGFuPjwv c3Bhbj5Hcm91cCBjb21tdW5pY2F0aW9uIGRlZmluaXRpb24gLSZndDs8YnI+DQpXaHkgY2FuJ3Qg YSBzb3VyY2Ugbm9kZSBiZSBwYXJ0IG9mIHRoZSBncm91cCB0aGF0IGl0IHNlbmRzIHRvPyBFLmcu IGNvbWJpbmVkIHNlbnNvciYjNDM7bHVtaW5haXJlIHVzZSBjYXNlLiBUaGUgSVAgc3RhY2sgd291 bGQgZGVsaXZlciBzZW50IG11bHRpY2FzdCBDb0FQIHJlcXVlc3RzIGFsc28gdG8gdGhlIGxvY2Fs IGFwcGxpY2F0aW9uIGlmIGl0IGlzIHN1YnNjcmliZWQgdG8gdGhlIG11bHRpY2FzdCBJUCBhZGRy ZXNzLjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4w cHQ7IHRleHQtaW5kZW50Oi0xOC4wcHQiPjxzcGFuIHN0eWxlPSIiPjIuPHNwYW4gc3R5bGU9ImZv bnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsNCjwvc3Bhbj48L3Nw YW4+SSBkb27igJl0IHNlZSB3aHkgd2Ugc2hvdWxkIGFkZCDigJx0aGUgdXNlIG9mIGdyb3VwIGNv bW11bmljYXRpb24gZm9yIG1ETlMgaXMgb3V0IG9mIHNjb3BlLuKAnSAtJmd0Ozxicj4NCm1ETlMg b2J2aW91c2x5IGlzIG5vdCBDb0FQLCBhbmQgdGhlIGRvY3VtZW50IHNob3VsZCBkZWZpbmUgdGhl IHNjb3BlIGFueXdheSBjbGVhcmx5IGFzIENvQVAgZ3JvdXAgY29tbXVuaWNhdGlvbi4gU28gd2Ug ZG9u4oCZdCBoYXZlIHRvIGxpc3QgYW55IG90aGVyIHByb3RvY29scyB0aGFuIENvQVAuPC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdDsgdGV4dC1p bmRlbnQ6LTE4LjBwdCI+PHNwYW4gc3R5bGU9IiI+My48c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAm cXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOw0KPC9zcGFuPjwvc3Bhbj7igJxzbyBz ZXR0aW5nIGEgbXVsdGljYXN0IGFkZHJlc3MgaW4gYSBzb3VyY2UgYXQgaW5zdGFsbGF0aW9uIGlz IGZvcmJpZGRlbj/igJ0gLSZndDs8YnI+DQpObywgdGhhdCBzaG91bGQgbm90IGJlIGZvcmJpZGRl biA6KSAmbmJzcDtJdCBzaG91bGQgYWxzbyBiZSBwb3NzaWJsZSB0byBzZXQgYSBDb0FQIHBhdGgg YW5kL29yIHBvcnQgYXQgaW5zdGFsbGF0aW9uIHRpbWUuIFRoYXQgbWVhbnMgdGhlIHR3byBwcmVz ZW50ZWQgbWVhc3VyZXMgaGF2ZSB0byBjaGFuZ2Ugb3IgYmUgcmVtb3ZlZC48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0OyB0ZXh0LWluZGVudDot MTguMHB0Ij48c3BhbiBzdHlsZT0iIj40LjxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1Rp bWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPuKAnHRoZXJlIGFyZSAy IHdheXM6ICgxKSB0aGUgbm9kZSBxdWVyaWVzIHRvIHdoaWNoIGdyb3VwIGl0IGJlbG9uZ3Mgb3Ig KDIpIGFuIGluc3RhbGF0aW9uIHRvb2xzIGluc3RydWN0cyB0aGUgbm9kZSB0byB3aGljaCBncm91 cHPigJ0gLSZndDs8YnI+DQpHb29kIHBvaW50LiAoMikgaGFzIGJlZW4gY2hvc2VuIGJlY2F1c2Ug aXQgd29ya3Mgd2l0aG91dCByZWx5aW5nIG9uIGEgc2VydmljZSB0byBxdWVyeSAoZS5nLiBETlMg b3IgUkQpLiBJcyB0aGF0IHN1ZmZpY2llbnQgYXJndW1lbnRhdGlvbj8gVGhlIG1lY2hhbmlzbSBp cyBvcHRpb25hbCBpbiBhbnkgY2FzZSBzbyBpdCBkb2VzIG5vdCBibG9jayBvdGhlcnMgZnJvbSBk ZWZpbmluZyBhIEROUyBvciBSRCB2YXJpYW50LjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi IHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQ7IHRleHQtaW5kZW50Oi0xOC4wcHQiPjxzcGFuIHN0 eWxlPSIiPjUuPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1 b3Q7Ij4mbmJzcDsNCjwvc3Bhbj48L3NwYW4+4oCcL3MgcmVxdWVzdHMgL3MgcmVwbGllc+KAnSAt Jmd0OyA8YnI+DQptdWx0aWNhc3QgcmVwbGllcyAoaWYgeW91IG1lYW4gcmVzcG9uc2VzKSBkbyBu b3QgZXhpc3QgaW4gQ29BUC4gSXTigJlzIGFib3V0IHJlcXVlc3RzIHRoYXQgc2hvdWxkIGJlIGNh cmVmdWxseSBjb250cm9sbGVkIHNpbmNlIHRoZXkgZ2VuZXJhdGUgdW5pY2FzdCByZXNwb25zZXMu PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdDsg dGV4dC1pbmRlbnQ6LTE4LjBwdCI+PHNwYW4gc3R5bGU9IiI+Ni48c3BhbiBzdHlsZT0iZm9udDo3 LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOw0KPC9zcGFuPjwvc3Bhbj7i gJwvY29tbWVudCB3aGF0IGFib3V0IHRoZSByZXBseT/igJ0gLSZndDs8YnI+DQpiYXNlZCBvbiBj b3JlLWNvYXAg4oCcSWYgdGhlIHJlcXVlc3QgbWVzc2FnZSBpcyBOb24tY29uZmlybWFibGUsIHRo ZW4gdGhlIHJlc3BvbnNlIFNIT1VMRCBiZSByZXR1cm5lZCBpbiBhIE5vbi1jb25maXJtYWJsZSBt ZXNzYWdlIGFzIHdlbGwu4oCdIC4gRG8geW91IHRoaW5rIHdlIHNob3VsZCBxdW90ZSB0aGlzIGZy b20gdGhlIGNvcmUtY29hcCBzcGVjPzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxl PSJtYXJnaW4tbGVmdDozNi4wcHQ7IHRleHQtaW5kZW50Oi0xOC4wcHQiPjxzcGFuIHN0eWxlPSIi PjcuPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4m bmJzcDsNCjwvc3Bhbj48L3NwYW4+4oCcL2NvbW1lbnQgaW52b2tpbmcgYXMgbWFueSBjZXJ0aWZp Y2F0ZXM/4oCdIC0mZ3Q7PGJyPg0KY29yZS1jb2FwLTEzIG5vdyBsb29zZW5zIHRoZSBjb25jZXB0 IG9mIGF1dGhlbnRpY2F0aW9uIHRvIGFsc28gaW5jbHVkZSBvdGhlciBtZWFzdXJlcywgbm90IG5l ZWRpbmcgY2VydGlmaWNhdGVzLjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJt YXJnaW4tbGVmdDozNi4wcHQ7IHRleHQtaW5kZW50Oi0xOC4wcHQiPjxzcGFuIHN0eWxlPSIiPjgu PHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJz cDsNCjwvc3Bhbj48L3NwYW4+TmV0d29yayBjb25maWd1cmF0aW9uOiAyIHN1Ym5ldHMgdnMgMSAt Jmd0Ozxicj4NCm1heWJlIGEgb25lLXN1Ym5ldCBjb25maWd1cmF0aW9uIGlzIHdvcnRoIGFkZGlu Zz8gJm5ic3A7SGVyZSBhbiBvdmVydmlldyBvZiBwcmVzZW50L2Fic2VudCB1c2UgY2FzZXM6PGJy Pg0KPGJyPg0KLSBMaW5rLWxvY2FsIENvQVAgbXVsdGljYXN0IHdpdGggcmVzcG9uc2VzOiBQcmVz ZW50LCBBcHBlbmRpeCBBIG9mIGNvcmUtY29hcDxicj4NCi0gU2l0ZS1sb2NhbCBDb0FQIG11bHRp Y2FzdCwgc2luZ2xlIHN1Ym5ldDogJmx0O21pc3NpbmcmZ3Q7PGJyPg0KLSBTaXRlLWxvY2FsIENv QVAgbXVsdGljYXN0LCBtdWx0aSBzdWJuZXQsIHdpdGggb3Igd2l0aG91dCByZXNwb25zZXMgKGlu IHRoZSBuZXcgLTA0IGdyb3VwY29tbSk6IFByZXNlbnQ8YnI+DQotIEdsb2JhbCZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyBDb0FQIG11bHRpY2FzdCwgc2luZ2xlIG9yIG11bHRpIHN1Ym5ldCwgd2l0 aCBvciB3aXRob3V0IHJlc3BvbnNlczogJmx0O21pc3NpbmcmZ3Q7IC8gZGVwZW5kZW5jeSBvbiBJ QU5BIElQdjYgYWxsb2NhdGlvbjxicj4NCi0gYW55IGNvbmZpZ3VyYXRpb25zIHdpdGggYSBjZW50 cmFsIGNvbnRyb2xsZXIgb24gdGhlIGJhY2tib25lIG11bHRpY2FzdGluZzogJmx0O21pc3Npbmcm Z3Q7PGJyPg0KPGJyPg0KPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdp bi1sZWZ0OjM2LjBwdDsgdGV4dC1pbmRlbnQ6LTE4LjBwdCI+PHNwYW4gc3R5bGU9IiI+OS48c3Bh biBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOw0K PC9zcGFuPjwvc3Bhbj7igJxJdCBtaWdodCBiZSB1c2VmdWwgaWYgdGhlIHByYWN0aWNhbCBpbXBv c3NpYmlsaXR5IG9mIHNvbWUgY29uZmlndXJhdGlvbnMgaXMgaGlnaCBsaWdodGVk4oCdIC0mZ3Q7 PGJyPg0KYW55IHRob3VnaHRzLCB3aGljaCB3b3VsZCBiZSBpbXBvc3NpYmxlPzwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQ7IHRleHQtaW5kZW50 Oi0xOC4wcHQiPjxzcGFuIHN0eWxlPSIiPjEwLjwvc3Bhbj7igJx0aGUgUkQgZGlzY292ZXJ5IHdp bGwgYmUgbW9yZSBjb21wbGV4IHdoZW4gdGhlcmUgaXMgYSByb3V0ZXIgYmV0d2VlbiBsaWdodC0y IGFuZCBzd2l0Y2jigJ0gLSZndDs8YnI+DQp5ZXMsIHRoZXJlIGFyZSBpc3N1ZXMgaW4gUkQvZGlz Y292ZXJ5IGVzcGVjaWFsbHkgd2hlbiBtb3JlIHRoYW4gb25lIGlzIHByZXNlbnQgaW4gYSBuZXR3 b3JrLjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4w cHQ7IHRleHQtaW5kZW50Oi0xOC4wcHQiPjxzcGFuIHN0eWxlPSIiPjExLjwvc3Bhbj7igJxhZGRp dGlvbmFsIHJlYXNvbiB0byByZW1vdmUgcm91dGVyIGZyb20gdGhlIG11bHRpY2FzdCBjb25maWd1 cmF0aW9u4oCdLSZndDs8YnI+DQpobW0sIEkgdGhpbmsgdGhhdCB3ZSBzaG91bGQgb3B0IGZvciBo YXZpbmcgYSBzaW5nbGUgUkQgaW4gdGhlIHN5c3RlbSB0byBhdm9pZCBjb21wbGV4aXR5LiBSb3V0 ZXJzIGFyZSBvay4gKE9uZSBvZiBvdXIgZ29hbHMgaXMgdG8gZGVmaW5lIGhvdyBDb0FQIGdyb3Vw Y29tbSB3b3JrcyBldmVuIGFjcm9zcyByb3V0ZXJzKTwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQ7IHRleHQtaW5kZW50Oi0xOC4wcHQiPjxzcGFu IHN0eWxlPSIiPjEyLjwvc3Bhbj7igJxNTEQgaXMgdXNlZCB0byBmb3JtIGdyb3VwcywgY29ycmVj dD8gYnV0IHRoYXQgd2FzIGFscmVhZHkgZG9uZSBieSBlbmFibGluZyB0aGUgTUMgYWRkcmVzcyBp biB0aGUgbGlnaHRzIChwb2ludCAyKeKAnSAtJmd0Ozxicj4NClN0ZXAgMSBpcyBwdXR0aW5nIHRo ZSBNQyBhZGRyZXNzIGluIHRoZSBsaWdodHMsIHRoZW4gc3RlcCAyIGlzIHRoZSBMaWdodHMgdXNl IE1MRCB0byAqPGI+YWR2ZXJ0aXplPC9iPiogdGhpcyBhZGRyZXNzIHRvIGFueSBNTEQtZW5hYmxl ZCBSb3V0ZXJzIHByZXNlbnQgbGluay1sb2NhbC48YnI+DQpTbyBNTEQgaXMgbm90IGEgY29tbWlz c2lvbmluZy10aW1lIHByb3RvY29sIGJ1dCBydW5zIGFsbCB0aGUgdGltZSBkdXJpbmcgb3BlcmF0 aW9uLjxicj4NCk5vdGUgdGhhdCBpbiBncm91cGNvbW0gLTA0IHdlIHdpbGwgcmVtb3ZlIE1MRCBp biB0aGUgYmFzaWMgdXNlIGNhc2UgYW5kIHByZXNlbnQgaXQgYXMgYW4gb3B0aW9uIGxhdGVyLjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOzwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQ7IHRleHQtaW5kZW50Oi0xOC4wcHQiPjxz cGFuIHN0eWxlPSIiPjEzLjwvc3Bhbj7igJxXSFkgYXJlIHRoZSBtdWx0aWNhc3QgZGVzdGluYXRp b25zIHNlbmRpbmcgYmFjayByZXN1bHRzP+KAnSAtJmd0Ozxicj4NCndlIHJlbW92ZSByZXNwb25z ZXMgaW4gdGhlIG5ldyAtMDQgZ3JvdXBjb21tLiBUaGV5IGFyZSBwcmVzZW50ZWQgYXMgYW4gb3B0 aW9uYWwgdGhpbmcgdGhhdCBzZXJ2ZXJzIGNhbiBkby48YnI+DQpDb0FQIHNlcnZlcnMgbm9ybWFs bHkgTVVTVCByZXNwb25kIHRvIGEgcmVxdWVzdCB3aXRoIGEgcmVzcG9uc2UgKGNvcmUtY29hcC0x MykgYnV0IGFuIGV4Y2VwdGlvbiBpcyBub3cgbWFkZSBmb3IgbXVsdGljYXN0IHdoZXJlIGEgc2Vy dmVyIE1BWSBjaG9vc2Ugbm90IHRvLiBUaGlzIGNob2ljZSBpcyBjb21wbGV0ZWx5IGluZGVwZW5k ZW50IGZyb20gY29uZmlybWFibGUvbm9uLWNvbmZpcm1hYmxlLiBOb24tY29uZmlybWFibGUgb25s eSBtZWFucyB0aGF0DQogYW4gQUNLIG11c3Qgbm90IGJlIHNlbnQuIEFuZCBhbiBBQ0sgaXMgc29t ZXRoaW5nIGRpZmZlcmVudCBmcm9tIGEgQ29BUCByZXNwb25zZS48YnI+DQpBZ3JlZSB0aGF0IGEg cHJvdG9jb2wgbGlrZSBNUEwgY29tZXMgdmVyeSBjbG9zZSB0byDigJhyZWxpYWJsZSBtdWx0aWNh c3TigJkuPC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiPiZuYnNwOzwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPkVza288YnI+DQo8YnI+DQo8L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij4mbmJzcDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDs8L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCkZy b206IHBldGVyIHZhbiBkZXIgU3RvayBbbWFpbHRvOnN0b2tjb25zQHhzNGFsbC5ubF0gPGJyPg0K U2VudDogVHVlc2RheSAxOCBEZWNlbWJlciAyMDEyIDEyOjA2PGJyPg0KVG86IGFrYmFyIHJhaG1h bjsgRGlqaywgRXNrbzsgQ29yZTxicj4NClN1YmplY3Q6IGdyb3VwLWNvbW0gY29tbWVudHM8L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij4mbmJzcDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5IaSBBa2JhciBhbmQgRXNr byw8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDs8L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij5JIGhhZCBwcm9taXNlZCB0byByZXZpZXcsIGNvbW1lbnQgdGhlIGdyb3VwIGNv bW0gZHJhZnQuPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+QmVsb3cgdGhlIGNvbW1lbnRl ZCB0ZXh0LjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOzwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPkkgaGF2ZSBub3QgZ29uZSB2ZXJ5IGRldGFpbGVkIHdpdGggbXkgY29t bWVudHMuIEkgaG9wZSB0aGF0IGl0IGlzIGNsZWFyIGZyb20mbmJzcDsgbXkgY29tbWVudHMgdGhh dCBhIHJlb3JnYW5pemF0aW9uIG9mIHRoZSBkcmFmdCBhbmQgYSByZXZpZXcgb2YgdGhlIHVzZXMg Y2FzZXMgYXJlIG5lY2Vzc2FyeSB0byBnZXQgYSBjbGVhcmVyIHBpY3R1cmUgb2YgdGhlIGZlYXNp YmlsaXR5IG9mIGdyb3VwIGNvbW0gaW4gdGhlDQogY29udGV4dCBvZiBDb2FwLjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPiZuYnNwOzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkVz cGVjaWFseSBkaWZmaWN1bHQgdG8gdW5kZXJzdGFuZCBmb3IgbWUgd2VyZTo8L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4tIHRo ZSB1c2UgY2FzZSBuZXR3b3JrIGNvbmZpZ3VyYXRpb248L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij4tIHRoZSBmb3JtaW5nIGFuZCBlbmFibGluZyBvZiBncm91cHM8L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij4tIHVzZSBvZiByZXNwb25zZXM8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij4mbmJzcDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5Ib3BlIHRoaXMgaGVscHMu PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+R3JlZXRpbmdzLDwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOzwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPnBldGVyPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+Jm5ic3A7PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+X19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX188L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij5BYnN0cmFjdDwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOzwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyBDb0FQIGlzIGEgUkVTVGZ1bCB0 cmFuc2ZlciBwcm90b2NvbCBmb3IgY29uc3RyYWluZWQgZGV2aWNlcy4mbmJzcDsgSXQgaXM8L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsgYW50aWNpcGF0ZWQg dGhhdCBjb25zdHJhaW5lZCBkZXZpY2VzIHdpbGwgb2Z0ZW4gbmF0dXJhbGx5IG9wZXJhdGUgaW48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsgZ3JvdXBzIChl LmcuIGluIGEgYnVpbGRpbmcgYXV0b21hdGlvbiBzY2VuYXJpbyBhbGwgbGlnaHRzIGluIGEgZ2l2 ZW48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsgcm9vbSBt YXkgbmVlZCB0byBiZSBzd2l0Y2hlZCBvbi9vZmYgYXMgYSBncm91cCkuJm5ic3A7IFRoaXMgZG9j dW1lbnQ8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsgZGVm aW5lcyBob3cgdGhlIENvQVAgcHJvdG9jb2wgc2hvdWxkIGJlIHVzZWQgaW4gYSBncm91cCBjb21t dW5pY2F0aW9uPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 IGNvbnRleHQuJm5ic3A7IEFuIGFwcHJvYWNoIGZvciB1c2luZyBDb0FQIG9uIHRvcCBvZiBJUCBt dWx0aWNhc3QgaXM8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJz cDsgZGV0YWlsZWQgZm9yIGJvdGggY29uc3RyYWluZWQgYW5kIHVuLWNvbnN0cmFpbmVkIG5ldHdv cmtzLiZuYnNwOyBBbHNvLDwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNw OyZuYnNwOyB2YXJpb3VzIHVzZTwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPi9zIGNhdXNl cyAvcyBjYXNlcy88L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJz cDsgYW5kIGNvcnJlc3BvbmRpbmcgcHJvdG9jb2wgZmxvd3MgYXJlIHByb3ZpZGVkIHRvPC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IGlsbHVzdHJhdGUgaW1w b3J0YW50IGNvbmNlcHRzLiZuYnNwOyBGaW5hbGx5LCBndWlkYW5jZSBpcyBwcm92aWRlZCBmb3I8 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsgZGVwbG95bWVu dCBpbiB2YXJpb3VzIG5ldHdvcmsgdG9wb2xvZ2llcy48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij4mbmJzcDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5TdGF0dXMgb2YgdGhpcyBN ZW1vPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRoaXMgSW50ZXJuZXQtRHJhZnQgaXMgc3Vi bWl0dGVkIGluIGZ1bGwgY29uZm9ybWFuY2Ugd2l0aCB0aGU8L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsgcHJvdmlzaW9ucyBvZiBCQ1AgNzggYW5kIEJDUCA3 OS48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDs8L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsgSW50ZXJuZXQtRHJhZnRzIGFyZSB3b3JraW5n IGRvY3VtZW50cyBvZiB0aGUgSW50ZXJuZXQgRW5naW5lZXJpbmc8L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsgVGFzayBGb3JjZSAoSUVURikuJm5ic3A7IE5v dGUgdGhhdCBvdGhlciBncm91cHMgbWF5IGFsc28gZGlzdHJpYnV0ZTwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyB3b3JraW5nIGRvY3VtZW50cyBhcyBJbnRl cm5ldC1EcmFmdHMuJm5ic3A7IFRoZSBsaXN0IG9mIGN1cnJlbnQgSW50ZXJuZXQtPC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IERyYWZ0cyBpcyBhdCA8YSBo cmVmPSJodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZHJhZnRzL2N1cnJlbnQvIj4NCjxzcGFu IHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0OyB0ZXh0LWRlY29yYXRpb246bm9uZSI+aHR0cDovL2Rh dGF0cmFja2VyLmlldGYub3JnL2RyYWZ0cy9jdXJyZW50Lzwvc3Bhbj48L2E+LjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPiZuYnNwOzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZu YnNwOyZuYnNwOyZuYnNwOyBJbnRlcm5ldC1EcmFmdHMgYXJlIGRyYWZ0IGRvY3VtZW50cyB2YWxp ZCBmb3IgYSBtYXhpbXVtIG9mIHNpeCBtb250aHM8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij4mbmJzcDsmbmJzcDsmbmJzcDsgYW5kIG1heSBiZSB1cGRhdGVkLCByZXBsYWNlZCwgb3Igb2Jz b2xldGVkIGJ5IG90aGVyIGRvY3VtZW50cyBhdCBhbnk8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsgdGltZS4mbmJzcDsgSXQgaXMgaW5hcHByb3ByaWF0ZSB0 byB1c2UgSW50ZXJuZXQtRHJhZnRzIGFzIHJlZmVyZW5jZTwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyBtYXRlcmlhbCBvciB0byBjaXRlIHRoZW0gb3RoZXIg dGhhbiBhcyAmcXVvdDt3b3JrIGluIHByb2dyZXNzLiZxdW90OzwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPiZuYnNwOzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNw OyZuYnNwOyBUaGlzIEludGVybmV0LURyYWZ0IHdpbGwgZXhwaXJlIG9uIEFwcmlsIDIyLCAyMDEz LjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOzwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPkNvcHlyaWdodCBOb3RpY2U8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4m bmJzcDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsgQ29w eXJpZ2h0IChjKSAyMDEyIElFVEYgVHJ1c3QgYW5kIHRoZSBwZXJzb25zIGlkZW50aWZpZWQgYXMg dGhlPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IGRvY3Vt ZW50IGF1dGhvcnMuJm5ic3A7IEFsbCByaWdodHMgcmVzZXJ2ZWQuPC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+Jm5ic3A7PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5i c3A7Jm5ic3A7IFRoaXMgZG9jdW1lbnQgaXMgc3ViamVjdCB0byBCQ1AgNzggYW5kIHRoZSBJRVRG IFRydXN0J3MgTGVnYWw8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsm bmJzcDsgUHJvdmlzaW9ucyBSZWxhdGluZyB0byBJRVRGIERvY3VtZW50czwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyAoPGEgaHJlZj0iaHR0cDovL3RydXN0 ZWUuaWV0Zi5vcmcvbGljZW5zZS1pbmZvIj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dDsg dGV4dC1kZWNvcmF0aW9uOm5vbmUiPmh0dHA6Ly90cnVzdGVlLmlldGYub3JnL2xpY2Vuc2UtaW5m bzwvc3Bhbj48L2E+KSBpbiBlZmZlY3Qgb24gdGhlIGRhdGUgb2Y8L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij4mbmJzcDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDs8L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij5SYWhtYW4gJmFtcDsgRGlqayZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBFeHBpcmVzIEFwcmlsIDIyLCAyMDEzJm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwO1tQYWdlDQo8L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij4xXTwvcD4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0OyBm b250LWZhbWlseTpDb25zb2xhcyI+PGJyIGNsZWFyPSJhbGwiIHN0eWxlPSJwYWdlLWJyZWFrLWJl Zm9yZTphbHdheXMiPg0KPC9zcGFuPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+SW50ZXJuZXQtRHJhZnQmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgR3JvdXAgQ29tbXVuaWNhdGlvbiBmb3IgQ29BUCZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBPY3Rv YmVyDQo8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4yMDEyPC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+Jm5ic3A7PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IHB1YmxpY2F0aW9u IG9mIHRoaXMgZG9jdW1lbnQuJm5ic3A7IFBsZWFzZSByZXZpZXcgdGhlc2UgZG9jdW1lbnRzPC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IGNhcmVmdWxseSwg YXMgdGhleSBkZXNjcmliZSB5b3VyIHJpZ2h0cyBhbmQgcmVzdHJpY3Rpb25zIHdpdGggcmVzcGVj dDwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyB0byB0aGlz IGRvY3VtZW50LiZuYnNwOyBDb2RlIENvbXBvbmVudHMgZXh0cmFjdGVkIGZyb20gdGhpcyBkb2N1 bWVudCBtdXN0PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 IGluY2x1ZGUgU2ltcGxpZmllZCBCU0QgTGljZW5zZSB0ZXh0IGFzIGRlc2NyaWJlZCBpbiBTZWN0 aW9uIDQuZSBvZjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNw OyB0aGUgVHJ1c3QgTGVnYWwgUHJvdmlzaW9ucyBhbmQgYXJlIHByb3ZpZGVkIHdpdGhvdXQgd2Fy cmFudHkgYXM8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsg ZGVzY3JpYmVkIGluIHRoZSBTaW1wbGlmaWVkIEJTRCBMaWNlbnNlLjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPiZuYnNwOzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOzwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjEuJm5ic3A7IENvbnZlbnRpb25zIGFuZCBUZXJt aW5vbG9neTwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOzwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyBUaGUga2V5IHdvcmRzICZxdW90O01V U1QmcXVvdDssICZxdW90O01VU1QgTk9UJnF1b3Q7LCAmcXVvdDtSRVFVSVJFRCZxdW90OywgJnF1 b3Q7U0hBTEwmcXVvdDssICZxdW90O1NIQUxMIE5PVCZxdW90Oyw8L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsgJnF1b3Q7U0hPVUxEJnF1b3Q7LCAmcXVvdDtT SE9VTEQgTk9UJnF1b3Q7LCAmcXVvdDtSRUNPTU1FTkRFRCZxdW90OywgJnF1b3Q7TUFZJnF1b3Q7 LCBhbmQgJnF1b3Q7T1BUSU9OQUwmcXVvdDsgaW4gdGhpczwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyBkb2N1bWVudCBhcmUgdG8gYmUgaW50ZXJwcmV0ZWQg YXMgZGVzY3JpYmVkIGluIFtSRkMyMTE5XS48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4m bmJzcDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsgVGhp cyBkb2N1bWVudCBhc3N1bWVzIHJlYWRlcnMgYXJlIGZhbWlsaWFyIHdpdGggdGhlIHRlcm1zIGFu ZDwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyBjb25jZXB0 cyB0aGF0IGFyZSB1c2VkIGluIFtJLUQuaWV0Zi1jb3JlLWNvYXBdLiZuYnNwOyBJbiBhZGRpdGlv biwgdGhpczwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyBk b2N1bWVudCBkZWZpbmVzIHRoZSBmb2xsb3dpbmcgdGVybWlub2xvZ3k6PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+Jm5ic3A7PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7IEdyb3VwIENvbW11bmljYXRpb248L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgQSBzb3VyY2Ugbm9kZSBz ZW5kcyBhIHNpbmdsZSBtZXNzYWdlIHdoaWNoIGlzIGRlbGl2ZXJlZCB0bzwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBtdWx0 aXBsZSBkZXN0aW5hdGlvbiBub2Rlcywgd2hlcmUgYWxsIGRlc3RpbmF0aW9ucyBhcmUgaWRlbnRp ZmllZDwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyB0byBiZWxvbmcgdG8gYSBzcGVjaWZpYyBncm91cC4mbmJzcDsgVGhlIHNv dXJjZSBub2RlIG1heTwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPi9yZW1vdmUgb3IgbWF5 IG5vdDwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyBiZTwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBwYXJ0IG9mIHRoZSBncm91cC4mbmJzcDsgVGhlIHVu ZGVybHlpbmcgbWVjaGFuaXNtIGZvciBncm91cDwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBjb21tdW5pY2F0aW9uIGlzIGFz c3VtZWQgdG8gYmUgbXVsdGljYXN0IGJhc2VkLjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi Pi9yZW1vdmU8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgVGhlIG5ldHdvcmsgd2hlcmU8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdGhlIGdyb3VwIGNvbW11bmlj YXRpb24gdGFrZXMgcGxhY2UgY2FuIGJlIGVpdGhlciBhIGNvbnN0cmFpbmVkDQo8L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij5vcjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBhIHJlZ3VsYXIgKHVuLWNvbnN0cmFpbmVk KSBuZXR3b3JrLzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPi9jb21tZW50IG5vdCBzdXJl IGFib3V0IHRoZSBtZWFuaW5nIGFuZCBjb25zZXF1ZW5jZXM8L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij4mbmJzcDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsm bmJzcDsgTXVsdGljYXN0PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFNlbmRpbmcgYSBtZXNzYWdlIHRvIG11bHRpcGxlIGRl c3RpbmF0aW9uIG5vZGVzPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+L3Mgc2ltdWx0YW5l b3VzbHkuLzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPi9zIHdpdGggb25lIG5ldHdvcmsg aW52b2NhdGlvbiAvPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IFRoZXJlIGFyZSB2YXJpb3VzIG9wdGlvbnMgdG8gaW1wbGVtZW50IG11bHRpY2FzdCBpbmNsdWRp bmcgbGF5ZXINCjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjI8L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgKE1lZGlh IEFjY2VzcyBDb250cm9sKSBvciBsYXllciAzIChJUCkgbWVjaGFuaXNtcy48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJz cDsmbmJzcDsmbmJzcDsgSVAgTXVsdGljYXN0PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEEgc3BlY2lmaWMgbXVsdGljYXN0 IHNvbHV0aW9uIGJhc2VkIG9uIHRoZSB1c2Ugb2YgSVAgbXVsdGljYXN0PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGFkZHJl c3NlcyBhcyBkZWZpbmVkIGluICZxdW90O0lBTkEgR3VpZGVsaW5lcyBmb3IgSVB2NCBNdWx0aWNh c3Q8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgQWRkcmVzcyBBc3NpZ25tZW50cyZxdW90OyBbUkZDNTc3MV0gYW5kICZxdW90 O0lQIFZlcnNpb24gNiBBZGRyZXNzaW5nPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEFyY2hpdGVjdHVyZSZxdW90OyBbUkZD NDI5MV0uPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IExvdyBwb3dlciBhbmQgTG9zc3kgTmV0 d29yayAoTExOKTwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyBMb3cgcG93ZXIgYW5kIExvc3N5IE5ldHdvcmsgKExMTik6IEEg dHlwZSBvZiBjb25zdHJhaW5lZCBuZXR3b3JrPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHdoZXJlIHRoZSBkZXZpY2VzIGFy ZSBpbnRlcmNvbm5lY3RlZCBieSBhIHZhcmlldHkgb2YgbG93IHBvd2VyLDwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBsb3Nz eSBsaW5rcyBzdWNoIGFzIElFRUUgODAyLjE1LjQsIEJsdWV0b290aCw8L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij4mbHQ7bm90IHNvIGNvbnN0cmFpbmVkJmd0OyBXaUZpLCB3aXJlZCAmbHQ7 LyZndDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgb3IgbG93PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHBvd2VyIHBvd2VyLWxpbmUgY29tbXVuaWNhdGlvbiBs aW5rcy48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDs8L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij4mbmJzcDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4yLiZuYnNw OyBJbnRyb2R1Y3Rpb248L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDs8L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4yLjEuJm5ic3A7IEJhY2tncm91bmQ8L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJz cDsmbmJzcDsmbmJzcDsgVGhlIENvbnN0cmFpbmVkIEFwcGxpY2F0aW9uIFByb3RvY29sIChDb0FQ KSBpcyBhbiBhcHBsaWNhdGlvbjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZu YnNwOyZuYnNwOyBwcm90b2NvbCAoYW5hbG9nb3VzIHRvIEhUVFApIGZvciByZXNvdXJjZSBjb25z dHJhaW5lZCBkZXZpY2VzPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7IG9wZXJhdGluZyBpbiBhbiBJUCBuZXR3b3JrIFtJLUQuaWV0Zi1jb3JlLWNvYXBdLiZu YnNwOyBDb25zdHJhaW5lZA0KPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ZGV2aWNlczwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyBjYW4gYmUgbGFy Z2UgaW4gbnVtYmVyLCBidXQgYXJlIG9mdGVuIGhpZ2hseSBjb3JyZWxhdGVkIHRvIGVhY2gNCjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPm90aGVyPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IChlLmcuIGJ5IHR5cGUgb3IgbG9jYXRpb24pLiZuYnNw OyBGb3IgZXhhbXBsZSwgYWxsIHRoZSBsaWdodCBzd2l0Y2hlcyBpbg0KPC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+YTwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNw OyZuYnNwOyBidWlsZGluZyBtYXkgYmVsb25nIHRvIG9uZSBncm91cCBhbmQgYWxsIHRoZSB0aGVy bW9zdGF0cyBtYXkgYmVsb25nPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5i c3A7Jm5ic3A7IHRvIGFub3RoZXIgZ3JvdXAuJm5ic3A7IEdyb3VwcyBtYXkgYmUgY29tcG9zZWQg YnkgZnVuY3Rpb24uJm5ic3A7IEZvciBleGFtcGxlLDwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPiZuYnNwOzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOzwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPiZuYnNwOzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPlJh aG1hbiAmYW1wOyBEaWprJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEV4cGlyZXMgQXByaWwgMjIsIDIwMTMmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgW1BhZ2UNCjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPjNdPC9wPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7IGZvbnQtZmFt aWx5OkNvbnNvbGFzIj48YnIgY2xlYXI9ImFsbCIgc3R5bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFs d2F5cyI+DQo8L3NwYW4+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDs8L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij5JbnRlcm5ldC1EcmFmdCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyBHcm91cCBDb21tdW5pY2F0aW9uIGZvciBDb0FQJm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IE9jdG9iZXINCjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjIwMTI8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij4mbmJzcDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDs8L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsgdGhlIGdyb3VwICZxdW90O2Fs bCBsaWdodHMgaW4gYnVpbGRpbmcgb25lJnF1b3Q7IG1heSBjb25zaXN0IG9mIHRoZSBncm91cHMN CjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZxdW90O2FsbDwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyBsaWdodHMgb24gZmxvb3Igb25lIG9mIGJ1 aWxkaW5nIG9uZSZxdW90OywgJnF1b3Q7YWxsIGxpZ2h0cyBvbiBmbG9vciB0d28gb2Y8L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsgYnVpbGRpbmcgb25lJnF1 b3Q7LCBldGMuJm5ic3A7IEdyb3VwcyBtYXkgYmUgcHJlY29uZmlndXJlZDwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPi9hZGQgYmVmb3JlIGRlcGxveW1lbnQ8L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgb3IgZHluYW1pY2FsbHk8L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsgJm5ic3A7Jm5ic3A7Zm9ybWVkPC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+L2FkZCBkdXJpbmcgb3BlcmF0aW9uPC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7IC4mbmJzcDsgSWYgaW5mb3JtYXRpb24gbmVlZHMg dG8gYmUgc2VudCB0byBvciByZWNlaXZlZCBmcm9tIGEgZ3JvdXA8L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsgb2YgZGV2aWNlcywgZ3JvdXAgY29tbXVuaWNh dGlvbiBtZWNoYW5pc21zIGNhbiBpbXByb3ZlIGVmZmljaWVuY3kNCjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPmFuZDwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNw OyZuYnNwOyBsYXRlbmN5IG9mIGNvbW11bmljYXRpb24gYW5kIHJlZHVjZSBiYW5kd2lkdGggcmVx dWlyZW1lbnRzIGZvciBhPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7IGdpdmVuIGFwcGxpY2F0aW9uLiZuYnNwOyBIVFRQIGRvZXMgbm90IHN1cHBvcnQgYW55 IGVxdWl2YWxlbnQ8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJz cDsgZnVuY3Rpb25hbGl0eSB0byBDb0FQIGdyb3VwIGNvbW11bmljYXRpb24uPC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Mi4y LiZuYnNwOyBTY29wZTwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOzwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyBJbiB0aGlzIGRyYWZ0LCB3 ZSBhZGRyZXNzIHRoZSBpc3N1ZXMgcmVsYXRlZCB0byBDb0FQIGdyb3VwPC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IGNvbW11bmljYXRpb24gaW4gZGV0YWls LCB3aXRoIHVzZSBjYXNlcywgcmVjb21tZW5kZWQgYXBwcm9hY2hlcyBhbmQ8L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsgYW5hbHlzaXMgb2YgdGhlIGltcGFj dCB0byB0aGUgQ29BUCBwcm90b2NvbCBhbmQgdG8gaW1wbGVtZW50YXRpb25zLjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPi9hZGQgdGhlIHVzZSBvZiBncm91cCBjb21tdW5pY2F0aW9uIGZv ciBtRE5TIGlzIG91dCBvZiBzY29wZS48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJz cDsmbmJzcDsmbmJzcDsgVGhlIGd1aWRpbmcgcHJpbmNpcGxlIGlzIHRvIGFwcGx5IHdoZXJldmVy IHBvc3NpYmxlIGV4aXN0aW5nIElFVEY8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJz cDsmbmJzcDsmbmJzcDsgcHJvdG9jb2xzIHRvIGFjaGlldmUgZ3JvdXAgY29tbXVuaWNhdGlvbiBm dW5jdGlvbmFsaXR5LiZuYnNwOyBJbiBtYW55PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7IGNhc2VzIHRoZSBjb250cmlidXRpb24gb2YgdGhpcyBkb2N1bWVu dCBsaWVzIGluIGV4cGxhaW5pbmcgaG93PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5i c3A7Jm5ic3A7Jm5ic3A7IGV4aXN0aW5nIG1lY2hhbmlzbXMgbWF5IGJlIHVzZWQgdG88L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4vcmVtb3ZlIHRvZ2V0aGVyPC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IGZ1bGZpbGwgQ29BUCBncm91cDwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyBjb21tdW5pY2F0aW9uIG5l ZWRzIGZvciBzcGVjaWZpYyB1c2UgY2FzZXMuPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ Jm5ic3A7PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Mi4zLiZuYnNwOyBQb3RlbnRpYWwg U29sdXRpb25zIGZvciBHcm91cCBDb21tdW5pY2F0aW9uPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+Jm5ic3A7PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5i c3A7IFRoZSBjbGFzc2ljIGNvbmNlcHQgb2YgZ3JvdXA8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij4vcyBjb21tdW5pY2F0aW9ucyAvcyBjb21tdW5pY2F0aW9uPC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IGlzIHRoYXQgb2YgYSBzaW5nbGU8L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsgc291cmNlIGRpc3RyaWJ1 dGluZyBjb250ZW50IHRvIG11bHRpcGxlIGRlc3RpbmF0aW9uIHJlY2lwaWVudHMgdGhhdDwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyBhcmUgYWxsIHBhcnQg b2YgYSBncm91cC4mbmJzcDsgQmVmb3JlIGNvbnRlbnQgY2FuIGJlIGRpc3RyaWJ1dGVkLCB0aGVy ZQ0KPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+aXM8L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsgYSBzZXBhcmF0ZSBwcm9jZXNzIHRvIGZvcm0gdGhl IGdyb3VwLiZuYnNwOyBUaGUgc291cmNlIG1heSBiZSBlaXRoZXIgYTwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyBtZW1iZXIgb3Igbm9uLW1lbWJlciBvZiB0 aGUgZ3JvdXAuPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IEdyb3VwIGNvbW11bmljYXRpb24g c29sdXRpb25zIGhhdmUgZXZvbHZlZCBmcm9tICZxdW90O2JvdHRvbSZxdW90OyB0byAmcXVvdDt0 b3AmcXVvdDssPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 IGkuZS4sIGZyb20gbGF5ZXIgMiAoTWVkaWEgQWNjZXNzIENvbnRyb2wgYnJvYWRjYXN0L211bHRp Y2FzdCkgYW5kPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 IGxheWVyIDMgKElQIG11bHRpY2FzdCkgdG8gYXBwbGljYXRpb24gbGF5ZXIgZ3JvdXAgY29tbXVu aWNhdGlvbiwNCjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPmFsc288L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsgcmVmZXJyZWQgdG8gYXMgYXBwbGlj YXRpb24gbGF5ZXIgbXVsdGljYXN0LiZuYnNwOyBBIHN0dWR5IHB1Ymxpc2hlZCBpbjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyAyMDA1IFtMYW8wNV0gaWRl bnRpZmllZCBuZXcgc29sdXRpb25zIGluIHRoZSAmcXVvdDttaWRkbGUmcXVvdDsgKHJlZmVycmVk IHRvDQo8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5hczwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyBvdmVybGF5IG11bHRpY2FzdCkgdGhhdCB1dGls aXplIGFuIGluZnJhc3RydWN0dXJlIGJhc2VkIG9uIHByb3hpZXMuPC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+Jm5ic3A7PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5i c3A7Jm5ic3A7IEVhY2ggb2YgdGhlc2UgY2xhc3NlcyBvZiBzb2x1dGlvbnMgbWF5IGJlIGNvbXBh cmVkIFtMYW8wNV0gdXNpbmc8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJz cDsmbmJzcDsgbWV0cmljcyBzdWNoIGFzIGxpbmsgc3RyZXNzIGFuZCBsZXZlbCBvZiBob3N0IGNv bXBsZXhpdHk8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsg W0JhbmVyamVlMDFdLiZuYnNwOyBUaGUgcmVzdWx0cyBzaG93IGZvciBhIHJlYWxpc3RpYyBpbnRl cm5ldCB0b3BvbG9neTwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZu YnNwOyB0aGF0IElQIE11bHRpY2FzdCBpcyB0aGUgbW9zdCByZXNvdXJjZS1lZmZpY2llbnQsIHdp dGggdGhlIGRvd25zaWRlPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7IGJlaW5nIHRoYXQgaXQgcmVxdWlyZXM8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij4vcyB0aGUgbW9zdCAvcyBtb3JlIG9yZ2FuaXphdGlvbmFsPC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IGVmZm9ydCB0byBkZXBsb3kgaW4gdGhlPC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IGluZnJhc3RydWN0dXJl LiZuYnNwOyBJUCBNdWx0aWNhc3QgaXMgdGhlIHNvbHV0aW9uIGFkb3B0ZWQgYnkgdGhpcyBkcmFm dDwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyBmb3IgQ29B UCBncm91cCBjb21tdW5pY2F0aW9uLjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNw OzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOzwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPjMuJm5ic3A7IENvQVAgR3JvdXAgQ29tbXVuaWNhdGlvbiBCYXNlZCBPbiBJUCBN dWx0aWNhc3Q8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDs8L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJz cDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDs8L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij4mbmJzcDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDs8L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5SYWhtYW4gJmFtcDsgRGlqayZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBFeHBp cmVzIEFwcmlsIDIyLCAyMDEzJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IFtQYWdlDQo8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij40XTwvcD4NCjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuNXB0OyBmb250LWZhbWlseTpDb25zb2xhcyI+PGJyIGNsZWFyPSJhbGwi IHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPg0KPC9zcGFuPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+Jm5ic3A7PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+SW50ZXJuZXQt RHJhZnQmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgR3JvdXAgQ29t bXVuaWNhdGlvbiBmb3IgQ29BUCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyBPY3RvYmVyDQo8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4y MDEyPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+Jm5ic3A7PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+My4xLiZuYnNw OyBJUCBNdWx0aWNhc3QgQmFja2dyb3VuZDwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZu YnNwOzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyBJUCBN dWx0aWNhc3Qgcm91dGluZyBwcm90b2NvbHMgaGF2ZSBiZWVuIGV2b2x2aW5nIGZvciBkZWNhZGVz LDwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyByZXN1bHRp bmcgaW4gcHJvcG9zZWQgc3RhbmRhcmRzIHN1Y2ggYXMgUHJvdG9jb2wgSW5kZXBlbmRlbnQ8L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsgTXVsdGljYXN0IC0g U3BhcnNlIE1vZGUgKFBJTS1TTSkgW1JGQzQ2MDFdLiZuYnNwOyBZZXQsIGR1ZSB0byB2YXJpb3Vz PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IHRlY2huaWNh bCBhbmQgbWFya2V0aW5nIHJlYXNvbnMsIElQIE11bHRpY2FzdCByb3V0aW5nIGlzIG5vdCB3aWRl bHk8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsgZGVwbG95 ZWQgb24gdGhlIGdlbmVyYWwgSW50ZXJuZXQuJm5ic3A7IEhvd2V2ZXIsIElQIE11bHRpY2FzdCBp cyB2ZXJ5PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IHBv cHVsYXIgaW4gc3BlY2lmaWMgZGVwbG95bWVudHMgc3VjaCBhcyBpbiBlbnRlcnByaXNlIG5ldHdv cmtzIChlLmcuPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 IGZvciB2aWRlbyBjb25mZXJlbmNpbmcpLCBzbWFydCBob21lIG5ldHdvcmtzIChlLmcuJm5ic3A7 IFVQblAvbUROUykgYW5kPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7IGNhcnJpZXIgSVBUViBkZXBsb3ltZW50cy4mbmJzcDsgVGhlIHBhY2tldCBlY29ub215 IGFuZCBtaW5pbWFsIGhvc3Q8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJz cDsmbmJzcDsgY29tcGxleGl0eSBvZiBJUCBtdWx0aWNhc3QgbWFrZSBpdCBhdHRyYWN0aXZlIGZv ciBncm91cA0KPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Y29tbXVuaWNhdGlvbjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyBpbiBjb25zdHJhaW5l ZCBlbnZpcm9ubWVudHMuJm5ic3A7IFRoZXJlZm9yZSBJUCBtdWx0aWNhc3QgaXMgdGhlPC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IHJlY29tbWVuZGVkIHVu ZGVybHlpbmcgbWVjaGFuaXNtIGZvciBDb0FQIGdyb3VwIGNvbW11bmljYXRpb24sIGFuZDwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyB0aGUgYXBwcm9hY2gg YXNzdW1lZCBpbiB0aGlzIGRvY3VtZW50LjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZu YnNwOzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyBUbyBh Y2hpZXZlIElQIG11bHRpY2FzdCBiZXlvbmQgYSBzdWJuZXQsIGFuIElQIG11bHRpY2FzdCByb3V0 aW5nPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IHByb3Rv Y29sIG5lZWRzIHRvIGJlIGFjdGl2ZSBvbiByb3V0ZXJzLiZuYnNwOyBUaGUgUlBMIHByb3RvY29s IFtSRkM2NTUwXTwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNw OyBmb3IgZXhhbXBsZSBpcyBhYmxlIHRvIHJvdXRlIG11bHRpY2FzdCB0cmFmZmljIGluIGNvbnN0 cmFpbmVkIExMTnMuPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5i c3A7IFdoaWxlIFBJTS1TTSBbUkZDNDYwMV0gaXMgb2Z0ZW4gdXNlZCBmb3IgbXVsdGljYXN0IHJv dXRpbmcgaW4gdW4tPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5i c3A7IGNvbnN0cmFpbmVkIG5ldHdvcmtzLjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZu YnNwOzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyBJUCBt dWx0aWNhc3QgY2FuIGFsc28gYmUgcnVuIGluIGEgTGluay1Mb2NhbCAoTEwpIHNjb3BlLiZuYnNw OyBUaGlzIG1lYW5zPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5i c3A7IHRoYXQgdGhlcmUgaXMgbm8gcm91dGluZyBpbnZvbHZlZCBhbmQgYW4gSVAgbXVsdGljYXN0 IG1lc3NhZ2UgaXMNCjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPm9ubHk8L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsgcmVjZWl2ZWQ8L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij4vcyBvbiB0aGUgbmV0d29yayAvcyBvdmVyIHRoZTwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBsaW5rIG9uIHdo aWNoIGl0IHdhcyBzZW50LjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOzwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjMuMi4mbmJzcDsgQ29BUCBHcm91cCBEZWZpbml0aW9u IGFuZCBOYW1pbmc8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDs8L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsgQSBncm91cCBpcyBkZWZpbmVk IGFzIGEgc2V0IG9mIENvQVAgZW5kcG9pbnRzLCB3aGVyZSBlYWNoIGVuZHBvaW50DQo8L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5pczwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZu YnNwOyZuYnNwOyZuYnNwOyBjb25maWd1cmVkIHRvIHJlY2VpdmUgYSBtdWx0aWNhc3QgQ29BUCBy ZXF1ZXN0IHRoYXQgaXMgc2VudCB0byB0aGU8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4m bmJzcDsmbmJzcDsmbmJzcDsgZ3JvdXAncyBhc3NvY2lhdGVkIElQIG11bHRpY2FzdCBhZGRyZXNz LiZuYnNwOyBUaGUgZ3JvdXAgTUFZIGhhdmUgbW9yZTwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPiZuYnNwOyZuYnNwOyZuYnNwOyB0aGFuIG9uZSBhc3NvY2lhdGVkIElQIG11bHRpY2FzdCBh ZGRyZXNzLiZuYnNwOyBBbiBlbmRwb2ludCBNQVkgYmUgYTwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyBtZW1iZXIgb2YgbXVsdGlwbGUgZ3JvdXBzLiZuYnNw OyBHcm91cCBtZW1iZXJzaGlwIG9mIGFuIGVuZHBvaW50IE1BWTwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyBkeW5hbWljYWxseSBjaGFuZ2Ugb3ZlciB0aW1l LiZuYnNwOyBUaGUgZ3JvdXAgTUFZIGJlIGlkZW50aWZpZWQgYnkgYQ0KPC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+R3JvdXA8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsm bmJzcDsmbmJzcDsgTmFtZSAoW0ktRC52YW5kZXJzdG9rLWNvcmUtZG5hXSkgd2hpY2ggaXMgZGVm aW5lZCBhcyBhIHByZWZpeCBzdHJpbmc8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJz cDsmbmJzcDsmbmJzcDsgb2YgYSBHcm91cCBGUUROLiZuYnNwOyBUaGUgR3JvdXAgRlFETiBjYW4g YmUgdW5pcXVlbHkgbWFwcGVkIHRvIGEgc2l0ZS08L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij4mbmJzcDsmbmJzcDsmbmJzcDsgbG9jYWwgb3IgZ2xvYmFsIG11bHRpY2FzdCBJUCBhZGRyZXNz IHZpYSBETlMgcmVzb2x1dGlvbi48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDs8 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsgQSBDb0FQIG11 bHRpY2FzdCByZXF1ZXN0IHRoYXQgYWRkcmVzc2VzIGEgZ3JvdXAgaW5jbHVkZXMgYSBHcm91cCBV Ukk8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsgYXMgdGhl IHJlcXVlc3QgVVJJLiZuYnNwOyBBIEdyb3VwIFVSSSBoYXMgdGhlIHNjaGVtZSAnY29hcCcgYW5k IGluY2x1ZGVzPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 IGluIHRoZSBhdXRob3JpdHkgcGFydCBlaXRoZXIgYSBncm91cCBJUCBhZGRyZXNzPC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+L2FkZCAmIzQzOyBvcHRpb25hbCBwb3J0PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IG9yIGEgaG9zdG5hbWU8 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4vYWRkICYjNDM7IG9wdGlvbmFsIHBvcnQ8L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsgdGhhdDwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyBjYW4gYmUgcmVzb2x2ZWQg dG8gdGhlIGdyb3VwIElQIGFkZHJlc3MgKGUuZy4sIGEgR3JvdXAgTmFtZSBvciBHcm91cDwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyBGUUROKS4mbmJzcDsg R3JvdXAgVVJJcyBNVVNUIGZvbGxvdyB0aGUgVVJJIHN5bnRheCBbUkZDMzk4Nl0uPC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7IEEgQ29BUDwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPi9z IG5vZGUgL3MgZW5kLXBvaW50PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5i c3A7Jm5ic3A7IGJlY29tZXMgYSBncm91cCBtZW1iZXIgYnkgbGlzdGVuaW5nIGZvciBDb0FQIG1l c3NhZ2VzIG9uPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 IHRoZSBncm91cCdzIElQIG11bHRpY2FzdCBhZGRyZXNzLCBhc3N1bWluZyB0aGUgZGVmYXVsdCBD b0FQIFVEUA0KPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+cG9ydC48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsgTm90ZSB0aGF0IGEgbm9uLWRlZmF1 bHQgVURQIHBvcnQgTUFZIGJlIHNwZWNpZmllZCBmb3IgdGhlIGdyb3VwOyBpbjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyB3aGljaCBjYXNlIGltcGxlbWVu dGVycyBNVVNUIGVuc3VyZSB0aGF0IGFsbCBncm91cCBtZW1iZXJzIGFyZTwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyBjb25maWd1cmVkIHRvIHVzZSB0aGlz IHNhbWUgcG9ydC48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDs8L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4m bmJzcDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5SYWhtYW4gJmFtcDsgRGlqayZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyBFeHBpcmVzIEFwcmlsIDIyLCAyMDEzJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IFtQYWdlDQo8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij41XTwvcD4NCjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0OyBmb250LWZhbWlseTpDb25zb2xhcyI+PGJyIGNs ZWFyPSJhbGwiIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPg0KPC9zcGFuPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ SW50ZXJuZXQtRHJhZnQmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg R3JvdXAgQ29tbXVuaWNhdGlvbiBmb3IgQ29BUCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBPY3RvYmVyDQo8L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij4yMDEyPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7IEV4YW1wbGVzIG9mIGhpZXJhcmNoaWNhbCBncm91cCBuYW1pbmcg KGFuZCBzY29waW5nKSBmb3IgYSBidWlsZGluZzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PiZuYnNwOyZuYnNwOyZuYnNwOyBjb250cm9sIGFwcGxpY2F0aW9uIGFyZSBzaG93biBiZWxvdy48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgVVJJIGF1dGhvcml0eSAmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtUYXJnZXRlZCBncm91cDwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyBhbGwuYmxkZzYuZXhhbXBsZS5jb20mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgJnF1b3Q7YWxsIG5vZGVzIGluIGJ1aWxkaW5nIDYmcXVvdDs8 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgYWxsLndlc3QuYmxkZzYuZXhhbXBsZS5jb20mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJnF1 b3Q7YWxsIG5vZGVzIGluIHdlc3Qgd2luZywgYnVpbGRpbmcNCjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPjYmcXVvdDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgYWxsLmZsb29yMS53ZXN0LmJsZGc2LmV4YW1wLi4uICZxdW90 O2FsbCBub2RlcyBpbiBmbG9vciAxLCB3ZXN0IHdpbmcsPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IGJ1aWxkaW5nIDYmcXVvdDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgYWxsLmJ1MDM2LmZsb29yMS53ZXN0LmJsZGc2Li4uICZxdW90 O2FsbCBub2RlcyBpbiBvZmZpY2UgYnUwMzYsIGZsb29yMSw8L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgd2VzdCB3aW5nLCBidWlsZGluZyA2JnF1b3Q7PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+Jm5ic3A7PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 IFJldmVyc2UgbWFwcGluZyAoZnJvbSBJUCBtdWx0aWNhc3QgYWRkcmVzcyB0byBncm91cCBGUURO KSBpczwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyBzdXBw b3J0ZWQgdXNpbmcgdGhlIHJldmVyc2UgRE5TIHJlc29sdXRpb24gdGVjaG5pcXVlPC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IChbSS1ELnZhbmRlcnN0b2st Y29yZS1kbmFdKS48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDs8L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij4zLjMuJm5ic3A7IEdyb3VwIERpc2NvdmVyeSBhbmQgTWVtYmVy IERpc2NvdmVyeTwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOzwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyBDb0FQIGRlZmluZXMgYSByZXNv dXJjZSBkaXNjb3ZlcnkgY2FwYWJpbGl0eSwgYnV0IGRvZXMgbm90IHlldDwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyBzcGVjaWZ5IGhvdyB0byBkaXNjb3Zl ciBncm91cHMgKGUuZy4gZmluZCBhIGdyb3VwIHRvIGpvaW4gb3Igc2VuZCBhPC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IG11bHRpY2FzdCBtZXNzYWdlIHRv KSBvciB0byBkaXNjb3ZlciBtZW1iZXJzIG9mIGEgZ3JvdXAgKGUuZy4gdG88L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsgYWRkcmVzcyBzZWxlY3RlZCBncm91 cCBtZW1iZXJzIGJ5IHVuaWNhc3QpLiZuYnNwOyBUaGVzZSB0b3BpY3MgYXJlPC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IGVsYWJvcmF0ZWQgaW4gbW9yZSBk ZXRhaWwgaW4gW0ktRC52YW5kZXJzdG9rLWNvcmUtZG5hXSBpbmNsdWRpbmc8L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsgZXhhbXBsZXMgZm9yIHVzaW5nIERO Uy1TRCBhbmQgQ29SRSBSZXNvdXJjZSBEaXJlY3RvcnkuPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+Jm5ic3A7PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+My4zLjEuJm5ic3A7IERO Uy1TRDwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOzwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyBETlMtYmFzZWQgU2VydmljZSBEaXNjb3Zl cnkgW0ktRC5jaGVzaGlyZS1kbnNleHQtZG5zLXNkXSBkZWZpbmVzIGE8L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsgY29udmVudGlvbmFsIHdheSB0byBjb25m aWd1cmUgRE5TIFBUUiwgU1JWLCBhbmQgVFhUIHJlY29yZHMgdG8NCjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPmVuYWJsZTwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZu YnNwOyZuYnNwOyBlbnVtZXJhdGlvbiBvZiBzZXJ2aWNlcywgc3VjaCBhcyBzZXJ2aWNlcyBvZmZl cmVkIGJ5IENvQVAgbm9kZXMsIG9yPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7 ICZuYnNwOyZuYnNwO2VudW1lcmF0aW9uIG9mIGFsbCBDb0FQIG5vZGVzLCB3aXRoaW4gc3BlY2lm aWVkIHN1YmRvbWFpbnMuJm5ic3A7IEE8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJz cDsmbmJzcDsmbmJzcDsgc2VydmljZSBpcyBzcGVjaWZpZWQgYnkgYSBuYW1lIG9mIHRoZSBmb3Jt PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZsdDtJbnN0 YW5jZSZndDsuJmx0O1NlcnZpY2VUeXBlJmd0Oy4mbHQ7RG9tYWluJmd0Oywgd2hlcmUgdGhlIHNl cnZpY2UgdHlwZSBmb3IgQ29BUDwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZu YnNwOyZuYnNwOyBub2RlcyBpcyBfY29hcC5fdWRwIGFuZCB0aGUgZG9tYWluIGlzIGEgRE5TIGRv bWFpbiBuYW1lIHRoYXQ8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsm bmJzcDsgaWRlbnRpZmllcyBhIGdyb3VwIGFzIGluIHRoZSBleGFtcGxlcyBhYm92ZS4mbmJzcDsg Rm9yIGVhY2ggQ29BUA0KPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ZW5kLXBvaW50PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IGluIGEgZ3JvdXAs IGEgUFRSIHJlY29yZCB3aXRoIHRoZSBuYW1lIF9jb2FwLl91ZHAgYW5kL29yIGEgUFRSDQo8L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5yZWNvcmQ8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsgd2l0aCB0aGUgbmFtZSBfY29hcC5fdWRwLiZsdDtEb21h aW4mZ3Q7IGlzIGRlZmluZWQgYW5kIGl0IHBvaW50cyB0byBhbiBTUlY8L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsgcmVjb3JkIGhhdmluZyB0aGUgJmx0O0lu c3RhbmNlJmd0Oy4mbHQ7U2VydmljZVR5cGUmZ3Q7LiZsdDtEb21haW4mZ3Q7IG5hbWUuPC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IEFsbCBDb0FQIG5vZGVzIGluIGEgZ2l2ZW4gc3ViZG9tYWlu IG1heSBiZSBlbnVtZXJhdGVkIGJ5IHNlbmRpbmcgYTwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPiZuYnNwOyZuYnNwOyZuYnNwOyBxdWVyeSBmb3IgUFRSIHJlY29yZHMgbmFtZWQgX2NvYXAu X3VkcCB0byB0aGUgYXV0aG9yaXRhdGl2ZSBETlM8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij4mbmJzcDsmbmJzcDsmbmJzcDsgc2VydmVyIGZvciB0aGF0IHpvbmUuJm5ic3A7IEEgbGlzdCBv ZiBTUlYgcmVjb3JkcyBpcyByZXR1cm5lZC4mbmJzcDsgRWFjaCBTUlY8L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsgcmVjb3JkIGNvbnRhaW5zIHRoZSBwb3J0 IGFuZCBob3N0IG5hbWUgKEFBQUEgcmVjb3JkKSBvZiBhIENvQVAgbm9kZS48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsgVGhlIElQIGFkZHJlc3Mgb2YgdGhl IG5vZGUgaXMgb2J0YWluZWQgYnkgcmVzb2x2aW5nIHRoZSBob3N0IG5hbWUuPC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IEROUy1TRCBhbHNvIHNwZWNpZmll cyBhbiBvcHRpb25hbCBUWFQgcmVjb3JkLCBoYXZpbmcgdGhlIHNhbWUgbmFtZQ0KPC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+YXM8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJz cDsmbmJzcDsmbmJzcDsgdGhlIFNSViByZWNvcmQsIHdoaWNoIGNhbiBjb250YWluICZxdW90O2tl eT12YWx1ZSZxdW90OyBhdHRyaWJ1dGVzLiZuYnNwOyBUaGlzIGNhbjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyBiZSB1c2VkIHRvIHN0b3JlIGluZm9ybWF0 aW9uIGFib3V0IHRoZSBkZXZpY2UsIGUuZy4gc2NoZW1hPURBTEksPC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IHR5cGU9c3dpdGNoLCBncm91cD1saWdodGlu Zy5ibGRnNiwgZXRjLjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOzwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PiZuYnNwOzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOzwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPlJhaG1hbiAmYW1wOyBEaWprJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEV4cGlyZXMgQXByaWwg MjIsIDIwMTMmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgW1BhZ2UNCjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjZdPC9wPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7IGZvbnQtZmFtaWx5OkNvbnNvbGFzIj48YnIgY2xlYXI9ImFsbCIgc3R5bGU9InBh Z2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+DQo8L3NwYW4+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij4mbmJzcDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5JbnRlcm5ldC1EcmFmdCZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBHcm91cCBDb21tdW5pY2F0aW9u IGZvciBDb0FQJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IE9jdG9iZXINCjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjIwMTI8L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij4mbmJzcDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsg QW5vdGhlciBmZWF0dXJlIG9mIEROUy1TRCBpcyB0aGUgYWJpbGl0eSB0byBzcGVjaWZ5IHNlcnZp Y2Ugc3VidHlwZXM8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJz cDsgdXNpbmcgUFRSIHJlY29yZHMuJm5ic3A7IEZvciBleGFtcGxlLCBvbmUgY291bGQgcmVwcmVz ZW50IGFsbCB0aGUgQ29BUDwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNw OyZuYnNwOyBncm91cHMgaW4gYSBzdWJkb21haW4gYnkgUFRSIHJlY29yZHMgd2l0aCB0aGUgbmFt ZTwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyBfZ3JvdXAu X3N1Yi5fY29hcC5fdWRwIG9yIGFsdGVybmF0aXZlbHk8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsgX2dyb3VwLl9zdWIuX2NvYXAuX3VkcC4mbHQ7RG9tYWlu Jmd0Oy48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDs8L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij4zLjMuMi4mbmJzcDsgQ29SRSBSZXNvdXJjZSBEaXJlY3Rvcnk8L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij4mbmJzcDsmbmJzcDsmbmJzcDsgQ29SRSBSZXNvdXJjZSBEaXJlY3RvcnkgW0ktRC5zaGVsYnkt Y29yZS1yZXNvdXJjZS1kaXJlY3RvcnldIGRlZmluZXM8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsgdGhlIGNvbmNlcHQgb2YgYSBSZXNvdXJjZSBEaXJlY3Rv cnkgKFJEKSBzZXJ2ZXIgd2hlcmUgQ29BUCBzZXJ2ZXJzPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IGNhbiByZWdpc3RlciB0aGVpciByZXNvdXJjZXMgb2Zm ZXJlZCBhbmQgQ29BUCBjbGllbnRzIGNhbiBkaXNjb3ZlcjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyB0aGVzZSByZXNvdXJjZXMgYnkgcXVlcnlpbmcgdGhl IFJEIHNlcnZlci4mbmJzcDsgUkQgc3ludGF4IGNhbiBiZSBtYXBwZWQ8L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsgdG8gRE5TLVNEIHN5bnRheCBhbmQgdmlj ZSB2ZXJzYSBbSS1ELmx5bm4tY29yZS1kaXNjb3ZlcnktbWFwcGluZ10sPC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IHN1Y2ggdGhhdCB0aGUgYWJvdmUgYXBw cm9hY2ggY2FuIGJlIHJldXNlZCBmb3IgZ3JvdXAgZGlzY292ZXJ5IGFuZDwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyBncm91cCBtZW1iZXIgZGlzY292ZXJ5 LjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOzwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPiZuYnNwOyAvcmVtb3ZlJm5ic3A7IFNwZWNpZmljYWxseSwgdGhlIERvbWFpbiAo ZCkgcGFyYW1ldGVyIGNhbiBiZSBzZXQgdG8gdGhlDQo8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij5ncm91cCBVUkkgYnk8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJz cDsmbmJzcDsgYW4gZW5kLXBvaW50IHJlZ2lzdGVyaW5nIHRvIHRoZSBSRC4mbmJzcDsgSWYgYW4g ZW5kLXBvaW50IHdhbnRzIHRvIGpvaW48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJz cDsmbmJzcDsmbmJzcDsgbXVsdGlwbGUgZ3JvdXBzLCBpdCBoYXMgdG8gcmVwZWF0IHRoZSByZWdp c3RyYXRpb24gcHJvY2VzcyBmb3IgZWFjaDwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZu YnNwOyZuYnNwOyZuYnNwOyBncm91cCBpdCB3YW50cyB0byBqb2luLjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPi9lbmQgcmVtb3ZlPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+L2Nv bW1lbnQgZCBwYXJhbWV0ZXIgc2VtYW50aWNzIG5vdCBjbGVhcjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPiZuYnNwOzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjMuNC4mbmJzcDsg R3JvdXAgUmVzb3VyY2UgTWFuaXB1bGF0aW9uPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ Jm5ic3A7PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IEdy b3VwIGNvbW11bmljYXRpb25zIFNIQUxMIG9ubHkgYmUgdXNlZCBmb3IgaWRlbXBvdGVudCBtZXRo b2RzIChpLmUuPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 IENvQVAgR0VULCBQVVQsIERFTEVURSkuJm5ic3A7IFRoZSBDb0FQIG1lc3NhZ2VzIHRoYXQgYXJl IHNlbnQgdmlhPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 IG11bHRpY2FzdCBTSEFMTCBiZSBOb24tQ29uZmlybWFibGUuPC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+Jm5ic3A7PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7IEEgdW5pY2FzdCByZXNwb25zZSBwZXIgc2VydmVyIE1BWSBiZSBzZW50IGJhY2sgdG8g YW5zd2VyIHRoZSBncm91cDwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNw OyZuYnNwOyByZXF1ZXN0IChlLmcuIHJlc3BvbnNlICZxdW90OzIuMDUgQ29udGVudCZxdW90OyB0 byBhIGdyb3VwIEdFVCByZXF1ZXN0KSB0YWtpbmc8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij4mbmJzcDsmbmJzcDsmbmJzcDsgaW50byBhY2NvdW50IHRoZSBjb25nZXN0aW9uIGNvbnRyb2wg cnVsZXMgZGVmaW5lZCBpbjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNw OyZuYnNwOyBbSS1ELmlldGYtY29yZS1jb2FwXS4mbmJzcDsgVGhlIHVuaWNhc3QgcmVzcG9uc2Vz IG1heSBiZSBhIG1peHR1cmUgb2Y8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsm bmJzcDsmbmJzcDsgc3VjY2VzcyAoZS5nLiAyLjA1IENvbnRlbnQpIGFuZCBmYWlsdXJlIChlLmcu IDQuMDQgTm90IEZvdW5kKSBjb2RlczwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNw OyZuYnNwOyZuYnNwOyBkZXBlbmRpbmcgb24gdGhlIGluZGl2aWR1YWwgc2VydmVyIHByb2Nlc3Np bmcgcmVzdWx0LjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOzwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyBHcm91cCBjb21tdW5pY2F0aW9u cyBTSEFMTCBOT1QgYmUgdXNlZCBmb3Igbm9uLWlkZW1wb3RlbnQgbWV0aG9kczwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyAoaS5lLiZuYnNwOyBDb0FQIFBP U1QpLiZuYnNwOyBUaGlzIGlzIGJlY2F1c2Ugbm90IGFsbCBncm91cCBtZW1iZXJzIGFyZTwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyBndWFyYW50ZWVkIHRv IHJlY2VpdmUgdGhlIG11bHRpY2FzdCByZXF1ZXN0LCBhbmQgdGhlIHNlbmRlciBjYW4gbm90PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IHJlYWRpbHkgZmlu ZCBvdXQgd2hpY2ggZ3JvdXAgbWVtYmVycyBkaWQgbm90IHJlY2VpdmUgaXQuPC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5i c3A7Jm5ic3A7Jm5ic3A7IEFsbCBub2RlcyBpbiBhIGdpdmVuIGdyb3VwIFNIT1VMRCByZWNlaXZl IHRoZSBzYW1lIHJlcXVlc3Q8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4vcmVtb3ZlIHdp dGggaGlnaCBwcm9iYWJpbGl0eS48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4vY29tbWVu dCBJIGRvbid0IHNlZSB3aGVyZSBwcm9iYWJpbGl0eSBjb21lcyBpbi48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsgVGhpcyB3aWxsIG5vdCBiZSB0aGUgY2Fz ZSBpZiB0aGVyZSBpcyBkaXZlcnNpdHkgaW4gdGhlPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IGF1dGhvcml0eSBwb3J0IChpLmUuIGEgZGl2ZXJzaXR5IG9m IGR5bmFtaWMgcG9ydCBhZGRyZXNzZXMgYWNyb3NzDQo8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij50aGU8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsg Z3JvdXApIG9yIGlmIHRoZSB0YXJnZXRlZCByZXNvdXJjZSBpcyBsb2NhdGVkIGF0IGRpZmZlcmVu dCBwYXRocyBvbjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNw OyBkaWZmZXJlbnQgbm9kZXMuPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRoZXJlZm9yZSwg c29tZSBtZWFzdXJlcyBtdXN0IGJlIHByZXNlbnQgdG8gZW5zdXJlIHVuaWZvcm1pdHkgaW4NCjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPnBvcnQ8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsgbnVtYmVyIGFuZCByZXNvdXJjZSBuYW1lcy9sb2NhdGlv bnMgd2l0aGluIGEgZ3JvdXAuJm5ic3A7IFRoaXMgZG9jdW1lbnQ8L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsgcHJvcG9zZXMgdGhlIGZvbGxvd2luZyBtZWFz dXJlczo8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDs8L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij4mbmJzcDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDs8 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5SYWhtYW4gJmFtcDsgRGlqayZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBF eHBpcmVzIEFwcmlsIDIyLCAyMDEzJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IFtQYWdlDQo8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij43XTwvcD4NCjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0OyBmb250LWZhbWlseTpDb25zb2xhcyI+PGJyIGNsZWFyPSJh bGwiIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPg0KPC9zcGFuPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+Jm5ic3A7PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+SW50ZXJu ZXQtRHJhZnQmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgR3JvdXAg Q29tbXVuaWNhdGlvbiBmb3IgQ29BUCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyBPY3RvYmVyDQo8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij4yMDEyPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+Jm5ic3A7PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7IG8mbmJzcDsgQWxsIENvQVAgbXVsdGljYXN0IHJlcXVlc3RzIE1VU1QgYmUg c2VudCBlaXRoZXIgdG8gdGhlIGRlZmF1bHQ8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgQ29BUCBVRFAgcG9ydCAoaS5lLiBk ZWZhdWx0IFVyaS1Qb3J0IGFzIGRlZmluZWQgaW48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgW0ktRC5pZXRmLWNvcmUtY29h cF0pLCBvciB0byBhIHBvcnQgbnVtYmVyIG9idGFpbmVkIHZpYSBhIHNlcnZpY2U8L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg ZGlzY292ZXJ5IGxvb2t1cCBvcGVyYXRpb24gYXMgYSB2YWxpZCBDb0FQIHBvcnQgZm9yIHRoZSB0 YXJnZXRlZDwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyBtdWx0aWNhc3QgZ3JvdXAuPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+Jm5ic3A7PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5i c3A7IG8mbmJzcDsgQWxsIENvQVAgbXVsdGljYXN0IHJlcXVlc3RzIFNIT1VMRCBvcGVyYXRlIG9u bHkgb24gVVJJcyAobGlua3MpPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHdoaWNoIHdlcmU8L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij4vcyByZXRyZWl2ZWQgL3MgcmV0cmlldmVkPC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGVpdGhlciBmcm9t IGEgJnF1b3Q7Ly53ZWxsLWtub3duL2NvcmUmcXVvdDsgbG9va3VwIG9uPC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGF0IGxl YXN0IG9uZSBncm91cCBtZW1iZXIgbm9kZSwgb3IgZnJvbSBhbiBlcXVpdmFsZW50IHNlcnZpY2U8 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgZGlzY292ZXJ5IGxvb2t1cCB3aGljaCByZXR1cm5zIGVpdGhlciB0aGUgcmVzb3Vy Y2VzIHN1cHBvcnRlZCBieTwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBhbGwgZ3JvdXAgbWVtYmVycyBvciByZXNvdXJjZXMg c3VwcG9ydGVkIGJ5IG9uZSBwYXJ0aWN1bGFyIGdyb3VwPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IG1lbWJlci48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4vY29tbWVudCBzbyBzZXR0aW5nIGEgbXVsdGljYXN0IGFk ZHJlc3MgaW4gYSBzb3VyY2UgYXQgaW5zdGFsbGF0aW9uIGlzDQo8L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij5mb3JiaWRkZW4/PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7 PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+My41LiZuYnNwOyBDb25maWd1cmluZyBHcm91cCBNZW1iZXJzaGlwIEluIEVuZHBv aW50czwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOzwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyBJbiBzb21lIHVzZSBjYXNlcywgdGhlIGdy b3VwIG1lbWJlcnNoaXAgb2YgZW5kcG9pbnRzIG5lZWRzIHRvIGJlPC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IGNvbmZpZ3VyYWJsZSBhZnRlciB0aGUgbmV0 d29yayBoYXMgYmVlbiBkZXBsb3llZC4mbmJzcDsgRXhhbXBsZSB1c2UgY2FzZXM8L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsgY2FuIGJlIGZvdW5kIGluIGJ1 aWxkaW5nIGNvbnRyb2w6IGEgY29tbWlzc2lvbmluZyB0b29sIGRldGVybWluZXMgdG88L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsgd2hpY2ggZ3JvdXBzIGEg bGlnaHQgb3Igc2Vuc29yIG5vZGUgYmVsb25ncywgYW5kIHdyaXRlcyB0aGlzPC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IGluZm9ybWF0aW9uIHRvIGFsbCBu b2Rlcywgd2hpY2ggY2FuIHN1YnNlcXVlbnRseSBqb2luIHRoZSBjb3JyZWN0PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IGdyb3VwLjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPiZuYnNwOzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNw OyZuYnNwOyZuYnNwOyBUbyBhY2hpZXZlIHNtb290aGVyIGludGVyb3BlcmFiaWxpdHkgYmV0d2Vl biBub2Rlcy9lbmRwb2ludHMgZnJvbTwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNw OyZuYnNwOyZuYnNwOyBkaWZmZXJlbnQgbWFudWZhY3R1cmVycywgaXQgaXMgcHJvcG9zZWQgaGVy ZSB0byBkZWZpbmUgYW4gT1BUSU9OQUw8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJz cDsmbmJzcDsmbmJzcDsgc3RhbmRhcmRpemVkIFJFU1RmdWwgbWVhbnMgb2YgY29uZmlndXJpbmcg Q29BUCBlbmRwb2ludHMgd2l0aDwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZu YnNwOyZuYnNwOyByZWxldmFudCBncm91cCBpbmZvcm1hdGlvbi48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij4mbmJzcDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJz cDsmbmJzcDsgQ29BUCBlbmRwb2ludHMgaW1wbGVtZW50aW5nIHRoaXMgbWVjaGFuaXNtIE1VU1Qg c3VwcG9ydCBhPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 IGRpc2NvdmVyYWJsZSAmcXVvdDtHcm91cCBDb25maWd1cmF0aW9uJnF1b3Q7IHJlc291cmNlIG9m IHJlc291cmNlIHR5cGUgKHJ0KTwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZu YnNwOyZuYnNwOyBbUkZDNjY5MF0gJnF1b3Q7Y29yZS5ncCZxdW90Oy4mbmJzcDsgVGhpcyByZXNv dXJjZSAoYW5kIHBlcmhhcHMgaXRzIHN1Yi1yZXNvdXJjZXMsPC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRCRCkgYXJlIHVzZWQgdG8gbWFuYWdlIGdyb3Vw IG1lbWJlcnNoaXAuJm5ic3A7IFRocmVlIGRlc2lnbiBvcHRpb25zIGZvcjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyB0aGlzIG1lY2hhbmlzbSBhcmUgcHJl c2VudGVkIGhlcmUgYXMgYSBwbGFjZWhvbGRlciAoVEJEKS48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij4mbmJzcDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsm bmJzcDsgRGVzaWduIDE6IHVzZSBDb1JFIGxpbmsgZm9ybWF0IHBheWxvYWRzIHRvIGNvbW11bmlj YXRlIGdyb3VwPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 IG1lbWJlcnNoaXAgdG8gZW5kcG9pbnRzLiZuYnNwOyAoVEJEIE5vdCBjbGVhciBob3cgdGhpcyBz aG91bGQgYmU8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsg cmVhbGl6ZWQuKTwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPi9jb21tZW50LCBub3QgY2xl YXIgd2hhdCB5b3UgbWVhbiBlaXRoZXIuIFJlbW92ZSBkZXNpZ24gMSBpbiB0aGlzIHN0YXRlPC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IERlc2lnbiAyOiB1c2UgYSBKU09OIHR5cGUgcmVzb3Vy Y2UuJm5ic3A7IEZvciBleGFtcGxlLCBhIEdFVCBvbiB0aGU8L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsgJnF1b3Q7Y29yZS5ncCZxdW90OyByZXNvdXJjZSBy ZXR1cm5zIGEgSlNPTiBhcnJheSBvZiBncm91cCBvYmplY3RzLjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPiZuYnNwOzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBSZXE6IEdFVCAvZ3A8L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgUmVzOiAyLjA1 IENvbnRlbnQgKENvbnRlbnQtRm9ybWF0OiBhcHBsaWNhdGlvbi9qc29uKTwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBbIHsg JnF1b3Q7biZxdW90OzogJnF1b3Q7Um9vbS1BLUxpZ2h0cy5mbG9vcjEud2VzdC5ibGRnNi5leGFt cGxlLmNvbSZxdW90Oyw8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJnF1b3Q7aXAm cXVvdDs6ICZxdW90O2ZmMDU6OjQyMDA6ZjdmZTplZDM3OjE0Y2EmcXVvdDsgfTwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBd PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IHdoZXJlICZxdW90O24mcXVvdDsgZGVmaW5lcyB0 aGUgR3JvdXAgRlFETiBhbmQgJnF1b3Q7aXAmcXVvdDsgZGVmaW5lcyB0aGUgYXNzb2NpYXRlZDwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyBtdWx0aWNhc3Qg SVAgYWRkcmVzcy4mbmJzcDsgQXMgYSBuZXh0IGV4YW1wbGUsIHRoZSBzYW1lIGVuZHBvaW50IGNh biBiZTwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOzwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPiZuYnNwOzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOzwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPlJhaG1hbiAmYW1wOyBEaWprJm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEV4 cGlyZXMgQXByaWwgMjIsIDIwMTMmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgW1BhZ2UNCjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjhdPC9wPg0KPHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC41cHQ7IGZvbnQtZmFtaWx5OkNvbnNvbGFzIj48YnIgY2xlYXI9ImFs bCIgc3R5bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+DQo8L3NwYW4+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij4mbmJzcDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5JbnRlcm5l dC1EcmFmdCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBHcm91cCBD b21tdW5pY2F0aW9uIGZvciBDb0FQJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IE9jdG9iZXINCjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PjIwMTI8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDs8L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij4mbmJzcDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsm bmJzcDsmbmJzcDsgYWRkZWQgdG8gYW5vdGhlciBncm91cCBieSBhIFBPU1Qgb24gdGhlIHJlc291 cmNlIHdpdGggYSBKU09OIGdyb3VwPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7IG9iamVjdDo8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDs8 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgUmVxOiBQT1NUIC9ncCAoQ29udGVudC1Gb3JtYXQ6IGFwcGxpY2F0aW9uL2pzb24p PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IHsgJnF1b3Q7biZxdW90OzogJnF1b3Q7Zmxvb3IxLndlc3QuYmxkZzYuZXhhbXBs ZS5jb20mcXVvdDssPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZxdW90O2lwJnF1b3Q7OiAmcXVvdDtm ZjA1Ojo0MjAwOmY3ZmU6ZWQzNzoxNGNiJnF1b3Q7IH08L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgUmVzOiAyLjA0IENoYW5n ZWQ8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDs8L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsgRGVzaWduIDM6IGRlZmluZSBuYW1lZCBzdWIt cmVzb3VyY2VzLCBlYWNoIHN1Yi1yZXNvdXJjZSByZXByZXNlbnRpbmc8L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsgYSBncm91cCBtZW1iZXJzaGlwLiZuYnNw OyBUaGUgcGF5bG9hZCBvZiB0aGUgc3ViLXJlc291cmNlIG1heSBiZSBKU09OIG9yDQo8L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5hPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5i c3A7Jm5ic3A7Jm5ic3A7IHNpbXBsZSBwcmUtZGVmaW5lZCBmb3JtYXQuJm5ic3A7IE9yIGFsdGVy bmF0aXZlbHksIGluZm9ybWF0aW9uIGlzDQo8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5w cm92aWRlZDwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyB2 aWEgUE9TVCB3aXRoIHF1ZXJ5IHBhcmFtZXRlcnMuPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+Jm5ic3A7PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+L2NvbW1lbnQgYXJlIHRoZXNl IG11dHVhbGx5IGV4Y2x1c2l2ZSBkZXNpZ25zPzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi Pi9jb21tZW50IGRlc2lnbiAyIHdpdGhvdXQgSlNPTiBpcyBhbHMgcG9zc2libGU8L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij4vY29tbWVudCBkZXNpZ24gd2l0aCBTUlYgYW5kIFRYdCByZWNv cmRzIGlzIGFsc28gcG9zc2libGU8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4vY29tbWVu dCB0aGVyZSBhcmUgMiB3YXlzOiAoMSkgdGhlIG5vZGUgcXVlcmllcyB0byB3aGljaCBncm91cCBp dA0KPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+YmVsb25nczwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPi9jb21tZW50Jm5ic3A7ICgyKSBhbiBpbnN0YWxhdGlvbiB0b29scyBpbnN0 cnVjdHMgdGhlIG5vZGUgdG8gd2hpY2ggZ3JvdXBzDQo8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij5pdCBiZWxvbmdzPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+L2NvbW1lbnQgbm90 IGNsZWFyIGluIHRleHQgdGhhdCB0aGlzIGNob2ljZSBleGlzdHMgb3IgdGhhdCBhIGNob2ljZSB3 YXMNCjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPm1hZGUuPC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+Jm5ic3A7PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+My42LiZuYnNw OyBDb25nZXN0aW9uIENvbnRyb2w8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDs8 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsgTXVsdGljYXN0 IENvQVAgcmVxdWVzdHMgbWF5IHJlc3VsdCBpbiBhIG11bHRpdHVkZSBvZiByZXBsaWVzIGZyb208 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsgZGlmZmVyZW50 IG5vZGVzLCBwb3RlbnRpYWxseSBjYXVzaW5nIGNvbmdlc3Rpb24uJm5ic3A7IFRoZXJlZm9yZSBz ZW5kaW5nPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IG11 bHRpY2FzdDwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPi9zIHJlcXVlc3RzIC9zIHJlcGxp ZXM8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg c2hvdWxkIGJlIGNvbnNlcnZhdGl2ZWx5IGNvbnRyb2xsZWQuPC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+Jm5ic3A7PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7IFRoZSBiYXNlIENvQVAgZHJhZnQgW0ktRC5pZXRmLWNvcmUtY29hcF0gcmVkdWNlcyBt dWx0aWNhc3Qtc3BlY2lmaWM8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJz cDsmbmJzcDsgY29uZ2VzdGlvbiByaXNrcyB0aHJvdWdoIHRoZSBmb2xsb3dpbmcgbWVhc3VyZXM6 PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IG8mbmJzcDsgQSBzZXJ2ZXIgTUFZIGNob29zZSBu b3QgdG8gcmVzcG9uZCB0byBhIG11bHRpY2FzdCByZXF1ZXN0IGlmPC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHRoZXJlJ3Mg bm90aGluZyB1c2VmdWwgdG8gcmVzcG9uZCAoZS5nLiBlcnJvciBvciBlbXB0eSByZXNwb25zZSku PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IG8mbmJzcDsgQSBzZXJ2ZXIgU0hPVUxEIGxpbWl0 IHRoZSBzdXBwb3J0IGZvciBtdWx0aWNhc3QgcmVxdWVzdHMgdG88L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgc3BlY2lmaWMg cmVzb3VyY2VzIHdoZXJlIG11bHRpY2FzdCBvcGVyYXRpb24gaXMgcmVxdWlyZWQuPC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7IG8mbmJzcDsgQSBtdWx0aWNhc3QgcmVxdWVzdCBNVVNUIGJlIE5v bi1Db25maXJtYWJsZS48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4vY29tbWVudCB3aGF0 IGFib3V0IHRoZSByZXBseT88L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDs8L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsgbyZuYnNwOyBBIHNl cnZlciBkb2VzIG5vdCByZXNwb25kIGltbWVkaWF0ZWx5IHRvIGEgbXVsdGljYXN0IHJlcXVlc3Qs IGJ1dDwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyBTSE9VTEQgZmlyc3Qgd2FpdCBmb3IgYSB0aW1lIHRoYXQgaXMgcmFuZG9t bHkgcGlja2VkIHdpdGhpbiBhPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHByZWRldGVybWluZWQgdGltZSBpbnRlcnZhbCBj YWxsZWQgdGhlIExlaXN1cmUuPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IG8mbmJzcDsgQSBz ZXJ2ZXIgU0hPVUxEIE5PVCBhY2NlcHQgbXVsdGljYXN0IHJlcXVlc3RzIHRoYXQgY2FuIG5vdCBi ZTwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyBhdXRoZW50aWNhdGVkLjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPi9j b21tZW50IGludm9raW5nIGFzIG1hbnkgY2VydGlmaWNhdGVzPzwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPiZuYnNwOzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNw OyZuYnNwOyBBZGRpdGlvbmFsIGd1aWRlbGluZXMgdG8gcmVkdWNlIGNvbmdlc3Rpb24gcmlza3Mg YXJlOjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOzwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyBvJm5ic3A7IEEgc2VydmVyIGluIGFuIExM TiBzaG91bGQgb25seSBzdXBwb3J0IG11bHRpY2FzdCBHRVQgZm9yDQo8L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij5yZXNvdXJjZXM8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdGhhdCBhcmUgc21hbGwsIGUuZy48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4vcmVtb3ZlIGZvciBhbiBMTE4gdGhhdCBjb3VsZCBt ZWFuPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IHRoZSBwYXlsb2FkIG9mIHRoZTwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyByZXNwb25zZSBmaXRzIGlu dG8gYSBzaW5nbGUgbGluay1sYXllciBmcmFtZS48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij4mbmJzcDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsg byZuYnNwOyBBIHNlcnZlciBjYW4gbWluaW1pemUgdGhlIHBheWxvYWQgbGVuZ3RoIGluIHJlc3Bv bnNlIHRvIGE8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgbXVsdGljYXN0IEdFVCBvbiAmcXVvdDsvLndlbGwta25vd24vY29y ZSZxdW90OyBieSB1c2luZyBoaWVyYXJjaHkgaW48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYXJyYW5naW5nIGxpbmsgZGVz Y3JpcHRpb25zIGZvciB0aGUgcmVzcG9uc2UuJm5ic3A7IEFuIGV4YW1wbGUgb2YgdGhpczwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyBpcyBnaXZlbiBpbiBTZWN0aW9uIDUgb2YgW1JGQzY2OTBdLjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPiZuYnNwOzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOzwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOzwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPiZuYnNwOzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPlJhaG1hbiAmYW1wOyBE aWprJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IEV4cGlyZXMgQXByaWwgMjIsIDIwMTMmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgW1BhZ2UNCjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjld PC9wPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7IGZvbnQtZmFtaWx5OkNvbnNvbGFz Ij48YnIgY2xlYXI9ImFsbCIgc3R5bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+DQo8L3Nw YW4+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij5JbnRlcm5ldC1EcmFmdCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyBHcm91cCBDb21tdW5pY2F0aW9uIGZvciBDb0FQJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IE9jdG9iZXINCjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPjIwMTI8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDs8 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsgbyZuYnNwOyBQcmVmZXJhYmx5IElQIG11bHRpY2Fz dCB3aXRoIGxpbmstbG9jYWwgc2NvcGUgc2hvdWxkIGJlIHVzZWQsPC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHJhdGhlciB0 aGFuIGdsb2JhbCBvciBzaXRlLWxvY2FsLjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZu YnNwOzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyBvJm5i c3A7IFRoZSBIb3AgTGltaXQgZmllbGQgaW4gdGhlIElQdjYgcGFja2V0IHNob3VsZCBiZSBjaG9z ZW4gYXMgbG93IGFzPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHBvc3NpYmxlIChpZiB0aGUgQ29BUC9JUCBzdGFjayBhbGxv d3Mgc2V0dGluZyBvZiB0aGlzIHZhbHVlLiZuYnNwOyBUQkQ8L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLSBkaXNjdXNzIHdo ZXRoZXIgdGhpcyBndWlkZWxpbmUgaXMgcmVsZXZhbnQvcmVhbGlzdGljIGluIENvQVA8L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgY29udGV4dCk8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDs8L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij4zLjcuJm5ic3A7IENvQVAgTXVsdGljYXN0IGFuZCBIVFRQIFVu aWNhc3QgSW50ZXJ3b3JraW5nPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+L2NvbW1lbnQgYSByZWZlcmVuY2Ugd2lsbCBzdWZm aWNlPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IENvQVAgc3VwcG9ydHMgb3BlcmF0aW9uIG92 ZXIgVURQIG11bHRpY2FzdCwgd2hpbGUgSFRUUCBkb2VzIG5vdC4mbmJzcDsNCjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPkZvcjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNw OyZuYnNwOyZuYnNwOyB1c2UgY2FzZXMgd2hlcmUgaXQgaXMgcmVxdWlyZWQgdGhhdCBDb0FQIGdy b3VwIGNvbW11bmljYXRpb24gaXM8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsm bmJzcDsmbmJzcDsgaW5pdGlhdGVkIGZyb20gYW4gSFRUUCBlbmQtcG9pbnQsIGl0IHdvdWxkIGJl IGFkdmFudGFnZW91cyBpZiB0aGU8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsm bmJzcDsmbmJzcDsgSFRUUC1Db0FQIFByb3h5IHN1cHBvcnRzIG1hcHBpbmcgb2YgSFRUUCB1bmlj YXN0IHRvIENvQVAgZ3JvdXA8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJz cDsmbmJzcDsgY29tbXVuaWNhdGlvbiBiYXNlZCBvbiBJUCBtdWx0aWNhc3QuPC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+L3JlbW92ZSBPbmUgcG9zc2libGUgd2F5IG9mIG9wZXJhdGlvbjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPi9yZW1vdmUmbmJzcDsmbmJzcDsmbmJzcDsgb2Yg c3VjaCBIVFRQLUNvQVAgUHJveHkgaXMgaWxsdXN0cmF0ZWQgaW4gRmlndXJlIDEuPC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IE5vdGUgdGhhdCB0aGlzPC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IHRvcGljIGlzIGNv dmVyZWQgaW4gbW9yZSBkZXRhaWwgaW48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJz cDsmbmJzcDsmbmJzcDsgW0ktRC5jYXN0ZWxsYW5pLWNvcmUtYWR2YW5jZWQtaHR0cC1tYXBwaW5n XS48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDs8L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij4vcmVtb3ZlPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IENvQVAmbmJzcDsmbmJzcDsmbmJzcDsgTWNhc3QmbmJzcDsmbmJzcDsm bmJzcDsgQ29BUCZuYnNwOyZuYnNwOyZuYnNwOyBNY2FzdCZuYnNwOyZuYnNwOyBIVFRQLUNvQVAm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgSFRUUDwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBOb2RlIDEmbmJzcDsmbmJz cDsgUnRyMSZuYnNwOyZuYnNwOyZuYnNwOyBOb2RlIDImbmJzcDsmbmJzcDsmbmJzcDsgUnRyMiZu YnNwOyZuYnNwOyZuYnNwOyBQcm94eSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBOb2RlIDM8L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHw8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgfE1MRCBSRVFVRVNUJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IHw8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgfChKb2luIEdyb3VwIFgpJm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHw8L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfC0tTEwtLSZndDt8Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHw8 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IHxNTEQgUkVRVUVTVCZuYnNwOyZuYnNwOyZuYnNwOyB8ICZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO3w8L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IHwoSm9pbiBHcm91cCBYKSB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHw8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwtLUxMLS0mZ3Q7fCZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHw8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyB8Jm5ic3A7IEhUVFAgUkVRVUVTVCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyB8PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyAmbmJzcDsmbmJzcDt8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZu YnNwOyAoVVJJIHRvJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHw8 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg fCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7IHVuaWNh c3QgYWRkcikmbmJzcDsmbmJzcDsgfDwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IHwmbHQ7IC0tLS0tLS0tLS0tLS0tLS0tfDwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgfDwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDt8Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyBSZXNvbHZlIEhUVFAgUmVx dWVzdC1MaW5lIFVSSSZuYnNwOyZuYnNwOyB8PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5i c3A7IHRvIEdyb3VwIFggbXVsdGljYXN0IGFkZHJlc3MmbmJzcDsmbmJzcDsmbmJzcDsgfDwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfDwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyB8IENvQVAgUkVRVUVTVCAodG8gbXVsdGljYXN0IGFkZHIpfCZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDt8PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbHQ7IC0tLS0tLSZsdDst LS0tLS0tLS0mbHQ7LS0tLS0tLSZsdDstLS0tLS18Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHw8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IHw8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgfDwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IChvcHRpb25hbCkgQ29BUCBSRVNQT05TRShzKSB8Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHw8L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyB8LS0tLS0tLS0tLS0tLS0mZ3Q7fCZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwtLS0tLS0tLS0tLS0tLS0tLXwtLS0tLS0tLS0tLS0tLSZn dDt8Jm5ic3A7Jm5ic3A7IEFnZ3JlZ2F0ZWQmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg fDwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgfCZuYnNwOyBIVFRQIFJFU1BPTlNFJm5ic3A7Jm5ic3A7Jm5ic3A7IHw8L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyAmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDt8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwtLS0tLS0tLS0t LS0tLS0tLS0mZ3Q7fDwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyB8PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ Jm5ic3A7PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+UmFobWFuICZhbXA7IERpamsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgRXhwaXJlcyBBcHJpbCAy MiwgMjAxMyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBbUGFnZQ0KPC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+MTBdPC9wPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7IGZvbnQtZmFtaWx5OkNvbnNvbGFzIj48YnIgY2xlYXI9ImFsbCIgc3R5bGU9InBhZ2UtYnJl YWstYmVmb3JlOmFsd2F5cyI+DQo8L3NwYW4+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJz cDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5JbnRlcm5ldC1EcmFmdCZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBHcm91cCBDb21tdW5pY2F0aW9uIGZvciBD b0FQJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IE9jdG9iZXINCjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjIwMTI8L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJz cDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgRmlndXJlIDE6IENvQVAgTXVsdGlj YXN0IGFuZCBIVFRQIFVuaWNhc3QgSW50ZXJ3b3JraW5nPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+Jm5ic3A7PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5i c3A7IE5vdGUgdGhhdCBGaWd1cmUgMSBpbGx1c3RyYXRlcyB0aGUgY2FzZSBvZiBJUCBtdWx0aWNh c3QgYXMgdGhlPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 IHVuZGVybHlpbmcgZ3JvdXAgY29tbXVuaWNhdGlvbnMgbWVjaGFuaXNtLiZuYnNwOyBNTEQgZGVu b3RlcyB0aGUNCjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPk11bHRpY2FzdDwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyBMaXN0ZW5lciBEaXNjb3Zl cnkgcHJvdG9jb2wgKFtSRkMzODEwXSwgQXBwZW5kaXggQSkgYW5kIExMIGRlbm90ZXMgYTwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyBMaW5rLUxvY2FsIG11 bHRpY2FzdC48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDs8L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsgQSBrZXkgcG9pbnQgaW4gRmlndXJl IDEgaXMgdGhhdCB0aGUgaW5jb21pbmcgSFRUUCBSZXF1ZXN0IChmcm9tIG5vZGU8L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsgMykgd2lsbCBjYXJyeSBhIEhv c3QgcmVxdWVzdC1oZWFkZXIgZmllbGQgdGhhdCByZXNvbHZlcyBpbiB0aGU8L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsgZ2VuZXJhbCBJbnRlcm5ldCB0byB0 aGUgcHJveHkgbm9kZS4mbmJzcDsgQXQgdGhlIHByb3h5IG5vZGUsIHRoaXMNCjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPmhvc3RuYW1lPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7IGFuZC9vciB0aGUgUmVxdWVzdC1MaW5lIFVSSSB3aWxsIHRoZW4g cG9zc2libHkgYmUgbWFwcGVkIChhcw0KPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ZGV0 YWlsZWQ8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsgaW4g W0ktRC5jYXN0ZWxsYW5pLWNvcmUtaHR0cC1tYXBwaW5nXSkgYW5kIGFnYWluIHJlc29sdmVkICh3 aXRoIHRoZTwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyBD b0FQIHNjaGVtZSkgdG8gYW4gSVAgbXVsdGljYXN0IGFkZHJlc3MuJm5ic3A7IFRoaXMgbWF5IGJl IGFjY29tcGxpc2hlZCw8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsm bmJzcDsgZm9yIGV4YW1wbGUsIGJ5IHVzaW5nIEROUyBvciBETlMtU0QgKFNlY3Rpb24gMy4zKS4m bmJzcDsgVGhlIHByb3h5IG5vZGU8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsm bmJzcDsmbmJzcDsgd2lsbCB0aGVuIElQIG11bHRpY2FzdCB0aGUgQ29BUCBSZXF1ZXN0IChjb3Jy ZXNwb25kaW5nIHRvIHRoZTwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNw OyZuYnNwOyByZWNlaXZlZCBIVFRQIFJlcXVlc3QpIHZpYSBtdWx0aWNhc3Qgcm91dGVycyB0byB0 aGUgYXBwcm9wcmlhdGUNCjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPm5vZGVzPC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IChpLmUuIG5vZGVzIDEg YW5kIDIpLjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOzwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyBJbiB0ZXJtcyBvZiB0aGUgSFRUUCBS ZXNwb25zZSwgRmlndXJlIDEgaWxsdXN0cmF0ZXMgdGhhdCBpdCB3aWxsIGJlPC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IGdlbmVyYXRlZCBieSB0aGUgcHJv eHkgbm9kZSBiYXNlZCBvbiBhZ2dyZWdhdGVkIHJlc3BvbnNlcyBvZiB0aGUNCjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPkNvQVA8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJz cDsmbmJzcDsmbmJzcDsgbm9kZXMgYW5kIHNlbnQgYmFjayB0byB0aGUgY2xpZW50IGluIHRoZSBn ZW5lcmFsIEludGVybmV0IHRoYXQgc2VudDwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZu YnNwOyZuYnNwOyZuYnNwOyB0aGUgSFRUUCBSZXF1ZXN0IChpLmUuIG5vZGUgMSkuJm5ic3A7IElu PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IFtJLUQuY2Fz dGVsbGFuaS1jb3JlLWFkdmFuY2VkLWh0dHAtbWFwcGluZ10gdGhlIEhUVFAgUmVzcG9uc2UgdGhh dDwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyB0aGUgUHJv eHkgbWF5IHVzZSB0byBhZ2dyZWdhdGUgbXVsdGlwbGUgQ29BUCByZXNwb25zZXMgaXMgZGVzY3Jp YmVkPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IGluIG1v cmUgZGV0YWlsLiZuYnNwOyBTbyBpbiB0ZXJtcyBvZiBvdmVyYWxsIG9wZXJhdGlvbiwgdGhlIENv QVAgcHJveHkNCjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPmNhbjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyBiZSBjb25zaWRlcmVkIHRvIGJlIGEg JnF1b3Q7bm9uLXRyYW5zcGFyZW50JnF1b3Q7IHByb3h5IGFjY29yZGluZyB0bw0KPC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+W1JGQzI2MTZdLjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPiZuYnNwOyZuYnNwOyZuYnNwOyBTcGVjaWZpY2FsbHksIFtSRkMyNjE2XSBzdGF0ZXMgdGhh dCBhICZxdW90O25vbi10cmFuc3BhcmVudCBwcm94eSBpcyBhPC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IHByb3h5IHRoYXQgbW9kaWZpZXMgdGhlIHJlcXVl c3Qgb3IgcmVzcG9uc2UgaW4gb3JkZXIgdG8gcHJvdmlkZSBzb21lPC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IGFkZGVkIHNlcnZpY2UgdG8gdGhlIHVzZXIg YWdlbnQsIHN1Y2ggYXMgZ3JvdXAgYW5ub3RhdGlvbiBzZXJ2aWNlcyw8L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsgbWVkaWEgdHlwZSB0cmFuc2Zvcm1hdGlv biwgcHJvdG9jb2wgcmVkdWN0aW9uIG9yIGFub255bWl0eTwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyBmaWx0ZXJpbmcuJnF1b3Q7PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+Jm5ic3A7PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7IEFuIGFsdGVybmF0aXZlIHRvIHRoZSBhYm92ZSBpcyB1c2luZyBhIEZvcndh cmQgUHJveHkuJm5ic3A7IEluIHRoaXMgY2FzZSw8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij4mbmJzcDsmbmJzcDsmbmJzcDsgdGhlIENvQVAgcmVxdWVzdCBVUkkgaXMgY2FycmllZCBpbiB0 aGUgSFRUUCBSZXF1ZXN0LUxpbmUgKGFzIGRlZmluZWQ8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsgaW4gW0ktRC5pZXRmLWNvcmUtY29hcF0gU2VjdGlvbiAx MC4yKSBpbiBhIEhUVFAgcmVxdWVzdCBzZW50IHRvIHRoZTwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyBJUCBhZGRyZXNzIG9mIHRoZSBQcm94eS48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij4vZW5kIHJlbW92ZTwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOzwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PjQuJm5ic3A7IFVzZSBDYXNlcyBhbmQgQ29ycmVzcG9uZGluZyBQcm90b2NvbCBGbG93czwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPjQuMS4mbmJzcDsgSW50cm9kdWN0aW9uPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ Jm5ic3A7PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRo ZSB1c2Ugb2YgQ29BUCBncm91cCBjb21tdW5pY2F0aW9uIGlzIHNob3duIGluIHRoZSBjb250ZXh0 IG9mIHRoZTwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyBm b2xsb3dpbmcgdXNlIGNhc2VzIGFuZCBjb3JyZXNwb25kaW5nIHByb3RvY29sIGZsb3dzOjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPiZuYnNwOyZuYnNwOyZuYnNwOyBvJm5ic3A7IERpc2NvdmVyeSBvZiBSZXNvdXJjZSBEaXJl Y3Rvcnk6IGRpc2NvdmVyaW5nIHRoZSBsb2NhbCBDb1JFIFJEPC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHdoaWNoIGNvbnRh aW5zIGxpbmtzIChVUklzKSB0byByZXNvdXJjZXMgc3RvcmVkIG9uIG90aGVyIHNlcnZlcnM8L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgW1JGQzY2OTBdLjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOzwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPiZuYnNwOzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPlJhaG1hbiAmYW1wOyBEaWpr Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IEV4cGlyZXMgQXByaWwgMjIsIDIwMTMmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgW1BhZ2UNCjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjExXTwvcD4NCjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0OyBmb250LWZhbWlseTpDb25zb2xhcyI+PGJyIGNs ZWFyPSJhbGwiIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPg0KPC9zcGFuPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ SW50ZXJuZXQtRHJhZnQmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg R3JvdXAgQ29tbXVuaWNhdGlvbiBmb3IgQ29BUCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBPY3RvYmVyDQo8L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij4yMDEyPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7IG8mbmJzcDsgTGlnaHRpbmcgQ29udHJvbDogc3luY2hyb25vdXMg b3BlcmF0aW9uIG9mIGEgZ3JvdXAgb2YgNkxvV1BBTjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBbUkZDNDk0NF0gSVB2Ni1j b25uZWN0ZWQgbGlnaHRzPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IG8mbmJzcDsgUGFyYW1l dGVyIFVwZGF0ZTogdXBkYXRpbmcgcGFyYW1ldGVycy9zZXR0aW5ncyBzaW11bHRhbmVvdXNseSBp bg0KPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+YTwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBsYXJnZSBncm91cCBv ZiBkZXZpY2VzIGluIGEgYnVpbGRpbmcvY2FtcHVzIGNvbnRyb2w8L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgKFtJLUQudmFu ZGVyc3Rvay1jb3JlLWJjXSkgYXBwbGljYXRpb24gLS0tIFRCRDwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPiZuYnNwOzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPi8gY29tbWVudCBJ IHN1Z2dlc3QgdG8gcmVtb3ZlIEZpcm13YXJlIFVwZGF0ZSBhbmQgR3JvdXBzIHN0YXR1cyByZXBv cnQ8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4vY29tbWVudCB0aGUgb25lcyBhYm92ZSBh cmUgZGlmZmljdWx0IGVub3VnaCwgYW5kIEkgZG91YnQgdGhhdA0KPC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+c2ltdWx0YW5laXR5PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+L2Nv bW1lbnQgKG1vdGl2YXRpb24gb2YgbXVsdGljYXN0KSBpcyBpbnZvbHZlZCBoZXJlPC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ Jm5ic3A7PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IG8m bmJzcDsgRmlybXdhcmUgVXBkYXRlOiBlZmZpY2llbnRseSB1cGRhdGluZyBmaXJtd2FyZSBzaW11 bHRhbmVvdXNseSBpbg0KPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+YTwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBs YXJnZSBncm91cCBvZiBkZXZpY2VzIGluIGEgYnVpbGRpbmcvY2FtcHVzIGNvbnRyb2w8L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgKFtJLUQudmFuZGVyc3Rvay1jb3JlLWJjXSkgYXBwbGljYXRpb24gLS0tIFRCRCBzdWdnZXN0 cyBhPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IG11bHRpY2FzdCBleHRlbnNpb24gb2YgY29yZS1ibG9jay48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4m bmJzcDsmbmJzcDsmbmJzcDsgbyZuYnNwOyBHcm91cCBTdGF0dXMgUmVwb3J0OiByZXF1ZXN0aW5n IHN0YXR1cyBpbmZvcm1hdGlvbiBvciBldmVudDwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyByZXBvcnRzIGZyb20gYSBncm91 cCBvZiBkZXZpY2VzIGluIGEgYnVpbGRpbmcvY2FtcHVzIGNvbnRyb2w8L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYXBwbGlj YXRpb24gLS0tIFRCRCwgbWF5IHJlcXVpcmUgcmVsaWFibGUgZ3JvdXAgY29tbXVuaWNhdGlvbiB0 bzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyBiZSBmZWFzaWJsZS48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJz cDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij40LjIuJm5ic3A7IE5ldHdvcmsgQ29uZmln dXJhdGlvbjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOzwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyBXZSBhc3N1bWUgdGhlIGZvbGxvd2lu ZyBuZXR3b3JrIGNvbmZpZ3VyYXRpb24gZm9yIGFsbCB0aGUgdXNlIGNhc2VzPC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IGFzIHNob3duIGluIEZpZ3VyZSAy OjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPi9jb21tZW50IHRoZSBjb25maWd1cmF0aW9u cyBmcmlnaHRlbiBtZTwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPi9jb21tZW50IGZyb20g Y29tcGxldGVuZXNzIGNvbnNpZGVyYXRpb25zIEkgY2FuIGltYWdpbmUgZXZlbiBtb3JlDQo8L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5jb21wbGV4IG9uZXM8L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij4vY29tbWVudCBJdCBtaWdodCBiZSB1c2VmdWwgaWYgdGhlIHByYWN0aWNhbCBp bXBvc3NpYmlsaXR5IG9mIHNvbWUNCjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPmNvbmZp Z3VyYXRpb25zIGlzIGhpZ2ggbGlnaHRlZDwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZu YnNwOzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOzwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyBvJm5ic3A7IEEgbGFyZ2Ugcm9vbSAoUm9v bS1BKSB3aXRoIHRocmVlIGxpZ2h0cyAoTGlnaHQtMSwgTGlnaHQtMiw8L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgTGlnaHQt MykgY29udHJvbGxlZCBieSBhIExpZ2h0IFN3aXRjaC4mbmJzcDsgVGhlIGRldmljZXMgYXJlIG9y Z2FuaXplZDwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyBpbnRvIHR3byA2TG9XUEFOIHN1Ym5ldHMuPC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+L2NvbW1lbnQgb25lIHN1Ym5ldCBpcyBlbm91Z2ggZm9yIG1lPC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+L3JlbW92ZTwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOzwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyBvJm5ic3A7IExpZ2h0LTEgYW5k IHRoZSBMaWdodCBTd2l0Y2ggYXJlIGNvbm5lY3RlZCB0byBhIHJvdXRlciAoUnRyLTEpPC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IHdoaWNoIGlzIGFsc28gYSBDb0FQIFByb3h5LCBhIENvQVAgUmVzb3VyY2UgRGlyZWN0b3J5 IChSRCkgYW5kIGE8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgNkxvV1BBTiBCb3JkZXIgUm91dGVyICg2TEJSKS48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij4mbmJzcDsmbmJzcDsmbmJzcDsgbyZuYnNwOyBMaWdodC0yIGFuZCB0aGUgTGlnaHQtMyBhcmUg Y29ubmVjdGVkIHRvIGFub3RoZXIgcm91dGVyIChSdHItMik8L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7d2hpY2ggaXMgYWxz byBhIENvQVAgUHJveHksIGEgQ29BUCBSRCBhbmQgYSA2TEJSLjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPiZuYnNwOzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNw OyZuYnNwOyBvJm5ic3A7IFRoZSByb3V0ZXJzIGFyZSBjb25uZWN0ZWQgdG8gYW4gSVB2NiBuZXR3 b3JrIGJhY2tib25lIHdoaWNoIGlzPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGFsc28gbXVsdGljYXN0IGVuYWJsZWQuJm5i c3A7IEluIHRoZSBnZW5lcmFsIGNhc2UsIHRoaXMgbWVhbnMgdGhlPC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IG5ldHdvcmsg YmFja2JvbmUgYW5kIDZMQlJzIHN1cHBvcnQgYSBQSU0gYmFzZWQgbXVsdGljYXN0IHJvdXRpbmc8 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgcHJvdG9jb2wsIGFuZCBNTEQgZm9yIGZvcm1pbmcgZ3JvdXBzLiZuYnNwOyBJbiBh IGxpbWl0ZWQgY2FzZSwgaWYgdGhlPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IG5ldHdvcmsgYmFja2JvbmUgaXMgb25lIGxp bmssIHRoZW4gdGhlIHJvdXRlcnMgb25seSBoYXZlIHRvPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHN1cHBvcnQgTUxELXNu b29waW5nIChBcHBlbmRpeCBBKSBmb3IgdGhlIGZvbGxvd2luZyB1c2UgY2FzZXMgdG88L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgd29yay48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDs8L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4vZW5k IHJlbW92ZTwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOzwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPi9jb21tZW50IEkgY2FuIGltYWdpbmUgdGhhdCBhbiBjZW50cmFsIGNv bnRyb2wgaXMgcHJlc2VudCBvbiB0aGUNCjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPmJh Y2tib25lPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+L2NvbW1lbnQgc3dpdGNoIG9yIHNl bnNvciBzZW5kIHVuaWNhc3QgdG8gY2VudHJhbCBjb250cm9sPC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+L2NvbW1lbnQgY2VudHJhbCBjb250cm9sIHNlbmRzIG11bHRpY2FzdCB0byBtdWx0 aWNhc3QgZ3JvdXAgd2l0aGluDQo8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5zaW5nbGUg bG93cGFuPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+Jm5ic3A7PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7 PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+Jm5ic3A7PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+Jm5ic3A7PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+UmFobWFuICZhbXA7IERpamsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgRXhwaXJlcyBBcHJpbCAyMiwgMjAxMyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyBbUGFnZQ0KPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+MTJdPC9wPg0KPHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7IGZvbnQtZmFtaWx5OkNvbnNvbGFzIj48YnIgY2xl YXI9ImFsbCIgc3R5bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+DQo8L3NwYW4+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5J bnRlcm5ldC1EcmFmdCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBH cm91cCBDb21tdW5pY2F0aW9uIGZvciBDb0FQJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IE9jdG9iZXINCjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPjIwMTI8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDs8L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPk5ldHdvcms8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+QmFja2JvbmU8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi Pnw8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij58PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICMmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgUm9vbS1BICMmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+fDwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyAjJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICoq KioqKioqKioqKioqKioqKioqKiombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgIyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+fDwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyAjJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICoq Jm5ic3A7IExvV1BBTi0xIChzdWJuZXQtMSkgKiombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgIyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+fDwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyAjJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICombmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgKiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAjJm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij58PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7ICMmbmJzcDsmbmJzcDsmbmJzcDsgKiZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmIzQz Oy0tLS0tLS0tLS0mIzQzOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAqJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICMmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsNCjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPnw8L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg IyZuYnNwOyZuYnNwOyAqJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsgTGln aHQmbmJzcDsmbmJzcDsgfC0tLS0tLS0mIzQzOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyAqJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICMmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPnw8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgIyZuYnNwOyAqJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IHwmbmJzcDsgU3dpdGNoJm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAqJm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICMmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPnw8L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgIyZuYnNwOyAqJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYjNDM7 LS0tLS0tLS0tLSYjNDM7Jm5ic3A7ICYjNDM7LS0tLS0tLS0tJiM0MzsmbmJzcDsgKiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAjJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij58PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7ICMmbmJzcDsgKiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7IFJ0ci0xJm5ic3A7IDwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPnwtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLXw8L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgIyZu YnNwOyAqJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7ICYjNDM7LS0tLS0tLS0tJiM0MzsmbmJzcDsgKiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAjJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7DQo8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij58PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICMmbmJz cDsgKiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmIzQzOy0tLS0tLS0tLS0m IzQzOyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDt8Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgIyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+fDwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAjJm5ic3A7Jm5ic3A7ICombmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyBMaWdodC0xIHwtLS0tLS0tLSYjNDM7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgIyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0K PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+fDwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAjJm5ic3A7Jm5ic3A7Jm5i c3A7ICombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJiM0MzstLS0tLS0tLS0tJiM0MzsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgKiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyAjJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij58PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICMmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgKiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAqJm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 ICMmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+fDwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAjJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7ICoqJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICoqJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICMmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPnw8 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgIyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyAqKioqKioqKioqKioqKioqKioqKioqJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICMmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPnw8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgIyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyAjJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij58PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICMmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOw0KPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+fDwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAjJm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICoqKioqKioqKioqKioqKioqKioqKiom bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgIyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOw0KPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+fDwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyAjJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICoqJm5ic3A7IExvV1BBTi0y IChzdWJuZXQtMikgKiombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgIyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOw0KPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+fDwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAj Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgKiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAjJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7DQo8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij58PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICMmbmJzcDsm bmJzcDsmbmJzcDsgKiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmIzQzOy0tLS0tLS0tLS0mIzQz OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyAqJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7ICMmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsN CjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPnw8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgIyZuYnNwOyZuYnNwOyAq Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsgTGlnaHQtMiB8LS0tLS0tLSYj NDM7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICombmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgIyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOw0KPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+fDwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAjJm5i c3A7ICombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8ICZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwO3wmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgKiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAjJm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij58PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7ICMmbmJzcDsgKiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyAmIzQzOy0tLS0tLS0tLS0mIzQzOyZuYnNwOyAmIzQzOy0tLS0tLS0tLSYjNDM7Jm5ic3A7 ICombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgIyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+fDwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyAjJm5ic3A7ICombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyBSdHItMiZuYnNwOyA8L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij58LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS18PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7ICMmbmJzcDsgKiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmIzQzOy0tLS0tLS0tLSYjNDM7Jm5ic3A7ICombmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgIyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij58PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7ICMmbmJzcDsgKiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmIzQzOy0t LS0tLS0tLS0mIzQzOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgIyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw Ow0KPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+fDwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAjJm5ic3A7Jm5ic3A7 ICombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyBMaWdodC0zIHwtLS0tLS0t LSYjNDM7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgIyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOw0KPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+fDwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAjJm5ic3A7 Jm5ic3A7Jm5ic3A7ICombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJiM0MzstLS0tLS0tLS0tJiM0 MzsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgKiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyAjJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 DQo8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij58PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICMmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgKiZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsqJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7ICMmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPnw8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgIyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyAqKiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAqKiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAjJm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij58PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7ICMmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgKioqKioqKioqKioqKioqKioqKioqKiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyAjJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij58PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICMmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw Ow0KPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+fDwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7DQo8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij58PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij58PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYjNDM7LS0tLS0tLS0mIzQzOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+fDwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyB8Jm5ic3A7IEROUyZuYnNwOyZuYnNwOyA8L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij58LS0tLS0tLS0tLS0tLS0tLS0tfDwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8IFNlcnZlciB8PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYjNDM7LS0tLS0t LS0mIzQzOzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOzwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPiZuYnNwOzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyBGaWd1cmUgMjogTmV0d29yayBUb3BvbG9neSBvZiBhIExhcmdlIFJvb20gKFJv b20tQSk8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDs8L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij4mbmJzcDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDs8 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij5SYWhtYW4gJmFtcDsgRGlqayZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBFeHBpcmVzIEFwcmlsIDIyLCAyMDEz Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFtQYWdlDQo8L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij4xM108L3A+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDsgZm9u dC1mYW1pbHk6Q29uc29sYXMiPjxiciBjbGVhcj0iYWxsIiBzdHlsZT0icGFnZS1icmVhay1iZWZv cmU6YWx3YXlzIj4NCjwvc3Bhbj4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOzwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkludGVybmV0LURyYWZ0Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEdyb3VwIENvbW11bmljYXRpb24gZm9yIENvQVAmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgT2N0b2Jl cg0KPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+MjAxMjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPiZuYnNwOzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOzwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjQuMy4mbmJzcDsgRGlzY292ZXJ5IG9mIFJlc291cmNl IERpcmVjdG9yeTwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOzwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyBUaGUgcHJvdG9jb2wgZmxvdyBm b3IgZGlzY292ZXJ5IG9mIGEgUkQgZm9yIHRoZSBnaXZlbiBuZXR3b3JrIChvZjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyBGaWd1cmUgMikgaXMgc2hvd24g aW4gRmlndXJlIDM6PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IG8mbmJzcDsgVGhlIGZpeHR1 cmUgZm9yIExpZ2h0LTIgaXMgaW5zdGFsbGVkIGFuZCBwb3dlcmVkIG9uIGZvciB0aGUgZmlyc3Q8 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgdGltZS48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDs8L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsgbyZuYnNwOyBMaWdodC0y IHdpbGwgdGhlbiBzZWFyY2ggZm9yIHRoZSBsb2NhbCBSRCAoUkQtMikgYnkgc2VuZGluZyBvdXQg YTwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyBHRVQgcmVxdWVzdCAod2l0aCB0aGUgJnF1b3Q7Ly53ZWxsLWtub3duL2NvcmU/ cnQ9Y29yZS5yZCZxdW90OyByZXF1ZXN0IFVSSSk8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdG8gdGhlIHNpdGUtbG9jYWwg JnF1b3Q7QWxsIENvQVAgTm9kZXMmcXVvdDsgYWRkcmVzcy4mbmJzcDsgSW4gdGhpcyBjYXNlLCB0 aGU8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgc2l0ZSBpcyBhc3N1bWVkIHRvIGluY2x1ZGUgYWxsIG5vZGVzIGluIHRoZSBz dWJuZXQuPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IG8mbmJzcDsgVGhpcyBtdWx0aWNhc3Qg bWVzc2FnZSB3aWxsIHRoZW4gZ28gdG8gZWFjaCBub2RlIGluIHN1Ym5ldC0yLjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBI b3dldmVyLCBvbmx5IFJ0ci0yIChSRC0yKSB3aWxsIHJlc3BvbmQgYmVjYXVzZSB0aGUgR0VUIGlz PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IHF1YWxpZmllZCBieSB0aGUgcXVlcnkgc3RyaW5nICZxdW90Oz9ydD1jb3JlLnJk JnF1b3Q7LjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOzwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyBvJm5ic3A7IE5vdGUgdGhhdCB0aGUg ZmxvdyBpcyBzaG93biBvbmx5IGZvciBMaWdodC0yIGZvciBjbGFyaXR5LiZuYnNwOw0KPC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+U2ltaWxhcjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBmbG93cyB3aWxsIGhhcHBl biBmb3IgTGlnaHQtMSwgTGlnaHQtMyBhbmQgdGhlIExpZ2h0IFN3aXRjaCB3aGVuPC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IHRoZXkgYXJlIGZpcnN0IHBvd2VyZWQgb24uPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ Jm5ic3A7PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRo ZSBSRCBtYXkgYWxzbyBiZSBkaXNjb3ZlcmVkIGJ5IG90aGVyIG1lYW5zIHN1Y2ggYXMgYnkgYXNz dW1pbmcgYTwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyBk ZWZhdWx0IGxvY2F0aW9uIChlLmcuIG9uIGEgNkxCUiksIHVzaW5nIERIQ1AsIGFueWNhc3QgYWRk cmVzcywgZXRjLjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNw OyBIb3dldmVyLCB0aGVzZSBhcHByb2FjaGVzIGRvIG5vdCBpbnZva2UgQ29BUCBncm91cCBjb21t dW5pY2F0aW9uIHNvPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5i c3A7IGFyZSBub3QgZnVydGhlciBkaXNjdXNzZWQgaGVyZS48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij4mbmJzcDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsm bmJzcDsgRm9yIG90aGVyIGRpc2NvdmVyeSB1c2UgY2FzZXMgc3VjaCBhcyBkaXNjb3ZlcmluZyBs b2NhbCBDb0FQDQo8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5zZXJ2ZXJzLDwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyBzZXJ2aWNlcyBvciByZXNv dXJjZXMgZ3JvdXAgY29tbXVuaWNhdGlvbiBjYW4gYmUgdXNlZCBpbiBhIHNpbWlsYXI8L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsgZmFzaGlvbiBhcyBpbiB0 aGUgYWJvdmUgdXNlIGNhc2UuJm5ic3A7IEJvdGggTGluay1Mb2NhbCAoTEwpIGFuZCBzaXRlLTwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyBsb2NhbCBkaXNj b3ZlcnkgYXJlIHBvc3NpYmxlIHRoaXMgd2F5LjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PiZuYnNwOzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPi9jb21tZW50IHRoZSBSRCBkaXNj b3Zlcnkgd2lsbCBiZSBtb3JlIGNvbXBsZXggd2hlbiB0aGVyZSBpcyBhIHJvdXRlcg0KPC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+YmV0d2VlbiBsaWdodC0yIGFuZCBzd2l0Y2g8L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4vY29tbWVudCBWaWEgd2hpY2ggUkQgd2lsbCBsaWdodCBz d2l0Y2ggZGlzY292ZXIgbGlnaHQtMj88L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4vY29t bWVudCBhZGRpdGlvbmFsIHJlYXNvbiB0byByZW1vdmUgcm91dGVyIGZyb20gdGhlIG11bHRpY2Fz dA0KPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Y29uZmlndXJhdGlvbjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPiZuYnNwOzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZu YnNwOzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOzwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPiZuYnNwOzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOzwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOzwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPiZuYnNwOzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOzwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PiZuYnNwOzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOzwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPiZuYnNwOzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNw OzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOzwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPiZuYnNwOzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOzwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPiZuYnNwOzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOzwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPiZuYnNwOzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZu YnNwOzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPlJhaG1hbiAmYW1wOyBEaWprJm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IEV4cGlyZXMgQXByaWwgMjIsIDIwMTMmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgW1BhZ2UNCjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjE0XTwvcD4NCjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0OyBmb250LWZhbWlseTpDb25zb2xhcyI+PGJyIGNsZWFyPSJh bGwiIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPg0KPC9zcGFuPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+Jm5ic3A7PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+SW50ZXJu ZXQtRHJhZnQmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgR3JvdXAg Q29tbXVuaWNhdGlvbiBmb3IgQ29BUCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyBPY3RvYmVyDQo8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij4yMDEyPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+Jm5ic3A7PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IExpZ2h0Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IFJ0ci0xJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFJ0ci0yJm5i c3A7Jm5ic3A7DQo8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5OZXR3b3JrPC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IExpZ2h0LTEmbmJzcDsmbmJz cDsgTGlnaHQtMiZuYnNwOyZuYnNwOyZuYnNwOyBMaWdodC0zJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IFN3aXRjaCZuYnNwOyZuYnNwOyZuYnNwOyAoUkQtMSkmbmJzcDsmbmJzcDsmbmJzcDsgKFJE LTIpJm5ic3A7DQo8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5CYWNrYm9uZTwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO3wmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHw8L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgfDwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyAqJm5ic3A7Jm5ic3A7IExpZ2h0LTIgaXMgaW5zdGFsbGVkJm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHw8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgKiZuYnNwOyZuYnNwOyBhbmQgcG93ZXJzIG9uIGZv ciBmaXJzdCB0aW1lICombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7ICZuYnNwO3w8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfDwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHw8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8IENPQVAgTk9OIChHRVQmbmJzcDsmbmJzcDsgJm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7fCZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAvLndlbGwta25vd24vY29yZT9y dD1jb3JlLnJkKSZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHw8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyB8LS0tLS0tLS0tJmd0Oy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tJmd0O3wmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgfDwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyB8PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg fCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHw8 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfDwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwgQ09BUCBOT04g KDIuMDUgQ29udGVudCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IHw8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7ICZsdDsvcmQmZ3Q7O3J0PSZxdW90O2NvcmUucmQmcXVvdDs7aW5zPSZxdW90O1ByaW1hcnkm cXVvdDspIHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgfDwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IHwmbHQ7LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tfCZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHw8L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJz cDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDs8L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgRmln dXJlIDM6IFJlc291cmNlIERpcmVjdG9yeSBEaXNjb3ZlcnkgdmlhIE11bHRpY2FzdCBNZXNzYWdl PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+NC40LiZuYnNwOyBMaWdodGluZyBDb250cm9sPC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+Jm5ic3A7PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+L2NvbW1lbnQgSSBh bSBjb25mdXNlZCBhYm91dCB0aGUgdXNlIG9mIHByb3RvY29sczwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPi9jb21tZW50IE1MRCBpcyB1c2VkIHRvIGZvcm0gZ3JvdXBzLCBjb3JyZWN0Pzwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPi9jb21tZW50IGJ1dCB0aGF0IHdhcyBhbHJlYWR5 IGRvbmUgYnkgZW5hYmxpbmcgdGhlIE1DIGFkZHJlc3MgaW4gdGhlDQo8L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij5saWdodHMgKHBvaW50IDIpPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+L2NvbW1lbnQgVGhlcmUgYXJlIHNldmVyYWwgd2F5cyB0byBzZXQgdXAgZ3JvdXBzLCBwb2lu dGluZyB0aGVtIG91dCBhbmQNCjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPndoZW4gdG8g dXNlIHRoZW0gd291bGQgYmUgYW4gYXNzZXQuPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ Jm5ic3A7PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRo ZSBwcm90b2NvbCBmbG93IGZvciBhIGJ1aWxkaW5nIGF1dG9tYXRpb24gbGlnaHRpbmcgY29udHJv bA0KPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+c2NlbmFyaW88L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsgZm9yIHRoZSBuZXR3b3JrIChGaWd1cmUg MikgaXMgc2hvd24gaW4gc2VxdWVuY2UgaW4gRmlndXJlIDQsPC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IEZpZ3VyZSA1LCBhbmQgRmlndXJlIDYuJm5ic3A7 IFdlIGFzc3VtZSB0aGUgZm9sbG93aW5nIHN0ZXBzIG9jY3VyIGJlZm9yZTwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyB0aGUgaWxsdXN0cmF0ZWQgZmxvdzo8 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsgbyZuYnNwOyAxKSBTdGFydHVwIHBoYXNlOiA2TG9X UEFOcyBhcmUgZm9ybWVkLiZuYnNwOyBJUHY2IGFkZHJlc3NlcyBhc3NpZ25lZA0KPC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+dG88L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYWxsIGRldmljZXMuJm5ic3A7IFRoZSBD b0FQIG5ldHdvcmsgaXMgZm9ybWVkLjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNw OzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyBvJm5ic3A7 IDIpIENvbW1pc3Npb25pbmcgcGhhc2UgKGJ5IGFwcGxpY2F0aW9ucyk6IFRoZSBJUCBtdWx0aWNh c3QNCjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPmFkZHJlc3M8L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgb2YgdGhl IGdyb3VwIChSb29tLUEtTGlnaHRzKSBoYXMgYmVlbjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPi9zIHNldCAvcyBlbmFibGU8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgaW4gYWxsIHRoZSBMaWdodHMuJm5ic3A7IFRo ZTwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyBVUkkgb2YgdGhlIGdyb3VwIChSb29tLUEtTGlnaHRzKSBoYXMgYmVlbjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPi9zIHNldCAvcyByZXNvbHZlZDwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBpbiB0 aGUgTGlnaHQgU3dpdGNoLjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOzwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyBvJm5ic3A7IDMpIFRo ZSBpbmRpY2F0ZWQgTUxEIFJlcG9ydCBtZXNzYWdlcyBhcmUgbGluay1sb2NhbCBtdWx0aWNhc3Qu Jm5ic3A7DQo8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5JbjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBlYWNoIExv V1BBTiwgaXQgaXMgYXNzdW1lZCB0aGF0IGEgbXVsdGljYXN0IHJvdXRpbmcvZm9yd2FyZGluZzwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyBwcm90b2NvbCBpbiA2TFJzIHdpbGwgdGhlbiBwcm9wYWdhdGUgdGhlIEpvaW4gaW5m b3JtYXRpb248L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgY29udGFpbmVkIGluIHRoZSBNTEQgUmVwb3J0IG92ZXIgbXVsdGlw bGUgaG9wcyB0byB0aGUgNkxCUi48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDs8 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4vY29tbWVudCBEb24ndCBzZWUgdGhlIG5lZWQ8 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij4mbmJzcDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDs8L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij4mbmJzcDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDs8L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij5SYWhtYW4gJmFtcDsgRGlqayZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBFeHBpcmVzIEFwcmls IDIyLCAyMDEzJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFtQYWdlDQo8L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4xNV08L3A+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDsgZm9udC1mYW1pbHk6Q29uc29sYXMiPjxiciBjbGVhcj0iYWxsIiBzdHlsZT0icGFnZS1i cmVhay1iZWZvcmU6YWx3YXlzIj4NCjwvc3Bhbj4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZu YnNwOzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkludGVybmV0LURyYWZ0Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEdyb3VwIENvbW11bmljYXRpb24gZm9y IENvQVAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgT2N0b2Jlcg0KPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+MjAxMjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPiZuYnNwOzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZu YnNwOzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBMaWdodCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyBSdHItMSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBSdHItMiZuYnNwOyZuYnNwOw0KPC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+TmV0d29yazwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPiZuYnNwOyZuYnNwOyZuYnNwOyBMaWdodC0xJm5ic3A7Jm5ic3A7IExpZ2h0LTImbmJzcDsm bmJzcDsmbmJzcDsgTGlnaHQtMyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBTd2l0Y2gmbmJzcDsm bmJzcDsmbmJzcDsgKENvQVAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgKENvQVAmbmJzcDsmbmJz cDsNCjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkJhY2tib25lPC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgUHJveHkpJm5ic3A7Jm5ic3A7Jm5ic3A7IFBy b3h5KSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHw8L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7fCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfDwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8IE1MRCBSZXBvcnQ6IEpvaW4mbmJzcDsmbmJzcDsm bmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyB8PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IHwgR3JvdXAgKFJvb20tQS1MaWdodHMpJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IHw8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgfC0tLUxMLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLSZndDt8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7fDwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IHxNTEQgUmVwb3J0OiBKb2luJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHw8L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8R3JvdXAgKFJvb20tQS1MaWdo dHMpfDwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg fCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwt LS1MTC0tLS0tLS0tLS0tLS0tLSZndDt8PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IHw8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyB8IE1MRCBSZXBvcnQ6IEpvaW4mbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfDwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwgR3JvdXAgKFJv b20tQS1MaWdodHMpJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyB8PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgfC0tLUxMLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSZndDt8Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHw8L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfDwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCBNTEQgUmVwb3J0OiBK b2luJm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyB8PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyB8IEdyb3VwIChSb29tLUEtTGlnaHRzKSZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHw8L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDt8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfC0tLUxMLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0mZ3Q7fCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyB8PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IHw8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg fCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8 TUxEIFJlcG9ydDogSm9pbiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfEdyb3VwIChSb29tLUEtTGlnaHRz KXw8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg fCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwtLS1M TC0tLS0mZ3Q7fDwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyB8PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg fCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHw8L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij4mbmJzcDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgRmlndXJlIDQ6IEpvaW5pbmcgTGlnaHRpbmcgR3JvdXBz IFVzaW5nIE1MRDwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOzwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPi9jb21tZW50IHBvc3NpYmx5IHJlbW92ZSBmcm9tIHRleHQsIG9y IGRvIHNlcGFyYXRlIHNlY3Rpb24gb24gdXNlIG9mDQo8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij5NTEQ8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4vY29tbWVudCBhbnl3YXkgc2Vw YXJhdGluZyBjb21taXNzaW9uaW5nIGZyb20gb3BlcmF0aW9uIGluIHNlcGFyYXRlDQo8L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5zZWN0aW9ucyBpcyBhIGdvb2QgaWRlYS48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4v Y29tbWVudCB0aGUgcHJveGllcyBhcmUgYSBjb21wbGljYXRpb24gaW4gdGhlIHBpY3R1cmUgbm90 IGVsYWJvcmF0ZWQNCjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPmluIHRoZSB0ZXh0Ljwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPi9jb21tZW50IHRoZSBzdWJqZWN0IG9mIHByb3hp ZXMgaXMgYW5vdGhlciBvbmUsIHRvIGJlIHRyZWF0ZWQNCjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPmVsc2V3aGVyZS48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4vY29tbWVudCBh bHNvIGZvciBwcm94aWVzIHRoZSBkbydzIGFuZCBkb24ndCdzIGZyb20gYSBzaW1wbGUNCjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPnBlcmZvcm1hbmNlIHBlcnNwZWN0aXZlIHdpbGwgYmUg aW50ZXJlc3Rpbmc8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDs8L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4m bmJzcDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDs8L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij4mbmJzcDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDs8 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij4mbmJzcDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDs8L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij4mbmJzcDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDs8L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJz cDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDs8L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij4mbmJzcDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDs8L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij4mbmJzcDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDs8L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4m bmJzcDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDs8L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij5SYWhtYW4gJmFtcDsgRGlqayZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBFeHBpcmVzIEFwcmlsIDIy LCAyMDEzJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFtQYWdlDQo8L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij4xNl08L3A+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dDsgZm9udC1mYW1pbHk6Q29uc29sYXMiPjxiciBjbGVhcj0iYWxsIiBzdHlsZT0icGFnZS1icmVh ay1iZWZvcmU6YWx3YXlzIj4NCjwvc3Bhbj4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNw OzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkludGVybmV0LURyYWZ0Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEdyb3VwIENvbW11bmljYXRpb24gZm9yIENv QVAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg T2N0b2Jlcg0KPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+MjAxMjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPiZuYnNwOzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNw OzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyBMaWdodCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBS dHItMSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBSdHItMiZuYnNwOyZuYnNwOw0KPC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+TmV0d29yazwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PiZuYnNwOyZuYnNwOyZuYnNwOyBMaWdodC0xJm5ic3A7Jm5ic3A7IExpZ2h0LTImbmJzcDsmbmJz cDsmbmJzcDsgTGlnaHQtMyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBTd2l0Y2gmbmJzcDsmbmJz cDsmbmJzcDsgKENvQVAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgKENvQVAmbmJzcDsmbmJzcDsN CjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkJhY2tib25lPC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgUHJveHkpJm5ic3A7Jm5ic3A7Jm5ic3A7IFByb3h5 KSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHw8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICoqKioqKioqKioqKioqKioqKioqKioqJm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfDwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgKiZuYnNwOyZuYnNw OyBVc2VyIGZsaXBzIG9uJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICombmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAqJm5ic3A7Jm5ic3A7IGxpZ2h0IHN3 aXRjaCB0byZuYnNwOyZuYnNwOyAqJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgfDwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgKiZuYnNwOyZuYnNwOyB0dXJuIG9uIGFsbCB0aGUmbmJzcDsmbmJzcDsg KiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHw8 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICombmJz cDsmbmJzcDsgbGlnaHRzIGluIFJvb20gQSZuYnNwOyAqJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfDwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgKioqKioqKioqKioqKioqKioqKioqKiombmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHw8L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7fCZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfDwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCBDT0FQIE5PTiAoUFVUJm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFByb3h5LVVSSSB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfDwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBVUkkgZm9yIFJvb20tQS1MaWdodHMm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgfDwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg fCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyBQYXlsb2FkPXR1cm4gb24gbGlnaHRzKSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyB8PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IHwtLS0tLS0tLS0mZ3Q7fCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHw8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgfDwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyAmbmJzcDt8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyB8PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgUmVxdWVzdCBETlMgcmVzb2x1dGlv biBvZiZuYnNwOyB8PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgVVJJIGZvciBSb29tLUEtTGlnaHRzJm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHw8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8LS0tLS0tLS0tLS0tLS0tLS0tLS0mZ3Q7fDwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO3wmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHw8L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfDwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IERO UyByZXR1cm5zOiBBQUFBJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IHw8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBHcm91cCAoUm9vbS1BLUxpZ2h0cykm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfDwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IElQdjYg bXVsdGljYXN0IGFkZHJlc3MmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfDwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbHQ7LS0tLS0tLS0tLS0tLS0t LS0tLS18PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNw O3wmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg fCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHw8 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfDwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBDT0FQIE5PTiAoUHV0 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IHw8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg fCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBVUkkgUGF0aCZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7fCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyBQYXlsb2FkPXR1cm4gb24gbGlnaHRzKXw8L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyBEZXN0 aW5hdGlvbiBJUCBBZGRyZXNzID0mbmJzcDsmbmJzcDsmbmJzcDsgfDwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IElQIG11bHRpY2FzdCBhZGRyZXNzJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IHw8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg fCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBmb3IgR3JvdXAgKFJvb20tQS1M aWdodHMpfDwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7IE9yaWdpbmF0aW5nIElQIEFkZHJlc3MgPSZuYnNwOyZuYnNw OyZuYnNwOyB8PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgUlRSLTEmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfDwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwtLS0tLS0tLS0tLS0t LS0tLS0tLSZndDt8PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7ICZuYnNwOyZu YnNwOyZuYnNwO3wmbHQ7LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t fCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHw8 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfDwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZsdDstLS0tLS0tLS18 PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZs dDstLS0tLS0tLS18Jmx0Oy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS18Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHw8L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfDwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+Jm5ic3A7PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEZpZ3VyZSA1OiBTZW5kaW5nIExpZ2h0aW5n IENvbnRyb2wgTXVsdGljYXN0IE1lc3NhZ2U8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4m bmJzcDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDs8L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij4mbmJzcDs8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5SYWhtYW4g JmFtcDsgRGlqayZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyBFeHBpcmVzIEFwcmlsIDIyLCAyMDEzJm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IFtQYWdlDQo8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4x N108L3A+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDsgZm9udC1mYW1pbHk6Q29uc29s YXMiPjxiciBjbGVhcj0iYWxsIiBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj4NCjwv c3Bhbj4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOzwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPkludGVybmV0LURyYWZ0Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IEdyb3VwIENvbW11bmljYXRpb24gZm9yIENvQVAmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgT2N0b2Jlcg0KPC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+MjAxMjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNw OzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOzwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBM aWdodCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBSdHItMSZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyBSdHItMiZuYnNwOyZuYnNwOw0KPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ TmV0d29yazwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyBM aWdodC0xJm5ic3A7Jm5ic3A7IExpZ2h0LTImbmJzcDsmbmJzcDsmbmJzcDsgTGlnaHQtMyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyBTd2l0Y2gmbmJzcDsmbmJzcDsmbmJzcDsgKENvQVAmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgKENvQVAmbmJzcDsmbmJzcDsNCjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPkJhY2tib25lPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgUHJveHkpJm5ic3A7Jm5ic3A7Jm5ic3A7IFByb3h5KSZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyB8PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IHw8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgKioqKioqKioqKioqKioqKioqKioqKiombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7fCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfDwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAqJm5ic3A7Jm5ic3A7IExpZ2h0cyBpbiBSb29tLUEm bmJzcDsgKiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyB8PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 ICombmJzcDsmbmJzcDsgdHVybiBvbiAobmVhcmx5Jm5ic3A7Jm5ic3A7ICombmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfDwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAqJm5ic3A7Jm5ic3A7IHNpbXVs dGFuZW91c2x5KSZuYnNwOyZuYnNwOyAqJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IHw8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgKioqKioqKioqKioqKioqKioqKioqKiombmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfDwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHw8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBDT0FQIE5PTiAo Mi4wNCBDaGFuZ2VkKSZuYnNwOyAmbmJzcDsmbmJzcDt8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0mZ3Q7fCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IHw8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgfDwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyB8PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg Q09BUCBOT04gKDIuMDQgQ2hhbmdlZCkmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IHw8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyB8LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSZndDt8Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfDwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwO3wmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHw8L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IENPQVAgTk9OICg1LjAwIEludGVybmFsIFNlcnZlciBFcnJv cikmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfDwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfC0tLS0tLS0t LS0tLS0tLS0tLS0tJmd0O3wmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyB8PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IHw8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqJm5ic3A7Jm5ic3A7IHw8L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgKiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyBSdHItMSBhcyBDb0FQIFByb3h5Jm5ic3A7Jm5ic3A7ICombmJzcDsm bmJzcDsgfDwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyAqJm5ic3A7IHwmbmJzcDsmbmJzcDsgc2VuZHMgdGhlIGluZGl2aWR1YWwmbmJzcDsgKiZuYnNw OyZuYnNwOyB8PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZu YnNwOyombmJzcDsgfCZuYnNwOyZuYnNwOyByZXNwb25zZXMgYmFjayB0byZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyAqJm5ic3A7Jm5ic3A7IHw8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgKiZuYnNwOyB2Jm5ic3A7Jm5ic3A7IG9yaWdpbmF0b3ImbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgKiZuYnNwOyZuYnNwOyB8PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7ICoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKiZuYnNwOyZuYnNw OyB8PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg fCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHw8L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDt8Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZu YnNwOyZuYnNwOyBDT0FQIE5PTiAoMi4wNCBDaGFuZ2VkKSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IHw8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg fCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZs dDstLS0tLS0tLS18Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgfDwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyB8PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg fCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8 Jm5ic3A7Jm5ic3A7Jm5ic3A7IENPQVAgTk9OICgyLjA0IENoYW5nZWQpJm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgfDwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyB8Jmx0Oy0tLS0tLS0tLXwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyB8PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IHw8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsgQ09BUCBOT04gKDUuMDAgSW50ZXJuYWwgU2VydmVy IEVycm9yKSZuYnNwOyB8PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7ICZuYnNw OyZuYnNwOyZuYnNwO3wmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IHwmbHQ7LS0tLS0tLS0tfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHw8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgfDwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOzwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOzwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBGaWd1cmUgNjogU2VuZGluZyBMaWdo dGluZyBDb250cm9sIFJlc3BvbnNlIHRvIE11bHRpY2FzdCBNZXNzYWdlPC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+Jm5ic3A7PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7IE5PVEU6IEluIHRoZSBsYXN0IHN0ZXAgb2YgRmlndXJlIDYsIFJ0ci0xIGFj dGluZyBhcyBDb0FQIHByb3h5LDwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZu YnNwOyZuYnNwOyByZXR1cm5zIG11bHRpcGxlIGluZGl2aWR1YWwgQ29BUCByZXNwb25zZXMgdG8g dGhlIGNsaWVudC4mbmJzcDsgRWFjaDwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNw OyZuYnNwOyZuYnNwOyByZXNwb25zZSBlY2hvZXMgdGhlIFRva2VuIG9mIHRoZSBjbGllbnQncyBy ZXF1ZXN0LiZuYnNwOyBUaGUgY2xpZW50IGNhbjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PiZuYnNwOyZuYnNwOyZuYnNwOyBpZGVudGlmeSB0aGUgb3JpZ2luYWwgc291cmNlIG9mIGVhY2gg cmVzcG9uc2UgYnkgLi4uVEJELjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOzwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOzwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPi9jb21tZW50IFdIWSBhcmUgdGhlIG11bHRpY2FzdCBkZXN0aW5hdGlvbnMgc2VuZGlu ZyBiYWNrIHJlc3VsdHM/PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+L2NvbW1lbnQgSSB0 aG91Z2h0IHRoYXQgeW91IHdhbnRlZCBNQyBtZXNzYWdlcyB0byBiZSBub24gY29uZmlybWFibGU8 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4vY29tbWVudCBzZW5kaW5nIHJlc3BvbnNlcyBz ZWVtcyB0byBjb250cmFkaWN0IHRoaXMgLjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPi9j b21tZW50IHBsZWFzZSByZW1vdmUgc2VuZGluZyBiYWNrIG9mIHJlc3BvbnNlcy48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij4vY29tbWVudCBvbmUgbWF5IGFzc3VtZSB0aGF0IHRoZSBNQyBh bGdvcml0aG0gd2l0aGluIHRoZSBsb3dwYW4gaXMNCjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPnJlbGlhYmxlIChhbGwgZGVzdGluYXRpb25zIHJlY2VpdmUgdGhlIG1lc3NhZ2UpPC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+L2NvbW1lbnQgYW55d2F5IE1QTCBjb21lcyBjbG9zZSBl bm91Z2ggdG8gdGhlIHJlbGlhYmlsaXR5IHJlcXVpcmVtZW50DQo8L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij5naXZlbiBhIHNwZWNpZmlhYmxlIHJhbmdlIG9mIGNvbmZpZ3VyYXRpb25zPC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+LS0gPC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+UGV0ZXIgdmFuIGRlciBTdG9rPC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+bWFpbHRvOiA8YSBocmVmPSJtYWlsdG86Y29uc3VsdGFuY3lAdmFuZGVyc3Rv ay5vcmciPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0OyB0ZXh0LWRlY29yYXRpb246bm9u ZSI+Y29uc3VsdGFuY3lAdmFuZGVyc3Rvay5vcmc8L3NwYW4+PC9hPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPnd3dzogPGEgaHJlZj0iaHR0cDovL3d3dy52YW5kZXJzdG9rLm9yZyI+PHNw YW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7IHRleHQtZGVjb3JhdGlvbjpub25lIj53d3cudmFu ZGVyc3Rvay5vcmc8L3NwYW4+PC9hPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPnRlbCBO TDogJiM0MzszMSgwKTQ5MjQ3NDY3MyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBGOiAmIzQzOzMz KDApOTY2MDE1MjQ4PC9wPg0KPC9kaXY+DQo8YnI+DQo8aHI+DQo8Zm9udCBmYWNlPSJBcmlhbCIg Y29sb3I9IkdyYXkiIHNpemU9IjEiPlRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBt ZXNzYWdlIG1heSBiZSBjb25maWRlbnRpYWwgYW5kIGxlZ2FsbHkgcHJvdGVjdGVkIHVuZGVyIGFw cGxpY2FibGUgbGF3LiBUaGUgbWVzc2FnZSBpcyBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSBhZGRy ZXNzZWUocykuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHlvdSBhcmUg aGVyZWJ5IG5vdGlmaWVkDQogdGhhdCBhbnkgdXNlLCBmb3J3YXJkaW5nLCBkaXNzZW1pbmF0aW9u LCBvciByZXByb2R1Y3Rpb24gb2YgdGhpcyBtZXNzYWdlIGlzIHN0cmljdGx5IHByb2hpYml0ZWQg YW5kIG1heSBiZSB1bmxhd2Z1bC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVu dCwgcGxlYXNlIGNvbnRhY3QgdGhlIHNlbmRlciBieSByZXR1cm4gZS1tYWlsIGFuZCBkZXN0cm95 IGFsbCBjb3BpZXMgb2YgdGhlIG9yaWdpbmFsIG1lc3NhZ2UuPGJyPg0KPC9mb250Pg0KPC9ib2R5 Pg0KPC9odG1sPg0K --_000_031DD135F9160444ABBE3B0C36CED618B39574011DB3MPN2082MGDP_-- From stokcons@xs4all.nl Thu Dec 20 02:27:02 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D4CA21F8849 for ; Thu, 20 Dec 2012 02:27:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.296 X-Spam-Level: X-Spam-Status: No, score=0.296 tagged_above=-999 required=5 tests=[AWL=-0.400, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, J_CHICKENPOX_64=0.6, J_CHICKENPOX_74=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gDTe8f5wn7t4 for ; Thu, 20 Dec 2012 02:26:58 -0800 (PST) Received: from smtp-vbr5.xs4all.nl (smtp-vbr5.xs4all.nl [194.109.24.25]) by ietfa.amsl.com (Postfix) with ESMTP id D52FC21F85B8 for ; Thu, 20 Dec 2012 02:26:57 -0800 (PST) Received: from roundcube.xs4all.nl (roundcube7.xs4all.net [194.109.20.205]) by smtp-vbr5.xs4all.nl (8.13.8/8.13.8) with ESMTP id qBKAQPVh067262; Thu, 20 Dec 2012 11:26:25 +0100 (CET) (envelope-from stokcons@xs4all.nl) Received: from a82-95-140-48.adsl.xs4all.nl ([82.95.140.48]) by roundcube.xs4all.nl with HTTP (HTTP/1.1 POST); Thu, 20 Dec 2012 11:26:25 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Thu, 20 Dec 2012 11:26:25 +0100 From: peter van der Stok To: "Dijk, Esko" Organization: vanderstok consultancy Mail-Reply-To: In-Reply-To: <031DD135F9160444ABBE3B0C36CED618B39574@011-DB3MPN2-082.MGDPHG.emi.philips.com> References: <031DD135F9160444ABBE3B0C36CED618B39574@011-DB3MPN2-082.MGDPHG.emi.philips.com> Message-ID: <8dd1c4cf0ca945d6059c24a988d3996b@xs4all.nl> X-Sender: stokcons@xs4all.nl (xY1P6HQhQQ46JSxfcuZaS+d2Lpw21gIc) User-Agent: XS4ALL Webmail X-Virus-Scanned: by XS4ALL Virus Scanner Cc: Core Subject: Re: [core] group-comm comments X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: consultancy@vanderstok.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Dec 2012 10:27:02 -0000 Hi Esko, thanks for your reactions. I will group my answers, to better explain my points on the return of packets to MC senders. 1) Return of packets to multicast As I understand the multicast message is preferably sent with no confirmation (ack) because the return of all the acks may overwhelm the network and the sender of the multicast. The acknowledgement is not needed for MPL as the protocol has all the machinery to assure that all destinations receive it, (given constraints on network load and configuration density and size). Supposing an ack is needed, then it would be advisable to staffle the responses and an additional acknowledgement protocol could be added to the multicast protocol. The same is true if a message is returned (as in the case of mDNS). One can then wonder whether the application protocol (e.g. mDNS) should take care of the staffled response or that an additional protocol needs to be specified. I have no opinion on the choice, but see the need for the one or the other. Coming with a recommendation (explanation) on the subject of returning responses (acks) would be my recommendation for the GroupComm document. Below some reactions on your reactions. Hope this helps to clarify misunderstandings. Peter Dijk, Esko schreef op 2012-12-19 14:24: > Hi Peter, > > still a fair number of comments! I would agree with most. Below I > have selected some which we should discuss further, or ones I don’t > agree with: > > 1. Group communication definition -> > Why can't a source node be part of the group that it sends to? E.g. > combined sensor+luminaire use case. The IP stack would deliver sent > multicast CoAP requests also to the local application if it is > subscribed to the multicast IP address. source can of course be member of destination group. source may be part of the group (remove the "or may be not" part of the phrase) > > 2. I don’t see why we should add “the use of group communication for > mDNS is out of scope.” -> > mDNS obviously is not CoAP, and the document should define the scope > anyway clearly as CoAP group communication. So we don’t have to list > any other protocols than CoAP. See my answer on return of packets. I wanted a clear statement on (NOT) specifying how applications handle the return of MC responses. > > 3. “so setting a multicast address in a source at installation is > forbidden?” -> > No, that should not be forbidden :) It should also be possible to > set a CoAP path and/or port at installation time. That means the two > presented measures have to change or be removed. No comment > > 4. “there are 2 ways: (1) the node queries to which group it belongs > or (2) an instalation tools instructs the node to which groups” -> > Good point. (2) has been chosen because it works without relying on > a service to query (e.g. DNS or RD). Is that sufficient argumentation? > The mechanism is optional in any case so it does not block others from > defining a DNS or RD variant. I would point out both variants and mention that the draft focusses on (2) > > 5. “/s requests /s replies” -> > multicast replies (if you mean responses) do not exist in CoAP. It’s > about requests that should be carefully controlled since they generate > unicast responses. Then I do not understand the text, because "request", "reply" and "response" are overloaded in my mind. > > 6. “/comment what about the reply?” -> > based on core-coap “If the request message is Non-confirmable, then > the response SHOULD be returned in a Non-confirmable message as well.” > . Do you think we should quote this from the core-coap spec? As explained above The subject of returning packets to the MC sender needs careful consideration. the response being NOn-confirmable does not solve a lot I am afraid. > > 7. “/comment invoking as many certificates?” -> > core-coap-13 now loosens the concept of authentication to also > include other measures, not needing certificates. No comment > > 8. Network configuration: 2 subnets vs 1 -> > maybe a one-subnet configuration is worth adding? Here an overview > of present/absent use cases: > > - Link-local CoAP multicast with responses: Present, Appendix A of > core-coap > - Site-local CoAP multicast, single subnet: > - Site-local CoAP multicast, multi subnet, with or without responses > (in the new -04 groupcomm): Present > - Global CoAP multicast, single or multi subnet, with or without > responses: / dependency on IANA IPv6 allocation > - any configurations with a central controller on the backbone > multicasting: Again, the draft should go for the most frequent use cases and not try to be complete. Actually explicitly excluding use cases looks ineresting to me. > > 9. “It might be useful if the practical impossibility of some > configurations is high lighted” -> > any thoughts, which would be impossible? During the coap meeting in Atlanta, Cullen Jennings presented some horrifying examples, as far as I remember. > > 10.“the RD discovery will be more complex when there is a router > between light-2 and switch” -> > yes, there are issues in RD/discovery especially when more than one > is present in a network. So, adapt the use case and exclude this possibility. > > 11.“additional reason to remove router from the multicast > configuration”-> > hmm, I think that we should opt for having a single RD in the system > to avoid complexity. Routers are ok. (One of our goals is to define > how CoAP groupcomm works even across routers) Looking forward to the supporting protocol. > > 12.“MLD is used to form groups, correct? but that was already done by > enabling the MC address in the lights (point 2)” -> > Step 1 is putting the MC address in the lights, then step 2 is the > Lights use MLD to *ADVERTIZE* this address to any MLD-enabled Routers > present link-local. > So MLD is not a commissioning-time protocol but runs all the time > during operation. > Note that in groupcomm -04 we will remove MLD in the basic use case > and present it as an option later. Sounds good. The point is not to add protocols because they exist but because they are needed. > > 13.“WHY are the multicast destinations sending back results?” -> > we remove responses in the new -04 groupcomm. They are presented as > an optional thing that servers can do. > CoAP servers normally MUST respond to a request with a response > (core-coap-13) but an exception is now made for multicast where a > server MAY choose not to. This choice is completely independent from > confirmable/non-confirmable. Non-confirmable only means that an ACK > must not be sent. And an ACK is something different from a CoAP > response. > Agree that a protocol like MPL comes very close to ‘reliable > multicast’. see my worries at the beginning. > > Esko > > -----Original Message----- > From: peter van der Stok [mailto:stokcons@xs4all.nl] > Sent: Tuesday 18 December 2012 12:06 > To: akbar rahman; Dijk, Esko; Core > Subject: group-comm comments > > Hi Akbar and Esko, > > I had promised to review, comment the group comm draft. > > Below the commented text. > > I have not gone very detailed with my comments. I hope that it is > clear from my comments that a reorganization of the draft and a review > of the uses cases are necessary to get a clearer picture of the > feasibility of group comm in the context of Coap. > > Especialy difficult to understand for me were: > > - the use case network configuration > > - the forming and enabling of groups > > - use of responses > > Hope this helps. > > Greetings, > > peter > > _____________________________________________________________________________________________________ > > > Abstract > > CoAP is a RESTful transfer protocol for constrained devices. It is > > anticipated that constrained devices will often naturally operate in > > groups (e.g. in a building automation scenario all lights in a given > > room may need to be switched on/off as a group). This document > > defines how the CoAP protocol should be used in a group communication > > context. An approach for using CoAP on top of IP multicast is > > detailed for both constrained and un-constrained networks. Also, > > various use > > /s causes /s cases/ > > and corresponding protocol flows are provided to > > illustrate important concepts. Finally, guidance is provided for > > deployment in various network topologies. > > Status of this Memo > > This Internet-Draft is submitted in full conformance with the > > provisions of BCP 78 and BCP 79. > > Internet-Drafts are working documents of the Internet Engineering > > Task Force (IETF). Note that other groups may also distribute > > working documents as Internet-Drafts. The list of current Internet- > > Drafts is at http://datatracker.ietf.org/drafts/current/ [1]. > > Internet-Drafts are draft documents valid for a maximum of six months > > and may be updated, replaced, or obsoleted by other documents at any > > time. It is inappropriate to use Internet-Drafts as reference > > material or to cite them other than as "work in progress." > > This Internet-Draft will expire on April 22, 2013. > > Copyright Notice > > Copyright (c) 2012 IETF Trust and the persons identified as the > > document authors. All rights reserved. > > This document is subject to BCP 78 and the IETF Trust's Legal > > Provisions Relating to IETF Documents > > (http://trustee.ietf.org/license-info [2]) in effect on the date of > > Rahman & Dijk Expires April 22, 2013 [Page > > 1] > > Internet-Draft Group Communication for CoAP October > > 2012 > > publication of this document. Please review these documents > > carefully, as they describe your rights and restrictions with respect > > to this document. Code Components extracted from this document must > > include Simplified BSD License text as described in Section 4.e of > > the Trust Legal Provisions and are provided without warranty as > > described in the Simplified BSD License. > > 1. Conventions and Terminology > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this > > document are to be interpreted as described in [RFC2119]. > > This document assumes readers are familiar with the terms and > > concepts that are used in [I-D.ietf-core-coap]. In addition, this > > document defines the following terminology: > > Group Communication > > A source node sends a single message which is delivered to > > multiple destination nodes, where all destinations are identified > > to belong to a specific group. The source node may > > /remove or may not > > be > > part of the group. The underlying mechanism for group > > communication is assumed to be multicast based. > > /remove > > The network where > > the group communication takes place can be either a constrained > > or > > a regular (un-constrained) network/ > > /comment not sure about the meaning and consequences > > Multicast > > Sending a message to multiple destination nodes > > /s simultaneously./ > > /s with one network invocation / > > There are various options to implement multicast including layer > > 2 > > (Media Access Control) or layer 3 (IP) mechanisms. > > IP Multicast > > A specific multicast solution based on the use of IP multicast > > addresses as defined in "IANA Guidelines for IPv4 Multicast > > Address Assignments" [RFC5771] and "IP Version 6 Addressing > > Architecture" [RFC4291]. > > Low power and Lossy Network (LLN) > > Low power and Lossy Network (LLN): A type of constrained network > > where the devices are interconnected by a variety of low power, > > lossy links such as IEEE 802.15.4, Bluetooth, > > WiFi, wired > > or low > > power power-line communication links. > > 2. Introduction > > 2.1. Background > > The Constrained Application Protocol (CoAP) is an application > > protocol (analogous to HTTP) for resource constrained devices > > operating in an IP network [I-D.ietf-core-coap]. Constrained > > devices > > can be large in number, but are often highly correlated to each > > other > > (e.g. by type or location). For example, all the light switches in > > a > > building may belong to one group and all the thermostats may belong > > to another group. Groups may be composed by function. For example, > > Rahman & Dijk Expires April 22, 2013 [Page > > 3] > > Internet-Draft Group Communication for CoAP October > > 2012 > > the group "all lights in building one" may consist of the groups > > "all > > lights on floor one of building one", "all lights on floor two of > > building one", etc. Groups may be preconfigured > > /add before deployment > > or dynamically > > formed > > /add during operation > > . If information needs to be sent to or received from a group > > of devices, group communication mechanisms can improve efficiency > > and > > latency of communication and reduce bandwidth requirements for a > > given application. HTTP does not support any equivalent > > functionality to CoAP group communication. > > 2.2. Scope > > In this draft, we address the issues related to CoAP group > > communication in detail, with use cases, recommended approaches and > > analysis of the impact to the CoAP protocol and to implementations. > > /add the use of group communication for mDNS is out of scope. > > The guiding principle is to apply wherever possible existing IETF > > protocols to achieve group communication functionality. In many > > cases the contribution of this document lies in explaining how > > existing mechanisms may be used to > > /remove together > > fulfill CoAP group > > communication needs for specific use cases. > > 2.3. Potential Solutions for Group Communication > > The classic concept of group > > /s communications /s communication > > is that of a single > > source distributing content to multiple destination recipients that > > are all part of a group. Before content can be distributed, there > > is > > a separate process to form the group. The source may be either a > > member or non-member of the group. > > Group communication solutions have evolved from "bottom" to "top", > > i.e., from layer 2 (Media Access Control broadcast/multicast) and > > layer 3 (IP multicast) to application layer group communication, > > also > > referred to as application layer multicast. A study published in > > 2005 [Lao05] identified new solutions in the "middle" (referred to > > as > > overlay multicast) that utilize an infrastructure based on proxies. > > Each of these classes of solutions may be compared [Lao05] using > > metrics such as link stress and level of host complexity > > [Banerjee01]. The results show for a realistic internet topology > > that IP Multicast is the most resource-efficient, with the downside > > being that it requires > > /s the most /s more organizational > > effort to deploy in the > > infrastructure. IP Multicast is the solution adopted by this draft > > for CoAP group communication. > > 3. CoAP Group Communication Based On IP Multicast > > Rahman & Dijk Expires April 22, 2013 [Page > > 4] > > Internet-Draft Group Communication for CoAP October > > 2012 > > 3.1. IP Multicast Background > > IP Multicast routing protocols have been evolving for decades, > > resulting in proposed standards such as Protocol Independent > > Multicast - Sparse Mode (PIM-SM) [RFC4601]. Yet, due to various > > technical and marketing reasons, IP Multicast routing is not widely > > deployed on the general Internet. However, IP Multicast is very > > popular in specific deployments such as in enterprise networks (e.g. > > for video conferencing), smart home networks (e.g. UPnP/mDNS) and > > carrier IPTV deployments. The packet economy and minimal host > > complexity of IP multicast make it attractive for group > > communication > > in constrained environments. Therefore IP multicast is the > > recommended underlying mechanism for CoAP group communication, and > > the approach assumed in this document. > > To achieve IP multicast beyond a subnet, an IP multicast routing > > protocol needs to be active on routers. The RPL protocol [RFC6550] > > for example is able to route multicast traffic in constrained LLNs. > > While PIM-SM [RFC4601] is often used for multicast routing in un- > > constrained networks. > > IP multicast can also be run in a Link-Local (LL) scope. This means > > that there is no routing involved and an IP multicast message is > > only > > received > > /s on the network /s over the > > link on which it was sent. > > 3.2. CoAP Group Definition and Naming > > A group is defined as a set of CoAP endpoints, where each endpoint > > is > > configured to receive a multicast CoAP request that is sent to the > > group's associated IP multicast address. The group MAY have more > > than one associated IP multicast address. An endpoint MAY be a > > member of multiple groups. Group membership of an endpoint MAY > > dynamically change over time. The group MAY be identified by a > > Group > > Name ([I-D.vanderstok-core-dna]) which is defined as a prefix string > > of a Group FQDN. The Group FQDN can be uniquely mapped to a site- > > local or global multicast IP address via DNS resolution. > > A CoAP multicast request that addresses a group includes a Group URI > > as the request URI. A Group URI has the scheme 'coap' and includes > > in the authority part either a group IP address > > /add + optional port > > or a hostname > > /add + optional port > > that > > can be resolved to the group IP address (e.g., a Group Name or Group > > FQDN). Group URIs MUST follow the URI syntax [RFC3986]. > > A CoAP > > /s node /s end-point > > becomes a group member by listening for CoAP messages on > > the group's IP multicast address, assuming the default CoAP UDP > > port. > > Note that a non-default UDP port MAY be specified for the group; in > > which case implementers MUST ensure that all group members are > > configured to use this same port. > > Rahman & Dijk Expires April 22, 2013 [Page > > 5] > > Internet-Draft Group Communication for CoAP October > > 2012 > > Examples of hierarchical group naming (and scoping) for a building > > control application are shown below. > > URI authority Targeted group > > all.bldg6.example.com "all nodes in building 6" > > all.west.bldg6.example.com "all nodes in west wing, building > > 6" > > all.floor1.west.bldg6.examp... "all nodes in floor 1, west wing, > > building 6" > > all.bu036.floor1.west.bldg6... "all nodes in office bu036, floor1, > > west wing, building 6" > > Reverse mapping (from IP multicast address to group FQDN) is > > supported using the reverse DNS resolution technique > > ([I-D.vanderstok-core-dna]). > > 3.3. Group Discovery and Member Discovery > > CoAP defines a resource discovery capability, but does not yet > > specify how to discover groups (e.g. find a group to join or send a > > multicast message to) or to discover members of a group (e.g. to > > address selected group members by unicast). These topics are > > elaborated in more detail in [I-D.vanderstok-core-dna] including > > examples for using DNS-SD and CoRE Resource Directory. > > 3.3.1. DNS-SD > > DNS-based Service Discovery [I-D.cheshire-dnsext-dns-sd] defines a > > conventional way to configure DNS PTR, SRV, and TXT records to > > enable > > enumeration of services, such as services offered by CoAP nodes, or > > enumeration of all CoAP nodes, within specified subdomains. A > > service is specified by a name of the form > > .., where the service type for CoAP > > nodes is _coap._udp and the domain is a DNS domain name that > > identifies a group as in the examples above. For each CoAP > > end-point > > in a group, a PTR record with the name _coap._udp and/or a PTR > > record > > with the name _coap._udp. is defined and it points to an SRV > > record having the .. name. > > All CoAP nodes in a given subdomain may be enumerated by sending a > > query for PTR records named _coap._udp to the authoritative DNS > > server for that zone. A list of SRV records is returned. Each SRV > > record contains the port and host name (AAAA record) of a CoAP node. > > The IP address of the node is obtained by resolving the host name. > > DNS-SD also specifies an optional TXT record, having the same name > > as > > the SRV record, which can contain "key=value" attributes. This can > > be used to store information about the device, e.g. schema=DALI, > > type=switch, group=lighting.bldg6, etc. > > Rahman & Dijk Expires April 22, 2013 [Page > > 6] > > Internet-Draft Group Communication for CoAP October > > 2012 > > Another feature of DNS-SD is the ability to specify service subtypes > > using PTR records. For example, one could represent all the CoAP > > groups in a subdomain by PTR records with the name > > _group._sub._coap._udp or alternatively > > _group._sub._coap._udp.. > > 3.3.2. CoRE Resource Directory > > CoRE Resource Directory [I-D.shelby-core-resource-directory] defines > > the concept of a Resource Directory (RD) server where CoAP servers > > can register their resources offered and CoAP clients can discover > > these resources by querying the RD server. RD syntax can be mapped > > to DNS-SD syntax and vice versa [I-D.lynn-core-discovery-mapping], > > such that the above approach can be reused for group discovery and > > group member discovery. > > /remove Specifically, the Domain (d) parameter can be set to the > > group URI by > > an end-point registering to the RD. If an end-point wants to join > > multiple groups, it has to repeat the registration process for each > > group it wants to join. > > /end remove > > /comment d parameter semantics not clear > > 3.4. Group Resource Manipulation > > Group communications SHALL only be used for idempotent methods (i.e. > > CoAP GET, PUT, DELETE). The CoAP messages that are sent via > > multicast SHALL be Non-Confirmable. > > A unicast response per server MAY be sent back to answer the group > > request (e.g. response "2.05 Content" to a group GET request) taking > > into account the congestion control rules defined in > > [I-D.ietf-core-coap]. The unicast responses may be a mixture of > > success (e.g. 2.05 Content) and failure (e.g. 4.04 Not Found) codes > > depending on the individual server processing result. > > Group communications SHALL NOT be used for non-idempotent methods > > (i.e. CoAP POST). This is because not all group members are > > guaranteed to receive the multicast request, and the sender can not > > readily find out which group members did not receive it. > > All nodes in a given group SHOULD receive the same request > > /remove with high probability. > > /comment I don't see where probability comes in. > > This will not be the case if there is diversity in the > > authority port (i.e. a diversity of dynamic port addresses across > > the > > group) or if the targeted resource is located at different paths on > > different nodes. > > Therefore, some measures must be present to ensure uniformity in > > port > > number and resource names/locations within a group. This document > > proposes the following measures: > > Rahman & Dijk Expires April 22, 2013 [Page > > 7] > > Internet-Draft Group Communication for CoAP October > > 2012 > > o All CoAP multicast requests MUST be sent either to the default > > CoAP UDP port (i.e. default Uri-Port as defined in > > [I-D.ietf-core-coap]), or to a port number obtained via a service > > discovery lookup operation as a valid CoAP port for the targeted > > multicast group. > > o All CoAP multicast requests SHOULD operate only on URIs (links) > > which were > > /s retreived /s retrieved > > either from a "/.well-known/core" lookup on > > at least one group member node, or from an equivalent service > > discovery lookup which returns either the resources supported by > > all group members or resources supported by one particular group > > member. > > /comment so setting a multicast address in a source at installation is > > forbidden? > > 3.5. Configuring Group Membership In Endpoints > > In some use cases, the group membership of endpoints needs to be > > configurable after the network has been deployed. Example use cases > > can be found in building control: a commissioning tool determines to > > which groups a light or sensor node belongs, and writes this > > information to all nodes, which can subsequently join the correct > > group. > > To achieve smoother interoperability between nodes/endpoints from > > different manufacturers, it is proposed here to define an OPTIONAL > > standardized RESTful means of configuring CoAP endpoints with > > relevant group information. > > CoAP endpoints implementing this mechanism MUST support a > > discoverable "Group Configuration" resource of resource type (rt) > > [RFC6690] "core.gp". This resource (and perhaps its sub-resources, > > TBD) are used to manage group membership. Three design options for > > this mechanism are presented here as a placeholder (TBD). > > Design 1: use CoRE link format payloads to communicate group > > membership to endpoints. (TBD Not clear how this should be > > realized.) > > /comment, not clear what you mean either. Remove design 1 in this > state > > Design 2: use a JSON type resource. For example, a GET on the > > "core.gp" resource returns a JSON array of group objects. > > Req: GET /gp > > Res: 2.05 Content (Content-Format: application/json) > > [ { "n": "Room-A-Lights.floor1.west.bldg6.example.com", > > "ip": "ff05::4200:f7fe:ed37:14ca" } > > ] > > where "n" defines the Group FQDN and "ip" defines the associated > > multicast IP address. As a next example, the same endpoint can be > > Rahman & Dijk Expires April 22, 2013 [Page > > 8] > > Internet-Draft Group Communication for CoAP October > > 2012 > > added to another group by a POST on the resource with a JSON group > > object: > > Req: POST /gp (Content-Format: application/json) > > { "n": "floor1.west.bldg6.example.com", > > "ip": "ff05::4200:f7fe:ed37:14cb" } > > Res: 2.04 Changed > > Design 3: define named sub-resources, each sub-resource representing > > a group membership. The payload of the sub-resource may be JSON or > > a > > simple pre-defined format. Or alternatively, information is > > provided > > via POST with query parameters. > > /comment are these mutually exclusive designs? > > /comment design 2 without JSON is als possible > > /comment design with SRV and TXt records is also possible > > /comment there are 2 ways: (1) the node queries to which group it > > belongs > > /comment (2) an instalation tools instructs the node to which groups > > it belongs > > /comment not clear in text that this choice exists or that a choice > was > > made. > > 3.6. Congestion Control > > Multicast CoAP requests may result in a multitude of replies from > > different nodes, potentially causing congestion. Therefore sending > > multicast > > /s requests /s replies > > should be conservatively controlled. > > The base CoAP draft [I-D.ietf-core-coap] reduces multicast-specific > > congestion risks through the following measures: > > o A server MAY choose not to respond to a multicast request if > > there's nothing useful to respond (e.g. error or empty response). > > o A server SHOULD limit the support for multicast requests to > > specific resources where multicast operation is required. > > o A multicast request MUST be Non-Confirmable. > > /comment what about the reply? > > o A server does not respond immediately to a multicast request, but > > SHOULD first wait for a time that is randomly picked within a > > predetermined time interval called the Leisure. > > o A server SHOULD NOT accept multicast requests that can not be > > authenticated. > > /comment invoking as many certificates? > > Additional guidelines to reduce congestion risks are: > > o A server in an LLN should only support multicast GET for > > resources > > that are small, e.g. > > /remove for an LLN that could mean > > the payload of the > > response fits into a single link-layer frame. > > o A server can minimize the payload length in response to a > > multicast GET on "/.well-known/core" by using hierarchy in > > arranging link descriptions for the response. An example of this > > is given in Section 5 of [RFC6690]. > > Rahman & Dijk Expires April 22, 2013 [Page > > 9] > > Internet-Draft Group Communication for CoAP October > > 2012 > > o Preferably IP multicast with link-local scope should be used, > > rather than global or site-local. > > o The Hop Limit field in the IPv6 packet should be chosen as low as > > possible (if the CoAP/IP stack allows setting of this value. TBD > > - discuss whether this guideline is relevant/realistic in CoAP > > context) > > 3.7. CoAP Multicast and HTTP Unicast Interworking > > /comment a reference will suffice > > CoAP supports operation over UDP multicast, while HTTP does not. > > For > > use cases where it is required that CoAP group communication is > > initiated from an HTTP end-point, it would be advantageous if the > > HTTP-CoAP Proxy supports mapping of HTTP unicast to CoAP group > > communication based on IP multicast. > > /remove One possible way of operation > > /remove of such HTTP-CoAP Proxy is illustrated in Figure 1. > > Note that this > > topic is covered in more detail in > > [I-D.castellani-core-advanced-http-mapping]. > > /remove > > CoAP Mcast CoAP Mcast HTTP-CoAP HTTP > > Node 1 Rtr1 Node 2 Rtr2 Proxy Node 3 > > | | | | | | > > |MLD REQUEST | | | | > > |(Join Group X) | | | | > > |--LL-->| | | | | > > | | |MLD REQUEST | | > > | | |(Join Group X) | | > > | | |--LL-->| | | > > | | | | | HTTP REQUEST | > > | | | | | (URI to | > > | | | | | unicast addr) | > > | | | | |< -----------------| > > | | | | | | > > | | | Resolve HTTP Request-Line URI | > > | | | to Group X multicast address | > > | | | | | | > > | CoAP REQUEST (to multicast addr)| | > > |< ------<---------<-------<------| | > > | | | | | | > > | | | | > > | (optional) CoAP RESPONSE(s) | | > > | |-------------->| | > > |-----------------|-------------->| Aggregated | > > | | | HTTP RESPONSE | > > | | |------------------>| > > | | | | > > Rahman & Dijk Expires April 22, 2013 [Page > > 10] > > Internet-Draft Group Communication for CoAP October > > 2012 > > Figure 1: CoAP Multicast and HTTP Unicast Interworking > > Note that Figure 1 illustrates the case of IP multicast as the > > underlying group communications mechanism. MLD denotes the > > Multicast > > Listener Discovery protocol ([RFC3810], Appendix A) and LL denotes a > > Link-Local multicast. > > A key point in Figure 1 is that the incoming HTTP Request (from node > > 3) will carry a Host request-header field that resolves in the > > general Internet to the proxy node. At the proxy node, this > > hostname > > and/or the Request-Line URI will then possibly be mapped (as > > detailed > > in [I-D.castellani-core-http-mapping]) and again resolved (with the > > CoAP scheme) to an IP multicast address. This may be accomplished, > > for example, by using DNS or DNS-SD (Section 3.3). The proxy node > > will then IP multicast the CoAP Request (corresponding to the > > received HTTP Request) via multicast routers to the appropriate > > nodes > > (i.e. nodes 1 and 2). > > In terms of the HTTP Response, Figure 1 illustrates that it will be > > generated by the proxy node based on aggregated responses of the > > CoAP > > nodes and sent back to the client in the general Internet that sent > > the HTTP Request (i.e. node 1). In > > [I-D.castellani-core-advanced-http-mapping] the HTTP Response that > > the Proxy may use to aggregate multiple CoAP responses is described > > in more detail. So in terms of overall operation, the CoAP proxy > > can > > be considered to be a "non-transparent" proxy according to > > [RFC2616]. > > Specifically, [RFC2616] states that a "non-transparent proxy is a > > proxy that modifies the request or response in order to provide some > > added service to the user agent, such as group annotation services, > > media type transformation, protocol reduction or anonymity > > filtering." > > An alternative to the above is using a Forward Proxy. In this case, > > the CoAP request URI is carried in the HTTP Request-Line (as defined > > in [I-D.ietf-core-coap] Section 10.2) in a HTTP request sent to the > > IP address of the Proxy. > > /end remove > > 4. Use Cases and Corresponding Protocol Flows > > 4.1. Introduction > > The use of CoAP group communication is shown in the context of the > > following use cases and corresponding protocol flows: > > o Discovery of Resource Directory: discovering the local CoRE RD > > which contains links (URIs) to resources stored on other servers > > [RFC6690]. > > Rahman & Dijk Expires April 22, 2013 [Page > > 11] > > Internet-Draft Group Communication for CoAP October > > 2012 > > o Lighting Control: synchronous operation of a group of 6LoWPAN > > [RFC4944] IPv6-connected lights > > o Parameter Update: updating parameters/settings simultaneously in > > a > > large group of devices in a building/campus control > > ([I-D.vanderstok-core-bc]) application --- TBD > > / comment I suggest to remove Firmware Update and Groups status report > > /comment the ones above are difficult enough, and I doubt that > > simultaneity > > /comment (motivation of multicast) is involved here > > o Firmware Update: efficiently updating firmware simultaneously in > > a > > large group of devices in a building/campus control > > ([I-D.vanderstok-core-bc]) application --- TBD suggests a > > multicast extension of core-block. > > o Group Status Report: requesting status information or event > > reports from a group of devices in a building/campus control > > application --- TBD, may require reliable group communication to > > be feasible. > > 4.2. Network Configuration > > We assume the following network configuration for all the use cases > > as shown in Figure 2: > > /comment the configurations frighten me > > /comment from completeness considerations I can imagine even more > > complex ones > > /comment It might be useful if the practical impossibility of some > > configurations is high lighted > > o A large room (Room-A) with three lights (Light-1, Light-2, > > Light-3) controlled by a Light Switch. The devices are organized > > into two 6LoWPAN subnets. > > /comment one subnet is enough for me > > /remove > > o Light-1 and the Light Switch are connected to a router (Rtr-1) > > which is also a CoAP Proxy, a CoAP Resource Directory (RD) and a > > 6LoWPAN Border Router (6LBR). > > o Light-2 and the Light-3 are connected to another router (Rtr-2) > > which is also a CoAP Proxy, a CoAP RD and a 6LBR. > > o The routers are connected to an IPv6 network backbone which is > > also multicast enabled. In the general case, this means the > > network backbone and 6LBRs support a PIM based multicast routing > > protocol, and MLD for forming groups. In a limited case, if the > > network backbone is one link, then the routers only have to > > support MLD-snooping (Appendix A) for the following use cases to > > work. > > /end remove > > /comment I can imagine that an central control is present on the > > backbone > > /comment switch or sensor send unicast to central control > > /comment central control sends multicast to multicast group within > > single lowpan > > Rahman & Dijk Expires April 22, 2013 [Page > > 12] > > Internet-Draft Group Communication for CoAP October > > 2012 > > Network > > Backbone > > | > > ################################################ > > | > > # Room-A # > > | > > # ********************** # > > | > > # ** LoWPAN-1 (subnet-1) ** # > > | > > # * * # > > | > > # * +----------+ * # > > | > > # * | Light |-------+ * # > > | > > # * | Switch | | * # > > | > > # * +----------+ +---------+ * # > > | > > # * | Rtr-1 > > |-----------------------------| > > # * +---------+ * # > > | > > # * +----------+ | * # > > | > > # * | Light-1 |--------+ * # > > | > > # * +----------+ * # > > | > > # * * # > > | > > # ** ** # > > | > > # ********************** # > > | > > # # > > | > > # # > > | > > # ********************** # > > | > > # ** LoWPAN-2 (subnet-2) ** # > > | > > # * * # > > | > > # * +----------+ * # > > | > > # * | Light-2 |-------+ * # > > | > > # * | | | * # > > | > > # * +----------+ +---------+ * # > > | > > # * | Rtr-2 > > |-----------------------------| > > # * +---------+ * # > > | > > # * +----------+ | * # > > | > > # * | Light-3 |--------+ * # > > | > > # * +----------+ * # > > | > > # * * # > > | > > # ** ** # > > | > > # ********************** # > > | > > # # > > | > > ################################################# > > | > > | > > +--------+ > > | > > | DNS > > |------------------| > > | Server | > > +--------+ > > Figure 2: Network Topology of a Large Room (Room-A) > > Rahman & Dijk Expires April 22, 2013 [Page > > 13] > > Internet-Draft Group Communication for CoAP October > > 2012 > > 4.3. Discovery of Resource Directory > > The protocol flow for discovery of a RD for the given network (of > > Figure 2) is shown in Figure 3: > > o The fixture for Light-2 is installed and powered on for the first > > time. > > o Light-2 will then search for the local RD (RD-2) by sending out a > > GET request (with the "/.well-known/core?rt=core.rd" request URI) > > to the site-local "All CoAP Nodes" address. In this case, the > > site is assumed to include all nodes in the subnet. > > o This multicast message will then go to each node in subnet-2. > > However, only Rtr-2 (RD-2) will respond because the GET is > > qualified by the query string "?rt=core.rd". > > o Note that the flow is shown only for Light-2 for clarity. > > Similar > > flows will happen for Light-1, Light-3 and the Light Switch when > > they are first powered on. > > The RD may also be discovered by other means such as by assuming a > > default location (e.g. on a 6LBR), using DHCP, anycast address, etc. > > However, these approaches do not invoke CoAP group communication so > > are not further discussed here. > > For other discovery use cases such as discovering local CoAP > > servers, > > services or resources group communication can be used in a similar > > fashion as in the above use case. Both Link-Local (LL) and site- > > local discovery are possible this way. > > /comment the RD discovery will be more complex when there is a router > > between light-2 and switch > > /comment Via which RD will light switch discover light-2? > > /comment additional reason to remove router from the multicast > > configuration > > Rahman & Dijk Expires April 22, 2013 [Page > > 14] > > Internet-Draft Group Communication for CoAP October > > 2012 > > Light Rtr-1 Rtr-2 > > Network > > Light-1 Light-2 Light-3 Switch (RD-1) (RD-2) > > Backbone > > | | | | | | | > > | | | | | | | > > ********************************** | | | > > * Light-2 is installed * | | | > > * and powers on for first time * | | | > > ********************************** | | | > > | | | | | | | > > | | | | | | | > > | | COAP NON (GET | | > > | | /.well-known/core?rt=core.rd) | | > > | |--------->-------------------------------->| | > > | | | | | | | > > | | | | | | | > > | | | | | | | > > | | COAP NON (2.05 Content | | > > | | ;rt="core.rd";ins="Primary") | | > > | |<------------------------------------------| | > > | | | | | | | > > Figure 3: Resource Directory Discovery via Multicast Message > > 4.4. Lighting Control > > /comment I am confused about the use of protocols > > /comment MLD is used to form groups, correct? > > /comment but that was already done by enabling the MC address in the > > lights (point 2) > > /comment There are several ways to set up groups, pointing them out > and > > when to use them would be an asset. > > The protocol flow for a building automation lighting control > > scenario > > for the network (Figure 2) is shown in sequence in Figure 4, > > Figure 5, and Figure 6. We assume the following steps occur before > > the illustrated flow: > > o 1) Startup phase: 6LoWPANs are formed. IPv6 addresses assigned > > to > > all devices. The CoAP network is formed. > > o 2) Commissioning phase (by applications): The IP multicast > > address > > of the group (Room-A-Lights) has been > > /s set /s enable > > in all the Lights. The > > URI of the group (Room-A-Lights) has been > > /s set /s resolved > > in the Light Switch. > > o 3) The indicated MLD Report messages are link-local multicast. > > In > > each LoWPAN, it is assumed that a multicast routing/forwarding > > protocol in 6LRs will then propagate the Join information > > contained in the MLD Report over multiple hops to the 6LBR. > > /comment Don't see the need > > Rahman & Dijk Expires April 22, 2013 [Page > > 15] > > Internet-Draft Group Communication for CoAP October > > 2012 > > Light Rtr-1 Rtr-2 > > Network > > Light-1 Light-2 Light-3 Switch (CoAP (CoAP > > Backbone > > | | | | Proxy) Proxy) | > > | | | | | | | > > | | | | | | | > > | MLD Report: Join | | | | | > > | Group (Room-A-Lights) | | | | > > |---LL------------------------------------->| | | > > | | | | |MLD Report: Join | > > | | | | |Group (Room-A-Lights)| > > | | | | |---LL--------------->| > > | | | | | | | > > | | MLD Report: Join | | | | > > | | Group (Room-A-Lights) | | | > > | |---LL------------------------------------->| | > > | | | | | | | > > | | | MLD Report: Join | | | > > | | | Group (Room-A-Lights) | | > > | | |---LL-------------------------->| | > > | | | | | | | > > | | | | |MLD Report: Join | > > | | | | |Group (Room-A-Lights)| > > | | | | | |---LL---->| > > | | | | | | | > > | | | | | | | > > Figure 4: Joining Lighting Groups Using MLD > > /comment possibly remove from text, or do separate section on use of > > MLD > > /comment anyway separating commissioning from operation in separate > > sections is a good idea. > > /comment the proxies are a complication in the picture not elaborated > > in the text. > > /comment the subject of proxies is another one, to be treated > > elsewhere. > > /comment also for proxies the do's and don't's from a simple > > performance perspective will be interesting > > Rahman & Dijk Expires April 22, 2013 [Page > > 16] > > Internet-Draft Group Communication for CoAP October > > 2012 > > Light Rtr-1 Rtr-2 > > Network > > Light-1 Light-2 Light-3 Switch (CoAP (CoAP > > Backbone > > | | | | Proxy) Proxy) | > > | | | | | | | > > | | *********************** | | > > | | * User flips on * | | > > | | * light switch to * | | > > | | * turn on all the * | | > > | | * lights in Room A * | | > > | | *********************** | | > > | | | | | | | > > | | | | | | | > > | | | COAP NON (PUT | | | > > | | | Proxy-URI | | | > > | | | URI for Room-A-Lights | > > | | | Payload=turn on lights) | > > | | | |--------->| | | > > | | | | | | | > > | | | | | | | > > | | | | Request DNS resolution of | > > | | | | URI for Room-A-Lights | > > | | | | |-------------------->| > > | | | | | | | > > | | | | | | | > > | | | | DNS returns: AAAA | > > | | | | Group (Room-A-Lights) | > > | | | | IPv6 multicast address | > > | | | | |<--------------------| > > | | | | | | | > > | | | | | | | > > | | | COAP NON (Put | > > | | | | URI Path | > > | | | | Payload=turn on lights)| > > | | | | Destination IP Address = | > > | | | | IP multicast address | > > | | | | for Group (Room-A-Lights)| > > | | | | Originating IP Address = | > > | | | | RTR-1 | > > | | | | |-------------------->| > > |<------------------------------------------| | | > > | | | | | | | > > | | | | | |<---------| > > | |<---------|<-------------------------------| | > > | | | | | | | > > | | | | | | | > > Figure 5: Sending Lighting Control Multicast Message > > Rahman & Dijk Expires April 22, 2013 [Page > > 17] > > Internet-Draft Group Communication for CoAP October > > 2012 > > Light Rtr-1 Rtr-2 > > Network > > Light-1 Light-2 Light-3 Switch (CoAP (CoAP > > Backbone > > | | | | Proxy) Proxy) | > > | | | | | | | > > *********************** | | | | > > * Lights in Room-A * | | | | > > * turn on (nearly * | | | | > > * simultaneously) * | | | | > > *********************** | | | | > > | | | | | | | > > | | | | | | | > > | COAP NON (2.04 Changed) | | | | > > |------------------------------------------>| | | > > | | | | | | | > > | | | | | | | > > | COAP NON (2.04 Changed) | | | > > | |------------------------------->| | | > > | | | | | | | > > | | | | | | | > > | | COAP NON (5.00 Internal Server Error) | > > | | |-------------------->| | | > > | | | | | | | > > | | | ****************************** | > > | | | * Rtr-1 as CoAP Proxy * | > > | | | * | sends the individual * | > > | | | * | responses back to * | > > | | | * v originator * | > > | | | ****************************** | > > | | | | | | | > > | | | COAP NON (2.04 Changed) | | > > | | | |<---------| | | > > | | | | | | | > > | | | COAP NON (2.04 Changed) | | > > | | | |<---------| | | > > | | | | | | | > > | | | COAP NON (5.00 Internal Server Error) | > > | | | |<---------| | | > > | | | | | | | > > Figure 6: Sending Lighting Control Response to Multicast Message > > NOTE: In the last step of Figure 6, Rtr-1 acting as CoAP proxy, > > returns multiple individual CoAP responses to the client. Each > > response echoes the Token of the client's request. The client can > > identify the original source of each response by ...TBD. > > /comment WHY are the multicast destinations sending back results? > > /comment I thought that you wanted MC messages to be non confirmable > > /comment sending responses seems to contradict this . > > /comment please remove sending back of responses. > > /comment one may assume that the MC algorithm within the lowpan is > > reliable (all destinations receive the message) > > /comment anyway MPL comes close enough to the reliability requirement > > given a specifiable range of configurations > > ___________________________________________________________________________________________________________________________ > > > -- > > Peter van der Stok > > mailto: consultancy@vanderstok.org > > www: www.vanderstok.org [3] > > tel NL: +31(0)492474673 F: +33(0)966015248 > > ------------------------- > The information contained in this message may be confidential and > legally protected under applicable law. The message is intended solely > for the addressee(s). If you are not the intended recipient, you are > hereby notified that any use, forwarding, dissemination, or > reproduction of this message is strictly prohibited and may be > unlawful. If you are not the intended recipient, please contact the > sender by return e-mail and destroy all copies of the original > message. > > > Links: > ------ > [1] http://datatracker.ietf.org/drafts/current/ > [2] http://trustee.ietf.org/license-info > [3] http://www.vanderstok.org From esko.dijk@philips.com Thu Dec 20 02:56:18 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CB2E21F880C for ; Thu, 20 Dec 2012 02:56:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.499 X-Spam-Level: X-Spam-Status: No, score=-4.499 tagged_above=-999 required=5 tests=[AWL=-2.100, BAYES_00=-2.599, J_CHICKENPOX_64=0.6, J_CHICKENPOX_74=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LL85DvjF5wbC for ; Thu, 20 Dec 2012 02:56:15 -0800 (PST) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe004.messaging.microsoft.com [216.32.180.14]) by ietfa.amsl.com (Postfix) with ESMTP id 4819221F85D9 for ; Thu, 20 Dec 2012 02:56:13 -0800 (PST) Received: from mail119-va3-R.bigfish.com (10.7.14.235) by VA3EHSOBE001.bigfish.com (10.7.40.21) with Microsoft SMTP Server id 14.1.225.23; Thu, 20 Dec 2012 10:56:12 +0000 Received: from mail119-va3 (localhost [127.0.0.1]) by mail119-va3-R.bigfish.com (Postfix) with ESMTP id 11D9D100095; Thu, 20 Dec 2012 10:56:12 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.55.7.222; KIP:(null); UIP:(null); IPV:NLI; H:mail.philips.com; RD:none; EFVD:NLI X-SpamScore: -46 X-BigFish: VPS-46(zz217bI15d6O9251Jc89bhd6eah936eI1102I542I1432I1418I328cM179dNzz1de0h1202h1e76h1d1ah1d2ahzz1033IL1954cbh17326ah18602eh8275bh8275dhz2dh2a8h668h839h93fhd25hf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h1155h) Received: from mail119-va3 (localhost.localdomain [127.0.0.1]) by mail119-va3 (MessageSwitch) id 13560009676095_23367; Thu, 20 Dec 2012 10:56:07 +0000 (UTC) Received: from VA3EHSMHS004.bigfish.com (unknown [10.7.14.247]) by mail119-va3.bigfish.com (Postfix) with ESMTP id ED4E4400BB; Thu, 20 Dec 2012 10:56:06 +0000 (UTC) Received: from mail.philips.com (157.55.7.222) by VA3EHSMHS004.bigfish.com (10.7.99.14) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 20 Dec 2012 10:56:06 +0000 Received: from 011-DB3MPN2-083.MGDPHG.emi.philips.com ([169.254.3.34]) by 011-DB3MMR1-006.MGDPHG.emi.philips.com ([10.128.28.56]) with mapi id 14.02.0318.003; Thu, 20 Dec 2012 10:56:04 +0000 From: "Dijk, Esko" To: "consultancy@vanderstok.org" Thread-Topic: group-comm comments Thread-Index: AQHN3Q/EamfaSRtiukaKyou8LL6fj5ggEhMAgAFsuoCAAAIesA== Date: Thu, 20 Dec 2012 10:56:03 +0000 Message-ID: <031DD135F9160444ABBE3B0C36CED618B40B66@011-DB3MPN2-083.MGDPHG.emi.philips.com> References: <031DD135F9160444ABBE3B0C36CED618B39574@011-DB3MPN2-082.MGDPHG.emi.philips.com> <8dd1c4cf0ca945d6059c24a988d3996b@xs4all.nl> In-Reply-To: <8dd1c4cf0ca945d6059c24a988d3996b@xs4all.nl> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.138.224.32] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: philips.com Cc: Core Subject: Re: [core] group-comm comments X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 20 Dec 2012 10:56:18 -0000 VGhhbmtzIFBldGVyLA0KDQpJIHdvdWxkIGFncmVlIHdlIG5lZWQgdG8gaW5jbHVkZSBndWlkZWxp bmVzIG9uIHJldHVybmluZyBvZiByZXNwb25zZXMgdG8gQ29BUCBtdWx0aWNhc3QgcmVxdWVzdHMu IChOb3RlIHRoZSBDb0FQIHNwZWMgZW5zdXJlcyB0aGF0IGEgQ29BUCBzZXJ2ZXIgd2lsbCBuZXZl ciBBQ0sgYSBtdWx0aWNhc3QgYnV0IHRoYXQgZG9lcyBub3QgaGVscCBhIHRoaW5nIGlmIGl0IHN0 aWxsIHNlbmRzIGEgcmVzcG9uc2UgcGFja2V0Li4uKSBJJ2xsIG1ha2UgYSB0aWNrZXQgZm9yIHRo aXMuIElmIGFueW9uZSBkaXNhZ3JlZXMgd2UnbGwgaGVhciBpdC4NCg0KPiBUaGVuIEkgZG8gbm90 IHVuZGVyc3RhbmQgdGhlIHRleHQsIGJlY2F1c2UgInJlcXVlc3QiLCAicmVwbHkiIGFuZCAicmVz cG9uc2UiIGFyZSBvdmVybG9hZGVkIGluIG15IG1pbmQuDQpUbyBjbGFyaWZ5OiB1bmRlciB0aGUg YXNzdW1wdGlvbiB0aGF0IGEgc2VydmVyIE1BWSByZXNwb25kIHRvIGEgbXVsdGljYXN0IHJlcXVl c3QsIGFuZCB0aGUgY2xpZW50IGRvZXNuJ3Qga25vdyBhIHByaW9yaSBob3cgbWFueSBzZXJ2ZXJz IHdpbGwgcmVzcG9uZCB0byBhIG11bHRpY2FzdCwgKHNpbmNlIHRoZXJlIGFyZSBubyBndWlkZWxp bmVzL3J1bGVzIGZvciB0aGF0KSwgdGhlIHNhZmVzdCB0aGluZyB0byBkbyBpcyBub3Qgc2VuZCB0 aGUgbXVsdGljYXN0IGluIHRoZSBmaXJzdCBwbGFjZS4gVGhlcmVmb3JlIHRoZSBhZHZpY2UgaXMg dG8gY2FyZWZ1bGx5IGNvbnRyb2wgc2VuZGluZyBvZiBtdWx0aWNhc3QgcmVxdWVzdHMuDQoNCkVz a28NCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IHBldGVyIHZhbiBkZXIgU3Rv ayBbbWFpbHRvOnN0b2tjb25zQHhzNGFsbC5ubF0NClNlbnQ6IFRodXJzZGF5IDIwIERlY2VtYmVy IDIwMTIgMTE6MjYNClRvOiBEaWprLCBFc2tvDQpDYzogY29uc3VsdGFuY3lAdmFuZGVyc3Rvay5v cmc7IGFrYmFyIHJhaG1hbjsgQ29yZQ0KU3ViamVjdDogUkU6IGdyb3VwLWNvbW0gY29tbWVudHMN Cg0KDQpIaSBFc2tvLA0KDQp0aGFua3MgZm9yIHlvdXIgcmVhY3Rpb25zLiBJIHdpbGwgZ3JvdXAg bXkgYW5zd2VycywgdG8gYmV0dGVyIGV4cGxhaW4gbXkgcG9pbnRzIG9uIHRoZSByZXR1cm4gb2Yg cGFja2V0cyB0byBNQyBzZW5kZXJzLg0KDQoxKSBSZXR1cm4gb2YgcGFja2V0cyB0byBtdWx0aWNh c3QNCg0KQXMgSSB1bmRlcnN0YW5kIHRoZSBtdWx0aWNhc3QgbWVzc2FnZSBpcyBwcmVmZXJhYmx5 IHNlbnQgd2l0aCBubyBjb25maXJtYXRpb24gKGFjaykgYmVjYXVzZSB0aGUgcmV0dXJuIG9mIGFs bCB0aGUgYWNrcyBtYXkgb3ZlcndoZWxtIHRoZSBuZXR3b3JrIGFuZCB0aGUgc2VuZGVyIG9mIHRo ZSBtdWx0aWNhc3QuDQpUaGUgYWNrbm93bGVkZ2VtZW50IGlzIG5vdCBuZWVkZWQgZm9yIE1QTCBh cyB0aGUgcHJvdG9jb2wgaGFzIGFsbCB0aGUgbWFjaGluZXJ5IHRvIGFzc3VyZSB0aGF0IGFsbCBk ZXN0aW5hdGlvbnMgcmVjZWl2ZSBpdCwgKGdpdmVuIGNvbnN0cmFpbnRzIG9uIG5ldHdvcmsgbG9h ZCBhbmQgY29uZmlndXJhdGlvbiBkZW5zaXR5IGFuZCBzaXplKS4NCg0KU3VwcG9zaW5nIGFuIGFj ayBpcyBuZWVkZWQsIHRoZW4gaXQgd291bGQgYmUgYWR2aXNhYmxlIHRvIHN0YWZmbGUgdGhlIHJl c3BvbnNlcyBhbmQgYW4gYWRkaXRpb25hbCBhY2tub3dsZWRnZW1lbnQgcHJvdG9jb2wgY291bGQg YmUgYWRkZWQgdG8gdGhlIG11bHRpY2FzdCBwcm90b2NvbC4gVGhlIHNhbWUgaXMgdHJ1ZSBpZiBh IG1lc3NhZ2UgaXMgcmV0dXJuZWQgKGFzIGluIHRoZSBjYXNlIG9mIG1ETlMpLg0KDQpPbmUgY2Fu IHRoZW4gd29uZGVyIHdoZXRoZXIgdGhlIGFwcGxpY2F0aW9uIHByb3RvY29sIChlLmcuIG1ETlMp IHNob3VsZCB0YWtlIGNhcmUgb2YgdGhlIHN0YWZmbGVkIHJlc3BvbnNlIG9yIHRoYXQgYW4gYWRk aXRpb25hbCBwcm90b2NvbCBuZWVkcyB0byBiZSBzcGVjaWZpZWQuDQpJIGhhdmUgbm8gb3Bpbmlv biBvbiB0aGUgY2hvaWNlLCBidXQgc2VlIHRoZSBuZWVkIGZvciB0aGUgb25lIG9yIHRoZSBvdGhl ci4gQ29taW5nIHdpdGggYSByZWNvbW1lbmRhdGlvbiAoZXhwbGFuYXRpb24pIG9uIHRoZSBzdWJq ZWN0IG9mIHJldHVybmluZyByZXNwb25zZXMgKGFja3MpIHdvdWxkIGJlIG15IHJlY29tbWVuZGF0 aW9uIGZvciB0aGUgR3JvdXBDb21tIGRvY3VtZW50Lg0KDQpCZWxvdyBzb21lIHJlYWN0aW9ucyBv biB5b3VyIHJlYWN0aW9ucy4gSG9wZSB0aGlzIGhlbHBzIHRvIGNsYXJpZnkgbWlzdW5kZXJzdGFu ZGluZ3MuDQoNClBldGVyDQoNCkRpamssIEVza28gc2NocmVlZiBvcCAyMDEyLTEyLTE5IDE0OjI0 Og0KPiBIaSBQZXRlciwNCj4NCj4gc3RpbGwgYSBmYWlyIG51bWJlciBvZiBjb21tZW50cyEgSSB3 b3VsZCBhZ3JlZSB3aXRoIG1vc3QuIEJlbG93IEkgaGF2ZQ0KPiBzZWxlY3RlZCBzb21lIHdoaWNo IHdlIHNob3VsZCBkaXNjdXNzIGZ1cnRoZXIsIG9yIG9uZXMgSSBkb27igJl0IGFncmVlDQo+IHdp dGg6DQo+DQo+IDEuIEdyb3VwIGNvbW11bmljYXRpb24gZGVmaW5pdGlvbiAtPg0KPiAgV2h5IGNh bid0IGEgc291cmNlIG5vZGUgYmUgcGFydCBvZiB0aGUgZ3JvdXAgdGhhdCBpdCBzZW5kcyB0bz8g RS5nLg0KPiBjb21iaW5lZCBzZW5zb3IrbHVtaW5haXJlIHVzZSBjYXNlLiBUaGUgSVAgc3RhY2sg d291bGQgZGVsaXZlciBzZW50DQo+IG11bHRpY2FzdCBDb0FQIHJlcXVlc3RzIGFsc28gdG8gdGhl IGxvY2FsIGFwcGxpY2F0aW9uIGlmIGl0IGlzDQo+IHN1YnNjcmliZWQgdG8gdGhlIG11bHRpY2Fz dCBJUCBhZGRyZXNzLg0Kc291cmNlIGNhbiBvZiBjb3Vyc2UgYmUgbWVtYmVyIG9mIGRlc3RpbmF0 aW9uIGdyb3VwLg0Kc291cmNlIG1heSBiZSBwYXJ0IG9mIHRoZSBncm91cCAocmVtb3ZlIHRoZSAi b3IgbWF5IGJlIG5vdCIgcGFydCBvZiB0aGUNCnBocmFzZSkNCj4NCj4gMi4gSSBkb27igJl0IHNl ZSB3aHkgd2Ugc2hvdWxkIGFkZCDigJx0aGUgdXNlIG9mIGdyb3VwIGNvbW11bmljYXRpb24gZm9y DQo+IG1ETlMgaXMgb3V0IG9mIHNjb3BlLuKAnSAtPiAgbUROUyBvYnZpb3VzbHkgaXMgbm90IENv QVAsIGFuZCB0aGUNCj4gZG9jdW1lbnQgc2hvdWxkIGRlZmluZSB0aGUgc2NvcGUgYW55d2F5IGNs ZWFybHkgYXMgQ29BUCBncm91cA0KPiBjb21tdW5pY2F0aW9uLiBTbyB3ZSBkb27igJl0IGhhdmUg dG8gbGlzdCBhbnkgb3RoZXIgcHJvdG9jb2xzIHRoYW4gQ29BUC4NClNlZSBteSBhbnN3ZXIgb24g cmV0dXJuIG9mIHBhY2tldHMuIEkgd2FudGVkIGEgY2xlYXIgc3RhdGVtZW50IG9uIChOT1QpIHNw ZWNpZnlpbmcgaG93IGFwcGxpY2F0aW9ucyBoYW5kbGUgdGhlIHJldHVybiBvZiBNQyByZXNwb25z ZXMuDQoNCj4NCj4gMy4g4oCcc28gc2V0dGluZyBhIG11bHRpY2FzdCBhZGRyZXNzIGluIGEgc291 cmNlIGF0IGluc3RhbGxhdGlvbiBpcw0KPiBmb3JiaWRkZW4/4oCdIC0+ICBObywgdGhhdCBzaG91 bGQgbm90IGJlIGZvcmJpZGRlbiA6KSBJdCBzaG91bGQgYWxzbyBiZQ0KPiBwb3NzaWJsZSB0byBz ZXQgYSBDb0FQIHBhdGggYW5kL29yIHBvcnQgYXQgaW5zdGFsbGF0aW9uIHRpbWUuIFRoYXQNCj4g bWVhbnMgdGhlIHR3byBwcmVzZW50ZWQgbWVhc3VyZXMgaGF2ZSB0byBjaGFuZ2Ugb3IgYmUgcmVt b3ZlZC4NCk5vIGNvbW1lbnQNCj4NCj4gNC4g4oCcdGhlcmUgYXJlIDIgd2F5czogKDEpIHRoZSBu b2RlIHF1ZXJpZXMgdG8gd2hpY2ggZ3JvdXAgaXQgYmVsb25ncw0KPiBvciAoMikgYW4gaW5zdGFs YXRpb24gdG9vbHMgaW5zdHJ1Y3RzIHRoZSBub2RlIHRvIHdoaWNoIGdyb3Vwc+KAnSAtPg0KPiBH b29kIHBvaW50LiAoMikgaGFzIGJlZW4gY2hvc2VuIGJlY2F1c2UgaXQgd29ya3Mgd2l0aG91dCBy ZWx5aW5nIG9uIGENCj4gc2VydmljZSB0byBxdWVyeSAoZS5nLiBETlMgb3IgUkQpLiBJcyB0aGF0 IHN1ZmZpY2llbnQgYXJndW1lbnRhdGlvbj8NCj4gVGhlIG1lY2hhbmlzbSBpcyBvcHRpb25hbCBp biBhbnkgY2FzZSBzbyBpdCBkb2VzIG5vdCBibG9jayBvdGhlcnMgZnJvbQ0KPiBkZWZpbmluZyBh IEROUyBvciBSRCB2YXJpYW50Lg0KSSB3b3VsZCBwb2ludCBvdXQgYm90aCB2YXJpYW50cyBhbmQg bWVudGlvbiB0aGF0IHRoZSBkcmFmdCBmb2N1c3NlcyBvbg0KKDIpDQo+DQo+IDUuIOKAnC9zIHJl cXVlc3RzIC9zIHJlcGxpZXPigJ0gLT4NCj4gIG11bHRpY2FzdCByZXBsaWVzIChpZiB5b3UgbWVh biByZXNwb25zZXMpIGRvIG5vdCBleGlzdCBpbiBDb0FQLiBJdOKAmXMNCj4gYWJvdXQgcmVxdWVz dHMgdGhhdCBzaG91bGQgYmUgY2FyZWZ1bGx5IGNvbnRyb2xsZWQgc2luY2UgdGhleSBnZW5lcmF0 ZQ0KPiB1bmljYXN0IHJlc3BvbnNlcy4NClRoZW4gSSBkbyBub3QgdW5kZXJzdGFuZCB0aGUgdGV4 dCwgYmVjYXVzZSAicmVxdWVzdCIsICJyZXBseSIgYW5kICJyZXNwb25zZSIgYXJlIG92ZXJsb2Fk ZWQgaW4gbXkgbWluZC4NCj4NCj4gNi4g4oCcL2NvbW1lbnQgd2hhdCBhYm91dCB0aGUgcmVwbHk/ 4oCdIC0+ICBiYXNlZCBvbiBjb3JlLWNvYXAg4oCcSWYgdGhlDQo+IHJlcXVlc3QgbWVzc2FnZSBp cyBOb24tY29uZmlybWFibGUsIHRoZW4gdGhlIHJlc3BvbnNlIFNIT1VMRCBiZQ0KPiByZXR1cm5l ZCBpbiBhIE5vbi1jb25maXJtYWJsZSBtZXNzYWdlIGFzIHdlbGwu4oCdDQo+IC4gRG8geW91IHRo aW5rIHdlIHNob3VsZCBxdW90ZSB0aGlzIGZyb20gdGhlIGNvcmUtY29hcCBzcGVjPw0KQXMgZXhw bGFpbmVkIGFib3ZlIFRoZSBzdWJqZWN0IG9mIHJldHVybmluZyBwYWNrZXRzIHRvIHRoZSBNQyBz ZW5kZXIgbmVlZHMgY2FyZWZ1bCBjb25zaWRlcmF0aW9uLg0KdGhlIHJlc3BvbnNlIGJlaW5nIE5P bi1jb25maXJtYWJsZSBkb2VzIG5vdCBzb2x2ZSBhIGxvdCBJIGFtIGFmcmFpZC4NCj4NCj4gNy4g 4oCcL2NvbW1lbnQgaW52b2tpbmcgYXMgbWFueSBjZXJ0aWZpY2F0ZXM/4oCdIC0+DQo+ICBjb3Jl LWNvYXAtMTMgbm93IGxvb3NlbnMgdGhlIGNvbmNlcHQgb2YgYXV0aGVudGljYXRpb24gdG8gYWxz bw0KPiBpbmNsdWRlIG90aGVyIG1lYXN1cmVzLCBub3QgbmVlZGluZyBjZXJ0aWZpY2F0ZXMuDQpO byBjb21tZW50DQo+DQo+IDguIE5ldHdvcmsgY29uZmlndXJhdGlvbjogMiBzdWJuZXRzIHZzIDEg LT4gIG1heWJlIGEgb25lLXN1Ym5ldA0KPiBjb25maWd1cmF0aW9uIGlzIHdvcnRoIGFkZGluZz8g SGVyZSBhbiBvdmVydmlldyBvZiBwcmVzZW50L2Fic2VudCB1c2UNCj4gY2FzZXM6DQo+DQo+ICAt IExpbmstbG9jYWwgQ29BUCBtdWx0aWNhc3Qgd2l0aCByZXNwb25zZXM6IFByZXNlbnQsIEFwcGVu ZGl4IEEgb2YNCj4gY29yZS1jb2FwDQo+ICAtIFNpdGUtbG9jYWwgQ29BUCBtdWx0aWNhc3QsIHNp bmdsZSBzdWJuZXQ6IDxtaXNzaW5nPg0KPiAgLSBTaXRlLWxvY2FsIENvQVAgbXVsdGljYXN0LCBt dWx0aSBzdWJuZXQsIHdpdGggb3Igd2l0aG91dCByZXNwb25zZXMNCj4gKGluIHRoZSBuZXcgLTA0 IGdyb3VwY29tbSk6IFByZXNlbnQNCj4gIC0gR2xvYmFsIENvQVAgbXVsdGljYXN0LCBzaW5nbGUg b3IgbXVsdGkgc3VibmV0LCB3aXRoIG9yIHdpdGhvdXQNCj4gcmVzcG9uc2VzOiA8bWlzc2luZz4g LyBkZXBlbmRlbmN5IG9uIElBTkEgSVB2NiBhbGxvY2F0aW9uDQo+ICAtIGFueSBjb25maWd1cmF0 aW9ucyB3aXRoIGEgY2VudHJhbCBjb250cm9sbGVyIG9uIHRoZSBiYWNrYm9uZQ0KPiBtdWx0aWNh c3Rpbmc6IDxtaXNzaW5nPg0KDQpBZ2FpbiwgdGhlIGRyYWZ0IHNob3VsZCBnbyBmb3IgdGhlIG1v c3QgZnJlcXVlbnQgdXNlIGNhc2VzIGFuZCBub3QgdHJ5IHRvIGJlIGNvbXBsZXRlLg0KQWN0dWFs bHkgZXhwbGljaXRseSBleGNsdWRpbmcgdXNlIGNhc2VzIGxvb2tzIGluZXJlc3RpbmcgdG8gbWUu DQo+DQo+IDkuIOKAnEl0IG1pZ2h0IGJlIHVzZWZ1bCBpZiB0aGUgcHJhY3RpY2FsIGltcG9zc2li aWxpdHkgb2Ygc29tZQ0KPiBjb25maWd1cmF0aW9ucyBpcyBoaWdoIGxpZ2h0ZWTigJ0gLT4gIGFu eSB0aG91Z2h0cywgd2hpY2ggd291bGQgYmUNCj4gaW1wb3NzaWJsZT8NCkR1cmluZyB0aGUgY29h cCBtZWV0aW5nIGluIEF0bGFudGEsIEN1bGxlbiBKZW5uaW5ncyBwcmVzZW50ZWQgc29tZSBob3Jy aWZ5aW5nIGV4YW1wbGVzLCBhcyBmYXIgYXMgSSByZW1lbWJlci4NCg0KPg0KPiAxMC7igJx0aGUg UkQgZGlzY292ZXJ5IHdpbGwgYmUgbW9yZSBjb21wbGV4IHdoZW4gdGhlcmUgaXMgYSByb3V0ZXIN Cj4gYmV0d2VlbiBsaWdodC0yIGFuZCBzd2l0Y2jigJ0gLT4gIHllcywgdGhlcmUgYXJlIGlzc3Vl cyBpbiBSRC9kaXNjb3ZlcnkNCj4gZXNwZWNpYWxseSB3aGVuIG1vcmUgdGhhbiBvbmUgaXMgcHJl c2VudCBpbiBhIG5ldHdvcmsuDQpTbywgYWRhcHQgdGhlIHVzZSBjYXNlIGFuZCBleGNsdWRlIHRo aXMgcG9zc2liaWxpdHkuDQo+DQo+IDExLuKAnGFkZGl0aW9uYWwgcmVhc29uIHRvIHJlbW92ZSBy b3V0ZXIgZnJvbSB0aGUgbXVsdGljYXN0DQo+IGNvbmZpZ3VyYXRpb27igJ0tPiAgaG1tLCBJIHRo aW5rIHRoYXQgd2Ugc2hvdWxkIG9wdCBmb3IgaGF2aW5nIGEgc2luZ2xlDQo+IFJEIGluIHRoZSBz eXN0ZW0gdG8gYXZvaWQgY29tcGxleGl0eS4gUm91dGVycyBhcmUgb2suIChPbmUgb2Ygb3VyDQo+ IGdvYWxzIGlzIHRvIGRlZmluZSBob3cgQ29BUCBncm91cGNvbW0gd29ya3MgZXZlbiBhY3Jvc3Mg cm91dGVycykNCkxvb2tpbmcgZm9yd2FyZCB0byB0aGUgc3VwcG9ydGluZyBwcm90b2NvbC4NCj4N Cj4gMTIu4oCcTUxEIGlzIHVzZWQgdG8gZm9ybSBncm91cHMsIGNvcnJlY3Q/IGJ1dCB0aGF0IHdh cyBhbHJlYWR5IGRvbmUgYnkNCj4gZW5hYmxpbmcgdGhlIE1DIGFkZHJlc3MgaW4gdGhlIGxpZ2h0 cyAocG9pbnQgMinigJ0gLT4gIFN0ZXAgMSBpcyBwdXR0aW5nDQo+IHRoZSBNQyBhZGRyZXNzIGlu IHRoZSBsaWdodHMsIHRoZW4gc3RlcCAyIGlzIHRoZSBMaWdodHMgdXNlIE1MRCB0bw0KPiAqQURW RVJUSVpFKiB0aGlzIGFkZHJlc3MgdG8gYW55IE1MRC1lbmFibGVkIFJvdXRlcnMgcHJlc2VudA0K PiBsaW5rLWxvY2FsLg0KPiAgU28gTUxEIGlzIG5vdCBhIGNvbW1pc3Npb25pbmctdGltZSBwcm90 b2NvbCBidXQgcnVucyBhbGwgdGhlIHRpbWUNCj4gZHVyaW5nIG9wZXJhdGlvbi4NCj4gIE5vdGUg dGhhdCBpbiBncm91cGNvbW0gLTA0IHdlIHdpbGwgcmVtb3ZlIE1MRCBpbiB0aGUgYmFzaWMgdXNl IGNhc2UNCj4gYW5kIHByZXNlbnQgaXQgYXMgYW4gb3B0aW9uIGxhdGVyLg0KDQpTb3VuZHMgZ29v ZC4gVGhlIHBvaW50IGlzIG5vdCB0byBhZGQgcHJvdG9jb2xzIGJlY2F1c2UgdGhleSBleGlzdCBi dXQgYmVjYXVzZSB0aGV5IGFyZSBuZWVkZWQuDQo+DQo+IDEzLuKAnFdIWSBhcmUgdGhlIG11bHRp Y2FzdCBkZXN0aW5hdGlvbnMgc2VuZGluZyBiYWNrIHJlc3VsdHM/4oCdIC0+ICB3ZQ0KPiByZW1v dmUgcmVzcG9uc2VzIGluIHRoZSBuZXcgLTA0IGdyb3VwY29tbS4gVGhleSBhcmUgcHJlc2VudGVk IGFzIGFuDQo+IG9wdGlvbmFsIHRoaW5nIHRoYXQgc2VydmVycyBjYW4gZG8uDQo+ICBDb0FQIHNl cnZlcnMgbm9ybWFsbHkgTVVTVCByZXNwb25kIHRvIGEgcmVxdWVzdCB3aXRoIGEgcmVzcG9uc2UN Cj4gKGNvcmUtY29hcC0xMykgYnV0IGFuIGV4Y2VwdGlvbiBpcyBub3cgbWFkZSBmb3IgbXVsdGlj YXN0IHdoZXJlIGENCj4gc2VydmVyIE1BWSBjaG9vc2Ugbm90IHRvLiBUaGlzIGNob2ljZSBpcyBj b21wbGV0ZWx5IGluZGVwZW5kZW50IGZyb20NCj4gY29uZmlybWFibGUvbm9uLWNvbmZpcm1hYmxl LiBOb24tY29uZmlybWFibGUgb25seSBtZWFucyB0aGF0IGFuIEFDSw0KPiBtdXN0IG5vdCBiZSBz ZW50LiBBbmQgYW4gQUNLIGlzIHNvbWV0aGluZyBkaWZmZXJlbnQgZnJvbSBhIENvQVANCj4gcmVz cG9uc2UuDQo+ICBBZ3JlZSB0aGF0IGEgcHJvdG9jb2wgbGlrZSBNUEwgY29tZXMgdmVyeSBjbG9z ZSB0byDigJhyZWxpYWJsZQ0KPiBtdWx0aWNhc3TigJkuDQoNCnNlZSBteSB3b3JyaWVzIGF0IHRo ZSBiZWdpbm5pbmcuDQo+DQo+IEVza28NCj4NCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N Cj4gIEZyb206IHBldGVyIHZhbiBkZXIgU3RvayBbbWFpbHRvOnN0b2tjb25zQHhzNGFsbC5ubF0N Cj4gIFNlbnQ6IFR1ZXNkYXkgMTggRGVjZW1iZXIgMjAxMiAxMjowNg0KPiAgVG86IGFrYmFyIHJh aG1hbjsgRGlqaywgRXNrbzsgQ29yZQ0KPiAgU3ViamVjdDogZ3JvdXAtY29tbSBjb21tZW50cw0K Pg0KPiBIaSBBa2JhciBhbmQgRXNrbywNCj4NCj4gSSBoYWQgcHJvbWlzZWQgdG8gcmV2aWV3LCBj b21tZW50IHRoZSBncm91cCBjb21tIGRyYWZ0Lg0KPg0KPiBCZWxvdyB0aGUgY29tbWVudGVkIHRl eHQuDQo+DQo+IEkgaGF2ZSBub3QgZ29uZSB2ZXJ5IGRldGFpbGVkIHdpdGggbXkgY29tbWVudHMu IEkgaG9wZSB0aGF0IGl0IGlzDQo+IGNsZWFyIGZyb20gbXkgY29tbWVudHMgdGhhdCBhIHJlb3Jn YW5pemF0aW9uIG9mIHRoZSBkcmFmdCBhbmQgYSByZXZpZXcNCj4gb2YgdGhlIHVzZXMgY2FzZXMg YXJlIG5lY2Vzc2FyeSB0byBnZXQgYSBjbGVhcmVyIHBpY3R1cmUgb2YgdGhlDQo+IGZlYXNpYmls aXR5IG9mIGdyb3VwIGNvbW0gaW4gdGhlIGNvbnRleHQgb2YgQ29hcC4NCj4NCj4gRXNwZWNpYWx5 IGRpZmZpY3VsdCB0byB1bmRlcnN0YW5kIGZvciBtZSB3ZXJlOg0KPg0KPiAtIHRoZSB1c2UgY2Fz ZSBuZXR3b3JrIGNvbmZpZ3VyYXRpb24NCj4NCj4gLSB0aGUgZm9ybWluZyBhbmQgZW5hYmxpbmcg b2YgZ3JvdXBzDQo+DQo+IC0gdXNlIG9mIHJlc3BvbnNlcw0KPg0KPiBIb3BlIHRoaXMgaGVscHMu DQo+DQo+IEdyZWV0aW5ncywNCj4NCj4gcGV0ZXINCj4NCj4gX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+DQo+DQo+IEFic3RyYWN0DQo+DQo+ICBDb0FQ IGlzIGEgUkVTVGZ1bCB0cmFuc2ZlciBwcm90b2NvbCBmb3IgY29uc3RyYWluZWQgZGV2aWNlcy4g SXQgaXMNCj4NCj4gIGFudGljaXBhdGVkIHRoYXQgY29uc3RyYWluZWQgZGV2aWNlcyB3aWxsIG9m dGVuIG5hdHVyYWxseSBvcGVyYXRlIGluDQo+DQo+ICBncm91cHMgKGUuZy4gaW4gYSBidWlsZGlu ZyBhdXRvbWF0aW9uIHNjZW5hcmlvIGFsbCBsaWdodHMgaW4gYSBnaXZlbg0KPg0KPiAgcm9vbSBt YXkgbmVlZCB0byBiZSBzd2l0Y2hlZCBvbi9vZmYgYXMgYSBncm91cCkuIFRoaXMgZG9jdW1lbnQN Cj4NCj4gIGRlZmluZXMgaG93IHRoZSBDb0FQIHByb3RvY29sIHNob3VsZCBiZSB1c2VkIGluIGEg Z3JvdXAgY29tbXVuaWNhdGlvbg0KPg0KPiAgY29udGV4dC4gQW4gYXBwcm9hY2ggZm9yIHVzaW5n IENvQVAgb24gdG9wIG9mIElQIG11bHRpY2FzdCBpcw0KPg0KPiAgZGV0YWlsZWQgZm9yIGJvdGgg Y29uc3RyYWluZWQgYW5kIHVuLWNvbnN0cmFpbmVkIG5ldHdvcmtzLiBBbHNvLA0KPg0KPiAgdmFy aW91cyB1c2UNCj4NCj4gL3MgY2F1c2VzIC9zIGNhc2VzLw0KPg0KPiAgYW5kIGNvcnJlc3BvbmRp bmcgcHJvdG9jb2wgZmxvd3MgYXJlIHByb3ZpZGVkIHRvDQo+DQo+ICBpbGx1c3RyYXRlIGltcG9y dGFudCBjb25jZXB0cy4gRmluYWxseSwgZ3VpZGFuY2UgaXMgcHJvdmlkZWQgZm9yDQo+DQo+ICBk ZXBsb3ltZW50IGluIHZhcmlvdXMgbmV0d29yayB0b3BvbG9naWVzLg0KPg0KPiBTdGF0dXMgb2Yg dGhpcyBNZW1vDQo+DQo+ICBUaGlzIEludGVybmV0LURyYWZ0IGlzIHN1Ym1pdHRlZCBpbiBmdWxs IGNvbmZvcm1hbmNlIHdpdGggdGhlDQo+DQo+ICBwcm92aXNpb25zIG9mIEJDUCA3OCBhbmQgQkNQ IDc5Lg0KPg0KPiAgSW50ZXJuZXQtRHJhZnRzIGFyZSB3b3JraW5nIGRvY3VtZW50cyBvZiB0aGUg SW50ZXJuZXQgRW5naW5lZXJpbmcNCj4NCj4gIFRhc2sgRm9yY2UgKElFVEYpLiBOb3RlIHRoYXQg b3RoZXIgZ3JvdXBzIG1heSBhbHNvIGRpc3RyaWJ1dGUNCj4NCj4gIHdvcmtpbmcgZG9jdW1lbnRz IGFzIEludGVybmV0LURyYWZ0cy4gVGhlIGxpc3Qgb2YgY3VycmVudCBJbnRlcm5ldC0NCj4NCj4g IERyYWZ0cyBpcyBhdCBodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZHJhZnRzL2N1cnJlbnQv IFsxXS4NCj4NCj4gIEludGVybmV0LURyYWZ0cyBhcmUgZHJhZnQgZG9jdW1lbnRzIHZhbGlkIGZv ciBhIG1heGltdW0gb2Ygc2l4IG1vbnRocw0KPg0KPiAgYW5kIG1heSBiZSB1cGRhdGVkLCByZXBs YWNlZCwgb3Igb2Jzb2xldGVkIGJ5IG90aGVyIGRvY3VtZW50cyBhdCBhbnkNCj4NCj4gIHRpbWUu IEl0IGlzIGluYXBwcm9wcmlhdGUgdG8gdXNlIEludGVybmV0LURyYWZ0cyBhcyByZWZlcmVuY2UN Cj4NCj4gIG1hdGVyaWFsIG9yIHRvIGNpdGUgdGhlbSBvdGhlciB0aGFuIGFzICJ3b3JrIGluIHBy b2dyZXNzLiINCj4NCj4gIFRoaXMgSW50ZXJuZXQtRHJhZnQgd2lsbCBleHBpcmUgb24gQXByaWwg MjIsIDIwMTMuDQo+DQo+IENvcHlyaWdodCBOb3RpY2UNCj4NCj4gIENvcHlyaWdodCAoYykgMjAx MiBJRVRGIFRydXN0IGFuZCB0aGUgcGVyc29ucyBpZGVudGlmaWVkIGFzIHRoZQ0KPg0KPiAgZG9j dW1lbnQgYXV0aG9ycy4gQWxsIHJpZ2h0cyByZXNlcnZlZC4NCj4NCj4gIFRoaXMgZG9jdW1lbnQg aXMgc3ViamVjdCB0byBCQ1AgNzggYW5kIHRoZSBJRVRGIFRydXN0J3MgTGVnYWwNCj4NCj4gIFBy b3Zpc2lvbnMgUmVsYXRpbmcgdG8gSUVURiBEb2N1bWVudHMNCj4NCj4gIChodHRwOi8vdHJ1c3Rl ZS5pZXRmLm9yZy9saWNlbnNlLWluZm8gWzJdKSBpbiBlZmZlY3Qgb24gdGhlIGRhdGUgb2YNCj4N Cj4gUmFobWFuICYgRGlqayBFeHBpcmVzIEFwcmlsIDIyLCAyMDEzIFtQYWdlDQo+DQo+IDFdDQo+ DQo+IEludGVybmV0LURyYWZ0IEdyb3VwIENvbW11bmljYXRpb24gZm9yIENvQVAgT2N0b2Jlcg0K Pg0KPiAyMDEyDQo+DQo+ICBwdWJsaWNhdGlvbiBvZiB0aGlzIGRvY3VtZW50LiBQbGVhc2UgcmV2 aWV3IHRoZXNlIGRvY3VtZW50cw0KPg0KPiAgY2FyZWZ1bGx5LCBhcyB0aGV5IGRlc2NyaWJlIHlv dXIgcmlnaHRzIGFuZCByZXN0cmljdGlvbnMgd2l0aCByZXNwZWN0DQo+DQo+ICB0byB0aGlzIGRv Y3VtZW50LiBDb2RlIENvbXBvbmVudHMgZXh0cmFjdGVkIGZyb20gdGhpcyBkb2N1bWVudCBtdXN0 DQo+DQo+ICBpbmNsdWRlIFNpbXBsaWZpZWQgQlNEIExpY2Vuc2UgdGV4dCBhcyBkZXNjcmliZWQg aW4gU2VjdGlvbiA0LmUgb2YNCj4NCj4gIHRoZSBUcnVzdCBMZWdhbCBQcm92aXNpb25zIGFuZCBh cmUgcHJvdmlkZWQgd2l0aG91dCB3YXJyYW50eSBhcw0KPg0KPiAgZGVzY3JpYmVkIGluIHRoZSBT aW1wbGlmaWVkIEJTRCBMaWNlbnNlLg0KPg0KPiAxLiBDb252ZW50aW9ucyBhbmQgVGVybWlub2xv Z3kNCj4NCj4gIFRoZSBrZXkgd29yZHMgIk1VU1QiLCAiTVVTVCBOT1QiLCAiUkVRVUlSRUQiLCAi U0hBTEwiLCAiU0hBTEwgTk9UIiwNCj4NCj4gICJTSE9VTEQiLCAiU0hPVUxEIE5PVCIsICJSRUNP TU1FTkRFRCIsICJNQVkiLCBhbmQgIk9QVElPTkFMIiBpbiB0aGlzDQo+DQo+ICBkb2N1bWVudCBh cmUgdG8gYmUgaW50ZXJwcmV0ZWQgYXMgZGVzY3JpYmVkIGluIFtSRkMyMTE5XS4NCj4NCj4gIFRo aXMgZG9jdW1lbnQgYXNzdW1lcyByZWFkZXJzIGFyZSBmYW1pbGlhciB3aXRoIHRoZSB0ZXJtcyBh bmQNCj4NCj4gIGNvbmNlcHRzIHRoYXQgYXJlIHVzZWQgaW4gW0ktRC5pZXRmLWNvcmUtY29hcF0u IEluIGFkZGl0aW9uLCB0aGlzDQo+DQo+ICBkb2N1bWVudCBkZWZpbmVzIHRoZSBmb2xsb3dpbmcg dGVybWlub2xvZ3k6DQo+DQo+ICBHcm91cCBDb21tdW5pY2F0aW9uDQo+DQo+ICBBIHNvdXJjZSBu b2RlIHNlbmRzIGEgc2luZ2xlIG1lc3NhZ2Ugd2hpY2ggaXMgZGVsaXZlcmVkIHRvDQo+DQo+ICBt dWx0aXBsZSBkZXN0aW5hdGlvbiBub2Rlcywgd2hlcmUgYWxsIGRlc3RpbmF0aW9ucyBhcmUgaWRl bnRpZmllZA0KPg0KPiAgdG8gYmVsb25nIHRvIGEgc3BlY2lmaWMgZ3JvdXAuIFRoZSBzb3VyY2Ug bm9kZSBtYXkNCj4NCj4gL3JlbW92ZSBvciBtYXkgbm90DQo+DQo+ICBiZQ0KPg0KPiAgcGFydCBv ZiB0aGUgZ3JvdXAuIFRoZSB1bmRlcmx5aW5nIG1lY2hhbmlzbSBmb3IgZ3JvdXANCj4NCj4gIGNv bW11bmljYXRpb24gaXMgYXNzdW1lZCB0byBiZSBtdWx0aWNhc3QgYmFzZWQuDQo+DQo+IC9yZW1v dmUNCj4NCj4gIFRoZSBuZXR3b3JrIHdoZXJlDQo+DQo+ICB0aGUgZ3JvdXAgY29tbXVuaWNhdGlv biB0YWtlcyBwbGFjZSBjYW4gYmUgZWl0aGVyIGEgY29uc3RyYWluZWQNCj4NCj4gb3INCj4NCj4g IGEgcmVndWxhciAodW4tY29uc3RyYWluZWQpIG5ldHdvcmsvDQo+DQo+IC9jb21tZW50IG5vdCBz dXJlIGFib3V0IHRoZSBtZWFuaW5nIGFuZCBjb25zZXF1ZW5jZXMNCj4NCj4gIE11bHRpY2FzdA0K Pg0KPiAgU2VuZGluZyBhIG1lc3NhZ2UgdG8gbXVsdGlwbGUgZGVzdGluYXRpb24gbm9kZXMNCj4N Cj4gL3Mgc2ltdWx0YW5lb3VzbHkuLw0KPg0KPiAvcyB3aXRoIG9uZSBuZXR3b3JrIGludm9jYXRp b24gLw0KPg0KPiAgVGhlcmUgYXJlIHZhcmlvdXMgb3B0aW9ucyB0byBpbXBsZW1lbnQgbXVsdGlj YXN0IGluY2x1ZGluZyBsYXllcg0KPg0KPiAyDQo+DQo+ICAoTWVkaWEgQWNjZXNzIENvbnRyb2wp IG9yIGxheWVyIDMgKElQKSBtZWNoYW5pc21zLg0KPg0KPiAgSVAgTXVsdGljYXN0DQo+DQo+ICBB IHNwZWNpZmljIG11bHRpY2FzdCBzb2x1dGlvbiBiYXNlZCBvbiB0aGUgdXNlIG9mIElQIG11bHRp Y2FzdA0KPg0KPiAgYWRkcmVzc2VzIGFzIGRlZmluZWQgaW4gIklBTkEgR3VpZGVsaW5lcyBmb3Ig SVB2NCBNdWx0aWNhc3QNCj4NCj4gIEFkZHJlc3MgQXNzaWdubWVudHMiIFtSRkM1NzcxXSBhbmQg IklQIFZlcnNpb24gNiBBZGRyZXNzaW5nDQo+DQo+ICBBcmNoaXRlY3R1cmUiIFtSRkM0MjkxXS4N Cj4NCj4gIExvdyBwb3dlciBhbmQgTG9zc3kgTmV0d29yayAoTExOKQ0KPg0KPiAgTG93IHBvd2Vy IGFuZCBMb3NzeSBOZXR3b3JrIChMTE4pOiBBIHR5cGUgb2YgY29uc3RyYWluZWQgbmV0d29yaw0K Pg0KPiAgd2hlcmUgdGhlIGRldmljZXMgYXJlIGludGVyY29ubmVjdGVkIGJ5IGEgdmFyaWV0eSBv ZiBsb3cgcG93ZXIsDQo+DQo+ICBsb3NzeSBsaW5rcyBzdWNoIGFzIElFRUUgODAyLjE1LjQsIEJs dWV0b290aCwNCj4NCj4gPG5vdCBzbyBjb25zdHJhaW5lZD4gV2lGaSwgd2lyZWQgPC8+DQo+DQo+ ICBvciBsb3cNCj4NCj4gIHBvd2VyIHBvd2VyLWxpbmUgY29tbXVuaWNhdGlvbiBsaW5rcy4NCj4N Cj4gMi4gSW50cm9kdWN0aW9uDQo+DQo+IDIuMS4gQmFja2dyb3VuZA0KPg0KPiAgVGhlIENvbnN0 cmFpbmVkIEFwcGxpY2F0aW9uIFByb3RvY29sIChDb0FQKSBpcyBhbiBhcHBsaWNhdGlvbg0KPg0K PiAgcHJvdG9jb2wgKGFuYWxvZ291cyB0byBIVFRQKSBmb3IgcmVzb3VyY2UgY29uc3RyYWluZWQg ZGV2aWNlcw0KPg0KPiAgb3BlcmF0aW5nIGluIGFuIElQIG5ldHdvcmsgW0ktRC5pZXRmLWNvcmUt Y29hcF0uIENvbnN0cmFpbmVkDQo+DQo+IGRldmljZXMNCj4NCj4gIGNhbiBiZSBsYXJnZSBpbiBu dW1iZXIsIGJ1dCBhcmUgb2Z0ZW4gaGlnaGx5IGNvcnJlbGF0ZWQgdG8gZWFjaA0KPg0KPiBvdGhl cg0KPg0KPiAgKGUuZy4gYnkgdHlwZSBvciBsb2NhdGlvbikuIEZvciBleGFtcGxlLCBhbGwgdGhl IGxpZ2h0IHN3aXRjaGVzIGluDQo+DQo+IGENCj4NCj4gIGJ1aWxkaW5nIG1heSBiZWxvbmcgdG8g b25lIGdyb3VwIGFuZCBhbGwgdGhlIHRoZXJtb3N0YXRzIG1heSBiZWxvbmcNCj4NCj4gIHRvIGFu b3RoZXIgZ3JvdXAuIEdyb3VwcyBtYXkgYmUgY29tcG9zZWQgYnkgZnVuY3Rpb24uIEZvciBleGFt cGxlLA0KPg0KPiBSYWhtYW4gJiBEaWprIEV4cGlyZXMgQXByaWwgMjIsIDIwMTMgW1BhZ2UNCj4N Cj4gM10NCj4NCj4gSW50ZXJuZXQtRHJhZnQgR3JvdXAgQ29tbXVuaWNhdGlvbiBmb3IgQ29BUCBP Y3RvYmVyDQo+DQo+IDIwMTINCj4NCj4gIHRoZSBncm91cCAiYWxsIGxpZ2h0cyBpbiBidWlsZGlu ZyBvbmUiIG1heSBjb25zaXN0IG9mIHRoZSBncm91cHMNCj4NCj4gImFsbA0KPg0KPiAgbGlnaHRz IG9uIGZsb29yIG9uZSBvZiBidWlsZGluZyBvbmUiLCAiYWxsIGxpZ2h0cyBvbiBmbG9vciB0d28g b2YNCj4NCj4gIGJ1aWxkaW5nIG9uZSIsIGV0Yy4gR3JvdXBzIG1heSBiZSBwcmVjb25maWd1cmVk DQo+DQo+IC9hZGQgYmVmb3JlIGRlcGxveW1lbnQNCj4NCj4gIG9yIGR5bmFtaWNhbGx5DQo+DQo+ ICBmb3JtZWQNCj4NCj4gL2FkZCBkdXJpbmcgb3BlcmF0aW9uDQo+DQo+ICAuIElmIGluZm9ybWF0 aW9uIG5lZWRzIHRvIGJlIHNlbnQgdG8gb3IgcmVjZWl2ZWQgZnJvbSBhIGdyb3VwDQo+DQo+ICBv ZiBkZXZpY2VzLCBncm91cCBjb21tdW5pY2F0aW9uIG1lY2hhbmlzbXMgY2FuIGltcHJvdmUgZWZm aWNpZW5jeQ0KPg0KPiBhbmQNCj4NCj4gIGxhdGVuY3kgb2YgY29tbXVuaWNhdGlvbiBhbmQgcmVk dWNlIGJhbmR3aWR0aCByZXF1aXJlbWVudHMgZm9yIGENCj4NCj4gIGdpdmVuIGFwcGxpY2F0aW9u LiBIVFRQIGRvZXMgbm90IHN1cHBvcnQgYW55IGVxdWl2YWxlbnQNCj4NCj4gIGZ1bmN0aW9uYWxp dHkgdG8gQ29BUCBncm91cCBjb21tdW5pY2F0aW9uLg0KPg0KPiAyLjIuIFNjb3BlDQo+DQo+ICBJ biB0aGlzIGRyYWZ0LCB3ZSBhZGRyZXNzIHRoZSBpc3N1ZXMgcmVsYXRlZCB0byBDb0FQIGdyb3Vw DQo+DQo+ICBjb21tdW5pY2F0aW9uIGluIGRldGFpbCwgd2l0aCB1c2UgY2FzZXMsIHJlY29tbWVu ZGVkIGFwcHJvYWNoZXMgYW5kDQo+DQo+ICBhbmFseXNpcyBvZiB0aGUgaW1wYWN0IHRvIHRoZSBD b0FQIHByb3RvY29sIGFuZCB0byBpbXBsZW1lbnRhdGlvbnMuDQo+DQo+IC9hZGQgdGhlIHVzZSBv ZiBncm91cCBjb21tdW5pY2F0aW9uIGZvciBtRE5TIGlzIG91dCBvZiBzY29wZS4NCj4NCj4gIFRo ZSBndWlkaW5nIHByaW5jaXBsZSBpcyB0byBhcHBseSB3aGVyZXZlciBwb3NzaWJsZSBleGlzdGlu ZyBJRVRGDQo+DQo+ICBwcm90b2NvbHMgdG8gYWNoaWV2ZSBncm91cCBjb21tdW5pY2F0aW9uIGZ1 bmN0aW9uYWxpdHkuIEluIG1hbnkNCj4NCj4gIGNhc2VzIHRoZSBjb250cmlidXRpb24gb2YgdGhp cyBkb2N1bWVudCBsaWVzIGluIGV4cGxhaW5pbmcgaG93DQo+DQo+ICBleGlzdGluZyBtZWNoYW5p c21zIG1heSBiZSB1c2VkIHRvDQo+DQo+IC9yZW1vdmUgdG9nZXRoZXINCj4NCj4gIGZ1bGZpbGwg Q29BUCBncm91cA0KPg0KPiAgY29tbXVuaWNhdGlvbiBuZWVkcyBmb3Igc3BlY2lmaWMgdXNlIGNh c2VzLg0KPg0KPiAyLjMuIFBvdGVudGlhbCBTb2x1dGlvbnMgZm9yIEdyb3VwIENvbW11bmljYXRp b24NCj4NCj4gIFRoZSBjbGFzc2ljIGNvbmNlcHQgb2YgZ3JvdXANCj4NCj4gL3MgY29tbXVuaWNh dGlvbnMgL3MgY29tbXVuaWNhdGlvbg0KPg0KPiAgaXMgdGhhdCBvZiBhIHNpbmdsZQ0KPg0KPiAg c291cmNlIGRpc3RyaWJ1dGluZyBjb250ZW50IHRvIG11bHRpcGxlIGRlc3RpbmF0aW9uIHJlY2lw aWVudHMgdGhhdA0KPg0KPiAgYXJlIGFsbCBwYXJ0IG9mIGEgZ3JvdXAuIEJlZm9yZSBjb250ZW50 IGNhbiBiZSBkaXN0cmlidXRlZCwgdGhlcmUNCj4NCj4gaXMNCj4NCj4gIGEgc2VwYXJhdGUgcHJv Y2VzcyB0byBmb3JtIHRoZSBncm91cC4gVGhlIHNvdXJjZSBtYXkgYmUgZWl0aGVyIGENCj4NCj4g IG1lbWJlciBvciBub24tbWVtYmVyIG9mIHRoZSBncm91cC4NCj4NCj4gIEdyb3VwIGNvbW11bmlj YXRpb24gc29sdXRpb25zIGhhdmUgZXZvbHZlZCBmcm9tICJib3R0b20iIHRvICJ0b3AiLA0KPg0K PiAgaS5lLiwgZnJvbSBsYXllciAyIChNZWRpYSBBY2Nlc3MgQ29udHJvbCBicm9hZGNhc3QvbXVs dGljYXN0KSBhbmQNCj4NCj4gIGxheWVyIDMgKElQIG11bHRpY2FzdCkgdG8gYXBwbGljYXRpb24g bGF5ZXIgZ3JvdXAgY29tbXVuaWNhdGlvbiwNCj4NCj4gYWxzbw0KPg0KPiAgcmVmZXJyZWQgdG8g YXMgYXBwbGljYXRpb24gbGF5ZXIgbXVsdGljYXN0LiBBIHN0dWR5IHB1Ymxpc2hlZCBpbg0KPg0K PiAgMjAwNSBbTGFvMDVdIGlkZW50aWZpZWQgbmV3IHNvbHV0aW9ucyBpbiB0aGUgIm1pZGRsZSIg KHJlZmVycmVkIHRvDQo+DQo+IGFzDQo+DQo+ICBvdmVybGF5IG11bHRpY2FzdCkgdGhhdCB1dGls aXplIGFuIGluZnJhc3RydWN0dXJlIGJhc2VkIG9uIHByb3hpZXMuDQo+DQo+ICBFYWNoIG9mIHRo ZXNlIGNsYXNzZXMgb2Ygc29sdXRpb25zIG1heSBiZSBjb21wYXJlZCBbTGFvMDVdIHVzaW5nDQo+ DQo+ICBtZXRyaWNzIHN1Y2ggYXMgbGluayBzdHJlc3MgYW5kIGxldmVsIG9mIGhvc3QgY29tcGxl eGl0eQ0KPg0KPiAgW0JhbmVyamVlMDFdLiBUaGUgcmVzdWx0cyBzaG93IGZvciBhIHJlYWxpc3Rp YyBpbnRlcm5ldCB0b3BvbG9neQ0KPg0KPiAgdGhhdCBJUCBNdWx0aWNhc3QgaXMgdGhlIG1vc3Qg cmVzb3VyY2UtZWZmaWNpZW50LCB3aXRoIHRoZSBkb3duc2lkZQ0KPg0KPiAgYmVpbmcgdGhhdCBp dCByZXF1aXJlcw0KPg0KPiAvcyB0aGUgbW9zdCAvcyBtb3JlIG9yZ2FuaXphdGlvbmFsDQo+DQo+ ICBlZmZvcnQgdG8gZGVwbG95IGluIHRoZQ0KPg0KPiAgaW5mcmFzdHJ1Y3R1cmUuIElQIE11bHRp Y2FzdCBpcyB0aGUgc29sdXRpb24gYWRvcHRlZCBieSB0aGlzIGRyYWZ0DQo+DQo+ICBmb3IgQ29B UCBncm91cCBjb21tdW5pY2F0aW9uLg0KPg0KPiAzLiBDb0FQIEdyb3VwIENvbW11bmljYXRpb24g QmFzZWQgT24gSVAgTXVsdGljYXN0DQo+DQo+IFJhaG1hbiAmIERpamsgRXhwaXJlcyBBcHJpbCAy MiwgMjAxMyBbUGFnZQ0KPg0KPiA0XQ0KPg0KPiBJbnRlcm5ldC1EcmFmdCBHcm91cCBDb21tdW5p Y2F0aW9uIGZvciBDb0FQIE9jdG9iZXINCj4NCj4gMjAxMg0KPg0KPiAzLjEuIElQIE11bHRpY2Fz dCBCYWNrZ3JvdW5kDQo+DQo+ICBJUCBNdWx0aWNhc3Qgcm91dGluZyBwcm90b2NvbHMgaGF2ZSBi ZWVuIGV2b2x2aW5nIGZvciBkZWNhZGVzLA0KPg0KPiAgcmVzdWx0aW5nIGluIHByb3Bvc2VkIHN0 YW5kYXJkcyBzdWNoIGFzIFByb3RvY29sIEluZGVwZW5kZW50DQo+DQo+ICBNdWx0aWNhc3QgLSBT cGFyc2UgTW9kZSAoUElNLVNNKSBbUkZDNDYwMV0uIFlldCwgZHVlIHRvIHZhcmlvdXMNCj4NCj4g IHRlY2huaWNhbCBhbmQgbWFya2V0aW5nIHJlYXNvbnMsIElQIE11bHRpY2FzdCByb3V0aW5nIGlz IG5vdCB3aWRlbHkNCj4NCj4gIGRlcGxveWVkIG9uIHRoZSBnZW5lcmFsIEludGVybmV0LiBIb3dl dmVyLCBJUCBNdWx0aWNhc3QgaXMgdmVyeQ0KPg0KPiAgcG9wdWxhciBpbiBzcGVjaWZpYyBkZXBs b3ltZW50cyBzdWNoIGFzIGluIGVudGVycHJpc2UgbmV0d29ya3MgKGUuZy4NCj4NCj4gIGZvciB2 aWRlbyBjb25mZXJlbmNpbmcpLCBzbWFydCBob21lIG5ldHdvcmtzIChlLmcuIFVQblAvbUROUykg YW5kDQo+DQo+ICBjYXJyaWVyIElQVFYgZGVwbG95bWVudHMuIFRoZSBwYWNrZXQgZWNvbm9teSBh bmQgbWluaW1hbCBob3N0DQo+DQo+ICBjb21wbGV4aXR5IG9mIElQIG11bHRpY2FzdCBtYWtlIGl0 IGF0dHJhY3RpdmUgZm9yIGdyb3VwDQo+DQo+IGNvbW11bmljYXRpb24NCj4NCj4gIGluIGNvbnN0 cmFpbmVkIGVudmlyb25tZW50cy4gVGhlcmVmb3JlIElQIG11bHRpY2FzdCBpcyB0aGUNCj4NCj4g IHJlY29tbWVuZGVkIHVuZGVybHlpbmcgbWVjaGFuaXNtIGZvciBDb0FQIGdyb3VwIGNvbW11bmlj YXRpb24sIGFuZA0KPg0KPiAgdGhlIGFwcHJvYWNoIGFzc3VtZWQgaW4gdGhpcyBkb2N1bWVudC4N Cj4NCj4gIFRvIGFjaGlldmUgSVAgbXVsdGljYXN0IGJleW9uZCBhIHN1Ym5ldCwgYW4gSVAgbXVs dGljYXN0IHJvdXRpbmcNCj4NCj4gIHByb3RvY29sIG5lZWRzIHRvIGJlIGFjdGl2ZSBvbiByb3V0 ZXJzLiBUaGUgUlBMIHByb3RvY29sIFtSRkM2NTUwXQ0KPg0KPiAgZm9yIGV4YW1wbGUgaXMgYWJs ZSB0byByb3V0ZSBtdWx0aWNhc3QgdHJhZmZpYyBpbiBjb25zdHJhaW5lZCBMTE5zLg0KPg0KPiAg V2hpbGUgUElNLVNNIFtSRkM0NjAxXSBpcyBvZnRlbiB1c2VkIGZvciBtdWx0aWNhc3Qgcm91dGlu ZyBpbiB1bi0NCj4NCj4gIGNvbnN0cmFpbmVkIG5ldHdvcmtzLg0KPg0KPiAgSVAgbXVsdGljYXN0 IGNhbiBhbHNvIGJlIHJ1biBpbiBhIExpbmstTG9jYWwgKExMKSBzY29wZS4gVGhpcyBtZWFucw0K Pg0KPiAgdGhhdCB0aGVyZSBpcyBubyByb3V0aW5nIGludm9sdmVkIGFuZCBhbiBJUCBtdWx0aWNh c3QgbWVzc2FnZSBpcw0KPg0KPiBvbmx5DQo+DQo+ICByZWNlaXZlZA0KPg0KPiAvcyBvbiB0aGUg bmV0d29yayAvcyBvdmVyIHRoZQ0KPg0KPiAgbGluayBvbiB3aGljaCBpdCB3YXMgc2VudC4NCj4N Cj4gMy4yLiBDb0FQIEdyb3VwIERlZmluaXRpb24gYW5kIE5hbWluZw0KPg0KPiAgQSBncm91cCBp cyBkZWZpbmVkIGFzIGEgc2V0IG9mIENvQVAgZW5kcG9pbnRzLCB3aGVyZSBlYWNoIGVuZHBvaW50 DQo+DQo+IGlzDQo+DQo+ICBjb25maWd1cmVkIHRvIHJlY2VpdmUgYSBtdWx0aWNhc3QgQ29BUCBy ZXF1ZXN0IHRoYXQgaXMgc2VudCB0byB0aGUNCj4NCj4gIGdyb3VwJ3MgYXNzb2NpYXRlZCBJUCBt dWx0aWNhc3QgYWRkcmVzcy4gVGhlIGdyb3VwIE1BWSBoYXZlIG1vcmUNCj4NCj4gIHRoYW4gb25l IGFzc29jaWF0ZWQgSVAgbXVsdGljYXN0IGFkZHJlc3MuIEFuIGVuZHBvaW50IE1BWSBiZSBhDQo+ DQo+ICBtZW1iZXIgb2YgbXVsdGlwbGUgZ3JvdXBzLiBHcm91cCBtZW1iZXJzaGlwIG9mIGFuIGVu ZHBvaW50IE1BWQ0KPg0KPiAgZHluYW1pY2FsbHkgY2hhbmdlIG92ZXIgdGltZS4gVGhlIGdyb3Vw IE1BWSBiZSBpZGVudGlmaWVkIGJ5IGENCj4NCj4gR3JvdXANCj4NCj4gIE5hbWUgKFtJLUQudmFu ZGVyc3Rvay1jb3JlLWRuYV0pIHdoaWNoIGlzIGRlZmluZWQgYXMgYSBwcmVmaXggc3RyaW5nDQo+ DQo+ICBvZiBhIEdyb3VwIEZRRE4uIFRoZSBHcm91cCBGUUROIGNhbiBiZSB1bmlxdWVseSBtYXBw ZWQgdG8gYSBzaXRlLQ0KPg0KPiAgbG9jYWwgb3IgZ2xvYmFsIG11bHRpY2FzdCBJUCBhZGRyZXNz IHZpYSBETlMgcmVzb2x1dGlvbi4NCj4NCj4gIEEgQ29BUCBtdWx0aWNhc3QgcmVxdWVzdCB0aGF0 IGFkZHJlc3NlcyBhIGdyb3VwIGluY2x1ZGVzIGEgR3JvdXAgVVJJDQo+DQo+ICBhcyB0aGUgcmVx dWVzdCBVUkkuIEEgR3JvdXAgVVJJIGhhcyB0aGUgc2NoZW1lICdjb2FwJyBhbmQgaW5jbHVkZXMN Cj4NCj4gIGluIHRoZSBhdXRob3JpdHkgcGFydCBlaXRoZXIgYSBncm91cCBJUCBhZGRyZXNzDQo+ DQo+IC9hZGQgKyBvcHRpb25hbCBwb3J0DQo+DQo+ICBvciBhIGhvc3RuYW1lDQo+DQo+IC9hZGQg KyBvcHRpb25hbCBwb3J0DQo+DQo+ICB0aGF0DQo+DQo+ICBjYW4gYmUgcmVzb2x2ZWQgdG8gdGhl IGdyb3VwIElQIGFkZHJlc3MgKGUuZy4sIGEgR3JvdXAgTmFtZSBvciBHcm91cA0KPg0KPiAgRlFE TikuIEdyb3VwIFVSSXMgTVVTVCBmb2xsb3cgdGhlIFVSSSBzeW50YXggW1JGQzM5ODZdLg0KPg0K PiAgQSBDb0FQDQo+DQo+IC9zIG5vZGUgL3MgZW5kLXBvaW50DQo+DQo+ICBiZWNvbWVzIGEgZ3Jv dXAgbWVtYmVyIGJ5IGxpc3RlbmluZyBmb3IgQ29BUCBtZXNzYWdlcyBvbg0KPg0KPiAgdGhlIGdy b3VwJ3MgSVAgbXVsdGljYXN0IGFkZHJlc3MsIGFzc3VtaW5nIHRoZSBkZWZhdWx0IENvQVAgVURQ DQo+DQo+IHBvcnQuDQo+DQo+ICBOb3RlIHRoYXQgYSBub24tZGVmYXVsdCBVRFAgcG9ydCBNQVkg YmUgc3BlY2lmaWVkIGZvciB0aGUgZ3JvdXA7IGluDQo+DQo+ICB3aGljaCBjYXNlIGltcGxlbWVu dGVycyBNVVNUIGVuc3VyZSB0aGF0IGFsbCBncm91cCBtZW1iZXJzIGFyZQ0KPg0KPiAgY29uZmln dXJlZCB0byB1c2UgdGhpcyBzYW1lIHBvcnQuDQo+DQo+IFJhaG1hbiAmIERpamsgRXhwaXJlcyBB cHJpbCAyMiwgMjAxMyBbUGFnZQ0KPg0KPiA1XQ0KPg0KPiBJbnRlcm5ldC1EcmFmdCBHcm91cCBD b21tdW5pY2F0aW9uIGZvciBDb0FQIE9jdG9iZXINCj4NCj4gMjAxMg0KPg0KPiAgRXhhbXBsZXMg b2YgaGllcmFyY2hpY2FsIGdyb3VwIG5hbWluZyAoYW5kIHNjb3BpbmcpIGZvciBhIGJ1aWxkaW5n DQo+DQo+ICBjb250cm9sIGFwcGxpY2F0aW9uIGFyZSBzaG93biBiZWxvdy4NCj4NCj4gIFVSSSBh dXRob3JpdHkgVGFyZ2V0ZWQgZ3JvdXANCj4NCj4gIGFsbC5ibGRnNi5leGFtcGxlLmNvbSAiYWxs IG5vZGVzIGluIGJ1aWxkaW5nIDYiDQo+DQo+ICBhbGwud2VzdC5ibGRnNi5leGFtcGxlLmNvbSAi YWxsIG5vZGVzIGluIHdlc3Qgd2luZywgYnVpbGRpbmcNCj4NCj4gNiINCj4NCj4gIGFsbC5mbG9v cjEud2VzdC5ibGRnNi5leGFtcC4uLiAiYWxsIG5vZGVzIGluIGZsb29yIDEsIHdlc3Qgd2luZywN Cj4NCj4gIGJ1aWxkaW5nIDYiDQo+DQo+ICBhbGwuYnUwMzYuZmxvb3IxLndlc3QuYmxkZzYuLi4g ImFsbCBub2RlcyBpbiBvZmZpY2UgYnUwMzYsIGZsb29yMSwNCj4NCj4gIHdlc3Qgd2luZywgYnVp bGRpbmcgNiINCj4NCj4gIFJldmVyc2UgbWFwcGluZyAoZnJvbSBJUCBtdWx0aWNhc3QgYWRkcmVz cyB0byBncm91cCBGUUROKSBpcw0KPg0KPiAgc3VwcG9ydGVkIHVzaW5nIHRoZSByZXZlcnNlIERO UyByZXNvbHV0aW9uIHRlY2huaXF1ZQ0KPg0KPiAgKFtJLUQudmFuZGVyc3Rvay1jb3JlLWRuYV0p Lg0KPg0KPiAzLjMuIEdyb3VwIERpc2NvdmVyeSBhbmQgTWVtYmVyIERpc2NvdmVyeQ0KPg0KPiAg Q29BUCBkZWZpbmVzIGEgcmVzb3VyY2UgZGlzY292ZXJ5IGNhcGFiaWxpdHksIGJ1dCBkb2VzIG5v dCB5ZXQNCj4NCj4gIHNwZWNpZnkgaG93IHRvIGRpc2NvdmVyIGdyb3VwcyAoZS5nLiBmaW5kIGEg Z3JvdXAgdG8gam9pbiBvciBzZW5kIGENCj4NCj4gIG11bHRpY2FzdCBtZXNzYWdlIHRvKSBvciB0 byBkaXNjb3ZlciBtZW1iZXJzIG9mIGEgZ3JvdXAgKGUuZy4gdG8NCj4NCj4gIGFkZHJlc3Mgc2Vs ZWN0ZWQgZ3JvdXAgbWVtYmVycyBieSB1bmljYXN0KS4gVGhlc2UgdG9waWNzIGFyZQ0KPg0KPiAg ZWxhYm9yYXRlZCBpbiBtb3JlIGRldGFpbCBpbiBbSS1ELnZhbmRlcnN0b2stY29yZS1kbmFdIGlu Y2x1ZGluZw0KPg0KPiAgZXhhbXBsZXMgZm9yIHVzaW5nIEROUy1TRCBhbmQgQ29SRSBSZXNvdXJj ZSBEaXJlY3RvcnkuDQo+DQo+IDMuMy4xLiBETlMtU0QNCj4NCj4gIEROUy1iYXNlZCBTZXJ2aWNl IERpc2NvdmVyeSBbSS1ELmNoZXNoaXJlLWRuc2V4dC1kbnMtc2RdIGRlZmluZXMgYQ0KPg0KPiAg Y29udmVudGlvbmFsIHdheSB0byBjb25maWd1cmUgRE5TIFBUUiwgU1JWLCBhbmQgVFhUIHJlY29y ZHMgdG8NCj4NCj4gZW5hYmxlDQo+DQo+ICBlbnVtZXJhdGlvbiBvZiBzZXJ2aWNlcywgc3VjaCBh cyBzZXJ2aWNlcyBvZmZlcmVkIGJ5IENvQVAgbm9kZXMsIG9yDQo+DQo+ICBlbnVtZXJhdGlvbiBv ZiBhbGwgQ29BUCBub2Rlcywgd2l0aGluIHNwZWNpZmllZCBzdWJkb21haW5zLiBBDQo+DQo+ICBz ZXJ2aWNlIGlzIHNwZWNpZmllZCBieSBhIG5hbWUgb2YgdGhlIGZvcm0NCj4NCj4gIDxJbnN0YW5j ZT4uPFNlcnZpY2VUeXBlPi48RG9tYWluPiwgd2hlcmUgdGhlIHNlcnZpY2UgdHlwZSBmb3IgQ29B UA0KPg0KPiAgbm9kZXMgaXMgX2NvYXAuX3VkcCBhbmQgdGhlIGRvbWFpbiBpcyBhIEROUyBkb21h aW4gbmFtZSB0aGF0DQo+DQo+ICBpZGVudGlmaWVzIGEgZ3JvdXAgYXMgaW4gdGhlIGV4YW1wbGVz IGFib3ZlLiBGb3IgZWFjaCBDb0FQDQo+DQo+IGVuZC1wb2ludA0KPg0KPiAgaW4gYSBncm91cCwg YSBQVFIgcmVjb3JkIHdpdGggdGhlIG5hbWUgX2NvYXAuX3VkcCBhbmQvb3IgYSBQVFINCj4NCj4g cmVjb3JkDQo+DQo+ICB3aXRoIHRoZSBuYW1lIF9jb2FwLl91ZHAuPERvbWFpbj4gaXMgZGVmaW5l ZCBhbmQgaXQgcG9pbnRzIHRvIGFuIFNSVg0KPg0KPiAgcmVjb3JkIGhhdmluZyB0aGUgPEluc3Rh bmNlPi48U2VydmljZVR5cGU+LjxEb21haW4+IG5hbWUuDQo+DQo+ICBBbGwgQ29BUCBub2RlcyBp biBhIGdpdmVuIHN1YmRvbWFpbiBtYXkgYmUgZW51bWVyYXRlZCBieSBzZW5kaW5nIGENCj4NCj4g IHF1ZXJ5IGZvciBQVFIgcmVjb3JkcyBuYW1lZCBfY29hcC5fdWRwIHRvIHRoZSBhdXRob3JpdGF0 aXZlIEROUw0KPg0KPiAgc2VydmVyIGZvciB0aGF0IHpvbmUuIEEgbGlzdCBvZiBTUlYgcmVjb3Jk cyBpcyByZXR1cm5lZC4gRWFjaCBTUlYNCj4NCj4gIHJlY29yZCBjb250YWlucyB0aGUgcG9ydCBh bmQgaG9zdCBuYW1lIChBQUFBIHJlY29yZCkgb2YgYSBDb0FQIG5vZGUuDQo+DQo+ICBUaGUgSVAg YWRkcmVzcyBvZiB0aGUgbm9kZSBpcyBvYnRhaW5lZCBieSByZXNvbHZpbmcgdGhlIGhvc3QgbmFt ZS4NCj4NCj4gIEROUy1TRCBhbHNvIHNwZWNpZmllcyBhbiBvcHRpb25hbCBUWFQgcmVjb3JkLCBo YXZpbmcgdGhlIHNhbWUgbmFtZQ0KPg0KPiBhcw0KPg0KPiAgdGhlIFNSViByZWNvcmQsIHdoaWNo IGNhbiBjb250YWluICJrZXk9dmFsdWUiIGF0dHJpYnV0ZXMuIFRoaXMgY2FuDQo+DQo+ICBiZSB1 c2VkIHRvIHN0b3JlIGluZm9ybWF0aW9uIGFib3V0IHRoZSBkZXZpY2UsIGUuZy4gc2NoZW1hPURB TEksDQo+DQo+ICB0eXBlPXN3aXRjaCwgZ3JvdXA9bGlnaHRpbmcuYmxkZzYsIGV0Yy4NCj4NCj4g UmFobWFuICYgRGlqayBFeHBpcmVzIEFwcmlsIDIyLCAyMDEzIFtQYWdlDQo+DQo+IDZdDQo+DQo+ IEludGVybmV0LURyYWZ0IEdyb3VwIENvbW11bmljYXRpb24gZm9yIENvQVAgT2N0b2Jlcg0KPg0K PiAyMDEyDQo+DQo+ICBBbm90aGVyIGZlYXR1cmUgb2YgRE5TLVNEIGlzIHRoZSBhYmlsaXR5IHRv IHNwZWNpZnkgc2VydmljZSBzdWJ0eXBlcw0KPg0KPiAgdXNpbmcgUFRSIHJlY29yZHMuIEZvciBl eGFtcGxlLCBvbmUgY291bGQgcmVwcmVzZW50IGFsbCB0aGUgQ29BUA0KPg0KPiAgZ3JvdXBzIGlu IGEgc3ViZG9tYWluIGJ5IFBUUiByZWNvcmRzIHdpdGggdGhlIG5hbWUNCj4NCj4gIF9ncm91cC5f c3ViLl9jb2FwLl91ZHAgb3IgYWx0ZXJuYXRpdmVseQ0KPg0KPiAgX2dyb3VwLl9zdWIuX2NvYXAu X3VkcC48RG9tYWluPi4NCj4NCj4gMy4zLjIuIENvUkUgUmVzb3VyY2UgRGlyZWN0b3J5DQo+DQo+ ICBDb1JFIFJlc291cmNlIERpcmVjdG9yeSBbSS1ELnNoZWxieS1jb3JlLXJlc291cmNlLWRpcmVj dG9yeV0gZGVmaW5lcw0KPg0KPiAgdGhlIGNvbmNlcHQgb2YgYSBSZXNvdXJjZSBEaXJlY3Rvcnkg KFJEKSBzZXJ2ZXIgd2hlcmUgQ29BUCBzZXJ2ZXJzDQo+DQo+ICBjYW4gcmVnaXN0ZXIgdGhlaXIg cmVzb3VyY2VzIG9mZmVyZWQgYW5kIENvQVAgY2xpZW50cyBjYW4gZGlzY292ZXINCj4NCj4gIHRo ZXNlIHJlc291cmNlcyBieSBxdWVyeWluZyB0aGUgUkQgc2VydmVyLiBSRCBzeW50YXggY2FuIGJl IG1hcHBlZA0KPg0KPiAgdG8gRE5TLVNEIHN5bnRheCBhbmQgdmljZSB2ZXJzYSBbSS1ELmx5bm4t Y29yZS1kaXNjb3ZlcnktbWFwcGluZ10sDQo+DQo+ICBzdWNoIHRoYXQgdGhlIGFib3ZlIGFwcHJv YWNoIGNhbiBiZSByZXVzZWQgZm9yIGdyb3VwIGRpc2NvdmVyeSBhbmQNCj4NCj4gIGdyb3VwIG1l bWJlciBkaXNjb3ZlcnkuDQo+DQo+ICAvcmVtb3ZlIFNwZWNpZmljYWxseSwgdGhlIERvbWFpbiAo ZCkgcGFyYW1ldGVyIGNhbiBiZSBzZXQgdG8gdGhlDQo+DQo+IGdyb3VwIFVSSSBieQ0KPg0KPiAg YW4gZW5kLXBvaW50IHJlZ2lzdGVyaW5nIHRvIHRoZSBSRC4gSWYgYW4gZW5kLXBvaW50IHdhbnRz IHRvIGpvaW4NCj4NCj4gIG11bHRpcGxlIGdyb3VwcywgaXQgaGFzIHRvIHJlcGVhdCB0aGUgcmVn aXN0cmF0aW9uIHByb2Nlc3MgZm9yIGVhY2gNCj4NCj4gIGdyb3VwIGl0IHdhbnRzIHRvIGpvaW4u DQo+DQo+IC9lbmQgcmVtb3ZlDQo+DQo+IC9jb21tZW50IGQgcGFyYW1ldGVyIHNlbWFudGljcyBu b3QgY2xlYXINCj4NCj4gMy40LiBHcm91cCBSZXNvdXJjZSBNYW5pcHVsYXRpb24NCj4NCj4gIEdy b3VwIGNvbW11bmljYXRpb25zIFNIQUxMIG9ubHkgYmUgdXNlZCBmb3IgaWRlbXBvdGVudCBtZXRo b2RzIChpLmUuDQo+DQo+ICBDb0FQIEdFVCwgUFVULCBERUxFVEUpLiBUaGUgQ29BUCBtZXNzYWdl cyB0aGF0IGFyZSBzZW50IHZpYQ0KPg0KPiAgbXVsdGljYXN0IFNIQUxMIGJlIE5vbi1Db25maXJt YWJsZS4NCj4NCj4gIEEgdW5pY2FzdCByZXNwb25zZSBwZXIgc2VydmVyIE1BWSBiZSBzZW50IGJh Y2sgdG8gYW5zd2VyIHRoZSBncm91cA0KPg0KPiAgcmVxdWVzdCAoZS5nLiByZXNwb25zZSAiMi4w NSBDb250ZW50IiB0byBhIGdyb3VwIEdFVCByZXF1ZXN0KSB0YWtpbmcNCj4NCj4gIGludG8gYWNj b3VudCB0aGUgY29uZ2VzdGlvbiBjb250cm9sIHJ1bGVzIGRlZmluZWQgaW4NCj4NCj4gIFtJLUQu aWV0Zi1jb3JlLWNvYXBdLiBUaGUgdW5pY2FzdCByZXNwb25zZXMgbWF5IGJlIGEgbWl4dHVyZSBv Zg0KPg0KPiAgc3VjY2VzcyAoZS5nLiAyLjA1IENvbnRlbnQpIGFuZCBmYWlsdXJlIChlLmcuIDQu MDQgTm90IEZvdW5kKSBjb2Rlcw0KPg0KPiAgZGVwZW5kaW5nIG9uIHRoZSBpbmRpdmlkdWFsIHNl cnZlciBwcm9jZXNzaW5nIHJlc3VsdC4NCj4NCj4gIEdyb3VwIGNvbW11bmljYXRpb25zIFNIQUxM IE5PVCBiZSB1c2VkIGZvciBub24taWRlbXBvdGVudCBtZXRob2RzDQo+DQo+ICAoaS5lLiBDb0FQ IFBPU1QpLiBUaGlzIGlzIGJlY2F1c2Ugbm90IGFsbCBncm91cCBtZW1iZXJzIGFyZQ0KPg0KPiAg Z3VhcmFudGVlZCB0byByZWNlaXZlIHRoZSBtdWx0aWNhc3QgcmVxdWVzdCwgYW5kIHRoZSBzZW5k ZXIgY2FuIG5vdA0KPg0KPiAgcmVhZGlseSBmaW5kIG91dCB3aGljaCBncm91cCBtZW1iZXJzIGRp ZCBub3QgcmVjZWl2ZSBpdC4NCj4NCj4gIEFsbCBub2RlcyBpbiBhIGdpdmVuIGdyb3VwIFNIT1VM RCByZWNlaXZlIHRoZSBzYW1lIHJlcXVlc3QNCj4NCj4gL3JlbW92ZSB3aXRoIGhpZ2ggcHJvYmFi aWxpdHkuDQo+DQo+IC9jb21tZW50IEkgZG9uJ3Qgc2VlIHdoZXJlIHByb2JhYmlsaXR5IGNvbWVz IGluLg0KPg0KPiAgVGhpcyB3aWxsIG5vdCBiZSB0aGUgY2FzZSBpZiB0aGVyZSBpcyBkaXZlcnNp dHkgaW4gdGhlDQo+DQo+ICBhdXRob3JpdHkgcG9ydCAoaS5lLiBhIGRpdmVyc2l0eSBvZiBkeW5h bWljIHBvcnQgYWRkcmVzc2VzIGFjcm9zcw0KPg0KPiB0aGUNCj4NCj4gIGdyb3VwKSBvciBpZiB0 aGUgdGFyZ2V0ZWQgcmVzb3VyY2UgaXMgbG9jYXRlZCBhdCBkaWZmZXJlbnQgcGF0aHMgb24NCj4N Cj4gIGRpZmZlcmVudCBub2Rlcy4NCj4NCj4gIFRoZXJlZm9yZSwgc29tZSBtZWFzdXJlcyBtdXN0 IGJlIHByZXNlbnQgdG8gZW5zdXJlIHVuaWZvcm1pdHkgaW4NCj4NCj4gcG9ydA0KPg0KPiAgbnVt YmVyIGFuZCByZXNvdXJjZSBuYW1lcy9sb2NhdGlvbnMgd2l0aGluIGEgZ3JvdXAuIFRoaXMgZG9j dW1lbnQNCj4NCj4gIHByb3Bvc2VzIHRoZSBmb2xsb3dpbmcgbWVhc3VyZXM6DQo+DQo+IFJhaG1h biAmIERpamsgRXhwaXJlcyBBcHJpbCAyMiwgMjAxMyBbUGFnZQ0KPg0KPiA3XQ0KPg0KPiBJbnRl cm5ldC1EcmFmdCBHcm91cCBDb21tdW5pY2F0aW9uIGZvciBDb0FQIE9jdG9iZXINCj4NCj4gMjAx Mg0KPg0KPiAgbyBBbGwgQ29BUCBtdWx0aWNhc3QgcmVxdWVzdHMgTVVTVCBiZSBzZW50IGVpdGhl ciB0byB0aGUgZGVmYXVsdA0KPg0KPiAgQ29BUCBVRFAgcG9ydCAoaS5lLiBkZWZhdWx0IFVyaS1Q b3J0IGFzIGRlZmluZWQgaW4NCj4NCj4gIFtJLUQuaWV0Zi1jb3JlLWNvYXBdKSwgb3IgdG8gYSBw b3J0IG51bWJlciBvYnRhaW5lZCB2aWEgYSBzZXJ2aWNlDQo+DQo+ICBkaXNjb3ZlcnkgbG9va3Vw IG9wZXJhdGlvbiBhcyBhIHZhbGlkIENvQVAgcG9ydCBmb3IgdGhlIHRhcmdldGVkDQo+DQo+ICBt dWx0aWNhc3QgZ3JvdXAuDQo+DQo+ICBvIEFsbCBDb0FQIG11bHRpY2FzdCByZXF1ZXN0cyBTSE9V TEQgb3BlcmF0ZSBvbmx5IG9uIFVSSXMgKGxpbmtzKQ0KPg0KPiAgd2hpY2ggd2VyZQ0KPg0KPiAv cyByZXRyZWl2ZWQgL3MgcmV0cmlldmVkDQo+DQo+ICBlaXRoZXIgZnJvbSBhICIvLndlbGwta25v d24vY29yZSIgbG9va3VwIG9uDQo+DQo+ICBhdCBsZWFzdCBvbmUgZ3JvdXAgbWVtYmVyIG5vZGUs IG9yIGZyb20gYW4gZXF1aXZhbGVudCBzZXJ2aWNlDQo+DQo+ICBkaXNjb3ZlcnkgbG9va3VwIHdo aWNoIHJldHVybnMgZWl0aGVyIHRoZSByZXNvdXJjZXMgc3VwcG9ydGVkIGJ5DQo+DQo+ICBhbGwg Z3JvdXAgbWVtYmVycyBvciByZXNvdXJjZXMgc3VwcG9ydGVkIGJ5IG9uZSBwYXJ0aWN1bGFyIGdy b3VwDQo+DQo+ICBtZW1iZXIuDQo+DQo+IC9jb21tZW50IHNvIHNldHRpbmcgYSBtdWx0aWNhc3Qg YWRkcmVzcyBpbiBhIHNvdXJjZSBhdCBpbnN0YWxsYXRpb24gaXMNCj4NCj4gZm9yYmlkZGVuPw0K Pg0KPiAzLjUuIENvbmZpZ3VyaW5nIEdyb3VwIE1lbWJlcnNoaXAgSW4gRW5kcG9pbnRzDQo+DQo+ ICBJbiBzb21lIHVzZSBjYXNlcywgdGhlIGdyb3VwIG1lbWJlcnNoaXAgb2YgZW5kcG9pbnRzIG5l ZWRzIHRvIGJlDQo+DQo+ICBjb25maWd1cmFibGUgYWZ0ZXIgdGhlIG5ldHdvcmsgaGFzIGJlZW4g ZGVwbG95ZWQuIEV4YW1wbGUgdXNlIGNhc2VzDQo+DQo+ICBjYW4gYmUgZm91bmQgaW4gYnVpbGRp bmcgY29udHJvbDogYSBjb21taXNzaW9uaW5nIHRvb2wgZGV0ZXJtaW5lcyB0bw0KPg0KPiAgd2hp Y2ggZ3JvdXBzIGEgbGlnaHQgb3Igc2Vuc29yIG5vZGUgYmVsb25ncywgYW5kIHdyaXRlcyB0aGlz DQo+DQo+ICBpbmZvcm1hdGlvbiB0byBhbGwgbm9kZXMsIHdoaWNoIGNhbiBzdWJzZXF1ZW50bHkg am9pbiB0aGUgY29ycmVjdA0KPg0KPiAgZ3JvdXAuDQo+DQo+ICBUbyBhY2hpZXZlIHNtb290aGVy IGludGVyb3BlcmFiaWxpdHkgYmV0d2VlbiBub2Rlcy9lbmRwb2ludHMgZnJvbQ0KPg0KPiAgZGlm ZmVyZW50IG1hbnVmYWN0dXJlcnMsIGl0IGlzIHByb3Bvc2VkIGhlcmUgdG8gZGVmaW5lIGFuIE9Q VElPTkFMDQo+DQo+ICBzdGFuZGFyZGl6ZWQgUkVTVGZ1bCBtZWFucyBvZiBjb25maWd1cmluZyBD b0FQIGVuZHBvaW50cyB3aXRoDQo+DQo+ICByZWxldmFudCBncm91cCBpbmZvcm1hdGlvbi4NCj4N Cj4gIENvQVAgZW5kcG9pbnRzIGltcGxlbWVudGluZyB0aGlzIG1lY2hhbmlzbSBNVVNUIHN1cHBv cnQgYQ0KPg0KPiAgZGlzY292ZXJhYmxlICJHcm91cCBDb25maWd1cmF0aW9uIiByZXNvdXJjZSBv ZiByZXNvdXJjZSB0eXBlIChydCkNCj4NCj4gIFtSRkM2NjkwXSAiY29yZS5ncCIuIFRoaXMgcmVz b3VyY2UgKGFuZCBwZXJoYXBzIGl0cyBzdWItcmVzb3VyY2VzLA0KPg0KPiAgVEJEKSBhcmUgdXNl ZCB0byBtYW5hZ2UgZ3JvdXAgbWVtYmVyc2hpcC4gVGhyZWUgZGVzaWduIG9wdGlvbnMgZm9yDQo+ DQo+ICB0aGlzIG1lY2hhbmlzbSBhcmUgcHJlc2VudGVkIGhlcmUgYXMgYSBwbGFjZWhvbGRlciAo VEJEKS4NCj4NCj4gIERlc2lnbiAxOiB1c2UgQ29SRSBsaW5rIGZvcm1hdCBwYXlsb2FkcyB0byBj b21tdW5pY2F0ZSBncm91cA0KPg0KPiAgbWVtYmVyc2hpcCB0byBlbmRwb2ludHMuIChUQkQgTm90 IGNsZWFyIGhvdyB0aGlzIHNob3VsZCBiZQ0KPg0KPiAgcmVhbGl6ZWQuKQ0KPg0KPiAvY29tbWVu dCwgbm90IGNsZWFyIHdoYXQgeW91IG1lYW4gZWl0aGVyLiBSZW1vdmUgZGVzaWduIDEgaW4gdGhp cw0KPiBzdGF0ZQ0KPg0KPiAgRGVzaWduIDI6IHVzZSBhIEpTT04gdHlwZSByZXNvdXJjZS4gRm9y IGV4YW1wbGUsIGEgR0VUIG9uIHRoZQ0KPg0KPiAgImNvcmUuZ3AiIHJlc291cmNlIHJldHVybnMg YSBKU09OIGFycmF5IG9mIGdyb3VwIG9iamVjdHMuDQo+DQo+ICBSZXE6IEdFVCAvZ3ANCj4NCj4g IFJlczogMi4wNSBDb250ZW50IChDb250ZW50LUZvcm1hdDogYXBwbGljYXRpb24vanNvbikNCj4N Cj4gIFsgeyAibiI6ICJSb29tLUEtTGlnaHRzLmZsb29yMS53ZXN0LmJsZGc2LmV4YW1wbGUuY29t IiwNCj4NCj4gICJpcCI6ICJmZjA1Ojo0MjAwOmY3ZmU6ZWQzNzoxNGNhIiB9DQo+DQo+ICBdDQo+ DQo+ICB3aGVyZSAibiIgZGVmaW5lcyB0aGUgR3JvdXAgRlFETiBhbmQgImlwIiBkZWZpbmVzIHRo ZSBhc3NvY2lhdGVkDQo+DQo+ICBtdWx0aWNhc3QgSVAgYWRkcmVzcy4gQXMgYSBuZXh0IGV4YW1w bGUsIHRoZSBzYW1lIGVuZHBvaW50IGNhbiBiZQ0KPg0KPiBSYWhtYW4gJiBEaWprIEV4cGlyZXMg QXByaWwgMjIsIDIwMTMgW1BhZ2UNCj4NCj4gOF0NCj4NCj4gSW50ZXJuZXQtRHJhZnQgR3JvdXAg Q29tbXVuaWNhdGlvbiBmb3IgQ29BUCBPY3RvYmVyDQo+DQo+IDIwMTINCj4NCj4gIGFkZGVkIHRv IGFub3RoZXIgZ3JvdXAgYnkgYSBQT1NUIG9uIHRoZSByZXNvdXJjZSB3aXRoIGEgSlNPTiBncm91 cA0KPg0KPiAgb2JqZWN0Og0KPg0KPiAgUmVxOiBQT1NUIC9ncCAoQ29udGVudC1Gb3JtYXQ6IGFw cGxpY2F0aW9uL2pzb24pDQo+DQo+ICB7ICJuIjogImZsb29yMS53ZXN0LmJsZGc2LmV4YW1wbGUu Y29tIiwNCj4NCj4gICJpcCI6ICJmZjA1Ojo0MjAwOmY3ZmU6ZWQzNzoxNGNiIiB9DQo+DQo+ICBS ZXM6IDIuMDQgQ2hhbmdlZA0KPg0KPiAgRGVzaWduIDM6IGRlZmluZSBuYW1lZCBzdWItcmVzb3Vy Y2VzLCBlYWNoIHN1Yi1yZXNvdXJjZSByZXByZXNlbnRpbmcNCj4NCj4gIGEgZ3JvdXAgbWVtYmVy c2hpcC4gVGhlIHBheWxvYWQgb2YgdGhlIHN1Yi1yZXNvdXJjZSBtYXkgYmUgSlNPTiBvcg0KPg0K PiBhDQo+DQo+ICBzaW1wbGUgcHJlLWRlZmluZWQgZm9ybWF0LiBPciBhbHRlcm5hdGl2ZWx5LCBp bmZvcm1hdGlvbiBpcw0KPg0KPiBwcm92aWRlZA0KPg0KPiAgdmlhIFBPU1Qgd2l0aCBxdWVyeSBw YXJhbWV0ZXJzLg0KPg0KPiAvY29tbWVudCBhcmUgdGhlc2UgbXV0dWFsbHkgZXhjbHVzaXZlIGRl c2lnbnM/DQo+DQo+IC9jb21tZW50IGRlc2lnbiAyIHdpdGhvdXQgSlNPTiBpcyBhbHMgcG9zc2li bGUNCj4NCj4gL2NvbW1lbnQgZGVzaWduIHdpdGggU1JWIGFuZCBUWHQgcmVjb3JkcyBpcyBhbHNv IHBvc3NpYmxlDQo+DQo+IC9jb21tZW50IHRoZXJlIGFyZSAyIHdheXM6ICgxKSB0aGUgbm9kZSBx dWVyaWVzIHRvIHdoaWNoIGdyb3VwIGl0DQo+DQo+IGJlbG9uZ3MNCj4NCj4gL2NvbW1lbnQgKDIp IGFuIGluc3RhbGF0aW9uIHRvb2xzIGluc3RydWN0cyB0aGUgbm9kZSB0byB3aGljaCBncm91cHMN Cj4NCj4gaXQgYmVsb25ncw0KPg0KPiAvY29tbWVudCBub3QgY2xlYXIgaW4gdGV4dCB0aGF0IHRo aXMgY2hvaWNlIGV4aXN0cyBvciB0aGF0IGEgY2hvaWNlDQo+IHdhcw0KPg0KPiBtYWRlLg0KPg0K PiAzLjYuIENvbmdlc3Rpb24gQ29udHJvbA0KPg0KPiAgTXVsdGljYXN0IENvQVAgcmVxdWVzdHMg bWF5IHJlc3VsdCBpbiBhIG11bHRpdHVkZSBvZiByZXBsaWVzIGZyb20NCj4NCj4gIGRpZmZlcmVu dCBub2RlcywgcG90ZW50aWFsbHkgY2F1c2luZyBjb25nZXN0aW9uLiBUaGVyZWZvcmUgc2VuZGlu Zw0KPg0KPiAgbXVsdGljYXN0DQo+DQo+IC9zIHJlcXVlc3RzIC9zIHJlcGxpZXMNCj4NCj4gIHNo b3VsZCBiZSBjb25zZXJ2YXRpdmVseSBjb250cm9sbGVkLg0KPg0KPiAgVGhlIGJhc2UgQ29BUCBk cmFmdCBbSS1ELmlldGYtY29yZS1jb2FwXSByZWR1Y2VzIG11bHRpY2FzdC1zcGVjaWZpYw0KPg0K PiAgY29uZ2VzdGlvbiByaXNrcyB0aHJvdWdoIHRoZSBmb2xsb3dpbmcgbWVhc3VyZXM6DQo+DQo+ ICBvIEEgc2VydmVyIE1BWSBjaG9vc2Ugbm90IHRvIHJlc3BvbmQgdG8gYSBtdWx0aWNhc3QgcmVx dWVzdCBpZg0KPg0KPiAgdGhlcmUncyBub3RoaW5nIHVzZWZ1bCB0byByZXNwb25kIChlLmcuIGVy cm9yIG9yIGVtcHR5IHJlc3BvbnNlKS4NCj4NCj4gIG8gQSBzZXJ2ZXIgU0hPVUxEIGxpbWl0IHRo ZSBzdXBwb3J0IGZvciBtdWx0aWNhc3QgcmVxdWVzdHMgdG8NCj4NCj4gIHNwZWNpZmljIHJlc291 cmNlcyB3aGVyZSBtdWx0aWNhc3Qgb3BlcmF0aW9uIGlzIHJlcXVpcmVkLg0KPg0KPiAgbyBBIG11 bHRpY2FzdCByZXF1ZXN0IE1VU1QgYmUgTm9uLUNvbmZpcm1hYmxlLg0KPg0KPiAvY29tbWVudCB3 aGF0IGFib3V0IHRoZSByZXBseT8NCj4NCj4gIG8gQSBzZXJ2ZXIgZG9lcyBub3QgcmVzcG9uZCBp bW1lZGlhdGVseSB0byBhIG11bHRpY2FzdCByZXF1ZXN0LCBidXQNCj4NCj4gIFNIT1VMRCBmaXJz dCB3YWl0IGZvciBhIHRpbWUgdGhhdCBpcyByYW5kb21seSBwaWNrZWQgd2l0aGluIGENCj4NCj4g IHByZWRldGVybWluZWQgdGltZSBpbnRlcnZhbCBjYWxsZWQgdGhlIExlaXN1cmUuDQo+DQo+ICBv IEEgc2VydmVyIFNIT1VMRCBOT1QgYWNjZXB0IG11bHRpY2FzdCByZXF1ZXN0cyB0aGF0IGNhbiBu b3QgYmUNCj4NCj4gIGF1dGhlbnRpY2F0ZWQuDQo+DQo+IC9jb21tZW50IGludm9raW5nIGFzIG1h bnkgY2VydGlmaWNhdGVzPw0KPg0KPiAgQWRkaXRpb25hbCBndWlkZWxpbmVzIHRvIHJlZHVjZSBj b25nZXN0aW9uIHJpc2tzIGFyZToNCj4NCj4gIG8gQSBzZXJ2ZXIgaW4gYW4gTExOIHNob3VsZCBv bmx5IHN1cHBvcnQgbXVsdGljYXN0IEdFVCBmb3INCj4NCj4gcmVzb3VyY2VzDQo+DQo+ICB0aGF0 IGFyZSBzbWFsbCwgZS5nLg0KPg0KPiAvcmVtb3ZlIGZvciBhbiBMTE4gdGhhdCBjb3VsZCBtZWFu DQo+DQo+ICB0aGUgcGF5bG9hZCBvZiB0aGUNCj4NCj4gIHJlc3BvbnNlIGZpdHMgaW50byBhIHNp bmdsZSBsaW5rLWxheWVyIGZyYW1lLg0KPg0KPiAgbyBBIHNlcnZlciBjYW4gbWluaW1pemUgdGhl IHBheWxvYWQgbGVuZ3RoIGluIHJlc3BvbnNlIHRvIGENCj4NCj4gIG11bHRpY2FzdCBHRVQgb24g Ii8ud2VsbC1rbm93bi9jb3JlIiBieSB1c2luZyBoaWVyYXJjaHkgaW4NCj4NCj4gIGFycmFuZ2lu ZyBsaW5rIGRlc2NyaXB0aW9ucyBmb3IgdGhlIHJlc3BvbnNlLiBBbiBleGFtcGxlIG9mIHRoaXMN Cj4NCj4gIGlzIGdpdmVuIGluIFNlY3Rpb24gNSBvZiBbUkZDNjY5MF0uDQo+DQo+IFJhaG1hbiAm IERpamsgRXhwaXJlcyBBcHJpbCAyMiwgMjAxMyBbUGFnZQ0KPg0KPiA5XQ0KPg0KPiBJbnRlcm5l dC1EcmFmdCBHcm91cCBDb21tdW5pY2F0aW9uIGZvciBDb0FQIE9jdG9iZXINCj4NCj4gMjAxMg0K Pg0KPiAgbyBQcmVmZXJhYmx5IElQIG11bHRpY2FzdCB3aXRoIGxpbmstbG9jYWwgc2NvcGUgc2hv dWxkIGJlIHVzZWQsDQo+DQo+ICByYXRoZXIgdGhhbiBnbG9iYWwgb3Igc2l0ZS1sb2NhbC4NCj4N Cj4gIG8gVGhlIEhvcCBMaW1pdCBmaWVsZCBpbiB0aGUgSVB2NiBwYWNrZXQgc2hvdWxkIGJlIGNo b3NlbiBhcyBsb3cgYXMNCj4NCj4gIHBvc3NpYmxlIChpZiB0aGUgQ29BUC9JUCBzdGFjayBhbGxv d3Mgc2V0dGluZyBvZiB0aGlzIHZhbHVlLiBUQkQNCj4NCj4gIC0gZGlzY3VzcyB3aGV0aGVyIHRo aXMgZ3VpZGVsaW5lIGlzIHJlbGV2YW50L3JlYWxpc3RpYyBpbiBDb0FQDQo+DQo+ICBjb250ZXh0 KQ0KPg0KPiAzLjcuIENvQVAgTXVsdGljYXN0IGFuZCBIVFRQIFVuaWNhc3QgSW50ZXJ3b3JraW5n DQo+DQo+IC9jb21tZW50IGEgcmVmZXJlbmNlIHdpbGwgc3VmZmljZQ0KPg0KPiAgQ29BUCBzdXBw b3J0cyBvcGVyYXRpb24gb3ZlciBVRFAgbXVsdGljYXN0LCB3aGlsZSBIVFRQIGRvZXMgbm90Lg0K Pg0KPiBGb3INCj4NCj4gIHVzZSBjYXNlcyB3aGVyZSBpdCBpcyByZXF1aXJlZCB0aGF0IENvQVAg Z3JvdXAgY29tbXVuaWNhdGlvbiBpcw0KPg0KPiAgaW5pdGlhdGVkIGZyb20gYW4gSFRUUCBlbmQt cG9pbnQsIGl0IHdvdWxkIGJlIGFkdmFudGFnZW91cyBpZiB0aGUNCj4NCj4gIEhUVFAtQ29BUCBQ cm94eSBzdXBwb3J0cyBtYXBwaW5nIG9mIEhUVFAgdW5pY2FzdCB0byBDb0FQIGdyb3VwDQo+DQo+ ICBjb21tdW5pY2F0aW9uIGJhc2VkIG9uIElQIG11bHRpY2FzdC4NCj4NCj4gL3JlbW92ZSBPbmUg cG9zc2libGUgd2F5IG9mIG9wZXJhdGlvbg0KPg0KPiAvcmVtb3ZlIG9mIHN1Y2ggSFRUUC1Db0FQ IFByb3h5IGlzIGlsbHVzdHJhdGVkIGluIEZpZ3VyZSAxLg0KPg0KPiAgTm90ZSB0aGF0IHRoaXMN Cj4NCj4gIHRvcGljIGlzIGNvdmVyZWQgaW4gbW9yZSBkZXRhaWwgaW4NCj4NCj4gIFtJLUQuY2Fz dGVsbGFuaS1jb3JlLWFkdmFuY2VkLWh0dHAtbWFwcGluZ10uDQo+DQo+IC9yZW1vdmUNCj4NCj4g IENvQVAgTWNhc3QgQ29BUCBNY2FzdCBIVFRQLUNvQVAgSFRUUA0KPg0KPiAgTm9kZSAxIFJ0cjEg Tm9kZSAyIFJ0cjIgUHJveHkgTm9kZSAzDQo+DQo+ICB8IHwgfCB8IHwgfA0KPg0KPiAgfE1MRCBS RVFVRVNUIHwgfCB8IHwNCj4NCj4gIHwoSm9pbiBHcm91cCBYKSB8IHwgfCB8DQo+DQo+ICB8LS1M TC0tPnwgfCB8IHwgfA0KPg0KPiAgfCB8IHxNTEQgUkVRVUVTVCB8IHwNCj4NCj4gIHwgfCB8KEpv aW4gR3JvdXAgWCkgfCB8DQo+DQo+ICB8IHwgfC0tTEwtLT58IHwgfA0KPg0KPiAgfCB8IHwgfCB8 IEhUVFAgUkVRVUVTVCB8DQo+DQo+ICB8IHwgfCB8IHwgKFVSSSB0byB8DQo+DQo+ICB8IHwgfCB8 IHwgdW5pY2FzdCBhZGRyKSB8DQo+DQo+ICB8IHwgfCB8IHw8IC0tLS0tLS0tLS0tLS0tLS0tfA0K Pg0KPiAgfCB8IHwgfCB8IHwNCj4NCj4gIHwgfCB8IFJlc29sdmUgSFRUUCBSZXF1ZXN0LUxpbmUg VVJJIHwNCj4NCj4gIHwgfCB8IHRvIEdyb3VwIFggbXVsdGljYXN0IGFkZHJlc3MgfA0KPg0KPiAg fCB8IHwgfCB8IHwNCj4NCj4gIHwgQ29BUCBSRVFVRVNUICh0byBtdWx0aWNhc3QgYWRkcil8IHwN Cj4NCj4gIHw8IC0tLS0tLTwtLS0tLS0tLS08LS0tLS0tLTwtLS0tLS18IHwNCj4NCj4gIHwgfCB8 IHwgfCB8DQo+DQo+ICB8IHwgfCB8DQo+DQo+ICB8IChvcHRpb25hbCkgQ29BUCBSRVNQT05TRShz KSB8IHwNCj4NCj4gIHwgfC0tLS0tLS0tLS0tLS0tPnwgfA0KPg0KPiAgfC0tLS0tLS0tLS0tLS0t LS0tfC0tLS0tLS0tLS0tLS0tPnwgQWdncmVnYXRlZCB8DQo+DQo+ICB8IHwgfCBIVFRQIFJFU1BP TlNFIHwNCj4NCj4gIHwgfCB8LS0tLS0tLS0tLS0tLS0tLS0tPnwNCj4NCj4gIHwgfCB8IHwNCj4N Cj4gUmFobWFuICYgRGlqayBFeHBpcmVzIEFwcmlsIDIyLCAyMDEzIFtQYWdlDQo+DQo+IDEwXQ0K Pg0KPiBJbnRlcm5ldC1EcmFmdCBHcm91cCBDb21tdW5pY2F0aW9uIGZvciBDb0FQIE9jdG9iZXIN Cj4NCj4gMjAxMg0KPg0KPiAgRmlndXJlIDE6IENvQVAgTXVsdGljYXN0IGFuZCBIVFRQIFVuaWNh c3QgSW50ZXJ3b3JraW5nDQo+DQo+ICBOb3RlIHRoYXQgRmlndXJlIDEgaWxsdXN0cmF0ZXMgdGhl IGNhc2Ugb2YgSVAgbXVsdGljYXN0IGFzIHRoZQ0KPg0KPiAgdW5kZXJseWluZyBncm91cCBjb21t dW5pY2F0aW9ucyBtZWNoYW5pc20uIE1MRCBkZW5vdGVzIHRoZQ0KPg0KPiBNdWx0aWNhc3QNCj4N Cj4gIExpc3RlbmVyIERpc2NvdmVyeSBwcm90b2NvbCAoW1JGQzM4MTBdLCBBcHBlbmRpeCBBKSBh bmQgTEwgZGVub3RlcyBhDQo+DQo+ICBMaW5rLUxvY2FsIG11bHRpY2FzdC4NCj4NCj4gIEEga2V5 IHBvaW50IGluIEZpZ3VyZSAxIGlzIHRoYXQgdGhlIGluY29taW5nIEhUVFAgUmVxdWVzdCAoZnJv bSBub2RlDQo+DQo+ICAzKSB3aWxsIGNhcnJ5IGEgSG9zdCByZXF1ZXN0LWhlYWRlciBmaWVsZCB0 aGF0IHJlc29sdmVzIGluIHRoZQ0KPg0KPiAgZ2VuZXJhbCBJbnRlcm5ldCB0byB0aGUgcHJveHkg bm9kZS4gQXQgdGhlIHByb3h5IG5vZGUsIHRoaXMNCj4NCj4gaG9zdG5hbWUNCj4NCj4gIGFuZC9v ciB0aGUgUmVxdWVzdC1MaW5lIFVSSSB3aWxsIHRoZW4gcG9zc2libHkgYmUgbWFwcGVkIChhcw0K Pg0KPiBkZXRhaWxlZA0KPg0KPiAgaW4gW0ktRC5jYXN0ZWxsYW5pLWNvcmUtaHR0cC1tYXBwaW5n XSkgYW5kIGFnYWluIHJlc29sdmVkICh3aXRoIHRoZQ0KPg0KPiAgQ29BUCBzY2hlbWUpIHRvIGFu IElQIG11bHRpY2FzdCBhZGRyZXNzLiBUaGlzIG1heSBiZSBhY2NvbXBsaXNoZWQsDQo+DQo+ICBm b3IgZXhhbXBsZSwgYnkgdXNpbmcgRE5TIG9yIEROUy1TRCAoU2VjdGlvbiAzLjMpLiBUaGUgcHJv eHkgbm9kZQ0KPg0KPiAgd2lsbCB0aGVuIElQIG11bHRpY2FzdCB0aGUgQ29BUCBSZXF1ZXN0IChj b3JyZXNwb25kaW5nIHRvIHRoZQ0KPg0KPiAgcmVjZWl2ZWQgSFRUUCBSZXF1ZXN0KSB2aWEgbXVs dGljYXN0IHJvdXRlcnMgdG8gdGhlIGFwcHJvcHJpYXRlDQo+DQo+IG5vZGVzDQo+DQo+ICAoaS5l LiBub2RlcyAxIGFuZCAyKS4NCj4NCj4gIEluIHRlcm1zIG9mIHRoZSBIVFRQIFJlc3BvbnNlLCBG aWd1cmUgMSBpbGx1c3RyYXRlcyB0aGF0IGl0IHdpbGwgYmUNCj4NCj4gIGdlbmVyYXRlZCBieSB0 aGUgcHJveHkgbm9kZSBiYXNlZCBvbiBhZ2dyZWdhdGVkIHJlc3BvbnNlcyBvZiB0aGUNCj4NCj4g Q29BUA0KPg0KPiAgbm9kZXMgYW5kIHNlbnQgYmFjayB0byB0aGUgY2xpZW50IGluIHRoZSBnZW5l cmFsIEludGVybmV0IHRoYXQgc2VudA0KPg0KPiAgdGhlIEhUVFAgUmVxdWVzdCAoaS5lLiBub2Rl IDEpLiBJbg0KPg0KPiAgW0ktRC5jYXN0ZWxsYW5pLWNvcmUtYWR2YW5jZWQtaHR0cC1tYXBwaW5n XSB0aGUgSFRUUCBSZXNwb25zZSB0aGF0DQo+DQo+ICB0aGUgUHJveHkgbWF5IHVzZSB0byBhZ2dy ZWdhdGUgbXVsdGlwbGUgQ29BUCByZXNwb25zZXMgaXMgZGVzY3JpYmVkDQo+DQo+ICBpbiBtb3Jl IGRldGFpbC4gU28gaW4gdGVybXMgb2Ygb3ZlcmFsbCBvcGVyYXRpb24sIHRoZSBDb0FQIHByb3h5 DQo+DQo+IGNhbg0KPg0KPiAgYmUgY29uc2lkZXJlZCB0byBiZSBhICJub24tdHJhbnNwYXJlbnQi IHByb3h5IGFjY29yZGluZyB0bw0KPg0KPiBbUkZDMjYxNl0uDQo+DQo+ICBTcGVjaWZpY2FsbHks IFtSRkMyNjE2XSBzdGF0ZXMgdGhhdCBhICJub24tdHJhbnNwYXJlbnQgcHJveHkgaXMgYQ0KPg0K PiAgcHJveHkgdGhhdCBtb2RpZmllcyB0aGUgcmVxdWVzdCBvciByZXNwb25zZSBpbiBvcmRlciB0 byBwcm92aWRlIHNvbWUNCj4NCj4gIGFkZGVkIHNlcnZpY2UgdG8gdGhlIHVzZXIgYWdlbnQsIHN1 Y2ggYXMgZ3JvdXAgYW5ub3RhdGlvbiBzZXJ2aWNlcywNCj4NCj4gIG1lZGlhIHR5cGUgdHJhbnNm b3JtYXRpb24sIHByb3RvY29sIHJlZHVjdGlvbiBvciBhbm9ueW1pdHkNCj4NCj4gIGZpbHRlcmlu Zy4iDQo+DQo+ICBBbiBhbHRlcm5hdGl2ZSB0byB0aGUgYWJvdmUgaXMgdXNpbmcgYSBGb3J3YXJk IFByb3h5LiBJbiB0aGlzIGNhc2UsDQo+DQo+ICB0aGUgQ29BUCByZXF1ZXN0IFVSSSBpcyBjYXJy aWVkIGluIHRoZSBIVFRQIFJlcXVlc3QtTGluZSAoYXMgZGVmaW5lZA0KPg0KPiAgaW4gW0ktRC5p ZXRmLWNvcmUtY29hcF0gU2VjdGlvbiAxMC4yKSBpbiBhIEhUVFAgcmVxdWVzdCBzZW50IHRvIHRo ZQ0KPg0KPiAgSVAgYWRkcmVzcyBvZiB0aGUgUHJveHkuDQo+DQo+IC9lbmQgcmVtb3ZlDQo+DQo+ IDQuIFVzZSBDYXNlcyBhbmQgQ29ycmVzcG9uZGluZyBQcm90b2NvbCBGbG93cw0KPg0KPiA0LjEu IEludHJvZHVjdGlvbg0KPg0KPiAgVGhlIHVzZSBvZiBDb0FQIGdyb3VwIGNvbW11bmljYXRpb24g aXMgc2hvd24gaW4gdGhlIGNvbnRleHQgb2YgdGhlDQo+DQo+ICBmb2xsb3dpbmcgdXNlIGNhc2Vz IGFuZCBjb3JyZXNwb25kaW5nIHByb3RvY29sIGZsb3dzOg0KPg0KPiAgbyBEaXNjb3Zlcnkgb2Yg UmVzb3VyY2UgRGlyZWN0b3J5OiBkaXNjb3ZlcmluZyB0aGUgbG9jYWwgQ29SRSBSRA0KPg0KPiAg d2hpY2ggY29udGFpbnMgbGlua3MgKFVSSXMpIHRvIHJlc291cmNlcyBzdG9yZWQgb24gb3RoZXIg c2VydmVycw0KPg0KPiAgW1JGQzY2OTBdLg0KPg0KPiBSYWhtYW4gJiBEaWprIEV4cGlyZXMgQXBy aWwgMjIsIDIwMTMgW1BhZ2UNCj4NCj4gMTFdDQo+DQo+IEludGVybmV0LURyYWZ0IEdyb3VwIENv bW11bmljYXRpb24gZm9yIENvQVAgT2N0b2Jlcg0KPg0KPiAyMDEyDQo+DQo+ICBvIExpZ2h0aW5n IENvbnRyb2w6IHN5bmNocm9ub3VzIG9wZXJhdGlvbiBvZiBhIGdyb3VwIG9mIDZMb1dQQU4NCj4N Cj4gIFtSRkM0OTQ0XSBJUHY2LWNvbm5lY3RlZCBsaWdodHMNCj4NCj4gIG8gUGFyYW1ldGVyIFVw ZGF0ZTogdXBkYXRpbmcgcGFyYW1ldGVycy9zZXR0aW5ncyBzaW11bHRhbmVvdXNseSBpbg0KPg0K PiBhDQo+DQo+ICBsYXJnZSBncm91cCBvZiBkZXZpY2VzIGluIGEgYnVpbGRpbmcvY2FtcHVzIGNv bnRyb2wNCj4NCj4gIChbSS1ELnZhbmRlcnN0b2stY29yZS1iY10pIGFwcGxpY2F0aW9uIC0tLSBU QkQNCj4NCj4gLyBjb21tZW50IEkgc3VnZ2VzdCB0byByZW1vdmUgRmlybXdhcmUgVXBkYXRlIGFu ZCBHcm91cHMgc3RhdHVzIHJlcG9ydA0KPg0KPiAvY29tbWVudCB0aGUgb25lcyBhYm92ZSBhcmUg ZGlmZmljdWx0IGVub3VnaCwgYW5kIEkgZG91YnQgdGhhdA0KPg0KPiBzaW11bHRhbmVpdHkNCj4N Cj4gL2NvbW1lbnQgKG1vdGl2YXRpb24gb2YgbXVsdGljYXN0KSBpcyBpbnZvbHZlZCBoZXJlDQo+ DQo+ICBvIEZpcm13YXJlIFVwZGF0ZTogZWZmaWNpZW50bHkgdXBkYXRpbmcgZmlybXdhcmUgc2lt dWx0YW5lb3VzbHkgaW4NCj4NCj4gYQ0KPg0KPiAgbGFyZ2UgZ3JvdXAgb2YgZGV2aWNlcyBpbiBh IGJ1aWxkaW5nL2NhbXB1cyBjb250cm9sDQo+DQo+ICAoW0ktRC52YW5kZXJzdG9rLWNvcmUtYmNd KSBhcHBsaWNhdGlvbiAtLS0gVEJEIHN1Z2dlc3RzIGENCj4NCj4gIG11bHRpY2FzdCBleHRlbnNp b24gb2YgY29yZS1ibG9jay4NCj4NCj4gIG8gR3JvdXAgU3RhdHVzIFJlcG9ydDogcmVxdWVzdGlu ZyBzdGF0dXMgaW5mb3JtYXRpb24gb3IgZXZlbnQNCj4NCj4gIHJlcG9ydHMgZnJvbSBhIGdyb3Vw IG9mIGRldmljZXMgaW4gYSBidWlsZGluZy9jYW1wdXMgY29udHJvbA0KPg0KPiAgYXBwbGljYXRp b24gLS0tIFRCRCwgbWF5IHJlcXVpcmUgcmVsaWFibGUgZ3JvdXAgY29tbXVuaWNhdGlvbiB0bw0K Pg0KPiAgYmUgZmVhc2libGUuDQo+DQo+IDQuMi4gTmV0d29yayBDb25maWd1cmF0aW9uDQo+DQo+ ICBXZSBhc3N1bWUgdGhlIGZvbGxvd2luZyBuZXR3b3JrIGNvbmZpZ3VyYXRpb24gZm9yIGFsbCB0 aGUgdXNlIGNhc2VzDQo+DQo+ICBhcyBzaG93biBpbiBGaWd1cmUgMjoNCj4NCj4gL2NvbW1lbnQg dGhlIGNvbmZpZ3VyYXRpb25zIGZyaWdodGVuIG1lDQo+DQo+IC9jb21tZW50IGZyb20gY29tcGxl dGVuZXNzIGNvbnNpZGVyYXRpb25zIEkgY2FuIGltYWdpbmUgZXZlbiBtb3JlDQo+DQo+IGNvbXBs ZXggb25lcw0KPg0KPiAvY29tbWVudCBJdCBtaWdodCBiZSB1c2VmdWwgaWYgdGhlIHByYWN0aWNh bCBpbXBvc3NpYmlsaXR5IG9mIHNvbWUNCj4NCj4gY29uZmlndXJhdGlvbnMgaXMgaGlnaCBsaWdo dGVkDQo+DQo+ICBvIEEgbGFyZ2Ugcm9vbSAoUm9vbS1BKSB3aXRoIHRocmVlIGxpZ2h0cyAoTGln aHQtMSwgTGlnaHQtMiwNCj4NCj4gIExpZ2h0LTMpIGNvbnRyb2xsZWQgYnkgYSBMaWdodCBTd2l0 Y2guIFRoZSBkZXZpY2VzIGFyZSBvcmdhbml6ZWQNCj4NCj4gIGludG8gdHdvIDZMb1dQQU4gc3Vi bmV0cy4NCj4NCj4gL2NvbW1lbnQgb25lIHN1Ym5ldCBpcyBlbm91Z2ggZm9yIG1lDQo+DQo+IC9y ZW1vdmUNCj4NCj4gIG8gTGlnaHQtMSBhbmQgdGhlIExpZ2h0IFN3aXRjaCBhcmUgY29ubmVjdGVk IHRvIGEgcm91dGVyIChSdHItMSkNCj4NCj4gIHdoaWNoIGlzIGFsc28gYSBDb0FQIFByb3h5LCBh IENvQVAgUmVzb3VyY2UgRGlyZWN0b3J5IChSRCkgYW5kIGENCj4NCj4gIDZMb1dQQU4gQm9yZGVy IFJvdXRlciAoNkxCUikuDQo+DQo+ICBvIExpZ2h0LTIgYW5kIHRoZSBMaWdodC0zIGFyZSBjb25u ZWN0ZWQgdG8gYW5vdGhlciByb3V0ZXIgKFJ0ci0yKQ0KPg0KPiAgd2hpY2ggaXMgYWxzbyBhIENv QVAgUHJveHksIGEgQ29BUCBSRCBhbmQgYSA2TEJSLg0KPg0KPiAgbyBUaGUgcm91dGVycyBhcmUg Y29ubmVjdGVkIHRvIGFuIElQdjYgbmV0d29yayBiYWNrYm9uZSB3aGljaCBpcw0KPg0KPiAgYWxz byBtdWx0aWNhc3QgZW5hYmxlZC4gSW4gdGhlIGdlbmVyYWwgY2FzZSwgdGhpcyBtZWFucyB0aGUN Cj4NCj4gIG5ldHdvcmsgYmFja2JvbmUgYW5kIDZMQlJzIHN1cHBvcnQgYSBQSU0gYmFzZWQgbXVs dGljYXN0IHJvdXRpbmcNCj4NCj4gIHByb3RvY29sLCBhbmQgTUxEIGZvciBmb3JtaW5nIGdyb3Vw cy4gSW4gYSBsaW1pdGVkIGNhc2UsIGlmIHRoZQ0KPg0KPiAgbmV0d29yayBiYWNrYm9uZSBpcyBv bmUgbGluaywgdGhlbiB0aGUgcm91dGVycyBvbmx5IGhhdmUgdG8NCj4NCj4gIHN1cHBvcnQgTUxE LXNub29waW5nIChBcHBlbmRpeCBBKSBmb3IgdGhlIGZvbGxvd2luZyB1c2UgY2FzZXMgdG8NCj4N Cj4gIHdvcmsuDQo+DQo+IC9lbmQgcmVtb3ZlDQo+DQo+IC9jb21tZW50IEkgY2FuIGltYWdpbmUg dGhhdCBhbiBjZW50cmFsIGNvbnRyb2wgaXMgcHJlc2VudCBvbiB0aGUNCj4NCj4gYmFja2JvbmUN Cj4NCj4gL2NvbW1lbnQgc3dpdGNoIG9yIHNlbnNvciBzZW5kIHVuaWNhc3QgdG8gY2VudHJhbCBj b250cm9sDQo+DQo+IC9jb21tZW50IGNlbnRyYWwgY29udHJvbCBzZW5kcyBtdWx0aWNhc3QgdG8g bXVsdGljYXN0IGdyb3VwIHdpdGhpbg0KPg0KPiBzaW5nbGUgbG93cGFuDQo+DQo+IFJhaG1hbiAm IERpamsgRXhwaXJlcyBBcHJpbCAyMiwgMjAxMyBbUGFnZQ0KPg0KPiAxMl0NCj4NCj4gSW50ZXJu ZXQtRHJhZnQgR3JvdXAgQ29tbXVuaWNhdGlvbiBmb3IgQ29BUCBPY3RvYmVyDQo+DQo+IDIwMTIN Cj4NCj4gTmV0d29yaw0KPg0KPiBCYWNrYm9uZQ0KPg0KPiB8DQo+DQo+ICAjIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMNCj4NCj4gfA0KPg0KPiAgIyBSb29t LUEgIw0KPg0KPiB8DQo+DQo+ICAjICoqKioqKioqKioqKioqKioqKioqKiogIw0KPg0KPiB8DQo+ DQo+ICAjICoqIExvV1BBTi0xIChzdWJuZXQtMSkgKiogIw0KPg0KPiB8DQo+DQo+ICAjICogKiAj DQo+DQo+IHwNCj4NCj4gICMgKiArLS0tLS0tLS0tLSsgKiAjDQo+DQo+IHwNCj4NCj4gICMgKiB8 IExpZ2h0IHwtLS0tLS0tKyAqICMNCj4NCj4gfA0KPg0KPiAgIyAqIHwgU3dpdGNoIHwgfCAqICMN Cj4NCj4gfA0KPg0KPiAgIyAqICstLS0tLS0tLS0tKyArLS0tLS0tLS0tKyAqICMNCj4NCj4gfA0K Pg0KPiAgIyAqIHwgUnRyLTENCj4NCj4gfC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tfA0K Pg0KPiAgIyAqICstLS0tLS0tLS0rICogIw0KPg0KPiB8DQo+DQo+ICAjICogKy0tLS0tLS0tLS0r IHwgKiAjDQo+DQo+IHwNCj4NCj4gICMgKiB8IExpZ2h0LTEgfC0tLS0tLS0tKyAqICMNCj4NCj4g fA0KPg0KPiAgIyAqICstLS0tLS0tLS0tKyAqICMNCj4NCj4gfA0KPg0KPiAgIyAqICogIw0KPg0K PiB8DQo+DQo+ICAjICoqICoqICMNCj4NCj4gfA0KPg0KPiAgIyAqKioqKioqKioqKioqKioqKioq KioqICMNCj4NCj4gfA0KPg0KPiAgIyAjDQo+DQo+IHwNCj4NCj4gICMgIw0KPg0KPiB8DQo+DQo+ ICAjICoqKioqKioqKioqKioqKioqKioqKiogIw0KPg0KPiB8DQo+DQo+ICAjICoqIExvV1BBTi0y IChzdWJuZXQtMikgKiogIw0KPg0KPiB8DQo+DQo+ICAjICogKiAjDQo+DQo+IHwNCj4NCj4gICMg KiArLS0tLS0tLS0tLSsgKiAjDQo+DQo+IHwNCj4NCj4gICMgKiB8IExpZ2h0LTIgfC0tLS0tLS0r ICogIw0KPg0KPiB8DQo+DQo+ICAjICogfCB8IHwgKiAjDQo+DQo+IHwNCj4NCj4gICMgKiArLS0t LS0tLS0tLSsgKy0tLS0tLS0tLSsgKiAjDQo+DQo+IHwNCj4NCj4gICMgKiB8IFJ0ci0yDQo+DQo+ IHwtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLXwNCj4NCj4gICMgKiArLS0tLS0tLS0tKyAq ICMNCj4NCj4gfA0KPg0KPiAgIyAqICstLS0tLS0tLS0tKyB8ICogIw0KPg0KPiB8DQo+DQo+ICAj ICogfCBMaWdodC0zIHwtLS0tLS0tLSsgKiAjDQo+DQo+IHwNCj4NCj4gICMgKiArLS0tLS0tLS0t LSsgKiAjDQo+DQo+IHwNCj4NCj4gICMgKiAqICMNCj4NCj4gfA0KPg0KPiAgIyAqKiAqKiAjDQo+ DQo+IHwNCj4NCj4gICMgKioqKioqKioqKioqKioqKioqKioqKiAjDQo+DQo+IHwNCj4NCj4gICMg Iw0KPg0KPiB8DQo+DQo+ICAjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjDQo+DQo+IHwNCj4NCj4gfA0KPg0KPiAgKy0tLS0tLS0tKw0KPg0KPiB8DQo+DQo+ ICB8IEROUw0KPg0KPiB8LS0tLS0tLS0tLS0tLS0tLS0tfA0KPg0KPiAgfCBTZXJ2ZXIgfA0KPg0K PiAgKy0tLS0tLS0tKw0KPg0KPiAgRmlndXJlIDI6IE5ldHdvcmsgVG9wb2xvZ3kgb2YgYSBMYXJn ZSBSb29tIChSb29tLUEpDQo+DQo+IFJhaG1hbiAmIERpamsgRXhwaXJlcyBBcHJpbCAyMiwgMjAx MyBbUGFnZQ0KPg0KPiAxM10NCj4NCj4gSW50ZXJuZXQtRHJhZnQgR3JvdXAgQ29tbXVuaWNhdGlv biBmb3IgQ29BUCBPY3RvYmVyDQo+DQo+IDIwMTINCj4NCj4gNC4zLiBEaXNjb3Zlcnkgb2YgUmVz b3VyY2UgRGlyZWN0b3J5DQo+DQo+ICBUaGUgcHJvdG9jb2wgZmxvdyBmb3IgZGlzY292ZXJ5IG9m IGEgUkQgZm9yIHRoZSBnaXZlbiBuZXR3b3JrIChvZg0KPg0KPiAgRmlndXJlIDIpIGlzIHNob3du IGluIEZpZ3VyZSAzOg0KPg0KPiAgbyBUaGUgZml4dHVyZSBmb3IgTGlnaHQtMiBpcyBpbnN0YWxs ZWQgYW5kIHBvd2VyZWQgb24gZm9yIHRoZSBmaXJzdA0KPg0KPiAgdGltZS4NCj4NCj4gIG8gTGln aHQtMiB3aWxsIHRoZW4gc2VhcmNoIGZvciB0aGUgbG9jYWwgUkQgKFJELTIpIGJ5IHNlbmRpbmcg b3V0IGENCj4NCj4gIEdFVCByZXF1ZXN0ICh3aXRoIHRoZSAiLy53ZWxsLWtub3duL2NvcmU/cnQ9 Y29yZS5yZCIgcmVxdWVzdCBVUkkpDQo+DQo+ICB0byB0aGUgc2l0ZS1sb2NhbCAiQWxsIENvQVAg Tm9kZXMiIGFkZHJlc3MuIEluIHRoaXMgY2FzZSwgdGhlDQo+DQo+ICBzaXRlIGlzIGFzc3VtZWQg dG8gaW5jbHVkZSBhbGwgbm9kZXMgaW4gdGhlIHN1Ym5ldC4NCj4NCj4gIG8gVGhpcyBtdWx0aWNh c3QgbWVzc2FnZSB3aWxsIHRoZW4gZ28gdG8gZWFjaCBub2RlIGluIHN1Ym5ldC0yLg0KPg0KPiAg SG93ZXZlciwgb25seSBSdHItMiAoUkQtMikgd2lsbCByZXNwb25kIGJlY2F1c2UgdGhlIEdFVCBp cw0KPg0KPiAgcXVhbGlmaWVkIGJ5IHRoZSBxdWVyeSBzdHJpbmcgIj9ydD1jb3JlLnJkIi4NCj4N Cj4gIG8gTm90ZSB0aGF0IHRoZSBmbG93IGlzIHNob3duIG9ubHkgZm9yIExpZ2h0LTIgZm9yIGNs YXJpdHkuDQo+DQo+IFNpbWlsYXINCj4NCj4gIGZsb3dzIHdpbGwgaGFwcGVuIGZvciBMaWdodC0x LCBMaWdodC0zIGFuZCB0aGUgTGlnaHQgU3dpdGNoIHdoZW4NCj4NCj4gIHRoZXkgYXJlIGZpcnN0 IHBvd2VyZWQgb24uDQo+DQo+ICBUaGUgUkQgbWF5IGFsc28gYmUgZGlzY292ZXJlZCBieSBvdGhl ciBtZWFucyBzdWNoIGFzIGJ5IGFzc3VtaW5nIGENCj4NCj4gIGRlZmF1bHQgbG9jYXRpb24gKGUu Zy4gb24gYSA2TEJSKSwgdXNpbmcgREhDUCwgYW55Y2FzdCBhZGRyZXNzLCBldGMuDQo+DQo+ICBI b3dldmVyLCB0aGVzZSBhcHByb2FjaGVzIGRvIG5vdCBpbnZva2UgQ29BUCBncm91cCBjb21tdW5p Y2F0aW9uIHNvDQo+DQo+ICBhcmUgbm90IGZ1cnRoZXIgZGlzY3Vzc2VkIGhlcmUuDQo+DQo+ICBG b3Igb3RoZXIgZGlzY292ZXJ5IHVzZSBjYXNlcyBzdWNoIGFzIGRpc2NvdmVyaW5nIGxvY2FsIENv QVANCj4NCj4gc2VydmVycywNCj4NCj4gIHNlcnZpY2VzIG9yIHJlc291cmNlcyBncm91cCBjb21t dW5pY2F0aW9uIGNhbiBiZSB1c2VkIGluIGEgc2ltaWxhcg0KPg0KPiAgZmFzaGlvbiBhcyBpbiB0 aGUgYWJvdmUgdXNlIGNhc2UuIEJvdGggTGluay1Mb2NhbCAoTEwpIGFuZCBzaXRlLQ0KPg0KPiAg bG9jYWwgZGlzY292ZXJ5IGFyZSBwb3NzaWJsZSB0aGlzIHdheS4NCj4NCj4gL2NvbW1lbnQgdGhl IFJEIGRpc2NvdmVyeSB3aWxsIGJlIG1vcmUgY29tcGxleCB3aGVuIHRoZXJlIGlzIGEgcm91dGVy DQo+DQo+IGJldHdlZW4gbGlnaHQtMiBhbmQgc3dpdGNoDQo+DQo+IC9jb21tZW50IFZpYSB3aGlj aCBSRCB3aWxsIGxpZ2h0IHN3aXRjaCBkaXNjb3ZlciBsaWdodC0yPw0KPg0KPiAvY29tbWVudCBh ZGRpdGlvbmFsIHJlYXNvbiB0byByZW1vdmUgcm91dGVyIGZyb20gdGhlIG11bHRpY2FzdA0KPg0K PiBjb25maWd1cmF0aW9uDQo+DQo+IFJhaG1hbiAmIERpamsgRXhwaXJlcyBBcHJpbCAyMiwgMjAx MyBbUGFnZQ0KPg0KPiAxNF0NCj4NCj4gSW50ZXJuZXQtRHJhZnQgR3JvdXAgQ29tbXVuaWNhdGlv biBmb3IgQ29BUCBPY3RvYmVyDQo+DQo+IDIwMTINCj4NCj4gIExpZ2h0IFJ0ci0xIFJ0ci0yDQo+ DQo+IE5ldHdvcmsNCj4NCj4gIExpZ2h0LTEgTGlnaHQtMiBMaWdodC0zIFN3aXRjaCAoUkQtMSkg KFJELTIpDQo+DQo+IEJhY2tib25lDQo+DQo+ICB8IHwgfCB8IHwgfCB8DQo+DQo+ICB8IHwgfCB8 IHwgfCB8DQo+DQo+ICAqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqIHwgfCB8DQo+ DQo+ICAqIExpZ2h0LTIgaXMgaW5zdGFsbGVkICogfCB8IHwNCj4NCj4gICogYW5kIHBvd2VycyBv biBmb3IgZmlyc3QgdGltZSAqIHwgfCB8DQo+DQo+ICAqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqIHwgfCB8DQo+DQo+ICB8IHwgfCB8IHwgfCB8DQo+DQo+ICB8IHwgfCB8IHwgfCB8 DQo+DQo+ICB8IHwgQ09BUCBOT04gKEdFVCB8IHwNCj4NCj4gIHwgfCAvLndlbGwta25vd24vY29y ZT9ydD1jb3JlLnJkKSB8IHwNCj4NCj4gIHwgfC0tLS0tLS0tLT4tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLT58IHwNCj4NCj4gIHwgfCB8IHwgfCB8IHwNCj4NCj4gIHwgfCB8IHwgfCB8 IHwNCj4NCj4gIHwgfCB8IHwgfCB8IHwNCj4NCj4gIHwgfCBDT0FQIE5PTiAoMi4wNSBDb250ZW50 IHwgfA0KPg0KPiAgfCB8IDwvcmQ+O3J0PSJjb3JlLnJkIjtpbnM9IlByaW1hcnkiKSB8IHwNCj4N Cj4gIHwgfDwtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS18IHwNCj4N Cj4gIHwgfCB8IHwgfCB8IHwNCj4NCj4gIEZpZ3VyZSAzOiBSZXNvdXJjZSBEaXJlY3RvcnkgRGlz Y292ZXJ5IHZpYSBNdWx0aWNhc3QgTWVzc2FnZQ0KPg0KPiA0LjQuIExpZ2h0aW5nIENvbnRyb2wN Cj4NCj4gL2NvbW1lbnQgSSBhbSBjb25mdXNlZCBhYm91dCB0aGUgdXNlIG9mIHByb3RvY29scw0K Pg0KPiAvY29tbWVudCBNTEQgaXMgdXNlZCB0byBmb3JtIGdyb3VwcywgY29ycmVjdD8NCj4NCj4g L2NvbW1lbnQgYnV0IHRoYXQgd2FzIGFscmVhZHkgZG9uZSBieSBlbmFibGluZyB0aGUgTUMgYWRk cmVzcyBpbiB0aGUNCj4NCj4gbGlnaHRzIChwb2ludCAyKQ0KPg0KPiAvY29tbWVudCBUaGVyZSBh cmUgc2V2ZXJhbCB3YXlzIHRvIHNldCB1cCBncm91cHMsIHBvaW50aW5nIHRoZW0gb3V0DQo+IGFu ZA0KPg0KPiB3aGVuIHRvIHVzZSB0aGVtIHdvdWxkIGJlIGFuIGFzc2V0Lg0KPg0KPiAgVGhlIHBy b3RvY29sIGZsb3cgZm9yIGEgYnVpbGRpbmcgYXV0b21hdGlvbiBsaWdodGluZyBjb250cm9sDQo+ DQo+IHNjZW5hcmlvDQo+DQo+ICBmb3IgdGhlIG5ldHdvcmsgKEZpZ3VyZSAyKSBpcyBzaG93biBp biBzZXF1ZW5jZSBpbiBGaWd1cmUgNCwNCj4NCj4gIEZpZ3VyZSA1LCBhbmQgRmlndXJlIDYuIFdl IGFzc3VtZSB0aGUgZm9sbG93aW5nIHN0ZXBzIG9jY3VyIGJlZm9yZQ0KPg0KPiAgdGhlIGlsbHVz dHJhdGVkIGZsb3c6DQo+DQo+ICBvIDEpIFN0YXJ0dXAgcGhhc2U6IDZMb1dQQU5zIGFyZSBmb3Jt ZWQuIElQdjYgYWRkcmVzc2VzIGFzc2lnbmVkDQo+DQo+IHRvDQo+DQo+ICBhbGwgZGV2aWNlcy4g VGhlIENvQVAgbmV0d29yayBpcyBmb3JtZWQuDQo+DQo+ICBvIDIpIENvbW1pc3Npb25pbmcgcGhh c2UgKGJ5IGFwcGxpY2F0aW9ucyk6IFRoZSBJUCBtdWx0aWNhc3QNCj4NCj4gYWRkcmVzcw0KPg0K PiAgb2YgdGhlIGdyb3VwIChSb29tLUEtTGlnaHRzKSBoYXMgYmVlbg0KPg0KPiAvcyBzZXQgL3Mg ZW5hYmxlDQo+DQo+ICBpbiBhbGwgdGhlIExpZ2h0cy4gVGhlDQo+DQo+ICBVUkkgb2YgdGhlIGdy b3VwIChSb29tLUEtTGlnaHRzKSBoYXMgYmVlbg0KPg0KPiAvcyBzZXQgL3MgcmVzb2x2ZWQNCj4N Cj4gIGluIHRoZSBMaWdodCBTd2l0Y2guDQo+DQo+ICBvIDMpIFRoZSBpbmRpY2F0ZWQgTUxEIFJl cG9ydCBtZXNzYWdlcyBhcmUgbGluay1sb2NhbCBtdWx0aWNhc3QuDQo+DQo+IEluDQo+DQo+ICBl YWNoIExvV1BBTiwgaXQgaXMgYXNzdW1lZCB0aGF0IGEgbXVsdGljYXN0IHJvdXRpbmcvZm9yd2Fy ZGluZw0KPg0KPiAgcHJvdG9jb2wgaW4gNkxScyB3aWxsIHRoZW4gcHJvcGFnYXRlIHRoZSBKb2lu IGluZm9ybWF0aW9uDQo+DQo+ICBjb250YWluZWQgaW4gdGhlIE1MRCBSZXBvcnQgb3ZlciBtdWx0 aXBsZSBob3BzIHRvIHRoZSA2TEJSLg0KPg0KPiAvY29tbWVudCBEb24ndCBzZWUgdGhlIG5lZWQN Cj4NCj4gUmFobWFuICYgRGlqayBFeHBpcmVzIEFwcmlsIDIyLCAyMDEzIFtQYWdlDQo+DQo+IDE1 XQ0KPg0KPiBJbnRlcm5ldC1EcmFmdCBHcm91cCBDb21tdW5pY2F0aW9uIGZvciBDb0FQIE9jdG9i ZXINCj4NCj4gMjAxMg0KPg0KPiAgTGlnaHQgUnRyLTEgUnRyLTINCj4NCj4gTmV0d29yaw0KPg0K PiAgTGlnaHQtMSBMaWdodC0yIExpZ2h0LTMgU3dpdGNoIChDb0FQIChDb0FQDQo+DQo+IEJhY2ti b25lDQo+DQo+ICB8IHwgfCB8IFByb3h5KSBQcm94eSkgfA0KPg0KPiAgfCB8IHwgfCB8IHwgfA0K Pg0KPiAgfCB8IHwgfCB8IHwgfA0KPg0KPiAgfCBNTEQgUmVwb3J0OiBKb2luIHwgfCB8IHwgfA0K Pg0KPiAgfCBHcm91cCAoUm9vbS1BLUxpZ2h0cykgfCB8IHwgfA0KPg0KPiAgfC0tLUxMLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLT58IHwgfA0KPg0KPiAgfCB8IHwgfCB8TUxE IFJlcG9ydDogSm9pbiB8DQo+DQo+ICB8IHwgfCB8IHxHcm91cCAoUm9vbS1BLUxpZ2h0cyl8DQo+ DQo+ICB8IHwgfCB8IHwtLS1MTC0tLS0tLS0tLS0tLS0tLT58DQo+DQo+ICB8IHwgfCB8IHwgfCB8 DQo+DQo+ICB8IHwgTUxEIFJlcG9ydDogSm9pbiB8IHwgfCB8DQo+DQo+ICB8IHwgR3JvdXAgKFJv b20tQS1MaWdodHMpIHwgfCB8DQo+DQo+ICB8IHwtLS1MTC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0+fCB8DQo+DQo+ICB8IHwgfCB8IHwgfCB8DQo+DQo+ICB8IHwgfCBNTEQg UmVwb3J0OiBKb2luIHwgfCB8DQo+DQo+ICB8IHwgfCBHcm91cCAoUm9vbS1BLUxpZ2h0cykgfCB8 DQo+DQo+ICB8IHwgfC0tLUxMLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0+fCB8DQo+DQo+ICB8 IHwgfCB8IHwgfCB8DQo+DQo+ICB8IHwgfCB8IHxNTEQgUmVwb3J0OiBKb2luIHwNCj4NCj4gIHwg fCB8IHwgfEdyb3VwIChSb29tLUEtTGlnaHRzKXwNCj4NCj4gIHwgfCB8IHwgfCB8LS0tTEwtLS0t PnwNCj4NCj4gIHwgfCB8IHwgfCB8IHwNCj4NCj4gIHwgfCB8IHwgfCB8IHwNCj4NCj4gIEZpZ3Vy ZSA0OiBKb2luaW5nIExpZ2h0aW5nIEdyb3VwcyBVc2luZyBNTEQNCj4NCj4gL2NvbW1lbnQgcG9z c2libHkgcmVtb3ZlIGZyb20gdGV4dCwgb3IgZG8gc2VwYXJhdGUgc2VjdGlvbiBvbiB1c2Ugb2YN Cj4NCj4gTUxEDQo+DQo+IC9jb21tZW50IGFueXdheSBzZXBhcmF0aW5nIGNvbW1pc3Npb25pbmcg ZnJvbSBvcGVyYXRpb24gaW4gc2VwYXJhdGUNCj4NCj4gc2VjdGlvbnMgaXMgYSBnb29kIGlkZWEu DQo+DQo+IC9jb21tZW50IHRoZSBwcm94aWVzIGFyZSBhIGNvbXBsaWNhdGlvbiBpbiB0aGUgcGlj dHVyZSBub3QgZWxhYm9yYXRlZA0KPg0KPiBpbiB0aGUgdGV4dC4NCj4NCj4gL2NvbW1lbnQgdGhl IHN1YmplY3Qgb2YgcHJveGllcyBpcyBhbm90aGVyIG9uZSwgdG8gYmUgdHJlYXRlZA0KPg0KPiBl bHNld2hlcmUuDQo+DQo+IC9jb21tZW50IGFsc28gZm9yIHByb3hpZXMgdGhlIGRvJ3MgYW5kIGRv bid0J3MgZnJvbSBhIHNpbXBsZQ0KPg0KPiBwZXJmb3JtYW5jZSBwZXJzcGVjdGl2ZSB3aWxsIGJl IGludGVyZXN0aW5nDQo+DQo+IFJhaG1hbiAmIERpamsgRXhwaXJlcyBBcHJpbCAyMiwgMjAxMyBb UGFnZQ0KPg0KPiAxNl0NCj4NCj4gSW50ZXJuZXQtRHJhZnQgR3JvdXAgQ29tbXVuaWNhdGlvbiBm b3IgQ29BUCBPY3RvYmVyDQo+DQo+IDIwMTINCj4NCj4gIExpZ2h0IFJ0ci0xIFJ0ci0yDQo+DQo+ IE5ldHdvcmsNCj4NCj4gIExpZ2h0LTEgTGlnaHQtMiBMaWdodC0zIFN3aXRjaCAoQ29BUCAoQ29B UA0KPg0KPiBCYWNrYm9uZQ0KPg0KPiAgfCB8IHwgfCBQcm94eSkgUHJveHkpIHwNCj4NCj4gIHwg fCB8IHwgfCB8IHwNCj4NCj4gIHwgfCAqKioqKioqKioqKioqKioqKioqKioqKiB8IHwNCj4NCj4g IHwgfCAqIFVzZXIgZmxpcHMgb24gKiB8IHwNCj4NCj4gIHwgfCAqIGxpZ2h0IHN3aXRjaCB0byAq IHwgfA0KPg0KPiAgfCB8ICogdHVybiBvbiBhbGwgdGhlICogfCB8DQo+DQo+ICB8IHwgKiBsaWdo dHMgaW4gUm9vbSBBICogfCB8DQo+DQo+ICB8IHwgKioqKioqKioqKioqKioqKioqKioqKiogfCB8 DQo+DQo+ICB8IHwgfCB8IHwgfCB8DQo+DQo+ICB8IHwgfCB8IHwgfCB8DQo+DQo+ICB8IHwgfCBD T0FQIE5PTiAoUFVUIHwgfCB8DQo+DQo+ICB8IHwgfCBQcm94eS1VUkkgfCB8IHwNCj4NCj4gIHwg fCB8IFVSSSBmb3IgUm9vbS1BLUxpZ2h0cyB8DQo+DQo+ICB8IHwgfCBQYXlsb2FkPXR1cm4gb24g bGlnaHRzKSB8DQo+DQo+ICB8IHwgfCB8LS0tLS0tLS0tPnwgfCB8DQo+DQo+ICB8IHwgfCB8IHwg fCB8DQo+DQo+ICB8IHwgfCB8IHwgfCB8DQo+DQo+ICB8IHwgfCB8IFJlcXVlc3QgRE5TIHJlc29s dXRpb24gb2YgfA0KPg0KPiAgfCB8IHwgfCBVUkkgZm9yIFJvb20tQS1MaWdodHMgfA0KPg0KPiAg fCB8IHwgfCB8LS0tLS0tLS0tLS0tLS0tLS0tLS0+fA0KPg0KPiAgfCB8IHwgfCB8IHwgfA0KPg0K PiAgfCB8IHwgfCB8IHwgfA0KPg0KPiAgfCB8IHwgfCBETlMgcmV0dXJuczogQUFBQSB8DQo+DQo+ ICB8IHwgfCB8IEdyb3VwIChSb29tLUEtTGlnaHRzKSB8DQo+DQo+ICB8IHwgfCB8IElQdjYgbXVs dGljYXN0IGFkZHJlc3MgfA0KPg0KPiAgfCB8IHwgfCB8PC0tLS0tLS0tLS0tLS0tLS0tLS0tfA0K Pg0KPiAgfCB8IHwgfCB8IHwgfA0KPg0KPiAgfCB8IHwgfCB8IHwgfA0KPg0KPiAgfCB8IHwgQ09B UCBOT04gKFB1dCB8DQo+DQo+ICB8IHwgfCB8IFVSSSBQYXRoIHwNCj4NCj4gIHwgfCB8IHwgUGF5 bG9hZD10dXJuIG9uIGxpZ2h0cyl8DQo+DQo+ICB8IHwgfCB8IERlc3RpbmF0aW9uIElQIEFkZHJl c3MgPSB8DQo+DQo+ICB8IHwgfCB8IElQIG11bHRpY2FzdCBhZGRyZXNzIHwNCj4NCj4gIHwgfCB8 IHwgZm9yIEdyb3VwIChSb29tLUEtTGlnaHRzKXwNCj4NCj4gIHwgfCB8IHwgT3JpZ2luYXRpbmcg SVAgQWRkcmVzcyA9IHwNCj4NCj4gIHwgfCB8IHwgUlRSLTEgfA0KPg0KPiAgfCB8IHwgfCB8LS0t LS0tLS0tLS0tLS0tLS0tLS0+fA0KPg0KPiAgfDwtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS18IHwgfA0KPg0KPiAgfCB8IHwgfCB8IHwgfA0KPg0KPiAgfCB8IHwgfCB8 IHw8LS0tLS0tLS0tfA0KPg0KPiAgfCB8PC0tLS0tLS0tLXw8LS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLXwgfA0KPg0KPiAgfCB8IHwgfCB8IHwgfA0KPg0KPiAgfCB8IHwgfCB8IHwgfA0K Pg0KPiAgRmlndXJlIDU6IFNlbmRpbmcgTGlnaHRpbmcgQ29udHJvbCBNdWx0aWNhc3QgTWVzc2Fn ZQ0KPg0KPiBSYWhtYW4gJiBEaWprIEV4cGlyZXMgQXByaWwgMjIsIDIwMTMgW1BhZ2UNCj4NCj4g MTddDQo+DQo+IEludGVybmV0LURyYWZ0IEdyb3VwIENvbW11bmljYXRpb24gZm9yIENvQVAgT2N0 b2Jlcg0KPg0KPiAyMDEyDQo+DQo+ICBMaWdodCBSdHItMSBSdHItMg0KPg0KPiBOZXR3b3JrDQo+ DQo+ICBMaWdodC0xIExpZ2h0LTIgTGlnaHQtMyBTd2l0Y2ggKENvQVAgKENvQVANCj4NCj4gQmFj a2JvbmUNCj4NCj4gIHwgfCB8IHwgUHJveHkpIFByb3h5KSB8DQo+DQo+ICB8IHwgfCB8IHwgfCB8 DQo+DQo+ICAqKioqKioqKioqKioqKioqKioqKioqKiB8IHwgfCB8DQo+DQo+ICAqIExpZ2h0cyBp biBSb29tLUEgKiB8IHwgfCB8DQo+DQo+ICAqIHR1cm4gb24gKG5lYXJseSAqIHwgfCB8IHwNCj4N Cj4gICogc2ltdWx0YW5lb3VzbHkpICogfCB8IHwgfA0KPg0KPiAgKioqKioqKioqKioqKioqKioq KioqKiogfCB8IHwgfA0KPg0KPiAgfCB8IHwgfCB8IHwgfA0KPg0KPiAgfCB8IHwgfCB8IHwgfA0K Pg0KPiAgfCBDT0FQIE5PTiAoMi4wNCBDaGFuZ2VkKSB8IHwgfCB8DQo+DQo+ICB8LS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPnwgfCB8DQo+DQo+ICB8IHwgfCB8IHwg fCB8DQo+DQo+ICB8IHwgfCB8IHwgfCB8DQo+DQo+ICB8IENPQVAgTk9OICgyLjA0IENoYW5nZWQp IHwgfCB8DQo+DQo+ICB8IHwtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPnwgfCB8DQo+ DQo+ICB8IHwgfCB8IHwgfCB8DQo+DQo+ICB8IHwgfCB8IHwgfCB8DQo+DQo+ICB8IHwgQ09BUCBO T04gKDUuMDAgSW50ZXJuYWwgU2VydmVyIEVycm9yKSB8DQo+DQo+ICB8IHwgfC0tLS0tLS0tLS0t LS0tLS0tLS0tPnwgfCB8DQo+DQo+ICB8IHwgfCB8IHwgfCB8DQo+DQo+ICB8IHwgfCAqKioqKioq KioqKioqKioqKioqKioqKioqKioqKiogfA0KPg0KPiAgfCB8IHwgKiBSdHItMSBhcyBDb0FQIFBy b3h5ICogfA0KPg0KPiAgfCB8IHwgKiB8IHNlbmRzIHRoZSBpbmRpdmlkdWFsICogfA0KPg0KPiAg fCB8IHwgKiB8IHJlc3BvbnNlcyBiYWNrIHRvICogfA0KPg0KPiAgfCB8IHwgKiB2IG9yaWdpbmF0 b3IgKiB8DQo+DQo+ICB8IHwgfCAqKioqKioqKioqKioqKioqKioqKioqKioqKioqKiogfA0KPg0K PiAgfCB8IHwgfCB8IHwgfA0KPg0KPiAgfCB8IHwgQ09BUCBOT04gKDIuMDQgQ2hhbmdlZCkgfCB8 DQo+DQo+ICB8IHwgfCB8PC0tLS0tLS0tLXwgfCB8DQo+DQo+ICB8IHwgfCB8IHwgfCB8DQo+DQo+ ICB8IHwgfCBDT0FQIE5PTiAoMi4wNCBDaGFuZ2VkKSB8IHwNCj4NCj4gIHwgfCB8IHw8LS0tLS0t LS0tfCB8IHwNCj4NCj4gIHwgfCB8IHwgfCB8IHwNCj4NCj4gIHwgfCB8IENPQVAgTk9OICg1LjAw IEludGVybmFsIFNlcnZlciBFcnJvcikgfA0KPg0KPiAgfCB8IHwgfDwtLS0tLS0tLS18IHwgfA0K Pg0KPiAgfCB8IHwgfCB8IHwgfA0KPg0KPiAgRmlndXJlIDY6IFNlbmRpbmcgTGlnaHRpbmcgQ29u dHJvbCBSZXNwb25zZSB0byBNdWx0aWNhc3QgTWVzc2FnZQ0KPg0KPiAgTk9URTogSW4gdGhlIGxh c3Qgc3RlcCBvZiBGaWd1cmUgNiwgUnRyLTEgYWN0aW5nIGFzIENvQVAgcHJveHksDQo+DQo+ICBy ZXR1cm5zIG11bHRpcGxlIGluZGl2aWR1YWwgQ29BUCByZXNwb25zZXMgdG8gdGhlIGNsaWVudC4g RWFjaA0KPg0KPiAgcmVzcG9uc2UgZWNob2VzIHRoZSBUb2tlbiBvZiB0aGUgY2xpZW50J3MgcmVx dWVzdC4gVGhlIGNsaWVudCBjYW4NCj4NCj4gIGlkZW50aWZ5IHRoZSBvcmlnaW5hbCBzb3VyY2Ug b2YgZWFjaCByZXNwb25zZSBieSAuLi5UQkQuDQo+DQo+IC9jb21tZW50IFdIWSBhcmUgdGhlIG11 bHRpY2FzdCBkZXN0aW5hdGlvbnMgc2VuZGluZyBiYWNrIHJlc3VsdHM/DQo+DQo+IC9jb21tZW50 IEkgdGhvdWdodCB0aGF0IHlvdSB3YW50ZWQgTUMgbWVzc2FnZXMgdG8gYmUgbm9uIGNvbmZpcm1h YmxlDQo+DQo+IC9jb21tZW50IHNlbmRpbmcgcmVzcG9uc2VzIHNlZW1zIHRvIGNvbnRyYWRpY3Qg dGhpcyAuDQo+DQo+IC9jb21tZW50IHBsZWFzZSByZW1vdmUgc2VuZGluZyBiYWNrIG9mIHJlc3Bv bnNlcy4NCj4NCj4gL2NvbW1lbnQgb25lIG1heSBhc3N1bWUgdGhhdCB0aGUgTUMgYWxnb3JpdGht IHdpdGhpbiB0aGUgbG93cGFuIGlzDQo+DQo+IHJlbGlhYmxlIChhbGwgZGVzdGluYXRpb25zIHJl Y2VpdmUgdGhlIG1lc3NhZ2UpDQo+DQo+IC9jb21tZW50IGFueXdheSBNUEwgY29tZXMgY2xvc2Ug ZW5vdWdoIHRvIHRoZSByZWxpYWJpbGl0eSByZXF1aXJlbWVudA0KPg0KPiBnaXZlbiBhIHNwZWNp ZmlhYmxlIHJhbmdlIG9mIGNvbmZpZ3VyYXRpb25zDQo+DQo+IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4NCj4N Cj4gLS0NCj4NCj4gUGV0ZXIgdmFuIGRlciBTdG9rDQo+DQo+IG1haWx0bzogY29uc3VsdGFuY3lA dmFuZGVyc3Rvay5vcmcNCj4NCj4gd3d3OiB3d3cudmFuZGVyc3Rvay5vcmcgWzNdDQo+DQo+IHRl bCBOTDogKzMxKDApNDkyNDc0NjczIEY6ICszMygwKTk2NjAxNTI0OA0KPg0KPiAtLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tDQo+ICBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgbWVz c2FnZSBtYXkgYmUgY29uZmlkZW50aWFsIGFuZA0KPiBsZWdhbGx5IHByb3RlY3RlZCB1bmRlciBh cHBsaWNhYmxlIGxhdy4gVGhlIG1lc3NhZ2UgaXMgaW50ZW5kZWQgc29sZWx5DQo+IGZvciB0aGUg YWRkcmVzc2VlKHMpLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCB5b3Ug YXJlDQo+IGhlcmVieSBub3RpZmllZCB0aGF0IGFueSB1c2UsIGZvcndhcmRpbmcsIGRpc3NlbWlu YXRpb24sIG9yDQo+IHJlcHJvZHVjdGlvbiBvZiB0aGlzIG1lc3NhZ2UgaXMgc3RyaWN0bHkgcHJv aGliaXRlZCBhbmQgbWF5IGJlDQo+IHVubGF3ZnVsLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5k ZWQgcmVjaXBpZW50LCBwbGVhc2UgY29udGFjdCB0aGUNCj4gc2VuZGVyIGJ5IHJldHVybiBlLW1h aWwgYW5kIGRlc3Ryb3kgYWxsIGNvcGllcyBvZiB0aGUgb3JpZ2luYWwNCj4gbWVzc2FnZS4NCj4N Cj4NCj4gTGlua3M6DQo+IC0tLS0tLQ0KPiBbMV0gaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3Jn L2RyYWZ0cy9jdXJyZW50Lw0KPiBbMl0gaHR0cDovL3RydXN0ZWUuaWV0Zi5vcmcvbGljZW5zZS1p bmZvDQo+IFszXSBodHRwOi8vd3d3LnZhbmRlcnN0b2sub3JnDQoNCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQpUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgbWVzc2Fn ZSBtYXkgYmUgY29uZmlkZW50aWFsIGFuZCBsZWdhbGx5IHByb3RlY3RlZCB1bmRlciBhcHBsaWNh YmxlIGxhdy4gVGhlIG1lc3NhZ2UgaXMgaW50ZW5kZWQgc29sZWx5IGZvciB0aGUgYWRkcmVzc2Vl KHMpLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCB5b3UgYXJlIGhlcmVi eSBub3RpZmllZCB0aGF0IGFueSB1c2UsIGZvcndhcmRpbmcsIGRpc3NlbWluYXRpb24sIG9yIHJl cHJvZHVjdGlvbiBvZiB0aGlzIG1lc3NhZ2UgaXMgc3RyaWN0bHkgcHJvaGliaXRlZCBhbmQgbWF5 IGJlIHVubGF3ZnVsLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVh c2UgY29udGFjdCB0aGUgc2VuZGVyIGJ5IHJldHVybiBlLW1haWwgYW5kIGRlc3Ryb3kgYWxsIGNv cGllcyBvZiB0aGUgb3JpZ2luYWwgbWVzc2FnZS4NCg== From trac+core@trac.tools.ietf.org Thu Dec 20 04:00:01 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D859321F85E6 for ; Thu, 20 Dec 2012 04:00:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H-FzObWETmt1 for ; Thu, 20 Dec 2012 04:00:00 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 145F721F85D0 for ; Thu, 20 Dec 2012 03:59:59 -0800 (PST) Received: from localhost ([127.0.0.1]:58599 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1Tlen5-0001UO-FW; Thu, 20 Dec 2012 12:59:55 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "core issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-core-groupcomm@tools.ietf.org, esko.dijk@philips.com X-Trac-Project: core Date: Thu, 20 Dec 2012 11:59:55 -0000 X-URL: http://tools.ietf.org/core/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/core/trac/ticket/273 Message-ID: <060.a27f62e00f2d05b781ab5068c8e0d20e@trac.tools.ietf.org> X-Trac-Ticket-ID: 273 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-core-groupcomm@tools.ietf.org, esko.dijk@philips.com, core@ietf.org X-SA-Exim-Mail-From: trac+core@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: akbar.rahman@interdigital.com, esko.dijk@philips.com Resent-Message-Id: <20121220120000.145F721F85D0@ietfa.amsl.com> Resent-Date: Thu, 20 Dec 2012 03:59:59 -0800 (PST) Resent-From: trac+core@trac.tools.ietf.org Cc: core@ietf.org Subject: [core] #273: Include guidelines on when (not) to use CoAP response to multicast request X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Reply-To: trac+core@trac.tools.ietf.org List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Dec 2012 12:00:01 -0000 #273: Include guidelines on when (not) to use CoAP response to multicast request Groupcomm: if possible, include guidelines on when (not) to use CoAP response to multicast request; based on review comments Peter vd Stok. core-coap indicates that a server MAY suppress a response to a multicast but it may be helpful to indicate in detail when the server should or should not do this. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-core- esko.dijk@philips.com | groupcomm@tools.ietf.org Type: task | Status: new Priority: minor | Milestone: Component: groupcomm | Version: Severity: - | Keywords: -------------------------+------------------------------------------------- Ticket URL: core From internet-drafts@ietf.org Thu Dec 20 06:30:17 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C46821F8973; Thu, 20 Dec 2012 06:30:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.529 X-Spam-Level: X-Spam-Status: No, score=-102.529 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VY9jcb6VPWia; Thu, 20 Dec 2012 06:30:16 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A4D921F8812; Thu, 20 Dec 2012 06:30:16 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.37 Message-ID: <20121220143016.22755.53076.idtracker@ietfa.amsl.com> Date: Thu, 20 Dec 2012 06:30:16 -0800 Cc: core@ietf.org Subject: [core] I-D Action: draft-ietf-core-groupcomm-04.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 20 Dec 2012 14:30:17 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Constrained RESTful Environments Working = Group of the IETF. Title : Group Communication for CoAP Author(s) : Akbar Rahman Esko Dijk Filename : draft-ietf-core-groupcomm-04.txt Pages : 24 Date : 2012-12-20 Abstract: CoAP is a RESTful transfer protocol for constrained devices and networks. It is anticipated that constrained devices will often naturally operate in groups (e.g. in a building automation scenario all lights in a given room may need to be switched on/off as a group). This document defines how the CoAP protocol should be used in a group communication context. An approach for using CoAP on top of IP multicast is detailed for both constrained and un-constrained networks. Also, various use causes and corresponding protocol flows are provided to illustrate important concepts. Finally, guidance is provided for deployment in various network topologies. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-groupcomm There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-core-groupcomm-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-core-groupcomm-04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From Akbar.Rahman@InterDigital.com Thu Dec 20 06:46:54 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A3AA21F86C1 for ; Thu, 20 Dec 2012 06:46:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jsh4tLHOkVPc for ; Thu, 20 Dec 2012 06:46:53 -0800 (PST) Received: from smtp-out1.interdigital.com (smtp-out1.interdigital.com [64.208.228.135]) by ietfa.amsl.com (Postfix) with ESMTP id 71D1021F8751 for ; Thu, 20 Dec 2012 06:46:53 -0800 (PST) Received: from SAM.InterDigital.com ([10.30.2.11]) by smtp-out1.interdigital.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 20 Dec 2012 09:46:52 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 20 Dec 2012 09:46:51 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [core] I-D Action: draft-ietf-core-groupcomm-04.txt Thread-Index: Ac3evorAGUHOwZTvRXOuf8t1+EynEQAAPM8g From: "Rahman, Akbar" To: X-OriginalArrivalTime: 20 Dec 2012 14:46:52.0041 (UTC) FILETIME=[D9101790:01CDDEC0] Subject: [core] FW: I-D Action: draft-ietf-core-groupcomm-04.txt X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 20 Dec 2012 14:46:54 -0000 Hi All, Esko and I have updated the Group Communications draft as per the guidance from the Chairs at the IETF Atlanta meeting. Namely we have addressed the items listed below that were brought up online and offline in Atlanta. Our next steps (in January) will be to address the comments from Peter van der Stok that were recently sent to the list. We also look forward to receiving the comments from the other volunteer reviewers (Cullen Jennings, Zach Shelby, Salvatore Loreto) whenever they are ready. The current -04 version of the draft is stable so it will be a good version to give comments on. Of course comments from everyone else on the list are also definitely encouraged and welcome. Sincerely, Esko & Akbar ------------------------------------------------------------------------ -- Changes from ietf-03 to ietf-04: o Removed section 2.3 (Potential Solutions for Group Communications) as it is purely background information and moved section to draft-dijk-core-groupcomm-misc (#266). o Added reference to draft-keoh-tls-multicast-security to section 6 (Security Considerations). o Removed Appendix B (CoAP-Observe Alternative to Group Communications) as it is as an alternative to IP Multicast that the WG has not adopted and moved section to draft-dijk-core-groupcomm-misc (#267). o Deleted section 8 (Conclusions) as it is redundant (#268). o Simplified light switch use case (#269) by splitting into basic operations and additional functions (#269). o Moved section 3.7 (CoAP Multicast and HTTP Unicast Interworking) to draft-dijk-core-groupcomm-misc (#270). o Moved section 3.3.1 (DNS-SD) and 3.3.2 (CoRE Resource Directory) to draft-dijk-core-groupcomm-misc as these sections essentially just repeated text from other drafts regarding DNS based features. Clarified remaining text in this draft relating to DNS based features to clearly indicate that these features are optional (#272). o Focus section 3.5 (Configuring Group Membership) on a single proposed solution. o Scope of section 5.3 (Use of MLD) widened to multicast destination advertisement methods in general. o Rewrote section 2.2 (Scope) for improved readibility. o Moved use cases that are not adressed to draft-dijk-core-groupcomm-misc. o Various editorial updates for improved readibility. -----Original Message----- From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org Sent: Thursday, December 20, 2012 9:30 AM To: i-d-announce@ietf.org Cc: core@ietf.org Subject: [core] I-D Action: draft-ietf-core-groupcomm-04.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Constrained RESTful Environments Working Group of the IETF. Title : Group Communication for CoAP Author(s) : Akbar Rahman Esko Dijk Filename : draft-ietf-core-groupcomm-04.txt Pages : 24 Date : 2012-12-20 Abstract: CoAP is a RESTful transfer protocol for constrained devices and networks. It is anticipated that constrained devices will often naturally operate in groups (e.g. in a building automation scenario all lights in a given room may need to be switched on/off as a group). This document defines how the CoAP protocol should be used in a group communication context. An approach for using CoAP on top of IP multicast is detailed for both constrained and un-constrained networks. Also, various use causes and corresponding protocol flows are provided to illustrate important concepts. Finally, guidance is provided for deployment in various network topologies. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-core-groupcomm There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-core-groupcomm-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-core-groupcomm-04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core From cabo@tzi.org Thu Dec 20 14:41:43 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7D1821F8949 for ; Thu, 20 Dec 2012 14:41:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IkBM-MINrnTX for ; Thu, 20 Dec 2012 14:41:43 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 2180A21F8202 for ; Thu, 20 Dec 2012 14:41:42 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id qBKMfXrq002270 for ; Thu, 20 Dec 2012 23:41:33 +0100 (CET) Received: from [192.168.217.117] (p54893288.dip.t-dialin.net [84.137.50.136]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 313FBC87; Thu, 20 Dec 2012 23:41:33 +0100 (CET) From: Carsten Bormann Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Thu, 20 Dec 2012 23:41:32 +0100 To: "core@ietf.org WG" Message-Id: Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) Subject: [core] IETF-85 (Atlanta) minutes posted X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 20 Dec 2012 22:41:44 -0000 I have posted minutes for the Atlanta CoRE meeting slots at: http://www.ietf.org/proceedings/85/minutes/minutes-85-core Thanks to the note takers Dominique and Zach. All errors are mine. Unfortunately, time ran out for me to do my usual routine of filling in = the minutes from the audio recordings. So please double-check that your views are properly represented. Gr=FC=DFe, Carsten From Bert.Greevenbosch@huawei.com Thu Dec 20 18:43:07 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A955321E802E for ; Thu, 20 Dec 2012 18:43:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BtaoyaIl02SI for ; Thu, 20 Dec 2012 18:43:05 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id EC8E321F884B for ; Thu, 20 Dec 2012 18:43:03 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AMR77644; Fri, 21 Dec 2012 02:43:02 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 21 Dec 2012 02:42:46 +0000 Received: from SZXEML429-HUB.china.huawei.com (10.72.61.37) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 21 Dec 2012 02:43:00 +0000 Received: from SZXEML509-MBX.china.huawei.com ([10.82.67.37]) by SZXEML429-HUB.china.huawei.com ([10.72.61.37]) with mapi id 14.01.0323.003; Fri, 21 Dec 2012 10:42:56 +0800 From: Bert Greevenbosch To: "core@ietf.org WG" Thread-Topic: draft-ietf-core-coap-13 WGLC - my comments Thread-Index: Ac3fJOBotWMwxik5SqmwNsss62gtLA== Date: Fri, 21 Dec 2012 02:42:56 +0000 Message-ID: <46A1DF3F04371240B504290A071B4DB63CB1D314@szxeml509-mbx> Accept-Language: en-GB, zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: 07E= Ahtu A0fP A3zE CmCD D8v0 ESXB EtuM GKwW G5RI HClo HaRs Hqct Ij4w JbT5 Khj8; 1; YwBvAHIAZQBAAGkAZQB0AGYALgBvAHIAZwA=; Sosha1_v1; 7; {85B60721-836D-43EA-A559-2E3BDEF7DA25}; YgBlAHIAdAAuAGcAcgBlAGUAdgBlAG4AYgBvAHMAYwBoAEAAaAB1AGEAdwBlAGkALgBjAG8AbQA=; Fri, 21 Dec 2012 02:42:54 GMT; ZAByAGEAZgB0AC0AaQBlAHQAZgAtAGMAbwByAGUALQBjAG8AYQBwAC0AMQAzACAAVwBHAEwAQwAgAC0AIABtAHkAIABjAG8AbQBtAGUAbgB0AHMA x-cr-puzzleid: {85B60721-836D-43EA-A559-2E3BDEF7DA25} x-originating-ip: [10.70.110.143] Content-Type: multipart/alternative; boundary="_000_46A1DF3F04371240B504290A071B4DB63CB1D314szxeml509mbx_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [core] draft-ietf-core-coap-13 WGLC - my comments X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 21 Dec 2012 02:43:07 -0000 --_000_46A1DF3F04371240B504290A071B4DB63CB1D314szxeml509mbx_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello all, I have reviewed the CoAP spec. I have the comments below. After each comment number, I wrote an "E" for "Editorial" or "T" for "Techn= ical". I think the draft is in a very good shape, and that most comments below can= be resolved quite easily. I look forward to your opinions! Best regards, Bert 1,E) p.9: "Provoking a Reset message (e.g., by sending an empty Confirmable= message) is also useful as an inexpensive check of the liveness of an endp= oint ("CoAP ping")." I am not sure if we should endorse provoking RST messages by sending empty = CON messages. 2,E) p.11: "One could think of CoAP logically as using a two-layer approach= , a CoAP messaging layer used to deal with UDP and the asynchronous nature = of the interactions, and the request/response interactions using Method and= Response codes (see Figure 1). CoAP is however a single protocol, with mes= sages and request/response just features of the CoAP header." I do not follow the thread about CoAP as a two layer protocol, whereas in m= y view it is a plain single application layer protocol. Is this text needed= ? 3,E) p.14: "almost, but not entirely unlike" Should this be "almost, but not entirely alike"? 4,T) p.21: "An empty message has a Code field set to 0. The Token Length fi= eld MUST be set to 0 and no bytes MUST be present after the Message ID fiel= d. If there are any bytes, they MUST be processed as a message format error= ." p.32: "The Acknowledgement to the Confirmable response MUST also be an empt= y message, i.e. one that carries neither a request nor a response." This is violated by figure 10 in the block-10 draft, where a block option i= s included in the ACK from a CON response. Change here or in block? Maybe t= here will be future options that may need inclusion in ACKs to CON response= s too? 5,E) p.23: "A server MAY relax the requirement to answer all retransmission= s of an idempotent request with the same response (Section 4.2), so that it= does not have to maintain state for Message IDs. For example, an implement= ation might want to process duplicate transmissions of a GET, PUT or DELETE= request as separate requests if the effort incurred by duplicate processin= g is less expensive than keeping track of previous responses would be." Although not explicitly stated here, the draft seems to imply that DELETE i= s idempotent. This is true from the result point of view (afterwards the re= source is deleted), however the first request should give a different respo= nse (2.02 Deleted) than the subsequent request (4.04 Not Found). Is this is= sue too small to declare DELETE non-idempotent? 6,E) p.25: "In order not to cause congestion, Clients (including proxies) M= UST strictly limit the number of simultaneous outstanding interactions that= they maintain to a given server (including proxies) to NSTART. ... The def= ault value of NSTART for this representation is 1." The usage of NSTART is confusing in this text. It may be better to start th= e text with "Let NSTART be an integer, which has a default value 1.", after= which continuing with "In order not to cause congestion, ...". 7,T) p.25: "Unless this is modified by additional congestion control optimi= zations, it MUST be chosen in such a way that an endpoint does not exceed a= n average data rate of PROBING_RATE in sending to another endpoint that doe= s not respond." p.26, in the table: "PROBING_RATE =3D 1 Byte/second". p.21: "Retransmission is controlled by two things that a CoAP endpoint MUST= keep track of for each Confirmable message it sends while waiting for an a= cknowledgement (or reset): a timeout and a retransmission counter. For a ne= w Confirmable message, the initial timeout is set to a random counter betwe= en ACK_TIMEOUT and (ACK_TIMEOUT*ACK_RANDOM_FACTOR) (see Section 4.8), and t= he retransmission counter is set to 0. When the timeout is triggered and th= e retransmission counter is less than MAX_RETRANSMIT, the message is retran= smitted, the retransmission counter is incremented, and the timeout is doub= led. If the retransmission counter reaches MAX_RETRANSMIT on a timeout, or = if the endpoint receives a Reset message, then the attempt to transmit the = message is canceled and the application process informed of failure." It seems that PROBING_RATE is another constraint on top of what is defined = on p.21, since the algorithm of p.21 alone would already violate the probin= g rate, especially at the beginning of the retransmissions. Is 1 Byte/secon= d reasonable? Does it mean that a 16 byte CoAP message needs at least 16 se= conds between two subsequent retransmissions? Over which time frame is the = PROBING_RATE calculated? Suggestion: remove PROBING_RATE. 8,T) NSTART=3D1 implies that you cannot send a bulk of requests at once. Is= this the intention, or would a small but higher value of NSTART still be a= cceptable? 9,E) p. 28, According to my calculations the final value EXCHANGE_LIFETIME = should be 247, not 248. 10,E) An important goal of section 4.8.2 seems to be finding a reasonable t= ime after which message IDs can be re-used. Maybe that goal should be expli= citly mentioned at the beginning of the section? 11,E) Depending on the resolution of comment 5, the text in section 5.1, p2= 9 may need to be updated. 12,E) p.32: "A token is intended for use as a client-local identifier for d= ifferentiating between concurrent requests (see Section 5.3); it could have= been called a "request ID"." Remove the reference to Section 5.3, especially since the text is in its su= bsection 5.3.1. 13,T) p.35: "an option is never "mandatory"" Maybe in the future there will be options that require other options to be = included? Or a option could be mandatory in the response, when responding o= n a critical option from a request. 14,T) p.37: "Implementation Note: On a quality of implementation level, the= re is a strong expectation that a Content-Format indication will be provide= d with resource representations whenever possible. This is not a "SHOULD"-l= evel requirement solely because it is not a protocol requirement, and it al= so would be difficult to outline exactly in what cases this expectation can= be violated." There could be other means to determine the content-format. For example, if= the resource URI has the suffix ".jpg", it is highly expectable that it re= fers to a picture coded as an octet-stream. Would it be good to define a de= fault value "octet-stream" for the content-format option? 15,E) p.37: "For responses indicating a client or server error, the payload= is considered a representation of the result of the requested action only = if a Content-Format Option is given. In the absence of this option, the pay= load is a Diagnostic Payload ({{diagnostic-message-payload}})." Is this text needed? What does ({{diagnostic-message-payload}}) mean? What = is the format of the Diagnostic Payload? Suggestion: remove the text. 16,E) p.38: ""selected representation""" Fix the typo of the double quotes. Consider if the "selected representation= " is a good name, as in fact the representation is not selected. Maybe "can= didate representation" is better? 17,T) p.39: "Unlike HTTP, the cachability of CoAP responses does not depend= on the request method, but on the Response Code." What does this mean? When the choice of the methods is between PUT and GET,= I suspect that the caching depends on that choice. 18,T) p.42: "The request URI in a proxy request is specified as a string in= the Proxy-Uri Option (see Section 5.10.2), while the request URI in a requ= est to an origin server is split into the Uri-Host, Uri-Port, Uri-Path and = Uri-Query Options (see Section 5.10.1); alternatively the URI in a proxy re= quest can be assembled from a Proxy-Scheme option and the split options men= tioned." Also related to section 5.10.2 on p.50. Why are there two ways to define the proxy URI? Maybe the Proxy-Uri option = is not needed. An advantage of the proxy-uri option may be that multiple URIs can be inclu= ded in a single request. If that is the case, why not mandate proxy-uri for= all forward-proxy requests? Two mechanisms to provide the same functionali= ty is unnecessary overhead. 19,T) The cache key seems to be the collection of options that are needed t= o identify a particular representation of a resource. After much reading, I= understand that when a request contains options that are in the cache key,= and the proxy does not have a cached representation for exactly those valu= es of the cache key options, then it needs to acquire the related represent= ation, whereas if all options are proxy-safe and not in the cache key, the = proxy can ignore them and provide the cached response. The draft already implies that the no-cache-key property will seldom be use= d, as it reserves three bits of the option number for it, and the option is= only considered not a cache key when these three bits are all set. In addi= tion, the no-cache-key property can only hold for options that are proxy sa= fe, leading to possible option numbers 28, 29, 40, 41, 72, 73, ... A proxy can safely ignore the no-cache-key property, in which case it will = consider all proxy-safe options to be in the cache key and it does not need= to check these bits. The draft itself does not provide itself a proxy safe option that is not in= the cache key. Is this mechanism really needed? If so, provide a clear definition of the c= ache-key is needed, also in the definitions section. 20,E) It would be easier to look up the default port value directly from ta= ble 1 on p.49. 21,E) The '-' in the 'N' column in table 1 on p.49 indicates that the optio= n per definition is in the cache-key. Provided that we keep the no-cache-ke= y property, add a clarification to the table. 22,E) p. 51: "The CoAP Accept option indicates when included one or more ti= mes in a request, one or more Content-Formats, each of which is an acceptab= le Content-Format for the client, in the order of preference (most preferre= d first)." This sentence is hard to read. How about the following rewrite: "The CoAP Accept option can be used to indicate which Content-Formats are a= cceptable to the client. Multiple Accept options can be included in a reque= st, in order of preferred Content-Format (most preferred first)." 23,E) p.52: "If one or more Location-* options are present and thus a locat= ion URI is indicated (Section 5.10.7), the tagged representation is the rep= resentation that would be retried by a GET request to the location URI." Replace "retried" by "retrieved" 24,T) p.53: "... more Location-* options may be defined in the future, and = have been reserved option numbers 128, 132, 136, and 140." Are these reservations still needed, or are they remnants of the long jump = times? 25,T) p.58: "7. If /port/ does not equal the request's destination UDP port= , include a Uri-Port Option and let that option's value be /port/." Is my understanding correct that this happens only when talking with forwar= d-proxies? 26,T) p.63: "The NoSec and RawPublicKey modes are mandatory to implement fo= r this specification." Do we really want to mandate DTLS for all CoAP implementations? 27,T) p.66: "A message is the same when it is sent within the same DTLS ses= sion and same epoch and has the same Message ID." This requires the epoch to be shorter than the EXCHANGE_LIFETIME from secti= on 4.8.1, as after this EXCHANGE_LIFETIME message ids can be re-used. 28,T) p.71, section 10.1.4: "If the action performed by the POST method doe= s not result in a resource that can be identified by a URI, a 2.04 (Changed= ) response MUST be returned to the client. If a resource has been created o= n the origin server, a 2.01 (Created) response MUST be returned." Can a resource that can be identified by an URI also be changed, and thus a= 2.04 (Changed) response returned? If so, simplify the first sentence. 29,E) p.71: "Unless otherwise specified all the statements made are RECOMME= NDED behavior; some highly constrained implementations may need to resort t= o shortcuts." I am not sure if there will be much constrained proxies. Maybe it could be = rephrased as follows: "Unless otherwise specified all the statements made are RECOMMENDED behavio= r; implementations MAY defer from those recommendations in accordance with = their requirements." 30,E) p.71: "As the OPTIONS and TRACE methods are not supported in CoAP a 5= 01 (Not Implemented) error MUST be returned to the client." Should the MUST be a SHOULD, as the section contains recommendations? 31,E) p.74: "Also, a caching proxy MUST NOT make cached values available to= requests that have lesser transport security properties than to which it w= ould make available the process of forwarding the request in the first plac= e." What does this sentence mean? Clarify. 32,T) p.75: "A CoAP server can reduce the amount of amplification it provid= es to an attacker by using slicing/blocking modes of CoAP [I-D.ietf-core-bl= ock] and offering large resource representations only in relatively small s= lices. E.g., for a 1000 byte resource, a 10-byte request might result in an= 80-byte response (with a 64-byte block) instead of a 1016-byte response, c= onsiderably reducing the amplification provided." This indeed reduces the amplification attack, but instead it increases the = network traffic and transport complexity in the normal case. How about the = adding the following sentence: "The advantages of the amplification attack mitigation should be weighed ag= ainst the increase in network traffic in the general case." 33,E) Section 12.1.1: If we want to maintain the no-cache-key indication, we need to reflect that= in the requirements for IANA registration of new options too. 34,T) p.80: "Each entry in the sub-registry must include the Response Code = in the range 64-191, a description of the Response Code, and a reference to= the Response Code's documentation." Do we exclude 1.xx codes on purpose? 35,E) Depending on the outcome of comment 24, remove the reserved options 1= 28, 132, 136 and 140 from table 4 on p.82. 36,T) p.83: "The default value, if any. For a critical option with a defaul= t value, a discussion on how the default value enables processing by implem= entations not implementing the critical option (Section 5.4.4)." Non-critical options need to have a well considered default value too, as t= he other endpoint may not know whether the option was ignored or was not in= cluded because the endpoint uses the default value. I think IANA registrati= on should require text on default values in any case, although the text "No= default value has been defined." may be acceptable. 37,E) p.93: "The response includes a Payload of "22.3 C" and is 10 bytes lo= ng." I think this should be 11 bytes. 38,E) p.94: "Figure 16 shows a similar example, but the inclusion of an non= -empty Token (Value 0x20) in the request and (Jump 15 + 4 =3D 19) in the re= sponse, increasing the sizes to 18 and 12 bytes respectively." Remove "and (Jump 15 + 4 =3D 19) in the response". According to my calculations, the value 18 should be replaced by 17. 39,E) In the last example of Appendix B, a rather exotic URI is encoded. Is= such an URI allowed? I especially worry about the empty uri-path options a= nd "/" characters. --_000_46A1DF3F04371240B504290A071B4DB63CB1D314szxeml509mbx_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello all,

 

I have reviewed the CoAP spec. I have the comments b= elow.

After each comment number, I wrote an "E" = for "Editorial" or "T" for "Technical".<= /o:p>

I think the draft is in a very good shape, and that = most comments below can be resolved quite easily.

I look forward to your opinions!

 

Best regards,

Bert

 

 

1,E) p.9: "Provoking a Reset message (e.g., by = sending an empty Confirmable message) is also useful as an inexpensive chec= k of the liveness of an endpoint ("CoAP ping")."<= /p>

I am not sure if we should endorse provoking RST mes= sages by sending empty CON messages.

 

2,E) p.11: "One could think of CoAP logically a= s using a two-layer approach, a CoAP messaging layer used to deal with UDP = and the asynchronous nature of the interactions, and the request/response i= nteractions using Method and Response codes (see Figure 1). CoAP is however a single protocol, with messages and reque= st/response just features of the CoAP header."

I do not follow the thread about CoAP as a two layer= protocol, whereas in my view it is a plain single application layer protoc= ol. Is this text needed?

 

3,E) p.14: "almost, but not entirely unlike&quo= t;

Should this be "almost, but not entirely alike&= quot;?

 

4,T) p.21: "An empty message has a Code field s= et to 0. The Token Length field MUST be set to 0 and no bytes MUST be prese= nt after the Message ID field. If there are any bytes, they MUST be process= ed as a message format error."

p.32: "The Acknowledgement to the Confirmable r= esponse MUST also be an empty message, i.e. one that carries neither a requ= est nor a response."

This is violated by figure 10 in the block-10 draft,= where a block option is included in the ACK from a CON response. Change he= re or in block? Maybe there will be future options that may need inclusion = in ACKs to CON responses too?

 

5,E) p.23: "A server MAY relax the requirement = to answer all retransmissions of an idempotent request with the same respon= se (Section 4.2), so that it does not have to maintain state for Message ID= s. For example, an implementation might want to process duplicate transmissions of a GET, PUT or DELETE request as= separate requests if the effort incurred by duplicate processing is less e= xpensive than keeping track of previous responses would be."

Although not explicitly stated here, the draft seems= to imply that DELETE is idempotent. This is true from the result point of = view (afterwards the resource is deleted), however the first request should= give a different response (2.02 Deleted) than the subsequent request (4.04 Not Found). Is this issue too small to d= eclare DELETE non-idempotent?

 

6,E) p.25: "In order not to cause congestion, C= lients (including proxies) MUST strictly limit the number of simultaneous o= utstanding interactions that they maintain to a given server (including pro= xies) to NSTART. ... The default value of NSTART for this representation is 1."

The usage of NSTART is confusing in this text. It ma= y be better to start the text with "Let NSTART be an integer, which ha= s a default value 1.", after which continuing with "In order not = to cause congestion, ...".

 

7,T) p.25: "Unless this is modified by addition= al congestion control optimizations, it MUST be chosen in such a way that a= n endpoint does not exceed an average data rate of PROBING_RATE in sending = to another endpoint that does not respond."

p.26, in the table: "PROBING_RATE =3D 1 Byte/se= cond".

p.21: "Retransmission is controlled by two thin= gs that a CoAP endpoint MUST keep track of for each Confirmable message it = sends while waiting for an acknowledgement (or reset): a timeout and a retr= ansmission counter. For a new Confirmable message, the initial timeout is set to a random counter between ACK_TIMEOU= T and (ACK_TIMEOUT*ACK_RANDOM_FACTOR) (see Section 4.8), and the retransmis= sion counter is set to 0. When the timeout is triggered and the retransmiss= ion counter is less than MAX_RETRANSMIT, the message is retransmitted, the retransmission counter is incremented, a= nd the timeout is doubled. If the retransmission counter reaches MAX_RETRAN= SMIT on a timeout, or if the endpoint receives a Reset message, then the at= tempt to transmit the message is canceled and the application process informed of failure."=

It seems that PROBING_RATE is another constraint on = top of what is defined on p.21, since the algorithm of p.21 alone would alr= eady violate the probing rate, especially at the beginning of the retransmi= ssions. Is 1 Byte/second reasonable? Does it mean that a 16 byte CoAP message needs at least 16 seconds between= two subsequent retransmissions? Over which time frame is the PROBING_RATE = calculated?

Suggestion: remove PROBING_RATE.

 

8,T) NSTART=3D1 implies that you cannot send a bulk = of requests at once. Is this the intention, or would a small but higher val= ue of NSTART still be acceptable?

 

9,E) p. 28, According to my calculations the final v= alue EXCHANGE_LIFETIME should be 247, not 248.

 

10,E) An important goal of section 4.8.2 seems to be= finding a reasonable time after which message IDs can be re-used. Maybe th= at goal should be explicitly mentioned at the beginning of the section?

 

11,E) Depending on the resolution of comment 5, the = text in section 5.1, p29 may need to be updated.

 

12,E) p.32: "A token is intended for use as a c= lient-local identifier for differentiating between concurrent requests (see= Section 5.3); it could have been called a "request ID"."

Remove the reference to Section 5.3, especially sinc= e the text is in its subsection 5.3.1.

 

13,T) p.35: "an option is never "mandatory= ""

Maybe in the future there will be options that requi= re other options to be included? Or a option could be mandatory in the resp= onse, when responding on a critical option from a request.

 

14,T) p.37: "Implementation Note: On a quality = of implementation level, there is a strong expectation that a Content-Forma= t indication will be provided with resource representations whenever possib= le. This is not a "SHOULD"-level requirement solely because it is not a protocol requirement, and it also would be diff= icult to outline exactly in what cases this expectation can be violated.&qu= ot;

There could be other means to determine the content-= format. For example, if the resource URI has the suffix ".jpg", i= t is highly expectable that it refers to a picture coded as an octet-stream= . Would it be good to define a default value "octet-stream" for the content-format option?

 

15,E) p.37: "For responses indicating a client = or server error, the payload is considered a representation of the result o= f the requested action only if a Content-Format Option is given. In the abs= ence of this option, the payload is a Diagnostic Payload ({{diagnostic-message-payload}})."

Is this text needed? What does ({{diagnostic-message= -payload}}) mean? What is the format of the Diagnostic Payload?<= /p>

Suggestion: remove the text.

 

16,E) p.38: ""selected representation"= ;""

Fix the typo of the double quotes. Consider if the &= quot;selected representation" is a good name, as in fact the represent= ation is not selected. Maybe "candidate representation" is better= ?

 

17,T) p.39: "Unlike HTTP, the cachability of Co= AP responses does not depend on the request method, but on the Response Cod= e."

What does this mean? When the choice of the methods = is between PUT and GET, I suspect that the caching depends on that choice.<= o:p>

 

18,T) p.42: "The request URI in a proxy request= is specified as a string in the Proxy-Uri Option (see Section 5.10.2), whi= le the request URI in a request to an origin server is split into the Uri-H= ost, Uri-Port, Uri-Path and Uri-Query Options (see Section 5.10.1); alternatively the URI in a proxy request can be asse= mbled from a Proxy-Scheme option and the split options mentioned."

Also related to section 5.10.2 on p.50.

Why are there two ways to define the proxy URI? Mayb= e the Proxy-Uri option is not needed.

An advantage of the proxy-uri option may be that mul= tiple URIs can be included in a single request. If that is the case, why no= t mandate proxy-uri for all forward-proxy requests? Two mechanisms to provi= de the same functionality is unnecessary overhead.

 

19,T) The cache key seems to be the collection of op= tions that are needed to identify a particular representation of a resource= . After much reading, I understand that when a request contains options tha= t are in the cache key, and the proxy does not have a cached representation for exactly those values of the cach= e key options, then it needs to acquire the related representation, whereas= if all options are proxy-safe and not in the cache key, the proxy can igno= re them and provide the cached response.

The draft already implies that the no-cache-key prop= erty will seldom be used, as it reserves three bits of the option number fo= r it, and the option is only considered not a cache key when these three bi= ts are all set. In addition, the no-cache-key property can only hold for options that are proxy safe, leading to possibl= e option numbers 28, 29, 40, 41, 72, 73, ...

A proxy can safely ignore the no-cache-key property,= in which case it will consider all proxy-safe options to be in the cache k= ey and it does not need to check these bits.

The draft itself does not provide itself a proxy saf= e option that is not in the cache key.

Is this mechanism really needed? If so, provide a cl= ear definition of the cache-key is needed, also in the definitions section.=

 

20,E) It would be easier to look up the default port= value directly from table 1 on p.49.

 

21,E) The '-' in the 'N' column in table 1 on p.49 i= ndicates that the option per definition is in the cache-key. Provided that = we keep the no-cache-key property, add a clarification to the table.

 

22,E) p. 51: "The CoAP Accept option indicates = when included one or more times in a request, one or more Content-Formats, = each of which is an acceptable Content-Format for the client, in the order = of preference (most preferred first)."

This sentence is hard to read. How about the followi= ng rewrite:

"The CoAP Accept option can be used to indicate= which Content-Formats are acceptable to the client. Multiple Accept option= s can be included in a request, in order of preferred Content-Format (most = preferred first)."

 

23,E) p.52: "If one or more Location-* options = are present and thus a location URI is indicated (Section 5.10.7), the tagg= ed representation is the representation that would be retried by a GET requ= est to the location URI."

Replace "retried" by "retrieved"=

 

24,T) p.53: "... more Location-* options may be= defined in the future, and have been reserved option numbers 128, 132, 136= , and 140."

Are these reservations still needed, or are they rem= nants of the long jump times?

 

25,T) p.58: "7. If /port/ does not equal the re= quest's destination UDP port, include a Uri-Port Option and let that option= 's value be /port/."

Is my understanding correct that this happens only w= hen talking with forward-proxies?

 

26,T) p.63: "The NoSec and RawPublicKey modes a= re mandatory to implement for this specification."

Do we really want to mandate DTLS for all CoAP imple= mentations?

 

27,T) p.66: "A message is the same when it is s= ent within the same DTLS session and same epoch and has the same Message ID= ."

This requires the epoch to be shorter than the EXCHA= NGE_LIFETIME from section 4.8.1, as after this EXCHANGE_LIFETIME message id= s can be re-used.

 

28,T) p.71, section 10.1.4: "If the action perf= ormed by the POST method does not result in a resource that can be identifi= ed by a URI, a 2.04 (Changed) response MUST be returned to the client. If a= resource has been created on the origin server, a 2.01 (Created) response MUST be returned."

Can a resource that can be identified by an URI also= be changed, and thus a 2.04 (Changed) response returned? If so, simplify t= he first sentence.

 

29,E) p.71: "Unless otherwise specified all the= statements made are RECOMMENDED behavior; some highly constrained implemen= tations may need to resort to shortcuts."

I am not sure if there will be much constrained prox= ies. Maybe it could be rephrased as follows:

"Unless otherwise specified all the statements = made are RECOMMENDED behavior; implementations MAY defer from those recomme= ndations in accordance with their requirements."

 

30,E) p.71: "As the OPTIONS and TRACE methods a= re not supported in CoAP a 501 (Not Implemented) error MUST be returned to = the client."

Should the MUST be a SHOULD, as the section contains= recommendations?

 

31,E) p.74: "Also, a caching proxy MUST NOT mak= e cached values available to requests that have lesser transport security p= roperties than to which it would make available the process of forwarding t= he request in the first place."

What does this sentence mean? Clarify.

 

32,T) p.75: "A CoAP server can reduce the amoun= t of amplification it provides to an attacker by using slicing/blocking mod= es of CoAP [I-D.ietf-core-block] and offering large resource representation= s only in relatively small slices. E.g., for a 1000 byte resource, a 10-byte request might result in an 80-byte res= ponse (with a 64-byte block) instead of a 1016-byte response, considerably = reducing the amplification provided."

This indeed reduces the amplification attack, but in= stead it increases the network traffic and transport complexity in the norm= al case. How about the adding the following sentence:

"The advantages of the amplification attack mit= igation should be weighed against the increase in network traffic in the ge= neral case."

 

33,E) Section 12.1.1:

If we want to maintain the no-cache-key indication, = we need to reflect that in the requirements for IANA registration of new op= tions too.

 

34,T) p.80: "Each entry in the sub-registry mus= t include the Response Code in the range 64-191, a description of the Respo= nse Code, and a reference to the Response Code's documentation."<= /o:p>

Do we exclude 1.xx codes on purpose?

 

35,E) Depending on the outcome of comment 24, remove= the reserved options 128, 132, 136 and 140 from table 4 on p.82.

 

36,T) p.83: "The default value, if any. For a c= ritical option with a default value, a discussion on how the default value = enables processing by implementations not implementing the critical option = (Section 5.4.4)."

Non-critical options need to have a well considered = default value too, as the other endpoint may not know whether the option wa= s ignored or was not included because the endpoint uses the default value. = I think IANA registration should require text on default values in any case, although the text "No default val= ue has been defined." may be acceptable.

 

37,E) p.93: "The response includes a Payload of= "22.3 C" and is 10 bytes long."

I think this should be 11 bytes.

 

38,E) p.94: "Figure 16 shows a similar example,= but the inclusion of an non-empty Token (Value 0x20) in the request and (J= ump 15 + 4 =3D 19) in the response, increasing the sizes to 18 and 12 b= ytes respectively."

Remove "and (Jump 15 + 4 =3D 19) in the res= ponse".

According to my calculations, the value 18 should be= replaced by 17.

 

39,E) In the last example of Appendix B, a rather ex= otic URI is encoded. Is such an URI allowed? I especially worry about the e= mpty uri-path options and "/" characters.

--_000_46A1DF3F04371240B504290A071B4DB63CB1D314szxeml509mbx_-- From barryleiba.mailing.lists@gmail.com Thu Dec 20 20:19:27 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5004B21F8953 for ; Thu, 20 Dec 2012 20:19:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.035 X-Spam-Level: X-Spam-Status: No, score=-103.035 tagged_above=-999 required=5 tests=[AWL=-0.059, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C8sja++gIDc9 for ; Thu, 20 Dec 2012 20:19:26 -0800 (PST) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 87D4721F88E1 for ; Thu, 20 Dec 2012 20:19:26 -0800 (PST) Received: by mail-la0-f44.google.com with SMTP id d3so4350928lah.17 for ; Thu, 20 Dec 2012 20:19:25 -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 :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=VmB+GopOhvya8bawdBCKc8/ce/60nmv8OlGx1ZitUWo=; b=jaTivQhnh8+YlFUGtbwsjwIHcPjdA5nK+5Py3o2L5gjb6p4xYAOBMOrrwdQiS6qpnh 2u6PPujcOmlWBW7Q7ZUu2uNea/a5isQg6NkxUYbRSbY+FT/xe7DboygkC/GcXuhSbxDv XGzwTET2zB1Dibn8hmqQN1v/oUTmQ9uaXlX4QsG6SbjbPBCTGbnqoZONUmjxpsUdNRjl twPPoQT4M+VPnNhUIKkhgh54ICykfdP2o9dyq7KIZkt2Rkjp8LkMwT4AFdIudh1JXojK mtR4sMBq3G9scXfE5Eoqikc9JbX3u9X/NljI+MpjGtsAWWD7Q+lp8rZY9zilDQp4G9hI pplw== MIME-Version: 1.0 Received: by 10.112.51.233 with SMTP id n9mr4907887lbo.47.1356063565101; Thu, 20 Dec 2012 20:19:25 -0800 (PST) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.112.12.166 with HTTP; Thu, 20 Dec 2012 20:19:24 -0800 (PST) In-Reply-To: <46A1DF3F04371240B504290A071B4DB63CB1D314@szxeml509-mbx> References: <46A1DF3F04371240B504290A071B4DB63CB1D314@szxeml509-mbx> Date: Thu, 20 Dec 2012 23:19:24 -0500 X-Google-Sender-Auth: leWi5i2JbWrLJJyao9CT66wIRUM Message-ID: From: Barry Leiba To: Bert Greevenbosch Content-Type: multipart/alternative; boundary=f46d0401f97f173a0404d1552724 Cc: "core@ietf.org WG" Subject: Re: [core] draft-ietf-core-coap-13 WGLC - my comments X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 21 Dec 2012 04:19:27 -0000 --f46d0401f97f173a0404d1552724 Content-Type: text/plain; charset=ISO-8859-1 > 3,E) p.14: "almost, but not entirely unlike" > Should this be "almost, but not entirely alike"? It's a kind of "inside joke." It's referring to a line from the book "The Hitchhiker's Guide to the Galaxy", in which, when they ask the food synthesizer for tea, they get something "almost, but not entirely unlike tea." Barry --f46d0401f97f173a0404d1552724 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

>=A03,E) p.14: "almost, but not entirely unlike"<= /font>

>=A0Should this be "a= lmost, but not entirely alike"?

It's a kind of "inside joke." =A0It's referring to a= line from the book "The Hitchhiker's Guide to the Galaxy", i= n which, when they ask the food synthesizer for tea, they get something &qu= ot;almost, but not entirely unlike tea."

Barry
--f46d0401f97f173a0404d1552724-- From Bert.Greevenbosch@huawei.com Thu Dec 20 21:53:39 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBA8021F89E8 for ; Thu, 20 Dec 2012 21:53:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0eoSMl1EXdnL for ; Thu, 20 Dec 2012 21:53:39 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id AD82521F853A for ; Thu, 20 Dec 2012 21:53:37 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AMR88754; Fri, 21 Dec 2012 05:53:34 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 21 Dec 2012 05:53:03 +0000 Received: from SZXEML401-HUB.china.huawei.com (10.82.67.31) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 21 Dec 2012 05:53:10 +0000 Received: from SZXEML509-MBX.china.huawei.com ([10.82.67.37]) by szxeml401-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.003; Fri, 21 Dec 2012 13:50:29 +0800 From: Bert Greevenbosch To: Barry Leiba Thread-Topic: [core] draft-ietf-core-coap-13 WGLC - my comments Thread-Index: Ac3fJOBotWMwxik5SqmwNsss62gtLP//lNkA//9k16A= Date: Fri, 21 Dec 2012 05:50:29 +0000 Message-ID: <46A1DF3F04371240B504290A071B4DB63CB1D39B@szxeml509-mbx> References: <46A1DF3F04371240B504290A071B4DB63CB1D314@szxeml509-mbx> In-Reply-To: Accept-Language: en-GB, zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.110.143] Content-Type: multipart/alternative; boundary="_000_46A1DF3F04371240B504290A071B4DB63CB1D39Bszxeml509mbx_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "core@ietf.org WG" Subject: Re: [core] draft-ietf-core-coap-13 WGLC - my comments X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 21 Dec 2012 05:53:39 -0000 --_000_46A1DF3F04371240B504290A071B4DB63CB1D39Bszxeml509mbx_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Barry, Haha, yes, I have seen that citation more often. Maybe it here misses the "= quite" as in "Almost, but not quite, entirely unlike tea." tough. Maybe tha= t was done on purpose as the food synthesizer did a bad job in making tea, = whereas we want to convey much similarity between the CoAP methods and thei= r HTTP counterparts? Best regards, Bert From: barryleiba.mailing.lists@gmail.com [mailto:barryleiba.mailing.lists@g= mail.com] On Behalf Of Barry Leiba Sent: 21 December 2012 12:19 To: Bert Greevenbosch Cc: core@ietf.org WG Subject: Re: [core] draft-ietf-core-coap-13 WGLC - my comments > 3,E) p.14: "almost, but not entirely unlike" > Should this be "almost, but not entirely alike"? It's a kind of "inside joke." It's referring to a line from the book "The = Hitchhiker's Guide to the Galaxy", in which, when they ask the food synthes= izer for tea, they get something "almost, but not entirely unlike tea." Barry --_000_46A1DF3F04371240B504290A071B4DB63CB1D39Bszxeml509mbx_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Barry,

 

Haha, yes, I have seen that citation mo= re often. Maybe it here misses the "quite" as in "Almost, bu= t not quite, entirely unlike tea." tough. Maybe that was done on purpo= se as the food synthesizer did a bad job in making tea, whereas we want to co= nvey much similarity between the CoAP methods and their HTTP counterparts?<= o:p>

 

Best regards,

Bert

 

 

From: barryleiba.mailing.= lists@gmail.com [mailto:barryleiba.mailing.lists@gmail.com] On Behalf Of Barry Leiba
Sent: 21 December 2012 12:19
To: Bert Greevenbosch
Cc: core@ietf.org WG
Subject: Re: [core] draft-ietf-core-coap-13 WGLC - my comments<= /o:p>

 

> 3,E) p.14: "almost, but not entirely unlike"

> Should this be "almost, but not entirely alike"?

It's a kind of "inside joke."  It's r= eferring to a line from the book "The Hitchhiker's Guide to the Galaxy= ", in which, when they ask the food synthesizer for tea, they get some= thing "almost, but not entirely unlike tea."

 

Barry

--_000_46A1DF3F04371240B504290A071B4DB63CB1D39Bszxeml509mbx_-- From cabo@tzi.org Thu Dec 20 23:11:16 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4297B21F86BB for ; Thu, 20 Dec 2012 23:11:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ptvGST4O5zJe for ; Thu, 20 Dec 2012 23:11:14 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 70A4C21F85D2 for ; Thu, 20 Dec 2012 23:11:13 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id qBL7Armg002096; Fri, 21 Dec 2012 08:10:53 +0100 (CET) Received: from [192.168.217.105] (p54893288.dip.t-dialin.net [84.137.50.136]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 45860CC1; Fri, 21 Dec 2012 08:10:53 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: <46A1DF3F04371240B504290A071B4DB63CB1D39B@szxeml509-mbx> Date: Fri, 21 Dec 2012 08:10:52 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <6839CDEA-2045-4541-9E2A-CB24A3C8AFD0@tzi.org> References: <46A1DF3F04371240B504290A071B4DB63CB1D314@szxeml509-mbx> <46A1DF3F04371240B504290A071B4DB63CB1D39B@szxeml509-mbx> To: Bert Greevenbosch X-Mailer: Apple Mail (2.1499) Cc: Barry Leiba , "core@ietf.org WG" Subject: Re: [core] draft-ietf-core-coap-13 WGLC - my comments X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 21 Dec 2012 07:11:16 -0000 On Dec 21, 2012, at 06:50, Bert Greevenbosch = wrote: > Maybe it here misses the "quite" as in "Almost, but not quite, = entirely unlike tea." Oh, I'll take that as an editorial comment :-) (This wasn't intended as a direct quote, but more in the sense of the = general jargon as documented in http://www.catb.org/~esr/jargon/html/N/not-entirely-unlike-X.html as Barry correctly decoded.) Gr=FC=DFe, Carsten From cabo@tzi.org Thu Dec 20 23:36:42 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F25F121F8971 for ; Thu, 20 Dec 2012 23:36:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W-9dnvM95ex1 for ; Thu, 20 Dec 2012 23:36:41 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 9FA7321F857A for ; Thu, 20 Dec 2012 23:36:40 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id qBL7aUaG011130; Fri, 21 Dec 2012 08:36:30 +0100 (CET) Received: from [192.168.217.105] (p54893288.dip.t-dialin.net [84.137.50.136]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 65420CCD; Fri, 21 Dec 2012 08:36:30 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: <46A1DF3F04371240B504290A071B4DB63CB1D314@szxeml509-mbx> Date: Fri, 21 Dec 2012 08:36:29 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <42115B7C-3C57-4A42-9325-B89A6FE5CABB@tzi.org> References: <46A1DF3F04371240B504290A071B4DB63CB1D314@szxeml509-mbx> To: Bert Greevenbosch X-Mailer: Apple Mail (2.1499) Cc: "core@ietf.org WG" Subject: [core] BG1 -- CoAP Ping (Re: draft-ietf-core-coap-13 WGLC - my comments) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 21 Dec 2012 07:36:42 -0000 Hi Bert, I'll pick some of your comments and reply with my personal view. I'll construct a separate subject for each so we have some threading if = the discussion continues. On Dec 21, 2012, at 03:42, Bert Greevenbosch = wrote: > 1,E) p.9: "Provoking a Reset message (e.g., by sending an empty = Confirmable message) is also useful as an inexpensive check of the = liveness of an endpoint ("CoAP ping")." > I am not sure if we should endorse provoking RST messages by sending = empty CON messages. We have found that it is very useful to have some lightweight "are you = there" mechanism. This is both for diagnostics, and for address selection ahead of a = heavy-weight non-idempotent operation. Now we could define a NOOP method that does nothing. In a Confirmable = message, this would elicit an empty ACK. In total, this would look a lot like the mechanism described above, but = with a "positive" ACK. 4-byte request, 4-byte ACK. However, the empty/RST exchange has essentially the same properties, = with the simple advantage that you already (should) have implemented it. One method less, requires no additional code. Calling it out here was motivated by noticing that not every = implementation before ETSI CoAP2 caught the MUSTs that make it work. One could argue that a ping that "works" should not end in an "error" = message like RST. However, there are other cases where a RST is somewhat "normal", so = seeing a RST should not be raising red alarms anyway. So I agree a bit with the sentiment you are expressing, but I think it = is not sufficient reason to add a NOOP method. (I also briefly thought about instead adding an ECHO method (sends back = the payload) so you can run diagnostics with different packet sizes. With a payload of 0 bytes, this becomes similar to NOOP, except that the = ACK would carry a response code. Also sounds somewhat useful, but do we really need it? =20 We most likely don't want an equivalent of CHARGEN, as this would be = inviting amplification attacks.) Gr=FC=DFe, Carsten From cabo@tzi.org Thu Dec 20 23:47:40 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02EE121F89EB for ; Thu, 20 Dec 2012 23:47:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P7BkyNuycMEg for ; Thu, 20 Dec 2012 23:47:39 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id E342221F85C7 for ; Thu, 20 Dec 2012 23:47:38 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id qBL7lShX015345; Fri, 21 Dec 2012 08:47:28 +0100 (CET) Received: from [192.168.217.105] (p54893288.dip.t-dialin.net [84.137.50.136]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 8F38CCD7; Fri, 21 Dec 2012 08:47:27 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: <46A1DF3F04371240B504290A071B4DB63CB1D314@szxeml509-mbx> Date: Fri, 21 Dec 2012 08:47:26 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <4AE25BDF-9CAA-4AF6-BBD3-4460D7086E02@tzi.org> References: <46A1DF3F04371240B504290A071B4DB63CB1D314@szxeml509-mbx> To: Bert Greevenbosch X-Mailer: Apple Mail (2.1499) Cc: "core@ietf.org WG" Subject: [core] BG4 -- empty ACKs (Re: draft-ietf-core-coap-13 WGLC - my comments) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 21 Dec 2012 07:47:40 -0000 On Dec 21, 2012, at 03:42, Bert Greevenbosch = wrote: > 4,T) p.21: "An empty message has a Code field set to 0. The Token = Length field MUST be set to 0 and no bytes MUST be present after the = Message ID field. If there are any bytes, they MUST be processed as a = message format error." > p.32: "The Acknowledgement to the Confirmable response MUST also be an = empty message, i.e. one that carries neither a request nor a response." > This is violated by figure 10 in the block-10 draft, where a block = option is included in the ACK from a CON response. Change here or in = block? We had a long discussion of this in Sophia-Antipolis (ETSI CoAP2). This needs to be fixed in -block. (See my notes below.) > Maybe there will be future options that may need inclusion in ACKs to = CON responses too? The conclusion from this discussion was that it is a good thing to keep = empty ACKs empty so they can be left out when running CoAP over = alternate transports that have their own reliability mechanisms, such as = SMS or TCP. Gr=FC=DFe, Carsten Fixed examples for Block1-Block2 interaction: (Needs to add discussion of "Initiative".) Block options may be used in both directions of a single exchange. The following example demonstrates a blockwise POST request, resulting in a separate blockwise response. ~~~~~~~~~~~ CLIENT SERVER | | | CON [MID=3D1234], POST, /soap, 1/0/1/128 ------> | | | | <------ ACK [MID=3D1234], 2.01 Created, 1/0/1/128 | | | | CON [MID=3D1235], POST, /soap, 1/1/1/128 ------> | | | | <------ ACK [MID=3D1235], 2.01 Created, 1/1/1/128 | | | | CON [MID=3D1236], POST, /soap, 1/2/0/128 ------> | | | | <------ ACK [MID=3D1236], 0 | | | | <------ CON [MID=3D4712], 2.01 Created, 2/0/1/128, 1/2/0/128 | | | | ACK [MID=3D4712], 0 ------> | | | | <------ CON [MID=3D4713], 2.01 Created, 2/1/1/128 | | | | ACK [MID=3D4713], 0 ------> | | | | <------ CON [MID=3D4714], 2.01 Created, 2/2/1/128 | | | | ACK [MID=3D4714], 0 ------> | | | | <------ CON [MID=3D4715], 2.01 Created, 2/3/0/128 | | | | ACK [MID=3D4715], 0 ------> | ~~~~~~~~~~~ {: #post-response title=3D"Atomic blockwise POST with separate blockwise = response" } This model does provide for early negotiation input to the=20 ~~~~~~~~~~~ CLIENT SERVER | | | CON [MID=3D1234], POST, /soap, 1/0/1/128 ------> | | | | <------ ACK [MID=3D1234], 2.01 Created, 1/0/1/128 | | | | CON [MID=3D1235], POST, /soap, 1/1/1/128 ------> | | | | <------ ACK [MID=3D1235], 2.01 Created, 1/1/1/128 | | | | CON [MID=3D1236], POST, /soap, 1/2/0/128, 2/0/0/64 ------> | | | | <------ ACK [MID=3D1236], 0 | | | | <------ CON [MID=3D4712], 2.01 Created, 1/2/0/128, 2/0/1/64 | | | | ACK [MID=3D4712], 0 ------> | | | | <------ CON [MID=3D4713], 2.01 Created, 2/1/1/64 | | | | ACK [MID=3D4713], 0 ------> | | | | <------ CON [MID=3D4714], 2.01 Created, 2/2/1/64 | | | | ACK [MID=3D4714], 0 ------> | | | | <------ CON [MID=3D4715], 2.01 Created, 2/3/0/64 | | | | ACK [MID=3D4715], 0 ------> | ~~~~~~~~~~~ {: #post-response-e title=3D"Atomic blockwise POST with separate = blockwise response, early negotiation" } THERE IS NO LATE NEGOTIATION... From cabo@tzi.org Fri Dec 21 01:24:28 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 465A221F8548 for ; Fri, 21 Dec 2012 01:24:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.249 X-Spam-Level: X-Spam-Status: No, score=-107.249 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tRCT4AZeNxHT for ; Fri, 21 Dec 2012 01:24:27 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 0DBFE21F890E for ; Fri, 21 Dec 2012 01:24:26 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id qBL9OFMB003141; Fri, 21 Dec 2012 10:24:15 +0100 (CET) Received: from [192.168.217.117] (p54893288.dip.t-dialin.net [84.137.50.136]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id DC351D54; Fri, 21 Dec 2012 10:24:14 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: <46A1DF3F04371240B504290A071B4DB63CB1D314@szxeml509-mbx> Date: Fri, 21 Dec 2012 10:24:13 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <980474C2-9E1D-4ADF-8BCF-A9D47F1A7D9A@tzi.org> References: <46A1DF3F04371240B504290A071B4DB63CB1D314@szxeml509-mbx> To: Bert Greevenbosch X-Mailer: Apple Mail (2.1499) Cc: "core@ietf.org WG" Subject: [core] BG8 -- NSTART=1 (Re: draft-ietf-core-coap-13 WGLC - my comments) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 21 Dec 2012 09:24:28 -0000 On Dec 21, 2012, at 03:42, Bert Greevenbosch = wrote: > 8,T) NSTART=3D1 implies that you cannot send a bulk of requests at = once. Is this the intention, Yes. > or would a small but higher value of NSTART still be acceptable? According to RFC 5405, no. However, this is qualified for a 3-second interval, so there may be some = leeway here. What happens is this: The first request goes out. If it is acknowledged, the counter limited = by NSTART (we need a name for that) goes back to 0 and we can send the = second request. If it isn't, we retransmit the first request after 2-3 seconds, so we = continue to use up the RFC 5405 limit. If the first retransmission of the first request is acknowledged, we can = send the second request. If not, we might be able to squeeze in a second request if we only want = to stick to the letter of RFC 5405. However, the point of BEBO is to actually slow down in the face of = losses, so this shouldn't be overdone. If we have to do this, it may be a good idea to operate the second = request on the BEBO schedule of the first request (i.e., stick to the = maximum of the BEBO variables per peer). Of course, the 3 seconds of RFC 5405 were picked out of thin air at a = time when people weren't thinking that much about constrained networks. Maybe it actually is too low (i.e., too high a rate) for us! But, actually, clamping down NSTART to 1 if you know nothing about path = or peer is a *feature*. =20 The poor server receiving those requests has to process them. It may = only have one buffer. If a new request comes in before it had a chance to respond to the first = one, it will essentially have to drop the packet (or trash the old = request). (And similar considerations may apply to constrained routers on the = way.) Gr=FC=DFe, Carsten From cabo@tzi.org Fri Dec 21 01:34:18 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21A0C21F88C4 for ; Fri, 21 Dec 2012 01:34:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.302 X-Spam-Level: X-Spam-Status: No, score=-106.302 tagged_above=-999 required=5 tests=[AWL=-0.053, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rid4UqVtz6h3 for ; Fri, 21 Dec 2012 01:34:17 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 395E421F885C for ; Fri, 21 Dec 2012 01:34:17 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id qBL9Y8ck008559; Fri, 21 Dec 2012 10:34:08 +0100 (CET) Received: from [192.168.217.117] (p54893288.dip.t-dialin.net [84.137.50.136]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 6A5A9D6D; Fri, 21 Dec 2012 10:34:08 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: <46A1DF3F04371240B504290A071B4DB63CB1D314@szxeml509-mbx> Date: Fri, 21 Dec 2012 10:34:07 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <1210DB98-C3CA-49E5-BFB8-B81990696EA0@tzi.org> References: <46A1DF3F04371240B504290A071B4DB63CB1D314@szxeml509-mbx> To: Bert Greevenbosch X-Mailer: Apple Mail (2.1499) Cc: "core@ietf.org WG" Subject: [core] BG7 -- PROBING_RATE (Re: draft-ietf-core-coap-13 WGLC - my comments) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 21 Dec 2012 09:34:18 -0000 This may actually mainly be an editorial problem. On Dec 21, 2012, at 03:42, Bert Greevenbosch = wrote: > 7,T) p.25: "Unless this is modified by additional congestion control = optimizations, it MUST be chosen in such a way that an endpoint does not = exceed an average data rate of PROBING_RATE in sending to another = endpoint that does not respond." You are quoting this out of context. The context is: In order not to cause congestion, Clients (including proxies) MUST strictly limit the number of simultaneous outstanding interactions that they maintain to a given server (including proxies) to NSTART. An outstanding interaction is either a CON for which an ACK has not yet been received but is still expected (message layer) or a request for which neither a response nor an Acknowledgment message has yet been received but is still expected (which may both occur at the same time, counting as one outstanding interaction). The default value of NSTART for this specification is 1. Now this is the text that explains how to handle non-responding peers: A client stops expecting a response to a Confirmable request for which no acknowledgment message was received, after EXCHANGE_LIFETIME. The specific algorithm by which a client stops to "expect" a response to a Confirmable request that was acknowledged, or to a Non-confirmable request, is not defined. Unless this is modified by additional congestion control optimizations, it MUST be chosen in such a way that an endpoint does not exceed an average data rate of PROBING_RATE in sending to another endpoint that does not respond. So: 1) If a Confirmable request times out, you reset the NSTART counter (for = which we still need a name) to 0 after EXCHANGE_LIFETIME. 2) For Non-confirmables, we don't have a timeout. So we use = PROBING_RATE to decay the NSTART counter. > p.26, in the table: "PROBING_RATE =3D 1 Byte/second". Yes, that is quite conservative. I had 7 bytes/second, but there was = some transport input that this might be too much. > p.21: "Retransmission is controlled by two things that a CoAP endpoint = MUST keep track of for each Confirmable message it sends while waiting = for an acknowledgement (or reset): a timeout and a retransmission = counter. For a new Confirmable message, the initial timeout is set to a = random counter between ACK_TIMEOUT and (ACK_TIMEOUT*ACK_RANDOM_FACTOR) = (see Section 4.8), and the retransmission counter is set to 0. When the = timeout is triggered and the retransmission counter is less than = MAX_RETRANSMIT, the message is retransmitted, the retransmission counter = is incremented, and the timeout is doubled. If the retransmission = counter reaches MAX_RETRANSMIT on a timeout, or if the endpoint receives = a Reset message, then the attempt to transmit the message is canceled = and the application process informed of failure." Well, this is unrelated; none of this is controlled by PROBING_RATE. > It seems that PROBING_RATE is another constraint on top of what is = defined on p.21, since the algorithm of p.21 alone would already violate = the probing rate, especially at the beginning of the retransmissions. This is the editorial issue: We need to make clear that these two don't = interact. > Is 1 Byte/second reasonable? Does it mean that a 16 byte CoAP message = needs at least 16 seconds between two subsequent retransmissions? Over = which time frame is the PROBING_RATE calculated? Actually, there is a need for another clarification: The usage of = PROBING_RATE needs to account for overhead. So, for a 16 byte CoAP = message, you would account 16+8+40 =3D 64 bytes (IPv6), so, the next one = goes out only after 64 seconds or when the response is received, = whatever comes earlier. > Suggestion: remove PROBING_RATE. PROBING_RATE is needed to keep some control over Non-confirmables. I = don't think we can take that away. If you never send a Non-confirmable, you can ignore PROBING_RATE. Gr=FC=DFe, Carsten From cabo@tzi.org Fri Dec 21 02:12:19 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D10EB21F8AFC for ; Fri, 21 Dec 2012 02:12:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.299 X-Spam-Level: X-Spam-Status: No, score=-106.299 tagged_above=-999 required=5 tests=[AWL=-0.050, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vynjEoOS7IW8 for ; Fri, 21 Dec 2012 02:12:19 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id E04B321F8AEC for ; Fri, 21 Dec 2012 02:12:18 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id qBLAC8gf028443; Fri, 21 Dec 2012 11:12:08 +0100 (CET) Received: from [192.168.217.117] (p54893288.dip.t-dialin.net [84.137.50.136]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 4DE07DAD; Fri, 21 Dec 2012 11:12:08 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: <46A1DF3F04371240B504290A071B4DB63CB1D314@szxeml509-mbx> Date: Fri, 21 Dec 2012 11:12:07 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <0CDEB6C5-42BF-4012-B948-D58B7DE1DBE8@tzi.org> References: <46A1DF3F04371240B504290A071B4DB63CB1D314@szxeml509-mbx> To: Bert Greevenbosch X-Mailer: Apple Mail (2.1499) Cc: "core@ietf.org WG" Subject: [core] BG39 -- Exotic URI (Re: draft-ietf-core-coap-13 WGLC - my comments) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 21 Dec 2012 10:12:20 -0000 On Dec 21, 2012, at 03:42, Bert Greevenbosch = wrote: > 39,E) In the last example of Appendix B, a rather exotic URI is = encoded. Is such an URI allowed? I especially worry about the empty = uri-path options and "/" characters. Yes, such a URI is allowed. There have been comments to the previous = WGLC that the likelihood of implementers getting this right is low. Thus the example. (We all know that implementers tend to implement the = examples, not so much the text.) Empty Uri-Path options just reared their ugly head when we started to do = nested link-format resources. If you have a link-format resource at coap://foo.bar then as an anchor means coap://foo.bar/baz which is what most people would expect. If you have a "nested" link-format resource at coap://foo.bar/qux then as an anchor means coap://foo.bar/baz which is NOT what most people expect. You have to put the resource at coap://foo.bar/qux/ so that as an anchor means coap://foo.bar/qux/baz Aren't relative-path URIs fun? To encode coap://foo.bar/qux/ you need Uri-Path "qux" Uri-Path "" This is a piece of URI complexity that I don't think we can avoid to = mimic in CoAP. Gr=FC=DFe, Carsten (PS.: Fun observation: The encoding of the second Uri-Path option is a = single null byte.) From hartke@tzi.org Fri Dec 21 03:04:38 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7EA421F8626 for ; Fri, 21 Dec 2012 03:04:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.627 X-Spam-Level: X-Spam-Status: No, score=-4.627 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7V4-5-ACl1hA for ; Fri, 21 Dec 2012 03:04:38 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 26D9B21F87A3 for ; Fri, 21 Dec 2012 03:04:37 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id qBLB4VZM026552 for ; Fri, 21 Dec 2012 12:04:31 +0100 (CET) Received: from mail-la0-f50.google.com (mail-la0-f50.google.com [209.85.215.50]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id EDE63DF9 for ; Fri, 21 Dec 2012 12:04:30 +0100 (CET) Received: by mail-la0-f50.google.com with SMTP id c1so4828763lah.37 for ; Fri, 21 Dec 2012 03:04:30 -0800 (PST) Received: by 10.112.49.202 with SMTP id w10mr4938613lbn.2.1356087870339; Fri, 21 Dec 2012 03:04:30 -0800 (PST) MIME-Version: 1.0 Received: by 10.112.95.166 with HTTP; Fri, 21 Dec 2012 03:04:09 -0800 (PST) In-Reply-To: <0CDEB6C5-42BF-4012-B948-D58B7DE1DBE8@tzi.org> References: <46A1DF3F04371240B504290A071B4DB63CB1D314@szxeml509-mbx> <0CDEB6C5-42BF-4012-B948-D58B7DE1DBE8@tzi.org> From: Klaus Hartke Date: Fri, 21 Dec 2012 13:04:09 +0200 Message-ID: To: "core@ietf.org WG" Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [core] BG39 -- Exotic URI (Re: draft-ietf-core-coap-13 WGLC - my comments) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 21 Dec 2012 11:04:39 -0000 Carsten Bormann wrote: > You have to put the resource at > > coap://foo.bar/qux/ > > so that as an anchor means > > coap://foo.bar/qux/baz RFC6690 says that, if the link has no "anchor" and no "rel" attribute, then the Context URI is the Origin of the link format resource's base URI. The Origin of is the triple ("coap", "foo.bar", 5683). So, for this example, the result should be , no? Klaus From cabo@tzi.org Fri Dec 21 03:28:48 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 275E621F85BC for ; Fri, 21 Dec 2012 03:28:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.297 X-Spam-Level: X-Spam-Status: No, score=-106.297 tagged_above=-999 required=5 tests=[AWL=-0.048, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DO2pQpsyluBl for ; Fri, 21 Dec 2012 03:28:47 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 5BCA721F852B for ; Fri, 21 Dec 2012 03:28:47 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id qBLBSi8e007999 for ; Fri, 21 Dec 2012 12:28:45 +0100 (CET) Received: from [192.168.217.105] (p54893288.dip.t-dialin.net [84.137.50.136]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 95545E1B; Fri, 21 Dec 2012 12:28:44 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: Date: Fri, 21 Dec 2012 12:28:43 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <46A1DF3F04371240B504290A071B4DB63CB1D314@szxeml509-mbx> <0CDEB6C5-42BF-4012-B948-D58B7DE1DBE8@tzi.org> To: Klaus Hartke X-Mailer: Apple Mail (2.1499) Cc: "core@ietf.org WG" Subject: Re: [core] BG39 -- Exotic URI (Re: draft-ietf-core-coap-13 WGLC - my comments) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 21 Dec 2012 11:28:48 -0000 On Dec 21, 2012, at 12:04, Klaus Hartke wrote: > Carsten Bormann wrote: >> You have to put the resource at >>=20 >> coap://foo.bar/qux/ >>=20 >> so that as an anchor means >>=20 >> coap://foo.bar/qux/baz >=20 > RFC6690 says that, if the link has no "anchor" and no "rel" attribute, > then the Context URI is the Origin of the link format resource's base > URI. The Origin of is the triple ("coap", > "foo.bar", 5683). So, for this example, the result should be > , no? OK, so let's not take RFC 6690 as an example but any other content = format that simply makes use of the rules in section 5 of RFC 3986. My more general point is that >> coap://foo.bar/qux/ is different from >> coap://foo.bar/qux so we need a way to represent it. And that's probably the most = important reason Uri-Path components need to be able to be zero-length. (The more general principle enabled by this is data transparency, which = is also a good thing to have.) Gr=FC=DFe, Carsten From cabo@tzi.org Fri Dec 21 07:47:21 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97EC821F86D1 for ; Fri, 21 Dec 2012 07:47:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.294 X-Spam-Level: X-Spam-Status: No, score=-106.294 tagged_above=-999 required=5 tests=[AWL=-0.045, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1ttrqjoJB6r7 for ; Fri, 21 Dec 2012 07:47:20 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 1EE2E21F86AF for ; Fri, 21 Dec 2012 07:47:19 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id qBLFl6en001566; Fri, 21 Dec 2012 16:47:07 +0100 (CET) Received: from [192.168.217.105] (p54892B6F.dip.t-dialin.net [84.137.43.111]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 44E3FFB5; Fri, 21 Dec 2012 16:47:06 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: <46A1DF3F04371240B504290A071B4DB63CB1D314@szxeml509-mbx> Date: Fri, 21 Dec 2012 16:47:05 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <46A1DF3F04371240B504290A071B4DB63CB1D314@szxeml509-mbx> To: Bert Greevenbosch X-Mailer: Apple Mail (2.1499) Cc: "core@ietf.org WG" Subject: [core] BG24, BG35 -- reserved Location-* options (Re: draft-ietf-core-coap-13 WGLC - my comments) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 21 Dec 2012 15:47:21 -0000 On Dec 21, 2012, at 03:42, Bert Greevenbosch = wrote: > 24,T) p.53: "... more Location-* options may be defined in the future, = and have been reserved option numbers 128, 132, 136, and 140." > Are these reservations still needed, or are they remnants of the long = jump times? > 35,E) Depending on the outcome of comment 24, remove the reserved = options 128, 132, 136 and 140 from table 4 on p.82. They are still needed. Long jump just facilitated giving them higher option numbers (and we = could go even higher if we wanted). But the point is that any endpoint that is trying to piece together a = Location and finds one of these options BUT doesn't understand it knows = that it can't properly piece together the location. This is an evolvability problem: We don't have any other way right now to make elective options depend on = each other, where some of them will only be defined in the future, if = ever. Gr=FC=DFe, Carsten From darconeous@gmail.com Mon Dec 24 07:55:19 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB7EB21F86B3 for ; Mon, 24 Dec 2012 07:55:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zNYpqEjJEqOg for ; Mon, 24 Dec 2012 07:55:19 -0800 (PST) Received: from mail-ia0-f176.google.com (mail-ia0-f176.google.com [209.85.210.176]) by ietfa.amsl.com (Postfix) with ESMTP id CD1B521F86A8 for ; Mon, 24 Dec 2012 07:55:18 -0800 (PST) Received: by mail-ia0-f176.google.com with SMTP id y26so5926474iab.7 for ; Mon, 24 Dec 2012 07:55:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:content-type:content-transfer-encoding:date:subject :to:message-id:mime-version:x-mailer; bh=DnnxCgei5eyyAdItAcjP/zP1OhaM50OpbO7YpxjA7Yg=; b=q5EaRebgbK/H1rgwlna670jBH9xbQSo45i8Wo5NUFA4r6hkKznds/A1VTzLCsN5BBr Y8rh+vial5EpyM0b3qf4o0ldv/XwTs06FGGzMj5Vd+G9egfhR4TR6ytVqOF6TOqJkZKG dNFtnCEmaVDMFo47hV138uNZU51sS+9MhXz/hiTFZfW9R3JA/aTCeDsBy74dvYa51aTo TXniTnq478a6u59RgBHaXHZspxclSrYiWEmeh02Vdk8Tlt1Asl4lgMb++Vl4vyg/5CFG O3N9b6R9EuNhh06RfEvWeHOHCtjwTDqpkcKePWDnkInUGtQ/7OvOGJZUsf8L3NFWfU5T SyXg== X-Received: by 10.50.13.173 with SMTP id i13mr15120186igc.93.1356364518376; Mon, 24 Dec 2012 07:55:18 -0800 (PST) Received: from ?IPv6:2001:470:1f11:b36:542e:3d9c:1e2b:b0a0? ([2001:470:1f11:b36:542e:3d9c:1e2b:b0a0]) by mx.google.com with ESMTPS id gk1sm17128304igc.5.2012.12.24.07.55.17 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 24 Dec 2012 07:55:17 -0800 (PST) From: Robert Quattlebaum Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Mon, 24 Dec 2012 10:55:19 -0500 To: IETF CoRE Working Group Message-Id: <76B4185D-C1CF-4DF8-89C2-8C610D7A3669@gmail.com> Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) Subject: [core] Apparent race condition in blockwise transfer draft X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 24 Dec 2012 16:02:59 -0000 Hello everyone, I just wanted to bring up a race condition apparently present in the current blockwise transfer draft. However, even if you are not interested in draft-ietf-core-block, you may want to read over this email anyway: Similar problems may be present in protocols which need the server to associate multiple messages as being a part of the same logical request. For now I'll limit the discussion to draft-ietf-core-block-10. Previously, the token field (as well as the source IP address and port) could be used by the server to correlate multiple messages that were a part of the same logical request ("token-affinity"). In this sense the token field was not really opaque because the server was relying on the value of the token to not change between subsequent messages in the same logical request. However, this semantic-entanglement had the benefit of ensuring truly atomic behavior of requests which consist of multiple messages, without depending on artificial limitations on how the protocol should be used or the behavior of a specific transport layer. At some point over the past year (Forgive me, I haven't been paying attention), the semantics of the token parameter was clarified to be entirely opaque (meaning that only the client's address/port could be used for determining which messages are a part of the same blocked request). This was a reasonable change because it allows client implementations to be more flexible. However, without further clarification or additional mechanisms, this change leads to undefined/unreliable behavior in certain cases. Consider the case where you have a LoWPAN where nodes regularly dump gathered information to a CoAP server in "the cloud" via a CoAP-CoAP proxy. If two (or more) nodes try to perform a large POST (using Block1) to the same CoAP URL thru the proxy at the same time, the destination machine in the cloud has no way to differentiate the messages as being two independent atomic requests. In a previous discussion off-list, Carsten suggested that the proxy could identify the start of subsequent requests as potentially conflicting and use a different source port for each conflicting request sent from the proxy, but this technique only works if the cloud-side transport layer uses the UDP/IP transport---this technique would not work if the proxy was sending requests to the cloud via CoAP-over-SMS, as described in section 14 of draft-becker-core-coap-sms-gprs-02. I think the root of this problem is the reliance on information from the transport layer in determining which individual messages belong to the same logical request. Doing this just happens to work out in most cases. However, because these edge cases are transient in nature, diagnosing such problems in the field may be very difficult and frustrating. Sure, there are work-arounds, but they have specific disadvantages which may not be obvious. The bottom line is that by refining the semantics of the token field to no longer allow the server to use token-affinity to associate multiple messages to logical requests, a race condition has been introduced into the protocol. This race condition was hidden by the fact that, by using the address/port information from the transport layer, things *usually* work just fine. Usually, but not always. All that being said, I don't necessarily believe that reverting the token behavior is necessarily the right solution to this problem: Allowing the client to use the token to keep track of state on a message-per-message basis is useful. The trick is giving the same flexibility to the server: If we can't rely entirely on the transport layer information to associate logically-related messages (and we can't use the token) then what should be used? We could always simply document this class of problems in the draft so that implementors are aware that they may need to work around it, but I worry that this may be the first of a class of similar race conditions if this issue is not addressed directly. Thoughts? __________________ Robert Quattlebaum eMail: darco@deepdarc.com www: http://www.deepdarc.com/ From Bert.Greevenbosch@huawei.com Wed Dec 26 22:49:51 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E9EE21F8BBB for ; Wed, 26 Dec 2012 22:49:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vNv05d6hwJ6x for ; Wed, 26 Dec 2012 22:49:50 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 0D05D21F8846 for ; Wed, 26 Dec 2012 22:49:46 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AMW52356; Thu, 27 Dec 2012 06:49:45 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 27 Dec 2012 06:49:21 +0000 Received: from SZXEML450-HUB.china.huawei.com (10.82.67.193) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 27 Dec 2012 06:49:44 +0000 Received: from SZXEML509-MBX.china.huawei.com ([10.82.67.37]) by szxeml450-hub.china.huawei.com ([10.82.67.193]) with mapi id 14.01.0323.003; Thu, 27 Dec 2012 14:48:47 +0800 From: Bert Greevenbosch To: Carsten Bormann , Klaus Hartke Thread-Topic: [core] BG39 -- Exotic URI (Re: draft-ietf-core-coap-13 WGLC - my comments) Thread-Index: AQHN32r9pbBCjiD8CkaPnTRDAgaOQpgil7eAgAlO58A= Date: Thu, 27 Dec 2012 06:48:46 +0000 Message-ID: <46A1DF3F04371240B504290A071B4DB63CB1D8B8@szxeml509-mbx> References: <46A1DF3F04371240B504290A071B4DB63CB1D314@szxeml509-mbx> <0CDEB6C5-42BF-4012-B948-D58B7DE1DBE8@tzi.org> In-Reply-To: Accept-Language: en-GB, zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.110.143] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "core@ietf.org WG" Subject: Re: [core] BG39 -- Exotic URI (Re: draft-ietf-core-coap-13 WGLC - my comments) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 27 Dec 2012 06:49:51 -0000 Hi Carsten and Klaus, I have checked RFC 3986, and section 6.2.4 indeed indicates that the two UR= Is "http://example.com/data" and "http://example.com/data/" are considered = different unless there are strong reasons to believe they are equivalent. T= hat justifies an empty URI-Path option on the end of the URI. I didn't find text in RFC 3986 that forbids the example URI (coap://198.51.= 100.1:61616//%2F//?%2F%2F&?%26), so on the risk of a false positive, I woul= d say the URI indeed is valid. =20 I had some worries about the two slashes at the beginning of the path compo= nent. However RFC 3986 forbids this only for relative URIs, not for absolut= e URIs such as this one (see also the schema below). Best regards, Bert URI =3D scheme ":" hier-part [ "?" query ] [ "#" fragment ] hier-part =3D "//" authority path-abempty / path-absolute / path-rootless / path-empty path-abempty =3D *( "/" segment ) path-absolute =3D "/" [ segment-nz *( "/" segment ) ] path-rootless =3D segment-nz *( "/" segment ) path-empty =3D 0 segment =3D *pchar segment-nz =3D 1*pchar pchar =3D unreserved / pct-encoded / sub-delims / ":" / "@" unreserved =3D ALPHA / DIGIT / "-" / "." / "_" / "~" =20 pct-encoded =3D "%" HEXDIG HEXDIG sub-delims =3D "!" / "$" / "&" / "'" / "(" / ")" / "*" / "+" / ","= / ";" / "=3D"=09 -----Original Message----- From: core-bounces@ietf.org [mailto:core-bounces@ietf.org] On Behalf Of Car= sten Bormann Sent: 21 December 2012 19:29 To: Klaus Hartke Cc: core@ietf.org WG Subject: Re: [core] BG39 -- Exotic URI (Re: draft-ietf-core-coap-13 WGLC - = my comments) On Dec 21, 2012, at 12:04, Klaus Hartke wrote: > Carsten Bormann wrote: >> You have to put the resource at >>=20 >> coap://foo.bar/qux/ >>=20 >> so that as an anchor means >>=20 >> coap://foo.bar/qux/baz >=20 > RFC6690 says that, if the link has no "anchor" and no "rel" attribute, > then the Context URI is the Origin of the link format resource's base > URI. The Origin of is the triple ("coap", > "foo.bar", 5683). So, for this example, the result should be > , no? OK, so let's not take RFC 6690 as an example but any other content format t= hat simply makes use of the rules in section 5 of RFC 3986. My more general point is that >> coap://foo.bar/qux/ is different from >> coap://foo.bar/qux so we need a way to represent it. And that's probably the most important r= eason Uri-Path components need to be able to be zero-length. (The more general principle enabled by this is data transparency, which is = also a good thing to have.) Gr=FC=DFe, Carsten _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core From Bert.Greevenbosch@huawei.com Wed Dec 26 23:13:42 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A08021F8D48 for ; Wed, 26 Dec 2012 23:13:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RVEkfM56vHrb for ; Wed, 26 Dec 2012 23:13:41 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 342E721F8D47 for ; Wed, 26 Dec 2012 23:13:41 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AMW53873; Thu, 27 Dec 2012 07:13:39 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 27 Dec 2012 07:13:15 +0000 Received: from SZXEML452-HUB.china.huawei.com (10.82.67.195) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 27 Dec 2012 15:13:38 +0800 Received: from SZXEML509-MBX.china.huawei.com ([10.82.67.37]) by szxeml452-hub.china.huawei.com ([10.82.67.195]) with mapi id 14.01.0323.003; Thu, 27 Dec 2012 15:13:35 +0800 From: Bert Greevenbosch To: Carsten Bormann Thread-Topic: BG24, BG35 -- reserved Location-* options (Re: [core] draft-ietf-core-coap-13 WGLC - my comments) Thread-Index: AQHN35J2WH3R3smRvkqDyKt6xvNf3ZgsPn8Q Date: Thu, 27 Dec 2012 07:13:35 +0000 Message-ID: <46A1DF3F04371240B504290A071B4DB63CB1D8D4@szxeml509-mbx> References: <46A1DF3F04371240B504290A071B4DB63CB1D314@szxeml509-mbx> In-Reply-To: Accept-Language: en-GB, zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.110.143] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "core@ietf.org WG" Subject: Re: [core] BG24, BG35 -- reserved Location-* options (Re: draft-ietf-core-coap-13 WGLC - my comments) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 27 Dec 2012 07:13:42 -0000 Hi Carsten, Thanks for your explanation. I certainly understand your point. However, I am not sure if reserving the location options justifies it. Espe= cially since now every client that supports location-path and location-quer= y MUST check for the absence of the elective options 128, 132, 136 and 140 = before interpreting the known location options. Although the draft indeed requires this check: "If any of these reserved op= tion numbers occurs in addition to Location-Path and/or Location-Query and = are not supported, then a 4.02 (Bad Option) error MUST be returned.", I won= der how many implementations actually do it. =20 Apart from that, there may be other elective options in the future that rel= ate to already existent options. Why not reserve numbers for them? I am not= really proposing this, but I wonder why, as an exceptional case, we do thi= s for future location-* options. It seems we are looking for some kind of option hierarchy: elective options= that are not really elective when other options are present. Why not just = make these options critical? Best regards, Bert -----Original Message----- From: Carsten Bormann [mailto:cabo@tzi.org]=20 Sent: 21 December 2012 23:47 To: Bert Greevenbosch Cc: core@ietf.org WG Subject: BG24, BG35 -- reserved Location-* options (Re: [core] draft-ietf-c= ore-coap-13 WGLC - my comments) On Dec 21, 2012, at 03:42, Bert Greevenbosch = wrote: > 24,T) p.53: "... more Location-* options may be defined in the future, an= d have been reserved option numbers 128, 132, 136, and 140." > Are these reservations still needed, or are they remnants of the long jum= p times? > 35,E) Depending on the outcome of comment 24, remove the reserved options= 128, 132, 136 and 140 from table 4 on p.82. They are still needed. Long jump just facilitated giving them higher option numbers (and we could = go even higher if we wanted). But the point is that any endpoint that is trying to piece together a Locat= ion and finds one of these options BUT doesn't understand it knows that it = can't properly piece together the location. This is an evolvability problem: We don't have any other way right now to make elective options depend on ea= ch other, where some of them will only be defined in the future, if ever. Gr=FC=DFe, Carsten From Bert.Greevenbosch@huawei.com Wed Dec 26 23:48:50 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC35421F8D3F for ; Wed, 26 Dec 2012 23:48:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 51rikU-pAeSm for ; Wed, 26 Dec 2012 23:48:49 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 5596921F8D3C for ; Wed, 26 Dec 2012 23:48:49 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AOF59999; Thu, 27 Dec 2012 07:48:48 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 27 Dec 2012 07:48:14 +0000 Received: from SZXEML449-HUB.china.huawei.com (10.82.67.192) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 27 Dec 2012 07:48:47 +0000 Received: from SZXEML509-MBX.china.huawei.com ([10.82.67.37]) by szxeml449-hub.china.huawei.com ([10.82.67.192]) with mapi id 14.01.0323.003; Thu, 27 Dec 2012 15:47:11 +0800 From: Bert Greevenbosch To: Carsten Bormann Thread-Topic: BG4 -- empty ACKs (Re: [core] draft-ietf-core-coap-13 WGLC - my comments) Thread-Index: AQHN3097StcQQpyer0GID+MyVZw60pgsSM7g Date: Thu, 27 Dec 2012 07:47:05 +0000 Message-ID: <46A1DF3F04371240B504290A071B4DB63CB1D8F3@szxeml509-mbx> References: <46A1DF3F04371240B504290A071B4DB63CB1D314@szxeml509-mbx> <4AE25BDF-9CAA-4AF6-BBD3-4460D7086E02@tzi.org> In-Reply-To: <4AE25BDF-9CAA-4AF6-BBD3-4460D7086E02@tzi.org> Accept-Language: en-GB, zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.110.143] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "core@ietf.org WG" Subject: Re: [core] BG4 -- empty ACKs (Re: draft-ietf-core-coap-13 WGLC - my comments) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 27 Dec 2012 07:48:50 -0000 Hi Carsten, We had a long discussion of this in Sophia-Antipolis (ETSI CoAP2). This needs to be fixed in -block. ... The conclusion from this discussion was that it is a good thing to keep emp= ty ACKs empty so they can be left out when running CoAP over alternate tran= sports that have their own reliability mechanisms, such as SMS or TCP. Yes, that makes a lot of sense. Then indeed it is best to fix it in the Blo= ck draft. B.T.W. The below sequence could also make sense when the client sent a PUT/= POST request without Block, but the server needs to use Block in its respon= se. Would it then would be something like below? CLIENT SERVER | | | CON [MID=3D1234], POST, /soap ------> | | | | <------ ACK [MID=3D1236], 0 | | | | <------ CON [MID=3D4712], 2.01 Created, 2/0/1/128 | | | | ACK [MID=3D4712], 0 ------> | | | | <------ CON [MID=3D4713], 2.01 Created, 2/1/1/128 | | | | ACK [MID=3D4713], 0 ------> | | | | <------ CON [MID=3D4714], 2.01 Created, 2/2/1/128 | | | | ACK [MID=3D4714], 0 ------> | | | | <------ CON [MID=3D4715], 2.01 Created, 2/3/0/128 | | | | ACK [MID=3D4715], 0 ------> | Best regards, Bert -----Original Message----- From: Carsten Bormann [mailto:cabo@tzi.org]=20 Sent: 21 December 2012 15:47 To: Bert Greevenbosch Cc: core@ietf.org WG Subject: BG4 -- empty ACKs (Re: [core] draft-ietf-core-coap-13 WGLC - my co= mments) On Dec 21, 2012, at 03:42, Bert Greevenbosch = wrote: > 4,T) p.21: "An empty message has a Code field set to 0. The Token Length = field MUST be set to 0 and no bytes MUST be present after the Message ID fi= eld. If there are any bytes, they MUST be processed as a message format err= or." > p.32: "The Acknowledgement to the Confirmable response MUST also be an em= pty message, i.e. one that carries neither a request nor a response." > This is violated by figure 10 in the block-10 draft, where a block option= is included in the ACK from a CON response. Change here or in block? We had a long discussion of this in Sophia-Antipolis (ETSI CoAP2). This needs to be fixed in -block. (See my notes below.) > Maybe there will be future options that may need inclusion in ACKs to CON= responses too? The conclusion from this discussion was that it is a good thing to keep emp= ty ACKs empty so they can be left out when running CoAP over alternate tran= sports that have their own reliability mechanisms, such as SMS or TCP. Gr=FC=DFe, Carsten Fixed examples for Block1-Block2 interaction: (Needs to add discussion of "Initiative".) Block options may be used in both directions of a single exchange. The following example demonstrates a blockwise POST request, resulting in a separate blockwise response. ~~~~~~~~~~~ CLIENT SERVER | | | CON [MID=3D1234], POST, /soap, 1/0/1/128 ------> | | | | <------ ACK [MID=3D1234], 2.01 Created, 1/0/1/128 | | | | CON [MID=3D1235], POST, /soap, 1/1/1/128 ------> | | | | <------ ACK [MID=3D1235], 2.01 Created, 1/1/1/128 | | | | CON [MID=3D1236], POST, /soap, 1/2/0/128 ------> | | | | <------ ACK [MID=3D1236], 0 | | | | <------ CON [MID=3D4712], 2.01 Created, 2/0/1/128, 1/2/0/128 | | | | ACK [MID=3D4712], 0 ------> | | | | <------ CON [MID=3D4713], 2.01 Created, 2/1/1/128 | | | | ACK [MID=3D4713], 0 ------> | | | | <------ CON [MID=3D4714], 2.01 Created, 2/2/1/128 | | | | ACK [MID=3D4714], 0 ------> | | | | <------ CON [MID=3D4715], 2.01 Created, 2/3/0/128 | | | | ACK [MID=3D4715], 0 ------> | ~~~~~~~~~~~ {: #post-response title=3D"Atomic blockwise POST with separate blockwise re= sponse" } This model does provide for early negotiation input to the=20 ~~~~~~~~~~~ CLIENT SERVER | | | CON [MID=3D1234], POST, /soap, 1/0/1/128 ------> | | | | <------ ACK [MID=3D1234], 2.01 Created, 1/0/1/128 | | | | CON [MID=3D1235], POST, /soap, 1/1/1/128 ------> | | | | <------ ACK [MID=3D1235], 2.01 Created, 1/1/1/128 | | | | CON [MID=3D1236], POST, /soap, 1/2/0/128, 2/0/0/64 ------> | | | | <------ ACK [MID=3D1236], 0 | | | | <------ CON [MID=3D4712], 2.01 Created, 1/2/0/128, 2/0/1/64 | | | | ACK [MID=3D4712], 0 ------> | | | | <------ CON [MID=3D4713], 2.01 Created, 2/1/1/64 | | | | ACK [MID=3D4713], 0 ------> | | | | <------ CON [MID=3D4714], 2.01 Created, 2/2/1/64 | | | | ACK [MID=3D4714], 0 ------> | | | | <------ CON [MID=3D4715], 2.01 Created, 2/3/0/64 | | | | ACK [MID=3D4715], 0 ------> | ~~~~~~~~~~~ {: #post-response-e title=3D"Atomic blockwise POST with separate blockwise = response, early negotiation" } THERE IS NO LATE NEGOTIATION... From Bert.Greevenbosch@huawei.com Thu Dec 27 01:28:21 2012 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFBCF21F8C54 for ; Thu, 27 Dec 2012 01:28:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S9wmnCCMgH+2 for ; Thu, 27 Dec 2012 01:28:19 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 3381F21F8B2B for ; Thu, 27 Dec 2012 01:28:16 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AOF67633; Thu, 27 Dec 2012 09:28:15 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 27 Dec 2012 09:27:50 +0000 Received: from SZXEML450-HUB.china.huawei.com (10.82.67.193) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 27 Dec 2012 09:28:14 +0000 Received: from SZXEML509-MBX.china.huawei.com ([10.82.67.37]) by szxeml450-hub.china.huawei.com ([10.82.67.193]) with mapi id 14.01.0323.003; Thu, 27 Dec 2012 17:28:08 +0800 From: Bert Greevenbosch To: Carsten Bormann Thread-Topic: BG7 -- PROBING_RATE (Re: [core] draft-ietf-core-coap-13 WGLC - my comments) Thread-Index: AQHN315iJ1Q/0+sXYEmo5E7r/F2NcJgsXhDA Date: Thu, 27 Dec 2012 09:28:07 +0000 Message-ID: <46A1DF3F04371240B504290A071B4DB63CB1D925@szxeml509-mbx> References: <46A1DF3F04371240B504290A071B4DB63CB1D314@szxeml509-mbx> <1210DB98-C3CA-49E5-BFB8-B81990696EA0@tzi.org> In-Reply-To: <1210DB98-C3CA-49E5-BFB8-B81990696EA0@tzi.org> Accept-Language: en-GB, zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.110.143] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "core@ietf.org WG" Subject: Re: [core] BG7 -- PROBING_RATE (Re: draft-ietf-core-coap-13 WGLC - my comments) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 27 Dec 2012 09:28:21 -0000 Hi Carsten, Thank you for your many answers to my comments. I believe to understand that you mean, that the probing rate does not apply= to messages that are resent as part as the CON resend mechanism. So only a= new message (with a new message ID) needs to observe the probing rate? What I mean is, when we send a 64 byte message, we need at least 64*PROBING= _RATE =3D 64 seconds between sending two messages *with different message i= ds*, for which no ACK or response is received? However, resending *the same= * message (as part of the CON resend mechanism) within this time is OK? Why is the probing rate dependent on the message size? Can't we just set a = fixed value for all messages? Best regards, Bert -----Original Message----- From: Carsten Bormann [mailto:cabo@tzi.org]=20 Sent: 21 December 2012 17:34 To: Bert Greevenbosch Cc: core@ietf.org WG Subject: BG7 -- PROBING_RATE (Re: [core] draft-ietf-core-coap-13 WGLC - my = comments) This may actually mainly be an editorial problem. On Dec 21, 2012, at 03:42, Bert Greevenbosch = wrote: > 7,T) p.25: "Unless this is modified by additional congestion control opti= mizations, it MUST be chosen in such a way that an endpoint does not exceed= an average data rate of PROBING_RATE in sending to another endpoint that d= oes not respond." You are quoting this out of context. The context is: In order not to cause congestion, Clients (including proxies) MUST strictly limit the number of simultaneous outstanding interactions that they maintain to a given server (including proxies) to NSTART. An outstanding interaction is either a CON for which an ACK has not yet been received but is still expected (message layer) or a request for which neither a response nor an Acknowledgment message has yet been received but is still expected (which may both occur at the same time, counting as one outstanding interaction). The default value of NSTART for this specification is 1. Now this is the text that explains how to handle non-responding peers: A client stops expecting a response to a Confirmable request for which no acknowledgment message was received, after EXCHANGE_LIFETIME. The specific algorithm by which a client stops to "expect" a response to a Confirmable request that was acknowledged, or to a Non-confirmable request, is not defined. Unless this is modified by additional congestion control optimizations, it MUST be chosen in such a way that an endpoint does not exceed an average data rate of PROBING_RATE in sending to another endpoint that does not respond. So: 1) If a Confirmable request times out, you reset the NSTART counter (for wh= ich we still need a name) to 0 after EXCHANGE_LIFETIME. 2) For Non-confirmables, we don't have a timeout. So we use PROBING_RATE t= o decay the NSTART counter. > p.26, in the table: "PROBING_RATE =3D 1 Byte/second". Yes, that is quite conservative. I had 7 bytes/second, but there was some = transport input that this might be too much. > p.21: "Retransmission is controlled by two things that a CoAP endpoint MU= ST keep track of for each Confirmable message it sends while waiting for an= acknowledgement (or reset): a timeout and a retransmission counter. For a = new Confirmable message, the initial timeout is set to a random counter bet= ween ACK_TIMEOUT and (ACK_TIMEOUT*ACK_RANDOM_FACTOR) (see Section 4.8), and= the retransmission counter is set to 0. When the timeout is triggered and = the retransmission counter is less than MAX_RETRANSMIT, the message is retr= ansmitted, the retransmission counter is incremented, and the timeout is do= ubled. If the retransmission counter reaches MAX_RETRANSMIT on a timeout, o= r if the endpoint receives a Reset message, then the attempt to transmit th= e message is canceled and the application process informed of failure." Well, this is unrelated; none of this is controlled by PROBING_RATE. > It seems that PROBING_RATE is another constraint on top of what is define= d on p.21, since the algorithm of p.21 alone would already violate the prob= ing rate, especially at the beginning of the retransmissions. This is the editorial issue: We need to make clear that these two don't int= eract. > Is 1 Byte/second reasonable? Does it mean that a 16 byte CoAP message nee= ds at least 16 seconds between two subsequent retransmissions? Over which t= ime frame is the PROBING_RATE calculated? Actually, there is a need for another clarification: The usage of PROBING_R= ATE needs to account for overhead. So, for a 16 byte CoAP message, you wou= ld account 16+8+40 =3D 64 bytes (IPv6), so, the next one goes out only afte= r 64 seconds or when the response is received, whatever comes earlier. > Suggestion: remove PROBING_RATE. PROBING_RATE is needed to keep some control over Non-confirmables. I don't= think we can take that away. If you never send a Non-confirmable, you can ignore PROBING_RATE. Gr=FC=DFe, Carsten