From k.pentikousis@huawei.com Mon Sep 3 09:42:41 2012 Return-Path: X-Original-To: decade@ietfa.amsl.com Delivered-To: decade@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 156EB21F86A2 for ; Mon, 3 Sep 2012 09:42:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.886 X-Spam-Level: X-Spam-Status: No, score=-3.886 tagged_above=-999 required=5 tests=[AWL=-0.113, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227] 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 WslYyQXrd84Y for ; Mon, 3 Sep 2012 09:42:40 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id E5BA021F8685 for ; Mon, 3 Sep 2012 09:42:39 -0700 (PDT) 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 AJH66976; Mon, 03 Sep 2012 16:42:36 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 3 Sep 2012 17:41:52 +0100 Received: from SZXEML420-HUB.china.huawei.com (10.82.67.159) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 3 Sep 2012 17:42:33 +0100 Received: from szxeml545-mbx.china.huawei.com ([169.254.1.98]) by szxeml420-hub.china.huawei.com ([10.82.67.159]) with mapi id 14.01.0323.003; Tue, 4 Sep 2012 00:42:31 +0800 From: Konstantinos Pentikousis To: "Rahman, Akbar" Thread-Topic: Review of draft-ietf-decade-reqs-08 Thread-Index: AQHNek8zSOtXNshZRkafaYo+6v08l5ddw0pwgBaNv4CABJpuYA== Date: Mon, 3 Sep 2012 16:42:30 +0000 Message-ID: <8D38716F0C1A444BA0CD7E96454366C23A4D82BF@szxeml545-mbx.china.huawei.com> References: <20120813195006.29392.94335.idtracker@ietfa.amsl.com> <8D38716F0C1A444BA0CD7E96454366C23A4C5095@szxeml545-mbs.china.huawei.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.37.56] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "decade@ietf.org" Subject: Re: [decade] Review of draft-ietf-decade-reqs-08 X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Sep 2012 16:42:41 -0000 SGkgQWtiYXIsDQoNCiAgfFRoYW5rcywgeW91ciBjb21tZW50cyBhbmQgYW5hbHlzaXMgYXJlIGFs d2F5cyB2ZXJ5IHRob3VnaHQgcHJvdm9raW5nIQ0KDQpUaGFuayB5b3UgZm9yIHlvdXIga2luZCB3 b3Jkcy4NCg0KPHNuaXA+DQoNCiAgfEluIGEgREVDQURFIHN5c3RlbSwgZWZmaWNpZW50IHN0b3Jh Z2UgYW5kIGRhdGEgdHJhbnNmZXIgb2Ygc21hbGwgZGF0YQ0KICB8b2JqZWN0cyBpcyByZXF1aXJl ZCBbNS4zXS4NCiAgfA0KICB8W0FLQkFSXSBBTkQgV0UgU0hPVUxEIEFERCBUSEUgUEhSQVNFICIu Li4gQU5EIERBVEEgVFJBTlNGRVIgT0YgTEFSR0UNCiAgfERBVEEgT0JKRUNUUyBJUyBBTFNPIElO SEVSRU5UTFkgU1VQUE9SVEVELiINCg0KU3VyZSwgSSBndWVzcyB0aGlzIGdvZXMgaW50byB0aGUg dGV4dCBvZiBbNS4zXSB0aGVuLg0KDQoNCiAgfFRoZSBkYXRhIHRyYW5zcG9ydCBwcm90b2NvbCBj YW4gYmUgbmVnb3RpYXRlZCBidXQgbXVzdCBiZSBzZWN1cmUgWzcuMSwNCiAgfDcuM10uDQogIHwN CiAgfA0KICB8W0FLQkFSXSBBTkQgSSBXT1VMRCBBREQgVFdPIE1PUkUgUE9JTlRTIEFQUExJQ0FC TEUgVE8gVEhFIE5FWFQNCiAgfFBBUkFHUkFQSDoNCiAgfC0gQUxMIENPTlRST0wgRlVOQ1RJT05T IEFSRSBBQ0NPTVBMSVNIRUQgVVNJTkcgVEhFIERFQ0FERSBSRVNPVVJDRQ0KICB8UFJPVE9DT0wg KERSUCkNCg0KSSB1bmRlcnN0YW5kIHdoYXQgeW91IGhhdmUgaW4gbWluZCwgYnV0IGl0IHdpbGwg YmUgYSBiaXQgc3RyYW5nZSB0byBwdXQsIGxldCBtZSBjYWxsIGl0LCBhICJmb3J3YXJkIHJlZmVy ZW5jZSIgdG8gYSBwcm90b2NvbCB0aGF0IGRvZXMgbm90IGV4aXN0LiBKdXN0IG15ICQwLjAyLg0K DQoNCiAgfFNlY3VyaXR5IGlzIGJhc2VkIG9uIGNyeXB0b2dyYXBoaWMgbWV0aG9kcyB3aGljaCBh bGxvdyBhIERFQ0FERQ0KICB8cHJvdmlkZXIgdG8gYWNjZXNzIHN5c3RlbSByZXNvdXJjZXMsIGRp c3RyaWJ1dGUgY29udGVudCB0byBjb250ZW50DQogIHxjb25zdW1lcnMgb2YgaXRzIGNob29zaW5n LCBldmVuIHdoZW4gb2ZmbGluZSwgdXNpbmcgKGlmIG5lZWRlZCkgZmluZS0NCiAgfGdyYWluZWQg YWNjZXNzIGNvbnRyb2wgcG9saWNpZXMgWzYuMiwgNi4zLCA2LjQsIDYuNSwgNi42LCA4LjIsIDgu M10uDQogIHxDbGllbnQgZGF0YSBvbiBhIHNlcnZlciBhcmUgYnkgZGVmYXVsdCBwcml2YXRlIFs2 LjddLiBJdCBpcyB0aGUgY2xpZW50DQogIHx0aGF0IGFsd2F5cyBkaXNjb3ZlcnMgYW5kIGluaXRp YXRlcyBhIGNvbm5lY3Rpb24gdG8gYSBzZXJ2ZXIgWzYuOCwNCiAgfDYuOV0sIG5vdCB2aWNlIHZl cnNhLiBEYXRhIG9iamVjdHMgY2FuIGJlIHdyaXR0ZW4gYnkgYSBwcm92aWRlciBpbiBvbmUNCiAg fGdvIG9yIHNldmVyYWwgcm91bmRzIGFuZCBjYW4gYmUgcmVhZCBieSBtdWx0aXBsZSBjb25zdW1l cnMNCiAgfHNpbXVsdGFuZW91c2x5IFs3LjIsIDcuNF0uIEV2ZXJ5IHByb3ZpZGVyIGlzIGdpdmVu IHRoZSBtZWFucyB0byBvYnRhaW4NCiAgfHJlc291cmNlIHVzYWdlIHN0YXRzIGFuZCBxdW90YXMg WzEwLjFdLiBPdmVyYWxsLCBhdHRhY2sgbWl0aWdhdGlvbiBpcw0KICB8YSBNVVNUIFs5LjVdIGFu ZCB0cmFuc3BvcnQgcmVkaXJlY3Rpb24gU0hPVUxEIGJlIHN1cHBvcnRlZCBbNy43XQ0KICB8DQog IHxbQUtCQVJdIElOIFRIRSBFWFBMQU5BVElPTiBZT1UgU1dJVENIIFRFUk1TIEJFVFdFRU4gIlBS T1ZJREVSIiBBTkQNCiAgfCJDTElFTlQiLiAgSVQgV09VTEQgQkUgQ0xFQVJFUiBJIFRISU5LIElG IFlPVSBTVFVDSyBUTyBKVVNUICJQUk9WSURFUiINCiAgfEFORCAiQ09OU1VNRVIiLg0KDQpXZWxs LCBJIGFncmVlIHRoYXQgYSBmZXcgdGVybXMgaW4gc2VjIDIuKiBoYXZlIHNvbWUgb3ZlcmxhcCBh bmQgcGVyaGFwcyBjb3VsZCBiZSBzaW1wbGlmaWVkIGEgYml0LCBidXQgSSB0cmllZCB0byBoYXZl IHRoZSBjaGVhdCBzaGVldCBzdW1tYXJ5IGFzIGNsb3NlIGFzIHBvc3NpYmxlIHRvIHRoZSBkZWZp bml0aW9ucyBpbiBTZWMgMi4qIGFuZCB0aGUgLXJlcXMgdGV4dC4gRm9yIGV4YW1wbGUsIGluIDYu NyAoY29weSBhbmQgcGFzdGUpOg0KDQpSRVFVSVJFTUVOVChTKTogVW5sZXNzIHJlYWQgb3Igd3Jp dGUgYWNjZXNzIGlzIGdyYW50ZWQgYnkgYSBQcm92aWRlciwgdGhlIGRlZmF1bHQgcGVybWlzc2lv biBNVVNUIGJlIG5vIGFjY2Vzcy4NClJBVElPTkFMRTogVGhpcyByZXF1aXJlbWVudCBpcyB0byBw cm90ZWN0IGNsaWVudCBwcml2YWN5IGJ5IGRlZmF1bHQuIA0KDQpJIGd1ZXNzIHRoYXQgbWVhbnMg cy9jbGllbnQvcHJvdmlkZXIgaW4gdGhlIHJhdGlvbmFsZSBwYXJ0LCBhbmQgdGhlIGNoZWF0IHNo ZWV0IHN1bW1hcnkgYmVjb21lcyAiUHJvdmlkZXIgZGF0YSBvbiBhIHNlcnZlciBhcmUgYnkgZGVm YXVsdCBwcml2YXRlIFs2LjddIg0KDQpPbiB0aGUgb3RoZXIgaGFuZCwgaW4gdGhlIHNlbnRlbmNl ICJJdCBpcyB0aGUgY2xpZW50Li4uIFs2LjgsIDYuOV0iLCAiY2xpZW50IiAoYXMgcGVyIHNlYy4g Mi4xKSBpcyB0aGUgcmlnaHQgdGVybSwgbm90ICJwcm92aWRlciIuDQoNCkJlc3QgcmVnYXJkcywN Cg0KS29zdGFzDQo= From wangdanhua@huawei.com Wed Sep 5 01:50:02 2012 Return-Path: X-Original-To: decade@ietfa.amsl.com Delivered-To: decade@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B557A21F8528 for ; Wed, 5 Sep 2012 01:50:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345] 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 GbQW+hAsxlcp for ; Wed, 5 Sep 2012 01:50:02 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 6C5FB21F84C9 for ; Wed, 5 Sep 2012 01:50:01 -0700 (PDT) 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 AKJ26392; Wed, 05 Sep 2012 08:49:56 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 5 Sep 2012 09:48:53 +0100 Received: from SZXEML403-HUB.china.huawei.com (10.82.67.35) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 5 Sep 2012 09:49:39 +0100 Received: from SZXEML507-MBS.china.huawei.com ([169.254.7.120]) by szxeml403-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.003; Wed, 5 Sep 2012 16:49:34 +0800 From: Wangdanhua To: "DECADE@ietf.org" Thread-Topic: =?gb2312?B?T3BlbiBJc3N1ZS0yIKOoZHJhZnQgIkFuIEhUVFAtYmFzZWQgREVDQURFIFJl?= =?gb2312?B?c291cmNlIFByb3RvY29sIqOpLg==?= Thread-Index: Ac2LQ14Nke+22TPoQViTkmz/bcyL0w== Date: Wed, 5 Sep 2012 08:49:33 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.177] Content-Type: multipart/alternative; boundary="_000_AFD688AF30E249418739DBDC55B9C75B34D7A07BSZXEML507MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [decade] =?gb2312?b?T3BlbiBJc3N1ZS0yIKOoZHJhZnQgIkFuIEhUVFAtYmFz?= =?gb2312?b?ZWQgREVDQURFIFJlc291cmNlIFByb3RvY29sIqOpLg==?= X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 08:50:02 -0000 --_000_AFD688AF30E249418739DBDC55B9C75B34D7A07BSZXEML507MBSchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgYWxsLA0KDQpUaGUgZm9sbG93aW5nIGlzIGFub3RoZXIgb3BlbiBpc3N1ZSBsZWZ0IGZvciCh sEFuIEhUVFAtYmFzZWQgREVDQURFIFJlc291cmNlIFByb3RvY29sobEgKGRyYWZ0LXdhbmctZHJw KS4gV2Whr3JlIGxvb2tpbmcgZm9yd2FyZCB0byB5b3VyIG9waW5pb25zIGFuZCBjb21tZW50cy4N Cg0KU2luY2UgSUVURiA4M3JkIGluIFBhaXJzLCB3ZSByZWNlaXZlZCBhIGxvdCBvZiBjb21tZW50 cyBvbiB0aGUgZGVmaW5pbmcgb2YgobBSRU1PVEVfR0VUX09iamVjdCBNZXNzYWdlobEgZnJvbSBX RyBhcyB3ZWxsIGFzIG1haWxpbmcgbGlzdCBkaXNjdXNzaW9uLiBUaGUgbWFpbiBpZGVhIGluY2x1 ZGVzIDEpIG5vdCBpbnRyb2R1Y2UgbmV3IEhUVFAgaGVhZGVycywgbGV0IGFsb25lIG5ldyBtZXNz YWdlIHR5cGVzOyAyKSBsZXZlcmFnZSB0aGUgYmFzZSBmdW5jdGlvbmFsaXR5IG9mIGEgobBub24t dHJhbnNwYXJlbnQgcHJveHmhsSBpbiBERUNBREUsIGxvY2FsIERFQ0FERSBTZXJ2ZXIgdG8gYWN0 IGFzIGEgbm9uLXRyYW5zcGFyZW50IHByb3h5IHdoZW4gcHJvY2Vzc2luZyBhIHJlcXVlc3QgZnJv bSBhIERFQ0FERSBDbGllbnQuIFdlIGFkb3B0ZWQgV0ehr3Mgc3VnZ2VzdGlvbiBhbmQgYWxyZWFk eSB1cGRhdGVkIHRoZSBkcmFmdCAoc2VlIKGwU2VjdGlvbiA4LiBSZW1vdGVfR2V0X09iamVjdCBN ZXNzYWdlobEgaW4gdGhlIGRyYWZ0KS4gV2UgbmVlZCBtb3JlIHJldmlldyBhbmQgY29tbWVudHMg dG8gc2VlIHdoZXRoZXIgd2UgY291bGQgbWFrZSBmdXJ0aGVyIGVmZm9ydC4NCg0KVGhhbmtzIQ0K DQpCZXN0IHdpc2hlcywNCkRhbmh1YQ0KDQo= --_000_AFD688AF30E249418739DBDC55B9C75B34D7A07BSZXEML507MBSchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi all,

 

The following is another open i= ssue left for =A1=B0An HTTP-based DECADE Resource Protocol=A1=B1 (draft-wan= g-drp). We=A1=AFre looking forward to your opinions and comments.

 

Since IETF 83rd in P= airs, we received a lot of comments on the defining of =A1=B0REMOTE_GET_Obj= ect Message=A1=B1 from WG as well as mailing list discussion. The main idea= includes 1) not introduce new HTTP headers, let alone new message types; 2) leverage the base functionality of a =A1=B0non= -transparent proxy=A1=B1 in DECADE, local DECADE Server to act as a non-tra= nsparent proxy when processing a request from a DECADE Client. We adopted W= G=A1=AFs suggestion and already updated the draft (see =A1=B0Section 8. Remote_Get_Object Message=A1=B1 in the draft). We ne= ed more review and comments to see whether we could make further effort.

 

Thanks!

 

Best wishes,<= /p>

Danhua

 

--_000_AFD688AF30E249418739DBDC55B9C75B34D7A07BSZXEML507MBSchi_-- From Martin.Stiemerling@neclab.eu Wed Sep 5 08:17:37 2012 Return-Path: X-Original-To: decade@ietfa.amsl.com Delivered-To: decade@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2D7D21F84E2 for ; Wed, 5 Sep 2012 08:17:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.16 X-Spam-Level: X-Spam-Status: No, score=-102.16 tagged_above=-999 required=5 tests=[AWL=0.211, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227, 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 eJ3a0HCVe8Gb for ; Wed, 5 Sep 2012 08:17:37 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id BD2B221F84CD for ; Wed, 5 Sep 2012 08:17:34 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 099C5101D0C for ; Wed, 5 Sep 2012 17:17:34 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n8gWrbREltfL for ; Wed, 5 Sep 2012 17:17:33 +0200 (CEST) Received: from ENCELADUS.office.hd (enceladus.office.hd [192.168.24.52]) by mailer1.neclab.eu (Postfix) with ESMTP id E3DC4101D0B for ; Wed, 5 Sep 2012 17:17:28 +0200 (CEST) Received: from [10.1.1.190] (10.1.1.190) by skoll.office.hd (192.168.125.11) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 5 Sep 2012 17:17:38 +0200 Message-ID: <50476D02.7030002@neclab.eu> Date: Wed, 5 Sep 2012 17:17:22 +0200 From: Martin Stiemerling User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0 MIME-Version: 1.0 To: References: <20120813195006.29392.94335.idtracker@ietfa.amsl.com> In-Reply-To: <20120813195006.29392.94335.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.1.1.190] Subject: Re: [decade] I-D Action: draft-ietf-decade-reqs-08.txt X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 15:17:37 -0000 Hi there, I am reading the -08 version of the requirements draft and do wonder if and how the apps area review comments of Dave Crocker have been addressed. Here is the link to his review: http://www.ietf.org/mail-archive/web/apps-discuss/current/msg04704.html Martin On 08/13/2012 09:50 PM, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Decoupled Application Data Enroute Working Group of the IETF. > > Title : DECADE Requirements > Author(s) : Yingjie Gu > David A. Bryan > Yang Richard Yang > Peng Zhang > Richard Alimi > Filename : draft-ietf-decade-reqs-08.txt > Pages : 21 > Date : 2012-08-13 > > Abstract: > The target of the DECoupled Application Data Enroute (DECADE) system > is to provide an open and standard in-network storage system for > applications, primarily P2P (peer-to-peer) applications, to store, > retrieve and manage their data. This draft enumerates and explains > requirements, not only for storage and retrieval, but also for data > management, access control and resource control, that should be > considered during the design and implementation of a DECADE- > compatible system. These are requirements on the entire system; some > of the requirements may eventually be implemented by an existing > protocol with/without some extensions (e.g., a protocol used to read > and write data from the storage system). The requirements in this > document are intended to ensure that a DECADE-compatible system > architecture includes all of the desired functionality for intended > applications. > > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-decade-reqs > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-decade-reqs-08 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-decade-reqs-08 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > -- martin.stiemerling@neclab.eu NEC Laboratories Europe - Network Research Division NEC Europe Limited Registered Office: NEC House, 1 Victoria Road, London W3 6BL Registered in England 283 From Akbar.Rahman@InterDigital.com Wed Sep 5 08:45:21 2012 Return-Path: X-Original-To: decade@ietfa.amsl.com Delivered-To: decade@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B028821F865E for ; Wed, 5 Sep 2012 08:45:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.372 X-Spam-Level: X-Spam-Status: No, score=-2.372 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227] 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 qRFMOi2AdwpE for ; Wed, 5 Sep 2012 08:45:21 -0700 (PDT) Received: from idcout.InterDigital.com (smtp-out1.interdigital.com [64.208.228.135]) by ietfa.amsl.com (Postfix) with ESMTP id 0FE3921F865D for ; Wed, 5 Sep 2012 08:45:20 -0700 (PDT) Received: from SAM.InterDigital.com ([10.30.2.11]) by idcout.InterDigital.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 5 Sep 2012 11:45:16 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Date: Wed, 5 Sep 2012 11:45:16 -0400 Message-ID: In-Reply-To: <50476D02.7030002@neclab.eu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [decade] I-D Action: draft-ietf-decade-reqs-08.txt Thread-Index: Ac2LeZ2R3IABLUbOQUKVrs2dndeupQAA5kGA References: <20120813195006.29392.94335.idtracker@ietfa.amsl.com> <50476D02.7030002@neclab.eu> From: "Rahman, Akbar" To: "Martin Stiemerling" X-OriginalArrivalTime: 05 Sep 2012 15:45:16.0530 (UTC) FILETIME=[721D2D20:01CD8B7D] Cc: decade@ietf.org Subject: Re: [decade] I-D Action: draft-ietf-decade-reqs-08.txt X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 15:45:21 -0000 SGkgTWFydGluLA0KDQoNCk5vbWluYWxseSBhbGwgdGhlIGNvbW1lbnRzIGZyb20gRGF2ZSBDcm9j a2VyIHdlcmUgYWRkcmVzc2VkIGJ5IHRoZSAtMDYgdG8gLTA4IHZlcnNpb25zIG9mIHRoZSBSZXF1 aXJlbWVudHMgZHJhZnRzLiAgRGlkIHlvdSBub3RpY2UgYW55IHNwZWNpZmljIGlzc3VlcyB0aGF0 IHlvdSBmZWx0IHdlcmUgbm90IGFkZHJlc3NlZD8NCg0KDQoNCi9Ba2JhciAoYXMgRG9jdW1lbnQg U2hlcGhlcmQpDQoNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogZGVjYWRl LWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpkZWNhZGUtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVo YWxmIE9mIE1hcnRpbiBTdGllbWVybGluZw0KU2VudDogV2VkbmVzZGF5LCBTZXB0ZW1iZXIgMDUs IDIwMTIgMTE6MTcgQU0NClRvOiBkZWNhZGVAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbZGVjYWRl XSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLWRlY2FkZS1yZXFzLTA4LnR4dA0KDQpIaSB0aGVyZSwN Cg0KSSBhbSByZWFkaW5nIHRoZSAtMDggdmVyc2lvbiBvZiB0aGUgcmVxdWlyZW1lbnRzIGRyYWZ0 IGFuZCBkbyB3b25kZXIgaWYgDQphbmQgaG93IHRoZSBhcHBzIGFyZWEgcmV2aWV3IGNvbW1lbnRz IG9mIERhdmUgQ3JvY2tlciBoYXZlIGJlZW4gYWRkcmVzc2VkLg0KDQpIZXJlIGlzIHRoZSBsaW5r IHRvIGhpcyByZXZpZXc6DQpodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvYXBw cy1kaXNjdXNzL2N1cnJlbnQvbXNnMDQ3MDQuaHRtbA0KDQogICBNYXJ0aW4NCg0KT24gMDgvMTMv MjAxMiAwOTo1MCBQTSwgaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIHdyb3RlOg0KPg0KPiBBIE5l dyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0aGUgb24tbGluZSBJbnRlcm5ldC1E cmFmdHMgZGlyZWN0b3JpZXMuDQo+ICAgVGhpcyBkcmFmdCBpcyBhIHdvcmsgaXRlbSBvZiB0aGUg RGVjb3VwbGVkIEFwcGxpY2F0aW9uIERhdGEgRW5yb3V0ZSBXb3JraW5nIEdyb3VwIG9mIHRoZSBJ RVRGLg0KPg0KPiAJVGl0bGUgICAgICAgICAgIDogREVDQURFIFJlcXVpcmVtZW50cw0KPiAJQXV0 aG9yKHMpICAgICAgIDogWWluZ2ppZSBHdQ0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgICBE YXZpZCBBLiBCcnlhbg0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgICBZYW5nIFJpY2hhcmQg WWFuZw0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgICBQZW5nIFpoYW5nDQo+ICAgICAgICAg ICAgICAgICAgICAgICAgICAgIFJpY2hhcmQgQWxpbWkNCj4gCUZpbGVuYW1lICAgICAgICA6IGRy YWZ0LWlldGYtZGVjYWRlLXJlcXMtMDgudHh0DQo+IAlQYWdlcyAgICAgICAgICAgOiAyMQ0KPiAJ RGF0ZSAgICAgICAgICAgIDogMjAxMi0wOC0xMw0KPg0KPiBBYnN0cmFjdDoNCj4gICAgIFRoZSB0 YXJnZXQgb2YgdGhlIERFQ291cGxlZCBBcHBsaWNhdGlvbiBEYXRhIEVucm91dGUgKERFQ0FERSkg c3lzdGVtDQo+ICAgICBpcyB0byBwcm92aWRlIGFuIG9wZW4gYW5kIHN0YW5kYXJkIGluLW5ldHdv cmsgc3RvcmFnZSBzeXN0ZW0gZm9yDQo+ICAgICBhcHBsaWNhdGlvbnMsIHByaW1hcmlseSBQMlAg KHBlZXItdG8tcGVlcikgYXBwbGljYXRpb25zLCB0byBzdG9yZSwNCj4gICAgIHJldHJpZXZlIGFu ZCBtYW5hZ2UgdGhlaXIgZGF0YS4gIFRoaXMgZHJhZnQgZW51bWVyYXRlcyBhbmQgZXhwbGFpbnMN Cj4gICAgIHJlcXVpcmVtZW50cywgbm90IG9ubHkgZm9yIHN0b3JhZ2UgYW5kIHJldHJpZXZhbCwg YnV0IGFsc28gZm9yIGRhdGENCj4gICAgIG1hbmFnZW1lbnQsIGFjY2VzcyBjb250cm9sIGFuZCBy ZXNvdXJjZSBjb250cm9sLCB0aGF0IHNob3VsZCBiZQ0KPiAgICAgY29uc2lkZXJlZCBkdXJpbmcg dGhlIGRlc2lnbiBhbmQgaW1wbGVtZW50YXRpb24gb2YgYSBERUNBREUtDQo+ICAgICBjb21wYXRp YmxlIHN5c3RlbS4gIFRoZXNlIGFyZSByZXF1aXJlbWVudHMgb24gdGhlIGVudGlyZSBzeXN0ZW07 IHNvbWUNCj4gICAgIG9mIHRoZSByZXF1aXJlbWVudHMgbWF5IGV2ZW50dWFsbHkgYmUgaW1wbGVt ZW50ZWQgYnkgYW4gZXhpc3RpbmcNCj4gICAgIHByb3RvY29sIHdpdGgvd2l0aG91dCBzb21lIGV4 dGVuc2lvbnMgKGUuZy4sIGEgcHJvdG9jb2wgdXNlZCB0byByZWFkDQo+ICAgICBhbmQgd3JpdGUg ZGF0YSBmcm9tIHRoZSBzdG9yYWdlIHN5c3RlbSkuICBUaGUgcmVxdWlyZW1lbnRzIGluIHRoaXMN Cj4gICAgIGRvY3VtZW50IGFyZSBpbnRlbmRlZCB0byBlbnN1cmUgdGhhdCBhIERFQ0FERS1jb21w YXRpYmxlIHN5c3RlbQ0KPiAgICAgYXJjaGl0ZWN0dXJlIGluY2x1ZGVzIGFsbCBvZiB0aGUgZGVz aXJlZCBmdW5jdGlvbmFsaXR5IGZvciBpbnRlbmRlZA0KPiAgICAgYXBwbGljYXRpb25zLg0KPg0K Pg0KPg0KPiBUaGUgSUVURiBkYXRhdHJhY2tlciBzdGF0dXMgcGFnZSBmb3IgdGhpcyBkcmFmdCBp czoNCj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1kZWNhZGUt cmVxcw0KPg0KPiBUaGVyZSdzIGFsc28gYSBodG1saXplZCB2ZXJzaW9uIGF2YWlsYWJsZSBhdDoN Cj4gaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1kZWNhZGUtcmVxcy0wOA0K Pg0KPiBBIGRpZmYgZnJvbSB0aGUgcHJldmlvdXMgdmVyc2lvbiBpcyBhdmFpbGFibGUgYXQ6DQo+ IGh0dHA6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtZGVjYWRlLXJlcXMt MDgNCj4NCj4NCj4gSW50ZXJuZXQtRHJhZnRzIGFyZSBhbHNvIGF2YWlsYWJsZSBieSBhbm9ueW1v dXMgRlRQIGF0Og0KPiBmdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLw0KPg0KDQot LSANCm1hcnRpbi5zdGllbWVybGluZ0BuZWNsYWIuZXUNCg0KTkVDIExhYm9yYXRvcmllcyBFdXJv cGUgLSBOZXR3b3JrIFJlc2VhcmNoIERpdmlzaW9uIE5FQyBFdXJvcGUgTGltaXRlZA0KUmVnaXN0 ZXJlZCBPZmZpY2U6IE5FQyBIb3VzZSwgMSBWaWN0b3JpYSBSb2FkLCBMb25kb24gVzMgNkJMDQpS ZWdpc3RlcmVkIGluIEVuZ2xhbmQgMjgzDQo= From haibin.song@huawei.com Thu Sep 6 23:18:42 2012 Return-Path: X-Original-To: decade@ietfa.amsl.com Delivered-To: decade@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC3B221F86A8 for ; Thu, 6 Sep 2012 23:18:42 -0700 (PDT) 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 T0Ix63FLknEV for ; Thu, 6 Sep 2012 23:18:42 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id C008021F8686 for ; Thu, 6 Sep 2012 23:18:41 -0700 (PDT) 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 AKK96401; Fri, 07 Sep 2012 06:18:40 +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; Fri, 7 Sep 2012 07:17:47 +0100 Received: from SZXEML416-HUB.china.huawei.com (10.82.67.155) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 7 Sep 2012 07:18:37 +0100 Received: from SZXEML534-MBX.china.huawei.com ([169.254.2.70]) by szxeml416-hub.china.huawei.com ([10.82.67.155]) with mapi id 14.01.0323.003; Fri, 7 Sep 2012 14:18:19 +0800 From: Songhaibin To: "decade@ietf.org" Thread-Topic: Help the NomCom: Nominations and Feedback Thread-Index: AQHNi8WUFFcI2/gEFE2qWaqCh3Rd8pd+aY6Q Date: Fri, 7 Sep 2012 06:18:19 +0000 Message-ID: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.123] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [decade] FW: Help the NomCom: Nominations and Feedback X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 06:18:42 -0000 DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogd2djaGFpcnMtYm91bmNl c0BpZXRmLm9yZyBbbWFpbHRvOndnY2hhaXJzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZg0K PiBPZiBOb21Db20gQ2hhaXINCj4gU2VudDogVGh1cnNkYXksIFNlcHRlbWJlciAwNiwgMjAxMiA4 OjIxIEFNDQo+IFRvOiBXb3JraW5nIEdyb3VwIENoYWlycw0KPiBTdWJqZWN0OiBIZWxwIHRoZSBO b21Db206IE5vbWluYXRpb25zIGFuZCBGZWVkYmFjaw0KPiANCj4gVGhlIElFVEYgTm9taW5hdGlv bnMgQ29tbWl0dGVlIChOb21Db20pIGlzIGN1cnJlbnRseSBzZWVraW5nDQo+IG5vbWluYXRpb25z IGZvciBpbmRpdmlkdWFscyB0byBzZXJ2ZSBvbiB0aGUgSUVTRywgSUFCLCBhbmQgSUFPQy4NCj4g QWRkaXRpb25hbGx5LCB0aGlzIGlzIGFuIGFubm91bmNlbWVudCB0aGF0IHRoZSBOb21Db20gaXMg c2Vla2luZw0KPiBmZWVkYmFjayBvbiBpbmRpdmlkdWFscyB3aG8gaGF2ZSBhY2NlcHRlZCBub21p bmF0aW9ucyBmb3IgSUVURg0KPiBsZWFkZXJzaGlwIHBvc2l0aW9ucy4NCj4gDQo+IEl0IGlzIHZl cnkgaW1wb3J0YW50IHRvIHRoZSBOb21Db20gcHJvY2VzcyB0aGF0IHdlIGdldCBpbnB1dCBmcm9t IGENCj4gYnJvYWQgc3BlY3RydW0gb2YgdGhlIGNvbW11bml0eS4gVGhlcmVmb3JlLCBpbiBjYXNl IG1lbWJlcnMgb2YgeW91cg0KPiB3b3JraW5nIGdyb3VwIGRvIG5vdCByZWFkIHRoZSBJRVRGIGFu bm91bmNlbWVudCBhbmQgZGlzY3Vzc2lvbiBsaXN0cywNCj4gdGhlIE5vbUNvbSB3b3VsZCBhcHBy ZWNpYXRlIHlvdXIgaGVscCBpbiBkaXNzZW1pbmF0aW5nIHRoZSBmb2xsb3dpbmcNCj4gaW5mb3Jt YXRpb24uDQo+IA0KPiBUaGUgTm9tQ29tIHdlYnNpdGUgY29udGFpbnMgaW5mb3JtYXRpb24gYWJv dXQgdGhpcyB5ZWFyJ3MgTm9tQ29tDQo+IGluY2x1ZGluZyB0aGUgcG9zaXRpb25zIHdlIGFyZSBz ZWVraW5nIHRvIGZpbGwsIGFuZCB0aGUgcXVhbGlmaWNhdGlvbnMNCj4gcmVxdWlyZWQgZm9yIHRo ZXNlIHBvc2l0aW9uczoNCj4gDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL2dyb3VwL25vbWNvbS8y MDEyLw0KPiANCj4gVGhlIE5vbUNvbSBpcyBhY2NlcHRpbmcgbm9taW5hdGlvbnMgdW50aWwgU2Vw dGVtYmVyIDI0LiBOb21pbmF0aW9ucw0KPiBmb3IgYW55IHBvc2l0aW9uIGNhbiBiZSBtYWRlIHVz aW5nIHRoZSBmb2xsb3dpbmcgd2ViIHRvb2w6DQo+IA0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9n cm91cC9ub21jb20vMjAxMi9ub21pbmF0ZQ0KPiANCj4gRmVlZGJhY2sgYWJvdXQgaW5kaXZpZHVh bHMgd2hvIHRoZSBOb21Db20gaXMgY29uc2lkZXJpbmcgY2FuIGJlDQo+IHByb3ZpZGluZyB1c2lu ZyB0aGUgZm9sbG93aW5nIHdlYiB0b29sOg0KPiANCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvZ3Jv dXAvbm9tY29tLzIwMTIvaW5wdXQNCj4gDQo+IFRoZSBmZWVkYmFjayB0b29sIHByb3ZpZGVzIGEg bGlzdCBvZiBpbmRpdmlkdWFscyB3aG8gaGF2ZSBhZ3JlZWQgdG8gYmUNCj4gY29uc2lkZXJlZCBm b3IgZWFjaCBwb3NpdGlvbi4gV2Ugd2lsbCBiZSB1cGRhdGluZyB0aGlzIGxpc3QgaW4gdGhlIGNv bWluZw0KPiB3ZWVrcyBhcyBtb3JlIGluZGl2aWR1YWxzIGFjY2VwdCBub21pbmF0aW9ucy4NCj4g DQo+IEZlZWRiYWNrIHByb3ZpZGVkIHRvIHRoZSBOb21Db20gaXMga2VwdCBzdHJpY3RseSBjb25m aWRlbnRpYWwhDQo+IA0KPiBOb3RlIHRoYXQgdXNlIG9mIHRoZSBOb21Db20gd2ViIHRvb2xzIHJl cXVpcmUgYW4gaWV0Zi5vcmcgKGkuZS4sDQo+IGRhdGF0cmFja2VyKSBhY2NvdW50LiBZb3UgY2Fu IGNyZWF0ZSBhbiBpZXRmLm9yZyBhY2NvdW50IGJ5IHZpc2l0aW5nIHRoZQ0KPiBmb2xsb3dpbmcg VVJMOg0KPiANCj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9hY2NvdW50cy9jcmVhdGUv DQo+IA0KPiBBcyBhbiBhbHRlcm5hdGl2ZSB0byB1c2luZyB0aGUgd2ViIHRvb2xzLCAgeW91IGNh biBzZW5kIGVtYWlsIHRvIHRoZQ0KPiBOb21Db20gYXQgbm9tY29tMTJAaWV0Zi5vcmcgdG8gbWFr ZSBhIG5vbWluYXRpb24gb3IgcHJvdmlkZSBpbnB1dCB0bw0KPiB0aGUgY29tbWl0dGVlLg0KPiAN Cj4gVGhhbmsgeW91IGZvciB5b3VyIGhlbHAsDQo+IC0gTWF0dCBMZXBpbnNraQ0KPiAgIG5vbWNv bS1jaGFpckBpZXRmLm9yZw0K From Martin.Stiemerling@neclab.eu Fri Sep 7 03:17:38 2012 Return-Path: X-Original-To: decade@ietfa.amsl.com Delivered-To: decade@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D9ED21F84DA for ; Fri, 7 Sep 2012 03:17:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.309 X-Spam-Level: X-Spam-Status: No, score=-102.309 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227, 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 MfXFYn17kwpF for ; Fri, 7 Sep 2012 03:17:37 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 5238D21F8487 for ; Fri, 7 Sep 2012 03:17:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id B3DDD101D20; Fri, 7 Sep 2012 12:17:35 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8c-aYirLt3HJ; Fri, 7 Sep 2012 12:17:35 +0200 (CEST) Received: from METHONE.office.hd (methone.office.hd [192.168.24.54]) by mailer1.neclab.eu (Postfix) with ESMTP id 92823101C79; Fri, 7 Sep 2012 12:17:25 +0200 (CEST) Received: from [10.7.0.105] (10.7.0.105) by skoll.office.hd (192.168.125.11) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 7 Sep 2012 12:17:25 +0200 Message-ID: <5049C9B4.9080106@neclab.eu> Date: Fri, 7 Sep 2012 12:17:24 +0200 From: Martin Stiemerling User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0 MIME-Version: 1.0 To: "Rahman, Akbar" References: <20120813195006.29392.94335.idtracker@ietfa.amsl.com> <50476D02.7030002@neclab.eu> In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.7.0.105] Cc: decade@ietf.org Subject: Re: [decade] I-D Action: draft-ietf-decade-reqs-08.txt X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 10:17:38 -0000 Akbar, I cannot link his comments and the changes. It would be good to get this documented by email, e.g., a change list. He had a number of comments and would be really good to answer to him, to show what has happened with his comments. Thanks, Martin On 09/05/2012 05:45 PM, Rahman, Akbar wrote: > Hi Martin, > > > Nominally all the comments from Dave Crocker were addressed by the -06 to -08 versions of the Requirements drafts. Did you notice any specific issues that you felt were not addressed? > > > > /Akbar (as Document Shepherd) > > > > -----Original Message----- > From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.org] On Behalf Of Martin Stiemerling > Sent: Wednesday, September 05, 2012 11:17 AM > To: decade@ietf.org > Subject: Re: [decade] I-D Action: draft-ietf-decade-reqs-08.txt > > Hi there, > > I am reading the -08 version of the requirements draft and do wonder if > and how the apps area review comments of Dave Crocker have been addressed. > > Here is the link to his review: > http://www.ietf.org/mail-archive/web/apps-discuss/current/msg04704.html > > Martin > > On 08/13/2012 09:50 PM, internet-drafts@ietf.org wrote: >> >> A New Internet-Draft is available from the on-line Internet-Drafts directories. >> This draft is a work item of the Decoupled Application Data Enroute Working Group of the IETF. >> >> Title : DECADE Requirements >> Author(s) : Yingjie Gu >> David A. Bryan >> Yang Richard Yang >> Peng Zhang >> Richard Alimi >> Filename : draft-ietf-decade-reqs-08.txt >> Pages : 21 >> Date : 2012-08-13 >> >> Abstract: >> The target of the DECoupled Application Data Enroute (DECADE) system >> is to provide an open and standard in-network storage system for >> applications, primarily P2P (peer-to-peer) applications, to store, >> retrieve and manage their data. This draft enumerates and explains >> requirements, not only for storage and retrieval, but also for data >> management, access control and resource control, that should be >> considered during the design and implementation of a DECADE- >> compatible system. These are requirements on the entire system; some >> of the requirements may eventually be implemented by an existing >> protocol with/without some extensions (e.g., a protocol used to read >> and write data from the storage system). The requirements in this >> document are intended to ensure that a DECADE-compatible system >> architecture includes all of the desired functionality for intended >> applications. >> >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-decade-reqs >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-decade-reqs-08 >> >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=draft-ietf-decade-reqs-08 >> >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> > -- martin.stiemerling@neclab.eu NEC Laboratories Europe - Network Research Division NEC Europe Limited Registered Office: NEC House, 1 Victoria Road, London W3 6BL Registered in England 283 From Akbar.Rahman@InterDigital.com Fri Sep 7 08:40:55 2012 Return-Path: X-Original-To: decade@ietfa.amsl.com Delivered-To: decade@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CDF921F855A for ; Fri, 7 Sep 2012 08:40:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.372 X-Spam-Level: X-Spam-Status: No, score=-2.372 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227] 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 p5FDmNaKS18I for ; Fri, 7 Sep 2012 08:40:54 -0700 (PDT) Received: from idcout.InterDigital.com (smtp-out1.interdigital.com [64.208.228.135]) by ietfa.amsl.com (Postfix) with ESMTP id 64C4521F8688 for ; Fri, 7 Sep 2012 08:40:54 -0700 (PDT) Received: from SAM.InterDigital.com ([10.30.2.11]) by idcout.InterDigital.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 7 Sep 2012 11:40:53 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Date: Fri, 7 Sep 2012 11:40:53 -0400 Message-ID: In-Reply-To: <5049C9B4.9080106@neclab.eu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [decade] I-D Action: draft-ietf-decade-reqs-08.txt Thread-Index: Ac2M4gHipzXlaZafQd+X8SXptnNwmQALPOOg References: <20120813195006.29392.94335.idtracker@ietfa.amsl.com> <50476D02.7030002@neclab.eu> <5049C9B4.9080106@neclab.eu> From: "Rahman, Akbar" To: "Martin Stiemerling" X-OriginalArrivalTime: 07 Sep 2012 15:40:53.0230 (UTC) FILETIME=[2A0048E0:01CD8D0F] Cc: decade@ietf.org Subject: Re: [decade] I-D Action: draft-ietf-decade-reqs-08.txt X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 15:40:55 -0000 SGkgTWFydGluLA0KDQoNCk9rYXkuICBJIGhhdmUgc3VnZ2VzdGVkIHRvIHRoZSBhdXRob3JzIHRv IG1ha2UgdGhpcyBjaGFuZ2UgbGlzdCBhcyBwYXJ0IG9mIHRoZWlyIHBsYW4gdG8gYWRkcmVzcyB0 aGUgb3V0c3RhbmRpbmcgY29tbWVudHMgb24gdGhlIFJlcXVpcmVtZW50cyBkb2N1bWVudC4NCg0K DQoNCi9Ba2JhciAoYXMgRG9jdW1lbnQgU2hlcGhlcmQpDQoNCg0KDQotLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KRnJvbTogTWFydGluIFN0aWVtZXJsaW5nIFttYWlsdG86bWFydGluLnN0aWVt ZXJsaW5nQG5lY2xhYi5ldV0gDQpTZW50OiBGcmlkYXksIFNlcHRlbWJlciAwNywgMjAxMiA2OjE3 IEFNDQpUbzogUmFobWFuLCBBa2Jhcg0KQ2M6IGRlY2FkZUBpZXRmLm9yZw0KU3ViamVjdDogUmU6 IFtkZWNhZGVdIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtZGVjYWRlLXJlcXMtMDgudHh0DQoNCkFr YmFyLA0KDQpJIGNhbm5vdCBsaW5rIGhpcyBjb21tZW50cyBhbmQgdGhlIGNoYW5nZXMuIEl0IHdv dWxkIGJlIGdvb2QgdG8gZ2V0IHRoaXMgDQpkb2N1bWVudGVkIGJ5IGVtYWlsLCBlLmcuLCBhIGNo YW5nZSBsaXN0Lg0KDQpIZSBoYWQgYSBudW1iZXIgb2YgY29tbWVudHMgYW5kIHdvdWxkIGJlIHJl YWxseSBnb29kIHRvIGFuc3dlciB0byBoaW0sIA0KdG8gc2hvdyB3aGF0IGhhcyBoYXBwZW5lZCB3 aXRoIGhpcyBjb21tZW50cy4NCg0KVGhhbmtzLA0KDQogIE1hcnRpbg0KDQpPbiAwOS8wNS8yMDEy IDA1OjQ1IFBNLCBSYWhtYW4sIEFrYmFyIHdyb3RlOg0KPiBIaSBNYXJ0aW4sDQo+DQo+DQo+IE5v bWluYWxseSBhbGwgdGhlIGNvbW1lbnRzIGZyb20gRGF2ZSBDcm9ja2VyIHdlcmUgYWRkcmVzc2Vk IGJ5IHRoZSAtMDYgdG8gLTA4IHZlcnNpb25zIG9mIHRoZSBSZXF1aXJlbWVudHMgZHJhZnRzLiAg RGlkIHlvdSBub3RpY2UgYW55IHNwZWNpZmljIGlzc3VlcyB0aGF0IHlvdSBmZWx0IHdlcmUgbm90 IGFkZHJlc3NlZD8NCj4NCj4NCj4NCj4gL0FrYmFyIChhcyBEb2N1bWVudCBTaGVwaGVyZCkNCj4N Cj4NCj4NCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogZGVjYWRlLWJvdW5j ZXNAaWV0Zi5vcmcgW21haWx0bzpkZWNhZGUtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9m IE1hcnRpbiBTdGllbWVybGluZw0KPiBTZW50OiBXZWRuZXNkYXksIFNlcHRlbWJlciAwNSwgMjAx MiAxMToxNyBBTQ0KPiBUbzogZGVjYWRlQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbZGVjYWRl XSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLWRlY2FkZS1yZXFzLTA4LnR4dA0KPg0KPiBIaSB0aGVy ZSwNCj4NCj4gSSBhbSByZWFkaW5nIHRoZSAtMDggdmVyc2lvbiBvZiB0aGUgcmVxdWlyZW1lbnRz IGRyYWZ0IGFuZCBkbyB3b25kZXIgaWYNCj4gYW5kIGhvdyB0aGUgYXBwcyBhcmVhIHJldmlldyBj b21tZW50cyBvZiBEYXZlIENyb2NrZXIgaGF2ZSBiZWVuIGFkZHJlc3NlZC4NCj4NCj4gSGVyZSBp cyB0aGUgbGluayB0byBoaXMgcmV2aWV3Og0KPiBodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJj aGl2ZS93ZWIvYXBwcy1kaXNjdXNzL2N1cnJlbnQvbXNnMDQ3MDQuaHRtbA0KPg0KPiAgICAgTWFy dGluDQo+DQo+IE9uIDA4LzEzLzIwMTIgMDk6NTAgUE0sIGludGVybmV0LWRyYWZ0c0BpZXRmLm9y ZyB3cm90ZToNCj4+DQo+PiBBIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0 aGUgb24tbGluZSBJbnRlcm5ldC1EcmFmdHMgZGlyZWN0b3JpZXMuDQo+PiAgICBUaGlzIGRyYWZ0 IGlzIGEgd29yayBpdGVtIG9mIHRoZSBEZWNvdXBsZWQgQXBwbGljYXRpb24gRGF0YSBFbnJvdXRl IFdvcmtpbmcgR3JvdXAgb2YgdGhlIElFVEYuDQo+Pg0KPj4gCVRpdGxlICAgICAgICAgICA6IERF Q0FERSBSZXF1aXJlbWVudHMNCj4+IAlBdXRob3IocykgICAgICAgOiBZaW5namllIEd1DQo+PiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgRGF2aWQgQS4gQnJ5YW4NCj4+ICAgICAgICAgICAg ICAgICAgICAgICAgICAgICBZYW5nIFJpY2hhcmQgWWFuZw0KPj4gICAgICAgICAgICAgICAgICAg ICAgICAgICAgIFBlbmcgWmhhbmcNCj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBSaWNo YXJkIEFsaW1pDQo+PiAJRmlsZW5hbWUgICAgICAgIDogZHJhZnQtaWV0Zi1kZWNhZGUtcmVxcy0w OC50eHQNCj4+IAlQYWdlcyAgICAgICAgICAgOiAyMQ0KPj4gCURhdGUgICAgICAgICAgICA6IDIw MTItMDgtMTMNCj4+DQo+PiBBYnN0cmFjdDoNCj4+ICAgICAgVGhlIHRhcmdldCBvZiB0aGUgREVD b3VwbGVkIEFwcGxpY2F0aW9uIERhdGEgRW5yb3V0ZSAoREVDQURFKSBzeXN0ZW0NCj4+ICAgICAg aXMgdG8gcHJvdmlkZSBhbiBvcGVuIGFuZCBzdGFuZGFyZCBpbi1uZXR3b3JrIHN0b3JhZ2Ugc3lz dGVtIGZvcg0KPj4gICAgICBhcHBsaWNhdGlvbnMsIHByaW1hcmlseSBQMlAgKHBlZXItdG8tcGVl cikgYXBwbGljYXRpb25zLCB0byBzdG9yZSwNCj4+ICAgICAgcmV0cmlldmUgYW5kIG1hbmFnZSB0 aGVpciBkYXRhLiAgVGhpcyBkcmFmdCBlbnVtZXJhdGVzIGFuZCBleHBsYWlucw0KPj4gICAgICBy ZXF1aXJlbWVudHMsIG5vdCBvbmx5IGZvciBzdG9yYWdlIGFuZCByZXRyaWV2YWwsIGJ1dCBhbHNv IGZvciBkYXRhDQo+PiAgICAgIG1hbmFnZW1lbnQsIGFjY2VzcyBjb250cm9sIGFuZCByZXNvdXJj ZSBjb250cm9sLCB0aGF0IHNob3VsZCBiZQ0KPj4gICAgICBjb25zaWRlcmVkIGR1cmluZyB0aGUg ZGVzaWduIGFuZCBpbXBsZW1lbnRhdGlvbiBvZiBhIERFQ0FERS0NCj4+ICAgICAgY29tcGF0aWJs ZSBzeXN0ZW0uICBUaGVzZSBhcmUgcmVxdWlyZW1lbnRzIG9uIHRoZSBlbnRpcmUgc3lzdGVtOyBz b21lDQo+PiAgICAgIG9mIHRoZSByZXF1aXJlbWVudHMgbWF5IGV2ZW50dWFsbHkgYmUgaW1wbGVt ZW50ZWQgYnkgYW4gZXhpc3RpbmcNCj4+ICAgICAgcHJvdG9jb2wgd2l0aC93aXRob3V0IHNvbWUg ZXh0ZW5zaW9ucyAoZS5nLiwgYSBwcm90b2NvbCB1c2VkIHRvIHJlYWQNCj4+ICAgICAgYW5kIHdy aXRlIGRhdGEgZnJvbSB0aGUgc3RvcmFnZSBzeXN0ZW0pLiAgVGhlIHJlcXVpcmVtZW50cyBpbiB0 aGlzDQo+PiAgICAgIGRvY3VtZW50IGFyZSBpbnRlbmRlZCB0byBlbnN1cmUgdGhhdCBhIERFQ0FE RS1jb21wYXRpYmxlIHN5c3RlbQ0KPj4gICAgICBhcmNoaXRlY3R1cmUgaW5jbHVkZXMgYWxsIG9m IHRoZSBkZXNpcmVkIGZ1bmN0aW9uYWxpdHkgZm9yIGludGVuZGVkDQo+PiAgICAgIGFwcGxpY2F0 aW9ucy4NCj4+DQo+Pg0KPj4NCj4+IFRoZSBJRVRGIGRhdGF0cmFja2VyIHN0YXR1cyBwYWdlIGZv ciB0aGlzIGRyYWZ0IGlzOg0KPj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJh ZnQtaWV0Zi1kZWNhZGUtcmVxcw0KPj4NCj4+IFRoZXJlJ3MgYWxzbyBhIGh0bWxpemVkIHZlcnNp b24gYXZhaWxhYmxlIGF0Og0KPj4gaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0 Zi1kZWNhZGUtcmVxcy0wOA0KPj4NCj4+IEEgZGlmZiBmcm9tIHRoZSBwcmV2aW91cyB2ZXJzaW9u IGlzIGF2YWlsYWJsZSBhdDoNCj4+IGh0dHA6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRy YWZ0LWlldGYtZGVjYWRlLXJlcXMtMDgNCj4+DQo+Pg0KPj4gSW50ZXJuZXQtRHJhZnRzIGFyZSBh bHNvIGF2YWlsYWJsZSBieSBhbm9ueW1vdXMgRlRQIGF0Og0KPj4gZnRwOi8vZnRwLmlldGYub3Jn L2ludGVybmV0LWRyYWZ0cy8NCj4+DQo+DQoNCi0tIA0KbWFydGluLnN0aWVtZXJsaW5nQG5lY2xh Yi5ldQ0KDQpORUMgTGFib3JhdG9yaWVzIEV1cm9wZSAtIE5ldHdvcmsgUmVzZWFyY2ggRGl2aXNp b24gTkVDIEV1cm9wZSBMaW1pdGVkDQpSZWdpc3RlcmVkIE9mZmljZTogTkVDIEhvdXNlLCAxIFZp Y3RvcmlhIFJvYWQsIExvbmRvbiBXMyA2QkwNClJlZ2lzdGVyZWQgaW4gRW5nbGFuZCAyODMNCg== From haibin.song@huawei.com Mon Sep 10 00:19:44 2012 Return-Path: X-Original-To: decade@ietfa.amsl.com Delivered-To: decade@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB84721F84CF for ; Mon, 10 Sep 2012 00:19:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.3 X-Spam-Level: X-Spam-Status: No, score=-3.3 tagged_above=-999 required=5 tests=[AWL=-3.300, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345] 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 zuri5WykDDHk for ; Mon, 10 Sep 2012 00:19:44 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 90C8F21F846E for ; Mon, 10 Sep 2012 00:19:43 -0700 (PDT) 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 AJM85214; Mon, 10 Sep 2012 07:19:42 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 10 Sep 2012 08:18:21 +0100 Received: from SZXEML402-HUB.china.huawei.com (10.82.67.32) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 10 Sep 2012 08:19:20 +0100 Received: from SZXEML534-MBX.china.huawei.com ([169.254.2.70]) by szxeml402-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.003; Mon, 10 Sep 2012 15:19:02 +0800 From: Songhaibin To: Wangdanhua , "DECADE@ietf.org" Thread-Topic: =?gb2312?B?T3BlbiBJc3N1ZS0yIKOoZHJhZnQgIkFuIEhUVFAtYmFzZWQgREVDQURFIFJl?= =?gb2312?B?c291cmNlIFByb3RvY29sIqOpLg==?= Thread-Index: Ac2LQ14Nke+22TPoQViTkmz/bcyL0wD4QvNg Date: Mon, 10 Sep 2012 07:19:02 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.123] Content-Type: multipart/alternative; boundary="_000_E33E01DFD5BEA24B9F3F18671078951F23B2E06Dszxeml534mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [decade] =?gb2312?b?T3BlbiBJc3N1ZS0yIKOoZHJhZnQgIkFuIEhUVFAtYmFz?= =?gb2312?b?ZWQgREVDQURFIFJlc291cmNlIFByb3RvY29sIqOpLg==?= X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2012 07:19:44 -0000 --_000_E33E01DFD5BEA24B9F3F18671078951F23B2E06Dszxeml534mbxchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgRGFuaHVhLA0KDQpUaGF0oa9zIGEgZ29vZCBwb2ludC4gSSBmZWVsIHRoYXShr3MgdGhlIGNv bnNlbnN1cyBpbiB0aGUgbWFpbGluZyBsaXN0Lg0KDQotSGFpYmluDQoNCkZyb206IGRlY2FkZS1i b3VuY2VzQGlldGYub3JnIFttYWlsdG86ZGVjYWRlLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFs ZiBPZiBXYW5nZGFuaHVhDQpTZW50OiBXZWRuZXNkYXksIFNlcHRlbWJlciAwNSwgMjAxMiA0OjUw IFBNDQpUbzogREVDQURFQGlldGYub3JnDQpTdWJqZWN0OiBbZGVjYWRlXSBPcGVuIElzc3VlLTIg o6hkcmFmdCAiQW4gSFRUUC1iYXNlZCBERUNBREUgUmVzb3VyY2UgUHJvdG9jb2wio6kuDQoNCkhp IGFsbCwNCg0KVGhlIGZvbGxvd2luZyBpcyBhbm90aGVyIG9wZW4gaXNzdWUgbGVmdCBmb3IgobBB biBIVFRQLWJhc2VkIERFQ0FERSBSZXNvdXJjZSBQcm90b2NvbKGxIChkcmFmdC13YW5nLWRycCku IFdloa9yZSBsb29raW5nIGZvcndhcmQgdG8geW91ciBvcGluaW9ucyBhbmQgY29tbWVudHMuDQoN ClNpbmNlIElFVEYgODNyZCBpbiBQYWlycywgd2UgcmVjZWl2ZWQgYSBsb3Qgb2YgY29tbWVudHMg b24gdGhlIGRlZmluaW5nIG9mIKGwUkVNT1RFX0dFVF9PYmplY3QgTWVzc2FnZaGxIGZyb20gV0cg YXMgd2VsbCBhcyBtYWlsaW5nIGxpc3QgZGlzY3Vzc2lvbi4gVGhlIG1haW4gaWRlYSBpbmNsdWRl cyAxKSBub3QgaW50cm9kdWNlIG5ldyBIVFRQIGhlYWRlcnMsIGxldCBhbG9uZSBuZXcgbWVzc2Fn ZSB0eXBlczsgMikgbGV2ZXJhZ2UgdGhlIGJhc2UgZnVuY3Rpb25hbGl0eSBvZiBhIKGwbm9uLXRy YW5zcGFyZW50IHByb3h5obEgaW4gREVDQURFLCBsb2NhbCBERUNBREUgU2VydmVyIHRvIGFjdCBh cyBhIG5vbi10cmFuc3BhcmVudCBwcm94eSB3aGVuIHByb2Nlc3NpbmcgYSByZXF1ZXN0IGZyb20g YSBERUNBREUgQ2xpZW50LiBXZSBhZG9wdGVkIFdHoa9zIHN1Z2dlc3Rpb24gYW5kIGFscmVhZHkg dXBkYXRlZCB0aGUgZHJhZnQgKHNlZSChsFNlY3Rpb24gOC4gUmVtb3RlX0dldF9PYmplY3QgTWVz c2FnZaGxIGluIHRoZSBkcmFmdCkuIFdlIG5lZWQgbW9yZSByZXZpZXcgYW5kIGNvbW1lbnRzIHRv IHNlZSB3aGV0aGVyIHdlIGNvdWxkIG1ha2UgZnVydGhlciBlZmZvcnQuDQoNClRoYW5rcyENCg0K QmVzdCB3aXNoZXMsDQpEYW5odWENCg0K --_000_E33E01DFD5BEA24B9F3F18671078951F23B2E06Dszxeml534mbxchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi Danh= ua,

&n= bsp;

That=A1= =AFs a good point. I feel that=A1=AFs the consensus in the mailing list.

&n= bsp;

-Haibin=

&n= bsp;

From: decade-bounc= es@ietf.org [mailto:decade-bounces@ietf.org] On Behalf Of Wangdanhua
Sent: Wednesday, September 05, 2012 4:50 PM
To: DECADE@ietf.org
Subject: [decade] Open Issue-2 =A3=A8draft &= quot;An HTTP-based DECADE Resource Protocol"=A3=A9.

 

Hi all,

 

The following is another open i= ssue left for =A1=B0An HTTP-based DECADE Resource Protocol=A1=B1 (draft-wan= g-drp). We=A1=AFre looking forward to your opinions and comments.

 

Since IETF 83rd in P= airs, we received a lot of comments on the defining of =A1=B0REMOTE_GET_Obj= ect Message=A1=B1 from WG as well as mailing list discussion. The main idea= includes 1) not introduce new HTTP headers, let alone new message types; 2) leverage the base functionality of a =A1=B0non= -transparent proxy=A1=B1 in DECADE, local DECADE Server to act as a non-tra= nsparent proxy when processing a request from a DECADE Client. We adopted W= G=A1=AFs suggestion and already updated the draft (see =A1=B0Section 8. Remote_Get_Object Message=A1=B1 in the draft). We ne= ed more review and comments to see whether we could make further effort.

 

Thanks!

 

Best wishes,<= /p>

Danhua

 

--_000_E33E01DFD5BEA24B9F3F18671078951F23B2E06Dszxeml534mbxchi_-- From haibin.song@huawei.com Mon Sep 10 01:26:57 2012 Return-Path: X-Original-To: decade@ietfa.amsl.com Delivered-To: decade@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB5E421F850D for ; Mon, 10 Sep 2012 01:26:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.629 X-Spam-Level: X-Spam-Status: No, score=-3.629 tagged_above=-999 required=5 tests=[AWL=0.329, BAYES_40=-0.185, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227] 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 E-cJqlX30Q-U for ; Mon, 10 Sep 2012 01:26:57 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id E2E3721F8501 for ; Mon, 10 Sep 2012 01:26:48 -0700 (PDT) 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 AJM92027; Mon, 10 Sep 2012 08:26:47 +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; Mon, 10 Sep 2012 09:26:37 +0100 Received: from SZXEML427-HUB.china.huawei.com (10.72.61.35) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 10 Sep 2012 09:26:41 +0100 Received: from SZXEML534-MBX.china.huawei.com ([169.254.2.70]) by szxeml427-hub.china.huawei.com ([10.72.61.35]) with mapi id 14.01.0323.003; Mon, 10 Sep 2012 16:26:29 +0800 From: Songhaibin To: Konstantinos Pentikousis , "Rahman, Akbar" Thread-Topic: Review of draft-ietf-decade-reqs-08 Thread-Index: AQHNek8zSOtXNshZRkafaYo+6v08l5ddw0pwgBaNv4CABJpuYIAKckBA Date: Mon, 10 Sep 2012 08:26:29 +0000 Message-ID: References: <20120813195006.29392.94335.idtracker@ietfa.amsl.com> <8D38716F0C1A444BA0CD7E96454366C23A4C5095@szxeml545-mbs.china.huawei.com> <8D38716F0C1A444BA0CD7E96454366C23A4D82BF@szxeml545-mbx.china.huawei.com> In-Reply-To: <8D38716F0C1A444BA0CD7E96454366C23A4D82BF@szxeml545-mbx.china.huawei.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.123] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "decade@ietf.org" Subject: Re: [decade] Review of draft-ietf-decade-reqs-08 X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2012 08:26:58 -0000 SGkgS29zdGFzIGFuZCBBa2JhciwNCg0KVGhhbmsgeW91IGZvciB0aGUgZ29vZCBjb21tZW50cyBh bmQgZGlzY3Vzc2lvbi4NCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBk ZWNhZGUtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmRlY2FkZS1ib3VuY2VzQGlldGYub3JnXSBP biBCZWhhbGYgT2YNCj4gS29uc3RhbnRpbm9zIFBlbnRpa291c2lzDQo+IFNlbnQ6IFR1ZXNkYXks IFNlcHRlbWJlciAwNCwgMjAxMiAxMjo0MyBBTQ0KPiBUbzogUmFobWFuLCBBa2Jhcg0KPiBDYzog ZGVjYWRlQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbZGVjYWRlXSBSZXZpZXcgb2YgZHJhZnQt aWV0Zi1kZWNhZGUtcmVxcy0wOA0KPiANCj4gSGkgQWtiYXIsDQo+IA0KPiAgIHxUaGFua3MsIHlv dXIgY29tbWVudHMgYW5kIGFuYWx5c2lzIGFyZSBhbHdheXMgdmVyeSB0aG91Z2h0IHByb3Zva2lu ZyENCj4gDQo+IFRoYW5rIHlvdSBmb3IgeW91ciBraW5kIHdvcmRzLg0KPiANCj4gPHNuaXA+DQo+ IA0KPiAgIHxJbiBhIERFQ0FERSBzeXN0ZW0sIGVmZmljaWVudCBzdG9yYWdlIGFuZCBkYXRhIHRy YW5zZmVyIG9mIHNtYWxsIGRhdGENCj4gICB8b2JqZWN0cyBpcyByZXF1aXJlZCBbNS4zXS4NCj4g ICB8DQo+ICAgfFtBS0JBUl0gQU5EIFdFIFNIT1VMRCBBREQgVEhFIFBIUkFTRSAiLi4uIEFORCBE QVRBIFRSQU5TRkVSIE9GDQo+IExBUkdFDQo+ICAgfERBVEEgT0JKRUNUUyBJUyBBTFNPIElOSEVS RU5UTFkgU1VQUE9SVEVELiINCj4gDQo+IFN1cmUsIEkgZ3Vlc3MgdGhpcyBnb2VzIGludG8gdGhl IHRleHQgb2YgWzUuM10gdGhlbi4NCj4gDQo+IA0KPiAgIHxUaGUgZGF0YSB0cmFuc3BvcnQgcHJv dG9jb2wgY2FuIGJlIG5lZ290aWF0ZWQgYnV0IG11c3QgYmUgc2VjdXJlIFs3LjEsDQo+ICAgfDcu M10uDQo+ICAgfA0KPiAgIHwNCj4gICB8W0FLQkFSXSBBTkQgSSBXT1VMRCBBREQgVFdPIE1PUkUg UE9JTlRTIEFQUExJQ0FCTEUgVE8gVEhFIE5FWFQNCj4gICB8UEFSQUdSQVBIOg0KPiAgIHwtIEFM TCBDT05UUk9MIEZVTkNUSU9OUyBBUkUgQUNDT01QTElTSEVEIFVTSU5HIFRIRSBERUNBREUNCj4g UkVTT1VSQ0UNCj4gICB8UFJPVE9DT0wgKERSUCkNCj4gDQo+IEkgdW5kZXJzdGFuZCB3aGF0IHlv dSBoYXZlIGluIG1pbmQsIGJ1dCBpdCB3aWxsIGJlIGEgYml0IHN0cmFuZ2UgdG8gcHV0LCBsZXQg bWUgY2FsbA0KPiBpdCwgYSAiZm9yd2FyZCByZWZlcmVuY2UiIHRvIGEgcHJvdG9jb2wgdGhhdCBk b2VzIG5vdCBleGlzdC4gSnVzdCBteSAkMC4wMi4NCg0KQXMgbG9uZyBhcyB0aGUgZXhwbGFuYXRp b24gZm9yIERSUCBleGlzdHMgaW4gdGhlIGRvY3VtZW50LCBJIGRvIG5vdCB0aGluayB0aGlzIGlz IGEgcHJvYmxlbS4NCg0KLUhhaWJpbg0KDQo+IA0KPiAgIHxTZWN1cml0eSBpcyBiYXNlZCBvbiBj cnlwdG9ncmFwaGljIG1ldGhvZHMgd2hpY2ggYWxsb3cgYSBERUNBREUNCj4gICB8cHJvdmlkZXIg dG8gYWNjZXNzIHN5c3RlbSByZXNvdXJjZXMsIGRpc3RyaWJ1dGUgY29udGVudCB0byBjb250ZW50 DQo+ICAgfGNvbnN1bWVycyBvZiBpdHMgY2hvb3NpbmcsIGV2ZW4gd2hlbiBvZmZsaW5lLCB1c2lu ZyAoaWYgbmVlZGVkKSBmaW5lLQ0KPiAgIHxncmFpbmVkIGFjY2VzcyBjb250cm9sIHBvbGljaWVz IFs2LjIsIDYuMywgNi40LCA2LjUsIDYuNiwgOC4yLCA4LjNdLg0KPiAgIHxDbGllbnQgZGF0YSBv biBhIHNlcnZlciBhcmUgYnkgZGVmYXVsdCBwcml2YXRlIFs2LjddLiBJdCBpcyB0aGUgY2xpZW50 DQo+ICAgfHRoYXQgYWx3YXlzIGRpc2NvdmVycyBhbmQgaW5pdGlhdGVzIGEgY29ubmVjdGlvbiB0 byBhIHNlcnZlciBbNi44LA0KPiAgIHw2LjldLCBub3QgdmljZSB2ZXJzYS4gRGF0YSBvYmplY3Rz IGNhbiBiZSB3cml0dGVuIGJ5IGEgcHJvdmlkZXIgaW4gb25lDQo+ICAgfGdvIG9yIHNldmVyYWwg cm91bmRzIGFuZCBjYW4gYmUgcmVhZCBieSBtdWx0aXBsZSBjb25zdW1lcnMNCj4gICB8c2ltdWx0 YW5lb3VzbHkgWzcuMiwgNy40XS4gRXZlcnkgcHJvdmlkZXIgaXMgZ2l2ZW4gdGhlIG1lYW5zIHRv IG9idGFpbg0KPiAgIHxyZXNvdXJjZSB1c2FnZSBzdGF0cyBhbmQgcXVvdGFzIFsxMC4xXS4gT3Zl cmFsbCwgYXR0YWNrIG1pdGlnYXRpb24gaXMNCj4gICB8YSBNVVNUIFs5LjVdIGFuZCB0cmFuc3Bv cnQgcmVkaXJlY3Rpb24gU0hPVUxEIGJlIHN1cHBvcnRlZCBbNy43XQ0KPiAgIHwNCj4gICB8W0FL QkFSXSBJTiBUSEUgRVhQTEFOQVRJT04gWU9VIFNXSVRDSCBURVJNUyBCRVRXRUVOICJQUk9WSURF UiINCj4gQU5EDQo+ICAgfCJDTElFTlQiLiAgSVQgV09VTEQgQkUgQ0xFQVJFUiBJIFRISU5LIElG IFlPVSBTVFVDSyBUTyBKVVNUICJQUk9WSURFUiINCj4gICB8QU5EICJDT05TVU1FUiIuDQo+IA0K PiBXZWxsLCBJIGFncmVlIHRoYXQgYSBmZXcgdGVybXMgaW4gc2VjIDIuKiBoYXZlIHNvbWUgb3Zl cmxhcCBhbmQgcGVyaGFwcyBjb3VsZCBiZQ0KPiBzaW1wbGlmaWVkIGEgYml0LCBidXQgSSB0cmll ZCB0byBoYXZlIHRoZSBjaGVhdCBzaGVldCBzdW1tYXJ5IGFzIGNsb3NlIGFzIHBvc3NpYmxlDQo+ IHRvIHRoZSBkZWZpbml0aW9ucyBpbiBTZWMgMi4qIGFuZCB0aGUgLXJlcXMgdGV4dC4gRm9yIGV4 YW1wbGUsIGluIDYuNyAoY29weSBhbmQNCj4gcGFzdGUpOg0KPiANCj4gUkVRVUlSRU1FTlQoUyk6 IFVubGVzcyByZWFkIG9yIHdyaXRlIGFjY2VzcyBpcyBncmFudGVkIGJ5IGEgUHJvdmlkZXIsIHRo ZQ0KPiBkZWZhdWx0IHBlcm1pc3Npb24gTVVTVCBiZSBubyBhY2Nlc3MuDQo+IFJBVElPTkFMRTog VGhpcyByZXF1aXJlbWVudCBpcyB0byBwcm90ZWN0IGNsaWVudCBwcml2YWN5IGJ5IGRlZmF1bHQu DQo+IA0KPiBJIGd1ZXNzIHRoYXQgbWVhbnMgcy9jbGllbnQvcHJvdmlkZXIgaW4gdGhlIHJhdGlv bmFsZSBwYXJ0LCBhbmQgdGhlIGNoZWF0IHNoZWV0DQo+IHN1bW1hcnkgYmVjb21lcyAiUHJvdmlk ZXIgZGF0YSBvbiBhIHNlcnZlciBhcmUgYnkgZGVmYXVsdCBwcml2YXRlIFs2LjddIg0KPiANCj4g T24gdGhlIG90aGVyIGhhbmQsIGluIHRoZSBzZW50ZW5jZSAiSXQgaXMgdGhlIGNsaWVudC4uLiBb Ni44LCA2LjldIiwgImNsaWVudCIgKGFzIHBlcg0KPiBzZWMuIDIuMSkgaXMgdGhlIHJpZ2h0IHRl cm0sIG5vdCAicHJvdmlkZXIiLg0KPiANCj4gQmVzdCByZWdhcmRzLA0KPiANCj4gS29zdGFzDQo= From haibin.song@huawei.com Mon Sep 10 18:08:36 2012 Return-Path: X-Original-To: decade@ietfa.amsl.com Delivered-To: decade@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9B2321F86AB for ; Mon, 10 Sep 2012 18:08:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.344 X-Spam-Level: X-Spam-Status: No, score=-5.344 tagged_above=-999 required=5 tests=[AWL=1.254, 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 yAe5J07GmnVc for ; Mon, 10 Sep 2012 18:08:35 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id CA82621F8653 for ; Mon, 10 Sep 2012 18:08:34 -0700 (PDT) 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 AKN66064; Tue, 11 Sep 2012 01:08:33 +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 Sep 2012 02:08:26 +0100 Received: from SZXEML422-HUB.china.huawei.com (10.82.67.161) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 11 Sep 2012 02:08:32 +0100 Received: from SZXEML534-MBX.china.huawei.com ([169.254.2.70]) by szxeml422-hub.china.huawei.com ([10.82.67.161]) with mapi id 14.01.0323.003; Tue, 11 Sep 2012 09:08:15 +0800 From: Songhaibin To: Wangdanhua , "DECADE@ietf.org" Thread-Topic: An open issue for "An HTTP-based DECADE Resource Protocol". Thread-Index: Ac2CpCj8fl0YRwWDTHeBcwdmL2UFSANFW9XQ Date: Tue, 11 Sep 2012 01:08:15 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.123] Content-Type: multipart/alternative; boundary="_000_E33E01DFD5BEA24B9F3F18671078951F23B2E502szxeml534mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [decade] An open issue for "An HTTP-based DECADE Resource Protocol". X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2012 01:08:37 -0000 --_000_E33E01DFD5BEA24B9F3F18671078951F23B2E502szxeml534mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Danhua, Personally I think OAuth is a good base for the access and resource control= . I realize that OAuth is also considering solutions to prevent token leaki= ng or abuse. I think that's also useful for DECADE context. -Haibin From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.org] On Behalf Of= Wangdanhua Sent: Saturday, August 25, 2012 5:30 PM To: DECADE@ietf.org Subject: [decade] An open issue for "An HTTP-based DECADE Resource Protocol= ". Hi all, The following is one of the open issues left for "An HTTP-based DECADE Reso= urce Protocol" (draft-wang-drp). We're looking forward to your opinions and= comments. As to access and resource control, we authors once had several candidate pr= otocols in our mind, they are Kerberos, AAA, and OAuth. 1. During the latest DECADE WG meeting in IETF 82nd Taipei, we realized tha= t Kerberos isn't the right solution for resource control, since it works on= the basis of "tickers" to allow nodes to prove their identity to one anoth= er in a secure manner. 2. As to AAA, it is mainly used in management environment. Extending the bi= nary-value-pairs may be possible to grant network resources for data access= , but a text-based protocol may be preferred. 3. OAuth 2.0 is used to grant access to the resource owner's resources from= a third party without explicitly exposing the resource owner's credentials= . Certain grant types can be extended for access and resource control in DE= CADE. In summary, we believe that OAuth2.0 seems to be the most suitable protocol= for DECADE access and resource control till now. Maybe it's time for us to= write a protocol using OAuth 2.0 and see what problems we may meet. Thanks a lot. Best wishes, Danhua Wang --_000_E33E01DFD5BEA24B9F3F18671078951F23B2E502szxeml534mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Danh= ua,

&n= bsp;

Persona= lly I think OAuth is a good base for the access and resource control. I rea= lize that OAuth is also considering solutions to prevent token leaking or a= buse. I think that’s also useful for DECADE context.

&n= bsp;

-Haibin=

&n= bsp;

From: decade-bounc= es@ietf.org [mailto:decade-bounces@ietf.org] On Behalf Of Wangdanhua
Sent: Saturday, August 25, 2012 5:30 PM
To: DECADE@ietf.org
Subject: [decade] An open issue for "An HTTP-based DECADE Resou= rce Protocol".

 

Hi all,

 

The following is one of the ope= n issues left for "An HTTP-based DECADE Resource Protocol" (draft= -wang-drp). We're looking forward to your opinions and comments.=

As to access and resource contr= ol, we authors once had several candidate protocols in our mind, they are K= erberos, AAA, and OAuth.

 

1. During the latest DECADE WG = meeting in IETF 82nd Taipei, we realized that Kerberos isn't the right solu= tion for resource control, since it works on the basis of "tickers&quo= t; to allow nodes to prove their identity to one another in a secure manner.

2. As to AAA, it is mainly used= in management environment. Extending the binary-value-pairs may be possibl= e to grant network resources for data access, but a text-based protocol may= be preferred.

3. OAuth 2.0 is used to grant a= ccess to the resource owner's resources from a third party without explicit= ly exposing the resource owner's credentials. Certain grant types can be ex= tended for access and resource control in DECADE.

 

In summary, we believe that OAu= th2.0 seems to be the most suitable protocol for DECADE access and resource= control till now. Maybe it's time for us to write a protocol using OAuth 2= .0 and see what problems we may meet.

 

Thanks a lot.=

 

Best wishes,<= /p>

Danhua Wang

--_000_E33E01DFD5BEA24B9F3F18671078951F23B2E502szxeml534mbxchi_-- From wangdanhua@huawei.com Tue Sep 11 23:15:01 2012 Return-Path: X-Original-To: decade@ietfa.amsl.com Delivered-To: decade@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F080A21F8551 for ; Tue, 11 Sep 2012 23:15:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=3.299, 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 nr43VeFLuGwG for ; Tue, 11 Sep 2012 23:15:01 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id C471D21F8550 for ; Tue, 11 Sep 2012 23:15:00 -0700 (PDT) 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 AJO86863; Wed, 12 Sep 2012 06:14:58 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 12 Sep 2012 07:13:44 +0100 Received: from SZXEML417-HUB.china.huawei.com (10.82.67.156) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 12 Sep 2012 07:13:47 +0100 Received: from SZXEML507-MBS.china.huawei.com ([169.254.7.120]) by szxeml417-hub.china.huawei.com ([10.82.67.156]) with mapi id 14.01.0323.003; Wed, 12 Sep 2012 14:13:24 +0800 From: Wangdanhua To: "DECADE@ietf.org" Thread-Topic: Open Issue-3 (draft "An HTTP-based DECADE Resource Protocol") Thread-Index: Ac2QrbZ/PXLu2UrYSaS5JxQFT3PHzA== Date: Wed, 12 Sep 2012 06:13:24 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.177] Content-Type: multipart/alternative; boundary="_000_AFD688AF30E249418739DBDC55B9C75B34D7C3B4SZXEML507MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [decade] Open Issue-3 (draft "An HTTP-based DECADE Resource Protocol") X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Sep 2012 06:15:02 -0000 --_000_AFD688AF30E249418739DBDC55B9C75B34D7C3B4SZXEML507MBSchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, The following is the third open issue left for "An HTTP-based DECADE Resour= ce Protocol" (draft-wang-drp). We're looking forward to your opinions and c= omments. About the object naming scheme used in DECADE Protocol, we're inclined to a= dopting the naming scheme proposed in the draft-farrell-decade-ni (Naming T= hings with Hashes). We thought it's a good scheme and we are planning to ha= ve a try and see whether it's workable in the protocol we proposed. Does anybody have other opinions? And we'd like to hear your voice. Best wishes, Danhua Wang --_000_AFD688AF30E249418739DBDC55B9C75B34D7C3B4SZXEML507MBSchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

Hi all,

 

The following is the third open= issue left for “An HTTP-based DECADE Resource Protocol” (draft= -wang-drp). We’re looking forward to your opinions and comments.=

 

About the object naming scheme = used in DECADE Protocol, we’re inclined to adopting the naming scheme= proposed in the draft-farrell-decade-ni (Naming Things with Hashes). We th= ought it’s a good scheme and we are planning to have a try and see whether it’s workable in the protocol we propo= sed.

 

Does anybody have other opinion= s? And we’d like to hear your voice.

 

Best wishes,<= /p>

Danhua Wang

 

--_000_AFD688AF30E249418739DBDC55B9C75B34D7C3B4SZXEML507MBSchi_-- From zongning@huawei.com Tue Sep 11 23:47:58 2012 Return-Path: X-Original-To: decade@ietfa.amsl.com Delivered-To: decade@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3F4021F854E for ; Tue, 11 Sep 2012 23:47:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.598 X-Spam-Level: X-Spam-Status: No, score=-106.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 s9mBwO0ymZaB for ; Tue, 11 Sep 2012 23:47:57 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 44B6C21F8533 for ; Tue, 11 Sep 2012 23:47:57 -0700 (PDT) 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 AJO89510; Wed, 12 Sep 2012 06:47:56 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 12 Sep 2012 07:47:44 +0100 Received: from SZXEML427-HUB.china.huawei.com (10.72.61.35) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 12 Sep 2012 07:47:52 +0100 Received: from SZXEML504-MBS.china.huawei.com ([169.254.8.206]) by szxeml427-hub.china.huawei.com ([10.72.61.35]) with mapi id 14.01.0323.003; Wed, 12 Sep 2012 14:47:39 +0800 From: Zongning To: Wangdanhua , "DECADE@ietf.org" Thread-Topic: [decade] Open Issue-3 (draft "An HTTP-based DECADE Resource Protocol") Thread-Index: Ac2QrbZ/PXLu2UrYSaS5JxQFT3PHzAABJeDg Date: Wed, 12 Sep 2012 06:47:38 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.38] Content-Type: multipart/alternative; boundary="_000_B0D29E0424F2DE47A0B36779EC66677924AE6296szxeml504mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [decade] Open Issue-3 (draft "An HTTP-based DECADE Resource Protocol") X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Sep 2012 06:47:59 -0000 --_000_B0D29E0424F2DE47A0B36779EC66677924AE6296szxeml504mbschi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Danhua, I support adopting the naming scheme proposed in draft-farrell-decede-ni as= well. Thanks. -Ning From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.org] On Behalf Of= Wangdanhua Sent: Wednesday, September 12, 2012 2:13 PM To: DECADE@ietf.org Subject: [decade] Open Issue-3 (draft "An HTTP-based DECADE Resource Protoc= ol") Hi all, The following is the third open issue left for "An HTTP-based DECADE Resour= ce Protocol" (draft-wang-drp). We're looking forward to your opinions and c= omments. About the object naming scheme used in DECADE Protocol, we're inclined to a= dopting the naming scheme proposed in the draft-farrell-decade-ni (Naming T= hings with Hashes). We thought it's a good scheme and we are planning to ha= ve a try and see whether it's workable in the protocol we proposed. Does anybody have other opinions? And we'd like to hear your voice. Best wishes, Danhua Wang --_000_B0D29E0424F2DE47A0B36779EC66677924AE6296szxeml504mbschi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi, Dan= hua,

&n= bsp;

I suppo= rt adopting the naming scheme proposed in draft-farrell-decede-ni as well.<= o:p>

Thanks.=

&n= bsp;

-Ning

&n= bsp;

From: decade-bounc= es@ietf.org [mailto:decade-bounces@ietf.org] On Behalf Of Wangdanhua
Sent: Wednesday, September 12, 2012 2:13 PM
To: DECADE@ietf.org
Subject: [decade] Open Issue-3 (draft "An HTTP-based DECADE Res= ource Protocol")

 

 

Hi all,

 

The following is the third open= issue left for “An HTTP-based DECADE Resource Protocol” (draft= -wang-drp). We’re looking forward to your opinions and comments.=

 

About the object naming scheme = used in DECADE Protocol, we’re inclined to adopting the naming scheme= proposed in the draft-farrell-decade-ni (Naming Things with Hashes). We th= ought it’s a good scheme and we are planning to have a try and see whether it’s workable in the protocol we propo= sed.

 

Does anybody have other opinion= s? And we’d like to hear your voice.

 

Best wishes,<= /p>

Danhua Wang

 

--_000_B0D29E0424F2DE47A0B36779EC66677924AE6296szxeml504mbschi_-- From lampson0505@gmail.com Wed Sep 12 06:55:04 2012 Return-Path: X-Original-To: decade@ietfa.amsl.com Delivered-To: decade@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0581421F860F for ; Wed, 12 Sep 2012 06:55:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.69 X-Spam-Level: X-Spam-Status: No, score=-1.69 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_ILLEGAL_IP=1.908, 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 cbs28jcwv-pi for ; Wed, 12 Sep 2012 06:55:03 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id D012121F8600 for ; Wed, 12 Sep 2012 06:55:02 -0700 (PDT) Received: by dadf8 with SMTP id f8so1029471dad.31 for ; Wed, 12 Sep 2012 06:55:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type; bh=hsNAmXJIf851wRkf46XZBF/u4E2V07QJR+VChDWcS4Y=; b=Ayf/ciiX+vKxOQU7u2uLxqd6y3t2vtQBP0QQJ6Kp4neyBmOled4BByacZbXvTWE0f8 STprAEKbTx1os5yWi3tYM32jwI+2S0YI/bjGGvkzAFIMLBZax9S3n8Eznz5p2GQlMJjK 0VJZSJOH1C1qE5i8q8q1Q8d1ivt0U3gwUFryL/Y0RX/4Tmq9ET4sE2hA1fM5UNaFvtBb mwOucEVJPn/TOSbT611Qb9WHfQvgx/gl1P409b0zXNJjfSbkg9inFtjEDDuBYeOY+zAG bacxnGm8QcF5NSDNobWcb68z/5aH9YvAfaAz869NgybqO4d05et9EfAzn9XDUonjL6Sb owjg== Received: by 10.68.134.228 with SMTP id pn4mr16806627pbb.147.1347458102602; Wed, 12 Sep 2012 06:55:02 -0700 (PDT) Received: from [223.82.202.196] ([223.82.202.196]) by mx.google.com with ESMTPS id ps2sm5264187pbb.0.2012.09.12.06.55.00 (version=SSLv3 cipher=OTHER); Wed, 12 Sep 2012 06:55:01 -0700 (PDT) Message-ID: <50509431.8000500@gmail.com> Date: Wed, 12 Sep 2012 09:54:57 -0400 From: Hongqiang Harry Liu User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0 MIME-Version: 1.0 To: decade@ietf.org References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------090108010808020104000807" Subject: Re: [decade] An open issue for "An HTTP-based DECADE Resource Protocol". X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Sep 2012 13:55:04 -0000 This is a multi-part message in MIME format. --------------090108010808020104000807 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Danhua I agree that OAuth is a good option and starting point. Thanks Harry Liu On 08/25/2012 05:29 AM, Wangdanhua wrote: > > Hi all, > > The following is one of the open issues left for "An HTTP-based DECADE > Resource Protocol" (draft-wang-drp). We're looking forward to your > opinions and comments. > > As to access and resource control, we authors once had several > candidate protocols in our mind, they are Kerberos, AAA, and OAuth. > > 1. During the latest DECADE WG meeting in IETF 82nd Taipei, we > realized that Kerberos isn't the right solution for resource control, > since it works on the basis of "tickers" to allow nodes to prove their > identity to one another in a secure manner. > > 2. As to AAA, it is mainly used in management environment. Extending > the binary-value-pairs may be possible to grant network resources for > data access, but a text-based protocol may be preferred. > > 3. OAuth 2.0 is used to grant access to the resource owner's resources > from a third party without explicitly exposing the resource owner's > credentials. Certain grant types can be extended for access and > resource control in DECADE. > > In summary, we believe that OAuth2.0 seems to be the most suitable > protocol for DECADE access and resource control till now. Maybe it's > time for us to write a protocol using OAuth 2.0 and see what problems > we may meet. > > Thanks a lot. > > Best wishes, > > Danhua Wang > --------------090108010808020104000807 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Hi Danhua

I agree that OAuth is a good option and starting point.

Thanks
Harry Liu

On 08/25/2012 05:29 AM, Wangdanhua wrote:

Hi all,

 

The following is one of the open issues left for "An HTTP-based DECADE Resource Protocol" (draft-wang-drp). We're looking forward to your opinions and comments.

As to access and resource control, we authors once had several candidate protocols in our mind, they are Kerberos, AAA, and OAuth.

 

1. During the latest DECADE WG meeting in IETF 82nd Taipei, we realized that Kerberos isn't the right solution for resource control, since it works on the basis of "tickers" to allow nodes to prove their identity to one another in a secure manner.

2. As to AAA, it is mainly used in management environment. Extending the binary-value-pairs may be possible to grant network resources for data access, but a text-based protocol may be preferred.

3. OAuth 2.0 is used to grant access to the resource owner's resources from a third party without explicitly exposing the resource owner's credentials. Certain grant types can be extended for access and resource control in DECADE.

 

In summary, we believe that OAuth2.0 seems to be the most suitable protocol for DECADE access and resource control till now. Maybe it's time for us to write a protocol using OAuth 2.0 and see what problems we may meet.

 

Thanks a lot.

 

Best wishes,

Danhua Wang


--------------090108010808020104000807-- From lampson0505@gmail.com Wed Sep 12 07:10:45 2012 Return-Path: X-Original-To: decade@ietfa.amsl.com Delivered-To: decade@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAAC421F863F for ; Wed, 12 Sep 2012 07:10:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.662 X-Spam-Level: * X-Spam-Status: No, score=1.662 tagged_above=-999 required=5 tests=[AWL=-3.352, BAYES_20=-0.74, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_ENC_GB2312=1.345] 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 uDcwVMsFDlx5 for ; Wed, 12 Sep 2012 07:10:40 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5AB6021F8627 for ; Wed, 12 Sep 2012 07:10:40 -0700 (PDT) Received: by pbbrr4 with SMTP id rr4so2367727pbb.31 for ; Wed, 12 Sep 2012 07:10:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type; bh=mN8vpnAJir3RFCZxKfPLcJ6JUJ1dHgmyARXzzjgeooE=; b=ydjpuhR4WF3fTqVFOosZzrmCRVG+kFxAnvDAhuMPtmWnWg/CYr6BYGqsdHnbe8T6Z1 P1iUpsQ39lXwpISU7P4T9SqWw3aPJt0bVLv4GvwmyzRkXqlb6mtPjgowuN6dLD1BGdSA uyp+olZQDEqtY69F5Vaq6gzJgOFICXyhjdPYwtwGXs/6eUfz+FVuRKBoHGd7clTCsbhT Wimlkm7shP9drp2haPPQ1PPmeTmYnz5stGBoLlP9TUpqv+SbH8L+vCWjgNLEJo1g8SFE m4Qx5SvwSuQ7PClpb70QNWRdTDRnNR4u7lJB/X0CbB3njtsVMl219Nzgu1qiziO3KDj5 8r8A== Received: by 10.68.231.130 with SMTP id tg2mr17038631pbc.70.1347459039865; Wed, 12 Sep 2012 07:10:39 -0700 (PDT) Received: from [223.82.202.196] ([223.82.202.196]) by mx.google.com with ESMTPS id to6sm5281815pbc.12.2012.09.12.07.10.37 (version=SSLv3 cipher=OTHER); Wed, 12 Sep 2012 07:10:38 -0700 (PDT) Message-ID: <505097DA.3060501@gmail.com> Date: Wed, 12 Sep 2012 10:10:34 -0400 From: Hongqiang Harry Liu User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0 MIME-Version: 1.0 To: decade@ietf.org References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------040209040604020707090703" Subject: Re: [decade] =?gb2312?b?T3BlbiBJc3N1ZS0yIKOoZHJhZnQgIkFuIEhUVFAtYmFz?= =?gb2312?b?ZWQgREVDQURFIFJlc291cmNlIFByb3RvY29sIqOpLg==?= X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Sep 2012 14:10:45 -0000 This is a multi-part message in MIME format. --------------040209040604020707090703 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 8bit Hi Danhua I am wondering whether we need to add corresponding HTTP proxy headers in the REMOTE_GET_Object case. For example: Via, Proxy-Authorization. Of course we can use OAuth to replace Proxy-Authorization. In next version, Section 8 needs more details on message flows. Thank you very much Harry On 09/05/2012 04:49 AM, Wangdanhua wrote: > > Hi all, > > The following is another open issue left for An HTTP-based DECADE > Resource Protocol (draft-wang-drp). Were looking forward to your > opinions and comments. > > Since IETF 83^rd in Pairs, we received a lot of comments on the > defining of REMOTE_GET_Object Message from WG as well as mailing > list discussion. The main idea includes 1) not introduce new HTTP > headers, let alone new message types; 2) leverage the base > functionality of a non-transparent proxy in DECADE, local DECADE > Server to act as a non-transparent proxy when processing a request > from a DECADE Client. We adopted WGs suggestion and already updated > the draft (see Section 8. Remote_Get_Object Message in the draft). > We need more review and comments to see whether we could make further > effort. > > Thanks! > > Best wishes, > > Danhua > --------------040209040604020707090703 Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: 8bit
Hi Danhua

I am wondering whether we need to add corresponding HTTP proxy headers in the REMOTE_GET_Object case.
For example: Via, Proxy-Authorization.

Of course we can use OAuth to replace Proxy-Authorization.
In next version, Section 8 needs more details on message flows.

Thank you very much

Harry

On 09/05/2012 04:49 AM, Wangdanhua wrote:

Hi all,

 

The following is another open issue left for An HTTP-based DECADE Resource Protocol (draft-wang-drp). Were looking forward to your opinions and comments.

 

Since IETF 83rd in Pairs, we received a lot of comments on the defining of REMOTE_GET_Object Message from WG as well as mailing list discussion. The main idea includes 1) not introduce new HTTP headers, let alone new message types; 2) leverage the base functionality of a non-transparent proxy in DECADE, local DECADE Server to act as a non-transparent proxy when processing a request from a DECADE Client. We adopted WGs suggestion and already updated the draft (see Section 8. Remote_Get_Object Message in the draft). We need more review and comments to see whether we could make further effort.

 

Thanks!

 

Best wishes,

Danhua

 


--------------040209040604020707090703-- From lampson0505@gmail.com Wed Sep 12 07:11:45 2012 Return-Path: X-Original-To: decade@ietfa.amsl.com Delivered-To: decade@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCF7C21F863F for ; Wed, 12 Sep 2012 07:11:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.014 X-Spam-Level: X-Spam-Status: No, score=-0.014 tagged_above=-999 required=5 tests=[AWL=1.676, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_ILLEGAL_IP=1.908, 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 uio5PhJ4Bh97 for ; Wed, 12 Sep 2012 07:11:44 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id CA4CC21F8604 for ; Wed, 12 Sep 2012 07:11:44 -0700 (PDT) Received: by pbbrr4 with SMTP id rr4so2369132pbb.31 for ; Wed, 12 Sep 2012 07:11:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type; bh=mT+uWxefG41W0TIAEXhCIfZ/Fx6+9NzBAFzKERqeJYM=; b=zm0K456OhRO3KABehYlfJQR7QCpwhmdM5QqrHE60ClOqiAmS850yEt5MZi6Ftw16L2 bKfsqPcxYnywT2PlhYSmgn85DqfwXilFSCa8BHX/Crj6XYc9I+dBEvW9CiGWRE3Ip420 nXFzvgnJCKM2l+xqOXS8FxghLbt6DGIr2k+wWHrULeyYRumrT8O/7CHKHeYz/C6naCaR +9pLLc4zIxnmEy5ErG04wzSxK7gj8ciBRvGsET47qgD8JSSB+NU+SujVI+vZIrRlwZ1G ugTVXYxMwbQbmdW0a9i8R64uE9ACIaLMeBh/Z15QuP4VQ92EVY9dNVMq8hW84zf2GU5n kReQ== Received: by 10.66.88.233 with SMTP id bj9mr31892773pab.72.1347459104635; Wed, 12 Sep 2012 07:11:44 -0700 (PDT) Received: from [223.82.202.196] ([223.82.202.196]) by mx.google.com with ESMTPS id pk9sm11464337pbb.4.2012.09.12.07.11.42 (version=SSLv3 cipher=OTHER); Wed, 12 Sep 2012 07:11:43 -0700 (PDT) Message-ID: <5050981C.9050006@gmail.com> Date: Wed, 12 Sep 2012 10:11:40 -0400 From: Hongqiang Harry Liu User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0 MIME-Version: 1.0 To: decade@ietf.org References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------060005080204050504080408" Subject: Re: [decade] Open Issue-3 (draft "An HTTP-based DECADE Resource Protocol") X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Sep 2012 14:11:45 -0000 This is a multi-part message in MIME format. --------------060005080204050504080408 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Danhua It sounds good to me. Harry On 09/12/2012 02:13 AM, Wangdanhua wrote: > > Hi all, > > The following is the third open issue left for "An HTTP-based DECADE > Resource Protocol" (draft-wang-drp). We're looking forward to your > opinions and comments. > > About the object naming scheme used in DECADE Protocol, we're inclined > to adopting the naming scheme proposed in the draft-farrell-decade-ni > (Naming Things with Hashes). We thought it's a good scheme and we are > planning to have a try and see whether it's workable in the protocol > we proposed. > > Does anybody have other opinions? And we'd like to hear your voice. > > Best wishes, > > Danhua Wang > --------------060005080204050504080408 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Hi Danhua

It sounds good to me.

Harry
On 09/12/2012 02:13 AM, Wangdanhua wrote:

 

Hi all,

 

The following is the third open issue left for “An HTTP-based DECADE Resource Protocol” (draft-wang-drp). We’re looking forward to your opinions and comments.

 

About the object naming scheme used in DECADE Protocol, we’re inclined to adopting the naming scheme proposed in the draft-farrell-decade-ni (Naming Things with Hashes). We thought it’s a good scheme and we are planning to have a try and see whether it’s workable in the protocol we proposed.

 

Does anybody have other opinions? And we’d like to hear your voice.

 

Best wishes,

Danhua Wang

 


--------------060005080204050504080408-- From Akbar.Rahman@InterDigital.com Wed Sep 12 07:31:12 2012 Return-Path: X-Original-To: decade@ietfa.amsl.com Delivered-To: decade@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7703821F8618 for ; Wed, 12 Sep 2012 07:31:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.356 X-Spam-Level: X-Spam-Status: No, score=-2.356 tagged_above=-999 required=5 tests=[AWL=0.242, BAYES_00=-2.599, 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 0SnPQCeiYqn8 for ; Wed, 12 Sep 2012 07:31:11 -0700 (PDT) Received: from idcout.InterDigital.com (smtp-out1.interdigital.com [64.208.228.135]) by ietfa.amsl.com (Postfix) with ESMTP id 2D41A21F8613 for ; Wed, 12 Sep 2012 07:31:08 -0700 (PDT) Received: from SAM.InterDigital.com ([10.30.2.11]) by idcout.InterDigital.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 12 Sep 2012 10:31:07 -0400 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_01CD90F3.3EFF43C8" Date: Wed, 12 Sep 2012 10:31:06 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [decade] Open Issue-3 (draft "An HTTP-based DECADE ResourceProtocol") Thread-Index: Ac2QrbZ/PXLu2UrYSaS5JxQFT3PHzAARRvvg References: From: "Rahman, Akbar" To: "Wangdanhua" X-OriginalArrivalTime: 12 Sep 2012 14:31:07.0132 (UTC) FILETIME=[3EF52BC0:01CD90F3] Cc: DECADE@ietf.org Subject: Re: [decade] Open Issue-3 (draft "An HTTP-based DECADE ResourceProtocol") X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Sep 2012 14:31:12 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD90F3.3EFF43C8 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Danhua, =20 Yes, I agree that to make progress on your draft you need to show how to use a naming scheme as part of your proposal. And I also agree that using the draft-farrell-decade-ni should be the starting point. =20 =20 Sincerely, =20 =20 Akbar =20 From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.org] On Behalf Of Wangdanhua Sent: Wednesday, September 12, 2012 2:13 AM To: DECADE@ietf.org Subject: [decade] Open Issue-3 (draft "An HTTP-based DECADE ResourceProtocol") =20 =20 Hi all, =20 The following is the third open issue left for "An HTTP-based DECADE Resource Protocol" (draft-wang-drp). We're looking forward to your opinions and comments. =20 About the object naming scheme used in DECADE Protocol, we're inclined to adopting the naming scheme proposed in the draft-farrell-decade-ni (Naming Things with Hashes). We thought it's a good scheme and we are planning to have a try and see whether it's workable in the protocol we proposed. =20 Does anybody have other opinions? And we'd like to hear your voice. =20 Best wishes, Danhua Wang =20 ------_=_NextPart_001_01CD90F3.3EFF43C8 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi = Danhua,

 

Yes, I = agree that to make progress on your draft you need to show how to use a = naming scheme as part of your proposal.  And I also agree that = using the draft-farrell-decade-ni should be the starting = point.

 

 

Sincerely,

=

 

 

Akbar

 

From:= = decade-bounces@ietf.org [mailto:decade-bounces@ietf.org] On Behalf Of = Wangdanhua
Sent: Wednesday, September 12, 2012 2:13 = AM
To: DECADE@ietf.org
Subject: [decade] Open = Issue-3 (draft "An HTTP-based DECADE = ResourceProtocol")

 

 

Hi = all,

 

The following is the third open issue left for = “An HTTP-based DECADE Resource Protocol” (draft-wang-drp). = We’re looking forward to your opinions and = comments.

 

About the object naming scheme used in DECADE = Protocol, we’re inclined to adopting the naming scheme proposed in = the draft-farrell-decade-ni (Naming Things with Hashes). We thought = it’s a good scheme and we are planning to have a try and see = whether it’s workable in the protocol we = proposed.

 

Does anybody have other opinions? And we’d like = to hear your voice.

 

Best = wishes,

Danhua Wang

 

------_=_NextPart_001_01CD90F3.3EFF43C8-- From k.pentikousis@huawei.com Thu Sep 13 07:58:47 2012 Return-Path: X-Original-To: decade@ietfa.amsl.com Delivered-To: decade@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31C8F21F85F0 for ; Thu, 13 Sep 2012 07:58:47 -0700 (PDT) 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 56jLzlUyhhOJ for ; Thu, 13 Sep 2012 07:58:46 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 5AB6521F85AF for ; Thu, 13 Sep 2012 07:58:46 -0700 (PDT) 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 AKQ23739; Thu, 13 Sep 2012 14:58:45 +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; Thu, 13 Sep 2012 15:58:07 +0100 Received: from SZXEML415-HUB.china.huawei.com (10.82.67.154) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 13 Sep 2012 22:58:20 +0800 Received: from szxeml545-mbx.china.huawei.com ([169.254.1.98]) by szxeml415-hub.china.huawei.com ([10.82.67.154]) with mapi id 14.01.0323.003; Thu, 13 Sep 2012 22:58:12 +0800 From: Konstantinos Pentikousis To: "decade@ietf.org" Thread-Topic: DECADE Server Discovery Thread-Index: Ac2RwC2WGSY2z1VtS7iDP+g5hJIzkw== Date: Thu, 13 Sep 2012 14:58:11 +0000 Message-ID: <8D38716F0C1A444BA0CD7E96454366C23A4DCDBA@szxeml545-mbx.china.huawei.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: Ap5h As5h A3nr A4ay BCFF BHlB CQNF Ccbf CxAL DLl1 EDMR GTbf IEWC I0SA JRiq KJUw; 1; ZABlAGMAYQBkAGUAQABpAGUAdABmAC4AbwByAGcA; Sosha1_v1; 7; {35084BB3-CFB9-4581-A6CC-7F6FE1802DF4}; awAuAHAAZQBuAHQAaQBrAG8AdQBzAGkAcwBAAGgAdQBhAHcAZQBpAC4AYwBvAG0A; Thu, 13 Sep 2012 14:58:05 GMT;RABFAEMAQQBEAEUAIABTAGUAcgB2AGUAcgAgAEQAaQBzAGMAbwB2AGUAcgB5AA== x-cr-puzzleid: {35084BB3-CFB9-4581-A6CC-7F6FE1802DF4} x-originating-ip: [10.200.37.56] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [decade] DECADE Server Discovery X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Sep 2012 14:58:47 -0000 Dear All, I just submitted a first draft on DECADE server discovery (http://datatrack= er.ietf.org/doc/draft-pentikousis-decade-discovery) Looking forward to your comments and suggestions. Best Regards, Kostas From haibin.song@huawei.com Mon Sep 17 02:43:30 2012 Return-Path: X-Original-To: decade@ietfa.amsl.com Delivered-To: decade@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FA5421F846D for ; Mon, 17 Sep 2012 02:43:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.595 X-Spam-Level: X-Spam-Status: No, score=-5.595 tagged_above=-999 required=5 tests=[AWL=1.004, 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 EkSLbwLyk76q for ; Mon, 17 Sep 2012 02:43:28 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id BD57421F84A5 for ; Mon, 17 Sep 2012 02:43:27 -0700 (PDT) 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 AJS93898; Mon, 17 Sep 2012 09:43:21 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 17 Sep 2012 10:42:56 +0100 Received: from SZXEML428-HUB.china.huawei.com (10.72.61.36) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 17 Sep 2012 10:43:20 +0100 Received: from SZXEML534-MBX.china.huawei.com ([169.254.2.70]) by szxeml428-hub.china.huawei.com ([10.72.61.36]) with mapi id 14.01.0323.003; Mon, 17 Sep 2012 17:42:47 +0800 From: Songhaibin To: "Rahman, Akbar" , Wangdanhua Thread-Topic: [decade] Open Issue-3 (draft "An HTTP-based DECADE ResourceProtocol") Thread-Index: AQHNkPNHeL+BYmlsWEaxiNEGPOwE1peOTyAA Date: Mon, 17 Sep 2012 09:42:47 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.123] Content-Type: multipart/alternative; boundary="_000_E33E01DFD5BEA24B9F3F18671078951F23B31EAFszxeml534mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "DECADE@ietf.org" Subject: Re: [decade] Open Issue-3 (draft "An HTTP-based DECADE ResourceProtocol") X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Sep 2012 09:43:30 -0000 --_000_E33E01DFD5BEA24B9F3F18671078951F23B31EAFszxeml534mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable While many people advocate Hashed names, the key point is, shall we allow c= onflict for the names? If we do not allow, how to solve it. BR, -Haibin From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.org] On Behalf Of= Rahman, Akbar Sent: Wednesday, September 12, 2012 10:31 PM To: Wangdanhua Cc: DECADE@ietf.org Subject: Re: [decade] Open Issue-3 (draft "An HTTP-based DECADE ResourcePro= tocol") Hi Danhua, Yes, I agree that to make progress on your draft you need to show how to us= e a naming scheme as part of your proposal. And I also agree that using th= e draft-farrell-decade-ni should be the starting point. Sincerely, Akbar From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.org] On Behalf Of= Wangdanhua Sent: Wednesday, September 12, 2012 2:13 AM To: DECADE@ietf.org Subject: [decade] Open Issue-3 (draft "An HTTP-based DECADE ResourceProtoco= l") Hi all, The following is the third open issue left for "An HTTP-based DECADE Resour= ce Protocol" (draft-wang-drp). We're looking forward to your opinions and c= omments. About the object naming scheme used in DECADE Protocol, we're inclined to a= dopting the naming scheme proposed in the draft-farrell-decade-ni (Naming T= hings with Hashes). We thought it's a good scheme and we are planning to ha= ve a try and see whether it's workable in the protocol we proposed. Does anybody have other opinions? And we'd like to hear your voice. Best wishes, Danhua Wang --_000_E33E01DFD5BEA24B9F3F18671078951F23B31EAFszxeml534mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

While m= any people advocate Hashed names, the key point is, shall we allow conflict= for the names? If we do not allow, how to solve it.

&n= bsp;

BR,

-Haibin=

&n= bsp;

From: decade-bounc= es@ietf.org [mailto:decade-bounces@ietf.org] On Behalf Of Rahman, Akbar
Sent: Wednesday, September 12, 2012 10:31 PM
To: Wangdanhua
Cc: DECADE@ietf.org
Subject: Re: [decade] Open Issue-3 (draft "An HTTP-based DECADE= ResourceProtocol")

 

Hi Danhua,

 

Yes, I agree that to make progress on your draft you need to show= how to use a naming scheme as part of your proposal.  And I also agre= e that using the draft-farrell-decade-ni should be the starting point.

 

 

Sincerely,

 

 

Akbar

 

From: decade-bounc= es@ietf.org [mailto:decade-bounces@ietf.org] On Behalf Of Wangdanhua
Sent: Wednesday, September 12, 2012 2:13 AM
To: DECADE@ietf.org
Subject: [decade] Open Issue-3 (draft "An HTTP-based DECADE Res= ourceProtocol")

 

 

Hi all,

 

The following is the third open= issue left for “An HTTP-based DECADE Resource Protocol” (draft= -wang-drp). We’re looking forward to your opinions and comments.=

 

About the object naming scheme = used in DECADE Protocol, we’re inclined to adopting the naming scheme= proposed in the draft-farrell-decade-ni (Naming Things with Hashes). We th= ought it’s a good scheme and we are planning to have a try and see whether it’s workable in the protocol we propo= sed.

 

Does anybody have other opinion= s? And we’d like to hear your voice.

 

Best wishes,<= /p>

Danhua Wang

 

--_000_E33E01DFD5BEA24B9F3F18671078951F23B31EAFszxeml534mbxchi_-- From pzhang.thu@gmail.com Mon Sep 17 23:09:40 2012 Return-Path: X-Original-To: decade@ietfa.amsl.com Delivered-To: decade@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A2D221E80B1 for ; Mon, 17 Sep 2012 23:09:40 -0700 (PDT) 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 T0UNbsuaJRTy for ; Mon, 17 Sep 2012 23:09:39 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id F331321E804A for ; Mon, 17 Sep 2012 23:09:38 -0700 (PDT) Received: by pbbrr4 with SMTP id rr4so10364762pbb.31 for ; Mon, 17 Sep 2012 23:09:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer; bh=rIiyJET0EaHRuZjbARwK5j8DyINNb+oZc4mk/S3kKZs=; b=STF65pPSbTuek4p16yxVg3sDqQuuWFKWKtSZsIemnUHcO64yudXMARpNKJbBEmXNgQ pfZzXXTYOb9gUH+atF2BM5gJqG3qdF5+sZ95A7e5zGgZWOuWApEoL/RrXS/lg8m1bdnr kSkcWDItoa8rmXh815dscB2YTual04C4NWS3LfrheRhNHWy/GCV3KYAnC+O64zt2Wr6w PiocBiKHoWXPcZsCfVRaZlJewy/JjJxchzdayJYCi2oqSTXeKGzgu6waY/Fn2fAzi3CU 7nVEjDk5bDuJupCa4jJtJBcAD+bZZ/nLAcCE32Kc5k2xLE+MJrEiSDvLbDNFouB5WXGD TIOQ== Received: by 10.66.90.1 with SMTP id bs1mr24332401pab.13.1347948578734; Mon, 17 Sep 2012 23:09:38 -0700 (PDT) Received: from tu130206.ip.tsinghua.edu.cn (tu130206.ip.tsinghua.edu.cn. [166.111.130.206]) by mx.google.com with ESMTPS id iq3sm8128548pbc.5.2012.09.17.23.09.36 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 17 Sep 2012 23:09:38 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/alternative; boundary="Apple-Mail=_5C9AF8D4-DC0E-4A79-8AC3-EBCBEC61197D" From: Peng Zhang In-Reply-To: Date: Tue, 18 Sep 2012 14:09:33 +0800 Message-Id: <7B31966F-AA1F-4BBA-9095-0F65053A8F9D@gmail.com> References: To: Songhaibin X-Mailer: Apple Mail (2.1278) Cc: "DECADE@ietf.org" Subject: Re: [decade] Open Issue-3 (draft "An HTTP-based DECADE ResourceProtocol") X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2012 06:09:40 -0000 --Apple-Mail=_5C9AF8D4-DC0E-4A79-8AC3-EBCBEC61197D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Haibin, I don't quite understand your question. If we are using SHA-256, = as suggested in draft-farrell-decade-ni, the probability that two = different objects have the same name would be very low.=20 BR, Peng. On Sep 17, 2012, at 5:42 PM, Songhaibin wrote: > While many people advocate Hashed names, the key point is, shall we = allow conflict for the names? If we do not allow, how to solve it. > =20 > BR, > -Haibin > =20 > From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.org] On = Behalf Of Rahman, Akbar > Sent: Wednesday, September 12, 2012 10:31 PM > To: Wangdanhua > Cc: DECADE@ietf.org > Subject: Re: [decade] Open Issue-3 (draft "An HTTP-based DECADE = ResourceProtocol") > =20 > Hi Danhua, > =20 > Yes, I agree that to make progress on your draft you need to show how = to use a naming scheme as part of your proposal. And I also agree that = using the draft-farrell-decade-ni should be the starting point. > =20 > =20 > Sincerely, > =20 > =20 > Akbar > =20 > From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.org] On = Behalf Of Wangdanhua > Sent: Wednesday, September 12, 2012 2:13 AM > To: DECADE@ietf.org > Subject: [decade] Open Issue-3 (draft "An HTTP-based DECADE = ResourceProtocol") > =20 > =20 > Hi all, > =20 > The following is the third open issue left for =93An HTTP-based DECADE = Resource Protocol=94 (draft-wang-drp). We=92re looking forward to your = opinions and comments. > =20 > About the object naming scheme used in DECADE Protocol, we=92re = inclined to adopting the naming scheme proposed in the = draft-farrell-decade-ni (Naming Things with Hashes). We thought it=92s a = good scheme and we are planning to have a try and see whether it=92s = workable in the protocol we proposed. > =20 > Does anybody have other opinions? And we=92d like to hear your voice. > =20 > Best wishes, > Danhua Wang > =20 --Apple-Mail=_5C9AF8D4-DC0E-4A79-8AC3-EBCBEC61197D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hi Haibin,

I don't = quite understand your question. If we are using SHA-256, as suggested = in 
 decade-bounces@ietf.org [mailto:decade-bounces@ietf.o= rg] On Behalf = Of Rahman, = Akbar
Sent: Wednesday, September 12, = 2012 10:31 PM
To: Wangdanhua
Cc: DECADE@ietf.org
Subject: Re: [decade] Open Issue-3 = (draft "An HTTP-based DECADE = ResourceProtocol")
 
Hi Danhua,
Yes, I agree that to make progress on your draft you = need to show how to use a naming scheme as part of your proposal.  = And I also agree that using the draft-farrell-decade-ni should be the = starting point.
 
Sincerely,
 
 
From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.o= rg] On Behalf = Of Wangdanhua
Sent: Wednesday, September = 12, 2012 2:13 AM
To: DECADE@ietf.org
Subject: [decade] Open Issue-3 = (draft "An HTTP-based DECADE = ResourceProtocol")
 
 
Hi = all,
 
The following is the third open issue = left for =93An HTTP-based DECADE Resource Protocol=94 (draft-wang-drp). = We=92re looking forward to your opinions and = comments.
 
About the = object naming scheme used in DECADE Protocol, we=92re inclined to = adopting the naming scheme proposed in the draft-farrell-decade-ni = (Naming Things with Hashes). We thought it=92s a good scheme and we are = planning to have a try and see whether it=92s workable in the protocol = we proposed.
 
Does anybody = have other opinions? And we=92d like to hear your = voice.
 
Best = wishes,
Danhua = Wang
 

= --Apple-Mail=_5C9AF8D4-DC0E-4A79-8AC3-EBCBEC61197D-- From haibin.song@huawei.com Tue Sep 18 00:09:02 2012 Return-Path: X-Original-To: decade@ietfa.amsl.com Delivered-To: decade@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E5C421E8043 for ; Tue, 18 Sep 2012 00:09:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.762 X-Spam-Level: X-Spam-Status: No, score=-5.762 tagged_above=-999 required=5 tests=[AWL=0.836, 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 wWktE-qjjTG3 for ; Tue, 18 Sep 2012 00:09:00 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id B2B6311E808D for ; Tue, 18 Sep 2012 00:08:59 -0700 (PDT) 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 AKT70983; Tue, 18 Sep 2012 07:08:58 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 18 Sep 2012 08:08:33 +0100 Received: from SZXEML404-HUB.china.huawei.com (10.82.67.59) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 18 Sep 2012 08:08:51 +0100 Received: from SZXEML534-MBX.china.huawei.com ([169.254.2.70]) by szxeml404-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.003; Tue, 18 Sep 2012 15:08:43 +0800 From: Songhaibin To: Peng Zhang Thread-Topic: [decade] Open Issue-3 (draft "An HTTP-based DECADE ResourceProtocol") Thread-Index: AQHNlWQzR+7XvxHv20iTTVNveMuap5ePrAzQ Date: Tue, 18 Sep 2012 07:08:42 +0000 Message-ID: References: <7B31966F-AA1F-4BBA-9095-0F65053A8F9D@gmail.com> In-Reply-To: <7B31966F-AA1F-4BBA-9095-0F65053A8F9D@gmail.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.123] Content-Type: multipart/alternative; boundary="_000_E33E01DFD5BEA24B9F3F18671078951F23B324A9szxeml534mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "DECADE@ietf.org" Subject: Re: [decade] Open Issue-3 (draft "An HTTP-based DECADE ResourceProtocol") X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2012 07:09:02 -0000 --_000_E33E01DFD5BEA24B9F3F18671078951F23B324A9szxeml534mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Peng, "Low" does not mean no existence. I'm wondering if two different objects ar= e happened to have the same name at the same DECADE server, or at different= DECADE servers with different service providers (we require the name to be= global unique), we should have a collision avoidance mechanism for it. -Haibin From: Peng Zhang [mailto:pzhang.thu@gmail.com] Sent: Tuesday, September 18, 2012 2:10 PM To: Songhaibin Cc: Rahman, Akbar; Wangdanhua; DECADE@ietf.org Subject: Re: [decade] Open Issue-3 (draft "An HTTP-based DECADE ResourcePro= tocol") Hi Haibin, I don't quite understand your question. If we are using SHA-256, as su= ggested in draft-farrell-decade-ni, the probability that two different obje= cts have the same name would be very low. BR, Peng. On Sep 17, 2012, at 5:42 PM, Songhaibin wrote: While many people advocate Hashed names, the key point is, shall we allow c= onflict for the names? If we do not allow, how to solve it. BR, -Haibin From: decade-bounces@ietf.org [mailto:decad= e-bounces@ietf.org] On Behalf Of Rahman, Akbar Sent: Wednesday, September 12, 2012 10:31 PM To: Wangdanhua Cc: DECADE@ietf.org Subject: Re: [decade] Open Issue-3 (draft "An HTTP-based DECADE ResourcePro= tocol") Hi Danhua, Yes, I agree that to make progress on your draft you need to show how to us= e a naming scheme as part of your proposal. And I also agree that using th= e draft-farrell-decade-ni should be the starting point. Sincerely, Akbar From: decade-bounces@ietf.org [mailto:decad= e-bounces@ietf.org] On Behalf Of Wangdanhua Sent: Wednesday, September 12, 2012 2:13 AM To: DECADE@ietf.org Subject: [decade] Open Issue-3 (draft "An HTTP-based DECADE ResourceProtoco= l") Hi all, The following is the third open issue left for "An HTTP-based DECADE Resour= ce Protocol" (draft-wang-drp). We're looking forward to your opinions and c= omments. About the object naming scheme used in DECADE Protocol, we're inclined to a= dopting the naming scheme proposed in the draft-farrell-decade-ni (Naming T= hings with Hashes). We thought it's a good scheme and we are planning to ha= ve a try and see whether it's workable in the protocol we proposed. Does anybody have other opinions? And we'd like to hear your voice. Best wishes, Danhua Wang --_000_E33E01DFD5BEA24B9F3F18671078951F23B324A9szxeml534mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Peng,

 = ;

“Low= ” does not mean no existence. I’m wondering if two different ob= jects are happened to have the same name at the same DECADE server, or at d= ifferent DECADE servers with different service providers (we require the name to be= global unique), we should have a collision avoidance mechanism for it.

 = ;

-Haibin

 = ;

 = ;

From: Peng Zhang [mailto:pzhang.thu@gmail.com]
Sent: Tuesday, September 18, 2012 2:10 PM
To: Songhaibin
Cc: Rahman, Akbar; Wangdanhua; DECADE@ietf.org
Subject: Re: [decade] Open Issue-3 (draft "An HTTP-based DECADE= ResourceProtocol")

 

Hi Haibin,

 

=      I don't quite understand your question. If we a= re using SHA-256, as suggested in draft-farrell-decade-ni, the probability that two different objects have the same name would be ver= y low. 

 

BR,

 

Peng.

 

On Sep 17, 2012, at 5:42 PM, So= nghaibin wrote:



While many people advocate = Hashed names, the key point is, shall we allow conflict for the names? If we do not allow, how to solve it.

 

BR,

-Haibin

 

From: d= ecade-bounces@ietf.org [mailto:decade-bounces@ietf.org]&nb= sp;On Behalf Of Rahman, Ak= bar
Sent: Wednesday, S= eptember 12, 2012 10:31 PM
To: Wangdanhua
Cc: DECADE@ietf.org
Subject: Re: [deca= de] Open Issue-3 (draft "An HTTP-based DECADE ResourceProtocol")<= /span>

 =

Hi Danhua,

 

Yes, I agree that to make p= rogress on your draft you need to show how to use a naming scheme as part of your proposal.  And I also agree that using the draft-farr= ell-decade-ni should be the starting point.

 

 

Sincerely,

 

 

Akbar

 

From: d= ecade-bounces@ietf.org [mailto:decade-bounces@ietf.org]&nb= sp;On Behalf Of Wangdanhua=
Sent: Wednesday, S= eptember 12, 2012 2:13 AM
To: DECADE@ietf.org
Subject: [decade] = Open Issue-3 (draft "An HTTP-based DECADE ResourceProtocol")

 =

 

Hi all,

 

The following is the third open issue lef= t for “An HTTP-based DECADE Resource Protocol” (draft-wang-drp)= . We’re looking forward to your opinions and comments.

 

About the object naming scheme used in DE= CADE Protocol, we’re inclined to adopting the naming scheme proposed in the draft-farrell-decade-ni (Naming Things with Hashes). We th= ought it’s a good scheme and we are planning to have a try and see wh= ether it’s workable in the protocol we proposed.

 

Does anybody have other opinions? And we&= #8217;d like to hear your voice.

 

Best wishes,

Danhua Wang

 

 

--_000_E33E01DFD5BEA24B9F3F18671078951F23B324A9szxeml534mbxchi_-- From stephen.farrell@cs.tcd.ie Tue Sep 18 01:34:19 2012 Return-Path: X-Original-To: decade@ietfa.amsl.com Delivered-To: decade@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0922421F8780 for ; Tue, 18 Sep 2012 01:34:19 -0700 (PDT) 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 OHkPft+NGW51 for ; Tue, 18 Sep 2012 01:34:18 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 47A9021F877F for ; Tue, 18 Sep 2012 01:34:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id E4992171480; Tue, 18 Sep 2012 09:34:12 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1347957252; bh=+2l6YtjJAKgPmF IR0k+poeJ5f3bVbyiUEA70j4+uhl0=; b=PB4GM1g0Vre4LgduoD2f97kKLUrxrz OlwIlrGCwMKYJS0QuIeYyN1IEahNop/SuJNYIB8Y2mOALp2wNge4Nww+t6jUKpak r1cV1MdVUIe9ibtVicGT9MJ8NjhEqDqQ/nvBqCGuCMAPJJYHGgjaTzA31fmQoPhB 25YiTKrzZjmO8obofImzxc1JNDIrygLDvg/aDPfeYJ8UpAaY1uAXgDbPndpdGf0k G/+SZZR+QlUqR4yVBAOkUXe4vAog8Zr4uPWDHt1GA+oUdnAx30Jacf43/sqyeIGE l4vFmNxVzyPrBvI/IGmfh3lK2XYZlKB5aiwxq0MkR7dJ7dmPHjnwWBqg== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id 67hot9uUfF4Q; Tue, 18 Sep 2012 09:34:12 +0100 (IST) Received: from [192.6.10.155] (bri-event-56.hpl.hp.com [192.6.10.155]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id E7AF0171476; Tue, 18 Sep 2012 09:34:02 +0100 (IST) Message-ID: <505831F8.3010209@cs.tcd.ie> Date: Tue, 18 Sep 2012 09:34:00 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0 MIME-Version: 1.0 To: Songhaibin References: <7B31966F-AA1F-4BBA-9095-0F65053A8F9D@gmail.com> In-Reply-To: X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "DECADE@ietf.org" Subject: Re: [decade] Open Issue-3 (draft "An HTTP-based DECADE ResourceProtocol") X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2012 08:34:19 -0000 On 09/18/2012 08:08 AM, Songhaibin wrote: > Hi Peng, > > "Low" does not mean no existence. I'm wondering if two different objects are happened to have the same name at the same DECADE server, or at different DECADE servers with different service providers (we require the name to be global unique), we should have a collision avoidance mechanism for it. The existence of SHA256 collisions would be news that would make CNN and BBC probably (after they picked it up from /.:-). In this case "low" is practically the same as non-existent if you use all the bits of SHA256. S. > -Haibin > > > From: Peng Zhang [mailto:pzhang.thu@gmail.com] > Sent: Tuesday, September 18, 2012 2:10 PM > To: Songhaibin > Cc: Rahman, Akbar; Wangdanhua; DECADE@ietf.org > Subject: Re: [decade] Open Issue-3 (draft "An HTTP-based DECADE ResourceProtocol") > > Hi Haibin, > > I don't quite understand your question. If we are using SHA-256, as suggested in draft-farrell-decade-ni, the probability that two different objects have the same name would be very low. > > BR, > > Peng. > > On Sep 17, 2012, at 5:42 PM, Songhaibin wrote: > > > While many people advocate Hashed names, the key point is, shall we allow conflict for the names? If we do not allow, how to solve it. > > BR, > -Haibin > > From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.org] On Behalf Of Rahman, Akbar > Sent: Wednesday, September 12, 2012 10:31 PM > To: Wangdanhua > Cc: DECADE@ietf.org > Subject: Re: [decade] Open Issue-3 (draft "An HTTP-based DECADE ResourceProtocol") > > Hi Danhua, > > Yes, I agree that to make progress on your draft you need to show how to use a naming scheme as part of your proposal. And I also agree that using the draft-farrell-decade-ni should be the starting point. > > > Sincerely, > > > Akbar > > From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.org] On Behalf Of Wangdanhua > Sent: Wednesday, September 12, 2012 2:13 AM > To: DECADE@ietf.org > Subject: [decade] Open Issue-3 (draft "An HTTP-based DECADE ResourceProtocol") > > > Hi all, > > The following is the third open issue left for "An HTTP-based DECADE Resource Protocol" (draft-wang-drp). We're looking forward to your opinions and comments. > > About the object naming scheme used in DECADE Protocol, we're inclined to adopting the naming scheme proposed in the draft-farrell-decade-ni (Naming Things with Hashes). We thought it's a good scheme and we are planning to have a try and see whether it's workable in the protocol we proposed. > > Does anybody have other opinions? And we'd like to hear your voice. > > Best wishes, > Danhua Wang > > > From pzhang.thu@gmail.com Tue Sep 18 01:48:14 2012 Return-Path: X-Original-To: decade@ietfa.amsl.com Delivered-To: decade@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B982121F878A for ; Tue, 18 Sep 2012 01:48:14 -0700 (PDT) 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 FMO8iAw-kRzM for ; Tue, 18 Sep 2012 01:48:14 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2C23C21F8783 for ; Tue, 18 Sep 2012 01:48:14 -0700 (PDT) Received: by pbbrr4 with SMTP id rr4so10646410pbb.31 for ; Tue, 18 Sep 2012 01:48:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=v8vZBabiNaGl67lKGHZRrvUl9e1vvTV+vrwHd65nq3E=; b=t8jBJPayOicMwGVfoa0MaKBwEyfnW2pttJpTNgla1pwz/cx2J7rcs7e5rtA7xb/44y WD6WDUEFEzb7b6D3n+TkCY68BR/1LzlJpFW1D1SxvYBXQZ/P+dXdkl+NVqlX9PAN0D3X zunSqqrH5rHtHwvaa2tOrEaK9h+BZpVvJju/xXPuLOKFqZXjUnqQqXV7aya0pJzX8JBA z3MTjL6GXuPs3Ka7CHzlYdo2uCGFMKW/4sC9reZAPr5fzSLYS4ujpviiEdHyDrWbZ2TF 6DEVwHLfO5wzuqClaQrser2eLiiCpJwH2sYMAEP2EQsvlILNUN6GRf0PL8nkjO8NV2M/ rgHg== Received: by 10.68.138.166 with SMTP id qr6mr42582pbb.69.1347958093968; Tue, 18 Sep 2012 01:48:13 -0700 (PDT) Received: from tu130206.ip.tsinghua.edu.cn (tu130206.ip.tsinghua.edu.cn. [166.111.130.206]) by mx.google.com with ESMTPS id py9sm8314591pbb.20.2012.09.18.01.48.11 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 18 Sep 2012 01:48:13 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: Peng Zhang In-Reply-To: <505831F8.3010209@cs.tcd.ie> Date: Tue, 18 Sep 2012 16:48:08 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: <6EB5BD9B-F14B-4FEB-94DE-B65E9C7DDEA9@gmail.com> References: <7B31966F-AA1F-4BBA-9095-0F65053A8F9D@gmail.com> <505831F8.3010209@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.1278) Cc: "DECADE@ietf.org" Subject: Re: [decade] Open Issue-3 (draft "An HTTP-based DECADE ResourceProtocol") X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2012 08:48:14 -0000 Exactly, the probability would be negligible. Even if we use the trunked = hash, say 32 bit, it would suffice too. BR, Peng. On Sep 18, 2012, at 4:34 PM, Stephen Farrell wrote: >=20 >=20 > On 09/18/2012 08:08 AM, Songhaibin wrote: >> Hi Peng, >>=20 >> "Low" does not mean no existence. I'm wondering if two different = objects are happened to have the same name at the same DECADE server, or = at different DECADE servers with different service providers (we require = the name to be global unique), we should have a collision avoidance = mechanism for it. >=20 > The existence of SHA256 collisions would be news that would make > CNN and BBC probably (after they picked it up from /.:-). In > this case "low" is practically the same as non-existent if you > use all the bits of SHA256. >=20 > S. >=20 >> -Haibin >>=20 >>=20 >> From: Peng Zhang [mailto:pzhang.thu@gmail.com] >> Sent: Tuesday, September 18, 2012 2:10 PM >> To: Songhaibin >> Cc: Rahman, Akbar; Wangdanhua; DECADE@ietf.org >> Subject: Re: [decade] Open Issue-3 (draft "An HTTP-based DECADE = ResourceProtocol") >>=20 >> Hi Haibin, >>=20 >> I don't quite understand your question. If we are using SHA-256, = as suggested in draft-farrell-decade-ni, the probability that two = different objects have the same name would be very low. >>=20 >> BR, >>=20 >> Peng. >>=20 >> On Sep 17, 2012, at 5:42 PM, Songhaibin wrote: >>=20 >>=20 >> While many people advocate Hashed names, the key point is, shall we = allow conflict for the names? If we do not allow, how to solve it. >>=20 >> BR, >> -Haibin >>=20 >> From: decade-bounces@ietf.org = [mailto:decade-bounces@ietf.org] On Behalf Of Rahman, Akbar >> Sent: Wednesday, September 12, 2012 10:31 PM >> To: Wangdanhua >> Cc: DECADE@ietf.org >> Subject: Re: [decade] Open Issue-3 (draft "An HTTP-based DECADE = ResourceProtocol") >>=20 >> Hi Danhua, >>=20 >> Yes, I agree that to make progress on your draft you need to show how = to use a naming scheme as part of your proposal. And I also agree that = using the draft-farrell-decade-ni should be the starting point. >>=20 >>=20 >> Sincerely, >>=20 >>=20 >> Akbar >>=20 >> From: decade-bounces@ietf.org = [mailto:decade-bounces@ietf.org] On Behalf Of Wangdanhua >> Sent: Wednesday, September 12, 2012 2:13 AM >> To: DECADE@ietf.org >> Subject: [decade] Open Issue-3 (draft "An HTTP-based DECADE = ResourceProtocol") >>=20 >>=20 >> Hi all, >>=20 >> The following is the third open issue left for "An HTTP-based DECADE = Resource Protocol" (draft-wang-drp). We're looking forward to your = opinions and comments. >>=20 >> About the object naming scheme used in DECADE Protocol, we're = inclined to adopting the naming scheme proposed in the = draft-farrell-decade-ni (Naming Things with Hashes). We thought it's a = good scheme and we are planning to have a try and see whether it's = workable in the protocol we proposed. >>=20 >> Does anybody have other opinions? And we'd like to hear your voice. >>=20 >> Best wishes, >> Danhua Wang >>=20 >>=20 >>=20 From stephen.farrell@cs.tcd.ie Tue Sep 18 01:57:55 2012 Return-Path: X-Original-To: decade@ietfa.amsl.com Delivered-To: decade@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D038C21F8466 for ; Tue, 18 Sep 2012 01:57:55 -0700 (PDT) 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 d35OTWQBt6VY for ; Tue, 18 Sep 2012 01:57:55 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id E285D21F8422 for ; Tue, 18 Sep 2012 01:57:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 56CAB171480; Tue, 18 Sep 2012 09:57:54 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1347958673; bh=b6ZjbsvpR9fxoH qum0+6D4uBAeIEOEwEvSBkLdlMaTE=; b=b4IyesWlxZkDNVwrg1ZFmjCN5u0Wn+ DuGsCuEwP9wStrNGuFUt7803wYVPZ97/sn9CMF/U62ZlaWTnMOpCqaxjAO11XExQ zzlMqS0JUkeMRhdAorVFvJrSY7gNM2Xzwmn279SzUvVP5gV/fMGK143p0ZpxYc+9 Pr5Bxj4BsA311bWG4ImVeooMhL0qEb4wMNWDOmxQelomo1vWCtqYoVAo4l3LfmmX XgTZzp+YwPvXgrJ/Md+yzceLuuDQTartjDP/WjuOHFIyiWC7TIdAhQIAyyyiM+Wo f/6vsgYWr1/epEFlfoCXPF0ZZ9saU4y4jf/Dj4KJnrSHolI4x3PbcRTg== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id zki8Z1oFhNc4; Tue, 18 Sep 2012 09:57:53 +0100 (IST) Received: from [192.6.10.155] (bri-event-56.hpl.hp.com [192.6.10.155]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id B9615171476; Tue, 18 Sep 2012 09:57:53 +0100 (IST) Message-ID: <50583791.1040704@cs.tcd.ie> Date: Tue, 18 Sep 2012 09:57:53 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0 MIME-Version: 1.0 To: Peng Zhang References: <7B31966F-AA1F-4BBA-9095-0F65053A8F9D@gmail.com> <505831F8.3010209@cs.tcd.ie> <6EB5BD9B-F14B-4FEB-94DE-B65E9C7DDEA9@gmail.com> In-Reply-To: <6EB5BD9B-F14B-4FEB-94DE-B65E9C7DDEA9@gmail.com> X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "DECADE@ietf.org" Subject: Re: [decade] Open Issue-3 (draft "An HTTP-based DECADE ResourceProtocol") X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2012 08:57:55 -0000 On 09/18/2012 09:48 AM, Peng Zhang wrote: > Exactly, the probability would be negligible. Even if we use the trunked hash, say 32 bit, it would suffice too. Not sure about that. For collisions you need to think about the birthday problem, so a 32 bit hash may mean a 2^-16 collision probability which is probably too high in many cases. Either don't truncate at all or think deeply about it first is the right approach I'd say. S. > BR, > > Peng. > > On Sep 18, 2012, at 4:34 PM, Stephen Farrell wrote: > >> >> >> On 09/18/2012 08:08 AM, Songhaibin wrote: >>> Hi Peng, >>> >>> "Low" does not mean no existence. I'm wondering if two different objects are happened to have the same name at the same DECADE server, or at different DECADE servers with different service providers (we require the name to be global unique), we should have a collision avoidance mechanism for it. >> >> The existence of SHA256 collisions would be news that would make >> CNN and BBC probably (after they picked it up from /.:-). In >> this case "low" is practically the same as non-existent if you >> use all the bits of SHA256. >> >> S. >> >>> -Haibin >>> >>> >>> From: Peng Zhang [mailto:pzhang.thu@gmail.com] >>> Sent: Tuesday, September 18, 2012 2:10 PM >>> To: Songhaibin >>> Cc: Rahman, Akbar; Wangdanhua; DECADE@ietf.org >>> Subject: Re: [decade] Open Issue-3 (draft "An HTTP-based DECADE ResourceProtocol") >>> >>> Hi Haibin, >>> >>> I don't quite understand your question. If we are using SHA-256, as suggested in draft-farrell-decade-ni, the probability that two different objects have the same name would be very low. >>> >>> BR, >>> >>> Peng. >>> >>> On Sep 17, 2012, at 5:42 PM, Songhaibin wrote: >>> >>> >>> While many people advocate Hashed names, the key point is, shall we allow conflict for the names? If we do not allow, how to solve it. >>> >>> BR, >>> -Haibin >>> >>> From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.org] On Behalf Of Rahman, Akbar >>> Sent: Wednesday, September 12, 2012 10:31 PM >>> To: Wangdanhua >>> Cc: DECADE@ietf.org >>> Subject: Re: [decade] Open Issue-3 (draft "An HTTP-based DECADE ResourceProtocol") >>> >>> Hi Danhua, >>> >>> Yes, I agree that to make progress on your draft you need to show how to use a naming scheme as part of your proposal. And I also agree that using the draft-farrell-decade-ni should be the starting point. >>> >>> >>> Sincerely, >>> >>> >>> Akbar >>> >>> From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.org] On Behalf Of Wangdanhua >>> Sent: Wednesday, September 12, 2012 2:13 AM >>> To: DECADE@ietf.org >>> Subject: [decade] Open Issue-3 (draft "An HTTP-based DECADE ResourceProtocol") >>> >>> >>> Hi all, >>> >>> The following is the third open issue left for "An HTTP-based DECADE Resource Protocol" (draft-wang-drp). We're looking forward to your opinions and comments. >>> >>> About the object naming scheme used in DECADE Protocol, we're inclined to adopting the naming scheme proposed in the draft-farrell-decade-ni (Naming Things with Hashes). We thought it's a good scheme and we are planning to have a try and see whether it's workable in the protocol we proposed. >>> >>> Does anybody have other opinions? And we'd like to hear your voice. >>> >>> Best wishes, >>> Danhua Wang >>> >>> >>> > > > From iesg-secretary@ietf.org Wed Sep 19 16:03:14 2012 Return-Path: X-Original-To: decade@ietfa.amsl.com Delivered-To: decade@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F69E21E8051; Wed, 19 Sep 2012 16:03:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.538 X-Spam-Level: X-Spam-Status: No, score=-102.538 tagged_above=-999 required=5 tests=[AWL=0.062, 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 V63J9bBti2Po; Wed, 19 Sep 2012 16:03:13 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BC3F21F84FD; Wed, 19 Sep 2012 16:03:13 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: IESG Secretary To: IETF Announcement List X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20120919230313.17329.44102.idtracker@ietfa.amsl.com> Date: Wed, 19 Sep 2012 16:03:13 -0700 Cc: decade@ietf.org Subject: [decade] WG Action: Conclusion of Decoupled Application Data Enroute (decade) X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Sep 2012 23:03:14 -0000 The Decoupled Application Data Enroute (decade) working group in the = Transport Area has concluded. The IESG contact persons are Martin = Stiemerling and Wesley Eddy. The DECADE working group will be closed after having completed the below listed RFCs, but before finishing all of its chartered documents. The DECADE WG has reached the point where it is evident that the chartered work cannot be completed at a technical level suitable for the coming steps of the protocol definition and also within an appropriate time frame. The list of published RFCs: - RFC 6392 - RFC 6646 Thank you to all contributors, draft authors, and the chairs. The DECADE mailing list (decade@ietf.org) will remain open. From wangdanhua@huawei.com Thu Sep 20 02:09:01 2012 Return-Path: X-Original-To: decade@ietfa.amsl.com Delivered-To: decade@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 141E821F86EA for ; Thu, 20 Sep 2012 02:09:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.949 X-Spam-Level: X-Spam-Status: No, score=-4.949 tagged_above=-999 required=5 tests=[AWL=1.649, 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 CLP4gu9QLT0B for ; Thu, 20 Sep 2012 02:09:00 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id E5B2421F86EB for ; Thu, 20 Sep 2012 02:08:59 -0700 (PDT) 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 AJV75941; Thu, 20 Sep 2012 09:08:56 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 20 Sep 2012 10:08:11 +0100 Received: from SZXEML419-HUB.china.huawei.com (10.82.67.158) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 20 Sep 2012 10:08:44 +0100 Received: from SZXEML507-MBS.china.huawei.com ([169.254.7.120]) by szxeml419-hub.china.huawei.com ([10.82.67.158]) with mapi id 14.01.0323.003; Thu, 20 Sep 2012 17:08:30 +0800 From: Wangdanhua To: "DECADE@ietf.org" Thread-Topic: Open Issue-4 (draft "An HTTP-based DECADE ResourceProtocol") Thread-Index: Ac2XD3/qQWNlzkJ7RF6MHYNtHO16vw== Date: Thu, 20 Sep 2012 09:08:30 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.177] Content-Type: multipart/alternative; boundary="_000_AFD688AF30E249418739DBDC55B9C75B34D7C893SZXEML507MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [decade] Open Issue-4 (draft "An HTTP-based DECADE ResourceProtocol") X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2012 09:09:01 -0000 --_000_AFD688AF30E249418739DBDC55B9C75B34D7C893SZXEML507MBSchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, The following is the forth open issue left for "An HTTP-based DECADE Resour= ce Protocol" (draft-wang-drp). As to SDT, we'd like to support both push mode and pull mode while DECADE C= lient gets data object from its DECADE Server. If so, subscription mode has= to be introduced in DECADE. Do you think it's necessary to include both these two modes or just pull mo= de is enough? We're looking forward to your opinions and comments. Thanks! Best wishes, Danhua --_000_AFD688AF30E249418739DBDC55B9C75B34D7C893SZXEML507MBSchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 

The following is the forth open= issue left for “An HTTP-based DECADE Resource Protocol” (draft= -wang-drp).

 

As to SDT, we’d like to support both push mode and = pull mode while DECADE Client gets data object from its DECADE Server. If s= o, subscription mode has to be introduced

in DECADE.

 

Do you think it’s necessa= ry to include both these two modes or just pull mode is enough? We’re= looking forward to your opinions and comments.

 

Thanks!

 

Best wishes,<= /p>

Danhua

 

--_000_AFD688AF30E249418739DBDC55B9C75B34D7C893SZXEML507MBSchi_-- From zhangyunfei@chinamobile.com Thu Sep 20 02:34:11 2012 Return-Path: X-Original-To: decade@ietfa.amsl.com Delivered-To: decade@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9888A21F8704 for ; Thu, 20 Sep 2012 02:34:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.378 X-Spam-Level: X-Spam-Status: No, score=-96.378 tagged_above=-999 required=5 tests=[AWL=0.386, BAYES_20=-0.74, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, RELAY_IS_221=2.222, 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 P4+lWxbR85cQ for ; Thu, 20 Sep 2012 02:34:11 -0700 (PDT) Received: from imss.chinamobile.com (imss.chinamobile.com [221.130.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id BE63C21F8701 for ; Thu, 20 Sep 2012 02:34:10 -0700 (PDT) Received: from imss.chinamobile.com (localhost [127.0.0.1]) by localhost.chinamobile.com (Postfix) with ESMTP id 4375DE684; Thu, 20 Sep 2012 17:34:10 +0800 (CST) Received: from mail.chinamobile.com (unknown [10.1.28.22]) by imss.chinamobile.com (Postfix) with ESMTP id CCAB1E678; Thu, 20 Sep 2012 17:34:09 +0800 (CST) Received: from zyf-PC ([10.2.54.163]) by mail.chinamobile.com (Lotus Domino Release 6.5.6) with ESMTP id 2012092017340544-21192 ; Thu, 20 Sep 2012 17:34:05 +0800 Date: Thu, 20 Sep 2012 17:33:55 +0800 From: zhangyunfei To: Wangdanhua , decade References: X-Priority: 3 (Normal) X-Mailer: Foxmail 7.0.1.85[cn] Mime-Version: 1.0 Message-ID: <2012092017335583939015@chinamobile.com> X-MIMETrack: Itemize by SMTP Server on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2012-09-20 17:34:07, Serialize by Router on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2012-09-20 17:34:09, Serialize complete at 2012-09-20 17:34:09 Content-Type: multipart/alternative; boundary="----=_001_NextPart708023327108_=----" X-TM-AS-Product-Ver: IMSS-7.0.0.8231-6.8.0.1017-19196.000 X-TM-AS-Result: No--30.639-7.0-31-10 X-imss-scan-details: No--30.639-7.0-31-10;No--30.639-7.0-31-10 X-TM-AS-User-Approved-Sender: No;No X-TM-AS-User-Blocked-Sender: No;No Subject: Re: [decade] Open Issue-4 (draft "An HTTP-based DECADE ResourceProtocol") X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: zhangyunfei List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2012 09:34:11 -0000 This is a multi-part message in MIME format. ------=_001_NextPart708023327108_=---- Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="gb2312" SGkgRGFuaHVhLA0KICAgQ291bGQgeW91IGVsYWJvcmF0ZSB5b3VyIGltYWdpbmF0aW9uIG9uIHRo ZSB1c2UgY2FzZSBvZiB0aGUgcHVzaCBtb2RlIFNEVD8gRm9yIG1lIGl0IHNlZW1zIG9rYXkgdG8g dXNlIHB1c2ggbW9kZSAgZm9yIHB1Ymxpc2gvc3Vic2NyaWJlIGFwcHMsIGUuZy4sIHRoZSBERUNB REUgc2VydmVyLCBvbiBiZWhhbGYgb2YgREVDQURFIGNsaWVudCwgc3Vic2NyaWJlcyBhIG1hZ2F6 aW5lIGFuZCBvbmx5IG5vdGlmaWVzIHRoZSBERUNBREUgY2xpZW50IGluIGNhc2Ugb2YgZ29vZCBu ZXR3b3JrIGNvbmRpdGlvbi4NCg0KQlINCll1bmZlaQ0KDQoNCg0KDQp6aGFuZ3l1bmZlaQ0KDQpG cm9tOiBXYW5nZGFuaHVhDQpEYXRlOiAyMDEyLTA5LTIwIDE3OjA4DQpUbzogREVDQURFQGlldGYu b3JnDQpTdWJqZWN0OiBbZGVjYWRlXSBPcGVuIElzc3VlLTQgKGRyYWZ0ICJBbiBIVFRQLWJhc2Vk IERFQ0FERSBSZXNvdXJjZVByb3RvY29sIikNCkhpIGFsbCwNCiANClRoZSBmb2xsb3dpbmcgaXMg dGhlIGZvcnRoIG9wZW4gaXNzdWUgbGVmdCBmb3IgobBBbiBIVFRQLWJhc2VkIERFQ0FERSBSZXNv dXJjZSBQcm90b2NvbKGxIChkcmFmdC13YW5nLWRycCkuIA0KIA0KQXMgdG8gU0RULCB3ZaGvZCBs aWtlIHRvIHN1cHBvcnQgYm90aCBwdXNoIG1vZGUgYW5kIHB1bGwgbW9kZSB3aGlsZSBERUNBREUg Q2xpZW50IGdldHMgZGF0YSBvYmplY3QgZnJvbSBpdHMgREVDQURFIFNlcnZlci4gSWYgc28sIHN1 YnNjcmlwdGlvbiBtb2RlIGhhcyB0byBiZSBpbnRyb2R1Y2VkDQppbiBERUNBREUuIA0KIA0KRG8g eW91IHRoaW5rIGl0oa9zIG5lY2Vzc2FyeSB0byBpbmNsdWRlIGJvdGggdGhlc2UgdHdvIG1vZGVz IG9yIGp1c3QgcHVsbCBtb2RlIGlzIGVub3VnaD8gV2Whr3JlIGxvb2tpbmcgZm9yd2FyZCB0byB5 b3VyIG9waW5pb25zIGFuZCBjb21tZW50cy4NCiANClRoYW5rcyENCiANCkJlc3Qgd2lzaGVzLA0K RGFuaHVhIA0KIA== ------=_001_NextPart708023327108_=---- Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="gb2312"
Hi Danhua,
   Could you elaborate your imagination on the use case of = the=20 push mode SDT? For me it seems okay to use push mode  for=20 publish/subscribe apps, e.g., the DECADE server, on behalf of DECADE=20 client, subscribes a magazine and only notifies the DECADE client in case = of=20 good network condition.
 
BR
Yunfei
 
zhangyunfei
 
From: Wangdanhua
Date: 2012-09-20 17:08
Subject: [decade] Open Issue-4 (draft "An HTTP-based DECA= DE=20 ResourceProtocol")

Hi all,

 

The following is the forth open is= sue left=20 for =A1=B0An HTTP-based DECADE Resource Protocol=A1=B1 (draft-wang-drp).=20

 

<= SPAN=20 lang=3DEN-US>As to SDT, we=A1=AFd like to support both push mode and pull = mode while=20 DECADE Client gets data object from its DECADE Server. If so, subscription= mode=20 has to be introduced

<= SPAN=20 lang=3DEN-US>in DECADE.

 

Do you think it=A1=AFs necessary t= o include both=20 these two modes or just pull mode is enough? We=A1=AFre looking forward to= your=20 opinions and comments.

 

Thanks!

 

Best wishes,

Danhua

 

------=_001_NextPart708023327108_=------ From Martin.Stiemerling@neclab.eu Thu Sep 20 02:53:32 2012 Return-Path: X-Original-To: decade@ietfa.amsl.com Delivered-To: decade@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25DBF21F8773 for ; Thu, 20 Sep 2012 02:53:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.387 X-Spam-Level: X-Spam-Status: No, score=-102.387 tagged_above=-999 required=5 tests=[AWL=0.212, 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 DmOSA+W+6sk4 for ; Thu, 20 Sep 2012 02:53:31 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id ADDDA21F846F for ; Thu, 20 Sep 2012 02:53:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id AFE87101ECA for ; Thu, 20 Sep 2012 11:53:29 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GNUHOLNDRFvi for ; Thu, 20 Sep 2012 11:53:29 +0200 (CEST) Received: from ENCELADUS.office.hd (enceladus.office.hd [192.168.24.52]) by mailer1.neclab.eu (Postfix) with ESMTP id 972E5101EC8 for ; Thu, 20 Sep 2012 11:53:24 +0200 (CEST) Received: from [10.1.1.190] (10.1.1.190) by skoll.office.hd (192.168.125.11) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 20 Sep 2012 11:53:21 +0200 Message-ID: <505AE794.8070304@neclab.eu> Date: Thu, 20 Sep 2012 11:53:24 +0200 From: Martin Stiemerling User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0 MIME-Version: 1.0 To: References: <20120919230313.17329.44102.idtracker@ietfa.amsl.com> In-Reply-To: <20120919230313.17329.44102.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.1.1.190] Subject: Re: [decade] WG Action: Conclusion of Decoupled Application Data Enroute (decade) X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2012 09:53:33 -0000 Dear all, The DECADE working group has just been closed by your responsible Area Director. This may come as a surprise to some in the WG, but it should not be a surprise for the working drafts authors. The chairs have been notified in advance about this action. There has been significant feedback from the community that questioned the technical status of DECADE in the recent past. These concerns were not been taken up and were not addressed. The working group did made only small progress in the last six months, which was visible in the low amount of emails on the list, though there are a number of issues that should have been discussed. The WG chairs were explicitly notified in mid of June that there are severe issues and the WG had time to address those issues. However, it must have been obvious even before mid of June that there are severe issues, i.e., there has been sufficient time to fix it. Furthermore, the requirements and architecture draft were submitted to the IESG for publication and both drafts have been returned to the WG, as both are not ready to be published as RFC. You can find the AD review in the datatracker: - https://datatracker.ietf.org/doc/draft-ietf-decade-reqs/history/ - https://datatracker.ietf.org/doc/draft-ietf-decade-arch/history/ Both drafts do leave any number of key questions unanswered, i.e., they are far away from being technically useful to be the base for the next steps in the protocol development. To give 2 examples: 1) It is completely unclear how the resources on a DECADE server are supposed to be managed and how this management is mapped to the protocol split of SDT, DRP, and other management protocols. Parts of it, such as setting the permissions of data objects clearly belongs to the DRP, and it is sort of stated in a vague way in the architecture, but it is not documented in a comprehensive way. Other parts, such as the accounting is probably not part of the the DRP nor SDT, but there is supposedly another interface that is needed for this. 2) What is the model how data objects are handled on the server in the sense about who is allowed to do what? The drafts solely talk about tokens to be used to do access control. But there other aspects, for instance, who is controlling what on a DECADE server: The DECADE server can be operated by an ISP, but the content is provided by a content provider and it is access by an unlimited set of clients or limited set of clients. How is the access control divided between those parties? To conclude this email: The DECADE group started its work in end of April 2010 and is now working for more than 2 years on the milestones and drafts. The time isn't a big deal, but after 2 years I would have expected that the documents are on a good technical level where the WG can build on top of. Some of you probably ask how the remaining drafts are handled: First of all, they are not working groups drafts anymore. But you may resubmit those drafts as individual submissions, address the review received so far, e.g., Dave Crocker's, Carsten Bormann's, and the AD reviews. Ask for feedback again, if you have addressed the reviews in your updated drafts. If you believe that the drafts are solid work, with a base for further protocol development, you may consider to submit the drafts via the RFC editor's Independent Stream. The decisions to close the WG can be of course appealed via the IETF appeal process: See 'Appeals and PR-Actions' under http://www.ietf.org/iesg/ and RFC 2026. Regards, Martin -- IETF Transport Area Director martin.stiemerling@neclab.eu NEC Laboratories Europe - Network Research Division NEC Europe Limited Registered Office: NEC House, 1 Victoria Road, London W3 6BL Registered in England 283 On 09/20/2012 01:03 AM, IESG Secretary wrote: > The Decoupled Application Data Enroute (decade) working group in the > Transport Area has concluded. The IESG contact persons are Martin > Stiemerling and Wesley Eddy. > > The DECADE working group will be closed after having completed the below > listed RFCs, but before finishing all of its chartered documents. > > The DECADE WG has reached the point where it is evident that the > chartered work cannot be completed at a technical level suitable for the > coming steps of the protocol definition and also within an appropriate > time frame. > > The list of published RFCs: > - RFC 6392 > - RFC 6646 > > Thank you to all contributors, draft authors, and the chairs. > > The DECADE mailing list (decade@ietf.org) will remain open. > From k.pentikousis@huawei.com Fri Sep 21 05:15:39 2012 Return-Path: X-Original-To: decade@ietfa.amsl.com Delivered-To: decade@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48D9821F8806 for ; Fri, 21 Sep 2012 05:15:39 -0700 (PDT) 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 xZ2kE7pj--qi for ; Fri, 21 Sep 2012 05:15:38 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 2663821F873C for ; Fri, 21 Sep 2012 05:15:37 -0700 (PDT) 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 AJW79360; Fri, 21 Sep 2012 12:15:36 +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; Fri, 21 Sep 2012 13:14:47 +0100 Received: from SZXEML401-HUB.china.huawei.com (10.82.67.31) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 21 Sep 2012 13:15:14 +0100 Received: from szxeml545-mbx.china.huawei.com ([169.254.1.98]) by szxeml401-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.003; Fri, 21 Sep 2012 20:15:07 +0800 From: Konstantinos Pentikousis To: Martin Stiemerling , "decade@ietf.org" Thread-Topic: [decade] WG Action: Conclusion of Decoupled Application Data Enroute (decade) Thread-Index: AQHNl2Kl6GCO1u70702WO/JGN/AGq5eUsBSA Date: Fri, 21 Sep 2012 12:15:06 +0000 Message-ID: <8D38716F0C1A444BA0CD7E96454366C23A4DDEF6@szxeml545-mbx.china.huawei.com> References: <20120919230313.17329.44102.idtracker@ietfa.amsl.com> <505AE794.8070304@neclab.eu> In-Reply-To: <505AE794.8070304@neclab.eu> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.37.56] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [decade] WG Action: Conclusion of Decoupled Application Data Enroute (decade) X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2012 12:15:39 -0000 RGVhciBNYXJ0aW4sIEFsbCwNCg0KICB8VGhlIERFQ0FERSB3b3JraW5nIGdyb3VwIGhhcyBqdXN0 IGJlZW4gY2xvc2VkIGJ5IHlvdXIgcmVzcG9uc2libGUgQXJlYQ0KICB8RGlyZWN0b3IuDQogIHwN CiAgfFRoaXMgbWF5IGNvbWUgYXMgYSBzdXJwcmlzZSB0byBzb21lIGluIHRoZSBXRw0KDQpJbmRl ZWQsIGl0IGhhcyBiZWVuIGEgc3VycHJpc2UuDQoNCiAgfCBidXQgaXQgc2hvdWxkIG5vdCBiZSBh IHN1cnByaXNlIGZvciB0aGUgd29ya2luZyBkcmFmdHMgYXV0aG9ycw0KDQpUaGF0J3MgZmluZSwg YnV0IEkgdGhpbmsgc29tZSBzb3J0IG9mIGFubm91bmNlbWVudCAoYW5kIGV2ZW4gYmV0dGVyIGEg ZGlzY3Vzc2lvbikgc2hvdWxkIGhhdmUgYmVlbiBjaXJjdWxhdGVkIHByaW9yIHRvIHRoZSBJRVNH IGFubm91bmNlbWVudC4gSSdtIG5vdCBpbnRlcmVzdGVkIGludG8gX3dob18gc2hvdWxkIGhhdmUg ZG9uZSB0aGlzLiBJdCdzIHRvbyBsYXRlIGFuZCwgaW4gdGhlIGVuZCwgaXJyZWxldmFudCBhdCB0 aGlzIHN0YWdlLiBCdXQgdGhlcmUncyBhbiBvcmRlciBvZiBtYWduaXR1ZGUgbW9yZSBwZW9wbGUg b24gdGhpcyBtYWlsaW5nIGxpc3QgdGhhbiBpbiB0aGUgYXV0aG9yIGxpbmUgb2YgYWxsIGRyYWZ0 cyB0b2dldGhlci4gSSB3b3VsZCBjb25zaWRlciB0aGlzIGEgYnJlYWtkb3duIGluIGNvbW11bmlj YXRpb24gYmV0d2VlbiB0aGUgaW5uZXItIGFuZCBvdXRlci1jaXJjbGUuIFRoaXMgd2FzIGZhciBm cm9tIHdoYXQsIGluIGdlbmVyYWwsIEkgd291bGQgY2FsbCBhICJncmFjZWZ1bCB0ZWFyZG93biIu DQoNCiAgfCBCb3RoIGRyYWZ0cyBkbyBsZWF2ZSBhbnkgbnVtYmVyIG9mIGtleSBxdWVzdGlvbnMg dW5hbnN3ZXJlZA0KDQpJIGRvIGFncmVlIHdpdGggbW9zdCBvZiB5b3VyIHRlY2huaWNhbCBjb21t ZW50cy4gSSBzZW50IHJldmlld3Mgb24gYm90aCBkb2N1bWVudHMgZWFybGllci4gVGhhdCBzYWlk LCBpbW8sIHRoaXMgYWN0aW9uIHdhcyBhIGJpdCBhYnJ1cHQuIEkgZG8gcmVjYWxsIGEgZmV3IGdy b3VwcyB0aGF0IHdlcmUgbXVjaCBsYXRlciBpbiB0aGVpciB0aW1lbGluZXMgdGhhbiBkZWNhZGUg aXMgbm93LCBhbmQgdGhleSBzdGlsbCBtYW5hZ2VkIHRvIGRvIGRlY2VudCB3b3JrIGFmdGVyIGEg KHByb2xvbmdlZCkgc2xvdyBzdGFydC4NCg0KSW4gYW55IGNhc2UsIEkgcmVzcGVjdCB5b3VyIGRl Y2lzaW9uLCBidXQgSSBkbyBub3Qgc2Vjb25kIGl0Lg0KDQpCZXN0IFJlZ2FyZHMsDQoNCktvc3Rh cw0KDQoNCg== From Akbar.Rahman@InterDigital.com Fri Sep 21 06:21:36 2012 Return-Path: X-Original-To: decade@ietfa.amsl.com Delivered-To: decade@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0ACC21F8629 for ; Fri, 21 Sep 2012 06:21:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.405 X-Spam-Level: X-Spam-Status: No, score=-2.405 tagged_above=-999 required=5 tests=[AWL=0.194, 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 RsDucHjR3H5c for ; Fri, 21 Sep 2012 06:21:32 -0700 (PDT) Received: from idcout.InterDigital.com (smtp-out1.interdigital.com [64.208.228.135]) by ietfa.amsl.com (Postfix) with ESMTP id 561F121F871C for ; Fri, 21 Sep 2012 06:21:28 -0700 (PDT) Received: from SAM.InterDigital.com ([10.30.2.11]) by idcout.InterDigital.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 21 Sep 2012 09:21:27 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Date: Fri, 21 Sep 2012 09:21:25 -0400 Message-ID: In-Reply-To: <8D38716F0C1A444BA0CD7E96454366C23A4DDEF6@szxeml545-mbx.china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [decade] WG Action: Conclusion of Decoupled Application Data Enroute (decade) Thread-Index: AQHNl2Kl6GCO1u70702WO/JGN/AGq5eUsBSAgAARZPA= References: <20120919230313.17329.44102.idtracker@ietfa.amsl.com><505AE794.8070304@neclab.eu> <8D38716F0C1A444BA0CD7E96454366C23A4DDEF6@szxeml545-mbx.china.huawei.com> From: "Rahman, Akbar" To: "Konstantinos Pentikousis" , "Martin Stiemerling" , X-OriginalArrivalTime: 21 Sep 2012 13:21:27.0438 (UTC) FILETIME=[01623AE0:01CD97FC] Subject: Re: [decade] WG Action: Conclusion of Decoupled Application Data Enroute (decade) X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2012 13:21:36 -0000 VG8gQWxsLA0KDQoNCg0KSSBhbHNvIHdhbnQgdG8gbWFrZSBzb21lIHBvaW50cyBmb3IgdGhlIHJl Y29yZDoNCg0KLSBBcyBhbiBhdXRob3IsIEkgZG8gTk9UIGZlZWwgdGhhdCBJIHdhcyBwYXJ0IG9m IGFueSBleHRlbnNpdmUgZGlzY3Vzc2lvbnMgcmVnYXJkaW5nIHBvdGVudGlhbCBzaHV0dGluZyBk b3duIG9mIHRoZSBERUNBREUgV0cgYW5kIGVzcGVjaWFsbHkgc3RvcHBpbmcgdGhlIGN1cnJlbnQg YWN0aXZlIFdHIGRyYWZ0cyAoZXNwZWNpYWxseSB0aGUgQXJjaGl0ZWN0dXJlIEktRCB3aGVyZSBJ IHdhcyBhbiBhdXRob3IpLiAgDQoNCi0gV2UgZGlkIGhhdmUgb25lIGx1bmNoIG1lZXRpbmcgaW4g VmFuY291dmVyIHdpdGggTWFydGluIGFuZCB0aGUgY2hhaXJzIGJ1dCB0aGF0IHdhcyBwdWJsaWNs eSBhbm5vdW5jZWQgYW5kIG9wZW4gdG8gYWxsIGluIHRoZSBXRy4gIEF0IHRoYXQgbWVldGluZywg SSByZWNhbGwgTWFydGluIGFza2luZyB0aGUgYXR0ZW5kZWVzIGlmIHRoZXJlIHdhcyBpbmR1c3Ry eSBpbnRlcmVzdCBmb3IgdGhlIERFQ0FERSB3b3JrLiAgRnJvbSB3aGF0IEkgcmVjYWxsLCBldmVy eW9uZSB0aGVyZSBkaWQgZXhwcmVzcyB2YXJpb3VzIGxldmVscyBvZiBpbnRlcmVzdCBhbmQgc3Vw cG9ydC4gIEkgZGlkbuKAmXQgaGVhciBhbnlvbmUgc2F5IHRoYXQgREVDQURFIHdhcyBhICJ3YXN0 ZWQgZWZmb3J0Ii4gU28sIGZyYW5rbHkgSSB3YXMgc3VycHJpc2VkIGFuZCBkaXNhcHBvaW50ZWQg dG8gc2VlIHRoZSBXRyBzaHV0IGRvd24gc28gc3VkZGVubHkuICBJZiB0aGVyZSByZWFsbHkgaXMg bm8gY29tbXVuaXR5IHN1cHBvcnQgdG8gY29udGludWUgd2l0aCB0aGUgYWN0aXZpdHksIHRoZW4g c28gYmUgaXQuICBCdXQgeW91IGNhbm5vdCBjb25jbHVkZSB0aGF0IHRoZXJlIGlzIG5vdCBpbnRl cmVzdCB3aXRob3V0IGZpcnN0IGhhdmluZyBhbiBvcGVuIGRpc2N1c3Npb24uDQoNCi0gSW4gdGVy bXMgb2YgdGhlIGRvY3VtZW50IHF1YWxpdHkuICBUaGUgZmlyc3QgZHJhZnQgb2YgdGhlIEFyY2hp dGVjdHVyZSBJLUQgd2FzIGluIE1hcmNoIDIwMTEuICBTaW5jZSB0aGVuIHdlIGhhdmUgZ290dGVu IGV4dGVuc2l2ZSBjb21tZW50cyBmcm9tIHZhcmlvdXMgZXhjZWxsZW50IHJldmlld2Vycy4gIEJ1 dCBhcyBpcyBvZnRlbiB0aGUgY2FzZSB3aGVuIHlvdSBoYXZlIG11bHRpcGxlIHJldmlld2Vycywg eW91IHNvbWV0aW1lcyBnZXQgY29uZmxpY3RpbmcgZGlyZWN0aW9ucy4gIFNvbWUgcmV2aWV3ZXJz IHdhbnRlZCBhIGhpZ2ggbGV2ZWwgYWJzdHJhY3QgYXJjaGl0ZWN0dXJlIHRoYXQgYXZvaWRlZCBh bGwgImltcGxlbWVudGF0aW9uIiBkZXRhaWxzLiAgT3RoZXIgcmV2aWV3ZXJzIHdhbnRlZCBhIG1v cmUgZGV0YWlsZWQgYXBwcm9hY2ggdGhhdCBnb3QgbW9yZSBpbnRvIHRoZSBkZXRhaWxzIG9mIHRo ZSBwcm90b2NvbHMgYW5kIGlubmVyIHdvcmtpbmdzIG9mIHRoZSBub2Rlcy4gIEkgcGVyc29uYWxs eSB0cmllZCBpbiBhIGdvb2QgZmFpdGggZWZmb3J0IHRvIGFkZHJlc3MgYWxsIHRoZSBjb21tZW50 cyBhbmQgdG8gdHJ5IHRvIHN0cmlrZSBhIGJhbGFuY2UgaW4gYWRkcmVzc2luZyB0aGUgcGhpbG9z b3BoaWVzIG9mIHRoZSBkaWZmZXJlbnQgcmV2aWV3ZXJzLg0KDQotIEkgYWdyZWUgd2l0aCBLb3N0 YXMgdGhhdCBtYW55IGRvY3VtZW50cyBpbiBvdGhlciBXR3MgZ28gdGhyb3VnaCBzaW1pbGFyIGlz c3VlcyBidXQgYXQgdGhlIGVuZCBzdGlsbCBtYW5hZ2VkIHRvIHByb2R1Y2UgZ29vZCB3b3JrLg0K DQotIFRvIGNvbmNsdWRlLCBJIGRldm90ZWQgaW4gZ29vZCBmYWl0aCBhIGZhaXIgYW1vdW50IG9m IG15IGVuZXJneSB0byBwYXJ0aWNpcGF0ZSBpbiBhZHZhbmNpbmcgdGhlIHRvcGljcyBpbiB0aGUg V0cgc2luY2UgdGhlIGZpcnN0IHNlc3Npb24gYmFjayBpbiBBbmFoZWltLiAgSSBkZWZlciB0byB0 aGUgaGlnaGVyIHBvd2VycyB0byBtYWtlIHRoZSBkZWNpc2lvbiBvbiBjbG9zaW5nIHRoZSBERUNB REUgV0cgb3Igbm90LiAgSG93ZXZlciwgSSBjbGVhcmx5IHdhbnQgdG8gc3RhdGUgdGhhdCBJIHRo aW5rIGl0IHdhcyB1bmZvcnR1bmF0ZSB0byBhbHNvIHN1ZGRlbmx5IHRlcm1pbmF0ZSB0aGUgREVD QURFIEFyY2hpdGVjdHVyZSBJLUQgd2hpY2ggd2FzIGJlaW5nIGV4dGVuc2l2ZWx5IHJldmlzZWQg d2hlbmV2ZXIgd2UgZ290IHJldmlld2VyIGNvbW1lbnRzLiAgSSB1bmRlcnN0YW5kIGlmIHBlb3Bs ZSBhcmUgc2F5aW5nIHRoYXQgbW9yZSB3b3JrIGhhcyB0byBiZSBkb25lIHRvIGdldCBpdCB0byBw dWJsaWNhdGlvbiBzdGF0ZS4gIEJ1dCB0aGF0IGRvZXMgbm90IHdhcnJhbnQsIGluIG15IG9waW5p b24sIHRvIGp1c3Qgc2h1dCBkb3duIHRoZSB3b3JrLiAgSG9uZXN0bHksIGlmIHlvdSB1c2UgdGhh dCBjcml0ZXJpYSB0aGVyZSB3b3VsZCBiZSBtYW55IFdHIGRvY3VtZW50cyBpbiBvdGhlciBncm91 cHMgdGhhdCBzaG91bGQgYWxzbyBiZSBhYnJ1cHRseSBzaHV0IGRvd24uDQoNCg0KUmVzcGVjdGZ1 bGx5LA0KDQoNCkFrYmFyDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBkZWNh ZGUtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmRlY2FkZS1ib3VuY2VzQGlldGYub3JnXSBPbiBC ZWhhbGYgT2YgS29uc3RhbnRpbm9zIFBlbnRpa291c2lzDQpTZW50OiBGcmlkYXksIFNlcHRlbWJl ciAyMSwgMjAxMiA4OjE1IEFNDQpUbzogTWFydGluIFN0aWVtZXJsaW5nOyBkZWNhZGVAaWV0Zi5v cmcNClN1YmplY3Q6IFJlOiBbZGVjYWRlXSBXRyBBY3Rpb246IENvbmNsdXNpb24gb2YgRGVjb3Vw bGVkIEFwcGxpY2F0aW9uIERhdGEgRW5yb3V0ZSAoZGVjYWRlKQ0KDQpEZWFyIE1hcnRpbiwgQWxs LA0KDQogIHxUaGUgREVDQURFIHdvcmtpbmcgZ3JvdXAgaGFzIGp1c3QgYmVlbiBjbG9zZWQgYnkg eW91ciByZXNwb25zaWJsZSBBcmVhDQogIHxEaXJlY3Rvci4NCiAgfA0KICB8VGhpcyBtYXkgY29t ZSBhcyBhIHN1cnByaXNlIHRvIHNvbWUgaW4gdGhlIFdHDQoNCkluZGVlZCwgaXQgaGFzIGJlZW4g YSBzdXJwcmlzZS4NCg0KICB8IGJ1dCBpdCBzaG91bGQgbm90IGJlIGEgc3VycHJpc2UgZm9yIHRo ZSB3b3JraW5nIGRyYWZ0cyBhdXRob3JzDQoNClRoYXQncyBmaW5lLCBidXQgSSB0aGluayBzb21l IHNvcnQgb2YgYW5ub3VuY2VtZW50IChhbmQgZXZlbiBiZXR0ZXIgYSBkaXNjdXNzaW9uKSBzaG91 bGQgaGF2ZSBiZWVuIGNpcmN1bGF0ZWQgcHJpb3IgdG8gdGhlIElFU0cgYW5ub3VuY2VtZW50LiBJ J20gbm90IGludGVyZXN0ZWQgaW50byBfd2hvXyBzaG91bGQgaGF2ZSBkb25lIHRoaXMuIEl0J3Mg dG9vIGxhdGUgYW5kLCBpbiB0aGUgZW5kLCBpcnJlbGV2YW50IGF0IHRoaXMgc3RhZ2UuIEJ1dCB0 aGVyZSdzIGFuIG9yZGVyIG9mIG1hZ25pdHVkZSBtb3JlIHBlb3BsZSBvbiB0aGlzIG1haWxpbmcg bGlzdCB0aGFuIGluIHRoZSBhdXRob3IgbGluZSBvZiBhbGwgZHJhZnRzIHRvZ2V0aGVyLiBJIHdv dWxkIGNvbnNpZGVyIHRoaXMgYSBicmVha2Rvd24gaW4gY29tbXVuaWNhdGlvbiBiZXR3ZWVuIHRo ZSBpbm5lci0gYW5kIG91dGVyLWNpcmNsZS4gVGhpcyB3YXMgZmFyIGZyb20gd2hhdCwgaW4gZ2Vu ZXJhbCwgSSB3b3VsZCBjYWxsIGEgImdyYWNlZnVsIHRlYXJkb3duIi4NCg0KICB8IEJvdGggZHJh ZnRzIGRvIGxlYXZlIGFueSBudW1iZXIgb2Yga2V5IHF1ZXN0aW9ucyB1bmFuc3dlcmVkDQoNCkkg ZG8gYWdyZWUgd2l0aCBtb3N0IG9mIHlvdXIgdGVjaG5pY2FsIGNvbW1lbnRzLiBJIHNlbnQgcmV2 aWV3cyBvbiBib3RoIGRvY3VtZW50cyBlYXJsaWVyLiBUaGF0IHNhaWQsIGltbywgdGhpcyBhY3Rp b24gd2FzIGEgYml0IGFicnVwdC4gSSBkbyByZWNhbGwgYSBmZXcgZ3JvdXBzIHRoYXQgd2VyZSBt dWNoIGxhdGVyIGluIHRoZWlyIHRpbWVsaW5lcyB0aGFuIGRlY2FkZSBpcyBub3csIGFuZCB0aGV5 IHN0aWxsIG1hbmFnZWQgdG8gZG8gZGVjZW50IHdvcmsgYWZ0ZXIgYSAocHJvbG9uZ2VkKSBzbG93 IHN0YXJ0Lg0KDQpJbiBhbnkgY2FzZSwgSSByZXNwZWN0IHlvdXIgZGVjaXNpb24sIGJ1dCBJIGRv IG5vdCBzZWNvbmQgaXQuDQoNCkJlc3QgUmVnYXJkcywNCg0KS29zdGFzDQoNCg0K From k.pentikousis@huawei.com Fri Sep 21 06:27:38 2012 Return-Path: X-Original-To: decade@ietfa.amsl.com Delivered-To: decade@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C01221F87A8 for ; Fri, 21 Sep 2012 06:27:38 -0700 (PDT) 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 p6YZFN9VzYv1 for ; Fri, 21 Sep 2012 06:27:37 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 70CC621F86F3 for ; Fri, 21 Sep 2012 06:27:37 -0700 (PDT) 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 AJW84633; Fri, 21 Sep 2012 13:27:36 +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; Fri, 21 Sep 2012 14:26:48 +0100 Received: from SZXEML419-HUB.china.huawei.com (10.82.67.158) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 21 Sep 2012 21:27:15 +0800 Received: from szxeml545-mbx.china.huawei.com ([169.254.1.98]) by szxeml419-hub.china.huawei.com ([10.82.67.158]) with mapi id 14.01.0323.003; Fri, 21 Sep 2012 21:27:09 +0800 From: Konstantinos Pentikousis To: "Rahman, Akbar" , Martin Stiemerling , "decade@ietf.org" Thread-Topic: [decade] WG Action: Conclusion of Decoupled Application Data Enroute (decade) Thread-Index: AQHNl2Kl6GCO1u70702WO/JGN/AGq5eUsBSAgAARZPCAAAiaUA== Date: Fri, 21 Sep 2012 13:27:08 +0000 Message-ID: <8D38716F0C1A444BA0CD7E96454366C23A4DDFFC@szxeml545-mbx.china.huawei.com> References: <20120919230313.17329.44102.idtracker@ietfa.amsl.com><505AE794.8070304@neclab.eu> <8D38716F0C1A444BA0CD7E96454366C23A4DDEF6@szxeml545-mbx.china.huawei.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.37.56] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [decade] WG Action: Conclusion of Decoupled Application Data Enroute (decade) X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2012 13:27:38 -0000 SGkgQWtiYXIsIEFsbCwNCg0KPHNuaXA+DQogIHxBdCB0aGF0IG1lZXRpbmcsIEkgcmVjYWxsIE1h cnRpbiBhc2tpbmcgdGhlIGF0dGVuZGVlcyBpZiB0aGVyZSB3YXMNCiAgfGluZHVzdHJ5IGludGVy ZXN0IGZvciB0aGUgREVDQURFIHdvcmsuDQo8c25pcD4NCg0KRm9yIHRoZSByZWNvcmQsIGhvdyBt YW55IGZvbGtzIGF0dGVuZGVkIHRoaXMgImx1bmNoIG1lZXRpbmciPw0KDQpCZXN0IFJlZ2FyZHMs DQoNCktvc3Rhcw0KDQoNCg0KDQo= From cabo@tzi.org Fri Sep 21 06:33:40 2012 Return-Path: X-Original-To: decade@ietfa.amsl.com Delivered-To: decade@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B823A21F875C for ; Fri, 21 Sep 2012 06:33:40 -0700 (PDT) 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 SNwpNH3mVFKq for ; Fri, 21 Sep 2012 06:33:40 -0700 (PDT) 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 D123D21F87F3 for ; Fri, 21 Sep 2012 06:33:35 -0700 (PDT) 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 q8LDXRcg009905; Fri, 21 Sep 2012 15:33:27 +0200 (CEST) Received: from [192.168.217.105] (p54893726.dip.t-dialin.net [84.137.55.38]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 8BED1DB7; Fri, 21 Sep 2012 15:33:27 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 6.1 \(1498\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: <505AE794.8070304@neclab.eu> Date: Fri, 21 Sep 2012 15:33:28 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <940898BC-1BCA-48FC-8BF2-4FB703AA923B@tzi.org> References: <20120919230313.17329.44102.idtracker@ietfa.amsl.com> <505AE794.8070304@neclab.eu> To: Martin Stiemerling X-Mailer: Apple Mail (2.1498) Cc: decade@ietf.org Subject: Re: [decade] WG Action: Conclusion of Decoupled Application Data Enroute (decade) X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2012 13:33:40 -0000 On Sep 20, 2012, at 11:53, Martin Stiemerling = wrote: > But you may resubmit those drafts as individual submissions, address = the review received so far, e.g., Dave Crocker's, Carsten Bormann's, and = the AD reviews. Ask for feedback again, if you have addressed the = reviews in your updated drafts. Let me just say that, although I haven't had much time to invest in this = work after my initial review, I'm certainly available for continued = review. Maybe the authors can take the closure of the WG as an opportunity to = relieve themselves of some of the too many strings pulling on this. Focus more sharply, nail things down, and it may still work out. If you need some cheering up, consider that -- outside the confines of = the WG -- draft-farrell-decade-ni did work out, as it did exactly this = focusing and nailing down. Gr=FC=DFe, Carsten From Martin.Stiemerling@neclab.eu Fri Sep 21 07:09:29 2012 Return-Path: X-Original-To: decade@ietfa.amsl.com Delivered-To: decade@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D39421F8839 for ; Fri, 21 Sep 2012 07:09:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.409 X-Spam-Level: X-Spam-Status: No, score=-102.409 tagged_above=-999 required=5 tests=[AWL=0.190, 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 kOpg9QxN+-Ni for ; Fri, 21 Sep 2012 07:09:28 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 9E79921F882C for ; Fri, 21 Sep 2012 07:09:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 0757B101F07; Fri, 21 Sep 2012 16:09:28 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8RZR4lOlHp2r; Fri, 21 Sep 2012 16:09:27 +0200 (CEST) Received: from ENCELADUS.office.hd (enceladus.office.hd [192.168.24.52]) by mailer1.neclab.eu (Postfix) with ESMTP id DBEB1101F03; Fri, 21 Sep 2012 16:09:12 +0200 (CEST) Received: from [10.1.1.190] (10.1.1.190) by skoll.office.hd (192.168.125.11) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 21 Sep 2012 16:08:57 +0200 Message-ID: <505C74F3.7060002@neclab.eu> Date: Fri, 21 Sep 2012 16:08:51 +0200 From: Martin Stiemerling User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0 MIME-Version: 1.0 To: "Rahman, Akbar" References: <20120919230313.17329.44102.idtracker@ietfa.amsl.com><505AE794.8070304@neclab.eu> <8D38716F0C1A444BA0CD7E96454366C23A4DDEF6@szxeml545-mbx.china.huawei.com> In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [10.1.1.190] Cc: decade@ietf.org, Konstantinos Pentikousis Subject: Re: [decade] WG Action: Conclusion of Decoupled Application Data Enroute (decade) X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2012 14:09:29 -0000 Hi Akbar, On 09/21/2012 03:21 PM, Rahman, Akbar wrote: > To All, > > > > I also want to make some points for the record: > > - As an author, I do NOT feel that I was part of any extensive discussions regarding potential shutting down of the DECADE WG and especially stopping the current active WG drafts (especially the Architecture I-D where I was an author). Talk to your chairs and consider that the requirements went from publication requested (i.e., on the way to the IESG) back to the WG (i.e., not on the way to the IESG). The same is true for the architecture draft. > > - We did have one lunch meeting in Vancouver with Martin and the chairs but that was publicly announced and open to all in the WG. At that meeting, I recall Martin asking the attendees if there was industry interest for the DECADE work. From what I recall, everyone there did express various levels of interest and support. I didn’t hear anyone say that DECADE was a "wasted effort". So, frankly I was surprised and disappointed to see the WG shut down so suddenly. If there really is no community support to continue with the activity, then so be it. But you cannot conclude that there is not interest without first having an open discussion. To be honestly, but expressing interest and transforming interest to technical progress are two very distinct actions. I have seen a lot of 'expressing interest', but the technical progress was and is just not there. I also told at the lunch meeting in Vancouver that I want to see actions on the two main drafts in the WG, i.e., the requirements and the architecture. Yes there has been action, but the technical quality of the drafts is far from being useful for any further protocol development. See also my email with 2 examples on issues not addressed in neither the requirements nor the architecture draft. > > - In terms of the document quality. The first draft of the Architecture I-D was in March 2011. Since then we have gotten extensive comments from various excellent reviewers. But as is often the case when you have multiple reviewers, you sometimes get conflicting directions. Some reviewers wanted a high level abstract architecture that avoided all "implementation" details. Other reviewers wanted a more detailed approach that got more into the details of the protocols and inner workings of the nodes. I personally tried in a good faith effort to address all the comments and to try to strike a balance in addressing the philosophies of the different reviewers. The architecture drafts clearly fails to show the architecture of the DECADE protocols. See my AD review. You have indeed received extensive reviews, but it is up to date not clear if and how they were addressed. You can see also this, as the draft talks about the DECADE system which is not equal to the protocols. > > - I agree with Kostas that many documents in other WGs go through similar issues but at the end still managed to produce good work. Yes and no. There are examples in both directions, so it doesn't help here in this particular case. > > - To conclude, I devoted in good faith a fair amount of my energy to participate in advancing the topics in the WG since the first session back in Anaheim. I defer to the higher powers to make the decision on closing the DECADE WG or not. However, I clearly want to state that I think it was unfortunate to also suddenly terminate the DECADE Architecture I-D which was being extensively revised whenever we got reviewer comments. I understand if people are saying that more work has to be done to get it to publication state. But that does not warrant, in my opinion, to just shut down the work. Honestly, if you use that criteria there would be many WG documents in other groups that should also be abruptly shut down. I wonder why there is so much care about other groups? This is about DECADE not any other arbitrary group somewhere else. With respect to the energy: If people still believe in DECADE, take the documents, address the reviews, get reviews and go for the Independent Stream submission with the RFC editor. Regards, Martin > > > Respectfully, > > > Akbar > > -----Original Message----- > From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.org] On Behalf Of Konstantinos Pentikousis > Sent: Friday, September 21, 2012 8:15 AM > To: Martin Stiemerling; decade@ietf.org > Subject: Re: [decade] WG Action: Conclusion of Decoupled Application Data Enroute (decade) > > Dear Martin, All, > > |The DECADE working group has just been closed by your responsible Area > |Director. > | > |This may come as a surprise to some in the WG > > Indeed, it has been a surprise. > > | but it should not be a surprise for the working drafts authors > > That's fine, but I think some sort of announcement (and even better a discussion) should have been circulated prior to the IESG announcement. I'm not interested into _who_ should have done this. It's too late and, in the end, irrelevant at this stage. But there's an order of magnitude more people on this mailing list than in the author line of all drafts together. I would consider this a breakdown in communication between the inner- and outer-circle. This was far from what, in general, I would call a "graceful teardown". > > | Both drafts do leave any number of key questions unanswered > > I do agree with most of your technical comments. I sent reviews on both documents earlier. That said, imo, this action was a bit abrupt. I do recall a few groups that were much later in their timelines than decade is now, and they still managed to do decent work after a (prolonged) slow start. > > In any case, I respect your decision, but I do not second it. > > Best Regards, > > Kostas > > -- martin.stiemerling@neclab.eu NEC Laboratories Europe - Network Research Division NEC Europe Limited Registered Office: NEC House, 1 Victoria Road, London W3 6BL Registered in England 283 From Martin.Stiemerling@neclab.eu Fri Sep 21 07:10:18 2012 Return-Path: X-Original-To: decade@ietfa.amsl.com Delivered-To: decade@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44B2521F8839 for ; Fri, 21 Sep 2012 07:10:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.414 X-Spam-Level: X-Spam-Status: No, score=-102.414 tagged_above=-999 required=5 tests=[AWL=0.185, 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 u+MXKf1regTV for ; Fri, 21 Sep 2012 07:10:17 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id C01C721F8830 for ; Fri, 21 Sep 2012 07:10:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 26C68101F05; Fri, 21 Sep 2012 16:10:17 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BOPmVFxgzz3P; Fri, 21 Sep 2012 16:10:17 +0200 (CEST) Received: from ENCELADUS.office.hd (enceladus.office.hd [192.168.24.52]) by mailer1.neclab.eu (Postfix) with ESMTP id 095F1101F03; Fri, 21 Sep 2012 16:10:02 +0200 (CEST) Received: from [10.1.1.190] (10.1.1.190) by skoll.office.hd (192.168.125.11) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 21 Sep 2012 16:10:07 +0200 Message-ID: <505C7539.5040801@neclab.eu> Date: Fri, 21 Sep 2012 16:10:01 +0200 From: Martin Stiemerling User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0 MIME-Version: 1.0 To: Konstantinos Pentikousis References: <20120919230313.17329.44102.idtracker@ietfa.amsl.com><505AE794.8070304@neclab.eu> <8D38716F0C1A444BA0CD7E96454366C23A4DDEF6@szxeml545-mbx.china.huawei.com> <8D38716F0C1A444BA0CD7E96454366C23A4DDFFC@szxeml545-mbx.china.huawei.com> In-Reply-To: <8D38716F0C1A444BA0CD7E96454366C23A4DDFFC@szxeml545-mbx.china.huawei.com> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.1.1.190] Cc: "decade@ietf.org" Subject: Re: [decade] WG Action: Conclusion of Decoupled Application Data Enroute (decade) X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2012 14:10:18 -0000 On 09/21/2012 03:27 PM, Konstantinos Pentikousis wrote: > Hi Akbar, All, > > > |At that meeting, I recall Martin asking the attendees if there was > |industry interest for the DECADE work. > > > For the record, how many folks attended this "lunch meeting"? I cannot remember the exact number anymore, but it should have been 6 to 8 people. -- martin.stiemerling@neclab.eu NEC Laboratories Europe - Network Research Division NEC Europe Limited Registered Office: NEC House, 1 Victoria Road, London W3 6BL Registered in England 283 From yry@cs.yale.edu Fri Sep 21 07:19:35 2012 Return-Path: X-Original-To: decade@ietfa.amsl.com Delivered-To: decade@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BE3421F8831 for ; Fri, 21 Sep 2012 07:19:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 7yHZsfMvJ4L5 for ; Fri, 21 Sep 2012 07:19:33 -0700 (PDT) Received: from vm-emlprdomr-10.its.yale.edu (vm-emlprdomr-10.its.yale.edu [130.132.50.176]) by ietfa.amsl.com (Postfix) with ESMTP id 18BCB21F86FD for ; Fri, 21 Sep 2012 07:19:33 -0700 (PDT) Received: from Faculty-Supports-MacBook-Pro-2.local ([128.36.46.181]) (authenticated bits=0) by vm-emlprdomr-10.its.yale.edu (8.14.4/8.14.4) with ESMTP id q8LEJU6H022138 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 21 Sep 2012 10:19:31 -0400 Message-ID: <505C7772.3070503@cs.yale.edu> Date: Fri, 21 Sep 2012 10:19:30 -0400 From: "Y. Richard Yang" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: decade@ietf.org References: <20120919230313.17329.44102.idtracker@ietfa.amsl.com> <505AE794.8070304@neclab.eu> In-Reply-To: <505AE794.8070304@neclab.eu> Content-Type: multipart/alternative; boundary="------------020706060909090002060705" X-Scanned-By: MIMEDefang 2.71 on 130.132.50.176 Subject: Re: [decade] WG Action: Conclusion of Decoupled Application Data Enroute (decade) X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2012 14:19:36 -0000 This is a multi-part message in MIME format. --------------020706060909090002060705 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hi Martin, Since IETF wants paper records on decision. Just for the record, I was and am still very disappointed in the close of the DECADE WG and very surprised by the decision. Please see below. On 9/20/12 5:53 AM, Martin Stiemerling wrote: > Dear all, > > The DECADE working group has just been closed by your responsible Area > Director. > > This may come as a surprise to some in the WG, but it should not be a > surprise for the working drafts authors. An a co-author, I am very surprised to receive the email notification. > The chairs have been notified in advance about this action. > > There has been significant feedback from the community that questioned > the technical status of DECADE in the recent past. Yes. The authors appreciate the feedback! > These concerns were not been taken up and were not addressed. As far as I know, they have been considered. The authors of the Arch document was scheduling a conference call *this week* to discuss the comments, and then were surprised by the announcement that the WG has been closed. > > The working group did made only small progress in the last six months, > which was visible in the low amount of emails on the list, I think the WG has reasonable amount of email lately. The announcement of close was made on Sept. 20, and two days before the announcement, Sept. 18, there were 5 emails on the mailing list. > though there are a number of issues that should have been discussed. > > The WG chairs were explicitly notified in mid of June that there are > severe issues and the WG had time to address those issues. However, it > must have been obvious even before mid of June that there are severe > issues, i.e., there has been sufficient time to fix it. > > Furthermore, the requirements and architecture draft were submitted to > the IESG for publication and both drafts have been returned to the WG, > as both are not ready to be published as RFC. > You can find the AD review in the datatracker: > - https://datatracker.ietf.org/doc/draft-ietf-decade-reqs/history/ > - https://datatracker.ietf.org/doc/draft-ietf-decade-arch/history/ > Your preceding AD reviews are extensive. But I think the main criticism is writing/English/organization problems, not technical problems. > Both drafts do leave any number of key questions unanswered, i.e., > they are far away from being technically useful to be the base for the > next steps in the protocol development. > > To give 2 examples: > 1) > It is completely unclear how the resources on a DECADE server are > supposed to be managed The basic design principles are stated in Sec. 4.4 and 4.5 of -arch: Explicit Control and Delegation, with sentences such as "Storage Providers will have the ability to explicitly manage the entities allowed to utilize the resources at a DECADE-compatible server. This capability is needed for reasons such as capacity- planning and legal considerations in certain deployment scenarios." "Content Providers are able to explicitly and independently manage their own shares of resources on a server." "The client can in turn share the granted resources amongst its multiple applications. The share of resources granted by a server is called a User Delegation." "As a simple example, a DECADE-compatible server operated by an ISP might be configured to grant each ISP Subscriber 1.5 Mbit/s of bandwidth. The ISP Subscriber might in turn divide this share of resources amongst a video streaming application and file-sharing application which are running concurrently." In -req: -Multiple Applications Sharing Resources "REQUIREMENT(S): A client MUST be able to indicate to a DECADE- compatible server about resource sharing policies among multiple Target Applications being run/managed by the same client." - Per-Client Resource Policy "REQUIREMENT(S): A Provider MUST be able to specify resource policies (bandwidth share, storage quota, and network connection quota) to individual Consumers for reading from and writing data to its in- network storage within a particular range of time." - Distributed Resource Sharing Specification REQUIREMENT(S): A Provider MUST be able to indicate to its DECADE- compatible server, without itself contacting the server, resource control policies for a Consumer. The DECADE-compatible server MUST be able to authenticate the resource control policies. - Resource Set REQUIREMENT(S): A DECADE-compatible server MUST allow specification on the following resources: storage, bandwidth, and number of connections, and MAY allow additional types of resources to be specified. ... > and how this management is mapped to the protocol split of SDT, DRP, > and other management protocols. > Parts of it, such as setting the permissions of data objects clearly > belongs to the DRP, and it is sort of stated in a vague way in the > architecture, but it is not documented in a comprehensive way. The documents intentionally stayed vague as the understanding was that they are not solution-specifying protocol documents. Some authors have a lot more details on resource management, e.g., the recent SIGCOMM ICN'12 paper (http://conferences.sigcomm.org/sigcomm/2012/paper/icn/p25.pdf) discusses using a hierarchical weighted sharing scheme for resource sharing and how to encode them in tokens. But the authors discussed the issues intensively, considered this to be too solution specific, and intentionally left them over to allow a larger design space to allow better participation. > Other parts, such as the accounting is probably not part of the the > DRP nor SDT, but there is supposedly another interface that is needed > for this. > > 2) > What is the model how data objects are handled on the server in the > sense about who is allowed to do what? > The drafts solely talk about tokens to be used to do access control. > But there other aspects, for instance, who is controlling what on a > DECADE server: The DECADE server can be operated by an ISP, but the > content is provided by a content provider and it is access by an > unlimited set of clients or limited set of clients. Limited set of clients. See -req: " REQUIREMENT(S): A Provider MUST be able to control which individual clients are authorized to read/write which particular data objects from/to its in-network storage. RATIONALE: A Target Application should able to conduct access control on the granularity of individual clients, individual data objects." > How is the access control divided between those parties? Mostly by clients, but with the exception that ISP has a say when: -req Sec. 9: 9.1. Illegal Data Object REQUIREMENT(S): A DECADE-compatible server SHOULD provide an error indicating that (1) data was rejected from being written, (2) deleted, or (3) marked unavailable. RATIONALE: DECADE Storage Providers may require the ability to (1) avoid storing, (2) delete, or (3) quarantine certain data that has been identified as illegal (or otherwise prohibited). It is not specified how such data is identified, but applications employing DECADE-compatible servers should not break if a Storage Provider is obligated to enforce such policies. Appropriate error conditions should be indicated to applications. EXCEPTION: A DECADE-compatible server should be able to be configured to suppress Illegal Data Object responses for security reasons. Again, I found the decision surprising, abrupt, and disappointing. Richard To conclude this email: > The DECADE group started its work in end of April 2010 and is now > working for more than 2 years on the milestones and drafts. The time > isn't a big deal, but after 2 years I would have expected that the > documents are on a good technical level where the WG can build on top of. > > Some of you probably ask how the remaining drafts are handled: > First of all, they are not working groups drafts anymore. > > But you may resubmit those drafts as individual submissions, address > the review received so far, e.g., Dave Crocker's, Carsten Bormann's, > and the AD reviews. Ask for feedback again, if you have addressed the > reviews in your updated drafts. > > If you believe that the drafts are solid work, with a base for further > protocol development, you may consider to submit the drafts via the > RFC editor's Independent Stream. > > > The decisions to close the WG can be of course appealed via the IETF > appeal process: > See 'Appeals and PR-Actions' under http://www.ietf.org/iesg/ and RFC > 2026. > > Regards, > > Martin > --------------020706060909090002060705 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
Hi Martin,

Since IETF wants paper records on decision. Just for the record, I was and am still very disappointed in the close of the DECADE WG and very surprised by the decision. Please see below.

On 9/20/12 5:53 AM, Martin Stiemerling wrote:
Dear all,

The DECADE working group has just been closed by your responsible Area Director.

This may come as a surprise to some in the WG, but it should not be a surprise for the working drafts authors.
An a co-author, I am very surprised to receive the email notification.

The chairs have been notified in advance about this action.

There has been significant feedback from the community that questioned the technical status of DECADE in the recent past.
Yes. The authors appreciate the feedback!

These concerns were not been taken up and were not addressed.
As far as I know, they have been considered. The authors of the Arch document was scheduling a conference call *this week* to discuss the comments, and then were surprised by the announcement that the WG has been closed.


The working group did made only small progress in the last six months, which was visible in the low amount of emails on the list,
I think the WG has reasonable amount of email lately. The announcement of close was made on Sept. 20, and two days before the announcement, Sept. 18, there were 5 emails on the mailing list.

though there are a number of issues that should have been discussed.

The WG chairs were explicitly notified in mid of June that there are severe issues and the WG had time to address those issues. However, it must have been obvious even before mid of June that there are severe issues, i.e., there has been sufficient time to fix it.

Furthermore, the requirements and architecture draft were submitted to the IESG for publication and both drafts have been returned to the WG, as both are not ready to be published as RFC.
You can find the AD review in the datatracker:
- https://datatracker.ietf.org/doc/draft-ietf-decade-reqs/history/
- https://datatracker.ietf.org/doc/draft-ietf-decade-arch/history/

Your preceding AD reviews are extensive. But I think the main criticism is writing/English/organization problems, not technical problems.

Both drafts do leave any number of key questions unanswered, i.e., they are far away from being technically useful to be the base for the next steps in the protocol development.

To give 2 examples:
1)
It is completely unclear how the resources on a DECADE server are supposed to be managed
The basic design principles are stated in Sec. 4.4 and 4.5 of -arch: Explicit Control and Delegation, with sentences such as 
"Storage Providers will have the ability to explicitly manage the
   entities allowed to utilize the resources at a DECADE-compatible
   server.  This capability is needed for reasons such as capacity-
   planning and legal considerations in certain deployment scenarios."

"Content Providers are able to explicitly and independently manage their 
own shares of resources on a server."

"The client can in turn share the
   granted resources amongst its multiple applications.  The share of
   resources granted by a server is called a User Delegation."

"As a simple example, a DECADE-compatible server operated by an ISP
   might be configured to grant each ISP Subscriber 1.5 Mbit/s of
   bandwidth.  The ISP Subscriber might in turn divide this share of
   resources amongst a video streaming application and file-sharing
   application which are running concurrently."
In -req: 
- Multiple Applications Sharing Resources

"REQUIREMENT(S):  A client MUST be able to indicate to a DECADE-
       compatible server about resource sharing policies among multiple
       Target Applications being run/managed by the same client."

- Per-Client Resource Policy

"REQUIREMENT(S):  A Provider MUST be able to specify resource policies
       (bandwidth share, storage quota, and network connection quota) to
       individual Consumers for reading from and writing data to its in-
       network storage within a particular range of time."

- Distributed Resource Sharing Specification
REQUIREMENT(S):  A Provider MUST be able to indicate to its DECADE-
       compatible server, without itself contacting the server, resource
       control policies for a Consumer.  The DECADE-compatible server
       MUST be able to authenticate the resource control policies.

- Resource Set
REQUIREMENT(S):  A DECADE-compatible server MUST allow specification
       on the following resources: storage, bandwidth, and number of
       connections, and MAY allow additional types of resources to be
       specified.

...



    
and
      how this management is mapped to the protocol split of SDT, DRP,
      and other management protocols.
      

    

    
Parts
      of it, such as setting the permissions of data objects clearly
      belongs to the DRP, and it is sort of stated in a vague way in the
      architecture, but it is not documented in a comprehensive way. 

    

    The documents intentionally stayed vague as the understanding was
    that they are not solution-specifying protocol documents. Some
    authors have a lot more details on resource management, e.g., the
    recent SIGCOMM ICN'12 paper
    (http://conferences.sigcomm.org/sigcomm/2012/paper/icn/p25.pdf)
    discusses using a hierarchical weighted sharing scheme for resource
    sharing and how to encode them in tokens. But the authors discussed
    the issues intensively, considered this to be too solution specific,
    and intentionally left them over to allow a larger design space to
    allow better participation.

    

    
Other
      parts, such as the accounting is probably not part of the the DRP
      nor SDT, but there is supposedly another interface that is needed
      for this.
      

      

    

    
2)
      

      What is the model how data objects are handled on the server in
      the sense about who is allowed to do what? 

    
The
      drafts solely talk about tokens to be used to do access control.
      But there other aspects, for instance, who is controlling what on
      a DECADE server: The DECADE server can be operated by an ISP, but
      the content is provided by a content provider and it is access by
      an unlimited set of clients or limited set of clients. 

    Limited set of clients. See -req: "
    
    
REQUIREMENT(S):  A Provider MUST be able to control which individual
       clients are authorized to read/write which particular data
       objects from/to its in-network storage.

   RATIONALE:  A Target Application should able to conduct access
       control on the granularity of individual clients, individual data
       objects."

    

    

    
How is
      the access control divided between those parties?
      

    

    Mostly by clients, but with the exception that ISP has a say when:

    -req Sec. 9:

    9.1.  Illegal Data Object

    

       REQUIREMENT(S):  A DECADE-compatible server SHOULD provide an
    error

           indicating that (1) data was rejected from being written, (2)

           deleted, or (3) marked unavailable.

    

       RATIONALE:  DECADE Storage Providers may require the ability to
    (1)

           avoid storing, (2) delete, or (3) quarantine certain data
    that

           has been identified as illegal (or otherwise prohibited).  It
    is

           not specified how such data is identified, but applications

           employing DECADE-compatible servers should not break if a
    Storage

           Provider is obligated to enforce such policies.  Appropriate

           error conditions should be indicated to applications.

    

       EXCEPTION:  A DECADE-compatible server should be able to be

           configured to suppress Illegal Data Object responses for
    security

           reasons.

    

    Again, I found the decision surprising, abrupt, and disappointing.

    

    Richard

    

    To conclude this email:
    

    
The
      DECADE group started its work in end of April 2010 and is now
      working for more than 2 years on the milestones and drafts. The
      time isn't a big deal, but after 2 years I would have expected
      that the documents are on a good technical level where the WG can
      build on top of.
      

      

    

    

    
Some
      of you probably ask how the remaining drafts are handled:
      

      First of all, they are not working groups drafts anymore.
      

      

      But you may resubmit those drafts as individual submissions,
      address the review received so far, e.g., Dave Crocker's, Carsten
      Bormann's, and the AD reviews. Ask for feedback again, if you have
      addressed the reviews in your updated drafts.
      

      

      If you believe that the drafts are solid work, with a base for
      further protocol development, you may consider to submit the
      drafts via the RFC editor's Independent Stream.
      

      

      

      The decisions to close the WG can be of course appealed via the
      IETF appeal process:
      

      See 'Appeals and PR-Actions' under http://www.ietf.org/iesg/ and
      RFC 2026.
      

      

      Regards,
      

      

        Martin
      

      

    

    

  


--------------020706060909090002060705--

From k.pentikousis@huawei.com  Fri Sep 21 07:22:27 2012
Return-Path: 
X-Original-To: decade@ietfa.amsl.com
Delivered-To: decade@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDCE721F8819 for ; Fri, 21 Sep 2012 07:22:27 -0700 (PDT)
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 Ercv6Yh3K9tS for ; Fri, 21 Sep 2012 07:22:27 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id B90E821F8850 for ; Fri, 21 Sep 2012 07:22:25 -0700 (PDT)
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 AJW88936; Fri, 21 Sep 2012 14:22:24 +0000 (GMT)
Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 21 Sep 2012 15:21:37 +0100
Received: from SZXEML438-HUB.china.huawei.com (10.72.61.73) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 21 Sep 2012 15:22:04 +0100
Received: from szxeml545-mbx.china.huawei.com ([169.254.1.98]) by szxeml438-hub.china.huawei.com ([10.72.61.73]) with mapi id 14.01.0323.003; Fri, 21 Sep 2012 22:22:01 +0800
From: Konstantinos Pentikousis 
To: Martin Stiemerling 
Thread-Topic: [decade] WG Action: Conclusion of Decoupled Application Data Enroute (decade)
Thread-Index: AQHNmALKaxNFT9W+GUmf67JVVgCMtJeU2GEg
Date: Fri, 21 Sep 2012 14:22:01 +0000
Message-ID: <8D38716F0C1A444BA0CD7E96454366C23A4DE06E@szxeml545-mbx.china.huawei.com>
References: <20120919230313.17329.44102.idtracker@ietfa.amsl.com><505AE794.8070304@neclab.eu> <8D38716F0C1A444BA0CD7E96454366C23A4DDEF6@szxeml545-mbx.china.huawei.com>  <8D38716F0C1A444BA0CD7E96454366C23A4DDFFC@szxeml545-mbx.china.huawei.com> <505C7539.5040801@neclab.eu>
In-Reply-To: <505C7539.5040801@neclab.eu>
Accept-Language: en-US, zh-CN
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.200.37.56]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: "decade@ietf.org" 
Subject: Re: [decade] WG Action: Conclusion of Decoupled Application Data Enroute (decade)
X-BeenThere: decade@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 21 Sep 2012 14:22:27 -0000

ICB8PiAgICB8QXQgdGhhdCBtZWV0aW5nLCBJIHJlY2FsbCBNYXJ0aW4gYXNraW5nIHRoZSBhdHRl
bmRlZXMgaWYgdGhlcmUgd2FzDQogIHw+ICAgIHxpbmR1c3RyeSBpbnRlcmVzdCBmb3IgdGhlIERF
Q0FERSB3b3JrLg0KICB8PiA8c25pcD4NCiAgfD4NCiAgfD4gRm9yIHRoZSByZWNvcmQsIGhvdyBt
YW55IGZvbGtzIGF0dGVuZGVkIHRoaXMgImx1bmNoIG1lZXRpbmciPw0KICB8DQogIHxJIGNhbm5v
dCByZW1lbWJlciB0aGUgZXhhY3QgbnVtYmVyIGFueW1vcmUsIGJ1dCBpdCBzaG91bGQgaGF2ZSBi
ZWVuIDYNCiAgfHRvIDggcGVvcGxlLg0KDQpTbywgYmFzaWNhbGx5LCAzLTYgZm9sa3MgYmVzaWRl
cyB0aGUgY2hhaXIocykgYW5kIHRoZSBBRC4NCg0KTWFueSB0aGFua3MsDQoNCktvc3Rhcw0K

From Akbar.Rahman@InterDigital.com  Fri Sep 21 07:24:00 2012
Return-Path: 
X-Original-To: decade@ietfa.amsl.com
Delivered-To: decade@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDD6D21F8826 for ; Fri, 21 Sep 2012 07:23:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.437
X-Spam-Level: 
X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[AWL=0.162,  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 kUTUJthV3VtE for ; Fri, 21 Sep 2012 07:23:57 -0700 (PDT)
Received: from idcout.InterDigital.com (smtp-out1.interdigital.com [64.208.228.135]) by ietfa.amsl.com (Postfix) with ESMTP id DCE7021F884E for ; Fri, 21 Sep 2012 07:23:55 -0700 (PDT)
Received: from SAM.InterDigital.com ([10.30.2.11]) by idcout.InterDigital.com with Microsoft SMTPSVC(6.0.3790.4675);  Fri, 21 Sep 2012 10:23:54 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: base64
Date: Fri, 21 Sep 2012 10:23:53 -0400
Message-ID: 
In-Reply-To: <505C74F3.7060002@neclab.eu>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [decade] WG Action: Conclusion of Decoupled Application Data Enroute (decade)
Thread-Index: Ac2YArgq2Fy7uduzRtm9MtKtp9ZJcAAAOlzA
References: <20120919230313.17329.44102.idtracker@ietfa.amsl.com><505AE794.8070304@neclab.eu> <8D38716F0C1A444BA0CD7E96454366C23A4DDEF6@szxeml545-mbx.china.huawei.com>  <505C74F3.7060002@neclab.eu>
From: "Rahman, Akbar" 
To: "Martin Stiemerling" 
X-OriginalArrivalTime: 21 Sep 2012 14:23:54.0974 (UTC) FILETIME=[BB16D7E0:01CD9804]
Cc: decade@ietf.org, Konstantinos Pentikousis 
Subject: Re: [decade] WG Action: Conclusion of Decoupled Application Data Enroute (decade)
X-BeenThere: decade@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 21 Sep 2012 14:24:00 -0000

SGkgTWFydGluLA0KDQoNClRoYW5rcyBmb3IgdGhlIGZlZWRiYWNrLiAgSSB3aWxsIHRhbGsgdG8g
dGhlIG90aGVyIGF1dGhvcnMgYW5kIHNlZSBpZiB0aGV5IGFncmVlIHRvIHVzZSB0aGUgSW5kZXBl
bmRlbnQgU3RyZWFtIHN1Ym1pc3Npb24uDQoNCg0KT24geW91ciBwb2ludDoNCg0KCS0tIHNuaXAg
LS0tDQoJWW91IGNhbiBzZWUgYWxzbyB0aGlzLCBhcyB0aGUgZHJhZnQgdGFsa3MgYWJvdXQgdGhl
IERFQ0FERSBzeXN0ZW0gd2hpY2ggDQoJaXMgbm90IGVxdWFsIHRvIHRoZSBwcm90b2NvbHMuDQoN
CgktLSBzbmlwIC0tLQ0KDQpQbGVhc2Ugbm90ZSB0aGF0IHRoZSBub21lbmNsYXR1cmUgb2YgIkRF
Q0FERSBzeXN0ZW0iIHdhcyBzcGVjaWZpY2FsbHkgYWdyZWVkIGluIHRoZSBXRyB0byBhZGRyZXNz
IHRoZSBjb21tZW50cyBmcm9tIHRoZSBwcmV2aW91cyBBRCBEYXZlIEhhcnJpbmd0b24uICBBbHNv
IHRoZSBXRyBjaGFydGVyIHNwZWNpZmljYWxseSBwcm9oaWJpdGVkIHVzIGZyb20gc2VsZWN0aW5n
IGFuZCBzcGVjaWZ5aW5nIHRoZSBkZXRhaWxzIG9mIHRoZSBwcm90b2NvbHMuICBQZXJoYXBzIHRo
aXMgaXMgdGhlIGNhdXNlIG9mIHNvbWUgb2YgdGhlIGNvbmZ1c2lvbiBmb3IgeW91Lg0KDQoNClNp
bmNlcmVseSwNCg0KDQpBa2Jhcg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9t
OiBNYXJ0aW4gU3RpZW1lcmxpbmcgW21haWx0bzptYXJ0aW4uc3RpZW1lcmxpbmdAbmVjbGFiLmV1
XSANClNlbnQ6IEZyaWRheSwgU2VwdGVtYmVyIDIxLCAyMDEyIDEwOjA5IEFNDQpUbzogUmFobWFu
LCBBa2Jhcg0KQ2M6IEtvbnN0YW50aW5vcyBQZW50aWtvdXNpczsgZGVjYWRlQGlldGYub3JnDQpT
dWJqZWN0OiBSZTogW2RlY2FkZV0gV0cgQWN0aW9uOiBDb25jbHVzaW9uIG9mIERlY291cGxlZCBB
cHBsaWNhdGlvbiBEYXRhIEVucm91dGUgKGRlY2FkZSkNCg0KSGkgQWtiYXIsDQoNCk9uIDA5LzIx
LzIwMTIgMDM6MjEgUE0sIFJhaG1hbiwgQWtiYXIgd3JvdGU6DQo+IFRvIEFsbCwNCj4NCj4NCj4N
Cj4gSSBhbHNvIHdhbnQgdG8gbWFrZSBzb21lIHBvaW50cyBmb3IgdGhlIHJlY29yZDoNCj4NCj4g
LSBBcyBhbiBhdXRob3IsIEkgZG8gTk9UIGZlZWwgdGhhdCBJIHdhcyBwYXJ0IG9mIGFueSBleHRl
bnNpdmUgZGlzY3Vzc2lvbnMgcmVnYXJkaW5nIHBvdGVudGlhbCBzaHV0dGluZyBkb3duIG9mIHRo
ZSBERUNBREUgV0cgYW5kIGVzcGVjaWFsbHkgc3RvcHBpbmcgdGhlIGN1cnJlbnQgYWN0aXZlIFdH
IGRyYWZ0cyAoZXNwZWNpYWxseSB0aGUgQXJjaGl0ZWN0dXJlIEktRCB3aGVyZSBJIHdhcyBhbiBh
dXRob3IpLg0KDQpUYWxrIHRvIHlvdXIgY2hhaXJzIGFuZCBjb25zaWRlciB0aGF0IHRoZSByZXF1
aXJlbWVudHMgd2VudCBmcm9tIA0KcHVibGljYXRpb24gcmVxdWVzdGVkIChpLmUuLCBvbiB0aGUg
d2F5IHRvIHRoZSBJRVNHKSBiYWNrIHRvIHRoZSBXRyANCihpLmUuLCBub3Qgb24gdGhlIHdheSB0
byB0aGUgSUVTRykuDQoNClRoZSBzYW1lIGlzIHRydWUgZm9yIHRoZSBhcmNoaXRlY3R1cmUgZHJh
ZnQuDQoNCj4NCj4gLSBXZSBkaWQgaGF2ZSBvbmUgbHVuY2ggbWVldGluZyBpbiBWYW5jb3V2ZXIg
d2l0aCBNYXJ0aW4gYW5kIHRoZSBjaGFpcnMgYnV0IHRoYXQgd2FzIHB1YmxpY2x5IGFubm91bmNl
ZCBhbmQgb3BlbiB0byBhbGwgaW4gdGhlIFdHLiAgQXQgdGhhdCBtZWV0aW5nLCBJIHJlY2FsbCBN
YXJ0aW4gYXNraW5nIHRoZSBhdHRlbmRlZXMgaWYgdGhlcmUgd2FzIGluZHVzdHJ5IGludGVyZXN0
IGZvciB0aGUgREVDQURFIHdvcmsuICBGcm9tIHdoYXQgSSByZWNhbGwsIGV2ZXJ5b25lIHRoZXJl
IGRpZCBleHByZXNzIHZhcmlvdXMgbGV2ZWxzIG9mIGludGVyZXN0IGFuZCBzdXBwb3J0LiAgSSBk
aWRu4oCZdCBoZWFyIGFueW9uZSBzYXkgdGhhdCBERUNBREUgd2FzIGEgIndhc3RlZCBlZmZvcnQi
LiBTbywgZnJhbmtseSBJIHdhcyBzdXJwcmlzZWQgYW5kIGRpc2FwcG9pbnRlZCB0byBzZWUgdGhl
IFdHIHNodXQgZG93biBzbyBzdWRkZW5seS4gIElmIHRoZXJlIHJlYWxseSBpcyBubyBjb21tdW5p
dHkgc3VwcG9ydCB0byBjb250aW51ZSB3aXRoIHRoZSBhY3Rpdml0eSwgdGhlbiBzbyBiZSBpdC4g
IEJ1dCB5b3UgY2Fubm90IGNvbmNsdWRlIHRoYXQgdGhlcmUgaXMgbm90IGludGVyZXN0IHdpdGhv
dXQgZmlyc3QgaGF2aW5nIGFuIG9wZW4gZGlzY3Vzc2lvbi4NCg0KVG8gYmUgaG9uZXN0bHksIGJ1
dCBleHByZXNzaW5nIGludGVyZXN0IGFuZCB0cmFuc2Zvcm1pbmcgaW50ZXJlc3QgdG8gDQp0ZWNo
bmljYWwgcHJvZ3Jlc3MgYXJlIHR3byB2ZXJ5IGRpc3RpbmN0IGFjdGlvbnMuDQoNCkkgaGF2ZSBz
ZWVuIGEgbG90IG9mICdleHByZXNzaW5nIGludGVyZXN0JywgYnV0IHRoZSB0ZWNobmljYWwgcHJv
Z3Jlc3MgDQp3YXMgYW5kIGlzIGp1c3Qgbm90IHRoZXJlLg0KDQpJIGFsc28gdG9sZCBhdCB0aGUg
bHVuY2ggbWVldGluZyBpbiBWYW5jb3V2ZXIgdGhhdCBJIHdhbnQgdG8gc2VlIGFjdGlvbnMgDQpv
biB0aGUgdHdvIG1haW4gZHJhZnRzIGluIHRoZSBXRywgaS5lLiwgdGhlIHJlcXVpcmVtZW50cyBh
bmQgdGhlIA0KYXJjaGl0ZWN0dXJlLiBZZXMgdGhlcmUgaGFzIGJlZW4gYWN0aW9uLCBidXQgdGhl
IHRlY2huaWNhbCBxdWFsaXR5IG9mIA0KdGhlIGRyYWZ0cyBpcyBmYXIgZnJvbSBiZWluZyB1c2Vm
dWwgZm9yIGFueSBmdXJ0aGVyIHByb3RvY29sIGRldmVsb3BtZW50Lg0KU2VlIGFsc28gbXkgZW1h
aWwgd2l0aCAyIGV4YW1wbGVzIG9uIGlzc3VlcyBub3QgYWRkcmVzc2VkIGluIG5laXRoZXIgdGhl
IA0KcmVxdWlyZW1lbnRzIG5vciB0aGUgYXJjaGl0ZWN0dXJlIGRyYWZ0Lg0KDQo+DQo+IC0gSW4g
dGVybXMgb2YgdGhlIGRvY3VtZW50IHF1YWxpdHkuICBUaGUgZmlyc3QgZHJhZnQgb2YgdGhlIEFy
Y2hpdGVjdHVyZSBJLUQgd2FzIGluIE1hcmNoIDIwMTEuICBTaW5jZSB0aGVuIHdlIGhhdmUgZ290
dGVuIGV4dGVuc2l2ZSBjb21tZW50cyBmcm9tIHZhcmlvdXMgZXhjZWxsZW50IHJldmlld2Vycy4g
IEJ1dCBhcyBpcyBvZnRlbiB0aGUgY2FzZSB3aGVuIHlvdSBoYXZlIG11bHRpcGxlIHJldmlld2Vy
cywgeW91IHNvbWV0aW1lcyBnZXQgY29uZmxpY3RpbmcgZGlyZWN0aW9ucy4gIFNvbWUgcmV2aWV3
ZXJzIHdhbnRlZCBhIGhpZ2ggbGV2ZWwgYWJzdHJhY3QgYXJjaGl0ZWN0dXJlIHRoYXQgYXZvaWRl
ZCBhbGwgImltcGxlbWVudGF0aW9uIiBkZXRhaWxzLiAgT3RoZXIgcmV2aWV3ZXJzIHdhbnRlZCBh
IG1vcmUgZGV0YWlsZWQgYXBwcm9hY2ggdGhhdCBnb3QgbW9yZSBpbnRvIHRoZSBkZXRhaWxzIG9m
IHRoZSBwcm90b2NvbHMgYW5kIGlubmVyIHdvcmtpbmdzIG9mIHRoZSBub2Rlcy4gIEkgcGVyc29u
YWxseSB0cmllZCBpbiBhIGdvb2QgZmFpdGggZWZmb3J0IHRvIGFkZHJlc3MgYWxsIHRoZSBjb21t
ZW50cyBhbmQgdG8gdHJ5IHRvIHN0cmlrZSBhIGJhbGFuY2UgaW4gYWRkcmVzc2luZyB0aGUgcGhp
bG9zb3BoaWVzIG9mIHRoZSBkaWZmZXJlbnQgcmV2aWV3ZXJzLg0KDQpUaGUgYXJjaGl0ZWN0dXJl
IGRyYWZ0cyBjbGVhcmx5IGZhaWxzIHRvIHNob3cgdGhlIGFyY2hpdGVjdHVyZSBvZiB0aGUgDQpE
RUNBREUgcHJvdG9jb2xzLiBTZWUgbXkgQUQgcmV2aWV3Lg0KDQpZb3UgaGF2ZSBpbmRlZWQgcmVj
ZWl2ZWQgZXh0ZW5zaXZlIHJldmlld3MsIGJ1dCBpdCBpcyB1cCB0byBkYXRlIG5vdCANCmNsZWFy
IGlmIGFuZCBob3cgdGhleSB3ZXJlIGFkZHJlc3NlZC4NCg0KWW91IGNhbiBzZWUgYWxzbyB0aGlz
LCBhcyB0aGUgZHJhZnQgdGFsa3MgYWJvdXQgdGhlIERFQ0FERSBzeXN0ZW0gd2hpY2ggDQppcyBu
b3QgZXF1YWwgdG8gdGhlIHByb3RvY29scy4NCg0KPg0KPiAtIEkgYWdyZWUgd2l0aCBLb3N0YXMg
dGhhdCBtYW55IGRvY3VtZW50cyBpbiBvdGhlciBXR3MgZ28gdGhyb3VnaCBzaW1pbGFyIGlzc3Vl
cyBidXQgYXQgdGhlIGVuZCBzdGlsbCBtYW5hZ2VkIHRvIHByb2R1Y2UgZ29vZCB3b3JrLg0KDQpZ
ZXMgYW5kIG5vLiBUaGVyZSBhcmUgZXhhbXBsZXMgaW4gYm90aCBkaXJlY3Rpb25zLCBzbyBpdCBk
b2Vzbid0IGhlbHAgDQpoZXJlIGluIHRoaXMgcGFydGljdWxhciBjYXNlLg0KDQo+DQo+IC0gVG8g
Y29uY2x1ZGUsIEkgZGV2b3RlZCBpbiBnb29kIGZhaXRoIGEgZmFpciBhbW91bnQgb2YgbXkgZW5l
cmd5IHRvIHBhcnRpY2lwYXRlIGluIGFkdmFuY2luZyB0aGUgdG9waWNzIGluIHRoZSBXRyBzaW5j
ZSB0aGUgZmlyc3Qgc2Vzc2lvbiBiYWNrIGluIEFuYWhlaW0uICBJIGRlZmVyIHRvIHRoZSBoaWdo
ZXIgcG93ZXJzIHRvIG1ha2UgdGhlIGRlY2lzaW9uIG9uIGNsb3NpbmcgdGhlIERFQ0FERSBXRyBv
ciBub3QuICBIb3dldmVyLCBJIGNsZWFybHkgd2FudCB0byBzdGF0ZSB0aGF0IEkgdGhpbmsgaXQg
d2FzIHVuZm9ydHVuYXRlIHRvIGFsc28gc3VkZGVubHkgdGVybWluYXRlIHRoZSBERUNBREUgQXJj
aGl0ZWN0dXJlIEktRCB3aGljaCB3YXMgYmVpbmcgZXh0ZW5zaXZlbHkgcmV2aXNlZCB3aGVuZXZl
ciB3ZSBnb3QgcmV2aWV3ZXIgY29tbWVudHMuICBJIHVuZGVyc3RhbmQgaWYgcGVvcGxlIGFyZSBz
YXlpbmcgdGhhdCBtb3JlIHdvcmsgaGFzIHRvIGJlIGRvbmUgdG8gZ2V0IGl0IHRvIHB1YmxpY2F0
aW9uIHN0YXRlLiAgQnV0IHRoYXQgZG9lcyBub3Qgd2FycmFudCwgaW4gbXkgb3BpbmlvbiwgdG8g
anVzdCBzaHV0IGRvd24gdGhlIHdvcmsuICBIb25lc3RseSwgaWYgeW91IHVzZSB0aGF0IGNyaXRl
cmlhIHRoZXJlIHdvdWxkIGJlIG1hbnkgV0cgZG9jdW1lbnRzIGluIG90aGVyIGdyb3VwcyB0aGF0
IHNob3VsZCBhbHNvIGJlIGFicnVwdGx5IHNodXQgZG93bi4NCg0KSSB3b25kZXIgd2h5IHRoZXJl
IGlzIHNvIG11Y2ggY2FyZSBhYm91dCBvdGhlciBncm91cHM/IFRoaXMgaXMgYWJvdXQgDQpERUNB
REUgbm90IGFueSBvdGhlciBhcmJpdHJhcnkgZ3JvdXAgc29tZXdoZXJlIGVsc2UuDQoNCldpdGgg
cmVzcGVjdCB0byB0aGUgZW5lcmd5Og0KSWYgcGVvcGxlIHN0aWxsIGJlbGlldmUgaW4gREVDQURF
LCB0YWtlIHRoZSBkb2N1bWVudHMsIGFkZHJlc3MgdGhlIA0KcmV2aWV3cywgZ2V0IHJldmlld3Mg
YW5kIGdvIGZvciB0aGUgSW5kZXBlbmRlbnQgU3RyZWFtIHN1Ym1pc3Npb24gd2l0aCANCnRoZSBS
RkMgZWRpdG9yLg0KDQpSZWdhcmRzLA0KDQogICBNYXJ0aW4NCg0KPg0KPg0KPiBSZXNwZWN0ZnVs
bHksDQo+DQo+DQo+IEFrYmFyDQo+DQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZy
b206IGRlY2FkZS1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86ZGVjYWRlLWJvdW5jZXNAaWV0Zi5v
cmddIE9uIEJlaGFsZiBPZiBLb25zdGFudGlub3MgUGVudGlrb3VzaXMNCj4gU2VudDogRnJpZGF5
LCBTZXB0ZW1iZXIgMjEsIDIwMTIgODoxNSBBTQ0KPiBUbzogTWFydGluIFN0aWVtZXJsaW5nOyBk
ZWNhZGVAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFtkZWNhZGVdIFdHIEFjdGlvbjogQ29uY2x1
c2lvbiBvZiBEZWNvdXBsZWQgQXBwbGljYXRpb24gRGF0YSBFbnJvdXRlIChkZWNhZGUpDQo+DQo+
IERlYXIgTWFydGluLCBBbGwsDQo+DQo+ICAgIHxUaGUgREVDQURFIHdvcmtpbmcgZ3JvdXAgaGFz
IGp1c3QgYmVlbiBjbG9zZWQgYnkgeW91ciByZXNwb25zaWJsZSBBcmVhDQo+ICAgIHxEaXJlY3Rv
ci4NCj4gICAgfA0KPiAgICB8VGhpcyBtYXkgY29tZSBhcyBhIHN1cnByaXNlIHRvIHNvbWUgaW4g
dGhlIFdHDQo+DQo+IEluZGVlZCwgaXQgaGFzIGJlZW4gYSBzdXJwcmlzZS4NCj4NCj4gICAgfCBi
dXQgaXQgc2hvdWxkIG5vdCBiZSBhIHN1cnByaXNlIGZvciB0aGUgd29ya2luZyBkcmFmdHMgYXV0
aG9ycw0KPg0KPiBUaGF0J3MgZmluZSwgYnV0IEkgdGhpbmsgc29tZSBzb3J0IG9mIGFubm91bmNl
bWVudCAoYW5kIGV2ZW4gYmV0dGVyIGEgZGlzY3Vzc2lvbikgc2hvdWxkIGhhdmUgYmVlbiBjaXJj
dWxhdGVkIHByaW9yIHRvIHRoZSBJRVNHIGFubm91bmNlbWVudC4gSSdtIG5vdCBpbnRlcmVzdGVk
IGludG8gX3dob18gc2hvdWxkIGhhdmUgZG9uZSB0aGlzLiBJdCdzIHRvbyBsYXRlIGFuZCwgaW4g
dGhlIGVuZCwgaXJyZWxldmFudCBhdCB0aGlzIHN0YWdlLiBCdXQgdGhlcmUncyBhbiBvcmRlciBv
ZiBtYWduaXR1ZGUgbW9yZSBwZW9wbGUgb24gdGhpcyBtYWlsaW5nIGxpc3QgdGhhbiBpbiB0aGUg
YXV0aG9yIGxpbmUgb2YgYWxsIGRyYWZ0cyB0b2dldGhlci4gSSB3b3VsZCBjb25zaWRlciB0aGlz
IGEgYnJlYWtkb3duIGluIGNvbW11bmljYXRpb24gYmV0d2VlbiB0aGUgaW5uZXItIGFuZCBvdXRl
ci1jaXJjbGUuIFRoaXMgd2FzIGZhciBmcm9tIHdoYXQsIGluIGdlbmVyYWwsIEkgd291bGQgY2Fs
bCBhICJncmFjZWZ1bCB0ZWFyZG93biIuDQo+DQo+ICAgIHwgQm90aCBkcmFmdHMgZG8gbGVhdmUg
YW55IG51bWJlciBvZiBrZXkgcXVlc3Rpb25zIHVuYW5zd2VyZWQNCj4NCj4gSSBkbyBhZ3JlZSB3
aXRoIG1vc3Qgb2YgeW91ciB0ZWNobmljYWwgY29tbWVudHMuIEkgc2VudCByZXZpZXdzIG9uIGJv
dGggZG9jdW1lbnRzIGVhcmxpZXIuIFRoYXQgc2FpZCwgaW1vLCB0aGlzIGFjdGlvbiB3YXMgYSBi
aXQgYWJydXB0LiBJIGRvIHJlY2FsbCBhIGZldyBncm91cHMgdGhhdCB3ZXJlIG11Y2ggbGF0ZXIg
aW4gdGhlaXIgdGltZWxpbmVzIHRoYW4gZGVjYWRlIGlzIG5vdywgYW5kIHRoZXkgc3RpbGwgbWFu
YWdlZCB0byBkbyBkZWNlbnQgd29yayBhZnRlciBhIChwcm9sb25nZWQpIHNsb3cgc3RhcnQuDQo+
DQo+IEluIGFueSBjYXNlLCBJIHJlc3BlY3QgeW91ciBkZWNpc2lvbiwgYnV0IEkgZG8gbm90IHNl
Y29uZCBpdC4NCj4NCj4gQmVzdCBSZWdhcmRzLA0KPg0KPiBLb3N0YXMNCj4NCj4NCg0KLS0gDQpt
YXJ0aW4uc3RpZW1lcmxpbmdAbmVjbGFiLmV1DQoNCk5FQyBMYWJvcmF0b3JpZXMgRXVyb3BlIC0g
TmV0d29yayBSZXNlYXJjaCBEaXZpc2lvbiBORUMgRXVyb3BlIExpbWl0ZWQNClJlZ2lzdGVyZWQg
T2ZmaWNlOiBORUMgSG91c2UsIDEgVmljdG9yaWEgUm9hZCwgTG9uZG9uIFczIDZCTA0KUmVnaXN0
ZXJlZCBpbiBFbmdsYW5kIDI4Mw0K

From Akbar.Rahman@InterDigital.com  Fri Sep 21 07:24:55 2012
Return-Path: 
X-Original-To: decade@ietfa.amsl.com
Delivered-To: decade@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D96121F8850 for ; Fri, 21 Sep 2012 07:24:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.46
X-Spam-Level: 
X-Spam-Status: No, score=-2.46 tagged_above=-999 required=5 tests=[AWL=0.139,  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 e7TQneHL76DG for ; Fri, 21 Sep 2012 07:24:52 -0700 (PDT)
Received: from idcout.InterDigital.com (smtp-out1.interdigital.com [64.208.228.135]) by ietfa.amsl.com (Postfix) with ESMTP id 5727E21F884E for ; Fri, 21 Sep 2012 07:24:49 -0700 (PDT)
Received: from SAM.InterDigital.com ([10.30.2.11]) by idcout.InterDigital.com with Microsoft SMTPSVC(6.0.3790.4675);  Fri, 21 Sep 2012 10:24:48 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: base64
Date: Fri, 21 Sep 2012 10:24:47 -0400
Message-ID: 
In-Reply-To: <8D38716F0C1A444BA0CD7E96454366C23A4DE06E@szxeml545-mbx.china.huawei.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [decade] WG Action: Conclusion of Decoupled Application Data Enroute (decade)
Thread-Index: AQHNmALKaxNFT9W+GUmf67JVVgCMtJeU2GEggAABHfA=
References: <20120919230313.17329.44102.idtracker@ietfa.amsl.com><505AE794.8070304@neclab.eu> <8D38716F0C1A444BA0CD7E96454366C23A4DDEF6@szxeml545-mbx.china.huawei.com>  <8D38716F0C1A444BA0CD7E96454366C23A4DDFFC@szxeml545-mbx.china.huawei.com> <505C7539.5040801@neclab.eu> <8D38716F0C1A444BA0CD7E96454366C23A4DE06E@szxeml545-mbx.china.huawei.com>
From: "Rahman, Akbar" 
To: "Konstantinos Pentikousis" , "Martin Stiemerling" 
X-OriginalArrivalTime: 21 Sep 2012 14:24:48.0566 (UTC) FILETIME=[DB085560:01CD9804]
Cc: decade@ietf.org
Subject: Re: [decade] WG Action: Conclusion of Decoupled Application Data Enroute (decade)
X-BeenThere: decade@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 21 Sep 2012 14:24:55 -0000

WWVzLiAgQW5kIG5vdGUgdGhhdCBpdCB3YXMgYWR2ZXJ0aXNlZCBhcyBhbiBpbmZvcm1hbCBsdW5j
aCBhbmQgbm90IG11Y2ggbW9yZS4NCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206
IEtvbnN0YW50aW5vcyBQZW50aWtvdXNpcyBbbWFpbHRvOmsucGVudGlrb3VzaXNAaHVhd2VpLmNv
bV0gDQpTZW50OiBGcmlkYXksIFNlcHRlbWJlciAyMSwgMjAxMiAxMDoyMiBBTQ0KVG86IE1hcnRp
biBTdGllbWVybGluZw0KQ2M6IFJhaG1hbiwgQWtiYXI7IGRlY2FkZUBpZXRmLm9yZw0KU3ViamVj
dDogUkU6IFtkZWNhZGVdIFdHIEFjdGlvbjogQ29uY2x1c2lvbiBvZiBEZWNvdXBsZWQgQXBwbGlj
YXRpb24gRGF0YSBFbnJvdXRlIChkZWNhZGUpDQoNCiAgfD4gICAgfEF0IHRoYXQgbWVldGluZywg
SSByZWNhbGwgTWFydGluIGFza2luZyB0aGUgYXR0ZW5kZWVzIGlmIHRoZXJlIHdhcw0KICB8PiAg
ICB8aW5kdXN0cnkgaW50ZXJlc3QgZm9yIHRoZSBERUNBREUgd29yay4NCiAgfD4gPHNuaXA+DQog
IHw+DQogIHw+IEZvciB0aGUgcmVjb3JkLCBob3cgbWFueSBmb2xrcyBhdHRlbmRlZCB0aGlzICJs
dW5jaCBtZWV0aW5nIj8NCiAgfA0KICB8SSBjYW5ub3QgcmVtZW1iZXIgdGhlIGV4YWN0IG51bWJl
ciBhbnltb3JlLCBidXQgaXQgc2hvdWxkIGhhdmUgYmVlbiA2DQogIHx0byA4IHBlb3BsZS4NCg0K
U28sIGJhc2ljYWxseSwgMy02IGZvbGtzIGJlc2lkZXMgdGhlIGNoYWlyKHMpIGFuZCB0aGUgQUQu
DQoNCk1hbnkgdGhhbmtzLA0KDQpLb3N0YXMNCg==

From yry@cs.yale.edu  Fri Sep 21 09:43:01 2012
Return-Path: 
X-Original-To: decade@ietfa.amsl.com
Delivered-To: decade@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 410B021F867C for ; Fri, 21 Sep 2012 09:43:01 -0700 (PDT)
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=[AWL=0.001,  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 DtjX29MElXbt for ; Fri, 21 Sep 2012 09:43:00 -0700 (PDT)
Received: from vm-emlprdomr-10.its.yale.edu (vm-emlprdomr-10.its.yale.edu [130.132.50.176]) by ietfa.amsl.com (Postfix) with ESMTP id 9E8BF21F8679 for ; Fri, 21 Sep 2012 09:42:59 -0700 (PDT)
Received: from Faculty-Supports-MacBook-Pro-2.local ([128.36.46.181]) (authenticated bits=0) by vm-emlprdomr-10.its.yale.edu (8.14.4/8.14.4) with ESMTP id q8LGgvRP024440 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 21 Sep 2012 12:42:57 -0400
Message-ID: <505C9911.6040009@cs.yale.edu>
Date: Fri, 21 Sep 2012 12:42:57 -0400
From: "Y. Richard Yang" 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1
MIME-Version: 1.0
To: decade@ietf.org
References: <20120919230313.17329.44102.idtracker@ietfa.amsl.com> <505AE794.8070304@neclab.eu> <940898BC-1BCA-48FC-8BF2-4FB703AA923B@tzi.org>
In-Reply-To: <940898BC-1BCA-48FC-8BF2-4FB703AA923B@tzi.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-Scanned-By: MIMEDefang 2.71 on 130.132.50.176
Subject: Re: [decade] WG Action: Conclusion of Decoupled Application Data Enroute (decade)
X-BeenThere: decade@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 21 Sep 2012 16:43:01 -0000

Hi Carsten,

Thanks a lot for the offer of continued feedback and the "cheering up" 
to the authors.

As I see it, the WG was guided to work on high-level (-req and -arch) 
documents, and then was killed because the documents do not provide 
sufficient lower-level details. As a result, I do not see them surviving 
the IETF process. Thanks for the good draft-farrell-decade-ni example. 
But the example is a specific design document, and the killed docs are 
design-guideline documents. Hence, I am quite pessimistic on they they 
may go through the IETF process. A specific protocol/component design 
document might be more possible. Does this make sense?

Thanks!

Richard

On 9/21/12 9:33 AM, Carsten Bormann wrote:
> On Sep 20, 2012, at 11:53, Martin Stiemerling  wrote:
>
>> But you may resubmit those drafts as individual submissions, address the review received so far, e.g., Dave Crocker's, Carsten Bormann's, and the AD reviews. Ask for feedback again, if you have addressed the reviews in your updated drafts.
> Let me just say that, although I haven't had much time to invest in this work after my initial review, I'm certainly available for continued review.
> Maybe the authors can take the closure of the WG as an opportunity to relieve themselves of some of the too many strings pulling on this.
>
> Focus more sharply, nail things down, and it may still work out.
>
> If you need some cheering up, consider that -- outside the confines of the WG -- draft-farrell-decade-ni did work out, as it did exactly this focusing and nailing down.
>
> Gre, Carsten
>

From Akbar.Rahman@InterDigital.com  Fri Sep 21 16:52:29 2012
Return-Path: 
X-Original-To: decade@ietfa.amsl.com
Delivered-To: decade@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9226321F84FD for ; Fri, 21 Sep 2012 16:52:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.478
X-Spam-Level: 
X-Spam-Status: No, score=-2.478 tagged_above=-999 required=5 tests=[AWL=0.122,  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 FVcwRKHg8RC2 for ; Fri, 21 Sep 2012 16:52:28 -0700 (PDT)
Received: from idcout.InterDigital.com (smtp-out1.interdigital.com [64.208.228.135]) by ietfa.amsl.com (Postfix) with ESMTP id 88C0B21F84F9 for ; Fri, 21 Sep 2012 16:52:28 -0700 (PDT)
Received: from SAM.InterDigital.com ([10.30.2.11]) by idcout.InterDigital.com with Microsoft SMTPSVC(6.0.3790.4675);  Fri, 21 Sep 2012 19:52:27 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: base64
Date: Fri, 21 Sep 2012 19:52:25 -0400
Message-ID: 
In-Reply-To: <505C74F3.7060002@neclab.eu>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [decade] WG Action: Conclusion of Decoupled Application Data Enroute (decade)
Thread-Index: Ac2YArgq2Fy7uduzRtm9MtKtp9ZJcAAUDdtg
References: <20120919230313.17329.44102.idtracker@ietfa.amsl.com><505AE794.8070304@neclab.eu> <8D38716F0C1A444BA0CD7E96454366C23A4DDEF6@szxeml545-mbx.china.huawei.com>  <505C74F3.7060002@neclab.eu>
From: "Rahman, Akbar" 
To: "Martin Stiemerling" 
X-OriginalArrivalTime: 21 Sep 2012 23:52:27.0490 (UTC) FILETIME=[27BBB420:01CD9854]
Cc: decade@ietf.org, Konstantinos Pentikousis 
Subject: Re: [decade] WG Action: Conclusion of Decoupled Application Data Enroute (decade)
X-BeenThere: decade@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 21 Sep 2012 23:52:29 -0000

SGkgTWFydGluLA0KDQoNClJlZ2FyZGluZyB5b3VyIHBvaW50IGJlbG93LiAgVW5mb3J0dW5hdGVs
eSwgSSB0aGluayB0aGF0IHlvdSBhcmUgZmFjdHVhbGx5IHdyb25nLiAgT3RoZXJ3aXNlIHByb3Zl
IG1lIHdyb25nIGJ5IHNob3dpbmcgbWUgd2hlcmUgb24gdGhlIEktRCBTdGF0ZSBEaWFncmFtIGh0
dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9pbWFnZXMvc3RhdGVfZGlhZ3JhbS5wbmcgaXQgc3Bl
Y2lmaWVzIHRoYXQgc2VuZGluZyBhbiBJLUQgYmFjayB0byB0aGUgYXV0aG9ycyB3aXRoIGNvbW1l
bnRzIGVxdWFscyBzaHV0dGluZyBkb3duIHRoZSBXRyBhbmQgc3RvcHBpbmcgYSBXRyBhcHByb3Zl
ZCBJLUQuDQoNCg0KDQotLSBzbmlwIC0tDQoNCj4gLSBBcyBhbiBhdXRob3IsIEkgZG8gTk9UIGZl
ZWwgdGhhdCBJIHdhcyBwYXJ0IG9mIGFueSBleHRlbnNpdmUgZGlzY3Vzc2lvbnMgcmVnYXJkaW5n
IHBvdGVudGlhbCBzaHV0dGluZyBkb3duIG9mIHRoZSBERUNBREUgV0cgYW5kIGVzcGVjaWFsbHkg
c3RvcHBpbmcgdGhlIGN1cnJlbnQgYWN0aXZlIFdHIGRyYWZ0cyAoZXNwZWNpYWxseSB0aGUgQXJj
aGl0ZWN0dXJlIEktRCB3aGVyZSBJIHdhcyBhbiBhdXRob3IpLg0KDQpUYWxrIHRvIHlvdXIgY2hh
aXJzIGFuZCBjb25zaWRlciB0aGF0IHRoZSByZXF1aXJlbWVudHMgd2VudCBmcm9tIA0KcHVibGlj
YXRpb24gcmVxdWVzdGVkIChpLmUuLCBvbiB0aGUgd2F5IHRvIHRoZSBJRVNHKSBiYWNrIHRvIHRo
ZSBXRyANCihpLmUuLCBub3Qgb24gdGhlIHdheSB0byB0aGUgSUVTRykuDQoNClRoZSBzYW1lIGlz
IHRydWUgZm9yIHRoZSBhcmNoaXRlY3R1cmUgZHJhZnQuDQoNCg0KLS0gc25pcCAtLQ0KDQoNCkJS
DQoNCi9Ba2Jhcg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBNYXJ0aW4g
U3RpZW1lcmxpbmcgW21haWx0bzptYXJ0aW4uc3RpZW1lcmxpbmdAbmVjbGFiLmV1XSANClNlbnQ6
IEZyaWRheSwgU2VwdGVtYmVyIDIxLCAyMDEyIDEwOjA5IEFNDQpUbzogUmFobWFuLCBBa2Jhcg0K
Q2M6IEtvbnN0YW50aW5vcyBQZW50aWtvdXNpczsgZGVjYWRlQGlldGYub3JnDQpTdWJqZWN0OiBS
ZTogW2RlY2FkZV0gV0cgQWN0aW9uOiBDb25jbHVzaW9uIG9mIERlY291cGxlZCBBcHBsaWNhdGlv
biBEYXRhIEVucm91dGUgKGRlY2FkZSkNCg0KSGkgQWtiYXIsDQoNCk9uIDA5LzIxLzIwMTIgMDM6
MjEgUE0sIFJhaG1hbiwgQWtiYXIgd3JvdGU6DQo+IFRvIEFsbCwNCj4NCj4NCj4NCj4gSSBhbHNv
IHdhbnQgdG8gbWFrZSBzb21lIHBvaW50cyBmb3IgdGhlIHJlY29yZDoNCj4NCj4gLSBBcyBhbiBh
dXRob3IsIEkgZG8gTk9UIGZlZWwgdGhhdCBJIHdhcyBwYXJ0IG9mIGFueSBleHRlbnNpdmUgZGlz
Y3Vzc2lvbnMgcmVnYXJkaW5nIHBvdGVudGlhbCBzaHV0dGluZyBkb3duIG9mIHRoZSBERUNBREUg
V0cgYW5kIGVzcGVjaWFsbHkgc3RvcHBpbmcgdGhlIGN1cnJlbnQgYWN0aXZlIFdHIGRyYWZ0cyAo
ZXNwZWNpYWxseSB0aGUgQXJjaGl0ZWN0dXJlIEktRCB3aGVyZSBJIHdhcyBhbiBhdXRob3IpLg0K
DQpUYWxrIHRvIHlvdXIgY2hhaXJzIGFuZCBjb25zaWRlciB0aGF0IHRoZSByZXF1aXJlbWVudHMg
d2VudCBmcm9tIA0KcHVibGljYXRpb24gcmVxdWVzdGVkIChpLmUuLCBvbiB0aGUgd2F5IHRvIHRo
ZSBJRVNHKSBiYWNrIHRvIHRoZSBXRyANCihpLmUuLCBub3Qgb24gdGhlIHdheSB0byB0aGUgSUVT
RykuDQoNClRoZSBzYW1lIGlzIHRydWUgZm9yIHRoZSBhcmNoaXRlY3R1cmUgZHJhZnQuDQoNCj4N
Cj4gLSBXZSBkaWQgaGF2ZSBvbmUgbHVuY2ggbWVldGluZyBpbiBWYW5jb3V2ZXIgd2l0aCBNYXJ0
aW4gYW5kIHRoZSBjaGFpcnMgYnV0IHRoYXQgd2FzIHB1YmxpY2x5IGFubm91bmNlZCBhbmQgb3Bl
biB0byBhbGwgaW4gdGhlIFdHLiAgQXQgdGhhdCBtZWV0aW5nLCBJIHJlY2FsbCBNYXJ0aW4gYXNr
aW5nIHRoZSBhdHRlbmRlZXMgaWYgdGhlcmUgd2FzIGluZHVzdHJ5IGludGVyZXN0IGZvciB0aGUg
REVDQURFIHdvcmsuICBGcm9tIHdoYXQgSSByZWNhbGwsIGV2ZXJ5b25lIHRoZXJlIGRpZCBleHBy
ZXNzIHZhcmlvdXMgbGV2ZWxzIG9mIGludGVyZXN0IGFuZCBzdXBwb3J0LiAgSSBkaWRu4oCZdCBo
ZWFyIGFueW9uZSBzYXkgdGhhdCBERUNBREUgd2FzIGEgIndhc3RlZCBlZmZvcnQiLiBTbywgZnJh
bmtseSBJIHdhcyBzdXJwcmlzZWQgYW5kIGRpc2FwcG9pbnRlZCB0byBzZWUgdGhlIFdHIHNodXQg
ZG93biBzbyBzdWRkZW5seS4gIElmIHRoZXJlIHJlYWxseSBpcyBubyBjb21tdW5pdHkgc3VwcG9y
dCB0byBjb250aW51ZSB3aXRoIHRoZSBhY3Rpdml0eSwgdGhlbiBzbyBiZSBpdC4gIEJ1dCB5b3Ug
Y2Fubm90IGNvbmNsdWRlIHRoYXQgdGhlcmUgaXMgbm90IGludGVyZXN0IHdpdGhvdXQgZmlyc3Qg
aGF2aW5nIGFuIG9wZW4gZGlzY3Vzc2lvbi4NCg0KVG8gYmUgaG9uZXN0bHksIGJ1dCBleHByZXNz
aW5nIGludGVyZXN0IGFuZCB0cmFuc2Zvcm1pbmcgaW50ZXJlc3QgdG8gDQp0ZWNobmljYWwgcHJv
Z3Jlc3MgYXJlIHR3byB2ZXJ5IGRpc3RpbmN0IGFjdGlvbnMuDQoNCkkgaGF2ZSBzZWVuIGEgbG90
IG9mICdleHByZXNzaW5nIGludGVyZXN0JywgYnV0IHRoZSB0ZWNobmljYWwgcHJvZ3Jlc3MgDQp3
YXMgYW5kIGlzIGp1c3Qgbm90IHRoZXJlLg0KDQpJIGFsc28gdG9sZCBhdCB0aGUgbHVuY2ggbWVl
dGluZyBpbiBWYW5jb3V2ZXIgdGhhdCBJIHdhbnQgdG8gc2VlIGFjdGlvbnMgDQpvbiB0aGUgdHdv
IG1haW4gZHJhZnRzIGluIHRoZSBXRywgaS5lLiwgdGhlIHJlcXVpcmVtZW50cyBhbmQgdGhlIA0K
YXJjaGl0ZWN0dXJlLiBZZXMgdGhlcmUgaGFzIGJlZW4gYWN0aW9uLCBidXQgdGhlIHRlY2huaWNh
bCBxdWFsaXR5IG9mIA0KdGhlIGRyYWZ0cyBpcyBmYXIgZnJvbSBiZWluZyB1c2VmdWwgZm9yIGFu
eSBmdXJ0aGVyIHByb3RvY29sIGRldmVsb3BtZW50Lg0KU2VlIGFsc28gbXkgZW1haWwgd2l0aCAy
IGV4YW1wbGVzIG9uIGlzc3VlcyBub3QgYWRkcmVzc2VkIGluIG5laXRoZXIgdGhlIA0KcmVxdWly
ZW1lbnRzIG5vciB0aGUgYXJjaGl0ZWN0dXJlIGRyYWZ0Lg0KDQo+DQo+IC0gSW4gdGVybXMgb2Yg
dGhlIGRvY3VtZW50IHF1YWxpdHkuICBUaGUgZmlyc3QgZHJhZnQgb2YgdGhlIEFyY2hpdGVjdHVy
ZSBJLUQgd2FzIGluIE1hcmNoIDIwMTEuICBTaW5jZSB0aGVuIHdlIGhhdmUgZ290dGVuIGV4dGVu
c2l2ZSBjb21tZW50cyBmcm9tIHZhcmlvdXMgZXhjZWxsZW50IHJldmlld2Vycy4gIEJ1dCBhcyBp
cyBvZnRlbiB0aGUgY2FzZSB3aGVuIHlvdSBoYXZlIG11bHRpcGxlIHJldmlld2VycywgeW91IHNv
bWV0aW1lcyBnZXQgY29uZmxpY3RpbmcgZGlyZWN0aW9ucy4gIFNvbWUgcmV2aWV3ZXJzIHdhbnRl
ZCBhIGhpZ2ggbGV2ZWwgYWJzdHJhY3QgYXJjaGl0ZWN0dXJlIHRoYXQgYXZvaWRlZCBhbGwgImlt
cGxlbWVudGF0aW9uIiBkZXRhaWxzLiAgT3RoZXIgcmV2aWV3ZXJzIHdhbnRlZCBhIG1vcmUgZGV0
YWlsZWQgYXBwcm9hY2ggdGhhdCBnb3QgbW9yZSBpbnRvIHRoZSBkZXRhaWxzIG9mIHRoZSBwcm90
b2NvbHMgYW5kIGlubmVyIHdvcmtpbmdzIG9mIHRoZSBub2Rlcy4gIEkgcGVyc29uYWxseSB0cmll
ZCBpbiBhIGdvb2QgZmFpdGggZWZmb3J0IHRvIGFkZHJlc3MgYWxsIHRoZSBjb21tZW50cyBhbmQg
dG8gdHJ5IHRvIHN0cmlrZSBhIGJhbGFuY2UgaW4gYWRkcmVzc2luZyB0aGUgcGhpbG9zb3BoaWVz
IG9mIHRoZSBkaWZmZXJlbnQgcmV2aWV3ZXJzLg0KDQpUaGUgYXJjaGl0ZWN0dXJlIGRyYWZ0cyBj
bGVhcmx5IGZhaWxzIHRvIHNob3cgdGhlIGFyY2hpdGVjdHVyZSBvZiB0aGUgDQpERUNBREUgcHJv
dG9jb2xzLiBTZWUgbXkgQUQgcmV2aWV3Lg0KDQpZb3UgaGF2ZSBpbmRlZWQgcmVjZWl2ZWQgZXh0
ZW5zaXZlIHJldmlld3MsIGJ1dCBpdCBpcyB1cCB0byBkYXRlIG5vdCANCmNsZWFyIGlmIGFuZCBo
b3cgdGhleSB3ZXJlIGFkZHJlc3NlZC4NCg0KWW91IGNhbiBzZWUgYWxzbyB0aGlzLCBhcyB0aGUg
ZHJhZnQgdGFsa3MgYWJvdXQgdGhlIERFQ0FERSBzeXN0ZW0gd2hpY2ggDQppcyBub3QgZXF1YWwg
dG8gdGhlIHByb3RvY29scy4NCg0KPg0KPiAtIEkgYWdyZWUgd2l0aCBLb3N0YXMgdGhhdCBtYW55
IGRvY3VtZW50cyBpbiBvdGhlciBXR3MgZ28gdGhyb3VnaCBzaW1pbGFyIGlzc3VlcyBidXQgYXQg
dGhlIGVuZCBzdGlsbCBtYW5hZ2VkIHRvIHByb2R1Y2UgZ29vZCB3b3JrLg0KDQpZZXMgYW5kIG5v
LiBUaGVyZSBhcmUgZXhhbXBsZXMgaW4gYm90aCBkaXJlY3Rpb25zLCBzbyBpdCBkb2Vzbid0IGhl
bHAgDQpoZXJlIGluIHRoaXMgcGFydGljdWxhciBjYXNlLg0KDQo+DQo+IC0gVG8gY29uY2x1ZGUs
IEkgZGV2b3RlZCBpbiBnb29kIGZhaXRoIGEgZmFpciBhbW91bnQgb2YgbXkgZW5lcmd5IHRvIHBh
cnRpY2lwYXRlIGluIGFkdmFuY2luZyB0aGUgdG9waWNzIGluIHRoZSBXRyBzaW5jZSB0aGUgZmly
c3Qgc2Vzc2lvbiBiYWNrIGluIEFuYWhlaW0uICBJIGRlZmVyIHRvIHRoZSBoaWdoZXIgcG93ZXJz
IHRvIG1ha2UgdGhlIGRlY2lzaW9uIG9uIGNsb3NpbmcgdGhlIERFQ0FERSBXRyBvciBub3QuICBI
b3dldmVyLCBJIGNsZWFybHkgd2FudCB0byBzdGF0ZSB0aGF0IEkgdGhpbmsgaXQgd2FzIHVuZm9y
dHVuYXRlIHRvIGFsc28gc3VkZGVubHkgdGVybWluYXRlIHRoZSBERUNBREUgQXJjaGl0ZWN0dXJl
IEktRCB3aGljaCB3YXMgYmVpbmcgZXh0ZW5zaXZlbHkgcmV2aXNlZCB3aGVuZXZlciB3ZSBnb3Qg
cmV2aWV3ZXIgY29tbWVudHMuICBJIHVuZGVyc3RhbmQgaWYgcGVvcGxlIGFyZSBzYXlpbmcgdGhh
dCBtb3JlIHdvcmsgaGFzIHRvIGJlIGRvbmUgdG8gZ2V0IGl0IHRvIHB1YmxpY2F0aW9uIHN0YXRl
LiAgQnV0IHRoYXQgZG9lcyBub3Qgd2FycmFudCwgaW4gbXkgb3BpbmlvbiwgdG8ganVzdCBzaHV0
IGRvd24gdGhlIHdvcmsuICBIb25lc3RseSwgaWYgeW91IHVzZSB0aGF0IGNyaXRlcmlhIHRoZXJl
IHdvdWxkIGJlIG1hbnkgV0cgZG9jdW1lbnRzIGluIG90aGVyIGdyb3VwcyB0aGF0IHNob3VsZCBh
bHNvIGJlIGFicnVwdGx5IHNodXQgZG93bi4NCg0KSSB3b25kZXIgd2h5IHRoZXJlIGlzIHNvIG11
Y2ggY2FyZSBhYm91dCBvdGhlciBncm91cHM/IFRoaXMgaXMgYWJvdXQgDQpERUNBREUgbm90IGFu
eSBvdGhlciBhcmJpdHJhcnkgZ3JvdXAgc29tZXdoZXJlIGVsc2UuDQoNCldpdGggcmVzcGVjdCB0
byB0aGUgZW5lcmd5Og0KSWYgcGVvcGxlIHN0aWxsIGJlbGlldmUgaW4gREVDQURFLCB0YWtlIHRo
ZSBkb2N1bWVudHMsIGFkZHJlc3MgdGhlIA0KcmV2aWV3cywgZ2V0IHJldmlld3MgYW5kIGdvIGZv
ciB0aGUgSW5kZXBlbmRlbnQgU3RyZWFtIHN1Ym1pc3Npb24gd2l0aCANCnRoZSBSRkMgZWRpdG9y
Lg0KDQpSZWdhcmRzLA0KDQogICBNYXJ0aW4NCg0KPg0KPg0KPiBSZXNwZWN0ZnVsbHksDQo+DQo+
DQo+IEFrYmFyDQo+DQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IGRlY2Fk
ZS1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86ZGVjYWRlLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJl
aGFsZiBPZiBLb25zdGFudGlub3MgUGVudGlrb3VzaXMNCj4gU2VudDogRnJpZGF5LCBTZXB0ZW1i
ZXIgMjEsIDIwMTIgODoxNSBBTQ0KPiBUbzogTWFydGluIFN0aWVtZXJsaW5nOyBkZWNhZGVAaWV0
Zi5vcmcNCj4gU3ViamVjdDogUmU6IFtkZWNhZGVdIFdHIEFjdGlvbjogQ29uY2x1c2lvbiBvZiBE
ZWNvdXBsZWQgQXBwbGljYXRpb24gRGF0YSBFbnJvdXRlIChkZWNhZGUpDQo+DQo+IERlYXIgTWFy
dGluLCBBbGwsDQo+DQo+ICAgIHxUaGUgREVDQURFIHdvcmtpbmcgZ3JvdXAgaGFzIGp1c3QgYmVl
biBjbG9zZWQgYnkgeW91ciByZXNwb25zaWJsZSBBcmVhDQo+ICAgIHxEaXJlY3Rvci4NCj4gICAg
fA0KPiAgICB8VGhpcyBtYXkgY29tZSBhcyBhIHN1cnByaXNlIHRvIHNvbWUgaW4gdGhlIFdHDQo+
DQo+IEluZGVlZCwgaXQgaGFzIGJlZW4gYSBzdXJwcmlzZS4NCj4NCj4gICAgfCBidXQgaXQgc2hv
dWxkIG5vdCBiZSBhIHN1cnByaXNlIGZvciB0aGUgd29ya2luZyBkcmFmdHMgYXV0aG9ycw0KPg0K
PiBUaGF0J3MgZmluZSwgYnV0IEkgdGhpbmsgc29tZSBzb3J0IG9mIGFubm91bmNlbWVudCAoYW5k
IGV2ZW4gYmV0dGVyIGEgZGlzY3Vzc2lvbikgc2hvdWxkIGhhdmUgYmVlbiBjaXJjdWxhdGVkIHBy
aW9yIHRvIHRoZSBJRVNHIGFubm91bmNlbWVudC4gSSdtIG5vdCBpbnRlcmVzdGVkIGludG8gX3do
b18gc2hvdWxkIGhhdmUgZG9uZSB0aGlzLiBJdCdzIHRvbyBsYXRlIGFuZCwgaW4gdGhlIGVuZCwg
aXJyZWxldmFudCBhdCB0aGlzIHN0YWdlLiBCdXQgdGhlcmUncyBhbiBvcmRlciBvZiBtYWduaXR1
ZGUgbW9yZSBwZW9wbGUgb24gdGhpcyBtYWlsaW5nIGxpc3QgdGhhbiBpbiB0aGUgYXV0aG9yIGxp
bmUgb2YgYWxsIGRyYWZ0cyB0b2dldGhlci4gSSB3b3VsZCBjb25zaWRlciB0aGlzIGEgYnJlYWtk
b3duIGluIGNvbW11bmljYXRpb24gYmV0d2VlbiB0aGUgaW5uZXItIGFuZCBvdXRlci1jaXJjbGUu
IFRoaXMgd2FzIGZhciBmcm9tIHdoYXQsIGluIGdlbmVyYWwsIEkgd291bGQgY2FsbCBhICJncmFj
ZWZ1bCB0ZWFyZG93biIuDQo+DQo+ICAgIHwgQm90aCBkcmFmdHMgZG8gbGVhdmUgYW55IG51bWJl
ciBvZiBrZXkgcXVlc3Rpb25zIHVuYW5zd2VyZWQNCj4NCj4gSSBkbyBhZ3JlZSB3aXRoIG1vc3Qg
b2YgeW91ciB0ZWNobmljYWwgY29tbWVudHMuIEkgc2VudCByZXZpZXdzIG9uIGJvdGggZG9jdW1l
bnRzIGVhcmxpZXIuIFRoYXQgc2FpZCwgaW1vLCB0aGlzIGFjdGlvbiB3YXMgYSBiaXQgYWJydXB0
LiBJIGRvIHJlY2FsbCBhIGZldyBncm91cHMgdGhhdCB3ZXJlIG11Y2ggbGF0ZXIgaW4gdGhlaXIg
dGltZWxpbmVzIHRoYW4gZGVjYWRlIGlzIG5vdywgYW5kIHRoZXkgc3RpbGwgbWFuYWdlZCB0byBk
byBkZWNlbnQgd29yayBhZnRlciBhIChwcm9sb25nZWQpIHNsb3cgc3RhcnQuDQo+DQo+IEluIGFu
eSBjYXNlLCBJIHJlc3BlY3QgeW91ciBkZWNpc2lvbiwgYnV0IEkgZG8gbm90IHNlY29uZCBpdC4N
Cj4NCj4gQmVzdCBSZWdhcmRzLA0KPg0KPiBLb3N0YXMNCj4NCj4NCg0KLS0gDQptYXJ0aW4uc3Rp
ZW1lcmxpbmdAbmVjbGFiLmV1DQoNCk5FQyBMYWJvcmF0b3JpZXMgRXVyb3BlIC0gTmV0d29yayBS
ZXNlYXJjaCBEaXZpc2lvbiBORUMgRXVyb3BlIExpbWl0ZWQNClJlZ2lzdGVyZWQgT2ZmaWNlOiBO
RUMgSG91c2UsIDEgVmljdG9yaWEgUm9hZCwgTG9uZG9uIFczIDZCTA0KUmVnaXN0ZXJlZCBpbiBF
bmdsYW5kIDI4Mw0K

From haibin.song@huawei.com  Fri Sep 21 22:49:08 2012
Return-Path: 
X-Original-To: decade@ietfa.amsl.com
Delivered-To: decade@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BF3F21F87FE for ; Fri, 21 Sep 2012 22:49:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.882
X-Spam-Level: 
X-Spam-Status: No, score=-5.882 tagged_above=-999 required=5 tests=[AWL=0.717,  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 iG4vAOtgG6aW for ; Fri, 21 Sep 2012 22:49:07 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id B25F521F86B1 for ; Fri, 21 Sep 2012 22:49:05 -0700 (PDT)
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 AKX94099; Sat, 22 Sep 2012 05:49:04 +0000 (GMT)
Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.3; Sat, 22 Sep 2012 06:48:23 +0100
Received: from SZXEML416-HUB.china.huawei.com (10.82.67.155) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.1.323.3; Sat, 22 Sep 2012 06:49:01 +0100
Received: from SZXEML534-MBX.china.huawei.com ([169.254.2.70]) by szxeml416-hub.china.huawei.com ([10.82.67.155]) with mapi id 14.01.0323.003; Sat, 22 Sep 2012 13:48:50 +0800
From: Songhaibin 
To: Martin Stiemerling , "Rahman, Akbar" 
Thread-Topic: [decade] WG Action: Conclusion of Decoupled Application Data Enroute (decade)
Thread-Index: AQHNmAK+y9myRhkH+kSZKUqot0hH7peVkf+A
Date: Sat, 22 Sep 2012 05:48:50 +0000
Message-ID: 
References: <20120919230313.17329.44102.idtracker@ietfa.amsl.com><505AE794.8070304@neclab.eu> <8D38716F0C1A444BA0CD7E96454366C23A4DDEF6@szxeml545-mbx.china.huawei.com>  <505C74F3.7060002@neclab.eu>
In-Reply-To: <505C74F3.7060002@neclab.eu>
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.138.41.123]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: "decade@ietf.org" , Konstantinos Pentikousis 
Subject: Re: [decade] WG Action: Conclusion of Decoupled Application Data Enroute (decade)
X-BeenThere: decade@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 22 Sep 2012 05:49:08 -0000

PiBUYWxrIHRvIHlvdXIgY2hhaXJzIGFuZCBjb25zaWRlciB0aGF0IHRoZSByZXF1aXJlbWVudHMg
d2VudCBmcm9tDQo+IHB1YmxpY2F0aW9uIHJlcXVlc3RlZCAoaS5lLiwgb24gdGhlIHdheSB0byB0
aGUgSUVTRykgYmFjayB0byB0aGUgV0cNCj4gKGkuZS4sIG5vdCBvbiB0aGUgd2F5IHRvIHRoZSBJ
RVNHKS4NCj4gDQo+IFRoZSBzYW1lIGlzIHRydWUgZm9yIHRoZSBhcmNoaXRlY3R1cmUgZHJhZnQu
DQoNCkkgd2FzIG5vdGlmaWVkIGluIEp1bmUgYWJvdXQgdGhlIGVuZXJneSBvZiB0aGUgd29ya2lu
ZyBncm91cCwgYnV0IEkgd2FzIGFsc28gc3VycHJpc2VkIGFib3V0IHRoZSBhYnJ1cHQgbm90aWZp
Y2F0aW9uIG9mIHRoZSBjbG9zdXJlIG9mIHRoZSBXRyB3aXRoIHRoZSBlbWFpbCBmcm9tIE1hcnRp
biBvbiBNb25kYXksIEkgc2F3IGEgZ29vZCBsaXN0IGRpc2N1c3Npb24sIG5ldyBJLUQgc3VibWlz
c2lvbiBhbmQgd2FzIHByZXBhcmluZyBmb3IgdGhlIEF0bGFudGEgbWVldGluZyB3aGVuIEkgcmVj
ZWl2ZWQgdGhpcyBub3RpZmljYXRpb24uIEkgYWxzbyBleHByZXNzZWQgbXkgZGlzYWdyZWUgdG8g
dGhlIGNvbW1lbnQgb2YgbGFjayBvZiB0ZWNobmljYWwgc3Vic3RhbmNlcy4gQmVmb3JlIE1hcnRp
biBiZWNhbWUgdGhlIEFEIGZvciB0aGUgREVDQURFIFdHLCB0aGUgYXJjaGl0ZWN0dXJlIGRvY3Vt
ZW50IHdhcyBpbnRlbmRlZCB0byByZW1vdmUgYSBsb3Qgb2YgdGVjaG5pY2FsIGRldGFpbHMgYWNj
b3JkaW5nIHRvIGNvbW1lbnRzIHJlY2VpdmVkLCBpdCdzIG5vdCBhIHByb3RvY29sIGRyYWZ0Lg0K
DQpUaGUgZXh0ZW5zaXZlIGNvbW1lbnRzIGZyb20gTWFydGluIHRvIHRoZXNlIHR3byBJRHMgYXJl
IG1vc3RseSBlZmZlY3RpdmUsIGJ1dCBlZGl0b3JpYWwuIFRoZXkgY291bGQgYmUgYWRkcmVzc2Vk
IHRvZ2V0aGVyIHdpdGggS29zdGFzJ3MgY29tbWVudHMgaW4gdGhlIG5leHQgdmVyc2lvbiAuIEFn
YWluLCBJIGRvIG5vdCB0aGluayB0aGVzZSB0d28gZG9jdW1lbnRzIGFyZSBleHRyZW1lbHkgYmFk
IGFuZCBsYWNrIG9mIHRlY2huaWNhbCBzdWJzdGFuY2VzLiANCg0KQlIsDQotSGFpYmluDQo=

From haibin.song@huawei.com  Fri Sep 21 23:53:06 2012
Return-Path: 
X-Original-To: decade@ietfa.amsl.com
Delivered-To: decade@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E1C221F884D; Fri, 21 Sep 2012 23:53:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.971
X-Spam-Level: 
X-Spam-Status: No, score=-5.971 tagged_above=-999 required=5 tests=[AWL=0.628,  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 ecJzOAZrwHIY; Fri, 21 Sep 2012 23:53:02 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 3BBA921F884A; Fri, 21 Sep 2012 23:53:01 -0700 (PDT)
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 AKX96813; Sat, 22 Sep 2012 06:53:00 +0000 (GMT)
Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Sat, 22 Sep 2012 07:51:48 +0100
Received: from SZXEML422-HUB.china.huawei.com (10.82.67.161) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.1.323.3; Sat, 22 Sep 2012 07:52:18 +0100
Received: from SZXEML534-MBX.china.huawei.com ([169.254.2.70]) by szxeml422-hub.china.huawei.com ([10.82.67.161]) with mapi id 14.01.0323.003; Sat, 22 Sep 2012 14:52:11 +0800
From: Songhaibin 
To: Martin Stiemerling 
Thread-Topic: DECADE WG to be closed
Thread-Index: AQHNkm+beTF1FP7MtkORFrVdv9nRf5eNxdIggAGAV4CABqD7AA==
Date: Sat, 22 Sep 2012 06:52:10 +0000
Message-ID: 
References: <50531AB3.6090601@neclab.eu>  <50583257.2080404@neclab.eu>
In-Reply-To: <50583257.2080404@neclab.eu>
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.138.41.123]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: "decade@ietf.org" , "ietf@ietf.org" 
Subject: Re: [decade] DECADE WG to be closed
X-BeenThere: decade@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 22 Sep 2012 06:53:06 -0000

Dear Martin,

> -----Original Message-----
> From: Martin Stiemerling [mailto:martin.stiemerling@neclab.eu]
> Sent: Tuesday, September 18, 2012 4:36 PM
> To: Songhaibin
> Cc: Richard Woundy
> Subject: Re: DECADE WG to be closed
>=20
> Dear Haibin,
>=20
> On 09/17/2012 11:39 AM, Songhaibin wrote:
> > Dear Martin,
> >
> > Hope everything goes well with you and thank you very much for your eff=
orts
> to reviewing the drafts in detail and giving guidance.
> >
> > As I agree with most of your comments to the DECADE requirements draft,=
 but
> I have to say IMO the architecture document is not that bad. This documen=
t gives
> a clear description of the DECADE server/client components and
> implementation/design principals which will be reflected in the protocols=
, IMO
> this is what an architecture document should do.
> >
> > I do not agree there is lack of technical substances to design a base p=
rotocol
> which can satisfy the transport and resource control requirements for con=
tent
> distribution applications. Some detailed design choices are still not ver=
y clear, and
> need efforts for them.
> >
> > And recently, the energy is growing, we recently received a lot of list=
 discussion
> including comments from Kostas about the requirements and architecture an=
d
> also a new individual draft for the service discovery was submitted.
>=20
> The energy has indeed grown in the WG since before the summer. But, I
> indicated in my email from mid of June that I have doubts on the
> technical quality of the DECADE drafts. These doubts have turned into
> certainty, i.e., see the my AD reviews of the requirements and the
> architecture.
>=20
> The technical quality of the drafts would be ok, if the WG would be at
> the beginning of the process of discussing and writing those drafts, but
> it is not acceptable at the end when the drafts are intended to become RF=
Cs:
> The technical base is just to weak to continue from, even after spending
> time and effort of the WG participants for more than 2 years.

The requirements document was accepted on Oct. 18, 2010, and the architectu=
re draft was accepted on March 7, 2011.=20

>=20
> Another important data point, as mentioned earlier:
> There has been public feedback from IETF community members, such as Dave
> Crocker and Carsten Bormann, which questioned the technical base of
> DECADE as a whole. This happened at the end of the 2011 and in the first
> quarter of 2012.

> The was no and still has not been an adequate response from the DECADE
> WG to these reviews. For instance, the requirements did get a lot of
> feedback from Dave Crocker, but this feedback was never addressed in an
> email. I also have been unable to sort out what parts of the feedback
> has been addressed in the updated draft and how, and what parts have not
> been addressed.

I believe all those comments were addressed in the current draft, as I join=
ed the discussion with the authors to address the comments. Their efforts s=
hould be respected. The authors and I would like Dave and Carsten to check =
the draft with their comments, if they are interested. While I admit answer=
ing in the mailing list is a main method to resolve comments, but it is not=
 the only method.

>=20
> I have also received much stronger feedback about the DECADE WG in
> private emails to me. Again from long standing IETF community members
> that send me feedback arguing that DECADE is not having a technical base
> to build on top of.

OK. But general rule for IETF is rough consensus, not private emails. Why n=
ot discuss their questions in the list?

>=20
> You have asked in your other email to give more time to the WG until the
> next IETF meeting in November. This would be one possible way forward,
> but I do know about the past 6 months after the IETF meeting in Paris.
> Not a lot has happened during this period in order to improve the WG
> drafts, in the sense that there is a solid technical base where DECADE
> could continue to work from.

I can answer If your question about the technical base can be more specific=
.

>=20
> Even if you and the whole WG would start to work full-time on the
> drafts, it still would take longer than to the next IETF meeting to move
> the requirements and architecture forward. My gut guessing is that it
> will take at least until March 2013.

> To give an example:
> It is completely unclear how the resources on a DECADE server are
> supposed to be managed and how this management is mapped to the protocol
> split of SDT, DRP, and other management protocols.
> Parts of it, such as setting the permissions of data objects clearly
> belongs to the DRP, and it is sort of stated in a vague way in the
> architecture, but it is not documented in a comprehensive way. Other
> parts, such as the accounting is probably not part of the the DRP nor
> SDT, but there is supposedly another interface that is needed for this.
>=20
> Has this been discussed at any point in the WG?

I just read the email that Richard answered these questions with text from =
the current drafts. And I agree with his answers.

While I respect that AD can make the decision of closing a WG, but I see a =
dozen of emails expressed their disappointment.

BR,
-Haibin


> Given the above points and my summaries out of the last email and the
> one of 6/12, the DECADE WG is going to be closed by today.
>=20
> The DECADE WG mailing list will remain open until the end of the year,
> to let the people a chance to discuss how to go forward with the drafts.
>=20
> As suggest in my earlier email:
> The participants are free to overhaul the drafts and to submit them as
> individual submissions to the RFC Editor's Independent Stream.
>=20
>=20
> The decisions to close the WG can be of course appealed via the IETF
> appeal process:
> See 'Appeals and PR-Actions' under http://www.ietf.org/iesg/ and RFC 2026=
.
>=20
>    Martin
>=20
> >
> > BR,
> > -Haibin
> >
> >
> >> -----Original Message-----
> >> From: Martin Stiemerling [mailto:martin.stiemerling@neclab.eu]
> >> Sent: Friday, September 14, 2012 7:53 PM
> >> To: Songhaibin; Richard Woundy
> >> Subject: DECADE WG to be closed
> >>
> >> Dear Rich and Haibin,
> >>
> >> I have finally done my AD review for the DECADE architecture draft aft=
er
> >> finishing the DECADE requirements draft.
> >>
> >> The first feedback for the DECADE architecture draft has been provided
> >> in the datatracker and sent to the authors and you by email.
> >>
> >> Both drafts are in an extremely bad shape, i.e., they would require a
> >> major overhaul and have been sent back to the working group due to lac=
k
> >> of technical quality.
> >>
> >> I have already expressed my concerns about the energy and the lack of
> >> technical confidence in the group in my summary email of 6/12. The
> >> requirements and architecture drafts got advanced towards the IESG
> >> afterwards. The push for energy was good.
> >>
> >> However, after reviewing the two key drafts, requirements and
> >> architecture, and receiving feedback from IETF community members, I ha=
ve
> >> come to the conclusion that the DECADE working group lacks a sound
> >> technical ground.
> >>
> >> The DECADE group started its work in end of April 2010 and is now
> >> working for more than 2 years on the milestones/drafts. The time isn't=
 a
> >> big deal, but after 2 years I would have expected that the documents a=
re
> >> on a good technical level where the WG can build on top of.
> >>
> >> The issues for the potential future protocol works is that if the basi=
cs
> >> are not well understood and documented, how can the protocols be
> >> designed in a comprehensive and technical sound way?
> >> I cannot see this anymore.
> >> This was also documented in my email on 6/12:
> >> "
> >> I have seen reviews for the ps, the reqs, and the architecture drafts
> >> which go all in the same direction: where is the technical substance,
> >> DECADE will built on?
> >>
> >> The last meeting in Paris was really discouraging with respect to the
> >> technical substance...
> >> Yet another sign of lack of energy in the WG...
> >> "
> >>
> >> The WG did get a grace period starting after the IETF meeting in Paris
> >> and had the chance to really show that it is moving in the right
> >> direction. However, the current state does still not document this and
> >> therefore the DECADE WG will be closed in the next week. I will inform
> >> the WG on Tuesday afternoon CEST.
> >>
> >> The draft authors of the requirements, architecture, and also the
> >> Integration Examples of DECADE System can submit the respective drafts
> >> via the Independent Stream of the RFC editor (see
> >> http://tools.ietf.org/html/rfc6548 for further information), if they
> >> wish to.
> >>
> >> Regards,
> >>
> >>     Martin
> >>
> >> --
> >> IETF Transport Area Director
> >>
> >> martin.stiemerling@neclab.eu
> >>
> >> NEC Laboratories Europe - Network Research Division NEC Europe Limited
> >> Registered Office: NEC House, 1 Victoria Road, London W3 6BL
> >> Registered in England 283
>=20
> --
> martin.stiemerling@neclab.eu
>=20
> NEC Laboratories Europe - Network Research Division NEC Europe Limited
> Registered Office: NEC House, 1 Victoria Road, London W3 6BL
> Registered in England 283

From haibin.song@huawei.com  Sat Sep 22 02:14:03 2012
Return-Path: 
X-Original-To: decade@ietfa.amsl.com
Delivered-To: decade@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79E0021F86F7 for ; Sat, 22 Sep 2012 02:14:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.041
X-Spam-Level: 
X-Spam-Status: No, score=-6.041 tagged_above=-999 required=5 tests=[AWL=0.558,  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 C37h++jh6HdI for ; Sat, 22 Sep 2012 02:14:02 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 1C2CA21F86F6 for ; Sat, 22 Sep 2012 02:14:01 -0700 (PDT)
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 AKY03189; Sat, 22 Sep 2012 09:14:00 +0000 (GMT)
Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Sat, 22 Sep 2012 10:13:30 +0100
Received: from SZXEML439-HUB.china.huawei.com (10.72.61.74) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.3; Sat, 22 Sep 2012 10:13:59 +0100
Received: from SZXEML534-MBX.china.huawei.com ([169.254.2.70]) by szxeml439-hub.china.huawei.com ([10.72.61.74]) with mapi id 14.01.0323.003; Sat, 22 Sep 2012 17:13:48 +0800
From: Songhaibin 
To: Songhaibin , Martin Stiemerling , "Rahman, Akbar" 
Thread-Topic: [decade] WG Action: Conclusion of Decoupled Application Data Enroute (decade)
Thread-Index: AQHNmAK+y9myRhkH+kSZKUqot0hH7peVkf+AgACAWcA=
Date: Sat, 22 Sep 2012 09:13:46 +0000
Message-ID: 
References: <20120919230313.17329.44102.idtracker@ietfa.amsl.com><505AE794.8070304@neclab.eu> <8D38716F0C1A444BA0CD7E96454366C23A4DDEF6@szxeml545-mbx.china.huawei.com>  <505C74F3.7060002@neclab.eu> 
In-Reply-To: 
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.138.41.123]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: "decade@ietf.org" , Konstantinos Pentikousis 
Subject: Re: [decade] WG Action: Conclusion of Decoupled Application Data Enroute (decade)
X-BeenThere: decade@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 22 Sep 2012 09:14:03 -0000

PkFnYWluLCBJIGRvIG5vdCB0aGluayB0aGVzZSB0d28gZG9jdW1lbnRzIGFyZSBleHRyZW1lbHkg
YmFkIGFuZCBsYWNrDQo+IG9mIHRlY2huaWNhbCBzdWJzdGFuY2VzLg0KDQpKdXN0IHRvIG1ha2Ug
YSBjbGFyaWZpY2F0aW9uLCBJIHdhbnRlZCB0byBleHByZXNzIHRoZXNlIHR3byBkb2N1bWVudHMg
YXJlIG5vdCBwZXJmZWN0LCBidXQgdGhleSBhcmUgZ29vZC4gQW5kIEkgYWRtaXQgdGhlIGRvY3Vt
ZW50cyBjb3VsZCBoYXZlIGJlZW4gd3JpdHRlbiBlbGFib3JhdGUgaWYgd2UgcGFpZCBtb3JlIGF0
dGVudGlvbiB0byB0aGUgZWRpdGluZyB3b3JrLg0KDQpCUiwNCi1IYWliaW4NCg0KPiAtLS0tLU9y
aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBkZWNhZGUtYm91bmNlc0BpZXRmLm9yZyBbbWFp
bHRvOmRlY2FkZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YNCj4gU29uZ2hhaWJpbg0K
PiBTZW50OiBTYXR1cmRheSwgU2VwdGVtYmVyIDIyLCAyMDEyIDE6NDkgUE0NCj4gVG86IE1hcnRp
biBTdGllbWVybGluZzsgUmFobWFuLCBBa2Jhcg0KPiBDYzogZGVjYWRlQGlldGYub3JnOyBLb25z
dGFudGlub3MgUGVudGlrb3VzaXMNCj4gU3ViamVjdDogUmU6IFtkZWNhZGVdIFdHIEFjdGlvbjog
Q29uY2x1c2lvbiBvZiBEZWNvdXBsZWQgQXBwbGljYXRpb24gRGF0YQ0KPiBFbnJvdXRlIChkZWNh
ZGUpDQo+IA0KPiA+IFRhbGsgdG8geW91ciBjaGFpcnMgYW5kIGNvbnNpZGVyIHRoYXQgdGhlIHJl
cXVpcmVtZW50cyB3ZW50IGZyb20NCj4gPiBwdWJsaWNhdGlvbiByZXF1ZXN0ZWQgKGkuZS4sIG9u
IHRoZSB3YXkgdG8gdGhlIElFU0cpIGJhY2sgdG8gdGhlIFdHDQo+ID4gKGkuZS4sIG5vdCBvbiB0
aGUgd2F5IHRvIHRoZSBJRVNHKS4NCj4gPg0KPiA+IFRoZSBzYW1lIGlzIHRydWUgZm9yIHRoZSBh
cmNoaXRlY3R1cmUgZHJhZnQuDQo+IA0KPiBJIHdhcyBub3RpZmllZCBpbiBKdW5lIGFib3V0IHRo
ZSBlbmVyZ3kgb2YgdGhlIHdvcmtpbmcgZ3JvdXAsIGJ1dCBJIHdhcyBhbHNvDQo+IHN1cnByaXNl
ZCBhYm91dCB0aGUgYWJydXB0IG5vdGlmaWNhdGlvbiBvZiB0aGUgY2xvc3VyZSBvZiB0aGUgV0cg
d2l0aCB0aGUgZW1haWwNCj4gZnJvbSBNYXJ0aW4gb24gTW9uZGF5LCBJIHNhdyBhIGdvb2QgbGlz
dCBkaXNjdXNzaW9uLCBuZXcgSS1EIHN1Ym1pc3Npb24gYW5kIHdhcw0KPiBwcmVwYXJpbmcgZm9y
IHRoZSBBdGxhbnRhIG1lZXRpbmcgd2hlbiBJIHJlY2VpdmVkIHRoaXMgbm90aWZpY2F0aW9uLiBJ
IGFsc28NCj4gZXhwcmVzc2VkIG15IGRpc2FncmVlIHRvIHRoZSBjb21tZW50IG9mIGxhY2sgb2Yg
dGVjaG5pY2FsIHN1YnN0YW5jZXMuIEJlZm9yZQ0KPiBNYXJ0aW4gYmVjYW1lIHRoZSBBRCBmb3Ig
dGhlIERFQ0FERSBXRywgdGhlIGFyY2hpdGVjdHVyZSBkb2N1bWVudCB3YXMNCj4gaW50ZW5kZWQg
dG8gcmVtb3ZlIGEgbG90IG9mIHRlY2huaWNhbCBkZXRhaWxzIGFjY29yZGluZyB0byBjb21tZW50
cyByZWNlaXZlZCwgaXQncw0KPiBub3QgYSBwcm90b2NvbCBkcmFmdC4NCj4gDQo+IFRoZSBleHRl
bnNpdmUgY29tbWVudHMgZnJvbSBNYXJ0aW4gdG8gdGhlc2UgdHdvIElEcyBhcmUgbW9zdGx5IGVm
ZmVjdGl2ZSwgYnV0DQo+IGVkaXRvcmlhbC4gVGhleSBjb3VsZCBiZSBhZGRyZXNzZWQgdG9nZXRo
ZXIgd2l0aCBLb3N0YXMncyBjb21tZW50cyBpbiB0aGUgbmV4dA0KPiB2ZXJzaW9uIC4gQWdhaW4s
IEkgZG8gbm90IHRoaW5rIHRoZXNlIHR3byBkb2N1bWVudHMgYXJlIGV4dHJlbWVseSBiYWQgYW5k
IGxhY2sNCj4gb2YgdGVjaG5pY2FsIHN1YnN0YW5jZXMuDQo+IA0KPiBCUiwNCj4gLUhhaWJpbg0K

From wangdanhua@huawei.com  Sat Sep 22 02:27:47 2012
Return-Path: 
X-Original-To: decade@ietfa.amsl.com
Delivered-To: decade@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F5E521F86B1 for ; Sat, 22 Sep 2012 02:27:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.974
X-Spam-Level: 
X-Spam-Status: No, score=-0.974 tagged_above=-999 required=5 tests=[AWL=-3.424, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345]
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 0I8N-uwqzrBS for ; Sat, 22 Sep 2012 02:27:46 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id A26B821F8759 for ; Sat, 22 Sep 2012 02:27:45 -0700 (PDT)
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 AKY03820; Sat, 22 Sep 2012 09:27:44 +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; Sat, 22 Sep 2012 10:27:13 +0100
Received: from SZXEML425-HUB.china.huawei.com (10.72.61.33) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.1.323.3; Sat, 22 Sep 2012 10:27:42 +0100
Received: from SZXEML507-MBS.china.huawei.com ([169.254.7.120]) by szxeml425-hub.china.huawei.com ([10.72.61.33]) with mapi id 14.01.0323.003; Sat, 22 Sep 2012 17:27:39 +0800
From: Wangdanhua 
To: zhangyunfei , decade 
Thread-Topic: [decade] Open Issue-4 (draft "An HTTP-based DECADE ResourceProtocol")
Thread-Index: Ac2XD3/qQWNlzkJ7RF6MHYNtHO16vwAA5upAAGQeAzA=
Date: Sat, 22 Sep 2012 09:27:38 +0000
Message-ID: 
References:  <2012092017335583939015@chinamobile.com>
In-Reply-To: <2012092017335583939015@chinamobile.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.138.41.177]
Content-Type: multipart/alternative; boundary="_000_AFD688AF30E249418739DBDC55B9C75B34D7C9ECSZXEML507MBSchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Subject: [decade] =?gb2312?b?tPC4tDogIE9wZW4gSXNzdWUtNCAoZHJhZnQgIkFuIEhU?= =?gb2312?b?VFAtYmFzZWQgREVDQURFIFJlc291cmNlUHJvdG9jb2wiKQ==?=
X-BeenThere: decade@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 22 Sep 2012 09:27:47 -0000

--_000_AFD688AF30E249418739DBDC55B9C75B34D7C9ECSZXEML507MBSchi_
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64

SGkgWXVuZmVpLA0KDQpJbiBteSBtaW5kLCB0aGVyZaGvcmUgbWFueSBzY2VuYXJpb3MgdGhhdCBt
YXkgbmVlZCBwdXNoIG1vZGUvc3Vic2NyaXB0aW9uIG1vZGUsIGUuZy4sIGEgY3VzdG9tZXIgbWF5
IGp1c3QgYmUgaW50ZXJlc3RlZCBpbiBuZXdzIG9yIHZpZGVvcyBvbiBzcG9ydHMgYW5kIGJlIHdp
bGxpbmcgdG8gcGF5IGEgc3Vic2NyaXB0aW9uIHByaWNlIHRvIGhhdmUgYWNjZXNzIHRvIHN1Y2gg
c2VydmljZXMuIEluIHRoaXMga2luZCBvZiBzY2VuYXJpbywgb25jZSB0aGVyZaGvcmUgbGF0ZXN0
IHNwb3J0cyBuZXdzL3ZpZGVvcywgdGhlIGN1c3RvbWVyIHdpbGwgYmUgbm90aWZpZWQgYW5kIHRo
b3NlIG5ld3MvdmlkZW9zIHdpbGwgYmUgcHVzaGVkIHRvIHRoZSBjdXN0b21lci4NCg0KQmVzdCB3
aXNoZXMsDQpEYW5odWEgV2FuZw0KDQoNCreivP7Iyzogemhhbmd5dW5mZWkgW21haWx0bzp6aGFu
Z3l1bmZlaUBjaGluYW1vYmlsZS5jb21dDQq3osvNyrG85DogMjAxMsTqOdTCMjDI1SAxNzozNA0K
ytW8/sjLOiBXYW5nZGFuaHVhOyBkZWNhZGUNCtb3zOI6IFJlOiBbZGVjYWRlXSBPcGVuIElzc3Vl
LTQgKGRyYWZ0ICJBbiBIVFRQLWJhc2VkIERFQ0FERSBSZXNvdXJjZVByb3RvY29sIikNCg0KSGkg
RGFuaHVhLA0KICAgQ291bGQgeW91IGVsYWJvcmF0ZSB5b3VyIGltYWdpbmF0aW9uIG9uIHRoZSB1
c2UgY2FzZSBvZiB0aGUgcHVzaCBtb2RlIFNEVD8gRm9yIG1lIGl0IHNlZW1zIG9rYXkgdG8gdXNl
IHB1c2ggbW9kZSAgZm9yIHB1Ymxpc2gvc3Vic2NyaWJlIGFwcHMsIGUuZy4sIHRoZSBERUNBREUg
c2VydmVyLCBvbiBiZWhhbGYgb2YgREVDQURFIGNsaWVudCwgc3Vic2NyaWJlcyBhIG1hZ2F6aW5l
IGFuZCBvbmx5IG5vdGlmaWVzIHRoZSBERUNBREUgY2xpZW50IGluIGNhc2Ugb2YgZ29vZCBuZXR3
b3JrIGNvbmRpdGlvbi4NCg0KQlINCll1bmZlaQ0KDQpfX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fXw0Kemhhbmd5dW5mZWkNCg0KRnJvbTogV2FuZ2Rhbmh1YTxtYWlsdG86d2FuZ2Rhbmh1
YUBodWF3ZWkuY29tPg0KRGF0ZTogMjAxMi0wOS0yMCAxNzowOA0KVG86IERFQ0FERUBpZXRmLm9y
ZzxtYWlsdG86REVDQURFQGlldGYub3JnPg0KU3ViamVjdDogW2RlY2FkZV0gT3BlbiBJc3N1ZS00
IChkcmFmdCAiQW4gSFRUUC1iYXNlZCBERUNBREUgUmVzb3VyY2VQcm90b2NvbCIpDQpIaSBhbGws
DQoNClRoZSBmb2xsb3dpbmcgaXMgdGhlIGZvcnRoIG9wZW4gaXNzdWUgbGVmdCBmb3IgobBBbiBI
VFRQLWJhc2VkIERFQ0FERSBSZXNvdXJjZSBQcm90b2NvbKGxIChkcmFmdC13YW5nLWRycCkuDQoN
CkFzIHRvIFNEVCwgd2Whr2QgbGlrZSB0byBzdXBwb3J0IGJvdGggcHVzaCBtb2RlIGFuZCBwdWxs
IG1vZGUgd2hpbGUgREVDQURFIENsaWVudCBnZXRzIGRhdGEgb2JqZWN0IGZyb20gaXRzIERFQ0FE
RSBTZXJ2ZXIuIElmIHNvLCBzdWJzY3JpcHRpb24gbW9kZSBoYXMgdG8gYmUgaW50cm9kdWNlZA0K
aW4gREVDQURFLg0KDQpEbyB5b3UgdGhpbmsgaXShr3MgbmVjZXNzYXJ5IHRvIGluY2x1ZGUgYm90
aCB0aGVzZSB0d28gbW9kZXMgb3IganVzdCBwdWxsIG1vZGUgaXMgZW5vdWdoPyBXZaGvcmUgbG9v
a2luZyBmb3J3YXJkIHRvIHlvdXIgb3BpbmlvbnMgYW5kIGNvbW1lbnRzLg0KDQpUaGFua3MhDQoN
CkJlc3Qgd2lzaGVzLA0KRGFuaHVhDQoNCg==

--_000_AFD688AF30E249418739DBDC55B9C75B34D7C9ECSZXEML507MBSchi_
Content-Type: text/html; charset="gb2312"
Content-Transfer-Encoding: quoted-printable











Hi Yunfei,

 


In my mind, there=A1=AFre many =
scenarios that may need push mode/subscription mode, e.g., a customer may j=
ust be interested in news or videos on sports and be willing to pay a subsc=
ription price to have access to such services.
 In this kind of scenario, once there=A1=AFre latest sports news/videos, th=
e customer will be notified and those news/videos will be pushed to the cus=
tomer.


 


Best wishes,<=
/p>

Danhua Wang

&n=
bsp;


&n=
bsp;






=B7=A2=BC=FE=C8=CB: zhangyunfei [mailto:zhangyunfei@chinamobile=
.com]


=B7=A2=
=CB=CD=CA=B1=BC=E4: 2012=C4=EA9=D4=C220=C8=D5
 17:34

=CA=D5=BC=FE=C8=CB: Wangdanhua; decade

=D6=F7=CC=E2: Re: [decade] Open Issue-4 (draft "An HTTP-based DECADE ResourceProto=
col")






 




Hi Danhua,






   Could you elaborate your imaginat=
ion on the use case of the push mode SDT? For me it seems okay to use =
push mode  for publish/subscribe apps,
 e.g., the DECADE server, on behalf of DECADE client, subscribes a magazine=
 and only notifies the DECADE client in case of good network condition=
.






 






BR






Yunfei






 












zhangyunfei






 










From: Wangdanhua






Date: 2012-=
09-20 17:08







Subject:=
 [d=
ecade]
 Open Issue-4 (draft "An HTTP-based DECADE ResourceProtocol")












Hi all,


&nbs=
p;


The follo=
wing is the forth open issue left for =A1=B0An HTTP-based DECADE Resource P=
rotocol=A1=B1 (draft-wang-drp).



&nbs=
p;


As to SDT, we=A1=AFd like to suppor=
t both push mode and pull mode while DECADE Client gets data object from it=
s DECADE Server. If so, subscription mode has
 to be introduced


in DECADE.



&nbs=
p;


Do you th=
ink it=A1=AFs necessary to include both these two modes or just pull mode i=
s enough? We=A1=AFre looking forward to your opinions and comments.


&nbs=
p;


Thanks!


&nbs=
p;


Best wish=
es,


Danhua 


&nbs=
p;










--_000_AFD688AF30E249418739DBDC55B9C75B34D7C9ECSZXEML507MBSchi_--

From pzhang.thu@gmail.com  Sat Sep 22 10:49:17 2012
Return-Path: 
X-Original-To: decade@ietfa.amsl.com
Delivered-To: decade@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EEB021F8674 for ; Sat, 22 Sep 2012 10:49:17 -0700 (PDT)
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 074at2L94Os9 for ; Sat, 22 Sep 2012 10:49:16 -0700 (PDT)
Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 96EBD21F8581 for ; Sat, 22 Sep 2012 10:49:16 -0700 (PDT)
Received: by pbbjt11 with SMTP id jt11so7345290pbb.31 for ; Sat, 22 Sep 2012 10:49:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=9bwP4TgChRWESIr6qI/1Eosq5nwhKQdMpv0wFPEnVCE=; b=fKhDAIoTXs9ZC3BSyrtrJ7LrHhHffWwr1SHrn1q+QADEX6VU42MkJ0eSjfCRi1EsB0 x3Ib3DCxqD6ZMIVCh8Kq2M8xa7HVBxRUOBXtsTXwN2VJkIOo9XMv6MdvTqDjk+n+A0dx XsLJUr+NN2dVQC3fwpYCEPJK+UZLNKxfuYecrnB/rfEpIeEDH0wW7nz8IoA85nKapMb5 RnSHvzTmZBMZVUkAr4Jt0V/34EKR65znB1CrjHPVCEriEy8h0bLQ1r0gSA8padZu721a 9AkMypoSY2Gp1BC+D/c5Kbzfwk0+fdM14TCoPr2D80RV3BBMDuzZgrkndzuP1O6X5tbQ CZ9w==
Received: by 10.68.190.8 with SMTP id gm8mr24964077pbc.74.1348336156260; Sat, 22 Sep 2012 10:49:16 -0700 (PDT)
Received: from th211134.ip.tsinghua.edu.cn (th211134.ip.tsinghua.edu.cn. [59.66.211.134]) by mx.google.com with ESMTPS id i2sm5980573pay.31.2012.09.22.10.49.12 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 22 Sep 2012 10:49:15 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1278)
Content-Type: text/plain; charset=us-ascii
From: Peng Zhang 
In-Reply-To: 
Date: Sun, 23 Sep 2012 01:49:10 +0800
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <50531AB3.6090601@neclab.eu>  <50583257.2080404@neclab.eu> 
To: Martin Stiemerling 
X-Mailer: Apple Mail (2.1278)
Cc: "DECADE@ietf.org" 
Subject: Re: [decade] DECADE WG to be closed
X-BeenThere: decade@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 22 Sep 2012 17:49:17 -0000

Dear Martin,

	I tend to agree with you on some points, but can hardly agree on =
all. For example I cannot agree with your points that.=20

>> The was no and still has not been an adequate response from the =
DECADE
>> WG to these reviews. For instance, the requirements did get a lot of
>> feedback from Dave Crocker, but this feedback was never addressed in =
an

>> email.=20


As far as I know, Richard has called for participation on addressing =
these feedbacks, and gave some valuable points =
(http://www.ietf.org/mail-archive/web/decade/current/msg00694.html). As =
a participant, I tried to address these issues in my later emails. For =
example, I gave some suggestions on how to organize the -req and -arch =
documents =
(http://www.ietf.org/mail-archive/web/decade/current/msg00697.html). =
Also, Stephen and me had a lot of discussions on the issue of object =
naming in -req and -arch documents =
(http://www.ietf.org/mail-archive/web/decade/current/msg00705.html). We =
even cc'ed our discussions to the ppsp wg for comments, and received =
comments from Arno =
(http://www.ietf.org/mail-archive/web/decade/current/msg00741.html).=20

Given this, I don't know why you would arrive at the conclusions that =
"this feedback was never addressed in an email".=20

BR,

Peng.

On Sep 22, 2012, at 2:52 PM, Songhaibin wrote:

> Dear Martin,
>=20
>> -----Original Message-----
>> From: Martin Stiemerling [mailto:martin.stiemerling@neclab.eu]
>> Sent: Tuesday, September 18, 2012 4:36 PM
>> To: Songhaibin
>> Cc: Richard Woundy
>> Subject: Re: DECADE WG to be closed
>>=20
>> Dear Haibin,
>>=20
>> On 09/17/2012 11:39 AM, Songhaibin wrote:
>>> Dear Martin,
>>>=20
>>> Hope everything goes well with you and thank you very much for your =
efforts
>> to reviewing the drafts in detail and giving guidance.
>>>=20
>>> As I agree with most of your comments to the DECADE requirements =
draft, but
>> I have to say IMO the architecture document is not that bad. This =
document gives
>> a clear description of the DECADE server/client components and
>> implementation/design principals which will be reflected in the =
protocols, IMO
>> this is what an architecture document should do.
>>>=20
>>> I do not agree there is lack of technical substances to design a =
base protocol
>> which can satisfy the transport and resource control requirements for =
content
>> distribution applications. Some detailed design choices are still not =
very clear, and
>> need efforts for them.
>>>=20
>>> And recently, the energy is growing, we recently received a lot of =
list discussion
>> including comments from Kostas about the requirements and =
architecture and
>> also a new individual draft for the service discovery was submitted.
>>=20
>> The energy has indeed grown in the WG since before the summer. But, I
>> indicated in my email from mid of June that I have doubts on the
>> technical quality of the DECADE drafts. These doubts have turned into
>> certainty, i.e., see the my AD reviews of the requirements and the
>> architecture.
>>=20
>> The technical quality of the drafts would be ok, if the WG would be =
at
>> the beginning of the process of discussing and writing those drafts, =
but
>> it is not acceptable at the end when the drafts are intended to =
become RFCs:
>> The technical base is just to weak to continue from, even after =
spending
>> time and effort of the WG participants for more than 2 years.
>=20
> The requirements document was accepted on Oct. 18, 2010, and the =
architecture draft was accepted on March 7, 2011.=20
>=20
>>=20
>> Another important data point, as mentioned earlier:
>> There has been public feedback from IETF community members, such as =
Dave
>> Crocker and Carsten Bormann, which questioned the technical base of
>> DECADE as a whole. This happened at the end of the 2011 and in the =
first
>> quarter of 2012.
>=20
>> The was no and still has not been an adequate response from the =
DECADE
>> WG to these reviews. For instance, the requirements did get a lot of
>> feedback from Dave Crocker, but this feedback was never addressed in =
an

>> email. I also have been unable to sort out what parts of the feedback
>> has been addressed in the updated draft and how, and what parts have =
not
>> been addressed.
>=20
> I believe all those comments were addressed in the current draft, as I =
joined the discussion with the authors to address the comments. Their =
efforts should be respected. The authors and I would like Dave and =
Carsten to check the draft with their comments, if they are interested. =
While I admit answering in the mailing list is a main method to resolve =
comments, but it is not the only method.
>=20
>>=20
>> I have also received much stronger feedback about the DECADE WG in
>> private emails to me. Again from long standing IETF community members
>> that send me feedback arguing that DECADE is not having a technical =
base
>> to build on top of.
>=20
> OK. But general rule for IETF is rough consensus, not private emails. =
Why not discuss their questions in the list?
>=20
>>=20
>> You have asked in your other email to give more time to the WG until =
the
>> next IETF meeting in November. This would be one possible way =
forward,
>> but I do know about the past 6 months after the IETF meeting in =
Paris.
>> Not a lot has happened during this period in order to improve the WG
>> drafts, in the sense that there is a solid technical base where =
DECADE
>> could continue to work from.
>=20
> I can answer If your question about the technical base can be more =
specific.
>=20
>>=20
>> Even if you and the whole WG would start to work full-time on the
>> drafts, it still would take longer than to the next IETF meeting to =
move
>> the requirements and architecture forward. My gut guessing is that it
>> will take at least until March 2013.
>=20
>> To give an example:
>> It is completely unclear how the resources on a DECADE server are
>> supposed to be managed and how this management is mapped to the =
protocol
>> split of SDT, DRP, and other management protocols.
>> Parts of it, such as setting the permissions of data objects clearly
>> belongs to the DRP, and it is sort of stated in a vague way in the
>> architecture, but it is not documented in a comprehensive way. Other
>> parts, such as the accounting is probably not part of the the DRP nor
>> SDT, but there is supposedly another interface that is needed for =
this.
>>=20
>> Has this been discussed at any point in the WG?
>=20
> I just read the email that Richard answered these questions with text =
from the current drafts. And I agree with his answers.
>=20
> While I respect that AD can make the decision of closing a WG, but I =
see a dozen of emails expressed their disappointment.
>=20
> BR,
> -Haibin
>=20
>=20
>> Given the above points and my summaries out of the last email and the
>> one of 6/12, the DECADE WG is going to be closed by today.
>>=20
>> The DECADE WG mailing list will remain open until the end of the =
year,
>> to let the people a chance to discuss how to go forward with the =
drafts.
>>=20
>> As suggest in my earlier email:
>> The participants are free to overhaul the drafts and to submit them =
as
>> individual submissions to the RFC Editor's Independent Stream.
>>=20
>>=20
>> The decisions to close the WG can be of course appealed via the IETF
>> appeal process:
>> See 'Appeals and PR-Actions' under http://www.ietf.org/iesg/ and RFC =
2026.
>>=20
>>   Martin
>>=20
>>>=20
>>> BR,
>>> -Haibin
>>>=20
>>>=20
>>>> -----Original Message-----
>>>> From: Martin Stiemerling [mailto:martin.stiemerling@neclab.eu]
>>>> Sent: Friday, September 14, 2012 7:53 PM
>>>> To: Songhaibin; Richard Woundy
>>>> Subject: DECADE WG to be closed
>>>>=20
>>>> Dear Rich and Haibin,
>>>>=20
>>>> I have finally done my AD review for the DECADE architecture draft =
after
>>>> finishing the DECADE requirements draft.
>>>>=20
>>>> The first feedback for the DECADE architecture draft has been =
provided
>>>> in the datatracker and sent to the authors and you by email.
>>>>=20
>>>> Both drafts are in an extremely bad shape, i.e., they would require =
a
>>>> major overhaul and have been sent back to the working group due to =
lack
>>>> of technical quality.
>>>>=20
>>>> I have already expressed my concerns about the energy and the lack =
of
>>>> technical confidence in the group in my summary email of 6/12. The
>>>> requirements and architecture drafts got advanced towards the IESG
>>>> afterwards. The push for energy was good.
>>>>=20
>>>> However, after reviewing the two key drafts, requirements and
>>>> architecture, and receiving feedback from IETF community members, I =
have
>>>> come to the conclusion that the DECADE working group lacks a sound
>>>> technical ground.
>>>>=20
>>>> The DECADE group started its work in end of April 2010 and is now
>>>> working for more than 2 years on the milestones/drafts. The time =
isn't a
>>>> big deal, but after 2 years I would have expected that the =
documents are
>>>> on a good technical level where the WG can build on top of.
>>>>=20
>>>> The issues for the potential future protocol works is that if the =
basics
>>>> are not well understood and documented, how can the protocols be
>>>> designed in a comprehensive and technical sound way?
>>>> I cannot see this anymore.
>>>> This was also documented in my email on 6/12:
>>>> "
>>>> I have seen reviews for the ps, the reqs, and the architecture =
drafts
>>>> which go all in the same direction: where is the technical =
substance,
>>>> DECADE will built on?
>>>>=20
>>>> The last meeting in Paris was really discouraging with respect to =
the
>>>> technical substance...
>>>> Yet another sign of lack of energy in the WG...
>>>> "
>>>>=20
>>>> The WG did get a grace period starting after the IETF meeting in =
Paris
>>>> and had the chance to really show that it is moving in the right
>>>> direction. However, the current state does still not document this =
and
>>>> therefore the DECADE WG will be closed in the next week. I will =
inform
>>>> the WG on Tuesday afternoon CEST.
>>>>=20
>>>> The draft authors of the requirements, architecture, and also the
>>>> Integration Examples of DECADE System can submit the respective =
drafts
>>>> via the Independent Stream of the RFC editor (see
>>>> http://tools.ietf.org/html/rfc6548 for further information), if =
they
>>>> wish to.
>>>>=20
>>>> Regards,
>>>>=20
>>>>    Martin
>>>>=20
>>>> --
>>>> IETF Transport Area Director
>>>>=20
>>>> martin.stiemerling@neclab.eu
>>>>=20
>>>> NEC Laboratories Europe - Network Research Division NEC Europe =
Limited
>>>> Registered Office: NEC House, 1 Victoria Road, London W3 6BL
>>>> Registered in England 283
>>=20
>> --
>> martin.stiemerling@neclab.eu
>>=20
>> NEC Laboratories Europe - Network Research Division NEC Europe =
Limited
>> Registered Office: NEC House, 1 Victoria Road, London W3 6BL
>> Registered in England 283


From Akbar.Rahman@InterDigital.com  Sat Sep 22 19:47:30 2012
Return-Path: 
X-Original-To: decade@ietfa.amsl.com
Delivered-To: decade@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFB7A21F8559 for ; Sat, 22 Sep 2012 19:47:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.491
X-Spam-Level: 
X-Spam-Status: No, score=-2.491 tagged_above=-999 required=5 tests=[AWL=0.108,  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 7cyocyVamXnb for ; Sat, 22 Sep 2012 19:47:30 -0700 (PDT)
Received: from idcout.InterDigital.com (smtp-out1.interdigital.com [64.208.228.135]) by ietfa.amsl.com (Postfix) with ESMTP id 8F35A21F8555 for ; Sat, 22 Sep 2012 19:47:29 -0700 (PDT)
Received: from SAM.InterDigital.com ([10.30.2.11]) by idcout.InterDigital.com with Microsoft SMTPSVC(6.0.3790.4675);  Sat, 22 Sep 2012 22:47:28 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01CD9935.C5176CBA"
Date: Sat, 22 Sep 2012 22:47:25 -0400
Message-ID: 
In-Reply-To: 
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
Thread-Topic: [decade] WG Action: Conclusion of Decoupled Application Data Enroute (decade)
Thread-Index: AQHNmAK+y9myRhkH+kSZKUqot0hH7peVkf+AgAGky2A=
References: <20120919230313.17329.44102.idtracker@ietfa.amsl.com><505AE794.8070304@neclab.eu><8D38716F0C1A444BA0CD7E96454366C23A4DDEF6@szxeml545-mbx.china.huawei.com> <505C74F3.7060002@neclab.eu> 
From: "Rahman, Akbar" 
To: "Songhaibin" , "Martin Stiemerling" 
X-OriginalArrivalTime: 23 Sep 2012 02:47:28.0113 (UTC) FILETIME=[C5015E10:01CD9935]
Cc: decade@ietf.org, Konstantinos Pentikousis 
Subject: Re: [decade] WG Action: Conclusion of Decoupled Application Data Enroute (decade)
X-BeenThere: decade@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 23 Sep 2012 02:47:30 -0000

This is a multi-part message in MIME format.

------_=_NextPart_001_01CD9935.C5176CBA
Content-Type: text/plain;
	charset="UTF-8"
Content-Transfer-Encoding: base64

Rm9yIHRoZSByZWNvcmQsIGhlcmUgaXMgdGhlIGludGVybmFsIFdvcmQgdHJhY2tpbmcgZG9jdW1l
bnQgZnJvbSBKdW5lIDIwMTIgdGhhdCB0aGUgYXV0aG9ycyB1c2VkIHRvIGVuc3VyZSB0aGF0IHdl
IGFkZHJlc3NlZCBhbGwgdGhlIGNvbW1lbnRzIHRoYXQgd2UgcmVjZWl2ZWQgZnJvbSBDYXJzdGVu
IChBcHBzIEFyZWEgUmV2aWV3ZXIpIGFuZCBEYXZlIEhhcnJpbmd0b24gKFByZXZpb3VzIEFEKSBv
biB0aGUgQXJjaGl0ZWN0dXJlIEktRCBSZXYuIDA0LiAgQWxsIHRoZXNlIGNvbW1lbnRzIHdlcmUg
aW5jb3Jwb3JhdGVkIGludG8gdGhlIHN1YnNlcXVlbnQgdmVyc2lvbnMgb2YgdGhlIEFyY2hpdGVj
dHVyZSBJLUQuICBUaGUgYXV0aG9ycyBoYWQga2VwdCB0aGUgY2hhaXJzIGluIHRoZSBsb29wIHdp
dGggdGhlIHRyYWNraW5nIGRvY3VtZW50Lg0KDQpUaGlzIGlzIHBhcnQgb2YgdGhlIHJlYXNvbiB0
aGF0IHRoZSBhdXRob3JzIHRha2Ugb2ZmZW5zZSB0byAoYW5kIGFyZSBwdXp6bGVkIGJ5KSB0aGUg
c3VnZ2VzdGlvbiB0aGF0IHdlIGRpZCBub3Qgc2VyaW91c2x5IGFkZHJlc3MgdGhlIGNvbW1lbnRz
IHRoYXQgd2UgZ290IGZyb20gdmFyaW91cyByZXZpZXdlcnMuDQoNCg0KL0FrYmFyDQoNCg0KDQot
LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogU29uZ2hhaWJpbiBbbWFpbHRvOmhhaWJp
bi5zb25nQGh1YXdlaS5jb21dIA0KU2VudDogU2F0dXJkYXksIFNlcHRlbWJlciAyMiwgMjAxMiAx
OjQ5IEFNDQpUbzogTWFydGluIFN0aWVtZXJsaW5nOyBSYWhtYW4sIEFrYmFyDQpDYzogZGVjYWRl
QGlldGYub3JnOyBLb25zdGFudGlub3MgUGVudGlrb3VzaXMNClN1YmplY3Q6IFJFOiBbZGVjYWRl
XSBXRyBBY3Rpb246IENvbmNsdXNpb24gb2YgRGVjb3VwbGVkIEFwcGxpY2F0aW9uIERhdGEgRW5y
b3V0ZSAoZGVjYWRlKQ0KDQo+IFRhbGsgdG8geW91ciBjaGFpcnMgYW5kIGNvbnNpZGVyIHRoYXQg
dGhlIHJlcXVpcmVtZW50cyB3ZW50IGZyb20NCj4gcHVibGljYXRpb24gcmVxdWVzdGVkIChpLmUu
LCBvbiB0aGUgd2F5IHRvIHRoZSBJRVNHKSBiYWNrIHRvIHRoZSBXRw0KPiAoaS5lLiwgbm90IG9u
IHRoZSB3YXkgdG8gdGhlIElFU0cpLg0KPiANCj4gVGhlIHNhbWUgaXMgdHJ1ZSBmb3IgdGhlIGFy
Y2hpdGVjdHVyZSBkcmFmdC4NCg0KSSB3YXMgbm90aWZpZWQgaW4gSnVuZSBhYm91dCB0aGUgZW5l
cmd5IG9mIHRoZSB3b3JraW5nIGdyb3VwLCBidXQgSSB3YXMgYWxzbyBzdXJwcmlzZWQgYWJvdXQg
dGhlIGFicnVwdCBub3RpZmljYXRpb24gb2YgdGhlIGNsb3N1cmUgb2YgdGhlIFdHIHdpdGggdGhl
IGVtYWlsIGZyb20gTWFydGluIG9uIE1vbmRheSwgSSBzYXcgYSBnb29kIGxpc3QgZGlzY3Vzc2lv
biwgbmV3IEktRCBzdWJtaXNzaW9uIGFuZCB3YXMgcHJlcGFyaW5nIGZvciB0aGUgQXRsYW50YSBt
ZWV0aW5nIHdoZW4gSSByZWNlaXZlZCB0aGlzIG5vdGlmaWNhdGlvbi4gSSBhbHNvIGV4cHJlc3Nl
ZCBteSBkaXNhZ3JlZSB0byB0aGUgY29tbWVudCBvZiBsYWNrIG9mIHRlY2huaWNhbCBzdWJzdGFu
Y2VzLiBCZWZvcmUgTWFydGluIGJlY2FtZSB0aGUgQUQgZm9yIHRoZSBERUNBREUgV0csIHRoZSBh
cmNoaXRlY3R1cmUgZG9jdW1lbnQgd2FzIGludGVuZGVkIHRvIHJlbW92ZSBhIGxvdCBvZiB0ZWNo
bmljYWwgZGV0YWlscyBhY2NvcmRpbmcgdG8gY29tbWVudHMgcmVjZWl2ZWQsIGl0J3Mgbm90IGEg
cHJvdG9jb2wgZHJhZnQuDQoNClRoZSBleHRlbnNpdmUgY29tbWVudHMgZnJvbSBNYXJ0aW4gdG8g
dGhlc2UgdHdvIElEcyBhcmUgbW9zdGx5IGVmZmVjdGl2ZSwgYnV0IGVkaXRvcmlhbC4gVGhleSBj
b3VsZCBiZSBhZGRyZXNzZWQgdG9nZXRoZXIgd2l0aCBLb3N0YXMncyBjb21tZW50cyBpbiB0aGUg
bmV4dCB2ZXJzaW9uIC4gQWdhaW4sIEkgZG8gbm90IHRoaW5rIHRoZXNlIHR3byBkb2N1bWVudHMg
YXJlIGV4dHJlbWVseSBiYWQgYW5kIGxhY2sgb2YgdGVjaG5pY2FsIHN1YnN0YW5jZXMuIA0KDQpC
UiwNCi1IYWliaW4NCg==

------_=_NextPart_001_01CD9935.C5176CBA
Content-Type: application/msword;
	name="TrackingforupdatestoDECADEArchitecturedraft_06.doc"
Content-Transfer-Encoding: base64
Content-Description: TrackingforupdatestoDECADEArchitecturedraft_06.doc
Content-Disposition: attachment;
	filename="TrackingforupdatestoDECADEArchitecturedraft_06.doc"

0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAACAAAAtAAAAAAAAAAA
EAAAtgAAAAEAAAD+////AAAAALIAAACzAAAA////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
///////////////////////////////////////////////////////////////////////////s
pcEAecAJBAAA+BK/AAAAAAAAEAAAAAAACAAAWKAAAA4AYmpiar0RvREAAAAAAAAAAAAAAAAAAAAA
AAAJBBYALuYAAN97AADfewAALokAAAAAAAAAAAAAAAAAACkPAAAAAAAAAAAAAAAAAAD//w8AAAAA
AAAAAAD//w8AAAAAAAAAAAD//w8AAAAAAAAAAAAAAAAAAAAAALcAAAAAAEYOAAAAAAAARg4AAKAb
AAAAAAAAoBsAAAAAAADQGwAALgkAANgpAAAcAQAA9CoAABQAAAAAAAAAAAAAAP////8AAAAACCsA
AAAAAAAIKwAAAAAAAAgrAAAAAAAACCsAAFwAAABkKwAAvAAAAAgrAAAAAAAAnkYAAFgCAAAgLAAA
XgAAAH4sAAAAAAAAfiwAAAAAAAB+LAAAAAAAAH4sAAAAAAAAWS0AAAAAAABZLQAAAAAAAFktAAAA
AAAAHUYAAAIAAAAfRgAAAAAAAB9GAAAAAAAAH0YAAAAAAAAfRgAAAAAAAB9GAAAAAAAAH0YAACQA
AAD2SAAAsgIAAKhLAABEAAAAQ0YAABUAAAAAAAAAAAAAAAAAAAAAAAAAoBsAADAAAABZLQAAKgAA
AAAAAAAAAAAAAAAAAAAAAABZLQAAAAAAAFktAAAAAAAAgy0AABwAAACfLQAAEAAAAENGAAAAAAAA
AAAAAAAAAACgGwAAAAAAAKAbAAAAAAAAfiwAAAAAAAAAAAAAAAAAAH4sAADbAAAAWEYAABYAAACv
PwAAAAAAAK8/AAAAAAAArz8AAAAAAACvLQAA4AIAAKAbAAAAAAAAfiwAAAAAAACgGwAAAAAAAH4s
AAAAAAAAHUYAAAAAAAAAAAAAAAAAAK8/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAWS0AAAAAAAAdRgAAAAAAAAAAAAAAAAAArz8AAAAAAACvPwAA
OgAAAI9FAAAsAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA3UUAAAAAAAB+LAAAAAAAAP////8AAAAAgKDXCSIw
zQEAAAAAAAAAAP////8AAAAAjzAAANQOAAC7RQAAGAAAAAAAAAAAAAAACUYAABQAAABuRgAAMAAA
AJ5GAAAAAAAA00UAAAoAAADsSwAAAAAAAGM/AABMAAAA7EsAABQAAADdRQAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAOxLAAAAAAAAAAAAAAAAAAD+JAAA2gQAAN1FAAAsAAAAAAAAAAAAAAAAAAAAAAAAAK8/
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAWS0A
AAAAAABZLQAAAAAAAFktAAAAAAAAQ0YAAAAAAABDRgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAArz8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFktAAAA
AAAAWS0AAAAAAABZLQAAAAAAAJ5GAAAAAAAAWS0AAAAAAABZLQAAAAAAAFktAAAAAAAAWS0AAAAA
AAAAAAAAAAAAAP////8AAAAA/////wAAAAD/////AAAAAAAAAAAAAAAA/////wAAAAD/////AAAA
AP////8AAAAA/////wAAAAD/////AAAAAP////8AAAAA/////wAAAAD/////AAAAAP////8AAAAA
/////wAAAAD/////AAAAAP////8AAAAA/////wAAAAD/////AAAAAOxLAAAAAAAAWS0AAAAAAABZ
LQAAAAAAAFktAAAAAAAAWS0AAAAAAABZLQAAAAAAAFktAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABZLQAAAAAAAFktAAAAAAAAWS0A
AAAAAABGDgAAIAwAAGYaAAA6AQAABQASAQAACQQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFdlIHJl
Y2VpdmVkIGEgbGFyZ2UgbnVtYmVyIG9mIGdvb2QgY29tbWVudHMgb24gIHRoZSBERUNBREUgQXJj
aGl0ZWN0dXJlIEktRCBmcm9tIENhcnN0ZW4gQm9ybWFubiAoQXBwcyBBcmVhIHJldmlldykgYW5k
IERhdmUgSGFycmluZ3RvbiAoQUQgcmV2aWV3KS4gIEZvbGxvd2luZyBpcyBhbiBhbmFseXNpcyBv
ZiB0aGUgY29tbWVudHMgd2l0aCBhIHByb3Bvc2VkIHNvbHV0aW9uIHdoZW5ldmVyIHBvc3NpYmxl
LiAgU2luY2UgdGhlcmUgd2VyZSBtYW55IHJlbGF0ZWQgY29tbWVudHMsIEkgaGF2ZSBncm91cGVk
IHRoZSBjb21tZW50cy4gIEFsc28sIGJlY2F1c2UgdGhlIHByb3Bvc2VkIHNvbHV0aW9ucyByZXF1
aXJlIGV4dGVuc2l2ZSByZS13cml0ZXMgb2YgdGhlIEktRCwgSSB3b3VsZCBsaWtlIHRvIGdldCB0
aGUgZmVlZGJhY2sgb2YgdGhlIG90aGVyIGF1dGhvcnMgYW5kIGNoYWlycyBiZWZvcmUgSSBnbyBh
aGVhZCBhbmQgbWFrZSB0aGUgdXBkYXRlcyBpbiB0aGUgSS1ELg0NR3JvdXBlZCBjb21tZW50cyBv
biB0aGUgc3RydWN0dXJlIGFuZCBjb250ZW50cyBvZiB0aGUgSS1EOg1Ub28gbXVjaCAoY29uZnVz
aW5nKSBpbXBsZW1lbnRhdGlvbiBkZXRhaWxzIGluIGEgZG9jdW1lbnQgdGhhdCBpcyBzdXBwb3Nl
ZCB0byBiZSBmb2N1c2VkIG9uIGFyY2hpdGVjdHVyZQ1TcGVjaWZpYyBjb21tZW50czogU2VlIHRo
ZSBjb21tZW50cyBiZWxvdyBoaWdobGlnaHRlZCBpbiBncmVlbi4NUHJvcG9zZWQgc29sdXRpb246
IFdlIG5lZWQgdG8gYWJzdHJhY3Qgb3V0IChhbmQgZWxpbWluYXRlKSB0aGUgaW1wbGVtZW50YXRp
b24gZGV0YWlscyBhcyB0aGlzIGFwcGVhcnMgdG8gYmUgYSBjYXNlIG9mIGxvc2luZyBzaWdodCBv
ZiB0aGUgZm9yZXN0IGJlY2F1c2Ugb2YgdGhlIHRyZWVzLiAgU3BlY2lmaWNhbGx5LCBzZWN0aW9u
IDUgcHJvYmFibHkgbmVlZHMgdG8gYmUgc3Vic3RhbnRpYWxseSBkb3duc2l6ZWQuDQ1TRFQgYW5k
IERSUCBndWlkYW5jZSBpcyBub3QgY2xlYXIgYW5kIGlzIGluY29tcGxldGUNU3BlY2lmaWMgY29t
bWVudHM6IFNlZSB0aGUgY29tbWVudHMgYmVsb3cgaGlnaGxpZ2h0ZWQgaW4gYmx1ZS4NUHJvcG9z
ZWQgc29sdXRpb246IFRoZSBjb21tZW50cyB3ZXJlIHF1aXRlIGZ1bmRhbWVudGFsIGZyb20gdGhl
IHNsb2dhbnMgd2Ugd2VyZSB1c2luZyB0byBob3cgd2UgZGVzY3JpYmVkIHRoZSBsb2dpY2FsIHJl
bGF0aW9uIGJldHdlZW4gdGhlIHR3by4gIFdlIG5lZWQgdG8gaGF2ZSBhIGdyb3VwIGRpc2N1c3Np
b24gb24gaG93IHdlIHdhbnQgdG8gYWRkcmVzcyB0aGlzIGlzc3VlLg0NQW5hbHlzaXMgb2YgZXhp
c3RpbmcgcHJvdG9jb2xzIGZvciBERUNBREUgaXMgaW5jb21wbGV0ZSBhbmQgYmlhc2VkIHRvd2Fy
ZHMgSFRUUA1TcGVjaWZpYyBjb21tZW50czogIFNlZSB0aGUgY29tbWVudHMgYmVsb3cgaGlnaGxp
Z2h0ZWQgaW4gcHVycGxlLg1Qcm9wb3NlZCBzb2x1dGlvbjogV2Ugc2hvdWxkIHNlbGVjdCBhbmQg
cmVjb21tZW5kIGEgc3BlY2lmaWMgcHJvdG9jb2wuICBPdGhlcndpc2Ugd2Ugc2hvdWxkIGp1c3Qg
aW5kaWNhdGUgYSBsaXN0IG9mIHBvdGVudGlhbCBwcm90b2NvbHMgKGFuZCB0aGVuIGVsaW1pbmF0
ZSBBcHBlbmRpeCBBKS4gDQ1OYW1pbmcgZ3VpZGVsaW5lcyAoaW5jbHVkaW5nIGltbXV0YWJsZSBu
YXR1cmUgb2YgZGF0YSkgYXJlIG5vdCBjbGVhciBhbmQgaXMgaW5jb21wbGV0ZQ1TcGVjaWZpYyBj
b21tZW50czogU2VlIHRoZSBjb21tZW50cyBiZWxvdyBoaWdobGlnaHRlZCBpbiBvcmFuZ2UuDVBy
b3Bvc2VkIHNvbHV0aW9uOiBJIHRoaW5rIHRoYXQgaWYgd2UgY2xlYW4gdXAgdGhlIHRleHQgKGUu
Zy4gc2VjdGlvbiA1LjMpIGFuZCBtYWtlIGl0IG1vcmUgZm9jdXNlZCB3ZSB3aWxsIGFkZHJlc3Mg
dGhlIGNvbmNlcm5zLiAgSSBkaWRuknQgZ2V0IHRoZSBzZW5zZSB0aGF0IHRoZXkgZnVuZGFtZW50
YWxseSBvYmplY3RlZCB0byBvdXIgYXBwcm9hY2guDQ1TZWN1cml0eSBhbmFseXNpcyAmIGd1aWRl
bGluZXMgKGluY2x1ZGluZyBUb2tlbnMsIEFjY2VzcyBDb250cm9sLCBldGMuKSBhcmUgbm90IGNs
ZWFyIGFuZCBpcyBpbmNvbXBsZXRlDVNwZWNpZmljIGNvbW1lbnRzOiBTZWUgdGhlIGNvbW1lbnRz
IGJlbG93IGhpZ2hsaWdodGVkIGluIHJlZA1Qcm9wb3NlZCBzb2x1dGlvbjogSSB0aGluayB0aGF0
IGlmIHdlIGJlZWYgdXAgdGhlIGRlc2NyaXB0aW9uIChlLmcuIHNlY3Rpb24gNS40IGFuZCA5KSBh
bmQgbWFrZSBpdCBtb3JlIGZvY3VzZWQgd2Ugd2lsbCBhZGRyZXNzIHRoZSBjb25jZXJucy4gIEkg
ZGlkbpJ0IGdldCB0aGUgc2Vuc2UgdGhhdCB0aGV5IGZ1bmRhbWVudGFsbHkgb2JqZWN0ZWQgdG8g
b3VyIGFwcHJvYWNoLg0NVmFyaWV0eSBvZiBtaXNjZWxsYW5lb3VzIGNvbW1lbnRzDVNwZWNpZmlj
IGNvbW1lbnRzOiBTZWUgcmVtYWluaW5nICh1bi1zaGFkZWQpIGNvbW1lbnRzDVByb3Bvc2VkIHNv
bHV0aW9uOiBBIGxvdCBvZiBjb21tZW50cyBidXQgbm90aGluZyBmdW5kYW1lbnRhbCBmcm9tIHdo
YXQgSSBjb3VsZCB0ZWxsLiAgSnVzdCBuZWVkcyBhIGxvdCBvZiB0aW1lIHRvIGFkZHJlc3MgdGhl
bSBvbmUgYnkgb25lLg0NLS0tLS0gQ2Fyc3RlbiBCb3JtYW5uknMgQ29tbWVudHMgLS0tLS0LRnJv
bTogZGVjYWRlLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpkZWNhZGUtYm91bmNlc0BpZXRmLm9y
Z10gT24gQmVoYWxmIE9mIENhcnN0ZW4gQm9ybWFubgtTZW50OiBTdW5kYXksIEphbnVhcnkgMjIs
IDIwMTIgODo0NCBQTQtUbzogSUVURiBBcHBzIERpc2N1c3M7IGRyYWZ0LWlldGYtZGVjYWRlLWFy
Y2gtMDQuYWxsQHRvb2xzLmlldGYub3JnC0NjOiBkZWNhZGVAaWV0Zi5vcmc7IFNNC1N1YmplY3Q6
IFtkZWNhZGVdIEFQUFNESVIgcmV2aWV3IG9mIGRyYWZ0LWlldGYtZGVjYWRlLWFyY2gtMDQNDUkg
aGF2ZSBiZWVuIHNlbGVjdGVkIGFzIHRoZSBBcHBsaWNhdGlvbnMgQXJlYSBEaXJlY3RvcmF0ZSBy
ZXZpZXdlciBmb3INdGhpcyBkcmFmdCAoZm9yIGJhY2tncm91bmQgb24gQVBQU0RJUiwgcGxlYXNl
IHNlZQ1odHRwOi8vdHJhYy50b29scy5pZXRmLm9yZy9hcmVhL2FwcC90cmFjL3dpa2kvQXBwbGlj
YXRpb25zQXJlYURpcmVjdG9yYXRlKS4NDVBsZWFzZSByZXNvbHZlIHRoZXNlIGNvbW1lbnRzIGFs
b25nIHdpdGggYW55IG90aGVyIExhc3QgQ2FsbCBjb21tZW50cw15b3UgbWF5IHJlY2VpdmUuIFBs
ZWFzZSB3YWl0IGZvciBkaXJlY3Rpb24gZnJvbSB5b3VyIGRvY3VtZW50IHNoZXBoZXJkDW9yIEFE
IGJlZm9yZSBwb3N0aW5nIGEgbmV3IHZlcnNpb24gb2YgdGhlIGRyYWZ0Lg0NR3J1ZXNzZSwgQ2Fy
c3Rlbg0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NDURvY3VtZW50OiBkcmFmdC1p
ZXRmLWRlY2FkZS1hcmNoLTA0DVRpdGxlOiBERUNBREUgQXJjaGl0ZWN0dXJlDVJldmlld2VyOiBD
YXJzdGVuIEJvcm1hbm4NUmV2aWV3IERhdGU6IDIwMTItMDEtMjINDQ0qKiBTdW1tYXJ5OiBUaGlz
IGRyYWZ0IGlzIG5vdCByZWFkeSBmb3IgcHVibGljYXRpb24gYXMgYW4NSW5mb3JtYXRpb25hbCBS
RkMgYW5kIHNob3VsZCBiZSByZXZpc2VkIGJlZm9yZSBwdWJsaWNhdGlvbi4NDU5vdGU6IEkgZGVj
aWRlZCB0byByZXZpZXcgdGhpcyBieSByZWFkaW5nIHRoZSBhcmNoaXRlY3R1cmUgZG9jdW1lbnQN
b25seSwgdG8gc2VlIHdoZXRoZXIgaXQgaXMgYWJsZSB0byBzdGFuZCBhbG9uZS4gIE5vdGUgdGhh
dCB0aGlzDWltcGxpZXMgdGhhdCB0aGUgcmV2aWV3IGlzIGxpa2VseSBpbmNvbXBsZXRlLiAgR2l2
ZW4gdGhlIGNsdXN0ZXIgb2YNZW50YW5nbGVkIGRvY3VtZW50cyB0aGlzIGlzIGEgcGFydCBvZiwg
SSByZWNvbW1lbmQgYSBjb25jZXJ0ZWQgcmV2aWV3DW9mIHRoZSBuZXh0IHZlcnNpb24ocykuDQ0N
KiogTWFqb3IgSXNzdWVzOg0NQTEpIEdlbmVyYWw6DQ1BbHRob3VnaCB0aGlzIGlzIG5vdCBleHBs
aWNpdGx5IHNhaWQgaW4gdGhlIGludHJvZHVjdGlvbiwgdGhlDW9iamVjdGl2ZSBvZiB0aGlzIGRv
Y3VtZW50IGFwcGVhcnMgdG8gYmUgYm90aDoNLS0gdG8gcHJvdmlkZSBhbiBhcmNoaXRlY3R1cmUg
dGhhdCB3aWxsIGNvbnN0cmFpbiBhbmQgZ3VpZGUgdGhlDSAgIGZ1cnRoZXIgd29yayBvZiBERUNB
REU7DS0tIHRvIHByZXNlbnQgdGhlIGFyY2hpdGVjdHVyZSBpbiBhbiBpbnRyb2R1Y3RvcnksIHJl
YXNvbmFibHkNICAgYWNjZXNzaWJsZSB3YXksIHdoaWNoIHdpbGwgZmFjaWxpdGF0ZSB1bmRlcnN0
YW5kaW5nIHRoZSBzcGVjaWZpYw0gICBwcm90b2NvbCBzcGVjaWZpY2F0aW9ucyBlbnZpc2FnZWQu
DQ1UaGVzZSB0d28gKHByZXNjcmlwdGl2ZSB2cy4gZGVzY3JpcHRpdmUpIG9iamVjdGl2ZXMgb2Yg
dGhpcyBkb2N1bWVudA1kbyBjb25mbGljdCwgYW5kIHRoZSBjb25mbGljdCBpcyBub3QgYWx3YXlz
IG1hbmFnZWQuDQ1JbiBwYXJ0aWN1bGFyLCB0aGUgZG9jdW1lbnQgZ29lcyB0byBjb25zaWRlcmFi
bGUgZGV0YWlsIGluIGRlc2NyaWJpbmcNdGhlIHByb3RvY29scywgYnV0IGl0IGlzIG5vdCBjbGVh
ciB3aGV0aGVyIHRoaXMgaXMganVzdCBpbGx1c3RyYXRpbmcNdGhlIGFyY2hpdGVjdHVyZSAoYXMg
SSB3b3VsZCBleHBlY3QgaW4gYW4gYXJjaGl0ZWN0dXJlIGRvY3VtZW50KSBvcg1hY3R1YWxseSBj
b25zdHJhaW5pbmcgdGhlIHByb3RvY29sIGRlc2lnbi4gIEUuZy4sDS0tIGZvciB0aGUgd3JpdGUt
dGhyb3VnaCBQVVQgKHNlY3Rpb24gNy4xKSwgaXQgaXMgc3BlY2lmaWVkIHRoYXQganVzdA0gICBv
bmUgdGFyZ2V0IHNlcnZlciBjYW4gYmUgZ2l2ZW4gdG8gdGhlIGludGVybWVkaWFyeS4gIElzIHRo
aXMgYW4NICAgYWNjaWRlbnQgb3IgZGVsaWJlcmF0ZT8NLS0gRm9yIEdFVCwgcmV0dXJuaW5nIHRo
ZSBkYXRhIGlzIG9wdGlvbmFsIChzZWN0aW9uIDcuMSk/DS0tICJEUlAgaXMgc3BlY2lmaWVkIGFz
IGJlaW5nIGNhcnJpZWQgdGhyb3VnaCBleHRlbnNpb24gZmllbGRzIHdpdGhpbg0gICBhbiBTRFQg
KGUuZy4sIEhUVFAgaGVhZGVycykuIiAoc2VjdGlvbiA2KS4gIElzIGl0IGFsd2F5cyBleHRlbnNp
b24NICAgZmllbGRzIG9yIGlzIGl0IHNvbWV0aW1lcyB0aGUgYm9keT8gIChXZWxsLCB0aGUgSFRU
UCBib2R5IGNvdWxkIGJlDSAgIGNhbGxlZCBhbiBleHRlbnNpb24gZmllbGQgb2YgSFRUUCwgdG9v
LikgIEkgdGhpbmsgdGhlIHBvaW50IGlzIHRoYXQNICAgdGhlIERSUCBkYXRhIGFyZSBtb3N0bHkg
cGlnZ3ktYmFja2VkIG9uIFNEVC4gIFdoeSBub3Qgc2F5IHRoYXQuDQUNQTFhKQ1UaGVyZSBhcmUg
YSBudW1iZXIgb2YgcGxhY2VzIHdoZXJlIHRoZSBhcmNoaXRlY3R1cmUgaXMgbm90IHlldA1leHBs
aWNpdCBhYm91dCB0aGUgcm9sZSBvZiBlbnRpdGllcyBhbmQgZGF0YSBvYmplY3RzIHRoYXQgaXQg
cmVxdWlyZXMNdG8gZnVuY3Rpb24uICBBZ2FpbiwgdGhlIGRvY3VtZW50IG5lZWRzIHRvIGRlY2lk
ZSBmb3IgaXRzZWxmIHdoZXRoZXINdGhlc2UgZW50aXRpZXMgYW5kIG9iamVjdHMgYXJlIGlsbHVz
dHJhdGl2ZSBvbmx5IG9yIHBhcnQgb2YgdGhlDXByZXNjcmlwdGl2ZSBlbGVtZW50cyBvZiB0aGUg
YXJjaGl0ZWN0dXJlLg0NRS5nLiwNLS0gaXMgdGhlICJhYnN0cmFjdCBzcGVjaWZpY2F0aW9uIG9m
IC4uLiBvcGVyYXRpb24iIGluIDYuMi4xIGFuZA0gICA2LjIuMiBvbmx5IHByb3ZpZGVkIGZvciBp
bGx1c3RyYXRpb24sIG9yIGlzIHRoZSBhcmNoaXRlY3R1cmUgbGltaXRpbmcNICAgaXRzZWxmIHRv
IGV4YWN0bHkgdGhlc2UgdHdvIG9wZXJhdGlvbnM/DS0tIFRoZXJlIGFwcGVhciB0byBiZSBzb21l
IGltcGxpY2l0IHBhcmFtZXRlcnMgc3VjaCBhcyBhcHBsaWNhdGlvbg0gICBjb250ZXh0Pw0tLSBP
ciwgZm9yIGEgUFVULCBob3cgYXJlIG1ldGFkYXRhIHN1Y2ggYXMgdGhlIGV4cGlyYXRpb24gdGlt
ZQ0gICBlc3RhYmxpc2hlZD8NLS0gSXMgdGhlIGludHJvZHVjdG9yeSBzZW50ZW5jZSBvZiA3IGlu
dGVuZGVkIHRvIGxpbWl0IHRoZQ0gICBzZXJ2ZXItdG8tc2VydmVyIGludGVyYWN0aW9uIHRvIGEg
cHVsbCBtb2RlbCAoImRvd25sb2FkIik/DS0tIFdoYXQgaXMgdGhlIHNlbWFudGljcyBvZiBhIHRo
aXJkLXBhcnR5IChjbGllbnQtdG8tc2VydmVyLXRvLXNlcnZlcikNICAgR0VUIHdpdGggcmVzcGVj
dCB0byB0aGUgbWlkZGxlIHNlcnZlcj8gIElzIHRoZSBpbml0aWF0aW5nIHNlcnZlcg0gICBzdXBw
b3NlZCB0byBleGVjdXRlIGEgbG9jYWwgUFVUIHdpdGggdGhlIHJlc3VsdD8gIE9yIHdoYXQgaXMg
aXRzDSAgIHJvbGU/DQUNQTIpIFRlcm1pbm9sb2d5Og0NVGhlIGFyY2hpdGVjdHVyZSBkZWZpbmVz
IGEgbnVtYmVyIG9mIHRlcm1zIHF1aXRlIGRlbGliZXJhdGVseSAoc2VjdGlvbg0yKSwgYnV0IG1p
c3NlcyBvdXQgb24gYSBmZXcgaW1wb3J0YW50IG9uZXMuDVNvbWUgaW1wb3J0YW50IHJvbGVzIGlu
IHRoZSBhcmNoaXRlY3R1cmUgKHN1Y2ggYXMgdGhlIHRpY2tldA1nZW5lcmF0aW5nIHNlcnZlcikg
YXJlIG9ubHkgaW50cm9kdWNlZCBjdXJzb3JpbHksIHdpdGhvdXQgY29uc2lkZXJpbmcNdGhlIGlt
cGxpY2F0aW9ucyBvZiB0aGVpciBleGlzdGVuY2UgdG8gdGhlIGFyY2hpdGVjdHVyZS4NBQ1BMmEp
DSJ1c2VyIiAoNC41LjIpIGFwcGVhcnMgdG8gYmUgYSBjZW50cmFsIGNvbmNlcHQgb2YgdGhlIGFy
Y2hpdGVjdHVyZSwNYnV0IGlzIGZsZXNoZWQgb3V0IG9ubHkgdmVyeSB0aGlubHkuICBBIHJlbGF0
ZWQgY29uY2VwdCBtaWdodCBvciBtaWdodA1ub3QgYmUgImFjY291bnQiLCB3aGljaCBpcyBvbmx5
IHRvdWNoZWQgb24sIG9yICJwcmluY2lwYWwiICh1c2VkIGluDXRoZSBhcHBlbmRpY2VzIG9ubHkp
Lg0FDUEyYikNNC41LjIgaW50cm9kdWNlcyBhbiAiQXBwbGljYXRpb24gUHJvdmlkZXIiIHRoYXQg
aXMgdXNlZCBub3doZXJlIGVsc2UuDVdoYXQgaXMgdGhhdD8gIElzIHRoYXQgYW4gaW1wb3J0YW50
IGZ1bmN0aW9uYWwgZW50aXR5Pw0FDUEyYykNVGhlIGNhcGFiaWxpdHkgYXJjaGl0ZWN0dXJlICh0
aGUgInRva2VuIiBhcyBhIGRhdGEgc3RydWN0dXJlLCBhbmQgaXRzDWludGVyYWN0aW9uIHdpdGgg
dmFyaW91cyBmdW5jdGlvbmFsIGVsZW1lbnRzKSBpcyBhIGNlbnRyYWwgZWxlbWVudCBvZg10aGUg
REVDQURFIGFyY2hpdGVjdHVyZS4NLS0gU2VlIFJGQyA0OTQ5IHdpdGggcmVzcGVjdCB0byB0aGUg
dXNhZ2Ugb2YgdGhlIHRlcm0gInRva2VuIi4NLS0gVGhlICJ0b2tlbiBnZW5lcmF0aW5nIHNlcnZl
ciIgYXBwZWFycyB0byBiZSBpbXBvcnRhbnQsIGJ1dCBpcyBub3QNICAgY2FsbGVkIG91dCBpbiB0
aGUgbGlzdCBvZiBmdW5jdGlvbmFsIGVsZW1lbnRzIGluIDIuDSAgIEhvdyBkb2VzIGEgY2xpZW50
IHNlbGVjdC9maW5kIG9uZT8NLS0gVGhlIGRvY3VtZW50IHJlcGVhdGVkbHkgKDUuNCwgNi4xLjIp
IHN0YXRlcyB0aGF0IGEgREVDQURFIGNsaWVudA0gICBtdXN0IHRydXN0IHRoZSB0b2tlbiBnZW5l
cmF0aW5nIHNlcnZlciwgYnV0IG5ldmVyIGluZGljYXRlcyB3aHkuDS0tIE9idmlvdXNseSwgdGhl
IERFQ0FERSBzZXJ2ZXJzIG5lZWQgdG8gdHJ1c3QgdGhlIHRva2Vucy4gIFRoaXMgaXMNICAgbm90
IGRpc2N1c3NlZC4NLS0gVGhlIHRva2VuIGlzIHNhaWQgdG8gY29udGFpbiBkYXRhIG9iamVjdCBu
YW1lcywgYnV0IHRoZW4gaXQgaXMgYWxzbw0gICBtZWFudCB0byBiZSB1c2VmdWwgZm9yIGEgImJh
dGNoIG9mIG9wZXJhdGlvbnMiLCBzb21lIG9mIHdoaWNoIG1heQ0gICBjb25jZXJuIGRhdGEgdGhl
IG5hbWVzIG9mIHdoaWNoIHdlIGRvbid0IGtub3cgeWV0Lg0tLSBIb3cgaXMgaXQgdXNlZnVsIHRv
ICJhbGxvdyBhIERFQ0FERSBTZXJ2ZXIgdG8gZGV0ZWN0IHdoZW4gYSB0b2tlbg0gICBpcyB1c2Vk
IG11bHRpcGxlIHRpbWVzIiAod2hhdCBpcyB0aGUgc2VydmVyIHN1cHBvc2VkIHRvIGRvIHdoZW4g
aXQgaGFzDSAgIGRldGVjdGVkIHRoYXQ/KT8NLS0gRG8gdG9rZW5zIG5lZWQgYSByZXZvY2F0aW9u
IG1lY2hhbmlzbT8NDVtSQUE6IEkgYWRkZWQgYSByZXZvY2F0aW9uIG1lY2hhbmlzbV0NDUEyZCkN
U2VjdGlvbnMgNC4zIGFuZCA2LjEuMyB1c2UgYSBjb25jZXB0IGNhbGxlZCAiYXBwbGljYXRpb24g
Y29udGV4dCIuDUFwcGFyZW50bHkgYXBwbGljYXRpb24gY29udGV4dHMgYXJlIHF1aXRlIGltcG9y
dGFudCBmb3IgREVDQURFDW9wZXJhdGlvbnMgKGUuZy4sIDYuMS4zIG1ha2VzIGNsZWFyIHRoYXQg
Im9iamVjdHMiIGFyZSBhbHdheXMNYXNzb2NpYXRlZCB3aXRoIGFuIGFwcGxpY2F0aW9uIGNvbnRl
eHQpOyB3aGF0IGFyZSB0aGVzZSBhcHBsaWNhdGlvbg1jb250ZXh0cz8gIFdobyBjcmVhdGVzLCBk
ZWxldGVzIHRoZW0/ICBSZXNvdXJjZSBjb250cm9sLCBhY2Nlc3MNY29udHJvbCBmb3IgdGhlbT8g
IChTb21lIG9wZXJhdGlvbnMgc2VlbSB0byBoYXZlIGFuIGFwcGxpY2F0aW9uDWNvbnRleHQgYXMg
YW4gaW1wbGljaXQgcGFyYW1ldGVyLiBBc3N1bXB0aW9ucyBsaWtlIHRoZXNlIG5lZWQgdG8gYmUN
c3BlbGxlZCBvdXQuKQ0NW1JBQTogQ2FuIERpcmsgcmVzb2x2ZSB0aGlzIG9uZT8gIE15IGluY2xp
bmF0aW9uIHdhcyB0byByZW1vdmUgdGhpcyB0ZXJtIGJ1dCB0aGlzIHRvdWNoZXMgb24gdGhlIG5h
bWluZyBhbmQgc2VjdXJpdHkgc2VjdGlvbnMgc28gSSdkIGRlZmVyIHRvIERpcmsgYmVmb3JlIGRv
aW5nIHRoYXQuXQ0NW2RrdTogSSB0aGluayB0aGlzIGlzIHJlc29sdmVkIG5vdy5dDQ1BMmUpDTMu
MTogIkxldCBTKEEpIGRlbm90ZSBBJ3MgREVDQURFIHN0b3JhZ2Ugc2VydmVyLiIgIFRoaXMgY29u
Y2VwdCBvZg1vd25lcnNoaXAgaXMgbmV2ZXIgZXhwbGFpbmVkLiAgSXMgaXQgaW1wb3J0YW50Pw0N
W1JBQTogUmV3b3JkZWQgdG8gbm90IHNob3cgcG9zc2Vzc2lvbi5dDQ1BMykNVGhlIGFwcGVuZGlj
ZXMgcHJvdmlkZSByZWxhdGl2ZWx5IHJhdyBleGlzdGVuY2UgcHJvb2ZzIHRoYXQgYXJlIGxpa2Vs
eQ10byBiZSBvdmVydGFrZW4gYnkgZXZlbnRzIGluIGEgeWVhciBmcm9tIG5vdy4gIE11Y2ggb2Yg
dGhlc2UgYXJlDShvdmVybHkpIGJyaWVmIG1pbmktdHV0b3JpYWxzIGZvciB0aGUgcmVsZXZhbnQg
cHJvdG9jb2xzLiAgQXBwZW5kaXgNQS4zIGlzIGFib3V0IGEgcHJvdG9jb2wgdGhhdCBpdHNlbGYg
ZG9lcyBub3Qgc2VlbSB0byBiZSBmdWxseSBjb29rZWQNYXQgdGhpcyBwb2ludC4NVGhpcyBpcyBj
ZXJ0YWlubHkgdXNlZnVsIG1hdGVyaWFsIHRvIGNvbGxlY3QgZm9yIHRoZSBXRywgYnV0IGl0IGlz
IG5vdA1jbGVhciB0aGF0IHRoZXNlIHNob3VsZCBiZSBwYXJ0IG9mIHRoaXMgZG9jdW1lbnQuICBU
aGVyZSBhcmUgbG90cyBvZg1hZGRpdGlvbmFsIGlzc3VlcyBpbiB0aGVzZSBhcHBlbmRpY2VzLCBl
LmcuOg0NQS4xLjEuMSkNSFRUUFMgKHdoZXJlIGlzIHRoZSByZWZlcmVuY2U/KSBpcyBhIHNlY3Vy
aXR5IHByb3RvY29sLCBidXQgZG9lcyBub3QNcHJvdmlkZSBhY2Nlc3MgY29udHJvbC4NQS4xLjEu
MykNVGhpcyB3b3VsZCBuZWVkIHRvIChhdCBsZWFzdCBicmllZmx5KSBleGFtaW5lIHRoZSBpbnRl
cmFjdGlvbnMgYmV0d2Vlbg1IVFRQIGNhY2hpbmcgYW5kIERFQ0FERSBwcm90b2NvbCBvcGVyYXRp
b24uDUEuMS4zKQ1UaGlzIHNwZWNpZmllcyAoPykgIkluIHRoZSByZXBseSwgdGhlIGhhc2ggaXMg
c2VudCBpbiBhbiBFVEFHIGhlYWRlci4iDVdoYXQga2luZCBvZiByZXNwb25zZSBhcmUgd2UgdGFs
a2luZyBhYm91dD8gMzA0PyAgSXMgdGhpcyByZWFsbHkNcGFydCBvZiB0aGUgYXJjaGl0ZWN0dXJl
Pw1BLjEuNSkNV2h5IHNob3VsZCB0aGUgdHJhbnNmZXIgcHJvdG9jb2wgcHJvdmlkZSB0aGUgY29t
cGxldGUgYWNjZXNzIGNvbnRyb2wNbWVjaGFuaXNtPyAgQWNjZXNzIGNvbnRyb2wgaXMgYSBsb2Nh
bCBmdW5jdGlvbi4gIFRyYW5zZmVyIHByb3RvY29scw1qdXN0IGhhdmUgdG8gbWFrZSBzdXJlIHRo
ZSBuZWNlc3NhcnkgcGFyYW1ldGVycyBhcmUgaW4gcGxhY2UgKGFuZC9vcg1tYXkgYmUgdXNlZCBm
b3IgdHJhbnNmZXJyaW5nIHRoZSBwYXJhbWV0ZXJzIGluIHRoZSBmaXJzdCBwbGFjZSkuDVdoZW4g
dGFsa2luZyBhYm91dCBPQVVUSCAyLCBhZGQgdGhlIHJlbGV2YW50IHJlZmVyZW5jZShzKS4NDQUF
SSBoYXZlIG5vdCB1bmRlcnRha2VuIHRvIHJldmlldyB0aGUgYXBwZW5kaWNlcyBpbiBhbnkgZGV0
YWlsLg0NBUE0KQ1JcyB0aGUgYXJjaGl0ZWN0dXJhbCB0aGlua2luZyBjb252ZXJnZWQgZW5vdWdo
IG9uIGlzc3VlcyBvZiBuYW1pbmc/DUUuZy4sDS0tIDQuMyBzZWVtcyB0byBpbXBseSAicmVzb3Vy
Y2UgaWRlbnRpZmllcnMiIGFyZSBiZWluZyB1c2VkIHRoYXQgYXJlDSAgIHRoZSBzYW1lIGJldHdl
ZW4gZGlmZmVyZW50IHNlcnZlcnMuDS0tIDUuMy4xIHNlZW1zIHRvIHN1cHBvcnQgdGhpcyBieSBi
dWlsZGluZyBuYW1lcyBpbiBhIHByZWRpY3RhYmxlIHdheQ0gICBvdXQgb2YgaGFzaGVzLiAgSW4g
cGFydGljdWxhciwgImEgREVDQURFIGNsaWVudCBrbm93cyB0aGUNICAgbmFtZSBvZiBhIGRhdGEg
b2JqZWN0IGJlZm9yZSBpdCBpcyBjb21wbGV0ZWx5IHN0b3JlZCBhdCB0aGUgREVDQURFDSAgIHNl
cnZlci4iDS0tIEhvd2V2ZXIsIGlmIERFQ0FERSBpcyB0byBiZSB1c2VkIGZvciByZWFsLXRpbWUg
aW50ZXJhY3Rpb25zLCBzb21lDSAgIHRob3VnaHQgbmVlZHMgdG8gYmUgZ2l2ZW4gb24gdGhlIHBv
aW50IGluIHRpbWUgd2hlbiBoYXNoLWJhc2VkIGRhdGENICAgaWRlbnRpZmllcnMvbmFtZXMgY2Fu
IGJlIGdlbmVyYXRlZC4gIEEgREVDQURFIGNsaWVudCB0aGF0IFBVVHMNICAgdmlkZW8gdG8gYSBE
RUNBREUgc2VydmVyIG1heSBub3QgaGF2ZSB0aGUgY29tcGxldGUgYnl0ZS1zdHJpbmcgb2YgYQ0g
ICBzbGljZSBpbiBoYW5kIHdoZW4gaXQgc3RhcnRzIHNlbmRpbmcsIHNvIGl0IGNhbid0IHNlbmQg
YSBoYXNoLWJhc2VkDSAgIG5hbWUgYXQgdGhlIHN0YXJ0LiAgVGhpcyBpcyBsaWtlbHkgdG8gaGF2
ZSBzb21lIGltcGFjdCBvbiB0aGUNICAgcHJvdG9jb2wgbWFwcGluZ3MgcG9zc2libGUuICAoSXQg
YWxzbyBtYWtlcyBpdCBsZXNzIGNsZWFyIHRoYXQNICAgdGhlcmUgaXMgYSBnb29kIHJlYXNvbiBu
b3QgdG8gc3VwcG9ydCBuYW1lIGdlbmVyYXRpb24gYnkgdGhlDSAgIHNlcnZlciByaWdodCBmcm9t
IHRoZSBzdGFydC4pDS0tIAVBLjIuMyBzYXlzICJERUNBREUgbWF5IGZpbmQgdGhlIGNvbmNlcHQg
b2YgY29sbGVjdGlvbnMgdG8gYmUNICAgdXNlZnVsIGlmIHRoZXJlIGlzIGEgbmVlZCB0byBzdXBw
b3J0IGRpcmVjdG9yeSBsaWtlIHN0cnVjdHVyZXMgaW4NICAgREVDQURFLiAgSXQgYWxzbyBkaXNj
dXNzZXMgV2ViREFWJ3MgTU9WRSBhbmQgQ09QWSBvcGVyYXRpb25zLg0gICBXaGF0IGlzIHRoZSBw
b2ludCB3aGVuIHRoZSBuYW1lIHVuaXF1ZWx5IGZvbGxvd3MgZnJvbSB0aGUgY29udGVudD8NLS0g
BTYuMS4yIHNheXMgdG9rZW5zIGluY2x1ZGUgIlBlcm1pdHRlZCBvYmplY3RzIChlLmcuLCBuYW1l
cyBvZiBkYXRhDSAgIG9iamVjdHMgdGhhdCBtYXkgYmUgcmVhZCBvciB3cml0dGVuKSIgYW5kICJJ
dCBpcyBwb3NzaWJsZSBmb3IgRFJQDSAgIHRvIGFsbG93IHRva2VucyB0byBhcHBseSB0byBhIGJh
dGNoIG9mIG9wZXJhdGlvbnMgdG8gcmVkdWNlDSAgIGNvbW11bmljYXRpb24gb3ZlcmhlYWQgcmVx
dWlyZWQgYmV0d2VlbiBERUNBREUgQ2xpZW50cy4iICBEb2VzIHRoaXMNICAgcmVxdWlyZSBwcmVz
Y2llbmNlIG9uIHdoYXQgdGhlIGhhc2ggdmFsdWVzIG9mIGZ1dHVyZSBzbGljZXMgd2lsbA0gICBi
ZT8NDUE1KQ1BdXRob3JpemF0aW9uIGJhc2VkIGluIElQIGFkZHJlc3NlcyAoNi4xLjIgInBlcm1p
dHRlZCBjbGllbnRzIikgaXMNcmFyZWx5IGFwcHJvcHJpYXRlLg0FDUE2KQ1NdWNoIG9mIHRoZSBp
bmZvcm1hdGlvbiBkaXNjdXNzZWQgaW4gNi4xLjMgd2lsbCBiZSBQSUkuICBUaGUNYXJjaGl0ZWN0
dXJlIG11c3QgZGlzY3VzcyBob3cgdGhlIHByb3RvY29scyB3aWxsIHByb3ZpZGUgdGhlDWZsZXhp
YmlsaXR5IHRvIGNvcGUgd2l0aCBkaWZmZXJlbnQgZGF0YSBwcm90ZWN0aW9uIGFuZCBzdXJ2ZWls
bGFuY2UNcmVndWxhdGlvbnMuICBGb3IgaW5zdGFuY2UsIHRoZSBsZXZlbCBvZiBsb2dnaW5nIHBl
cmZvcm1lZCBieSBhIHNlcnZlcg1tYXkgYmUgYW4gaW1wb3J0YW50IHBhcmFtZXRlciB0aGF0IG11
c3QgYmUgaW5kaWNhdGVkIHRvIHRoZSBjbGllbnQNYmVmb3JlIGl0IHN0YXJ0cyBvcGVyYXRpb24s
IG9yIHNvbWUgb2YgaXQgbWF5IGNvbnZlcnNlbHkgYmUNY2xhbmRlc3RpbmUuDQ1BNykNUGxlYXNl
IHJld3JpdGUgc2VjdGlvbiA5IGZyb20gc2NyYXRjaC4gIFRoZXJlIGlzIG5vIG5lZWQgdG8gZXhw
bGFpbg1mdW5kYW1lbnRhbHMgb2YgY3J5cHRvZ3JhcGhpYyBkYXRhIHN0cnVjdHVyZXMgKGFzc3Vt
aW5nIHRoYXQgdGhlIG5leHQNdmVyc2lvbiB3aWxsIHVzZSB0ZXJtcyB0aGF0IGNhbiBiZSByZWZl
cmVuY2VkIHByb3Blcmx5KS4gIEluc3RlYWQsDWFjdHVhbCBzZWN1cml0eSBjb25zaWRlcmF0aW9u
cyBvZiB0aGUgREVDQURFIGFyY2hpdGVjdHVyZSBtdXN0IGJlDWRpc2N1c3NlZCwgZS5nLiwgdGhl
IGNhY2hlIGRpc2NvdmVyeSBhdHRhY2sgbWVudGlvbmVkIGFib3ZlLiAgTW9yZQ1pbXBvcnRhbnRs
eSwgdGhlcmUgbmVlZHMgdG8gYmUgYSBkaXNjdXNzaW9uIG9mIHRoZSB0aHJlYXQgbW9kZWwsIHRo
ZQ10cnVzdCByZWxhdGlvbnNoaXBzIGVudmlzYWdlZCwgZXRjLiAgUGxlYXNlIHNlZSBSRkMgMzU1
Mi4NBQ0NKiogTWlub3IgSXNzdWVzOg0NTTEpIFRlcm1pbm9sb2d5DQ1CZXlvbmQgdGhlIHByb2Js
ZW1zIGxpc3RlZCBhYm92ZSwgdGhlIGRyYWZ0IG5lZWRzIGFuIG92ZXJoYXVsIGluIGl0cw10ZXJt
aW5vbG9neS4gRS5nLjoNDS0tIGl0IHVzZXMgIlRUTCIgYXMgYSB0ZXJtIGZvciBhbiBvYmplY3Qg
ZXhwaXJhdGlvbiB0aW1lLCB3aXRob3V0IGV2ZXINICAgZXhwbGFpbmluZyB0aGUgdGVybS4gIChX
aGF0IGlzIGFjdHVhbGx5IG1lYW50IGlzIGFuIGV4cGlyYXRpb24NICAgdGltZSwgKk5PVCogYSBs
aWZldGltZS9kdXJhdGlvbiBvciBob3AgY291bnQgdGhhdCB3b3VsZCBiZQ0gICBhbmFsb2dvdXMg
dG8gSVB2NCdzIHVzZSBvZiB0aGUgYWJyZXZpYXRpb24uKQ0FDS0tIHVzaW5nICJkYXRhIG9iamVj
dCIgYXMgdGhlIHRlcm0gZm9yIHRoZSB0aGluZ3Mgc2F2ZWQgaW4gYSBERUNBREUNICAgc2VydmVy
IGlzIGhpZ2hseSBjb25mdXNpbmcuICBJdCBpcyBub3QgYWx3YXlzIGNsZWFyIHdoZXRoZXIgdGhl
IHJhdw0gICBieXRlIHN0cmluZyBvciB0aGUgY29tYmluYXRpb24gb2YgdGhpcyBhbmQgY2VydGFp
biBtZXRhZGF0YSBpcw0gICBtZWFudC4gIERvIE5PVCB1c2UgImNvbnRlbnRzIiBpbiBpdHMgcGx1
cmFsIGZvcm0gYXMgYSBzeW5vbnltIGZvcg0gICAiZGF0YSBvYmplY3RzIiAoNC4yKS4gIEluZGVl
ZCwgdGhlIGRvY3VtZW50IHdvdWxkIGltcHJvdmUgYnkgdXNpbmcNICAgImNvbnRlbnQiIHZlcnkg
c3BhcmluZ2x5LCBvbmx5IGluIHRoZSBvdmVydmlldyBzZWN0aW9ucywgYW5kIGJlaW5nDSAgIHBy
ZWNpc2UgYWJvdXQgZGF0YSBvYmplY3RzIG90aGVyd2lzZS4gIChJdCB3b3VsZCBiZSBwcmVmZXJh
YmxlIHRvDSAgIGhhdmUgYSBuYW1lIGZvciB0aGUgImRhdGEgb2JqZWN0cyIgdGhhdCBpcyBkaXN0
aW5jdGl2ZSBmcm9tIHRoZQ0gICBwbGFpbiBFbmdsaXNoIG1lYW5pbmcgb2YgdGhhdCB0ZXJtLiAg
RS5nLiwgc2xpY2UuKQ0gICBFLmcuLCB3aGlsZSB3ZSBsZWFybiBhYm91dCBkYXRhIG9iamVjdHMg
dGhhdCB0aGV5IGFyZSBpbW11dGFibGUgYW5kDSAgIG5vdCBhbGwgb2YgdGhlIHNhbWUgc2l6ZSwg
d2UgbmVlZCBjb25zaXN0ZW50IHRlcm1zIGZvciB0aGUgdmFyaW91cw0gICBraW5kcyBvZiBtZXRh
ZGF0YSB1c2VkLCBzdWNoIGFzIHRoZSBERUNBREUgbWV0YWRhdGEgdGhhdCBhcmUgdXNlZCBpbg0g
ICBtYW5hZ2luZyB0aGUgbG9jYWxpemVkIHN0b3JhZ2UgdnMuIHRob3NlIG1ldGFkYXRhIHRoYXQg
d291bGQgYmUNICAgdmlzaWJsZSBpbiB0aGUgU0RULg0gICAiSWYgYW4gYXBwbGljYXRpb24gd2lz
aGVzIHRvIHN0b3JlIHN1Y2ggbWV0YWRhdGEgcGVyc2lzdGVudGx5DSAgIHdpdGhpbiBERUNBREUs
IGl0IGNhbiBiZSBzdG9yZWQgd2l0aGluIGRhdGEgb2JqZWN0cw0gICB0aGVtc2VsdmVzLiIgIChX
aGF0IGRvZXMgdGhhdCBtZWFuPyAgTmV3LCBzZXBhcmF0ZSBvYmplY3RzPyAgV2l0aGluDSAgIHRo
ZSBleGlzdGluZyBvbmVzPyAgSW4gdGhlIHNsaWNlIGJ5dGUtc3RyaW5nIGl0c2VsZj8pDQ0FLS0g
ImRhdGEgdHJhbnNwb3J0IHByb3RvY29sIiBjb250YWlucyB0aGUgdGVybSAidHJhbnNwb3J0IHBy
b3RvY29sIg0gICB3aGljaCBtZWFucyBzb21ldGhpbmcgZGlmZmVyZW50IGluIHRoZSBJRVRGLiAg
V2UgdGVuZCB0byB1c2UNICAgInRyYW5zZmVyIHByb3RvY29sIiBmb3IgdGhlIHB1cnBvc2UgaW50
ZW5kZWQuDQ0tLSA0LjQgaW50cm9kdWNlcyBhICJsb2NhdGlvbiIuICBXaGF0IGlzIHRoYXQ/ICBB
IERFQ0FERSBzZXJ2ZXI/BQ0NLS0gIlRyYWZmaWMgRGUtZHVwbGljYXRpb24iIGlzIGEgc2VyaW91
c2x5IG1pc2xlYWRpbmcgdGVybSBmb3INICAgdmFsaWRhdGVkIGNhY2hlIGFjY2Vzcy4gIFRoZSB3
aG9sZSBwb2ludCBvZiB0aGUgdmFsaWRhdGlvbiBwcm90b2NvbA0gICBpbiA4LjIuMS4yIGFwcGVh
cnMgdG8gYmUgdG8gcHJvdGVjdCB0aGUgY2FjaGUgYXQgUyBhZ2FpbnN0IGENICAgY29sbHVkaW5n
IHBhaXIgb2YgQSBhbmQgUiwgdW5kZXIgdGhlIGFzc3VtcHRpb24gdGhhdCBBIGlzIG5vdA0gICBh
dXRob3JpemVkIHRvIGFjY2VzcyBTJyBjb3B5IG9mIHRoZSBvYmplY3QgYnV0IGNvbXBlbnNhdGVz
IGJ5IGJlaW5nDSAgIGF1dGhvcml6ZWQgdG8gYWNjZXNzIFIncyBjb3B5LiAgU2luY2UgUiBjYW4g
KDEpIGluZGljYXRlDSAgIGF1dGhvcml6YXRpb24gYW5kICgyKSBwcm92ZSB0byBTIGl0IGRvZXMg
aGF2ZSB0aGUgZGF0YSwgYm90aCB1c2luZw0gICB0aGUgY2hhbGxlbmdlLXJlc3BvbnNlIHByb3Rv
Y29sLCBTIGNhbiBmdWxmaWxsIHRoZSByZXF1ZXN0IGZvciBSLg0gICBJZiB0aGF0IGlzIHRoZSBw
b2ludCwgcGxlYXNlIHNheSB0aGF0LiAgUGxlYXNlIG5vdGUgdGhhdCwgZnJvbSB0aGlzDSAgIGV4
Y2hhbmdlLCBBIGFuZCBSIGNhbiBzdGlsbCBleHRyYWN0IHRoZSBmYWN0IHRoYXQgUyBoYWQgYSBj
b3B5Lg0gICBEaXNjdXNzIHNlY3VyaXR5IGltcGxpY2F0aW9ucyBvZiB0aGlzIGRpc2NvdmVyeS4N
BQ0FNC4xKQ0iSG93ZXZlciwgdGhlIGFyY2hpdGVjdHVyZSBtYXkgYWxsb3cgZm9yIG1vcmUtdGhh
bi1vbmUgZGF0YSB0cmFuc3BvcnQNcHJvdG9jb2xzIHRvIGJlIHVzZWQuIg1UaGlzICppcyogdGhl
IGFyY2hpdGVjdHVyZS4gIEl0IGVpdGhlciBhbGxvd3MgaXQgb3Igbm90Lg0oQlRXLCBzaG91bGRu
J3QgdGhlIGFyY2hpdGVjdHVyZSBhbHNvIHNheSBzb21ldGhpbmcgYWJvdXQNbmVnb3RpYXRpb24v
Y2FwYWJpbGl0eSBkaXNjb3Zlcnk/KQ0NNC41LjEpDSJUaGUgU3RvcmFnZSBQcm92aWRlciBkZWxl
Z2F0ZXMgdGhlIG1hbmFnZW1lbnQgb2YgdGhlIHJlc291cmNlcyBhdCBhDURFQ0FERSBzZXJ2ZXIg
dG8gb25lIG9yIG1vcmUgYXBwbGljYXRpb25zLiINV2hhdCBkb2VzIHRoYXQgcmVhbGx5IG1lYW4/
ICAoQW5kIGFyZSB0aGUgbGF0dGVyICJDb250ZW50IERpc3RyaWJ1dGlvbg1BcHBsaWNhdGlvbnMi
PykNDTUuNCkNSXMgdGhpcyByZWFsbHkgYSBkaWdpdGFsIHNpZ25hdHVyZT8NKFBsZWFzZSByZXNl
cnZlIHRoZSB0ZXJtICJkaWdpdGFsbHkgc2lnbmVkIiBmb3IgYWN0dWFsIHNpZ25hdHVyZXMsIGFz
DW9wcG9zZWQgdG8gaW5jbHVkaW5nIGEga2luZCBvZiBwZWVyIGVudGl0eSBhdXRoZW50aWNhdGlv
biB0aGF0IGlzDWRpcmVjdGVkIHRvd2FyZHMgYSBzcGVjaWZpYyByZWNpcGllbnQuICBTZWUgUkZD
IDQ5NDkuKQ0NBTYuMSkNIi4uLkRSUCBhbGxvd3Mgb25lIGluc3RhbmNlIG9mIHN1Y2ggYW4gYXBw
bGljYXRpb24sIGUuZy4sIGFuDWFwcGxpY2F0aW9uIGVuZHBvaW50LCB0byBhcHBseSBhY2Nlc3Mg
Y29udHJvbCBhbmQgcmVzb3VyY2Ugc2hhcmluZw1wb2xpY2llcyBvbiBlYWNoIG9mIHRoZW0uIiAo
dGhlbSA9IERFQ0FERSBzZXJ2ZXJzLikgIFRoYXQgbGFzdA1zZW50ZW5jZSBpcyByYXRoZXIgb21p
bm91cy4gIElzIHRoaXMgY29tcGxldGVseSB0cml2aWFsLCBvciBkb2VzIGl0DWFjdHVhbGx5IG1l
YW4gYW55dGhpbmc/ICBJcyBEUlAgbWF5YmUgYSByZWxpYWJsZSBtdWx0aWNhc3QgcHJvdG9jb2wN
Zm9yIGNvbnRyb2wgZGF0YT8NDTYuMS40KQ1UaGUgdGVybSAiTUlNRSB0eXBlIiBoYXMgYmVlbiBz
dXBlcnNlZGVkIGJ5ICJtZWRpYSB0eXBlIiAocGxlYXNlIGFsc28NcmVmZXJlbmNlIHRoZSByZWxl
dmFudCBSRkNzIGhlcmUpLiAgSXQgaXMgYWxzbyBub3QgY2xlYXIgdG8gbWUgd2hhdA10aGF0IG1l
ZGlhIHR5cGUgbWVhbnMgaW4gY2FzZSBvZiBhIHNsaWNlIG9mIGEgbGFyZ2VyIHJlc291cmNlDXJl
cHJlc2VudGF0aW9uLiAgV2h5IGlzIGEgbWVkaWEgdHlwZSBub3QgY29waWVkIHdpdGggdGhlIG9i
amVjdD8NBQ03LjEpDSJJdCBpcyBhbHNvIGFzc3VtZWQgdGhhdCB0aGUgb3BlcmF0aW9uIHBlcmZv
cm1lZCBhdCB0aGUgcmVtb3RlIHNlcnZlcg1pcyB0aGUgc2FtZSBhcyB0aGUgb3BlcmF0aW9uIGlu
IHRoZSBvcmlnaW5hbCByZXF1ZXN0LiINRXhwbGFpbiAidGhlIHNhbWUiIC0tIGFyZSBhbGwgcGFy
YW1ldGVycyBpZGVudGljYWw/ICBPciBpcyBpdCBqdXN0IEdFVA12cy4gUFVUPw0FDQ0qKiBOaXRz
OiBbbGlzdCBlZGl0b3JpYWwgaXNzdWVzIHN1Y2ggYXMgdHlwb2dyYXBoaWNhbCBlcnJvcnMsIHBy
ZWZlcmFibHkgYnkgc2VjdGlvbiBudW1iZXJdDQ0xKQ0iQ29udGVudCBEaXN0cmlidXRpb24gQXBw
bGljYXRpb25zIiBpbiB0aGUgZmlyc3Qgc2VudGVuY2UgaXMgbm90DWRlZmluZWQuICBQb2ludCB0
byAyLjYuDQUNNC4yKQ0iYXJlIHJlZmVycmVkIGFzIiAtPiAiYXJlIHJlZmVycmVkIHRvIGFzIg0F
DTQuMykNIk9iamVjdHMgdGhhdCBhcmUgc3RvcmVkIGluIGEgREVDQURFIHN0b3JhZ2Ugc2VydmVy
IGNhbiBiZSBhY2Nlc3NlZCBieQ1ERUNBREUgY29udGVudCBjb25zdW1lcnMgYnkgYSByZXNvdXJj
ZSBpZGVudGlmaWVyIg1zZWNvbmQgYnkgLT4gdmlhDQUNNC4zKQ0iICAgICAgICAgIEJlY2F1c2Ug
YSBERUNBREUgY29udGVudCBjb25zdW1lciBjYW4gYWNjZXNzIG1vcmUgdGhhbiBvbmUgc3RvcmFn
ZQ0gICAgICAgICAgIHNlcnZlciB3aXRoaW4gYSBzaW5nbGUgYXBwbGljYXRpb24gY29udGV4dCwg
YSBkYXRhIG9iamVjdCB0aGF0IGlzDSAgICAgICAgICAgcmVwbGljYXRlZCBhY3Jvc3MgZGlmZmVy
ZW50IHN0b3JhZ2Ugc2VydmVycyBtYW5hZ2VkIGJ5IGEgREVDQURFDSAgICAgICAgICAgc3RvcmFn
ZSBwcm92aWRlciwgY2FuIGJlIGFjY2Vzc2VkIGJ5IGEgc2luZ2xlIGlkZW50aWZpZXIuIg1Ob24g
c2VxdWl0dXIuDUNoYW5nZSB0bzoNPj4NQSBERUNBREUgY29udGVudCBjb25zdW1lciBtYXkgYmUg
YWJsZSB0byBhY2Nlc3MgbW9yZSB0aGFuIG9uZSBzdG9yYWdlDXNlcnZlciB3aXRoaW4gYSBzaW5n
bGUgYXBwbGljYXRpb24gY29udGV4dC4gIEEgZGF0YSBvYmplY3QgdGhhdCBpcw1yZXBsaWNhdGVk
IGFjcm9zcyBkaWZmZXJlbnQgc3RvcmFnZSBzZXJ2ZXJzIG1hbmFnZWQgYnkgYSBERUNBREUNc3Rv
cmFnZSBwcm92aWRlciBjYW4gc3RpbGwgYmUgYWNjZXNzZWQgYnkgYSBzaW5nbGUgaWRlbnRpZmll
ci4NPDwNBVtOb3csIGl0IGlzIHN0aWxsIG5vdCBxdWl0ZSBjbGVhciBmcm9tIHRoYXQgc2VudGFu
Y2Ugd2hldGhlciB0aGF0IGlzIGENTVVTVCAoaS5lLiwgdGhlIHdoZXRoZXIgdGhlIGFyY2hpdGVj
dHVyZSBtYW5kYXRlcyB0aGF0IGFsbCByZXBsaWNhdGVkDWNvcGllcyBNVVNUIGhhdmUgdGhlIHNh
bWUgaWRlbnRpZmllcikuXQ0NNC41LjIpDSJhcHBsaWNhdGlvbnMgZ3JhbnRlZCByZXNvdXJjZXMi
Pw1hcHBsaWNhdGlvbnMgYmVpbmcgZ3JhbnRlZCByZXNvdXJjZXM/DXJlc291cmNlcyBncmFudGVk
IGJ5IGFwcGxpY2F0aW9ucz8NDQU1KQ1zL3ByaW5jaXBhbHMvcHJpbmNpcGxlcy8NKEp1c3Qgb25j
ZSBpbiB0aGUgZmlyc3QgcGFyYWdyYXBoOyBvdGhlcndpc2UsIHByaW5jaXBsZSB2cy4gcHJpbmNp
cGFsDWhhcyBiZWVuIHVzZWQgY29ycmVjdGx5LikNDTYuMi4yKQ1kZWZlcmVkIC0+IGRlZmVycmVk
DQ0FNy4xKQ0iTm90ZSB0aGF0IHdoZW4gYSBERUNBREUgY2xpZW50IGludm9rZXMgYSByZXF1ZXN0
IGEgREVDQURFIHNlcnZlciB3aXRoDXRoZXNlIGFkZGl0aW9uYWwgcGFyYW1ldGVycyIgLS0gc3lu
dGF4Lg0FDTguMi4xLjEpDSJXaGVuIGEgREVDQURFIGNsaWVudCAoQSkgaW5kaWNhdGVzIGl0cyBE
RUNBREUgYWNjb3VudCBvbiBhIERFQ0FERQ1zZXJ2ZXIgKFMpIHRvIGZldGNoIGFuIG9iamVjdCBm
cm9tIGEgcmVtb3RlIGVudGl0eSAoUikgKGEgREVDQURFDXNlcnZlciBvciBERUNBREUgY2xpZW50
KS4uLiIgIFdoYXQ/ICBUaGUgImFjY291bnQiIGlzIGFza2VkIHRvIGZldGNoDWZyb20gYSAiY2xp
ZW50Ij8NDUNldGVydW0gY2Vuc2VvKQ1SRkNzLCBhcyBhbnkga2luZCBvZiBmb3JtYWwgdGVjaG5p
Y2FsIHB1YmxpY2F0aW9uLCBzaG91bGQgdXNlIHVuaXRzIGluDWFjY29yZGFuY2Ugd2l0aCBJU08v
SUVDIDgwMDAwLCBpbiBwYXJ0aWN1bGFyIElFQyA4MDAwMC0xMy4NUmVwbGFjZSBNYnBzIGJ5IE1i
aXQvcywgS0IgYnkgS2lCLg0NDSoqIFJhbmRvbSBvYnNlcnZhdGlvbnM6DQ1PMSkNVGhlIHByb3Rv
IHdyaXRldXAgc2F5czoNDT4gVGhlIGRvY3VtZW50IHdhcyByZXZpZXdlZCBieSBERUNBREUgV0cg
bWVtYmVycywgdGhlIFdHIENoYWlycywgYW5kDT4ga2V5IG5vbi1XRyBjb250cmlidXRvcnMsIHBh
cnRpY3VsYXJseSBieSBEYXZpZCBFIE1jZHlzYW4sIEJvcmplDT4gT2hsbWFuLCBBa2JhciBSYWht
YW4sIE5pbmcgWm9uZyBhbmQgRGlyayBLdXRzY2hlci4NDUFrYmFyIFJhaG1hbiBhbmQgRGlyayBL
dXRzY2hlciBhcmUgY28tYXV0aG9ycyBvZiB0aGlzIGRvY3VtZW50LCBzbyBJDXN1cmUgaG9wZSB0
aGV5IGhhdmUgcmV2aWV3ZWQgdGhpcyBkb2N1bWVudC4NDU8yKQ0FVGhlIGFyY2hpdGVjdHVyZSBk
b2VzIG5vdCBnaXZlIGFuIGFyZ3VtZW50IHdoeSBtdWx0aXBsZSBTRFRzIGFyZQ1uZWVkZWQgd2hl
biBhbGwgb2YgdGhlbSBhcmUganVzdCBIVFRQIGFueXdheS4gIChCaW5kaW5nIHRoZSBTRFQgdG8N
bXVsdGlwbGUgdW5kZXJseWluZyBwcm90b2NvbHMgY3JlYXRlcyBhIGxvdCBvZiBoZWFkYWNoZXMg
dGhhdCBtYXkgYmUNY29tcGxldGVseSB1bm5lY2Vzc2FyeS4gIEF0IGxlYXN0IHRoZXkgYXJlbid0
IG1vdGl2YXRlZC4pDUJ1dCBtYXliZSBpdCBpcyBub3QgdGhlIGpvYiBvZiB0aGUgYXJjaGl0ZWN0
dXJlIGRvY3VtZW50IHRvIGFjdHVhbGx5DW1vdGl2YXRlIHRoaXMgaGlnaGx5IGNvbXBsZXhpdHkt
aW5kdWNpbmcgZ2VuZXJhbGl0eS4NDUUuZy4sIEEuMiBhbGx1ZGVzIHRvIGEgbWFwcGluZyB0byBX
ZWJEQVYsIGJ1dCB0aGVuIHNlZW1zIHRvIGdvIG9uDXN1Z2dlc3RpbmcgbW9kaWZpY2F0aW9ucyB0
byBXZWJEQVYgdG8gZW5hYmxlIHRoYXQgbGF5ZXJpbmcuICBUaGlzDWRvZXNuJ3Qgc2VlbSBjb25z
aXN0ZW50LiAgSW5kZWVkLCBpdCBzZWVtcyB1bmxpa2VseSB0aGF0IERFQ0FERSBjYW4NbGF5ZXIg
Y2xlYW5seSBvbiB0b3Agb2YgZWl0aGVyIFdlYkRBViBvciBDRE1JLiAgQSBtb3JlIHByb2R1Y3Rp
dmUgdmlldw1vZiB0aGVzZSBwcm90b2NvbHMgbWF5IGJlIGFzIGEgdG9vbGtpdCB0byB0YWtlIGNl
cnRhaW4gcGFydHMgZnJvbSwgdGhhdA1IVFRQIGRvZXMgbm90IGhhdmUsIGFuZCB0aGF0IERFQ0FE
RSBkb2VzIG5vdCB3YW50IHRvIHJlLWludmVudC4NU3BlY2lhbCBjYXJlIG11c3QgYmUgdGFrZW4g
bm90IHRvIGNyZWF0ZSBhIGNoaW1lcmEsIHRob3VnaC4NBQ0tLS0NDV9fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDWRlY2FkZSBtYWlsaW5nIGxpc3QNZGVjYWRl
QGlldGYub3JnDWh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGVjYWRlDQ0N
DS0tLS0tIERhdmUgSGFycmluZ3RvbpJzIENvbW1lbnRzIC0tLS0tDUZyb206IERhdmlkIEhhcnJp
bmd0b24gW21haWx0bzpkYmhhcnJpbmd0b25AY29tY2FzdC5uZXRdIAtTZW50OiBUaHVyc2RheSwg
RmVicnVhcnkgMDIsIDIwMTIgMzowNCBQTQtUbzogZGVjYWRlLWNoYWlyc0B0b29scy5pZXRmLm9y
ZzsgZHJhZnQtaWV0Zi1kZWNhZGUtYXJjaEB0b29scy5pZXRmLm9yZwtTdWJqZWN0OiBBRCBSZXZp
ZXcgb2YgZHJhZnQtaWV0Zi1kZWNhZGUtYXJjaC0wNA0NQUQgUmV2aWV3IG9mIGRyYWZ0LWlldGYt
ZGVjYWRlLWFyY2gtMDQNDUkgaGF2ZSBwZXJmb3JtZWQgYW4gQUQgUmV2aWV3IG9mIHRoaXMgZG9j
dW1lbnQgaW4gcHJlcGFyYXRpb24gZm9yIHN1Ym1pdHRpbmcgaXQgdG8gdGhlIElFU0cuIFRoZXJl
IGFyZSBhIG51bWJlciBvZiBlYXN5IHRvIGZpeCBlZGl0b3JpYWwgY29tbWVudHMuIFRoZXJlIGFy
ZSBzb21lIHRlY2huaWNhbCBjb25jZXJucyB0aGF0IHdpbGwgdGFrZSBhIGJpdCBtb3JlIHdvcmsg
dG8gYWRkcmVzcy4gUGxlYXNlIHB1Ymxpc2ggYSBSZXZpc2VkIElELqANDTEpIHdoeSBub3QgUHJv
cG9zZWQgU3RhbmRhcmQ/BQ0yKSBpbiAzLjIsIHRoZXJlIGlzIGRpc2N1c3Npb24gb2YgYW4gYXBw
bGljYXRpb24ncyBuYXRpdmUgcHJvdG9jb2wuIHdoYXQgaXMgYSBuYXRpdmUgcHJvdG9jb2w/IGNv
bnNpZGVyIGEgdGVybWlub2xvZ3kgc2VjdGlvbi4FDTMpIGluIDQuMSwgInRoZSBkZWNhZGUgYXJj
aGl0ZWN0dXJlIGRvZXMgbm90IGludGVuZCCFIjsgZmlyc3QsIGFuIGFyY2hpdGVjdHVyZSBkb2Vz
bid0IGludGVuZCBhbnl0aGluZy4gc2Vjb25kLCB0aGUgc2Vjb25kIHBhcnQgb2YgdGhlIHNlbnRl
bmNlIHZlcnkgbXVjaCBpbnRlbmRzIHRvIGVuYWJsZSBhcmJpdHJhcnkgcHJvdG9jb2xzLgUNBTQp
IGluIDQuMSwgIkFsc28gbm90ZSB0aGF0IIUiIGRpc2N1c3NlcyBpbXBsZW1lbnRhdGlvbiBkZXRh
aWxzLiB0aGlzIHdob2xlIHNlbnRlbmNlIGlzIHVubmVjZXNzYXJ5IHNpbmNlIHN1cHBvcnQgZm9y
IGRlY2FkZSBpcyBvZiBjb3Vyc2UgZ29pbmcgdG8gcmVxdWlyZSBpbXBsZW1lbnRhdGlvbiAiYWRq
dXN0bWVudHMiLiBZb3UgbWlnaHQgd2FudCB0byBzdGF0ZSB0aGlzIHNvbWV3aGF0IGRpZmZlcmVu
dGx5LCBpZiB5b3VyIGdvYWwgaXMgdG8gc2F5IGhvdyB0aGlzIGdldHMgaW1wbGVtZW50ZWQgaXMg
aW1wbGVtZW50YXRpb24tc3BlY2lmaWMsIGJ1dCBiZSBjYXJlZnVsIGhlcmUuIFdlIHdhbnQgaW50
ZXJvcGVyYWJpbGl0eSBhbmQgc3RhbmRhcmRpemVkIGJlaGF2aW9ycywgc28gd2UgbW9zdCBjZXJ0
YWlubHkgZG8gd2FudCB0byByZXF1aXJlIHRoZSBpbXBsZW1lbnRhdGlvbiB0byBtZWV0IGNlcnRh
aW4gcmVxdWlyZW1lbnRzIGZvciBjb21wbGlhbmNlIHRvIHRoZSBzdGFuZGFyZC4NBTUpIHRocm91
Z2hvdXQgdGhlIGRvY3VtZW50IHRoZXJlIGFyZSBudW1lcm91cyBpbnN0YW5jZXMgb2YgIm5vdGUg
dGhhdCIgdGhhdCBhcmUgcHVyZWx5IHN1cGVyZmx1b3VzLiBZb3UgQVJFIG5vdGluZyB0aGVzZSBw
b2ludHMgaW4gdGhlIHRleHQsIGFuZCB5b3UgZG9uJ3QgbmVlZCB0byBzdGFydCB0aGUgdGV4dCB3
aXRoICJub3RlIHRoYXQiLg0FNikgaW4gNC4yLCAidXNpbmcgdGhlIGFmb3JlbWVudGlvbmVkIGRh
dGEgbW9kZWwiIC0gSSBkb24ndCBrbm93IHdoYXQgdGhpcyBtZWFucy4gaW4gdGhlIElFVEYgYSAi
ZGF0YSBtb2RlbCIgdGVuZHMgdG8gbWVhbiBzb21ldGhpbmcgc3BlY2lmaWMgLSBzZWUgcmZjMzQ0
NC4gU28gSSBkb24ndCB0aGluayB5b3UgaGF2ZSBhZm9yZW1lbnRpb25lZCBhbnkgZGF0YSBtb2Rl
bC4gSWYgeW91IGRpZCwgSSBkb24ndCB0aGluayB5b3UgaWRlbnRpZmllZCBpdCBhcyBhIGRhdGEg
bW9kZWwgd2hlbiB5b3UgZGVzY3JpYmVkIGl0LCBzbyBpdCBpcyB1bmNsZWFyIHdoYXQgeW91IGFy
ZSByZWZlcnJpbmcgdG8uDQU3KSBpbW11dGFibGUgbWVhbnMgaXQgY2Fubm90IGJlIG1vZGlmaWVk
LiB5ZXQgeW91IHNvbWV0aW1lcyB0YWxrIGFib3V0IHRoZSBibG9ja3MgYmVpbmcgbW9kaWZpZWQ7
IGUuZy4gIml0IGlzIG5vdCBjb21tb24gdGhhdCCFIjsgaW4gNC4yLCB5b3Ugc3RhdGUgdGhhdCBp
bW11dGFibGUgYmxvY2tzICJkbyBub3Qgbm90IGltcGx5IHRoYXQgY29udGVudHMgY2Fubm90IGJl
IG1vZGlmaWVkLiBBcyBJIHVuZGVyc3RhbmQgaW1tdXRhYmlsaXR5LCBibG9ja3MgdGhhdCBjYW4g
YmUgbW9kaWZpZWQgYXJlIG5vdCBpbW11dGFibGUuIEJ1dCB5b3UgdXNlIHRoZSBpbW11dGFiaWxp
dHkgcHJvcGVydHkgdG8ganVzdGlmeSBkZWNpc2lvbnMgbGF0ZXIgaW4gdGhlIGFyY2hpdGVjdHVy
ZS4gRWl0aGVyIHlvdSBSRVFVSVJFIGltbXV0YWJpbGl0eSBvZiBhbGwgYmxvY2tzLCBvciB0aGV5
IGFyZSBub3QgaW1tdXRhYmxlLCBhbmQgdGhlcmVmb3JlIHRoZWlyIHByb3BlcnR5IG9mIGltbXV0
YWJpbGl0eSBDQU5OT1QgYmUgdXNlZCB0byBqdXN0aWZ5IGxhdGVyIGRlc2lnbiBkZWNpc2lvbnMg
KHVubGVzcyB5b3UgZXhwbGljaXRseSBtYWtlIHRoZSBkZXNpZ24gZGVjaXNpb24gY29uZGl0aW9u
YWwpLg1JZiB5b3UgbWFrZSBpbW11dGFiaWxpdHkgUkVDT01NRU5ERUQgYnV0IG5vdCBSRVFVSVJF
RCwgdGhhdCBjYW4gaGF2ZSBhIHNpZ25pZmljYW50IGltcGFjdCBvbiBpc3N1ZXMgb2YgY29tcGxl
eGl0eSwgc2VjdXJpdHksIGludGVyb3BlcmFiaWxpdHksIGFuZCBzbyBvbi4gWW91IHJlYWxseSBu
ZWVkIHRvIG1ha2UgYSBkZWNpc2lvbiBhYm91dCBpbW11dGFiaWxpdHkgYmVpbmcgcmVxdWlyZWQg
Zm9yIGNvbXBsaWFudCBpbXBsZW1lbnRhdGlvbnMsIG9yIGp1c3QgcmVjb21tZW5kZWQuIEl0IGlz
IGFjY2VwdGFibGUgdGhhdCBzb21lIHZlbmRvcnMgY2hvb3NlIHRvIGltcGxlbWVudCBtdXRhYmxl
IGJsb2NrcywgYnV0IHRoZXkgc2hvdWxkIG5vdCBjbGFpbSBjb21wbGlhbmNlIHRvIHRoZSBzdGFu
ZGFyZCBpZiB0aGUgc3RhbmRhcmQgcmVxdWlyZXMgaW1tdXRhYmlsaXR5LiBJZiB5b3UgbWFrZSBt
dXRhYmlsaXR5IGFjY2VwdGFibGUgaW4gY29tcGxhaW50IGltcGxlbWVudGF0aW9ucywgdGhlbiB0
aGVyZSBpcyBhIGxvdCBtcmUgd29yayB0byBkbyB0byBuYWlsIGRvd24gdGhlIHNlY3VyaXR5IGFz
cGVjdHMsIHRoZSBpbnRlcm9wZXJhYmlsaXR5IGFzcGVjdHMsIGV0Yy4NBTgpIGluIDQuMiwgImRv
IG5vdCBzcGVjaWZ5IGEgZml4ZWQgc2l6ZSI7IEZvciBpbnRlcm9wZXJhYmlsaXR5LCB5b3Ugc2hv
dWxkIHN0YW5kYXJkaXplIGVpdGhlciBhIG1hbmRhdG9yeS10by1pbXBsZW1lbnQgZml4ZWQgc2l6
ZSwgd2l0aCB3YXlzIHRvIGhhbmRsZSBvdGhlciBzaXplcywgb3IgeW91IHN0YW5kYXJkaXplIGhv
dyB0byBzcGVjaWZ5IHRoZSBzaXplIChlLmcuLCB2aWEgYSBibG9jayBzaXplIGZpZWxkIGluIGEg
c3RhbmRhcmRpemVkIGhlYWRlciBvciBzb21ldGhpbmcsIG9yIGEgc2Vzc2lvbiBkZXNjcmlwdGlv
biBzdGFuZGFyZCBzdWNoIGFzIFNEUCwgYW5kIHBvc3NpYmx5IGEgc2l6ZS1uZWdvdGlhdGlvbiBo
YW5kc2hha2luZyBwaGFzZSkuDUF0IGEgbWluaW11bSwgeW91IG5lZWQgdG8gc3BlY2lmeSB0aGUg
bWluaW11bSByZWNlaXZlIGJ1ZmZlciBzaXplIHRoYXQgTVVTVCBiZSBzdXBwb3J0ZWQgaW4gY29t
cGxpYW50IGltcGxlbWVudGF0aW9ucywgYW5kIGEgbWF4aW11bS1hbGxvd2VkIHNlbmRpbmcgc2l6
ZSBpbiBjb21wbGlhbnQgaW1wbGVtZW50YXRpb25zLg0FOSkgdGhlIGFyY2ggbWlnaHQgbm90IHNw
ZWNpZnkgZml4ZWQgc2l6ZXMsIGJ1dCBzcGVjaWZpYyBwcm90b2NvbHMgbWlnaHQuIGFuZCBzaW5j
ZSB5b3UgYXJlIHN1cHBvcnRpbmcgdGhlIHJldXNlIG9mIGV4aXN0aW5nIHN0YW5kYXJkIHByb3Rv
Y29scywgeW91IGNlcnRhaW4gY2Fubm90IHN0YXRlIHRoYXQgdGhleSBjYW5ub3Qgc3BlY2lmeSBh
IGZpeGVkIHNpemUuDQUxMCkgaW4gNC41LjEsIHlvdSB1c2UgdGhlIHdvcmQgImNvbnRyb2wiIGFz
IGEgdmVyYiwgIkFwcGxpY2F0aW9ucyBjb250cm9sIIUiLCBpbiB0aGUgbWlkZGxlIG9mIGRpc2N1
c3Npb25zIGFib3V0IHJlc291cmNlIGNvbnRyb2w7IHVzaW5nIGEgZGlmZmVyZW50IHdvcmQgKHN1
Y2ggYXMgY29vcmRpbmF0ZXMpIG1pZ2h0IGJlIGJldHRlci4NMTEpIGluIDQuNS4xLCAiaXNvbGF0
aW9uIGlzIHJlcXVpcmVkIjsgSSB0aGluayBuZWVkcyBleHBhbnNpb24sIHNpbmNlIHRoZXJlIGhh
cyBiZWVuIG5vIGRpc2N1c3Npb24gb2YgaXNvbGF0aW9uLg0xMikgaW4gNSwgInJlbGF0ZWQgdG8g
cHJvdG9jb2wgZGV2ZWxvcG1lbnQiIGlzIHRvbyBicm9hZCAtICJyZWxhdGVkIHRvIERFQ0FERSBw
cm90b2NvbCBkZXZlbG9wbWVudCIgd291bGQgYmUgYmV0dGVyLgUNMTMpIGluIDUuMS4gIm1hbmFn
ZSCFIG1hbmFnZW1lbnQiIGlzIHJlZHVuZGFudC4FDTE0KSBpbiA1LjEsICJwaWVjZSBzZWxlY3Rp
b24iIC0geXUgaGF2ZW4ndCB0YWxrZWQgYWJvdXQgcGllY2VzLiBhcmUgdGhlc2UgYmxvY2tzIG9y
IHNvbWV0aGluZyBlbHNlPwUNMTUpIGluIDUuMS4sICJJbiBzdXBwb3J0aW5nIERFQ0FERSwgaXQg
bWF5IGJlIGFkdmFudGFnZW91cyCFIHRvIGNvbnNpZGVyIERFQ0FERSCFIiA7IGNhbiB3ZSBza2lw
IHRoZSBtYXJrZXRpbmcgcGxlYXNlPwUNMTYpIDUuMS4xICJERUNBREUgaXMgcHJpbWFyaWx5IGRl
c2lnbmVkIHRvIHN1cHBvcnQiIC0gc2ltcGxpZnkgdG8gIkRFQ0FERSBzdXBwb3J0cyIFDTE3KSA1
LjEuMSAiVGhlIHNwZWNpZmljIGltcGxlbWVudGF0aW9uIGlzIGVudGlyZWx5IGRlY2lkZWQgYnkg
dGhlIGFwcGxpY2F0aW9uLiIgU28gdGhhdCBtZWFucyB0aGlzIGlzIG5vdCBwYXJ0IG9mIERFQ0FE
RSBhdCBhbGwuIEVyZ28sIG1heWJlIHdlIHNob3VsZG4ndCBiZSBkaXNjdXNzaW5nIGl0IGhlcmUg
YXQgYWxsLiBhbmQgdGhlbiB3ZSBnbyBvbiB0byBzYXkgdGhhdCBzZXF1ZW5jaW5nIGFuZCBuYW1p
bmcgYXJlIG5vdCBzcGVjaWZpZWQgYXMgcGFydCBvZiBkZWNhZGUuIHdoeSBhcmUgd2UgZGlzY3Vz
c2luZz8FDTE4KSBpbiA1LjEuMiwgIm1heSBzdGlsbCB1c2UiPz8/PyB3aHkgdGhlIHN0aWxsIGlu
IHRoaXMgc2VudGVuY2U/IEkgdGhpbmsgdGhpcyB3aG9sZSBwYXJhZ3JhcGggbmVlZHMgdG8gYmUg
cmV3b3JrZWQFLg0FMTkpIGluIDUuMS4yLCAiaW4gYWRkaXRpb24gdG8gZGVjYWRlIGFzIHRoZSBk
YXRhIHRyYW5zcG9ydCBwcm90b2NvbCIuIEluIDMuMSwgeW91IHNhaWQgc3RhbmRhcmQgZGF0YSBw
cm90b2NvbHMgd2VyZSB1c2VkIGZvciBkYXRhIHRyYW5zcG9ydC4gSSBhbSBvZiB0aGUgaW1wcmVz
c2lvbiwgYXMgYXJlYSBkaXJlY3RvciwgdGhhdCBleGlzdGluZyBzdGFuZGFyZHMgYXJlIHN1cHBv
c2VkIHRvIGJlIHVzZWQgZm9yIGRlY2FkZSBkYXRhIHRyYW5zcG9ydCwgbm90IHNvbWUgbmV3IGRl
Y2FkZSBkYXRhIHRyYW5zcG9ydC6gDTIwKSBPbmUgbWFuZGF0b3J5LXRvLWltcGxlbWVudCBkYXRh
IHByb3RvY29sIHNob3VsZCBiZSBpZGVudGlmaWVkIGZvciBpbnRlcm9wZXJhYmlsaXR5LiBUaGlz
IGRvY3VtZW50IGRvZXNuJ3Qgc2VlbSB0byBkbyB0aGF0OyB0aGUgYXJjaCBkb2N1bWVudCB3b3Vs
ZCBiZSB0aGUgYXBwcm9wcmlhdGUgcGxhY2UgdG8gc3BlY2lmeSB0aGlzIG1hbmRhdG9yeS10by1p
bXBsZW1lbnQgcHJvdG9jb2wsIHBsdXMgaG93IHRvIGFjY29tbW9kYXRlIG9wdGlvbmFsIHByb3Rv
Y29scyAobmVnb3RpYXRpb24sIHNlc3Npb24gZGVzY3JpcHRpb24sIGhlYWRlciBmaWVsZHMsIGV0
Yy4pDVtSQUE6IE1hcnRpbiBzYXlzIHdlIGRvbid0IG5lZWQgdG8gZG8gdGhpc10NBTIxKSBpbiA1
LjEuMywgaXQgaXMgaW1wb3J0YW50IHRvIG5vdGUgdGhhdCAiYSBkZWNhZGUgY2xpZW50IG5lZWQg
bm90IGJlIGVtYmVkZGVkIGludG8gYW4gYXBwbGljYXRpb24iOyBpdCBpcyBOT1QgaW1wb3J0YW50
IHRvIG5vdGUgdGhhdCAiSXQgaXMgaW1wb3J0YW50IHRvIG5vdGUgdGhhdCIsIHNpbmNlIHdlIGFy
ZSBhbHJlYWR5IG5vdGluZyBpdC4gUGxlYXNlIGdldCByaWQgb2YgdGhlICJpdCBpcyBpbXBvcnRh
bnQgdG8gbm90ZSB0aGF0Ii4NMjIpIGluIDUuMS4zLjEsIHlvdSByZWZlciB0byB0aXQtZm9yLXRh
dDsgcGxlYXNlIHByb3ZpZGUgYSByZWZlcmVuY2UgZm9yIHRpdC1mb3ItdGF0LgUNMjMpIGluIDUu
MS4zLjEgKGFuZCBsb3RzIG9mIG90aGVyIHBsYWNlcywgeW91IHN0YXRlICJUaGUgc3BlY2lmaWMg
aW1wbGVtZW50YXRpb24gaXMgZGVjaWRlIGJoIHRoZSBhcHBsaWNhdGlvbi4iIFBsZWFzZSBtYWtl
IGEgZ2VuZXJhbCBzdGF0ZW1lbnQgb25jZSwgaW4gdGhlIEludHJvZHVjdGlvbiBhbmQgbG9zZSB0
aGlzIGNvbnN0YW50IGNob3J1cy4NBTI0KSBpbiA1LjEuMy4yLCAidXNlcyBzdGFuZGFyZCBkYXRh
IHRyYW5zcG9ydCBwcm90b2NvbHMiIC0gd2hhdCBkb2VzIHRoaXMgYWN0dWFsbHkgbWVhbj8gd2hv
c2Ugc3RhbmRhcmRzPyBjYW4gYW4gaW1wbGVtZW50YXRpb24gaW1wbGVtZW50IGEgcHJvcHJpZXRh
cnkgcHJvdG9jb2wgYW5kIHN0aWxsIGJlIGNvbXBsaWFudCAoYXMgbG9uZyBhcyB0aGV5IGFsc28g
aW1wbGVtZW50IHRoZSBtYW5kYXRvcnktdG8taW1wbGVtZW50IHByb3RvY29sKT8NMjUpIGluIDUu
MS4zLjIsIHlvdSBtZW50aW9uICJhIGRpc3RyaWJ1dGVkIHNldCBvZiBhcHBsaWNhdGlvbiBlbmQt
cG9pbnRzLiBJIHRoaW5rIHRoaXMgZGVzZXJ2ZXMgYSBiaXQgbW9yZSBkaXNjdXNzaW9uIHRvIG1h
a2UgaXQgY2xlYXIgd2hhdCB0aGUgcmVxdWlyZW1lbnRzIGFyZSBmb3IgYSBkaXN0cmlidXRlZCBz
ZXQgb2YgZW5kcG9pbnRzLg1bUkFBOiByZXdvcmRlZCBhbmQgZ2F2ZSBleGFtcGxlIG9mIGEgRGlz
dHJpYnV0ZWQgaGFzaCBUYWJsZSB0byBpbmRpY2F0ZSB3aGF0IGlzIG1lYW50XQ0yNikgaW4gNS4y
LjEsIHlvdSBzdGFydCB0byBnZXQgaW50byBzcGVjaWZ5aW5nIHN0YW5kYXJkIGJlaGF2aW9ycyAt
ICJ0aGUgZGVjYWRlIHNlcnZlciB3aWxsIHByb3ZpZGUgYWNjZXNzLiIgSWYgdGhpcyBpcyByZXF1
aXJlZCBiZWhhdmlvciwgdGhlbiBNVVNUIG1heSBiZSBhcHByb3ByaWF0ZSygIGJ1dCBpZiB5b3Ug
YXJlIGdvaW5nIHRvIHNwZWNpZnkgYmVoYXZpb3JzLCB0aGVuIHRoZSBkb2MgbmVlZHMgdG8gYmUg
YSBzdGFuZGFyZC4gWW91IGNhbm5vdCBzcGVjaWZ5IHJlcXVpcmVkIGJlaGF2aW9ycyBpbiBhbiBJ
bmZvIGRvYy4gUGxlYXNlIGJlIGNsZWFyIHdoYXQgaXMgbm9ybWF0aXZlIGFuZCB3aGF0IGlzIGlu
Zm9ybWF0aW9uYWwuDVtSQUE6IGR1cGxpY2F0ZSBvZiBDYXJzdGVuJ3MgY29tbWVudCBhYm91dCBw
cmVzY3JpcHRpdmUgdGV4dF0Ncy9Ob3RlIHRoYXQvLw1zL2l0c2VsZi8vDTI3KSBpbiA1LjIuMi4g
cy9BcHBsaWNhdGlvbnMgbWF5IGFwcGx5IHRoZWlyIGV4aXN0aW5nIHJlc291cmNlIHNoYXJpbmcg
cG9saWNpZXMvQXBwbGljYXRpb25zIGFwcGx5IHJlc291cmNlIHNoYXJpbmcgcG9saWNpZXMvBQ0y
OCkgaW4gNS4yLjMsIFJGQzIxMTkga2V5d29yZHMgc2hvdWxkIHJlYWxseSBvbmx5IGJlIHVzZWQg
aWYgdGhleSBhcmUgbm9ybWF0aXZlLiBpbnN0ZWFkIG9mICJtYXkiIHBsZWFzZSB1c2UgIm1pZ2h0
Ii6gDUxldCdzIHNlZSBpZiBJIGNhbiBjbGFyaWZ5IHVzZSBvZiBub3JtYXRpdmUuIEluIGFuIGFy
Y2ggZG9jLCB5b3Ugbm9ybWFsbHkgZG8gbm90IHNwZWNpZnkgdGhlIHJlcXVpcmVtZW50cyBvZiB0
aGUgcHJvdG9jb2xzLCBFWENFUFQgaWYgdGhpcyBpcyBuZWNlc3NhcnkgZm9yIG9uLXRoZS13aXJl
IGNvbW11bmljYXRpb25zIGJldHdlZW4gYXJjaGl0ZWN0dXJhbCBjb21wb25lbnRzLiBIb3cgYW4g
aW50ZXJuYWwgY29tcG9uZW50IHRhbGtzIHRvIGFub3RoZXIgaW50ZXJuYWwgY29tcG9uZW50IGlz
IGFuIGltcGxlbWVudGF0aW9uIGRldGFpbCAoYW4gaW1wbGVtZW50ZXIgbWlnaHQgY2hvb3NlIHNo
YXJlZCBtZW1vcnksIGdsb2JhbCB2YXJpYWJsZXMsIGludGVycHJvY2VzcyBjb21tdW5pY2F0aW9u
cywgYW5kIGEgdmFyaWV0eSBvZiBpbXBsZW1lbnRhdGlvbi1zcGVjaWZpYyBvcHRpbWl6YXRpb25z
KS4gQnV0IGlmIGFyY2hpdGVjdHVyYWwgY29tcG9uZW50cyBhcmUgZXhwZWN0ZWQgdG8gYmUgZGV2
ZWxvcGVkIGJ5IGRpZmZlcmVudCB2ZW5kb3JzIChlLmcuLCBjbGllbnRzIGFuZCBzZXJ2ZXJzKSwg
YW5kIHRoZSBvbi10aGUtd2lyZSBmb3JtYXQgbXVzdCBiZSBzcGVjaWZpZWQgZm9yIGludGVyb3Bl
cmFiaWxpdHksIHRoZW4gcmZjMjExOSBsYW5ndWFnZSBpcyBjYWxsZWQgZm9yLiBpZiB5b3UgdXNl
IHJmYzIxMTkgbGFuZ3VhZ2UsIHBsZWFzZSBwdXQgaXQgaW4gY2FwcyBzbyB0aGVyZSBpcyBubyBx
dWVzdGlvbiBpdCBpcyBhIHJmYzIxMTkga2V5d29yZC4NBTI5KSBzL3NjaGVtZSBtdWx0aXBsZS9z
Y2hlbWUgaGFzIG11bHRpcGxlLwUNMzApIGluIDUuMy4xLCAidGhpcyBwb3NzaWJpbGl0eSBpcyBu
b3QgY29uc2lkZXJlZCBpbiB0aGUgY3VycmVudCBhcmNoaXRlY3R1cmUiIC0gdGhlbiB3aHkgYXJl
IHlvdSBtZW50aW9uaW5nIGl0IGluIHRoZSBhcmNoaXRlY3R1cmUgZG9jdW1lbnQ/IElmIHRoZSBh
cmNoaXRlY3R1cmUgaXMgYmVpbmcgZGVzaWduZWQgdG8gcGVybWl0IHRoaXMgcG9zc2libGUgZnV0
dXJlIGV4dGVuc2lvbiwgdGhlbiB0aGUgZmxleGliaWxpdHkgSVMgYmVpbmcgY29uc2lkZXJlZCBh
cyBhbiByZXF1aXJlbWVudCBmb3IgdGhlIGFyY2hpdGVjdHVyZQUuDTMxKSBpbiA1LjMuMiwgd2hh
dCBpcyBhIGRlY2FkZSBsYXllcj8gSSBkb24ndCBzZWUgdGhhdCBpbiB0aGUgYXJjaGl0ZWN0dXJh
bCBkaWFncmFtcywgb3IgYW55IHByZXZpb3VzIGRpc2N1c3Npb24uIChmIHlvdSB3YW50IHRvIHNo
b3cgZGVjYWRlIGFzIGFuIGFic3RyYWN0aW9uIGxheWVyLCBJIHdvdWxkbid0IG9iamV0LCBidXQg
ZG8gc28gY2xlYXJseS4pDVtSQUE6IEkgZG9uJ3Qgc2VlIGFueSByZWZlcmVuY2UgdG8gYSCTREVD
QURFIGxheWVylCBhbnltb3JlXQ0zMikgImFyZSBub3QgbmVjZXNzYXJpbHkgY29ycmVsYXRlZCIg
YW5kICJpcyBleHBlY3RlZCB0byIgY29uZmxpY3QuIFdoYXQgaXMgdGhlIGJlaGF2aW9yIGV4cGVj
dGVkIG9mIGEgc3RhbmRhcmQtY29tcGxpYW50IGFyY2hpdGVjdHVyYWwgY29tcG9uZW50Pw0zMykg
YnkgdGhlIHRpbWUgSSBoaXQgNS4zLjMsIEkgYW0gc2NyZWFtaW5nIGF0IHlvdSCFDSJldmVyeXRo
aW5nIHNlZW1zIHRvIGJlIGltcGxlbWVudGF0aW9uLWRlcGVuZGVudC4gd2UgYXJlIHN1cHBvc2Vk
IHRvIGJlIHdyaXRpbmcgYSBzdGFuZGFyZCwgYW5kIHN0YW5kYXJkcyBkZW1hbmQgY29tcGxpYW5j
ZS4gV2Ugc2hvdWxkIGJlIHNwZWNpZnlpbmcgTk9UIHdoYXQgaXMgaW1wbGVtZW50YXRpb24tZGVw
ZW5kZW50LCBidXQgd2hhdCBpcyBzdGFuZGFyZC1jb21wbGlhbnQuIFdoYXQgaXMgYW4gaW1wbGVt
ZW50YXRpb24gcmVxdWlyZWQgdG8gcHJvdmlkZSBmb3IgaW50ZXJvcGVyYWJsZSBiZWhhdmlvcnM/
DVtSQUE6IFJlbW92ZWQgdGhlIHNlY3Rpb24gb24gYXBwbGljYXRpb24tZGVwZW5kZW50IGRhdGEg
b2JqZWN0IHNpemVzIGZyb20gZXhhbXBsZV0NMzQpIDUuMy4zLjEsIHdoYXQgaXMgYSBuYXRpdmUg
cHJvdG9jb2w/BQ0zNSkgNS4zLjMuMSwgIndpdGggd2hpY2ggdGhlIGl0IGlzIGNvbW11bmljYXRp
bmciIHdoYXQgaXMgInRoZSBpdCI/BQ0zNikgcy9zaXplIHNpemVzL3NpemUvBQ0zNykgImlzIHVu
aXF1ZSIgbmVlZHMgYmV0dGVyIHNjb3BpbmcuIElzIHVuaXF1ZSB3aXRoaW4gd2hhdCBzY29wZSAt
IHRoZSBpbnRlcm5hbHMgb2YgdGhlIGltcGxlbWVudGF0aW9uLCB0aGUgcmVsYXRpb25zaGlwIGJl
dHdlZW4gb25lIGNsaWVudCBhbmQgb25lIHNlcnZlcj8gdGhlIG06biByZWxhdGlvbnNoaXBzIG9m
IGNsaWVudHMgYW5kIHNlcnZlcnMgaW4gYSBkZXBsb3ltZW50PyB0aGUgZ2xvYmFsIEludGVybmV0
IChpbiBjYXNlIG11bHRpcGxlIGRlcGxveW1lbnQgaW5zdGFuY2VzIHNvbWVob3cgb3ZlcmxhcCBl
YWNoIG90aGVyKT8NBTM4KSA1LjQgZGlzY3Vzc2VzoCBhIHJlZmVycmFsIGFwcHJvYWNoLiBFeGlz
dGluZyBzdGFuZGFyZHMgYWxyZWFkeSBzcGVjaWZ5IGhvdyB0byBkbyByZWZlcnJhbHM7IHdoeSBk
byB3ZSBuZWVkIGFub3RoZXIgb25lPyBIb3cgYWJvdXQgc3BlY2lmeWluZyBvbmUgYXMgbWFuZGF0
b3J5LXRvLWltcGxlbWVudCBmb3IgY29tcGxpYW5jZT8NMzkpIHRva2VuLWJhc2VkIGF1dGhlbnRp
Y2F0aW9uIC0gZXhpc3RpbmcgcHJvdG9jb2xzIGFscmVhZHkgc3BlY2lmeSB0b2tlbi1iYXNlZCBh
dXRoZW50aWNhdGlvbiBhbmQgYXV0aG9yaXphdGlvbiAoZS5nLiBrZXJiZXJvcywgcmFkaXVzLCBk
aWFtZXRlcik7IHdoeSBkbyB3ZSBuZWVkIGFub3RoZXIgb25lPyBIb3cgYWJvdXQgc3BlY2lmeWlu
ZyBvbmUgYXMgbWFuZGF0b3J5LXRvLWltcGxlbWVudCBmb3IgZGVjYWRlIGNvbXBsaWFuY2U/oA00
MCkgNS4zLjMuMiBzL25leHQsIGNvbnNpZGVyLy8FDTQxKSBpbiA2LCBzL3RvIG1hcHBlZC90byBi
ZSBtYXBwZWQvBQ00MikgaW4gNiwgeW91IGJpbmQgdGhlIERSUCBhbmQgZGF0YSB0cmFuc3BvcnQs
IGFmdGVyIHlvdSBoYXZlIGJlZW4gZXh0b2xsaW5nIHRoZSB2aXJ0dWVzIG9mIHNlcGFyYXRpb24g
b2YgdGhlIHByb3RvY29scy4gSSB0aGluayBiaW5kaW5nIHRoZXNlIGlzIGEgYmFkIGlkZWEsIGFu
ZCB3b3VsZCBsaWtlIHRvIHNlZSB0aGUgYWJzdHJhY3QgZGlzY3Vzc2lvbiBrZWVwIHRoZSBzZXBh
cmF0aW9uLiBTbyB1c2luZyB0aGUgaHR0cCBtb2RlbCB3aXRoIGRycCBlbWJlZGRlZCBpbiB0aGUg
aGVhZGVycyBtYXkgbm90IGJlIGEgZ29vZCBpZGVhIGhlcmUuIFBsZWFzZSB0cnkgYWRkcmVzc2lu
ZyB0aGlzIHVzaW5nIGFuIGV4YW1wbGUgd2hlcmUgdGhlIHR3byBhcmUga2VwdCBzZXBhcmF0ZSAo
YW5kIHlvdSBjYW4gc3VwcGxlbWVudCBpdCB3aXRoIGFuIGV4YW1wbGUgd2hlcmUgdGhleSBhcmUg
Ym91bmQgdG9nZXRoZXIpLiBQcm92aWRpbmcgb25seSBvbmUgZXhhbXBsZSB0aGF0IHJlcXVpcmVz
IGJpbmRpbmcgdGhlIHByb3RvY29scyBzZWVtcyBhIGJhZCBhcHByb2FjaC4NW1JBQTogQWxzbyBp
bmNsdWRlZCBhIHNlbnRlbmNlIGluZGljYXRpbmcgdGhhdCBEUlAgY291bGQgYmUgYSBzZXBhcmF0
ZSBjb250cm9sIGNoYW5uZWwgb3BlbiB3aXRoIHRoZSBzZXJ2ZXJdDTQzKSBpbiA2LCAidGhlIG9w
ZXJhdGlvbnMiIC0gd2hhdCBvcGVyYXRpb25zPyBhcmUgeW91IHJlZmVycmluZyB0byBkYXRhIG1h
bmlwdWxhdGlvbiBvcGVyYXRpb25zPwUNNDQpIGluIDUuNCwgIkRlZmluaW5nIHN1Y2ggcG9saWNp
ZXMgaXMgb3V0IG9mIHNjb3BlIIUiIGlzbid0IG5lY2Vzc2FyeS4gSnVzdCBzYXkgIkEgZGVjYWRl
IGNsaWVudCBtYXkgYmUgZGVuaWVkIGFjY2VzcyBmb3Igb3RoZXIgcmVhc29ucywgZXZlbiBpZiBp
dCBwb3Nlc3NlcyBhIHZhbGlkIHRva2VuLiIFDTQ1KSBhYWFhYWFyZ2ghIHMvTm90ZSB0aGF0Ly9n
LCBzL0l0IGlzIGltcG9ydGFudCB0byBub3RlIHRoYXQvL2cFDTQ2KSBpbiA2LjEuMiwgIml0IGlz
IG91dCBvZiBzY29wZSBvZiB0aGlzIGRvY3VtZW50IIUiIC0gU1RBTkRBUkRJWkUhISEhISBJdCAq
KioqSVMqKiogd2l0aCBzY29wZSBvZiB0aGlzIGRvY3VtZW50IHRvIHNwZWNpZnkgc3RhbmRhcmQg
aW50ZXItY29tcG9uZW50IGJlaGF2aW9ycyBhbmQgZXhwZWN0YXRpb25zLiBXZSBzaG91bGQgYmUg
c3BlY2lmeWluZyBob3cgdG8gYmUgY29uc2VydmF0aXZlIGluIHdoYXQgeW91IHNlbmQgYW5kIGxp
YmVyYWwgaW4gd2hhdCB5b3UgYWNjZXB0LqANBTQ3KSBpbiA2LjEuMiwgIkRSUCBtYXkgYWxzbyBk
ZWZpbmUgdG9rZW5zIiAtIHRvbyBtYW55IG9wdGlvbnMuIFNUQU5EQVJESVpFISEhIElzIHRoaXMg
Im1heSBhbHNvIiBhIFJFUVVJUkVNRU5UIG9yIGEgTklDRS1UTy1IQVZFLg0FNDgpIGluIDYuMi4x
LCAiQSBzZXJ2ZXIgTUFZIiBpcyB0aGlzIFNURCBvciBJbmZvPyByZmMyMTE5IGxhbmd1YWdlPw00
OSkgaW4gNi4yLjEsICJUaGUgbmFtaW5nIHNjaGVtZSBwcm92aWRlcyB0aGF0IHRoZSBuYW1lIGlz
IHVuaXF1ZSIgLSBJIGRpc2FncmVlLiBUaGlzIHByb3ZpZGVzIGEgaGFzaGluZyBhcHByb2FjaCwg
YW5kIHRoZXJlIGNhbiBiZSBjb25mbGljdHMuIERpc2N1c3Npb24gb2Ygd2hhdCBoYXBwZW5zIGlm
IHRoZSBoYXNoIGlzIG5vdCB1bmlxdWUgaXMgbm90IGRpc2N1c3NlZCwgYnV0IGl0IGNvdWxkIGNy
ZWF0ZSBzZWN1cml0eSBob2xlcywgYW5kIHZpb2xhdGVzIHByaXZhY3kgbGF3cywgYW5kIHNvIG9u
LiBNdWNoIG1vcmUgZGlzY3Vzc2lvbiBpcyBuZWVkZWQgYWJvdXQgdGhlIGd1YXJhbnRlZSBvZiB1
bmlxdWVuZXNzLg1bUkFBOiBDYW4gRGlyayBhZGRyZXNzIHRoaXMgb25lP10NNTApIGluIDYuMi4x
LCAiQSBzZXJ2ZXIgTUFUIHZlcmlmeSB0aGUgaW50ZWdyaXR5IIUiIHdoeSBub3QgTVVTVD8FDTUx
KSBpbiA2LjEueCwgIiJzcGVjaWZpZXMgYSBzZXQgb2YgYXR0cmlidXRlcyB0aGF0IFNIT1VMRCBi
ZSBzdXBwb3J0ZWQiIC0gd2h5IG5vdCBNVVNUPw1bUkFBOiBsZWF2aW5nIGFzIFNIT1VMRCBzaW5j
ZSBJIHRoaW5rIHRoZSBwcm90b2NvbCB3aWxsIGJlIHRoZSBiZXR0ZXIgcGxhY2UgdG8gbWFrZSB0
aGUgZmluYWwgZGVjaXNpb25dDQU1MikgaW4gNi4yLCAiQW4gU0RUIIUgU0hPVUxEIG9mZmVyIGEg
dHJhbnNwb3J0IG1vZGUghSIgd2hhdCBpcyBhIHRyYW5zcG9ydCBtb2RlPyBEb2VzICJvZmZlciBh
IHRyYW5zcG9ydCBtb2RlIiBtZWFuIHRoZXJlIGFyZSBvdGhlciBtb2Rlcz8gSXMgdGhpcyBtb3Jl
IG9wdGlvbnM/Pz8gd2h5IGlzIHRoaXMgbm90IGEgTVVTVD8NNTMpIDYuMi4xIGFuZCA2LjIuMiwg
UEVSTUlTU0lPTiBkZW5pZWQgLSBkb2VzIHRoaXMgZ2l2ZSBhbiBhdHRhY2tlciBpbnNpZ2h0IGlu
dG8gd2hhdCBpcyBwcmV2ZW50aW5nIHRoZW0gZnJtIGdldHRpbmcgYWNjZXNzLCBzbyB0aGV5IGNh
biBiZXR0ZXIgdGFyZ2V0IHRoZWlyIGF0dGFja3MgKENmOiB1c2VybmFtZS9wYXNzd29yZHM7IGlm
IGEgdXNlciBzdXBwbGllcyB0aGUgd3JvbmcgcGFzc3dvcmQsIHlvdSBkb24ndCB3YW50IHRvIHJl
cG9ydCAid3JvbmcgcGFzc3dvcmQiLCBiZWNhdXNlIHRoYXQgaW5kaWNhdGVzIHlvdSB1c2VkIGEg
dmFsaWQgdXNlcm5hbWUpOyB0aGV5IGNhbiBhcHBseSBkaWN0aW9uYXJ5IGF0dGFja3MgdG8gdHJ5
IHRvIGdhaW4gYWNjZXNzIHRvIGRpZmZlcmVudCBwYXJ0cyBvZiB0aGUgc3lzdGVtIGlmIHRoZXkg
YXJlIGRlbmllZCBhY2Nlc3MgdG8gY2VydGFpbiBwYXJ0cy4NW1JBQTogQWRkZWQgk2luZm9ybWF0
aW9uIHJldHVybmVkIGluIGVycm9yIHJlc3BvbnNlc5QgdG8gbGlzdCBvZiB0aGluZ3MgZGVmZXJy
ZWQgZm9yIHByb3RvY29sIHNwZWNpZmljYXRpb24uIFRoaXMgc2VlbXMgdG9vIGxvdy1sZXZlbCBm
b3IgYW4gYXJjaGl0ZWN0dXJlIGRvY3VtZW50Ll0NNTQpIHMvTm90ZSwgaG93ZXZlciwgdGhhdC8v
DXMvSXQgaXMgYXNzdW1lZCB0aGF0Ly8Ncy9ub3RlIHRoYXQvLw01NSkgOC4yLCBob3cgY2FuIHlv
dSBkZWR1cGxpY2F0ZSB3aGVuIGVhY2ggbmFtZSBpcyB1bmlxdWUsIGFuZCBzZXQgYnkgdGhlIGNs
aWVudCwgYW5kIHRoZSBzZXJ2ZXIgY2Fubm90IGNoYW5nZSB0aGUgbmFtZT8FDTU2KSBpbiA4LjIu
MS4yLCAiUyBvbmx5IG5lZWRzIHRvIGNoYWxsZW5nZSBSIHRvIHZlcmlmeSIgW2l0IGhhcyB0aGUg
ZGF0YV0uIERvZXNuJ3QgaXQgYWxzbyBoYXZlIHRvIHZlcmlmeSB0aGUgZGF0YSBpcyB0aGUgc2Ft
ZSBkYXRhLCB0byBhdm9pZCBnaXZpbmcgdGhlIHdyb25nIGRhdGEgdG8gdGhlIHJlcXVlc3Rlci4g
KFdvdWxkIHRoaXMgbWFrZSBhIG5pY2UgdmVjdG9yIGZvciB2aXJ1cyB0cmFuc21pc3Npb24/KQ1b
UkFBOiBubyBsb25nZXIgaW4gdGhlIGRvY3VtZW50P10NNTcpIEkgaGF2ZSBzZXJpb3VzIGNvbmNl
cm5zIHRoYXQgSFRUUCBoYXMgYWxyZWFkeSBiZWVuIGNob3NlbiBhcyB0aGUgYmFzaXMgZm9yIGEg
ZGVjYWRlIHByb3RvY29sLCBhbmQgdGhlIGFwcGVuZGljZXMgb25seSBjb3ZlciBodHRwLCB3ZWJk
YXYsIGFuZCBjZG1pLiBUaGVyZSBhcmUgZXhpc3RpbmcgcHJvdG9jb2xzIHRoYXQgY291bGQgYmUg
dXNlZCwgZXNwZWNpYWxseSBpZiB0aGUgRFJQIGlzIHNlcGFyYXRlIGZyb20gdGhlIGRhdGEgdHJh
bnNwb3J0IHByb3RvY29sLiBJIGNhbiBlbnZpc2lvbiBBQUEgYmVpbmcgdXNlZnVsIGFzIHRoZSBE
UlAsIHNpbmNlIGl0IGFscmVhZHkgaGFuZGxlcyBhdXRoZW50aWNhdGlvbiwgYW5kIGF1dGhvcml6
YXRpb24sIGFuZCBwcm92aXNpb25pbmcgb2YgcmVzb3VyY2VzIHN1Y2ggYXMgYmFuZHdpZHRoLiBJ
IGFsc28gaGF2ZSBjb25jZXJucyBhYm91dCB3aGV0aGVyIGV4aXN0aW5nIHN0b3JhZ2UgcHJvdG9j
b2xzLCBzdWNoIGFzIGlTQ1NJIG9yIE5GUywgZG9uJ3QgYWxyZWFkeSBoYXZlIGluZnJhc3RydWN0
dXJlICoqKnBpZWNlcyoqKiBhdmFpbGFibGUgdGhhdCBtaWdodCBiZSByZXVzYWJsZSBmb3IgZGVj
YWRlIHB1cnBvc2VzLiBGb3IgaW1wbGVtZW50YXRpb25zIHRoYXQgYWxyZWFkeSBzdXBwb3J0IGlT
Q1NJIG9yIE5GUyBmb3Igc3RvcmFnZSBtYW5pcHVsYXRpb24sIGl0IHNlZW1zoCB3YXN0ZWZ1bCB0
byByZWludmVudCB0aGUgd2hlZWwuIEJ1dCB0aGVyZSBpcyBubyBkaXNjdXNzaW9uIG9mIGhvdyBl
eGlzdGluZyBwcm90b2NvbHMsIG90aGVyIHRoYW4gaHR0cC1iYXNlZCB3aXRoIGEgYmluZGluZyBi
ZXR3ZWVuIHRoZSBEUlAgYW5kIFNEVCwgY291bGQgc3VwcG9ydCBkZWNhZGUgZW52aXJvbm1lbnRz
LgUNDS0tDURhdmlkIEhhcnJpbmd0b24NRGlyZWN0b3IsIFRyYW5zcG9ydCBBcmVhDUludGVybmV0
IEVuZ2luZWVyaW5nIFRhc2sgRm9yY2UgKElFVEYpDRMgSFlQRVJMSU5LICJtYWlsdG86SWV0ZmRi
aEBjb21jYXN0Lm5ldCIBFElldGZkYmgVEyBIWVBFUkxJTksgIm1haWx0bzpJZXRmZGJoQGNvbWNh
c3QubmV0IgEUQBUTIEhZUEVSTElOSyAibWFpbHRvOklldGZkYmhAY29tY2FzdC5uZXQiARRjb21j
YXN0FRMgSFlQRVJMSU5LICJtYWlsdG86SWV0ZmRiaEBjb21jYXN0Lm5ldCIBFC4VEyBIWVBFUkxJ
TksgIm1haWx0bzpJZXRmZGJoQGNvbWNhc3QubmV0IgEUbmV0FQ0rMS02MDMtODI4LTE0MDENDQ0N
DQUoQWtiYXIpIERvbmUuICBBZGRlZCAga2V5IHBocmFzZXMgk1NIT1VMRJQsIJNNQVmULCBldGMu
IHRvIG1ha2UgY2xlYXIgd2hhdCBpcyBwcmVzY3JpcHRpdmUuICBUaGUgcmVzdCBpcyBieSBkZWZp
bml0aW9uLCBkZXNjcmlwdGl2ZS4NBUkgcmVtb3ZlZCB0aGUgY29uY2VwdHVhbCBwcm90b2NvbCBz
cGVjaWZpY2F0aW9uIJYgc28gSSB0aGluayB3ZSBhZGRyZXNzZWQgdGhpcyBvbmUgbm93Lg0FKEFr
YmFyKS4gIEkgdGhpbmsgdGhhdCB0aGlzIGhhcyBiZWVuIHJlc29sdmVkIGluIG91ciB2YXJpb3Vz
IHVwZGF0ZXMuDQUoQWtiYXIpLiAgRG9uZS4NBShBa2JhcikgSSBkZWxldGVkIHRoZSB3b3JkIJNw
cm92aWRlcpQgYW5kIGFsc28gcmVmZXJlbmNlcyB0byCTQXBwbGljYXRpb24gRGV2ZWxvcGVylCBp
biBzZWN0aW9uIDIuNiBhcyB0aGV5IGFyZSBub3QgdXNlZCBlbHNld2hlcmUgaW4gdGhlIGRvY3Vt
ZW50IChpLmUuIHdlIG9ubHkgcmVmZXIgdG8gk2FwcGxpY2F0aW9uc5QgdHlwaWNhbGx5KS4NBShB
a2JhcikgZG9uZS4NBShBa2JhcikgV2UgaGF2ZSBkZWxldGVkIHRoaXMgQXBwZW5kaXggYXMgaXQg
Z29lcyB0b28gbXVjaCBpbnRvIHByb3RvY29sIGRlc2lnbi4NcmFobWFuc2ENBURpcmsgS3V0c2No
ZXI6DUhhdmUgYWRkcmVzc2VkIHRoaXMgaW4gYXJjaC1wcmluY2lwbGVzLnhtbA0FRGlyayBLdXRz
Y2hlcjoNd2UgaGF2ZSByZW1vdmVkIHRoZSBhcHBlbmRpeC4NBURpcmsgS3V0c2NoZXI6DWhhdmUg
Y2xhcmlmaWVkIHRoaXMgaW4gNC40IG5vdy4NBShBa2JhcikgSSBkZWxldGVkIHRoZSB3aG9sZSBy
ZWZlcmVuY2UgdG8gk3Blcm1pdHRlZCBjbGllbnRzlC4gIEJ1dCBwcm9iYWJseSB3ZSBzaG91bGQg
dGFrZSBhbiBvdmVyYWxsIGxvb2sgYXQgb3VyIHdob2xlIHRva2VuIHN0cnVjdHVyZSBhcyBzdWdn
ZXN0ZWQgYnkgRGlyay4NBShBa2JhcikgRGlyayBoYXMgcmUtd3JpdHRlbiB0aGUgU2VjdXJpdHkg
c2VjdGlvbiB3aXRoIHRoZSB0aHJlYXQgbW9kZWwsIGV0Yy4gc28gdGhpcyBjb21tZW50IGhhcyBi
ZWVuIGFkZHJlc3NlZCBieSBEaXJrIQ0FKEFrYmFyKSBDaGFuZ2VkIJNUVEyUIHRvIJNtYXhpbXVt
IHN0b3JhZ2UgdGltZSAoZXhwaXJhdGlvbiB0aW1lKSBmb3IgZGF0YSBoYXMgcGFzc2VklC4gIFRo
aXMgbWFrZXMgaXQgY29uc2lzdGVudCB3aXRoIHRlcm1pbm9sb2d5IGluIDYuMS4yIGFuZCA2LjEu
NA0FcmFsaW1pOg1Eb25lDQUoQWtiYXIpIENoYW5nZWQgdG8gk3NlcnZlcpQgd2hpY2ggaXMgbW9y
ZSBjbGVhcmVyLg0FKEFrYmFyKSBEZWxldGVkIHRoaXMgc2VjdGlvbiBhcyBpdCBpcyB0b28gZGVz
aWduIG9yaWVudGVkLg1yYWhtYW5zYQ0FcmFsaW1pOg1Eb25lDQVyYWxpbWk6DUNsYXJpZmllZCB0
aGF0IHRoZSBhcHBsaWNhdGlvbiBjYW4gb25seSBjb250cm9sIHNlcnZlcnMgdGhhdCBpdCBoYXMg
cGVybWlzc2lvbiB0byBjb250cm9sIChpLmUuLCB0aG9zZSBhdCB3aGljaCBpdCBoYXMgcGVybWlz
c2lvbiB0byBtYW5hZ2UgZGF0YSkuDQUoQWtiYXIpIERvbmUuDQUoQWtiYXIpLiBKdXN0IGRlbGV0
ZWQgc2VudGVuY2UgYXMgaXQgaXMgY29uZnVzaW5nIGFuZCBub3QgbmVjZXNzYXJ5Lg0FKEFrYmFy
KSBQdXQgk2UuZy4gUDJQIGFwcGxpY2F0aW9uc5QgYXMgYW4gZXhhbXBsZSBpbiBicmFja2V0cy4N
BShBa2JhcikgRG9uZS4gTG9va3MgbGlrZSBzb21lb25lIGhhcyBhbHJlYWR5IGZpeGVkIHRoaXMh
IA0FKEFrYmFyKS4gRG9uZS4gIFNvbWVvbmUgYWxyZWFkeSBmaXhlZCBpdC4NBShBa2JhcikgRG9u
ZS4NcmFobWFuc2ENBShBa2JhcikgUmV3cm90ZSBwYXJhZ3JhcGggdG8gbWFrZSBpdCBjbGVhcmVy
Lg1yYWhtYW5zYQ0FKEFrYmFyKS4gRG9uZS4gIFNvbWVib2R5IGFscmVhZHkgZml4ZWQgdGhpcy4N
BShBa2JhcikgRG9uZS4gIFJlLXdyb3RlIHNlbnRlbmNlLg0FcmFsaW1pOg1BZGRlZCB0byBQcm90
b2NvbCBGbG93J3MgT3ZlcnZpZXcgc2VjdGlvbi4NBShBa2JhcikgV2UgaGF2ZSBkZWxldGVkIHRo
aXMgQXBwZW5kaXggYXMgcGVyIG90aGVyIDIgY29tbWVudHMgYWJvdmUuDXJhaG1hbnNhDQUoQWti
YXIpIEFzIHBlciBjaGFydGVyLg0FKEFrYmFyKSBEb25lLg0FKEFrYmFyKSBXZW50IHRob3VnaCBh
bGwgdGhlIHNlY3Rpb25zIGFuZCBjaGFuZ2VkIGZyb20gk0RFQ0FERZQgdG8gk0RFQ0FERS1jb21w
YXRpYmxllCBhbG9uZyB3aXRoIHF1aXRlIGEgbG90IG9mIHJlLXdyaXRpbmcgdG8gbWFrZSB0aGUg
c2VudGVuY2VzIGZsb3cgd2l0aCB0aGUgbmV3IHdvcmRpbmcuDXJhaG1hbnNhDQVyYWxpbWk6DURv
bmUNBXJhbGltaToNRG9uZQ0FcmFsaW1pOg1DaGFuZ2VkIHRvICJzY2hlbWUiDQVyYWxpbWk6DUNs
YXJpZmllZCBzdGF0ZW1lbnQgdG8gaW5kaWNhdGUgdGhhdCB0aGUgIm1vZGlmaWNhdGlvbiIgZGlk
IG5vdCBwZXJ0YWluIHRvIG1vZGlmeWluZyBhY3R1YWwgZGF0YSBvYmplY3RzLCBidXQgcmF0aGVy
IHBvaW50aW5nIHRvIG5ldyBpbW11dGFibGUgb25lcy4NBXJhbGltaToNQWRkZWQgdGV4dCBpbmRp
Y2F0aW5nIHRoYXQgYSAoZXZlbnR1YWwpIHNwZWMgbWF5IHByZXNjcmliZSByZXF1aXJlbWVudHMg
b24gbWluIGFuZCBtYXggc3VwcG9ydGVkIHNpemVzIGluIGNvbXBsaWFudCBpbXBsZW1lbnRhdGlv
bnMuDQVyYWxpbWk6DUxpbWl0ZWQgdGV4dCB0byBpbmRpY2F0ZSB0aGF0IG9ubHkgdGhlIGFyY2gg
ZG9lcyBub3QgY2FyZSBhYm91dCBmaXhlZCBzaXplLg0FcmFsaW1pOg1Eb25lDQUoQWtiYXIpLiBD
aGFuZ2VkIHRvIJNERUNBREUtY29tcGF0aWJsZSBwcm90b2NvbCBkZXZlbG9wbWVudC4NBShBa2Jh
cikuIERvbmUuDQUoQWtiYXIpLiBDaGFuZ2VkIJNwaWVjZZQgdG8gk2Jsb2NrlCB3aGljaCBpcyB0
aGUgdGVybSB3ZSB1c2UgZWxzZXdoZXJlLiBBbHNvIGNoYW5nZWQgaXQgaW4gc2VjdGlvbiA0LjIN
BShBa2JhcikgRG9uZS4NcmFobWFuc2ENBShBa2JhcikgRG9uZS4NcmFobWFuc2ENBShBa2Jhcikg
RG9uZS4NcmFobWFuc2ENBShBa2JhcikgRG9uZQ0FcmFsaW1pOg1Eb25lDQVyYWxpbWk6DURvbmUN
BShBa2JhcikgRGVsZXRlZCByZWZlcmVuY2UuDQVyYWxpbWk6DUNoYW5nZWQgdG8gImEgZGF0YSB0
cmFuc2ZlciBwcm90b2NvbCB3aXRoIHN1cHBvcnQgZm9yIERFQ0FERSINBShBa2JhcikgRG9uZS4N
BShBa2JhcikgRG9uZS4NBShBa2JhcikgRG9uZS4NBShBa2JhcikgRGVsZXRlZCByZWZlcmVuY2Uu
DQUoQWtiYXIpIERvbmUNBShBa2JhcikgRG9uZS4NBShBa2JhcikgRG9uZS4NBXJhbGltaToNQ2xh
cmlmaWVkIHRoYXQgdGhlIHByb3RvY29sIHNwZWNpZmljYXRpb24gd2lsbCB1c2UgYW4gZXhpc3Rp
bmcgbWVjaGFuaXNtIHdoZXJlZXZlciBwb3NzaWJsZSwgd2l0aCBhIHJlZmVyZW5jZSB0byBPQXV0
aC4NBShBa2JhcikgRG9uZS4NBShBa2JhcikgRG9uZS4NBShBa2JhcikgRG9uZS4NBShBa2Jhcikg
IERvbmUuDQUoQWtiYXIpIERvbmUuDQVyYWxpbWk6DVJlbW92ZWQgdGhlIG9wdGlvbi4gVGhleSBo
YXZlIGEgdW5pcXVlIElELg0FcmFsaW1pOg1ubyBtb3JlIE1BWSBvciBNVVNUIGFueXdoZXJlLiAg
SWYgd2UgZmluZCB0aGF0IHdlIG5lZWQgdGhlbSBoZXJlLCB3ZSBzaG91bGQgcHJvYmFibHkgcHV0
IHRob3NlIHRoaW5ncyBpbiB0aGUgcmVxdWlyZW1lbnRzLg0FKEFrYmFyKSBEb25lLg0FcmFsaW1p
Og1Ecm9wcGVkIHRoZSBlbnRpcmUgc2VudGVuY2UuIFRoaXMgaXMgaW4gdGhlIHJlcXVpcmVtZW50
cyBkb2MgYWxyZWFkeS4NBShBa2JhcikgRG9uZS4NBShBa2JhcikgV2UgaGF2ZSBkZWxldGVkIHRo
ZSBBcHBlbmRpeCB3aXRoIHRoZSBwcm90b2NvbCBhbmFseXNpcyBhcyBwZXIgdGhpcyBjb21tZW50
IGZyb20gRGF2ZSBhbmQgYSBzaW1pbGFyIGNvbW1lbnQgYWJvdmUgZnJvbSBDYXJzdGVuLg1yYWht
YW5zYQ0NDQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAA0QoAANYKAAA0DAAAOAwAAJ8NAACl
DQAA4g4AAOgOAABYEAAAXBAAABkSAAA7FwAASRcAAHAcAABxHAAAchwAAFcgAABYIAAAWSAAAGsg
AACaIQAAmyEAAPzx/Ob82/zQ/MX8tZ6FfZ5hV561QzkTA2oAAAAAFmgEB7QAMEoTAFUIAScVaAQH
tAAWaPkLJAA3CIFDShQAT0oDAFBKAwBRSgMAXkoDAGFKFAATA2oAAAAAFmj9KL8AMEoTAFUIATYV
aP0ovwAWaPkLJAA1CIE3CIFCKgtDShQAT0oDAFBKAwBRSgMAXAiBXkoDAGFKFABwaACwUAAADwNq
AAAAABZo+QskAFUIATAWaPkLJAA1CIE3CIFCKgtDShQAT0oDAFBKAwBRSgMAXAiBXkoDAGFKFABw
aACwUAAALRZo+QskADUIgUIqC0NKFABPSgMAUEoDAFFKAwBcCIFeSgMAYUoUAHBoALBQAB4WaPkL
JABDShQAT0oDAFBKAwBRSgMAXkoDAGFKFAAAFRZo+QskADUIgUIqBlwIgXBo/wAAABUWaPkLJAA1
CIFCKgZcCIFwaPeWRgAVFmj5CyQANQiBQioFXAiBcGhwMKAAFRZo+QskADUIgUIqA1wIgXBoS6zG
ABUWaPkLJAA1CIFCKgtcCIFwaACwUAAGFmj5CyQAFgAIAADzCQAA9AkAAC8KAACYCgAA2AoAAMYL
AADHCwAA+wsAADoMAAAUDQAAFQ0AAGUNAACnDQAAUQ4AAFIOAACpDgAA6g4AALYPAAC3DwAAHxAA
AFwQAAA0EQAANREAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA7AAAAAAAAAAAAAAAAN4AAAAA
AAAAAAAAAADMAAAAAAAAAAAAAAAAzAAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAADeAAAAAAAAAAAA
AAAAzAAAAAAAAAAAAAAAAMwAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA3gAAAAAAAAAAAAAAAMwA
AAAAAAAAAAAAAADMAAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAN4AAAAAAAAAAAAAAADMAAAAAAAA
AAAAAAAAzAAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAADeAAAAAAAAAAAAAAAAzAAAAAAAAAAAAAAA
AMwAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABIAAAomAgtGAgANxgUAAXAI
ABGEmP4SZGQAAAAUpAAAYISY/g4AAAomAQtGAgANxgUAAaAFABJkZAAAABSkAAAOAAAKJgALRgIA
DcYFAAHQAgASZGQAAAAUpAAAAAQAABJkZAAAAAAXNREAAFcRAACNEQAAGBIAABkSAABdEwAAXhMA
AKUTAADXEwAAIxQAACQUAABqFAAAsRQAAOIUAADjFAAA9BQAABYVAAAXFQAAOxUAAFYVAABwFQAA
iBUAAIkVAACKFQAA8QAAAAAAAAAAAAAAAN8AAAAAAAAAAAAAAADfAAAAAAAAAAAAAAAA2gAAAAAA
AAAAAAAAANIAAAAAAAAAAAAAAADLAAAAAAAAAAAAAAAAywAAAAAAAAAAAAAAAMsAAAAAAAAAAAAA
AADLAAAAAAAAAAAAAAAAywAAAAAAAAAAAAAAAMsAAAAAAAAAAAAAAADLAAAAAAAAAAAAAAAAywAA
AAAAAAAAAAAAAMsAAAAAAAAAAAAAAADLAAAAAAAAAAAAAAAAywAAAAAAAAAAAAAAAMsAAAAAAAAA
AAAAAADLAAAAAAAAAAAAAAAAywAAAAAAAAAAAAAAAMsAAAAAAAAAAAAAAADLAAAAAAAAAAAAAAAA
ywAAAAAAAAAAAAAAAMsAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGAAASZGQAAAAUpAAACAAAByQB
EmRkAAAAFKQAAAAEAAASZGQAAAASAAAKJgILRgIADcYFAAFwCAARhJj+EmRkAAAAFKQAAGCEmP4O
AAAKJgELRgIADcYFAAGgBQASZGQAAAAUpAAAABeKFQAAxBUAAAAWAAABFgAARRYAAIUWAADJFgAA
DxcAACcXAAAoFwAAKRcAADoXAAA7FwAASBcAAEkXAACHFwAAthcAAPYXAAARGAAATxgAAJMYAAC5
GAAAuhgAAP8YAAA0GQAANRkAAHsZAADAGQAABBoAAPgAAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA
+AAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAPgAAAAA
AAAAAAAAAAD4AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD4AAAAAAAAAAAA
AAAA+AAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAPgA
AAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD4AAAAAAAA
AAAAAAAA+AAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAA
APgAAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAYAABJkZAAAABSkAAAAHAQaAAA2GgAAfBoAAL8aAADaGgAAFBsAAFobAACg
GwAA5hsAAC0cAABwHAAAchwAAHccAAC2HAAA/BwAAEEdAACBHQAArB0AAK0dAACzHQAA9B0AAD0e
AABoHgAAqx4AALceAAD2HgAABh8AAEEfAAB/HwAA+AAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD4
AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA+AAAAAAA
AAAAAAAAAPgAAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAPgAAAAAAAAAAAAA
AAD4AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA+AAA
AAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAPgAAAAAAAAA
AAAAAAD4AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA
+AAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAABgAAEmRkAAAAFKQAAAAcfx8AAMYfAAAKIAAATiAAAFcgAABZIAAAaiAAAGsg
AACyIAAA3iAAABshAABhIQAAmiEAAJwhAAChIQAA5SEAACwiAABwIgAAhiIAAIgiAACNIgAA0yIA
AAojAAAMIwAAESMAAFcjAACdIwAAtiMAAPUjAAD4AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAPgA
AAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD4AAAAAAAA
AAAAAAAA+AAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAA
APgAAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD4AAAA
AAAAAAAAAAAA+AAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA+AAAAAAAAAAA
AAAAAPgAAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD4
AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAGAAASZGQAAAAUpAAAABybIQAAnCEAAIYiAACHIgAAiCIAAAojAAALIwAAlyQA
AAUnAAArJwAALCcAAAcpAAAIKQAArykAALApAADWKQAA2ykAAE4qAAB4KgAA8NzS8MG5oolvolvw
SPA48MHwAAAAAAAAAAAAAAAAAAAAAAAAHhZo0R6DAENKFABPSgMAUEoDAFFKAwBeSgMAYUoUAAAk
Fmj5CyQANgiBQ0oUAE9KAwBQSgMAUUoDAF0IgV5KAwBhShQAACcVaNEegwAWaPkLJAA3CIFDShQA
T0oDAFBKAwBRSgMAXkoDAGFKFAAzFmj5CyQANQiBNgiBQioGQ0oUAE9KAwBQSgMAUUoDAFwIgV0I
gV5KAwBhShQAcGj/AAAAMBZo+QskADUIgTcIgUIqBkNKFABPSgMAUEoDAFFKAwBcCIFeSgMAYUoU
AHBo/wAAAAAtFmj5CyQANQiBQioGQ0oUAE9KAwBQSgMAUUoDAFwIgV5KAwBhShQAcGj/AAAADwNq
AAAAABZo+QskAFUIASEWaPkLJAA3CIFDShQAT0oDAFBKAwBRSgMAXkoDAGFKFAATA2oAAAAAFmiL
DhkAMEoTAFUIAScVaIsOGQAWaPkLJAA3CIFDShQAT0oDAFBKAwBRSgMAXkoDAGFKFAAeFmj5CyQA
Q0oUAE9KAwBQSgMAUUoDAF5KAwBhShQAEvUjAAA6JAAAcSQAAJckAADbJAAAHyUAAGMlAAB1JQAA
vCUAAAEmAAA3JgAAfCYAAMYmAADaJgAABCcAAAUnAAArJwAALCcAADEnAAB0JwAAsycAAPEnAAA1
KAAAdSgAALUoAAD5KAAABykAAAgpAACvKQAA+AAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD4AAAA
AAAAAAAAAAAA+AAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA+AAAAAAAAAAA
AAAAAPgAAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD4
AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA+AAAAAAA
AAAAAAAAAPgAAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAPgAAAAAAAAAAAAA
AAD4AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA+AAA
AAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAABgAAEmRkAAAAFKQAAAAcrykAALApAADVKQAA1ikAANspAAAeKgAATioAAE8qAAB3
KgAAeCoAAHwqAADDKgAABCsAAEgrAACNKwAAnCsAAOMrAAAoLAAAVSwAAFYsAABfLAAApCwAALws
AADFLAAADC0AADgtAAA/LQAAhi0AAMctAAD4AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAPgAAAAA
AAAAAAAAAAD4AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD4AAAAAAAAAAAA
AAAA+AAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAPgA
AAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD4AAAAAAAA
AAAAAAAA+AAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAA
APgAAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD4AAAA
AAAAAAAAAAAA+AAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAGAAASZGQAAAAUpAAAABx4KgAAViwAADMvAAA0LwAANS8AAHQvAAB1LwAARDMAAEcz
AABIMwAAVDQAAFU0AACtNQAArjUAAAk2AAAKNgAAoTcAAHY5AAB3OQAAeTkAAPU5AADsOgAA7ToA
AEo9AAByPwAAcz8AAOfOxrysxpN8xpPGk3zOxmXOxmWsVMZUk8YAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAhFmj5CyQANwiBQ0oUAE9KAwBQSgMAUUoDAF5KAwBhShQALRZo
+QskADUIgUIqBkNKFABPSgMAUEoDAFFKAwBcCIFeSgMAYUoUAHBo/wAAAC0WaPkLJAA1CIFCKgZD
ShQAT0oDAFBKAwBRSgMAXAiBXkoDAGFKFABwaPeWRgAwFmj5CyQANQiBNwiBQioGQ0oUAE9KAwBQ
SgMAUUoDAFwIgV5KAwBhShQAcGj3lkYAAB4WaPkLJABDShQAT0oDAFBKAwBRSgMAXkoDAGFKFAAA
EwNqAAAAABZo+QskADBKEwBVCAEPA2oAAAAAFmj5CyQAVQgBMBZo+QskADUIgTcIgUIqBkNKFABP
SgMAUEoDAFFKAwBcCIFeSgMAYUoUAHBo/wAAAAAwFmj5CyQANQiBNwiBQioFQ0oUAE9KAwBQSgMA
UUoDAFwIgV5KAwBhShQAcGhwMKAAGcctAADhLQAA6C0AAC0uAABxLgAAti4AAPcuAAAyLwAAMy8A
AHMvAAB0LwAAeS8AAL0vAADDLwAACDAAAC8wAAB1MAAAsjAAAPgwAAAEMQAASTEAAJAxAADSMQAA
GTIAAGAyAAChMgAA4zIAACMzAABEMwAA+AAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD4AAAAAAAA
AAAAAAAA+AAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAA
APgAAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD4AAAA
AAAAAAAAAAAA+AAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA+AAAAAAAAAAA
AAAAAPgAAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD4
AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA+AAAAAAA
AAAAAAAAAPgAAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAABgAAEmRkAAAAFKQAAAAcRDMAAIUzAADKMwAACzQAAFE0AACXNAAA3DQAABs1AABiNQAA
pjUAAK01AACuNQAAsjUAAPU1AAAJNgAACzYAAA82AABMNgAAiTYAAM02AAAUNwAAVzcAAJM3AACg
NwAAoTcAAKU3AADpNwAALzgAAHI4AAD4AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAPgAAAAAAAAA
AAAAAAD4AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA
+AAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAPgAAAAA
AAAAAAAAAAD4AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD4AAAAAAAAAAAA
AAAA+AAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAPgA
AAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD4AAAAAAAA
AAAAAAAA+AAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAGAAASZGQAAAAUpAAAABxyOAAAtDgAAPc4AAA8OQAAdjkAAHg5AAB5OQAAijkAAIs5AACb
OQAAnDkAAOE5AAD0OQAA9TkAADw6AAB+OgAAvDoAAOw6AADuOgAAMjsAAHk7AAC7OwAAADwAAEY8
AACMPAAA0TwAABQ9AABKPQAAkT0AAPgAAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA+AAAAAAAAAAA
AAAAAPgAAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD4
AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA+AAAAAAA
AAAAAAAAAPgAAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAPgAAAAAAAAAAAAA
AAD4AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA+AAA
AAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAPgAAAAAAAAA
AAAAAAD4AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAYAABJkZAAAABSkAAAAHJE9AADXPQAAHz4AAGI+AAB5PgAAuj4AAPE+AAA4PwAAcT8AAHI/
AAC3PwAA9z8AAChAAAApQAAAa0AAAGxAAACrQAAA8kAAADJBAABzQQAAukEAAPZBAAA8QgAAgUIA
AMhCAAALQwAAP0MAAEFDAABHQwAA+AAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD4AAAAAAAAAAAA
AAAA+AAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAPgA
AAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD4AAAAAAAA
AAAAAAAA+AAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAA
APgAAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD4AAAA
AAAAAAAAAAAA+AAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA+AAAAAAAAAAA
AAAAAPgAAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAABgAAEmRkAAAAFKQAAAAccz8AAChAAAApQAAAaUAAAGpAAABsQAAAP0MAAEBDAABBQwAAQkMA
ADtEAAAKRQAAC0UAAPRFAAD1RQAAVEcAAGRIAABlSAAAOEkAADlJAACYSQAA9EkAAPVJAAAlSgAA
JkoAALdKAAC4SgAAvkoAABFNAAASTQAAyE0AADtOAAA8TgAAuE4AALlOAADVTgAA1k4AAEpPAABL
TwAAMFAAAOVQAACkUQAA2lEAAFBSAABRUgAAz1MAAOfQv7enjreKt9C/p4630L+3v7env7e/t7+3
p7+3p7+3v6e/t7+3p7+nc6e30AAsFWj9KL8AFmj5CyQAQ0oUAE9KAwBQSgMAUUoDAF5KAwBhShQA
bUgHBHNIBwQABhZo+QskAAAwFmj5CyQANQiBNwiBQioGQ0oUAE9KAwBQSgMAUUoDAFwIgV5KAwBh
ShQAcGj/AAAAAB4WaPkLJABDShQAT0oDAFBKAwBRSgMAXkoDAGFKFAAADwNqAAAAABZo+QskAFUI
ASEWaPkLJAA3CIFDShQAT0oDAFBKAwBRSgMAXkoDAGFKFAAtFmj5CyQANQiBQioDQ0oUAE9KAwBQ
SgMAUUoDAFwIgV5KAwBhShQAcGhLrMYAMBZo+QskADUIgTcIgUIqA0NKFABPSgMAUEoDAFFKAwBc
CIFeSgMAYUoUAHBoS6zGAC1HQwAAjUMAAKRDAADdQwAAF0QAADpEAAA7RAAAQkQAAIdEAACzRAAA
+kQAAApFAAALRQAAEEUAADRFAAB6RQAAvEUAAPNFAAD0RQAA+kUAADdGAAB6RgAAuUYAAP1GAABB
RwAAU0cAAFRHAABbRwAAoUcAAPgAAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAA
APgAAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD4AAAA
AAAAAAAAAAAA+AAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA+AAAAAAAAAAA
AAAAAPgAAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD4
AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA+AAAAAAA
AAAAAAAAAPgAAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAPgAAAAAAAAAAAAA
AAD4AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAYAABJkZAAAABSkAAAAHKFHAADlRwAAI0gAAGRIAABmSAAAa0gAALFIAADoSAAAL0kAADhJAAA6
SQAAO0kAAJdJAACYSQAAm0kAANxJAAD0SQAA9kkAAPtJAAAlSgAAJ0oAACxKAABzSgAApkoAALdK
AAC5SgAAvkoAAAxLAABZSwAA+AAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA
+AAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAPgAAAAA
AAAAAAAAAAD4AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD4AAAAAAAAAAAA
AAAA+AAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAPgA
AAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD4AAAAAAAA
AAAAAAAA+AAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAA
APgAAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
BgAAEmRkAAAAFKQAAAAcWUsAAKRLAADqSwAA+EsAAANMAAAGTAAATEwAAI9MAADPTAAADk0AABFN
AABZTQAAn00AAMdNAADITQAAz00AAPFNAAAXTgAAOk4AADtOAAA/TgAAWE4AAJ5OAAC4TgAAuU4A
AMBOAADUTgAA1U4AANtOAAD4AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD4
AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA+AAAAAAA
AAAAAAAAAPgAAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAPgAAAAAAAAAAAAA
AAD4AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA+AAA
AAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAPgAAAAAAAAA
AAAAAAD4AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA
+AAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAG
AAASZGQAAAAUpAAAABzbTgAAIk8AAEpPAABMTwAAVU8AAJhPAADZTwAAHlAAAC9QAAAwUAAAQFAA
AIdQAADCUAAA5VAAAOZQAADnUAAA/1AAAABRAAAEUQAAHFEAAB1RAABiUQAApFEAANlRAADaUQAA
H1IAAEtSAABMUgAAUFIAAPgAAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAPgA
AAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD4AAAAAAAA
AAAAAAAA+AAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAA
APgAAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD4AAAA
AAAAAAAAAAAA+AAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA+AAAAAAAAAAA
AAAAAPgAAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD4
AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYA
ABJkZAAAABSkAAAAHFBSAACSUgAA1VIAABpTAABUUwAAmVMAAM5TAADPUwAAEVQAAFNUAACXVAAA
3lQAACZVAABmVQAAolUAAKRVAACoVQAAqVUAANlVAADtVQAA/VUAACpWAAArVgAALFYAAC1WAABU
VgAAMFcAADFXAAD4AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD4AAAAAAAA
AAAAAAAA+AAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAA
APgAAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD4AAAA
AAAAAAAAAAAA+AAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA+AAAAAAAAAAA
AAAAAPgAAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAADz
AAAAAAAAAAAAAAAA8wAAAAAAAAAAAAAAAPMAAAAAAAAAAAAAAADtAAAAAAAAAAAAAAAA8wAAAAAA
AAAAAAAAAPMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYAAAckARJkZAAAAAAEAAASZGQAAAAABgAA
EmRkAAAAFKQAAAAbz1MAAKJVAACjVQAALVYAAFRWAABZVgAAjlYAAJNWAAC4VgAAu1YAAABXAAAI
VwAAMVcAAFhYAAB1WAAAdlgAAPVYAAD2WAAAt1kAALhZAAC5WQAAulkAALRbAAC1WwAAeVwAAHpc
AADOXQAAz10AAJViAACWYgAAxWQAAMZkAACWZQAAl2UAAOffz8u4qLiouKi4qJiH327fbt/L327f
h9+H31Xfh99u3wAwFmj5CyQANQiBNwiBQioGQ0oUAE9KBQBQSgUAUUoFAFwIgV5KBQBhShQAcGj3
lkYAADAWaPkLJAA1CIE3CIFCKgtDShQAT0oFAFBKBQBRSgUAXAiBXkoFAGFKFABwaACwUAAAIRZo
+QskADcIgUNKFABPSgUAUEoFAFFKBQBeSgUAYUoUAB4WaPkLJABDShQAT0oFAFBKBQBRSgUAXkoF
AGFKFAAAHhZo+QskAENKFABPSgQAUEoEAFFKBABeSgQAYUoUAAAkFmj5CyQANQiBQ0oUAE9KBABQ
SgQAUUoEAFwIgV5KBABhShQAAAYWaPkLJAAAHhZo+QskAENKFABPSgMAUEoDAFFKAwBeSgMAYUoU
AAAPA2oAAAAAFmj5CyQAVQgBMBZo+QskADUIgTcIgUIqBUNKFABPSgMAUEoDAFFKAwBcCIFeSgMA
YUoUAHBocDCgACExVwAAWFcAAFlXAABXWAAAWFgAAHdYAAD3WAAAuVkAALRbAAB5XAAAzl0AADZg
AACVYgAADWQAAMVkAACWZQAAWGYAAMlmAAA/ZwAAcGcAANVnAABNaAAAomgAAMtpAABBagAAaWsA
AK1sAADZbAAA2G0AAPgAAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAPgAAAAA
AAAAAAAAAAD4AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD4AAAAAAAAAAAA
AAAA+AAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAPgA
AAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD4AAAAAAAA
AAAAAAAA+AAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAA
APgAAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD4AAAA
AAAAAAAAAAAA+AAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYAABJk
ZAAAABSkAAAAHJdlAABYZgAAyWYAAD1nAAA+ZwAAbmcAAG9nAADTZwAA1GcAAEtoAABMaAAAoGgA
AKFoAADJaQAAymkAAD5qAAA/agAAQWoAAEJqAACtbAAA2WwAANpsAAAtbgAALm4AAPhuAAD5bgAA
928AALxwAAATcQAAgHIAAL5yAABUcwAAVXMAAM92AADQdgAA+nYAAPt2AAApeAAAKngAACx4AAD4
eAAANXkAACN7AAB2ewAAnXsAAJ57AADiewAA7t7u1u7W7tbu1u7Wvdbu1t7WpI3Wvda91qS9dr12
vda91r3WvdZ2vXa9du7W7gAALRZo+QskADUIgUIqC0NKFABPSgUAUEoFAFFKBQBcCIFeSgUAYUoU
AHBoALBQAC0WaPkLJAA1CIFCKgNDShQAT0oFAFBKBQBRSgUAXAiBXkoFAGFKFABwaEusxgAwFmj5
CyQANQiBNwiBQioDQ0oUAE9KBQBQSgUAUUoFAFwIgV5KBQBhShQAcGhLrMYAADAWaPkLJAA1CIE3
CIFCKgtDShQAT0oFAFBKBQBRSgUAXAiBXkoFAGFKFABwaACwUAAADwNqAAAAABZo+QskAFUIAR4W
aPkLJABDShQAT0oFAFBKBQBRSgUAXkoFAGFKFAAAIRZo+QskADcIgUNKFABPSgUAUEoFAFFKBQBe
SgUAYUoUAAAu2G0AAC9uAAD4bgAA928AALxwAAATcQAAgHIAAL5yAADMcgAA13IAAFZzAADNcwAA
z3YAAPx2AAAseAAA+HgAADV5AADIeQAA/XkAACN7AAB2ewAAn3sAAOR7AAD8ewAAL30AAO99AADq
fgAACn8AAC9/AAD4AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD4AAAAAAAA
AAAAAAAA+AAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAA
APgAAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD4AAAA
AAAAAAAAAAAA+AAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA+AAAAAAAAAAA
AAAAAPgAAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD4
AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA+AAAAAAA
AAAAAAAAAPgAAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGAAASZGQA
AAAUpAAAABziewAA43sAAPp7AAD7ewAAL30AADB9AADvfQAA6n4AAAh/AAAJfwAALX8AAC5/AABS
gQAAv4EAAB+CAAAgggAAzoIAAM+CAAAQgwAAEYMAACWEAAAmhAAAqIQAAKmEAADthAAAcYYAALKG
AACzhgAADIcAAHSHAAB1hwAAMIgAAPiJAAD35vfm98225vfm982f5vfm9+b35vfN982I5vfmePfN
YgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKhZo+QskADcIgUIqBkNKFABPSgUAUEoF
AFFKBQBeSgUAYUoUAHBo/wAAAAAeFmj5CyQAQ0oUAE9KBQBQSgUAUUoFAF5KBQBhShQAAC0WaPkL
JAA1CIFCKgZDShQAT0oFAFBKBQBRSgUAXAiBXkoFAGFKFABwaPeWRgAtFmj5CyQANQiBQioDQ0oU
AE9KBQBQSgUAUUoFAFwIgV5KBQBhShQAcGhLrMYALRZo+QskADUIgUIqBkNKFABPSgUAUEoFAFFK
BQBcCIFeSgUAYUoUAHBo/wAAADAWaPkLJAA1CIE3CIFCKgNDShQAT0oFAFBKBQBRSgUAXAiBXkoF
AGFKFABwaEusxgAAIRZo+QskADcIgUNKFABPSgUAUEoFAFFKBQBeSgUAYUoUAA8DagAAAAAWaPkL
JABVCAEAIC9/AABSgQAAv4EAACGCAADQggAAEoMAACWEAACohAAA7YQAAE+GAABxhgAAtIYAAAyH
AAB0hwAAMIgAAPiJAACdigAAuYoAANCKAADeigAAWIsAAEaMAABojAAA2o8AANuPAADejwAA748A
AAiQAAAvkAAA+AAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA+AAAAAAAAAAA
AAAAAPgAAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD4
AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA+AAAAAAA
AAAAAAAAAPgAAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAPgAAAAAAAAAAAAA
AAD4AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA+AAA
AAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA8wAAAAAAAAAAAAAAAPMAAAAAAAAA
AAAAAADzAAAAAAAAAAAAAAAA8wAAAAAAAAAAAAAAAAAAAAAAAAAEAAASZGQAAAAABgAAEmRkAAAA
FKQAAAAc+IkAAN6KAABWiwAAV4sAAEaMAABojAAA2I8AANmPAADbjwAAL5AAADCQAABXkAAAWJAA
AFmQAABgkAAAYpAAAImQAACKkAAAi5AAAIyQAACOkAAAtZAAALaQAAC3kAAAvpAAAMCQAADnkAAA
69LKsZqByoF5ynVqymTKdVnKZMp1TspkynUAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFQIIgQNqTgEA
AAYIARZo+QskAFUIARUCCIEDaqcAAAAGCAEWaPkLJABVCAEKFmj5CyQAMEoXAAAVAgiBA2oAAAAA
BggBFmj5CyQAVQgBBhZo+QskAAAOFmj5CyQAQ0oUAGFKFAAAMBZo+QskADUIgTcIgUIqBUNKFABP
SgUAUEoFAFFKBQBcCIFeSgUAYUoUAHBocDCgAAAtFmj5CyQANQiBQioGQ0oUAE9KBQBQSgUAUUoF
AFwIgV5KBQBhShQAcGj/AAAAMBZo+QskADUIgTcIgUIqBkNKFABPSgUAUEoFAFFKBQBcCIFeSgUA
YUoUAHBo/wAAAAAPA2oAAAAAFmj5CyQAVQgBMBZo+QskADUIgTcIgUIqBkNKFABPSgUAUEoFAFFK
BQBcCIFeSgUAYUoUAHBo95ZGAAAnFmj5CyQAQioGQ0oUAE9KBQBQSgUAUUoFAF5KBQBhShQAcGj/
AAAAABrnkAAA6JAAAOmQAADqkAAA7JAAABORAAAUkQAAFZEAABiRAAAZkQAALZEAAC6RAAAvkQAA
tJEAALWRAAANkgAADpIAAFSSAABVkgAAZZIAAGaSAAArkwAALJMAADqTAAA7kwAAlJMAAJWTAADP
kwAA0JMAAP2TAAD+kwAALZQAAC6UAADMlAAAzZQAAEaVAABHlQAA3JUAAN2VAADqlQAA65UAAB6W
AAAflgAAY5YAAGSWAABxlgAAcpYAAA2XAAAOlwAAHJcAAB2XAABilwAAY5cAAKKXAACjlwAA3ZcA
AN6XAAAImAAACZgAACCYAAAhmAAA9Ozm7OLX7Obsz+Lsz8XBt7OppezP7JnsmeyZ7JnsmezP7M/s
z+yZ7M/smeyZ7Jnsz+zP7M/sz+zP7JnsAAAWFmj5CyQAT0oCAFBKAgBRSgIAXkoCAAAGFmiLDhkA
ABMDagAAAAAWaIsOGQAwShMAVQgBBhZoBAe0AAATA2oAAAAAFmgEB7QAMEoTAFUIAQYWaP0ovwAA
EwNqAAAAABZo/Si/ADBKEwBVCAEOFmj5CyQAQ0oUAGFKFAAAFQIIgQNqnAIAAAYIARZo+QskAFUI
AQYWaPkLJAAAChZo+QskADBKFwAADwNqAAAAABZo+QskAFUIARUCCIEDavUBAAAGCAEWaPkLJABV
CAEAPC+QAAAakQAAKpEAACuRAAAskQAALZEAAC6RAAC0kQAADZIAAFSSAABlkgAAK5MAADqTAACL
kwAAlJMAAKSTAADPkwAA35MAAP2TAAANlAAALZQAAMyUAABGlQAA3JUAAOWVAADqlQAAHpYAAFqW
AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA
AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA9gAAAAAAAAAAAAAAAPYAAAAAAAAA
AAAAAAD2AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAO8AAAAAAAAAAAAAAADvAAAAAAAAAAAAAAAA
7wAAAAAAAAAAAAAAAO8AAAAAAAAAAAAAAADvAAAAAAAAAAAAAAAA7wAAAAAAAAAAAAAAAO8AAAAA
AAAAAAAAAADvAAAAAAAAAAAAAAAA7wAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD4AAAAAAAAAAAA
AAAA+AAAAAAAAAAAAAAAAO8AAAAAAAAAAAAAAADvAAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAO8A
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABgAAEmQAAAAAFKQAAAABIQAAAQAAAAQAABJkZAAA
AAAbWpYAAGOWAABslgAAcZYAAHqWAAANlwAAHJcAAGKXAACilwAA3ZcAAAiYAAAXmAAAIJgAAE+Y
AABYmAAAhpgAAKmYAACymAAA3ZgAACOZAAAsmQAARZkAAFSZAAABmgAACpoAABOaAAAYmgAAIZoA
ACaaAAD4AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA
+AAAAAAAAAAAAAAAAPYAAAAAAAAAAAAAAAD2AAAAAAAAAAAAAAAA9gAAAAAAAAAAAAAAAPYAAAAA
AAAAAAAAAAD2AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD4AAAAAAAAAAAA
AAAA+AAAAAAAAAAAAAAAAPYAAAAAAAAAAAAAAAD2AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAPgA
AAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAPYAAAAAAAAAAAAAAAD2AAAAAAAA
AAAAAAAA+AAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAA
APgAAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAGAAASZAAAAAAUpAAA
ABwhmAAAWJgAAFmYAACGmAAAh5gAAKmYAACqmAAA3ZgAAN6YAAAsmQAALZkAAEWZAABGmQAAVJkA
AFWZAAAKmgAAC5oAABiaAAAZmgAAJpoAACeaAABDmgAARJoAAOGaAADimgAAb5sAAHCbAADEmwAA
xZsAANKbAADTmwAAEJwAABGcAAAgnAAAIZwAAIicAACJnAAAoJwAAKGcAAC4nAAAuZwAANCcAADR
nAAA3pwAAN+cAADsnAAA7ZwAAPqcAAD7nAAAFp0AABedAABdnQAAXp0AAGydAABtnQAAe50AAHyd
AACKnQAAi50AAKadAACnnQAAtJ0AALWdAADDnQAAxJ0AANKdAADTnQAAU54AAFSeAABingAAY54A
AHGeAAByngAAgJ4AAIGeAACQngAAkZ4AAJ+eAACgngAA054AANSeAABXnwAAWJ8AAGafAABnnwAA
tZ8AALafAADEnwAAxZ8AAFagAAD07OTs5Oz07PTs5Ozk7PTs9Oz07PTs9Oz07PTs9Ozk7OTs5Oz0
7PTs9Ozk7PTs9Ozk7PTs5Ozk7OTs5Ozk7OTs5Oz07OTs5Ozk7OTs5Oz07PTs5Oz07OTs9AAAAAAA
AAAOFmj5CyQAQ0oUAGFKFAAADwNqAAAAABZo+QskAFUIARYWaPkLJABPSgIAUEoCAFFKAgBeSgIA
WSaaAAAvmgAAQ5oAAEyaAADhmgAA6poAAG+bAAB4mwAAxJsAAM2bAADSmwAAEJwAACCcAACInAAA
l5wAAKCcAACvnAAAuJwAAMecAADQnAAA3pwAAOecAADsnAAA9ZwAAPqcAAAWnQAAH50AAF2dAABs
nQAA+AAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAPgA
AAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD4AAAAAAAA
AAAAAAAA+AAAAAAAAAAAAAAAAPYAAAAAAAAAAAAAAAD2AAAAAAAAAAAAAAAA9gAAAAAAAAAAAAAA
APgAAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD4AAAA
AAAAAAAAAAAA+AAAAAAAAAAAAAAAAPYAAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA+AAAAAAAAAAA
AAAAAPgAAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA9gAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD4
AAAAAAAAAAAAAAAA9gAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAABgAAEmQAAAAAFKQAAAAc
bJ0AAHudAACKnQAApp0AALSdAADDnQAA0p0AANudAABTngAAYp4AAHGeAACAngAAkJ4AAJ+eAACo
ngAA054AANyeAABXnwAAZp8AAG+fAAC1nwAAxJ8AAE2gAABWoAAAV6AAAFigAAD9AAAAAAAAAAAA
AAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0A
AAAAAAAAAAAAAAD2AAAAAAAAAAAAAAAA9gAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAA
AAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA9gAAAAAAAAAAAAAA
APYAAAAAAAAAAAAAAAD2AAAAAAAAAAAAAAAA9gAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD2AAAA
AAAAAAAAAAAA9gAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD2AAAAAAAAAAAAAAAA9gAAAAAAAAAA
AAAAAP0AAAAAAAAAAAAAAADxAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAEmRkAAAAAAYAABJkAAAAABSkAAAAAQAAABlW
oAAAV6AAAFigAAD8+AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABhZo+QskAAAGFmjRHoMAAiwA
MZBoAR+w0C8gsOA9IbCgBSKwoAUjkKAFJJCgBSWwAAAXsNACGLDQAgyQ0AIAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAApwAA
AEQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAA0Mnqefm6zhGMggCqAEupCwIAAAADAAAA4Mnqefm6zhGMggCqAEupCzYAAABtAGEA
aQBsAHQAbwA6AEkAZQB0AGYAZABiAGgAQABjAG8AbQBjAGEAcwB0AC4AbgBlAHQAAACnAAAARAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAADQyep5+brOEYyCAKoAS6kLAgAAAAMAAADgyep5+brOEYyCAKoAS6kLNgAAAG0AYQBpAGwA
dABvADoASQBlAHQAZgBkAGIAaABAAGMAbwBtAGMAYQBzAHQALgBuAGUAdAAAAKcAAABEAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
ANDJ6nn5us4RjIIAqgBLqQsCAAAAAwAAAODJ6nn5us4RjIIAqgBLqQs2AAAAbQBhAGkAbAB0AG8A
OgBJAGUAdABmAGQAYgBoAEAAYwBvAG0AYwBhAHMAdAAuAG4AZQB0AAAApwAAAEQAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA0Mnq
efm6zhGMggCqAEupCwIAAAADAAAA4Mnqefm6zhGMggCqAEupCzYAAABtAGEAaQBsAHQAbwA6AEkA
ZQB0AGYAZABiAGgAQABjAG8AbQBjAGEAcwB0AC4AbgBlAHQAAACnAAAARAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADQyep5+brO
EYyCAKoAS6kLAgAAAAMAAADgyep5+brOEYyCAKoAS6kLNgAAAG0AYQBpAGwAdABvADoASQBlAHQA
ZgBkAGIAaABAAGMAbwBtAGMAYQBzAHQALgBuAGUAdAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAF4EIwASAAEACwEP
AAcAAAAAAAAAAAAEAAgAAACYAAAAmAAAAJgAAACYAAAAmAAAAJgAAACeAAAAngAAAJ4AAAA2BgAA
NgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAB2AgAAdgIAAHYCAAB2AgAAdgIAAHYCAAB2
AgAAdgIAAHYCAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA4AgAANgYAADYGAAA2BgAANgYAADYG
AAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYA
ADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAAqAAAADYGAAA2BgAAFgAAADYGAAA2BgAA
NgYAADYGAAA2BgAANgYAADYGAAA2BgAAuAAAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2
BgAANgYAADYGAAA2BgAANgYAAGgBAABIAQAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYG
AAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYA
ADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAA
NgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2
BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYG
AACwAwAANgYAADIGAAAYAAAAwAMAANADAADgAwAA8AMAAAAEAAAQBAAAIAQAADAEAABABAAAUAQA
AGAEAABwBAAAgAQAAJAEAADAAwAA0AMAAOADAADwAwAAAAQAABAEAAAyBgAAKAIAANgBAADoAQAA
IAQAADAEAABABAAAUAQAAGAEAABwBAAAgAQAAJAEAADAAwAA0AMAAOADAADwAwAAAAQAABAEAAAg
BAAAMAQAAEAEAABQBAAAYAQAAHAEAACABAAAkAQAAMADAADQAwAA4AMAAPADAAAABAAAEAQAACAE
AAAwBAAAQAQAAFAEAABgBAAAcAQAAIAEAACQBAAAwAMAANADAADgAwAA8AMAAAAEAAAQBAAAIAQA
ADAEAABABAAAUAQAAGAEAABwBAAAgAQAAJAEAADAAwAA0AMAAOADAADwAwAAAAQAABAEAAAgBAAA
MAQAAEAEAABQBAAAYAQAAHAEAACABAAAkAQAAMADAADQAwAA4AMAAPADAAAABAAAEAQAACAEAAAw
BAAAQAQAAFAEAABgBAAAcAQAAIAEAACQBAAAOAEAAFgBAAD4AQAACAIAABgCAABWAgAAfgIAABQA
AABfSAEEbUgJBG5ICQRzSAkEdEgJBAAAAABoAABg8f8CAGgADBAAAAAAAAAAAAYATgBvAHIAbQBh
AGwAAAAPAAAAEmQUAQEAFKTIACokAQAxAEIqAUNKFgBPSgYAUEoGAFFKBgBeSgYAX0gBBGFKFgBt
SAkEcGgAAAAAc0gJBHRIAQQAeAABQAEAAgB4AAwQAAAAAAAAAAAJAEgAZQBhAGQAaQBuAGcAIAAx
AAAALQABAEAmAAomAAtGAQADJABhJAAKJgALRgEAEmRkAAAAE6TwABSkPAAHJABBJAAAHgBPSgIA
UUoCAENKIAA1CAFQSgIAXkoCAGFKIABcCAF+AAJAAQACAH4ADBAAAAAAAAAAAAkASABlAGEAZABp
AG4AZwAgADIAAAAtAAIAQCYBCiYBC0YBAAMkAGEkAAomAQtGAQASZGQAAAATpPAAFKQ8AAckAEEk
AAAkAE9KAgBRSgIAQ0ocADYIATUIAVBKAgBeSgIAYUocAF0IAVwIAXgAA0ABAAIAeAAMEAAAAAAA
AAAACQBIAGUAYQBkAGkAbgBnACAAMwAAAC0AAwBAJgIKJgILRgEAAyQAYSQACiYCC0YBABJkZAAA
ABOk8AAUpDwAByQAQSQAAB4AT0oCAFFKAgBDShoANQgBUEoCAF5KAgBhShoAXAgBaAAEQAEAAgBo
AAwQAAAAAAAAAAAJAEgAZQBhAGQAaQBuAGcAIAA0AAAALQAEAEAmAwomAwtGAQADJABhJAAKJgML
RgEAEmRkAAAAE6TwABSkPAAHJABBJAAADgBDShwANQgBYUocAFwIAW4ABUABAAIAbgAMEAAAAAAA
AAAACQBIAGUAYQBkAGkAbgBnACAANQAAAC0ABQBAJgQKJgQLRgEAAyQAYSQACiYEC0YBABJkZAAA
ABOk8AAUpDwAByQAQSQAABQAQ0oaADYIATUIAWFKGgBdCAFcCAFgAAZAAQACAGAADBAAAAAAAAAA
AAkASABlAGEAZABpAG4AZwAgADYAAAAtAAYAQCYFCiYFC0YBAAMkAGEkAAomBQtGAQASZGQAAAAT
pPAAFKQ8AAckAEEkAAAGADUIAVwIAQAAAAAAAEQAQSDy/6EARAAMAAAAAAAAAAAAFgBEAGUAZgBh
AHUAbAB0ACAAUABhAHIAYQBnAHIAYQBwAGgAIABGAG8AbgB0AAAAAABWAGkA8/+zAFYADA0AAAAA
AAAwBgwAVABhAGIAbABlACAATgBvAHIAbQBhAGwAAAAgADpWCwAX9gMAADTWBgABBQMAADTWBgAB
CgNsAGH2AwAAAgALAAAAKABrIPT/wQAoAAANAAAAAAAAMAYHAE4AbwAgAEwAaQBzAHQAAAACAAwA
AAAAAGAA/m/y//EAYAAMAAAAAAAAAAAACQBXAFcAOABOAHUAbQAxAHoAMAAAADYANQgANggANwgA
PioAQioBQ0oUAE9KBwBQSgcAUUoHAFMqAFwIAF0IAF5KBwBhShQAcGgAAAAAYAD+b/L/AQFgAAwA
AAAAAAAAAAAJAFcAVwA4AE4AdQBtADEAegAxAAAANgA1CAA2CAA3CAA+KgBCKgFDShQAT0oAAFBK
AABRSgAAUyoAXAgAXQgAXkoAAGFKFABwaAAAAABgAP5v8v8RAWAADAAAAAAAAAAAAAkAVwBXADgA
TgB1AG0AMQB6ADQAAAA2ADUIADYIADcIAD4qAEIqAUNKFABPSgUAUEoFAFFKBQBTKgBcCABdCABe
SgUAYUoUAHBoAAAAAEQAQSDy/yEBRAAMAAAAAAAAAAAAFgBEAGUAZgBhAHUAbAB0ACAAUABhAHIA
YQBnAHIAYQBwAGgAIABGAG8AbgB0AAAAAABCACdg8v8xAUIADAAAAAAAAAAAABEAQwBvAG0AbQBl
AG4AdAAgAFIAZQBmAGUAcgBlAG4AYwBlAAAACABDShAAYUoQAFwA/m/y/0EBXAAMAAAAAAAAAAAA
EQBCAGEAbABsAG8AbwBuACAAVABlAHgAdAAgAEMAaABhAHIAAAAhAEIqAUNKEABPSgQAUEoGAFFK
BABeSgQAYUoQAHBoAAAAAABUAP5v8v9RAVQADAAAAAAAAAAAABEAQwBvAG0AbQBlAG4AdAAgAFQA
ZQB4AHQAIABDAGgAYQByAAAAGQBCKgFPSgYAUEoGAFFKBgBeSgYAcGgAAAAAAGAA/m/y/2EBYAAM
AAAAAAAAAAAAFABDAG8AbQBtAGUAbgB0ACAAUwB1AGIAagBlAGMAdAAgAEMAaABhAHIAAAAfADUI
AUIqAU9KBgBQSgYAUUoGAFwIAV5KBgBwaAAAAAAARgBVYPL/cQFGAAwAAAAAAAAAAAAJAEgAeQBw
AGUAcgBsAGkAbgBrAAAAHAA+KgFCKglfSP8AbUj/AHBoAACAAHNI/wB0SP8AOgD+L/L/gQE6AAwA
AAAAAAAAAAARAE4AdQBtAGIAZQByAGkAbgBnACAAUwB5AG0AYgBvAGwAcwAAAAAATgD+TwEAogFO
AAwAAAAAAAAAAAAHAEgAZQBhAGQAaQBuAGcAAAANABkAE6TwABSkeAAGJAEAGABPSgIAUUoCAENK
HABQSggAXkoIAGFKHAA2AEIAAQCiATYADAAAAAAAAAAAAAkAQgBvAGQAeQAgAFQAZQB4AHQAAAAK
ABoAE6QAABSkeAAAACQALwChAbIBJAAMAAAAAAAAAAAABABMAGkAcwB0AAAAAgAbAAAARAAiQAEA
wgFEAAwQAAAAAAAAAAAHAEMAYQBwAHQAaQBvAG4AAAANABwAE6R4ABSkeAAMJAEADgBDShgANggB
YUoYAF0IASoA/g8BANIBKgAMAAAAAAAAAAAABQBJAG4AZABlAHgAAAAFAB0ADCQBAAAAXgA+QAEA
8gFeAAwQAAAAAAAAAAAFAFQAaQB0AGwAZQAAABwAHgASZGQAAAADJAFhJAETpPAAFKQ8AAckAEEk
AB4AT0oCAFFKAgBDSiAANQgBUEoCAF5KAgBhSiAAXAgBVgBKQAEAogFWAAwQAAAAAAAAAAAIAFMA
dQBiAHQAaQB0AGwAZQAAABwAHwASZGQAAAADJAFhJAETpAAAFKQ8AAckAEEkABAAT0oCAFFKAgBQ
SgIAXkoCAFYAmUABAAICVgAMAAAAAAAAAAAADABCAGEAbABsAG8AbwBuACAAVABlAHgAdAAAABAA
IAASZGQAAAATpAAAFKQAABQAT0oEAFFKBABDShAAXkoEAGFKEAA8AB5AAQASAjwADAAAAAAAAAAA
AAwAQwBvAG0AbQBlAG4AdAAgAFQAZQB4AHQAAAACACEACABDShQAYUoUAEAAakARAhICQAAMAAAA
AAAAAAAADwBDAG8AbQBtAGUAbgB0ACAAUwB1AGIAagBlAGMAdAAAAAIAIgAGADUIAVwIAVBLAwQU
AAYACAAAACEA6d4Pv/8AAAAcAgAAEwAAAFtDb250ZW50X1R5cGVzXS54bWyskctOwzAQRfdI/IPl
LUqcskAIJemCx47HonzAyJkkFsnYsqdV+/dM0lRCqCAWbCzZM/eeO+NyvR8HtcOYnKdKr/JCKyTr
G0ddpd83T9mtVomBGhg8YaUPmPS6vrwoN4eASYmaUqV75nBnTLI9jpByH5Ck0vo4Ass1diaA/YAO
zXVR3BjriZE448lD1+UDtrAdWD3u5fmYJOKQtLo/Nk6sSkMIg7PAktTsqPlGyRZCLsq5J/UupCuJ
oc1ZwlT5GbDoXmU10TWo3iDyC4wSw7AMiV/PZyAZLea/O56J7NvWWWy83Y6yjnw2XsxOwf8UYPU/
6BPTzH9bfwIAAP//AwBQSwMEFAAGAAgAAAAhAKXWp+fAAAAANgEAAAsAAABfcmVscy8ucmVsc4SP
z2rDMAyH74W9g9F9UdLDGCV2L6WQQy+jfQDhKH9oIhvbG+vbT8cGCrsIhKTv96k9/q6L+eGU5yAW
mqoGw+JDP8to4XY9v3+CyYWkpyUIW3hwhqN727VfvFDRozzNMRulSLYwlRIPiNlPvFKuQmTRyRDS
SkXbNGIkf6eRcV/XH5ieGeA2TNP1FlLXN2Cuj6jJ/7PDMMyeT8F/ryzlRQRuN5RMaeRioagv41O9
kKhlqtQe0LW4+db9AQAA//8DAFBLAwQUAAYACAAAACEAa3mWFoMAAACKAAAAHAAAAHRoZW1lL3Ro
ZW1lL3RoZW1lTWFuYWdlci54bWwMzE0KwyAQQOF9oXeQ2TdjuyhFYrLLrrv2AEOcGkHHoNKf29fl
44M3zt8U1ZtLDVksnAcNimXNLoi38Hwspxuo2kgcxSxs4ccV5ul4GMm0jRPfSchzUX0j1ZCFrbXd
INa1K9Uh7yzdXrkkaj2LR1fo0/cp4kXrKyYKAjj9AQAA//8DAFBLAwQUAAYACAAAACEAMN1DKagG
AACkGwAAFgAAAHRoZW1lL3RoZW1lL3RoZW1lMS54bWzsWU9v2zYUvw/YdyB0b2MndhoHdYrYsZst
TRvEboceaYmW2FCiQNJJfRva44ABw7phhxXYbYdhW4EW2KX7NNk6bB3Qr7BHUpLFWF6SNtiKrT4k
Evnj+/8eH6mr1+7HDB0SISlP2l79cs1DJPF5QJOw7d0e9i+teUgqnASY8YS0vSmR3rWN99+7itdV
RGKCYH0i13Hbi5RK15eWpA/DWF7mKUlgbsxFjBW8inApEPgI6MZsablWW12KMU08lOAYyN4aj6lP
0FCT9DZy4j0Gr4mSesBnYqBJE2eFwQYHdY2QU9llAh1i1vaAT8CPhuS+8hDDUsFE26uZn7e0cXUJ
r2eLmFqwtrSub37ZumxBcLBseIpwVDCt9xutK1sFfQNgah7X6/W6vXpBzwCw74OmVpYyzUZ/rd7J
aZZA9nGedrfWrDVcfIn+ypzMrU6n02xlsliiBmQfG3P4tdpqY3PZwRuQxTfn8I3OZre76uANyOJX
5/D9K63Vhos3oIjR5GAOrR3a72fUC8iYs+1K+BrA12oZfIaCaCiiS7MY80QtirUY3+OiDwANZFjR
BKlpSsbYhyju4ngkKNYM8DrBpRk75Mu5Ic0LSV/QVLW9D1MMGTGj9+r596+eP0XHD54dP/jp+OHD
4wc/WkLOqm2chOVVL7/97M/HH6M/nn7z8tEX1XhZxv/6wye//Px5NRDSZybOiy+f/PbsyYuvPv39
u0cV8E2BR2X4kMZEopvkCO3zGBQzVnElJyNxvhXDCNPyis0klDjBmksF/Z6KHPTNKWaZdxw5OsS1
4B0B5aMKeH1yzxF4EImJohWcd6LYAe5yzjpcVFphR/MqmXk4ScJq5mJSxu1jfFjFu4sTx7+9SQp1
Mw9LR/FuRBwx9xhOFA5JQhTSc/yAkArt7lLq2HWX+oJLPlboLkUdTCtNMqQjJ5pmi7ZpDH6ZVukM
/nZss3sHdTir0nqLHLpIyArMKoQfEuaY8TqeKBxXkRzimJUNfgOrqErIwVT4ZVxPKvB0SBhHvYBI
WbXmlgB9S07fwVCxKt2+y6axixSKHlTRvIE5LyO3+EE3wnFahR3QJCpjP5AHEKIY7XFVBd/lbobo
d/ADTha6+w4ljrtPrwa3aeiINAsQPTMRFb68TrgTv4MpG2NiSg0UdadWxzT5u8LNKFRuy+HiCjeU
yhdfP66Q+20t2Zuwe1XlzPaJQr0Id7I8d7kI6NtfnbfwJNkjkBDzW9S74vyuOHv/+eK8KJ8vviTP
qjAUaN2L2EbbtN3xwq57TBkbqCkjN6RpvCXsPUEfBvU6c+IkxSksjeBRZzIwcHChwGYNElx9RFU0
iHAKTXvd00RCmZEOJUq5hMOiGa6krfHQ+Ct71GzqQ4itHBKrXR7Y4RU9nJ81CjJGqtAcaHNGK5rA
WZmtXMmIgm6vw6yuhTozt7oRzRRFh1uhsjaxOZSDyQvVYLCwJjQ1CFohsPIqnPk1azjsYEYCbXfr
o9wtxgsX6SIZ4YBkPtJ6z/uobpyUx8qcIloPGwz64HiK1UrcWprsG3A7i5PK7BoL2OXeexMv5RE8
8xJQO5mOLCknJ0vQUdtrNZebHvJx2vbGcE6GxzgFr0vdR2IWwmWTr4QN+1OT2WT5zJutXDE3Cepw
9WHtPqewUwdSIdUWlpENDTOVhQBLNCcr/3ITzHpRClRUo7NJsbIGwfCvSQF2dF1LxmPiq7KzSyPa
dvY1K6V8oogYRMERGrGJ2Mfgfh2qoE9AJVx3mIqgX+BuTlvbTLnFOUu68o2YwdlxzNIIZ+VWp2ie
yRZuClIhg3kriQe6VcpulDu/KiblL0iVchj/z1TR+wncPqwE2gM+XA0LjHSmtD0uVMShCqUR9fsC
GgdTOyBa4H4XpiGo4ILa/BfkUP+3OWdpmLSGQ6TapyESFPYjFQlC9qAsmeg7hVg927ssSZYRMhFV
ElemVuwROSRsqGvgqt7bPRRBqJtqkpUBgzsZf+57lkGjUDc55XxzKlmx99oc+Kc7H5vMoJRbh01D
k9u/ELFoD2a7ql1vlud7b1kRPTFrsxp5VgCz0lbQytL+NUU451ZrK9acxsvNXDjw4rzGMFg0RCnc
ISH9B/Y/Knxmv3boDXXI96G2Ivh4oYlB2EBUX7KNB9IF0g6OoHGygzaYNClr2qx10lbLN+sL7nQL
vieMrSU7i7/PaeyiOXPZObl4kcbOLOzY2o4tNDV49mSKwtA4P8gYx5jPZOUvWXx0Dxy9Bd8MJkxJ
E0zwnUpg6KEHJg8g+S1Hs3TjLwAAAP//AwBQSwMEFAAGAAgAAAAhAA3RkJ+2AAAAGwEAACcAAAB0
aGVtZS90aGVtZS9fcmVscy90aGVtZU1hbmFnZXIueG1sLnJlbHOEj00KwjAUhPeCdwhvb9O6EJEm
3YjQrdQDhOQ1DTY/JFHs7Q2uLAguh2G+mWm7l53JE2My3jFoqhoIOumVcZrBbbjsjkBSFk6J2Ttk
sGCCjm837RVnkUsoTSYkUiguMZhyDidKk5zQilT5gK44o49W5CKjpkHIu9BI93V9oPGbAXzFJL1i
EHvVABmWUJr/s/04GolnLx8WXf5RQXPZhQUoosbM4CObqkwEylu6usTfAAAA//8DAFBLAQItABQA
BgAIAAAAIQDp3g+//wAAABwCAAATAAAAAAAAAAAAAAAAAAAAAABbQ29udGVudF9UeXBlc10ueG1s
UEsBAi0AFAAGAAgAAAAhAKXWp+fAAAAANgEAAAsAAAAAAAAAAAAAAAAAMAEAAF9yZWxzLy5yZWxz
UEsBAi0AFAAGAAgAAAAhAGt5lhaDAAAAigAAABwAAAAAAAAAAAAAAAAAGQIAAHRoZW1lL3RoZW1l
L3RoZW1lTWFuYWdlci54bWxQSwECLQAUAAYACAAAACEAMN1DKagGAACkGwAAFgAAAAAAAAAAAAAA
AADWAgAAdGhlbWUvdGhlbWUvdGhlbWUxLnhtbFBLAQItABQABgAIAAAAIQAN0ZCftgAAABsBAAAn
AAAAAAAAAAAAAAAAALIJAAB0aGVtZS90aGVtZS9fcmVscy90aGVtZU1hbmFnZXIueG1sLnJlbHNQ
SwUGAAAAAAUABQBdAQAArQoAAAAAPD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgi
IHN0YW5kYWxvbmU9InllcyI/Pg0KPGE6Y2xyTWFwIHhtbG5zOmE9Imh0dHA6Ly9zY2hlbWFzLm9w
ZW54bWxmb3JtYXRzLm9yZy9kcmF3aW5nbWwvMjAwNi9tYWluIiBiZzE9Imx0MSIgdHgxPSJkazEi
IGJnMj0ibHQyIiB0eDI9ImRrMiIgYWNjZW50MT0iYWNjZW50MSIgYWNjZW50Mj0iYWNjZW50MiIg
YWNjZW50Mz0iYWNjZW50MyIgYWNjZW50ND0iYWNjZW50NCIgYWNjZW50NT0iYWNjZW50NSIgYWNj
ZW50Nj0iYWNjZW50NiIgaGxpbms9ImhsaW5rIiBmb2xIbGluaz0iZm9sSGxpbmsiLz4IAHIAYQBo
AG0AYQBuAHMAYQANAEQAaQByAGsAIABLAHUAdABzAGMAaABlAHIAAABwFAAAVxgAAJoZAACGGgAA
ChsAADMnAAA0JwAAdCcAAEcrAABULAAACS4AAHYxAADsMgAAcjcAAGk4AAA/OwAAQTsAAPQ9AABk
QAAAOEEAAPRBAAAlQgAAt0IAABFFAAA7RgAA1UYAAEpHAABQSgAAok0AAHVQAAD1UAAAt1EAALlR
AAC0UwAAeVQAAM5VAACVWgAAxVwAAJZdAAA9XwAAbl8AANNfAABLYAAAoGAAAMlhAAA+YgAAQWIA
ANlkAAAtZgAA+GYAAFRrAADPbgAA+m4AAClwAACdcwAA4nMAAPpzAAAvdQAACHcAAC13AAAfegAA
znoAABB7AAAlfAAAqHwAALJ+AAB0fwAAVoMAANiHAABYmAAACAByAGEAaABtAGEAbgBzAGEAAAAA
AAAAAAD/////AwBkAGsAdQAAAAAAAAAAAAAAAAABAAAAAAA2N1ETAQByAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAADwg1ITAQByAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACQ1VMTCAByAGEAaABtAGEAbgBz
AGEAAAAAAAAAAAD/////AAAAAAAAAAAAAAAAAAAAAAAAAAACAAAAAAD/////AAAAAAAAAAAAAAAA
AAAAAAAAAAACAAAAAAD/////AAAAAAAAAAAAAAAAAAAAAAAAAAACAAAAAAD/////AAAAAAAAAAAA
AAAAAAAAAAAAAAACAAAAAAD/////AAAAAAAAAAAAAAAAAAAAAAAAAAACAAAAAAD/////CAByAGEA
aABtAGEAbgBzAGEAAAAAAAAAAAD/////CAByAGEAaABtAGEAbgBzAGEAAAAAAAAAAAD/////CABy
AGEAaABtAGEAbgBzAGEAAAAAAAAAAAD/////AAAAAAAAAAAAAAAAAAAAAAAAAAACAAAAAAD/////
CAByAGEAaABtAGEAbgBzAGEAAAAAAAAAAAD/////AAAAAAAAAAAAAAAAAAAAAAAAAAACAAAAAAD/
////AAAAAAAAAAAAAAAAAAAAAAAAAAACAAAAAAD/////AAAAAAAAAAAAAAAAAAAAAAAAAAACAAAA
AAD/////CAByAGEAaABtAGEAbgBzAGEAAAAAAAAAAAD/////CAByAGEAaABtAGEAbgBzAGEAAAAA
AAAAAAD/////CAByAGEAaABtAGEAbgBzAGEAAAAAAAAAAAD/////CAByAGEAaABtAGEAbgBzAGEA
AAAAAAAAAAD/////CAByAGEAaABtAGEAbgBzAGEAAAAAAAAAAAD/////AAAAAAAAAAAAAAAAAAAA
AAAAAAACAAAAAAD/////AAAAAAAAAAAAAAAAAAAAAAAAAAACAAAAAAD/////CAByAGEAaABtAGEA
bgBzAGEAAAAAAAAAAAD/////CAByAGEAaABtAGEAbgBzAGEAAAAAAAAAAAD/////AAAAAAAAAAAA
AAAAAAAAAAAAAAACAAAAAAD/////AAAAAAAAAAAAAAAAAAAAAAAAAAACAAAAAAD/////CAByAGEA
aABtAGEAbgBzAGEAAAAAAAAAAAD/////CAByAGEAaABtAGEAbgBzAGEAAAAAAAAAAAD/////AAAA
AAAAAAAAAAAAAAAAAAAAAAACAAAAAAD/////AAAAAAAAAAAAAAAAAAAAAAAAAAACAAAAAAD/////
AAAAAAAAAAAAAAAAAAAAAAAAAAACAAAAAAD/////AAAAAAAAAAAAAAAAAAAAAAAAAAACAAAAAAD/
////AAAAAAAAAAAAAAAAAAAAAAAAAAACAAAAAAD/////AAAAAAAAAAAAAAAAAAAAAAAAAAACAAAA
AAD/////AAAAAAAAAAAAAAAAAAAAAAAAAAACAAAAAAD/////AAAAAAAAAAAAAAAAAAAAAAAAAAAC
AAAAAAD/////CAByAGEAaABtAGEAbgBzAGEAAAAAAAAAAAD/////CAByAGEAaABtAGEAbgBzAGEA
AAAAAAAAAAD/////CAByAGEAaABtAGEAbgBzAGEAAAAAAAAAAAD/////AAAAAAAAAAAAAAAAAAAA
AAAAAAACAAAAAAD/////AAAAAAAAAAAAAAAAAAAAAAAAAAACAAAAAAD/////AAAAAAAAAAAAAAAA
AAAAAAAAAAACAAAAAAD/////CAByAGEAaABtAGEAbgBzAGEAAAAAAAAAAAD/////AAAAAAAAAAAA
AAAAAAAAAAAAAAACAAAAAAD/////AAAAAAAAAAAAAAAAAAAAAAAAAAACAAAAAAD/////CAByAGEA
aABtAGEAbgBzAGEAAAAAAAAAAAD/////AAAAAAAAAAAAAAAAAAAAAAAAAAACAAAAAAD/////CABy
AGEAaABtAGEAbgBzAGEAAAAAAAAAAAD/////CAByAGEAaABtAGEAbgBzAGEAAAAAAAAAAAD/////
CAByAGEAaABtAGEAbgBzAGEAAAAAAAAAAAD/////CAByAGEAaABtAGEAbgBzAGEAAAAAAAAAAAD/
////CAByAGEAaABtAGEAbgBzAGEAAAAAAAAAAAD/////CAByAGEAaABtAGEAbgBzAGEAAAAAAAAA
AAD/////CAByAGEAaABtAGEAbgBzAGEAAAAAAAAAAAD/////AAAAAAAAAAAAAAAAAAAAAAAAAAAC
AAAAAAD/////CAByAGEAaABtAGEAbgBzAGEAAAAAAAAAAAD/////CAByAGEAaABtAGEAbgBzAGEA
AAAAAAAAAAD/////CAByAGEAaABtAGEAbgBzAGEAAAAAAAAAAAD/////CAByAGEAaABtAGEAbgBz
AGEAAAAAAAAAAAD/////CAByAGEAaABtAGEAbgBzAGEAAAAAAAAAAAD/////AAAAAAAAAAAAAAAA
AAAAAAAAAAACAAAAAAD/////AAAAAAAAAAAAAAAAAAAAAAAAAAACAAAAAAD/////CAByAGEAaABt
AGEAbgBzAGEAAAAAAAAAAAD/////AAAAAAAAAAAAAAAAAAAAAAAAAAACAAAAAAD/////CAByAGEA
aABtAGEAbgBzAGEAAAAAAAAAAAD/////AAAAAAAAAAAAAAAAAAAAAAAAAAACAAAAAAD/////w4oE
RwAAAAAAAAAAAAAAAAAAbjQFBwAAAAAAAAAAAAAAAAAAWTwFJwAAAAAAAAAAAAAAAAAAWUQFRwAA
AAAAAAAAAAAAAAAAMlwDBwAAAAAAAAAAAAAAAAAAM1wDBwAAAAAAAAAAAAAAAAAAwFsDBwAAAAAA
AAAAAAAAAAAAwFsDBwAAAAAAAAAAAAAAAAAAwFsDBwAAAAAAAAAAAAAAAAAAwFsDBwAAAAAAAAAA
AAAAAAAAjGIDJwAAAAAAAAAAAAAAAAAAMlwDBwAAAAAAAAAAAAAAAAAAemIDJwAAAAAAAAAAAAAA
AAAAwFsDBwAAAAAAAAAAAAAAAAAARFwDBwAAAAAAAAAAAAAAAAAAwFsDBwAAAAAAAAAAAAAAAAAA
wFsDBwAAAAAAAAAAAAAAAAAAwFsDBwAAAAAAAAAAAAAAAAAAF4QEJwAAAAAAAAAAAAAAAAAAlmID
JwAAAAAAAAAAAAAAAAAAgmIDJwAAAAAAAAAAAAAAAAAAYFwDBwAAAAAAAAAAAAAAAAAAblwDBwAA
AAAAAAAAAAAAAAAAwFsDBwAAAAAAAAAAAAAAAAAAwFsDBwAAAAAAAAAAAAAAAAAAYlwDBwAAAAAA
AAAAAAAAAAAAnmIDJwAAAAAAAAAAAAAAAAAAwFsDBwAAAAAAAAAAAAAAAAAAwFsDBwAAAAAAAAAA
AAAAAAAAyFMERwAAAAAAAAAAAAAAAAAAwFMERwAAAAAAAAAAAAAAAAAAwFsDBwAAAAAAAAAAAAAA
AAAAwFsDBwAAAAAAAAAAAAAAAAAAwFsDBwAAAAAAAAAAAAAAAAAAwFsDBwAAAAAAAAAAAAAAAAAA
wFsDBwAAAAAAAAAAAAAAAAAAwFsDBwAAAAAAAAAAAAAAAAAAwFsDBwAAAAAAAAAAAAAAAAAAwFsD
BwAAAAAAAAAAAAAAAAAAZlwDBwAAAAAAAAAAAAAAAAAAZ1wDBwAAAAAAAAAAAAAAAAAAalwDBwAA
AAAAAAAAAAAAAAAAwFsDBwAAAAAAAAAAAAAAAAAAwFsDBwAAAAAAAAAAAAAAAAAAwFsDBwAAAAAA
AAAAAAAAAAAAulMERwAAAAAAAAAAAAAAAAAAwFsDBwAAAAAAAAAAAAAAAAAAwFsDBwAAAAAAAAAA
AAAAAAAABIsERwAAAAAAAAAAAAAAAAAAwFsDBwAAAAAAAAAAAAAAAAAAqmIDJwAAAAAAAAAAAAAA
AAAA5lMERwAAAAAAAAAAAAAAAAAArGIDJwAAAAAAAAAAAAAAAAAABYsERwAAAAAAAAAAAAAAAAAA
zVMERwAAAAAAAAAAAAAAAAAA0VMERwAAAAAAAAAAAAAAAAAA0VMERwAAAAAAAAAAAAAAAAAAwFsD
BwAAAAAAAAAAAAAAAAAAzlMERwAAAAAAAAAAAAAAAAAA0lMERwAAAAAAAAAAAAAAAAAA21MERwAA
AAAAAAAAAAAAAAAA1VMERwAAAAAAAAAAAAAAAAAA1VMERwAAAAAAAAAAAAAAAAAAwFsDBwAAAAAA
AAAAAAAAAAAAwFsDBwAAAAAAAAAAAAAAAAAAneQExwAAAAAAAAAAAAAAAAAAwFsDBwAAAAAAAAAA
AAAAAAAAnuQExwAAAAAAAAAAAAAAAAAAwFsDBwAAAAAAAAAAAAAAAAAAAAAAAIYAAADfAAAAJgEA
ADcBAAD9AQAADAIAAGYCAAChAgAAzwIAAP8CAACeAwAAGAQAAK4EAAC8BAAA8AQAADUFAABDBQAA
3wUAAO4FAAA0BgAAdAYAAK8GAADaBgAA8gYAACoHAABYBwAAewcAAK8HAAD+BwAAFwgAACYIAADc
CAAA6ggAAPgIAAAVCQAAswkAAEEKAACWCgAApAoAAOIKAADyCgAAWgsAAHILAACKCwAAogsAALAL
AAC+CwAAzAsAAOgLAAAvDAAAPgwAAE0MAABcDAAAeAwAAIYMAACVDAAApAwAACUNAAA0DQAAQw0A
AFINAABiDQAAcQ0AAKUNAAApDgAAOA4AAIcOAACWDgAAKA8AACsPAAAAAAAAWJgAABMAAOYAAAAA
/////wAIAACbIQAAeCoAAHM/AADPUwAAl2UAAOJ7AAD4iQAA55AAACGYAABWoAAAWKAAAFEAAABX
AAAAWgAAAF8AAABlAAAAZwAAAGkAAABrAAAAbAAAAG8AAAByAAAAAAgAADURAACKFQAABBoAAH8f
AAD1IwAArykAAMctAABEMwAAcjgAAJE9AABHQwAAoUcAAFlLAADbTgAAUFIAADFXAADYbQAAL38A
AC+QAABalgAAJpoAAGydAABYoAAAUgAAAFMAAABUAAAAVQAAAFYAAABYAAAAWQAAAFsAAABcAAAA
XQAAAF4AAABgAAAAYQAAAGIAAABjAAAAZAAAAGYAAABoAAAAagAAAG0AAABuAAAAcAAAAHEAAAAv
iAAAWIgAAGCIAABhiAAAiogAAIyIAACNiAAAtogAAL6IAAC/iAAA6IgAAOqIAADriAAAFIkAABiJ
AABYmAAAE1gU/xWAE1gU/xWAE1gU/xWAE1gU/xWAE1gU/xWADwAA8DgAAAAAAAbwGAAAAAIEAAAC
AAAAAQAAAAEAAAABAAAAAgAAAEAAHvEQAAAA//8AAAAA/wCAgIAA9wAAEAAPAALwkgAAABAACPAI
AAAAAQAAAAEEAAAPAAPwMAAAAA8ABPAoAAAAAQAJ8BAAAAAAAAAAAAAAAAAAAAAAAAAAAgAK8AgA
AAAABAAABQAAAA8ABPBCAAAAEgAK8AgAAAABBAAAAA4AAFMAC/AeAAAAvwEAABAAywEAAAAA/wEA
AAgABAMJAAAAPwMBAAEAAAAR8AQAAAABAAAA//8DAAoAAAAAATY3URP/////AAAAAfCDUhP/////
AAAAAZDVUxP/////chQAAGsYAACcGQAAMIkAAAAAAAABAAAAAgAAAFcYAACaGQAAhhoAADCJAAAA
AAAA4wwAAOoMAACxIQAAtCEAAN4yAADpMgAAPkUAAEZFAADARgAAx0YAADBIAAA3SAAAOEgAAD5I
AADgSAAA40gAAA5JAAAVSQAAnkkAAKNJAACkSQAA2UkAAIFWAACEVgAAQFoAAENaAACQXwAAkl8A
AIpmAACMZgAAk2oAAJxqAAA+bQAASm0AAN1wAADicAAAZnYAAG52AAAteAAAMHgAALZ6AAC+egAA
1HoAAN16AACZgAAAnIAAANaAAADYgAAA84IAAP6CAADuhAAA9IQAAPqEAAD+hAAAVYYAAFqGAADx
hgAA9oYAAC6JAACLiwAAk4sAAN2NAADjjQAAWo4AAGKOAABkjgAAao4AAHKOAAB4jgAAF5AAAB+Q
AABPkAAAV5AAAKqQAACwkAAAI5EAACuRAABikQAAaJEAAAGSAAAJkgAAC5IAABGSAAAZkgAAH5IA
ACeSAAAtkgAARJIAAEqSAADikgAA6JIAAHCTAAB2kwAAxZMAAMuTAACXlAAAn5QAAK+UAAC3lAAA
x5QAAM+UAADflAAA5ZQAAO2UAADzlAAAF5UAAB2VAADTlQAA2ZUAACSWAAAtlgAATJYAAFGWAACg
lgAAppYAANSWAADalgAAZ5cAAG2XAABNmAAAVZgAAFmYAAAHABwABwAcAAcAHAAHABwABwAcAAcA
HAAHABwABwAcAAcAHAAHABwABwAFAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHQAHABwABwAc
AAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcABwAcAAcAHAAHABwABwAcAAcA
HAAHABwABwAcAAcAHAAHABwABwAdAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAc
AAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAAAAAALMI
AAC2CAAApQsAAKkLAABqDAAAbQwAALEMAACzDAAARQ4AAEkOAACFDgAAjA4AAMkOAADSDgAADw8A
ABEPAACHDwAAkA8AALkPAAC7DwAA+Q8AAAAQAAAUEAAAFhAAAFIQAABcEAAAlhAAAJ4QAAD/EAAA
AREAAHsRAAB+EQAAwBEAAMMRAAAEEgAADBIAADASAAA1EgAAORIAADwSAAB/EgAAghIAAMISAADK
EgAAXRMAAF8TAAB8EwAAgxMAAJYTAACfEwAAoxMAAKkTAADpEwAA7xMAADAUAAAzFAAAthQAAL4U
AAD8FAAA/hQAAEEVAABGFQAAgRUAAI0VAACtFQAAshUAAP0VAAABFgAAQBYAAEYWAACuFgAAtRYA
APkWAAAEFwAARBcAAFQXAAC+FwAAxBcAAA0YAAAVGAAAURgAAFUYAAAbGQAAJRkAAGEZAABkGQAA
ohkAAKYZAADlGQAA6BkAACwaAAAvGgAAcBoAAHMaAACTGgAAnRoAAFcbAABiGwAAnRsAAKAbAAA9
HAAAQxwAAN4cAADiHAAAZh0AAGkdAAC/HQAAxB0AAAQeAAALHgAAfx4AAIEeAADJHgAA0R4AALMf
AAC9HwAA8R8AAPsfAAA1IAAAPSAAAHUgAAB8IAAAtSAAALwgAAD5IAAAACEAAFUhAABhIQAAsSEA
ALQhAADlIQAA5yEAAB4iAAAnIgAAwyIAAMUiAAAFIwAACyMAAGUjAABrIwAAjSMAAI8jAADjIwAA
6CMAACgkAAAyJAAApCQAAKskAADHJQAAyyUAACUmAAAsJgAALSYAADYmAABxJgAAdSYAALYmAAC5
JgAAvScAAMInAAALKAAADigAAHgoAAB7KAAAtSgAALkoAAD7KAAAASkAAEwpAABTKQAAkykAAKQp
AADVKQAA2ikAABwqAAAhKgAAYyoAAGcqAACkKgAArCoAAOYqAADrKgAAJisAACwrAACIKwAAjisA
AM0rAADUKwAAmiwAAKEsAADfLAAA4SwAAB4tAAArLQAAZS0AAGwtAACpLQAAqy0AAPUtAAD7LQAA
TC4AAFguAACJLgAAlC4AAM0uAADYLgAAFC8AABcvAABXLwAAXS8AAJMvAACeLwAA6S8AAPUvAAAv
MAAANjAAAHIwAAB4MAAAtDAAAL0wAAD3MAAAAjEAADwxAABBMQAA4TEAAOwxAAD4MQAA+jEAAD8y
AABJMgAAcDIAAH0yAACBMgAAhTIAAL8yAADIMgAANTMAADszAAB8MwAAgDMAAL4zAADDMwAABDQA
AAg0AABKNAAAUTQAAI80AACWNAAA1DQAANg0AAAXNQAAHDUAAJQ1AACXNQAA2jUAAN81AAAiNgAA
KjYAAGU2AABsNgAAvTYAAMM2AAD0NgAA/jYAABk3AAAvNwAAOzcAAD43AABPNwAAcDcAALo3AAC/
NwAA+zcAAAM4AAAwOAAAOjgAAFk4AABpOAAArjgAALc4AAD1OAAA9zgAADU5AAA+OQAAdjkAAIA5
AAC9OQAAxzkAAOU5AADoOQAA+TkAAAY6AAA/OgAAQjoAAMs6AADTOgAAjTsAAJY7AAARPAAAFjwA
ABc8AAAtPAAAhzwAALI8AAD6PAAACT0AAHo9AACBPQAAvD0AAMQ9AAA3PgAAQj4AAHo+AACCPgAA
lj4AAJo+AAC5PgAAwT4AAP0+AAAFPwAAOD8AAEA/AABBPwAARD8AAKE/AACqPwAA5T8AAOk/AAAj
QAAAMUAAALFAAACzQAAAL0EAADFBAADcQQAA40EAAPxBAAD/QQAApkIAAKxCAAD2QgAAC0MAABdD
AAAdQwAAZEMAAG5DAACvQwAAtkMAAOpDAAD3QwAANkQAAEtEAABMRAAAUkQAAI9EAACZRAAAz0QA
ANZEAACfRQAApUUAANBFAADcRQAA8UUAAP1FAAAXRgAAIEYAAD9GAABWRgAAnkYAAKFGAADARgAA
x0YAACJHAAAnRwAAmEcAAJ5HAAAeSAAAIkgAAIdIAACRSAAAZEkAAGdJAACkSQAA2EkAAB9KAAAj
SgAAkkoAAJhKAADVSgAA3UoAABpLAAAkSwAAmUsAAKFLAAARTAAAG0wAAFNMAABaTAAAl0wAAJxM
AADeTAAA4EwAANlNAADfTQAAW1AAAF5QAAB6UAAAfFAAALtQAAC/UAAA1lAAAN5QAAD6UAAA/FAA
AF9RAABlUQAAvVEAAL9RAAD6UQAA/lEAALhTAADCUwAAfVQAAH9UAADLVAAAzVQAANJVAADbVQAA
+VUAAPxVAABrWAAAbFgAAMlcAADMXAAAD10AABJdAABcXgAAXl4AAM1eAADPXgAAQ18AAEVfAABM
XwAAUl8AAHRfAAB2XwAAsF8AALNfAADZXwAA218AAFphAABdYQAAs2EAALZhAADPYQAA0WEAAO1h
AADwYQAARmIAAEhiAADeZAAA4GQAANxlAADeZQAAM2YAADVmAAD9ZgAA/2YAAFJnAABXZwAAY2cA
AGZnAAD7ZwAA/WcAABdpAAAZaQAAu2kAAMBpAAC+agAAxGoAAMxqAADUagAA22oAAN1qAADlagAA
82oAAFprAABcawAAp2sAAK5rAABrbgAAbW4AAABvAAACbwAABnAAAAhwAAAwcAAAMnAAAJ9wAACg
cAAAOnEAAD1xAADMcQAAznEAAP5xAAAIcgAAL3IAADFyAAA1cwAAYXMAALhzAAC+cwAAAXQAAAN0
AACZdAAAnHQAANd0AADadAAAQXUAAER1AAB4dgAAgHYAAA53AAAQdwAAM3cAADV3AADDeQAAxXkA
AO15AADweQAAJXoAACd6AADUegAA3XoAAN96AADlegAAFnsAABh7AAAqfAAALHwAAK18AACvfAAA
23wAAOJ8AADxfAAA83wAAHV+AAB3fgAAuH4AALp+AAB5fwAAe38AABiAAAAbgAAAuYIAAL2CAADQ
ggAA1oIAAFyDAABegwAAA4QAAA2EAAAghwAAKocAAFmIAAAZiQAALokAAD6JAABIiQAAi4sAAJOL
AADfiwAA4YsAAA2MAAARjAAA3Y0AAOONAABajgAAYo4AAGSOAABqjgAAco4AAHiOAAAXkAAAH5AA
AE+QAABXkAAAqpAAALCQAAAjkQAAK5EAAAGSAAAJkgAAC5IAABGSAAAZkgAAH5IAACeSAAAtkgAA
RJIAAEqSAADikgAA6JIAAHCTAAB2kwAAxZMAAMuTAACXlAAAn5QAAK+UAAC3lAAAx5QAAM+UAADf
lAAA5ZQAAO2UAADzlAAAF5UAAB2VAADTlQAA2ZUAAKCWAACmlgAA1JYAANqWAADclgAA3pYAAGeX
AABtlwAATZgAAFWYAABZmAAABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAz
AAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMA
BwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAH
ADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA
MwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAz
AAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMA
BwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAH
ADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA
MwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAz
AAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMA
BwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAH
ADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA
MwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAz
AAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHAAUABwAzAAcAMwAHADMA
BwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAH
ADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA
MwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAz
AAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMA
BwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAH
ADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA
MwAHADMABwAFAAcABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAH
ADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA
MwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHAAAAAACAAwAAxwMAADUJAABXCQAALB8AADEfAAAv
iAAALYkAAC6JAABNmAAAVZgAAFmYAAAHAAUABwAFAAcABQAHAAUABwAHAAUABwACAAEAAAABAAAA
/w//D/8P/w//D/8P/w//D/8PAAACAAAAAgAAAP8P/w//D/8P/w//D/8P/w//DwAAAQAAAP8AAAAA
AAAAAAAAAgAAAAAAAAAAABgAAA+EsAERhFD+FcYFAAGwAQZehLABYIRQ/gAAAQAAAP8AAAAAAAAA
AAAAAgAAAAAAAAAAABgAAA+EQAIRhMD9FcYFAAFAAgZehEACYITA/QAAAQAAAP8AAAAAAAAAAAAA
AgAAAAAAAAAAABgAAA+E0AIRhDD9FcYFAAHQAgZehNACYIQw/QAAAQAAAP8AAAAAAAAAAAAAAgAA
AAAAAAAAABgAAA+EYAMRhKD8FcYFAAFgAwZehGADYISg/AAAAQAAAP8AAAAAAAAAAAAAAgAAAAAA
AAAAABgAAA+E8AMRhBD8FcYFAAHwAwZehPADYIQQ/AAAAQAAAP8AAAAAAAAAAAAAAgAAAAAAAAAA
ABgAAA+EgAQRhID7FcYFAAGABAZehIAEYISA+wAAAQAAAP8AAAAAAAAAAAAAAgAAAAAAAAAAABgA
AA+EEAURhPD6FcYFAAEQBQZehBAFYITw+gAAAQAAAP8AAAAAAAAAAAAAAgAAAAAAAAAAABgAAA+E
oAURhGD6FcYFAAGgBQZehKAFYIRg+gAAAQAAAP8AAAAAAAAAAAAAAgAAAAAAAAAAABgAAA+EMAYR
hND5FcYFAAEwBgZehDAGYITQ+QAAAQAAABcAAAAAAAAAAAAAAAAAAAAAAAAAMhgAAA+E0AIRhJj+
FcYFAAEAAAZehNACYISY/k9KBwBRSgcAQioBcGgAAAAAUyoANwgAQ0oUADYIAD4qADUIAF5KBwBh
ShQAXQgAXAgAAQDPJQEAAAAAAAEAAAAAAAAAAAAAAAAAAAAAADYYAAAPhKAFEYSY/hXGBQABAAAG
XoSgBWCEmP5CKgFwaAAAAABTKgA3CABPSgAAUUoAAENKFAA2CAA+KgA1CABQSgAAXkoAAGFKFABd
CABcCAACAAEALgABAAAAFwAAAAAAAAAAAAAAAAAAAAAAAAAyGAAAD4RwCBGETP8VxgUAAQAABl6E
cAhghEz/T0oHAFFKBwBCKgFwaAAAAABTKgA3CABDShQANggAPioANQgAXkoHAGFKFABdCABcCAAB
AKAlAQAAABcAAAAAAAAAAAAAAAAAAAAAAAAAMhgAAA+EQAsRhJj+FcYFAAEAAAZehEALYISY/k9K
BwBRSgcAQioBcGgAAAAAUyoANwgAQ0oUADYIAD4qADUIAF5KBwBhShQAXQgAXAgAAQDPJQEAAAAX
AAAAAAAAAAAAAAAAAAAAAAAAADIYAAAPhBAOEYSY/hXGBQABAAAGXoQQDmCEmP5PSgUAUUoFAEIq
AXBoAAAAAFMqADcIAENKFAA2CAA+KgA1CABeSgUAYUoUAF0IAFwIAAEAyyUBAAAAFwAAAAAAAAAA
AAAAAAAAAAAAAAAyGAAAD4TgEBGETP8VxgUAAQAABl6E4BBghEz/T0oHAFFKBwBCKgFwaAAAAABT
KgA3CABDShQANggAPioANQgAXkoHAGFKFABdCABcCAABAKAlAQAAABcAAAAAAAAAAAAAAAAAAAAA
AAAAMhgAAA+EsBMRhJj+FcYFAAEAAAZehLATYISY/k9KBwBRSgcAQioBcGgAAAAAUyoANwgAQ0oU
ADYIAD4qADUIAF5KBwBhShQAXQgAXAgAAQDPJQEAAAAXAAAAAAAAAAAAAAAAAAAAAAAAADIYAAAP
hIAWEYSY/hXGBQABAAAGXoSAFmCEmP5PSgUAUUoFAEIqAXBoAAAAAFMqADcIAENKFAA2CAA+KgA1
CABeSgUAYUoUAF0IAFwIAAEAyyUBAAAAFwAAAAAAAAAAAAAAAAAAAAAAAAAyGAAAD4RQGRGETP8V
xgUAAQAABl6EUBlghEz/T0oHAFFKBwBCKgFwaAAAAABTKgA3CABDShQANggAPioANQgAXkoHAGFK
FABdCABcCAABAKAlAgAAAAEAAAAAAAAAAAAAAAAAAAACAAAAAAAAAAAAAAAAAAAA////////////
/wIAAAAAAAcAVwBXADgATgB1AG0AMQD//wIAAAAAAAAABQAAAAQAAAAIAAAA5QAAAAAAAAAEAAAA
iw4ZAPkLJADRHoMABAe0AP0ovwAAAAAALokAADCJAAAAAAAAAQAAAP9AAQABADocAABxHAAAAAAA
AAEAAQA6HAAABQAAADocAAAAAAAAAhAAAAAAAAAAWJgAAJgAABAAQAAA//8BAAAABwBVAG4AawBu
AG8AdwBuAP//AQAIAAAAAAAAAAAAAAD//wEAAAAAAP//AAACAP//AAAAAP//AAACAP//AAAAAAoA
AABHHpABAAACAgYDBQQFAgME/yoA4EF4AMAJAAAAAAAAAP8BAAAAAAAAVABpAG0AZQBzACAATgBl
AHcAIABSAG8AbQBhAG4AAAA1HpABAgAFBQECAQcGAgUHAAAAAAAAABAAAAAAAAAAAAAAAIAAAAAA
UwB5AG0AYgBvAGwAAAAzLpABAAACCwYEAgICAgIE/yoA4EN4AMAJAAAAAAAAAP8BAAAAAAAAQQBy
AGkAYQBsAAAAOT2QAQAAAgsGCQICBAMCBP8CAOH//ABACQAAAAAAAACfAQAAAAAAAEMAbwBuAHMA
bwBsAGEAcwAAADUukAEAAAILBgQDBQQEAgT/LgDhW2AAwCkAAAAAAAAA/wEBAAAAAABUAGEAaABv
AG0AYQAAAD89kAEAAAIHAwkCAgUCBAT/KgDgQ3gAwAkAAAAAAAAA/wEAAAAAAABDAG8AdQByAGkA
ZQByACAATgBlAHcAAAA3LpABAAACDwUCAgIEAwIE/wIA4f+sAEAJAAAAAAAAAJ8BAAAAAAAAQwBh
AGwAaQBiAHIAaQAAADcukAEAAAILBgQDBQQEAgT/BgChWyAAQBAAAAAAAAAAnwEAAAAAAABWAGUA
cgBkAGEAbgBhAAAAPyaQAQAAAgsGAwMIBAICBP8uAOf//QDSKWAkCgAAAAD/AQAAAAAAAEQAZQBq
AGEAVgB1ACAAUwBhAG4AcwAAAEEekAEAAAIEBQMFBAYDAgT/AgDg/yQAQgAAAAAAAAAAnwEAAAAA
AABDAGEAbQBiAHIAaQBhACAATQBhAHQAaAAAACIABABBCIgYACDQAgAAaAEAAAAAVlsDB99iBccA
AAAABQAgAAAAeRQAALV0AAAPAEYAAAAEAIOQ+AAAAHkUAAC1dAAADwBGAAAA+AAAAAAAAAAhAwAg
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMjAAAAAAAAAAAAAAAAAAAOiI
AADoiAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAgAAAAAAAAAAAAFLgxEAIAAAAAD//QEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAI
CFAAAAAAAPAAAAAJAAAAAAAAAAD///9/////f////3////9/////f////3////9//Si/AAAEAACy
AAAAAAAAAAAAAAAAAAAAAAAAAAAAIQQAAAAAAAAAAAAAAAAAAAAAAAAQHAAACQAAAAAAAAAAAHgA
AAB4AAAAAAAAAAAAAACgBQAAAAAAAAsAAAAAAAAA3AAAAP//EgAAAAAAAAAAAAAAAAAAAAAADQBE
AGkAcgBrACAASwB1AHQAcwBjAGgAZQByAAAAAAAAAAAAAAAAAAAAAAAAAAAAFAAAAAYAAAACAAAA
AAAMAAEADAD+/wAABgECAAAAAAAAAAAAAAAAAAAAAAABAAAA4IWf8vlPaBCrkQgAKyez2TAAAABs
AQAAEQAAAAEAAACQAAAAAgAAAJgAAAADAAAApAAAAAQAAACwAAAABQAAALwAAAAHAAAAyAAAAAgA
AADYAAAACQAAAPAAAAASAAAA/AAAAAoAAAAcAQAACwAAACgBAAAMAAAANAEAAA0AAABAAQAADgAA
AEwBAAAPAAAAVAEAABAAAABcAQAAEwAAAGQBAAACAAAA5AQAAB4AAAAEAAAAAAAAAB4AAAAEAAAA
AAAAAB4AAAAEAAAAAAAAAB4AAAAEAAAAAAAAAB4AAAAIAAAATm9ybWFsAAAeAAAAEAAAAERpcmsg
S3V0c2NoZXIAAAAeAAAABAAAADUAAAAeAAAAGAAAAE1pY3Jvc29mdCBPZmZpY2UgV29yZAAAAEAA
AAAAwGh4BAAAAEAAAAAAAAAAAAAAAEAAAAAAfB4tef/MAUAAAAAAog/xITDNAQMAAAAPAAAAAwAA
AHkUAAADAAAAtXQAAAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
/v8AAAYBAgAAAAAAAAAAAAAAAAAAAAAAAgAAAALVzdWcLhsQk5cIACss+a5EAAAABdXN1ZwuGxCT
lwgAKyz5rjgBAAD0AAAADAAAAAEAAABoAAAADwAAAHAAAAAFAAAAiAAAAAYAAACQAAAAEQAAAJgA
AAAXAAAAoAAAAAsAAACoAAAAEAAAALAAAAATAAAAuAAAABYAAADAAAAADQAAAMgAAAAMAAAA1QAA
AAIAAADkBAAAHgAAABAAAABORUMgRXVyb3BlIEx0ZC4AAwAAAPgAAAADAAAARgAAAAMAAADoiAAA
AwAAAAAADgALAAAAAAAAAAsAAAAAAAAACwAAAAAAAAALAAAAAAAAAB4QAAABAAAAAQAAAAAMEAAA
AgAAAB4AAAAGAAAAVGl0bGUAAwAAAAEAAAAAaAIAAAMAAAAAAAAAIAAAAAEAAAA4AAAAAgAAAEAA
AAABAAAAAgAAAAwAAABfUElEX0hMSU5LUwACAAAA5AQAAEEAAAAgAgAAHgAAAAMAAABfAHIAAwAA
AAwAAAADAAAAAAAAAAMAAAAFAAAAHwAAABsAAABtAGEAaQBsAHQAbwA6AEkAZQB0AGYAZABiAGgA
QABjAG8AbQBjAGEAcwB0AC4AbgBlAHQAAAAAAB8AAAABAAAAAAAAAAMAAABfAHIAAwAAAAkAAAAD
AAAAAAAAAAMAAAAFAAAAHwAAABsAAABtAGEAaQBsAHQAbwA6AEkAZQB0AGYAZABiAGgAQABjAG8A
bQBjAGEAcwB0AC4AbgBlAHQAAAAAAB8AAAABAAAAAAAAAAMAAABfAHIAAwAAAAYAAAADAAAAAAAA
AAMAAAAFAAAAHwAAABsAAABtAGEAaQBsAHQAbwA6AEkAZQB0AGYAZABiAGgAQABjAG8AbQBjAGEA
cwB0AC4AbgBlAHQAAAAAAB8AAAABAAAAAAAAAAMAAABfAHIAAwAAAAMAAAADAAAAAAAAAAMAAAAF
AAAAHwAAABsAAABtAGEAaQBsAHQAbwA6AEkAZQB0AGYAZABiAGgAQABjAG8AbQBjAGEAcwB0AC4A
bgBlAHQAAAAAAB8AAAABAAAAAAAAAAMAAABfAHIAAwAAAAAAAAADAAAAAAAAAAMAAAAFAAAAHwAA
ABsAAABtAGEAaQBsAHQAbwA6AEkAZQB0AGYAZABiAGgAQABjAG8AbQBjAGEAcwB0AC4AbgBlAHQA
AAAAAB8AAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAACAAAA
AwAAAAQAAAAFAAAABgAAAAcAAAAIAAAACQAAAAoAAAALAAAADAAAAA0AAAAOAAAADwAAABAAAAAR
AAAAEgAAABMAAAAUAAAAFQAAABYAAAAXAAAAGAAAABkAAAAaAAAAGwAAABwAAAAdAAAAHgAAAB8A
AAAgAAAAIQAAACIAAAAjAAAAJAAAACUAAAAmAAAAJwAAACgAAAApAAAAKgAAACsAAAAsAAAALQAA
AC4AAAAvAAAAMAAAADEAAAAyAAAAMwAAADQAAAA1AAAANgAAADcAAAA4AAAAOQAAADoAAAA7AAAA
PAAAAD0AAAA+AAAAPwAAAEAAAABBAAAAQgAAAEMAAABEAAAARQAAAEYAAABHAAAASAAAAEkAAABK
AAAASwAAAEwAAABNAAAATgAAAE8AAABQAAAAUQAAAFIAAABTAAAAVAAAAFUAAABWAAAAVwAAAFgA
AABZAAAAWgAAAFsAAABcAAAAXQAAAF4AAABfAAAAYAAAAGEAAABiAAAAYwAAAGQAAABlAAAAZgAA
AGcAAABoAAAAaQAAAGoAAABrAAAAbAAAAG0AAABuAAAAbwAAAHAAAABxAAAAcgAAAHMAAAD+////
dQAAAHYAAAB3AAAAeAAAAHkAAAB6AAAAewAAAP7///99AAAAfgAAAH8AAACAAAAAgQAAAIIAAACD
AAAAhAAAAIUAAACGAAAAhwAAAIgAAACJAAAAigAAAIsAAACMAAAAjQAAAI4AAACPAAAAkAAAAJEA
AACSAAAAkwAAAJQAAACVAAAAlgAAAJcAAACYAAAAmQAAAJoAAACbAAAAnAAAAJ0AAACeAAAAnwAA
AKAAAAChAAAA/v///6MAAACkAAAApQAAAKYAAACnAAAAqAAAAKkAAAD+////qwAAAKwAAACtAAAA
rgAAAK8AAACwAAAAsQAAAP7////9/////f///7UAAAD+/////v////7/////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
//////////////////////////////////////////////////////////////9SAG8AbwB0ACAA
RQBuAHQAcgB5AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFgAF
Af//////////AwAAAAYJAgAAAAAAwAAAAAAAAEYAAAAAAAAAAAAAAADQtt8JIjDNAbcAAACAAAAA
AAAAAEQAYQB0AGEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAKAAIB////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAdAAAAAAQAAAAAAAAMQBUAGEAYgBsAGUAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA4AAgEBAAAABgAAAP////8AAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAB8AAAAAEwAAAAAAABXAG8AcgBkAEQAbwBjAHUAbQBlAG4AdAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGgACAQIAAAAFAAAA/////wAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAu5gAAAAAAAAUAUwB1AG0AbQBh
AHIAeQBJAG4AZgBvAHIAbQBhAHQAaQBvAG4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAoAAIB
////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAogAAAAAQAAAA
AAAABQBEAG8AYwB1AG0AZQBuAHQAUwB1AG0AbQBhAHIAeQBJAG4AZgBvAHIAbQBhAHQAaQBvAG4A
AAAAAAAAAAAAADgAAgEEAAAA//////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAACqAAAAABAAAAAAAAABAEMAbwBtAHAATwBiAGoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEgACAP///////////////wAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAByAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA////////////////AAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAP7/////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
//////////////////////////////////////////////////////////8BAP7/AwoAAP////8G
CQIAAAAAAMAAAAAAAABGIAAAAE1pY3Jvc29mdCBXb3JkIDk3LTIwMDMgRG9jdW1lbnQACgAAAE1T
V29yZERvYwAQAAAAV29yZC5Eb2N1bWVudC44APQ5snEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA==

------_=_NextPart_001_01CD9935.C5176CBA--

From guyingjie@huawei.com  Sun Sep 23 23:55:18 2012
Return-Path: 
X-Original-To: decade@ietfa.amsl.com
Delivered-To: decade@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4BE321E8043 for ; Sun, 23 Sep 2012 23:55:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.471
X-Spam-Level: 
X-Spam-Status: No, score=-103.471 tagged_above=-999 required=5 tests=[AWL=2.676, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_UTF8=0.152, 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 xQ08gs4CHpXU for ; Sun, 23 Sep 2012 23:55:17 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id A4AC021E803C for ; Sun, 23 Sep 2012 23:55:16 -0700 (PDT)
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 AKZ12910; Mon, 24 Sep 2012 06:55:14 +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; Mon, 24 Sep 2012 07:54:38 +0100
Received: from SZXEML422-HUB.china.huawei.com (10.82.67.161) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 24 Sep 2012 07:55:13 +0100
Received: from SZXEML511-MBS.china.huawei.com ([169.254.4.129]) by szxeml422-hub.china.huawei.com ([10.82.67.161]) with mapi id 14.01.0323.003; Mon, 24 Sep 2012 14:54:37 +0800
From: "Guyingjie (Yingjie)" 
To: Martin Stiemerling , "decade@ietf.org" 
Thread-Topic: [decade] WG Action: Conclusion of Decoupled Application Data Enroute (decade)
Thread-Index: AQHNlxXQTgOvNeYw70eyG/03qRmw6JeZEILw
Date: Mon, 24 Sep 2012 06:54:37 +0000
Message-ID: 
References: <20120919230313.17329.44102.idtracker@ietfa.amsl.com> <505AE794.8070304@neclab.eu>
In-Reply-To: <505AE794.8070304@neclab.eu>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.138.122.31]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Subject: [decade] =?utf-8?b?562U5aSNOiAgV0cgQWN0aW9uOiBDb25jbHVzaW9uIG9m?= =?utf-8?q?_Decoupled_Application_Data_Enroute_=28decade=29?=
X-BeenThere: decade@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 24 Sep 2012 06:55:19 -0000

SSBhbSBhIGJpdCBzdXJwcmlzZWQgYnkgdGhlIGFubm91bmNlbWVudC4gDQoNClJpY2hhcmQgQWxp
bWkgYW5kIEkgbWFkZSBhIGxvdCBvZiByZXZpc2lvbiBpbiAtMDYgYWNjb3JkaW5nIHRvIERhdmlk
IEhhcnJpbmd0b24ncyBjb21tZW50cyBhdCB0aGlzIEZlYi4gYW5kIGFmdGVyIHRoYXQgd2UgaGF2
ZSBtYWRlIGFub3RoZXIgMiB2ZXJzaW9ucywgLTA3IGFuZCAtMDgsIGJvdGggd2l0aCBxdWl0ZSBh
IGJpdCBwcm9ncmVzcyB0byB0aGUgcHJldmlvdXMgdmVyc2lvbi4gU28gSSB0aGluayB0aGlzIGRy
YWZ0IGlzIGluIGRlY2VudCBhY3Rpdml0eSwgYW5kIHRoZSBhdXRob3JzIGFyZSB0cnlpbmcgdGhl
aXIgYmVzdCB0byBpbXByb3ZlIHRoZSBkcmFmdC4gDQoNCkJlc3QgUmVnYXJkcw0KR3UgWWluZ2pp
ZQ0KDQoNCi0tLS0t6YKu5Lu25Y6f5Lu2LS0tLS0NCuWPkeS7tuS6ujogZGVjYWRlLWJvdW5jZXNA
aWV0Zi5vcmcgW21haWx0bzpkZWNhZGUtYm91bmNlc0BpZXRmLm9yZ10g5Luj6KGoIE1hcnRpbiBT
dGllbWVybGluZw0K5Y+R6YCB5pe26Ze0OiAyMDEy5bm0OeaciDIw5pelIOS5kOS5kDE3OjUzDQrm
lLbku7bkuro6IGRlY2FkZUBpZXRmLm9yZw0K5Li76aKYOiBSZTogW2RlY2FkZV0gV0cgQWN0aW9u
OiBDb25jbHVzaW9uIG9mIERlY291cGxlZCBBcHBsaWNhdGlvbiBEYXRhIEVucm91dGUgKGRlY2Fk
ZSkNCg0KRGVhciBhbGwsDQoNClRoZSBERUNBREUgd29ya2luZyBncm91cCBoYXMganVzdCBiZWVu
IGNsb3NlZCBieSB5b3VyIHJlc3BvbnNpYmxlIEFyZWEgDQpEaXJlY3Rvci4NCg0KVGhpcyBtYXkg
Y29tZSBhcyBhIHN1cnByaXNlIHRvIHNvbWUgaW4gdGhlIFdHLCBidXQgaXQgc2hvdWxkIG5vdCBi
ZSBhIA0Kc3VycHJpc2UgZm9yIHRoZSB3b3JraW5nIGRyYWZ0cyBhdXRob3JzLiBUaGUgY2hhaXJz
IGhhdmUgYmVlbiBub3RpZmllZCANCmluIGFkdmFuY2UgYWJvdXQgdGhpcyBhY3Rpb24uDQoNClRo
ZXJlIGhhcyBiZWVuIHNpZ25pZmljYW50IGZlZWRiYWNrIGZyb20gdGhlIGNvbW11bml0eSB0aGF0
IHF1ZXN0aW9uZWQgDQp0aGUgdGVjaG5pY2FsIHN0YXR1cyBvZiBERUNBREUgaW4gdGhlIHJlY2Vu
dCBwYXN0LiBUaGVzZSBjb25jZXJucyB3ZXJlIA0Kbm90IGJlZW4gdGFrZW4gdXAgYW5kIHdlcmUg
bm90IGFkZHJlc3NlZC4NCg0KVGhlIHdvcmtpbmcgZ3JvdXAgZGlkIG1hZGUgb25seSBzbWFsbCBw
cm9ncmVzcyBpbiB0aGUgbGFzdCBzaXggbW9udGhzLCANCndoaWNoIHdhcyB2aXNpYmxlIGluIHRo
ZSBsb3cgYW1vdW50IG9mIGVtYWlscyBvbiB0aGUgbGlzdCwgdGhvdWdoIHRoZXJlIA0KYXJlIGEg
bnVtYmVyIG9mIGlzc3VlcyB0aGF0IHNob3VsZCBoYXZlIGJlZW4gZGlzY3Vzc2VkLg0KDQpUaGUg
V0cgY2hhaXJzIHdlcmUgZXhwbGljaXRseSBub3RpZmllZCBpbiBtaWQgb2YgSnVuZSB0aGF0IHRo
ZXJlIGFyZSANCnNldmVyZSBpc3N1ZXMgYW5kIHRoZSBXRyBoYWQgdGltZSB0byBhZGRyZXNzIHRo
b3NlIGlzc3Vlcy4gSG93ZXZlciwgaXQgDQptdXN0IGhhdmUgYmVlbiBvYnZpb3VzIGV2ZW4gYmVm
b3JlIG1pZCBvZiBKdW5lIHRoYXQgdGhlcmUgYXJlIHNldmVyZSANCmlzc3VlcywgaS5lLiwgdGhl
cmUgaGFzIGJlZW4gc3VmZmljaWVudCB0aW1lIHRvIGZpeCBpdC4NCg0KRnVydGhlcm1vcmUsIHRo
ZSByZXF1aXJlbWVudHMgYW5kIGFyY2hpdGVjdHVyZSBkcmFmdCB3ZXJlIHN1Ym1pdHRlZCB0byAN
CnRoZSBJRVNHIGZvciBwdWJsaWNhdGlvbiBhbmQgYm90aCBkcmFmdHMgaGF2ZSBiZWVuIHJldHVy
bmVkIHRvIHRoZSBXRywgDQphcyBib3RoIGFyZSBub3QgcmVhZHkgdG8gYmUgcHVibGlzaGVkIGFz
IFJGQy4NCllvdSBjYW4gZmluZCB0aGUgQUQgcmV2aWV3IGluIHRoZSBkYXRhdHJhY2tlcjoNCi0g
aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1kZWNhZGUtcmVxcy9o
aXN0b3J5Lw0KLSBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWRl
Y2FkZS1hcmNoL2hpc3RvcnkvDQoNCkJvdGggZHJhZnRzIGRvIGxlYXZlIGFueSBudW1iZXIgb2Yg
a2V5IHF1ZXN0aW9ucyB1bmFuc3dlcmVkLCBpLmUuLCB0aGV5IA0KYXJlIGZhciBhd2F5IGZyb20g
YmVpbmcgdGVjaG5pY2FsbHkgdXNlZnVsIHRvIGJlIHRoZSBiYXNlIGZvciB0aGUgbmV4dCANCnN0
ZXBzIGluIHRoZSBwcm90b2NvbCBkZXZlbG9wbWVudC4NCg0KVG8gZ2l2ZSAyIGV4YW1wbGVzOg0K
MSkNCkl0IGlzIGNvbXBsZXRlbHkgdW5jbGVhciBob3cgdGhlIHJlc291cmNlcyBvbiBhIERFQ0FE
RSBzZXJ2ZXIgYXJlIA0Kc3VwcG9zZWQgdG8gYmUgbWFuYWdlZCBhbmQgaG93IHRoaXMgbWFuYWdl
bWVudCBpcyBtYXBwZWQgdG8gdGhlIHByb3RvY29sIA0Kc3BsaXQgb2YgU0RULCBEUlAsIGFuZCBv
dGhlciBtYW5hZ2VtZW50IHByb3RvY29scy4NClBhcnRzIG9mIGl0LCBzdWNoIGFzIHNldHRpbmcg
dGhlIHBlcm1pc3Npb25zIG9mIGRhdGEgb2JqZWN0cyBjbGVhcmx5IA0KYmVsb25ncyB0byB0aGUg
RFJQLCBhbmQgaXQgaXMgc29ydCBvZiBzdGF0ZWQgaW4gYSB2YWd1ZSB3YXkgaW4gdGhlIA0KYXJj
aGl0ZWN0dXJlLCBidXQgaXQgaXMgbm90IGRvY3VtZW50ZWQgaW4gYSBjb21wcmVoZW5zaXZlIHdh
eS4gT3RoZXIgDQpwYXJ0cywgc3VjaCBhcyB0aGUgYWNjb3VudGluZyBpcyBwcm9iYWJseSBub3Qg
cGFydCBvZiB0aGUgdGhlIERSUCBub3IgDQpTRFQsIGJ1dCB0aGVyZSBpcyBzdXBwb3NlZGx5IGFu
b3RoZXIgaW50ZXJmYWNlIHRoYXQgaXMgbmVlZGVkIGZvciB0aGlzLg0KDQoyKQ0KV2hhdCBpcyB0
aGUgbW9kZWwgaG93IGRhdGEgb2JqZWN0cyBhcmUgaGFuZGxlZCBvbiB0aGUgc2VydmVyIGluIHRo
ZSANCnNlbnNlIGFib3V0IHdobyBpcyBhbGxvd2VkIHRvIGRvIHdoYXQ/IFRoZSBkcmFmdHMgc29s
ZWx5IHRhbGsgYWJvdXQgDQp0b2tlbnMgdG8gYmUgdXNlZCB0byBkbyBhY2Nlc3MgY29udHJvbC4g
QnV0IHRoZXJlIG90aGVyIGFzcGVjdHMsIGZvciANCmluc3RhbmNlLCB3aG8gaXMgY29udHJvbGxp
bmcgd2hhdCBvbiBhIERFQ0FERSBzZXJ2ZXI6IFRoZSBERUNBREUgc2VydmVyIA0KY2FuIGJlIG9w
ZXJhdGVkIGJ5IGFuIElTUCwgYnV0IHRoZSBjb250ZW50IGlzIHByb3ZpZGVkIGJ5IGEgY29udGVu
dCANCnByb3ZpZGVyIGFuZCBpdCBpcyBhY2Nlc3MgYnkgYW4gdW5saW1pdGVkIHNldCBvZiBjbGll
bnRzIG9yIGxpbWl0ZWQgc2V0IA0Kb2YgY2xpZW50cy4gSG93IGlzIHRoZSBhY2Nlc3MgY29udHJv
bCBkaXZpZGVkIGJldHdlZW4gdGhvc2UgcGFydGllcz8NCg0KDQpUbyBjb25jbHVkZSB0aGlzIGVt
YWlsOg0KVGhlIERFQ0FERSBncm91cCBzdGFydGVkIGl0cyB3b3JrIGluIGVuZCBvZiBBcHJpbCAy
MDEwIGFuZCBpcyBub3cgDQp3b3JraW5nIGZvciBtb3JlIHRoYW4gMiB5ZWFycyBvbiB0aGUgbWls
ZXN0b25lcyBhbmQgZHJhZnRzLiBUaGUgdGltZSANCmlzbid0IGEgYmlnIGRlYWwsIGJ1dCBhZnRl
ciAyIHllYXJzIEkgd291bGQgaGF2ZSBleHBlY3RlZCB0aGF0IHRoZSANCmRvY3VtZW50cyBhcmUg
b24gYSBnb29kIHRlY2huaWNhbCBsZXZlbCB3aGVyZSB0aGUgV0cgY2FuIGJ1aWxkIG9uIHRvcCBv
Zi4NCg0KDQpTb21lIG9mIHlvdSBwcm9iYWJseSBhc2sgaG93IHRoZSByZW1haW5pbmcgZHJhZnRz
IGFyZSBoYW5kbGVkOg0KRmlyc3Qgb2YgYWxsLCB0aGV5IGFyZSBub3Qgd29ya2luZyBncm91cHMg
ZHJhZnRzIGFueW1vcmUuDQoNCkJ1dCB5b3UgbWF5IHJlc3VibWl0IHRob3NlIGRyYWZ0cyBhcyBp
bmRpdmlkdWFsIHN1Ym1pc3Npb25zLCBhZGRyZXNzIHRoZSANCnJldmlldyByZWNlaXZlZCBzbyBm
YXIsIGUuZy4sIERhdmUgQ3JvY2tlcidzLCBDYXJzdGVuIEJvcm1hbm4ncywgYW5kIHRoZSANCkFE
IHJldmlld3MuIEFzayBmb3IgZmVlZGJhY2sgYWdhaW4sIGlmIHlvdSBoYXZlIGFkZHJlc3NlZCB0
aGUgcmV2aWV3cyBpbiANCnlvdXIgdXBkYXRlZCBkcmFmdHMuDQoNCklmIHlvdSBiZWxpZXZlIHRo
YXQgdGhlIGRyYWZ0cyBhcmUgc29saWQgd29yaywgd2l0aCBhIGJhc2UgZm9yIGZ1cnRoZXIgDQpw
cm90b2NvbCBkZXZlbG9wbWVudCwgeW91IG1heSBjb25zaWRlciB0byBzdWJtaXQgdGhlIGRyYWZ0
cyB2aWEgdGhlIFJGQyANCmVkaXRvcidzIEluZGVwZW5kZW50IFN0cmVhbS4NCg0KDQpUaGUgZGVj
aXNpb25zIHRvIGNsb3NlIHRoZSBXRyBjYW4gYmUgb2YgY291cnNlIGFwcGVhbGVkIHZpYSB0aGUg
SUVURiANCmFwcGVhbCBwcm9jZXNzOg0KU2VlICdBcHBlYWxzIGFuZCBQUi1BY3Rpb25zJyB1bmRl
ciBodHRwOi8vd3d3LmlldGYub3JnL2llc2cvIGFuZCBSRkMgMjAyNi4NCg0KUmVnYXJkcywNCg0K
ICAgTWFydGluDQoNCi0tIA0KSUVURiBUcmFuc3BvcnQgQXJlYSBEaXJlY3Rvcg0KDQptYXJ0aW4u
c3RpZW1lcmxpbmdAbmVjbGFiLmV1DQoNCk5FQyBMYWJvcmF0b3JpZXMgRXVyb3BlIC0gTmV0d29y
ayBSZXNlYXJjaCBEaXZpc2lvbiBORUMgRXVyb3BlIExpbWl0ZWQNClJlZ2lzdGVyZWQgT2ZmaWNl
OiBORUMgSG91c2UsIDEgVmljdG9yaWEgUm9hZCwgTG9uZG9uIFczIDZCTA0KUmVnaXN0ZXJlZCBp
biBFbmdsYW5kIDI4Mw0KDQoNCk9uIDA5LzIwLzIwMTIgMDE6MDMgQU0sIElFU0cgU2VjcmV0YXJ5
IHdyb3RlOg0KPiBUaGUgRGVjb3VwbGVkIEFwcGxpY2F0aW9uIERhdGEgRW5yb3V0ZSAoZGVjYWRl
KSB3b3JraW5nIGdyb3VwIGluIHRoZQ0KPiBUcmFuc3BvcnQgQXJlYSBoYXMgY29uY2x1ZGVkLiBU
aGUgSUVTRyBjb250YWN0IHBlcnNvbnMgYXJlIE1hcnRpbg0KPiBTdGllbWVybGluZyBhbmQgV2Vz
bGV5IEVkZHkuDQo+DQo+IFRoZSBERUNBREUgd29ya2luZyBncm91cCB3aWxsIGJlIGNsb3NlZCBh
ZnRlciBoYXZpbmcgY29tcGxldGVkIHRoZSBiZWxvdw0KPiBsaXN0ZWQgUkZDcywgYnV0IGJlZm9y
ZSBmaW5pc2hpbmcgYWxsIG9mIGl0cyBjaGFydGVyZWQgZG9jdW1lbnRzLg0KPg0KPiBUaGUgREVD
QURFIFdHIGhhcyByZWFjaGVkIHRoZSBwb2ludCB3aGVyZSBpdCBpcyBldmlkZW50IHRoYXQgdGhl
DQo+IGNoYXJ0ZXJlZCB3b3JrIGNhbm5vdCBiZSBjb21wbGV0ZWQgYXQgYSB0ZWNobmljYWwgbGV2
ZWwgc3VpdGFibGUgZm9yIHRoZQ0KPiBjb21pbmcgc3RlcHMgb2YgdGhlIHByb3RvY29sIGRlZmlu
aXRpb24gYW5kIGFsc28gd2l0aGluIGFuIGFwcHJvcHJpYXRlDQo+IHRpbWUgZnJhbWUuDQo+DQo+
IFRoZSBsaXN0IG9mIHB1Ymxpc2hlZCBSRkNzOg0KPiAtIFJGQyA2MzkyDQo+IC0gUkZDIDY2NDYN
Cj4NCj4gVGhhbmsgeW91IHRvIGFsbCBjb250cmlidXRvcnMsIGRyYWZ0IGF1dGhvcnMsIGFuZCB0
aGUgY2hhaXJzLg0KPg0KPiBUaGUgREVDQURFIG1haWxpbmcgbGlzdCAoZGVjYWRlQGlldGYub3Jn
KSB3aWxsIHJlbWFpbiBvcGVuLg0KPg0KDQo=

From Martin.Stiemerling@neclab.eu  Mon Sep 24 02:36:35 2012
Return-Path: 
X-Original-To: decade@ietfa.amsl.com
Delivered-To: decade@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFF3321F8613 for ; Mon, 24 Sep 2012 02:36:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.424
X-Spam-Level: 
X-Spam-Status: No, score=-102.424 tagged_above=-999 required=5 tests=[AWL=0.175, 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 tUBq+akiCGox for ; Mon, 24 Sep 2012 02:36:34 -0700 (PDT)
Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 635A421F8611 for ; Mon, 24 Sep 2012 02:36:34 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id CBB69101F19; Mon, 24 Sep 2012 11:36:33 +0200 (CEST)
X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de)
Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AImkdTUlbX2M; Mon, 24 Sep 2012 11:36:33 +0200 (CEST)
Received: from ENCELADUS.office.hd (enceladus.office.hd [192.168.24.52]) by mailer1.neclab.eu (Postfix) with ESMTP id AE3BC101B25; Mon, 24 Sep 2012 11:36:23 +0200 (CEST)
Received: from [10.1.1.190] (10.1.1.190) by skoll.office.hd (192.168.125.11) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 24 Sep 2012 11:35:47 +0200
Message-ID: <50602997.6090201@neclab.eu>
Date: Mon, 24 Sep 2012 11:36:23 +0200
From: Martin Stiemerling 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0
MIME-Version: 1.0
To: "Y. Richard Yang" 
References: <20120919230313.17329.44102.idtracker@ietfa.amsl.com> <505AE794.8070304@neclab.eu> <505C7772.3070503@cs.yale.edu>
In-Reply-To: <505C7772.3070503@cs.yale.edu>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit
X-Originating-IP: [10.1.1.190]
Cc: decade@ietf.org
Subject: Re: [decade] WG Action: Conclusion of Decoupled Application Data Enroute (decade)
X-BeenThere: decade@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 24 Sep 2012 09:36:36 -0000

Hi Richard,

On 09/21/2012 04:19 PM, Y. Richard Yang wrote:
[...]
>
>> though there are a number of issues that should have been discussed.
>>
>> The WG chairs were explicitly notified in mid of June that there are
>> severe issues and the WG had time to address those issues. However, it
>> must have been obvious even before mid of June that there are severe
>> issues, i.e., there has been sufficient time to fix it.
>>
>> Furthermore, the requirements and architecture draft were submitted to
>> the IESG for publication and both drafts have been returned to the WG,
>> as both are not ready to be published as RFC.
>> You can find the AD review in the datatracker:
>> - https://datatracker.ietf.org/doc/draft-ietf-decade-reqs/history/
>> - https://datatracker.ietf.org/doc/draft-ietf-decade-arch/history/
>>
> Your preceding AD reviews are extensive. But I think the main criticism
> is writing/English/organization problems, not technical problems.

No, it isn't!
The criticisms are about technical issues in the sense that it is not 
clear what DECADE is exactly looking like in many parts and also many 
requirements are not correct or incomplete.
This is not about language or organizational issues, but it is about 
technical issues, though that there are organizational issues, e.g., 
listing new requirements in the architecture.

>
>> Both drafts do leave any number of key questions unanswered, i.e.,
>> they are far away from being technically useful to be the base for the
>> next steps in the protocol development.
>>
>> To give 2 examples:
>> 1)
>> It is completely unclear how the resources on a DECADE server are
>> supposed to be managed
> The basic design principles are stated in Sec. 4.4 and 4.5 of -arch:
> Explicit Control and Delegation, with sentences such as
>
> "Storage Providers will have the ability to explicitly manage the
>     entities allowed to utilize the resources at a DECADE-compatible
>     server.  This capability is needed for reasons such as capacity-
>     planning and legal considerations in certain deployment scenarios."

This is a high-level description that does not add anything to question 
on how it will be managed.

>
> "Content Providers are able to explicitly and independently manage their
> own shares of resources on a server."

Nice, but how? The 'how' is about how on the conceptual level and not 
yet on the protocol detail level.

>
> "The client can in turn share the
>     granted resources amongst its multiple applications.  The share of
>     resources granted by a server is called a User Delegation."

Sure, that seems to be a glimpse of a concept, but how does the DECADE 
server distinguish the applications? Or this is handled solely by the 
client?
Each of these paragraphs opens up many questions, which are never answered.

>
> "As a simple example, a DECADE-compatible server operated by an ISP
>     might be configured to grant each ISP Subscriber 1.5 Mbit/s of
>     bandwidth.  The ISP Subscriber might in turn divide this share of
>     resources amongst a video streaming application and file-sharing
>     application which are running concurrently."

Again nice, but how is this done on a conceptual level? What the 
measures in the requirements to ensure this?
For instance, how would expect that an ISP subscriber is identified?

>
> In -req:
> - Multiple Applications Sharing Resources
>
>
> "REQUIREMENT(S):  A client MUST be able to indicate to a DECADE-
>         compatible server about resource sharing policies among multiple
>         Target Applications being run/managed by the same client."

But how exactly does the client indicate this and where? How are the 
target applications announced to the server and distinguished during 
operations?
It is clear that the requirements do not specify all the bits and bytes 
of the protocol, but writing a high-level requirement is not sufficient 
at all.

>
> - Per-Client Resource Policy
>
> "REQUIREMENT(S):  A Provider MUST be able to specify resource policies
>         (bandwidth share, storage quota, and network connection quota) to
>         individual Consumers for reading from and writing data to its in-
>         network storage within a particular range of time."

This is underspecified: What is the policy for bandwidth share that is 
expected to be implemented by a protocol? Is it 10 % of my outgoing link 
capacity or is it a maximum throughput in x bits per second? What is 
expected here?

And does this related to multiple customers? How is such a customer 
identified?


>
>
> - Distributed Resource Sharing Specification
> REQUIREMENT(S):  A Provider MUST be able to indicate to its DECADE-
>         compatible server, without itself contacting the server, resource
>         control policies for a Consumer.  The DECADE-compatible server
>         MUST be able to authenticate the resource control policies.
>
>
> - Resource Set
> REQUIREMENT(S):  A DECADE-compatible server MUST allow specification
>         on the following resources: storage, bandwidth, and number of
>         connections, and MAY allow additional types of resources to be
>         specified.
>
>
> ...
>
>> and how this management is mapped to the protocol split of SDT, DRP,
>> and other management protocols.
>> Parts of it, such as setting the permissions of data objects clearly
>> belongs to the DRP, and it is sort of stated in a vague way in the
>> architecture, but it is not documented in a comprehensive way.

You say it correctly: 'vague way' and 'not documented in a comprehensive 
way.'
This is one of the main points that it is all to vague.

>
> The documents intentionally stayed vague as the understanding was that
> they are not solution-specifying protocol documents. Some authors have a
> lot more details on resource management, e.g., the recent SIGCOMM ICN'12
> paper (http://conferences.sigcomm.org/sigcomm/2012/paper/icn/p25.pdf)
> discusses using a hierarchical weighted sharing scheme for resource
> sharing and how to encode them in tokens. But the authors discussed the
> issues intensively, considered this to be too solution specific, and
> intentionally left them over to allow a larger design space to allow
> better participation.

The requirements and the architecture can get specific without detailing 
what the bits and bytes of the protocol are. This is what it is actually 
needed to design a proper protocol later on!


>
>> Other parts, such as the accounting is probably not part of the the
>> DRP nor SDT, but there is supposedly another interface that is needed
>> for this.
>>
>> 2)
>> What is the model how data objects are handled on the server in the
>> sense about who is allowed to do what?
>> The drafts solely talk about tokens to be used to do access control.
>> But there other aspects, for instance, who is controlling what on a
>> DECADE server: The DECADE server can be operated by an ISP, but the
>> content is provided by a content provider and it is access by an
>> unlimited set of clients or limited set of clients.
> Limited set of clients. See -req: "
>
> REQUIREMENT(S):  A Provider MUST be able to control which individual
>         clients are authorized to read/write which particular data
>         objects from/to its in-network storage.
>
>     RATIONALE:  A Target Application should able to conduct access
>         control on the granularity of individual clients, individual data
>         objects."

Those are really high-level requirements that do not saying too much 
about how the protocol should look like in the end. For instance, a main 
use case for this is bittorrent. There are no clients that can be easily 
identified and authorized. How is this handled?

One way would be that the management protocol, which is not specified in 
the requirements or architecture, is used to limited the IP addresses 
that are allowed to access such a DECADE server. This would be a 
requirement!

>
>
>
>> How is the access control divided between those parties?
> Mostly by clients, but with the exception that ISP has a say when:
> -req Sec. 9:
> 9.1.  Illegal Data Object
>
>     REQUIREMENT(S):  A DECADE-compatible server SHOULD provide an error
>         indicating that (1) data was rejected from being written, (2)
>         deleted, or (3) marked unavailable.
>
>     RATIONALE:  DECADE Storage Providers may require the ability to (1)
>         avoid storing, (2) delete, or (3) quarantine certain data that
>         has been identified as illegal (or otherwise prohibited).  It is
>         not specified how such data is identified, but applications
>         employing DECADE-compatible servers should not break if a Storage
>         Provider is obligated to enforce such policies.  Appropriate
>         error conditions should be indicated to applications.
>
>     EXCEPTION:  A DECADE-compatible server should be able to be
>         configured to suppress Illegal Data Object responses for security
>         reasons.

Those requirements do not answer my question about access control is 
divided between the parties.


   Martin

-- 
martin.stiemerling@neclab.eu

NEC Laboratories Europe - Network Research Division NEC Europe Limited
Registered Office: NEC House, 1 Victoria Road, London W3 6BL
Registered in England 283

From Martin.Stiemerling@neclab.eu  Mon Sep 24 05:10:09 2012
Return-Path: 
X-Original-To: decade@ietfa.amsl.com
Delivered-To: decade@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C66021F862A for ; Mon, 24 Sep 2012 05:10:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.428
X-Spam-Level: 
X-Spam-Status: No, score=-102.428 tagged_above=-999 required=5 tests=[AWL=0.171, 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 ZP7NQDDhgWjo for ; Mon, 24 Sep 2012 05:10:08 -0700 (PDT)
Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id CD14C21F8628 for ; Mon, 24 Sep 2012 05:10:07 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 41A18101F19; Mon, 24 Sep 2012 14:10:06 +0200 (CEST)
X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de)
Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rBZcIdOSIkrf; Mon, 24 Sep 2012 14:10:06 +0200 (CEST)
Received: from ENCELADUS.office.hd (enceladus.office.hd [192.168.24.52]) by mailer1.neclab.eu (Postfix) with ESMTP id 26A3B101F18; Mon, 24 Sep 2012 14:09:51 +0200 (CEST)
Received: from [10.1.1.190] (10.1.1.190) by skoll.office.hd (192.168.125.11) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 24 Sep 2012 14:09:16 +0200
Message-ID: <50604D8F.7040906@neclab.eu>
Date: Mon, 24 Sep 2012 14:09:51 +0200
From: Martin Stiemerling 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0
MIME-Version: 1.0
To: "Rahman, Akbar" 
References: <20120919230313.17329.44102.idtracker@ietfa.amsl.com><505AE794.8070304@neclab.eu> <8D38716F0C1A444BA0CD7E96454366C23A4DDEF6@szxeml545-mbx.china.huawei.com>  <505C74F3.7060002@neclab.eu> 
In-Reply-To: 
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 8bit
X-Originating-IP: [10.1.1.190]
Cc: decade@ietf.org, Konstantinos Pentikousis 
Subject: Re: [decade] WG Action: Conclusion of Decoupled Application Data Enroute (decade)
X-BeenThere: decade@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 24 Sep 2012 12:10:09 -0000

On 09/21/2012 04:23 PM, Rahman, Akbar wrote:
> Hi Martin,
>
>
> Thanks for the feedback.  I will talk to the other authors and see if they agree to use the Independent Stream submission.
>
>
> On your point:
>
> 	-- snip ---
> 	You can see also this, as the draft talks about the DECADE system which
> 	is not equal to the protocols.
>
> 	-- snip ---
>
> Please note that the nomenclature of "DECADE system" was specifically agreed in the WG to address the comments from the previous AD Dave Harrington.  Also the WG charter specifically prohibited us from selecting and specifying the details of the protocols.  Perhaps this is the cause of some of the confusion for you.

The term "DECADE system" is not necessarily causing confusion to me, it 
is the content of the requirements and the architecture draft. The term 
DECADE system is summarizing nicely what the documents try to achieve, 
although they should discuss requirements and an architecture for DECADE 
protocols.

I would appreciate a point to the conclusion that Dave's comments, or 
anything else. lead to "DECADE system".


Thanks,

   Martin

>
>
> Sincerely,
>
>
> Akbar
>
>
> -----Original Message-----
> From: Martin Stiemerling [mailto:martin.stiemerling@neclab.eu]
> Sent: Friday, September 21, 2012 10:09 AM
> To: Rahman, Akbar
> Cc: Konstantinos Pentikousis; decade@ietf.org
> Subject: Re: [decade] WG Action: Conclusion of Decoupled Application Data Enroute (decade)
>
> Hi Akbar,
>
> On 09/21/2012 03:21 PM, Rahman, Akbar wrote:
>> To All,
>>
>>
>>
>> I also want to make some points for the record:
>>
>> - As an author, I do NOT feel that I was part of any extensive discussions regarding potential shutting down of the DECADE WG and especially stopping the current active WG drafts (especially the Architecture I-D where I was an author).
>
> Talk to your chairs and consider that the requirements went from
> publication requested (i.e., on the way to the IESG) back to the WG
> (i.e., not on the way to the IESG).
>
> The same is true for the architecture draft.
>
>>
>> - We did have one lunch meeting in Vancouver with Martin and the chairs but that was publicly announced and open to all in the WG.  At that meeting, I recall Martin asking the attendees if there was industry interest for the DECADE work.  From what I recall, everyone there did express various levels of interest and support.  I didn’t hear anyone say that DECADE was a "wasted effort". So, frankly I was surprised and disappointed to see the WG shut down so suddenly.  If there really is no community support to continue with the activity, then so be it.  But you cannot conclude that there is not interest without first having an open discussion.
>
> To be honestly, but expressing interest and transforming interest to
> technical progress are two very distinct actions.
>
> I have seen a lot of 'expressing interest', but the technical progress
> was and is just not there.
>
> I also told at the lunch meeting in Vancouver that I want to see actions
> on the two main drafts in the WG, i.e., the requirements and the
> architecture. Yes there has been action, but the technical quality of
> the drafts is far from being useful for any further protocol development.
> See also my email with 2 examples on issues not addressed in neither the
> requirements nor the architecture draft.
>
>>
>> - In terms of the document quality.  The first draft of the Architecture I-D was in March 2011.  Since then we have gotten extensive comments from various excellent reviewers.  But as is often the case when you have multiple reviewers, you sometimes get conflicting directions.  Some reviewers wanted a high level abstract architecture that avoided all "implementation" details.  Other reviewers wanted a more detailed approach that got more into the details of the protocols and inner workings of the nodes.  I personally tried in a good faith effort to address all the comments and to try to strike a balance in addressing the philosophies of the different reviewers.
>
> The architecture drafts clearly fails to show the architecture of the
> DECADE protocols. See my AD review.
>
> You have indeed received extensive reviews, but it is up to date not
> clear if and how they were addressed.
>
> You can see also this, as the draft talks about the DECADE system which
> is not equal to the protocols.
>
>>
>> - I agree with Kostas that many documents in other WGs go through similar issues but at the end still managed to produce good work.
>
> Yes and no. There are examples in both directions, so it doesn't help
> here in this particular case.
>
>>
>> - To conclude, I devoted in good faith a fair amount of my energy to participate in advancing the topics in the WG since the first session back in Anaheim.  I defer to the higher powers to make the decision on closing the DECADE WG or not.  However, I clearly want to state that I think it was unfortunate to also suddenly terminate the DECADE Architecture I-D which was being extensively revised whenever we got reviewer comments.  I understand if people are saying that more work has to be done to get it to publication state.  But that does not warrant, in my opinion, to just shut down the work.  Honestly, if you use that criteria there would be many WG documents in other groups that should also be abruptly shut down.
>
> I wonder why there is so much care about other groups? This is about
> DECADE not any other arbitrary group somewhere else.
>
> With respect to the energy:
> If people still believe in DECADE, take the documents, address the
> reviews, get reviews and go for the Independent Stream submission with
> the RFC editor.
>
> Regards,
>
>     Martin
>
>>
>>
>> Respectfully,
>>
>>
>> Akbar
>>
>> -----Original Message-----
>> From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.org] On Behalf Of Konstantinos Pentikousis
>> Sent: Friday, September 21, 2012 8:15 AM
>> To: Martin Stiemerling; decade@ietf.org
>> Subject: Re: [decade] WG Action: Conclusion of Decoupled Application Data Enroute (decade)
>>
>> Dear Martin, All,
>>
>>     |The DECADE working group has just been closed by your responsible Area
>>     |Director.
>>     |
>>     |This may come as a surprise to some in the WG
>>
>> Indeed, it has been a surprise.
>>
>>     | but it should not be a surprise for the working drafts authors
>>
>> That's fine, but I think some sort of announcement (and even better a discussion) should have been circulated prior to the IESG announcement. I'm not interested into _who_ should have done this. It's too late and, in the end, irrelevant at this stage. But there's an order of magnitude more people on this mailing list than in the author line of all drafts together. I would consider this a breakdown in communication between the inner- and outer-circle. This was far from what, in general, I would call a "graceful teardown".
>>
>>     | Both drafts do leave any number of key questions unanswered
>>
>> I do agree with most of your technical comments. I sent reviews on both documents earlier. That said, imo, this action was a bit abrupt. I do recall a few groups that were much later in their timelines than decade is now, and they still managed to do decent work after a (prolonged) slow start.
>>
>> In any case, I respect your decision, but I do not second it.
>>
>> Best Regards,
>>
>> Kostas
>>
>>
>

-- 
martin.stiemerling@neclab.eu

NEC Laboratories Europe - Network Research Division NEC Europe Limited
Registered Office: NEC House, 1 Victoria Road, London W3 6BL
Registered in England 283

From Martin.Stiemerling@neclab.eu  Mon Sep 24 05:15:01 2012
Return-Path: 
X-Original-To: decade@ietfa.amsl.com
Delivered-To: decade@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08C1021F861B for ; Mon, 24 Sep 2012 05:15:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.432
X-Spam-Level: 
X-Spam-Status: No, score=-102.432 tagged_above=-999 required=5 tests=[AWL=0.167, 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 wxp2G6zxJ6xA for ; Mon, 24 Sep 2012 05:14:58 -0700 (PDT)
Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 7BBC421F860E for ; Mon, 24 Sep 2012 05:14:57 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id E3B86101F19; Mon, 24 Sep 2012 14:14:56 +0200 (CEST)
X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de)
Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZSf1fM-fEsTm; Mon, 24 Sep 2012 14:14:56 +0200 (CEST)
Received: from ENCELADUS.office.hd (enceladus.office.hd [192.168.24.52]) by mailer1.neclab.eu (Postfix) with ESMTP id C9699101F18; Mon, 24 Sep 2012 14:14:41 +0200 (CEST)
Received: from [10.1.1.190] (10.1.1.190) by skoll.office.hd (192.168.125.11) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 24 Sep 2012 14:14:06 +0200
Message-ID: <50604EB1.8040404@neclab.eu>
Date: Mon, 24 Sep 2012 14:14:41 +0200
From: Martin Stiemerling 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0
MIME-Version: 1.0
To: "Rahman, Akbar" 
References: <20120919230313.17329.44102.idtracker@ietfa.amsl.com><505AE794.8070304@neclab.eu> <8D38716F0C1A444BA0CD7E96454366C23A4DDEF6@szxeml545-mbx.china.huawei.com>  <505C74F3.7060002@neclab.eu> 
In-Reply-To: 
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 8bit
X-Originating-IP: [10.1.1.190]
Cc: decade@ietf.org, Konstantinos Pentikousis 
Subject: Re: [decade] WG Action: Conclusion of Decoupled Application Data Enroute (decade)
X-BeenThere: decade@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 24 Sep 2012 12:15:01 -0000

Akbar,

On 09/22/2012 01:52 AM, Rahman, Akbar wrote:
> Hi Martin,
>
>
> Regarding your point below.  Unfortunately, I think that you are factually wrong.  Otherwise prove me wrong by showing me where on the I-D State Diagram http://datatracker.ietf.org/images/state_diagram.png it specifies that sending an I-D back to the authors with comments equals shutting down the WG and stopping a WG approved I-D.

You are referring the state diagram for Internet drafts and this state 
diagram does have no relationship to what happens with a WG.

However, for termination of WGs, please refer to RFC 2418, Section 4, 
copied here for your convenience:

4. Working Group Termination


    Working groups are typically chartered to accomplish a specific task
    or tasks.  After the tasks are complete, the group will be disbanded.
    However, if a WG produces a Proposed or Draft Standard, the WG will
    frequently become dormant rather than disband (i.e., the WG will no
    longer conduct formal activities, but the mailing list will remain
    available to review the work as it moves to Draft Standard and
    Standard status.)

    If, at some point, it becomes evident that a working group is unable
    to complete the work outlined in the charter, or if the assumptions
    which that work was based have been modified in discussion or by
    experience, the Area Director, in consultation with the working group
    can either:

    1. Recharter to refocus its tasks,
    2. Choose new Chair(s), or
    3. Disband.

    If the working group disagrees with the Area Director's choice, it
    may appeal to the IESG (see section 3.4).


and cite the email announcing the termination of the DECADE WG
"The DECADE WG has reached the point where it is evident that the
chartered work cannot be completed at a technical level suitable for the
coming steps of the protocol definition and also within an appropriate
time frame."

The drafts do not show that the WG is completing its technical work.

   Martin

>
>
>
> -- snip --
>
>> - As an author, I do NOT feel that I was part of any extensive discussions regarding potential shutting down of the DECADE WG and especially stopping the current active WG drafts (especially the Architecture I-D where I was an author).
>
> Talk to your chairs and consider that the requirements went from
> publication requested (i.e., on the way to the IESG) back to the WG
> (i.e., not on the way to the IESG).
>
> The same is true for the architecture draft.
>
>
> -- snip --
>
>
> BR
>
> /Akbar
>
>
> -----Original Message-----
> From: Martin Stiemerling [mailto:martin.stiemerling@neclab.eu]
> Sent: Friday, September 21, 2012 10:09 AM
> To: Rahman, Akbar
> Cc: Konstantinos Pentikousis; decade@ietf.org
> Subject: Re: [decade] WG Action: Conclusion of Decoupled Application Data Enroute (decade)
>
> Hi Akbar,
>
> On 09/21/2012 03:21 PM, Rahman, Akbar wrote:
>> To All,
>>
>>
>>
>> I also want to make some points for the record:
>>
>> - As an author, I do NOT feel that I was part of any extensive discussions regarding potential shutting down of the DECADE WG and especially stopping the current active WG drafts (especially the Architecture I-D where I was an author).
>
> Talk to your chairs and consider that the requirements went from
> publication requested (i.e., on the way to the IESG) back to the WG
> (i.e., not on the way to the IESG).
>
> The same is true for the architecture draft.
>
>>
>> - We did have one lunch meeting in Vancouver with Martin and the chairs but that was publicly announced and open to all in the WG.  At that meeting, I recall Martin asking the attendees if there was industry interest for the DECADE work.  From what I recall, everyone there did express various levels of interest and support.  I didn’t hear anyone say that DECADE was a "wasted effort". So, frankly I was surprised and disappointed to see the WG shut down so suddenly.  If there really is no community support to continue with the activity, then so be it.  But you cannot conclude that there is not interest without first having an open discussion.
>
> To be honestly, but expressing interest and transforming interest to
> technical progress are two very distinct actions.
>
> I have seen a lot of 'expressing interest', but the technical progress
> was and is just not there.
>
> I also told at the lunch meeting in Vancouver that I want to see actions
> on the two main drafts in the WG, i.e., the requirements and the
> architecture. Yes there has been action, but the technical quality of
> the drafts is far from being useful for any further protocol development.
> See also my email with 2 examples on issues not addressed in neither the
> requirements nor the architecture draft.
>
>>
>> - In terms of the document quality.  The first draft of the Architecture I-D was in March 2011.  Since then we have gotten extensive comments from various excellent reviewers.  But as is often the case when you have multiple reviewers, you sometimes get conflicting directions.  Some reviewers wanted a high level abstract architecture that avoided all "implementation" details.  Other reviewers wanted a more detailed approach that got more into the details of the protocols and inner workings of the nodes.  I personally tried in a good faith effort to address all the comments and to try to strike a balance in addressing the philosophies of the different reviewers.
>
> The architecture drafts clearly fails to show the architecture of the
> DECADE protocols. See my AD review.
>
> You have indeed received extensive reviews, but it is up to date not
> clear if and how they were addressed.
>
> You can see also this, as the draft talks about the DECADE system which
> is not equal to the protocols.
>
>>
>> - I agree with Kostas that many documents in other WGs go through similar issues but at the end still managed to produce good work.
>
> Yes and no. There are examples in both directions, so it doesn't help
> here in this particular case.
>
>>
>> - To conclude, I devoted in good faith a fair amount of my energy to participate in advancing the topics in the WG since the first session back in Anaheim.  I defer to the higher powers to make the decision on closing the DECADE WG or not.  However, I clearly want to state that I think it was unfortunate to also suddenly terminate the DECADE Architecture I-D which was being extensively revised whenever we got reviewer comments.  I understand if people are saying that more work has to be done to get it to publication state.  But that does not warrant, in my opinion, to just shut down the work.  Honestly, if you use that criteria there would be many WG documents in other groups that should also be abruptly shut down.
>
> I wonder why there is so much care about other groups? This is about
> DECADE not any other arbitrary group somewhere else.
>
> With respect to the energy:
> If people still believe in DECADE, take the documents, address the
> reviews, get reviews and go for the Independent Stream submission with
> the RFC editor.
>
> Regards,
>
>     Martin
>
>>
>>
>> Respectfully,
>>
>>
>> Akbar
>>
>> -----Original Message-----
>> From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.org] On Behalf Of Konstantinos Pentikousis
>> Sent: Friday, September 21, 2012 8:15 AM
>> To: Martin Stiemerling; decade@ietf.org
>> Subject: Re: [decade] WG Action: Conclusion of Decoupled Application Data Enroute (decade)
>>
>> Dear Martin, All,
>>
>>     |The DECADE working group has just been closed by your responsible Area
>>     |Director.
>>     |
>>     |This may come as a surprise to some in the WG
>>
>> Indeed, it has been a surprise.
>>
>>     | but it should not be a surprise for the working drafts authors
>>
>> That's fine, but I think some sort of announcement (and even better a discussion) should have been circulated prior to the IESG announcement. I'm not interested into _who_ should have done this. It's too late and, in the end, irrelevant at this stage. But there's an order of magnitude more people on this mailing list than in the author line of all drafts together. I would consider this a breakdown in communication between the inner- and outer-circle. This was far from what, in general, I would call a "graceful teardown".
>>
>>     | Both drafts do leave any number of key questions unanswered
>>
>> I do agree with most of your technical comments. I sent reviews on both documents earlier. That said, imo, this action was a bit abrupt. I do recall a few groups that were much later in their timelines than decade is now, and they still managed to do decent work after a (prolonged) slow start.
>>
>> In any case, I respect your decision, but I do not second it.
>>
>> Best Regards,
>>
>> Kostas
>>
>>
>

-- 
martin.stiemerling@neclab.eu

NEC Laboratories Europe - Network Research Division NEC Europe Limited
Registered Office: NEC House, 1 Victoria Road, London W3 6BL
Registered in England 283

From Martin.Stiemerling@neclab.eu  Mon Sep 24 05:22:13 2012
Return-Path: 
X-Original-To: decade@ietfa.amsl.com
Delivered-To: decade@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6523A21F8661 for ; Mon, 24 Sep 2012 05:22:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.21
X-Spam-Level: 
X-Spam-Status: No, score=-102.21 tagged_above=-999 required=5 tests=[AWL=-0.063, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, SARE_SUB_ENC_UTF8=0.152, 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 oRmfjS7UDdsk for ; Mon, 24 Sep 2012 05:22:12 -0700 (PDT)
Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 2F1F621F8634 for ; Mon, 24 Sep 2012 05:22:12 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 81C13101F1B; Mon, 24 Sep 2012 14:22:11 +0200 (CEST)
X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de)
Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dHMaRd0arvwY; Mon, 24 Sep 2012 14:22:11 +0200 (CEST)
Received: from ENCELADUS.office.hd (enceladus.office.hd [192.168.24.52]) by mailer1.neclab.eu (Postfix) with ESMTP id 67C57101F19; Mon, 24 Sep 2012 14:22:01 +0200 (CEST)
Received: from [10.1.1.190] (10.1.1.190) by skoll.office.hd (192.168.125.11) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 24 Sep 2012 14:21:26 +0200
Message-ID: <50605069.7030601@neclab.eu>
Date: Mon, 24 Sep 2012 14:22:01 +0200
From: Martin Stiemerling 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0
MIME-Version: 1.0
To: "Guyingjie (Yingjie)" , "decade@ietf.org" 
References: <20120919230313.17329.44102.idtracker@ietfa.amsl.com> <505AE794.8070304@neclab.eu> 
In-Reply-To: 
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 8bit
X-Originating-IP: [10.1.1.190]
Subject: Re: [decade] =?utf-8?b?562U5aSNOiAgV0cgQWN0aW9uOiBDb25jbHVzaW9uIG9m?= =?utf-8?q?_Decoupled_Application_Data_Enroute_=28decade=29?=
X-BeenThere: decade@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 24 Sep 2012 12:22:13 -0000

Hi Yingjie, all,

The quantity of changes does not matter, it is the quality of the 
changes that matter.

Actually, one part of my conclusion that there is lack of technical 
progress is exactly the amount of energy spent to address the reviewer's 
comments and the outcome as we have it right now.


So, if the majority in this group believes that you have good content, 
why are you not progressing the drafts by addressing the reviewer's 
comments (also by replying to the reviewers)?

   Martin


On 09/24/2012 08:54 AM, Guyingjie (Yingjie) wrote:
> I am a bit surprised by the announcement.
>
> Richard Alimi and I made a lot of revision in -06 according to David Harrington's comments at this Feb. and after that we have made another 2 versions, -07 and -08, both with quite a bit progress to the previous version. So I think this draft is in decent activity, and the authors are trying their best to improve the draft.
>
> Best Regards
> Gu Yingjie
>
>
> -----邮件原件-----
> 发件人: decade-bounces@ietf.org [mailto:decade-bounces@ietf.org] 代表 Martin Stiemerling
> 发送时间: 2012年9月20日 乐乐17:53
> 收件人: decade@ietf.org
> 主题: Re: [decade] WG Action: Conclusion of Decoupled Application Data Enroute (decade)
>
> Dear all,
>
> The DECADE working group has just been closed by your responsible Area
> Director.
>
> This may come as a surprise to some in the WG, but it should not be a
> surprise for the working drafts authors. The chairs have been notified
> in advance about this action.
>
> There has been significant feedback from the community that questioned
> the technical status of DECADE in the recent past. These concerns were
> not been taken up and were not addressed.
>
> The working group did made only small progress in the last six months,
> which was visible in the low amount of emails on the list, though there
> are a number of issues that should have been discussed.
>
> The WG chairs were explicitly notified in mid of June that there are
> severe issues and the WG had time to address those issues. However, it
> must have been obvious even before mid of June that there are severe
> issues, i.e., there has been sufficient time to fix it.
>
> Furthermore, the requirements and architecture draft were submitted to
> the IESG for publication and both drafts have been returned to the WG,
> as both are not ready to be published as RFC.
> You can find the AD review in the datatracker:
> - https://datatracker.ietf.org/doc/draft-ietf-decade-reqs/history/
> - https://datatracker.ietf.org/doc/draft-ietf-decade-arch/history/
>
> Both drafts do leave any number of key questions unanswered, i.e., they
> are far away from being technically useful to be the base for the next
> steps in the protocol development.
>
> To give 2 examples:
> 1)
> It is completely unclear how the resources on a DECADE server are
> supposed to be managed and how this management is mapped to the protocol
> split of SDT, DRP, and other management protocols.
> Parts of it, such as setting the permissions of data objects clearly
> belongs to the DRP, and it is sort of stated in a vague way in the
> architecture, but it is not documented in a comprehensive way. Other
> parts, such as the accounting is probably not part of the the DRP nor
> SDT, but there is supposedly another interface that is needed for this.
>
> 2)
> What is the model how data objects are handled on the server in the
> sense about who is allowed to do what? The drafts solely talk about
> tokens to be used to do access control. But there other aspects, for
> instance, who is controlling what on a DECADE server: The DECADE server
> can be operated by an ISP, but the content is provided by a content
> provider and it is access by an unlimited set of clients or limited set
> of clients. How is the access control divided between those parties?
>
>
> To conclude this email:
> The DECADE group started its work in end of April 2010 and is now
> working for more than 2 years on the milestones and drafts. The time
> isn't a big deal, but after 2 years I would have expected that the
> documents are on a good technical level where the WG can build on top of.
>
>
> Some of you probably ask how the remaining drafts are handled:
> First of all, they are not working groups drafts anymore.
>
> But you may resubmit those drafts as individual submissions, address the
> review received so far, e.g., Dave Crocker's, Carsten Bormann's, and the
> AD reviews. Ask for feedback again, if you have addressed the reviews in
> your updated drafts.
>
> If you believe that the drafts are solid work, with a base for further
> protocol development, you may consider to submit the drafts via the RFC
> editor's Independent Stream.
>
>
> The decisions to close the WG can be of course appealed via the IETF
> appeal process:
> See 'Appeals and PR-Actions' under http://www.ietf.org/iesg/ and RFC 2026.
>
> Regards,
>
>     Martin
>

-- 
martin.stiemerling@neclab.eu

NEC Laboratories Europe - Network Research Division NEC Europe Limited
Registered Office: NEC House, 1 Victoria Road, London W3 6BL
Registered in England 283

From Martin.Stiemerling@neclab.eu  Mon Sep 24 05:26:07 2012
Return-Path: 
X-Original-To: decade@ietfa.amsl.com
Delivered-To: decade@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C91121F852E; Mon, 24 Sep 2012 05:26:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.434
X-Spam-Level: 
X-Spam-Status: No, score=-102.434 tagged_above=-999 required=5 tests=[AWL=0.165, 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 bZitC73l53pt; Mon, 24 Sep 2012 05:26:06 -0700 (PDT)
Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 1066F21F84D7; Mon, 24 Sep 2012 05:26:06 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 7267C101F20; Mon, 24 Sep 2012 14:26:05 +0200 (CEST)
X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de)
Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GRCnb9-00kGc; Mon, 24 Sep 2012 14:26:05 +0200 (CEST)
Received: from ENCELADUS.office.hd (enceladus.office.hd [192.168.24.52]) by mailer1.neclab.eu (Postfix) with ESMTP id 572DB101F1D; Mon, 24 Sep 2012 14:25:50 +0200 (CEST)
Received: from [10.1.1.190] (10.1.1.190) by skoll.office.hd (192.168.125.11) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 24 Sep 2012 14:24:54 +0200
Message-ID: <50605139.4070907@neclab.eu>
Date: Mon, 24 Sep 2012 14:25:29 +0200
From: Martin Stiemerling 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0
MIME-Version: 1.0
To: Songhaibin 
References: <50531AB3.6090601@neclab.eu>  <50583257.2080404@neclab.eu> 
In-Reply-To: 
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit
X-Originating-IP: [10.1.1.190]
Cc: "decade@ietf.org" , "ietf@ietf.org" 
Subject: Re: [decade] DECADE WG to be closed
X-BeenThere: decade@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 24 Sep 2012 12:26:07 -0000

Dear Haibin,

It is really strange that you copy private emails between you, Richard, 
and me to the general public. Despite the fact that I do not mind about 
this, it is really odd.

I won't reply to this email.

   Martin

On 09/22/2012 08:52 AM, Songhaibin wrote:
> Dear Martin,
>
>> -----Original Message-----
>> From: Martin Stiemerling [mailto:martin.stiemerling@neclab.eu]
>> Sent: Tuesday, September 18, 2012 4:36 PM
>> To: Songhaibin
>> Cc: Richard Woundy
>> Subject: Re: DECADE WG to be closed
>>
>> Dear Haibin,
>>
>> On 09/17/2012 11:39 AM, Songhaibin wrote:
>>> Dear Martin,
>>>
>>> Hope everything goes well with you and thank you very much for your efforts
>> to reviewing the drafts in detail and giving guidance.
>>>
>>> As I agree with most of your comments to the DECADE requirements draft, but
>> I have to say IMO the architecture document is not that bad. This document gives
>> a clear description of the DECADE server/client components and
>> implementation/design principals which will be reflected in the protocols, IMO
>> this is what an architecture document should do.
>>>
>>> I do not agree there is lack of technical substances to design a base protocol
>> which can satisfy the transport and resource control requirements for content
>> distribution applications. Some detailed design choices are still not very clear, and
>> need efforts for them.
>>>
>>> And recently, the energy is growing, we recently received a lot of list discussion
>> including comments from Kostas about the requirements and architecture and
>> also a new individual draft for the service discovery was submitted.
>>
>> The energy has indeed grown in the WG since before the summer. But, I
>> indicated in my email from mid of June that I have doubts on the
>> technical quality of the DECADE drafts. These doubts have turned into
>> certainty, i.e., see the my AD reviews of the requirements and the
>> architecture.
>>
>> The technical quality of the drafts would be ok, if the WG would be at
>> the beginning of the process of discussing and writing those drafts, but
>> it is not acceptable at the end when the drafts are intended to become RFCs:
>> The technical base is just to weak to continue from, even after spending
>> time and effort of the WG participants for more than 2 years.
>
> The requirements document was accepted on Oct. 18, 2010, and the architecture draft was accepted on March 7, 2011.
>
>>
>> Another important data point, as mentioned earlier:
>> There has been public feedback from IETF community members, such as Dave
>> Crocker and Carsten Bormann, which questioned the technical base of
>> DECADE as a whole. This happened at the end of the 2011 and in the first
>> quarter of 2012.
>
>> The was no and still has not been an adequate response from the DECADE
>> WG to these reviews. For instance, the requirements did get a lot of
>> feedback from Dave Crocker, but this feedback was never addressed in an
>> email. I also have been unable to sort out what parts of the feedback
>> has been addressed in the updated draft and how, and what parts have not
>> been addressed.
>
> I believe all those comments were addressed in the current draft, as I joined the discussion with the authors to address the comments. Their efforts should be respected. The authors and I would like Dave and Carsten to check the draft with their comments, if they are interested. While I admit answering in the mailing list is a main method to resolve comments, but it is not the only method.
>
>>
>> I have also received much stronger feedback about the DECADE WG in
>> private emails to me. Again from long standing IETF community members
>> that send me feedback arguing that DECADE is not having a technical base
>> to build on top of.
>
> OK. But general rule for IETF is rough consensus, not private emails. Why not discuss their questions in the list?
>
>>
>> You have asked in your other email to give more time to the WG until the
>> next IETF meeting in November. This would be one possible way forward,
>> but I do know about the past 6 months after the IETF meeting in Paris.
>> Not a lot has happened during this period in order to improve the WG
>> drafts, in the sense that there is a solid technical base where DECADE
>> could continue to work from.
>
> I can answer If your question about the technical base can be more specific.
>
>>
>> Even if you and the whole WG would start to work full-time on the
>> drafts, it still would take longer than to the next IETF meeting to move
>> the requirements and architecture forward. My gut guessing is that it
>> will take at least until March 2013.
>
>> To give an example:
>> It is completely unclear how the resources on a DECADE server are
>> supposed to be managed and how this management is mapped to the protocol
>> split of SDT, DRP, and other management protocols.
>> Parts of it, such as setting the permissions of data objects clearly
>> belongs to the DRP, and it is sort of stated in a vague way in the
>> architecture, but it is not documented in a comprehensive way. Other
>> parts, such as the accounting is probably not part of the the DRP nor
>> SDT, but there is supposedly another interface that is needed for this.
>>
>> Has this been discussed at any point in the WG?
>
> I just read the email that Richard answered these questions with text from the current drafts. And I agree with his answers.
>
> While I respect that AD can make the decision of closing a WG, but I see a dozen of emails expressed their disappointment.
>
> BR,
> -Haibin
>
>
>> Given the above points and my summaries out of the last email and the
>> one of 6/12, the DECADE WG is going to be closed by today.
>>
>> The DECADE WG mailing list will remain open until the end of the year,
>> to let the people a chance to discuss how to go forward with the drafts.
>>
>> As suggest in my earlier email:
>> The participants are free to overhaul the drafts and to submit them as
>> individual submissions to the RFC Editor's Independent Stream.
>>
>>
>> The decisions to close the WG can be of course appealed via the IETF
>> appeal process:
>> See 'Appeals and PR-Actions' under http://www.ietf.org/iesg/ and RFC 2026.
>>
>>     Martin
>>
>>>
>>> BR,
>>> -Haibin
>>>
>>>
>>>> -----Original Message-----
>>>> From: Martin Stiemerling [mailto:martin.stiemerling@neclab.eu]
>>>> Sent: Friday, September 14, 2012 7:53 PM
>>>> To: Songhaibin; Richard Woundy
>>>> Subject: DECADE WG to be closed
>>>>
>>>> Dear Rich and Haibin,
>>>>
>>>> I have finally done my AD review for the DECADE architecture draft after
>>>> finishing the DECADE requirements draft.
>>>>
>>>> The first feedback for the DECADE architecture draft has been provided
>>>> in the datatracker and sent to the authors and you by email.
>>>>
>>>> Both drafts are in an extremely bad shape, i.e., they would require a
>>>> major overhaul and have been sent back to the working group due to lack
>>>> of technical quality.
>>>>
>>>> I have already expressed my concerns about the energy and the lack of
>>>> technical confidence in the group in my summary email of 6/12. The
>>>> requirements and architecture drafts got advanced towards the IESG
>>>> afterwards. The push for energy was good.
>>>>
>>>> However, after reviewing the two key drafts, requirements and
>>>> architecture, and receiving feedback from IETF community members, I have
>>>> come to the conclusion that the DECADE working group lacks a sound
>>>> technical ground.
>>>>
>>>> The DECADE group started its work in end of April 2010 and is now
>>>> working for more than 2 years on the milestones/drafts. The time isn't a
>>>> big deal, but after 2 years I would have expected that the documents are
>>>> on a good technical level where the WG can build on top of.
>>>>
>>>> The issues for the potential future protocol works is that if the basics
>>>> are not well understood and documented, how can the protocols be
>>>> designed in a comprehensive and technical sound way?
>>>> I cannot see this anymore.
>>>> This was also documented in my email on 6/12:
>>>> "
>>>> I have seen reviews for the ps, the reqs, and the architecture drafts
>>>> which go all in the same direction: where is the technical substance,
>>>> DECADE will built on?
>>>>
>>>> The last meeting in Paris was really discouraging with respect to the
>>>> technical substance...
>>>> Yet another sign of lack of energy in the WG...
>>>> "
>>>>
>>>> The WG did get a grace period starting after the IETF meeting in Paris
>>>> and had the chance to really show that it is moving in the right
>>>> direction. However, the current state does still not document this and
>>>> therefore the DECADE WG will be closed in the next week. I will inform
>>>> the WG on Tuesday afternoon CEST.
>>>>
>>>> The draft authors of the requirements, architecture, and also the
>>>> Integration Examples of DECADE System can submit the respective drafts
>>>> via the Independent Stream of the RFC editor (see
>>>> http://tools.ietf.org/html/rfc6548 for further information), if they
>>>> wish to.
>>>>
>>>> Regards,
>>>>
>>>>      Martin
>>>>
>>>> --
>>>> IETF Transport Area Director
>>>>
>>>> martin.stiemerling@neclab.eu
>>>>
>>>> NEC Laboratories Europe - Network Research Division NEC Europe Limited
>>>> Registered Office: NEC House, 1 Victoria Road, London W3 6BL
>>>> Registered in England 283
>>
>> --
>> martin.stiemerling@neclab.eu
>>
>> NEC Laboratories Europe - Network Research Division NEC Europe Limited
>> Registered Office: NEC House, 1 Victoria Road, London W3 6BL
>> Registered in England 283

-- 
IETF Transport Area Director

martin.stiemerling@neclab.eu

NEC Laboratories Europe - Network Research Division NEC Europe Limited
Registered Office: NEC House, 1 Victoria Road, London W3 6BL
Registered in England 283

From Martin.Stiemerling@neclab.eu  Mon Sep 24 05:31:03 2012
Return-Path: 
X-Original-To: decade@ietfa.amsl.com
Delivered-To: decade@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60A5121F8618 for ; Mon, 24 Sep 2012 05:31:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.438
X-Spam-Level: 
X-Spam-Status: No, score=-102.438 tagged_above=-999 required=5 tests=[AWL=0.161, 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 KtzYAcQNilVD for ; Mon, 24 Sep 2012 05:31:02 -0700 (PDT)
Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 6E6B721F8615 for ; Mon, 24 Sep 2012 05:31:02 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 80E6C101F1B; Mon, 24 Sep 2012 14:31:01 +0200 (CEST)
X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de)
Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8rlBgUAwegAG; Mon, 24 Sep 2012 14:31:01 +0200 (CEST)
Received: from ENCELADUS.office.hd (enceladus.office.hd [192.168.24.52]) by mailer1.neclab.eu (Postfix) with ESMTP id 61D04101EFA; Mon, 24 Sep 2012 14:30:41 +0200 (CEST)
Received: from [10.1.1.190] (10.1.1.190) by skoll.office.hd (192.168.125.11) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 24 Sep 2012 14:30:06 +0200
Message-ID: <50605271.7030105@neclab.eu>
Date: Mon, 24 Sep 2012 14:30:41 +0200
From: Martin Stiemerling 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0
MIME-Version: 1.0
To: Songhaibin 
References: <20120919230313.17329.44102.idtracker@ietfa.amsl.com><505AE794.8070304@neclab.eu> <8D38716F0C1A444BA0CD7E96454366C23A4DDEF6@szxeml545-mbx.china.huawei.com>  <505C74F3.7060002@neclab.eu>  
In-Reply-To: 
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit
X-Originating-IP: [10.1.1.190]
Cc: "decade@ietf.org" , Konstantinos Pentikousis 
Subject: Re: [decade] WG Action: Conclusion of Decoupled Application Data Enroute (decade)
X-BeenThere: decade@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 24 Sep 2012 12:31:03 -0000

Haibin,

On 09/22/2012 11:13 AM, Songhaibin wrote:
>> Again, I do not think these two documents are extremely bad and lack
>> of technical substances.
>
> Just to make a clarification, I wanted to express these two documents are not perfect, but they are good. And I admit the documents could have been written elaborate if we paid more attention to the editing work.

To reinforce my reviews:
Both drafts need a major overhaul, as many requirements have been 
spilled over into the architecture draft. Furthermore, the architecture 
draft should clearly lay out the protocol components used and what each 
of the component is intended to do.

The architecture draft can be used to double-check if all requirements 
are there, but it should not list new requirements beyond the ones in 
the requirements draft.

The requirements draft itself needs to have **technical** requirements. 
See for instance one part out of the AD review which needs still some work:
- Section 5.1, head of page 10

    REQUIREMENT(S):  Each Data Object should be named to allow access.
        DECADE-compatible protocol(s) MUST support a data object naming
        scheme that ensures a high probability of uniqueness, with no
        coordination among multiple Storage Providers.  In other words,
        two Data Objects with the same name should be the same content
        with high probability.  A DECADE-compatible server SHOULD be able
        to respond to a DECADE-compatible client with an error indicating
        potential name conflicts.
This requirement is actually a set of *four* requirements all stuffed 
together.
1) Each object must be associated with a name.
2) the naming scheme for those names must support a high probability of 
uniqueness
3) no coordination between multiple decade servers required
4) The error handling. Which is, by the way, not related to data name 
uniqueness whatsoever.

The 'rational' sub-part is not doing its job. E.g., there can be 
collisions on the name space between different objects that have 
different content. However, it is not clear, i.e., the rational, why 
this is ok for your system. The rational is solely motivating the 
collision detection mechanism.
By the way, there is no real requirements that says that such a 
collision detection mechanism is required on the server, as one could 
also implement this on the client, right?

The 'exception' part is actually generating a new requirement which is 
also listed later on. This text isn't consistent and it is really hard 
to read and understand.


>
> BR,
> -Haibin
>
>> -----Original Message-----
>> From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.org] On Behalf Of
>> Songhaibin
>> Sent: Saturday, September 22, 2012 1:49 PM
>> To: Martin Stiemerling; Rahman, Akbar
>> Cc: decade@ietf.org; Konstantinos Pentikousis
>> Subject: Re: [decade] WG Action: Conclusion of Decoupled Application Data
>> Enroute (decade)
>>
>>> Talk to your chairs and consider that the requirements went from
>>> publication requested (i.e., on the way to the IESG) back to the WG
>>> (i.e., not on the way to the IESG).
>>>
>>> The same is true for the architecture draft.
>>
>> I was notified in June about the energy of the working group, but I was also
>> surprised about the abrupt notification of the closure of the WG with the email
>> from Martin on Monday, I saw a good list discussion, new I-D submission and was
>> preparing for the Atlanta meeting when I received this notification. I also
>> expressed my disagree to the comment of lack of technical substances. Before
>> Martin became the AD for the DECADE WG, the architecture document was
>> intended to remove a lot of technical details according to comments received, it's
>> not a protocol draft.
>>
>> The extensive comments from Martin to these two IDs are mostly effective, but
>> editorial. They could be addressed together with Kostas's comments in the next
>> version . Again, I do not think these two documents are extremely bad and lack
>> of technical substances.
>>
>> BR,
>> -Haibin

-- 
martin.stiemerling@neclab.eu

NEC Laboratories Europe - Network Research Division NEC Europe Limited
Registered Office: NEC House, 1 Victoria Road, London W3 6BL
Registered in England 283

From Martin.Stiemerling@neclab.eu  Mon Sep 24 05:33:32 2012
Return-Path: 
X-Original-To: decade@ietfa.amsl.com
Delivered-To: decade@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B2EC21F8607 for ; Mon, 24 Sep 2012 05:33:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.441
X-Spam-Level: 
X-Spam-Status: No, score=-102.441 tagged_above=-999 required=5 tests=[AWL=0.158, 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 VGhHy30zvMJj for ; Mon, 24 Sep 2012 05:33:30 -0700 (PDT)
Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 8572E21F85C0 for ; Mon, 24 Sep 2012 05:33:30 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id E6D70101F1B; Mon, 24 Sep 2012 14:33:29 +0200 (CEST)
X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de)
Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f-TVMKd4APXr; Mon, 24 Sep 2012 14:33:29 +0200 (CEST)
Received: from ENCELADUS.office.hd (enceladus.office.hd [192.168.24.52]) by mailer1.neclab.eu (Postfix) with ESMTP id C44FC101EFA; Mon, 24 Sep 2012 14:33:14 +0200 (CEST)
Received: from [10.1.1.190] (10.1.1.190) by skoll.office.hd (192.168.125.11) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 24 Sep 2012 14:32:18 +0200
Message-ID: <506052F5.9070006@neclab.eu>
Date: Mon, 24 Sep 2012 14:32:53 +0200
From: Martin Stiemerling 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0
MIME-Version: 1.0
To: Peng Zhang 
References: <50531AB3.6090601@neclab.eu>  <50583257.2080404@neclab.eu>  
In-Reply-To: 
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit
X-Originating-IP: [10.1.1.190]
Cc: "DECADE@ietf.org" 
Subject: Re: [decade] DECADE WG to be closed
X-BeenThere: decade@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 24 Sep 2012 12:33:32 -0000

Dear Peng,

On 09/22/2012 07:49 PM, Peng Zhang wrote:
> Dear Martin,
>
> 	I tend to agree with you on some points, but can hardly agree on all. For example I cannot agree with your points that.
>
>>> The was no and still has not been an adequate response from the DECADE
>>> WG to these reviews. For instance, the requirements did get a lot of
>>> feedback from Dave Crocker, but this feedback was never addressed in an
>
>>> email.
>
>
> As far as I know, Richard has called for participation on addressing these feedbacks, and gave some valuable points (http://www.ietf.org/mail-archive/web/decade/current/msg00694.html). As a participant, I tried to address these issues in my later emails. For example, I gave some suggestions on how to organize the -req and -arch documents (http://www.ietf.org/mail-archive/web/decade/current/msg00697.html). Also, Stephen and me had a lot of discussions on the issue of object naming in -req and -arch documents (http://www.ietf.org/mail-archive/web/decade/current/msg00705.html). We even cc'ed our discussions to the ppsp wg for comments, and received comments from Arno (http://www.ietf.org/mail-archive/web/decade/current/msg00741.html).
>
> Given this, I don't know why you would arrive at the conclusions that "this feedback was never addressed in an email".

To make it short, there is no response to this:
http://www.ietf.org/mail-archive/web/apps-discuss/current/msg04704.html

This review was and still is fundamental.

   Martin

>
> BR,
>
> Peng.
>
> On Sep 22, 2012, at 2:52 PM, Songhaibin wrote:
>
>> Dear Martin,
>>
>>> -----Original Message-----
>>> From: Martin Stiemerling [mailto:martin.stiemerling@neclab.eu]
>>> Sent: Tuesday, September 18, 2012 4:36 PM
>>> To: Songhaibin
>>> Cc: Richard Woundy
>>> Subject: Re: DECADE WG to be closed
>>>
>>> Dear Haibin,
>>>
>>> On 09/17/2012 11:39 AM, Songhaibin wrote:
>>>> Dear Martin,
>>>>
>>>> Hope everything goes well with you and thank you very much for your efforts
>>> to reviewing the drafts in detail and giving guidance.
>>>>
>>>> As I agree with most of your comments to the DECADE requirements draft, but
>>> I have to say IMO the architecture document is not that bad. This document gives
>>> a clear description of the DECADE server/client components and
>>> implementation/design principals which will be reflected in the protocols, IMO
>>> this is what an architecture document should do.
>>>>
>>>> I do not agree there is lack of technical substances to design a base protocol
>>> which can satisfy the transport and resource control requirements for content
>>> distribution applications. Some detailed design choices are still not very clear, and
>>> need efforts for them.
>>>>
>>>> And recently, the energy is growing, we recently received a lot of list discussion
>>> including comments from Kostas about the requirements and architecture and
>>> also a new individual draft for the service discovery was submitted.
>>>
>>> The energy has indeed grown in the WG since before the summer. But, I
>>> indicated in my email from mid of June that I have doubts on the
>>> technical quality of the DECADE drafts. These doubts have turned into
>>> certainty, i.e., see the my AD reviews of the requirements and the
>>> architecture.
>>>
>>> The technical quality of the drafts would be ok, if the WG would be at
>>> the beginning of the process of discussing and writing those drafts, but
>>> it is not acceptable at the end when the drafts are intended to become RFCs:
>>> The technical base is just to weak to continue from, even after spending
>>> time and effort of the WG participants for more than 2 years.
>>
>> The requirements document was accepted on Oct. 18, 2010, and the architecture draft was accepted on March 7, 2011.
>>
>>>
>>> Another important data point, as mentioned earlier:
>>> There has been public feedback from IETF community members, such as Dave
>>> Crocker and Carsten Bormann, which questioned the technical base of
>>> DECADE as a whole. This happened at the end of the 2011 and in the first
>>> quarter of 2012.
>>
>>> The was no and still has not been an adequate response from the DECADE
>>> WG to these reviews. For instance, the requirements did get a lot of
>>> feedback from Dave Crocker, but this feedback was never addressed in an
>
>>> email. I also have been unable to sort out what parts of the feedback
>>> has been addressed in the updated draft and how, and what parts have not
>>> been addressed.
>>
>> I believe all those comments were addressed in the current draft, as I joined the discussion with the authors to address the comments. Their efforts should be respected. The authors and I would like Dave and Carsten to check the draft with their comments, if they are interested. While I admit answering in the mailing list is a main method to resolve comments, but it is not the only method.
>>
>>>
>>> I have also received much stronger feedback about the DECADE WG in
>>> private emails to me. Again from long standing IETF community members
>>> that send me feedback arguing that DECADE is not having a technical base
>>> to build on top of.
>>
>> OK. But general rule for IETF is rough consensus, not private emails. Why not discuss their questions in the list?
>>
>>>
>>> You have asked in your other email to give more time to the WG until the
>>> next IETF meeting in November. This would be one possible way forward,
>>> but I do know about the past 6 months after the IETF meeting in Paris.
>>> Not a lot has happened during this period in order to improve the WG
>>> drafts, in the sense that there is a solid technical base where DECADE
>>> could continue to work from.
>>
>> I can answer If your question about the technical base can be more specific.
>>
>>>
>>> Even if you and the whole WG would start to work full-time on the
>>> drafts, it still would take longer than to the next IETF meeting to move
>>> the requirements and architecture forward. My gut guessing is that it
>>> will take at least until March 2013.
>>
>>> To give an example:
>>> It is completely unclear how the resources on a DECADE server are
>>> supposed to be managed and how this management is mapped to the protocol
>>> split of SDT, DRP, and other management protocols.
>>> Parts of it, such as setting the permissions of data objects clearly
>>> belongs to the DRP, and it is sort of stated in a vague way in the
>>> architecture, but it is not documented in a comprehensive way. Other
>>> parts, such as the accounting is probably not part of the the DRP nor
>>> SDT, but there is supposedly another interface that is needed for this.
>>>
>>> Has this been discussed at any point in the WG?
>>
>> I just read the email that Richard answered these questions with text from the current drafts. And I agree with his answers.
>>
>> While I respect that AD can make the decision of closing a WG, but I see a dozen of emails expressed their disappointment.
>>
>> BR,
>> -Haibin
>>
>>
>>> Given the above points and my summaries out of the last email and the
>>> one of 6/12, the DECADE WG is going to be closed by today.
>>>
>>> The DECADE WG mailing list will remain open until the end of the year,
>>> to let the people a chance to discuss how to go forward with the drafts.
>>>
>>> As suggest in my earlier email:
>>> The participants are free to overhaul the drafts and to submit them as
>>> individual submissions to the RFC Editor's Independent Stream.
>>>
>>>
>>> The decisions to close the WG can be of course appealed via the IETF
>>> appeal process:
>>> See 'Appeals and PR-Actions' under http://www.ietf.org/iesg/ and RFC 2026.
>>>
>>>    Martin
>>>
>>>>
>>>> BR,
>>>> -Haibin
>>>>
>>>>
>>>>> -----Original Message-----
>>>>> From: Martin Stiemerling [mailto:martin.stiemerling@neclab.eu]
>>>>> Sent: Friday, September 14, 2012 7:53 PM
>>>>> To: Songhaibin; Richard Woundy
>>>>> Subject: DECADE WG to be closed
>>>>>
>>>>> Dear Rich and Haibin,
>>>>>
>>>>> I have finally done my AD review for the DECADE architecture draft after
>>>>> finishing the DECADE requirements draft.
>>>>>
>>>>> The first feedback for the DECADE architecture draft has been provided
>>>>> in the datatracker and sent to the authors and you by email.
>>>>>
>>>>> Both drafts are in an extremely bad shape, i.e., they would require a
>>>>> major overhaul and have been sent back to the working group due to lack
>>>>> of technical quality.
>>>>>
>>>>> I have already expressed my concerns about the energy and the lack of
>>>>> technical confidence in the group in my summary email of 6/12. The
>>>>> requirements and architecture drafts got advanced towards the IESG
>>>>> afterwards. The push for energy was good.
>>>>>
>>>>> However, after reviewing the two key drafts, requirements and
>>>>> architecture, and receiving feedback from IETF community members, I have
>>>>> come to the conclusion that the DECADE working group lacks a sound
>>>>> technical ground.
>>>>>
>>>>> The DECADE group started its work in end of April 2010 and is now
>>>>> working for more than 2 years on the milestones/drafts. The time isn't a
>>>>> big deal, but after 2 years I would have expected that the documents are
>>>>> on a good technical level where the WG can build on top of.
>>>>>
>>>>> The issues for the potential future protocol works is that if the basics
>>>>> are not well understood and documented, how can the protocols be
>>>>> designed in a comprehensive and technical sound way?
>>>>> I cannot see this anymore.
>>>>> This was also documented in my email on 6/12:
>>>>> "
>>>>> I have seen reviews for the ps, the reqs, and the architecture drafts
>>>>> which go all in the same direction: where is the technical substance,
>>>>> DECADE will built on?
>>>>>
>>>>> The last meeting in Paris was really discouraging with respect to the
>>>>> technical substance...
>>>>> Yet another sign of lack of energy in the WG...
>>>>> "
>>>>>
>>>>> The WG did get a grace period starting after the IETF meeting in Paris
>>>>> and had the chance to really show that it is moving in the right
>>>>> direction. However, the current state does still not document this and
>>>>> therefore the DECADE WG will be closed in the next week. I will inform
>>>>> the WG on Tuesday afternoon CEST.
>>>>>
>>>>> The draft authors of the requirements, architecture, and also the
>>>>> Integration Examples of DECADE System can submit the respective drafts
>>>>> via the Independent Stream of the RFC editor (see
>>>>> http://tools.ietf.org/html/rfc6548 for further information), if they
>>>>> wish to.
>>>>>
>>>>> Regards,
>>>>>
>>>>>     Martin
>>>>>
>>>>> --
>>>>> IETF Transport Area Director
>>>>>
>>>>> martin.stiemerling@neclab.eu
>>>>>
>>>>> NEC Laboratories Europe - Network Research Division NEC Europe Limited
>>>>> Registered Office: NEC House, 1 Victoria Road, London W3 6BL
>>>>> Registered in England 283
>>>
>>> --
>>> martin.stiemerling@neclab.eu
>>>
>>> NEC Laboratories Europe - Network Research Division NEC Europe Limited
>>> Registered Office: NEC House, 1 Victoria Road, London W3 6BL
>>> Registered in England 283
>

-- 
martin.stiemerling@neclab.eu

NEC Laboratories Europe - Network Research Division NEC Europe Limited
Registered Office: NEC House, 1 Victoria Road, London W3 6BL
Registered in England 283

From Martin.Stiemerling@neclab.eu  Mon Sep 24 05:34:50 2012
Return-Path: 
X-Original-To: decade@ietfa.amsl.com
Delivered-To: decade@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16FA021F8610 for ; Mon, 24 Sep 2012 05:34:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.445
X-Spam-Level: 
X-Spam-Status: No, score=-102.445 tagged_above=-999 required=5 tests=[AWL=0.155, 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 9MqLpOarjGLg for ; Mon, 24 Sep 2012 05:34:49 -0700 (PDT)
Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id A744F21F8607 for ; Mon, 24 Sep 2012 05:34:48 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 19179101F21; Mon, 24 Sep 2012 14:34:48 +0200 (CEST)
X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de)
Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fm4aunWUrB3i; Mon, 24 Sep 2012 14:34:48 +0200 (CEST)
Received: from ENCELADUS.office.hd (enceladus.office.hd [192.168.24.52]) by mailer1.neclab.eu (Postfix) with ESMTP id E3173101EFA; Mon, 24 Sep 2012 14:34:27 +0200 (CEST)
Received: from [10.1.1.190] (10.1.1.190) by skoll.office.hd (192.168.125.11) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 24 Sep 2012 14:33:52 +0200
Message-ID: <50605353.5020807@neclab.eu>
Date: Mon, 24 Sep 2012 14:34:27 +0200
From: Martin Stiemerling 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0
MIME-Version: 1.0
To: "Rahman, Akbar" 
References: <20120919230313.17329.44102.idtracker@ietfa.amsl.com><505AE794.8070304@neclab.eu><8D38716F0C1A444BA0CD7E96454366C23A4DDEF6@szxeml545-mbx.china.huawei.com> <505C74F3.7060002@neclab.eu>  
In-Reply-To: 
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit
X-Originating-IP: [10.1.1.190]
Cc: decade@ietf.org, Konstantinos Pentikousis 
Subject: Re: [decade] WG Action: Conclusion of Decoupled Application Data Enroute (decade)
X-BeenThere: decade@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 24 Sep 2012 12:34:50 -0000

On 09/23/2012 04:47 AM, Rahman, Akbar wrote:
> For the record, here is the internal Word tracking document from June 2012 that the authors used to ensure that we addressed all the comments that we received from Carsten (Apps Area Reviewer) and Dave Harrington (Previous AD) on the Architecture I-D Rev. 04.  All these comments were incorporated into the subsequent versions of the Architecture I-D.  The authors had kept the chairs in the loop with the tracking document.
>
> This is part of the reason that the authors take offense to (and are puzzled by) the suggestion that we did not seriously address the comments that we got from various reviewers.

Where is the publicly accessible record of this?
Any email to the reviewers would good, just in order to see what 
comments you have addressed and how.

   Martin


>
>
> /Akbar
>
>
>
> -----Original Message-----
> From: Songhaibin [mailto:haibin.song@huawei.com]
> Sent: Saturday, September 22, 2012 1:49 AM
> To: Martin Stiemerling; Rahman, Akbar
> Cc: decade@ietf.org; Konstantinos Pentikousis
> Subject: RE: [decade] WG Action: Conclusion of Decoupled Application Data Enroute (decade)
>
>> Talk to your chairs and consider that the requirements went from
>> publication requested (i.e., on the way to the IESG) back to the WG
>> (i.e., not on the way to the IESG).
>>
>> The same is true for the architecture draft.
>
> I was notified in June about the energy of the working group, but I was also surprised about the abrupt notification of the closure of the WG with the email from Martin on Monday, I saw a good list discussion, new I-D submission and was preparing for the Atlanta meeting when I received this notification. I also expressed my disagree to the comment of lack of technical substances. Before Martin became the AD for the DECADE WG, the architecture document was intended to remove a lot of technical details according to comments received, it's not a protocol draft.
>
> The extensive comments from Martin to these two IDs are mostly effective, but editorial. They could be addressed together with Kostas's comments in the next version . Again, I do not think these two documents are extremely bad and lack of technical substances.
>
> BR,
> -Haibin
>

-- 
martin.stiemerling@neclab.eu

NEC Laboratories Europe - Network Research Division NEC Europe Limited
Registered Office: NEC House, 1 Victoria Road, London W3 6BL
Registered in England 283

From Martin.Stiemerling@neclab.eu  Mon Sep 24 05:41:00 2012
Return-Path: 
X-Original-To: decade@ietfa.amsl.com
Delivered-To: decade@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D99C21F860E for ; Mon, 24 Sep 2012 05:40:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.448
X-Spam-Level: 
X-Spam-Status: No, score=-102.448 tagged_above=-999 required=5 tests=[AWL=0.151, 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 nvEoUw3w6RFJ for ; Mon, 24 Sep 2012 05:40:58 -0700 (PDT)
Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 4453C21F8607 for ; Mon, 24 Sep 2012 05:40:58 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 86FF7101F20 for ; Mon, 24 Sep 2012 14:40:57 +0200 (CEST)
X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de)
Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aBpt+sZnNird for ; Mon, 24 Sep 2012 14:40:57 +0200 (CEST)
Received: from ENCELADUS.office.hd (enceladus.office.hd [192.168.24.52]) by mailer1.neclab.eu (Postfix) with ESMTP id 7045E101F1B for ; Mon, 24 Sep 2012 14:40:52 +0200 (CEST)
Received: from [10.1.1.190] (10.1.1.190) by skoll.office.hd (192.168.125.11) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 24 Sep 2012 14:40:17 +0200
Message-ID: <506054D4.80006@neclab.eu>
Date: Mon, 24 Sep 2012 14:40:52 +0200
From: Martin Stiemerling 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0
MIME-Version: 1.0
To: "decade@ietf.org" 
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit
X-Originating-IP: [10.1.1.190]
Subject: [decade] The future of the DECADE mailing list
X-BeenThere: decade@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 24 Sep 2012 12:41:00 -0000

Hi all,

The DECADE mailing list was kept open as a courtesy to the people on 
that list in order to move on with the drafts, if there is still the 
wish to do.

However, the list will be closed by October 22nd if the list is not used 
for technical discussions around the remaining DECADE drafts.

Just to let know in advance,

   Martin

-- 
IETF Transport Area Director

martin.stiemerling@neclab.eu

NEC Laboratories Europe - Network Research Division NEC Europe Limited
Registered Office: NEC House, 1 Victoria Road, London W3 6BL
Registered in England 283

From hallam@gmail.com  Mon Sep 24 05:57:27 2012
Return-Path: 
X-Original-To: decade@ietfa.amsl.com
Delivered-To: decade@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADD2A21F8685 for ; Mon, 24 Sep 2012 05:57:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.989
X-Spam-Level: 
X-Spam-Status: No, score=-3.989 tagged_above=-999 required=5 tests=[AWL=-0.391, 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 igEYOsEG2MDe for ; Mon, 24 Sep 2012 05:57:27 -0700 (PDT)
Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id 300DA21F8682 for ; Mon, 24 Sep 2012 05:57:27 -0700 (PDT)
Received: by oagn5 with SMTP id n5so5430687oag.31 for ; Mon, 24 Sep 2012 05:57:26 -0700 (PDT)
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 :cc:content-type; bh=f+ES6aKGTqL3MaukZlrWiZEKL4kFPBnFOa7jh1ABbsE=; b=M3gWDex44Gl59t8F5oTpAJTsspeveYojYhxrqrZZu0S9eJKu8FbW7goRw9CNSx2Dul fLAqC4v2IhDxCe62mcf2/y2CvemMKq7qJ5AV16U0Cq1y6Qte+aAQMVmPgyUgTtIYdsV0 5H0wHQpZfOm4f5gsAXoiR+C41ttTs6HX0/uHNSJRbS5JdQydO70++yhReyHRuhJ/kuOE KS2VGj4Ii/DPs34NGX3P6d3Ra/BFmUS7Hl3OsYMWUP34Hj+wThHqn/kRTRr8rfja4rSN RoAMb4wEkuAY8pmfWE0xq8rbIXGgOvnMwFIQfEeDUeC/JcQs2BkTPcJ3rO+nRus2N89I xIAg==
MIME-Version: 1.0
Received: by 10.60.10.102 with SMTP id h6mr9199507oeb.18.1348491446854; Mon, 24 Sep 2012 05:57:26 -0700 (PDT)
Received: by 10.76.18.237 with HTTP; Mon, 24 Sep 2012 05:57:26 -0700 (PDT)
In-Reply-To: <506052F5.9070006@neclab.eu>
References: <50531AB3.6090601@neclab.eu>  <50583257.2080404@neclab.eu>   <506052F5.9070006@neclab.eu>
Date: Mon, 24 Sep 2012 08:57:26 -0400
Message-ID: 
From: Phillip Hallam-Baker 
To: Martin Stiemerling 
Content-Type: multipart/alternative; boundary=e89a8fb1f4aeac252f04ca7221b9
Cc: "DECADE@ietf.org" 
Subject: Re: [decade] DECADE WG to be closed
X-BeenThere: decade@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 24 Sep 2012 12:57:27 -0000

--e89a8fb1f4aeac252f04ca7221b9
Content-Type: text/plain; charset=ISO-8859-1

How does this leave the ni: extensions draft?

This is a piece of work that I originally proposed outside DECADE and was
persuaded to bring in since the DECADE ni work was similar to my di
proposal.

One part of the work is on track to become an RFC but the extensions piece
has the encryption capability which is very useful since it turns an
identifier into a bearer token.

--e89a8fb1f4aeac252f04ca7221b9
Content-Type: text/html; charset=ISO-8859-1

How does this leave the ni: extensions draft?

This is a piece of work that I originally proposed outside DECADE and was persuaded to bring in since the DECADE ni work was similar to my di proposal.



One part of the work is on track to become an RFC but the extensions piece has the encryption capability which is very useful since it turns an identifier into a bearer token.


--e89a8fb1f4aeac252f04ca7221b9--

From Martin.Stiemerling@neclab.eu  Mon Sep 24 06:05:21 2012
Return-Path: 
X-Original-To: decade@ietfa.amsl.com
Delivered-To: decade@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D7AC21F86AD for ; Mon, 24 Sep 2012 06:05:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.451
X-Spam-Level: 
X-Spam-Status: No, score=-102.451 tagged_above=-999 required=5 tests=[AWL=0.148, 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 r6Q5cVPToV4f for ; Mon, 24 Sep 2012 06:05:20 -0700 (PDT)
Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id EEEA621F86AA for ; Mon, 24 Sep 2012 06:05:19 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 5B0AE101F20; Mon, 24 Sep 2012 15:05:19 +0200 (CEST)
X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de)
Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5vPm3Pef2MzT; Mon, 24 Sep 2012 15:05:19 +0200 (CEST)
Received: from ENCELADUS.office.hd (enceladus.office.hd [192.168.24.52]) by mailer1.neclab.eu (Postfix) with ESMTP id 3E6FC101F1B; Mon, 24 Sep 2012 15:05:04 +0200 (CEST)
Received: from [10.1.1.190] (10.1.1.190) by skoll.office.hd (192.168.125.11) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 24 Sep 2012 15:04:29 +0200
Message-ID: <50605A7F.9070703@neclab.eu>
Date: Mon, 24 Sep 2012 15:05:03 +0200
From: Martin Stiemerling 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0
MIME-Version: 1.0
To: Phillip Hallam-Baker 
References: <50531AB3.6090601@neclab.eu>  <50583257.2080404@neclab.eu>   <506052F5.9070006@neclab.eu> 
In-Reply-To: 
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit
X-Originating-IP: [10.1.1.190]
Cc: "DECADE@ietf.org" 
Subject: Re: [decade] DECADE WG to be closed
X-BeenThere: decade@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 24 Sep 2012 13:05:21 -0000

Hi Phillip,

You still can announce this on the DECADE list, but it might be also 
worth to announce it on the IRTF ICNRG list.

There is no WG for this right now, but by announcing it to the above 
ones, you will reach the right set of people IHO.

   Martin

On 09/24/2012 02:57 PM, Phillip Hallam-Baker wrote:
> How does this leave the ni: extensions draft?
>
> This is a piece of work that I originally proposed outside DECADE and
> was persuaded to bring in since the DECADE ni work was similar to my di
> proposal.
>
> One part of the work is on track to become an RFC but the extensions
> piece has the encryption capability which is very useful since it turns
> an identifier into a bearer token.

-- 
martin.stiemerling@neclab.eu

NEC Laboratories Europe - Network Research Division NEC Europe Limited
Registered Office: NEC House, 1 Victoria Road, London W3 6BL
Registered in England 283

From Akbar.Rahman@InterDigital.com  Mon Sep 24 07:55:45 2012
Return-Path: 
X-Original-To: decade@ietfa.amsl.com
Delivered-To: decade@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5044221F87C4 for ; Mon, 24 Sep 2012 07:55:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.518
X-Spam-Level: 
X-Spam-Status: No, score=-2.518 tagged_above=-999 required=5 tests=[AWL=0.081,  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 1PvutHp3W34G for ; Mon, 24 Sep 2012 07:55:44 -0700 (PDT)
Received: from idcout.InterDigital.com (smtp-out1.interdigital.com [64.208.228.135]) by ietfa.amsl.com (Postfix) with ESMTP id E0FD021F87BF for ; Mon, 24 Sep 2012 07:55:43 -0700 (PDT)
Received: from SAM.InterDigital.com ([10.30.2.11]) by idcout.InterDigital.com with Microsoft SMTPSVC(6.0.3790.4675);  Mon, 24 Sep 2012 10:55:42 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: base64
Date: Mon, 24 Sep 2012 10:55:42 -0400
Message-ID: 
In-Reply-To: <50604EB1.8040404@neclab.eu>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [decade] WG Action: Conclusion of Decoupled Application Data Enroute (decade)
Thread-Index: Ac2aTjfEIucSmqKrSbOaICrDiu4QFgAFTqHQ
References: <20120919230313.17329.44102.idtracker@ietfa.amsl.com><505AE794.8070304@neclab.eu> <8D38716F0C1A444BA0CD7E96454366C23A4DDEF6@szxeml545-mbx.china.huawei.com>  <505C74F3.7060002@neclab.eu>  <50604EB1.8040404@neclab.eu>
From: "Rahman, Akbar" 
To: "Martin Stiemerling" 
X-OriginalArrivalTime: 24 Sep 2012 14:55:42.0988 (UTC) FILETIME=[AB97ECC0:01CD9A64]
Cc: decade@ietf.org, Konstantinos Pentikousis 
Subject: Re: [decade] WG Action: Conclusion of Decoupled Application Data Enroute (decade)
X-BeenThere: decade@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 24 Sep 2012 14:55:45 -0000

RGVhciBNYXJ0aW4sDQoNCg0KSnVzdCB0byBnZW50bHkgcmVtaW5kIHlvdSwgdGhlIG9yaWdpbmFs
IHBvaW50IGluIHRoaXMgZW1haWwgdHJhaWwgd2FzIHlvdXIgY29udGVudGlvbiB0aGF0ICIgLi4g
YnV0IGl0IHNob3VsZCBub3QgYmUgYSBzdXJwcmlzZSBmb3IgdGhlIHdvcmtpbmcgZHJhZnRzIGF1
dGhvcnMiIHRoYXQgdGhlIFdHIHdhcyBiZWluZyBjbG9zZWQuICBUbyBiYWNrLXVwIHRoaXMgcG9p
bnQgeW91IHNhaWQ6DQoNCj4gVGFsayB0byB5b3VyIGNoYWlycyBhbmQgY29uc2lkZXIgdGhhdCB0
aGUgcmVxdWlyZW1lbnRzIHdlbnQgZnJvbQ0KPiBwdWJsaWNhdGlvbiByZXF1ZXN0ZWQgKGkuZS4s
IG9uIHRoZSB3YXkgdG8gdGhlIElFU0cpIGJhY2sgdG8gdGhlIFdHDQo+IChpLmUuLCBub3Qgb24g
dGhlIHdheSB0byB0aGUgSUVTRykuDQoNCg0KQXQgbGVhc3Qgb25lIG9mIHRoZSBjaGFpcnMgaGFz
IHdyaXR0ZW4gYmFjayBhbmQgc2FpZCBoZSB3YXMgdmVyeSBzdXJwcmlzZWQgYXMgd2VsbCB0aGF0
IHRoZSBXRyB3YXMgYmVpbmcgY2xvc2VkLiAgQW5kIEkgcG9pbnRlZCB0byB0aGUgSS1EIHN0YXRl
IGRpYWdyYW0gdG8gc2hvdyB0aGF0IHNlbmRpbmcgdGhlIEktRCBiYWNrIHRvIHRoZSBhdXRob3Jz
IHdpdGggY29tbWVudHMgd2FzIHBhcnQgb2YgdGhlIHByb2Nlc3MgYW5kIHNvIGNvdWxkIG5vdCBo
YXZlIGZsYWdnZWQgdG8gbWUgdGhhdCB0aGUgV0cgd2FzIGJlaW5nIGNsb3NlZC4gIFNvIHlvdXIg
YXJndW1lbnQgZG9lcyBub3QgaG9sZCB3YXRlci4NCg0KTm93IHlvdSBicmluZyB1cCB0aGUgUkZD
IDI0MTggYnV0IHRoYXQgaGFzIG5vdGhpbmcgdG8gd2l0aCB0aGUgb3JpZ2luYWwgcG9pbnQuICBJ
biBmYWN0IGl0IGNlcnRhaW5seSBzZWVtcyB0byBiZSBhIHN1cnByaXNlIHRvIGV2ZXJ5b25lIEJV
VCB5b3UgdGhhdCB0aGUgV0cgaXMgYmVpbmcgc2h1dCBkb3duIChhcyBldmlkZW5jZWQgYnkgdGhl
IGF2YWxhbmNoZSBvZiBlbWFpbHMgb24gdGhlIGxpc3QpLiAgU28gcGxlYXNlIGp1c3QgY29uY2Vk
ZSB0aGUgcG9pbnQgb3IganVzdCBtb3ZlIG9uLg0KDQoNCg0KUmVzcGVjdGZ1bGx5IHlvdXJzLA0K
DQoNCkFrYmFyDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IE1hcnRpbiBT
dGllbWVybGluZyBbbWFpbHRvOm1hcnRpbi5zdGllbWVybGluZ0BuZWNsYWIuZXVdIA0KU2VudDog
TW9uZGF5LCBTZXB0ZW1iZXIgMjQsIDIwMTIgODoxNSBBTQ0KVG86IFJhaG1hbiwgQWtiYXINCkNj
OiBLb25zdGFudGlub3MgUGVudGlrb3VzaXM7IGRlY2FkZUBpZXRmLm9yZw0KU3ViamVjdDogUmU6
IFtkZWNhZGVdIFdHIEFjdGlvbjogQ29uY2x1c2lvbiBvZiBEZWNvdXBsZWQgQXBwbGljYXRpb24g
RGF0YSBFbnJvdXRlIChkZWNhZGUpDQoNCkFrYmFyLA0KDQpPbiAwOS8yMi8yMDEyIDAxOjUyIEFN
LCBSYWhtYW4sIEFrYmFyIHdyb3RlOg0KPiBIaSBNYXJ0aW4sDQo+DQo+DQo+IFJlZ2FyZGluZyB5
b3VyIHBvaW50IGJlbG93LiAgVW5mb3J0dW5hdGVseSwgSSB0aGluayB0aGF0IHlvdSBhcmUgZmFj
dHVhbGx5IHdyb25nLiAgT3RoZXJ3aXNlIHByb3ZlIG1lIHdyb25nIGJ5IHNob3dpbmcgbWUgd2hl
cmUgb24gdGhlIEktRCBTdGF0ZSBEaWFncmFtIGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9p
bWFnZXMvc3RhdGVfZGlhZ3JhbS5wbmcgaXQgc3BlY2lmaWVzIHRoYXQgc2VuZGluZyBhbiBJLUQg
YmFjayB0byB0aGUgYXV0aG9ycyB3aXRoIGNvbW1lbnRzIGVxdWFscyBzaHV0dGluZyBkb3duIHRo
ZSBXRyBhbmQgc3RvcHBpbmcgYSBXRyBhcHByb3ZlZCBJLUQuDQoNCllvdSBhcmUgcmVmZXJyaW5n
IHRoZSBzdGF0ZSBkaWFncmFtIGZvciBJbnRlcm5ldCBkcmFmdHMgYW5kIHRoaXMgc3RhdGUgDQpk
aWFncmFtIGRvZXMgaGF2ZSBubyByZWxhdGlvbnNoaXAgdG8gd2hhdCBoYXBwZW5zIHdpdGggYSBX
Ry4NCg0KSG93ZXZlciwgZm9yIHRlcm1pbmF0aW9uIG9mIFdHcywgcGxlYXNlIHJlZmVyIHRvIFJG
QyAyNDE4LCBTZWN0aW9uIDQsIA0KY29waWVkIGhlcmUgZm9yIHlvdXIgY29udmVuaWVuY2U6DQoN
CjQuIFdvcmtpbmcgR3JvdXAgVGVybWluYXRpb24NCg0KDQogICAgV29ya2luZyBncm91cHMgYXJl
IHR5cGljYWxseSBjaGFydGVyZWQgdG8gYWNjb21wbGlzaCBhIHNwZWNpZmljIHRhc2sNCiAgICBv
ciB0YXNrcy4gIEFmdGVyIHRoZSB0YXNrcyBhcmUgY29tcGxldGUsIHRoZSBncm91cCB3aWxsIGJl
IGRpc2JhbmRlZC4NCiAgICBIb3dldmVyLCBpZiBhIFdHIHByb2R1Y2VzIGEgUHJvcG9zZWQgb3Ig
RHJhZnQgU3RhbmRhcmQsIHRoZSBXRyB3aWxsDQogICAgZnJlcXVlbnRseSBiZWNvbWUgZG9ybWFu
dCByYXRoZXIgdGhhbiBkaXNiYW5kIChpLmUuLCB0aGUgV0cgd2lsbCBubw0KICAgIGxvbmdlciBj
b25kdWN0IGZvcm1hbCBhY3Rpdml0aWVzLCBidXQgdGhlIG1haWxpbmcgbGlzdCB3aWxsIHJlbWFp
bg0KICAgIGF2YWlsYWJsZSB0byByZXZpZXcgdGhlIHdvcmsgYXMgaXQgbW92ZXMgdG8gRHJhZnQg
U3RhbmRhcmQgYW5kDQogICAgU3RhbmRhcmQgc3RhdHVzLikNCg0KICAgIElmLCBhdCBzb21lIHBv
aW50LCBpdCBiZWNvbWVzIGV2aWRlbnQgdGhhdCBhIHdvcmtpbmcgZ3JvdXAgaXMgdW5hYmxlDQog
ICAgdG8gY29tcGxldGUgdGhlIHdvcmsgb3V0bGluZWQgaW4gdGhlIGNoYXJ0ZXIsIG9yIGlmIHRo
ZSBhc3N1bXB0aW9ucw0KICAgIHdoaWNoIHRoYXQgd29yayB3YXMgYmFzZWQgaGF2ZSBiZWVuIG1v
ZGlmaWVkIGluIGRpc2N1c3Npb24gb3IgYnkNCiAgICBleHBlcmllbmNlLCB0aGUgQXJlYSBEaXJl
Y3RvciwgaW4gY29uc3VsdGF0aW9uIHdpdGggdGhlIHdvcmtpbmcgZ3JvdXANCiAgICBjYW4gZWl0
aGVyOg0KDQogICAgMS4gUmVjaGFydGVyIHRvIHJlZm9jdXMgaXRzIHRhc2tzLA0KICAgIDIuIENo
b29zZSBuZXcgQ2hhaXIocyksIG9yDQogICAgMy4gRGlzYmFuZC4NCg0KICAgIElmIHRoZSB3b3Jr
aW5nIGdyb3VwIGRpc2FncmVlcyB3aXRoIHRoZSBBcmVhIERpcmVjdG9yJ3MgY2hvaWNlLCBpdA0K
ICAgIG1heSBhcHBlYWwgdG8gdGhlIElFU0cgKHNlZSBzZWN0aW9uIDMuNCkuDQoNCg0KYW5kIGNp
dGUgdGhlIGVtYWlsIGFubm91bmNpbmcgdGhlIHRlcm1pbmF0aW9uIG9mIHRoZSBERUNBREUgV0cN
CiJUaGUgREVDQURFIFdHIGhhcyByZWFjaGVkIHRoZSBwb2ludCB3aGVyZSBpdCBpcyBldmlkZW50
IHRoYXQgdGhlDQpjaGFydGVyZWQgd29yayBjYW5ub3QgYmUgY29tcGxldGVkIGF0IGEgdGVjaG5p
Y2FsIGxldmVsIHN1aXRhYmxlIGZvciB0aGUNCmNvbWluZyBzdGVwcyBvZiB0aGUgcHJvdG9jb2wg
ZGVmaW5pdGlvbiBhbmQgYWxzbyB3aXRoaW4gYW4gYXBwcm9wcmlhdGUNCnRpbWUgZnJhbWUuIg0K
DQpUaGUgZHJhZnRzIGRvIG5vdCBzaG93IHRoYXQgdGhlIFdHIGlzIGNvbXBsZXRpbmcgaXRzIHRl
Y2huaWNhbCB3b3JrLg0KDQogICBNYXJ0aW4NCg0KPg0KPg0KPg0KPiAtLSBzbmlwIC0tDQo+DQo+
PiAtIEFzIGFuIGF1dGhvciwgSSBkbyBOT1QgZmVlbCB0aGF0IEkgd2FzIHBhcnQgb2YgYW55IGV4
dGVuc2l2ZSBkaXNjdXNzaW9ucyByZWdhcmRpbmcgcG90ZW50aWFsIHNodXR0aW5nIGRvd24gb2Yg
dGhlIERFQ0FERSBXRyBhbmQgZXNwZWNpYWxseSBzdG9wcGluZyB0aGUgY3VycmVudCBhY3RpdmUg
V0cgZHJhZnRzIChlc3BlY2lhbGx5IHRoZSBBcmNoaXRlY3R1cmUgSS1EIHdoZXJlIEkgd2FzIGFu
IGF1dGhvcikuDQo+DQo+IFRhbGsgdG8geW91ciBjaGFpcnMgYW5kIGNvbnNpZGVyIHRoYXQgdGhl
IHJlcXVpcmVtZW50cyB3ZW50IGZyb20NCj4gcHVibGljYXRpb24gcmVxdWVzdGVkIChpLmUuLCBv
biB0aGUgd2F5IHRvIHRoZSBJRVNHKSBiYWNrIHRvIHRoZSBXRw0KPiAoaS5lLiwgbm90IG9uIHRo
ZSB3YXkgdG8gdGhlIElFU0cpLg0KPg0KPiBUaGUgc2FtZSBpcyB0cnVlIGZvciB0aGUgYXJjaGl0
ZWN0dXJlIGRyYWZ0Lg0KPg0KPg0KPiAtLSBzbmlwIC0tDQo+DQo+DQo+IEJSDQo+DQo+IC9Ba2Jh
cg0KPg0KPg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBNYXJ0aW4gU3Rp
ZW1lcmxpbmcgW21haWx0bzptYXJ0aW4uc3RpZW1lcmxpbmdAbmVjbGFiLmV1XQ0KPiBTZW50OiBG
cmlkYXksIFNlcHRlbWJlciAyMSwgMjAxMiAxMDowOSBBTQ0KPiBUbzogUmFobWFuLCBBa2Jhcg0K
PiBDYzogS29uc3RhbnRpbm9zIFBlbnRpa291c2lzOyBkZWNhZGVAaWV0Zi5vcmcNCj4gU3ViamVj
dDogUmU6IFtkZWNhZGVdIFdHIEFjdGlvbjogQ29uY2x1c2lvbiBvZiBEZWNvdXBsZWQgQXBwbGlj
YXRpb24gRGF0YSBFbnJvdXRlIChkZWNhZGUpDQo+DQo+IEhpIEFrYmFyLA0KPg0KPiBPbiAwOS8y
MS8yMDEyIDAzOjIxIFBNLCBSYWhtYW4sIEFrYmFyIHdyb3RlOg0KPj4gVG8gQWxsLA0KPj4NCj4+
DQo+Pg0KPj4gSSBhbHNvIHdhbnQgdG8gbWFrZSBzb21lIHBvaW50cyBmb3IgdGhlIHJlY29yZDoN
Cj4+DQo+PiAtIEFzIGFuIGF1dGhvciwgSSBkbyBOT1QgZmVlbCB0aGF0IEkgd2FzIHBhcnQgb2Yg
YW55IGV4dGVuc2l2ZSBkaXNjdXNzaW9ucyByZWdhcmRpbmcgcG90ZW50aWFsIHNodXR0aW5nIGRv
d24gb2YgdGhlIERFQ0FERSBXRyBhbmQgZXNwZWNpYWxseSBzdG9wcGluZyB0aGUgY3VycmVudCBh
Y3RpdmUgV0cgZHJhZnRzIChlc3BlY2lhbGx5IHRoZSBBcmNoaXRlY3R1cmUgSS1EIHdoZXJlIEkg
d2FzIGFuIGF1dGhvcikuDQo+DQo+IFRhbGsgdG8geW91ciBjaGFpcnMgYW5kIGNvbnNpZGVyIHRo
YXQgdGhlIHJlcXVpcmVtZW50cyB3ZW50IGZyb20NCj4gcHVibGljYXRpb24gcmVxdWVzdGVkIChp
LmUuLCBvbiB0aGUgd2F5IHRvIHRoZSBJRVNHKSBiYWNrIHRvIHRoZSBXRw0KPiAoaS5lLiwgbm90
IG9uIHRoZSB3YXkgdG8gdGhlIElFU0cpLg0KPg0KPiBUaGUgc2FtZSBpcyB0cnVlIGZvciB0aGUg
YXJjaGl0ZWN0dXJlIGRyYWZ0Lg0KPg0KPj4NCj4+IC0gV2UgZGlkIGhhdmUgb25lIGx1bmNoIG1l
ZXRpbmcgaW4gVmFuY291dmVyIHdpdGggTWFydGluIGFuZCB0aGUgY2hhaXJzIGJ1dCB0aGF0IHdh
cyBwdWJsaWNseSBhbm5vdW5jZWQgYW5kIG9wZW4gdG8gYWxsIGluIHRoZSBXRy4gIEF0IHRoYXQg
bWVldGluZywgSSByZWNhbGwgTWFydGluIGFza2luZyB0aGUgYXR0ZW5kZWVzIGlmIHRoZXJlIHdh
cyBpbmR1c3RyeSBpbnRlcmVzdCBmb3IgdGhlIERFQ0FERSB3b3JrLiAgRnJvbSB3aGF0IEkgcmVj
YWxsLCBldmVyeW9uZSB0aGVyZSBkaWQgZXhwcmVzcyB2YXJpb3VzIGxldmVscyBvZiBpbnRlcmVz
dCBhbmQgc3VwcG9ydC4gIEkgZGlkbuKAmXQgaGVhciBhbnlvbmUgc2F5IHRoYXQgREVDQURFIHdh
cyBhICJ3YXN0ZWQgZWZmb3J0Ii4gU28sIGZyYW5rbHkgSSB3YXMgc3VycHJpc2VkIGFuZCBkaXNh
cHBvaW50ZWQgdG8gc2VlIHRoZSBXRyBzaHV0IGRvd24gc28gc3VkZGVubHkuICBJZiB0aGVyZSBy
ZWFsbHkgaXMgbm8gY29tbXVuaXR5IHN1cHBvcnQgdG8gY29udGludWUgd2l0aCB0aGUgYWN0aXZp
dHksIHRoZW4gc28gYmUgaXQuICBCdXQgeW91IGNhbm5vdCBjb25jbHVkZSB0aGF0IHRoZXJlIGlz
IG5vdCBpbnRlcmVzdCB3aXRob3V0IGZpcnN0IGhhdmluZyBhbiBvcGVuIGRpc2N1c3Npb24uDQo+
DQo+IFRvIGJlIGhvbmVzdGx5LCBidXQgZXhwcmVzc2luZyBpbnRlcmVzdCBhbmQgdHJhbnNmb3Jt
aW5nIGludGVyZXN0IHRvDQo+IHRlY2huaWNhbCBwcm9ncmVzcyBhcmUgdHdvIHZlcnkgZGlzdGlu
Y3QgYWN0aW9ucy4NCj4NCj4gSSBoYXZlIHNlZW4gYSBsb3Qgb2YgJ2V4cHJlc3NpbmcgaW50ZXJl
c3QnLCBidXQgdGhlIHRlY2huaWNhbCBwcm9ncmVzcw0KPiB3YXMgYW5kIGlzIGp1c3Qgbm90IHRo
ZXJlLg0KPg0KPiBJIGFsc28gdG9sZCBhdCB0aGUgbHVuY2ggbWVldGluZyBpbiBWYW5jb3V2ZXIg
dGhhdCBJIHdhbnQgdG8gc2VlIGFjdGlvbnMNCj4gb24gdGhlIHR3byBtYWluIGRyYWZ0cyBpbiB0
aGUgV0csIGkuZS4sIHRoZSByZXF1aXJlbWVudHMgYW5kIHRoZQ0KPiBhcmNoaXRlY3R1cmUuIFll
cyB0aGVyZSBoYXMgYmVlbiBhY3Rpb24sIGJ1dCB0aGUgdGVjaG5pY2FsIHF1YWxpdHkgb2YNCj4g
dGhlIGRyYWZ0cyBpcyBmYXIgZnJvbSBiZWluZyB1c2VmdWwgZm9yIGFueSBmdXJ0aGVyIHByb3Rv
Y29sIGRldmVsb3BtZW50Lg0KPiBTZWUgYWxzbyBteSBlbWFpbCB3aXRoIDIgZXhhbXBsZXMgb24g
aXNzdWVzIG5vdCBhZGRyZXNzZWQgaW4gbmVpdGhlciB0aGUNCj4gcmVxdWlyZW1lbnRzIG5vciB0
aGUgYXJjaGl0ZWN0dXJlIGRyYWZ0Lg0KPg0KPj4NCj4+IC0gSW4gdGVybXMgb2YgdGhlIGRvY3Vt
ZW50IHF1YWxpdHkuICBUaGUgZmlyc3QgZHJhZnQgb2YgdGhlIEFyY2hpdGVjdHVyZSBJLUQgd2Fz
IGluIE1hcmNoIDIwMTEuICBTaW5jZSB0aGVuIHdlIGhhdmUgZ290dGVuIGV4dGVuc2l2ZSBjb21t
ZW50cyBmcm9tIHZhcmlvdXMgZXhjZWxsZW50IHJldmlld2Vycy4gIEJ1dCBhcyBpcyBvZnRlbiB0
aGUgY2FzZSB3aGVuIHlvdSBoYXZlIG11bHRpcGxlIHJldmlld2VycywgeW91IHNvbWV0aW1lcyBn
ZXQgY29uZmxpY3RpbmcgZGlyZWN0aW9ucy4gIFNvbWUgcmV2aWV3ZXJzIHdhbnRlZCBhIGhpZ2gg
bGV2ZWwgYWJzdHJhY3QgYXJjaGl0ZWN0dXJlIHRoYXQgYXZvaWRlZCBhbGwgImltcGxlbWVudGF0
aW9uIiBkZXRhaWxzLiAgT3RoZXIgcmV2aWV3ZXJzIHdhbnRlZCBhIG1vcmUgZGV0YWlsZWQgYXBw
cm9hY2ggdGhhdCBnb3QgbW9yZSBpbnRvIHRoZSBkZXRhaWxzIG9mIHRoZSBwcm90b2NvbHMgYW5k
IGlubmVyIHdvcmtpbmdzIG9mIHRoZSBub2Rlcy4gIEkgcGVyc29uYWxseSB0cmllZCBpbiBhIGdv
b2QgZmFpdGggZWZmb3J0IHRvIGFkZHJlc3MgYWxsIHRoZSBjb21tZW50cyBhbmQgdG8gdHJ5IHRv
IHN0cmlrZSBhIGJhbGFuY2UgaW4gYWRkcmVzc2luZyB0aGUgcGhpbG9zb3BoaWVzIG9mIHRoZSBk
aWZmZXJlbnQgcmV2aWV3ZXJzLg0KPg0KPiBUaGUgYXJjaGl0ZWN0dXJlIGRyYWZ0cyBjbGVhcmx5
IGZhaWxzIHRvIHNob3cgdGhlIGFyY2hpdGVjdHVyZSBvZiB0aGUNCj4gREVDQURFIHByb3RvY29s
cy4gU2VlIG15IEFEIHJldmlldy4NCj4NCj4gWW91IGhhdmUgaW5kZWVkIHJlY2VpdmVkIGV4dGVu
c2l2ZSByZXZpZXdzLCBidXQgaXQgaXMgdXAgdG8gZGF0ZSBub3QNCj4gY2xlYXIgaWYgYW5kIGhv
dyB0aGV5IHdlcmUgYWRkcmVzc2VkLg0KPg0KPiBZb3UgY2FuIHNlZSBhbHNvIHRoaXMsIGFzIHRo
ZSBkcmFmdCB0YWxrcyBhYm91dCB0aGUgREVDQURFIHN5c3RlbSB3aGljaA0KPiBpcyBub3QgZXF1
YWwgdG8gdGhlIHByb3RvY29scy4NCj4NCj4+DQo+PiAtIEkgYWdyZWUgd2l0aCBLb3N0YXMgdGhh
dCBtYW55IGRvY3VtZW50cyBpbiBvdGhlciBXR3MgZ28gdGhyb3VnaCBzaW1pbGFyIGlzc3VlcyBi
dXQgYXQgdGhlIGVuZCBzdGlsbCBtYW5hZ2VkIHRvIHByb2R1Y2UgZ29vZCB3b3JrLg0KPg0KPiBZ
ZXMgYW5kIG5vLiBUaGVyZSBhcmUgZXhhbXBsZXMgaW4gYm90aCBkaXJlY3Rpb25zLCBzbyBpdCBk
b2Vzbid0IGhlbHANCj4gaGVyZSBpbiB0aGlzIHBhcnRpY3VsYXIgY2FzZS4NCj4NCj4+DQo+PiAt
IFRvIGNvbmNsdWRlLCBJIGRldm90ZWQgaW4gZ29vZCBmYWl0aCBhIGZhaXIgYW1vdW50IG9mIG15
IGVuZXJneSB0byBwYXJ0aWNpcGF0ZSBpbiBhZHZhbmNpbmcgdGhlIHRvcGljcyBpbiB0aGUgV0cg
c2luY2UgdGhlIGZpcnN0IHNlc3Npb24gYmFjayBpbiBBbmFoZWltLiAgSSBkZWZlciB0byB0aGUg
aGlnaGVyIHBvd2VycyB0byBtYWtlIHRoZSBkZWNpc2lvbiBvbiBjbG9zaW5nIHRoZSBERUNBREUg
V0cgb3Igbm90LiAgSG93ZXZlciwgSSBjbGVhcmx5IHdhbnQgdG8gc3RhdGUgdGhhdCBJIHRoaW5r
IGl0IHdhcyB1bmZvcnR1bmF0ZSB0byBhbHNvIHN1ZGRlbmx5IHRlcm1pbmF0ZSB0aGUgREVDQURF
IEFyY2hpdGVjdHVyZSBJLUQgd2hpY2ggd2FzIGJlaW5nIGV4dGVuc2l2ZWx5IHJldmlzZWQgd2hl
bmV2ZXIgd2UgZ290IHJldmlld2VyIGNvbW1lbnRzLiAgSSB1bmRlcnN0YW5kIGlmIHBlb3BsZSBh
cmUgc2F5aW5nIHRoYXQgbW9yZSB3b3JrIGhhcyB0byBiZSBkb25lIHRvIGdldCBpdCB0byBwdWJs
aWNhdGlvbiBzdGF0ZS4gIEJ1dCB0aGF0IGRvZXMgbm90IHdhcnJhbnQsIGluIG15IG9waW5pb24s
IHRvIGp1c3Qgc2h1dCBkb3duIHRoZSB3b3JrLiAgSG9uZXN0bHksIGlmIHlvdSB1c2UgdGhhdCBj
cml0ZXJpYSB0aGVyZSB3b3VsZCBiZSBtYW55IFdHIGRvY3VtZW50cyBpbiBvdGhlciBncm91cHMg
dGhhdCBzaG91bGQgYWxzbyBiZSBhYnJ1cHRseSBzaHV0IGRvd24uDQo+DQo+IEkgd29uZGVyIHdo
eSB0aGVyZSBpcyBzbyBtdWNoIGNhcmUgYWJvdXQgb3RoZXIgZ3JvdXBzPyBUaGlzIGlzIGFib3V0
DQo+IERFQ0FERSBub3QgYW55IG90aGVyIGFyYml0cmFyeSBncm91cCBzb21ld2hlcmUgZWxzZS4N
Cj4NCj4gV2l0aCByZXNwZWN0IHRvIHRoZSBlbmVyZ3k6DQo+IElmIHBlb3BsZSBzdGlsbCBiZWxp
ZXZlIGluIERFQ0FERSwgdGFrZSB0aGUgZG9jdW1lbnRzLCBhZGRyZXNzIHRoZQ0KPiByZXZpZXdz
LCBnZXQgcmV2aWV3cyBhbmQgZ28gZm9yIHRoZSBJbmRlcGVuZGVudCBTdHJlYW0gc3VibWlzc2lv
biB3aXRoDQo+IHRoZSBSRkMgZWRpdG9yLg0KPg0KPiBSZWdhcmRzLA0KPg0KPiAgICAgTWFydGlu
DQo+DQo+Pg0KPj4NCj4+IFJlc3BlY3RmdWxseSwNCj4+DQo+Pg0KPj4gQWtiYXINCj4+DQo+PiAt
LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4gRnJvbTogZGVjYWRlLWJvdW5jZXNAaWV0Zi5v
cmcgW21haWx0bzpkZWNhZGUtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEtvbnN0YW50
aW5vcyBQZW50aWtvdXNpcw0KPj4gU2VudDogRnJpZGF5LCBTZXB0ZW1iZXIgMjEsIDIwMTIgODox
NSBBTQ0KPj4gVG86IE1hcnRpbiBTdGllbWVybGluZzsgZGVjYWRlQGlldGYub3JnDQo+PiBTdWJq
ZWN0OiBSZTogW2RlY2FkZV0gV0cgQWN0aW9uOiBDb25jbHVzaW9uIG9mIERlY291cGxlZCBBcHBs
aWNhdGlvbiBEYXRhIEVucm91dGUgKGRlY2FkZSkNCj4+DQo+PiBEZWFyIE1hcnRpbiwgQWxsLA0K
Pj4NCj4+ICAgICB8VGhlIERFQ0FERSB3b3JraW5nIGdyb3VwIGhhcyBqdXN0IGJlZW4gY2xvc2Vk
IGJ5IHlvdXIgcmVzcG9uc2libGUgQXJlYQ0KPj4gICAgIHxEaXJlY3Rvci4NCj4+ICAgICB8DQo+
PiAgICAgfFRoaXMgbWF5IGNvbWUgYXMgYSBzdXJwcmlzZSB0byBzb21lIGluIHRoZSBXRw0KPj4N
Cj4+IEluZGVlZCwgaXQgaGFzIGJlZW4gYSBzdXJwcmlzZS4NCj4+DQo+PiAgICAgfCBidXQgaXQg
c2hvdWxkIG5vdCBiZSBhIHN1cnByaXNlIGZvciB0aGUgd29ya2luZyBkcmFmdHMgYXV0aG9ycw0K
Pj4NCj4+IFRoYXQncyBmaW5lLCBidXQgSSB0aGluayBzb21lIHNvcnQgb2YgYW5ub3VuY2VtZW50
IChhbmQgZXZlbiBiZXR0ZXIgYSBkaXNjdXNzaW9uKSBzaG91bGQgaGF2ZSBiZWVuIGNpcmN1bGF0
ZWQgcHJpb3IgdG8gdGhlIElFU0cgYW5ub3VuY2VtZW50LiBJJ20gbm90IGludGVyZXN0ZWQgaW50
byBfd2hvXyBzaG91bGQgaGF2ZSBkb25lIHRoaXMuIEl0J3MgdG9vIGxhdGUgYW5kLCBpbiB0aGUg
ZW5kLCBpcnJlbGV2YW50IGF0IHRoaXMgc3RhZ2UuIEJ1dCB0aGVyZSdzIGFuIG9yZGVyIG9mIG1h
Z25pdHVkZSBtb3JlIHBlb3BsZSBvbiB0aGlzIG1haWxpbmcgbGlzdCB0aGFuIGluIHRoZSBhdXRo
b3IgbGluZSBvZiBhbGwgZHJhZnRzIHRvZ2V0aGVyLiBJIHdvdWxkIGNvbnNpZGVyIHRoaXMgYSBi
cmVha2Rvd24gaW4gY29tbXVuaWNhdGlvbiBiZXR3ZWVuIHRoZSBpbm5lci0gYW5kIG91dGVyLWNp
cmNsZS4gVGhpcyB3YXMgZmFyIGZyb20gd2hhdCwgaW4gZ2VuZXJhbCwgSSB3b3VsZCBjYWxsIGEg
ImdyYWNlZnVsIHRlYXJkb3duIi4NCj4+DQo+PiAgICAgfCBCb3RoIGRyYWZ0cyBkbyBsZWF2ZSBh
bnkgbnVtYmVyIG9mIGtleSBxdWVzdGlvbnMgdW5hbnN3ZXJlZA0KPj4NCj4+IEkgZG8gYWdyZWUg
d2l0aCBtb3N0IG9mIHlvdXIgdGVjaG5pY2FsIGNvbW1lbnRzLiBJIHNlbnQgcmV2aWV3cyBvbiBi
b3RoIGRvY3VtZW50cyBlYXJsaWVyLiBUaGF0IHNhaWQsIGltbywgdGhpcyBhY3Rpb24gd2FzIGEg
Yml0IGFicnVwdC4gSSBkbyByZWNhbGwgYSBmZXcgZ3JvdXBzIHRoYXQgd2VyZSBtdWNoIGxhdGVy
IGluIHRoZWlyIHRpbWVsaW5lcyB0aGFuIGRlY2FkZSBpcyBub3csIGFuZCB0aGV5IHN0aWxsIG1h
bmFnZWQgdG8gZG8gZGVjZW50IHdvcmsgYWZ0ZXIgYSAocHJvbG9uZ2VkKSBzbG93IHN0YXJ0Lg0K
Pj4NCj4+IEluIGFueSBjYXNlLCBJIHJlc3BlY3QgeW91ciBkZWNpc2lvbiwgYnV0IEkgZG8gbm90
IHNlY29uZCBpdC4NCj4+DQo+PiBCZXN0IFJlZ2FyZHMsDQo+Pg0KPj4gS29zdGFzDQo+Pg0KPj4N
Cj4NCg0KLS0gDQptYXJ0aW4uc3RpZW1lcmxpbmdAbmVjbGFiLmV1DQoNCk5FQyBMYWJvcmF0b3Jp
ZXMgRXVyb3BlIC0gTmV0d29yayBSZXNlYXJjaCBEaXZpc2lvbiBORUMgRXVyb3BlIExpbWl0ZWQN
ClJlZ2lzdGVyZWQgT2ZmaWNlOiBORUMgSG91c2UsIDEgVmljdG9yaWEgUm9hZCwgTG9uZG9uIFcz
IDZCTA0KUmVnaXN0ZXJlZCBpbiBFbmdsYW5kIDI4Mw0K

From yry@cs.yale.edu  Mon Sep 24 08:16:39 2012
Return-Path: 
X-Original-To: decade@ietfa.amsl.com
Delivered-To: decade@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79D9D21F87CF for ; Mon, 24 Sep 2012 08:16:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, 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 cMQ3RGLdLH1T for ; Mon, 24 Sep 2012 08:16:29 -0700 (PDT)
Received: from vm-emlprdomr-11.its.yale.edu (vm-emlprdomr-11.its.yale.edu [130.132.50.177]) by ietfa.amsl.com (Postfix) with ESMTP id BBE4421F87C5 for ; Mon, 24 Sep 2012 08:16:27 -0700 (PDT)
Received: from dhcp-128-36-55-174.central.yale.edu (dhcp-128-36-55-174.central.yale.edu [128.36.55.174]) (authenticated bits=0) by vm-emlprdomr-11.its.yale.edu (8.14.4/8.14.4) with ESMTP id q8OFGOZR025534 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 24 Sep 2012 11:16:25 -0400
Message-ID: <50607948.6060002@cs.yale.edu>
Date: Mon, 24 Sep 2012 11:16:24 -0400
From: "Y. Richard Yang" 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1
MIME-Version: 1.0
To: Martin Stiemerling 
References: <20120919230313.17329.44102.idtracker@ietfa.amsl.com> <505AE794.8070304@neclab.eu> <505C7772.3070503@cs.yale.edu> <50602997.6090201@neclab.eu>
In-Reply-To: <50602997.6090201@neclab.eu>
Content-Type: multipart/alternative; boundary="------------050407030700070505060005"
X-Scanned-By: MIMEDefang 2.71 on 130.132.50.177
Cc: decade@ietf.org
Subject: Re: [decade] WG Action: Conclusion of Decoupled Application Data Enroute (decade)
X-BeenThere: decade@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 24 Sep 2012 15:16:39 -0000

This is a multi-part message in MIME format.
--------------050407030700070505060005
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

On 9/24/12 5:36 AM, Martin Stiemerling wrote:
> Hi Richard,
>
> On 09/21/2012 04:19 PM, Y. Richard Yang wrote:
> [...]
>>
>>> though there are a number of issues that should have been discussed.
>>>
>>> The WG chairs were explicitly notified in mid of June that there are
>>> severe issues and the WG had time to address those issues. However, it
>>> must have been obvious even before mid of June that there are severe
>>> issues, i.e., there has been sufficient time to fix it.
>>>
>>> Furthermore, the requirements and architecture draft were submitted to
>>> the IESG for publication and both drafts have been returned to the WG,
>>> as both are not ready to be published as RFC.
>>> You can find the AD review in the datatracker:
>>> - https://datatracker.ietf.org/doc/draft-ietf-decade-reqs/history/
>>> - https://datatracker.ietf.org/doc/draft-ietf-decade-arch/history/
>>>
>> Your preceding AD reviews are extensive. But I think the main criticism
>> is writing/English/organization problems, not technical problems.
>
> No, it isn't!
> The criticisms are about technical issues in the sense that it is not 
> clear what DECADE is exactly looking like in many parts 
This could be a useful discussion on the mailing list, before the 
closure of the WG. From my personal point of view, requirements and 
architecture do not specify "exactly looking". My personal design 
approach is that if I can see two reasonable design approaches to 
satisfy one req, I will resist strongly to specify one.

> and also many requirements are not correct or incomplete.

It can helpful if you point out which part is "not correct".

> This is not about language or organizational issues, but it is about 
> technical issues, though that there are organizational issues, e.g., 
> listing new requirements in the architecture.
>
>>
>>> Both drafts do leave any number of key questions unanswered, i.e.,
>>> they are far away from being technically useful to be the base for the
>>> next steps in the protocol development.
>>>
>>> To give 2 examples:
>>> 1)
>>> It is completely unclear how the resources on a DECADE server are
>>> supposed to be managed
>> The basic design principles are stated in Sec. 4.4 and 4.5 of -arch:
>> Explicit Control and Delegation, with sentences such as
>>
>> "Storage Providers will have the ability to explicitly manage the
>>     entities allowed to utilize the resources at a DECADE-compatible
>>     server.  This capability is needed for reasons such as capacity-
>>     planning and legal considerations in certain deployment scenarios."
>
> This is a high-level description that does not add anything to 
> question on how it will be managed.
>
This is not an empty requirement--it rules out non-managed caches, and 
hence is a step in answering the management issue.

>>
>> "Content Providers are able to explicitly and independently manage their
>> own shares of resources on a server."
>
> Nice, but how? The 'how' is about how on the conceptual level and not 
> yet on the protocol detail level.
>
We list requirements, not how to satisfy the requirements. We resisted 
strongly to specify how. But even so, the documents suggested some 
'how'. A related 'how' for this:


      8.3 Distributed Resource Sharing Specification



    REQUIREMENT(S):  A Provider MUST be able to indicate to its DECADE-
        compatible server, without itself contacting the server, resource
        control policies for a Consumer.  The DECADE-compatible server
        MUST be able to authenticate the resource control policies.


RATIONALE:  One important consideration for a DECADE-compatible
        server is scalability, since a single storage element may be used
        to support many users.  Many Target Applications use small chunk
        sizes and frequent data exchanges.  If such an application
        employed resource control and contacted the DECADE-compatible
        server for each data exchange, this could present a scalability
        challenge for the server as well as additional latency for
        clients.

        The preferred way is to let requesting clients obtain signed
        resource control policies (in the form of a token) from the
        owning client, and then requesting clients can present the policy
        to a DECADE-compatible server directly.  This can result in
        reduced messaging handled by the DECADE-compatible server.


As another example, see Figure 2 of -arch.

>>
>> "The client can in turn share the
>>     granted resources amongst its multiple applications.  The share of
>>     resources granted by a server is called a User Delegation."
>
> Sure, that seems to be a glimpse of a concept, but how does the DECADE 
> server distinguish the applications? Or this is handled solely by the 
> client?
There are multiple design options: distinguish between the apps, or not 
(app is a higher level concept that needs to be managed by an App only). 
A first design distinguished (by explicitly introducing App ID), and a 
later did not. Either way can work. We do not rule out such design options.
> Each of these paragraphs opens up many questions, which are never 
> answered.
>
I look at it differently: they specify requirements/goals, now how. What 
is opened up is not questions, are design options. Like I said: My 
personal design approach is that if I can see two reasonable approaches 
to satisfy one req, I will resist strongly to specify one.

>>
>> "As a simple example, a DECADE-compatible server operated by an ISP
>>     might be configured to grant each ISP Subscriber 1.5 Mbit/s of
>>     bandwidth.  The ISP Subscriber might in turn divide this share of
>>     resources amongst a video streaming application and file-sharing
>>     application which are running concurrently."
>
> Again nice, but how is this done on a conceptual level? What the 
> measures in the requirements to ensure this?
> For instance, how would expect that an ISP subscriber is identified?
>

      2.4 DECADE Account



    An account of a DECADE-compatible server has associated cryptographic
    credentials for access control, and resource allocation attributes on
    the server.

>>
>> In -req:
>> - Multiple Applications Sharing Resources
>>
>>
>> "REQUIREMENT(S):  A client MUST be able to indicate to a DECADE-
>>         compatible server about resource sharing policies among multiple
>>         Target Applications being run/managed by the same client."
>
> But how exactly does the client indicate this and where? How are the 
> target applications announced to the server and distinguished during 
> operations?
There are multiple options: a control channel, or piggy backed on data 
requests.  See preceding text for Sec. 8.3. Regarding the need to 
distinguish apps or not, see preceding on the two design options.

> It is clear that the requirements do not specify all the bits and 
> bytes of the protocol, but writing a high-level requirement is not 
> sufficient at all.
>
>>
>> - Per-Client Resource Policy
>>
>> "REQUIREMENT(S):  A Provider MUST be able to specify resource policies
>>         (bandwidth share, storage quota, and network connection 
>> quota) to
>>         individual Consumers for reading from and writing data to its 
>> in-
>>         network storage within a particular range of time."
>
> This is underspecified: What is the policy for bandwidth share that is 
> expected to be implemented by a protocol? Is it 10 % of my outgoing 
> link capacity or is it a maximum throughput in x bits per second? What 
> is expected here?
This is very intentionally left open. The authors tried hard to leave 
the design space open. A design option considered your quesions is:
http://conferences.sigcomm.org/sigcomm/2012/paper/icn/p25.pdf
co-authors by the doc authors. See Sec. 4 of the paper. The authors felt 
strongly that IETF should allow other design options, instead of their 
own designs. Hence, they publish a paper on there design, instead of 
putting them in -req so that only their design is OK.
> And does this related to multiple customers? How is such a customer 
> identified?
>
See preceding text on Sec. 2.4 DECADE account and the mention on crypto 
credential.
>
>>
>>
>> - Distributed Resource Sharing Specification
>> REQUIREMENT(S):  A Provider MUST be able to indicate to its DECADE-
>>         compatible server, without itself contacting the server, 
>> resource
>>         control policies for a Consumer.  The DECADE-compatible server
>>         MUST be able to authenticate the resource control policies.
>>
>>
>> - Resource Set
>> REQUIREMENT(S):  A DECADE-compatible server MUST allow specification
>>         on the following resources: storage, bandwidth, and number of
>>         connections, and MAY allow additional types of resources to be
>>         specified.
>>
>>
>> ...
>>
>>> and how this management is mapped to the protocol split of SDT, DRP,
>>> and other management protocols.
>>> Parts of it, such as setting the permissions of data objects clearly
>>> belongs to the DRP, and it is sort of stated in a vague way in the
>>> architecture, but it is not documented in a comprehensive way.
>
> You say it correctly: 'vague way' and 'not documented in a 
> comprehensive way.'
> This is one of the main points that it is all to vague.
>
Like I said. I have different opinions on how -req and -arch should be 
specified.
I am a minimalist and prefer a larger design space for protocol.

>>
>> The documents intentionally stayed vague as the understanding was that
If I could, I would change:
s/stayed vague/leave as much design space as possible/

>> they are not solution-specifying protocol documents. Some authors have a
>> lot more details on resource management, e.g., the recent SIGCOMM ICN'12
>> paper (http://conferences.sigcomm.org/sigcomm/2012/paper/icn/p25.pdf)
>> discusses using a hierarchical weighted sharing scheme for resource
>> sharing and how to encode them in tokens. But the authors discussed the
>> issues intensively, considered this to be too solution specific, and
>> intentionally left them over to allow a larger design space to allow
>> better participation.
>
> The requirements and the architecture can get specific without 
> detailing what the bits and bytes of the protocol are. 

I share this point, and I think that the docs tried to get as specific 
as possible, and but leave as much design space possible as well. It is 
a tradeoff. If you have strong opinions, please discuss on the mailing 
list. Constructive opinions can be particularly valuable, e.g., you feel 
strongly that each client/app is assigned a unique clientID/AppID and 
then we can discuss.

> This is what it is actually needed to design a proper protocol later on!

>>
>>> Other parts, such as the accounting is probably not part of the the
>>> DRP nor SDT, but there is supposedly another interface that is needed
>>> for this.
>>>
>>> 2)
>>> What is the model how data objects are handled on the server in the
>>> sense about who is allowed to do what?
>>> The drafts solely talk about tokens to be used to do access control.
>>> But there other aspects, for instance, who is controlling what on a
>>> DECADE server: The DECADE server can be operated by an ISP, but the
>>> content is provided by a content provider and it is access by an
>>> unlimited set of clients or limited set of clients.
>> Limited set of clients. See -req: "
>>
>> REQUIREMENT(S):  A Provider MUST be able to control which individual
>>         clients are authorized to read/write which particular data
>>         objects from/to its in-network storage.
>>
>>     RATIONALE:  A Target Application should able to conduct access
>>         control on the granularity of individual clients, individual 
>> data
>>         objects."
>
> Those are really high-level requirements that do not saying too much 
> about how the protocol should look like in the end. 
It does say a lot and answered your question: by an unlimited set of 
clients or limited set. There are multiple design options, control 
channel setting ACL or token, etc. The doc suggested token, but did not 
make it a requirement.

> For instance, a main use case for this is bittorrent. There are no 
> clients that can be easily identified and authorized. How is this 
> handled?
>
The bittorren software client needs to be changed (e.g., with a plugin) 
and the user needs to specify DECADE account(s) that the software client 
can use. A recent design option being evaluated is to use OAuth.

> One way would be that the management protocol, which is not specified 
> in the requirements or architecture, is used to limited the IP 
> addresses that are allowed to access such a DECADE server. This would 
> be a requirement!
>
Setting up allowed IP address is an approximate way to implement the 
specified client-level access-control requirement.  The existing 
requirement is checkable.

>>
>>
>>
>>> How is the access control divided between those parties?
>> Mostly by clients, but with the exception that ISP has a say when:
>> -req Sec. 9:
>> 9.1.  Illegal Data Object
>>
>>     REQUIREMENT(S):  A DECADE-compatible server SHOULD provide an error
>>         indicating that (1) data was rejected from being written, (2)
>>         deleted, or (3) marked unavailable.
>>
>>     RATIONALE:  DECADE Storage Providers may require the ability to (1)
>>         avoid storing, (2) delete, or (3) quarantine certain data that
>>         has been identified as illegal (or otherwise prohibited).  It is
>>         not specified how such data is identified, but applications
>>         employing DECADE-compatible servers should not break if a 
>> Storage
>>         Provider is obligated to enforce such policies. Appropriate
>>         error conditions should be indicated to applications.
>>
>>     EXCEPTION:  A DECADE-compatible server should be able to be
>>         configured to suppress Illegal Data Object responses for 
>> security
>>         reasons.
>
> Those requirements do not answer my question about access control is 
> divided between the parties.
>
I think it does. User Delegation means that users are the boss. Storage 
Provider can interject but need to provide error messages. This was 
discussed in the WG and agreed upon.

Richard

>
>   Martin
>

--------------050407030700070505060005
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
On 9/24/12 5:36 AM, Martin Stiemerling
      wrote:

    

    
Hi
      Richard,
      

      

      On 09/21/2012 04:19 PM, Y. Richard Yang wrote:
      

      [...]
      

      

        

        
though there are a number of issues that
          should have been discussed.
          

          

          The WG chairs were explicitly notified in mid of June that
          there are
          

          severe issues and the WG had time to address those issues.
          However, it
          

          must have been obvious even before mid of June that there are
          severe
          

          issues, i.e., there has been sufficient time to fix it.
          

          

          Furthermore, the requirements and architecture draft were
          submitted to
          

          the IESG for publication and both drafts have been returned to
          the WG,
          

          as both are not ready to be published as RFC.
          

          You can find the AD review in the datatracker:
          

          -
          https://datatracker.ietf.org/doc/draft-ietf-decade-reqs/history/
          

          -
          https://datatracker.ietf.org/doc/draft-ietf-decade-arch/history/
          

          

        

        Your preceding AD reviews are extensive. But I think the main
        criticism
        

        is writing/English/organization problems, not technical
        problems.
        

      

      

      No, it isn't!
      

      The criticisms are about technical issues in the sense that it is
      not clear what DECADE is exactly looking like in many parts 

    This could be a useful discussion on the mailing list, before the
    closure of the WG. From my personal point of view, requirements and
    architecture do not specify "exactly looking". My personal design
    approach is that if I can see two reasonable design approaches to
    satisfy one req, I will resist strongly to specify one. 

    

    
and
      also many requirements are not correct or incomplete.
      

    

    

    It can helpful if you point out which part is "not correct".

    

    
This
      is not about language or organizational issues, but it is about
      technical issues, though that there are organizational issues,
      e.g., listing new requirements in the architecture.
      

      

      

        

        
Both drafts do leave any number of key
          questions unanswered, i.e.,
          

          they are far away from being technically useful to be the base
          for the
          

          next steps in the protocol development.
          

          

          To give 2 examples:
          

          1)
          

          It is completely unclear how the resources on a DECADE server
          are
          

          supposed to be managed
          

        

        The basic design principles are stated in Sec. 4.4 and 4.5 of
        -arch:
        

        Explicit Control and Delegation, with sentences such as
        

        

        "Storage Providers will have the ability to explicitly manage
        the
        

            entities allowed to utilize the resources at a
        DECADE-compatible
        

            server.  This capability is needed for reasons such as
        capacity-
        

            planning and legal considerations in certain deployment
        scenarios."
        

      

      

      This is a high-level description that does not add anything to
      question on how it will be managed.
      

      

    

    This is not an empty requirement--it rules out non-managed caches,
    and hence is a step in answering the management issue.

    

    

      

        

        "Content Providers are able to explicitly and independently
        manage their
        

        own shares of resources on a server."
        

      

      

      Nice, but how? The 'how' is about how on the conceptual level and
      not yet on the protocol detail level.
      

      

    

    We list requirements, not how to satisfy the requirements. We
    resisted strongly to specify how. But even so, the documents
    suggested some 'how'. A related 'how' for this:

    

    
    
8.3 Distributed Resource Sharing Specification


   REQUIREMENT(S):  A Provider MUST be able to indicate to its DECADE-
       compatible server, without itself contacting the server, resource
       control policies for a Consumer.  The DECADE-compatible server
       MUST be able to authenticate the resource control policies.

    

    
    
RATIONALE:  One important consideration for a DECADE-compatible
       server is scalability, since a single storage element may be used
       to support many users.  Many Target Applications use small chunk
       sizes and frequent data exchanges.  If such an application
       employed resource control and contacted the DECADE-compatible
       server for each data exchange, this could present a scalability
       challenge for the server as well as additional latency for
       clients.

       The preferred way is to let requesting clients obtain signed
       resource control policies (in the form of a token) from the
       owning client, and then requesting clients can present the policy
       to a DECADE-compatible server directly.  This can result in
       reduced messaging handled by the DECADE-compatible server.

    

    As another example, see Figure 2 of -arch.

    

    

      

        

        "The client can in turn share the
        

            granted resources amongst its multiple applications.  The
        share of
        

            resources granted by a server is called a User Delegation."
        

      

      

      Sure, that seems to be a glimpse of a concept, but how does the
      DECADE server distinguish the applications? Or this is handled
      solely by the client?
      

    

    There are multiple design options: distinguish between the apps, or
    not (app is a higher level concept that needs to be managed by an
    App only). A first design distinguished (by explicitly introducing
    App ID), and a later did not. Either way can work. We do not rule
    out such design options.

    
Each
      of these paragraphs opens up many questions, which are never
      answered.
      

      

    

    I look at it differently: they specify requirements/goals, now how.
    What is opened up is not questions, are design options. Like I said:
    My personal design approach is that if I can see two reasonable
    approaches to satisfy one req, I will resist strongly to specify
    one. 

    

    

      

        

        "As a simple example, a DECADE-compatible server operated by an
        ISP
        

            might be configured to grant each ISP Subscriber 1.5 Mbit/s
        of
        

            bandwidth.  The ISP Subscriber might in turn divide this
        share of
        

            resources amongst a video streaming application and
        file-sharing
        

            application which are running concurrently."
        

      

      

      Again nice, but how is this done on a conceptual level? What the
      measures in the requirements to ensure this?
      

      For instance, how would expect that an ISP subscriber is
      identified?
      

      

    

    
    
2.4 DECADE Account


   An account of a DECADE-compatible server has associated cryptographic
   credentials for access control, and resource allocation attributes on
   the server.



    

      

        

        In -req:
        

        - Multiple Applications Sharing Resources
        

        

        

        "REQUIREMENT(S):  A client MUST be able to indicate to a DECADE-
        

                compatible server about resource sharing policies among
        multiple
        

                Target Applications being run/managed by the same
        client."
        

      

      

      But how exactly does the client indicate this and where? How are
      the target applications announced to the server and distinguished
      during operations?
      

    

    There are multiple options: a control channel, or piggy backed on
    data requests.  See preceding text for Sec. 8.3. Regarding the need
    to distinguish apps or not, see preceding on the two design options.

    

    
It is
      clear that the requirements do not specify all the bits and bytes
      of the protocol, but writing a high-level requirement is not
      sufficient at all.
      

      

      

        

        - Per-Client Resource Policy
        

        

        "REQUIREMENT(S):  A Provider MUST be able to specify resource
        policies
        

                (bandwidth share, storage quota, and network connection
        quota) to
        

                individual Consumers for reading from and writing data
        to its in-
        

                network storage within a particular range of time."
        

      

      

      This is underspecified: What is the policy for bandwidth share
      that is expected to be implemented by a protocol? Is it 10 % of my
      outgoing link capacity or is it a maximum throughput in x bits per
      second? What is expected here?
      

    

    This is very intentionally left open. The authors tried hard to
    leave the design space open. A design option considered your
    quesions is:

    http://conferences.sigcomm.org/sigcomm/2012/paper/icn/p25.pdf

    co-authors by the doc authors. See Sec. 4 of the paper. The authors
    felt strongly that IETF should allow other design options, instead
    of their own designs. Hence, they publish a paper on there design,
    instead of putting them in -req so that only their design is OK.

    
And
      does this related to multiple customers? How is such a customer
      identified?
      

      

    

    See preceding text on Sec. 2.4 DECADE account and the mention on
    crypto credential.

    

      

      

        

        

        - Distributed Resource Sharing Specification
        

        REQUIREMENT(S):  A Provider MUST be able to indicate to its
        DECADE-
        

                compatible server, without itself contacting the server,
        resource
        

                control policies for a Consumer.  The DECADE-compatible
        server
        

                MUST be able to authenticate the resource control
        policies.
        

        

        

        - Resource Set
        

        REQUIREMENT(S):  A DECADE-compatible server MUST allow
        specification
        

                on the following resources: storage, bandwidth, and
        number of
        

                connections, and MAY allow additional types of resources
        to be
        

                specified.
        

        

        

        ...
        

        

        
and how this management is mapped to the
          protocol split of SDT, DRP,
          

          and other management protocols.
          

          Parts of it, such as setting the permissions of data objects
          clearly
          

          belongs to the DRP, and it is sort of stated in a vague way in
          the
          

          architecture, but it is not documented in a comprehensive way.
          

        

      

      

      You say it correctly: 'vague way' and 'not documented in a
      comprehensive way.'
      

      This is one of the main points that it is all to vague.
      

      

    

    Like I said. I have different opinions on how -req and -arch should
    be specified. 

    I am a minimalist and prefer a larger design space for protocol.

    

    

      

        

        The documents intentionally stayed vague as the understanding
        was that
        

      

    

    If I could, I would change:

    s/stayed vague/leave as much design space as possible/

    

    

      
they are not solution-specifying protocol
        documents. Some authors have a
        

        lot more details on resource management, e.g., the recent
        SIGCOMM ICN'12
        

        paper
        (http://conferences.sigcomm.org/sigcomm/2012/paper/icn/p25.pdf)
        

        discusses using a hierarchical weighted sharing scheme for
        resource
        

        sharing and how to encode them in tokens. But the authors
        discussed the
        

        issues intensively, considered this to be too solution specific,
        and
        

        intentionally left them over to allow a larger design space to
        allow
        

        better participation.
        

      

      

      The requirements and the architecture can get specific without
      detailing what the bits and bytes of the protocol are. 

    

    I share this point, and I think that the docs tried to get as
    specific as possible, and but leave as much design space possible as
    well. It is a tradeoff. If you have strong opinions, please discuss
    on the mailing list. Constructive opinions can be particularly
    valuable, e.g., you feel strongly that each client/app is assigned a
    unique clientID/AppID and then we can discuss. 

    

    
This
      is what it is actually needed to design a proper protocol later
      on!
      

    

    

    

      

        

        
Other parts, such as the accounting is
          probably not part of the the
          

          DRP nor SDT, but there is supposedly another interface that is
          needed
          

          for this.
          

          

          2)
          

          What is the model how data objects are handled on the server
          in the
          

          sense about who is allowed to do what?
          

          The drafts solely talk about tokens to be used to do access
          control.
          

          But there other aspects, for instance, who is controlling what
          on a
          

          DECADE server: The DECADE server can be operated by an ISP,
          but the
          

          content is provided by a content provider and it is access by
          an
          

          unlimited set of clients or limited set of clients.
          

        

        Limited set of clients. See -req: "
        

        

        REQUIREMENT(S):  A Provider MUST be able to control which
        individual
        

                clients are authorized to read/write which particular
        data
        

                objects from/to its in-network storage.
        

        

            RATIONALE:  A Target Application should able to conduct
        access
        

                control on the granularity of individual clients,
        individual data
        

                objects."
        

      

      

      Those are really high-level requirements that do not saying too
      much about how the protocol should look like in the end. 

    It does say a lot and answered your question: by an unlimited set of
    clients or limited set. There are multiple design options, control
    channel setting ACL or token, etc. The doc suggested token, but did
    not make it a requirement.

    

    
For
      instance, a main use case for this is bittorrent. There are no
      clients that can be easily identified and authorized. How is this
      handled?
      

      

    

    The bittorren software client needs to be changed (e.g., with a
    plugin) and the user needs to specify DECADE account(s) that the
    software client can use. A recent design option being evaluated is
    to use OAuth.

    

    
One
      way would be that the management protocol, which is not specified
      in the requirements or architecture, is used to limited the IP
      addresses that are allowed to access such a DECADE server. This
      would be a requirement!
      

      

    

    Setting up allowed IP address is an approximate way to implement the
    specified client-level access-control requirement.  The existing
    requirement is checkable.

    

    

      

        

        

        

        
How is the access control divided
          between those parties?
          

        

        Mostly by clients, but with the exception that ISP has a say
        when:
        

        -req Sec. 9:
        

        9.1.  Illegal Data Object
        

        

            REQUIREMENT(S):  A DECADE-compatible server SHOULD provide
        an error
        

                indicating that (1) data was rejected from being
        written, (2)
        

                deleted, or (3) marked unavailable.
        

        

            RATIONALE:  DECADE Storage Providers may require the ability
        to (1)
        

                avoid storing, (2) delete, or (3) quarantine certain
        data that
        

                has been identified as illegal (or otherwise
        prohibited).  It is
        

                not specified how such data is identified, but
        applications
        

                employing DECADE-compatible servers should not break if
        a Storage
        

                Provider is obligated to enforce such policies. 
        Appropriate
        

                error conditions should be indicated to applications.
        

        

            EXCEPTION:  A DECADE-compatible server should be able to be
        

                configured to suppress Illegal Data Object responses for
        security
        

                reasons.
        

      

      

      Those requirements do not answer my question about access control
      is divided between the parties.
      

      

    

    I think it does. User Delegation means that users are the boss.
    Storage Provider can interject but need to provide error messages.
    This was discussed in the WG and agreed upon.

    

    Richard

    

    

      

        Martin
      

      

    

  


--------------050407030700070505060005--

From yry@cs.yale.edu  Mon Sep 24 08:20:03 2012
Return-Path: 
X-Original-To: decade@ietfa.amsl.com
Delivered-To: decade@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15C6021F87C5 for ; Mon, 24 Sep 2012 08:20:03 -0700 (PDT)
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=[AWL=0.000,  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 JZJLzuvBHkjl for ; Mon, 24 Sep 2012 08:20:02 -0700 (PDT)
Received: from vm-emlprdomr-11.its.yale.edu (vm-emlprdomr-11.its.yale.edu [130.132.50.177]) by ietfa.amsl.com (Postfix) with ESMTP id 864D321F87AA for ; Mon, 24 Sep 2012 08:20:01 -0700 (PDT)
Received: from dhcp-128-36-55-174.central.yale.edu (dhcp-128-36-55-174.central.yale.edu [128.36.55.174]) (authenticated bits=0) by vm-emlprdomr-11.its.yale.edu (8.14.4/8.14.4) with ESMTP id q8OFJhUf027445 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 24 Sep 2012 11:19:43 -0400
Message-ID: <50607A0F.3060200@cs.yale.edu>
Date: Mon, 24 Sep 2012 11:19:43 -0400
From: "Y. Richard Yang" 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1
MIME-Version: 1.0
To: Martin Stiemerling 
References: <20120919230313.17329.44102.idtracker@ietfa.amsl.com><505AE794.8070304@neclab.eu> <8D38716F0C1A444BA0CD7E96454366C23A4DDEF6@szxeml545-mbx.china.huawei.com>  <505C74F3.7060002@neclab.eu>  <50604EB1.8040404@neclab.eu>
In-Reply-To: <50604EB1.8040404@neclab.eu>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Scanned-By: MIMEDefang 2.71 on 130.132.50.177
Cc: decade@ietf.org, Konstantinos Pentikousis 
Subject: Re: [decade] WG Action: Conclusion of Decoupled Application Data Enroute (decade)
X-BeenThere: decade@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 24 Sep 2012 15:20:03 -0000

On 9/24/12 8:14 AM, Martin Stiemerling wrote:
> Akbar,
>
> On 09/22/2012 01:52 AM, Rahman, Akbar wrote:
>> Hi Martin,
>>
>>
>> Regarding your point below.  Unfortunately, I think that you are 
>> factually wrong.  Otherwise prove me wrong by showing me where on the 
>> I-D State Diagram 
>> http://datatracker.ietf.org/images/state_diagram.png it specifies 
>> that sending an I-D back to the authors with comments equals shutting 
>> down the WG and stopping a WG approved I-D.
>
> You are referring the state diagram for Internet drafts and this state 
> diagram does have no relationship to what happens with a WG.
>
> However, for termination of WGs, please refer to RFC 2418, Section 4, 
> copied here for your convenience:
>
> 4. Working Group Termination
>
>
>    Working groups are typically chartered to accomplish a specific task
>    or tasks.  After the tasks are complete, the group will be disbanded.
>    However, if a WG produces a Proposed or Draft Standard, the WG will
>    frequently become dormant rather than disband (i.e., the WG will no
>    longer conduct formal activities, but the mailing list will remain
>    available to review the work as it moves to Draft Standard and
>    Standard status.)
>
>    If, at some point, it becomes evident that a working group is unable
>    to complete the work outlined in the charter, or if the assumptions
>    which that work was based have been modified in discussion or by
>    experience, the Area Director, in consultation with the working group
I am wondering this large number of emails in the last few days is the 
"consultation with the working group" part or not.

Richard
>
>    can either:
>
>    1. Recharter to refocus its tasks,
>    2. Choose new Chair(s), or
>    3. Disband.
>
>    If the working group disagrees with the Area Director's choice, it
>    may appeal to the IESG (see section 3.4).
>
>
> and cite the email announcing the termination of the DECADE WG
> "The DECADE WG has reached the point where it is evident that the
> chartered work cannot be completed at a technical level suitable for the
> coming steps of the protocol definition and also within an appropriate
> time frame."
>
> The drafts do not show that the WG is completing its technical work.
>
>   Martin
>
>>
>>
>>
>> -- snip --
>>
>>> - As an author, I do NOT feel that I was part of any extensive 
>>> discussions regarding potential shutting down of the DECADE WG and 
>>> especially stopping the current active WG drafts (especially the 
>>> Architecture I-D where I was an author).
>>
>> Talk to your chairs and consider that the requirements went from
>> publication requested (i.e., on the way to the IESG) back to the WG
>> (i.e., not on the way to the IESG).
>>
>> The same is true for the architecture draft.
>>
>>
>> -- snip --
>>
>>
>> BR
>>
>> /Akbar
>>
>>
>> -----Original Message-----
>> From: Martin Stiemerling [mailto:martin.stiemerling@neclab.eu]
>> Sent: Friday, September 21, 2012 10:09 AM
>> To: Rahman, Akbar
>> Cc: Konstantinos Pentikousis; decade@ietf.org
>> Subject: Re: [decade] WG Action: Conclusion of Decoupled Application 
>> Data Enroute (decade)
>>
>> Hi Akbar,
>>
>> On 09/21/2012 03:21 PM, Rahman, Akbar wrote:
>>> To All,
>>>
>>>
>>>
>>> I also want to make some points for the record:
>>>
>>> - As an author, I do NOT feel that I was part of any extensive 
>>> discussions regarding potential shutting down of the DECADE WG and 
>>> especially stopping the current active WG drafts (especially the 
>>> Architecture I-D where I was an author).
>>
>> Talk to your chairs and consider that the requirements went from
>> publication requested (i.e., on the way to the IESG) back to the WG
>> (i.e., not on the way to the IESG).
>>
>> The same is true for the architecture draft.
>>
>>>
>>> - We did have one lunch meeting in Vancouver with Martin and the 
>>> chairs but that was publicly announced and open to all in the WG.  
>>> At that meeting, I recall Martin asking the attendees if there was 
>>> industry interest for the DECADE work.  From what I recall, everyone 
>>> there did express various levels of interest and support.  I didn’t 
>>> hear anyone say that DECADE was a "wasted effort". So, frankly I was 
>>> surprised and disappointed to see the WG shut down so suddenly.  If 
>>> there really is no community support to continue with the activity, 
>>> then so be it.  But you cannot conclude that there is not interest 
>>> without first having an open discussion.
>>
>> To be honestly, but expressing interest and transforming interest to
>> technical progress are two very distinct actions.
>>
>> I have seen a lot of 'expressing interest', but the technical progress
>> was and is just not there.
>>
>> I also told at the lunch meeting in Vancouver that I want to see actions
>> on the two main drafts in the WG, i.e., the requirements and the
>> architecture. Yes there has been action, but the technical quality of
>> the drafts is far from being useful for any further protocol 
>> development.
>> See also my email with 2 examples on issues not addressed in neither the
>> requirements nor the architecture draft.
>>
>>>
>>> - In terms of the document quality.  The first draft of the 
>>> Architecture I-D was in March 2011.  Since then we have gotten 
>>> extensive comments from various excellent reviewers.  But as is 
>>> often the case when you have multiple reviewers, you sometimes get 
>>> conflicting directions.  Some reviewers wanted a high level abstract 
>>> architecture that avoided all "implementation" details.  Other 
>>> reviewers wanted a more detailed approach that got more into the 
>>> details of the protocols and inner workings of the nodes.  I 
>>> personally tried in a good faith effort to address all the comments 
>>> and to try to strike a balance in addressing the philosophies of the 
>>> different reviewers.
>>
>> The architecture drafts clearly fails to show the architecture of the
>> DECADE protocols. See my AD review.
>>
>> You have indeed received extensive reviews, but it is up to date not
>> clear if and how they were addressed.
>>
>> You can see also this, as the draft talks about the DECADE system which
>> is not equal to the protocols.
>>
>>>
>>> - I agree with Kostas that many documents in other WGs go through 
>>> similar issues but at the end still managed to produce good work.
>>
>> Yes and no. There are examples in both directions, so it doesn't help
>> here in this particular case.
>>
>>>
>>> - To conclude, I devoted in good faith a fair amount of my energy to 
>>> participate in advancing the topics in the WG since the first 
>>> session back in Anaheim.  I defer to the higher powers to make the 
>>> decision on closing the DECADE WG or not. However, I clearly want to 
>>> state that I think it was unfortunate to also suddenly terminate the 
>>> DECADE Architecture I-D which was being extensively revised whenever 
>>> we got reviewer comments.  I understand if people are saying that 
>>> more work has to be done to get it to publication state.  But that 
>>> does not warrant, in my opinion, to just shut down the work.  
>>> Honestly, if you use that criteria there would be many WG documents 
>>> in other groups that should also be abruptly shut down.
>>
>> I wonder why there is so much care about other groups? This is about
>> DECADE not any other arbitrary group somewhere else.
>>
>> With respect to the energy:
>> If people still believe in DECADE, take the documents, address the
>> reviews, get reviews and go for the Independent Stream submission with
>> the RFC editor.
>>
>> Regards,
>>
>>     Martin
>>
>>>
>>>
>>> Respectfully,
>>>
>>>
>>> Akbar
>>>
>>> -----Original Message-----
>>> From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.org] On 
>>> Behalf Of Konstantinos Pentikousis
>>> Sent: Friday, September 21, 2012 8:15 AM
>>> To: Martin Stiemerling; decade@ietf.org
>>> Subject: Re: [decade] WG Action: Conclusion of Decoupled Application 
>>> Data Enroute (decade)
>>>
>>> Dear Martin, All,
>>>
>>>     |The DECADE working group has just been closed by your 
>>> responsible Area
>>>     |Director.
>>>     |
>>>     |This may come as a surprise to some in the WG
>>>
>>> Indeed, it has been a surprise.
>>>
>>>     | but it should not be a surprise for the working drafts authors
>>>
>>> That's fine, but I think some sort of announcement (and even better 
>>> a discussion) should have been circulated prior to the IESG 
>>> announcement. I'm not interested into _who_ should have done this. 
>>> It's too late and, in the end, irrelevant at this stage. But there's 
>>> an order of magnitude more people on this mailing list than in the 
>>> author line of all drafts together. I would consider this a 
>>> breakdown in communication between the inner- and outer-circle. This 
>>> was far from what, in general, I would call a "graceful teardown".
>>>
>>>     | Both drafts do leave any number of key questions unanswered
>>>
>>> I do agree with most of your technical comments. I sent reviews on 
>>> both documents earlier. That said, imo, this action was a bit 
>>> abrupt. I do recall a few groups that were much later in their 
>>> timelines than decade is now, and they still managed to do decent 
>>> work after a (prolonged) slow start.
>>>
>>> In any case, I respect your decision, but I do not second it.
>>>
>>> Best Regards,
>>>
>>> Kostas
>>>
>>>
>>
>


From alexey.melnikov@isode.com  Tue Sep 25 04:32:19 2012
Return-Path: 
X-Original-To: decade@ietfa.amsl.com
Delivered-To: decade@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 628DF21F888C for ; Tue, 25 Sep 2012 04:32:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.976
X-Spam-Level: 
X-Spam-Status: No, score=-101.976 tagged_above=-999 required=5 tests=[AWL=-0.369, BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992, 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 YciPj2WNU7kt for ; Tue, 25 Sep 2012 04:32:17 -0700 (PDT)
Received: from statler.isode.com (statler.isode.com [62.3.217.254]) by ietfa.amsl.com (Postfix) with ESMTP id 9854021F8880 for ; Tue, 25 Sep 2012 04:32:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1348572736; d=isode.com; s=selector; i=@isode.com; bh=SUxe+jNMNcnPfbtsMvUnB880Yhi3rUgPTjzkfW4Kasw=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=ut1OETYrRQGDBL6D+nNyolIrOhI1TLJBHYz7DGqxixDLBJNf10HBCx9Dh4nXqf+eO5SXoS FMIlOG13Gmvgz2c87e9D0WE8XrhNI5Dt5wtRh06unUQ6yH1OxnfkxtOkRl4ZnFFJgGdbHb Pj3Rk/pP/cvlRidk9+JUgi+LBYjvcUQ=;
Received: from [172.16.1.29] (shiny.isode.com [62.3.217.250])  by statler.isode.com (submission channel) via TCP with ESMTPA  id ; Tue, 25 Sep 2012 12:32:16 +0100
Message-ID: <5060B690.9090302@isode.com>
Date: Mon, 24 Sep 2012 20:37:52 +0100
From: Alexey Melnikov 
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1
To: Phillip Hallam-Baker 
References: <50531AB3.6090601@neclab.eu>  <50583257.2080404@neclab.eu>   <506052F5.9070006@neclab.eu> 
In-Reply-To: 
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "DECADE@ietf.org" , Martin Stiemerling 
Subject: Re: [decade] DECADE WG to be closed
X-BeenThere: decade@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 25 Sep 2012 11:32:19 -0000

On 24/09/2012 13:57, Phillip Hallam-Baker wrote:
> How does this leave the ni: extensions draft?
>
> This is a piece of work that I originally proposed outside DECADE and 
> was persuaded to bring in since the DECADE ni work was similar to my 
> di proposal.
>
> One part of the work is on track to become an RFC but the extensions 
> piece has the encryption capability which is very useful since it 
> turns an identifier into a bearer token.

IMHO, I think it would be Ok to get this published as an AD sponsored 
document (in SEC or Apps). I might know a document shepherd who might be 
able to help ;-).

From sm@elandsys.com  Tue Sep 25 08:14:05 2012
Return-Path: 
X-Original-To: decade@ietfa.amsl.com
Delivered-To: decade@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B0591F0C7E; Tue, 25 Sep 2012 08:14:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.577
X-Spam-Level: 
X-Spam-Status: No, score=-102.577 tagged_above=-999 required=5 tests=[AWL=0.022, 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 tGXYGmGpfKUE; Tue, 25 Sep 2012 08:14:04 -0700 (PDT)
Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DA8F1F0C54; Tue, 25 Sep 2012 08:14:04 -0700 (PDT)
Received: from SUBMAN.elandsys.com ([41.136.233.101]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q8PFDm43012314 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 25 Sep 2012 08:13:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1348586041; bh=UNJL4V+9+MvaDf/bkL+wpdlwzomp7NkLAWEUpov1rtM=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=u+sL6m0HBrReszVWyd/vXal6gX+yHN4booJHjhHTvitbq0nmupBgcGZteltXybFQq eQcd9O6nCzvOrzr+4DnY1hJ/qv2uHM0+SLWyl1LOjB7mBaQlz7mWAky6WlFUutRmqR sJka+TB7oyHko/mb32MHI1Z6qXbk/x5YniH16zQA=
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1348586041; i=@elandsys.com; bh=UNJL4V+9+MvaDf/bkL+wpdlwzomp7NkLAWEUpov1rtM=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=mw45IWaqd9+37nKfpwuB5AWFbU3s0KoKyWm5A7BgBd4knlvQKau9dZTBDuwhZpDH4 8o2G9D7035T9AJijeLJILbey1gQT8sDr/fLR0rJisZFRVYAJLhagvmOp9Nv6UmZhSg SJjsrjJsFRQSTuHPE8XV4jF6C9NCKMGosn85fKSQ=
Message-Id: <6.2.5.6.2.20120925072708.098586a0@resistor.net>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Tue, 25 Sep 2012 07:57:16 -0700
To: decade@ietf.org
From: S Moonesamy 
In-Reply-To: 
References: <50531AB3.6090601@neclab.eu>  <50583257.2080404@neclab.eu> 
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Mailman-Approved-At: Tue, 25 Sep 2012 08:16:52 -0700
Cc: appsdir@ietf.org
Subject: Re: [decade] DECADE WG to be closed
X-BeenThere: decade@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 25 Sep 2012 15:14:05 -0000

At 23:52 21-09-2012, Songhaibin wrote:
>I believe all those comments were addressed in the current draft, as 
>I joined the discussion with the authors to address the comments. 
>Their efforts should be respected. The authors and I would like Dave 
>and Carsten to check the draft with their comments, if they are 
>interested. While I admit answering in the mailing list is a main 
>method to resolve comments, but it is not the only method.

The Applications Directorate reviewers have volunteered their free 
time and effort to perform these reviews.  It is a disincentive to 
the reviewers if they have to track WG drafts to determine whether 
their comments have been addressed.

Regards,
S. Moonesamy 


From Martin.Stiemerling@neclab.eu  Wed Sep 26 03:43:07 2012
Return-Path: 
X-Original-To: decade@ietfa.amsl.com
Delivered-To: decade@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5797621F87FF for ; Wed, 26 Sep 2012 03:43:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.448
X-Spam-Level: 
X-Spam-Status: No, score=-102.448 tagged_above=-999 required=5 tests=[AWL=0.151, 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 rWiJCfkA6rS1 for ; Wed, 26 Sep 2012 03:43:06 -0700 (PDT)
Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 3751621F87F3 for ; Wed, 26 Sep 2012 03:43:05 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 0F778101F53; Wed, 26 Sep 2012 12:43:04 +0200 (CEST)
X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de)
Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gZFtJUBLWz1v; Wed, 26 Sep 2012 12:43:03 +0200 (CEST)
Received: from METHONE.office.hd (methone.office.hd [192.168.24.54]) by mailer1.neclab.eu (Postfix) with ESMTP id E231C101EF3; Wed, 26 Sep 2012 12:42:48 +0200 (CEST)
Received: from [10.1.1.190] (10.1.1.190) by skoll.office.hd (192.168.125.11) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 26 Sep 2012 12:42:27 +0200
Message-ID: <5062DC13.90905@neclab.eu>
Date: Wed, 26 Sep 2012 12:42:27 +0200
From: Martin Stiemerling 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0
MIME-Version: 1.0
To: "Rahman, Akbar" 
References: <20120919230313.17329.44102.idtracker@ietfa.amsl.com><505AE794.8070304@neclab.eu> <8D38716F0C1A444BA0CD7E96454366C23A4DDEF6@szxeml545-mbx.china.huawei.com>  <505C74F3.7060002@neclab.eu>  <50604EB1.8040404@neclab.eu> 
In-Reply-To: 
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 8bit
X-Originating-IP: [10.1.1.190]
Cc: decade@ietf.org, Konstantinos Pentikousis 
Subject: Re: [decade] WG Action: Conclusion of Decoupled Application Data Enroute (decade)
X-BeenThere: decade@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 26 Sep 2012 10:43:07 -0000

Hi Akbar,

The decision has been made and there are ways forward for the drafts 
described in my original email. If you believe that there have been 
errors in the process, you can also follow what's written in my original 
email.

If DECADE is really important, take your time and get the drafts 
progressed by solving the technical challenges.

  Martin

On 09/24/2012 04:55 PM, Rahman, Akbar wrote:
> Dear Martin,
>
>
> Just to gently remind you, the original point in this email trail was your contention that " .. but it should not be a surprise for the working drafts authors" that the WG was being closed.  To back-up this point you said:
>
>> Talk to your chairs and consider that the requirements went from
>> publication requested (i.e., on the way to the IESG) back to the WG
>> (i.e., not on the way to the IESG).
>
>
> At least one of the chairs has written back and said he was very surprised as well that the WG was being closed.  And I pointed to the I-D state diagram to show that sending the I-D back to the authors with comments was part of the process and so could not have flagged to me that the WG was being closed.  So your argument does not hold water.
>
> Now you bring up the RFC 2418 but that has nothing to with the original point.  In fact it certainly seems to be a surprise to everyone BUT you that the WG is being shut down (as evidenced by the avalanche of emails on the list).  So please just concede the point or just move on.
>
>
>
> Respectfully yours,
>
>
> Akbar
>
>
> -----Original Message-----
> From: Martin Stiemerling [mailto:martin.stiemerling@neclab.eu]
> Sent: Monday, September 24, 2012 8:15 AM
> To: Rahman, Akbar
> Cc: Konstantinos Pentikousis; decade@ietf.org
> Subject: Re: [decade] WG Action: Conclusion of Decoupled Application Data Enroute (decade)
>
> Akbar,
>
> On 09/22/2012 01:52 AM, Rahman, Akbar wrote:
>> Hi Martin,
>>
>>
>> Regarding your point below.  Unfortunately, I think that you are factually wrong.  Otherwise prove me wrong by showing me where on the I-D State Diagram http://datatracker.ietf.org/images/state_diagram.png it specifies that sending an I-D back to the authors with comments equals shutting down the WG and stopping a WG approved I-D.
>
> You are referring the state diagram for Internet drafts and this state
> diagram does have no relationship to what happens with a WG.
>
> However, for termination of WGs, please refer to RFC 2418, Section 4,
> copied here for your convenience:
>
> 4. Working Group Termination
>
>
>      Working groups are typically chartered to accomplish a specific task
>      or tasks.  After the tasks are complete, the group will be disbanded.
>      However, if a WG produces a Proposed or Draft Standard, the WG will
>      frequently become dormant rather than disband (i.e., the WG will no
>      longer conduct formal activities, but the mailing list will remain
>      available to review the work as it moves to Draft Standard and
>      Standard status.)
>
>      If, at some point, it becomes evident that a working group is unable
>      to complete the work outlined in the charter, or if the assumptions
>      which that work was based have been modified in discussion or by
>      experience, the Area Director, in consultation with the working group
>      can either:
>
>      1. Recharter to refocus its tasks,
>      2. Choose new Chair(s), or
>      3. Disband.
>
>      If the working group disagrees with the Area Director's choice, it
>      may appeal to the IESG (see section 3.4).
>
>
> and cite the email announcing the termination of the DECADE WG
> "The DECADE WG has reached the point where it is evident that the
> chartered work cannot be completed at a technical level suitable for the
> coming steps of the protocol definition and also within an appropriate
> time frame."
>
> The drafts do not show that the WG is completing its technical work.
>
>     Martin
>
>>
>>
>>
>> -- snip --
>>
>>> - As an author, I do NOT feel that I was part of any extensive discussions regarding potential shutting down of the DECADE WG and especially stopping the current active WG drafts (especially the Architecture I-D where I was an author).
>>
>> Talk to your chairs and consider that the requirements went from
>> publication requested (i.e., on the way to the IESG) back to the WG
>> (i.e., not on the way to the IESG).
>>
>> The same is true for the architecture draft.
>>
>>
>> -- snip --
>>
>>
>> BR
>>
>> /Akbar
>>
>>
>> -----Original Message-----
>> From: Martin Stiemerling [mailto:martin.stiemerling@neclab.eu]
>> Sent: Friday, September 21, 2012 10:09 AM
>> To: Rahman, Akbar
>> Cc: Konstantinos Pentikousis; decade@ietf.org
>> Subject: Re: [decade] WG Action: Conclusion of Decoupled Application Data Enroute (decade)
>>
>> Hi Akbar,
>>
>> On 09/21/2012 03:21 PM, Rahman, Akbar wrote:
>>> To All,
>>>
>>>
>>>
>>> I also want to make some points for the record:
>>>
>>> - As an author, I do NOT feel that I was part of any extensive discussions regarding potential shutting down of the DECADE WG and especially stopping the current active WG drafts (especially the Architecture I-D where I was an author).
>>
>> Talk to your chairs and consider that the requirements went from
>> publication requested (i.e., on the way to the IESG) back to the WG
>> (i.e., not on the way to the IESG).
>>
>> The same is true for the architecture draft.
>>
>>>
>>> - We did have one lunch meeting in Vancouver with Martin and the chairs but that was publicly announced and open to all in the WG.  At that meeting, I recall Martin asking the attendees if there was industry interest for the DECADE work.  From what I recall, everyone there did express various levels of interest and support.  I didn’t hear anyone say that DECADE was a "wasted effort". So, frankly I was surprised and disappointed to see the WG shut down so suddenly.  If there really is no community support to continue with the activity, then so be it.  But you cannot conclude that there is not interest without first having an open discussion.
>>
>> To be honestly, but expressing interest and transforming interest to
>> technical progress are two very distinct actions.
>>
>> I have seen a lot of 'expressing interest', but the technical progress
>> was and is just not there.
>>
>> I also told at the lunch meeting in Vancouver that I want to see actions
>> on the two main drafts in the WG, i.e., the requirements and the
>> architecture. Yes there has been action, but the technical quality of
>> the drafts is far from being useful for any further protocol development.
>> See also my email with 2 examples on issues not addressed in neither the
>> requirements nor the architecture draft.
>>
>>>
>>> - In terms of the document quality.  The first draft of the Architecture I-D was in March 2011.  Since then we have gotten extensive comments from various excellent reviewers.  But as is often the case when you have multiple reviewers, you sometimes get conflicting directions.  Some reviewers wanted a high level abstract architecture that avoided all "implementation" details.  Other reviewers wanted a more detailed approach that got more into the details of the protocols and inner workings of the nodes.  I personally tried in a good faith effort to address all the comments and to try to strike a balance in addressing the philosophies of the different reviewers.
>>
>> The architecture drafts clearly fails to show the architecture of the
>> DECADE protocols. See my AD review.
>>
>> You have indeed received extensive reviews, but it is up to date not
>> clear if and how they were addressed.
>>
>> You can see also this, as the draft talks about the DECADE system which
>> is not equal to the protocols.
>>
>>>
>>> - I agree with Kostas that many documents in other WGs go through similar issues but at the end still managed to produce good work.
>>
>> Yes and no. There are examples in both directions, so it doesn't help
>> here in this particular case.
>>
>>>
>>> - To conclude, I devoted in good faith a fair amount of my energy to participate in advancing the topics in the WG since the first session back in Anaheim.  I defer to the higher powers to make the decision on closing the DECADE WG or not.  However, I clearly want to state that I think it was unfortunate to also suddenly terminate the DECADE Architecture I-D which was being extensively revised whenever we got reviewer comments.  I understand if people are saying that more work has to be done to get it to publication state.  But that does not warrant, in my opinion, to just shut down the work.  Honestly, if you use that criteria there would be many WG documents in other groups that should also be abruptly shut down.
>>
>> I wonder why there is so much care about other groups? This is about
>> DECADE not any other arbitrary group somewhere else.
>>
>> With respect to the energy:
>> If people still believe in DECADE, take the documents, address the
>> reviews, get reviews and go for the Independent Stream submission with
>> the RFC editor.
>>
>> Regards,
>>
>>      Martin
>>
>>>
>>>
>>> Respectfully,
>>>
>>>
>>> Akbar
>>>
>>> -----Original Message-----
>>> From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.org] On Behalf Of Konstantinos Pentikousis
>>> Sent: Friday, September 21, 2012 8:15 AM
>>> To: Martin Stiemerling; decade@ietf.org
>>> Subject: Re: [decade] WG Action: Conclusion of Decoupled Application Data Enroute (decade)
>>>
>>> Dear Martin, All,
>>>
>>>      |The DECADE working group has just been closed by your responsible Area
>>>      |Director.
>>>      |
>>>      |This may come as a surprise to some in the WG
>>>
>>> Indeed, it has been a surprise.
>>>
>>>      | but it should not be a surprise for the working drafts authors
>>>
>>> That's fine, but I think some sort of announcement (and even better a discussion) should have been circulated prior to the IESG announcement. I'm not interested into _who_ should have done this. It's too late and, in the end, irrelevant at this stage. But there's an order of magnitude more people on this mailing list than in the author line of all drafts together. I would consider this a breakdown in communication between the inner- and outer-circle. This was far from what, in general, I would call a "graceful teardown".
>>>
>>>      | Both drafts do leave any number of key questions unanswered
>>>
>>> I do agree with most of your technical comments. I sent reviews on both documents earlier. That said, imo, this action was a bit abrupt. I do recall a few groups that were much later in their timelines than decade is now, and they still managed to do decent work after a (prolonged) slow start.
>>>
>>> In any case, I respect your decision, but I do not second it.
>>>
>>> Best Regards,
>>>
>>> Kostas
>>>
>>>
>>
>

-- 
martin.stiemerling@neclab.eu

NEC Laboratories Europe - Network Research Division NEC Europe Limited
Registered Office: NEC House, 1 Victoria Road, London W3 6BL
Registered in England 283

From Martin.Stiemerling@neclab.eu  Wed Sep 26 04:25:16 2012
Return-Path: 
X-Original-To: decade@ietfa.amsl.com
Delivered-To: decade@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0006F21F87DB for ; Wed, 26 Sep 2012 04:25:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.45
X-Spam-Level: 
X-Spam-Status: No, score=-102.45 tagged_above=-999 required=5 tests=[AWL=0.149, 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 ou6o4RZdHL7e for ; Wed, 26 Sep 2012 04:25:15 -0700 (PDT)
Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 0A95A21F86E0 for ; Wed, 26 Sep 2012 04:25:15 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 70F3A101F84; Wed, 26 Sep 2012 13:25:14 +0200 (CEST)
X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de)
Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xJeJ5inm2jzZ; Wed, 26 Sep 2012 13:25:14 +0200 (CEST)
Received: from ENCELADUS.office.hd (enceladus.office.hd [192.168.24.52]) by mailer1.neclab.eu (Postfix) with ESMTP id 53582101F53; Wed, 26 Sep 2012 13:25:04 +0200 (CEST)
Received: from [10.1.1.190] (10.1.1.190) by skoll.office.hd (192.168.125.11) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 26 Sep 2012 13:24:13 +0200
Message-ID: <5062E5FA.7030405@neclab.eu>
Date: Wed, 26 Sep 2012 13:24:42 +0200
From: Martin Stiemerling 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0
MIME-Version: 1.0
To: "Y. Richard Yang" 
References: <20120919230313.17329.44102.idtracker@ietfa.amsl.com> <505AE794.8070304@neclab.eu> <505C7772.3070503@cs.yale.edu> <50602997.6090201@neclab.eu> <50607948.6060002@cs.yale.edu>
In-Reply-To: <50607948.6060002@cs.yale.edu>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit
X-Originating-IP: [10.1.1.190]
Cc: decade@ietf.org
Subject: Re: [decade] WG Action: Conclusion of Decoupled Application Data Enroute (decade)
X-BeenThere: decade@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 26 Sep 2012 11:25:16 -0000

Hi Richard,

On 09/24/2012 05:16 PM, Y. Richard Yang wrote:
> On 9/24/12 5:36 AM, Martin Stiemerling wrote:
>> Hi Richard,
>>
>> On 09/21/2012 04:19 PM, Y. Richard Yang wrote:
>> [...]
>>>
>>>> though there are a number of issues that should have been discussed.
>>>>
>>>> The WG chairs were explicitly notified in mid of June that there are
>>>> severe issues and the WG had time to address those issues. However, it
>>>> must have been obvious even before mid of June that there are severe
>>>> issues, i.e., there has been sufficient time to fix it.
>>>>
>>>> Furthermore, the requirements and architecture draft were submitted to
>>>> the IESG for publication and both drafts have been returned to the WG,
>>>> as both are not ready to be published as RFC.
>>>> You can find the AD review in the datatracker:
>>>> - https://datatracker.ietf.org/doc/draft-ietf-decade-reqs/history/
>>>> - https://datatracker.ietf.org/doc/draft-ietf-decade-arch/history/
>>>>
>>> Your preceding AD reviews are extensive. But I think the main criticism
>>> is writing/English/organization problems, not technical problems.
>>
>> No, it isn't!
>> The criticisms are about technical issues in the sense that it is not
>> clear what DECADE is exactly looking like in many parts
> This could be a useful discussion on the mailing list, before the
> closure of the WG. From my personal point of view, requirements and
> architecture do not specify "exactly looking". My personal design
> approach is that if I can see two reasonable design approaches to
> satisfy one req, I will resist strongly to specify one.

There have been criticism by other reviewers before. Those reviewers 
wrote it in their reviews sent to the draft authors and also in emails 
to the chairs and the responsible AD.

I believe the DECADE had time to work on their drafts and did also 
receive sufficient feedback to change things.

>
>> and also many requirements are not correct or incomplete.
>
> It can helpful if you point out which part is "not correct".
>
>> This is not about language or organizational issues, but it is about
>> technical issues, though that there are organizational issues, e.g.,
>> listing new requirements in the architecture.
>>
>>>
>>>> Both drafts do leave any number of key questions unanswered, i.e.,
>>>> they are far away from being technically useful to be the base for the
>>>> next steps in the protocol development.
>>>>
>>>> To give 2 examples:
>>>> 1)
>>>> It is completely unclear how the resources on a DECADE server are
>>>> supposed to be managed
>>> The basic design principles are stated in Sec. 4.4 and 4.5 of -arch:
>>> Explicit Control and Delegation, with sentences such as
>>>
>>> "Storage Providers will have the ability to explicitly manage the
>>>     entities allowed to utilize the resources at a DECADE-compatible
>>>     server.  This capability is needed for reasons such as capacity-
>>>     planning and legal considerations in certain deployment scenarios."
>>
>> This is a high-level description that does not add anything to
>> question on how it will be managed.
>>
> This is not an empty requirement--it rules out non-managed caches, and
> hence is a step in answering the management issue.

Right, it is one step in answering the management issue. But defining a 
managed cache is not a trivial task, i.e., this needs much more attention.

>
>>>
>>> "Content Providers are able to explicitly and independently manage their
>>> own shares of resources on a server."
>>
>> Nice, but how? The 'how' is about how on the conceptual level and not
>> yet on the protocol detail level.
>>
> We list requirements, not how to satisfy the requirements. We resisted
> strongly to specify how. But even so, the documents suggested some
> 'how'. A related 'how' for this:

Well, requirements must say how they can be satisfied in the sense that 
it must be feasible to test a protocol against the requirements on a 
technical level.

>
>
>       8.3 Distributed Resource Sharing Specification
>
>
>
>     REQUIREMENT(S):  A Provider MUST be able to indicate to its DECADE-
>         compatible server, without itself contacting the server, resource
>         control policies for a Consumer.  The DECADE-compatible server
>         MUST be able to authenticate the resource control policies.

How can the provider indicate its policies to a DECADE server w/o 
contacting the server? This is completely impossible!

Probably you can see from where I coming, by comparing the text in the 
RATIONAL with the REQUIREMENT(S) text. While the rational gives a hint 
to what is expected by this requirement, the requirement itself is not 
useful at all.

And, this requirement does still not say how this is done. Is this done 
via the SDT or DRP or something else?

This is an excellent example about what is wrong with the requirements 
draft, why it has been pushed back to the WG, and why this is one piece 
of the puzzle why the DECADE was closed.

   Martin

-- 
martin.stiemerling@neclab.eu

NEC Laboratories Europe - Network Research Division NEC Europe Limited
Registered Office: NEC House, 1 Victoria Road, London W3 6BL
Registered in England 283

From yang.r.yang@gmail.com  Thu Sep 27 16:10:13 2012
Return-Path: 
X-Original-To: decade@ietfa.amsl.com
Delivered-To: decade@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF98021F84E4 for ; Thu, 27 Sep 2012 16:10:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.976
X-Spam-Level: 
X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 To5qnUaB-0eY for ; Thu, 27 Sep 2012 16:10:13 -0700 (PDT)
Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 20B7821F860E for ; Thu, 27 Sep 2012 16:10:13 -0700 (PDT)
Received: by obqv19 with SMTP id v19so2826058obq.31 for ; Thu, 27 Sep 2012 16:10:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=I9+hlwyHuW4z45f+rN/wl9oqVWGFoW4Ch6MNwRXTFW8=; b=BGA4T+gTe5GoXe52M69vxXQLXo21GiccH2mMIZoCSUJv4tcXGQn6LrOXSFnWzHq3ID IineuuWYPcTktSK+Kn+XpPmg2iMxSvFOhH6HmjmhY+PG4qd4EluZo/Hk0gCEfibkTkeS RNdAXcaIeYT/rVWQBSs4yzR40ZxqA5lm9YPZE5KPeIzWdCxbCHQ8rbmBNQjZ0UJ8aQlz ZqXqTxJ9eeYgxyFNFWlHi9s7JaMZMWCV7XT2ge1tFghkCnKLVn1Go1AJsMEcO2faM295 k6kmdkcGJp2YswQ0mWKgOO0wngOuT43B3Y6ZZs4BxORLZOk/RRdRKfmPYQ1mphF0hfYd 8Zrw==
MIME-Version: 1.0
Received: by 10.60.8.71 with SMTP id p7mr4569614oea.56.1348787412685; Thu, 27 Sep 2012 16:10:12 -0700 (PDT)
Sender: yang.r.yang@gmail.com
Received: by 10.76.152.166 with HTTP; Thu, 27 Sep 2012 16:10:12 -0700 (PDT)
In-Reply-To: <5062E5FA.7030405@neclab.eu>
References: <20120919230313.17329.44102.idtracker@ietfa.amsl.com> <505AE794.8070304@neclab.eu> <505C7772.3070503@cs.yale.edu> <50602997.6090201@neclab.eu> <50607948.6060002@cs.yale.edu> <5062E5FA.7030405@neclab.eu>
Date: Thu, 27 Sep 2012 19:10:12 -0400
X-Google-Sender-Auth: Ckjt1LUHr2QOnvfStIlEtzWKm_E
Message-ID: 
From: "Y. Richard Yang" 
To: Martin Stiemerling 
Content-Type: multipart/alternative; boundary=e89a8ff1c5549c534604cab70ab2
Cc: "decade@ietf.org" 
Subject: Re: [decade] WG Action: Conclusion of Decoupled Application Data Enroute (decade)
X-BeenThere: decade@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 27 Sep 2012 23:10:13 -0000

--e89a8ff1c5549c534604cab70ab2
Content-Type: text/plain; charset=ISO-8859-1

On Wednesday, September 26, 2012, Martin Stiemerling wrote:

>
>>       8.3 Distributed Resource Sharing Specification
>>
>>
>>
>>     REQUIREMENT(S):  A Provider MUST be able to indicate to its DECADE-
>>         compatible server, without itself contacting the server, resource
>>         control policies for a Consumer.  The DECADE-compatible server
>>         MUST be able to authenticate the resource control policies.
>>
>
> How can the provider indicate its policies to a DECADE server w/o
> contacting the server? This is completely impossible!


This is possible! A provider can indicate the policies in a token. Hence,
the consumer contacts the server and the provider does not!


>
> Probably you can see from where I coming, by comparing the text in the
> RATIONAL with the REQUIREMENT(S) text. While the rational gives a hint to
> what is expected by this requirement, the requirement itself is not useful
> at all.
>


> And, this requirement does still not say how this is done.


I gave one example how abve. There can be other smart approaches that I may
not foresee. The documents specify what but now how.


> Is this done via the SDT or DRP or something else?
>
> Either way can work. Depend on the design.


> This is an excellent example about what is wrong with the requirements
> draft,


I look it diferrently. This is an excellent example of giving requirements,
but not limiting the design space!

Richard


> why it has been pushed back to the WG, and why this is one piece of the
> puzzle why the DECADE was closed.
>
>   Martin
>
> --
> martin.stiemerling@neclab.eu
>
> NEC Laboratories Europe - Network Research Division NEC Europe Limited
> Registered Office: NEC House, 1 Victoria Road, London W3 6BL
> Registered in England 283
>

--e89a8ff1c5549c534604cab70ab2
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable



On Wednesday, September 26, 2012, Martin Stiemerling  wrote:



=A0 =A0 =A0 8.3 Distributed Resource Sharing Specification







=A0 =A0 REQUIREMENT(S): =A0A Provider MUST be able to indicate to its DECAD=
E-

=A0 =A0 =A0 =A0 compatible server, without itself contacting the server, re=
source

=A0 =A0 =A0 =A0 control policies for a Consumer. =A0The DECADE-compatible s=
erver

=A0 =A0 =A0 =A0 MUST be able to authenticate the resource control policies.=






How can the provider indicate its policies to a DECADE server w/o contactin=
g the server? This is completely impossible!

This is possible! A provider can indicate the policies in a token. Hence,=
 the consumer contacts the server and the provider does not!

=A0



Probably you can see from where I coming, by comparing the text in the RATI=
ONAL with the REQUIREMENT(S) text. While the rational gives a hint to what =
is expected by this requirement, the requirement itself is not useful at al=
l.


=A0

And, this requirement does still not say how this is done.=A0<=
blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px=
 #ccc solid;padding-left:1ex">

I gave one e=
xample how abve. There can be other smart approaches that I may not foresee=
. The documents specify what but now how.


=A0
Is this done via the SDT or DR=
P or something else?


Either way can work. Depend on the design.
=
=A0

This is an excellent example about what is wrong with the requirements draf=
t,=A0



I look it diferrently. This is an excellent example of giving requirem=
ents, but not limiting the design space!

<=
div>Richard
=A0

why it has been pushed back to the WG, and why this is one piece of the puz=
zle why the DECADE was closed.



=A0 Martin



-- 

martin.stiemerling@neclab.eu



NEC Laboratories Europe - Network Research Division NEC Europe Limited

Registered Office: NEC House, 1 Victoria Road, London W3 6BL

Registered in England 283




--e89a8ff1c5549c534604cab70ab2--

From yang.r.yang@gmail.com  Thu Sep 27 16:44:02 2012
Return-Path: 
X-Original-To: decade@ietfa.amsl.com
Delivered-To: decade@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E20C21F8599 for ; Thu, 27 Sep 2012 16:44:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.976
X-Spam-Level: 
X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 jzrOu-52uftn for ; Thu, 27 Sep 2012 16:44:01 -0700 (PDT)
Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2E6A821F8594 for ; Thu, 27 Sep 2012 16:44:01 -0700 (PDT)
Received: by obqv19 with SMTP id v19so2849527obq.31 for ; Thu, 27 Sep 2012 16:44:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=mFWapuijgLvUNj5IO/MSIHSWpafmxnz45sI1IrlpO80=; b=hfUBz9nk9+C6DXkGbM8zE5+UxNYb4q5uvBYjV/LONkJ2+iW0BR4Da42EP8PWy5VPHY Mx8if2zM4aJiEw6iCn2H4Cx0Qfxokh34kbLdzydyDeIpldD7jZ9f6hXqu8PLXOsPNVqb O9IqENp6ybJmu3uRxwDU5L33K7eSsjDq2TzntNKd9/96ZKICUWBg0CQhKGzSEwT+N6tn eNf2H52vBRVA8rJxYoigKGkhGuBqJoqnetT8KW7El5f7//uGTn/MzrgwYWu71DrA4HMa MzX0IygMNjUuZ9YPvN6kktCzUmxXXo8AYiJXh/tNla5cyAHeheicBvR1UoJUWEOaX0DO yuQw==
MIME-Version: 1.0
Received: by 10.60.13.2 with SMTP id d2mr4609532oec.110.1348789440691; Thu, 27 Sep 2012 16:44:00 -0700 (PDT)
Sender: yang.r.yang@gmail.com
Received: by 10.76.152.166 with HTTP; Thu, 27 Sep 2012 16:44:00 -0700 (PDT)
In-Reply-To: 
References: <20120919230313.17329.44102.idtracker@ietfa.amsl.com> <505AE794.8070304@neclab.eu> <505C7772.3070503@cs.yale.edu> <50602997.6090201@neclab.eu> <50607948.6060002@cs.yale.edu> <5062E5FA.7030405@neclab.eu> 
Date: Thu, 27 Sep 2012 19:44:00 -0400
X-Google-Sender-Auth: mp730cg672mUAp0k_5T8drTSZbI
Message-ID: 
From: "Y. Richard Yang" 
To: "Y. Richard Yang" 
Content-Type: multipart/alternative; boundary=e89a8ff256727d3c8e04cab783dc
Cc: "decade@ietf.org" , Martin Stiemerling 
Subject: Re: [decade] WG Action: Conclusion of Decoupled Application Data Enroute (decade)
X-BeenThere: decade@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 27 Sep 2012 23:44:02 -0000

--e89a8ff256727d3c8e04cab783dc
Content-Type: text/plain; charset=ISO-8859-1

On Thursday, September 27, 2012, Y. Richard Yang wrote:

>
>
> On Wednesday, September 26, 2012, Martin Stiemerling wrote:
>
>>
>>>       8.3 Distributed Resource Sharing Specification
>>>
>>>
>>>
>>>     REQUIREMENT(S):  A Provider MUST be able to indicate to its DECADE-
>>>         compatible server, without itself contacting the server, resource
>>>         control policies for a Consumer.  The DECADE-compatible server
>>>         MUST be able to authenticate the resource control policies.
>>>
>>
>> How can the provider indicate its policies to a DECADE server w/o
>> contacting the server? This is completely impossible!
>
>
> This is possible! A provider can indicate the policies in a token. Hence,
> the consumer contacts the server and the provider does not!
>
>
>>
>> Probably you can see from where I coming, by comparing the text in the
>> RATIONAL with the REQUIREMENT(S) text. While the rational gives a hint to
>> what is expected by this requirement, the requirement itself is not useful
>> at all.
>>
>
>
>> And, this requirement does still not say how this is done.
>
>
> I gave one example how abve. There can be other smart approaches that I
> may not foresee. The documents specify what but now how.
>
>
>> Is this done via the SDT or DRP or something else?
>>
>> Either way can work. Depend on the design.
>
>
>> This is an excellent example about what is wrong with the requirements
>> draft,
>
>
> I look it diferrently. This is an excellent example of giving
> requirements, but not limiting the design space!
>

Let me add to this. As a researcher, I am always impressed by human
ingeninuity.  As an example, in my today's lecture on wireless
networks/mobile computing, we discussed how to handle ISI. After so many
years, I am still impressed by the endless human ingenuity in handling the
problem, wave shaping, vertibi, ofdm, rake receiver... You learn to be
humble. One key research strategy in my group is also to come up with
surprising solutions. This approach works well and we are the few who
consistently publish in sigcomm, the most competitive networking
conference. Hence, in the requirement specification setting, we make sure
that it is possible, by coming up with a solution ourself, and then post
the requirement. We are humble, but not incapable. I am puzzled that you
did not ask these questions in your tenure as the AD so that we can
help/clarify. This is one piece of the puzzle why we were hugely surprised
by the unexpected closure.

Richard

>
>
>
>> why it has been pushed back to the WG, and why this is one piece of the
>> puzzle why the DECADE was closed.
>>
>>   Martin
>>
>> --
>> martin.stiemerling@neclab.eu
>>
>> NEC Laboratories Europe - Network Research Division NEC Europe Limited
>> Registered Office: NEC House, 1 Victoria Road, London W3 6BL
>> Registered in England 283
>>
>

--e89a8ff256727d3c8e04cab783dc
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable



On Thursday, September 27, 2012, Y. Richard Yang  wrote:


On Wednesday, September 26, 2012, Martin St=
iemerling  wrote:





=A0 =A0 =A0 8.3 Distributed Resource Sharing Specification







=A0 =A0 REQUIREMENT(S): =A0A Provider MUST be able to indicate to its DECAD=
E-

=A0 =A0 =A0 =A0 compatible server, without itself contacting the server, re=
source

=A0 =A0 =A0 =A0 control policies for a Consumer. =A0The DECADE-compatible s=
erver

=A0 =A0 =A0 =A0 MUST be able to authenticate the resource control policies.=






How can the provider indicate its policies to a DECADE server w/o contactin=
g the server? This is completely impossible!

This is possible! A provider can indicate the policies in a token. Hence,=
 the consumer contacts the server and the provider does not!


=A0



Probably you can see from where I coming, by comparing the text in the RATI=
ONAL with the REQUIREMENT(S) text. While the rational gives a hint to what =
is expected by this requirement, the requirement itself is not useful at al=
l.



=A0

And, this requirement does still not say how this is done.=A0
<=
blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px=
 #ccc solid;padding-left:1ex">

I gave one e=
xample how abve. There can be other smart approaches that I may not foresee=
. The documents specify what but now how.



=A0
Is this done via the SDT or DR=
P or something else?


Either way can work. Depend on the design.
=
=A0

This is an excellent example about what is wrong with the requirements draf=
t,=A0




I look it diferrently. This is an excellent example of giving requirem=
ents, but not limiting the design space!

Let me add to this. As a researcher, I am always impressed=
 by human ingeninuity. =A0As an example, in my today's lecture on wirel=
ess networks/mobile computing, we discussed how to handle ISI. After so man=
y years, I am still impressed by the endless human ingenuity in handling th=
e problem, wave shaping, vertibi, ofdm, rake receiver... You learn to be hu=
mble. One key research strategy in my group is also to come up with surpris=
ing solutions. This approach works well and we are the few who consistently=
 publish in sigcomm, the most competitive networking conference. Hence, in =
the requirement specification setting, we make sure that it is possible, by=
 coming up with a solution ourself, and then post the requirement. We are h=
umble, but not incapable. I am puzzled that you did not ask these questions=
 in your tenure as the AD so that we can help/clarify. This is one piece of=
 the puzzle why we were hugely surprised by the unexpected closure.



Richard=A0
=A0


why it has been pushed back to the WG, and why this is one piece of the puz=
zle why the DECADE was closed.



=A0 Martin



-- 

martin.stiemerling@neclab.eu



NEC Laboratories Europe - Network Research Division NEC Europe Limited

Registered Office: NEC House, 1 Victoria Road, London W3 6BL

Registered in England 283






--e89a8ff256727d3c8e04cab783dc--

From haibin.song@huawei.com  Thu Sep 27 17:39:07 2012
Return-Path: 
X-Original-To: decade@ietfa.amsl.com
Delivered-To: decade@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 700C921F8550; Thu, 27 Sep 2012 17:39:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.097
X-Spam-Level: 
X-Spam-Status: No, score=-6.097 tagged_above=-999 required=5 tests=[AWL=0.502,  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 fCkYTPCRXHhi; Thu, 27 Sep 2012 17:39:07 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 17E6E21F855A; Thu, 27 Sep 2012 17:39:05 -0700 (PDT)
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 AKC10816; Fri, 28 Sep 2012 00:39:04 +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; Fri, 28 Sep 2012 01:38:19 +0100
Received: from SZXEML430-HUB.china.huawei.com (10.72.61.38) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 28 Sep 2012 08:39:03 +0800
Received: from SZXEML534-MBX.china.huawei.com ([169.254.2.70]) by szxeml430-hub.china.huawei.com ([10.72.61.38]) with mapi id 14.01.0323.003; Fri, 28 Sep 2012 08:38:58 +0800
From: Songhaibin 
To: S Moonesamy , "decade@ietf.org" 
Thread-Topic: [decade] DECADE WG to be closed
Thread-Index: AQHNmy4NeTF1FP7MtkORFrVdv9nRf5ee6t6w
Date: Fri, 28 Sep 2012 00:38:58 +0000
Message-ID: 
References: <50531AB3.6090601@neclab.eu>  <50583257.2080404@neclab.eu>  <6.2.5.6.2.20120925072708.098586a0@resistor.net>
In-Reply-To: <6.2.5.6.2.20120925072708.098586a0@resistor.net>
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.138.41.123]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: "appsdir@ietf.org" 
Subject: Re: [decade] DECADE WG to be closed
X-BeenThere: decade@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 28 Sep 2012 00:39:07 -0000

Part of the resolution to comments (Carsten's and David Harrington's) were =
recorded in the document sent out by Akbar to the DECADE list several days =
ago. It might be easier to check with that one. It was for the discussion i=
n June.

BR,
-Haibin

> -----Original Message-----
> From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.org] On Behalf =
Of
> S Moonesamy
> Sent: Tuesday, September 25, 2012 10:57 PM
> To: decade@ietf.org
> Cc: appsdir@ietf.org
> Subject: Re: [decade] DECADE WG to be closed
>=20
> At 23:52 21-09-2012, Songhaibin wrote:
> >I believe all those comments were addressed in the current draft, as
> >I joined the discussion with the authors to address the comments.
> >Their efforts should be respected. The authors and I would like Dave
> >and Carsten to check the draft with their comments, if they are
> >interested. While I admit answering in the mailing list is a main
> >method to resolve comments, but it is not the only method.
>=20
> The Applications Directorate reviewers have volunteered their free
> time and effort to perform these reviews.  It is a disincentive to
> the reviewers if they have to track WG drafts to determine whether
> their comments have been addressed.
>=20
> Regards,
> S. Moonesamy


From yang.r.yang@gmail.com  Thu Sep 27 18:07:26 2012
Return-Path: 
X-Original-To: decade@ietfa.amsl.com
Delivered-To: decade@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E14C21F8550 for ; Thu, 27 Sep 2012 18:07:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.976
X-Spam-Level: 
X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 O--eJUSfFE9M for ; Thu, 27 Sep 2012 18:07:25 -0700 (PDT)
Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1680421F8527 for ; Thu, 27 Sep 2012 18:07:25 -0700 (PDT)
Received: by oagn5 with SMTP id n5so2946512oag.31 for ; Thu, 27 Sep 2012 18:07:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=OiRBfamAWrzJ9BCsXZ4vzIWOAW/1tnaLSpzmv7wdYLc=; b=oBmMdP1Wm+eHOi8I5+DeaZReL+gnpwI1xZDFOum7wmfeZd0WBbWjyFBvh3ud2GdIYv IyGv92LF+B7KFFS2V7a3NxDzC7FVSTGf6icynVl0urpy4AqUftHSKbAAm0esnkpFhUNv lKv7cWuTra3ZrB1sz47Bv08VkxIbe6UsBgSEwPS2aB7VS58R4s0oZ6lDl6OIs1ojx+Jp nmfBQEDh8dzqQZJSqOQ3DRu7Stzi8gsTI/lMde2CkTW0LHcXBi3Zl1EDX8MmE0xzn0Pg hk0ILQLc/lbCj6N2rkpL/Mx+KtVOyoZDamV11RBuQxopTZrQiNpiL8WguCY9LboOnZmg OTPg==
MIME-Version: 1.0
Received: by 10.60.6.202 with SMTP id d10mr4516453oea.132.1348794444555; Thu, 27 Sep 2012 18:07:24 -0700 (PDT)
Sender: yang.r.yang@gmail.com
Received: by 10.76.152.166 with HTTP; Thu, 27 Sep 2012 18:07:24 -0700 (PDT)
In-Reply-To: <50607A0F.3060200@cs.yale.edu>
References: <20120919230313.17329.44102.idtracker@ietfa.amsl.com> <505AE794.8070304@neclab.eu> <8D38716F0C1A444BA0CD7E96454366C23A4DDEF6@szxeml545-mbx.china.huawei.com>  <505C74F3.7060002@neclab.eu>  <50604EB1.8040404@neclab.eu> <50607A0F.3060200@cs.yale.edu>
Date: Thu, 27 Sep 2012 21:07:24 -0400
X-Google-Sender-Auth: Kxsnzguep-nhCiTOCWfFRK5AnPQ
Message-ID: 
From: "Y. Richard Yang" 
To: "Y. Richard Yang" 
Content-Type: multipart/alternative; boundary=e89a8fb1f096be25f304cab8adf7
Cc: Konstantinos Pentikousis , "decade@ietf.org" , Martin Stiemerling 
Subject: Re: [decade] WG Action: Conclusion of Decoupled Application Data Enroute (decade)
X-BeenThere: decade@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 28 Sep 2012 01:07:26 -0000

--e89a8fb1f096be25f304cab8adf7
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

On Monday, September 24, 2012, Y. Richard Yang wrote:

> On 9/24/12 8:14 AM, Martin Stiemerling wrote:
>>
>>
>> 4. Working Group Termination
>>
>>
>>    Working groups are typically chartered to accomplish a specific task
>>    or tasks.  After the tasks are complete, the group will be disbanded.
>>    However, if a WG produces a Proposed or Draft Standard, the WG will
>>    frequently become dormant rather than disband (i.e., the WG will no
>>    longer conduct formal activities, but the mailing list will remain
>>    available to review the work as it moves to Draft Standard and
>>    Standard status.)
>>
>>    If, at some point, it becomes evident that a working group is unable
>>    to complete the work outlined in the charter, or if the assumptions
>>    which that work was based have been modified in discussion or by
>>    experience, the Area Director, in consultation with the working group
>>
> I am wondering this large number of emails in the last few days is the
> "consultation with the working group" part or not.


A timer just fired time out. So let me resend the procedure question. Can
someone clarify where, when, and with whom did the "in consultation with
the working group" happen?

Thanks!

Richard

>
> Richard
>
>
>    can either:
>
>    1. Recharter to refocus its tasks,
>    2. Choose new Chair(s), or
>    3. Disband.
>
>    If the working group disagrees with the Area Director's choice, it
>    may appeal to the IESG (see section 3.4).
>
>
> and cite the email announcing the termination of the DECADE WG
> "The DECADE WG has reached the point where it is evident that the
> chartered work cannot be completed at a technical level suitable for the
> coming steps of the protocol definition and also within an appropriate
> time frame."
>
> The drafts do not show that the WG is completing its technical work.
>
>   Martin
>
>
>
>
> -- snip --
>
>  - As an author, I do NOT feel that I was part of any extensive
> discussions regarding potential shutting down of the DECADE WG and
> especially stopping the current active WG drafts (especially the
> Architecture I-D where I was an author).
>
>
> Talk to your chairs and consider that the requirements went from
> publication requested (i.e., on the way to the IESG) back to the WG
> (i.e., not on the way to the IESG).
>
> The same is true for the architecture draft.
>
>
> -- snip --
>
>
> BR
>
> /Akbar
>
>
> -----Original Message-----
> From: Martin Stiemerling [mailto:martin.stiemerling@neclab.eu]
> Sent: Friday, September 21, 2012 10:09 AM
> To: Rahman, Akbar
> Cc: Konstantinos Pentikousis; decade@ietf.org
> Subject: Re: [decade] WG Action: Conclusion of Decoupled Application Data
> Enroute (decade)
>
> Hi Akbar,
>
> On 09/21/2012 03:21 PM, Rahman, Akbar wrote:
>
> To All,
>
>
>
> I also want to make some points for the record:
>
> - As an author, I do NOT feel that I was part of any extensive discussion=
s
> regarding potential shutting down of the DECADE WG and especially stoppin=
g
> the current active WG drafts (especially the Architecture I-D where I was
> an author).
>
>
> Talk to your chairs and consider that the requirements went from
> publication requested (i.e., on the way to the IESG) back to the WG
> (i.e., not on the way to the IESG).
>
> The same is true for the architecture draft.
>
>
> - We did have one lunch meeting in Vancouver with Martin and the chairs
> but that was publicly announced and open to all in the WG.  At that
> meeting, I recall Martin asking the attendees if there was industry
> interest for the DECADE work.  From what I recall, everyone there did
> express various levels of interest and support.  I didn=92t hear anyone s=
ay
> that DECADE was a "wasted effort". So, frankly I was surprised and
> disappointed to see the WG shut down so suddenly.  If there really is no
> community support to continue with the activity, then so be it.  But you
> cannot conclude that there is not interest without first having an open
> discussion.
>
>
> To be honestly, but expressing interest and transforming interest to
> technical progress are two very distinct actions.
>
> I have seen a lot of 'expressing interest', but the technical progress
> was and is just not there.
>
> I also told at the lunch meeting in Vancouver that I want to see actions
> on the two main drafts in the WG, i.e., the requirements and the
> architecture. Yes there has been action, but the technical quality of
> the drafts is far from being useful for any further protocol development.
> See also my email with 2 examples on issues not addressed in neither the
> requirements nor the architecture draft.
>
>
> - In terms of the document quality.  The first draft of the Architecture
> I-D was in March 2011.  Since then we have gotten extensive comments from
> various excellent reviewers.  But as is often the case when you have
> multiple reviewers, you sometimes get conflicting directions.  Some
> reviewers wanted a high level abstract architecture that avoided all
> "implementation" details.  Other reviewers wanted a more detailed approac=
h
> that got more into the details of the protocols and inner workings of the
> nodes.  I personally tried in a good faith effort to address all the
> comments and to try to strike a balance in addressing the philosophies of
> the different reviewers.
>
>
> The architecture drafts clearly fails to show the architecture of the
> DECADE protocols. See my AD review.
>
> You have indeed received extensive review
>
>

--e89a8fb1f096be25f304cab8adf7
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable



On Monday, September 24, 2012, Y. Richard Yang  wrote:
On 9/24/12 8:14 AM, Martin Stiemerling wrote:



4. Working Group Termination





=A0 =A0Working groups are typically chartered to accomplish a specific task=


=A0 =A0or tasks. =A0After the tasks are complete, the group will be disband=
ed.

=A0 =A0However, if a WG produces a Proposed or Draft Standard, the WG will<=
br>
=A0 =A0frequently become dormant rather than disband (i.e., the WG will no<=
br>
=A0 =A0longer conduct formal activities, but the mailing list will remain
=A0 =A0available to review the work as it moves to Draft Standard and

=A0 =A0Standard status.)



=A0 =A0If, at some point, it becomes evident that a working group is unable=


=A0 =A0to complete the work outlined in the charter, or if the assumptions<=
br>
=A0 =A0which that work was based have been modified in discussion or by

=A0 =A0experience, the Area Director, in consultation with the working grou=
p


I am wondering this large number of emails in the last few days is the &quo=
t;consultation with the working group" part or not.
<=
br>
A timer just fired time out. So let me resend the procedure q=
uestion. Can someone clarify where, when, and with whom did the "in co=
nsultation with the working group" happen?=A0


=A0
Thanks!

Richard



Richard





=A0 =A0can either:



=A0 =A01. Recharter to refocus its tasks,

=A0 =A02. Choose new Chair(s), or

=A0 =A03. Disband.



=A0 =A0If the working group disagrees with the Area Director's choice, =
it

=A0 =A0may appeal to the IESG (see section 3.4).





and cite the email announcing the termination of the DECADE WG

"The DECADE WG has reached the point where it is evident that the

chartered work cannot be completed at a technical level suitable for the
coming steps of the protocol definition and also within an appropriate

time frame."



The drafts do not show that the WG is completing its technical work.



=A0 Martin











-- snip --





- As an author, I do NOT feel that I was part of any extensive discussions =
regarding potential shutting down of the DECADE WG and especially stopping =
the current active WG drafts (especially the Architecture I-D where I was a=
n author).






Talk to your chairs and consider that the requirements went from

publication requested (i.e., on the way to the IESG) back to the WG

(i.e., not on the way to the IESG).



The same is true for the architecture draft.





-- snip --





BR



/Akbar





-----Original Message-----

From: Martin Stiemerling [mailto:martin.stiemerling@neclab.eu]

Sent: Friday, September 21, 2012 10:09 AM

To: Rahman, Akbar

Cc: Konstantinos Pentikousis; decade@ietf.org

Subject: Re: [decade] WG Action: Conclusion of Decoupled Application Data E=
nroute (decade)



Hi Akbar,



On 09/21/2012 03:21 PM, Rahman, Akbar wrote:



To All,







I also want to make some points for the record:



- As an author, I do NOT feel that I was part of any extensive discussions =
regarding potential shutting down of the DECADE WG and especially stopping =
the current active WG drafts (especially the Architecture I-D where I was a=
n author).






Talk to your chairs and consider that the requirements went from

publication requested (i.e., on the way to the IESG) back to the WG

(i.e., not on the way to the IESG).



The same is true for the architecture draft.







- We did have one lunch meeting in Vancouver with Martin and the chairs but=
 that was publicly announced and open to all in the WG. =A0At that meeting,=
 I recall Martin asking the attendees if there was industry interest for th=
e DECADE work. =A0From what I recall, everyone there did express various le=
vels of interest and support. =A0I didn=92t hear anyone say that DECADE was=
 a "wasted effort". So, frankly I was surprised and disappointed =
to see the WG shut down so suddenly. =A0If there really is no community sup=
port to continue with the activity, then so be it. =A0But you cannot conclu=
de that there is not interest without first having an open discussion.






To be honestly, but expressing interest and transforming interest to

technical progress are two very distinct actions.



I have seen a lot of 'expressing interest', but the technical progr=
ess

was and is just not there.



I also told at the lunch meeting in Vancouver that I want to see actions
on the two main drafts in the WG, i.e., the requirements and the

architecture. Yes there has been action, but the technical quality of

the drafts is far from being useful for any further protocol development.
See also my email with 2 examples on issues not addressed in neither the
requirements nor the architecture draft.







- In terms of the document quality. =A0The first draft of the Architecture =
I-D was in March 2011. =A0Since then we have gotten extensive comments from=
 various excellent reviewers. =A0But as is often the case when you have mul=
tiple reviewers, you sometimes get conflicting directions. =A0Some reviewer=
s wanted a high level abstract architecture that avoided all "implemen=
tation" details. =A0Other reviewers wanted a more detailed approach th=
at got more into the details of the protocols and inner workings of the nod=
es. =A0I personally tried in a good faith effort to address all the comment=
s and to try to strike a balance in addressing the philosophies of the diff=
erent reviewers.






The architecture drafts clearly fails to show the architecture of the

DECADE protocols. See my AD review.



You have indeed received extensive review


--e89a8fb1f096be25f304cab8adf7--

From sm@elandsys.com  Fri Sep 28 02:47:54 2012
Return-Path: 
X-Original-To: decade@ietfa.amsl.com
Delivered-To: decade@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CBD521F85C0; Fri, 28 Sep 2012 02:47:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.579
X-Spam-Level: 
X-Spam-Status: No, score=-102.579 tagged_above=-999 required=5 tests=[AWL=0.020, 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 ZlqI+RyOdIry; Fri, 28 Sep 2012 02:47:54 -0700 (PDT)
Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id D528521F85BB; Fri, 28 Sep 2012 02:47:53 -0700 (PDT)
Received: from SUBMAN.elandsys.com ([41.136.236.122]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q8S9kncj005663 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 28 Sep 2012 02:46:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1348825621; bh=iP9OIuaoEwEqjgSkfuYXC4Il3XGftfA3v2fzP/wOkV4=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=0qPwrZ2+Ypejvd1DnCsLSCO3BIzpAVO9bEa35ea308asq0IkSZQ6mbLOulocEWYxv UPo6AckVUNhrLx/oD3QvxoygitpZ/1kC4Iu/vStAGdP62+h9TSUFZxRYsvjPFV4GzA 9UF6JLwPn0hDu5oqphRpD0PjWbTNHAIKBjwv7SHc=
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1348825621; i=@elandsys.com; bh=iP9OIuaoEwEqjgSkfuYXC4Il3XGftfA3v2fzP/wOkV4=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=27ZizW27zow7ARytrZgXCpvo9FjYADkSZMeX2nUOSVI+AVm2Xf6FFncjsS4VBXDhg Yewh8u3uT32wrDHmaHD1F1yn/pMrZVzTPKUTiskkdbyyy4k8HhbWhVwIQcTUYeLI7X P1VnReb3yPuXxcrFkgRRpRfQZWU20d8RiSADf82Y=
Message-Id: <6.2.5.6.2.20120928005916.0aed8b00@elandnews.com>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Fri, 28 Sep 2012 02:30:16 -0700
To: Songhaibin 
From: S Moonesamy 
In-Reply-To: 
References: <50531AB3.6090601@neclab.eu>  <50583257.2080404@neclab.eu>  <6.2.5.6.2.20120925072708.098586a0@resistor.net> 
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Mailman-Approved-At: Fri, 28 Sep 2012 05:38:10 -0700
Cc: decade@ietf.org, appsdir@ietf.org
Subject: Re: [decade] DECADE WG to be closed
X-BeenThere: decade@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 28 Sep 2012 09:47:54 -0000

Hello,
At 17:38 27-09-2012, Songhaibin wrote:
>Part of the resolution to comments (Carsten's and David 
>Harrington's) were recorded in the document sent out by Akbar to the 
>DECADE list several days ago. It might be easier to check with that 
>one. It was for the discussion in June.

There were three reviews from the Applications Area Directorate for 
drafts from the DECADE WG:

  23 Jan 2012 
http://www.ietf.org/mail-archive/web/apps-discuss/current/msg04174.html
  22 Mar 2012 
http://www.ietf.org/mail-archive/web/apps-discuss/current/msg04704.html
  22 Mar 2012 
http://www.ietf.org/mail-archive/web/apps-discuss/current/msg04705.html

The reviews could be summarized as "the drafts are not ready for 
publication as a RFC".  The reviewers explained why they came to such 
a conclusion.  The reviews were posted to apps-discuss@ietf.org, an 
open mailing list, so that anyone can comment.  There wasn't any 
timely follow-up on any of these reviews.

According to the message at 
http://www.ietf.org/mail-archive/web/decade/current/msg00805.html the 
Decoupled Application Data Enroute (decade) working group in the 
Transport Area has concluded.  Given the closure of the DECADE WG I 
don't have a good reason to ask the reviewers to check the 
"resolution to comments".

Regards,
S. Moonesamy 


From Martin.Stiemerling@neclab.eu  Fri Sep 28 06:34:23 2012
Return-Path: 
X-Original-To: decade@ietfa.amsl.com
Delivered-To: decade@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1256E21F855E for ; Fri, 28 Sep 2012 06:34:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.411
X-Spam-Level: 
X-Spam-Status: No, score=-102.411 tagged_above=-999 required=5 tests=[AWL=0.188, 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 r0Rn9p3Jpeb6 for ; Fri, 28 Sep 2012 06:34:22 -0700 (PDT)
Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 42FEB21F8508 for ; Fri, 28 Sep 2012 06:34:22 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 914E9101FB3; Fri, 28 Sep 2012 15:34:21 +0200 (CEST)
X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de)
Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LLm1DYbY5NsS; Fri, 28 Sep 2012 15:34:21 +0200 (CEST)
Received: from ENCELADUS.office.hd (enceladus.office.hd [192.168.24.52]) by mailer1.neclab.eu (Postfix) with ESMTP id 71A0C101F95; Fri, 28 Sep 2012 15:34:11 +0200 (CEST)
Received: from [10.1.1.190] (10.1.1.190) by skoll.office.hd (192.168.125.11) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 28 Sep 2012 15:33:49 +0200
Message-ID: <5065A753.1010109@neclab.eu>
Date: Fri, 28 Sep 2012 15:34:11 +0200
From: Martin Stiemerling 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0
MIME-Version: 1.0
To: "Y. Richard Yang" 
References: <20120919230313.17329.44102.idtracker@ietfa.amsl.com> <505AE794.8070304@neclab.eu> <505C7772.3070503@cs.yale.edu> <50602997.6090201@neclab.eu> <50607948.6060002@cs.yale.edu> <5062E5FA.7030405@neclab.eu> 
In-Reply-To: 
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit
X-Originating-IP: [10.1.1.190]
Cc: "decade@ietf.org" 
Subject: Re: [decade] WG Action: Conclusion of Decoupled Application Data Enroute (decade)
X-BeenThere: decade@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 28 Sep 2012 13:34:23 -0000

On 09/28/2012 01:10 AM, Y. Richard Yang wrote:
>
>
> On Wednesday, September 26, 2012, Martin Stiemerling wrote:
>
>
>                8.3 Distributed Resource Sharing Specification
>
>
>
>              REQUIREMENT(S):  A Provider MUST be able to indicate to its
>         DECADE-
>                  compatible server, without itself contacting the
>         server, resource
>                  control policies for a Consumer.  The DECADE-compatible
>         server
>                  MUST be able to authenticate the resource control policies.
>
>
>     How can the provider indicate its policies to a DECADE server w/o
>     contacting the server? This is completely impossible!
>
>
> This is possible! A provider can indicate the policies in a token.
> Hence, the consumer contacts the server and the provider does not!

Right, but than I do have the question on how the DECADE server is able 
to verify that the token is correct?

>
>
>     Probably you can see from where I coming, by comparing the text in
>     the RATIONAL with the REQUIREMENT(S) text. While the rational gives
>     a hint to what is expected by this requirement, the requirement
>     itself is not useful at all.
>
>     And, this requirement does still not say how this is done.
>
>
> I gave one example how abve. There can be other smart approaches that I
> may not foresee. The documents specify what but now how.
>
>     Is this done via the SDT or DRP or something else?
>
> Either way can work. Depend on the design.
>
>     This is an excellent example about what is wrong with the
>     requirements draft,
>
>
> I look it diferrently. This is an excellent example of giving
> requirements, but not limiting the design space!

No, it is limiting the space to the use of tokens and it requires 
modifications to the application protocol, e.g., to the 2p filesharing 
protocol where the tokens would need to be exchanged.

It is necessary to take design choices at the beginning and I would 
expect that the architecture draft would do this. For instance, 
explicitly arguing for tokens and introducing it. Such decisions do 
influence a lot in the design and also in the requirements.

For instance, if you use tokens, you need a management interface where 
you can configure, for instance, public keys which are used to verify if 
a token has been issued by a known and trusted party. This assumes that 
the token is signed with the private key.

   Martin

>
> Richard
>
>     why it has been pushed back to the WG, and why this is one piece of
>     the puzzle why the DECADE was closed.
>
>        Martin
>
>     --
>     martin.stiemerling@neclab.eu
>
>     NEC Laboratories Europe - Network Research Division NEC Europe Limited
>     Registered Office: NEC House, 1 Victoria Road, London W3 6BL
>     Registered in England 283
>

-- 
martin.stiemerling@neclab.eu

NEC Laboratories Europe - Network Research Division NEC Europe Limited
Registered Office: NEC House, 1 Victoria Road, London W3 6BL
Registered in England 283

From Martin.Stiemerling@neclab.eu  Fri Sep 28 06:38:08 2012
Return-Path: 
X-Original-To: decade@ietfa.amsl.com
Delivered-To: decade@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B17AA21F85C3 for ; Fri, 28 Sep 2012 06:38:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.414
X-Spam-Level: 
X-Spam-Status: No, score=-102.414 tagged_above=-999 required=5 tests=[AWL=0.185, 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 6IiXXa8sFR-1 for ; Fri, 28 Sep 2012 06:38:07 -0700 (PDT)
Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id A53F921F8505 for ; Fri, 28 Sep 2012 06:38:07 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 0FAEE101FB2; Fri, 28 Sep 2012 15:38:07 +0200 (CEST)
X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de)
Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I9O9DK9VbInV; Fri, 28 Sep 2012 15:38:06 +0200 (CEST)
Received: from ENCELADUS.office.hd (enceladus.office.hd [192.168.24.52]) by mailer1.neclab.eu (Postfix) with ESMTP id E4D98101F95; Fri, 28 Sep 2012 15:37:46 +0200 (CEST)
Received: from [10.1.1.190] (10.1.1.190) by skoll.office.hd (192.168.125.11) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 28 Sep 2012 15:37:25 +0200
Message-ID: <5065A82A.9020304@neclab.eu>
Date: Fri, 28 Sep 2012 15:37:46 +0200
From: Martin Stiemerling 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0
MIME-Version: 1.0
To: "Y. Richard Yang" 
References: <20120919230313.17329.44102.idtracker@ietfa.amsl.com> <505AE794.8070304@neclab.eu> <8D38716F0C1A444BA0CD7E96454366C23A4DDEF6@szxeml545-mbx.china.huawei.com>  <505C74F3.7060002@neclab.eu>  <50604EB1.8040404@neclab.eu> <50607A0F.3060200@cs.yale.edu> 
In-Reply-To: 
Content-Type: text/plain; charset="windows-1252"; format=flowed
Content-Transfer-Encoding: 8bit
X-Originating-IP: [10.1.1.190]
Cc: "decade@ietf.org" , Konstantinos Pentikousis 
Subject: Re: [decade] WG Action: Conclusion of Decoupled Application Data Enroute (decade)
X-BeenThere: decade@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 28 Sep 2012 13:38:08 -0000

On 09/28/2012 03:07 AM, Y. Richard Yang wrote:
>
>
> On Monday, September 24, 2012, Y. Richard Yang wrote:
>
>     On 9/24/12 8:14 AM, Martin Stiemerling wrote:
>
>
>         4. Working Group Termination
>
>
>             Working groups are typically chartered to accomplish a
>         specific task
>             or tasks.  After the tasks are complete, the group will be
>         disbanded.
>             However, if a WG produces a Proposed or Draft Standard, the
>         WG will
>             frequently become dormant rather than disband (i.e., the WG
>         will no
>             longer conduct formal activities, but the mailing list will
>         remain
>             available to review the work as it moves to Draft Standard and
>             Standard status.)
>
>             If, at some point, it becomes evident that a working group
>         is unable
>             to complete the work outlined in the charter, or if the
>         assumptions
>             which that work was based have been modified in discussion or by
>             experience, the Area Director, in consultation with the
>         working group
>
>     I am wondering this large number of emails in the last few days is
>     the "consultation with the working group" part or not.
>
>
> A timer just fired time out. So let me resend the procedure question.
> Can someone clarify where, when, and with whom did the "in consultation
> with the working group" happen?

I did discuss with the chairs and they are my first contact to the WG.
The operation of the WG is the duty of the chairs.

Again what I have said before and to save everybody's energy and time:
Write an appeal, if you believe that DECADE has done technical progress 
and it was closed without any good reason, or if you see procedural 
mistakes.

   Martin

> Thanks!
>
> Richard
>
>
>     Richard
>
>
>             can either:
>
>             1. Recharter to refocus its tasks,
>             2. Choose new Chair(s), or
>             3. Disband.
>
>             If the working group disagrees with the Area Director's
>         choice, it
>             may appeal to the IESG (see section 3.4).
>
>
>         and cite the email announcing the termination of the DECADE WG
>         "The DECADE WG has reached the point where it is evident that the
>         chartered work cannot be completed at a technical level suitable
>         for the
>         coming steps of the protocol definition and also within an
>         appropriate
>         time frame."
>
>         The drafts do not show that the WG is completing its technical work.
>
>            Martin
>
>
>
>
>             -- snip --
>
>                 - As an author, I do NOT feel that I was part of any
>                 extensive discussions regarding potential shutting down
>                 of the DECADE WG and especially stopping the current
>                 active WG drafts (especially the Architecture I-D where
>                 I was an author).
>
>
>             Talk to your chairs and consider that the requirements went from
>             publication requested (i.e., on the way to the IESG) back to
>             the WG
>             (i.e., not on the way to the IESG).
>
>             The same is true for the architecture draft.
>
>
>             -- snip --
>
>
>             BR
>
>             /Akbar
>
>
>             -----Original Message-----
>             From: Martin Stiemerling [mailto:martin.stiemerling@neclab.eu]
>             Sent: Friday, September 21, 2012 10:09 AM
>             To: Rahman, Akbar
>             Cc: Konstantinos Pentikousis; decade@ietf.org
>             Subject: Re: [decade] WG Action: Conclusion of Decoupled
>             Application Data Enroute (decade)
>
>             Hi Akbar,
>
>             On 09/21/2012 03:21 PM, Rahman, Akbar wrote:
>
>                 To All,
>
>
>
>                 I also want to make some points for the record:
>
>                 - As an author, I do NOT feel that I was part of any
>                 extensive discussions regarding potential shutting down
>                 of the DECADE WG and especially stopping the current
>                 active WG drafts (especially the Architecture I-D where
>                 I was an author).
>
>
>             Talk to your chairs and consider that the requirements went from
>             publication requested (i.e., on the way to the IESG) back to
>             the WG
>             (i.e., not on the way to the IESG).
>
>             The same is true for the architecture draft.
>
>
>                 - We did have one lunch meeting in Vancouver with Martin
>                 and the chairs but that was publicly announced and open
>                 to all in the WG.  At that meeting, I recall Martin
>                 asking the attendees if there was industry interest for
>                 the DECADE work.  From what I recall, everyone there did
>                 express various levels of interest and support.  I
>                 didnt hear anyone say that DECADE was a "wasted
>                 effort". So, frankly I was surprised and disappointed to
>                 see the WG shut down so suddenly.  If there really is no
>                 community support to continue with the activity, then so
>                 be it.  But you cannot conclude that there is not
>                 interest without first having an open discussion.
>
>
>             To be honestly, but expressing interest and transforming
>             interest to
>             technical progress are two very distinct actions.
>
>             I have seen a lot of 'expressing interest', but the
>             technical progress
>             was and is just not there.
>
>             I also told at the lunch meeting in Vancouver that I want to
>             see actions
>             on the two main drafts in the WG, i.e., the requirements and the
>             architecture. Yes there has been action, but the technical
>             quality of
>             the drafts is far from being useful for any further protocol
>             development.
>             See also my email with 2 examples on issues not addressed in
>             neither the
>             requirements nor the architecture draft.
>
>
>                 - In terms of the document quality.  The first draft of
>                 the Architecture I-D was in March 2011.  Since then we
>                 have gotten extensive comments from various excellent
>                 reviewers.  But as is often the case when you have
>                 multiple reviewers, you sometimes get conflicting
>                 directions.  Some reviewers wanted a high level abstract
>                 architecture that avoided all "implementation" details.
>                   Other reviewers wanted a more detailed approach that
>                 got more into the details of the protocols and inner
>                 workings of the nodes.  I personally tried in a good
>                 faith effort to address all the comments and to try to
>                 strike a balance in addressing the philosophies of the
>                 different reviewers.
>
>
>             The architecture drafts clearly fails to show the
>             architecture of the
>             DECADE protocols. See my AD review.
>
>             You have indeed received extensive review
>

-- 
martin.stiemerling@neclab.eu

NEC Laboratories Europe - Network Research Division NEC Europe Limited
Registered Office: NEC House, 1 Victoria Road, London W3 6BL
Registered in England 283

From yry@cs.yale.edu  Fri Sep 28 07:22:03 2012
Return-Path: 
X-Original-To: decade@ietfa.amsl.com
Delivered-To: decade@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC04121F8620 for ; Fri, 28 Sep 2012 07:22:03 -0700 (PDT)
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=[AWL=0.000,  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 cxhoAWaPl4Mn for ; Fri, 28 Sep 2012 07:22:03 -0700 (PDT)
Received: from vm-emlprdomr-03.its.yale.edu (vm-emlprdomr-03.its.yale.edu [130.132.50.144]) by ietfa.amsl.com (Postfix) with ESMTP id 2A23B21F8617 for ; Fri, 28 Sep 2012 07:22:03 -0700 (PDT)
Received: from dhcp-128-36-46-174.central.yale.edu (dhcp-128-36-46-174.central.yale.edu [128.36.46.174]) (authenticated bits=0) by vm-emlprdomr-03.its.yale.edu (8.14.4/8.14.4) with ESMTP id q8SEM0fk013045 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 28 Sep 2012 10:22:01 -0400
Message-ID: <5065B288.20401@cs.yale.edu>
Date: Fri, 28 Sep 2012 10:22:00 -0400
From: "Y. Richard Yang" 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1
MIME-Version: 1.0
To: Martin Stiemerling 
References: <20120919230313.17329.44102.idtracker@ietfa.amsl.com> <505AE794.8070304@neclab.eu> <505C7772.3070503@cs.yale.edu> <50602997.6090201@neclab.eu> <50607948.6060002@cs.yale.edu> <5062E5FA.7030405@neclab.eu>  <5065A753.1010109@neclab.eu>
In-Reply-To: <5065A753.1010109@neclab.eu>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.71 on 130.132.50.144
Cc: "decade@ietf.org" 
Subject: Re: [decade] WG Action: Conclusion of Decoupled Application Data Enroute (decade)
X-BeenThere: decade@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 28 Sep 2012 14:22:04 -0000

On 9/28/12 9:34 AM, Martin Stiemerling wrote:
>
>
> On 09/28/2012 01:10 AM, Y. Richard Yang wrote:
>>
>>
>> On Wednesday, September 26, 2012, Martin Stiemerling wrote:
>>
>>
>>                8.3 Distributed Resource Sharing Specification
>>
>>
>>
>>              REQUIREMENT(S):  A Provider MUST be able to indicate to its
>>         DECADE-
>>                  compatible server, without itself contacting the
>>         server, resource
>>                  control policies for a Consumer.  The DECADE-compatible
>>         server
>>                  MUST be able to authenticate the resource control 
>> policies.
>>
>>
>>     How can the provider indicate its policies to a DECADE server w/o
>>     contacting the server? This is completely impossible!
>>
>>
>> This is possible! A provider can indicate the policies in a token.
>> Hence, the consumer contacts the server and the provider does not!
>
> Right, but than I do have the question on how the DECADE server is 
> able to verify that the token is correct?
The requirement has the following sentence: "The DECADE-compatible 
server MUST be able to authenticate the resource control policies". Like 
I repeatedly said, I do not feel that it is wise to specify how to 
authenticate: there are so many variations, shared key, public key, from 
standard textbooks.

>
>>
>>
>>     Probably you can see from where I coming, by comparing the text in
>>     the RATIONAL with the REQUIREMENT(S) text. While the rational gives
>>     a hint to what is expected by this requirement, the requirement
>>     itself is not useful at all.
>>
>>     And, this requirement does still not say how this is done.
>>
>>
>> I gave one example how abve. There can be other smart approaches that I
>> may not foresee. The documents specify what but now how.
>>
>>     Is this done via the SDT or DRP or something else?
>>
>> Either way can work. Depend on the design.
>>
>>     This is an excellent example about what is wrong with the
>>     requirements draft,
>>
>>
>> I look it diferrently. This is an excellent example of giving
>> requirements, but not limiting the design space!
>
> No, it is limiting the space to the use of tokens 
It is not clear that we have to be limited to the use of tokens. The 
-req authors have thought through that tokens work and hence it is a 
feasible requirement. But there is no "proof" that it is a necessary 
condition.

> and it requires modifications to the application protocol, e.g., to 
> the 2p filesharing protocol where the tokens would need to be exchanged.
>
Yes. This is consistent.

> It is necessary to take design choices at the beginning 
It depends on what you mean by "it is necessary". Personally, I prefer a 
minimal (late-binding) approach, i.e., give more design choices at the 
beginning.

> and I would expect that the architecture draft would do this. For 
> instance, explicitly arguing for tokens and introducing it. Such 
> decisions do influence a lot in the design and also in the requirements.
>
> For instance, if you use tokens, you need a management interface where 
> you can configure, for instance, public keys 
It does not have to use a public-key system. It can be a symmetric key 
system. Either way can go through, as I think through, and why not leave 
this space to the protocol designer so that they can come up with a 
coherent design? This is IETF design, not a class homework assignment 
where the instructor already has a solution in mind and prefers that the 
students just say the right answer.

Thanks.

Richard

> which are used to verify if a token has been issued by a known and 
> trusted party. This assumes that the token is signed with the private 
> key.
>
>   Martin
>
>>
>> Richard
>>
>>     why it has been pushed back to the WG, and why this is one piece of
>>     the puzzle why the DECADE was closed.
>>
>>        Martin
>>
>>     --
>>     martin.stiemerling@neclab.eu
>>
>>     NEC Laboratories Europe - Network Research Division NEC Europe 
>> Limited
>>     Registered Office: NEC House, 1 Victoria Road, London W3 6BL
>>     Registered in England 283
>>
>


From haibin.song@huawei.com  Fri Sep 28 19:38:17 2012
Return-Path: 
X-Original-To: decade@ietfa.amsl.com
Delivered-To: decade@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06C8321F845C; Fri, 28 Sep 2012 19:38:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.181
X-Spam-Level: 
X-Spam-Status: No, score=-6.181 tagged_above=-999 required=5 tests=[AWL=0.418,  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 AKNInDPMkSkT; Fri, 28 Sep 2012 19:38:16 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id AAB4321F844D; Fri, 28 Sep 2012 19:38:15 -0700 (PDT)
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 ALD65275; Sat, 29 Sep 2012 02:38:13 +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; Sat, 29 Sep 2012 03:35:16 +0100
Received: from SZXEML435-HUB.china.huawei.com (10.72.61.63) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.3; Sat, 29 Sep 2012 03:36:14 +0100
Received: from SZXEML534-MBX.china.huawei.com ([169.254.2.70]) by szxeml435-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.003; Sat, 29 Sep 2012 10:36:07 +0800
From: Songhaibin 
To: S Moonesamy 
Thread-Topic: [decade] DECADE WG to be closed
Thread-Index: AQHNmy4NeTF1FP7MtkORFrVdv9nRf5ee6t6wgACe2q6AARDdYA==
Date: Sat, 29 Sep 2012 02:36:06 +0000
Message-ID: 
References: <50531AB3.6090601@neclab.eu>  <50583257.2080404@neclab.eu>  <6.2.5.6.2.20120925072708.098586a0@resistor.net>  <6.2.5.6.2.20120928005916.0aed8b00@elandnews.com>
In-Reply-To: <6.2.5.6.2.20120928005916.0aed8b00@elandnews.com>
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.138.41.123]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: "decade@ietf.org" , "appsdir@ietf.org" 
Subject: Re: [decade] DECADE WG to be closed
X-BeenThere: decade@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 29 Sep 2012 02:38:17 -0000

Hi,

Here are the public emails sent by Akbar when the architecture document was=
 updated. And they were only sent to the decade@ietf.org, I would like it h=
ad been copied to apps-discuss@ietf.org.=20

http://www.ietf.org/mail-archive/web/decade/current/msg00682.html
http://www.ietf.org/mail-archive/web/decade/current/msg00681.html

And yes, you do not have to ask the reviewers to check. I was only asking t=
heir personal will in polite.

BR,
-Haibin

> -----Original Message-----
> From: S Moonesamy [mailto:sm+ietf@elandsys.com]
> Sent: Friday, September 28, 2012 5:30 PM
> To: Songhaibin
> Cc: appsdir@ietf.org; decade@ietf.org
> Subject: RE: [decade] DECADE WG to be closed
>=20
> Hello,
> At 17:38 27-09-2012, Songhaibin wrote:
> >Part of the resolution to comments (Carsten's and David
> >Harrington's) were recorded in the document sent out by Akbar to the
> >DECADE list several days ago. It might be easier to check with that
> >one. It was for the discussion in June.
>=20
> There were three reviews from the Applications Area Directorate for
> drafts from the DECADE WG:
>=20
>   23 Jan 2012
> http://www.ietf.org/mail-archive/web/apps-discuss/current/msg04174.html
>   22 Mar 2012
> http://www.ietf.org/mail-archive/web/apps-discuss/current/msg04704.html
>   22 Mar 2012
> http://www.ietf.org/mail-archive/web/apps-discuss/current/msg04705.html
>=20
> The reviews could be summarized as "the drafts are not ready for
> publication as a RFC".  The reviewers explained why they came to such
> a conclusion.  The reviews were posted to apps-discuss@ietf.org, an
> open mailing list, so that anyone can comment.  There wasn't any
> timely follow-up on any of these reviews.
>=20
> According to the message at
> http://www.ietf.org/mail-archive/web/decade/current/msg00805.html the
> Decoupled Application Data Enroute (decade) working group in the
> Transport Area has concluded.  Given the closure of the DECADE WG I
> don't have a good reason to ask the reviewers to check the
> "resolution to comments".
>=20
> Regards,
> S. Moonesamy