From melodysong@huawei.com Mon Jul 20 18:25:15 2009 Return-Path: X-Original-To: decade@core3.amsl.com Delivered-To: decade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B669A3A6A50 for ; Mon, 20 Jul 2009 18:25:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.049 X-Spam-Level: *** X-Spam-Status: No, score=3.049 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fN7NwPOYhstB for ; Mon, 20 Jul 2009 18:25:15 -0700 (PDT) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id D11623A698E for ; Mon, 20 Jul 2009 18:25:14 -0700 (PDT) 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 <0KN3001YXYL1A5@szxga04-in.huawei.com> for decade@ietf.org; Tue, 21 Jul 2009 09:24:37 +0800 (CST) Received: from huawei.com ([172.24.1.33]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KN3005PLYL1YL@szxga04-in.huawei.com> for decade@ietf.org; Tue, 21 Jul 2009 09:24:37 +0800 (CST) Received: from s64081 ([10.164.12.15]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KN300FOYYL15V@szxml06-in.huawei.com> for decade@ietf.org; Tue, 21 Jul 2009 09:24:37 +0800 (CST) Date: Tue, 21 Jul 2009 09:24:40 +0800 From: Song Haibin To: decade@ietf.org Message-id: <007d01ca09a2$053c4bb0$0f0ca40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Thread-index: AcoJogUCy7uJ2Q9tQuyu3DMv89gt+Q== Subject: [decade] test X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2009 01:25:15 -0000 Please ignore. Best Regards, Haibin Skype: alexsonghw From melodysong@huawei.com Mon Jul 20 23:52:21 2009 Return-Path: X-Original-To: decade@core3.amsl.com Delivered-To: decade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C87933A6E0A for ; Mon, 20 Jul 2009 23:52:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.049 X-Spam-Level: *** X-Spam-Status: No, score=3.049 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xql7E7XSKyaz for ; Mon, 20 Jul 2009 23:52:20 -0700 (PDT) Received: from szxga02-in.huawei.com (unknown [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id 9D0233A67EE for ; Mon, 20 Jul 2009 23:52:20 -0700 (PDT) Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KN400B21DC8YU@szxga02-in.huawei.com> for decade@ietf.org; Tue, 21 Jul 2009 14:43:21 +0800 (CST) Received: from huawei.com ([172.24.1.33]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KN400JQADC8BB@szxga02-in.huawei.com> for decade@ietf.org; Tue, 21 Jul 2009 14:43:20 +0800 (CST) Received: from s64081 ([10.164.12.15]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KN400BFIDC8S2@szxml06-in.huawei.com> for decade@ietf.org; Tue, 21 Jul 2009 14:43:20 +0800 (CST) Date: Tue, 21 Jul 2009 14:43:20 +0800 From: Song Haibin To: decade@ietf.org Message-id: <00d001ca09ce$897ca240$0f0ca40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Thread-index: AcoJzolA0el+Orf1QxigqcR1Oi2mjg== Subject: [decade] Poll for the time slot of DECADE bar BoF X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2009 06:52:21 -0000 Dear all, First, thanks to Alexey and Lisa for their help to setup this mailing list. Again, please follow the link below to select the time slot that you will be available for the bar BoF. http://www.doodle.com/ekbyza5rt75purw8 During this bar bof, we will discuss a possible way to move p2p applications data plane into the network and how to integrate it with p2p applications seamlessly. It will help to save the last-mile bandwidth problem caused by p2p applications. We will also discuss to use a possible simple unified protocol to access the in-network storage, which will make the in-network storage system a light one that does not need to support various p2p applicaton protocols. The agenda will be published soon. If you have some topic to be discussed during the bar BoF, please let me know. Best Regards, Haibin Skype: alexsonghw Best Regards, Haibin Skype: alexsonghw From abcdmatao@gmail.com Wed Jul 22 00:53:57 2009 Return-Path: X-Original-To: decade@core3.amsl.com Delivered-To: decade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 95E313A69E0 for ; Wed, 22 Jul 2009 00:53:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2fP00-8g68o6 for ; Wed, 22 Jul 2009 00:53:56 -0700 (PDT) Received: from mail-gx0-f213.google.com (mail-gx0-f213.google.com [209.85.217.213]) by core3.amsl.com (Postfix) with ESMTP id B60963A6889 for ; Wed, 22 Jul 2009 00:53:43 -0700 (PDT) Received: by gxk9 with SMTP id 9so21538gxk.13 for ; Wed, 22 Jul 2009 00:51:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:cc:content-type; bh=pn4lkuAud+CmNhb7xqNkWJcHAYb4ZYoXU478TtkMk+s=; b=NFxt4zLubLK17n6Wxiykbwew3F+7ZxM92VIxV3XjyZJAPAVJNexNZB6i3ruAY78IPX LMlcSRXWvKQmqAynoAbHVUHGj4wAiKAfx7hDF/TgWrnHhgyHseRXimFtkxoeegjt5Wwl 3hQ04CQFpWP3FUj7jkcYHQ3S97NjKTEQRFdZA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=LNd4o+frW6hfPGBKPj4aqqK04jBaDkjxUruULg42EKRuCGX2GgdYlTQsgdAu8dbIho bHT3vbiWKxtdmiZlbaWhtGku3NvA48gi7uHCSZMmbezQYgO0ZT73OYgUPbvv6PX2egHE SZ3NCdq4Q8ZzsOLaA6DLIgaB0jWIS8rDz197M= MIME-Version: 1.0 Received: by 10.150.11.6 with SMTP id 6mr319094ybk.54.1248249118464; Wed, 22 Jul 2009 00:51:58 -0700 (PDT) Date: Wed, 22 Jul 2009 15:51:58 +0800 Message-ID: <99978d7d0907220051l19c710a0u9ff93b0635328f07@mail.gmail.com> From: Tao Ma To: decade@ietf.org, melodysong@huawei.com Content-Type: multipart/alternative; boundary=000e0cd6b1a64c1b92046f46a5fc Cc: standardMINE@googlegroups.com Subject: Re: [decade] Poll for the time slot of DECADE bar BoF X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2009 07:53:57 -0000 --000e0cd6b1a64c1b92046f46a5fc Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi, I am not very clear about the description of DECADE bar BoF.What does "a possible way to move p2p applications data plane into the network and how to integrate it with p2p applications seamlessly" mean? Does it mean that there would be an independent data storage system which would be accessed by various P2P applications? In that way, who would operate the storage system or is this system a distributed system? I am a little confused about the concept of "in-network storage". I would appreciate your reply:) Tao Ma July 22nd Beijing University of Posts and Telecommunications, Mobile lIfe and New Media Lab --000e0cd6b1a64c1b92046f46a5fc Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable Hi,
     I am not very clear about the description o= f DECADE bar BoF.What does "a possible way to move p2p applications data plane= into the network and how to integrate it with p2p applications seamlessly" mean? Does it me= an that there would be an independent data storage system which would be ac= cessed by various P2P applications? In that way, who would operate the stor= age system or is this system a distributed system? I am a little confused a= bout the concept of "in-network storage". I would appreciate your= reply:)
Tao Ma
July 22nd
Beijing University of Posts and Telecommunications, = Mobile lIfe and New Media Lab
 --000e0cd6b1a64c1b92046f46a5fc-- From zongning@huawei.com Wed Jul 22 01:47:28 2009 Return-Path: X-Original-To: decade@core3.amsl.com Delivered-To: decade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C8E703A6842 for ; Wed, 22 Jul 2009 01:47:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.337 X-Spam-Level: X-Spam-Status: No, score=-95.337 tagged_above=-999 required=5 tests=[AWL=-3.022, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RDNS_NONE=0.1, SARE_SUB_ENC_GB2312=1.345, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WK5mmnnWpL2e for ; Wed, 22 Jul 2009 01:47:27 -0700 (PDT) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 29D403A683A for ; Wed, 22 Jul 2009 01:47:27 -0700 (PDT) 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 <0KN600ACBDKLNN@szxga04-in.huawei.com> for decade@ietf.org; Wed, 22 Jul 2009 16:43:33 +0800 (CST) Received: from huawei.com ([172.24.1.33]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KN6007KZDKK0U@szxga04-in.huawei.com> for decade@ietf.org; Wed, 22 Jul 2009 16:43:32 +0800 (CST) Received: from z63316 ([10.164.12.81]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KN6000Z5DKK2L@szxml06-in.huawei.com> for decade@ietf.org; Wed, 22 Jul 2009 16:43:32 +0800 (CST) Date: Wed, 22 Jul 2009 16:43:31 +0800 From: Ning Zong In-reply-to: <99978d7d0907220051l19c710a0u9ff93b0635328f07@mail.gmail.com> To: 'Tao Ma' , decade@ietf.org, melodysong@huawei.com Message-id: <001901ca0aa8$7e5391f0$510ca40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/alternative; boundary="Boundary_(ID_mVhn+8LEIpiNqDQiWKBkxA)" Thread-index: AcoKog4K7jbGUz7pSjOl2CC4QT4xKQABU6yA Cc: standardMINE@googlegroups.com Subject: [decade] =?gb2312?b?ILTwuLQ6ICBQb2xsIGZvciB0aGUgdGltZSBzbG90IG9m?= =?gb2312?b?IERFQ0FERSBiYXIgQm9G?= X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2009 08:47:28 -0000 This is a multi-part message in MIME format. --Boundary_(ID_mVhn+8LEIpiNqDQiWKBkxA) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: quoted-printable Hi, Tao, =20 Please see inline. =20 =20 BR, Ning Zong _____ =20 =B7=A2=BC=FE=C8=CB: decade-bounces@ietf.org = [mailto:decade-bounces@ietf.org] =B4=FA=B1=ED Tao Ma =B7=A2=CB=CD=CA=B1=BC=E4: 2009=C4=EA7=D4=C222=C8=D5 15:52 =CA=D5=BC=FE=C8=CB: decade@ietf.org; melodysong@huawei.com =B3=AD=CB=CD: standardMINE@googlegroups.com =D6=F7=CC=E2: Re: [decade] Poll for the time slot of DECADE bar BoF =20 Hi, I am not very clear about the description of DECADE bar BoF.What = does "a possible way to move p2p applications data plane into the network and = how to integrate it with p2p applications seamlessly" mean?=20 =20 [Ning Zong] Our aim is to decouple P2P signaling plane and data plane = such that the data traffic is not necessarily among the peers =A8C hence potentially reduce the burden on access domain. Here, =A1=B0in-network storage=A1=B1 means the storage provided by ISP, = Cache or CDN providers and provides the above capabilities to P2P applications. =20 Does it mean that there would be an independent data storage system = which would be accessed by various P2P applications?=20 =20 [Ning Zong] Yes. =20 In that way, who would operate the storage system or is this system a distributed system? =20 [Ning Zong] see above, ISP, Cache or CDN providers would provide such = system to P2P applications, and such system would be a distributed system. =20 I am a little confused about the concept of "in-network storage". =20 [Ning Zong] see above =20 I would appreciate your reply:)=20 =20 [Ning Zong] I would also thank you for your interest in this topic. Look forward to see you DECADE bar BoF in Stockholm. =20 Tao Ma July 22nd Beijing University of Posts and Telecommunications, Mobile lIfe and New Media Lab --Boundary_(ID_mVhn+8LEIpiNqDQiWKBkxA) Content-type: text/html; charset=gb2312 Content-transfer-encoding: quoted-printable

Hi, = Tao,

 <= /span>

Please see = inline.

 <= /span>

 <= /span>

BR,

Ning = Zong

=B7=A2=BC=FE= =C8=CB: = decade-bounces@ietf.org [mailto:decade-bounces@ietf.org] =B4=FA=B1=ED= Tao Ma
=B7=A2=CB=CD=CA=B1=BC=E4: = 2009=C4=EA7=D4=C222=C8=D5 15:52
=CA=D5=BC=FE=C8=CB: decade@ietf.org; melodysong@huawei.com
=B3=AD=CB=CD: standardMINE@googlegroups.com
=D6=F7=CC=E2: Re: [decade] Poll for the time slot of DECADE bar = BoF

 

Hi,
     I am not very clear about the description of = DECADE bar BoF.What does "a possible way = to move p2p applications data plane into the network and how to integrate it = with p2p applications seamlessly" mean?

 

[Ning Zong] Our aim is to decouple P2P signaling plane and = data plane such that the data traffic is not necessarily among the peers =A8C = hence potentially reduce the burden on access = domain.

Here, =A1=B0in-network storage=A1=B1 means the storage = provided by ISP, Cache or CDN providers and provides the above capabilities to = P2P applications.

 

Does it mean that there would be an independent data storage system which would be = accessed by various P2P applications?

 

[Ning Zong] Yes.

 

In that way, who would operate the storage system or is this system a distributed = system?

 

[Ning Zong] see above, ISP, Cache or CDN providers would = provide such system to P2P applications, and such system would be a distributed = system.

 

 I am a little confused about the concept of "in-network storage".

 

[Ning Zong] see above

 

 I would appreciate your reply:)

 

[Ning Zong] I would also thank you for your interest in this = topic. Look forward to see you DECADE bar BoF in Stockholm.

 


Tao Ma
July 22nd
Beijing University of Posts and Telecommunications, Mobile lIfe and New Media Lab

--Boundary_(ID_mVhn+8LEIpiNqDQiWKBkxA)-- From melodysong@huawei.com Wed Jul 22 02:31:27 2009 Return-Path: X-Original-To: decade@core3.amsl.com Delivered-To: decade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 849743A6B4D for ; Wed, 22 Jul 2009 02:31:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.31 X-Spam-Level: ** X-Spam-Status: No, score=2.31 tagged_above=-999 required=5 tests=[AWL=-0.530, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aqDHE1WuIy7Z for ; Wed, 22 Jul 2009 02:31:26 -0700 (PDT) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id CB6363A68DA for ; Wed, 22 Jul 2009 02:31:25 -0700 (PDT) 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 <0KN600FUAFLCFQ@szxga04-in.huawei.com> for decade@ietf.org; Wed, 22 Jul 2009 17:27:13 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KN6004QTFLC0Z@szxga04-in.huawei.com> for decade@ietf.org; Wed, 22 Jul 2009 17:27:12 +0800 (CST) Received: from s64081 ([10.164.12.15]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KN600JILFLCDT@szxml04-in.huawei.com> for decade@ietf.org; Wed, 22 Jul 2009 17:27:12 +0800 (CST) Date: Wed, 22 Jul 2009 17:27:13 +0800 From: Song Haibin In-reply-to: <001901ca0aa8$7e5391f0$510ca40a@china.huawei.com> To: 'Ning Zong' , 'Tao Ma' , decade@ietf.org Message-id: <007f01ca0aae$99220010$0f0ca40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/alternative; boundary="Boundary_(ID_08gZ1AZqQ+rwVnCnFxvKTg)" Thread-index: AcoKog4K7jbGUz7pSjOl2CC4QT4xKQABU6yAAAFiVnA= Subject: Re: [decade] Poll for the time slot of DECADE bar BoF X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2009 09:31:27 -0000 This is a multi-part message in MIME format. --Boundary_(ID_08gZ1AZqQ+rwVnCnFxvKTg) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: quoted-printable Hi, =20 The reason that we would like to move the data plane of P2P applications into network is that P2P puts pressure not only on the transit link and = the network backbone, but also on the last mile link (upload). The existing solution is cache system which has to support various evolving p2p application protocols. We would like to simplify that by decoupling the signal plane and data plane, and with a unified protocol for the data = plane access. The signal plane may remain the way it works now in a p2p = fashion. We will send out the problem statement document soon, it will be more = clear than what I said here: ) =20 Thanks! Haibin =20 =20 _____ =20 From: Ning Zong [mailto:zongning@huawei.com]=20 Sent: Wednesday, July 22, 2009 4:44 PM To: 'Tao Ma'; decade@ietf.org; melodysong@huawei.com Cc: standardMINE@googlegroups.com Subject: =B4=F0=B8=B4: [decade] Poll for the time slot of DECADE bar BoF Hi, Tao, =20 Please see inline. =20 =20 BR, Ning Zong _____ =20 =B7=A2=BC=FE=C8=CB: decade-bounces@ietf.org = [mailto:decade-bounces@ietf.org] =B4=FA=B1=ED Tao Ma =B7=A2=CB=CD=CA=B1=BC=E4: 2009=C4=EA7=D4=C222=C8=D5 15:52 =CA=D5=BC=FE=C8=CB: decade@ietf.org; melodysong@huawei.com =B3=AD=CB=CD: standardMINE@googlegroups.com =D6=F7=CC=E2: Re: [decade] Poll for the time slot of DECADE bar BoF =20 Hi, I am not very clear about the description of DECADE bar BoF.What = does "a possible way to move p2p applications data plane into the network and = how to integrate it with p2p applications seamlessly" mean?=20 =20 [Ning Zong] Our aim is to decouple P2P signaling plane and data plane = such that the data traffic is not necessarily among the peers =A8C hence potentially reduce the burden on access domain. Here, =A1=B0in-network storage=A1=B1 means the storage provided by ISP, = Cache or CDN providers and provides the above capabilities to P2P applications. =20 Does it mean that there would be an independent data storage system = which would be accessed by various P2P applications?=20 =20 [Ning Zong] Yes. =20 In that way, who would operate the storage system or is this system a distributed system? =20 [Ning Zong] see above, ISP, Cache or CDN providers would provide such = system to P2P applications, and such system would be a distributed system. =20 I am a little confused about the concept of "in-network storage". =20 [Ning Zong] see above =20 I would appreciate your reply:)=20 =20 [Ning Zong] I would also thank you for your interest in this topic. Look forward to see you DECADE bar BoF in Stockholm. =20 Tao Ma July 22nd Beijing University of Posts and Telecommunications, Mobile lIfe and New Media Lab --Boundary_(ID_08gZ1AZqQ+rwVnCnFxvKTg) Content-type: text/html; charset=gb2312 Content-transfer-encoding: quoted-printable
Hi,
 
The reason that we would like to move the data plane of P2P = applications=20 into network is that P2P puts pressure not only on the transit link and = the=20 network backbone, but also on the last mile link (upload). The=20 existing solution is cache system which has to support various = evolving p2p=20 application protocols. We would like to simplify that by decoupling the = signal=20 plane and data plane, and with a unified protocol for the data=20 plane access. The signal plane may remain the way it works now in a = p2p=20 fashion. We will send out the problem statement document soon, it will = be more=20 clear than what I said here: )
 

Thanks!
Haibin

 

 

From: Ning Zong = [mailto:zongning@huawei.com]=20
Sent: Wednesday, July 22, 2009 4:44 PM
To: 'Tao = Ma';=20 decade@ietf.org; melodysong@huawei.com
Cc:=20 standardMINE@googlegroups.com
Subject: =B4=F0=B8=B4: = [decade] Poll for the=20 time slot of DECADE bar BoF

Hi,=20 Tao,

 

Please see=20 inline.

 

 

BR,

Ning=20 Zong

=B7=A2=BC=FE=C8=CB: = decade-bounces@ietf.org=20 [mailto:decade-bounces@ietf.org] =B4=FA=B1=ED=20 Tao = Ma
=B7=A2=CB=CD=CA=B1=BC=E4: = 2009=C4=EA7=D4=C222=C8=D5=20 15:52
=CA=D5=BC=FE=C8=CB: decade@ietf.org;=20 melodysong@huawei.com
=B3=AD=CB=CD:=20 standardMINE@googlegroups.com
=D6=F7=CC=E2: Re: [decade] Poll for the time slot of DECADE bar=20 BoF

 

Hi,
    =20 I am not very clear about the description of DECADE bar BoF.What does=20 "a possible way to move p2p = applications data=20 plane into the network and how to integrate it with p2p applications=20 seamlessly" mean?

 

[Ning Zong] = Our aim is=20 to decouple P2P signaling plane and data plane such that the data = traffic is=20 not necessarily among the peers =A8C hence potentially reduce the = burden on=20 access domain.

Here, = =A1=B0in-network=20 storage=A1=B1 means the storage provided by ISP, Cache or CDN = providers and=20 provides the above capabilities to P2P=20 applications.

 

Does=20 it mean that there would be an independent data storage system which = would be=20 accessed by various P2P applications?

 

[Ning Zong]=20 Yes.

 

In=20 that way, who would operate the storage system or is this system a = distributed=20 system?

 

[Ning Zong] = see above,=20 ISP, Cache or CDN providers would provide such system to P2P = applications, and=20 such system would be a distributed = system.

 

 I am a little confused about the = concept of=20 "in-network storage".

 

[Ning Zong] = see=20 above

 

 I would appreciate your reply:) =

 

[Ning Zong] = I would=20 also thank you for your interest in this topic. Look forward to see = you DECADE=20 bar BoF in Stockholm.

 


Tao Ma
July 22nd
Beijing = University of=20 Posts and Telecommunications, Mobile lIfe and=20 New Media Lab

--Boundary_(ID_08gZ1AZqQ+rwVnCnFxvKTg)-- From abcdmatao@gmail.com Wed Jul 22 03:59:50 2009 Return-Path: X-Original-To: decade@core3.amsl.com Delivered-To: decade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ACF173A6768 for ; Wed, 22 Jul 2009 03:59:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.931 X-Spam-Level: X-Spam-Status: No, score=-0.931 tagged_above=-999 required=5 tests=[AWL=-1.667, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GihqK0zlodxJ for ; Wed, 22 Jul 2009 03:59:45 -0700 (PDT) Received: from mail-gx0-f213.google.com (mail-gx0-f213.google.com [209.85.217.213]) by core3.amsl.com (Postfix) with ESMTP id E389028C3C0 for ; Wed, 22 Jul 2009 03:58:34 -0700 (PDT) Received: by gxk9 with SMTP id 9so158025gxk.13 for ; Wed, 22 Jul 2009 03:57:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=/giU0uuyf6oFz6rzleX+/JTdVu8YEWqK9caBNfFQOsA=; b=pX3qBskmEvJE419fsQuGtanklxp7zJBIb/qH22fUskFre6ssM+Hwb3rbFZD4BDckFr 6Hev7E5HtnxoBv22FmJ3BNlE4aRvCqkIuGBvNuytYcNSdGAdONACytEFa5MEb+FqUJwj /peIALdyJuUtVpY8X79tLQhpz/WmMTls86XdQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=eGdzOhCxaz0g53Rp/0t78eD6zV3upe9ShooSLIyqwZa2JN2R/plMsg7aSlldvzWKO+ TqnZrorFQVVMrwWe8TatrguCIlHrvYpJDjHC4UWifC0iiCYTQpDlEzzJy83TjPKoE1r/ 2Rq2uiFnN1huBYGPBtMDrdjIXMbKDASYy5Kxg= MIME-Version: 1.0 Received: by 10.150.199.14 with SMTP id w14mr559062ybf.259.1248257556429; Wed, 22 Jul 2009 03:12:36 -0700 (PDT) In-Reply-To: <007f01ca0aae$99220010$0f0ca40a@china.huawei.com> References: <001901ca0aa8$7e5391f0$510ca40a@china.huawei.com> <007f01ca0aae$99220010$0f0ca40a@china.huawei.com> Date: Wed, 22 Jul 2009 18:12:36 +0800 Message-ID: <99978d7d0907220312n5ec3bae1xe0cac9fbc0a9a27f@mail.gmail.com> From: Tao Ma To: Song Haibin Content-Type: multipart/alternative; boundary=000e0cd348383d3ce3046f489cbc Cc: decade@ietf.org Subject: Re: [decade] Poll for the time slot of DECADE bar BoF X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2009 10:59:50 -0000 --000e0cd348383d3ce3046f489cbc Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable Hi, Really thanks for explanation. I would wait for the problem statement draft:) Tao Ma Beijing University of Posts and Telecommunications, Mobile lIfe and New Media Lab 2009/7/22 Song Haibin > Hi, > > The reason that we would like to move the data plane of P2P applications > into network is that P2P puts pressure not only on the transit link and t= he > network backbone, but also on the last mile link (upload). The > existing solution is cache system which has to support various evolving p= 2p > application protocols. We would like to simplify that by decoupling the > signal plane and data plane, and with a unified protocol for the data > plane access. The signal plane may remain the way it works now in a p2p > fashion. We will send out the problem statement document soon, it will be > more clear than what I said here: ) > > > Thanks! > Haibin > > > > > ------------------------------ > *From:* Ning Zong [mailto:zongning@huawei.com] > *Sent:* Wednesday, July 22, 2009 4:44 PM > *To:* 'Tao Ma'; decade@ietf.org; melodysong@huawei.com > *Cc:* standardMINE@googlegroups.com > *Subject:* =B4=F0=B8=B4: [decade] Poll for the time slot of DECADE bar Bo= F > > Hi, Tao, > > > > Please see inline. > > > > > > BR, > > Ning Zong > ------------------------------ > > *=B7=A2=BC=FE=C8=CB:* decade-bounces@ietf.org [mailto:decade-bounces@ietf= .org] *=B4=FA=B1=ED *Tao > Ma > *=B7=A2=CB=CD=CA=B1=BC=E4:* 2009=C4=EA7=D4=C222=C8=D5 15:52 > *=CA=D5=BC=FE=C8=CB:* decade@ietf.org; melodysong@huawei.com > *=B3=AD=CB=CD:* standardMINE@googlegroups.com > *=D6=F7=CC=E2:* Re: [decade] Poll for the time slot of DECADE bar BoF > > > > Hi, > I am not very clear about the description of DECADE bar BoF.What doe= s > "a possible way to move p2p applications data plane into the network and > how to integrate it with p2p applications seamlessly" mean? > > > > [Ning Zong] Our aim is to decouple P2P signaling plane and data plane suc= h > that the data traffic is not necessarily among the peers =A8C hence poten= tially > reduce the burden on access domain. > > Here, =A1=B0in-network storage=A1=B1 means the storage provided by ISP, C= ache or CDN > providers and provides the above capabilities to P2P applications. > > > > Does it mean that there would be an independent data storage system which > would be accessed by various P2P applications? > > > > [Ning Zong] Yes. > > > > In that way, who would operate the storage system or is this system a > distributed system? > > > > [Ning Zong] see above, ISP, Cache or CDN providers would provide such > system to P2P applications, and such system would be a distributed system= . > > > > I am a little confused about the concept of "in-network storage". > > > > [Ning Zong] see above > > > > I would appreciate your reply:) > > > > [Ning Zong] I would also thank you for your interest in this topic. Look > forward to see you DECADE bar BoF in Stockholm. > > > > > Tao Ma > July 22nd > Beijing University of Posts and Telecommunications, Mobile lIfe and New > Media Lab > > --000e0cd348383d3ce3046f489cbc Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable Hi,
    Really thanks for explanation. I would wait for t= he problem statement draft:)
Tao Ma
Beijing Universi= ty of=20 Posts and Telecommunications, Mobile lIfe and=20 New Media Lab

2009/7/22 S= ong Haibin <m= elodysong@huawei.com>
Hi= ,
 
Th= e reason that we would like to move the data plane of P2P applications=20 into network is that P2P puts pressure not only on the transit link and the= =20 network backbone, but also on the last mile link (upload). The=20 existing solution is cache system which has to support various evolvin= g p2p=20 application protocols. We would like to simplify that by decoupling the sig= nal=20 plane and data plane, and with a unified protocol for the data=20 plane access. The signal plane may remain the way it works now in a p2= p=20 fashion. We will send out the problem statement document soon, it will be m= ore=20 clear than what I said here: )
 

Thanks!
Haibin

 

 

From: Ning Zong [mailto:zongning@huawei.com]= =20
Sent: Wednesday, July 22, 2009 4:44 PM
To: 'Tao = Ma';=20 decade@ietf.org;= melodysong@huaw= ei.com
Cc:=20 standa= rdMINE@googlegroups.com
Subject: =B4=F0=B8=B4: [decade] Poll = for the=20 time slot of DECADE bar BoF

Hi,=20 Tao,

 

Please see=20 inline.

 

 

BR,<= /p>

Ning=20 Zong

=B7=A2=BC=FE=C8=CB:<= /b> decade-bounces@ietf.org=20 [mailto:deca= de-bounces@ietf.org] =B4=FA=B1=ED=20 Tao Ma
=B7=A2=CB=CD=CA=B1=BC=E4: 200= 9=C4=EA7=D4=C2<= span lang=3D"EN-US">22=C8=D5=20 15:52
=CA=D5=BC=FE=C8=CB<= span lang=3D"EN-US">: decade@ietf.org;=20 melodysong@hua= wei.com
=B3=AD=CB=CD:=20 standa= rdMINE@googlegroups.com
=D6=F7=CC=E2: = Re: [decade] Poll for the time slot of DECADE bar=20 BoF

 

Hi,
    =20 I am not very clear about the description of DECADE bar BoF.What does=20 "a possible way to move p2p appli= cations data=20 plane into the network and how to integrate it with p2p applications=20 seamlessly" mean? =

 

[Ning Zong] Our aim is=20 to decouple P2P signaling plane and data plane such that the data traffic= is=20 not necessarily among the peers – hence potentially reduce the burd= en on=20 access domain.

Here, “in-network=20 storage” means the storage provided by ISP, Cache or CDN providers = and=20 provides the above capabilities to P2P=20 applications.

 

Does=20 it mean that there would be an independent data storage system which woul= d be=20 accessed by various P2P applications?

 

[Ning Zong]=20 Yes.

 

In=20 that way, who would operate the storage system or is this system a distri= buted=20 system?

 

[Ning Zong] see above,=20 ISP, Cache or CDN providers would provide such system to P2P applications= , and=20 such system would be a distributed system.

 

 I am= a little confused about the concept of=20 "in-network storage".

 

[Ning Zong] see=20 above

 

 I wo= uld appreciate your reply:)

 

[Ning Zong] I would=20 also thank you for your interest in this topic. Look forward to see you D= ECADE=20 bar BoF in Stockholm.

 


Tao Ma=
July 22nd
Beijing University of=20 Posts and Telecommunications, Mobile lIfe and=20 New Media Lab


--000e0cd348383d3ce3046f489cbc-- From melodysong@huawei.com Wed Jul 22 18:39:37 2009 Return-Path: X-Original-To: decade@core3.amsl.com Delivered-To: decade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 524B73A6C94; Wed, 22 Jul 2009 18:39:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.493 X-Spam-Level: * X-Spam-Status: No, score=1.493 tagged_above=-999 required=5 tests=[AWL=0.499, BAYES_05=-1.11, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lahLp9Ic615f; Wed, 22 Jul 2009 18:39:36 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 601683A6405; Wed, 22 Jul 2009 18:39:36 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KN700M6WNZUHQ@szxga03-in.huawei.com>; Thu, 23 Jul 2009 09:26:18 +0800 (CST) Received: from huawei.com ([172.24.1.33]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KN700I0ONZU6M@szxga03-in.huawei.com>; Thu, 23 Jul 2009 09:26:18 +0800 (CST) Received: from s64081 ([10.164.12.15]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KN700DZYNZU0J@szxml06-in.huawei.com>; Thu, 23 Jul 2009 09:26:18 +0800 (CST) Date: Thu, 23 Jul 2009 09:26:18 +0800 From: Song Haibin To: decade@ietf.org Message-id: <002a01ca0b34$94a4e580$0f0ca40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcoLNJRWCfupf79bT9KLUFLQHEknxg== Cc: ppsp@ietf.org, p2psip@ietf.org, alto@ietf.org Subject: [decade] DECADE Bar BOF X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2009 01:39:37 -0000 Dear all, The time poll result shows that most people will be available on Wednesday evening. So the DECADE Bar BOF will finally be held on Wednesday evening, from 8pm to 10pm. The place is Room 201. The draft agenda is as the following: 1. Agenda bash 5min 2. Problem statement Haibin Song 20min 3. Survey Ning Zong 30min 4. Sailor presentation Richard Alimi 20min 5. BrachCache presentation Yu-shun Wang 20min Welcome to join the meeting and lookforward to meeting you in Stockholm. Best Regards, Haibin Skype: alexsonghw From melodysong@huawei.com Wed Jul 29 05:14:46 2009 Return-Path: X-Original-To: decade@core3.amsl.com Delivered-To: decade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1EF1B3A6FFF for ; Wed, 29 Jul 2009 05:14:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.74 X-Spam-Level: X-Spam-Status: No, score=-0.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T16ioyT7uDlk for ; Wed, 29 Jul 2009 05:14:45 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id 3FF353A6FF4 for ; Wed, 29 Jul 2009 05:14:45 -0700 (PDT) Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KNJ000T9M0K42@szxga01-in.huawei.com> for decade@ietf.org; Wed, 29 Jul 2009 20:14:45 +0800 (CST) Received: from huawei.com ([172.24.1.6]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KNJ004BYM0KO2@szxga01-in.huawei.com> for decade@ietf.org; Wed, 29 Jul 2009 20:14:44 +0800 (CST) Received: from 975DEF9223E44C7 (dhcp-17c2.meeting.ietf.org [130.129.23.194]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KNJ005O8M0GWF@szxml02-in.huawei.com> for decade@ietf.org; Wed, 29 Jul 2009 20:14:44 +0800 (CST) Date: Wed, 29 Jul 2009 14:14:38 +0200 From: Song Haibin To: decade@ietf.org Message-id: <008701ca1046$273e2620$c2178182@975DEF9223E44C7> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: text/plain; charset=gb2312 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal Subject: [decade] DECADE Bar BOF X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2009 12:14:46 -0000 Hi all, Just to remind that the DECADE (DECoupled Application Data Enroute) Bar BOF will be held this evening from 8pm to 10pm, in Room 201. Here is the agenda for the meeting. 1. Agenda Bash 5min 2. Problem statement Haibin Song 20min 3. A Survey on Network Storage Ning Zong & Richard Alimi 30min 4. Sailor presentation Richard Alimi 25min 5. BrachCache presentation Yu-shun Wang 20min Welcome to join the meeting! BR, Haibin From lin.xiao@nsn.com Wed Jul 29 09:22:39 2009 Return-Path: X-Original-To: decade@core3.amsl.com Delivered-To: decade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 720D73A6CFB for ; Wed, 29 Jul 2009 09:22:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h28IYgs1tBfw for ; Wed, 29 Jul 2009 09:22:38 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id 67C3A3A6ECC for ; Wed, 29 Jul 2009 09:22:38 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n6TGMNaF022006 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 29 Jul 2009 18:22:24 +0200 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n6TGMN50021004; Wed, 29 Jul 2009 18:22:23 +0200 Received: from CNBEEXC007.nsn-intra.net ([10.159.192.12]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 29 Jul 2009 18:22:23 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 30 Jul 2009 00:22:18 +0800 Message-ID: <5D84FDD8D5DC8646B9F73CF1EFD1BFA495F7B9@CNBEEXC007.nsn-intra.net> In-Reply-To: <002a01ca0b34$94a4e580$0f0ca40a@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ppsp] DECADE Bar BOF Thread-Index: AcoLNJRWCfupf79bT9KLUFLQHEknxgFM8mCA References: <002a01ca0b34$94a4e580$0f0ca40a@china.huawei.com> From: "Xiao, Lin (NSN - CN/Beijing)" To: "ext Song Haibin" , X-OriginalArrivalTime: 29 Jul 2009 16:22:23.0523 (UTC) FILETIME=[C110D730:01CA1068] X-Mailman-Approved-At: Wed, 29 Jul 2009 10:39:46 -0700 Subject: Re: [decade] [ppsp] DECADE Bar BOF X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2009 16:22:39 -0000 =20 Hi Haibin, =20 Are there any slides available for downloading? BR Xiao Lin -----Original Message----- From: ppsp-bounces@ietf.org [mailto:ppsp-bounces@ietf.org] On Behalf Of ext Song Haibin Sent: Thursday, July 23, 2009 3:26 AM To: decade@ietf.org Cc: ppsp@ietf.org; p2psip@ietf.org; alto@ietf.org Subject: [ppsp] DECADE Bar BOF Dear all, The time poll result shows that most people will be available on Wednesday evening. So the DECADE Bar BOF will finally be held on Wednesday evening, from 8pm to 10pm. The place is Room 201. The draft agenda is as the following: 1. Agenda bash 5min =20 2. Problem statement Haibin Song 20min 3. Survey Ning Zong 30min 4. Sailor presentation Richard Alimi 20min 5. BrachCache presentation Yu-shun Wang 20min Welcome to join the meeting and lookforward to meeting you in Stockholm. Best Regards, Haibin Skype: alexsonghw _______________________________________________ ppsp mailing list ppsp@ietf.org https://www.ietf.org/mailman/listinfo/ppsp From huizhang@nec-labs.com Wed Jul 29 10:49:30 2009 Return-Path: X-Original-To: decade@core3.amsl.com Delivered-To: decade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 307503A6D3A for ; Wed, 29 Jul 2009 10:49:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NzOzAw4bIrNC for ; Wed, 29 Jul 2009 10:49:29 -0700 (PDT) Received: from mail.nec-labs.com (mail.nec-labs.com [138.15.200.209]) by core3.amsl.com (Postfix) with ESMTP id 409D23A6943 for ; Wed, 29 Jul 2009 10:49:29 -0700 (PDT) Received: from mail.nec-labs.com (localhost.localdomain [127.0.0.1]) by mail.nec-labs.com (8.14.3/8.13.7) with ESMTP id n6THnQLY024690 for ; Wed, 29 Jul 2009 13:49:26 -0400 Received: from mailer.nec-labs.com (mailer.nec-labs.com [138.15.108.3]) by mail.nec-labs.com (8.14.3/8.14.3) with ESMTP id n6THnQJo024685; Wed, 29 Jul 2009 13:49:26 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Wed, 29 Jul 2009 13:49:29 -0400 Message-ID: <951A499AA688EF47A898B45F25BD8EE8068DF76F@mailer.nec-labs.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [decade] [ppsp] DECADE Bar BOF thread-index: AcoLNJRWCfupf79bT9KLUFLQHEknxgFM8mCAAAMg85A= References: <002a01ca0b34$94a4e580$0f0ca40a@china.huawei.com> <5D84FDD8D5DC8646B9F73CF1EFD1BFA495F7B9@CNBEEXC007.nsn-intra.net> From: "Hui Zhang" To: "Xiao, Lin \(NSN - CN/Beijing\)" , "ext Song Haibin" , Subject: Re: [decade] [ppsp] DECADE Bar BOF X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2009 17:49:30 -0000 Same query from me. Thanks, Hui -----Original Message----- From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.org] On Behalf Of Xiao, Lin (NSN - CN/Beijing) Sent: Wednesday, July 29, 2009 12:22 PM To: ext Song Haibin; decade@ietf.org Subject: Re: [decade] [ppsp] DECADE Bar BOF =20 Hi Haibin, =20 Are there any slides available for downloading? BR Xiao Lin -----Original Message----- From: ppsp-bounces@ietf.org [mailto:ppsp-bounces@ietf.org] On Behalf Of ext Song Haibin Sent: Thursday, July 23, 2009 3:26 AM To: decade@ietf.org Cc: ppsp@ietf.org; p2psip@ietf.org; alto@ietf.org Subject: [ppsp] DECADE Bar BOF Dear all, The time poll result shows that most people will be available on Wednesday evening. So the DECADE Bar BOF will finally be held on Wednesday evening, from 8pm to 10pm. The place is Room 201. The draft agenda is as the following: 1. Agenda bash 5min =20 2. Problem statement Haibin Song 20min 3. Survey Ning Zong 30min 4. Sailor presentation Richard Alimi 20min 5. BrachCache presentation Yu-shun Wang 20min Welcome to join the meeting and lookforward to meeting you in Stockholm. Best Regards, Haibin Skype: alexsonghw _______________________________________________ ppsp mailing list ppsp@ietf.org https://www.ietf.org/mailman/listinfo/ppsp _______________________________________________ decade mailing list decade@ietf.org https://www.ietf.org/mailman/listinfo/decade From melodysong@huawei.com Wed Jul 29 16:17:10 2009 Return-Path: X-Original-To: decade@core3.amsl.com Delivered-To: decade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 992BA3A69DE for ; Wed, 29 Jul 2009 16:17:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sUGzYV2c9ck2 for ; Wed, 29 Jul 2009 16:17:09 -0700 (PDT) Received: from szxga02-in.huawei.com (unknown [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id BB1303A698C for ; Wed, 29 Jul 2009 16:17:09 -0700 (PDT) Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KNK0032CGOA2R@szxga02-in.huawei.com> for decade@ietf.org; Thu, 30 Jul 2009 07:16:58 +0800 (CST) Received: from huawei.com ([172.17.1.31]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KNK00NY5GOA4Q@szxga02-in.huawei.com> for decade@ietf.org; Thu, 30 Jul 2009 07:16:58 +0800 (CST) Received: from [172.24.1.6] (Forwarded-For: [77.241.97.116]) by szxmc03-in.huawei.com (mshttpd); Thu, 30 Jul 2009 01:16:58 +0200 Date: Thu, 30 Jul 2009 01:16:58 +0200 From: songhaibin 64081 In-reply-to: <951A499AA688EF47A898B45F25BD8EE8068DF76F@mailer.nec-labs.com> To: Hui Zhang Message-id: MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 2.14 (built Aug 8 2006) Content-type: text/plain; charset=us-ascii Content-language: zh-CN Content-transfer-encoding: 7BIT Content-disposition: inline X-Accept-Language: zh-CN Priority: normal References: <002a01ca0b34$94a4e580$0f0ca40a@china.huawei.com> <5D84FDD8D5DC8646B9F73CF1EFD1BFA495F7B9@CNBEEXC007.nsn-intra.net> <951A499AA688EF47A898B45F25BD8EE8068DF76F@mailer.nec-labs.com> Cc: "Xiao, Lin \(NSN - CN/Beijing\)" , decade@ietf.org Subject: Re: [decade] [ppsp] DECADE Bar BOF X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2009 23:17:10 -0000 Hi Hui and Lin, I don't want to send large files to the mailing list. I will try to upload the slides on some webpage, and send a link of these slides to the mailing list soon. Sorry for the delay. Best Regards, Haibin > Same query from me. > > Thanks, > > Hui > > -----Original Message----- > From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.org] On > BehalfOf Xiao, Lin (NSN - CN/Beijing) > Sent: Wednesday, July 29, 2009 12:22 PM > To: ext Song Haibin; decade@ietf.org > Subject: Re: [decade] [ppsp] DECADE Bar BOF > > > Hi Haibin, > > Are there any slides available for downloading? > > BR > Xiao Lin > > > > -----Original Message----- > From: ppsp-bounces@ietf.org [mailto:ppsp-bounces@ietf.org] On > Behalf Of > ext Song Haibin > Sent: Thursday, July 23, 2009 3:26 AM > To: decade@ietf.org > Cc: ppsp@ietf.org; p2psip@ietf.org; alto@ietf.org > Subject: [ppsp] DECADE Bar BOF > > Dear all, > > The time poll result shows that most people will be available on > Wednesday evening. So the DECADE Bar BOF will finally be held on > Wednesday evening, from 8pm to 10pm. The place is Room 201. The draft > agenda is as the > following: > > 1. Agenda bash 5min > 2. Problem statement Haibin Song 20min > 3. Survey Ning Zong 30min > 4. Sailor presentation Richard Alimi 20min > 5. BrachCache presentation Yu-shun Wang 20min > > Welcome to join the meeting and lookforward to meeting you in > Stockholm. > > > > Best Regards, > Haibin > Skype: alexsonghw > > > > _______________________________________________ > ppsp mailing list > ppsp@ietf.org > https://www.ietf.org/mailman/listinfo/ppsp > _______________________________________________ > decade mailing list > decade@ietf.org > https://www.ietf.org/mailman/listinfo/decade > From Yu-Shun.Wang@microsoft.com Thu Jul 30 00:52:15 2009 Return-Path: X-Original-To: decade@core3.amsl.com Delivered-To: decade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 572373A6E47 for ; Thu, 30 Jul 2009 00:52:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ym07AC62xtS6 for ; Thu, 30 Jul 2009 00:52:14 -0700 (PDT) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id 957473A6AFC for ; Thu, 30 Jul 2009 00:52:14 -0700 (PDT) Received: from TK5EX14HUBC103.redmond.corp.microsoft.com (157.54.86.9) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.99.4; Thu, 30 Jul 2009 00:52:16 -0700 Received: from TK5EX14MBXC112.redmond.corp.microsoft.com ([169.254.5.236]) by TK5EX14HUBC103.redmond.corp.microsoft.com ([157.54.86.9]) with mapi; Thu, 30 Jul 2009 00:52:16 -0700 From: Yu-Shun Wang To: "decade@ietf.org" Thread-Topic: DECADE Bar BOF follow up Thread-Index: AcoQ6qb580Jj9NwPRTygUJCng76MRQ== Date: Thu, 30 Jul 2009 07:52:14 +0000 Message-ID: <81E94869FA91394CB0D6408786148E9B10471264@TK5EX14MBXC112.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [decade] DECADE Bar BOF follow up X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2009 07:52:15 -0000 Hi Everyone, First of all, thanks for coming and for a productive discussion. I think it's fair to say that there are problems in this space that IETF can and should consider, and also that there are interests among the participants to work on the problems. But there are also issues that we definitely should address in order to move toward a working group. Just to list some high level points here: - in depth investigation on prior work (also justification on new work) - applicability - benefit - incentives - some statement on layer 8 issues, esp. on potential deployment hurdles - ... Some logistics. - Slide decks: Alexey mentioned last night after the BoF for us to send the slides to him, and (presumably) Alexey will find some place to post the materials, maybe a page on the wiki? And yes, the slide deck, at least the BranchCache one, is pretty big (6MB) due to the animations and diagrams. I'll try to condense it a bit before posting it. - Minutes: Haibing and I will combine the minutes and send it to the list. The chairs would also like to thank Linda and Roni for volunteering as note takers. Next steps: Let's continue the discussion on list. Or send a note to Haibing and I if you are interested on certain aspects of the problems. We would very much like to shoot for an official BoF for the next IETF. (And get out of early/late Bar BoFs!) Thanks, Haiging and Yushun From zongning@huawei.com Thu Jul 30 04:09:24 2009 Return-Path: X-Original-To: decade@core3.amsl.com Delivered-To: decade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 69E833A68D7 for ; Thu, 30 Jul 2009 04:09:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.719 X-Spam-Level: X-Spam-Status: No, score=-99.719 tagged_above=-999 required=5 tests=[AWL=0.526, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_84=0.6, MIME_BASE64_TEXT=1.753, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Al6CRdqL0ibh for ; Thu, 30 Jul 2009 04:09:23 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id F2C353A6A20 for ; Thu, 30 Jul 2009 04:08:58 -0700 (PDT) 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 <0KNL00023DMY34@szxga04-in.huawei.com> for decade@ietf.org; Thu, 30 Jul 2009 19:08:59 +0800 (CST) Received: from huawei.com ([172.24.1.3]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KNL0095TDMYEH@szxga04-in.huawei.com> for decade@ietf.org; Thu, 30 Jul 2009 19:08:58 +0800 (CST) Received: from z-20684ca876cc4 (dhcp-14d2.meeting.ietf.org [130.129.20.210]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KNL00MB8DMRWF@szxml01-in.huawei.com> for decade@ietf.org; Thu, 30 Jul 2009 19:08:58 +0800 (CST) Date: Thu, 30 Jul 2009 13:09:02 +0200 From: Ning Zong To: decade Message-id: <0KNL00MBADMWWF@szxml01-in.huawei.com> MIME-version: 1.0 X-Mailer: Foxmail 5.0 [en] Content-type: multipart/alternative; boundary="Boundary_(ID_DncGIWNH3VsOSXjsIgUaiQ)" Subject: [decade] Fw: [ppsp] updated agenda of PPSP Bar BOF X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2009 11:09:24 -0000 This is a multi-part message in MIME format. --Boundary_(ID_DncGIWNH3VsOSXjsIgUaiQ) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: base64 DQoNCiAgDQpIaSxhbGwsDQogICBUaGUgUFBTUCAoUDJQIHN0cmVhbWluZyBwcm90b2NvbCkgZmlu YWwgYmFyIGJvZiBhZ2VuZGEgaXMgdXBkYXRlZCBhcyBmb2xsb3dzLiBXZSBjaGFuZ2UgYSBsaXR0 bGUgdGhlIG9yZGVyIG9mIHRoZSBwcmVzZW50YXRpb24gdG8gbWFrZSB0aGUgcHJvYmxlbSBkaXNj dXNzaW9uIG1vcmUgY29uc2lzdGVudC5Bbnkgc3VnZ2VzdGlvbnMgYW5kIGNvbnRyaWJ1dGlvbnMg YXJlIHdlbGNvbWUuDQogICANCiAgUFBTUCBGaW5hbCBCYXIgQm9GLS0gSUVURiA3NSwgU3RvY2to b2xtDQogIDIwMDAtMjIwMCBUaHVyc2RheSxKdWx5IDMwLFJvb20gMzAwLiANCiAgTWFpbGluZyBs aXN0o7pwcHNwQGlldGYub3JnIGh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9w cHNwDQogIENoYWlyOiBZdW5mZWkgWmhhbmcoIHpoYW5neXVuZmVpQGNoaW5hbW9iaWxlLmNvbSkN CiAgICAgICAgICAgIEdvbnphbG8gQ2FtYXJpbGxvICggZ29uemFsby5jYW1hcmlsbG9AZXJpY3Nz b24uY29tKQ0KICAgICAgICAgICAgTmluZyBab25nKHpvbmduaW5nQGh1YXdlaS5jb20pDQogICBB RDogTGFycyBFZ2dlcnQoIGxhcnMuZWdnZXJ0QG5va2lhLmNvbSkgDQogIA0KICANCiAgDQogDQpB Z2VuZGENCjEuIEFnZW5kYSBiYXNoaW5nICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKENoYWlyLDUnKSAgDQoNCjIu IFNob3J0IEludHJvZHVjdGlvbiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIChDaGFpciw1JykNCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIA0KMy4gUHJvYmxlbSBTdGF0ZW1lbnQgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIChZdW5mZWkgWmhhbmcsIDQwJykNCiAgIGRyYWZ0 LXpoYW5nLXBwc3AtcHJvYmxlbS1zdGF0ZW1lbnQtMDQgDQoNCiANCjQuIFNvbHV0aW9uIGFuZCBz dXJ2ZXkgZHJhZnRzIA0KIC0tLS1DaHVuayBEaXNjb3ZlcnkgZm9yIFAyUCBTdHJlYW1pbmcgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIChOaW5nIFpvbmcsIDIwoa8pIA0KICAgICAgICBk cmFmdC16b25nLXBwc3AtY2h1bmstZGlzY292ZXJ5LTAwIA0KDQogLS0tLSBQcm90b2NvbCBBbmFs eXNpcyBvZiBQUGxpdmUsIFBQU3RyZWFtIGFuZCBVVVNlZSBieSBJbnRlcmVudCBNZWFzdXJlbWVu dCAgICAgICAgICAgICAgICAgICAgICAgICAgIChZdW5mZWkgWmhhbmcsMTAnKQ0KICAgICAgICAg ZHJhZnQtemhhbmctcHBzcC1wcm90b2NvbC1jb21wYXJpc29uLW1lYXN1cmVtZW50LTAyIA0KDQo1 LiBEaXNjdXNzaW9uICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIChBbGwsIDMwJykNCiANCjYuIERlY2lzaW9u cyBhbmQgSFVNcyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIChBbGwsIDUnKQ0KIA0KNy4gQ29uY2x1c2lvbnMgYW5kIE5leHQgU3RlcHMg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIChDaGFpcnMv QURzLCA1JykgICANCg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg QlINCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFl1bmZlaQ0KDQoN Cg0KDQp6aGFuZ3l1bmZlaQ0KMjAwOS0wNy0yOA0K --Boundary_(ID_DncGIWNH3VsOSXjsIgUaiQ) Content-type: text/html; charset=gb2312 Content-transfer-encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MIHhtbG5zOm8geG1sbnM6c3QxPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1D b250ZW50LVR5cGUgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWdiMjMxMiI+DQo8TUVUQSBj b250ZW50PSJNU0hUTUwgNi4wMC42MDAwLjE2ODA5IiBuYW1lPUdFTkVSQVRPUj48L0hFQUQ+DQo8 Qk9EWT4NCjxIUj4NCg0KPERJVj48Rk9OVCBmYWNlPVZlcmRhbmEgc2l6ZT0yPjxGT05UIGNvbG9y PSMwMDAwMDA+Jm5ic3A7PC9GT05UPiANCjxESVY+PEZPTlQgZmFjZT1WZXJkYW5hIHNpemU9Mj48 Rk9OVCBmYWNlPVZlcmRhbmEgc2l6ZT0yPg0KPERJVj4NCjxESVY+PEZPTlQgZmFjZT1WZXJkYW5h PjxGT05UIGNvbG9yPSMwMDAwMDAgc2l6ZT0yPjwvRk9OVD48L0ZPTlQ+PC9ESVY+PEZPTlQgDQpm YWNlPVZlcmRhbmEgc2l6ZT0yPjwvRk9OVD48L0RJVj48Rk9OVCBmYWNlPVZlcmRhbmEgc2l6ZT0y PjxGT05UIA0KZmFjZT1WZXJkYW5hPjxGT05UIHNpemU9Mj48U1BBTiBsYW5nPUVOLVVTIHN0eWxl PSJGT05ULVNJWkU6IDEycHQiPjxGT05UIA0KZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48Rk9OVCAN CmNvbG9yPSMwMDAwMDA+SGksYWxsLDxvOnA+PC9vOnA+PC9GT05UPjwvRk9OVD48L1NQQU4+PC9E SVY+DQo8RElWPg0KPERJVj4NCjxESVY+DQo8RElWPg0KPFAgY2xhc3M9TXNvTm9ybWFsIHN0eWxl PSJNQVJHSU46IDBjbSAwY20gMHB0Ij48U1BBTiBsYW5nPUVOLVVTIA0Kc3R5bGU9IkZPTlQtU0la RTogMTJwdCI+PEZPTlQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48Rk9OVCBjb2xvcj0jMDAwMDAw PjxTUEFOIA0Kc3R5bGU9Im1zby1zcGFjZXJ1bjogeWVzIj4mbmJzcDsmbmJzcDsgPC9TUEFOPlRo ZSBQUFNQIChQMlAgc3RyZWFtaW5nIHByb3RvY29sKSANCmZpbmFsIGJhciBib2YgYWdlbmRhIGlz IHVwZGF0ZWQgYXMgZm9sbG93cy4gV2UgY2hhbmdlIGEgbGl0dGxlIHRoZSBvcmRlciBvZiB0aGUg DQpwcmVzZW50YXRpb24gdG8gbWFrZSB0aGUgcHJvYmxlbSZuYnNwO2Rpc2N1c3Npb24gbW9yZSBj b25zaXN0ZW50LkFueSBzdWdnZXN0aW9ucyANCmFuZCBjb250cmlidXRpb25zIGFyZSB3ZWxjb21l LjxvOnA+PC9vOnA+PC9GT05UPjwvRk9OVD48L1NQQU4+PC9QPg0KPFAgY2xhc3M9TXNvTm9ybWFs IHN0eWxlPSJNQVJHSU46IDBjbSAwY20gMHB0Ij48U1BBTiBsYW5nPUVOLVVTIA0Kc3R5bGU9IkZP TlQtU0laRTogMTJwdCI+PEZPTlQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48Rk9OVCBjb2xvcj0j MDAwMDAwPjxTUEFOIA0Kc3R5bGU9Im1zby1zcGFjZXJ1bjogeWVzIj4mbmJzcDsmbmJzcDsgDQo8 L1NQQU4+PG86cD48L286cD48L0ZPTlQ+PC9GT05UPjwvU1BBTj48L1A+DQo8UCBjbGFzcz1Nc29O b3JtYWwgc3R5bGU9Ik1BUkdJTjogMGNtIDBjbSAwcHQiPjxTUEFOIGxhbmc9RU4tVVMgDQpzdHls ZT0iRk9OVC1TSVpFOiAxMnB0Ij48Rk9OVCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxGT05UIA0K Y29sb3I9IzAwMDAwMD4mbmJzcDsmbmJzcDtQUFNQIEZpbmFsIEJhciBCb0YtLSBJRVRGIDc1LCA8 c3QxOkNpdHkgDQp3OnN0PSJvbiI+PHN0MTpwbGFjZSANCnc6c3Q9Im9uIj5TdG9ja2hvbG08L3N0 MTpwbGFjZT48L3N0MTpDaXR5PjxvOnA+PC9vOnA+PC9GT05UPjwvRk9OVD48L1NQQU4+PC9QPg0K PFAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSJNQVJHSU46IDBjbSAwY20gMHB0Ij48U1BBTiBsYW5n PUVOLVVTIA0Kc3R5bGU9IkZPTlQtU0laRTogMTJwdCI+PEZPTlQgZmFjZT0iVGltZXMgTmV3IFJv bWFuIj48Rk9OVCBjb2xvcj0jMDAwMDAwPjxTUEFOIA0Kc3R5bGU9Im1zby1zcGFjZXJ1bjogeWVz Ij4mbmJzcDsgPC9TUEFOPjIwMDAtMjIwMCBUaHVyc2RheSxKdWx5IDMwLFJvb20gMzAwLiANCjxv OnA+PC9vOnA+PC9GT05UPjwvRk9OVD48L1NQQU4+PC9QPg0KPFAgY2xhc3M9TXNvTm9ybWFsIHN0 eWxlPSJNQVJHSU46IDBjbSAwY20gMHB0Ij48Rk9OVCBjb2xvcj0jMDAwMDAwPjxTUEFOIA0KbGFu Zz1FTi1VUyBzdHlsZT0iRk9OVC1TSVpFOiAxMnB0Ij48Rk9OVCBmYWNlPSJUaW1lcyBOZXcgUm9t YW4iPjxTUEFOIA0Kc3R5bGU9Im1zby1zcGFjZXJ1bjogeWVzIj4mbmJzcDsgPC9TUEFOPk1haWxp bmcgbGlzdDwvRk9OVD48L1NQQU4+PFNQQU4gDQpzdHlsZT0iRk9OVC1TSVpFOiAxMnB0OyBGT05U LUZBTUlMWTogy87M5TsgbXNvLWFzY2lpLWZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJzsg bXNvLWhhbnNpLWZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJyI+o7o8L1NQQU4+PFNQQU4g DQpsYW5nPUVOLVVTIHN0eWxlPSJGT05ULVNJWkU6IDEycHQiPjxGT05UIGZhY2U9IlRpbWVzIE5l dyBSb21hbiI+cHBzcEBpZXRmLm9yZyA8QSANCmhyZWY9Imh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9wcHNwIj5odHRwOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v cHBzcDwvQT48L0ZPTlQ+PC9TUEFOPjwvRk9OVD48L1A+DQo8UCBjbGFzcz1Nc29Ob3JtYWwgc3R5 bGU9Ik1BUkdJTjogMGNtIDBjbSAwcHQiPjxTUEFOIGxhbmc9RU4tVVMgDQpzdHlsZT0iRk9OVC1T SVpFOiAxMnB0Ij48Rk9OVCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxGT05UIGNvbG9yPSMwMDAw MDA+Jm5ic3A7IA0KQ2hhaXI6IFl1bmZlaSBaaGFuZyggPC9GT05UPjxBIGhyZWY9Im1haWx0bzp6 aGFuZ3l1bmZlaUBjaGluYW1vYmlsZS5jb20iPjxGT05UIA0KY29sb3I9IzAwMDAwMD56aGFuZ3l1 bmZlaUBjaGluYW1vYmlsZS5jb208L0ZPTlQ+PC9BPjxGT05UIA0KY29sb3I9IzAwMDAwMD4pPC9G T05UPjwvRk9OVD48L1NQQU4+PC9QPg0KPFAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSJNQVJHSU46 IDBjbSAwY20gMHB0Ij48U1BBTiBsYW5nPUVOLVVTIA0Kc3R5bGU9IkZPTlQtU0laRTogMTJwdCI+ PEZPTlQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48Rk9OVCANCmNvbG9yPSMwMDAwMDA+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IA0KR29uemFsbyBDYW1hcmlsbG8gPFU+KCZuYnNwOzwvVT48L0ZPTlQ+PEEgDQpocmVmPSJt YWlsdG86Z29uemFsby5jYW1hcmlsbG9AZXJpY3Nzb24uY29tIj48Rk9OVCANCmNvbG9yPSMwMDAw MDA+Z29uemFsby5jYW1hcmlsbG9AZXJpY3Nzb24uY29tPC9GT05UPjwvQT48Rk9OVCANCmNvbG9y PSMwMDAwMDA+KTwvRk9OVD48L0ZPTlQ+PC9TUEFOPjwvUD4NCjxQIGNsYXNzPU1zb05vcm1hbCBz dHlsZT0iTUFSR0lOOiAwY20gMGNtIDBwdCI+PFNQQU4gbGFuZz1FTi1VUyANCnN0eWxlPSJGT05U LVNJWkU6IDEycHQiPjxGT05UIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PEZPTlQgDQpjb2xvcj0j MDAwMDAwPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyANCk5pbmcgWm9uZyg8L0ZPTlQ+PEEgaHJlZj0ibWFpbHRvOnpvbmdu aW5nQGh1YXdlaS5jb20iPjxGT05UIA0KY29sb3I9IzAwMDAwMD56b25nbmluZ0BodWF3ZWkuY29t PC9GT05UPjwvQT48Rk9OVCANCmNvbG9yPSMwMDAwMDA+KTwvRk9OVD48L0ZPTlQ+PC9TUEFOPjwv UD4NCjxQIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0iTUFSR0lOOiAwY20gMGNtIDBwdCI+PFNQQU4g bGFuZz1FTi1VUyANCnN0eWxlPSJGT05ULVNJWkU6IDEycHQiPjxGT05UIGZhY2U9IlRpbWVzIE5l dyBSb21hbiIgY29sb3I9IzAwMDAwMD4mbmJzcDsmbmJzcDsgDQpBRDogTGFycyBFZ2dlcnQoJm5i c3A7PC9GT05UPjxBIGhyZWY9Im1haWx0bzpsYXJzLmVnZ2VydEBub2tpYS5jb20iPjxGT05UIA0K ZmFjZT0iVGltZXMgTmV3IFJvbWFuIiBjb2xvcj0jMDAwMDAwPmxhcnMuZWdnZXJ0QG5va2lhLmNv bTwvRk9OVD48L0E+PEZPTlQgDQpjb2xvcj0jMDAwMDAwPikmbmJzcDs8L0ZPTlQ+PC9TUEFOPjwv UD4NCjxQIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0iTUFSR0lOOiAwY20gMGNtIDBwdCI+PFNQQU4g bGFuZz1FTi1VUyANCnN0eWxlPSJGT05ULVNJWkU6IDEycHQiPjxGT05UIGZhY2U9IlRpbWVzIE5l dyBSb21hbiIgY29sb3I9IzAwMDAwMD4mbmJzcDsgDQo8L0ZPTlQ+PC9TUEFOPjwvUD48L0RJVj48 L0RJVj48L0RJVj48L0RJVj48L0ZPTlQ+PC9GT05UPjwvRk9OVD48L0ZPTlQ+PC9GT05UPjwvRk9O VD48Rk9OVCANCmZhY2U9VmVyZGFuYSBzaXplPTI+PEZPTlQgZmFjZT1WZXJkYW5hPjxGT05UIHNp emU9Mj48Rk9OVCBmYWNlPVZlcmRhbmEgDQpzaXplPTI+PEZPTlQgZmFjZT1WZXJkYW5hIHNpemU9 Mj48Rk9OVCBmYWNlPVZlcmRhbmEgc2l6ZT0yPjxGT05UIA0KZmFjZT1WZXJkYW5hPjxGT05UIHNp emU9Mj48U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJGT05ULVNJWkU6IDEycHQiPjxGT05UIA0KZmFj ZT0iVGltZXMgTmV3IFJvbWFuIiBjb2xvcj0jMDAwMDAwPiZuYnNwOyA8L0ZPTlQ+PC9TUEFOPjwv RElWPg0KPERJVj4NCjxESVY+DQo8RElWPg0KPERJVj4NCjxESVY+DQo8RElWPg0KPFAgY2xhc3M9 TXNvTm9ybWFsIHN0eWxlPSJNQVJHSU46IDBjbSAwY20gMHB0Ij48U1BBTiBsYW5nPUVOLVVTIA0K c3R5bGU9IkZPTlQtU0laRTogMTJwdCI+PEZPTlQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48Rk9O VCBjb2xvcj0jMDAwMDAwPiZuYnNwOyANCjxvOnA+PC9vOnA+PC9GT05UPjwvRk9OVD48L1NQQU4+ PC9QPg0KPFAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSJNQVJHSU46IDBjbSAwY20gMHB0Ij48U1BB TiBsYW5nPUVOLVVTIA0Kc3R5bGU9IkZPTlQtU0laRTogMTJwdCI+PEZPTlQgZmFjZT0iVGltZXMg TmV3IFJvbWFuIj48Rk9OVCBjb2xvcj0jMDAwMDAwPjxTUEFOIA0Kc3R5bGU9Im1zby1zcGFjZXJ1 bjogeWVzIj4mbmJzcDs8L1NQQU4+PG86cD48L286cD48L0ZPTlQ+PC9GT05UPjwvU1BBTj48L1A+ DQo8UCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9Ik1BUkdJTjogMGNtIDBjbSAwcHQiPjxTUEFOIGxh bmc9RU4tVVMgDQpzdHlsZT0iRk9OVC1TSVpFOiAxMnB0Ij48Rk9OVCBmYWNlPSJUaW1lcyBOZXcg Um9tYW4iPjxGT05UIA0KY29sb3I9IzAwMDAwMD5BZ2VuZGE8bzpwPjwvbzpwPjwvRk9OVD48L0ZP TlQ+PC9TUEFOPjwvUD4NCjxQIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0iTUFSR0lOOiAwY20gMGNt IDBwdCI+PFNQQU4gbGFuZz1FTi1VUyANCnN0eWxlPSJGT05ULVNJWkU6IDEycHQiPjxGT05UIGZh Y2U9IlRpbWVzIE5ldyBSb21hbiI+PEZPTlQgY29sb3I9IzAwMDAwMD4xLiANCkFnZW5kYSBiYXNo aW5nPFNQQU4gc3R5bGU9Im1zby1zcGFjZXJ1bjogeWVzIj4mbmJzcDsmbmJzcDsmbmJzcDs8L1NQ QU4+PFNQQU4gDQpzdHlsZT0ibXNvLXNwYWNlcnVuOiB5ZXMiPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCiZuYnNwOzwvU1BBTj4o Q2hhaXIsNScpPFNQQU4gDQpzdHlsZT0ibXNvLXNwYWNlcnVuOiB5ZXMiPiZuYnNwOyZuYnNwOzwv U1BBTj48L0ZPTlQ+PC9GT05UPjwvU1BBTj48L1A+DQo8UCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9 Ik1BUkdJTjogMGNtIDBjbSAwcHQiPjxTUEFOIGxhbmc9RU4tVVMgDQpzdHlsZT0iRk9OVC1TSVpF OiAxMnB0Ij48Rk9OVCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iIGNvbG9yPSMwMDAwMDA+PFNQQU4g DQpzdHlsZT0ibXNvLXNwYWNlcnVuOiB5ZXMiPjwvU1BBTj48L0ZPTlQ+PC9TUEFOPiZuYnNwOzwv UD4NCjxQIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0iTUFSR0lOOiAwY20gMGNtIDBwdCI+PFNQQU4g bGFuZz1FTi1VUyANCnN0eWxlPSJGT05ULVNJWkU6IDEycHQiPjxGT05UIGZhY2U9IlRpbWVzIE5l dyBSb21hbiIgY29sb3I9IzAwMDAwMD48U1BBTiANCnN0eWxlPSJtc28tc3BhY2VydW46IHllcyI+ Mi4gU2hvcnQgDQpJbnRyb2R1Y3Rpb24mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQooQ2hhaXIsNScpPC9TUEFOPjwvRk9O VD48L1NQQU4+PC9QPg0KPFAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSJNQVJHSU46IDBjbSAwY20g MHB0Ij48U1BBTiBsYW5nPUVOLVVTIA0Kc3R5bGU9IkZPTlQtU0laRTogMTJwdCI+PEZPTlQgZmFj ZT0iVGltZXMgTmV3IFJvbWFuIj48Rk9OVCBjb2xvcj0jMDAwMDAwPjxTUEFOIA0Kc3R5bGU9Im1z by1zcGFjZXJ1bjogeWVzIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQo8L1NQQU4+PG86cD48L286cD48L0ZPTlQ+PC9GT05U PjwvU1BBTj48L1A+DQo8UCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9Ik1BUkdJTjogMGNtIDBjbSAw cHQiPjxTUEFOIGxhbmc9RU4tVVMgDQpzdHlsZT0iRk9OVC1TSVpFOiAxMnB0Ij48Rk9OVCBmYWNl PSJUaW1lcyBOZXcgUm9tYW4iPjxGT05UIGNvbG9yPSMwMDAwMDA+My4gDQpQcm9ibGVtIFN0YXRl bWVudDxTUEFOIA0Kc3R5bGU9Im1zby1zcGFjZXJ1bjogeWVzIj4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDs8L1NQQU4+PFNQQU4gDQpzdHlsZT0ibXNvLXNwYWNlcnVuOiB5ZXMiPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOzwvU1BBTj48U1BBTiANCnN0eWxlPSJtc28tc3BhY2VydW46IHllcyI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 PC9TUEFOPihZdW5mZWkgDQpaaGFuZywgNDAnKTxvOnA+PC9vOnA+PC9GT05UPjwvRk9OVD48L1NQ QU4+PC9QPg0KPFAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSJNQVJHSU46IDBjbSAwY20gMHB0Ij48 Rk9OVCBjb2xvcj0jMDAwMDAwPjxTUEFOIA0KbGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1TSVpFOiAx MnB0Ij48Rk9OVCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxTUEFOIA0Kc3R5bGU9Im1zby1zcGFj ZXJ1bjogeWVzIj4mbmJzcDsmbmJzcDsmbmJzcDs8L1NQQU4+ZHJhZnQtemhhbmctcHBzcC1wcm9i bGVtLXN0YXRlbWVudC0wNDwvRk9OVD48L1NQQU4+PFNQQU4gDQpsYW5nPUVOLVVTIHN0eWxlPSJG T05ULVNJWkU6IDEycHQiPjxGT05UIA0KZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48bzpwPjwvbzpw PjwvRk9OVD48L1NQQU4+Jm5ic3A7PC9GT05UPjwvUD4NCjxQIGNsYXNzPU1zb05vcm1hbCBzdHls ZT0iTUFSR0lOOiAwY20gMGNtIDBwdCI+PEZPTlQgDQpjb2xvcj0jMDAwMDAwPjwvRk9OVD4mbmJz cDs8L1A+DQo8UCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9Ik1BUkdJTjogMGNtIDBjbSAwcHQiPjxT UEFOIA0Kc3R5bGU9IkZPTlQtU0laRTogMTJwdDsgRk9OVC1GQU1JTFk6IMvOzOU7IG1zby1hc2Np aS1mb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbic7IG1zby1oYW5zaS1mb250LWZhbWlseTog J1RpbWVzIE5ldyBSb21hbiciPjwvU1BBTj48U1BBTiANCmxhbmc9RU4tVVMgc3R5bGU9IkZPTlQt U0laRTogMTJwdCI+PG86cD48L286cD48L1NQQU4+PEZPTlQgDQpjb2xvcj0jMDAwMDAwPiZuYnNw OzwvRk9OVD48L1A+DQo8UCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9Ik1BUkdJTjogMGNtIDBjbSAw cHQiPjxTUEFOIGxhbmc9RU4tVVMgDQpzdHlsZT0iRk9OVC1TSVpFOiAxMnB0Ij48Rk9OVCBmYWNl PSJUaW1lcyBOZXcgUm9tYW4iIGNvbG9yPSMwMDAwMDA+NC4gU29sdXRpb24gDQphbmQgc3VydmV5 IGRyYWZ0cyZuYnNwOzwvRk9OVD48L1NQQU4+PC9QPg0KPFAgY2xhc3M9TXNvTm9ybWFsIHN0eWxl PSJNQVJHSU46IDBjbSAwY20gMHB0Ij48U1BBTiBsYW5nPUVOLVVTIA0Kc3R5bGU9IkZPTlQtU0la RTogMTJwdCI+PC9TUEFOPjxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9IkZPTlQtU0laRTogMTJwdCI+ PEZPTlQgDQpmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxGT05UIGNvbG9yPSMwMDAwMDA+Jm5ic3A7 LS0tLUNodW5rIERpc2NvdmVyeSBmb3IgUDJQIA0KU3RyZWFtaW5nJm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7KE5pbmcgDQpab25nLCA8c3QxOmNobWV0Y252IHc6c3Q9Im9uIiBVbml0TmFtZT0ioa8iIFNv dXJjZVZhbHVlPSIxMCIgSGFzU3BhY2U9IkZhbHNlIiANCk5lZ2F0aXZlPSJGYWxzZSIgTnVtYmVy VHlwZT0iMSIgVENTQz0iMCI+MjChrzwvc3QxOmNobWV0Y252PikgPC9GT05UPjwvUD4NCjxQIGNs YXNzPU1zb05vcm1hbCBzdHlsZT0iTUFSR0lOOiAwY20gMGNtIDBwdCI+PFNQQU4gbGFuZz1FTi1V UyANCnN0eWxlPSJGT05ULVNJWkU6IDEycHQiPjxGT05UIA0KY29sb3I9IzAwMDAwMD4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQpkcmFmdC16b25nLXBwc3AtY2h1 bmstZGlzY292ZXJ5LTAwJm5ic3A7PC9GT05UPjwvU1BBTj48L1A+DQo8UCBjbGFzcz1Nc29Ob3Jt YWwgc3R5bGU9Ik1BUkdJTjogMGNtIDBjbSAwcHQiPjxTUEFOIGxhbmc9RU4tVVMgDQpzdHlsZT0i Rk9OVC1TSVpFOiAxMnB0Ij48Rk9OVCANCmNvbG9yPSMwMDAwMDA+PC9GT05UPjwvU1BBTj4mbmJz cDs8L1A+PC9GT05UPjwvU1BBTj4NCjxQIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0iTUFSR0lOOiAw Y20gMGNtIDBwdCI+PFNQQU4gbGFuZz1FTi1VUyANCnN0eWxlPSJGT05ULVNJWkU6IDEycHQiPjxG T05UIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PEZPTlQgDQpjb2xvcj0jMDAwMDAwPiZuYnNwOy0t LS0gUHJvdG9jb2wgQW5hbHlzaXMgb2YgUFBsaXZlLCBQUFN0cmVhbSBhbmQgVVVTZWUgYnkgDQpJ bnRlcmVudCBNZWFzdXJlbWVudDxTUEFOIA0Kc3R5bGU9Im1zby1zcGFjZXJ1bjogeWVzIj4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQo8L1NQQU4+KFl1bmZlaSBa aGFuZywxMCcpPG86cD48L286cD48L0ZPTlQ+PC9GT05UPjwvU1BBTj48L1A+DQo8UCBjbGFzcz1N c29Ob3JtYWwgc3R5bGU9Ik1BUkdJTjogMGNtIDBjbSAwcHQiPjxTUEFOIGxhbmc9RU4tVVMgDQpz dHlsZT0iRk9OVC1TSVpFOiAxMnB0Ij48Rk9OVCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxGT05U IGNvbG9yPSMwMDAwMDA+PFNQQU4gDQpzdHlsZT0ibXNvLXNwYWNlcnVuOiB5ZXMiPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCjwvU1BBTj48U1BBTiBs YW5nPUVOLVVTIA0Kc3R5bGU9IkZPTlQtU0laRTogMTJwdCI+ZHJhZnQtemhhbmctcHBzcC1wcm90 b2NvbC1jb21wYXJpc29uLW1lYXN1cmVtZW50LTAyPC9TUEFOPjxTUEFOIA0KbGFuZz1FTi1VUyBz dHlsZT0iRk9OVC1TSVpFOiAxMnB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvU1BBTj48L0ZPTlQ+PC9Q Pg0KPFAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSJNQVJHSU46IDBjbSAwY20gMHB0Ij48U1BBTiBs YW5nPUVOLVVTIA0Kc3R5bGU9IkZPTlQtU0laRTogMTJwdCI+PEZPTlQgY29sb3I9IzAwMDAwMD48 L0ZPTlQ+PC9TUEFOPiZuYnNwOzwvUD4NCjxQIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0iTUFSR0lO OiAwY20gMGNtIDBwdCI+PFNQQU4gbGFuZz1FTi1VUyANCnN0eWxlPSJGT05ULVNJWkU6IDEycHQi PjwvU1BBTj48U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJGT05ULVNJWkU6IDEycHQiPjxGT05UIA0K Y29sb3I9IzAwMDAwMD41LjwvRk9OVD48L1NQQU4+PC9GT05UPjwvRk9OVD48L0ZPTlQ+PC9TUEFO PjxGT05UIA0KZmFjZT1WZXJkYW5hPjxGT05UIHNpemU9Mj48U1BBTiBsYW5nPUVOLVVTIA0Kc3R5 bGU9IkZPTlQtU0laRTogMTJwdDsgbXNvLWZvbnQta2VybmluZzogMHB0Ij48bzpwPjxGT05UIGZh Y2U9IlRpbWVzIE5ldyBSb21hbiIgDQpjb2xvcj0jMDAwMDAwPiZuYnNwO0Rpc2N1c3Npb24mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsoQWxs LCANCjMwJyk8L0ZPTlQ+PC9vOnA+PC9TUEFOPjwvRk9OVD48L0ZPTlQ+PC9QPg0KPFAgY2xhc3M9 TXNvTm9ybWFsIHN0eWxlPSJNQVJHSU46IDBjbSAwY20gMHB0Ij48Rk9OVCBmYWNlPVZlcmRhbmE+ PEZPTlQgDQpmYWNlPSJUaW1lcyBOZXcgUm9tYW4iIHNpemU9Mj48U1BBTiBsYW5nPUVOLVVTIA0K c3R5bGU9IkZPTlQtU0laRTogMTJwdDsgbXNvLWZvbnQta2VybmluZzogMHB0Ij48bzpwPjwvbzpw PjwvU1BBTj48L0ZPTlQ+PC9GT05UPjxGT05UIA0KY29sb3I9IzAwMDAwMD4mbmJzcDs8L0ZPTlQ+ PC9QPg0KPFAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSJNQVJHSU46IDBjbSAwY20gMHB0Ij48Rk9O VCBjb2xvcj0jMDAwMDAwPjxGT05UIA0KZmFjZT0iVGltZXMgTmV3IFJvbWFuIiBzaXplPTI+PFNQ QU4gbGFuZz1FTi1VUyANCnN0eWxlPSJGT05ULVNJWkU6IDEycHQ7IG1zby1mb250LWtlcm5pbmc6 IDBwdCI+PG86cD42LiBEZWNpc2lvbnMgDQo8L286cD48L1NQQU4+PC9GT05UPjxGT05UIGZhY2U9 VmVyZGFuYT48Rk9OVCBzaXplPTI+PFNQQU4gbGFuZz1FTi1VUyANCnN0eWxlPSJGT05ULVNJWkU6 IDEycHQ7IG1zby1mb250LWtlcm5pbmc6IDBwdCI+PEZPTlQgZmFjZT0iVGltZXMgTmV3IFJvbWFu Ij5hbmQgDQpIVU1zJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KKEFsbCwgNScpPC9GT05UPjwvU1BBTj48L0ZPTlQ+ PC9GT05UPjwvRk9OVD48L1A+DQo8UCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9Ik1BUkdJTjogMGNt IDBjbSAwcHQiPjxGT05UIGZhY2U9VmVyZGFuYT48Rk9OVCANCnNpemU9Mj48U1BBTiBsYW5nPUVO LVVTIHN0eWxlPSJGT05ULVNJWkU6IDEycHQ7IG1zby1mb250LWtlcm5pbmc6IDBwdCI+PEZPTlQg DQpmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxvOnA+PC9vOnA+PC9GT05UPjwvU1BBTj48Rk9OVCAN CmNvbG9yPSMwMDAwMDA+Jm5ic3A7PC9GT05UPjwvUD4NCjxQIGNsYXNzPU1zb05vcm1hbCANCnN0 eWxlPSJNQVJHSU46IDBjbSAwY20gMHB0OyBURVhULUFMSUdOOiBsZWZ0OyBtc28tcGFnaW5hdGlv bjogd2lkb3ctb3JwaGFuOyB0YWItc3RvcHM6IDQ1LjhwdCA5MS42cHQgMTM3LjRwdCAxODMuMnB0 IDIyOS4wcHQgMjc0LjhwdCAzMjAuNnB0IDM2Ni40cHQgNDEyLjJwdCA0NTguMHB0IDUwMy44cHQg NTQ5LjZwdCA1OTUuNHB0IDY0MS4ycHQgNjg3LjBwdCA3MzIuOHB0IiANCmFsaWduPWxlZnQ+PEZP TlQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48Rk9OVCBjb2xvcj0jMDAwMDAwPjxTUEFOIGxhbmc9 RU4tVVMgDQpzdHlsZT0iRk9OVC1TSVpFOiAxMnB0OyBtc28tZm9udC1rZXJuaW5nOiAwcHQiPjcu IENvbmNsdXNpb25zIGFuZCBOZXh0IA0KU3RlcHMmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsoQ2hhaXJzL0FEcywg DQo1JykmbmJzcDs8L1NQQU4+PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1TSVpFOiAxMnB0 Ij48U1BBTiANCnN0eWxlPSJtc28tc3BhY2VydW46IHllcyI+Jm5ic3A7Jm5ic3A7PC9TUEFOPjwv U1BBTj48L0ZPTlQ+PC9GT05UPjwvUD4NCjxQIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0iTUFSR0lO OiAwY20gMGNtIDBwdCI+PEZPTlQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIiANCmNvbG9yPSMwMDAw MDA+PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1TSVpFOiAxMnB0Ij48U1BBTiANCnN0eWxl PSJtc28tc3BhY2VydW46IHllcyI+PC9TUEFOPjwvU1BBTj48L0ZPTlQ+Jm5ic3A7PC9QPg0KPFAg Y2xhc3M9TXNvTm9ybWFsIHN0eWxlPSJNQVJHSU46IDBjbSAwY20gMHB0Ij48Rk9OVCBmYWNlPSJU aW1lcyBOZXcgUm9tYW4iIA0KY29sb3I9IzAwMDAwMD48U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJG T05ULVNJWkU6IDEycHQiPjxTUEFOIA0Kc3R5bGU9Im1zby1zcGFjZXJ1bjogeWVzIj48L1NQQU4+ PC9TUEFOPjwvRk9OVD4mbmJzcDs8L1A+DQo8UCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9Ik1BUkdJ TjogMGNtIDBjbSAwcHQiPjxGT05UIGZhY2U9IlRpbWVzIE5ldyBSb21hbiIgDQpjb2xvcj0jMDAw MDAwPjxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9IkZPTlQtU0laRTogMTJwdCI+PFNQQU4gDQpzdHls ZT0ibXNvLXNwYWNlcnVuOiB5ZXMiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCkJSPC9TUEFOPjwvU1BBTj48L0ZPTlQ+PC9Q Pg0KPFAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSJNQVJHSU46IDBjbSAwY20gMHB0Ij48Rk9OVCAN CmZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1TSVpF OiAxMnB0Ij48Rk9OVCANCmNvbG9yPSMwMDAwMDA+PFNQQU4gDQpzdHlsZT0ibXNvLXNwYWNlcnVu OiB5ZXMiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCll1bmZlaTwvU1BBTj48bzpwPjwvbzpwPjwvRk9O VD48L1NQQU4+PC9GT05UPjwvUD48L0ZPTlQ+PC9GT05UPjwvRElWPjwvRElWPjwvRElWPjwvRElW PjwvRk9OVD48L0ZPTlQ+PC9GT05UPjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgY29sb3I9IzAw MDAwMCBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJViBhbGlnbj1sZWZ0PjxGT05UIGNv bG9yPSMwMDAwMDAgc2l6ZT0yPg0KPEhSIHN0eWxlPSJXSURUSDogMTIycHg7IEhFSUdIVDogMnB4 IiBTSVpFPTI+DQo8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGNvbG9yPSMwMDAwMDAgc2l6ZT0y PnpoYW5neXVuZmVpPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBjb2xvcj0jMDAwMDAwIHNpemU9 Mj4yMDA5LTA3LTI4PC9GT05UPjwvRElWPjwvRk9OVD48L0ZPTlQ+PC9ESVY+DQo8SFI+DQo8L0JP RFk+PC9IVE1MPg0K --Boundary_(ID_DncGIWNH3VsOSXjsIgUaiQ)-- From melodysong@huawei.com Thu Jul 30 04:37:55 2009 Return-Path: X-Original-To: decade@core3.amsl.com Delivered-To: decade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5BF9C3A6B84 for ; Thu, 30 Jul 2009 04:37:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.547 X-Spam-Level: X-Spam-Status: No, score=-1.547 tagged_above=-999 required=5 tests=[AWL=1.052, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ybxm1xetk+wx for ; Thu, 30 Jul 2009 04:37:54 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 6DB713A67DF for ; Thu, 30 Jul 2009 04:37:54 -0700 (PDT) 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 <0KNL00N2REHM1M@szxga04-in.huawei.com> for decade@ietf.org; Thu, 30 Jul 2009 19:27:22 +0800 (CST) Received: from huawei.com ([172.24.1.6]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KNL009GLEHMEH@szxga04-in.huawei.com> for decade@ietf.org; Thu, 30 Jul 2009 19:27:22 +0800 (CST) Received: from 975DEF9223E44C7 ([77.241.97.115]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KNL005HAEHISQ@szxml02-in.huawei.com>; Thu, 30 Jul 2009 19:27:22 +0800 (CST) Date: Thu, 30 Jul 2009 13:27:15 +0200 From: Song Haibin To: Yu-Shun Wang , decade@ietf.org Message-id: <015001ca1108$b30c9fc0$45012b0a@975DEF9223E44C7> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <81E94869FA91394CB0D6408786148E9B10471264@TK5EX14MBXC112.redmond.corp.microsoft.com> Subject: Re: [decade] DECADE Bar BOF follow up X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2009 11:37:55 -0000 And don't forget the nice guy who brought a lot of delicious food and beers for us : ) Thanks to Eric Burger. Anyone who is still unclear to the problem and scope please send email to the mailing list. We will try to make it clearer. Thanks, Haibin ----- Original Message ----- From: "Yu-Shun Wang" To: Cc: "ext Song Haibin" ; "Alexey Melnikov" ; "Lars Eggert" Sent: Thursday, July 30, 2009 9:52 AM Subject: DECADE Bar BOF follow up Hi Everyone, First of all, thanks for coming and for a productive discussion. I think it's fair to say that there are problems in this space that IETF can and should consider, and also that there are interests among the participants to work on the problems. But there are also issues that we definitely should address in order to move toward a working group. Just to list some high level points here: - in depth investigation on prior work (also justification on new work) - applicability - benefit - incentives - some statement on layer 8 issues, esp. on potential deployment hurdles - ... Some logistics. - Slide decks: Alexey mentioned last night after the BoF for us to send the slides to him, and (presumably) Alexey will find some place to post the materials, maybe a page on the wiki? And yes, the slide deck, at least the BranchCache one, is pretty big (6MB) due to the animations and diagrams. I'll try to condense it a bit before posting it. - Minutes: Haibing and I will combine the minutes and send it to the list. The chairs would also like to thank Linda and Roni for volunteering as note takers. Next steps: Let's continue the discussion on list. Or send a note to Haibing and I if you are interested on certain aspects of the problems. We would very much like to shoot for an official BoF for the next IETF. (And get out of early/late Bar BoFs!) Thanks, Haiging and Yushun From richard_woundy@cable.comcast.com Thu Jul 30 05:31:13 2009 Return-Path: X-Original-To: decade@core3.amsl.com Delivered-To: decade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9785B3A6C65 for ; Thu, 30 Jul 2009 05:31:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.463 X-Spam-Level: X-Spam-Status: No, score=-0.463 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9+gibQRN++lT for ; Thu, 30 Jul 2009 05:31:12 -0700 (PDT) Received: from paoakoavas09.cable.comcast.com (paoakoavas09.cable.comcast.com [208.17.35.58]) by core3.amsl.com (Postfix) with ESMTP id 6A4EB3A6BA1 for ; Thu, 30 Jul 2009 05:31:12 -0700 (PDT) Received: from ([10.52.116.31]) by paoakoavas09.cable.comcast.com with ESMTP id KP-NTF18.75921550; Thu, 30 Jul 2009 08:30:52 -0400 Received: from PACDCEXCMB06.cable.comcast.com ([24.40.15.22]) by PAOAKEXCSMTP02.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 30 Jul 2009 08:30:52 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 30 Jul 2009 08:30:52 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [decade] DECADE Bar BOF follow up Thread-Index: AcoRCj6yqaZkAG57SBmHP43JXoKRDAAAnd8f References: <81E94869FA91394CB0D6408786148E9B10471264@TK5EX14MBXC112.redmond.corp.microsoft.com> <015001ca1108$b30c9fc0$45012b0a@975DEF9223E44C7> From: "Woundy, Richard" To: "Song Haibin" , "Yu-Shun Wang" , X-OriginalArrivalTime: 30 Jul 2009 12:30:52.0973 (UTC) FILETIME=[9410DDD0:01CA1111] Subject: Re: [decade] DECADE Bar BOF follow up X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2009 12:31:13 -0000 This was a very interesting bar bof, thanks for setting it up. =20 In the meeting, I said I would obtain and share information about the = InterStream Association (http://interstream.com/), and their approach to = cooperative content distribution among ISPs. (Note: this email does not = imply endorsement of the InterStream technology or business model.) =20 Here is the link to their Wiki, which describes the InterStream = technologies, business model, and philosophy: = http://interstream.com/PmWiKi/pmwiki.php?n=3DInterStream.Concepts.=20 =20 It may be worthwhile for Decade folks to take a look at this, as another = comparison point. =20 -- Rich ________________________________ From: decade-bounces@ietf.org on behalf of Song Haibin Sent: Thu 7/30/2009 7:27 AM To: Yu-Shun Wang; decade@ietf.org Subject: Re: [decade] DECADE Bar BOF follow up And don't forget the nice guy who brought a lot of delicious food and = beers for us : ) Thanks to Eric Burger. Anyone who is still unclear to the problem and scope please send email = to the mailing list. We will try to make it clearer. Thanks, Haibin ----- Original Message ----- From: "Yu-Shun Wang" To: Cc: "ext Song Haibin" ; "Alexey Melnikov" = ; "Lars Eggert" Sent: Thursday, July 30, 2009 9:52 AM Subject: DECADE Bar BOF follow up Hi Everyone, First of all, thanks for coming and for a productive discussion. I think it's fair to say that there are problems in this space that IETF can and should consider, and also that there are interests among the participants to work on the problems. But there are also issues that we definitely should address in order to move toward a working group. Just to list some high level points here: - in depth investigation on prior work (also justification on new work) - applicability - benefit - incentives - some statement on layer 8 issues, esp. on potential deployment hurdles - ... Some logistics. - Slide decks: Alexey mentioned last night after the BoF for us to send the slides to him, and (presumably) Alexey will find some place to post the materials, maybe a page on the wiki? And yes, the slide deck, at least the BranchCache one, is pretty big (6MB) due to the animations and diagrams. I'll try to condense it a bit before posting it. - Minutes: Haibing and I will combine the minutes and send it to the list. The chairs would also like to thank Linda and Roni for volunteering as note takers. Next steps: Let's continue the discussion on list. Or send a note to Haibing and I if you are interested on certain aspects of the problems. We would very much like to shoot for an official BoF for the next IETF. (And get out of early/late Bar BoFs!) Thanks, Haiging and Yushun _______________________________________________ decade mailing list decade@ietf.org https://www.ietf.org/mailman/listinfo/decade From melodysong@huawei.com Thu Jul 30 07:44:49 2009 Return-Path: X-Original-To: decade@core3.amsl.com Delivered-To: decade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 98F943A71C2 for ; Thu, 30 Jul 2009 07:44:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.559 X-Spam-Level: * X-Spam-Status: No, score=1.559 tagged_above=-999 required=5 tests=[AWL=-2.299, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_BASE64_TEXT=1.753, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BtYk1dRZ6SQs for ; Thu, 30 Jul 2009 07:44:48 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id C8C743A71D8 for ; Thu, 30 Jul 2009 07:43:51 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KNL00C3JNKUNX@szxga03-in.huawei.com> for decade@ietf.org; Thu, 30 Jul 2009 22:43:42 +0800 (CST) Received: from huawei.com ([172.24.1.3]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KNL00GDLNKUKW@szxga03-in.huawei.com> for decade@ietf.org; Thu, 30 Jul 2009 22:43:42 +0800 (CST) Received: from 975DEF9223E44C7 (dhcp-17c2.meeting.ietf.org [130.129.23.194]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KNL00AWONKQ10@szxml01-in.huawei.com> for decade@ietf.org; Thu, 30 Jul 2009 22:43:42 +0800 (CST) Date: Thu, 30 Jul 2009 16:43:30 +0200 From: Song Haibin To: decade@ietf.org Message-id: <039901ca1124$2002cdf0$45012b0a@975DEF9223E44C7> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: text/plain; charset=gb2312 Content-transfer-encoding: base64 X-Priority: 3 X-MSMail-priority: Normal Subject: [decade] DECADE meeting minutes X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2009 14:44:49 -0000 SGkgYWxsLA0KDQoNCg0KSGVyZSBhcmUgdGhlIG1lZXRpbmcgbm90ZXMgb2YgREVDQURFIEJhciBC T0YuICBJdCdzIGEgbWVyZ2VkIHZlcnNpb24gZnJvbSB0aGUgbm90ZXMgdGFrZW4gYnkgUm9uaSBh bmQgTGluZGEuIFBsZWFzZSBjaGVjayBmb3IgY29uc2lzdGVuY3kgd2l0aCB5b3VyIG93biBtZW1v cmllcyENCg0KDQoNCg0KREVDQURFIEJBUiBCT0YNCg0KVGhlcmUgd2VyZSBhYm91dCA1MCBwZW9w bGUgaW4gdGhlIHJvb20NCll1IFNodW4gYW5kIEhhaWJpbiBjaGFpcmVkIHRoZSBCT0YNCg0KDQoN Cg0KVGhlIENoYWlyIGFubm91bmNlZCB0aGUgYWdlbmRhIGFuZCBhbm5vdW5jZWQgSUVURiBwb2xp Y3kuDQoNCkFnZW5kYSBiYXNoaW5nIChjaGFpcnMpDQoNCg0KRXJpYyAtIGxlYXZlIHRpbWUgdG8g ZGlzY3VzcyB0aGUgb2JqZWN0aXZlcyBhbmQgaWYgdGhpcyBpcyBhIHRvcGljIGZvciBJRVRGDQpZ dS1TaHVuOiB0aGVyZSBhcmUgbm8gZHJhZnRzIHlldA0KDQpHb2FscyAmIE5leHQgc3RlcHMNCg0K SW50cm9kdWN0aW9uOg0KQXJjaGl0ZWN0dXJlIGZyYW1ld29yayAtIGFwcGxpY2F0aW9uIGFnbm9z dGljcyBpbiBuZXR3b3JrIGNhY2hlcyBmb3IgYm90aCBwMnAgYW5kIGNsaWVudCBzZXJ2ZXIgYXBw bGljYXRpb25zLg0KTWFpbiBjb21wb25lbnRzIC0gaGFkIGEgc2ltcGxpZmllZCBwaWN0dXJlLg0K DQpRdXNldGlvbnM6IA0KU2hvdWxkIHRoZSBjYWNoZSBiZSBiZXR3ZWVuIHRoZSBzb3VyY2UgYW5k IGNsaWVudCCoQyByZXNwb25zZTogaXQgZGVwZW5kcyBvbiBob3cgaXQgaXMgZGVwbG95ZWQuDQpM aW5kYTogV2lsbCB0aGUgY2FjaGUgYmUgYSBwdWJsaXNoZWQgc2VydmVyLCB3aG8gb3ducyB0aGVt IHdobyBwcm92aWRlIC0gcmVzcG9uc2U6IHRoZXJlIGFyZSBzZXZlcmFsIG9wdGlvbnMgaW5jbHVk aW5nIHNlcnZlciBwcm92aWRlcnMgYW5kIElTUHMuIFRoaXMgaXMgbm90IGEgY29tcGxldGUgcGlj dHVyZS4gDQpWb2xrZXI6IGNhY2hlcyBleGlzdHMgKENETikgd2h5IG5vdCBzYXkgSFRUUCBpcyB0 aGUgcHJvdG9jb2wgYW5kIHdlIGFyZSBwdXNoaW5nIHRoZSBkYXRhIHRvIHRoZW0uIFJlc3BvbnNl OiBUaGUgcmVzdWx0IG9mIHRoZSByZXF1aXJlbWVudHMgbWF5IGJlIHRoZSBjdXJyZW50IENETiBi dXQgdGhlcmUgYXJlIGlzc3Vlcy4gSXQgd2lsbCBiZSBkaXNjdXNzZWQgbGF0ZXIuIEhUVFAgbWln aHQgYmUgYSBwb3NzaWJsZSBzb2x1dGlvbi4NCg0KRGF2ZSBDcm9ja2VyOiBTb3VuZHMgbGlrZSB1 c2luZyBzdGFuZGFyZCBDRE4gcHJvdG9jb2wgYW5kIGNoZWNrIGlmIGV4aXN0aW5nIENETiBpcyBu b3QgZWZmaWNpZW50LiBJZiB0aGUgZXhpc3RpbmcgcHJvdG9jb2xzIGFyZSBub3QgZW5vdWdoLCBj YW4geW91IGxpc3QgdGhlbT8gIFJlc3BvbnNlOiBJdCB3aWxsIGJlIGRpc2N1c3NlZCBvbiB0aGUg c2Vjb25kIHByZXNlbnRhdGlvbi4NCg0KIA0KDQpZdW5mZWkgLSBXaWxsIHdlIHN0YW5kYXJkaXpl IHRoZSBjYWNoZSB0byBjYWNoZSAtIFJlc3BvbnNlOiB0aGlzIGlzIGEgc2NvcGUgcXVlc3Rpb24N Cg0KIA0KDQogDQoNClRoZW4gSGFpYmluIHByZXNlbnRlZCBQcm9ibGVtIFN0YXRlbWVudHM6DQoN Cg0KUmljaCBXb3VuZHk6IFJlZHVjZSB1cGxpbmsgd2lsbCBkZWZpbml0ZWx5IGhlbHAgbWUgYXMg YW4gSVNQLiBCdXQgb3RoZXIgSVNQcyBtYXkgbm90IGhhdmUgdGhpcyBwcm9ibGVtLiBJcyBpdCB1 bml2ZXJzYWwgdHJ1ZSB0aGF0IHJlZHVjaW5nIHVwbGluayBiYW5kd2lkdGggaXMgYW4gaXNzdWU/ IFdpcmVsZXNzIG9wZXJhdG9yIG1heSBoYXZlIHRoaXMgaXNzdWUuIA0KDQogDQoNCkthciBmcm9t IFZvZGFmb25lIGFncmVlZDogaXQgaXMgdHJ1ZSB0aGF0IHVwbGluayBiYW5kd2lkdGggaXMgYW4g aXNzdWUuIFRoZXkgZG8gd2FudCB0byByZWR1Y2UgdXBsaW5rLiBCdXQgdGhleSBiZWxpZXZlIHRo YXQgQ2FjaGUgd2lsbCByZWR1Y2UgdGhlIGRvd25saW5rIGFzIHdlbGwuIA0KDQogDQoNCkRhdmUg Q3JvY2tlcjogTm93IHlvdSBhcmUgdGFsa2luZyBhYm91dCBsaW5rIGJlaGF2aW9yLiBQMlAgaXMg bWFueSB0aGluZ3MuIElmIHlvdSBkb26hr3QgaGF2ZSBzcGVjaWZpYyBhcHBsaWNhdGlvbiBhdCB0 aGUgYmVnaW5uaW5nLCB0aGVuIHRoaXMgaXMgYW4gYWJzdHJhY3QgZGlzY3Vzc2lvbi4gVGhlcmVm b3JlLCB0aGUgZGViYXRlIGlzIG5vdCB2ZXJ5IHVzZWZ1bC4gDQoNCll1IFNodW4gLSBuZWVkIG5v dCB0byBjb25jZW50cmF0ZSBvbiB0aGUgbGluayBidXQgYXBwbGljYXRpb24gdXNlIGNhc2VzLg0K DQoNCg0KRGF2ZSBDcm9ja2VyOiBDYWNoaW5nIHdpbGwgbm90IHNvbHZlIHByb2JsZW0gZm9yIElN IGFuZCBJTSBpcyBQMlAuIFJpY2hhcmQgQWxpbWkgc3RhdGVkIG9uZSBleGFtcGxlIG9mIEZpbGUg U2hhcmluZywgd2hpY2ggY2FuIGRlbW9uc3RyYXRlIHRoYXQgdGhlIGNhY2hpbmcgY2FuIHJlZHVj ZSB0aGUgbGluayB1dGlsaXphdGlvbi4gDQoNCiANCg0KTHVjeSBZb25nOiBzYXZpbmcgdGhlIHVw bGluayBpcyBub3QgdGhlIG1haW4gZHJpdmluZyBmb3JjZS4gSXQgaXMgZm9yIHNhdmluZyBib3Ro IGxpbmtzLiANCg0KDQpSaWNoIFdvdW5keS0gY3VycmVudCBjYWNoaW5nIHN5c3RlbSBiYXNlZCBv biB0cmFuc3BhcmVudCBwYXNzaW5nIGJ5IHdoaWNoIHRoZXkgc3N1bWUgdGhhdCBpZiBpdCBpcyBw MnAgcHJvdG9jb2wgdGhleSBwdXQgY2FjaGUgaW5saW5lIG9mIHRoZSB0cmFuc21pc3Npb24gbGlu ZS4NCkFuc3dlcjogeW91IGRvIG5vdCBoYXZlIHRvIGludGVyY2VwdCB0cmFmZmljIHRvIGNhY2hl IGl0LiBJdCB3aWxsIGJlIGluIHRoZSByZXF1aXJlbWVudC4NCg0KIA0KDQpUaGUgZGlyZWN0aW9u IGlzIGZvciBvZmYgcGF0aCBjYWNoZSBidXQgdGhlIHBlZXIgd2lsbCBiZSBhd2FyZSANCg0KDQoN ClF1c3Rpb24gZnJvbSBSaWNoIFdvdW5keTogVGhlcmUgYXJlIGEgbG90IG9mIGNhY2hlIHZlbmRv cnMuIFVzaW5nIERQSSB0byByZS1kaXJlY3QgdGhlIHRyYWZmaWMuIElzIGl0IHRoZSBhc3N1bXB0 aW9uIGZvciB0cmFuc3BhcmVudCBjYWNoaW5nPw0KDQogDQoNClJpY2hhcmQgQWxpbWk6IEl0IHNo b3VsZCBoYXZlIGEgcmVxdWlyZW1lbnQgdGhhdCBjYWNoaW5nIGZhaWx1cmUgc2hvdWxkIGFsbG93 IHRoZSBQMlAgdG8gcmVzdW1lIHRoZSBub3JtYWwgY29tbXVuaWNhdGlvbi4NCg0KIA0KDQpTdGV2 ZW4gUmlnaHQ6IERvIHlvdSBtZWFuIG11bHRpcGxlIHN5c3RlbXMgc2hhcmluZyB0aGUgc2luZ2xl IGNhY2hlPyBEbyB5b3UgbmVlZCB0byBjb25maWd1cmUgaG93IG11Y2ggY2FjaGUgc2hvdWxkIGJl IHJlc2VydmVkIHRvIEJpdFRvcnJlbnQ/ICAgQW5zd2VyOiBpdCBzaG91bGQgZGVwZW5kIG9uIHRo ZSBjb25maWd1cmF0aW9uLiANCg0KIA0KDQpSaWNoIGZyb20gYW4gSVNQOiBzdGF0aW5nIHNhdmlu ZyB1cGxpbmsgaXMgdG9vIGJyb2FkIHNjb3BlLCBidXQgaXQgaXMgbm90IHNwZWNpZmljIHRvIFAy UC4gDQoNCg0KUmVzcG9uc2U6IFRoZSBjYWNoZSBzb2x1dGlvbiBjYW4gYmUgdXNlZCB0byBub24g cDJwIHNvbHV0aW9uLiBUaGUgYmFyIEJPRiBpcyBhYm91dCBwMnANCg0KDQoNClE6IFdoZW4geW91 IHNheSB0aGF0IFAyUCByZXByZXNlbnQgNDAlIHRyYWZmaWMgb2YgaW50ZXJuZXQsIHdoYXQgb3Ro ZXIgdHJhZmZpYyBhcmUgaW4gdGhlIG5ldHdvcmsuIEFuc3dlcjogaXQgaXMgbm90IHRoZSBjb25j ZXJuIGZvciB0aGlzIHdvcmsuDQoNClpvbmdOaW5nOiB3ZWIgY2FjaGUgaXMgYW5vdGhlciB3YXkg b2YgY2FjaGluZy4gTm93IHdlIHdhbnQgdG8gZmluZCBvdGhlciB3YXkgdG8gY2FjaGUNCg0KUTog dXNpbmcgdGhlIGNhY2hlIGlzIG5vdCBtYW5kYXRvcnkgc28gdGhlcmUgbmVlZCB0byBiZSBtb3Rp dmF0aW9uDQpmb3IgY2xpZW50cyB0byB1c2UgdGhlbS4gQW5zd2VyOiBtYXliZSBiZXR0ZXIgcGVy Zm9ybWFuY2UsIHNvIHRoYXQgUDJQIHNvZnR3YXJlIHdhbnRzIHRvIHVzZSBpdC4gDQoNClE6IHdo YXQgaXMgdGhlIGRpZmZlcmVuY2UgYmV0d2VlbiB5b3VyIHByb3RvY29sIGFuZCBSRUxPQUQ/IA0K DQogICAgYS4uIFJlc3BvbnNlIGZyb20gdGhlIGNoYWlyIG9mIFAyUFNJUCwgRGF2aWQgQnJ5YW4g c3RhdGVkIFJFTE9BRCBpcyBmb3IgcmVzb3VyY2UgZGlzY292ZXJ5LiANClZpamF5OiB3aGF0IGlz IHRoZSByb2xlIG9mIGNhY2hpbmcgaW4gdGhlIHN0cmVhbWluZyBhcHBsaWNhdGlvbj8gV2hlbiB0 aGUgbG9hZCBpcyBjb25zaXN0ZW50DQoNClE6IGlzIGl0IGRlc2lyYWJsZSB0byBtYWtlIGl0IHRo ZSBnb2FsIG9mIHRoaXMgQm9GIHRvIGhhdmUgY2VydGFpbiBsb2NhdGlvbiBvciBzdHJ1Y3R1cmUg d2lsbCBtYWtlIHRoaXMgcHJvdG9jb2wgcHJhY3RpY2FsPyBDaGFpcjogbGV0oa9zIHNlZSBmaXJz dCBpZiB0aGUgcHJvdG9jb2wgaXMgaW50ZXJlc3RpbmcgZW5vdWdoIHRvIGdldCBkb3duIHRvIHRo ZSB0b3BvbG9neS4gDQoNCkthcjogSXMgaXQgc3BlY2lmaWNhbGx5IGZvciBQMlAgb3Igb3RoZXJz PyBDaGFpcjogVGhlIG1vdGl2YXRpb24gaXMgZnJvbSBQMlAsIGJ1dCBzb2x1dGlvbiBjb3VsZCBi ZSB1c2VkIGZvciBvdGhlcnMuIExldKGvcyBjb25zaWRlciBpdCBmb3IgZnV0dXJlLiANCg0KUTog d2hvIGRlY2lkZXMgd2hhdCB0byBiZSBzdG9yZWQgaW4gdGhlIGNhY2hlPyBBbnN3ZXI6IFRoZSB0 aGlyZCBwcmVzZW50YXRpb24gd2lsbCBzaG93IGEgcG9zc2libGUgZXhhbXBsZSBvZiB0aGUgZGV0 YWlscy4gDQoNCiANCg0KDQpUaGVuIE5pbmcgWm9uZyBhbmQgUmljaGFyZCBBbGltaSBkaWQgam9p bnQgcHJlc2VudGF0aW9uIG9uIFN1cnZleSBzbGlkZXMuDQoNCk5ldHdvcmsgc3RvcmFnZSBzeXN0 ZW0gY29tcG9uZW50cw0KDQoNCg0KV2ViIENhY2hpbmc6IHVzZSBIVFRQLCBidXQgbm90IGRlc2ln bmVkIGZvciBQMlAgYXBwbGljYXRpb25zLiANCg0KVHJhbnNwYXJlbnQgUDJQIENhY2hlIGFuZCBu b24tdHJhbnNwYXJlbnQgUDJQIGNhY2hlDQoNCiANCg0KQ0ROOiBQdXNoIHRoZSBjb250ZW50IHRv IHRoZSBlZGdlLCBidXQgbm90IGRlc2lnbmVkIGZvciBQMlAuIERpc2N1c3Npb24gYWJvdXQgdGhl IGlzc3VlIG9mIHJlc291cmNlIGNvbnRyb2wgcmVxdWlyZW1lbnQuIFE6IFdoYXQgZG8geW91IG1l YW4gYnkgc2F5aW5nIGl0IGRvZXNuoa90IHByb3ZpZGUgcmVzb3VyY2UgY29udHJvbD8gQW5zd2Vy OiB0aGUgcHVzaCBtb2RlbCBkb2VzbqGvdCByZXF1aXJlIHRoZSBjb250ZW50IGZyb20gdGhlIGNv bnRlbnQgcHJvdmlkZXIgdG8ga25vdyB0aGUgYmFuZHdpZHRoIGF2YWlsYWJsZSBmb3IgdGhlIGNs aWVudC4gDQoNCiANCg0KUmljaGFyZCBBbGltaaGvcyBwcmVzZW50YXRpb24gb24gQW1hem9uIFMz LCBXaW5kb3dzIEF6dXJlLCBPY2VhbiBTdG9yZSwgaVNDU0kNCg0KRG9lc26hr3QgcHJvdmlkZSB0 aGUgcmVzb3VyY2UgY29udHJvbCAoYmFuZHdpZHRoIGFuZCBjb25uZWN0aW9ucykNCg0KUXVlc3Rp b24gZnJvbSBEYXZlIENyb2NrZXI6IHdoYXQgaXMgdGhlIGFjY2VzcyBjb250cm9sPyBBbnN3ZXI6 IHRoZSBwZWVyIGNsaWVudCBzaG91bGQgaGF2ZSBjb250cm9sIG9uIHdoaWNoIHBlZXIgdG8gaGF2 ZSB0aGUgY29udGVudC4NCg0KRGF2ZSBmcm9tIFZlcml6b246IHdoYXQgaXMgdGhlIHRvcG9sb2d5 IGZvciBjYWNoaW5nPyBJcyBpdCBmb3IgdW5pY2FzdCBvciBtdWx0aWNhc3Q/ICBBbnN3ZXI6IGl0 IGlzIG5vdCBpbXBvcnRhbnQgYXQgdGhpcyBwb2ludC4gDQoNCiANCg0KDQpUaGVuIFJpY2hhcmQg QWxpbWkgZGlkIFNhaWxvciBwcmVzZW50YXRpb24uDQoNClBvc3NpYmxlIHNvbHV0aW9uIHRvIGRl Y2FkZQ0KVXNlIGFwcGxpY2F0aW9uIGFnbm9zdGljIGRhdGEgbG9ja2Vycy4gQ2hhbmdlIGZyb20g obBjbGllbnQgdG8gY2xpZW50IFAyUCBkYXRhobEsIHRvIHVzaW5nIGRhdGEgbG9ja2VyIGZvciBj bGllbnQgdG8gZ2V0IGRhdGEgZnJvbSBDYWNoZSBhcyBpZiBpdCBnZXRzIHRoZSBkYXRhIGZyb20g dGhlIG90aGVyIGNsaWVudC4gDQoNCg0KUmljaCBXb3VuZHkgLSBpcyB0aGVyZSBhIHJlbGF0aW9u IGJldHdlZW4gdGhlIGNodW5rcyBpZHMgaW4gYml0IHRvcnJlbnQgYW5kIHRoZQ0Kb25lcyBpbiB0 aGUgY2FjaGUgLSByZXNwb25zZSB0aGV5IGFyZSBub3QgdGhlIHNhbWUgYnV0IG1hcHBpbmcgaXMg cmVxdWlyZWQNCg0KUXVlc3Rpb24gLSBjYW4gdGhlIGNsaWVudCBjb250cm9sIHRoZSBsaWZlIHRp bWUgb2YgdGhlIGRhdGEgaW4gdGhlIGNhY2hlIC0gZm9yIGV4YW1wbGUgdGltZSBmb3IgZmlsZSBz aGFyaW5nIGNvbXBhcmVkIHRvIHN0cmVhbWluZyBjaHVua3MuIA0KUmljaGFyZCB5ZXMgaXQgd2ls bCBiZSBjb25zaWRlcmVkLg0KDQoNCg0KUXVlc3Rpb24gZnJvbSBSaWNoIChJU1ApOiBkb2VzIExv Y2tlciBhc3NvY2lhdGUgd2l0aCBtZWdhIGRhdGE/IA0KDQpRdWVzdG9pbiBmcm9tIFJpY2ggKElT UCk6IHNob3VsZCB5b3UgYWxsb2NhdGUgYSB0aW1lciB0byBhIGJsb2NrIG9mIGRhdGE/IEFuc3dl cjogYW5vdGhlciB3YXkgaXMgdG8gc3BlY2lmeSBhIGNhY2hlIHBvbGljeS4gDQoNCkthciAoVm9k YWZvbmUpOiBmb3Igb3B0aW1pemF0aW9uOiBtYXliZSBvbmx5IHN0b3JlIGZvciB4IG1pbnV0ZXMs IGJ1dCBub3QgdGhlIGVudGlyZSBsZW5ndGguICANCg0KTG9ja2VyIEFjY2VzcyBQcm90b2NvbCAo TEFQKQ0KDQpRdWVzdGlvbiBmcm9tIEVyaWM6IGhvdyB0byByZXZva2UgdGhlIGFjY2Vzcz8gQW5z d2VyOiBwZXJtYW5lbnQgZ3JhbnQNCg0KUXVlc3Rpb246IGhvdyB0byBwcm90ZWN0IHByaXZhY3k/ IExpa2UgSVAgYWRkcmVzcy4gQW5zd2VyOiB0b2RheaGvcyBEUEkgYWxyZWFkeSBleHBvc2UgdGhl IElQIGFkZHJlc3MNCg0KDQoNCkJyYW5jaCBjYWNoZSAtIFl1LVNodW4NClRoZXJlIGlzIElQUiBv biBzb21lIG9mIHRoZSBjb250ZW50DQpUaGUgbW90aXZhdGlvbiB3YXMgZm9yIGJyYW5jaCBvZmZp Y2VzIG9mIGxhcmdlIGNvcnBvcmF0aW9uIHdoZXJlIHRoZSBkYXRhIGlzDQp1c3VhbGx5IGluIHRo ZSBtYWluIG9mZmljZSBhbmQgdGhlIGNvc3Qgb2YgY29tbXVuaWNhdGlvbiB0byB0aGUgYnJhbmNo IGFyZQ0KbGFyZ2UuDQoNCg0KDQogIGEuLiBEZWNvdXBsZSB0aGUgYXBwbGljYXRpb24gcHJvdG9j b2wgZnJvbSBjYWNoZS4gDQogIGIuLiBHb2FsOiB0byByZWR1Y2UgdGhlIGxpbmsgdXRpbGl6YXRp b24uIExvY2FsIHNlYXJjaCByZXF1aXJlcyBhdXRoZW50aWNhdGlvbiBiZWZvcmUgc2VhcmNoaW5n IHRoZSBsb2NhbCBjb250ZW50LiANCiAgYy4uIERpc3RyaWJ1dGVkIENhY2hlOiANCiAgZC4uIEhv c3RlZCBDYWNoZTogDQogIGUuLiBRIGZyb20gTHVjeTogd2lsbCBBcHAgR2V0IGhhdmUgYXV0aGVu dGljYXRpb24/IEE6IHllcy4gSWYgdGhlIGF1dGhlbnRpY2F0aW9uIGZhaWxzLCB0aGVyZSBpcyBu byBrZXkgY29taW5nIGJhY2suIA0KICBmLi4gQnJlYWsgdGhlIGNvbnRlbnQgdG8gc2VnbWVudCBh bmQgYmxvY2tzLiBTZWdtZW50cyBoYXZlIElELCB3aGljaCBpcyB1c2VkIGJ5IGNsaWVudCB0byBz ZWFyY2ggDQogIGcuLiBBbGwgdGhlIGRhdGEgdHJhbnNmZXIgdXNlcyBIVFRQIA0KICBoLi4gUTog aWYgdGhlIGNvbnRlbnQgaGFzIGFueSBjaGFuZ2VzLCB3aWxsIHRoZSBjbGllbnQgZ2V0IHVwZGF0 ZWQgaW5mb3JtYXRpb24/IEE6IEFsbCBjb250ZW50IHNlYXJjaGVzIGhhdmUgdG8gZ28gdG8gdGhl IGNlbnRlciB0byBnZXQgYXV0aGVudGljYXRpb24uIElmIHRoZXJlIGlzIGFueSBjaGFuZ2UgdG8g dGhlIGNvbnRlbnQsIHRoZSBkYXRhIGNlbnRlciB3aWxsIGluZm9ybSB0aGUgY2hhbmdlIHN0YXR1 cyB3aGVuIHBhc3NpbmcgZG93biB0aGUga2V5Lg0KICBpLi4gRm9yIG1vcmUgaW5mb3JtYXRpb246 IHd3dy5icmFuY2hjYWNoZS5jb20gDQogIGouLiBRIGZyb20gUmljaCBXb3VuZHk6IERpZCB5b3Ug Y292ZXIgSW50ZXJTdHJlYW0/IHdoaWNoIGlzIGEgTXVsdGktSVNQIENETiBtZXRob2QuIE11bHRp cGxlIElTUCBwcm92aWRlZCBjb250ZW50cyB0byBhIGNvbW1vbiBjb250ZW50IGRpc3RyaWJ1dGlv biBuZXR3b3JrLiBBbm90aGVyIHNpbWlsYXIgYXNwZWN0IGlzIFJlbW90ZSBEVlIsIHdoaWNoIHJl cXVpcmVzIHRvIHN0b3J5IHNlcGFyYXRlIGNvcHkgaW4gbXVsdGlwbGUgY2FjaGVzIGR1ZSB0byBs ZWdhbCBpc3N1ZXMuIEJpbGwgc3RhdGVkOiB3ZSBkZWNpZGUgdG8gdHVybiB0aGUgY2FjaGUgb2Zm IGR1ZSB0byB0aGUgcmVndWxhdG9yeSBpc3N1ZS4gDQogIGsuLiBFcmljOiB3aWxsIElTUCBiZSBp bnRlcmVzdGVkIGluIHByb3ZpZGluZyB0aGlzPyANCiAgbC4uIFJpY2ggV291bmR5OiBpZiBtZWdh IGRhdGEgaXMgc3RvcmVkIHdpdGggZGF0YSwgSVNQIGlzIGxpYWJsZSBmb3IgdmFsaWRhdGUgdGhl IHNvdXJjZSwgb3RoZXJ3aXNlIHRoZSBJU1AgY2FuIGdldCBzdWVkDQpFcmljIFJvZ2VyOiBpZiBh biBlbXBsb3llZSBoYXMgYSBwaXJhdGVkIGRhdGEgb24gaGlzL2hlciBsYXB0b3AsIGFuIGVudGVy cHJpc2UgYmFja2luZyBvZmYgdGhlIGNvbnRlbnQgY2FuIGdldCBpbnRvIGxlZ2FsIHRyb3VibGUu DQoNCg0KDQpSZXF1ZXN0IC0gdG8gbWFrZSB0aGUgcHJlc2VudGF0aW9ucyBhdmFpbGFibGUNCg0K aHR0cDovL3d3dy5icmFuY2hjYWNoZS5jb20NCg0KUmljaCAtIGRpZCB5b3UgbG9vayBhdCBpbnRl cnN0cmVhbSBhc3NvY2lhdGlvbiBodHRwOi8vaW50ZXJzdHJlYW0uY29tLyANCiwgYW5vdGhlciBz b2x1dGlvbiBpcyByZW1vdGUgZHZyIHNldCBieSBjYWJsZXZpc2lvbg0KIA0KDQoNCg0KICAgICBD aGFpcjogaG93IG1hbnkgcGVvcGxlIHRoaW5rIGl0IHNob3VsZCBiZSB3b3JrZWQgaW4gSUVURj8g TWFqb3JpdHkgb2YgcGVvcGxlIHJhaXNlZCAgICB0aGVpciBoYW5kcy4gDQoNClZvbGtlcjogSSBh bSBub3QgZnVsbHkgY29udmluY2VkIGl0IGlzIGEgcHJvYmxlbS4gDQoNCg0KSG93IG1hbnkgd291 bGQgbGlrZSB0byB3b3JrIG9uIHRoaXMgcHJvYmxlbSBpZiBpdCBiZWNvbWVzIGEgd29yayBpbiB0 aGUgSUVURi4gDQpUaGVyZSB3ZXJlIGFib3V0IDIzIGhhbmRzDQoNCiANCg0KDQoNClRoYW5rcywN Cg0KSGFpYmluDQoNCg0KDQoNCg== From richard_woundy@cable.comcast.com Thu Jul 30 09:47:32 2009 Return-Path: X-Original-To: decade@core3.amsl.com Delivered-To: decade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA9483A68EF for ; Thu, 30 Jul 2009 09:47:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.463 X-Spam-Level: X-Spam-Status: No, score=-4.463 tagged_above=-999 required=5 tests=[AWL=4.000, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1xKWgEm1-JCa for ; Thu, 30 Jul 2009 09:47:30 -0700 (PDT) Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by core3.amsl.com (Postfix) with ESMTP id 1D42B3A6A06 for ; Thu, 30 Jul 2009 09:47:30 -0700 (PDT) Received: from ([24.40.15.92]) by pacdcimo01.cable.comcast.com with ESMTP id 5503620.47785280; Thu, 30 Jul 2009 12:47:01 -0400 Received: from PACDCEXCMB06.cable.comcast.com ([24.40.15.22]) by PACDCEXCSMTP03.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 30 Jul 2009 12:47:01 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 30 Jul 2009 12:46:00 -0400 Message-ID: In-Reply-To: <039901ca1124$2002cdf0$45012b0a@975DEF9223E44C7> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [decade] DECADE meeting minutes Thread-Index: AcoRJGWfJP/3MCwuSNGPSWkhZ23G/wACJcNg References: <039901ca1124$2002cdf0$45012b0a@975DEF9223E44C7> From: "Woundy, Richard" To: "Song Haibin" , X-OriginalArrivalTime: 30 Jul 2009 16:47:01.0010 (UTC) FILETIME=[5C213720:01CA1135] Subject: Re: [decade] DECADE meeting minutes X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2009 16:47:32 -0000 In the minutes, I think I am both "Rich Woundy" and "Rich from ISP". > Rich Woundy- current caching system based on transparent passing by which they ssume that if it is p2p protocol they put cache inline of the transmission line. They put the cache inline, or they intercept the traffic inline ala DPI. > Rich from an ISP: stating saving uplink is too broad scope, but it is not specific to P2P. Actually, I think I said that "saving uplink bandwidth" is too broad of a statement. Some ISPs benefit from reduced uplink traffic, others do not. >Question from Rich (ISP): does Locker associate with mega data? My question was, does the Locker store both the content and its associated metadata. Here is a concrete example of what I mean by metadata: see the BitTorrent description of 'metainfo' in http://www.bittorrent.org/beps/bep_0003.html. Or possibly just the 'info_hash'. Essentially I mean the data that helps identify the content. > j.. Q from Rich Woundy: Did you cover InterStream? which is a Multi-ISP CDN method. Multiple ISP provided contents to a common content distribution network. Another similar aspect is Remote DVR, which requires to story separate copy in multiple caches due to legal issues. With Remote DVR, video content is kept in centralized storage (by the cable operator), with each cable subscriber getting their own allocation of storage, and their own copies of video content. This approach was debated for years in the US courts, and an appeal to the US supreme court was recently rejected. http://www.engadget.com/2006/03/27/cablevision-to-rollout-remote-storage -dvr-service/ http://arstechnica.com/tech-policy/news/2009/06/cablevision-remote-dvr-s tays-legal-supremes-wont-hear-case.ars My point is that there can be legal issues associated with content storage -- even outside the 'content piracy' domain. > l.. Rich Woundy: if mega data is stored with data, ISP is liable for validate the source, otherwise the ISP can get sued Again "mega data" should be "metadata". Let me explain the dilemma better. Let's start with the scenario where some subscriber has placed copyright infringing content in the "Locker", and the offended content provider has detected this. In the US, the content provider sends a "take down notice" to the ISP, and the ISP is expected to remove the offending content. If the metadata is associated with the content data in the Locker, then the ISP can find the offending content and delete it. The Locker can also be programmed to prevent any other data associated with the metadata from being stored in the Locker (aka "blacklisting"). The downside is that some customers may prefer the anonymity of content within their own Locker, even for non-piracy-related reasons. But is anonymity important? Maybe not for public P2P file sharing??? Now suppose that metadata is not associated with the content data in the Locker. Then the required response by the ISP becomes much more complicated. First possible response: the ISP might say that it cannot determine which data in the Locker is offending content and therefore do nothing; this response would likely prompt the content providers to advocate for tougher anti-piracy regulations (because they would see this as a 'piracy loophole'). Second possible response: the ISP might choose to remove *all* the content from that subscriber's Locker; that might satisfy the content provider, but the ISP may be deleting non-infringing content as well as the offending content, which doesn't seem user-friendly. Third possible response: the ISP turns off the Locker because it seems like the "safest" approach. -- Rich -----Original Message----- From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.org] On Behalf Of Song Haibin Sent: Thursday, July 30, 2009 10:44 AM To: decade@ietf.org Subject: [decade] DECADE meeting minutes Hi all, Here are the meeting notes of DECADE Bar BOF. It's a merged version from the notes taken by Roni and Linda. Please check for consistency with your own memories! DECADE BAR BOF There were about 50 people in the room Yu Shun and Haibin chaired the BOF The Chair announced the agenda and announced IETF policy. Agenda bashing (chairs) Eric - leave time to discuss the objectives and if this is a topic for IETF Yu-Shun: there are no drafts yet Goals & Next steps Introduction: Architecture framework - application agnostics in network caches for both p2p and client server applications. Main components - had a simplified picture. Qusetions:=20 Should the cache be between the source and client - response: it depends on how it is deployed. Linda: Will the cache be a published server, who owns them who provide - response: there are several options including server providers and ISPs. This is not a complete picture.=20 Volker: caches exists (CDN) why not say HTTP is the protocol and we are pushing the data to them. Response: The result of the requirements may be the current CDN but there are issues. It will be discussed later. HTTP might be a possible solution. Dave Crocker: Sounds like using standard CDN protocol and check if existing CDN is not efficient. If the existing protocols are not enough, can you list them? Response: It will be discussed on the second presentation. =20 Yunfei - Will we standardize the cache to cache - Response: this is a scope question =20 =20 Then Haibin presented Problem Statements: Rich Woundy: Reduce uplink will definitely help me as an ISP. But other ISPs may not have this problem. Is it universal true that reducing uplink bandwidth is an issue? Wireless operator may have this issue.=20 =20 Kar from Vodafone agreed: it is true that uplink bandwidth is an issue. They do want to reduce uplink. But they believe that Cache will reduce the downlink as well.=20 =20 Dave Crocker: Now you are talking about link behavior. P2P is many things. If you don't have specific application at the beginning, then this is an abstract discussion. Therefore, the debate is not very useful.=20 Yu Shun - need not to concentrate on the link but application use cases. Dave Crocker: Caching will not solve problem for IM and IM is P2P. Richard Alimi stated one example of File Sharing, which can demonstrate that the caching can reduce the link utilization.=20 =20 Lucy Yong: saving the uplink is not the main driving force. It is for saving both links.=20 Rich Woundy- current caching system based on transparent passing by which they ssume that if it is p2p protocol they put cache inline of the transmission line. Answer: you do not have to intercept traffic to cache it. It will be in the requirement. =20 The direction is for off path cache but the peer will be aware=20 Qustion from Rich Woundy: There are a lot of cache vendors. Using DPI to re-direct the traffic. Is it the assumption for transparent caching? =20 Richard Alimi: It should have a requirement that caching failure should allow the P2P to resume the normal communication. =20 Steven Right: Do you mean multiple systems sharing the single cache? Do you need to configure how much cache should be reserved to BitTorrent? Answer: it should depend on the configuration.=20 =20 Rich from an ISP: stating saving uplink is too broad scope, but it is not specific to P2P.=20 Response: The cache solution can be used to non p2p solution. The bar BOF is about p2p Q: When you say that P2P represent 40% traffic of internet, what other traffic are in the network. Answer: it is not the concern for this work. ZongNing: web cache is another way of caching. Now we want to find other way to cache Q: using the cache is not mandatory so there need to be motivation for clients to use them. Answer: maybe better performance, so that P2P software wants to use it.=20 Q: what is the difference between your protocol and RELOAD?=20 a.. Response from the chair of P2PSIP, David Bryan stated RELOAD is for resource discovery.=20 Vijay: what is the role of caching in the streaming application? When the load is consistent Q: is it desirable to make it the goal of this BoF to have certain location or structure will make this protocol practical? Chair: let's see first if the protocol is interesting enough to get down to the topology.=20 Kar: Is it specifically for P2P or others? Chair: The motivation is from P2P, but solution could be used for others. Let's consider it for future.=20 Q: who decides what to be stored in the cache? Answer: The third presentation will show a possible example of the details.=20 =20 Then Ning Zong and Richard Alimi did joint presentation on Survey slides. Network storage system components Web Caching: use HTTP, but not designed for P2P applications.=20 Transparent P2P Cache and non-transparent P2P cache =20 CDN: Push the content to the edge, but not designed for P2P. Discussion about the issue of resource control requirement. Q: What do you mean by saying it doesn't provide resource control? Answer: the push model doesn't require the content from the content provider to know the bandwidth available for the client.=20 =20 Richard Alimi's presentation on Amazon S3, Windows Azure, Ocean Store, iSCSI Doesn't provide the resource control (bandwidth and connections) Question from Dave Crocker: what is the access control? Answer: the peer client should have control on which peer to have the content. Dave from Verizon: what is the topology for caching? Is it for unicast or multicast? Answer: it is not important at this point.=20 =20 Then Richard Alimi did Sailor presentation. Possible solution to decade Use application agnostic data lockers. Change from "client to client P2P data", to using data locker for client to get data from Cache as if it gets the data from the other client.=20 Rich Woundy - is there a relation between the chunks ids in bit torrent and the ones in the cache - response they are not the same but mapping is required Question - can the client control the life time of the data in the cache - for example time for file sharing compared to streaming chunks.=20 Richard yes it will be considered. Question from Rich (ISP): does Locker associate with mega data?=20 Questoin from Rich (ISP): should you allocate a timer to a block of data? Answer: another way is to specify a cache policy.=20 Kar (Vodafone): for optimization: maybe only store for x minutes, but not the entire length. =20 Locker Access Protocol (LAP) Question from Eric: how to revoke the access? Answer: permanent grant Question: how to protect privacy? Like IP address. Answer: today's DPI already expose the IP address Branch cache - Yu-Shun There is IPR on some of the content The motivation was for branch offices of large corporation where the data is usually in the main office and the cost of communication to the branch are large. a.. Decouple the application protocol from cache.=20 b.. Goal: to reduce the link utilization. Local search requires authentication before searching the local content.=20 c.. Distributed Cache:=20 d.. Hosted Cache:=20 e.. Q from Lucy: will App Get have authentication? A: yes. If the authentication fails, there is no key coming back.=20 f.. Break the content to segment and blocks. Segments have ID, which is used by client to search g.. All the data transfer uses HTTP h.. Q: if the content has any changes, will the client get updated information? A: All content searches have to go to the center to get authentication. If there is any change to the content, the data center will inform the change status when passing down the key. i.. For more information: www.branchcache.com j.. Q from Rich Woundy: Did you cover InterStream? which is a Multi-ISP CDN method. Multiple ISP provided contents to a common content distribution network. Another similar aspect is Remote DVR, which requires to story separate copy in multiple caches due to legal issues. Bill stated: we decide to turn the cache off due to the regulatory issue.=20 k.. Eric: will ISP be interested in providing this?=20 l.. Rich Woundy: if mega data is stored with data, ISP is liable for validate the source, otherwise the ISP can get sued Eric Roger: if an employee has a pirated data on his/her laptop, an enterprise backing off the content can get into legal trouble. Request - to make the presentations available http://www.branchcache.com Rich - did you look at interstream association http://interstream.com/ , another solution is remote dvr set by cablevision =20 Chair: how many people think it should be worked in IETF? Majority of people raised their hands.=20 Volker: I am not fully convinced it is a problem.=20 How many would like to work on this problem if it becomes a work in the IETF.=20 There were about 23 hands =20 Thanks, Haibin From melodysong@huawei.com Thu Jul 30 23:53:05 2009 Return-Path: X-Original-To: decade@core3.amsl.com Delivered-To: decade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8636028C10F for ; Thu, 30 Jul 2009 23:53:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[AWL=0.701, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id liSL0fD4Pvpo for ; Thu, 30 Jul 2009 23:53:03 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 4511428B56A for ; Thu, 30 Jul 2009 23:53:03 -0700 (PDT) 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 <0KNM008QVWGFHE@szxga04-in.huawei.com> for decade@ietf.org; Fri, 31 Jul 2009 14:53:03 +0800 (CST) Received: from huawei.com ([172.24.1.3]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KNM00HM7WGFZ9@szxga04-in.huawei.com> for decade@ietf.org; Fri, 31 Jul 2009 14:53:03 +0800 (CST) Received: from 975DEF9223E44C7 ([77.241.97.115]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KNM004G6WGB1I@szxml01-in.huawei.com>; Fri, 31 Jul 2009 14:53:03 +0800 (CST) Date: Fri, 31 Jul 2009 08:52:51 +0200 From: Song Haibin To: "Woundy, Richard" , decade@ietf.org Message-id: <002b01ca11ab$8a38ab90$45012b0a@975DEF9223E44C7> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <039901ca1124$2002cdf0$45012b0a@975DEF9223E44C7> Subject: Re: [decade] DECADE meeting minutes X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2009 06:53:05 -0000 Hi Rich, Thank you for correcting and detailed explanations. BR, Haibin ----- Original Message ----- From: "Woundy, Richard" To: "Song Haibin" ; Sent: Thursday, July 30, 2009 6:46 PM Subject: RE: [decade] DECADE meeting minutes In the minutes, I think I am both "Rich Woundy" and "Rich from ISP". > Rich Woundy- current caching system based on transparent passing by which they ssume that if it is p2p protocol they put cache inline of the transmission line. They put the cache inline, or they intercept the traffic inline ala DPI. > Rich from an ISP: stating saving uplink is too broad scope, but it is not specific to P2P. Actually, I think I said that "saving uplink bandwidth" is too broad of a statement. Some ISPs benefit from reduced uplink traffic, others do not. >Question from Rich (ISP): does Locker associate with mega data? My question was, does the Locker store both the content and its associated metadata. Here is a concrete example of what I mean by metadata: see the BitTorrent description of 'metainfo' in http://www.bittorrent.org/beps/bep_0003.html. Or possibly just the 'info_hash'. Essentially I mean the data that helps identify the content. > j.. Q from Rich Woundy: Did you cover InterStream? which is a Multi-ISP CDN method. Multiple ISP provided contents to a common content distribution network. Another similar aspect is Remote DVR, which requires to story separate copy in multiple caches due to legal issues. With Remote DVR, video content is kept in centralized storage (by the cable operator), with each cable subscriber getting their own allocation of storage, and their own copies of video content. This approach was debated for years in the US courts, and an appeal to the US supreme court was recently rejected. http://www.engadget.com/2006/03/27/cablevision-to-rollout-remote-storage -dvr-service/ http://arstechnica.com/tech-policy/news/2009/06/cablevision-remote-dvr-s tays-legal-supremes-wont-hear-case.ars My point is that there can be legal issues associated with content storage -- even outside the 'content piracy' domain. > l.. Rich Woundy: if mega data is stored with data, ISP is liable for validate the source, otherwise the ISP can get sued Again "mega data" should be "metadata". Let me explain the dilemma better. Let's start with the scenario where some subscriber has placed copyright infringing content in the "Locker", and the offended content provider has detected this. In the US, the content provider sends a "take down notice" to the ISP, and the ISP is expected to remove the offending content. If the metadata is associated with the content data in the Locker, then the ISP can find the offending content and delete it. The Locker can also be programmed to prevent any other data associated with the metadata from being stored in the Locker (aka "blacklisting"). The downside is that some customers may prefer the anonymity of content within their own Locker, even for non-piracy-related reasons. But is anonymity important? Maybe not for public P2P file sharing??? Now suppose that metadata is not associated with the content data in the Locker. Then the required response by the ISP becomes much more complicated. First possible response: the ISP might say that it cannot determine which data in the Locker is offending content and therefore do nothing; this response would likely prompt the content providers to advocate for tougher anti-piracy regulations (because they would see this as a 'piracy loophole'). Second possible response: the ISP might choose to remove *all* the content from that subscriber's Locker; that might satisfy the content provider, but the ISP may be deleting non-infringing content as well as the offending content, which doesn't seem user-friendly. Third possible response: the ISP turns off the Locker because it seems like the "safest" approach. -- Rich -----Original Message----- From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.org] On Behalf Of Song Haibin Sent: Thursday, July 30, 2009 10:44 AM To: decade@ietf.org Subject: [decade] DECADE meeting minutes Hi all, Here are the meeting notes of DECADE Bar BOF. It's a merged version from the notes taken by Roni and Linda. Please check for consistency with your own memories! DECADE BAR BOF There were about 50 people in the room Yu Shun and Haibin chaired the BOF The Chair announced the agenda and announced IETF policy. Agenda bashing (chairs) Eric - leave time to discuss the objectives and if this is a topic for IETF Yu-Shun: there are no drafts yet Goals & Next steps Introduction: Architecture framework - application agnostics in network caches for both p2p and client server applications. Main components - had a simplified picture. Qusetions: Should the cache be between the source and client - response: it depends on how it is deployed. Linda: Will the cache be a published server, who owns them who provide - response: there are several options including server providers and ISPs. This is not a complete picture. Volker: caches exists (CDN) why not say HTTP is the protocol and we are pushing the data to them. Response: The result of the requirements may be the current CDN but there are issues. It will be discussed later. HTTP might be a possible solution. Dave Crocker: Sounds like using standard CDN protocol and check if existing CDN is not efficient. If the existing protocols are not enough, can you list them? Response: It will be discussed on the second presentation. Yunfei - Will we standardize the cache to cache - Response: this is a scope question Then Haibin presented Problem Statements: Rich Woundy: Reduce uplink will definitely help me as an ISP. But other ISPs may not have this problem. Is it universal true that reducing uplink bandwidth is an issue? Wireless operator may have this issue. Kar from Vodafone agreed: it is true that uplink bandwidth is an issue. They do want to reduce uplink. But they believe that Cache will reduce the downlink as well. Dave Crocker: Now you are talking about link behavior. P2P is many things. If you don't have specific application at the beginning, then this is an abstract discussion. Therefore, the debate is not very useful. Yu Shun - need not to concentrate on the link but application use cases. Dave Crocker: Caching will not solve problem for IM and IM is P2P. Richard Alimi stated one example of File Sharing, which can demonstrate that the caching can reduce the link utilization. Lucy Yong: saving the uplink is not the main driving force. It is for saving both links. Rich Woundy- current caching system based on transparent passing by which they ssume that if it is p2p protocol they put cache inline of the transmission line. Answer: you do not have to intercept traffic to cache it. It will be in the requirement. The direction is for off path cache but the peer will be aware Qustion from Rich Woundy: There are a lot of cache vendors. Using DPI to re-direct the traffic. Is it the assumption for transparent caching? Richard Alimi: It should have a requirement that caching failure should allow the P2P to resume the normal communication. Steven Right: Do you mean multiple systems sharing the single cache? Do you need to configure how much cache should be reserved to BitTorrent? Answer: it should depend on the configuration. Rich from an ISP: stating saving uplink is too broad scope, but it is not specific to P2P. Response: The cache solution can be used to non p2p solution. The bar BOF is about p2p Q: When you say that P2P represent 40% traffic of internet, what other traffic are in the network. Answer: it is not the concern for this work. ZongNing: web cache is another way of caching. Now we want to find other way to cache Q: using the cache is not mandatory so there need to be motivation for clients to use them. Answer: maybe better performance, so that P2P software wants to use it. Q: what is the difference between your protocol and RELOAD? a.. Response from the chair of P2PSIP, David Bryan stated RELOAD is for resource discovery. Vijay: what is the role of caching in the streaming application? When the load is consistent Q: is it desirable to make it the goal of this BoF to have certain location or structure will make this protocol practical? Chair: let's see first if the protocol is interesting enough to get down to the topology. Kar: Is it specifically for P2P or others? Chair: The motivation is from P2P, but solution could be used for others. Let's consider it for future. Q: who decides what to be stored in the cache? Answer: The third presentation will show a possible example of the details. Then Ning Zong and Richard Alimi did joint presentation on Survey slides. Network storage system components Web Caching: use HTTP, but not designed for P2P applications. Transparent P2P Cache and non-transparent P2P cache CDN: Push the content to the edge, but not designed for P2P. Discussion about the issue of resource control requirement. Q: What do you mean by saying it doesn't provide resource control? Answer: the push model doesn't require the content from the content provider to know the bandwidth available for the client. Richard Alimi's presentation on Amazon S3, Windows Azure, Ocean Store, iSCSI Doesn't provide the resource control (bandwidth and connections) Question from Dave Crocker: what is the access control? Answer: the peer client should have control on which peer to have the content. Dave from Verizon: what is the topology for caching? Is it for unicast or multicast? Answer: it is not important at this point. Then Richard Alimi did Sailor presentation. Possible solution to decade Use application agnostic data lockers. Change from "client to client P2P data", to using data locker for client to get data from Cache as if it gets the data from the other client. Rich Woundy - is there a relation between the chunks ids in bit torrent and the ones in the cache - response they are not the same but mapping is required Question - can the client control the life time of the data in the cache - for example time for file sharing compared to streaming chunks. Richard yes it will be considered. Question from Rich (ISP): does Locker associate with mega data? Questoin from Rich (ISP): should you allocate a timer to a block of data? Answer: another way is to specify a cache policy. Kar (Vodafone): for optimization: maybe only store for x minutes, but not the entire length. Locker Access Protocol (LAP) Question from Eric: how to revoke the access? Answer: permanent grant Question: how to protect privacy? Like IP address. Answer: today's DPI already expose the IP address Branch cache - Yu-Shun There is IPR on some of the content The motivation was for branch offices of large corporation where the data is usually in the main office and the cost of communication to the branch are large. a.. Decouple the application protocol from cache. b.. Goal: to reduce the link utilization. Local search requires authentication before searching the local content. c.. Distributed Cache: d.. Hosted Cache: e.. Q from Lucy: will App Get have authentication? A: yes. If the authentication fails, there is no key coming back. f.. Break the content to segment and blocks. Segments have ID, which is used by client to search g.. All the data transfer uses HTTP h.. Q: if the content has any changes, will the client get updated information? A: All content searches have to go to the center to get authentication. If there is any change to the content, the data center will inform the change status when passing down the key. i.. For more information: www.branchcache.com j.. Q from Rich Woundy: Did you cover InterStream? which is a Multi-ISP CDN method. Multiple ISP provided contents to a common content distribution network. Another similar aspect is Remote DVR, which requires to story separate copy in multiple caches due to legal issues. Bill stated: we decide to turn the cache off due to the regulatory issue. k.. Eric: will ISP be interested in providing this? l.. Rich Woundy: if mega data is stored with data, ISP is liable for validate the source, otherwise the ISP can get sued Eric Roger: if an employee has a pirated data on his/her laptop, an enterprise backing off the content can get into legal trouble. Request - to make the presentations available http://www.branchcache.com Rich - did you look at interstream association http://interstream.com/ , another solution is remote dvr set by cablevision Chair: how many people think it should be worked in IETF? Majority of people raised their hands. Volker: I am not fully convinced it is a problem. How many would like to work on this problem if it becomes a work in the IETF. There were about 23 hands Thanks, Haibin From spis@intracom.com Thu Jul 30 23:55:23 2009 Return-Path: X-Original-To: decade@core3.amsl.com Delivered-To: decade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 92B483A6966 for ; Thu, 30 Jul 2009 23:55:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uUMOzYdl8Am5 for ; Thu, 30 Jul 2009 23:55:22 -0700 (PDT) Received: from extmail.intranet.gr (extmail.intranet.GR [192.92.155.11]) by core3.amsl.com (Postfix) with ESMTP id 7BAB83A6812 for ; Thu, 30 Jul 2009 23:55:22 -0700 (PDT) Received: from mailserv.intranet.gr (mailserv [146.124.14.106]) by extmail.intranet.gr (8.13.8/8.13.8) with ESMTP id n6V6tHxB002139 for ; Fri, 31 Jul 2009 09:55:17 +0300 (EEST) Received: from mailserv.intranet.gr (localhost [127.0.0.1]) by mailserv.intranet.gr (8.13.6/8.13.1) with ESMTP id n6V6tGMq013688 for ; Fri, 31 Jul 2009 09:55:16 +0300 (EEST) Received: from iris.intranet.gr (iris.intranet.GR [146.124.80.178]) by mailserv.intranet.gr (8.13.6/8.13.1) with ESMTP id n6V6tFNF013673; Fri, 31 Jul 2009 09:55:15 +0300 (EEST) Received: from [146.124.44.139] ([146.124.44.139] verified) by iris.intranet.gr (CommuniGate Pro SMTP 5.2.11) with ESMTP id 29903962; Fri, 31 Jul 2009 09:55:15 +0300 Message-ID: <4A72940E.6000907@intracom.com> Date: Fri, 31 Jul 2009 09:49:50 +0300 From: Spiros Spirou Organization: Intracom Telecom User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Song Haibin References: <039901ca1124$2002cdf0$45012b0a@975DEF9223E44C7> In-Reply-To: <039901ca1124$2002cdf0$45012b0a@975DEF9223E44C7> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: decade@ietf.org Subject: Re: [decade] DECADE meeting minutes X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: spis@intracom.com List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2009 06:55:23 -0000 I didn't attend the BoF, so I quickly went over the minutes. (BTW, thanks to the note takers). I'm surprised that the legal issues associated with the storage of copyright-infringing content in P2P caches were not debated further. I've been led to believe that P2P cache owners (e.g., ISPs) are liable for the content stored on their caches and this is a show-stopper for work on P2P caches. Opinions? What's the situation outside the US? Thanks, Spiros From melodysong@huawei.com Fri Jul 31 00:10:49 2009 Return-Path: X-Original-To: decade@core3.amsl.com Delivered-To: decade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C07013A6D04 for ; Fri, 31 Jul 2009 00:10:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.073 X-Spam-Level: X-Spam-Status: No, score=-2.073 tagged_above=-999 required=5 tests=[AWL=0.526, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pf8RBeIP2IVn for ; Fri, 31 Jul 2009 00:10:49 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id CC6B73A6CBC for ; Fri, 31 Jul 2009 00:10:48 -0700 (PDT) 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 <0KNM008EQX7PHH@szxga04-in.huawei.com> for decade@ietf.org; Fri, 31 Jul 2009 15:09:25 +0800 (CST) Received: from huawei.com ([172.24.1.3]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KNM00H23X7PZ9@szxga04-in.huawei.com> for decade@ietf.org; Fri, 31 Jul 2009 15:09:25 +0800 (CST) Received: from 975DEF9223E44C7 ([77.241.97.115]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KNM005JYX7LGR@szxml01-in.huawei.com>; Fri, 31 Jul 2009 15:09:25 +0800 (CST) Date: Fri, 31 Jul 2009 09:09:17 +0200 From: Song Haibin To: spis@intracom.com Message-id: <004401ca11ad$d3a1c850$45012b0a@975DEF9223E44C7> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: text/plain; charset=UTF-8 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <039901ca1124$2002cdf0$45012b0a@975DEF9223E44C7> <4A72940E.6000907@intracom.com> Cc: decade@ietf.org Subject: Re: [decade] DECADE meeting minutes X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2009 07:10:49 -0000 Hi Spiros, It's really a very interesting question. "Legal" means different things in different countries. I know some organizations are trying hard to protect the copyright using DRM mechanisms. We really don't want to touch the legal issues and the content itself. Haibin ----- Original Message ----- From: "Spiros Spirou" To: "Song Haibin" Cc: Sent: Friday, July 31, 2009 8:49 AM Subject: Re: [decade] DECADE meeting minutes >I didn't attend the BoF, so I quickly went over the minutes. (BTW, > thanks to the note takers). > > I'm surprised that the legal issues associated with the storage of > copyright-infringing content in P2P caches were not debated further. > I've been led to believe that P2P cache owners (e.g., ISPs) are liable > for the content stored on their caches and this is a show-stopper for > work on P2P caches. Opinions? What's the situation outside the US? > > Thanks, > > Spiros From guyingjie@huawei.com Fri Jul 31 00:34:29 2009 Return-Path: X-Original-To: decade@core3.amsl.com Delivered-To: decade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B6913A6CD6 for ; Fri, 31 Jul 2009 00:34:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.294 X-Spam-Level: ** X-Spam-Status: No, score=2.294 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CN_BODY_35=0.339, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_CHARSET_FARAWAY=2.45, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cH-0LMRrVUy4 for ; Fri, 31 Jul 2009 00:34:28 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id A5F7B3A6BCD for ; Fri, 31 Jul 2009 00:33:43 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KNM008QIYBZ5H@szxga03-in.huawei.com> for decade@ietf.org; Fri, 31 Jul 2009 15:33:35 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KNM00JQ7YBZPN@szxga03-in.huawei.com> for decade@ietf.org; Fri, 31 Jul 2009 15:33:35 +0800 (CST) Received: from g00107907 ([10.164.12.64]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KNM00EHZYBWED@szxml04-in.huawei.com> for decade@ietf.org; Fri, 31 Jul 2009 15:33:35 +0800 (CST) Date: Fri, 31 Jul 2009 15:33:32 +0800 From: "Y.J. Gu" In-reply-to: To: "'Woundy, Richard'" , 'Song Haibin' , decade@ietf.org Message-id: <003101ca11b1$351d80d0$400ca40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=gb2312 Content-transfer-encoding: quoted-printable Thread-index: AcoRJGWfJP/3MCwuSNGPSWkhZ23G/wACJcNgAB6l2PA= Subject: Re: [decade] DECADE meeting minutes X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2009 07:34:29 -0000 Hi, this is Yingjie. Thanks to chairs and attendees. Glad to see that many people are interested in this topic, that's a good beginning to DECADE.=20 However we still have much work to do before IETF 76, following are my conclusion of what to do according to the meeting minutes.=20 1) Motivation clarification; First, saving uplink/downlink bandwidth is = a possible motivation, although it may be not true for all ISPs, it really helps a lot. Second, for each application it supports, the existing = cache has to understand the corresponding protocol, which makes it painful to adapt new applications, especially in flourishing P2P. 2) Advantages over existing mechanisms; maybe not overwhelming = advantage, but it should be clarified about what DECADE can do (or do better) while = the others cannot, i.e. why we need a new one instead of reusing the = existing ones with some modification. =20 3) Specific application use case; I agree with Yu Shun that we should = first list the applications that might benefits from DECADE, meanwhile specify = how and how much these apps will benefit. 4) Legal issues; Sure it is not so much important in some countries as = in others, but we should give some consideration or further explanation = before simply leaving it out of account. Hope for more comments and proposals. Regards Yingjie Gu -----=D3=CA=BC=FE=D4=AD=BC=FE----- =B7=A2=BC=FE=C8=CB: decade-bounces@ietf.org = [mailto:decade-bounces@ietf.org] =B4=FA=B1=ED Woundy, Richard =B7=A2=CB=CD=CA=B1=BC=E4: 2009=C4=EA7=D4=C231=C8=D5 =C0=D6=C0=D60:46 =CA=D5=BC=FE=C8=CB: Song Haibin; decade@ietf.org =D6=F7=CC=E2: Re: [decade] DECADE meeting minutes In the minutes, I think I am both "Rich Woundy" and "Rich from ISP". > Rich Woundy- current caching system based on transparent passing by which they ssume that if it is p2p protocol they put cache inline of the transmission line. They put the cache inline, or they intercept the traffic inline ala DPI............ From richard_woundy@cable.comcast.com Fri Jul 31 01:07:33 2009 Return-Path: X-Original-To: decade@core3.amsl.com Delivered-To: decade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 278D028C28A for ; Fri, 31 Jul 2009 01:07:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.463 X-Spam-Level: X-Spam-Status: No, score=-6.463 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SLKZyxoGOG9v for ; Fri, 31 Jul 2009 01:07:32 -0700 (PDT) Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by core3.amsl.com (Postfix) with ESMTP id 3226B28C254 for ; Fri, 31 Jul 2009 01:07:32 -0700 (PDT) Received: from ([10.195.246.152]) by pacdcimo01.cable.comcast.com with ESMTP id 5503620.47881409; Fri, 31 Jul 2009 04:07:20 -0400 Received: from PACDCEXCMB06.cable.comcast.com ([24.40.15.22]) by NJMDCEXCRLY01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 31 Jul 2009 04:07:20 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Fri, 31 Jul 2009 04:06:55 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [decade] DECADE meeting minutes Thread-Index: AcoRq/La9vi19VlDTRmKuuTOigycEAACb+oF From: "Woundy, Richard" To: , X-OriginalArrivalTime: 31 Jul 2009 08:07:20.0874 (UTC) FILETIME=[EDBBC8A0:01CA11B5] Cc: decade@ietf.org Subject: Re: [decade] DECADE meeting minutes X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2009 08:07:33 -0000 PkknbSBzdXJwcmlzZWQgdGhhdCB0aGUgbGVnYWwgaXNzdWVzIGFzc29jaWF0ZWQgd2l0aCB0aGUg c3RvcmFnZSBvZiBjb3B5cmlnaHQtaW5mcmluZ2luZyBjb250ZW50IGluIFAyUCBjYWNoZXMgd2Vy ZSBub3QgZGViYXRlZCBmdXJ0aGVyLiANCg0KVGhhdCdzIGJlY2F1c2Ugd2Ugd291bGQgaGF2ZSBi ZWVuIHRyYXBwZWQgaW4gdGhlIG1lZXRpbmcgdmVudWUgYWxsIG5pZ2h0LiA6KQ0KDQpUaGUgbWVl dGluZyByYW4gdG8gMjI6MDAsIHdoaWNoIGlzIGFsc28gdGhlIHNhbWUgdGltZSB0aGF0IHRoZSBi dWlsZGluZyBjbG9zZWQuDQoNCkFsc28sIHdlJ3JlIGVuZ2luZWVycyBub3QgbGF3eWVycyAoYXQg bGVhc3QgbW9zdCBvZiB1cykuDQoNCg0KLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLQ0KRnJv bTogZGVjYWRlLWJvdW5jZXNAaWV0Zi5vcmcgPGRlY2FkZS1ib3VuY2VzQGlldGYub3JnPg0KVG86 IFNvbmcgSGFpYmluIDxtZWxvZHlzb25nQGh1YXdlaS5jb20+DQpDYzogZGVjYWRlQGlldGYub3Jn IDxkZWNhZGVAaWV0Zi5vcmc+DQpTZW50OiBGcmkgSnVsIDMxIDAyOjQ5OjUwIDIwMDkNClN1Ympl Y3Q6IFJlOiBbZGVjYWRlXSBERUNBREUgbWVldGluZyBtaW51dGVzDQoNCkkgZGlkbid0IGF0dGVu ZCB0aGUgQm9GLCBzbyBJIHF1aWNrbHkgd2VudCBvdmVyIHRoZSBtaW51dGVzLiAoQlRXLCANCnRo YW5rcyB0byB0aGUgbm90ZSB0YWtlcnMpLg0KDQpJJ20gc3VycHJpc2VkIHRoYXQgdGhlIGxlZ2Fs IGlzc3VlcyBhc3NvY2lhdGVkIHdpdGggdGhlIHN0b3JhZ2Ugb2YgDQpjb3B5cmlnaHQtaW5mcmlu Z2luZyBjb250ZW50IGluIFAyUCBjYWNoZXMgd2VyZSBub3QgZGViYXRlZCBmdXJ0aGVyLiANCkkn dmUgYmVlbiBsZWQgdG8gYmVsaWV2ZSB0aGF0IFAyUCBjYWNoZSBvd25lcnMgKGUuZy4sIElTUHMp IGFyZSBsaWFibGUgDQpmb3IgdGhlIGNvbnRlbnQgc3RvcmVkIG9uIHRoZWlyIGNhY2hlcyBhbmQg dGhpcyBpcyBhIHNob3ctc3RvcHBlciBmb3IgDQp3b3JrIG9uIFAyUCBjYWNoZXMuIE9waW5pb25z PyBXaGF0J3MgdGhlIHNpdHVhdGlvbiBvdXRzaWRlIHRoZSBVUz8NCg0KVGhhbmtzLA0KDQpTcGly b3MNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpkZWNh ZGUgbWFpbGluZyBsaXN0DQpkZWNhZGVAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vZGVjYWRlDQo= From richard_woundy@cable.comcast.com Fri Jul 31 01:44:54 2009 Return-Path: X-Original-To: decade@core3.amsl.com Delivered-To: decade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 232F63A6E8B for ; Fri, 31 Jul 2009 01:44:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.13 X-Spam-Level: X-Spam-Status: No, score=-3.13 tagged_above=-999 required=5 tests=[AWL=-2.667, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X2imvlxI3CFy for ; Fri, 31 Jul 2009 01:44:53 -0700 (PDT) Received: from paoakoavas09.cable.comcast.com (paoakoavas09.cable.comcast.com [208.17.35.58]) by core3.amsl.com (Postfix) with ESMTP id BEE223A69DA for ; Fri, 31 Jul 2009 01:44:52 -0700 (PDT) Received: from ([24.40.15.118]) by paoakoavas09.cable.comcast.com with ESMTP id KP-NTF18.75989633; Fri, 31 Jul 2009 04:44:32 -0400 Received: from PACDCEXCMB06.cable.comcast.com ([24.40.15.22]) by PACDCEXCSMTP04.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 31 Jul 2009 04:44:33 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Fri, 31 Jul 2009 04:37:56 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [decade] DECADE meeting minutes Thread-Index: AcoRrhMIAxMKg5vfR7ygeO04szzXeQADB/Lr From: "Woundy, Richard" To: , X-OriginalArrivalTime: 31 Jul 2009 08:44:33.0980 (UTC) FILETIME=[20C4B7C0:01CA11BB] Cc: decade@ietf.org Subject: Re: [decade] DECADE meeting minutes X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2009 08:44:54 -0000 VGhlIGZpcnN0IGZldyBwYWdlcyBvZiBSRkMgMjgwNCBtYXkgYmUgcmVsZXZhbnQgaGVyZSwgZXZl biB0aG91Z2ggdGhhdCBSRkMgaXMgYWJvdXQgd2lyZXRhcHBpbmcsIG5vdCBjb3B5cmlnaHQgaW5m cmluZ2VtZW50Lg0KDQpodHRwOi8vd3d3LmlzaS5lZHUvaW4tbm90ZXMvcmZjMjgwNC50eHQNCg0K VGhlIGlzc3VlcyBhYm91dCB3aGF0IGNvbnN0aXR1dGVzIGEgbGVnYWwgY29weSBvZiBjb250ZW50 IGdvIGJleW9uZCBhbnRpLXBpcmFjeSBjb25jZXJucywgYnkgdGhlIHdheS4NCg0KV2Ugc2hvdWxk IHRyeSB0byB1bmRlcnN0YW5kIHdoZXRoZXIgdGhlIGxlZ2FsIGlzc3VlcyB3b3VsZCBwcmVjbHVk ZSBkZXBsb3ltZW50LiBJIHRoaW5rIGl0IGlzIHdheSB0b28gZWFybHkgdG8gZHJhdyBhbnkgY29u Y2x1c2lvbnMgYWJvdXQgZGVwbG95YWJpbGl0eSB5ZXQuDQoNCi0tIFJpY2gNCg0KDQotLS0tLSBP cmlnaW5hbCBNZXNzYWdlIC0tLS0tDQpGcm9tOiBkZWNhZGUtYm91bmNlc0BpZXRmLm9yZyA8ZGVj YWRlLWJvdW5jZXNAaWV0Zi5vcmc+DQpUbzogc3Bpc0BpbnRyYWNvbS5jb20gPHNwaXNAaW50cmFj b20uY29tPg0KQ2M6IGRlY2FkZUBpZXRmLm9yZyA8ZGVjYWRlQGlldGYub3JnPg0KU2VudDogRnJp IEp1bCAzMSAwMzowOToxNyAyMDA5DQpTdWJqZWN0OiBSZTogW2RlY2FkZV0gREVDQURFIG1lZXRp bmcgbWludXRlcw0KDQpIaSBTcGlyb3MsDQoNCkl0J3MgcmVhbGx5IGEgdmVyeSBpbnRlcmVzdGlu ZyBxdWVzdGlvbi4gIkxlZ2FsIiBtZWFucyBkaWZmZXJlbnQgdGhpbmdzIGluIGRpZmZlcmVudCBj b3VudHJpZXMuIEkga25vdyBzb21lIG9yZ2FuaXphdGlvbnMgYXJlIHRyeWluZyBoYXJkIHRvIHBy b3RlY3QgdGhlIGNvcHlyaWdodCB1c2luZyBEUk0gbWVjaGFuaXNtcy4gV2UgcmVhbGx5IGRvbid0 IHdhbnQgdG8gdG91Y2ggdGhlIGxlZ2FsIGlzc3VlcyBhbmQgdGhlIGNvbnRlbnQgaXRzZWxmLg0K DQpIYWliaW4NCg0KDQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIlNwaXJv cyBTcGlyb3UiIDxzcGlzQGludHJhY29tLmNvbT4NClRvOiAiU29uZyBIYWliaW4iIDxtZWxvZHlz b25nQGh1YXdlaS5jb20+DQpDYzogPGRlY2FkZUBpZXRmLm9yZz4NClNlbnQ6IEZyaWRheSwgSnVs eSAzMSwgMjAwOSA4OjQ5IEFNDQpTdWJqZWN0OiBSZTogW2RlY2FkZV0gREVDQURFIG1lZXRpbmcg bWludXRlcw0KDQoNCj5JIGRpZG4ndCBhdHRlbmQgdGhlIEJvRiwgc28gSSBxdWlja2x5IHdlbnQg b3ZlciB0aGUgbWludXRlcy4gKEJUVywgDQo+IHRoYW5rcyB0byB0aGUgbm90ZSB0YWtlcnMpLg0K PiANCj4gSSdtIHN1cnByaXNlZCB0aGF0IHRoZSBsZWdhbCBpc3N1ZXMgYXNzb2NpYXRlZCB3aXRo IHRoZSBzdG9yYWdlIG9mIA0KPiBjb3B5cmlnaHQtaW5mcmluZ2luZyBjb250ZW50IGluIFAyUCBj YWNoZXMgd2VyZSBub3QgZGViYXRlZCBmdXJ0aGVyLiANCj4gSSd2ZSBiZWVuIGxlZCB0byBiZWxp ZXZlIHRoYXQgUDJQIGNhY2hlIG93bmVycyAoZS5nLiwgSVNQcykgYXJlIGxpYWJsZSANCj4gZm9y IHRoZSBjb250ZW50IHN0b3JlZCBvbiB0aGVpciBjYWNoZXMgYW5kIHRoaXMgaXMgYSBzaG93LXN0 b3BwZXIgZm9yIA0KPiB3b3JrIG9uIFAyUCBjYWNoZXMuIE9waW5pb25zPyBXaGF0J3MgdGhlIHNp dHVhdGlvbiBvdXRzaWRlIHRoZSBVUz8NCj4gDQo+IFRoYW5rcywNCj4gDQo+IFNwaXJvcw0KX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCmRlY2FkZSBtYWls aW5nIGxpc3QNCmRlY2FkZUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9kZWNhZGUNCg== From spis@intracom.com Fri Jul 31 04:25:37 2009 Return-Path: X-Original-To: decade@core3.amsl.com Delivered-To: decade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 518BC3A6CB9 for ; Fri, 31 Jul 2009 04:25:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C5PnnLmeQovx for ; Fri, 31 Jul 2009 04:25:36 -0700 (PDT) Received: from extmail.intranet.gr (extmail.intranet.GR [192.92.155.11]) by core3.amsl.com (Postfix) with ESMTP id 3211A3A6B27 for ; Fri, 31 Jul 2009 04:25:35 -0700 (PDT) Received: from mailserv.intranet.gr (mailserv [146.124.14.106]) by extmail.intranet.gr (8.13.8/8.13.8) with ESMTP id n6VBPUrR026456 for ; Fri, 31 Jul 2009 14:25:30 +0300 (EEST) Received: from mailserv.intranet.gr (localhost [127.0.0.1]) by mailserv.intranet.gr (8.13.6/8.13.1) with ESMTP id n6VBPTbR002410 for ; Fri, 31 Jul 2009 14:25:30 +0300 (EEST) Received: from iris.intranet.gr (iris.intranet.GR [146.124.80.178]) by mailserv.intranet.gr (8.13.6/8.13.1) with ESMTP id n6VBPSS7002396; Fri, 31 Jul 2009 14:25:29 +0300 (EEST) Received: from [146.124.44.139] ([146.124.44.139] verified) by iris.intranet.gr (CommuniGate Pro SMTP 5.2.11) with ESMTP id 29910001; Fri, 31 Jul 2009 14:25:28 +0300 Message-ID: <4A72D363.8090002@intracom.com> Date: Fri, 31 Jul 2009 14:20:03 +0300 From: Spiros Spirou Organization: Intracom Telecom User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: "Woundy, Richard" References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: decade@ietf.org Subject: Re: [decade] DECADE meeting minutes X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: spis@intracom.com List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2009 11:25:37 -0000 Woundy, Richard wrote: >> I'm surprised that the legal issues associated with the storage of copyright-infringing content in P2P caches were not debated further. > > That's because we would have been trapped in the meeting venue all night. :) > > The meeting ran to 22:00, which is also the same time that the building closed. > > Also, we're engineers not lawyers (at least most of us). I understand. Discussions on this topic usually lead to nowhere. So, it's sensible to draw the line somewhere and get on with the work. The question is where this "somewhere" should be for DECADE? As we're now considering the DECADE framework, I thought it's a good time to try to answer this one. Intuitively, I agree with Haibin that we should not touch legal issues (and let the market sort these out). However, there's probably value in understanding the current and foreseen situation a bit better before making a decision. Does copyright-infringing content on P2P caches really create problems for ISPs? Will this change in the foreseeable future? Is it universal? Should DECADE do something about it? Any opinions on these, especially from people familiar with the ISP perspective, would be helpful. Thanks, Spiros From Yu-Shun.Wang@microsoft.com Fri Jul 31 09:16:43 2009 Return-Path: X-Original-To: decade@core3.amsl.com Delivered-To: decade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8BC8028C379 for ; Fri, 31 Jul 2009 09:16:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OGVKuak-Fant for ; Fri, 31 Jul 2009 09:16:42 -0700 (PDT) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.212]) by core3.amsl.com (Postfix) with ESMTP id F254628C380 for ; Fri, 31 Jul 2009 09:13:46 -0700 (PDT) Received: from TK5EX14HUBC101.redmond.corp.microsoft.com (157.54.7.153) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.2.99.4; Fri, 31 Jul 2009 09:13:48 -0700 Received: from TK5EX14MBXC112.redmond.corp.microsoft.com ([169.254.5.236]) by TK5EX14HUBC101.redmond.corp.microsoft.com ([157.54.7.153]) with mapi; Fri, 31 Jul 2009 09:13:48 -0700 From: Yu-Shun Wang To: "decade@ietf.org" Thread-Topic: [decade] DECADE meeting minutes Thread-Index: AQHKESRjJezFapK7BUCK2VMaw+xPvpCPVoFg Date: Fri, 31 Jul 2009 16:13:45 +0000 Message-ID: <81E94869FA91394CB0D6408786148E9B10483731@TK5EX14MBXC112.redmond.corp.microsoft.com> References: <039901ca1124$2002cdf0$45012b0a@975DEF9223E44C7> In-Reply-To: <039901ca1124$2002cdf0$45012b0a@975DEF9223E44C7> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [decade] DECADE meeting minutes X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2009 16:16:43 -0000 Hi, I've gone through the notes as well. Please take a look, especially those who contributed to the discussion. I have also asked Alexey. He agrees to put the slides up in the Wiki page. Thanks, Yushun & Haibin DECADE BAR BOF 7/29/2009 WED 8PM-10PM Room 201 Attendance: about 50 BoF Co-Chairs: Yu-Shun Wang & Haibin Son Note Takers: Linda Dunbar & Roni Even The Chair announced the agenda, Note Well 7 IPR policy. Agenda bashing (chairs) Eric Burger (EricB) - leave time to discuss the objectives and if this is a topic for IETF Yu-Shun: there are no drafts yet Goals & Next steps Introduction: Architecture framework - application agnostics in network caches for both p2p and client server applications. Main components - had a simplified picture. Qusetions: Q: Should the cache be between the source and client Answer (A): Response: it depends on how it is deployed. Linda: Will the cache be a published server, who owns them who provide A: There are several options including server providers and ISPs. This is not a complete picture. Volker: Caches exists (CDN) why not say HTTP is the protocol and we are pushing the data to them. A: The result of the requirements may be the current CDN but there are issues. It will be discussed later. HTTP might be a possible solution. Dave Crocker (DaveC): Sounds like using standard CDN protocol and check if existing CDN is not efficient. If the existing protocols are not enough, can you list them? A: It will be discussed on the second presentation. Yunfei - Will we standardize the cache to cache A: This is a scope question (Yushun: To further clarify, this will be considered. The current thinking is that it can be the same protocol as the one between client and cache.) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Then Haibin presented Problem Statements: Rich Woundy (RichW): Reduce uplink will definitely help me as an ISP. But other ISPs may not have this problem. Is it universal true that reducing uplink bandwidth is an issue? Wireless operator may have this issue. Kar from Vodafone agreed: it is true that uplink bandwidth is an issue. They do want to reduce uplink. But they believe that cache will reduce the downlink as well. DaveC: Now you are talking about link behavior. P2P is many things. If you don't have specific application at the beginning, then this is an abstract discussion. Therefore, the debate is not very useful. Yu Shun - So the feedback is that we should not just focus on link aspect but also the application use cases. DaveC: Caching will not solve problem for IM and IM is P2P. Richard Alimi (RichardA): File Sharing is one example, which can demonstrate that the caching can reduce the link utilization. Lucy Yong (LucyY): Saving the uplink is not the main driving force. It is for saving both links. RichW - (paraphrasing based on RichW's clarification) Current caching systems are usually deployed inline, or they can intercept packets for DPI. They use DPI to determine if the packets are p2p and whether to cache it or not. A: you do not have to intercept traffic to cache it. It will be in the requirement. The direction is for off path cache but the peer will be aware. RichW: There are a lot of cache vendors. Using DPI to re-direct the traffic. Is it the assumption for transparent caching? RichardA: It should have a requirement that caching failure should allow the P2P to resume the normal communication. Steven Right (StevenR): Do you mean multiple systems sharing the single cache? Do you need to configure how much cache should be reserved to BitTorrent? A: It should depend on the configuration. (It should be RichW: "Saving uplink is good for ISP" is probably too broad a statement. Some ISPs benefit from reduced uplink traffic, but some may not. Also it is not specific to P2P. A: The cache solution can be used to non p2p solution. The bar BOF is about p2p Q: When you say that P2P represent 40% traffic of internet, what other traffic are in the network. A: it is not the concern for this work. ZongNing: Web cache is another way of caching. Now we want to find other way to cache Q: Using the cache is not mandatory so there need to be motivation for clients to use them. Answer: maybe better performance, so that P2P software wants to use it. Q: What is the difference between your protocol and RELOAD? David Bryan (P2PSIP chair): RELOAD is for resource discovery. Vijay: what is the role of caching in the streaming application? When the load is consistent Q: Is it desirable to make it the goal of this BoF to have certain location or structure will make this protocol practical? Chair: Let's see first if the protocol is interesting enough to form a wg; then we can think if we want to get down to the topology and deployment optimization. Kar: Is it specifically for P2P or others? Chair: The motivation is from P2P, but solution could be used for others. Let's consider it for future. Q: Who decides what to be stored in the cache? Answer: The third presentation will show a possible example of the details. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Then Ning Zong and Richard Alimi did a joint presentation on Survey slides. Network storage system components Web Caching: use HTTP, but not designed for P2P applications. Transparent P2P Cache and non-transparent P2P cache CDN: Push the content to the edge, but not designed for P2P. Discussion about the issue of resource control requirement. Q: What do you mean by saying it doesn't provide resource control? A: The push model doesn't require the content from the content provider to know the bandwidth available for the client. Richard Alimi's presentation on Amazon S3, Windows Azure, Ocean Store, iSCSI Doesn't provide the resource control (bandwidth and connections) DaveC: What is the access control? A: the peer client should have control on which peer can access The content. David McDysan from Verizon (DavidM): What is the topology for caching? Is it for unicast or multicast? Answer: it is not important at this point. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Then Richard Alimi did Sailor presentation. Possible solution to decade Use application agnostic data lockers. Change from "client to client P2P data", to using data locker for client to get data from Cache as if it gets the data from the other client. RichW - Is there a relation between the chunks IDs in BitTorrent and the ones in the cache? A: They are not the same but mapping is required Q: Can the client control the life time of the data in the cache - for example time for file sharing compared to streaming chunks. RichardA: Yes it will be considered. RichW: Does Locker associate with meta data? A: Currently no. But it's possible to add. RichW: Should you allocate a timer to a block of data? A: Another way is to specify a cache policy. Kar (Vodafone): For optimization: maybe only store for x minutes, but not the entire length. Locker Access Protocol (LAP) EricB: How to revoke the access? Answer: Permanent grant? (Chair: I thought RichA said there is a valid time associated with the data?) Q: How to protect privacy? Like IP address. A: Today's DPI already expose the IP address =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Windows BranchCache Presentation - Yu-Shun Wang There is IPR on some of the content The motivation was for branch offices of large corporation where the data is usually in the main office and the cost of communication to the branch are high. - Decouple the application protocol from cache access protocol - Goal: To reduce the link utilization. - Local search requires authentication with the original content server before a client can search for the local content. - Distributed Cache: - Hosted Cache: Q from LucyY: will App Get have authentication? A: Yes. If the authentication fails, there is no content ID coming back. - Break the content to segment and blocks. Segments have ID, which is used by client to search - All the data transfer uses HTTP Q: if the content has any changes, will the client get updated information? A: All content accesses have to go to the content servers to get authentication. If there is any change to the content, the data center will need to generate new content IDs (hashes) and pass the new IDs back. Q: Would you publish the protocol? A: Currently, the protocol specification is available under the consent decree regulation license (not sure the complete or correct term here). We will need to discuss internally to see if we will write this up as informational RFC. - For more information: www.branchcache.com =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D General Discussion: RichW: Did you cover InterStream? which is a Multi-ISP CDN method. Multiple ISP provided contents to a common content distribution network. Another similar aspect is Remote DVR, which requires to story separate copy in multiple caches due to legal issues. Bill: We decide to turn the cache off due to the regulatory issue. EricB: Will ISP be interested in providing this? RichW: If meta data is stored with data, ISP is liable for Validating the source, otherwise the ISP can get sued EricB: If an employee has a pirated data on his/her laptop, an enterprise backing up the content can get into legal trouble. Request - to make the presentations available =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D BoF Summary Chair: How many people think it should be worked in IETF? Majority of people raised their hands. Volker: I am not fully convinced it is a problem. Chair: How many would like to work on this problem if it becomes a working group in the IETF. There were about 23 hands From guyingjie@huawei.com Fri Jul 31 22:07:34 2009 Return-Path: X-Original-To: decade@core3.amsl.com Delivered-To: decade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BCCA53A689F for ; Fri, 31 Jul 2009 22:07:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.451 X-Spam-Level: X-Spam-Status: No, score=0.451 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_93=0.6, MIME_CHARSET_FARAWAY=2.45] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SSOgghhANSAh for ; Fri, 31 Jul 2009 22:07:33 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 4851F3A6863 for ; Fri, 31 Jul 2009 22:07:33 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KNO0094CM8K96@szxga03-in.huawei.com> for decade@ietf.org; Sat, 01 Aug 2009 13:07:32 +0800 (CST) Received: from huawei.com ([172.17.1.36]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KNO00JL5M8JLB@szxga03-in.huawei.com> for decade@ietf.org; Sat, 01 Aug 2009 13:07:32 +0800 (CST) Received: from [172.24.1.3] (Forwarded-For: [114.221.140.92]) by szxmc04-in.huawei.com (mshttpd); Sat, 01 Aug 2009 13:07:31 +0800 Date: Sat, 01 Aug 2009 13:07:31 +0800 From: guyingjie 00107907 In-reply-to: <200907312328364066426@ctbri.com.cn> To: zhouky@ctbri.com.cn Message-id: MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 2.14 (built Aug 8 2006) Content-type: text/plain; charset=big5 Content-language: zh-tw Content-transfer-encoding: quoted-printable Content-disposition: inline X-Accept-Language: zh-TW Priority: normal References: <200907312328364066426@ctbri.com.cn> Cc: decade Subject: Re: [decade] DECADE meeting minutes X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Aug 2009 05:07:35 -0000 DMCA surely can be a reference for law issues of DECADE=2C it presents so= me aspects the content providers may concentrate on=2E Thanks to Kaiyu=2E= IMHO=2CDMCA has been the target of much debate since its rollout and it m= aybe a little bit faraway as =22somewhere to draw the line=22 as Spiros s= aid=2E DECADE=2C as introduced in the slide=2C might help resource-client authen= ticate request-client by checking the password before forwarding the cont= ent=2C which already offends DMCA=2E Some DMCA requirements are applicable to DECADE=2C e=2Eg=2E 1=2E ISP is not the one who originally made the material available 2=2E Caching is automatic=2C intermediate and temporary storage of conten= t in local servers 4=2E caching complies with industry standards regarding the updating of t= he content 6=2E Provider must remove infringing files upon gaining actual knowledge = of infringement I=27m still hesitating whether or not =236 should be considered by DECADE= =2E Best Regards Yingjie Gu ----- Original mail ----- From=3A =3Czhouky=40ctbri=2Ecom=2Ecn=3E Date=3A Fri=2E=2C 31 July=2C 2009 11=3A30 PM Subject=3A Re=3A Re=3A =5Bdecade=5D DECADE meeting minutes To=3A =22Y=2EJ=2E Gu=22 =3Cguyingjie=40huawei=2Ecom=3E=2C =22=27Woundy=2C= Richard=27=22 =3CRichard=5FWoundy=40cable=2Ecomcast=2Ecom=3E=2C =27Song = Haibin=27 =3Cmelodysong=40huawei=2Ecom=3E=2C decade =3Cdecade=40ietf=2Eor= g=3E =3E It is good to see that DECADE has a good beginning=2E = =3E For the legal issue=2C I was told that a ISP=27s cache system should = =3E follows DMCA=2E Which requires=3A =3E 1=2E ISP is not the one who originally made the material available =3E 2=2E Caching is automatic=2C intermediate and temporary storage of = =3E content in local servers =3E 3=2E ISP did not modify the content =3E 4=2E caching complies with industry standards regarding the updating = =3E of the content =3E 5=2E ISP does not interfere with content=A1=A6s access manners (such = as = =3E passwords=2C etc=2E) =3E 6=2E Provider must remove infringing files upon gaining actual = =3E knowledge of infringement =3E These may still be applicable to DECADE=2E =3E = =3E = =3E 2009-07-31 = =3E = =3E = =3E = =3E Zhou Kaiyu = =3E = =3E = =3E = =3E =B5o=A5=F3=A4H=A1G Y=2EJ=2E Gu = =3E =B5o=B0e=AE=C9=B6=A1=A1G 2009-07-31 15=3A34=3A47 = =3E =A6=AC=A5=F3=A4H=A1G =27Woundy=2C Richard=27=3B =27Song Haibin=27=3B = decade = =3E =A7=DB=B0e=A1G = =3E =A5D=C3D=A1G Re=3A =5Bdecade=5D DECADE meeting minutes = =3E = =3E Hi=2C this is Yingjie=2E =3E Thanks to chairs and attendees=2E =3E Glad to see that many people are interested in this topic=2C that=27s= = =3E a good =3E beginning to DECADE=2E = =3E However we still have much work to do before IETF 76=2C following = =3E are my =3E conclusion of what to do according to the meeting minutes=2E = =3E 1) Motivation clarification=3B First=2C saving uplink/downlink = =3E bandwidth is a =3E possible motivation=2C although it may be not true for all ISPs=2C it= = =3E reallyhelps a lot=2E Second=2C for each application it supports=2C th= e = =3E existing cache =3E has to understand the corresponding protocol=2C which makes it = =3E painful to =3E adapt new applications=2C especially in flourishing P2P=2E =3E 2) Advantages over existing mechanisms=3B maybe not overwhelming = =3E advantage=2Cbut it should be clarified about what DECADE can do (or = =3E do better) while the =3E others cannot=2C i=2Ee=2E why we need a new one instead of reusing th= e = =3E existingones with some modification=2E = =3E 3) Specific application use case=3B I agree with Yu Shun that we = =3E should first =3E list the applications that might benefits from DECADE=2C meanwhile = =3E specify how =3E and how much these apps will benefit=2E =3E 4) Legal issues=3B Sure it is not so much important in some = =3E countries as in =3E others=2C but we should give some consideration or further = =3E explanation before =3E simply leaving it out of account=2E =3E Hope for more comments and proposals=2E =3E Regards =3E Yingjie Gu =3E -----=B6l=A5=F3=AD=EC=A5=F3----- =3E =B5o=A5=F3=A4H=3A decade-bounces=40ietf=2Eorg =5Bmailto=3Adecade-boun= ces=40ietf=2Eorg=5D =A5N=AA=ED =3E Woundy=2C Richard =3E =B5o=B0e=AE=C9=B6=A1=3A 2009=A6=7E7=A4=EB31=A4=E9 =BC=D6=BC=D60=3A46 =3E =A6=AC=A5=F3=A4H=3A Song Haibin=3B decade=40ietf=2Eorg =3E =A5D=C3D=3A Re=3A =5Bdecade=5D DECADE meeting minutes =3E In the minutes=2C I think I am both =22Rich Woundy=22 and =22Rich fro= m ISP=22=2E =3E =3E Rich Woundy- current caching system based on transparent passing = by =3E which they ssume that if it is p2p protocol they put cache inline = =3E of the =3E transmission line=2E =3E They put the cache inline=2C or they intercept the traffic inline ala= =3E DPI=2E=2E=2E=2E=2E=2E=2E=2E=2E=2E=2E=2E =3E =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F =3E decade mailing list =3E decade=40ietf=2Eorg =3E https=3A//www=2Eietf=2Eorg/mailman/listinfo/decade =3E