From richard_woundy@cable.comcast.com Wed Mar 2 06:36:28 2011 Return-Path: X-Original-To: decade@core3.amsl.com Delivered-To: decade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 21E0C3A6811 for ; Wed, 2 Mar 2011 06:36:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.199 X-Spam-Level: X-Spam-Status: No, score=-101.199 tagged_above=-999 required=5 tests=[AWL=-3.968, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E0oT-xUz-auS for ; Wed, 2 Mar 2011 06:36:25 -0800 (PST) Received: from cable.comcast.com (copdcimo01.potomac.co.ndcwest.comcast.net [76.96.32.251]) by core3.amsl.com (Postfix) with ESMTP id 8B0C23A680F for ; Wed, 2 Mar 2011 06:36:24 -0800 (PST) Received: from ([24.40.55.40]) by copdcimo01.cable.comcast.com with ESMTP with TLS id 5503630.27844710; Wed, 02 Mar 2011 07:49:23 -0700 Received: from PACDCEXMB05.cable.comcast.com ([fe80::a5b0:e5c4:df1b:2367]) by pacdcexhub03.cable.comcast.com ([fe80::d1dd:b302:b617:3755%12]) with mapi id 14.01.0270.001; Wed, 2 Mar 2011 09:37:25 -0500 From: "Woundy, Richard" To: =?gb2312?B?1uzk7A==?= , Richard Alimi Thread-Topic: [decade] draft-zhu-decade-additional-requirements Thread-Index: AQHLteqM/dhHPQkqkkOgeCjk3l6c0JQaYNaw Date: Wed, 2 Mar 2011 14:37:23 +0000 Message-ID: <1CA25301D2219F40B3AA37201F0EACD11343C0AB@PACDCEXMB05.cable.comcast.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [76.96.111.6] Content-Type: multipart/alternative; boundary="_000_1CA25301D2219F40B3AA37201F0EACD11343C0ABPACDCEXMB05cabl_" MIME-Version: 1.0 Cc: "decade@ietf.org" Subject: Re: [decade] draft-zhu-decade-additional-requirements X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.9 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, 02 Mar 2011 14:36:28 -0000 --_000_1CA25301D2219F40B3AA37201F0EACD11343C0ABPACDCEXMB05cabl_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 Rm9sa3MsDQoNCkRvIHdlIGhhdmUgY29uc2Vuc3VzIHlldCBhYm91dCBob3cgdGhlIFdHIGNvdWxk IGhhdmUgYSBzaW5nbGUgREVDQURFIHJlcXVpcmVtZW50cyBkb2N1bWVudCBnb2luZyBmb3J3YXJk PyBJIGNhbqGvdCB0ZWxsIHRoZSBzdGF0ZSBvZiBvdXIgcmVxdWlyZW1lbnRzIGNvbnNvbGlkYXRp b24gZnJvbSB0aGUgZW1haWwgdGhyZWFkIGJlbG93Lg0KDQpJdCB3b3VsZCBiZSBwcmVmZXJhYmxl IGlmIHdlIGNvdWxkIHJlc29sdmUgdGhpcyBmdWxseSBvbiB0aGUgV0cgbWFpbGluZyBsaXN0LCBi dXQgdGhpcyBpcyBpbXBvcnRhbnQgZW5vdWdoIHRvIGFsbG9jYXRlIHNvbWUgdGltZSBhdCBvdXIg bWVldGluZyBpbiBQcmFndWUuDQoNCi0tIFJpY2gNCg0KRnJvbTogZGVjYWRlLWJvdW5jZXNAaWV0 Zi5vcmcgW21haWx0bzpkZWNhZGUtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mID8/DQpT ZW50OiBTdW5kYXksIEphbnVhcnkgMTYsIDIwMTEgOTowMiBQTQ0KVG86IFJpY2hhcmQgQWxpbWkN CkNjOiBkZWNhZGVAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbZGVjYWRlXSBkcmFmdC16aHUtZGVj YWRlLWFkZGl0aW9uYWwtcmVxdWlyZW1lbnRzDQoNCmhpLCBSaWNoYXJkOg0KDQp0aGFua3MgZm9y IHlvdXIgcmVwbHk6RA0KYWRkaXRpb25hbCBkaXNjdXNzaW9uIHNlZSBpbmxpbmU6RA0KDQoyMDEx LzEvMTQgUmljaGFyZCBBbGltaSA8cmljaEB2ZWx2ZXRzZWEubmV0PG1haWx0bzpyaWNoQHZlbHZl dHNlYS5uZXQ+Pg0KSEkgWGlhbywNCg0KMjAxMS8xLzEyINbs5OwgPGJ1cHR4aWFvemh1QGdtYWls LmNvbTxtYWlsdG86YnVwdHhpYW96aHVAZ21haWwuY29tPj46DQo+IGhpLCBSaWNoYXJkDQo+IHNl ZSBpbmxpbmU6RA0KPg0KPiAyMDExLzEvMTEgUmljaGFyZCBBbGltaSA8cmljaEB2ZWx2ZXRzZWEu bmV0PG1haWx0bzpyaWNoQHZlbHZldHNlYS5uZXQ+Pg0KPj4NCj4+IEhpIFhpYW8sDQo+Pg0KPj4g T24gTW9uLCBKYW4gMTAsIDIwMTEgYXQgNjo0NSBQTSwg1uzk7CA8YnVwdHhpYW96aHVAZ21haWwu Y29tPG1haWx0bzpidXB0eGlhb3podUBnbWFpbC5jb20+PiB3cm90ZToNCj4+ID4NCj4+ID4gaGks IFJpY2hhcmQsIHNvcnJ5IGZvciBzbyBsYXRlIHJlc3BvbnNlIGJlY2F1c2Ugb2YgYmUgYnVzeSB3 aXRoIG90aGVyDQo+PiA+IHByb2plY3RzLg0KPj4gPiBzb21lIGRpc2N1c3Npb24gc2VlIGlubGlu ZTpEIG1hcmtlZCBieSByZWQuDQo+PiA+DQo+PiA+IE9uIFR1ZSwgSmFuIDQsIDIwMTEgYXQgNDow NiBBTSwgUmljaGFyZCBBbGltaSA8cmljaEB2ZWx2ZXRzZWEubmV0PG1haWx0bzpyaWNoQHZlbHZl dHNlYS5uZXQ+Pg0KPj4gPiB3cm90ZToNCj4+ID4+DQo+PiA+PiBIaSBYaWFvLA0KPj4gPj4NCj4+ ID4+IFRoYW5rIHlvdSBmb3IgdGhlIGRyYWZ0LiAgU29tZSBjb21tZW50cyBvbiB0aGUgcmVxdWly ZW1lbnRzOg0KPj4gPj4NCj4+ID4+IFJlcXVlc3QgUmVkaXJlY3RzOg0KPj4gPj4NCj4+ID4+IFRo aXMgd291bGQgcHJvdmlkZSBzb21lIGFkZGl0aW9uYWwgZnJlZWRvbSBmb3IgdGhlIHN0b3JhZ2Ug cHJvdmlkZXIuDQo+PiA+PiBJIHRoaW5rIGl0IGlzIHJlYXNvbmFibGUgc2luY2UgaXQgZG9lc24n dCBuZWNlc3NpdGF0ZSBhZGRpdGlvbmFsDQo+PiA+PiBjb21wbGV4aXR5IGZvciB0aGUgREVDQURF IHNlcnZlciwgYnV0IGFsbG93cyBpdCBpZiBkZXNpcmVkLiBIb3dldmVyLA0KPj4gPj4gbm90ZSB0 aGF0IGl0IG1heSBjb21wbGljYXRlIHNvbWUgb2YgdGhlIG90aGVyIGNvbXBvbmVudHMgb2YgdGhl DQo+PiA+PiBkZXNpZ24uIEluIHBhcnRpY3VsYXIsIGlmIHRoZXJlIGlzIGEgcGVyLXVzZXIgcXVv dGEgZm9yIHN0b3JhZ2UsIGlzDQo+PiA+PiB0aGUgdXNlciBtYWRlIGF3YXJlIG9mIHRoZSBxdW90 YSBhdCBlYWNoIGluLW5ldHdvcmsgc3RvcmFnZSAoaWYgdGhlcmUNCj4+ID4+IGlzIG5vIHNoYXJl ZCBzdG9yYWdlIGJldHdlZW4gdGhlbSk/ICBSZXNvdXJjZSBzaGFyaW5nIHBvbGljaWVzIG1heSBi ZQ0KPj4gPj4gaW1wYWN0ZWQgKGUuZy4sIGlmIGEgYmFuZHdpZHRoIHNoYXJpbmcgd2VpZ2h0IG9m IDEgbWF5IG1lYW4gc29tZXRoaW5nDQo+PiA+PiBkaWZmZXJlbnQgYXQgREVDQURFIHNlcnZlciBB IHRoYW4gaXQgZG9lcyBhdCBERUNBREUgc2VydmVyIEIpLiAgQXQNCj4+ID4+IHRoaXMgcG9pbnQg aXQgbWF5IGJlIGJlc3QgdG8ganVzdCBub3RlIHRoZXNlIHNvIHRoZXkgYXJlIGRvY3VtZW50ZWQs DQo+PiA+PiBidXQgc2luY2UgdGhlIHNwZWNpZmljYXRpb24gb2YgdGhlIHJlc291cmNlIHNoYXJp bmcgcG9saWNpZXMgYXJlIHN0aWxsDQo+PiA+PiBiZWluZyBjb250ZW1wbGF0ZWQgZm9yIHRoZSBi YXNpYyBjYXNlIG9mIGEgc2luZ2xlIHNlcnZlciBpdCBtYXkgYmUNCj4+ID4+IHByZW1hdHVyZSB0 byBldmVuIHRyeSBhbmQgc29sdmUgdGhlbSBmb3IgdGhlIGNhc2Ugc3VwcG9ydGluZw0KPj4gPj4g cmVkaXJlY3Rpb24uDQo+PiA+Pg0KPj4gPiBhY3R1YWxseSwgeW91IG1lYW4gdHdvIHBvaW50cywg cmlnaHQ/DQo+PiA+IDEuIHdoZXRoZXIgb3Igbm90IHRvIGJlIHdhcmUgb2YgdGhlIGNvbnRlbnQg YXQgZWFjaCBpbi1uZXR3b3JrIHN0b3JhZ2UNCj4+ID4gYW5kIG9mIGNvdXJzZSByZXNvdXJjZSBz aGFyaW5nIHBvbGljaWVzIGNhbiBiZSBpbXBhY3QgaW4gdGhlIHJlcXVlc3QNCj4+ID4gcmVkaXJl Y3Rpb24uIHlvdXIgc3VnZ2VzdGlvbiJqdXN0IHRvIG5vdGUgdGhlc2Ugc28gdGhleSBhcmUgZG9j dW1lbnRlZCIgd2lsbA0KPj4gPiBiZSBvaywgb3IgREVDQURFIHNlcnZlciBsaXN0IHdpdGggc29t ZSBwYXJhbWV0ZXJzIHdpbGwgYmUgcmV0dXJuIGZvciB1c2VyIHRvDQo+PiA+IHNlbGVjdCB0aGUg YXBwcm9wcmlhdGUgREVDQURFIHNlcnZlciwgd2hpY2ggY2FuIGF2b2lkIHRoZSBkaWZmZXJlbnQg d2VpZ2h0ZWQNCj4+ID4gb2YgdGhlIHNhbWUgcGFyYW1ldGVyIGluIHNlcnZlciBkZWNpc2lvbi4g YnV0IHRoZSBwYXJhbWV0ZXIgdXNlZCBpbiBzZWxlY3QNCj4+ID4gdGhlIGJlc3QgREVDQURFIHNl cnZlciB3aWxsIGJlIGtub3duIGZvciBERUNBREUgc2VydmVycywgaW4gd2hpY2ggb3RoZXINCj4+ ID4gY29tcGxleGl0aWVzIHdpbGwgYmUgYWRkZWQuIGFueXdheSwgYWxsIHRoZSBzb2x1dGlvbiBh cmUgdGhlIGltcGxlbWVudGF0aW9uDQo+PiA+IGlzc3VlLCB3aGljaCwgaSBiZWxpZXZlLCBkb2Vz IG5vdCBpbXBhY3QgdGhlIG5lY2Vzc2l0eSBvZiB0aGUgcmVxdWlyZW1lbnQuDQo+Pg0KPj4gSW4g Z2VuZXJhbCwgSSdkIGFncmVlIHRoYXQgdGhlIGRlY2lzaW9uIGFib3V0IHdoZXJlIHRvIHJlZGly ZWN0IHdvdWxkDQo+PiBiZSBhbiBpbXBsZW1lbnRhdGlvbiBpc3N1ZS4NCj4+DQo+PiA+DQo+PiA+ IDIuIHlvdSBtZWFuICJ0aGUgcmVzb3VyY2Ugc2hhcmluZyBwb2xpY2llcyBhcmUgc3RpbGwgYmVp bmcgY29uc2lkZXJlZCBpbg0KPj4gPiBhIHNpbmdsZSBzZXJ2ZXIiLCBzbyBpdCBtYXkgYmUgcHJl bWF0dXJlIHRvIHN1cHBvcnQgcmVkaXJlY3Rpb24uICB0aGUNCj4+ID4gYXJjaGl0ZWN0dXJlIGFu ZCBwcm90b2NvbCB3aWxsIGJlIGJhZGx5IGltcGFjdGVkIGlmIHRoZSByZXF1aXJlbWVudHMgY2hh bmdlLg0KPj4gPiBzbyB0aGUgZGVzaWduaW5nIGNhbiBiZSAgdGFrZW4gIHN0ZXAgYnkgc3RlcCwg YnV0IHRoZSByZXF1aXJlbWVudHMgc2hvdWxkIGJlDQo+PiA+IG92ZXJhbGwgY29uc2lkZXJlZC4N Cj4+DQo+PiBJIHNhaWQgdGhhdCBpdCBpcyBwcm9iYWJseSBwcmVtYXR1cmUgdG8gY29uc2lkZXIg aG93IHJlc291cmNlIHNoYXJpbmcNCj4+IHBvbGljaWVzIHdvcmtzIGFjcm9zcyBzZXJ2ZXJzIChv ciBldmVuIGlmIHdlIG5lZWQgdG8gc2F5IGFueXRoaW5nDQo+PiBhYm91dCBpdCkgc2luY2Ugd2Ug aGF2ZSBub3QgZGV0ZXJtaW5lZCBob3cgdG8gc3BlY2lmeSB0aGVtIChvciByYXRoZXIsDQo+PiBo b3cgbGl0dGxlIHdlIG5lZWQgdG8gc3BlY2lmeSBpbiBwcm90b2NvbCkgZm9yIGEgc2luZ2xlIHNl cnZlci4gSSBkaWQNCj4+IG5vdCBtZWFuIHRvIGltcGx5IHRoYXQgcmVkaXJlY3Rpb24gY291bGQg bm90IGJlIGludHJvZHVjZWQgYXMgYQ0KPj4gcmVxdWlyZW1lbnQuDQo+Pg0KPg0KPj4NCj4+ID4N Cj4+ID4NCj4+ID4+DQo+PiA+PiBNdWx0aS1jb25uZWN0aW9uOg0KPj4gPj4NCj4+ID4+IEknbSBu b3QgcXVpdGUgY2xlYXIgb24gdGhlIGludGVudGlvbiBvZiB0aGUgcmVxdWlyZW1lbnQuICBNeQ0K Pj4gPj4gdW5kZXJzdGFuZGluZyBpcyB0aGF0IHlvdSB3aXNoIHRoZSBjbGllbnQgdG8gYmUgYWJs ZSB0byBoYXZlIG11bHRpcGxlDQo+PiA+PiBjb25uZWN0aW9ucyBvcGVuIHNwYW5uaW5nIG11bHRp cGxlIERFQ0FERSBzZXJ2ZXJzLiBJcyB0aGF0IGNvcnJlY3Q/DQo+PiA+Pg0KPj4gPj4gSWYgc28s IGRvIHdlIG5lZWQgdGhpcyBzdGF0ZWQgYXMgYSByZXF1aXJlbWVudCBvciB0aGUgcHJvdG9jb2w/ IE9yIGlzDQo+PiA+PiB0aGlzIGEgcG9saWN5IHRoYXQgd291bGQgYmUgYWxsb3dlZC9kaXNhbGxv d2VkIGJ5IHRoZSBzdG9yYWdlDQo+PiA+PiBwcm92aWRlcj8NCj4+ID4+DQo+PiA+IHllcCwgeW91 ciB1bmRlcnN0YW5kaW5nIGlzIHJpZ2h0LCB0aGUgc2NlbmFyaW9zIHdlcmUganVzdCBkZXNjcmli ZWQgaW4NCj4+ID4gZHJhZnQgYXMgInNvZnQgaGFuZG92ZXIgaW4gd2lyZWxlc3MgZW52aXJvbm1l bnQgYW5kIGRlbGV0ZSBvcGVyYXRpb24gaW4NCj4+ID4gbXVsdGktc2VydmVycyIuIHVuZGVyIHRo ZXNlIGNvbnNpZGVyYXRpb24sIHRoZSBhdXRoZW50aWNhdGlvbiBhbmQNCj4+ID4gYXV0aG9yaXph dGlvbiBuZWVkIHRvIGJlIHRha2VuIGVhY2ggdGltZSB3aGVuIHNldHVwIGNvbm5lY3Rpb24gd2l0 aCBhIG5ldw0KPj4gPiBERUNBREUgc2VydmVyLCBvciBqdXN0IGJlIHRha2VuIG9ubHkgb25jZSBk dXJpbmcgIHRoZSBzZXJ2aWNlPw0KPj4NCj4+IFRoZSBERUNBREUgc2VydmVyIHNob3VsZCBuZWVk IHRvIGRvIHNvbWUgc29ydCBvZiBjaGVjayBvbiBlYWNoIG5ldw0KPj4gY29ubmVjdGlvbiwgcmVn YXJkbGVzcyBvZiB3aGV0aGVyIHRoZSB1c2VyIGhhcyBvciBwcmV2aW91c2x5IGhhZCBhDQo+PiBj b25uZWN0aW9uIG9wZW4gdG8gYSBkaWZmZXJlbnQgREVDQURFIHNlcnZlciwgcmlnaHQ/ICBOb3Rl IHRoYXQgdGhlDQo+PiByZXF1aXJlbWVudHMgZG9uJ3QgaW5kaWNhdGUgaG93IGF1dGhlbnRpY2F0 aW9uIG9yIGF1dGhvcml6YXRpb24gaXMNCj4+IGRvbmUsIGFuZCBhbGxvdyBhIHNlcnZlciB0byBt YWtlIG9wdGltaXphdGlvbnMgaWYgaXQgaXMgZW5mb3JjaW5nIHRoZQ0KPj4gc2FtZSBwZXJtaXNz aW9ucy4NCj4+DQo+PiBDYW4geW91IGluZGljYXRlIHdoZXJlIHRoZSBleGlzdGluZyBhdXRob3Jp emF0aW9uLXJlbGF0ZWQgcmVxdWlyZW1lbnRzDQo+PiAoaW4gcGFydGljdWxhciwgNC4xLjYuMyBv ZiBkcmFmdC1pZXRmLWRlY2FkZS1yZXFzLTAwKSBkbyBub3Qgc3VmZmljZQ0KPj4gZm9yIHRoZSB1 c2UgY2FzZSB5b3UgYXJlIHRoaW5raW5nIG9mPw0KDQo+IGFzIGNvbnNpZGVyaW5nIHRoZSBzZXJ2 aWNlIGNvbnRpbnVpdHksIHRoZSBuZXh0IHNlcnZpbmcgIERFQ0FERSBzZXJ2ZXINCj4gc2hvdWxk IGtub3cgdGhlIHByb2dyZXNzIG9mIHRoZSBzZXJ2aWNlLCBob3cgZG9lcyB0aGV5IGtub3c/DQpC eSBwcm9ncmVzcyBvZiB0aGUgc2VydmljZSwgZG8geW91IG1lYW4gY3VycmVudCB1c2VyIHN0YXRl IChlLmcuLA0KcXVvdGEsIHJlY2VudCByZXNvdXJjZSB1c2FnZSBoaXN0b3J5LCBwZXJtaXNzaW9u cywgZXRjKT8NCnllcywgYW5kIGluY2x1ZGUgZGF0YSBkZWxpdmVyeSBwcm9jZWVkaW5nLg0KPiBz byBpZiB0aGUNCj4gc2VydmljZSBwcm9jZWVkaW5nIGluZm9ybWF0aW9uIHNob3VsZCBiZSBrbm93 biBieSB0aGUgbmV4dCBzZXJ2aW5nIHNlcnZlciwNCj4gb3IgZGlmZmVyZW50IHNlcnZlcnMgbmVl ZCB0byBjb29yZGluYXRlIGFuZCBzY2hlZHVsZSBlYWNoIG90aGVyIHRvIGZ1bGZpbGwNCj4gdGhl IHVzZXIgcmVxdWVzdCwgaSBiZWxpZXZlIHRoZSB0aGUgNC4xLjYuMyBvZiB0aGUgZHJhZnQtaWV0 Zi1kZWNhZGUtcmVxLTAwDQo+IGNhbm5vdCBzYXRpc2Z5IHRoZSByZXEuIHdoYXQgZG8geW91IHRo aW5rIGFib3V0Pw0KTm90ZSB0aGF0IHRoZSBwcm90b2NvbCB0aGF0IGlzIGNvdmVyZWQgaGVyZSBp cyB0aGUgY2xpZW50LXNlcnZlcg0KcHJvdG9jb2wuIFNvbWUgb2YgdGhlIHNhbWUgcHJvdG9jb2wg bWF5IGJlIHVzZWZ1bCBiZXR3ZWVuIERFQ0FERQ0Kc2VydmVycyAoZXNwZWNpYWxseSBpbiBkaWZm ZXJlbnQgYWRtaW5pc3RyYXRpdmUgZG9tYWlucykgZm9yIHN0b3JpbmcNCmFuZCByZXRyaWV2aW5n IGRhdGEsIGJ1dCB0aGF0IGRvZXMgbm90IG1lYW4gdGhhdCB0aGVyZSBjYW4ndCBiZQ0KYWRkaXRp b25hbCBwcm90b2NvbChzKSAobm90IHNwZWNpZmllZCBoZXJlKSB0aGF0IGFyZSB1c2VkIGJldHdl ZW4NCkRFQ0FERSBzZXJ2ZXJzIGFzIHdlbGwuICBGb3IgZXhhbXBsZSwgaWYgREVDQURFIHNlcnZl cnMgd2l0aGluIGFuDQphZG1pbmlzdHJhdGl2ZSBkb21haW4gY2FuIGNlcnRhaW5seSBoYXZlIHRo ZWlyIG93biBtZWNoYW5pc20gdG8gc2hhcmUNCnN1Y2ggaW5mb3JtYXRpb24uICBJZiBzdWNoIGNh cGFiaWxpdGllcyB3ZXJlIGluY2x1ZGVkIGluIHRoZSBERUNBREUNCnByb3RvY29sIChlLmcuLCBh IG5lZWQgdG8gZG8gdGhpcyBiZXR3ZWVuIGFkbWluaXN0cmF0aXZlIGRvbWFpbnMpLA0KdGhhdCBz b3VuZHMgbGlrZSBsb3RzIG1vcmUgY29tcGxleGl0eSB0aGF0IHdlIG5lZWQgYXQgdGhpcyBwb2lu dC4NCmJ1dCB0aGUgYWNjZXNzIGJldHdlZW4gaW4tbmV0d29yayBzdG9yYWdlIGFsc28gaXMgaW5j bHVkZWQgaW4gSUFQIGRlc2NyaWJlZCBpbiBwcm9ibGVtIHN0YXRlbWVudC4gIGkgbWVhbiB3aHkg bm90IHB1dCB0aGlzIGtpbmQgb2YgZnVuY3Rpb24gaW4gREVDQURFIHNpbmNlIHRoZSBJQVAgaXMg ZGVmaW5lZCBqdXN0IGxpa2UgdGhhdD8NClRoYXQgc2FpZCwgaXQgc291bmRzIHRvIG1lIGxpa2Ug d2hhdCBpcyBkZXNjcmliZWQgaW4gNC4xLjYuMyB3b3VsZCBiZQ0Kc3VmZmljaWVudCAoZnJvbSB0 aGUgcGVyc3BlY3RpdmUgb2YgdGhlIGNsaWVudC1zZXJ2ZXIgcHJvdG9jb2wsDQphbnl3YXlzKSB0 byBpbXBsZW1lbnQgd2hhdCB5b3UncmUgZGVzY3JpYmluZy4gSWYgbm90LCB3aGF0DQpzcGVjaWZp Y2FsbHkgaXMgbWlzc2luZyBhbmQgd2hhdCB1c2UtY2FzZSBkb2VzIGl0IG5vdCBtZWV0Pw0Kc28g eW91IG1lYW4gdGhlIGluZm9ybWF0aW9uIHlvdSBtZW50aW9uZWQgYWJvdmUsIGp1c3QgbGlrZSBj dXJyZW50IHVzZXIgc3RhdGUgKGUuZy4sDQpxdW90YSwgcmVjZW50IHJlc291cmNlIHVzYWdlIGhp c3RvcnksIHBlcm1pc3Npb25zLCBldGMpIHdhcyBhbHJlYWR5IGluY2x1ZGVkIGluIERFQ0FERSBy ZXF1aXJlbWVudD8gd2hhdCBhYm91dCB0aGUgZGF0YSBkZWxpdmVyeSBwcm9jZWVkaW5nIGluZm9y bWF0aW9uPyBjYW4geW91IHNwZWNpZnkgdGhlIGNoYXB0ZXIgZm9yIG1lID8gdGhhbmtzPw0KPj4g Pg0KPj4gPg0KPj4gPj4NCj4+ID4+IERhdGEgRGlzdHJpYnV0aW9uOg0KPj4gPj4NCj4+ID4+IEkn bSBhbHNvIGNvbmZ1c2VkIGFib3V0IHRoZSBpbnRlbnQgb2YgdGhpcyByZXF1aXJlbWVudC4gIFRo aXMNCj4+ID4+IHN0YXRlbWVudCBoYXMgbWUgc29tZXdoYXQgd29ycmllZDogIlRoZSBkaXN0cmli dXRpb24gaXMgdHJhbnNwYXJlbnQgdG8NCj4+ID4+IHRoZSB1c2VycyBhcyB0aGV5IGludGVyYWN0 IHdpdGggdGhlIGluLW5ldHdvcmsgc3RvcmFnZSBhcyBhIHNpbmdsZQ0KPj4gPj4gbG9naWNhbCBz eXN0ZW0uIiBEb2VzIHRoaXMgbWVhbiB0aGF0IHlvdSBhcmUgcHJvcG9zaW5nIGZvciBERUNBREUN Cj4+ID4+IHNlcnZlcnMgdG8gYXNzdW1lIHRoZSByZXNwb25zaWJpbGl0eSBmb3IgZGVjaWRpbmcg aG93IGRhdGEgaXMgdG8gYmUNCj4+ID4+IGRpc3RyaWJ1dGVkIHRocm91Z2hvdXQgdGhlIG5ldHdv cmssIGluY2x1ZGluZyB0aGUgcGF0aCBvZiB0aGUgZGF0YSwNCj4+ID4+IHdoaWNoIHNlcnZlcnMg YWN0IGFzIGludGVybWVkaWF0ZSBjYWNoZXMsIGNvbnRlbnQgZXhwaXJhdGlvbiBwb2xpY2llcywN Cj4+ID4+IGV0Yz8gIElmIHRoaXMgaXMgdHJ1ZSwgSSB0aGluayBpdCBpcyBtaXNzaW5nIG9uZSBv ZiB0aGUgbWFqb3IgcG9pbnRzDQo+PiA+PiBvZiBERUNBREUuIEluIHBhcnRpY3VsYXIsIHRoZXNl IGRlY2lzaW9ucyBhcmUgYXBwbGljYXRpb24tZGVwZW5kZW50DQo+PiA+PiBhbmQgYXJlIG5vdCBp bXBsZW1lbnRlZCB3aXRoaW4gREVDQURFLiBJbnN0ZWFkLCBERUNBREUgcHJvdmlkZXMgdGhlDQo+ PiA+PiBiYXNpYyBjYXBhYmlsaXRpZXMgYW5kIHRoZSBmdW5jdGlvbmFsaXR5IGRlc2NyaWJlZCBh Ym92ZSBhcmUNCj4+ID4+IGltcGxlbWVudGVkIGJ5IHRoZSBhcHBsaWNhdGlvbnMgdXNpbmcgREVD QURFLg0KPj4gPj4NCj4+ID4+IE9yLCBhbSBJIG1pc2ludGVycHJldGluZyB0aGUgaW50ZW50IG9m IHRoZSByZXF1aXJlbWVudD8NCj4+ID4+DQo+PiA+IHlvdSBtZWFuIERFQ0FERSBwcm92aWRlcyB0 aGUgYmFzaWMgY2FwYWJpbGl0aWVzLCBzbyBjYW4geW91IGdpdmUgc29tZQ0KPj4gPiBzcGVjaWZ5 IGV4cGxhbmF0aW9ucyBvbiBERUNBREUgY2FwYWJpbGl0aWVzIGluIHN1cHBvcnRpbmcgZGF0YSBk aXN0cmlidXRpb24/DQo+PiA+Pg0KPj4NCj4+IFRoZSBwcm9ibGVtIHN0YXRlbWVudCBnaXZlcyBh IGNvdXBsZSBvZiBzY2VuYXJpb3MuIFRoZSAiSW50ZWdyYXRpb24NCj4+IEV4YW1wbGVzIiBwcmVz ZW50YXRpb24gZnJvbSBJRVRGIDc5IGFsc28gaGFzIG1vcmUgZGV0YWlscyBvZiBhbg0KPj4gb24t Z29pbmcgZWZmb3J0IGF0IFlhbGUuDQoNCj4gb2theSwgdGh4IGZvciB5b3VyIGluZm9ybWF0aW9u LCBpIHdpbGwgbG9va3VwIGFuZCByZWZlciwgYWN0dWFsbHksIHRoZQ0KPiBjb250ZW50IHB1Ymxp c2hlciBkZXNjcmliZWQgaW4gcHJvYmxlbSBzdGF0ZW1lbnQgcmVtaW5kIG1lIG9mICB0aGUNCj4g cHJvdG9jb2wgcmVxdWlyZW1lbnRzIHdoaWNoIGkgZGlkIG5vdCBmaW5kIGluIGRyYWZ0LWlldGYt ZGVjYWRlLXJlcXMtMDAgdG8NCj4gc3VwcG9ydCBjb250ZW50IHB1Ymxpc2guIG9yIGkgbWlzcyBz b21lIHBvaW50cz8NCldoaWNoIHJlcXVpcmVtZW50cyBkbyB5b3UgdGhpbmsgYXJlIG1pc3Npbmc/ DQoNCj4+ID4+IFNlcnZpY2UgQXNzdXJhbmNlOg0KPj4gPj4NCj4+ID4+IEl0IHNlZW1zIHByb2Js ZW1hdGljIHRvIGluY2x1ZGUgImFzc3VyYW5jZSIgaW4gYSBERUNBREUuICBTaG91bGRuJ3QNCj4+ ID4+IHRoZXNlIGluc3RlYWQgYmUgcGFydCBvZiBTTEFzIHdpdGggYSBzdG9yYWdlIHByb3ZpZGVy PyAgV2h5IHNob3VsZA0KPj4gPj4gdGhleSBiZSBERUNBREUncyByZXNwb25zaWJpbGl0eT8NCj4+ ID4+DQo+PiA+PiBSZWdhcmRpbmcgInJlc291cmNlIHJlc2VydmF0aW9uIiwgYXJlIHlvdSByZWZl cnJpbmcgdG8gYW4gYWN0dWFsDQo+PiA+PiByZXNlcnZhdGlvbiAod2hpY2ggbWlnaHQgYmUgcHJv YmxlbWF0aWMgLS0gc2VlIGFib3ZlKSBvciBkbyB5b3UgbWVhbg0KPj4gPj4gdGhhdCB0aGUgcmVz b3VyY2Ugc2hhcmUgc2hvdWxkIGFibGUgdG8gYmUgc3BlY2lmaWVkIGF0IHRoZSB0aW1lIHRoZQ0K Pj4gPj4gY29ubmVjdGlvbiBvcGVucyBhbmQgYmUgYXNzdW1lZCB0byBiZSB0aGUgc2FtZSBmb3Ig dGhlIGR1cmF0aW9uIG9mIHRoZQ0KPj4gPj4gY29ubmVjdGlvbj8NCj4+ID4+DQo+PiA+PiBSZWdh cmRpbmcgRHluYW1pYyBGZWVkYmFjaywgaXMgdGhpcyBvcnRob2dvbmFsIHRvIHRoZSBzdG9yYWdl DQo+PiA+PiBwcm90b2NvbD8gIEl0IHNlZW1zIGxpa2Ugd2hhdCB5b3Ugd2FudCBoZXJlIGlzIGEg Z2VuZXJpYyAic3RhdHVzIg0KPj4gPj4gc2VydmljZSBzYXlpbmcgaG93IGxvYWRlZCBhIHNlcnZl ciBpcz8NCj4+ID4+DQo+PiA+IHRoYXRzIHJpZ2h0LCBhY3R1YWxseSwgdGhlIGZsb3cgY29udHJv bCBtZWNoYW5pc20gd2FzIHVuZGVyIGRpc2N1c3Npb24NCj4+ID4gaW4gd3JpdGluZyB0aGUgZHJh ZnQgYXQgZmlyc3QuIHdoYXQgYWJvdXQgeW91ciBvcGluaW9uIGluIHRoaXMgcmVxdWlyZW1lbnRz Pw0KPj4gPg0KPj4NCj4+IEknbSBub3Qgc3VyZSB3aGF0IHRoZSB0eXBpY2FsIHdheSBvZiBwcm92 aWRpbmcgc3VjaCAibG9hZCBzdGF0dXMiDQo+PiBpbmZvcm1hdGlvbiBmb3IgSUVURiBwcm90b2Nv bHMsIGJ1dCBteSBpbmNsaW5hdGlvbiBpcyB0aGF0IGl0IHNob3VsZA0KPj4gbm90IGJlIGluIHRo ZSBERUNBREUgcHJvdG9jb2wgaXRzZWxmLiAgTWF5YmUgc29tZW9uZSBlbHNlIHdpdGggYQ0KPj4g bG9uZ2VyIGhpc3RvcnkgaW4gSUVURiBjb3VsZCBqdW1wIGluIGhlcmUgOikNCj4gc28gY2FuIGkg dW5kZXJzdGFuZCB0aGF0ICJsb2FkIHN0YXR1cyIgaXMga2luZCBvZiBuZWNlc3NpdHkgIGluZm9y bWF0aW9uDQo+IGZvciBERUNBREUgU2VydmVyLCBidXQgd2hlcmUgYW5kIHdobyBjb2xsZWN0cyB0 aGUgaW5mb3JtYXRpb24gYXJlDQo+IHJlbWFpbiBkaXNjdXNzaW9uPw0KVGhlIHN0b3JhZ2UgcHJv dmlkZXIgaXMgZnJlZSB0byBjb2xsZWN0IHRoZSBpbmZvcm1hdGlvbiB3aGVyZXZlciBhbmQNCmhv d2V2ZXIgdGhleSB3aXNoLiAgVGhlIERFQ0FERSBzZXJ2ZXIgaW1wbGVtZW50YXRpb24gY291bGQg YWRkaXRpb25hbA0KZXhwb3J0IHdoYXRldmVyIHN0YXR1cyBpbmZvcm1hdGlvbiBpdCB3aXNoZXMu IEkgZG9uJ3QgdGhpbmsgdGhlIERFQ0FERQ0KcHJvdG9jb2wgbmVlZHMgdG8gYmUgY29uY2VybmVk IHdpdGggdGhhdC4NCg0KTm90ZSB0aGF0IGNlcnRhaW4gZXJyb3IgY29uZGl0aW9ucyAoZS5nLiwg b3ZlcmxvYWQsIGluc3VmZmljaWVudA0KcmVzb3VyY2VzKSBtYXkgYmUgc2lnbmFsZWQgYnkgYSBE RUNBREUgc2VydmVyICh0aGVyZSBhcmUgYWxyZWFkeSBoYXZlDQpyZXF1aXJlbWVudHMgZm9yIHRo b3NlKS4gIElmIHlvdSBhcmUgcmVmZXJyaW5nIHRvIHN0YXR1cyBmb3IgYSB1c2VyJ3MNCnJlc291 cmNlcywgdGhlcmUgaXMgYWxyZWFkeSBhIHJlcXVpcmVtZW50IGZvciB0aGF0IHRvby4NCg0KSSdt IGp1c3Qgbm90IGNvbnZpbmNlZCB0aGF0IHRoZSBERUNBREUgcHJvdG9jb2wgbmVlZHMgdG8gZXhw b3J0IGl0cw0KY3VycmVudCBsb2FkIHN0YXR1cyB0byBjbGllbnRzLg0KYWN0dWFsbHkgaSBhbSBu b3Qgc3VyZSB3aGljaCBlbGVtZW50cyBpbiBERUNBREUgbmVlZHMgdGhlIGxvYWQgc3RhdHVzLChE RUNBREUgY2xpZW50IG9yIG5ldHdvcmsgc3RvcmFnZSBpZiB0aGUgbmV0d29yayBzdG9yYWdlIG5l ZWRzIHRvIHJlZGlyZWN0IHRoZSByZXF1ZXN0IG9yIGJvdGg/KS4NCg0KQW5kIHRoZSByZXF1aXJl bWVudCBkcmFmdCBjdXJyZW50bHkgc2VlbXMgZGVzY3JpYmUgdGhlIG92ZXJsb2FkIGNvbmRpdGlv biBhcyB0aGUgZXZlbnQgdHJpZ2dlcmluZy4gZG8geW91IHRoaW5rIGlmIGl0IGlzIG5lY2Vzc2Fy eSB0byBwZXJpb2RpY2FsbHkgcmVwb3J0aW5nIG9mIHRoZSBERUNBREUgbmV0d29yayBzdGF0dXMg dG8gY2xpZW50IGZvciBpdHMgbmV0d29yayBzdG9yYWdlIHNlbGVjdGlvbj8NCg0KYW5kIHRoZSBy ZXF1aXJlbWVudCBkcmFmdCBqdXN0IGRlc2NyaWJlIERFQ0FERSB3aGljaCBpcyBidXN5IHRvIHNl cnZlIG90aGVyIHJlcXVlc3RzIG11c3QgYmUgYWJsZSB0byByZWplY3QgcmVxdWVzdHMsIG5vdCBj b25zaWRlciBob3cgdG8gaGFuZGxlIHRoZSB1c2VyIHJlcXVlc3QgYWZ0ZXIgYmVpbmcgcmVqZWN0 ZWQ/DQoNCj4+ID4+DQo+PiA+PiBEYXRhIGNsYXNzaWZpY2F0aW9uOg0KPj4gPj4NCj4+ID4+IFdv dWxkIGl0IGJlIGJldHRlciB0byBpbnN0ZWFkIGhhdmUgdGhlIGNsaWVudCBzcGVjaWZ5IHByb3Bl cnRpZXMgb2YNCj4+ID4+IHRoZSBjb250ZW50IGluc3RlYWQgb2YgcGxhY2UgaXQgaW50byA/IFNl ZQ0KPj4gPj4gd3d3LmlldGYub3JnL3Byb2NlZWRpbmdzLzc4L3NsaWRlcy9uZnN2NC0wLnBkZjxo dHRwOi8vd3d3LmlldGYub3JnL3Byb2NlZWRpbmdzLzc4L3NsaWRlcy9uZnN2NC0wLnBkZj4gZm9y IGFuIGV4YW1wbGUgb2YgdGhpcw0KPj4gPj4gYXBwcm9hY2ggZm9yIE5GUy4NCj4+ID4+DQo+PiA+ PiBJIHRoaW5rIGEgcHJvYmxlbSB3aXRoIGNsYXNzaWZ5aW5nIGFwcGxpY2F0aW9ucyBpcyB0aGF0 IGl0IGFzc3VtZXMNCj4+ID4+IHRoYXQgYXBwbGljYXRpb25zIGZpdCBvbmUgb2YgdGhlIHN1cHBs aWVkIGNsYXNzaWZpY2F0aW9ucy4gV2hhdCBpZiBpdA0KPj4gPj4gbWF5IGZpdCBtdWx0aXBsZSBj bGFzc2lmaWNhdGlvbnM/IG9yIG5vbmU/ICBBbm90aGVyIHByb2JsZW0gaXMgaXQNCj4+ID4+IGFz c3VtZXMgdGhhdCBzZXJ2ZXJzIGFzc3VtZSBiYXNlZCBvbiBpbmRpcmVjdCBhbmQgYXNzdW1lZCBp bmZvcm1hdGlvbg0KPj4gPj4gdGhhdCB0aGV5IGtub3cgd2hhdCB0byBkbyB3aXRoIGEgcGFydGlj dWxhciBwaWVjZSBvZiBjb250ZW50LiBXaHkgbm90DQo+PiA+PiBoYXZlIGFuIGFwcGxpY2F0aW9u IHNwZWNpZnkgaXRzIGRlc2lyZXMgZGlyZWN0bHk/DQo+PiA+Pg0KPj4gPg0KPj4gPg0KPj4gPj4N Cj4+ID4+IFNtYWxsIE9iamVjdHM6DQo+PiA+Pg0KPj4gPj4gV2hhdCBpcyB0aGUgbmV3IHJlcXVp cmVtZW50IGhlcmU/ICBXaHkgaXMgdGhlIGV4aXN0aW5nIHJlcXVpcmVtZW50IGluDQo+PiA+PiBk cmFmdC1pZXRmLWRlY2FkZS1yZXFzLTAwIGluc3VmZmljaWVudD8NCj4+ID4+DQo+PiA+PiBUaGlz IGFsc28gaGFzIG1lIGEgYml0IHdvcnJpZWQ6DQo+PiA+PiAiQW5kIHRoZSBpbi1uZXR3b3JrIHN0 b3JhZ2UgaGFzIHRoZSBsaW1pdGVkIHN0b3JhZ2UgY2FwYWNpdHksIHdpdGggdGhlDQo+PiA+PiBh cnJpdmFsIG9mIHVzZXIgcmVxdWVzdHMgYW5kIGRhdGEgZGlzdHJpYnV0aW9uIHJlcXVpcmVtZW50 cywgdGhlIGRhdGENCj4+ID4+IHN0b3JlZCBpbiB0aGUgaW4tbmV0d29yayBzdG9yYWdlIHdpbGwg YmUgcmVwbGFjZWQgaWYgdGhlIHN0b3JhZ2UNCj4+ID4+IHJlYWNoZXMgdGhlIGxpbWl0IGFuZCBk YXRhIGFycml2YWxzIGNvbnRpbnVhbGx5LiINCj4+ID4+DQo+PiA+PiBIb3cgZG9lcyB0aGUgc2Vy dmVyIGtub3cgd2hhdCB0aGUgcHJvcGVyIHJlcGxhY2VtZW50IHN0cmF0ZWd5IGlzIGZvcg0KPj4g Pj4gYW4gYXBwbGljYXRpb24/IEkgdGhpbmsgREVDQURFJ3MgcGhpbG9zb3BoeSBpcyB0aGF0IGFw cGxpY2F0aW9ucw0KPj4gPj4gc2hvdWxkIGRlY2lkZSB0aGlzLiBBIHNpbXBsZSB3YXkgdG8gZG8g dGhpcyBpcyBleHBsaWNpdCBkZWxldGlvbiBieSBhbg0KPj4gPj4gYXBwbGljYXRpb24sIGJ1dCBw ZXJoYXBzIGEgbW9yZSBlZmZpY2llbnQgKHlldCBtb3JlIGNvbXBsZXgpIHNvbHV0aW9uDQo+PiA+ PiBpcyBmb3IgYW4gYXBwbGljYXRpb24gdG8gc3BlY2lmeSB0aGUgcmVwbGFjZW1lbnQgcG9saWN5 IHRvIHRoZSBzZXJ2ZXIuDQo+PiA+Pg0KPj4gPiBhY3R1YWxseSwgdGhlIGtleSBpbiAidGhlIGRh dGEgY2xhc3NpZmljYXRpb24gYW5kIHNtYWxsIG9iamVjdHMgIiBpcw0KPj4gPiB3aGV0aGVyIGRv ZXMgaXQgb3Igbm90IGluIFAyUCBhcHBsaWNhdGlvbj8gaSBkaWQgbm90IGZpbmQgZGF0YQ0KPj4g PiBjbGFzc2lmaWNhdGlvbiB3YXMgYWRvcHRlZCBpbiBQMlAgYXBwbGljYXRpb24gc28gZmFyLCBs ZXQgYWxvbmUgREVDQURFIG5lZWQNCj4+ID4gdG8gY2xhc3NpZnkgdGhlIGRhdGEgdXNlZCBpbiBh bGwga2luZHMgb2YgYXBwbGljYXRpb24uDQo+PiA+DQo+Pg0KPj4gU28sIGRvIHlvdSBhZ3JlZSB0 aGF0IGl0IGlzIHByb2JsZW1hdGljIHRvIHRyeSBhbmQgY2xhc3NpZnkgZWFjaCB0eXBlDQo+PiBv ZiBhcHBsaWNhdGlvbiBhbmQgdHJ5IHRvIHNwZWNpZnkgdGhlIHR5cGljYWwgd29ya2xvYWQgZm9y IGVhY2ggY2xhc3M/DQo+Pg0KPj4gTXkgcG9pbnQgd2FzIHRoYXQgSSBkb24ndCB0aGluayBpdHMg bmVjZXNzYXJ5IHRvIGRvIHRoZSBjbGFzc2lmaWNhdGlvbg0KPj4gYXQgYWxsLiAgSXQgaXMgbW9y ZSBleHRlbnNpYmxlIChhbmQgZGlyZWN0bHkgdXNlZnVsKSBmb3IgYSBzZXJ2ZXIgdG8NCj4+IGp1 c3QgZ2l2ZSBpdCBkaXJlY3QgaGludHMgYWJvdXQgd2hhdCB3b3VsZCBiZSBwcmVmZXJhYmxlLg0K Pg0KPiB5ZXAsIGkgYmVsaWV2ZSBpdCBtYXkgYmUgYSBsaXR0bGUgZGlmZmljdWx0LCBidXQgd29y dGh5IGRvaW5nLiBzcGVjaWFsbHkNCj4gZm9yIGltcHJvdmluZyB0aGUgcmVzb3VyY2UgdXRpbGl6 YXRpb24gd2l0aGluIGEgc2luZ2xlIHNlcnZlciBhbmQgcmVkdWNpbmcNCj4gdGhlIHJlc3BvbnNl IHRpbWUgZm9yIGNsaWVudC4gd2hhdCBhYm91dCBvdGhlcnMgb3Bpbmlvbj8NCkNhbiB5b3UganVz dGlmeSB3aHkgZ2l2aW5nIGNsYXNzaWZpY2F0aW9ucyAoZS5nLiwgIkknbSBhIGxpdmUNCnN0cmVh bWluZyBhcHBsaWNhdGlvbiIpIHdvdWxkIGJlIGJldHRlciB0aGFuIGdpdmluZyBzcGVjaWZpYyBo aW50cw0KKGUuZy4sICJwbGVhc2UgZG9uJ3QgYm90aGVyIHBlcnNpc3RlbnQgdGhlc2Ugb2JqZWN0 cyB0byBkaXNrIik/DQppIG1lYW4gZGF0YSBpbiBkaWZmZXJlbnQga2luZCBvZiBvcGVyYXRpb24g bW9kZSBhbmQgYXR0cmlidXRlIHNob3VsZCBoYXZlIGRpZmZlcmVudCB1c2VyIHBhdHRlcm5zIGFu ZCBzdG9yYWdlIHJ1bGVzLCB3aGljaCBtYXkgYmUgaGVscCB0byBpbXByb3ZlIHRoZSByZXNvdXJj ZSB1dGlsaXphdGlvbiBhbmQgcmVkdWNlIHRoZSByZXNwb25zZSB0aW1lIGZvciByZXF1ZXN0LCB3 aGF0IGFyZSB5b3UgdW5kZXJzdGFuZGluZz8NCj4gPj4NCj4+ID4+IFJlbW92YWwgb2YgRXhwaXJl ZCBSZWNvcmRzOg0KPj4gPj4NCj4+ID4+ICJIb3dldmVyLCB0aGUgdHdvIHNjZW5hcmlvcyBkaWQg bm90IG1lbnRpb24gaG93IHRvIGhhbmRsZSB0aGUgb2xkDQo+PiA+PiByZXNvdXJjZSBpZiB0aGUg dXNlciBkaXN0cmlidXRlcyB0aGUgbmV3IHJlc291cmNlIHdoaWNoIGlzIGFuIHVwZGF0ZWQNCj4+ ID4+IGNvcHkgb2YgdGhlIG9sZCByZXNvdXJjZS4iDQo+PiA+Pg0KPj4gPj4gV2h5IGRvZXMgdGhp cyBuZWVkIHRvIGJlIGhhbmRsZWQgaW4gdGhlIHJlcXVpcmVtZW50cz8gIEFyZSB5b3UgdHJ5aW5n DQo+PiA+PiB0byBkcmF3IHRoZSBkaXN0aW5jdGlvbiBiZXR3ZWVuIGltbWVkaWF0ZSBkZWxldGlv biBvZiBjb250ZW50IGFuZCBsYXp5DQo+PiA+PiBkZWxldGlvbj8NCj4+ID4+DQo+PiA+IGkgbWVh biB0aGUgbWVhbmluZyBvZiBkZWxldGUgb3BlcmF0aW9uIGFuZCBob3cgdG8gaGFuZGxlIHRoZSBl eHBpcmVkDQo+PiA+IHJlY29yZHMgbmVlZCB0byBiZSBjbGFyaWZ5IGluIHJlcXVpcmVtZW50cy4N Cj4+DQo+PiBNeSBpbmNsaW5hdGlvbiBpcyB0aGF0ICJkZWxldGVkIiBtZWFucyB0aGF0IG90aGVy IHJlcXVlc3RzIHRoZSBvYmplY3QNCj4+IG9mIHRoZSBzYW1lIG5hbWUgc2hvdWxkIHJlc3VsdCBh biBlcnJvciwgdW50aWwgYW5vdGhlciBvYmplY3Qgd2l0aCB0aGUNCj4+IHNhbWUgbmFtZSBpcyBz dG9yZWQuDQo+DQo+IG9rYXksIHVuZGVyIHRoZSBzY2VuYXJpbyAiY2xpZW50IHVwbG9hZHMgdGhl IG5ldyB2ZXJzaW9uLCBhbmQgZGlkIG5vdA0KPiBzcGVjaWZ5IGhvdyB0byBoYW5kbGUgdGhlIG9s ZCB2ZXJzaW9uIiwgZGlkIERFQ0FERSBzZXJ2ZXIgZGVsZXRlIHRoZSBvbGRlcg0KPiB2ZXJzaW9u IChvciBqdXN0IGxhYmVsIGl0IHVuYXZhaWxhYmxlLCBhbnl3YXksIGl0IGlzIGltcGxlbWVudGF0 aW9uIGlzc3VlICkNCj4gb3Igbm90ID8gaW4gYW5vdGhlciB3b3JkLCBqdXN0IHJlcGxhY2UgdGhl IG9sZGVyIHZlcnNpb24gd2l0aCB0aGUgbmV3DQo+IHZlcnNpb24gd2l0aCB0aGUgc2FtZSBuYW1l Pw0KSW4gdGhpcyBjYXNlLCBJIHdvdWxkIHRoaW5rIHRoZSAid3JpdGUiIG9mIHRoZSBuZXcgb2Jq ZWN0IHNob3VsZCBiZQ0KcmVqZWN0ZWQsIG9yIGlmIGRlc2lyZWQsIHdlIGNvdWxkIGhhdmUgYW4g b3ZlcndyaXRlIG9wdGlvbi4gIFRoaXMNCmNvdWxkIGJlIGFkZGVkIHRvIHRoZSByZXF1aXJlbWVu dHMgaWYgaXQgaGVscHMgdG8gY2xhcmlmeS4NCnllcCwgbm8gbWF0dGVyIHdoaWNoIHNvbHV0aW9u IGlzIGNob3NlbiwgbGV0IHRoZSB1bmRlcnN0YW5kaW5nIHVuYW5pbW91c2x5OkQNCj4gaG93IHRv IGhhbmRsZSB0aGUgb2xkZXIgdmVyc2lvbiB3aGljaCBpcw0KPiB0cmFuc2ZlcnJpbmcgZnJvbSBz ZXJ2ZXIgdG8gY2xpZW50Pw0KSSB0aGluayBpdCB3b3VsZCBiZSBjbGVhbmVyIHRvIGFzayB0aGUg c2VydmVyIHRvIGNvbnRpbnVlIHNlbmRpbmcgYW4NCm9iamVjdCBvbmNlIGl0IGhhcyBiZWVuIHN0 YXJ0ZWQsIGJ1dCB1bHRpbWF0ZWx5IHRoaXMgd291bGQgYmUgdGhlDQpkZWNpc2lvbiBvZiB0aGUg c2VydmVyJ3MgaW1wbGVtZW50YXRpb24gSSB0aGluay4gIE1heWJlIGEgIlNIT1VMRCINCnJlcXVp cmVtZW50LiAgVGhpcyBjb3VsZCBiZSBhZGRlZCBpZiBkZXNpcmVkLg0KDQpUaGFuayB5b3UgZm9y IHRoZXNlIHF1ZXN0aW9ucy4gIEl0IGhlbHBzIGRlc2lnbiB0aGUgcmVxdWlyZW1lbnRzIG1vcmUN CmNsZWFubHkgaWYgdGhlcmUgYXJlIHNwZWNpZmljIHNjZW5hcmlvcyBpbiBmcm9udCBvZiB1cyA6 KQ0KanVzdCBkaXNjdXNzaW9uIHRvZ2V0aGVyOkQgYW5kIGFsc28gdGhhbmtzIGZvciB5b3VyIHBv aW50cyB0byBoZWxwIG1lIHVuZGVyc3RhbmRpbmcgbW9yZSENClJpY2gNCg0KPj4gSSB0aGluayB0 aGF0IHRoZSB0aW1lIHRoZSBkYXRhIGlzIHJlbW92ZWQgZnJvbSBkaXNrIChvciBtZW1vcnkpIHNo b3VsZA0KPj4gYmUgdXAgdG8gdGhlIGltcGxlbWVudGF0aW9uLiBBIHN0b3JhZ2UgcHJvdmlkZXIg bWlnaHQgc3RpbGwgaGF2ZSBhcw0KPj4gcGFydCBvZiBzb21lIGFncmVlbWVudCB0aGF0IGRlbGV0 ZWQgZGF0YSB3aWxsIGJlIHJlbW92ZWQgd2l0aGluIFgNCj4+IGRheXMvaG91cnMvbWludXRlcy93 aGF0ZXZlci4NCj4NCj4gICAgYWdyZWUgd2l0aCB5b3UuDQo+Pg0KPj4gSWYgcGVvcGxlIGluIHRo ZSBXRyB0aGluayBpdCBpcyBuZWNlc3NhcnksIHdlIGNvdWxkIGhhdmUgYSByZXF1aXJlbWVudA0K Pj4gdGhhdCBzYXlzIHRoZSBwcm90b2NvbCBzaG91bGQgc3VwcG9ydCBhbiBhcmd1bWVudCBpbmRp Y2F0aW5nIGltbWVkaWF0ZQ0KPj4gZGVsZXRpb24sIGJ1dCBpdCBpcyBub3QgY2xlYXIgdGhhdCB3 ZSBuZWVkIHRoaXMuDQo+Pg0KPj4gUmljaA0KPj4NCj4+ID4+DQo+PiA+PiBUaGFua3MhDQo+PiA+ PiBSaWNoDQo+PiA+Pg0KPj4gPj4NCj4+ID4+IE9uIE1vbiwgRGVjIDI3LCAyMDEwIGF0IDEyOjU3 IEFNLCDW7OTsIDxidXB0eGlhb3podUBnbWFpbC5jb208bWFpbHRvOmJ1cHR4aWFvemh1QGdtYWls LmNvbT4+IHdyb3RlOg0KPj4gPj4gPiBEZWFyIGFsbCwNCj4+ID4+ID4NCj4+ID4+ID4gVGhlcmUg aXMgYSBzbGlnaHRseSB1cGRhdGVkIHZlcnNpb24gb2YgdGhlIGRlY2FkZSBhZGRpdGlvbmFsDQo+ PiA+PiA+IHJlcXVpcmVtZW50cw0KPj4gPj4gPiBkcmFmdC4NCj4+ID4+ID4NCj4+ID4+ID4gaHR0 cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtemh1LWRlY2FkZS1hZGRpdGlvbmFs LXJlcXVpcmVtZW50cy8NCj4+ID4+ID4NCj4+ID4+ID4gSmluIFBlbmcsIFl1bmZlaSBaaGFuZyBh bmQgbWUgYXJlIGV4cGVjdGluZyB0byBoYXZlIGEgZGlzY3Vzc2lvbiB3aXRoDQo+PiA+PiA+IGFs bCBvZg0KPj4gPj4gPiB5b3UuDQo+PiA+PiA+DQo+PiA+PiA+IEFueSBjb21tZW50cyBhcmUgYXBw cmVjaWF0ZWQhDQo+PiA+PiA+DQo+PiA+PiA+IEEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC16 aHUtZGVjYWRlLWFkZGl0aW9uYWwtcmVxdWlyZW1lbnRzLTAwLnR4dA0KPj4gPj4gPiBoYXMgYmVl biBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IFhpYW8gWmh1IGFuZCBwb3N0ZWQgdG8gdGhlIElF VEYNCj4+ID4+ID4gcmVwb3NpdG9yeS4NCj4+ID4+ID4NCj4+ID4+ID4gRmlsZW5hbWU6ICAgICAg ZHJhZnQtemh1LWRlY2FkZS1hZGRpdGlvbmFsLXJlcXVpcmVtZW50cw0KPj4gPj4gPiBSZXZpc2lv bjogICAgICAwMA0KPj4gPj4gPiBUaXRsZTogICAgICAgICAgICAgICAgIEFkZGl0aW9uYWwgcHJv dG9jb2wgcmVxdWlyZW1lbnRzIG9uIERFQ0FERQ0KPj4gPj4gPiBDcmVhdGlvbl9kYXRlOiAgICAg ICAgIDIwMTAtMTItMjcNCj4+ID4+ID4gV0cgSUQ6ICAgICAgICAgICAgICAgICBJbmRlcGVuZGVu dCBTdWJtaXNzaW9uDQo+PiA+PiA+IE51bWJlcl9vZl9wYWdlczogMTANCj4+ID4+ID4NCj4+ID4+ ID4gQWJzdHJhY3Q6DQo+PiA+PiA+IFRoZSBERUNvdXBsZWQgQXBwbGljYXRpb24gRGF0YSBFbnJv dXRlKERFQ0FERSl3b3JraW5nIGdyb3VwIGlzDQo+PiA+PiA+IHNwZWNpZnlpbmcgc3RhbmRhcmRp emVkIGludGVyZmFjZXMgZm9yIGFjY2Vzc2luZyBpbi1uZXR3b3JrIHN0b3JhZ2UNCj4+ID4+ID4g ZnJvbSBhcHBsaWNhdGlvbnMgdG8gc3RvcmUsIHJldHJpZXZlIGFuZCBtYW5hZ2UgZGF0YS4gVGhl IG1haW4gb2JqZWN0DQo+PiA+PiA+IGlzIHRvIHByb3ZpZGUgYSBmcmFtZXdvcmsgdGhhdCBpcyB1 c2VmdWwgdG8gdGhlIGFwcGxpY2F0aW9ucywNCj4+ID4+ID4gaW5jbHVkaW5nIFAyUCBhcHBsaWNh dGlvbnMgYW5kIG90aGVyIGRhdGEtb3JpZW50ZWQgYXBwbGljYXRpb25zLA0KPj4gPj4gPiBwb3Nz aWJseSByZWxhdGVkIGFwcGxpY2F0aW9ucyB0aGF0IGNhbiBiZW5lZml0IGZyb20gYWNjZXNzaW5n IGluLQ0KPj4gPj4gPiBuZXR3b3JrIHN0b3JhZ2UuIFRoaXMgbWVtbyBmb2N1c2VzIG9uIHNvbWUg cmVxdWlyZW1lbnRzIHN1Y2ggYXMNCj4+ID4+ID4gcmVxdWVzdCByZWRpcmVjdGluZyBhbmQgc28g b24gd2hpY2ggYXJlIG9uIHRoZSBjZW50cmFsIG9mIG1vYmlsaXR5LA0KPj4gPj4gPiB3aXJlbGVz cyBuZXR3b3JrIGVudmlyb25tZW50IGFuZCBDRE4gYXBwbGljYXRpb24uIFdlIHByZXNlbnQgdGhl c2UgaW4NCj4+ID4+ID4gdGhpcyBtZW1vIGFzIGFkZGl0aW9uYWwgcmVxdWlyZW1lbnRzIHRoYXQg c2hvdWxkIGJlIGNvbnNpZGVyZWQgZm9yDQo+PiA+PiA+IHRoZSBERUNBREUgYXJjaGl0ZWN0dXJl IGFuZCBwcm90b2NvbCBzcGVjaWZpY2F0aW9ucy4NCj4+ID4+ID4NCj4+ID4+ID4NCj4+ID4+ID4N Cj4+ID4+ID4gVGhlIElFVEYgU2VjcmV0YXJpYXQuDQo+PiA+PiA+DQo+PiA+PiA+IC0tDQo+PiA+ PiA+IEJlc3Qgd2lzaGVzLA0KPj4gPj4gPg0KPj4gPj4gPiBCZWlqaW5nIFVuaXZlcnNpdHkgb2Yg UG9zdHMgJiBUZWxlY29tbXVuaWNhdGlvbnMgKEJVUFQpDQo+PiA+PiA+IFpodSBYaWFvICAoINbs 5OwgKQ0KPj4gPj4gPiBFLW1haWw6IGJ1cHR4aWFvemh1QGdtYWlsLmNvbTxtYWlsdG86YnVwdHhp YW96aHVAZ21haWwuY29tPg0KPj4gPj4gPiBtb2JpbGU6Kzg2IDEzNC04ODgxLTkwMDQNCj4+ID4+ ID4NCj4+ID4+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCj4+ID4+ID4gZGVjYWRlIG1haWxpbmcgbGlzdA0KPj4gPj4gPiBkZWNhZGVAaWV0Zi5vcmc8 bWFpbHRvOmRlY2FkZUBpZXRmLm9yZz4NCj4+ID4+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9kZWNhZGUNCj4+ID4+ID4NCj4+ID4+ID4NCj4+ID4NCj4+ID4NCj4+ID4N Cj4+ID4gLS0NCj4+ID4gQmVzdCB3aXNoZXMsDQo+PiA+DQo+PiA+IEJlaWppbmcgVW5pdmVyc2l0 eSBvZiBQb3N0cyAmIFRlbGVjb21tdW5pY2F0aW9ucyAoQlVQVCkNCj4+ID4gWmh1IFhpYW8gICgg 1uzk7CApDQo+PiA+IEUtbWFpbDogYnVwdHhpYW96aHVAZ21haWwuY29tPG1haWx0bzpidXB0eGlh b3podUBnbWFpbC5jb20+DQo+PiA+IG1vYmlsZTorODYgMTM0LTg4ODEtOTAwNA0KPg0KPg0KPg0K PiAtLQ0KPiBCZXN0IHdpc2hlcywNCj4NCj4gQmVpamluZyBVbml2ZXJzaXR5IG9mIFBvc3RzICYg VGVsZWNvbW11bmljYXRpb25zIChCVVBUKQ0KPiBaaHUgWGlhbyAgKCDW7OTsICkNCj4gRS1tYWls OiBidXB0eGlhb3podUBnbWFpbC5jb208bWFpbHRvOmJ1cHR4aWFvemh1QGdtYWlsLmNvbT4NCj4g bW9iaWxlOis4NiAxMzQtODg4MS05MDA0DQo+DQoNCg0KDQotLQ0KQmVzdCB3aXNoZXMsDQoNCkJl aWppbmcgVW5pdmVyc2l0eSBvZiBQb3N0cyAmIFRlbGVjb21tdW5pY2F0aW9ucyAoQlVQVCkNClpo dSBYaWFvICAoINbs5OwgKQ0KRS1tYWlsOiBidXB0eGlhb3podUBnbWFpbC5jb208bWFpbHRvOmJ1 cHR4aWFvemh1QGdtYWlsLmNvbT4NCm1vYmlsZTorODYgMTM0LTg4ODEtOTAwNA0K --_000_1CA25301D2219F40B3AA37201F0EACD11343C0ABPACDCEXMB05cabl_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Folks,

 

Do we have consensus yet about how the WG could have a singl= e DECADE requirements document going forward? I can=A1=AFt tell the state o= f our requirements consolidation from the email thread below.

 

It would be preferable if we could resolve this fully on the= WG mailing list, but this is important enough to allocate some time at our= meeting in Prague.

 

-- Rich

 

From: decade-b= ounces@ietf.org [mailto:decade-bounces@ietf.org] On Behalf Of ??
Sent: Sunday, January 16, 2011 9:02 PM
To: Richard Alimi
Cc: decade@ietf.org
Subject: Re: [decade] draft-zhu-decade-additional-requirements<= /o:p>

 

hi, Richard:

 

thanks for your reply:D

additional discussion see inline:D

 

2011/1/14 Richard Alimi <rich@velvetsea.net>

HI Xiao,

2011/1/12 =D6=EC=E4=EC <buptxiaozhu@gmail.com>:

> hi, Richard
> see inline:D
>
> 2011/1/11 Richard Alimi <rich= @velvetsea.net>
>>
>> Hi Xiao,
>>
>> On Mon, Jan 10, 2011 at 6:45 PM, =D6=EC=E4=EC= <buptxiaozhu@gmail.com<= /a>> wrote:
>> >
>> > hi, Richard, sorry for so late response because of be busy wi= th other
>> > projects.
>> > some discussion see inline:D marked by red.
>> >
>> > On Tue, Jan 4, 2011 at 4:06 AM, Richard Alimi <rich@velvetsea.net>
>> > wrote:
>> >>
>> >> Hi Xiao,
>> >>
>> >> Thank you for the draft.  Some comments on the re= quirements:
>> >>
>> >> Request Redirects:
>> >>
>> >> This would provide some additional freedom for the storag= e provider.
>> >> I think it is reasonable since it doesn't necessitate add= itional
>> >> complexity for the DECADE server, but allows it if desire= d. However,
>> >> note that it may complicate some of the other components = of the
>> >> design. In particular, if there is a per-user quota for s= torage, is
>> >> the user made aware of the quota at each in-network stora= ge (if there
>> >> is no shared storage between them)?  Resource sharing policies may be
>> >> impacted (e.g., if a bandwidth sharing weight of 1 may me= an something
>> >> different at DECADE server A than it does at DECADE serve= r B).  At
>> >> this point it may be best to just note these so they are = documented,
>> >> but since the specification of the resource sharing polic= ies are still
>> >> being contemplated for the basic case of a single server = it may be
>> >> premature to even try and solve them for the case support= ing
>> >> redirection.
>> >>
>> > actually, you mean two points, right?
>> > 1. whether or not to be ware of the content at each in-networ= k storage
>> > and of course resource sharing policies can be impact in the = request
>> > redirection. your suggestion"just to note these so they = are documented" will
>> > be ok, or DECADE server list with some parameters will be ret= urn for user to
>> > select the appropriate DECADE server, which can avoid the dif= ferent weighted
>> > of the same parameter in server decision. but the parameter u= sed in select
>> > the best DECADE server will be known for DECADE servers, in w= hich other
>> > complexities will be added. anyway, all the solution are the = implementation
>> > issue, which, i believe, does not impact the necessity of the= requirement.
>>
>> In general, I'd agree that the decision about where to redirect wo= uld
>> be an implementation issue.
>>
>> >
>> > 2. you mean "the resource sharing policies are still bei= ng considered in
>> > a single server", so it may be premature to support redi= rection.  the
>> > architecture and protocol will be badly impacted if the requi= rements change.
>> > so the designing can be  taken &nbs= p;step by step, but the requirements should be
>> > overall considered.
>>
>> I said that it is probably premature to consider how resource shar= ing
>> policies works across servers (or even if we need to say anything<= br> >> about it) since we have not determined how to specify them (or rat= her,
>> how little we need to specify in protocol) for a single server. I = did
>> not mean to imply that redirection could not be introduced as a >> requirement.
>>
>
>>
>> >
>> >
>> >>
>> >> Multi-connection:
>> >>
>> >> I'm not quite clear on the intention of the requirement. =  My
>> >> understanding is that you wish the client to be able to h= ave multiple
>> >> connections open spanning multiple DECADE servers. Is tha= t correct?
>> >>
>> >> If so, do we need this stated as a requirement or the pro= tocol? Or is
>> >> this a policy that would be allowed/disallowed by the sto= rage
>> >> provider?
>> >>
>> > yep, your understanding is right, the scenarios were just des= cribed in
>> > draft as "soft handover in wireless environment and dele= te operation in
>> > multi-servers". under these consideration, the authentic= ation and
>> > authorization need to be taken each time when setup connectio= n with a new
>> > DECADE server, or just be taken only once during  the service?
>>
>> The DECADE server should need to do some sort of check on each new=
>> connection, regardless of whether the user has or previously had a=
>> connection open to a different DECADE server, right?  Note that the
>> requirements don't indicate how authentication or authorization is=
>> done, and allow a server to make optimizations if it is enforcing = the
>> same permissions.
>>
>> Can you indicate where the existing authorization-related requirem= ents
>> (in particular, 4.1.6.3 of draft-ietf-decade-reqs-00) do not suffi= ce
>> for the use case you are thinking of?

> as considering the service continuity, the next serving  DECADE server
> should know the progress of the service, how does they know?

By progress of the service, do you mean current user= state (e.g.,
quota, recent resource usage history, permissions, etc)?

yes, and include data delivery proceeding.
> so if the
> service proceeding information should be known by the next serving ser= ver,
> or different servers need to coordinate and schedule each other to ful= fill
> the user request, i believe the the 4.1.6.3 of the draft-ietf-decade-r= eq-00
> cannot satisfy the req. what do you think about?

Note that the protocol that is covered here is the c= lient-server
protocol. Some of the same protocol may be useful between DECADE
servers (especially in different administrative domains) for storing
and retrieving data, but that does not mean that there can't be
additional protocol(s) (not specified here) that are used between
DECADE servers as well.  For example, if DECADE servers within an administrative domain can certainly have their own mechanism to share
such information.  If such capabilities were included in the DECADE=
protocol (e.g., a need to do this between administrative domains),
that sounds like lots more complexity that we need at this point.
but the access between in-network storage also is= included in IAP described in problem statement.  i mean why not put this kind of function in DECADE since = the IAP is defined just like that?
That said, it sounds to me like what is described in 4.1.6.3 would be
sufficient (from the perspective of the client-server protocol,
anyways) to implement what you're describing. If not, what
specifically is missing and what use-case does it not meet?

so you mean the information you mentioned above, just like current user state (e.g.,
quota, recent resource usage history, permissions, etc) was already include= d in DECADE requirement? what about the data delivery proceeding informatio= n? can you specify the chapter for me ? thanks? 
>> >
>> >
>> >>
>> >> Data Distribution:
>> >>
>> >> I'm also confused about the intent of this requirement. <= span style=3D"font-family:"Calibri","sans-serif"">  This
>> >> statement has me somewhat worried: "The distribution= is transparent to
>> >> the users as they interact with the in-network storage as= a single
>> >> logical system." Does this mean that you are proposi= ng for DECADE
>> >> servers to assume the responsibility for deciding how dat= a is to be
>> >> distributed throughout the network, including the path of= the data,
>> >> which servers act as intermediate caches, content expirat= ion policies,
>> >> etc?  If this is true, I think it is missing one = of the major points
>> >> of DECADE. In particular, these decisions are application= -dependent
>> >> and are not implemented within DECADE. Instead, DECADE pr= ovides the
>> >> basic capabilities and the functionality described above = are
>> >> implemented by the applications using DECADE.
>> >>
>> >> Or, am I misinterpreting the intent of the requirement? >> >>
>> > you mean DECADE provides the basic capabilities, so can you g= ive some
>> > specify explanations on DECADE capabilities in supporting dat= a distribution?
>> >>
>>
>> The problem statement gives a couple of scenarios. The "Integ= ration
>> Examples" presentation from IETF 79 also has more details of = an
>> on-going effort at Yale.

> okay, thx for your information, i will lookup and refer, actually, the=
> content publisher described in problem statement remind me of  the
> protocol requirements which i did not find in draft-ietf-decade-reqs-0= 0 to
> support content publish. or i miss some points?

Which requirements do you think are missing?


>> >> Service Assurance:
>> >>
>> >> It seems problematic to include "assurance" in = a DECADE.  Shouldn't
>> >> these instead be part of SLAs with a storage provider?  Why should
>> >> they be DECADE's responsibility?
>> >>
>> >> Regarding "resource reservation", are you refer= ring to an actual
>> >> reservation (which might be problematic -- see above) or = do you mean
>> >> that the resource share should able to be specified at th= e time the
>> >> connection opens and be assumed to be the same for the du= ration of the
>> >> connection?
>> >>
>> >> Regarding Dynamic Feedback, is this orthogonal to the sto= rage
>> >> protocol?  It seems like what you want here is a = generic "status"
>> >> service saying how loaded a server is?
>> >>
>> > thats right, actually, the flow control mechanism was under d= iscussion
>> > in writing the draft at first. what about your opinion in thi= s requirements?
>> >
>>
>> I'm not sure what the typical way of providing such "load sta= tus"
>> information for IETF protocols, but my inclination is that it shou= ld
>> not be in the DECADE protocol itself.  Maybe someone else with a
>> longer history in IETF could jump in here :)
> so can i understand that "load status" is kind of necessity =  information
> for DECADE Server, but where and who collects the information are
> remain discussion?

The storage provider is free to collect the informat= ion wherever and
however they wish.  The DECADE server implementation could addition= al
export whatever status information it wishes. I don't think the DECADE
protocol needs to be concerned with that.

Note that certain error conditions (e.g., overload, insufficient
resources) may be signaled by a DECADE server (there are already have
requirements for those).  If you are referring to status for a user= 's
resources, there is already a requirement for that too.

I'm just not convinced that the DECADE protocol needs to export its
current load status to clients.

actually i am not sure whi= ch elements in DECADE needs the load status,(DECADE client or network stora= ge if the network storage needs to redirect the request or both?).

 

And the requirement draft = currently seems describe the overload condition as the event triggering. do= you think if it is nece= ssary to periodically reporting of the DECADE network status to client for its netw= ork storage selection?

 

and the requirement draft just describe DECADE which is busy to= serve other requests must be able to reject requests, not consider how to = handle the user request after being rejected? 

>> >>
>> >> Data classification:
>> >>
>> >> Would it be better to instead have the client specify pro= perties of
>> >> the content instead of place it into ? See
>> >> www.ietf.org/proceedings/78/slides/nfsv4-0.pdf for an example of this >> >> approach for NFS.
>> >>
>> >> I think a problem with classifying applications is that i= t assumes
>> >> that applications fit one of the supplied classifications= . What if it
>> >> may fit multiple classifications? or none?  Another problem is it
>> >> assumes that servers assume based on indirect and assumed= information
>> >> that they know what to do with a particular piece of cont= ent. Why not
>> >> have an application specify its desires directly?
>> >>
>> >
>> >
>> >>
>> >> Small Objects:
>> >>
>> >> What is the new requirement here?  Why is the existing requirement in
>> >> draft-ietf-decade-reqs-00 insufficient?
>> >>
>> >> This also has me a bit worried:
>> >> "And the in-network storage has the limited storage = capacity, with the
>> >> arrival of user requests and data distribution requiremen= ts, the data
>> >> stored in the in-network storage will be replaced if the = storage
>> >> reaches the limit and data arrivals continually." >> >>
>> >> How does the server know what the proper replacement stra= tegy is for
>> >> an application? I think DECADE's philosophy is that appli= cations
>> >> should decide this. A simple way to do this is explicit d= eletion by an
>> >> application, but perhaps a more efficient (yet more compl= ex) solution
>> >> is for an application to specify the replacement policy t= o the server.
>> >>
>> > actually, the key in "the data classification and small = objects " is
>> > whether does it or not in P2P application? i did not find dat= a
>> > classification was adopted in P2P application so far, let alo= ne DECADE need
>> > to classify the data used in all kinds of application.
>> >
>>
>> So, do you agree that it is problematic to try and classify each t= ype
>> of application and try to specify the typical workload for each cl= ass?
>>
>> My point was that I don't think its necessary to do the classifica= tion
>> at all.  It is more extensible (and directly useful) for a= server to
>> just give it direct hints about what would be preferable.
>
> yep, i believe it may be a little difficult, but worthy doing. special= ly
> for improving the resource utilization within a single server and redu= cing
> the response time for client. what about others opinion?

Can you justify why giving classifications (e.g., &q= uot;I'm a live
streaming application") would be better than giving specific hints
(e.g., "please don't bother persistent these objects to disk")?

i mean data in different kind of operation mode and attribute should h= ave different user patterns and storage rules, which may be help to improve= the resource utilization and reduce the response time for request, what are you understanding?
> >>
>> >> Removal of Expired Records:
>> >>
>> >> "However, the two scenarios did not mention how to h= andle the old
>> >> resource if the user distributes the new resource which i= s an updated
>> >> copy of the old resource."
>> >>
>> >> Why does this need to be handled in the requirements?  Are you trying
>> >> to draw the distinction between immediate deletion of con= tent and lazy
>> >> deletion?
>> >>
>> > i mean the meaning of delete operation and how to handle the = expired
>> > records need to be clarify in requirements.
>>
>> My inclination is that "deleted" means that other reques= ts the object
>> of the same name should result an error, until another object with= the
>> same name is stored.
>
> okay, under the scenario "client uploads the new version, and did= not
> specify how to handle the old version", did DECADE server delete = the older
> version (or just label it unavailable, anyway, it is implementation is= sue )
> or not ? in another word, just replace the older version with the new<= br> > version with the same name?

In this case, I would think the "write" of= the new object should be
rejected, or if desired, we could have an overwrite option.  This
could be added to the requirements if it helps to clarify.

yep, no matter which solution is chosen, let the understanding unanimo= usly:D
> how to handle the older version which is
> transferring from server to client?

I think it would be cleaner to ask the server to con= tinue sending an
object once it has been started, but ultimately this would be the
decision of the server's implementation I think.  Maybe a "SHOULD"
requirement.  This could be added if desired.

Thank you for these questions.  It helps design the requirements mo= re
cleanly if there are specific scenarios in front of us :)
just discussion together:D and also thanks for yo= ur points to help me understanding more!
Rich


>> I think that the time the data is removed from disk (or memory) sh= ould
>> be up to the implementation. A storage provider might still have a= s
>> part of some agreement that deleted data will be removed within X<= br> >> days/hours/minutes/whatever.
>
>    agree with you.
>>
>> If people in the WG think it is necessary, we could have a require= ment
>> that says the protocol should support an argument indicating immed= iate
>> deletion, but it is not clear that we need this.
>>
>> Rich
>>
>> >>
>> >> Thanks!
>> >> Rich
>> >>
>> >>
>> >> On Mon, Dec 27, 2010 at 12:57 AM, = =D6=EC=E4=EC <buptxiaozh= u@gmail.com> wrote:
>> >> > Dear all,
>> >> >
>> >> > There is a slightly updated version of the decade ad= ditional
>> >> > requirements
>> >> > draft.
>> >> >
>> >> > https://datatracker.ietf.org/doc/draft-zhu-decade-additional-requirements/<= /a>
>> >> >
>> >> > Jin Peng, Yunfei Zhang and me are expecting to have = a discussion with
>> >> > all of
>> >> > you.
>> >> >
>> >> > Any comments are appreciated!
>> >> >
>> >> > A new version of I-D, draft-zhu-decade-additional-re= quirements-00.txt
>> >> > has been successfully submitted by Xiao Zhu and post= ed to the IETF
>> >> > repository.
>> >> >
>> >> > Filename:      draft-zhu-decade-additional-requirements
>> >> > Revision:      00
>> >> > Title:                 Additional protocol requirements on DECADE
>> >> > Creation_date:         2010-12-27
>> >> > WG ID:                 Independent Submission
>> >> > Number_of_pages: 10
>> >> >
>> >> > Abstract:
>> >> > The DECoupled Application Data Enroute(DECADE)workin= g group is
>> >> > specifying standardized interfaces for accessing in-= network storage
>> >> > from applications to store, retrieve and manage data= . The main object
>> >> > is to provide a framework that is useful to the appl= ications,
>> >> > including P2P applications and other data-oriented a= pplications,
>> >> > possibly related applications that can benefit from = accessing in-
>> >> > network storage. This memo focuses on some requireme= nts such as
>> >> > request redirecting and so on which are on the centr= al of mobility,
>> >> > wireless network environment and CDN application. We= present these in
>> >> > this memo as additional requirements that should be = considered for
>> >> > the DECADE architecture and protocol specifications.=
>> >> >
>> >> >
>> >> >
>> >> > The IETF Secretariat.
>> >> >
>> >> > --
>> >> > Best wishes,
>> >> >
>> >> > Beijing University of Posts & Telecommunications= (BUPT)
>> >> > Zhu Xiao  ( =D6=EC=E4=EC )
>> >> > E-mail: bup= txiaozhu@gmail.com
>> >> > mobile:+86 134-8881-9004
>> >> >
>> >> > _______________________________________________
>> >> > decade mailing list
>> >> > decade@ietf.org
>> >> > https://www.ietf.org/mailman/listinfo/decade
>> >> >
>> >> >
>> >
>> >
>> >
>> > --
>> > Best wishes,
>> >
>> > Beijing University of Posts & Telecommunications (BUPT) >> > Zhu Xiao  ( =D6=EC=E4=EC )
>> > E-mail: buptxiaozhu@= gmail.com
>> > mobile:+86 134-8881-9004
>
>
>
> --
> Best wishes,
>
> Beijing University of Posts & Telecommunications (BUPT)
> Zhu Xiao  ( =D6=EC=E4=EC )
> E-mail: buptxiaozhu@gmail.com=
> mobile:+86 134-8881-9004
>




--
Best wishes,

Beijing University of Posts & Telecommunications (BUPT)
Zhu Xiao  ( =D6=EC=E4=EC )
E-mail: buptxiao= zhu@gmail.com
mobile:+86 134-8881-9004

--_000_1CA25301D2219F40B3AA37201F0EACD11343C0ABPACDCEXMB05cabl_-- From richard_woundy@cable.comcast.com Wed Mar 2 07:04:01 2011 Return-Path: X-Original-To: decade@core3.amsl.com Delivered-To: decade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 34E393A67B2 for ; Wed, 2 Mar 2011 07:04:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.153 X-Spam-Level: X-Spam-Status: No, score=-106.153 tagged_above=-999 required=5 tests=[AWL=2.309, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zVRvTjGQJRbl for ; Wed, 2 Mar 2011 07:03:57 -0800 (PST) Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by core3.amsl.com (Postfix) with ESMTP id 869FE3A67A1 for ; Wed, 2 Mar 2011 07:03:57 -0800 (PST) Received: from ([24.40.55.40]) by pacdcimo01.cable.comcast.com with ESMTP with TLS id 5503620.115192091; Wed, 02 Mar 2011 10:04:56 -0500 Received: from PACDCEXMB05.cable.comcast.com ([fe80::a5b0:e5c4:df1b:2367]) by pacdcexhub03.cable.comcast.com ([fe80::d1dd:b302:b617:3755%12]) with mapi id 14.01.0270.001; Wed, 2 Mar 2011 10:04:54 -0500 From: "Woundy, Richard" To: "decade@ietf.org" Thread-Topic: Call for IETF 80 agenda items Thread-Index: AcvY6zEAkDk1oQR2Rnyvgb7ac5p4Jw== Date: Wed, 2 Mar 2011 15:04:53 +0000 Message-ID: <1CA25301D2219F40B3AA37201F0EACD11343C0F8@PACDCEXMB05.cable.comcast.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [76.96.111.6] Content-Type: multipart/alternative; boundary="_000_1CA25301D2219F40B3AA37201F0EACD11343C0F8PACDCEXMB05cabl_" MIME-Version: 1.0 Subject: [decade] Call for IETF 80 agenda items X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.9 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, 02 Mar 2011 15:04:01 -0000 --_000_1CA25301D2219F40B3AA37201F0EACD11343C0F8PACDCEXMB05cabl_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable DECADE working group, To help the chairs plan the DECADE agenda for IETF 80 (Prague), please send= requests for a slot on the DECADE agenda by Monday March 14 to Haibin and = myself. Please provide a title, the presenter and the requested amount of t= ime, as well as a list of the issues that will be addressed during the allo= cated time. The area directors are expected the chairs to promote shorter and more focu= sed WG meetings. So below is some advice and guidelines for potential prese= nters. - The WG discussion needs to focus on WG drafts, and individual drafts rela= ted to DECADE work. (Do not present the same draft in multiple WGs, eg in D= ECADE and PPSP.) Note the following draft deadlines coming up: * 2011-03-07 (Monday): Internet Draft Cut-off for initial document (-00= ) submission by 17:00 PT (01:00 Tuesday, March 8 UTC), upload using IETF ID= Submission Tool. * 2011-03-14 (Monday): Internet Draft final submission cut-off by 17:00= PT (01:00 Tuesday, March 15 UTC), upload using IETF ID Submission Tool. - For existing WG efforts, please consider David Bryan's last presentation = as a model (http://www.ietf.org/proceedings/79/slides/decade-3.pdf). Focus = on the open issues, not as much on general description of the drafts. - For drafts that have completed WG last call (Problem Statement and Survey= ), we should focus exclusively on any open items from WGLC. - High priority agenda items should include what is needed to take Requirem= ents and Architecture to WGLC, as well as to discuss integration examples a= nd re-chartering work. In order to facilitate session participation by non-English speakers, pleas= e note the following policies: 1. If a presenter does not submit initial slides by end of day Friday (Marc= h 25) before the IETF meeting, the presentation slot will be removed from t= he agenda. 2. If a presenter does not provide final slides 24 hours before the WG sess= ion, we will use their initial slides. Currently our WG session is schedule= d to meet on Monday afternoon (March 28), so this deadline would be Sunday = afternoon March 27. Thanks in advance. -- Rich and Haibin --_000_1CA25301D2219F40B3AA37201F0EACD11343C0F8PACDCEXMB05cabl_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

DECADE working group,

 

To help the chairs plan the DECADE agenda for IETF 8= 0 (Prague), please send requests for a slot on the DECADE agenda by Monday = March 14 to Haibin and myself. Please provide a title, the presenter a= nd the requested amount of time, as well as a list of the issues that will be addressed during the allocated time.<= o:p>

 

The area directors are expected the chairs to promot= e shorter and more focused WG meetings. So below is some advice and guideli= nes for potential presenters.

 

- The WG discussion needs to focus on WG drafts, and= individual drafts related to DECADE work. (Do not present the same draft i= n multiple WGs, eg in DECADE and PPSP.) Note the following draft deadlines = coming up:

  • 2011-03-07 (Mo= nday): Internet Draft Cut-off for initial docu= ment (-00) submission by 17:00 PT (01:00 Tuesday, March 8 UTC), upload using IETF ID Submission Tool.
  • 2011-03-14 (Mo= nday): Internet Draft final submission cut-off= by 17:00 PT (01:00 Tuesday, March 15 UTC), upload using IETF ID Submission Tool.

 

- For existing WG efforts, please consider David Bry= an's last presentation as a model (http://www.ietf.org/proceedings/79/slides/decade= -3.pdf). Focus on the open issues, not as much on general description of the drafts.

 

- For drafts that have completed WG last call (Probl= em Statement and Survey), we should focus exclusively on any open items fro= m WGLC.

 

- High priority agenda items should include what is = needed to take Requirements and Architecture to WGLC, as well as to discuss= integration examples and re-chartering work.

 

In order to facilitate session participation by non-= English speakers, please note the following policies:

 

1. If a presenter does not submit initial slides by = end of day Friday (March 25) before the IETF meeting, the presentation slot= will be removed from the agenda.

 

2. If a presenter does not provide final slides 24 h= ours before the WG session, we will use their initial slides. Currently our= WG session is scheduled to meet on Monday afternoon (March 28), so this de= adline would be Sunday afternoon March 27.

 

Thanks in advance.

 

-- Rich and Haibin

--_000_1CA25301D2219F40B3AA37201F0EACD11343C0F8PACDCEXMB05cabl_-- From richard.alimi@gmail.com Wed Mar 2 17:12:37 2011 Return-Path: X-Original-To: decade@core3.amsl.com Delivered-To: decade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D2743A68E7 for ; Wed, 2 Mar 2011 17:12:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.489 X-Spam-Level: X-Spam-Status: No, score=-1.489 tagged_above=-999 required=5 tests=[AWL=-1.262, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HvPahxxzgAHU for ; Wed, 2 Mar 2011 17:12:35 -0800 (PST) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id EE4283A67EB for ; Wed, 2 Mar 2011 17:12:31 -0800 (PST) Received: by iwl42 with SMTP id 42so586057iwl.31 for ; Wed, 02 Mar 2011 17:13:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=agR7elhREjP+kSPU+ReCMAX4Ns8dxfhS99VmZcU6RD4=; b=naJTgvrDDIYytRBQNS81Y49ucv5LPuJKIJgi41X4irJgc6pbBraEBKNILoE8Eqk4FK Tdn3Y8eRmk5P6Ydo6I3ubuYMipnMoRrauAWyzklL/6jI8q0jzS/GwIPYhT0EMKu1CwDH wIiqsrawTG/1MFxU9pTUG/NfJU+hFdNW/aICg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=qSHIOJi6DHVdDwxS/fTcUtXCNXKCu+SY6/NGu/xrYAL2+AgMZTCgPKIzqiHtqa61Td OkvXjPLaD1FGxBUlhjHb+1cm7ZYHU+wKqDuZtfwJ30jF87DTCD8KRAIFPTGpg302Fm0B oQSJPRJIyidTzyGsVG/h3fXHtTqdI6J98OVdc= MIME-Version: 1.0 Received: by 10.231.39.67 with SMTP id f3mr462082ibe.42.1299114817822; Wed, 02 Mar 2011 17:13:37 -0800 (PST) Sender: richard.alimi@gmail.com Received: by 10.231.30.138 with HTTP; Wed, 2 Mar 2011 17:13:37 -0800 (PST) In-Reply-To: References: Date: Wed, 2 Mar 2011 17:13:37 -0800 X-Google-Sender-Auth: rVr01QDerk2IiRDBcJTkzOsxSeU Message-ID: From: Richard Alimi To: =?GB2312?B?1uzk7A==?= Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable Cc: decade@ietf.org Subject: Re: [decade] draft-zhu-decade-additional-requirements X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.9 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, 03 Mar 2011 01:12:37 -0000 Hi Xiao, Sorry for the delay. Finally coming back to this. 2011/1/16 =D6=EC=E4=EC : > hi, Richard: > thanks for your reply:D > additional discussion see inline:D > 2011/1/14 Richard Alimi >> >> HI Xiao, >> >> 2011/1/12 =D6=EC=E4=EC : >> > hi, Richard >> > see inline:D >> > >> > 2011/1/11 Richard Alimi >> >> >> >> Hi Xiao, >> >> >> >> On Mon, Jan 10, 2011 at 6:45 PM, =D6=EC=E4=EC = wrote: >> >> > >> >> > hi, Richard, sorry for so late response because of be busy with oth= er >> >> > projects. >> >> > some discussion see inline:D marked by red. >> >> > >> >> > On Tue, Jan 4, 2011 at 4:06 AM, Richard Alimi >> >> > wrote: >> >> >> >> >> >> Hi Xiao, >> >> >> >> >> >> Thank you for the draft. Some comments on the requirements: >> >> >> >> >> >> Request Redirects: >> >> >> >> >> >> This would provide some additional freedom for the storage provide= r. >> >> >> I think it is reasonable since it doesn't necessitate additional >> >> >> complexity for the DECADE server, but allows it if desired. Howeve= r, >> >> >> note that it may complicate some of the other components of the >> >> >> design. In particular, if there is a per-user quota for storage, i= s >> >> >> the user made aware of the quota at each in-network storage (if >> >> >> there >> >> >> is no shared storage between them)? Resource sharing policies may >> >> >> be >> >> >> impacted (e.g., if a bandwidth sharing weight of 1 may mean >> >> >> something >> >> >> different at DECADE server A than it does at DECADE server B). At >> >> >> this point it may be best to just note these so they are documente= d, >> >> >> but since the specification of the resource sharing policies are >> >> >> still >> >> >> being contemplated for the basic case of a single server it may be >> >> >> premature to even try and solve them for the case supporting >> >> >> redirection. >> >> >> >> >> > actually, you mean two points, right? >> >> > 1. whether or not to be ware of the content at each in-network >> >> > storage >> >> > and of course resource sharing policies can be impact in the reques= t >> >> > redirection. your suggestion"just to note these so they are >> >> > documented" will >> >> > be ok, or DECADE server list with some parameters will be return fo= r >> >> > user to >> >> > select the appropriate DECADE server, which can avoid the different >> >> > weighted >> >> > of the same parameter in server decision. but the parameter used in >> >> > select >> >> > the best DECADE server will be known for DECADE servers, in which >> >> > other >> >> > complexities will be added. anyway, all the solution are the >> >> > implementation >> >> > issue, which, i believe, does not impact the necessity of the >> >> > requirement. >> >> >> >> In general, I'd agree that the decision about where to redirect would >> >> be an implementation issue. >> >> >> >> > >> >> > 2. you mean "the resource sharing policies are still being consider= ed >> >> > in >> >> > a single server", so it may be premature to support redirection. t= he >> >> > architecture and protocol will be badly impacted if the requirement= s >> >> > change. >> >> > so the designing can be taken step by step, but the requirements >> >> > should be >> >> > overall considered. >> >> >> >> I said that it is probably premature to consider how resource sharing >> >> policies works across servers (or even if we need to say anything >> >> about it) since we have not determined how to specify them (or rather= , >> >> how little we need to specify in protocol) for a single server. I did >> >> not mean to imply that redirection could not be introduced as a >> >> requirement. >> >> >> > >> >> >> >> > >> >> > >> >> >> >> >> >> Multi-connection: >> >> >> >> >> >> I'm not quite clear on the intention of the requirement. My >> >> >> understanding is that you wish the client to be able to have >> >> >> multiple >> >> >> connections open spanning multiple DECADE servers. Is that correct= ? >> >> >> >> >> >> If so, do we need this stated as a requirement or the protocol? Or >> >> >> is >> >> >> this a policy that would be allowed/disallowed by the storage >> >> >> provider? >> >> >> >> >> > yep, your understanding is right, the scenarios were just described >> >> > in >> >> > draft as "soft handover in wireless environment and delete operatio= n >> >> > in >> >> > multi-servers". under these consideration, the authentication and >> >> > authorization need to be taken each time when setup connection with= a >> >> > new >> >> > DECADE server, or just be taken only once during the service? >> >> >> >> The DECADE server should need to do some sort of check on each new >> >> connection, regardless of whether the user has or previously had a >> >> connection open to a different DECADE server, right? Note that the >> >> requirements don't indicate how authentication or authorization is >> >> done, and allow a server to make optimizations if it is enforcing the >> >> same permissions. >> >> >> >> Can you indicate where the existing authorization-related requirement= s >> >> (in particular, 4.1.6.3 of draft-ietf-decade-reqs-00) do not suffice >> >> for the use case you are thinking of? >> >> > as considering the service continuity, the next serving DECADE server >> > should know the progress of the service, how does they know? >> >> By progress of the service, do you mean current user state (e.g., >> quota, recent resource usage history, permissions, etc)? > yes, and include data delivery proceeding. I still don't think I understand what you are suggesting as new requirements here. Why can't the client retry any failed requests? >> > so if the >> > service proceeding information should be known by the next serving >> > server, >> > or different servers need to coordinate and schedule each other to >> > fulfill >> > the user request, i believe the the 4.1.6.3 of the >> > draft-ietf-decade-req-00 >> > cannot satisfy the req. what do you think about? >> >> Note that the protocol that is covered here is the client-server >> protocol. Some of the same protocol may be useful between DECADE >> servers (especially in different administrative domains) for storing >> and retrieving data, but that does not mean that there can't be >> additional protocol(s) (not specified here) that are used between >> DECADE servers as well. For example, if DECADE servers within an >> administrative domain can certainly have their own mechanism to share >> such information. If such capabilities were included in the DECADE >> protocol (e.g., a need to do this between administrative domains), >> that sounds like lots more complexity that we need at this point. > but the access between in-network storage also is included in IAP > described in problem statement. i mean why not put this kind of function= in > DECADE since the IAP is defined just like that? The IAP in the problem statement is intended to describe data transfer between DECADE servers. I think the discussion above relates to storing state about the progress of delivering data to DECADE clients. Is that an accurate summary? If so, then the point of DECADE is that this is managed and controlled by the clients. I don't think it makes sense to add additional state in to DECADE servers for this. >> That said, it sounds to me like what is described in 4.1.6.3 would be >> sufficient (from the perspective of the client-server protocol, >> anyways) to implement what you're describing. If not, what >> specifically is missing and what use-case does it not meet? > so you mean the information you mentioned above, just like current user > state (e.g., > quota, recent resource usage history, permissions, etc) was already > included in DECADE requirement? what about the data delivery proceeding > information? can you specify the chapter for me ? thanks? Historical information is not specified, but I can't think of another storage protocol off the top of my head that provides this. Quota/resource usage is in Section 5.1.6. Permissions, if applicable, should be there too (we will update the doc to state this). For data delivery, I see value in getting status about other client that may have open connections or active transfers (reads or writes) to one's storage. This could probably be added as a requirement. However, if the expectation is for DECADE servers to somehow coordinate (e.g., picking a data path, resuming/retrying failed transfers, etc), then this is going towards delay-tolerant networking or CDNs. DECADE is not intended for that. >> >> > >> >> > >> >> >> >> >> >> Data Distribution: >> >> >> >> >> >> I'm also confused about the intent of this requirement. This >> >> >> statement has me somewhat worried: "The distribution is transparen= t >> >> >> to >> >> >> the users as they interact with the in-network storage as a single >> >> >> logical system." Does this mean that you are proposing for DECADE >> >> >> servers to assume the responsibility for deciding how data is to b= e >> >> >> distributed throughout the network, including the path of the data= , >> >> >> which servers act as intermediate caches, content expiration >> >> >> policies, >> >> >> etc? If this is true, I think it is missing one of the major poin= ts >> >> >> of DECADE. In particular, these decisions are application-dependen= t >> >> >> and are not implemented within DECADE. Instead, DECADE provides th= e >> >> >> basic capabilities and the functionality described above are >> >> >> implemented by the applications using DECADE. >> >> >> >> >> >> Or, am I misinterpreting the intent of the requirement? >> >> >> >> >> > you mean DECADE provides the basic capabilities, so can you give so= me >> >> > specify explanations on DECADE capabilities in supporting data >> >> > distribution? >> >> >> >> >> >> >> The problem statement gives a couple of scenarios. The "Integration >> >> Examples" presentation from IETF 79 also has more details of an >> >> on-going effort at Yale. >> >> > okay, thx for your information, i will lookup and refer, actually, the >> > content publisher described in problem statement remind me of the >> > protocol requirements which i did not find in draft-ietf-decade-reqs-0= 0 >> > to >> > support content publish. or i miss some points? >> >> Which requirements do you think are missing? >> >> >> >> Service Assurance: >> >> >> >> >> >> It seems problematic to include "assurance" in a DECADE. Shouldn'= t >> >> >> these instead be part of SLAs with a storage provider? Why should >> >> >> they be DECADE's responsibility? >> >> >> >> >> >> Regarding "resource reservation", are you referring to an actual >> >> >> reservation (which might be problematic -- see above) or do you me= an >> >> >> that the resource share should able to be specified at the time th= e >> >> >> connection opens and be assumed to be the same for the duration of >> >> >> the >> >> >> connection? >> >> >> >> >> >> Regarding Dynamic Feedback, is this orthogonal to the storage >> >> >> protocol? It seems like what you want here is a generic "status" >> >> >> service saying how loaded a server is? >> >> >> >> >> > thats right, actually, the flow control mechanism was under >> >> > discussion >> >> > in writing the draft at first. what about your opinion in this >> >> > requirements? >> >> > >> >> >> >> I'm not sure what the typical way of providing such "load status" >> >> information for IETF protocols, but my inclination is that it should >> >> not be in the DECADE protocol itself. Maybe someone else with a >> >> longer history in IETF could jump in here :) >> > so can i understand that "load status" is kind of necessity informati= on >> > for DECADE Server, but where and who collects the information are >> > remain discussion? >> >> The storage provider is free to collect the information wherever and >> however they wish. The DECADE server implementation could additional >> export whatever status information it wishes. I don't think the DECADE >> protocol needs to be concerned with that. >> >> Note that certain error conditions (e.g., overload, insufficient >> resources) may be signaled by a DECADE server (there are already have >> requirements for those). If you are referring to status for a user's >> resources, there is already a requirement for that too. >> >> I'm just not convinced that the DECADE protocol needs to export its >> current load status to clients. > actually i am not sure which elements in DECADE needs the load > status,(DECADE client or network storage if the network storage needs to > redirect the request or both?). > And the requirement draft currently seems describe the overload condition > as the event triggering. do you think if it is necessary to periodically > reporting of the DECADE network status to client for its network storage > selection? No I don't think this is necessary. The client can retry the request at a later time (e.g., exponential backoff). Note that asking a heavily-loaded DECADE server to also keep track of clients that need to be notified, and keep them updated of the current status, is probably counter-productive. > and the requirement draft just describe DECADE which is busy to serve > other requests must be able to reject requests, not consider how to handl= e > the user request after being rejected? That's the implementation's decision. I suspect most would drop it on the f= loor. >> >> >> >> >> >> Data classification: >> >> >> >> >> >> Would it be better to instead have the client specify properties o= f >> >> >> the content instead of place it into ? See >> >> >> www.ietf.org/proceedings/78/slides/nfsv4-0.pdf for an example of >> >> >> this >> >> >> approach for NFS. >> >> >> >> >> >> I think a problem with classifying applications is that it assumes >> >> >> that applications fit one of the supplied classifications. What if >> >> >> it >> >> >> may fit multiple classifications? or none? Another problem is it >> >> >> assumes that servers assume based on indirect and assumed >> >> >> information >> >> >> that they know what to do with a particular piece of content. Why >> >> >> not >> >> >> have an application specify its desires directly? >> >> >> >> >> > >> >> > >> >> >> >> >> >> Small Objects: >> >> >> >> >> >> What is the new requirement here? Why is the existing requirement >> >> >> in >> >> >> draft-ietf-decade-reqs-00 insufficient? >> >> >> >> >> >> This also has me a bit worried: >> >> >> "And the in-network storage has the limited storage capacity, with >> >> >> the >> >> >> arrival of user requests and data distribution requirements, the >> >> >> data >> >> >> stored in the in-network storage will be replaced if the storage >> >> >> reaches the limit and data arrivals continually." >> >> >> >> >> >> How does the server know what the proper replacement strategy is f= or >> >> >> an application? I think DECADE's philosophy is that applications >> >> >> should decide this. A simple way to do this is explicit deletion b= y >> >> >> an >> >> >> application, but perhaps a more efficient (yet more complex) >> >> >> solution >> >> >> is for an application to specify the replacement policy to the >> >> >> server. >> >> >> >> >> > actually, the key in "the data classification and small objects " i= s >> >> > whether does it or not in P2P application? i did not find data >> >> > classification was adopted in P2P application so far, let alone >> >> > DECADE need >> >> > to classify the data used in all kinds of application. >> >> > >> >> >> >> So, do you agree that it is problematic to try and classify each type >> >> of application and try to specify the typical workload for each class= ? >> >> >> >> My point was that I don't think its necessary to do the classificatio= n >> >> at all. It is more extensible (and directly useful) for a server to >> >> just give it direct hints about what would be preferable. >> > >> > yep, i believe it may be a little difficult, but worthy doing. special= ly >> > for improving the resource utilization within a single server and >> > reducing >> > the response time for client. what about others opinion? >> >> Can you justify why giving classifications (e.g., "I'm a live >> streaming application") would be better than giving specific hints >> (e.g., "please don't bother persistent these objects to disk")? > > i mean data in different kind of operation mode and attribute should have > different user patterns and storage rules, which may be help to improve t= he > resource utilization and reduce the response time for request, what are y= ou > understanding? That's fine. Explicit and more-specific hints are a different way to accomplish the same thing, and seem to be a much better design to me. They are simpler from an extensibility and implementation point of view. >> > >> >> >> >> Removal of Expired Records: >> >> >> >> >> >> "However, the two scenarios did not mention how to handle the old >> >> >> resource if the user distributes the new resource which is an >> >> >> updated >> >> >> copy of the old resource." >> >> >> >> >> >> Why does this need to be handled in the requirements? Are you >> >> >> trying >> >> >> to draw the distinction between immediate deletion of content and >> >> >> lazy >> >> >> deletion? >> >> >> >> >> > i mean the meaning of delete operation and how to handle the expire= d >> >> > records need to be clarify in requirements. >> >> >> >> My inclination is that "deleted" means that other requests the object >> >> of the same name should result an error, until another object with th= e >> >> same name is stored. >> > >> > okay, under the scenario "client uploads the new version, and did not >> > specify how to handle the old version", did DECADE server delete the >> > older >> > version (or just label it unavailable, anyway, it is implementation >> > issue ) >> > or not ? in another word, just replace the older version with the new >> > version with the same name? >> >> In this case, I would think the "write" of the new object should be >> rejected, or if desired, we could have an overwrite option. This >> could be added to the requirements if it helps to clarify. >> yep, no matter which solution is chosen, let the understanding >> unanimously:D >> > how to handle the older version which is >> > transferring from server to client? >> >> I think it would be cleaner to ask the server to continue sending an >> object once it has been started, but ultimately this would be the >> decision of the server's implementation I think. Maybe a "SHOULD" >> requirement. This could be added if desired. >> > Thank you for these questions. It helps design the requirements more > cleanly if there are specific scenarios in front of us :) > just discussion together:D and also thanks for your points to help me > understanding more! Thanks, Rich >> Rich >> >> >> I think that the time the data is removed from disk (or memory) shoul= d >> >> be up to the implementation. A storage provider might still have as >> >> part of some agreement that deleted data will be removed within X >> >> days/hours/minutes/whatever. >> > >> > agree with you. >> >> >> >> If people in the WG think it is necessary, we could have a requiremen= t >> >> that says the protocol should support an argument indicating immediat= e >> >> deletion, but it is not clear that we need this. >> >> >> >> Rich >> >> >> >> >> >> >> >> Thanks! >> >> >> Rich >> >> >> >> >> >> >> >> >> On Mon, Dec 27, 2010 at 12:57 AM, =D6=EC=E4=EC wrote: >> >> >> > Dear all, >> >> >> > >> >> >> > There is a slightly updated version of the decade additional >> >> >> > requirements >> >> >> > draft. >> >> >> > >> >> >> > >> >> >> > https://datatracker.ietf.org/doc/draft-zhu-decade-additional-req= uirements/ >> >> >> > >> >> >> > Jin Peng, Yunfei Zhang and me are expecting to have a discussion >> >> >> > with >> >> >> > all of >> >> >> > you. >> >> >> > >> >> >> > Any comments are appreciated! >> >> >> > >> >> >> > A new version of I-D, >> >> >> > draft-zhu-decade-additional-requirements-00.txt >> >> >> > has been successfully submitted by Xiao Zhu and posted to the IE= TF >> >> >> > repository. >> >> >> > >> >> >> > Filename: draft-zhu-decade-additional-requirements >> >> >> > Revision: 00 >> >> >> > Title: Additional protocol requirements on DECAD= E >> >> >> > Creation_date: 2010-12-27 >> >> >> > WG ID: Independent Submission >> >> >> > Number_of_pages: 10 >> >> >> > >> >> >> > Abstract: >> >> >> > The DECoupled Application Data Enroute(DECADE)working group is >> >> >> > specifying standardized interfaces for accessing in-network >> >> >> > storage >> >> >> > from applications to store, retrieve and manage data. The main >> >> >> > object >> >> >> > is to provide a framework that is useful to the applications, >> >> >> > including P2P applications and other data-oriented applications, >> >> >> > possibly related applications that can benefit from accessing in= - >> >> >> > network storage. This memo focuses on some requirements such as >> >> >> > request redirecting and so on which are on the central of >> >> >> > mobility, >> >> >> > wireless network environment and CDN application. We present the= se >> >> >> > in >> >> >> > this memo as additional requirements that should be considered f= or >> >> >> > the DECADE architecture and protocol specifications. >> >> >> > >> >> >> > >> >> >> > >> >> >> > The IETF Secretariat. >> >> >> > >> >> >> > -- >> >> >> > Best wishes, >> >> >> > >> >> >> > Beijing University of Posts & Telecommunications (BUPT) >> >> >> > Zhu Xiao ( =D6=EC=E4=EC ) >> >> >> > E-mail: buptxiaozhu@gmail.com >> >> >> > mobile:+86 134-8881-9004 >> >> >> > >> >> >> > _______________________________________________ >> >> >> > decade mailing list >> >> >> > decade@ietf.org >> >> >> > https://www.ietf.org/mailman/listinfo/decade >> >> >> > >> >> >> > >> >> > >> >> > >> >> > >> >> > -- >> >> > Best wishes, >> >> > >> >> > Beijing University of Posts & Telecommunications (BUPT) >> >> > Zhu Xiao ( =D6=EC=E4=EC ) >> >> > E-mail: buptxiaozhu@gmail.com >> >> > mobile:+86 134-8881-9004 >> > >> > >> > >> > -- >> > Best wishes, >> > >> > Beijing University of Posts & Telecommunications (BUPT) >> > Zhu Xiao ( =D6=EC=E4=EC ) >> > E-mail: buptxiaozhu@gmail.com >> > mobile:+86 134-8881-9004 >> > > > > > -- > Best wishes, > > Beijing University of Posts & Telecommunications (BUPT) > Zhu Xiao ( =D6=EC=E4=EC ) > E-mail: buptxiaozhu@gmail.com > mobile:+86 134-8881-9004 > From richard.alimi@gmail.com Wed Mar 2 17:14:44 2011 Return-Path: X-Original-To: decade@core3.amsl.com Delivered-To: decade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F95F3A6920 for ; Wed, 2 Mar 2011 17:14:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.008 X-Spam-Level: X-Spam-Status: No, score=-1.008 tagged_above=-999 required=5 tests=[AWL=-0.481, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S7ZbiIHwckf6 for ; Wed, 2 Mar 2011 17:14:42 -0800 (PST) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 085093A67EB for ; Wed, 2 Mar 2011 17:14:41 -0800 (PST) Received: by iwl42 with SMTP id 42so587367iwl.31 for ; Wed, 02 Mar 2011 17:15:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=ozJUY7Ph8i4TG4TgaKEUqbIQNZhxJ2JH1PkYf4VtpTg=; b=xh2rBt5g5IlfadRktlDZ9nkEwamefoq6UBdKFxQrYJhC1xP7alv9WjIDAEIS4C6yfg RFbxte0X9Fko0CaGNGRL4egwX28bEsvjOIMZ64mNOncg++P8DlqL9+u9flS2Ue6gtHOw EFWypO3c97OZeYfoJYeyKrG1+jx6GTECrmtD4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=ntF9cMzIbEfZGjXTyJceT05xzxNz5LITQV7oF6osj2WkkDg27BaDXhyrF29/Ekt+xE 080CF2KD2Yo85jT0xo0w6uLYF+U+jH7iFk8a8c+IYfRi3a0foMG8MK+tMFMXpU0iTGUe O8wTveite/iOI69P4zj+Fhu2Ux8My5SoG6R+A= MIME-Version: 1.0 Received: by 10.231.39.67 with SMTP id f3mr463235ibe.42.1299114948902; Wed, 02 Mar 2011 17:15:48 -0800 (PST) Sender: richard.alimi@gmail.com Received: by 10.231.30.138 with HTTP; Wed, 2 Mar 2011 17:15:48 -0800 (PST) In-Reply-To: <1CA25301D2219F40B3AA37201F0EACD11343C0AB@PACDCEXMB05.cable.comcast.com> References: <1CA25301D2219F40B3AA37201F0EACD11343C0AB@PACDCEXMB05.cable.comcast.com> Date: Wed, 2 Mar 2011 17:15:48 -0800 X-Google-Sender-Auth: fte78QKnYC7AddBXXWN02-bg6Lw Message-ID: From: Richard Alimi To: "Woundy, Richard" Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable Cc: "decade@ietf.org" Subject: Re: [decade] draft-zhu-decade-additional-requirements X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.9 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, 03 Mar 2011 01:14:44 -0000 Hi All, I'll offer a summary of this discussion. Let me know if I missed anything, or if there are objections/other thoughts on these proposed resolutions. Redirection: - We can add a requirement mentioning that DECADE may support redirection. Data Classification: - I (personally) strongly disagree with attempting to classify access patterns or applications. We could add something saying that explicit hints (a la www.ietf.org/proceedings/78/slides/nfsv4-0.pdf) could be provided in DECADE. However, I don't think we need to do something new here. In particular, if the underlying storage/data transport supports hints, a DECADE client or server can use it. Storage Status: - Update section 5.1.6 to indicate that status information should include permissions of stored objects, if applicable. - Update 5.1.6 to indicate that status information should include other information about resource usage (the clients own resources, or resources used by other clients that have been authorized to read/write objects or open connections to one's storage). Requirements for object deletion/overwriting: - DECADE MAY have an overwrite flag (note that this may or may not be necessary depending on our naming, but the requirements document probably is not the place to take a stand on this at the current point.) - If an object is deleted as it is concurrently being read, then the server MAY continue to read it (lazy deletion), or it MAY discontinue reading the object and signal an error to the client reading the object. Would this be sufficient to merge in the points from draft-zhu-decade-additional-requirements-00 and this ensuing discussion? Thanks, Rich 2011/3/2 Woundy, Richard : > Folks, > > > > Do we have consensus yet about how the WG could have a single DECADE > requirements document going forward? I can't tell the state of our > requirements consolidation from the email thread below. > > > > It would be preferable if we could resolve this fully on the WG mailing > list, but this is important enough to allocate some time at our meeting i= n > Prague. > > > > -- Rich > > > > From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.org] On Behalf = Of > ?? > Sent: Sunday, January 16, 2011 9:02 PM > To: Richard Alimi > Cc: decade@ietf.org > Subject: Re: [decade] draft-zhu-decade-additional-requirements > > > > hi, Richard: > > > > thanks for your reply:D > > additional discussion see inline:D > > > > 2011/1/14 Richard Alimi > > HI Xiao, > > 2011/1/12 =D6=EC=E4=EC : > >> hi, Richard >> see inline:D >> >> 2011/1/11 Richard Alimi >>> >>> Hi Xiao, >>> >>> On Mon, Jan 10, 2011 at 6:45 PM, =D6=EC=E4=EC w= rote: >>> > >>> > hi, Richard, sorry for so late response because of be busy with other >>> > projects. >>> > some discussion see inline:D marked by red. >>> > >>> > On Tue, Jan 4, 2011 at 4:06 AM, Richard Alimi >>> > wrote: >>> >> >>> >> Hi Xiao, >>> >> >>> >> Thank you for the draft. Some comments on the requirements: >>> >> >>> >> Request Redirects: >>> >> >>> >> This would provide some additional freedom for the storage provider. >>> >> I think it is reasonable since it doesn't necessitate additional >>> >> complexity for the DECADE server, but allows it if desired. However, >>> >> note that it may complicate some of the other components of the >>> >> design. In particular, if there is a per-user quota for storage, is >>> >> the user made aware of the quota at each in-network storage (if ther= e >>> >> is no shared storage between them)? Resource sharing policies may b= e >>> >> impacted (e.g., if a bandwidth sharing weight of 1 may mean somethin= g >>> >> different at DECADE server A than it does at DECADE server B). At >>> >> this point it may be best to just note these so they are documented, >>> >> but since the specification of the resource sharing policies are sti= ll >>> >> being contemplated for the basic case of a single server it may be >>> >> premature to even try and solve them for the case supporting >>> >> redirection. >>> >> >>> > actually, you mean two points, right? >>> > 1. whether or not to be ware of the content at each in-network storag= e >>> > and of course resource sharing policies can be impact in the request >>> > redirection. your suggestion"just to note these so they are documente= d" >>> > will >>> > be ok, or DECADE server list with some parameters will be return for >>> > user to >>> > select the appropriate DECADE server, which can avoid the different >>> > weighted >>> > of the same parameter in server decision. but the parameter used in >>> > select >>> > the best DECADE server will be known for DECADE servers, in which oth= er >>> > complexities will be added. anyway, all the solution are the >>> > implementation >>> > issue, which, i believe, does not impact the necessity of the >>> > requirement. >>> >>> In general, I'd agree that the decision about where to redirect would >>> be an implementation issue. >>> >>> > >>> > 2. you mean "the resource sharing policies are still being considered >>> > in >>> > a single server", so it may be premature to support redirection. the >>> > architecture and protocol will be badly impacted if the requirements >>> > change. >>> > so the designing can be taken step by step, but the requirements >>> > should be >>> > overall considered. >>> >>> I said that it is probably premature to consider how resource sharing >>> policies works across servers (or even if we need to say anything >>> about it) since we have not determined how to specify them (or rather, >>> how little we need to specify in protocol) for a single server. I did >>> not mean to imply that redirection could not be introduced as a >>> requirement. >>> >> >>> >>> > >>> > >>> >> >>> >> Multi-connection: >>> >> >>> >> I'm not quite clear on the intention of the requirement. My >>> >> understanding is that you wish the client to be able to have multipl= e >>> >> connections open spanning multiple DECADE servers. Is that correct? >>> >> >>> >> If so, do we need this stated as a requirement or the protocol? Or i= s >>> >> this a policy that would be allowed/disallowed by the storage >>> >> provider? >>> >> >>> > yep, your understanding is right, the scenarios were just described i= n >>> > draft as "soft handover in wireless environment and delete operation = in >>> > multi-servers". under these consideration, the authentication and >>> > authorization need to be taken each time when setup connection with a >>> > new >>> > DECADE server, or just be taken only once during the service? >>> >>> The DECADE server should need to do some sort of check on each new >>> connection, regardless of whether the user has or previously had a >>> connection open to a different DECADE server, right? Note that the >>> requirements don't indicate how authentication or authorization is >>> done, and allow a server to make optimizations if it is enforcing the >>> same permissions. >>> >>> Can you indicate where the existing authorization-related requirements >>> (in particular, 4.1.6.3 of draft-ietf-decade-reqs-00) do not suffice >>> for the use case you are thinking of? > >> as considering the service continuity, the next serving DECADE server >> should know the progress of the service, how does they know? > > By progress of the service, do you mean current user state (e.g., > quota, recent resource usage history, permissions, etc)? > > yes, and include data delivery proceeding. >> so if the >> service proceeding information should be known by the next serving serve= r, >> or different servers need to coordinate and schedule each other to fulfi= ll >> the user request, i believe the the 4.1.6.3 of the >> draft-ietf-decade-req-00 >> cannot satisfy the req. what do you think about? > > Note that the protocol that is covered here is the client-server > protocol. Some of the same protocol may be useful between DECADE > servers (especially in different administrative domains) for storing > and retrieving data, but that does not mean that there can't be > additional protocol(s) (not specified here) that are used between > DECADE servers as well. For example, if DECADE servers within an > administrative domain can certainly have their own mechanism to share > such information. If such capabilities were included in the DECADE > protocol (e.g., a need to do this between administrative domains), > that sounds like lots more complexity that we need at this point. > but the access between in-network storage also is included in IAP describ= ed > in problem statement. i mean why not put this kind of function in DECADE > since the IAP is defined just like that? > That said, it sounds to me like what is described in 4.1.6.3 would be > sufficient (from the perspective of the client-server protocol, > anyways) to implement what you're describing. If not, what > specifically is missing and what use-case does it not meet? > > so you mean the information you mentioned above, just like current user > state (e.g., > quota, recent resource usage history, permissions, etc) was already inclu= ded > in DECADE requirement? what about the data delivery proceeding informatio= n? > can you specify the chapter for me ? thanks? >>> > >>> > >>> >> >>> >> Data Distribution: >>> >> >>> >> I'm also confused about the intent of this requirement. This >>> >> statement has me somewhat worried: "The distribution is transparent = to >>> >> the users as they interact with the in-network storage as a single >>> >> logical system." Does this mean that you are proposing for DECADE >>> >> servers to assume the responsibility for deciding how data is to be >>> >> distributed throughout the network, including the path of the data, >>> >> which servers act as intermediate caches, content expiration policie= s, >>> >> etc? If this is true, I think it is missing one of the major points >>> >> of DECADE. In particular, these decisions are application-dependent >>> >> and are not implemented within DECADE. Instead, DECADE provides the >>> >> basic capabilities and the functionality described above are >>> >> implemented by the applications using DECADE. >>> >> >>> >> Or, am I misinterpreting the intent of the requirement? >>> >> >>> > you mean DECADE provides the basic capabilities, so can you give some >>> > specify explanations on DECADE capabilities in supporting data >>> > distribution? >>> >> >>> >>> The problem statement gives a couple of scenarios. The "Integration >>> Examples" presentation from IETF 79 also has more details of an >>> on-going effort at Yale. > >> okay, thx for your information, i will lookup and refer, actually, the >> content publisher described in problem statement remind me of the >> protocol requirements which i did not find in draft-ietf-decade-reqs-00 = to >> support content publish. or i miss some points? > > Which requirements do you think are missing? > >>> >> Service Assurance: >>> >> >>> >> It seems problematic to include "assurance" in a DECADE. Shouldn't >>> >> these instead be part of SLAs with a storage provider? Why should >>> >> they be DECADE's responsibility? >>> >> >>> >> Regarding "resource reservation", are you referring to an actual >>> >> reservation (which might be problematic -- see above) or do you mean >>> >> that the resource share should able to be specified at the time the >>> >> connection opens and be assumed to be the same for the duration of t= he >>> >> connection? >>> >> >>> >> Regarding Dynamic Feedback, is this orthogonal to the storage >>> >> protocol? It seems like what you want here is a generic "status" >>> >> service saying how loaded a server is? >>> >> >>> > thats right, actually, the flow control mechanism was under discussio= n >>> > in writing the draft at first. what about your opinion in this >>> > requirements? >>> > >>> >>> I'm not sure what the typical way of providing such "load status" >>> information for IETF protocols, but my inclination is that it should >>> not be in the DECADE protocol itself. Maybe someone else with a >>> longer history in IETF could jump in here :) >> so can i understand that "load status" is kind of necessity information >> for DECADE Server, but where and who collects the information are >> remain discussion? > > The storage provider is free to collect the information wherever and > however they wish. The DECADE server implementation could additional > export whatever status information it wishes. I don't think the DECADE > protocol needs to be concerned with that. > > Note that certain error conditions (e.g., overload, insufficient > resources) may be signaled by a DECADE server (there are already have > requirements for those). If you are referring to status for a user's > resources, there is already a requirement for that too. > > I'm just not convinced that the DECADE protocol needs to export its > current load status to clients. > > actually i am not sure which elements in DECADE needs the load > status,(DECADE client or network storage if the network storage needs to > redirect the request or both?). > > > > And the requirement draft currently seems describe the overload condition= as > the event triggering. do you think if it is necessary to periodically > reporting of the DECADE network status to client for its network storage > selection? > > > > and the requirement draft just describe DECADE which is busy to serve oth= er > requests must be able to reject requests, not consider how to handle the > user request after being rejected? > >>> >> >>> >> Data classification: >>> >> >>> >> Would it be better to instead have the client specify properties of >>> >> the content instead of place it into ? See >>> >> www.ietf.org/proceedings/78/slides/nfsv4-0.pdf for an example of thi= s >>> >> approach for NFS. >>> >> >>> >> I think a problem with classifying applications is that it assumes >>> >> that applications fit one of the supplied classifications. What if i= t >>> >> may fit multiple classifications? or none? Another problem is it >>> >> assumes that servers assume based on indirect and assumed informatio= n >>> >> that they know what to do with a particular piece of content. Why no= t >>> >> have an application specify its desires directly? >>> >> >>> > >>> > >>> >> >>> >> Small Objects: >>> >> >>> >> What is the new requirement here? Why is the existing requirement i= n >>> >> draft-ietf-decade-reqs-00 insufficient? >>> >> >>> >> This also has me a bit worried: >>> >> "And the in-network storage has the limited storage capacity, with t= he >>> >> arrival of user requests and data distribution requirements, the dat= a >>> >> stored in the in-network storage will be replaced if the storage >>> >> reaches the limit and data arrivals continually." >>> >> >>> >> How does the server know what the proper replacement strategy is for >>> >> an application? I think DECADE's philosophy is that applications >>> >> should decide this. A simple way to do this is explicit deletion by = an >>> >> application, but perhaps a more efficient (yet more complex) solutio= n >>> >> is for an application to specify the replacement policy to the serve= r. >>> >> >>> > actually, the key in "the data classification and small objects " is >>> > whether does it or not in P2P application? i did not find data >>> > classification was adopted in P2P application so far, let alone DECAD= E >>> > need >>> > to classify the data used in all kinds of application. >>> > >>> >>> So, do you agree that it is problematic to try and classify each type >>> of application and try to specify the typical workload for each class? >>> >>> My point was that I don't think its necessary to do the classification >>> at all. It is more extensible (and directly useful) for a server to >>> just give it direct hints about what would be preferable. >> >> yep, i believe it may be a little difficult, but worthy doing. specially >> for improving the resource utilization within a single server and reduci= ng >> the response time for client. what about others opinion? > > Can you justify why giving classifications (e.g., "I'm a live > streaming application") would be better than giving specific hints > (e.g., "please don't bother persistent these objects to disk")? > > i mean data in different kind of operation mode and attribute should have > different user patterns and storage rules, which may be help to improve t= he > resource utilization and reduce the response time for request, what are y= ou > understanding? >> >> >>> >> Removal of Expired Records: >>> >> >>> >> "However, the two scenarios did not mention how to handle the old >>> >> resource if the user distributes the new resource which is an update= d >>> >> copy of the old resource." >>> >> >>> >> Why does this need to be handled in the requirements? Are you tryin= g >>> >> to draw the distinction between immediate deletion of content and la= zy >>> >> deletion? >>> >> >>> > i mean the meaning of delete operation and how to handle the expired >>> > records need to be clarify in requirements. >>> >>> My inclination is that "deleted" means that other requests the object >>> of the same name should result an error, until another object with the >>> same name is stored. >> >> okay, under the scenario "client uploads the new version, and did not >> specify how to handle the old version", did DECADE server delete the old= er >> version (or just label it unavailable, anyway, it is implementation issu= e >> ) >> or not ? in another word, just replace the older version with the new >> version with the same name? > > In this case, I would think the "write" of the new object should be > rejected, or if desired, we could have an overwrite option. This > could be added to the requirements if it helps to clarify. > > yep, no matter which solution is chosen, let the understanding unanimousl= y:D >> how to handle the older version which is >> transferring from server to client? > > I think it would be cleaner to ask the server to continue sending an > object once it has been started, but ultimately this would be the > decision of the server's implementation I think. Maybe a "SHOULD" > requirement. This could be added if desired. > > Thank you for these questions. It helps design the requirements more > cleanly if there are specific scenarios in front of us :) > just discussion together:D and also thanks for your points to help me > understanding more! > Rich > >>> I think that the time the data is removed from disk (or memory) should >>> be up to the implementation. A storage provider might still have as >>> part of some agreement that deleted data will be removed within X >>> days/hours/minutes/whatever. >> >> agree with you. >>> >>> If people in the WG think it is necessary, we could have a requirement >>> that says the protocol should support an argument indicating immediate >>> deletion, but it is not clear that we need this. >>> >>> Rich >>> >>> >> >>> >> Thanks! >>> >> Rich >>> >> >>> >> >>> >> On Mon, Dec 27, 2010 at 12:57 AM, =D6=EC=E4=EC wrote: >>> >> > Dear all, >>> >> > >>> >> > There is a slightly updated version of the decade additional >>> >> > requirements >>> >> > draft. >>> >> > >>> >> > >>> >> > https://datatracker.ietf.org/doc/draft-zhu-decade-additional-requi= rements/ >>> >> > >>> >> > Jin Peng, Yunfei Zhang and me are expecting to have a discussion >>> >> > with >>> >> > all of >>> >> > you. >>> >> > >>> >> > Any comments are appreciated! >>> >> > >>> >> > A new version of I-D, >>> >> > draft-zhu-decade-additional-requirements-00.txt >>> >> > has been successfully submitted by Xiao Zhu and posted to the IETF >>> >> > repository. >>> >> > >>> >> > Filename: draft-zhu-decade-additional-requirements >>> >> > Revision: 00 >>> >> > Title: Additional protocol requirements on DECADE >>> >> > Creation_date: 2010-12-27 >>> >> > WG ID: Independent Submission >>> >> > Number_of_pages: 10 >>> >> > >>> >> > Abstract: >>> >> > The DECoupled Application Data Enroute(DECADE)working group is >>> >> > specifying standardized interfaces for accessing in-network storag= e >>> >> > from applications to store, retrieve and manage data. The main >>> >> > object >>> >> > is to provide a framework that is useful to the applications, >>> >> > including P2P applications and other data-oriented applications, >>> >> > possibly related applications that can benefit from accessing in- >>> >> > network storage. This memo focuses on some requirements such as >>> >> > request redirecting and so on which are on the central of mobility= , >>> >> > wireless network environment and CDN application. We present these >>> >> > in >>> >> > this memo as additional requirements that should be considered for >>> >> > the DECADE architecture and protocol specifications. >>> >> > >>> >> > >>> >> > >>> >> > The IETF Secretariat. >>> >> > >>> >> > -- >>> >> > Best wishes, >>> >> > >>> >> > Beijing University of Posts & Telecommunications (BUPT) >>> >> > Zhu Xiao ( =D6=EC=E4=EC ) >>> >> > E-mail: buptxiaozhu@gmail.com >>> >> > mobile:+86 134-8881-9004 >>> >> > >>> >> > _______________________________________________ >>> >> > decade mailing list >>> >> > decade@ietf.org >>> >> > https://www.ietf.org/mailman/listinfo/decade >>> >> > >>> >> > >>> > >>> > >>> > >>> > -- >>> > Best wishes, >>> > >>> > Beijing University of Posts & Telecommunications (BUPT) >>> > Zhu Xiao ( =D6=EC=E4=EC ) >>> > E-mail: buptxiaozhu@gmail.com >>> > mobile:+86 134-8881-9004 >> >> >> >> -- >> Best wishes, >> >> Beijing University of Posts & Telecommunications (BUPT) >> Zhu Xiao ( =D6=EC=E4=EC ) >> E-mail: buptxiaozhu@gmail.com >> mobile:+86 134-8881-9004 >> > > > -- > Best wishes, > > Beijing University of Posts & Telecommunications (BUPT) > Zhu Xiao ( =D6=EC=E4=EC ) > E-mail: buptxiaozhu@gmail.com > mobile:+86 134-8881-9004 From Internet-Drafts@ietf.org Fri Mar 4 19:00:02 2011 Return-Path: X-Original-To: decade@core3.amsl.com Delivered-To: decade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B86C13A69FC; Fri, 4 Mar 2011 19:00:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.522 X-Spam-Level: X-Spam-Status: No, score=-102.522 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zoVpbg1x88Cg; Fri, 4 Mar 2011 19:00:01 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A9B893A68EA; Fri, 4 Mar 2011 19:00:01 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110305030001.23988.97626.idtracker@localhost> Date: Fri, 04 Mar 2011 19:00:01 -0800 Cc: decade@ietf.org Subject: [decade] I-D Action:draft-ietf-decade-survey-04.txt X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.9 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, 05 Mar 2011 03:00:02 -0000 --NextPart 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 : A Survey of In-network Storage Systems Author(s) : R. Alimi, et al. Filename : draft-ietf-decade-survey-04.txt Pages : 41 Date : 2011-03-04 This document surveys deployed and experimental in-network storage systems and describes their applicability for DECADE. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-decade-survey-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-decade-survey-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-03-04185654.I-D@ietf.org> --NextPart-- From Akbar.Rahman@InterDigital.com Fri Mar 4 19:02:29 2011 Return-Path: X-Original-To: decade@core3.amsl.com Delivered-To: decade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 219D33A69E7 for ; Fri, 4 Mar 2011 19:02:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qqzn9tnwJ73c for ; Fri, 4 Mar 2011 19:02:28 -0800 (PST) Received: from idcout.InterDigital.com (idcexmail.interdigital.com [12.32.197.135]) by core3.amsl.com (Postfix) with ESMTP id 2BA703A68EA for ; Fri, 4 Mar 2011 19:02:28 -0800 (PST) Received: from SAM.InterDigital.com ([10.30.2.12]) by idcout.InterDigital.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 4 Mar 2011 22:03:37 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Fri, 4 Mar 2011 22:03:22 -0500 Message-ID: In-Reply-To: <20110305030001.23988.97626.idtracker@localhost> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [decade] I-D Action:draft-ietf-decade-survey-04.txt Thread-Index: Acva4Ztx04jPsqQATnG7N/ltiyRQnAAAA6Hg References: <20110305030001.23988.97626.idtracker@localhost> From: "Rahman, Akbar" To: X-OriginalArrivalTime: 05 Mar 2011 03:03:37.0687 (UTC) FILETIME=[EC489E70:01CBDAE1] Subject: Re: [decade] I-D Action:draft-ietf-decade-survey-04.txt X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.9 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, 05 Mar 2011 03:02:29 -0000 FYI - Updated survey. -----Original Message----- From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: Friday, March 04, 2011 10:00 PM To: i-d-announce@ietf.org Cc: decade@ietf.org Subject: [decade] I-D Action:draft-ietf-decade-survey-04.txt 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 : A Survey of In-network Storage Systems Author(s) : R. Alimi, et al. Filename : draft-ietf-decade-survey-04.txt Pages : 41 Date : 2011-03-04 This document surveys deployed and experimental in-network storage systems and describes their applicability for DECADE. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-decade-survey-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. From richard_woundy@cable.comcast.com Sat Mar 5 10:09:01 2011 Return-Path: X-Original-To: decade@core3.amsl.com Delivered-To: decade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D11993A6A3D for ; Sat, 5 Mar 2011 10:09:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.693 X-Spam-Level: X-Spam-Status: No, score=-102.693 tagged_above=-999 required=5 tests=[AWL=-0.958, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ksOECIaFc-F7 for ; Sat, 5 Mar 2011 10:09:00 -0800 (PST) Received: from cable.comcast.com (copdcimo01.potomac.co.ndcwest.comcast.net [76.96.32.251]) by core3.amsl.com (Postfix) with ESMTP id B58A33A69A1 for ; Sat, 5 Mar 2011 10:09:00 -0800 (PST) Received: from ([24.40.55.42]) by copdcimo01.cable.comcast.com with ESMTP with TLS id 5503630.28395634; Sat, 05 Mar 2011 11:22:10 -0700 Received: from PACDCEXMB05.cable.comcast.com ([fe80::a5b0:e5c4:df1b:2367]) by PACDCEXHUB01.cable.comcast.com ([fe80::d1e7:20b5:9b63:21a6%12]) with mapi id 14.01.0270.001; Sat, 5 Mar 2011 13:10:07 -0500 From: "Woundy, Richard" To: "Rahman, Akbar" , "decade@ietf.org" Thread-Topic: [decade] I-D Action:draft-ietf-decade-survey-04.txt Thread-Index: AQHL2uGZgxRdx+njwkybT1XiDfvb7JQeYdQAgACnKCA= Date: Sat, 5 Mar 2011 18:10:07 +0000 Message-ID: <1CA25301D2219F40B3AA37201F0EACD11345AD38@PACDCEXMB05.cable.comcast.com> References: <20110305030001.23988.97626.idtracker@localhost> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [76.96.111.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [decade] I-D Action:draft-ietf-decade-survey-04.txt X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.9 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, 05 Mar 2011 18:09:01 -0000 Thanks Akbar. Also, thanks to the draft authors, and to the folks that revi= ewed and provided comments on this draft. This survey draft version reflects the comments from WGLC, and was carefull= y reviewed by both the co-chairs. The next step for the draft is to submit it to the IESG. See RFC 4858 for a= description of the process, http://www.rfc-editor.org/rfc/rfc4858.txt. Eit= her Haibin or I will be the document shepherd for the Survey draft. -- Rich -----Original Message----- From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.org] On Behalf Of= Rahman, Akbar Sent: Friday, March 04, 2011 10:03 PM To: decade@ietf.org Subject: Re: [decade] I-D Action:draft-ietf-decade-survey-04.txt FYI - Updated survey. -----Original Message----- From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: Friday, March 04, 2011 10:00 PM To: i-d-announce@ietf.org Cc: decade@ietf.org Subject: [decade] I-D Action:draft-ietf-decade-survey-04.txt 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 : A Survey of In-network Storage Systems Author(s) : R. Alimi, et al. Filename : draft-ietf-decade-survey-04.txt Pages : 41 Date : 2011-03-04 This document surveys deployed and experimental in-network storage systems and describes their applicability for DECADE. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-decade-survey-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ decade mailing list decade@ietf.org https://www.ietf.org/mailman/listinfo/decade From buptxiaozhu@gmail.com Sun Mar 6 18:10:44 2011 Return-Path: X-Original-To: decade@core3.amsl.com Delivered-To: decade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5EDCC3A68BD for ; Sun, 6 Mar 2011 18:10:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.372 X-Spam-Level: **** X-Spam-Status: No, score=4.372 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, J_CHICKENPOX_42=0.6, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1, SARE_GIF_ATTACH=1.42] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NmpPcjos5yPo for ; Sun, 6 Mar 2011 18:10:40 -0800 (PST) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by core3.amsl.com (Postfix) with ESMTP id B58343A68BA for ; Sun, 6 Mar 2011 18:10:39 -0800 (PST) Received: by eye13 with SMTP id 13so1501587eye.31 for ; Sun, 06 Mar 2011 18:11:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references :x-goomoji-body:date:message-id:subject:from:to:cc:content-type; bh=my0FdOg1RECKCUzOz5dPhK0HtWf7nbgiGTfQQjDE0O0=; b=I1uLWpuep8izCiJ2uXK1h7gFcfQWjxMlXQfyZzR06CCeeQH0aoWP6YTa6ExM10QDp1 C+Sh38uG8ZH/C4zpOvI+rSmsmXvQXsEQIbhXVBzJVAmLc4UQoYUVuY1eZhun6qjv8O0B S1jPwMRHpUxVhuj4K1N14xhCHxnPieK/tgoN4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:x-goomoji-body:date:message-id :subject:from:to:cc:content-type; b=hw7UbvcFUUXBYDaAZ05Hdwtvb8VknrAiO75y4N77CPRM29vm5qF7EocGV4sRgilp2e BaGrWBOq6jNP7s03Fu6Tr4TsWiHURs9YsJeqU2eDiPfbeHFw/PVhRZehnpGRGFfMkfts NGBrsJi58KAQ9mzJwHbV+mIK3pNMf46Orl74o= MIME-Version: 1.0 Received: by 10.14.22.70 with SMTP id s46mr2106616ees.11.1299463910804; Sun, 06 Mar 2011 18:11:50 -0800 (PST) Received: by 10.14.29.71 with HTTP; Sun, 6 Mar 2011 18:11:50 -0800 (PST) In-Reply-To: References: X-Goomoji-Body: true Date: Mon, 7 Mar 2011 10:11:50 +0800 Message-ID: From: =?GB2312?B?1uzk7A==?= To: Richard Alimi Content-Type: multipart/related; boundary=90e6ba5bb927cd53b7049ddb0461 Cc: decade@ietf.org Subject: Re: [decade] draft-zhu-decade-additional-requirements X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.9 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, 07 Mar 2011 02:10:44 -0000 --90e6ba5bb927cd53b7049ddb0461 Content-Type: multipart/alternative; boundary=90e6ba5bb927cd53b2049ddb0460 --90e6ba5bb927cd53b2049ddb0460 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable Hi, Richard: sorry for reply so late, because i should remember what we are dissuasion and the key of the problem[?] so many quoted texts, let me make a summarize. 1 multi connection, i have the arguments as followings: @me: - need it to process new authentication and authorization after the user moves in the wireless environment and access a new DECADE server @you: - DECADE server should need to do some sort of check on each new connection, regardless of whether the user has or previously had a connection open to a different DECADE server, --> okay, agree with you, but we should specify in the requirements draft. @me: - considering the service continuity, the next serving DECADE server should know the progress of the service, how does they know?or differen= t servers need to coordinate and schedule each other to fulfill the user request? @you: - that does not mean that there can't be additional protocol(s) (not specified here) that are used between DECADE servers as well. and The IA= P in the problem statement is intended to describe data transfer between DECADE servers. -> basically agree with you, a question reminds me that "IAP means in the media layer=A3=BF and signalling or controlling layer protocol may be neede= d to solve the problem? and we can reuse the other protocol to fulfill the storing status transfer. and we should consider to update the draft to add the permission requirement and retrieve the client status about getting and writing storage. 2 Service Assurance -> basically agree with you, keep tracking the status of the DCADE server may also bring the additional burden to the overloaded DECADE server. 2011/3/3 Richard Alimi > Hi Xiao, > > Sorry for the delay. Finally coming back to this. > > 2011/1/16 =D6=EC=E4=EC : > > hi, Richard: > > thanks for your reply:D > > additional discussion see inline:D > > 2011/1/14 Richard Alimi > >> > >> HI Xiao, > >> > >> 2011/1/12 =D6=EC=E4=EC : > >> > hi, Richard > >> > see inline:D > >> > > >> > 2011/1/11 Richard Alimi > >> >> > >> >> Hi Xiao, > >> >> > >> >> On Mon, Jan 10, 2011 at 6:45 PM, =D6=EC=E4=EC wrote: > >> >> > > >> >> > hi, Richard, sorry for so late response because of be busy with > other > >> >> > projects. > >> >> > some discussion see inline:D marked by red. > >> >> > > >> >> > On Tue, Jan 4, 2011 at 4:06 AM, Richard Alimi > >> >> > wrote: > >> >> >> > >> >> >> Hi Xiao, > >> >> >> > >> >> >> Thank you for the draft. Some comments on the requirements: > >> >> >> > >> >> >> Request Redirects: > >> >> >> > >> >> >> This would provide some additional freedom for the storage > provider. > >> >> >> I think it is reasonable since it doesn't necessitate additional > >> >> >> complexity for the DECADE server, but allows it if desired. > However, > >> >> >> note that it may complicate some of the other components of the > >> >> >> design. In particular, if there is a per-user quota for storage, > is > >> >> >> the user made aware of the quota at each in-network storage (if > >> >> >> there > >> >> >> is no shared storage between them)? Resource sharing policies m= ay > >> >> >> be > >> >> >> impacted (e.g., if a bandwidth sharing weight of 1 may mean > >> >> >> something > >> >> >> different at DECADE server A than it does at DECADE server B). = At > >> >> >> this point it may be best to just note these so they are > documented, > >> >> >> but since the specification of the resource sharing policies are > >> >> >> still > >> >> >> being contemplated for the basic case of a single server it may = be > >> >> >> premature to even try and solve them for the case supporting > >> >> >> redirection. > >> >> >> > >> >> > actually, you mean two points, right? > >> >> > 1. whether or not to be ware of the content at each in-network > >> >> > storage > >> >> > and of course resource sharing policies can be impact in the > request > >> >> > redirection. your suggestion"just to note these so they are > >> >> > documented" will > >> >> > be ok, or DECADE server list with some parameters will be return > for > >> >> > user to > >> >> > select the appropriate DECADE server, which can avoid the differe= nt > >> >> > weighted > >> >> > of the same parameter in server decision. but the parameter used = in > >> >> > select > >> >> > the best DECADE server will be known for DECADE servers, in which > >> >> > other > >> >> > complexities will be added. anyway, all the solution are the > >> >> > implementation > >> >> > issue, which, i believe, does not impact the necessity of the > >> >> > requirement. > >> >> > >> >> In general, I'd agree that the decision about where to redirect wou= ld > >> >> be an implementation issue. > >> >> > >> >> > > >> >> > 2. you mean "the resource sharing policies are still being > considered > >> >> > in > >> >> > a single server", so it may be premature to support redirection. > the > >> >> > architecture and protocol will be badly impacted if the > requirements > >> >> > change. > >> >> > so the designing can be taken step by step, but the requirement= s > >> >> > should be > >> >> > overall considered. > >> >> > >> >> I said that it is probably premature to consider how resource shari= ng > >> >> policies works across servers (or even if we need to say anything > >> >> about it) since we have not determined how to specify them (or > rather, > >> >> how little we need to specify in protocol) for a single server. I d= id > >> >> not mean to imply that redirection could not be introduced as a > >> >> requirement. > >> >> > >> > > >> >> > >> >> > > >> >> > > >> >> >> > >> >> >> Multi-connection: > >> >> >> > >> >> >> I'm not quite clear on the intention of the requirement. My > >> >> >> understanding is that you wish the client to be able to have > >> >> >> multiple > >> >> >> connections open spanning multiple DECADE servers. Is that > correct? > >> >> >> > >> >> >> If so, do we need this stated as a requirement or the protocol? = Or > >> >> >> is > >> >> >> this a policy that would be allowed/disallowed by the storage > >> >> >> provider? > >> >> >> > >> >> > yep, your understanding is right, the scenarios were just describ= ed > >> >> > in > >> >> > draft as "soft handover in wireless environment and delete > operation > >> >> > in > >> >> > multi-servers". under these consideration, the authentication and > >> >> > authorization need to be taken each time when setup connection wi= th > a > >> >> > new > >> >> > DECADE server, or just be taken only once during the service? > >> >> > >> >> The DECADE server should need to do some sort of check on each new > >> >> connection, regardless of whether the user has or previously had a > >> >> connection open to a different DECADE server, right? Note that the > >> >> requirements don't indicate how authentication or authorization is > >> >> done, and allow a server to make optimizations if it is enforcing t= he > >> >> same permissions. > >> >> > >> >> Can you indicate where the existing authorization-related > requirements > >> >> (in particular, 4.1.6.3 of draft-ietf-decade-reqs-00) do not suffic= e > >> >> for the use case you are thinking of? > >> > >> > as considering the service continuity, the next serving DECADE serv= er > >> > should know the progress of the service, how does they know? > >> > >> By progress of the service, do you mean current user state (e.g., > >> quota, recent resource usage history, permissions, etc)? > > > yes, and include data delivery proceeding. > > I still don't think I understand what you are suggesting as new > requirements here. Why can't the client retry any failed requests? > > >> > so if the > >> > service proceeding information should be known by the next serving > >> > server, > >> > or different servers need to coordinate and schedule each other to > >> > fulfill > >> > the user request, i believe the the 4.1.6.3 of the > >> > draft-ietf-decade-req-00 > >> > cannot satisfy the req. what do you think about? > >> > >> Note that the protocol that is covered here is the client-server > >> protocol. Some of the same protocol may be useful between DECADE > >> servers (especially in different administrative domains) for storing > >> and retrieving data, but that does not mean that there can't be > >> additional protocol(s) (not specified here) that are used between > >> DECADE servers as well. For example, if DECADE servers within an > >> administrative domain can certainly have their own mechanism to share > >> such information. If such capabilities were included in the DECADE > >> protocol (e.g., a need to do this between administrative domains), > >> that sounds like lots more complexity that we need at this point. > > > but the access between in-network storage also is included in IAP > > described in problem statement. i mean why not put this kind of functi= on > in > > DECADE since the IAP is defined just like that? > > The IAP in the problem statement is intended to describe data transfer > between DECADE servers. I think the discussion above relates to > storing state about the progress of delivering data to DECADE clients. > Is that an accurate summary? If so, then the point of DECADE is that > this is managed and controlled by the clients. I don't think it makes > sense to add additional state in to DECADE servers for this. > > >> That said, it sounds to me like what is described in 4.1.6.3 would be > >> sufficient (from the perspective of the client-server protocol, > >> anyways) to implement what you're describing. If not, what > >> specifically is missing and what use-case does it not meet? > > > so you mean the information you mentioned above, just like current user > > state (e.g., > > quota, recent resource usage history, permissions, etc) was already > > included in DECADE requirement? what about the data delivery proceeding > > information? can you specify the chapter for me ? thanks? > > Historical information is not specified, but I can't think of another > storage protocol off the top of my head that provides this. > > Quota/resource usage is in Section 5.1.6. Permissions, if applicable, > should be there too (we will update the doc to state this). > > For data delivery, I see value in getting status about other client > that may have open connections or active transfers (reads or writes) > to one's storage. This could probably be added as a requirement. > > However, if the expectation is for DECADE servers to somehow > coordinate (e.g., picking a data path, resuming/retrying failed > transfers, etc), then this is going towards delay-tolerant networking > or CDNs. DECADE is not intended for that. > > >> >> > > >> >> > > >> >> >> > >> >> >> Data Distribution: > >> >> >> > >> >> >> I'm also confused about the intent of this requirement. This > >> >> >> statement has me somewhat worried: "The distribution is > transparent > >> >> >> to > >> >> >> the users as they interact with the in-network storage as a sing= le > >> >> >> logical system." Does this mean that you are proposing for DECAD= E > >> >> >> servers to assume the responsibility for deciding how data is to > be > >> >> >> distributed throughout the network, including the path of the > data, > >> >> >> which servers act as intermediate caches, content expiration > >> >> >> policies, > >> >> >> etc? If this is true, I think it is missing one of the major > points > >> >> >> of DECADE. In particular, these decisions are > application-dependent > >> >> >> and are not implemented within DECADE. Instead, DECADE provides > the > >> >> >> basic capabilities and the functionality described above are > >> >> >> implemented by the applications using DECADE. > >> >> >> > >> >> >> Or, am I misinterpreting the intent of the requirement? > >> >> >> > >> >> > you mean DECADE provides the basic capabilities, so can you give > some > >> >> > specify explanations on DECADE capabilities in supporting data > >> >> > distribution? > >> >> >> > >> >> > >> >> The problem statement gives a couple of scenarios. The "Integration > >> >> Examples" presentation from IETF 79 also has more details of an > >> >> on-going effort at Yale. > >> > >> > okay, thx for your information, i will lookup and refer, actually, t= he > >> > content publisher described in problem statement remind me of the > >> > protocol requirements which i did not find in > draft-ietf-decade-reqs-00 > >> > to > >> > support content publish. or i miss some points? > >> > >> Which requirements do you think are missing? > >> > >> >> >> Service Assurance: > >> >> >> > >> >> >> It seems problematic to include "assurance" in a DECADE. > Shouldn't > >> >> >> these instead be part of SLAs with a storage provider? Why shou= ld > >> >> >> they be DECADE's responsibility? > >> >> >> > >> >> >> Regarding "resource reservation", are you referring to an actual > >> >> >> reservation (which might be problematic -- see above) or do you > mean > >> >> >> that the resource share should able to be specified at the time > the > >> >> >> connection opens and be assumed to be the same for the duration = of > >> >> >> the > >> >> >> connection? > >> >> >> > >> >> >> Regarding Dynamic Feedback, is this orthogonal to the storage > >> >> >> protocol? It seems like what you want here is a generic "status= " > >> >> >> service saying how loaded a server is? > >> >> >> > >> >> > thats right, actually, the flow control mechanism was under > >> >> > discussion > >> >> > in writing the draft at first. what about your opinion in this > >> >> > requirements? > >> >> > > >> >> > >> >> I'm not sure what the typical way of providing such "load status" > >> >> information for IETF protocols, but my inclination is that it shoul= d > >> >> not be in the DECADE protocol itself. Maybe someone else with a > >> >> longer history in IETF could jump in here :) > >> > so can i understand that "load status" is kind of necessity > information > >> > for DECADE Server, but where and who collects the information are > >> > remain discussion? > >> > >> The storage provider is free to collect the information wherever and > >> however they wish. The DECADE server implementation could additional > >> export whatever status information it wishes. I don't think the DECADE > >> protocol needs to be concerned with that. > >> > >> Note that certain error conditions (e.g., overload, insufficient > >> resources) may be signaled by a DECADE server (there are already have > >> requirements for those). If you are referring to status for a user's > >> resources, there is already a requirement for that too. > >> > >> I'm just not convinced that the DECADE protocol needs to export its > >> current load status to clients. > > > actually i am not sure which elements in DECADE needs the load > > status,(DECADE client or network storage if the network storage needs t= o > > redirect the request or both?). > > And the requirement draft currently seems describe the overload conditi= on > > as the event triggering. do you think if it is necessary to periodical= ly > > reporting of the DECADE network status to client for its network storag= e > > selection? > > No I don't think this is necessary. The client can retry the request > at a later time (e.g., exponential backoff). Note that asking a > heavily-loaded DECADE server to also keep track of clients that need > to be notified, and keep them updated of the current status, is > probably counter-productive. > > > and the requirement draft just describe DECADE which is busy to serve > > other requests must be able to reject requests, not consider how to > handle > > the user request after being rejected? > > That's the implementation's decision. I suspect most would drop it on the > floor. > > >> >> >> > >> >> >> Data classification: > >> >> >> > >> >> >> Would it be better to instead have the client specify properties > of > >> >> >> the content instead of place it into ? See > >> >> >> www.ietf.org/proceedings/78/slides/nfsv4-0.pdf for an example of > >> >> >> this > >> >> >> approach for NFS. > >> >> >> > >> >> >> I think a problem with classifying applications is that it assum= es > >> >> >> that applications fit one of the supplied classifications. What = if > >> >> >> it > >> >> >> may fit multiple classifications? or none? Another problem is i= t > >> >> >> assumes that servers assume based on indirect and assumed > >> >> >> information > >> >> >> that they know what to do with a particular piece of content. Wh= y > >> >> >> not > >> >> >> have an application specify its desires directly? > >> >> >> > >> >> > > >> >> > > >> >> >> > >> >> >> Small Objects: > >> >> >> > >> >> >> What is the new requirement here? Why is the existing requireme= nt > >> >> >> in > >> >> >> draft-ietf-decade-reqs-00 insufficient? > >> >> >> > >> >> >> This also has me a bit worried: > >> >> >> "And the in-network storage has the limited storage capacity, wi= th > >> >> >> the > >> >> >> arrival of user requests and data distribution requirements, the > >> >> >> data > >> >> >> stored in the in-network storage will be replaced if the storage > >> >> >> reaches the limit and data arrivals continually." > >> >> >> > >> >> >> How does the server know what the proper replacement strategy is > for > >> >> >> an application? I think DECADE's philosophy is that applications > >> >> >> should decide this. A simple way to do this is explicit deletion > by > >> >> >> an > >> >> >> application, but perhaps a more efficient (yet more complex) > >> >> >> solution > >> >> >> is for an application to specify the replacement policy to the > >> >> >> server. > >> >> >> > >> >> > actually, the key in "the data classification and small objects " > is > >> >> > whether does it or not in P2P application? i did not find data > >> >> > classification was adopted in P2P application so far, let alone > >> >> > DECADE need > >> >> > to classify the data used in all kinds of application. > >> >> > > >> >> > >> >> So, do you agree that it is problematic to try and classify each ty= pe > >> >> of application and try to specify the typical workload for each > class? > >> >> > >> >> My point was that I don't think its necessary to do the > classification > >> >> at all. It is more extensible (and directly useful) for a server t= o > >> >> just give it direct hints about what would be preferable. > >> > > >> > yep, i believe it may be a little difficult, but worthy doing. > specially > >> > for improving the resource utilization within a single server and > >> > reducing > >> > the response time for client. what about others opinion? > >> > >> Can you justify why giving classifications (e.g., "I'm a live > >> streaming application") would be better than giving specific hints > >> (e.g., "please don't bother persistent these objects to disk")? > > > > i mean data in different kind of operation mode and attribute should ha= ve > > different user patterns and storage rules, which may be help to improve > the > > resource utilization and reduce the response time for request, what are > you > > understanding? > > That's fine. Explicit and more-specific hints are a different way to > accomplish the same thing, and seem to be a much better design to me. > They are simpler from an extensibility and implementation point of > view. > > >> > >> > >> >> >> Removal of Expired Records: > >> >> >> > >> >> >> "However, the two scenarios did not mention how to handle the ol= d > >> >> >> resource if the user distributes the new resource which is an > >> >> >> updated > >> >> >> copy of the old resource." > >> >> >> > >> >> >> Why does this need to be handled in the requirements? Are you > >> >> >> trying > >> >> >> to draw the distinction between immediate deletion of content an= d > >> >> >> lazy > >> >> >> deletion? > >> >> >> > >> >> > i mean the meaning of delete operation and how to handle the > expired > >> >> > records need to be clarify in requirements. > >> >> > >> >> My inclination is that "deleted" means that other requests the obje= ct > >> >> of the same name should result an error, until another object with > the > >> >> same name is stored. > >> > > >> > okay, under the scenario "client uploads the new version, and did no= t > >> > specify how to handle the old version", did DECADE server delete the > >> > older > >> > version (or just label it unavailable, anyway, it is implementation > >> > issue ) > >> > or not ? in another word, just replace the older version with the ne= w > >> > version with the same name? > >> > >> In this case, I would think the "write" of the new object should be > >> rejected, or if desired, we could have an overwrite option. This > >> could be added to the requirements if it helps to clarify. > >> yep, no matter which solution is chosen, let the understanding > >> unanimously:D > >> > how to handle the older version which is > >> > transferring from server to client? > >> > >> I think it would be cleaner to ask the server to continue sending an > >> object once it has been started, but ultimately this would be the > >> decision of the server's implementation I think. Maybe a "SHOULD" > >> requirement. This could be added if desired. > >> > > Thank you for these questions. It helps design the requirements more > > cleanly if there are specific scenarios in front of us :) > > just discussion together:D and also thanks for your points to help me > > understanding more! > > Thanks, > Rich > > >> Rich > >> > >> >> I think that the time the data is removed from disk (or memory) > should > >> >> be up to the implementation. A storage provider might still have as > >> >> part of some agreement that deleted data will be removed within X > >> >> days/hours/minutes/whatever. > >> > > >> > agree with you. > >> >> > >> >> If people in the WG think it is necessary, we could have a > requirement > >> >> that says the protocol should support an argument indicating > immediate > >> >> deletion, but it is not clear that we need this. > >> >> > >> >> Rich > >> >> > >> >> >> > >> >> >> Thanks! > >> >> >> Rich > >> >> >> > >> >> >> > >> >> >> On Mon, Dec 27, 2010 at 12:57 AM, =D6=EC=E4=EC > wrote: > >> >> >> > Dear all, > >> >> >> > > >> >> >> > There is a slightly updated version of the decade additional > >> >> >> > requirements > >> >> >> > draft. > >> >> >> > > >> >> >> > > >> >> >> > > https://datatracker.ietf.org/doc/draft-zhu-decade-additional-requirements= / > >> >> >> > > >> >> >> > Jin Peng, Yunfei Zhang and me are expecting to have a discussi= on > >> >> >> > with > >> >> >> > all of > >> >> >> > you. > >> >> >> > > >> >> >> > Any comments are appreciated! > >> >> >> > > >> >> >> > A new version of I-D, > >> >> >> > draft-zhu-decade-additional-requirements-00.txt > >> >> >> > has been successfully submitted by Xiao Zhu and posted to the > IETF > >> >> >> > repository. > >> >> >> > > >> >> >> > Filename: draft-zhu-decade-additional-requirements > >> >> >> > Revision: 00 > >> >> >> > Title: Additional protocol requirements on > DECADE > >> >> >> > Creation_date: 2010-12-27 > >> >> >> > WG ID: Independent Submission > >> >> >> > Number_of_pages: 10 > >> >> >> > > >> >> >> > Abstract: > >> >> >> > The DECoupled Application Data Enroute(DECADE)working group is > >> >> >> > specifying standardized interfaces for accessing in-network > >> >> >> > storage > >> >> >> > from applications to store, retrieve and manage data. The main > >> >> >> > object > >> >> >> > is to provide a framework that is useful to the applications, > >> >> >> > including P2P applications and other data-oriented application= s, > >> >> >> > possibly related applications that can benefit from accessing > in- > >> >> >> > network storage. This memo focuses on some requirements such a= s > >> >> >> > request redirecting and so on which are on the central of > >> >> >> > mobility, > >> >> >> > wireless network environment and CDN application. We present > these > >> >> >> > in > >> >> >> > this memo as additional requirements that should be considered > for > >> >> >> > the DECADE architecture and protocol specifications. > >> >> >> > > >> >> >> > > >> >> >> > > >> >> >> > The IETF Secretariat. > >> >> >> > > >> >> >> > -- > >> >> >> > Best wishes, > >> >> >> > > >> >> >> > Beijing University of Posts & Telecommunications (BUPT) > >> >> >> > Zhu Xiao ( =D6=EC=E4=EC ) > >> >> >> > E-mail: buptxiaozhu@gmail.com > >> >> >> > mobile:+86 134-8881-9004 > >> >> >> > > >> >> >> > _______________________________________________ > >> >> >> > decade mailing list > >> >> >> > decade@ietf.org > >> >> >> > https://www.ietf.org/mailman/listinfo/decade > >> >> >> > > >> >> >> > > >> >> > > >> >> > > >> >> > > >> >> > -- > >> >> > Best wishes, > >> >> > > >> >> > Beijing University of Posts & Telecommunications (BUPT) > >> >> > Zhu Xiao ( =D6=EC=E4=EC ) > >> >> > E-mail: buptxiaozhu@gmail.com > >> >> > mobile:+86 134-8881-9004 > >> > > >> > > >> > > >> > -- > >> > Best wishes, > >> > > >> > Beijing University of Posts & Telecommunications (BUPT) > >> > Zhu Xiao ( =D6=EC=E4=EC ) > >> > E-mail: buptxiaozhu@gmail.com > >> > mobile:+86 134-8881-9004 > >> > > > > > > > > > -- > > Best wishes, > > > > Beijing University of Posts & Telecommunications (BUPT) > > Zhu Xiao ( =D6=EC=E4=EC ) > > E-mail: buptxiaozhu@gmail.com > > mobile:+86 134-8881-9004 > > > --=20 Best wishes, Beijing University of Posts & Telecommunications (BUPT) Zhu Xiao ( =D6=EC=E4=EC ) E-mail: buptxiaozhu@gmail.com mobile:+86 134-8881-9004 --90e6ba5bb927cd53b2049ddb0460 Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable
Hi, Richard:

sorry for reply so late, because= i should remember what we are dissuasion and the key of the prob= lem


so many quoted texts, let me make a = ;summarize.

1 multi connection, i have the argumen= ts as followings:

@me:

  • need it to process new authentication and authorization after the = user moves in the wireless environment and access a new DECADE se= rver
    • @you:
    • DECADE server should n= eed to do some sort of check on each new
       connection, regardless of whether the user has or previously had a connection open to a different DECADE server,
    =
    --> okay, agree with you, but we should specify in the require= ments draft.

    @me:
    • considering the service continuity, the= next serving  DECADE server
      =  should know the progress of the service, how does they know?or differ= ent servers need to coordinate and schedule each other to fulfill = ;the user request?
    @you:

    • that does not mean that there can't be <= /span>a= dditional protocol(s) (not specified here) that are used between DECAD= E servers as well. and The IAP in the problem statement is intended to describe data transf= er between DECADE servers.
    -> basically agree with you,  a question reminds me= that "IAP means in the media layer=A3=BF and signalling or controllin= g layer protocol may be needed to solve the problem? and we can reuse the o= ther protocol to fulfill the storing status transfer. and we should conside= r to update the draft to add the permission requirement and retrieve&n= bsp;the client status about getting and writing storage. 

    2 Service Assurance

    -> basically agree with you, keep tracking the status = of the DCADE server may also bring the additional burden to the o= verloaded DECADE server.

    2011/3/3 Richard Alimi <rich@velvetsea.net>
    Hi Xiao,

    Sorry for the delay. Finally coming back to this.

    2011/1/16 =D6=EC=E4=EC <buptxia= ozhu@gmail.com>:
    > hi, Richard:
    > thanks for your reply:D
    > additional discussion see inline:D
    > 2011/1/14 Richard Alimi <rich= @velvetsea.net>
    >>
    >> HI Xiao,
    >>
    >> 2011/1/12 =D6=EC=E4=EC <buptxiaozhu@gmail.com>:
    >> > hi, Richard
    >> > see inline:D
    >> >
    >> > 2011/1/11 Richard Alimi <rich@velvetsea.net>
    >> >>
    >> >> Hi Xiao,
    >> >>
    >> >> On Mon, Jan 10, 2011 at 6:45 PM, =D6=EC=E4=EC <buptxiaozhu@gmail.com> wrote:
    >> >> >
    >> >> > hi, Richard, sorry for so late response because of b= e busy with other
    >> >> > projects.
    >> >> > some discussion see inline:D marked by red.
    >> >> >
    >> >> > On Tue, Jan 4, 2011 at 4:06 AM, Richard Alimi <rich@velvetsea.net>
    >> >> > wrote:
    >> >> >>
    >> >> >> Hi Xiao,
    >> >> >>
    >> >> >> Thank you for the draft.  Some comments on = the requirements:
    >> >> >>
    >> >> >> Request Redirects:
    >> >> >>
    >> >> >> This would provide some additional freedom for t= he storage provider.
    >> >> >> I think it is reasonable since it doesn't ne= cessitate additional
    >> >> >> complexity for the DECADE server, but allows it = if desired. However,
    >> >> >> note that it may complicate some of the other co= mponents of the
    >> >> >> design. In particular, if there is a per-user qu= ota for storage, is
    >> >> >> the user made aware of the quota at each in-netw= ork storage (if
    >> >> >> there
    >> >> >> is no shared storage between them)?  Resour= ce sharing policies may
    >> >> >> be
    >> >> >> impacted (e.g., if a bandwidth sharing weight of= 1 may mean
    >> >> >> something
    >> >> >> different at DECADE server A than it does at DEC= ADE server B).  At
    >> >> >> this point it may be best to just note these so = they are documented,
    >> >> >> but since the specification of the resource shar= ing policies are
    >> >> >> still
    >> >> >> being contemplated for the basic case of a singl= e server it may be
    >> >> >> premature to even try and solve them for the cas= e supporting
    >> >> >> redirection.
    >> >> >>
    >> >> > actually, you mean two points, right?
    >> >> > 1. whether or not to be ware of the content at each = in-network
    >> >> > storage
    >> >> > and of course resource sharing policies can be impac= t in the request
    >> >> > redirection. your suggestion"just to note these= so they are
    >> >> > documented" will
    >> >> > be ok, or DECADE server list with some parameters wi= ll be return for
    >> >> > user to
    >> >> > select the appropriate DECADE server, which can avoi= d the different
    >> >> > weighted
    >> >> > of the same parameter in server decision. but the pa= rameter used in
    >> >> > select
    >> >> > the best DECADE server will be known for DECADE serv= ers, in which
    >> >> > other
    >> >> > complexities will be added. anyway, all the solution= are the
    >> >> > implementation
    >> >> > issue, which, i believe, does not impact the necessi= ty of the
    >> >> > requirement.
    >> >>
    >> >> In general, I'd agree that the decision about where t= o redirect would
    >> >> be an implementation issue.
    >> >>
    >> >> >
    >> >> > 2. you mean "the resource sharing policies are = still being considered
    >> >> > in
    >> >> > a single server", so it may be premature to sup= port redirection.  the
    >> >> > architecture and protocol will be badly impacted if = the requirements
    >> >> > change.
    >> >> > so the designing can be  taken  step by st= ep, but the requirements
    >> >> > should be
    >> >> > overall considered.
    >> >>
    >> >> I said that it is probably premature to consider how reso= urce sharing
    >> >> policies works across servers (or even if we need to say = anything
    >> >> about it) since we have not determined how to specify the= m (or rather,
    >> >> how little we need to specify in protocol) for a single s= erver. I did
    >> >> not mean to imply that redirection could not be introduce= d as a
    >> >> requirement.
    >> >>
    >> >
    >> >>
    >> >> >
    >> >> >
    >> >> >>
    >> >> >> Multi-connection:
    >> >> >>
    >> >> >> I'm not quite clear on the intention of the = requirement.  My
    >> >> >> understanding is that you wish the client to be = able to have
    >> >> >> multiple
    >> >> >> connections open spanning multiple DECADE server= s. Is that correct?
    >> >> >>
    >> >> >> If so, do we need this stated as a requirement o= r the protocol? Or
    >> >> >> is
    >> >> >> this a policy that would be allowed/disallowed b= y the storage
    >> >> >> provider?
    >> >> >>
    >> >> > yep, your understanding is right, the scenarios were= just described
    >> >> > in
    >> >> > draft as "soft handover in wireless environment= and delete operation
    >> >> > in
    >> >> > multi-servers". under these consideration, the = authentication and
    >> >> > authorization need to be taken each time when setup = connection with a
    >> >> > new
    >> >> > DECADE server, or just be taken only once during &nb= sp;the service?
    >> >>
    >> >> The DECADE server should need to do some sort of check on= each new
    >> >> connection, regardless of whether the user has or previou= sly had a
    >> >> connection open to a different DECADE server, right? &nbs= p;Note that the
    >> >> requirements don't indicate how authentication or aut= horization is
    >> >> done, and allow a server to make optimizations if it is e= nforcing the
    >> >> same permissions.
    >> >>
    >> >> Can you indicate where the existing authorization-related= requirements
    >> >> (in particular, 4.1.6.3 of draft-ietf-decade-reqs-00) do = not suffice
    >> >> for the use case you are thinking of?
    >>
    >> > as considering the service continuity, the next serving  = ;DECADE server
    >> > should know the progress of the service, how does they know?<= br> >>
    >> By progress of the service, do you mean current user state (e.g.,<= br> >> quota, recent resource usage history, permissions, etc)?

    > yes, and include data delivery proceeding.

    I still don't think I understand what you are suggesting as= new
    requirements here.  Why can't the client retry any failed requests= ?

    >> > so if the
    >> > service proceeding information should be known by the next se= rving
    >> > server,
    >> > or different servers need to coordinate and schedule each oth= er to
    >> > fulfill
    >> > the user request, i believe the the 4.1.6.3 of the
    >> > draft-ietf-decade-req-00
    >> > cannot satisfy the req. what do you think about?
    >>
    >> Note that the protocol that is covered here is the client-server >> protocol. Some of the same protocol may be useful between DECADE >> servers (especially in different administrative domains) for stori= ng
    >> and retrieving data, but that does not mean that there can't b= e
    >> additional protocol(s) (not specified here) that are used between<= br> >> DECADE servers as well.  For example, if DECADE servers withi= n an
    >> administrative domain can certainly have their own mechanism to sh= are
    >> such information.  If such capabilities were included in the = DECADE
    >> protocol (e.g., a need to do this between administrative domains),=
    >> that sounds like lots more complexity that we need at this point.<= br>
    > but the access between in-network storage also is included in IAP
    > described in problem statement.  i mean why not put this kind of = function in
    > DECADE since the IAP is defined just like that?

    The IAP in the problem statement is intended to describe data transfe= r
    between DECADE servers.  I think the discussion above relates to
    storing state about the progress of delivering data to DECADE clients.
    Is that an accurate summary?  If so, then the point of DECADE is that<= br> this is managed and controlled by the clients.  I don't think it m= akes
    sense to add additional state in to DECADE servers for this.

    >> That said, it sounds to me like what is described in 4.1.6.3 would= be
    >> sufficient (from the perspective of the client-server protocol, >> anyways) to implement what you're describing. If not, what
    >> specifically is missing and what use-case does it not meet?

    > so you mean the information you mentioned above, just like current use= r
    > state (e.g.,
    > quota, recent resource usage history, permissions, etc) was already > included in DECADE requirement? what about the data delivery proceedin= g
    > information? can you specify the chapter for me ? thanks?

    Historical information is not specified, but I can't think of ano= ther
    storage protocol off the top of my head that provides this.

    Quota/resource usage is in Section 5.1.6. Permissions, if applicable,
    should be there too (we will update the doc to state this).

    For data delivery, I see value in getting status about other client
    that may have open connections or active transfers (reads or writes)
    to one's storage. This could probably be added as a requirement.

    However, if the expectation is for DECADE servers to somehow
    coordinate (e.g., picking a data path, resuming/retrying failed
    transfers, etc), then this is going towards delay-tolerant networking
    or CDNs. DECADE is not intended for that.

    >> >> >
    >> >> >
    >> >> >>
    >> >> >> Data Distribution:
    >> >> >>
    >> >> >> I'm also confused about the intent of this r= equirement.  This
    >> >> >> statement has me somewhat worried: "The dis= tribution is transparent
    >> >> >> to
    >> >> >> the users as they interact with the in-network s= torage as a single
    >> >> >> logical system." Does this mean that you ar= e proposing for DECADE
    >> >> >> servers to assume the responsibility for decidin= g how data is to be
    >> >> >> distributed throughout the network, including th= e path of the data,
    >> >> >> which servers act as intermediate caches, conten= t expiration
    >> >> >> policies,
    >> >> >> etc?  If this is true, I think it is missin= g one of the major points
    >> >> >> of DECADE. In particular, these decisions are ap= plication-dependent
    >> >> >> and are not implemented within DECADE. Instead, = DECADE provides the
    >> >> >> basic capabilities and the functionality describ= ed above are
    >> >> >> implemented by the applications using DECADE. >> >> >>
    >> >> >> Or, am I misinterpreting the intent of the requi= rement?
    >> >> >>
    >> >> > you mean DECADE provides the basic capabilities, so = can you give some
    >> >> > specify explanations on DECADE capabilities in suppo= rting data
    >> >> > distribution?
    >> >> >>
    >> >>
    >> >> The problem statement gives a couple of scenarios. The &q= uot;Integration
    >> >> Examples" presentation from IETF 79 also has more de= tails of an
    >> >> on-going effort at Yale.
    >>
    >> > okay, thx for your information, i will lookup and refer, actu= ally, the
    >> > content publisher described in problem statement remind me of=  the
    >> > protocol requirements which i did not find in draft-ietf-deca= de-reqs-00
    >> > to
    >> > support content publish. or i miss some points?
    >>
    >> Which requirements do you think are missing?
    >>
    >> >> >> Service Assurance:
    >> >> >>
    >> >> >> It seems problematic to include "assurance&= quot; in a DECADE.  Shouldn't
    >> >> >> these instead be part of SLAs with a storage pro= vider?  Why should
    >> >> >> they be DECADE's responsibility?
    >> >> >>
    >> >> >> Regarding "resource reservation", are = you referring to an actual
    >> >> >> reservation (which might be problematic -- see a= bove) or do you mean
    >> >> >> that the resource share should able to be specif= ied at the time the
    >> >> >> connection opens and be assumed to be the same f= or the duration of
    >> >> >> the
    >> >> >> connection?
    >> >> >>
    >> >> >> Regarding Dynamic Feedback, is this orthogonal t= o the storage
    >> >> >> protocol?  It seems like what you want here= is a generic "status"
    >> >> >> service saying how loaded a server is?
    >> >> >>
    >> >> > thats right, actually, the flow control mechanism wa= s under
    >> >> > discussion
    >> >> > in writing the draft at first. what about your opini= on in this
    >> >> > requirements?
    >> >> >
    >> >>
    >> >> I'm not sure what the typical way of providing such &= quot;load status"
    >> >> information for IETF protocols, but my inclination is tha= t it should
    >> >> not be in the DECADE protocol itself.  Maybe someone= else with a
    >> >> longer history in IETF could jump in here :)
    >> > so can i understand that "load status" is kind of n= ecessity  information
    >> > for DECADE Server, but where and who collects the information= are
    >> > remain discussion?
    >>
    >> The storage provider is free to collect the information wherever a= nd
    >> however they wish.  The DECADE server implementation could ad= ditional
    >> export whatever status information it wishes. I don't think th= e DECADE
    >> protocol needs to be concerned with that.
    >>
    >> Note that certain error conditions (e.g., overload, insufficient >> resources) may be signaled by a DECADE server (there are already h= ave
    >> requirements for those).  If you are referring to status for = a user's
    >> resources, there is already a requirement for that too.
    >>
    >> I'm just not convinced that the DECADE protocol needs to expor= t its
    >> current load status to clients.

    > actually i am not sure which elements in DECADE needs the load
    > status,(DECADE client or network storage if the network storage needs = to
    > redirect the request or both?).
    > And the requirement draft currently seems describe the overload condit= ion
    > as the event triggering.  do you think if it is necessary to peri= odically
    > reporting of the DECADE network status to client for its network stora= ge
    > selection?

    No I don't think this is necessary.  The client can re= try the request
    at a later time (e.g., exponential backoff).  Note that asking a
    heavily-loaded DECADE server to also keep track of clients that need
    to be notified, and keep them updated of the current status, is
    probably counter-productive.

    > and the requirement draft just describe DECADE which is busy to serve<= br> > other requests must be able to reject requests, not consider how to ha= ndle
    > the user request after being rejected?

    That's the implementation's decision. I suspect most would dr= op it on the floor.

    >> >> >>
    >> >> >> Data classification:
    >> >> >>
    >> >> >> Would it be better to instead have the client sp= ecify properties of
    >> >> >> the content instead of place it into ? See
    >> >> >> www.ietf.org/proceedings/78/slides/nfsv= 4-0.pdf for an example of
    >> >> >> this
    >> >> >> approach for NFS.
    >> >> >>
    >> >> >> I think a problem with classifying applications = is that it assumes
    >> >> >> that applications fit one of the supplied classi= fications. What if
    >> >> >> it
    >> >> >> may fit multiple classifications? or none?  = ;Another problem is it
    >> >> >> assumes that servers assume based on indirect an= d assumed
    >> >> >> information
    >> >> >> that they know what to do with a particular piec= e of content. Why
    >> >> >> not
    >> >> >> have an application specify its desires directly= ?
    >> >> >>
    >> >> >
    >> >> >
    >> >> >>
    >> >> >> Small Objects:
    >> >> >>
    >> >> >> What is the new requirement here?  Why is t= he existing requirement
    >> >> >> in
    >> >> >> draft-ietf-decade-reqs-00 insufficient?
    >> >> >>
    >> >> >> This also has me a bit worried:
    >> >> >> "And the in-network storage has the limited= storage capacity, with
    >> >> >> the
    >> >> >> arrival of user requests and data distribution r= equirements, the
    >> >> >> data
    >> >> >> stored in the in-network storage will be replace= d if the storage
    >> >> >> reaches the limit and data arrivals continually.= "
    >> >> >>
    >> >> >> How does the server know what the proper replace= ment strategy is for
    >> >> >> an application? I think DECADE's philosophy = is that applications
    >> >> >> should decide this. A simple way to do this is e= xplicit deletion by
    >> >> >> an
    >> >> >> application, but perhaps a more efficient (yet m= ore complex)
    >> >> >> solution
    >> >> >> is for an application to specify the replacement= policy to the
    >> >> >> server.
    >> >> >>
    >> >> > actually, the key in "the data classification a= nd small objects " is
    >> >> > whether does it or not in P2P application? i did not= find data
    >> >> > classification was adopted in P2P application so far= , let alone
    >> >> > DECADE need
    >> >> > to classify the data used in all kinds of applicatio= n.
    >> >> >
    >> >>
    >> >> So, do you agree that it is problematic to try and classi= fy each type
    >> >> of application and try to specify the typical workload fo= r each class?
    >> >>
    >> >> My point was that I don't think its necessary to do t= he classification
    >> >> at all.  It is more extensible (and directly useful)= for a server to
    >> >> just give it direct hints about what would be preferable.=
    >> >
    >> > yep, i believe it may be a little difficult, but worthy doing= . specially
    >> > for improving the resource utilization within a single server= and
    >> > reducing
    >> > the response time for client. what about others opinion?
    >>
    >> Can you justify why giving classifications (e.g., "I'm a = live
    >> streaming application") would be better than giving specific = hints
    >> (e.g., "please don't bother persistent these objects to d= isk")?
    >
    > i mean data in different kind of operation mode and attribute should h= ave
    > different user patterns and storage rules, which may be help to improv= e the
    > resource utilization and reduce the response time for request, what ar= e you
    > understanding?

    That's fine. Explicit and more-specific hints are a differe= nt way to
    accomplish the same thing, and seem to be a much better design to me.
    They are simpler from an extensibility and implementation point of
    view.

    >> > >>
    >> >> >> Removal of Expired Records:
    >> >> >>
    >> >> >> "However, the two scenarios did not mention= how to handle the old
    >> >> >> resource if the user distributes the new resourc= e which is an
    >> >> >> updated
    >> >> >> copy of the old resource."
    >> >> >>
    >> >> >> Why does this need to be handled in the requirem= ents?  Are you
    >> >> >> trying
    >> >> >> to draw the distinction between immediate deleti= on of content and
    >> >> >> lazy
    >> >> >> deletion?
    >> >> >>
    >> >> > i mean the meaning of delete operation and how to ha= ndle the expired
    >> >> > records need to be clarify in requirements.
    >> >>
    >> >> My inclination is that "deleted" means that oth= er requests the object
    >> >> of the same name should result an error, until another ob= ject with the
    >> >> same name is stored.
    >> >
    >> > okay, under the scenario "client uploads the new version= , and did not
    >> > specify how to handle the old version", did DECADE serve= r delete the
    >> > older
    >> > version (or just label it unavailable, anyway, it is implemen= tation
    >> > issue )
    >> > or not ? in another word, just replace the older version with= the new
    >> > version with the same name?
    >>
    >> In this case, I would think the "write" of the new objec= t should be
    >> rejected, or if desired, we could have an overwrite option.  = This
    >> could be added to the requirements if it helps to clarify.
    >> yep, no matter which solution is chosen, let the understanding
    >> unanimously:D
    >> > how to handle the older version which is
    >> > transferring from server to client?
    >>
    >> I think it would be cleaner to ask the server to continue sending = an
    >> object once it has been started, but ultimately this would be the<= br> >> decision of the server's implementation I think.  Maybe a= "SHOULD"
    >> requirement.  This could be added if desired.
    >>
    > Thank you for these questions.  It helps design the requirements = more
    > cleanly if there are specific scenarios in front of us :)
    > just discussion together:D and also thanks for your points to help me<= br> > understanding more!

    Thanks,
    Rich

    >> Rich
    >>
    >> >> I think that the time the data is removed from disk (or m= emory) should
    >> >> be up to the implementation. A storage provider might sti= ll have as
    >> >> part of some agreement that deleted data will be removed = within X
    >> >> days/hours/minutes/whatever.
    >> >
    >> >    agree with you.
    >> >>
    >> >> If people in the WG think it is necessary, we could have = a requirement
    >> >> that says the protocol should support an argument indicat= ing immediate
    >> >> deletion, but it is not clear that we need this.
    >> >>
    >> >> Rich
    >> >>
    >> >> >>
    >> >> >> Thanks!
    >> >> >> Rich
    >> >> >>
    >> >> >>
    >> >> >> On Mon, Dec 27, 2010 at 12:57 AM, =D6=EC=E4=EC &= lt;buptxiaozhu@gmail.com> w= rote:
    >> >> >> > Dear all,
    >> >> >> >
    >> >> >> > There is a slightly updated version of the = decade additional
    >> >> >> > requirements
    >> >> >> > draft.
    >> >> >> >
    >> >> >> >
    >> >> >> > https://datat= racker.ietf.org/doc/draft-zhu-decade-additional-requirements/
    >> >> >> >
    >> >> >> > Jin Peng, Yunfei Zhang and me are expecting= to have a discussion
    >> >> >> > with
    >> >> >> > all of
    >> >> >> > you.
    >> >> >> >
    >> >> >> > Any comments are appreciated!
    >> >> >> >
    >> >> >> > A new version of I-D,
    >> >> >> > draft-zhu-decade-additional-requirements-00= .txt
    >> >> >> > has been successfully submitted by Xiao Zhu= and posted to the IETF
    >> >> >> > repository.
    >> >> >> >
    >> >> >> > Filename:      draft-zhu-dec= ade-additional-requirements
    >> >> >> > Revision:      00
    >> >> >> > Title:           &= nbsp;     Additional protocol requirements on DECADE
    >> >> >> > Creation_date:         = 2010-12-27
    >> >> >> > WG ID:           &= nbsp;     Independent Submission
    >> >> >> > Number_of_pages: 10
    >> >> >> >
    >> >> >> > Abstract:
    >> >> >> > The DECoupled Application Data Enroute(DECA= DE)working group is
    >> >> >> > specifying standardized interfaces for acce= ssing in-network
    >> >> >> > storage
    >> >> >> > from applications to store, retrieve and ma= nage data. The main
    >> >> >> > object
    >> >> >> > is to provide a framework that is useful to= the applications,
    >> >> >> > including P2P applications and other data-o= riented applications,
    >> >> >> > possibly related applications that can bene= fit from accessing in-
    >> >> >> > network storage. This memo focuses on some = requirements such as
    >> >> >> > request redirecting and so on which are on = the central of
    >> >> >> > mobility,
    >> >> >> > wireless network environment and CDN applic= ation. We present these
    >> >> >> > in
    >> >> >> > this memo as additional requirements that s= hould be considered for
    >> >> >> > the DECADE architecture and protocol specif= ications.
    >> >> >> >
    >> >> >> >
    >> >> >> >
    >> >> >> > The IETF Secretariat.
    >> >> >> >
    >> >> >> > --
    >> >> >> > Best wishes,
    >> >> >> >
    >> >> >> > Beijing University of Posts & Telecommu= nications (BUPT)
    >> >> >> > Zhu Xiao  ( =D6=EC=E4=EC )
    >> >> >> > E-mail: buptxiaozhu@gmail.com
    >> >> >> > mobile:+86 134-8881-9004
    >> >> >> >
    >> >> >> > ___________________________________________= ____
    >> >> >> > decade mailing list
    >> >> >> > decade@i= etf.org
    >> >> >> > https://www.ietf.org/mailman/listinfo/decad= e
    >> >> >> >
    >> >> >> >
    >> >> >
    >> >> >
    >> >> >
    >> >> > --
    >> >> > Best wishes,
    >> >> >
    >> >> > Beijing University of Posts & Telecommunications= (BUPT)
    >> >> > Zhu Xiao  ( =D6=EC=E4=EC )
    >> >> > E-mail: bup= txiaozhu@gmail.com
    >> >> > mobile:+86 134-8881-9004
    >> >
    >> >
    >> >
    >> > --
    >> > Best wishes,
    >> >
    >> > Beijing University of Posts & Telecommunications (BUPT) >> > Zhu Xiao  ( =D6=EC=E4=EC )
    >> > E-mail: buptxiaozhu@= gmail.com
    >> > mobile:+86 134-8881-9004
    >> >
    >
    >
    >
    > --
    > Best wishes,
    >
    > Beijing University of Posts & Telecommunications (BUPT)
    > Zhu Xiao  ( =D6=EC=E4=EC )
    > E-mail: buptxiaozhu@gmail.com=
    > mobile:+86 134-8881-9004
    >



    --
    Best wishes= ,

    Beijing University of Posts & Telecommunications (BUPT)
    Zhu= Xiao  ( =D6=EC=E4=EC )
    E-mail: buptxiaozhu@gmail.com
    mobile:+86 134-8881-9004
    --90e6ba5bb927cd53b2049ddb0460-- --90e6ba5bb927cd53b7049ddb0461 Content-Type: image/gif; name="1A5.gif" Content-Transfer-Encoding: base64 X-Attachment-Id: 1A5@goomoji.gmail Content-ID: <1A5@goomoji.gmail> R0lGODlhEAAMAKIFAF5LAP/zxAAAANyuAP/gaP///wAAAAAAACH/C05FVFNDQVBFMi4wAwEAAAAh +QQJZAAFACwAAAAAEAAMAAADO1iq0/6LhUkBmCOOQLonAJEtGyEI3dmNkom6q8Z9H1sML22OTnC+ P9GNU9LFBquZJxS7NWYWZpP0qBYSACH5BAkKAAUALAAAAAAQAAwAAAM7WKrT/ouFSQGYI45AuicA kS0bIQjd2Y2Sibqrxn0fWwwvbbJNcL4/UWug84yIIlooxiiBLLXI7UEtJAAAIfkECQoABQAsAAAA ABAADAAAAzhYqtP+i4VJAZgjjkC6JwCRLRshCN3ZjZKJuqvGfR9bNLQnsOWguijeKhcjDWihYgtk qUVuj2ghAQAh+QQFCgAFACwAAAAAEAAMAAADN1iq0/6LhUkBmCOOQLonAJEtGyEI3dmNkom6q8Z9 H1s4dGqXw3uiu1VOpGl8QjHSzIJMkh7QQgIAIfkEBRQABQAsAAAFAAgABQAAAxFYMxpEwy0H3xBY KBZf+c2TAAAh+QQFCgAFACwEAAYABQACAAADBlgqMkEqAQAh+QQFAAAFACwGAAYAAwACAAADBChE 0gkAIfkECQoABQAsAAAFAAcAAgAAAwVYuqxCCQAh+QQJCgAFACwAAAAAEAAMAAADGFi63P4wyknd CESOUYbIUVB1BMFR26iuCQAh+QQFkAEFACwAAAAAEAAMAAADO1iq0/6LhUkBmCOOQLonAJEtGyEI 3dmNkom6q8Z9H1sML22OTnC+P9GNU9LFBquZJxS7NWYWZpP0qBYSADs= --90e6ba5bb927cd53b7049ddb0461-- From haibin.song@huawei.com Mon Mar 7 01:31:07 2011 Return-Path: X-Original-To: decade@core3.amsl.com Delivered-To: decade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F42383A6942 for ; Mon, 7 Mar 2011 01:31:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.845 X-Spam-Level: X-Spam-Status: No, score=-1.845 tagged_above=-999 required=5 tests=[AWL=-1.350, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UmuqhPNP8x0Z for ; Mon, 7 Mar 2011 01:31:06 -0800 (PST) Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id 213BA3A6827 for ; Mon, 7 Mar 2011 01:31:06 -0800 (PST) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LHO00MFRL5KML@szxga05-in.huawei.com> for decade@ietf.org; Mon, 07 Mar 2011 17:32:09 +0800 (CST) Received: from szxeml201-edg.china.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LHO00LB2L5KXX@szxga05-in.huawei.com> for decade@ietf.org; Mon, 07 Mar 2011 17:32:08 +0800 (CST) Received: from SZXEML401-HUB.china.huawei.com (10.82.67.31) by szxeml201-edg.china.huawei.com (172.24.2.39) with Microsoft SMTP Server (TLS) id 14.1.270.1; Mon, 07 Mar 2011 17:32:05 +0800 Received: from SZXEML505-MBS.china.huawei.com ([169.254.1.207]) by SZXEML401-HUB.china.huawei.com ([10.82.67.31]) with mapi id 14.01.0270.001; Mon, 07 Mar 2011 17:32:07 +0800 Date: Mon, 07 Mar 2011 09:32:06 +0000 From: Songhaibin X-Originating-IP: [10.138.41.70] To: "decade@ietf.org" Message-id: MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: zh-CN Content-transfer-encoding: 7BIT Accept-Language: en-US, zh-CN Thread-topic: Agenda requests for IETF 80 Thread-index: AcvcqoYQcM14CBb8Qq+HH3KWjH549w== X-MS-Has-Attach: X-MS-TNEF-Correlator: Subject: [decade] Agenda requests for IETF 80 X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.9 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, 07 Mar 2011 09:31:07 -0000 Hi all, If you are interested in getting a slot on the agenda of the next DECADE meeting, please send the chairs a request by Monday March 14. Please provide a title for the agenda slot, the requested amount of time as well as a list of the issues that will be addressed during the allocated time. As usual, the goal is to make best use of meeting time in order to make progress on the chartered work items. Working group documents will thus have max priority, followed by individual drafts candidate for fulfilling charter milestones and document that have attracted attention on the mailing list. BR, Haibin and Rich From Internet-Drafts@ietf.org Mon Mar 7 15:45:05 2011 Return-Path: X-Original-To: decade@core3.amsl.com Delivered-To: decade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 073613A687B; Mon, 7 Mar 2011 15:45:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.589 X-Spam-Level: X-Spam-Status: No, score=-102.589 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LgCS1k4IJbxD; Mon, 7 Mar 2011 15:45:02 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 447903A6878; Mon, 7 Mar 2011 15:45:02 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110307234502.11613.45896.idtracker@localhost> Date: Mon, 07 Mar 2011 15:45:02 -0800 Cc: decade@ietf.org Subject: [decade] I-D Action:draft-ietf-decade-arch-00.txt X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.9 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, 07 Mar 2011 23:45:05 -0000 --NextPart 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 Architecture Author(s) : R. Alimi, et al. Filename : draft-ietf-decade-arch-00.txt Pages : 25 Date : 2011-03-07 Peer-to-peer (P2P) applications have become widely used on the Internet today and make up a large portion of the traffic in many networks. One technique to improve the network efficiency of P2P applications is to introduce storage capabilities within the networks. The DECADE Working Group has been formed with the goal of developing an architecture to provide this capability. This document presents an architecture, discusses the underlying principles, and identifies core components and protocols supporting the architecture. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-decade-arch-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-decade-arch-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-03-07153037.I-D@ietf.org> --NextPart-- From li.lichun1@zte.com.cn Tue Mar 8 01:47:42 2011 Return-Path: X-Original-To: decade@core3.amsl.com Delivered-To: decade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8AC093A67B8 for ; Tue, 8 Mar 2011 01:47:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.838 X-Spam-Level: X-Spam-Status: No, score=-101.838 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iqsKEs1pCYj9 for ; Tue, 8 Mar 2011 01:47:41 -0800 (PST) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by core3.amsl.com (Postfix) with ESMTP id 1C04F3A67D7 for ; Tue, 8 Mar 2011 01:47:40 -0800 (PST) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 205951047745636; Tue, 8 Mar 2011 17:43:24 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.16] with StormMail ESMTP id 34558.1047745636; Tue, 8 Mar 2011 17:39:17 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id p289mejp091104 for ; Tue, 8 Mar 2011 17:48:40 +0800 (GMT-8) (envelope-from li.lichun1@zte.com.cn) In-Reply-To: <03EF6997-73A2-4F65-923C-ECF8836EEA76@nokia.com> To: "decade@ietf.org" MIME-Version: 1.0 X-KeepSent: 0562ED06:A5327300-4825784D:0035C19A; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: li.lichun1@zte.com.cn Date: Tue, 8 Mar 2011 17:48:37 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-03-08 17:48:41, Serialize complete at 2011-03-08 17:48:41 Content-Type: multipart/alternative; boundary="=_alternative 0035F20B4825784D_=" X-MAIL: mse02.zte.com.cn p289mejp091104 Subject: [decade] Supporting DECADE in PPSP X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.9 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, 08 Mar 2011 09:47:42 -0000 This is a multipart message in MIME format. --=_alternative 0035F20B4825784D_= Content-Type: text/plain; charset="US-ASCII" Hi, all We submitted a new draft about supporting DECADE in PPSP. It can be accessed at http://www.ietf.org/id/draft-le-ppsp-decade-interoperation-00.txt Comments are welcome. BR Lichun A new version of I-D, draft-le-ppsp-decade-interoperation-00.txt has been successfully submitted by Guan Le and posted to the IETF repository. Filename: draft-le-ppsp-decade-interoperation Revision: 00 Title: PPSP Usage for DECADE Creation_date: 2011-03-07 WG ID: Independent Submission Number_of_pages: 14 Abstract: P2P Streaming has become popular application in the Internet. Currently, most home subscribers access Internet via ADSL, in which downlink bandwidth and uplink bandwidth are not symmetric. This feature would influence the performance of P2P Streaming, and the problem may be worse in mobile scenarios. This draft presents the interoperation between PPSP protocol and DECADE protocol to provide DECADE service for PPSP applications. Typically, there are two solution to achieve interoperation, loose interoperation among peers, and close interoperation via connection of peer and tracker. By introducing DECADE in both tracker protocol and peer protocol, PPSP streaming can alleviate strength of upload bandwidth and improve performance for fix and mobile scenario. The IETF Secretariat. -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. --=_alternative 0035F20B4825784D_= Content-Type: text/html; charset="US-ASCII"
    Hi, all

    We submitted a new draft about supporting DECADE in PPSP. It can be accessed at http://www.ietf.org/id/draft-le-ppsp-decade-interoperation-00.txt
    Comments are welcome.

    BR
    Lichun



    A new version of I-D, draft-le-ppsp-decade-interoperation-00.txt has been successfully submitted by Guan Le and posted to the IETF repository.

    Filename:                  draft-le-ppsp-decade-interoperation
    Revision:                  00
    Title:                                   PPSP Usage for DECADE
    Creation_date:                  2011-03-07
    WG ID:                                   Independent Submission
    Number_of_pages: 14

    Abstract:
    P2P Streaming has become popular application in the Internet.
    Currently, most home subscribers access Internet via ADSL, in which
    downlink bandwidth and uplink bandwidth are not symmetric.  This
    feature would influence the performance of P2P Streaming, and the
    problem may be worse in mobile scenarios.  This draft presents the
    interoperation between PPSP protocol and DECADE protocol to provide
    DECADE service for PPSP applications.  Typically, there are two
    solution to achieve interoperation, loose interoperation among peers,
    and close interoperation via connection of peer and tracker.  By
    introducing DECADE in both tracker protocol and peer protocol, PPSP
    streaming can alleviate strength of upload bandwidth and improve
    performance for fix and mobile scenario.
                                                                                     


    The IETF Secretariat.     



    --------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
    --=_alternative 0035F20B4825784D_=-- From davidbryan@gmail.com Wed Mar 9 11:03:30 2011 Return-Path: X-Original-To: decade@core3.amsl.com Delivered-To: decade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 26E893A6967 for ; Wed, 9 Mar 2011 11:03:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.527 X-Spam-Level: X-Spam-Status: No, score=-100.527 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tiGaAX68iUzo for ; Wed, 9 Mar 2011 11:03:27 -0800 (PST) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 0E86D3A680F for ; Wed, 9 Mar 2011 11:03:26 -0800 (PST) Received: by wyb42 with SMTP id 42so841436wyb.31 for ; Wed, 09 Mar 2011 11:04:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=8C7pdU29FcJQ0UAxKOzJunxBfdXZh86e4yjAKdGp9Uc=; b=ABnVRSAc504xTOhaFg23+aqzIbDozzrI9bIofaOtqX57UOJBrMmvseDE7g+BOkssOK ojnnSnOn5SYRFyPgstkzvqu3nBg1qPi4Ex9KcrMm4m4DUT/M1R7Dyzs3M1Uzaek8Oikj xSCyDNNK2APUnx5l4J3ndvwGEkAEPfomh2TGI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=xZxj+b5gbqlDJfUVnnHMcndORDVY6nNPsgZQlj+X8GcyjMieK/PAexhEQ4HRIIl2sD QrbUk0oBRFWr2LRVww3ymITg/nFDBMYskieOtCIrlyDJ7NNaRpKiLiyKMRIlKHvqDtET WRrycKtooHdHkwl/QMoeBRiXG3Dmt2GWMIxEk= MIME-Version: 1.0 Received: by 10.227.197.199 with SMTP id el7mr6091065wbb.32.1299697483104; Wed, 09 Mar 2011 11:04:43 -0800 (PST) Sender: davidbryan@gmail.com Received: by 10.227.143.77 with HTTP; Wed, 9 Mar 2011 11:04:41 -0800 (PST) In-Reply-To: References: <1CA25301D2219F40B3AA37201F0EACD11343C0AB@PACDCEXMB05.cable.comcast.com> Date: Wed, 9 Mar 2011 14:04:41 -0500 X-Google-Sender-Auth: 3RVcu6MBilmZ6mU-cER07Pss1rQ Message-ID: From: "David A. Bryan" To: Richard Alimi Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable Cc: "decade@ietf.org" Subject: Re: [decade] draft-zhu-decade-additional-requirements X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.9 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, 09 Mar 2011 19:03:30 -0000 A few comments inline: 2011/3/2 Richard Alimi : > Hi All, > > I'll offer a summary of this discussion. Let me know if I missed > anything, or if there are objections/other thoughts on these proposed > resolutions. > > Redirection: > - We can add a requirement mentioning that DECADE may support redirection= . +1 > Data Classification: > - I (personally) strongly disagree with attempting to classify access > patterns or applications. We could add something saying that explicit > hints (a la www.ietf.org/proceedings/78/slides/nfsv4-0.pdf) could be > provided in DECADE. However, I don't think we need to do something > new here. In particular, if the underlying storage/data transport > supports hints, a DECADE client or server can use it. Exactly. My preference is to keep the protocol as simple as possible, for a few reasons. First, it is very critical for getting an IETF protocol finished to keep things simple. Otherwise, it takes years to get a protocol finished. Even more critically, I just don't think we need this from a protocol perspective. We should avoid trying to classify the application/access pattern. David > Storage Status: > - Update section 5.1.6 to indicate that status information should > include permissions of stored objects, if applicable. > - Update 5.1.6 to indicate that status information should include > other information about resource usage (the clients own resources, or > resources used by other clients that have been authorized to > read/write objects or open connections to one's storage). > > Requirements for object deletion/overwriting: > - DECADE MAY have an overwrite flag (note that this may or may not be > necessary depending on our naming, but the requirements document > probably is not the place to take a stand on this at the current > point.) > - If an object is deleted as it is concurrently being read, then the > server MAY continue to read it (lazy deletion), or it MAY discontinue > reading the object and signal an error to the client reading the > object. > > Would this be sufficient to merge in the points from > draft-zhu-decade-additional-requirements-00 and this ensuing > discussion? > > Thanks, > Rich > > > 2011/3/2 Woundy, Richard : >> Folks, >> >> >> >> Do we have consensus yet about how the WG could have a single DECADE >> requirements document going forward? I can't tell the state of our >> requirements consolidation from the email thread below. >> >> >> >> It would be preferable if we could resolve this fully on the WG mailing >> list, but this is important enough to allocate some time at our meeting = in >> Prague. >> >> >> >> -- Rich >> >> >> >> From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.org] On Behalf= Of >> ?? >> Sent: Sunday, January 16, 2011 9:02 PM >> To: Richard Alimi >> Cc: decade@ietf.org >> Subject: Re: [decade] draft-zhu-decade-additional-requirements >> >> >> >> hi, Richard: >> >> >> >> thanks for your reply:D >> >> additional discussion see inline:D >> >> >> >> 2011/1/14 Richard Alimi >> >> HI Xiao, >> >> 2011/1/12 =D6=EC=E4=EC : >> >>> hi, Richard >>> see inline:D >>> >>> 2011/1/11 Richard Alimi >>>> >>>> Hi Xiao, >>>> >>>> On Mon, Jan 10, 2011 at 6:45 PM, =D6=EC=E4=EC = wrote: >>>> > >>>> > hi, Richard, sorry for so late response because of be busy with othe= r >>>> > projects. >>>> > some discussion see inline:D marked by red. >>>> > >>>> > On Tue, Jan 4, 2011 at 4:06 AM, Richard Alimi >>>> > wrote: >>>> >> >>>> >> Hi Xiao, >>>> >> >>>> >> Thank you for the draft. Some comments on the requirements: >>>> >> >>>> >> Request Redirects: >>>> >> >>>> >> This would provide some additional freedom for the storage provider= . >>>> >> I think it is reasonable since it doesn't necessitate additional >>>> >> complexity for the DECADE server, but allows it if desired. However= , >>>> >> note that it may complicate some of the other components of the >>>> >> design. In particular, if there is a per-user quota for storage, is >>>> >> the user made aware of the quota at each in-network storage (if the= re >>>> >> is no shared storage between them)? Resource sharing policies may = be >>>> >> impacted (e.g., if a bandwidth sharing weight of 1 may mean somethi= ng >>>> >> different at DECADE server A than it does at DECADE server B). At >>>> >> this point it may be best to just note these so they are documented= , >>>> >> but since the specification of the resource sharing policies are st= ill >>>> >> being contemplated for the basic case of a single server it may be >>>> >> premature to even try and solve them for the case supporting >>>> >> redirection. >>>> >> >>>> > actually, you mean two points, right? >>>> > 1. whether or not to be ware of the content at each in-network stora= ge >>>> > and of course resource sharing policies can be impact in the request >>>> > redirection. your suggestion"just to note these so they are document= ed" >>>> > will >>>> > be ok, or DECADE server list with some parameters will be return for >>>> > user to >>>> > select the appropriate DECADE server, which can avoid the different >>>> > weighted >>>> > of the same parameter in server decision. but the parameter used in >>>> > select >>>> > the best DECADE server will be known for DECADE servers, in which ot= her >>>> > complexities will be added. anyway, all the solution are the >>>> > implementation >>>> > issue, which, i believe, does not impact the necessity of the >>>> > requirement. >>>> >>>> In general, I'd agree that the decision about where to redirect would >>>> be an implementation issue. >>>> >>>> > >>>> > 2. you mean "the resource sharing policies are still being considere= d >>>> > in >>>> > a single server", so it may be premature to support redirection. th= e >>>> > architecture and protocol will be badly impacted if the requirements >>>> > change. >>>> > so the designing can be taken step by step, but the requirements >>>> > should be >>>> > overall considered. >>>> >>>> I said that it is probably premature to consider how resource sharing >>>> policies works across servers (or even if we need to say anything >>>> about it) since we have not determined how to specify them (or rather, >>>> how little we need to specify in protocol) for a single server. I did >>>> not mean to imply that redirection could not be introduced as a >>>> requirement. >>>> >>> >>>> >>>> > >>>> > >>>> >> >>>> >> Multi-connection: >>>> >> >>>> >> I'm not quite clear on the intention of the requirement. My >>>> >> understanding is that you wish the client to be able to have multip= le >>>> >> connections open spanning multiple DECADE servers. Is that correct? >>>> >> >>>> >> If so, do we need this stated as a requirement or the protocol? Or = is >>>> >> this a policy that would be allowed/disallowed by the storage >>>> >> provider? >>>> >> >>>> > yep, your understanding is right, the scenarios were just described = in >>>> > draft as "soft handover in wireless environment and delete operation= in >>>> > multi-servers". under these consideration, the authentication and >>>> > authorization need to be taken each time when setup connection with = a >>>> > new >>>> > DECADE server, or just be taken only once during the service? >>>> >>>> The DECADE server should need to do some sort of check on each new >>>> connection, regardless of whether the user has or previously had a >>>> connection open to a different DECADE server, right? Note that the >>>> requirements don't indicate how authentication or authorization is >>>> done, and allow a server to make optimizations if it is enforcing the >>>> same permissions. >>>> >>>> Can you indicate where the existing authorization-related requirements >>>> (in particular, 4.1.6.3 of draft-ietf-decade-reqs-00) do not suffice >>>> for the use case you are thinking of? >> >>> as considering the service continuity, the next serving DECADE server >>> should know the progress of the service, how does they know? >> >> By progress of the service, do you mean current user state (e.g., >> quota, recent resource usage history, permissions, etc)? >> >> yes, and include data delivery proceeding. >>> so if the >>> service proceeding information should be known by the next serving serv= er, >>> or different servers need to coordinate and schedule each other to fulf= ill >>> the user request, i believe the the 4.1.6.3 of the >>> draft-ietf-decade-req-00 >>> cannot satisfy the req. what do you think about? >> >> Note that the protocol that is covered here is the client-server >> protocol. Some of the same protocol may be useful between DECADE >> servers (especially in different administrative domains) for storing >> and retrieving data, but that does not mean that there can't be >> additional protocol(s) (not specified here) that are used between >> DECADE servers as well. For example, if DECADE servers within an >> administrative domain can certainly have their own mechanism to share >> such information. If such capabilities were included in the DECADE >> protocol (e.g., a need to do this between administrative domains), >> that sounds like lots more complexity that we need at this point. >> but the access between in-network storage also is included in IAP descri= bed >> in problem statement. i mean why not put this kind of function in DECAD= E >> since the IAP is defined just like that? >> That said, it sounds to me like what is described in 4.1.6.3 would be >> sufficient (from the perspective of the client-server protocol, >> anyways) to implement what you're describing. If not, what >> specifically is missing and what use-case does it not meet? >> >> so you mean the information you mentioned above, just like current user >> state (e.g., >> quota, recent resource usage history, permissions, etc) was already incl= uded >> in DECADE requirement? what about the data delivery proceeding informati= on? >> can you specify the chapter for me ? thanks? >>>> > >>>> > >>>> >> >>>> >> Data Distribution: >>>> >> >>>> >> I'm also confused about the intent of this requirement. This >>>> >> statement has me somewhat worried: "The distribution is transparent= to >>>> >> the users as they interact with the in-network storage as a single >>>> >> logical system." Does this mean that you are proposing for DECADE >>>> >> servers to assume the responsibility for deciding how data is to be >>>> >> distributed throughout the network, including the path of the data, >>>> >> which servers act as intermediate caches, content expiration polici= es, >>>> >> etc? If this is true, I think it is missing one of the major point= s >>>> >> of DECADE. In particular, these decisions are application-dependent >>>> >> and are not implemented within DECADE. Instead, DECADE provides the >>>> >> basic capabilities and the functionality described above are >>>> >> implemented by the applications using DECADE. >>>> >> >>>> >> Or, am I misinterpreting the intent of the requirement? >>>> >> >>>> > you mean DECADE provides the basic capabilities, so can you give som= e >>>> > specify explanations on DECADE capabilities in supporting data >>>> > distribution? >>>> >> >>>> >>>> The problem statement gives a couple of scenarios. The "Integration >>>> Examples" presentation from IETF 79 also has more details of an >>>> on-going effort at Yale. >> >>> okay, thx for your information, i will lookup and refer, actually, the >>> content publisher described in problem statement remind me of the >>> protocol requirements which i did not find in draft-ietf-decade-reqs-00= to >>> support content publish. or i miss some points? >> >> Which requirements do you think are missing? >> >>>> >> Service Assurance: >>>> >> >>>> >> It seems problematic to include "assurance" in a DECADE. Shouldn't >>>> >> these instead be part of SLAs with a storage provider? Why should >>>> >> they be DECADE's responsibility? >>>> >> >>>> >> Regarding "resource reservation", are you referring to an actual >>>> >> reservation (which might be problematic -- see above) or do you mea= n >>>> >> that the resource share should able to be specified at the time the >>>> >> connection opens and be assumed to be the same for the duration of = the >>>> >> connection? >>>> >> >>>> >> Regarding Dynamic Feedback, is this orthogonal to the storage >>>> >> protocol? It seems like what you want here is a generic "status" >>>> >> service saying how loaded a server is? >>>> >> >>>> > thats right, actually, the flow control mechanism was under discussi= on >>>> > in writing the draft at first. what about your opinion in this >>>> > requirements? >>>> > >>>> >>>> I'm not sure what the typical way of providing such "load status" >>>> information for IETF protocols, but my inclination is that it should >>>> not be in the DECADE protocol itself. Maybe someone else with a >>>> longer history in IETF could jump in here :) >>> so can i understand that "load status" is kind of necessity informatio= n >>> for DECADE Server, but where and who collects the information are >>> remain discussion? >> >> The storage provider is free to collect the information wherever and >> however they wish. The DECADE server implementation could additional >> export whatever status information it wishes. I don't think the DECADE >> protocol needs to be concerned with that. >> >> Note that certain error conditions (e.g., overload, insufficient >> resources) may be signaled by a DECADE server (there are already have >> requirements for those). If you are referring to status for a user's >> resources, there is already a requirement for that too. >> >> I'm just not convinced that the DECADE protocol needs to export its >> current load status to clients. >> >> actually i am not sure which elements in DECADE needs the load >> status,(DECADE client or network storage if the network storage needs to >> redirect the request or both?). >> >> >> >> And the requirement draft currently seems describe the overload conditio= n as >> the event triggering. do you think if it is necessary to periodically >> reporting of the DECADE network status to client for its network storage >> selection? >> >> >> >> and the requirement draft just describe DECADE which is busy to serve ot= her >> requests must be able to reject requests, not consider how to handle the >> user request after being rejected? >> >>>> >> >>>> >> Data classification: >>>> >> >>>> >> Would it be better to instead have the client specify properties of >>>> >> the content instead of place it into ? See >>>> >> www.ietf.org/proceedings/78/slides/nfsv4-0.pdf for an example of th= is >>>> >> approach for NFS. >>>> >> >>>> >> I think a problem with classifying applications is that it assumes >>>> >> that applications fit one of the supplied classifications. What if = it >>>> >> may fit multiple classifications? or none? Another problem is it >>>> >> assumes that servers assume based on indirect and assumed informati= on >>>> >> that they know what to do with a particular piece of content. Why n= ot >>>> >> have an application specify its desires directly? >>>> >> >>>> > >>>> > >>>> >> >>>> >> Small Objects: >>>> >> >>>> >> What is the new requirement here? Why is the existing requirement = in >>>> >> draft-ietf-decade-reqs-00 insufficient? >>>> >> >>>> >> This also has me a bit worried: >>>> >> "And the in-network storage has the limited storage capacity, with = the >>>> >> arrival of user requests and data distribution requirements, the da= ta >>>> >> stored in the in-network storage will be replaced if the storage >>>> >> reaches the limit and data arrivals continually." >>>> >> >>>> >> How does the server know what the proper replacement strategy is fo= r >>>> >> an application? I think DECADE's philosophy is that applications >>>> >> should decide this. A simple way to do this is explicit deletion by= an >>>> >> application, but perhaps a more efficient (yet more complex) soluti= on >>>> >> is for an application to specify the replacement policy to the serv= er. >>>> >> >>>> > actually, the key in "the data classification and small objects " is >>>> > whether does it or not in P2P application? i did not find data >>>> > classification was adopted in P2P application so far, let alone DECA= DE >>>> > need >>>> > to classify the data used in all kinds of application. >>>> > >>>> >>>> So, do you agree that it is problematic to try and classify each type >>>> of application and try to specify the typical workload for each class? >>>> >>>> My point was that I don't think its necessary to do the classification >>>> at all. It is more extensible (and directly useful) for a server to >>>> just give it direct hints about what would be preferable. >>> >>> yep, i believe it may be a little difficult, but worthy doing. speciall= y >>> for improving the resource utilization within a single server and reduc= ing >>> the response time for client. what about others opinion? >> >> Can you justify why giving classifications (e.g., "I'm a live >> streaming application") would be better than giving specific hints >> (e.g., "please don't bother persistent these objects to disk")? >> >> i mean data in different kind of operation mode and attribute should hav= e >> different user patterns and storage rules, which may be help to improve = the >> resource utilization and reduce the response time for request, what are = you >> understanding? >>> >> >>>> >> Removal of Expired Records: >>>> >> >>>> >> "However, the two scenarios did not mention how to handle the old >>>> >> resource if the user distributes the new resource which is an updat= ed >>>> >> copy of the old resource." >>>> >> >>>> >> Why does this need to be handled in the requirements? Are you tryi= ng >>>> >> to draw the distinction between immediate deletion of content and l= azy >>>> >> deletion? >>>> >> >>>> > i mean the meaning of delete operation and how to handle the expired >>>> > records need to be clarify in requirements. >>>> >>>> My inclination is that "deleted" means that other requests the object >>>> of the same name should result an error, until another object with the >>>> same name is stored. >>> >>> okay, under the scenario "client uploads the new version, and did not >>> specify how to handle the old version", did DECADE server delete the ol= der >>> version (or just label it unavailable, anyway, it is implementation iss= ue >>> ) >>> or not ? in another word, just replace the older version with the new >>> version with the same name? >> >> In this case, I would think the "write" of the new object should be >> rejected, or if desired, we could have an overwrite option. This >> could be added to the requirements if it helps to clarify. >> >> yep, no matter which solution is chosen, let the understanding unanimous= ly:D >>> how to handle the older version which is >>> transferring from server to client? >> >> I think it would be cleaner to ask the server to continue sending an >> object once it has been started, but ultimately this would be the >> decision of the server's implementation I think. Maybe a "SHOULD" >> requirement. This could be added if desired. >> >> Thank you for these questions. It helps design the requirements more >> cleanly if there are specific scenarios in front of us :) >> just discussion together:D and also thanks for your points to help me >> understanding more! >> Rich >> >>>> I think that the time the data is removed from disk (or memory) should >>>> be up to the implementation. A storage provider might still have as >>>> part of some agreement that deleted data will be removed within X >>>> days/hours/minutes/whatever. >>> >>> agree with you. >>>> >>>> If people in the WG think it is necessary, we could have a requirement >>>> that says the protocol should support an argument indicating immediate >>>> deletion, but it is not clear that we need this. >>>> >>>> Rich >>>> >>>> >> >>>> >> Thanks! >>>> >> Rich >>>> >> >>>> >> >>>> >> On Mon, Dec 27, 2010 at 12:57 AM, =D6=EC=E4=EC wrote: >>>> >> > Dear all, >>>> >> > >>>> >> > There is a slightly updated version of the decade additional >>>> >> > requirements >>>> >> > draft. >>>> >> > >>>> >> > >>>> >> > https://datatracker.ietf.org/doc/draft-zhu-decade-additional-requ= irements/ >>>> >> > >>>> >> > Jin Peng, Yunfei Zhang and me are expecting to have a discussion >>>> >> > with >>>> >> > all of >>>> >> > you. >>>> >> > >>>> >> > Any comments are appreciated! >>>> >> > >>>> >> > A new version of I-D, >>>> >> > draft-zhu-decade-additional-requirements-00.txt >>>> >> > has been successfully submitted by Xiao Zhu and posted to the IET= F >>>> >> > repository. >>>> >> > >>>> >> > Filename: draft-zhu-decade-additional-requirements >>>> >> > Revision: 00 >>>> >> > Title: Additional protocol requirements on DECADE >>>> >> > Creation_date: 2010-12-27 >>>> >> > WG ID: Independent Submission >>>> >> > Number_of_pages: 10 >>>> >> > >>>> >> > Abstract: >>>> >> > The DECoupled Application Data Enroute(DECADE)working group is >>>> >> > specifying standardized interfaces for accessing in-network stora= ge >>>> >> > from applications to store, retrieve and manage data. The main >>>> >> > object >>>> >> > is to provide a framework that is useful to the applications, >>>> >> > including P2P applications and other data-oriented applications, >>>> >> > possibly related applications that can benefit from accessing in- >>>> >> > network storage. This memo focuses on some requirements such as >>>> >> > request redirecting and so on which are on the central of mobilit= y, >>>> >> > wireless network environment and CDN application. We present thes= e >>>> >> > in >>>> >> > this memo as additional requirements that should be considered fo= r >>>> >> > the DECADE architecture and protocol specifications. >>>> >> > >>>> >> > >>>> >> > >>>> >> > The IETF Secretariat. >>>> >> > >>>> >> > -- >>>> >> > Best wishes, >>>> >> > >>>> >> > Beijing University of Posts & Telecommunications (BUPT) >>>> >> > Zhu Xiao ( =D6=EC=E4=EC ) >>>> >> > E-mail: buptxiaozhu@gmail.com >>>> >> > mobile:+86 134-8881-9004 >>>> >> > >>>> >> > _______________________________________________ >>>> >> > decade mailing list >>>> >> > decade@ietf.org >>>> >> > https://www.ietf.org/mailman/listinfo/decade >>>> >> > >>>> >> > >>>> > >>>> > >>>> > >>>> > -- >>>> > Best wishes, >>>> > >>>> > Beijing University of Posts & Telecommunications (BUPT) >>>> > Zhu Xiao ( =D6=EC=E4=EC ) >>>> > E-mail: buptxiaozhu@gmail.com >>>> > mobile:+86 134-8881-9004 >>> >>> >>> >>> -- >>> Best wishes, >>> >>> Beijing University of Posts & Telecommunications (BUPT) >>> Zhu Xiao ( =D6=EC=E4=EC ) >>> E-mail: buptxiaozhu@gmail.com >>> mobile:+86 134-8881-9004 >>> >> >> >> -- >> Best wishes, >> >> Beijing University of Posts & Telecommunications (BUPT) >> Zhu Xiao ( =D6=EC=E4=EC ) >> E-mail: buptxiaozhu@gmail.com >> mobile:+86 134-8881-9004 > _______________________________________________ > decade mailing list > decade@ietf.org > https://www.ietf.org/mailman/listinfo/decade > From davidbryan@gmail.com Wed Mar 9 11:12:16 2011 Return-Path: X-Original-To: decade@core3.amsl.com Delivered-To: decade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D9B5B3A6892 for ; Wed, 9 Mar 2011 11:12:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.626 X-Spam-Level: X-Spam-Status: No, score=-99.626 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_42=0.6, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z9Yd9+41InVg for ; Wed, 9 Mar 2011 11:12:12 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 055B93A680F for ; Wed, 9 Mar 2011 11:12:11 -0800 (PST) Received: by fxm15 with SMTP id 15so890527fxm.31 for ; Wed, 09 Mar 2011 11:13:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references :x-goomoji-body:date:x-google-sender-auth:message-id:subject:from:to :cc:content-type; bh=CnWXiwKoVGIelq0GkWyfVVWhl/pa47XhuaiLyJrTDZw=; b=IyRDO1VtWdZU8wdUSCURZe87up0YePtHqF3IhNHZv7MGQKahYCruuDlmiOf3rhqgTG 4k6CUMxl7NuC6soJynKibAVK1r41mLXCpFEJa75y6vhHPtVNwHUYbK5vpbliPNA+xBUF 3LNDUhKZYW0RgpR77Y+HZ7HtomfOClNDyNxT0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:x-goomoji-body:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=IvMIXucvCTXJNKvyjuYjjvLcyCadsRDVPVgPBn5rv1KR77BGyHbxTASh0ZcV1GVNPK Vc4EYrvVwjLPLwX0KHduLvSQvxFlneN2u9KRFr2uW18M9gFEiOJtBq8/eETqOta+yP/e XiTTbnw8TG8pWx8Xhr63QYZmhaeMd+X1Tjg88= MIME-Version: 1.0 Received: by 10.223.65.196 with SMTP id k4mt1257946fai.9.1299697991954; Wed, 09 Mar 2011 11:13:11 -0800 (PST) Sender: davidbryan@gmail.com Received: by 10.223.86.200 with HTTP; Wed, 9 Mar 2011 11:13:11 -0800 (PST) In-Reply-To: References: X-Goomoji-Body: true Date: Wed, 9 Mar 2011 14:13:11 -0500 X-Google-Sender-Auth: POcmCKRmW35e9c7R3MD5izqSou8 Message-ID: From: "David A. Bryan" To: =?GB2312?B?1uzk7A==?= Content-Type: multipart/alternative; boundary=0015174c114213f42c049e118623 Cc: decade@ietf.org Subject: Re: [decade] draft-zhu-decade-additional-requirements X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.9 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, 09 Mar 2011 19:12:17 -0000 --0015174c114213f42c049e118623 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable Comments inline: 2011/3/6 =D6=EC=E4=EC > Hi, Richard: > > sorry for reply so late, because i should remember what we > are dissuasion and the key of the problem[?] > > > so many quoted texts, let me make a summarize. > > 1 multi connection, i have the arguments as followings: > > @me: > > > - need it to process new authentication and authorization after the > user moves in the wireless environment and access a new DECADE server > > @you: > > - DECADE server should need to do some sort of check on each new > connection, regardless of whether the user has or previously had a > connection open to a different DECADE server, > > --> okay, agree with you, but we should specify in the requirements draft= . > > @me: > > - considering the service continuity, the next serving DECADE server > should know the progress of the service, how does they know?or > different servers need to coordinate and schedule each other to fulfil= l the > user request? > > @you: > > > - that does not mean that there can't be additional protocol(s) (not > specified here) that are used between DECADE servers as well. and The > IAP in the problem statement is intended to describe data transfer bet= ween > DECADE servers. > > -> basically agree with you, a question reminds me that "IAP means in th= e > media layer=A3=BF and signalling or controlling layer protocol may be nee= ded to > solve the problem? and we can reuse the other protocol to fulfill the > storing status transfer. and we should consider to update the draft to ad= d > the permission requirement and retrieve the client status about getting a= nd > writing storage. > I'm not sure I quite understand this, but it sounds like a proposal to add some sort of shared state explicitly to the protocol. In other words, to allow a request to be received by one server and processed by another or something similar. I have no problem with someone implementing this, but explicitly adding it to the protocol will complicate this incredibly. If someone wants to be a distributed version of a DECADE server (service?) that is great, but, it is up to the application developer to handle that in the background, transparently to the user. I also don't really like the idea of different servers being involved in one transaction, from a security perspective. I want to send a request and get a response from that same "server". Now if you want to use signed certificates and some fancy process in the back wher= e it appears the response came from a different server, I'm ok with that, but I firmly think to be able to finish on time we should treat the server as a single, client-server entity from a protocol perspective. BTW and on a slight tangent, there are lots of protocols that seem to be considering distributed backends (PPSP ruled it out of scope to make the problem simple enough to be solved as well, but there was a similar discussion). Perhaps some folks (in another mailing list of course) should look at the generic aspects required by these and other distributed servers and figure out if there is a need for a protocol framework to help enable that it... > > 2 Service Assurance > > -> basically agree with you, keep tracking the status of the DCADE server > may also bring the additional burden to the overloaded DECADE server. > I also think that publicly sharing load could be a security threat, althoug= h we might need to think about it. Redirection is great, and a busy server ca= n use it to shed load. Explicitly telling a client (with which the server may have no other relationship than this transaction) the load might let me kno= w that I shouldn't waste any more bots on a DoS attack on this server...already compromised and I can move on to DoS-ing a different one. Just seems like a bad idea. David > > 2011/3/3 Richard Alimi > > Hi Xiao, >> >> Sorry for the delay. Finally coming back to this. >> >> 2011/1/16 =D6=EC=E4=EC : >> > hi, Richard: >> > thanks for your reply:D >> > additional discussion see inline:D >> > 2011/1/14 Richard Alimi >> >> >> >> HI Xiao, >> >> >> >> 2011/1/12 =D6=EC=E4=EC : >> >> > hi, Richard >> >> > see inline:D >> >> > >> >> > 2011/1/11 Richard Alimi >> >> >> >> >> >> Hi Xiao, >> >> >> >> >> >> On Mon, Jan 10, 2011 at 6:45 PM, =D6=EC=E4=EC wrote: >> >> >> > >> >> >> > hi, Richard, sorry for so late response because of be busy with >> other >> >> >> > projects. >> >> >> > some discussion see inline:D marked by red. >> >> >> > >> >> >> > On Tue, Jan 4, 2011 at 4:06 AM, Richard Alimi > > >> >> >> > wrote: >> >> >> >> >> >> >> >> Hi Xiao, >> >> >> >> >> >> >> >> Thank you for the draft. Some comments on the requirements: >> >> >> >> >> >> >> >> Request Redirects: >> >> >> >> >> >> >> >> This would provide some additional freedom for the storage >> provider. >> >> >> >> I think it is reasonable since it doesn't necessitate additiona= l >> >> >> >> complexity for the DECADE server, but allows it if desired. >> However, >> >> >> >> note that it may complicate some of the other components of the >> >> >> >> design. In particular, if there is a per-user quota for storage= , >> is >> >> >> >> the user made aware of the quota at each in-network storage (if >> >> >> >> there >> >> >> >> is no shared storage between them)? Resource sharing policies >> may >> >> >> >> be >> >> >> >> impacted (e.g., if a bandwidth sharing weight of 1 may mean >> >> >> >> something >> >> >> >> different at DECADE server A than it does at DECADE server B). >> At >> >> >> >> this point it may be best to just note these so they are >> documented, >> >> >> >> but since the specification of the resource sharing policies ar= e >> >> >> >> still >> >> >> >> being contemplated for the basic case of a single server it may >> be >> >> >> >> premature to even try and solve them for the case supporting >> >> >> >> redirection. >> >> >> >> >> >> >> > actually, you mean two points, right? >> >> >> > 1. whether or not to be ware of the content at each in-network >> >> >> > storage >> >> >> > and of course resource sharing policies can be impact in the >> request >> >> >> > redirection. your suggestion"just to note these so they are >> >> >> > documented" will >> >> >> > be ok, or DECADE server list with some parameters will be return >> for >> >> >> > user to >> >> >> > select the appropriate DECADE server, which can avoid the >> different >> >> >> > weighted >> >> >> > of the same parameter in server decision. but the parameter used >> in >> >> >> > select >> >> >> > the best DECADE server will be known for DECADE servers, in whic= h >> >> >> > other >> >> >> > complexities will be added. anyway, all the solution are the >> >> >> > implementation >> >> >> > issue, which, i believe, does not impact the necessity of the >> >> >> > requirement. >> >> >> >> >> >> In general, I'd agree that the decision about where to redirect >> would >> >> >> be an implementation issue. >> >> >> >> >> >> > >> >> >> > 2. you mean "the resource sharing policies are still being >> considered >> >> >> > in >> >> >> > a single server", so it may be premature to support redirection. >> the >> >> >> > architecture and protocol will be badly impacted if the >> requirements >> >> >> > change. >> >> >> > so the designing can be taken step by step, but the requiremen= ts >> >> >> > should be >> >> >> > overall considered. >> >> >> >> >> >> I said that it is probably premature to consider how resource >> sharing >> >> >> policies works across servers (or even if we need to say anything >> >> >> about it) since we have not determined how to specify them (or >> rather, >> >> >> how little we need to specify in protocol) for a single server. I >> did >> >> >> not mean to imply that redirection could not be introduced as a >> >> >> requirement. >> >> >> >> >> > >> >> >> >> >> >> > >> >> >> > >> >> >> >> >> >> >> >> Multi-connection: >> >> >> >> >> >> >> >> I'm not quite clear on the intention of the requirement. My >> >> >> >> understanding is that you wish the client to be able to have >> >> >> >> multiple >> >> >> >> connections open spanning multiple DECADE servers. Is that >> correct? >> >> >> >> >> >> >> >> If so, do we need this stated as a requirement or the protocol? >> Or >> >> >> >> is >> >> >> >> this a policy that would be allowed/disallowed by the storage >> >> >> >> provider? >> >> >> >> >> >> >> > yep, your understanding is right, the scenarios were just >> described >> >> >> > in >> >> >> > draft as "soft handover in wireless environment and delete >> operation >> >> >> > in >> >> >> > multi-servers". under these consideration, the authentication an= d >> >> >> > authorization need to be taken each time when setup connection >> with a >> >> >> > new >> >> >> > DECADE server, or just be taken only once during the service? >> >> >> >> >> >> The DECADE server should need to do some sort of check on each new >> >> >> connection, regardless of whether the user has or previously had a >> >> >> connection open to a different DECADE server, right? Note that th= e >> >> >> requirements don't indicate how authentication or authorization is >> >> >> done, and allow a server to make optimizations if it is enforcing >> the >> >> >> same permissions. >> >> >> >> >> >> Can you indicate where the existing authorization-related >> requirements >> >> >> (in particular, 4.1.6.3 of draft-ietf-decade-reqs-00) do not suffi= ce >> >> >> for the use case you are thinking of? >> >> >> >> > as considering the service continuity, the next serving DECADE >> server >> >> > should know the progress of the service, how does they know? >> >> >> >> By progress of the service, do you mean current user state (e.g., >> >> quota, recent resource usage history, permissions, etc)? >> >> > yes, and include data delivery proceeding. >> >> I still don't think I understand what you are suggesting as new >> requirements here. Why can't the client retry any failed requests? >> >> >> > so if the >> >> > service proceeding information should be known by the next serving >> >> > server, >> >> > or different servers need to coordinate and schedule each other to >> >> > fulfill >> >> > the user request, i believe the the 4.1.6.3 of the >> >> > draft-ietf-decade-req-00 >> >> > cannot satisfy the req. what do you think about? >> >> >> >> Note that the protocol that is covered here is the client-server >> >> protocol. Some of the same protocol may be useful between DECADE >> >> servers (especially in different administrative domains) for storing >> >> and retrieving data, but that does not mean that there can't be >> >> additional protocol(s) (not specified here) that are used between >> >> DECADE servers as well. For example, if DECADE servers within an >> >> administrative domain can certainly have their own mechanism to share >> >> such information. If such capabilities were included in the DECADE >> >> protocol (e.g., a need to do this between administrative domains), >> >> that sounds like lots more complexity that we need at this point. >> >> > but the access between in-network storage also is included in IAP >> > described in problem statement. i mean why not put this kind of >> function in >> > DECADE since the IAP is defined just like that? >> >> The IAP in the problem statement is intended to describe data transfer >> between DECADE servers. I think the discussion above relates to >> storing state about the progress of delivering data to DECADE clients. >> Is that an accurate summary? If so, then the point of DECADE is that >> this is managed and controlled by the clients. I don't think it makes >> sense to add additional state in to DECADE servers for this. >> >> >> That said, it sounds to me like what is described in 4.1.6.3 would be >> >> sufficient (from the perspective of the client-server protocol, >> >> anyways) to implement what you're describing. If not, what >> >> specifically is missing and what use-case does it not meet? >> >> > so you mean the information you mentioned above, just like current use= r >> > state (e.g., >> > quota, recent resource usage history, permissions, etc) was already >> > included in DECADE requirement? what about the data delivery proceedin= g >> > information? can you specify the chapter for me ? thanks? >> >> Historical information is not specified, but I can't think of another >> storage protocol off the top of my head that provides this. >> >> Quota/resource usage is in Section 5.1.6. Permissions, if applicable, >> should be there too (we will update the doc to state this). >> >> For data delivery, I see value in getting status about other client >> that may have open connections or active transfers (reads or writes) >> to one's storage. This could probably be added as a requirement. >> >> However, if the expectation is for DECADE servers to somehow >> coordinate (e.g., picking a data path, resuming/retrying failed >> transfers, etc), then this is going towards delay-tolerant networking >> or CDNs. DECADE is not intended for that. >> >> >> >> > >> >> >> > >> >> >> >> >> >> >> >> Data Distribution: >> >> >> >> >> >> >> >> I'm also confused about the intent of this requirement. This >> >> >> >> statement has me somewhat worried: "The distribution is >> transparent >> >> >> >> to >> >> >> >> the users as they interact with the in-network storage as a >> single >> >> >> >> logical system." Does this mean that you are proposing for DECA= DE >> >> >> >> servers to assume the responsibility for deciding how data is t= o >> be >> >> >> >> distributed throughout the network, including the path of the >> data, >> >> >> >> which servers act as intermediate caches, content expiration >> >> >> >> policies, >> >> >> >> etc? If this is true, I think it is missing one of the major >> points >> >> >> >> of DECADE. In particular, these decisions are >> application-dependent >> >> >> >> and are not implemented within DECADE. Instead, DECADE provides >> the >> >> >> >> basic capabilities and the functionality described above are >> >> >> >> implemented by the applications using DECADE. >> >> >> >> >> >> >> >> Or, am I misinterpreting the intent of the requirement? >> >> >> >> >> >> >> > you mean DECADE provides the basic capabilities, so can you give >> some >> >> >> > specify explanations on DECADE capabilities in supporting data >> >> >> > distribution? >> >> >> >> >> >> >> >> >> >> The problem statement gives a couple of scenarios. The "Integratio= n >> >> >> Examples" presentation from IETF 79 also has more details of an >> >> >> on-going effort at Yale. >> >> >> >> > okay, thx for your information, i will lookup and refer, actually, >> the >> >> > content publisher described in problem statement remind me of the >> >> > protocol requirements which i did not find in >> draft-ietf-decade-reqs-00 >> >> > to >> >> > support content publish. or i miss some points? >> >> >> >> Which requirements do you think are missing? >> >> >> >> >> >> Service Assurance: >> >> >> >> >> >> >> >> It seems problematic to include "assurance" in a DECADE. >> Shouldn't >> >> >> >> these instead be part of SLAs with a storage provider? Why >> should >> >> >> >> they be DECADE's responsibility? >> >> >> >> >> >> >> >> Regarding "resource reservation", are you referring to an actua= l >> >> >> >> reservation (which might be problematic -- see above) or do you >> mean >> >> >> >> that the resource share should able to be specified at the time >> the >> >> >> >> connection opens and be assumed to be the same for the duration >> of >> >> >> >> the >> >> >> >> connection? >> >> >> >> >> >> >> >> Regarding Dynamic Feedback, is this orthogonal to the storage >> >> >> >> protocol? It seems like what you want here is a generic "statu= s" >> >> >> >> service saying how loaded a server is? >> >> >> >> >> >> >> > thats right, actually, the flow control mechanism was under >> >> >> > discussion >> >> >> > in writing the draft at first. what about your opinion in this >> >> >> > requirements? >> >> >> > >> >> >> >> >> >> I'm not sure what the typical way of providing such "load status" >> >> >> information for IETF protocols, but my inclination is that it shou= ld >> >> >> not be in the DECADE protocol itself. Maybe someone else with a >> >> >> longer history in IETF could jump in here :) >> >> > so can i understand that "load status" is kind of necessity >> information >> >> > for DECADE Server, but where and who collects the information are >> >> > remain discussion? >> >> >> >> The storage provider is free to collect the information wherever and >> >> however they wish. The DECADE server implementation could additional >> >> export whatever status information it wishes. I don't think the DECAD= E >> >> protocol needs to be concerned with that. >> >> >> >> Note that certain error conditions (e.g., overload, insufficient >> >> resources) may be signaled by a DECADE server (there are already have >> >> requirements for those). If you are referring to status for a user's >> >> resources, there is already a requirement for that too. >> >> >> >> I'm just not convinced that the DECADE protocol needs to export its >> >> current load status to clients. >> >> > actually i am not sure which elements in DECADE needs the load >> > status,(DECADE client or network storage if the network storage needs = to >> > redirect the request or both?). >> > And the requirement draft currently seems describe the overload >> condition >> > as the event triggering. do you think if it is necessary to >> periodically >> > reporting of the DECADE network status to client for its network stora= ge >> > selection? >> >> No I don't think this is necessary. The client can retry the request >> at a later time (e.g., exponential backoff). Note that asking a >> heavily-loaded DECADE server to also keep track of clients that need >> to be notified, and keep them updated of the current status, is >> probably counter-productive. >> >> > and the requirement draft just describe DECADE which is busy to serve >> > other requests must be able to reject requests, not consider how to >> handle >> > the user request after being rejected? >> >> That's the implementation's decision. I suspect most would drop it on th= e >> floor. >> >> >> >> >> >> >> >> >> Data classification: >> >> >> >> >> >> >> >> Would it be better to instead have the client specify propertie= s >> of >> >> >> >> the content instead of place it into ? See >> >> >> >> www.ietf.org/proceedings/78/slides/nfsv4-0.pdf for an example o= f >> >> >> >> this >> >> >> >> approach for NFS. >> >> >> >> >> >> >> >> I think a problem with classifying applications is that it >> assumes >> >> >> >> that applications fit one of the supplied classifications. What >> if >> >> >> >> it >> >> >> >> may fit multiple classifications? or none? Another problem is = it >> >> >> >> assumes that servers assume based on indirect and assumed >> >> >> >> information >> >> >> >> that they know what to do with a particular piece of content. W= hy >> >> >> >> not >> >> >> >> have an application specify its desires directly? >> >> >> >> >> >> >> > >> >> >> > >> >> >> >> >> >> >> >> Small Objects: >> >> >> >> >> >> >> >> What is the new requirement here? Why is the existing >> requirement >> >> >> >> in >> >> >> >> draft-ietf-decade-reqs-00 insufficient? >> >> >> >> >> >> >> >> This also has me a bit worried: >> >> >> >> "And the in-network storage has the limited storage capacity, >> with >> >> >> >> the >> >> >> >> arrival of user requests and data distribution requirements, th= e >> >> >> >> data >> >> >> >> stored in the in-network storage will be replaced if the storag= e >> >> >> >> reaches the limit and data arrivals continually." >> >> >> >> >> >> >> >> How does the server know what the proper replacement strategy i= s >> for >> >> >> >> an application? I think DECADE's philosophy is that application= s >> >> >> >> should decide this. A simple way to do this is explicit deletio= n >> by >> >> >> >> an >> >> >> >> application, but perhaps a more efficient (yet more complex) >> >> >> >> solution >> >> >> >> is for an application to specify the replacement policy to the >> >> >> >> server. >> >> >> >> >> >> >> > actually, the key in "the data classification and small objects = " >> is >> >> >> > whether does it or not in P2P application? i did not find data >> >> >> > classification was adopted in P2P application so far, let alone >> >> >> > DECADE need >> >> >> > to classify the data used in all kinds of application. >> >> >> > >> >> >> >> >> >> So, do you agree that it is problematic to try and classify each >> type >> >> >> of application and try to specify the typical workload for each >> class? >> >> >> >> >> >> My point was that I don't think its necessary to do the >> classification >> >> >> at all. It is more extensible (and directly useful) for a server = to >> >> >> just give it direct hints about what would be preferable. >> >> > >> >> > yep, i believe it may be a little difficult, but worthy doing. >> specially >> >> > for improving the resource utilization within a single server and >> >> > reducing >> >> > the response time for client. what about others opinion? >> >> >> >> Can you justify why giving classifications (e.g., "I'm a live >> >> streaming application") would be better than giving specific hints >> >> (e.g., "please don't bother persistent these objects to disk")? >> > >> > i mean data in different kind of operation mode and attribute should >> have >> > different user patterns and storage rules, which may be help to improv= e >> the >> > resource utilization and reduce the response time for request, what ar= e >> you >> > understanding? >> >> That's fine. Explicit and more-specific hints are a different way to >> accomplish the same thing, and seem to be a much better design to me. >> They are simpler from an extensibility and implementation point of >> view. >> >> >> > >> >> >> >> >> Removal of Expired Records: >> >> >> >> >> >> >> >> "However, the two scenarios did not mention how to handle the o= ld >> >> >> >> resource if the user distributes the new resource which is an >> >> >> >> updated >> >> >> >> copy of the old resource." >> >> >> >> >> >> >> >> Why does this need to be handled in the requirements? Are you >> >> >> >> trying >> >> >> >> to draw the distinction between immediate deletion of content a= nd >> >> >> >> lazy >> >> >> >> deletion? >> >> >> >> >> >> >> > i mean the meaning of delete operation and how to handle the >> expired >> >> >> > records need to be clarify in requirements. >> >> >> >> >> >> My inclination is that "deleted" means that other requests the >> object >> >> >> of the same name should result an error, until another object with >> the >> >> >> same name is stored. >> >> > >> >> > okay, under the scenario "client uploads the new version, and did n= ot >> >> > specify how to handle the old version", did DECADE server delete th= e >> >> > older >> >> > version (or just label it unavailable, anyway, it is implementation >> >> > issue ) >> >> > or not ? in another word, just replace the older version with the n= ew >> >> > version with the same name? >> >> >> >> In this case, I would think the "write" of the new object should be >> >> rejected, or if desired, we could have an overwrite option. This >> >> could be added to the requirements if it helps to clarify. >> >> yep, no matter which solution is chosen, let the understanding >> >> unanimously:D >> >> > how to handle the older version which is >> >> > transferring from server to client? >> >> >> >> I think it would be cleaner to ask the server to continue sending an >> >> object once it has been started, but ultimately this would be the >> >> decision of the server's implementation I think. Maybe a "SHOULD" >> >> requirement. This could be added if desired. >> >> >> > Thank you for these questions. It helps design the requirements more >> > cleanly if there are specific scenarios in front of us :) >> > just discussion together:D and also thanks for your points to help me >> > understanding more! >> >> Thanks, >> Rich >> >> >> Rich >> >> >> >> >> I think that the time the data is removed from disk (or memory) >> should >> >> >> be up to the implementation. A storage provider might still have a= s >> >> >> part of some agreement that deleted data will be removed within X >> >> >> days/hours/minutes/whatever. >> >> > >> >> > agree with you. >> >> >> >> >> >> If people in the WG think it is necessary, we could have a >> requirement >> >> >> that says the protocol should support an argument indicating >> immediate >> >> >> deletion, but it is not clear that we need this. >> >> >> >> >> >> Rich >> >> >> >> >> >> >> >> >> >> >> Thanks! >> >> >> >> Rich >> >> >> >> >> >> >> >> >> >> >> >> On Mon, Dec 27, 2010 at 12:57 AM, =D6=EC=E4=EC >> wrote: >> >> >> >> > Dear all, >> >> >> >> > >> >> >> >> > There is a slightly updated version of the decade additional >> >> >> >> > requirements >> >> >> >> > draft. >> >> >> >> > >> >> >> >> > >> >> >> >> > >> https://datatracker.ietf.org/doc/draft-zhu-decade-additional-requirement= s/ >> >> >> >> > >> >> >> >> > Jin Peng, Yunfei Zhang and me are expecting to have a >> discussion >> >> >> >> > with >> >> >> >> > all of >> >> >> >> > you. >> >> >> >> > >> >> >> >> > Any comments are appreciated! >> >> >> >> > >> >> >> >> > A new version of I-D, >> >> >> >> > draft-zhu-decade-additional-requirements-00.txt >> >> >> >> > has been successfully submitted by Xiao Zhu and posted to the >> IETF >> >> >> >> > repository. >> >> >> >> > >> >> >> >> > Filename: draft-zhu-decade-additional-requirements >> >> >> >> > Revision: 00 >> >> >> >> > Title: Additional protocol requirements on >> DECADE >> >> >> >> > Creation_date: 2010-12-27 >> >> >> >> > WG ID: Independent Submission >> >> >> >> > Number_of_pages: 10 >> >> >> >> > >> >> >> >> > Abstract: >> >> >> >> > The DECoupled Application Data Enroute(DECADE)working group i= s >> >> >> >> > specifying standardized interfaces for accessing in-network >> >> >> >> > storage >> >> >> >> > from applications to store, retrieve and manage data. The mai= n >> >> >> >> > object >> >> >> >> > is to provide a framework that is useful to the applications, >> >> >> >> > including P2P applications and other data-oriented >> applications, >> >> >> >> > possibly related applications that can benefit from accessing >> in- >> >> >> >> > network storage. This memo focuses on some requirements such = as >> >> >> >> > request redirecting and so on which are on the central of >> >> >> >> > mobility, >> >> >> >> > wireless network environment and CDN application. We present >> these >> >> >> >> > in >> >> >> >> > this memo as additional requirements that should be considere= d >> for >> >> >> >> > the DECADE architecture and protocol specifications. >> >> >> >> > >> >> >> >> > >> >> >> >> > >> >> >> >> > The IETF Secretariat. >> >> >> >> > >> >> >> >> > -- >> >> >> >> > Best wishes, >> >> >> >> > >> >> >> >> > Beijing University of Posts & Telecommunications (BUPT) >> >> >> >> > Zhu Xiao ( =D6=EC=E4=EC ) >> >> >> >> > E-mail: buptxiaozhu@gmail.com >> >> >> >> > mobile:+86 134-8881-9004 >> >> >> >> > >> >> >> >> > _______________________________________________ >> >> >> >> > decade mailing list >> >> >> >> > decade@ietf.org >> >> >> >> > https://www.ietf.org/mailman/listinfo/decade >> >> >> >> > >> >> >> >> > >> >> >> > >> >> >> > >> >> >> > >> >> >> > -- >> >> >> > Best wishes, >> >> >> > >> >> >> > Beijing University of Posts & Telecommunications (BUPT) >> >> >> > Zhu Xiao ( =D6=EC=E4=EC ) >> >> >> > E-mail: buptxiaozhu@gmail.com >> >> >> > mobile:+86 134-8881-9004 >> >> > >> >> > >> >> > >> >> > -- >> >> > Best wishes, >> >> > >> >> > Beijing University of Posts & Telecommunications (BUPT) >> >> > Zhu Xiao ( =D6=EC=E4=EC ) >> >> > E-mail: buptxiaozhu@gmail.com >> >> > mobile:+86 134-8881-9004 >> >> > >> > >> > >> > >> > -- >> > Best wishes, >> > >> > Beijing University of Posts & Telecommunications (BUPT) >> > Zhu Xiao ( =D6=EC=E4=EC ) >> > E-mail: buptxiaozhu@gmail.com >> > mobile:+86 134-8881-9004 >> > >> > > > > -- > Best wishes, > > Beijing University of Posts & Telecommunications (BUPT) > Zhu Xiao ( =D6=EC=E4=EC ) > E-mail: buptxiaozhu@gmail.com > mobile:+86 134-8881-9004 > > _______________________________________________ > decade mailing list > decade@ietf.org > https://www.ietf.org/mailman/listinfo/decade > > --0015174c114213f42c049e118623 Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable Comments inline:

    2011/3/6 =D6=EC=E4=EC <buptxiaozhu@gm= ail.com>
    Hi, Richard:

    sorry for reply so late, because= i should remember what we are dissuasion and the key of the prob= lem


    so many quoted texts, let me make a = ;summarize.

    1 multi connection, i have the argumen= ts as followings:

    @me:

  • need it to process new authentication and authorization after the = user moves in the wireless environment and access a new DECADE se= rver
    • @you:
      <= li>DECADE server should need to do some sor= t of check on each new
       connection, regardless of whether the user has or previously had a connection open to a different DECADE server,
    =
    --> okay, agree with you, but we should specify in the r= equirements draft.

    @me:
    • considering the service continuity, the next serving &nbs= p;DECADE server
       should know the progress= of the service, how does they know?= or different servers need to coordinate and schedule each other to ful= fill the user request?
    @you:

    • that does = not mean that there can't be DECADE servers as well. and The IAP in the problem statement is intended to describe data = transfer between DECADE servers.
    -> basically agree with you,  a question reminds me= that "IAP means in the media layer=A3=BF and signalling or controllin= g layer protocol may be needed to solve the problem? and we can reuse the o= ther protocol to fulfill the storing status transfer. and we should conside= r to update the draft to add the permission requirement and retrieve&n= bsp;the client status about getting and writing storage. 

    I'm not sure I quite understand this, = but it sounds like a proposal to add some sort of shared state explicitly t= o the protocol. In other words, to allow a request to be received by one se= rver and processed by another or something similar.

    I have no problem with someone implementing this, but e= xplicitly adding it to the protocol will complicate this incredibly. If som= eone wants to be a distributed version of a DECADE server (service?) that i= s great, but, it is up to the application developer to handle that in the b= ackground, transparently to the user. I also don't really like the idea= of different servers being involved in one transaction, from a security pe= rspective. I want to send a request and get a response from that same "= ;server". Now if you want to use signed certificates and some fancy pr= ocess in the back where it appears the response came from a different serve= r, I'm ok with that, but I firmly think to be able to finish on time we= should treat the server as a single, client-server entity from a protocol = perspective.

    BTW and on a slight tangent, there are lots of protocol= s that seem to be considering distributed backends (PPSP ruled it out of sc= ope to make the problem simple enough to be solved as well, but there was a= similar discussion). Perhaps some folks (in another mailing list of course= ) should look at the generic aspects required by these and other distribute= d servers and figure out if there is a need for a protocol framework to hel= p enable that it...
     

    2 Service Assurance

    -> basically agree with you, keep tra= cking the status of the DCADE server may also bring the additional&nbs= p;burden to the overloaded DECADE server.

    I also think that publicly sharing load co= uld be a security threat, although we might need to think about it. Redirec= tion is great, and a busy server can use it to shed load. Explicitly tellin= g a client (with which the server may have no other relationship than this = transaction) the load might let me know that I shouldn't waste any more= bots on a DoS attack on this server...already compromised and I can move o= n to DoS-ing a different one. Just seems like a bad idea.

    David

     

    2011/3/3 Richard Alimi <rich@velvetse= a.net>

    Hi Xiao,

    Sorry for the delay. Finally coming back to this.

    2011/1/16 =D6=EC=E4=EC <buptxiaozhu@gmail.com>:
    > hi, Richard:
    > thanks for your reply:D
    > additional discussion see inline:D
    > 2011/1/14 Richard Alimi <rich@velvetsea.net>
    >>
    >> HI Xiao,
    >>
    >> 2011/1/12 =D6=EC=E4=EC <buptxiaozhu@gmail.com>:
    >> > hi, Richard
    >> > see inline:D
    >> >
    >> > 2011/1/11 Richard Alimi <rich@velvetsea.net>
    >> >>
    >> >> Hi Xiao,
    >> >>
    >> >> On Mon, Jan 10, 2011 at 6:45 PM, =D6=EC=E4=EC <buptxiaozhu@gmail.com> wrote:
    >> >> >
    >> >> > hi, Richard, sorry for so late response because of b= e busy with other
    >> >> > projects.
    >> >> > some discussion see inline:D marked by red.
    >> >> >
    >> >> > On Tue, Jan 4, 2011 at 4:06 AM, Richard Alimi <rich@velvetsea.net>
    >> >> > wrote:
    >> >> >>
    >> >> >> Hi Xiao,
    >> >> >>
    >> >> >> Thank you for the draft.  Some comments on = the requirements:
    >> >> >>
    >> >> >> Request Redirects:
    >> >> >>
    >> >> >> This would provide some additional freedom for t= he storage provider.
    >> >> >> I think it is reasonable since it doesn't ne= cessitate additional
    >> >> >> complexity for the DECADE server, but allows it = if desired. However,
    >> >> >> note that it may complicate some of the other co= mponents of the
    >> >> >> design. In particular, if there is a per-user qu= ota for storage, is
    >> >> >> the user made aware of the quota at each in-netw= ork storage (if
    >> >> >> there
    >> >> >> is no shared storage between them)?  Resour= ce sharing policies may
    >> >> >> be
    >> >> >> impacted (e.g., if a bandwidth sharing weight of= 1 may mean
    >> >> >> something
    >> >> >> different at DECADE server A than it does at DEC= ADE server B).  At
    >> >> >> this point it may be best to just note these so = they are documented,
    >> >> >> but since the specification of the resource shar= ing policies are
    >> >> >> still
    >> >> >> being contemplated for the basic case of a singl= e server it may be
    >> >> >> premature to even try and solve them for the cas= e supporting
    >> >> >> redirection.
    >> >> >>
    >> >> > actually, you mean two points, right?
    >> >> > 1. whether or not to be ware of the content at each = in-network
    >> >> > storage
    >> >> > and of course resource sharing policies can be impac= t in the request
    >> >> > redirection. your suggestion"just to note these= so they are
    >> >> > documented" will
    >> >> > be ok, or DECADE server list with some parameters wi= ll be return for
    >> >> > user to
    >> >> > select the appropriate DECADE server, which can avoi= d the different
    >> >> > weighted
    >> >> > of the same parameter in server decision. but the pa= rameter used in
    >> >> > select
    >> >> > the best DECADE server will be known for DECADE serv= ers, in which
    >> >> > other
    >> >> > complexities will be added. anyway, all the solution= are the
    >> >> > implementation
    >> >> > issue, which, i believe, does not impact the necessi= ty of the
    >> >> > requirement.
    >> >>
    >> >> In general, I'd agree that the decision about where t= o redirect would
    >> >> be an implementation issue.
    >> >>
    >> >> >
    >> >> > 2. you mean "the resource sharing policies are = still being considered
    >> >> > in
    >> >> > a single server", so it may be premature to sup= port redirection.  the
    >> >> > architecture and protocol will be badly impacted if = the requirements
    >> >> > change.
    >> >> > so the designing can be  taken  step by st= ep, but the requirements
    >> >> > should be
    >> >> > overall considered.
    >> >>
    >> >> I said that it is probably premature to consider how reso= urce sharing
    >> >> policies works across servers (or even if we need to say = anything
    >> >> about it) since we have not determined how to specify the= m (or rather,
    >> >> how little we need to specify in protocol) for a single s= erver. I did
    >> >> not mean to imply that redirection could not be introduce= d as a
    >> >> requirement.
    >> >>
    >> >
    >> >>
    >> >> >
    >> >> >
    >> >> >>
    >> >> >> Multi-connection:
    >> >> >>
    >> >> >> I'm not quite clear on the intention of the = requirement.  My
    >> >> >> understanding is that you wish the client to be = able to have
    >> >> >> multiple
    >> >> >> connections open spanning multiple DECADE server= s. Is that correct?
    >> >> >>
    >> >> >> If so, do we need this stated as a requirement o= r the protocol? Or
    >> >> >> is
    >> >> >> this a policy that would be allowed/disallowed b= y the storage
    >> >> >> provider?
    >> >> >>
    >> >> > yep, your understanding is right, the scenarios were= just described
    >> >> > in
    >> >> > draft as "soft handover in wireless environment= and delete operation
    >> >> > in
    >> >> > multi-servers". under these consideration, the = authentication and
    >> >> > authorization need to be taken each time when setup = connection with a
    >> >> > new
    >> >> > DECADE server, or just be taken only once during &nb= sp;the service?
    >> >>
    >> >> The DECADE server should need to do some sort of check on= each new
    >> >> connection, regardless of whether the user has or previou= sly had a
    >> >> connection open to a different DECADE server, right? &nbs= p;Note that the
    >> >> requirements don't indicate how authentication or aut= horization is
    >> >> done, and allow a server to make optimizations if it is e= nforcing the
    >> >> same permissions.
    >> >>
    >> >> Can you indicate where the existing authorization-related= requirements
    >> >> (in particular, 4.1.6.3 of draft-ietf-decade-reqs-00) do = not suffice
    >> >> for the use case you are thinking of?
    >>
    >> > as considering the service continuity, the next serving  = ;DECADE server
    >> > should know the progress of the service, how does they know?<= br> >>
    >> By progress of the service, do you mean current user state (e.g.,<= br> >> quota, recent resource usage history, permissions, etc)?

    > yes, and include data delivery proceeding.

    I still don't think I understand what you are suggesting as= new
    requirements here.  Why can't the client retry any failed requests= ?

    >> > so if the
    >> > service proceeding information should be known by the next se= rving
    >> > server,
    >> > or different servers need to coordinate and schedule each oth= er to
    >> > fulfill
    >> > the user request, i believe the the 4.1.6.3 of the
    >> > draft-ietf-decade-req-00
    >> > cannot satisfy the req. what do you think about?
    >>
    >> Note that the protocol that is covered here is the client-server >> protocol. Some of the same protocol may be useful between DECADE >> servers (especially in different administrative domains) for stori= ng
    >> and retrieving data, but that does not mean that there can't b= e
    >> additional protocol(s) (not specified here) that are used between<= br> >> DECADE servers as well.  For example, if DECADE servers withi= n an
    >> administrative domain can certainly have their own mechanism to sh= are
    >> such information.  If such capabilities were included in the = DECADE
    >> protocol (e.g., a need to do this between administrative domains),=
    >> that sounds like lots more complexity that we need at this point.<= br>
    > but the access between in-network storage also is included in IAP
    > described in problem statement.  i mean why not put this kind of = function in
    > DECADE since the IAP is defined just like that?

    The IAP in the problem statement is intended to describe data transfe= r
    between DECADE servers.  I think the discussion above relates to
    storing state about the progress of delivering data to DECADE clients.
    Is that an accurate summary?  If so, then the point of DECADE is that<= br> this is managed and controlled by the clients.  I don't think it m= akes
    sense to add additional state in to DECADE servers for this.

    >> That said, it sounds to me like what is described in 4.1.6.3 would= be
    >> sufficient (from the perspective of the client-server protocol, >> anyways) to implement what you're describing. If not, what
    >> specifically is missing and what use-case does it not meet?

    > so you mean the information you mentioned above, just like current use= r
    > state (e.g.,
    > quota, recent resource usage history, permissions, etc) was already > included in DECADE requirement? what about the data delivery proceedin= g
    > information? can you specify the chapter for me ? thanks?

    Historical information is not specified, but I can't think of ano= ther
    storage protocol off the top of my head that provides this.

    Quota/resource usage is in Section 5.1.6. Permissions, if applicable,
    should be there too (we will update the doc to state this).

    For data delivery, I see value in getting status about other client
    that may have open connections or active transfers (reads or writes)
    to one's storage. This could probably be added as a requirement.

    However, if the expectation is for DECADE servers to somehow
    coordinate (e.g., picking a data path, resuming/retrying failed
    transfers, etc), then this is going towards delay-tolerant networking
    or CDNs. DECADE is not intended for that.

    >> >> >
    >> >> >
    >> >> >>
    >> >> >> Data Distribution:
    >> >> >>
    >> >> >> I'm also confused about the intent of this r= equirement.  This
    >> >> >> statement has me somewhat worried: "The dis= tribution is transparent
    >> >> >> to
    >> >> >> the users as they interact with the in-network s= torage as a single
    >> >> >> logical system." Does this mean that you ar= e proposing for DECADE
    >> >> >> servers to assume the responsibility for decidin= g how data is to be
    >> >> >> distributed throughout the network, including th= e path of the data,
    >> >> >> which servers act as intermediate caches, conten= t expiration
    >> >> >> policies,
    >> >> >> etc?  If this is true, I think it is missin= g one of the major points
    >> >> >> of DECADE. In particular, these decisions are ap= plication-dependent
    >> >> >> and are not implemented within DECADE. Instead, = DECADE provides the
    >> >> >> basic capabilities and the functionality describ= ed above are
    >> >> >> implemented by the applications using DECADE. >> >> >>
    >> >> >> Or, am I misinterpreting the intent of the requi= rement?
    >> >> >>
    >> >> > you mean DECADE provides the basic capabilities, so = can you give some
    >> >> > specify explanations on DECADE capabilities in suppo= rting data
    >> >> > distribution?
    >> >> >>
    >> >>
    >> >> The problem statement gives a couple of scenarios. The &q= uot;Integration
    >> >> Examples" presentation from IETF 79 also has more de= tails of an
    >> >> on-going effort at Yale.
    >>
    >> > okay, thx for your information, i will lookup and refer, actu= ally, the
    >> > content publisher described in problem statement remind me of=  the
    >> > protocol requirements which i did not find in draft-ietf-deca= de-reqs-00
    >> > to
    >> > support content publish. or i miss some points?
    >>
    >> Which requirements do you think are missing?
    >>
    >> >> >> Service Assurance:
    >> >> >>
    >> >> >> It seems problematic to include "assurance&= quot; in a DECADE.  Shouldn't
    >> >> >> these instead be part of SLAs with a storage pro= vider?  Why should
    >> >> >> they be DECADE's responsibility?
    >> >> >>
    >> >> >> Regarding "resource reservation", are = you referring to an actual
    >> >> >> reservation (which might be problematic -- see a= bove) or do you mean
    >> >> >> that the resource share should able to be specif= ied at the time the
    >> >> >> connection opens and be assumed to be the same f= or the duration of
    >> >> >> the
    >> >> >> connection?
    >> >> >>
    >> >> >> Regarding Dynamic Feedback, is this orthogonal t= o the storage
    >> >> >> protocol?  It seems like what you want here= is a generic "status"
    >> >> >> service saying how loaded a server is?
    >> >> >>
    >> >> > thats right, actually, the flow control mechanism wa= s under
    >> >> > discussion
    >> >> > in writing the draft at first. what about your opini= on in this
    >> >> > requirements?
    >> >> >
    >> >>
    >> >> I'm not sure what the typical way of providing such &= quot;load status"
    >> >> information for IETF protocols, but my inclination is tha= t it should
    >> >> not be in the DECADE protocol itself.  Maybe someone= else with a
    >> >> longer history in IETF could jump in here :)
    >> > so can i understand that "load status" is kind of n= ecessity  information
    >> > for DECADE Server, but where and who collects the information= are
    >> > remain discussion?
    >>
    >> The storage provider is free to collect the information wherever a= nd
    >> however they wish.  The DECADE server implementation could ad= ditional
    >> export whatever status information it wishes. I don't think th= e DECADE
    >> protocol needs to be concerned with that.
    >>
    >> Note that certain error conditions (e.g., overload, insufficient >> resources) may be signaled by a DECADE server (there are already h= ave
    >> requirements for those).  If you are referring to status for = a user's
    >> resources, there is already a requirement for that too.
    >>
    >> I'm just not convinced that the DECADE protocol needs to expor= t its
    >> current load status to clients.

    > actually i am not sure which elements in DECADE needs the load
    > status,(DECADE client or network storage if the network storage needs = to
    > redirect the request or both?).
    > And the requirement draft currently seems describe the overload condit= ion
    > as the event triggering.  do you think if it is necessary to peri= odically
    > reporting of the DECADE network status to client for its network stora= ge
    > selection?

    No I don't think this is necessary.  The client can re= try the request
    at a later time (e.g., exponential backoff).  Note that asking a
    heavily-loaded DECADE server to also keep track of clients that need
    to be notified, and keep them updated of the current status, is
    probably counter-productive.

    > and the requirement draft just describe DECADE which is busy to serve<= br> > other requests must be able to reject requests, not consider how to ha= ndle
    > the user request after being rejected?

    That's the implementation's decision. I suspect most would dr= op it on the floor.

    >> >> >>
    >> >> >> Data classification:
    >> >> >>
    >> >> >> Would it be better to instead have the client sp= ecify properties of
    >> >> >> the content instead of place it into ? See
    >> >> >>     www.ietf.org/proceedings/78/slides/nfsv= 4-0.pdf for an example of
    >> >> >> this
    >> >> >> approach for NFS.
    >> >> >>
    >> >> >> I think a problem with classifying applications = is that it assumes
    >> >> >> that applications fit one of the supplied classi= fications. What if
    >> >> >> it
    >> >> >> may fit multiple classifications? or none?  = ;Another problem is it
    >> >> >> assumes that servers assume based on indirect an= d assumed
    >> >> >> information
    >> >> >> that they know what to do with a particular piec= e of content. Why
    >> >> >> not
    >> >> >> have an application specify its desires directly= ?
    >> >> >>
    >> >> >
    >> >> >
    >> >> >>
    >> >> >> Small Objects:
    >> >> >>
    >> >> >> What is the new requirement here?  Why is t= he existing requirement
    >> >> >> in
    >> >> >> draft-ietf-decade-reqs-00 insufficient?
    >> >> >>
    >> >> >> This also has me a bit worried:
    >> >> >> "And the in-network storage has the limited= storage capacity, with
    >> >> >> the
    >> >> >> arrival of user requests and data distribution r= equirements, the
    >> >> >> data
    >> >> >> stored in the in-network storage will be replace= d if the storage
    >> >> >> reaches the limit and data arrivals continually.= "
    >> >> >>
    >> >> >> How does the server know what the proper replace= ment strategy is for
    >> >> >> an application? I think DECADE's philosophy = is that applications
    >> >> >> should decide this. A simple way to do this is e= xplicit deletion by
    >> >> >> an
    >> >> >> application, but perhaps a more efficient (yet m= ore complex)
    >> >> >> solution
    >> >> >> is for an application to specify the replacement= policy to the
    >> >> >> server.
    >> >> >>
    >> >> > actually, the key in "the data classification a= nd small objects " is
    >> >> > whether does it or not in P2P application? i did not= find data
    >> >> > classification was adopted in P2P application so far= , let alone
    >> >> > DECADE need
    >> >> > to classify the data used in all kinds of applicatio= n.
    >> >> >
    >> >>
    >> >> So, do you agree that it is problematic to try and classi= fy each type
    >> >> of application and try to specify the typical workload fo= r each class?
    >> >>
    >> >> My point was that I don't think its necessary to do t= he classification
    >> >> at all.  It is more extensible (and directly useful)= for a server to
    >> >> just give it direct hints about what would be preferable.=
    >> >
    >> > yep, i believe it may be a little difficult, but worthy doing= . specially
    >> > for improving the resource utilization within a single server= and
    >> > reducing
    >> > the response time for client. what about others opinion?
    >>
    >> Can you justify why giving classifications (e.g., "I'm a = live
    >> streaming application") would be better than giving specific = hints
    >> (e.g., "please don't bother persistent these objects to d= isk")?
    >
    > i mean data in different kind of operation mode and attribute should h= ave
    > different user patterns and storage rules, which may be help to improv= e the
    > resource utilization and reduce the response time for request, what ar= e you
    > understanding?

    That's fine. Explicit and more-specific hints are a differe= nt way to
    accomplish the same thing, and seem to be a much better design to me.
    They are simpler from an extensibility and implementation point of
    view.

    >> > >>
    >> >> >> Removal of Expired Records:
    >> >> >>
    >> >> >> "However, the two scenarios did not mention= how to handle the old
    >> >> >> resource if the user distributes the new resourc= e which is an
    >> >> >> updated
    >> >> >> copy of the old resource."
    >> >> >>
    >> >> >> Why does this need to be handled in the requirem= ents?  Are you
    >> >> >> trying
    >> >> >> to draw the distinction between immediate deleti= on of content and
    >> >> >> lazy
    >> >> >> deletion?
    >> >> >>
    >> >> > i mean the meaning of delete operation and how to ha= ndle the expired
    >> >> > records need to be clarify in requirements.
    >> >>
    >> >> My inclination is that "deleted" means that oth= er requests the object
    >> >> of the same name should result an error, until another ob= ject with the
    >> >> same name is stored.
    >> >
    >> > okay, under the scenario "client uploads the new version= , and did not
    >> > specify how to handle the old version", did DECADE serve= r delete the
    >> > older
    >> > version (or just label it unavailable, anyway, it is implemen= tation
    >> > issue )
    >> > or not ? in another word, just replace the older version with= the new
    >> > version with the same name?
    >>
    >> In this case, I would think the "write" of the new objec= t should be
    >> rejected, or if desired, we could have an overwrite option.  = This
    >> could be added to the requirements if it helps to clarify.
    >> yep, no matter which solution is chosen, let the understanding
    >> unanimously:D
    >> > how to handle the older version which is
    >> > transferring from server to client?
    >>
    >> I think it would be cleaner to ask the server to continue sending = an
    >> object once it has been started, but ultimately this would be the<= br> >> decision of the server's implementation I think.  Maybe a= "SHOULD"
    >> requirement.  This could be added if desired.
    >>
    > Thank you for these questions.  It helps design the requirements = more
    > cleanly if there are specific scenarios in front of us :)
    > just discussion together:D and also thanks for your points to help me<= br> > understanding more!

    Thanks,
    Rich

    >> Rich
    >>
    >> >> I think that the time the data is removed from disk (or m= emory) should
    >> >> be up to the implementation. A storage provider might sti= ll have as
    >> >> part of some agreement that deleted data will be removed = within X
    >> >> days/hours/minutes/whatever.
    >> >
    >> >    agree with you.
    >> >>
    >> >> If people in the WG think it is necessary, we could have = a requirement
    >> >> that says the protocol should support an argument indicat= ing immediate
    >> >> deletion, but it is not clear that we need this.
    >> >>
    >> >> Rich
    >> >>
    >> >> >>
    >> >> >> Thanks!
    >> >> >> Rich
    >> >> >>
    >> >> >>
    >> >> >> On Mon, Dec 27, 2010 at 12:57 AM, =D6=EC=E4=EC &= lt;buptxiaozhu@g= mail.com> wrote:
    >> >> >> > Dear all,
    >> >> >> >
    >> >> >> > There is a slightly updated version of the = decade additional
    >> >> >> > requirements
    >> >> >> > draft.
    >> >> >> >
    >> >> >> >
    >> >> >> > https://datat= racker.ietf.org/doc/draft-zhu-decade-additional-requirements/
    >> >> >> >
    >> >> >> > Jin Peng, Yunfei Zhang and me are expecting= to have a discussion
    >> >> >> > with
    >> >> >> > all of
    >> >> >> > you.
    >> >> >> >
    >> >> >> > Any comments are appreciated!
    >> >> >> >
    >> >> >> > A new version of I-D,
    >> >> >> > draft-zhu-decade-additional-requirements-00= .txt
    >> >> >> > has been successfully submitted by Xiao Zhu= and posted to the IETF
    >> >> >> > repository.
    >> >> >> >
    >> >> >> > Filename:      draft-zhu-dec= ade-additional-requirements
    >> >> >> > Revision:      00
    >> >> >> > Title:           &= nbsp;     Additional protocol requirements on DECADE
    >> >> >> > Creation_date:         = 2010-12-27
    >> >> >> > WG ID:           &= nbsp;     Independent Submission
    >> >> >> > Number_of_pages: 10
    >> >> >> >
    >> >> >> > Abstract:
    >> >> >> > The DECoupled Application Data Enroute(DECA= DE)working group is
    >> >> >> > specifying standardized interfaces for acce= ssing in-network
    >> >> >> > storage
    >> >> >> > from applications to store, retrieve and ma= nage data. The main
    >> >> >> > object
    >> >> >> > is to provide a framework that is useful to= the applications,
    >> >> >> > including P2P applications and other data-o= riented applications,
    >> >> >> > possibly related applications that can bene= fit from accessing in-
    >> >> >> > network storage. This memo focuses on some = requirements such as
    >> >> >> > request redirecting and so on which are on = the central of
    >> >> >> > mobility,
    >> >> >> > wireless network environment and CDN applic= ation. We present these
    >> >> >> > in
    >> >> >> > this memo as additional requirements that s= hould be considered for
    >> >> >> > the DECADE architecture and protocol specif= ications.
    >> >> >> >
    >> >> >> >
    >> >> >> >
    >> >> >> > The IETF Secretariat.
    >> >> >> >
    >> >> >> > --
    >> >> >> > Best wishes,
    >> >> >> >
    >> >> >> > Beijing University of Posts & Telecommu= nications (BUPT)
    >> >> >> > Zhu Xiao  ( =D6=EC=E4=EC )
    >> >> >> > E-mail: buptxiaozhu@gmail.com
    >> >> >> > mobile:+86 134-8881-9004
    >> >> >> >
    >> >> >> > ___________________________________________= ____
    >> >> >> > decade mailing list
    >> >> >> > decade@ietf.org
    >> >> >> > https://www.ietf.org/mailman/listinfo/decad= e
    >> >> >> >
    >> >> >> >
    >> >> >
    >> >> >
    >> >> >
    >> >> > --
    >> >> > Best wishes,
    >> >> >
    >> >> > Beijing University of Posts & Telecommunications= (BUPT)
    >> >> > Zhu Xiao  ( =D6=EC=E4=EC )
    >> >> > E-mail: buptxiaozhu@gmail.com
    >> >> > mobile:+86 134-8881-9004
    >> >
    >> >
    >> >
    >> > --
    >> > Best wishes,
    >> >
    >> > Beijing University of Posts & Telecommunications (BUPT) >> > Zhu Xiao  ( =D6=EC=E4=EC )
    >> > E-mail: buptxiaozhu@gmail.com
    >> > mobile:+86 134-8881-9004
    >> >
    >
    >
    >
    > --
    > Best wishes,
    >
    > Beijing University of Posts & Telecommunications (BUPT)
    > Zhu Xiao  ( =D6=EC=E4=EC )
    > E-mail: bup= txiaozhu@gmail.com
    > mobile:+86 134-8881-9004
    >



    --
    Best wishes,

    Beijing University of Posts & Te= lecommunications (BUPT)
    Zhu Xiao  ( =D6=EC=E4=EC )
    E-mail: buptxiaozhu@gmail.com=
    mobile:+86 134-8881-9004

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


    --0015174c114213f42c049e118623-- From li.lichun1@zte.com.cn Fri Mar 11 01:47:07 2011 Return-Path: X-Original-To: decade@core3.amsl.com Delivered-To: decade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9501E3A6893 for ; Fri, 11 Mar 2011 01:47:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.787 X-Spam-Level: X-Spam-Status: No, score=-100.787 tagged_above=-999 required=5 tests=[AWL=1.051, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vub2RBM8XTHg for ; Fri, 11 Mar 2011 01:47:06 -0800 (PST) Received: from mx5.zte.com.cn (mx6.zte.com.cn [63.218.89.70]) by core3.amsl.com (Postfix) with ESMTP id 196BD3A6C10 for ; Fri, 11 Mar 2011 01:47:05 -0800 (PST) Received: from [10.34.0.130] by mx5.zte.com.cn with surfront esmtp id 35101047745636; Fri, 11 Mar 2011 17:45:43 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.16] with StormMail ESMTP id 8738.1047745636; Fri, 11 Mar 2011 17:38:41 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id p2B9mIeU096006 for ; Fri, 11 Mar 2011 17:48:18 +0800 (GMT-8) (envelope-from li.lichun1@zte.com.cn) To: DECADE@ietf.org MIME-Version: 1.0 X-KeepSent: C40CC6F4:47CF36F0-48257850:002CFBE0; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: li.lichun1@zte.com.cn Date: Fri, 11 Mar 2011 17:48:07 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-03-11 17:48:19, Serialize complete at 2011-03-11 17:48:19 Content-Type: multipart/alternative; boundary="=_alternative 0035EB2048257850_=" X-MAIL: mse01.zte.com.cn p2B9mIeU096006 Subject: [decade] How about modifying tracker to support DECADE? X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.9 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, 11 Mar 2011 09:47:07 -0000 This is a multipart message in MIME format. --=_alternative 0035EB2048257850_= Content-Type: text/plain; charset="US-ASCII" Hi all, It seems that this WG has not considered modifying tracker to support DECADE. I believe that modifying both tracker and peer can make better use of DECADE compared with modifying peer only. We have proposed two solutions and submitted a draft about extending PPSP to support DECADE (http://tools.ietf.org/html/draft-le-ppsp-decade-interoperation-00.txt ). The solutions also put some requirements on DECADE. I summarize our solutions as below. Comments are welcome. Solution 1 Each peer reports to tracker that whether it has DECADE server or not. Peer A queries peer list from tracker. The peer list indicates that each peer has DECADE server or not. The Peer A can request content from peers having DECADE servers with high priority. Solution 2 Tracker maintains DECADE information (DECADE list and the content availability information of each DECADE server). Peer A queries node list from tracker for downloading content. Tracker returns the list of peers and DECADE servers having requested content. Then Peer A can request content from other peer's or tracker's DECADE server. If the DECADE service is rent by peers, peers upload contents to DECADE servers and report the DECADE information to tracker. If the DECADE service is rent by tracker (i.e. P2P content sharing service provider), tracker instruct peers uploading contents to DECADE servers or DECADE servers downloading contents from peers. BR Lichun -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. --=_alternative 0035EB2048257850_= Content-Type: text/html; charset="US-ASCII"
    Hi all,
    It seems that this WG has not considered modifying tracker to support DECADE.
    I believe that modifying both tracker and peer can make better use of DECADE compared with modifying peer only.
    We have proposed two solutions and submitted a draft about extending PPSP to support DECADE (http://tools.ietf.org/html/draft-le-ppsp-decade-interoperation-00.txt
    ). The solutions also put some requirements on DECADE.
    I summarize our solutions as below. Comments are welcome.

    Solution 1
    Each peer reports to tracker that whether it has DECADE server or not. Peer A queries peer list from tracker.
    The peer list indicates that each peer has DECADE server or not. The Peer A can request content from peers having DECADE servers with high priority.

    Solution 2
    Tracker maintains DECADE information (DECADE list and the content availability information of each DECADE server). Peer A queries node list from tracker for downloading content. Tracker returns the list of peers and DECADE servers having requested content. Then Peer A can request content from other peer's or tracker's DECADE server.
    If the DECADE service is rent by peers, peers upload contents to DECADE servers and report the DECADE information to tracker.
    If the DECADE service is rent by tracker (i.e. P2P content sharing service provider), tracker instruct peers uploading contents to DECADE servers or DECADE servers downloading contents from peers.

    BR
    Lichun
    --------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
    --=_alternative 0035EB2048257850_=-- From richard.alimi@gmail.com Sat Mar 12 21:58:47 2011 Return-Path: X-Original-To: decade@core3.amsl.com Delivered-To: decade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E0E063A688F for ; Sat, 12 Mar 2011 21:58:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.313 X-Spam-Level: X-Spam-Status: No, score=0.313 tagged_above=-999 required=5 tests=[AWL=-1.481, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_42=0.6, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1, SARE_GIF_ATTACH=1.42] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H9Rbc7i8oqw9 for ; Sat, 12 Mar 2011 21:58:42 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id 5F6DB3A6860 for ; Sat, 12 Mar 2011 21:58:42 -0800 (PST) Received: by iyi12 with SMTP id 12so963731iyi.31 for ; Sat, 12 Mar 2011 22:00:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references :x-goomoji-body:date:x-google-sender-auth:message-id:subject:from:to :cc:content-type; bh=ezFDcndpKEhYHvPos28JOGoWX6bGHqggQ6YRSExGoHg=; b=RnnogSaZLuMWgjzmjh903/WNzccWqMDXgqHOdCh2zC4pXaeR3EzbJ5sEESW0/lpUBf LDGKOn/Hinve1Dth6WrCu+4IDsgujwDZ32Z1L0T83bVyEMPgmzxj7X+R29zFB7pS2sub citHsIWw6zfT7PBqqveKpSP8C5lWw/A4BmZQA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:x-goomoji-body:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=apr+N/s6aaNX+OiC6q9njrN9IeXt/+NF5fS6FyP5N9P7QO+GaYWQB/Y3Ud9K+xDLPi TmLfiBxk61/oL71AYI/KLT+z/g38VpRDkK0h5+jeJ0oPbmrdxGNG+az+JaoFkuvsBig4 jg3WYdN1uszDYsKQRRuw/5pU4E/fkYRYlybeI= MIME-Version: 1.0 Received: by 10.231.33.131 with SMTP id h3mt10978814ibd.74.1299996003784; Sat, 12 Mar 2011 22:00:03 -0800 (PST) Sender: richard.alimi@gmail.com Received: by 10.231.10.71 with HTTP; Sat, 12 Mar 2011 22:00:03 -0800 (PST) In-Reply-To: References: X-Goomoji-Body: true Date: Sat, 12 Mar 2011 22:00:03 -0800 X-Google-Sender-Auth: ETXQpw1EW8DhohXIL7VH87E3IPY Message-ID: From: Richard Alimi To: =?GB2312?B?1uzk7A==?= Content-Type: multipart/related; boundary=002215048937046a3a049e56e8ff Cc: decade@ietf.org Subject: Re: [decade] draft-zhu-decade-additional-requirements X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.9 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, 13 Mar 2011 05:58:47 -0000 --002215048937046a3a049e56e8ff Content-Type: multipart/alternative; boundary=002215048937046a33049e56e8fe --002215048937046a33049e56e8fe Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable 2011/3/6 =D6=EC=E4=EC > Hi, Richard: > > sorry for reply so late, because i should remember what we > are dissuasion and the key of the problem[?] > > > so many quoted texts, let me make a summarize. > > 1 multi connection, i have the arguments as followings: > > @me: > > > - need it to process new authentication and authorization after the > user moves in the wireless environment and access a new DECADE server > > @you: > > - DECADE server should need to do some sort of check on each new > connection, regardless of whether the user has or previously had a > connection open to a different DECADE server, > > --> okay, agree with you, but we should specify in the requirements draft= . > > Can you point out what, if anything, should be added to the existing requirement? The intent was to specify this, but note that the existing text does this at the request level instead of connections. The notion of when to drop an connection seems like an implementation detail to me. The existing text is here: http://tools.ietf.org/html/draft-ietf-decade-reqs-00#section-4.1.6.3 Thanks! Rich > @me: > > - considering the service continuity, the next serving DECADE server > should know the progress of the service, how does they know?or > different servers need to coordinate and schedule each other to fulfil= l the > user request? > > @you: > > > - that does not mean that there can't be additional protocol(s) (not > specified here) that are used between DECADE servers as well. and The > IAP in the problem statement is intended to describe data transfer bet= ween > DECADE servers. > > -> basically agree with you, a question reminds me that "IAP means in th= e > media layer=A3=BF and signalling or controlling layer protocol may be nee= ded to > solve the problem? and we can reuse the other protocol to fulfill the > storing status transfer. and we should consider to update the draft to ad= d > the permission requirement and retrieve the client status about getting a= nd > writing storage. > > 2 Service Assurance > > -> basically agree with you, keep tracking the status of the DCADE server > may also bring the additional burden to the overloaded DECADE server. > > 2011/3/3 Richard Alimi > >> Hi Xiao, >> >> Sorry for the delay. Finally coming back to this. >> >> 2011/1/16 =D6=EC=E4=EC : >> > hi, Richard: >> > thanks for your reply:D >> > additional discussion see inline:D >> > 2011/1/14 Richard Alimi >> >> >> >> HI Xiao, >> >> >> >> 2011/1/12 =D6=EC=E4=EC : >> >> > hi, Richard >> >> > see inline:D >> >> > >> >> > 2011/1/11 Richard Alimi >> >> >> >> >> >> Hi Xiao, >> >> >> >> >> >> On Mon, Jan 10, 2011 at 6:45 PM, =D6=EC=E4=EC wrote: >> >> >> > >> >> >> > hi, Richard, sorry for so late response because of be busy with >> other >> >> >> > projects. >> >> >> > some discussion see inline:D marked by red. >> >> >> > >> >> >> > On Tue, Jan 4, 2011 at 4:06 AM, Richard Alimi > > >> >> >> > wrote: >> >> >> >> >> >> >> >> Hi Xiao, >> >> >> >> >> >> >> >> Thank you for the draft. Some comments on the requirements: >> >> >> >> >> >> >> >> Request Redirects: >> >> >> >> >> >> >> >> This would provide some additional freedom for the storage >> provider. >> >> >> >> I think it is reasonable since it doesn't necessitate additiona= l >> >> >> >> complexity for the DECADE server, but allows it if desired. >> However, >> >> >> >> note that it may complicate some of the other components of the >> >> >> >> design. In particular, if there is a per-user quota for storage= , >> is >> >> >> >> the user made aware of the quota at each in-network storage (if >> >> >> >> there >> >> >> >> is no shared storage between them)? Resource sharing policies >> may >> >> >> >> be >> >> >> >> impacted (e.g., if a bandwidth sharing weight of 1 may mean >> >> >> >> something >> >> >> >> different at DECADE server A than it does at DECADE server B). >> At >> >> >> >> this point it may be best to just note these so they are >> documented, >> >> >> >> but since the specification of the resource sharing policies ar= e >> >> >> >> still >> >> >> >> being contemplated for the basic case of a single server it may >> be >> >> >> >> premature to even try and solve them for the case supporting >> >> >> >> redirection. >> >> >> >> >> >> >> > actually, you mean two points, right? >> >> >> > 1. whether or not to be ware of the content at each in-network >> >> >> > storage >> >> >> > and of course resource sharing policies can be impact in the >> request >> >> >> > redirection. your suggestion"just to note these so they are >> >> >> > documented" will >> >> >> > be ok, or DECADE server list with some parameters will be return >> for >> >> >> > user to >> >> >> > select the appropriate DECADE server, which can avoid the >> different >> >> >> > weighted >> >> >> > of the same parameter in server decision. but the parameter used >> in >> >> >> > select >> >> >> > the best DECADE server will be known for DECADE servers, in whic= h >> >> >> > other >> >> >> > complexities will be added. anyway, all the solution are the >> >> >> > implementation >> >> >> > issue, which, i believe, does not impact the necessity of the >> >> >> > requirement. >> >> >> >> >> >> In general, I'd agree that the decision about where to redirect >> would >> >> >> be an implementation issue. >> >> >> >> >> >> > >> >> >> > 2. you mean "the resource sharing policies are still being >> considered >> >> >> > in >> >> >> > a single server", so it may be premature to support redirection. >> the >> >> >> > architecture and protocol will be badly impacted if the >> requirements >> >> >> > change. >> >> >> > so the designing can be taken step by step, but the requiremen= ts >> >> >> > should be >> >> >> > overall considered. >> >> >> >> >> >> I said that it is probably premature to consider how resource >> sharing >> >> >> policies works across servers (or even if we need to say anything >> >> >> about it) since we have not determined how to specify them (or >> rather, >> >> >> how little we need to specify in protocol) for a single server. I >> did >> >> >> not mean to imply that redirection could not be introduced as a >> >> >> requirement. >> >> >> >> >> > >> >> >> >> >> >> > >> >> >> > >> >> >> >> >> >> >> >> Multi-connection: >> >> >> >> >> >> >> >> I'm not quite clear on the intention of the requirement. My >> >> >> >> understanding is that you wish the client to be able to have >> >> >> >> multiple >> >> >> >> connections open spanning multiple DECADE servers. Is that >> correct? >> >> >> >> >> >> >> >> If so, do we need this stated as a requirement or the protocol? >> Or >> >> >> >> is >> >> >> >> this a policy that would be allowed/disallowed by the storage >> >> >> >> provider? >> >> >> >> >> >> >> > yep, your understanding is right, the scenarios were just >> described >> >> >> > in >> >> >> > draft as "soft handover in wireless environment and delete >> operation >> >> >> > in >> >> >> > multi-servers". under these consideration, the authentication an= d >> >> >> > authorization need to be taken each time when setup connection >> with a >> >> >> > new >> >> >> > DECADE server, or just be taken only once during the service? >> >> >> >> >> >> The DECADE server should need to do some sort of check on each new >> >> >> connection, regardless of whether the user has or previously had a >> >> >> connection open to a different DECADE server, right? Note that th= e >> >> >> requirements don't indicate how authentication or authorization is >> >> >> done, and allow a server to make optimizations if it is enforcing >> the >> >> >> same permissions. >> >> >> >> >> >> Can you indicate where the existing authorization-related >> requirements >> >> >> (in particular, 4.1.6.3 of draft-ietf-decade-reqs-00) do not suffi= ce >> >> >> for the use case you are thinking of? >> >> >> >> > as considering the service continuity, the next serving DECADE >> server >> >> > should know the progress of the service, how does they know? >> >> >> >> By progress of the service, do you mean current user state (e.g., >> >> quota, recent resource usage history, permissions, etc)? >> >> > yes, and include data delivery proceeding. >> >> I still don't think I understand what you are suggesting as new >> requirements here. Why can't the client retry any failed requests? >> >> >> > so if the >> >> > service proceeding information should be known by the next serving >> >> > server, >> >> > or different servers need to coordinate and schedule each other to >> >> > fulfill >> >> > the user request, i believe the the 4.1.6.3 of the >> >> > draft-ietf-decade-req-00 >> >> > cannot satisfy the req. what do you think about? >> >> >> >> Note that the protocol that is covered here is the client-server >> >> protocol. Some of the same protocol may be useful between DECADE >> >> servers (especially in different administrative domains) for storing >> >> and retrieving data, but that does not mean that there can't be >> >> additional protocol(s) (not specified here) that are used between >> >> DECADE servers as well. For example, if DECADE servers within an >> >> administrative domain can certainly have their own mechanism to share >> >> such information. If such capabilities were included in the DECADE >> >> protocol (e.g., a need to do this between administrative domains), >> >> that sounds like lots more complexity that we need at this point. >> >> > but the access between in-network storage also is included in IAP >> > described in problem statement. i mean why not put this kind of >> function in >> > DECADE since the IAP is defined just like that? >> >> The IAP in the problem statement is intended to describe data transfer >> between DECADE servers. I think the discussion above relates to >> storing state about the progress of delivering data to DECADE clients. >> Is that an accurate summary? If so, then the point of DECADE is that >> this is managed and controlled by the clients. I don't think it makes >> sense to add additional state in to DECADE servers for this. >> >> >> That said, it sounds to me like what is described in 4.1.6.3 would be >> >> sufficient (from the perspective of the client-server protocol, >> >> anyways) to implement what you're describing. If not, what >> >> specifically is missing and what use-case does it not meet? >> >> > so you mean the information you mentioned above, just like current use= r >> > state (e.g., >> > quota, recent resource usage history, permissions, etc) was already >> > included in DECADE requirement? what about the data delivery proceedin= g >> > information? can you specify the chapter for me ? thanks? >> >> Historical information is not specified, but I can't think of another >> storage protocol off the top of my head that provides this. >> >> Quota/resource usage is in Section 5.1.6. Permissions, if applicable, >> should be there too (we will update the doc to state this). >> >> For data delivery, I see value in getting status about other client >> that may have open connections or active transfers (reads or writes) >> to one's storage. This could probably be added as a requirement. >> >> However, if the expectation is for DECADE servers to somehow >> coordinate (e.g., picking a data path, resuming/retrying failed >> transfers, etc), then this is going towards delay-tolerant networking >> or CDNs. DECADE is not intended for that. >> >> >> >> > >> >> >> > >> >> >> >> >> >> >> >> Data Distribution: >> >> >> >> >> >> >> >> I'm also confused about the intent of this requirement. This >> >> >> >> statement has me somewhat worried: "The distribution is >> transparent >> >> >> >> to >> >> >> >> the users as they interact with the in-network storage as a >> single >> >> >> >> logical system." Does this mean that you are proposing for DECA= DE >> >> >> >> servers to assume the responsibility for deciding how data is t= o >> be >> >> >> >> distributed throughout the network, including the path of the >> data, >> >> >> >> which servers act as intermediate caches, content expiration >> >> >> >> policies, >> >> >> >> etc? If this is true, I think it is missing one of the major >> points >> >> >> >> of DECADE. In particular, these decisions are >> application-dependent >> >> >> >> and are not implemented within DECADE. Instead, DECADE provides >> the >> >> >> >> basic capabilities and the functionality described above are >> >> >> >> implemented by the applications using DECADE. >> >> >> >> >> >> >> >> Or, am I misinterpreting the intent of the requirement? >> >> >> >> >> >> >> > you mean DECADE provides the basic capabilities, so can you give >> some >> >> >> > specify explanations on DECADE capabilities in supporting data >> >> >> > distribution? >> >> >> >> >> >> >> >> >> >> The problem statement gives a couple of scenarios. The "Integratio= n >> >> >> Examples" presentation from IETF 79 also has more details of an >> >> >> on-going effort at Yale. >> >> >> >> > okay, thx for your information, i will lookup and refer, actually, >> the >> >> > content publisher described in problem statement remind me of the >> >> > protocol requirements which i did not find in >> draft-ietf-decade-reqs-00 >> >> > to >> >> > support content publish. or i miss some points? >> >> >> >> Which requirements do you think are missing? >> >> >> >> >> >> Service Assurance: >> >> >> >> >> >> >> >> It seems problematic to include "assurance" in a DECADE. >> Shouldn't >> >> >> >> these instead be part of SLAs with a storage provider? Why >> should >> >> >> >> they be DECADE's responsibility? >> >> >> >> >> >> >> >> Regarding "resource reservation", are you referring to an actua= l >> >> >> >> reservation (which might be problematic -- see above) or do you >> mean >> >> >> >> that the resource share should able to be specified at the time >> the >> >> >> >> connection opens and be assumed to be the same for the duration >> of >> >> >> >> the >> >> >> >> connection? >> >> >> >> >> >> >> >> Regarding Dynamic Feedback, is this orthogonal to the storage >> >> >> >> protocol? It seems like what you want here is a generic "statu= s" >> >> >> >> service saying how loaded a server is? >> >> >> >> >> >> >> > thats right, actually, the flow control mechanism was under >> >> >> > discussion >> >> >> > in writing the draft at first. what about your opinion in this >> >> >> > requirements? >> >> >> > >> >> >> >> >> >> I'm not sure what the typical way of providing such "load status" >> >> >> information for IETF protocols, but my inclination is that it shou= ld >> >> >> not be in the DECADE protocol itself. Maybe someone else with a >> >> >> longer history in IETF could jump in here :) >> >> > so can i understand that "load status" is kind of necessity >> information >> >> > for DECADE Server, but where and who collects the information are >> >> > remain discussion? >> >> >> >> The storage provider is free to collect the information wherever and >> >> however they wish. The DECADE server implementation could additional >> >> export whatever status information it wishes. I don't think the DECAD= E >> >> protocol needs to be concerned with that. >> >> >> >> Note that certain error conditions (e.g., overload, insufficient >> >> resources) may be signaled by a DECADE server (there are already have >> >> requirements for those). If you are referring to status for a user's >> >> resources, there is already a requirement for that too. >> >> >> >> I'm just not convinced that the DECADE protocol needs to export its >> >> current load status to clients. >> >> > actually i am not sure which elements in DECADE needs the load >> > status,(DECADE client or network storage if the network storage needs = to >> > redirect the request or both?). >> > And the requirement draft currently seems describe the overload >> condition >> > as the event triggering. do you think if it is necessary to >> periodically >> > reporting of the DECADE network status to client for its network stora= ge >> > selection? >> >> No I don't think this is necessary. The client can retry the request >> at a later time (e.g., exponential backoff). Note that asking a >> heavily-loaded DECADE server to also keep track of clients that need >> to be notified, and keep them updated of the current status, is >> probably counter-productive. >> >> > and the requirement draft just describe DECADE which is busy to serve >> > other requests must be able to reject requests, not consider how to >> handle >> > the user request after being rejected? >> >> That's the implementation's decision. I suspect most would drop it on th= e >> floor. >> >> >> >> >> >> >> >> >> Data classification: >> >> >> >> >> >> >> >> Would it be better to instead have the client specify propertie= s >> of >> >> >> >> the content instead of place it into ? See >> >> >> >> www.ietf.org/proceedings/78/slides/nfsv4-0.pdf for an example o= f >> >> >> >> this >> >> >> >> approach for NFS. >> >> >> >> >> >> >> >> I think a problem with classifying applications is that it >> assumes >> >> >> >> that applications fit one of the supplied classifications. What >> if >> >> >> >> it >> >> >> >> may fit multiple classifications? or none? Another problem is = it >> >> >> >> assumes that servers assume based on indirect and assumed >> >> >> >> information >> >> >> >> that they know what to do with a particular piece of content. W= hy >> >> >> >> not >> >> >> >> have an application specify its desires directly? >> >> >> >> >> >> >> > >> >> >> > >> >> >> >> >> >> >> >> Small Objects: >> >> >> >> >> >> >> >> What is the new requirement here? Why is the existing >> requirement >> >> >> >> in >> >> >> >> draft-ietf-decade-reqs-00 insufficient? >> >> >> >> >> >> >> >> This also has me a bit worried: >> >> >> >> "And the in-network storage has the limited storage capacity, >> with >> >> >> >> the >> >> >> >> arrival of user requests and data distribution requirements, th= e >> >> >> >> data >> >> >> >> stored in the in-network storage will be replaced if the storag= e >> >> >> >> reaches the limit and data arrivals continually." >> >> >> >> >> >> >> >> How does the server know what the proper replacement strategy i= s >> for >> >> >> >> an application? I think DECADE's philosophy is that application= s >> >> >> >> should decide this. A simple way to do this is explicit deletio= n >> by >> >> >> >> an >> >> >> >> application, but perhaps a more efficient (yet more complex) >> >> >> >> solution >> >> >> >> is for an application to specify the replacement policy to the >> >> >> >> server. >> >> >> >> >> >> >> > actually, the key in "the data classification and small objects = " >> is >> >> >> > whether does it or not in P2P application? i did not find data >> >> >> > classification was adopted in P2P application so far, let alone >> >> >> > DECADE need >> >> >> > to classify the data used in all kinds of application. >> >> >> > >> >> >> >> >> >> So, do you agree that it is problematic to try and classify each >> type >> >> >> of application and try to specify the typical workload for each >> class? >> >> >> >> >> >> My point was that I don't think its necessary to do the >> classification >> >> >> at all. It is more extensible (and directly useful) for a server = to >> >> >> just give it direct hints about what would be preferable. >> >> > >> >> > yep, i believe it may be a little difficult, but worthy doing. >> specially >> >> > for improving the resource utilization within a single server and >> >> > reducing >> >> > the response time for client. what about others opinion? >> >> >> >> Can you justify why giving classifications (e.g., "I'm a live >> >> streaming application") would be better than giving specific hints >> >> (e.g., "please don't bother persistent these objects to disk")? >> > >> > i mean data in different kind of operation mode and attribute should >> have >> > different user patterns and storage rules, which may be help to improv= e >> the >> > resource utilization and reduce the response time for request, what ar= e >> you >> > understanding? >> >> That's fine. Explicit and more-specific hints are a different way to >> accomplish the same thing, and seem to be a much better design to me. >> They are simpler from an extensibility and implementation point of >> view. >> >> >> > >> >> >> >> >> Removal of Expired Records: >> >> >> >> >> >> >> >> "However, the two scenarios did not mention how to handle the o= ld >> >> >> >> resource if the user distributes the new resource which is an >> >> >> >> updated >> >> >> >> copy of the old resource." >> >> >> >> >> >> >> >> Why does this need to be handled in the requirements? Are you >> >> >> >> trying >> >> >> >> to draw the distinction between immediate deletion of content a= nd >> >> >> >> lazy >> >> >> >> deletion? >> >> >> >> >> >> >> > i mean the meaning of delete operation and how to handle the >> expired >> >> >> > records need to be clarify in requirements. >> >> >> >> >> >> My inclination is that "deleted" means that other requests the >> object >> >> >> of the same name should result an error, until another object with >> the >> >> >> same name is stored. >> >> > >> >> > okay, under the scenario "client uploads the new version, and did n= ot >> >> > specify how to handle the old version", did DECADE server delete th= e >> >> > older >> >> > version (or just label it unavailable, anyway, it is implementation >> >> > issue ) >> >> > or not ? in another word, just replace the older version with the n= ew >> >> > version with the same name? >> >> >> >> In this case, I would think the "write" of the new object should be >> >> rejected, or if desired, we could have an overwrite option. This >> >> could be added to the requirements if it helps to clarify. >> >> yep, no matter which solution is chosen, let the understanding >> >> unanimously:D >> >> > how to handle the older version which is >> >> > transferring from server to client? >> >> >> >> I think it would be cleaner to ask the server to continue sending an >> >> object once it has been started, but ultimately this would be the >> >> decision of the server's implementation I think. Maybe a "SHOULD" >> >> requirement. This could be added if desired. >> >> >> > Thank you for these questions. It helps design the requirements more >> > cleanly if there are specific scenarios in front of us :) >> > just discussion together:D and also thanks for your points to help me >> > understanding more! >> >> Thanks, >> Rich >> >> >> Rich >> >> >> >> >> I think that the time the data is removed from disk (or memory) >> should >> >> >> be up to the implementation. A storage provider might still have a= s >> >> >> part of some agreement that deleted data will be removed within X >> >> >> days/hours/minutes/whatever. >> >> > >> >> > agree with you. >> >> >> >> >> >> If people in the WG think it is necessary, we could have a >> requirement >> >> >> that says the protocol should support an argument indicating >> immediate >> >> >> deletion, but it is not clear that we need this. >> >> >> >> >> >> Rich >> >> >> >> >> >> >> >> >> >> >> Thanks! >> >> >> >> Rich >> >> >> >> >> >> >> >> >> >> >> >> On Mon, Dec 27, 2010 at 12:57 AM, =D6=EC=E4=EC >> wrote: >> >> >> >> > Dear all, >> >> >> >> > >> >> >> >> > There is a slightly updated version of the decade additional >> >> >> >> > requirements >> >> >> >> > draft. >> >> >> >> > >> >> >> >> > >> >> >> >> > >> https://datatracker.ietf.org/doc/draft-zhu-decade-additional-requirement= s/ >> >> >> >> > >> >> >> >> > Jin Peng, Yunfei Zhang and me are expecting to have a >> discussion >> >> >> >> > with >> >> >> >> > all of >> >> >> >> > you. >> >> >> >> > >> >> >> >> > Any comments are appreciated! >> >> >> >> > >> >> >> >> > A new version of I-D, >> >> >> >> > draft-zhu-decade-additional-requirements-00.txt >> >> >> >> > has been successfully submitted by Xiao Zhu and posted to the >> IETF >> >> >> >> > repository. >> >> >> >> > >> >> >> >> > Filename: draft-zhu-decade-additional-requirements >> >> >> >> > Revision: 00 >> >> >> >> > Title: Additional protocol requirements on >> DECADE >> >> >> >> > Creation_date: 2010-12-27 >> >> >> >> > WG ID: Independent Submission >> >> >> >> > Number_of_pages: 10 >> >> >> >> > >> >> >> >> > Abstract: >> >> >> >> > The DECoupled Application Data Enroute(DECADE)working group i= s >> >> >> >> > specifying standardized interfaces for accessing in-network >> >> >> >> > storage >> >> >> >> > from applications to store, retrieve and manage data. The mai= n >> >> >> >> > object >> >> >> >> > is to provide a framework that is useful to the applications, >> >> >> >> > including P2P applications and other data-oriented >> applications, >> >> >> >> > possibly related applications that can benefit from accessing >> in- >> >> >> >> > network storage. This memo focuses on some requirements such = as >> >> >> >> > request redirecting and so on which are on the central of >> >> >> >> > mobility, >> >> >> >> > wireless network environment and CDN application. We present >> these >> >> >> >> > in >> >> >> >> > this memo as additional requirements that should be considere= d >> for >> >> >> >> > the DECADE architecture and protocol specifications. >> >> >> >> > >> >> >> >> > >> >> >> >> > >> >> >> >> > The IETF Secretariat. >> >> >> >> > >> >> >> >> > -- >> >> >> >> > Best wishes, >> >> >> >> > >> >> >> >> > Beijing University of Posts & Telecommunications (BUPT) >> >> >> >> > Zhu Xiao ( =D6=EC=E4=EC ) >> >> >> >> > E-mail: buptxiaozhu@gmail.com >> >> >> >> > mobile:+86 134-8881-9004 >> >> >> >> > >> >> >> >> > _______________________________________________ >> >> >> >> > decade mailing list >> >> >> >> > decade@ietf.org >> >> >> >> > https://www.ietf.org/mailman/listinfo/decade >> >> >> >> > >> >> >> >> > >> >> >> > >> >> >> > >> >> >> > >> >> >> > -- >> >> >> > Best wishes, >> >> >> > >> >> >> > Beijing University of Posts & Telecommunications (BUPT) >> >> >> > Zhu Xiao ( =D6=EC=E4=EC ) >> >> >> > E-mail: buptxiaozhu@gmail.com >> >> >> > mobile:+86 134-8881-9004 >> >> > >> >> > >> >> > >> >> > -- >> >> > Best wishes, >> >> > >> >> > Beijing University of Posts & Telecommunications (BUPT) >> >> > Zhu Xiao ( =D6=EC=E4=EC ) >> >> > E-mail: buptxiaozhu@gmail.com >> >> > mobile:+86 134-8881-9004 >> >> > >> > >> > >> > >> > -- >> > Best wishes, >> > >> > Beijing University of Posts & Telecommunications (BUPT) >> > Zhu Xiao ( =D6=EC=E4=EC ) >> > E-mail: buptxiaozhu@gmail.com >> > mobile:+86 134-8881-9004 >> > >> > > > > -- > Best wishes, > > Beijing University of Posts & Telecommunications (BUPT) > Zhu Xiao ( =D6=EC=E4=EC ) > E-mail: buptxiaozhu@gmail.com > mobile:+86 134-8881-9004 > --002215048937046a33049e56e8fe Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable
    2011/3/6 =D6=EC=E4=EC <buptxiaozhu@gmail.com>
    Hi, Richard:

    sorry for reply so late, because= i should remember what we are dissuasion and the key of the prob= lem


    so many quoted texts, let me make a = ;summarize.

    1 multi connection, i have the argumen= ts as followings:

    @me:

  • need it to process new authentication and authorization after the = user moves in the wireless environment and access a new DECADE se= rver
    • @you:
      <= li>DECADE server should need to do some sor= t of check on each new
       connection, regardless of whether the user has or previously had a connection open to a different DECADE server,
    =
    --> okay, agree with you, but we should specify in the r= equirements draft.


    Can you point out what, if = anything, should be added to the existing requirement?  The intent was= to specify this, but note that the existing text does this at the request = level instead of connections.  The notion of when to drop an connectio= n seems like an implementation detail to me.

    The existing text is here:
      = http://tools.ietf.org/html/draft-ietf-decade-reqs-00#section-4.1.6.3

    Thanks!
    Rich
     
    @me:
    • considering the service continuity, the next serving  DE= CADE server
       should know the progress= of the service, how does they know?= or different servers need to coordinate and schedule each other to ful= fill the user request?
    @you:

    • that does = not mean that there can't be DECADE servers as well. and The IAP in the problem statement is intended to describe data = transfer between DECADE servers.
    -> basically agree with you,  a question reminds me= that "IAP means in the media layer=A3=BF and signalling or controllin= g layer protocol may be needed to solve the problem? and we can reuse the o= ther protocol to fulfill the storing status transfer. and we should conside= r to update the draft to add the permission requirement and retrieve&n= bsp;the client status about getting and writing storage. 

    2 Service Assurance

    -> basically agree with you, keep tra= cking the status of the DCADE server may also bring the additional&nbs= p;burden to the overloaded DECADE server.

    2011/= 3/3 Richard Alimi <rich@velvetsea.net>
    Hi Xiao,

    Sorry for the delay. Finally coming back to this.

    2011/1/16 =D6=EC=E4=EC <buptxiaozhu@gmail.com>:
    > hi, Richard:
    > thanks for your reply:D
    > additional discussion see inline:D
    > 2011/1/14 Richard Alimi <rich@velvetsea.net>
    >>
    >> HI Xiao,
    >>
    >> 2011/1/12 =D6=EC=E4=EC <buptxiaozhu@gmail.com>:
    >> > hi, Richard
    >> > see inline:D
    >> >
    >> > 2011/1/11 Richard Alimi <rich@velvetsea.net>
    >> >>
    >> >> Hi Xiao,
    >> >>
    >> >> On Mon, Jan 10, 2011 at 6:45 PM, =D6=EC=E4=EC <buptxiaozhu@gmail.com> wrote:
    >> >> >
    >> >> > hi, Richard, sorry for so late response because of b= e busy with other
    >> >> > projects.
    >> >> > some discussion see inline:D marked by red.
    >> >> >
    >> >> > On Tue, Jan 4, 2011 at 4:06 AM, Richard Alimi <rich@velvetsea.net>
    >> >> > wrote:
    >> >> >>
    >> >> >> Hi Xiao,
    >> >> >>
    >> >> >> Thank you for the draft.  Some comments on = the requirements:
    >> >> >>
    >> >> >> Request Redirects:
    >> >> >>
    >> >> >> This would provide some additional freedom for t= he storage provider.
    >> >> >> I think it is reasonable since it doesn't ne= cessitate additional
    >> >> >> complexity for the DECADE server, but allows it = if desired. However,
    >> >> >> note that it may complicate some of the other co= mponents of the
    >> >> >> design. In particular, if there is a per-user qu= ota for storage, is
    >> >> >> the user made aware of the quota at each in-netw= ork storage (if
    >> >> >> there
    >> >> >> is no shared storage between them)?  Resour= ce sharing policies may
    >> >> >> be
    >> >> >> impacted (e.g., if a bandwidth sharing weight of= 1 may mean
    >> >> >> something
    >> >> >> different at DECADE server A than it does at DEC= ADE server B).  At
    >> >> >> this point it may be best to just note these so = they are documented,
    >> >> >> but since the specification of the resource shar= ing policies are
    >> >> >> still
    >> >> >> being contemplated for the basic case of a singl= e server it may be
    >> >> >> premature to even try and solve them for the cas= e supporting
    >> >> >> redirection.
    >> >> >>
    >> >> > actually, you mean two points, right?
    >> >> > 1. whether or not to be ware of the content at each = in-network
    >> >> > storage
    >> >> > and of course resource sharing policies can be impac= t in the request
    >> >> > redirection. your suggestion"just to note these= so they are
    >> >> > documented" will
    >> >> > be ok, or DECADE server list with some parameters wi= ll be return for
    >> >> > user to
    >> >> > select the appropriate DECADE server, which can avoi= d the different
    >> >> > weighted
    >> >> > of the same parameter in server decision. but the pa= rameter used in
    >> >> > select
    >> >> > the best DECADE server will be known for DECADE serv= ers, in which
    >> >> > other
    >> >> > complexities will be added. anyway, all the solution= are the
    >> >> > implementation
    >> >> > issue, which, i believe, does not impact the necessi= ty of the
    >> >> > requirement.
    >> >>
    >> >> In general, I'd agree that the decision about where t= o redirect would
    >> >> be an implementation issue.
    >> >>
    >> >> >
    >> >> > 2. you mean "the resource sharing policies are = still being considered
    >> >> > in
    >> >> > a single server", so it may be premature to sup= port redirection.  the
    >> >> > architecture and protocol will be badly impacted if = the requirements
    >> >> > change.
    >> >> > so the designing can be  taken  step by st= ep, but the requirements
    >> >> > should be
    >> >> > overall considered.
    >> >>
    >> >> I said that it is probably premature to consider how reso= urce sharing
    >> >> policies works across servers (or even if we need to say = anything
    >> >> about it) since we have not determined how to specify the= m (or rather,
    >> >> how little we need to specify in protocol) for a single s= erver. I did
    >> >> not mean to imply that redirection could not be introduce= d as a
    >> >> requirement.
    >> >>
    >> >
    >> >>
    >> >> >
    >> >> >
    >> >> >>
    >> >> >> Multi-connection:
    >> >> >>
    >> >> >> I'm not quite clear on the intention of the = requirement.  My
    >> >> >> understanding is that you wish the client to be = able to have
    >> >> >> multiple
    >> >> >> connections open spanning multiple DECADE server= s. Is that correct?
    >> >> >>
    >> >> >> If so, do we need this stated as a requirement o= r the protocol? Or
    >> >> >> is
    >> >> >> this a policy that would be allowed/disallowed b= y the storage
    >> >> >> provider?
    >> >> >>
    >> >> > yep, your understanding is right, the scenarios were= just described
    >> >> > in
    >> >> > draft as "soft handover in wireless environment= and delete operation
    >> >> > in
    >> >> > multi-servers". under these consideration, the = authentication and
    >> >> > authorization need to be taken each time when setup = connection with a
    >> >> > new
    >> >> > DECADE server, or just be taken only once during &nb= sp;the service?
    >> >>
    >> >> The DECADE server should need to do some sort of check on= each new
    >> >> connection, regardless of whether the user has or previou= sly had a
    >> >> connection open to a different DECADE server, right? &nbs= p;Note that the
    >> >> requirements don't indicate how authentication or aut= horization is
    >> >> done, and allow a server to make optimizations if it is e= nforcing the
    >> >> same permissions.
    >> >>
    >> >> Can you indicate where the existing authorization-related= requirements
    >> >> (in particular, 4.1.6.3 of draft-ietf-decade-reqs-00) do = not suffice
    >> >> for the use case you are thinking of?
    >>
    >> > as considering the service continuity, the next serving  = ;DECADE server
    >> > should know the progress of the service, how does they know?<= br> >>
    >> By progress of the service, do you mean current user state (e.g.,<= br> >> quota, recent resource usage history, permissions, etc)?

    > yes, and include data delivery proceeding.

    I still don't think I understand what you are suggesting as= new
    requirements here.  Why can't the client retry any failed requests= ?

    >> > so if the
    >> > service proceeding information should be known by the next se= rving
    >> > server,
    >> > or different servers need to coordinate and schedule each oth= er to
    >> > fulfill
    >> > the user request, i believe the the 4.1.6.3 of the
    >> > draft-ietf-decade-req-00
    >> > cannot satisfy the req. what do you think about?
    >>
    >> Note that the protocol that is covered here is the client-server >> protocol. Some of the same protocol may be useful between DECADE >> servers (especially in different administrative domains) for stori= ng
    >> and retrieving data, but that does not mean that there can't b= e
    >> additional protocol(s) (not specified here) that are used between<= br> >> DECADE servers as well.  For example, if DECADE servers withi= n an
    >> administrative domain can certainly have their own mechanism to sh= are
    >> such information.  If such capabilities were included in the = DECADE
    >> protocol (e.g., a need to do this between administrative domains),=
    >> that sounds like lots more complexity that we need at this point.<= br>
    > but the access between in-network storage also is included in IAP
    > described in problem statement.  i mean why not put this kind of = function in
    > DECADE since the IAP is defined just like that?

    The IAP in the problem statement is intended to describe data transfe= r
    between DECADE servers.  I think the discussion above relates to
    storing state about the progress of delivering data to DECADE clients.
    Is that an accurate summary?  If so, then the point of DECADE is that<= br> this is managed and controlled by the clients.  I don't think it m= akes
    sense to add additional state in to DECADE servers for this.

    >> That said, it sounds to me like what is described in 4.1.6.3 would= be
    >> sufficient (from the perspective of the client-server protocol, >> anyways) to implement what you're describing. If not, what
    >> specifically is missing and what use-case does it not meet?

    > so you mean the information you mentioned above, just like current use= r
    > state (e.g.,
    > quota, recent resource usage history, permissions, etc) was already > included in DECADE requirement? what about the data delivery proceedin= g
    > information? can you specify the chapter for me ? thanks?

    Historical information is not specified, but I can't think of ano= ther
    storage protocol off the top of my head that provides this.

    Quota/resource usage is in Section 5.1.6. Permissions, if applicable,
    should be there too (we will update the doc to state this).

    For data delivery, I see value in getting status about other client
    that may have open connections or active transfers (reads or writes)
    to one's storage. This could probably be added as a requirement.

    However, if the expectation is for DECADE servers to somehow
    coordinate (e.g., picking a data path, resuming/retrying failed
    transfers, etc), then this is going towards delay-tolerant networking
    or CDNs. DECADE is not intended for that.

    >> >> >
    >> >> >
    >> >> >>
    >> >> >> Data Distribution:
    >> >> >>
    >> >> >> I'm also confused about the intent of this r= equirement.  This
    >> >> >> statement has me somewhat worried: "The dis= tribution is transparent
    >> >> >> to
    >> >> >> the users as they interact with the in-network s= torage as a single
    >> >> >> logical system." Does this mean that you ar= e proposing for DECADE
    >> >> >> servers to assume the responsibility for decidin= g how data is to be
    >> >> >> distributed throughout the network, including th= e path of the data,
    >> >> >> which servers act as intermediate caches, conten= t expiration
    >> >> >> policies,
    >> >> >> etc?  If this is true, I think it is missin= g one of the major points
    >> >> >> of DECADE. In particular, these decisions are ap= plication-dependent
    >> >> >> and are not implemented within DECADE. Instead, = DECADE provides the
    >> >> >> basic capabilities and the functionality describ= ed above are
    >> >> >> implemented by the applications using DECADE. >> >> >>
    >> >> >> Or, am I misinterpreting the intent of the requi= rement?
    >> >> >>
    >> >> > you mean DECADE provides the basic capabilities, so = can you give some
    >> >> > specify explanations on DECADE capabilities in suppo= rting data
    >> >> > distribution?
    >> >> >>
    >> >>
    >> >> The problem statement gives a couple of scenarios. The &q= uot;Integration
    >> >> Examples" presentation from IETF 79 also has more de= tails of an
    >> >> on-going effort at Yale.
    >>
    >> > okay, thx for your information, i will lookup and refer, actu= ally, the
    >> > content publisher described in problem statement remind me of=  the
    >> > protocol requirements which i did not find in draft-ietf-deca= de-reqs-00
    >> > to
    >> > support content publish. or i miss some points?
    >>
    >> Which requirements do you think are missing?
    >>
    >> >> >> Service Assurance:
    >> >> >>
    >> >> >> It seems problematic to include "assurance&= quot; in a DECADE.  Shouldn't
    >> >> >> these instead be part of SLAs with a storage pro= vider?  Why should
    >> >> >> they be DECADE's responsibility?
    >> >> >>
    >> >> >> Regarding "resource reservation", are = you referring to an actual
    >> >> >> reservation (which might be problematic -- see a= bove) or do you mean
    >> >> >> that the resource share should able to be specif= ied at the time the
    >> >> >> connection opens and be assumed to be the same f= or the duration of
    >> >> >> the
    >> >> >> connection?
    >> >> >>
    >> >> >> Regarding Dynamic Feedback, is this orthogonal t= o the storage
    >> >> >> protocol?  It seems like what you want here= is a generic "status"
    >> >> >> service saying how loaded a server is?
    >> >> >>
    >> >> > thats right, actually, the flow control mechanism wa= s under
    >> >> > discussion
    >> >> > in writing the draft at first. what about your opini= on in this
    >> >> > requirements?
    >> >> >
    >> >>
    >> >> I'm not sure what the typical way of providing such &= quot;load status"
    >> >> information for IETF protocols, but my inclination is tha= t it should
    >> >> not be in the DECADE protocol itself.  Maybe someone= else with a
    >> >> longer history in IETF could jump in here :)
    >> > so can i understand that "load status" is kind of n= ecessity  information
    >> > for DECADE Server, but where and who collects the information= are
    >> > remain discussion?
    >>
    >> The storage provider is free to collect the information wherever a= nd
    >> however they wish.  The DECADE server implementation could ad= ditional
    >> export whatever status information it wishes. I don't think th= e DECADE
    >> protocol needs to be concerned with that.
    >>
    >> Note that certain error conditions (e.g., overload, insufficient >> resources) may be signaled by a DECADE server (there are already h= ave
    >> requirements for those).  If you are referring to status for = a user's
    >> resources, there is already a requirement for that too.
    >>
    >> I'm just not convinced that the DECADE protocol needs to expor= t its
    >> current load status to clients.

    > actually i am not sure which elements in DECADE needs the load
    > status,(DECADE client or network storage if the network storage needs = to
    > redirect the request or both?).
    > And the requirement draft currently seems describe the overload condit= ion
    > as the event triggering.  do you think if it is necessary to peri= odically
    > reporting of the DECADE network status to client for its network stora= ge
    > selection?

    No I don't think this is necessary.  The client can re= try the request
    at a later time (e.g., exponential backoff).  Note that asking a
    heavily-loaded DECADE server to also keep track of clients that need
    to be notified, and keep them updated of the current status, is
    probably counter-productive.

    > and the requirement draft just describe DECADE which is busy to serve<= br> > other requests must be able to reject requests, not consider how to ha= ndle
    > the user request after being rejected?

    That's the implementation's decision. I suspect most would dr= op it on the floor.

    >> >> >>
    >> >> >> Data classification:
    >> >> >>
    >> >> >> Would it be better to instead have the client sp= ecify properties of
    >> >> >> the content instead of place it into ? See
    >> >> >>     www.ietf.org/proceedings/78/slides/nfsv= 4-0.pdf for an example of
    >> >> >> this
    >> >> >> approach for NFS.
    >> >> >>
    >> >> >> I think a problem with classifying applications = is that it assumes
    >> >> >> that applications fit one of the supplied classi= fications. What if
    >> >> >> it
    >> >> >> may fit multiple classifications? or none?  = ;Another problem is it
    >> >> >> assumes that servers assume based on indirect an= d assumed
    >> >> >> information
    >> >> >> that they know what to do with a particular piec= e of content. Why
    >> >> >> not
    >> >> >> have an application specify its desires directly= ?
    >> >> >>
    >> >> >
    >> >> >
    >> >> >>
    >> >> >> Small Objects:
    >> >> >>
    >> >> >> What is the new requirement here?  Why is t= he existing requirement
    >> >> >> in
    >> >> >> draft-ietf-decade-reqs-00 insufficient?
    >> >> >>
    >> >> >> This also has me a bit worried:
    >> >> >> "And the in-network storage has the limited= storage capacity, with
    >> >> >> the
    >> >> >> arrival of user requests and data distribution r= equirements, the
    >> >> >> data
    >> >> >> stored in the in-network storage will be replace= d if the storage
    >> >> >> reaches the limit and data arrivals continually.= "
    >> >> >>
    >> >> >> How does the server know what the proper replace= ment strategy is for
    >> >> >> an application? I think DECADE's philosophy = is that applications
    >> >> >> should decide this. A simple way to do this is e= xplicit deletion by
    >> >> >> an
    >> >> >> application, but perhaps a more efficient (yet m= ore complex)
    >> >> >> solution
    >> >> >> is for an application to specify the replacement= policy to the
    >> >> >> server.
    >> >> >>
    >> >> > actually, the key in "the data classification a= nd small objects " is
    >> >> > whether does it or not in P2P application? i did not= find data
    >> >> > classification was adopted in P2P application so far= , let alone
    >> >> > DECADE need
    >> >> > to classify the data used in all kinds of applicatio= n.
    >> >> >
    >> >>
    >> >> So, do you agree that it is problematic to try and classi= fy each type
    >> >> of application and try to specify the typical workload fo= r each class?
    >> >>
    >> >> My point was that I don't think its necessary to do t= he classification
    >> >> at all.  It is more extensible (and directly useful)= for a server to
    >> >> just give it direct hints about what would be preferable.=
    >> >
    >> > yep, i believe it may be a little difficult, but worthy doing= . specially
    >> > for improving the resource utilization within a single server= and
    >> > reducing
    >> > the response time for client. what about others opinion?
    >>
    >> Can you justify why giving classifications (e.g., "I'm a = live
    >> streaming application") would be better than giving specific = hints
    >> (e.g., "please don't bother persistent these objects to d= isk")?
    >
    > i mean data in different kind of operation mode and attribute should h= ave
    > different user patterns and storage rules, which may be help to improv= e the
    > resource utilization and reduce the response time for request, what ar= e you
    > understanding?

    That's fine. Explicit and more-specific hints are a differe= nt way to
    accomplish the same thing, and seem to be a much better design to me.
    They are simpler from an extensibility and implementation point of
    view.

    >> > >>
    >> >> >> Removal of Expired Records:
    >> >> >>
    >> >> >> "However, the two scenarios did not mention= how to handle the old
    >> >> >> resource if the user distributes the new resourc= e which is an
    >> >> >> updated
    >> >> >> copy of the old resource."
    >> >> >>
    >> >> >> Why does this need to be handled in the requirem= ents?  Are you
    >> >> >> trying
    >> >> >> to draw the distinction between immediate deleti= on of content and
    >> >> >> lazy
    >> >> >> deletion?
    >> >> >>
    >> >> > i mean the meaning of delete operation and how to ha= ndle the expired
    >> >> > records need to be clarify in requirements.
    >> >>
    >> >> My inclination is that "deleted" means that oth= er requests the object
    >> >> of the same name should result an error, until another ob= ject with the
    >> >> same name is stored.
    >> >
    >> > okay, under the scenario "client uploads the new version= , and did not
    >> > specify how to handle the old version", did DECADE serve= r delete the
    >> > older
    >> > version (or just label it unavailable, anyway, it is implemen= tation
    >> > issue )
    >> > or not ? in another word, just replace the older version with= the new
    >> > version with the same name?
    >>
    >> In this case, I would think the "write" of the new objec= t should be
    >> rejected, or if desired, we could have an overwrite option.  = This
    >> could be added to the requirements if it helps to clarify.
    >> yep, no matter which solution is chosen, let the understanding
    >> unanimously:D
    >> > how to handle the older version which is
    >> > transferring from server to client?
    >>
    >> I think it would be cleaner to ask the server to continue sending = an
    >> object once it has been started, but ultimately this would be the<= br> >> decision of the server's implementation I think.  Maybe a= "SHOULD"
    >> requirement.  This could be added if desired.
    >>
    > Thank you for these questions.  It helps design the requirements = more
    > cleanly if there are specific scenarios in front of us :)
    > just discussion together:D and also thanks for your points to help me<= br> > understanding more!

    Thanks,
    Rich

    >> Rich
    >>
    >> >> I think that the time the data is removed from disk (or m= emory) should
    >> >> be up to the implementation. A storage provider might sti= ll have as
    >> >> part of some agreement that deleted data will be removed = within X
    >> >> days/hours/minutes/whatever.
    >> >
    >> >    agree with you.
    >> >>
    >> >> If people in the WG think it is necessary, we could have = a requirement
    >> >> that says the protocol should support an argument indicat= ing immediate
    >> >> deletion, but it is not clear that we need this.
    >> >>
    >> >> Rich
    >> >>
    >> >> >>
    >> >> >> Thanks!
    >> >> >> Rich
    >> >> >>
    >> >> >>
    >> >> >> On Mon, Dec 27, 2010 at 12:57 AM, =D6=EC=E4=EC &= lt;buptxiaozhu@g= mail.com> wrote:
    >> >> >> > Dear all,
    >> >> >> >
    >> >> >> > There is a slightly updated version of the = decade additional
    >> >> >> > requirements
    >> >> >> > draft.
    >> >> >> >
    >> >> >> >
    >> >> >> > https://datat= racker.ietf.org/doc/draft-zhu-decade-additional-requirements/
    >> >> >> >
    >> >> >> > Jin Peng, Yunfei Zhang and me are expecting= to have a discussion
    >> >> >> > with
    >> >> >> > all of
    >> >> >> > you.
    >> >> >> >
    >> >> >> > Any comments are appreciated!
    >> >> >> >
    >> >> >> > A new version of I-D,
    >> >> >> > draft-zhu-decade-additional-requirements-00= .txt
    >> >> >> > has been successfully submitted by Xiao Zhu= and posted to the IETF
    >> >> >> > repository.
    >> >> >> >
    >> >> >> > Filename:      draft-zhu-dec= ade-additional-requirements
    >> >> >> > Revision:      00
    >> >> >> > Title:           &= nbsp;     Additional protocol requirements on DECADE
    >> >> >> > Creation_date:         = 2010-12-27
    >> >> >> > WG ID:           &= nbsp;     Independent Submission
    >> >> >> > Number_of_pages: 10
    >> >> >> >
    >> >> >> > Abstract:
    >> >> >> > The DECoupled Application Data Enroute(DECA= DE)working group is
    >> >> >> > specifying standardized interfaces for acce= ssing in-network
    >> >> >> > storage
    >> >> >> > from applications to store, retrieve and ma= nage data. The main
    >> >> >> > object
    >> >> >> > is to provide a framework that is useful to= the applications,
    >> >> >> > including P2P applications and other data-o= riented applications,
    >> >> >> > possibly related applications that can bene= fit from accessing in-
    >> >> >> > network storage. This memo focuses on some = requirements such as
    >> >> >> > request redirecting and so on which are on = the central of
    >> >> >> > mobility,
    >> >> >> > wireless network environment and CDN applic= ation. We present these
    >> >> >> > in
    >> >> >> > this memo as additional requirements that s= hould be considered for
    >> >> >> > the DECADE architecture and protocol specif= ications.
    >> >> >> >
    >> >> >> >
    >> >> >> >
    >> >> >> > The IETF Secretariat.
    >> >> >> >
    >> >> >> > --
    >> >> >> > Best wishes,
    >> >> >> >
    >> >> >> > Beijing University of Posts & Telecommu= nications (BUPT)
    >> >> >> > Zhu Xiao  ( =D6=EC=E4=EC )
    >> >> >> > E-mail: buptxiaozhu@gmail.com
    >> >> >> > mobile:+86 134-8881-9004
    >> >> >> >
    >> >> >> > ___________________________________________= ____
    >> >> >> > decade mailing list
    >> >> >> > decade@ietf.org
    >> >> >> > https://www.ietf.org/mailman/listinfo/decad= e
    >> >> >> >
    >> >> >> >
    >> >> >
    >> >> >
    >> >> >
    >> >> > --
    >> >> > Best wishes,
    >> >> >
    >> >> > Beijing University of Posts & Telecommunications= (BUPT)
    >> >> > Zhu Xiao  ( =D6=EC=E4=EC )
    >> >> > E-mail: buptxiaozhu@gmail.com
    >> >> > mobile:+86 134-8881-9004
    >> >
    >> >
    >> >
    >> > --
    >> > Best wishes,
    >> >
    >> > Beijing University of Posts & Telecommunications (BUPT) >> > Zhu Xiao  ( =D6=EC=E4=EC )
    >> > E-mail: buptxiaozhu@gmail.com
    >> > mobile:+86 134-8881-9004
    >> >
    >
    >
    >
    > --
    > Best wishes,
    >
    > Beijing University of Posts & Telecommunications (BUPT)
    > Zhu Xiao  ( =D6=EC=E4=EC )
    > E-mail: bup= txiaozhu@gmail.com
    > mobile:+86 134= -8881-9004
    >



    --
    Best wishes,

    Beijing University of Posts & Te= lecommunications (BUPT)
    Zhu Xiao  ( =D6=EC=E4=EC )
    E-mail: buptxiaozhu@gmail.com=
    mobile:+86 134-8881= -9004

    --002215048937046a33049e56e8fe-- --002215048937046a3a049e56e8ff Content-Type: image/gif; name="1A5.gif" Content-Transfer-Encoding: base64 X-Attachment-Id: 1A5@goomoji.gmail Content-ID: <1A5@goomoji.gmail> R0lGODlhEAAMAKIFAF5LAP/zxAAAANyuAP/gaP///wAAAAAAACH/C05FVFNDQVBFMi4wAwEAAAAh +QQJZAAFACwAAAAAEAAMAAADO1iq0/6LhUkBmCOOQLonAJEtGyEI3dmNkom6q8Z9H1sML22OTnC+ P9GNU9LFBquZJxS7NWYWZpP0qBYSACH5BAkKAAUALAAAAAAQAAwAAAM7WKrT/ouFSQGYI45AuicA kS0bIQjd2Y2Sibqrxn0fWwwvbbJNcL4/UWug84yIIlooxiiBLLXI7UEtJAAAIfkECQoABQAsAAAA ABAADAAAAzhYqtP+i4VJAZgjjkC6JwCRLRshCN3ZjZKJuqvGfR9bNLQnsOWguijeKhcjDWihYgtk qUVuj2ghAQAh+QQFCgAFACwAAAAAEAAMAAADN1iq0/6LhUkBmCOOQLonAJEtGyEI3dmNkom6q8Z9 H1s4dGqXw3uiu1VOpGl8QjHSzIJMkh7QQgIAIfkEBRQABQAsAAAFAAgABQAAAxFYMxpEwy0H3xBY KBZf+c2TAAAh+QQFCgAFACwEAAYABQACAAADBlgqMkEqAQAh+QQFAAAFACwGAAYAAwACAAADBChE 0gkAIfkECQoABQAsAAAFAAcAAgAAAwVYuqxCCQAh+QQJCgAFACwAAAAAEAAMAAADGFi63P4wyknd CESOUYbIUVB1BMFR26iuCQAh+QQFkAEFACwAAAAAEAAMAAADO1iq0/6LhUkBmCOOQLonAJEtGyEI 3dmNkom6q8Z9H1sML22OTnC+P9GNU9LFBquZJxS7NWYWZpP0qBYSADs= --002215048937046a3a049e56e8ff-- From buptxiaozhu@gmail.com Sun Mar 13 03:07:54 2011 Return-Path: X-Original-To: decade@core3.amsl.com Delivered-To: decade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 50B153A69C1 for ; Sun, 13 Mar 2011 03:07:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.372 X-Spam-Level: **** X-Spam-Status: No, score=4.372 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, J_CHICKENPOX_42=0.6, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1, SARE_GIF_ATTACH=1.42] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nn8QRKUibEUf for ; Sun, 13 Mar 2011 03:07:50 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id F23B73A695C for ; Sun, 13 Mar 2011 03:07:49 -0700 (PDT) Received: by iwl42 with SMTP id 42so5005859iwl.31 for ; Sun, 13 Mar 2011 03:09:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references :x-goomoji-body:date:message-id:subject:from:to:cc:content-type; bh=Zr9wOVjG4WpcnzgrfM0gzu233y/g7ZwgJNq7J5tjeGo=; b=CCV2JsmLcRIu+IvOQ4kGCk+kB8e2qZ1hXoSaTckDDFXaj2afZHDRk+KqQb+SQBwqOI L8yBwSA5AoNDclLQnD5m6qSuyYS6xXzHl0zrbdqDBuuJccwPNSiJAeUg0l3BO6hfxAa3 vG/Xo+AKk0nO4hTXgvzxbGAHcs5ssT8nBxSy8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:x-goomoji-body:date:message-id :subject:from:to:cc:content-type; b=PDvnOql1z0JwaFHaDWrV9VAitZLXSY8CzDG++9De+lI/yMwWf84/0MKdtXAWpEswP7 k87SWXuC3/srxMnmx3sOh2ySUYTJd2fQvX0i6hsleQLIBHraDyzyNNQxBVwRMbEI0W2v 1pxKWrCYdB7sRZ543O1q/Cualae56zbqCToOI= MIME-Version: 1.0 Received: by 10.43.71.82 with SMTP id yj18mr12023744icb.39.1300010950286; Sun, 13 Mar 2011 03:09:10 -0700 (PDT) Received: by 10.42.147.66 with HTTP; Sun, 13 Mar 2011 03:09:10 -0700 (PDT) In-Reply-To: References: X-Goomoji-Body: true Date: Sun, 13 Mar 2011 18:09:10 +0800 Message-ID: From: =?GB2312?B?1uzk7A==?= To: "David A. Bryan" Content-Type: multipart/related; boundary=bcaec51d21d0e5671f049e5a6241 Cc: decade@ietf.org Subject: Re: [decade] draft-zhu-decade-additional-requirements X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.9 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, 13 Mar 2011 10:07:54 -0000 --bcaec51d21d0e5671f049e5a6241 Content-Type: multipart/alternative; boundary=bcaec51d21d0e5671a049e5a6240 --bcaec51d21d0e5671a049e5a6240 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable hi David: thanks for joining our discussion. i can understand your concerns, especially we should finish the protocol in time. but i just wonder how decade support the user in mobile environment. you know users may roam and need to handover when they access the decade server and when the service continues, how the decade handle this situation. In Richard`s opinion, he gives explanations, basically i agree with him. i= f we just see the problem from the technical view, what about your opinion? d= o your agree with Richard? thanks! 2011/3/10 David A. Bryan > Comments inline: > > 2011/3/6 =D6=EC=E4=EC > >> Hi, Richard: >> >> sorry for reply so late, because i should remember what we >> are dissuasion and the key of the problem[?] >> >> >> so many quoted texts, let me make a summarize. >> >> 1 multi connection, i have the arguments as followings: >> >> @me: >> >> >> - need it to process new authentication and authorization after the >> user moves in the wireless environment and access a new DECADE server >> >> @you: >> >> - DECADE server should need to do some sort of check on each new >> connection, regardless of whether the user has or previously had a >> connection open to a different DECADE server, >> >> --> okay, agree with you, but we should specify in the requirements draf= t. >> >> @me: >> >> - considering the service continuity, the next serving DECADE server >> should know the progress of the service, how does they know?or >> different servers need to coordinate and schedule each other to fulfi= ll the >> user request? >> >> @you: >> >> >> - that does not mean that there can't be additional protocol(s) (not >> specified here) that are used between DECADE servers as well. and The >> IAP in the problem statement is intended to describe data transfer be= tween >> DECADE servers. >> >> -> basically agree with you, a question reminds me that "IAP means in t= he >> media layer=A3=BF and signalling or controlling layer protocol may be ne= eded to >> solve the problem? and we can reuse the other protocol to fulfill the >> storing status transfer. and we should consider to update the draft to a= dd >> the permission requirement and retrieve the client status about getting = and >> writing storage. >> > > I'm not sure I quite understand this, but it sounds like a proposal to ad= d > some sort of shared state explicitly to the protocol. In other words, to > allow a request to be received by one server and processed by another or > something similar. > > I have no problem with someone implementing this, but explicitly adding i= t > to the protocol will complicate this incredibly. If someone wants to be a > distributed version of a DECADE server (service?) that is great, but, it = is > up to the application developer to handle that in the background, > transparently to the user. I also don't really like the idea of different > servers being involved in one transaction, from a security perspective. I > want to send a request and get a response from that same "server". Now if > you want to use signed certificates and some fancy process in the back wh= ere > it appears the response came from a different server, I'm ok with that, b= ut > I firmly think to be able to finish on time we should treat the server as= a > single, client-server entity from a protocol perspective. > > BTW and on a slight tangent, there are lots of protocols that seem to be > considering distributed backends (PPSP ruled it out of scope to make the > problem simple enough to be solved as well, but there was a similar > discussion). Perhaps some folks (in another mailing list of course) shoul= d > look at the generic aspects required by these and other distributed serve= rs > and figure out if there is a need for a protocol framework to help enable > that it... > > >> >> 2 Service Assurance >> >> -> basically agree with you, keep tracking the status of the DCADE serve= r >> may also bring the additional burden to the overloaded DECADE server. >> > > I also think that publicly sharing load could be a security threat, > although we might need to think about it. Redirection is great, and a bus= y > server can use it to shed load. Explicitly telling a client (with which t= he > server may have no other relationship than this transaction) the load mig= ht > let me know that I shouldn't waste any more bots on a DoS attack on this > server...already compromised and I can move on to DoS-ing a different one= . > Just seems like a bad idea. > > David > > > >> >> 2011/3/3 Richard Alimi >> >> Hi Xiao, >>> >>> Sorry for the delay. Finally coming back to this. >>> >>> 2011/1/16 =D6=EC=E4=EC : >>> > hi, Richard: >>> > thanks for your reply:D >>> > additional discussion see inline:D >>> > 2011/1/14 Richard Alimi >>> >> >>> >> HI Xiao, >>> >> >>> >> 2011/1/12 =D6=EC=E4=EC : >>> >> > hi, Richard >>> >> > see inline:D >>> >> > >>> >> > 2011/1/11 Richard Alimi >>> >> >> >>> >> >> Hi Xiao, >>> >> >> >>> >> >> On Mon, Jan 10, 2011 at 6:45 PM, =D6=EC=E4=EC wrote: >>> >> >> > >>> >> >> > hi, Richard, sorry for so late response because of be busy with >>> other >>> >> >> > projects. >>> >> >> > some discussion see inline:D marked by red. >>> >> >> > >>> >> >> > On Tue, Jan 4, 2011 at 4:06 AM, Richard Alimi < >>> rich@velvetsea.net> >>> >> >> > wrote: >>> >> >> >> >>> >> >> >> Hi Xiao, >>> >> >> >> >>> >> >> >> Thank you for the draft. Some comments on the requirements: >>> >> >> >> >>> >> >> >> Request Redirects: >>> >> >> >> >>> >> >> >> This would provide some additional freedom for the storage >>> provider. >>> >> >> >> I think it is reasonable since it doesn't necessitate addition= al >>> >> >> >> complexity for the DECADE server, but allows it if desired. >>> However, >>> >> >> >> note that it may complicate some of the other components of th= e >>> >> >> >> design. In particular, if there is a per-user quota for storag= e, >>> is >>> >> >> >> the user made aware of the quota at each in-network storage (i= f >>> >> >> >> there >>> >> >> >> is no shared storage between them)? Resource sharing policies >>> may >>> >> >> >> be >>> >> >> >> impacted (e.g., if a bandwidth sharing weight of 1 may mean >>> >> >> >> something >>> >> >> >> different at DECADE server A than it does at DECADE server B). >>> At >>> >> >> >> this point it may be best to just note these so they are >>> documented, >>> >> >> >> but since the specification of the resource sharing policies a= re >>> >> >> >> still >>> >> >> >> being contemplated for the basic case of a single server it ma= y >>> be >>> >> >> >> premature to even try and solve them for the case supporting >>> >> >> >> redirection. >>> >> >> >> >>> >> >> > actually, you mean two points, right? >>> >> >> > 1. whether or not to be ware of the content at each in-network >>> >> >> > storage >>> >> >> > and of course resource sharing policies can be impact in the >>> request >>> >> >> > redirection. your suggestion"just to note these so they are >>> >> >> > documented" will >>> >> >> > be ok, or DECADE server list with some parameters will be retur= n >>> for >>> >> >> > user to >>> >> >> > select the appropriate DECADE server, which can avoid the >>> different >>> >> >> > weighted >>> >> >> > of the same parameter in server decision. but the parameter use= d >>> in >>> >> >> > select >>> >> >> > the best DECADE server will be known for DECADE servers, in whi= ch >>> >> >> > other >>> >> >> > complexities will be added. anyway, all the solution are the >>> >> >> > implementation >>> >> >> > issue, which, i believe, does not impact the necessity of the >>> >> >> > requirement. >>> >> >> >>> >> >> In general, I'd agree that the decision about where to redirect >>> would >>> >> >> be an implementation issue. >>> >> >> >>> >> >> > >>> >> >> > 2. you mean "the resource sharing policies are still being >>> considered >>> >> >> > in >>> >> >> > a single server", so it may be premature to support redirection= . >>> the >>> >> >> > architecture and protocol will be badly impacted if the >>> requirements >>> >> >> > change. >>> >> >> > so the designing can be taken step by step, but the >>> requirements >>> >> >> > should be >>> >> >> > overall considered. >>> >> >> >>> >> >> I said that it is probably premature to consider how resource >>> sharing >>> >> >> policies works across servers (or even if we need to say anything >>> >> >> about it) since we have not determined how to specify them (or >>> rather, >>> >> >> how little we need to specify in protocol) for a single server. I >>> did >>> >> >> not mean to imply that redirection could not be introduced as a >>> >> >> requirement. >>> >> >> >>> >> > >>> >> >> >>> >> >> > >>> >> >> > >>> >> >> >> >>> >> >> >> Multi-connection: >>> >> >> >> >>> >> >> >> I'm not quite clear on the intention of the requirement. My >>> >> >> >> understanding is that you wish the client to be able to have >>> >> >> >> multiple >>> >> >> >> connections open spanning multiple DECADE servers. Is that >>> correct? >>> >> >> >> >>> >> >> >> If so, do we need this stated as a requirement or the protocol= ? >>> Or >>> >> >> >> is >>> >> >> >> this a policy that would be allowed/disallowed by the storage >>> >> >> >> provider? >>> >> >> >> >>> >> >> > yep, your understanding is right, the scenarios were just >>> described >>> >> >> > in >>> >> >> > draft as "soft handover in wireless environment and delete >>> operation >>> >> >> > in >>> >> >> > multi-servers". under these consideration, the authentication a= nd >>> >> >> > authorization need to be taken each time when setup connection >>> with a >>> >> >> > new >>> >> >> > DECADE server, or just be taken only once during the service? >>> >> >> >>> >> >> The DECADE server should need to do some sort of check on each ne= w >>> >> >> connection, regardless of whether the user has or previously had = a >>> >> >> connection open to a different DECADE server, right? Note that t= he >>> >> >> requirements don't indicate how authentication or authorization i= s >>> >> >> done, and allow a server to make optimizations if it is enforcing >>> the >>> >> >> same permissions. >>> >> >> >>> >> >> Can you indicate where the existing authorization-related >>> requirements >>> >> >> (in particular, 4.1.6.3 of draft-ietf-decade-reqs-00) do not >>> suffice >>> >> >> for the use case you are thinking of? >>> >> >>> >> > as considering the service continuity, the next serving DECADE >>> server >>> >> > should know the progress of the service, how does they know? >>> >> >>> >> By progress of the service, do you mean current user state (e.g., >>> >> quota, recent resource usage history, permissions, etc)? >>> >>> > yes, and include data delivery proceeding. >>> >>> I still don't think I understand what you are suggesting as new >>> requirements here. Why can't the client retry any failed requests? >>> >>> >> > so if the >>> >> > service proceeding information should be known by the next serving >>> >> > server, >>> >> > or different servers need to coordinate and schedule each other to >>> >> > fulfill >>> >> > the user request, i believe the the 4.1.6.3 of the >>> >> > draft-ietf-decade-req-00 >>> >> > cannot satisfy the req. what do you think about? >>> >> >>> >> Note that the protocol that is covered here is the client-server >>> >> protocol. Some of the same protocol may be useful between DECADE >>> >> servers (especially in different administrative domains) for storing >>> >> and retrieving data, but that does not mean that there can't be >>> >> additional protocol(s) (not specified here) that are used between >>> >> DECADE servers as well. For example, if DECADE servers within an >>> >> administrative domain can certainly have their own mechanism to shar= e >>> >> such information. If such capabilities were included in the DECADE >>> >> protocol (e.g., a need to do this between administrative domains), >>> >> that sounds like lots more complexity that we need at this point. >>> >>> > but the access between in-network storage also is included in IAP >>> > described in problem statement. i mean why not put this kind of >>> function in >>> > DECADE since the IAP is defined just like that? >>> >>> The IAP in the problem statement is intended to describe data transfer >>> between DECADE servers. I think the discussion above relates to >>> storing state about the progress of delivering data to DECADE clients. >>> Is that an accurate summary? If so, then the point of DECADE is that >>> this is managed and controlled by the clients. I don't think it makes >>> sense to add additional state in to DECADE servers for this. >>> >>> >> That said, it sounds to me like what is described in 4.1.6.3 would b= e >>> >> sufficient (from the perspective of the client-server protocol, >>> >> anyways) to implement what you're describing. If not, what >>> >> specifically is missing and what use-case does it not meet? >>> >>> > so you mean the information you mentioned above, just like current us= er >>> > state (e.g., >>> > quota, recent resource usage history, permissions, etc) was already >>> > included in DECADE requirement? what about the data delivery proceedi= ng >>> > information? can you specify the chapter for me ? thanks? >>> >>> Historical information is not specified, but I can't think of another >>> storage protocol off the top of my head that provides this. >>> >>> Quota/resource usage is in Section 5.1.6. Permissions, if applicable, >>> should be there too (we will update the doc to state this). >>> >>> For data delivery, I see value in getting status about other client >>> that may have open connections or active transfers (reads or writes) >>> to one's storage. This could probably be added as a requirement. >>> >>> However, if the expectation is for DECADE servers to somehow >>> coordinate (e.g., picking a data path, resuming/retrying failed >>> transfers, etc), then this is going towards delay-tolerant networking >>> or CDNs. DECADE is not intended for that. >>> >>> >> >> > >>> >> >> > >>> >> >> >> >>> >> >> >> Data Distribution: >>> >> >> >> >>> >> >> >> I'm also confused about the intent of this requirement. This >>> >> >> >> statement has me somewhat worried: "The distribution is >>> transparent >>> >> >> >> to >>> >> >> >> the users as they interact with the in-network storage as a >>> single >>> >> >> >> logical system." Does this mean that you are proposing for >>> DECADE >>> >> >> >> servers to assume the responsibility for deciding how data is = to >>> be >>> >> >> >> distributed throughout the network, including the path of the >>> data, >>> >> >> >> which servers act as intermediate caches, content expiration >>> >> >> >> policies, >>> >> >> >> etc? If this is true, I think it is missing one of the major >>> points >>> >> >> >> of DECADE. In particular, these decisions are >>> application-dependent >>> >> >> >> and are not implemented within DECADE. Instead, DECADE provide= s >>> the >>> >> >> >> basic capabilities and the functionality described above are >>> >> >> >> implemented by the applications using DECADE. >>> >> >> >> >>> >> >> >> Or, am I misinterpreting the intent of the requirement? >>> >> >> >> >>> >> >> > you mean DECADE provides the basic capabilities, so can you giv= e >>> some >>> >> >> > specify explanations on DECADE capabilities in supporting data >>> >> >> > distribution? >>> >> >> >> >>> >> >> >>> >> >> The problem statement gives a couple of scenarios. The "Integrati= on >>> >> >> Examples" presentation from IETF 79 also has more details of an >>> >> >> on-going effort at Yale. >>> >> >>> >> > okay, thx for your information, i will lookup and refer, actually, >>> the >>> >> > content publisher described in problem statement remind me of the >>> >> > protocol requirements which i did not find in >>> draft-ietf-decade-reqs-00 >>> >> > to >>> >> > support content publish. or i miss some points? >>> >> >>> >> Which requirements do you think are missing? >>> >> >>> >> >> >> Service Assurance: >>> >> >> >> >>> >> >> >> It seems problematic to include "assurance" in a DECADE. >>> Shouldn't >>> >> >> >> these instead be part of SLAs with a storage provider? Why >>> should >>> >> >> >> they be DECADE's responsibility? >>> >> >> >> >>> >> >> >> Regarding "resource reservation", are you referring to an actu= al >>> >> >> >> reservation (which might be problematic -- see above) or do yo= u >>> mean >>> >> >> >> that the resource share should able to be specified at the tim= e >>> the >>> >> >> >> connection opens and be assumed to be the same for the duratio= n >>> of >>> >> >> >> the >>> >> >> >> connection? >>> >> >> >> >>> >> >> >> Regarding Dynamic Feedback, is this orthogonal to the storage >>> >> >> >> protocol? It seems like what you want here is a generic >>> "status" >>> >> >> >> service saying how loaded a server is? >>> >> >> >> >>> >> >> > thats right, actually, the flow control mechanism was under >>> >> >> > discussion >>> >> >> > in writing the draft at first. what about your opinion in this >>> >> >> > requirements? >>> >> >> > >>> >> >> >>> >> >> I'm not sure what the typical way of providing such "load status" >>> >> >> information for IETF protocols, but my inclination is that it >>> should >>> >> >> not be in the DECADE protocol itself. Maybe someone else with a >>> >> >> longer history in IETF could jump in here :) >>> >> > so can i understand that "load status" is kind of necessity >>> information >>> >> > for DECADE Server, but where and who collects the information are >>> >> > remain discussion? >>> >> >>> >> The storage provider is free to collect the information wherever and >>> >> however they wish. The DECADE server implementation could additiona= l >>> >> export whatever status information it wishes. I don't think the DECA= DE >>> >> protocol needs to be concerned with that. >>> >> >>> >> Note that certain error conditions (e.g., overload, insufficient >>> >> resources) may be signaled by a DECADE server (there are already hav= e >>> >> requirements for those). If you are referring to status for a user'= s >>> >> resources, there is already a requirement for that too. >>> >> >>> >> I'm just not convinced that the DECADE protocol needs to export its >>> >> current load status to clients. >>> >>> > actually i am not sure which elements in DECADE needs the load >>> > status,(DECADE client or network storage if the network storage needs >>> to >>> > redirect the request or both?). >>> > And the requirement draft currently seems describe the overload >>> condition >>> > as the event triggering. do you think if it is necessary to >>> periodically >>> > reporting of the DECADE network status to client for its network >>> storage >>> > selection? >>> >>> No I don't think this is necessary. The client can retry the request >>> at a later time (e.g., exponential backoff). Note that asking a >>> heavily-loaded DECADE server to also keep track of clients that need >>> to be notified, and keep them updated of the current status, is >>> probably counter-productive. >>> >>> > and the requirement draft just describe DECADE which is busy to serve >>> > other requests must be able to reject requests, not consider how to >>> handle >>> > the user request after being rejected? >>> >>> That's the implementation's decision. I suspect most would drop it on t= he >>> floor. >>> >>> >> >> >> >>> >> >> >> Data classification: >>> >> >> >> >>> >> >> >> Would it be better to instead have the client specify properti= es >>> of >>> >> >> >> the content instead of place it into ? See >>> >> >> >> www.ietf.org/proceedings/78/slides/nfsv4-0.pdf for an example >>> of >>> >> >> >> this >>> >> >> >> approach for NFS. >>> >> >> >> >>> >> >> >> I think a problem with classifying applications is that it >>> assumes >>> >> >> >> that applications fit one of the supplied classifications. Wha= t >>> if >>> >> >> >> it >>> >> >> >> may fit multiple classifications? or none? Another problem is >>> it >>> >> >> >> assumes that servers assume based on indirect and assumed >>> >> >> >> information >>> >> >> >> that they know what to do with a particular piece of content. >>> Why >>> >> >> >> not >>> >> >> >> have an application specify its desires directly? >>> >> >> >> >>> >> >> > >>> >> >> > >>> >> >> >> >>> >> >> >> Small Objects: >>> >> >> >> >>> >> >> >> What is the new requirement here? Why is the existing >>> requirement >>> >> >> >> in >>> >> >> >> draft-ietf-decade-reqs-00 insufficient? >>> >> >> >> >>> >> >> >> This also has me a bit worried: >>> >> >> >> "And the in-network storage has the limited storage capacity, >>> with >>> >> >> >> the >>> >> >> >> arrival of user requests and data distribution requirements, t= he >>> >> >> >> data >>> >> >> >> stored in the in-network storage will be replaced if the stora= ge >>> >> >> >> reaches the limit and data arrivals continually." >>> >> >> >> >>> >> >> >> How does the server know what the proper replacement strategy = is >>> for >>> >> >> >> an application? I think DECADE's philosophy is that applicatio= ns >>> >> >> >> should decide this. A simple way to do this is explicit deleti= on >>> by >>> >> >> >> an >>> >> >> >> application, but perhaps a more efficient (yet more complex) >>> >> >> >> solution >>> >> >> >> is for an application to specify the replacement policy to the >>> >> >> >> server. >>> >> >> >> >>> >> >> > actually, the key in "the data classification and small objects= " >>> is >>> >> >> > whether does it or not in P2P application? i did not find data >>> >> >> > classification was adopted in P2P application so far, let alone >>> >> >> > DECADE need >>> >> >> > to classify the data used in all kinds of application. >>> >> >> > >>> >> >> >>> >> >> So, do you agree that it is problematic to try and classify each >>> type >>> >> >> of application and try to specify the typical workload for each >>> class? >>> >> >> >>> >> >> My point was that I don't think its necessary to do the >>> classification >>> >> >> at all. It is more extensible (and directly useful) for a server >>> to >>> >> >> just give it direct hints about what would be preferable. >>> >> > >>> >> > yep, i believe it may be a little difficult, but worthy doing. >>> specially >>> >> > for improving the resource utilization within a single server and >>> >> > reducing >>> >> > the response time for client. what about others opinion? >>> >> >>> >> Can you justify why giving classifications (e.g., "I'm a live >>> >> streaming application") would be better than giving specific hints >>> >> (e.g., "please don't bother persistent these objects to disk")? >>> > >>> > i mean data in different kind of operation mode and attribute should >>> have >>> > different user patterns and storage rules, which may be help to impro= ve >>> the >>> > resource utilization and reduce the response time for request, what a= re >>> you >>> > understanding? >>> >>> That's fine. Explicit and more-specific hints are a different way to >>> accomplish the same thing, and seem to be a much better design to me. >>> They are simpler from an extensibility and implementation point of >>> view. >>> >>> >> > >> >>> >> >> >> Removal of Expired Records: >>> >> >> >> >>> >> >> >> "However, the two scenarios did not mention how to handle the >>> old >>> >> >> >> resource if the user distributes the new resource which is an >>> >> >> >> updated >>> >> >> >> copy of the old resource." >>> >> >> >> >>> >> >> >> Why does this need to be handled in the requirements? Are you >>> >> >> >> trying >>> >> >> >> to draw the distinction between immediate deletion of content >>> and >>> >> >> >> lazy >>> >> >> >> deletion? >>> >> >> >> >>> >> >> > i mean the meaning of delete operation and how to handle the >>> expired >>> >> >> > records need to be clarify in requirements. >>> >> >> >>> >> >> My inclination is that "deleted" means that other requests the >>> object >>> >> >> of the same name should result an error, until another object wit= h >>> the >>> >> >> same name is stored. >>> >> > >>> >> > okay, under the scenario "client uploads the new version, and did >>> not >>> >> > specify how to handle the old version", did DECADE server delete t= he >>> >> > older >>> >> > version (or just label it unavailable, anyway, it is implementatio= n >>> >> > issue ) >>> >> > or not ? in another word, just replace the older version with the >>> new >>> >> > version with the same name? >>> >> >>> >> In this case, I would think the "write" of the new object should be >>> >> rejected, or if desired, we could have an overwrite option. This >>> >> could be added to the requirements if it helps to clarify. >>> >> yep, no matter which solution is chosen, let the understanding >>> >> unanimously:D >>> >> > how to handle the older version which is >>> >> > transferring from server to client? >>> >> >>> >> I think it would be cleaner to ask the server to continue sending an >>> >> object once it has been started, but ultimately this would be the >>> >> decision of the server's implementation I think. Maybe a "SHOULD" >>> >> requirement. This could be added if desired. >>> >> >>> > Thank you for these questions. It helps design the requirements more >>> > cleanly if there are specific scenarios in front of us :) >>> > just discussion together:D and also thanks for your points to help me >>> > understanding more! >>> >>> Thanks, >>> Rich >>> >>> >> Rich >>> >> >>> >> >> I think that the time the data is removed from disk (or memory) >>> should >>> >> >> be up to the implementation. A storage provider might still have = as >>> >> >> part of some agreement that deleted data will be removed within X >>> >> >> days/hours/minutes/whatever. >>> >> > >>> >> > agree with you. >>> >> >> >>> >> >> If people in the WG think it is necessary, we could have a >>> requirement >>> >> >> that says the protocol should support an argument indicating >>> immediate >>> >> >> deletion, but it is not clear that we need this. >>> >> >> >>> >> >> Rich >>> >> >> >>> >> >> >> >>> >> >> >> Thanks! >>> >> >> >> Rich >>> >> >> >> >>> >> >> >> >>> >> >> >> On Mon, Dec 27, 2010 at 12:57 AM, =D6=EC=E4=EC >>> wrote: >>> >> >> >> > Dear all, >>> >> >> >> > >>> >> >> >> > There is a slightly updated version of the decade additional >>> >> >> >> > requirements >>> >> >> >> > draft. >>> >> >> >> > >>> >> >> >> > >>> >> >> >> > >>> https://datatracker.ietf.org/doc/draft-zhu-decade-additional-requiremen= ts/ >>> >> >> >> > >>> >> >> >> > Jin Peng, Yunfei Zhang and me are expecting to have a >>> discussion >>> >> >> >> > with >>> >> >> >> > all of >>> >> >> >> > you. >>> >> >> >> > >>> >> >> >> > Any comments are appreciated! >>> >> >> >> > >>> >> >> >> > A new version of I-D, >>> >> >> >> > draft-zhu-decade-additional-requirements-00.txt >>> >> >> >> > has been successfully submitted by Xiao Zhu and posted to th= e >>> IETF >>> >> >> >> > repository. >>> >> >> >> > >>> >> >> >> > Filename: draft-zhu-decade-additional-requirements >>> >> >> >> > Revision: 00 >>> >> >> >> > Title: Additional protocol requirements on >>> DECADE >>> >> >> >> > Creation_date: 2010-12-27 >>> >> >> >> > WG ID: Independent Submission >>> >> >> >> > Number_of_pages: 10 >>> >> >> >> > >>> >> >> >> > Abstract: >>> >> >> >> > The DECoupled Application Data Enroute(DECADE)working group = is >>> >> >> >> > specifying standardized interfaces for accessing in-network >>> >> >> >> > storage >>> >> >> >> > from applications to store, retrieve and manage data. The ma= in >>> >> >> >> > object >>> >> >> >> > is to provide a framework that is useful to the applications= , >>> >> >> >> > including P2P applications and other data-oriented >>> applications, >>> >> >> >> > possibly related applications that can benefit from accessin= g >>> in- >>> >> >> >> > network storage. This memo focuses on some requirements such >>> as >>> >> >> >> > request redirecting and so on which are on the central of >>> >> >> >> > mobility, >>> >> >> >> > wireless network environment and CDN application. We present >>> these >>> >> >> >> > in >>> >> >> >> > this memo as additional requirements that should be consider= ed >>> for >>> >> >> >> > the DECADE architecture and protocol specifications. >>> >> >> >> > >>> >> >> >> > >>> >> >> >> > >>> >> >> >> > The IETF Secretariat. >>> >> >> >> > >>> >> >> >> > -- >>> >> >> >> > Best wishes, >>> >> >> >> > >>> >> >> >> > Beijing University of Posts & Telecommunications (BUPT) >>> >> >> >> > Zhu Xiao ( =D6=EC=E4=EC ) >>> >> >> >> > E-mail: buptxiaozhu@gmail.com >>> >> >> >> > mobile:+86 134-8881-9004 >>> >> >> >> > >>> >> >> >> > _______________________________________________ >>> >> >> >> > decade mailing list >>> >> >> >> > decade@ietf.org >>> >> >> >> > https://www.ietf.org/mailman/listinfo/decade >>> >> >> >> > >>> >> >> >> > >>> >> >> > >>> >> >> > >>> >> >> > >>> >> >> > -- >>> >> >> > Best wishes, >>> >> >> > >>> >> >> > Beijing University of Posts & Telecommunications (BUPT) >>> >> >> > Zhu Xiao ( =D6=EC=E4=EC ) >>> >> >> > E-mail: buptxiaozhu@gmail.com >>> >> >> > mobile:+86 134-8881-9004 >>> >> > >>> >> > >>> >> > >>> >> > -- >>> >> > Best wishes, >>> >> > >>> >> > Beijing University of Posts & Telecommunications (BUPT) >>> >> > Zhu Xiao ( =D6=EC=E4=EC ) >>> >> > E-mail: buptxiaozhu@gmail.com >>> >> > mobile:+86 134-8881-9004 >>> >> > >>> > >>> > >>> > >>> > -- >>> > Best wishes, >>> > >>> > Beijing University of Posts & Telecommunications (BUPT) >>> > Zhu Xiao ( =D6=EC=E4=EC ) >>> > E-mail: buptxiaozhu@gmail.com >>> > mobile:+86 134-8881-9004 >>> > >>> >> >> >> >> -- >> Best wishes, >> >> Beijing University of Posts & Telecommunications (BUPT) >> Zhu Xiao ( =D6=EC=E4=EC ) >> E-mail: buptxiaozhu@gmail.com >> mobile:+86 134-8881-9004 >> >> _______________________________________________ >> decade mailing list >> decade@ietf.org >> https://www.ietf.org/mailman/listinfo/decade >> >> > --=20 Best wishes, Beijing University of Posts & Telecommunications (BUPT) Zhu Xiao ( =D6=EC=E4=EC ) E-mail: buptxiaozhu@gmail.com mobile:+86 134-8881-9004 --bcaec51d21d0e5671a049e5a6240 Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable hi David: 

    thanks for joining our discussion.<= /div>

    i can understand your concerns, especially we= should finish the protocol in time. but i just wonder how decade support t= he user in mobile environment. you know users may roam and need to han= dover when they access the decade server and when the service continues, ho= w the decade handle this situation. 

    In Richard`s opinion, he gives explanations,&= nbsp;basically  i agree with him. if we just see the problem from the = technical view, what about your opinion? do your agree with Richard?
    <= div>
    thanks!

    2011/3/10 David A. Bryan <dbryan@ethernot.o= rg>
    Comments inline:

    2011/3= /6 =D6=EC=E4=EC <buptxiaozhu@gmail.com>
    Hi, Richard:

    sorry for reply so late, because= i should remember what we are dissuasion and the key of the prob= lem


    so many quoted texts, let me make a = ;summarize.

    1 multi connection, i have the argumen= ts as followings:

    @me:

  • need it to process new authentication and authorization after the = user moves in the wireless environment and access a new DECADE se= rver
    • @you:
    • DECADE server should need to do some sort of check on= each new
       connection, regardless of whether the user has or previously had a connection open to a different DECADE server,
    =
    --> okay, agree with you, but we should specify in the r= equirements draft.

    @me:
    • considering the service continuity, the next serving  DECADE serv= er
       should know the progress= of the service, how does they know?= or different servers need to coordinate and schedule each other to ful= fill the user request?
    @you:

    • that does = not mean that there can't be DECADE servers as well. and The IAP in the problem statement is intended to describe data = transfer between DECADE servers.
    -> basically agree with you,  a question reminds me= that "IAP means in the media layer=A3=BF and signalling or controllin= g layer protocol may be needed to solve the problem? and we can reuse the o= ther protocol to fulfill the storing status transfer. and we should conside= r to update the draft to add the permission requirement and retrieve&n= bsp;the client status about getting and writing storage. 

    I'm not sure I quite understand = this, but it sounds like a proposal to add some sort of shared state explic= itly to the protocol. In other words, to allow a request to be received by = one server and processed by another or something similar.

    I have no problem with someone implementing this, but e= xplicitly adding it to the protocol will complicate this incredibly. If som= eone wants to be a distributed version of a DECADE server (service?) that i= s great, but, it is up to the application developer to handle that in the b= ackground, transparently to the user. I also don't really like the idea= of different servers being involved in one transaction, from a security pe= rspective. I want to send a request and get a response from that same "= ;server". Now if you want to use signed certificates and some fancy pr= ocess in the back where it appears the response came from a different serve= r, I'm ok with that, but I firmly think to be able to finish on time we= should treat the server as a single, client-server entity from a protocol = perspective.

    BTW and on a slight tangent, there are lots of protocol= s that seem to be considering distributed backends (PPSP ruled it out of sc= ope to make the problem simple enough to be solved as well, but there was a= similar discussion). Perhaps some folks (in another mailing list of course= ) should look at the generic aspects required by these and other distribute= d servers and figure out if there is a need for a protocol framework to hel= p enable that it...
     

    2 Service Assurance

    -> basically agree with you, keep tra= cking the status of the DCADE server may also bring the additional&nbs= p;burden to the overloaded DECADE server.

    I also think that publicly sharing l= oad could be a security threat, although we might need to think about it. R= edirection is great, and a busy server can use it to shed load. Explicitly = telling a client (with which the server may have no other relationship than= this transaction) the load might let me know that I shouldn't waste an= y more bots on a DoS attack on this server...already compromised and I can = move on to DoS-ing a different one. Just seems like a bad idea.

    David

     

    2011/3/3 Richard Alimi <rich@velvetse= a.net>

    Hi Xiao,

    Sorry for the delay. Finally coming back to this.

    2011/1/16 =D6=EC=E4=EC <buptxiaozhu@gmail.com>:
    > hi, Richard:
    > thanks for your reply:D
    > additional discussion see inline:D
    > 2011/1/14 Richard Alimi <rich@velvetsea.net>
    >>
    >> HI Xiao,
    >>
    >> 2011/1/12 =D6=EC=E4=EC <buptxiaozhu@gmail.com>:
    >> > hi, Richard
    >> > see inline:D
    >> >
    >> > 2011/1/11 Richard Alimi <rich@velvetsea.net>
    >> >>
    >> >> Hi Xiao,
    >> >>
    >> >> On Mon, Jan 10, 2011 at 6:45 PM, =D6=EC=E4=EC <buptxiaozhu@gmail.com> wrote:
    >> >> >
    >> >> > hi, Richard, sorry for so late response because of b= e busy with other
    >> >> > projects.
    >> >> > some discussion see inline:D marked by red.
    >> >> >
    >> >> > On Tue, Jan 4, 2011 at 4:06 AM, Richard Alimi <rich@velvetsea.net>
    >> >> > wrote:
    >> >> >>
    >> >> >> Hi Xiao,
    >> >> >>
    >> >> >> Thank you for the draft.  Some comments on = the requirements:
    >> >> >>
    >> >> >> Request Redirects:
    >> >> >>
    >> >> >> This would provide some additional freedom for t= he storage provider.
    >> >> >> I think it is reasonable since it doesn't ne= cessitate additional
    >> >> >> complexity for the DECADE server, but allows it = if desired. However,
    >> >> >> note that it may complicate some of the other co= mponents of the
    >> >> >> design. In particular, if there is a per-user qu= ota for storage, is
    >> >> >> the user made aware of the quota at each in-netw= ork storage (if
    >> >> >> there
    >> >> >> is no shared storage between them)?  Resour= ce sharing policies may
    >> >> >> be
    >> >> >> impacted (e.g., if a bandwidth sharing weight of= 1 may mean
    >> >> >> something
    >> >> >> different at DECADE server A than it does at DEC= ADE server B).  At
    >> >> >> this point it may be best to just note these so = they are documented,
    >> >> >> but since the specification of the resource shar= ing policies are
    >> >> >> still
    >> >> >> being contemplated for the basic case of a singl= e server it may be
    >> >> >> premature to even try and solve them for the cas= e supporting
    >> >> >> redirection.
    >> >> >>
    >> >> > actually, you mean two points, right?
    >> >> > 1. whether or not to be ware of the content at each = in-network
    >> >> > storage
    >> >> > and of course resource sharing policies can be impac= t in the request
    >> >> > redirection. your suggestion"just to note these= so they are
    >> >> > documented" will
    >> >> > be ok, or DECADE server list with some parameters wi= ll be return for
    >> >> > user to
    >> >> > select the appropriate DECADE server, which can avoi= d the different
    >> >> > weighted
    >> >> > of the same parameter in server decision. but the pa= rameter used in
    >> >> > select
    >> >> > the best DECADE server will be known for DECADE serv= ers, in which
    >> >> > other
    >> >> > complexities will be added. anyway, all the solution= are the
    >> >> > implementation
    >> >> > issue, which, i believe, does not impact the necessi= ty of the
    >> >> > requirement.
    >> >>
    >> >> In general, I'd agree that the decision about where t= o redirect would
    >> >> be an implementation issue.
    >> >>
    >> >> >
    >> >> > 2. you mean "the resource sharing policies are = still being considered
    >> >> > in
    >> >> > a single server", so it may be premature to sup= port redirection.  the
    >> >> > architecture and protocol will be badly impacted if = the requirements
    >> >> > change.
    >> >> > so the designing can be  taken  step by st= ep, but the requirements
    >> >> > should be
    >> >> > overall considered.
    >> >>
    >> >> I said that it is probably premature to consider how reso= urce sharing
    >> >> policies works across servers (or even if we need to say = anything
    >> >> about it) since we have not determined how to specify the= m (or rather,
    >> >> how little we need to specify in protocol) for a single s= erver. I did
    >> >> not mean to imply that redirection could not be introduce= d as a
    >> >> requirement.
    >> >>
    >> >
    >> >>
    >> >> >
    >> >> >
    >> >> >>
    >> >> >> Multi-connection:
    >> >> >>
    >> >> >> I'm not quite clear on the intention of the = requirement.  My
    >> >> >> understanding is that you wish the client to be = able to have
    >> >> >> multiple
    >> >> >> connections open spanning multiple DECADE server= s. Is that correct?
    >> >> >>
    >> >> >> If so, do we need this stated as a requirement o= r the protocol? Or
    >> >> >> is
    >> >> >> this a policy that would be allowed/disallowed b= y the storage
    >> >> >> provider?
    >> >> >>
    >> >> > yep, your understanding is right, the scenarios were= just described
    >> >> > in
    >> >> > draft as "soft handover in wireless environment= and delete operation
    >> >> > in
    >> >> > multi-servers". under these consideration, the = authentication and
    >> >> > authorization need to be taken each time when setup = connection with a
    >> >> > new
    >> >> > DECADE server, or just be taken only once during &nb= sp;the service?
    >> >>
    >> >> The DECADE server should need to do some sort of check on= each new
    >> >> connection, regardless of whether the user has or previou= sly had a
    >> >> connection open to a different DECADE server, right? &nbs= p;Note that the
    >> >> requirements don't indicate how authentication or aut= horization is
    >> >> done, and allow a server to make optimizations if it is e= nforcing the
    >> >> same permissions.
    >> >>
    >> >> Can you indicate where the existing authorization-related= requirements
    >> >> (in particular, 4.1.6.3 of draft-ietf-decade-reqs-00) do = not suffice
    >> >> for the use case you are thinking of?
    >>
    >> > as considering the service continuity, the next serving  = ;DECADE server
    >> > should know the progress of the service, how does they know?<= br> >>
    >> By progress of the service, do you mean current user state (e.g.,<= br> >> quota, recent resource usage history, permissions, etc)?

    > yes, and include data delivery proceeding.

    I still don't think I understand what you are suggesting as= new
    requirements here.  Why can't the client retry any failed requests= ?

    >> > so if the
    >> > service proceeding information should be known by the next se= rving
    >> > server,
    >> > or different servers need to coordinate and schedule each oth= er to
    >> > fulfill
    >> > the user request, i believe the the 4.1.6.3 of the
    >> > draft-ietf-decade-req-00
    >> > cannot satisfy the req. what do you think about?
    >>
    >> Note that the protocol that is covered here is the client-server >> protocol. Some of the same protocol may be useful between DECADE >> servers (especially in different administrative domains) for stori= ng
    >> and retrieving data, but that does not mean that there can't b= e
    >> additional protocol(s) (not specified here) that are used between<= br> >> DECADE servers as well.  For example, if DECADE servers withi= n an
    >> administrative domain can certainly have their own mechanism to sh= are
    >> such information.  If such capabilities were included in the = DECADE
    >> protocol (e.g., a need to do this between administrative domains),=
    >> that sounds like lots more complexity that we need at this point.<= br>
    > but the access between in-network storage also is included in IAP
    > described in problem statement.  i mean why not put this kind of = function in
    > DECADE since the IAP is defined just like that?

    The IAP in the problem statement is intended to describe data transfe= r
    between DECADE servers.  I think the discussion above relates to
    storing state about the progress of delivering data to DECADE clients.
    Is that an accurate summary?  If so, then the point of DECADE is that<= br> this is managed and controlled by the clients.  I don't think it m= akes
    sense to add additional state in to DECADE servers for this.

    >> That said, it sounds to me like what is described in 4.1.6.3 would= be
    >> sufficient (from the perspective of the client-server protocol, >> anyways) to implement what you're describing. If not, what
    >> specifically is missing and what use-case does it not meet?

    > so you mean the information you mentioned above, just like current use= r
    > state (e.g.,
    > quota, recent resource usage history, permissions, etc) was already > included in DECADE requirement? what about the data delivery proceedin= g
    > information? can you specify the chapter for me ? thanks?

    Historical information is not specified, but I can't think of ano= ther
    storage protocol off the top of my head that provides this.

    Quota/resource usage is in Section 5.1.6. Permissions, if applicable,
    should be there too (we will update the doc to state this).

    For data delivery, I see value in getting status about other client
    that may have open connections or active transfers (reads or writes)
    to one's storage. This could probably be added as a requirement.

    However, if the expectation is for DECADE servers to somehow
    coordinate (e.g., picking a data path, resuming/retrying failed
    transfers, etc), then this is going towards delay-tolerant networking
    or CDNs. DECADE is not intended for that.

    >> >> >
    >> >> >
    >> >> >>
    >> >> >> Data Distribution:
    >> >> >>
    >> >> >> I'm also confused about the intent of this r= equirement.  This
    >> >> >> statement has me somewhat worried: "The dis= tribution is transparent
    >> >> >> to
    >> >> >> the users as they interact with the in-network s= torage as a single
    >> >> >> logical system." Does this mean that you ar= e proposing for DECADE
    >> >> >> servers to assume the responsibility for decidin= g how data is to be
    >> >> >> distributed throughout the network, including th= e path of the data,
    >> >> >> which servers act as intermediate caches, conten= t expiration
    >> >> >> policies,
    >> >> >> etc?  If this is true, I think it is missin= g one of the major points
    >> >> >> of DECADE. In particular, these decisions are ap= plication-dependent
    >> >> >> and are not implemented within DECADE. Instead, = DECADE provides the
    >> >> >> basic capabilities and the functionality describ= ed above are
    >> >> >> implemented by the applications using DECADE. >> >> >>
    >> >> >> Or, am I misinterpreting the intent of the requi= rement?
    >> >> >>
    >> >> > you mean DECADE provides the basic capabilities, so = can you give some
    >> >> > specify explanations on DECADE capabilities in suppo= rting data
    >> >> > distribution?
    >> >> >>
    >> >>
    >> >> The problem statement gives a couple of scenarios. The &q= uot;Integration
    >> >> Examples" presentation from IETF 79 also has more de= tails of an
    >> >> on-going effort at Yale.
    >>
    >> > okay, thx for your information, i will lookup and refer, actu= ally, the
    >> > content publisher described in problem statement remind me of=  the
    >> > protocol requirements which i did not find in draft-ietf-deca= de-reqs-00
    >> > to
    >> > support content publish. or i miss some points?
    >>
    >> Which requirements do you think are missing?
    >>
    >> >> >> Service Assurance:
    >> >> >>
    >> >> >> It seems problematic to include "assurance&= quot; in a DECADE.  Shouldn't
    >> >> >> these instead be part of SLAs with a storage pro= vider?  Why should
    >> >> >> they be DECADE's responsibility?
    >> >> >>
    >> >> >> Regarding "resource reservation", are = you referring to an actual
    >> >> >> reservation (which might be problematic -- see a= bove) or do you mean
    >> >> >> that the resource share should able to be specif= ied at the time the
    >> >> >> connection opens and be assumed to be the same f= or the duration of
    >> >> >> the
    >> >> >> connection?
    >> >> >>
    >> >> >> Regarding Dynamic Feedback, is this orthogonal t= o the storage
    >> >> >> protocol?  It seems like what you want here= is a generic "status"
    >> >> >> service saying how loaded a server is?
    >> >> >>
    >> >> > thats right, actually, the flow control mechanism wa= s under
    >> >> > discussion
    >> >> > in writing the draft at first. what about your opini= on in this
    >> >> > requirements?
    >> >> >
    >> >>
    >> >> I'm not sure what the typical way of providing such &= quot;load status"
    >> >> information for IETF protocols, but my inclination is tha= t it should
    >> >> not be in the DECADE protocol itself.  Maybe someone= else with a
    >> >> longer history in IETF could jump in here :)
    >> > so can i understand that "load status" is kind of n= ecessity  information
    >> > for DECADE Server, but where and who collects the information= are
    >> > remain discussion?
    >>
    >> The storage provider is free to collect the information wherever a= nd
    >> however they wish.  The DECADE server implementation could ad= ditional
    >> export whatever status information it wishes. I don't think th= e DECADE
    >> protocol needs to be concerned with that.
    >>
    >> Note that certain error conditions (e.g., overload, insufficient >> resources) may be signaled by a DECADE server (there are already h= ave
    >> requirements for those).  If you are referring to status for = a user's
    >> resources, there is already a requirement for that too.
    >>
    >> I'm just not convinced that the DECADE protocol needs to expor= t its
    >> current load status to clients.

    > actually i am not sure which elements in DECADE needs the load
    > status,(DECADE client or network storage if the network storage needs = to
    > redirect the request or both?).
    > And the requirement draft currently seems describe the overload condit= ion
    > as the event triggering.  do you think if it is necessary to peri= odically
    > reporting of the DECADE network status to client for its network stora= ge
    > selection?

    No I don't think this is necessary.  The client can re= try the request
    at a later time (e.g., exponential backoff).  Note that asking a
    heavily-loaded DECADE server to also keep track of clients that need
    to be notified, and keep them updated of the current status, is
    probably counter-productive.

    > and the requirement draft just describe DECADE which is busy to serve<= br> > other requests must be able to reject requests, not consider how to ha= ndle
    > the user request after being rejected?

    That's the implementation's decision. I suspect most would dr= op it on the floor.

    >> >> >>
    >> >> >> Data classification:
    >> >> >>
    >> >> >> Would it be better to instead have the client sp= ecify properties of
    >> >> >> the content instead of place it into ? See
    >> >> >>     www.ietf.org/proceedings/78/slides/nfsv= 4-0.pdf for an example of
    >> >> >> this
    >> >> >> approach for NFS.
    >> >> >>
    >> >> >> I think a problem with classifying applications = is that it assumes
    >> >> >> that applications fit one of the supplied classi= fications. What if
    >> >> >> it
    >> >> >> may fit multiple classifications? or none?  = ;Another problem is it
    >> >> >> assumes that servers assume based on indirect an= d assumed
    >> >> >> information
    >> >> >> that they know what to do with a particular piec= e of content. Why
    >> >> >> not
    >> >> >> have an application specify its desires directly= ?
    >> >> >>
    >> >> >
    >> >> >
    >> >> >>
    >> >> >> Small Objects:
    >> >> >>
    >> >> >> What is the new requirement here?  Why is t= he existing requirement
    >> >> >> in
    >> >> >> draft-ietf-decade-reqs-00 insufficient?
    >> >> >>
    >> >> >> This also has me a bit worried:
    >> >> >> "And the in-network storage has the limited= storage capacity, with
    >> >> >> the
    >> >> >> arrival of user requests and data distribution r= equirements, the
    >> >> >> data
    >> >> >> stored in the in-network storage will be replace= d if the storage
    >> >> >> reaches the limit and data arrivals continually.= "
    >> >> >>
    >> >> >> How does the server know what the proper replace= ment strategy is for
    >> >> >> an application? I think DECADE's philosophy = is that applications
    >> >> >> should decide this. A simple way to do this is e= xplicit deletion by
    >> >> >> an
    >> >> >> application, but perhaps a more efficient (yet m= ore complex)
    >> >> >> solution
    >> >> >> is for an application to specify the replacement= policy to the
    >> >> >> server.
    >> >> >>
    >> >> > actually, the key in "the data classification a= nd small objects " is
    >> >> > whether does it or not in P2P application? i did not= find data
    >> >> > classification was adopted in P2P application so far= , let alone
    >> >> > DECADE need
    >> >> > to classify the data used in all kinds of applicatio= n.
    >> >> >
    >> >>
    >> >> So, do you agree that it is problematic to try and classi= fy each type
    >> >> of application and try to specify the typical workload fo= r each class?
    >> >>
    >> >> My point was that I don't think its necessary to do t= he classification
    >> >> at all.  It is more extensible (and directly useful)= for a server to
    >> >> just give it direct hints about what would be preferable.=
    >> >
    >> > yep, i believe it may be a little difficult, but worthy doing= . specially
    >> > for improving the resource utilization within a single server= and
    >> > reducing
    >> > the response time for client. what about others opinion?
    >>
    >> Can you justify why giving classifications (e.g., "I'm a = live
    >> streaming application") would be better than giving specific = hints
    >> (e.g., "please don't bother persistent these objects to d= isk")?
    >
    > i mean data in different kind of operation mode and attribute should h= ave
    > different user patterns and storage rules, which may be help to improv= e the
    > resource utilization and reduce the response time for request, what ar= e you
    > understanding?

    That's fine. Explicit and more-specific hints are a differe= nt way to
    accomplish the same thing, and seem to be a much better design to me.
    They are simpler from an extensibility and implementation point of
    view.

    >> > >>
    >> >> >> Removal of Expired Records:
    >> >> >>
    >> >> >> "However, the two scenarios did not mention= how to handle the old
    >> >> >> resource if the user distributes the new resourc= e which is an
    >> >> >> updated
    >> >> >> copy of the old resource."
    >> >> >>
    >> >> >> Why does this need to be handled in the requirem= ents?  Are you
    >> >> >> trying
    >> >> >> to draw the distinction between immediate deleti= on of content and
    >> >> >> lazy
    >> >> >> deletion?
    >> >> >>
    >> >> > i mean the meaning of delete operation and how to ha= ndle the expired
    >> >> > records need to be clarify in requirements.
    >> >>
    >> >> My inclination is that "deleted" means that oth= er requests the object
    >> >> of the same name should result an error, until another ob= ject with the
    >> >> same name is stored.
    >> >
    >> > okay, under the scenario "client uploads the new version= , and did not
    >> > specify how to handle the old version", did DECADE serve= r delete the
    >> > older
    >> > version (or just label it unavailable, anyway, it is implemen= tation
    >> > issue )
    >> > or not ? in another word, just replace the older version with= the new
    >> > version with the same name?
    >>
    >> In this case, I would think the "write" of the new objec= t should be
    >> rejected, or if desired, we could have an overwrite option.  = This
    >> could be added to the requirements if it helps to clarify.
    >> yep, no matter which solution is chosen, let the understanding
    >> unanimously:D
    >> > how to handle the older version which is
    >> > transferring from server to client?
    >>
    >> I think it would be cleaner to ask the server to continue sending = an
    >> object once it has been started, but ultimately this would be the<= br> >> decision of the server's implementation I think.  Maybe a= "SHOULD"
    >> requirement.  This could be added if desired.
    >>
    > Thank you for these questions.  It helps design the requirements = more
    > cleanly if there are specific scenarios in front of us :)
    > just discussion together:D and also thanks for your points to help me<= br> > understanding more!

    Thanks,
    Rich

    >> Rich
    >>
    >> >> I think that the time the data is removed from disk (or m= emory) should
    >> >> be up to the implementation. A storage provider might sti= ll have as
    >> >> part of some agreement that deleted data will be removed = within X
    >> >> days/hours/minutes/whatever.
    >> >
    >> >    agree with you.
    >> >>
    >> >> If people in the WG think it is necessary, we could have = a requirement
    >> >> that says the protocol should support an argument indicat= ing immediate
    >> >> deletion, but it is not clear that we need this.
    >> >>
    >> >> Rich
    >> >>
    >> >> >>
    >> >> >> Thanks!
    >> >> >> Rich
    >> >> >>
    >> >> >>
    >> >> >> On Mon, Dec 27, 2010 at 12:57 AM, =D6=EC=E4=EC &= lt;buptxiaozhu@g= mail.com> wrote:
    >> >> >> > Dear all,
    >> >> >> >
    >> >> >> > There is a slightly updated version of the = decade additional
    >> >> >> > requirements
    >> >> >> > draft.
    >> >> >> >
    >> >> >> >
    >> >> >> > https://datat= racker.ietf.org/doc/draft-zhu-decade-additional-requirements/
    >> >> >> >
    >> >> >> > Jin Peng, Yunfei Zhang and me are expecting= to have a discussion
    >> >> >> > with
    >> >> >> > all of
    >> >> >> > you.
    >> >> >> >
    >> >> >> > Any comments are appreciated!
    >> >> >> >
    >> >> >> > A new version of I-D,
    >> >> >> > draft-zhu-decade-additional-requirements-00= .txt
    >> >> >> > has been successfully submitted by Xiao Zhu= and posted to the IETF
    >> >> >> > repository.
    >> >> >> >
    >> >> >> > Filename:      draft-zhu-dec= ade-additional-requirements
    >> >> >> > Revision:      00
    >> >> >> > Title:           &= nbsp;     Additional protocol requirements on DECADE
    >> >> >> > Creation_date:         = 2010-12-27
    >> >> >> > WG ID:           &= nbsp;     Independent Submission
    >> >> >> > Number_of_pages: 10
    >> >> >> >
    >> >> >> > Abstract:
    >> >> >> > The DECoupled Application Data Enroute(DECA= DE)working group is
    >> >> >> > specifying standardized interfaces for acce= ssing in-network
    >> >> >> > storage
    >> >> >> > from applications to store, retrieve and ma= nage data. The main
    >> >> >> > object
    >> >> >> > is to provide a framework that is useful to= the applications,
    >> >> >> > including P2P applications and other data-o= riented applications,
    >> >> >> > possibly related applications that can bene= fit from accessing in-
    >> >> >> > network storage. This memo focuses on some = requirements such as
    >> >> >> > request redirecting and so on which are on = the central of
    >> >> >> > mobility,
    >> >> >> > wireless network environment and CDN applic= ation. We present these
    >> >> >> > in
    >> >> >> > this memo as additional requirements that s= hould be considered for
    >> >> >> > the DECADE architecture and protocol specif= ications.
    >> >> >> >
    >> >> >> >
    >> >> >> >
    >> >> >> > The IETF Secretariat.
    >> >> >> >
    >> >> >> > --
    >> >> >> > Best wishes,
    >> >> >> >
    >> >> >> > Beijing University of Posts & Telecommu= nications (BUPT)
    >> >> >> > Zhu Xiao  ( =D6=EC=E4=EC )
    >> >> >> > E-mail: buptxiaozhu@gmail.com
    >> >> >> > mobile:+86 134-8881-9004
    >> >> >> >
    >> >> >> > ___________________________________________= ____
    >> >> >> > decade mailing list
    >> >> >> > decade@ietf.org
    >> >> >> > https://www.ietf.org/mailman/listinfo/decad= e
    >> >> >> >
    >> >> >> >
    >> >> >
    >> >> >
    >> >> >
    >> >> > --
    >> >> > Best wishes,
    >> >> >
    >> >> > Beijing University of Posts & Telecommunications= (BUPT)
    >> >> > Zhu Xiao  ( =D6=EC=E4=EC )
    >> >> > E-mail: buptxiaozhu@gmail.com
    >> >> > mobile:+86 134-8881-9004
    >> >
    >> >
    >> >
    >> > --
    >> > Best wishes,
    >> >
    >> > Beijing University of Posts & Telecommunications (BUPT) >> > Zhu Xiao  ( =D6=EC=E4=EC )
    >> > E-mail: buptxiaozhu@gmail.com
    >> > mobile:+86 134-8881-9004
    >> >
    >
    >
    >
    > --
    > Best wishes,
    >
    > Beijing University of Posts & Telecommunications (BUPT)
    > Zhu Xiao  ( =D6=EC=E4=EC )
    > E-mail: bup= txiaozhu@gmail.com
    > mobile:+86 134-8881-9004
    >



    --
    Best wishes,

    Beijing University of Posts & Telecommunicati= ons (BUPT)
    Zhu Xiao  ( =D6=EC=E4=EC )
    E-mail: buptxiaozhu@gmail.com
    mobile:+86 134-8881-9004

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





    --
    Best wishes,

    Bei= jing University of Posts & Telecommunications (BUPT)
    Zhu Xiao  = ( =D6=EC=E4=EC )
    E-mail: buptxiaozhu@gmail.com
    mobile:+86 134-8881-9004
    --bcaec51d21d0e5671a049e5a6240-- --bcaec51d21d0e5671f049e5a6241 Content-Type: image/gif; name="1A5.gif" Content-Transfer-Encoding: base64 X-Attachment-Id: 1A5@goomoji.gmail Content-ID: <1A5@goomoji.gmail> R0lGODlhEAAMAKIFAF5LAP/zxAAAANyuAP/gaP///wAAAAAAACH/C05FVFNDQVBFMi4wAwEAAAAh +QQJZAAFACwAAAAAEAAMAAADO1iq0/6LhUkBmCOOQLonAJEtGyEI3dmNkom6q8Z9H1sML22OTnC+ P9GNU9LFBquZJxS7NWYWZpP0qBYSACH5BAkKAAUALAAAAAAQAAwAAAM7WKrT/ouFSQGYI45AuicA kS0bIQjd2Y2Sibqrxn0fWwwvbbJNcL4/UWug84yIIlooxiiBLLXI7UEtJAAAIfkECQoABQAsAAAA ABAADAAAAzhYqtP+i4VJAZgjjkC6JwCRLRshCN3ZjZKJuqvGfR9bNLQnsOWguijeKhcjDWihYgtk qUVuj2ghAQAh+QQFCgAFACwAAAAAEAAMAAADN1iq0/6LhUkBmCOOQLonAJEtGyEI3dmNkom6q8Z9 H1s4dGqXw3uiu1VOpGl8QjHSzIJMkh7QQgIAIfkEBRQABQAsAAAFAAgABQAAAxFYMxpEwy0H3xBY KBZf+c2TAAAh+QQFCgAFACwEAAYABQACAAADBlgqMkEqAQAh+QQFAAAFACwGAAYAAwACAAADBChE 0gkAIfkECQoABQAsAAAFAAcAAgAAAwVYuqxCCQAh+QQJCgAFACwAAAAAEAAMAAADGFi63P4wyknd CESOUYbIUVB1BMFR26iuCQAh+QQFkAEFACwAAAAAEAAMAAADO1iq0/6LhUkBmCOOQLonAJEtGyEI 3dmNkom6q8Z9H1sML22OTnC+P9GNU9LFBquZJxS7NWYWZpP0qBYSADs= --bcaec51d21d0e5671f049e5a6241-- From buptxiaozhu@gmail.com Sun Mar 13 04:54:43 2011 Return-Path: X-Original-To: decade@core3.amsl.com Delivered-To: decade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0EA1E3A68BA for ; Sun, 13 Mar 2011 04:54:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.372 X-Spam-Level: **** X-Spam-Status: No, score=4.372 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, J_CHICKENPOX_42=0.6, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1, SARE_GIF_ATTACH=1.42] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B7aQRtaIr76H for ; Sun, 13 Mar 2011 04:54:38 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id AB3233A688B for ; Sun, 13 Mar 2011 04:54:37 -0700 (PDT) Received: by iyi12 with SMTP id 12so1142950iyi.31 for ; Sun, 13 Mar 2011 04:55:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references :x-goomoji-body:date:message-id:subject:from:to:cc:content-type; bh=JAl4RzjYTauw2z3gFNld/g9cRo+vZIHa+PcB8P7HwCA=; b=Sy3CLKUVhQn0sMG36k8cFa9NnB3dxqlIMZ27dKTEH4ivS//gUBjK0P7LKD6LBt3JYx q3mR5P/9Tmdd623wpJoTnb+xb1s/Wlee40SR5kdZmfrQGPJfgJWG07firfLDnPNEqLdY oJ5nyI1wWmD0IxHSBNBRs6uZA1oA+bPk5xrtI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:x-goomoji-body:date:message-id :subject:from:to:cc:content-type; b=FaFsq512nqpTrBM1Gkw/WTMAGdbGjKWgsOTpEBhYQWEsO5RAYQ12orLp16JA7SN7nf nSl+M9PpZ2rUhYg+JtZIy3RWAZwMT+KVMU9mYZ2fpo4hXQtT3KMKF2rRTW+KAaKzKe5n h2IQAu+zSFACo/weKS7HUvMdBjdSfTWzj7Wa0= MIME-Version: 1.0 Received: by 10.42.232.205 with SMTP id jv13mr298428icb.441.1300017358399; Sun, 13 Mar 2011 04:55:58 -0700 (PDT) Received: by 10.42.147.66 with HTTP; Sun, 13 Mar 2011 04:55:58 -0700 (PDT) In-Reply-To: References: X-Goomoji-Body: true Date: Sun, 13 Mar 2011 19:55:58 +0800 Message-ID: From: =?GB2312?B?1uzk7A==?= To: Richard Alimi Content-Type: multipart/related; boundary=00235444785dd96ff8049e5be0b9 Cc: decade@ietf.org Subject: Re: [decade] draft-zhu-decade-additional-requirements X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.9 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, 13 Mar 2011 11:54:43 -0000 --00235444785dd96ff8049e5be0b9 Content-Type: multipart/alternative; boundary=00235444785dd96ff2049e5be0b8 --00235444785dd96ff2049e5be0b8 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable hi, Richard: The in-network storage MAY use optimizations to avoid such authorization checks as long as the enforced permissions are the the same. right? i see! many thx[?]! 2011/3/13 Richard Alimi > 2011/3/6 =D6=EC=E4=EC > >> Hi, Richard: >> >> sorry for reply so late, because i should remember what we >> are dissuasion and the key of the problem[?] >> >> >> so many quoted texts, let me make a summarize. >> >> 1 multi connection, i have the arguments as followings: >> >> @me: >> >> >> - need it to process new authentication and authorization after the >> user moves in the wireless environment and access a new DECADE server >> >> @you: >> >> - DECADE server should need to do some sort of check on each new >> connection, regardless of whether the user has or previously had a >> connection open to a different DECADE server, >> >> --> okay, agree with you, but we should specify in the requirements draf= t. >> >> > Can you point out what, if anything, should be added to the existing > requirement? The intent was to specify this, but note that the existing > text does this at the request level instead of connections. The notion o= f > when to drop an connection seems like an implementation detail to me. > > The existing text is here: > http://tools.ietf.org/html/draft-ietf-decade-reqs-00#section-4.1.6.3 > > Thanks! > Rich > > >> @me: >> >> - considering the service continuity, the next serving DECADE server >> should know the progress of the service, how does they know?or >> different servers need to coordinate and schedule each other to fulfi= ll the >> user request? >> >> @you: >> >> >> - that does not mean that there can't be additional protocol(s) (not >> specified here) that are used between DECADE servers as well. and The >> IAP in the problem statement is intended to describe data transfer be= tween >> DECADE servers. >> >> -> basically agree with you, a question reminds me that "IAP means in t= he >> media layer=A3=BF and signalling or controlling layer protocol may be ne= eded to >> solve the problem? and we can reuse the other protocol to fulfill the >> storing status transfer. and we should consider to update the draft to a= dd >> the permission requirement and retrieve the client status about getting = and >> writing storage. >> >> 2 Service Assurance >> >> -> basically agree with you, keep tracking the status of the DCADE serve= r >> may also bring the additional burden to the overloaded DECADE server. >> >> 2011/3/3 Richard Alimi >> >>> Hi Xiao, >>> >>> Sorry for the delay. Finally coming back to this. >>> >>> 2011/1/16 =D6=EC=E4=EC : >>> > hi, Richard: >>> > thanks for your reply:D >>> > additional discussion see inline:D >>> > 2011/1/14 Richard Alimi >>> >> >>> >> HI Xiao, >>> >> >>> >> 2011/1/12 =D6=EC=E4=EC : >>> >> > hi, Richard >>> >> > see inline:D >>> >> > >>> >> > 2011/1/11 Richard Alimi >>> >> >> >>> >> >> Hi Xiao, >>> >> >> >>> >> >> On Mon, Jan 10, 2011 at 6:45 PM, =D6=EC=E4=EC wrote: >>> >> >> > >>> >> >> > hi, Richard, sorry for so late response because of be busy with >>> other >>> >> >> > projects. >>> >> >> > some discussion see inline:D marked by red. >>> >> >> > >>> >> >> > On Tue, Jan 4, 2011 at 4:06 AM, Richard Alimi < >>> rich@velvetsea.net> >>> >> >> > wrote: >>> >> >> >> >>> >> >> >> Hi Xiao, >>> >> >> >> >>> >> >> >> Thank you for the draft. Some comments on the requirements: >>> >> >> >> >>> >> >> >> Request Redirects: >>> >> >> >> >>> >> >> >> This would provide some additional freedom for the storage >>> provider. >>> >> >> >> I think it is reasonable since it doesn't necessitate addition= al >>> >> >> >> complexity for the DECADE server, but allows it if desired. >>> However, >>> >> >> >> note that it may complicate some of the other components of th= e >>> >> >> >> design. In particular, if there is a per-user quota for storag= e, >>> is >>> >> >> >> the user made aware of the quota at each in-network storage (i= f >>> >> >> >> there >>> >> >> >> is no shared storage between them)? Resource sharing policies >>> may >>> >> >> >> be >>> >> >> >> impacted (e.g., if a bandwidth sharing weight of 1 may mean >>> >> >> >> something >>> >> >> >> different at DECADE server A than it does at DECADE server B). >>> At >>> >> >> >> this point it may be best to just note these so they are >>> documented, >>> >> >> >> but since the specification of the resource sharing policies a= re >>> >> >> >> still >>> >> >> >> being contemplated for the basic case of a single server it ma= y >>> be >>> >> >> >> premature to even try and solve them for the case supporting >>> >> >> >> redirection. >>> >> >> >> >>> >> >> > actually, you mean two points, right? >>> >> >> > 1. whether or not to be ware of the content at each in-network >>> >> >> > storage >>> >> >> > and of course resource sharing policies can be impact in the >>> request >>> >> >> > redirection. your suggestion"just to note these so they are >>> >> >> > documented" will >>> >> >> > be ok, or DECADE server list with some parameters will be retur= n >>> for >>> >> >> > user to >>> >> >> > select the appropriate DECADE server, which can avoid the >>> different >>> >> >> > weighted >>> >> >> > of the same parameter in server decision. but the parameter use= d >>> in >>> >> >> > select >>> >> >> > the best DECADE server will be known for DECADE servers, in whi= ch >>> >> >> > other >>> >> >> > complexities will be added. anyway, all the solution are the >>> >> >> > implementation >>> >> >> > issue, which, i believe, does not impact the necessity of the >>> >> >> > requirement. >>> >> >> >>> >> >> In general, I'd agree that the decision about where to redirect >>> would >>> >> >> be an implementation issue. >>> >> >> >>> >> >> > >>> >> >> > 2. you mean "the resource sharing policies are still being >>> considered >>> >> >> > in >>> >> >> > a single server", so it may be premature to support redirection= . >>> the >>> >> >> > architecture and protocol will be badly impacted if the >>> requirements >>> >> >> > change. >>> >> >> > so the designing can be taken step by step, but the >>> requirements >>> >> >> > should be >>> >> >> > overall considered. >>> >> >> >>> >> >> I said that it is probably premature to consider how resource >>> sharing >>> >> >> policies works across servers (or even if we need to say anything >>> >> >> about it) since we have not determined how to specify them (or >>> rather, >>> >> >> how little we need to specify in protocol) for a single server. I >>> did >>> >> >> not mean to imply that redirection could not be introduced as a >>> >> >> requirement. >>> >> >> >>> >> > >>> >> >> >>> >> >> > >>> >> >> > >>> >> >> >> >>> >> >> >> Multi-connection: >>> >> >> >> >>> >> >> >> I'm not quite clear on the intention of the requirement. My >>> >> >> >> understanding is that you wish the client to be able to have >>> >> >> >> multiple >>> >> >> >> connections open spanning multiple DECADE servers. Is that >>> correct? >>> >> >> >> >>> >> >> >> If so, do we need this stated as a requirement or the protocol= ? >>> Or >>> >> >> >> is >>> >> >> >> this a policy that would be allowed/disallowed by the storage >>> >> >> >> provider? >>> >> >> >> >>> >> >> > yep, your understanding is right, the scenarios were just >>> described >>> >> >> > in >>> >> >> > draft as "soft handover in wireless environment and delete >>> operation >>> >> >> > in >>> >> >> > multi-servers". under these consideration, the authentication a= nd >>> >> >> > authorization need to be taken each time when setup connection >>> with a >>> >> >> > new >>> >> >> > DECADE server, or just be taken only once during the service? >>> >> >> >>> >> >> The DECADE server should need to do some sort of check on each ne= w >>> >> >> connection, regardless of whether the user has or previously had = a >>> >> >> connection open to a different DECADE server, right? Note that t= he >>> >> >> requirements don't indicate how authentication or authorization i= s >>> >> >> done, and allow a server to make optimizations if it is enforcing >>> the >>> >> >> same permissions. >>> >> >> >>> >> >> Can you indicate where the existing authorization-related >>> requirements >>> >> >> (in particular, 4.1.6.3 of draft-ietf-decade-reqs-00) do not >>> suffice >>> >> >> for the use case you are thinking of? >>> >> >>> >> > as considering the service continuity, the next serving DECADE >>> server >>> >> > should know the progress of the service, how does they know? >>> >> >>> >> By progress of the service, do you mean current user state (e.g., >>> >> quota, recent resource usage history, permissions, etc)? >>> >>> > yes, and include data delivery proceeding. >>> >>> I still don't think I understand what you are suggesting as new >>> requirements here. Why can't the client retry any failed requests? >>> >>> >> > so if the >>> >> > service proceeding information should be known by the next serving >>> >> > server, >>> >> > or different servers need to coordinate and schedule each other to >>> >> > fulfill >>> >> > the user request, i believe the the 4.1.6.3 of the >>> >> > draft-ietf-decade-req-00 >>> >> > cannot satisfy the req. what do you think about? >>> >> >>> >> Note that the protocol that is covered here is the client-server >>> >> protocol. Some of the same protocol may be useful between DECADE >>> >> servers (especially in different administrative domains) for storing >>> >> and retrieving data, but that does not mean that there can't be >>> >> additional protocol(s) (not specified here) that are used between >>> >> DECADE servers as well. For example, if DECADE servers within an >>> >> administrative domain can certainly have their own mechanism to shar= e >>> >> such information. If such capabilities were included in the DECADE >>> >> protocol (e.g., a need to do this between administrative domains), >>> >> that sounds like lots more complexity that we need at this point. >>> >>> > but the access between in-network storage also is included in IAP >>> > described in problem statement. i mean why not put this kind of >>> function in >>> > DECADE since the IAP is defined just like that? >>> >>> The IAP in the problem statement is intended to describe data transfer >>> between DECADE servers. I think the discussion above relates to >>> storing state about the progress of delivering data to DECADE clients. >>> Is that an accurate summary? If so, then the point of DECADE is that >>> this is managed and controlled by the clients. I don't think it makes >>> sense to add additional state in to DECADE servers for this. >>> >>> >> That said, it sounds to me like what is described in 4.1.6.3 would b= e >>> >> sufficient (from the perspective of the client-server protocol, >>> >> anyways) to implement what you're describing. If not, what >>> >> specifically is missing and what use-case does it not meet? >>> >>> > so you mean the information you mentioned above, just like current us= er >>> > state (e.g., >>> > quota, recent resource usage history, permissions, etc) was already >>> > included in DECADE requirement? what about the data delivery proceedi= ng >>> > information? can you specify the chapter for me ? thanks? >>> >>> Historical information is not specified, but I can't think of another >>> storage protocol off the top of my head that provides this. >>> >>> Quota/resource usage is in Section 5.1.6. Permissions, if applicable, >>> should be there too (we will update the doc to state this). >>> >>> For data delivery, I see value in getting status about other client >>> that may have open connections or active transfers (reads or writes) >>> to one's storage. This could probably be added as a requirement. >>> >>> However, if the expectation is for DECADE servers to somehow >>> coordinate (e.g., picking a data path, resuming/retrying failed >>> transfers, etc), then this is going towards delay-tolerant networking >>> or CDNs. DECADE is not intended for that. >>> >>> >> >> > >>> >> >> > >>> >> >> >> >>> >> >> >> Data Distribution: >>> >> >> >> >>> >> >> >> I'm also confused about the intent of this requirement. This >>> >> >> >> statement has me somewhat worried: "The distribution is >>> transparent >>> >> >> >> to >>> >> >> >> the users as they interact with the in-network storage as a >>> single >>> >> >> >> logical system." Does this mean that you are proposing for >>> DECADE >>> >> >> >> servers to assume the responsibility for deciding how data is = to >>> be >>> >> >> >> distributed throughout the network, including the path of the >>> data, >>> >> >> >> which servers act as intermediate caches, content expiration >>> >> >> >> policies, >>> >> >> >> etc? If this is true, I think it is missing one of the major >>> points >>> >> >> >> of DECADE. In particular, these decisions are >>> application-dependent >>> >> >> >> and are not implemented within DECADE. Instead, DECADE provide= s >>> the >>> >> >> >> basic capabilities and the functionality described above are >>> >> >> >> implemented by the applications using DECADE. >>> >> >> >> >>> >> >> >> Or, am I misinterpreting the intent of the requirement? >>> >> >> >> >>> >> >> > you mean DECADE provides the basic capabilities, so can you giv= e >>> some >>> >> >> > specify explanations on DECADE capabilities in supporting data >>> >> >> > distribution? >>> >> >> >> >>> >> >> >>> >> >> The problem statement gives a couple of scenarios. The "Integrati= on >>> >> >> Examples" presentation from IETF 79 also has more details of an >>> >> >> on-going effort at Yale. >>> >> >>> >> > okay, thx for your information, i will lookup and refer, actually, >>> the >>> >> > content publisher described in problem statement remind me of the >>> >> > protocol requirements which i did not find in >>> draft-ietf-decade-reqs-00 >>> >> > to >>> >> > support content publish. or i miss some points? >>> >> >>> >> Which requirements do you think are missing? >>> >> >>> >> >> >> Service Assurance: >>> >> >> >> >>> >> >> >> It seems problematic to include "assurance" in a DECADE. >>> Shouldn't >>> >> >> >> these instead be part of SLAs with a storage provider? Why >>> should >>> >> >> >> they be DECADE's responsibility? >>> >> >> >> >>> >> >> >> Regarding "resource reservation", are you referring to an actu= al >>> >> >> >> reservation (which might be problematic -- see above) or do yo= u >>> mean >>> >> >> >> that the resource share should able to be specified at the tim= e >>> the >>> >> >> >> connection opens and be assumed to be the same for the duratio= n >>> of >>> >> >> >> the >>> >> >> >> connection? >>> >> >> >> >>> >> >> >> Regarding Dynamic Feedback, is this orthogonal to the storage >>> >> >> >> protocol? It seems like what you want here is a generic >>> "status" >>> >> >> >> service saying how loaded a server is? >>> >> >> >> >>> >> >> > thats right, actually, the flow control mechanism was under >>> >> >> > discussion >>> >> >> > in writing the draft at first. what about your opinion in this >>> >> >> > requirements? >>> >> >> > >>> >> >> >>> >> >> I'm not sure what the typical way of providing such "load status" >>> >> >> information for IETF protocols, but my inclination is that it >>> should >>> >> >> not be in the DECADE protocol itself. Maybe someone else with a >>> >> >> longer history in IETF could jump in here :) >>> >> > so can i understand that "load status" is kind of necessity >>> information >>> >> > for DECADE Server, but where and who collects the information are >>> >> > remain discussion? >>> >> >>> >> The storage provider is free to collect the information wherever and >>> >> however they wish. The DECADE server implementation could additiona= l >>> >> export whatever status information it wishes. I don't think the DECA= DE >>> >> protocol needs to be concerned with that. >>> >> >>> >> Note that certain error conditions (e.g., overload, insufficient >>> >> resources) may be signaled by a DECADE server (there are already hav= e >>> >> requirements for those). If you are referring to status for a user'= s >>> >> resources, there is already a requirement for that too. >>> >> >>> >> I'm just not convinced that the DECADE protocol needs to export its >>> >> current load status to clients. >>> >>> > actually i am not sure which elements in DECADE needs the load >>> > status,(DECADE client or network storage if the network storage needs >>> to >>> > redirect the request or both?). >>> > And the requirement draft currently seems describe the overload >>> condition >>> > as the event triggering. do you think if it is necessary to >>> periodically >>> > reporting of the DECADE network status to client for its network >>> storage >>> > selection? >>> >>> No I don't think this is necessary. The client can retry the request >>> at a later time (e.g., exponential backoff). Note that asking a >>> heavily-loaded DECADE server to also keep track of clients that need >>> to be notified, and keep them updated of the current status, is >>> probably counter-productive. >>> >>> > and the requirement draft just describe DECADE which is busy to serve >>> > other requests must be able to reject requests, not consider how to >>> handle >>> > the user request after being rejected? >>> >>> That's the implementation's decision. I suspect most would drop it on t= he >>> floor. >>> >>> >> >> >> >>> >> >> >> Data classification: >>> >> >> >> >>> >> >> >> Would it be better to instead have the client specify properti= es >>> of >>> >> >> >> the content instead of place it into ? See >>> >> >> >> www.ietf.org/proceedings/78/slides/nfsv4-0.pdf for an example >>> of >>> >> >> >> this >>> >> >> >> approach for NFS. >>> >> >> >> >>> >> >> >> I think a problem with classifying applications is that it >>> assumes >>> >> >> >> that applications fit one of the supplied classifications. Wha= t >>> if >>> >> >> >> it >>> >> >> >> may fit multiple classifications? or none? Another problem is >>> it >>> >> >> >> assumes that servers assume based on indirect and assumed >>> >> >> >> information >>> >> >> >> that they know what to do with a particular piece of content. >>> Why >>> >> >> >> not >>> >> >> >> have an application specify its desires directly? >>> >> >> >> >>> >> >> > >>> >> >> > >>> >> >> >> >>> >> >> >> Small Objects: >>> >> >> >> >>> >> >> >> What is the new requirement here? Why is the existing >>> requirement >>> >> >> >> in >>> >> >> >> draft-ietf-decade-reqs-00 insufficient? >>> >> >> >> >>> >> >> >> This also has me a bit worried: >>> >> >> >> "And the in-network storage has the limited storage capacity, >>> with >>> >> >> >> the >>> >> >> >> arrival of user requests and data distribution requirements, t= he >>> >> >> >> data >>> >> >> >> stored in the in-network storage will be replaced if the stora= ge >>> >> >> >> reaches the limit and data arrivals continually." >>> >> >> >> >>> >> >> >> How does the server know what the proper replacement strategy = is >>> for >>> >> >> >> an application? I think DECADE's philosophy is that applicatio= ns >>> >> >> >> should decide this. A simple way to do this is explicit deleti= on >>> by >>> >> >> >> an >>> >> >> >> application, but perhaps a more efficient (yet more complex) >>> >> >> >> solution >>> >> >> >> is for an application to specify the replacement policy to the >>> >> >> >> server. >>> >> >> >> >>> >> >> > actually, the key in "the data classification and small objects= " >>> is >>> >> >> > whether does it or not in P2P application? i did not find data >>> >> >> > classification was adopted in P2P application so far, let alone >>> >> >> > DECADE need >>> >> >> > to classify the data used in all kinds of application. >>> >> >> > >>> >> >> >>> >> >> So, do you agree that it is problematic to try and classify each >>> type >>> >> >> of application and try to specify the typical workload for each >>> class? >>> >> >> >>> >> >> My point was that I don't think its necessary to do the >>> classification >>> >> >> at all. It is more extensible (and directly useful) for a server >>> to >>> >> >> just give it direct hints about what would be preferable. >>> >> > >>> >> > yep, i believe it may be a little difficult, but worthy doing. >>> specially >>> >> > for improving the resource utilization within a single server and >>> >> > reducing >>> >> > the response time for client. what about others opinion? >>> >> >>> >> Can you justify why giving classifications (e.g., "I'm a live >>> >> streaming application") would be better than giving specific hints >>> >> (e.g., "please don't bother persistent these objects to disk")? >>> > >>> > i mean data in different kind of operation mode and attribute should >>> have >>> > different user patterns and storage rules, which may be help to impro= ve >>> the >>> > resource utilization and reduce the response time for request, what a= re >>> you >>> > understanding? >>> >>> That's fine. Explicit and more-specific hints are a different way to >>> accomplish the same thing, and seem to be a much better design to me. >>> They are simpler from an extensibility and implementation point of >>> view. >>> >>> >> > >> >>> >> >> >> Removal of Expired Records: >>> >> >> >> >>> >> >> >> "However, the two scenarios did not mention how to handle the >>> old >>> >> >> >> resource if the user distributes the new resource which is an >>> >> >> >> updated >>> >> >> >> copy of the old resource." >>> >> >> >> >>> >> >> >> Why does this need to be handled in the requirements? Are you >>> >> >> >> trying >>> >> >> >> to draw the distinction between immediate deletion of content >>> and >>> >> >> >> lazy >>> >> >> >> deletion? >>> >> >> >> >>> >> >> > i mean the meaning of delete operation and how to handle the >>> expired >>> >> >> > records need to be clarify in requirements. >>> >> >> >>> >> >> My inclination is that "deleted" means that other requests the >>> object >>> >> >> of the same name should result an error, until another object wit= h >>> the >>> >> >> same name is stored. >>> >> > >>> >> > okay, under the scenario "client uploads the new version, and did >>> not >>> >> > specify how to handle the old version", did DECADE server delete t= he >>> >> > older >>> >> > version (or just label it unavailable, anyway, it is implementatio= n >>> >> > issue ) >>> >> > or not ? in another word, just replace the older version with the >>> new >>> >> > version with the same name? >>> >> >>> >> In this case, I would think the "write" of the new object should be >>> >> rejected, or if desired, we could have an overwrite option. This >>> >> could be added to the requirements if it helps to clarify. >>> >> yep, no matter which solution is chosen, let the understanding >>> >> unanimously:D >>> >> > how to handle the older version which is >>> >> > transferring from server to client? >>> >> >>> >> I think it would be cleaner to ask the server to continue sending an >>> >> object once it has been started, but ultimately this would be the >>> >> decision of the server's implementation I think. Maybe a "SHOULD" >>> >> requirement. This could be added if desired. >>> >> >>> > Thank you for these questions. It helps design the requirements more >>> > cleanly if there are specific scenarios in front of us :) >>> > just discussion together:D and also thanks for your points to help me >>> > understanding more! >>> >>> Thanks, >>> Rich >>> >>> >> Rich >>> >> >>> >> >> I think that the time the data is removed from disk (or memory) >>> should >>> >> >> be up to the implementation. A storage provider might still have = as >>> >> >> part of some agreement that deleted data will be removed within X >>> >> >> days/hours/minutes/whatever. >>> >> > >>> >> > agree with you. >>> >> >> >>> >> >> If people in the WG think it is necessary, we could have a >>> requirement >>> >> >> that says the protocol should support an argument indicating >>> immediate >>> >> >> deletion, but it is not clear that we need this. >>> >> >> >>> >> >> Rich >>> >> >> >>> >> >> >> >>> >> >> >> Thanks! >>> >> >> >> Rich >>> >> >> >> >>> >> >> >> >>> >> >> >> On Mon, Dec 27, 2010 at 12:57 AM, =D6=EC=E4=EC >>> wrote: >>> >> >> >> > Dear all, >>> >> >> >> > >>> >> >> >> > There is a slightly updated version of the decade additional >>> >> >> >> > requirements >>> >> >> >> > draft. >>> >> >> >> > >>> >> >> >> > >>> >> >> >> > >>> https://datatracker.ietf.org/doc/draft-zhu-decade-additional-requiremen= ts/ >>> >> >> >> > >>> >> >> >> > Jin Peng, Yunfei Zhang and me are expecting to have a >>> discussion >>> >> >> >> > with >>> >> >> >> > all of >>> >> >> >> > you. >>> >> >> >> > >>> >> >> >> > Any comments are appreciated! >>> >> >> >> > >>> >> >> >> > A new version of I-D, >>> >> >> >> > draft-zhu-decade-additional-requirements-00.txt >>> >> >> >> > has been successfully submitted by Xiao Zhu and posted to th= e >>> IETF >>> >> >> >> > repository. >>> >> >> >> > >>> >> >> >> > Filename: draft-zhu-decade-additional-requirements >>> >> >> >> > Revision: 00 >>> >> >> >> > Title: Additional protocol requirements on >>> DECADE >>> >> >> >> > Creation_date: 2010-12-27 >>> >> >> >> > WG ID: Independent Submission >>> >> >> >> > Number_of_pages: 10 >>> >> >> >> > >>> >> >> >> > Abstract: >>> >> >> >> > The DECoupled Application Data Enroute(DECADE)working group = is >>> >> >> >> > specifying standardized interfaces for accessing in-network >>> >> >> >> > storage >>> >> >> >> > from applications to store, retrieve and manage data. The ma= in >>> >> >> >> > object >>> >> >> >> > is to provide a framework that is useful to the applications= , >>> >> >> >> > including P2P applications and other data-oriented >>> applications, >>> >> >> >> > possibly related applications that can benefit from accessin= g >>> in- >>> >> >> >> > network storage. This memo focuses on some requirements such >>> as >>> >> >> >> > request redirecting and so on which are on the central of >>> >> >> >> > mobility, >>> >> >> >> > wireless network environment and CDN application. We present >>> these >>> >> >> >> > in >>> >> >> >> > this memo as additional requirements that should be consider= ed >>> for >>> >> >> >> > the DECADE architecture and protocol specifications. >>> >> >> >> > >>> >> >> >> > >>> >> >> >> > >>> >> >> >> > The IETF Secretariat. >>> >> >> >> > >>> >> >> >> > -- >>> >> >> >> > Best wishes, >>> >> >> >> > >>> >> >> >> > Beijing University of Posts & Telecommunications (BUPT) >>> >> >> >> > Zhu Xiao ( =D6=EC=E4=EC ) >>> >> >> >> > E-mail: buptxiaozhu@gmail.com >>> >> >> >> > mobile:+86 134-8881-9004 >>> >> >> >> > >>> >> >> >> > _______________________________________________ >>> >> >> >> > decade mailing list >>> >> >> >> > decade@ietf.org >>> >> >> >> > https://www.ietf.org/mailman/listinfo/decade >>> >> >> >> > >>> >> >> >> > >>> >> >> > >>> >> >> > >>> >> >> > >>> >> >> > -- >>> >> >> > Best wishes, >>> >> >> > >>> >> >> > Beijing University of Posts & Telecommunications (BUPT) >>> >> >> > Zhu Xiao ( =D6=EC=E4=EC ) >>> >> >> > E-mail: buptxiaozhu@gmail.com >>> >> >> > mobile:+86 134-8881-9004 >>> >> > >>> >> > >>> >> > >>> >> > -- >>> >> > Best wishes, >>> >> > >>> >> > Beijing University of Posts & Telecommunications (BUPT) >>> >> > Zhu Xiao ( =D6=EC=E4=EC ) >>> >> > E-mail: buptxiaozhu@gmail.com >>> >> > mobile:+86 134-8881-9004 >>> >> > >>> > >>> > >>> > >>> > -- >>> > Best wishes, >>> > >>> > Beijing University of Posts & Telecommunications (BUPT) >>> > Zhu Xiao ( =D6=EC=E4=EC ) >>> > E-mail: buptxiaozhu@gmail.com >>> > mobile:+86 134-8881-9004 >>> > >>> >> >> >> >> -- >> Best wishes, >> >> Beijing University of Posts & Telecommunications (BUPT) >> Zhu Xiao ( =D6=EC=E4=EC ) >> E-mail: buptxiaozhu@gmail.com >> mobile:+86 134-8881-9004 >> > > --=20 Best wishes, Beijing University of Posts & Telecommunications (BUPT) Zhu Xiao ( =D6=EC=E4=EC ) E-mail: buptxiaozhu@gmail.com mobile:+86 134-8881-9004 --00235444785dd96ff2049e5be0b8 Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable hi, Richard:

    The in-network storage MAY use optimizations to avoid such a= uthorization checks
    as long as the enforced permissions are the the same.

    ri= ght? i see! many thx!

    2011/3/13 Richard Alimi <= ;rich@velvetsea.net= >
    2011/3/6 =D6=EC=E4=EC <= ;buptxiaozhu@gma= il.com>
    Hi, Richard:

    sorry for reply so late, because= i should remember what we are dissuasion and the key of the prob= lem


    so many quoted texts, let me make a = ;summarize.

    1 multi connection, i have the argumen= ts as followings:

    @me:

  • need it to process new authentication and authorization after the = user moves in the wireless environment and access a new DECADE se= rver
    • @you:
    • DECADE server should need to do some sort of check on= each new
       connection, regardless of whether the user has or previously had a connection open to a different DECADE server,
    =
    --> okay, agree with you, but we should specify in the r= equirements draft.


    Can you point out wha= t, if anything, should be added to the existing requirement?  The inte= nt was to specify this, but note that the existing text does this at the re= quest level instead of connections.  The notion of when to drop an con= nection seems like an implementation detail to me.

    The existing text is here:

    Thanks!
    Rich
     =
    @me:
    • considering the service continuity, the next serving  DECADE server
       should know the progress= of the service, how does they know?= or different servers need to coordinate and schedule each other to ful= fill the user request?
    @you:

    • that does = not mean that there can't be DECADE servers as well. and The IAP in the problem statement is intended to describe data = transfer between DECADE servers.
    -> basically agree with you,  a question reminds me= that "IAP means in the media layer=A3=BF and signalling or controllin= g layer protocol may be needed to solve the problem? and we can reuse the o= ther protocol to fulfill the storing status transfer. and we should conside= r to update the draft to add the permission requirement and retrieve&n= bsp;the client status about getting and writing storage. 

    2 Service Assurance

    -> basically agree with you, keep tra= cking the status of the DCADE server may also bring the additional&nbs= p;burden to the overloaded DECADE server.

    2011/3/3 Richard A= limi <rich@velvetsea.net>
    Hi Xiao,

    Sorry for the delay. Finally coming back to this.

    2011/1/16 =D6=EC=E4=EC <buptxiaozhu@gmail.com>:
    > hi, Richard:
    > thanks for your reply:D
    > additional discussion see inline:D
    > 2011/1/14 Richard Alimi <rich@velvetsea.net>
    >>
    >> HI Xiao,
    >>
    >> 2011/1/12 =D6=EC=E4=EC <buptxiaozhu@gmail.com>:
    >> > hi, Richard
    >> > see inline:D
    >> >
    >> > 2011/1/11 Richard Alimi <rich@velvetsea.net>
    >> >>
    >> >> Hi Xiao,
    >> >>
    >> >> On Mon, Jan 10, 2011 at 6:45 PM, =D6=EC=E4=EC <buptxiaozhu@gmail.com> wrote:
    >> >> >
    >> >> > hi, Richard, sorry for so late response because of b= e busy with other
    >> >> > projects.
    >> >> > some discussion see inline:D marked by red.
    >> >> >
    >> >> > On Tue, Jan 4, 2011 at 4:06 AM, Richard Alimi <rich@velvetsea.net>
    >> >> > wrote:
    >> >> >>
    >> >> >> Hi Xiao,
    >> >> >>
    >> >> >> Thank you for the draft.  Some comments on = the requirements:
    >> >> >>
    >> >> >> Request Redirects:
    >> >> >>
    >> >> >> This would provide some additional freedom for t= he storage provider.
    >> >> >> I think it is reasonable since it doesn't ne= cessitate additional
    >> >> >> complexity for the DECADE server, but allows it = if desired. However,
    >> >> >> note that it may complicate some of the other co= mponents of the
    >> >> >> design. In particular, if there is a per-user qu= ota for storage, is
    >> >> >> the user made aware of the quota at each in-netw= ork storage (if
    >> >> >> there
    >> >> >> is no shared storage between them)?  Resour= ce sharing policies may
    >> >> >> be
    >> >> >> impacted (e.g., if a bandwidth sharing weight of= 1 may mean
    >> >> >> something
    >> >> >> different at DECADE server A than it does at DEC= ADE server B).  At
    >> >> >> this point it may be best to just note these so = they are documented,
    >> >> >> but since the specification of the resource shar= ing policies are
    >> >> >> still
    >> >> >> being contemplated for the basic case of a singl= e server it may be
    >> >> >> premature to even try and solve them for the cas= e supporting
    >> >> >> redirection.
    >> >> >>
    >> >> > actually, you mean two points, right?
    >> >> > 1. whether or not to be ware of the content at each = in-network
    >> >> > storage
    >> >> > and of course resource sharing policies can be impac= t in the request
    >> >> > redirection. your suggestion"just to note these= so they are
    >> >> > documented" will
    >> >> > be ok, or DECADE server list with some parameters wi= ll be return for
    >> >> > user to
    >> >> > select the appropriate DECADE server, which can avoi= d the different
    >> >> > weighted
    >> >> > of the same parameter in server decision. but the pa= rameter used in
    >> >> > select
    >> >> > the best DECADE server will be known for DECADE serv= ers, in which
    >> >> > other
    >> >> > complexities will be added. anyway, all the solution= are the
    >> >> > implementation
    >> >> > issue, which, i believe, does not impact the necessi= ty of the
    >> >> > requirement.
    >> >>
    >> >> In general, I'd agree that the decision about where t= o redirect would
    >> >> be an implementation issue.
    >> >>
    >> >> >
    >> >> > 2. you mean "the resource sharing policies are = still being considered
    >> >> > in
    >> >> > a single server", so it may be premature to sup= port redirection.  the
    >> >> > architecture and protocol will be badly impacted if = the requirements
    >> >> > change.
    >> >> > so the designing can be  taken  step by st= ep, but the requirements
    >> >> > should be
    >> >> > overall considered.
    >> >>
    >> >> I said that it is probably premature to consider how reso= urce sharing
    >> >> policies works across servers (or even if we need to say = anything
    >> >> about it) since we have not determined how to specify the= m (or rather,
    >> >> how little we need to specify in protocol) for a single s= erver. I did
    >> >> not mean to imply that redirection could not be introduce= d as a
    >> >> requirement.
    >> >>
    >> >
    >> >>
    >> >> >
    >> >> >
    >> >> >>
    >> >> >> Multi-connection:
    >> >> >>
    >> >> >> I'm not quite clear on the intention of the = requirement.  My
    >> >> >> understanding is that you wish the client to be = able to have
    >> >> >> multiple
    >> >> >> connections open spanning multiple DECADE server= s. Is that correct?
    >> >> >>
    >> >> >> If so, do we need this stated as a requirement o= r the protocol? Or
    >> >> >> is
    >> >> >> this a policy that would be allowed/disallowed b= y the storage
    >> >> >> provider?
    >> >> >>
    >> >> > yep, your understanding is right, the scenarios were= just described
    >> >> > in
    >> >> > draft as "soft handover in wireless environment= and delete operation
    >> >> > in
    >> >> > multi-servers". under these consideration, the = authentication and
    >> >> > authorization need to be taken each time when setup = connection with a
    >> >> > new
    >> >> > DECADE server, or just be taken only once during &nb= sp;the service?
    >> >>
    >> >> The DECADE server should need to do some sort of check on= each new
    >> >> connection, regardless of whether the user has or previou= sly had a
    >> >> connection open to a different DECADE server, right? &nbs= p;Note that the
    >> >> requirements don't indicate how authentication or aut= horization is
    >> >> done, and allow a server to make optimizations if it is e= nforcing the
    >> >> same permissions.
    >> >>
    >> >> Can you indicate where the existing authorization-related= requirements
    >> >> (in particular, 4.1.6.3 of draft-ietf-decade-reqs-00) do = not suffice
    >> >> for the use case you are thinking of?
    >>
    >> > as considering the service continuity, the next serving  = ;DECADE server
    >> > should know the progress of the service, how does they know?<= br> >>
    >> By progress of the service, do you mean current user state (e.g.,<= br> >> quota, recent resource usage history, permissions, etc)?

    > yes, and include data delivery proceeding.

    I still don't think I understand what you are suggesting as= new
    requirements here.  Why can't the client retry any failed requests= ?

    >> > so if the
    >> > service proceeding information should be known by the next se= rving
    >> > server,
    >> > or different servers need to coordinate and schedule each oth= er to
    >> > fulfill
    >> > the user request, i believe the the 4.1.6.3 of the
    >> > draft-ietf-decade-req-00
    >> > cannot satisfy the req. what do you think about?
    >>
    >> Note that the protocol that is covered here is the client-server >> protocol. Some of the same protocol may be useful between DECADE >> servers (especially in different administrative domains) for stori= ng
    >> and retrieving data, but that does not mean that there can't b= e
    >> additional protocol(s) (not specified here) that are used between<= br> >> DECADE servers as well.  For example, if DECADE servers withi= n an
    >> administrative domain can certainly have their own mechanism to sh= are
    >> such information.  If such capabilities were included in the = DECADE
    >> protocol (e.g., a need to do this between administrative domains),=
    >> that sounds like lots more complexity that we need at this point.<= br>
    > but the access between in-network storage also is included in IAP
    > described in problem statement.  i mean why not put this kind of = function in
    > DECADE since the IAP is defined just like that?

    The IAP in the problem statement is intended to describe data transfe= r
    between DECADE servers.  I think the discussion above relates to
    storing state about the progress of delivering data to DECADE clients.
    Is that an accurate summary?  If so, then the point of DECADE is that<= br> this is managed and controlled by the clients.  I don't think it m= akes
    sense to add additional state in to DECADE servers for this.

    >> That said, it sounds to me like what is described in 4.1.6.3 would= be
    >> sufficient (from the perspective of the client-server protocol, >> anyways) to implement what you're describing. If not, what
    >> specifically is missing and what use-case does it not meet?

    > so you mean the information you mentioned above, just like current use= r
    > state (e.g.,
    > quota, recent resource usage history, permissions, etc) was already > included in DECADE requirement? what about the data delivery proceedin= g
    > information? can you specify the chapter for me ? thanks?

    Historical information is not specified, but I can't think of ano= ther
    storage protocol off the top of my head that provides this.

    Quota/resource usage is in Section 5.1.6. Permissions, if applicable,
    should be there too (we will update the doc to state this).

    For data delivery, I see value in getting status about other client
    that may have open connections or active transfers (reads or writes)
    to one's storage. This could probably be added as a requirement.

    However, if the expectation is for DECADE servers to somehow
    coordinate (e.g., picking a data path, resuming/retrying failed
    transfers, etc), then this is going towards delay-tolerant networking
    or CDNs. DECADE is not intended for that.

    >> >> >
    >> >> >
    >> >> >>
    >> >> >> Data Distribution:
    >> >> >>
    >> >> >> I'm also confused about the intent of this r= equirement.  This
    >> >> >> statement has me somewhat worried: "The dis= tribution is transparent
    >> >> >> to
    >> >> >> the users as they interact with the in-network s= torage as a single
    >> >> >> logical system." Does this mean that you ar= e proposing for DECADE
    >> >> >> servers to assume the responsibility for decidin= g how data is to be
    >> >> >> distributed throughout the network, including th= e path of the data,
    >> >> >> which servers act as intermediate caches, conten= t expiration
    >> >> >> policies,
    >> >> >> etc?  If this is true, I think it is missin= g one of the major points
    >> >> >> of DECADE. In particular, these decisions are ap= plication-dependent
    >> >> >> and are not implemented within DECADE. Instead, = DECADE provides the
    >> >> >> basic capabilities and the functionality describ= ed above are
    >> >> >> implemented by the applications using DECADE. >> >> >>
    >> >> >> Or, am I misinterpreting the intent of the requi= rement?
    >> >> >>
    >> >> > you mean DECADE provides the basic capabilities, so = can you give some
    >> >> > specify explanations on DECADE capabilities in suppo= rting data
    >> >> > distribution?
    >> >> >>
    >> >>
    >> >> The problem statement gives a couple of scenarios. The &q= uot;Integration
    >> >> Examples" presentation from IETF 79 also has more de= tails of an
    >> >> on-going effort at Yale.
    >>
    >> > okay, thx for your information, i will lookup and refer, actu= ally, the
    >> > content publisher described in problem statement remind me of=  the
    >> > protocol requirements which i did not find in draft-ietf-deca= de-reqs-00
    >> > to
    >> > support content publish. or i miss some points?
    >>
    >> Which requirements do you think are missing?
    >>
    >> >> >> Service Assurance:
    >> >> >>
    >> >> >> It seems problematic to include "assurance&= quot; in a DECADE.  Shouldn't
    >> >> >> these instead be part of SLAs with a storage pro= vider?  Why should
    >> >> >> they be DECADE's responsibility?
    >> >> >>
    >> >> >> Regarding "resource reservation", are = you referring to an actual
    >> >> >> reservation (which might be problematic -- see a= bove) or do you mean
    >> >> >> that the resource share should able to be specif= ied at the time the
    >> >> >> connection opens and be assumed to be the same f= or the duration of
    >> >> >> the
    >> >> >> connection?
    >> >> >>
    >> >> >> Regarding Dynamic Feedback, is this orthogonal t= o the storage
    >> >> >> protocol?  It seems like what you want here= is a generic "status"
    >> >> >> service saying how loaded a server is?
    >> >> >>
    >> >> > thats right, actually, the flow control mechanism wa= s under
    >> >> > discussion
    >> >> > in writing the draft at first. what about your opini= on in this
    >> >> > requirements?
    >> >> >
    >> >>
    >> >> I'm not sure what the typical way of providing such &= quot;load status"
    >> >> information for IETF protocols, but my inclination is tha= t it should
    >> >> not be in the DECADE protocol itself.  Maybe someone= else with a
    >> >> longer history in IETF could jump in here :)
    >> > so can i understand that "load status" is kind of n= ecessity  information
    >> > for DECADE Server, but where and who collects the information= are
    >> > remain discussion?
    >>
    >> The storage provider is free to collect the information wherever a= nd
    >> however they wish.  The DECADE server implementation could ad= ditional
    >> export whatever status information it wishes. I don't think th= e DECADE
    >> protocol needs to be concerned with that.
    >>
    >> Note that certain error conditions (e.g., overload, insufficient >> resources) may be signaled by a DECADE server (there are already h= ave
    >> requirements for those).  If you are referring to status for = a user's
    >> resources, there is already a requirement for that too.
    >>
    >> I'm just not convinced that the DECADE protocol needs to expor= t its
    >> current load status to clients.

    > actually i am not sure which elements in DECADE needs the load
    > status,(DECADE client or network storage if the network storage needs = to
    > redirect the request or both?).
    > And the requirement draft currently seems describe the overload condit= ion
    > as the event triggering.  do you think if it is necessary to peri= odically
    > reporting of the DECADE network status to client for its network stora= ge
    > selection?

    No I don't think this is necessary.  The client can re= try the request
    at a later time (e.g., exponential backoff).  Note that asking a
    heavily-loaded DECADE server to also keep track of clients that need
    to be notified, and keep them updated of the current status, is
    probably counter-productive.

    > and the requirement draft just describe DECADE which is busy to serve<= br> > other requests must be able to reject requests, not consider how to ha= ndle
    > the user request after being rejected?

    That's the implementation's decision. I suspect most would dr= op it on the floor.

    >> >> >>
    >> >> >> Data classification:
    >> >> >>
    >> >> >> Would it be better to instead have the client sp= ecify properties of
    >> >> >> the content instead of place it into ? See
    >> >> >>     www.ietf.org/proceedings/78/slides/nfsv= 4-0.pdf for an example of
    >> >> >> this
    >> >> >> approach for NFS.
    >> >> >>
    >> >> >> I think a problem with classifying applications = is that it assumes
    >> >> >> that applications fit one of the supplied classi= fications. What if
    >> >> >> it
    >> >> >> may fit multiple classifications? or none?  = ;Another problem is it
    >> >> >> assumes that servers assume based on indirect an= d assumed
    >> >> >> information
    >> >> >> that they know what to do with a particular piec= e of content. Why
    >> >> >> not
    >> >> >> have an application specify its desires directly= ?
    >> >> >>
    >> >> >
    >> >> >
    >> >> >>
    >> >> >> Small Objects:
    >> >> >>
    >> >> >> What is the new requirement here?  Why is t= he existing requirement
    >> >> >> in
    >> >> >> draft-ietf-decade-reqs-00 insufficient?
    >> >> >>
    >> >> >> This also has me a bit worried:
    >> >> >> "And the in-network storage has the limited= storage capacity, with
    >> >> >> the
    >> >> >> arrival of user requests and data distribution r= equirements, the
    >> >> >> data
    >> >> >> stored in the in-network storage will be replace= d if the storage
    >> >> >> reaches the limit and data arrivals continually.= "
    >> >> >>
    >> >> >> How does the server know what the proper replace= ment strategy is for
    >> >> >> an application? I think DECADE's philosophy = is that applications
    >> >> >> should decide this. A simple way to do this is e= xplicit deletion by
    >> >> >> an
    >> >> >> application, but perhaps a more efficient (yet m= ore complex)
    >> >> >> solution
    >> >> >> is for an application to specify the replacement= policy to the
    >> >> >> server.
    >> >> >>
    >> >> > actually, the key in "the data classification a= nd small objects " is
    >> >> > whether does it or not in P2P application? i did not= find data
    >> >> > classification was adopted in P2P application so far= , let alone
    >> >> > DECADE need
    >> >> > to classify the data used in all kinds of applicatio= n.
    >> >> >
    >> >>
    >> >> So, do you agree that it is problematic to try and classi= fy each type
    >> >> of application and try to specify the typical workload fo= r each class?
    >> >>
    >> >> My point was that I don't think its necessary to do t= he classification
    >> >> at all.  It is more extensible (and directly useful)= for a server to
    >> >> just give it direct hints about what would be preferable.=
    >> >
    >> > yep, i believe it may be a little difficult, but worthy doing= . specially
    >> > for improving the resource utilization within a single server= and
    >> > reducing
    >> > the response time for client. what about others opinion?
    >>
    >> Can you justify why giving classifications (e.g., "I'm a = live
    >> streaming application") would be better than giving specific = hints
    >> (e.g., "please don't bother persistent these objects to d= isk")?
    >
    > i mean data in different kind of operation mode and attribute should h= ave
    > different user patterns and storage rules, which may be help to improv= e the
    > resource utilization and reduce the response time for request, what ar= e you
    > understanding?

    That's fine. Explicit and more-specific hints are a differe= nt way to
    accomplish the same thing, and seem to be a much better design to me.
    They are simpler from an extensibility and implementation point of
    view.

    >> > >>
    >> >> >> Removal of Expired Records:
    >> >> >>
    >> >> >> "However, the two scenarios did not mention= how to handle the old
    >> >> >> resource if the user distributes the new resourc= e which is an
    >> >> >> updated
    >> >> >> copy of the old resource."
    >> >> >>
    >> >> >> Why does this need to be handled in the requirem= ents?  Are you
    >> >> >> trying
    >> >> >> to draw the distinction between immediate deleti= on of content and
    >> >> >> lazy
    >> >> >> deletion?
    >> >> >>
    >> >> > i mean the meaning of delete operation and how to ha= ndle the expired
    >> >> > records need to be clarify in requirements.
    >> >>
    >> >> My inclination is that "deleted" means that oth= er requests the object
    >> >> of the same name should result an error, until another ob= ject with the
    >> >> same name is stored.
    >> >
    >> > okay, under the scenario "client uploads the new version= , and did not
    >> > specify how to handle the old version", did DECADE serve= r delete the
    >> > older
    >> > version (or just label it unavailable, anyway, it is implemen= tation
    >> > issue )
    >> > or not ? in another word, just replace the older version with= the new
    >> > version with the same name?
    >>
    >> In this case, I would think the "write" of the new objec= t should be
    >> rejected, or if desired, we could have an overwrite option.  = This
    >> could be added to the requirements if it helps to clarify.
    >> yep, no matter which solution is chosen, let the understanding
    >> unanimously:D
    >> > how to handle the older version which is
    >> > transferring from server to client?
    >>
    >> I think it would be cleaner to ask the server to continue sending = an
    >> object once it has been started, but ultimately this would be the<= br> >> decision of the server's implementation I think.  Maybe a= "SHOULD"
    >> requirement.  This could be added if desired.
    >>
    > Thank you for these questions.  It helps design the requirements = more
    > cleanly if there are specific scenarios in front of us :)
    > just discussion together:D and also thanks for your points to help me<= br> > understanding more!

    Thanks,
    Rich

    >> Rich
    >>
    >> >> I think that the time the data is removed from disk (or m= emory) should
    >> >> be up to the implementation. A storage provider might sti= ll have as
    >> >> part of some agreement that deleted data will be removed = within X
    >> >> days/hours/minutes/whatever.
    >> >
    >> >    agree with you.
    >> >>
    >> >> If people in the WG think it is necessary, we could have = a requirement
    >> >> that says the protocol should support an argument indicat= ing immediate
    >> >> deletion, but it is not clear that we need this.
    >> >>
    >> >> Rich
    >> >>
    >> >> >>
    >> >> >> Thanks!
    >> >> >> Rich
    >> >> >>
    >> >> >>
    >> >> >> On Mon, Dec 27, 2010 at 12:57 AM, =D6=EC=E4=EC &= lt;buptxiaozhu@g= mail.com> wrote:
    >> >> >> > Dear all,
    >> >> >> >
    >> >> >> > There is a slightly updated version of the = decade additional
    >> >> >> > requirements
    >> >> >> > draft.
    >> >> >> >
    >> >> >> >
    >> >> >> > https://datat= racker.ietf.org/doc/draft-zhu-decade-additional-requirements/
    >> >> >> >
    >> >> >> > Jin Peng, Yunfei Zhang and me are expecting= to have a discussion
    >> >> >> > with
    >> >> >> > all of
    >> >> >> > you.
    >> >> >> >
    >> >> >> > Any comments are appreciated!
    >> >> >> >
    >> >> >> > A new version of I-D,
    >> >> >> > draft-zhu-decade-additional-requirements-00= .txt
    >> >> >> > has been successfully submitted by Xiao Zhu= and posted to the IETF
    >> >> >> > repository.
    >> >> >> >
    >> >> >> > Filename:      draft-zhu-dec= ade-additional-requirements
    >> >> >> > Revision:      00
    >> >> >> > Title:           &= nbsp;     Additional protocol requirements on DECADE
    >> >> >> > Creation_date:         = 2010-12-27
    >> >> >> > WG ID:           &= nbsp;     Independent Submission
    >> >> >> > Number_of_pages: 10
    >> >> >> >
    >> >> >> > Abstract:
    >> >> >> > The DECoupled Application Data Enroute(DECA= DE)working group is
    >> >> >> > specifying standardized interfaces for acce= ssing in-network
    >> >> >> > storage
    >> >> >> > from applications to store, retrieve and ma= nage data. The main
    >> >> >> > object
    >> >> >> > is to provide a framework that is useful to= the applications,
    >> >> >> > including P2P applications and other data-o= riented applications,
    >> >> >> > possibly related applications that can bene= fit from accessing in-
    >> >> >> > network storage. This memo focuses on some = requirements such as
    >> >> >> > request redirecting and so on which are on = the central of
    >> >> >> > mobility,
    >> >> >> > wireless network environment and CDN applic= ation. We present these
    >> >> >> > in
    >> >> >> > this memo as additional requirements that s= hould be considered for
    >> >> >> > the DECADE architecture and protocol specif= ications.
    >> >> >> >
    >> >> >> >
    >> >> >> >
    >> >> >> > The IETF Secretariat.
    >> >> >> >
    >> >> >> > --
    >> >> >> > Best wishes,
    >> >> >> >
    >> >> >> > Beijing University of Posts & Telecommu= nications (BUPT)
    >> >> >> > Zhu Xiao  ( =D6=EC=E4=EC )
    >> >> >> > E-mail: buptxiaozhu@gmail.com
    >> >> >> > mobile:+86 134-8881-9004
    >> >> >> >
    >> >> >> > ___________________________________________= ____
    >> >> >> > decade mailing list
    >> >> >> > decade@ietf.org
    >> >> >> > https://www.ietf.org/mailman/listinfo/decad= e
    >> >> >> >
    >> >> >> >
    >> >> >
    >> >> >
    >> >> >
    >> >> > --
    >> >> > Best wishes,
    >> >> >
    >> >> > Beijing University of Posts & Telecommunications= (BUPT)
    >> >> > Zhu Xiao  ( =D6=EC=E4=EC )
    >> >> > E-mail: buptxiaozhu@gmail.com
    >> >> > mobile:+86 134-8881-9004
    >> >
    >> >
    >> >
    >> > --
    >> > Best wishes,
    >> >
    >> > Beijing University of Posts & Telecommunications (BUPT) >> > Zhu Xiao  ( =D6=EC=E4=EC )
    >> > E-mail: buptxiaozhu@gmail.com
    >> > mobile:+86 134-8881-9004
    >> >
    >
    >
    >
    > --
    > Best wishes,
    >
    > Beijing University of Posts & Telecommunications (BUPT)
    > Zhu Xiao  ( =D6=EC=E4=EC )
    > E-mail: bup= txiaozhu@gmail.com
    > mobile:+86 134= -8881-9004
    >



    --
    Best wishes,

    Beijing University of Posts & Telecommunicati= ons (BUPT)
    Zhu Xiao  ( =D6=EC=E4=EC )
    E-mail: buptxiaozhu@gmail.com
    mobile:+86 134-8881= -9004




    --
    Best wishes,

    Bei= jing University of Posts & Telecommunications (BUPT)
    Zhu Xiao  = ( =D6=EC=E4=EC )
    E-mail: buptxiaozhu@gmail.com
    mobile:+86 134-8881-9004
    --00235444785dd96ff2049e5be0b8-- --00235444785dd96ff8049e5be0b9 Content-Type: image/gif; name="338.gif" Content-Transfer-Encoding: base64 X-Attachment-Id: 338@goomoji.gmail Content-ID: <338@goomoji.gmail> R0lGODlhDAAMAKIGAF5LAJh3AP/zxAAAANyuAP/gaP///wAAACH/C05FVFNDQVBFMi4wAwEAAAAh +QQFZAAGACwAAAAADAAMAAADJmi03CowyiWKvZeWMSy32rd1hYZh5gkSVQFY79q6saxm7A0qTW8k ACH5BAUUAAYALAIAAwAIAAYAAAMMWFOsvq/JSYMN07YEACH5BAUUAAYALAMABwAGAAMAAAMIGLq0 QYVImAAAIfkEBRQABgAsAgACAAgABQAAAwtYU6y+r8k5g70lAQAh+QQFFAAGACwCAAIACAAFAAAD CVi6O+xQRUZrAgAh+QQFFAAGACwCAAIACAAFAAADC1hTrL6vyTmDvSUBACH5BAUUAAYALAIAAgAI AAUAAAMJWLo77FBFRmsCACH5BAUUAAYALAIAAgAIAAUAAAMLWFOsvq/JOYO9JQEAIfkEBRQABgAs AgACAAgABQAAAwlYujvsUEVGawIAIfkEBRQABgAsAgACAAgABQAAAwtYU6y+r8k5g70lAQAh+QQF FAAGACwCAAIACAAFAAADCVi6O+xQRUZrAgAh+QQFFAAGACwCAAIACAAFAAADC1hTrL6vyTmDvSUB ACH5BAUUAAYALAIAAgAIAAUAAAMJWLo77FBFRmsCACH5BAUUAAYALAMABwAGAAMAAAMHWLZWvs+9 BAAh+QQFFAAGACwEAAcABAACAAADBAhVCpoAOw== --00235444785dd96ff8049e5be0b9 Content-Type: image/gif; name="1A5.gif" Content-Transfer-Encoding: base64 X-Attachment-Id: 1A5@goomoji.gmail Content-ID: <1A5@goomoji.gmail> R0lGODlhEAAMAKIFAF5LAP/zxAAAANyuAP/gaP///wAAAAAAACH/C05FVFNDQVBFMi4wAwEAAAAh +QQJZAAFACwAAAAAEAAMAAADO1iq0/6LhUkBmCOOQLonAJEtGyEI3dmNkom6q8Z9H1sML22OTnC+ P9GNU9LFBquZJxS7NWYWZpP0qBYSACH5BAkKAAUALAAAAAAQAAwAAAM7WKrT/ouFSQGYI45AuicA kS0bIQjd2Y2Sibqrxn0fWwwvbbJNcL4/UWug84yIIlooxiiBLLXI7UEtJAAAIfkECQoABQAsAAAA ABAADAAAAzhYqtP+i4VJAZgjjkC6JwCRLRshCN3ZjZKJuqvGfR9bNLQnsOWguijeKhcjDWihYgtk qUVuj2ghAQAh+QQFCgAFACwAAAAAEAAMAAADN1iq0/6LhUkBmCOOQLonAJEtGyEI3dmNkom6q8Z9 H1s4dGqXw3uiu1VOpGl8QjHSzIJMkh7QQgIAIfkEBRQABQAsAAAFAAgABQAAAxFYMxpEwy0H3xBY KBZf+c2TAAAh+QQFCgAFACwEAAYABQACAAADBlgqMkEqAQAh+QQFAAAFACwGAAYAAwACAAADBChE 0gkAIfkECQoABQAsAAAFAAcAAgAAAwVYuqxCCQAh+QQJCgAFACwAAAAAEAAMAAADGFi63P4wyknd CESOUYbIUVB1BMFR26iuCQAh+QQFkAEFACwAAAAAEAAMAAADO1iq0/6LhUkBmCOOQLonAJEtGyEI 3dmNkom6q8Z9H1sML22OTnC+P9GNU9LFBquZJxS7NWYWZpP0qBYSADs= --00235444785dd96ff8049e5be0b9-- From richard.alimi@gmail.com Sun Mar 13 10:13:45 2011 Return-Path: X-Original-To: decade@core3.amsl.com Delivered-To: decade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A00C33A6A0B for ; Sun, 13 Mar 2011 10:13:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.477 X-Spam-Level: X-Spam-Status: No, score=-0.477 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GVQkUH9Zb7Tc for ; Sun, 13 Mar 2011 10:13:43 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id 45D513A69E2 for ; Sun, 13 Mar 2011 10:13:43 -0700 (PDT) Received: by iyi12 with SMTP id 12so1329116iyi.31 for ; Sun, 13 Mar 2011 10:15:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=f2zGY4GzWx2+aNFG2Yb20lECrUtqwlNj5H2fKBglD6I=; b=VF4qMY77JdYiE+rHZ+cHCtzLnM5mizt2ITJ6pfpPrmQF7cbpPZwj/gZZPfqYTXd7ZY nzYXYvtFApyTBm/uucbE6l+aHkHqrKNTHJBmyAdwnyZB9QDDiqmfafTx/yxk8ieKaP7o zfZfyGpQSAp+RISyjVpZFBEuL2/q/YKaZ9Gzw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=Or3pTr9ERACOlMk2uhExJQfuZhvW2UYPppEbU/QJAjsLrGObs4ruJiHS2ESm+Z1r4b oAhw8pJKahH6X3ORMs4SZkNMCwzc6ACxjPgKf0fFKnzkgbiQ3cC2DgitMZWbJ+StZAbk wDsZ5fd/s9Uou+6uYQRYt7H1C0SyIPisR+CXw= MIME-Version: 1.0 Received: by 10.42.174.131 with SMTP id v3mr890625icz.21.1300036504151; Sun, 13 Mar 2011 10:15:04 -0700 (PDT) Sender: richard.alimi@gmail.com Received: by 10.231.10.71 with HTTP; Sun, 13 Mar 2011 10:15:04 -0700 (PDT) In-Reply-To: References: <1CA25301D2219F40B3AA37201F0EACD11343C0AB@PACDCEXMB05.cable.comcast.com> Date: Sun, 13 Mar 2011 10:15:04 -0700 X-Google-Sender-Auth: hco_fmI-KlAViBV9WUZcK3sfq30 Message-ID: From: Richard Alimi To: "Woundy, Richard" Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable Cc: "decade@ietf.org" Subject: Re: [decade] draft-zhu-decade-additional-requirements X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.9 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, 13 Mar 2011 17:13:45 -0000 Hi All, We've made all of these updates to the requirements document, with the exception of: > - If an object is deleted as it is concurrently being read, then the > server MAY continue to read it (lazy deletion), or it MAY discontinue > reading the object and signal an error to the client reading the > object. Upon looking at this again, it looks more like an implementation detail. If anything, this would result in a "non-requirement" in the document. However, it seems like a fairly low-level non-requirement to state at this time. I'd propose to leave it out for now and revisit this if it comes up again in the future. Thoughts? Thanks, Rich 2011/3/2 Richard Alimi : > Hi All, > > I'll offer a summary of this discussion. Let me know if I missed > anything, or if there are objections/other thoughts on these proposed > resolutions. > > Redirection: > - We can add a requirement mentioning that DECADE may support redirection= . > > Data Classification: > - I (personally) strongly disagree with attempting to classify access > patterns or applications. We could add something saying that explicit > hints (a la www.ietf.org/proceedings/78/slides/nfsv4-0.pdf) could be > provided in DECADE. However, I don't think we need to do something > new here. In particular, if the underlying storage/data transport > supports hints, a DECADE client or server can use it. > > Storage Status: > - Update section 5.1.6 to indicate that status information should > include permissions of stored objects, if applicable. > - Update 5.1.6 to indicate that status information should include > other information about resource usage (the clients own resources, or > resources used by other clients that have been authorized to > read/write objects or open connections to one's storage). > > Requirements for object deletion/overwriting: > - DECADE MAY have an overwrite flag (note that this may or may not be > necessary depending on our naming, but the requirements document > probably is not the place to take a stand on this at the current > point.) > - If an object is deleted as it is concurrently being read, then the > server MAY continue to read it (lazy deletion), or it MAY discontinue > reading the object and signal an error to the client reading the > object. > > Would this be sufficient to merge in the points from > draft-zhu-decade-additional-requirements-00 and this ensuing > discussion? > > Thanks, > Rich > > > 2011/3/2 Woundy, Richard : >> Folks, >> >> >> >> Do we have consensus yet about how the WG could have a single DECADE >> requirements document going forward? I can't tell the state of our >> requirements consolidation from the email thread below. >> >> >> >> It would be preferable if we could resolve this fully on the WG mailing >> list, but this is important enough to allocate some time at our meeting = in >> Prague. >> >> >> >> -- Rich >> >> >> >> From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.org] On Behalf= Of >> ?? >> Sent: Sunday, January 16, 2011 9:02 PM >> To: Richard Alimi >> Cc: decade@ietf.org >> Subject: Re: [decade] draft-zhu-decade-additional-requirements >> >> >> >> hi, Richard: >> >> >> >> thanks for your reply:D >> >> additional discussion see inline:D >> >> >> >> 2011/1/14 Richard Alimi >> >> HI Xiao, >> >> 2011/1/12 =D6=EC=E4=EC : >> >>> hi, Richard >>> see inline:D >>> >>> 2011/1/11 Richard Alimi >>>> >>>> Hi Xiao, >>>> >>>> On Mon, Jan 10, 2011 at 6:45 PM, =D6=EC=E4=EC = wrote: >>>> > >>>> > hi, Richard, sorry for so late response because of be busy with othe= r >>>> > projects. >>>> > some discussion see inline:D marked by red. >>>> > >>>> > On Tue, Jan 4, 2011 at 4:06 AM, Richard Alimi >>>> > wrote: >>>> >> >>>> >> Hi Xiao, >>>> >> >>>> >> Thank you for the draft. Some comments on the requirements: >>>> >> >>>> >> Request Redirects: >>>> >> >>>> >> This would provide some additional freedom for the storage provider= . >>>> >> I think it is reasonable since it doesn't necessitate additional >>>> >> complexity for the DECADE server, but allows it if desired. However= , >>>> >> note that it may complicate some of the other components of the >>>> >> design. In particular, if there is a per-user quota for storage, is >>>> >> the user made aware of the quota at each in-network storage (if the= re >>>> >> is no shared storage between them)? Resource sharing policies may = be >>>> >> impacted (e.g., if a bandwidth sharing weight of 1 may mean somethi= ng >>>> >> different at DECADE server A than it does at DECADE server B). At >>>> >> this point it may be best to just note these so they are documented= , >>>> >> but since the specification of the resource sharing policies are st= ill >>>> >> being contemplated for the basic case of a single server it may be >>>> >> premature to even try and solve them for the case supporting >>>> >> redirection. >>>> >> >>>> > actually, you mean two points, right? >>>> > 1. whether or not to be ware of the content at each in-network stora= ge >>>> > and of course resource sharing policies can be impact in the request >>>> > redirection. your suggestion"just to note these so they are document= ed" >>>> > will >>>> > be ok, or DECADE server list with some parameters will be return for >>>> > user to >>>> > select the appropriate DECADE server, which can avoid the different >>>> > weighted >>>> > of the same parameter in server decision. but the parameter used in >>>> > select >>>> > the best DECADE server will be known for DECADE servers, in which ot= her >>>> > complexities will be added. anyway, all the solution are the >>>> > implementation >>>> > issue, which, i believe, does not impact the necessity of the >>>> > requirement. >>>> >>>> In general, I'd agree that the decision about where to redirect would >>>> be an implementation issue. >>>> >>>> > >>>> > 2. you mean "the resource sharing policies are still being considere= d >>>> > in >>>> > a single server", so it may be premature to support redirection. th= e >>>> > architecture and protocol will be badly impacted if the requirements >>>> > change. >>>> > so the designing can be taken step by step, but the requirements >>>> > should be >>>> > overall considered. >>>> >>>> I said that it is probably premature to consider how resource sharing >>>> policies works across servers (or even if we need to say anything >>>> about it) since we have not determined how to specify them (or rather, >>>> how little we need to specify in protocol) for a single server. I did >>>> not mean to imply that redirection could not be introduced as a >>>> requirement. >>>> >>> >>>> >>>> > >>>> > >>>> >> >>>> >> Multi-connection: >>>> >> >>>> >> I'm not quite clear on the intention of the requirement. My >>>> >> understanding is that you wish the client to be able to have multip= le >>>> >> connections open spanning multiple DECADE servers. Is that correct? >>>> >> >>>> >> If so, do we need this stated as a requirement or the protocol? Or = is >>>> >> this a policy that would be allowed/disallowed by the storage >>>> >> provider? >>>> >> >>>> > yep, your understanding is right, the scenarios were just described = in >>>> > draft as "soft handover in wireless environment and delete operation= in >>>> > multi-servers". under these consideration, the authentication and >>>> > authorization need to be taken each time when setup connection with = a >>>> > new >>>> > DECADE server, or just be taken only once during the service? >>>> >>>> The DECADE server should need to do some sort of check on each new >>>> connection, regardless of whether the user has or previously had a >>>> connection open to a different DECADE server, right? Note that the >>>> requirements don't indicate how authentication or authorization is >>>> done, and allow a server to make optimizations if it is enforcing the >>>> same permissions. >>>> >>>> Can you indicate where the existing authorization-related requirements >>>> (in particular, 4.1.6.3 of draft-ietf-decade-reqs-00) do not suffice >>>> for the use case you are thinking of? >> >>> as considering the service continuity, the next serving DECADE server >>> should know the progress of the service, how does they know? >> >> By progress of the service, do you mean current user state (e.g., >> quota, recent resource usage history, permissions, etc)? >> >> yes, and include data delivery proceeding. >>> so if the >>> service proceeding information should be known by the next serving serv= er, >>> or different servers need to coordinate and schedule each other to fulf= ill >>> the user request, i believe the the 4.1.6.3 of the >>> draft-ietf-decade-req-00 >>> cannot satisfy the req. what do you think about? >> >> Note that the protocol that is covered here is the client-server >> protocol. Some of the same protocol may be useful between DECADE >> servers (especially in different administrative domains) for storing >> and retrieving data, but that does not mean that there can't be >> additional protocol(s) (not specified here) that are used between >> DECADE servers as well. For example, if DECADE servers within an >> administrative domain can certainly have their own mechanism to share >> such information. If such capabilities were included in the DECADE >> protocol (e.g., a need to do this between administrative domains), >> that sounds like lots more complexity that we need at this point. >> but the access between in-network storage also is included in IAP descri= bed >> in problem statement. i mean why not put this kind of function in DECAD= E >> since the IAP is defined just like that? >> That said, it sounds to me like what is described in 4.1.6.3 would be >> sufficient (from the perspective of the client-server protocol, >> anyways) to implement what you're describing. If not, what >> specifically is missing and what use-case does it not meet? >> >> so you mean the information you mentioned above, just like current user >> state (e.g., >> quota, recent resource usage history, permissions, etc) was already incl= uded >> in DECADE requirement? what about the data delivery proceeding informati= on? >> can you specify the chapter for me ? thanks? >>>> > >>>> > >>>> >> >>>> >> Data Distribution: >>>> >> >>>> >> I'm also confused about the intent of this requirement. This >>>> >> statement has me somewhat worried: "The distribution is transparent= to >>>> >> the users as they interact with the in-network storage as a single >>>> >> logical system." Does this mean that you are proposing for DECADE >>>> >> servers to assume the responsibility for deciding how data is to be >>>> >> distributed throughout the network, including the path of the data, >>>> >> which servers act as intermediate caches, content expiration polici= es, >>>> >> etc? If this is true, I think it is missing one of the major point= s >>>> >> of DECADE. In particular, these decisions are application-dependent >>>> >> and are not implemented within DECADE. Instead, DECADE provides the >>>> >> basic capabilities and the functionality described above are >>>> >> implemented by the applications using DECADE. >>>> >> >>>> >> Or, am I misinterpreting the intent of the requirement? >>>> >> >>>> > you mean DECADE provides the basic capabilities, so can you give som= e >>>> > specify explanations on DECADE capabilities in supporting data >>>> > distribution? >>>> >> >>>> >>>> The problem statement gives a couple of scenarios. The "Integration >>>> Examples" presentation from IETF 79 also has more details of an >>>> on-going effort at Yale. >> >>> okay, thx for your information, i will lookup and refer, actually, the >>> content publisher described in problem statement remind me of the >>> protocol requirements which i did not find in draft-ietf-decade-reqs-00= to >>> support content publish. or i miss some points? >> >> Which requirements do you think are missing? >> >>>> >> Service Assurance: >>>> >> >>>> >> It seems problematic to include "assurance" in a DECADE. Shouldn't >>>> >> these instead be part of SLAs with a storage provider? Why should >>>> >> they be DECADE's responsibility? >>>> >> >>>> >> Regarding "resource reservation", are you referring to an actual >>>> >> reservation (which might be problematic -- see above) or do you mea= n >>>> >> that the resource share should able to be specified at the time the >>>> >> connection opens and be assumed to be the same for the duration of = the >>>> >> connection? >>>> >> >>>> >> Regarding Dynamic Feedback, is this orthogonal to the storage >>>> >> protocol? It seems like what you want here is a generic "status" >>>> >> service saying how loaded a server is? >>>> >> >>>> > thats right, actually, the flow control mechanism was under discussi= on >>>> > in writing the draft at first. what about your opinion in this >>>> > requirements? >>>> > >>>> >>>> I'm not sure what the typical way of providing such "load status" >>>> information for IETF protocols, but my inclination is that it should >>>> not be in the DECADE protocol itself. Maybe someone else with a >>>> longer history in IETF could jump in here :) >>> so can i understand that "load status" is kind of necessity informatio= n >>> for DECADE Server, but where and who collects the information are >>> remain discussion? >> >> The storage provider is free to collect the information wherever and >> however they wish. The DECADE server implementation could additional >> export whatever status information it wishes. I don't think the DECADE >> protocol needs to be concerned with that. >> >> Note that certain error conditions (e.g., overload, insufficient >> resources) may be signaled by a DECADE server (there are already have >> requirements for those). If you are referring to status for a user's >> resources, there is already a requirement for that too. >> >> I'm just not convinced that the DECADE protocol needs to export its >> current load status to clients. >> >> actually i am not sure which elements in DECADE needs the load >> status,(DECADE client or network storage if the network storage needs to >> redirect the request or both?). >> >> >> >> And the requirement draft currently seems describe the overload conditio= n as >> the event triggering. do you think if it is necessary to periodically >> reporting of the DECADE network status to client for its network storage >> selection? >> >> >> >> and the requirement draft just describe DECADE which is busy to serve ot= her >> requests must be able to reject requests, not consider how to handle the >> user request after being rejected? >> >>>> >> >>>> >> Data classification: >>>> >> >>>> >> Would it be better to instead have the client specify properties of >>>> >> the content instead of place it into ? See >>>> >> www.ietf.org/proceedings/78/slides/nfsv4-0.pdf for an example of th= is >>>> >> approach for NFS. >>>> >> >>>> >> I think a problem with classifying applications is that it assumes >>>> >> that applications fit one of the supplied classifications. What if = it >>>> >> may fit multiple classifications? or none? Another problem is it >>>> >> assumes that servers assume based on indirect and assumed informati= on >>>> >> that they know what to do with a particular piece of content. Why n= ot >>>> >> have an application specify its desires directly? >>>> >> >>>> > >>>> > >>>> >> >>>> >> Small Objects: >>>> >> >>>> >> What is the new requirement here? Why is the existing requirement = in >>>> >> draft-ietf-decade-reqs-00 insufficient? >>>> >> >>>> >> This also has me a bit worried: >>>> >> "And the in-network storage has the limited storage capacity, with = the >>>> >> arrival of user requests and data distribution requirements, the da= ta >>>> >> stored in the in-network storage will be replaced if the storage >>>> >> reaches the limit and data arrivals continually." >>>> >> >>>> >> How does the server know what the proper replacement strategy is fo= r >>>> >> an application? I think DECADE's philosophy is that applications >>>> >> should decide this. A simple way to do this is explicit deletion by= an >>>> >> application, but perhaps a more efficient (yet more complex) soluti= on >>>> >> is for an application to specify the replacement policy to the serv= er. >>>> >> >>>> > actually, the key in "the data classification and small objects " is >>>> > whether does it or not in P2P application? i did not find data >>>> > classification was adopted in P2P application so far, let alone DECA= DE >>>> > need >>>> > to classify the data used in all kinds of application. >>>> > >>>> >>>> So, do you agree that it is problematic to try and classify each type >>>> of application and try to specify the typical workload for each class? >>>> >>>> My point was that I don't think its necessary to do the classification >>>> at all. It is more extensible (and directly useful) for a server to >>>> just give it direct hints about what would be preferable. >>> >>> yep, i believe it may be a little difficult, but worthy doing. speciall= y >>> for improving the resource utilization within a single server and reduc= ing >>> the response time for client. what about others opinion? >> >> Can you justify why giving classifications (e.g., "I'm a live >> streaming application") would be better than giving specific hints >> (e.g., "please don't bother persistent these objects to disk")? >> >> i mean data in different kind of operation mode and attribute should hav= e >> different user patterns and storage rules, which may be help to improve = the >> resource utilization and reduce the response time for request, what are = you >> understanding? >>> >> >>>> >> Removal of Expired Records: >>>> >> >>>> >> "However, the two scenarios did not mention how to handle the old >>>> >> resource if the user distributes the new resource which is an updat= ed >>>> >> copy of the old resource." >>>> >> >>>> >> Why does this need to be handled in the requirements? Are you tryi= ng >>>> >> to draw the distinction between immediate deletion of content and l= azy >>>> >> deletion? >>>> >> >>>> > i mean the meaning of delete operation and how to handle the expired >>>> > records need to be clarify in requirements. >>>> >>>> My inclination is that "deleted" means that other requests the object >>>> of the same name should result an error, until another object with the >>>> same name is stored. >>> >>> okay, under the scenario "client uploads the new version, and did not >>> specify how to handle the old version", did DECADE server delete the ol= der >>> version (or just label it unavailable, anyway, it is implementation iss= ue >>> ) >>> or not ? in another word, just replace the older version with the new >>> version with the same name? >> >> In this case, I would think the "write" of the new object should be >> rejected, or if desired, we could have an overwrite option. This >> could be added to the requirements if it helps to clarify. >> >> yep, no matter which solution is chosen, let the understanding unanimous= ly:D >>> how to handle the older version which is >>> transferring from server to client? >> >> I think it would be cleaner to ask the server to continue sending an >> object once it has been started, but ultimately this would be the >> decision of the server's implementation I think. Maybe a "SHOULD" >> requirement. This could be added if desired. >> >> Thank you for these questions. It helps design the requirements more >> cleanly if there are specific scenarios in front of us :) >> just discussion together:D and also thanks for your points to help me >> understanding more! >> Rich >> >>>> I think that the time the data is removed from disk (or memory) should >>>> be up to the implementation. A storage provider might still have as >>>> part of some agreement that deleted data will be removed within X >>>> days/hours/minutes/whatever. >>> >>> agree with you. >>>> >>>> If people in the WG think it is necessary, we could have a requirement >>>> that says the protocol should support an argument indicating immediate >>>> deletion, but it is not clear that we need this. >>>> >>>> Rich >>>> >>>> >> >>>> >> Thanks! >>>> >> Rich >>>> >> >>>> >> >>>> >> On Mon, Dec 27, 2010 at 12:57 AM, =D6=EC=E4=EC wrote: >>>> >> > Dear all, >>>> >> > >>>> >> > There is a slightly updated version of the decade additional >>>> >> > requirements >>>> >> > draft. >>>> >> > >>>> >> > >>>> >> > https://datatracker.ietf.org/doc/draft-zhu-decade-additional-requ= irements/ >>>> >> > >>>> >> > Jin Peng, Yunfei Zhang and me are expecting to have a discussion >>>> >> > with >>>> >> > all of >>>> >> > you. >>>> >> > >>>> >> > Any comments are appreciated! >>>> >> > >>>> >> > A new version of I-D, >>>> >> > draft-zhu-decade-additional-requirements-00.txt >>>> >> > has been successfully submitted by Xiao Zhu and posted to the IET= F >>>> >> > repository. >>>> >> > >>>> >> > Filename: draft-zhu-decade-additional-requirements >>>> >> > Revision: 00 >>>> >> > Title: Additional protocol requirements on DECADE >>>> >> > Creation_date: 2010-12-27 >>>> >> > WG ID: Independent Submission >>>> >> > Number_of_pages: 10 >>>> >> > >>>> >> > Abstract: >>>> >> > The DECoupled Application Data Enroute(DECADE)working group is >>>> >> > specifying standardized interfaces for accessing in-network stora= ge >>>> >> > from applications to store, retrieve and manage data. The main >>>> >> > object >>>> >> > is to provide a framework that is useful to the applications, >>>> >> > including P2P applications and other data-oriented applications, >>>> >> > possibly related applications that can benefit from accessing in- >>>> >> > network storage. This memo focuses on some requirements such as >>>> >> > request redirecting and so on which are on the central of mobilit= y, >>>> >> > wireless network environment and CDN application. We present thes= e >>>> >> > in >>>> >> > this memo as additional requirements that should be considered fo= r >>>> >> > the DECADE architecture and protocol specifications. >>>> >> > >>>> >> > >>>> >> > >>>> >> > The IETF Secretariat. >>>> >> > >>>> >> > -- >>>> >> > Best wishes, >>>> >> > >>>> >> > Beijing University of Posts & Telecommunications (BUPT) >>>> >> > Zhu Xiao ( =D6=EC=E4=EC ) >>>> >> > E-mail: buptxiaozhu@gmail.com >>>> >> > mobile:+86 134-8881-9004 >>>> >> > >>>> >> > _______________________________________________ >>>> >> > decade mailing list >>>> >> > decade@ietf.org >>>> >> > https://www.ietf.org/mailman/listinfo/decade >>>> >> > >>>> >> > >>>> > >>>> > >>>> > >>>> > -- >>>> > Best wishes, >>>> > >>>> > Beijing University of Posts & Telecommunications (BUPT) >>>> > Zhu Xiao ( =D6=EC=E4=EC ) >>>> > E-mail: buptxiaozhu@gmail.com >>>> > mobile:+86 134-8881-9004 >>> >>> >>> >>> -- >>> Best wishes, >>> >>> Beijing University of Posts & Telecommunications (BUPT) >>> Zhu Xiao ( =D6=EC=E4=EC ) >>> E-mail: buptxiaozhu@gmail.com >>> mobile:+86 134-8881-9004 >>> >> >> >> -- >> Best wishes, >> >> Beijing University of Posts & Telecommunications (BUPT) >> Zhu Xiao ( =D6=EC=E4=EC ) >> E-mail: buptxiaozhu@gmail.com >> mobile:+86 134-8881-9004 > From zhangyunfei@chinamobile.com Sun Mar 13 19:46:53 2011 Return-Path: X-Original-To: decade@core3.amsl.com Delivered-To: decade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA4523A6AE5 for ; Sun, 13 Mar 2011 19:46:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -94.889 X-Spam-Level: X-Spam-Status: No, score=-94.889 tagged_above=-999 required=5 tests=[AWL=0.684, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_62=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RELAY_IS_221=2.222, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GD2eEziBHqJe for ; Sun, 13 Mar 2011 19:46:52 -0700 (PDT) Received: from hqmta.chinamobile.com (hqmta.chinamobile.com [221.130.253.171]) by core3.amsl.com (Postfix) with ESMTP id F00083A6AB4 for ; Sun, 13 Mar 2011 19:46:51 -0700 (PDT) Received: from hqmta.chinamobile.com (localhost [127.0.0.1]) by localhost.imsstest.com (Postfix) with ESMTP id 7DC9E2100C; Mon, 14 Mar 2011 10:48:09 +0800 (CST) Received: from mail.chinamobile.com (unknown [10.1.28.22]) by hqmta.chinamobile.com (Postfix) with ESMTP id 7233B21008; Mon, 14 Mar 2011 10:48:09 +0800 (CST) Received: from zyf-PC ([10.2.2.220]) by mail.chinamobile.com (Lotus Domino Release 6.5.6) with ESMTP id 2011031410480781-6055 ; Mon, 14 Mar 2011 10:48:07 +0800 Date: Mon, 14 Mar 2011 10:48:07 +0800 From: "zhangyunfei" To: "li.lichun1@zte.com.cn" , "DECADE@ietf.org" References: Message-ID: <201103141048070715482@chinamobile.com> X-mailer: Foxmail 6, 2, 103, 20 [cn] Mime-Version: 1.0 X-MIMETrack: Itemize by SMTP Server on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2011-03-14 10:48:07, Serialize by Router on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2011-03-14 10:48:09, Serialize complete at 2011-03-14 10:48:09 Content-Type: multipart/alternative; boundary="=====003_Dragon641688824620_=====" X-TM-AS-Product-Ver: IMSS-7.0.0.8231-6.5.0.1024-18010.004 X-TM-AS-Result: No--23.405-7.0-31-10 X-imss-scan-details: No--23.405-7.0-31-10;No--23.405-5.0-31-10 X-TM-AS-User-Approved-Sender: No Subject: Re: [decade] How about modifying tracker to support DECADE? X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.9 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, 14 Mar 2011 02:46:53 -0000 This is a multi-part message in MIME format. --=====003_Dragon641688824620_===== Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="gb2312" SGkgTGljaHVuLA0KICAgIFRoaXMgaXMgYW4gaW50ZXJzdGluZyB0b3BpYyBJIHRob3VnaHQgYW5k IGRpc2N1c3NlZCBkdXJpbmcgdGhlIHNldCB1cCBvZiBQUFNQIGFuZCBERUNBREUuIFRoYW5rcyBm b3IgbWFraW5nIGl0IG1vcmUgY2xlYXI6KS5Tb21lIHN1Z2dlc3Rpb25zIGFyZSBhcyBmb2xsb3dz Og0KMSkgVGhlIHRhcmdldCBvZiB0aGlzIGRyYWZ0OiBJcyBpdCBiZXR0ZXIgdG8gZGlzY3VzcyB0 aGUgaW50ZXItb3BlYXJhYmlsaXR5IGJldHdlZW4gUFBTUCBhbmQgREVDQURFO29yIGRpc2N1c3Mg dGhlIHVzYWdlIG9mIERFQ0FERSBpbiBQUFNQPyBJIG1lYW4gdGhlIGZvY3VzIG1heSBiZSBhIGxp dHRsZSBiaXQgZGlmZmVyZW50OiBJbiB0aGUgZm9ybWVyIGNhc2UsIHRoZSBmb2N1cyBpcyBob3cg dGhlIHByb3RvY29scyBpbnRlci1hY3QgaW4gdGhlIG1lc2FnZSBvcHRpb25zIGV4Y2hhbmdlOyBp biB0aGUgbGF0dGVyIGNhc2UsIHRoZSBmb2N1cyBpcyBob3cgdGhlIFBQU1AgYXBwbGljYXRpb25z IHVzZSBERUNBREUgdG8gZW5oYW5jZSB0aGUgcGVyZm9ybWFuY2UuIEkgcHJlZmVyIHRvIHRha2lu ZyBpdCBhcyB0aGUgdXNhZ2UuDQoyKSBTaG91bGQgd2UgbWFrZSBERUNBREUgc2VydmVyIHNlbGVj dGlvbiB3aXRoIHByaW9yaXR5IGFsbCB0aGUgdGltZT8gSW4gdGhlIG1vYmlsZSBzZW5hcmlvLCBz dWNoIHNlbGVjdGlvbiBpcyByZWFzb25hYmxlOyBpbiB3aXJlZCBzZW5hcmlvLCBpdCBzZWVtcyBi ZXR0ZXIgdG8gc2VsZWN0IGdvb2QgZW5vdWdoIHBlZXJzIHdpdGhpbiBteSBMQU4gdGhhbiBzZWxl Y3QgREVDQURFIHNlcnZlcnMgd2hpY2ggaXMgbW9yZSBmYXIgZnJvbSBtZS4gVGhpcyB3aWxsIHJl ZHVjZSB0aGUgdW5uZWNlc3NhcnkgdHJhZmZpYyBhbmQgcHJvdmlkZSBiZXR0ZXIgcGVyZm9ybWFu Y2UuDQoNCkJSDQpZdW5mZWkNCg0KDQoNCg0Kemhhbmd5dW5mZWkNCjIwMTEtMDMtMTQNCg0KDQoN CreivP7Iy6O6IGxpLmxpY2h1bjFAenRlLmNvbS5jbg0Kt6LLzcqxvOSjuiAyMDExLTAzLTExIDE3 OjQ4OjM2DQrK1bz+yMujuiBERUNBREVAaWV0Zi5vcmcNCrOty82juiANCtb3zOKjuiBbZGVjYWRl XSBIb3cgYWJvdXQgbW9kaWZ5aW5nIHRyYWNrZXIgdG8gc3VwcG9ydCBERUNBREU/DQoNCg0KSGkg YWxsLCANCkl0IHNlZW1zIHRoYXQgdGhpcyBXRyBoYXMgbm90IGNvbnNpZGVyZWQgbW9kaWZ5aW5n IHRyYWNrZXIgdG8gc3VwcG9ydCBERUNBREUuIA0KSSBiZWxpZXZlIHRoYXQgbW9kaWZ5aW5nIGJv dGggdHJhY2tlciBhbmQgcGVlciBjYW4gbWFrZSBiZXR0ZXIgdXNlIG9mIERFQ0FERSBjb21wYXJl ZCB3aXRoIG1vZGlmeWluZyBwZWVyIG9ubHkuIA0KV2UgaGF2ZSBwcm9wb3NlZCB0d28gc29sdXRp b25zIGFuZCBzdWJtaXR0ZWQgYSBkcmFmdCBhYm91dCBleHRlbmRpbmcgUFBTUCB0byBzdXBwb3J0 IERFQ0FERSAoaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtbGUtcHBzcC1kZWNhZGUt aW50ZXJvcGVyYXRpb24tMDAudHh0IA0KKS4gVGhlIHNvbHV0aW9ucyBhbHNvIHB1dCBzb21lIHJl cXVpcmVtZW50cyBvbiBERUNBREUuIA0KSSBzdW1tYXJpemUgb3VyIHNvbHV0aW9ucyBhcyBiZWxv dy4gQ29tbWVudHMgYXJlIHdlbGNvbWUuIA0KDQpTb2x1dGlvbiAxIA0KRWFjaCBwZWVyIHJlcG9y dHMgdG8gdHJhY2tlciB0aGF0IHdoZXRoZXIgaXQgaGFzIERFQ0FERSBzZXJ2ZXIgb3Igbm90LiBQ ZWVyIEEgcXVlcmllcyBwZWVyIGxpc3QgZnJvbSB0cmFja2VyLiANClRoZSBwZWVyIGxpc3QgaW5k aWNhdGVzIHRoYXQgZWFjaCBwZWVyIGhhcyBERUNBREUgc2VydmVyIG9yIG5vdC4gVGhlIFBlZXIg QSBjYW4gcmVxdWVzdCBjb250ZW50IGZyb20gcGVlcnMgaGF2aW5nIERFQ0FERSBzZXJ2ZXJzIHdp dGggaGlnaCBwcmlvcml0eS4gDQoNClNvbHV0aW9uIDIgDQpUcmFja2VyIG1haW50YWlucyBERUNB REUgaW5mb3JtYXRpb24gKERFQ0FERSBsaXN0IGFuZCB0aGUgY29udGVudCBhdmFpbGFiaWxpdHkg aW5mb3JtYXRpb24gb2YgZWFjaCBERUNBREUgc2VydmVyKS4gUGVlciBBIHF1ZXJpZXMgbm9kZSBs aXN0IGZyb20gdHJhY2tlciBmb3IgZG93bmxvYWRpbmcgY29udGVudC4gVHJhY2tlciByZXR1cm5z IHRoZSBsaXN0IG9mIHBlZXJzIGFuZCBERUNBREUgc2VydmVycyBoYXZpbmcgcmVxdWVzdGVkIGNv bnRlbnQuIFRoZW4gUGVlciBBIGNhbiByZXF1ZXN0IGNvbnRlbnQgZnJvbSBvdGhlciBwZWVyJ3Mg b3IgdHJhY2tlcidzIERFQ0FERSBzZXJ2ZXIuIA0KSWYgdGhlIERFQ0FERSBzZXJ2aWNlIGlzIHJl bnQgYnkgcGVlcnMsIHBlZXJzIHVwbG9hZCBjb250ZW50cyB0byBERUNBREUgc2VydmVycyBhbmQg cmVwb3J0IHRoZSBERUNBREUgaW5mb3JtYXRpb24gdG8gdHJhY2tlci4gDQpJZiB0aGUgREVDQURF IHNlcnZpY2UgaXMgcmVudCBieSB0cmFja2VyIChpLmUuIFAyUCBjb250ZW50IHNoYXJpbmcgc2Vy dmljZSBwcm92aWRlciksIHRyYWNrZXIgaW5zdHJ1Y3QgcGVlcnMgdXBsb2FkaW5nIGNvbnRlbnRz IHRvIERFQ0FERSBzZXJ2ZXJzIG9yIERFQ0FERSBzZXJ2ZXJzIGRvd25sb2FkaW5nIGNvbnRlbnRz IGZyb20gcGVlcnMuIA0KDQpCUiANCkxpY2h1bg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KWlRFIEluZm9ybWF0aW9uIFNlY3VyaXR5 IE5vdGljZTogVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIG1haWwgaXMgc29sZWx5 IHByb3BlcnR5IG9mIHRoZSBzZW5kZXIncyBvcmdhbml6YXRpb24uIFRoaXMgbWFpbCBjb21tdW5p Y2F0aW9uIGlzIGNvbmZpZGVudGlhbC4gUmVjaXBpZW50cyBuYW1lZCBhYm92ZSBhcmUgb2JsaWdh dGVkIHRvIG1haW50YWluIHNlY3JlY3kgYW5kIGFyZSBub3QgcGVybWl0dGVkIHRvIGRpc2Nsb3Nl IHRoZSBjb250ZW50cyBvZiB0aGlzIGNvbW11bmljYXRpb24gdG8gb3RoZXJzLg0KVGhpcyBlbWFp bCBhbmQgYW55IGZpbGVzIHRyYW5zbWl0dGVkIHdpdGggaXQgYXJlIGNvbmZpZGVudGlhbCBhbmQg aW50ZW5kZWQgc29sZWx5IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsIG9yIGVudGl0eSB0 byB3aG9tIHRoZXkgYXJlIGFkZHJlc3NlZC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFp bCBpbiBlcnJvciBwbGVhc2Ugbm90aWZ5IHRoZSBvcmlnaW5hdG9yIG9mIHRoZSBtZXNzYWdlLiBB bnkgdmlld3MgZXhwcmVzc2VkIGluIHRoaXMgbWVzc2FnZSBhcmUgdGhvc2Ugb2YgdGhlIGluZGl2 aWR1YWwgc2VuZGVyLg0KVGhpcyBtZXNzYWdlIGhhcyBiZWVuIHNjYW5uZWQgZm9yIHZpcnVzZXMg YW5kIFNwYW0gYnkgWlRFIEFudGktU3BhbSBzeXN0ZW0uDQo= --=====003_Dragon641688824620_===== Content-Transfer-Encoding: base64 Content-Type: text/html; charset="gb2312" PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWdi MjMxMiIgaHR0cC1lcXVpdj1Db250ZW50LVR5cGU+DQo8TUVUQSBuYW1lPUdFTkVSQVRPUiBjb250 ZW50PSJNU0hUTUwgOC4wMC43NjAwLjE2NzIyIj4NCjxTVFlMRT4NCjwhLS0NCiAvKiBGb250IERl ZmluaXRpb25zICovDQogQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTrLzszlOw0KCXBhbm9zZS0x OjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpWZXJkYW5h Ow0KCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1m YW1pbHk6IlxAy87M5SI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQogLyogU3R5 bGUgRGVmaW5pdGlvbnMgKi8NCiBwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9y bWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCXRleHQtYWxpZ246 anVzdGlmeTsNCgl0ZXh0LWp1c3RpZnk6aW50ZXItaWRlb2dyYXBoOw0KCWZvbnQtc2l6ZToxMC41 cHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5 cGVybGluaw0KCXtjb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2 aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe2NvbG9yOnB1cnBsZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10 eXBlOnBlcnNvbmFsLWNvbXBvc2U7DQoJZm9udC1mYW1pbHk6VmVyZGFuYTsNCgljb2xvcjp3aW5k b3d0ZXh0Ow0KCWZvbnQtd2VpZ2h0Om5vcm1hbDsNCglmb250LXN0eWxlOm5vcm1hbDsNCgl0ZXh0 LWRlY29yYXRpb246bm9uZSBub25lO30NCiAvKiBQYWdlIERlZmluaXRpb25zICovDQogQHBhZ2Ug U2VjdGlvbjENCgl7c2l6ZTo1OTUuM3B0IDg0MS45cHQ7DQoJbWFyZ2luOjcyLjBwdCA5MC4wcHQg NzIuMHB0IDkwLjBwdDsNCglsYXlvdXQtZ3JpZDoxNS42cHQ7fQ0KZGl2LlNlY3Rpb24xDQoJe3Bh Z2U6U2VjdGlvbjE7fQ0KLS0+DQo8L1NUWUxFPg0KPC9IRUFEPg0KPEJPRFk+DQo8RElWPjxGT05U IGNvbG9yPSMwMDAwZmYgc2l6ZT0yIGZhY2U9VmVyZGFuYT4NCjxESVY+PEZPTlQgY29sb3I9IzAw MDBmZiBzaXplPTIgZmFjZT1WZXJkYW5hPkhpIExpY2h1biw8L0ZPTlQ+PC9ESVY+DQo8RElWPjxG T05UIGNvbG9yPSMwMDAwZmYgc2l6ZT0yIGZhY2U9VmVyZGFuYT4mbmJzcDsmbmJzcDsmbmJzcDsg VGhpcyBpcyBhbiANCmludGVyc3RpbmcgdG9waWMgSSZuYnNwO3Rob3VnaHQgYW5kIGRpc2N1c3Nl ZCBkdXJpbmcgdGhlIHNldCB1cCBvZiBQUFNQIGFuZCANCkRFQ0FERS4gVGhhbmtzIGZvciBtYWtp bmcgaXQgbW9yZSBjbGVhcjopLlNvbWUgc3VnZ2VzdGlvbnMgYXJlIGFzIA0KZm9sbG93czo8L0ZP TlQ+PC9ESVY+DQo8RElWPjxGT05UIGNvbG9yPSMwMDAwZmYgc2l6ZT0yIGZhY2U9VmVyZGFuYT4x KSBUaGUgdGFyZ2V0IG9mIHRoaXMgZHJhZnQ6IElzIGl0IA0KYmV0dGVyIHRvIGRpc2N1c3MgdGhl IGludGVyLW9wZWFyYWJpbGl0eSBiZXR3ZWVuIFBQU1AgYW5kIERFQ0FERTtvciBkaXNjdXNzIHRo ZSANCnVzYWdlIG9mIERFQ0FERSBpbiBQUFNQPyBJIG1lYW4gdGhlIGZvY3VzIG1heSBiZSBhIGxp dHRsZSBiaXQgZGlmZmVyZW50OiBJbiB0aGUgDQpmb3JtZXIgY2FzZSwgdGhlIGZvY3VzIGlzIGhv dyB0aGUgcHJvdG9jb2xzIGludGVyLWFjdCBpbiB0aGUgbWVzYWdlIG9wdGlvbnMgDQpleGNoYW5n ZTsgaW4gdGhlIGxhdHRlciBjYXNlLCB0aGUgZm9jdXMgaXMgaG93IHRoZSBQUFNQIGFwcGxpY2F0 aW9ucyB1c2UgREVDQURFIA0KdG8gZW5oYW5jZSB0aGUgcGVyZm9ybWFuY2UuIEkgcHJlZmVyIHRv IHRha2luZyBpdCBhcyB0aGUgdXNhZ2UuPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBjb2xvcj0j MDAwMGZmIHNpemU9MiBmYWNlPVZlcmRhbmE+MikgU2hvdWxkIHdlIG1ha2UgREVDQURFIHNlcnZl ciANCnNlbGVjdGlvbiB3aXRoIHByaW9yaXR5IGFsbCB0aGUgdGltZT8gSW4gdGhlIG1vYmlsZSBz ZW5hcmlvLCBzdWNoIHNlbGVjdGlvbiBpcyANCnJlYXNvbmFibGU7IGluIHdpcmVkIHNlbmFyaW8s IGl0IHNlZW1zIGJldHRlciB0byBzZWxlY3QgZ29vZCBlbm91Z2ggcGVlcnMgd2l0aGluIA0KbXkg TEFOIHRoYW4gc2VsZWN0IERFQ0FERSBzZXJ2ZXJzIHdoaWNoIGlzIG1vcmUgZmFyIGZyb20gbWUu IFRoaXMgd2lsbCByZWR1Y2UgDQp0aGUgdW5uZWNlc3NhcnkgdHJhZmZpYyBhbmQgcHJvdmlkZSBi ZXR0ZXIgcGVyZm9ybWFuY2UuPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBjb2xvcj0jMDAwMGZm IHNpemU9MiBmYWNlPVZlcmRhbmE+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBjb2xv cj0jMDAwMGZmIHNpemU9MiBmYWNlPVZlcmRhbmE+QlI8L0ZPTlQ+PC9ESVY+DQo8RElWPll1bmZl aTwvRElWPjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yIGZhY2U9VmVyZGFuYT48L0ZP TlQ+Jm5ic3A7PC9ESVY+DQo8RElWIGFsaWduPWxlZnQ+DQo8RElWIGFsaWduPWxlZnQ+PEZPTlQg c2l6ZT0yIGZhY2U9VmVyZGFuYT4NCjxIUiBzdHlsZT0iV0lEVEg6IDEyMnB4OyBIRUlHSFQ6IDJw eCIgU0laRT0yPg0KPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBjb2xvcj0jYzBjMGMwPjxGT05U IHNpemU9MiBmYWNlPVZlcmRhbmE+emhhbmd5dW5mZWk8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05U IHNpemU9MiBmYWNlPVZlcmRhbmE+MjAxMS0wMy0xNDwvRk9OVD48L0ZPTlQ+PC9ESVY+PC9ESVY+ DQo8RElWPjxGT05UIHNpemU9MiBmYWNlPVZlcmRhbmE+DQo8SFI+DQo8L0ZPTlQ+PC9ESVY+DQo8 RElWPjxGT05UIGZhY2U9VmVyZGFuYT48Rk9OVCBzaXplPTI+PFNUUk9ORz63orz+yMujujwvU1RS T05HPiANCmxpLmxpY2h1bjFAenRlLmNvbS5jbjwvRk9OVD48L0ZPTlQ+PC9ESVY+DQo8RElWPjxG T05UIGZhY2U9VmVyZGFuYT48Rk9OVCBzaXplPTI+PFNUUk9ORz63osvNyrG85KO6PC9TVFJPTkc+ IA0KMjAxMS0wMy0xMSZuYnNwOzE3OjQ4OjM2PC9GT05UPjwvRk9OVD48L0RJVj4NCjxESVY+PEZP TlQgZmFjZT1WZXJkYW5hPjxGT05UIHNpemU9Mj48U1RST05HPsrVvP7Iy6O6PC9TVFJPTkc+IA0K REVDQURFQGlldGYub3JnPC9GT05UPjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1WZXJk YW5hPjxGT05UIHNpemU9Mj48U1RST05HPrOty82jujwvU1RST05HPiA8L0ZPTlQ+PC9GT05UPjwv RElWPg0KPERJVj48Rk9OVCBmYWNlPVZlcmRhbmE+PEZPTlQgc2l6ZT0yPjxTVFJPTkc+1vfM4qO6 PC9TVFJPTkc+IFtkZWNhZGVdIEhvdyBhYm91dCANCm1vZGlmeWluZyB0cmFja2VyIHRvIHN1cHBv cnQgREVDQURFPzwvRk9OVD48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9MiBmYWNlPVZl cmRhbmE+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBzaXplPTIgZmFjZT1WZXJkYW5h PjxCUj48Rk9OVCBzaXplPTIgZmFjZT1zYW5zLXNlcmlmPkhpIGFsbCw8L0ZPTlQ+IA0KPEJSPjxG T05UIHNpemU9MiBmYWNlPXNhbnMtc2VyaWY+SXQgc2VlbXMgdGhhdCB0aGlzIFdHIGhhcyBub3Qg Y29uc2lkZXJlZCANCm1vZGlmeWluZyB0cmFja2VyIHRvIHN1cHBvcnQgREVDQURFLjwvRk9OVD4g PEJSPjxGT05UIHNpemU9MiBmYWNlPXNhbnMtc2VyaWY+SSANCmJlbGlldmUgdGhhdCBtb2RpZnlp bmcgYm90aCB0cmFja2VyIGFuZCBwZWVyIGNhbiBtYWtlIGJldHRlciB1c2Ugb2YgREVDQURFIA0K Y29tcGFyZWQgd2l0aCBtb2RpZnlpbmcgcGVlciBvbmx5LiA8L0ZPTlQ+PEJSPjxGT05UIHNpemU9 MiBmYWNlPXNhbnMtc2VyaWY+V2UgDQpoYXZlIHByb3Bvc2VkIHR3byBzb2x1dGlvbnMgYW5kIHN1 Ym1pdHRlZCBhIGRyYWZ0IGFib3V0IGV4dGVuZGluZyBQUFNQIHRvIA0Kc3VwcG9ydCBERUNBREUg DQooaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtbGUtcHBzcC1kZWNhZGUtaW50ZXJv cGVyYXRpb24tMDAudHh0PC9GT05UPiANCjxCUj48Rk9OVCBzaXplPTIgZmFjZT1zYW5zLXNlcmlm PikuIFRoZSBzb2x1dGlvbnMgYWxzbyBwdXQgc29tZSByZXF1aXJlbWVudHMgb24gDQpERUNBREUu PC9GT05UPiA8QlI+PEZPTlQgc2l6ZT0yIGZhY2U9c2Fucy1zZXJpZj5JIHN1bW1hcml6ZSBvdXIg c29sdXRpb25zIGFzIA0KYmVsb3cuIENvbW1lbnRzIGFyZSB3ZWxjb21lLjwvRk9OVD4gPEJSPjxC Uj48Rk9OVCBzaXplPTIgDQpmYWNlPXNhbnMtc2VyaWY+U29sdXRpb24gMTwvRk9OVD4gPEJSPjxG T05UIHNpemU9MiBmYWNlPXNhbnMtc2VyaWY+RWFjaCBwZWVyIA0KcmVwb3J0cyB0byB0cmFja2Vy IHRoYXQgd2hldGhlciBpdCBoYXMgREVDQURFIHNlcnZlciBvciBub3QuIFBlZXIgQSBxdWVyaWVz IHBlZXIgDQpsaXN0IGZyb20gdHJhY2tlci48L0ZPTlQ+IDxCUj48Rk9OVCBzaXplPTIgZmFjZT1z YW5zLXNlcmlmPlRoZSBwZWVyIGxpc3QgDQppbmRpY2F0ZXMgdGhhdCBlYWNoIHBlZXIgaGFzIERF Q0FERSBzZXJ2ZXIgb3Igbm90LiBUaGUgUGVlciBBIGNhbiByZXF1ZXN0IA0KY29udGVudCBmcm9t IHBlZXJzIGhhdmluZyBERUNBREUgc2VydmVycyB3aXRoIGhpZ2ggcHJpb3JpdHkuPC9GT05UPiAN CjxCUj48QlI+PEZPTlQgc2l6ZT0yIGZhY2U9c2Fucy1zZXJpZj5Tb2x1dGlvbiAyPC9GT05UPiA8 QlI+PEZPTlQgc2l6ZT0yIA0KZmFjZT1zYW5zLXNlcmlmPlRyYWNrZXIgbWFpbnRhaW5zIERFQ0FE RSBpbmZvcm1hdGlvbiAoREVDQURFIGxpc3QgYW5kIHRoZSANCmNvbnRlbnQgYXZhaWxhYmlsaXR5 IGluZm9ybWF0aW9uIG9mIGVhY2ggREVDQURFIHNlcnZlcikuIFBlZXIgQSBxdWVyaWVzIG5vZGUg DQpsaXN0IGZyb20gdHJhY2tlciBmb3IgZG93bmxvYWRpbmcgY29udGVudC4gVHJhY2tlciByZXR1 cm5zIHRoZSBsaXN0IG9mIHBlZXJzIGFuZCANCkRFQ0FERSBzZXJ2ZXJzIGhhdmluZyByZXF1ZXN0 ZWQgY29udGVudC4gVGhlbiBQZWVyIEEgY2FuIHJlcXVlc3QgY29udGVudCBmcm9tIA0Kb3RoZXIg cGVlcidzIG9yIHRyYWNrZXIncyBERUNBREUgc2VydmVyLjwvRk9OVD4gPEJSPjxGT05UIHNpemU9 MiANCmZhY2U9c2Fucy1zZXJpZj5JZiB0aGUgREVDQURFIHNlcnZpY2UgaXMgcmVudCBieSBwZWVy cywgcGVlcnMgdXBsb2FkIGNvbnRlbnRzIHRvIA0KREVDQURFIHNlcnZlcnMgYW5kIHJlcG9ydCB0 aGUgREVDQURFIGluZm9ybWF0aW9uIHRvIHRyYWNrZXIuPC9GT05UPiA8QlI+PEZPTlQgDQpzaXpl PTIgZmFjZT1zYW5zLXNlcmlmPklmIHRoZSBERUNBREUgc2VydmljZSBpcyByZW50IGJ5IHRyYWNr ZXIgKGkuZS4gUDJQIA0KY29udGVudCBzaGFyaW5nIHNlcnZpY2UgcHJvdmlkZXIpLCB0cmFja2Vy IGluc3RydWN0IHBlZXJzIHVwbG9hZGluZyBjb250ZW50cyB0byANCkRFQ0FERSBzZXJ2ZXJzIG9y IERFQ0FERSBzZXJ2ZXJzIGRvd25sb2FkaW5nIGNvbnRlbnRzIGZyb20gcGVlcnMuPC9GT05UPiAN CjxCUj48QlI+PEZPTlQgc2l6ZT0yIGZhY2U9c2Fucy1zZXJpZj5CUjwvRk9OVD4gPEJSPjxGT05U IHNpemU9MiANCmZhY2U9c2Fucy1zZXJpZj5MaWNodW48L0ZPTlQ+PEJSPjxQUkU+LS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClpURSZuYnNw O0luZm9ybWF0aW9uJm5ic3A7U2VjdXJpdHkmbmJzcDtOb3RpY2U6Jm5ic3A7VGhlJm5ic3A7aW5m b3JtYXRpb24mbmJzcDtjb250YWluZWQmbmJzcDtpbiZuYnNwO3RoaXMmbmJzcDttYWlsJm5ic3A7 aXMmbmJzcDtzb2xlbHkmbmJzcDtwcm9wZXJ0eSZuYnNwO29mJm5ic3A7dGhlJm5ic3A7c2VuZGVy J3MmbmJzcDtvcmdhbml6YXRpb24uJm5ic3A7VGhpcyZuYnNwO21haWwmbmJzcDtjb21tdW5pY2F0 aW9uJm5ic3A7aXMmbmJzcDtjb25maWRlbnRpYWwuJm5ic3A7UmVjaXBpZW50cyZuYnNwO25hbWVk Jm5ic3A7YWJvdmUmbmJzcDthcmUmbmJzcDtvYmxpZ2F0ZWQmbmJzcDt0byZuYnNwO21haW50YWlu Jm5ic3A7c2VjcmVjeSZuYnNwO2FuZCZuYnNwO2FyZSZuYnNwO25vdCZuYnNwO3Blcm1pdHRlZCZu YnNwO3RvJm5ic3A7ZGlzY2xvc2UmbmJzcDt0aGUmbmJzcDtjb250ZW50cyZuYnNwO29mJm5ic3A7 dGhpcyZuYnNwO2NvbW11bmljYXRpb24mbmJzcDt0byZuYnNwO290aGVycy4NClRoaXMmbmJzcDtl bWFpbCZuYnNwO2FuZCZuYnNwO2FueSZuYnNwO2ZpbGVzJm5ic3A7dHJhbnNtaXR0ZWQmbmJzcDt3 aXRoJm5ic3A7aXQmbmJzcDthcmUmbmJzcDtjb25maWRlbnRpYWwmbmJzcDthbmQmbmJzcDtpbnRl bmRlZCZuYnNwO3NvbGVseSZuYnNwO2ZvciZuYnNwO3RoZSZuYnNwO3VzZSZuYnNwO29mJm5ic3A7 dGhlJm5ic3A7aW5kaXZpZHVhbCZuYnNwO29yJm5ic3A7ZW50aXR5Jm5ic3A7dG8mbmJzcDt3aG9t Jm5ic3A7dGhleSZuYnNwO2FyZSZuYnNwO2FkZHJlc3NlZC4mbmJzcDtJZiZuYnNwO3lvdSZuYnNw O2hhdmUmbmJzcDtyZWNlaXZlZCZuYnNwO3RoaXMmbmJzcDtlbWFpbCZuYnNwO2luJm5ic3A7ZXJy b3ImbmJzcDtwbGVhc2UmbmJzcDtub3RpZnkmbmJzcDt0aGUmbmJzcDtvcmlnaW5hdG9yJm5ic3A7 b2YmbmJzcDt0aGUmbmJzcDttZXNzYWdlLiZuYnNwO0FueSZuYnNwO3ZpZXdzJm5ic3A7ZXhwcmVz c2VkJm5ic3A7aW4mbmJzcDt0aGlzJm5ic3A7bWVzc2FnZSZuYnNwO2FyZSZuYnNwO3Rob3NlJm5i c3A7b2YmbmJzcDt0aGUmbmJzcDtpbmRpdmlkdWFsJm5ic3A7c2VuZGVyLg0KVGhpcyZuYnNwO21l c3NhZ2UmbmJzcDtoYXMmbmJzcDtiZWVuJm5ic3A7c2Nhbm5lZCZuYnNwO2ZvciZuYnNwO3ZpcnVz ZXMmbmJzcDthbmQmbmJzcDtTcGFtJm5ic3A7YnkmbmJzcDtaVEUmbmJzcDtBbnRpLVNwYW0mbmJz cDtzeXN0ZW0uDQo8L1BSRT48L0ZPTlQ+PC9ESVY+PC9CT0RZPjwvSFRNTD4NCg== --=====003_Dragon641688824620_=====-- From li.lichun1@zte.com.cn Sun Mar 13 22:39:52 2011 Return-Path: X-Original-To: decade@core3.amsl.com Delivered-To: decade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F41A3A6A34 for ; Sun, 13 Mar 2011 22:39:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.311 X-Spam-Level: X-Spam-Status: No, score=-98.311 tagged_above=-999 required=5 tests=[AWL=-1.276, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_62=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id urHrjR0tfrOd for ; Sun, 13 Mar 2011 22:39:50 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [63.218.89.70]) by core3.amsl.com (Postfix) with ESMTP id 4A3F33A6AEC for ; Sun, 13 Mar 2011 22:39:47 -0700 (PDT) Received: from [10.34.0.130] by mx5.zte.com.cn with surfront esmtp id 35101047745636; Mon, 14 Mar 2011 13:38:48 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.15] with StormMail ESMTP id 84746.2351682932; Mon, 14 Mar 2011 13:41:02 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id p2E5evw1003531; Mon, 14 Mar 2011 13:40:57 +0800 (GMT-8) (envelope-from li.lichun1@zte.com.cn) In-Reply-To: <201103141048070715482@chinamobile.com> To: "zhangyunfei" MIME-Version: 1.0 X-KeepSent: 269AD3EC:827D3602-48257853:001F1F8E; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: li.lichun1@zte.com.cn Date: Mon, 14 Mar 2011 13:40:54 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-03-14 13:40:57, Serialize complete at 2011-03-14 13:40:57 Content-Type: multipart/alternative; boundary="=_alternative 001F46C348257853_=" X-MAIL: mse01.zte.com.cn p2E5evw1003531 Cc: "DECADE@ietf.org" Subject: Re: [decade] How about modifying tracker to support DECADE? X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.9 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, 14 Mar 2011 05:39:52 -0000 This is a multipart message in MIME format. --=_alternative 001F46C348257853_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGkgeXVuZmVpLA0KVGhhbmtzIGZvciB5b3VyIGNvbW1lbnRzLg0KMSkgVGhlIGZvY3VzIGlzIHRo ZSB1c2FnZSBvZiBERUNBREUgaW4gUFBTUC4gVGhlIHVzYWdlIGFsc28gbmVlZHMgc29tZSANCmV4 dGVuc2lvbnMgdG8gdGhlIHByb3RvY29scy4NCjIpIFlvdSBhcmUgcmlnaHQuIFRoZSBwcmlvcml0 eSBvZiBERUNBREUgZGVwZW5kcyBvbiBzY2VuYXJpbyBhbmQgDQpwZWVyL0RFQ0FERSBzZWxlY3Rp b24gYWxnb3JpdGhtLiBTb21ldGltZXMsIGRvd25sb2FkaW5nIGZyb20gcGVlciBpcyANCmJldHRl ci4gQWxzbywgc29tZSBzY2VuYXJpb3MgbWF5IHVzZSBERUNBREUgYXMgYmFja3VwIG9ubHkgYW5k IGdpdmUgbG93IA0KcHJpb3JpdHkgdG8gREVDQURFLg0KDQpCUg0KTGljaHVuDQoNCg0KDQoiemhh bmd5dW5mZWkiIDx6aGFuZ3l1bmZlaUBjaGluYW1vYmlsZS5jb20+IA0KMjAxMS0wMy0xNCAxMDo0 OA0KDQrK1bz+yMsNCiJsaS5saWNodW4xQHp0ZS5jb20uY24iIDxsaS5saWNodW4xQHp0ZS5jb20u Y24+LCAiREVDQURFQGlldGYub3JnIiANCjxERUNBREVAaWV0Zi5vcmc+DQqzrcvNDQoNCtb3zOIN ClJlOiBbZGVjYWRlXSBIb3cgYWJvdXQgbW9kaWZ5aW5nIHRyYWNrZXIgdG8gc3VwcG9ydCBERUNB REU/DQoNCg0KDQoNCg0KDQpIaSBMaWNodW4sDQogICAgVGhpcyBpcyBhbiBpbnRlcnN0aW5nIHRv cGljIEkgdGhvdWdodCBhbmQgZGlzY3Vzc2VkIGR1cmluZyB0aGUgc2V0IHVwIA0Kb2YgUFBTUCBh bmQgREVDQURFLiBUaGFua3MgZm9yIG1ha2luZyBpdCBtb3JlIGNsZWFyOikuU29tZSBzdWdnZXN0 aW9ucyBhcmUgDQphcyBmb2xsb3dzOg0KMSkgVGhlIHRhcmdldCBvZiB0aGlzIGRyYWZ0OiBJcyBp dCBiZXR0ZXIgdG8gZGlzY3VzcyB0aGUgDQppbnRlci1vcGVhcmFiaWxpdHkgYmV0d2VlbiBQUFNQ IGFuZCBERUNBREU7b3IgZGlzY3VzcyB0aGUgdXNhZ2Ugb2YgREVDQURFIA0KaW4gUFBTUD8gSSBt ZWFuIHRoZSBmb2N1cyBtYXkgYmUgYSBsaXR0bGUgYml0IGRpZmZlcmVudDogSW4gdGhlIGZvcm1l ciANCmNhc2UsIHRoZSBmb2N1cyBpcyBob3cgdGhlIHByb3RvY29scyBpbnRlci1hY3QgaW4gdGhl IG1lc2FnZSBvcHRpb25zIA0KZXhjaGFuZ2U7IGluIHRoZSBsYXR0ZXIgY2FzZSwgdGhlIGZvY3Vz IGlzIGhvdyB0aGUgUFBTUCBhcHBsaWNhdGlvbnMgdXNlIA0KREVDQURFIHRvIGVuaGFuY2UgdGhl IHBlcmZvcm1hbmNlLiBJIHByZWZlciB0byB0YWtpbmcgaXQgYXMgdGhlIHVzYWdlLg0KMikgU2hv dWxkIHdlIG1ha2UgREVDQURFIHNlcnZlciBzZWxlY3Rpb24gd2l0aCBwcmlvcml0eSBhbGwgdGhl IHRpbWU/IEluIA0KdGhlIG1vYmlsZSBzZW5hcmlvLCBzdWNoIHNlbGVjdGlvbiBpcyByZWFzb25h YmxlOyBpbiB3aXJlZCBzZW5hcmlvLCBpdCANCnNlZW1zIGJldHRlciB0byBzZWxlY3QgZ29vZCBl bm91Z2ggcGVlcnMgd2l0aGluIG15IExBTiB0aGFuIHNlbGVjdCBERUNBREUgDQpzZXJ2ZXJzIHdo aWNoIGlzIG1vcmUgZmFyIGZyb20gbWUuIFRoaXMgd2lsbCByZWR1Y2UgdGhlIHVubmVjZXNzYXJ5 IA0KdHJhZmZpYyBhbmQgcHJvdmlkZSBiZXR0ZXIgcGVyZm9ybWFuY2UuDQogDQpCUg0KWXVuZmVp DQogDQoNCnpoYW5neXVuZmVpDQoyMDExLTAzLTE0DQoNCreivP7Iy6O6IGxpLmxpY2h1bjFAenRl LmNvbS5jbg0Kt6LLzcqxvOSjuiAyMDExLTAzLTExIDE3OjQ4OjM2DQrK1bz+yMujuiBERUNBREVA aWV0Zi5vcmcNCrOty82juiANCtb3zOKjuiBbZGVjYWRlXSBIb3cgYWJvdXQgbW9kaWZ5aW5nIHRy YWNrZXIgdG8gc3VwcG9ydCBERUNBREU/DQogDQoNCkhpIGFsbCwgDQpJdCBzZWVtcyB0aGF0IHRo aXMgV0cgaGFzIG5vdCBjb25zaWRlcmVkIG1vZGlmeWluZyB0cmFja2VyIHRvIHN1cHBvcnQgDQpE RUNBREUuIA0KSSBiZWxpZXZlIHRoYXQgbW9kaWZ5aW5nIGJvdGggdHJhY2tlciBhbmQgcGVlciBj YW4gbWFrZSBiZXR0ZXIgdXNlIG9mIA0KREVDQURFIGNvbXBhcmVkIHdpdGggbW9kaWZ5aW5nIHBl ZXIgb25seS4gDQpXZSBoYXZlIHByb3Bvc2VkIHR3byBzb2x1dGlvbnMgYW5kIHN1Ym1pdHRlZCBh IGRyYWZ0IGFib3V0IGV4dGVuZGluZyBQUFNQIA0KdG8gc3VwcG9ydCBERUNBREUgKA0KaHR0cDov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtbGUtcHBzcC1kZWNhZGUtaW50ZXJvcGVyYXRpb24t MDAudHh0IA0KKS4gVGhlIHNvbHV0aW9ucyBhbHNvIHB1dCBzb21lIHJlcXVpcmVtZW50cyBvbiBE RUNBREUuIA0KSSBzdW1tYXJpemUgb3VyIHNvbHV0aW9ucyBhcyBiZWxvdy4gQ29tbWVudHMgYXJl IHdlbGNvbWUuIA0KDQpTb2x1dGlvbiAxIA0KRWFjaCBwZWVyIHJlcG9ydHMgdG8gdHJhY2tlciB0 aGF0IHdoZXRoZXIgaXQgaGFzIERFQ0FERSBzZXJ2ZXIgb3Igbm90LiANClBlZXIgQSBxdWVyaWVz IHBlZXIgbGlzdCBmcm9tIHRyYWNrZXIuIA0KVGhlIHBlZXIgbGlzdCBpbmRpY2F0ZXMgdGhhdCBl YWNoIHBlZXIgaGFzIERFQ0FERSBzZXJ2ZXIgb3Igbm90LiBUaGUgUGVlciANCkEgY2FuIHJlcXVl c3QgY29udGVudCBmcm9tIHBlZXJzIGhhdmluZyBERUNBREUgc2VydmVycyB3aXRoIGhpZ2ggcHJp b3JpdHkuIA0KDQoNClNvbHV0aW9uIDIgDQpUcmFja2VyIG1haW50YWlucyBERUNBREUgaW5mb3Jt YXRpb24gKERFQ0FERSBsaXN0IGFuZCB0aGUgY29udGVudCANCmF2YWlsYWJpbGl0eSBpbmZvcm1h dGlvbiBvZiBlYWNoIERFQ0FERSBzZXJ2ZXIpLiBQZWVyIEEgcXVlcmllcyBub2RlIGxpc3QgDQpm cm9tIHRyYWNrZXIgZm9yIGRvd25sb2FkaW5nIGNvbnRlbnQuIFRyYWNrZXIgcmV0dXJucyB0aGUg bGlzdCBvZiBwZWVycyANCmFuZCBERUNBREUgc2VydmVycyBoYXZpbmcgcmVxdWVzdGVkIGNvbnRl bnQuIFRoZW4gUGVlciBBIGNhbiByZXF1ZXN0IA0KY29udGVudCBmcm9tIG90aGVyIHBlZXIncyBv ciB0cmFja2VyJ3MgREVDQURFIHNlcnZlci4gDQpJZiB0aGUgREVDQURFIHNlcnZpY2UgaXMgcmVu dCBieSBwZWVycywgcGVlcnMgdXBsb2FkIGNvbnRlbnRzIHRvIERFQ0FERSANCnNlcnZlcnMgYW5k IHJlcG9ydCB0aGUgREVDQURFIGluZm9ybWF0aW9uIHRvIHRyYWNrZXIuIA0KSWYgdGhlIERFQ0FE RSBzZXJ2aWNlIGlzIHJlbnQgYnkgdHJhY2tlciAoaS5lLiBQMlAgY29udGVudCBzaGFyaW5nIHNl cnZpY2UgDQpwcm92aWRlciksIHRyYWNrZXIgaW5zdHJ1Y3QgcGVlcnMgdXBsb2FkaW5nIGNvbnRl bnRzIHRvIERFQ0FERSBzZXJ2ZXJzIG9yIA0KREVDQURFIHNlcnZlcnMgZG93bmxvYWRpbmcgY29u dGVudHMgZnJvbSBwZWVycy4gDQoNCkJSIA0KTGljaHVuDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KWlRFIEluZm9ybWF0aW9uIFNlY3Vy aXR5IE5vdGljZTogVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIG1haWwgaXMgDQpz b2xlbHkgcHJvcGVydHkgb2YgdGhlIHNlbmRlcidzIG9yZ2FuaXphdGlvbi4gVGhpcyBtYWlsIGNv bW11bmljYXRpb24gaXMgDQpjb25maWRlbnRpYWwuIFJlY2lwaWVudHMgbmFtZWQgYWJvdmUgYXJl IG9ibGlnYXRlZCB0byBtYWludGFpbiBzZWNyZWN5IGFuZCANCmFyZSBub3QgcGVybWl0dGVkIHRv IGRpc2Nsb3NlIHRoZSBjb250ZW50cyBvZiB0aGlzIGNvbW11bmljYXRpb24gdG8gDQpvdGhlcnMu DQpUaGlzIGVtYWlsIGFuZCBhbnkgZmlsZXMgdHJhbnNtaXR0ZWQgd2l0aCBpdCBhcmUgY29uZmlk ZW50aWFsIGFuZCBpbnRlbmRlZCANCnNvbGVseSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVh bCBvciBlbnRpdHkgdG8gd2hvbSB0aGV5IGFyZSBhZGRyZXNzZWQuIA0KSWYgeW91IGhhdmUgcmVj ZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciBwbGVhc2Ugbm90aWZ5IHRoZSBvcmlnaW5hdG9yIG9m IA0KdGhlIG1lc3NhZ2UuIEFueSB2aWV3cyBleHByZXNzZWQgaW4gdGhpcyBtZXNzYWdlIGFyZSB0 aG9zZSBvZiB0aGUgDQppbmRpdmlkdWFsIHNlbmRlci4NClRoaXMgbWVzc2FnZSBoYXMgYmVlbiBz Y2FubmVkIGZvciB2aXJ1c2VzIGFuZCBTcGFtIGJ5IFpURSBBbnRpLVNwYW0gDQpzeXN0ZW0uDQoN Cg0KDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tDQpaVEUgSW5mb3JtYXRpb24gU2VjdXJpdHkgTm90aWNlOiBUaGUgaW5mb3JtYXRpb24g Y29udGFpbmVkIGluIHRoaXMgbWFpbCBpcyBzb2xlbHkgcHJvcGVydHkgb2YgdGhlIHNlbmRlcidz IG9yZ2FuaXphdGlvbi4gVGhpcyBtYWlsIGNvbW11bmljYXRpb24gaXMgY29uZmlkZW50aWFsLiBS ZWNpcGllbnRzIG5hbWVkIGFib3ZlIGFyZSBvYmxpZ2F0ZWQgdG8gbWFpbnRhaW4gc2VjcmVjeSBh bmQgYXJlIG5vdCBwZXJtaXR0ZWQgdG8gZGlzY2xvc2UgdGhlIGNvbnRlbnRzIG9mIHRoaXMgY29t bXVuaWNhdGlvbiB0byBvdGhlcnMuDQpUaGlzIGVtYWlsIGFuZCBhbnkgZmlsZXMgdHJhbnNtaXR0 ZWQgd2l0aCBpdCBhcmUgY29uZmlkZW50aWFsIGFuZCBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1 c2Ugb2YgdGhlIGluZGl2aWR1YWwgb3IgZW50aXR5IHRvIHdob20gdGhleSBhcmUgYWRkcmVzc2Vk LiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yIHBsZWFzZSBub3RpZnkg dGhlIG9yaWdpbmF0b3Igb2YgdGhlIG1lc3NhZ2UuIEFueSB2aWV3cyBleHByZXNzZWQgaW4gdGhp cyBtZXNzYWdlIGFyZSB0aG9zZSBvZiB0aGUgaW5kaXZpZHVhbCBzZW5kZXIuDQpUaGlzIG1lc3Nh Z2UgaGFzIGJlZW4gc2Nhbm5lZCBmb3IgdmlydXNlcyBhbmQgU3BhbSBieSBaVEUgQW50aS1TcGFt IHN5c3RlbS4NCg== --=_alternative 001F46C348257853_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIHl1bmZlaSw8L2ZvbnQ+DQo8 YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlRoYW5rcyBmb3IgeW91ciBjb21tZW50 cy48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjEpIFRoZSBmb2N1 cyBpcyB0aGUgdXNhZ2Ugb2YgREVDQURFDQppbiBQUFNQLiBUaGUgdXNhZ2UgYWxzbyBuZWVkcyBz b21lIGV4dGVuc2lvbnMgdG8gdGhlIHByb3RvY29scy48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0y IGZhY2U9InNhbnMtc2VyaWYiPjIpIFlvdSBhcmUgcmlnaHQuIFRoZSBwcmlvcml0eSBvZiBERUNB REUNCmRlcGVuZHMgb24gc2NlbmFyaW8gYW5kIHBlZXIvREVDQURFIHNlbGVjdGlvbiBhbGdvcml0 aG0uIFNvbWV0aW1lcywgZG93bmxvYWRpbmcNCmZyb20gcGVlciBpcyBiZXR0ZXIuIEFsc28sIHNv bWUgc2NlbmFyaW9zIG1heSB1c2UgREVDQURFIGFzIGJhY2t1cCBvbmx5DQphbmQgZ2l2ZSBsb3cg cHJpb3JpdHkgdG8gREVDQURFLjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0i c2Fucy1zZXJpZiI+QlI8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYi PkxpY2h1bjwvZm9udD4NCjxicj4NCjxicj4NCjxicj4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRy IHZhbGlnbj10b3A+DQo8dGQgd2lkdGg9MzUlPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlm Ij48Yj4mcXVvdDt6aGFuZ3l1bmZlaSZxdW90Ow0KJmx0O3poYW5neXVuZmVpQGNoaW5hbW9iaWxl LmNvbSZndDs8L2I+IDwvZm9udD4NCjxwPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4y MDExLTAzLTE0IDEwOjQ4PC9mb250Pg0KPHRkIHdpZHRoPTY0JT4NCjx0YWJsZSB3aWR0aD0xMDAl Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBm YWNlPSJzYW5zLXNlcmlmIj7K1bz+yMs8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZh Y2U9InNhbnMtc2VyaWYiPiZxdW90O2xpLmxpY2h1bjFAenRlLmNvbS5jbiZxdW90OyAmbHQ7bGku bGljaHVuMUB6dGUuY29tLmNuJmd0OywNCiZxdW90O0RFQ0FERUBpZXRmLm9yZyZxdW90OyAmbHQ7 REVDQURFQGlldGYub3JnJmd0OzwvZm9udD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBh bGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+s63LzTwvZm9udD48L2Rp dj4NCjx0ZD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBz aXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+1vfM4jwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXpl PTEgZmFjZT0ic2Fucy1zZXJpZiI+UmU6IFtkZWNhZGVdIEhvdyBhYm91dCBtb2RpZnlpbmcgdHJh Y2tlcg0KdG8gc3VwcG9ydCBERUNBREU/PC9mb250PjwvdGFibGU+DQo8YnI+DQo8dGFibGU+DQo8 dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjx0ZD48L3RhYmxlPg0KPGJyPjwvdGFibGU+DQo8YnI+DQo8 YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWUgZmFjZT0iVmVyZGFuYSI+SGkgTGljaHVu LDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNlPSJWZXJkYW5hIj4mbmJz cDsgJm5ic3A7IFRoaXMgaXMgYW4gaW50ZXJzdGluZw0KdG9waWMgSSB0aG91Z2h0IGFuZCBkaXNj dXNzZWQgZHVyaW5nIHRoZSBzZXQgdXAgb2YgUFBTUCBhbmQgREVDQURFLiBUaGFua3MNCmZvciBt YWtpbmcgaXQgbW9yZSBjbGVhcjopLlNvbWUgc3VnZ2VzdGlvbnMgYXJlIGFzIGZvbGxvd3M6PC9m b250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj1ibHVlIGZhY2U9IlZlcmRhbmEiPjEpIFRoZSB0 YXJnZXQgb2YgdGhpcyBkcmFmdDoNCklzIGl0IGJldHRlciB0byBkaXNjdXNzIHRoZSBpbnRlci1v cGVhcmFiaWxpdHkgYmV0d2VlbiBQUFNQIGFuZCBERUNBREU7b3INCmRpc2N1c3MgdGhlIHVzYWdl IG9mIERFQ0FERSBpbiBQUFNQPyBJIG1lYW4gdGhlIGZvY3VzIG1heSBiZSBhIGxpdHRsZSBiaXQN CmRpZmZlcmVudDogSW4gdGhlIGZvcm1lciBjYXNlLCB0aGUgZm9jdXMgaXMgaG93IHRoZSBwcm90 b2NvbHMgaW50ZXItYWN0DQppbiB0aGUgbWVzYWdlIG9wdGlvbnMgZXhjaGFuZ2U7IGluIHRoZSBs YXR0ZXIgY2FzZSwgdGhlIGZvY3VzIGlzIGhvdyB0aGUNClBQU1AgYXBwbGljYXRpb25zIHVzZSBE RUNBREUgdG8gZW5oYW5jZSB0aGUgcGVyZm9ybWFuY2UuIEkgcHJlZmVyIHRvIHRha2luZw0KaXQg YXMgdGhlIHVzYWdlLjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNlPSJW ZXJkYW5hIj4yKSBTaG91bGQgd2UgbWFrZSBERUNBREUgc2VydmVyDQpzZWxlY3Rpb24gd2l0aCBw cmlvcml0eSBhbGwgdGhlIHRpbWU/IEluIHRoZSBtb2JpbGUgc2VuYXJpbywgc3VjaCBzZWxlY3Rp b24NCmlzIHJlYXNvbmFibGU7IGluIHdpcmVkIHNlbmFyaW8sIGl0IHNlZW1zIGJldHRlciB0byBz ZWxlY3QgZ29vZCBlbm91Z2gNCnBlZXJzIHdpdGhpbiBteSBMQU4gdGhhbiBzZWxlY3QgREVDQURF IHNlcnZlcnMgd2hpY2ggaXMgbW9yZSBmYXIgZnJvbSBtZS4NClRoaXMgd2lsbCByZWR1Y2UgdGhl IHVubmVjZXNzYXJ5IHRyYWZmaWMgYW5kIHByb3ZpZGUgYmV0dGVyIHBlcmZvcm1hbmNlLjwvZm9u dD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNlPSJWZXJkYW5hIj4mbmJzcDs8L2Zv bnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWUgZmFjZT0iVmVyZGFuYSI+QlI8L2ZvbnQ+ DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWUgZmFjZT0iVmVyZGFuYSI+WXVuZmVpPC9mb250 Pg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDs8L2ZvbnQ+DQo8YnI+ DQo8aHI+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSNjMGMwYzAgZmFjZT0iVmVyZGFuYSI+emhh bmd5dW5mZWk8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSNjMGMwYzAgZmFjZT0iVmVy ZGFuYSI+MjAxMS0wMy0xNDwvZm9udD4NCjxicj4NCjxocj4NCjxicj48Zm9udCBzaXplPTIgZmFj ZT0iVmVyZGFuYSI+PGI+t6K8/sjLo7o8L2I+IGxpLmxpY2h1bjFAenRlLmNvbS5jbjwvZm9udD4N Cjxicj48Zm9udCBzaXplPTIgZmFjZT0iVmVyZGFuYSI+PGI+t6LLzcqxvOSjujwvYj4gMjAxMS0w My0xMSAxNzo0ODozNjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iVmVyZGFuYSI+PGI+ ytW8/sjLo7o8L2I+IERFQ0FERUBpZXRmLm9yZzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFj ZT0iVmVyZGFuYSI+PGI+s63LzaO6PC9iPiA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9 IlZlcmRhbmEiPjxiPtb3zOKjujwvYj4gW2RlY2FkZV0gSG93IGFib3V0IG1vZGlmeWluZw0KdHJh Y2tlciB0byBzdXBwb3J0IERFQ0FERT88L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9InNh bnMtc2VyaWYiPiZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJp ZiI+PGJyPg0KSGkgYWxsLDwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iVmVyZGFuYSI+IDwvZm9u dD48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0KSXQgc2VlbXMgdGhhdCB0aGlz IFdHIGhhcyBub3QgY29uc2lkZXJlZCBtb2RpZnlpbmcgdHJhY2tlciB0byBzdXBwb3J0IERFQ0FE RS48L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IlZlcmRhbmEiPg0KPC9mb250Pjxmb250IHNpemU9 MiBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQpJIGJlbGlldmUgdGhhdCBtb2RpZnlpbmcgYm90aCB0 cmFja2VyIGFuZCBwZWVyIGNhbiBtYWtlIGJldHRlciB1c2Ugb2YgREVDQURFDQpjb21wYXJlZCB3 aXRoIG1vZGlmeWluZyBwZWVyIG9ubHkuIDxicj4NCldlIGhhdmUgcHJvcG9zZWQgdHdvIHNvbHV0 aW9ucyBhbmQgc3VibWl0dGVkIGEgZHJhZnQgYWJvdXQgZXh0ZW5kaW5nIFBQU1ANCnRvIHN1cHBv cnQgREVDQURFIChodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1sZS1wcHNwLWRlY2Fk ZS1pbnRlcm9wZXJhdGlvbi0wMC50eHQ8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IlZlcmRhbmEi Pg0KPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQopLiBUaGUgc29s dXRpb25zIGFsc28gcHV0IHNvbWUgcmVxdWlyZW1lbnRzIG9uIERFQ0FERS48L2ZvbnQ+PGZvbnQg c2l6ZT0yIGZhY2U9IlZlcmRhbmEiPg0KPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNl cmlmIj48YnI+DQpJIHN1bW1hcml6ZSBvdXIgc29sdXRpb25zIGFzIGJlbG93LiBDb21tZW50cyBh cmUgd2VsY29tZS48L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IlZlcmRhbmEiPg0KPGJyPg0KPC9m b250Pjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQpTb2x1dGlvbiAxPC9mb250 Pjxmb250IHNpemU9MiBmYWNlPSJWZXJkYW5hIj4gPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJz YW5zLXNlcmlmIj48YnI+DQpFYWNoIHBlZXIgcmVwb3J0cyB0byB0cmFja2VyIHRoYXQgd2hldGhl ciBpdCBoYXMgREVDQURFIHNlcnZlciBvciBub3QuDQpQZWVyIEEgcXVlcmllcyBwZWVyIGxpc3Qg ZnJvbSB0cmFja2VyLjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iVmVyZGFuYSI+DQo8L2ZvbnQ+ PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjxicj4NClRoZSBwZWVyIGxpc3QgaW5kaWNh dGVzIHRoYXQgZWFjaCBwZWVyIGhhcyBERUNBREUgc2VydmVyIG9yIG5vdC4gVGhlIFBlZXINCkEg Y2FuIHJlcXVlc3QgY29udGVudCBmcm9tIHBlZXJzIGhhdmluZyBERUNBREUgc2VydmVycyB3aXRo IGhpZ2ggcHJpb3JpdHkuPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJWZXJkYW5hIj4NCjxicj4N CjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0KU29sdXRpb24gMjwv Zm9udD48Zm9udCBzaXplPTIgZmFjZT0iVmVyZGFuYSI+IDwvZm9udD48Zm9udCBzaXplPTIgZmFj ZT0ic2Fucy1zZXJpZiI+PGJyPg0KVHJhY2tlciBtYWludGFpbnMgREVDQURFIGluZm9ybWF0aW9u IChERUNBREUgbGlzdCBhbmQgdGhlIGNvbnRlbnQgYXZhaWxhYmlsaXR5DQppbmZvcm1hdGlvbiBv ZiBlYWNoIERFQ0FERSBzZXJ2ZXIpLiBQZWVyIEEgcXVlcmllcyBub2RlIGxpc3QgZnJvbSB0cmFj a2VyDQpmb3IgZG93bmxvYWRpbmcgY29udGVudC4gVHJhY2tlciByZXR1cm5zIHRoZSBsaXN0IG9m IHBlZXJzIGFuZCBERUNBREUgc2VydmVycw0KaGF2aW5nIHJlcXVlc3RlZCBjb250ZW50LiBUaGVu IFBlZXIgQSBjYW4gcmVxdWVzdCBjb250ZW50IGZyb20gb3RoZXIgcGVlcidzDQpvciB0cmFja2Vy J3MgREVDQURFIHNlcnZlci48L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IlZlcmRhbmEiPiA8L2Zv bnQ+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjxicj4NCklmIHRoZSBERUNBREUgc2Vy dmljZSBpcyByZW50IGJ5IHBlZXJzLCBwZWVycyB1cGxvYWQgY29udGVudHMgdG8gREVDQURFDQpz ZXJ2ZXJzIGFuZCByZXBvcnQgdGhlIERFQ0FERSBpbmZvcm1hdGlvbiB0byB0cmFja2VyLjwvZm9u dD48Zm9udCBzaXplPTIgZmFjZT0iVmVyZGFuYSI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9 InNhbnMtc2VyaWYiPjxicj4NCklmIHRoZSBERUNBREUgc2VydmljZSBpcyByZW50IGJ5IHRyYWNr ZXIgKGkuZS4gUDJQIGNvbnRlbnQgc2hhcmluZyBzZXJ2aWNlDQpwcm92aWRlciksIHRyYWNrZXIg aW5zdHJ1Y3QgcGVlcnMgdXBsb2FkaW5nIGNvbnRlbnRzIHRvIERFQ0FERSBzZXJ2ZXJzDQpvciBE RUNBREUgc2VydmVycyBkb3dubG9hZGluZyBjb250ZW50cyBmcm9tIHBlZXJzLjwvZm9udD48Zm9u dCBzaXplPTIgZmFjZT0iVmVyZGFuYSI+DQo8YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9 InNhbnMtc2VyaWYiPjxicj4NCkJSPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJWZXJkYW5hIj4g PC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQpMaWNodW48L2ZvbnQ+ DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IlZlcmRhbmEiPi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0KWlRFIEluZm9ybWF0aW9uIFNl Y3VyaXR5IE5vdGljZTogVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIG1haWwNCmlz IHNvbGVseSBwcm9wZXJ0eSBvZiB0aGUgc2VuZGVyJ3Mgb3JnYW5pemF0aW9uLiBUaGlzIG1haWwg Y29tbXVuaWNhdGlvbg0KaXMgY29uZmlkZW50aWFsLiBSZWNpcGllbnRzIG5hbWVkIGFib3ZlIGFy ZSBvYmxpZ2F0ZWQgdG8gbWFpbnRhaW4gc2VjcmVjeQ0KYW5kIGFyZSBub3QgcGVybWl0dGVkIHRv IGRpc2Nsb3NlIHRoZSBjb250ZW50cyBvZiB0aGlzIGNvbW11bmljYXRpb24gdG8NCm90aGVycy48 YnI+DQpUaGlzIGVtYWlsIGFuZCBhbnkgZmlsZXMgdHJhbnNtaXR0ZWQgd2l0aCBpdCBhcmUgY29u ZmlkZW50aWFsIGFuZCBpbnRlbmRlZA0Kc29sZWx5IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlk dWFsIG9yIGVudGl0eSB0byB3aG9tIHRoZXkgYXJlIGFkZHJlc3NlZC4NCklmIHlvdSBoYXZlIHJl Y2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IgcGxlYXNlIG5vdGlmeSB0aGUgb3JpZ2luYXRvciBv Zg0KdGhlIG1lc3NhZ2UuIEFueSB2aWV3cyBleHByZXNzZWQgaW4gdGhpcyBtZXNzYWdlIGFyZSB0 aG9zZSBvZiB0aGUgaW5kaXZpZHVhbA0Kc2VuZGVyLjxicj4NClRoaXMgbWVzc2FnZSBoYXMgYmVl biBzY2FubmVkIGZvciB2aXJ1c2VzIGFuZCBTcGFtIGJ5IFpURSBBbnRpLVNwYW0gc3lzdGVtLjxi cj4NCjwvZm9udD4NCjxicj4NCjxicj48cHJlPg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClpURSZuYnNwO0luZm9ybWF0aW9uJm5ic3A7 U2VjdXJpdHkmbmJzcDtOb3RpY2U6Jm5ic3A7VGhlJm5ic3A7aW5mb3JtYXRpb24mbmJzcDtjb250 YWluZWQmbmJzcDtpbiZuYnNwO3RoaXMmbmJzcDttYWlsJm5ic3A7aXMmbmJzcDtzb2xlbHkmbmJz cDtwcm9wZXJ0eSZuYnNwO29mJm5ic3A7dGhlJm5ic3A7c2VuZGVyJ3MmbmJzcDtvcmdhbml6YXRp b24uJm5ic3A7VGhpcyZuYnNwO21haWwmbmJzcDtjb21tdW5pY2F0aW9uJm5ic3A7aXMmbmJzcDtj b25maWRlbnRpYWwuJm5ic3A7UmVjaXBpZW50cyZuYnNwO25hbWVkJm5ic3A7YWJvdmUmbmJzcDth cmUmbmJzcDtvYmxpZ2F0ZWQmbmJzcDt0byZuYnNwO21haW50YWluJm5ic3A7c2VjcmVjeSZuYnNw O2FuZCZuYnNwO2FyZSZuYnNwO25vdCZuYnNwO3Blcm1pdHRlZCZuYnNwO3RvJm5ic3A7ZGlzY2xv c2UmbmJzcDt0aGUmbmJzcDtjb250ZW50cyZuYnNwO29mJm5ic3A7dGhpcyZuYnNwO2NvbW11bmlj YXRpb24mbmJzcDt0byZuYnNwO290aGVycy4NClRoaXMmbmJzcDtlbWFpbCZuYnNwO2FuZCZuYnNw O2FueSZuYnNwO2ZpbGVzJm5ic3A7dHJhbnNtaXR0ZWQmbmJzcDt3aXRoJm5ic3A7aXQmbmJzcDth cmUmbmJzcDtjb25maWRlbnRpYWwmbmJzcDthbmQmbmJzcDtpbnRlbmRlZCZuYnNwO3NvbGVseSZu YnNwO2ZvciZuYnNwO3RoZSZuYnNwO3VzZSZuYnNwO29mJm5ic3A7dGhlJm5ic3A7aW5kaXZpZHVh bCZuYnNwO29yJm5ic3A7ZW50aXR5Jm5ic3A7dG8mbmJzcDt3aG9tJm5ic3A7dGhleSZuYnNwO2Fy ZSZuYnNwO2FkZHJlc3NlZC4mbmJzcDtJZiZuYnNwO3lvdSZuYnNwO2hhdmUmbmJzcDtyZWNlaXZl ZCZuYnNwO3RoaXMmbmJzcDtlbWFpbCZuYnNwO2luJm5ic3A7ZXJyb3ImbmJzcDtwbGVhc2UmbmJz cDtub3RpZnkmbmJzcDt0aGUmbmJzcDtvcmlnaW5hdG9yJm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtt ZXNzYWdlLiZuYnNwO0FueSZuYnNwO3ZpZXdzJm5ic3A7ZXhwcmVzc2VkJm5ic3A7aW4mbmJzcDt0 aGlzJm5ic3A7bWVzc2FnZSZuYnNwO2FyZSZuYnNwO3Rob3NlJm5ic3A7b2YmbmJzcDt0aGUmbmJz cDtpbmRpdmlkdWFsJm5ic3A7c2VuZGVyLg0KVGhpcyZuYnNwO21lc3NhZ2UmbmJzcDtoYXMmbmJz cDtiZWVuJm5ic3A7c2Nhbm5lZCZuYnNwO2ZvciZuYnNwO3ZpcnVzZXMmbmJzcDthbmQmbmJzcDtT cGFtJm5ic3A7YnkmbmJzcDtaVEUmbmJzcDtBbnRpLVNwYW0mbmJzcDtzeXN0ZW0uDQo8L3ByZT4= --=_alternative 001F46C348257853_=-- From Internet-Drafts@ietf.org Mon Mar 14 08:30:28 2011 Return-Path: X-Original-To: decade@core3.amsl.com Delivered-To: decade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6AB8B3A6D3C; Mon, 14 Mar 2011 08:30:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.573 X-Spam-Level: X-Spam-Status: No, score=-102.573 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f7XDhpGOtFWF; Mon, 14 Mar 2011 08:30:23 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A76723A6D59; Mon, 14 Mar 2011 08:30:09 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110314153009.29808.77044.idtracker@localhost> Date: Mon, 14 Mar 2011 08:30:09 -0700 Cc: decade@ietf.org Subject: [decade] I-D Action:draft-ietf-decade-problem-statement-03.txt X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.9 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, 14 Mar 2011 15:30:28 -0000 --NextPart 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 : DECoupled Application Data Enroute (DECADE) Problem Statement Author(s) : H. Song, et al. Filename : draft-ietf-decade-problem-statement-03.txt Pages : 19 Date : 2011-03-14 Peer-to-peer (P2P) applications have become widely used on the Internet today and make up a large portion of the traffic in many networks. In P2P applications, one technique for reducing the transit and uplink P2P traffic is to introduce storage capabilities within the network (the download traffic may increase because the in- network storage is likely much better connected). Traditional P2P and Web caches provide such storage, but they are complex (due to explicitly supporting individual P2P application protocols and cache refreshing mechanisms) and they do not allow users to manage access to content in the cache. For example, content providers cannot easily control cache access and resource usage policies to satisfy their own requirements, in the case when the content provider is also the user of in-network storage. This document discusses the introduction of in-network storage for P2P applications, shows the need for a standard protocol for accessing this storage, and identifies the scope of this protocol. The access protocol can also be used by other applications with similar requirements. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-decade-problem-statement-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-decade-problem-statement-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-03-14082926.I-D@ietf.org> --NextPart-- From Internet-Drafts@ietf.org Mon Mar 14 14:00:04 2011 Return-Path: X-Original-To: decade@core3.amsl.com Delivered-To: decade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F8BD3A6F0D; Mon, 14 Mar 2011 14:00:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.466 X-Spam-Level: X-Spam-Status: No, score=-102.466 tagged_above=-999 required=5 tests=[AWL=-0.094, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kNGZpdbgvsTn; Mon, 14 Mar 2011 14:00:03 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A1CF43A6EE8; Mon, 14 Mar 2011 14:00:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110314210002.8579.65432.idtracker@localhost> Date: Mon, 14 Mar 2011 14:00:02 -0700 Cc: decade@ietf.org Subject: [decade] I-D Action:draft-ietf-decade-reqs-01.txt X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.9 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, 14 Mar 2011 21:00:04 -0000 --NextPart 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) : G. Yingjie, et al. Filename : draft-ietf-decade-reqs-01.txt Pages : 21 Date : 2011-03-14 The target of DECoupled Application Data Enroute (DECADE) is to provide an open and standard in-network storage system for applications, primarily P2P applications, to store, retrieve and manage their data. This draft enumerates and explains requirements, not only for store and retrieve, but also for data management, access control and resource control, that should be considered during the design and implementation of a DECADE 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., the data transport level). A user of DECADE as a complete architecture would be guaranteed complete functionality. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-decade-reqs-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-decade-reqs-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-03-14134712.I-D@ietf.org> --NextPart-- From borje.ohlman@ericsson.com Wed Mar 16 06:22:16 2011 Return-Path: X-Original-To: decade@core3.amsl.com Delivered-To: decade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C6D33A6994; Wed, 16 Mar 2011 06:22:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.298 X-Spam-Level: X-Spam-Status: No, score=-6.298 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FjthqnPAKAGu; Wed, 16 Mar 2011 06:22:14 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 28BEF3A6990; Wed, 16 Mar 2011 06:22:09 -0700 (PDT) X-AuditID: c1b4fb39-b7c6dae0000023f2-23-4d80b9d7e9bf Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 29.8F.09202.7D9B08D4; Wed, 16 Mar 2011 14:23:35 +0100 (CET) Received: from abro.ki.sw.ericsson.se (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.2.234.1; Wed, 16 Mar 2011 14:23:34 +0100 Received: from [IPv6:::1] (abro.ki.sw.ericsson.se [147.214.177.159]) by abro.ki.sw.ericsson.se (Postfix) with ESMTP id BA0E227980; Wed, 16 Mar 2011 14:23:34 +0100 (CET) From: =?iso-8859-1?Q?B=F6rje_Ohlman?= Content-Type: multipart/alternative; boundary="Apple-Mail-77--147932781" Date: Wed, 16 Mar 2011 14:23:34 +0100 References: <20110314205442.844303A6EE4@core3.amsl.com> To: decade ietf , ppsp@ietf.org, cdni ietf Message-ID: <437C8C77-EC3D-4D39-A3FA-881B7E1D260B@ericsson.com> MIME-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) X-Brightmail-Tracker: AAAAAA== Subject: [decade] Fwd: New Version Notification for draft-dannewitz-ppsp-secure-naming-02 X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.9 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, 16 Mar 2011 13:22:16 -0000 --Apple-Mail-77--147932781 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" We have made a new version of this draft, originally directed towards = ppsp. The main change in this draft is that it has been generalized so = that it is applicable to any protocol that have a need to name = information/data objects in addition to nodes and interfaces. At the upcoming IETF we hope to present it in the DECADE WG. Potentially = we think this could also be of interest for CDNI. B=F6rje Ohlman Begin forwarded message: > From: IETF I-D Submission Tool > Date: 14 mars 2011 21.54.42 CET > To: B=F6rje Ohlman > Cc: "cdannewitz@upb.de" , "teemu.rautio@vtt.fi" = , "ove.strandberg@nsn.com" > Subject: New Version Notification for = draft-dannewitz-ppsp-secure-naming-02=20 >=20 >=20 > A new version of I-D, draft-dannewitz-ppsp-secure-naming-02.txt has = been successfully submitted by Borje Ohlman and posted to the IETF = repository. >=20 > Filename: draft-dannewitz-ppsp-secure-naming > Revision: 02 > Title: Secure naming structure and p2p application = interaction > Creation_date: 2011-03-14 > WG ID: Independent Submission > Number_of_pages: 15 >=20 > Abstract: > Today, each application typically uses its own way to identify data. > The lack of a common naming scheme prevents applications from > benefiting from available copies of the same data distributed via > different P2P and CDN systems. The main proposal presented in this > draft is idea that there should be a secure and application > independent way of naming information objects that are transported > over the Internet. The draft defines a set of requirements for such > a naming structure. It also presents a proposal for such a naming > structure that could relevant for a number of work groups (existing > and potential), e.g. PPSP, DECADE and CDNI. In addition, today's > P2P naming schemes lack important security aspects that would allow > the user to check the data integrity and build trust in data and data > publishers. This is especially important in P2P applications as data > is received from untrusted peers. Providing a generic naming scheme > for P2P systems so that multiple P2P systems can use the same data > regardless of data location and P2P system increases the efficiency > and data availability of the overall data dissemination process. The > secure naming scheme is providing self-certification such that the > receiver can verify the data integrity, i.e., that the correct data > has been received, without requiring a trusted third party. It also > enables owner authentication to build up trust in (potentially > anonymous) data publishers. The secure naming structure should be > beneficial as potential design principle in defining the two > protocols identified as objectives in the PPSP charter. This > document enumerates a number of design considerations to impact the > design and implementation of the tracker-peer signaling and peer-peer > streaming signaling protocols. >=20 >=20 >=20 > The IETF Secretariat. >=20 >=20 --Apple-Mail-77--147932781 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="iso-8859-1" We = have made a new version of this draft, originally directed towards ppsp. = The main change in this draft is that it has been generalized so that it = is applicable to any protocol that have a need to name information/data = objects in addition to nodes and interfaces.
    At the upcoming IETF we = hope to present it in the DECADE WG. Potentially we think this could = also be of interest for CDNI.

    B=F6rje = Ohlman

    Begin forwarded message:

    From: IETF I-D Submission = Tool <idsubmission@ietf.org>
    Date: 14 mars 2011 21.54.42 CET
    To: B=F6rje Ohlman = <borje.ohlman@ericsson.com>= ;
    Subject: New Version Notification for = draft-dannewitz-ppsp-secure-naming-02 =


    A new version of I-D, = draft-dannewitz-ppsp-secure-naming-02.txt has been successfully = submitted by Borje Ohlman and posted to the IETF = repository.

    Filename: = draft-dannewitz-ppsp-secure-naming
    Revision: = 02
    Title: = = Secure naming structure and p2p application = interaction
    Creation_date: 2011-03-14
    WG ID: = Independent Submission
    Number_of_pages: 15

    Abstract:
    Today, = each application typically uses its own way to identify data.
    The = lack of a common naming scheme prevents applications from
    benefiting = from available copies of the same data distributed via
    different P2P = and CDN systems.  The main proposal presented in this
    draft is = idea that there should be a secure and application
    independent way of = naming information objects that are transported
    over the Internet. =  The draft defines a set of requirements for such
    a naming = structure.  It also presents a proposal for such a = naming
    structure that could relevant for a number of work groups = (existing
    and potential), e.g.  PPSP, DECADE and CDNI.  In = addition, today's
    P2P naming schemes lack important security aspects = that would allow
    the user to check the data integrity and build trust = in data and data
    publishers.  This is especially important in = P2P applications as data
    is received from untrusted peers. =  Providing a generic naming scheme
    for P2P systems so that = multiple P2P systems can use the same data
    regardless of data = location and P2P system increases the efficiency
    and data = availability of the overall data dissemination process. =  The
    secure naming scheme is providing self-certification such = that the
    receiver can verify the data integrity, i.e., that the = correct data
    has been received, without requiring a trusted third = party.  It also
    enables owner authentication to build up trust = in (potentially
    anonymous) data publishers.  The secure naming = structure should be
    beneficial as potential design principle in = defining the two
    protocols identified as objectives in the PPSP = charter.  This
    document enumerates a number of design = considerations to impact the
    design and implementation of the = tracker-peer signaling and peer-peer
    streaming signaling = protocols.



    The IETF = Secretariat.



    = --Apple-Mail-77--147932781-- From optimism1226@gmail.com Wed Mar 16 07:34:52 2011 Return-Path: X-Original-To: decade@core3.amsl.com Delivered-To: decade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9356F3A6920 for ; Wed, 16 Mar 2011 07:34:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.455 X-Spam-Level: *** X-Spam-Status: No, score=3.455 tagged_above=-999 required=5 tests=[AWL=1.250, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_62=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5oZX36hXN5Ji for ; Wed, 16 Mar 2011 07:34:51 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by core3.amsl.com (Postfix) with ESMTP id A76D23A6911 for ; Wed, 16 Mar 2011 07:34:50 -0700 (PDT) Received: by vxg33 with SMTP id 33so1984110vxg.31 for ; Wed, 16 Mar 2011 07:36:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:date:from:to:cc:references:subject:message-id :x-mailer:mime-version:content-type; bh=aBx431EW6VizFzJvidm5WlgismvawBmgB2eCzIOrJL8=; b=ugbUPdshdOuA50eRiu5Gz0IzKi1CbbWucbGeRp7orrj4q/ghFeIOR4lFGr52Hg3YdW U1zUktaSQTTgUXW7/QkoOIdsJ1l9XGtfQPZYmoLlOBpQYmN0fSnavX5cPPTMhR7XYRH8 I/vkfvXOard76OeO4C76soSwaHy9h+syxiH7E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:references:subject:message-id:x-mailer:mime-version :content-type; b=SPxPkZ3UZEh9eLo97lrPJj+i0FMnMkyWBHkIlUyvFG9izi5sI+qt62X+6ehqFjNmFT jfoY8aN/prKLZ7y+2b0cwSSd/f+X1qQDwsQJKxtH7nfORYsahNHEgmM4KaHUfOpX2TOC 6wjNkiDtEQzQ/dniY4BG/60SJn4+8i1GFD/LI= Received: by 10.52.0.101 with SMTP id 5mr33304vdd.293.1300286037039; Wed, 16 Mar 2011 07:33:57 -0700 (PDT) Received: from leguan-THINK ([59.64.154.36]) by mx.google.com with ESMTPS id q13sm365441vdu.29.2011.03.16.07.33.49 (version=SSLv3 cipher=OTHER); Wed, 16 Mar 2011 07:33:56 -0700 (PDT) Date: Wed, 16 Mar 2011 22:33:49 +0800 From: "Guan Le" To: "li.lichun1" , "zhangyunfei" References: Message-ID: <201103162233445802250@gmail.com> X-mailer: Foxmail 6, 15, 201, 23 [cn] Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====003_Dragon514602362137_=====" Cc: "DECADE@ietf.org" Subject: Re: [decade] How about modifying tracker to support DECADE? X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.9 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, 16 Mar 2011 14:34:52 -0000 This is a multi-part message in MIME format. --=====003_Dragon514602362137_===== Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgWXVuZmVpIGFuZCBMaWNodW4NCg0KVGhhbmsgeW91IGZvciB5b3VyIGNvbW1lbnRzLiBJIHdp bGwgdXBkYXRlIGRyYWZ0IGJhc2VkIG9uIHlvdXIgc3VnZ2VzdGlvbi4gSGVyZSBhcmUgbXkgY29u c2lkZXJhdGlvbnMgaW4gbGluZToNCg0KMSkgVGhlIHRhcmdldCBvZiB0aGlzIGRyYWZ0OiBJcyBp dCBiZXR0ZXIgdG8gZGlzY3VzcyB0aGUgaW50ZXItb3BlYXJhYmlsaXR5IGJldHdlZW4gUFBTUCBh bmQgREVDQURFO29yIGRpc2N1c3MgdGhlIHVzYWdlIG9mIERFQ0FERSBpbiBQUFNQPyBJIG1lYW4g dGhlIGZvY3VzIG1heSBiZSBhIGxpdHRsZSBiaXQgZGlmZmVyZW50OiBJbiB0aGUgZm9ybWVyIGNh c2UsIHRoZSBmb2N1cyBpcyBob3cgdGhlIHByb3RvY29scyBpbnRlci1hY3QgaW4gdGhlIG1lc2Fn ZSBvcHRpb25zIGV4Y2hhbmdlOyBpbiB0aGUgbGF0dGVyIGNhc2UsIHRoZSBmb2N1cyBpcyBob3cg dGhlIFBQU1AgYXBwbGljYXRpb25zIHVzZSBERUNBREUgdG8gZW5oYW5jZSB0aGUgcGVyZm9ybWFu Y2UuIEkgcHJlZmVyIHRvIHRha2luZyBpdCBhcyB0aGUgdXNhZ2UuDQpJIGFncmVlIHlvdXIgb3Bp bmlvbi4gV2hhdCdzIG1vcmUsIGNvbnRlbnQgYWJvdXQgUFBTUCBhbmQgREVDQURFIGludGVyb3Bl cmF0aW9uIGFpbXMgdG8gcHJvdmlkZSBzY2VuYXJpb3MgZm9yIHVzYWdlLiBBbHNvLCB3ZSBjYW4g bGlzdCBzb21lIGV4dGVuc2lvbiBzdWdnZXN0aW9ucyB0byBib3RoIHByb3RvY29sLiBQZWhhcnBz IEkgY2FuIGFkZCBhIG5ldyBjaGFwdGVyIHRvIHRob3NlIHN1Z2dlc3Rpb24uDQoNCjIpIFNob3Vs ZCB3ZSBtYWtlIERFQ0FERSBzZXJ2ZXIgc2VsZWN0aW9uIHdpdGggcHJpb3JpdHkgYWxsIHRoZSB0 aW1lPyBJbiB0aGUgbW9iaWxlIHNlbmFyaW8sIHN1Y2ggc2VsZWN0aW9uIGlzIHJlYXNvbmFibGU7 IGluIHdpcmVkIHNlbmFyaW8sIGl0IHNlZW1zIGJldHRlciB0byBzZWxlY3QgZ29vZCBlbm91Z2gg cGVlcnMgd2l0aGluIG15IExBTiB0aGFuIHNlbGVjdCBERUNBREUgc2VydmVycyB3aGljaCBpcyBt b3JlIGZhciBmcm9tIG1lLiBUaGlzIHdpbGwgcmVkdWNlIHRoZSB1bm5lY2Vzc2FyeSB0cmFmZmlj IGFuZCBwcm92aWRlIGJldHRlciBwZXJmb3JtYW5jZS4NCkkgYWdyZWUuIFdlIHNob3VsZCBkZXNp Z24gYmFzZWQgb24gZGlmZmVyZW50IHNjZW5hcmlvcy4gT25lIG1vcmUgcXVlc3Rpb24sIHNob3Vs ZCBwZWVyIHVwbG9hZCBjb250ZW50IHRvIERFQ0FERSBzZXJ2ZXIgYXV0b21hdGljYWxseSB3aGVu IGdldCBkYXRhIGZyb20gb3RoZXIgcGVlcnM/IFBlcmhhcHMgaW4gcHVzaC1iYXNlZCBtb2RlbCwg aXQgbWF5IGJlIHJlYXNvbmFibGU7IGluIHB1bGwtYmFzZWQgbW9kZWwsIHBlZXIgY2FuIHdhaXQg Zm9yIG90aGVyIHBlZXJzJyByZXF1ZXN0IGFuZCB0aGVuIHRha2UgYWN0aW9uIHRvIHJlcXVlc3Rz Lg0KDQoNCjIwMTEtMDMtMTYgDQoNCg0KDQpHdWFuIExlIA0KDQoNCg0Kt6K8/sjLo7ogbGkubGlj aHVuMSANCreiy83Ksbzko7ogMjAxMS0wMy0xNCAgMTM6NDE6MjEgDQrK1bz+yMujuiB6aGFuZ3l1 bmZlaSANCrOty82juiBERUNBREVAaWV0Zi5vcmcgDQrW98zio7ogUmU6IFtkZWNhZGVdIEhvdyBh Ym91dCBtb2RpZnlpbmcgdHJhY2tlciB0byBzdXBwb3J0IERFQ0FERT8gDQogDQoNCkhpIHl1bmZl aSwgDQpUaGFua3MgZm9yIHlvdXIgY29tbWVudHMuIA0KMSkgVGhlIGZvY3VzIGlzIHRoZSB1c2Fn ZSBvZiBERUNBREUgaW4gUFBTUC4gVGhlIHVzYWdlIGFsc28gbmVlZHMgc29tZSBleHRlbnNpb25z IHRvIHRoZSBwcm90b2NvbHMuIA0KMikgWW91IGFyZSByaWdodC4gVGhlIHByaW9yaXR5IG9mIERF Q0FERSBkZXBlbmRzIG9uIHNjZW5hcmlvIGFuZCBwZWVyL0RFQ0FERSBzZWxlY3Rpb24gYWxnb3Jp dGhtLiBTb21ldGltZXMsIGRvd25sb2FkaW5nIGZyb20gcGVlciBpcyBiZXR0ZXIuIEFsc28sIHNv bWUgc2NlbmFyaW9zIG1heSB1c2UgREVDQURFIGFzIGJhY2t1cCBvbmx5IGFuZCBnaXZlIGxvdyBw cmlvcml0eSB0byBERUNBREUuIA0KDQpCUiANCkxpY2h1biANCg0KDQoiemhhbmd5dW5mZWkiIDx6 aGFuZ3l1bmZlaUBjaGluYW1vYmlsZS5jb20+IA0KMjAxMS0wMy0xNCAxMDo0OCDK1bz+yMsibGku bGljaHVuMUB6dGUuY29tLmNuIiA8bGkubGljaHVuMUB6dGUuY29tLmNuPiwgIkRFQ0FERUBpZXRm Lm9yZyIgPERFQ0FERUBpZXRmLm9yZz4gDQqzrcvNDQrW98ziUmU6IFtkZWNhZGVdIEhvdyBhYm91 dCBtb2RpZnlpbmcgdHJhY2tlciB0byBzdXBwb3J0IERFQ0FERT8NCg0KDQoNCg0KDQoNCg0KSGkg TGljaHVuLCANCiAgICBUaGlzIGlzIGFuIGludGVyc3RpbmcgdG9waWMgSSB0aG91Z2h0IGFuZCBk aXNjdXNzZWQgZHVyaW5nIHRoZSBzZXQgdXAgb2YgUFBTUCBhbmQgREVDQURFLiBUaGFua3MgZm9y IG1ha2luZyBpdCBtb3JlIGNsZWFyOikuU29tZSBzdWdnZXN0aW9ucyBhcmUgYXMgZm9sbG93czog DQoxKSBUaGUgdGFyZ2V0IG9mIHRoaXMgZHJhZnQ6IElzIGl0IGJldHRlciB0byBkaXNjdXNzIHRo ZSBpbnRlci1vcGVhcmFiaWxpdHkgYmV0d2VlbiBQUFNQIGFuZCBERUNBREU7b3IgZGlzY3VzcyB0 aGUgdXNhZ2Ugb2YgREVDQURFIGluIFBQU1A/IEkgbWVhbiB0aGUgZm9jdXMgbWF5IGJlIGEgbGl0 dGxlIGJpdCBkaWZmZXJlbnQ6IEluIHRoZSBmb3JtZXIgY2FzZSwgdGhlIGZvY3VzIGlzIGhvdyB0 aGUgcHJvdG9jb2xzIGludGVyLWFjdCBpbiB0aGUgbWVzYWdlIG9wdGlvbnMgZXhjaGFuZ2U7IGlu IHRoZSBsYXR0ZXIgY2FzZSwgdGhlIGZvY3VzIGlzIGhvdyB0aGUgUFBTUCBhcHBsaWNhdGlvbnMg dXNlIERFQ0FERSB0byBlbmhhbmNlIHRoZSBwZXJmb3JtYW5jZS4gSSBwcmVmZXIgdG8gdGFraW5n IGl0IGFzIHRoZSB1c2FnZS4gDQoyKSBTaG91bGQgd2UgbWFrZSBERUNBREUgc2VydmVyIHNlbGVj dGlvbiB3aXRoIHByaW9yaXR5IGFsbCB0aGUgdGltZT8gSW4gdGhlIG1vYmlsZSBzZW5hcmlvLCBz dWNoIHNlbGVjdGlvbiBpcyByZWFzb25hYmxlOyBpbiB3aXJlZCBzZW5hcmlvLCBpdCBzZWVtcyBi ZXR0ZXIgdG8gc2VsZWN0IGdvb2QgZW5vdWdoIHBlZXJzIHdpdGhpbiBteSBMQU4gdGhhbiBzZWxl Y3QgREVDQURFIHNlcnZlcnMgd2hpY2ggaXMgbW9yZSBmYXIgZnJvbSBtZS4gVGhpcyB3aWxsIHJl ZHVjZSB0aGUgdW5uZWNlc3NhcnkgdHJhZmZpYyBhbmQgcHJvdmlkZSBiZXR0ZXIgcGVyZm9ybWFu Y2UuIA0KICANCkJSIA0KWXVuZmVpIA0KICANCg0KDQoNCnpoYW5neXVuZmVpIA0KMjAxMS0wMy0x NCANCg0KDQoNCreivP7Iy6O6IGxpLmxpY2h1bjFAenRlLmNvbS5jbiANCreiy83Ksbzko7ogMjAx MS0wMy0xMSAxNzo0ODozNiANCsrVvP7Iy6O6IERFQ0FERUBpZXRmLm9yZyANCrOty82juiANCtb3 zOKjuiBbZGVjYWRlXSBIb3cgYWJvdXQgbW9kaWZ5aW5nIHRyYWNrZXIgdG8gc3VwcG9ydCBERUNB REU/IA0KICANCg0KSGkgYWxsLCANCkl0IHNlZW1zIHRoYXQgdGhpcyBXRyBoYXMgbm90IGNvbnNp ZGVyZWQgbW9kaWZ5aW5nIHRyYWNrZXIgdG8gc3VwcG9ydCBERUNBREUuIA0KSSBiZWxpZXZlIHRo YXQgbW9kaWZ5aW5nIGJvdGggdHJhY2tlciBhbmQgcGVlciBjYW4gbWFrZSBiZXR0ZXIgdXNlIG9m IERFQ0FERSBjb21wYXJlZCB3aXRoIG1vZGlmeWluZyBwZWVyIG9ubHkuIA0KV2UgaGF2ZSBwcm9w b3NlZCB0d28gc29sdXRpb25zIGFuZCBzdWJtaXR0ZWQgYSBkcmFmdCBhYm91dCBleHRlbmRpbmcg UFBTUCB0byBzdXBwb3J0IERFQ0FERSAoaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt bGUtcHBzcC1kZWNhZGUtaW50ZXJvcGVyYXRpb24tMDAudHh0IA0KKS4gVGhlIHNvbHV0aW9ucyBh bHNvIHB1dCBzb21lIHJlcXVpcmVtZW50cyBvbiBERUNBREUuIA0KSSBzdW1tYXJpemUgb3VyIHNv bHV0aW9ucyBhcyBiZWxvdy4gQ29tbWVudHMgYXJlIHdlbGNvbWUuIA0KDQpTb2x1dGlvbiAxIA0K RWFjaCBwZWVyIHJlcG9ydHMgdG8gdHJhY2tlciB0aGF0IHdoZXRoZXIgaXQgaGFzIERFQ0FERSBz ZXJ2ZXIgb3Igbm90LiBQZWVyIEEgcXVlcmllcyBwZWVyIGxpc3QgZnJvbSB0cmFja2VyLiANClRo ZSBwZWVyIGxpc3QgaW5kaWNhdGVzIHRoYXQgZWFjaCBwZWVyIGhhcyBERUNBREUgc2VydmVyIG9y IG5vdC4gVGhlIFBlZXIgQSBjYW4gcmVxdWVzdCBjb250ZW50IGZyb20gcGVlcnMgaGF2aW5nIERF Q0FERSBzZXJ2ZXJzIHdpdGggaGlnaCBwcmlvcml0eS4gDQoNClNvbHV0aW9uIDIgDQpUcmFja2Vy IG1haW50YWlucyBERUNBREUgaW5mb3JtYXRpb24gKERFQ0FERSBsaXN0IGFuZCB0aGUgY29udGVu dCBhdmFpbGFiaWxpdHkgaW5mb3JtYXRpb24gb2YgZWFjaCBERUNBREUgc2VydmVyKS4gUGVlciBB IHF1ZXJpZXMgbm9kZSBsaXN0IGZyb20gdHJhY2tlciBmb3IgZG93bmxvYWRpbmcgY29udGVudC4g VHJhY2tlciByZXR1cm5zIHRoZSBsaXN0IG9mIHBlZXJzIGFuZCBERUNBREUgc2VydmVycyBoYXZp bmcgcmVxdWVzdGVkIGNvbnRlbnQuIFRoZW4gUGVlciBBIGNhbiByZXF1ZXN0IGNvbnRlbnQgZnJv bSBvdGhlciBwZWVyJ3Mgb3IgdHJhY2tlcidzIERFQ0FERSBzZXJ2ZXIuIA0KSWYgdGhlIERFQ0FE RSBzZXJ2aWNlIGlzIHJlbnQgYnkgcGVlcnMsIHBlZXJzIHVwbG9hZCBjb250ZW50cyB0byBERUNB REUgc2VydmVycyBhbmQgcmVwb3J0IHRoZSBERUNBREUgaW5mb3JtYXRpb24gdG8gdHJhY2tlci4g DQpJZiB0aGUgREVDQURFIHNlcnZpY2UgaXMgcmVudCBieSB0cmFja2VyIChpLmUuIFAyUCBjb250 ZW50IHNoYXJpbmcgc2VydmljZSBwcm92aWRlciksIHRyYWNrZXIgaW5zdHJ1Y3QgcGVlcnMgdXBs b2FkaW5nIGNvbnRlbnRzIHRvIERFQ0FERSBzZXJ2ZXJzIG9yIERFQ0FERSBzZXJ2ZXJzIGRvd25s b2FkaW5nIGNvbnRlbnRzIGZyb20gcGVlcnMuIA0KDQpCUiANCkxpY2h1biANCi0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpaVEUgSW5mb3Jt YXRpb24gU2VjdXJpdHkgTm90aWNlOiBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMg bWFpbCBpcyBzb2xlbHkgcHJvcGVydHkgb2YgdGhlIHNlbmRlcidzIG9yZ2FuaXphdGlvbi4gVGhp cyBtYWlsIGNvbW11bmljYXRpb24gaXMgY29uZmlkZW50aWFsLiBSZWNpcGllbnRzIG5hbWVkIGFi b3ZlIGFyZSBvYmxpZ2F0ZWQgdG8gbWFpbnRhaW4gc2VjcmVjeSBhbmQgYXJlIG5vdCBwZXJtaXR0 ZWQgdG8gZGlzY2xvc2UgdGhlIGNvbnRlbnRzIG9mIHRoaXMgY29tbXVuaWNhdGlvbiB0byBvdGhl cnMuDQpUaGlzIGVtYWlsIGFuZCBhbnkgZmlsZXMgdHJhbnNtaXR0ZWQgd2l0aCBpdCBhcmUgY29u ZmlkZW50aWFsIGFuZCBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1 YWwgb3IgZW50aXR5IHRvIHdob20gdGhleSBhcmUgYWRkcmVzc2VkLiBJZiB5b3UgaGF2ZSByZWNl aXZlZCB0aGlzIGVtYWlsIGluIGVycm9yIHBsZWFzZSBub3RpZnkgdGhlIG9yaWdpbmF0b3Igb2Yg dGhlIG1lc3NhZ2UuIEFueSB2aWV3cyBleHByZXNzZWQgaW4gdGhpcyBtZXNzYWdlIGFyZSB0aG9z ZSBvZiB0aGUgaW5kaXZpZHVhbCBzZW5kZXIuDQpUaGlzIG1lc3NhZ2UgaGFzIGJlZW4gc2Nhbm5l ZCBmb3IgdmlydXNlcyBhbmQgU3BhbSBieSBaVEUgQW50aS1TcGFtIHN5c3RlbS4NCg0KDQoNCi0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpa VEUgSW5mb3JtYXRpb24gU2VjdXJpdHkgTm90aWNlOiBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVk IGluIHRoaXMgbWFpbCBpcyBzb2xlbHkgcHJvcGVydHkgb2YgdGhlIHNlbmRlcidzIG9yZ2FuaXph dGlvbi4gVGhpcyBtYWlsIGNvbW11bmljYXRpb24gaXMgY29uZmlkZW50aWFsLiBSZWNpcGllbnRz IG5hbWVkIGFib3ZlIGFyZSBvYmxpZ2F0ZWQgdG8gbWFpbnRhaW4gc2VjcmVjeSBhbmQgYXJlIG5v dCBwZXJtaXR0ZWQgdG8gZGlzY2xvc2UgdGhlIGNvbnRlbnRzIG9mIHRoaXMgY29tbXVuaWNhdGlv biB0byBvdGhlcnMuDQpUaGlzIGVtYWlsIGFuZCBhbnkgZmlsZXMgdHJhbnNtaXR0ZWQgd2l0aCBp dCBhcmUgY29uZmlkZW50aWFsIGFuZCBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgdGhl IGluZGl2aWR1YWwgb3IgZW50aXR5IHRvIHdob20gdGhleSBhcmUgYWRkcmVzc2VkLiBJZiB5b3Ug aGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yIHBsZWFzZSBub3RpZnkgdGhlIG9yaWdp bmF0b3Igb2YgdGhlIG1lc3NhZ2UuIEFueSB2aWV3cyBleHByZXNzZWQgaW4gdGhpcyBtZXNzYWdl IGFyZSB0aG9zZSBvZiB0aGUgaW5kaXZpZHVhbCBzZW5kZXIuDQpUaGlzIG1lc3NhZ2UgaGFzIGJl ZW4gc2Nhbm5lZCBmb3IgdmlydXNlcyBhbmQgU3BhbSBieSBaVEUgQW50aS1TcGFtIHN5c3RlbS4N Cg== --=====003_Dragon514602362137_===== Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PUdC MjMxMiIgaHR0cC1lcXVpdj1Db250ZW50LVR5cGU+DQo8TUVUQSBuYW1lPUdFTkVSQVRPUiBjb250 ZW50PSJNU0hUTUwgOC4wMC43NjAwLjE2NzIyIj4NCjxTVFlMRT5AZm9udC1mYWNlIHsNCglmb250 LWZhbWlseTogy87M5TsNCn0NCkBmb250LWZhY2Ugew0KCWZvbnQtZmFtaWx5OiBWZXJkYW5hOw0K fQ0KQGZvbnQtZmFjZSB7DQoJZm9udC1mYW1pbHk6IEDLzszlOw0KfQ0KQHBhZ2UgU2VjdGlvbjEg e3NpemU6IDU5NS4zcHQgODQxLjlwdDsgbWFyZ2luOiA3Mi4wcHQgOTAuMHB0IDcyLjBwdCA5MC4w cHQ7IGxheW91dC1ncmlkOiAxNS42cHQ7IH0NClAuTXNvTm9ybWFsIHsNCglURVhULUpVU1RJRlk6 IGludGVyLWlkZW9ncmFwaDsgVEVYVC1BTElHTjoganVzdGlmeTsgTUFSR0lOOiAwY20gMGNtIDBw dDsgRk9OVC1GQU1JTFk6ICJUaW1lcyBOZXcgUm9tYW4iOyBGT05ULVNJWkU6IDEwLjVwdA0KfQ0K TEkuTXNvTm9ybWFsIHsNCglURVhULUpVU1RJRlk6IGludGVyLWlkZW9ncmFwaDsgVEVYVC1BTElH TjoganVzdGlmeTsgTUFSR0lOOiAwY20gMGNtIDBwdDsgRk9OVC1GQU1JTFk6ICJUaW1lcyBOZXcg Um9tYW4iOyBGT05ULVNJWkU6IDEwLjVwdA0KfQ0KRElWLk1zb05vcm1hbCB7DQoJVEVYVC1KVVNU SUZZOiBpbnRlci1pZGVvZ3JhcGg7IFRFWFQtQUxJR046IGp1c3RpZnk7IE1BUkdJTjogMGNtIDBj bSAwcHQ7IEZPTlQtRkFNSUxZOiAiVGltZXMgTmV3IFJvbWFuIjsgRk9OVC1TSVpFOiAxMC41cHQN Cn0NCkE6bGluayB7DQoJQ09MT1I6IGJsdWU7IFRFWFQtREVDT1JBVElPTjogdW5kZXJsaW5lDQp9 DQpTUEFOLk1zb0h5cGVybGluayB7DQoJQ09MT1I6IGJsdWU7IFRFWFQtREVDT1JBVElPTjogdW5k ZXJsaW5lDQp9DQpBOnZpc2l0ZWQgew0KCUNPTE9SOiBwdXJwbGU7IFRFWFQtREVDT1JBVElPTjog dW5kZXJsaW5lDQp9DQpTUEFOLk1zb0h5cGVybGlua0ZvbGxvd2VkIHsNCglDT0xPUjogcHVycGxl OyBURVhULURFQ09SQVRJT046IHVuZGVybGluZQ0KfQ0KU1BBTi5FbWFpbFN0eWxlMTcgew0KCUZP TlQtU1RZTEU6IG5vcm1hbDsgRk9OVC1GQU1JTFk6IFZlcmRhbmE7IENPTE9SOiB3aW5kb3d0ZXh0 OyBGT05ULVdFSUdIVDogbm9ybWFsOyBURVhULURFQ09SQVRJT046IG5vbmU7IG1zby1zdHlsZS10 eXBlOiBwZXJzb25hbC1jb21wb3NlDQp9DQpESVYuU2VjdGlvbjEgew0KCXBhZ2U6IFNlY3Rpb24x DQp9DQpVTktOT1dOIHsNCglGT05ULVNJWkU6IDEwcHQNCn0NCkJMT0NLUVVPVEUgew0KCU1BUkdJ Ti1UT1A6IDBweDsgTUFSR0lOLUJPVFRPTTogMHB4OyBNQVJHSU4tTEVGVDogMmVtDQp9DQpPTCB7 DQoJTUFSR0lOLVRPUDogMHB4OyBNQVJHSU4tQk9UVE9NOiAwcHgNCn0NClVMIHsNCglNQVJHSU4t VE9QOiAwcHg7IE1BUkdJTi1CT1RUT006IDBweA0KfQ0KPC9TVFlMRT4NCjwvSEVBRD4NCjxCT0RZ IHN0eWxlPSJNQVJHSU46IDEwcHg7IEZPTlQtRkFNSUxZOiB2ZXJkYW5hOyBGT05ULVNJWkU6IDEw cHQiPg0KPERJVj48Rk9OVCBjb2xvcj0jMDAwMDgwIHNpemU9MiBmYWNlPVZlcmRhbmE+DQo8RElW PjxGT05UIGNvbG9yPSMwMDAwODAgc2l6ZT0yIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+DQo8RElW PjxGT05UIGNvbG9yPSMwMDAwMDAgZmFjZT1WZXJkYW5hPkhpIFl1bmZlaSBhbmQgTGljaHVuPC9G T05UPjwvRElWPg0KPERJVj48Rk9OVCBjb2xvcj0jMDAwMDAwIGZhY2U9VmVyZGFuYT48L0ZPTlQ+ Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGNvbG9yPSMwMDAwMDAgZmFjZT1WZXJkYW5hPlRoYW5r IHlvdSBmb3IgeW91ciBjb21tZW50cy4gSSB3aWxsIHVwZGF0ZSANCmRyYWZ0IGJhc2VkIG9uIHlv dXIgc3VnZ2VzdGlvbi4gSGVyZSBhcmUgbXkgY29uc2lkZXJhdGlvbnMgaW4gbGluZTo8L0ZPTlQ+ PC9ESVY+DQo8RElWPjxGT05UIGNvbG9yPSMwMDAwODAgZmFjZT1WZXJkYW5hPjwvRk9OVD4mbmJz cDs8L0RJVj4NCjxESVY+PEZPTlQgY29sb3I9IzAwMDA4MD48L0ZPTlQ+PEZPTlQgZmFjZT0iVGlt ZXMgTmV3IFJvbWFuIj4NCjxESVY+PEZPTlQgY29sb3I9IzAwMDBmZiBmYWNlPVZlcmRhbmE+MSkg VGhlIHRhcmdldCBvZiB0aGlzIGRyYWZ0OiBJcyBpdCBiZXR0ZXIgDQp0byBkaXNjdXNzIHRoZSBp bnRlci1vcGVhcmFiaWxpdHkgYmV0d2VlbiBQUFNQIGFuZCBERUNBREU7b3IgZGlzY3VzcyB0aGUg dXNhZ2UgDQpvZiBERUNBREUgaW4gUFBTUD8gSSBtZWFuIHRoZSBmb2N1cyBtYXkgYmUgYSBsaXR0 bGUgYml0IGRpZmZlcmVudDogSW4gdGhlIGZvcm1lciANCmNhc2UsIHRoZSBmb2N1cyBpcyBob3cg dGhlIHByb3RvY29scyBpbnRlci1hY3QgaW4gdGhlIG1lc2FnZSBvcHRpb25zIGV4Y2hhbmdlOyAN CmluIHRoZSBsYXR0ZXIgY2FzZSwgdGhlIGZvY3VzIGlzIGhvdyB0aGUgUFBTUCBhcHBsaWNhdGlv bnMgdXNlIERFQ0FERSB0byBlbmhhbmNlIA0KdGhlIHBlcmZvcm1hbmNlLiBJIHByZWZlciB0byB0 YWtpbmcgaXQgYXMgdGhlIHVzYWdlLjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgY29sb3I9IzAw MDAwMCBmYWNlPVZlcmRhbmE+SSBhZ3JlZSB5b3VyIG9waW5pb24uIFdoYXQncyBtb3JlLCBjb250 ZW50IA0KYWJvdXQgUFBTUCBhbmQgREVDQURFIGludGVyb3BlcmF0aW9uIGFpbXMgdG8gcHJvdmlk ZSBzY2VuYXJpb3MgZm9yIHVzYWdlLiBBbHNvLCANCndlIGNhbiBsaXN0IHNvbWUgZXh0ZW5zaW9u IHN1Z2dlc3Rpb25zIHRvIGJvdGggcHJvdG9jb2wuIFBlaGFycHMgSSBjYW4gYWRkIGEgbmV3IA0K Y2hhcHRlciB0byB0aG9zZSBzdWdnZXN0aW9uLjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgY29s b3I9IzAwMDBmZiBmYWNlPVZlcmRhbmE+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBj b2xvcj0jMDAwMGZmIGZhY2U9VmVyZGFuYT4yKSBTaG91bGQgd2UgbWFrZSBERUNBREUgc2VydmVy IHNlbGVjdGlvbiANCndpdGggcHJpb3JpdHkgYWxsIHRoZSB0aW1lPyBJbiB0aGUgbW9iaWxlIHNl bmFyaW8sIHN1Y2ggc2VsZWN0aW9uIGlzIHJlYXNvbmFibGU7IA0KaW4gd2lyZWQgc2VuYXJpbywg aXQgc2VlbXMgYmV0dGVyIHRvIHNlbGVjdCBnb29kIGVub3VnaCBwZWVycyB3aXRoaW4gbXkgTEFO IHRoYW4gDQpzZWxlY3QgREVDQURFIHNlcnZlcnMgd2hpY2ggaXMgbW9yZSBmYXIgZnJvbSBtZS4g VGhpcyB3aWxsIHJlZHVjZSB0aGUgDQp1bm5lY2Vzc2FyeSB0cmFmZmljIGFuZCBwcm92aWRlIGJl dHRlciBwZXJmb3JtYW5jZS48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGNvbG9yPSMwMDAwMDAg ZmFjZT1WZXJkYW5hPkkgYWdyZWUuIFdlIHNob3VsZCBkZXNpZ24gYmFzZWQgb24gDQpkaWZmZXJl bnQmbmJzcDtzY2VuYXJpb3MuIE9uZSBtb3JlIHF1ZXN0aW9uLCZuYnNwO3Nob3VsZCZuYnNwO3Bl ZXImbmJzcDt1cGxvYWQgDQpjb250ZW50Jm5ic3A7dG8gREVDQURFIHNlcnZlciBhdXRvbWF0aWNh bGx5IHdoZW4gZ2V0IGRhdGEgZnJvbSBvdGhlciBwZWVycz8gDQpQZXJoYXBzIGluIHB1c2gtYmFz ZWQgbW9kZWwsIGl0IG1heSBiZSByZWFzb25hYmxlOyBpbiBwdWxsLWJhc2VkIG1vZGVsLCBwZWVy IGNhbiANCndhaXQgZm9yIG90aGVyIHBlZXJzJyByZXF1ZXN0IGFuZCB0aGVuIHRha2UgYWN0aW9u IHRvIA0KcmVxdWVzdHMuPC9GT05UPjwvRElWPjwvRk9OVD48L0RJVj48L0ZPTlQ+PC9ESVY+PC9G T05UPjwvRElWPg0KPERJVj48Rk9OVCBjb2xvcj0jMDAwMDgwIHNpemU9MiBmYWNlPVZlcmRhbmE+ PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBjb2xvcj0jMDAwMDgwIHNpemU9MiBmYWNl PVZlcmRhbmE+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBjb2xvcj0jYzBjMGMwIHNp emU9MiBmYWNlPVZlcmRhbmE+MjAxMS0wMy0xNiA8L0ZPTlQ+PC9ESVY+PEZPTlQgDQpjb2xvcj0j MDAwMDgwIHNpemU9MiBmYWNlPVZlcmRhbmE+DQo8SFIgc3R5bGU9IldJRFRIOiAxMDBweCIgYWxp Z249bGVmdCBjb2xvcj0jYjVjNGRmIFNJWkU9MT4NCjwvRk9OVD4NCjxESVY+PEZPTlQgY29sb3I9 I2MwYzBjMCBzaXplPTIgZmFjZT1WZXJkYW5hPjxTUEFOPkd1YW4gTGU8L1NQQU4+IDwvRk9OVD48 L0RJVj4NCjxIUiBjb2xvcj0jYjVjNGRmIFNJWkU9MT4NCg0KPERJVj48Rk9OVCBzaXplPTIgZmFj ZT1WZXJkYW5hPjxTVFJPTkc+t6K8/sjLo7o8L1NUUk9ORz4gbGkubGljaHVuMSA8L0ZPTlQ+PC9E SVY+DQo8RElWPjxGT05UIHNpemU9MiBmYWNlPVZlcmRhbmE+PFNUUk9ORz63osvNyrG85KO6PC9T VFJPTkc+IDIwMTEtMDMtMTQmbmJzcDsgMTM6NDE6MjEgDQo8L0ZPTlQ+PC9ESVY+DQo8RElWPjxG T05UIHNpemU9MiBmYWNlPVZlcmRhbmE+PFNUUk9ORz7K1bz+yMujujwvU1RST05HPiB6aGFuZ3l1 bmZlaSA8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9MiBmYWNlPVZlcmRhbmE+PFNUUk9O Rz6zrcvNo7o8L1NUUk9ORz4gREVDQURFQGlldGYub3JnIA0KPC9GT05UPjwvRElWPg0KPERJVj48 Rk9OVCBzaXplPTIgZmFjZT1WZXJkYW5hPjxTVFJPTkc+1vfM4qO6PC9TVFJPTkc+IFJlOiBbZGVj YWRlXSBIb3cgYWJvdXQgDQptb2RpZnlpbmcgdHJhY2tlciB0byBzdXBwb3J0IERFQ0FERT8gPC9G T05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTIgZmFjZT1WZXJkYW5hPjwvRk9OVD4gPC9ESVY+ DQo8RElWPjxGT05UIHNpemU9MiBmYWNlPVZlcmRhbmE+PEJSPjxGT05UIHNpemU9MiBmYWNlPXNh bnMtc2VyaWY+SGkgDQp5dW5mZWksPC9GT05UPiA8QlI+PEZPTlQgc2l6ZT0yIGZhY2U9c2Fucy1z ZXJpZj5UaGFua3MgZm9yIHlvdXIgY29tbWVudHMuPC9GT05UPiANCjxCUj48Rk9OVCBzaXplPTIg ZmFjZT1zYW5zLXNlcmlmPjEpIFRoZSBmb2N1cyBpcyB0aGUgdXNhZ2Ugb2YgREVDQURFIGluIFBQ U1AuIA0KVGhlIHVzYWdlIGFsc28gbmVlZHMgc29tZSBleHRlbnNpb25zIHRvIHRoZSBwcm90b2Nv bHMuPC9GT05UPiA8QlI+PEZPTlQgc2l6ZT0yIA0KZmFjZT1zYW5zLXNlcmlmPjIpIFlvdSBhcmUg cmlnaHQuIFRoZSBwcmlvcml0eSBvZiBERUNBREUgZGVwZW5kcyBvbiBzY2VuYXJpbyBhbmQgDQpw ZWVyL0RFQ0FERSBzZWxlY3Rpb24gYWxnb3JpdGhtLiBTb21ldGltZXMsIGRvd25sb2FkaW5nIGZy b20gcGVlciBpcyBiZXR0ZXIuIA0KQWxzbywgc29tZSBzY2VuYXJpb3MgbWF5IHVzZSBERUNBREUg YXMgYmFja3VwIG9ubHkgYW5kIGdpdmUgbG93IHByaW9yaXR5IHRvIA0KREVDQURFLjwvRk9OVD4g PEJSPjxCUj48Rk9OVCBzaXplPTIgZmFjZT1zYW5zLXNlcmlmPkJSPC9GT05UPiA8QlI+PEZPTlQg c2l6ZT0yIA0KZmFjZT1zYW5zLXNlcmlmPkxpY2h1bjwvRk9OVD4gPEJSPjxCUj48QlI+DQo8VEFC TEUgd2lkdGg9IjEwMCUiPg0KICA8VEJPRFk+DQogIDxUUiB2QWxpZ249dG9wPg0KICAgIDxURCB3 aWR0aD0iMzUlIj48Rk9OVCBzaXplPTEgZmFjZT1zYW5zLXNlcmlmPjxCPiJ6aGFuZ3l1bmZlaSIg DQogICAgICAmbHQ7emhhbmd5dW5mZWlAY2hpbmFtb2JpbGUuY29tJmd0OzwvQj4gPC9GT05UPg0K ICAgICAgPFA+PEZPTlQgc2l6ZT0xIGZhY2U9c2Fucy1zZXJpZj4yMDExLTAzLTE0IDEwOjQ4PC9G T05UPiA8L1A+DQogICAgPFREIHdpZHRoPSI2NCUiPg0KICAgICAgPFRBQkxFIHdpZHRoPSIxMDAl Ij4NCiAgICAgICAgPFRCT0RZPg0KICAgICAgICA8VFIgdkFsaWduPXRvcD4NCiAgICAgICAgICA8 VEQ+DQogICAgICAgICAgICA8RElWIGFsaWduPXJpZ2h0PjxGT05UIHNpemU9MSBmYWNlPXNhbnMt c2VyaWY+ytW8/sjLPC9GT05UPjwvRElWPg0KICAgICAgICAgIDxURD48Rk9OVCBzaXplPTEgZmFj ZT1zYW5zLXNlcmlmPiJsaS5saWNodW4xQHp0ZS5jb20uY24iIA0KICAgICAgICAgICAgJmx0O2xp LmxpY2h1bjFAenRlLmNvbS5jbiZndDssICJERUNBREVAaWV0Zi5vcmciIA0KICAgICAgICAgICAg Jmx0O0RFQ0FERUBpZXRmLm9yZyZndDs8L0ZPTlQ+IA0KICAgICAgICA8VFIgdkFsaWduPXRvcD4N CiAgICAgICAgICA8VEQ+DQogICAgICAgICAgICA8RElWIGFsaWduPXJpZ2h0PjxGT05UIHNpemU9 MSBmYWNlPXNhbnMtc2VyaWY+s63LzTwvRk9OVD48L0RJVj4NCiAgICAgICAgICA8VEQ+DQogICAg ICAgIDxUUiB2QWxpZ249dG9wPg0KICAgICAgICAgIDxURD4NCiAgICAgICAgICAgIDxESVYgYWxp Z249cmlnaHQ+PEZPTlQgc2l6ZT0xIGZhY2U9c2Fucy1zZXJpZj7W98ziPC9GT05UPjwvRElWPg0K ICAgICAgICAgIDxURD48Rk9OVCBzaXplPTEgZmFjZT1zYW5zLXNlcmlmPlJlOiBbZGVjYWRlXSBI b3cgYWJvdXQgbW9kaWZ5aW5nIA0KICAgICAgICAgICAgdHJhY2tlciB0byBzdXBwb3J0IERFQ0FE RT88L0ZPTlQ+PC9UUj48L1RCT0RZPjwvVEFCTEU+PEJSPg0KICAgICAgPFRBQkxFPg0KICAgICAg ICA8VEJPRFk+DQogICAgICAgIDxUUiB2QWxpZ249dG9wPg0KICAgICAgICAgIDxURD4NCiAgICAg ICAgICA8VEQ+PC9UUj48L1RCT0RZPjwvVEFCTEU+PEJSPjwvVFI+PC9UQk9EWT48L1RBQkxFPjxC Uj48QlI+PEJSPjxGT05UIGNvbG9yPWJsdWUgDQpzaXplPTIgZmFjZT1WZXJkYW5hPkhpIExpY2h1 biw8L0ZPTlQ+IDxCUj48Rk9OVCBjb2xvcj1ibHVlIHNpemU9MiANCmZhY2U9VmVyZGFuYT4mbmJz cDsgJm5ic3A7IFRoaXMgaXMgYW4gaW50ZXJzdGluZyB0b3BpYyBJIHRob3VnaHQgYW5kIGRpc2N1 c3NlZCANCmR1cmluZyB0aGUgc2V0IHVwIG9mIFBQU1AgYW5kIERFQ0FERS4gVGhhbmtzIGZvciBt YWtpbmcgaXQgbW9yZSBjbGVhcjopLlNvbWUgDQpzdWdnZXN0aW9ucyBhcmUgYXMgZm9sbG93czo8 L0ZPTlQ+IDxCUj48Rk9OVCBjb2xvcj1ibHVlIHNpemU9MiBmYWNlPVZlcmRhbmE+MSkgDQpUaGUg dGFyZ2V0IG9mIHRoaXMgZHJhZnQ6IElzIGl0IGJldHRlciB0byBkaXNjdXNzIHRoZSBpbnRlci1v cGVhcmFiaWxpdHkgYmV0d2VlbiANClBQU1AgYW5kIERFQ0FERTtvciBkaXNjdXNzIHRoZSB1c2Fn ZSBvZiBERUNBREUgaW4gUFBTUD8gSSBtZWFuIHRoZSBmb2N1cyBtYXkgYmUgDQphIGxpdHRsZSBi aXQgZGlmZmVyZW50OiBJbiB0aGUgZm9ybWVyIGNhc2UsIHRoZSBmb2N1cyBpcyBob3cgdGhlIHBy b3RvY29scyANCmludGVyLWFjdCBpbiB0aGUgbWVzYWdlIG9wdGlvbnMgZXhjaGFuZ2U7IGluIHRo ZSBsYXR0ZXIgY2FzZSwgdGhlIGZvY3VzIGlzIGhvdyANCnRoZSBQUFNQIGFwcGxpY2F0aW9ucyB1 c2UgREVDQURFIHRvIGVuaGFuY2UgdGhlIHBlcmZvcm1hbmNlLiBJIHByZWZlciB0byB0YWtpbmcg DQppdCBhcyB0aGUgdXNhZ2UuPC9GT05UPiA8QlI+PEZPTlQgY29sb3I9Ymx1ZSBzaXplPTIgZmFj ZT1WZXJkYW5hPjIpIFNob3VsZCB3ZSANCm1ha2UgREVDQURFIHNlcnZlciBzZWxlY3Rpb24gd2l0 aCBwcmlvcml0eSBhbGwgdGhlIHRpbWU/IEluIHRoZSBtb2JpbGUgc2VuYXJpbywgDQpzdWNoIHNl bGVjdGlvbiBpcyByZWFzb25hYmxlOyBpbiB3aXJlZCBzZW5hcmlvLCBpdCBzZWVtcyBiZXR0ZXIg dG8gc2VsZWN0IGdvb2QgDQplbm91Z2ggcGVlcnMgd2l0aGluIG15IExBTiB0aGFuIHNlbGVjdCBE RUNBREUgc2VydmVycyB3aGljaCBpcyBtb3JlIGZhciBmcm9tIG1lLiANClRoaXMgd2lsbCByZWR1 Y2UgdGhlIHVubmVjZXNzYXJ5IHRyYWZmaWMgYW5kIHByb3ZpZGUgYmV0dGVyIHBlcmZvcm1hbmNl LjwvRk9OVD4gDQo8QlI+PEZPTlQgY29sb3I9Ymx1ZSBzaXplPTIgZmFjZT1WZXJkYW5hPiZuYnNw OzwvRk9OVD4gPEJSPjxGT05UIGNvbG9yPWJsdWUgDQpzaXplPTIgZmFjZT1WZXJkYW5hPkJSPC9G T05UPiA8QlI+PEZPTlQgY29sb3I9Ymx1ZSBzaXplPTIgDQpmYWNlPVZlcmRhbmE+WXVuZmVpPC9G T05UPiA8QlI+PEZPTlQgc2l6ZT0zIGZhY2U9c2Fucy1zZXJpZj4mbmJzcDs8L0ZPTlQ+IDxCUj4N CjxIUj4NCjxCUj48Rk9OVCBjb2xvcj0jYzBjMGMwIHNpemU9MiBmYWNlPVZlcmRhbmE+emhhbmd5 dW5mZWk8L0ZPTlQ+IDxCUj48Rk9OVCANCmNvbG9yPSNjMGMwYzAgc2l6ZT0yIGZhY2U9VmVyZGFu YT4yMDExLTAzLTE0PC9GT05UPiA8QlI+DQo8SFI+DQo8QlI+PEZPTlQgc2l6ZT0yIGZhY2U9VmVy ZGFuYT48Qj63orz+yMujujwvQj4gbGkubGljaHVuMUB6dGUuY29tLmNuPC9GT05UPiA8QlI+PEZP TlQgDQpzaXplPTIgZmFjZT1WZXJkYW5hPjxCPreiy83Ksbzko7o8L0I+IDIwMTEtMDMtMTEgMTc6 NDg6MzY8L0ZPTlQ+IDxCUj48Rk9OVCBzaXplPTIgDQpmYWNlPVZlcmRhbmE+PEI+ytW8/sjLo7o8 L0I+IERFQ0FERUBpZXRmLm9yZzwvRk9OVD4gPEJSPjxGT05UIHNpemU9MiANCmZhY2U9VmVyZGFu YT48Qj6zrcvNo7o8L0I+IDwvRk9OVD48QlI+PEZPTlQgc2l6ZT0yIGZhY2U9VmVyZGFuYT48Qj7W 98zio7o8L0I+IFtkZWNhZGVdIA0KSG93IGFib3V0IG1vZGlmeWluZyB0cmFja2VyIHRvIHN1cHBv cnQgREVDQURFPzwvRk9OVD4gPEJSPjxGT05UIHNpemU9MyANCmZhY2U9c2Fucy1zZXJpZj4mbmJz cDs8L0ZPTlQ+IDxCUj48Rk9OVCBzaXplPTIgZmFjZT1zYW5zLXNlcmlmPjxCUj5IaSANCmFsbCw8 L0ZPTlQ+PEZPTlQgc2l6ZT0yIGZhY2U9VmVyZGFuYT4gPC9GT05UPjxGT05UIHNpemU9MiBmYWNl PXNhbnMtc2VyaWY+PEJSPkl0IA0Kc2VlbXMgdGhhdCB0aGlzIFdHIGhhcyBub3QgY29uc2lkZXJl ZCBtb2RpZnlpbmcgdHJhY2tlciB0byBzdXBwb3J0IA0KREVDQURFLjwvRk9OVD48Rk9OVCBzaXpl PTIgZmFjZT1WZXJkYW5hPiA8L0ZPTlQ+PEZPTlQgc2l6ZT0yIA0KZmFjZT1zYW5zLXNlcmlmPjxC Uj5JIGJlbGlldmUgdGhhdCBtb2RpZnlpbmcgYm90aCB0cmFja2VyIGFuZCBwZWVyIGNhbiBtYWtl IA0KYmV0dGVyIHVzZSBvZiBERUNBREUgY29tcGFyZWQgd2l0aCBtb2RpZnlpbmcgcGVlciBvbmx5 LiA8QlI+V2UgaGF2ZSBwcm9wb3NlZCB0d28gDQpzb2x1dGlvbnMgYW5kIHN1Ym1pdHRlZCBhIGRy YWZ0IGFib3V0IGV4dGVuZGluZyBQUFNQIHRvIHN1cHBvcnQgREVDQURFIA0KKGh0dHA6Ly90b29s cy5pZXRmLm9yZy9odG1sL2RyYWZ0LWxlLXBwc3AtZGVjYWRlLWludGVyb3BlcmF0aW9uLTAwLnR4 dDwvRk9OVD48Rk9OVCANCnNpemU9MiBmYWNlPVZlcmRhbmE+IDwvRk9OVD48Rk9OVCBzaXplPTIg ZmFjZT1zYW5zLXNlcmlmPjxCUj4pLiBUaGUgc29sdXRpb25zIA0KYWxzbyBwdXQgc29tZSByZXF1 aXJlbWVudHMgb24gREVDQURFLjwvRk9OVD48Rk9OVCBzaXplPTIgZmFjZT1WZXJkYW5hPiANCjwv Rk9OVD48Rk9OVCBzaXplPTIgZmFjZT1zYW5zLXNlcmlmPjxCUj5JIHN1bW1hcml6ZSBvdXIgc29s dXRpb25zIGFzIGJlbG93LiANCkNvbW1lbnRzIGFyZSB3ZWxjb21lLjwvRk9OVD48Rk9OVCBzaXpl PTIgZmFjZT1WZXJkYW5hPiA8QlI+PC9GT05UPjxGT05UIHNpemU9MiANCmZhY2U9c2Fucy1zZXJp Zj48QlI+U29sdXRpb24gMTwvRk9OVD48Rk9OVCBzaXplPTIgZmFjZT1WZXJkYW5hPiA8L0ZPTlQ+ PEZPTlQgDQpzaXplPTIgZmFjZT1zYW5zLXNlcmlmPjxCUj5FYWNoIHBlZXIgcmVwb3J0cyB0byB0 cmFja2VyIHRoYXQgd2hldGhlciBpdCBoYXMgDQpERUNBREUgc2VydmVyIG9yIG5vdC4gUGVlciBB IHF1ZXJpZXMgcGVlciBsaXN0IGZyb20gdHJhY2tlci48L0ZPTlQ+PEZPTlQgc2l6ZT0yIA0KZmFj ZT1WZXJkYW5hPiA8L0ZPTlQ+PEZPTlQgc2l6ZT0yIGZhY2U9c2Fucy1zZXJpZj48QlI+VGhlIHBl ZXIgbGlzdCBpbmRpY2F0ZXMgDQp0aGF0IGVhY2ggcGVlciBoYXMgREVDQURFIHNlcnZlciBvciBu b3QuIFRoZSBQZWVyIEEgY2FuIHJlcXVlc3QgY29udGVudCBmcm9tIA0KcGVlcnMgaGF2aW5nIERF Q0FERSBzZXJ2ZXJzIHdpdGggaGlnaCBwcmlvcml0eS48L0ZPTlQ+PEZPTlQgc2l6ZT0yIGZhY2U9 VmVyZGFuYT4gDQo8QlI+PC9GT05UPjxGT05UIHNpemU9MiBmYWNlPXNhbnMtc2VyaWY+PEJSPlNv bHV0aW9uIDI8L0ZPTlQ+PEZPTlQgc2l6ZT0yIA0KZmFjZT1WZXJkYW5hPiA8L0ZPTlQ+PEZPTlQg c2l6ZT0yIGZhY2U9c2Fucy1zZXJpZj48QlI+VHJhY2tlciBtYWludGFpbnMgREVDQURFIA0KaW5m b3JtYXRpb24gKERFQ0FERSBsaXN0IGFuZCB0aGUgY29udGVudCBhdmFpbGFiaWxpdHkgaW5mb3Jt YXRpb24gb2YgZWFjaCBERUNBREUgDQpzZXJ2ZXIpLiBQZWVyIEEgcXVlcmllcyBub2RlIGxpc3Qg ZnJvbSB0cmFja2VyIGZvciBkb3dubG9hZGluZyBjb250ZW50LiBUcmFja2VyIA0KcmV0dXJucyB0 aGUgbGlzdCBvZiBwZWVycyBhbmQgREVDQURFIHNlcnZlcnMgaGF2aW5nIHJlcXVlc3RlZCBjb250 ZW50LiBUaGVuIFBlZXIgDQpBIGNhbiByZXF1ZXN0IGNvbnRlbnQgZnJvbSBvdGhlciBwZWVyJ3Mg b3IgdHJhY2tlcidzIERFQ0FERSBzZXJ2ZXIuPC9GT05UPjxGT05UIA0Kc2l6ZT0yIGZhY2U9VmVy ZGFuYT4gPC9GT05UPjxGT05UIHNpemU9MiBmYWNlPXNhbnMtc2VyaWY+PEJSPklmIHRoZSBERUNB REUgDQpzZXJ2aWNlIGlzIHJlbnQgYnkgcGVlcnMsIHBlZXJzIHVwbG9hZCBjb250ZW50cyB0byBE RUNBREUgc2VydmVycyBhbmQgcmVwb3J0IHRoZSANCkRFQ0FERSBpbmZvcm1hdGlvbiB0byB0cmFj a2VyLjwvRk9OVD48Rk9OVCBzaXplPTIgZmFjZT1WZXJkYW5hPiA8L0ZPTlQ+PEZPTlQgDQpzaXpl PTIgZmFjZT1zYW5zLXNlcmlmPjxCUj5JZiB0aGUgREVDQURFIHNlcnZpY2UgaXMgcmVudCBieSB0 cmFja2VyIChpLmUuIFAyUCANCmNvbnRlbnQgc2hhcmluZyBzZXJ2aWNlIHByb3ZpZGVyKSwgdHJh Y2tlciBpbnN0cnVjdCBwZWVycyB1cGxvYWRpbmcgY29udGVudHMgdG8gDQpERUNBREUgc2VydmVy cyBvciBERUNBREUgc2VydmVycyBkb3dubG9hZGluZyBjb250ZW50cyBmcm9tIHBlZXJzLjwvRk9O VD48Rk9OVCANCnNpemU9MiBmYWNlPVZlcmRhbmE+IDxCUj48L0ZPTlQ+PEZPTlQgc2l6ZT0yIGZh Y2U9c2Fucy1zZXJpZj48QlI+QlI8L0ZPTlQ+PEZPTlQgDQpzaXplPTIgZmFjZT1WZXJkYW5hPiA8 L0ZPTlQ+PEZPTlQgc2l6ZT0yIGZhY2U9c2Fucy1zZXJpZj48QlI+TGljaHVuPC9GT05UPiANCjxC Uj48Rk9OVCBzaXplPTIgDQpmYWNlPVZlcmRhbmE+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08QlI+WlRFIA0KSW5mb3JtYXRpb24gU2VjdXJp dHkgTm90aWNlOiBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgbWFpbCBpcyBzb2xl bHkgDQpwcm9wZXJ0eSBvZiB0aGUgc2VuZGVyJ3Mgb3JnYW5pemF0aW9uLiBUaGlzIG1haWwgY29t bXVuaWNhdGlvbiBpcyBjb25maWRlbnRpYWwuIA0KUmVjaXBpZW50cyBuYW1lZCBhYm92ZSBhcmUg b2JsaWdhdGVkIHRvIG1haW50YWluIHNlY3JlY3kgYW5kIGFyZSBub3QgcGVybWl0dGVkIA0KdG8g ZGlzY2xvc2UgdGhlIGNvbnRlbnRzIG9mIHRoaXMgY29tbXVuaWNhdGlvbiB0byBvdGhlcnMuPEJS PlRoaXMgZW1haWwgYW5kIGFueSANCmZpbGVzIHRyYW5zbWl0dGVkIHdpdGggaXQgYXJlIGNvbmZp ZGVudGlhbCBhbmQgaW50ZW5kZWQgc29sZWx5IGZvciB0aGUgdXNlIG9mIA0KdGhlIGluZGl2aWR1 YWwgb3IgZW50aXR5IHRvIHdob20gdGhleSBhcmUgYWRkcmVzc2VkLiBJZiB5b3UgaGF2ZSByZWNl aXZlZCB0aGlzIA0KZW1haWwgaW4gZXJyb3IgcGxlYXNlIG5vdGlmeSB0aGUgb3JpZ2luYXRvciBv ZiB0aGUgbWVzc2FnZS4gQW55IHZpZXdzIGV4cHJlc3NlZCANCmluIHRoaXMgbWVzc2FnZSBhcmUg dGhvc2Ugb2YgdGhlIGluZGl2aWR1YWwgc2VuZGVyLjxCUj5UaGlzIG1lc3NhZ2UgaGFzIGJlZW4g DQpzY2FubmVkIGZvciB2aXJ1c2VzIGFuZCBTcGFtIGJ5IFpURSBBbnRpLVNwYW0gc3lzdGVtLjxC Uj48L0ZPTlQ+PEJSPjxCUj48UFJFPi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpaVEUmbmJzcDtJbmZvcm1hdGlvbiZuYnNwO1NlY3VyaXR5 Jm5ic3A7Tm90aWNlOiZuYnNwO1RoZSZuYnNwO2luZm9ybWF0aW9uJm5ic3A7Y29udGFpbmVkJm5i c3A7aW4mbmJzcDt0aGlzJm5ic3A7bWFpbCZuYnNwO2lzJm5ic3A7c29sZWx5Jm5ic3A7cHJvcGVy dHkmbmJzcDtvZiZuYnNwO3RoZSZuYnNwO3NlbmRlcidzJm5ic3A7b3JnYW5pemF0aW9uLiZuYnNw O1RoaXMmbmJzcDttYWlsJm5ic3A7Y29tbXVuaWNhdGlvbiZuYnNwO2lzJm5ic3A7Y29uZmlkZW50 aWFsLiZuYnNwO1JlY2lwaWVudHMmbmJzcDtuYW1lZCZuYnNwO2Fib3ZlJm5ic3A7YXJlJm5ic3A7 b2JsaWdhdGVkJm5ic3A7dG8mbmJzcDttYWludGFpbiZuYnNwO3NlY3JlY3kmbmJzcDthbmQmbmJz cDthcmUmbmJzcDtub3QmbmJzcDtwZXJtaXR0ZWQmbmJzcDt0byZuYnNwO2Rpc2Nsb3NlJm5ic3A7 dGhlJm5ic3A7Y29udGVudHMmbmJzcDtvZiZuYnNwO3RoaXMmbmJzcDtjb21tdW5pY2F0aW9uJm5i c3A7dG8mbmJzcDtvdGhlcnMuDQpUaGlzJm5ic3A7ZW1haWwmbmJzcDthbmQmbmJzcDthbnkmbmJz cDtmaWxlcyZuYnNwO3RyYW5zbWl0dGVkJm5ic3A7d2l0aCZuYnNwO2l0Jm5ic3A7YXJlJm5ic3A7 Y29uZmlkZW50aWFsJm5ic3A7YW5kJm5ic3A7aW50ZW5kZWQmbmJzcDtzb2xlbHkmbmJzcDtmb3Im bmJzcDt0aGUmbmJzcDt1c2UmbmJzcDtvZiZuYnNwO3RoZSZuYnNwO2luZGl2aWR1YWwmbmJzcDtv ciZuYnNwO2VudGl0eSZuYnNwO3RvJm5ic3A7d2hvbSZuYnNwO3RoZXkmbmJzcDthcmUmbmJzcDth ZGRyZXNzZWQuJm5ic3A7SWYmbmJzcDt5b3UmbmJzcDtoYXZlJm5ic3A7cmVjZWl2ZWQmbmJzcDt0 aGlzJm5ic3A7ZW1haWwmbmJzcDtpbiZuYnNwO2Vycm9yJm5ic3A7cGxlYXNlJm5ic3A7bm90aWZ5 Jm5ic3A7dGhlJm5ic3A7b3JpZ2luYXRvciZuYnNwO29mJm5ic3A7dGhlJm5ic3A7bWVzc2FnZS4m bmJzcDtBbnkmbmJzcDt2aWV3cyZuYnNwO2V4cHJlc3NlZCZuYnNwO2luJm5ic3A7dGhpcyZuYnNw O21lc3NhZ2UmbmJzcDthcmUmbmJzcDt0aG9zZSZuYnNwO29mJm5ic3A7dGhlJm5ic3A7aW5kaXZp ZHVhbCZuYnNwO3NlbmRlci4NClRoaXMmbmJzcDttZXNzYWdlJm5ic3A7aGFzJm5ic3A7YmVlbiZu YnNwO3NjYW5uZWQmbmJzcDtmb3ImbmJzcDt2aXJ1c2VzJm5ic3A7YW5kJm5ic3A7U3BhbSZuYnNw O2J5Jm5ic3A7WlRFJm5ic3A7QW50aS1TcGFtJm5ic3A7c3lzdGVtLg0KPC9QUkU+PC9GT05UPjwv RElWPjwvQk9EWT48L0hUTUw+DQo= --=====003_Dragon514602362137_=====-- From haibin.song@huawei.com Thu Mar 17 18:37:56 2011 Return-Path: X-Original-To: decade@core3.amsl.com Delivered-To: decade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 350453A69E2 for ; Thu, 17 Mar 2011 18:37:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.762 X-Spam-Level: X-Spam-Status: No, score=-3.762 tagged_above=-999 required=5 tests=[AWL=0.733, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uQhWfQPsS8CF for ; Thu, 17 Mar 2011 18:37:54 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 07BA23A69CF for ; Thu, 17 Mar 2011 18:37:54 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LI80060TCIECT@szxga03-in.huawei.com> for decade@ietf.org; Fri, 18 Mar 2011 09:37:26 +0800 (CST) Received: from szxeml207-edg.china.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LI800BL7CIEZH@szxga03-in.huawei.com> for decade@ietf.org; Fri, 18 Mar 2011 09:37:26 +0800 (CST) Received: from SZXEML401-HUB.china.huawei.com (10.82.67.31) by szxeml207-edg.china.huawei.com (172.24.2.59) with Microsoft SMTP Server (TLS) id 14.1.270.1; Fri, 18 Mar 2011 09:37:19 +0800 Received: from SZXEML505-MBS.china.huawei.com ([169.254.1.207]) by SZXEML401-HUB.china.huawei.com ([10.82.67.31]) with mapi id 14.01.0270.001; Fri, 18 Mar 2011 09:37:25 +0800 Date: Fri, 18 Mar 2011 01:37:24 +0000 From: Songhaibin X-Originating-IP: [10.138.41.84] To: "decade@ietf.org" Message-id: MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: zh-CN Content-transfer-encoding: 7BIT Accept-Language: en-US, zh-CN Thread-topic: DECADE Agenda for IETF 80 Thread-index: AcvlDQiE8x8ajFM9TVmB6ZKbJX4wXQ== X-MS-Has-Attach: X-MS-TNEF-Correlator: Subject: [decade] DECADE Agenda for IETF 80 X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.9 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, 18 Mar 2011 01:37:56 -0000 Dear all, Here is a draft agenda for IETF 80. If you have any concern, please send email to Rich and me. Please notice that our meeting will be held on Monday afternoon, which means you should start preparing your slides early. Monday, March 28, 2011, 1300-1500, Grand Ballroom Agenda: Agenda Bash, Chairs, 5 minutes, 1300-1305 Problem Statement, Haibin Song, draft-ietf-decade-problem-statement-03, 5 minutes, 1305-1310 Survey, Akbar Rahman, draft-ietf-decade-survey-04, 5 minutes, 1310-1315 DECADE Architecture, Richard Alimi, draft-ietf-decade-arch-00, 20 minutes, 1315-1335 Requirements, TBD, draft-ietf-decade-reqs-01, 20 minutes, 1335-1355 Integration examples, TBD, draft-chen-decade-intgr-livestr-exmp-01, 15 minutes, 1355-1410 PPSP and DECADE Interoperation, Lichun Li, draft-le-ppsp-decade-interoperation-00, 10 minutes 1410-1420 Secure Naming, Borje Ohlman, draft-dannewitz-ppsp-secure-naming-02, 10 minutes 1420-1430 Rechartering Discussion, Chairs, 20 minutes, 1430-1450 Conclusion and next steps, Chairs, 10 minutes, 1450-1500 You can also find our agenda with the link below. http://www.ietf.org/proceedings/80/agenda/decade.html Thanks, Haibin and Rich (Chairs) From li.lichun1@zte.com.cn Tue Mar 22 19:48:42 2011 Return-Path: X-Original-To: decade@core3.amsl.com Delivered-To: decade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 57CF928C0E8; Tue, 22 Mar 2011 19:48:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.906 X-Spam-Level: X-Spam-Status: No, score=-97.906 tagged_above=-999 required=5 tests=[AWL=-1.171, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_62=0.6, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oYee8ZrXnP7a; Tue, 22 Mar 2011 19:48:40 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [63.218.89.70]) by core3.amsl.com (Postfix) with ESMTP id 93CA93A687F; Tue, 22 Mar 2011 19:48:39 -0700 (PDT) Received: from [10.34.0.130] by mx5.zte.com.cn with surfront esmtp id 35101838658141; Wed, 23 Mar 2011 10:47:20 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.16] with StormMail ESMTP id 73094.2705217652; Wed, 23 Mar 2011 10:39:53 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id p2N2o2Z1088592; Wed, 23 Mar 2011 10:50:02 +0800 (GMT-8) (envelope-from li.lichun1@zte.com.cn) In-Reply-To: <002601cbe83d$03523780$09f6a680$@chinamobile.com> To: =?GB2312?B?tcvB6cDyL2RlbmdsaW5nbGk=?= MIME-Version: 1.0 X-KeepSent: 8611E982:43D94FC0-4825785C:000626A1; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: li.lichun1@zte.com.cn Date: Wed, 23 Mar 2011 10:49:55 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-03-23 10:50:02, Serialize complete at 2011-03-23 10:50:02 Content-Type: multipart/alternative; boundary="=_alternative 000FA6E44825785C_=" X-MAIL: mse02.zte.com.cn p2N2o2Z1088592 Cc: 'ppsp' , decade@ietf.org Subject: Re: [decade] [ppsp] Supporting DECADE in PPSP X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.9 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, 23 Mar 2011 02:48:42 -0000 This is a multipart message in MIME format. --=_alternative 000FA6E44825785C_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGkgTGluZ2xpLA0KDQpUaGUgbWVzc2FnZSBmbG93cyBvZiBjbG9zZSBpbnRlZ3JhdGlvbiBpbiB0 aGUgZHJhZnQgYXJlIHdyb25nLiBJIGhhdmUgDQp1cGRhdGVkIHRoZW0gaW4gbXkgc2xpZGVzLiBU aGUgcmlnaHQgZmxvd3MgYXJlIGRlc2NyaWJlZCBhcyBiZWxvdy4gDQpJZiB0aGUgREVDQURFIHNl cnZlciBpcyByZW50IGJ5IHBlZXIsIHBlZXIgcmVwb3J0cyBERUNBREUgc3RhdHVzIHRvIA0KdHJh Y2tlciB3aGVuIHRoZSBzdGF0dXMgY2hhbmdlcy4NCklmIHRoZSBERUNBREUgc2VydmVyIGlzIHJl bnQgYnkgUDJQIHN0cmVhbWluZyBzZXJ2aWNlIHByb3ZpZGVyLCB0cmFja2VyIA0KYXNrcyBERUNB REUgc2VydmVyIHRvIGRvd25sb2FkIHNwZWNpZmljIGNvbnRlbnQgZnJvbSBzcGVjaWZpYyBwZWVy LCBvciANCmFza3MgcGVlciB0byB1cGxvYWQgc3BlY2lmaWMgY29udGVudCB0byBzcGVjaWZpYyBE RUNBREUgc2VydmVyLiBJbiBhbm90aGVyIA0Kd29yZCwgdHJhY2tlciBjYW4gY29udHJvbCB0aGUg Y29udGVudCBkaXN0cmlidXRpb24gaW4gREVDQURFIHNlcnZlcnMgDQphY2NvcmRpbmcgdG8gdGhl IGNvcHkgbnVtYmVyIGFuZCBkZW1hbmQgcmF0ZSBvZiBldmVyeSBjb250ZW50LiBUaGlzIGNhbiAN Cm1ha2UgYmV0dGVyIHVzZSBvZiBERUNBREUgcmVzb3VyY2VzLiANCg0KQlINCkxpY2h1bg0KDQq1 y8HpwPIvZGVuZ2xpbmdsaSA8ZGVuZ2xpbmdsaUBjaGluYW1vYmlsZS5jb20+INC009ogMjAxMS0w My0yMiAxMDo1ODoyNToNCg0KPiBIaSBMaWNodW4sDQo+IA0KPiBGb3IgdGhlIGNsb3NlIGludGVn cmF0aW9uIG1vZGUgeW91IG1lbnRpb25lZCwgSSB3b25kZXIgaWYgUFBTUCANCj4gdHJhY2tlciB3 b3VsZCBiZSBib3RoZXJlZCBieSB0aGUgdW5uZWNlc3Nhcnkgc2lnbmFsaW5nIGJ1cmRlbiBmb3Ig DQo+IHRoZSByZXBlYXRlZCBERUNBREUgc3RhdHVzIHVwZGF0ZXMgZm9yIGEgc2luZ2xlIERFQ0FE RSBzZXJ2ZXIgZm9yIA0KPiBmcm9tIHRoZSBwZWVyIGdyb3VwIHNoYXJlIGl0cyByZXNvdXJjZS4N Cj4gV2hhdCBkbyB5b3UgdGhpbms/DQo+IA0KPiBMaW5nbGkgRGVuZw0KPiANCj4gt6K8/sjLOiBw cHNwLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpwcHNwLWJvdW5jZXNAaWV0Zi5vcmddILT6se0g wNa52g0KPiC3osvNyrG85DogMjAxMcTqM9TCMTbI1SAxNzo0Ng0KPiDK1bz+yMs6IGxpLmxpY2h1 bjENCj4gs63LzTogcHBzcA0KPiDW98ziOiBSZTogW3Bwc3BdIFN1cHBvcnRpbmcgREVDQURFIGlu IFBQU1ANCj4gDQo+IEhpIFl1bmZlaSBhbmQgTGljaHVuDQo+IA0KPiBUaGFuayB5b3UgZm9yIHlv dXIgY29tbWVudHMuIEkgd2lsbCB1cGRhdGUgZHJhZnQgYmFzZWQgb24geW91ciANCj4gc3VnZ2Vz dGlvbi4gSGVyZSBhcmUgbXkgY29uc2lkZXJhdGlvbnMgaW4gbGluZToNCj4gDQo+IDEpIFRoZSB0 YXJnZXQgb2YgdGhpcyBkcmFmdDogSXMgaXQgYmV0dGVyIHRvIGRpc2N1c3MgdGhlIGludGVyLQ0K PiBvcGVhcmFiaWxpdHkgYmV0d2VlbiBQUFNQIGFuZCBERUNBREU7b3IgZGlzY3VzcyB0aGUgdXNh Z2Ugb2YgREVDQURFIA0KPiBpbiBQUFNQPyBJIG1lYW4gdGhlIGZvY3VzIG1heSBiZSBhIGxpdHRs ZSBiaXQgZGlmZmVyZW50OiBJbiB0aGUgDQo+IGZvcm1lciBjYXNlLCB0aGUgZm9jdXMgaXMgaG93 IHRoZSBwcm90b2NvbHMgaW50ZXItYWN0IGluIHRoZSBtZXNhZ2UgDQo+IG9wdGlvbnMgZXhjaGFu Z2U7IGluIHRoZSBsYXR0ZXIgY2FzZSwgdGhlIGZvY3VzIGlzIGhvdyB0aGUgUFBTUCANCj4gYXBw bGljYXRpb25zIHVzZSBERUNBREUgdG8gZW5oYW5jZSB0aGUgcGVyZm9ybWFuY2UuIEkgcHJlZmVy IHRvIA0KPiB0YWtpbmcgaXQgYXMgdGhlIHVzYWdlLg0KPiBJIGFncmVlIHlvdXIgb3Bpbmlvbi4g V2hhdCdzIG1vcmUsIGNvbnRlbnQgYWJvdXQgUFBTUCBhbmQgREVDQURFIA0KPiBpbnRlcm9wZXJh dGlvbiBhaW1zIHRvIHByb3ZpZGUgc2NlbmFyaW9zIGZvciB1c2FnZS4gQWxzbywgd2UgY2FuIA0K PiBsaXN0IHNvbWUgZXh0ZW5zaW9uIHN1Z2dlc3Rpb25zIHRvIGJvdGggcHJvdG9jb2wuIFBlaGFy cHMgSSBjYW4gYWRkIA0KPiBhIG5ldyBjaGFwdGVyIHRvIHRob3NlIHN1Z2dlc3Rpb24uDQo+IA0K PiAyKSBTaG91bGQgd2UgbWFrZSBERUNBREUgc2VydmVyIHNlbGVjdGlvbiB3aXRoIHByaW9yaXR5 IGFsbCB0aGUgDQo+IHRpbWU/IEluIHRoZSBtb2JpbGUgc2VuYXJpbywgc3VjaCBzZWxlY3Rpb24g aXMgcmVhc29uYWJsZTsgaW4gd2lyZWQgDQo+IHNlbmFyaW8sIGl0IHNlZW1zIGJldHRlciB0byBz ZWxlY3QgZ29vZCBlbm91Z2ggcGVlcnMgd2l0aGluIG15IExBTiANCj4gdGhhbiBzZWxlY3QgREVD QURFIHNlcnZlcnMgd2hpY2ggaXMgbW9yZSBmYXIgZnJvbSBtZS4gVGhpcyB3aWxsIA0KPiByZWR1 Y2UgdGhlIHVubmVjZXNzYXJ5IHRyYWZmaWMgYW5kIHByb3ZpZGUgYmV0dGVyIHBlcmZvcm1hbmNl Lg0KPiBJIGFncmVlLiBXZSBzaG91bGQgZGVzaWduIGJhc2VkIG9uIGRpZmZlcmVudCBzY2VuYXJp b3MuIE9uZSBtb3JlIA0KPiBxdWVzdGlvbiwgc2hvdWxkIHBlZXIgdXBsb2FkIGNvbnRlbnQgdG8g REVDQURFIHNlcnZlciBhdXRvbWF0aWNhbGx5IA0KPiB3aGVuIGdldCBkYXRhIGZyb20gb3RoZXIg cGVlcnM/IFBlcmhhcHMgaW4gcHVzaC1iYXNlZCBtb2RlbCwgaXQgbWF5IA0KPiBiZSByZWFzb25h YmxlOyBpbiBwdWxsLWJhc2VkIG1vZGVsLCBwZWVyIGNhbiB3YWl0IGZvciBvdGhlciBwZWVycycg DQo+IHJlcXVlc3QgYW5kIHRoZW4gdGFrZSBhY3Rpb24gdG8gcmVxdWVzdHMuDQo+IA0KPiANCj4g R3VhbiBMZQ0KPiBTY2hvb2wgb2YgQ29tcHV0ZXIgU2NpZW5jZQ0KPiBCZWlqaW5nIFVuaXZlcnNp dHkgb2YgUG9zdHMgYW5kIFRlbGVjb21tdW5pY2F0aW9ucw0KPiAgMjAxMS0wMy0xNg0KPiANCj4g RnJvbTogIGxpLmxpY2h1bjEgDQo+IERhdGU6ICAyMDExLTAzLTE0ICAxMzo0MDowOSANCj4gVG86 ICB6aGFuZ3l1bmZlaSANCj4gQ2M6ICBwcHNwQGlldGYub3JnIA0KPiBTdWJqZWN0OiAgUmU6IFtw cHNwXSBTdXBwb3J0aW5nIERFQ0FERSBpbiBQUFNQIA0KPiANCj4gDQo+IEhpIHl1bmZlaSwgDQo+ IFRoYW5rcyBmb3IgeW91ciBjb21tZW50cy4gDQo+IDEpIFRoZSBmb2N1cyBpcyB0aGUgdXNhZ2Ug b2YgREVDQURFIGluIFBQU1AuIFRoZSB1c2FnZSBhbHNvIG5lZWRzIA0KPiBzb21lIGV4dGVuc2lv bnMgdG8gdGhlIHByb3RvY29scy4gDQo+IDIpIFlvdSBhcmUgcmlnaHQuIFRoZSBwcmlvcml0eSBv ZiBERUNBREUgZGVwZW5kcyBvbiBzY2VuYXJpbyBhbmQgDQo+IHBlZXIvREVDQURFIHNlbGVjdGlv biBhbGdvcml0aG0uIFNvbWV0aW1lcywgZG93bmxvYWRpbmcgZnJvbSBwZWVyIGlzDQo+IGJldHRl ci4gQWxzbywgc29tZSBzY2VuYXJpb3MgbWF5IHVzZSBERUNBREUgYXMgYmFja3VwIG9ubHkgYW5k IGdpdmUgDQo+IGxvdyBwcmlvcml0eSB0byBERUNBREUuIA0KPiANCj4gQlIgDQo+IExpY2h1biAN Cj4gDQoNCj4gDQo+ICJ6aGFuZ3l1bmZlaSIgPHpoYW5neXVuZmVpQGNoaW5hbW9iaWxlLmNvbT4g DQo+IDIwMTEtMDMtMTQgMTA6MzEgDQo+IA0KPiDK1bz+yMsNCj4gDQo+ICJsaS5saWNodW4xQHp0 ZS5jb20uY24iIDxsaS5saWNodW4xQHp0ZS5jb20uY24+LCAicHBzcEBpZXRmLm9yZyIgPA0KPiBw cHNwQGlldGYub3JnPiANCj4gDQo+ILOty80NCj4gDQo+INb3zOINCj4gDQo+IFJlOiBbcHBzcF0g U3VwcG9ydGluZyBERUNBREUgaW4gUFBTUA0KPiANCj4gDQo+IA0KPiANCj4gDQo+IA0KPiBIaSBM aWNodW4sIA0KPiAgICAgVGhpcyBpcyBhbiBpbnRlcnN0aW5nIHRvcGljIEkgdGhvdWdodCBhbmQg ZGlzY3Vzc2VkIGR1cmluZyB0aGUgDQo+IHNldCB1cCBvZiBQUFNQIGFuZCBERUNBREUuIFRoYW5r cyBmb3IgbWFraW5nIGl0IG1vcmUgY2xlYXI6KS5Tb21lIA0KPiBzdWdnZXN0aW9ucyBhcmUgYXMg Zm9sbG93czogDQo+IDEpIFRoZSB0YXJnZXQgb2YgdGhpcyBkcmFmdDogSXMgaXQgYmV0dGVyIHRv IGRpc2N1c3MgdGhlIGludGVyLQ0KPiBvcGVhcmFiaWxpdHkgYmV0d2VlbiBQUFNQIGFuZCBERUNB REU7b3IgZGlzY3VzcyB0aGUgdXNhZ2Ugb2YgREVDQURFIA0KPiBpbiBQUFNQPyBJIG1lYW4gdGhl IGZvY3VzIG1heSBiZSBhIGxpdHRsZSBiaXQgZGlmZmVyZW50OiBJbiB0aGUgDQo+IGZvcm1lciBj YXNlLCB0aGUgZm9jdXMgaXMgaG93IHRoZSBwcm90b2NvbHMgaW50ZXItYWN0IGluIHRoZSBtZXNh Z2UgDQo+IG9wdGlvbnMgZXhjaGFuZ2U7IGluIHRoZSBsYXR0ZXIgY2FzZSwgdGhlIGZvY3VzIGlz IGhvdyB0aGUgUFBTUCANCj4gYXBwbGljYXRpb25zIHVzZSBERUNBREUgdG8gZW5oYW5jZSB0aGUg cGVyZm9ybWFuY2UuIEkgcHJlZmVyIHRvIA0KPiB0YWtpbmcgaXQgYXMgdGhlIHVzYWdlLiANCj4g MikgU2hvdWxkIHdlIG1ha2UgREVDQURFIHNlcnZlciBzZWxlY3Rpb24gd2l0aCBwcmlvcml0eSBh bGwgdGhlIA0KPiB0aW1lPyBJbiB0aGUgbW9iaWxlIHNlbmFyaW8sIHN1Y2ggc2VsZWN0aW9uIGlz IHJlYXNvbmFibGU7IGluIHdpcmVkIA0KPiBzZW5hcmlvLCBpdCBzZWVtcyBiZXR0ZXIgdG8gc2Vs ZWN0IGdvb2QgZW5vdWdoIHBlZXJzIHdpdGhpbiBteSBMQU4gDQo+IHRoYW4gc2VsZWN0IERFQ0FE RSBzZXJ2ZXJzIHdoaWNoIGlzIG1vcmUgZmFyIGZyb20gbWUuIFRoaXMgd2lsbCANCj4gcmVkdWNl IHRoZSB1bm5lY2Vzc2FyeSB0cmFmZmljIGFuZCBwcm92aWRlIGJldHRlciBwZXJmb3JtYW5jZS4g DQo+IA0KPiBCUiANCj4gWXVuZmVpIA0KPiANCj4gDQo+IA0KPiB6aGFuZ3l1bmZlaSANCj4gMjAx MS0wMy0xNCANCj4gDQo+IA0KPiC3orz+yMujuiBsaS5saWNodW4xQHp0ZS5jb20uY24gDQo+ILei y83Ksbzko7ogMjAxMS0wMy0wOCAxNzo0NzoxMSANCj4gytW8/sjLo7ogcHBzcEBpZXRmLm9yZyAN Cj4gs63LzaO6IA0KPiDW98zio7ogW3Bwc3BdIFN1cHBvcnRpbmcgREVDQURFIGluIFBQU1AgDQo+ IA0KPiANCj4gSGksIGFsbCANCj4gDQo+IFdlIHN1Ym1pdHRlZCBhIG5ldyBkcmFmdCBhYm91dCBz dXBwb3J0aW5nIERFQ0FERSBpbiBQUFNQLiBJdCBjYW4gYmUgDQo+IGFjY2Vzc2VkIGF0IA0KaHR0 cDovL3d3dy5pZXRmLm9yZy9pZC9kcmFmdC1sZS1wcHNwLWRlY2FkZS1pbnRlcm9wZXJhdGlvbi0w MC50eHQNCj4gQ29tbWVudHMgYXJlIHdlbGNvbWUuIA0KPiANCj4gQlIgDQo+IExpY2h1biANCj4g DQo+IEEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1sZS1wcHNwLWRlY2FkZS1pbnRlcm9wZXJh dGlvbi0wMC50eHQgaGFzDQo+IGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBHdWFuIExl IGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgDQpyZXBvc2l0b3J5Lg0KPiANCj4gRmlsZW5hbWU6ICAg ICAgICAgICAgICAgICAgZHJhZnQtbGUtcHBzcC1kZWNhZGUtaW50ZXJvcGVyYXRpb24NCj4gUmV2 aXNpb246ICAgICAgICAgICAgICAgICAgMDANCj4gVGl0bGU6ICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICBQUFNQIFVzYWdlIGZvciBERUNBREUNCj4gQ3JlYXRpb25fZGF0ZTogICAg ICAgICAgICAgICAgICAyMDExLTAzLTA3DQo+IFdHIElEOiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgSW5kZXBlbmRlbnQgU3VibWlzc2lvbg0KPiBOdW1iZXJfb2ZfcGFnZXM6IDE0 DQo+IA0KPiBBYnN0cmFjdDoNCj4gUDJQIFN0cmVhbWluZyBoYXMgYmVjb21lIHBvcHVsYXIgYXBw bGljYXRpb24gaW4gdGhlIEludGVybmV0Lg0KPiBDdXJyZW50bHksIG1vc3QgaG9tZSBzdWJzY3Jp YmVycyBhY2Nlc3MgSW50ZXJuZXQgdmlhIEFEU0wsIGluIHdoaWNoDQo+IGRvd25saW5rIGJhbmR3 aWR0aCBhbmQgdXBsaW5rIGJhbmR3aWR0aCBhcmUgbm90IHN5bW1ldHJpYy4gIFRoaXMNCj4gZmVh dHVyZSB3b3VsZCBpbmZsdWVuY2UgdGhlIHBlcmZvcm1hbmNlIG9mIFAyUCBTdHJlYW1pbmcsIGFu ZCB0aGUNCj4gcHJvYmxlbSBtYXkgYmUgd29yc2UgaW4gbW9iaWxlIHNjZW5hcmlvcy4gIFRoaXMg ZHJhZnQgcHJlc2VudHMgdGhlDQo+IGludGVyb3BlcmF0aW9uIGJldHdlZW4gUFBTUCBwcm90b2Nv bCBhbmQgREVDQURFIHByb3RvY29sIHRvIHByb3ZpZGUNCj4gREVDQURFIHNlcnZpY2UgZm9yIFBQ U1AgYXBwbGljYXRpb25zLiAgVHlwaWNhbGx5LCB0aGVyZSBhcmUgdHdvDQo+IHNvbHV0aW9uIHRv IGFjaGlldmUgaW50ZXJvcGVyYXRpb24sIGxvb3NlIGludGVyb3BlcmF0aW9uIGFtb25nIHBlZXJz LA0KPiBhbmQgY2xvc2UgaW50ZXJvcGVyYXRpb24gdmlhIGNvbm5lY3Rpb24gb2YgcGVlciBhbmQg dHJhY2tlci4gIEJ5DQo+IGludHJvZHVjaW5nIERFQ0FERSBpbiBib3RoIHRyYWNrZXIgcHJvdG9j b2wgYW5kIHBlZXIgcHJvdG9jb2wsIFBQU1ANCj4gc3RyZWFtaW5nIGNhbiBhbGxldmlhdGUgc3Ry ZW5ndGggb2YgdXBsb2FkIGJhbmR3aWR0aCBhbmQgaW1wcm92ZQ0KPiBwZXJmb3JtYW5jZSBmb3Ig Zml4IGFuZCBtb2JpbGUgc2NlbmFyaW8uDQo+ICANCj4gDQo+IA0KPiBUaGUgSUVURiBTZWNyZXRh cmlhdC4NCj4gDQo+IA0KPiANCj4gDQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IFpURSBJbmZvcm1hdGlvbiBTZWN1cml0eSBOb3Rp Y2U6IFRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyANCj4gbWFpbCBpcyBzb2xlbHkg cHJvcGVydHkgb2YgdGhlIHNlbmRlcidzIG9yZ2FuaXphdGlvbi4gVGhpcyBtYWlsIA0KPiBjb21t dW5pY2F0aW9uIGlzIGNvbmZpZGVudGlhbC4gUmVjaXBpZW50cyBuYW1lZCBhYm92ZSBhcmUgb2Js aWdhdGVkIA0KPiB0byBtYWludGFpbiBzZWNyZWN5IGFuZCBhcmUgbm90IHBlcm1pdHRlZCB0byBk aXNjbG9zZSB0aGUgY29udGVudHMgDQo+IG9mIHRoaXMgY29tbXVuaWNhdGlvbiB0byBvdGhlcnMu DQo+IFRoaXMgZW1haWwgYW5kIGFueSBmaWxlcyB0cmFuc21pdHRlZCB3aXRoIGl0IGFyZSBjb25m aWRlbnRpYWwgYW5kIA0KPiBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2 aWR1YWwgb3IgZW50aXR5IHRvIHdob20gdGhleQ0KPiBhcmUgYWRkcmVzc2VkLiBJZiB5b3UgaGF2 ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yIHBsZWFzZSANCj4gbm90aWZ5IHRoZSBvcmln aW5hdG9yIG9mIHRoZSBtZXNzYWdlLiBBbnkgdmlld3MgZXhwcmVzc2VkIGluIHRoaXMgDQo+IG1l c3NhZ2UgYXJlIHRob3NlIG9mIHRoZSBpbmRpdmlkdWFsIHNlbmRlci4NCj4gVGhpcyBtZXNzYWdl IGhhcyBiZWVuIHNjYW5uZWQgZm9yIHZpcnVzZXMgYW5kIFNwYW0gYnkgWlRFIEFudGktU3BhbSAN CnN5c3RlbS4NCg0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLQ0KPiBaVEUgSW5mb3JtYXRpb24gU2VjdXJpdHkgTm90aWNlOiBUaGUgaW5m b3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgDQo+IG1haWwgaXMgc29sZWx5IHByb3BlcnR5IG9m IHRoZSBzZW5kZXIncyBvcmdhbml6YXRpb24uIFRoaXMgbWFpbCANCj4gY29tbXVuaWNhdGlvbiBp cyBjb25maWRlbnRpYWwuIFJlY2lwaWVudHMgbmFtZWQgYWJvdmUgYXJlIG9ibGlnYXRlZCANCj4g dG8gbWFpbnRhaW4gc2VjcmVjeSBhbmQgYXJlIG5vdCBwZXJtaXR0ZWQgdG8gZGlzY2xvc2UgdGhl IGNvbnRlbnRzIA0KPiBvZiB0aGlzIGNvbW11bmljYXRpb24gdG8gb3RoZXJzLg0KPiBUaGlzIGVt YWlsIGFuZCBhbnkgZmlsZXMgdHJhbnNtaXR0ZWQgd2l0aCBpdCBhcmUgY29uZmlkZW50aWFsIGFu ZCANCj4gaW50ZW5kZWQgc29sZWx5IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsIG9yIGVu dGl0eSB0byB3aG9tIHRoZXkNCj4gYXJlIGFkZHJlc3NlZC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQg dGhpcyBlbWFpbCBpbiBlcnJvciBwbGVhc2UgDQo+IG5vdGlmeSB0aGUgb3JpZ2luYXRvciBvZiB0 aGUgbWVzc2FnZS4gQW55IHZpZXdzIGV4cHJlc3NlZCBpbiB0aGlzIA0KPiBtZXNzYWdlIGFyZSB0 aG9zZSBvZiB0aGUgaW5kaXZpZHVhbCBzZW5kZXIuDQo+IFRoaXMgbWVzc2FnZSBoYXMgYmVlbiBz Y2FubmVkIGZvciB2aXJ1c2VzIGFuZCBTcGFtIGJ5IFpURSBBbnRpLVNwYW0gDQpzeXN0ZW0uDQoN Cg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0NClpURSBJbmZvcm1hdGlvbiBTZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZvcm1hdGlvbiBjb250 YWluZWQgaW4gdGhpcyBtYWlsIGlzIHNvbGVseSBwcm9wZXJ0eSBvZiB0aGUgc2VuZGVyJ3Mgb3Jn YW5pemF0aW9uLiBUaGlzIG1haWwgY29tbXVuaWNhdGlvbiBpcyBjb25maWRlbnRpYWwuIFJlY2lw aWVudHMgbmFtZWQgYWJvdmUgYXJlIG9ibGlnYXRlZCB0byBtYWludGFpbiBzZWNyZWN5IGFuZCBh cmUgbm90IHBlcm1pdHRlZCB0byBkaXNjbG9zZSB0aGUgY29udGVudHMgb2YgdGhpcyBjb21tdW5p Y2F0aW9uIHRvIG90aGVycy4NClRoaXMgZW1haWwgYW5kIGFueSBmaWxlcyB0cmFuc21pdHRlZCB3 aXRoIGl0IGFyZSBjb25maWRlbnRpYWwgYW5kIGludGVuZGVkIHNvbGVseSBmb3IgdGhlIHVzZSBv ZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgdG8gd2hvbSB0aGV5IGFyZSBhZGRyZXNzZWQuIElm IHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IgcGxlYXNlIG5vdGlmeSB0aGUg b3JpZ2luYXRvciBvZiB0aGUgbWVzc2FnZS4gQW55IHZpZXdzIGV4cHJlc3NlZCBpbiB0aGlzIG1l c3NhZ2UgYXJlIHRob3NlIG9mIHRoZSBpbmRpdmlkdWFsIHNlbmRlci4NClRoaXMgbWVzc2FnZSBo YXMgYmVlbiBzY2FubmVkIGZvciB2aXJ1c2VzIGFuZCBTcGFtIGJ5IFpURSBBbnRpLVNwYW0gc3lz dGVtLg0K --=_alternative 000FA6E44825785C_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yPkhpIExpbmdsaSw8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6 ZT0yPlRoZSBtZXNzYWdlIGZsb3dzIG9mIGNsb3NlIGludGVncmF0aW9uIGluIHRoZSBkcmFmdCBh cmUNCndyb25nLiBJIGhhdmUgdXBkYXRlZCB0aGVtIGluIG15IHNsaWRlcy4gVGhlIHJpZ2h0IGZs b3dzIGFyZSBkZXNjcmliZWQNCmFzIGJlbG93LiA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yPklm IHRoZSBERUNBREUgc2VydmVyIGlzIHJlbnQgYnkgcGVlciwgcGVlciByZXBvcnRzIERFQ0FERQ0K c3RhdHVzIHRvIHRyYWNrZXIgd2hlbiB0aGUgc3RhdHVzIGNoYW5nZXMuPC9mb250Pg0KPGJyPjxm b250IHNpemU9Mj5JZiB0aGUgREVDQURFIHNlcnZlciBpcyByZW50IGJ5IFAyUCBzdHJlYW1pbmcg c2VydmljZQ0KcHJvdmlkZXIsIHRyYWNrZXIgYXNrcyBERUNBREUgc2VydmVyIHRvIGRvd25sb2Fk IHNwZWNpZmljIGNvbnRlbnQgZnJvbQ0Kc3BlY2lmaWMgcGVlciwgb3IgYXNrcyBwZWVyIHRvIHVw bG9hZCBzcGVjaWZpYyBjb250ZW50IHRvIHNwZWNpZmljIERFQ0FERQ0Kc2VydmVyLiBJbiBhbm90 aGVyIHdvcmQsIHRyYWNrZXIgY2FuIGNvbnRyb2wgdGhlIGNvbnRlbnQgZGlzdHJpYnV0aW9uIGlu DQpERUNBREUgc2VydmVycyBhY2NvcmRpbmcgdG8gdGhlIGNvcHkgbnVtYmVyIGFuZCBkZW1hbmQg cmF0ZSBvZiBldmVyeSBjb250ZW50Lg0KVGhpcyBjYW4gbWFrZSBiZXR0ZXIgdXNlIG9mIERFQ0FE RSByZXNvdXJjZXMuIDwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTI+QlI8L2ZvbnQ+DQo8 YnI+PGZvbnQgc2l6ZT0yPkxpY2h1bjwvZm9udD4NCjxicj4NCjxicj48dHQ+PGZvbnQgc2l6ZT0y PrXLwenA8i9kZW5nbGluZ2xpICZsdDtkZW5nbGluZ2xpQGNoaW5hbW9iaWxlLmNvbSZndDsNCtC0 09ogMjAxMS0wMy0yMiAxMDo1ODoyNTo8YnI+DQo8YnI+DQomZ3Q7IEhpIExpY2h1biw8L2ZvbnQ+ PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgJm5ic3A7PC9mb250PjwvdHQ+DQo8YnI+ PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IEZvciB0aGUgY2xvc2UgaW50ZWdyYXRpb24gbW9kZSB5b3Ug bWVudGlvbmVkLA0KSSB3b25kZXIgaWYgUFBTUCA8YnI+DQomZ3Q7IHRyYWNrZXIgd291bGQgYmUg Ym90aGVyZWQgYnkgdGhlIHVubmVjZXNzYXJ5IHNpZ25hbGluZyBidXJkZW4gZm9yDQo8YnI+DQom Z3Q7IHRoZSByZXBlYXRlZCBERUNBREUgc3RhdHVzIHVwZGF0ZXMgZm9yIGEgc2luZ2xlIERFQ0FE RSBzZXJ2ZXIgZm9yDQo8YnI+DQomZ3Q7IGZyb20gdGhlIHBlZXIgZ3JvdXAgc2hhcmUgaXRzIHJl c291cmNlLjwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyBXaGF0IGRvIHlv dSB0aGluaz88L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgJm5ic3A7PC9m b250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IExpbmdsaSBEZW5nPC9mb250Pjwv dHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7ICZuYnNwOzwvZm9udD48L3R0Pg0KPGJyPjx0 dD48Zm9udCBzaXplPTI+Jmd0OyC3orz+yMs6IHBwc3AtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRv OnBwc3AtYm91bmNlc0BpZXRmLm9yZ10NCrT6se0gwNa52jxicj4NCiZndDsgt6LLzcqxvOQ6IDIw MTHE6jPUwjE2yNUgMTc6NDY8YnI+DQomZ3Q7IMrVvP7IyzogbGkubGljaHVuMTxicj4NCiZndDsg s63LzTogcHBzcDxicj4NCiZndDsg1vfM4jogUmU6IFtwcHNwXSBTdXBwb3J0aW5nIERFQ0FERSBp biBQUFNQPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7ICZuYnNwOzwvZm9u dD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyBIaSBZdW5mZWkgYW5kIExpY2h1bjwv Zm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyAmbmJzcDs8L2ZvbnQ+PC90dD4N Cjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgVGhhbmsgeW91IGZvciB5b3VyIGNvbW1lbnRzLiBJ IHdpbGwgdXBkYXRlIGRyYWZ0DQpiYXNlZCBvbiB5b3VyIDxicj4NCiZndDsgc3VnZ2VzdGlvbi4g SGVyZSBhcmUgbXkgY29uc2lkZXJhdGlvbnMgaW4gbGluZTo8L2ZvbnQ+PC90dD4NCjxicj48dHQ+ PGZvbnQgc2l6ZT0yPiZndDsgJm5ic3A7PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9 Mj4mZ3Q7IDEpIFRoZSB0YXJnZXQgb2YgdGhpcyBkcmFmdDogSXMgaXQgYmV0dGVyIHRvDQpkaXNj dXNzIHRoZSBpbnRlci08YnI+DQomZ3Q7IG9wZWFyYWJpbGl0eSBiZXR3ZWVuIFBQU1AgYW5kIERF Q0FERTtvciBkaXNjdXNzIHRoZSB1c2FnZSBvZiBERUNBREUNCjxicj4NCiZndDsgaW4gUFBTUD8g SSBtZWFuIHRoZSBmb2N1cyBtYXkgYmUgYSBsaXR0bGUgYml0IGRpZmZlcmVudDogSW4gdGhlIDxi cj4NCiZndDsgZm9ybWVyIGNhc2UsIHRoZSBmb2N1cyBpcyBob3cgdGhlIHByb3RvY29scyBpbnRl ci1hY3QgaW4gdGhlIG1lc2FnZQ0KPGJyPg0KJmd0OyBvcHRpb25zIGV4Y2hhbmdlOyBpbiB0aGUg bGF0dGVyIGNhc2UsIHRoZSBmb2N1cyBpcyBob3cgdGhlIFBQU1AgPGJyPg0KJmd0OyBhcHBsaWNh dGlvbnMgdXNlIERFQ0FERSB0byBlbmhhbmNlIHRoZSBwZXJmb3JtYW5jZS4gSSBwcmVmZXIgdG8g PGJyPg0KJmd0OyB0YWtpbmcgaXQgYXMgdGhlIHVzYWdlLjwvZm9udD48L3R0Pg0KPGJyPjx0dD48 Zm9udCBzaXplPTI+Jmd0OyBJIGFncmVlIHlvdXIgb3Bpbmlvbi4gV2hhdCdzIG1vcmUsIGNvbnRl bnQgYWJvdXQNClBQU1AgYW5kIERFQ0FERSA8YnI+DQomZ3Q7IGludGVyb3BlcmF0aW9uIGFpbXMg dG8gcHJvdmlkZSBzY2VuYXJpb3MgZm9yIHVzYWdlLiBBbHNvLCB3ZSBjYW4gPGJyPg0KJmd0OyBs aXN0IHNvbWUgZXh0ZW5zaW9uIHN1Z2dlc3Rpb25zIHRvIGJvdGggcHJvdG9jb2wuIFBlaGFycHMg SSBjYW4gYWRkDQo8YnI+DQomZ3Q7IGEgbmV3IGNoYXB0ZXIgdG8gdGhvc2Ugc3VnZ2VzdGlvbi48 L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgJm5ic3A7PC9mb250PjwvdHQ+ DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IDIpIFNob3VsZCB3ZSBtYWtlIERFQ0FERSBzZXJ2 ZXIgc2VsZWN0aW9uIHdpdGgNCnByaW9yaXR5IGFsbCB0aGUgPGJyPg0KJmd0OyB0aW1lPyBJbiB0 aGUgbW9iaWxlIHNlbmFyaW8sIHN1Y2ggc2VsZWN0aW9uIGlzIHJlYXNvbmFibGU7IGluIHdpcmVk DQo8YnI+DQomZ3Q7IHNlbmFyaW8sIGl0IHNlZW1zIGJldHRlciB0byBzZWxlY3QgZ29vZCBlbm91 Z2ggcGVlcnMgd2l0aGluIG15IExBTg0KPGJyPg0KJmd0OyB0aGFuIHNlbGVjdCBERUNBREUgc2Vy dmVycyB3aGljaCBpcyBtb3JlIGZhciBmcm9tIG1lLiBUaGlzIHdpbGwgPGJyPg0KJmd0OyByZWR1 Y2UgdGhlIHVubmVjZXNzYXJ5IHRyYWZmaWMgYW5kIHByb3ZpZGUgYmV0dGVyIHBlcmZvcm1hbmNl LjwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyBJIGFncmVlLiBXZSBzaG91 bGQgZGVzaWduIGJhc2VkIG9uIGRpZmZlcmVudA0Kc2NlbmFyaW9zLiBPbmUgbW9yZSA8YnI+DQom Z3Q7IHF1ZXN0aW9uLCBzaG91bGQgcGVlciB1cGxvYWQgY29udGVudCB0byBERUNBREUgc2VydmVy IGF1dG9tYXRpY2FsbHkNCjxicj4NCiZndDsgd2hlbiBnZXQgZGF0YSBmcm9tIG90aGVyIHBlZXJz PyBQZXJoYXBzIGluIHB1c2gtYmFzZWQgbW9kZWwsIGl0IG1heQ0KPGJyPg0KJmd0OyBiZSByZWFz b25hYmxlOyBpbiBwdWxsLWJhc2VkIG1vZGVsLCBwZWVyIGNhbiB3YWl0IGZvciBvdGhlciBwZWVy cycNCjxicj4NCiZndDsgcmVxdWVzdCBhbmQgdGhlbiB0YWtlIGFjdGlvbiB0byByZXF1ZXN0cy48 L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgJm5ic3A7PC9mb250PjwvdHQ+ DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IDxicj4NCiZndDsgR3VhbiBMZTwvZm9udD48L3R0 Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyBTY2hvb2wgb2YgQ29tcHV0ZXIgU2NpZW5jZTwv Zm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyBCZWlqaW5nIFVuaXZlcnNpdHkg b2YgUG9zdHMgYW5kIFRlbGVjb21tdW5pY2F0aW9uczwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9u dCBzaXplPTI+Jmd0OyAmbmJzcDsyMDExLTAzLTE2PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250 IHNpemU9Mj4mZ3Q7IDxicj4NCiZndDsgRnJvbTogJm5ic3A7bGkubGljaHVuMSA8L2ZvbnQ+PC90 dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgRGF0ZTogJm5ic3A7MjAxMS0wMy0xNCAmbmJz cDsxMzo0MDowOSA8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgVG86ICZu YnNwO3poYW5neXVuZmVpIDwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyBD YzogJm5ic3A7cHBzcEBpZXRmLm9yZyA8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0y PiZndDsgU3ViamVjdDogJm5ic3A7UmU6IFtwcHNwXSBTdXBwb3J0aW5nIERFQ0FERSBpbg0KUFBT UCA8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgJm5ic3A7IDwvZm9udD48 L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyA8YnI+DQomZ3Q7IEhpIHl1bmZlaSwgPGJy Pg0KJmd0OyBUaGFua3MgZm9yIHlvdXIgY29tbWVudHMuIDxicj4NCiZndDsgMSkgVGhlIGZvY3Vz IGlzIHRoZSB1c2FnZSBvZiBERUNBREUgaW4gUFBTUC4gVGhlIHVzYWdlIGFsc28gbmVlZHMNCjxi cj4NCiZndDsgc29tZSBleHRlbnNpb25zIHRvIHRoZSBwcm90b2NvbHMuIDxicj4NCiZndDsgMikg WW91IGFyZSByaWdodC4gVGhlIHByaW9yaXR5IG9mIERFQ0FERSBkZXBlbmRzIG9uIHNjZW5hcmlv IGFuZCA8YnI+DQomZ3Q7IHBlZXIvREVDQURFIHNlbGVjdGlvbiBhbGdvcml0aG0uIFNvbWV0aW1l cywgZG93bmxvYWRpbmcgZnJvbSBwZWVyDQppczxicj4NCiZndDsgYmV0dGVyLiBBbHNvLCBzb21l IHNjZW5hcmlvcyBtYXkgdXNlIERFQ0FERSBhcyBiYWNrdXAgb25seSBhbmQgZ2l2ZQ0KPGJyPg0K Jmd0OyBsb3cgcHJpb3JpdHkgdG8gREVDQURFLiA8YnI+DQomZ3Q7IDxicj4NCiZndDsgQlIgPGJy Pg0KJmd0OyBMaWNodW4gPGJyPg0KJmd0OyA8YnI+DQo8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZv bnQgc2l6ZT0yPiZndDsgPGJyPg0KJmd0OyAmcXVvdDt6aGFuZ3l1bmZlaSZxdW90OyAmbHQ7emhh bmd5dW5mZWlAY2hpbmFtb2JpbGUuY29tJmd0OyA8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQg c2l6ZT0yPiZndDsgMjAxMS0wMy0xNCAxMDozMSA8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQg c2l6ZT0yPiZndDsgPGJyPg0KJmd0OyDK1bz+yMs8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQg c2l6ZT0yPiZndDsgPGJyPg0KJmd0OyAmcXVvdDtsaS5saWNodW4xQHp0ZS5jb20uY24mcXVvdDsg Jmx0O2xpLmxpY2h1bjFAenRlLmNvbS5jbiZndDssICZxdW90O3Bwc3BAaWV0Zi5vcmcmcXVvdDsN CiZsdDs8YnI+DQomZ3Q7IHBwc3BAaWV0Zi5vcmcmZ3Q7IDwvZm9udD48L3R0Pg0KPGJyPjx0dD48 Zm9udCBzaXplPTI+Jmd0OyA8YnI+DQomZ3Q7ILOty808L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZv bnQgc2l6ZT0yPiZndDsgPGJyPg0KJmd0OyDW98ziPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250 IHNpemU9Mj4mZ3Q7IDxicj4NCiZndDsgUmU6IFtwcHNwXSBTdXBwb3J0aW5nIERFQ0FERSBpbiBQ UFNQPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IDxicj4NCiZndDsgJm5i c3A7PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IDxicj4NCiZndDsgPGJy Pg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgSGkgTGljaHVuLCA8YnI+DQomZ3Q7ICZuYnNw OyAmbmJzcDsgVGhpcyBpcyBhbiBpbnRlcnN0aW5nIHRvcGljIEkgdGhvdWdodCBhbmQgZGlzY3Vz c2VkDQpkdXJpbmcgdGhlIDxicj4NCiZndDsgc2V0IHVwIG9mIFBQU1AgYW5kIERFQ0FERS4gVGhh bmtzIGZvciBtYWtpbmcgaXQgbW9yZSBjbGVhcjopLlNvbWUNCjxicj4NCiZndDsgc3VnZ2VzdGlv bnMgYXJlIGFzIGZvbGxvd3M6IDxicj4NCiZndDsgMSkgVGhlIHRhcmdldCBvZiB0aGlzIGRyYWZ0 OiBJcyBpdCBiZXR0ZXIgdG8gZGlzY3VzcyB0aGUgaW50ZXItPGJyPg0KJmd0OyBvcGVhcmFiaWxp dHkgYmV0d2VlbiBQUFNQIGFuZCBERUNBREU7b3IgZGlzY3VzcyB0aGUgdXNhZ2Ugb2YgREVDQURF DQo8YnI+DQomZ3Q7IGluIFBQU1A/IEkgbWVhbiB0aGUgZm9jdXMgbWF5IGJlIGEgbGl0dGxlIGJp dCBkaWZmZXJlbnQ6IEluIHRoZSA8YnI+DQomZ3Q7IGZvcm1lciBjYXNlLCB0aGUgZm9jdXMgaXMg aG93IHRoZSBwcm90b2NvbHMgaW50ZXItYWN0IGluIHRoZSBtZXNhZ2UNCjxicj4NCiZndDsgb3B0 aW9ucyBleGNoYW5nZTsgaW4gdGhlIGxhdHRlciBjYXNlLCB0aGUgZm9jdXMgaXMgaG93IHRoZSBQ UFNQIDxicj4NCiZndDsgYXBwbGljYXRpb25zIHVzZSBERUNBREUgdG8gZW5oYW5jZSB0aGUgcGVy Zm9ybWFuY2UuIEkgcHJlZmVyIHRvIDxicj4NCiZndDsgdGFraW5nIGl0IGFzIHRoZSB1c2FnZS4g PGJyPg0KJmd0OyAyKSBTaG91bGQgd2UgbWFrZSBERUNBREUgc2VydmVyIHNlbGVjdGlvbiB3aXRo IHByaW9yaXR5IGFsbCB0aGUgPGJyPg0KJmd0OyB0aW1lPyBJbiB0aGUgbW9iaWxlIHNlbmFyaW8s IHN1Y2ggc2VsZWN0aW9uIGlzIHJlYXNvbmFibGU7IGluIHdpcmVkDQo8YnI+DQomZ3Q7IHNlbmFy aW8sIGl0IHNlZW1zIGJldHRlciB0byBzZWxlY3QgZ29vZCBlbm91Z2ggcGVlcnMgd2l0aGluIG15 IExBTg0KPGJyPg0KJmd0OyB0aGFuIHNlbGVjdCBERUNBREUgc2VydmVycyB3aGljaCBpcyBtb3Jl IGZhciBmcm9tIG1lLiBUaGlzIHdpbGwgPGJyPg0KJmd0OyByZWR1Y2UgdGhlIHVubmVjZXNzYXJ5 IHRyYWZmaWMgYW5kIHByb3ZpZGUgYmV0dGVyIHBlcmZvcm1hbmNlLiA8YnI+DQomZ3Q7ICZuYnNw OyA8YnI+DQomZ3Q7IEJSIDxicj4NCiZndDsgWXVuZmVpIDxicj4NCiZndDsgJm5ic3A7IDwvZm9u dD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsg emhhbmd5dW5mZWkgPGJyPg0KJmd0OyAyMDExLTAzLTE0IDwvZm9udD48L3R0Pg0KPGJyPjx0dD48 Zm9udCBzaXplPTI+Jmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgt6K8/sjLo7ogbGkubGljaHVu MUB6dGUuY29tLmNuIDxicj4NCiZndDsgt6LLzcqxvOSjuiAyMDExLTAzLTA4IDE3OjQ3OjExIDxi cj4NCiZndDsgytW8/sjLo7ogcHBzcEBpZXRmLm9yZyA8YnI+DQomZ3Q7ILOty82juiA8YnI+DQom Z3Q7INb3zOKjuiBbcHBzcF0gU3VwcG9ydGluZyBERUNBREUgaW4gUFBTUCA8YnI+DQomZ3Q7ICZu YnNwOyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgSGksIGFsbCA8YnI+DQomZ3Q7IDxicj4NCiZndDsg V2Ugc3VibWl0dGVkIGEgbmV3IGRyYWZ0IGFib3V0IHN1cHBvcnRpbmcgREVDQURFIGluIFBQU1Au IEl0IGNhbiBiZQ0KPGJyPg0KJmd0OyBhY2Nlc3NlZCBhdCBodHRwOi8vd3d3LmlldGYub3JnL2lk L2RyYWZ0LWxlLXBwc3AtZGVjYWRlLWludGVyb3BlcmF0aW9uLTAwLnR4dDxicj4NCiZndDsgQ29t bWVudHMgYXJlIHdlbGNvbWUuIDxicj4NCiZndDsgPGJyPg0KJmd0OyBCUiA8YnI+DQomZ3Q7IExp Y2h1biA8YnI+DQomZ3Q7IDxicj4NCiZndDsgQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWxl LXBwc3AtZGVjYWRlLWludGVyb3BlcmF0aW9uLTAwLnR4dCBoYXM8YnI+DQomZ3Q7IGJlZW4gc3Vj Y2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBHdWFuIExlIGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVw b3NpdG9yeS48YnI+DQomZ3Q7IDxicj4NCiZndDsgRmlsZW5hbWU6ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwO2RyYWZ0LWxlLXBw c3AtZGVjYWRlLWludGVyb3BlcmF0aW9uPGJyPg0KJmd0OyBSZXZpc2lvbjogJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7MDA8YnI+ DQomZ3Q7IFRpdGxlOiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyBQUFNQIFVzYWdlIGZvcg0KREVDQURFPGJyPg0KJmd0OyBDcmVh dGlvbl9kYXRlOiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7DQombmJzcDsyMDExLTAzLTA3PGJyPg0KJmd0OyBXRyBJRDogJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgSW5kZXBl bmRlbnQgU3VibWlzc2lvbjxicj4NCiZndDsgTnVtYmVyX29mX3BhZ2VzOiAxNDxicj4NCiZndDsg PGJyPg0KJmd0OyBBYnN0cmFjdDo8YnI+DQomZ3Q7IFAyUCBTdHJlYW1pbmcgaGFzIGJlY29tZSBw b3B1bGFyIGFwcGxpY2F0aW9uIGluIHRoZSBJbnRlcm5ldC48YnI+DQomZ3Q7IEN1cnJlbnRseSwg bW9zdCBob21lIHN1YnNjcmliZXJzIGFjY2VzcyBJbnRlcm5ldCB2aWEgQURTTCwgaW4gd2hpY2g8 YnI+DQomZ3Q7IGRvd25saW5rIGJhbmR3aWR0aCBhbmQgdXBsaW5rIGJhbmR3aWR0aCBhcmUgbm90 IHN5bW1ldHJpYy4gJm5ic3A7VGhpczxicj4NCiZndDsgZmVhdHVyZSB3b3VsZCBpbmZsdWVuY2Ug dGhlIHBlcmZvcm1hbmNlIG9mIFAyUCBTdHJlYW1pbmcsIGFuZCB0aGU8YnI+DQomZ3Q7IHByb2Js ZW0gbWF5IGJlIHdvcnNlIGluIG1vYmlsZSBzY2VuYXJpb3MuICZuYnNwO1RoaXMgZHJhZnQgcHJl c2VudHMNCnRoZTxicj4NCiZndDsgaW50ZXJvcGVyYXRpb24gYmV0d2VlbiBQUFNQIHByb3RvY29s IGFuZCBERUNBREUgcHJvdG9jb2wgdG8gcHJvdmlkZTxicj4NCiZndDsgREVDQURFIHNlcnZpY2Ug Zm9yIFBQU1AgYXBwbGljYXRpb25zLiAmbmJzcDtUeXBpY2FsbHksIHRoZXJlIGFyZSB0d288YnI+ DQomZ3Q7IHNvbHV0aW9uIHRvIGFjaGlldmUgaW50ZXJvcGVyYXRpb24sIGxvb3NlIGludGVyb3Bl cmF0aW9uIGFtb25nIHBlZXJzLDxicj4NCiZndDsgYW5kIGNsb3NlIGludGVyb3BlcmF0aW9uIHZp YSBjb25uZWN0aW9uIG9mIHBlZXIgYW5kIHRyYWNrZXIuICZuYnNwO0J5PGJyPg0KJmd0OyBpbnRy b2R1Y2luZyBERUNBREUgaW4gYm90aCB0cmFja2VyIHByb3RvY29sIGFuZCBwZWVyIHByb3RvY29s LCBQUFNQPGJyPg0KJmd0OyBzdHJlYW1pbmcgY2FuIGFsbGV2aWF0ZSBzdHJlbmd0aCBvZiB1cGxv YWQgYmFuZHdpZHRoIGFuZCBpbXByb3ZlPGJyPg0KJmd0OyBwZXJmb3JtYW5jZSBmb3IgZml4IGFu ZCBtb2JpbGUgc2NlbmFyaW8uPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOzxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFRoZSBJ RVRGIFNlY3JldGFyaWF0Ljxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZn dDsgPGJyPg0KJmd0OyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLTxicj4NCiZndDsgWlRFIEluZm9ybWF0aW9uIFNlY3VyaXR5IE5vdGljZTog VGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzDQo8YnI+DQomZ3Q7IG1haWwgaXMgc29s ZWx5IHByb3BlcnR5IG9mIHRoZSBzZW5kZXIncyBvcmdhbml6YXRpb24uIFRoaXMgbWFpbCA8YnI+ DQomZ3Q7IGNvbW11bmljYXRpb24gaXMgY29uZmlkZW50aWFsLiBSZWNpcGllbnRzIG5hbWVkIGFi b3ZlIGFyZSBvYmxpZ2F0ZWQNCjxicj4NCiZndDsgdG8gbWFpbnRhaW4gc2VjcmVjeSBhbmQgYXJl IG5vdCBwZXJtaXR0ZWQgdG8gZGlzY2xvc2UgdGhlIGNvbnRlbnRzDQo8YnI+DQomZ3Q7IG9mIHRo aXMgY29tbXVuaWNhdGlvbiB0byBvdGhlcnMuPGJyPg0KJmd0OyBUaGlzIGVtYWlsIGFuZCBhbnkg ZmlsZXMgdHJhbnNtaXR0ZWQgd2l0aCBpdCBhcmUgY29uZmlkZW50aWFsIGFuZA0KPGJyPg0KJmd0 OyBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwgb3IgZW50aXR5 IHRvIHdob20gdGhleTxicj4NCiZndDsgYXJlIGFkZHJlc3NlZC4gSWYgeW91IGhhdmUgcmVjZWl2 ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciBwbGVhc2UgPGJyPg0KJmd0OyBub3RpZnkgdGhlIG9yaWdp bmF0b3Igb2YgdGhlIG1lc3NhZ2UuIEFueSB2aWV3cyBleHByZXNzZWQgaW4gdGhpcw0KPGJyPg0K Jmd0OyBtZXNzYWdlIGFyZSB0aG9zZSBvZiB0aGUgaW5kaXZpZHVhbCBzZW5kZXIuPGJyPg0KJmd0 OyBUaGlzIG1lc3NhZ2UgaGFzIGJlZW4gc2Nhbm5lZCBmb3IgdmlydXNlcyBhbmQgU3BhbSBieSBa VEUgQW50aS1TcGFtDQpzeXN0ZW0uPGJyPg0KPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNp emU9Mj4mZ3Q7IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IFpURSBJbmZv cm1hdGlvbiBTZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZvcm1hdGlvbg0KY29udGFpbmVkIGluIHRo aXMgPGJyPg0KJmd0OyBtYWlsIGlzIHNvbGVseSBwcm9wZXJ0eSBvZiB0aGUgc2VuZGVyJ3Mgb3Jn YW5pemF0aW9uLiBUaGlzIG1haWwgPGJyPg0KJmd0OyBjb21tdW5pY2F0aW9uIGlzIGNvbmZpZGVu dGlhbC4gUmVjaXBpZW50cyBuYW1lZCBhYm92ZSBhcmUgb2JsaWdhdGVkDQo8YnI+DQomZ3Q7IHRv IG1haW50YWluIHNlY3JlY3kgYW5kIGFyZSBub3QgcGVybWl0dGVkIHRvIGRpc2Nsb3NlIHRoZSBj b250ZW50cw0KPGJyPg0KJmd0OyBvZiB0aGlzIGNvbW11bmljYXRpb24gdG8gb3RoZXJzLjwvZm9u dD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyBUaGlzIGVtYWlsIGFuZCBhbnkgZmls ZXMgdHJhbnNtaXR0ZWQgd2l0aCBpdA0KYXJlIGNvbmZpZGVudGlhbCBhbmQgPGJyPg0KJmd0OyBp bnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwgb3IgZW50aXR5IHRv IHdob20gdGhleTxicj4NCiZndDsgYXJlIGFkZHJlc3NlZC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQg dGhpcyBlbWFpbCBpbiBlcnJvciBwbGVhc2UgPGJyPg0KJmd0OyBub3RpZnkgdGhlIG9yaWdpbmF0 b3Igb2YgdGhlIG1lc3NhZ2UuIEFueSB2aWV3cyBleHByZXNzZWQgaW4gdGhpcw0KPGJyPg0KJmd0 OyBtZXNzYWdlIGFyZSB0aG9zZSBvZiB0aGUgaW5kaXZpZHVhbCBzZW5kZXIuPC9mb250PjwvdHQ+ DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IFRoaXMgbWVzc2FnZSBoYXMgYmVlbiBzY2FubmVk IGZvciB2aXJ1c2VzIGFuZA0KU3BhbSBieSBaVEUgQW50aS1TcGFtIHN5c3RlbS48L2ZvbnQ+PC90 dD4NCjxicj48cHJlPg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0NClpURSZuYnNwO0luZm9ybWF0aW9uJm5ic3A7U2VjdXJpdHkmbmJzcDtO b3RpY2U6Jm5ic3A7VGhlJm5ic3A7aW5mb3JtYXRpb24mbmJzcDtjb250YWluZWQmbmJzcDtpbiZu YnNwO3RoaXMmbmJzcDttYWlsJm5ic3A7aXMmbmJzcDtzb2xlbHkmbmJzcDtwcm9wZXJ0eSZuYnNw O29mJm5ic3A7dGhlJm5ic3A7c2VuZGVyJ3MmbmJzcDtvcmdhbml6YXRpb24uJm5ic3A7VGhpcyZu YnNwO21haWwmbmJzcDtjb21tdW5pY2F0aW9uJm5ic3A7aXMmbmJzcDtjb25maWRlbnRpYWwuJm5i c3A7UmVjaXBpZW50cyZuYnNwO25hbWVkJm5ic3A7YWJvdmUmbmJzcDthcmUmbmJzcDtvYmxpZ2F0 ZWQmbmJzcDt0byZuYnNwO21haW50YWluJm5ic3A7c2VjcmVjeSZuYnNwO2FuZCZuYnNwO2FyZSZu YnNwO25vdCZuYnNwO3Blcm1pdHRlZCZuYnNwO3RvJm5ic3A7ZGlzY2xvc2UmbmJzcDt0aGUmbmJz cDtjb250ZW50cyZuYnNwO29mJm5ic3A7dGhpcyZuYnNwO2NvbW11bmljYXRpb24mbmJzcDt0byZu YnNwO290aGVycy4NClRoaXMmbmJzcDtlbWFpbCZuYnNwO2FuZCZuYnNwO2FueSZuYnNwO2ZpbGVz Jm5ic3A7dHJhbnNtaXR0ZWQmbmJzcDt3aXRoJm5ic3A7aXQmbmJzcDthcmUmbmJzcDtjb25maWRl bnRpYWwmbmJzcDthbmQmbmJzcDtpbnRlbmRlZCZuYnNwO3NvbGVseSZuYnNwO2ZvciZuYnNwO3Ro ZSZuYnNwO3VzZSZuYnNwO29mJm5ic3A7dGhlJm5ic3A7aW5kaXZpZHVhbCZuYnNwO29yJm5ic3A7 ZW50aXR5Jm5ic3A7dG8mbmJzcDt3aG9tJm5ic3A7dGhleSZuYnNwO2FyZSZuYnNwO2FkZHJlc3Nl ZC4mbmJzcDtJZiZuYnNwO3lvdSZuYnNwO2hhdmUmbmJzcDtyZWNlaXZlZCZuYnNwO3RoaXMmbmJz cDtlbWFpbCZuYnNwO2luJm5ic3A7ZXJyb3ImbmJzcDtwbGVhc2UmbmJzcDtub3RpZnkmbmJzcDt0 aGUmbmJzcDtvcmlnaW5hdG9yJm5ic3A7b2YmbmJzcDt0aGUmbmJzcDttZXNzYWdlLiZuYnNwO0Fu eSZuYnNwO3ZpZXdzJm5ic3A7ZXhwcmVzc2VkJm5ic3A7aW4mbmJzcDt0aGlzJm5ic3A7bWVzc2Fn ZSZuYnNwO2FyZSZuYnNwO3Rob3NlJm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtpbmRpdmlkdWFsJm5i c3A7c2VuZGVyLg0KVGhpcyZuYnNwO21lc3NhZ2UmbmJzcDtoYXMmbmJzcDtiZWVuJm5ic3A7c2Nh bm5lZCZuYnNwO2ZvciZuYnNwO3ZpcnVzZXMmbmJzcDthbmQmbmJzcDtTcGFtJm5ic3A7YnkmbmJz cDtaVEUmbmJzcDtBbnRpLVNwYW0mbmJzcDtzeXN0ZW0uDQo8L3ByZT4= --=_alternative 000FA6E44825785C_=-- From li.lichun1@zte.com.cn Wed Mar 23 18:30:28 2011 Return-Path: X-Original-To: decade@core3.amsl.com Delivered-To: decade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 359353A6767 for ; Wed, 23 Mar 2011 18:30:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.736 X-Spam-Level: X-Spam-Status: No, score=-99.736 tagged_above=-999 required=5 tests=[AWL=-2.102, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I2-Ux6hsOxJ4 for ; Wed, 23 Mar 2011 18:30:27 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by core3.amsl.com (Postfix) with ESMTP id 9D4EE3A659A for ; Wed, 23 Mar 2011 18:30:25 -0700 (PDT) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 50831047745636; Thu, 24 Mar 2011 09:29:59 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.15] with StormMail ESMTP id 84746.2200778454; Thu, 24 Mar 2011 09:31:56 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id p2O1Vpq3090934; Thu, 24 Mar 2011 09:31:51 +0800 (GMT-8) (envelope-from li.lichun1@zte.com.cn) In-Reply-To: To: Songhaibin MIME-Version: 1.0 X-KeepSent: FCC8D62E:736F1B70-4825785D:000746E4; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: li.lichun1@zte.com.cn Date: Thu, 24 Mar 2011 09:31:41 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-03-24 09:31:51, Serialize complete at 2011-03-24 09:31:51 Content-Type: multipart/alternative; boundary="=_alternative 00087F0D4825785D_=" X-MAIL: mse01.zte.com.cn p2O1Vpq3090934 Cc: "decade@ietf.org" Subject: [decade] agenda change: "PPSP and DECADE Interoperation" will be presented in PPSP WG only X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.9 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, 24 Mar 2011 01:30:28 -0000 This is a multipart message in MIME format. --=_alternative 00087F0D4825785D_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGkgYWxsLA0KDQpJJ2QgcmVhbGx5IGxpa2UgdG8gZGlzY3VzcyB0aGUgIlBQU1AgYW5kIERFQ0FE RSBJbnRlcm9wZXJhdGlvbiIgdG9waWMgaW4gDQpERUNBREUgV0cgYW5kIFBQU1AgV0cuIEkgcGxh bm5lZCB0byBnaXZlIHRoZSBwcmVzZW50YXRpb24gaW4gYm90aCBXR3MuDQpCdXQsIHRvIHNhdmUg dGltZSBmb3IgdGhlIHJlY2hhcnRlcmluZyBkaXNjdXNzaW9uLCBJIHdpbGwgb25seSBnaXZlIHRo ZSANCnByZXNlbnRhdGlvbiBpbiBQUFNQIFdHLiANClBlb3BsZSBpbnRlcmVzdGVkIGluICJERUNB REUgdXNhZ2UgaW4gUFBTUCIsIHBsZWFzZSBhdHRlbmQgdGhlIFBQU1AgDQpzZXNzaW9uIG9uIE1v bmRheSBtb3JuaW5nLiANClRoYW5rIHlvdSENCg0KQlINCkxpY2h1bg0KDQoNCg0KZGVjYWRlLWJv dW5jZXNAaWV0Zi5vcmcg0LTT2iAyMDExLTAzLTE4IDA5OjM3OjI0Og0KDQo+IERlYXIgYWxsLA0K PiANCj4gSGVyZSBpcyBhIGRyYWZ0IGFnZW5kYSBmb3IgSUVURiA4MC4gSWYgeW91IGhhdmUgYW55 IGNvbmNlcm4sIHBsZWFzZSANCj4gc2VuZCBlbWFpbCB0byBSaWNoIGFuZCBtZS4gUGxlYXNlIG5v dGljZSB0aGF0IG91ciBtZWV0aW5nIHdpbGwgYmUgDQo+IGhlbGQgb24gTW9uZGF5IGFmdGVybm9v biwgd2hpY2ggbWVhbnMgeW91IHNob3VsZCBzdGFydCBwcmVwYXJpbmcgDQo+IHlvdXIgc2xpZGVz IGVhcmx5Lg0KPiANCj4gTW9uZGF5LCBNYXJjaCAyOCwgMjAxMSwgMTMwMC0xNTAwLCBHcmFuZCBC YWxscm9vbQ0KPiANCj4gQWdlbmRhOg0KPiBBZ2VuZGEgQmFzaCwgQ2hhaXJzLCA1IG1pbnV0ZXMs IDEzMDAtMTMwNSANCj4gUHJvYmxlbSBTdGF0ZW1lbnQsIEhhaWJpbiBTb25nLCBkcmFmdC1pZXRm LWRlY2FkZS1wcm9ibGVtLQ0KPiBzdGF0ZW1lbnQtMDMsIDUgbWludXRlcywgMTMwNS0xMzEwIA0K PiBTdXJ2ZXksIEFrYmFyIFJhaG1hbiwgZHJhZnQtaWV0Zi1kZWNhZGUtc3VydmV5LTA0LCA1IG1p bnV0ZXMsIDEzMTAtMTMxNSANCj4gREVDQURFIEFyY2hpdGVjdHVyZSwgUmljaGFyZCBBbGltaSwg ZHJhZnQtaWV0Zi1kZWNhZGUtYXJjaC0wMCwgMjAgDQo+IG1pbnV0ZXMsIDEzMTUtMTMzNSANCj4g UmVxdWlyZW1lbnRzLCBUQkQsIGRyYWZ0LWlldGYtZGVjYWRlLXJlcXMtMDEsIDIwIG1pbnV0ZXMs IDEzMzUtMTM1NSANCj4gSW50ZWdyYXRpb24gZXhhbXBsZXMsIFRCRCwgZHJhZnQtY2hlbi1kZWNh ZGUtaW50Z3ItbGl2ZXN0ci1leG1wLTAxLCANCj4gMTUgbWludXRlcywgMTM1NS0xNDEwIA0KPiBQ UFNQIGFuZCBERUNBREUgSW50ZXJvcGVyYXRpb24sIExpY2h1biBMaSwgZHJhZnQtbGUtcHBzcC1k ZWNhZGUtDQo+IGludGVyb3BlcmF0aW9uLTAwLCAxMCBtaW51dGVzIDE0MTAtMTQyMCANCj4gU2Vj dXJlIE5hbWluZywgQm9yamUgT2hsbWFuLCBkcmFmdC1kYW5uZXdpdHotcHBzcC1zZWN1cmUtbmFt aW5nLTAyLCANCj4gMTAgbWludXRlcyAxNDIwLTE0MzAgDQo+IFJlY2hhcnRlcmluZyBEaXNjdXNz aW9uLCBDaGFpcnMsIDIwIG1pbnV0ZXMsIDE0MzAtMTQ1MCANCj4gQ29uY2x1c2lvbiBhbmQgbmV4 dCBzdGVwcywgQ2hhaXJzLCAxMCBtaW51dGVzLCAxNDUwLTE1MDANCj4gDQo+IFlvdSBjYW4gYWxz byBmaW5kIG91ciBhZ2VuZGEgd2l0aCB0aGUgbGluayBiZWxvdy4NCj4gaHR0cDovL3d3dy5pZXRm Lm9yZy9wcm9jZWVkaW5ncy84MC9hZ2VuZGEvZGVjYWRlLmh0bWwNCj4gDQo+IFRoYW5rcywNCj4g SGFpYmluIGFuZCBSaWNoIChDaGFpcnMpDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQo+IGRlY2FkZSBtYWlsaW5nIGxpc3QNCj4gZGVjYWRlQGlldGYu b3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGVjYWRlDQo+IA0K DQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0NClpURSBJbmZvcm1hdGlvbiBTZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZvcm1hdGlvbiBj b250YWluZWQgaW4gdGhpcyBtYWlsIGlzIHNvbGVseSBwcm9wZXJ0eSBvZiB0aGUgc2VuZGVyJ3Mg b3JnYW5pemF0aW9uLiBUaGlzIG1haWwgY29tbXVuaWNhdGlvbiBpcyBjb25maWRlbnRpYWwuIFJl Y2lwaWVudHMgbmFtZWQgYWJvdmUgYXJlIG9ibGlnYXRlZCB0byBtYWludGFpbiBzZWNyZWN5IGFu ZCBhcmUgbm90IHBlcm1pdHRlZCB0byBkaXNjbG9zZSB0aGUgY29udGVudHMgb2YgdGhpcyBjb21t dW5pY2F0aW9uIHRvIG90aGVycy4NClRoaXMgZW1haWwgYW5kIGFueSBmaWxlcyB0cmFuc21pdHRl ZCB3aXRoIGl0IGFyZSBjb25maWRlbnRpYWwgYW5kIGludGVuZGVkIHNvbGVseSBmb3IgdGhlIHVz ZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgdG8gd2hvbSB0aGV5IGFyZSBhZGRyZXNzZWQu IElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IgcGxlYXNlIG5vdGlmeSB0 aGUgb3JpZ2luYXRvciBvZiB0aGUgbWVzc2FnZS4gQW55IHZpZXdzIGV4cHJlc3NlZCBpbiB0aGlz IG1lc3NhZ2UgYXJlIHRob3NlIG9mIHRoZSBpbmRpdmlkdWFsIHNlbmRlci4NClRoaXMgbWVzc2Fn ZSBoYXMgYmVlbiBzY2FubmVkIGZvciB2aXJ1c2VzIGFuZCBTcGFtIGJ5IFpURSBBbnRpLVNwYW0g c3lzdGVtLg0K --=_alternative 00087F0D4825785D_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIGFsbCw8L2ZvbnQ+DQo8YnI+ DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkknZCByZWFsbHkgbGlrZSB0byBk aXNjdXNzIHRoZSAmcXVvdDs8L2ZvbnQ+PHR0Pjxmb250IHNpemU9Mj5QUFNQDQphbmQgREVDQURF IEludGVyb3BlcmF0aW9uPC9mb250PjwvdHQ+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYi PiZxdW90Ow0KdG9waWMgaW4gREVDQURFIFdHIGFuZCBQUFNQIFdHLiBJIHBsYW5uZWQgdG8gZ2l2 ZSB0aGUgcHJlc2VudGF0aW9uIGluIGJvdGgNCldHcy48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0y IGZhY2U9InNhbnMtc2VyaWYiPkJ1dCwgdG8gc2F2ZSB0aW1lIGZvciB0aGUgcmVjaGFydGVyaW5n DQpkaXNjdXNzaW9uLCBJIHdpbGwgb25seSBnaXZlIHRoZSBwcmVzZW50YXRpb24gaW4gUFBTUCBX Ry4gPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5QZW9wbGUgaW50 ZXJlc3RlZCBpbiAmcXVvdDtERUNBREUgdXNhZ2UNCmluIFBQU1AmcXVvdDssIHBsZWFzZSBhdHRl bmQgdGhlIFBQU1Agc2Vzc2lvbiBvbiBNb25kYXkgbW9ybmluZy4gPC9mb250Pg0KPGJyPjxmb250 IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5UaGFuayB5b3UhPGJyPg0KPGJyPg0KQlI8YnI+DQpM aWNodW48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjxicj4NCjxi cj4NCjwvZm9udD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPmRlY2FkZS1ib3VuY2VzQGlldGYub3Jn INC009ogMjAxMS0wMy0xOCAwOTozNzoyNDo8YnI+DQo8YnI+DQomZ3Q7IERlYXIgYWxsLDxicj4N CiZndDsgPGJyPg0KJmd0OyBIZXJlIGlzIGEgZHJhZnQgYWdlbmRhIGZvciBJRVRGIDgwLiBJZiB5 b3UgaGF2ZSBhbnkgY29uY2VybiwgcGxlYXNlDQo8YnI+DQomZ3Q7IHNlbmQgZW1haWwgdG8gUmlj aCBhbmQgbWUuIFBsZWFzZSBub3RpY2UgdGhhdCBvdXIgbWVldGluZyB3aWxsIGJlDQo8YnI+DQom Z3Q7IGhlbGQgb24gTW9uZGF5IGFmdGVybm9vbiwgd2hpY2ggbWVhbnMgeW91IHNob3VsZCBzdGFy dCBwcmVwYXJpbmcgPGJyPg0KJmd0OyB5b3VyIHNsaWRlcyBlYXJseS48YnI+DQomZ3Q7IDxicj4N CiZndDsgTW9uZGF5LCBNYXJjaCAyOCwgMjAxMSwgMTMwMC0xNTAwLCBHcmFuZCBCYWxscm9vbTxi cj4NCiZndDsgPGJyPg0KJmd0OyBBZ2VuZGE6PGJyPg0KJmd0OyBBZ2VuZGEgQmFzaCwgQ2hhaXJz LCA1IG1pbnV0ZXMsIDEzMDAtMTMwNSA8YnI+DQomZ3Q7IFByb2JsZW0gU3RhdGVtZW50LCBIYWli aW4gU29uZywgZHJhZnQtaWV0Zi1kZWNhZGUtcHJvYmxlbS08YnI+DQomZ3Q7IHN0YXRlbWVudC0w MywgNSBtaW51dGVzLCAxMzA1LTEzMTAgPGJyPg0KJmd0OyBTdXJ2ZXksIEFrYmFyIFJhaG1hbiwg ZHJhZnQtaWV0Zi1kZWNhZGUtc3VydmV5LTA0LCA1IG1pbnV0ZXMsIDEzMTAtMTMxNQ0KPGJyPg0K Jmd0OyBERUNBREUgQXJjaGl0ZWN0dXJlLCBSaWNoYXJkIEFsaW1pLCBkcmFmdC1pZXRmLWRlY2Fk ZS1hcmNoLTAwLCAyMA0KPGJyPg0KJmd0OyBtaW51dGVzLCAxMzE1LTEzMzUgPGJyPg0KJmd0OyBS ZXF1aXJlbWVudHMsIFRCRCwgZHJhZnQtaWV0Zi1kZWNhZGUtcmVxcy0wMSwgMjAgbWludXRlcywg MTMzNS0xMzU1DQo8YnI+DQomZ3Q7IEludGVncmF0aW9uIGV4YW1wbGVzLCBUQkQsIGRyYWZ0LWNo ZW4tZGVjYWRlLWludGdyLWxpdmVzdHItZXhtcC0wMSwNCjxicj4NCiZndDsgMTUgbWludXRlcywg MTM1NS0xNDEwIDxicj4NCiZndDsgUFBTUCBhbmQgREVDQURFIEludGVyb3BlcmF0aW9uLCBMaWNo dW4gTGksIGRyYWZ0LWxlLXBwc3AtZGVjYWRlLTxicj4NCiZndDsgaW50ZXJvcGVyYXRpb24tMDAs IDEwIG1pbnV0ZXMgMTQxMC0xNDIwIDxicj4NCiZndDsgU2VjdXJlIE5hbWluZywgQm9yamUgT2hs bWFuLCBkcmFmdC1kYW5uZXdpdHotcHBzcC1zZWN1cmUtbmFtaW5nLTAyLA0KPGJyPg0KJmd0OyAx MCBtaW51dGVzIDE0MjAtMTQzMCA8YnI+DQomZ3Q7IFJlY2hhcnRlcmluZyBEaXNjdXNzaW9uLCBD aGFpcnMsIDIwIG1pbnV0ZXMsIDE0MzAtMTQ1MCA8YnI+DQomZ3Q7IENvbmNsdXNpb24gYW5kIG5l eHQgc3RlcHMsIENoYWlycywgMTAgbWludXRlcywgMTQ1MC0xNTAwPGJyPg0KJmd0OyA8YnI+DQom Z3Q7IFlvdSBjYW4gYWxzbyBmaW5kIG91ciBhZ2VuZGEgd2l0aCB0aGUgbGluayBiZWxvdy48YnI+ DQomZ3Q7IGh0dHA6Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvODAvYWdlbmRhL2RlY2FkZS5o dG1sPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFRoYW5rcyw8YnI+DQomZ3Q7IEhhaWJpbiBhbmQgUmlj aCAoQ2hhaXJzKTxicj4NCiZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX188YnI+DQomZ3Q7IGRlY2FkZSBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7IGRlY2Fk ZUBpZXRmLm9yZzxicj4NCiZndDsgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9kZWNhZGU8YnI+DQomZ3Q7IDxicj4NCjwvZm9udD48L3R0Pg0KPGJyPjxwcmU+DQotLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KWlRFJm5i c3A7SW5mb3JtYXRpb24mbmJzcDtTZWN1cml0eSZuYnNwO05vdGljZTombmJzcDtUaGUmbmJzcDtp bmZvcm1hdGlvbiZuYnNwO2NvbnRhaW5lZCZuYnNwO2luJm5ic3A7dGhpcyZuYnNwO21haWwmbmJz cDtpcyZuYnNwO3NvbGVseSZuYnNwO3Byb3BlcnR5Jm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtzZW5k ZXIncyZuYnNwO29yZ2FuaXphdGlvbi4mbmJzcDtUaGlzJm5ic3A7bWFpbCZuYnNwO2NvbW11bmlj YXRpb24mbmJzcDtpcyZuYnNwO2NvbmZpZGVudGlhbC4mbmJzcDtSZWNpcGllbnRzJm5ic3A7bmFt ZWQmbmJzcDthYm92ZSZuYnNwO2FyZSZuYnNwO29ibGlnYXRlZCZuYnNwO3RvJm5ic3A7bWFpbnRh aW4mbmJzcDtzZWNyZWN5Jm5ic3A7YW5kJm5ic3A7YXJlJm5ic3A7bm90Jm5ic3A7cGVybWl0dGVk Jm5ic3A7dG8mbmJzcDtkaXNjbG9zZSZuYnNwO3RoZSZuYnNwO2NvbnRlbnRzJm5ic3A7b2YmbmJz cDt0aGlzJm5ic3A7Y29tbXVuaWNhdGlvbiZuYnNwO3RvJm5ic3A7b3RoZXJzLg0KVGhpcyZuYnNw O2VtYWlsJm5ic3A7YW5kJm5ic3A7YW55Jm5ic3A7ZmlsZXMmbmJzcDt0cmFuc21pdHRlZCZuYnNw O3dpdGgmbmJzcDtpdCZuYnNwO2FyZSZuYnNwO2NvbmZpZGVudGlhbCZuYnNwO2FuZCZuYnNwO2lu dGVuZGVkJm5ic3A7c29sZWx5Jm5ic3A7Zm9yJm5ic3A7dGhlJm5ic3A7dXNlJm5ic3A7b2YmbmJz cDt0aGUmbmJzcDtpbmRpdmlkdWFsJm5ic3A7b3ImbmJzcDtlbnRpdHkmbmJzcDt0byZuYnNwO3do b20mbmJzcDt0aGV5Jm5ic3A7YXJlJm5ic3A7YWRkcmVzc2VkLiZuYnNwO0lmJm5ic3A7eW91Jm5i c3A7aGF2ZSZuYnNwO3JlY2VpdmVkJm5ic3A7dGhpcyZuYnNwO2VtYWlsJm5ic3A7aW4mbmJzcDtl cnJvciZuYnNwO3BsZWFzZSZuYnNwO25vdGlmeSZuYnNwO3RoZSZuYnNwO29yaWdpbmF0b3ImbmJz cDtvZiZuYnNwO3RoZSZuYnNwO21lc3NhZ2UuJm5ic3A7QW55Jm5ic3A7dmlld3MmbmJzcDtleHBy ZXNzZWQmbmJzcDtpbiZuYnNwO3RoaXMmbmJzcDttZXNzYWdlJm5ic3A7YXJlJm5ic3A7dGhvc2Um bmJzcDtvZiZuYnNwO3RoZSZuYnNwO2luZGl2aWR1YWwmbmJzcDtzZW5kZXIuDQpUaGlzJm5ic3A7 bWVzc2FnZSZuYnNwO2hhcyZuYnNwO2JlZW4mbmJzcDtzY2FubmVkJm5ic3A7Zm9yJm5ic3A7dmly dXNlcyZuYnNwO2FuZCZuYnNwO1NwYW0mbmJzcDtieSZuYnNwO1pURSZuYnNwO0FudGktU3BhbSZu YnNwO3N5c3RlbS4NCjwvcHJlPg== --=_alternative 00087F0D4825785D_=-- From haibin.song@huawei.com Thu Mar 24 18:28:29 2011 Return-Path: X-Original-To: decade@core3.amsl.com Delivered-To: decade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 75AA13A691C for ; Thu, 24 Mar 2011 18:28:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.013 X-Spam-Level: X-Spam-Status: No, score=-4.013 tagged_above=-999 required=5 tests=[AWL=0.482, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ak46xmwfKimU for ; Thu, 24 Mar 2011 18:28:28 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id E34873A691B for ; Thu, 24 Mar 2011 18:28:27 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LIL006JNAQC1N@szxga03-in.huawei.com> for decade@ietf.org; Fri, 25 Mar 2011 09:27:49 +0800 (CST) Received: from szxeml207-edg.china.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LIL00C20AQCPK@szxga03-in.huawei.com> for decade@ietf.org; Fri, 25 Mar 2011 09:27:48 +0800 (CST) Received: from SZXEML401-HUB.china.huawei.com (10.82.67.31) by szxeml207-edg.china.huawei.com (172.24.2.59) with Microsoft SMTP Server (TLS) id 14.1.270.1; Fri, 25 Mar 2011 09:27:44 +0800 Received: from SZXEML505-MBX.china.huawei.com ([169.254.2.240]) by SZXEML401-HUB.china.huawei.com ([10.82.67.31]) with mapi id 14.01.0270.001; Fri, 25 Mar 2011 09:27:48 +0800 Date: Fri, 25 Mar 2011 01:27:47 +0000 From: Songhaibin In-reply-to: X-Originating-IP: [172.24.2.41] To: "li.lichun1@zte.com.cn" Message-id: MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-language: en-US Content-transfer-encoding: 7BIT Accept-Language: en-US, zh-CN Thread-topic: agenda change: "PPSP and DECADE Interoperation" will be presented in PPSP WG only Thread-index: AQHL6cOhKKHMmfdVBEmD6zjaqz6C95Q9QoNw X-MS-Has-Attach: X-MS-TNEF-Correlator: References: Cc: "decade@ietf.org" Subject: Re: [decade] agenda change: "PPSP and DECADE Interoperation" will be presented in PPSP WG only X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.9 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, 25 Mar 2011 01:28:29 -0000 Yes. We have moved the "PPSP and DECADE Interoperation" topic out of DECADE agenda, as we do not want this topic to be presented twice in PPSP and DECADE. If you are interested in it, please attend the PPSP WG meeting on Monday morning. BR, Haibin ________________________________________ From: li.lichun1@zte.com.cn [li.lichun1@zte.com.cn] Sent: Thursday, March 24, 2011 9:31 AM To: Songhaibin Cc: decade@ietf.org Subject: agenda change: "PPSP and DECADE Interoperation" will be presented in PPSP WG only Hi all, I'd really like to discuss the "PPSP and DECADE Interoperation" topic in DECADE WG and PPSP WG. I planned to give the presentation in both WGs. But, to save time for the rechartering discussion, I will only give the presentation in PPSP WG. People interested in "DECADE usage in PPSP", please attend the PPSP session on Monday morning. Thank you! BR Lichun decade-bounces@ietf.org $B Dear all, > > Here is a draft agenda for IETF 80. If you have any concern, please > send email to Rich and me. Please notice that our meeting will be > held on Monday afternoon, which means you should start preparing > your slides early. > > Monday, March 28, 2011, 1300-1500, Grand Ballroom > > Agenda: > Agenda Bash, Chairs, 5 minutes, 1300-1305 > Problem Statement, Haibin Song, draft-ietf-decade-problem- > statement-03, 5 minutes, 1305-1310 > Survey, Akbar Rahman, draft-ietf-decade-survey-04, 5 minutes, 1310-1315 > DECADE Architecture, Richard Alimi, draft-ietf-decade-arch-00, 20 > minutes, 1315-1335 > Requirements, TBD, draft-ietf-decade-reqs-01, 20 minutes, 1335-1355 > Integration examples, TBD, draft-chen-decade-intgr-livestr-exmp-01, > 15 minutes, 1355-1410 > PPSP and DECADE Interoperation, Lichun Li, draft-le-ppsp-decade- > interoperation-00, 10 minutes 1410-1420 > Secure Naming, Borje Ohlman, draft-dannewitz-ppsp-secure-naming-02, > 10 minutes 1420-1430 > Rechartering Discussion, Chairs, 20 minutes, 1430-1450 > Conclusion and next steps, Chairs, 10 minutes, 1450-1500 > > You can also find our agenda with the link below. > http://www.ietf.org/proceedings/80/agenda/decade.html > > Thanks, > Haibin and Rich (Chairs) > _______________________________________________ > decade mailing list > decade@ietf.org > https://www.ietf.org/mailman/listinfo/decade > -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. From richard_woundy@cable.comcast.com Sun Mar 27 11:59:53 2011 Return-Path: X-Original-To: decade@core3.amsl.com Delivered-To: decade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C74B3A68F5 for ; Sun, 27 Mar 2011 11:59:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.657 X-Spam-Level: X-Spam-Status: No, score=-102.657 tagged_above=-999 required=5 tests=[AWL=-0.922, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Y8gkpnscIEk for ; Sun, 27 Mar 2011 11:59:52 -0700 (PDT) Received: from cable.comcast.com (copdcimo01.potomac.co.ndcwest.comcast.net [76.96.32.251]) by core3.amsl.com (Postfix) with ESMTP id 6160E3A68F4 for ; Sun, 27 Mar 2011 11:59:52 -0700 (PDT) Received: from ([24.40.55.40]) by copdcimo01.cable.comcast.com with ESMTP with TLS id 5503630.31158432; Sun, 27 Mar 2011 13:04:02 -0600 Received: from PACDCEXMB05.cable.comcast.com ([fe80::a5b0:e5c4:df1b:2367]) by pacdcexhub03.cable.comcast.com ([fe80::d1dd:b302:b617:3755%12]) with mapi id 14.01.0270.001; Sun, 27 Mar 2011 15:01:25 -0400 From: "Woundy, Richard" To: "decade@ietf.org" Thread-Topic: DECADE Agenda for IETF 80 Thread-Index: AcvlDQiE8x8ajFM9TVmB6ZKbJX4wXQHo9EXQ Date: Sun, 27 Mar 2011 19:01:23 +0000 Message-ID: <1CA25301D2219F40B3AA37201F0EACD1134D2522@PACDCEXMB05.cable.comcast.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [76.96.111.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [decade] DECADE Agenda for IETF 80 X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.9 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, 27 Mar 2011 18:59:53 -0000 Folks, Haibin and I have uploaded all of the DECADE presentations to -- thank you to all o= f the authors that made this possible. Below is the final agenda for IETF 80. Monday, March 28, 2011, 1300-1500, Grand Ballroom Chairs: Haibin Song, Richard Woundy Mailing List: decade@ietf.org Agenda: Agenda Bash, Chairs, 5 minutes, 1300-1305=20 Problem Statement, Haibin Song, draft-ietf-decade-problem-statement-03, 5 m= inutes, 1305-1310=20 Survey, Akbar Rahman, draft-ietf-decade-survey-04, 5 minutes, 1310-1315=20 DECADE Architecture, Richard Alimi, draft-ietf-decade-arch-00, 20 minutes, = 1315-1335=20 Requirements, Richard Alimi, draft-ietf-decade-reqs-01, 20 minutes, 1335-13= 55=20 Secure Naming, Borje Ohlman, draft-dannewitz-ppsp-secure-naming-02, 10 minu= tes 1355-1405=20 Integration examples, Lucy Yong, draft-chen-decade-intgr-livestr-exmp-01, 1= 5 minutes, 1405-1420=20 Rechartering Discussion, Chairs, 30 minutes, 1420-1450=20 Conclusion and next steps, Chairs, 10 minutes, 1450-1500 -- Rich and Haibin -----Original Message----- From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.org] On Behalf Of= Songhaibin Sent: Thursday, March 17, 2011 9:37 PM To: decade@ietf.org Subject: [decade] DECADE Agenda for IETF 80 Dear all, Here is a draft agenda for IETF 80. If you have any concern, please send em= ail to Rich and me. Please notice that our meeting will be held on Monday a= fternoon, which means you should start preparing your slides early. Monday, March 28, 2011, 1300-1500, Grand Ballroom Agenda: Agenda Bash, Chairs, 5 minutes, 1300-1305=20 Problem Statement, Haibin Song, draft-ietf-decade-problem-statement-03, 5 m= inutes, 1305-1310=20 Survey, Akbar Rahman, draft-ietf-decade-survey-04, 5 minutes, 1310-1315=20 DECADE Architecture, Richard Alimi, draft-ietf-decade-arch-00, 20 minutes, = 1315-1335=20 Requirements, TBD, draft-ietf-decade-reqs-01, 20 minutes, 1335-1355=20 Integration examples, TBD, draft-chen-decade-intgr-livestr-exmp-01, 15 minu= tes, 1355-1410=20 PPSP and DECADE Interoperation, Lichun Li, draft-le-ppsp-decade-interoperat= ion-00, 10 minutes 1410-1420=20 Secure Naming, Borje Ohlman, draft-dannewitz-ppsp-secure-naming-02, 10 minu= tes 1420-1430=20 Rechartering Discussion, Chairs, 20 minutes, 1430-1450=20 Conclusion and next steps, Chairs, 10 minutes, 1450-1500 You can also find our agenda with the link below. http://www.ietf.org/proceedings/80/agenda/decade.html Thanks, Haibin and Rich (Chairs) _______________________________________________ decade mailing list decade@ietf.org https://www.ietf.org/mailman/listinfo/decade From ietfdbh@comcast.net Mon Mar 28 05:36:57 2011 Return-Path: X-Original-To: decade@core3.amsl.com Delivered-To: decade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B5C73A6917 for ; Mon, 28 Mar 2011 05:36:57 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wqOoutIDlstO for ; Mon, 28 Mar 2011 05:36:56 -0700 (PDT) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [76.96.62.48]) by core3.amsl.com (Postfix) with ESMTP id 6C8A13A67E4 for ; Mon, 28 Mar 2011 05:36:56 -0700 (PDT) Received: from omta23.westchester.pa.mail.comcast.net ([76.96.62.74]) by qmta05.westchester.pa.mail.comcast.net with comcast id Qc5f1g0041c6gX855cea61; Mon, 28 Mar 2011 12:38:34 +0000 Received: from davidPC ([130.129.68.162]) by omta23.westchester.pa.mail.comcast.net with comcast id QceR1g00A3W3hpu3jceTYR; Mon, 28 Mar 2011 12:38:32 +0000 From: "David Harrington" To: Date: Mon, 28 Mar 2011 14:38:14 +0200 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_04A2_01CBED55.C952A1F0" X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcvtKNxC/VEhw0kETk+Zd9fzr2LmmQAHBz5w X-MIMEOLE: Produced By Microsoft MimeOLE V6.1.7600.16543 Subject: [decade] FW: I-D Action:draft-farrell-ni-00.txt X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.9 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, 28 Mar 2011 12:36:57 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_04A2_01CBED55.C952A1F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit -----Original Message----- From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: Monday, March 28, 2011 11:15 AM To: i-d-announce@ietf.org Subject: I-D Action:draft-farrell-ni-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : URIs for Named Information Author(s) : S. Farrell, et al. Filename : draft-farrell-ni-00.txt Pages : 11 Date : 2011-03-28 This document defines a URI-based name form for objects intended to be used for information-centric networking and more generally. The name form defined here allows for the various forms of hash-based binding between the name and the named-object, as well as supporting human-readable and hierarchical names. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-farrell-ni-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ------=_NextPart_000_04A2_01CBED55.C952A1F0 Content-Type: Message/External-body; name="draft-farrell-ni-00.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="draft-farrell-ni-00.txt" Content-Type: text/plain Content-ID: <2011-03-28020554.I-D@ietf.org> ------=_NextPart_000_04A2_01CBED55.C952A1F0 Content-Type: text/plain; name="ATT01011.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="ATT01011.txt" _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt ------=_NextPart_000_04A2_01CBED55.C952A1F0-- From richard_woundy@cable.comcast.com Mon Mar 28 16:42:19 2011 Return-Path: X-Original-To: decade@core3.amsl.com Delivered-To: decade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 610C73A6AA6 for ; Mon, 28 Mar 2011 16:42:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.364 X-Spam-Level: X-Spam-Status: No, score=-102.364 tagged_above=-999 required=5 tests=[AWL=-0.929, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o6zV6NIoZoU4 for ; Mon, 28 Mar 2011 16:42:18 -0700 (PDT) Received: from cable.comcast.com (copdcimo01.potomac.co.ndcwest.comcast.net [76.96.32.251]) by core3.amsl.com (Postfix) with ESMTP id 5BAD43A6980 for ; Mon, 28 Mar 2011 16:42:18 -0700 (PDT) Received: from ([24.40.55.42]) by copdcimo01.cable.comcast.com with ESMTP with TLS id 5503630.31343841; Mon, 28 Mar 2011 17:46:29 -0600 Received: from PACDCEXMB05.cable.comcast.com ([fe80::a5b0:e5c4:df1b:2367]) by PACDCEXHUB01.cable.comcast.com ([fe80::d1e7:20b5:9b63:21a6%12]) with mapi id 14.01.0270.001; Mon, 28 Mar 2011 19:43:48 -0400 From: "Woundy, Richard" To: David Harrington , =?iso-8859-1?Q?B=F6rje_Ohlman?= Thread-Topic: [decade] FW: I-D Action:draft-farrell-ni-00.txt Thread-Index: AcvtKNxC/VEhw0kETk+Zd9fzr2LmmQAHBz5wABch2bA= Date: Mon, 28 Mar 2011 23:43:48 +0000 Message-ID: <1CA25301D2219F40B3AA37201F0EACD1134D3A81@PACDCEXMB05.cable.comcast.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [76.96.111.6] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "decade@ietf.org" Subject: Re: [decade] FW: I-D Action:draft-farrell-ni-00.txt X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.9 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, 28 Mar 2011 23:42:19 -0000 Borje, How does draft-farrell-ni-00 relate to draft-dannewitz-ppsp-secure-naming-0= 2? I noticed a significant author overlap -- two out of four authors in common= , particularly you. :) -- Rich -----Original Message----- From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.org] On Behalf Of= David Harrington Sent: Monday, March 28, 2011 2:38 PM To: decade@ietf.org Subject: [decade] FW: I-D Action:draft-farrell-ni-00.txt =20 -----Original Message----- From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.or= g Sent: Monday, March 28, 2011 11:15 AM To: i-d-announce@ietf.org Subject: I-D Action:draft-farrell-ni-00.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : URIs for Named Information Author(s) : S. Farrell, et al. Filename : draft-farrell-ni-00.txt Pages : 11 Date : 2011-03-28 This document defines a URI-based name form for objects intended to be used= for information-centric networking and more generally. The name form defi= ned here allows for the various forms of hash-based binding between the nam= e and the named-object, as well as supporting human-readable and hierarchic= al names. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-farrell-ni-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementa= tion to automatically retrieve the ASCII version of the Internet-Draft. From borje.ohlman@ericsson.com Tue Mar 29 00:17:36 2011 Return-Path: X-Original-To: decade@core3.amsl.com Delivered-To: decade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CEDE13A67AC for ; Tue, 29 Mar 2011 00:17:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nBr6DwNyhYeK for ; Tue, 29 Mar 2011 00:17:35 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 7B74A3A67FC for ; Tue, 29 Mar 2011 00:17:34 -0700 (PDT) X-AuditID: c1b4fb39-b7c6dae0000023f2-f3-4d9187ef6c40 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 70.F8.09202.FE7819D4; Tue, 29 Mar 2011 09:19:11 +0200 (CEST) Received: from abro.ki.sw.ericsson.se (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.137.0; Tue, 29 Mar 2011 09:19:11 +0200 Received: from [IPv6:::1] (abro.ki.sw.ericsson.se [147.214.177.159]) by abro.ki.sw.ericsson.se (Postfix) with ESMTP id 2408D279AC; Tue, 29 Mar 2011 09:19:09 +0200 (CEST) MIME-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/mixed; boundary="Apple-Mail-44-953402252" From: =?iso-8859-1?Q?B=F6rje_Ohlman?= In-Reply-To: <1CA25301D2219F40B3AA37201F0EACD1134D3A81@PACDCEXMB05.cable.comcast.com> Date: Tue, 29 Mar 2011 09:19:09 +0200 Message-ID: <74D47E5D-D27C-4D4E-83F3-E4C682128ED2@ericsson.com> References: <1CA25301D2219F40B3AA37201F0EACD1134D3A81@PACDCEXMB05.cable.comcast.com> To: "Woundy, Richard" X-Mailer: Apple Mail (2.1082) X-Brightmail-Tracker: AAAAAA== Cc: Tim Polk , Dirk Kutscher , decade ietf , Sean Turner , Christian Dannewitz Subject: Re: [decade] FW: I-D Action:draft-farrell-ni-00.txt X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.9 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, 29 Mar 2011 07:17:36 -0000 --Apple-Mail-44-953402252 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" Hi Rich, The dannewitz draft has it's origin in the naming work that we have done = for Information Centric Networks (ICN). We realized that this type of = naming can be of general interest for many applications, also in today's = Internet. We thus wrote the draft for ppsp. The work that that draft is = based on is largely summarized in the Global Internet Symposium paper = "Secure Naming for a Network of Information" (attached), you can also = find the presentation at:=20 https://fit.nokia.com/gi2010/gi2010/GIS2010-SecureNamingNetInf.pdf In the latest version of the dannewitz draft we have put the emphasis on = stating that a flexible secure application independent naming scheme for = information objects should be a great thing to have for the future = development of the Internet.=20 The naming scheme presented in the paper was a first shot at that. Our = work on this has since then evolved and our current thinking is = represented by the farrell draft. Which we think is an even more simple, = flexible and extensible way to do secure naming of information objects = (and any type of objects for that matter). Please note that we by no = means claim this to be the 'final solution'. It is just another proof of = concept on the way to, what we hope to see, a common secure naming = scheme widely adopted on the Internet for naming information objects. Hope this helps, B=F6rje --Apple-Mail-44-953402252 Content-Disposition: inline; filename="main.pdf" Content-Type: application/pdf; x-unix-mode=0644; name="main.pdf" Content-Transfer-Encoding: base64 JVBERi0xLjQKJcfsj6IKNSAwIG9iago8PC9MZW5ndGggNiAwIFIvRmlsdGVyIC9GbGF0ZURlY29k ZT4+CnN0cmVhbQp4nNV923Iex5FmhOZOT8E7AxtEq+tcfbfyyDOriQnZa3N3Ljy+oEgAhAUSEklY hl5kX2EfYB9wM7OqurMO2X+DB2s3FA7/bFTXKbMyvzxU9k9P5kk9mfG//P8vXn/51R/Dk+t3X85P /hX+d/3lT18qavAk/9+L109++wwaxSfaTIuazZNnV1+ml9WTqKaoZv0kKDMFHZ48e/3ln8/+dD5P s/WLX/TZ5fkFDOVnM8ezF/TbLWEJZ/fQRhkVVDx7S4/VYr3D5sYuUzTh7DvsxSnn7dlz9uJr/D0b o6INZzepd2tgpDdbj9epl8XYsyvW+V01Jo0zK+zcuHnSSuch9RysKxNXRi9n79NvY4I6+/lcYWMX m+7WUX4og/MGV2kQFc3Zt9RWzzb6POfZw7qu2OO77fFb9jgv3QaYyronOoYyP2eVKVtCc2X9bCP9 5dm/ETVhGYuLC1Lzwk9xsco+uTBqMlHHJ89eAh3/Gd+xATb77BX1aoACBqY0T2ZxFseaJ6uihlW/ wwY6KG00TIceR61zixCA+jRhvdjZ47ppO+DNs29wEG281aWFg/16k8eDP+TfdjZIFG0nA30DGdbX 2Bhs5F/WzsqCgSZee4sLdpM2AdZ+ofRko9FpvS/wbasXs5y9xJ/AZMCHz+mpcS6xWH6afwa74KTc FCwsHCelYbuWzJnaRNiv99vPX9IIBtb9X/Fp/n2/dfbj9vP7c4uUjPZsSj047WyemV0C7kbpYUBT ZdUER/BJtcJ/o4784jwyh7KT18Gf/Q131SGZWxrZOBmnzv6VNls7jUxPhInwz7Nb2m3vFls4ATYe pwLsP7sneJbMMnuTxv4/xDbWKJot9OKVVjPQoGn3YpvDgHIXIcIWz7Eh3V+3PYZ1ATmionXBLx3t gIa4wXxbr7fHd9vPW2phZ+Vcpmj6nThFKRAfmY70O1Haaj/7TBwakvfCHr/YfrIhX+NeLyZt6vbe e/b7+Ta6NEG2YL7KQY842RH7eAvTaNjnt6tAwDeAENqr0NL5f7d0XlQAVdDR+W471m/XV4CQ6wm+ TEICOf33GwO+GjMgbpsOoBN0y8Sl9YiZjJ6Csi0zfT/kBZLExsKWLpndOormrQZR5PKbXsOEh+zE 6MzoybiTM9bl1oJPo2dJmgbJYiB4jKr6naak9LLkcegn5w/G16xxmqqfrRvKGdx4KzFK0qM9NVBH r7/fJ5WJcv1rorQNsKKe0sQW/MXEOHqOizTOgOoaVgtSekh0Wu9lSw96er39FA4jpxjf95t2h5Et UgMbllhRgL+3zSOtYnkSYRXeROJd0NeTdXCunMJDkHX21zQH4Cs4S9+TztczYBXq1jqADnDw36Z/ wGH0NH1oE0Dn4dQMqJMF9WgaESAgG9IA1UHGAvCjof4XHjlvEZT9iZBJCH5WOG0QwLA5EQSwQj4A Fr+kvgEKhUQza+awlMFxgrfIAshJDlQg6+ztuYqwPFtAEXSyHj83O897frH9fM9awNpBJaMiONB1 bhGBWxx/njfQw8skmAzsSwYHucWbtAKAJGc3b3gvV6heAeosNa5bd+F1Ao+A2ar+8hJCgCY3FZKj vr1GmHHBGr3YurzcflbNeZ9pBi7OgKBepC0CSZ1nQCP9KIxEch2WGqMPTy7gNcCCiSVG++sKECY6 M5Kz+cJRB6k31XS7w4fA295Uj1/VvAZt4EC7daHl+ZAVCLwbryIn7dut7Q9pHoCbeIOrNEi0xyZy xdrc8zbvpT+knZp1dU6m1KMDGVMdr3tOlXYP9eRDRcM35ekiUrZi+TQVPVfGA+PKwYAgL3oWpvd+ OCfmCIYzJBNFyEgkmFGV/PuXz/7Ln3lDvo9f8B1gguqm53QwXxRKsAs/L4BqqykzRnwjUYaRoG2T etSAwdnzm0q2so4YX918f67hDbDdZI64uatkiZ8Re4f6SLH581G5cIKh2Au3l9hTgJPtzr7ndH5I q1F6h3iMR24qMXKdpqdw1v8oUYe8ggySz0p0nFX6bS/cAaoIMKcuqiiGRun46Cdnl/owC9vMR7ng lKv2oGIONscf++c9kw1eHnNiNFNUjfqp5uCjmzws4OYEo9PcrrcFd+q5p1A1FPJCBCQyt/vQiHJq ZJaRBE3tL9Oc1dKs5XLTU3wWWZQbLbDaDwPekYh5t7N8esr25zKZxeSxQWaHU1S/D3+G82Yq/dZp PSJqxXPdriIiBgOhIWA+YdEIGqw/YTTqQND0UnBKgwLEO/sj9gim2RI4F/400EMdqw42mQj2Lm1c AAstLcItracr7ZyvNdLzdp38xCeGZDtdacfb6t1Et6h7hdDjKt49Y8A3hIs19DMD9Mk4mO0tIaPy Z0RGwJ9xcy713FDt/9PzC5cwtowzql3nW40vaxhxXgX9CkywU29VpSb6s514g7f5QqDwy9TlbJZ6 qIf0PFpZMK1NzFGJi811jcXf5iUBsuSNmTx7i8IBTBCzyv36r/C+msCsqSUQG+L25Uj7rWeT1uDJ p4mbjq7oMVNVQOvhPECbCGd3ghazj3NQusimZ8xwa5ElWK4t495zsPO2WjmoRzOPbIANGek4uega o2ZtzkRUA1M3QMOZBrGEDuRB5+KH0VRSa7fpTVDXNSc9H7NDzYP4JoDmswY34dNNuEqGXLAmbwXo /0Vz4FOJEC4IXvE/DLa3U3s33aGnAfZQH84eUOINm2bhkDfCgYHu7EwuT75vFdyo/nF7wwA0e6MD jhaAowpJA+EILjhZMOGMsdHiFWegu04Q7CLuv4/FEtpCs4f9OPttOibQIEhcgtYszkQFu8/h1UHK 1s9mEzccjuObMLTu0rsVF7wYgxbRjmfccduPDBg21Kq9GlmANYVvagCRG5PzJze2JpSz1fIEHDMT PMqlTqvAlOCfRkIZ/Ldo9EvqBfu2ICdrQys7FGKFSViHfMjbh9SLXlSLRHFBGLLas+Vpcb7B4/1K jV8cBRCpS90Y3ht5y5KCX/lqxUTBgSqxNfsw9cmp3llhtEJX2dSDHeY4ujPD2OOBVvr6/AKw5hSc rY8v24rcmV6W1ti4xpc1YeF+gsRpAxYYTDBNoaMjPl3scmpiWyd6Qsf8hwunto0Gk0ZHv2eFYZMt VtxJf4lAb8uaHX/ze079v3YIlUm2TvC8Sx06reXxaw2FzaFH0ZX4vJtX6uVWdvUgQ212eLXczWSX PD3MUb1jzDgHRlOo1OMVPo2Taa1r+TQ7B2ZIsB9jOrcyHGeQIz0bDsGH6N77eWhs3d6mFnONTtb3 LEY6E7ZNHdjFDU3nFfPCa8Gb/1egztpPYQ3JLEKoZ5MOuhkASeIOkVIjfmqNsD08ZlFqR0I33oKk dlrUW9kzlRA72IAYBhICDoK5vCNrRvKo2owpTRZdhtmUANaKLSFpJ2dggg9SN/gyJgx8lLqhac4g AEYYV6Jvhe+uBUZhQ0I/Fowc70UvDf5ZB332TwI1GRKtXao3K0AjefGQurLLnhpIc3FC/0fUTbUB wnyysHEAF7UjjwCO64wWlDyQVAFMjq4ySNN7C7zXh2Nwoa71AO4KxtYtJ/gUL9OYOjxeUxZ9N3Ly MQ7qIT83apPuaYU2eSrGAck6qjXw7bLZdWGom/r8ozPCGgPIPwVMPFnv5FmAs9JHX9pgpyBNWM+P xDxZki2VbX07ZfeUMhSlzwrnfRpF7yGLshhdiw6mJxoRQe6dusMbAbRmv1dcdl3LpfnQlj4KZi26 1Bf9kWDWRtBl3jYBxnXiV91pYlHzQmPsA33AUkzh7ZgjxFDVjuLBoWab0xazJf3NBljKZLzt4/6V 0+1Nahijl+nEzn6FTJgoeZXIEJeh/bayG7axTn2Uq1cQcU9JVDoD9mnhpg+KMA5xi1NhQgP3boXJ DBxKyg6xnUI3ltvTQdurX9WaEN9N+YBzStbYH7JlsN+cG0wfDeSMdSA4TLS1txYDNTEUMtJDCevd /LJ1/EgYydd+m1a1WDNyjrD0hz5mIPgTGjcRLnOJphVEMGZcNUOJahBtAEPesscsfDhgomOBG1Ds 0+yGCIwcvcxiqhzA19vzChdQh5j8mvEj+dhax0hynOuiIkLkXCHHh4rvZq4wUC/S97EvaTSDkLGD dVtgQE/e7WKHtIYPhMD4bgzmIyFwmkHc8xedMI+sMlPKmR4fJB7lfth+t9oAu5lVrZabwAxKhVBL hV4zQjdmGb7qPOZFUwtt1IguWwINttGi0fToLK3KGsD9+liyYcqdil72Ad9+Uf3rtuzwfAzMvsbm wL/ecs7IR83bAY4RoGnvgyF/b2/I7yqn1r50M+Asffa7JB4oUvX3R2HgQbYOt8szmKVxHIX4N45r ts+p+QCbCDH+Gua3TFWH41cWd3OKXe8KFpy4/VDJggPEj5YsOAWnhsY1lwl8FLTsAHfYFifccN6R 7KdBHlLLay0fWVCINu7rGQvk1K0uEJy7A3GUVsPFwYHAQ3faYQr2LKVugUnQaLRbLqQJB8Oos477 uBT71Ms4A6LCISP41nleB7GlgotwNl7LuRb4d9hJ1tsHG9DJWIxpfWpSS3t8ctJKkDJtPiZphSdi dRmw+3CCS6YXZe5GxLyPTSSF7hCftFvRjt+6TPcBK9kmlc45DFjtXPg60ehgIABA29SkFzf5pbTQ Oob5LifKAPKNuiTK3FWsdlH+erGmgGKjWjBtAivZlOifukxBs7lxRN51woGseGpt8T5iExTAPkCn 7kcBLSFsgT+RstiL9UFCHh+QSoE9omPytHobxV24ILMmJb/DKmKdJ7cuvw2qrS1e9gxBYz5sTbLh p+I2iCtuAqLIES/hW8rQxFyaI0l/TYSyudgRwY71eKMM9IvxWiWG+haVIt4FTTaOjZPzS5pnukZT esKgD+w1XWqBvZndUhj3O0zMmCIGlkBneZPM5D+eX2gwBjAN6vdbg2+2n/9j+/nP8FNNxrmF9/At /TRgDfAe8Baq1THa0c3Fi0UjJsJFWgxn5lPzJ3rH0t7SbUQg1d9wa+OcLLR8rzHfHrIl0z8/xjwc Eya82MjvF20XDMu9FBAGnj9m98zyiz6s94jo8Svs2oJN5vndRj4Ku2PFrvGxQVhv77cGeUZgEFLm nDdwbBbDB2GT443fl8bVNTl28+plagCL5UPfj2ff71d7kYvfFsoTNXp0b6y9iMivk5UXZ0Pet3zL lF0+4qOwZV3UfL7K2gsQ2ovTm2DO91o5g/DrZZfdTqktPtC2wA1cPBwnT8ycJ8vYkJHx52QlZmww 2OAfsLMARne6HJY74y0qblv76G7g7l3A5C0EQl/mRYHg/88z9pyR4/fbz+/OgVrWwLLYpP/zPPUR vT/7M+tCbSP+hT1+mloHN9jGjubH9hGJEniLq5o/kCtQhObbGExKco6+Gp9ePlq6M2j1XMmZTPfF 0bXtbfKsEwy6gg2M/sRqm7sd6Oh2YLJEAOgdsGhFAC0TgPwG+uwPJGDNYgPnD3ZT9HZjN8Z5XO4w 3mSnMovunZ55H4xlpYug7E1kWVQTIMiEzRFORu47kIc6X1is+S7tS0kUjyEoTsT7DP8sSpsmT5rG asVSaZrFUr5OdsPYhUkdtPBApcOvP9Bd7xA9ZzJBx7Er/bzf6+0xul/wMuXSsB6jfSIWwDNd7Wja hWUBK+sPWwvkNpwo6OWK24zIbdhaGVkt0bJdoMoM1a5TPYCOrkyRtp0NiIHUZh2ffk++ikz7qHMR j4+WW41IT++xOW0qs5iwFfnSmhYTDf/JZoZ0onIUoH45nWxFJyrqYUPDlFSiYfEr2Kou/jeoYyAf rs8x+29RnOT1mYSZAcj01YITxgPAgJ5V/LvWsf77CDClnUZmlDUEXbhfTuA6ouGrIhcyUajowSdS tOsg79Ly4IRzsSbguhqA0Ep8aFQLPsW7Y9UJK4oP4VDSe4Lg+YR6L/1mwIsNc8EE2IsNBu8dSCLw znl0c6Cc1zE65iR+zndxBKYYQGU1DKY0xlIixauqgccehQuf6BilvUtttYTh+fL2ZpkWPZ7m0zJN NzicHRYRRmRdX+attehoSzpPT8F77vLoO8sqL7WskDgrQcPYhz3ttm4gDS+0j1NY9MezcdRlGsiA YxFWHzDtEWI2ZAXOAwP8CPe9Tz00pTeu0tPorMBFl3lgtxyQE2xuL/J7lH8ti0+uqbQxO/IzLV9L tOE73zNXVzhioGxRSd8X0fsisZwx0xzsCGbtStjW9ExcmTu7WC0B7PMZ6k0VXVh3XeWkaqfpRvQb /nQo9jrt01qbuHvO0EVSQarzJfxtKEIqaZkmp1oZg0/tHLncYGN8sWG9jiOoX0zqdnYyxvN+kfNB UXlte+hFr/WHi+RRmY8yLb/DUwNo4mMtMFZghjM0aWvZAiNCaMcNWnau+uo3xLmVlk+yEO8Prfck GVWzAEx/rgRghdy+ZezBpsLZgzA2es7Wu0mJ3V4NGZJp5+LQCqoiLzPjCNKFrdBWJ0gQsINk2yWH 9WZKaJo6i5FCpr2AYtRiUvJ2yEs0Lt5G8mf/cR5nDL5U5+T7NGyMiyBxr4esP1oaFSBYGzOJy1Yp KM+uO4vefr7QXKkLYEl3mjsI2fTGZRYCtlqmOPK16oohiABRqbL/2X3lYKMwaMesQ7YGpniZKGVL OInJ+LynPJwNA4Fa0ATwMpbuY9RiBBizxlgAChaFqLlxanib5bSX9nrcYszNQj2zGrCkVTupxb6X gga/Ol8mPyMvsWkwibTJqdXNpUyB+0xYMNSFIV2tMc9blizUwmxoksQJn+5DS7HVrrNagYxVjdyn EU1F6c4rRMZ+X/lNcDhR669Ya+7K3/U4UQvGUb19QUNWDqdKSGk8W4GXRXzVtm3dTeuWakmvCSBf YB3hFAh9F5I7tUuATM4EvrBu2Ropuun3ufH9ZZSV3qpUH1f1tbaDnZlUThfLzMkA18vUAIMHAshj YoxR6Aa9CDNWyBk6LzgspyxfrPlWM9j9xmCH/ZXUn8Q9aSGmcltgdkqIk6mDdsIOdRU4u1qHm+Pi bkjh96mzpWGYV4NphoF5gIsuM7b6gCXby+YOWDXAqXZVjJF35QtZG8j+VGc8YLFYCbq7km0ZuQ+O na07ckOhM+3n1INVmi9zXEex3mtn3NRMmFmcdRwR2+o6fCGZg2yrHTrA55ASXIHhYWUsJPMmsb7P 1StwACvgnMZhQJ2pFu85Y7cbuadMGIKEphWF2LGySpBogyiNrJ0cLF5b+4nMM+ccXWYdbw8DJGPH UaPynZ/mfN3SUtrnuB7qjzl9fEnXKHEGra3kXOPQy136RmDQY7y/9KJltu093Hojnfz7ihmwMZYY GRuStX5GSeutESUt9rVoPRJa+Ls/9s1BxcxUralSNv2cvaQLftrIez/kih7J9PG6mpSYz4cY+oW0 +saI2YHLU5p/XLQAkWuoY2E351l9crcmLUmv8vAEI+CMU6rRaHVjgdjXBC6iHoeOc42Wx9ZhDc+L MBmy2Mtzfs0gU7r3Pu+A7Trqj/Uv5+2kt8pFQsNSdgHlWBqsOng/ZAvJaFl/PsUpAckW3aNNwidC qdxX+B4mi9rTFtdu2kuBj7gxWpkGwBjjKBewBjs4Y6dFJistlGiTpTiQM+NK13zJgzrRBIbW6O51 mroxDXMnjBswd79g3FOOhIxw0zu1H5Fx3FUpkx929BcFcaId2OGtehqkLTGYnNkJu0NhsBsM3/Pc nYyxNe5Unm3jfAH6PFlrnenpJfa6IW0Z6sXoJ7ylXuE7eOrWYlxMx2HbICjmD/ErHo0NrD959sOn im/FMHlrdgl03ItPW+SFznpoXfAAzMG51h+2UqEzk9ezUuVkrWeFE5P5LX/cmOO2cm+t7MMa9ydB NeeNtUDPtrdUx2asIimNe0F5dNWftvaonKQmF0kPOLRGSSQg+pqFqW2NLMpT6/Zz9ggMHJ3nmrOH XaNUP2QYrC/2fN4y0PHECpLWFK7ChFEnMjrJa/xIhlpjkAc4friULjSUuxWdFm+KDtkV6dhCV7zb Bcp7GVelsJLzRNuk9APyeu1VbldDfiwCLaJdxsQQc2oILgvGog9lQV7wCrOOJXYWsO06za38fqqh OU+zkRDIusH68QkTsK1oKzYJE/hUHzSJsfFc5y+xE3ixYtDTgRpBWnGZOA6VD1zdfabFBUB7KvIt JlrpEDBac9q/QJ3htXYraap7cbsGCrOJ40PPi5JnkYYOC5fXncOTXnteluQltFm/h40bVdaOHKji 4CG+wGn6oD7YUk4gdMZibkWoNbCbCy0krg0SysvoNHVWa9zKvZrsAiv5zD5XKtDnh0q0LqVPY9kD +WLr46fFJHT7HLGJYqwXKggKketO6U3hEz27kbBR+LuIQslPxNoW1nTGDXJ+sqWMi5bhX3m90qsC RBn4VQYwzswLvsANiR87qjRJZ0hB/KxLbGECdmZUEBj0Mo/W+uQMfSVNdtCmt7QR0hRqZ1NqrCQv TrJ+VZTkuXA1ojNe15RDpafZtGnyZUU1FKWZzWLk8vPmaczJdr8YOXdEI/ikMwbTd4Mipv0Av/G+ kMCOUa8ylccvvwh3YujFGe+ajY+RkKrDcnmOaFsbNFUfHyRpEQJkmdav04Ssb9ih+OAeUm+E09Cz hXUyHuWjYQlhotMwDaHdAcc5pnJgkdGn6aUwY3RhTdGJTkjRaW7FUdhSK1SbeFfMseSwedHeq3y1 WlskG80Qy/C6/NGq9ROPeI48Jsi/g5/ORuAv/vT59pO/92J7/CqV48XPNN7SU2W8yl2E8o2H/PMl m9HN1vgNe3ydJuodgpW1xV1+ShB0fVovcB0lrWSJNi8bXZF2sOy28T3rji2FDVjKKodQjf2cdwct sBhKLqLdzy79tOjlzKWcvc77SQ/v0mtqKbef8z3Nl+z5PXv+Yuv6/dYLG+Vl2buy59XYpnxgSsO0 F7t+UOoVG6IwDxx5yx7/xzls54R1976mw423JPEiJnAtnFE4W9+sj5NuxatEWj+5wM9YAVnYZ4ry NnEa3bHnf6V5w3+B8yZjQsS1GMNaFs6xnK9ephbOO+kAsO7Y0yowb+Fo18ydu/XVt005IzVzaNhf x43Khf21w8tq9ddS85RBnplqY16n5jp/bnN4LqBFoKr9vyPZYCyGbe8P7PqPYwZm3P4mz5ZuwWx0 v2NM8vr1vcDQjBkZ4z6wFr/B8olazzlVlOQ5v/WTjZEZr9OvKbctmQq3r3Ngg73KTAEGyr9s3fL9 YIt9zfq7SE2AizNszHNA1g4gfZmzx8+E18bbnW95GFUuNrlZZUWn9KxT/gJnjmEvjOVfvy5f7QWa pPzN3Cgt0IXo8lDwD3MWWJdfbRyk2eNZ+M1fvWADSe8q9tuw33TjB1QfVg08cnIYK77NX/IN5sTe FG5dm7wv3zb2uQWR9ZqxiaAvGBO8vuz6LtXWqW8bq8dcsE+piTfrVlMTxZp49nzOrkQ1ARwojG6F FydCIBaYc3Bl3eI33PTyxFG4J/Pp2BXQ+5WZ8dVdHRt74nGdCr9sZc/+G25WCgXuOK0AzJg1ueof Y4t2S+GfiExTzZ/ppLWY9R4TPb1Kk4Z/oV8Hf2LYIUPVtUBH/wXLl9tP1luyPxTwV7IBI5WFueeT WH++Z9McXUiQLi8w++plnrEvBmE7n6YPmpApgAGM6RjDBhjWt7p95Vca0kuVfT32fO0FfltiU64g FhapA7h3JYGxHgKtAMQS3K1FCZIlawPf0dJHgaskGHqL0Nlo+5pkApohJ+FdRU1K0VxLOuxeQOlM EurjlnHEIPmRenmVk11dGBynPOk1kfbNcCkVA40avExrxeSggY2bqxY1PGY3D29q3UQ8dm7ASyGf Tmi10ulpSh6ctZJFy5peuBusEAJcncuPexIect9W9wdgZRlKpbQdU+N7oaJ9mamriHIjbH93U6Q9 rG1EMOVQShKTv/h82PUrkVGimub+1OYk0x0WzWT5lq0qpaHOoLI5yw+S9MZJ0IKWeFVSH3Zy1dJV 1jalBN9ygXOc7LejEYJ0+eJ5GWKUCFu2pLTgx/0kCZjGWe83q/54th9BLrd6sS51Qzt6HAIXHs/l 8XCLnLyo5j0KvO3kdUihUEfVkEfjdFv9LhX+xWs840y2sTKiSCim3+bSs4uvEqAvU69aqf07HbTs H0/q4twdqxwmb13+erTiMFAZgzW0tppKc11poDvh/Jgxwl7lxUbXkXsDNPlIclhVfcqbChUrFRrG LbnAMj/kjtulVoB3segdXVc6pdHClsDOi7WV9E7KmDLK1DyVEuNUqG5qSE7DOh2FYM9+DA8jNl5L Tmo2YhUcHTHosbgKPJyCUztecdyERbsawNJEFzu641E4Yt1Vxrxc+bCj/FgEvv68YP0xGXdZwO/q j5cASONkp1U5UdqxIe7HixokhNH0H7Lp5gEOrdVX2A6w5bVgCqfPIF3O+0gd1cHSY2Fkj9+fMFJ0 pEZOdBnwyO0ywbJAnkenfBAvEH8UcNI+UOGmMf5kP5ko7XKcFvoSt8DH7ysWTLf44ygZvWhfauGN gJkHWW8uSAfkh9xbiPyAvB2zPJuFxIMtI6dzUbKToluzkwTeZu9Pia7GekElrNlJ2G0lPo/pXrPA wqls5CiJ6HTSAprNyzI5NbQ9TiSB4OBemX5OwG3GHs7iWQESTCTUZ/xNGiT6PVaiFi7+OiI2zbrJ 0ubcJIhITgQ+wyntX5jD2W83mHE/5lpuwVZmTIqPKcSbhVkrDFGzX244qquXtR/VFNRNkDoVR7S1 8TxmuQOOJhbxFC4dfdWtvFPUpzMnap3tKZejNvk7Gdh7CJoUS9wHE6syY5JZB209pubUdhj1EENo TxI+dsYygpUso0UXd4yv2OpNWpMhkysTSAseMc7TP22P7/nh4lBxqy70uUhtFyzsvAwrKbitYCHB WKqesGCw8tjNSWpsTaVJOXc9DA2KnnWaEyT5LlkfncpJW465Cgv6K3hb3tvYxGHE5o0lYSV4x6a0 2fgts2dYhyFst0rbBQpqeWxnvE2LwkzKn7ktkwQSfpbRj4q9bJ1liZRaVhJp7JQSSigdAvUj9XSL GltPzc0lISGf0ftlQQqn65piUnYw03wiSXGenK8dNt+kx1ErwS1PGZ0YsoiNr4t6iwcdFdRF6JxM aUaC3JGwPVdtD7mPpQKi4n6lecQRAu8g5+VajqM6mYnrYEjtRrfca8Oj4cD0lsSBdcotFqQ2sc3Q Ljkze1fUmX1QYAF+kHeuk5lPR3Le5uLb3n5KA6JsDZXItvFXElS4MGVDg6DhscFUFH4UxqGhH4fM 1nNsj9capEdfSl5qwba9WBMpTY8eFzDm3SD4U6vYi9yutlc/h0loZjvNVG/9UYaDyd9S75IcLf9S TCtqx44XVl/kN+mqe/pOEo4R5oMxtnX7OxdHU/h1PxQ4cnLgoha1fBoTdTj/p3lDR/coO7xAO2Om GASYUR3OFHHEeiyhzu1tj8HQNM5OvfR6JQJPl8QR7v7yx79sPND4QDxK3VGobVWL0MKPCpz199ug raJC6DsuOxxPDb1eW2x4EHXTDkzm9gzgw9CKgUoJ57kfsFMFUCnxvhAq7GJVaczTbounabJ2Hl2d b7vmRhLrurdHtZ+MskN7NNHK7Vj5tZTMXUlh8QMX3MjLvJALau9aesRkaiHKJEDP5h6M1fRBqD1X 9sKcc3ve6QZDYnLKXoCLXNY+Ct6vcZ7FWNY1HiNck9FK6OJlmpqPe/HIsujvNl3aRb3IH3OZe3O8 XLeAFZiEux3zOz80Qy/J0H3ee0lW1cwqoAvgTmCe6lJlrvgrVo1PS8da7mk8jx812ko/6/rFPhOd PsPQf52hJKin1C7NPwfQIanWOdYCAFwASL8j9EyLdXktCuxQbnxLMq4KZqU0QL0VO8/20Tp4moeL a91zGga3bG1d/eNIkLSr6kEAY829H6e/PLL+OAXNYO1iItdpY5byIMwUVFWW/CpNNCrxVDZYA687 LGoR0LOI82noWTTaHqU3LlN3URQ1z9veSrhiyE3dAvWa0DiUYjS29VKCCIMEDHsObsUrwwskt3id K6i+1O8oFGnQB1AbiFfpaVuzpLm2hO95Izg+jhQ7XH/yu30ChhCuhHRH2vh0hReoga5Kobexf/JA vk4lemRjYAteBEUfYRW5AhsE6/5xtvBamtuNoPxVw3qlpey4uACEjcXefuV7X+vh+djyAsVcg0NO 9Uk/TUSRNkl7yWPwKSKKQ/FXs3FalDYyO1IDQ97+RFf1OM4ULOvnme0iFpUrbNdF1/OfpcAR6hyH N5H3pBK2cPV3twSu6++Vdgiwvyoqp4DsFAXzCLdsLyjblCw5R8e6iA6zj8gtox6C6HOvRSo2XmsO tq6wN2MSS04vIUVBEJlciz9kasa6zjabirBh75ryCnueztoZdmFnM5mg99PEdrKiH1/PEu92zb51 j4+0pBA16Na1YifsWQ5kNzkWtPLYaCq6TqdLgWry0p/01wso6jZNKPrwKwvB9bUpLW9p8+uSs8th JLeIKsnnqzDXATBQi9jK62IKhmC7MSAnAJ5c8yWYFPfx9DnBvbhPKovxKH4W/B2NOywEgNL78O+E VKMuZvcxYi2VL6klI6P82J8pqOkmzQK3LoTR5m5hsLS5J0MG37fs3O2GmCeyOhWCOehUCGZPgxbS D/NS9eQAj9YutY2y6WdK/SxptQDPyAiQpCGcD2+dFU2RA7cH2DSG2G6QdophQWNWL0xTJb9dNl6f VrMe3PzezbCRAgVdFtxbQRtyVvhio2kbi+2VZI+GGTP40YZ4/MinXY5viBswW/oIPXnMxqD4beKH UErPdwYWP2Ht6RbzRveuj43ccDt7Uw7K4Gu5YTHC7hAudcYPS+T00dvyc3jAFswyVoPyKN3eDoAF uVBM7fD/uKSZ7lQ9332RTLEOCMubulVT2MEEHt6JsQWgcIKXWaCgcMxKTY0QeNT+NFq8zkU+rKuz HAjmKM3dP+PpvMz1J1TIiQMLCMS/jxGMcN2qh2het3l1CmsfqCav7sOdL3BUHflYhSL1Y7g8TmJ5 l3rDr1LtfP8FSyaqU/VhcGf+P8pcx2U3E/o1IW2bkwXS2GtTu9HX26MhDjLi29BYblh/jfS07fMZ 9P2Fs1hrocsPxsdqlipq9x9p6EBwjWud9ZNq2BQv2lg7KR8Gpm3Hbp0xVB/mU5eDrMGi37WTpNNn n0cRGnSaSnqwnWhAZRRXTHHSWXDUEcAGrCansfiW5hgGSRW8/SxD12u90MpgQti4iPNRBV4YcbQ4 rPRuFV8c3uHtSpDBEZwMiciSDsayVfcGJsGa8mKa8zlarwvQuYsDoAL2J6IlHbhn4vlw17k0/qVy Bu6g2j3hzV68xa1wWATkRBZDZxIeyWKgJc7tp5IakqkZv30XB/x/Miw+ToclontKdq29FOuS2Hv5 8Wyc2bilk1qVU0JF/C7kri/fzlgJJAoav/vmVpEueCUfS2A+DBmQ3GoL3UEY44sxlBY/zQbG2uTm wVcyWrN77LWpvnNCfS26Ed92jhP5qah+1bJYyQme6xMtttQ08xI0KZtwIGf2baJDCOYTMFXeL7sD Owa3tbeva/B0eZad8IdzhYXcLeUEWNAbs1VC9sLgagr1tlsTmiOpXWcqS/4f3w8/dh8Tl6DrMriN ocJkE33rx0WeufkudaFqXqzMZGhgJtU4lNDxatSE0vtjEqFTH3vZO9TCm2Op0rQbx27nfd5U6VXT fpKvWRlMqQujLyQQwX8avjcICvNwYf/tCBgE4egH3H8DrbssbSCVOpyH1YoLbWnIT4NMU1/qKOzs g/AnYSdlCCEhFrVzl44WPWtukd+NGbBOM22BjAbUaL1tfHvdHh1wtG1LH2CBizLOoQT/8nMI/+ME qmsFgsy/8zDsbeyZPTxxE+CwbaUIHpV0dNrhRNn2cQo28Oog6SxTMpXoR8TXYl3vqvMj7qR1StJq z5f4CHcCTA/2cC1l3Bn1qzxg0vZdXlRsr9jgUwWs3tzhMyGASG8/yE6t58Aj+CQ1nZu8d41z6MM/ udfduBdCUttlkfTB+8f5IPnzVJk12JTFjoEhyqyYH1cpBjdn/bLu5ilCUjykblVsCvfUh6Mt1EEf yK68mJ08G0u5h21irFgGazuqFDYqGefgb4qHMpD3MOi3k1KE5cdDsRE9xyn7B86OnMs7R6sNeyos he/aRLXPDN0Mos+5+u6m4GKsq4Lge/gV5KaWkMH0S9V+L88gfNL9aYTH3XmmHsyuNOrlS30W0qLW D8aevBxkFJXMeZ5+Yimj07eUpJmMq22I4WiaalhTJqjxq3N0BuPXSA7kTq6uzipIUG54QvORK6wD jallJf5OXpQTmJExxE7F6ejAcFSD8/IBwZiG+DZaynf/uDRsGw0W0yc8jx36cCCFUL6ulvroLGV4 6iQP3CNN8egnd5DhcW0h8KU95k47Zx324Vg5iML2vqR5E00YIbo079V0+ZeNs1aZz3xyhy5jjlIl hbQ29uLT9BFWZfY+4EsftvWG3w/o8hwTDeosmXW7r/KnXo0+a311j8hwwy7MR6WC0EJMne70Lj02 RlJmvVBKL14XSrUKM+cX03S9O1ANZOhOHl4I+CdOl1Il8+8bOevE/qGykz5uWAuY0uMIbmisurvU cdtHB7k9YJTSxeVa9p8tZdch77UYPjq+7LGbQTKDnAFG2lJAGEB8yImwrubNT5FjJHhXrsuIHMYK mljS4ULhpcvkYdYN8u9qVZSrrpkUOJ2lLpLX+ZZVql9fi76+1kb5SvlKXXQfOir1LF6IcWra5MWH hbodsLV3HxLq3vJnFZWaPXA9Qb6Gjp0o2xqTuH6zdwWgZCJIJVossO8cuiiu8fpRDmQpg5dtxLu0 l6jLpBX/kAr0zm1lwO2jLEKtlDYL8XRCrFAUjfUhWo0XbnFU4mschuCMIvRRcxjwH5j2crnp3KA6 mexMHygjzCjJkxjSdoc5styTh7S8qFyX43DcDEiAmO65nfaUXG47cJLjBLH3Lk3auzYVujCPGLJf 6cBcFXXmQLoOvJsnmy9TS+YBZwgsEOfAWjaR8+VVGsbOlt/RFLwnJyO14xLTnD7S+du9BLTpVhpl SnPGr86wFBHB0Vp2aZh+Pggo0JVvtVPlp7l9/0GwkShrrIwbU7YLfux+AyRjAMmF1UV+pXZktI55 +iS14pqNeTm/OzcOegz27OvUNIDc/jNjL7XxwF/SZ+CMlsKi73IDVStPxn6VtZKmNoS3aRO7ve3D XK2R74G1f5XaUuu3TXWpAet04wymv8cquCXWgU+fJa+A/V3fWV388TGhwCKuGEEEISB5A4Qwe6kx DQK+xlV04dosA5S/d1OlAWFlTYdrOmPuOyj5ccyXid9jTjyHefyq/lIl/42mbAhT+s6SaMqi+9EM FAUR8R9259MF/J6f37ENHX1TdK8IZV7KxxjUtKNtWeeRbj4kEMe+DSGsgKzqF7ppKNyQE5D4gYvM Y9U/pfvIWD70E3FkuhbtRxxJFP0W14iXJY+4FtjGSxH9YVAiRY2wnp4SDdt3aSKL1oIbrrkDipQB nVax57iio5AqdTBRa98wKhVwMeS9XkR+KLfKowiky89cuCW9XgmqT0R/rKmHN984/f9nqiIXar4W hKpg7AjujKZyEQyuohL9L3l2Wtim04UMfhnaBTSyndL3wURuw4KG8L9hlK2WR9QUEfFnKOxNfZtP VUQuwURQMFvm7QFo0n0XPvdQ8WNXaIZnF5F37vHV401iwiYaRY/r748e8i5jaS4323KRfY6Sb/mH behGmOOXe4MelLBsju2RxPWdUpKUoNyWvFrXzUqzjJnsWHCfRjGBTjsG1mow3JQmora7ZZNwcurI uisfX4p/gRGi1nzsnZy9i9JUzE++SjBxWU/M3l1QwfVyBF/mj5jgkSmfIh5+7rWvqNTaPIfqP6Th QmuuVPqOPswSJEEhEOM00qtZM83DdzYi7Dnm/H0i1ky1jlARrXYmxyQsKRi54nfPvvzv8N//BdWD 5GhlbmRzdHJlYW0KZW5kb2JqCjYgMCBvYmoKMTE5NjEKZW5kb2JqCjE1IDAgb2JqCjw8L0xlbmd0 aCAxNiAwIFIvRmlsdGVyIC9GbGF0ZURlY29kZT4+CnN0cmVhbQp4nMV925Iex3FmhH3Hp8CdZzYw za5z1cVeSLZsy2tZsgSHL2RfgJghSAkEQAxIG36N3QfezKo+ZFZl9t+DGdjBYPBnT3UdszO/PNaP z+bJPJvxn+W/r3746uvfp2ev77+an/0d/Pv6qx+/MrXBs+U/r3549ssX0Cg/K1OJNvpnL779qr1s nhlnp5Dzs2TjNPv87MUPX/3x6tfXN2GeivOF/pzgp89TiOXq99fz5Oackvn3F/9Qu05TSbMx2LW1 UwoWen9xC3396vomusn44q/+GTqwU7Q2Xf0LPLVTNsngCNDABWeg25to4Gco9LXf1LbFh0Sf/tPe w4v2NJirP8C8PPRv7TovsuSbEidvYn52Y2H2GaZYJ/gC12JySO7qO3zdOePS1d31jYW5BHv1Azw0 xds5Xb3Ev3tbXLn6/vpmnqwrwdurt0tbb65uWw8JtuuuNobF2Kt7bAy/oOv1xVzc1eu98doF9Eye vtt/vtx7e9PaOutpZ/ftqbfx6uP+9B08DWVK/ilm9nLdkwhPpZm1rXKhrDPzswmBNn699mbY0K/2 Pr4T50l6ridjyULbIN+JM/q47JXJV9/W8Tw8LVc/7Y3fkD5u9iZIPzeVeHJ5dmMM/JpLI5i/qETm Q2TvviEEAUtzM/xfDutZ1MecvNxsJhvT1QcyL7LiH/fGP+0/6bYqL7KtqvTq+IF9ZETjZjvN0VNa +7ZNzkRLt/JtW5TLiVLKW/baNh/SG50mmdvLfW5kQt9T0iU0uP1cjiiVTInmjk6zW+i4WXQTX7Ud sDNbyh2joK3xf1wbmL91Tlvfn5djTYwIP1wjNVkXgHfGlS+22Rszm4UuYLeXidk4x4EW19crLa68 i1LX3c6cXu0/6fR/kieNtJjNFIGT/tsVeU5WcN+aBNj1254YV0KSPmYyIm2x/PYG1klo9BZHAQFh DKcweDpPKWWFhxHyIURFenjT+nXwxX4j9vCGUp0NU3JzgcOekSxcSVf/do09gJDKhX8RW2fr1Gd/ 9V7e5XfXJkx5hm37eW9AKVFl0HXkZFhj8iEdjZeQBH5uI2fc60qIHkT9Rof7sI3M2h8Zla3HlUxR qIxwqGUOvhjOrSipfrq+8XOacnbr7Ps33+2P34v7QpdKaZwcO99FP2cg8UQpgBP4Rp3kvdv2XubM qE0+lS/OB9uSBkYInOILsEFcaAIQNMiP2p8soV/uTGyb2vc7t3NlpbJlf23Ohg5Atn1ncq4XuB3W cgBI55Qp/RFyWeBatpS0CHAbd2CT2RuRk+6W8QpQDmEI5ODJoX23zC12EIxwCYn2Pu1P/+o6eABr wKjuW18ZkNuvyYxlMU546Ae5scwup/Yz2OBx+3e4A8Da+bb5f7uhHQF71G+VfjvQufPIBx3dRAQU 3gHyD/QkKGKiSOp5ax2c55tLFlMHyXyJRzi0/0RfYw9+isE/BobWLnxSoOd9axAcxxDvlslHx4VR XXPyDHvL37PCBXtUg93ZyNa3jR3OQWecP3zeAh+vv0eMvEoM8mmSA6+qBHDOkNfldN/m/u1WkN/4 EetglWmflq5iBszVidP+sG+XtiAAOcjFpynEQ7Y5cGPy+NN1DJNPwSHJYmfRadiYUBYl9SY3fUlM /I+6U23xetkTWHP3yW2t+fF1QnEjDRsjqtM6lKnbxfEWYVIP0v1eLZMOhvGx3+689H4BJXkKyazy 4nnbxZTmsMCS9ucmGIw7BCb0q1DAFiFQ8iLtD2bgja8YhRAraUwBzaIY+HCgGHgDyGpm2vAgGuo5 E25Oz7lOCMk/K5CI9EYaEGxLOn7e5oOYX6WCOmGjqZlE9L9pW1XWbZiztg2U9m/beow7AVsUBsQU pg7u4YQa9ietG6UZIMe8Utqfcc4Ascn7C8W1ZoyvEUhBpRdhUSphuQD9RcvZ2dbb7QIzoqVykwiI P4m49pUIHinVTG3k6KNg6Op45oo5RNtCHeTH/T3Cup7IKFHn6dQu6KoU+w0ljSp+QTiFxAA5V5G2 Xn5oS3edsO5AB4I7EE5/WSGRKx75AX6SGWTkf8qM5puF5tyU/aZz0TkPZNdaMrL7p51bDgyo9fJr gscIWcHKAblNaFDlIJq2OKesoFR+mM0Ghg6V5Mnhy2CYq+I+JFQVFPDHRRyuDkibiNeXlLzq32PO Gk0puvPdztuo4kIec8qts7BpVOsWnoY0kkyuei8sLkSriftvry3wrWAiOxgF8WnzQULaFKh//OrF //ojJRty+FSEUfqglIVIq7jJ8Naf9k4IT1RE6YRd2KkYUCbqVqSe1nAE/JxUvF+nELjRWAYfd20w UGk0Jqao/Zx264DZHmCk4kEL7aF9Hdqz45eVvveMgLCz5KPWm2K6Pmfbq51Er2gQd+JECSYLrsNk q7Z4s/5ZtUh27pQEaDubi9Bf8Bxg29ethzw7RltEAp7yHKQ8xcIB9He7JCM0MIiYSpW3yzqK7bS3 9tQtAqEAy/nP/qB64f2W7vc+HcJOv+nn0IuMqnikMrnI2QhR7CmXoI+ftznDmD26sgmBobRHPWhV xPC2SUbZJPIdEPkY/Fn5CC1VokMd10GbOVLyIlZrhFoOPrcO16PZF7YGMGz9M+IGQWR+aT9Hm7u1 3BJPmNdyhH62zFPYnSz2Ekr12OHPlIti2/iJDr79RDeGC+ippU9JW7I+2aL+AXuIkyv5YLtwajHF q19er95kFei/uEYXwOy9tuOKgFf0iZtKdSgYKYyngxO1ABndCTs1J8Lt8Wil7D8X6g1BTwPy1cQt iygLfKpWSF1EYoNsz6rngkkMBy5zfIRJjJKpBbTskx/Vjmi36ZZTYgnalimbI1LC3nJOmpLAVlHX mYs54tUDo3278ClgYDasfGrw0S1/Vr0nh2b9Si73zdsVs2HsBx8Dn0+BIyvBtF/JUgFiupfDgVws mX3Nnxa/Ww6cEiUAf8aajf5DELE/N06bGUZa5h5TYOSpuGGXmeXZdQa9NsYDLVSdWbh2HB75Deyu Ozt5YL4CN69Npt3Mxbm5bhLj8Gs1iQW7mMT+5rpzUrRFks41pxy3zHvk/3ByxFD3zU6lfyLvjR7B RdbBlw7wIjG736D0ETtARWCKL6/FXCwqNyUbHCRCA7bDZBPI/Ok8kM/CiAAl7NUfyfOwz+/f2yak FDteU5/GePU7bU46DKgt/nFniAodEpN2myjgtJwUpULWo2/b1mSBzSyuXpR+isx6j7YTDDfwV70X J8CS81FUC/pEHOtt9Aj3MUayRCLICT34PkKTL+AMwzV16iRlR/LHLzsAydCv2Bhrg1FLq2PcteVB +7N+GdgLH86ENJEPp4tWqs4dx4WCbFgma1lMqDaBgr05d3ls2maQpcT9X4popwR5s3bLxKdsfB87 WYVnCZOxhjprCYFSkUqAGTpuQd/3/LiZJUmCye8Y24I9BkCTeq8e9muNIiKW1wxgm07y1ukc+D9B qQ9zotNl1sxtMNn29rZtlLXl+IMaYNBCteiE2Bz+RMH82GZuuZvjgTKY0sRKCc2KJSj+7fgkEiFx m4oV+Xkz6abIrV+j8kxl9aZiISYNnCH9brERF3OZVyvGKaoMKHBtM9MfBSMtzoR/2T+DFrNbSolU AnW+AoowWDiAd2u0LGJCGKYq2slUF61sXWRa/vaUKlx3SxeMxBYTaKGsiwALGR7KogCPKbnJsQgv 8ll/uDYA2A0oAMzpDi/B9jpVEeKCaZ9Ne88nBRmzOLW2cK/ZgYVouZ4MLn9KJ7zBHU9oczongxKG 8YZxX4i6JAcHyAHVTeGOpu6jxehTR8PKuKu3tfClhycWenZ5NL4vIQPO2mmubnKMAMcYIlEboRs0 EA6l58G/uoygGX07CqirNAoPf98MEKksYQY5NrYDL2XLg4II3L1vLWaf+cnheo1NLBZw2+Y+PAUa YwRrJ8iwccgMRZDpymTwUYEDxyFtgv9C8V4R2U940IBiRm/rhQYU32Law2ymaDUP6igeF1AnkUs7 TPxon2O/oOkXpujIaP5yWIrKnnwBOWU7BalTaEquEGSMPu/Mft/j1zKHJH82o9WWBwZSYkC1BncV vWJH38oa1lLniHBFYzd1nYYYlEEttJuTfzAit78ytkRJTKarE56zQU9drM83NgMscpFKQvSsYViy 01ydd0sDW076vbKZAH51vKE+jvs8h+goieDGT6jT0x+kyL8hZo66aqAi29lucKXwaakW4Pu2ENvF N3yUuQpFV2S/Xo+b+xiGtoaTzGVLdxI42xZOgs24tUYNBvGAzsOOdiptEbk5WqODHPPdUaHHFCh3 Tjx5UEyiNSNCGWJMlHD+iyZneehRTlR6ertuijvw9uOUZxXAMIbaejNOcWDI5gLyeX9su2lSPhlf 4tHHzWP0xvyhLa4Shd4AU1KmFENp4w3jllsT1YEI4jxOIQreiS7kfoDbg5aCEUYwOx/zuQgjW/NY HuOBxS5ijANAwads8qQzTa869LYucWXQtYfPagwAZ1yqNt48HPI6Pq57VS5r7mpeh9T4eynMiK5z dFUIcUYKykKzeEkAKiOTe3RWClL/2OwMZe6dqfA4VgB/Cijj4K7TmGvcFZoLgM/Bd98lXO0w7Fak IsUiUA1IubpZOs8CTLcwaumy6ArGSmaFbZC2p1LIcL2RO7NkeqIvynkgU+suGc0Rt+E0xYOq+twa wXlQuPwIs/oA3q9/bwzLxV3fPJNoRFnXt4SMbo5WTyKBKVJQINvgq315iPXU/EQh7TgWUOPmzVjK uWHNSioN4WL+TQmK04Cr+NC4wJlKh/bl4zS3PiYMs0Wl3S+J170vZDi4ZcDDgxuIUbNdDPYhBaxd MHrgEqLxivDv+eZ6mjxDiRKukgvXRQNnPGweRN45UjI6qdW4TZ75uTFDkTMMXIu4UfNUbOiZXZ2c P8ebsQfTxTsS5QIaNN+9YsUilj1CqYoe/UaYvWNBRooljIW21SmlWfW1dHa49ahOqanrdvQmFXg8 O8FCxu3bilGnxk+WCc7pN9eY+lZmN/dOSR7xVyafrBazIjtsFWwvZ8kumS+2pklgxvPsnaLEdiUK CgaruRPg5mFpn5+W5PRUFE+L7My5XzPdzxo9YQyThOje1cBY5+CUsCrylhLFKYfZaVle/7UpoNEZ LoMrE71dpPymgGIzLU+LcJ/xW24okLKnMPsphNwZYMPsQKdi4XYq5wiznZLLp9Iqa1sft9c89x6j VSpmZtwkK2hz9aW3i2BPcwodheLTqJXLULxiJJdfyca6HMlZzYwBXdwkHG7EYeh5U7/8rbFMwDJD 7OJKtgSr0eU2Mo6D3O+7hfUPwF3cTC1rvMVl+lJUk6Mr8H85DyKsAK6KR2byKgQeHWgJvYQspJnt 8hH3QHXiMGdUD4pIcYj1pOp4KSqQTTZlnIkVqf5kG3uY2SSs3xYCcvxf0QEImInpUPvAo1CT07A7 h1v20CeLQVoLHxSrxmiOETM4yPP2oo0qsRG0SI+zVXmwaJ3vbRbQn5+fPivqduk6M974rk0jZC2h XwlyHGp6IC8+Kddww0LWGt+tM0paRY8u9LfWysjKePftvK0q+u626FwtWZ/IIvIeLsTYioQ7Vu+A JH0ebBDQ2FgvgfB11cah5YFoGnRGfeI70r0JSvIl2QCCujpNHYaLRdCm+pCig1OHLooRNsDCiUjp QxorRkEzcmIQUTonNrUel+6iqXOzg2MR99jbcYN6SSbIhRDl6ibBHJU3CaZT37hTBuP7ZmM1m5Zu JMOAwpKjtslyJLgcqyN/+JdVkCP7ROVKfUaxy4DHI6VZJT3q4xITmld9s4ubvozX+flJ6yNij5uS MALS9/REtqVOLecHB7OJWO1UDNtnFdLpP0oPylBhBntCc6ppQALno41qyHN/aCJKsJi0eMDlt6XI 4EfmcmvwUjywGNQaKod1aPp8L7kvmh1+uQDNqWoov9gxJNl9JQtEPjXYuYQZroVH+MuWfwXqM01q 2xBupsNBrJT5+uUthCnkyYS+plzCLNmQDkAGtojw8Q/5zoNqpUQtrqPEx+QAsM9YLgH4+YGINy7C sbghu2OlQslYjq4aazaR1ofY7XLEzh5zttZRrF48q2Bwd1f9ZrQAVW+ZmhDTsW1qeweSkC3hsB80 oQGnmXkS0DtGSdhg3vOsOoMKs0i1NXtzzk0HrQN0c6rawJEg2cJeYfBih3zgOoofaiRJpugzIQvr 00qaBoBT6iQMVZXkJDQibDSh0QuCAihZo/OB89pgV+uMUM3ERQPQ0ffqAAyBpVEuhxo8qrZgwBAi LY7v3QZqRDPS8zb3UNDtXKPpUuw9u9A/FiRSHPx9ISbkkeWkU3mZu+qkezC1Yk3YZJdaARWqpDyG sOxAJuUnMhxur+Gx1wzR0NkQa8LqHJZKjBjzQLborUhYNZe0xkheNnd9LQKepYdQw5JW9ebMuNtp tGS30OqhYQZx5CFOLdbYesVlPcKWHnO+ZCd42bElib83bdOPgqgEr37H48+VHaiJzAa/BiFKSjya MU5qK/Qkh6lcTlfgCNlF+ECd+xzi3b+mjZOlGRRQtYSInCcpb6iakOtAYs6LY6nChi5dluasR1Tk rMy8qDuNAuEDpg/dYWhwZ1WFp7NRHWd3y3sma+Dqc1LnKc2dCiSeNvORjhLPzaKPUT8nML3DMMxH RTjVLlJnYClYlcFvVbaYNkyybu/b6zb2JSpap08SbUwMYmecHDC0rRM6J+y8g37yEZnVFvFkOZjW WPMFCMHm3AoNQLlG4yjQipuAsLHJRemC+7dCdPB1q5lAR3EgPa+4oECgPxj6EcJ0TuSZHFHDroEO VNz56nGxNp6KMd/f+7mTfpoDTY0zF5SQjGHie2FadLvFWOujEavr+7UvYgwdvDa9c0VPKg8RHZQd M2VhJSbnCaWdVm1uiGlipVeH2gJjjYAhV5uLRlvQwBYG3VIuziPVjkAay09SO2ILE/CUnsjIrDZH iYBkw5jyXTXhX2ODDF+/GnbboXLch1i0SRJZr7o2OnVaSX9da4u1hapemrtlRpHL/a6zhRBH15su 6GAGwKeqQx1/ui9Ha2NaAA5YsoJQz9QpgV7hgJ+qTgn2lpO7+vudglbVgwmsxQECEErBWK60fC20 V6PJZvaX13jXxjecuBQ7q0ZdGpQ/aa1BWjyWgjw3YYnAOBusuZDPGPPXJ3ILBs4+5rLhDrzf5XTI n2DaxsSjbBl06bLxMTGrWKO4RWhjIhK5NaoOEtk8ZfWM9EA7PpQxFSkpKpmCaD+16JwoajqL5b3O medPPswV1yq/gyYyWx7vesnMur7E5B9xy73r92tllUt1dpU7ESB/WDR0qIEyMNzKLwbwPjjVOpsk zq74EyqHhNsMhpvt5Yb6cszDEQ7m4D6qaj9NARk5NJ9ayy8oOUe4KlysNV3jwK5qZVYm1DqzL6bl d/UQuSuxhnx5p9V3VqQ9qbfTYJcF2DN7reL9QbHYglkcqWUntEIKarLyRjyjuSjapWiFRwo8FgFU e6/WzSND3+jmww2Dx7p1E7MEZq22tDYHxUwr10TpSAMTQ8xRhBbuinlkEAymmbiTN0XhjGZrGMVc rtBzL6S6b4YrXYg6LKMQFB5H9EsS2TQU4u2LnbNZwRAWGdQj9MsbeAW+C3s535fZFNriQm/lx6fR MjkpM5bXSw/e9T3AdJI9QsttZPVSrYfaycn68PtBkwzLoA/OkKL/A5V0yQNnwfmDrVCCUWLxPAnB Ggc3N3U5TaAX27lXkTahx1Bsi9J0Y9mdI5P56qc0oSO71Wuml7+BqTkTFK2IHtyJfKvt8fPW8VzU OKmTplzJBtAMuH2JX4K+JKbEiumtBQhNTEKG31aAEP+smRGU0pWH0cmLBeDGzWEyfvDWAKbMIAj/ 797W773N+0/fesg242dRX0t2LE+1FdKABoVrfh1EmP0E4kj7jOQIfLLL/691kXmUJZVzivTvNLK6 klIOoMr+/DWliAMx25mbbpeplqE+IzydjcThRWSoKMIkV2DF450qyIu5ATSa8NpNwp2a8xQrEimJ 5+hEtLM568g5Rg5rg6n1m4Eo/3anIx202VqbDi3F9acL7jNArjCfOolw4Ar6rJvfRrSYFpsR7n/U 8J9mMLgYDcddLJfgYi11mjoLx6r+5d2ZLEZxbSpf7v3K/10mT2aBuLEBILxxF5TI3gQoGyfHCiCr TTNgZbp4KquuTcgoGE2ukSjHXFyMKUX6DbnWeuZgq8531soTnfa9bmPAN2KE+np92+dtZKlMao3S H8ukYgVQS4KKoNVUknLX40J69RWtKtVlboY22czKmpEGlPqY/XA7FJ6eVE3YRc20Zp7BbkUDpLpv dwnkcHS702Iyl6Ntjm6gEBCcdtygSkXdp8SjR9cEOp2LYXeJ31W0Po3nL12+kItB6KrN37NIRBJ/ 8QOpMZQOawylLnDwf4a/gaSrBTPO3WBoa2jQifqEcpEgLlKgKXFwbPktOEh+IvHrkFnGoJgq5c9A hl/3rTPHb8EkPZAidfwlP/nCIxM+tm2HQz2uSEJdrzQoo8phcjtC7G9H6C69qrCtlsByzyJeMuPp 3Qh7QGKp5RtP4A+Fw9MXKYeoRUuxTFrRfKJPcrdNHcQbJUpPAD9KoIuxZSW0+vO+5cAh5CENvm1P XenNzluLu2VL92tJ6oCMWSAlGeNbnV/cIyPoiet4OH83bzfk1McfyOPWXZy3+/uUiLAmLdlil8HX BJz6dD22wbCucrjVXaRwuFMhGfVySl48Uv7+n8bl9bGNGIw9SLGvLXiDWvG6ZSn3n3a9oHQ0a1fP 2Agd63G933ddOdsxeZh8ALV1HRqYzXjzUN3SuH7MtbHw8cXAaIx8ZR/kx3xskcaa12ELvFgL5y6H TIlNCeb/jwXHYci6FfLYxeksQK69IyC5Smon7omjmzSA+y2AqeWkKOrQGR/tZfJeqxF7terwmIZc K+ptZYx9z7ow0QZ4/b+iazr5jg/+mRFKLWfsLCVSQoGvxTOkDO/54utp6vW6XbfiewqJEtPrwNmG q4xu23g49HIm0WjkfEoSbK5L01XqqSOTz+B1T4L1HV7X7/F3aO8inmcu3cBLoHukgfVg/LNuuLwc a6UIX14oAAc3SWNOt62Bd+mJzqQGKwfLBvlp/0l4q8xkiDntvs3NljBIUNzwT/tYnDfjUw8K4IWX yATJ+4R215DUvjp8rDYBxWx8eGtwb9DsDIagopbBBVPLmNnmtUTHGFfQHpEwid3htSky++hk3Nq4 B1owt1nKQd+BVsTYvVVE1+6aDJ+Lb4UIQW3LcNrkKRlE/aCX8nbhicj25IBFLGewMhbuLHq53ByZ hHqcx4hIs0W3LBa0ySq1aGTdGIObMBclauBNqWlJyeGb9QMarer4qarhPLvPfz8lmE0BhQ19EWUC dsnyJOhpfdcfCz242CqCwsI2da3/lmlfXAbia24rzdlLOEXYUbF2mZBI11jSOYJ0dUWDbD8usgzv jtxiR36Sp6F0cbM/XoRc60zDWZfVxh7pVLgh3NLRkzWrhNLCabIUjLU5FOsdvdot2yS0ZIiv6k9L 2RpKBwpNrPcvpD4muM0uSSmwA79Yo2S8wlPJU8arahYSvH+QzTyXaNoR0mIuNy4HvCDiy6rvIu5W vvhlTn3FCLFto6SQPUsZZtOAzvAKIde9h/5ht+hQWIaGivq7lTsMBXn641C4/ph2Xg0B920ypeRB jcND2C6pNbsBvh/7sBrGco1CBrRmgiQOKlUTnnC/s1/SWr/DQQ8hTIbUNOgBBFnK4KuNKu8YRMdA m1rEDu0FAyCTxSjD/qsMEUVHWYy9FTUMmmo7Too8FLPN1PbAJDsWXF2BTNuk1VdkfEkqyPjYpueC JO3XyxKGuEGk4z3RmsgU/EyW2mJv6ZQo2MFdMusVNgPoptvxXdfFfoZRr77Zy5Z1skJ+6e4mOuYf Z0ux2upEpwnogN0nDwxZFkSaZ76+FstRvaRgQMCVeJRNSobYtt7itU7DUdfO5qyJpOGr6vTUkTnR rISeUeJHbNFY5jsoFQAwqqLrbvn7frfysR0UG+etiNhZUxP/nmsNSm+EmxHbMXPDpHzE7zCIC2RM UnOrZa1Isb3KoLnPhQJFdE4Ki6Ru+Bo0h9nXQyBcfXp0FrimyLQfoiL/qbepdCLuYxsh+y0Le/Ud VeaocQ5Xy9nU8ID19SVXPtiOheD8inOaWo2vm+Q0giekRM5B1rYk/rilNwwGOdlMR6KtSVy1HG00 pOIxDoR3DQZjafaZM7hs7ZrcGoFp1WJrFw3oW6hpfoD8SFjubs+Re6j8wDhPbhuX7YDDBz+qQ3+x N+nNg8cvinqUlA6I5n12yWo7EE8JvpdzksUcTipXi4v6Ua4vNh41G7TXcal3Tlis8giTjAZRUbOJ ZtOZZ0Q17N2S+2WtcFaf4Q2U72jFbGbva/Vj7naqWVw2txQ0TOhims53WCQhYF7Upx6lUutLO/hX 6wfD9eTt7x3/rfMx9rK1Z1xdxWoDHq2Te8OYaj0d85RfgY1uDQtsmanbHcHBHd4RHNyBi069JLsl 7PbZjfgUY8+wEG+01fDysDC0MyUqcJByfIPkAiO2TZxakjWKHBl194iqrkO16lw2Yz7Y91r3Mw9e TNxF6/gX+PQ+w7qjrlc2KVvcM/4GnsEvSEIO5arp5sbPAMA6e0CXZgot8NJ6WV1ktLDGSJKQZ/nu Ui5r6wUKibnuCNJQPs+zXqdLZ+rnWG9N54ZsXDQ6v2RYrqDcywwBLa9zqlFJnPA7/2B9cXk8Y4xr fRFNN72tASdqIvcwkc17L/5kZLiyIJu26JSPAgvCPzNBp92YRBgIstCMpdx4ioLMbS462XAPsIBx PGFy7GtX5FRLp3IjlceK/llKRVkheH2v2HPqEHZ3pPj0rWOtaCGi63EprQvFEM39EnUeuXAyEGd3 ypCEe2B8nx+zbCkVpELQOSvMLYdQnYr8OLA4EqAwHv2SvTlrIWRPwb02sq61pwNo3T49SOWqSYQ8 TAC3MmV8EWOr0XBQtuqjaJV2vig/UYh6rDZATWErZk7AyGdQE9CMgqG8+402v7i+ibYG9/6m/ire JuwWZA4sCWMo17//XV0FhihL6afIH+aNj/xhw1vCDCL6P/bSq38NIxjcynL199tgv6ozMMHQaf3q ul7PnEuUtLMb47DeM+4blpP1mU6lB7ZK+rVql2qIcM4swkj7vV+GituLMB3gjeYm1tx9RzWoepWq c2mhajEfBb019M6iexTHGxe2Ky6+KBzluRFB1HmXENRnZ3pZDNMs6cipvC7kKYy/B4mgJ6tdDGcL PDl6+D4DryH58HIXa+JG9O0u23OlmHDsWVVdFOxJBVenfGJ/2UdFhSJnx81FddI+HBxjnajrYwOA A2BRjtib1LfpEbPu5oXYtEnakMyn0/vryFuq6hgTQ1E2d+rLxhv6BSsuNboaWTLKOW86jQWfa+UH mWyUc17vl9GA88smT4BRU2i6+PGLon+/XSYzFJGrfc3WE8mgGMFPgXeKWHDAuOei15PVfhP3xdUv 8dWA/6dHRNUdMA/v+6+vLQbolOGClv5eBCXl4QnSm0VtcLmN3JUecwxOqAV6NFrHwtmLVj61y5ox 5eWX+9PN/KtFUL5a3ecn0gbkuxDJliihCQIm2Nk53lu6YinFWovCbQZeQtJGFHZJhT0vTYgCCSDK YyRGM3AxNiE7kWWb+mq9mgdrRZtbVMSBJvVfrzvUo1h8ttoHx9rJVTIb1UZDVqQyZxHkf9q7lkNs RBPTkS8cZECumrQiVJlJFRoX2EQnF1U4vjBhICNYS8SPwvTXaeOMSmYQlPjOTziAtr/ftxnn5HUm t86BMrPf7oDqfp2PVCmhR3tUZ/2JjkIkiKa+4kQLt9B26h3OI8erI3PLsdvx+37rBtoXdFktPuFE GkMNqs2Tc/0Hf+MAeJjjS3sA/RxUjf7soOCHRn45gG/51Jf8MNE9tU3IFi+3zejlqkGFbWece4Rh ayfjj8sYRvXs9FFbsOnGbBeWRc2CfPh1t94+7QmuabPxn8GZN+s7UnL1ExtRKEKoakPPa7HM6dxV MasQULuyT/MdoFxCRb6o9V0Gij4b8NjHfB2yhi7vAeeEqfAHOmZEp5x9lI6JfWDFjIsiSw86bpv3 UFiwJYKZfJQIZnKn8cq0dKZcMGWqAe+JBj7zlxX0LzaYmp7tDb1+iIc2i4/PBol5vHXuqEoe1o6Y t8o60S3zOGnTJxbScdKHFlwtfniddM6dizUAzPH5MQZ+xgfFiXASw71BRPP5WWhbDYks5B0qX+Re TyJ3tW9OlEBpsboHwviJKuKLMHkNheYX1T9d2K0Yh3eYtrd1cLuHW/8sn+aa6JXtAe9bW+wC+pNI dndLQld3QRBLQlsM8kMAJ24h3sdxeRZ66sjqLhuCpXNM4+1db9sFAMiEDuAXtojuUdqgS3YK7kQl WV0bdMlg9t8j1MHtKZJrAk5jOl2gMkJTORFOOKZ0QozqgX1b868V0fjbtqq5S7a9b3sOVKbJeUJw J+L7L69BzGqUVEXHSpq2oLKbMJeaDvBy+RkczfHkfndJjTvhsF9GwWsJ5ZJYdP9kheBu6SIefT5h Bu5rGQwnckGisItxUjWWzGBOaaauMI1svls28YgNtA0Pmp76V5s/7b6taGamjgMzJ+4PjwpVsTnq g09sZt16wOo3iDV5FhXWmIk1Jo/ymd9ipRw81sHKg4+xHpAcCUbCvOQ45ts2Cc9X0SnIg7XQ4HVI m0ev+9jXif7v5Scc4eoeHoyohC6ft4V7AGvkqRI9SB7X9wyAPHf1m2sUHNna2WrE+1I66ROjoM+X eo46w6OZE5rkSajokbUV9KnizeY9fchyJUeodWYyVrz06WK1loEqFdGE9sTkp+iPrgT0CS+/O65W uscVgOzpbxDn4lSJU1oB+WOKa9SZei0a/6FhPz6FWnakc2fCGMkcujOX/VI4XAd0eiqyWAc5bjT3 5YhfpLll8C9Mc/Bf4EOfRyPhkTcUbehIDuqVayR0mBwJo+a77gfcpaxXyHgEhoFGgh78eNmwfqCI rguk0yO9yCbfBzvs6hkCLOgyyHHh+6V2gBy29NeDQOzWjkfIPgqxY5mBHB+F2NHgy+8FfYTHH3sz M6Ojc1GDuBJTEgXND42t3ApCtMpZofp6V7OJEtm9TBkp52l4KfZWipa5qSSJHyjsOLnieYRKIzmQ Zvs9rR+uTYEPMZQxnXppyDjdibD6y3de6LO2IVUft14WMKR6c/zL9hNvXb183/jL9T0enjJ6/+SI 74iG4dF6IoVZ1GEcs6YPWYlHysSJMPuHhQJzwxfC0nTEdGH+Tx0RvNS/tBHTQyXk/LHV3eS1CYR0 kEojPB78Zu2W0ajCsj63Tkn1KBd0pF/OwaL3x1xOhlKscLrZVxxnKMdc6VWpaqGaBeoaoXfNbPpl i75tP+u1RFiriH+elOcrEmJ9c2ZfH7P64N8Dj+v6yPa6UarHyxh2/igjihrVbMt2Y8vRl9FplTfr EFyc8xyWjXSUvJTLBW/0o8bibKjQnLzVFyukiVBtMyG2Gmpcb9+6fr5VrXu4bMcqcubQcNuGHq1Q PXpTinWp2Xhtk7bbIM9n2NX3XCtfVHeOIhOFkZ+L4WvHZtfbAub92lqsdxW7cvs7tS1/5jY+RSOh CEgSwRgWBRoQFg6oehd6uFgZeKXfU0IaNmMKs1EQxNulwXBjKMx4V3PW8LzWl3TH6yChFlddDJQS lTSqN+v6T1aRwsm5NAT8Grzk9MgGWBeV+1iV+jhvt7CsE8WnPnmF3Ld9U6ocruY+zZv0wHzyrXyM iuGqw6aLoRtzvhTnFBtFDNU5EOVyORrRCHoC2YwBhxgv+nwpqRv7ygS10KFvtzGhKyiqZvzPTuxb /YS5nDStnPIh+eCnHGP/LeLTJBWJ/W8wUczN1kwSEORgStG/qIl0jPsPsUpGOZOFdrIw4dB/i1vP pHLl89YxpnYQjEQY/XHZz0Zt7+Xmd+v5ZAW4K9KnS6WA6QXfF7uDY5qwlNlFveXAl3Sq0q6v5SJ7 wz8+nW3WMDAJFBrFai88jkJ/QFMORbiDqO+541c4vQFMYmcuqtVDn6bAbR2kmC+AeraflDNNy4gh dZE/7dxKeJjKqPAxnvywVhR3c+A5m/2kF4jTWqqmiofdYYT+NaxThUwbzitmq1nSFClIVLKNA3E+ 4iyIC06ilDUOnu+u3Koy7kMh5db6+TIjx5JoyHt3rUGMQ36us27K+TCsAVsE1S9L3eefQdFD4w/L qXkpBeXQErgrgDBHUq0AFxCD6gzeqjPK4nxT+bBTrvKp4dcSctJMb8PmrAzPZawYljS9jJR3Y4V+ a7auTfwOOewriz6dTQnMqQY9niswn/NUZt8nQmEfg9ejNsbKHE9V+QxHwbyOX+z9dXU4Wot0ECmO LXIJitdAhpEfliMRS3IJEpXnYZ0TpBiy2hn+/wYfYzX2EykpGiTXTFJqVdY6k+KVtGTJq1ciBtt6 IZzuR5Ej0Sn93H0C42cuy1JmHIcpJ1TXhyj/wYc4VtfcaxQxbyHGNLlC6/b4Jdz6fyLyp51JjH2J m4VmzqE8ExOWRT7j/ySkKaeZv911wY5g8bHt40OICN/eO3JRUlWxcHcmL3+9VrRn6vEyxNPUxpEF 2Jt1aPW0FdBP9QK561Xf5PoJKbd/J74mFLItQrFwSiQrtGnlflbodFTYFbTGUc/kgglrluQkXX6+ mAJaVZOUFCVSCR0b6q8MIWyn7Kd+LlPisT0PNm3i/PEyBDnsTC1bdtkCQCa69fG8zRmDnYgCSo5V UVdIOanjjlNPwYJFbVSl+kquJxSh2y30encmnasnpUfKF1erICu2JkF16aPiW2XbMAc5U4QgO4ym CnhrVwp9lGXx0zyzq/tadTHvCtVOHlhdDAcL6Uy+yMNTyXDjcuTlg+W6Dd+tu9wXPsdVp8gqh8hU 2Y/s0anDP0FFbivzv5w1s9pFu2JREfPZPAW/ynVZQrdbFZWN0J4vhdK9V3KhH1airCtgXrvuLXeU 9n3EIsBaCAPB7LJJkmzi5YzDakeA8fAi3t/tjKVSedptOwPCOkHltdtkvwiVY99YKOuont6OemHD bUKQszpmktsgbV+DY/0z51PypW9qfcWNOA5drkL8zvaTXIojuFz7HelcrmteyCt5UgPKOKxE08UX Vdjme9V+wS8PkmNUAfwkN9nsNOvIuQ/mZ+pfK3qvWOe3VI6kA79tYEVL4eHYYwhkmdzn1j4tIDvN wOr6KtRYsU4N7K15TFULoHiOlSCqxd6dvZw82QHi2QFyUO/k/KzoiWoyqzdR23qDrnoF8vZ44MWS b+8E88ARZ17h+Nv1KWO13ESHDUrI9AQfmkaJXQAufkx5BTwKvKXigMpxkORP1Fc6nYJCCXpTEgum wx8mMWEL2LB2v4pLWml/VPYK0L+VYgoE7zT2C7Mb1NNSalrPZ8T91i1Qju2+9Rzd8f1Cbaln4gRr d2lQAaGHFNoVaNiZK48LnsQxvFGCJ9cpKAviUqudjVR9YDWwICB7L54W/ZKrjyRO6GfhBSfQYRGq Cxb/jhBSVgmVrF/Fz/S1gvRky7yuZ1SPUlF3Ep0wWBRLxmJd/jiuD2/TJUjr/1QRVm8foTP+g9hi WqaT/LlatXVns33oeM3JBwR/clEwSByulSP00ZW0eNoaPD/1hKcI8921mFqINCEnucpih8pT9Sx2 jhZMtojxMIMfW7ghZiTVMoFqPLzCpulSvl2SYA4qSNU5B6docjVXJAJk0RDa5Usj9MiLZd3+wRu2 9o2E86sXX/0z/PP/AQu7sfRlbmRzdHJlYW0KZW5kb2JqCjE2IDAgb2JqCjExODM1CmVuZG9iagoy MCAwIG9iago8PC9MZW5ndGggMjEgMCBSL0ZpbHRlciAvRmxhdGVEZWNvZGU+PgpzdHJlYW0KeJzl fVuTHblxZsTuG1/2L/Sbux3dNYU74Ag/SLZsyx5b4yFXGw57H0h2kxyJHI54GW1rY//7ZuJSlbgk Th2yOaNdx4SCR9UoAAUkMr+84g8X6yIuVvwv//v8zaOvvnUXL98/Wi/+Hv738tEfHonY4CL/8/zN xS+fQCN/EZZgpdUXT148Si+LC+3h2SovnLTLqv3FkzeP/v3y7ZU0i5POX/7xal3kqlRwl9/DT62U UO7yDn9qGVS4fHd1o4xbhPWXT/en7/GpWfC1765uoAsVjJbQBTzWi/EOhoi9OR0uP6QWPqjLV/vT NAb0ItMYdpHw2ntsCw9hHpf3sbEOzlSPSXd5nkrayzfwUwRlgt4m59Xl673td/vP31+JNf75Ls/X hsu/3RfiN/GntlJe/suVMjCC05e/2P++pOkKePrrOC8NHxHKx9s1wGtb4zRFIdYycb0KY5oXt0V5 QR5fp8+Q2ldvVksYW2j4pG/wKeyCdpf/tA/+FXnv8ajF/3zyj4+EQAoJF0++fvTkL//98oedDMiG 012G7ZLWLCvs3PO9BWn8fWogjLp8RokKnupFSkefEjr5uO83WZJbfA1p19Kdf5s7m5BXamB0oXav e2qPgxEqyp8WYPnJxMhsCEHdb09xFb/6Vojq/Gm7BAdH8MktHDhCfNWnbT+/Izv17krZxa1S0DPy fP+ZqUHa1eb5pPfutyZpQhU/UG7xsMl5PtfpO70ylz+OJ/F0X7/yU1WzqM8vUq0LNaXS7v5LpD6r oMnz/UQ87T4qNr6rPuRGeL04Fy5ukFKNTF9AKO9VS7GxQzo6WXM4vEati4HRn8BTJbxxinZBKR04 iZF+8dLQHYxPXSQS8pQwoB/24QgVvSNnm9Ds0536yDQ/4BhhsUo1VI/zWbWjbces9i61DfD02ZDr kr18um9JOoRWViz3Li2as9Wqfkjr4EVFDGRiZDfIFF53Ox0Hfp/GsNLPDuxAdGTSK6zMSFVY2Uka ISLvZcWo9OqB5OjwDIXUHwPvAaeCxUsSxnhKy5TPEAoZs4aX2BesbaBN+++2zuiyU1qstiHTEzKT 8MAPae7wzVQyEaFIe1uwMXAP0x8hK8syBJDmdBkEbGnwHrhU/rOkn8Yc3HepsXcVBXUyo+XSt2n1 wqoqvrK/N5B7tfxSZoWNrOX0b9JjGTomAWsI4rBwv/SYEMzH/ef71IeH77wdbuyBc73t3y12JoBI DF0/slNJDkhZCaZVLUHJIgm+uboRKuDOASyAFwXAQmvyi/oChZjyJr4ICE0bBWwYEYcz6X1YIOeA BhA2wetwhJUbyR8gBJA24aJ6+avts0YzlUCOwvsy08fAIPwiRZAnZwrYQ7uTM5VCcjPVupnpkmZq QB4mmQQ77oWGISRuuE+t/hl2YXVAdnASCT39fixim+MebNyFAQ1lPKODAbkVLv/jkhDlq/YMRcqg LOFVfhMeE4p6kZ7qVZ3G5/9xVRpXnIucvWc7J6EckXCj5/kLJc8V8M/CM1yhkZ44HdV9j13UahoO Bo/14u1DySicufQ+Hq2bSDW+QSZl7Z0oixiJgHaZYb4OQIw3ZLZEYPW8ngKHSB09vtLGMpCce69C uTfKAWDwLZ2UwUcw14tFwIKUM0p42j2/3Onnm124VHQyB7FGClFGIwhmjNZnYq80UB54AaxEL+vb 89rIelysFdTiiayPPztZPzr9ygE/CXYu7SMFUEFM++vFfQum+5WJLRI/E36xxiZKjlIxs8wJFogU jlggAESGJX680eAXIvuOqSSqjzrt831/O62i1f9rojfrCodXnEH0ArDFCj/X6sC3QOvpkA47Uscp D0hdWqDK8KCUDjrPYoLtgX8mjrgSKwDKSl9ITxVtSjpgjspdRPBICj8ii/ert3Rrb9NkvFZ0rFqh BliiQBtQPHOlAybtS8vV0SNUa8c3CkHrDpKzyWrDZs9bqk0tCHpjFHaCo/EoA3VYqXm7hEKgLVwv ulv4hqI7NpamoU58iqD7YTggKDuyJs3v82KJmpeMv4PhEtepBegosMkS9QTQHz82I8PfvebGaNgb trYCtTJguEKunlEE6K7fXiEtIb5/u2/jswg7HPz6cazVkbakX7ozlEAQu4AcXJ2veNZdt6cRjnUT jQuOkAZEwKp1sw34VDrB6AWE8m6IRvgpUuS0zjiQIdojrBcTQYHzFwBrqWWzNopgHytwghY7dLRM DgkxtlAieZ53wrqjJ2MuI5F2pPbAiTdmnxUB59YkOMufKy71d4nAdiSFlIRWboUKjC6fik/7T20s r4SzURJ9jr0BaazhYZhAaXCdZokokGdg0EDJz1EFYg+KVQXSAK7lSAD/tFAzjhRb+FYDUGhPhTPE Cr44nnCN4EuTlBwLqOVZHFqaE/YGJJBkbmC0BCKDPlakswEnBlvdF34sqHWdkXS3ufFE+fuzlVK1 ObSWUsPPwAatUjgWUoT/5C9i0fbL4XdM8H1czdom/iHNzrhK+WhabJb+V1cDoxVjcLrLBixfeWje jgmql1nFxbcRaG/Qxk5mnoyBPTOZqgR3hgiAZ6Toh/RVzgSGb1gDaMLq5DkTiwWlv9PqImPqtbpi Mo/LxorbMgNd+RvJsThk6YkLYUNHC2hS0pxVtNGGYmPVHTg0LWqO1pdIQbvNglquxr4QdKI5A3Tk znQZb8T1F1dGw46JiAWwLw8nrXJWwlON+9JwF3waThiDItb5kNp62y5G7MFN3IPw99aH+7d5Oq3s 2d5jHdgjgu3RxsBnF1dF1HoL7e9tUqB2sNoS19iO3FmBaxVWCrsIv+mXZOVwe4HXuvoQdB+79Xwj QVUVINhuNu8L9vh0CKFZ0b0RDyEpzmbVWrj6rhksv3/PQOE2bjHKCYLzjAWy0jW4fYGPBYATzxOW sXJRn2UpjT04Fh4ZqxZpQwPc47xg3DMdJfiVIjS4JXamzQxrpRaf6KwrfKHWRCI5lX2oLVF0Rwl6 Pko46feH+uApWEYL2KGyp9P2GetrqwUdiT5GUQObpb1vgQk8dfv4vkYuqM3C+sEZG0jfxoZFBBTV 8bIWbFkfM3nvNn/sekCfIpNAu78C8tCCZT5P85euPv1Ek42rFppOiUHSjCp2W1bxiH2ADlNeBPn4 Q9LhFMAsa8vZ5sUqIQ/KKm5KB1wIAiP9OJ50zFpPFyQ+vs7W6sae37umC4k5v3gXemKqLMbRKvE2 G//51q8peeORh8HpkSe9DW2mQi1r0KzACSHYnm0UOIifbU31fSfdp9NQlNSkVQjZF6Pc7nQXO/JR eAHtFREjCp5ogKL/4wr0dWfWLohiRNpjzv0hOQosz5gZj0AyqAaNSndNxITqCF9lDJ0cY+1lbGPE eF0QuZ+fmjY4pndxEWM/UeQjnYwNVkUZ0JKX2EVZOi9SDLt1hptNDiIIrFGw0yCii7FWG1IXtjZX jIjk+w0lEoMSGWFMT01Qx0o83JWaAOKt+OAL4yJbTixUZEc59Na17uwJ1xhXZJYQDLtjQ03gLr2H XXT6dOzidfUT2wJHar0d2ANuZP6lGSxTh2EYicERHYiSIDsrxeYoFD7Ky86JpauiQacKROyvsLhK daGvUYtuIy6HfnGy8YwlApcf9FrHSbc6RMfA0UAINjYplb5W1qhdqe2Is62pln/MjStUxUgreBsk WhtCt3V8WqcdezDJIFUYKpo98IxfpzWBjulo5FxTqxWxY+8vukj3uGyinv14jV/mxlJy1Fx/CA6i GypqhBQfwcfYQKeoaYORXkfLMbGMIv73aoHu2siv2FZOzA21cBr5TZQHAvCW93vBGMJ8uopYW19H 4il/NMbbNnbN7aPjT4QjjHwivOVt4QVEg7stfXnGvjsOiK0kWZRZVhDTXcRLGPCnmNjCMqeBMbSL uu+o4teEhghQQWORDRgRNvfBeDaq+CWacTBgrNqasZ98DAGiQQqwvRefAcCxB23cVOKMhenEI9RF LMzEDR9blNdnjGRuy9fruWQ6C+MzWDHPOemF6PcRdZQ+BftWNkajm/JKJdreVrRktFvQ90cEHvHl UM8xh5GYEIa71Pe6jtTnLyzTqOcYmT4GkvA+3bgEYeJCNJgeUX8GZ46InflQpYoQnva7Mdev8yUM emldE20SOw5KcYeadEF34SMl2+0nyxgo9TRxxj+NwkWeEjJ8KGYwUcLYiCsAI9EfSz56jHieZtXM +NYVHN00E+N+0eimzqaWQVIy59xw96Vv1xvNOm5I9Lrbwk/Is75pi9jGpvtF7Ajpl7uUXFKslg2d TwO9RSgtHnf7XxK6NlcfIRECvmjrasH6TKWBSWRXB+wi1vWkywnREyzPaXnOuLdRngM0EaKi4ln4 yMBdiT1grMbnCHTsYh3FEEWbGzls79NXS9iA/7qLrvpYYYMQ5CTWBltgePzYN8lwqNYbFRffPEjO kESYqyqQUgO4WlG0IvuOsmlb6BqaU9pVgBbsWjPIxgEOiG6drRY28LILKMDXjGlDQeBpUJpjJ0SA viC6Qh/j2poOpmavrj9i2uG97Dh/NcFZ6VNO5BUxMWKfGWkc0b0NMUilzZyN066Q6y2d9kQ6FlZQ AJ0JfmBlJjO6rvnrTXmpgnTpGKKlq9YwlTQRYk/oSir0bNH3GiOHkuj7MgMogNP7MYJ74Tmr3zh3 8OVwO1mzn5J+kVYw8REVDIifbF3FKj+kz7Saiz4by8Y4sI0Jy42pDHvz3jImy2fj/e+1454u7nPf VkyORPxA1ogRfa9emNbM1aifk1xowLrGdrnQmLEkG9C2MbPX1fo0mPS45UNaD7rIIMCo9Uge8T3g lJ1qFjJ9SK223g4JYcyzTkefTi1jZffRmOuin3KPN4epgebgPH3rtAWWcadOCCxtZWi0i/jUssEh rzPDUvC3zV3UcfgTCsVNeZ9TR79PHlyzA5mI8nrkydjstxTHdmOYqAyqDhQ9BHPHvWIiEMj2/6Gl u54XjXgcnVwU6w6wQ6cwoGc62uLTekADIrQJH313JRxyX19zVHjLxPjOg/7zbmZjE1iHCiKeimIS D1WgZSde9wSYAwMz+hqfW/IZr1K/qkVFKcwZls2bQU5LDnNOf+Z8h62EA7YjKkzeRNFZzKofua4j XTHu9H48Aq3i7nWe0ImmSvb/OuOSlfcR7iIgI0tf27mjoVc2/Kdgrad5RZQd0ERL5WS2jEmrjZFA FC0o92ECdZtQ+bRJqlMW4QBpNzr004COvkBFay15lwkNlAK9ZQwSsm9wWav33pQ3Zzlqm6r710lP V8LU8T1Prhwcf8yzuN+pidQ8uYtmM+cdjSLFU5hV1escewkQ8Ot9RzBSpgwxUIAdaG5G0eobqY+K S71uf9IFnFXBOctzdJvtF6FlkDAhdFT83f5RpAFhIoy95K74qt2l2Fs0poxfPXn0r49WwBAaE6tX lM1htfgD/pHm4t3LRxaXP5gLtQJ1Gn2hgB3D518AHkaDzsW7u0cv/vJRKnyEzVMG0QVAOGiuLt48 CliSQvrtyev9Se7y9f5W/2R761U3lTfkCeyoNlXf+xO92BBI39sTieWBqhltT7ae+ydbPy9w6TyQ Ybj44yNxAQD04nd5Jb79+/9UK/Hq0WO2Cpa08GTRSCsYdrTAIQoqF8NCGR6MA6KSaJ5OxbCeXGH1 Bq2QtyNnwUjiH65uDBxZE12pxtiDxNuub1hFXEuGeMly5C0TXgL7EmTxtyf9Io6WdduydipvBhu0 902ewBKRrsuDbTPIDNkt7MnsxX+ib/1U4hQr1tTyNXH+4sovAQEgCDQpgUyNuPyHqxvoZJUrYneF ncR0jUK7r3baBckHL2mtzeU3VwJLQAgs82Gty2Uz7AVmMksb9umYMh2DhhqYDTBwkWfz6yv4WoXp NL+5cs5vnfDfBFhiBX5Fvgll5ZPfHTlNLTnAAqFbnTtN+/ZlApPeg15PKKU86HZ8QAIbcbWzeDMg JSwIsbjRg9JxeTChrZ76X/x/+E2fejrkqjGhvD4dXydSt6AowfHAKjZeXP7vKwH0YQSqdQIf6Wjo AAjmvDb057vtdHx35Rbj1qjDl3c+7p2Td+6ulF+0WFGfBiAZANxc/p8rpQi+OVmm0UFfK4BbUqZR YJkx4S4k0HaQIX1ewmKgdaJFGI8hKBACjbwIDhFUpVKEWJgLUVf1GGYYMHT6lxGjATb0CRxK4XSs s7jCfniAvLTr5wXEZaVAiKCBo2RYbXV+LaR13F57R9p+JNN4vo9HWucWIhTomt+8i00ApmIUCOJV LawegOkbtNsHLS5AIYB+QJxP3UkF5A+DkjHRda+K9wvU4gQmWfSO0t7DQEx8I9vszDbSNe5sTiSO us5SweiDsM24UwpbzXa3xDGuRJAt5Pu3JfxrNGg4j/l6/7CbIMjk6wpD9SDSVUVb1OLVvshJG9Nm Deuw6hPaakOY1KdSoQzDl6fSQtdFn/yg6lM9TSz7ZJW6qF5Peh2dbK3Xwcki9WgYM/U4T/J9DiCe hYLmCOLenxvLkPnOiJ694rsSmOsnrsCNQ5OgRXTeLvasC1RpLQdCxcKCOT/JhSo/qfQw2l1tFumC 6nbXHKo+ps1DVh9D5gnSBCuC9MyjbED8UsXENLZZ0JjjkPzPIwvJOLRk4M/uIiaKBYCpwBTE5vGa HlYSL7gf1rrqDFpY7HZW2wIcsFphjUGi+BOPPvkQag0gdmxi+BznxlPjAu2DrDPpg8l12CPTEsk7 j9baxlQ0DiWmdnHcRBUl1YlNnMRHsCFw20+0/0hc9QPpyVXIQZ5cm+Yj0XTTmmM2aTA2q3O5U21V AxSIrhZVcUCsgtiWS1ijBYmLx976pW7x5OrHTEOy3fe5M9YFmmcmpWDcj33cZO8l5Cyj1fyLaRz0 lHIoyPQ30zj+uTKNzwvB0LIr1MEy883wLnX4BardJJ5Gy8V4eYyHATBbrPsCPCxNwyouhoKu2I9J mqh27XByqNceqM2chjOulZG4WM4qnuZHhs7KTZN6djOxnRaRwwMfUgMEunV058AhOPT8MSMfcgiS GmzD6qC4R1pM5LMoIV4j+RwY+OX8GQJ6e5sk2o7mahfQavZgj3OxBDvXU1PFdH1Zz7RmyFq6WLl5 HJPBJjmOJB9rxNfA/7Rri3bhyM70HkbiWCIB/Z3IHQdkjs/8XZ6Dtceql6S5pRST9FMx8XRkcgyv aGKyHX706htp/xkAd2O6N8T7mMCuU7JOxpdhjZnyTKpKQkLSSE3dfT0S6hw8990qRF2LCfUgDmiU CD5EQmZhrfQ+ZpGOpSd1KB0QZONy56fr3DfxlnEdDwTs9jMqwbTpsz1TNqHRUetSwzF8ZFM6S6lh f0rnxELD1pyhc/rGo4lwDhkRfrvzfY1DIsnHRenqYnepJphSl32A+CDWMzbWXNmr3w/3MqeeeFWn yN4o+BShZIsUY7ZEKhOQS35V9XZEqt70siWQNjqJPO2CW/vc3/Rh03TePu4R61HYNUZR4+uhi1DM 8z9ZzIqh4A6GT+TC+JqF7B8vpefm9csx5s1td18cvelFYpkD0+CFGNCoGyy+jUCX6TfpMQzTqSjQ hfVMQg+xYo2FY4nRC65BrinWsplawY73KdLSn5k7NIoedINIyXwcUgPQ5c44LydKtP9ZcaO2giHo mqJRTOiCx5NXlQk7bUB9l9jHKtgA62PFwbBuYdwIpqhgmto5yXEHYgH/NDyrt5kjas1XuO2wt8Gk d/dp286h2ZPbLjSMsTbIe1LtJdV+fFpETZgmsXZShzFtUJPAGGdVgA8gDRJJY9H8qeqxbIEus/tF Iq32SUvoWqnikRiC30rRVRc3jaPEjqVcpSlTbv1bWGho40O1/DGhKNX/olFNx+pDfKITxhGb49fb XpASYs/aztqsvJEtM3rBH8xVgusXmllib6MSMABqiAvjnPKXHPFQdBFj910quIRlwl1Vo4KcQQKV SE55U8QEO/PVzE6V/A8YHze0ET9ETZ7aJKQw4MDa3m3Wy2pSl67qOybhy7CyhehmVfNqCQk8ePGt qY8xJdPfRBoSnkE50OniTyhRglyMlHN9O4uw1Fi1oC2IWKCrBm3rXiEyvoZlVjnVcagB3u1zYwL0 +3BFIkjj47xNok06qM0fG/CD4aDNpKRvUAt69hvdBmcpRqbylqFweZqNjMf1VK1nIw2jJ7XT+3rA JBeYCcjH0hzAbK2piGis6M3TsjIqMyj6DZ8qtv3cr+lp07wFLLKbVN818JFuWiNwwJJir7Uh/l36 duO4fP7v02tYPuFZPwNzyOr83Xj3X6exdVdpr8yIMd2N13KYIzVQ58hWdRw9lhToRGKHdprqTlZg ZiNvE7IYaWvC9FaucoAtCG20HFAow8gKIoL3+IIBc8WYLrVbc08Eg3s4dqu3h8Qx6rTES4+oJs6f q1Tzfvt7bcywwg4ILC6brWwYTO7WOECfc1Xdp1koO02cSW1P2ha27W8TL2tYvWJRYcsHCjAJH/OU IFp5oF2dqkOFkfs+hdjHoKZZdm/O7z+/IOCsrlyDPWI15Z9MpG1n9a+2FlndC1Td24G3hrMlc/TT f8N3wqqAM4y9KyscgXICyI7SbSyVhgV3LUZVePVGW/w43RN+KyhYusceVuN+qswwOKWgUI2yq3f2 1XrDEO/13rBDsUisg+m0Sm6w5OrQxbS5rjVGgjnWjznO7j6CaYbn9L5sN1s+cNhH4irpiuLGO8PX jsFQQzyMt2MifHElNXInWXXBeNJYRlAKyTNAuClHGL2Q60Yj1XmUBpN7YPuxcLE+ehrNTlU/c3nA VPCMzfY6UOcJA8L8Gu27eTkVRtKm5VyDjklvWAXVbHqmQEqKdV0BWA1d6bEFce98t+OB7UW7kSCG IhfOamTJg9qrF6aHzKR/2AckB+Qd+ZQP9dnbRrxO36W3O7NiJ/dpeiaMam7EFmRfXpP5fdxb3O4/ mT5ebjcbnSaVJtgnCjY7uDtyGNSWssV+3CA8g13GwGNwkIr/oj1IN+VcVNr1WUdpfDrIhNkrHm+U Mos9dvfC8BA8bbd0iOiUkosPbBTb3Zj8GKokVPSqJZdEUM/LKahnh98KkotSE2mQdAyBpuu4LiAC ZTUumSU9DORk93QRH3NnkbxJphRvIgLW1FTde5FW0YWRep25Rpq1KCWEIg/69mqzayaLqgAQMSg5 OdbVGuuDtrHMLH9LiDaxFj+XN8vKZIBiMLVpSLDG3ApZsdoYoK+W4Cs6fJ8aG6VzNRP84h4DpP24 zpOWnu5vXzw0rnB+vCqjtheFLgI5Tqnh83kelF464dQdHvL42ZjAB/Ux4/PWh4drph1HxU9PEjQh S9qiuxV442A4nio2cZQzKt6hAoLBxxDaYWVQrrbJbX5P2FS2M/0khaKSowTvqvhf494mfC+s8eam znCRxRAMh2WSRHHGWJXHICe6Y17dcsWKof2EOmZxl8cT4jRzovtdycU8ZctR2xhgVGxve3qdVghT WM4/Fmj98DWb2mmKL5Q8LqQyDodGluGx3OSUZUCLNRwuhjaKzkGiayoaHyyGtgkSmIRoFyMWe5XS z1h5NfmpsNqe5gOzCslQ5cAROOQbcc5tSMDWyw9FvN6VH9d5O6zkEFxWX6ypuCUj+E9OfgQBx7H3 jQDDiwjX1usDP7CIxay2FbYY1UY2pQZAvAavopOPw/l0QWN1dWEqmpqNRQd0D7jjuKNrEXZIkO4G JJCgjh7bxqOSlSx7XiDpD9DihDfFmKvP4U05Eqm6NaBi2ZTDNFZlJhIvE6WwA516FnN3QAVl9U7C 424UpjaHWdQBFr3UdvtpB3FgY6N7u0l0o2uMsu35fZpQCPwSpwY2UO7fW32tpFS6qaRU5Wv1A1wI 40+rtd2GF5BPzlH8mI4NpY7+tH9Ydbwo7XQucIDdmFSzFlyDlVSEyNEZqQeiS9elHrtgo9xZJfnG ptgWCgW3BN3q1ulxHYTThUHnIwZtPSjA7T2ha+UGBS6+DiJobYrNwA6At2VsZ2UvFja+k8dK3xYh OFlxSgu3ubGuQeZwSekH9cZsi3XfN6EU3aUBlIapmI3L5+hTBha/yo2trUQY0fPGlg5O5p6E2b2z 9NCNrGZ1mGvYIg6zWiyLfTQ4v2N/rA0VevbApGY3Zqcpja5LjvJoSbMT+3WlcWVfpMdSpesZsI/N VtipJLWwjI29OLarcWVc+AK7mpbGesoOx7RMXhtDuwFdEPnGANhPrgJdawKRZ63TxB+1Ln4NROfj 0FjszMpjLC92qwb197NkSp0ZUa9vek2qsepG2Mrr8b5xQbE1iaXvkA0ek0rEEqc8wylLxZloUhdt cfb0mlac7L4dEti71JttLip5O4jDOG2NH1c5ndvJYw7MOHJhYi2Md69yo1Ay/T22VXDS3Yw26/tO s+GI2uixD2EDx1p4UBsHD6MCqh3wIMMcYkpx1l5/CaaEXcvVN4Pj09XZhu4wlteCFprN4PayMlml LFGkZ12HxRXBvg3bWozKW7XLvUk9SNk6gTEMHCqOPCTfOiUZE3D4m3zuUnqNAW58hLkFgfx2yt02 0BP7deqSsQLWJrm0GFoyJ52grO+HDXCHg1yEmpmPyxij3abchnEAdMatosemJCdlJ5bS7TERfzXk SPtkagmQKNAu6x5IW4P5m/LX2g37BYo81vYAlDxatYYGjKRRM1qL7ykTA3sy/h67cWbhwLX6ErBi /O4rOhHB62JQfOWiHamB8CG2Rs054WPF3PYbrF7ofHcxXPo6zrPH2D4ocfwwppnaoIGTg7NwkCvj nNCvwKmexDiz1fvf/Eu04ceTc1vy3IRjbC3JNhrw+j1Za4if7qAj4mEajJQ7jMFIziXYJxY9F60q 3uV7CPWpxUhxFPaJeAgeWhvESegmSvpFglZ26lbL31l7+ePT1dbk/H5HXJ/joi/At+aRsedVURFA 1O/KOFdS6u0umRNjhQcsfZy4gOWmdHgjgTAwdSH2+zc7eoUOdEA3hi5XrjSsaqZ59BHsrVU6FgVy l/98hTFwXqIht86Eqkm6gwlMMH28bUfEpL7H4xYdD5gBr4oPxHtiNNUdTtwTI7EawDinJJlgjFyj n+hL3PAT+17VQ9/wA/3i+enKkBgRsGT0T+ZiS9PgpVr8++ACwPZ4MQvB6AnvU8dWOA7pvU4rb+zE UEXJh7k+hjEC8BFn2+OpPtddgNqUN4mQ13Fu/nGI7rwKz6ZiY06GbnXXBCY1JxKo7D0EN+MXWDGS cxv/x2/UjjM4dSK2G2WQrhLJ5H5fvy9rU4zY31SuHwK0n+23Ao4KlBN5c7PPcr8WsMEq44BkrN2x 6uhGakwbelULuXB3gDPiizb0N2N1izGO8sbFxT6abJGjzuCi7uvVQCPzGT4sKmpxQsGYBgrmRQpn Rud10U8dOTIBJhHx6TUZ+nBsLBHPn4S0V1/kJBSf7kMLnwgbjOPY41m3HU4j14kGxoeuW/UpsbJM 2ZGx3GeC/LkLQQ+YS2601/GmoFqd1V7ibayzgwstPBDUIZNXbLwHp38BTjhMw00xbWWlXzWNG6Dm AlYKOKUexy+x03OUF4ZBBMS9ysgtLnqDDLMD/iGaB3EQL1SsDSPEHUjAMKmQ2k+zRLy3echhMesm Tg65ruJRDfJkkPwIJ20WlJwhw8ShvCwMg1M0mpDRHC/P2YNfDumTYUanLQRd9lcTKqwwr8x8Tqjw OXdW1/B5yDJavaapehqLW0yqqn2hPBINmMS5pqQtrT7w/fB8bfkRHJCiVs1d8x6dLr3S0ompOml0 Nzxt9ZfC/hJZjs6RWFaAWXUd4R2C9XWEFTXhbWvuypoLoz6nkLA0gitkh1s2KCOcybz6P6cIXTgs UBs+g9B/mvIcN17qZTMJduVQusiufjhiqxq7ORtvu5eY324Z4NmpoxvKTu9VPXch6p0IOSB8/sSN SJFzHHwYIlAEoo8q8pl8lh2QHs3GVf7Njoj+aZd1X5GeHtMW0TQkuXvMRgkmoLAerXQS7x5SfaWT Fksf8+slI1ZtpvztznlG5w9Ddr9QTsrPDVnjbWXatB4Yi+Gxo3jJDT9Yh8X7z8+OSl1XNqMXqTtg x9TjzETlPc1j64mFKt2m5jn2MPBbdEpXWxZkYGzb1iBaWjG+3nP6dqeKzeIO98dF16sOSpvtEqHe JNcERXVdno2LKUDSj93xl53W9FVgwCTgN8JMwynCr+tv2XaC2E/oAWfsV9y5H8fUkQ04KV4/+3jz EF0DkHChUpvv6ckcLTljfnmOvfmYp3EsYRXHxit7j+mb0DjUITWo1Aq3WD8LGYzvNUk9P/vWp1mJ efhvd2av0/ditsYfdwY1y6rrEEdDanVUUWvpQ1n6ebddM+x++4lfZCSm7h0sP9X5QBlQ8T51HIaG yo008AN1l6SmgVmYYFpKg8ZCaS55+Dq1WGVvMM3LeG4sGM5/FXV23tu9O9a5jo59s5pyx6etiJZP 0GiA17jawVlZ4J9SlnDLnzCYPOkpWYzZf1d6fAsVxh58yy+iXFGziL9ikTgSNI0QzjgWANQqZ19G 0QYS51FtRs/NJWl8JEh7qLee1uMs4q0HwpG9IWdCTscCdbTFjAfXWjYtGvBmhk2L94C01cB+dhkA s1q9PyQDUmPnz1S52gFVHQA7JdDog2rKfMpVnzRMHCv0yRkmDBKErw0TY86ZPFqgqjot2NTEuuwr nte66svpqgRFUawF4QNyP0JTdl2zZTXphnsKeNZ+jdfuPLi4mYrPOsYtuHeg7rN5B+PCLOOnmHqI Aa3KTzQBHM5MPRXYwllz7OjExpoz4v5h74KoWAOXd/vibZnGLKMcF05upeUsxW3jYxpfwsAne57t ZybjR0FLW2tm3Q55Z5qiBFyGW67rWoO1z6vCeabFIUZFbOluZJAcRLVVKwceFZB5VTFTv8bUEFQi 0ELjsG5qvNHGAJbAK8h/sSk45WCRqxNh332QWwm4f8GwXVi0VcFrNyi3gJOC9MfrGrGq2L/tDx/v P2ECVgHXV/GpsljhzSIjjQ10voLRe+1HheWQjxvCyVdSVqKZLYh/FS84TW1/FccVRlz+DZZmQ9EZ Lv/7Nuy3+0MywyfbS/8W13m/Esw3Nndttdkt38enBePC/nh4Rtbgm+3XPmtoCJxEKCnJrMhU95aP Zyt4I0D2rVHK4EWxRkxDvrQ2MfeD0bk5q0diEYgHmMKpdap7HEXWFSPHlvPTzn+OS7DxKVo7vKaX 0V2YgAvexFXpZPhdwvJGNTiWoN9IpgHjoSUQvhK6qTc1y8iOE1KCBmRuMaHjGDK+ZsIXiALMM8lQ FVWmw1VjJ+7BGM9l18XqysX4bkzSY4PxkXBnhmr+Ko2uhf3ZzTYPICljdDYySuEPFTOKC1/btPOt W0KBzrixQfolvVqwWbqHYc1juDBesQZv3pRp8Jh7JPvPuuYkXTpqzjQ4PHTZuYm7IgN03vQfv9oM EM8noLXW6TiMoDrKvkn5l2H6PBaKM5sZiISS5HBxFyQTLt6dyfyb+mVT+LlVA79rn97TrUEXA8bE iJ80PJ4K6y4FSztf3/hD88fRD+08zJT5THniA3nUUt4gW2jycBHxKuPQd+bIQXpig3AwkXKtU+F4 XS0nkzaZFDi0tZe/62xEbWT5hzycsed7BMsotcGwPJ2EG2NaqZONYTjya4n3tW9xJdepbTBtMmfh 0DlGF15SbpIB96n+2SZ6K12R0taniPVnph7XXKHmS2Q0qFwfh2CtLSNo7Jo8z4GSb81aYbSmdEEd o9PEHKIGpeyhmENYUy3323GOWYab4dzi9BZARDzRj/ceugi/1gg4jvBTdr+viTkUd/sufHLU8Aw7 rEDdoc0kPiLP84WmMzNvaiEYB1Kbtp5vXmVqCTGOSGpPeFZI8zV5WKYB5y3dGtwwxzJy6BiNVrHi xwPlSRwo8pRu3BVM1O5R65Ntq+XWWT7zQj4wB4O1x0/HR3U1ZXH2ToVBAkTHUXPLCq+2ua4xuGdG XMUvxPC945iArMJhPYnn4jgrW1nTGKRQYuttqx9El1ith9+Xz3Vnbsz2kw8uS569aQ20vNKMp/Uv 0iWIpcYpsPOmpHNdq4aC3eo6KK/9//MgD0RktJbU/jC7msV+XkqrXQFFrWZSKps6FXEaJngmKoGw BwLV7vLsZRVJeTqFj1WdLBYGCpVR6i2lK8of4gqJqvrC23a4XWgNbTnne6YrTtJcbh/vJnWLcvzO jzNtYmFbrHrZ60Wb5EzMzbe3DGkfSzSRszyr1VxWH7V4vPdsGF6wab6hZSc4Bd9+89biYUqNb6NM eAt+tDtY1SU29uGyDSHw5A7ZiSNmi6oQm4fkz0x4WKx3rA4KD2zcR7fEx3oqOG0swIchDvgTL6I6 VmXOoi9YtqsPT9U63eI8Hi8SsIUETvHbKyHQLMcirX4VT9oET5hhovNG6Y6mYEZ6nQhF9iqu+aZF 4/XaiXytdXx8CHcnA7g9YOU9L3e5iU2I/gzfsA2cKAbvnay9RlDzVveDOw9NmiiwXaum2V84CXmQ ZyTvj2BKMA3tF8UNoV1DFXGb+NIoNadBmuBvnd3e7wA65eskbMzbhllo312OPKG72Jg3Cqe/cze7 d/lNMysOr9/EQTp7A+byYZFJglX47LycGziNL825gWPkcpenYeooAfoBFUHH7gRfpKz0581ByNuE 9ZEYceaE3mUeJeVDFJ/k68Yhd7chARgYD+vYzmSIjTe0U/nZBSRvlYfj9BkEykfJxdh/MVOvsWMp mni/GF8kYnGAGIgvW6/trCjbgTJdjH/gOg23NhzoXJwfhazib5dJmjYKp82M2ZhNG1U7Na2QcpPT AQzy1N0RJl7DcITT1DgYNlA69g707Wd7KSgwX4y3OXbRDE7uXP5OhQXOEvaCr5IZp+Nav3galwW/ ZwHoBrBHvaOl2jTglPOVffo6/bRbndBjkak9pGkIBcOg5JQrQAtjw6xAMrRAfMcVSMYO6rvzCNGl LRaek2MMJTZhyA6I0nZ5RvHbjpaijK1tRWrkvDKB4GRATsODjgFMNzfXlPH4/L8a88YlnkVQDJnd XYoDREWyG1zG4L+has5fQTqLSUw6qatrxrwtijhbDIeefEZYfkg6p28iys8yKI4h8We4O5J32nY5 peVzz01EiOGvpl+9/IVDQwAn2KhwLUXC3Ax8l1V6GBvRtqRLlGy/evLoX+G//wuvHge3ZW5kc3Ry ZWFtCmVuZG9iagoyMSAwIG9iagoxMTM0MAplbmRvYmoKMzQgMCBvYmoKPDwvTGVuZ3RoIDM1IDAg Ui9GaWx0ZXIgL0ZsYXRlRGVjb2RlPj4Kc3RyZWFtCniczX1Lkx23kW6EZ6df0bvpvtFdKryBhRf2 eB4eO8YeizGbmbug2E3KVxIpqylp6F9/MxP1SCQep87pJqVwOHRYjQJQQCLf+eFvV/Okrmb83/Lf V99+9vlfwtWbx8/mq3+F/7/57G+fKWpwtfzn1bdXv30BjeJVmpLX3l69eP1ZfllduTglba6C9tNs 49WLbz/77+t/uVFuCiH663c382SNUSZcf39z51ScYkzX9/vTD/lnsOn67f70Jf60Opl0/S38VMm4 ZK//enM3T9rEZK5fYWcJOrPXv8enxjqn0/WfoLGejUnh+pEeOwcdXt9i6zDFcP1+7+KrfeSHPLW5 fJonAV3oorOvcmO1fhs2fb1/2/9cs/n8eKNhIRQsBOvse9Ygf5KdlXNLE6Vmdf3l3vU3rMXD3sn/ 3CxDhrAup5jz+6JrWq55TrByWwvW+G21DfiTfeH73IOPhk9un9D/ffHvn90RecR0dacU/JrT1Yt7 oIZl25Kzmu/xq32Pv2EtfthbMDJhX35/cwfPJjUb0fOd0WnSadtkelzusjFEHwXN/C6/6JQXO46N Z5842b3PbWd//dONArrUmq/RD3LX6J1lvnNSQA5bA9bpu+ZrnZ1cPkIBLb9tbjs7Lw/LSil3/V1r zwpK5CTOqZI/f9+mRTYRRl0POzlPedmSM9df4FPYG1vsKSfy1zdIS9qGKRgLLIZo6G6fKVHa+mei NKdzI0ZRD/vP5SNtUqH4AE48v6JZWed5H4wJ9d5j7A3ozwYNvJBv7SM+nKeUYpfzsFWkDmYd+HYu 8zHa89fYEA/EYqyPQF3AdeMMzKY8LTbYKTh+bD+sQ7W2V9Jkj12xXX+D/QGhGVOsVHn2qIVWXUJ7 02RB8lNg1uogl6bGRrBpTkWZdszViz9+9uL//HeLbWTWc2cCCIcQ1wHgSwoKK6l3pzZGtDVtVgeQ D8/X5VfNE3OfZ6WGzH9hJHn+znCyQXYZwqSC6svE9bMLltKRL2xip4XR9vgWBwGpAtT70y662+dj WasAZ2mZWwphQG9i0w7SW2fOP7TPw8PCq+xklVl5VYd7LnwrNy0l5HdS0FWMi1Fu72zmXbJ6LjoB OtHBT9jHl1zryk/hOL7Enw5YlOPS54F4iVJ8lUo5uP5kTxmdvNzZ1nveKw0bYVfeEdvSoL+xjc/7 YFNYxQt18D2+FSafNN+G9SwqEMY1W6I+9rnj2n/+F60LBRY0V6PSumtfgIITJ63i9R+wNxVMWl+z V7BUwUSXX5uU9ajjTDaZ4PLboFDAFA2K5T/h685oUA7y+6XabCaXYrwq3i53FJcoBFuqZ6hQ434u OxdhoFI7a58CfnpoEUMhgv+wrT1RJ0wfdBtXSlUmBplu1mGWQ7mRW/+9KaVJS/KwboJORzsI++Xj rOQOAp0sWwgr5c7fw20LZxOaWzhPEU5luYWo4hg42zFe/9eNgvUzusG8fHCFGcN4OxP0bT7e1hiR jxs3+TkKQYdP3ZwG3B2mG9Qxhp3H0EcI7e3ac+DKYDFjeYYP65yPuW8/64FUv4vQAiR0ScW7htdQ ekmgv8cToidgC5sm1ePGfK5c4H/YKbdj9LzBQSyo73w7X+NDAyMPdgunBu//mZ9degs4TY8tMh56 nxvrkAaihCYRfGNbaEKVwCQm21cJ84ByY2mQWJDM35omFCPGb/KqRV/K+3dD7gCCEE68XrnDn2/u lEnQ3p1i8B76twtzsMpewODhpFwVbxdOgUIR519wpw1YNVEoB0xzZObGIu2j5srDy4pcK+5b0qKZ LagGbqT6zrBd6pjCjb3NavV6oGwv91BoU1LO897QvYHdheAEkeKEkBBKK8vMYHrFwnJipNQ+VQds nCyryIYVujfMLYKeUxpVebE0MUz4Ocd4ei34cEvH6Kb5rnkmOn4h3ser3XzWbmg+ayHov0aXhnEh Ze0PFO2IH+VgaQNsyaexrh+WAa3j4qMiPyKY0pzJr6kTKohgZEUXrTHaArhkdDSy7zRoq57AHby6 kDW5M1iTGJdpLtvrv96/ZdWgYLfHE9Ho+7L6Yh4J0tWkWM6j7Y28Xzf2kOpRclNlJ6ecYKcfV7b7 OIWucvywNPDmPBHbJseuSZoHcV7oSNqnyQ1VDB+As5YOmspHtyosmzZbOzmY92+136STQxynrouD viS685wKU/5WC5N7AU+BHl1Yv9VvvhXtZxI5OIQPuk1H0IC4qQaydnE9r92V54KRlruw4jJRLl0V nLfjV2LckllenFhp1xRsKzeaOuTJ1nCgs1Fvqu3j57vHrHa21aUdoL2Gf7kRxc2Tt+FnozhQqnVF cTAlc8woora6F0e5X1ZzO7UtJ9W6AmVAYlvaKbfAnyy09XYR8QajHStRcn1AqpVLy7vN4YkvjHS+ hMexCMtIh5AktJ73knmlKom/9nxnUPHQ5kynELfijMIIS6yjW9T47TqE4noV7+Id37eW5lUQGg2n h8b1soRnq380Tf2RnZZ5esr1KZfmYQVpZ6rz0+xXoqsIjf7YtV8YmdUjZxHK6dBaSy5KTi3v8LEi L02fgKFj0E/cL4mvQA9AMf6Qu56mP6tx0I6mfNgtzJz3ZM3cr4tkZFyInsaznYv43qxCR4zWlkH+ 3XhOcvlhM2JU2Iit9qXnP/digIzfYGzNwr9KL/hDpiWdXB1qbrCpllzuRETZLk95kASWOmfysHMW dH4DNlZxFPI850K9a5/0p9m31PjvTcm90obxpbtp48ifs48unMk0eW+LcDObMd/573NjHaJ0ENFj GKV2aslzfL+slj4SH0GSwSgf17XGnHWo6m8/b2EScwCdIVZ8akaLiftnniBx7BynSMwBe03F6coh YA3m4095MhjF+KgWBg4S/ciXiNOMofBjdFjKeRyjFqPEMErtJ88PlG/G/NrrXQdavUmx5JRrqJgk Wg4VM3bR0WrYYwxyunkKRo90LmgxCx7xu/wYDwPTh9hmflP8hK0Es/q026TQ+Fu61ZS7tbNejH+l CusdA7bIb/Na/PZms7EmNNaBA8By/wc+nZOJSybL7rXcrIb8zQG5TMTlCfa6sMlhmHmeu5TMPd0X JKbglzZcE3sKk5tgXUKWKpUdudnzxoCG7+hzS3NISoffM7ONcZLXuQ8Las7JfJ6uA4pmYUoPapsM Hpodbx/SSA9bFWhq0FtdPvDAL7FM81MlI73PQ4Ky3rOv0E43enLKCpsYHityQvIR2bx7SswwIU6Z Ity7br/ToAa4y/Xk7TX8GmfRf9ccwg8McWgAlHlmNhCb2xu5pfvxEsxj1qC0CatVDiKJsNJy+PJX oUVkZ42TDfvs7ZakcZvXah7kv/CdbPDAALxp7e1kpPMsgdee/Kz3ZIUe+Q0NnsKnSRtIiwCtoj6t 5LdWwSCL3ibFvvwn4v4xBFXqKeKwb7q8+No7rf2knC5V+5KmUdolOiBZjvhDQpnaJpcavgu+OTLz +HaTriJF1KFHPdXeMGlnruLZhU4PF7o+/vHGYXKfCtI6qggW7E8WcihOtPHoAQ38EL9sUnEZGttJ rTqktd7WPhb5RV/ocg168GqKSqvGaWvHJSsNR5IfPyeLtgNS3OYkmGRBZADpwZHzMW6hjW3NC09J iw9X8m2xQbe296MGOwNcDLM7b5FmZcI5N2zkbgcPn9A8mcd2u4rs/50pW0dZMnVSbfYavASDaYKT 9WoLNcqtrIjlDcUnQ5lYU5G9SNUB1WrPEBKqhIelqJxc8DTA066TfJicKOMANX9fKfxORWCeQUan Xrf76QRLBwaapRCb4JnWwt7rsecM31O1PivdVL9nXihGM+sg81PUWewhCGl2pjpLXVjJbGlqputt FyUjuBZe9dhGW4ll0+yUdnBZLK1WmrQ7JotF8vJv9s84naXXZjq98P3poL00/ePkXSOqR/ysqIzY XrvNrznfqpQhIntYHSr++h/2jkvHBTliQktpXtza5BcACmEjb46aoqCi9FXkfmPvlP+D/FBJCu+X r4vlSilMwiCSd6gDdGVYnZHCmAIR1blSN3tX46Sdb8SPFu9q/nM3UMnH5DFJRn6Vo7Qq8SmDmVvr x0W/C56THFOXRCY7tMXEtcrDNCi3wFQip7BKja86O9WnI0WM+E6yJ8FbQN3ANDHegukhXDYzZ8ym hmpz/U83m4adf3qQi4xrC61GKgi7Ycq1nD8SIVtX1O3J4z9mFmVFjEvZvd5m9ZUaJLeAsQ0mY2rt STQotCfOMyvtAEh7Nwnr083T0kj1aVd4CQvMgWQ3wMi4LOecjGlH32LrOEVxhEVpYsRkBlm0Jr3x lRt0YE/XocKSg7uEfwg9edeLXwoT9g7ToFMVD+zIpFK0wJiYdthXVLCBKZ3yVdEo2rX9pC3sQD9J yXDkbMGsPI3uwVDQR9tNy2j3Mc9Bm+K1yl/OtGilE/EDHDfNppndsi6NavgkK1HRsWpeLzOb00BT cuhTmk1DXLMDhCO22I/woX9o6iNtv/FIM8mNedpClRVBrRu8AESBY76ML+U2sOiMtGsw0QMOsZc+ M3jqQZk2HSmMbrcYSEsVadgRw0mOE9uI78gQdHVQt9IbHE0EjprMYKltNV3H39dLZ8K1dJTjEKt6 t1Isq+taziKsJglJHMMpfWZpGGf4d+u2Hkmp7rh3RVoXKCAuWmFYobKEmsQg8c/GRrV61rLMSOnN L55bqNmNRWN3Hp7+m2QOhwIm2WOoQLy5eleYn2rLAENtZc7JUjBwEvbPxQSD/fr4zI6g9duiTNha 81682bRlQWbrXwtluSoyR4bZdRW0E6U6TgjUhLWFJTgRTCEiqivlePxMElRbpXqf54/WaT9nSBsK CrfZHeNFH5a2YRCRoAYwBGPEJ5XIfloj9TZCd8AGwSmhE9E3p2jLdMjlQ4uUrnZaD9ub2se8RJcX or69WRMUam4nExGKSFH2aCdVtFjtJ98hq3auezsafJ8NpbLgsJ180qvJvC+XD931blR3jF8U7RM8 SNSDD09R7nIXssCDovSOBR2YkvWXm9UOy0kxlElwjh0WosqcI1t0FDwv7KkBNTWcOTZiibQtCOMX ZH0lP80mbb7ZYxk8VVjDT9an1EgRK3PqWtRawMmsc25MVHv8m37eWJ8Foy4G3ZF7b/Pu6aQF66Gn voEQIem61GAIIgLM+g5ExPpWttpQUCsBrVHWjsPKUG1pzx10oAq4rJvwGl2tI+QWajHbo6vfFmWy QY6eQXcUDdCBUm0OlbrRCiiJqICTdGmQFrx+hVAN8HHUYjgcwqrOMe0wtl4dW5XOvyaB0iAielOW 0aBIyvwMCWiUBVknfwt4FCAoByyTf/x/gakBbWIqsm+ZM3vK7+mwgkqFc9hDiKCq6o09sLX80DyY jFHUJufOKDoczQRQWUw6k1EcI1V0kIOMwMrZZ2JA2FvqKk0HpUOtBp5oILIasRJfl14kmearsOpN BWHCvWwS4pgB+nZlN9nvBsawEiIjzpPMRjptevWztEIC7jDAIMvjnVl/LYq8sQvlPwqbdLleKmpy eh1ikzQdI9kLrYQXMqO9FJ2u+e+2EVlG38iCM4iWtqXsDBXyTRiuLxXCsI200sn+PCMrJfYkZE/O 1hHiTWFHDVoiQlDGTB+JatO7+8VIayTidEghLaosK1v6addq2beVZZgmGPhXV1X4uXVW9OzPocHg RbFR0JP3RpqN+NTWqtuTwL1McHgQ5AkzQU2h9GNkr14+MfnvQa+uvrkIgjFMRhm2Cuh1r6wi+twD hSI5JzKBBpukS66sNdtIQhx6cjpr3XHgNTERSvxEVCGiDdf/WxxzScoe+lE7oBP72pfV0ki3yqs8 S6uLRJkqrkhk9/2NBcaaSowD9tarbdO/EvMt06OAm2I19nyqkJpCHhflO4Jq47wvRqgE/o/iOFQy p3IprkTsHKgBJg4XbJGztGClL+L8BYsK+RhLBeUmOnkqnXTmneuVgTOLhWDSK2N9mMDo5SKkhEgt kng8+r/LBPgqwYC4xw+cprj7eGuM+iPQCaJQNsNV7/OUVVS9SkVO7+/WyZlOiUX1JbgaHa2E9dAJ Mq7nVrFzS5YBfBG6vjqBsDxqGOVWDiIJLBix2kHd4rIsOVVDFRWgWGyzy6LvRQUwAxN4LRF57nQF SkYIqVctI0tHcRb28qSJTotOjQ8PADwsjkjvhbNhy/84XakoStAoncT3ACfbQZRB7mjbm9crHllJ pcVvNXQwOyUk0KZE1jMpOdGdd4hFFj6ZCAJ1wrtduS7DDB7kjg2hkqO1Xl+KBQ9iwWqRxUSf5uYR 0mhuoUDnxfx0E1ytc63EhU0xKNPprJ0t0YRWQZ5q42WQLs5ciqQCwmpGcwzeh5niDgwCnB0XQadC szoTq7HsgWJcqtCXvcUgwcCtnxv4yvkFj1WMkmYs6JSl5+pIIN5bQ2iiZSC+nFqTZBpz+1OexZzK GqSn1VtgLnfQvSDl+gVukIzIqVDC1r7LuTskn3LyVbCFoGkjjTJy6eE2QW+IjefOK1RAv4FXjpJW 4P1ofIMbtkWwVGDG8YGGukMDunAoTk0ft8Xvm0lYuJjuXF0C+02h56N/QqCaSx1RmzpI7o5oAKYO d+CpmI1UOGaNcUoSSs0oMFu7xEqBUjLUELFi9onYnhVDPYntiTCXRiBTde18WtAgw8P01HVxlCq1 vaFlzVMjWxwzxMFymUOhcR3wkImS+WV6pVSlp1EqVvkDB7J27Th7aueEkrk0nApXD69TN45crsuB CrFxoCr/ECImJJ2tGUQktb3jjXM3dsKfR0qnsW1wfdcs5xVrv13QTWqBu9SVhLmLYo/aAW5plAud g5xl4UKdI1yM3tZCkfu8FEwVGOcUAgj5i8CWw8XaEb7urTjNR7ApXEaelKVhWE3stRZASqf0+16S exFs8KDqOtCCkLJDwgDs6eKNJiayB7bpUkUT/iTf5LCnz4OJ/PlG/2eQxEEOvxLF+TPFCKwTMx3R BJ1fLGsJmKpXX++AZRK6r65hA4RSeboKcL/y/1GBC9AOFhD0FRkwxPBfHSf/EnFDjDolPLTPlLeG ABFRmY4myo9KjdRyUd7aNo8FnSLMPSVU7GwCqtHPXx2S8Sx1czhjG0Y9B1Ibe8kK9XcB4uh5+2gp RDUx66GNySzcJy2NZd1iY5e426oM/LGC32lbIH2oQ4NeQHhcoCnXPkWmh+LP3YoZhYFkzJNtTukP NXg4jO0fQQOc1LuiwUmopnOm09ZGq5Mg3VaEqKwiLNsYIkZ+Udu2WRdiBEGG2+XtmbpqyThy3BZt qM1bj9l9ymKiRTuyvQjq/E6hiV4kT2EzDSgAleKyy1O1KWfn2CHxgEA1TihZlAwTJq/U9W/yT4ya tA2tjnJZxGvWtLD2zssEOp4kukkTPRP+TRlppkmmnitI8D1Y4ZDsE9kss6yIC2EEBnGKbAns8pjn FlTXpCk9fvQhc1XlhHP2qdv1IdcNLB2KoIGQZe8uTFwrzh1FVgBhTFld2zvcbbVSf3aZ+xYXr4re 2uH10o+KjnnvvPC7rX750xTKemtDwhxDGMpJuZIcc9HoOO8BAytDg73Krytrqmj1XVpB1OMatMog 6qjdY8b4KF6wpUyUVVnQswGd5UAtdzOOEOB4aiMCtyKV4sdd+B4M3O55Jp7qJT5ZmAG12z3Djgpp A2jEhdAbxLny3SE96DxoB/rF8G6iho8P38Jyz24mLw7rYuoDGtIW4/VGL5efPvbmKPR0NPbERScd FH+D9ee6cABX6nqmLbpjAWyEsMI/ooTI6I86wJp8ztqW6I/4GliBI5Vg9rAU3ZP2aYBZT1fD/rXJ gt7mL/S6XwOz/bzNK44Fkm0ExIb+Q2VvC8umgGd2EJToOAszQRK5zfMxyQsVtRmeeJdXH+/leZlf dDuUNAI57aZ4l+DWdqXMahfxcumEZ08ZhHvhpFEjnA4wA06iGrS4H/AG4Jzbd41zQiZ1MoEmK54t hfWiC3JwTcR1j3z3WDlOJ+DBxm4Lt91obGbsqaxjLp/NUv2+2LvAXOzFVK4n11lLvAt4VpvSPOWV 8+1EDU7xj3lRMNOjE07rmMS8k7drzx2AjD560J2KBvFrD9oN24Fqu6tFoh4yYGUuZ45npfuIajtk W6ogkhrHT1qfXAV83R6Fd9KhS0HxM0r5UdnfsqJPUsWIKdqOKrZIwjg45QTnKy4zOE8R3Zjqjs// uIjVyG2Mnavu8PyX3GXbEeUrbKdNIr8S+buZUzMdHi/bMhY4gQQcI5zSuWuIrTZKC7m5AmltB4yF UKQBle9EcAoaIosfN+2Z7BlaAV36D98to/QvrDhEngRJCvTXIU8c2Xpd20y1SC+MpnxPiZ9SbMG+ HaLarbcq7rH0W8r9FxtsL+oWwDktaCJc/WxR8HfY1ILRMEIho85gOWQFddRox32yiudt0W/z2Cb0 5Cyb87Gb0pbVEnYqPMXs+L7zfh3kwNVl1SVXlQbSVjuaoRqwT+1cB5U+9lV6FqEKShdYv1ANIVnV rK88aH3O1kUeEvF2RlVWkpim7EY1DnawG27pUPeDHYgngPnobTD/J4WEWLXKigtDgLZwQDK2w5ys X03ZlYfSs8z+HZyThf1vIHfU5xJln00GRDCT8q3EGBqULWReGj/bhaOjAvZ+5yN8vdisOyraywxJ 7EQd+Yq/kVLDZuLIWdT3Wz5PNjj1gYbgl3uDDy2U98E5NBEz6Z+kpUAX80BLgU3QpYB9nV/SahTe W2b2TbGYTSO3jNlsi7lObau/XxaQ6Egp8pPg4fehSVztRV9oKkemuGip3e0Y4DTC3a5nu3Ia5Uw/ U6Byt8MyoOctUTEGvA+ClTSRB/pia6OiRNKWCTNjNK7kPbf7rjG6ZV98v+wbMJDO0SJqAD2wdfOA siVS035MFlzaMCnXrsvGzWfwBAPyWFyd7Uz8hj7fCO9tpNL2bJyNzUHZ54Wf5Id9SdkZ/YYdc97d q9Xva9bDRKtOh8mb1fuaL2IY0p4JSBKVlAsnaa95LePz0l6FUuxBOHp7KtV8gxjckbjER6cpsgrp J4r2/M1Jh/WbnVNwdrdvXpjfwW/+lDlFp2Y+2C2H8TzdSjKSIk6Ez/MFOIaTOz9epdDC24LQbH3N eMi7/cXv1/uEWu7EkWisDyY9frPerdPh6G0l5HH5qFhnEuL0leHnuSRMYGvYXjUBRwcS9uwcSoOx 4VkNM8trRpYvNa8KT6ivsTzGFi0gPRKXU27hUwPNr9qex9w4hEorosdb6RZ9dREMbXZXwYJ4SXN0 67tJpaKUP0nZHtlykisJil4kzwv9jDHxc3Iu098merefiDUnvqNUWacp9bVdiMhqv+pgABfUBOzD JtBVsPKAfnyVcaPwAt4zFMesckhoTTrKeMkNhKKRV5DdZz049zh4aGkRjWNbX23spnmvrfxlCdGL BMrPoXw69ELYC0QKPwh3sOlUtTvSGPGyAze4/gNauEm7E9dqP7/LwePF9EFfqJecc0X2R8ptPko2 p7ObYfU73pGAOQNnEwklN2ePAW7urBv5kKt1T7uvw3Pz6YVBB/I874o6DOeBXxr+Vsd8aoRraWxm SlUcuhMJ2jUQhFRMTqR3n8u7dUJ8zNBPXSJZCwzxx/Zx6QI+aSxSomwu+InsxDxFPcrzdHwP60O7 +aFPqIo4NVz9pnYnUChQ93HRho42uXfc9g94BAq7VLz00ttPnjUzhUWYbO/2XADD6QfQjff7SJ46 /cslDMgGxP1QuW7UBz2OfG8/0SXo89UivQKZ7Wlby6IeMG/lFNDAmrUAM2a0JceraWvxcbbGXom6 uTUz3pF2seLyBMpCEfAclDWrHU3xQt3lGSiL6V1bb1PeRTBy/nkXNNJWQWbzVSYv1NHbkuyICGB8 n8mq2iMqO1wyABwmOpU6U+WaWgKe289ehgI7AjyJ6Wt2kxEP/QUPRlH4dOYJDpj6AQzWBxfvP7Ro UvgIsWcQ6qO4QXB06cqfd4H9h/wUrE5uy7zOT2M40RneJNp3jmyPc5xCKWuFakGDRHuWVxteChT9 KI7sihc9e4E8uPly17+2bkZoexEQH7NAxC0zF43HQuvyvmZ6K5oqGxatgnkEvoa9IYjcqdHOWSmq BM+hZXwdlI/VJbKeZZyXKV3rDalALoZ3+4owGmUbzmZRp0kwlbjyUpAvJdCdJX1qW8fmH/CnfQn+ cfvYx3W1ddH2d9mbhADFNWrqSiNl2UwFg10d1vtcEhubh25L18cWQdd+BZmhfvge8dya+RWGKZWD /D3yHZoIQsfWvkM43U0vG1NL81Y+5tZgGIkV5x43Kh12A6vHIoHH2Ah2SMJ+JSmqzYib2Wi1sVRQ MMwiTEFwQpyZ9+KY7aG59St7d26cyIAMNs7uVBZk2YOAY44gu416YkYhnKCNzFowq2bCOH/7Tj8D DDm51j3hzYzYgBDZXcvmUgFIuHxpYvm8q3GIA87NgvqNuSxT+lQWN84zqU9ncecRfenCZnKb5KOf 4cAbWYF6mj/JvHq8bFjC/q9ZahxREVqaaY7PcaNEed0GJjy6EHsIZXlY9ylXH0dMFeIurtR8duxI kDz0AaddRgtmvMlpKE5xl4Bhf1FogvjU6iT4H83Tt5B8Gr5p5HinYeXbeAsZjDQQ1NlZ9SAk+2EV pvx+hAkuiXKEWkgPVSwKVs7NLs19eLVU8G0wuZXOxHew48fhoujDOjsvVx0XYpgFRO9tlV7VKG9W mu8BKZUfYNAucWcSY4fmGfPk54mR7u0yoF1D09piMVtZNdCKWC7tTuBEChb1jTiPCMroPqHNhwMm a891a24tbnMXYfYybWjbn47ltaWFIa9ArElfAUPTYzcUj7he+pjqDZ1hOtozZ6YVdLOsxJkxchDD 5AB7v5uKe5VKaQbcrX8tRaFAFqYbVVwbJLins1fXs0rxdbuUdXrVSDNCDNazhnu9kzLDFx6lBeEg xXr2otvLFTjpU4pRuh0m9Rhv2xTdvqprylQZWjJ+P8w6XfNA8atm40wNSRlCJp/fojqSbw9tVyjT qs6oMA6zybBFGaZ+ltrtTUHanj1mRUI4gdqG2FfNxe94CDsbKHNGZgXq24nWK/Oj4goXyVMC7+EN dv33cAkRQqyCu40w3Bs5/Vpm1/VQxOhGCqCiG2TOcd7kcpaAgk3ctLOi4wKbQpXEi9hZFRqzdKYH adkJvtz5T+gCxQHDAcW/+hTPbvzbXBXrF8qtQHLOFhgl2Wyvn6fB5dkmf5o5FFyntakUT4yT7X/C wNu6bFJHCE+5j2BKH8zr/GLwXfH+10Uckgo6JLTYT2p46Gwkmn14h3In6ipK8cxM5pC0knQgjthL EmtNogdu0r2tEUZJjNkwC2HLMYYGOuonebuNjmezgb3bxzwJtNq4EthORqqCMBs55y/1ZdiYpoar /F37k5byhdm109Y6rt9CF2vk+jcua5bS6tsbuv8gqlTXgdAufX1Ir1kubHgWSFAyzFyNhx2whmxo c2OL0DvBt3maSg1iLmzBl94OjNdWtTMTVKWPtO2Gk042LFQoumVE06EfRpmn0iVrP/wpSGleh3zg muxxbcaW+IGX0BxSqDr3H3WiB4f88zR6Ki8ppqeJIJVfrg26Kgz814ZZxnWg3YSf92VzNxqICMx9 SwrAbR44KJmeStPxz+PTHWS8LN8/kJI0DyxXzKWZDo1Rcde8JEg29A/NKYtc17u120bB+ql9ReQU o0ZAZpRO71mMmt2+0LksmdMlWYp45YTvzqjtenvMY9dGDs0ZL0U8ZhQmcjyyBs+dQ9vRsnnrMqSz rsenNFRhxOg7nHXb5QiHqBG2/lCwwk7Y+hkS3friMqN4URaKVXjcS7bFB+zg63T46v3SoTlGnATu hQztE21dfW59Rh/G9TDdQhE+jx/bfKz4gLwGui7XoKVp5QVvMVJqEcTWAVcHpRArCijMspWXVSk4 P+6eVqt24JmGerC7WmVxyMX3usDfKV2kAJKs699DmIuwJKvBygjUGpQvK5xj+FT7luK0B+Gxha2v DiZ/zBdLg2g70qBXRLhlbL5Zeqj0ZrpEx7ueW4EJ18YRoz7OZXjbT5ZCzb/lbfuzlqkq/zGmmp0Z btItlyufESJmbt3VUNC5h8wKlaluu+vuvzyrRHwd0L5Ofi/hEWD6lKFaGviJYB69SuIIBvNshMFJ pT9RrQc1FFgEFULWOSKOhlNNr/s5bguR1bExu2/zEMa7DhelOXh41Ui7Ep/O6Vi5XW5sBzY2tpC6 TT8rhfsw0JBopxTyPTqNG1ZyLI0X67Uu2MihZvT2uFDiC/dA53NjHzr6WWW6XraNOOFgTH8bcRa+ 76MVGWE6IehoEpueP9sf2/TcWEthmHu2pz+WMWwR5sNvxWsc2wXKXNQhcXR8QwWuKHHI1XZGaXFu 4lXOtLUDICTKvA4SDOM8ztGbD1nIXLGh2fgii+91noKyhcLMGjDv1mljnzGkjijhAUqaTujRCptO J6iMQD/eTJhoMt7zYog1URokH0tZq0op1rjlpkKZZjpUfVjwM3d9yujmpcpmt8sH1bHvl+ig696a I52neP2sLeC0W+it0Y0GRIjbCjanuNe2Gadaom58qdsUVWT5LVE+mQxBw3WdXYLh5a/uZLO3cwpz Dgniswilo8q2Q8QbRI3Nvql/2pXIKePJRzDvqwt4YdtHYKZ4b6y//g0e7iPJoW321GNAkj10WzP2 sNvO+Yqul01l7X7fZe7UbOfndXzElbFWuV9enn6xqUs2shj3wKzD4pB8AH+TGY+dVc867lm2wxT+ BhNGvxG0KLPgsDBnNuWdZQ9iy3oZNs0SM+zPV9n88BRRNAeuM6oB8YuFNOKBfK/f1qPowJ+y+TPJ 0a9Xxy6QoLgO2DExijgLScg5sMuVO26lr5clClruMa5A6gbKio0gfr5TE+fnZwIZ+whjnpkcfsn5 vyhPPGf+2GqljEcUfNOT1KfLiE7Whm75SgJ9o6tn0JwQIOkQ0BU21gIFuINewUfnub3P75PKRrLB rKJVszjP4G9dnYSdFQ6cA3Cwerl3r22JtFXXtVbWdkshSuLDMdqxrj0tQaHyVNbXbCeKOzfKJFZ8 D7/uUO0+fao5aJ/m6t0wsE+pO1LfzqlnwnVTRUTttNN8JFmH+ennOhfqeBz34LXKIhFqUz0bcuE7 fCd5rzXhoGn0dPjMUecQZhXC9QOdOjunDXNZgAVoECnyXo9f78S2ohgBQxjPUKNoMfE5ZljWbxpM vRcTpMtjYOHwBgrJfxGSznQTWHqpUS3BvsGn1QFtRLVTTjp0TPZ4dAJ2r280mFLOl3yzwyC7NIxD p+SPcn6DHoRh7Rji+vWK1USCcXSTDysy8CbVu/cIbDwN+YN15EPu579jC2WLjM+OTMYYr/VUSTEE 7i+EFI1YI/czIVWZgOOcLuK6T2Aey5LIiqqcX1u5niz6VJVIkIDHFszmjeusYdgapQD+mo4hySXB dpIDKWkQ5CAtyZozvjMnNeu5yQngrwF4HPICPxlSA0+VoMvS9wx6okFttUlznkSrtPIk507NX9PF X/Gjz7+J2VJMv3De3+YNxUwhxnk6Rns3E+ROqzjlezOZDtNLqDh2UtA9gCUmLV9JkVbdvo+trHIj f4yRsby1cRNlJyGUw4W3lp8F7NumuIYUPE1xtRi0+nIMHVgbgaEj3PyLu6e1Q+6jZhcIyejyHeai uopcZs2bnqi7Ex6kOxDowFqjgJE8z2cUwIS1m3Ok4bb7efxGXp9wwOAtq7EReuZKd0cBP+BAOqAP fcC1qxD2mjHdsn4E33J65EGhflU6VCcTEEp0dk8wQDNyxkwVr61rDJ6Wxy2rDJFB9RBsO7TUpTaj UDSlM1gmluc2QGKfz6BYjppQ1xV8t2up62BPJMlJp7xMKoUKZIHuxmjkxm+hU1xeXYVO50SvPTe+ pFKELScrRnEKsXEQnjGBr2QM5RYDBcdJVfcc/dvNXQSjm65DxC0JOrkFIyA6jWgnX+0naOk3FHuF Z24jnaxEWjenuXk/spmiT+lSBLznMV3DSVLLehb/ioI8V4WuEZ0iLRtYxonbwArGgxzj2R1fwrGC czqMUY/XCffSllek+TnIDFWEzE+6YLin61sHuagLBP+xiBR+oI/mrFpHYvDB4h/6lReDSjIElLGi jHDEZA3oZUFJNKsWtHMSWFbRhab5EYPTG2LpZebH4JoKFW1pfvSTahFk3LgzlkLhhRTPhUn6DALH I8kKJsDs4RGuQ2UGwJoxuJCf5eOMF8irwcXi8679zYv/VzHDeZ30r4n/zybENqg8Gh8VJbc/8Sgt f1xTGm+E65vSC35TD65aVshrNA3EnQW9iqjq+ryRT+r0JUaY5wnK2q6Lt1IOsIWpsli3rqtraavB 20VfmFyMd5UGK0WeDTk0NEisxRamwMfrWSTMnuwAEXVAhwS0PF2r6nsGQBtPr5eGKgAl6GuseY4i /JztAsxWC4wi+nsVcFpadhM0q3BIw7T1GgE7f6kRUY91gMZI14RHFh0GaB1c38cvtEp3U1H2Tb64 2vB+GWWOQg/CiTp15l0pfBosi6ofxc9feKCSbc2++3T8aRtmdC/0VrR/Ju1aT+Lll0q81itCmrk0 bvS4fGEcgUxalzAj+rwYKM5Mot1gSQQIbtsFkWGk30UZpAnr0MseLaIVdCLgXDISlw6XMudj5XAs UN7OoxN0pyMiKkdejVBdENZH+Did5V4mwjapn/9GV32MaJqJugqcZ7TdoN3wMoqm0YT9NbMGtywk TLE3pVjspfxwHtLErL74WiGJzPsMGjxVZIYSoneQRxAxZ1XmIizn6STrbh/vLKHnOAWCv2fK4e8Z cTGGJ0jEBXJfDjI2HCLC6g3N9WAKlEM417l3Rfjb3G3Sdr3stEwsr3Nvt0p3ms5c1L58t/QmEvn4 4lVEvbpM6fur+p88iuqGHwYlCRXNRlAt5ktx1p15fqLFMjVJtCez8MWNX3S5qor9atm2JOzcK7Rd z75cyZ6oMAfrBL2qb3RBk1WPKNYqTL58Lsd2nkZXMz/m6wcLeErJSFxSmujQhFk+5eziblwlvE9J gJ4ij2leaycH/Nv+9Ifm2D1sFd71h9wf3trUI7AGgMQTqlJzniiiBHcQCg8k2LdZmpCyiMIA1rvM n8enegQbTJgVQTcqfStEjiYz3AJyHSkt0ZaK4eRuHoBA7WCSSPAITxkyZyFIn051m3LPs0knXSQb spJFUJEiEomLJfiLs+7UDYZ3a1cFg/s5Igcl7w6oTYrAQRuyp838ujABNs5TxljKnpwNhGUUSc1N fcVl0FmkQ4+G66BCFXcq+Qz2p0xJmAfLEWqKrrwq8AW9Dxi5luKCrv/ki1vvrAWFZo7dcG97+xgH 6Tjl2CJ2Llgg1VxTPmA7bJuNCPhDLAQkL9+uq7qp2Ht90Xuh9+FTNxexaIahx+b8YW17pOSQtGtF 8zxZpvCQO7b9itPS14cdq9Sr0HzMveFt4y/3GZ8XTutiEQKPSJR9UO4aGfFzKmyG7NNDKKrt5pXK TFj+LEsbChHWKAE7JoTxzWgCpzW28/38ylwaJlFx1gq2QVJYLgiLPTne0xE6HrcPuUMslhFVam6m 7zpQHv+2TaftWH+PQbVFp6htnBkwpUxFKn1el2UiITp06oKMnOfb+tXe5JLsI6a0+1akJRLi1c+c fUTI2/Hc7KMMxHkE0ftI9hEheqenZB99hCyA9WOynw2zsGM6IunOtdLI1VXetPJONAiTMAxYW6E3 k0tLV9dnZD+WrGpfO2npkWD8OxA0/dSTQ9b/x85yul2dl2Z1xzh5TWpePgkv3rQT3u0OvwPrJz2F 2ZfYNiU4IXa8l52LRtpM9Wh6U+Y7wE/jFAT1dkISQoFF678qYqyMU76g9/ktLbK3LmbClVluqVSu FP40z3EYgFI0ziuFYnov+h+CL1hErUvyqjeUcflFO763Cnuekzqk/ZEHaZYACfnjTcbHsoRvcjqU 14khl+my6NQQqKjWTxk2hH7CQb9U4X+7qYDZto0+G86g6mFOHXcCv8+DYfJP1ytLswmmtCnhacAL Lp87ZxHVLe9lziLO4COnLOYPiiNGRNMADtZhM+X5xu6UPVCm/E11lFca+ecXn/0n/O//A4w/cnxl bmRzdHJlYW0KZW5kb2JqCjM1IDAgb2JqCjEyMDUyCmVuZG9iago0MSAwIG9iago8PC9MZW5ndGgg NDIgMCBSL0ZpbHRlciAvRmxhdGVEZWNvZGU+PgpzdHJlYW0KeJzNfduSHblxYIT9xq/gm7od3TWF O2rfbEveHWssaWWu9CBPhJvD22jIbg6bHJn+DfuDNxOXqkQCWacOm9Q4GAwW66CABJDIeyZ+fDxP 6vGMf8q/37159NXvw+OX94/mx/8b/r589OMjlRo8Lv989+bxPzyBRvHxMi1ee/v4yYtH+WP12EZ4 N+vHQftptvHxkzeP/nTx/eX1PGmzOKsvnl3OkzVGmXDxHB+tXsxycbu9fU8a0w/zezsr5y4+Xl5b 5SZl2ia3+NpOWtuLe3xtnA1qqeMY7S9e59ZxMRcvUgvrg7MX1/nZOb1cfJdaG3imH74jLd5vnXy/ Pf4NNtY66Ppd6uJZAUmpOvNgl4ubrQHp7AbbwrLNgTa43T57VqY9x4un29t1MUydtYOVLKDl9Xq5 tSbd0Rbk9cvSn47Nmr8af3ifJzjHZXeCufFNnYBng5cRHRvx2yf//EhbP3njAbuePANc2tYWf7yu v14rhYi35EZ09282LHsDj2qxekbcu7bwaQCE+8ulgtdaWdr0Y/k9Ab2+xcnaMDkTK/okhLjbJv4O W7jJLx7eajcFHS2MAHOajVlCWWe7BMewy8LJse3Of9i6JVhC9oH0cDtsS9CToPXN9tm47d0QXSYE coHT5S6+JpO/rStFQX9GkXaIN3Sj6fvx2Fd54e28SDi5bqhpzupzPm2lZlXIQOoDsQhxx+nHT755 9OTv/kTw4W6jSqVPu6hAv8YjacIyxai+CJXLfTdEgMyI7D9ZZUBSE9XkYCPf0z2FzoA4B0tpx3Ns O09hcRc/XcIRjHP0dIR3hEh2tM4sNvQwJNy+yjBYF2VShgMfJTEIegxLj8Wl3zwL2ITx3Ehb0oMw 3PN0bq3z4yXZVhpRBxHm6batuGWLmrwNlGzclre6eUtwZPeM9EiS8VI74HOEnpBj/RoHBKK86AFL SDvYcQTeBUEdQofao5VnBfA/5fCn75rtPtHg5QoErupXv9e6kS6QpEZTecDvLq+VWaC9v/g19qaC WZbynX3sAclNdOk7D0tpHXCHyS4muPz5HX6zeK+1gsN+rQMypEya5xBmFQCr00SB3LjF5o4baQeE m7gAiE237xsqVtZGpFccwaG1m23z+hnF5dEhkmhoS0S8AyiVwTOJC++0S1O6VhHOlGack6LZtH1A AaCvrxL3bxD1FSV9STZQIBu83d4SdCIn53WH6xl+cl6vCTH6AYk09IHHFQ5pWGLMghDsvlWfIsTl 4QhlO8kx2zVBCSYAFE/grVHRBdNvd/rsPred5wGYlOjCnMQdzmACesXSR2JrgtT1vIhXyowkNy6M UYJBnz8MsfFZltGMnmDj6vkcC6cbdFlyK99cV+67naGMBXS3PmyIQmU72pzwWWQuc5ycMhJmfi+M k74MkwdB7O1QmqUMkaAC0v05UySyTqSLu43I3pa2IEmcw3OpwPnxNDnNY2hJdGxRBduqRe3IVmk9 gV6SKb26BNidNQ04kgYyZtzIp0Azegh1y+hnYGVW9kDE7cF32gPC58n5ion5cxETBcRJZBv0Nae/ jOwHfePjD0OJOGsXJho63Xo24EyP2GjUAM28HtN/vbx2EVRTkBIKG9XBuyEfhRNsfeGjQDQaPgoq 78ZH3ZlsFNinetz0KsuLS5hgmoyUph1oCRv57LsG19YWH2jHY7KWh3Oa9Zx3xYpy6/O6b60yTrom IAmClYS0HynSKm3hQFrGvhsNd8U9inBjAfTmZOMpU0bj3cVvN4TrNFuul77Dz1B4i3TfDko2D+LO kj5bCHzkeDRbkCKUQC4bKNOMQCl7O/yd7qRsJFhf5x0zcEBKJ4mTPyuDAAdrmWl+G3c5R4dELzaB ouEc2byiUE+oNKETySuNLM0aGknQg4pvSNUt6K3O7wiGxgGZiLph5/smqx08FTWUFTEIZaQCLM4t GtgAF2BqC9p7VJ7bHy5R5VQ+yXYOpgMQXvweZbs5hqAqNQtAJGelEjUDCR5k6rqSv7q89tAzULaL b7bHv79EC2kAMeDJ9pI0/WXC8BhtHNBL4yZn4MynES7+ePnkzxwGWHXg47bC8FvoWMOrBPq1V0iO FiD2O2NcKwsIOSM3RPYeYu6pl2rLPuqwTG7xVJRvDWZsd/OGfYcfxmNk4aYOckyW0aDz68Uy+wCO FubWcvXL/HoBoY1Qk7EBqjHTrlg1Fr7uMxB27oFYkmj572OyQE76nxvxfcQ76kzDrqFRIE5ICX5B gKD2b8F6RtknsaS9HwOa1YLrhFdxqVTDZFx6O0QVamFDkXSZUbm++LcLAk+36R2SvUKjTzoF1Hr3 Ir/1i6NEu1NEk3hOJ9rYTxNIQRfV08VW9Vy7+rfLrM3bg/iKvTol8LPbMp3WxvK8wKIaSUaQN56V LuY9mzW2CEAa96zPA1nnHLH9tJ4qmoGrjTaJOdlI21jX1n1GBwlIXzYZ2uAR6CUsIj1ulE+RPp7y WRGmlgH6Re7aqIOaITbWhxDAoqAZFTcRAPAmNupkZ08buRGgM62kgZ+XRZmXoxQvT/7dGHFeV+Cb Pl6UlQJqS1d+x26PIIFM82A61tvyCa9qCYbxoK2ohm2RjWfino8g0DdkhtgjXnaPTASmokdnPSqG 8wSPtoyjwFtYx9aQ0JJnXDBQNX6iUt1I7G3JBE5o0bp6OrQkmxLN8yoDsyyabo5gzyRH/VWZmuaK 1Prhp6poZR6ziaDIrmoBHYSI1m8bpB1wrGrL/+U2uYFRrDM69RJ3fv/0UqO8ZAzFlB1rlYrwP18m gq4Hgh1HFca059yGoFFE4A47elQ530/066ZZ5pWrEOwdGOfYZr7vNjORKzrM823mDZsn+0n2g7yl 00n8FkR3NEf/ibz3G1TflhZ2x7GeVsorOmDWc+cFwPvNJcje1gYU4FNfDpg+HU0VZcoBHFX6/pb8 znSO69Ky1d7/zzZ2oYWenrZy3De/FMWid5dmAYYBGiweVWhoYcM2fBLX0WiDzq69hTFT9Eu/MNbD oW4XRqPPyR1xB+Vug5cZldF6OiGvdee5JUIr6GOJLf/sRA+1IAgT4kZR/DU/eNA3O493eVLILoer XWnQg6yGOgbAkXoSUyeymj4W3euQWTsExZKoh07Dzi8Vwzu+lLlcT+nT0f9uo2kELbg0RXcVG4z0 YI+26BWKCWcNZERJzhfBuE5e7xtqeOurPKABCb9jhlwmu81tvd+zrqdNsxKbP804aYtOOq0RD3mN JA/4+Px3Ek3HE7hXEQYJZl4YZdtzEIL6AyeCKeZ2XoC1awl3KQR3ubWPuzPjUTIvh7uVfGIGdrQh YgQjGnKVgPczl9oQmqDsITaGPdiwQ35h+0BeP8KX1t+v8lfaN8bD3aiY9EjEvb3QMITHnNYJKzUb W++KoTrqldR7ahdoGNtmF5CMhSd8gtvWczrUunARjgBDsvAmo9WkvCRPv8vfRdNIVmRZiRgqO+tw BUKL12Nsfj7suCVOdR6N7JB5T3tKWAwNAhFDwy7X38nj263pjhcEFw0wtD3XFZ6KHF9sy3vmqYFr YIdZilKxE6NWK50B7ciGY6TdgBppZSEm/X5uKCB+tBj7ecgZLAuwFtNbOLhBkTCLjN1eM5NSWpnZ 8yDNwXwfIrSlQWyDhDUMdPYrz98MbmsYKP4qB7Ogumjt5Nqok/5I49vWomQsur1aX8Zd7s37MGJt 9QhYtNfb5gj8Nn8Yo++1tmr6GVnx6IK9KFMxe8F1sCDWSaGcJAz6Y4HTHQ7d+hzSMULnO+G4WdEh USkrepalyNkpeOBYU95KpRxllmS9K1G6wYaAR9ZSKfquww9idKVx5tj4x60xwaveYIpvx7FKV3mV tAIeT6j42pSgzNdESiVEJaGJTiHON2NEopapuzzpWbcRQERzJ4e6C2zpJIwWo401k9eSkNngaCLJ KZJyfUn4nGzSslnjfQDlGXHFgXk6ueLvKoW8LcQJMDesASh78nFt2jhSe5MajzUhiPgKRfll2twT lb7hW6sV9evTFi8uQT2HIXVxo6NZgIhCZKfpGiHnXOB/7Z7eFa2mxS3S2zj0rYTW+tZ/DQOAVukb ivgiD8BQiWtNsArWfopLZ+M26GYC2U4wEaSfXRc3l0BTX4Y25ll5Qf/4sDntt3jYIbXe3PbR7Ghj eO49nE67F8VpPLAbpSrdDXFAdzsZLtFdQMcpm47nRV38yyXGBi0emkuEg5DAu5UYCNEOyeIVVuM0 jsDt53lmp21XVHnKfemL/9rGojGv7BnHMC1p6jjtxvgwGBf49qvh5va21i0+GHbAzvE8B52wxBRV /3PDyTNi3J0GEdkNZZ+CMTBOCgAhAj6V6ndNGgl/dk0alZPhKB441u8qSFKey22FiHmqkCLi5r0Y Y+C7/FkwnPjhaLMNkrRGV/unTE+SVykDYZhXm061IFfAWAU55hqH94uXDEb04AwJVONRKSujekrO qZZgAhqIUC2FWVEAbfWA/pNdGtv1mVZO+p70cl/6jn0AKBey0XQDmopfFkE/XTsLkbs209s9Bys0 8KADHYr9SmAsCYPnahX6X1vP31wCZ7QOhvtvbArsHTa9dTusHVNvw1XuGETCs711OIrTRuSZnTWj D8q9z6O7sCPKV0RaXfvKVJ+tEOs99tZTGKQUAopTGI8e9ATvWXwIjDEtCiMg0HM3BxRRqpJBDsZg vC0mKLXoZM0i+cAIBs6+4Hh/y6fEfcQsgA0n4ZfQZeLh3Mxh737nytt1/OVZX9XBPV9kG+ZpDeja UAEXllmaEpjWSoh1VL2o0UhZJDKTXsJAJCJti0yUWzYSeM8AKAvZ4g075zTLiEqZHUvrDF7TW32v y/GoVVmXw1yNZeGMqObNktVrLLoo1Xq1poCABNFHDCWcWmF3nOAhL4nMc1pZWkm5mZOX6cyD08WS CVpagWxZGr61l2Gcc6ilg4ZLglIjgb01RFDZpw0nobtKQq17IWdjw2mZiKXx2jg1RW8p58pyiJ8F zawjCIOQK+zV2/0VqknmKfTWRSEpb8DZC4KsAJ20aI+H7uO7Sj7M+h3zkm/hg+g1DepEKKqfMSPC X5zyOMjODVDtYRUb+MdWDyEgikicJ6339zhcnEzbw4s8Da8fYvbBHlzLlVrrYJ6nvfjHyxrPXB69 wYFTB4tvIxxsI2r42aboXUEDLrYGJgaNJeRRpCjN9e9iPAWb264USYmN4AmvAgKqaCEkR4pToNv5 Xdt52uyxVsas5w4IuAVC2i06UHXkDNBAJ1lQpNBUGMDGKBhKhha+0jyuh2Lw6ZxoMX0LJ6XbQzx2 fbWYj59h7lIbvCBLQyegWO1yrz/ZVzC29FKddWCl4JjZCy6dO2E4MeZitXrSa/WNldNbaKNcKxGp AIw2fQX8xS6iH5+gxn8O0XagXw0rQQwyzaEHVDY/Z6SYYBVKUkIZRmPJhSkvC2awdVzBr0c/YUYq 3aFS0/NiBGnrBolz5qFHh0LFNEHdGa9zyT3MHRzJPUThAYTp4N1JFpeamsmZZd/FmhaXEhlBEBjH rUo+dRgbFARrDiniaUqyEZAC1yVccU77Pk/bGH548rqdGWGMXQHO8FB5mJvjMbPnnUNqeuO+10MB 8QSzMr2Lk3ZriZzXHMfKzw2ONQ4FhkzcQ/VyiEJ4onSYvLGNXJxe22nWjSDWhtDY5IJvUWxPZuzw ca8ASZUk0yDaiDFhqcHslcyQsYGWfbIPyeTMg7c8bbzF4xoBb9l6hsm5EYtKjX/cGn8Y4+JpWjvI wRDIVKszmznV59ihaXpZJuu5m3w9nr9YHQnoeFniZJ3q0rgWjLjaie5NY0Q5u3MF4hzDiVh+ycyw UJFl7KQRgm+QiWD3uEQXy+OBtTRtfO3H3LGbWQhZmXHjMDk7t7500oppAj+XzEVdUlirUY9r5+ww wAWo7xwkI+F+EFECbsrDAIugSPQip1R5MXWGZ53nci1nZS+T1x/LTLTrOp5R+ZOcfyu/5anxBiUe zvT2K9DU+j0sK7I/evM2ZRbN8ssM8OJi69HoPRfJoUFwnDk0cDH04mVQa3/VwXCWJxK6j9CYS/aY 4R+VogSrsWzh74u3x/K9sHGYA9Pl8xAPEha+kNA+4w9RPLafW2pHzw91T2CRhDjvhJJRWpY3Yrc8 SSrW4HamUMM0rBqGafRG4tz0enVOfD6hKS7THFo3FtpZo59M2IsnszEA+dfnFhaMcVKe6Y2pL5AL f2bEHLh0cXVicF8aMdMC7IdY8lmPY+GnvMKLN4yfDOKfuzjy1aOSCvCEnXoJhEKVWjy7xRVKtZ7T ajhbZvwQzTknLV5kKlTrXH9HhqFwbMHKvBkIu5oeJ6KRsFv0YzBeh0U91GH57VRa69pkygOCdtCJ CzAiIKtElJgXDBfW6kPSWK1o5KIf2RU+lu21fAjqg7+uHTQ638nAsNPG2p34aod+7zjKKUwyGOG9 b3JrtRfb5UIq5HYWrcN4IPThYn6OW/gJENlLHuu4ZJ4Gls13OLXYmg1elOVZGoP5xyGC7mUObGFr bkmlTs9CdxH50mKppXUirobUsGdHDcyM2uRTX2usAZoKeODD7KRwIIIbohNwRTvieEuZXzkTocsB 5j6p1kKVAFJxBwGxgQ6fDSkATKPDp8Qq1vITdQ1P1J9I4YkmJbcL5v46OyOZPMeBQG15ojwh3asn HdpJJeGebeWdddgr76zDYfMohm3rIAX1pJjqOQnkxdCDPgjy+JscMq3EHu5zD0trbLqrI7MKbXQ5 sF+vpSD7s5IVx5omj+nHU7kfyq1Ave9dFp4XoMyQH0xMWBeNlpTpUks6HHlgVRHuEmqp3uYSqljW RcmmHxskO2Rhd1g3kJ2tVAYUlp7I/8w8ulorBrJIIofnFjRDOMKOuzc1iCO5jzsWmVsAmk5GqrV2 S4FgSJSwLFnjfdLcKPK85dw7IYaQzdpWvcwzcTvZhwlkG46oDIcsVrk/b44kFtQwpOhWh9AYVdcw JGzZ8s9C3MPSE/di6zIeFCQrVS55MeaqFLtI610ldkUeoJjGHUqHQ9hmcziT6OzC9CxpMo2mmOEz vd2iR9lnwkbv279X7ciHxF5aNl/qw5hj0UkZ6L16C6nB4NDxtleXo2hbsqWCjRSl46AmvcUqrqXc VDKS39VopXGdiQ2TxrGlBCUITxqHAqAgAQdMt9FfHwssQQE+Y8k002ZI50MSzQa0PxT4lNv2JQc6 UadUlzaNwsZkGh1AyPL2WLVZaI1p7nu22AScj03NJMmXRKTPV2Pc/kUesveVVH+hC6oSqZKihCba 1V+IP7dV287NUUq5emspbl6IomcexEBSNEoDcGA+Gqt8lvpt7AYEzQ6f77XwEnYXOEdNL/eKk5RE xKdDTBJ0hpqm5rhumN7ulcgassZ35UMlBrFPuYUZOUH78IjUmTWnQ0lH8zzuHhRqf7ZMbigiNanv qRNjXE1xYJXlCUrsVhAj8mnCCDF6G4dbXOdicanYMV30sfz6PSVElD6mwE3PYwCxfurSVrYSpDQh w6PR2zLwrMgSAZmMTQZMhZXgw+iDxM9a3jaS5UhNCeaEq+6fLtAzhJApDsnKEmmEbC1doziw2Nnc 5BZRnYXIq72Gw5nYxywDaJmijHMCdsTL1J0SpJVx0Ewf0dhHTWB0AXTR5lkmQcXwIB9MdwPYaQpK xoJ0vQAlLbn8rU9t185ojKjZQGfFr3Ce8zwo0OMbwwKnb6lKnxJIUiuG9WGkq9uGMqlxdXYQDtyM 5E9zZQ1fwzRYRhO8tpPz7aU/e7FkPGBgLA61gqqbPawwAU4qrMCMO/uNT9ua6Dkgov5Xgk1nrRZB aKdQx4QYFujmtQwep40RXIIx7bya2v0h1J5VqOoMpx6vGulDFQgB6Y3ggmuhS3b8DoN1QBTU4UHc b53flPvDsqRSnFMiAFmqthrvZNpLAUHY7CgeiKv84wqkJKbtp1ICcRDBUEeGb1JWzE4OHpbas61+ flfANH4AZkduBZQrtfTm9t6r3DETqH7bQERZGELHxa++nNu44v4nXfnEw4kxFwsZSNxxBuLslMvb 710Kk2pcnWmXdGDrAL0C7krneJy4lr7zE1qmd3bU2ynMXRoTQjaLeNeXUO0tO1Sabb3BOKRb9I7u lRdG2pMjruiWnOGaatnaKVKfBGqqppvVtDAFsxZzJ4SvqGn559aANHal9PXEEz4KXnNKgqacbYz1 zA6WpxTuTWvS9Z3BA8wvqHN4hYh1AsF4lyEBWia4p9k+YW9Rm3PuT3m9acKtu2P9rF6KQH9O81Gp 3vuZMlRKI29MYAJXF+xTAvNpiw5wejQuZMOrUCxh8tFJ3JbwwtOReDVuk2vZaYxTnoVaDWR1hHzm u1qP1n0Z2N314qfgrVB9+aZOcC/oFO/NjDvUEntwfq0nHDwjKfg70FzZ7YQLb3wPeV750/HwKx3S Kx3aOOpGhupFNIObQYQCyGN97UAO19ieJLUWrxP1sKDopSc79nPeStODtmOS91jM2Mt1KUfTeJf7 nVmcw+cKZ/cqpioop3MkpVtzctgLVq83o7CXPg1nFKF+XXuQ7wMm+Pi2eyQHiLtNell8rd6N1pUt aKrGMuPbtUTiyIZYrGAPqu+1YBDV0fCRkQ8lZSOLCts5hSdJpG/ay4AlLZfH3gEJK3d7/VPyaYWF V5zHjLc57N/tq1K4Qe9I5MAJjkQWZYju8WAF6s8SN3M+XjXaJq95YUgGgB5VSVbzjOXjWKBpSlkr +5oCn2+2Dvf924jqo/vTHGCYXm8cIoU8CKi340E6KYK02O72hJnHpWBoKjhLPqNtv97Wg3b3oiTd xYUCd0OHLqs7usEtdUG+e00G/LC1eLY9Pm9W61oZP8U4rkU8RDJjASsGBovifh7RsFYzZXJiRwfH ieVi0m2uUhNjq7EN8TSVbnHpkuQWT3FS0Y+0n7Jk5TtN1/T2xPLWSaUN78XN1Pp7sl2kP0xwhX3h CnmLNWvfZC50yEyB/GzFy4jo6M1pyLscebBWWoV5tvI6VfmZJ0DEZVJutxrOOXEzaCvFynpAqf++ dG6tGEMlRAgKwVzloh+/8ECsER29uSw3KXm6DGS1a7ZK4XscQxoCk+8rWvlst59kh0gL8paS0E4z Sy1KFolpfqdpJi/btlhmLyqOBWnKxhXtTQGjBaa1Pv5rnYiuZu8Efdh6/pa8ZqUfyX00RAE1ZqBD O3tAh9beJVBlg6j2uB5no2CvYfHqX1IpHjlyZ0jgWqqA0G4lPDm2CcfydtiYkIdWVsQ1m+0ofmgw HnDZaVbNW4qzzwvI7LwRpB3zPMo3e1WlUikcXMPJL1GSWN1OmzZKMvVGVmvM0q9bUeW6dtUyxbPu Gl+Ta9XFN5er0ZnOhQZQ1HLbQqCEgJxXdYwRRV4ZdkqiPUbMsO3iPeeOGPpuB1Xuuu2WmMvfbORh b7+r1JXhME3jMQYKJ+U+dxEBN6o/N8HXXvbADcoJVDIOWQXC9gmJJG3TVviU0N+73FKErlkjKzco tvhdM05D4NTgnJoxshFMBySgWrBWi5Fgidh6dfEf4wboC9cBzT1SotB9HjqGIFgnW36InS3K0MUX WVzqeO4lFnytGlm/PynVUlnCevMc/Gdhwx3CZSSrCxFHZTRykxK/lV1OaXJLw3Fp2zfFMBBxadt7 ZxJEdGgm/tePGuQjFtqR43JQ+aN4FIq+fvFrJGh2mcNFe5kQKtKLEXxBo6wYohB0hU0ED9anJLxV XoW2AuVUSzTIov9ue/x1otQubjdtpcZrQIgLjfgTG/En2SRaubzRJkowiusX0huqPhCls8Pwut15 1aNvwFnG0theyAlIxEJtsXR+rh3A1/g/usl5WjSXl68DmjaZWdPgmnqX94ko5CLNJACw0C2dp9rm OTdTxsY6upbTJT63pWcVrBhyuvvSRbpEM1Wt8p6yhrGcIXTWUglcCWTCXEDDlTjJEMlg37cEZz03 b/IQ7FBsCzEIEqkS0OnbvCUl7EAg+SFHzbUNEcbSB+SZA5kRLHIe6Ee6305gvqtfS1Jj233E3pB9 ERQjWuCfOU1m2/u+3T0bgbB6mWDg78rF6gRxjaWiV3tzv0QzvM/wqmGE5WoEwfVZnaYDXXfFsXbr M3dacI7MUbtjvyjsKX/VsCchRVi06WMWKlZmpzjYJoOdQk1iQrgv/c1yBSwaem2wiiBw7vHVVF/X FNlWV3YidcbWxi+FzBbC37iZiwWSqcieiewpC3Q2a1r1MipDXLc95w03g0p4KIgcObV3y7VKOPKx wb6h8bcl8LiWeAEUGeaOAjrCRJZh3jv/nDeJ0wqRVGfevArduVQ39Ev4jxBU7cMXZAzYryq2NOex 3mo4JqAm0KKS5POBFSVhNNG7/1rapWzzxAmrNUWsLNqgVOKGfjulEs+sorZgheImEu9/0NXiCTxt bGcHxOo8VjQ7pZIjdjJ23wKV8E22g6cujGswa4zsz4c9Vyj0qIhTfwYOIC0pxUNILgGEToZd84w1 iFyQrWWVXH3uImVJQnDJmCubQrGFbSug3uaaKzaMfE+fHGp6/FCuj3uUIt8xVB4GWmH6iDuN0mpY QTinnZQLwNf8l84g8ENeo628WLevY3yV0JEnfG6z6tx6PfJovK5liw6YchEXFbTgfixSltsK+bTh KSUGf8TtJCn4UGgJ0MMpLlGmbamFHl3t1e2QbE7APpSOu77/U/QHa6fa+CD6g12YSOWWgU3Pu4N6 Z5rUbJvWgoEKhSaDiWqdMzCfmRRpoLJtJgFpmOk3jaV2HH4VyEFu0/i+h7vVINSmXTgcKB6K+T8D 01giCQ6iH6wHpFXEjXBwsqIVfHtjUUS0ZWbgZsc3II0hE4sKBrT+200MKhn2yhdbbYdzTysOSB5R eiDoYiQrXsTwIR5vbpyfTDsrMtmumgIX399tVVqDbYOb6MVw+ec263J4l4IkU8u346HVLvgva3nH QfDmce4fh9d6OafSXBX5DzMHqhwl82OoaYEdctTrD+LwipgV7eyS3ISUr5CptEjDNt+vGXc4iGBC Ida0YpecjTO9XTLGjAZExT6gW7HSM8Zj+V9J7hp7eJlTBe/OtZSgNL61IZ7Q/b4qXeiuICa+Rh+r GGKAAX2ziqcJUcMaKIvKF8o2us/4xIqSK0P4aohG0KIRI2uYMznN351mVukK3cBIZS4TvhPEQ3nV +DKF05GZu6WXBrYiLGkVlFiMo1XFsMhWUErCllLya56N0AVB+wMck0UWYEUuLXr9SbkxIY5NMMy/ G7duRTns2jPzUCcSIxa8yW01E5Zk8UcjV7IjOZNPS9ACyTkZW1PeH6tpQty9tKZJTb+8W4UhIahl Q4M+kILgAYn4YdnrvNaWK7XjqLyMRbHmuFNiFlrYJCZSBva7UumqrZDSKQ0nmNK6+PR5yjDFEDHS Cx+xPLQQSvK+VjrjYaj43RKbwMxynZCyRyLpasdhJ8wLF2Y2h+K8cO1nQ6nqBzYJM/H4+QHCYWW5 1dvL3Df114a6tf2hvI9nbohvkiDSukMchkUfsie1yJfuz1OKohaN9Er3Vfi2WuptvjTQLaNCDskA 8xWhF58Qa9Q1fpfhxFvNKUYKbnXGshFWE70w4m1dAsayy/WF3NDGNIZac2xo5iCYNDITC2HMzHGF mne6pG6AaNx0QBFt5Cf81Ds3ZexJ7ggt3Tj0vt0IgSWhK8GFUY42j10+UPttRgPZDh0xeFlViHRD xj7B85UxvIcpmmxRQTCWRkf9wHFVMtbshT4dsZKsj1fVRWUPhM+025OtVwoU9EGs/qF4wBYxc1eS SSsRL9xCuVjCuu+8wpXGYtFibRD4HfOCxdoWgrZzuh7IVe4aRHUJ38mCTQVO14hrZC87LbzD6xF1 aOlHAsfFaiKdo8RAf8htneJMDV7DQVxEHwJzVWFr20IkCBQ3ZR+CGEF/JGki0z89BRsHYaVdXlVp OSjEOTZwWpD2dZsyLCKdselKXcr8PjnsgRt0EBATaNiXoP0IiRx5Kf08a4oAWLgHVDLTRlMRJzLF TBJZlUKoACS8dEGI5SGPLJg8rdO+N7ss+xdQYwza0ecodS3YfwUM/m615zu7DAxih+lg7qBl0P/j IvCqgmu0SXeiN2WYKLSkfE5CFBDjPbuFkVz4rLdHdvczfuh2DNvQALg2yGLjGLtxxg+3hWEYs/q5 3UJ5Jl48TEY+TLhGwG56j7gBAd3pzSOexwijuypGxpf6fUMpSZg8YZ1je5pgp8M4YBBI1WKo26hz OXe5QEw3tm7SIMGQ2lp0vG7bdr1hY0NcfxhGG5cACVraODveuCl/iDE/JNSoHQUbgPb3EMc8dmEY QTjTMVb3igUK4r0i2gamldAW64B38nVJO3mADGMC3nVtLxoP0jWm5nYFg/PbRUvVCL4i9hbBTHO6 lgLLTyolNM/XQdfnWsxUC+GB7/Mo8655I4Eh8rCzfJiysRihsGcmwJ0ZLPR8OK2bTf2I9O6b9Hto ghLGx3XTOSK/EGe3PAi3265j+u5UBLyQi4fmVDT9HIrsActNOitNDv5mSBuHYXVr35shsFO8SfnZ EPlafSlDEIOEiMREctqgKxC31edwMAsNtyC6A8FALOQ9fejbuW6JHFG+MHXMUvNHDUulWDEuepAS 9OIUvIwBvHVIblKha6kT2vxw1uOKdQMImVk6tTASmflxeHwPCOHjJElBXbiv9YR5ejlC5wv6IqDR SMhJDs6OWFCWQ1BsP1NqeK01ErYiyCdDs9byImErjUxtOSTJa09XFerR1fwi3wT0CLaQYpMwhvHT FfN+KFk2i3gHSCfNMI+KECQimK1Oe+Z3s2+ql7vV3NIdFljJfcfMUO77+DziNUA9BUCbTxCvt4gq DSpeLOJ1opdHtaLeBPoA8XptfZVhcsue97Mu4ziWR/hOOH73eR39JpYKZU8YDypgYL1v4ZDvCCfj sq+Cpf50NDxtIVyRw4JO0k3RViiIL4Qqv8rfuTC6aruPjRE8WGl0emvqiTgEvL4afjitHfEZ2lRH jO7pyXTiNh8nzzYaOnRrMU93d+s44NCJnB+pDJGvHl9rgXN6PjZvkU25XsOU5fUeyQZtoZhrO4MO CiT+wAZK+91mn54UQsYxgpj6NNskcrf3K9jZp0soezflvCQ3JRbhVTuxBbSsKPYVjeTtIQmSqama uU6Yl8t7YdO+RAWa+Ygm1muuNDStMQfXOnnKh0HVp7VQHv4s5Xul6ixqwrtfPoOPEY8ChhSsceDj COEq+pqITMJ/sSxILluOM2KmDIgBdH1yGbHQSlrntC6YaXakwAJFEFwB7GzHf4krHnds6pQINnQm gfRzCOXnotpqGBfrCVoPYIUmwoWeqNbas5VNTd9hasC43vZ/jHF03Ph17g2L2eVY33LnQYr1teoL xPqiezmbgtPAhiUZlkVZdqKaQRlKPJEEJ7dYmTr2zHK+jnGfe9DuiHrdyg3YMRJqwYpI+W7ZMBfJ IG1l6u6EPx1vnKDF7DBBkBmC5vejjXSJNe6X9DtIuU28cCXEjM0FvJFFuisJkTz4yTmxrAqPK9t3 Xw1pz+lMn/sMhtWRmSAr9IfYLbT1Zq8sUW7BQ18OowdPrkoL5z89Nmt84t9eptvhdFgE2YXH4Aek aTuXgI8424HKVz+txSdaAc2EOMU4qDVdYuxOGiKebxM8sq1pftFTU+NYRqfbxwoI1D4ORCK2zmy2 GhiK/Lx053y/Ez6Vn70pj58WlNadk3eXzmJxUPTyDFJu/mljC0J5u/e5br2ZzW79+TBZxcviUTct 1rBHm++xiJmh7E6s1Gcl/bBYNbxhJYr68Lsy3TCKaV2j7nwOTXlQCU8cJR5QGXfkbZiKbR09Z/rT sAezSBGNvafs84jQdkZnbmB0pKbknAxnZvs5a1ydL5I/b5ZlCt79Fd1L60ZOeZmAedJyQuOj35/c 9Jpojqy4AjQFjah3YQxRBDcr6AdQvw8kLiU+NC4lslQuOZsYhEg4pFaia+8uFeZOBE+ryqbrnOzk tKUCc0sNDci4WrkjCiDlfCtynrwnkdmI8LYmdnHPfZmdzmFr8OhH1ucxj+vFlbFONK5NVG+dUuri j0IMCq/kgeDNy46BKi2oFiLhd8zCuFNqp5pA7WPA9852sRq8pDTSti9qGpWY/cD9sdhaSwgg2QhS bVKTk70wM2r3tkvMcvIX/3KJ9+dFLExFNKMcR5fqjz3JTXVgkTpEbl8TvIgXID8apAb/WHswksT8 V4pVokcleTSdl6Jf2iI5NQXuJQUOK1/6RTdFcHou2EZ4ZA+TOychR+CS2/VJf8FuzTS3zihyhaGU CIGl27R86SUnIqmq3AH2JrKSslVvysiq8+HmYvoNX3pG8ezAtq78Ra7lmC8LWKi6JdkoBFNA3chF P0iqozFVsmtuvzAeP05rpCMwQD8vO0J2jlTlstAnClYYiot3YB1Ofh9UYKLlgVKE7kF3isG715dz a5PlFTIHig80W/8uw+aWaohrS2Pdln61/SvVUWqMjsOsU6Y6gjCUoi5PXjFBYP0BP3N4SdmxG7ZT Yy1mPLTW4mRfFMv17wSWg+AFX+gD9eLa85+/4+WZ8GWjElEa06WYC84JLgsJZRhJH6KxESCCI6Wt gCiCF1Aghld5T3jOvRxmwSSgs+qUyZE2aUqmSQsdSzK35SYy3TpmxVvJWFBFkYzX8fo+OhJMqVIO 7jBODK1+vp2HcfJ6c3ZGDRp5OV9Cps2BqDMpMa+1yLeX33W4KlpJ14MrCnoZKXfMaVyM3gShf0D+ NccQlHios8dptpZpZ+v2CnZsVgVjNqCI77jwhoRoLNiTtxTxp20UUlG2rZ2xhRjMdprn0BzIc6sT Nrxx1tMi6ve3ZUBRRxo74InN833uAXMKDxYBAoCs2kGKtFhKnS0syVcwbuFg9ArGyvJOatsyiUq3 aIVWCf/E25iu8jVhi23s2lJZzx46klfvNRN6hme51XjTTPZKE3gVoMcoIETLM9N9Z7GzQ3us9BvV 2bJXXuXzRS/8DlMWxqJX7WDAwMY7NN7YUWVpuiW9MLaWbgW1JrgjQUgsVjdfYm8eaDL1Inev14wt /rRuJWndJw1vXCWAATEv6JNjUSVAPm7a15e1tWZLpEWr7ugeMaa1XSsLh8Gi523B+Kfi8v8DXqcN yB5TJXdUPbFYJN7pauPkfLz41WXV6+r9YgHU01mpdL8YVv80q6/vD5dBA4PUWK7C6ykqe/ENPJlU Vv7/oZ1i0h5/hb4XLJ76ZP316/RknMG8nfrxb9Lq4F12g7vNrhVwAaNQnUCHVChG1D8ik7ZqTgWI tdOTm9ntWMP7jLUzKGAPr9GUTsb7PEA2HK1j/TMhzTdrd8MyXfQenXPVBNhWkFfcgzR8BBmvn/3E QKdW4RnjdFlYIxmy/Pb4bW6sO8euxqOqbVH/ldd1Nb1kEf4wXMz33fEZq6RyhEAqwtE6jTvrFep8 f8lto969UxpaeLmk2n5x8UTqeXBLl3q1o57ixXF4dw6/Cy5O1u+WQS9QP8hfiKPEAz6bHX8hlhCZ 23DT8xyG69urXHNFeSdSfbxkXnkzUkM3DeKQ9D8kJLgdCoRUIEq8msAgcn9Il1iNGWWQ7LB0qfQW uiCOcgFm8kj0IuK8I7b4q9zxEox01xPZObKqJGCLdPFHdBIE2927xkSB9Wri2VsqZTGrQup1MbLC mJYElB8Sjj+OKxXoIkVQ0prxXibtSXeIOCwApx+iHjgsuMYqu5ynHkAXeCm6FyTO+9wANkhmGomr Kj2uvn9bgQycyuP0MZmjLQpUwWmqWwwJ48eygqbjH+m1tQN9hkeNCwH85yRC7bpYamX5wCkzvo3e crtKahz12Vm9znuQphU7/6k8v+fl+SWTeieJtrwWh/BrNZZuN4SgFcH5MggT3jEdPstTWRb9RaT3 tEzB/QwWcsSWI/dqWAtoMY/uRWf2oTbecm0h3E4rBFHCcB4jAHfkImwgFrA69+YY61L1k17oMfyW zrH8cF7+030eMcyiLYKF7Fo/yeErt7m3aBQvboZvrViDshVNk8/BuwOm+hpyifk9alClp7uuITds w74Frf2mkGpnLraLzISY7SMl8xpWtT6i7R+DlZU6Yl4YeP0SYVMgT4pH5+nJZZQogxzQhCvjgFnv X285R6K0CA5dgYTVddG+4xVumezcrT9ChDeAHSocQXb2EF9dAG0c46uIUb968uj/wp//D+KAbfFl bmRzdHJlYW0KZW5kb2JqCjQyIDAgb2JqCjEyMTA0CmVuZG9iago0NiAwIG9iago8PC9MZW5ndGgg NDcgMCBSL0ZpbHRlciAvRmxhdGVEZWNvZGU+PgpzdHJlYW0KeJzVfduOHseRJjB7x4cY9NVM96K7 VHnOMrBY+CSPbNnWSPR4dzy+oHiUxSZpkbRFv8Ya+wz7APuAGxGZVRWRmVH9N5u0Z2EY/FWdlcfI iC+O9cezeTJnM/6v/vvw+t4nX6azp6/vzWc/g/8/vffHe4YanNV/Hl6f/eg+NMpny7REG/3Z/Sf3 ysvmzGd4NtuzZOM0+3x2//re786/ubiaJ+uW4O35i4t58s4Zl87fsMePL0yYUl7On+5//w7/7rxf TDp/gI+9XdzSvHYV4jKFJfMWbIxHawNz/rY8TX45f009B2/mWLrIU0xx7Tkv7vzZ3nhrsE0en5bh XAj2/Bp+msWFxa8rxR5Y26frJOI6coDZnT/cuxDDjTpeFwo7VMbwswkBBqG5pTnxCb3ae2M/n7P3 eB9sGqUPY2ZT96Jv/XLv8EW3obSsCeaUoH2I57+9yNDEzI6t6vf3f37PGKSS5ez+5/fu/9ffravH 83pwYaEjY9P5n5Ai8pxx6T7ZafHm/Ovy17SeJb7Bies5+/0GX5unZbacNI62ho6NnWDZGOts5Jvb bww17vbFLyngvvjkpmSX8yeFmqGLZaXsmIKvL1Lra2xtJliUQibfsT4e7LN708650hT1ZowgVnZo j8rGzrAtzzhhtycQ+RGUi7rkfP79/g7fk8fKWCMCf1S2J7s47vdqX+9KNsGuVMMPnu8X5w/yrvAL 6bKZYjYD2kCiOrw2peuH+4t3oA6XA1zxcP4f5+OjfYFN7BRSVhgDa8vGe46v+clEThCDlWDb8YG9 wR4c3OIs53b/Aqkjh7TySGOXhfPW0ke0/ZETX+Ek/PXegh8Ub8I6+Y+LdbusTtA45zDjhaV9i7MX TAipyHoQTXEBcXX/EQinfRL4x6v1r1eF2Jxo1EqllxcWiNbCPP8MDezs3CLvLttbeM/mBSYi9/NT bGF9iIK4+BawPp6M+cb3cpO2JvgfNmfYkMwnyM5eSDxom2A1nu/uI767zWm1PRyKCZooI1YgRrtA c6tuGGO/jLz4zvAB68WzEQ7/XV2KD4LrdkRKP9kFuZ3MY7v0nA0uJ0UEBww1zBvBvSuEEHzkF4D1 puzHo4ZQa69XmzDFzl/uhAqswwY/uV2cgDiQm1b4iLezyvEel04ssCjGHrmcZbv6dEghPUwg3DWV nheAbp8S709p4TuN9yWEaV4UmTMGYGOh/ngnpUvsNoJY83ywt/24IPbK3XSLF3fm+G7SY9bz9+sp DOZWtvhoAzeUh1Oys1eYNduLr7Vz3Djw67IDMzCFSp8eRGHY6HOIRStvLA2vVkH8AVkjQDWAGEJ4 v4THCG7DcoMG0RwxP6BX4mBH5/YGRwG+DC2KpCgUxzaU/h6zuCNsx5+2+0WTwF0mLKepFQ/6KTiB 38Zch/Mo1kVLLrCdoC+c/2rfe0YBvI/P2K6wYZ6UKQVnRYufiLPE04kxaCirB2UrLe5UtxLdUOQw opM0x7gcThQgpImxOeCiT0auUL4d3w0GAb9be3Pnv9mX+iVinjmnZM4/3+HP69p2A5Er86anKSpa Bdugb8d7hZwR0LYBqNChrRZBc01CEO3W+N1FDJNH3oisL/kphwNdeHiJXpcJ2aTjLlwzSLXb0a+K PLG3xWd+4diMFRbHqZBv57NKbg7OMK701m/hqmRcrS2lYO3gfrU0XPkZxGOMnA8+5g1a5oBP/2ED failzqBl+ZF+yGTJph/OboomDcAHrft5mc8MpNNdfQZxiBA/Y6TDMNqT0oVx+Q7mDlwTtLmLuYO6 yFEBo38i8dL8/WY22fHqVSL6GTABnIIGL9mLz4ajIOmgVvpgwyp/vjCwHms8JxgAf2FBzpQ5wdSn aO04hmoHGIf6gGuzWO1292yaDvzpOiV7YABbgG9EbegTIGBZn2m4AvW7zFEc13jkQz22wziSEnDs kCRX4C8+6keESWu8jkunxpDFzFL9OXbohe6JnTxsfHdZmaVTyGnCVqyPJ6UP59yBnIYeJh/DMSjn tpPGLMDUtkd1zlGc5DqLKHVbiebLPE1DFzi3EJZTdU6h7B0rasQrXUqiNWtxWaZkbdCwO5v0WFNj RMlkebn4wER507FRo7dqMTnDUE5V1LLlWphiE+cbolhYnivNeTfv9oHI8uLyhLysg0XLAiBLwiJq a1udFqYxOWtvC4voNWMbssGn3jgVstPf/amIvVO7J+xhIR2pKqeLbShj3ZC7KKcdDLos4+ZF54hr 21XgHKvlhc8MieBFVa8A1TKM/A0K1jkmzw3wG51toD+9B4SkFxvbHTxNIHjd38zmRKqe0OeZnYlh rXVqMSpUqrCmzpvCLUudgUiiJtIzk2RppIgBNvHpQEiWmQqIpZjMvitg2BlAJosEwwPB2TCM8vud 4F5Xa18SLivKNuNujKoKzXngIyOaQxdeiNMCquh624WU/Br/DljR5lOuO/U1C9bzGh96hGr8rbft TvSwaKObbtd6V1IZF3C55CI482XWDAOvS4PZC07O9lNoUHUIKYM7V4EGoYg2GQEpN6u/9sQwxwSy maNX5aog5O3oGn9dwxFXjXzDPYIoNo6F/kYPOg8Ixy/wKelVjP0xnN3LvZUAmLY42ueGlW2tL3Fs 1PY7uOsBJCVNe/kAbO2yrHqJCmV0iic9LYonWTTf1A5gtGPVk/q4xtZmypKiJC2zC0+74kAm/pd9 wGqSgSvwfbv8DqxI8bhSzhgbnWxcqBZDmw0gGMON333swH4R6YI/3TeeXXuhsI52nkazk5k1HjLW MSQAssTzBHmgZTSB6DZJV9mwQQTB+mpICNxuVAna5izVIt1+p601LXDo5kATkTauTHrEL6HFjHSR D+iJVqO5kVWbaDH8eNg+v8q65/0CceHV8lOaSlHGiIOxkp4lVvJyLk7Qo8DSLMDhMbZwoAobjtyk 5XwkTMZPGasV5wxjhCk6M9BAqqkQWnggIK9s6XEAAvXBONeYBT2qg8ytzleeZk4bLPJkcyALFobm njCH3o/Zu//+Upc/t5YvHNcvI88d9TGtLez57xj1mX0acf/5e9Zi2rv+bHcxp7zS3L6Q3cUMfxUm 7aecREbcqJeJLFagWwsqEj6BFuqPCNGHKTjf87yT7XxACpMP+S52vtKF0REQzhJ4r0KoY2l0ghdC 2cSe0RFRPir76VprAjz1pA7dbKuTkpWURrfIIBsaorFvHCp/3MrECIQJSsacOJPRtf4rb0CZ8PYG 9tREyShYSQmHkYwGOD/wqtgalGAacUEOVmYEyv44hkFa76itS9VAbPPICNOyL0WUvCtTS1Iwialt 7/1dQu4Au2A3GimLq8oQ1+p9mxfbcyjWdHO/YcMiE02NhxkgxpY4rpGc4Q9pg9qt/VO3ujXaC8do TbybFmMFY8O8XVSgNmcKivXiRvbXMQ0Fua/mBJqRVw7o0fp3q4x28ma1qp5mehhtV1D6GK96bEbr QHEV6oXqMsaFrlTXuE+u1j8LwdhEBLhAaJGjMqYLtm6hNhyYXTxpYQAUCPw4nOq/rGyDWHc0fSgk /f1KXMu1bXUL2SNohpPJmqbV2XTXiL99XrRLS17+7hzKBTPhTwVPJRVP4VqCDR7pgsLMM1qYLBx9 SoUuetd4RTVhjtCR+XCIqrvXAoDDeAn+4BsZgbNA14LuUsNpRi2i7KSYchx419/eK6ac5n7kTmZn jFfLZdcE9GAXGC+hMyjaCif1ycebeOYAaIghGP09bxjGThmMYYw5w6EnSViEKqfZ3mTsQ5quPAaY 2jTy+tXEAp+Rpfv+Nq0hQqNoqEZN9qD+Z7eoQXI4RnareeWDBcl5DKQ9IN+ytOPYzSND9EHsZula euU6b2THj5RxGqhZN0va4ItowoDRDRA1kedX659lWLBgPC0zaU2W0grlEeovoRVvHk1yNhwobR70 peTcneI7QKNKd2A8NIXGQHTb6A5YflQtlqfEM5ZZmEwKgkcWsrw/NQpNby7mh8uy/JRmYjaffGkM z3iyzk3LbFaCUYbmc37Cfnf0VXsbmJ662LVD7XBAag2D4wJ+j2c6NKBKh3WT+hUygHw3MHYoZIXw JGdYbXsEMgPsALEzIr85I0bXEHASBxr69rgHjYx7k9X0dekNSVCiAHyaYBBuEf21EJ8ug766LDJi r26QXaNoQUwyoTs27dfJgwQo3S5wORRfI1Hcemwq2G5sRdkDv+Jcp7r/ERF8hU2Llf+yJGnMUZjq nrVn2qHMZ+U9u2Q9ZpdsgG6MGMYQnXYiAhR20iumhE2OBSMj48a1RekoSRgymc73Vdk1b8NAH+vi WJhYG4eV1LXMS+wIGY/G6XxhPbxxAsTYrvbdhVkmEHSxZVVoduJ+NBYnosc5QZeUlnNjiO4gqYuM WwPLHc8LPfnOwzz8osIWPr0/bSY63W3iAiDbeIJz501pizi5D0Kj906J76PZZzUDQVHrGGG9K9PA K3tALLRHbrTlBxamY4cBcqVqeLJpCrvhic2Zj/e6TAMYVMNQpdCsfUmhqdgtGfsYUhtD/NLH7UDB CbbNyTqNdj+cuGo3es2hcbOfYmrC+Olp7kKWBgFoDXE7UNVgRxtfI/Z2Z3HdgQre2ydjIP9iPP06 dgxaaNNpo6+LfVAI08AxZ7/DGPg7KVSa8L6smx8VU1kh0dprk75AUj3lgVTvdQkHVM4MBU2DHqVV PbS8ltqjtJ6Cj4/8EnkmS9roWKWtHYfwJCBLv6nJbeTpirpONgq9IOEKmxS81xjm05ZMWLTX6coh jYK5PQ1uw7EP/DDlNR3Y/fNFgP2Ic0Eg2Fn2jVucHmOA4Slxxih0D7AZ8vQlfDTp2sYiD9jmJl9x JhpD60zDq7GBZGO2PWJsIy7aw6PhvCJ/2c68Bw21jPmAhEik5pYDEThI9mYDF3+PBeg0nvQA13lO rZ4AT5v8a7nU1ddjdk1V9fV88qW1XLG7Wl+U8vWLiyvjMFstnP8CxzLJmuKRhA78GaBtUCsCFQWJ aBhF8xyCLuPL+3ANEob0Avv7Nb4fHPAbO1AsjcOgvzPx8omOpxnjWg/IwsCLtr2RG+1NpYUxhms2 R3TT8snGS25IU7p5Ph9DH+6UDh7vV7aNYi3qJNKobevVxinPC9ysD6Ws7ZcGbfzmRA84TAKoLzVG uWN03IYBytwc8psk3yt09N5Xq/spHSt0rdbIIoz7lL8VyN3B4+GsRd+sWBebtjCIl8aqe48auCnH DQvkeMjBSLiPLX4i9rEghKhm5L7kc9h+Mr7WWWFEx7lljLRKcyjBoUU41Qo6CtemjUp38r+Uk1NC V45cHFceOH9IhtvxtKyOsfeL78wnCi5QPGRFNc6t6uzDQgKPDdKdahXo1NbFg6gf6iykU4DqkMFc +QhLytps0AIfyNvcBvTgY+llfVwfxgarlaepE/xtZAH9fjukhqkcpPO51eDW831ysUyAI1PoGUrn 3r+UXGSL2CiZRQxcIeUtCaRrvLn2klsWdPs1Wa/l9eVWFoxbRs5KRnq6iQfnmzpAvyRKP9RFMC4o nOwVGfKDJU8Y3nwXfoBdOMlSxlEAXTxox+P0nA2ZccavVa97NxHWg9VXEx/VNIlNZDaVn4k+nP9w Jz6GtBmnV0piyTTN0p0sk8CoitHa8zIhJ+Kfn7XbV0NzmnPh5v2tVAnWqoELoSXkl5kFd6LUPHBs b5VxvD1BViq5jW+GZ9/ECNOJWauF1PKiNs9LRZ1gUQFZI1yjTX06/Rbhin8VQosBsD6Zf5ydIVgq SaSxx/VRRW6LwHOvy9Msb8s4aPHF2oN0yzMy6fU/olVBiaWPeCC1tsd/GPJFydixt+RGRhKaUW/c oxnpeVtYCCKb0KLNHAD3E8QAzjnPuRzXv2HgBubPkpqE64JR+U/Ku0kU/PpjvBVUIGNV44CZptkY VOMczjJtyWag80ULvDhhiYLt54/hp8E1Luefw083GTTT/2Zv8FX9CQL7M2rgAuyG6AzGgVvo80CV vDJYZIFC++lft6miTOZyeXH7wMSjNNyxJZfHhzEV4UaBqNkOHlZ/0xx7ntYGB9QoND+iIur42+Ld csMs5pbyO/dem8+kkvjNFrqNR67V8rKXqHFYrrDMvXFWlO0xalnAm3O/auka57Cg08CgwtDYVkvE LqmxoJxgyQURsAAMPUpNh35B4OLx0M+Ykobdu0pqxD6aoEML0CNELcL1lLAQmnK+S43TbZpT6c2G 8x9trEWJ6GBSVLGCPV6nljXbwB/3F8c4/dihsGYIlDMzHNYodoIHdb9T7JcycCMgTBP1ZYCwQDR4 w23+7MClJKWE7jBOrlXTK4l0QS05rWwpTseYphjL6j/FgndYxCmtKgbG7w7j8wc1ChpTShcOtEa8 wqWjGh9j75HCPRWCGVfBeFSXEbTkSn7Alb86d8BfqbdsmyjLrfXtMsmFiClMKsKRhEGste6jXlvU kKTSgeRdQl/c6KUPLtbDbpGPJ0tYso3tToDWwnKskxb2njCuuHie8CVvlMjtV3gOLqdiFMKmnWYI XcUjxTACjrD28FK3eupl6TYY1zCiEQO7fYAkrSPmg5QpWlNoTRu0lNBkDJfe3J2KUSJ/knpfcbwc ZkHWMINHQ4Li7z2o3g9jxhyywP/IJHsLP9ZwgsaZ+5PyGFMR1fdOCOoDgUtJcAeTw9lrYcCsrWqr wh6WHNqTw0VLn9ApJ1c3K7WGEzoyLbzslsytpQ4GeXpLb8MrOIpBJQP4EMbsauZvRZbReyYGDb5S izDZmDWNrwmVx8ahZn20cdY3O2b0KH6cZjjwyLectaEOPp4Sxv+6jILVJw6i9LGFcxo2/rj5R/gT mHDViGB3B8W1xrVDFIu2luv4sJTl9FtMdEtEnPGcoiRRb1lNtP5QSpLigm4DGJvaFKWMpEJ7SkU1 piEoOROydhyOgebpsfyVtWc0vW5eA2nHJH5z1Z1GEalTqkDIwgUDjb+vNHqKVZczsqu1K+lw5PyK EemYSTHDwUHOBwoMZ8//5YK5IQkvR2nGJydrVG2NbinY57J6O1wrIOEeTNGrhXk7iz1WICPnTJyC 17JD5OXHtl7/tgbO2wSCZ9gyxsFNWgMtfCg+5YPilxhnaoN2sppzRiclGjINJAQ1GLoxegv7e2RS dz43zbQk5SbZO/dCji3saiNSZ9rOxjGEHm4VEGsV28pry5G0pRZZcKOxy0hhH2OoPVbyTvKns9tV 9dKoBYc20cyzmeyi7nITZYVWARcbBFBtBflmwwrjeBRxOFNh4ObMZlRyvIY9lDPR1VycWwqtSx0G QbQpLwsq/nFROJBmNuFdPL0IGG5gFFX0yN9Gx7AoeQYNrUPbOZziUWEt2iSdoS9eAaBavFxzX80y Ib54MO7kcWkB/6Xh44HF76SCZLIqHg5igEnrIK9MtCkAfeXg1li1Qt77QMZbh0P3RnQCFTcHGx1Z 0S0d191iQ8rOqLbQtQzfEkc1qcf+8crV1oy0q/V9WZuhWEwpL+fBmGgazxnGzyyt47Y8jSfyOGwd g1YzVxLbep7ML6lVKebPL8soGBHcMD8KwznFJwDoLaSmkAyhKhfG/EuxzI1diI9qQHQ6TK7AyYZB wd9bFOanzY53oE6OadsqMu8JYFFPX1A0ye8FwIJCzoRlNeMHNEDbfBu4OsIIXf3+VoPqcEEbP9xV 7Vq/w7SN3FTUxrk1ye3jWbDA3QaT0gaYQV0B2WI0u003x1AGryb+jN0X3yjMjtHbiWE4HXge+CRO YjUBIMSy18CsrAafztZorOZxbWGyomOyVYxrY4xZ0SnBRAFgQ+5rXQM+WgwZJmlmwD76OodWMxDp Gc3r9jQ2ShzOJaOiKcWjcVtHK41jrF74vMzPcQ1tYKZ575JUnf9qq8IUsodxRQgap5U+i7L1eo5d j7iiHMmPoOi/b8rYqSUAfJidov8N5tOYzHWvoOCnMLfQ1HV/UTcjGqXnOxVMp66bCJKX6/bfIbte d2XMZPf7u2rMNqOHXg0++rY4kBwHEIduAbrjPPOpR6itbUXRchnPKNLFJjuQo4rGNAqNxHzJwxJU hF/iLdPOnQW+kUS3p1YrOJI3faI4ySx10cXWZzDIfEXU7fJBh8lqHeSxjafa/Uq3WjybpNESmWw0 W8LY6YG7n5YJjaDywyAu5WnOZjC9gZMCG4NGoFQLVeNb8LV8p+/b4tzn+S6xr9vTxoaNPcd4GMmP O5Ty3TB1SiB675IOwAnmQCTeDl9XU0zubUol8nzcGwM5Sj4Qk41jK5BSKfEvQ/71qNpism9MRiWm SPQgvau0jhiVqA32WgdxW2S/2sZkBNPNNgPdJEBhM4vtM2E7Yf28jp38eyDUjpRqOrLD2qzLKHzj xshCeh85ebJnEfMIfMcOqYol8Kl8w+c37yLWmTtP01z6OgUdY5chVt7glwDM7ex4rIva2M1pmNKK BmPNNzWV0dMoCpw+gttYLrBxnkfOBWrNRNpzNvjbvcWj/aecEtYfTWZkZqiNaewZlO6ilhi/bGqJ iVUt6ab89XpsMgqriNXMo735ZslI83I+8yguHcerwjTvweFtTKTOeKnik0XWWCo+mWlQEHZNFODi gZpaf1gRtqNnRYC8K5Owc1vuDwcxafANKtpmjdJuSYGXZfR53qIQgNt9Px5mPJHX+43sj76jCE6X /WUvz2tUec5ldoY+6PpqSLn87vFlDSx+9PzNeEfEvq6RbjFtDt7P2DAlj3NevKjXtIW34VsC092u Qg4pBJ4iK29BWurHNKi3nBXcNAbt6rd9BDgj3O84y9nvJN/PR2M6eKPQwbiTdSVp/xIJncWhy7+l FTbVXuh2TLOxF5SaDq3LnKjghUaZpVxG5AMzlvpgSH5PayrMTKkF/cd01q+f0PKb5Lyr9bVhLMGN ZeQqXckSs9vAH0f9OtI5GykdgUvlEz4giew5IueU3KEt8DISrysfGwA46uOwbG0hmzH9Xpbc0SUG 5di3BTpByExyvxr+ZMM1MITGC1t0Fj2WrXGX5uiUGb2sfBB0mD3i90VRRM1aootaXu0jVC5Y3pHC eJxy2HArSq0ShpjbfaP1VEPGoFJBMFNj3UAVzi9kJTw5gK07ibLsOHu1jszN1KNGHpgpLCavOVAb bpHY2mdPgTUfN/HPZ9At4ho/ZLIiwJSPlHdbc4NggOEihcjxy/KMEy+OjZEFjE+/LrP0afRt0JYl vykb5zely+w1UbYLhL1tuaxtD+XkDX4ugx+x4PU0RkxWrGMsLjoXC/W8P9WjCVodAhMpzQmVcAd4 iq7NBup5Nierv6qaAqlBOFC01EJRAwy+jUFLWgCOFwwfSY151dICJm4xWlAgJGeW7KwxCgzryC9R Y6dvOXWOsM9tLz+tCT9ldMC/PdYaC2XZsLNGQt0x8pEUPABSqx/uP0fMrlKi4/bxF7DBk7TQHQei h6RxdAzQDW7yW5mtjorGF1hDv+05uT1QrtXexydGmW2wvCVFoahgRFiwUzAjQ+eq1eNS3O5daCm/ 9/IdTeRyM5h7sxXvFbeubN323RV6yu9AXymeodvar0S3w9j5HkaOPBOLn9wRnIUWMFl/8kfLh3oS DuLUj1918Lln8KWLQebNAmfrzYfCizjKvEgWyKZ0WATviCZel210fgDayplXd1gRIrTlVlwtxkXr tziiVUBrF63VdNB7BW+sqKDF9LaJLhiImlRu1NnJaWKsctMBBVENgSMPGxUIUDOQn+zM9CNiVKYE dKewf3gtWlW3auPlqGqWkJsPhz8VE8DrAulTPsFEoU2JteaWgYm4XMawX0rDBilsfEXhe02SQdUC DMAPZovNY/UJflFrDvitfoHHOgQWq4kn/CI1ViewfitkACDqp9uvn2yv/Gz79Uv6tXibWMO9bzQ2 z6A6LHGrrsArG6QFgS8szeNnAaxSKixSeYrs8XNWwtR+s6lAQQ6vS3dRjXYb34Fv6yyauI0xeOak /F0dzwaFSBRxpDBGZlh4Oxwb1wd07Y24RU9wFvj1ryPr+7pAvz/97YWxcHGBL/1wF6algjrlthdD ZYC+dd3g1KIinSgdVRXx2jd5wv7z96uW748ig1Ht9lmXzNvYTUAavRjbePLtxVcr3UqEg4wiDr4X uVpmCoMNHZ8sfI0+oWLyVupv8UKGcobChtXQoK6BOJ/JnawYVJn56qFcZrQtZxyayVXLK/NWkfkh 4VdAY8P4drobMj7j0RBUGd/OkT7dONL+7MudLY5Y149Hfy4lNddCLVdmBgoj9jWDcl0GJdI0Bu5I ANKkZRv8UPHvsWe07SJXTKCNwwmXOjTQZXDAmh1o+YG8M/RWmEMEStp74M9fsOdIphYwnPXiMX5l GZOoDH2l1s0OdY2pPpypbM2MVZYDFSXZu35wAevJSMZ/3lYLdLGN8WD/eVmn79P5j1hv007gV2U3 op8tSI2tu23dizqNt91qyZm+rspl4kbVmb4uK8BZbRKnXAljQTnJ59d899hqviHmlfHbDS9Yi9fw OATjEpa93B9/s79IziMk6W0X6BDFlPBpSpSs0z9lbWsAkMNIlk2fub6kbUzWpqqWeFTDz64wTAY2 rLQqFEnRVdB3xMqmwObY02c3U8q3F1gmIGXPG1AGHhwifUwmznkyOfGz5x08Ki2WuSqGlfy3CTk+ oTd7Hy/brS0HgXzFgkQJpiG2CAAeQy7+10VGJE+12Whka8h2z2h4e+3NkHI5XfJZcJJhh91vHLV+ M2zxiCZaHUh1jH7jqIN14wxau/bHj+kKLo7iuLen/f2vdc33x+i1iTMwzhJvyTpk+1Eqxkcs0bPr zrCzEV0Z/WaUBbBbUIvDlw6QGpObw56gutHP/vLD/TEnx7LBxlGE1Ggny3vJk8KztX3LuviOkdvj vfXlRUJ6W8z5X1ex6vh5vpCroe8jMTkSPFat36pOfyF4Cn6AapanweY5rbmJyJ8cMpEcBI/7ZWkA uALrgm1dfDZmlPzNX+8M45flscHSDb/cm4xEIuXObx6+yyLf0Tb9C9RxLX5EQCMy5aZerjjs/Oc7 l2Qn/6q9iOUqv2i6AAgVgR0wLs5Z/lP2e9oGtOzp3P2m65DEi6sgKuIav3e8+MJB/Rx7gW3HAlsK N/pkVwBN/of7OXGyfr6T6tNDUh2JbOw7GtfI7GJuLjEBdcR/Zt2xiVxzPsLvID9BJt0Y230ppCwN CUT64/Haf7Ifm8LbJP/BiDSXiz97k3rb0G/2n38RHB8NzjmtECY6u80B6HZ/eCrfqbHJ22BHG7FR Ks3Bixs6VQMkxtdvbOLG6bDRnokhBJVaFHL4cStBpQ0JAnKnoiq/vpEErx/szKm7ghH+EgoS2YAZ aEpUD+uLXWQ/HnfB+ANj5Tua4PvImTbtg8dcd8aS2ebUD8BjZ1+2y8a5OfGY3SVB/MohSPqiDjln 3QZZGNjn9MkRgsLduESWYn1r/t2FwZq9gPafDs7E+QPAQF9tB6T7b6CWLxQ0WucMejk+BLUbI4pr uT9DwG0lUeVysC1k0PhqX2klzNKXFPnshRMUFCzskbG8eQIQtz0tzAQt0bxtIZPsjEAKnKVSkd4A 1Jb5al7KFpLr8f5WtNbAJKJzzq3ZDWIw5JvDhdcRYX6gHNrqzxsDToufK6XUJGrtQtKx2/bzJMSG PccYRJMndcDket1nz/+oBK71fd0C7NLLWJhIroPAzIGq9FeiT0PeAL9HZw5mNEJoGHo97ybOAUJb zACi0YSnQjXA2gRP7zhbmUeDIexsgU21GOK3F4uBftoN2+jt252CGBVyIcCJ9lVBRya0hEVPsyEj yLrcx+2F3SHBviMOJJilj/ka/BwWmbmGWu0RDm8bKKozuRJgk5xgm0z+Pi4LydGcsv9CJd1ExAve 3YAUB0jYOAwTWTgSLqCS8fkOuiorXUES9eAXjobG23YrCJsPICz6f4w9gLBuDGG/qIKhmCDSTOFG P99pkVMaSXBjg1UEA+OHaPtIdprhQjMQug4RlvN/Z3TIdlSxSlyz2/GXfZRvkWw92nyK1SXN+8gx 8APcRo5csei0+nKWivh+gqx1Rn+IgBDMHLIO/MUmbdmm/mqIcL8dU5aix3d2GIQEl/sYOjrAFj4t LWxfN+WnFbguIJTc/v3f7V6Ji0dZJJQMhtvvJbNprVPkw1ka6xST8Z8zQmAMh9+4sYDmC/xBKfWH ZfT7/kgqS9xBxQdTFFz3VbfPRGPSgIPvYSUh3phDWA7rng8FoAL2PxkiXq75ft3uSGnykJPEzjXZ iBJq1qVrzEvjsJY2RBpuj9BI6aKiEfqGsIpGpLzpZiSBMIED/Hz8/vGvv9Y12XQ6TjAYOefz++IE HC+AKqCaclYrTGHOC2L32ADk97HylMe1f9CUTDtWW6cedfW4DKw8XG/sNSKSGA+Hl6DH9R2glnKg mL3sncTpR7IJLbpADcC/HX4nThWofixQV/Wr+B7IKcXlKVsu219OaV93GnEniDt3joGpe24FmurT OTVa/PqUGd6vx5qExgmGdguaBYC7mLnxr46HNWoZEqobA9oGjwMYod6OWyhWBk3PuqxHQAEJzFBE m2CqJWP3YzHp33HiwVpt4DJ975Zfre+2okgsnYIJsacKGYvhGjMQfrOkJUzdAeOxGABsXWMx8Zg/ QwEd+wlMpTUWNZdraFXe6ui68fbzNx9Jmi3jcyDA9vJAmISluS63Fibeltp1/ZwL1JQCf23d2xFa f8v4vowbcHWX9jwv5hbCC2N/on1f4YVLAmUxjO/SszIhOKdTpVudjSRI7u/jFMkMJcKqsvE5eSzD F48tLNT6gcBhV8HHCTvn69BefaLMEHVlI3Uf/powm8GAJUu8GQTnkRZpmxySfRkOv3X8tKXpHv1i xWWPyJ3Ct0YGUHGL2i2onxBYba/f7tqPrsnjV3IWCu7aae9/sN89mG41dda32ALil3MCCWrZd6tH lPq6LNuRBjkWAI/EPbpa+5VA7D4aaTDaVeroq6v1mUInSuDAS1SSXZqddnKMqF4XaANseHUKVxuN I0bnOgchLtcElYz56Wsnc38X/CWXr/DOAXjEz8vhh144eKQP9wlZwse/FnrgBts4umWUyJguE79F k3duYZaYD2tGOUB9oMejH6HRVjnqC2PUt3+paVcP0FVi0GUw96BiNf/tnSm66mXtbY6KYVwxgY99 6GLLqyZoVPT5h5Zoe6Nf6YM+mrid4H7pDuMjmGZcWrCCQBJwupAnyj3lkRMM7DI3TSG1YtGhD64H rKPC4RR3amsGjo0BXhdBjQGT76VlLlhC0u5xZ/s15NvBdvTdPvZDflbbgH0QWLvRj1q2s962YrwI rjH7ry9WYY4Xu3Uyfr6fDDsv6VE2GDRA31fnTzdSf7cbdwfMegWreIkxLEhDD0w2c+WTjXO9k8WD luI6l2SjwJbRhWL+sH3vKOyHxSe17ioispHxGU2Kqbc9OwXhbnuknThwHzNjAb8InB4O02KgYo/a e6klxsMxDICPf1prZ7vzT/eN7VydHdRtt60zfa0rhTE0jm327maxQMmxLXrGjmI34phjtx7kHLHi aqMOuZzIJ8kblyo6LoSx/ZOxd2SPGUvUuwP9DFtEANutI7+fD1dSOvNo2dYDRRg2ckIzNZMizCLD uCl7+ll5LeaMdj/cDA+Y9odl0vMseuB4jjEmxroel97Qj8kE+pg+Osf6wKppkTC9sASpgXc4cHbC JSBEWtHSQZHZmPVb5QaOo1PeNUATq9l0Fj+dq+3PFf/yHhrBlsjbciP02C03WNA4PA6QJ0k7ZNcu 8ogjDuRKsDIWgd251n1835g5KniBOftWxGa9FrTxqrv06FTYYeiyhlFTi6X7TcPEA87h0QR15DJL Y84hzWxwI6gkEtsmdm4sqmSXHzg8ftoNP+CBnATUhUoh/7iPTnOkCaM/+6ppqFjkBB+CqcVpOQrO 9VjnBnhPE1QGT7Ee1acoP0Je8vZwFtHJrN+xzUyz6DGA9a1kUjQKEDljUhw0jd0ezF3HaUZXXnFf 4hx0NzROY3a1mMAcZkz8G+pyjLu9Lq9l1+IreuwklrjRQMQPdawnseX9ZYg7GCooPAntF7mFdifE xygchzcnE4uf5iySA7r4AQJdz7At3CRvuawcexg4Z+RRDGPXBN+0sbmI9/fuiFZWYyHNNGoOC2k2 G0peRpzXQ1BYmS5+m+Kv1VBl7S1UDJ/xUxPvawvEU0OLah6f93pW6cAYiF1gBtsJ/iymqPGJftVQ 6romSamcEUhZhjNE77eWIMP2/YGkcQqcSf7Dx+nw9TSQH3nu7nlkVhXmklEMfTczCBZ7wrwbWiaD gg6eXqBoLCrU6FZupp2s4CkpujdBf4K8PghxSQtAjGqbSTYO5HUey+sm5CFhHoSgJhYV22YAlae9 G65jkpfYMSL5FsiX4T7dz1ZBeArHlWGpNEQfeF7G+HC6Ag6DObVfjoYZ6EL2SBfqAP1l6Qk/zDxc xylOwesx4ljnfpRZQxEEQ+wn8u/84iaAdf9zJ/DbRbS28fvYnU+9+hVSDjymmrlrP8PXPAX4cxru JR7R0jgC7x/27lrI1Mmwx2U8l616Bo/bPdi/P1x5yjtBSsx6hjtgvTQes2vxY2xhgbqDsAjEMZ9w kmDLYUm5Qzc8hxSXJJbDDBnrm9aexshwdzDfWTKyEjllp7w5eNlED4zN9R1d/2AhH5yaGLtS5ART 6X7P+pt2WfNDJPUl0EdiKH/QCKJoIW5HNV+P58MG/kEJ90ShygmoDTDo9/kHO/GyoKhP9qcMYbKs kT9fkO4QLU8zHdvsGC/i4dfsPSkwMSTfZSMcOmxqnPp5fw+Hs+eCm4dUM+PhMf2X346r0sTSIsxy jzFga/x+pGFsrts+cp+T4DIWqVJhjC7ixgluzohirA4Ls0PpAqiRRcpQxyAmgpCe7DXF86Hw4D4F hDrhuOd6ncggFHPzJ+KcjPNNlvG6BT8ZPt1T6hRtRYi2d+11OYohvKy75EUsRRkQ42wfb5HdvFu+ ppcj8uAT/UEZIoFydx+T0Y3Z7VQ0+7e1Zih+UCAdBo9WvpcmOOKG8Wn5SOwxv3+MDq6VE0fzq8Ec 4CD0Puk4oCYhLadHdHYckt1zrqNStPQcXXMGOF7MpyRZKBD/Zispp+lTbYFlSGaZ0TRU/Apcqd4/ mP841NJN2b5/qCV9x08mxbbWxTJjuahRoIE02NJK4gkTUiLNlJCg581RodW2xuiXjfjPHCgTYU9y WD6eQkwMCz89EmJ1K5IgL5ELySUjC1B81ZCWdJ7NANeF9wynHwuoQfCnn8xUZ+GyAHOh+z3wP10Z uMtYsIVPlCtcWqpt5yPfLJKSsgs5r8sxSXUcPx0vThdeEmQxt2/dSbWGBDencKVDiVpQOHX9erOL PBKZ5YfIUULA93ZXgRsZEKgtB0bcCLCOkmXAPh9mxcROBsTxHv/3TggcjTlBFCLpAaUO1pvRcRWv AMOpizCWpzhaWcHDLdhGVPDgUqp19mHrFDt3Jj4OVrMUvFA65Ff5eu19lGyy+TSXklXS+TTxY2xB PO78Ap2QYxz+WbvKElvMgA8rqXJ4C0a+SZh0mEXa14mxIvXalwmhA4DZOYtdxJqoQb/Os8CzbAIW EC76JaJ7xuq4RMaJN9YaqVjzOhBXdgZy97ERQ5yaucecX4p5fLW4BOOcqle6aT6bidLxqKmXZZ88 1m1eU7mYvjoIEujuDs9wKxfSwxZ3F3Ksa/MLacYXso0YMOgDF84zflFEmBeGBLqFPkJWle0b3SR/ WQHKSBnZLhqCSVB5RRYfISaT+e6yIT5Mwtk6xvjqKTUl3pT3MJyaG2qU8RSDqA7nTHHxM7s3h7Z3 AXRVj7AYgVbiU+207Hly/7KPyNfFjHoUimZKJIWSf3hjTYox12Hcsc3LN1jbuwvMfp+IgBQMjwjQ GQ1VsIE74VnPPE/GKtf1g3CTYZ2NWhUPk01OCA09Che4lUznYzEW0lTBgt6nZE4tgtVpmzLPyhtH FUub8ASDRsaFoyyeiaEUMXvRXuDCyNZR8tKgkzKKE1m9WtE2Jbu2qXdBW+NSk8Nb1ihktGKd5l0X /jsvahkzGuwAMODyvDlhMppeLdZc6m84TKVeOYj04NFuBsFcT02IX6uI7EN3duHSpLUELgFL4ze8 QqEITkBMAVBYyEGRAD0Kc87a4CcHS9UQvHZ6ioXkVsXEVgWNR0vxYmKnmEWWNM1mfm/HfcmqDAfF xGquwN+qmJizfuDT/s3eHeMYLPrzQ6d0WvGi5OCoLsz+ILifc3AOiBkH70p+IexKH6nkl5lAMW9s 4p4+GJf5iLw7nlJAfM/PTfb15d5Hm/xXF8PFrpagqHAbdsPrOKj6HHBWP4My0iaNrvPjQIP18Yf9 jjHGKmuVbo2Zktekp5TZyaKR9dlA+22Vx5qpZPHriWZQp+Z9syC6oFJqXDU3gEitw/AoVKTzfHFK UfzWfS2h22Tv9xOhbxDEKZ5ejO19i0BqmLaNjJRFIPFrrbMSATY0Z4P6bHZN/NZ8G/k+sMBlfFbP ym6FnFRfNr+dPy0dYrXZn+2MVEkXkR6wjTqflyHNaWWPbld2h2ZnYxJS6N3egmX+scIS1SRZ9lni 7Vf9xWy1bUY4XIjviSEDAWYxCMAsx0FZ3Gw49pW3VjhSTG5l4TzFzhGbUariJCm4oCir6bTswBg3 VWortwjuhqJeNUHlxoqOz3bV7FRax/LqYRHNmZWDRXaw0AkV3ewFAQRM8PjV585No8EErukymMBM AhhliXlgMJJSdGNsuv9WkMo+elsbkbICOOdUvKcNcdKcom3LQ9SZKhZizu+7QG86/+uxX7Pj/Z1e 9K6bdXel9KKxZdpdxSd8mlQY8eammbIVcvdOyVANttTeWPCrjq1quI781Wa8xe9WV+7yATRWGUcE nDKYVndrTA0hR6xy9oFsDSHDWMtyYJkMmCzk2tQCfIplW3+LmMsENcKUpYKqxVHLJHJT9XsdoS3o 0RPZzSkU2zIGId2VFvTA8friyaCn3fsDc98J7vx1LbRJxhyVmcSZor5dC4Bj4MgeTy7yItbxahRH aXg3b3bXunUZCoWC47Zqizy9eDfw9eDCUdWM/6+Ldxe4wrqTcR3rtxu4DqcAgtpdAPk7Vt+Zzs7M rydp8luEHa8jxrpmauUoiNyfZAPwwyELqnSYopNPtOJy59eBDaDEWt2t5jJ10n4uA55G3JmPY16g EVNTQhsGdGkZ1P8phPRWIL2GesYuI4dleGk8Pxm/tOORKOVxc//MhmM09eEKmOOezl1awLrVty1g XjJHw+T8ZgW4XS1zETmAiaNzbkxUsoJmnrGkQRx80aTDhx1cKxrSaVXFMipgObQkWYZ3nJ+x0XER yZXNkBmL/0c2gv+IMY5SG+WUgIAAjSthys+bn1t+AU0S5i7DMXFFFri84qnsreatQnu59yGouOzJ 8rcqPJ/xe4WNur7OIqYPVW8+WYCwoZHvbVCKo8gZpoONDf+KYUcPyyRXcyzyBVMgllZRoafRf5xq 9ENe0ukENLeSKvtVMzfcFq/pHUo0ivKJGY42GZLdVT9ZMAcnZJYuVmEwIx66ctv6+JxQzJImdGSg v2772tX/3d8schdtObM7uxKtOAvbztRos1RUQX5mjAuIhCMZnbUAfJrbKlC/FkfoZ0CLKSnqklIR r1GBtlnxZAkhHanWv+tq/fsZ5yuDOmhCIYyLeoxrMCuHelk7A07RWN1nuPGAYxjo410wfvS8+dkr kfKa0HiA3cSnCdYV8U8T3MQ0x1nCir1T8Xyy9R/4JWAvrHWNAKH38vm/b0EgYdk0pQKxc7LiNJ+1 xNld6rFI6Aoqy0LzS6t3jWtD8XD0PrQBo6MQ7gYsxZgzj6r4ZkzrsrZJgLPEUqJj7s80voO6F8Ds 2k/m9CVo7xIUwxocacm0FKMUGrtVtWWutow9PHriJSsKGajupFdmJOoA1EDBYQamkkPwdf3IgsH4 spWCGX1KzINzMXskD032t3BrQeVchDZYGHeJ4mYTbyh4HVZScGr3bTv2mGdK7mP0+QU+NeQ55DLk NzsVcdLnMEMLmuUxDdIEhAOZLGsAaPrHHxpy7Cp5yTRY7BpdPWwL+1E6RPC8bEkyeu0ktdodvemz X1VeWkGfZ9jyK6WWBtuo30ssSsOkvOYZxnhanmFXGFDJvhHZSdv3bPZvJB5lHPbXdM843L9nk1oH QJuLWFhbm4u4/pS5iMRp+e0ppWzzPDCM9zGRV/TtUQvjnU6DN3tLafpseqwtvyMsc/E4GqgSxFo1 8/tO3FD1Hr4Afkj8+X8fodz/hr9sRNMuMw4PSQIP8af37/3rPeCL/uzP93x0cFvSmXFYOtmcXcOT hGEH25Pn976698d7Zj7D/9V/Hl6f/eh+l3FSWpxBB5OB1y2mjp3dvwb64NtQwnzTYrgpoLtaPWJh qJZ390/KZ4nKnswJsCKPVtmzj2vaUQAm4k80eXGYwExejbHEJvyWOA81VCxbMshgLZx2SvAz6GZT mo+yDLDF7KxM27cJpJKRVgum9nXG5/oV2BNMPZd12VZkWh5GG7dJlV0Mcls87LiA0epboIV7KqSI MwrLKPtbCea44cNQqUj69sNQMErOef0eLXYUt+hnNre/2Sei+FUHPGEBvNnGaHa6Y2CBn1gYqa6H ETVPMt2fajYzpUabIe1cZtp1NgkNGNaOrzyQ+Ki0VLIYRqoVInpcXsTMU84g/HgmWPkbbXfLcqo/ HpvjR8xuKKtdZzsSS7WsdlaDpERNzbKa1JktadrAYj8fH5JwY3ImXPpzSV0Ai08Z5Ae393j9tN4y Jbt9QnePkqluM0TNqQEXvxpbPMT1Hc+wy8msGkstLN1UlmaFXPmS+fBrUejVUNtIwOAmC/B+4Hri sd9aZkHnW6a71aZ1UT6eKC7ZCgym/JXeusICHaIa40sl7YXcWmbKwXKP2hjHr74peHq34tMJHZRH 9Qi5nObqki6n14jOjyiot94oohI00MUKj3wbG9/lh14f2W07XepRidFcZnvraLVx6/F1+0EZBrVp ppy92Af/O3wjkeX3KKWG5S4UIxV+si3uzOhqZLN4WCjFSX2kT5nt7NRspkcmrU30ku4fQ1sY9aA8 Q8CS/VaG+jOCGRtBufJfvxoS9I/KMC8qRnxQNE0AxYd+zuljxDTQsharVFGQFDzy3CtmnfexN9Xq TGWtyjeYhnGw6No1R99CPy48iITp3SmXeCrbhaZpvSxBMc8JETgKT2tKBIY5A59K7RbR47ioBUIl /Kwb8VEkOn3TOjvfAT8fp8W18E0AP2wBZPOpIpbV8CH68MgcmmW2ESgBPxTIqxiuX+Rmdr+uskh3 MjcHybOeWYRzx9dHahyaQ03w8tuQa2fM9dFHvW7WMvrYuTO3FezrZ9JDc53woY1qounHDMoVXHg9 PUmyp1RubQJ2uyzNUcBulEmdHKJIuMLREBlw/vXe/wMmMOoSZW5kc3RyZWFtCmVuZG9iago0NyAw IG9iagoxNDUzNQplbmRvYmoKNCAwIG9iago8PC9UeXBlL1BhZ2UvTWVkaWFCb3ggWzAgMCA2MTIg NzkyXQovUm90YXRlIDAvUGFyZW50IDMgMCBSCi9SZXNvdXJjZXM8PC9Qcm9jU2V0Wy9QREYgL1Rl eHRdCi9FeHRHU3RhdGUgMTIgMCBSCi9Gb250IDEzIDAgUgo+PgovQ29udGVudHMgNSAwIFIKPj4K ZW5kb2JqCjE0IDAgb2JqCjw8L1R5cGUvUGFnZS9NZWRpYUJveCBbMCAwIDYxMiA3OTJdCi9Sb3Rh dGUgMC9QYXJlbnQgMyAwIFIKL1Jlc291cmNlczw8L1Byb2NTZXRbL1BERiAvVGV4dF0KL0V4dEdT dGF0ZSAxNyAwIFIKL0ZvbnQgMTggMCBSCj4+Ci9Db250ZW50cyAxNSAwIFIKPj4KZW5kb2JqCjE5 IDAgb2JqCjw8L1R5cGUvUGFnZS9NZWRpYUJveCBbMCAwIDYxMiA3OTJdCi9Sb3RhdGUgMC9QYXJl bnQgMyAwIFIKL1Jlc291cmNlczw8L1Byb2NTZXRbL1BERiAvVGV4dF0KL0V4dEdTdGF0ZSAzMSAw IFIKL0ZvbnQgMzIgMCBSCj4+Ci9Db250ZW50cyAyMCAwIFIKPj4KZW5kb2JqCjMzIDAgb2JqCjw8 L1R5cGUvUGFnZS9NZWRpYUJveCBbMCAwIDYxMiA3OTJdCi9Sb3RhdGUgMC9QYXJlbnQgMyAwIFIK L1Jlc291cmNlczw8L1Byb2NTZXRbL1BERiAvVGV4dF0KL0V4dEdTdGF0ZSAzOCAwIFIKL0ZvbnQg MzkgMCBSCj4+Ci9Db250ZW50cyAzNCAwIFIKPj4KZW5kb2JqCjQwIDAgb2JqCjw8L1R5cGUvUGFn ZS9NZWRpYUJveCBbMCAwIDYxMiA3OTJdCi9Sb3RhdGUgMC9QYXJlbnQgMyAwIFIKL1Jlc291cmNl czw8L1Byb2NTZXRbL1BERiAvVGV4dF0KL0V4dEdTdGF0ZSA0MyAwIFIKL0ZvbnQgNDQgMCBSCj4+ Ci9Db250ZW50cyA0MSAwIFIKPj4KZW5kb2JqCjQ1IDAgb2JqCjw8L1R5cGUvUGFnZS9NZWRpYUJv eCBbMCAwIDYxMiA3OTJdCi9Sb3RhdGUgMC9QYXJlbnQgMyAwIFIKL1Jlc291cmNlczw8L1Byb2NT ZXRbL1BERiAvVGV4dF0KL0V4dEdTdGF0ZSA0OCAwIFIKL0ZvbnQgNDkgMCBSCj4+Ci9Db250ZW50 cyA0NiAwIFIKPj4KZW5kb2JqCjMgMCBvYmoKPDwgL1R5cGUgL1BhZ2VzIC9LaWRzIFsKNCAwIFIK MTQgMCBSCjE5IDAgUgozMyAwIFIKNDAgMCBSCjQ1IDAgUgpdIC9Db3VudCA2Cj4+CmVuZG9iagox IDAgb2JqCjw8L1R5cGUgL0NhdGFsb2cgL1BhZ2VzIDMgMCBSCi9NZXRhZGF0YSA2MiAwIFIKPj4K ZW5kb2JqCjcgMCBvYmoKPDwvVHlwZS9FeHRHU3RhdGUKL09QTSAxPj5lbmRvYmoKMTIgMCBvYmoK PDwvUjcKNyAwIFI+PgplbmRvYmoKMTMgMCBvYmoKPDwvUjgKOCAwIFIvUjExCjExIDAgUi9SMTAK MTAgMCBSL1I5CjkgMCBSPj4KZW5kb2JqCjE3IDAgb2JqCjw8L1I3CjcgMCBSPj4KZW5kb2JqCjE4 IDAgb2JqCjw8L1I4CjggMCBSL1IxMQoxMSAwIFI+PgplbmRvYmoKMzEgMCBvYmoKPDwvUjcKNyAw IFI+PgplbmRvYmoKMzIgMCBvYmoKPDwvUjgKOCAwIFIvUjExCjExIDAgUi9SMjkKMjkgMCBSL1Iy NwoyNyAwIFIvUjI0CjI0IDAgUi9SMjIKMjIgMCBSL1IyNgoyNiAwIFI+PgplbmRvYmoKMzggMCBv YmoKPDwvUjcKNyAwIFI+PgplbmRvYmoKMzkgMCBvYmoKPDwvUjgKOCAwIFIvUjExCjExIDAgUi9S MzYKMzYgMCBSL1IyOQoyOSAwIFIvUjI3CjI3IDAgUi9SMjQKMjQgMCBSL1IyMgoyMiAwIFI+Pgpl bmRvYmoKNDMgMCBvYmoKPDwvUjcKNyAwIFI+PgplbmRvYmoKNDQgMCBvYmoKPDwvUjgKOCAwIFIv UjExCjExIDAgUi9SMjQKMjQgMCBSL1IyMgoyMiAwIFI+PgplbmRvYmoKNDggMCBvYmoKPDwvUjcK NyAwIFI+PgplbmRvYmoKNDkgMCBvYmoKPDwvUjgKOCAwIFIvUjExCjExIDAgUi9SMjQKMjQgMCBS L1IyMgoyMiAwIFI+PgplbmRvYmoKOCAwIG9iago8PC9CYXNlRm9udC9UaW1lcy1Sb21hbi9UeXBl L0ZvbnQKL0VuY29kaW5nIDU1IDAgUi9TdWJ0eXBlL1R5cGUxPj4KZW5kb2JqCjU1IDAgb2JqCjw8 L1R5cGUvRW5jb2RpbmcvRGlmZmVyZW5jZXNbCjIvZmkvZmwKMzAvZ3JhdmUKMTQ3L3F1b3RlZGJs bGVmdC9xdW90ZWRibHJpZ2h0CjE1MC9lbmRhc2gKMTY4L2RpZXJlc2lzCjE4MC9hY3V0ZV0+Pgpl bmRvYmoKMTEgMCBvYmoKPDwvQmFzZUZvbnQvVGltZXMtSXRhbGljL1R5cGUvRm9udAovRW5jb2Rp bmcgNTYgMCBSL1N1YnR5cGUvVHlwZTE+PgplbmRvYmoKNTYgMCBvYmoKPDwvVHlwZS9FbmNvZGlu Zy9EaWZmZXJlbmNlc1sKMi9maS9mbF0+PgplbmRvYmoKMTAgMCBvYmoKPDwvQmFzZUZvbnQvVGlt ZXMtQm9sZC9UeXBlL0ZvbnQKL0VuY29kaW5nIDU3IDAgUi9TdWJ0eXBlL1R5cGUxPj4KZW5kb2Jq CjU3IDAgb2JqCjw8L1R5cGUvRW5jb2RpbmcvRGlmZmVyZW5jZXNbCjIvZmkvZmwKMTUxL2VtZGFz aF0+PgplbmRvYmoKMzYgMCBvYmoKPDwvQmFzZUZvbnQvR0tLS0tDK0NNU1kxMC9Gb250RGVzY3Jp cHRvciAzNyAwIFIvVHlwZS9Gb250Ci9GaXJzdENoYXIgNTQvTGFzdENoYXIgNTQvV2lkdGhzWyAw XQovRW5jb2RpbmcgNTggMCBSL1N1YnR5cGUvVHlwZTE+PgplbmRvYmoKNTggMCBvYmoKPDwvVHlw ZS9FbmNvZGluZy9CYXNlRW5jb2RpbmcvV2luQW5zaUVuY29kaW5nL0RpZmZlcmVuY2VzWwo1NC9u ZWdhdGlvbnNsYXNoXT4+CmVuZG9iago1OSAwIG9iago8PC9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVu Z3RoIDE3MD4+c3RyZWFtCnicXY+xDsIgEIZ3noI3gNI4mDQsdemgMeoL0ONoGHoQSgff3kKtg8NP cvB/lw/RD5eBfObingI8MXPnySZcwpoA+YiTJ9Yobj3k71RPmE1kor+a+HpH5FsB3T7fzIzicTrX m2ZnIFhcogFMhiZknZS6c04zJPv3pHZgdEfT6RolldKsazewRMlWVfwolk1F6TDgsKaElKt39So+ nvD3tRhiofgW9gFhdFZkCmVuZHN0cmVhbQplbmRvYmoKMjkgMCBvYmoKPDwvQmFzZUZvbnQvWUFT UUVaK0NNU1k3L0ZvbnREZXNjcmlwdG9yIDMwIDAgUi9Ub1VuaWNvZGUgNTkgMCBSL1R5cGUvRm9u dAovRmlyc3RDaGFyIDE1L0xhc3RDaGFyIDQ4L1dpZHRoc1sgNTg1CjAgMCAwIDAgMCAwIDAgMCAw IDAgMCAwIDAgMCAwIDAKMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMAozMjldCi9FbmNv ZGluZyA2MCAwIFIvU3VidHlwZS9UeXBlMT4+CmVuZG9iago2MCAwIG9iago8PC9UeXBlL0VuY29k aW5nL0Jhc2VFbmNvZGluZy9XaW5BbnNpRW5jb2RpbmcvRGlmZmVyZW5jZXNbCjE1L2J1bGxldAo0 OC9wcmltZV0+PgplbmRvYmoKMjcgMCBvYmoKPDwvQmFzZUZvbnQvR1RCUk1XK0NNUjEwL0ZvbnRE ZXNjcmlwdG9yIDI4IDAgUi9UeXBlL0ZvbnQKL0ZpcnN0Q2hhciA0MC9MYXN0Q2hhciA2MS9XaWR0 aHNbIDM4OCAzODggMCAwIDAgMCAwIDAKMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCA3NzddCi9F bmNvZGluZy9XaW5BbnNpRW5jb2RpbmcvU3VidHlwZS9UeXBlMT4+CmVuZG9iago5IDAgb2JqCjw8 L0Jhc2VGb250L1RpbWVzLUJvbGRJdGFsaWMvVHlwZS9Gb250Ci9TdWJ0eXBlL1R5cGUxPj4KZW5k b2JqCjI0IDAgb2JqCjw8L0Jhc2VGb250L0hUT01VRytDTU1JNy9Gb250RGVzY3JpcHRvciAyNSAw IFIvVHlwZS9Gb250Ci9GaXJzdENoYXIgNzMvTGFzdENoYXIgMTE5L1dpZHRoc1sgNTA2IDAgMCAw IDAgMCA4NjgKMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMAowIDYxOSAwIDAgMCA1NDIg MCAwIDAgMCAwIDAgMzYxIDAgNzA2IDU2MwowIDAgNTMwIDUzOSA0MzEgMCAwIDgyNl0KL0VuY29k aW5nL1dpbkFuc2lFbmNvZGluZy9TdWJ0eXBlL1R5cGUxPj4KZW5kb2JqCjIyIDAgb2JqCjw8L0Jh c2VGb250L01DU0RHVytDTU1JMTAvRm9udERlc2NyaXB0b3IgMjMgMCBSL1R5cGUvRm9udAovRmly c3RDaGFyIDYxL0xhc3RDaGFyIDExNS9XaWR0aHNbIDUwMCAwIDAKMCAwIDAgMCAwIDAgMCAwIDgz MSAwIDAgODQ5IDY4MCAwIDAgMAo2NDIgMCAwIDYxMyAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMAow IDUyOCAwIDAgMCAwIDAgMCA1NzYgMCAwIDAgMCAwIDAgMAowIDAgMCA0NjhdCi9FbmNvZGluZyA2 MSAwIFIvU3VidHlwZS9UeXBlMT4+CmVuZG9iago2MSAwIG9iago8PC9UeXBlL0VuY29kaW5nL0Jh c2VFbmNvZGluZy9XaW5BbnNpRW5jb2RpbmcvRGlmZmVyZW5jZXNbCjYxL3NsYXNoXT4+CmVuZG9i agoyNiAwIG9iago8PC9CYXNlRm9udC9IZWx2ZXRpY2EvVHlwZS9Gb250Ci9TdWJ0eXBlL1R5cGUx Pj4KZW5kb2JqCjM3IDAgb2JqCjw8L1R5cGUvRm9udERlc2NyaXB0b3IvRm9udE5hbWUvR0tLS0tD K0NNU1kxMC9Gb250QkJveFswIC0yMTYgNjM4IDcxNl0vRmxhZ3MgNQovQXNjZW50IDcxNgovQ2Fw SGVpZ2h0IDcxNgovRGVzY2VudCAtMjE2Ci9JdGFsaWNBbmdsZSAwCi9TdGVtViA5NQovQXZnV2lk dGggNTAwCi9NYXhXaWR0aCA1MDAKL01pc3NpbmdXaWR0aCA1MDAKL0NoYXJTZXQoL25lZ2F0aW9u c2xhc2gpL0ZvbnRGaWxlMyA1MCAwIFI+PgplbmRvYmoKNTAgMCBvYmoKPDwvRmlsdGVyL0ZsYXRl RGVjb2RlCi9TdWJ0eXBlL1R5cGUxQy9MZW5ndGggMzEyPj5zdHJlYW0KeJxjZGBhYmBkZGR39g2O NDQAMVV/SDP+kGH6Icvc/Tvnp9DPBNZuHuZuHpaV39cKfc8R/J7J/z1NgIGFkTG/tGWic35BZVFm ekaJgkaypoKhpaW5joKRgYGlgmNualFmcmKegm9iSUZqbmIJkJOjEJyfnJlaUqmgYZNRUlJgpa9f Xl6ul5hbrJdflG6nqaNQnlmSoRCUWpxaVJaaouCWn1ei4JeYm6oAcZ0ehHLOzy0oLUktUvDNT0kt ystLTQeanp9XnJNYnMHAwMBoxsDYxcDEyMhi86OD73fOgl/88xm/y/9oZ/7J9dNSdPLM7t7uPo5J rTNq6ztaa1vk/oT+/dtc293Z3SHZPKl+xvS+iTMnyfEVL/5pv5Dtt/Q09s1cm7nluFjE0up5ODfP 5uEBYl4GBgDE2G2KCmVuZHN0cmVhbQplbmRvYmoKMzAgMCBvYmoKPDwvVHlwZS9Gb250RGVzY3Jp cHRvci9Gb250TmFtZS9ZQVNRRVorQ01TWTcvRm9udEJCb3hbMCAwIDUwNyA1NTldL0ZsYWdzIDQK L0FzY2VudCA1NTkKL0NhcEhlaWdodCA1NTkKL0Rlc2NlbnQgMAovSXRhbGljQW5nbGUgMAovU3Rl bVYgNzYKL01pc3NpbmdXaWR0aCA1MDAKL0NoYXJTZXQoL2J1bGxldC9wcmltZSkvRm9udEZpbGUz IDUxIDAgUj4+CmVuZG9iago1MSAwIG9iago8PC9GaWx0ZXIvRmxhdGVEZWNvZGUKL1N1YnR5cGUv VHlwZTFDL0xlbmd0aCAzNDU+PnN0cmVhbQp4nGNkYGFiYGRkZHP2DY40B7FUfkgz/pBh+iHL3N39 o//HYdZuHuZuHpaF3y8IfU8W/B7H/z1KgIGFkTGvuKndOb+gsigzPaNEQSNZU8HQ0tJcR8HIwMBS wTE3tSgzOTFPwTexJCM1N7EEyMlRCM5PzkwtqVTQsMkoKSmw0tcvLy/XS8wt1ssvSrfT1FEozyzJ UAhKLU4tKktNUXDLzytR8EvMTVUAu00PTDrn5xaUlqQWKfjmp6QW5RUUZeamMjAwMPEbMDCUMHYx MDMysuin/+jg+3F3/YIfEvMZb/5wYP7R/71P9Duv1svfXL95dLR+c/7mfaP7nes7z6s33znl+L7f 3bLgR+F8xt3f+5m/b/uRIzp5Ts/k7kkcq/IX56TW51S3yf2W+OPa1dle190lWb+qcfKknt5Zk+T4 ihf/tF/C9lt+Ovserj3ce+bz8AAxLwMDAG87gRAKZW5kc3RyZWFtCmVuZG9iagoyOCAwIG9iago8 PC9UeXBlL0ZvbnREZXNjcmlwdG9yL0ZvbnROYW1lL0dUQlJNVytDTVIxMC9Gb250QkJveFswIC0y NTAgNzIxIDc1MF0vRmxhZ3MgNjU1NjgKL0FzY2VudCA3NTAKL0NhcEhlaWdodCA3NTAKL0Rlc2Nl bnQgLTI1MAovSXRhbGljQW5nbGUgMAovU3RlbVYgMTA4Ci9NaXNzaW5nV2lkdGggNTAwCi9DaGFy U2V0KC9lcXVhbC9wYXJlbmxlZnQvcGFyZW5yaWdodCkvRm9udEZpbGUzIDUyIDAgUj4+CmVuZG9i ago1MiAwIG9iago8PC9GaWx0ZXIvRmxhdGVEZWNvZGUKL1N1YnR5cGUvVHlwZTFDL0xlbmd0aCA0 OTQ+PnN0cmVhbQp4nGNkYGFiYGRkZHP2DTI0ALFUf0gz/pBh+iHL3P2772fqzybWbh7mbh6WtT+S hb4nCn6P4v8eKsDAzMiYV9zknF9QWZSZnlGioJGsqWBoaWmuo2BkYGCp4JibWpSZnJin4JtYkpGa m1gC5OQoBOcnZ6aWVCpo2GSUlBRY6euXl5frJeYW6+UXpdtp6iiUZ5ZkKASlFqcWlaWmKLjl55Uo +CXmpiqA3aYHJp3zcwtKS1KLFHzzU1KL8hgYGJhtNTQZGOQYOBm4GFgYGVncFv7+0cH3c+53yc3f 9TYzHv6py/zT+ftt0VnzuufPr+iulf/zmq22oru8fF73LPkfr36Hic6EyNTI/3nJVgORmSnP90Pi d9+CX8HzGd8dZf5+/3eLaHdfd2/VnN+C34Wyvwd2f9ft/u608bvTd/7vgjOmd/d293FMau9rbTR0 /y0cIBfxm6n+N3O3ebfttN+8h36zHv/N/9BrajfHxP6+SUhGf68Gmr31e59o982G77wh31n9v/Ob nmns5mhtb2/t6O6cVyn/VuPIb+Pu36ndv+3Tfrv8FvgtVFff3dndwdHa3z5x6tPz34WPye37zjT9 O3P3fQ6+0oU/nOd8z5s2cSHb76Tp7Ku4LnDLcbGYz+fhXDiFh+fCfB5eBgYAEVnReQplbmRzdHJl YW0KZW5kb2JqCjI1IDAgb2JqCjw8L1R5cGUvRm9udERlc2NyaXB0b3IvRm9udE5hbWUvSFRPTVVH K0NNTUk3L0ZvbnRCQm94WzAgLTIwIDgyOSA3MDNdL0ZsYWdzIDEzMTEwNAovQXNjZW50IDcwMwov Q2FwSGVpZ2h0IDcwMwovRGVzY2VudCAtMjAKL0l0YWxpY0FuZ2xlIDAKL1N0ZW1WIDEyNAovTWlz c2luZ1dpZHRoIDUwMAovWEhlaWdodCA0NDIKL0NoYXJTZXQoL0kvTy9hL2UvbC9uL28vci9zL3Qv dykvRm9udEZpbGUzIDUzIDAgUj4+CmVuZG9iago1MyAwIG9iago8PC9GaWx0ZXIvRmxhdGVEZWNv ZGUKL1N1YnR5cGUvVHlwZTFDL0xlbmd0aCAxNjg5Pj5zdHJlYW0KeJxtlHtQU9kdx28IsFdl6a7d dGTq3putStFxEDrb+tiyujAy4yhCBS10Z5AACbI8EpKbXBIgIS/z+CUkgTwx5GUei6C4QEFFsbi4 dXHH0Vpt6+p2OrMdp9Xta6c9l7l22rvLdKad6T9nzjl/nN/3+/19foeHZWdhPB4vt6Kq6tDur3bb mG/zmM1ZzOt8oFfvrdbmQB4f8rLHN+c+34jUr6Lmb6Djr2B8Hq9bYaiQytTy9rZTlLCoZbuwdO/e 3TuF3ysp2St8p0ssb28RdQurRNQpcZeI4g6dwlppS7uYUguLfniKomT7du2iabpY1KUolsrb3t6+ U0i3U6eEx8QKsVwlbhVWSrsp4VFRl1j4tbbir9cKaZdMSYnlwippq1jejWHYhm6pXEEdokXi6k4M q8ZqsFqsDjuO7cDqsXKsEivBqrA8ziOWjX3IK+BdyCrPWuAfyd6Y/UHO5pyBnGeMNX/1hD7DkBke s/u+8wEf5a8ILFqzHKy4ckx/ZuxM0Osm3N6RCXfMHfFf9iQ9cU/cnfDPOkfen83MXLn+EPCbjvre 6iaW3yciB6UWA2jwE/PvLf55HhGjQS1YB+zmQQtBvdXU3AK4yhKKJdzBsUtk4Nzs3+FD/Pnb4RN7 autbugjT3Zp4MzQB1amllJKBY3Aa14ZgKOQYSg8Tox9Frk4DnhpWynoNEpOMNMn0zaeVeD7z8zX5 H3+Glp/wmQyKCBB/z+3tbBErZEn29e/+8gDioS1oK9qEthLsNOsQNDRMPJqNfDG9TM59fDN1CfCl y5J3FLqikwdJcU11RwNwr6b1MXT1aYiL5c1nfKRDjQKHJ/F7p5uzfW3irH8kHZ0DHyTtUW2HQScF Na4M9ycSk5GfXq+L1f+4UdVwklDfOupTgATkVJ+Uah340f/6uRW58n/8dLCvbfqv+Eej3ugI4fT4 5z1JTtSUPjP/FG35dCrDQ8UraP9jPlPB5Al6zH0qoHEqagj6PvAsflIRP8qWSNmXOiUxRUhHpOgx y11dzHJbBw2gGRSL5K3Kn4AOWuCYl5qcdMWTkMGT6oCqu5s6WX1b8hwdOY82Tj8tHJMMEwan3GV2 SobVMYhDYiwdD6XDF5xhiMF1a7yd01TBxf/yFCqP8v7wkI/sDCn4a24kCPGQFjTkztyLqMjhdrrB VTA2EKLl/ZoeE2GSBxdOsuX4ttxeLSgHAjBG/jG3hh00yw1toC2ouda2jPgrSBj8ih6d3aYxEtIj 9bV1HD0DwSmfK+b0kfnMEEwxaIrHlDJ/EXjPO70ciMkAxLwmj0Elt4KKVILCrgSASgfAtbwtSpAP KQE393Ml/RB3RMEWJqO2YTsMgtlmshnZgheZTcb3rPoDgMv0oLSD9sz4QxeMk3ftcUha41DgGeWM 6YC2qcBJk5QTXOAFB3hco3j+6p01ENHWB0zjl3wmge4LhtOBBXDj0b6Aplet05gJq1EvMsk5tm39 tdo6m9He7aKNvYoubR+taQe8tT70m8XMg+giGZ53eSGMLzRfPF7YyG7WrJHj9g8Ryc/mpmcAD48M KiiD8rSWPMYWAg2dOLv+H/1Lkatw5xKRaLyhvAWfw/yvo7Nzv02jV+Ey/rDJZeqRyno0PuOwmThL B6XQgWtFLLDf3Af3w2nXmdAykc/8a83FLY6tfcxGgWqyPfUu4Oxr7LfYN9itOz6p/N3SwrnpGTJS fVOfgilIxsfOxaeDy+DC14bdIjMRund7a0SA95ji6fDI1HCKHE77Zt3x6K82eVKBK1wicbWvT0Pp pGbiMOsTmKRKWtlrMLZ0NAEuaUv94mfvo6zEDHn508XRDOD3IvsHLTaT3cp1fVqfQZIMKs3w7jxB 5+f4iEK9ggw8ci5FHqRCCzCO36ibrGTz2B/sYvcXrryJ1qGyR38KeQx+o9lmMxqJsl3sOlADXt0y 8zgE0cANciQjmEXbED/AlZq/qBTvYMugicxfZejJ1cIJ3r2/MUtf8FfvMWUCVMrmoJfZg6yR7WMp Vsl+H23gbg4gA+pD3YgmXohelAjeKL2PihZD6DtPUS5558nzq58D/uWzQ+y28k62sFhIHnyrpLmM +2PQP/WZ1XULvBVubi6s7hQ4nENBcOBui1dH7zHa5ITJPmAHFT4QAv8CmIwmm9lmINhXXhisevsg 6AsOL3cunB0fuZQiYhdDH/2nATaz2kJoG3oPc1nKTMmz/qHIkJ/Mp6NMhc8XQLJoLtvke2li/eMN xPrs3dG8dROuvDwM+zfCdGcKCmVuZHN0cmVhbQplbmRvYmoKMjMgMCBvYmoKPDwvVHlwZS9Gb250 RGVzY3JpcHRvci9Gb250TmFtZS9NQ1NER1crQ01NSTEwL0ZvbnRCQm94WzAgLTI1MCA4ODkgNzUw XS9GbGFncyAxMzExMDQKL0FzY2VudCA3NTAKL0NhcEhlaWdodCA3MDUKL0Rlc2NlbnQgLTI1MAov SXRhbGljQW5nbGUgMAovU3RlbVYgMTMzCi9NaXNzaW5nV2lkdGggNTAwCi9YSGVpZ2h0IDQ0Mgov Q2hhclNldCgvSC9LL0wvUC9TL2EvaC9zL3NsYXNoKS9Gb250RmlsZTMgNTQgMCBSPj4KZW5kb2Jq CjU0IDAgb2JqCjw8L0ZpbHRlci9GbGF0ZURlY29kZQovU3VidHlwZS9UeXBlMUMvTGVuZ3RoIDE0 OTY+PnN0cmVhbQp4nK2UfWwTdRjH7+gotzHK1FRWwLuqAbfIeItKRnhRZlBeBsimhvAyyla2AV3H dqXr6Laur9d7rtd2vbYbe+O2waDIBkxwgsjkXSUBgcUXjNEQEtE/jJr4u3LEeNs0JmpiTPzjcne5 J8/v+3y/n+dwLGUchuP4hLz8/BXz5o48zpSm4dL0cdITKpD5B5OSzvGQroL0lMPTJ6Q+iqyPoJLJ aEMGpsJxs8WdZ660VZWXltH6rOJs/bzc3AWz9PPnzs3Vv2QyVpUXGyr0+Qa6zGgy0MrLLn2Bubjc SNv0WYvKaLpy4Zw5Vqt1tsFUPdtcVboke5beWk6X6dcbq41Ve4wl+uXmClq/xmAy6sfUzR675ZlN lRbaWKXPN5cYqyowDEutftWwavW6soLFGFaIZWPLsFlYDjYPW4E9h2VgacqEWArmwmHcs6rFquGU qvH68cNqjcRopDKHOHQXZd0+LeJIdxFlX1RJ06Q0rZm1WsBC1Al2UexuOzG49e2lcub2GUWLh+2H POS5xnMOKCR20wvk9LolMESTx709h6GX6Nob37PbtGfL+ovF36AXTqBJg/01PQ1xsrK3IlQklEaK m2CQONR99W7PWXfJPlKTvAUJ9GECHU3gyaD0k1boD0RvA3EgAp0xBzCUGfIYM1TAy3wFnE1/2uUA q0OAjkAH+Nuodr/AQj34WD9Tv1ZmMuVL6suoQejno7dA9x9bMEyDPPXh0czGEr9rERA2p1IVh0Dv TR56qf0gssoFon8/EJG40tgJNdvN0B4OhLgwdR0dHI8uqQ3yQnqWz964s4bNB8L+XzpopB6HKOWI +MBNlZQqabS2YxUHtwAhp8oZ8jPyzJzzKz7vPBu8eYWKGPp2nIE+6OpqPdLW33wVAkTUCUwj66tj yNqVtnXbgKhkDnSKgUjsHSp2MhAVjvcjfWZTLwQgSLQ1RGur7RYLQ66U41qvDfz22qLCbXvNQGyo O3/i7BE0uetdKnF58NgAENdacj0ev4f1UprkPUgk8QQuhaUsLcv7IsAD194Si6A8NC3z/o0TwcN8 hIty0E4EmSYXaYEqphpKoYQvHTHd3QBWd4hpYinRL3ihDmwm2uN9OFUeyryDhsdC1/UI0Cm4Ap6/ Juauh5oG5VtzO8vGqVZ/mAHH3xOrdShVceD/we+m5j/9bgqL/D6q5VzzUPM5lI2ITETIYrwS/ODR mbayTodjLDZyAE7yA0qHDxhxRESoeRQnJ7WNqxfsfYQmueh3R9KkHxVs+dh9IA5HoCPuAC+1A3KZ HWCCZbzpj/H/nbnaxtGqdkoqVncDB+G2L9CuzGBMCY4bcdXpZL173WT5nCJZLb8ERI66bkQ218gx HIwEEgi1K7oeVzbq+AH0kbJRWd+q0AV0Q4uWqNFTiPoZpXy2YlieQsmfqWsc/6OpYxCjqdKgVugL 8KeA+F791VDl8hLr8yWl1IYta11FCstPKj+c26OYo+0ncfTNlX0fq9BAcqmWg2g9vczl3026WAcL NkIRtu9MwN1IMlZ5xsPbvtE5dXSnV2htjbeEyI5PxXthMSyGunSBcOQtLswLiQtHD4qtiQ7l7FOx 8tLXjTJevYZy0V7FemJTX9np+8fQzMjoqgBj95L2N3a+XKgM6I529Qjdgki1nhpEE+ESca345Iur N+7avJ3USElLIjm3F0evfILsn6iSuuQqLe9vcnpZtq6B3Lh+9+k3e1aCTn5MTpcnyJMWDm1+3079 Yj7mPG+HXN283JzsVbJKRBndoW4uTHJBjhvZVjfn9foVo0mfr0CuAYbwhHzhEMe1xMn3Lp567Xrd JdCh6SgN6VDGjfKj9haK7rIH53dZwqVRZ6BSKD8EQ8SXd77+7qurW+WUnT4beEgWnPEox7cFFdGM zO9/UNCJX5CmqKRVyU1aBd2gQlDMKTjcbsbDkPIPv+Z7FQCB1TkEZ6yZb2oLkxqLKOXFYs3IJKpl Q2xCIu3WRDItZUFnempPOD0dw34DxJpvfQplbmRzdHJlYW0KZW5kb2JqCjYyIDAgb2JqCjw8L1R5 cGUvTWV0YWRhdGEKL1N1YnR5cGUvWE1ML0xlbmd0aCAxNDY0Pj5zdHJlYW0KPD94cGFja2V0IGJl Z2luPSfvu78nIGlkPSdXNU0wTXBDZWhpSHpyZVN6TlRjemtjOWQnPz4KPD9hZG9iZS14YXAtZmls dGVycyBlc2M9IkNSTEYiPz4KPHg6eG1wbWV0YSB4bWxuczp4PSdhZG9iZTpuczptZXRhLycgeDp4 bXB0az0nWE1QIHRvb2xraXQgMi45LjEtMTMsIGZyYW1ld29yayAxLjYnPgo8cmRmOlJERiB4bWxu czpyZGY9J2h0dHA6Ly93d3cudzMub3JnLzE5OTkvMDIvMjItcmRmLXN5bnRheC1ucyMnIHhtbG5z OmlYPSdodHRwOi8vbnMuYWRvYmUuY29tL2lYLzEuMC8nPgo8cmRmOkRlc2NyaXB0aW9uIHJkZjph Ym91dD0nYzJkOGRlMjgtMjNiMy0xMWRmLTAwMDAtY2ZkY2Y5Y2E4N2E2JyB4bWxuczpwZGY9J2h0 dHA6Ly9ucy5hZG9iZS5jb20vcGRmLzEuMy8nIHBkZjpQcm9kdWNlcj0nR1BMIEdob3N0c2NyaXB0 IDguNzAnLz4KPHJkZjpEZXNjcmlwdGlvbiByZGY6YWJvdXQ9J2MyZDhkZTI4LTIzYjMtMTFkZi0w MDAwLWNmZGNmOWNhODdhNicgeG1sbnM6eG1wPSdodHRwOi8vbnMuYWRvYmUuY29tL3hhcC8xLjAv Jz48eG1wOk1vZGlmeURhdGU+MjAxMC0wMi0yNFQxNjoyMToyMSswMTowMDwveG1wOk1vZGlmeURh dGU+Cjx4bXA6Q3JlYXRlRGF0ZT4yMDEwLTAyLTI0VDE2OjIxOjIxKzAxOjAwPC94bXA6Q3JlYXRl RGF0ZT4KPHhtcDpDcmVhdG9yVG9vbD5kdmlwc1woa1wpIDUuOTggQ29weXJpZ2h0IDIwMDkgUmFk aWNhbCBFeWUgU29mdHdhcmU8L3htcDpDcmVhdG9yVG9vbD48L3JkZjpEZXNjcmlwdGlvbj4KPHJk ZjpEZXNjcmlwdGlvbiByZGY6YWJvdXQ9J2MyZDhkZTI4LTIzYjMtMTFkZi0wMDAwLWNmZGNmOWNh ODdhNicgeG1sbnM6eGFwTU09J2h0dHA6Ly9ucy5hZG9iZS5jb20veGFwLzEuMC9tbS8nIHhhcE1N OkRvY3VtZW50SUQ9J2MyZDhkZTI4LTIzYjMtMTFkZi0wMDAwLWNmZGNmOWNhODdhNicvPgo8cmRm OkRlc2NyaXB0aW9uIHJkZjphYm91dD0nYzJkOGRlMjgtMjNiMy0xMWRmLTAwMDAtY2ZkY2Y5Y2E4 N2E2JyB4bWxuczpkYz0naHR0cDovL3B1cmwub3JnL2RjL2VsZW1lbnRzLzEuMS8nIGRjOmZvcm1h dD0nYXBwbGljYXRpb24vcGRmJz48ZGM6dGl0bGU+PHJkZjpBbHQ+PHJkZjpsaSB4bWw6bGFuZz0n eC1kZWZhdWx0Jz5DOi9SZXBvc2l0b3JpZXMvNFdBUkQgU1ZOL1dQNi1OZXRJbmYvUHVibGljYXRp b25zLzIwMTAtMDMtLUdsb2JhbCBJbnRlcm5ldCBTeW1wb3NpdW0tTmFtaW5nX1NjaGVtZS9DYW1l cmFfcmVhZHkvbWFpbi5kdmk8L3JkZjpsaT48L3JkZjpBbHQ+PC9kYzp0aXRsZT48L3JkZjpEZXNj cmlwdGlvbj4KPC9yZGY6UkRGPgo8L3g6eG1wbWV0YT4KICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIAo8P3hwYWNrZXQgZW5kPSd3Jz8+CmVuZHN0cmVhbQplbmRvYmoKMiAwIG9iago8PC9Q cm9kdWNlcihHUEwgR2hvc3RzY3JpcHQgOC43MCkKL0NyZWF0aW9uRGF0ZShEOjIwMTAwMjI0MTYy MTIxKzAxJzAwJykKL01vZERhdGUoRDoyMDEwMDIyNDE2MjEyMSswMScwMCcpCi9DcmVhdG9yKGR2 aXBzXChrXCkgNS45OCBDb3B5cmlnaHQgMjAwOSBSYWRpY2FsIEV5ZSBTb2Z0d2FyZSkKL1RpdGxl KEM6L1JlcG9zaXRvcmllcy80V0FSRCBTVk4vV1A2LU5ldEluZi9QdWJsaWNhdGlvbnMvMjAxMC0w My0tR2xvYmFsIEludGVybmV0IFN5bXBvc2l1bS1OYW1pbmdfU2NoZW1lL0NhbWVyYV9yZWFkeS9t YWluLmR2aSk+PmVuZG9iagp4cmVmCjAgNjMKMDAwMDAwMDAwMCA2NTUzNSBmIAowMDAwMDc1NDY3 IDAwMDAwIG4gCjAwMDAwODU5NDQgMDAwMDAgbiAKMDAwMDA3NTM3MyAwMDAwMCBuIAowMDAwMDc0 NDAzIDAwMDAwIG4gCjAwMDAwMDAwMTUgMDAwMDAgbiAKMDAwMDAxMjA0NiAwMDAwMCBuIAowMDAw MDc1NTMyIDAwMDAwIG4gCjAwMDAwNzYxNzMgMDAwMDAgbiAKMDAwMDA3NzY4MSAwMDAwMCBuIAow MDAwMDc2NTI3IDAwMDAwIG4gCjAwMDAwNzYzODYgMDAwMDAgbiAKMDAwMDA3NTU3MyAwMDAwMCBu IAowMDAwMDc1NjAzIDAwMDAwIG4gCjAwMDAwNzQ1NjMgMDAwMDAgbiAKMDAwMDAxMjA2NyAwMDAw MCBuIAowMDAwMDIzOTc0IDAwMDAwIG4gCjAwMDAwNzU2NjQgMDAwMDAgbiAKMDAwMDA3NTY5NCAw MDAwMCBuIAowMDAwMDc0NzI1IDAwMDAwIG4gCjAwMDAwMjM5OTYgMDAwMDAgbiAKMDAwMDAzNTQw OCAwMDAwMCBuIAowMDAwMDc4MDE5IDAwMDAwIG4gCjAwMDAwODI1NzIgMDAwMDAgbiAKMDAwMDA3 Nzc1MiAwMDAwMCBuIAowMDAwMDgwNTUxIDAwMDAwIG4gCjAwMDAwNzgzNzcgMDAwMDAgbiAKMDAw MDA3NzQ4MSAwMDAwMCBuIAowMDAwMDc5NzMzIDAwMDAwIG4gCjAwMDAwNzcxNTQgMDAwMDAgbiAK MDAwMDA3OTA4OSAwMDAwMCBuIAowMDAwMDc1NzM1IDAwMDAwIG4gCjAwMDAwNzU3NjUgMDAwMDAg biAKMDAwMDA3NDg4NyAwMDAwMCBuIAowMDAwMDM1NDMwIDAwMDAwIG4gCjAwMDAwNDc1NTQgMDAw MDAgbiAKMDAwMDA3NjY3NyAwMDAwMCBuIAowMDAwMDc4NDQyIDAwMDAwIG4gCjAwMDAwNzU4NjEg MDAwMDAgbiAKMDAwMDA3NTg5MSAwMDAwMCBuIAowMDAwMDc1MDQ5IDAwMDAwIG4gCjAwMDAwNDc1 NzYgMDAwMDAgbiAKMDAwMDA1OTc1MiAwMDAwMCBuIAowMDAwMDc1OTg3IDAwMDAwIG4gCjAwMDAw NzYwMTcgMDAwMDAgbiAKMDAwMDA3NTIxMSAwMDAwMCBuIAowMDAwMDU5Nzc0IDAwMDAwIG4gCjAw MDAwNzQzODEgMDAwMDAgbiAKMDAwMDA3NjA4MCAwMDAwMCBuIAowMDAwMDc2MTEwIDAwMDAwIG4g CjAwMDAwNzg2OTMgMDAwMDAgbiAKMDAwMDA3OTMwNCAwMDAwMCBuIAowMDAwMDc5OTczIDAwMDAw IG4gCjAwMDAwODA3OTggMDAwMDAgbiAKMDAwMDA4MjgyMiAwMDAwMCBuIAowMDAwMDc2MjU1IDAw MDAwIG4gCjAwMDAwNzY0NzAgMDAwMDAgbiAKMDAwMDA3NjYwOSAwMDAwMCBuIAowMDAwMDc2ODIx IDAwMDAwIG4gCjAwMDAwNzY5MTYgMDAwMDAgbiAKMDAwMDA3NzM4NCAwMDAwMCBuIAowMDAwMDc4 MjkwIDAwMDAwIG4gCjAwMDAwODQ0MDMgMDAwMDAgbiAKdHJhaWxlcgo8PCAvU2l6ZSA2MyAvUm9v dCAxIDAgUiAvSW5mbyAyIDAgUgovSUQgWzxFM0VDQTZCNzA2RDgzRTUyMEQ5M0Q0ODYwODFCNzVF OD48RTNFQ0E2QjcwNkQ4M0U1MjBEOTNENDg2MDgxQjc1RTg+XQo+PgpzdGFydHhyZWYKODYyNTgK JSVFT0YK --Apple-Mail-44-953402252 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="us-ascii" On 29 mar 2011, at 01.43, Woundy, Richard wrote: > Borje, >=20 > How does draft-farrell-ni-00 relate to = draft-dannewitz-ppsp-secure-naming-02? >=20 > I noticed a significant author overlap -- two out of four authors in = common, particularly you. :) >=20 > -- Rich >=20 > -----Original Message----- > From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.org] On = Behalf Of David Harrington > Sent: Monday, March 28, 2011 2:38 PM > To: decade@ietf.org > Subject: [decade] FW: I-D Action:draft-farrell-ni-00.txt >=20 >=20 >=20 > -----Original Message----- > From: i-d-announce-bounces@ietf.org > [mailto:i-d-announce-bounces@ietf.org] On Behalf Of = Internet-Drafts@ietf.org > Sent: Monday, March 28, 2011 11:15 AM > To: i-d-announce@ietf.org > Subject: I-D Action:draft-farrell-ni-00.txt >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. >=20 > Title : URIs for Named Information > Author(s) : S. Farrell, et al. > Filename : draft-farrell-ni-00.txt > Pages : 11 > Date : 2011-03-28 >=20 > This document defines a URI-based name form for objects intended to be = used for information-centric networking and more generally. The name = form defined here allows for the various forms of hash-based binding = between the name and the named-object, as well as supporting = human-readable and hierarchical names. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-farrell-ni-00.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > Below is the data which will enable a MIME compliant mail reader = implementation to automatically retrieve the ASCII version of the = Internet-Draft. --Apple-Mail-44-953402252-- From zhangyunfei@chinamobile.com Tue Mar 29 01:02:37 2011 Return-Path: X-Original-To: decade@core3.amsl.com Delivered-To: decade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 97DF63A69FC for ; Tue, 29 Mar 2011 01:02:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -94.937 X-Spam-Level: X-Spam-Status: No, score=-94.937 tagged_above=-999 required=5 tests=[AWL=0.336, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_61=0.6, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RELAY_IS_221=2.222, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00dShW20yQtA for ; Tue, 29 Mar 2011 01:02:36 -0700 (PDT) Received: from hqmta.chinamobile.com (hqmta.chinamobile.com [221.130.253.171]) by core3.amsl.com (Postfix) with ESMTP id 706633A6ABD for ; Tue, 29 Mar 2011 01:02:35 -0700 (PDT) Received: from hqmta.chinamobile.com (localhost [127.0.0.1]) by localhost.imsstest.com (Postfix) with ESMTP id BC93916A64; Tue, 29 Mar 2011 16:04:05 +0800 (CST) Received: from mail.chinamobile.com (unknown [10.1.28.22]) by hqmta.chinamobile.com (Postfix) with ESMTP id 6E69520D65; Tue, 29 Mar 2011 16:04:05 +0800 (CST) Received: from zyf-PC ([10.1.5.3]) by mail.chinamobile.com (Lotus Domino Release 6.5.6) with ESMTP id 2011032916035820-16464 ; Tue, 29 Mar 2011 16:03:58 +0800 Date: Tue, 29 Mar 2011 16:03:50 +0800 From: "zhangyunfei" To: "=?gb2312?B?QvZyamVfT2hsbWFu?=" , "Woundy, Richard" References: <1CA25301D2219F40B3AA37201F0EACD1134D3A81@PACDCEXMB05.cable.comcast.com> <74D47E5D-D27C-4D4E-83F3-E4C682128ED2@ericsson.com> Message-ID: <201103291603446880709@chinamobile.com> X-mailer: Foxmail 6, 2, 103, 20 [cn] Mime-Version: 1.0 X-MIMETrack: Itemize by SMTP Server on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2011-03-29 16:04:00, Serialize by Router on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2011-03-29 16:04:05, Serialize complete at 2011-03-29 16:04:05 Content-Type: multipart/alternative; boundary="=====003_Dragon844323387111_=====" X-TM-AS-Product-Ver: IMSS-7.0.0.8231-6.5.0.1024-18040.005 X-TM-AS-Result: No--18.866-7.0-31-10 X-imss-scan-details: No--18.866-7.0-31-10;No--18.866-5.0-31-10 X-TM-AS-User-Approved-Sender: No Cc: Tim Polk , Sean Turner , decade ietf , Christian Dannewitz , Dirk Kutscher Subject: Re: [decade] FW: I-D Action:draft-farrell-ni-00.txt X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.9 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, 29 Mar 2011 08:02:37 -0000 This is a multi-part message in MIME format. --=====003_Dragon844323387111_===== Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="gb2312" QXMgaXMgYSBnZW5lcmFsIG5hbWluZyBzY2hlbWUsSSBzdWdnZXN0ZWQgYXMgc3RhdGluZyBpbiB0 aGUgV0cgbWVldGluZywgdG8gZGlzY3VzcyBpbiB0aGUgVVJOYmlzIG1haWxpbmcgbGlzdC4NCg0K WXVuZmVpDQoNCg0KDQoNCnpoYW5neXVuZmVpDQoyMDExLTAzLTI5DQoNCg0KDQq3orz+yMujuiBC 9nJqZV9PaGxtYW4NCreiy83Ksbzko7ogMjAxMS0wMy0yOSAxNToxOTozNA0KytW8/sjLo7ogV291 bmR5LCBSaWNoYXJkDQqzrcvNo7ogVGltIFBvbGs7IERpcmsgS3V0c2NoZXI7IGRlY2FkZSBpZXRm OyBTZWFuIFR1cm5lcjsgQ2hyaXN0aWFuIERhbm5ld2l0eg0K1vfM4qO6IFJlOiBbZGVjYWRlXSBG VzogSS1EIEFjdGlvbjpkcmFmdC1mYXJyZWxsLW5pLTAwLnR4dA0KDQpIaSAgUmljaCwNCg0KVGhl ICBkYW5uZXdpdHogIGRyYWZ0ICBoYXMgIGl0J3MgIG9yaWdpbiAgaW4gIHRoZSAgbmFtaW5nICB3 b3JrICB0aGF0ICB3ZSAgaGF2ZSAgZG9uZSAgZm9yICBJbmZvcm1hdGlvbiAgQ2VudHJpYyAgTmV0 d29ya3MgIChJQ04pLiAgV2UgIHJlYWxpemVkICB0aGF0ICB0aGlzICB0eXBlICBvZiAgbmFtaW5n ICBjYW4gIGJlICBvZiAgZ2VuZXJhbCAgaW50ZXJlc3QgIGZvciAgbWFueSAgYXBwbGljYXRpb25z LCAgYWxzbyAgaW4gIHRvZGF5J3MgIEludGVybmV0LiAgV2UgIHRodXMgIHdyb3RlICB0aGUgIGRy YWZ0ICBmb3IgIHBwc3AuICBUaGUgIHdvcmsgIHRoYXQgIHRoYXQgIGRyYWZ0ICBpcyAgYmFzZWQg IG9uICBpcyAgbGFyZ2VseSAgc3VtbWFyaXplZCAgaW4gIHRoZSAgR2xvYmFsICBJbnRlcm5ldCAg U3ltcG9zaXVtICBwYXBlciAgIlNlY3VyZSAgTmFtaW5nICBmb3IgIGEgIE5ldHdvcmsgIG9mICBJ bmZvcm1hdGlvbiIgIChhdHRhY2hlZCksICB5b3UgIGNhbiAgYWxzbyAgZmluZCAgdGhlICBwcmVz ZW50YXRpb24gIGF0OiAgDQpodHRwczovL2ZpdC5ub2tpYS5jb20vZ2kyMDEwL2dpMjAxMC9HSVMy MDEwLVNlY3VyZU5hbWluZ05ldEluZi5wZGYNCg0KSW4gIHRoZSAgbGF0ZXN0ICB2ZXJzaW9uICBv ZiAgdGhlICBkYW5uZXdpdHogIGRyYWZ0ICB3ZSAgaGF2ZSAgcHV0ICB0aGUgIGVtcGhhc2lzICBv biAgc3RhdGluZyAgdGhhdCAgYSAgZmxleGlibGUgIHNlY3VyZSAgYXBwbGljYXRpb24gIGluZGVw ZW5kZW50ICBuYW1pbmcgIHNjaGVtZSAgZm9yICBpbmZvcm1hdGlvbiAgb2JqZWN0cyAgc2hvdWxk ICBiZSAgYSAgZ3JlYXQgIHRoaW5nICB0byAgaGF2ZSAgZm9yICB0aGUgIGZ1dHVyZSAgZGV2ZWxv cG1lbnQgIG9mICB0aGUgIEludGVybmV0LiAgDQoNClRoZSAgbmFtaW5nICBzY2hlbWUgIHByZXNl bnRlZCAgaW4gIHRoZSAgcGFwZXIgIHdhcyAgYSAgZmlyc3QgIHNob3QgIGF0ICB0aGF0LiAgT3Vy ICB3b3JrICBvbiAgdGhpcyAgaGFzICBzaW5jZSAgdGhlbiAgZXZvbHZlZCAgYW5kICBvdXIgIGN1 cnJlbnQgIHRoaW5raW5nICBpcyAgcmVwcmVzZW50ZWQgIGJ5ICB0aGUgIGZhcnJlbGwgIGRyYWZ0 LiAgV2hpY2ggIHdlICB0aGluayAgaXMgIGFuICBldmVuICBtb3JlICBzaW1wbGUsICBmbGV4aWJs ZSAgYW5kICBleHRlbnNpYmxlICB3YXkgIHRvICBkbyAgc2VjdXJlICBuYW1pbmcgIG9mICBpbmZv cm1hdGlvbiAgb2JqZWN0cyAgKGFuZCAgYW55ICB0eXBlICBvZiAgb2JqZWN0cyAgZm9yICB0aGF0 ICBtYXR0ZXIpLiAgUGxlYXNlICBub3RlICB0aGF0ICB3ZSAgYnkgIG5vICBtZWFucyAgY2xhaW0g IHRoaXMgIHRvICBiZSAgdGhlICAnZmluYWwgIHNvbHV0aW9uJy4gIEl0ICBpcyAganVzdCAgYW5v dGhlciAgcHJvb2YgIG9mICBjb25jZXB0ICBvbiAgdGhlICB3YXkgIHRvLCAgd2hhdCAgd2UgIGhv cGUgIHRvICBzZWUsICBhICBjb21tb24gIHNlY3VyZSAgbmFtaW5nICBzY2hlbWUgIHdpZGVseSAg YWRvcHRlZCAgb24gIHRoZSAgSW50ZXJuZXQgIGZvciAgbmFtaW5nICBpbmZvcm1hdGlvbiAgb2Jq ZWN0cy4NCg0KSG9wZSAgdGhpcyAgaGVscHMsDQpC9nJqZQ0KT24gIDI5ICBtYXIgIDIwMTEsICBh dCAgMDEuNDMsICBXb3VuZHksICBSaWNoYXJkICB3cm90ZToNCg0KPiAgQm9yamUsDQo+ICANCj4g IEhvdyAgZG9lcyAgZHJhZnQtZmFycmVsbC1uaS0wMCAgcmVsYXRlICB0byAgZHJhZnQtZGFubmV3 aXR6LXBwc3Atc2VjdXJlLW5hbWluZy0wMj8NCj4gIA0KPiAgSSAgbm90aWNlZCAgYSAgc2lnbmlm aWNhbnQgIGF1dGhvciAgb3ZlcmxhcCAgLS0gIHR3byAgb3V0ICBvZiAgZm91ciAgYXV0aG9ycyAg aW4gIGNvbW1vbiwgIHBhcnRpY3VsYXJseSAgeW91LiAgOikNCj4gIA0KPiAgLS0gIFJpY2gNCj4g IA0KPiAgLS0tLS1PcmlnaW5hbCAgTWVzc2FnZS0tLS0tDQo+ICBGcm9tOiAgZGVjYWRlLWJvdW5j ZXNAaWV0Zi5vcmcgIFttYWlsdG86ZGVjYWRlLWJvdW5jZXNAaWV0Zi5vcmddICBPbiAgQmVoYWxm ICBPZiAgRGF2aWQgIEhhcnJpbmd0b24NCj4gIFNlbnQ6ICBNb25kYXksICBNYXJjaCAgMjgsICAy MDExICAyOjM4ICBQTQ0KPiAgVG86ICBkZWNhZGVAaWV0Zi5vcmcNCj4gIFN1YmplY3Q6ICBbZGVj YWRlXSAgRlc6ICBJLUQgIEFjdGlvbjpkcmFmdC1mYXJyZWxsLW5pLTAwLnR4dA0KPiAgDQo+ICAN Cj4gIA0KPiAgLS0tLS1PcmlnaW5hbCAgTWVzc2FnZS0tLS0tDQo+ICBGcm9tOiAgaS1kLWFubm91 bmNlLWJvdW5jZXNAaWV0Zi5vcmcNCj4gIFttYWlsdG86aS1kLWFubm91bmNlLWJvdW5jZXNAaWV0 Zi5vcmddICBPbiAgQmVoYWxmICBPZiAgSW50ZXJuZXQtRHJhZnRzQGlldGYub3JnDQo+ICBTZW50 OiAgTW9uZGF5LCAgTWFyY2ggIDI4LCAgMjAxMSAgMTE6MTUgIEFNDQo+ICBUbzogIGktZC1hbm5v dW5jZUBpZXRmLm9yZw0KPiAgU3ViamVjdDogIEktRCAgQWN0aW9uOmRyYWZ0LWZhcnJlbGwtbmkt MDAudHh0DQo+ICANCj4gIEEgIE5ldyAgSW50ZXJuZXQtRHJhZnQgIGlzICBhdmFpbGFibGUgIGZy b20gIHRoZSAgb24tbGluZSAgSW50ZXJuZXQtRHJhZnRzICBkaXJlY3Rvcmllcy4NCj4gIA0KPiAg IFRpdGxlICAgICAgICAgICAgICAgICAgICAgIDogIFVSSXMgIGZvciAgTmFtZWQgIEluZm9ybWF0 aW9uDQo+ICAgQXV0aG9yKHMpICAgICAgICAgICAgICA6ICBTLiAgRmFycmVsbCwgIGV0ICBhbC4N Cj4gICBGaWxlbmFtZSAgICAgICAgICAgICAgICA6ICBkcmFmdC1mYXJyZWxsLW5pLTAwLnR4dA0K PiAgIFBhZ2VzICAgICAgICAgICAgICAgICAgICAgIDogIDExDQo+ICAgRGF0ZSAgICAgICAgICAg ICAgICAgICAgICAgIDogIDIwMTEtMDMtMjgNCj4gIA0KPiAgVGhpcyAgZG9jdW1lbnQgIGRlZmlu ZXMgIGEgIFVSSS1iYXNlZCAgbmFtZSAgZm9ybSAgZm9yICBvYmplY3RzICBpbnRlbmRlZCAgdG8g IGJlICB1c2VkICBmb3IgIGluZm9ybWF0aW9uLWNlbnRyaWMgIG5ldHdvcmtpbmcgIGFuZCAgbW9y ZSAgZ2VuZXJhbGx5LiAgICBUaGUgIG5hbWUgIGZvcm0gIGRlZmluZWQgIGhlcmUgIGFsbG93cyAg Zm9yICB0aGUgIHZhcmlvdXMgIGZvcm1zICBvZiAgaGFzaC1iYXNlZCAgYmluZGluZyAgYmV0d2Vl biAgdGhlICBuYW1lICBhbmQgIHRoZSAgbmFtZWQtb2JqZWN0LCAgYXMgIHdlbGwgIGFzICBzdXBw b3J0aW5nICBodW1hbi1yZWFkYWJsZSAgYW5kICBoaWVyYXJjaGljYWwgIG5hbWVzLg0KPiAgDQo+ ICBBICBVUkwgIGZvciAgdGhpcyAgSW50ZXJuZXQtRHJhZnQgIGlzOg0KPiAgaHR0cDovL3d3dy5p ZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtZmFycmVsbC1uaS0wMC50eHQNCj4gIA0KPiAg SW50ZXJuZXQtRHJhZnRzICBhcmUgIGFsc28gIGF2YWlsYWJsZSAgYnkgIGFub255bW91cyAgRlRQ ICBhdDoNCj4gIGZ0cDovL2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvDQo+ICANCj4gIEJl bG93ICBpcyAgdGhlICBkYXRhICB3aGljaCAgd2lsbCAgZW5hYmxlICBhICBNSU1FICBjb21wbGlh bnQgIG1haWwgIHJlYWRlciAgaW1wbGVtZW50YXRpb24gIHRvICBhdXRvbWF0aWNhbGx5ICByZXRy aWV2ZSAgdGhlICBBU0NJSSAgdmVyc2lvbiAgb2YgIHRoZSAgSW50ZXJuZXQtRHJhZnQuDQpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KZGVjYWRlICBtYWls aW5nICBsaXN0DQpkZWNhZGVAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vZGVjYWRlDQo= --=====003_Dragon844323387111_===== Content-Transfer-Encoding: base64 Content-Type: text/html; charset="gb2312" PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWdi MjMxMiIgaHR0cC1lcXVpdj1Db250ZW50LVR5cGU+DQo8TUVUQSBuYW1lPUdFTkVSQVRPUiBjb250 ZW50PSJNU0hUTUwgOS4wMC44MTEyLjE2NDIxIj4NCjxTVFlMRT4NCjwhLS0NCiAvKiBGb250IERl ZmluaXRpb25zICovDQogQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTrLzszlOw0KCXBhbm9zZS0x OjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpWZXJkYW5h Ow0KCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1m YW1pbHk6IlxAy87M5SI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQogLyogU3R5 bGUgRGVmaW5pdGlvbnMgKi8NCiBwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9y bWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCXRleHQtYWxpZ246 anVzdGlmeTsNCgl0ZXh0LWp1c3RpZnk6aW50ZXItaWRlb2dyYXBoOw0KCWZvbnQtc2l6ZToxMC41 cHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5 cGVybGluaw0KCXtjb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2 aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe2NvbG9yOnB1cnBsZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10 eXBlOnBlcnNvbmFsLWNvbXBvc2U7DQoJZm9udC1mYW1pbHk6VmVyZGFuYTsNCgljb2xvcjp3aW5k b3d0ZXh0Ow0KCWZvbnQtd2VpZ2h0Om5vcm1hbDsNCglmb250LXN0eWxlOm5vcm1hbDsNCgl0ZXh0 LWRlY29yYXRpb246bm9uZSBub25lO30NCiAvKiBQYWdlIERlZmluaXRpb25zICovDQogQHBhZ2Ug U2VjdGlvbjENCgl7c2l6ZTo1OTUuM3B0IDg0MS45cHQ7DQoJbWFyZ2luOjcyLjBwdCA5MC4wcHQg NzIuMHB0IDkwLjBwdDsNCglsYXlvdXQtZ3JpZDoxNS42cHQ7fQ0KZGl2LlNlY3Rpb24xDQoJe3Bh Z2U6U2VjdGlvbjE7fQ0KLS0+DQo8L1NUWUxFPg0KPC9IRUFEPg0KPEJPRFk+DQo8RElWPjxGT05U IGNvbG9yPSMwMDAwZmYgc2l6ZT0yIGZhY2U9VmVyZGFuYT5BcyBpcyBhIGdlbmVyYWwgbmFtaW5n IHNjaGVtZSxJIA0Kc3VnZ2VzdGVkIGFzIHN0YXRpbmcgaW4gdGhlIFdHIG1lZXRpbmcsIHRvIGRp c2N1c3MgaW4gdGhlIFVSTmJpcyBtYWlsaW5nIA0KbGlzdC48L0ZPTlQ+PC9ESVY+DQo8RElWPjxG T05UIGNvbG9yPSMwMDAwZmYgc2l6ZT0yIGZhY2U9VmVyZGFuYT48L0ZPTlQ+Jm5ic3A7PC9ESVY+ DQo8RElWPjxGT05UIGNvbG9yPSMwMDAwZmYgc2l6ZT0yIGZhY2U9VmVyZGFuYT5ZdW5mZWk8L0ZP TlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9MiBmYWNlPVZlcmRhbmE+PC9GT05UPiZuYnNwOzwv RElWPg0KPERJViBhbGlnbj1sZWZ0Pg0KPERJViBhbGlnbj1sZWZ0PjxGT05UIHNpemU9MiBmYWNl PVZlcmRhbmE+DQo8SFIgc3R5bGU9IldJRFRIOiAxMjJweDsgSEVJR0hUOiAycHgiIFNJWkU9Mj4N CjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgY29sb3I9I2MwYzBjMD48Rk9OVCBzaXplPTIgZmFj ZT1WZXJkYW5hPnpoYW5neXVuZmVpPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTIgZmFj ZT1WZXJkYW5hPjIwMTEtMDMtMjk8L0ZPTlQ+PC9GT05UPjwvRElWPjwvRElWPg0KPERJVj48Rk9O VCBzaXplPTIgZmFjZT1WZXJkYW5hPg0KPEhSPg0KPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBm YWNlPVZlcmRhbmE+PEZPTlQgc2l6ZT0yPjxTVFJPTkc+t6K8/sjLo7o8L1NUUk9ORz4gDQpC9nJq ZV9PaGxtYW48L0ZPTlQ+PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPVZlcmRhbmE+PEZP TlQgc2l6ZT0yPjxTVFJPTkc+t6LLzcqxvOSjujwvU1RST05HPiANCjIwMTEtMDMtMjkmbmJzcDsx NToxOTozNDwvRk9OVD48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9VmVyZGFuYT48Rk9O VCBzaXplPTI+PFNUUk9ORz7K1bz+yMujujwvU1RST05HPiBXb3VuZHksIA0KUmljaGFyZDwvRk9O VD48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9VmVyZGFuYT48Rk9OVCBzaXplPTI+PFNU Uk9ORz6zrcvNo7o8L1NUUk9ORz4gVGltIFBvbGs7IERpcmsgDQpLdXRzY2hlcjsgZGVjYWRlIGll dGY7IFNlYW4gVHVybmVyOyBDaHJpc3RpYW4gRGFubmV3aXR6PC9GT05UPjwvRk9OVD48L0RJVj4N CjxESVY+PEZPTlQgZmFjZT1WZXJkYW5hPjxGT05UIHNpemU9Mj48U1RST05HPtb3zOKjujwvU1RS T05HPiBSZTogW2RlY2FkZV0gRlc6IEktRCANCkFjdGlvbjpkcmFmdC1mYXJyZWxsLW5pLTAwLnR4 dDwvRk9OVD48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9MiBmYWNlPVZlcmRhbmE+PC9G T05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBzaXplPTIgZmFjZT1WZXJkYW5hPg0KPERJVj5I aSAmbmJzcDtSaWNoLDwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+VGhlICZuYnNwO2Rh bm5ld2l0eiAmbmJzcDtkcmFmdCAmbmJzcDtoYXMgJm5ic3A7aXQncyAmbmJzcDtvcmlnaW4gJm5i c3A7aW4gDQombmJzcDt0aGUgJm5ic3A7bmFtaW5nICZuYnNwO3dvcmsgJm5ic3A7dGhhdCAmbmJz cDt3ZSAmbmJzcDtoYXZlICZuYnNwO2RvbmUgDQombmJzcDtmb3IgJm5ic3A7SW5mb3JtYXRpb24g Jm5ic3A7Q2VudHJpYyAmbmJzcDtOZXR3b3JrcyAmbmJzcDsoSUNOKS4gJm5ic3A7V2UgDQombmJz cDtyZWFsaXplZCAmbmJzcDt0aGF0ICZuYnNwO3RoaXMgJm5ic3A7dHlwZSAmbmJzcDtvZiAmbmJz cDtuYW1pbmcgJm5ic3A7Y2FuIA0KJm5ic3A7YmUgJm5ic3A7b2YgJm5ic3A7Z2VuZXJhbCAmbmJz cDtpbnRlcmVzdCAmbmJzcDtmb3IgJm5ic3A7bWFueSANCiZuYnNwO2FwcGxpY2F0aW9ucywgJm5i c3A7YWxzbyAmbmJzcDtpbiAmbmJzcDt0b2RheSdzICZuYnNwO0ludGVybmV0LiAmbmJzcDtXZSAN CiZuYnNwO3RodXMgJm5ic3A7d3JvdGUgJm5ic3A7dGhlICZuYnNwO2RyYWZ0ICZuYnNwO2ZvciAm bmJzcDtwcHNwLiAmbmJzcDtUaGUgDQombmJzcDt3b3JrICZuYnNwO3RoYXQgJm5ic3A7dGhhdCAm bmJzcDtkcmFmdCAmbmJzcDtpcyAmbmJzcDtiYXNlZCAmbmJzcDtvbiANCiZuYnNwO2lzICZuYnNw O2xhcmdlbHkgJm5ic3A7c3VtbWFyaXplZCAmbmJzcDtpbiAmbmJzcDt0aGUgJm5ic3A7R2xvYmFs IA0KJm5ic3A7SW50ZXJuZXQgJm5ic3A7U3ltcG9zaXVtICZuYnNwO3BhcGVyICZuYnNwOyJTZWN1 cmUgJm5ic3A7TmFtaW5nICZuYnNwO2ZvciANCiZuYnNwO2EgJm5ic3A7TmV0d29yayAmbmJzcDtv ZiAmbmJzcDtJbmZvcm1hdGlvbiIgJm5ic3A7KGF0dGFjaGVkKSwgJm5ic3A7eW91IA0KJm5ic3A7 Y2FuICZuYnNwO2Fsc28gJm5ic3A7ZmluZCAmbmJzcDt0aGUgJm5ic3A7cHJlc2VudGF0aW9uICZu YnNwO2F0OiANCiZuYnNwOzwvRElWPg0KPERJVj5odHRwczovL2ZpdC5ub2tpYS5jb20vZ2kyMDEw L2dpMjAxMC9HSVMyMDEwLVNlY3VyZU5hbWluZ05ldEluZi5wZGY8L0RJVj4NCjxESVY+Jm5ic3A7 PC9ESVY+DQo8RElWPkluICZuYnNwO3RoZSAmbmJzcDtsYXRlc3QgJm5ic3A7dmVyc2lvbiAmbmJz cDtvZiAmbmJzcDt0aGUgJm5ic3A7ZGFubmV3aXR6IA0KJm5ic3A7ZHJhZnQgJm5ic3A7d2UgJm5i c3A7aGF2ZSAmbmJzcDtwdXQgJm5ic3A7dGhlICZuYnNwO2VtcGhhc2lzICZuYnNwO29uIA0KJm5i c3A7c3RhdGluZyAmbmJzcDt0aGF0ICZuYnNwO2EgJm5ic3A7ZmxleGlibGUgJm5ic3A7c2VjdXJl ICZuYnNwO2FwcGxpY2F0aW9uIA0KJm5ic3A7aW5kZXBlbmRlbnQgJm5ic3A7bmFtaW5nICZuYnNw O3NjaGVtZSAmbmJzcDtmb3IgJm5ic3A7aW5mb3JtYXRpb24gDQombmJzcDtvYmplY3RzICZuYnNw O3Nob3VsZCAmbmJzcDtiZSAmbmJzcDthICZuYnNwO2dyZWF0ICZuYnNwO3RoaW5nICZuYnNwO3Rv IA0KJm5ic3A7aGF2ZSAmbmJzcDtmb3IgJm5ic3A7dGhlICZuYnNwO2Z1dHVyZSAmbmJzcDtkZXZl bG9wbWVudCAmbmJzcDtvZiAmbmJzcDt0aGUgDQombmJzcDtJbnRlcm5ldC4gJm5ic3A7PC9ESVY+ DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj5UaGUgJm5ic3A7bmFtaW5nICZuYnNwO3NjaGVtZSAm bmJzcDtwcmVzZW50ZWQgJm5ic3A7aW4gJm5ic3A7dGhlIA0KJm5ic3A7cGFwZXIgJm5ic3A7d2Fz ICZuYnNwO2EgJm5ic3A7Zmlyc3QgJm5ic3A7c2hvdCAmbmJzcDthdCAmbmJzcDt0aGF0LiANCiZu YnNwO091ciAmbmJzcDt3b3JrICZuYnNwO29uICZuYnNwO3RoaXMgJm5ic3A7aGFzICZuYnNwO3Np bmNlICZuYnNwO3RoZW4gDQombmJzcDtldm9sdmVkICZuYnNwO2FuZCAmbmJzcDtvdXIgJm5ic3A7 Y3VycmVudCAmbmJzcDt0aGlua2luZyAmbmJzcDtpcyANCiZuYnNwO3JlcHJlc2VudGVkICZuYnNw O2J5ICZuYnNwO3RoZSAmbmJzcDtmYXJyZWxsICZuYnNwO2RyYWZ0LiAmbmJzcDtXaGljaCANCiZu YnNwO3dlICZuYnNwO3RoaW5rICZuYnNwO2lzICZuYnNwO2FuICZuYnNwO2V2ZW4gJm5ic3A7bW9y ZSAmbmJzcDtzaW1wbGUsIA0KJm5ic3A7ZmxleGlibGUgJm5ic3A7YW5kICZuYnNwO2V4dGVuc2li bGUgJm5ic3A7d2F5ICZuYnNwO3RvICZuYnNwO2RvIA0KJm5ic3A7c2VjdXJlICZuYnNwO25hbWlu ZyAmbmJzcDtvZiAmbmJzcDtpbmZvcm1hdGlvbiAmbmJzcDtvYmplY3RzICZuYnNwOyhhbmQgDQom bmJzcDthbnkgJm5ic3A7dHlwZSAmbmJzcDtvZiAmbmJzcDtvYmplY3RzICZuYnNwO2ZvciAmbmJz cDt0aGF0ICZuYnNwO21hdHRlcikuIA0KJm5ic3A7UGxlYXNlICZuYnNwO25vdGUgJm5ic3A7dGhh dCAmbmJzcDt3ZSAmbmJzcDtieSAmbmJzcDtubyAmbmJzcDttZWFucyANCiZuYnNwO2NsYWltICZu YnNwO3RoaXMgJm5ic3A7dG8gJm5ic3A7YmUgJm5ic3A7dGhlICZuYnNwOydmaW5hbCAmbmJzcDtz b2x1dGlvbicuIA0KJm5ic3A7SXQgJm5ic3A7aXMgJm5ic3A7anVzdCAmbmJzcDthbm90aGVyICZu YnNwO3Byb29mICZuYnNwO29mICZuYnNwO2NvbmNlcHQgDQombmJzcDtvbiAmbmJzcDt0aGUgJm5i c3A7d2F5ICZuYnNwO3RvLCAmbmJzcDt3aGF0ICZuYnNwO3dlICZuYnNwO2hvcGUgJm5ic3A7dG8g DQombmJzcDtzZWUsICZuYnNwO2EgJm5ic3A7Y29tbW9uICZuYnNwO3NlY3VyZSAmbmJzcDtuYW1p bmcgJm5ic3A7c2NoZW1lIA0KJm5ic3A7d2lkZWx5ICZuYnNwO2Fkb3B0ZWQgJm5ic3A7b24gJm5i c3A7dGhlICZuYnNwO0ludGVybmV0ICZuYnNwO2ZvciANCiZuYnNwO25hbWluZyAmbmJzcDtpbmZv cm1hdGlvbiAmbmJzcDtvYmplY3RzLjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+SG9w ZSAmbmJzcDt0aGlzICZuYnNwO2hlbHBzLDwvRElWPg0KPERJVj5C9nJqZTwvRElWPg0KPERJVj5P biAmbmJzcDsyOSAmbmJzcDttYXIgJm5ic3A7MjAxMSwgJm5ic3A7YXQgJm5ic3A7MDEuNDMsICZu YnNwO1dvdW5keSwgDQombmJzcDtSaWNoYXJkICZuYnNwO3dyb3RlOjwvRElWPg0KPERJVj4mbmJz cDs8L0RJVj4NCjxESVY+Jmd0OyAmbmJzcDtCb3JqZSw8L0RJVj4NCjxESVY+Jmd0OyAmbmJzcDs8 L0RJVj4NCjxESVY+Jmd0OyAmbmJzcDtIb3cgJm5ic3A7ZG9lcyAmbmJzcDtkcmFmdC1mYXJyZWxs LW5pLTAwICZuYnNwO3JlbGF0ZSAmbmJzcDt0byANCiZuYnNwO2RyYWZ0LWRhbm5ld2l0ei1wcHNw LXNlY3VyZS1uYW1pbmctMDI/PC9ESVY+DQo8RElWPiZndDsgJm5ic3A7PC9ESVY+DQo8RElWPiZn dDsgJm5ic3A7SSAmbmJzcDtub3RpY2VkICZuYnNwO2EgJm5ic3A7c2lnbmlmaWNhbnQgJm5ic3A7 YXV0aG9yIA0KJm5ic3A7b3ZlcmxhcCAmbmJzcDstLSAmbmJzcDt0d28gJm5ic3A7b3V0ICZuYnNw O29mICZuYnNwO2ZvdXIgJm5ic3A7YXV0aG9ycyANCiZuYnNwO2luICZuYnNwO2NvbW1vbiwgJm5i c3A7cGFydGljdWxhcmx5ICZuYnNwO3lvdS4gJm5ic3A7Oik8L0RJVj4NCjxESVY+Jmd0OyAmbmJz cDs8L0RJVj4NCjxESVY+Jmd0OyAmbmJzcDstLSAmbmJzcDtSaWNoPC9ESVY+DQo8RElWPiZndDsg Jm5ic3A7PC9ESVY+DQo8RElWPiZndDsgJm5ic3A7LS0tLS1PcmlnaW5hbCAmbmJzcDtNZXNzYWdl LS0tLS08L0RJVj4NCjxESVY+Jmd0OyAmbmJzcDtGcm9tOiAmbmJzcDtkZWNhZGUtYm91bmNlc0Bp ZXRmLm9yZyANCiZuYnNwO1ttYWlsdG86ZGVjYWRlLWJvdW5jZXNAaWV0Zi5vcmddICZuYnNwO09u ICZuYnNwO0JlaGFsZiAmbmJzcDtPZiANCiZuYnNwO0RhdmlkICZuYnNwO0hhcnJpbmd0b248L0RJ Vj4NCjxESVY+Jmd0OyAmbmJzcDtTZW50OiAmbmJzcDtNb25kYXksICZuYnNwO01hcmNoICZuYnNw OzI4LCAmbmJzcDsyMDExICZuYnNwOzI6MzggDQombmJzcDtQTTwvRElWPg0KPERJVj4mZ3Q7ICZu YnNwO1RvOiAmbmJzcDtkZWNhZGVAaWV0Zi5vcmc8L0RJVj4NCjxESVY+Jmd0OyAmbmJzcDtTdWJq ZWN0OiAmbmJzcDtbZGVjYWRlXSAmbmJzcDtGVzogJm5ic3A7SS1EIA0KJm5ic3A7QWN0aW9uOmRy YWZ0LWZhcnJlbGwtbmktMDAudHh0PC9ESVY+DQo8RElWPiZndDsgJm5ic3A7PC9ESVY+DQo8RElW PiZndDsgJm5ic3A7PC9ESVY+DQo8RElWPiZndDsgJm5ic3A7PC9ESVY+DQo8RElWPiZndDsgJm5i c3A7LS0tLS1PcmlnaW5hbCAmbmJzcDtNZXNzYWdlLS0tLS08L0RJVj4NCjxESVY+Jmd0OyAmbmJz cDtGcm9tOiAmbmJzcDtpLWQtYW5ub3VuY2UtYm91bmNlc0BpZXRmLm9yZzwvRElWPg0KPERJVj4m Z3Q7ICZuYnNwO1ttYWlsdG86aS1kLWFubm91bmNlLWJvdW5jZXNAaWV0Zi5vcmddICZuYnNwO09u ICZuYnNwO0JlaGFsZiANCiZuYnNwO09mICZuYnNwO0ludGVybmV0LURyYWZ0c0BpZXRmLm9yZzwv RElWPg0KPERJVj4mZ3Q7ICZuYnNwO1NlbnQ6ICZuYnNwO01vbmRheSwgJm5ic3A7TWFyY2ggJm5i c3A7MjgsICZuYnNwOzIwMTEgJm5ic3A7MTE6MTUgDQombmJzcDtBTTwvRElWPg0KPERJVj4mZ3Q7 ICZuYnNwO1RvOiAmbmJzcDtpLWQtYW5ub3VuY2VAaWV0Zi5vcmc8L0RJVj4NCjxESVY+Jmd0OyAm bmJzcDtTdWJqZWN0OiAmbmJzcDtJLUQgJm5ic3A7QWN0aW9uOmRyYWZ0LWZhcnJlbGwtbmktMDAu dHh0PC9ESVY+DQo8RElWPiZndDsgJm5ic3A7PC9ESVY+DQo8RElWPiZndDsgJm5ic3A7QSAmbmJz cDtOZXcgJm5ic3A7SW50ZXJuZXQtRHJhZnQgJm5ic3A7aXMgJm5ic3A7YXZhaWxhYmxlIA0KJm5i c3A7ZnJvbSAmbmJzcDt0aGUgJm5ic3A7b24tbGluZSAmbmJzcDtJbnRlcm5ldC1EcmFmdHMgDQom bmJzcDtkaXJlY3Rvcmllcy48L0RJVj4NCjxESVY+Jmd0OyAmbmJzcDs8L0RJVj4NCjxESVY+Jmd0 OyAmbmJzcDsgVGl0bGUgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyANCiZuYnNwOyAmbmJzcDsgJm5ic3A7OiAmbmJzcDtVUklzICZuYnNwO2Zv ciAmbmJzcDtOYW1lZCAmbmJzcDtJbmZvcm1hdGlvbjwvRElWPg0KPERJVj4mZ3Q7ICZuYnNwOyBB dXRob3IocykgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 OiANCiZuYnNwO1MuICZuYnNwO0ZhcnJlbGwsICZuYnNwO2V0ICZuYnNwO2FsLjwvRElWPg0KPERJ Vj4mZ3Q7ICZuYnNwOyBGaWxlbmFtZSAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgDQombmJzcDs6ICZuYnNwO2RyYWZ0LWZhcnJlbGwtbmktMDAudHh0PC9E SVY+DQo8RElWPiZndDsgJm5ic3A7IFBhZ2VzICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgDQombmJzcDsgJm5ic3A7ICZuYnNwOzogJm5ic3A7 MTE8L0RJVj4NCjxESVY+Jmd0OyAmbmJzcDsgRGF0ZSAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IA0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7OiAmbmJzcDsyMDExLTAzLTI4PC9ESVY+DQo8RElWPiZndDsgJm5ic3A7PC9ESVY+DQo8RElW PiZndDsgJm5ic3A7VGhpcyAmbmJzcDtkb2N1bWVudCAmbmJzcDtkZWZpbmVzICZuYnNwO2EgJm5i c3A7VVJJLWJhc2VkIA0KJm5ic3A7bmFtZSAmbmJzcDtmb3JtICZuYnNwO2ZvciAmbmJzcDtvYmpl Y3RzICZuYnNwO2ludGVuZGVkICZuYnNwO3RvICZuYnNwO2JlIA0KJm5ic3A7dXNlZCAmbmJzcDtm b3IgJm5ic3A7aW5mb3JtYXRpb24tY2VudHJpYyAmbmJzcDtuZXR3b3JraW5nICZuYnNwO2FuZCAN CiZuYnNwO21vcmUgJm5ic3A7Z2VuZXJhbGx5LiAmbmJzcDsgJm5ic3A7VGhlICZuYnNwO25hbWUg Jm5ic3A7Zm9ybSAmbmJzcDtkZWZpbmVkIA0KJm5ic3A7aGVyZSAmbmJzcDthbGxvd3MgJm5ic3A7 Zm9yICZuYnNwO3RoZSAmbmJzcDt2YXJpb3VzICZuYnNwO2Zvcm1zICZuYnNwO29mIA0KJm5ic3A7 aGFzaC1iYXNlZCAmbmJzcDtiaW5kaW5nICZuYnNwO2JldHdlZW4gJm5ic3A7dGhlICZuYnNwO25h bWUgJm5ic3A7YW5kIA0KJm5ic3A7dGhlICZuYnNwO25hbWVkLW9iamVjdCwgJm5ic3A7YXMgJm5i c3A7d2VsbCAmbmJzcDthcyAmbmJzcDtzdXBwb3J0aW5nIA0KJm5ic3A7aHVtYW4tcmVhZGFibGUg Jm5ic3A7YW5kICZuYnNwO2hpZXJhcmNoaWNhbCAmbmJzcDtuYW1lcy48L0RJVj4NCjxESVY+Jmd0 OyAmbmJzcDs8L0RJVj4NCjxESVY+Jmd0OyAmbmJzcDtBICZuYnNwO1VSTCAmbmJzcDtmb3IgJm5i c3A7dGhpcyAmbmJzcDtJbnRlcm5ldC1EcmFmdCANCiZuYnNwO2lzOjwvRElWPg0KPERJVj4mZ3Q7 ICZuYnNwOzxBIA0KaHJlZj0iaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJh ZnQtZmFycmVsbC1uaS0wMC50eHQiPmh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRz L2RyYWZ0LWZhcnJlbGwtbmktMDAudHh0PC9BPjwvRElWPg0KPERJVj4mZ3Q7ICZuYnNwOzwvRElW Pg0KPERJVj4mZ3Q7ICZuYnNwO0ludGVybmV0LURyYWZ0cyAmbmJzcDthcmUgJm5ic3A7YWxzbyAm bmJzcDthdmFpbGFibGUgJm5ic3A7YnkgDQombmJzcDthbm9ueW1vdXMgJm5ic3A7RlRQICZuYnNw O2F0OjwvRElWPg0KPERJVj4mZ3Q7ICZuYnNwO2Z0cDovL2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1k cmFmdHMvPC9ESVY+DQo8RElWPiZndDsgJm5ic3A7PC9ESVY+DQo8RElWPiZndDsgJm5ic3A7QmVs b3cgJm5ic3A7aXMgJm5ic3A7dGhlICZuYnNwO2RhdGEgJm5ic3A7d2hpY2ggJm5ic3A7d2lsbCAN CiZuYnNwO2VuYWJsZSAmbmJzcDthICZuYnNwO01JTUUgJm5ic3A7Y29tcGxpYW50ICZuYnNwO21h aWwgJm5ic3A7cmVhZGVyIA0KJm5ic3A7aW1wbGVtZW50YXRpb24gJm5ic3A7dG8gJm5ic3A7YXV0 b21hdGljYWxseSAmbmJzcDtyZXRyaWV2ZSAmbmJzcDt0aGUgDQombmJzcDtBU0NJSSAmbmJzcDt2 ZXJzaW9uICZuYnNwO29mICZuYnNwO3RoZSAmbmJzcDtJbnRlcm5ldC1EcmFmdC48L0RJVj4NCjxE SVY+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188L0RJVj4N CjxESVY+ZGVjYWRlICZuYnNwO21haWxpbmcgJm5ic3A7bGlzdDwvRElWPg0KPERJVj5kZWNhZGVA aWV0Zi5vcmc8L0RJVj4NCjxESVY+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9kZWNhZGU8L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+PC9GT05UPjwvRElWPjwvQk9EWT48L0hU TUw+DQo= --=====003_Dragon844323387111_=====--