From melodysong@huawei.com Thu Dec 10 19:22:04 2009 Return-Path: X-Original-To: decade@core3.amsl.com Delivered-To: decade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ACFAA3A68E8 for ; Thu, 10 Dec 2009 19:22:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.688 X-Spam-Level: X-Spam-Status: No, score=-0.688 tagged_above=-999 required=5 tests=[AWL=1.026, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r4md+cIDHW-P for ; Thu, 10 Dec 2009 19:22:03 -0800 (PST) Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id 8A5983A68D6 for ; Thu, 10 Dec 2009 19:22:03 -0800 (PST) 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 <0KUG00DB3XCBGS@szxga02-in.huawei.com> for decade@ietf.org; Fri, 11 Dec 2009 11:21:47 +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 <0KUG00B3CXCA74@szxga02-in.huawei.com> for decade@ietf.org; Fri, 11 Dec 2009 11:21:46 +0800 (CST) Received: from s64081a ([10.164.12.24]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KUG006MVXC7VU@szxml04-in.huawei.com> for decade@ietf.org; Fri, 11 Dec 2009 11:21:46 +0800 (CST) Date: Fri, 11 Dec 2009 11:21:43 +0800 From: Song Haibin To: decade@ietf.org Message-id: <00ab01ca7a11$10483200$180ca40a@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_CJ9e0w5yk0PagWLzis7c4w)" Thread-index: Acp6ERATHoC5nsRERPewL+zbG01A+Q== Subject: [decade] scope discussion X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Dec 2009 03:22:05 -0000 This is a multi-part message in MIME format. --Boundary_(ID_CJ9e0w5yk0PagWLzis7c4w) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Dear all, While many people in the meeting room at IETF 76 thought the problem was clear, and reasonable to solve, but not well-scoped (mainly about the in-network storage access protocol). I propose a few options for the protocol scope. (1) A standard IAP protocol, which includes read/write & resource control. P2P client can use this protocol to upload contents to/download contents from the in-network storage, or send commands to its in-network storage on resource sharing policies with remote peers (bandwidth, connections, etc. ); (2) A single standard read/write protocol. P2P client can use this protocol to upload contents to/download contents from the in-network storage. (3) A resource control and transport negotiation protocol. We don't need to standardize the read/write protocol here, but P2P client can use this protocol to negotiate the necessary transport protocol for the content, and send commands to its in-network storage on resource sharing policies with remote peers (bandwidth, connections, etc. ); For option (1) and (2), I think it might be a little harder to enable a single read/write protocol qualified to transport various kinds of contents, and there might be a little overlap with NFS/WebDAV. How about limiting the IAP scope to option (3)? I think it is much cleaner and feasible to solve. BR, Haibin --Boundary_(ID_CJ9e0w5yk0PagWLzis7c4w) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT
Dear all,
 
While many people in the meeting room at IETF 76 thought the problem was clear, and reasonable to solve, but not well-scoped (mainly about the in-network storage access protocol). I propose a few options for the protocol scope.
 
(1) A standard IAP protocol, which includes read/write & resource control. P2P client can use this protocol to upload contents to/download contents from the in-network storage, or send commands to its in-network storage on resource sharing policies with remote peers (bandwidth, connections, etc. );
 
(2) A single standard read/write protocol.  P2P client can use this protocol to upload contents to/download contents from the in-network storage.
 
(3) A resource control and transport negotiation protocol. We don't need to standardize the read/write protocol here, but P2P client can use this protocol to negotiate the necessary transport protocol for the content, and send commands to its in-network storage on resource sharing policies with remote peers (bandwidth, connections, etc. );
 
For option (1) and (2), I think it might be a little harder to enable a single read/write protocol qualified to transport various kinds of contents, and there might be a little overlap with NFS/WebDAV.
 
How about limiting the IAP scope to option (3)? I think it is much cleaner and feasible to solve.
 
BR,
Haibin
--Boundary_(ID_CJ9e0w5yk0PagWLzis7c4w)-- From lucyyong@huawei.com Mon Dec 14 12:25:59 2009 Return-Path: X-Original-To: decade@core3.amsl.com Delivered-To: decade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4596F28C0F9 for ; Mon, 14 Dec 2009 12:25:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.866 X-Spam-Level: X-Spam-Status: No, score=-1.866 tagged_above=-999 required=5 tests=[AWL=-0.757, BAYES_05=-1.11, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9-CerD-RdQaL for ; Mon, 14 Dec 2009 12:25:54 -0800 (PST) Received: from usaga02-in.huawei.com (usaga02-in.huawei.com [206.16.17.70]) by core3.amsl.com (Postfix) with ESMTP id ECD853A6912 for ; Mon, 14 Dec 2009 12:25:53 -0800 (PST) Received: from huawei.com (localhost [127.0.0.1]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KUN00BKISQR46@usaga02-in.huawei.com> for decade@ietf.org; Mon, 14 Dec 2009 12:25:40 -0800 (PST) Received: from y736742 ([10.124.12.75]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KUN00D8QSQP4E@usaga02-in.huawei.com> for decade@ietf.org; Mon, 14 Dec 2009 12:25:39 -0800 (PST) Date: Mon, 14 Dec 2009 14:25:37 -0600 From: Yong Lucy In-reply-to: <00ab01ca7a11$10483200$180ca40a@china.huawei.com> To: 'Song Haibin' , decade@ietf.org Message-id: <009201ca7cfb$99a73c70$4b0c7c0a@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_yrHyiRnyQOUj1UaEonVqCg)" Thread-index: Acp6ERATHoC5nsRERPewL+zbG01A+QC5cXKQ References: <00ab01ca7a11$10483200$180ca40a@china.huawei.com> Subject: Re: [decade] scope discussion X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Dec 2009 20:25:59 -0000 This is a multi-part message in MIME format. --Boundary_(ID_yrHyiRnyQOUj1UaEonVqCg) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT I studied NFS WG work a bit. NFS works on remote direct memory access (RDMA) protocol that allows remote memory access operation. The protocol works in RPC based architecture. IAP protocol includes read/write protocol for in-network storage access. IAP may be able to use RDAM for read/write operation. The question is that if DECADE architecture has to use client/server architecture. IAP also needs the protocol to pass the in-network storage access reference and authority to other peers or in-network storage itself so that the peers or the storage can use the references to perform the read/write actions over in-network storage. I don't see this work under NFS WG scope. Not sure if DECADE work should include the protocol to help the negotiation of transport protocol underline. Would like to see some experts on NFS to provide the input. Regards, Lucy _____ From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.org] On Behalf Of Song Haibin Sent: Thursday, December 10, 2009 9:22 PM To: decade@ietf.org Subject: [decade] scope discussion Dear all, While many people in the meeting room at IETF 76 thought the problem was clear, and reasonable to solve, but not well-scoped (mainly about the in-network storage access protocol). I propose a few options for the protocol scope. (1) A standard IAP protocol, which includes read/write & resource control. P2P client can use this protocol to upload contents to/download contents from the in-network storage, or send commands to its in-network storage on resource sharing policies with remote peers (bandwidth, connections, etc. ); (2) A single standard read/write protocol. P2P client can use this protocol to upload contents to/download contents from the in-network storage. (3) A resource control and transport negotiation protocol. We don't need to standardize the read/write protocol here, but P2P client can use this protocol to negotiate the necessary transport protocol for the content, and send commands to its in-network storage on resource sharing policies with remote peers (bandwidth, connections, etc. ); For option (1) and (2), I think it might be a little harder to enable a single read/write protocol qualified to transport various kinds of contents, and there might be a little overlap with NFS/WebDAV. How about limiting the IAP scope to option (3)? I think it is much cleaner and feasible to solve. BR, Haibin --Boundary_(ID_yrHyiRnyQOUj1UaEonVqCg) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

I studied NFS WG work a bit. NFS works on remote direct memory access (RDMA) protocol that allows remote memory access operation. The protocol works in RPC based architecture. IAP protocol includes read/write protocol for in-network storage access. IAP may be able to use RDAM for read/write operation. The question is that if DECADE architecture has to use client/server architecture.  

 

IAP also needs the protocol to pass the in-network storage access reference and authority to other peers or in-network storage itself so that the peers or the storage can use the references to perform the read/write actions over in-network storage. I don’t see this work under NFS WG scope.

 

Not sure if DECADE work should include the protocol to help the negotiation of transport protocol underline.

 

Would like to see some experts on NFS to provide the input.

 

Regards,

Lucy

 

 

 

From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.org] On Behalf Of Song Haibin
Sent: Thursday, December 10, 2009 9:22 PM
To: decade@ietf.org
Subject: [decade] scope discussion

 

Dear all,

 

While many people in the meeting room at IETF 76 thought the problem was clear, and reasonable to solve, but not well-scoped (mainly about the in-network storage access protocol). I propose a few options for the protocol scope.

 

(1) A standard IAP protocol, which includes read/write & resource control. P2P client can use this protocol to upload contents to/download contents from the in-network storage, or send commands to its in-network storage on resource sharing policies with remote peers (bandwidth, connections, etc. );

 

(2) A single standard read/write protocol.  P2P client can use this protocol to upload contents to/download contents from the in-network storage.

 

(3) A resource control and transport negotiation protocol. We don't need to standardize the read/write protocol here, but P2P client can use this protocol to negotiate the necessary transport protocol for the content, and send commands to its in-network storage on resource sharing policies with remote peers (bandwidth, connections, etc. );

 

For option (1) and (2), I think it might be a little harder to enable a single read/write protocol qualified to transport various kinds of contents, and there might be a little overlap with NFS/WebDAV.

 

How about limiting the IAP scope to option (3)? I think it is much cleaner and feasible to solve.

 

BR,

Haibin

--Boundary_(ID_yrHyiRnyQOUj1UaEonVqCg)-- From melodysong@huawei.com Wed Dec 16 18:41:45 2009 Return-Path: X-Original-To: decade@core3.amsl.com Delivered-To: decade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F0D533A68E5 for ; Wed, 16 Dec 2009 18:41:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.192 X-Spam-Level: X-Spam-Status: No, score=-0.192 tagged_above=-999 required=5 tests=[AWL=0.303, 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 6KFSZKjvFt-V for ; Wed, 16 Dec 2009 18:41:45 -0800 (PST) Received: from szxga02-in.huawei.com (unknown [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id F0CB23A684D for ; Wed, 16 Dec 2009 18:41:44 -0800 (PST) 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 <0KUR000KAZGWJA@szxga02-in.huawei.com> for decade@ietf.org; Thu, 17 Dec 2009 10:41:20 +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 <0KUR00JAZZGWCN@szxga02-in.huawei.com> for decade@ietf.org; Thu, 17 Dec 2009 10:41:20 +0800 (CST) Received: from s64081a ([10.164.12.24]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KUR00EUNZGS3X@szxml06-in.huawei.com> for decade@ietf.org; Thu, 17 Dec 2009 10:41:20 +0800 (CST) Date: Thu, 17 Dec 2009 10:41:13 +0800 From: Song Haibin In-reply-to: <009201ca7cfb$99a73c70$4b0c7c0a@china.huawei.com> To: 'Yong Lucy' , decade@ietf.org Message-id: <000001ca7ec2$680a6f70$180ca40a@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: Acp6ERATHoC5nsRERPewL+zbG01A+QC5cXKQAHHoeiA= Subject: Re: [decade] scope discussion 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, 17 Dec 2009 02:41:46 -0000 Hi Lucy, Thanks for your reply. Sorry for the late reply because I'm very busy these days. Please see inline. > -----Original Message----- > From: Yong Lucy [mailto:lucyyong@huawei.com] > Sent: Tuesday, December 15, 2009 4:26 AM > To: 'Song Haibin'; decade@ietf.org > Subject: RE: [decade] scope discussion > > I studied NFS WG work a bit. NFS works on remote direct > memory access (RDMA) protocol that allows remote memory > access operation. The protocol works in RPC based > architecture. IAP protocol includes read/write protocol for > in-network storage access. IAP may be able to use RDAM for > read/write operation. I am sorry that I know little about RDMA, maybe some experts on NFS could provide good comments here. IMHO, there are many kinds of contents could be transferred between client and in-network storage. For real-time or near-real-time media, RTP/RTCP might be used for the transport. For non-real-time data, you might use HTTP or other standard protocol (might be RDMA?) for the transport. That's why I suggest IAP should not include the read/write protocol itself but instead the negotiation of transport protocol underline. However, comments from NFS experts would be very appreciated. >The question is that if DECADE > architecture has to use client/server architecture. > IMO, yes. What's in your mind? > > IAP also needs the protocol to pass the in-network storage > access reference and authority to other peers or in-network > storage itself so that the peers or the storage can use the > references to perform the read/write actions over in-network > storage. I don't see this work under NFS WG scope. > This is related to access control and resource control. P2P applications clients usually have the resource control and access control locally, but now they have their contents in the network core, so they need to have the ability ( with IAP) to control the resource allocation and sharing policies for their contents in the in-network storage. I don't think this is under NFS scope. Any comments? > > Not sure if DECADE work should include the protocol to help > the negotiation of transport protocol underline. > See above. > > Would like to see some experts on NFS to provide the input. > > Me too. BR, Haibin > > Regards, > > Lucy > > > > > > > > ________________________________ > > From: decade-bounces@ietf.org > [mailto:decade-bounces@ietf.org] On Behalf Of Song Haibin > Sent: Thursday, December 10, 2009 9:22 PM > To: decade@ietf.org > Subject: [decade] scope discussion > > > > Dear all, > > > > While many people in the meeting room at IETF 76 thought the > problem was clear, and reasonable to solve, but not > well-scoped (mainly about the in-network storage access > protocol). I propose a few options for the protocol scope. > > > > (1) A standard IAP protocol, which includes read/write & > resource control. P2P client can use this protocol to upload > contents to/download contents from the in-network storage, or > send commands to its in-network storage on resource sharing > policies with remote peers (bandwidth, connections, etc. ); > > > > (2) A single standard read/write protocol. P2P client can > use this protocol to upload contents to/download contents > from the in-network storage. > > > > (3) A resource control and transport negotiation protocol. We > don't need to standardize the read/write protocol here, but > P2P client can use this protocol to negotiate the necessary > transport protocol for the content, and send commands to its > in-network storage on resource sharing policies with remote > peers (bandwidth, connections, etc. ); > > > > For option (1) and (2), I think it might be a little harder > to enable a single read/write protocol qualified to transport > various kinds of contents, and there might be a little > overlap with NFS/WebDAV. > > > > How about limiting the IAP scope to option (3)? I think it is > much cleaner and feasible to solve. > > > > BR, > > Haibin > > From lars.eggert@nokia.com Wed Dec 16 22:42:28 2009 Return-Path: X-Original-To: decade@core3.amsl.com Delivered-To: decade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1146F3A6848 for ; Wed, 16 Dec 2009 22:42:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.239 X-Spam-Level: X-Spam-Status: No, score=-3.239 tagged_above=-999 required=5 tests=[AWL=0.360, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yGcCcdcJNlqF for ; Wed, 16 Dec 2009 22:42:25 -0800 (PST) Received: from smtp.tele.fi (smtp.tele.fi [192.89.123.25]) by core3.amsl.com (Postfix) with ESMTP id DE1AA3A6AF4 for ; Wed, 16 Dec 2009 22:41:57 -0800 (PST) X-Originating-Ip: [212.213.221.241] Received: from host-241.nrln.net (host-241.nrln.net [212.213.221.241]) by smtp.tele.fi (Postfix) with ESMTP id 4E37834E; Thu, 17 Dec 2009 08:41:10 +0200 (EET) Received: from mail.fit.nokia.com ([212.213.221.40]) by host-241.nrln.net (Lotus Domino Release 6.5) with ESMTP id 2009121708471262-11923 ; Thu, 17 Dec 2009 08:47:12 +0200 Received: from [10.0.1.5] (cs95024.pp.htv.fi [212.90.95.24]) (authenticated bits=0) by mail.fit.nokia.com (8.14.3/8.14.3) with ESMTP id nBH6f165006956 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 17 Dec 2009 08:41:02 +0200 (EET) (envelope-from lars.eggert@nokia.com) Mime-Version: 1.0 (Apple Message framework v1077) From: Lars Eggert In-Reply-To: <009201ca7cfb$99a73c70$4b0c7c0a@china.huawei.com> Date: Thu, 17 Dec 2009 08:41:01 +0200 Message-Id: References: <00ab01ca7a11$10483200$180ca40a@china.huawei.com> <009201ca7cfb$99a73c70$4b0c7c0a@china.huawei.com> To: Yong Lucy X-Mailer: Apple Mail (2.1077) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (mail.fit.nokia.com [195.148.124.194]); Thu, 17 Dec 2009 08:41:03 +0200 (EET) X-MIMETrack: Itemize by SMTP Server on host-241/srv/nrln(Release 6.5|September 26, 2003) at 12/17/2009 08:47:12 AM, Serialize by Router on host-241/srv/nrln(Release 6.5|September 26, 2003) at 12/17/2009 08:47:21 AM, Serialize complete at 12/17/2009 08:47:21 AM Content-Type: multipart/signed; boundary=Apple-Mail-48--742979956; protocol="application/pkcs7-signature"; micalg=sha1 Cc: "decade@ietf.org" Subject: Re: [decade] scope discussion 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, 17 Dec 2009 06:42:28 -0000 --Apple-Mail-48--742979956 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, On 2009-12-14, at 22:25, Yong Lucy wrote: > Would like to see some experts on NFS to provide the input. in that case, let me suggest that you ask them by putting together an = email and sending it to nfsv4@ietf.org? Lars= --Apple-Mail-48--742979956 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGbDCCAyUw ggKOoAMCAQICEAdjk36sXKbnVn15S0/qUp0wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDYxNTExMjYxNFoXDTEwMDYxNTExMjYx NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA7mR8A+Pn0/FsUkMX6Pyjw+FL3IFcJk8GaKV5VJ40TMI0Wh8oq20cqA9X uqnVDW9WztKwH+o+msJenLwWpprbpJm4TImYGbnUJxYyN8gb81aiX1Bw2xCpJ5z3H2+8DsReJLuY Rdl4bVvaIxLIL4odmfsRwzPyNkOK8LRtfl6OPcaDOlFWzbikULfIVGGu7BqK4lxQSpYwwpZkOMOB 6nnBSfUOtBEmqO+qZG/nL/JxWFV5vxQgg4XHbsMMTxFf6+ji18BD09BUIfDLTuJoCzFmQhrM9vLT VuRhHWSL20LoafGjXv6mPt3i9IGJHpVb2dMQUgOgRyWHTKiUJVU/rUTdWwIDAQABo14wXDAqBgUr ZQEEAQQhMB8CAQAwGjAYAgEEBBNMMnVNeWZmQk5VYk5KSmNkWjJzMCAGA1UdEQQZMBeBFWxhcnMu ZWdnZXJ0QG5va2lhLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBADUx+67n98wt I1vydB90HeSZP4Y64VCxxb0NxGGFvfc2+JdVKeHJ/xT+l+ygYKsWNwJJprkPi4WZ5G0crkq4VK1H 5drEJIztpSPVfWI05vPidaaGuuuCR+6MvJMtOTEYEvc/6eovBnkrzRf9x5x5EyuJXAWTeuBADg80 QI3vQ1tZMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUg Q29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIG A1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25h bC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUA A4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAK MNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7 n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAw QwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJl ZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRl TGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9M Ibj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAxAwggMMAgEBMHYw YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAq BgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAHY5N+rFym51Z9eUtP 6lKdMAkGBSsOAwIaBQCgggFvMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkF MQ8XDTA5MTIxNzA2NDEwMVowIwYJKoZIhvcNAQkEMRYEFGyDbkvbseWS9Hdabx8Z/gr77wLZMIGF BgkrBgEEAYI3EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGlu ZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBD QQIQB2OTfqxcpudWfXlLT+pSnTCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVy c29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQB2OTfqxcpudWfXlLT+pSnTANBgkqhkiG9w0BAQEF AASCAQAOl/jJnBTc2qBPv6FKJRW/6Rp0QW19hOS20GMCyKbz3QdoHPEXhxlH48D1BD5kHgd2Hq3S RhdUKHaF5apknxkuTp9w+WlhSq2HcO10jLfFL+WzHejxGQ209f81vpIlIkTpaSuOfJdPrHgmm5DA 8qOYQKwQqiTZI7aXmtthDpTM8f8H5zotw97DCBIIGpf4xHAj6ImwUoyc1qLDMLmP2nPg4z1XcN1m VZOg6/O4CeC4Iw1poYHlj1x9h/W+y1vwxEkUS14HgweLOAZFfN3CrYMbmzQ6Lqg7HX0NXXPvAEvR //omHdPUahxa+lDN0fNyANhFvp9Tr2/hAmw8k1KUeUHDAAAAAAAA --Apple-Mail-48--742979956-- From shepler@storspeed.com Thu Dec 17 06:21:23 2009 Return-Path: X-Original-To: decade@core3.amsl.com Delivered-To: decade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AAD673A6892 for ; Thu, 17 Dec 2009 06:21:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eWSgD+hwosY8 for ; Thu, 17 Dec 2009 06:21:22 -0800 (PST) Received: from mail.storspeed.com (mail.storspeed.com [209.163.168.123]) by core3.amsl.com (Postfix) with ESMTP id C85153A685A for ; Thu, 17 Dec 2009 06:21:19 -0800 (PST) Received: from [192.168.0.8] (adsl-75-60-181-130.dsl.austtx.sbcglobal.net [75.60.181.130]) (authenticated bits=0) by mail.storspeed.com (8.14.3/8.14.3) with ESMTP id nBHEHitf009624; Thu, 17 Dec 2009 08:18:00 -0600 (CST) (envelope-from shepler@storspeed.com) References: <00ab01ca7a11$10483200$180ca40a@china.huawei.com> <009201ca7cfb$99a73c70$4b0c7c0a@china.huawei.com> Message-Id: From: Spencer Shepler To: Lars Eggert In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit X-Mailer: iPhone Mail (7D11) Mime-Version: 1.0 (iPhone Mail 7D11) Date: Thu, 17 Dec 2009 08:19:59 -0600 Cc: "decade@ietf.org" Subject: Re: [decade] scope discussion 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, 17 Dec 2009 14:21:23 -0000 I can help. I have been lurking but apologize that I haven't been following closely enough to know the specific question(s). Spencer On Dec 17, 2009, at 12:41 AM, Lars Eggert wrote: > Hi, > > On 2009-12-14, at 22:25, Yong Lucy wrote: >> Would like to see some experts on NFS to provide the input. > > in that case, let me suggest that you ask them by putting together > an email and sending it to nfsv4@ietf.org? > > Lars > _______________________________________________ > decade mailing list > decade@ietf.org > https://www.ietf.org/mailman/listinfo/decade From rpenno@juniper.net Thu Dec 17 11:20:24 2009 Return-Path: X-Original-To: decade@core3.amsl.com Delivered-To: decade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 486B728C129 for ; Thu, 17 Dec 2009 11:20:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aPMgYh3sYwmC for ; Thu, 17 Dec 2009 11:20:22 -0800 (PST) Received: from exprod7og115.obsmtp.com (exprod7og115.obsmtp.com [64.18.2.217]) by core3.amsl.com (Postfix) with SMTP id 9C22D3A69F8 for ; Thu, 17 Dec 2009 11:20:14 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob115.postini.com ([64.18.6.12]) with SMTP ID DSNKSyqEWQgAMNvNAzPGj86rZWvJuiAi8K5d@postini.com; Thu, 17 Dec 2009 11:20:07 PST Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.1.393.1; Thu, 17 Dec 2009 11:16:10 -0800 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Thu, 17 Dec 2009 14:16:09 -0500 From: Reinaldo Penno To: Song Haibin , 'Yong Lucy' , "decade@ietf.org" Date: Thu, 17 Dec 2009 14:16:05 -0500 Thread-Topic: [decade] scope discussion Thread-Index: Acp6ERATHoC5nsRERPewL+zbG01A+QC5cXKQAHHoeiAAI7pOBA== Message-ID: In-Reply-To: <000001ca7ec2$680a6f70$180ca40a@china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.0.0.090609 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [decade] scope discussion 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, 17 Dec 2009 19:20:24 -0000 I'm not an expert on NFS by any means (know some WebDAV) but I would like t= o discuss the feasibility of these protocols and any other from a different point of view. A few points. * Since this protocol will be hopefully implemented by many different P2P clients that run on top of many different OSes, I would venture to say that the chances that any application layer protocol will be embraced has do with: 1 - Reusability: If it manages to reuse software already present in the clients it gets bonus points. For example, many P2P clients already have HTTP in it. 1.1 - Some smart phones such as iPhone SDK also have well-defined HTTP APIs. 2 - Socket API: Capability of relying only on the well-defined simple socket APIs instead of expecting say, NFS, to be in the kernel. I know that you could implement NFS in user space, but that goes to point 3 below 3 - Avoiding Code bloating: Many of these P2P clients have a really low footprint requirement even when installed on PCs and would have even more strict requirements when present on Smart Phones. Thanks, Reinaldo On 12/16/09 6:41 PM, "Song Haibin" wrote: > Hi Lucy, >=20 > Thanks for your reply. Sorry for the late reply because I'm very busy the= se > days. Please see inline. >=20 >> -----Original Message----- >> From: Yong Lucy [mailto:lucyyong@huawei.com] >> Sent: Tuesday, December 15, 2009 4:26 AM >> To: 'Song Haibin'; decade@ietf.org >> Subject: RE: [decade] scope discussion >>=20 >> I studied NFS WG work a bit. NFS works on remote direct >> memory access (RDMA) protocol that allows remote memory >> access operation. The protocol works in RPC based >> architecture. IAP protocol includes read/write protocol for >> in-network storage access. IAP may be able to use RDAM for >> read/write operation. >=20 > I am sorry that I know little about RDMA, maybe some experts on NFS could > provide good comments here. IMHO, there are many kinds of contents could = be > transferred between client and in-network storage. For real-time or > near-real-time media, RTP/RTCP might be used for the transport. For > non-real-time data, you might use HTTP or other standard protocol (might = be > RDMA?) for the transport. That's why I suggest IAP should not include the > read/write protocol itself but instead the negotiation of transport proto= col > underline. However, comments from NFS experts would be very appreciated. >=20 >> The question is that if DECADE >> architecture has to use client/server architecture. >>=20 >=20 > IMO, yes. What's in your mind? > =20 >>=20 >> IAP also needs the protocol to pass the in-network storage >> access reference and authority to other peers or in-network >> storage itself so that the peers or the storage can use the >> references to perform the read/write actions over in-network >> storage. I don't see this work under NFS WG scope. >>=20 > This is related to access control and resource control. P2P applications > clients usually have the resource control and access control locally, but > now they have their contents in the network core, so they need to have th= e > ability ( with IAP) to control the resource allocation and sharing polici= es > for their contents in the in-network storage. I don't think this is und= er > NFS scope. Any comments? >=20 >>=20 >> Not sure if DECADE work should include the protocol to help >> the negotiation of transport protocol underline. >>=20 >=20 > See above. =20 >=20 >>=20 >> Would like to see some experts on NFS to provide the input. >>=20 >> =20 > Me too. >=20 >=20 > BR, > Haibin >=20 >=20 >>=20 >> Regards, >>=20 >> Lucy=20 >>=20 >> =20 >>=20 >> =20 >>=20 >> =20 >>=20 >> ________________________________ >>=20 >> From: decade-bounces@ietf.org >> [mailto:decade-bounces@ietf.org] On Behalf Of Song Haibin >> Sent: Thursday, December 10, 2009 9:22 PM >> To: decade@ietf.org >> Subject: [decade] scope discussion >>=20 >> =20 >>=20 >> Dear all, >>=20 >> =20 >>=20 >> While many people in the meeting room at IETF 76 thought the >> problem was clear, and reasonable to solve, but not >> well-scoped (mainly about the in-network storage access >> protocol). I propose a few options for the protocol scope. >>=20 >> =20 >>=20 >> (1) A standard IAP protocol, which includes read/write & >> resource control. P2P client can use this protocol to upload >> contents to/download contents from the in-network storage, or >> send commands to its in-network storage on resource sharing >> policies with remote peers (bandwidth, connections, etc. ); >>=20 >> =20 >>=20 >> (2) A single standard read/write protocol. P2P client can >> use this protocol to upload contents to/download contents >> from the in-network storage. >>=20 >> =20 >>=20 >> (3) A resource control and transport negotiation protocol. We >> don't need to standardize the read/write protocol here, but >> P2P client can use this protocol to negotiate the necessary >> transport protocol for the content, and send commands to its >> in-network storage on resource sharing policies with remote >> peers (bandwidth, connections, etc. ); >>=20 >> =20 >>=20 >> For option (1) and (2), I think it might be a little harder >> to enable a single read/write protocol qualified to transport >> various kinds of contents, and there might be a little >> overlap with NFS/WebDAV. >>=20 >> =20 >>=20 >> How about limiting the IAP scope to option (3)? I think it is >> much cleaner and feasible to solve. >>=20 >> =20 >>=20 >> BR, >>=20 >> Haibin >>=20 >>=20 >=20 >=20 > _______________________________________________ > decade mailing list > decade@ietf.org > https://www.ietf.org/mailman/listinfo/decade From lin.xiao@nsn.com Thu Dec 17 22:04:47 2009 Return-Path: X-Original-To: decade@core3.amsl.com Delivered-To: decade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE7573A6A2C for ; Thu, 17 Dec 2009 22:04:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.714 X-Spam-Level: X-Spam-Status: No, score=-1.714 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ELWsmOgeFwoA for ; Thu, 17 Dec 2009 22:04:45 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by core3.amsl.com (Postfix) with ESMTP id 915213A6923 for ; Thu, 17 Dec 2009 22:04:43 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id nBI64KF8023306 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 18 Dec 2009 07:04:20 +0100 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id nBI64K97008138; Fri, 18 Dec 2009 07:04:20 +0100 Received: from CNBEEXC007.nsn-intra.net ([10.159.192.80]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 18 Dec 2009 07:04:19 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA7FA7.E31EC7BA" Date: Fri, 18 Dec 2009 14:03:57 +0800 Message-ID: <5D84FDD8D5DC8646B9F73CF1EFD1BFA4010A63D3@CNBEEXC007.nsn-intra.net> In-Reply-To: <00ab01ca7a11$10483200$180ca40a@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [decade] scope discussion Thread-Index: Acp6ERATHoC5nsRERPewL+zbG01A+QFlPKWg References: <00ab01ca7a11$10483200$180ca40a@china.huawei.com> From: "Xiao, Lin (NSN - CN/Beijing)" To: "ext Song Haibin" , X-OriginalArrivalTime: 18 Dec 2009 06:04:19.0967 (UTC) FILETIME=[F033C0F0:01CA7FA7] Subject: Re: [decade] scope discussion X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Dec 2009 06:04:47 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA7FA7.E31EC7BA Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Haibin, =20 I think I agree with your opinion. Option (1) and (2) are contents relevant.Most of the application themselves have their own ways to do the read/write thing. In order to make the Decade independent with the applications, we just need design a simple protocol to do the resource store and access control. That is to help setting up the contact between the peer and the in-network storage, maybe with the negotiation information about which protocol will be used for read/write the data. =20 =20 Br Xiao, Lin=20 ________________________________ From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.org] On Behalf Of ext Song Haibin Sent: Friday, December 11, 2009 11:22 AM To: decade@ietf.org Subject: [decade] scope discussion Dear all, =20 While many people in the meeting room at IETF 76 thought the problem was clear, and reasonable to solve, but not well-scoped (mainly about the in-network storage access protocol). I propose a few options for the protocol scope. =20 (1) A standard IAP protocol, which includes read/write & resource control. P2P client can use this protocol to upload contents to/download contents from the in-network storage, or send commands to its in-network storage on resource sharing policies with remote peers (bandwidth, connections, etc. ); =20 (2) A single standard read/write protocol. P2P client can use this protocol to upload contents to/download contents from the in-network storage. =20 (3) A resource control and transport negotiation protocol. We don't need to standardize the read/write protocol here, but P2P client can use this protocol to negotiate the necessary transport protocol for the content, and send commands to its in-network storage on resource sharing policies with remote peers (bandwidth, connections, etc. ); =20 For option (1) and (2), I think it might be a little harder to enable a single read/write protocol qualified to transport various kinds of contents, and there might be a little overlap with NFS/WebDAV.=20 =20 How about limiting the IAP scope to option (3)? I think it is much cleaner and feasible to solve. =20 BR, Haibin ------_=_NextPart_001_01CA7FA7.E31EC7BA Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Haibin,
 
I think I agree with your opinion. Option (1) and (2) = are contents=20 relevant.Most of the application themselves have their own ways to = do the=20 read/write thing. In order to make the Decade independent with = the=20 applications, we just need design a simple protocol to do the = resource=20 store and access control. That is to help setting up the=20 contact between the peer and the in-network storage, maybe = with the=20 negotiation information about which protocol will be used for read/write = the=20 data.
 
 
Br
Xiao, Lin 

From: decade-bounces@ietf.org=20 [mailto:decade-bounces@ietf.org] On Behalf Of ext Song=20 Haibin
Sent: Friday, December 11, 2009 11:22 AM
To:=20 decade@ietf.org
Subject: [decade] scope=20 discussion

Dear = all,
 
While many people = in the=20 meeting room at IETF 76 thought the problem was clear, and reasonable to = solve,=20 but not well-scoped (mainly about the in-network storage access=20 protocol). I propose a few options for the protocol=20 scope.
 
(1) A standard IAP = protocol,=20 which includes read/write & resource control. P2P client can use = this=20 protocol to upload contents to/download contents from the in-network = storage, or=20 send commands to its in-network storage on resource sharing = policies with=20 remote peers (bandwidth, connections, etc. );
 
(2) A single = standard=20 read/write protocol.  P2P client can use = this=20 protocol to upload contents to/download contents from the in-network=20 storage.
 
(3) A resource = control and=20 transport negotiation protocol. We don't need to standardize = the read/write=20 protocol here, but P2P client can use this protocol to negotiate the = necessary=20 transport protocol for the content, and send commands to its in-network = storage=20 on resource sharing policies with remote peers (bandwidth, = connections,=20 etc. );
 
For option (1) and = (2), I think=20 it might be a little harder to enable a single read/write protocol = qualified to=20 transport various kinds of contents, and there might be a = little=20 overlap with NFS/WebDAV.
 
How = about limiting the IAP=20 scope to option (3)? I think it is much cleaner and feasible to=20 solve.
 
BR,
Haibin
------_=_NextPart_001_01CA7FA7.E31EC7BA-- From melodysong@huawei.com Thu Dec 17 23:00:18 2009 Return-Path: X-Original-To: decade@core3.amsl.com Delivered-To: decade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE4883A69E0; Thu, 17 Dec 2009 23:00:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.025 X-Spam-Level: X-Spam-Status: No, score=-0.025 tagged_above=-999 required=5 tests=[AWL=0.470, 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 3MZhT5wHabh3; Thu, 17 Dec 2009 23:00:18 -0800 (PST) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id E68123A695F; Thu, 17 Dec 2009 23:00:17 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KUU00KZQ63SUJ@szxga04-in.huawei.com>; Fri, 18 Dec 2009 14:59:52 +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 <0KUU008KO63S7U@szxga04-in.huawei.com>; Fri, 18 Dec 2009 14:59:52 +0800 (CST) Received: from s64081a ([10.164.12.24]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KUU0043Z63PKB@szxml04-in.huawei.com>; Fri, 18 Dec 2009 14:59:52 +0800 (CST) Date: Fri, 18 Dec 2009 14:59:49 +0800 From: Song Haibin In-reply-to: To: 'Spencer Shepler' , 'Lars Eggert' Message-id: <00dc01ca7faf$b0baffd0$180ca40a@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: Acp/JDNRAJ7Y7hnkReWPpOyS7gZKLQAan/Xg Cc: decade@ietf.org, nfsv4@ietf.org Subject: Re: [decade] scope discussion X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Dec 2009 07:00:19 -0000 Hi Spencer, Very glad to hear from you. And thank Lars for the suggestion, so I also copied this email to nfsv4@ietf.org. I would like to copy it to WebDAV mailing list too, but I do not know the address : ( I think I should introduce some background. Please refer to this wiki page for the initial charter proposal for DECADE BOF at IETF 76. http://trac.tools.ietf.org/bof/trac/wiki/decade The feedback from the BOF is that there might be some overlap between the IAP protocol and NFS/WebDAV. So I sent an email to do scope discussion. Please refer to http://www.ietf.org/mail-archive/web/decade/current/msg00106.html and replied by Lucy, http://www.ietf.org/mail-archive/web/decade/current/msg00107.html, Reinaldo http://www.ietf.org/mail-archive/web/decade/current/msg00111.html and Xiao Lin http://www.ietf.org/mail-archive/web/decade/current/msg00112.html. So we want to continue the discussion, and let NFS & WebDAV experts to comment on list to see if there is any overlap, and to see if the new proposed IAP scope is reasonable and can avoid this kind of overlap. Xie Xie, Haibin > -----Original Message----- > From: decade-bounces@ietf.org > [mailto:decade-bounces@ietf.org ] On Behalf Of Spencer Shepler > Sent: Thursday, December 17, 2009 10:20 PM > To: Lars Eggert > Cc: decade@ietf.org > Subject: Re: [decade] scope discussion > > > I can help. I have been lurking but apologize that I haven't > been following closely enough to know the specific question(s). > > Spencer > > > > On Dec 17, 2009, at 12:41 AM, Lars Eggert > wrote: > > > Hi, > > > > On 2009-12-14, at 22:25, Yong Lucy wrote: > >> Would like to see some experts on NFS to provide the input. > > > > in that case, let me suggest that you ask them by putting > together an > > email and sending it to nfsv4@ietf.org? > > > > Lars > > _______________________________________________ > > 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 melodysong@huawei.com Thu Dec 17 23:10:52 2009 Return-Path: X-Original-To: decade@core3.amsl.com Delivered-To: decade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 76C7F3A69C7; Thu, 17 Dec 2009 23:10:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.059 X-Spam-Level: X-Spam-Status: No, score=-0.059 tagged_above=-999 required=5 tests=[AWL=0.436, 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 OjofaphI56CG; Thu, 17 Dec 2009 23:10:51 -0800 (PST) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 6440D3A67B8; Thu, 17 Dec 2009 23:10:51 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KUU00JE36LE6A@szxga04-in.huawei.com>; Fri, 18 Dec 2009 15:10:26 +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 <0KUU00CGW6LEIB@szxga04-in.huawei.com>; Fri, 18 Dec 2009 15:10:26 +0800 (CST) Received: from s64081a ([10.164.12.24]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KUU00D2O6LAX5@szxml06-in.huawei.com>; Fri, 18 Dec 2009 15:10:26 +0800 (CST) Date: Fri, 18 Dec 2009 15:10:22 +0800 From: Song Haibin In-reply-to: <00dc01ca7faf$b0baffd0$180ca40a@china.huawei.com> To: 'Spencer Shepler' , 'Lars Eggert' Message-id: <00e301ca7fb1$2a576530$180ca40a@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: Acp/JDNRAJ7Y7hnkReWPpOyS7gZKLQAan/XgAAh8KJA= Cc: decade@ietf.org, nfsv4@ietf.org Subject: Re: [decade] scope discussion X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Dec 2009 07:10:52 -0000 Hi Spencer, I just missed DECADE BOF meeting minutes at IETF 76. I don't know if you need it to have a better understanding of the background. The link is announced by Rich Woundy two weeks ago and you can find it below. http://www.ietf.org/proceedings/09nov/minutes/decade.txt Thank you very much. Haibin > -----Original Message----- > From: decade-bounces@ietf.org > [mailto:decade-bounces@ietf.org] On Behalf Of Song Haibin > Sent: Friday, December 18, 2009 3:00 PM > To: 'Spencer Shepler'; 'Lars Eggert' > Cc: decade@ietf.org; nfsv4@ietf.org > Subject: Re: [decade] scope discussion > > Hi Spencer, > > Very glad to hear from you. And thank Lars for the > suggestion, so I also copied this email to nfsv4@ietf.org. I > would like to copy it to WebDAV mailing list too, but I do > not know the address : ( > > I think I should introduce some background. Please refer to > this wiki page for the initial charter proposal for DECADE > BOF at IETF 76. > http://trac.tools.ietf.org/bof/trac/wiki/decade > > The feedback from the BOF is that there might be some overlap > between the IAP protocol and NFS/WebDAV. So I sent an email > to do scope discussion. > Please refer to > http://www.ietf.org/mail-archive/web/decade/current/msg00106.h > tml and replied by Lucy, > http://www.ietf.org/mail-archive/web/decade/current/msg00107.h > tml, Reinaldo > http://www.ietf.org/mail-archive/web/decade/current/msg00111.h > tml and Xiao Lin > http://www.ietf.org/mail-archive/web/decade/current/msg00112.html. > > So we want to continue the discussion, and let NFS & WebDAV > experts to comment on list to see if there is any overlap, > and to see if the new proposed IAP scope is reasonable and > can avoid this kind of overlap. > > > Xie Xie, > Haibin > > > > -----Original Message----- > > From: decade-bounces@ietf.org > > [mailto:decade-bounces@ietf.org > ] On > Behalf Of Spencer Shepler > > Sent: Thursday, December 17, 2009 10:20 PM > > To: Lars Eggert > > Cc: decade@ietf.org > > Subject: Re: [decade] scope discussion > > > > > > I can help. I have been lurking but apologize that I haven't been > > following closely enough to know the specific question(s). > > > > Spencer > > > > > > > > On Dec 17, 2009, at 12:41 AM, Lars Eggert > > wrote: > > > > > Hi, > > > > > > On 2009-12-14, at 22:25, Yong Lucy wrote: > > >> Would like to see some experts on NFS to provide the input. > > > > > > in that case, let me suggest that you ask them by putting > > together an > > > email and sending it to nfsv4@ietf.org? > > > > > > Lars > > > _______________________________________________ > > > 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 > > > > > > > _______________________________________________ > decade mailing list > decade@ietf.org > https://www.ietf.org/mailman/listinfo/decade > From richard_woundy@cable.comcast.com Fri Dec 18 13:40:31 2009 Return-Path: X-Original-To: decade@core3.amsl.com Delivered-To: decade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 443123A68EB; Fri, 18 Dec 2009 13:40:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.92 X-Spam-Level: X-Spam-Status: No, score=-0.92 tagged_above=-999 required=5 tests=[AWL=-0.457, 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 6Bm5cm3ZI2Bi; Fri, 18 Dec 2009 13:40:30 -0800 (PST) Received: from paoakoavas10.cable.comcast.com (paoakoavas10.cable.comcast.com [208.17.35.59]) by core3.amsl.com (Postfix) with ESMTP id 29E3A3A68C2; Fri, 18 Dec 2009 13:40:30 -0800 (PST) Received: from ([24.40.15.92]) by paoakoavas10.cable.comcast.com with ESMTP id KP-TDCH7.74830615; Fri, 18 Dec 2009 16:39:54 -0500 Received: from PACDCEXCMB06.cable.comcast.com ([24.40.15.22]) by PACDCEXCSMTP03.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 18 Dec 2009 16:39:55 -0500 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: Fri, 18 Dec 2009 16:39:54 -0500 Message-ID: <8A82D1BFEDDE7E4597978355239BBBCB9C83F9@PACDCEXCMB06.cable.comcast.com> In-Reply-To: <00e301ca7fb1$2a576530$180ca40a@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [decade] scope discussion Thread-Index: Acp/JDNRAJ7Y7hnkReWPpOyS7gZKLQAan/XgAAh8KJAAHgrzIA== References: <00dc01ca7faf$b0baffd0$180ca40a@china.huawei.com> <00e301ca7fb1$2a576530$180ca40a@china.huawei.com> From: "Woundy, Richard" To: "Song Haibin" , "Spencer Shepler" , "Lars Eggert" X-OriginalArrivalTime: 18 Dec 2009 21:39:55.0017 (UTC) FILETIME=[A34C9F90:01CA802A] Cc: decade@ietf.org, nfsv4@ietf.org Subject: Re: [decade] scope discussion X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Dec 2009 21:40:31 -0000 One other potentially useful document is the most recent "DECADE Requirements" draft, just updated this week: This draft still assumes the original scope of the DECADE effort, but it would still be useful to compare these requirements against the capabilities of existing protocols, particularly NFS. -- Rich P.S. All of the DECADE BOF proceedings can be found here: . -----Original Message----- From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.org] On Behalf Of Song Haibin Sent: Friday, December 18, 2009 2:10 AM To: 'Spencer Shepler'; 'Lars Eggert' Cc: decade@ietf.org; nfsv4@ietf.org Subject: Re: [decade] scope discussion Hi Spencer, I just missed DECADE BOF meeting minutes at IETF 76. I don't know if you need it to have a better understanding of the background. The link is announced by Rich Woundy two weeks ago and you can find it below.=20 http://www.ietf.org/proceedings/09nov/minutes/decade.txt Thank you very much. Haibin =20 > -----Original Message----- > From: decade-bounces@ietf.org=20 > [mailto:decade-bounces@ietf.org] On Behalf Of Song Haibin > Sent: Friday, December 18, 2009 3:00 PM > To: 'Spencer Shepler'; 'Lars Eggert' > Cc: decade@ietf.org; nfsv4@ietf.org > Subject: Re: [decade] scope discussion >=20 > Hi Spencer, >=20 > Very glad to hear from you. And thank Lars for the=20 > suggestion, so I also copied this email to nfsv4@ietf.org. I=20 > would like to copy it to WebDAV mailing list too, but I do=20 > not know the address : ( >=20 > I think I should introduce some background. Please refer to=20 > this wiki page for the initial charter proposal for DECADE=20 > BOF at IETF 76. > http://trac.tools.ietf.org/bof/trac/wiki/decade=20 >=20 > The feedback from the BOF is that there might be some overlap=20 > between the IAP protocol and NFS/WebDAV. So I sent an email=20 > to do scope discussion. > Please refer to > http://www.ietf.org/mail-archive/web/decade/current/msg00106.h > tml and replied by Lucy,=20 > http://www.ietf.org/mail-archive/web/decade/current/msg00107.h > tml, Reinaldo=20 > http://www.ietf.org/mail-archive/web/decade/current/msg00111.h > tml and Xiao Lin=20 > http://www.ietf.org/mail-archive/web/decade/current/msg00112.html. >=20 > So we want to continue the discussion, and let NFS & WebDAV=20 > experts to comment on list to see if there is any overlap,=20 > and to see if the new proposed IAP scope is reasonable and=20 > can avoid this kind of overlap. >=20 >=20 > Xie Xie, > Haibin >=20 >=20 > > -----Original Message----- > > From: decade-bounces@ietf.org > > [mailto:decade-bounces@ietf.org=20 > ] On > Behalf Of Spencer Shepler > > Sent: Thursday, December 17, 2009 10:20 PM > > To: Lars Eggert > > Cc: decade@ietf.org > > Subject: Re: [decade] scope discussion > > > > > > I can help. I have been lurking but apologize that I haven't been=20 > > following closely enough to know the specific question(s). > > > > Spencer > > > > > > > > On Dec 17, 2009, at 12:41 AM, Lars Eggert =20 > > wrote: > > > > > Hi, > > > > > > On 2009-12-14, at 22:25, Yong Lucy wrote: > > >> Would like to see some experts on NFS to provide the input. > > > > > > in that case, let me suggest that you ask them by putting > > together an > > > email and sending it to nfsv4@ietf.org? > > > > > > Lars > > > _______________________________________________ > > > decade mailing list > > > decade@ietf.org > > > https://www.ietf.org/mailman/listinfo/decade > =20 > > _______________________________________________ > > decade mailing list > > decade@ietf.org > > https://www.ietf.org/mailman/listinfo/decade > =20 > >=20 >=20 >=20 >=20 > _______________________________________________ > decade mailing list > decade@ietf.org > https://www.ietf.org/mailman/listinfo/decade >=20 _______________________________________________ decade mailing list decade@ietf.org https://www.ietf.org/mailman/listinfo/decade From melodysong@huawei.com Mon Dec 21 00:36:51 2009 Return-Path: X-Original-To: decade@core3.amsl.com Delivered-To: decade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D7063A68A7 for ; Mon, 21 Dec 2009 00:36:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.094 X-Spam-Level: * X-Spam-Status: No, score=1.094 tagged_above=-999 required=5 tests=[AWL=-0.825, BAYES_40=-0.185, 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 SVvLT-xg8hY4 for ; Mon, 21 Dec 2009 00:36:50 -0800 (PST) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 03DE03A689B for ; Mon, 21 Dec 2009 00:36:50 -0800 (PST) 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 <0KUZ00I4WTVOZ7@szxga03-in.huawei.com> for decade@ietf.org; Mon, 21 Dec 2009 16:21:24 +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 <0KUZ00HYQTVOAW@szxga03-in.huawei.com> for decade@ietf.org; Mon, 21 Dec 2009 16:21:24 +0800 (CST) Received: from s64081a ([10.164.12.24]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KUZ00CQJTVKAD@szxml06-in.huawei.com> for decade@ietf.org; Mon, 21 Dec 2009 16:21:24 +0800 (CST) Date: Mon, 21 Dec 2009 16:21:20 +0800 From: Song Haibin In-reply-to: To: 'Reinaldo Penno' , 'Yong Lucy' , decade@ietf.org Message-id: <009f01ca8216$93545770$180ca40a@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: Acp6ERATHoC5nsRERPewL+zbG01A+QC5cXKQAHHoeiAAI7pOBACxaf1A Subject: Re: [decade] scope discussion 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, 21 Dec 2009 08:36:51 -0000 Hi Reinaldo, These are very good general requirements to the protocol design. I think HTTP could be a good candiate protocol for the signaling between P2P client and in-network storage to do resource control and some negotiation. We should not tie closely to a specific complicated file system, which will make the scalability a big problem. Haibin > -----Original Message----- > From: Reinaldo Penno [mailto:rpenno@juniper.net] > Sent: Friday, December 18, 2009 3:16 AM > To: Song Haibin; 'Yong Lucy'; decade@ietf.org > Subject: Re: [decade] scope discussion > > I'm not an expert on NFS by any means (know some WebDAV) but > I would like to discuss the feasibility of these protocols > and any other from a different point of view. A few points. > > * Since this protocol will be hopefully implemented by many > different P2P clients that run on top of many different OSes, > I would venture to say that the chances that any application > layer protocol will be embraced has do > with: > > 1 - Reusability: If it manages to reuse software already > present in the clients it gets bonus points. For example, > many P2P clients already have HTTP in it. > 1.1 - Some smart phones such as iPhone SDK also have > well-defined HTTP APIs. > 2 - Socket API: Capability of relying only on the > well-defined simple socket APIs instead of expecting say, > NFS, to be in the kernel. I know that you could implement NFS > in user space, but that goes to point 3 below > 3 - Avoiding Code bloating: Many of these P2P clients have > a really low footprint requirement even when installed on PCs > and would have even more strict requirements when present on > Smart Phones. > > Thanks, > > Reinaldo > > > On 12/16/09 6:41 PM, "Song Haibin" wrote: > > > Hi Lucy, > > > > Thanks for your reply. Sorry for the late reply because I'm > very busy > > these days. Please see inline. > > > >> -----Original Message----- > >> From: Yong Lucy [mailto:lucyyong@huawei.com] > >> Sent: Tuesday, December 15, 2009 4:26 AM > >> To: 'Song Haibin'; decade@ietf.org > >> Subject: RE: [decade] scope discussion > >> > >> I studied NFS WG work a bit. NFS works on remote direct > memory access > >> (RDMA) protocol that allows remote memory access operation. The > >> protocol works in RPC based architecture. IAP protocol includes > >> read/write protocol for in-network storage access. IAP may > be able to > >> use RDAM for read/write operation. > > > > I am sorry that I know little about RDMA, maybe some experts on NFS > > could provide good comments here. IMHO, there are many kinds of > > contents could be transferred between client and in-network > storage. > > For real-time or near-real-time media, RTP/RTCP might be > used for the > > transport. For non-real-time data, you might use HTTP or other > > standard protocol (might be > > RDMA?) for the transport. That's why I suggest IAP should > not include > > the read/write protocol itself but instead the negotiation of > > transport protocol underline. However, comments from NFS > experts would be very appreciated. > > > >> The question is that if DECADE > >> architecture has to use client/server architecture. > >> > > > > IMO, yes. What's in your mind? > > > >> > >> IAP also needs the protocol to pass the in-network storage access > >> reference and authority to other peers or in-network > storage itself > >> so that the peers or the storage can use the references to perform > >> the read/write actions over in-network storage. I don't > see this work > >> under NFS WG scope. > >> > > This is related to access control and resource control. P2P > > applications clients usually have the resource control and access > > control locally, but now they have their contents in the > network core, > > so they need to have the ability ( with IAP) to control the > resource allocation and sharing policies > > for their contents in the in-network storage. I don't > think this is under > > NFS scope. Any comments? > > > >> > >> Not sure if DECADE work should include the protocol to help the > >> negotiation of transport protocol underline. > >> > > > > See above. > > > >> > >> Would like to see some experts on NFS to provide the input. > >> > >> > > Me too. > > > > > > BR, > > Haibin > > > > > >> > >> Regards, > >> > >> Lucy > >> > >> > >> > >> > >> > >> > >> > >> ________________________________ > >> > >> From: decade-bounces@ietf.org > >> [mailto:decade-bounces@ietf.org] On Behalf Of Song Haibin > >> Sent: Thursday, December 10, 2009 9:22 PM > >> To: decade@ietf.org > >> Subject: [decade] scope discussion > >> > >> > >> > >> Dear all, > >> > >> > >> > >> While many people in the meeting room at IETF 76 thought > the problem > >> was clear, and reasonable to solve, but not well-scoped > (mainly about > >> the in-network storage access protocol). I propose a few > options for > >> the protocol scope. > >> > >> > >> > >> (1) A standard IAP protocol, which includes read/write & resource > >> control. P2P client can use this protocol to upload contents > >> to/download contents from the in-network storage, or send > commands to > >> its in-network storage on resource sharing policies with > remote peers > >> (bandwidth, connections, etc. ); > >> > >> > >> > >> (2) A single standard read/write protocol. P2P client can > use this > >> protocol to upload contents to/download contents from the > in-network > >> storage. > >> > >> > >> > >> (3) A resource control and transport negotiation protocol. > We don't > >> need to standardize the read/write protocol here, but P2P > client can > >> use this protocol to negotiate the necessary transport > protocol for > >> the content, and send commands to its in-network storage > on resource > >> sharing policies with remote peers (bandwidth, connections, etc. ); > >> > >> > >> > >> For option (1) and (2), I think it might be a little > harder to enable > >> a single read/write protocol qualified to transport > various kinds of > >> contents, and there might be a little overlap with NFS/WebDAV. > >> > >> > >> > >> How about limiting the IAP scope to option (3)? I think it is much > >> cleaner and feasible to solve. > >> > >> > >> > >> BR, > >> > >> Haibin > >> > >> > > > > > > _______________________________________________ > > decade mailing list > > decade@ietf.org > > https://www.ietf.org/mailman/listinfo/decade > > From lucyyong@huawei.com Mon Dec 28 14:04:49 2009 Return-Path: X-Original-To: decade@core3.amsl.com Delivered-To: decade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 33EE73A68FA for ; Mon, 28 Dec 2009 14:04:49 -0800 (PST) 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 OYzLNeKIuRHV for ; Mon, 28 Dec 2009 14:04:47 -0800 (PST) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 9D4A83A6862 for ; Mon, 28 Dec 2009 14:04:47 -0800 (PST) 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 <0KVD003BTUNFHK@szxga03-in.huawei.com> for decade@ietf.org; Tue, 29 Dec 2009 06:04:27 +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 <0KVD00IN4UNF7P@szxga03-in.huawei.com> for decade@ietf.org; Tue, 29 Dec 2009 06:04:27 +0800 (CST) Received: from y736742 ([10.124.12.75]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KVD009HJUN7ET@szxml04-in.huawei.com> for decade@ietf.org; Tue, 29 Dec 2009 06:04:26 +0800 (CST) Date: Mon, 28 Dec 2009 16:04:31 -0600 From: Yong Lucy In-reply-to: <009f01ca8216$93545770$180ca40a@china.huawei.com> To: 'Song Haibin' , 'Reinaldo Penno' , decade@ietf.org Message-id: <000301ca8809$bfa07e50$4b0c7c0a@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: Acp6ERATHoC5nsRERPewL+zbG01A+QC5cXKQAHHoeiAAI7pOBACxaf1AAXywYyA= References: <009f01ca8216$93545770$180ca40a@china.huawei.com> Subject: Re: [decade] scope discussion X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Dec 2009 22:04:49 -0000 Hi Haibin, I agree that HTTP could be a good candidate protocol between p2p client and in-network storage for resource control and remote storage access negotiation. This protocol should not tight to a specific file system or transport methods. >From the architecture perspective, in-network storage application architecture requires all these pieces coherently work together. It would be nice to have a framework document to specify the architecture and state where to apply the signaling protocol, where to hook on transport method, where to use storage access, and how they will work together for supporting the application. Then we may more clear that such signaling protocol is not addressed by either NFS or WebDAV and DECADE will just work on the signaling protocol part in the application. Cheers, Lucy > -----Original Message----- > From: Song Haibin [mailto:melodysong@huawei.com] > Sent: Monday, December 21, 2009 2:21 AM > To: 'Reinaldo Penno'; 'Yong Lucy'; decade@ietf.org > Subject: RE: [decade] scope discussion > > Hi Reinaldo, > > These are very good general requirements to the protocol design. I think > HTTP could be a good candiate protocol for the signaling between P2P > client > and in-network storage to do resource control and some negotiation. We > should not tie closely to a specific complicated file system, which will > make the scalability a big problem. > > Haibin > > > > -----Original Message----- > > From: Reinaldo Penno [mailto:rpenno@juniper.net] > > Sent: Friday, December 18, 2009 3:16 AM > > To: Song Haibin; 'Yong Lucy'; decade@ietf.org > > Subject: Re: [decade] scope discussion > > > > I'm not an expert on NFS by any means (know some WebDAV) but > > I would like to discuss the feasibility of these protocols > > and any other from a different point of view. A few points. > > > > * Since this protocol will be hopefully implemented by many > > different P2P clients that run on top of many different OSes, > > I would venture to say that the chances that any application > > layer protocol will be embraced has do > > with: > > > > 1 - Reusability: If it manages to reuse software already > > present in the clients it gets bonus points. For example, > > many P2P clients already have HTTP in it. > > 1.1 - Some smart phones such as iPhone SDK also have > > well-defined HTTP APIs. > > 2 - Socket API: Capability of relying only on the > > well-defined simple socket APIs instead of expecting say, > > NFS, to be in the kernel. I know that you could implement NFS > > in user space, but that goes to point 3 below > > 3 - Avoiding Code bloating: Many of these P2P clients have > > a really low footprint requirement even when installed on PCs > > and would have even more strict requirements when present on > > Smart Phones. > > > > Thanks, > > > > Reinaldo > > > > > > On 12/16/09 6:41 PM, "Song Haibin" wrote: > > > > > Hi Lucy, > > > > > > Thanks for your reply. Sorry for the late reply because I'm > > very busy > > > these days. Please see inline. > > > > > >> -----Original Message----- > > >> From: Yong Lucy [mailto:lucyyong@huawei.com] > > >> Sent: Tuesday, December 15, 2009 4:26 AM > > >> To: 'Song Haibin'; decade@ietf.org > > >> Subject: RE: [decade] scope discussion > > >> > > >> I studied NFS WG work a bit. NFS works on remote direct > > memory access > > >> (RDMA) protocol that allows remote memory access operation. The > > >> protocol works in RPC based architecture. IAP protocol includes > > >> read/write protocol for in-network storage access. IAP may > > be able to > > >> use RDAM for read/write operation. > > > > > > I am sorry that I know little about RDMA, maybe some experts on NFS > > > could provide good comments here. IMHO, there are many kinds of > > > contents could be transferred between client and in-network > > storage. > > > For real-time or near-real-time media, RTP/RTCP might be > > used for the > > > transport. For non-real-time data, you might use HTTP or other > > > standard protocol (might be > > > RDMA?) for the transport. That's why I suggest IAP should > > not include > > > the read/write protocol itself but instead the negotiation of > > > transport protocol underline. However, comments from NFS > > experts would be very appreciated. > > > > > >> The question is that if DECADE > > >> architecture has to use client/server architecture. > > >> > > > > > > IMO, yes. What's in your mind? > > > > > >> > > >> IAP also needs the protocol to pass the in-network storage access > > >> reference and authority to other peers or in-network > > storage itself > > >> so that the peers or the storage can use the references to perform > > >> the read/write actions over in-network storage. I don't > > see this work > > >> under NFS WG scope. > > >> > > > This is related to access control and resource control. P2P > > > applications clients usually have the resource control and access > > > control locally, but now they have their contents in the > > network core, > > > so they need to have the ability ( with IAP) to control the > > resource allocation and sharing policies > > > for their contents in the in-network storage. I don't > > think this is under > > > NFS scope. Any comments? > > > > > >> > > >> Not sure if DECADE work should include the protocol to help the > > >> negotiation of transport protocol underline. > > >> > > > > > > See above. > > > > > >> > > >> Would like to see some experts on NFS to provide the input. > > >> > > >> > > > Me too. > > > > > > > > > BR, > > > Haibin > > > > > > > > >> > > >> Regards, > > >> > > >> Lucy > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> ________________________________ > > >> > > >> From: decade-bounces@ietf.org > > >> [mailto:decade-bounces@ietf.org] On Behalf Of Song Haibin > > >> Sent: Thursday, December 10, 2009 9:22 PM > > >> To: decade@ietf.org > > >> Subject: [decade] scope discussion > > >> > > >> > > >> > > >> Dear all, > > >> > > >> > > >> > > >> While many people in the meeting room at IETF 76 thought > > the problem > > >> was clear, and reasonable to solve, but not well-scoped > > (mainly about > > >> the in-network storage access protocol). I propose a few > > options for > > >> the protocol scope. > > >> > > >> > > >> > > >> (1) A standard IAP protocol, which includes read/write & resource > > >> control. P2P client can use this protocol to upload contents > > >> to/download contents from the in-network storage, or send > > commands to > > >> its in-network storage on resource sharing policies with > > remote peers > > >> (bandwidth, connections, etc. ); > > >> > > >> > > >> > > >> (2) A single standard read/write protocol. P2P client can > > use this > > >> protocol to upload contents to/download contents from the > > in-network > > >> storage. > > >> > > >> > > >> > > >> (3) A resource control and transport negotiation protocol. > > We don't > > >> need to standardize the read/write protocol here, but P2P > > client can > > >> use this protocol to negotiate the necessary transport > > protocol for > > >> the content, and send commands to its in-network storage > > on resource > > >> sharing policies with remote peers (bandwidth, connections, etc. ); > > >> > > >> > > >> > > >> For option (1) and (2), I think it might be a little > > harder to enable > > >> a single read/write protocol qualified to transport > > various kinds of > > >> contents, and there might be a little overlap with NFS/WebDAV. > > >> > > >> > > >> > > >> How about limiting the IAP scope to option (3)? I think it is much > > >> cleaner and feasible to solve. > > >> > > >> > > >> > > >> BR, > > >> > > >> Haibin > > >> > > >> > > > > > > > > > _______________________________________________ > > > decade mailing list > > > decade@ietf.org > > > https://www.ietf.org/mailman/listinfo/decade > > > > From melodysong@huawei.com Wed Dec 30 00:16:10 2009 Return-Path: X-Original-To: decade@core3.amsl.com Delivered-To: decade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D8E33A67A3 for ; Wed, 30 Dec 2009 00:16:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.898 X-Spam-Level: X-Spam-Status: No, score=0.898 tagged_above=-999 required=5 tests=[AWL=-0.466, BAYES_20=-0.74, 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 mNTxpym-pD6W for ; Wed, 30 Dec 2009 00:16:09 -0800 (PST) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 9F46C3A67DD for ; Wed, 30 Dec 2009 00:16:08 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KVG00CJCHLA2C@szxga04-in.huawei.com> for decade@ietf.org; Wed, 30 Dec 2009 16:15:10 +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 <0KVG006PTHLAVA@szxga04-in.huawei.com> for decade@ietf.org; Wed, 30 Dec 2009 16:15:10 +0800 (CST) Received: from s64081a ([10.164.12.24]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KVG00M7HHL69R@szxml06-in.huawei.com> for decade@ietf.org; Wed, 30 Dec 2009 16:15:10 +0800 (CST) Date: Wed, 30 Dec 2009 16:15:06 +0800 From: Song Haibin In-reply-to: <000301ca8809$bfa07e50$4b0c7c0a@china.huawei.com> To: 'Yong Lucy' , 'Reinaldo Penno' , decade@ietf.org Message-id: <004601ca8928$3235bc40$180ca40a@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: Acp6ERATHoC5nsRERPewL+zbG01A+QC5cXKQAHHoeiAAI7pOBACxaf1AAXywYyAASBOcMA== Subject: Re: [decade] scope discussion 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, 30 Dec 2009 08:16:10 -0000 Hi Lucy, > -----Original Message----- > From: Yong Lucy [mailto:lucyyong@huawei.com] > Sent: Tuesday, December 29, 2009 6:05 AM > To: 'Song Haibin'; 'Reinaldo Penno'; decade@ietf.org > Subject: RE: [decade] scope discussion > > Hi Haibin, > > I agree that HTTP could be a good candidate protocol between > p2p client and in-network storage for resource control and > remote storage access negotiation. This protocol should not > tight to a specific file system or transport methods. > Yes. IMO, resource control also includes access control and authorization. But developping the transport protocol itself will be excluded. > From the architecture perspective, in-network storage > application architecture requires all these pieces coherently > work together. It would be nice to have a framework document > to specify the architecture and state where to apply the > signaling protocol, where to hook on transport method, where > to use storage access, and how they will work together for > supporting the application. Then we may more clear that such > signaling protocol is not addressed by either NFS or WebDAV > and DECADE will just work on the signaling protocol part in > the application. Good, we will update the problem statement draft to specify that. Actually in Section 4 and section 5 of the problem statement draft, we already have something about the architecture and usage scenarios. But we will specify the differences of signaling protocol and transport methods in the next revision. Thank you for the good suggestion. BR, Haibin > > Cheers, > Lucy > > > -----Original Message----- > > From: Song Haibin [mailto:melodysong@huawei.com] > > Sent: Monday, December 21, 2009 2:21 AM > > To: 'Reinaldo Penno'; 'Yong Lucy'; decade@ietf.org > > Subject: RE: [decade] scope discussion > > > > Hi Reinaldo, > > > > These are very good general requirements to the protocol design. I > > think HTTP could be a good candiate protocol for the > signaling between > > P2P client and in-network storage to do resource control and some > > negotiation. We should not tie closely to a specific > complicated file > > system, which will make the scalability a big problem. > > > > Haibin > > > > > > > -----Original Message----- > > > From: Reinaldo Penno [mailto:rpenno@juniper.net] > > > Sent: Friday, December 18, 2009 3:16 AM > > > To: Song Haibin; 'Yong Lucy'; decade@ietf.org > > > Subject: Re: [decade] scope discussion > > > > > > I'm not an expert on NFS by any means (know some WebDAV) > but I would > > > like to discuss the feasibility of these protocols and any other > > > from a different point of view. A few points. > > > > > > * Since this protocol will be hopefully implemented by many > > > different P2P clients that run on top of many different OSes, I > > > would venture to say that the chances that any application layer > > > protocol will be embraced has do > > > with: > > > > > > 1 - Reusability: If it manages to reuse software > already present > > > in the clients it gets bonus points. For example, many > P2P clients > > > already have HTTP in it. > > > 1.1 - Some smart phones such as iPhone SDK also have > well-defined > > > HTTP APIs. > > > 2 - Socket API: Capability of relying only on the well-defined > > > simple socket APIs instead of expecting say, NFS, to be in the > > > kernel. I know that you could implement NFS in user > space, but that > > > goes to point 3 below > > > 3 - Avoiding Code bloating: Many of these P2P clients have a > > > really low footprint requirement even when installed on PCs and > > > would have even more strict requirements when present on Smart > > > Phones. > > > > > > Thanks, > > > > > > Reinaldo > > > > > > > > > On 12/16/09 6:41 PM, "Song Haibin" wrote: > > > > > > > Hi Lucy, > > > > > > > > Thanks for your reply. Sorry for the late reply because I'm > > > very busy > > > > these days. Please see inline. > > > > > > > >> -----Original Message----- > > > >> From: Yong Lucy [mailto:lucyyong@huawei.com] > > > >> Sent: Tuesday, December 15, 2009 4:26 AM > > > >> To: 'Song Haibin'; decade@ietf.org > > > >> Subject: RE: [decade] scope discussion > > > >> > > > >> I studied NFS WG work a bit. NFS works on remote direct > > > memory access > > > >> (RDMA) protocol that allows remote memory access > operation. The > > > >> protocol works in RPC based architecture. IAP protocol > includes > > > >> read/write protocol for in-network storage access. IAP may > > > be able to > > > >> use RDAM for read/write operation. > > > > > > > > I am sorry that I know little about RDMA, maybe some experts on > > > > NFS could provide good comments here. IMHO, there are > many kinds > > > > of contents could be transferred between client and in-network > > > storage. > > > > For real-time or near-real-time media, RTP/RTCP might be > > > used for the > > > > transport. For non-real-time data, you might use HTTP or other > > > > standard protocol (might be > > > > RDMA?) for the transport. That's why I suggest IAP should > > > not include > > > > the read/write protocol itself but instead the negotiation of > > > > transport protocol underline. However, comments from NFS > > > experts would be very appreciated. > > > > > > > >> The question is that if DECADE > > > >> architecture has to use client/server architecture. > > > >> > > > > > > > > IMO, yes. What's in your mind? > > > > > > > >> > > > >> IAP also needs the protocol to pass the in-network > storage access > > > >> reference and authority to other peers or in-network > > > storage itself > > > >> so that the peers or the storage can use the references to > > > >> perform the read/write actions over in-network storage. I don't > > > see this work > > > >> under NFS WG scope. > > > >> > > > > This is related to access control and resource control. P2P > > > > applications clients usually have the resource control > and access > > > > control locally, but now they have their contents in the > > > network core, > > > > so they need to have the ability ( with IAP) to control the > > > resource allocation and sharing policies > > > > for their contents in the in-network storage. I don't > > > think this is under > > > > NFS scope. Any comments? > > > > > > > >> > > > >> Not sure if DECADE work should include the protocol to > help the > > > >> negotiation of transport protocol underline. > > > >> > > > > > > > > See above. > > > > > > > >> > > > >> Would like to see some experts on NFS to provide the input. > > > >> > > > >> > > > > Me too. > > > > > > > > > > > > BR, > > > > Haibin > > > > > > > > > > > >> > > > >> Regards, > > > >> > > > >> Lucy > > > >> > > > >> > > > >> > > > >> > > > >> > > > >> > > > >> > > > >> ________________________________ > > > >> > > > >> From: decade-bounces@ietf.org > > > >> [mailto:decade-bounces@ietf.org] On Behalf Of Song Haibin > > > >> Sent: Thursday, December 10, 2009 9:22 PM > > > >> To: decade@ietf.org > > > >> Subject: [decade] scope discussion > > > >> > > > >> > > > >> > > > >> Dear all, > > > >> > > > >> > > > >> > > > >> While many people in the meeting room at IETF 76 thought > > > the problem > > > >> was clear, and reasonable to solve, but not well-scoped > > > (mainly about > > > >> the in-network storage access protocol). I propose a few > > > options for > > > >> the protocol scope. > > > >> > > > >> > > > >> > > > >> (1) A standard IAP protocol, which includes read/write > & resource > > > >> control. P2P client can use this protocol to upload contents > > > >> to/download contents from the in-network storage, or send > > > commands to > > > >> its in-network storage on resource sharing policies with > > > remote peers > > > >> (bandwidth, connections, etc. ); > > > >> > > > >> > > > >> > > > >> (2) A single standard read/write protocol. P2P client can > > > use this > > > >> protocol to upload contents to/download contents from the > > > in-network > > > >> storage. > > > >> > > > >> > > > >> > > > >> (3) A resource control and transport negotiation protocol. > > > We don't > > > >> need to standardize the read/write protocol here, but P2P > > > client can > > > >> use this protocol to negotiate the necessary transport > > > protocol for > > > >> the content, and send commands to its in-network storage > > > on resource > > > >> sharing policies with remote peers (bandwidth, > connections, etc. > > > >> ); > > > >> > > > >> > > > >> > > > >> For option (1) and (2), I think it might be a little > > > harder to enable > > > >> a single read/write protocol qualified to transport > > > various kinds of > > > >> contents, and there might be a little overlap with NFS/WebDAV. > > > >> > > > >> > > > >> > > > >> How about limiting the IAP scope to option (3)? I think it is > > > >> much cleaner and feasible to solve. > > > >> > > > >> > > > >> > > > >> BR, > > > >> > > > >> Haibin > > > >> > > > >> > > > > > > > > > > > > _______________________________________________ > > > > decade mailing list > > > > decade@ietf.org > > > > https://www.ietf.org/mailman/listinfo/decade > > > > > > > > >