From risker.chen@huawei.com Tue Jan 10 17:15:36 2012 Return-Path: X-Original-To: decade@ietfa.amsl.com Delivered-To: decade@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0F5921F858E for ; Tue, 10 Jan 2012 17:15:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.05 X-Spam-Level: *** X-Spam-Status: No, score=3.05 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, J_CHICKENPOX_46=0.6, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cPT45QrDLLyU for ; Tue, 10 Jan 2012 17:15:35 -0800 (PST) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 4F88521F8585 for ; Tue, 10 Jan 2012 17:15:33 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LXM004DH0TO2I@szxga04-in.huawei.com> for decade@ietf.org; Wed, 11 Jan 2012 09:15:24 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LXM003RN0TNBZ@szxga04-in.huawei.com> for decade@ietf.org; Wed, 11 Jan 2012 09:15:24 +0800 (CST) Received: from szxeml201-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AGI95798; Wed, 11 Jan 2012 09:15:22 +0800 Received: from SZXEML418-HUB.china.huawei.com (10.82.67.157) by szxeml201-edg.china.huawei.com (172.24.2.39) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 11 Jan 2012 09:15:17 +0800 Received: from SZXEML510-MBS.china.huawei.com ([169.254.8.223]) by szxeml418-hub.china.huawei.com ([10.82.67.157]) with mapi id 14.01.0323.003; Wed, 11 Jan 2012 09:15:00 +0800 Date: Wed, 11 Jan 2012 01:13:20 +0000 From: Chenxiaohui In-reply-to: X-Originating-IP: [10.138.41.30] To: "decade@ietf.org" Message-id: MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_Q5IA8axnZIm+81qad+QrjQ)" Content-language: zh-CN Accept-Language: zh-CN, en-US Thread-topic: WG review of draft-ietf-decade-integration-example-02 Thread-index: AcyuZtEyTmdUAfuhRiaQ6hx2V/nY9QS6uC+gAABAqzADqpwZQA== X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: X-Mailman-Approved-At: Wed, 11 Jan 2012 08:20:52 -0800 Cc: Lijiang Chen , Weihanyu , Hongqiang Liu , "Andy Huang\(Zhigang\)" Subject: [decade] =?gb2312?b?tPC4tDogV0cgcmV2aWV3IG9mIGRyYWZ0LWlldGYtZGVj?= =?gb2312?b?YWRlLWludGVncmF0aW9uLWV4YW1wbGUtMDI=?= X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2012 01:15:36 -0000 --Boundary_(ID_Q5IA8axnZIm+81qad+QrjQ) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: base64 VGhhbmtzIGZvciB5b3VyIGNvbW1lbnRzLg0KDQoNCg0KoaQgICAgICAgICBJIHRoaW5rIHRoZSBk b2N1bWVudCBjb3VsZCBnZW5lcmFsbHkgYmUgaW1wcm92ZWQgaWYgdGhlIGZvbGxvd2luZyBpbmZv cm1hdGlvbiB3ZXJlIGFkZGVkIChvciBleHBhbmRlZCk6DQoNCg0KDQpvICAgU29tZSBtb3JlIGRl dGFpbHMgb2YgdGhlIGFjdHVhbCBwcm90b2NvbHMgdXNlZCBpbiB0aGUgZGlmZmVyZW50IGludGVn cmF0aW9uIHNjZW5hcmlvcyBzaG91bGQgYmUgZ2l2ZW4uICBGb3IgZXhhbXBsZSwgd2hhdCB3ZXJl IHRoZSB1bmRlcmx5aW5nIHByb3RvY29scyBmb3IgdGhlIKGwUDJQIExpdmVTdHJlYW1pbmcgQ2xp ZW50IChQMlBMUymhsT8gICBBcyBhbiBleGFtcGxlLCBIVFRQL1RDUCBhcmUgdGhlIHByb3RvY29s cyB1c2VkIGZvciB3ZWIgYnJvd3NpbmcuICBXaGF0IHdlcmUgdGhlIHByb3RvY29scyBmb3IgUDJQ TFM/ICBBbHNvIHNvbWUgZGV0YWlscyBmb3IgdGhlIHByb3RvY29scyBzaG91bGQgYmUgZ2l2ZW4g ZXZlbiBmb3IgdGhlIKGwQml0VG9ycmVudKGxIGV4YW1wbGUuICBBcyBub3QgYWxsIHJlYWRlcnMg d2lsbCBoYXZlIGtub3dsZWRnZSBvZiBob3cgQml0VG9ycmVudCB3b3Jrcy4NCg0KDQpvICAgU29t ZSBtb3JlIGRldGFpbHMgb2YgdGhlIGZpbGUvb2JqZWN0IG5hbWluZyBzY2hlbWUgdXNlZCBpbiB0 aGUgZGlmZmVyZW50IGludGVncmF0aW9uIHNjZW5hcmlvcyBzaG91bGQgYmUgZ2l2ZW4uICBUaGlz IGlzIGEgY3JpdGljYWwgcGFydCBvZiBERUNBREUgYW5kIHRoZSBhcHByb2FjaGVkIHVzZWQgaW4g dGhlIGV4cGVyaW1lbnRzIGZvciBuYW1pbmcgbXVzdCBiZSBnaXZlbiBmb3IgYSBjb21wbGV0ZSB1 bmRlcnN0YW5kaW5nIG9mIHdoYXQgd2FzIGRvbmUuDQoNCg0KbyAgIEluIHRoZSBJbnRybyAoYW5k IGVsc2V3aGVyZSkgdGhlcmUgbmVlZHMgdG8gYmUgc29tZSBjbGVhciByZWZlcmVuY2VzIHRvIERF Q0FERSBXRyBkb2N1bWVudHMgc3VjaCBhcyB0aGUgUHJvYmxlbSBTdGF0ZW1lbnQsIFJlcXVpcmVt ZW50cyBvciBBcmNoaXRlY3R1cmUgKGFuZCB0aGUgYXNzb2NpYXRlZCBjb25jZXB0cyBkZWZpbmVk IGluIHRob3NlIGRvY3VtZW50cykuICBOb3RlIHRoYXQgdGhlcmUgY2FuIGJlIGRldmlhdGlvbnMg ZnJvbSB0aGUgY29uY2VwdHMgZGVmaW5lZCBpbiB0aGUgREVDQURFIFdHIGRvY3VtZW50cywgYnV0 IHRoZXNlIG5lZWQgdG8gYmUgY2xlYXJseSBleHBsYWluZWQuDQoNCg0KDQqhpCAgICAgICAgIFNv bWUgZGV0YWlsZWQgY29tbWVudHMgb24gc3BlY2lmaWMgc2VjdGlvbnM6DQoNCm8gICBUaGUgQWJz dHJhY3QgaXMgYSBiaXQgZGV0YWlsZWQgYW5kIGl0IGlzIGhhcmQgdG8gdW5kZXJzdGFuZC4gIEZv ciBleGFtcGxlIHRoZXJlIHNob3VsZCBub3QgYmUgYSBsaXN0IChwb2ludHMgMS02KSBpbiBhbiBh YnN0cmFjdC4NCg0KDQpvICAgSW4gc2VjdGlvbiAyLjkgKFJlbW90ZSBDb250cm9sbGVyKSwgSSBk aWQgbm90IHVuZGVyc3RhbmQgd2hhdCChsGEgbWFqb3Igb3BlcmF0aW5nIHBsYXRmb3JtobEgbWVh bnQ/DQoNCg0KbyAgIEkgZGlkIG5vdCB1bmRlcnN0YW5kIHRoZSChsGxpbWl0ZWQgY29ubmVjdGlv biBzbG90obEgaXNzdWUgKHNlYy4gNC4yLjEpLiAgTXkgdW5kZXJzdGFuZGluZyBpcyB0aGF0IGEg REVDQURFIGNsaWVudCB3aWxsIGhhdmUgYW4gYXNzb2NpYXRpb24gd2l0aCBhIGdpdmVuIERFQ0FE RSBzZXJ2ZXIsIGFuZCBub3QgZXZlcnkgb3RoZXIgcG9zc2libGUgc2VydmVyLiAgSXMgdGhpcyB0 aGUgYXNzdW1wdGlvbiB0aGF0IHdhcyB1c2VkIGluIHRoZSBpbnRlZ3JhdGlvbj8NCg0KDQoNCm8g ICBFZGl0b3JpYWw6IFRoZSB3b3JkIERFQ0FERSBpcyBzcGVsbGVkIGluY29ycmVjdGx5IGluIEZp Z3VyZSAyIGFuZCAzLg0KDQoNCm8gICBJIGRpZCBub3QgdW5kZXJzdGFuZCB0aGUgcmVsYXRpb24g YmV0d2VlbiBhIERFQ0FERSBjbGllbnQgYW5kIHNlcnZlciBpbiB0aGUgQUxUTyArIERFQ0FERSBp bnRlZ3JhdGlvbiAoc2VjdGlvbiA2KT8gIERvZXMgQUxUTyBnZXQgaW52b2tlZCBmb3IgYm90aCBQ VVQgYW5kIEdFVCBmcm9tIGEgREVDQURFIGNsaWVudD8gIE9yIGlzIGl0IG9ubHkgZm9yIGEgR0VU Pw0KDQqh7CAgU2ltaWxhcmx5LCBJIGRpZCBub3QgdW5kZXJzdGFuZCB0aGUgUGVyZm9ybWFuY2Ug QW5hbHlzaXMgb2YgdGhlIEFMVE8rREVDQURFIFBlcmZvcm1hbmNlIEFuYWx5c2lzIChzZWN0aW9u IDguMi4zKS4NCg0KDQoNCm8gICBTaG91bGQgYmV0dGVyIGRlZmluZSB3aGF0IGEgobBzbWFsbCBp bnN0YW5jZaGxIGlzIGluIHRoZSBBbWF6b24gRUMyIGZyYW1ld29yayAoc2VjdGlvbiA3LjIuMSkN Cg0KDQoNCm8gICBBIHNob3J0IENvbmNsdXNpb24gc2VjdGlvbiBzaG91bGQgYmUgYWRkZWQgdG8g dGhlIGRvY3VtZW50IGJyaWVmbHkgc3VtbWFyaXppbmcgdGhlIGxlc3NvbnMgbGVhcm5lZCBhbmQg c29tZSBzdWdnZXN0aW9ucyBmb3IgdGhlIERFQ0FERSBkZXNpZ24uICBBcyByaWdodCBub3cgdGhl IGNvbmNsdXNpb25zIGFyZSBzcHJlYWQgb3ZlciBzZXZlcmFsIHNlY3Rpb25zLg0KDQoNCg0KbyAg IFRoZSBTZWN1cml0eSBzZWN0aW9uIChzZWMuIDkpIHNob3VsZCBub3QgYmUgZW1wdHkgYXMgdGhl cmUgbXVzdCBoYXZlIGJlZW4gc29tZSBzZWN1cml0eSByZWxhdGVkIGFzc3VtcHRpb25zIGluIHRo ZSBpbnRlZ3JhdGlvbi4gIEZvciBleGFtcGxlLCB3YXMgYW55IERFQ0FERSBjbGllbnQgYWJsZSB0 byByZWFkIGZyb20gYW55IERFQ0FERSBzZXJ2ZXIgd2l0aG91dCBhdXRoZW50aWNhdGlvbj8gIFll cyBvciBObz8gIEVpdGhlciB3YXkgdGhpcyBzaG91bGQgYmUgZGVzY3JpYmVkLiAgKEluIHNlY3Rp b24gNS4zLCBmb3IgZXhhbXBsZSwgdGhlcmUgd2FzIGEgcmVmZXJlbmNlIHRvIGFuIKGwYXV0aG9y aXphdGlvbiB0b2tlbqGxKS4NCg0KICAgICAgICAgLS0tLWdvb2QgYWR2aWNlLCB3ZSB3aWxsICBw ZXJmZWN0IHRoZW0gbmV4dCB2ZXJzaW9uLg0KDQpGb3IgdGhlIGNvbW1lbnQgZnJvbSBOaW5nIFpv bmcsIHN1cmUsIHRoZXJlIGFyZSBzb21lIHByb2JsZW0gYXMgZm9sbG93aW5nLCB3ZSB3aWxsIGFk ZHJlc3MgdGhlbSBuZXh0IHZlcnNpb24gYWxzby4NCkkgYWxzbyBoYXZlIGZvbGxvd2luZyBjb21t ZW50cyAmIHN1Z2dlc3Rpb25zOg0KDQoxKSAgICAgIEluIFNlY3Rpb24gMSChsEludHJvZHVjdGlv bqGxLCBpdCBzZWVtcyB0aGF0IG9ubHkgUDJQIGxpdmUgc3RyZWFtaW5nIGlzIG1lbnRpb25lZC4g V2Ugc2hvdWxkIGFsc28gbWVudGlvbiBmaWxlIHNoYXJpbmcgYXBwbGljYXRpb24gKGUuZy4gVnV6 ZSkgYW5kIENvbnRlbnQgRGlzdHJpYnV0aW9uIFBsYXRmb3JtIGZvciBDUDsNCg0KMikgICAgICBJ biBTZWN0aW9uIDIsIKGwREVDQURFIE1vZHVsZaGxIGFuZCChsERFQ0FERSBQbHVnaW6hsSBzaG91 bGQgYmUgdGhlIHNhbWUuIFdlIHNob3VsZCBtZXJnZSB0aGVzZSB0d28gZGVmaW5pdGlvbiBhbmQg dXNlIG9uZSB0ZXJtIGluIHRoZSB3aG9sZSBkcmFmdC4NCg0KMykgICAgICBJbiBTZWN0aW9uIDIs IKGwREVDQURFLUVuYWJsZWQgVnV6ZaGxIGlzIGNvdmVyZWQgYnkgobBERUNBREUgQ2xpZW50obEu IEluIHRoZSB3aG9sZSBkcmFmdCwgd2UgY291bGQgZWl0aGVyIHVzZSB0d28gdGVybXMgqEMgobBE RUNBREUtZW5hYmxlZCBWdXplobEgJiChsERFQ0FERS1lbmFibGUgUFBMU6GxLCBvciBqdXN0IHVz ZSChsERFQ0FERSBDbGllbnShsSBmb3IgZ2VuZXJhbCBwdXJwb3NlLg0KDQo0KSAgICAgIEkgdGhp bmsgU2VjdGlvbiA2IG5lZWRzIG1vcmUgZWRpdG9yaWFsIHdvcmsuDQoNCjUpICAgICAgSW4gU2Vj dGlvbiA2LCBJIHRoaW5rIHdloa9kIGJldHRlciB0byBjYWxsIGl0IKGwY29udGVudCBkaXN0cmli dXRpb24gcGxhdGZvcm0gZm9yIENQobEgcmF0aGVyIHRoYW4gobBBTFRPK0RFQ0FERSBwbGF0Zm9y baGxLCBhcyB3ZSBkb26hr3QgZm9jdXMgb24gZGVzY3JpYmluZyBhbiBBTFRPK0RFQ0FERSBhcmNo aXRlY3R1cmUgaW4gdGhpcyBkcmFmdC4NCg0KNikgICAgICBJbiBTZWN0aW9uIDYsIHdloa9kIGJl dHRlciB0byB1c2UgREVDQURFIHNlcnZpY2UgcHJvdmlkZXIgcmF0aGVyIHRoYW4gSVNQIGluIEZp Z3VyZSA0LiBXZSBhbHNvIG5lZWQgbW9yZSBleHBsYW5hdGlvbiB0byBGaWd1cmUgNCwgYXMgdGhl IGNvbm5lY3Rpb25zIGFyZSB1bmNsZWFyLCBlLmcuIGFyZSB0aGVzZSBkYXRhIG9yIHNpZ25hbGlu ZyBsaW5rcz8gRG8gd2UgbmVlZCBtb3JlIGNvbXBvbmVudHMgc3VjaCBhcyBBTFRPIHNlcnZlciBh bmQgY29udGVudCBvcmlnaW5zPw0KDQo3KSAgICAgIEluIFNlY3Rpb24gNywgdGVzdCBzZXR0aW5n cyBmb3IgZGlzdHJpYnV0aW9uIHBsYXRmb3JtIGZvciBDUCBpcyBtaXNzaW5nLCBlLmcuIGhvdyBt YW55IGFuZCB3aGljaCB0eXBlcyBvZiBzZXJ2ZXJzIGFyZSB1c2VkLCB3aGljaCBDUHMgYXJlIHRl c3RlZD8NCg0KOCkgICAgICBJbiBTZWN0aW9uIDgsIEkgdGhpbmsgd2Whr2QgYmV0dGVyIHRvIGdp dmUgYSBjb250ZW50IGRpc3RyaWJ1dGlvbiBwZXJmb3JtYW5jZSBleGFtcGxlLCBlLmcuIGhvdyBs b25nIHRvIGNvbXBsZXRlIGEgY29udGVudCBkaXN0cmlidXRpb24sIHRvIGhvdyBtYW55IHVzZXJz LCBob3cgYWJvdXQgdGhlIGJhbmR3aWR0aCB1c2FnZT8NCg0KDQpGcm9tOiBTb25naGFpYmluDQpT ZW50OiBGcmlkYXksIERlY2VtYmVyIDIzLCAyMDExIDU6MDYgUE0NClRvOiAnUmFobWFuLCBBa2Jh cic7IGRlY2FkZUBpZXRmLm9yZw0KU3ViamVjdDogUkU6IFdHIHJldmlldyBvZiBkcmFmdC1pZXRm LWRlY2FkZS1pbnRlZ3JhdGlvbi1leGFtcGxlLTAyDQoNCkhpIEFrYmFyLA0KDQpUaGFua3MgZm9y IHRoZSBjb21tZW50cy4gVGhlIGF1dGhvcnMgcGxlYXNlIGRpc2N1c3MvYWRkcmVzcyB0aGVzZSBj b21tZW50cy4NCg0KQlIsDQotSGFpYmluDQoNCkZyb206IGRlY2FkZS1ib3VuY2VzQGlldGYub3Jn IFttYWlsdG86ZGVjYWRlLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBSYWhtYW4sIEFr YmFyDQpTZW50OiBUdWVzZGF5LCBOb3ZlbWJlciAyOSwgMjAxMSAzOjE3IFBNDQpUbzogZGVjYWRl QGlldGYub3JnDQpTdWJqZWN0OiBbZGVjYWRlXSBXRyByZXZpZXcgb2YgZHJhZnQtaWV0Zi1kZWNh ZGUtaW50ZWdyYXRpb24tZXhhbXBsZS0wMg0KDQpIaSwNCg0KDQpBcyBwZXIgdGhlIHJlcXVlc3Qg b2YgdGhlIERFQ0FERSBjaGFpcnMgaW4gSUVURiA4MiwgSSBkaWQgYSByZXZpZXcgb2YgdGhlIKGw SW50ZWdyYXRpb24gRXhhbXBsZXMgb2YgREVDQURFIFN5c3RlbaGxIChkcmFmdC1pZXRmLWRlY2Fk ZS1pbnRlZ3JhdGlvbi1leGFtcGxlLTAyKSBhbmQgaGF2ZSB0aGUgZm9sbG93aW5nIGNvbW1lbnRz Og0KDQoNCqGkICAgICAgICAgT3ZlcmFsbCwgSSBmb3VuZCB0aGUgZG9jdW1lbnQgdmVyeSB1c2Vm dWwgaW4gcHJvdmlkaW5nIGV4Y2VsbGVudCBpbnNpZ2h0cyBpbnRvIGhvdyBERUNBREUgY291bGQg YmUgdXNlZCBpbiBhIHJlYWwgbmV0d29yay4gIEFsc28sIEkgdG9vayBpdCBhcyBhIGdvb2QgZXhh bXBsZSBvZiChsHJ1bm5pbmcgY29kZaGxIGZvciBERUNBREUuICBUaGFua3MgZm9yIHRoZSBnb29k IHdvcmshDQoNCg0KoaQgICAgICAgICBJIHRoaW5rIHRoZSBkb2N1bWVudCBjb3VsZCBnZW5lcmFs bHkgYmUgaW1wcm92ZWQgaWYgdGhlIGZvbGxvd2luZyBpbmZvcm1hdGlvbiB3ZXJlIGFkZGVkIChv ciBleHBhbmRlZCk6DQoNCg0KDQpvICAgU29tZSBtb3JlIGRldGFpbHMgb2YgdGhlIGFjdHVhbCBw cm90b2NvbHMgdXNlZCBpbiB0aGUgZGlmZmVyZW50IGludGVncmF0aW9uIHNjZW5hcmlvcyBzaG91 bGQgYmUgZ2l2ZW4uICBGb3IgZXhhbXBsZSwgd2hhdCB3ZXJlIHRoZSB1bmRlcmx5aW5nIHByb3Rv Y29scyBmb3IgdGhlIKGwUDJQIExpdmVTdHJlYW1pbmcgQ2xpZW50IChQMlBMUymhsT8gICBBcyBh biBleGFtcGxlLCBIVFRQL1RDUCBhcmUgdGhlIHByb3RvY29scyB1c2VkIGZvciB3ZWIgYnJvd3Np bmcuICBXaGF0IHdlcmUgdGhlIHByb3RvY29scyBmb3IgUDJQTFM/ICBBbHNvIHNvbWUgZGV0YWls cyBmb3IgdGhlIHByb3RvY29scyBzaG91bGQgYmUgZ2l2ZW4gZXZlbiBmb3IgdGhlIKGwQml0VG9y cmVudKGxIGV4YW1wbGUuICBBcyBub3QgYWxsIHJlYWRlcnMgd2lsbCBoYXZlIGtub3dsZWRnZSBv ZiBob3cgQml0VG9ycmVudCB3b3Jrcy4NCg0KDQpvICAgU29tZSBtb3JlIGRldGFpbHMgb2YgdGhl IGZpbGUvb2JqZWN0IG5hbWluZyBzY2hlbWUgdXNlZCBpbiB0aGUgZGlmZmVyZW50IGludGVncmF0 aW9uIHNjZW5hcmlvcyBzaG91bGQgYmUgZ2l2ZW4uICBUaGlzIGlzIGEgY3JpdGljYWwgcGFydCBv ZiBERUNBREUgYW5kIHRoZSBhcHByb2FjaGVkIHVzZWQgaW4gdGhlIGV4cGVyaW1lbnRzIGZvciBu YW1pbmcgbXVzdCBiZSBnaXZlbiBmb3IgYSBjb21wbGV0ZSB1bmRlcnN0YW5kaW5nIG9mIHdoYXQg d2FzIGRvbmUuDQoNCg0KbyAgIEluIHRoZSBJbnRybyAoYW5kIGVsc2V3aGVyZSkgdGhlcmUgbmVl ZHMgdG8gYmUgc29tZSBjbGVhciByZWZlcmVuY2VzIHRvIERFQ0FERSBXRyBkb2N1bWVudHMgc3Vj aCBhcyB0aGUgUHJvYmxlbSBTdGF0ZW1lbnQsIFJlcXVpcmVtZW50cyBvciBBcmNoaXRlY3R1cmUg KGFuZCB0aGUgYXNzb2NpYXRlZCBjb25jZXB0cyBkZWZpbmVkIGluIHRob3NlIGRvY3VtZW50cyku ICBOb3RlIHRoYXQgdGhlcmUgY2FuIGJlIGRldmlhdGlvbnMgZnJvbSB0aGUgY29uY2VwdHMgZGVm aW5lZCBpbiB0aGUgREVDQURFIFdHIGRvY3VtZW50cywgYnV0IHRoZXNlIG5lZWQgdG8gYmUgY2xl YXJseSBleHBsYWluZWQuDQoNCg0KDQoNCqGkICAgICAgICAgU29tZSBkZXRhaWxlZCBjb21tZW50 cyBvbiBzcGVjaWZpYyBzZWN0aW9uczoNCg0KbyAgIFRoZSBBYnN0cmFjdCBpcyBhIGJpdCBkZXRh aWxlZCBhbmQgaXQgaXMgaGFyZCB0byB1bmRlcnN0YW5kLiAgRm9yIGV4YW1wbGUgdGhlcmUgc2hv dWxkIG5vdCBiZSBhIGxpc3QgKHBvaW50cyAxLTYpIGluIGFuIGFic3RyYWN0Lg0KDQoNCm8gICBJ biBzZWN0aW9uIDIuOSAoUmVtb3RlIENvbnRyb2xsZXIpLCBJIGRpZCBub3QgdW5kZXJzdGFuZCB3 aGF0IKGwYSBtYWpvciBvcGVyYXRpbmcgcGxhdGZvcm2hsSBtZWFudD8NCg0KDQpvICAgSSBkaWQg bm90IHVuZGVyc3RhbmQgdGhlIKGwbGltaXRlZCBjb25uZWN0aW9uIHNsb3ShsSBpc3N1ZSAoc2Vj LiA0LjIuMSkuICBNeSB1bmRlcnN0YW5kaW5nIGlzIHRoYXQgYSBERUNBREUgY2xpZW50IHdpbGwg aGF2ZSBhbiBhc3NvY2lhdGlvbiB3aXRoIGEgZ2l2ZW4gREVDQURFIHNlcnZlciwgYW5kIG5vdCBl dmVyeSBvdGhlciBwb3NzaWJsZSBzZXJ2ZXIuICBJcyB0aGlzIHRoZSBhc3N1bXB0aW9uIHRoYXQg d2FzIHVzZWQgaW4gdGhlIGludGVncmF0aW9uPw0KDQoNCg0KbyAgIEVkaXRvcmlhbDogVGhlIHdv cmQgREVDQURFIGlzIHNwZWxsZWQgaW5jb3JyZWN0bHkgaW4gRmlndXJlIDIgYW5kIDMuDQoNCg0K byAgIEkgZGlkIG5vdCB1bmRlcnN0YW5kIHRoZSByZWxhdGlvbiBiZXR3ZWVuIGEgREVDQURFIGNs aWVudCBhbmQgc2VydmVyIGluIHRoZSBBTFRPICsgREVDQURFIGludGVncmF0aW9uIChzZWN0aW9u IDYpPyAgRG9lcyBBTFRPIGdldCBpbnZva2VkIGZvciBib3RoIFBVVCBhbmQgR0VUIGZyb20gYSBE RUNBREUgY2xpZW50PyAgT3IgaXMgaXQgb25seSBmb3IgYSBHRVQ/DQoNCqHsICBTaW1pbGFybHks IEkgZGlkIG5vdCB1bmRlcnN0YW5kIHRoZSBQZXJmb3JtYW5jZSBBbmFseXNpcyBvZiB0aGUgQUxU TytERUNBREUgUGVyZm9ybWFuY2UgQW5hbHlzaXMgKHNlY3Rpb24gOC4yLjMpLg0KDQoNCg0KbyAg IFNob3VsZCBiZXR0ZXIgZGVmaW5lIHdoYXQgYSChsHNtYWxsIGluc3RhbmNlobEgaXMgaW4gdGhl IEFtYXpvbiBFQzIgZnJhbWV3b3JrIChzZWN0aW9uIDcuMi4xKQ0KDQoNCg0KbyAgIEEgc2hvcnQg Q29uY2x1c2lvbiBzZWN0aW9uIHNob3VsZCBiZSBhZGRlZCB0byB0aGUgZG9jdW1lbnQgYnJpZWZs eSBzdW1tYXJpemluZyB0aGUgbGVzc29ucyBsZWFybmVkIGFuZCBzb21lIHN1Z2dlc3Rpb25zIGZv ciB0aGUgREVDQURFIGRlc2lnbi4gIEFzIHJpZ2h0IG5vdyB0aGUgY29uY2x1c2lvbnMgYXJlIHNw cmVhZCBvdmVyIHNldmVyYWwgc2VjdGlvbnMuDQoNCg0KDQpvICAgVGhlIFNlY3VyaXR5IHNlY3Rp b24gKHNlYy4gOSkgc2hvdWxkIG5vdCBiZSBlbXB0eSBhcyB0aGVyZSBtdXN0IGhhdmUgYmVlbiBz b21lIHNlY3VyaXR5IHJlbGF0ZWQgYXNzdW1wdGlvbnMgaW4gdGhlIGludGVncmF0aW9uLiAgRm9y IGV4YW1wbGUsIHdhcyBhbnkgREVDQURFIGNsaWVudCBhYmxlIHRvIHJlYWQgZnJvbSBhbnkgREVD QURFIHNlcnZlciB3aXRob3V0IGF1dGhlbnRpY2F0aW9uPyAgWWVzIG9yIE5vPyAgRWl0aGVyIHdh eSB0aGlzIHNob3VsZCBiZSBkZXNjcmliZWQuICAoSW4gc2VjdGlvbiA1LjMsIGZvciBleGFtcGxl LCB0aGVyZSB3YXMgYSByZWZlcmVuY2UgdG8gYW4gobBhdXRob3JpemF0aW9uIHRva2VuobEpLg0K DQoNClRoYXShr3MgYWxsLg0KDQoNCkFrYmFyDQo= --Boundary_(ID_Q5IA8axnZIm+81qad+QrjQ) Content-type: text/html; charset=gb2312 Content-transfer-encoding: quoted-printable

Thanks for your comments.

 

 

=A1=A4         I think the document co= uld generally be improved if the following information were added (or expan= ded):

 =

o   Some more details of th= e actual protocols used in the different integration scenarios should be gi= ven.  For example, what were the underlying protocols for the =A1=B0P2= P LiveStreaming Client (P2PLS)=A1=B1?   As an example, HTTP/TCP are the protocols used for web browsing.  What were the prot= ocols for P2PLS?  Also some details for the protocols should be given = even for the =A1=B0BitTorrent=A1=B1 example.  As not all readers will = have knowledge of how BitTorrent works.

 

o   Some more details of th= e file/object naming scheme used in the different integration scenarios sho= uld be given.  This is a critical part of DECADE and the approached us= ed in the experiments for naming must be given for a complete understanding of what was done.

 

o   In the Intro (and elsew= here) there needs to be some clear references to DECADE WG documents such a= s the Problem Statement, Requirements or Architecture (and the associated c= oncepts defined in those documents).  Note that there can be deviations from the concepts defined in the DECADE = WG documents, but these need to be clearly explained.   &nbs= p;    

 =

=A1=A4         Some detailed comments = on specific sections:

o   The Abstract is a bit d= etailed and it is hard to understand.  For example there should not be= a list (points 1-6) in an abstract.

 

o   In section 2.9 (Remote = Controller), I did not understand what =A1=B0a major operating platform=A1= =B1 meant?

 

o   I did not understand th= e =A1=B0limited connection slot=A1=B1 issue (sec. 4.2.1).  My understa= nding is that a DECADE client will have an association with a given DECADE = server, and not every other possible server.  Is this the assumption that was used in the integration?

 =

o   Editorial: The word DEC= ADE is spelled incorrectly in Figure 2 and 3.

 

o   I did not understand th= e relation between a DECADE client and server in the ALTO + DECADE inte= gration (section 6)?  Does ALTO get invoked for both PUT and GET from = a DECADE client?  Or is it only for a GET?

<= span style=3D"mso-list:Ignore">=A1=EC  Similarly, I did not un= derstand the Performance Analysis of the ALTO+DECADE Performance Analys= is (section 8.2.3).

 =

o   Should better define wh= at a =A1=B0small instance=A1=B1 is in the Amazon EC2 framework (section 7.2= .1)

 =

o   A short Conclusion sect= ion should be added to the document briefly summarizing the lessons learned= and some suggestions for the DECADE design.  As right now the conclus= ions are spread over several sections.

 =

o   The Security section (s= ec. 9) should not be empty as there must have been some security related as= sumptions in the integration.  For example, was any DECADE client able= to read from any DECADE server without authentication?  Yes or No?  Either way this should be described= .  (In section 5.3, for example, there was a reference to an =A1=B0aut= horization token=A1=B1).

 

      = ;   ----good advice, we w= ill  perfect them next version.

 

For the comment from Ning Zong, sure, there are some problem as follo= wing, we will address them next version also.

I also have following comments = & suggestions:

1= )   &= nbsp;  In Section 1 =A1=B0Intr= oduction=A1=B1, it seems that only P2P live streaming is mentioned. We shou= ld also mention file sharing application (e.g. Vuze) and Content Distributi= on Platform for CP;

2= )   &= nbsp;  In Section 2, =A1=B0DEC= ADE Module=A1=B1 and =A1=B0DECADE Plugin=A1=B1 should be the same. We shoul= d merge these two definition and use one term in the whole draft.

3= )   &= nbsp;  In Section 2, =A1=B0DEC= ADE-Enabled Vuze=A1=B1 is covered by =A1=B0DECADE Client=A1=B1. In the whol= e draft, we could either use two terms =A8C =A1=B0DECADE-enabled Vuze=A1=B1= & =A1=B0DECADE-enable PPLS=A1=B1, or just use =A1=B0DECADE Client=A1= =B1 for general purpose.

4= )   &= nbsp;  I think Section 6 needs= more editorial work.

5= )   &= nbsp;  In Section 6, I think w= e=A1=AFd better to call it =A1=B0content distribution platform for CP=A1=B1= rather than =A1=B0ALTO+DECADE platform=A1=B1, as we don=A1=AFt focus o= n describing an ALTO+DECADE architecture in this draft.

6= )   &= nbsp;  In Section 6, we=A1=AFd= better to use DECADE service provider rather than ISP in Figure 4. We also= need more explanation to Figure 4, as the connections are unclear, e.g. ar= e these data or signaling links? Do we need more components such as ALTO server and content origins?

7= )   &= nbsp;  In Section 7, test sett= ings for distribution platform for CP is missing, e.g. how many and which t= ypes of servers are used, which CPs are tested?

8= )   &= nbsp;  In Section 8, I think w= e=A1=AFd better to give a content distribution performance example, e.g. ho= w long to complete a content distribution, to how many users, how about the= bandwidth usage?

 

 

From: Songhaibin
Sent: Friday, December 23, 2011 5:06 PM
To: 'Rahman, Akbar'; decade@ietf.org
Subject: RE: WG review of draft-ietf-decade-integration-example-02

 

Hi Akbar,

 

Thanks for the comments. The authors please discuss/address these= comments.

 

BR,

-Haibin

 

From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.o= rg] On Behalf Of Rahman, Akbar
Sent: Tuesday, November 29, 2011 3:17 PM
To: decade@ietf.org
Subject: [decade] WG review of draft-ietf-decade-integration-example= -02

 

Hi,

 

 

As per the request of the DECAD= E chairs in IETF 82, I did a review of the =A1=B0Integration Examples of DE= CADE System=A1=B1 (draft-ietf-decade-integration-example-02) and have the f= ollowing comments:

 

=A1=A4         Overall, I found the do= cument very useful in providing excellent insights into how DECADE could be= used in a real network.  Also, I took it as a good example of =A1=B0r= unning code=A1=B1 for DECADE.  Thanks for the good work!

 

=A1=A4         I think the document co= uld generally be improved if the following information were added (or expan= ded):

 =

o   Some more details of th= e actual protocols used in the different integration scenarios should be gi= ven.  For example, what were the underlying protocols for the =A1=B0P2= P LiveStreaming Client (P2PLS)=A1=B1?   As an example, HTTP/TCP are the protocols used for web browsing.  What were the prot= ocols for P2PLS?  Also some details for the protocols should be given = even for the =A1=B0BitTorrent=A1=B1 example.  As not all readers will = have knowledge of how BitTorrent works.

 

o   Some more details of th= e file/object naming scheme used in the different integration scenarios sho= uld be given.  This is a critical part of DECADE and the approached us= ed in the experiments for naming must be given for a complete understanding of what was done.

 

o   In the Intro (and elsew= here) there needs to be some clear references to DECADE WG documents such a= s the Problem Statement, Requirements or Architecture (and the associated c= oncepts defined in those documents).  Note that there can be deviations from the concepts defined in the DECADE = WG documents, but these need to be clearly explained.

 

 =

=A1=A4         Some detailed comments = on specific sections:

o   The Abstract is a bit d= etailed and it is hard to understand.  For example there should not be= a list (points 1-6) in an abstract.

 

o   In section 2.9 (Remote = Controller), I did not understand what =A1=B0a major operating platform=A1= =B1 meant?

 

o   I did not understand th= e =A1=B0limited connection slot=A1=B1 issue (sec. 4.2.1).  My understa= nding is that a DECADE client will have an association with a given DECADE = server, and not every other possible server.  Is this the assumption that was used in the integration?

 =

o   Editorial: The word DEC= ADE is spelled incorrectly in Figure 2 and 3.

 

o   I did not understand th= e relation between a DECADE client and server in the ALTO + DECADE inte= gration (section 6)?  Does ALTO get invoked for both PUT and GET from = a DECADE client?  Or is it only for a GET?

<= span style=3D"mso-list:Ignore">=A1=EC  Similarly, I did not un= derstand the Performance Analysis of the ALTO+DECADE Performance Analys= is (section 8.2.3).

 =

o   Should better define wh= at a =A1=B0small instance=A1=B1 is in the Amazon EC2 framework (section 7.2= .1)

 =

o   A short Conclusion sect= ion should be added to the document briefly summarizing the lessons learned= and some suggestions for the DECADE design.  As right now the conclus= ions are spread over several sections.

 =

o   The Security section (s= ec. 9) should not be empty as there must have been some security related as= sumptions in the integration.  For example, was any DECADE client able= to read from any DECADE server without authentication?  Yes or No?  Either way this should be described= .  (In section 5.3, for example, there was a reference to an =A1=B0aut= horization token=A1=B1).

 

 

That=A1=AFs all.

 

 

Akbar

--Boundary_(ID_Q5IA8axnZIm+81qad+QrjQ)-- From risker.chen@huawei.com Wed Jan 11 19:38:27 2012 Return-Path: X-Original-To: decade@ietfa.amsl.com Delivered-To: decade@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77B7421F8752 for ; Wed, 11 Jan 2012 19:38:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.05 X-Spam-Level: *** X-Spam-Status: No, score=3.05 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, J_CHICKENPOX_46=0.6, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jmz8uC2o4TXk for ; Wed, 11 Jan 2012 19:38:25 -0800 (PST) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 1B00921F8750 for ; Wed, 11 Jan 2012 19:38:24 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LXO00G0723SUH@szxga04-in.huawei.com> for decade@ietf.org; Thu, 12 Jan 2012 11:38:16 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LXO00K7323RJ2@szxga04-in.huawei.com> for decade@ietf.org; Thu, 12 Jan 2012 11:38:16 +0800 (CST) Received: from szxeml207-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AGG49968; Thu, 12 Jan 2012 11:38:11 +0800 Received: from SZXEML407-HUB.china.huawei.com (10.82.67.94) by szxeml207-edg.china.huawei.com (172.24.2.59) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 12 Jan 2012 11:38:05 +0800 Received: from SZXEML510-MBS.china.huawei.com ([169.254.8.223]) by szxeml407-hub.china.huawei.com ([10.82.67.94]) with mapi id 14.01.0323.003; Thu, 12 Jan 2012 11:37:51 +0800 Date: Thu, 12 Jan 2012 03:37:05 +0000 From: Chenxiaohui In-reply-to: X-Originating-IP: [10.138.41.30] To: "decade@ietf.org" Message-id: MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_LrfiUpywoAFd+4Us1x6Qhw)" Content-language: zh-CN Accept-Language: zh-CN, en-US Thread-topic: WG review of draft-ietf-decade-integration-example-02 Thread-index: AcyuZtEyTmdUAfuhRiaQ6hx2V/nY9QS6uC+gAABAqzADqpwZQAA0hifw X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: Cc: Lijiang Chen , Weihanyu , Hongqiang Liu , "Andy Huang\(Zhigang\)" Subject: [decade] =?gb2312?b?tPC4tDogV0cgcmV2aWV3IG9mIGRyYWZ0LWlldGYtZGVj?= =?gb2312?b?YWRlLWludGVncmF0aW9uLWV4YW1wbGUtMDI=?= X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2012 03:38:27 -0000 --Boundary_(ID_LrfiUpywoAFd+4Us1x6Qhw) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: base64 Rm9yIHRoZSBxdWVzdGlvbnMsIEkgd2lsbCBleHBsYWluIGFzIGZvbGxvd2luZzoNCg0KDQqhpCAg ICAgICAgIEkgdGhpbmsgdGhlIGRvY3VtZW50IGNvdWxkIGdlbmVyYWxseSBiZSBpbXByb3ZlZCBp ZiB0aGUgZm9sbG93aW5nIGluZm9ybWF0aW9uIHdlcmUgYWRkZWQgKG9yIGV4cGFuZGVkKToNCg0K DQoNCm8gICBTb21lIG1vcmUgZGV0YWlscyBvZiB0aGUgYWN0dWFsIHByb3RvY29scyB1c2VkIGlu IHRoZSBkaWZmZXJlbnQgaW50ZWdyYXRpb24gc2NlbmFyaW9zIHNob3VsZCBiZSBnaXZlbi4gIEZv ciBleGFtcGxlLCB3aGF0IHdlcmUgdGhlIHVuZGVybHlpbmcgcHJvdG9jb2xzIGZvciB0aGUgobBQ MlAgTGl2ZVN0cmVhbWluZyBDbGllbnQgKFAyUExTKaGxPyAgIEFzIGFuIGV4YW1wbGUsIEhUVFAv VENQIGFyZSB0aGUgcHJvdG9jb2xzIHVzZWQgZm9yIHdlYiBicm93c2luZy4gIFdoYXQgd2VyZSB0 aGUgcHJvdG9jb2xzIGZvciBQMlBMUz8gIEFsc28gc29tZSBkZXRhaWxzIGZvciB0aGUgcHJvdG9j b2xzIHNob3VsZCBiZSBnaXZlbiBldmVuIGZvciB0aGUgobBCaXRUb3JyZW50obEgZXhhbXBsZS4g IEFzIG5vdCBhbGwgcmVhZGVycyB3aWxsIGhhdmUga25vd2xlZGdlIG9mIGhvdyBCaXRUb3JyZW50 IHdvcmtzLg0KDQogICAgICAgICAtLS0tLS1IVFRQIGlzIHRoZSBwcm90b2NvbCB1c2VkIGZvciBQ MlBMUy4gU29tZSBkZXRhaWxzIGZvciB0aGUgcHJvdG9jb2wgbGlrZSChsEJpdFRvcnJlbnShsSB3 aWxsIGJlIGdpdmVuIGluIG5leHQgdmVyc2lvbi4NCg0KDQpvICAgU29tZSBtb3JlIGRldGFpbHMg b2YgdGhlIGZpbGUvb2JqZWN0IG5hbWluZyBzY2hlbWUgdXNlZCBpbiB0aGUgZGlmZmVyZW50IGlu dGVncmF0aW9uIHNjZW5hcmlvcyBzaG91bGQgYmUgZ2l2ZW4uICBUaGlzIGlzIGEgY3JpdGljYWwg cGFydCBvZiBERUNBREUgYW5kIHRoZSBhcHByb2FjaGVkIHVzZWQgaW4gdGhlIGV4cGVyaW1lbnRz IGZvciBuYW1pbmcgbXVzdCBiZSBnaXZlbiBmb3IgYSBjb21wbGV0ZSB1bmRlcnN0YW5kaW5nIG9m IHdoYXQgd2FzIGRvbmUuDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg LS0tLS0tV2Ugd2lsbCBnaXZlIHRoZW0gaW4gbmV4dCB2ZXJzaW9uLg0KDQoNCm8gICBJbiB0aGUg SW50cm8gKGFuZCBlbHNld2hlcmUpIHRoZXJlIG5lZWRzIHRvIGJlIHNvbWUgY2xlYXIgcmVmZXJl bmNlcyB0byBERUNBREUgV0cgZG9jdW1lbnRzIHN1Y2ggYXMgdGhlIFByb2JsZW0gU3RhdGVtZW50 LCBSZXF1aXJlbWVudHMgb3IgQXJjaGl0ZWN0dXJlIChhbmQgdGhlIGFzc29jaWF0ZWQgY29uY2Vw dHMgZGVmaW5lZCBpbiB0aG9zZSBkb2N1bWVudHMpLiAgTm90ZSB0aGF0IHRoZXJlIGNhbiBiZSBk ZXZpYXRpb25zIGZyb20gdGhlIGNvbmNlcHRzIGRlZmluZWQgaW4gdGhlIERFQ0FERSBXRyBkb2N1 bWVudHMsIGJ1dCB0aGVzZSBuZWVkIHRvIGJlIGNsZWFybHkgZXhwbGFpbmVkLg0KDQogICAgICAg ICAgICAgICAgICAgICAgICAtLS0tLS1XZSB3aWxsIGV4cGxhaW4gdGhlbSBpbiBuZXh0IHZlcnNp b24uDQoNCg0KDQqhpCAgICAgICAgIFNvbWUgZGV0YWlsZWQgY29tbWVudHMgb24gc3BlY2lmaWMg c2VjdGlvbnM6DQoNCm8gICBUaGUgQWJzdHJhY3QgaXMgYSBiaXQgZGV0YWlsZWQgYW5kIGl0IGlz IGhhcmQgdG8gdW5kZXJzdGFuZC4gIEZvciBleGFtcGxlIHRoZXJlIHNob3VsZCBub3QgYmUgYSBs aXN0IChwb2ludHMgMS02KSBpbiBhbiBhYnN0cmFjdC4NCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAtLS0tLS1Hb29kIGFkdmljZSwgV2Ugd2lsbCBwZXJmZWN0IHRoZSChsEFi c3RyYWN0obEgaW4gbmV4dCB2ZXJzaW9uDQoNCg0KbyAgIEluIHNlY3Rpb24gMi45IChSZW1vdGUg Q29udHJvbGxlciksIEkgZGlkIG5vdCB1bmRlcnN0YW5kIHdoYXQgobBhIG1ham9yIG9wZXJhdGlu ZyBwbGF0Zm9ybaGxIG1lYW50Pw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg LS0tLS0tobBhIG1ham9yIG9wZXJhdGluZyBwbGF0Zm9ybaGxIG1lYW5zOiBpbiB0aGUgdHJhaWws IHdlIGFsd2F5cyB1c2UgobBSZW1vdGUgQ29udHJvbGxlcqGxIHRvIGNvbnRyb2wgVnV6ZSBzZXJ2 ZXIgYW5kIFZ1emUgY2xpZW50cywNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgV2UgbG9vayBSZW1vdGUgQ29udHJvbGxlciBhcyBhIG9wZXJhdGluZyBwbGF0 Zm9ybSB0byBzdGFydC9zdG9wIGEgdHJhaWwsIGFuZCBjb2xsZWN0IGRlYnVnIGluZm9ybWF0aW9u Lg0KDQoNCm8gICBJIGRpZCBub3QgdW5kZXJzdGFuZCB0aGUgobBsaW1pdGVkIGNvbm5lY3Rpb24g c2xvdKGxIGlzc3VlIChzZWMuIDQuMi4xKS4gIE15IHVuZGVyc3RhbmRpbmcgaXMgdGhhdCBhIERF Q0FERSBjbGllbnQgd2lsbCBoYXZlIGFuIGFzc29jaWF0aW9uIHdpdGggYSBnaXZlbiBERUNBREUg c2VydmVyLCBhbmQgbm90IGV2ZXJ5IG90aGVyIHBvc3NpYmxlIHNlcnZlci4gIElzIHRoaXMgdGhl IGFzc3VtcHRpb24gdGhhdCB3YXMgdXNlZCBpbiB0aGUgaW50ZWdyYXRpb24/DQoNCi0tLS0tLVll cywgSXQgaXMgYW4gYXNzdW1wdGlvbiB1bmRlciB0aGUgY29uZGl0aW9uIHRoYXQgaWYgb25seSBv bmUgREVDQURFIFNlcnZlciBpbiBzdG9yYWdlIG5ldHdvcmsuDQoNCg0KDQpvICAgRWRpdG9yaWFs OiBUaGUgd29yZCBERUNBREUgaXMgc3BlbGxlZCBpbmNvcnJlY3RseSBpbiBGaWd1cmUgMiBhbmQg My4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC0tLS0tLSBXZSB3aWxsIHBl cmZlY3QgdGhlIKGwQWJzdHJhY3ShsSBpbiBuZXh0IHZlcnNpb24NCg0KDQpvICAgSSBkaWQgbm90 IHVuZGVyc3RhbmQgdGhlIHJlbGF0aW9uIGJldHdlZW4gYSBERUNBREUgY2xpZW50IGFuZCBzZXJ2 ZXIgaW4gdGhlIEFMVE8gKyBERUNBREUgaW50ZWdyYXRpb24gKHNlY3Rpb24gNik/ICBEb2VzIEFM VE8gZ2V0IGludm9rZWQgZm9yIGJvdGggUFVUIGFuZCBHRVQgZnJvbSBhIERFQ0FERSBjbGllbnQ/ ICBPciBpcyBpdCBvbmx5IGZvciBhIEdFVD8NCg0KLS0tLS0tSW4gcHJpbmNpcGxlLCBBTFRPIGNh biBzZXJ2aWNlIGJvdGggUFVUIGFuZCBHRVQuDQoNCg0KDQqh7CAgU2ltaWxhcmx5LCBJIGRpZCBu b3QgdW5kZXJzdGFuZCB0aGUgUGVyZm9ybWFuY2UgQW5hbHlzaXMgb2YgdGhlIEFMVE8rREVDQURF IFBlcmZvcm1hbmNlIEFuYWx5c2lzIChzZWN0aW9uIDguMi4zKS4NCg0KICAgICAgICAgICAgICAg ICAgICAtLS0tLS0gVGhlIFBlcmZvcm1hbmNlIEFuYWx5c2lzIHByZXNlbnQgdGhlIHVzaW5nIHJh dGUgb2YgYmFuZHdpZHRoIGluIGVhY2ggREVDQURFIFNlcnZlciBhbmQgdG90YWwgb25saW5lIHVz ZXJzIGNhbiBiZSBzdXBwb3J0IGluIE9uZQ0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAg IERFQ0FERSBTZXJ2ZXIuDQoNCm8gICBTaG91bGQgYmV0dGVyIGRlZmluZSB3aGF0IGEgobBzbWFs bCBpbnN0YW5jZaGxIGlzIGluIHRoZSBBbWF6b24gRUMyIGZyYW1ld29yayAoc2VjdGlvbiA3LjIu MSkNCg0KICAgICAgICAgICAgICAgICAgICAgLS0tLS0tV2Ugd2lsbCBkZWZpbmUgaXQgaW4gbmV4 dCB2ZXJzaW9uLg0KDQoNCg0KbyAgIEEgc2hvcnQgQ29uY2x1c2lvbiBzZWN0aW9uIHNob3VsZCBi ZSBhZGRlZCB0byB0aGUgZG9jdW1lbnQgYnJpZWZseSBzdW1tYXJpemluZyB0aGUgbGVzc29ucyBs ZWFybmVkIGFuZCBzb21lIHN1Z2dlc3Rpb25zIGZvciB0aGUgREVDQURFIGRlc2lnbi4gIEFzIHJp Z2h0IG5vdyB0aGUgY29uY2x1c2lvbnMgYXJlIHNwcmVhZCBvdmVyIHNldmVyYWwgc2VjdGlvbnMu DQoNCiAgICAgICAgICAgICAgICAgICAgIC0tLS0tLVdlIHdpbGwgYWRkIGluIG5leHQgdmVyc2lv bi4NCg0KDQoNCm8gICBUaGUgU2VjdXJpdHkgc2VjdGlvbiAoc2VjLiA5KSBzaG91bGQgbm90IGJl IGVtcHR5IGFzIHRoZXJlIG11c3QgaGF2ZSBiZWVuIHNvbWUgc2VjdXJpdHkgcmVsYXRlZCBhc3N1 bXB0aW9ucyBpbiB0aGUgaW50ZWdyYXRpb24uICBGb3IgZXhhbXBsZSwgd2FzIGFueSBERUNBREUg Y2xpZW50IGFibGUgdG8gcmVhZCBmcm9tIGFueSBERUNBREUgc2VydmVyIHdpdGhvdXQgYXV0aGVu dGljYXRpb24/ICBZZXMgb3IgTm8/ICBFaXRoZXIgd2F5IHRoaXMgc2hvdWxkIGJlIGRlc2NyaWJl ZC4gIChJbiBzZWN0aW9uIDUuMywgZm9yIGV4YW1wbGUsIHRoZXJlIHdhcyBhIHJlZmVyZW5jZSB0 byBhbiChsGF1dGhvcml6YXRpb24gdG9rZW6hsSkuDQoNCiAgICAgICAgICAgICAgICAgICAgIC0t LS0tLU5vLCBhdXRoZW50aWNhdGlvbiBpcyBuZWVkZWQsIFdlIHdpbGwgYWRkIGl0IGluIG5leHQg dmVyc2lvbi4NCg0KDQoNCkkgYWxzbyBoYXZlIGZvbGxvd2luZyBjb21tZW50cyAmIHN1Z2dlc3Rp b25zOg0KDQoxKSAgICAgIEluIFNlY3Rpb24gMSChsEludHJvZHVjdGlvbqGxLCBpdCBzZWVtcyB0 aGF0IG9ubHkgUDJQIGxpdmUgc3RyZWFtaW5nIGlzIG1lbnRpb25lZC4gV2Ugc2hvdWxkIGFsc28g bWVudGlvbiBmaWxlIHNoYXJpbmcgYXBwbGljYXRpb24gKGUuZy4gVnV6ZSkgYW5kIENvbnRlbnQg RGlzdHJpYnV0aW9uIFBsYXRmb3JtIGZvciBDUDsNCg0KLS0tLS0tV2Ugd2lsbCBwZXJmZWN0IGl0 IGluIG5leHQgdmVyc2lvbi4NCg0KDQoNCjIpICAgICAgSW4gU2VjdGlvbiAyLCChsERFQ0FERSBN b2R1bGWhsSBhbmQgobBERUNBREUgUGx1Z2luobEgc2hvdWxkIGJlIHRoZSBzYW1lLiBXZSBzaG91 bGQgbWVyZ2UgdGhlc2UgdHdvIGRlZmluaXRpb24gYW5kIHVzZSBvbmUgdGVybSBpbiB0aGUgd2hv bGUgZHJhZnQuDQoNCiAgICAgICAgICAgLS0tLS0tT0ssIFdlIHdpbGwgcGVyZmVjdCBpdCBpbiBu ZXh0IHZlcnNpb24uDQoNCg0KDQozKSAgICAgIEluIFNlY3Rpb24gMiwgobBERUNBREUtRW5hYmxl ZCBWdXplobEgaXMgY292ZXJlZCBieSChsERFQ0FERSBDbGllbnShsS4gSW4gdGhlIHdob2xlIGRy YWZ0LCB3ZSBjb3VsZCBlaXRoZXIgdXNlIHR3byB0ZXJtcyCoQyChsERFQ0FERS1lbmFibGVkIFZ1 emWhsSAmIKGwREVDQURFLWVuYWJsZSBQUExTobEsIG9yIGp1c3QgdXNlIKGwREVDQURFIENsaWVu dKGxIGZvciBnZW5lcmFsIHB1cnBvc2UuDQoNCiAgICAgICAgICAgLS0tLS0tT0ssIFdlIHdpbGwg cGVyZmVjdCBpdCBpbiBuZXh0IHZlcnNpb24uDQoNCg0KDQo0KSAgICAgIEkgdGhpbmsgU2VjdGlv biA2IG5lZWRzIG1vcmUgZWRpdG9yaWFsIHdvcmsuDQogICAgICAgICAgICAgICAgICAgLS0tLS0t T0ssIFdlIHdpbGwgcGVyZmVjdCBpdCBpbiBuZXh0IHZlcnNpb24uDQoNCg0KNSkgICAgICBJbiBT ZWN0aW9uIDYsIEkgdGhpbmsgd2Whr2QgYmV0dGVyIHRvIGNhbGwgaXQgobBjb250ZW50IGRpc3Ry aWJ1dGlvbiBwbGF0Zm9ybSBmb3IgQ1ChsSByYXRoZXIgdGhhbiChsEFMVE8rREVDQURFIHBsYXRm b3JtobEsIGFzIHdlIGRvbqGvdCBmb2N1cyBvbiBkZXNjcmliaW5nIGFuIEFMVE8rREVDQURFIGFy Y2hpdGVjdHVyZSBpbiB0aGlzIGRyYWZ0Lg0KICAgICAgICAgICAgICAgICAgIC0tLS0tLU9LLCBX ZSB3aWxsIHBlcmZlY3QgaXQgaW4gbmV4dCB2ZXJzaW9uLg0KDQoNCjYpICAgICAgSW4gU2VjdGlv biA2LCB3ZaGvZCBiZXR0ZXIgdG8gdXNlIERFQ0FERSBzZXJ2aWNlIHByb3ZpZGVyIHJhdGhlciB0 aGFuIElTUCBpbiBGaWd1cmUgNC4gV2UgYWxzbyBuZWVkIG1vcmUgZXhwbGFuYXRpb24gdG8gRmln dXJlIDQsIGFzIHRoZSBjb25uZWN0aW9ucyBhcmUgdW5jbGVhciwgZS5nLiBhcmUgdGhlc2UgZGF0 YSBvciBzaWduYWxpbmcgbGlua3M/IERvIHdlIG5lZWQgbW9yZSBjb21wb25lbnRzIHN1Y2ggYXMg QUxUTyBzZXJ2ZXIgYW5kIGNvbnRlbnQgb3JpZ2lucz8NCiAgICAgICAgICAgICAgICAgIC0tLS0t LU9LLCBXZSB3aWxsIHBlcmZlY3QgaXQgaW4gbmV4dCB2ZXJzaW9uLg0KDQoNCjcpICAgICAgSW4g U2VjdGlvbiA3LCB0ZXN0IHNldHRpbmdzIGZvciBkaXN0cmlidXRpb24gcGxhdGZvcm0gZm9yIENQ IGlzIG1pc3NpbmcsIGUuZy4gaG93IG1hbnkgYW5kIHdoaWNoIHR5cGVzIG9mIHNlcnZlcnMgYXJl IHVzZWQsIHdoaWNoIENQcyBhcmUgdGVzdGVkPw0KICAgICAgICAgICAgICAgICAgIC0tLS0tLU9L LCBXZSB3aWxsIGFkZCB0ZXN0IHNldHRpbmcgaW4gbmV4dCB2ZXJzaW9uLg0KDQoNCjgpICAgICAg SW4gU2VjdGlvbiA4LCBJIHRoaW5rIHdloa9kIGJldHRlciB0byBnaXZlIGEgY29udGVudCBkaXN0 cmlidXRpb24gcGVyZm9ybWFuY2UgZXhhbXBsZSwgZS5nLiBob3cgbG9uZyB0byBjb21wbGV0ZSBh IGNvbnRlbnQgZGlzdHJpYnV0aW9uLCB0byBob3cgbWFueSB1c2VycywgaG93IGFib3V0IHRoZSBi YW5kd2lkdGggdXNhZ2U/DQogICAgICAgICAgICAgICAgICAgLS0tLS0tT0ssIFdlIHdpbGwgcGVy ZmVjdCBpdCBpbiBuZXh0IHZlcnNpb24uDQoNCg0Kt6K8/sjLOiBkZWNhZGUtYm91bmNlc0BpZXRm Lm9yZyBbbWFpbHRvOmRlY2FkZS1ib3VuY2VzQGlldGYub3JnXSC0+rHtIENoZW54aWFvaHVpDQq3 osvNyrG85DogMjAxMsTqMdTCMTHI1SA5OjEzDQrK1bz+yMs6IGRlY2FkZUBpZXRmLm9yZw0Ks63L zTogTGlqaWFuZyBDaGVuOyBXZWloYW55dTsgSG9uZ3FpYW5nIExpdTsgQW5keSBIdWFuZyhaaGln YW5nKQ0K1vfM4jogW2RlY2FkZV0gtPC4tDogV0cgcmV2aWV3IG9mIGRyYWZ0LWlldGYtZGVjYWRl LWludGVncmF0aW9uLWV4YW1wbGUtMDINCg0KVGhhbmtzIGZvciB5b3VyIGNvbW1lbnRzLg0KDQoN Cg0KoaQgICAgICAgICBJIHRoaW5rIHRoZSBkb2N1bWVudCBjb3VsZCBnZW5lcmFsbHkgYmUgaW1w cm92ZWQgaWYgdGhlIGZvbGxvd2luZyBpbmZvcm1hdGlvbiB3ZXJlIGFkZGVkIChvciBleHBhbmRl ZCk6DQoNCg0KDQpvICAgU29tZSBtb3JlIGRldGFpbHMgb2YgdGhlIGFjdHVhbCBwcm90b2NvbHMg dXNlZCBpbiB0aGUgZGlmZmVyZW50IGludGVncmF0aW9uIHNjZW5hcmlvcyBzaG91bGQgYmUgZ2l2 ZW4uICBGb3IgZXhhbXBsZSwgd2hhdCB3ZXJlIHRoZSB1bmRlcmx5aW5nIHByb3RvY29scyBmb3Ig dGhlIKGwUDJQIExpdmVTdHJlYW1pbmcgQ2xpZW50IChQMlBMUymhsT8gICBBcyBhbiBleGFtcGxl LCBIVFRQL1RDUCBhcmUgdGhlIHByb3RvY29scyB1c2VkIGZvciB3ZWIgYnJvd3NpbmcuICBXaGF0 IHdlcmUgdGhlIHByb3RvY29scyBmb3IgUDJQTFM/ICBBbHNvIHNvbWUgZGV0YWlscyBmb3IgdGhl IHByb3RvY29scyBzaG91bGQgYmUgZ2l2ZW4gZXZlbiBmb3IgdGhlIKGwQml0VG9ycmVudKGxIGV4 YW1wbGUuICBBcyBub3QgYWxsIHJlYWRlcnMgd2lsbCBoYXZlIGtub3dsZWRnZSBvZiBob3cgQml0 VG9ycmVudCB3b3Jrcy4NCg0KDQpvICAgU29tZSBtb3JlIGRldGFpbHMgb2YgdGhlIGZpbGUvb2Jq ZWN0IG5hbWluZyBzY2hlbWUgdXNlZCBpbiB0aGUgZGlmZmVyZW50IGludGVncmF0aW9uIHNjZW5h cmlvcyBzaG91bGQgYmUgZ2l2ZW4uICBUaGlzIGlzIGEgY3JpdGljYWwgcGFydCBvZiBERUNBREUg YW5kIHRoZSBhcHByb2FjaGVkIHVzZWQgaW4gdGhlIGV4cGVyaW1lbnRzIGZvciBuYW1pbmcgbXVz dCBiZSBnaXZlbiBmb3IgYSBjb21wbGV0ZSB1bmRlcnN0YW5kaW5nIG9mIHdoYXQgd2FzIGRvbmUu DQoNCg0KbyAgIEluIHRoZSBJbnRybyAoYW5kIGVsc2V3aGVyZSkgdGhlcmUgbmVlZHMgdG8gYmUg c29tZSBjbGVhciByZWZlcmVuY2VzIHRvIERFQ0FERSBXRyBkb2N1bWVudHMgc3VjaCBhcyB0aGUg UHJvYmxlbSBTdGF0ZW1lbnQsIFJlcXVpcmVtZW50cyBvciBBcmNoaXRlY3R1cmUgKGFuZCB0aGUg YXNzb2NpYXRlZCBjb25jZXB0cyBkZWZpbmVkIGluIHRob3NlIGRvY3VtZW50cykuICBOb3RlIHRo YXQgdGhlcmUgY2FuIGJlIGRldmlhdGlvbnMgZnJvbSB0aGUgY29uY2VwdHMgZGVmaW5lZCBpbiB0 aGUgREVDQURFIFdHIGRvY3VtZW50cywgYnV0IHRoZXNlIG5lZWQgdG8gYmUgY2xlYXJseSBleHBs YWluZWQuDQoNCg0KDQqhpCAgICAgICAgIFNvbWUgZGV0YWlsZWQgY29tbWVudHMgb24gc3BlY2lm aWMgc2VjdGlvbnM6DQoNCm8gICBUaGUgQWJzdHJhY3QgaXMgYSBiaXQgZGV0YWlsZWQgYW5kIGl0 IGlzIGhhcmQgdG8gdW5kZXJzdGFuZC4gIEZvciBleGFtcGxlIHRoZXJlIHNob3VsZCBub3QgYmUg YSBsaXN0IChwb2ludHMgMS02KSBpbiBhbiBhYnN0cmFjdC4NCg0KDQpvICAgSW4gc2VjdGlvbiAy LjkgKFJlbW90ZSBDb250cm9sbGVyKSwgSSBkaWQgbm90IHVuZGVyc3RhbmQgd2hhdCChsGEgbWFq b3Igb3BlcmF0aW5nIHBsYXRmb3JtobEgbWVhbnQ/DQoNCg0KbyAgIEkgZGlkIG5vdCB1bmRlcnN0 YW5kIHRoZSChsGxpbWl0ZWQgY29ubmVjdGlvbiBzbG90obEgaXNzdWUgKHNlYy4gNC4yLjEpLiAg TXkgdW5kZXJzdGFuZGluZyBpcyB0aGF0IGEgREVDQURFIGNsaWVudCB3aWxsIGhhdmUgYW4gYXNz b2NpYXRpb24gd2l0aCBhIGdpdmVuIERFQ0FERSBzZXJ2ZXIsIGFuZCBub3QgZXZlcnkgb3RoZXIg cG9zc2libGUgc2VydmVyLiAgSXMgdGhpcyB0aGUgYXNzdW1wdGlvbiB0aGF0IHdhcyB1c2VkIGlu IHRoZSBpbnRlZ3JhdGlvbj8NCg0KDQoNCm8gICBFZGl0b3JpYWw6IFRoZSB3b3JkIERFQ0FERSBp cyBzcGVsbGVkIGluY29ycmVjdGx5IGluIEZpZ3VyZSAyIGFuZCAzLg0KDQoNCm8gICBJIGRpZCBu b3QgdW5kZXJzdGFuZCB0aGUgcmVsYXRpb24gYmV0d2VlbiBhIERFQ0FERSBjbGllbnQgYW5kIHNl cnZlciBpbiB0aGUgQUxUTyArIERFQ0FERSBpbnRlZ3JhdGlvbiAoc2VjdGlvbiA2KT8gIERvZXMg QUxUTyBnZXQgaW52b2tlZCBmb3IgYm90aCBQVVQgYW5kIEdFVCBmcm9tIGEgREVDQURFIGNsaWVu dD8gIE9yIGlzIGl0IG9ubHkgZm9yIGEgR0VUPw0KDQqh7CAgU2ltaWxhcmx5LCBJIGRpZCBub3Qg dW5kZXJzdGFuZCB0aGUgUGVyZm9ybWFuY2UgQW5hbHlzaXMgb2YgdGhlIEFMVE8rREVDQURFIFBl cmZvcm1hbmNlIEFuYWx5c2lzIChzZWN0aW9uIDguMi4zKS4NCg0KDQoNCm8gICBTaG91bGQgYmV0 dGVyIGRlZmluZSB3aGF0IGEgobBzbWFsbCBpbnN0YW5jZaGxIGlzIGluIHRoZSBBbWF6b24gRUMy IGZyYW1ld29yayAoc2VjdGlvbiA3LjIuMSkNCg0KDQoNCm8gICBBIHNob3J0IENvbmNsdXNpb24g c2VjdGlvbiBzaG91bGQgYmUgYWRkZWQgdG8gdGhlIGRvY3VtZW50IGJyaWVmbHkgc3VtbWFyaXpp bmcgdGhlIGxlc3NvbnMgbGVhcm5lZCBhbmQgc29tZSBzdWdnZXN0aW9ucyBmb3IgdGhlIERFQ0FE RSBkZXNpZ24uICBBcyByaWdodCBub3cgdGhlIGNvbmNsdXNpb25zIGFyZSBzcHJlYWQgb3ZlciBz ZXZlcmFsIHNlY3Rpb25zLg0KDQoNCg0KbyAgIFRoZSBTZWN1cml0eSBzZWN0aW9uIChzZWMuIDkp IHNob3VsZCBub3QgYmUgZW1wdHkgYXMgdGhlcmUgbXVzdCBoYXZlIGJlZW4gc29tZSBzZWN1cml0 eSByZWxhdGVkIGFzc3VtcHRpb25zIGluIHRoZSBpbnRlZ3JhdGlvbi4gIEZvciBleGFtcGxlLCB3 YXMgYW55IERFQ0FERSBjbGllbnQgYWJsZSB0byByZWFkIGZyb20gYW55IERFQ0FERSBzZXJ2ZXIg d2l0aG91dCBhdXRoZW50aWNhdGlvbj8gIFllcyBvciBObz8gIEVpdGhlciB3YXkgdGhpcyBzaG91 bGQgYmUgZGVzY3JpYmVkLiAgKEluIHNlY3Rpb24gNS4zLCBmb3IgZXhhbXBsZSwgdGhlcmUgd2Fz IGEgcmVmZXJlbmNlIHRvIGFuIKGwYXV0aG9yaXphdGlvbiB0b2tlbqGxKS4NCg0KICAgICAgICAg LS0tLWdvb2QgYWR2aWNlLCB3ZSB3aWxsICBwZXJmZWN0IHRoZW0gbmV4dCB2ZXJzaW9uLg0KDQpG b3IgdGhlIGNvbW1lbnQgZnJvbSBOaW5nIFpvbmcsIHN1cmUsIHRoZXJlIGFyZSBzb21lIHByb2Js ZW0gYXMgZm9sbG93aW5nLCB3ZSB3aWxsIGFkZHJlc3MgdGhlbSBuZXh0IHZlcnNpb24gYWxzby4N CkkgYWxzbyBoYXZlIGZvbGxvd2luZyBjb21tZW50cyAmIHN1Z2dlc3Rpb25zOg0KDQo5KSAgICAg IEluIFNlY3Rpb24gMSChsEludHJvZHVjdGlvbqGxLCBpdCBzZWVtcyB0aGF0IG9ubHkgUDJQIGxp dmUgc3RyZWFtaW5nIGlzIG1lbnRpb25lZC4gV2Ugc2hvdWxkIGFsc28gbWVudGlvbiBmaWxlIHNo YXJpbmcgYXBwbGljYXRpb24gKGUuZy4gVnV6ZSkgYW5kIENvbnRlbnQgRGlzdHJpYnV0aW9uIFBs YXRmb3JtIGZvciBDUDsNCg0KMTApICAgSW4gU2VjdGlvbiAyLCChsERFQ0FERSBNb2R1bGWhsSBh bmQgobBERUNBREUgUGx1Z2luobEgc2hvdWxkIGJlIHRoZSBzYW1lLiBXZSBzaG91bGQgbWVyZ2Ug dGhlc2UgdHdvIGRlZmluaXRpb24gYW5kIHVzZSBvbmUgdGVybSBpbiB0aGUgd2hvbGUgZHJhZnQu DQoNCjExKSAgIEluIFNlY3Rpb24gMiwgobBERUNBREUtRW5hYmxlZCBWdXplobEgaXMgY292ZXJl ZCBieSChsERFQ0FERSBDbGllbnShsS4gSW4gdGhlIHdob2xlIGRyYWZ0LCB3ZSBjb3VsZCBlaXRo ZXIgdXNlIHR3byB0ZXJtcyCoQyChsERFQ0FERS1lbmFibGVkIFZ1emWhsSAmIKGwREVDQURFLWVu YWJsZSBQUExTobEsIG9yIGp1c3QgdXNlIKGwREVDQURFIENsaWVudKGxIGZvciBnZW5lcmFsIHB1 cnBvc2UuDQoNCjEyKSAgIEkgdGhpbmsgU2VjdGlvbiA2IG5lZWRzIG1vcmUgZWRpdG9yaWFsIHdv cmsuDQoNCjEzKSAgIEluIFNlY3Rpb24gNiwgSSB0aGluayB3ZaGvZCBiZXR0ZXIgdG8gY2FsbCBp dCChsGNvbnRlbnQgZGlzdHJpYnV0aW9uIHBsYXRmb3JtIGZvciBDUKGxIHJhdGhlciB0aGFuIKGw QUxUTytERUNBREUgcGxhdGZvcm2hsSwgYXMgd2UgZG9uoa90IGZvY3VzIG9uIGRlc2NyaWJpbmcg YW4gQUxUTytERUNBREUgYXJjaGl0ZWN0dXJlIGluIHRoaXMgZHJhZnQuDQoNCjE0KSAgIEluIFNl Y3Rpb24gNiwgd2Whr2QgYmV0dGVyIHRvIHVzZSBERUNBREUgc2VydmljZSBwcm92aWRlciByYXRo ZXIgdGhhbiBJU1AgaW4gRmlndXJlIDQuIFdlIGFsc28gbmVlZCBtb3JlIGV4cGxhbmF0aW9uIHRv IEZpZ3VyZSA0LCBhcyB0aGUgY29ubmVjdGlvbnMgYXJlIHVuY2xlYXIsIGUuZy4gYXJlIHRoZXNl IGRhdGEgb3Igc2lnbmFsaW5nIGxpbmtzPyBEbyB3ZSBuZWVkIG1vcmUgY29tcG9uZW50cyBzdWNo IGFzIEFMVE8gc2VydmVyIGFuZCBjb250ZW50IG9yaWdpbnM/DQoNCjE1KSAgIEluIFNlY3Rpb24g NywgdGVzdCBzZXR0aW5ncyBmb3IgZGlzdHJpYnV0aW9uIHBsYXRmb3JtIGZvciBDUCBpcyBtaXNz aW5nLCBlLmcuIGhvdyBtYW55IGFuZCB3aGljaCB0eXBlcyBvZiBzZXJ2ZXJzIGFyZSB1c2VkLCB3 aGljaCBDUHMgYXJlIHRlc3RlZD8NCg0KMTYpICAgSW4gU2VjdGlvbiA4LCBJIHRoaW5rIHdloa9k IGJldHRlciB0byBnaXZlIGEgY29udGVudCBkaXN0cmlidXRpb24gcGVyZm9ybWFuY2UgZXhhbXBs ZSwgZS5nLiBob3cgbG9uZyB0byBjb21wbGV0ZSBhIGNvbnRlbnQgZGlzdHJpYnV0aW9uLCB0byBo b3cgbWFueSB1c2VycywgaG93IGFib3V0IHRoZSBiYW5kd2lkdGggdXNhZ2U/DQoNCg0KRnJvbTog U29uZ2hhaWJpbg0KU2VudDogRnJpZGF5LCBEZWNlbWJlciAyMywgMjAxMSA1OjA2IFBNDQpUbzog J1JhaG1hbiwgQWtiYXInOyBkZWNhZGVAaWV0Zi5vcmcNClN1YmplY3Q6IFJFOiBXRyByZXZpZXcg b2YgZHJhZnQtaWV0Zi1kZWNhZGUtaW50ZWdyYXRpb24tZXhhbXBsZS0wMg0KDQpIaSBBa2JhciwN Cg0KVGhhbmtzIGZvciB0aGUgY29tbWVudHMuIFRoZSBhdXRob3JzIHBsZWFzZSBkaXNjdXNzL2Fk ZHJlc3MgdGhlc2UgY29tbWVudHMuDQoNCkJSLA0KLUhhaWJpbg0KDQpGcm9tOiBkZWNhZGUtYm91 bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmRlY2FkZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYg T2YgUmFobWFuLCBBa2Jhcg0KU2VudDogVHVlc2RheSwgTm92ZW1iZXIgMjksIDIwMTEgMzoxNyBQ TQ0KVG86IGRlY2FkZUBpZXRmLm9yZw0KU3ViamVjdDogW2RlY2FkZV0gV0cgcmV2aWV3IG9mIGRy YWZ0LWlldGYtZGVjYWRlLWludGVncmF0aW9uLWV4YW1wbGUtMDINCg0KSGksDQoNCg0KQXMgcGVy IHRoZSByZXF1ZXN0IG9mIHRoZSBERUNBREUgY2hhaXJzIGluIElFVEYgODIsIEkgZGlkIGEgcmV2 aWV3IG9mIHRoZSChsEludGVncmF0aW9uIEV4YW1wbGVzIG9mIERFQ0FERSBTeXN0ZW2hsSAoZHJh ZnQtaWV0Zi1kZWNhZGUtaW50ZWdyYXRpb24tZXhhbXBsZS0wMikgYW5kIGhhdmUgdGhlIGZvbGxv d2luZyBjb21tZW50czoNCg0KDQqhpCAgICAgICAgIE92ZXJhbGwsIEkgZm91bmQgdGhlIGRvY3Vt ZW50IHZlcnkgdXNlZnVsIGluIHByb3ZpZGluZyBleGNlbGxlbnQgaW5zaWdodHMgaW50byBob3cg REVDQURFIGNvdWxkIGJlIHVzZWQgaW4gYSByZWFsIG5ldHdvcmsuICBBbHNvLCBJIHRvb2sgaXQg YXMgYSBnb29kIGV4YW1wbGUgb2YgobBydW5uaW5nIGNvZGWhsSBmb3IgREVDQURFLiAgVGhhbmtz IGZvciB0aGUgZ29vZCB3b3JrIQ0KDQoNCqGkICAgICAgICAgSSB0aGluayB0aGUgZG9jdW1lbnQg Y291bGQgZ2VuZXJhbGx5IGJlIGltcHJvdmVkIGlmIHRoZSBmb2xsb3dpbmcgaW5mb3JtYXRpb24g d2VyZSBhZGRlZCAob3IgZXhwYW5kZWQpOg0KDQoNCg0KbyAgIFNvbWUgbW9yZSBkZXRhaWxzIG9m IHRoZSBhY3R1YWwgcHJvdG9jb2xzIHVzZWQgaW4gdGhlIGRpZmZlcmVudCBpbnRlZ3JhdGlvbiBz Y2VuYXJpb3Mgc2hvdWxkIGJlIGdpdmVuLiAgRm9yIGV4YW1wbGUsIHdoYXQgd2VyZSB0aGUgdW5k ZXJseWluZyBwcm90b2NvbHMgZm9yIHRoZSChsFAyUCBMaXZlU3RyZWFtaW5nIENsaWVudCAoUDJQ TFMpobE/ICAgQXMgYW4gZXhhbXBsZSwgSFRUUC9UQ1AgYXJlIHRoZSBwcm90b2NvbHMgdXNlZCBm b3Igd2ViIGJyb3dzaW5nLiAgV2hhdCB3ZXJlIHRoZSBwcm90b2NvbHMgZm9yIFAyUExTPyAgQWxz byBzb21lIGRldGFpbHMgZm9yIHRoZSBwcm90b2NvbHMgc2hvdWxkIGJlIGdpdmVuIGV2ZW4gZm9y IHRoZSChsEJpdFRvcnJlbnShsSBleGFtcGxlLiAgQXMgbm90IGFsbCByZWFkZXJzIHdpbGwgaGF2 ZSBrbm93bGVkZ2Ugb2YgaG93IEJpdFRvcnJlbnQgd29ya3MuDQoNCg0KbyAgIFNvbWUgbW9yZSBk ZXRhaWxzIG9mIHRoZSBmaWxlL29iamVjdCBuYW1pbmcgc2NoZW1lIHVzZWQgaW4gdGhlIGRpZmZl cmVudCBpbnRlZ3JhdGlvbiBzY2VuYXJpb3Mgc2hvdWxkIGJlIGdpdmVuLiAgVGhpcyBpcyBhIGNy aXRpY2FsIHBhcnQgb2YgREVDQURFIGFuZCB0aGUgYXBwcm9hY2hlZCB1c2VkIGluIHRoZSBleHBl cmltZW50cyBmb3IgbmFtaW5nIG11c3QgYmUgZ2l2ZW4gZm9yIGEgY29tcGxldGUgdW5kZXJzdGFu ZGluZyBvZiB3aGF0IHdhcyBkb25lLg0KDQoNCm8gICBJbiB0aGUgSW50cm8gKGFuZCBlbHNld2hl cmUpIHRoZXJlIG5lZWRzIHRvIGJlIHNvbWUgY2xlYXIgcmVmZXJlbmNlcyB0byBERUNBREUgV0cg ZG9jdW1lbnRzIHN1Y2ggYXMgdGhlIFByb2JsZW0gU3RhdGVtZW50LCBSZXF1aXJlbWVudHMgb3Ig QXJjaGl0ZWN0dXJlIChhbmQgdGhlIGFzc29jaWF0ZWQgY29uY2VwdHMgZGVmaW5lZCBpbiB0aG9z ZSBkb2N1bWVudHMpLiAgTm90ZSB0aGF0IHRoZXJlIGNhbiBiZSBkZXZpYXRpb25zIGZyb20gdGhl IGNvbmNlcHRzIGRlZmluZWQgaW4gdGhlIERFQ0FERSBXRyBkb2N1bWVudHMsIGJ1dCB0aGVzZSBu ZWVkIHRvIGJlIGNsZWFybHkgZXhwbGFpbmVkLg0KDQoNCg0KDQqhpCAgICAgICAgIFNvbWUgZGV0 YWlsZWQgY29tbWVudHMgb24gc3BlY2lmaWMgc2VjdGlvbnM6DQoNCm8gICBUaGUgQWJzdHJhY3Qg aXMgYSBiaXQgZGV0YWlsZWQgYW5kIGl0IGlzIGhhcmQgdG8gdW5kZXJzdGFuZC4gIEZvciBleGFt cGxlIHRoZXJlIHNob3VsZCBub3QgYmUgYSBsaXN0IChwb2ludHMgMS02KSBpbiBhbiBhYnN0cmFj dC4NCg0KDQpvICAgSW4gc2VjdGlvbiAyLjkgKFJlbW90ZSBDb250cm9sbGVyKSwgSSBkaWQgbm90 IHVuZGVyc3RhbmQgd2hhdCChsGEgbWFqb3Igb3BlcmF0aW5nIHBsYXRmb3JtobEgbWVhbnQ/DQoN Cg0KbyAgIEkgZGlkIG5vdCB1bmRlcnN0YW5kIHRoZSChsGxpbWl0ZWQgY29ubmVjdGlvbiBzbG90 obEgaXNzdWUgKHNlYy4gNC4yLjEpLiAgTXkgdW5kZXJzdGFuZGluZyBpcyB0aGF0IGEgREVDQURF IGNsaWVudCB3aWxsIGhhdmUgYW4gYXNzb2NpYXRpb24gd2l0aCBhIGdpdmVuIERFQ0FERSBzZXJ2 ZXIsIGFuZCBub3QgZXZlcnkgb3RoZXIgcG9zc2libGUgc2VydmVyLiAgSXMgdGhpcyB0aGUgYXNz dW1wdGlvbiB0aGF0IHdhcyB1c2VkIGluIHRoZSBpbnRlZ3JhdGlvbj8NCg0KDQoNCm8gICBFZGl0 b3JpYWw6IFRoZSB3b3JkIERFQ0FERSBpcyBzcGVsbGVkIGluY29ycmVjdGx5IGluIEZpZ3VyZSAy IGFuZCAzLg0KDQoNCm8gICBJIGRpZCBub3QgdW5kZXJzdGFuZCB0aGUgcmVsYXRpb24gYmV0d2Vl biBhIERFQ0FERSBjbGllbnQgYW5kIHNlcnZlciBpbiB0aGUgQUxUTyArIERFQ0FERSBpbnRlZ3Jh dGlvbiAoc2VjdGlvbiA2KT8gIERvZXMgQUxUTyBnZXQgaW52b2tlZCBmb3IgYm90aCBQVVQgYW5k IEdFVCBmcm9tIGEgREVDQURFIGNsaWVudD8gIE9yIGlzIGl0IG9ubHkgZm9yIGEgR0VUPw0KDQqh 7CAgU2ltaWxhcmx5LCBJIGRpZCBub3QgdW5kZXJzdGFuZCB0aGUgUGVyZm9ybWFuY2UgQW5hbHlz aXMgb2YgdGhlIEFMVE8rREVDQURFIFBlcmZvcm1hbmNlIEFuYWx5c2lzIChzZWN0aW9uIDguMi4z KS4NCg0KDQoNCm8gICBTaG91bGQgYmV0dGVyIGRlZmluZSB3aGF0IGEgobBzbWFsbCBpbnN0YW5j ZaGxIGlzIGluIHRoZSBBbWF6b24gRUMyIGZyYW1ld29yayAoc2VjdGlvbiA3LjIuMSkNCg0KDQoN Cm8gICBBIHNob3J0IENvbmNsdXNpb24gc2VjdGlvbiBzaG91bGQgYmUgYWRkZWQgdG8gdGhlIGRv Y3VtZW50IGJyaWVmbHkgc3VtbWFyaXppbmcgdGhlIGxlc3NvbnMgbGVhcm5lZCBhbmQgc29tZSBz dWdnZXN0aW9ucyBmb3IgdGhlIERFQ0FERSBkZXNpZ24uICBBcyByaWdodCBub3cgdGhlIGNvbmNs dXNpb25zIGFyZSBzcHJlYWQgb3ZlciBzZXZlcmFsIHNlY3Rpb25zLg0KDQoNCg0KbyAgIFRoZSBT ZWN1cml0eSBzZWN0aW9uIChzZWMuIDkpIHNob3VsZCBub3QgYmUgZW1wdHkgYXMgdGhlcmUgbXVz dCBoYXZlIGJlZW4gc29tZSBzZWN1cml0eSByZWxhdGVkIGFzc3VtcHRpb25zIGluIHRoZSBpbnRl Z3JhdGlvbi4gIEZvciBleGFtcGxlLCB3YXMgYW55IERFQ0FERSBjbGllbnQgYWJsZSB0byByZWFk IGZyb20gYW55IERFQ0FERSBzZXJ2ZXIgd2l0aG91dCBhdXRoZW50aWNhdGlvbj8gIFllcyBvciBO bz8gIEVpdGhlciB3YXkgdGhpcyBzaG91bGQgYmUgZGVzY3JpYmVkLiAgKEluIHNlY3Rpb24gNS4z LCBmb3IgZXhhbXBsZSwgdGhlcmUgd2FzIGEgcmVmZXJlbmNlIHRvIGFuIKGwYXV0aG9yaXphdGlv biB0b2tlbqGxKS4NCg0KDQpUaGF0oa9zIGFsbC4NCg0KDQpBa2Jhcg0K --Boundary_(ID_LrfiUpywoAFd+4Us1x6Qhw) Content-type: text/html; charset=gb2312 Content-transfer-encoding: quoted-printable

For the= questions, I will explain as following:

 

=A1=A4         I think the document co= uld generally be improved if the following information were added (or expan= ded):

 =

o   Some more details of th= e actual protocols used in the different integration scenarios should be gi= ven.  For example, what were the underlying protocols for the =A1=B0P2= P LiveStreaming Client (P2PLS)=A1=B1?   As an example, HTTP/TCP are the protocols used for web browsing.  What were the prot= ocols for P2PLS?  Also some details for the protocols should be given = even for the =A1=B0BitTorrent=A1=B1 example.  As not all readers will = have knowledge of how BitTorrent works.

         ------HTTP is the protocol used for P2PLS. Some details for the pr= otocol like =A1=B0BitTorrent=A1=B1 will be given in next version.

 

o   Some more details of th= e file/object naming scheme used in the different integration scenarios sho= uld be given.  This is a critical part of DECADE and the approached us= ed in the experiments for naming must be given for a complete understanding of what was done.

     &= nbsp;           &nbs= p;             =        &nb= sp; ------We will give them in next version.<= /p>

&n= bsp;

o   In the Intro (and elsew= here) there needs to be some clear references to DECADE WG documents such a= s the Problem Statement, Requirements or Architecture (and the associated c= oncepts defined in those documents).  Note that there can be deviations from the concepts defined in the DECADE = WG documents, but these need to be clearly explained.   &nbs= p;    

    =             &nb= sp;       ------We will explain them in next version.

 =

=A1=A4         Some detailed comments = on specific sections:

o   The Abstract is a bit d= etailed and it is hard to understand.  For example there should not be= a list (points 1-6) in an abstract.

     &= nbsp;           &nbs= p;            &= nbsp;      ------Good advice, We will perfect the =A1=B0Abstract=A1=B1 in next v= ersion

 

o   In section 2.9 (Remote = Controller), I did not understand what =A1=B0a major operating platform=A1= =B1 meant?

     &= nbsp;           &nbs= p;             =      ------=A1=B0a m= ajor operating platform=A1=B1 means: in the trail, we always use =A1=B0Remo= te Controller=A1=B1 to control Vuze server and Vuze clients,

 &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;        We look Remote Controller as a= operating platform to start/stop a trail, and collect debug information.

 

o   I did not understand th= e =A1=B0limited connection slot=A1=B1 issue (sec. 4.2.1).  My understa= nding is that a DECADE client will have an association with a given DECADE = server, and not every other possible server.  Is this the assumption that was used in the integration?

------Yes, It is an assumpti= on under the condition that if only one DECADE Server in storage network.

 

o   Editorial: The word DEC= ADE is spelled incorrectly in Figure 2 and 3.

     &= nbsp;           &nbs= p;            &= nbsp;     ------ We will perfect the =A1=B0Abstract=A1=B1 in next version<= /o:p>

 

o   I did not understand th= e relation between a DECADE client and server in the ALTO + DECADE inte= gration (section 6)?  Does ALTO get invoked for both PUT and GET from = a DECADE client?  Or is it only for a GET?

------In principle, ALTO can= service both PUT and GET.

 

<= span style=3D"mso-list:Ignore">=A1=EC  Similarly, I did not un= derstand the Performance Analysis of the ALTO+DECADE Performance Analys= is (section 8.2.3).

    =             &nb= sp;   ------ The Performance Analysis present the using rate of bandwidth i= n each DECADE Server and total online users can be support in One

=             &nb= sp;            =     DECADE Server.

o   Should better define wh= at a =A1=B0small instance=A1=B1 is in the Amazon EC2 framework (section 7.2= .1)

    =             &nb= sp;    ------We will define it= in next version.

 =

o   A short Conclusion sect= ion should be added to the document briefly summarizing the lessons learned= and some suggestions for the DECADE design.  As right now the conclus= ions are spread over several sections.

    =              &n= bsp;   ------We will add in ne= xt version.

 =

o   The Security section (s= ec. 9) should not be empty as there must have been some security related as= sumptions in the integration.  For example, was any DECADE client able= to read from any DECADE server without authentication?  Yes or No?  Either way this should be described= .  (In section 5.3, for example, there was a reference to an =A1=B0aut= horization token=A1=B1).

    =             &n= bsp;   ------No, authenticatio= n is needed, We will add it in next version.

 

 

I also have following comments = & suggestions:

1= )   &= nbsp;  In Section 1 =A1=B0Intr= oduction=A1=B1, it seems that only P2P live streaming is mentioned. We shou= ld also mention file sharing application (e.g. Vuze) and Content Distributi= on Platform for CP;

------We will perfect it= in next version.

 

2= )   &= nbsp;  In Section 2, =A1=B0DEC= ADE Module=A1=B1 and =A1=B0DECADE Plugin=A1=B1 should be the same. We shoul= d merge these two definition and use one term in the whole draft.

         =   ------OK, We will perfect it in next v= ersion.

 

3= )   &= nbsp;  In Section 2, =A1=B0DEC= ADE-Enabled Vuze=A1=B1 is covered by =A1=B0DECADE Client=A1=B1. In the whol= e draft, we could either use two terms =A8C =A1=B0DECADE-enabled Vuze=A1=B1= & =A1=B0DECADE-enable PPLS=A1=B1, or just use =A1=B0DECADE Client=A1= =B1 for general purpose.

         =  ------OK, We will perfect it in next v= ersion.

 

4= )   &= nbsp;  I think Section 6 needs= more editorial work.

        =            ------OK, We will perfect it in next version.

 

5= )   &= nbsp;  In Section 6, I think w= e=A1=AFd better to call it =A1=B0content distribution platform for CP=A1=B1= rather than =A1=B0ALTO+DECADE platform=A1=B1, as we don=A1=AFt focus o= n describing an ALTO+DECADE architecture in this draft.

        =            ------OK, We will perfect it in next version.

 

6= )   &= nbsp;  In Section 6, we=A1=AFd= better to use DECADE service provider rather than ISP in Figure 4. We also= need more explanation to Figure 4, as the connections are unclear, e.g. ar= e these data or signaling links? Do we need more components such as ALTO server and content origins?

        =           ------OK, We will perfect it in next version.

 

7= )   &= nbsp;  In Section 7, test sett= ings for distribution platform for CP is missing, e.g. how many and which t= ypes of servers are used, which CPs are tested?

        =            ------OK, We will add test setting in next version.

 

8= )   &= nbsp;  In Section 8, I think w= e=A1=AFd better to give a content distribution performance example, e.g. ho= w long to complete a content distribution, to how many users, how about the= bandwidth usage?

        =            ------OK, We will perfect it in next version.

 

 

=B7=A2=BC=FE=C8=CB: decade-= bounces@ietf.org [mailto:decade-bounces@ietf.org] =B4=FA= =B1=ED Chenxiaohui
=B7=A2= =CB=CD=CA=B1=BC=E4: 2012=C4=EA1=D4=C211=C8=D5 9:13
=CA=D5=BC=FE=C8=CB: decade@ietf.org
=B3=AD=CB=CD: Lijiang Chen; Weihanyu; Hongqiang Liu; Andy Huang(Zhigang)
=D6=F7=CC=E2: [decade] =B4=F0=B8=B4: WG review of draft-iet= f-decade-integration-example-02

 

Thanks for your comments.

 

 

=A1=A4         I think the document co= uld generally be improved if the following information were added (or expan= ded):

 =

o   Some more details of th= e actual protocols used in the different integration scenarios should be gi= ven.  For example, what were the underlying protocols for the =A1=B0P2= P LiveStreaming Client (P2PLS)=A1=B1?   As an example, HTTP/TCP are the protocols used for web browsing.  What were the prot= ocols for P2PLS?  Also some details for the protocols should be given = even for the =A1=B0BitTorrent=A1=B1 example.  As not all readers will = have knowledge of how BitTorrent works.

 

o   Some more details of th= e file/object naming scheme used in the different integration scenarios sho= uld be given.  This is a critical part of DECADE and the approached us= ed in the experiments for naming must be given for a complete understanding of what was done.

 

o   In the Intro (and elsew= here) there needs to be some clear references to DECADE WG documents such a= s the Problem Statement, Requirements or Architecture (and the associated c= oncepts defined in those documents).  Note that there can be deviations from the concepts defined in the DECADE = WG documents, but these need to be clearly explained.   &nbs= p;    

 =

=A1=A4         Some detailed comments = on specific sections:

o   The Abstract is a bit d= etailed and it is hard to understand.  For example there should not be= a list (points 1-6) in an abstract.

 

o   In section 2.9 (Remote = Controller), I did not understand what =A1=B0a major operating platform=A1= =B1 meant?

 

o   I did not understand th= e =A1=B0limited connection slot=A1=B1 issue (sec. 4.2.1).  My understa= nding is that a DECADE client will have an association with a given DECADE = server, and not every other possible server.  Is this the assumption that was used in the integration?

 =

o   Editorial: The word DEC= ADE is spelled incorrectly in Figure 2 and 3.

 

o   I did not understand th= e relation between a DECADE client and server in the ALTO + DECADE inte= gration (section 6)?  Does ALTO get invoked for both PUT and GET from = a DECADE client?  Or is it only for a GET?

<= span style=3D"mso-list:Ignore">=A1=EC  Similarly, I did not un= derstand the Performance Analysis of the ALTO+DECADE Performance Analys= is (section 8.2.3).

 =

o   Should better define wh= at a =A1=B0small instance=A1=B1 is in the Amazon EC2 framework (section 7.2= .1)

 =

o   A short Conclusion sect= ion should be added to the document briefly summarizing the lessons learned= and some suggestions for the DECADE design.  As right now the conclus= ions are spread over several sections.

 =

o   The Security section (s= ec. 9) should not be empty as there must have been some security related as= sumptions in the integration.  For example, was any DECADE client able= to read from any DECADE server without authentication?  Yes or No?  Either way this should be described= .  (In section 5.3, for example, there was a reference to an =A1=B0aut= horization token=A1=B1).

 

      = ;   ----good advice, we w= ill  perfect them next version.

 

For the comment from Ning Zong, sure, there are some problem as follo= wing, we will address them next version also.

I also have following comments = & suggestions:

9= )   &= nbsp;  In Section 1 =A1=B0Intr= oduction=A1=B1, it seems that only P2P live streaming is mentioned. We shou= ld also mention file sharing application (e.g. Vuze) and Content Distributi= on Platform for CP;

1= 0)   In Section 2, =A1=B0DEC= ADE Module=A1=B1 and =A1=B0DECADE Plugin=A1=B1 should be the same. We shoul= d merge these two definition and use one term in the whole draft.

1= 1)   In Section 2, =A1=B0DEC= ADE-Enabled Vuze=A1=B1 is covered by =A1=B0DECADE Client=A1=B1. In the whol= e draft, we could either use two terms =A8C =A1=B0DECADE-enabled Vuze=A1=B1= & =A1=B0DECADE-enable PPLS=A1=B1, or just use =A1=B0DECADE Client=A1= =B1 for general purpose.

1= 2)   I think Section 6 needs= more editorial work.

1= 3)   In Section 6, I think w= e=A1=AFd better to call it =A1=B0content distribution platform for CP=A1=B1= rather than =A1=B0ALTO+DECADE platform=A1=B1, as we don=A1=AFt focus o= n describing an ALTO+DECADE architecture in this draft.

1= 4)   In Section 6, we=A1=AFd= better to use DECADE service provider rather than ISP in Figure 4. We also= need more explanation to Figure 4, as the connections are unclear, e.g. ar= e these data or signaling links? Do we need more components such as ALTO server and content origins?

1= 5)   In Section 7, test sett= ings for distribution platform for CP is missing, e.g. how many and which t= ypes of servers are used, which CPs are tested?

1= 6)   In Section 8, I think w= e=A1=AFd better to give a content distribution performance example, e.g. ho= w long to complete a content distribution, to how many users, how about the= bandwidth usage?

 

 

From: Songhaibin
Sent: Friday, December 23, 2011 5:06 PM
To: 'Rahman, Akbar'; decade@ietf.org
Subject: RE: WG review of draft-ietf-decade-integration-example-02

 

Hi Akbar,

 

Thanks for the comments. The authors please discuss/address these= comments.

 

BR,

-Haibin

 

From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.o= rg] On Behalf Of Rahman, Akbar
Sent: Tuesday, November 29, 2011 3:17 PM
To: decade@ietf.org
Subject: [decade] WG review of draft-ietf-decade-integration-example= -02

 

Hi,

 

 

As per the request of the DECAD= E chairs in IETF 82, I did a review of the =A1=B0Integration Examples of DE= CADE System=A1=B1 (draft-ietf-decade-integration-example-02) and have the f= ollowing comments:

 

=A1=A4         Overall, I found the do= cument very useful in providing excellent insights into how DECADE could be= used in a real network.  Also, I took it as a good example of =A1=B0r= unning code=A1=B1 for DECADE.  Thanks for the good work!

 

=A1=A4         I think the document co= uld generally be improved if the following information were added (or expan= ded):

 =

o   Some more details of th= e actual protocols used in the different integration scenarios should be gi= ven.  For example, what were the underlying protocols for the =A1=B0P2= P LiveStreaming Client (P2PLS)=A1=B1?   As an example, HTTP/TCP are the protocols used for web browsing.  What were the prot= ocols for P2PLS?  Also some details for the protocols should be given = even for the =A1=B0BitTorrent=A1=B1 example.  As not all readers will = have knowledge of how BitTorrent works.

 

o   Some more details of th= e file/object naming scheme used in the different integration scenarios sho= uld be given.  This is a critical part of DECADE and the approached us= ed in the experiments for naming must be given for a complete understanding of what was done.

 

o   In the Intro (and elsew= here) there needs to be some clear references to DECADE WG documents such a= s the Problem Statement, Requirements or Architecture (and the associated c= oncepts defined in those documents).  Note that there can be deviations from the concepts defined in the DECADE = WG documents, but these need to be clearly explained.

 

 =

=A1=A4         Some detailed comments = on specific sections:

o   The Abstract is a bit d= etailed and it is hard to understand.  For example there should not be= a list (points 1-6) in an abstract.

 

o   In section 2.9 (Remote = Controller), I did not understand what =A1=B0a major operating platform=A1= =B1 meant?

 

o   I did not understand th= e =A1=B0limited connection slot=A1=B1 issue (sec. 4.2.1).  My understa= nding is that a DECADE client will have an association with a given DECADE = server, and not every other possible server.  Is this the assumption that was used in the integration?

 =

o   Editorial: The word DEC= ADE is spelled incorrectly in Figure 2 and 3.

 

o   I did not understand th= e relation between a DECADE client and server in the ALTO + DECADE inte= gration (section 6)?  Does ALTO get invoked for both PUT and GET from = a DECADE client?  Or is it only for a GET?

<= span style=3D"mso-list:Ignore">=A1=EC  Similarly, I did not un= derstand the Performance Analysis of the ALTO+DECADE Performance Analys= is (section 8.2.3).

 =

o   Should better define wh= at a =A1=B0small instance=A1=B1 is in the Amazon EC2 framework (section 7.2= .1)

 =

o   A short Conclusion sect= ion should be added to the document briefly summarizing the lessons learned= and some suggestions for the DECADE design.  As right now the conclus= ions are spread over several sections.

 =

o   The Security section (s= ec. 9) should not be empty as there must have been some security related as= sumptions in the integration.  For example, was any DECADE client able= to read from any DECADE server without authentication?  Yes or No?  Either way this should be described= .  (In section 5.3, for example, there was a reference to an =A1=B0aut= horization token=A1=B1).

 

 

That=A1=AFs all.

 

 

Akbar

--Boundary_(ID_LrfiUpywoAFd+4Us1x6Qhw)-- From richard_woundy@cable.comcast.com Thu Jan 19 14:48:49 2012 Return-Path: X-Original-To: decade@ietfa.amsl.com Delivered-To: decade@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7707C21F8599; Thu, 19 Jan 2012 14:48:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.847 X-Spam-Level: X-Spam-Status: No, score=-104.847 tagged_above=-999 required=5 tests=[AWL=3.616, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 44DK7wkOGq3y; Thu, 19 Jan 2012 14:48:48 -0800 (PST) Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by ietfa.amsl.com (Postfix) with ESMTP id 8144C21F857D; Thu, 19 Jan 2012 14:48:48 -0800 (PST) Received: from ([24.40.56.116]) by pacdcimo01.cable.comcast.com with ESMTP id 5503620.149715022; Thu, 19 Jan 2012 17:48:31 -0500 Received: from PACDCEXMB05.cable.comcast.com ([fe80::a5b0:e5c4:df1b:2367]) by pacdcexhub03.cable.comcast.com ([fe80::5527:6d6b:29a7:f414%15]) with mapi id 14.01.0355.002; Thu, 19 Jan 2012 17:48:31 -0500 From: "Woundy, Richard" To: "'sm+ietf@elandsys.com'" , "'haibin.song@huawei.com'" Thread-Topic: Apps review of DECADE drafts Thread-Index: AQHM1vvR3jrrdOpRnEW5Txo4af4k9JYUSvbT Date: Thu, 19 Jan 2012 22:48:30 +0000 Message-ID: <1CA25301D2219F40B3AA37201F0EACD1150603A3@PACDCEXMB05.cable.comcast.com> In-Reply-To: <6.2.5.6.2.20120119142440.0634f7a8@elandnews.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [24.40.50.240] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "'decade@ietf.org'" , "'appsdir@ietf.org'" Subject: Re: [decade] Apps review of DECADE drafts X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2012 22:48:49 -0000 The document draft-ietf-decade-problem-statement-04 is held up due to a muc= h deeper review I undertook as document shepherd. I need to communicate a l= ot of changes and questions back to the authors as a result of this review.= I don't think this document is ready for your review at this time. -- Rich ----- Original Message ----- From: S Moonesamy [mailto:sm+ietf@elandsys.com] Sent: Thursday, January 19, 2012 05:41 PM=0A= To: Haibin Song ; Woundy, Richard Cc: appsdir@ietf.org ; decade@ietf.org Subject: RE: Apps review of DECADE drafts Dear DECADE WG Chairs, As I mentioned in a previous email, the Applications Area Directorate=20 has identified draft-ietf-decade-problem-statement-04 and=20 draft-ietf-decade-reqs-05 for review. Could you please tell me when=20 the revision of draft-ietf-decade-problem-statement-04 will be submitted? Regards, S. Moonesamy http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate From stpeter@stpeter.im Thu Jan 19 14:57:30 2012 Return-Path: X-Original-To: decade@ietfa.amsl.com Delivered-To: decade@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2BBD21F857A; Thu, 19 Jan 2012 14:57:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.656 X-Spam-Level: X-Spam-Status: No, score=-102.656 tagged_above=-999 required=5 tests=[AWL=-0.057, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aBymSZQjpzrU; Thu, 19 Jan 2012 14:57:30 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 086B821F84FA; Thu, 19 Jan 2012 14:57:29 -0800 (PST) Received: from dhcp-64-101-72-124.cisco.com (unknown [64.101.72.124]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 6486B40058; Thu, 19 Jan 2012 16:06:56 -0700 (MST) Message-ID: <4F189FD6.5020008@stpeter.im> Date: Thu, 19 Jan 2012 15:57:26 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: "Woundy, Richard" References: <1CA25301D2219F40B3AA37201F0EACD1150603A3@PACDCEXMB05.cable.comcast.com> In-Reply-To: <1CA25301D2219F40B3AA37201F0EACD1150603A3@PACDCEXMB05.cable.comcast.com> X-Enigmail-Version: 1.3.4 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "'decade@ietf.org'" , "'appsdir@ietf.org'" , "'sm+ietf@elandsys.com'" Subject: Re: [decade] [appsdir] Apps review of DECADE drafts X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2012 22:57:30 -0000 Rich, thanks for letting us know! On 1/19/12 3:48 PM, Woundy, Richard wrote: > The document draft-ietf-decade-problem-statement-04 is held up due to a much deeper review I undertook as document shepherd. I need to communicate a lot of changes and questions back to the authors as a result of this review. I don't think this document is ready for your review at this time. > > -- Rich > > > ----- Original Message ----- > From: S Moonesamy [mailto:sm+ietf@elandsys.com] > Sent: Thursday, January 19, 2012 05:41 PM > To: Haibin Song ; Woundy, Richard > Cc: appsdir@ietf.org ; decade@ietf.org > Subject: RE: Apps review of DECADE drafts > > Dear DECADE WG Chairs, > > As I mentioned in a previous email, the Applications Area Directorate > has identified draft-ietf-decade-problem-statement-04 and > draft-ietf-decade-reqs-05 for review. Could you please tell me when > the revision of draft-ietf-decade-problem-statement-04 will be submitted? > > Regards, > S. Moonesamy > > http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate > > _______________________________________________ > appsdir mailing list > appsdir@ietf.org > https://www.ietf.org/mailman/listinfo/appsdir -- Peter Saint-Andre https://stpeter.im/ From sm@elandsys.com Thu Jan 19 14:43:58 2012 Return-Path: X-Original-To: decade@ietfa.amsl.com Delivered-To: decade@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EDA321F86D8; Thu, 19 Jan 2012 14:43:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.619 X-Spam-Level: X-Spam-Status: No, score=-102.619 tagged_above=-999 required=5 tests=[AWL=-0.020, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xYEcVNCQ7D9Q; Thu, 19 Jan 2012 14:43:55 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8041921F859F; Thu, 19 Jan 2012 14:43:54 -0800 (PST) Received: from SUBMAN.elandsys.com ([41.136.233.89]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q0JMhWJB025552 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 19 Jan 2012 14:43:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1327013026; i=@elandsys.com; bh=nRz6cmxTkFbw4Vxrau3Xi3/ChTBBIXAgSqQv3pTfzhU=; h=Message-Id:Date:To:From:Subject:Cc:References:Mime-Version: Content-Type; b=HE1ONOd2EY+8Y6ciXgLfzfw+Z1gvuB6D6NxuhiVfgRoUNRlynkWa04aasMvlCt3V0 KpMfUXT3AOCfVAU8COtj4BKXHCluHfitF+2yPKAlgJMkn6hInFvh+Zb+QzfB2X5w76 HBumbqJ3M8wPV7bAPnUivouDv83u6veHDDZd6UZ4= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1327013026; i=@elandsys.com; bh=nRz6cmxTkFbw4Vxrau3Xi3/ChTBBIXAgSqQv3pTfzhU=; h=Message-Id:Date:To:From:Subject:Cc:References:Mime-Version: Content-Type; b=TnKaiD4C8s1MmivVu+GIvlOdK1tWusz177wLeNjJ5milLG3QgrZmHKn9Ke4sTDp98 KF0oBKcPGvCDy9hqT58IYfKmKMHM1oS76dTyAaEW43CWv7kLKESdJ8jP9k7HKFPGQY 0q4Iw32F2sUD9s/9PjgSow62HsaTM/bOVwohKnfo= Message-Id: <6.2.5.6.2.20120119142440.0634f7a8@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 19 Jan 2012 14:41:40 -0800 To: Haibin Song , Richard Woundy From: S Moonesamy References: <6.2.5.6.2.20120110211953.0e06fed0@elandnews.com> <6.2.5.6.2.20120110224228.0ccc4770@elandnews.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Mailman-Approved-At: Thu, 19 Jan 2012 15:23:43 -0800 Cc: decade@ietf.org, appsdir@ietf.org Subject: Re: [decade] Apps review of DECADE drafts X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2012 22:43:58 -0000 Dear DECADE WG Chairs, As I mentioned in a previous email, the Applications Area Directorate has identified draft-ietf-decade-problem-statement-04 and draft-ietf-decade-reqs-05 for review. Could you please tell me when the revision of draft-ietf-decade-problem-statement-04 will be submitted? Regards, S. Moonesamy http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate From sm@elandsys.com Thu Jan 19 15:13:18 2012 Return-Path: X-Original-To: decade@ietfa.amsl.com Delivered-To: decade@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DE4A21F86E0; Thu, 19 Jan 2012 15:13:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.619 X-Spam-Level: X-Spam-Status: No, score=-102.619 tagged_above=-999 required=5 tests=[AWL=-0.020, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id awy5cVfW6dKZ; Thu, 19 Jan 2012 15:13:17 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D1FA21F86D9; Thu, 19 Jan 2012 15:13:17 -0800 (PST) Received: from SUBMAN.elandsys.com ([41.136.233.89]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q0JND0re013692 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 19 Jan 2012 15:13:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1327014793; i=@elandsys.com; bh=KZvWmlUNUfq2VjKjKR4ARH9SgCXRk8E3WUStIIs/XE4=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=Vstxo09HK7uamL2ySIXnvLyUR1jqk9N3kpCKNIp6jiwRkYQKirWSvW76d0Cb9mGRG fsKhOXaGSMerYMuWuc/GwOUkCYPdxJunOmtGiNDLxtsGDNwgQO/yl4xiirWcIpeJcQ JNHDI64EbhRcArvzCIByusxoLzcQH5kSTifo8vAo= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1327014793; i=@elandsys.com; bh=KZvWmlUNUfq2VjKjKR4ARH9SgCXRk8E3WUStIIs/XE4=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=P0x31u/tvL+1Lor/dm96eDZShYAhcUTdgwwn+6aJ7D27Fm7N4mYYKDGoAnunlmnZ0 YGBHdRriavFL/7wuQKz2sAuqTcnkVRH6VhehSjdtNk6Nn1kLHRyTi19DaENXvFg4c1 H7sl+OwajRgd2iIvWTJPfmy6ipUygbKHm4xu26bw= Message-Id: <6.2.5.6.2.20120119145043.09d2f438@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 19 Jan 2012 14:57:52 -0800 To: "Woundy, Richard" , haibin.song@huawei.com From: S Moonesamy In-Reply-To: <1CA25301D2219F40B3AA37201F0EACD1150603A3@PACDCEXMB05.cable .comcast.com> References: <6.2.5.6.2.20120119142440.0634f7a8@elandnews.com> <1CA25301D2219F40B3AA37201F0EACD1150603A3@PACDCEXMB05.cable.comcast.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Mailman-Approved-At: Thu, 19 Jan 2012 15:23:43 -0800 Cc: decade@ietf.org, appsdir@ietf.org Subject: Re: [decade] Apps review of DECADE drafts X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2012 23:13:18 -0000 Hi Rich, At 14:48 19-01-2012, Woundy, Richard wrote: >The document draft-ietf-decade-problem-statement-04 is held up due >to a much deeper review I undertook as document shepherd. I need to >communicate a lot of changes and questions back to the authors as a >result of this review. I don't think this document is ready for your >review at this time. Thanks for the quick reply. Will draft-ietf-decade-reqs-05 and the revision of draft-ietf-decade-problem-statement be sent for IETF Last Call simultaneously? Regards, S. Moonesamy From cabo@tzi.org Sun Jan 22 17:44:11 2012 Return-Path: X-Original-To: decade@ietfa.amsl.com Delivered-To: decade@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92A8D21F85D5; Sun, 22 Jan 2012 17:44:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CHOVob08hbvZ; Sun, 22 Jan 2012 17:44:10 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id BE28121F85D1; Sun, 22 Jan 2012 17:44:09 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id q0N1hnVf017394; Mon, 23 Jan 2012 02:43:49 +0100 (CET) Received: from [192.168.217.117] (p54899A62.dip.t-dialin.net [84.137.154.98]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 88DDBA6A; Mon, 23 Jan 2012 02:43:48 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1251.1) From: Carsten Bormann Date: Mon, 23 Jan 2012 02:43:47 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: To: IETF Apps Discuss , draft-ietf-decade-arch-04.all@tools.ietf.org X-Mailer: Apple Mail (2.1251.1) X-Mailman-Approved-At: Mon, 23 Jan 2012 05:10:13 -0800 Cc: decade@ietf.org, SM Subject: [decade] APPSDIR review of draft-ietf-decade-arch-04 X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2012 01:44:11 -0000 I have been selected as the Applications Area Directorate reviewer for this draft (for background on APPSDIR, please see = http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate)= . Please resolve these comments along with any other Last Call comments you may receive. Please wait for direction from your document shepherd or AD before posting a new version of the draft. Gruesse, Carsten --------------------------------- Document: draft-ietf-decade-arch-04 Title: DECADE Architecture Reviewer: Carsten Bormann Review Date: 2012-01-22 ** Summary: This draft is not ready for publication as an Informational RFC and should be revised before publication. Note: I decided to review this by reading the architecture document only, to see whether it is able to stand alone. Note that this implies that the review is likely incomplete. Given the cluster of entangled documents this is a part of, I recommend a concerted review of the next version(s). ** Major Issues: A1) General: Although this is not explicitly said in the introduction, the objective of this document appears to be both: -- to provide an architecture that will constrain and guide the further work of DECADE; -- to present the architecture in an introductory, reasonably accessible way, which will facilitate understanding the specific protocol specifications envisaged. These two (prescriptive vs. descriptive) objectives of this document do conflict, and the conflict is not always managed. In particular, the document goes to considerable detail in describing the protocols, but it is not clear whether this is just illustrating the architecture (as I would expect in an architecture document) or actually constraining the protocol design. E.g., -- for the write-through PUT (section 7.1), it is specified that just one target server can be given to the intermediary. Is this an accident or deliberate? -- For GET, returning the data is optional (section 7.1)? -- "DRP is specified as being carried through extension fields within an SDT (e.g., HTTP headers)." (section 6). Is it always extension fields or is it sometimes the body? (Well, the HTTP body could be called an extension field of HTTP, too.) I think the point is that the DRP data are mostly piggy-backed on SDT. Why not say that. A1a) There are a number of places where the architecture is not yet explicit about the role of entities and data objects that it requires to function. Again, the document needs to decide for itself whether these entities and objects are illustrative only or part of the prescriptive elements of the architecture. E.g., -- is the "abstract specification of ... operation" in 6.2.1 and 6.2.2 only provided for illustration, or is the architecture limiting itself to exactly these two operations? -- There appear to be some implicit parameters such as application context? -- Or, for a PUT, how are metadata such as the expiration time established? -- Is the introductory sentence of 7 intended to limit the server-to-server interaction to a pull model ("download")? -- What is the semantics of a third-party (client-to-server-to-server) GET with respect to the middle server? Is the initiating server supposed to execute a local PUT with the result? Or what is its role? A2) Terminology: The architecture defines a number of terms quite deliberately (section 2), but misses out on a few important ones. Some important roles in the architecture (such as the ticket generating server) are only introduced cursorily, without considering the implications of their existence to the architecture. A2a) "user" (4.5.2) appears to be a central concept of the architecture, but is fleshed out only very thinly. A related concept might or might not be "account", which is only touched on, or "principal" (used in the appendices only). A2b) 4.5.2 introduces an "Application Provider" that is used nowhere else. What is that? Is that an important functional entity? A2c) The capability architecture (the "token" as a data structure, and its interaction with various functional elements) is a central element of the DECADE architecture. -- See RFC 4949 with respect to the usage of the term "token". -- The "token generating server" appears to be important, but is not called out in the list of functional elements in 2. How does a client select/find one? -- The document repeatedly (5.4, 6.1.2) states that a DECADE client must trust the token generating server, but never indicates why. -- Obviously, the DECADE servers need to trust the tokens. This is not discussed. -- The token is said to contain data object names, but then it is also meant to be useful for a "batch of operations", some of which may concern data the names of which we don't know yet. -- How is it useful to "allow a DECADE Server to detect when a token is used multiple times" (what is the server supposed to do when it = has detected that?)? -- Do tokens need a revocation mechanism? A2d) Sections 4.3 and 6.1.3 use a concept called "application context". Apparently application contexts are quite important for DECADE operations (e.g., 6.1.3 makes clear that "objects" are always associated with an application context); what are these application contexts? Who creates, deletes them? Resource control, access control for them? (Some operations seem to have an application context as an implicit parameter. Assumptions like these need to be spelled out.) A2e) 3.1: "Let S(A) denote A's DECADE storage server." This concept of ownership is never explained. Is it important? A3) The appendices provide relatively raw existence proofs that are likely to be overtaken by events in a year from now. Much of these are (overly) brief mini-tutorials for the relevant protocols. Appendix A.3 is about a protocol that itself does not seem to be fully cooked at this point. This is certainly useful material to collect for the WG, but it is not clear that these should be part of this document. There are lots of additional issues in these appendices, e.g.: A.1.1.1) HTTPS (where is the reference?) is a security protocol, but does not provide access control. A.1.1.3) This would need to (at least briefly) examine the interactions between HTTP caching and DECADE protocol operation. A.1.3) This specifies (?) "In the reply, the hash is sent in an ETAG header." What kind of response are we talking about? 304? Is this really part of the architecture? A.1.5) Why should the transfer protocol provide the complete access control mechanism? Access control is a local function. Transfer protocols just have to make sure the necessary parameters are in place (and/or may be used for transferring the parameters in the first place). When talking about OAUTH 2, add the relevant reference(s). I have not undertaken to review the appendices in any detail. A4) Is the architectural thinking converged enough on issues of naming? E.g., -- 4.3 seems to imply "resource identifiers" are being used that are the same between different servers. -- 5.3.1 seems to support this by building names in a predictable way out of hashes. In particular, "a DECADE client knows the name of a data object before it is completely stored at the DECADE server." -- However, if DECADE is to be used for real-time interactions, some thought needs to be given on the point in time when hash-based data identifiers/names can be generated. A DECADE client that PUTs video to a DECADE server may not have the complete byte-string of a slice in hand when it starts sending, so it can't send a hash-based name at the start. This is likely to have some impact on the protocol mappings possible. (It also makes it less clear that there is a good reason not to support name generation by the server right from the start.) -- A.2.3 says "DECADE may find the concept of collections to be useful if there is a need to support directory like structures in DECADE. It also discusses WebDAV's MOVE and COPY operations. What is the point when the name uniquely follows from the content? -- 6.1.2 says tokens include "Permitted objects (e.g., names of data objects that may be read or written)" and "It is possible for DRP to allow tokens to apply to a batch of operations to reduce communication overhead required between DECADE Clients." Does this require prescience on what the hash values of future slices will be? A5) Authorization based in IP addresses (6.1.2 "permitted clients") is rarely appropriate. A6) Much of the information discussed in 6.1.3 will be PII. The architecture must discuss how the protocols will provide the flexibility to cope with different data protection and surveillance regulations. For instance, the level of logging performed by a server may be an important parameter that must be indicated to the client before it starts operation, or some of it may conversely be clandestine. A7) Please rewrite section 9 from scratch. There is no need to explain fundamentals of cryptographic data structures (assuming that the next version will use terms that can be referenced properly). Instead, actual security considerations of the DECADE architecture must be discussed, e.g., the cache discovery attack mentioned above. More importantly, there needs to be a discussion of the threat model, the trust relationships envisaged, etc. Please see RFC 3552. ** Minor Issues: M1) Terminology Beyond the problems listed above, the draft needs an overhaul in its terminology. E.g.: -- it uses "TTL" as a term for an object expiration time, without ever explaining the term. (What is actually meant is an expiration time, *NOT* a lifetime/duration or hop count that would be analogous to IPv4's use of the abreviation.) -- using "data object" as the term for the things saved in a DECADE server is highly confusing. It is not always clear whether the raw byte string or the combination of this and certain metadata is meant. Do NOT use "contents" in its plural form as a synonym for "data objects" (4.2). Indeed, the document would improve by using "content" very sparingly, only in the overview sections, and being precise about data objects otherwise. (It would be preferable to have a name for the "data objects" that is distinctive from the plain English meaning of that term. E.g., slice.) E.g., while we learn about data objects that they are immutable and not all of the same size, we need consistent terms for the various kinds of metadata used, such as the DECADE metadata that are used in managing the localized storage vs. those metadata that would be visible in the SDT. "If an application wishes to store such metadata persistently within DECADE, it can be stored within data objects themselves." (What does that mean? New, separate objects? Within the existing ones? In the slice byte-string itself?) -- "data transport protocol" contains the term "transport protocol" which means something different in the IETF. We tend to use "transfer protocol" for the purpose intended. -- 4.4 introduces a "location". What is that? A DECADE server? -- "Traffic De-duplication" is a seriously misleading term for validated cache access. The whole point of the validation protocol in 8.2.1.2 appears to be to protect the cache at S against a colluding pair of A and R, under the assumption that A is not authorized to access S' copy of the object but compensates by being authorized to access R's copy. Since R can (1) indicate authorization and (2) prove to S it does have the data, both using the challenge-response protocol, S can fulfill the request for R. If that is the point, please say that. Please note that, from this exchange, A and R can still extract the fact that S had a copy. Discuss security implications of this discovery. 4.1) "However, the architecture may allow for more-than-one data transport protocols to be used." This *is* the architecture. It either allows it or not. (BTW, shouldn't the architecture also say something about negotiation/capability discovery?) 4.5.1) "The Storage Provider delegates the management of the resources at a DECADE server to one or more applications." What does that really mean? (And are the latter "Content Distribution Applications"?) 5.4) Is this really a digital signature? (Please reserve the term "digitally signed" for actual signatures, as opposed to including a kind of peer entity authentication that is directed towards a specific recipient. See RFC 4949.) 6.1) "...DRP allows one instance of such an application, e.g., an application endpoint, to apply access control and resource sharing policies on each of them." (them =3D DECADE servers.) That last sentence is rather ominous. Is this completely trivial, or does it actually mean anything? Is DRP maybe a reliable multicast protocol for control data? 6.1.4) The term "MIME type" has been superseded by "media type" (please also reference the relevant RFCs here). It is also not clear to me what that media type means in case of a slice of a larger resource representation. Why is a media type not copied with the object? 7.1) "It is also assumed that the operation performed at the remote server is the same as the operation in the original request." Explain "the same" -- are all parameters identical? Or is it just GET vs. PUT? ** Nits: [list editorial issues such as typographical errors, preferably = by section number] 1) "Content Distribution Applications" in the first sentence is not defined. Point to 2.6. 4.2) "are referred as" -> "are referred to as" 4.3) "Objects that are stored in a DECADE storage server can be accessed by DECADE content consumers by a resource identifier" second by -> via 4.3) " Because a DECADE content consumer can access more than one = storage server within a single application context, a data object = that is replicated across different storage servers managed by a = DECADE storage provider, can be accessed by a single identifier." Non sequitur. Change to: >> A DECADE content consumer may be able to access more than one storage server within a single application context. A data object that is replicated across different storage servers managed by a DECADE storage provider can still be accessed by a single identifier. << [Now, it is still not quite clear from that sentance whether that is a MUST (i.e., the whether the architecture mandates that all replicated copies MUST have the same identifier).] 4.5.2) "applications granted resources"? applications being granted resources? resources granted by applications? 5) s/principals/principles/ (Just once in the first paragraph; otherwise, principle vs. principal has been used correctly.) 6.2.2) defered -> deferred 7.1) "Note that when a DECADE client invokes a request a DECADE server with these additional parameters" -- syntax. 8.2.1.1) "When a DECADE client (A) indicates its DECADE account on a DECADE server (S) to fetch an object from a remote entity (R) (a DECADE server or DECADE client)..." What? The "account" is asked to fetch from a "client"? Ceterum censeo) RFCs, as any kind of formal technical publication, should use units in accordance with ISO/IEC 80000, in particular IEC 80000-13. Replace Mbps by Mbit/s, KB by KiB. ** Random observations: O1) The proto writeup says: > The document was reviewed by DECADE WG members, the WG Chairs, and > key non-WG contributors, particularly by David E Mcdysan, Borje > Ohlman, Akbar Rahman, Ning Zong and Dirk Kutscher. Akbar Rahman and Dirk Kutscher are co-authors of this document, so I sure hope they have reviewed this document. O2) The architecture does not give an argument why multiple SDTs are needed when all of them are just HTTP anyway. (Binding the SDT to multiple underlying protocols creates a lot of headaches that may be completely unnecessary. At least they aren't motivated.) But maybe it is not the job of the architecture document to actually motivate this highly complexity-inducing generality. E.g., A.2 alludes to a mapping to WebDAV, but then seems to go on suggesting modifications to WebDAV to enable that layering. This doesn't seem consistent. Indeed, it seems unlikely that DECADE can layer cleanly on top of either WebDAV or CDMI. A more productive view of these protocols may be as a toolkit to take certain parts from, that HTTP does not have, and that DECADE does not want to re-invent. Special care must be taken not to create a chimera, though. --- From richard.alimi@gmail.com Tue Jan 31 23:42:31 2012 Return-Path: X-Original-To: decade@ietfa.amsl.com Delivered-To: decade@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3703E21F8498 for ; Tue, 31 Jan 2012 23:42:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Csg-v0AU3Zfq for ; Tue, 31 Jan 2012 23:42:30 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0207021F8494 for ; Tue, 31 Jan 2012 23:42:29 -0800 (PST) Received: by iagf6 with SMTP id f6so1387836iag.31 for ; Tue, 31 Jan 2012 23:42:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:from:date:x-google-sender-auth:message-id :subject:to:content-type; bh=khXRqrEFqFWR6b4u3LU5srdD6lLz1Ypx+XwNfZTHbPs=; b=pZAeP+Z+/tbqF8654YeqQ0pz4NIldRvl/SvUDpJPWMjyMrODmucPre7K6kpGTUSk6P 0GxSI5axJ8uzw6viv4Ke1Gn2qLZOT9yIg8h5K7iDASD+tAGudODUqu9O4iUN1uqEGFki TTyg50/8sOsj6MuRkUe2IM0df9Y1TF8Z2Rofk= Received: by 10.50.189.134 with SMTP id gi6mr5568455igc.18.1328082149556; Tue, 31 Jan 2012 23:42:29 -0800 (PST) MIME-Version: 1.0 Sender: richard.alimi@gmail.com Received: by 10.231.69.7 with HTTP; Tue, 31 Jan 2012 23:42:09 -0800 (PST) From: Richard Alimi Date: Tue, 31 Jan 2012 23:42:09 -0800 X-Google-Sender-Auth: jnEqFSjTCDSsaE5f4H599p0U0-k Message-ID: To: decade@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [decade] (belated) review of draft-ietf-decade-integration-example-02 X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2012 07:42:31 -0000 The following is a (belated) review of draft-ietf-decade-integration-example-02. Apologies for the delay in getting this out: In general, I think the draft has good content and after it is cleaned up, it would be useful to have in order to record implementation experience that would be useful for protocol design. Abstract: - It seems awkward for an integration examples draft to say that it describes a DECADE client API (when mentioned in the abstract, it sounds like that is one of the main ideas of the draft). I understand the rationale for discussing it to put the experiments, etc in context. But I wouldn't mention it in the abstract. In the introduction, perhaps just say that it is presented for completeness since there is no standard DECADE Client API yet. - If the goal is to discuss a general "ALTO+DECADE based file distribution platform", that sounds like a topic for an entire draft instead of buried in integration examples. Is that too ambitious to mention in the abstract? Perhaps better worded as something like "an example integration of ALTO and DECADE to support file distribution". Section 1: - I'm not sure what "A DECADE server provides ... transport service with interactive control to DECADE clients" means. Is it possible to stick to terminology used in other DECADE drafts where it is available? - The way it is stated, "P2PLS" sounds like the name of a client that is commonly-known and publicly available. Is it? If it isn't and it is something developed internally, then it would be better to state that. (I see later that this is specific explicitly in Section 2, but might be better to reword the introduction along these lines too.) Section 2: - Should the section be named "Terminology"? - Indicate what "storage strategies" means (not clear to me) - It seems like DECADE Client in draft-ietf-decade-arch-04 is the same as a DECADE Module in this draft? Would be good to align the terminology. - I'm not sure "Remote Controller" is a term that needs to be defined formally. Section 3: - Does Generate_Token generate the token locally, or ask the server to generate the token? Might be good to indicate that here. Section 4: - Opening paragraph does not seem complete.. missing the end of the sentence? - Use "P2P Peer" instead of "DECADE Peer"? I think "DECADE Peer" gets across the wrong message. - "Neither the DECADE server and the original client knows each other." Though I understand what is intended, this sentence is kind of confusing and probably better left out. Section 5: - Why say "or at least not to hurt"? If there was no benefit for the application itself, it seems like it would not be adopted. - The "Limited Connection Slot" section actually talks about 2 other problems that seem to be distinct. Separate them or change the name of the section? - I somewhat disagree with saying that these will be harmful, particularly when we don't even have a protocol written down yet (or have been chartered to work on one). These are very useful data points to have, and things that should certainly be considered when developing the protocol, but I'd be concerned that someone reading the draft draws an incorrect conclusion that we've already written down a protocol that has known issues with it. Can that section be reworded to indicate that these are important design considerations that should be fed in to protocol development? - Another thing that P2P software does is have many outstanding download requests at a time, which reduces the impact of the additional per-block latency. It might be worth mentioning this. - The message-level details (BT_Piece/BT_Request) in the "Interface between DECADE plugin and Vuze client" paragraph are probably too technical for the introduction to the technique. Perhaps describe that part at a higher level... like "the DECADE plugin inserts itself into the Vuze client by intercepting certain BitTorrent messages, and adjusting their handling to send/receive data using DECADE instead"? The following sections that you have fill in this detail already. - Before discussing the technical details of 5.3, either give a reference to relevant messages in the BitTorrent protocol, or give a brief explanation of them here. - In 5.3, it might be clearer to have a diagram of the traditional BitTorrent message exchange, and then show the corresponding diagram including DECADE. That would give the reader a better basis for comparison (and would help explain the conclusions you draw earlier in Section 5). Section 6: - In the introduction, give an overview of the role of ALTO is in this architecture instead of jumping directly into the technical details. - I would have expected an ALTO Server and ALTO Client labeled somewhere in Figure 4? In general, Section 6 doesn't indicate anywhere explicitly where ALTO is used. The only thing I see is "optimal DECADE server", so I'm assuming that part is decided by ALTO. In any case, the usage of ALTO should be documented in the diagrams and the text. - "DECADE Server will divide the file into many slides as long as the length of file, and save them in different folder." -- why split put each piece in a different folder? That seems like too much implementation detail for this. - In 6.3, is the user using a normal web browser (the description seems to say it does). If so, then is the browser assumed to speak the DECADE protocol? - In Figure 6, why is the Publisher downloading the data? Presumably it was the one who originally put the data there :) I think that is supposed to be the end-user instead? Section 7: - Indicate why a flash-crowd scenario is used - is it to test scalability? or some other reason? A flash-crowd may not be the "typical" conditions, so it is worth noting why this was used. - Indicate what "total supply bandwidth" means. - "Test Controller" used here, but "Remote Controller" in previous sections? - The lines in Figure 7 are kind of confusing since it is all squished together. Is it possible to lay out the figure differently to make it more clear? - Figure 8: whats the FTP Server for? Section 8: - ".. is configured to the corresponding Ethernet port of DECADE Server." I tend to doubt that the link speed of the card was configured. IIRC, software was used to limit the maximum bandwidth? - In 8.1.3, I'm still unclear on what "ALTO+DECADE based file distribution platform" means. The text in that subsection seems to have nothing to do with ALTO or DECADE? (Similar comment for Section 8.2.3). - "While in the native P2P live streaming system, more than 70% of peers uploaded in a rate that is much more than streaming rate." Can that statement be made more precise? I'm not sure what "much more" means here. Editorial: - In general, the document could benefit from a thorough review for grammar.