From guyingjie@huawei.com Thu Apr 8 18:33:10 2010 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 16B5E3A68EF for ; Thu, 8 Apr 2010 18:33:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.173 X-Spam-Level: ** X-Spam-Status: No, score=2.173 tagged_above=-999 required=5 tests=[AWL=1.179, 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 VHvCFR19Mb2T for ; Thu, 8 Apr 2010 18:33:09 -0700 (PDT) Received: from szxga02-in.huawei.com (unknown [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id 305CF3A68ED for ; Thu, 8 Apr 2010 18:33: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 <0L0L00HT05MV5L@szxga02-in.huawei.com> for decade@ietf.org; Fri, 09 Apr 2010 09:32:55 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L0L003CM5MV2N@szxga02-in.huawei.com> for decade@ietf.org; Fri, 09 Apr 2010 09:32:55 +0800 (CST) Received: from g00107907 ([10.138.84.88]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L0L00LS95MUQQ@szxml04-in.huawei.com> for decade@ietf.org; Fri, 09 Apr 2010 09:32:55 +0800 (CST) Date: Fri, 09 Apr 2010 09:32:54 +0800 From: "Y.J. Gu" In-reply-to: To: decade@ietf.org Message-id: <009a01cad784$9377fe50$58548a0a@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: AcrNxuc5Ln/TB0wpSNuMUkUof0ZCrQJvYuZA Subject: [decade] Do we have meeting minutes? /N 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, 09 Apr 2010 01:33:10 -0000 Regards Yingjie Gu From richard_woundy@cable.comcast.com Thu Apr 8 18:57:21 2010 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 6233A3A6842 for ; Thu, 8 Apr 2010 18:57:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.163 X-Spam-Level: X-Spam-Status: No, score=-3.163 tagged_above=-999 required=5 tests=[AWL=-2.700, 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 sdop+lW3tmYP for ; Thu, 8 Apr 2010 18:57:20 -0700 (PDT) Received: from paoakoavas09.cable.comcast.com (paoakoavas09.cable.comcast.com [208.17.35.58]) by core3.amsl.com (Postfix) with ESMTP id 84C6A3A659C for ; Thu, 8 Apr 2010 18:57:20 -0700 (PDT) Received: from ([10.52.116.30]) by paoakoavas09.cable.comcast.com with ESMTP id KP-NTF18.89536886; Thu, 08 Apr 2010 21:57:00 -0400 Received: from pacdcexcmb05.cable.comcast.com ([24.40.15.116]) by PAOAKEXCSMTP01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 8 Apr 2010 21:57:00 -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: Thu, 8 Apr 2010 21:56:18 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [decade] Do we have meeting minutes? /N Thread-Index: AcrNxuc5Ln/TB0wpSNuMUkUof0ZCrQJvYuZAAADZiNE= From: "Woundy, Richard" To: , X-OriginalArrivalTime: 09 Apr 2010 01:57:00.0227 (UTC) FILETIME=[F14B2130:01CAD787] Subject: Re: [decade] Do we have meeting minutes? /N 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, 09 Apr 2010 01:57:21 -0000 SSBhbSBlZGl0aW5nIHRoZW0uIEkgaG9wZSB0byBwb3N0IHRoZW0gZm9yIHJldmlldyBieSB0aGlz IHdlZWtlbmQuDQoNCi0tIFJpY2gNCg0KDQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tDQpG cm9tOiBkZWNhZGUtYm91bmNlc0BpZXRmLm9yZyA8ZGVjYWRlLWJvdW5jZXNAaWV0Zi5vcmc+DQpU bzogZGVjYWRlQGlldGYub3JnIDxkZWNhZGVAaWV0Zi5vcmc+DQpTZW50OiBUaHUgQXByIDA4IDIx OjMyOjU0IDIwMTANClN1YmplY3Q6IFtkZWNhZGVdIERvIHdlIGhhdmUgbWVldGluZyBtaW51dGVz PyAvTg0KDQoNCg0KUmVnYXJkcw0KDQpZaW5namllIEd1DQoNCiANCg0KX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCmRlY2FkZSBtYWlsaW5nIGxpc3QNCmRl Y2FkZUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kZWNh ZGUNCg== From root@core3.amsl.com Tue Apr 13 11:00:01 2010 Return-Path: X-Original-To: decade@ietf.org Delivered-To: decade@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id D10783A681F; Tue, 13 Apr 2010 11:00:01 -0700 (PDT) From: IESG Secretary To: ietf-announce@ietf.org Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20100413180001.D10783A681F@core3.amsl.com> Date: Tue, 13 Apr 2010 11:00:01 -0700 (PDT) Cc: decade@ietf.org Subject: [decade] WG Review: DECoupled Application Data Enroute (decade) X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: iesg@ietf.org 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, 13 Apr 2010 18:00:01 -0000 A new IETF working group has been proposed in the Applications Area. The IESG has not made any determination as yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by Tuesday, April 20, 2010. DECoupled Application Data Enroute (decade) -------------------------------------------------- Current Status: Proposed Working Group Last modified: 2010-03-26 Chair(s): TBD Applications Area Director(s): * Alexey Melnikov * Peter Saint-Andre Applications Area Advisor: * Alexey Melnikov Mailing Lists: General Discussion: decade@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/decade Archive: http://www.ietf.org/mail-archive/web/decade/current/maillist.html Description of Working Group: Peer-to-Peer (P2P) applications, including both P2P streaming and P2P file-sharing applications, make up a large fraction of traffic in the Internet today. One way to reduce access network and/or cross-domain bandwidth usage by P2P applications is to introduce storage capabilities in the networks. Allowing P2P applications to store and retrieve data from inside networks can reduce traffic on the last-mile uplink, as well as backbone and transit links. Existing P2P caches often implement the specific P2P application protocols to operate transparently or act as super peers to provide in-network storage. However, it is challenging for P2P cache vendors to support a variety of evolving protocols. Also, for P2P applications, closed P2P caching systems limit effective utilization of in-network storage. Some P2P protocols may be entirely unsupported by a particular caching system. Additionally, applications may be better-equipped to decide how in-network storage is used to meet their specific requirements (e.g., data placement, access control and resource control). Both of these challenges can be effectively addressed by using an open, standard protocol to access in-network storage. P2P applications can store and retrieve content in the in-network storage, as well as control resources (e.g., bandwidth, connections) consumed by peers in a P2P application. As a simple example, a peer can choose to store content in the in-network storage, and direct other peers to retrieve from that location, reducing last-mile link usage. Furthermore, since a P2P client may have multiple peers, it can control resources used by each peer to store and retrieve content. Though there are existing data access protocols (e.g., HTTP, NFS, WebDAV), they might be lacking capabilities for fine-grained access and resource control (e.g., bandwidth and connections) that are essential for today's advanced P2P applications. The Working Group (WG) will have three primary tasks. First, the WG will identify target applications to appropriately scope the problem and requirements. P2P applications are the primary target, but suitability to other applications with similar requirements may be considered depending on additional complexity required to support such applications. Second, the WG will identify the requirements to enable target applications to utilize in-network storage. Requirements will include the ability for an application to (1) store, retrieve, and manage data, (2) indicate access control policies for storing and retrieving data suitable to an environment with users across multiple administrative and security domains (e.g., in a P2P environment), and (3) indicate resource control policies for storing and retrieving data. Third, the WG will develop an architecture within which the DECADE protocol can be specified. This architecture will identify DECADE's relationship to existing IETF protocols and where (if any) new protocol is needed or extensions to existing protocols need to be made. The architecture will not specify a protocol or extension; if development of a new protocol is needed, the WG will seek to recharter for this purpose or might ask an existing WG to work on such extensions. The WG will focus on the following work items: - A "problem statement" document. This document provides a description of the problem and common terminology. - A requirements document. This document lists the requirements for the in-network storage service (e.g., supported operations) and the protocol to support it. The service will include storing, retrieving, and managing data as well as specifying both access control and resource control policies in the in-network storage pertaining to that data. - A survey document. This document will survey existing related mechanisms and protocols (e.g., HTTP, NFS, and WebDAV), and evaluate their applicability to DECADE. - An architecture document. This document will identify DECADE's relationship with existing IETF protocols. Existing protocols will be used wherever possible and appropriate to support DECADE's requirements. In particular, data storage, retrieval, and management may be provided by an existing IETF protocols. The WG will not limit itself to a single data transport protocol since different protocols may have varying implementation costs and performance tradeoffs. However, to keep interoperability manageable, a small number of specific, targeted, data transport protocols will be identified and used. - An document describing the integration of DECADE with existing P2P applications (e.g., integration with BitTorrent). If new protocol development (and hence, rechartering) is deemed necessary, it is not expected that all work items will be ready for IESG review by that point. However, WG consensus must show that documents directing eventual protocol development (Requirements and Architecture document) have stabilized. This permits adjustments to such documents as necessary to maintain consistency as protocol development is done. The following issues are considered out-of-scope for the WG: - Implementation of policies regarding copyright-protected or illegal content. For example, one possibility is that that an in-network storage system may have system-wide ingress and egress filters to implement policies related to copyrighted and illegal content. This is outside the scope of this working group. - Locating the "best" in-network storage location from which to retrieve content if there are more than one location can provide the same content. - Developing a new protocol for data transport between P2P applications and in-network storage. Goals and Milestones: Aug 2010 Working Group Last Call for Problem Statement Nov 2010 Submit Problem Statement to IESG as Informational Nov 2010 Working Group Last Call for Survey document Feb 2011 Submit Survey document to IESG as Informational Feb 2011 Working Group Last Call for Requirements document Feb 2011 Working Group Last Call for Architecture document Mar 2011 Identify need for rechartering May 2011 Submit Requirements document to IESG as Informational Jul 2011 Submit Architecture document to IESG as Informational From melodysong@huawei.com Wed Apr 14 01:18:26 2010 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 0F43F3A68EA for ; Wed, 14 Apr 2010 01:18:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.105 X-Spam-Level: ** X-Spam-Status: No, score=2.105 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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 1zE1DvLNGe3n for ; Wed, 14 Apr 2010 01:18:20 -0700 (PDT) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 4AFD83A67BD for ; Wed, 14 Apr 2010 01:18:18 -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 <0L0U0018TXQ1C3@szxga04-in.huawei.com> for decade@ietf.org; Wed, 14 Apr 2010 16:18:02 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L0U001IZXQ1I1@szxga04-in.huawei.com> for decade@ietf.org; Wed, 14 Apr 2010 16:18:01 +0800 (CST) Received: from s64081a ([10.138.84.48]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L0U00A3BXPYYF@szxml04-in.huawei.com> for decade@ietf.org; Wed, 14 Apr 2010 16:18:01 +0800 (CST) Date: Wed, 14 Apr 2010 16:17:58 +0800 From: Song Haibin In-reply-to: To: 'Richard Alimi' , 'Tobias Heer' Message-id: <008a01cadbaa$fe05d9c0$30548a0a@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=ISO-8859-1 Content-transfer-encoding: quoted-printable Thread-index: AcrNxuc51DuldsXLR06HKM0452ZfQAN4gCkA Cc: decade@ietf.org Subject: Re: [decade] Work on decade security 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, 14 Apr 2010 08:18:26 -0000 Hi, It will be very helpful if there is a analysis about the scenarios of possible security threats within decade. Using in-network storage for content distribution is still a little vulnerable in case that the application control messages are using a different way/path than that of = the content.=20 BR, Haibin =20 > -----Original Message----- > From: decade-bounces@ietf.org=20 > [mailto:decade-bounces@ietf.org] On Behalf Of Richard Alimi > Sent: Sunday, March 28, 2010 12:02 AM > To: Tobias Heer > Cc: decade@ietf.org > Subject: Re: [decade] Work on decade security >=20 > Hi Tobias, >=20 > It would be wonderful if you could contribute here. I would=20 > agree that the security considerations had not yet been fully=20 > fleshed out, and are at this point intermingled with normal=20 > requirements. Here are some specific pointers to the ones we=20 > have thus far: >=20 > Security Considerations in the problem statement: > =20 > http://tools.ietf.org/html/draft-song-decade-problem-statement > -01#section-6 >=20 > Authorization requirements: > http://tools.ietf.org/html/draft-gu-decade-reqs-03#section-7 >=20 > I believe the Resource Control is also related to Security=20 > Considerations in the sense that it can help avoid Denial of Service > attacks: > http://tools.ietf.org/html/draft-gu-decade-reqs-03#section-6 > For a related measurement study on Akamai's infrastructure, see: > http://www.cs.northwestern.edu/~asu224/doc/streaming-imc.pdf >=20 > There are some other items that immediately come to mind that=20 > are not explicitly mentioned in drafts, or deserve to be=20 > called out more than they currently are: > - Encryption of metadata and/or data > - The possibility that (authorized) remote peers may upload=20 > (either intentionally or unintentionally) incorrect data to a=20 > user's storage. > Though it may not be preventable, a user should at least be=20 > able to detect this and react accordingly, likely be removing=20 > the data. > - A more formal/clarified distinction between "layers" with=20 > regards to authentication. The P2P application may have its=20 > own application-dependent way of doing authentication for=20 > peers in the P2P overlay. Separate from this (but presumably,=20 > though not always, after establishing connections in the P2P=20 > overlay), a DECADE user can grant authorization one or more=20 > of these peers to access its in-network storage. At the=20 > DECADE layer, the authentication is basically the model used in OAuth. >=20 > As far as the architecture goes, we do have some initial=20 > thoughts, but developing the architecture is one of the main=20 > work items for the WG according to the charter (to be sent=20 > out for IETF review shortly...). > That said: >=20 > The WG has not yet made any concrete decisions about how some=20 > of these security considerations will be addressed, which=20 > could certainly affect the architecture we come up with. =20 > There is some initial possibilities for an architecture in=20 > the Solution Architecture slides: > http://www.ietf.org/proceedings/10mar/slides/decade-7.pdf > There are some other details about an ongoing research=20 > project detailed in this set of slides presented at the Hiroshima BoF: > http://www.ietf.org/proceedings/09nov/slides/decade-3.pdf > And of course, there is the disclaimer the WG should in no=20 > way be restricted to such designs, and it would be great to=20 > hear input from others here. >=20 > Rich >=20 > On Sat, Mar 27, 2010 at 11:53 AM, Richard Alimi=20 > wrote: > > Hi Tobias, > > > > It would be wonderful if you could contribute here. I would=20 > agree that=20 > > the security considerations had not yet been fully fleshed out, and=20 > > are at this point intermingled with normal requirements. =A0Here are = > > some specific pointers to the ones we have thus far: > > > > Security Considerations in the problem statement: > > =A0 > >=20 > http://tools.ietf.org/html/draft-song-decade-problem-statement-01#sect > > ion-6 > > > > Authorization requirements: > > =A0http://tools.ietf.org/html/draft-gu-decade-reqs-03#section-7 > > > > I believe the Resource Control is also related to Security=20 > > Considerations in the sense that it can help avoid Denial of Service > > attacks: > > =A0http://tools.ietf.org/html/draft-gu-decade-reqs-03#section-6 > > For a related measurement study on Akamai's infrastructure, see: > > =A0http://www.cs.northwestern.edu/~asu224/doc/streaming-imc.pdf > > > > There are some other items that immediately come to mind=20 > that are not=20 > > explicitly mentioned in drafts, or deserve to be called out=20 > more than=20 > > they currently are: > > - Encryption of metadata and/or data > > - The possibility that (authorized) remote peers may upload (either=20 > > intentionally or unintentionally) incorrect data to a=20 > user's storage. > > Though it may not be preventable, a user should at least be able to=20 > > detect this and react accordingly, likely be removing the data. > > - A more formal/clarified distinction between "layers" with=20 > regards to=20 > > authentication. =A0The P2P application may have its own=20 > > application-dependent way of doing authentication for peers=20 > in the P2P=20 > > overlay. Separate from this (but presumably, though not=20 > always, after=20 > > establishing connections in the P2P overlay), a DECADE user=20 > can grant=20 > > authorization one or more of these peers to access its in-network=20 > > storage. At the DECADE layer, the authentication is basically the=20 > > model used in OAuth. > > > > As far as the architecture goes, we do have some initial=20 > thoughts, but=20 > > developing the architecture is one of the main work items=20 > for the WG=20 > > according to the charter (to be sent out for IETF review=20 > shortly...). > > That said: > > > > The WG has not yet made any concrete decisions about how=20 > some of these=20 > > security considerations will be addressed, which could certainly=20 > > affect the architecture we come up with. =A0There is some initial=20 > > possibilities for an architecture in the Solution=20 > Architecture slides: > > =A0http://www.ietf.org/proceedings/10mar/slides/decade-7.pdf > > There are some other details about an ongoing research project=20 > > detailed in this set of slides presented at the Hiroshima BoF: > > =A0http://www.ietf.org/proceedings/09nov/slides/decade-3.pdf > > And of course, there is the disclaimer the WG should in no way be=20 > > restricted to such designs, and it would be great to hear=20 > input from=20 > > others here. > > > > Rich > > > > On Sat, Mar 27, 2010 at 8:49 AM, Tobias Heer=20 > wrote: > >> Hi everyone, > >> > >> first I would like to thank the presenters for the nice=20 > presentations yesterday. > >> > >> I would be interested in contributing to the security=20 > architecture / requirements of decade. However, when=20 > screening the mailing list and the existing drafts I found=20 > little information on this topic. Maybe I was just looking=20 > for it in the wrong places, though. I'd be grateful for some=20 > pointers or background information about the security=20 > requirements and the envisioned architecture or maybe some=20 > pointers to previous discussions about it. I'll do some more=20 > thorough reading of the documents on the plane to see if I=20 > missed something. > >> > >> Cheers, > >> > >> Tobias > >> > >> > >> > >> -- > >> > >> Dipl.-Inform. Tobias Heer, Ph.D. Student Distributed Systems Group=20 > >> RWTH Aachen University, Germany > >> tel: +49 241 80 207 76 > >> web: http://ds.cs.rwth-aachen.de/members/heer > >> > >> > >> > >> > >> > >> > >> > >> _______________________________________________ > >> decade mailing list > >> decade@ietf.org > >> https://www.ietf.org/mailman/listinfo/decade > >> > > > _______________________________________________ > decade mailing list > decade@ietf.org > https://www.ietf.org/mailman/listinfo/decade >=20 From melodysong@huawei.com Wed Apr 14 01:24:00 2010 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 B38A83A69CA for ; Wed, 14 Apr 2010 01:24:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.247 X-Spam-Level: X-Spam-Status: No, score=-0.247 tagged_above=-999 required=5 tests=[AWL=2.352, 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 KLwaHTbloHra for ; Wed, 14 Apr 2010 01:23:59 -0700 (PDT) Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id 235F93A6976 for ; Wed, 14 Apr 2010 01:23:35 -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 <0L0U001XRXZ3V6@szxga02-in.huawei.com> for decade@ietf.org; Wed, 14 Apr 2010 16:23:27 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L0U002QZXZ32L@szxga02-in.huawei.com> for decade@ietf.org; Wed, 14 Apr 2010 16:23:27 +0800 (CST) Received: from s64081a ([10.138.84.48]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L0U00A6LXZ0PP@szxml04-in.huawei.com> for decade@ietf.org; Wed, 14 Apr 2010 16:23:27 +0800 (CST) Date: Wed, 14 Apr 2010 16:23:24 +0800 From: Song Haibin In-reply-to: To: "'Woundy, Richard'" , guyingjie@huawei.com, decade@ietf.org Message-id: <008b01cadbab$c026a890$30548a0a@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: AcrNxuc5Ln/TB0wpSNuMUkUof0ZCrQJvYuZAAADZiNEBCM42YA== Subject: Re: [decade] Do we have meeting minutes? /N 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, 14 Apr 2010 08:24:00 -0000 Rich and I have prepared a draft version of the meeting minutes based on Enrico's notes. Rich will send it out tomorrow. Thank you, Haibin > -----Original Message----- > From: decade-bounces@ietf.org > [mailto:decade-bounces@ietf.org] On Behalf Of Woundy, Richard > Sent: Friday, April 09, 2010 9:56 AM > To: guyingjie@huawei.com; decade@ietf.org > Subject: Re: [decade] Do we have meeting minutes? /N > > I am editing them. I hope to post them for review by this weekend. > > -- Rich > > > ----- Original Message ----- > From: decade-bounces@ietf.org > To: decade@ietf.org > Sent: Thu Apr 08 21:32:54 2010 > Subject: [decade] Do we have meeting minutes? /N > > > > Regards > > Yingjie Gu > > > > _______________________________________________ > decade mailing list > decade@ietf.org > https://www.ietf.org/mailman/listinfo/decade > _______________________________________________ > decade mailing list > decade@ietf.org > https://www.ietf.org/mailman/listinfo/decade > From richard_woundy@cable.comcast.com Wed Apr 14 03:08:39 2010 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 563123A65A6 for ; Wed, 14 Apr 2010 03:08:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.663 X-Spam-Level: X-Spam-Status: No, score=-5.663 tagged_above=-999 required=5 tests=[AWL=2.800, 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 BlyU7210jfmX for ; Wed, 14 Apr 2010 03:08:38 -0700 (PDT) Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by core3.amsl.com (Postfix) with ESMTP id B3CEB3A696A for ; Wed, 14 Apr 2010 03:08:34 -0700 (PDT) Received: from ([10.52.116.30]) by pacdcimo01.cable.comcast.com with ESMTP id 5503620.76867142; Wed, 14 Apr 2010 06:08:22 -0400 Received: from pacdcexcmb05.cable.comcast.com ([24.40.15.116]) by PAOAKEXCSMTP01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 14 Apr 2010 06:08:21 -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: Wed, 14 Apr 2010 06:05:24 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [decade] Do we have meeting minutes? /N Thread-Index: AcrNxuc5Ln/TB0wpSNuMUkUof0ZCrQJvYuZAAADZiNEBCM42YAADu4Fj References: <008b01cadbab$c026a890$30548a0a@china.huawei.com> From: "Woundy, Richard" To: "Song Haibin" , , X-OriginalArrivalTime: 14 Apr 2010 10:08:21.0518 (UTC) FILETIME=[6993E2E0:01CADBBA] Subject: Re: [decade] Do we have meeting minutes? /N 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, 14 Apr 2010 10:08:39 -0000 The draft meeting minutes are posted at = http://www.ietf.org/proceedings/10mar/minutes/decade.html. =20 Please send corrections by Friday April 16. Thanks. =20 -- Rich ________________________________ From: Song Haibin [mailto:melodysong@huawei.com] Sent: Wed 4/14/2010 4:23 AM To: Woundy, Richard; guyingjie@huawei.com; decade@ietf.org Subject: RE: [decade] Do we have meeting minutes? /N Rich and I have prepared a draft version of the meeting minutes based on Enrico's notes. Rich will send it out tomorrow. Thank you, Haibin > -----Original Message----- > From: decade-bounces@ietf.org > [mailto:decade-bounces@ietf.org] On Behalf Of Woundy, Richard > Sent: Friday, April 09, 2010 9:56 AM > To: guyingjie@huawei.com; decade@ietf.org > Subject: Re: [decade] Do we have meeting minutes? /N > > I am editing them. I hope to post them for review by this weekend. > > -- Rich > > > ----- Original Message ----- > From: decade-bounces@ietf.org > To: decade@ietf.org > Sent: Thu Apr 08 21:32:54 2010 > Subject: [decade] Do we have meeting minutes? /N > > > > Regards > > Yingjie Gu > >=20 > > _______________________________________________ > decade mailing list > decade@ietf.org > https://www.ietf.org/mailman/listinfo/decade > _______________________________________________ > decade mailing list > decade@ietf.org > https://www.ietf.org/mailman/listinfo/decade > From paul@countyanalytics.com Wed Apr 14 03:19:42 2010 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 159B53A68BF; Wed, 14 Apr 2010 03:19:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=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 hYP8sSr222ch; Wed, 14 Apr 2010 03:19:36 -0700 (PDT) Received: from exchange-out-46.livemail.co.uk (exchange-out-46.livemail.co.uk [213.171.216.46]) by core3.amsl.com (Postfix) with ESMTP id F38AD3A689F; Wed, 14 Apr 2010 03:19:33 -0700 (PDT) Received: by exchange-out-46.livemail.co.uk (Postfix, from userid 500) id 441076814A4; Wed, 14 Apr 2010 11:19:26 +0100 (BST) Received: from exch-be28.exchange.local (exch-be28.exchange.local [10.65.1.76]) by exchange-out-46.livemail.co.uk (Postfix) with ESMTP id 066AD682763; Wed, 14 Apr 2010 11:19:26 +0100 (BST) 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: Wed, 14 Apr 2010 11:19:18 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: DECADE Charter thread-index: Acrbu/EyRn8NiqZOQ5yHCXMamaAdFQ== From: "Paul Jessop" To: Cc: decade@ietf.org, IESG Secretary Subject: [decade] DECADE Charter 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, 14 Apr 2010 10:19:42 -0000 DECADE Charter =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D I am the Chief Technology Adviser to the Recording Industry Association = of America and have been asked to convey some thoughts to IETF on the = DECADE charter. I am sorry we could not do this before the recent IETF = meeting. We are very willing to discuss these comments and their implications = with IETF participants, either individually or collectively. We are dismayed to find that the Charter explicitly makes all issues of = rights protection out of scope: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D - Implementation of policies regarding copyright-protected or illegal = content. For example, one possibility is that that an in-network storage system = may have system-wide ingress and egress filters to implement policies = related to copyrighted and illegal content. This is outside the scope of this = working group. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D We are very keen to see legal applications of P2P technologies flourish = but we are quite sure that all IETF participants are well aware of the = consequences of their widespread abuse. We suggest that IETF needs to = factor the societal consequences of its actions into its choice of = subject areas for standardization and the way in which this is done. = Though we note that there are some non-infringing uses of P2P = technology, the vast majority of content carried over P2P networks is = infringing. IETF participants will doubtless be familiar with the recent = study of files available over a particular tracker-less BitTorrent = system which showed that less than 1% of the files investigated could = plausibly be regarded as non-infringing. We suggest the DECADE work needs particular scrutiny in this respect = because caching systems can have the effect of frustrating legal steps = taken to removing infringing content from availability. Content which is = taken down at its source by proper legal steps can remain available = indefinitely in caches. We have no desire to tell IETF how to specify technology: its = participants have far greater skills that we do in this area. We do = however have one high level proposal and one specific suggestion. 1. Implementation of Policy =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D We believe that the above scope restriction is problematic as drafted, = because it implies that IETF specification are above the law. While we = wholeheartedly agree that IETF should not set policy, it is clear that = it needs to respond to policy. We are recognize that policy varies from = jurisdiction to jurisdiction but believe that the general frameworks of = copyright law set out in international treaties make it straightforward = to enable this response. We suggest that this paragraph is replaced by: - Specification of policies regarding copyright-protected or illegal = content. For example, a decision to impose content filtering is outside the = scope of this working group. 2. Content removal interface =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D We note the proposed focus on the protocol between the in-network = storage and P2P applications. We suggest that a further interface in = necessary: that between the in-network storage and content owners (and = their representatives). While the primary interface may allow a certain = amount of discovery, it does not allow the removal of infringing content = and this needs to be enabled, along with certain safeguards against = abuse. We look forward to discussing these important issues. Best regards, Paul Jessop Chief Technology Adviser, Recording Industry Association of America Paul Jessop=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 county = analytics --------------------------------------------- rights - technology - markets - music - media --------------------------------------------- paul@countyanalytics.com=A0=A0=A0=A0=A0 +44 7850 685378 =A0 From richard_woundy@cable.comcast.com Wed Apr 14 06:47:53 2010 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 08FC23A6A0E; Wed, 14 Apr 2010 06:47:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.923 X-Spam-Level: X-Spam-Status: No, score=-0.923 tagged_above=-999 required=5 tests=[AWL=-3.060, BAYES_50=0.001, 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 sY00m-i7uLYA; Wed, 14 Apr 2010 06:47:51 -0700 (PDT) Received: from paoakoavas10.cable.comcast.com (paoakoavas10.cable.comcast.com [208.17.35.59]) by core3.amsl.com (Postfix) with ESMTP id 6382A3A69F5; Wed, 14 Apr 2010 06:47:43 -0700 (PDT) Received: from ([24.40.15.118]) by paoakoavas10.cable.comcast.com with ESMTP id KP-TDCH7.79956848; Wed, 14 Apr 2010 09:46:21 -0400 Received: from pacdcexcmb05.cable.comcast.com ([24.40.15.116]) by PACDCEXCSMTP04.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 14 Apr 2010 09:46: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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 14 Apr 2010 09:45:52 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: DECADE Charter Thread-Index: Acrbu/EyRn8NiqZOQ5yHCXMamaAdFQAGjRKj References: From: "Woundy, Richard" To: "Paul Jessop" , X-OriginalArrivalTime: 14 Apr 2010 13:46:20.0696 (UTC) FILETIME=[DD601180:01CADBD8] Cc: decade@ietf.org, IESG Secretary Subject: Re: [decade] DECADE Charter 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, 14 Apr 2010 13:47:53 -0000 (Not speaking as a co-chair, and not speaking on behalf of my employer) =20 >1. Implementation of Policy =20 I am sympathetic with the suggestion to change 'Implementation of = policies regarding copyright-protected or illegal content' to = 'Specification of policies regarding copyright-protected or illegal = content'. That is because the work product of the IETF is = specifications, not implementations. =20 Also consider the following existing requirement in the current draft: = http://tools.ietf.org/html/draft-gu-decade-reqs-04#section-9.2 = . =20 >2. Content removal interface =20 I don't believe the IETF community has the right skill set to specify a = content removal interface between the in-network storage providers and = content owners (and their representatives), keeping in mind various = regulations regarding notifications, counter-notices, etc. =20 However, other groups do have that expertise, and there is an existing = specification of note: >. This specification appears to = support notification of content available via "HTTP" and "FTP", and = should cover the protocols (FTP, WebDAV and/or HTTP) under consideration = by DECADE. Also note that DECADE is very similar to a "Cyberlocker", = which appears to be in scope for ACNS 2.0. =20 -- Rich ________________________________ From: Paul Jessop [mailto:paul@countyanalytics.com] Sent: Wed 4/14/2010 6:19 AM To: iesg@ietf.org Cc: decade@ietf.org; IESG Secretary; Song Haibin; Woundy, Richard Subject: DECADE Charter DECADE Charter =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D I am the Chief Technology Adviser to the Recording Industry Association = of America and have been asked to convey some thoughts to IETF on the = DECADE charter. I am sorry we could not do this before the recent IETF = meeting. We are very willing to discuss these comments and their implications = with IETF participants, either individually or collectively. We are dismayed to find that the Charter explicitly makes all issues of = rights protection out of scope: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D - Implementation of policies regarding copyright-protected or illegal = content. For example, one possibility is that that an in-network storage system = may have system-wide ingress and egress filters to implement policies = related to copyrighted and illegal content. This is outside the scope of this = working group. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D We are very keen to see legal applications of P2P technologies flourish = but we are quite sure that all IETF participants are well aware of the = consequences of their widespread abuse. We suggest that IETF needs to = factor the societal consequences of its actions into its choice of = subject areas for standardization and the way in which this is done. = Though we note that there are some non-infringing uses of P2P = technology, the vast majority of content carried over P2P networks is = infringing. IETF participants will doubtless be familiar with the recent = study of files available over a particular tracker-less BitTorrent = system which showed that less than 1% of the files investigated could = plausibly be regarded as non-infringing. We suggest the DECADE work needs particular scrutiny in this respect = because caching systems can have the effect of frustrating legal steps = taken to removing infringing content from availability. Content which is = taken down at its source by proper legal steps can remain available = indefinitely in caches. We have no desire to tell IETF how to specify technology: its = participants have far greater skills that we do in this area. We do = however have one high level proposal and one specific suggestion. 1. Implementation of Policy =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D We believe that the above scope restriction is problematic as drafted, = because it implies that IETF specification are above the law. While we = wholeheartedly agree that IETF should not set policy, it is clear that = it needs to respond to policy. We are recognize that policy varies from = jurisdiction to jurisdiction but believe that the general frameworks of = copyright law set out in international treaties make it straightforward = to enable this response. We suggest that this paragraph is replaced by: - Specification of policies regarding copyright-protected or illegal = content. For example, a decision to impose content filtering is outside the = scope of this working group. 2. Content removal interface =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D We note the proposed focus on the protocol between the in-network = storage and P2P applications. We suggest that a further interface in = necessary: that between the in-network storage and content owners (and = their representatives). While the primary interface may allow a certain = amount of discovery, it does not allow the removal of infringing content = and this needs to be enabled, along with certain safeguards against = abuse. We look forward to discussing these important issues. Best regards, Paul Jessop Chief Technology Adviser, Recording Industry Association of America Paul Jessop county analytics --------------------------------------------- rights - technology - markets - music - media --------------------------------------------- paul@countyanalytics.com +44 7850 685378 =20 From richard.alimi@gmail.com Wed Apr 14 06:55:01 2010 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 3E59F3A6AEA; Wed, 14 Apr 2010 06:55:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.623 X-Spam-Level: X-Spam-Status: No, score=0.623 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FM_FORGED_GMAIL=0.622] 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 uJTZMx3BRFDC; Wed, 14 Apr 2010 06:55:00 -0700 (PDT) Received: from mail-iw0-f189.google.com (mail-iw0-f189.google.com [209.85.223.189]) by core3.amsl.com (Postfix) with ESMTP id 923C13A689A; Wed, 14 Apr 2010 06:54:58 -0700 (PDT) Received: by iwn27 with SMTP id 27so69232iwn.5 for ; Wed, 14 Apr 2010 06:54:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:received:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=+WUf+v+GpPYKjjiGU/QJbykpwIe4fI1EIDbx8xsajp4=; b=xSUVyr2+zYralTx72H4OWx4Im/DT0Q9zYxHjR0B0UjZ+v9gKezFxmbum4nOXcWgzYd vW0NLmogPdTi/eVfYZRpYK37LHtJHqfTPd+QgOpn/2sH7fcZrh7z/pNtvT9E60UEwp9G N9wydvfWzuCCwoTPaHIcNj58xQBn65FQ5G++o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=wpW/2gUfHdVCgWWobYEnyrtrT3bM0RPP27PJotfwYfWVWjloqMO6Bk7HJx9cs362lN 13T3lc5v1D7r7swCSsqdX9qlGP8pfgneg/+xc/3bRDrGsI/dye/fz3YrKQwwy2TKS19B AejySwNthqZDnMO3UISi0Ti6KeC3VW73uLmjc= MIME-Version: 1.0 Sender: richard.alimi@gmail.com Received: by 10.231.169.12 with HTTP; Wed, 14 Apr 2010 06:54:49 -0700 (PDT) In-Reply-To: References: Date: Wed, 14 Apr 2010 09:54:49 -0400 X-Google-Sender-Auth: 653761d5dc1075e3 Received: by 10.231.145.204 with SMTP id e12mr3357125ibv.36.1271253289933; Wed, 14 Apr 2010 06:54:49 -0700 (PDT) Message-ID: From: Richard Alimi To: Paul Jessop Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: decade@ietf.org, IESG Secretary , iesg@ietf.org Subject: Re: [decade] DECADE Charter 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, 14 Apr 2010 13:55:01 -0000 Hi Paul, Thank you very much for your comments on the charter. Please allow me to clarify one point to add to Rich Woundy's comments. We certainly realize that a storage provider must have the ability to handle cases when certain content is identified as illegal or copyright-protected. In particular, please see the current draft of the requirements document: http://tools.ietf.org/html/draft-gu-decade-reqs-04#section-9.2 This requirement allows a storage provider to handle the situation where certain content is deemed (by some means outside of our scope) to not meet certain filtering criteria (the specification of which is outside of our scope). From the protocol perspective, we simply want to make sure that an application has the information it needs to handle this case appropriately (e.g., deal with the fact that some data may not currently be available). Thanks, -- Richard Alimi Department of Computer Science Yale University On Wed, Apr 14, 2010 at 6:19 AM, Paul Jessop wro= te: > DECADE Charter > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > I am the Chief Technology Adviser to the Recording Industry Association o= f America and have been asked to convey some thoughts to IETF on the DECADE= charter. I am sorry we could not do this before the recent IETF meeting. > > We are very willing to discuss these comments and their implications with= IETF participants, either individually or collectively. > > We are dismayed to find that the Charter explicitly makes all issues of r= ights protection out of scope: > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > - Implementation of policies regarding copyright-protected or illegal con= tent. > =A0For example, one possibility is that that an in-network storage system= may > =A0have system-wide ingress and egress filters to implement policies rela= ted to > =A0copyrighted and illegal content. =A0This is outside the scope of this = working > =A0group. > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > > We are very keen to see legal applications of P2P technologies flourish b= ut we are quite sure that all IETF participants are well aware of the conse= quences of their widespread abuse. We suggest that IETF needs to factor the= societal consequences of its actions into its choice of subject areas for = standardization and the way in which this is done. Though we note that ther= e are some non-infringing uses of P2P technology, the vast majority of cont= ent carried over P2P networks is infringing. IETF participants will doubtle= ss be familiar with the recent study of files available over a particular t= racker-less BitTorrent system which showed that less than 1% of the files i= nvestigated could plausibly be regarded as non-infringing. > > We suggest the DECADE work needs particular scrutiny in this respect beca= use caching systems can have the effect of frustrating legal steps taken to= removing infringing content from availability. Content which is taken down= at its source by proper legal steps can remain available indefinitely in c= aches. > > We have no desire to tell IETF how to specify technology: its participant= s have far greater skills that we do in this area. We do however have one h= igh level proposal and one specific suggestion. > > 1. Implementation of Policy > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > > We believe that the above scope restriction is problematic as drafted, be= cause it implies that IETF specification are above the law. While we wholeh= eartedly agree that IETF should not set policy, it is clear that it needs t= o respond to policy. We are recognize that policy varies from jurisdiction = to jurisdiction but believe that the general frameworks of copyright law se= t out in international treaties make it straightforward to enable this resp= onse. > > We suggest that this paragraph is replaced by: > > - Specification of policies regarding copyright-protected or illegal cont= ent. > =A0For example, a decision to impose content filtering is outside the sco= pe of > =A0this working group. > > 2. Content removal interface > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > > We note the proposed focus on the protocol between the in-network storage= and P2P applications. We suggest that a further interface in necessary: th= at between the in-network storage and content owners (and their representat= ives). While the primary interface may allow a certain amount of discovery,= it does not allow the removal of infringing content and this needs to be e= nabled, along with certain safeguards against abuse. > > > We look forward to discussing these important issues. > > Best regards, > > Paul Jessop > Chief Technology Adviser, > Recording Industry Association of America > > > > > Paul Jessop=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 county ana= lytics > --------------------------------------------- > rights - technology - markets - music - media > --------------------------------------------- > paul@countyanalytics.com=A0=A0=A0=A0=A0 +44 7850 685378 > > > > _______________________________________________ > decade mailing list > decade@ietf.org > https://www.ietf.org/mailman/listinfo/decade > From paul@countyanalytics.com Wed Apr 14 07:13:43 2010 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 DDD643A6A36; Wed, 14 Apr 2010 07:13:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=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 07JHof4EKgif; Wed, 14 Apr 2010 07:13:42 -0700 (PDT) Received: from exchange-out-45.livemail.co.uk (exchange-out-45.livemail.co.uk [213.171.216.45]) by core3.amsl.com (Postfix) with ESMTP id D10603A69C1; Wed, 14 Apr 2010 07:13:22 -0700 (PDT) Received: by exchange-out-45.livemail.co.uk (Postfix, from userid 100) id 73BB8CE88F4; Wed, 14 Apr 2010 15:13:28 +0100 (BST) Received: from exch-be28.exchange.local (exch-be28.exchange.local [10.65.1.76]) by exchange-out-45.livemail.co.uk (Postfix) with ESMTP id 5D26ECE8844; Wed, 14 Apr 2010 15:13:25 +0100 (BST) 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: Wed, 14 Apr 2010 15:13:06 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: DECADE Charter thread-index: Acrbu/EyRn8NiqZOQ5yHCXMamaAdFQAGjRKjAADKvfA= References: From: "Paul Jessop" To: "Woundy, Richard" , Cc: decade@ietf.org, IESG Secretary Subject: Re: [decade] DECADE Charter 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, 14 Apr 2010 14:13:44 -0000 Rich, Thanks on the first point. On the second, I had seen the requirement you mention but this deals = with the consequences of blocking, not the process that delivers it. I wonder if your reference to the "various regulations regarding = notifications, counter-notices, etc" risks confusing policy and = engineering. Assuming that the operator of a DECADE service trusts a = particular rights owner or their agent, then they might receive a = certification allowing them to block problematic content in a cache. I'm = not saying what policy, political or commercial considerations lead to = that point but it happens in certain contexts today and standardizing it = should reduce everyone's costs in implementing it. A similar interface could be used by (say) child protection agencies - = who would presumably have some form of MOU saying they would only block = child-porn related material. If the operator trusted them to do so, then = the interface would be useful to both parties. I'd note (at the risk of bumping up against the policy boundary) that = blocking something in a cache has none of the sensitivities of taking it = down at the source, because the source (provided it has not itself been = subject to takedown) is still available. If it goes beyond that we're = talking about an archive rather than a cache. I'm somewhat familiar with the ACNS specification but had considered it = to be working at a rather higher level than I was proposing here. If it = provides a basis to work from, it might save a lot of effort and time. Paul Paul Jessop=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 county = analytics --------------------------------------------- rights - technology - markets - music - media --------------------------------------------- paul@countyanalytics.com=A0=A0=A0=A0=A0 +44 7850 685378 =A0 -----Original Message----- From: Woundy, Richard [mailto:Richard_Woundy@cable.comcast.com]=20 Sent: 14 April 2010 14:46 To: Paul Jessop; iesg@ietf.org Cc: decade@ietf.org; IESG Secretary; Song Haibin; Woundy, Richard Subject: RE: DECADE Charter (Not speaking as a co-chair, and not speaking on behalf of my employer) =20 >1. Implementation of Policy =20 I am sympathetic with the suggestion to change 'Implementation of = policies regarding copyright-protected or illegal content' to = 'Specification of policies regarding copyright-protected or illegal = content'. That is because the work product of the IETF is = specifications, not implementations. =20 Also consider the following existing requirement in the current draft: = http://tools.ietf.org/html/draft-gu-decade-reqs-04#section-9.2 = . =20 >2. Content removal interface =20 I don't believe the IETF community has the right skill set to specify a = content removal interface between the in-network storage providers and = content owners (and their representatives), keeping in mind various = regulations regarding notifications, counter-notices, etc. =20 However, other groups do have that expertise, and there is an existing = specification of note: >. This specification appears to = support notification of content available via "HTTP" and "FTP", and = should cover the protocols (FTP, WebDAV and/or HTTP) under consideration = by DECADE. Also note that DECADE is very similar to a "Cyberlocker", = which appears to be in scope for ACNS 2.0. =20 -- Rich ________________________________ From: Paul Jessop [mailto:paul@countyanalytics.com] Sent: Wed 4/14/2010 6:19 AM To: iesg@ietf.org Cc: decade@ietf.org; IESG Secretary; Song Haibin; Woundy, Richard Subject: DECADE Charter DECADE Charter =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D I am the Chief Technology Adviser to the Recording Industry Association = of America and have been asked to convey some thoughts to IETF on the = DECADE charter. I am sorry we could not do this before the recent IETF = meeting. We are very willing to discuss these comments and their implications = with IETF participants, either individually or collectively. We are dismayed to find that the Charter explicitly makes all issues of = rights protection out of scope: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D - Implementation of policies regarding copyright-protected or illegal = content. For example, one possibility is that that an in-network storage system = may have system-wide ingress and egress filters to implement policies = related to copyrighted and illegal content. This is outside the scope of this = working group. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D We are very keen to see legal applications of P2P technologies flourish = but we are quite sure that all IETF participants are well aware of the = consequences of their widespread abuse. We suggest that IETF needs to = factor the societal consequences of its actions into its choice of = subject areas for standardization and the way in which this is done. = Though we note that there are some non-infringing uses of P2P = technology, the vast majority of content carried over P2P networks is = infringing. IETF participants will doubtless be familiar with the recent = study of files available over a particular tracker-less BitTorrent = system which showed that less than 1% of the files investigated could = plausibly be regarded as non-infringing. We suggest the DECADE work needs particular scrutiny in this respect = because caching systems can have the effect of frustrating legal steps = taken to removing infringing content from availability. Content which is = taken down at its source by proper legal steps can remain available = indefinitely in caches. We have no desire to tell IETF how to specify technology: its = participants have far greater skills that we do in this area. We do = however have one high level proposal and one specific suggestion. 1. Implementation of Policy =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D We believe that the above scope restriction is problematic as drafted, = because it implies that IETF specification are above the law. While we = wholeheartedly agree that IETF should not set policy, it is clear that = it needs to respond to policy. We are recognize that policy varies from = jurisdiction to jurisdiction but believe that the general frameworks of = copyright law set out in international treaties make it straightforward = to enable this response. We suggest that this paragraph is replaced by: - Specification of policies regarding copyright-protected or illegal = content. For example, a decision to impose content filtering is outside the = scope of this working group. 2. Content removal interface =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D We note the proposed focus on the protocol between the in-network = storage and P2P applications. We suggest that a further interface in = necessary: that between the in-network storage and content owners (and = their representatives). While the primary interface may allow a certain = amount of discovery, it does not allow the removal of infringing content = and this needs to be enabled, along with certain safeguards against = abuse. We look forward to discussing these important issues. Best regards, Paul Jessop Chief Technology Adviser, Recording Industry Association of America Paul Jessop county analytics --------------------------------------------- rights - technology - markets - music - media --------------------------------------------- paul@countyanalytics.com +44 7850 685378 =20 From richard_woundy@cable.comcast.com Wed Apr 14 08:03:47 2010 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 20FBF28C1FD; Wed, 14 Apr 2010 08:03:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.713 X-Spam-Level: X-Spam-Status: No, score=-5.713 tagged_above=-999 required=5 tests=[AWL=2.750, 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 Ta7TBpw0-G6l; Wed, 14 Apr 2010 08:03:45 -0700 (PDT) Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by core3.amsl.com (Postfix) with ESMTP id D7EF728C0FA; Wed, 14 Apr 2010 08:03:44 -0700 (PDT) Received: from ([10.52.116.30]) by pacdcimo01.cable.comcast.com with ESMTP id 5503620.76912062; Wed, 14 Apr 2010 11:03:31 -0400 Received: from pacdcexcmb05.cable.comcast.com ([24.40.15.116]) by PAOAKEXCSMTP01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 14 Apr 2010 11:03:30 -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: Wed, 14 Apr 2010 11:02:51 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: DECADE Charter Thread-Index: Acrbu/EyRn8NiqZOQ5yHCXMamaAdFQAGjRKjAADKvfAAAf6Ggw== References: From: "Woundy, Richard" To: "Paul Jessop" , X-OriginalArrivalTime: 14 Apr 2010 15:03:30.0740 (UTC) FILETIME=[A518B740:01CADBE3] Cc: decade@ietf.org, IESG Secretary Subject: Re: [decade] DECADE Charter 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, 14 Apr 2010 15:03:47 -0000 >I wonder if your reference to the "various regulations regarding = notifications, counter-notices, etc" risks confusing policy and = engineering. Assuming that the operator of a DECADE service trusts a = particular rights owner or their agent, then they might receive a = certification allowing them to block problematic content in a cache. I'm = not saying what policy, political or commercial considerations lead to = that point but it happens in certain contexts today and standardizing it = should reduce everyone's costs in implementing it. Two reactions. First, I think the ACNS specification already covers the = case of a "rights owner / agent" notifying a service provider about = copyright infringement, and it performs this task for multiple = technologies, e.g. P2P, cyberlockers, linking services, etc. =20 Second, there are numerous legal and policy considerations with respect = to how the service provider ought to react to such a notification. Maybe = content is immediately deleted (as in the case you suggest), or is = immediately quarantined with user notification, or is quarantined after = 24 hours if the user doesn't respond, etc. Maybe the ISP needs human = validation of the notification, or must wait for a legal supoena. That's = why I think the notification would be sent to a 'notification handling = service' rather than a 'DECADE service'. The 'notification handling = service' would send updates to the 'DECADE service' according to policy. =20 >I'd note (at the risk of bumping up against the policy boundary) that = blocking something in a cache has none of the sensitivities of taking it = down at the source, because the source (provided it has not itself been = subject to takedown) is still available. If it goes beyond that we're = talking about an archive rather than a cache. =20 In a P2P context, the content in DECADE storage could be the original = copy, or could be a duplicate copy. The DECADE service provider might = not know. =20 >I'm somewhat familiar with the ACNS specification but had considered it = to be working at a rather higher level than I was proposing here. If it = provides a basis to work from, it might save a lot of effort and time. I would suggest taking a look. Clearly *some* folks have implemented it, = e.g. = http://forums.afterdawn.com/t.cfm/f-18/nasty_email_fox_copyright-844134/ = (scroll to bottom of posting). =20 -- Rich ________________________________ From: Paul Jessop [mailto:paul@countyanalytics.com] Sent: Wed 4/14/2010 10:13 AM To: Woundy, Richard; iesg@ietf.org Cc: decade@ietf.org; IESG Secretary; Song Haibin Subject: RE: DECADE Charter Rich, Thanks on the first point. On the second, I had seen the requirement you mention but this deals = with the consequences of blocking, not the process that delivers it. I wonder if your reference to the "various regulations regarding = notifications, counter-notices, etc" risks confusing policy and = engineering. Assuming that the operator of a DECADE service trusts a = particular rights owner or their agent, then they might receive a = certification allowing them to block problematic content in a cache. I'm = not saying what policy, political or commercial considerations lead to = that point but it happens in certain contexts today and standardizing it = should reduce everyone's costs in implementing it. A similar interface could be used by (say) child protection agencies - = who would presumably have some form of MOU saying they would only block = child-porn related material. If the operator trusted them to do so, then = the interface would be useful to both parties. I'd note (at the risk of bumping up against the policy boundary) that = blocking something in a cache has none of the sensitivities of taking it = down at the source, because the source (provided it has not itself been = subject to takedown) is still available. If it goes beyond that we're = talking about an archive rather than a cache. I'm somewhat familiar with the ACNS specification but had considered it = to be working at a rather higher level than I was proposing here. If it = provides a basis to work from, it might save a lot of effort and time. Paul Paul Jessop county analytics --------------------------------------------- rights - technology - markets - music - media --------------------------------------------- paul@countyanalytics.com +44 7850 685378 =20 -----Original Message----- From: Woundy, Richard [mailto:Richard_Woundy@cable.comcast.com] Sent: 14 April 2010 14:46 To: Paul Jessop; iesg@ietf.org Cc: decade@ietf.org; IESG Secretary; Song Haibin; Woundy, Richard Subject: RE: DECADE Charter (Not speaking as a co-chair, and not speaking on behalf of my employer) >1. Implementation of Policy I am sympathetic with the suggestion to change 'Implementation of = policies regarding copyright-protected or illegal content' to = 'Specification of policies regarding copyright-protected or illegal = content'. That is because the work product of the IETF is = specifications, not implementations. Also consider the following existing requirement in the current draft: = http://tools.ietf.org/html/draft-gu-decade-reqs-04#section-9.2 = . >2. Content removal interface I don't believe the IETF community has the right skill set to specify a = content removal interface between the in-network storage providers and = content owners (and their representatives), keeping in mind various = regulations regarding notifications, counter-notices, etc. However, other groups do have that expertise, and there is an existing = specification of note: > = >. This specification appears to support notification of content = available via "HTTP" and "FTP", and should cover the protocols (FTP, = WebDAV and/or HTTP) under consideration by DECADE. Also note that DECADE = is very similar to a "Cyberlocker", which appears to be in scope for = ACNS 2.0. -- Rich ________________________________ From: Paul Jessop [mailto:paul@countyanalytics.com] Sent: Wed 4/14/2010 6:19 AM To: iesg@ietf.org Cc: decade@ietf.org; IESG Secretary; Song Haibin; Woundy, Richard Subject: DECADE Charter DECADE Charter =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D I am the Chief Technology Adviser to the Recording Industry Association = of America and have been asked to convey some thoughts to IETF on the = DECADE charter. I am sorry we could not do this before the recent IETF = meeting. We are very willing to discuss these comments and their implications = with IETF participants, either individually or collectively. We are dismayed to find that the Charter explicitly makes all issues of = rights protection out of scope: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D - Implementation of policies regarding copyright-protected or illegal = content. For example, one possibility is that that an in-network storage system = may have system-wide ingress and egress filters to implement policies = related to copyrighted and illegal content. This is outside the scope of this = working group. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D We are very keen to see legal applications of P2P technologies flourish = but we are quite sure that all IETF participants are well aware of the = consequences of their widespread abuse. We suggest that IETF needs to = factor the societal consequences of its actions into its choice of = subject areas for standardization and the way in which this is done. = Though we note that there are some non-infringing uses of P2P = technology, the vast majority of content carried over P2P networks is = infringing. IETF participants will doubtless be familiar with the recent = study of files available over a particular tracker-less BitTorrent = system which showed that less than 1% of the files investigated could = plausibly be regarded as non-infringing. We suggest the DECADE work needs particular scrutiny in this respect = because caching systems can have the effect of frustrating legal steps = taken to removing infringing content from availability. Content which is = taken down at its source by proper legal steps can remain available = indefinitely in caches. We have no desire to tell IETF how to specify technology: its = participants have far greater skills that we do in this area. We do = however have one high level proposal and one specific suggestion. 1. Implementation of Policy =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D We believe that the above scope restriction is problematic as drafted, = because it implies that IETF specification are above the law. While we = wholeheartedly agree that IETF should not set policy, it is clear that = it needs to respond to policy. We are recognize that policy varies from = jurisdiction to jurisdiction but believe that the general frameworks of = copyright law set out in international treaties make it straightforward = to enable this response. We suggest that this paragraph is replaced by: - Specification of policies regarding copyright-protected or illegal = content. For example, a decision to impose content filtering is outside the = scope of this working group. 2. Content removal interface =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D We note the proposed focus on the protocol between the in-network = storage and P2P applications. We suggest that a further interface in = necessary: that between the in-network storage and content owners (and = their representatives). While the primary interface may allow a certain = amount of discovery, it does not allow the removal of infringing content = and this needs to be enabled, along with certain safeguards against = abuse. We look forward to discussing these important issues. Best regards, Paul Jessop Chief Technology Adviser, Recording Industry Association of America Paul Jessop county analytics --------------------------------------------- rights - technology - markets - music - media --------------------------------------------- paul@countyanalytics.com +44 7850 685378 From richard_woundy@cable.comcast.com Wed Apr 14 08:16:02 2010 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 391CC3A6872; Wed, 14 Apr 2010 08:16:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.106 X-Spam-Level: X-Spam-Status: No, score=-2.106 tagged_above=-999 required=5 tests=[AWL=-1.643, 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 VG03dkBttYGm; Wed, 14 Apr 2010 08:16:00 -0700 (PDT) Received: from paoakoavas10.cable.comcast.com (paoakoavas10.cable.comcast.com [208.17.35.59]) by core3.amsl.com (Postfix) with ESMTP id DFCA728C212; Wed, 14 Apr 2010 08:15:05 -0700 (PDT) Received: from ([24.40.15.118]) by paoakoavas10.cable.comcast.com with ESMTP id KP-TDCH7.79968588; Wed, 14 Apr 2010 11:14:44 -0400 Received: from pacdcexcmb05.cable.comcast.com ([24.40.15.116]) by PACDCEXCSMTP04.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 14 Apr 2010 11:14:42 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 14 Apr 2010 11:14:38 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [decade] DECADE Charter Thread-Index: Acrbu/EyRn8NiqZOQ5yHCXMamaAdFQAGjRKjAADKvfAAAf6GgwAA658g References: From: "Woundy, Richard" To: "Paul Jessop" , X-OriginalArrivalTime: 14 Apr 2010 15:14:42.0813 (UTC) FILETIME=[35AEEAD0:01CADBE5] Cc: decade@ietf.org Subject: Re: [decade] DECADE Charter 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, 14 Apr 2010 15:16:02 -0000 FYI -- let's drop the IESG Secretary from this thread. Each email to them generates trouble tickets, which must be driving them crazy. :( -- Rich -----Original Message----- From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.org] On Behalf Of Woundy, Richard Sent: Wednesday, April 14, 2010 11:03 AM To: Paul Jessop; iesg@ietf.org Cc: decade@ietf.org; IESG Secretary Subject: Re: [decade] DECADE Charter >I wonder if your reference to the "various regulations regarding notifications, counter-notices, etc" risks confusing policy and engineering. Assuming that the operator of a DECADE service trusts a particular rights owner or their agent, then they might receive a certification allowing them to block problematic content in a cache. I'm not saying what policy, political or commercial considerations lead to that point but it happens in certain contexts today and standardizing it should reduce everyone's costs in implementing it. Two reactions. First, I think the ACNS specification already covers the case of a "rights owner / agent" notifying a service provider about copyright infringement, and it performs this task for multiple technologies, e.g. P2P, cyberlockers, linking services, etc. =20 Second, there are numerous legal and policy considerations with respect to how the service provider ought to react to such a notification. Maybe content is immediately deleted (as in the case you suggest), or is immediately quarantined with user notification, or is quarantined after 24 hours if the user doesn't respond, etc. Maybe the ISP needs human validation of the notification, or must wait for a legal supoena. That's why I think the notification would be sent to a 'notification handling service' rather than a 'DECADE service'. The 'notification handling service' would send updates to the 'DECADE service' according to policy. =20 >I'd note (at the risk of bumping up against the policy boundary) that blocking something in a cache has none of the sensitivities of taking it down at the source, because the source (provided it has not itself been subject to takedown) is still available. If it goes beyond that we're talking about an archive rather than a cache. =20 In a P2P context, the content in DECADE storage could be the original copy, or could be a duplicate copy. The DECADE service provider might not know. =20 >I'm somewhat familiar with the ACNS specification but had considered it to be working at a rather higher level than I was proposing here. If it provides a basis to work from, it might save a lot of effort and time. I would suggest taking a look. Clearly *some* folks have implemented it, e.g. http://forums.afterdawn.com/t.cfm/f-18/nasty_email_fox_copyright-844134/ (scroll to bottom of posting). =20 -- Rich ________________________________ From: Paul Jessop [mailto:paul@countyanalytics.com] Sent: Wed 4/14/2010 10:13 AM To: Woundy, Richard; iesg@ietf.org Cc: decade@ietf.org; IESG Secretary; Song Haibin Subject: RE: DECADE Charter Rich, Thanks on the first point. On the second, I had seen the requirement you mention but this deals with the consequences of blocking, not the process that delivers it. I wonder if your reference to the "various regulations regarding notifications, counter-notices, etc" risks confusing policy and engineering. Assuming that the operator of a DECADE service trusts a particular rights owner or their agent, then they might receive a certification allowing them to block problematic content in a cache. I'm not saying what policy, political or commercial considerations lead to that point but it happens in certain contexts today and standardizing it should reduce everyone's costs in implementing it. A similar interface could be used by (say) child protection agencies - who would presumably have some form of MOU saying they would only block child-porn related material. If the operator trusted them to do so, then the interface would be useful to both parties. I'd note (at the risk of bumping up against the policy boundary) that blocking something in a cache has none of the sensitivities of taking it down at the source, because the source (provided it has not itself been subject to takedown) is still available. If it goes beyond that we're talking about an archive rather than a cache. I'm somewhat familiar with the ACNS specification but had considered it to be working at a rather higher level than I was proposing here. If it provides a basis to work from, it might save a lot of effort and time. Paul Paul Jessop county analytics --------------------------------------------- rights - technology - markets - music - media --------------------------------------------- paul@countyanalytics.com +44 7850 685378 =20 -----Original Message----- From: Woundy, Richard [mailto:Richard_Woundy@cable.comcast.com] Sent: 14 April 2010 14:46 To: Paul Jessop; iesg@ietf.org Cc: decade@ietf.org; IESG Secretary; Song Haibin; Woundy, Richard Subject: RE: DECADE Charter (Not speaking as a co-chair, and not speaking on behalf of my employer) >1. Implementation of Policy I am sympathetic with the suggestion to change 'Implementation of policies regarding copyright-protected or illegal content' to 'Specification of policies regarding copyright-protected or illegal content'. That is because the work product of the IETF is specifications, not implementations. Also consider the following existing requirement in the current draft: http://tools.ietf.org/html/draft-gu-decade-reqs-04#section-9.2 . >2. Content removal interface I don't believe the IETF community has the right skill set to specify a content removal interface between the in-network storage providers and content owners (and their representatives), keeping in mind various regulations regarding notifications, counter-notices, etc. However, other groups do have that expertise, and there is an existing specification of note: > >. This specification appears to support notification of content available via "HTTP" and "FTP", and should cover the protocols (FTP, WebDAV and/or HTTP) under consideration by DECADE. Also note that DECADE is very similar to a "Cyberlocker", which appears to be in scope for ACNS 2.0. -- Rich ________________________________ From: Paul Jessop [mailto:paul@countyanalytics.com] Sent: Wed 4/14/2010 6:19 AM To: iesg@ietf.org Cc: decade@ietf.org; IESG Secretary; Song Haibin; Woundy, Richard Subject: DECADE Charter DECADE Charter =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D I am the Chief Technology Adviser to the Recording Industry Association of America and have been asked to convey some thoughts to IETF on the DECADE charter. I am sorry we could not do this before the recent IETF meeting. We are very willing to discuss these comments and their implications with IETF participants, either individually or collectively. We are dismayed to find that the Charter explicitly makes all issues of rights protection out of scope: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D - Implementation of policies regarding copyright-protected or illegal content. For example, one possibility is that that an in-network storage system may have system-wide ingress and egress filters to implement policies related to copyrighted and illegal content. This is outside the scope of this working group. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D We are very keen to see legal applications of P2P technologies flourish but we are quite sure that all IETF participants are well aware of the consequences of their widespread abuse. We suggest that IETF needs to factor the societal consequences of its actions into its choice of subject areas for standardization and the way in which this is done. Though we note that there are some non-infringing uses of P2P technology, the vast majority of content carried over P2P networks is infringing. IETF participants will doubtless be familiar with the recent study of files available over a particular tracker-less BitTorrent system which showed that less than 1% of the files investigated could plausibly be regarded as non-infringing. We suggest the DECADE work needs particular scrutiny in this respect because caching systems can have the effect of frustrating legal steps taken to removing infringing content from availability. Content which is taken down at its source by proper legal steps can remain available indefinitely in caches. We have no desire to tell IETF how to specify technology: its participants have far greater skills that we do in this area. We do however have one high level proposal and one specific suggestion. 1. Implementation of Policy =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D We believe that the above scope restriction is problematic as drafted, because it implies that IETF specification are above the law. While we wholeheartedly agree that IETF should not set policy, it is clear that it needs to respond to policy. We are recognize that policy varies from jurisdiction to jurisdiction but believe that the general frameworks of copyright law set out in international treaties make it straightforward to enable this response. We suggest that this paragraph is replaced by: - Specification of policies regarding copyright-protected or illegal content. For example, a decision to impose content filtering is outside the scope of this working group. 2. Content removal interface =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D We note the proposed focus on the protocol between the in-network storage and P2P applications. We suggest that a further interface in necessary: that between the in-network storage and content owners (and their representatives). While the primary interface may allow a certain amount of discovery, it does not allow the removal of infringing content and this needs to be enabled, along with certain safeguards against abuse. We look forward to discussing these important issues. Best regards, Paul Jessop Chief Technology Adviser, Recording Industry Association of America Paul Jessop county analytics --------------------------------------------- rights - technology - markets - music - media --------------------------------------------- paul@countyanalytics.com +44 7850 685378 _______________________________________________ decade mailing list decade@ietf.org https://www.ietf.org/mailman/listinfo/decade From melodysong@huawei.com Wed Apr 14 19:18:04 2010 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 846B53A6AD3; Wed, 14 Apr 2010 19:18:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.371 X-Spam-Level: X-Spam-Status: No, score=-0.371 tagged_above=-999 required=5 tests=[AWL=0.124, 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 Eh4FQXdI3wtD; Wed, 14 Apr 2010 19:18:02 -0700 (PDT) Received: from szxga02-in.huawei.com (unknown [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id A39633A6AB0; Wed, 14 Apr 2010 19:17:59 -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 <0L0W00CGEBPIJS@szxga02-in.huawei.com>; Thu, 15 Apr 2010 10:17:43 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L0W003LWBPIUG@szxga02-in.huawei.com>; Thu, 15 Apr 2010 10:17:42 +0800 (CST) Received: from s64081a ([10.138.84.48]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L0W00MC5BPF4P@szxml06-in.huawei.com>; Thu, 15 Apr 2010 10:17:42 +0800 (CST) Date: Thu, 15 Apr 2010 10:17:39 +0800 From: Song Haibin In-reply-to: To: "'Woundy, Richard'" , 'Paul Jessop' , iesg@ietf.org Message-id: <003601cadc41$d2a2a5a0$30548a0a@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: Acrbu/EyRn8NiqZOQ5yHCXMamaAdFQAGjRKjAADKvfAAAf6GgwAXtiDQ Cc: decade@ietf.org Subject: Re: [decade] DECADE Charter 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, 15 Apr 2010 02:18:04 -0000 I fully agree with what Rich said. > >> We suggest that this paragraph is replaced by: > >> > >> - Specification of policies regarding copyright-protected > or illegal content. > >> For example, a decision to impose content filtering is > outside the > >> scope of this working group. > >> I agree with changing "implementation" to "specification". And further, I would like to change the example a bit to "... For example, a decision to impose or how to process content filtering is outside the scope of this working group." That is because we do not have expertise in doing content filtering and it will broaden the scope a lot. BR, Haibin > -----Original Message----- > From: Woundy, Richard [mailto:Richard_Woundy@cable.comcast.com] > Sent: Wednesday, April 14, 2010 11:03 PM > To: Paul Jessop; iesg@ietf.org > Cc: decade@ietf.org; IESG Secretary; Song Haibin > Subject: RE: DECADE Charter > > >I wonder if your reference to the "various regulations > regarding notifications, counter-notices, etc" risks > confusing policy and engineering. Assuming that the operator > of a DECADE service trusts a particular rights owner or their > agent, then they might receive a certification allowing them > to block problematic content in a cache. I'm not saying what > policy, political or commercial considerations lead to that > point but it happens in certain contexts today and > standardizing it should reduce everyone's costs in implementing it. > > Two reactions. First, I think the ACNS specification already > covers the case of a "rights owner / agent" notifying a > service provider about copyright infringement, and it > performs this task for multiple technologies, e.g. P2P, > cyberlockers, linking services, etc. > > Second, there are numerous legal and policy considerations > with respect to how the service provider ought to react to > such a notification. Maybe content is immediately deleted (as > in the case you suggest), or is immediately quarantined with > user notification, or is quarantined after 24 hours if the > user doesn't respond, etc. Maybe the ISP needs human > validation of the notification, or must wait for a legal > supoena. That's why I think the notification would be sent to > a 'notification handling service' rather than a 'DECADE > service'. The 'notification handling service' would send > updates to the 'DECADE service' according to policy. > > >I'd note (at the risk of bumping up against the policy > boundary) that blocking something in a cache has none of the > sensitivities of taking it down at the source, because the > source (provided it has not itself been subject to takedown) > is still available. If it goes beyond that we're talking > about an archive rather than a cache. > > In a P2P context, the content in DECADE storage could be the > original copy, or could be a duplicate copy. The DECADE > service provider might not know. > > >I'm somewhat familiar with the ACNS specification but had > considered it to be working at a rather higher level than I > was proposing here. If it provides a basis to work from, it > might save a lot of effort and time. > > I would suggest taking a look. Clearly *some* folks have > implemented it, e.g. > http://forums.afterdawn.com/t.cfm/f-18/nasty_email_fox_copyrig > ht-844134/ > ght-844134/> (scroll to bottom of posting). > > -- Rich > > ________________________________ > > From: Paul Jessop [mailto:paul@countyanalytics.com] > Sent: Wed 4/14/2010 10:13 AM > To: Woundy, Richard; iesg@ietf.org > Cc: decade@ietf.org; IESG Secretary; Song Haibin > Subject: RE: DECADE Charter > > > > Rich, > > Thanks on the first point. > > On the second, I had seen the requirement you mention but > this deals with the consequences of blocking, not the process > that delivers it. > > I wonder if your reference to the "various regulations > regarding notifications, counter-notices, etc" risks > confusing policy and engineering. Assuming that the operator > of a DECADE service trusts a particular rights owner or their > agent, then they might receive a certification allowing them > to block problematic content in a cache. I'm not saying what > policy, political or commercial considerations lead to that > point but it happens in certain contexts today and > standardizing it should reduce everyone's costs in implementing it. > > A similar interface could be used by (say) child protection > agencies - who would presumably have some form of MOU saying > they would only block child-porn related material. If the > operator trusted them to do so, then the interface would be > useful to both parties. > > I'd note (at the risk of bumping up against the policy > boundary) that blocking something in a cache has none of the > sensitivities of taking it down at the source, because the > source (provided it has not itself been subject to takedown) > is still available. If it goes beyond that we're talking > about an archive rather than a cache. > > I'm somewhat familiar with the ACNS specification but had > considered it to be working at a rather higher level than I > was proposing here. If it provides a basis to work from, it > might save a lot of effort and time. > > Paul > > > > Paul Jessop county analytics > --------------------------------------------- > rights - technology - markets - music - media > --------------------------------------------- > paul@countyanalytics.com +44 7850 685378 > > > > -----Original Message----- > From: Woundy, Richard [mailto:Richard_Woundy@cable.comcast.com] > Sent: 14 April 2010 14:46 > To: Paul Jessop; iesg@ietf.org > Cc: decade@ietf.org; IESG Secretary; Song Haibin; Woundy, Richard > Subject: RE: DECADE Charter > > (Not speaking as a co-chair, and not speaking on behalf of my > employer) > > >1. Implementation of Policy > > I am sympathetic with the suggestion to change > 'Implementation of policies regarding copyright-protected or > illegal content' to 'Specification of policies regarding > copyright-protected or illegal content'. That is because the > work product of the IETF is specifications, not implementations. > > Also consider the following existing requirement in the > current draft: > http://tools.ietf.org/html/draft-gu-decade-reqs-04#section-9.2 > . > > >2. Content removal interface > > I don't believe the IETF community has the right skill set to > specify a content removal interface between the in-network > storage providers and content owners (and their > representatives), keeping in mind various regulations > regarding notifications, counter-notices, etc. > > However, other groups do have that expertise, and there is an > existing specification of note: > ACNS/> > >. This specification appears to support > notification of content available via "HTTP" and "FTP", and > should cover the protocols (FTP, WebDAV and/or HTTP) under > consideration by DECADE. Also note that DECADE is very > similar to a "Cyberlocker", which appears to be in scope for ACNS 2.0. > > -- Rich > > ________________________________ > > From: Paul Jessop [mailto:paul@countyanalytics.com] > Sent: Wed 4/14/2010 6:19 AM > To: iesg@ietf.org > Cc: decade@ietf.org; IESG Secretary; Song Haibin; Woundy, Richard > Subject: DECADE Charter > > > > DECADE Charter > ============== > > I am the Chief Technology Adviser to the Recording Industry > Association of America and have been asked to convey some > thoughts to IETF on the DECADE charter. I am sorry we could > not do this before the recent IETF meeting. > > We are very willing to discuss these comments and their > implications with IETF participants, either individually or > collectively. > > We are dismayed to find that the Charter explicitly makes all > issues of rights protection out of scope: > > ============================================================== > ================ > - Implementation of policies regarding copyright-protected or > illegal content. > For example, one possibility is that that an in-network > storage system may > have system-wide ingress and egress filters to implement > policies related to > copyrighted and illegal content. This is outside the scope > of this working > group. > ============================================================== > ================ > > We are very keen to see legal applications of P2P > technologies flourish but we are quite sure that all IETF > participants are well aware of the consequences of their > widespread abuse. We suggest that IETF needs to factor the > societal consequences of its actions into its choice of > subject areas for standardization and the way in which this > is done. Though we note that there are some non-infringing > uses of P2P technology, the vast majority of content carried > over P2P networks is infringing. IETF participants will > doubtless be familiar with the recent study of files > available over a particular tracker-less BitTorrent system > which showed that less than 1% of the files investigated > could plausibly be regarded as non-infringing. > > We suggest the DECADE work needs particular scrutiny in this > respect because caching systems can have the effect of > frustrating legal steps taken to removing infringing content > from availability. Content which is taken down at its source > by proper legal steps can remain available indefinitely in caches. > > We have no desire to tell IETF how to specify technology: its > participants have far greater skills that we do in this area. > We do however have one high level proposal and one specific > suggestion. > > 1. Implementation of Policy > =========================== > > We believe that the above scope restriction is problematic as > drafted, because it implies that IETF specification are above > the law. While we wholeheartedly agree that IETF should not > set policy, it is clear that it needs to respond to policy. > We are recognize that policy varies from jurisdiction to > jurisdiction but believe that the general frameworks of > copyright law set out in international treaties make it > straightforward to enable this response. > > We suggest that this paragraph is replaced by: > > - Specification of policies regarding copyright-protected or > illegal content. > For example, a decision to impose content filtering is > outside the scope of > this working group. > > 2. Content removal interface > ============================ > > We note the proposed focus on the protocol between the > in-network storage and P2P applications. We suggest that a > further interface in necessary: that between the in-network > storage and content owners (and their representatives). While > the primary interface may allow a certain amount of > discovery, it does not allow the removal of infringing > content and this needs to be enabled, along with certain > safeguards against abuse. > > > We look forward to discussing these important issues. > > Best regards, > > Paul Jessop > Chief Technology Adviser, > Recording Industry Association of America > > > > > Paul Jessop county analytics > --------------------------------------------- > rights - technology - markets - music - media > --------------------------------------------- > paul@countyanalytics.com +44 7850 685378 > > > > > > > > From ingemar.s.johansson@ericsson.com Wed Apr 14 22:49:37 2010 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 7F8B23A6AF7 for ; Wed, 14 Apr 2010 22:49:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.035 X-Spam-Level: X-Spam-Status: No, score=-3.035 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, RCVD_IN_DNSWL_MED=-4, SARE_CHILDPRN1=1.15] 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 ZRmAXosMoe5D for ; Wed, 14 Apr 2010 22:49:35 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id BC2E33A6B79 for ; Wed, 14 Apr 2010 22:48:07 -0700 (PDT) X-AuditID: c1b4fb3d-b7bf6ae000005bec-dd-4bc6a88eb3ca Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id F9.57.23532.E88A6CB4; Thu, 15 Apr 2010 07:47:59 +0200 (CEST) Received: from esessmw0191.eemea.ericsson.se (153.88.115.84) by esessmw0237.eemea.ericsson.se (153.88.115.90) with Microsoft SMTP Server (TLS) id 8.1.375.2; Thu, 15 Apr 2010 07:47:57 +0200 Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.2.100]) by esessmw0191.eemea.ericsson.se ([10.2.3.60]) with mapi; Thu, 15 Apr 2010 07:47:58 +0200 From: Ingemar Johansson S To: "decade@ietf.org" Date: Thu, 15 Apr 2010 07:47:55 +0200 Thread-Topic: [decade] DECADE Charter Thread-Index: AcrcBMvvAwHOumDARVevEHKZBJBODAAV0psA Message-ID: <548FC4B9D57A4043AAFFE888A39429031D020BE4A7@ESESSCMS0356.eemea.ericsson.se> References: In-Reply-To: Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: sv-SE, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [decade] DECADE Charter 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, 15 Apr 2010 05:49:37 -0000 Hi Suppose that some provider of illegal content decides to use DECADE servers= for their content. As a provider of this content I would encrypt the conte= nt and distribute the keys in a "members only" club.=20 The chance for outsiders to penetrate this depends on content and whether m= oney or (possibly perverse) ideology is the main driver for the providers.= =20 If money is the main driver then I would believe that it is fairly easy for= law enforcement to punch a hole in the balloon (just buy membership). I wo= uld believe that illegal distribution of movies and music fall into this ca= thegory. If (perverse) idelogy is the main driver then I believe things get more tri= cky, and I believe that e.g child pornography falls into this cathegory. On= the other hand , if/when these groups are penetrated I would say that logs= from DECADE servers are very helpful for the further criminal investigatio= ns. I believe that these are serious issues and deserves full attention Nevertheless I find it a bit hard at this stage to see in what way protocol= s devised in the IETF can be helpful, to me it seems more like agreements b= etween DECADE server hosts and law enforcement is the best cure. Also I wou= ld say that the problem is already here, DECADE does not make the problem w= orse IMHO. /Ingemar > -----Original Message----- > From: Woundy, Richard [mailto:Richard_Woundy@cable.comcast.com]=20 > Sent: den 14 april 2010 17:15 > To: Paul Jessop; iesg@ietf.org > Cc: decade@ietf.org > Subject: Re: [decade] DECADE Charter >=20 > FYI -- let's drop the IESG Secretary from this thread. Each=20 > email to them generates trouble tickets, which must be=20 > driving them crazy. :( >=20 > -- Rich >=20 > -----Original Message----- > From: decade-bounces@ietf.org=20 > [mailto:decade-bounces@ietf.org] On Behalf Of Woundy, Richard > Sent: Wednesday, April 14, 2010 11:03 AM > To: Paul Jessop; iesg@ietf.org > Cc: decade@ietf.org; IESG Secretary > Subject: Re: [decade] DECADE Charter >=20 > >I wonder if your reference to the "various regulations regarding > notifications, counter-notices, etc" risks confusing policy=20 > and engineering. Assuming that the operator of a DECADE=20 > service trusts a particular rights owner or their agent, then=20 > they might receive a certification allowing them to block=20 > problematic content in a cache. I'm not saying what policy,=20 > political or commercial considerations lead to that point but=20 > it happens in certain contexts today and standardizing it=20 > should reduce everyone's costs in implementing it. >=20 > Two reactions. First, I think the ACNS specification already=20 > covers the case of a "rights owner / agent" notifying a=20 > service provider about copyright infringement, and it=20 > performs this task for multiple technologies, e.g. P2P,=20 > cyberlockers, linking services, etc. > =20 > Second, there are numerous legal and policy considerations=20 > with respect to how the service provider ought to react to=20 > such a notification. Maybe content is immediately deleted (as=20 > in the case you suggest), or is immediately quarantined with=20 > user notification, or is quarantined after > 24 hours if the user doesn't respond, etc. Maybe the ISP=20 > needs human validation of the notification, or must wait for=20 > a legal supoena. That's why I think the notification would be=20 > sent to a 'notification handling service' rather than a=20 > 'DECADE service'. The 'notification handling service' would=20 > send updates to the 'DECADE service' according to policy. > =20 > >I'd note (at the risk of bumping up against the policy boundary) that > blocking something in a cache has none of the sensitivities=20 > of taking it down at the source, because the source (provided=20 > it has not itself been subject to takedown) is still=20 > available. If it goes beyond that we're talking about an=20 > archive rather than a cache. > =20 > In a P2P context, the content in DECADE storage could be the=20 > original copy, or could be a duplicate copy. The DECADE=20 > service provider might not know. > =20 > >I'm somewhat familiar with the ACNS specification but had=20 > considered it > to be working at a rather higher level than I was proposing=20 > here. If it provides a basis to work from, it might save a=20 > lot of effort and time. >=20 > I would suggest taking a look. Clearly *some* folks have=20 > implemented it, e.g. > http://forums.afterdawn.com/t.cfm/f-18/nasty_email_fox_copyrig > ht-844134/ > ght-844134 > /> (scroll to bottom of posting). > =20 > -- Rich >=20 > ________________________________ >=20 > From: Paul Jessop [mailto:paul@countyanalytics.com] > Sent: Wed 4/14/2010 10:13 AM > To: Woundy, Richard; iesg@ietf.org > Cc: decade@ietf.org; IESG Secretary; Song Haibin > Subject: RE: DECADE Charter >=20 >=20 >=20 > Rich, >=20 > Thanks on the first point. >=20 > On the second, I had seen the requirement you mention but=20 > this deals with the consequences of blocking, not the process=20 > that delivers it. >=20 > I wonder if your reference to the "various regulations=20 > regarding notifications, counter-notices, etc" risks=20 > confusing policy and engineering. Assuming that the operator=20 > of a DECADE service trusts a particular rights owner or their=20 > agent, then they might receive a certification allowing them=20 > to block problematic content in a cache. I'm not saying what=20 > policy, political or commercial considerations lead to that=20 > point but it happens in certain contexts today and=20 > standardizing it should reduce everyone's costs in implementing it. >=20 > A similar interface could be used by (say) child protection=20 > agencies - who would presumably have some form of MOU saying=20 > they would only block child-porn related material. If the=20 > operator trusted them to do so, then the interface would be=20 > useful to both parties. >=20 > I'd note (at the risk of bumping up against the policy=20 > boundary) that blocking something in a cache has none of the=20 > sensitivities of taking it down at the source, because the=20 > source (provided it has not itself been subject to takedown)=20 > is still available. If it goes beyond that we're talking=20 > about an archive rather than a cache. >=20 > I'm somewhat familiar with the ACNS specification but had=20 > considered it to be working at a rather higher level than I=20 > was proposing here. If it provides a basis to work from, it=20 > might save a lot of effort and time. >=20 > Paul >=20 >=20 >=20 > Paul Jessop county analytics > --------------------------------------------- > rights - technology - markets - music - media > --------------------------------------------- > paul@countyanalytics.com +44 7850 685378 > =20 >=20 >=20 > -----Original Message----- > From: Woundy, Richard [mailto:Richard_Woundy@cable.comcast.com] > Sent: 14 April 2010 14:46 > To: Paul Jessop; iesg@ietf.org > Cc: decade@ietf.org; IESG Secretary; Song Haibin; Woundy, Richard > Subject: RE: DECADE Charter >=20 > (Not speaking as a co-chair, and not speaking on behalf of my=20 > employer) >=20 > >1. Implementation of Policy >=20 > I am sympathetic with the suggestion to change=20 > 'Implementation of policies regarding copyright-protected or=20 > illegal content' to 'Specification of policies regarding=20 > copyright-protected or illegal content'. That is because the=20 > work product of the IETF is specifications, not implementations. >=20 > Also consider the following existing requirement in the current draft: > http://tools.ietf.org/html/draft-gu-decade-reqs-04#section-9.2 > . >=20 > >2. Content removal interface >=20 > I don't believe the IETF community has the right skill set to=20 > specify a content removal interface between the in-network=20 > storage providers and content owners (and their=20 > representatives), keeping in mind various regulations=20 > regarding notifications, counter-notices, etc. >=20 > However, other groups do have that expertise, and there is an=20 > existing specification of note:=20 > > > >. This specification appears to support notification of content > available via "HTTP" and "FTP", and should cover the=20 > protocols (FTP, WebDAV and/or HTTP) under consideration by=20 > DECADE. Also note that DECADE is very similar to a=20 > "Cyberlocker", which appears to be in scope for ACNS 2.0. >=20 > -- Rich >=20 > ________________________________ >=20 > From: Paul Jessop [mailto:paul@countyanalytics.com] > Sent: Wed 4/14/2010 6:19 AM > To: iesg@ietf.org > Cc: decade@ietf.org; IESG Secretary; Song Haibin; Woundy, Richard > Subject: DECADE Charter >=20 >=20 >=20 > DECADE Charter > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > I am the Chief Technology Adviser to the Recording Industry=20 > Association of America and have been asked to convey some=20 > thoughts to IETF on the DECADE charter. I am sorry we could=20 > not do this before the recent IETF meeting. >=20 > We are very willing to discuss these comments and their=20 > implications with IETF participants, either individually or=20 > collectively. >=20 > We are dismayed to find that the Charter explicitly makes all=20 > issues of rights protection out of scope: >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > =3D=3D=3D=3D=3D=3D > - Implementation of policies regarding copyright-protected or=20 > illegal content. > For example, one possibility is that that an in-network=20 > storage system may > have system-wide ingress and egress filters to implement=20 > policies related to > copyrighted and illegal content. This is outside the scope=20 > of this working > group. > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > =3D=3D=3D=3D=3D=3D >=20 > We are very keen to see legal applications of P2P=20 > technologies flourish but we are quite sure that all IETF=20 > participants are well aware of the consequences of their=20 > widespread abuse. We suggest that IETF needs to factor the=20 > societal consequences of its actions into its choice of=20 > subject areas for standardization and the way in which this is done. > Though we note that there are some non-infringing uses of P2P=20 > technology, the vast majority of content carried over P2P=20 > networks is infringing. IETF participants will doubtless be=20 > familiar with the recent study of files available over a=20 > particular tracker-less BitTorrent system which showed that=20 > less than 1% of the files investigated could plausibly be=20 > regarded as non-infringing. >=20 > We suggest the DECADE work needs particular scrutiny in this=20 > respect because caching systems can have the effect of=20 > frustrating legal steps taken to removing infringing content=20 > from availability. Content which is taken down at its source=20 > by proper legal steps can remain available indefinitely in caches. >=20 > We have no desire to tell IETF how to specify technology: its=20 > participants have far greater skills that we do in this area.=20 > We do however have one high level proposal and one specific=20 > suggestion. >=20 > 1. Implementation of Policy > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >=20 > We believe that the above scope restriction is problematic as=20 > drafted, because it implies that IETF specification are above=20 > the law. While we wholeheartedly agree that IETF should not=20 > set policy, it is clear that it needs to respond to policy.=20 > We are recognize that policy varies from jurisdiction to=20 > jurisdiction but believe that the general frameworks of=20 > copyright law set out in international treaties make it=20 > straightforward to enable this response. >=20 > We suggest that this paragraph is replaced by: >=20 > - Specification of policies regarding copyright-protected or=20 > illegal content. > For example, a decision to impose content filtering is=20 > outside the scope of > this working group. >=20 > 2. Content removal interface > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D >=20 > We note the proposed focus on the protocol between the=20 > in-network storage and P2P applications. We suggest that a=20 > further interface in > necessary: that between the in-network storage and content=20 > owners (and their representatives). While the primary=20 > interface may allow a certain amount of discovery, it does=20 > not allow the removal of infringing content and this needs to=20 > be enabled, along with certain safeguards against abuse. >=20 >=20 > We look forward to discussing these important issues. >=20 > Best regards, >=20 > Paul Jessop > Chief Technology Adviser, > Recording Industry Association of America >=20 >=20 >=20 >=20 > Paul Jessop county analytics > --------------------------------------------- > rights - technology - markets - music - media > --------------------------------------------- > paul@countyanalytics.com +44 7850 685378 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > decade mailing list > decade@ietf.org > https://www.ietf.org/mailman/listinfo/decade >=20 > = From dbharrington@comcast.net Sat Apr 17 22:48:28 2010 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 B37DD3A6897 for ; Sat, 17 Apr 2010 22:48:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=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 yjoPTXYkZgGN for ; Sat, 17 Apr 2010 22:48:27 -0700 (PDT) Received: from qmta08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [76.96.62.80]) by core3.amsl.com (Postfix) with ESMTP id 961C43A6888 for ; Sat, 17 Apr 2010 22:48:26 -0700 (PDT) Received: from omta12.westchester.pa.mail.comcast.net ([76.96.62.44]) by qmta08.westchester.pa.mail.comcast.net with comcast id 6tly1e0040xGWP858toKLz; Sun, 18 Apr 2010 05:48:19 +0000 Received: from Harrington73653 ([67.189.235.106]) by omta12.westchester.pa.mail.comcast.net with comcast id 6toK1e0012JQnJT3YtoKyE; Sun, 18 Apr 2010 05:48:19 +0000 From: "David B Harrington" To: Date: Sun, 18 Apr 2010 01:48:16 -0400 Message-ID: <001201cadeba$be627f90$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AcreuoNtwb9884INTLaEmGDPvii+9gAACsCA X-Mailman-Approved-At: Sun, 18 Apr 2010 05:13:47 -0700 Subject: [decade] proposed charter X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Apr 2010 05:48:28 -0000 Hi, Looking at the 3/26 proposed charter posted on 4-12, I have some comments: P2P networks are virtual networks overlaid onto physical networks, and while the P2P storage might be related to a specific P2P cache, that might be implemented on a physical storage device owned by somebody other than the owner of the P2P application. 1) in the first paragraph, there are references to "the network" and "inside networks". The decade work will cross administrative boundaries. The charter needs to be more specific about which network is being referenced here. 2) in the 2nd paragraph, the statement "applications may be better-equipped to decide ..." Better equipped than whom? again, it is important to differentiate between the virtual storage being used by a specific application, and the physical storage that actually stores the data. I think the owner of the physical storage may be better-equipped to make decisions about how the in-network storage is used than any particular P2P application. The P2P application might have a better understanding of application-specific issues, but multiple P2P applications might be contending for the same physical storage. There may be an application whose job is to coordinate multiple virtual allocations of storage to different applications, and that coordinator might be better-equipped to make decisions about the storage. 3) I disagree with the assertion that both of these problems can be effectively addressed by using an open, standard protocol to access in-network storage. I do believe that having an open standard can help to mitigate the issues, but I do not believe these problems can be effectively addressed using one open, standard protocol. There are many problems that are interrelated, and likely cross-domain, that will require more than just a protocol to solve. And many of the issues are layer 8 and above - economic, governmental, regulatory, etc. 4) I recommend the WG consider documenting, and possibly addressing, some of the cross-domain access control requirements. 5) The sentence starting "if new protocol development (and hence rechartering)" seems to imply that protocol work can start before rechartering, or that rechartering can be done before completion of existing deliverables. That sounds like a slippery slope to me ... 6) "Implementation of policies" - we don't do implementation, we do specifications. and generally, the ietf does not specify policies; it specifies technologies. organizations that specify policies are welcome to utilize our standardized technologies. I would eliminate the second sentence in that bullet - the example of what is out of scope. Simply leave it that "specification of policies regarding copyright-protected or illegal content" is out of scope. I think the justification for this being out of scope is very similar to the reasons we don't specify policies (or develop explicit-technology features) for wiretapping (RFC 2804). We focus on developing the best technologies. Wiretapping or copyright protection or content legality requirements differ dramatically across non-technological domains. Trying to build in features to mitigate this unclear set of (layer 8+) requirements would dramatically complicate technical designs. This should be out of scope for an organization focused on engineering standards, not policy. David Harrington dbharrington@comcast.net ietfdbh@comcast.net dharrington@huawei.com From richard.alimi@gmail.com Sun Apr 18 11:14:46 2010 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 5AAC33A6B79 for ; Sun, 18 Apr 2010 11:14:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.885 X-Spam-Level: X-Spam-Status: No, score=0.885 tagged_above=-999 required=5 tests=[AWL=0.262, BAYES_50=0.001, FM_FORGED_GMAIL=0.622] 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 H+fKcTq6wscm for ; Sun, 18 Apr 2010 11:14:45 -0700 (PDT) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.210.182]) by core3.amsl.com (Postfix) with ESMTP id 17E553A6B70 for ; Sun, 18 Apr 2010 11:14:45 -0700 (PDT) Received: by yxe12 with SMTP id 12so2371468yxe.32 for ; Sun, 18 Apr 2010 11:14:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:received:message-id:subject :from:to:cc:content-type; bh=5jJIrBsGfIeOeU18Iz/bh8xCYdAj1kL0Xnf8VZiHnY8=; b=MB0sCrkRQzcWkWpYYA77N+s6WCRfVrT2cMil4pnEU2X+ZhFbsHCVX9yf5zNZF3Co+B 0rfYBzqjtJ8wt/0b4sMYEebSX0qvl8CbfEy7JyQw8m4v3gXaMEyLvYYz2nh4iIY35dw4 w3z1b4+bY0J5OESpVevzI9F/D/TAJIGZV4QGY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=WR5yANbF/2jTXVA/vZjc9817h4hwmtVrnJwkycP8TaJ5L0FCIMn1IhGihoqE3JSlkg ZZ+X6EbdpMUPJ8aPmH8QryJLoTULs22H3EfSWrKQcd2IDOhn7tzn1AK5CG9Kw3X7bycr u3lEkoVlylhRa04TWRUMWDWLDyeq4w5GJe4L4= MIME-Version: 1.0 Sender: richard.alimi@gmail.com Received: by 10.231.169.12 with HTTP; Sun, 18 Apr 2010 11:14:34 -0700 (PDT) In-Reply-To: <001201cadeba$be627f90$0600a8c0@china.huawei.com> References: <001201cadeba$be627f90$0600a8c0@china.huawei.com> Date: Sun, 18 Apr 2010 14:14:34 -0400 X-Google-Sender-Auth: 4932c468ca32a8e1 Received: by 10.150.128.4 with SMTP id a4mr4699393ybd.301.1271614474375; Sun, 18 Apr 2010 11:14:34 -0700 (PDT) Message-ID: From: Richard Alimi To: David B Harrington Content-Type: text/plain; charset=ISO-8859-1 Cc: decade@ietf.org Subject: Re: [decade] proposed charter X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Apr 2010 18:14:46 -0000 Hi David, Thank you very much for your comments. Please see inline: On Sun, Apr 18, 2010 at 1:48 AM, David B Harrington wrote: > Hi, > > > > Looking at the 3/26 proposed charter posted on 4-12, I have some > comments: > > P2P networks are virtual networks overlaid onto physical networks, and > while the P2P storage > might be related to a specific P2P cache, that might be implemented on > a physical storage device owned by somebody other than the owner of > the P2P application. Yes, this is certainly a deployment possibility. > > 1) in the first paragraph, there are references to "the network" and > "inside networks". > The decade work will cross administrative boundaries. The charter > needs to be more specific about which network is being referenced > here. The intention here was to refer to "the network" between hosts running P2P applications. You're correct that this definition of "the network" can typically include multiple administrative domains. There is discussion later in the charter indicating that it can indeed cross administrative domains (as related to access control); This can be clarified here too if it is unclear to others as well. > > 2) in the 2nd paragraph, the statement "applications may be > better-equipped to decide ..." > Better equipped than whom? again, it is important to differentiate > between the virtual storage being used by a specific application, and > the physical storage that actually stores the data. > I think the owner of the physical storage may be better-equipped to > make decisions about how the in-network storage is used than any > particular P2P application. The P2P application might have a better > understanding of application-specific issues, but multiple P2P > applications might be contending for the same physical storage. There > may be an application whose job is to coordinate multiple virtual > allocations of storage to different applications, and that coordinator > might be better-equipped to make decisions about the storage. I certainly agree that the owner of the physical storage does have a say in how resources can be divided amongst users. As we mentioned during the BoF, we are certainly _not_ trying to create some (seemingly) limitless cloud storage or pool of resources that can be used by P2P applications. We fully recognize that the parties providing the storage will have their own considerations. As part of a research project we were working on, we addressed this issue using a hierarchy for resource allocation. Please see slide 10 of these slides that were presented at the Bar BoF at IETF75: http://trac.tools.ietf.org/area/app/trac/raw-attachment/wiki/BarBofs/IETF75/P2PCaching/decade-ietf75-3-sailor.pdf In this model, at the top level, the owner of the storage can define policies for sharing bandwidth/storage across users. Users may further allocate those amongst applications, and applications may then share resources (e.g., bandwidth) amongst peers. This is of course not a final solution or the only solution, but we certainly recognize the existence of the issues that you mentioned. If it makes things clearer, I think it is fine to mention in the charter that we recognize that storage providers can have their own policies for how resources are shared and allocated amongst users. > > 3) I disagree with the assertion that both of these problems can be > effectively addressed by using an open, standard protocol to access > in-network storage. I do believe that having an open standard can help > to mitigate the issues, but I do not believe these problems can be > effectively addressed using one open, standard protocol. There are > many problems that are interrelated, and likely cross-domain, that > will require more than just a protocol to solve. One immediate item that comes to mind here (and you have mentioned it below) is access control that crosses administrative boundaries, which we have explicitly called out in the charter and in one of the requirements: http://tools.ietf.org/html/draft-gu-decade-reqs-04#section-4.2 Do you have any other specific issues in mind? If it makes it clearer, we could change "protocol" to be plural. Note that the charter does not restrict us to considering a single "protocol" to solve all of the necessary problems. In particular, the description of the Architecture document indicates: "This document will identify DECADE's relationship with existing IETF protocols. Existing protocols will be used wherever possible and appropriate to support DECADE's requirements." > And many of the issues are layer 8 and above - economic, governmental, > regulatory, etc. Yes, there are certainly issues here, but the intent here is to scope for the technical issues. Perhaps the other thread regarding copyrighted/illegal content is more suited for this particular discussion? > 4) I recommend the WG consider documenting, and possibly addressing, > some of the cross-domain access control requirements. I think this is addressed in response to (3) above. Were you thinking of other aspects of cross-domain access control that should be documented beyond what is already mentioned? > > 5) The sentence starting "if new protocol development (and hence > rechartering)" seems to imply that protocol work can start before > rechartering, or that rechartering can be done before completion of > existing deliverables. That sounds like a slippery slope to me ... We certainly did not mean to imply that protocol development can begin before rechartering. With regards to the Requirements and Architecture deliverables, I personally feel that we should have them stabilized (shown by WG consensus), but not published, before rechartering. It is certainly possible that details in the protocol work will may require some minor updates to the text in the Requirements or Architecture document. > 6) "Implementation of policies" - we don't do implementation, we do > specifications. and generally, the ietf does not specify policies; it > specifies technologies. organizations that specify policies are > welcome to utilize our standardized technologies. If a storage provider were to enabling some sort of policy, I believe there are two steps towards achieving it: (1) Providing the capabilities to specify the policy (e.g., a filtering language) (2) Specifying the policies to be applied Item (2) is clearly out of scope for the WG since it is up to the storage provider. The word "implementation" in the charter text was meant to refer to step (1) in the sense of allowing the storage provider to implement policies, and not in the sense of writing code. The intent was that (1) is also out of scope, since it could be accomplished a separate entity than the protocol between applications and the storage. > I would eliminate the second sentence in that bullet - the example of > what is out of scope. > Simply leave it that "specification of policies regarding > copyright-protected or illegal content" is out of scope. Leaving out the example is fine with me. > I think the justification for this being out of scope is very similar > to the reasons we don't specify policies (or develop > explicit-technology features) for wiretapping (RFC 2804). We focus on > developing the best technologies. Wiretapping or copyright protection > or content legality requirements differ dramatically across > non-technological domains. Trying to build in features to mitigate > this unclear set of (layer 8+) requirements would dramatically > complicate technical > designs. This should be out of scope for an organization focused on > engineering standards, not policy. Agreed. > > David Harrington > dbharrington@comcast.net > ietfdbh@comcast.net > dharrington@huawei.com Thanks again for the comments! -- Richard Alimi Department of Computer Science Yale University From melodysong@huawei.com Mon Apr 19 01:03:20 2010 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 572BD3A6829; Mon, 19 Apr 2010 01:03:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.888 X-Spam-Level: X-Spam-Status: No, score=0.888 tagged_above=-999 required=5 tests=[AWL=-1.217, BAYES_50=0.001, 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 ysyW6qTJ0HJn; Mon, 19 Apr 2010 01:03:19 -0700 (PDT) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 9545C3A67D6; Mon, 19 Apr 2010 01:03:17 -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 <0L1400I616CBXH@szxga04-in.huawei.com>; Mon, 19 Apr 2010 16:02:35 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L1400JOD6CAUW@szxga04-in.huawei.com>; Mon, 19 Apr 2010 16:02:35 +0800 (CST) Received: from s64081a ([10.138.84.48]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L140026U6BDBW@szxml06-in.huawei.com>; Mon, 19 Apr 2010 16:02:34 +0800 (CST) Date: Mon, 19 Apr 2010 16:01:59 +0800 From: Song Haibin In-reply-to: To: 'Richard Alimi' , 'David B Harrington' Message-id: <007901cadf96$995dcbf0$30548a0a@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: AcrfIwci2O/vVqCUT8OQiBb2tC21kQAag/rQ Cc: decade@ietf.org, iesg@ietf.org Subject: Re: [decade] proposed charter X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Apr 2010 08:03:20 -0000 Hi David, I copied this thread to iesg mailing list, because I guess maybe other iesg memebers would be interested. > -----Original Message----- > From: decade-bounces@ietf.org > [mailto:decade-bounces@ietf.org] On Behalf Of Richard Alimi > Sent: Monday, April 19, 2010 2:15 AM > To: David B Harrington > Cc: decade@ietf.org > Subject: Re: [decade] proposed charter > > Hi David, > > Thank you very much for your comments. Please see inline: > > On Sun, Apr 18, 2010 at 1:48 AM, David B Harrington > wrote: > > Hi, > > > > > > > > Looking at the 3/26 proposed charter posted on 4-12, I have some > > comments: > > > > P2P networks are virtual networks overlaid onto physical > networks, and > > while the P2P storage might be related to a specific P2P > cache, that > > might be implemented on a physical storage device owned by somebody > > other than the owner of the P2P application. > > Yes, this is certainly a deployment possibility. > > > > > 1) in the first paragraph, there are references to "the > network" and > > "inside networks". > > The decade work will cross administrative boundaries. The charter > > needs to be more specific about which network is being referenced > > here. > > The intention here was to refer to "the network" between > hosts running P2P applications. You're correct that this > definition of "the network" can typically include multiple > administrative domains. There is discussion later in the > charter indicating that it can indeed cross administrative > domains (as related to access control); This can be > clarified here too if it is unclear to others as well. > > > > > 2) in the 2nd paragraph, the statement "applications may be > > better-equipped to decide ..." > > Better equipped than whom? In this paragraph, we compare with existing P2P caches. The existing P2P cache does not allow this kind of flexibility to integrate application policies. >>again, it is important to differentiate > > between the virtual storage being used by a specific > application, and > > the physical storage that actually stores the data. The in-network storage is considered as the logical entity in the network. It is either virtual or physical. It can be clarified in the charter if necessary. > > I think the owner of the physical storage may be better-equipped to > > make decisions about how the in-network storage is used than any > > particular P2P application. The P2P application might have a better > > understanding of application-specific issues, but multiple P2P > > applications might be contending for the same physical > storage. There > > may be an application whose job is to coordinate multiple virtual > > allocations of storage to different applications, and that > coordinator > > might be better-equipped to make decisions about the storage. > > I certainly agree that the owner of the physical storage does > have a say in how resources can be divided amongst users. As > we mentioned during the BoF, we are certainly _not_ trying to > create some > (seemingly) limitless cloud storage or pool of resources that > can be used by P2P applications. We fully recognize that the > parties providing the storage will have their own considerations. > > As part of a research project we were working on, we > addressed this issue using a hierarchy for resource > allocation. Please see slide 10 of these slides that were > presented at the Bar BoF at IETF75: > > http://trac.tools.ietf.org/area/app/trac/raw-attachment/wiki/B > arBofs/IETF75/P2PCaching/decade-ietf75-3-sailor.pdf > In this model, at the top level, the owner of the storage can > define policies for sharing bandwidth/storage across users. > Users may further allocate those amongst applications, and > applications may then share resources (e.g., bandwidth) amongst peers. > > This is of course not a final solution or the only solution, > but we certainly recognize the existence of the issues that > you mentioned. > > If it makes things clearer, I think it is fine to mention in > the charter that we recognize that storage providers can have > their own policies for how resources are shared and allocated > amongst users. > > > > > 3) I disagree with the assertion that both of these problems can be > > effectively addressed by using an open, standard protocol to access > > in-network storage. I do believe that having an open > standard can help > > to mitigate the issues, but I do not believe these problems can be > > effectively addressed using one open, standard protocol. There are > > many problems that are interrelated, and likely cross-domain, that > > will require more than just a protocol to solve. > > One immediate item that comes to mind here (and you have mentioned it > below) is access control that crosses administrative > boundaries, which we have explicitly called out in the > charter and in one of the > requirements: > http://tools.ietf.org/html/draft-gu-decade-reqs-04#section-4.2 > > Do you have any other specific issues in mind? > > If it makes it clearer, we could change "protocol" to be > plural. Note that the charter does not restrict us to > considering a single "protocol" to solve all of the necessary > problems. In particular, the description of the Architecture > document indicates: "This document will identify DECADE's > relationship with existing IETF protocols. > Existing protocols will be used wherever possible and > appropriate to support DECADE's requirements." > > > And many of the issues are layer 8 and above - economic, > governmental, > > regulatory, etc. > > Yes, there are certainly issues here, but the intent here is > to scope for the technical issues. Perhaps the other thread > regarding copyrighted/illegal content is more suited for this > particular discussion? > > > 4) I recommend the WG consider documenting, and possibly > addressing, > > some of the cross-domain access control requirements. > > I think this is addressed in response to (3) above. Were you > thinking of other aspects of cross-domain access control that > should be documented beyond what is already mentioned? > > > > > 5) The sentence starting "if new protocol development (and hence > > rechartering)" seems to imply that protocol work can start before > > rechartering, or that rechartering can be done before completion of > > existing deliverables. That sounds like a slippery slope to me ... > > We certainly did not mean to imply that protocol development > can begin before rechartering. With regards to the > Requirements and Architecture deliverables, I personally feel > that we should have them stabilized (shown by WG consensus), > but not published, before rechartering. It is certainly > possible that details in the protocol work will may require > some minor updates to the text in the Requirements or > Architecture document. > > > 6) "Implementation of policies" - we don't do implementation, we do > > specifications. and generally, the ietf does not specify > policies; it > > specifies technologies. organizations that specify policies are > > welcome to utilize our standardized technologies. > > If a storage provider were to enabling some sort of policy, I > believe there are two steps towards achieving it: > (1) Providing the capabilities to specify the policy (e.g., a > filtering language) > (2) Specifying the policies to be applied > > Item (2) is clearly out of scope for the WG since it is up to > the storage provider. > > The word "implementation" in the charter text was meant to > refer to step (1) in the sense of allowing the storage > provider to implement policies, and not in the sense of > writing code. The intent was that > (1) is also out of scope, since it could be accomplished a > separate entity than the protocol between applications and > the storage. > > > I would eliminate the second sentence in that bullet - the > example of > > what is out of scope. > > Simply leave it that "specification of policies regarding > > copyright-protected or illegal content" is out of scope. > > Leaving out the example is fine with me. > > > I think the justification for this being out of scope is > very similar > > to the reasons we don't specify policies (or develop > > explicit-technology features) for wiretapping (RFC 2804). > We focus on > > developing the best technologies. Wiretapping or copyright > protection > > or content legality requirements differ dramatically across > > non-technological domains. Trying to build in features to mitigate > > this unclear set of (layer 8+) requirements would dramatically > > complicate technical designs. This should be out of scope for an > > organization focused on engineering standards, not policy. > > Agreed. > > > > > David Harrington > > dbharrington@comcast.net > > ietfdbh@comcast.net > > dharrington@huawei.com > > > Thanks again for the comments! > -- > Richard Alimi > Department of Computer Science > Yale University > BR, Haibin From root@core3.amsl.com Tue Apr 27 11:00:01 2010 Return-Path: X-Original-To: decade@ietf.org Delivered-To: decade@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id ABBB928C121; Tue, 27 Apr 2010 11:00:01 -0700 (PDT) From: IESG Secretary To: ietf-announce@ietf.org Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20100427180001.ABBB928C121@core3.amsl.com> Date: Tue, 27 Apr 2010 11:00:01 -0700 (PDT) Cc: decade@ietf.org, richard_woundy@cable.comcast.com Subject: [decade] WG Action: DECoupled Application Data Enroute (decade) X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Apr 2010 18:00:01 -0000 A new IETF working group has been formed in the Applications Area. For additional information, please contact the Area Directors or the WG Chairs. DECoupled Application Data Enroute (decade) -------------------------------------------------- Last modified: 2010-04-23 Chair(s): Haibin Song Richard Woundy Applications Area Director(s): * Alexey Melnikov * Peter Saint-Andre Applications Area Advisor: * Alexey Melnikov Mailing Lists: General Discussion: decade@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/decade Archive: http://www.ietf.org/mail-archive/web/decade/current/maillist.html Description of Working Group: Peer-to-Peer (P2P) applications, including both P2P streaming and P2P file-sharing applications, make up a large fraction of traffic in the Internet today. One way to reduce access network and/or cross-domain bandwidth usage by P2P applications is to introduce storage capabilities in the network between hosts running P2P applications. Allowing P2P applications to store and retrieve data from inside the network can reduce traffic on the last-mile uplink, as well as backbone and transit links. Existing P2P caches often implement the specific P2P application protocols to operate transparently or act as super peers to provide in-network storage. However, it is challenging for P2P cache vendors to support a variety of evolving protocols. Also, for P2P applications, closed P2P caching systems limit effective utilization of in-network storage. Some P2P protocols may be entirely unsupported by a particular caching system. Additionally, applications may be better-equipped to decide how in-network storage is used to meet their specific requirements (e.g., data placement, access control and resource control). Note that providers of in-network storage may impose their own access control or resource usage policies. Both of these challenges can be effectively addressed by using open, standard protocols to access in-network storage. P2P applications can store and retrieve content in the in-network storage, as well as control resources (e.g., bandwidth, connections) consumed by peers in a P2P application. As a simple example, a peer can choose to store content in the in-network storage, and direct other peers to retrieve from that location, reducing last-mile link usage. Furthermore, since a P2P client may have multiple peers, it can control resources used by each peer to store and retrieve content. Though there are existing data access protocols (e.g., HTTP, NFS, WebDAV), they might be lacking capabilities for fine-grained access and resource control (e.g., bandwidth and connections) that are essential for today's advanced P2P applications. The Working Group (WG) will have three primary tasks. First, the WG will identify target applications to appropriately scope the problem and requirements. P2P applications are the primary target, but suitability to other applications with similar requirements may be considered depending on additional complexity required to support such applications. Second, the WG will identify the requirements to enable target applications to utilize in-network storage. Requirements will include the ability for an application to (1) store, retrieve, and manage data, (2) indicate access control policies for storing and retrieving data suitable to an environment with users across multiple administrative and security domains (e.g., in a P2P environment), and (3) indicate resource control policies for storing and retrieving data. Third, the WG will develop an architecture within which the DECADE protocol can be specified. This architecture will identify DECADE's relationship to existing IETF protocols and where (if any) new protocol is needed or extensions to existing protocols need to be made. The architecture will not specify a protocol or extension; if development of a new protocol is needed, the WG will seek to recharter for this purpose or might ask an existing WG to work on such extensions. The WG will focus on the following work items: - A "problem statement" document. This document provides a description of the problem and common terminology. - A requirements document. This document lists the requirements for the in-network storage service (e.g., supported operations) and the protocol to support it. The service will include storing, retrieving, and managing data as well as specifying both access control and resource control policies in the in-network storage pertaining to that data. - A survey document. This document will survey existing related mechanisms and protocols (e.g., HTTP, NFS, and WebDAV), and evaluate their applicability to DECADE. - An architecture document. This document will identify DECADE's relationship with existing IETF protocols. Existing protocols will be used wherever possible and appropriate to support DECADE's requirements. In particular, data storage, retrieval, and management may be provided by an existing IETF protocols. The WG will not limit itself to a single data transport protocol since different protocols may have varying implementation costs and performance tradeoffs. However, to keep interoperability manageable, a small number of specific, targeted, data transport protocols will be identified and used. - An document describing the integration of DECADE with existing P2P applications (e.g., integration with BitTorrent). If new protocol development is deemed necessary, the WG will be rechartered. It is not expected that all work items will be ready for IESG review by that point, but WG consensus must show that documents directing eventual protocol development (Requirements and Architecture document) have stabilized. This permits adjustments to such documents as necessary to maintain consistency as protocol development is done. The following issues are considered out-of-scope for the WG: - Specification of policies regarding copyright-protected or illegal content. - Locating the "best" in-network storage location from which to retrieve content if there are more than one location can provide the same content. - Developing a new protocol for data transport between P2P applications and in-network storage. Goals and Milestones: Aug 2010 Working Group Last Call for Problem Statement Nov 2010 Submit Problem Statement to IESG as Informational Nov 2010 Working Group Last Call for Survey document Feb 2011 Submit Survey document to IESG as Informational Feb 2011 Working Group Last Call for Requirements document Feb 2011 Working Group Last Call for Architecture document Mar 2011 Identify need for rechartering May 2011 Submit Requirements document to IESG as Informational Jul 2011 Submit Architecture document to IESG as Informational From davidbryan@gmail.com Tue Apr 27 15:04:45 2010 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 6432F3A68F1 for ; Tue, 27 Apr 2010 15:04:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 s4k9pnACeKRI for ; Tue, 27 Apr 2010 15:04:44 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id 1D02B3A6812 for ; Tue, 27 Apr 2010 15:04:43 -0700 (PDT) Received: by gwaa12 with SMTP id a12so3560081gwa.31 for ; Tue, 27 Apr 2010 15:04:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=y6C3bzNqVzHuJKeQk6No5Db6YtvsfjqW3z/fYLXW5qE=; b=OmY/25ZpzV9PlQNIojzhyrVQLYDx9HoPD7BNJjIehacIz+xRhd5u/HagIDErOa8pFe Xm3G9Uve3e0DkXOPHrpisVc/IuGlhVUKhc2d3bkGIEclDpDNqwXRIVKa45wFkOEKfGvE C7VR4cejiu44PUsIG7g7Qi1HnQPI+2qAERO/o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=Asjs20mQP8qoLA8AlLShY0fo13OZzmSfE+i2y+WWkvmYsZcXD6Hezl86u9zGlUdFlB QeEx8XwQ5bGhmv3INbsvwffpxtbJVpsRIjWCJBxzxMrYWk1d4WOPyzmQ+f4NloidsH2H 9RaB8ChU85pXnmjT7a/6NocdoftUMvr3KCiAc= MIME-Version: 1.0 Received: by 10.150.14.12 with SMTP id 12mr6137879ybn.282.1272405865724; Tue, 27 Apr 2010 15:04:25 -0700 (PDT) Sender: davidbryan@gmail.com Received: by 10.151.79.19 with HTTP; Tue, 27 Apr 2010 15:04:25 -0700 (PDT) In-Reply-To: <20100427180001.ABBB928C121@core3.amsl.com> References: <20100427180001.ABBB928C121@core3.amsl.com> Date: Tue, 27 Apr 2010 18:04:25 -0400 X-Google-Sender-Auth: 9aa8edc502ba2367 Message-ID: From: "David A. Bryan" To: DECADE Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: richard_woundy@cable.comcast.com Subject: Re: [decade] WG Action: DECoupled Application Data Enroute (decade) X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Apr 2010 22:04:45 -0000 Great to see the group get chartered. Thanks to all the folks who have worked to see this group come together! David On Tue, Apr 27, 2010 at 2:00 PM, IESG Secretary w= rote: > A new IETF working group has been formed in the Applications Area. =A0For > additional information, please contact the Area Directors or the WG > Chairs. > > DECoupled Application Data Enroute (decade) > -------------------------------------------------- > Last modified: 2010-04-23 > > Chair(s): > Haibin Song > Richard Woundy > > Applications Area Director(s): > * Alexey Melnikov > * Peter Saint-Andre > > Applications Area Advisor: > * Alexey Melnikov > > Mailing Lists: > =A0General Discussion: decade@ietf.org > =A0To Subscribe: https://www.ietf.org/mailman/listinfo/decade > =A0Archive: > http://www.ietf.org/mail-archive/web/decade/current/maillist.html > > Description of Working Group: > > Peer-to-Peer (P2P) applications, including both P2P streaming and P2P > file-sharing applications, make up a large fraction of traffic in > the Internet today. One way to reduce access network and/or cross-domain > bandwidth usage by P2P applications is to introduce storage capabilities > in the network between hosts running P2P applications. Allowing P2P > applications to store and retrieve data from inside the network can > reduce traffic on the last-mile uplink, as well as backbone and > transit links. > > Existing P2P caches often implement the specific P2P application > protocols to operate transparently or act as super peers to provide > in-network storage. However, it is challenging for P2P cache vendors to > support a variety of evolving protocols. Also, for P2P applications, > closed P2P caching systems limit effective utilization of in-network > storage. Some P2P protocols may be entirely unsupported by a particular > caching system. Additionally, applications may be better-equipped to > decide how in-network storage is used to meet their specific > requirements (e.g., data placement, access control and resource > control). Note that providers of in-network storage may impose their > own access control or resource usage policies. > > Both of these challenges can be effectively addressed by using open, > standard protocols to access in-network storage. P2P applications can > store and retrieve content in the in-network storage, as well as control > resources (e.g., bandwidth, connections) consumed by peers in a P2P > application. As a simple example, a peer can choose to store content in > the in-network storage, and direct other peers to retrieve from that > location, reducing last-mile link usage. Furthermore, since a P2P > client may have multiple peers, it can control resources used by each > peer to store and retrieve content. Though there are existing data > access protocols (e.g., HTTP, NFS, WebDAV), they might be lacking > capabilities for fine-grained access and resource control (e.g., > bandwidth and connections) that are essential for today's advanced P2P > applications. > > The Working Group (WG) will have three primary tasks. First, the WG will > identify target applications to appropriately scope the problem and > requirements. P2P applications are the primary target, but suitability > to other applications with similar requirements may be considered > depending on additional complexity required to support such > applications. > > Second, the WG will identify the requirements to enable target > applications to utilize in-network storage. Requirements will include > the ability for an application to (1) store, retrieve, and manage data, > (2) indicate access control policies for storing and retrieving data > suitable to an environment with users across multiple administrative and > security domains (e.g., in a P2P environment), and (3) indicate resource > control policies for storing and retrieving data. > > Third, the WG will develop an architecture within which the DECADE > protocol can be specified. This architecture will identify DECADE's > relationship to existing IETF protocols and where (if any) new protocol > is needed or extensions to existing protocols need to be made. The > architecture will not specify a protocol or extension; if development of > a new protocol is needed, the WG will seek to recharter for this purpose > or might ask an existing WG to work on such extensions. > > The WG will focus on the following work items: > > - A "problem statement" document. This document provides a description > of the problem and common terminology. > > - A requirements document. This document lists the requirements for the > in-network storage service (e.g., supported operations) and the > protocol to support it. The service will include storing, retrieving, > and managing data as well as specifying both access control and > resource control policies in the in-network storage pertaining to that > data. > > - A survey document. This document will survey existing related > mechanisms and protocols (e.g., HTTP, NFS, and WebDAV), and evaluate > their applicability to DECADE. > > - An architecture document. This document will identify DECADE's > relationship with existing IETF protocols. Existing protocols will be > used wherever possible and appropriate to support DECADE's > requirements. In particular, data storage, retrieval, and management > may be provided by an existing IETF protocols. The WG will not limit > itself to a single data transport protocol since different protocols > may have varying implementation costs and performance tradeoffs. > However, to keep interoperability manageable, a small number of > specific, targeted, data transport protocols will be identified and > used. > > - An document describing the integration of DECADE with existing P2P > applications (e.g., integration with BitTorrent). > > If new protocol development is deemed necessary, the WG will be > rechartered. It is not expected that all work items will be ready for > IESG review by that point, but WG consensus must show that documents > directing eventual protocol development (Requirements and Architecture > document) have stabilized. This permits adjustments to such documents as > necessary to maintain consistency as protocol development is done. > > The following issues are considered out-of-scope for the WG: > > - Specification of policies regarding copyright-protected or illegal > content. > > - Locating the "best" in-network storage location from which to retrieve > content if there are more than one location can provide the same > content. > > - Developing a new protocol for data transport between P2P applications > and in-network storage. > > Goals and Milestones: > > Aug 2010 Working Group Last Call for Problem Statement > Nov 2010 Submit Problem Statement to IESG as Informational > Nov 2010 Working Group Last Call for Survey document > Feb 2011 Submit Survey document to IESG as Informational > Feb 2011 Working Group Last Call for Requirements document > Feb 2011 Working Group Last Call for Architecture document > Mar 2011 Identify need for rechartering > May 2011 Submit Requirements document to IESG as Informational > Jul 2011 Submit Architecture document to IESG as Informational > _______________________________________________ > decade mailing list > decade@ietf.org > https://www.ietf.org/mailman/listinfo/decade > From guyingjie@huawei.com Tue Apr 27 17:50:25 2010 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 BCA6A3A6A5B; Tue, 27 Apr 2010 17:50:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.693 X-Spam-Level: * X-Spam-Status: No, score=1.693 tagged_above=-999 required=5 tests=[AWL=2.188, 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 D0+nEE6QXWjy; Tue, 27 Apr 2010 17:50:24 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 5AB253A6A5E; Tue, 27 Apr 2010 17:50:24 -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 <0L1K00LHYABDBL@szxga03-in.huawei.com>; Wed, 28 Apr 2010 08:50:01 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L1K001WYABD8D@szxga03-in.huawei.com>; Wed, 28 Apr 2010 08:50:01 +0800 (CST) Received: from g00107907 ([10.138.84.88]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L1K0009NABDQL@szxml04-in.huawei.com>; Wed, 28 Apr 2010 08:50:01 +0800 (CST) Date: Wed, 28 Apr 2010 08:50:04 +0800 From: "Y.J. Gu" In-reply-to: <20100427180001.ABBB928C121@core3.amsl.com> To: 'IESG Secretary' , ietf-announce@ietf.org Message-id: <004401cae66c$bd80ed00$58548a0a@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: AcrmNLMKSGyOxPhKRWOcWqfstvk0MgAN0eDQ Cc: decade@ietf.org, richard_woundy@cable.comcast.com Subject: Re: [decade] WG Action: DECoupled Application Data Enroute (decade) X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Apr 2010 00:50:25 -0000 Congratulations to all of the contributors and attendees! Let's keep moving the work forward. Regards Yingjie Gu > -----Original Message----- > From: ietf-announce-bounces@ietf.org > [mailto:ietf-announce-bounces@ietf.org] On Behalf Of IESG Secretary > Sent: Wednesday, April 28, 2010 2:00 AM > To: ietf-announce@ietf.org > Cc: decade@ietf.org; richard_woundy@cable.comcast.com > Subject: WG Action: DECoupled Application Data Enroute (decade) > > A new IETF working group has been formed in the Applications > Area. For additional information, please contact the Area > Directors or the WG Chairs. > > DECoupled Application Data Enroute (decade) > -------------------------------------------------- > Last modified: 2010-04-23 > > Chair(s): > Haibin Song > Richard Woundy > > Applications Area Director(s): > * Alexey Melnikov > * Peter Saint-Andre > > Applications Area Advisor: > * Alexey Melnikov > > Mailing Lists: > General Discussion: decade@ietf.org > To Subscribe: https://www.ietf.org/mailman/listinfo/decade > Archive: > http://www.ietf.org/mail-archive/web/decade/current/maillist.html > > Description of Working Group: > > Peer-to-Peer (P2P) applications, including both P2P streaming > and P2P file-sharing applications, make up a large fraction > of traffic in the Internet today. One way to reduce access > network and/or cross-domain bandwidth usage by P2P > applications is to introduce storage capabilities in the > network between hosts running P2P applications. Allowing P2P > applications to store and retrieve data from inside the > network can reduce traffic on the last-mile uplink, as well > as backbone and transit links. > > Existing P2P caches often implement the specific P2P > application protocols to operate transparently or act as > super peers to provide in-network storage. However, it is > challenging for P2P cache vendors to support a variety of > evolving protocols. Also, for P2P applications, closed P2P > caching systems limit effective utilization of in-network > storage. Some P2P protocols may be entirely unsupported by a > particular caching system. Additionally, applications may be > better-equipped to decide how in-network storage is used to > meet their specific requirements (e.g., data placement, > access control and resource control). Note that providers of > in-network storage may impose their own access control or > resource usage policies. > > Both of these challenges can be effectively addressed by > using open, standard protocols to access in-network storage. > P2P applications can store and retrieve content in the > in-network storage, as well as control resources (e.g., > bandwidth, connections) consumed by peers in a P2P > application. As a simple example, a peer can choose to store > content in the in-network storage, and direct other peers to > retrieve from that location, reducing last-mile link usage. > Furthermore, since a P2P client may have multiple peers, it > can control resources used by each peer to store and retrieve > content. Though there are existing data access protocols > (e.g., HTTP, NFS, WebDAV), they might be lacking capabilities > for fine-grained access and resource control (e.g., bandwidth > and connections) that are essential for today's advanced P2P > applications. > > The Working Group (WG) will have three primary tasks. First, > the WG will identify target applications to appropriately > scope the problem and requirements. P2P applications are the > primary target, but suitability to other applications with > similar requirements may be considered depending on > additional complexity required to support such applications. > > Second, the WG will identify the requirements to enable > target applications to utilize in-network storage. > Requirements will include the ability for an application to > (1) store, retrieve, and manage data, > (2) indicate access control policies for storing and > retrieving data suitable to an environment with users across > multiple administrative and security domains (e.g., in a P2P > environment), and (3) indicate resource control policies for > storing and retrieving data. > > Third, the WG will develop an architecture within which the > DECADE protocol can be specified. This architecture will > identify DECADE's relationship to existing IETF protocols and > where (if any) new protocol is needed or extensions to > existing protocols need to be made. The architecture will not > specify a protocol or extension; if development of a new > protocol is needed, the WG will seek to recharter for this > purpose or might ask an existing WG to work on such extensions. > > The WG will focus on the following work items: > > - A "problem statement" document. This document provides a > description of the problem and common terminology. > > - A requirements document. This document lists the > requirements for the in-network storage service (e.g., > supported operations) and the protocol to support it. The > service will include storing, retrieving, and managing data > as well as specifying both access control and resource > control policies in the in-network storage pertaining to that data. > > - A survey document. This document will survey existing > related mechanisms and protocols (e.g., HTTP, NFS, and > WebDAV), and evaluate their applicability to DECADE. > > - An architecture document. This document will identify > DECADE's relationship with existing IETF protocols. Existing > protocols will be used wherever possible and appropriate to > support DECADE's requirements. In particular, data storage, > retrieval, and management may be provided by an existing IETF > protocols. The WG will not limit itself to a single data > transport protocol since different protocols may have varying > implementation costs and performance tradeoffs. > However, to keep interoperability manageable, a small number > of specific, targeted, data transport protocols will be > identified and used. > > - An document describing the integration of DECADE with > existing P2P applications (e.g., integration with BitTorrent). > > If new protocol development is deemed necessary, the WG will > be rechartered. It is not expected that all work items will > be ready for IESG review by that point, but WG consensus must > show that documents directing eventual protocol development > (Requirements and Architecture > document) have stabilized. This permits adjustments to such > documents as necessary to maintain consistency as protocol > development is done. > > The following issues are considered out-of-scope for the WG: > > - Specification of policies regarding copyright-protected or > illegal content. > > - Locating the "best" in-network storage location from which > to retrieve content if there are more than one location can > provide the same content. > > - Developing a new protocol for data transport between P2P > applications and in-network storage. > > Goals and Milestones: > > Aug 2010 Working Group Last Call for Problem Statement Nov > 2010 Submit Problem Statement to IESG as Informational Nov > 2010 Working Group Last Call for Survey document Feb 2011 > Submit Survey document to IESG as Informational Feb 2011 > Working Group Last Call for Requirements document Feb 2011 > Working Group Last Call for Architecture document Mar 2011 > Identify need for rechartering May 2011 Submit Requirements > document to IESG as Informational Jul 2011 Submit > Architecture document to IESG as Informational > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-announce From denghui02@gmail.com Tue Apr 27 17:59:45 2010 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 87A953A680D for ; Tue, 27 Apr 2010 17:59:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.496 X-Spam-Level: X-Spam-Status: No, score=-2.496 tagged_above=-999 required=5 tests=[AWL=0.103, 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 JUTM6i0WcWp3 for ; Tue, 27 Apr 2010 17:59:44 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by core3.amsl.com (Postfix) with ESMTP id 532C13A67E6 for ; Tue, 27 Apr 2010 17:59:44 -0700 (PDT) Received: by pwj2 with SMTP id 2so9981502pwj.31 for ; Tue, 27 Apr 2010 17:59:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=pjXgGb3HVZUF+bgvacCFYXzXxcPoRExRBdpFNMGPctk=; b=Lyj5E32ao/k4kwc/Plg6IdTJbgGs14lXhZxKkF27TVx0V0/1MQYmzwZ768Z/rc98fu r2CzCfxxAHfjl1EgnIZVP+cdLbKa6RQ0pyKSRGrelzcHSzM6z7yWXeVfD6T/mqSMOsPo 64mgYx/zSCmtwGrN7farj1L/q/NLFI+Zcc/Wo= 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:content-transfer-encoding; b=PCxUI01iaXIM0aa8xWk2wLCIg8ox8aVV6/wVVXE0RiTrjZHCQ/VEX5rJuer1+60Bkm 20wATa59iP59uIR5aXgKV/N+qlVUJbBQrWZVCKOkX+FMZ/so3o6b5CKUO046jtJD/6Lf 7S6JJ6eMPtVe4mtb7wFCT63nLmS93ZrvoAc/U= MIME-Version: 1.0 Received: by 10.143.21.2 with SMTP id y2mr3638215wfi.239.1272416367255; Tue, 27 Apr 2010 17:59:27 -0700 (PDT) Received: by 10.142.192.1 with HTTP; Tue, 27 Apr 2010 17:59:27 -0700 (PDT) In-Reply-To: <004401cae66c$bd80ed00$58548a0a@china.huawei.com> References: <20100427180001.ABBB928C121@core3.amsl.com> <004401cae66c$bd80ed00$58548a0a@china.huawei.com> Date: Wed, 28 Apr 2010 08:59:27 +0800 Message-ID: From: Hui Deng To: "Y.J. Gu" Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable Cc: decade@ietf.org, richard_woundy@cable.comcast.com Subject: Re: [decade] WG Action: DECoupled Application Data Enroute (decade) X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Apr 2010 00:59:45 -0000 Good work, Cong=A3=A1 -Hui 2010/4/28 Y.J. Gu : > Congratulations to all of the contributors and attendees! Let's keep mov= ing > the work forward. > > Regards > > Yingjie Gu > > > >> -----Original Message----- >> From: ietf-announce-bounces@ietf.org >> [mailto:ietf-announce-bounces@ietf.org] On Behalf Of IESG Secretary >> Sent: Wednesday, April 28, 2010 2:00 AM >> To: ietf-announce@ietf.org >> Cc: decade@ietf.org; richard_woundy@cable.comcast.com >> Subject: WG Action: DECoupled Application Data Enroute (decade) >> >> A new IETF working group has been formed in the Applications >> Area. For additional information, please contact the Area >> Directors or the WG Chairs. >> >> DECoupled Application Data Enroute (decade) >> -------------------------------------------------- >> Last modified: 2010-04-23 >> >> Chair(s): >> Haibin Song >> Richard Woundy >> >> Applications Area Director(s): >> * Alexey Melnikov >> * Peter Saint-Andre >> >> Applications Area Advisor: >> * Alexey Melnikov >> >> Mailing Lists: >> General Discussion: decade@ietf.org >> To Subscribe: https://www.ietf.org/mailman/listinfo/decade >> Archive: >> http://www.ietf.org/mail-archive/web/decade/current/maillist.html >> >> Description of Working Group: >> >> Peer-to-Peer (P2P) applications, including both P2P streaming >> and P2P file-sharing applications, make up a large fraction >> of traffic in the Internet today. One way to reduce access >> network and/or cross-domain bandwidth usage by P2P >> applications is to introduce storage capabilities in the >> network between hosts running P2P applications. Allowing P2P >> applications to store and retrieve data from inside the >> network can reduce traffic on the last-mile uplink, as well >> as backbone and transit links. >> >> Existing P2P caches often implement the specific P2P >> application protocols to operate transparently or act as >> super peers to provide in-network storage. However, it is >> challenging for P2P cache vendors to support a variety of >> evolving protocols. Also, for P2P applications, closed P2P >> caching systems limit effective utilization of in-network >> storage. Some P2P protocols may be entirely unsupported by a >> particular caching system. Additionally, applications may be >> better-equipped to decide how in-network storage is used to >> meet their specific requirements (e.g., data placement, >> access control and resource control). Note that providers of >> in-network storage may impose their own access control or >> resource usage policies. >> >> Both of these challenges can be effectively addressed by >> using open, standard protocols to access in-network storage. >> P2P applications can store and retrieve content in the >> in-network storage, as well as control resources (e.g., >> bandwidth, connections) consumed by peers in a P2P >> application. As a simple example, a peer can choose to store >> content in the in-network storage, and direct other peers to >> retrieve from that location, reducing last-mile link usage. >> Furthermore, since a P2P client may have multiple peers, it >> can control resources used by each peer to store and retrieve >> content. Though there are existing data access protocols >> (e.g., HTTP, NFS, WebDAV), they might be lacking capabilities >> for fine-grained access and resource control (e.g., bandwidth >> and connections) that are essential for today's advanced P2P >> applications. >> >> The Working Group (WG) will have three primary tasks. First, >> the WG will identify target applications to appropriately >> scope the problem and requirements. P2P applications are the >> primary target, but suitability to other applications with >> similar requirements may be considered depending on >> additional complexity required to support such applications. >> >> Second, the WG will identify the requirements to enable >> target applications to utilize in-network storage. >> Requirements will include the ability for an application to >> (1) store, retrieve, and manage data, >> (2) indicate access control policies for storing and >> retrieving data suitable to an environment with users across >> multiple administrative and security domains (e.g., in a P2P >> environment), and (3) indicate resource control policies for >> storing and retrieving data. >> >> Third, the WG will develop an architecture within which the >> DECADE protocol can be specified. This architecture will >> identify DECADE's relationship to existing IETF protocols and >> where (if any) new protocol is needed or extensions to >> existing protocols need to be made. The architecture will not >> specify a protocol or extension; if development of a new >> protocol is needed, the WG will seek to recharter for this >> purpose or might ask an existing WG to work on such extensions. >> >> The WG will focus on the following work items: >> >> - A "problem statement" document. This document provides a >> description of the problem and common terminology. >> >> - A requirements document. This document lists the >> requirements for the in-network storage service (e.g., >> supported operations) and the protocol to support it. The >> service will include storing, retrieving, and managing data >> as well as specifying both access control and resource >> control policies in the in-network storage pertaining to that data. >> >> - A survey document. This document will survey existing >> related mechanisms and protocols (e.g., HTTP, NFS, and >> WebDAV), and evaluate their applicability to DECADE. >> >> - An architecture document. This document will identify >> DECADE's relationship with existing IETF protocols. Existing >> protocols will be used wherever possible and appropriate to >> support DECADE's requirements. In particular, data storage, >> retrieval, and management may be provided by an existing IETF >> protocols. The WG will not limit itself to a single data >> transport protocol since different protocols may have varying >> implementation costs and performance tradeoffs. >> However, to keep interoperability manageable, a small number >> of specific, targeted, data transport protocols will be >> identified and used. >> >> - An document describing the integration of DECADE with >> existing P2P applications (e.g., integration with BitTorrent). >> >> If new protocol development is deemed necessary, the WG will >> be rechartered. It is not expected that all work items will >> be ready for IESG review by that point, but WG consensus must >> show that documents directing eventual protocol development >> (Requirements and Architecture >> document) have stabilized. This permits adjustments to such >> documents as necessary to maintain consistency as protocol >> development is done. >> >> The following issues are considered out-of-scope for the WG: >> >> - Specification of policies regarding copyright-protected or >> illegal content. >> >> - Locating the "best" in-network storage location from which >> to retrieve content if there are more than one location can >> provide the same content. >> >> - Developing a new protocol for data transport between P2P >> applications and in-network storage. >> >> Goals and Milestones: >> >> Aug 2010 Working Group Last Call for Problem Statement Nov >> 2010 Submit Problem Statement to IESG as Informational Nov >> 2010 Working Group Last Call for Survey document Feb 2011 >> Submit Survey document to IESG as Informational Feb 2011 >> Working Group Last Call for Requirements document Feb 2011 >> Working Group Last Call for Architecture document Mar 2011 >> Identify need for rechartering May 2011 Submit Requirements >> document to IESG as Informational Jul 2011 Submit >> Architecture document to IESG as Informational >> _______________________________________________ >> IETF-Announce mailing list >> IETF-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/ietf-announce > > _______________________________________________ > decade mailing list > decade@ietf.org > https://www.ietf.org/mailman/listinfo/decade > From zhangyunfei@chinamobile.com Tue Apr 27 19:02:12 2010 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 04DEA3A6A38; Tue, 27 Apr 2010 19:02:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -93.586 X-Spam-Level: X-Spam-Status: No, score=-93.586 tagged_above=-999 required=5 tests=[AWL=-0.013, BAYES_50=0.001, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RELAY_IS_221=2.222, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jd3DOY-uR1Lf; Tue, 27 Apr 2010 19:02:10 -0700 (PDT) Received: from cmccmta.chinamobile.com (cmccmta.chinamobile.com [221.130.253.133]) by core3.amsl.com (Postfix) with ESMTP id 7E6993A6782; Tue, 27 Apr 2010 19:02:09 -0700 (PDT) Received: from LENOVO-917FFE55 ([10.2.2.58]) by mail.chinamobile.com (Lotus Domino Release 6.5.5FP1) with SMTP id 2010042810011583-3827 ; Wed, 28 Apr 2010 10:01:15 +0800 Date: Wed, 28 Apr 2010 10:01:48 +0800 From: "zhangyunfei" To: "IESG Secretary" , "ietf-announce@ietf.org" References: <20100427180001.ABBB928C121@core3.amsl.com> Message-ID: <201004281001480004072@chinamobile.com> X-mailer: Foxmail 6, 2, 103, 20 [cn] Mime-Version: 1.0 X-MIMETrack: Itemize by SMTP Server on jtgsml01/servers/cmcc(Release 6.5.5FP1 | April 14, 2006) at 2010-04-28 10:01:15, Serialize by Router on cmccmta/servers/cmcc(Release 6.5.5FP1 | April 14, 2006) at 2010-04-28 10:01:57, Serialize complete at 2010-04-28 10:01:57 Content-Type: multipart/alternative; boundary="=====003_Dragon152735187471_=====" Cc: "decade@ietf.org" , "richard_woundy@cable.comcast.com" Subject: Re: [decade] WG Action: DECoupled Application Data Enroute (decade) X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Apr 2010 02:02:12 -0000 This is a multi-part message in MIME format. --=====003_Dragon152735187471_===== Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="gb2312" Q29uZ3JhdHVsYXRpb25zIQ0KDQpZdW5mZWkNCg0KDQoNCg0Kemhhbmd5dW5mZWkNCjIwMTAtMDQt MjgNCg0KDQoNCreivP7Iy6O6IElFU0cgU2VjcmV0YXJ5DQq3osvNyrG85KO6IDIwMTAtMDQtMjgg MDE6NTk6MjENCsrVvP7Iy6O6IGlldGYtYW5ub3VuY2VAaWV0Zi5vcmcNCrOty82juiBkZWNhZGVA aWV0Zi5vcmc7IHJpY2hhcmRfd291bmR5QGNhYmxlLmNvbWNhc3QuY29tDQrW98zio7ogW2RlY2Fk ZV0gV0cgQWN0aW9uOiBERUNvdXBsZWQgQXBwbGljYXRpb24gRGF0YSBFbnJvdXRlIChkZWNhZGUp DQoNCkEgIG5ldyAgSUVURiAgd29ya2luZyAgZ3JvdXAgIGhhcyAgYmVlbiAgZm9ybWVkICBpbiAg dGhlICBBcHBsaWNhdGlvbnMgIEFyZWEuICAgIEZvcg0KYWRkaXRpb25hbCAgaW5mb3JtYXRpb24s ICBwbGVhc2UgIGNvbnRhY3QgIHRoZSAgQXJlYSAgRGlyZWN0b3JzICBvciAgdGhlICBXRw0KQ2hh aXJzLg0KDQpERUNvdXBsZWQgIEFwcGxpY2F0aW9uICBEYXRhICBFbnJvdXRlICAoZGVjYWRlKQ0K LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCkxhc3Qg IG1vZGlmaWVkOiAgMjAxMC0wNC0yMw0KDQpDaGFpcihzKToNCkhhaWJpbiAgU29uZyAgIDxtZWxv ZHlzb25nQGh1YXdlaS5jb20gPg0KUmljaGFyZCAgV291bmR5ICAgPHJpY2hhcmRfd291bmR5QGNh YmxlLmNvbWNhc3QuY29tID4NCg0KQXBwbGljYXRpb25zICBBcmVhICBEaXJlY3RvcihzKToNCiog IEFsZXhleSAgTWVsbmlrb3YgICA8YWxleGV5Lm1lbG5pa292QGlzb2RlLmNvbSA+DQoqICBQZXRl ciAgU2FpbnQtQW5kcmUgICA8c3RwZXRlckBzdHBldGVyLmltID4NCg0KQXBwbGljYXRpb25zICBB cmVhICBBZHZpc29yOg0KKiAgQWxleGV5ICBNZWxuaWtvdiAgIDxhbGV4ZXkubWVsbmlrb3ZAaXNv ZGUuY29tID4NCg0KTWFpbGluZyAgTGlzdHM6DQogR2VuZXJhbCAgRGlzY3Vzc2lvbjogIGRlY2Fk ZUBpZXRmLm9yZw0KIFRvICBTdWJzY3JpYmU6ICBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL2RlY2FkZQ0KIEFyY2hpdmU6DQpodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJj aGl2ZS93ZWIvZGVjYWRlL2N1cnJlbnQvbWFpbGxpc3QuaHRtbA0KDQpEZXNjcmlwdGlvbiAgb2Yg IFdvcmtpbmcgIEdyb3VwOg0KDQpQZWVyLXRvLVBlZXIgIChQMlApICBhcHBsaWNhdGlvbnMsICBp bmNsdWRpbmcgIGJvdGggIFAyUCAgc3RyZWFtaW5nICBhbmQgIFAyUA0KZmlsZS1zaGFyaW5nICBh cHBsaWNhdGlvbnMsICBtYWtlICB1cCAgYSAgbGFyZ2UgIGZyYWN0aW9uICBvZiAgdHJhZmZpYyAg aW4NCnRoZSAgSW50ZXJuZXQgIHRvZGF5LiAgT25lICB3YXkgIHRvICByZWR1Y2UgIGFjY2VzcyAg bmV0d29yayAgYW5kL29yICBjcm9zcy1kb21haW4NCmJhbmR3aWR0aCAgdXNhZ2UgIGJ5ICBQMlAg IGFwcGxpY2F0aW9ucyAgaXMgIHRvICBpbnRyb2R1Y2UgIHN0b3JhZ2UgIGNhcGFiaWxpdGllcw0K aW4gIHRoZSAgbmV0d29yayAgYmV0d2VlbiAgaG9zdHMgIHJ1bm5pbmcgIFAyUCAgYXBwbGljYXRp b25zLiAgQWxsb3dpbmcgIFAyUA0KYXBwbGljYXRpb25zICB0byAgc3RvcmUgIGFuZCAgcmV0cmll dmUgIGRhdGEgIGZyb20gIGluc2lkZSAgdGhlICBuZXR3b3JrICBjYW4NCnJlZHVjZSAgdHJhZmZp YyAgb24gIHRoZSAgbGFzdC1taWxlICB1cGxpbmssICBhcyAgd2VsbCAgYXMgIGJhY2tib25lICBh bmQNCnRyYW5zaXQgIGxpbmtzLg0KDQpFeGlzdGluZyAgUDJQICBjYWNoZXMgIG9mdGVuICBpbXBs ZW1lbnQgIHRoZSAgc3BlY2lmaWMgIFAyUCAgYXBwbGljYXRpb24NCnByb3RvY29scyAgdG8gIG9w ZXJhdGUgIHRyYW5zcGFyZW50bHkgIG9yICBhY3QgIGFzICBzdXBlciAgcGVlcnMgIHRvICBwcm92 aWRlDQppbi1uZXR3b3JrICBzdG9yYWdlLiAgSG93ZXZlciwgIGl0ICBpcyAgY2hhbGxlbmdpbmcg IGZvciAgUDJQICBjYWNoZSAgdmVuZG9ycyAgdG8NCnN1cHBvcnQgIGEgIHZhcmlldHkgIG9mICBl dm9sdmluZyAgcHJvdG9jb2xzLiAgQWxzbywgIGZvciAgUDJQICBhcHBsaWNhdGlvbnMsDQpjbG9z ZWQgIFAyUCAgY2FjaGluZyAgc3lzdGVtcyAgbGltaXQgIGVmZmVjdGl2ZSAgdXRpbGl6YXRpb24g IG9mICBpbi1uZXR3b3JrDQpzdG9yYWdlLiAgU29tZSAgUDJQICBwcm90b2NvbHMgIG1heSAgYmUg IGVudGlyZWx5ICB1bnN1cHBvcnRlZCAgYnkgIGEgIHBhcnRpY3VsYXINCmNhY2hpbmcgIHN5c3Rl bS4gIEFkZGl0aW9uYWxseSwgIGFwcGxpY2F0aW9ucyAgbWF5ICBiZSAgYmV0dGVyLWVxdWlwcGVk ICB0bw0KZGVjaWRlICBob3cgIGluLW5ldHdvcmsgIHN0b3JhZ2UgIGlzICB1c2VkICB0byAgbWVl dCAgdGhlaXIgIHNwZWNpZmljDQpyZXF1aXJlbWVudHMgIChlLmcuLCAgZGF0YSAgcGxhY2VtZW50 LCAgYWNjZXNzICBjb250cm9sICBhbmQgIHJlc291cmNlDQpjb250cm9sKS4gIE5vdGUgIHRoYXQg IHByb3ZpZGVycyAgb2YgIGluLW5ldHdvcmsgIHN0b3JhZ2UgIG1heSAgaW1wb3NlICB0aGVpcg0K b3duICBhY2Nlc3MgIGNvbnRyb2wgIG9yICByZXNvdXJjZSAgdXNhZ2UgIHBvbGljaWVzLg0KDQpC b3RoICBvZiAgdGhlc2UgIGNoYWxsZW5nZXMgIGNhbiAgYmUgIGVmZmVjdGl2ZWx5ICBhZGRyZXNz ZWQgIGJ5ICB1c2luZyAgb3BlbiwNCnN0YW5kYXJkICBwcm90b2NvbHMgIHRvICBhY2Nlc3MgIGlu LW5ldHdvcmsgIHN0b3JhZ2UuICBQMlAgIGFwcGxpY2F0aW9ucyAgY2FuDQpzdG9yZSAgYW5kICBy ZXRyaWV2ZSAgY29udGVudCAgaW4gIHRoZSAgaW4tbmV0d29yayAgc3RvcmFnZSwgIGFzICB3ZWxs ICBhcyAgY29udHJvbA0KcmVzb3VyY2VzICAoZS5nLiwgIGJhbmR3aWR0aCwgIGNvbm5lY3Rpb25z KSAgY29uc3VtZWQgIGJ5ICBwZWVycyAgaW4gIGEgIFAyUA0KYXBwbGljYXRpb24uICBBcyAgYSAg c2ltcGxlICBleGFtcGxlLCAgYSAgcGVlciAgY2FuICBjaG9vc2UgIHRvICBzdG9yZSAgY29udGVu dCAgaW4NCnRoZSAgaW4tbmV0d29yayAgc3RvcmFnZSwgIGFuZCAgZGlyZWN0ICBvdGhlciAgcGVl cnMgIHRvICByZXRyaWV2ZSAgZnJvbSAgdGhhdA0KbG9jYXRpb24sICByZWR1Y2luZyAgbGFzdC1t aWxlICBsaW5rICB1c2FnZS4gIEZ1cnRoZXJtb3JlLCAgc2luY2UgIGEgIFAyUA0KY2xpZW50ICBt YXkgIGhhdmUgIG11bHRpcGxlICBwZWVycywgIGl0ICBjYW4gIGNvbnRyb2wgIHJlc291cmNlcyAg dXNlZCAgYnkgIGVhY2gNCnBlZXIgIHRvICBzdG9yZSAgYW5kICByZXRyaWV2ZSAgY29udGVudC4g IFRob3VnaCAgdGhlcmUgIGFyZSAgZXhpc3RpbmcgIGRhdGENCmFjY2VzcyAgcHJvdG9jb2xzICAo ZS5nLiwgIEhUVFAsICBORlMsICBXZWJEQVYpLCAgdGhleSAgbWlnaHQgIGJlICBsYWNraW5nDQpj YXBhYmlsaXRpZXMgIGZvciAgZmluZS1ncmFpbmVkICBhY2Nlc3MgIGFuZCAgcmVzb3VyY2UgIGNv bnRyb2wgIChlLmcuLA0KYmFuZHdpZHRoICBhbmQgIGNvbm5lY3Rpb25zKSAgdGhhdCAgYXJlICBl c3NlbnRpYWwgIGZvciAgdG9kYXkncyAgYWR2YW5jZWQgIFAyUA0KYXBwbGljYXRpb25zLg0KDQpU aGUgIFdvcmtpbmcgIEdyb3VwICAoV0cpICB3aWxsICBoYXZlICB0aHJlZSAgcHJpbWFyeSAgdGFz a3MuICBGaXJzdCwgIHRoZSAgV0cgIHdpbGwNCmlkZW50aWZ5ICB0YXJnZXQgIGFwcGxpY2F0aW9u cyAgdG8gIGFwcHJvcHJpYXRlbHkgIHNjb3BlICB0aGUgIHByb2JsZW0gIGFuZA0KcmVxdWlyZW1l bnRzLiAgUDJQICBhcHBsaWNhdGlvbnMgIGFyZSAgdGhlICBwcmltYXJ5ICB0YXJnZXQsICBidXQg IHN1aXRhYmlsaXR5DQp0byAgb3RoZXIgIGFwcGxpY2F0aW9ucyAgd2l0aCAgc2ltaWxhciAgcmVx dWlyZW1lbnRzICBtYXkgIGJlICBjb25zaWRlcmVkDQpkZXBlbmRpbmcgIG9uICBhZGRpdGlvbmFs ICBjb21wbGV4aXR5ICByZXF1aXJlZCAgdG8gIHN1cHBvcnQgIHN1Y2gNCmFwcGxpY2F0aW9ucy4N Cg0KU2Vjb25kLCAgdGhlICBXRyAgd2lsbCAgaWRlbnRpZnkgIHRoZSAgcmVxdWlyZW1lbnRzICB0 byAgZW5hYmxlICB0YXJnZXQNCmFwcGxpY2F0aW9ucyAgdG8gIHV0aWxpemUgIGluLW5ldHdvcmsg IHN0b3JhZ2UuICBSZXF1aXJlbWVudHMgIHdpbGwgIGluY2x1ZGUNCnRoZSAgYWJpbGl0eSAgZm9y ICBhbiAgYXBwbGljYXRpb24gIHRvICAoMSkgIHN0b3JlLCAgcmV0cmlldmUsICBhbmQgIG1hbmFn ZSAgZGF0YSwNCigyKSAgaW5kaWNhdGUgIGFjY2VzcyAgY29udHJvbCAgcG9saWNpZXMgIGZvciAg c3RvcmluZyAgYW5kICByZXRyaWV2aW5nICBkYXRhDQpzdWl0YWJsZSAgdG8gIGFuICBlbnZpcm9u bWVudCAgd2l0aCAgdXNlcnMgIGFjcm9zcyAgbXVsdGlwbGUgIGFkbWluaXN0cmF0aXZlICBhbmQN CnNlY3VyaXR5ICBkb21haW5zICAoZS5nLiwgIGluICBhICBQMlAgIGVudmlyb25tZW50KSwgIGFu ZCAgKDMpICBpbmRpY2F0ZSAgcmVzb3VyY2UNCmNvbnRyb2wgIHBvbGljaWVzICBmb3IgIHN0b3Jp bmcgIGFuZCAgcmV0cmlldmluZyAgZGF0YS4NCg0KVGhpcmQsICB0aGUgIFdHICB3aWxsICBkZXZl bG9wICBhbiAgYXJjaGl0ZWN0dXJlICB3aXRoaW4gIHdoaWNoICB0aGUgIERFQ0FERQ0KcHJvdG9j b2wgIGNhbiAgYmUgIHNwZWNpZmllZC4gIFRoaXMgIGFyY2hpdGVjdHVyZSAgd2lsbCAgaWRlbnRp ZnkgIERFQ0FERSdzDQpyZWxhdGlvbnNoaXAgIHRvICBleGlzdGluZyAgSUVURiAgcHJvdG9jb2xz ICBhbmQgIHdoZXJlICAoaWYgIGFueSkgIG5ldyAgcHJvdG9jb2wNCmlzICBuZWVkZWQgIG9yICBl eHRlbnNpb25zICB0byAgZXhpc3RpbmcgIHByb3RvY29scyAgbmVlZCAgdG8gIGJlICBtYWRlLiAg VGhlDQphcmNoaXRlY3R1cmUgIHdpbGwgIG5vdCAgc3BlY2lmeSAgYSAgcHJvdG9jb2wgIG9yICBl eHRlbnNpb247ICBpZiAgZGV2ZWxvcG1lbnQgIG9mDQphICBuZXcgIHByb3RvY29sICBpcyAgbmVl ZGVkLCAgdGhlICBXRyAgd2lsbCAgc2VlayAgdG8gIHJlY2hhcnRlciAgZm9yICB0aGlzICBwdXJw b3NlDQpvciAgbWlnaHQgIGFzayAgYW4gIGV4aXN0aW5nICBXRyAgdG8gIHdvcmsgIG9uICBzdWNo ICBleHRlbnNpb25zLg0KDQpUaGUgIFdHICB3aWxsICBmb2N1cyAgb24gIHRoZSAgZm9sbG93aW5n ICB3b3JrICBpdGVtczoNCg0KLSAgQSAgInByb2JsZW0gIHN0YXRlbWVudCIgIGRvY3VtZW50LiAg VGhpcyAgZG9jdW1lbnQgIHByb3ZpZGVzICBhICBkZXNjcmlwdGlvbg0Kb2YgIHRoZSAgcHJvYmxl bSAgYW5kICBjb21tb24gIHRlcm1pbm9sb2d5Lg0KDQotICBBICByZXF1aXJlbWVudHMgIGRvY3Vt ZW50LiAgVGhpcyAgZG9jdW1lbnQgIGxpc3RzICB0aGUgIHJlcXVpcmVtZW50cyAgZm9yICB0aGUN CmluLW5ldHdvcmsgIHN0b3JhZ2UgIHNlcnZpY2UgIChlLmcuLCAgc3VwcG9ydGVkICBvcGVyYXRp b25zKSAgYW5kICB0aGUNCnByb3RvY29sICB0byAgc3VwcG9ydCAgaXQuICBUaGUgIHNlcnZpY2Ug IHdpbGwgIGluY2x1ZGUgIHN0b3JpbmcsICByZXRyaWV2aW5nLA0KYW5kICBtYW5hZ2luZyAgZGF0 YSAgYXMgIHdlbGwgIGFzICBzcGVjaWZ5aW5nICBib3RoICBhY2Nlc3MgIGNvbnRyb2wgIGFuZA0K cmVzb3VyY2UgIGNvbnRyb2wgIHBvbGljaWVzICBpbiAgdGhlICBpbi1uZXR3b3JrICBzdG9yYWdl ICBwZXJ0YWluaW5nICB0byAgdGhhdA0KZGF0YS4NCg0KLSAgQSAgc3VydmV5ICBkb2N1bWVudC4g IFRoaXMgIGRvY3VtZW50ICB3aWxsICBzdXJ2ZXkgIGV4aXN0aW5nICByZWxhdGVkDQptZWNoYW5p c21zICBhbmQgIHByb3RvY29scyAgKGUuZy4sICBIVFRQLCAgTkZTLCAgYW5kICBXZWJEQVYpLCAg YW5kICBldmFsdWF0ZQ0KdGhlaXIgIGFwcGxpY2FiaWxpdHkgIHRvICBERUNBREUuDQoNCi0gIEFu ICBhcmNoaXRlY3R1cmUgIGRvY3VtZW50LiAgVGhpcyAgZG9jdW1lbnQgIHdpbGwgIGlkZW50aWZ5 ICBERUNBREUncw0KcmVsYXRpb25zaGlwICB3aXRoICBleGlzdGluZyAgSUVURiAgcHJvdG9jb2xz LiAgRXhpc3RpbmcgIHByb3RvY29scyAgd2lsbCAgYmUNCnVzZWQgIHdoZXJldmVyICBwb3NzaWJs ZSAgYW5kICBhcHByb3ByaWF0ZSAgdG8gIHN1cHBvcnQgIERFQ0FERSdzDQpyZXF1aXJlbWVudHMu ICBJbiAgcGFydGljdWxhciwgIGRhdGEgIHN0b3JhZ2UsICByZXRyaWV2YWwsICBhbmQgIG1hbmFn ZW1lbnQNCm1heSAgYmUgIHByb3ZpZGVkICBieSAgYW4gIGV4aXN0aW5nICBJRVRGICBwcm90b2Nv bHMuICBUaGUgIFdHICB3aWxsICBub3QgIGxpbWl0DQppdHNlbGYgIHRvICBhICBzaW5nbGUgIGRh dGEgIHRyYW5zcG9ydCAgcHJvdG9jb2wgIHNpbmNlICBkaWZmZXJlbnQgIHByb3RvY29scw0KbWF5 ICBoYXZlICB2YXJ5aW5nICBpbXBsZW1lbnRhdGlvbiAgY29zdHMgIGFuZCAgcGVyZm9ybWFuY2Ug IHRyYWRlb2Zmcy4NCkhvd2V2ZXIsICB0byAga2VlcCAgaW50ZXJvcGVyYWJpbGl0eSAgbWFuYWdl YWJsZSwgIGEgIHNtYWxsICBudW1iZXIgIG9mDQpzcGVjaWZpYywgIHRhcmdldGVkLCAgZGF0YSAg dHJhbnNwb3J0ICBwcm90b2NvbHMgIHdpbGwgIGJlICBpZGVudGlmaWVkICBhbmQNCnVzZWQuDQoN Ci0gIEFuICBkb2N1bWVudCAgZGVzY3JpYmluZyAgdGhlICBpbnRlZ3JhdGlvbiAgb2YgIERFQ0FE RSAgd2l0aCAgZXhpc3RpbmcgIFAyUA0KYXBwbGljYXRpb25zICAoZS5nLiwgIGludGVncmF0aW9u ICB3aXRoICBCaXRUb3JyZW50KS4NCg0KSWYgIG5ldyAgcHJvdG9jb2wgIGRldmVsb3BtZW50ICBp cyAgZGVlbWVkICBuZWNlc3NhcnksICB0aGUgIFdHICB3aWxsICBiZQ0KcmVjaGFydGVyZWQuICBJ dCAgaXMgIG5vdCAgZXhwZWN0ZWQgIHRoYXQgIGFsbCAgd29yayAgaXRlbXMgIHdpbGwgIGJlICBy ZWFkeSAgZm9yDQpJRVNHICByZXZpZXcgIGJ5ICB0aGF0ICBwb2ludCwgIGJ1dCAgV0cgIGNvbnNl bnN1cyAgbXVzdCAgc2hvdyAgdGhhdCAgZG9jdW1lbnRzDQpkaXJlY3RpbmcgIGV2ZW50dWFsICBw cm90b2NvbCAgZGV2ZWxvcG1lbnQgIChSZXF1aXJlbWVudHMgIGFuZCAgQXJjaGl0ZWN0dXJlDQpk b2N1bWVudCkgIGhhdmUgIHN0YWJpbGl6ZWQuICBUaGlzICBwZXJtaXRzICBhZGp1c3RtZW50cyAg dG8gIHN1Y2ggIGRvY3VtZW50cyAgYXMNCm5lY2Vzc2FyeSAgdG8gIG1haW50YWluICBjb25zaXN0 ZW5jeSAgYXMgIHByb3RvY29sICBkZXZlbG9wbWVudCAgaXMgIGRvbmUuDQoNClRoZSAgZm9sbG93 aW5nICBpc3N1ZXMgIGFyZSAgY29uc2lkZXJlZCAgb3V0LW9mLXNjb3BlICBmb3IgIHRoZSAgV0c6 DQoNCi0gIFNwZWNpZmljYXRpb24gIG9mICBwb2xpY2llcyAgcmVnYXJkaW5nICBjb3B5cmlnaHQt cHJvdGVjdGVkICBvciAgaWxsZWdhbA0KY29udGVudC4NCg0KLSAgTG9jYXRpbmcgIHRoZSAgImJl c3QiICBpbi1uZXR3b3JrICBzdG9yYWdlICBsb2NhdGlvbiAgZnJvbSAgd2hpY2ggIHRvICByZXRy aWV2ZQ0KY29udGVudCAgaWYgIHRoZXJlICBhcmUgIG1vcmUgIHRoYW4gIG9uZSAgbG9jYXRpb24g IGNhbiAgcHJvdmlkZSAgdGhlICBzYW1lDQpjb250ZW50Lg0KDQotICBEZXZlbG9waW5nICBhICBu ZXcgIHByb3RvY29sICBmb3IgIGRhdGEgIHRyYW5zcG9ydCAgYmV0d2VlbiAgUDJQICBhcHBsaWNh dGlvbnMNCmFuZCAgaW4tbmV0d29yayAgc3RvcmFnZS4NCg0KR29hbHMgIGFuZCAgTWlsZXN0b25l czoNCg0KQXVnICAyMDEwICBXb3JraW5nICBHcm91cCAgTGFzdCAgQ2FsbCAgZm9yICBQcm9ibGVt ICBTdGF0ZW1lbnQNCk5vdiAgMjAxMCAgU3VibWl0ICBQcm9ibGVtICBTdGF0ZW1lbnQgIHRvICBJ RVNHICBhcyAgSW5mb3JtYXRpb25hbA0KTm92ICAyMDEwICBXb3JraW5nICBHcm91cCAgTGFzdCAg Q2FsbCAgZm9yICBTdXJ2ZXkgIGRvY3VtZW50DQpGZWIgIDIwMTEgIFN1Ym1pdCAgU3VydmV5ICBk b2N1bWVudCAgdG8gIElFU0cgIGFzICBJbmZvcm1hdGlvbmFsDQpGZWIgIDIwMTEgIFdvcmtpbmcg IEdyb3VwICBMYXN0ICBDYWxsICBmb3IgIFJlcXVpcmVtZW50cyAgZG9jdW1lbnQNCkZlYiAgMjAx MSAgV29ya2luZyAgR3JvdXAgIExhc3QgIENhbGwgIGZvciAgQXJjaGl0ZWN0dXJlICBkb2N1bWVu dA0KTWFyICAyMDExICBJZGVudGlmeSAgbmVlZCAgZm9yICByZWNoYXJ0ZXJpbmcNCk1heSAgMjAx MSAgU3VibWl0ICBSZXF1aXJlbWVudHMgIGRvY3VtZW50ICB0byAgSUVTRyAgYXMgIEluZm9ybWF0 aW9uYWwNCkp1bCAgMjAxMSAgU3VibWl0ICBBcmNoaXRlY3R1cmUgIGRvY3VtZW50ICB0byAgSUVT RyAgYXMgIEluZm9ybWF0aW9uYWwNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQpkZWNhZGUgIG1haWxpbmcgIGxpc3QNCmRlY2FkZUBpZXRmLm9yZw0KaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kZWNhZGUNCg== --=====003_Dragon152735187471_===== Content-Transfer-Encoding: base64 Content-Type: text/html; charset="gb2312" PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWdiMjMxMiI+DQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNi4w MC4yOTAwLjM0OTIiIG5hbWU9R0VORVJBVE9SPg0KPFNUWUxFPg0KPCEtLQ0KIC8qIEZvbnQgRGVm aW5pdGlvbnMgKi8NCiBAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OsvOzOU7DQoJcGFub3NlLTE6 MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlZlcmRhbmE7 DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZh bWlseToiXEDLzszlIjsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30NCiAvKiBTdHls ZSBEZWZpbml0aW9ucyAqLw0KIHAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3Jt YWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJdGV4dC1hbGlnbjpq dXN0aWZ5Ow0KCXRleHQtanVzdGlmeTppbnRlci1pZGVvZ3JhcGg7DQoJZm9udC1zaXplOjEwLjVw dDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQphOmxpbmssIHNwYW4uTXNvSHlw ZXJsaW5rDQoJe2NvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZp c2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7Y29sb3I6cHVycGxlOw0KCXRleHQt ZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5 cGU6cGVyc29uYWwtY29tcG9zZTsNCglmb250LWZhbWlseTpWZXJkYW5hOw0KCWNvbG9yOndpbmRv d3RleHQ7DQoJZm9udC13ZWlnaHQ6bm9ybWFsOw0KCWZvbnQtc3R5bGU6bm9ybWFsOw0KCXRleHQt ZGVjb3JhdGlvbjpub25lIG5vbmU7fQ0KIC8qIFBhZ2UgRGVmaW5pdGlvbnMgKi8NCiBAcGFnZSBT ZWN0aW9uMQ0KCXtzaXplOjU5NS4zcHQgODQxLjlwdDsNCgltYXJnaW46NzIuMHB0IDkwLjBwdCA3 Mi4wcHQgOTAuMHB0Ow0KCWxheW91dC1ncmlkOjE1LjZwdDt9DQpkaXYuU2VjdGlvbjENCgl7cGFn ZTpTZWN0aW9uMTt9DQotLT4NCjwvU1RZTEU+DQo8L0hFQUQ+DQo8Qk9EWT4NCjxESVY+PEZPTlQg ZmFjZT1WZXJkYW5hIGNvbG9yPSMwMDAwZmYgc2l6ZT0yPkNvbmdyYXR1bGF0aW9ucyE8L0ZPTlQ+ PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9VmVyZGFuYSBjb2xvcj0jMDAwMGZmIHNpemU9Mj48L0ZP TlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9VmVyZGFuYSBjb2xvcj0jMDAwMGZmIHNp emU9Mj5ZdW5mZWk8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9VmVyZGFuYSBzaXplPTI+ PC9GT05UPiZuYnNwOzwvRElWPg0KPERJViBhbGlnbj1sZWZ0Pg0KPERJViBhbGlnbj1sZWZ0PjxG T05UIGZhY2U9VmVyZGFuYSBzaXplPTI+DQo8SFIgc3R5bGU9IldJRFRIOiAxMjJweDsgSEVJR0hU OiAycHgiIFNJWkU9Mj4NCjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgY29sb3I9I2MwYzBjMD48 Rk9OVCBmYWNlPVZlcmRhbmEgc2l6ZT0yPnpoYW5neXVuZmVpPC9GT05UPjwvRElWPg0KPERJVj48 Rk9OVCBmYWNlPVZlcmRhbmEgc2l6ZT0yPjIwMTAtMDQtMjg8L0ZPTlQ+PC9GT05UPjwvRElWPjwv RElWPg0KPERJVj48Rk9OVCBmYWNlPVZlcmRhbmEgc2l6ZT0yPg0KPEhSPg0KPC9GT05UPjwvRElW Pg0KPERJVj48Rk9OVCBmYWNlPVZlcmRhbmE+PEZPTlQgc2l6ZT0yPjxTVFJPTkc+t6K8/sjLo7o8 L1NUUk9ORz4gSUVTRyANClNlY3JldGFyeTwvRk9OVD48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05U IGZhY2U9VmVyZGFuYT48Rk9OVCBzaXplPTI+PFNUUk9ORz63osvNyrG85KO6PC9TVFJPTkc+IA0K MjAxMC0wNC0yOCZuYnNwOzAxOjU5OjIxPC9GT05UPjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQg ZmFjZT1WZXJkYW5hPjxGT05UIHNpemU9Mj48U1RST05HPsrVvP7Iy6O6PC9TVFJPTkc+IA0KaWV0 Zi1hbm5vdW5jZUBpZXRmLm9yZzwvRk9OVD48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9 VmVyZGFuYT48Rk9OVCBzaXplPTI+PFNUUk9ORz6zrcvNo7o8L1NUUk9ORz4gZGVjYWRlQGlldGYu b3JnOyANCnJpY2hhcmRfd291bmR5QGNhYmxlLmNvbWNhc3QuY29tPC9GT05UPjwvRk9OVD48L0RJ Vj4NCjxESVY+PEZPTlQgZmFjZT1WZXJkYW5hPjxGT05UIHNpemU9Mj48U1RST05HPtb3zOKjujwv U1RST05HPiBbZGVjYWRlXSBXRyBBY3Rpb246IA0KREVDb3VwbGVkIEFwcGxpY2F0aW9uIERhdGEg RW5yb3V0ZSAoZGVjYWRlKTwvRk9OVD48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9VmVy ZGFuYSBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPVZlcmRhbmEg c2l6ZT0yPg0KPERJVj5BICZuYnNwO25ldyAmbmJzcDtJRVRGICZuYnNwO3dvcmtpbmcgJm5ic3A7 Z3JvdXAgJm5ic3A7aGFzICZuYnNwO2JlZW4gDQombmJzcDtmb3JtZWQgJm5ic3A7aW4gJm5ic3A7 dGhlICZuYnNwO0FwcGxpY2F0aW9ucyAmbmJzcDtBcmVhLiAmbmJzcDsgDQombmJzcDtGb3I8L0RJ Vj4NCjxESVY+YWRkaXRpb25hbCAmbmJzcDtpbmZvcm1hdGlvbiwgJm5ic3A7cGxlYXNlICZuYnNw O2NvbnRhY3QgJm5ic3A7dGhlIA0KJm5ic3A7QXJlYSAmbmJzcDtEaXJlY3RvcnMgJm5ic3A7b3Ig Jm5ic3A7dGhlICZuYnNwO1dHPC9ESVY+DQo8RElWPkNoYWlycy48L0RJVj4NCjxESVY+Jm5ic3A7 PC9ESVY+DQo8RElWPkRFQ291cGxlZCAmbmJzcDtBcHBsaWNhdGlvbiAmbmJzcDtEYXRhICZuYnNw O0Vucm91dGUgJm5ic3A7KGRlY2FkZSk8L0RJVj4NCjxESVY+LS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08L0RJVj4NCjxESVY+TGFzdCAmbmJzcDttb2Rp ZmllZDogJm5ic3A7MjAxMC0wNC0yMzwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+Q2hh aXIocyk6PC9ESVY+DQo8RElWPkhhaWJpbiAmbmJzcDtTb25nICZuYnNwOyAmbHQ7bWVsb2R5c29u Z0BodWF3ZWkuY29tICZndDs8L0RJVj4NCjxESVY+UmljaGFyZCAmbmJzcDtXb3VuZHkgJm5ic3A7 ICZsdDtyaWNoYXJkX3dvdW5keUBjYWJsZS5jb21jYXN0LmNvbSAmZ3Q7PC9ESVY+DQo8RElWPiZu YnNwOzwvRElWPg0KPERJVj5BcHBsaWNhdGlvbnMgJm5ic3A7QXJlYSAmbmJzcDtEaXJlY3Rvcihz KTo8L0RJVj4NCjxESVY+KiAmbmJzcDtBbGV4ZXkgJm5ic3A7TWVsbmlrb3YgJm5ic3A7ICZsdDth bGV4ZXkubWVsbmlrb3ZAaXNvZGUuY29tIA0KJmd0OzwvRElWPg0KPERJVj4qICZuYnNwO1BldGVy ICZuYnNwO1NhaW50LUFuZHJlICZuYnNwOyAmbHQ7c3RwZXRlckBzdHBldGVyLmltICZndDs8L0RJ Vj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPkFwcGxpY2F0aW9ucyAmbmJzcDtBcmVhICZuYnNw O0Fkdmlzb3I6PC9ESVY+DQo8RElWPiogJm5ic3A7QWxleGV5ICZuYnNwO01lbG5pa292ICZuYnNw OyAmbHQ7YWxleGV5Lm1lbG5pa292QGlzb2RlLmNvbSANCiZndDs8L0RJVj4NCjxESVY+Jm5ic3A7 PC9ESVY+DQo8RElWPk1haWxpbmcgJm5ic3A7TGlzdHM6PC9ESVY+DQo8RElWPiZuYnNwO0dlbmVy YWwgJm5ic3A7RGlzY3Vzc2lvbjogJm5ic3A7ZGVjYWRlQGlldGYub3JnPC9ESVY+DQo8RElWPiZu YnNwO1RvICZuYnNwO1N1YnNjcmliZTogDQombmJzcDtodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL2RlY2FkZTwvRElWPg0KPERJVj4mbmJzcDtBcmNoaXZlOjwvRElWPg0KPERJ Vj48QSANCmhyZWY9Imh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9kZWNhZGUv Y3VycmVudC9tYWlsbGlzdC5odG1sIj5odHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93 ZWIvZGVjYWRlL2N1cnJlbnQvbWFpbGxpc3QuaHRtbDwvQT48L0RJVj4NCjxESVY+Jm5ic3A7PC9E SVY+DQo8RElWPkRlc2NyaXB0aW9uICZuYnNwO29mICZuYnNwO1dvcmtpbmcgJm5ic3A7R3JvdXA6 PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj5QZWVyLXRvLVBlZXIgJm5ic3A7KFAyUCkg Jm5ic3A7YXBwbGljYXRpb25zLCAmbmJzcDtpbmNsdWRpbmcgJm5ic3A7Ym90aCANCiZuYnNwO1Ay UCAmbmJzcDtzdHJlYW1pbmcgJm5ic3A7YW5kICZuYnNwO1AyUDwvRElWPg0KPERJVj5maWxlLXNo YXJpbmcgJm5ic3A7YXBwbGljYXRpb25zLCAmbmJzcDttYWtlICZuYnNwO3VwICZuYnNwO2EgJm5i c3A7bGFyZ2UgDQombmJzcDtmcmFjdGlvbiAmbmJzcDtvZiAmbmJzcDt0cmFmZmljICZuYnNwO2lu PC9ESVY+DQo8RElWPnRoZSAmbmJzcDtJbnRlcm5ldCAmbmJzcDt0b2RheS4gJm5ic3A7T25lICZu YnNwO3dheSAmbmJzcDt0byAmbmJzcDtyZWR1Y2UgDQombmJzcDthY2Nlc3MgJm5ic3A7bmV0d29y ayAmbmJzcDthbmQvb3IgJm5ic3A7Y3Jvc3MtZG9tYWluPC9ESVY+DQo8RElWPmJhbmR3aWR0aCAm bmJzcDt1c2FnZSAmbmJzcDtieSAmbmJzcDtQMlAgJm5ic3A7YXBwbGljYXRpb25zICZuYnNwO2lz IA0KJm5ic3A7dG8gJm5ic3A7aW50cm9kdWNlICZuYnNwO3N0b3JhZ2UgJm5ic3A7Y2FwYWJpbGl0 aWVzPC9ESVY+DQo8RElWPmluICZuYnNwO3RoZSAmbmJzcDtuZXR3b3JrICZuYnNwO2JldHdlZW4g Jm5ic3A7aG9zdHMgJm5ic3A7cnVubmluZyANCiZuYnNwO1AyUCAmbmJzcDthcHBsaWNhdGlvbnMu ICZuYnNwO0FsbG93aW5nICZuYnNwO1AyUDwvRElWPg0KPERJVj5hcHBsaWNhdGlvbnMgJm5ic3A7 dG8gJm5ic3A7c3RvcmUgJm5ic3A7YW5kICZuYnNwO3JldHJpZXZlICZuYnNwO2RhdGEgDQombmJz cDtmcm9tICZuYnNwO2luc2lkZSAmbmJzcDt0aGUgJm5ic3A7bmV0d29yayAmbmJzcDtjYW48L0RJ Vj4NCjxESVY+cmVkdWNlICZuYnNwO3RyYWZmaWMgJm5ic3A7b24gJm5ic3A7dGhlICZuYnNwO2xh c3QtbWlsZSAmbmJzcDt1cGxpbmssIA0KJm5ic3A7YXMgJm5ic3A7d2VsbCAmbmJzcDthcyAmbmJz cDtiYWNrYm9uZSAmbmJzcDthbmQ8L0RJVj4NCjxESVY+dHJhbnNpdCAmbmJzcDtsaW5rcy48L0RJ Vj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPkV4aXN0aW5nICZuYnNwO1AyUCAmbmJzcDtjYWNo ZXMgJm5ic3A7b2Z0ZW4gJm5ic3A7aW1wbGVtZW50ICZuYnNwO3RoZSANCiZuYnNwO3NwZWNpZmlj ICZuYnNwO1AyUCAmbmJzcDthcHBsaWNhdGlvbjwvRElWPg0KPERJVj5wcm90b2NvbHMgJm5ic3A7 dG8gJm5ic3A7b3BlcmF0ZSAmbmJzcDt0cmFuc3BhcmVudGx5ICZuYnNwO29yICZuYnNwO2FjdCAN CiZuYnNwO2FzICZuYnNwO3N1cGVyICZuYnNwO3BlZXJzICZuYnNwO3RvICZuYnNwO3Byb3ZpZGU8 L0RJVj4NCjxESVY+aW4tbmV0d29yayAmbmJzcDtzdG9yYWdlLiAmbmJzcDtIb3dldmVyLCAmbmJz cDtpdCAmbmJzcDtpcyANCiZuYnNwO2NoYWxsZW5naW5nICZuYnNwO2ZvciAmbmJzcDtQMlAgJm5i c3A7Y2FjaGUgJm5ic3A7dmVuZG9ycyAmbmJzcDt0bzwvRElWPg0KPERJVj5zdXBwb3J0ICZuYnNw O2EgJm5ic3A7dmFyaWV0eSAmbmJzcDtvZiAmbmJzcDtldm9sdmluZyAmbmJzcDtwcm90b2NvbHMu IA0KJm5ic3A7QWxzbywgJm5ic3A7Zm9yICZuYnNwO1AyUCAmbmJzcDthcHBsaWNhdGlvbnMsPC9E SVY+DQo8RElWPmNsb3NlZCAmbmJzcDtQMlAgJm5ic3A7Y2FjaGluZyAmbmJzcDtzeXN0ZW1zICZu YnNwO2xpbWl0ICZuYnNwO2VmZmVjdGl2ZSANCiZuYnNwO3V0aWxpemF0aW9uICZuYnNwO29mICZu YnNwO2luLW5ldHdvcms8L0RJVj4NCjxESVY+c3RvcmFnZS4gJm5ic3A7U29tZSAmbmJzcDtQMlAg Jm5ic3A7cHJvdG9jb2xzICZuYnNwO21heSAmbmJzcDtiZSANCiZuYnNwO2VudGlyZWx5ICZuYnNw O3Vuc3VwcG9ydGVkICZuYnNwO2J5ICZuYnNwO2EgJm5ic3A7cGFydGljdWxhcjwvRElWPg0KPERJ Vj5jYWNoaW5nICZuYnNwO3N5c3RlbS4gJm5ic3A7QWRkaXRpb25hbGx5LCAmbmJzcDthcHBsaWNh dGlvbnMgJm5ic3A7bWF5IA0KJm5ic3A7YmUgJm5ic3A7YmV0dGVyLWVxdWlwcGVkICZuYnNwO3Rv PC9ESVY+DQo8RElWPmRlY2lkZSAmbmJzcDtob3cgJm5ic3A7aW4tbmV0d29yayAmbmJzcDtzdG9y YWdlICZuYnNwO2lzICZuYnNwO3VzZWQgDQombmJzcDt0byAmbmJzcDttZWV0ICZuYnNwO3RoZWly ICZuYnNwO3NwZWNpZmljPC9ESVY+DQo8RElWPnJlcXVpcmVtZW50cyAmbmJzcDsoZS5nLiwgJm5i c3A7ZGF0YSAmbmJzcDtwbGFjZW1lbnQsICZuYnNwO2FjY2VzcyANCiZuYnNwO2NvbnRyb2wgJm5i c3A7YW5kICZuYnNwO3Jlc291cmNlPC9ESVY+DQo8RElWPmNvbnRyb2wpLiAmbmJzcDtOb3RlICZu YnNwO3RoYXQgJm5ic3A7cHJvdmlkZXJzICZuYnNwO29mICZuYnNwO2luLW5ldHdvcmsgDQombmJz cDtzdG9yYWdlICZuYnNwO21heSAmbmJzcDtpbXBvc2UgJm5ic3A7dGhlaXI8L0RJVj4NCjxESVY+ b3duICZuYnNwO2FjY2VzcyAmbmJzcDtjb250cm9sICZuYnNwO29yICZuYnNwO3Jlc291cmNlICZu YnNwO3VzYWdlIA0KJm5ic3A7cG9saWNpZXMuPC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJ Vj5Cb3RoICZuYnNwO29mICZuYnNwO3RoZXNlICZuYnNwO2NoYWxsZW5nZXMgJm5ic3A7Y2FuICZu YnNwO2JlIA0KJm5ic3A7ZWZmZWN0aXZlbHkgJm5ic3A7YWRkcmVzc2VkICZuYnNwO2J5ICZuYnNw O3VzaW5nICZuYnNwO29wZW4sPC9ESVY+DQo8RElWPnN0YW5kYXJkICZuYnNwO3Byb3RvY29scyAm bmJzcDt0byAmbmJzcDthY2Nlc3MgJm5ic3A7aW4tbmV0d29yayANCiZuYnNwO3N0b3JhZ2UuICZu YnNwO1AyUCAmbmJzcDthcHBsaWNhdGlvbnMgJm5ic3A7Y2FuPC9ESVY+DQo8RElWPnN0b3JlICZu YnNwO2FuZCAmbmJzcDtyZXRyaWV2ZSAmbmJzcDtjb250ZW50ICZuYnNwO2luICZuYnNwO3RoZSAN CiZuYnNwO2luLW5ldHdvcmsgJm5ic3A7c3RvcmFnZSwgJm5ic3A7YXMgJm5ic3A7d2VsbCAmbmJz cDthcyAmbmJzcDtjb250cm9sPC9ESVY+DQo8RElWPnJlc291cmNlcyAmbmJzcDsoZS5nLiwgJm5i c3A7YmFuZHdpZHRoLCAmbmJzcDtjb25uZWN0aW9ucykgJm5ic3A7Y29uc3VtZWQgDQombmJzcDti eSAmbmJzcDtwZWVycyAmbmJzcDtpbiAmbmJzcDthICZuYnNwO1AyUDwvRElWPg0KPERJVj5hcHBs aWNhdGlvbi4gJm5ic3A7QXMgJm5ic3A7YSAmbmJzcDtzaW1wbGUgJm5ic3A7ZXhhbXBsZSwgJm5i c3A7YSANCiZuYnNwO3BlZXIgJm5ic3A7Y2FuICZuYnNwO2Nob29zZSAmbmJzcDt0byAmbmJzcDtz dG9yZSAmbmJzcDtjb250ZW50IA0KJm5ic3A7aW48L0RJVj4NCjxESVY+dGhlICZuYnNwO2luLW5l dHdvcmsgJm5ic3A7c3RvcmFnZSwgJm5ic3A7YW5kICZuYnNwO2RpcmVjdCAmbmJzcDtvdGhlciAN CiZuYnNwO3BlZXJzICZuYnNwO3RvICZuYnNwO3JldHJpZXZlICZuYnNwO2Zyb20gJm5ic3A7dGhh dDwvRElWPg0KPERJVj5sb2NhdGlvbiwgJm5ic3A7cmVkdWNpbmcgJm5ic3A7bGFzdC1taWxlICZu YnNwO2xpbmsgJm5ic3A7dXNhZ2UuIA0KJm5ic3A7RnVydGhlcm1vcmUsICZuYnNwO3NpbmNlICZu YnNwO2EgJm5ic3A7UDJQPC9ESVY+DQo8RElWPmNsaWVudCAmbmJzcDttYXkgJm5ic3A7aGF2ZSAm bmJzcDttdWx0aXBsZSAmbmJzcDtwZWVycywgJm5ic3A7aXQgJm5ic3A7Y2FuIA0KJm5ic3A7Y29u dHJvbCAmbmJzcDtyZXNvdXJjZXMgJm5ic3A7dXNlZCAmbmJzcDtieSAmbmJzcDtlYWNoPC9ESVY+ DQo8RElWPnBlZXIgJm5ic3A7dG8gJm5ic3A7c3RvcmUgJm5ic3A7YW5kICZuYnNwO3JldHJpZXZl ICZuYnNwO2NvbnRlbnQuIA0KJm5ic3A7VGhvdWdoICZuYnNwO3RoZXJlICZuYnNwO2FyZSAmbmJz cDtleGlzdGluZyAmbmJzcDtkYXRhPC9ESVY+DQo8RElWPmFjY2VzcyAmbmJzcDtwcm90b2NvbHMg Jm5ic3A7KGUuZy4sICZuYnNwO0hUVFAsICZuYnNwO05GUywgJm5ic3A7V2ViREFWKSwgDQombmJz cDt0aGV5ICZuYnNwO21pZ2h0ICZuYnNwO2JlICZuYnNwO2xhY2tpbmc8L0RJVj4NCjxESVY+Y2Fw YWJpbGl0aWVzICZuYnNwO2ZvciAmbmJzcDtmaW5lLWdyYWluZWQgJm5ic3A7YWNjZXNzICZuYnNw O2FuZCANCiZuYnNwO3Jlc291cmNlICZuYnNwO2NvbnRyb2wgJm5ic3A7KGUuZy4sPC9ESVY+DQo8 RElWPmJhbmR3aWR0aCAmbmJzcDthbmQgJm5ic3A7Y29ubmVjdGlvbnMpICZuYnNwO3RoYXQgJm5i c3A7YXJlICZuYnNwO2Vzc2VudGlhbCANCiZuYnNwO2ZvciAmbmJzcDt0b2RheSdzICZuYnNwO2Fk dmFuY2VkICZuYnNwO1AyUDwvRElWPg0KPERJVj5hcHBsaWNhdGlvbnMuPC9ESVY+DQo8RElWPiZu YnNwOzwvRElWPg0KPERJVj5UaGUgJm5ic3A7V29ya2luZyAmbmJzcDtHcm91cCAmbmJzcDsoV0cp ICZuYnNwO3dpbGwgJm5ic3A7aGF2ZSAmbmJzcDt0aHJlZSANCiZuYnNwO3ByaW1hcnkgJm5ic3A7 dGFza3MuICZuYnNwO0ZpcnN0LCAmbmJzcDt0aGUgJm5ic3A7V0cgJm5ic3A7d2lsbDwvRElWPg0K PERJVj5pZGVudGlmeSAmbmJzcDt0YXJnZXQgJm5ic3A7YXBwbGljYXRpb25zICZuYnNwO3RvICZu YnNwO2FwcHJvcHJpYXRlbHkgDQombmJzcDtzY29wZSAmbmJzcDt0aGUgJm5ic3A7cHJvYmxlbSAm bmJzcDthbmQ8L0RJVj4NCjxESVY+cmVxdWlyZW1lbnRzLiAmbmJzcDtQMlAgJm5ic3A7YXBwbGlj YXRpb25zICZuYnNwO2FyZSAmbmJzcDt0aGUgDQombmJzcDtwcmltYXJ5ICZuYnNwO3RhcmdldCwg Jm5ic3A7YnV0ICZuYnNwO3N1aXRhYmlsaXR5PC9ESVY+DQo8RElWPnRvICZuYnNwO290aGVyICZu YnNwO2FwcGxpY2F0aW9ucyAmbmJzcDt3aXRoICZuYnNwO3NpbWlsYXIgDQombmJzcDtyZXF1aXJl bWVudHMgJm5ic3A7bWF5ICZuYnNwO2JlICZuYnNwO2NvbnNpZGVyZWQ8L0RJVj4NCjxESVY+ZGVw ZW5kaW5nICZuYnNwO29uICZuYnNwO2FkZGl0aW9uYWwgJm5ic3A7Y29tcGxleGl0eSAmbmJzcDty ZXF1aXJlZCANCiZuYnNwO3RvICZuYnNwO3N1cHBvcnQgJm5ic3A7c3VjaDwvRElWPg0KPERJVj5h cHBsaWNhdGlvbnMuPC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj5TZWNvbmQsICZuYnNw O3RoZSAmbmJzcDtXRyAmbmJzcDt3aWxsICZuYnNwO2lkZW50aWZ5ICZuYnNwO3RoZSANCiZuYnNw O3JlcXVpcmVtZW50cyAmbmJzcDt0byAmbmJzcDtlbmFibGUgJm5ic3A7dGFyZ2V0PC9ESVY+DQo8 RElWPmFwcGxpY2F0aW9ucyAmbmJzcDt0byAmbmJzcDt1dGlsaXplICZuYnNwO2luLW5ldHdvcmsg Jm5ic3A7c3RvcmFnZS4gDQombmJzcDtSZXF1aXJlbWVudHMgJm5ic3A7d2lsbCAmbmJzcDtpbmNs dWRlPC9ESVY+DQo8RElWPnRoZSAmbmJzcDthYmlsaXR5ICZuYnNwO2ZvciAmbmJzcDthbiAmbmJz cDthcHBsaWNhdGlvbiAmbmJzcDt0byAmbmJzcDsoMSkgDQombmJzcDtzdG9yZSwgJm5ic3A7cmV0 cmlldmUsICZuYnNwO2FuZCAmbmJzcDttYW5hZ2UgJm5ic3A7ZGF0YSw8L0RJVj4NCjxESVY+KDIp ICZuYnNwO2luZGljYXRlICZuYnNwO2FjY2VzcyAmbmJzcDtjb250cm9sICZuYnNwO3BvbGljaWVz ICZuYnNwO2ZvciANCiZuYnNwO3N0b3JpbmcgJm5ic3A7YW5kICZuYnNwO3JldHJpZXZpbmcgJm5i c3A7ZGF0YTwvRElWPg0KPERJVj5zdWl0YWJsZSAmbmJzcDt0byAmbmJzcDthbiAmbmJzcDtlbnZp cm9ubWVudCAmbmJzcDt3aXRoICZuYnNwO3VzZXJzIA0KJm5ic3A7YWNyb3NzICZuYnNwO211bHRp cGxlICZuYnNwO2FkbWluaXN0cmF0aXZlICZuYnNwO2FuZDwvRElWPg0KPERJVj5zZWN1cml0eSAm bmJzcDtkb21haW5zICZuYnNwOyhlLmcuLCAmbmJzcDtpbiAmbmJzcDthICZuYnNwO1AyUCANCiZu YnNwO2Vudmlyb25tZW50KSwgJm5ic3A7YW5kICZuYnNwOygzKSAmbmJzcDtpbmRpY2F0ZSAmbmJz cDtyZXNvdXJjZTwvRElWPg0KPERJVj5jb250cm9sICZuYnNwO3BvbGljaWVzICZuYnNwO2ZvciAm bmJzcDtzdG9yaW5nICZuYnNwO2FuZCAmbmJzcDtyZXRyaWV2aW5nIA0KJm5ic3A7ZGF0YS48L0RJ Vj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPlRoaXJkLCAmbmJzcDt0aGUgJm5ic3A7V0cgJm5i c3A7d2lsbCAmbmJzcDtkZXZlbG9wICZuYnNwO2FuIA0KJm5ic3A7YXJjaGl0ZWN0dXJlICZuYnNw O3dpdGhpbiAmbmJzcDt3aGljaCAmbmJzcDt0aGUgJm5ic3A7REVDQURFPC9ESVY+DQo8RElWPnBy b3RvY29sICZuYnNwO2NhbiAmbmJzcDtiZSAmbmJzcDtzcGVjaWZpZWQuICZuYnNwO1RoaXMgJm5i c3A7YXJjaGl0ZWN0dXJlIA0KJm5ic3A7d2lsbCAmbmJzcDtpZGVudGlmeSAmbmJzcDtERUNBREUn czwvRElWPg0KPERJVj5yZWxhdGlvbnNoaXAgJm5ic3A7dG8gJm5ic3A7ZXhpc3RpbmcgJm5ic3A7 SUVURiAmbmJzcDtwcm90b2NvbHMgJm5ic3A7YW5kIA0KJm5ic3A7d2hlcmUgJm5ic3A7KGlmICZu YnNwO2FueSkgJm5ic3A7bmV3ICZuYnNwO3Byb3RvY29sPC9ESVY+DQo8RElWPmlzICZuYnNwO25l ZWRlZCAmbmJzcDtvciAmbmJzcDtleHRlbnNpb25zICZuYnNwO3RvICZuYnNwO2V4aXN0aW5nIA0K Jm5ic3A7cHJvdG9jb2xzICZuYnNwO25lZWQgJm5ic3A7dG8gJm5ic3A7YmUgJm5ic3A7bWFkZS4g Jm5ic3A7VGhlPC9ESVY+DQo8RElWPmFyY2hpdGVjdHVyZSAmbmJzcDt3aWxsICZuYnNwO25vdCAm bmJzcDtzcGVjaWZ5ICZuYnNwO2EgJm5ic3A7cHJvdG9jb2wgDQombmJzcDtvciAmbmJzcDtleHRl bnNpb247ICZuYnNwO2lmICZuYnNwO2RldmVsb3BtZW50ICZuYnNwO29mPC9ESVY+DQo8RElWPmEg Jm5ic3A7bmV3ICZuYnNwO3Byb3RvY29sICZuYnNwO2lzICZuYnNwO25lZWRlZCwgJm5ic3A7dGhl ICZuYnNwO1dHIA0KJm5ic3A7d2lsbCAmbmJzcDtzZWVrICZuYnNwO3RvICZuYnNwO3JlY2hhcnRl ciAmbmJzcDtmb3IgJm5ic3A7dGhpcyANCiZuYnNwO3B1cnBvc2U8L0RJVj4NCjxESVY+b3IgJm5i c3A7bWlnaHQgJm5ic3A7YXNrICZuYnNwO2FuICZuYnNwO2V4aXN0aW5nICZuYnNwO1dHICZuYnNw O3RvIA0KJm5ic3A7d29yayAmbmJzcDtvbiAmbmJzcDtzdWNoICZuYnNwO2V4dGVuc2lvbnMuPC9E SVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj5UaGUgJm5ic3A7V0cgJm5ic3A7d2lsbCAmbmJz cDtmb2N1cyAmbmJzcDtvbiAmbmJzcDt0aGUgJm5ic3A7Zm9sbG93aW5nIA0KJm5ic3A7d29yayAm bmJzcDtpdGVtczo8L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPi0gJm5ic3A7QSAmbmJz cDsicHJvYmxlbSAmbmJzcDtzdGF0ZW1lbnQiICZuYnNwO2RvY3VtZW50LiAmbmJzcDtUaGlzIA0K Jm5ic3A7ZG9jdW1lbnQgJm5ic3A7cHJvdmlkZXMgJm5ic3A7YSAmbmJzcDtkZXNjcmlwdGlvbjwv RElWPg0KPERJVj5vZiAmbmJzcDt0aGUgJm5ic3A7cHJvYmxlbSAmbmJzcDthbmQgJm5ic3A7Y29t bW9uICZuYnNwO3Rlcm1pbm9sb2d5LjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+LSAm bmJzcDtBICZuYnNwO3JlcXVpcmVtZW50cyAmbmJzcDtkb2N1bWVudC4gJm5ic3A7VGhpcyAmbmJz cDtkb2N1bWVudCANCiZuYnNwO2xpc3RzICZuYnNwO3RoZSAmbmJzcDtyZXF1aXJlbWVudHMgJm5i c3A7Zm9yICZuYnNwO3RoZTwvRElWPg0KPERJVj5pbi1uZXR3b3JrICZuYnNwO3N0b3JhZ2UgJm5i c3A7c2VydmljZSAmbmJzcDsoZS5nLiwgJm5ic3A7c3VwcG9ydGVkIA0KJm5ic3A7b3BlcmF0aW9u cykgJm5ic3A7YW5kICZuYnNwO3RoZTwvRElWPg0KPERJVj5wcm90b2NvbCAmbmJzcDt0byAmbmJz cDtzdXBwb3J0ICZuYnNwO2l0LiAmbmJzcDtUaGUgJm5ic3A7c2VydmljZSANCiZuYnNwO3dpbGwg Jm5ic3A7aW5jbHVkZSAmbmJzcDtzdG9yaW5nLCAmbmJzcDtyZXRyaWV2aW5nLDwvRElWPg0KPERJ Vj5hbmQgJm5ic3A7bWFuYWdpbmcgJm5ic3A7ZGF0YSAmbmJzcDthcyAmbmJzcDt3ZWxsICZuYnNw O2FzICZuYnNwO3NwZWNpZnlpbmcgDQombmJzcDtib3RoICZuYnNwO2FjY2VzcyAmbmJzcDtjb250 cm9sICZuYnNwO2FuZDwvRElWPg0KPERJVj5yZXNvdXJjZSAmbmJzcDtjb250cm9sICZuYnNwO3Bv bGljaWVzICZuYnNwO2luICZuYnNwO3RoZSAmbmJzcDtpbi1uZXR3b3JrIA0KJm5ic3A7c3RvcmFn ZSAmbmJzcDtwZXJ0YWluaW5nICZuYnNwO3RvICZuYnNwO3RoYXQ8L0RJVj4NCjxESVY+ZGF0YS48 L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPi0gJm5ic3A7QSAmbmJzcDtzdXJ2ZXkgJm5i c3A7ZG9jdW1lbnQuICZuYnNwO1RoaXMgJm5ic3A7ZG9jdW1lbnQgJm5ic3A7d2lsbCANCiZuYnNw O3N1cnZleSAmbmJzcDtleGlzdGluZyAmbmJzcDtyZWxhdGVkPC9ESVY+DQo8RElWPm1lY2hhbmlz bXMgJm5ic3A7YW5kICZuYnNwO3Byb3RvY29scyAmbmJzcDsoZS5nLiwgJm5ic3A7SFRUUCwgJm5i c3A7TkZTLCANCiZuYnNwO2FuZCAmbmJzcDtXZWJEQVYpLCAmbmJzcDthbmQgJm5ic3A7ZXZhbHVh dGU8L0RJVj4NCjxESVY+dGhlaXIgJm5ic3A7YXBwbGljYWJpbGl0eSAmbmJzcDt0byAmbmJzcDtE RUNBREUuPC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj4tICZuYnNwO0FuICZuYnNwO2Fy Y2hpdGVjdHVyZSAmbmJzcDtkb2N1bWVudC4gJm5ic3A7VGhpcyAmbmJzcDtkb2N1bWVudCANCiZu YnNwO3dpbGwgJm5ic3A7aWRlbnRpZnkgJm5ic3A7REVDQURFJ3M8L0RJVj4NCjxESVY+cmVsYXRp b25zaGlwICZuYnNwO3dpdGggJm5ic3A7ZXhpc3RpbmcgJm5ic3A7SUVURiAmbmJzcDtwcm90b2Nv bHMuIA0KJm5ic3A7RXhpc3RpbmcgJm5ic3A7cHJvdG9jb2xzICZuYnNwO3dpbGwgJm5ic3A7YmU8 L0RJVj4NCjxESVY+dXNlZCAmbmJzcDt3aGVyZXZlciAmbmJzcDtwb3NzaWJsZSAmbmJzcDthbmQg Jm5ic3A7YXBwcm9wcmlhdGUgJm5ic3A7dG8gDQombmJzcDtzdXBwb3J0ICZuYnNwO0RFQ0FERSdz PC9ESVY+DQo8RElWPnJlcXVpcmVtZW50cy4gJm5ic3A7SW4gJm5ic3A7cGFydGljdWxhciwgJm5i c3A7ZGF0YSAmbmJzcDtzdG9yYWdlLCANCiZuYnNwO3JldHJpZXZhbCwgJm5ic3A7YW5kICZuYnNw O21hbmFnZW1lbnQ8L0RJVj4NCjxESVY+bWF5ICZuYnNwO2JlICZuYnNwO3Byb3ZpZGVkICZuYnNw O2J5ICZuYnNwO2FuICZuYnNwO2V4aXN0aW5nICZuYnNwO0lFVEYgDQombmJzcDtwcm90b2NvbHMu ICZuYnNwO1RoZSAmbmJzcDtXRyAmbmJzcDt3aWxsICZuYnNwO25vdCAmbmJzcDtsaW1pdDwvRElW Pg0KPERJVj5pdHNlbGYgJm5ic3A7dG8gJm5ic3A7YSAmbmJzcDtzaW5nbGUgJm5ic3A7ZGF0YSAm bmJzcDt0cmFuc3BvcnQgDQombmJzcDtwcm90b2NvbCAmbmJzcDtzaW5jZSAmbmJzcDtkaWZmZXJl bnQgJm5ic3A7cHJvdG9jb2xzPC9ESVY+DQo8RElWPm1heSAmbmJzcDtoYXZlICZuYnNwO3Zhcnlp bmcgJm5ic3A7aW1wbGVtZW50YXRpb24gJm5ic3A7Y29zdHMgJm5ic3A7YW5kIA0KJm5ic3A7cGVy Zm9ybWFuY2UgJm5ic3A7dHJhZGVvZmZzLjwvRElWPg0KPERJVj5Ib3dldmVyLCAmbmJzcDt0byAm bmJzcDtrZWVwICZuYnNwO2ludGVyb3BlcmFiaWxpdHkgJm5ic3A7bWFuYWdlYWJsZSwgDQombmJz cDthICZuYnNwO3NtYWxsICZuYnNwO251bWJlciAmbmJzcDtvZjwvRElWPg0KPERJVj5zcGVjaWZp YywgJm5ic3A7dGFyZ2V0ZWQsICZuYnNwO2RhdGEgJm5ic3A7dHJhbnNwb3J0ICZuYnNwO3Byb3Rv Y29scyANCiZuYnNwO3dpbGwgJm5ic3A7YmUgJm5ic3A7aWRlbnRpZmllZCAmbmJzcDthbmQ8L0RJ Vj4NCjxESVY+dXNlZC48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPi0gJm5ic3A7QW4g Jm5ic3A7ZG9jdW1lbnQgJm5ic3A7ZGVzY3JpYmluZyAmbmJzcDt0aGUgJm5ic3A7aW50ZWdyYXRp b24gDQombmJzcDtvZiAmbmJzcDtERUNBREUgJm5ic3A7d2l0aCAmbmJzcDtleGlzdGluZyAmbmJz cDtQMlA8L0RJVj4NCjxESVY+YXBwbGljYXRpb25zICZuYnNwOyhlLmcuLCAmbmJzcDtpbnRlZ3Jh dGlvbiAmbmJzcDt3aXRoIA0KJm5ic3A7Qml0VG9ycmVudCkuPC9ESVY+DQo8RElWPiZuYnNwOzwv RElWPg0KPERJVj5JZiAmbmJzcDtuZXcgJm5ic3A7cHJvdG9jb2wgJm5ic3A7ZGV2ZWxvcG1lbnQg Jm5ic3A7aXMgJm5ic3A7ZGVlbWVkIA0KJm5ic3A7bmVjZXNzYXJ5LCAmbmJzcDt0aGUgJm5ic3A7 V0cgJm5ic3A7d2lsbCAmbmJzcDtiZTwvRElWPg0KPERJVj5yZWNoYXJ0ZXJlZC4gJm5ic3A7SXQg Jm5ic3A7aXMgJm5ic3A7bm90ICZuYnNwO2V4cGVjdGVkICZuYnNwO3RoYXQgDQombmJzcDthbGwg Jm5ic3A7d29yayAmbmJzcDtpdGVtcyAmbmJzcDt3aWxsICZuYnNwO2JlICZuYnNwO3JlYWR5ICZu YnNwO2ZvcjwvRElWPg0KPERJVj5JRVNHICZuYnNwO3JldmlldyAmbmJzcDtieSAmbmJzcDt0aGF0 ICZuYnNwO3BvaW50LCAmbmJzcDtidXQgJm5ic3A7V0cgDQombmJzcDtjb25zZW5zdXMgJm5ic3A7 bXVzdCAmbmJzcDtzaG93ICZuYnNwO3RoYXQgJm5ic3A7ZG9jdW1lbnRzPC9ESVY+DQo8RElWPmRp cmVjdGluZyAmbmJzcDtldmVudHVhbCAmbmJzcDtwcm90b2NvbCAmbmJzcDtkZXZlbG9wbWVudCAN CiZuYnNwOyhSZXF1aXJlbWVudHMgJm5ic3A7YW5kICZuYnNwO0FyY2hpdGVjdHVyZTwvRElWPg0K PERJVj5kb2N1bWVudCkgJm5ic3A7aGF2ZSAmbmJzcDtzdGFiaWxpemVkLiAmbmJzcDtUaGlzICZu YnNwO3Blcm1pdHMgDQombmJzcDthZGp1c3RtZW50cyAmbmJzcDt0byAmbmJzcDtzdWNoICZuYnNw O2RvY3VtZW50cyAmbmJzcDthczwvRElWPg0KPERJVj5uZWNlc3NhcnkgJm5ic3A7dG8gJm5ic3A7 bWFpbnRhaW4gJm5ic3A7Y29uc2lzdGVuY3kgJm5ic3A7YXMgJm5ic3A7cHJvdG9jb2wgDQombmJz cDtkZXZlbG9wbWVudCAmbmJzcDtpcyAmbmJzcDtkb25lLjwvRElWPg0KPERJVj4mbmJzcDs8L0RJ Vj4NCjxESVY+VGhlICZuYnNwO2ZvbGxvd2luZyAmbmJzcDtpc3N1ZXMgJm5ic3A7YXJlICZuYnNw O2NvbnNpZGVyZWQgDQombmJzcDtvdXQtb2Ytc2NvcGUgJm5ic3A7Zm9yICZuYnNwO3RoZSAmbmJz cDtXRzo8L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPi0gJm5ic3A7U3BlY2lmaWNhdGlv biAmbmJzcDtvZiAmbmJzcDtwb2xpY2llcyAmbmJzcDtyZWdhcmRpbmcgDQombmJzcDtjb3B5cmln aHQtcHJvdGVjdGVkICZuYnNwO29yICZuYnNwO2lsbGVnYWw8L0RJVj4NCjxESVY+Y29udGVudC48 L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPi0gJm5ic3A7TG9jYXRpbmcgJm5ic3A7dGhl ICZuYnNwOyJiZXN0IiAmbmJzcDtpbi1uZXR3b3JrICZuYnNwO3N0b3JhZ2UgDQombmJzcDtsb2Nh dGlvbiAmbmJzcDtmcm9tICZuYnNwO3doaWNoICZuYnNwO3RvICZuYnNwO3JldHJpZXZlPC9ESVY+ DQo8RElWPmNvbnRlbnQgJm5ic3A7aWYgJm5ic3A7dGhlcmUgJm5ic3A7YXJlICZuYnNwO21vcmUg Jm5ic3A7dGhhbiAmbmJzcDtvbmUgDQombmJzcDtsb2NhdGlvbiAmbmJzcDtjYW4gJm5ic3A7cHJv dmlkZSAmbmJzcDt0aGUgJm5ic3A7c2FtZTwvRElWPg0KPERJVj5jb250ZW50LjwvRElWPg0KPERJ Vj4mbmJzcDs8L0RJVj4NCjxESVY+LSAmbmJzcDtEZXZlbG9waW5nICZuYnNwO2EgJm5ic3A7bmV3 ICZuYnNwO3Byb3RvY29sICZuYnNwO2ZvciAmbmJzcDtkYXRhIA0KJm5ic3A7dHJhbnNwb3J0ICZu YnNwO2JldHdlZW4gJm5ic3A7UDJQICZuYnNwO2FwcGxpY2F0aW9uczwvRElWPg0KPERJVj5hbmQg Jm5ic3A7aW4tbmV0d29yayAmbmJzcDtzdG9yYWdlLjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4N CjxESVY+R29hbHMgJm5ic3A7YW5kICZuYnNwO01pbGVzdG9uZXM6PC9ESVY+DQo8RElWPiZuYnNw OzwvRElWPg0KPERJVj5BdWcgJm5ic3A7MjAxMCAmbmJzcDtXb3JraW5nICZuYnNwO0dyb3VwICZu YnNwO0xhc3QgJm5ic3A7Q2FsbCAmbmJzcDtmb3IgDQombmJzcDtQcm9ibGVtICZuYnNwO1N0YXRl bWVudDwvRElWPg0KPERJVj5Ob3YgJm5ic3A7MjAxMCAmbmJzcDtTdWJtaXQgJm5ic3A7UHJvYmxl bSAmbmJzcDtTdGF0ZW1lbnQgJm5ic3A7dG8gDQombmJzcDtJRVNHICZuYnNwO2FzICZuYnNwO0lu Zm9ybWF0aW9uYWw8L0RJVj4NCjxESVY+Tm92ICZuYnNwOzIwMTAgJm5ic3A7V29ya2luZyAmbmJz cDtHcm91cCAmbmJzcDtMYXN0ICZuYnNwO0NhbGwgJm5ic3A7Zm9yIA0KJm5ic3A7U3VydmV5ICZu YnNwO2RvY3VtZW50PC9ESVY+DQo8RElWPkZlYiAmbmJzcDsyMDExICZuYnNwO1N1Ym1pdCAmbmJz cDtTdXJ2ZXkgJm5ic3A7ZG9jdW1lbnQgJm5ic3A7dG8gJm5ic3A7SUVTRyANCiZuYnNwO2FzICZu YnNwO0luZm9ybWF0aW9uYWw8L0RJVj4NCjxESVY+RmViICZuYnNwOzIwMTEgJm5ic3A7V29ya2lu ZyAmbmJzcDtHcm91cCAmbmJzcDtMYXN0ICZuYnNwO0NhbGwgJm5ic3A7Zm9yIA0KJm5ic3A7UmVx dWlyZW1lbnRzICZuYnNwO2RvY3VtZW50PC9ESVY+DQo8RElWPkZlYiAmbmJzcDsyMDExICZuYnNw O1dvcmtpbmcgJm5ic3A7R3JvdXAgJm5ic3A7TGFzdCAmbmJzcDtDYWxsICZuYnNwO2ZvciANCiZu YnNwO0FyY2hpdGVjdHVyZSAmbmJzcDtkb2N1bWVudDwvRElWPg0KPERJVj5NYXIgJm5ic3A7MjAx MSAmbmJzcDtJZGVudGlmeSAmbmJzcDtuZWVkICZuYnNwO2ZvciAmbmJzcDtyZWNoYXJ0ZXJpbmc8 L0RJVj4NCjxESVY+TWF5ICZuYnNwOzIwMTEgJm5ic3A7U3VibWl0ICZuYnNwO1JlcXVpcmVtZW50 cyAmbmJzcDtkb2N1bWVudCAmbmJzcDt0byANCiZuYnNwO0lFU0cgJm5ic3A7YXMgJm5ic3A7SW5m b3JtYXRpb25hbDwvRElWPg0KPERJVj5KdWwgJm5ic3A7MjAxMSAmbmJzcDtTdWJtaXQgJm5ic3A7 QXJjaGl0ZWN0dXJlICZuYnNwO2RvY3VtZW50ICZuYnNwO3RvIA0KJm5ic3A7SUVTRyAmbmJzcDth cyAmbmJzcDtJbmZvcm1hdGlvbmFsPC9ESVY+DQo8RElWPl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fPC9ESVY+DQo8RElWPmRlY2FkZSAmbmJzcDttYWlsaW5n ICZuYnNwO2xpc3Q8L0RJVj4NCjxESVY+ZGVjYWRlQGlldGYub3JnPC9ESVY+DQo8RElWPmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGVjYWRlPC9ESVY+PC9GT05UPjwvRElW PjwvQk9EWT48L0hUTUw+DQo= --=====003_Dragon152735187471_=====-- From melodysong@huawei.com Tue Apr 27 19:14:41 2010 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 304323A6A68 for ; Tue, 27 Apr 2010 19:14:41 -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=-1.280, 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 PJ2jdiJncMZu for ; Tue, 27 Apr 2010 19:14:39 -0700 (PDT) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 966183A6A38 for ; Tue, 27 Apr 2010 19:14:20 -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 <0L1K00DOPE79E1@szxga04-in.huawei.com> for decade@ietf.org; Wed, 28 Apr 2010 10:13:57 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L1K00D6DE79UG@szxga04-in.huawei.com> for decade@ietf.org; Wed, 28 Apr 2010 10:13:57 +0800 (CST) Received: from s64081a ([10.138.84.48]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L1K00587E75GV@szxml04-in.huawei.com> for decade@ietf.org; Wed, 28 Apr 2010 10:13:56 +0800 (CST) Date: Wed, 28 Apr 2010 10:13:52 +0800 From: Song Haibin In-reply-to: <201004281001480004072@chinamobile.com> To: 'zhangyunfei' Message-id: <007801cae678$72dbec80$30548a0a@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_SMbcR6uvCFdMTBrGAiJimw)" Thread-index: AcrmdxYdcHseswGNS6m01geJUnmhkAAABkrQ Cc: decade@ietf.org, richard_woundy@cable.comcast.com Subject: Re: [decade] WG Action: DECoupled Application Data Enroute (decade) X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Apr 2010 02:14:41 -0000 This is a multi-part message in MIME format. --Boundary_(ID_SMbcR6uvCFdMTBrGAiJimw) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: quoted-printable Hi all, =20 I just deleted IESG secretary and ietf-announce from the recipients.=20 =20 Thanks to all decade guys for getting the WG approved. I would like to encourage people to write contributions to this WG. Look forward to = having our first WG meeting in Maastricht.=20 =20 BR, Haibin =20 _____ =20 From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.org] On Behalf = Of zhangyunfei Sent: Wednesday, April 28, 2010 10:02 AM To: IESG Secretary; ietf-announce@ietf.org Cc: decade@ietf.org; richard_woundy@cable.comcast.com Subject: Re: [decade] WG Action: DECoupled Application Data Enroute = (decade) Congratulations! =20 Yunfei =20 _____ =20 zhangyunfei 2010-04-28 _____ =20 =B7=A2=BC=FE=C8=CB=A3=BA IESG Secretary =B7=A2=CB=CD=CA=B1=BC=E4=A3=BA 2010-04-28 01:59:21 =CA=D5=BC=FE=C8=CB=A3=BA ietf-announce@ietf.org =B3=AD=CB=CD=A3=BA decade@ietf.org; richard_woundy@cable.comcast.com =D6=F7=CC=E2=A3=BA [decade] WG Action: DECoupled Application Data = Enroute (decade) =20 A new IETF working group has been formed in the Applications Area. For additional information, please contact the Area Directors or the = WG Chairs. =20 DECoupled Application Data Enroute (decade) -------------------------------------------------- Last modified: 2010-04-23 =20 Chair(s): Haibin Song Richard Woundy =20 Applications Area Director(s): * Alexey Melnikov * Peter Saint-Andre =20 Applications Area Advisor: * Alexey Melnikov =20 Mailing Lists: General Discussion: decade@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/decade Archive: http://www.ietf.org/mail-archive/web/decade/current/maillist.html =20 Description of Working Group: =20 Peer-to-Peer (P2P) applications, including both P2P streaming and P2P file-sharing applications, make up a large fraction of traffic = in the Internet today. One way to reduce access network and/or cross-domain bandwidth usage by P2P applications is to introduce storage capabilities in the network between hosts running P2P applications. Allowing = P2P applications to store and retrieve data from inside the network can reduce traffic on the last-mile uplink, as well as backbone = and transit links. =20 Existing P2P caches often implement the specific P2P application protocols to operate transparently or act as super peers to provide in-network storage. However, it is challenging for P2P cache vendors to support a variety of evolving protocols. Also, for P2P applications, closed P2P caching systems limit effective utilization of = in-network storage. Some P2P protocols may be entirely unsupported by a particular caching system. Additionally, applications may be better-equipped = to decide how in-network storage is used to meet their specific requirements (e.g., data placement, access control and resource control). Note that providers of in-network storage may impose their own access control or resource usage policies. =20 Both of these challenges can be effectively addressed by using open, standard protocols to access in-network storage. P2P applications can store and retrieve content in the in-network storage, as well = as control resources (e.g., bandwidth, connections) consumed by peers in a = P2P application. As a simple example, a peer can choose to store content in the in-network storage, and direct other peers to retrieve from that location, reducing last-mile link usage. Furthermore, since a = P2P client may have multiple peers, it can control resources used = by each peer to store and retrieve content. Though there are existing = data access protocols (e.g., HTTP, NFS, WebDAV), they might be = lacking capabilities for fine-grained access and resource control (e.g., bandwidth and connections) that are essential for today's = advanced P2P applications. =20 The Working Group (WG) will have three primary tasks. First, = the WG will identify target applications to appropriately scope the problem = and requirements. P2P applications are the primary target, but suitability to other applications with similar requirements may be = considered depending on additional complexity required to support such applications. =20 Second, the WG will identify the requirements to enable target applications to utilize in-network storage. Requirements will = include the ability for an application to (1) store, retrieve, and = manage data, (2) indicate access control policies for storing and retrieving data suitable to an environment with users across multiple = administrative and security domains (e.g., in a P2P environment), and (3) indicate resource control policies for storing and retrieving data. =20 Third, the WG will develop an architecture within which the = DECADE protocol can be specified. This architecture will identify = DECADE's relationship to existing IETF protocols and where (if any) new protocol is needed or extensions to existing protocols need to be made. The architecture will not specify a protocol or extension; if development of a new protocol is needed, the WG will seek to recharter for = this purpose or might ask an existing WG to work on such extensions. =20 The WG will focus on the following work items: =20 - A "problem statement" document. This document provides a description of the problem and common terminology. =20 - A requirements document. This document lists the requirements = for the in-network storage service (e.g., supported operations) and the protocol to support it. The service will include storing, retrieving, and managing data as well as specifying both access control = and resource control policies in the in-network storage pertaining = to that data. =20 - A survey document. This document will survey existing related mechanisms and protocols (e.g., HTTP, NFS, and WebDAV), and evaluate their applicability to DECADE. =20 - An architecture document. This document will identify DECADE's relationship with existing IETF protocols. Existing protocols = will be used wherever possible and appropriate to support DECADE's requirements. In particular, data storage, retrieval, and = management may be provided by an existing IETF protocols. The WG will = not limit itself to a single data transport protocol since different protocols may have varying implementation costs and performance tradeoffs. However, to keep interoperability manageable, a small number of specific, targeted, data transport protocols will be identified = and used. =20 - An document describing the integration of DECADE with = existing P2P applications (e.g., integration with BitTorrent). =20 If new protocol development is deemed necessary, the WG will = be rechartered. It is not expected that all work items will be = ready for IESG review by that point, but WG consensus must show that documents directing eventual protocol development (Requirements and = Architecture document) have stabilized. This permits adjustments to such documents as necessary to maintain consistency as protocol development is = done. =20 The following issues are considered out-of-scope for the WG: =20 - Specification of policies regarding copyright-protected or = illegal content. =20 - Locating the "best" in-network storage location from which to retrieve content if there are more than one location can provide the = same content. =20 - Developing a new protocol for data transport between P2P applications and in-network storage. =20 Goals and Milestones: =20 Aug 2010 Working Group Last Call for Problem Statement Nov 2010 Submit Problem Statement to IESG as Informational Nov 2010 Working Group Last Call for Survey document Feb 2011 Submit Survey document to IESG as Informational Feb 2011 Working Group Last Call for Requirements document Feb 2011 Working Group Last Call for Architecture document Mar 2011 Identify need for rechartering May 2011 Submit Requirements document to IESG as Informational Jul 2011 Submit Architecture document to IESG as Informational _______________________________________________ decade mailing list decade@ietf.org https://www.ietf.org/mailman/listinfo/decade --Boundary_(ID_SMbcR6uvCFdMTBrGAiJimw) Content-type: text/html; charset=gb2312 Content-transfer-encoding: quoted-printable
Hi all,
 
I just deleted IESG secretary and = ietf-announce from=20 the recipients.
 
Thanks to all decade guys for=20 getting the WG approved. I would like to encourage people to = write=20 contributions to this WG. Look forward to having our first WG = meeting=20 in Maastricht. 
 
BR,
Haibin
 

From: decade-bounces@ietf.org=20 [mailto:decade-bounces@ietf.org] On Behalf Of=20 zhangyunfei
Sent: Wednesday, April 28, 2010 10:02=20 AM
To: IESG Secretary; ietf-announce@ietf.org
Cc:=20 decade@ietf.org; richard_woundy@cable.comcast.com
Subject: = Re:=20 [decade] WG Action: DECoupled Application Data Enroute=20 (decade)

Congratulations!
 
Yunfei
 
zhangyunfei
2010-04-28
=B7=A2=BC=FE=C8=CB=A3=BA IESG=20 Secretary
=B7=A2=CB=CD=CA=B1=BC=E4=A3=BA=20 2010-04-28 01:59:21
=CA=D5=BC=FE=C8=CB=A3=BA=20 ietf-announce@ietf.org
=B3=AD=CB=CD=A3=BA decade@ietf.org;=20 richard_woundy@cable.comcast.com
=D6=F7=CC=E2=A3=BA [decade] WG Action:=20 DECoupled Application Data Enroute (decade)
 
A  new  IETF  working  group  has =  been=20  formed  in  the  Applications  Area.  =20  For
additional  information,  please  contact =  the=20  Area  Directors  or  the  WG
Chairs.
 
DECoupled  Application  Data  Enroute =  (decade)
--------------------------------------------------
Last  modified:  2010-04-23
 
Chair(s):
Haibin  Song   <melodysong@huawei.com >
Richard  Woundy   <richard_woundy@cable.comcast.com=20 >
 
Applications  Area  Director(s):
*  Alexey  Melnikov   = <alexey.melnikov@isode.com=20 >
*  Peter  Saint-Andre   <stpeter@stpeter.im = >
 
Applications  Area  Advisor:
*  Alexey  Melnikov   = <alexey.melnikov@isode.com=20 >
 
Mailing  Lists:
 General  Discussion:  decade@ietf.org
 To  Subscribe:=20  https://www.ietf.org/mailman/listinfo/decade
 Archive:
http://www.ietf.org/mail-archive/web/decade/current/maillist.html
 
Description  of  Working  Group:
 
Peer-to-Peer  (P2P)  applications,  including =  both=20  P2P  streaming  and  P2P
file-sharing  applications,  make  up  a =  large=20  fraction  of  traffic  in
the  Internet  today.  One  way  to =  reduce=20  access  network  and/or  cross-domain
bandwidth  usage  by  P2P  applications =  is=20  to  introduce  storage  capabilities
in  the  network  between  hosts =  running=20  P2P  applications.  Allowing  P2P
applications  to  store  and  retrieve =  data=20  from  inside  the  network  can
reduce  traffic  on  the  last-mile =  uplink,=20  as  well  as  backbone  and
transit  links.
 
Existing  P2P  caches  often  implement =  the=20  specific  P2P  application
protocols  to  operate  transparently  or =  act=20  as  super  peers  to  provide
in-network  storage.  However,  it  is=20  challenging  for  P2P  cache  vendors =  to
support  a  variety  of  evolving =  protocols.=20  Also,  for  P2P  applications,
closed  P2P  caching  systems  limit =  effective=20  utilization  of  in-network
storage.  Some  P2P  protocols  may  be=20  entirely  unsupported  by  a =  particular
caching  system.  Additionally,  applications =  may=20  be  better-equipped  to
decide  how  in-network  storage  is =  used=20  to  meet  their  specific
requirements  (e.g.,  data  placement, =  access=20  control  and  resource
control).  Note  that  providers  of =  in-network=20  storage  may  impose  their
own  access  control  or  resource =  usage=20  policies.
 
Both  of  these  challenges  can  be=20  effectively  addressed  by  using =  open,
standard  protocols  to  access  in-network=20  storage.  P2P  applications  can
store  and  retrieve  content  in  the=20  in-network  storage,  as  well  as=20  control
resources  (e.g.,  bandwidth,  connections) =  consumed=20  by  peers  in  a  P2P
application.  As  a  simple  example,  a =  peer  can  choose  to  store  content=20  in
the  in-network  storage,  and  direct =  other=20  peers  to  retrieve  from  that
location,  reducing  last-mile  link  usage.=20  Furthermore,  since  a  P2P
client  may  have  multiple  peers,  it=20  can  control  resources  used  by =  each
peer  to  store  and  retrieve  content. =  Though  there  are  existing  data
access  protocols  (e.g.,  HTTP,  NFS, =  WebDAV),=20  they  might  be  lacking
capabilities  for  fine-grained  access  and=20  resource  control  (e.g.,
bandwidth  and  connections)  that  are=20  essential  for  today's  advanced  P2P
applications.
 
The  Working  Group  (WG)  will  have=20  three  primary  tasks.  First,  the  WG =  will
identify  target  applications  to =  appropriately=20  scope  the  problem  and
requirements.  P2P  applications  are  the=20  primary  target,  but  suitability
to  other  applications  with  similar=20  requirements  may  be  considered
depending  on  additional  complexity =  required=20  to  support  such
applications.
 
Second,  the  WG  will  identify  the=20  requirements  to  enable  target
applications  to  utilize  in-network =  storage.=20  Requirements  will  include
the  ability  for  an  application  to =  (1)=20  store,  retrieve,  and  manage  data,
(2)  indicate  access  control  policies =  for=20  storing  and  retrieving  data
suitable  to  an  environment  with =  users=20  across  multiple  administrative  and
security  domains  (e.g.,  in  a  P2P=20  environment),  and  (3)  indicate =  resource
control  policies  for  storing  and =  retrieving=20  data.
 
Third,  the  WG  will  develop  an=20  architecture  within  which  the =  DECADE
protocol  can  be  specified.  This=20  architecture  will  identify  DECADE's
relationship  to  existing  IETF  protocols =  and=20  where  (if  any)  new  protocol
is  needed  or  extensions  to  existing =  protocols  need  to  be  made. =  The
architecture  will  not  specify  a =  protocol=20  or  extension;  if  development  of
a  new  protocol  is  needed,  the =  WG=20  will  seek  to  recharter  for  this=20  purpose
or  might  ask  an  existing  WG =  to=20  work  on  such  extensions.
 
The  WG  will  focus  on  the =  following=20  work  items:
 
-  A  "problem  statement"  document. =  This=20  document  provides  a  description
of  the  problem  and  common=20  terminology.
 
-  A  requirements  document.  This =  document=20  lists  the  requirements  for  the
in-network  storage  service  (e.g., =  supported=20  operations)  and  the
protocol  to  support  it.  The  service =  will  include  storing,  retrieving,
and  managing  data  as  well  as=20  specifying  both  access  control  and
resource  control  policies  in  the =  in-network=20  storage  pertaining  to  that
data.
 
-  A  survey  document.  This  document=20  will  survey  existing  related
mechanisms  and  protocols  (e.g.,  HTTP, =  NFS,=20  and  WebDAV),  and  evaluate
their  applicability  to  DECADE.
 
-  An  architecture  document.  This =  document=20  will  identify  DECADE's
relationship  with  existing  IETF =  protocols.=20  Existing  protocols  will  be
used  wherever  possible  and  appropriate =  to=20  support  DECADE's
requirements.  In  particular,  data =  storage,=20  retrieval,  and  management
may  be  provided  by  an  existing =  IETF=20  protocols.  The  WG  will  not =  limit
itself  to  a  single  data  transport=20  protocol  since  different  protocols
may  have  varying  implementation  costs =  and=20  performance  tradeoffs.
However,  to  keep  interoperability =  manageable,=20  a  small  number  of
specific,  targeted,  data  transport =  protocols=20  will  be  identified  and
used.
 
-  An  document  describing  the =  integration=20  of  DECADE  with  existing  P2P
applications  (e.g.,  integration  with=20  BitTorrent).
 
If  new  protocol  development  is =  deemed=20  necessary,  the  WG  will  be
rechartered.  It  is  not  expected =  that=20  all  work  items  will  be  ready=20  for
IESG  review  by  that  point,  but =  WG=20  consensus  must  show  that  documents
directing  eventual  protocol  development=20  (Requirements  and  Architecture
document)  have  stabilized.  This  permits=20  adjustments  to  such  documents  as
necessary  to  maintain  consistency  as=20  protocol  development  is  done.
 
The  following  issues  are  considered=20  out-of-scope  for  the  WG:
 
-  Specification  of  policies  regarding=20  copyright-protected  or  illegal
content.
 
-  Locating  the  "best"  in-network =  storage=20  location  from  which  to  retrieve
content  if  there  are  more  than =  one=20  location  can  provide  the  same
content.
 
-  Developing  a  new  protocol  for =  data=20  transport  between  P2P  applications
and  in-network  storage.
 
Goals  and  Milestones:
 
Aug  2010  Working  Group  Last  Call =  for=20  Problem  Statement
Nov  2010  Submit  Problem  Statement =  to=20  IESG  as  Informational
Nov  2010  Working  Group  Last  Call =  for=20  Survey  document
Feb  2011  Submit  Survey  document  to=20  IESG  as  Informational
Feb  2011  Working  Group  Last  Call =  for=20  Requirements  document
Feb  2011  Working  Group  Last  Call =  for=20  Architecture  document
Mar  2011  Identify  need  for=20  rechartering
May  2011  Submit  Requirements  document =  to=20  IESG  as  Informational
Jul  2011  Submit  Architecture  document =  to=20  IESG  as  Informational
_______________________________________________
decade  mailing  list
decade@ietf.org
=
https://www.ietf.org/mailman/listinfo/decade
--Boundary_(ID_SMbcR6uvCFdMTBrGAiJimw)--