From iesg-secretary@ietf.org Wed Jul 6 14:44:27 2011 Return-Path: X-Original-To: decade@ietfa.amsl.com Delivered-To: decade@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED95821F8BB1; Wed, 6 Jul 2011 14:44:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.498 X-Spam-Level: X-Spam-Status: No, score=-102.498 tagged_above=-999 required=5 tests=[AWL=0.101, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w8PD8sHpqL9q; Wed, 6 Jul 2011 14:44:27 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8390121F8B93; Wed, 6 Jul 2011 14:44:27 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110706214427.3371.45943.idtracker@ietfa.amsl.com> Date: Wed, 06 Jul 2011 14:44:27 -0700 Cc: decade@ietf.org Subject: [decade] Last Call: (A Survey of In-network Storage Systems) to Informational RFC X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@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: Wed, 06 Jul 2011 21:44:28 -0000 The IESG has received a request from the Decoupled Application Data Enroute WG (decade) to consider the following document: - 'A Survey of In-network Storage Systems' as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-07-20. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document surveys deployed and experimental in-network storage systems and describes their applicability for DECADE. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-decade-survey/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-decade-survey/ No IPR declarations have been submitted directly on this I-D. From internet-drafts@ietf.org Mon Jul 11 15:20:17 2011 Return-Path: X-Original-To: decade@ietfa.amsl.com Delivered-To: decade@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 900C111E8334; Mon, 11 Jul 2011 15:20:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.587 X-Spam-Level: X-Spam-Status: No, score=-102.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bZkFIz41xpYq; Mon, 11 Jul 2011 15:20:17 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA40211E832B; Mon, 11 Jul 2011 15:20:16 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110711222016.26534.9282.idtracker@ietfa.amsl.com> Date: Mon, 11 Jul 2011 15:20:16 -0700 Cc: decade@ietf.org Subject: [decade] I-D Action: draft-ietf-decade-arch-02.txt X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2011 22:20:17 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Decoupled Application Data Enroute Wo= rking Group of the IETF. Title : DECADE Architecture Author(s) : Richard Alimi Y. Richard Yang Akbar Rahman Dirk Kutscher Hongqiang Liu Filename : draft-ietf-decade-arch-02.txt Pages : 40 Date : 2011-07-11 Content Distribution Applications (e.g., P2P applications) are widely used on the Internet and make up a large portion of the traffic in many networks. One technique to improve the network efficiency of these applications is to introduce storage capabilities within the networks. This document presents an architecture, discusses the underlying principles, and identifies core components and protocols for supporting in-network storage functionality for these applications. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-decade-arch-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-decade-arch-02.txt From internet-drafts@ietf.org Mon Jul 11 15:28:44 2011 Return-Path: X-Original-To: decade@ietfa.amsl.com Delivered-To: decade@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 071D111E833C; Mon, 11 Jul 2011 15:28:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.474 X-Spam-Level: X-Spam-Status: No, score=-102.474 tagged_above=-999 required=5 tests=[AWL=-0.102, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zQBZH+DM0cpB; Mon, 11 Jul 2011 15:28:43 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F2E421F8C53; Mon, 11 Jul 2011 15:28:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110711222843.30972.46226.idtracker@ietfa.amsl.com> Date: Mon, 11 Jul 2011 15:28:43 -0700 Cc: decade@ietf.org Subject: [decade] I-D Action: draft-ietf-decade-reqs-03.txt X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2011 22:28:44 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Decoupled Application Data Enroute Wo= rking Group of the IETF. Title : DECADE Requirements Author(s) : Yingjie Gu David A. Bryan Yang Richard Yang Richard Alimi Filename : draft-ietf-decade-reqs-03.txt Pages : 23 Date : 2011-07-11 The target of DECoupled Application Data Enroute (DECADE) is to provide an open and standard in-network storage system for applications, primarily P2P (peer-to-peer) applications, to store, retrieve and manage their data. This draft enumerates and explains requirements, not only for store and retrieve, but also for data management, access control and resource control, that should be considered during the design and implementation of a DECADE system. These are requirements on the entire system; some of the requirements may eventually be implemented by an existing protocol with/without some extensions (e.g., a protocol used to read and write data from the storage system). A user of DECADE as a complete architecture would be guaranteed complete functionality. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-decade-reqs-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-decade-reqs-03.txt From borje.ohlman@ericsson.com Wed Jul 13 02:53:59 2011 Return-Path: X-Original-To: decade@ietfa.amsl.com Delivered-To: decade@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C16E321F8AD3 for ; Wed, 13 Jul 2011 02:53:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F8JXIJPfTNAm for ; Wed, 13 Jul 2011 02:53:59 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id F25C421F8AD1 for ; Wed, 13 Jul 2011 02:53:58 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-61-4e1d6b353496 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id DE.28.20773.53B6D1E4; Wed, 13 Jul 2011 11:53:57 +0200 (CEST) Received: from dhcp-147-214-183-80.ki.sw.ericsson.se (153.88.115.8) by smtps.internal.ericsson.com (153.88.115.84) with Microsoft SMTP Server id 8.3.137.0; Wed, 13 Jul 2011 11:53:56 +0200 MIME-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset="iso-8859-1" From: =?iso-8859-1?Q?B=F6rje_Ohlman?= In-Reply-To: Date: Wed, 13 Jul 2011 11:53:56 +0200 Content-Transfer-Encoding: quoted-printable Message-ID: References: To: Songhaibin X-Mailer: Apple Mail (2.1084) X-Brightmail-Tracker: AAAAAA== Cc: "decade@ietf.org" Subject: Re: [decade] re-chartering X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2011 09:53:59 -0000 I think the items listed below are the main items for the next period. = Obviously the protocol issues are key things to complete. For the other = two I want to make the following comments. Regarding the naming scheme I want to promote the idea to select a = naming scheme that can be generally applicable to naming any type of = information objects and thus not making it DECADE specific. As was = mentioned at the last IETF there is a draft proposing one possible such = naming scheme, see http://datatracker.ietf.org/doc/draft-farrell-ni/ In the DECADE architecture draft it is proposed to use a hash of the = information object to name them. I support this idea and the naming = scheme proposed in our draft could definitely support such naming. It = might add a slight overhead compared with using a plain hash, but it = will add flexibility and possibility for future extensions. These = features could be useful if there is a need to change a comprised hash = algorithm in the future or for making DECADE work smoothly with other = future features provided by e.g. ALTO or CDNI. Regarding service discovery I think this is a very important issue that = is key for making it possible to use DECADE in scenarios where users and = hosts are roaming in the network. B=F6rje On 20 jun 2011, at 09.54, Songhaibin wrote: > Dear all, >=20 > As we began our discussion about re-chartering from last IETF meeting. = We would like to hear more thoughts and comments in the list. The topics = include but not limit to what we talked at last meeting. >=20 > 1. protocols > 2. Mandatory underlying protocol > 3. Mandatory naming scheme > 4. service discovery and etc. >=20 > What stuff should we work on in the next period in this WG in your = opinion? Any special consideration? >=20 > BR, > -Haibin and Rich > _______________________________________________ > decade mailing list > decade@ietf.org > https://www.ietf.org/mailman/listinfo/decade From haibin.song@huawei.com Wed Jul 13 18:58:58 2011 Return-Path: X-Original-To: decade@ietfa.amsl.com Delivered-To: decade@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E90B911E81E2 for ; Wed, 13 Jul 2011 18:58:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oB4OTkqkiVtG for ; Wed, 13 Jul 2011 18:58:58 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 57C2211E81D2 for ; Wed, 13 Jul 2011 18:58:58 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LOA00LE9W40SC@szxga05-in.huawei.com> for decade@ietf.org; Thu, 14 Jul 2011 09:57:37 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LOA002AOW3OG2@szxga05-in.huawei.com> for decade@ietf.org; Thu, 14 Jul 2011 09:57:36 +0800 (CST) Received: from 172.24.2.119 (EHLO szxeml207-edg.china.huawei.com) ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA FastPath queued) with ESMTP id ACE87119; Thu, 14 Jul 2011 09:57:36 +0800 (CST) Received: from SZXEML408-HUB.china.huawei.com (10.82.67.95) by szxeml207-edg.china.huawei.com (172.24.2.59) with Microsoft SMTP Server (TLS) id 14.1.270.1; Thu, 14 Jul 2011 09:57:31 +0800 Received: from SZXEML524-MBX.china.huawei.com ([169.254.4.58]) by szxeml408-hub.china.huawei.com ([169.254.27.188]) with mapi id 14.01.0270.001; Thu, 14 Jul 2011 09:57:36 +0800 Date: Thu, 14 Jul 2011 01:57:35 +0000 From: Songhaibin X-Originating-IP: [10.138.41.119] To: "decade@ietf.org" Message-id: MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: zh-CN Content-transfer-encoding: 7BIT Accept-Language: en-US, zh-CN Thread-topic: Agenda request for IETF 81 Thread-index: AcxByWYjuQ6LCXgDQF+AlnU9soBjKQ== X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected Subject: [decade] Agenda request for IETF 81 X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jul 2011 01:58:59 -0000 Dear all, If you would like to get a slot in the DECADE meeting at IETF 81, please send the chairs a request by next Monday, July 18. And please also send the slides to the chairs by next Friday, July 22. Sorry for sending this out late. BR -Haibin From richard_woundy@cable.comcast.com Thu Jul 14 08:20:39 2011 Return-Path: X-Original-To: decade@ietfa.amsl.com Delivered-To: decade@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73CD821F85E0 for ; Thu, 14 Jul 2011 08:20:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.463 X-Spam-Level: X-Spam-Status: No, score=-108.463 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5s3LFZIMPkxf for ; Thu, 14 Jul 2011 08:20:38 -0700 (PDT) Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by ietfa.amsl.com (Postfix) with ESMTP id 1877621F8C8D for ; Thu, 14 Jul 2011 08:20:29 -0700 (PDT) Received: from ([24.40.55.41]) by pacdcimo01.cable.comcast.com with ESMTP with TLS id 5503620.134097848; Thu, 14 Jul 2011 11:20:21 -0400 Received: from PACDCEXMB05.cable.comcast.com ([fe80::a5b0:e5c4:df1b:2367]) by PACDCEXHUB02.cable.comcast.com ([fe80::11d4:f530:37a0:9f4e%12]) with mapi id 14.01.0289.001; Thu, 14 Jul 2011 11:20:20 -0400 From: "Woundy, Richard" To: Songhaibin , "decade@ietf.org" Thread-Topic: Agenda request for IETF 81 Thread-Index: AcxByWYjuQ6LCXgDQF+AlnU9soBjKQAcA0Bg Date: Thu, 14 Jul 2011 15:20:19 +0000 Message-ID: <1CA25301D2219F40B3AA37201F0EACD1135CB662@PACDCEXMB05.cable.comcast.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.191.223.245] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [decade] Agenda request for IETF 81 X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jul 2011 15:20:39 -0000 Thanks Haibin. Here is a link to the current proposed agenda: -- Rich -----Original Message----- From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.org] On Behalf Of= Songhaibin Sent: Wednesday, July 13, 2011 9:58 PM To: decade@ietf.org Subject: [decade] Agenda request for IETF 81 Dear all, If you would like to get a slot in the DECADE meeting at IETF 81, please se= nd the chairs a request by next Monday, July 18. And please also send the s= lides to the chairs by next Friday, July 22. Sorry for sending this out late. BR -Haibin _______________________________________________ decade mailing list decade@ietf.org https://www.ietf.org/mailman/listinfo/decade From richard_woundy@cable.comcast.com Thu Jul 21 07:40:32 2011 Return-Path: X-Original-To: decade@ietfa.amsl.com Delivered-To: decade@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3030821F87E2 for ; Thu, 21 Jul 2011 07:40:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.291 X-Spam-Level: X-Spam-Status: No, score=-102.291 tagged_above=-999 required=5 tests=[AWL=-0.557, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Avi0xGOAeon3 for ; Thu, 21 Jul 2011 07:40:31 -0700 (PDT) Received: from cable.comcast.com (copdcimo01.potomac.co.ndcwest.comcast.net [76.96.32.251]) by ietfa.amsl.com (Postfix) with ESMTP id 8DB2421F85F2 for ; Thu, 21 Jul 2011 07:40:31 -0700 (PDT) Received: from ([24.40.55.41]) by copdcimo01.cable.comcast.com with ESMTP with TLS id 5503630.45587278; Thu, 21 Jul 2011 08:44:59 -0600 Received: from PACDCEXMB05.cable.comcast.com ([fe80::a5b0:e5c4:df1b:2367]) by PACDCEXHUB02.cable.comcast.com ([fe80::11d4:f530:37a0:9f4e%12]) with mapi id 14.01.0289.001; Thu, 21 Jul 2011 10:40:24 -0400 From: "Woundy, Richard" To: "decade@ietf.org" Thread-Topic: Decade agenda and call for presentations Thread-Index: AcxHtB7dQ6vEhTabRzChlQQgIfdMtQ== Date: Thu, 21 Jul 2011 14:40:22 +0000 Message-ID: <1CA25301D2219F40B3AA37201F0EACD1135D78AE@PACDCEXMB05.cable.comcast.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.163.75.13] Content-Type: multipart/alternative; boundary="_000_1CA25301D2219F40B3AA37201F0EACD1135D78AEPACDCEXMB05cabl_" MIME-Version: 1.0 Subject: [decade] Decade agenda and call for presentations X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2011 14:40:32 -0000 --_000_1CA25301D2219F40B3AA37201F0EACD1135D78AEPACDCEXMB05cabl_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The updated DECADE session has been uploaded to http://www.ietf.org/proceed= ings/81/agenda/decade.html and is reproduced below. Presenters, please email your draft presentations to the co-chairs (Haibin = and myself) by Sunday evening. Our plan is to post the slides to the IETF w= ebsite by Monday evening, prior to our face-to-face meeting in Quebec City = on Tuesday afternoon. -- Rich & Haibin Agenda: * Agenda Bash, Chairs, 5 minutes, 1520-1525 * DECADE Architecture, Richard Alimi, draft-ietf-decade-arch-02, 20 minutes, 1525-1545 * Requirements, Richard Alimi, draft-ietf-decade-reqs-03, 20 minutes, 1545-1605 * Integration examples, TBD, draft-ietf-decade-integration-example-01, 10= minutes, 1605-1615 * URIs for Named Information, Dirk Kutscher, draft-farrell-ni-00, 5 minutes, 1615-1620 * Rechartering Discussion, Chairs, continue discussion from Prague, 35 minutes, 1620-1655 * Conclusion and next steps, Chairs, 5 minutes, 1655-1700 --_000_1CA25301D2219F40B3AA37201F0EACD1135D78AEPACDCEXMB05cabl_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The updated DECADE session has been uploaded to http://www.ietf.org/proceedings/81/agenda/decade.html and is reproduced= below.

 

Presenters, please email your draft presentations to= the co-chairs (Haibin and myself) by Sunday evening. Our plan is to post t= he slides to the IETF website by Monday evening, prior to our face-to-face = meeting in Quebec City on Tuesday afternoon.

 

-- Rich & Haibin

 

Agenda:

--_000_1CA25301D2219F40B3AA37201F0EACD1135D78AEPACDCEXMB05cabl_-- From richard_woundy@cable.comcast.com Thu Jul 21 07:49:28 2011 Return-Path: X-Original-To: decade@ietfa.amsl.com Delivered-To: decade@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA69A21F8B0A for ; Thu, 21 Jul 2011 07:49:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.03 X-Spam-Level: X-Spam-Status: No, score=-102.03 tagged_above=-999 required=5 tests=[AWL=-0.595, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V-gUmHQup0YZ for ; Thu, 21 Jul 2011 07:49:28 -0700 (PDT) Received: from cable.comcast.com (copdcimo01.potomac.co.ndcwest.comcast.net [76.96.32.251]) by ietfa.amsl.com (Postfix) with ESMTP id 0185921F88DC for ; Thu, 21 Jul 2011 07:49:27 -0700 (PDT) Received: from ([24.40.55.40]) by copdcimo01.cable.comcast.com with ESMTP with TLS id 5503630.45589287; Thu, 21 Jul 2011 08:53:55 -0600 Received: from PACDCEXMB05.cable.comcast.com ([fe80::a5b0:e5c4:df1b:2367]) by pacdcexhub03.cable.comcast.com ([fe80::d1dd:b302:b617:3755%12]) with mapi id 14.01.0289.001; Thu, 21 Jul 2011 10:49:19 -0400 From: "Woundy, Richard" To: =?iso-8859-1?Q?B=F6rje_Ohlman?= , Songhaibin Thread-Topic: [decade] re-chartering Thread-Index: AQHMQULNa3T7B36KmEW5Crt3k4+ej5T24bYw Date: Thu, 21 Jul 2011 14:49:18 +0000 Message-ID: <1CA25301D2219F40B3AA37201F0EACD1135D790F@PACDCEXMB05.cable.comcast.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.163.75.13] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "decade@ietf.org" Subject: Re: [decade] re-chartering X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2011 14:49:28 -0000 B=F6rje, thanks for your feedback. We will discuss the naming scheme of dra= ft-farrell-ni in our WG session on Tuesday. Folks, any additional feedback on the re-chartering discussion would be muc= h appreciated. Thanks! -- Rich -----Original Message----- From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.org] On Behalf Of= B=F6rje Ohlman Sent: Wednesday, July 13, 2011 5:54 AM To: Songhaibin Cc: decade@ietf.org Subject: Re: [decade] re-chartering I think the items listed below are the main items for the next period. Obvi= ously the protocol issues are key things to complete. For the other two I w= ant to make the following comments. Regarding the naming scheme I want to promote the idea to select a naming s= cheme that can be generally applicable to naming any type of information ob= jects and thus not making it DECADE specific. As was mentioned at the last = IETF there is a draft proposing one possible such naming scheme, see http:/= /datatracker.ietf.org/doc/draft-farrell-ni/ In the DECADE architecture draft it is proposed to use a hash of the inform= ation object to name them. I support this idea and the naming scheme propos= ed in our draft could definitely support such naming. It might add a slight= overhead compared with using a plain hash, but it will add flexibility and= possibility for future extensions. These features could be useful if there= is a need to change a comprised hash algorithm in the future or for making= DECADE work smoothly with other future features provided by e.g. ALTO or C= DNI. Regarding service discovery I think this is a very important issue that is = key for making it possible to use DECADE in scenarios where users and hosts= are roaming in the network. B=F6rje On 20 jun 2011, at 09.54, Songhaibin wrote: > Dear all, >=20 > As we began our discussion about re-chartering from last IETF meeting. We= would like to hear more thoughts and comments in the list. The topics incl= ude but not limit to what we talked at last meeting. >=20 > 1. protocols > 2. Mandatory underlying protocol > 3. Mandatory naming scheme > 4. service discovery and etc. >=20 > What stuff should we work on in the next period in this WG in your opinio= n? Any special consideration? >=20 > BR, > -Haibin and Rich > _______________________________________________ > 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.alimi@gmail.com Mon Jul 25 04:54:39 2011 Return-Path: X-Original-To: decade@ietfa.amsl.com Delivered-To: decade@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D95C421F8BAA for ; Mon, 25 Jul 2011 04:54:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.953 X-Spam-Level: X-Spam-Status: No, score=-2.953 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6dTEt+5XYWcI for ; Mon, 25 Jul 2011 04:54:39 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id B04DA21F8BE3 for ; Mon, 25 Jul 2011 03:59:03 -0700 (PDT) Received: by iye7 with SMTP id 7so5649382iye.31 for ; Mon, 25 Jul 2011 03:59:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:from:date:x-google-sender-auth:message-id :subject:to:content-type; bh=qePsmgB+vHLj5zQ8A9hGsVChwLHC4ONUF4NN3R7D8dM=; b=ndPsIwauCJ5SNRHGwBa3nraXsP0CYob6RQueRSv/HnVTYpJ29gDr1b0rEg1ETmE/lk 5S7EuinjYMMK2ZXt7ekzaA+kq5c96rKf42wskNsi1zpPCa994z1ht8N2AVHPkgF1wo84 mPe/SuW6hQPRHmhT6RHa8bLtigZzN+aHUh2Nk= Received: by 10.231.41.23 with SMTP id m23mr4578750ibe.183.1311591543266; Mon, 25 Jul 2011 03:59:03 -0700 (PDT) MIME-Version: 1.0 Sender: richard.alimi@gmail.com Received: by 10.231.168.3 with HTTP; Mon, 25 Jul 2011 03:58:43 -0700 (PDT) From: Richard Alimi Date: Mon, 25 Jul 2011 03:58:43 -0700 X-Google-Sender-Auth: F4dx-19n6Ws6xA87UmpcoCM8X4k Message-ID: To: decade@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [decade] Metadata, DECADE Data Objects, and you X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2011 11:54:40 -0000 In his review of the DECADE Requirements draft, Akbar brought up a very good question regarding metadata associated with data objects. In particular, he asked whether such metadata was immutable or not. A couple of the requirements drafts authors discussed a bit, but it seems clear that there are a couple of questions here that need input from the larger WG. To frame the problem space, lets begin with: (1) Should DECADE Clients be able to specify key/value pairs stored alongside the data object's content? The use case we had in mind would be to allow an application to specify contextual information associated with an object, for example "this is chunk 123 of that live soccer stream I am watching" (of course, not in plain English). It could be used if the application crashes and resumes, or is stopped and resumed on a different device (in which case a simple local checkpoint won't suffice). The DECADE Client could then request a list of objects matching "that soccer stream I am watching", and retrieve the ones it is missing from the DECADE Server. Possible answers are: (1a) Yes: Then we continue on to (2).. (1b) No: It might be possible for an application to still achieve what it wants, in a somewhat more limited way. For example, it could store additional metadata as the first K bytes of a data object, and (if we allow range requests) then the application could determine if this is the desired object without necessarily requesting the full object. It is less clear how we might support querying for a list of matching objects in this case. Alternatively, one could argue that this is the application's problem, and DECADE should not be in the business of storing this arbitrary metadata at all. (2) Should this additional metadata associated with a data object be immutable? In particular, should an application be prohibited from adding/modifying/removing these key/value pairs *after* a data object has been stored? It is important to note that data objects (the contents themselves) in DECADE are already immutable, which lends itself to some very attractive simplicity. Regardless of whether metadata is mutable or immutable, we would need to decide: Should the data object's name (content hash) be a hash over the data *and* the metadata? - If yes, this automatically means that one could in a sense change the metadata by creating a new data object. Note that the actual operation can be made to be cheap at the DECADE server, though it does make the operational model somewhat less simple and implementations more complex. - If no, then things like cross-server de-duplication (if an implementation wished to support that) become much trickier since they need to deal with conflicts in the key/value pairs associated with data objects. Now to whether metadata is immutable. Possible answers are: (2a) Yes: Then I think we are mostly done, aside from the naming issue above. We need to be sure to provide a mechanism (perhaps via the granted tokens) so that a DECADE Server can validate that the DECADE Client storing the data is indeed attaching the correct metadata (similar to how it can already validate that the data being written is the correct data). An important question here is: are we giving up flexibility that is needed? (2b) No: This seems to open a can of worms with regards to locking and caching (e.g., intermediaries, or even within applications). My personal opinion is that the can of worms in (2b) isn't worth dealing with. The tradeoffs between (2a) and (1b) are less clear to me. Thinking through this some more, I have a slight preference for the simplicity of (1b), but might be convinced otherwise. Other thoughts? Thanks, Rich From haibin.song@huawei.com Mon Jul 25 06:10:50 2011 Return-Path: X-Original-To: decade@ietfa.amsl.com Delivered-To: decade@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 623A921F8AF6 for ; Mon, 25 Jul 2011 06:10:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.932 X-Spam-Level: X-Spam-Status: No, score=-3.932 tagged_above=-999 required=5 tests=[AWL=-1.333, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lTZbkrI0ReN7 for ; Mon, 25 Jul 2011 06:10:46 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id F2B3521F87A4 for ; Mon, 25 Jul 2011 06:10:22 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LOW0053C4JWSX@szxga05-in.huawei.com> for decade@ietf.org; Mon, 25 Jul 2011 21:09:32 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LOW00EL84JV3B@szxga05-in.huawei.com> for decade@ietf.org; Mon, 25 Jul 2011 21:09:32 +0800 (CST) Received: from 172.24.2.119 (EHLO szxeml205-edg.china.huawei.com) ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA FastPath queued) with ESMTP id ACO86752; Mon, 25 Jul 2011 21:09:28 +0800 (CST) Received: from SZXEML410-HUB.china.huawei.com (10.82.67.137) by szxeml205-edg.china.huawei.com (172.24.2.57) with Microsoft SMTP Server (TLS) id 14.1.270.1; Mon, 25 Jul 2011 21:09:26 +0800 Received: from SZXEML524-MBS.china.huawei.com ([169.254.5.79]) by szxeml410-hub.china.huawei.com ([169.254.101.122]) with mapi id 14.01.0270.001; Mon, 25 Jul 2011 21:09:28 +0800 Date: Mon, 25 Jul 2011 13:09:27 +0000 From: Songhaibin In-reply-to: X-Originating-IP: [172.24.2.40] To: Richard Alimi , "decade@ietf.org" Message-id: MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: en-US Content-transfer-encoding: 7BIT Accept-Language: en-US, zh-CN Thread-topic: [decade] Metadata, DECADE Data Objects, and you Thread-index: AQHMSsLkpqdNpvnQmUy0+NtN6Q0YjpT9AY4X X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: Subject: Re: [decade] Metadata, DECADE Data Objects, and you X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2011 13:10:50 -0000 Hi Rich, Thank you very much for putting out this interesting issue. In my personal opinion, we should at least allow the extensibility to include metadata although we may not need to support it right now. My two cents: Can metadata be stored as a separate data object itself( include associated hash value of the content object as one parameter so as to associate them)? In this case, the metadata can be changed without creating a new object for the content itself, but creating a new object for the metadata iteself. And it still needs to resolve the conflicts if there are conflict metadatas associated with the same content object:( BR, -Haibin ________________________________________ From: decade-bounces@ietf.org [decade-bounces@ietf.org] on behalf of Richard Alimi [rich@velvetsea.net] Sent: Monday, July 25, 2011 6:58 PM To: decade@ietf.org Subject: [decade] Metadata, DECADE Data Objects, and you In his review of the DECADE Requirements draft, Akbar brought up a very good question regarding metadata associated with data objects. In particular, he asked whether such metadata was immutable or not. A couple of the requirements drafts authors discussed a bit, but it seems clear that there are a couple of questions here that need input from the larger WG. To frame the problem space, lets begin with: (1) Should DECADE Clients be able to specify key/value pairs stored alongside the data object's content? The use case we had in mind would be to allow an application to specify contextual information associated with an object, for example "this is chunk 123 of that live soccer stream I am watching" (of course, not in plain English). It could be used if the application crashes and resumes, or is stopped and resumed on a different device (in which case a simple local checkpoint won't suffice). The DECADE Client could then request a list of objects matching "that soccer stream I am watching", and retrieve the ones it is missing from the DECADE Server. Possible answers are: (1a) Yes: Then we continue on to (2).. (1b) No: It might be possible for an application to still achieve what it wants, in a somewhat more limited way. For example, it could store additional metadata as the first K bytes of a data object, and (if we allow range requests) then the application could determine if this is the desired object without necessarily requesting the full object. It is less clear how we might support querying for a list of matching objects in this case. Alternatively, one could argue that this is the application's problem, and DECADE should not be in the business of storing this arbitrary metadata at all. (2) Should this additional metadata associated with a data object be immutable? In particular, should an application be prohibited from adding/modifying/removing these key/value pairs *after* a data object has been stored? It is important to note that data objects (the contents themselves) in DECADE are already immutable, which lends itself to some very attractive simplicity. Regardless of whether metadata is mutable or immutable, we would need to decide: Should the data object's name (content hash) be a hash over the data *and* the metadata? - If yes, this automatically means that one could in a sense change the metadata by creating a new data object. Note that the actual operation can be made to be cheap at the DECADE server, though it does make the operational model somewhat less simple and implementations more complex. - If no, then things like cross-server de-duplication (if an implementation wished to support that) become much trickier since they need to deal with conflicts in the key/value pairs associated with data objects. Now to whether metadata is immutable. Possible answers are: (2a) Yes: Then I think we are mostly done, aside from the naming issue above. We need to be sure to provide a mechanism (perhaps via the granted tokens) so that a DECADE Server can validate that the DECADE Client storing the data is indeed attaching the correct metadata (similar to how it can already validate that the data being written is the correct data). An important question here is: are we giving up flexibility that is needed? (2b) No: This seems to open a can of worms with regards to locking and caching (e.g., intermediaries, or even within applications). My personal opinion is that the can of worms in (2b) isn't worth dealing with. The tradeoffs between (2a) and (1b) are less clear to me. Thinking through this some more, I have a slight preference for the simplicity of (1b), but might be convinced otherwise. Other thoughts? Thanks, Rich _______________________________________________ decade mailing list decade@ietf.org https://www.ietf.org/mailman/listinfo/decade From richard_woundy@cable.comcast.com Mon Jul 25 07:55:11 2011 Return-Path: X-Original-To: decade@ietfa.amsl.com Delivered-To: decade@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BB4221F8CA0 for ; Mon, 25 Jul 2011 07:55:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.081 X-Spam-Level: X-Spam-Status: No, score=-102.081 tagged_above=-999 required=5 tests=[AWL=-0.346, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Td2jeiFhujR for ; Mon, 25 Jul 2011 07:55:09 -0700 (PDT) Received: from cable.comcast.com (copdcimo01.potomac.co.ndcwest.comcast.net [76.96.32.251]) by ietfa.amsl.com (Postfix) with ESMTP id 7273221F8B6F for ; Mon, 25 Jul 2011 07:01:00 -0700 (PDT) Received: from ([24.40.55.40]) by copdcimo01.cable.comcast.com with ESMTP with TLS id 5503630.46005743; Mon, 25 Jul 2011 08:05:36 -0600 Received: from PACDCEXMB05.cable.comcast.com ([fe80::a5b0:e5c4:df1b:2367]) by pacdcexhub03.cable.comcast.com ([fe80::d1dd:b302:b617:3755%12]) with mapi id 14.01.0289.001; Mon, 25 Jul 2011 10:00:52 -0400 From: "Woundy, Richard" To: "'haibin.song@huawei.com'" , "'rich@velvetsea.net'" , "'decade@ietf.org'" Thread-Topic: [decade] Metadata, DECADE Data Objects, and you Thread-Index: AQHMSsLkb5ckbts0ikavYBtjoHLIapT9RbGA///LUAM= Date: Mon, 25 Jul 2011 14:00:52 +0000 Message-ID: <1CA25301D2219F40B3AA37201F0EACD1135D984A@PACDCEXMB05.cable.comcast.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [24.40.50.240] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [decade] Metadata, DECADE Data Objects, and you X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2011 14:55:11 -0000 Here is my personal opinion -- not as wg chair. I think the answer may depend on what *type* of metadata is associated with= the data object. If the metadata is related to the physical attributes of = the object (eg codec parameters for a media file), it may be immutable. If = the metadata is related to the management attributes of the object (eg obje= ct lifetime, owner contact info), then it may be desirable to update it ove= r time. -- Rich ----- Original Message ----- From: Songhaibin [mailto:haibin.song@huawei.com] Sent: Monday, July 25, 2011 09:09 AM=0A= To: Richard Alimi ; decade@ietf.org Subject: Re: [decade] Metadata, DECADE Data Objects, and you Hi Rich, Thank you very much for putting out this interesting issue. In my personal opinion, we should at least allow the extensibility to inclu= de metadata although we may not need to support it right now. My two cents: Can metadata be stored as a separate data object itself( incl= ude associated hash value of the content object as one parameter so as to a= ssociate them)? In this case, the metadata can be changed without creating = a new object for the content itself, but creating a new object for the meta= data iteself. And it still needs to resolve the conflicts if there are conf= lict metadatas associated with the same content object:( BR, -Haibin ________________________________________ From: decade-bounces@ietf.org [decade-bounces@ietf.org] on behalf of Richar= d Alimi [rich@velvetsea.net] Sent: Monday, July 25, 2011 6:58 PM To: decade@ietf.org Subject: [decade] Metadata, DECADE Data Objects, and you In his review of the DECADE Requirements draft, Akbar brought up a very good question regarding metadata associated with data objects. In particular, he asked whether such metadata was immutable or not. A couple of the requirements drafts authors discussed a bit, but it seems clear that there are a couple of questions here that need input from the larger WG. To frame the problem space, lets begin with: (1) Should DECADE Clients be able to specify key/value pairs stored alongside the data object's content? The use case we had in mind would be to allow an application to specify contextual information associated with an object, for example "this is chunk 123 of that live soccer stream I am watching" (of course, not in plain English). It could be used if the application crashes and resumes, or is stopped and resumed on a different device (in which case a simple local checkpoint won't suffice). The DECADE Client could then request a list of objects matching "that soccer stream I am watching", and retrieve the ones it is missing from the DECADE Server. Possible answers are: (1a) Yes: Then we continue on to (2).. (1b) No: It might be possible for an application to still achieve what it wants, in a somewhat more limited way. For example, it could store additional metadata as the first K bytes of a data object, and (if we allow range requests) then the application could determine if this is the desired object without necessarily requesting the full object. It is less clear how we might support querying for a list of matching objects in this case. Alternatively, one could argue that this is the application's problem, and DECADE should not be in the business of storing this arbitrary metadata at all. (2) Should this additional metadata associated with a data object be immutable? In particular, should an application be prohibited from adding/modifying/removing these key/value pairs *after* a data object has been stored? It is important to note that data objects (the contents themselves) in DECADE are already immutable, which lends itself to some very attractive simplicity. Regardless of whether metadata is mutable or immutable, we would need to decide: Should the data object's name (content hash) be a hash over the data *and* the metadata? - If yes, this automatically means that one could in a sense change the metadata by creating a new data object. Note that the actual operation can be made to be cheap at the DECADE server, though it does make the operational model somewhat less simple and implementations more complex. - If no, then things like cross-server de-duplication (if an implementation wished to support that) become much trickier since they need to deal with conflicts in the key/value pairs associated with data objects. Now to whether metadata is immutable. Possible answers are: (2a) Yes: Then I think we are mostly done, aside from the naming issue above. We need to be sure to provide a mechanism (perhaps via the granted tokens) so that a DECADE Server can validate that the DECADE Client storing the data is indeed attaching the correct metadata (similar to how it can already validate that the data being written is the correct data). An important question here is: are we giving up flexibility that is needed? (2b) No: This seems to open a can of worms with regards to locking and caching (e.g., intermediaries, or even within applications). My personal opinion is that the can of worms in (2b) isn't worth dealing with. The tradeoffs between (2a) and (1b) are less clear to me. Thinking through this some more, I have a slight preference for the simplicity of (1b), but might be convinced otherwise. Other thoughts? Thanks, Rich _______________________________________________ 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 Tue Jul 26 04:02:52 2011 Return-Path: X-Original-To: decade@ietfa.amsl.com Delivered-To: decade@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFDE121F8B27 for ; Tue, 26 Jul 2011 04:02:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.667 X-Spam-Level: X-Spam-Status: No, score=-106.667 tagged_above=-999 required=5 tests=[AWL=1.795, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kGodj1RbZV6p for ; Tue, 26 Jul 2011 04:02:52 -0700 (PDT) Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by ietfa.amsl.com (Postfix) with ESMTP id 0007521F8C40 for ; Tue, 26 Jul 2011 04:02:51 -0700 (PDT) Received: from ([24.40.55.40]) by pacdcimo01.cable.comcast.com with ESMTP with TLS id 5503620.135164161; Tue, 26 Jul 2011 07:02:12 -0400 Received: from PACDCEXMB05.cable.comcast.com ([fe80::a5b0:e5c4:df1b:2367]) by pacdcexhub03.cable.comcast.com ([fe80::d1dd:b302:b617:3755%12]) with mapi id 14.01.0289.001; Tue, 26 Jul 2011 07:02:12 -0400 From: "Woundy, Richard" To: "decade@ietf.org" Thread-Topic: Decade agenda and call for presentations Thread-Index: AcxHtB7dQ6vEhTabRzChlQQgIfdMtQDzyHkw Date: Tue, 26 Jul 2011 11:02:11 +0000 Message-ID: <1CA25301D2219F40B3AA37201F0EACD1135DA4C7@PACDCEXMB05.cable.comcast.com> References: <1CA25301D2219F40B3AA37201F0EACD1135D78AE@PACDCEXMB05.cable.comcast.com> In-Reply-To: <1CA25301D2219F40B3AA37201F0EACD1135D78AE@PACDCEXMB05.cable.comcast.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [76.96.69.4] Content-Type: multipart/alternative; boundary="_000_1CA25301D2219F40B3AA37201F0EACD1135DA4C7PACDCEXMB05cabl_" MIME-Version: 1.0 Subject: Re: [decade] Decade agenda and call for presentations X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2011 11:02:53 -0000 --_000_1CA25301D2219F40B3AA37201F0EACD1135DA4C7PACDCEXMB05cabl_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Folks, Haibin and I have uploaded the DECADE presentations to . Thanks to all the presenter= s that made this possible. -- Rich From: Woundy, Richard Sent: Thursday, July 21, 2011 10:40 AM To: decade@ietf.org Cc: Songhaibin; Woundy, Richard Subject: Decade agenda and call for presentations The updated DECADE session has been uploaded to http://www.ietf.org/proceed= ings/81/agenda/decade.html and is reproduced below. Presenters, please email your draft presentations to the co-chairs (Haibin = and myself) by Sunday evening. Our plan is to post the slides to the IETF w= ebsite by Monday evening, prior to our face-to-face meeting in Quebec City = on Tuesday afternoon. -- Rich & Haibin Agenda: * Agenda Bash, Chairs, 5 minutes, 1520-1525 * DECADE Architecture, Richard Alimi, draft-ietf-decade-arch-02, 20 minutes, 1525-1545 * Requirements, Richard Alimi, draft-ietf-decade-reqs-03, 20 minutes, 1545-1605 * Integration examples, TBD, draft-ietf-decade-integration-example-01, 10= minutes, 1605-1615 * URIs for Named Information, Dirk Kutscher, draft-farrell-ni-00, 5 minutes, 1615-1620 * Rechartering Discussion, Chairs, continue discussion from Prague, 35 minutes, 1620-1655 * Conclusion and next steps, Chairs, 5 minutes, 1655-1700 --_000_1CA25301D2219F40B3AA37201F0EACD1135DA4C7PACDCEXMB05cabl_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Folks,

 

Haibin and I have uplo= aded the DECADE presentations to <https://datatracker.ietf.org/meeting= /81/materials.html#wg-decade>. Thanks to all the presenters that made this possible.

 

-- Rich

 

From: Woundy, = Richard
Sent: Thursday, July 21, 2011 10:40 AM
To: decade@ietf.org
Cc: Songhaibin; Woundy, Richard
Subject: Decade agenda and call for presentations<= /p>

 

The updated DECADE session has been uploaded to http://www.ietf.org/proceedings/81/agenda/decade.html and is reproduced= below.

 

Presenters, please email your draft presentations to= the co-chairs (Haibin and myself) by Sunday evening. Our plan is to post t= he slides to the IETF website by Monday evening, prior to our face-to-face = meeting in Quebec City on Tuesday afternoon.

 

-- Rich & Haibin

 

Agenda:

--_000_1CA25301D2219F40B3AA37201F0EACD1135DA4C7PACDCEXMB05cabl_-- From richard.alimi@gmail.com Sat Jul 30 08:11:20 2011 Return-Path: X-Original-To: decade@ietfa.amsl.com Delivered-To: decade@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E96C421F874B for ; Sat, 30 Jul 2011 08:11:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.962 X-Spam-Level: X-Spam-Status: No, score=-2.962 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rI03RK5bF06R for ; Sat, 30 Jul 2011 08:11:19 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 638F321F8588 for ; Sat, 30 Jul 2011 08:11:16 -0700 (PDT) Received: by vws12 with SMTP id 12so4190131vws.31 for ; Sat, 30 Jul 2011 08:11:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=qgs7u4BVWgGWAw9NXGJzdwaHrQ39WYv6ySyMd1IuIns=; b=Xa1+QVw7HFgX6zXCogfcNr1VJCc+9jxXNr/zd1yLKLOHkUCrl2PRXknvVeQj8QBcP0 0mFgBOGHoYIyMcMUQUeeZlust7YkBC4QiWlkyXRioWlYWsAAxsa1tyq3e5/QluXuP0aJ SYegWUlZSiwnKlypnzMZGIQZ65yrjvQ8KjSbQ= Received: by 10.52.92.211 with SMTP id co19mr2683097vdb.57.1312038677073; Sat, 30 Jul 2011 08:11:17 -0700 (PDT) MIME-Version: 1.0 Sender: richard.alimi@gmail.com Received: by 10.52.109.162 with HTTP; Sat, 30 Jul 2011 08:10:57 -0700 (PDT) In-Reply-To: <1CA25301D2219F40B3AA37201F0EACD1135D984A@PACDCEXMB05.cable.comcast.com> References: <1CA25301D2219F40B3AA37201F0EACD1135D984A@PACDCEXMB05.cable.comcast.com> From: Richard Alimi Date: Sat, 30 Jul 2011 08:10:57 -0700 X-Google-Sender-Auth: cnPG78igsKxPiEMDGT4hLRfWjWk Message-ID: To: "Woundy, Richard" Content-Type: multipart/alternative; boundary=20cf307d03e6474d9504a94acf2f Cc: "decade@ietf.org" Subject: Re: [decade] Metadata, DECADE Data Objects, and you X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jul 2011 15:11:21 -0000 --20cf307d03e6474d9504a94acf2f Content-Type: text/plain; charset=ISO-8859-1 Just to update the status, we had a discussion about this during the meeting. The outcome was that decade will not allow arbitrary (application-specified) metadata associated with data objects. We will update the draft to reflect this and post an update by the end of this coming week. Thanks, Rich On Jul 25, 2011 10:01 AM, "Woundy, Richard" < Richard_Woundy@cable.comcast.com> wrote: > Here is my personal opinion -- not as wg chair. > > I think the answer may depend on what *type* of metadata is associated with the data object. If the metadata is related to the physical attributes of the object (eg codec parameters for a media file), it may be immutable. If the metadata is related to the management attributes of the object (eg object lifetime, owner contact info), then it may be desirable to update it over time. > > -- Rich > > > ----- Original Message ----- > From: Songhaibin [mailto:haibin.song@huawei.com] > Sent: Monday, July 25, 2011 09:09 AM > To: Richard Alimi ; decade@ietf.org > Subject: Re: [decade] Metadata, DECADE Data Objects, and you > > Hi Rich, > > Thank you very much for putting out this interesting issue. > > In my personal opinion, we should at least allow the extensibility to include metadata although we may not need to support it right now. > > My two cents: Can metadata be stored as a separate data object itself( include associated hash value of the content object as one parameter so as to associate them)? In this case, the metadata can be changed without creating a new object for the content itself, but creating a new object for the metadata iteself. And it still needs to resolve the conflicts if there are conflict metadatas associated with the same content object:( > > BR, > -Haibin > > ________________________________________ > From: decade-bounces@ietf.org [decade-bounces@ietf.org] on behalf of Richard Alimi [rich@velvetsea.net] > Sent: Monday, July 25, 2011 6:58 PM > To: decade@ietf.org > Subject: [decade] Metadata, DECADE Data Objects, and you > > In his review of the DECADE Requirements draft, Akbar brought up a > very good question regarding metadata associated with data objects. > In particular, he asked whether such metadata was immutable or not. A > couple of the requirements drafts authors discussed a bit, but it > seems clear that there are a couple of questions here that need input > from the larger WG. > > To frame the problem space, lets begin with: > (1) Should DECADE Clients be able to specify key/value pairs stored > alongside the data object's content? The use case we had in mind > would be to allow an application to specify contextual information > associated with an object, for example "this is chunk 123 of that live > soccer stream I am watching" (of course, not in plain English). It > could be used if the application crashes and resumes, or is stopped > and resumed on a different device (in which case a simple local > checkpoint won't suffice). The DECADE Client could then request a > list of objects matching "that soccer stream I am watching", and > retrieve the ones it is missing from the DECADE Server. > > Possible answers are: > (1a) Yes: Then we continue on to (2).. > (1b) No: It might be possible for an application to still achieve what > it wants, in a somewhat more limited way. For example, it could store > additional metadata as the first K bytes of a data object, and (if we > allow range requests) then the application could determine if this is > the desired object without necessarily requesting the full object. It > is less clear how we might support querying for a list of matching > objects in this case. Alternatively, one could argue that this is the > application's problem, and DECADE should not be in the business of > storing this arbitrary metadata at all. > > (2) Should this additional metadata associated with a data object be > immutable? In particular, should an application be prohibited from > adding/modifying/removing these key/value pairs *after* a data object > has been stored? It is important to note that data objects (the > contents themselves) in DECADE are already immutable, which lends > itself to some very attractive simplicity. > > Regardless of whether metadata is mutable or immutable, we would need > to decide: Should the data object's name (content hash) be a hash over > the data *and* the metadata? > - If yes, this automatically means that one could in a sense change > the metadata by creating a new data object. Note that the actual > operation can be made to be cheap at the DECADE server, though it does > make the operational model somewhat less simple and implementations > more complex. > - If no, then things like cross-server de-duplication (if an > implementation wished to support that) become much trickier since they > need to deal with conflicts in the key/value pairs associated with > data objects. > > Now to whether metadata is immutable. Possible answers are: > (2a) Yes: Then I think we are mostly done, aside from the naming issue > above. We need to be sure to provide a mechanism (perhaps via the > granted tokens) so that a DECADE Server can validate that the DECADE > Client storing the data is indeed attaching the correct metadata > (similar to how it can already validate that the data being written is > the correct data). An important question here is: are we giving up > flexibility that is needed? > (2b) No: This seems to open a can of worms with regards to locking and > caching (e.g., intermediaries, or even within applications). > > My personal opinion is that the can of worms in (2b) isn't worth > dealing with. The tradeoffs between (2a) and (1b) are less clear to > me. Thinking through this some more, I have a slight preference for > the simplicity of (1b), but might be convinced otherwise. > > Other thoughts? > > Thanks, > Rich > _______________________________________________ > 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 --20cf307d03e6474d9504a94acf2f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Just to update the status, we had a discussion about this during the mee= ting. The outcome was that decade will not allow arbitrary (application-spe= cified) metadata associated with data objects.

We will update the dra= ft to reflect this and post an update by the end of this coming week.

Thanks,

Rich

On Jul 25, 2011 10:01 AM, "Woundy, Richard&= quot; <Richard_Woundy@cable.comcast.com> wrote:
> Here is my personal opinion -- not as wg chair.
>
> I think the answer may depend on what *type* of metadata is a= ssociated with the data object. If the metadata is related to the physical = attributes of the object (eg codec parameters for a media file), it may be = immutable. If the metadata is related to the management attributes of the o= bject (eg object lifetime, owner contact info), then it may be desirable to= update it over time.
>
> -- Rich
>
>
> ----- Original Message ----= -
> From: Songhaibin [mailto:haibin.song@huawei.com]
> Sent: Monday, July = 25, 2011 09:09 AM
> To: Richard Alimi <rich@velvetsea.net>; decade@ietf.org <decade@ietf.org>
> Subject: Re: [decade] Metadata, DECADE Data Objects, and you
>
> Hi Rich,
>
> Thank you very much for putting out= this interesting issue.
>
> In my personal opinion, we should= at least allow the extensibility to include metadata although we may not n= eed to support it right now.
>
> My two cents: Can metadata be stored as a separate data objec= t itself( include associated hash value of the content object as one parame= ter so as to associate them)? In this case, the metadata can be changed wit= hout creating a new object for the content itself, but creating a new objec= t for the metadata iteself. And it still needs to resolve the conflicts if = there are conflict metadatas associated with the same content object:(
>
> BR,
> -Haibin
>
> ________________________= ________________
> From: decade-bounces@ietf.org [decade-bounces@ietf.org] on behalf of R= ichard Alimi [rich@= velvetsea.net]
> Sent: Monday, July 25, 2011 6:58 PM
> To: decade@ietf.org
> Subject: [decade= ] Metadata, DECADE Data Objects, and you
>
> In his review of = the DECADE Requirements draft, Akbar brought up a
> very good question regarding metadata associated with data objects.> In particular, he asked whether such metadata was immutable or not. A=
> couple of the requirements drafts authors discussed a bit, but it<= br> > seems clear that there are a couple of questions here that need input<= br>> from the larger WG.
>
> To frame the problem space, le= ts begin with:
> (1) Should DECADE Clients be able to specify key/val= ue pairs stored
> alongside the data object's content? The use case we had in mind<= br>> would be to allow an application to specify contextual information<= br>> associated with an object, for example "this is chunk 123 of t= hat live
> soccer stream I am watching" (of course, not in plain English). = It
> could be used if the application crashes and resumes, or is stop= ped
> and resumed on a different device (in which case a simple local=
> checkpoint won't suffice). The DECADE Client could then request a=
> list of objects matching "that soccer stream I am watching&qu= ot;, and
> retrieve the ones it is missing from the DECADE Server. >
> Possible answers are:
> (1a) Yes: Then we continue on = to (2)..
> (1b) No: It might be possible for an application to still = achieve what
> it wants, in a somewhat more limited way. For example= , it could store
> additional metadata as the first K bytes of a data object, and (if we<= br>> allow range requests) then the application could determine if this = is
> the desired object without necessarily requesting the full objec= t. It
> is less clear how we might support querying for a list of matching
= > objects in this case. Alternatively, one could argue that this is the<= br>> application's problem, and DECADE should not be in the business= of
> storing this arbitrary metadata at all.
>
> (2) Should th= is additional metadata associated with a data object be
> immutable? = In particular, should an application be prohibited from
> adding/mod= ifying/removing these key/value pairs *after* a data object
> has been stored? It is important to note that data objects (the
&g= t; contents themselves) in DECADE are already immutable, which lends
>= ; itself to some very attractive simplicity.
>
> Regardless of= whether metadata is mutable or immutable, we would need
> to decide: Should the data object's name (content hash) be a hash = over
> the data *and* the metadata?
> - If yes, this automatica= lly means that one could in a sense change
> the metadata by creating= a new data object. Note that the actual
> operation can be made to be cheap at the DECADE server, though it does=
> make the operational model somewhat less simple and implementation= s
> more complex.
> - If no, then things like cross-server de-d= uplication (if an
> implementation wished to support that) become much trickier since they=
> need to deal with conflicts in the key/value pairs associated with=
> data objects.
>
> Now to whether metadata is immutabl= e. Possible answers are:
> (2a) Yes: Then I think we are mostly done, aside from the naming issue=
> above. We need to be sure to provide a mechanism (perhaps via the=
> granted tokens) so that a DECADE Server can validate that the DECA= DE
> Client storing the data is indeed attaching the correct metadata
&g= t; (similar to how it can already validate that the data being written is> the correct data). An important question here is: are we giving up<= br> > flexibility that is needed?
> (2b) No: This seems to open a can = of worms with regards to locking and
> caching (e.g., intermediaries,= or even within applications).
>
> My personal opinion is that= the can of worms in (2b) isn't worth
> dealing with. The tradeoffs between (2a) and (1b) are less clear to> me. Thinking through this some more, I have a slight preference for=
> the simplicity of (1b), but might be convinced otherwise.
>
> Other thoughts?
>
> Thanks,
> Rich
> ________= _______________________________________
> decade mailing list
>= decade@ietf.org > https://www.ietf.org/mailman/listinfo/decade
> _______________________________________________
> decade mailing= list
> decade@i= etf.org
> https://www.ietf.org/mailman/listinfo/decade
--20cf307d03e6474d9504a94acf2f-- From Akbar.Rahman@InterDigital.com Sat Jul 30 08:27:30 2011 Return-Path: X-Original-To: decade@ietfa.amsl.com Delivered-To: decade@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7CAE21F8669 for ; Sat, 30 Jul 2011 08:27:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3FHXQ8VdZIhv for ; Sat, 30 Jul 2011 08:27:29 -0700 (PDT) Received: from idcout.InterDigital.com (idcexmail.interdigital.com [12.32.197.135]) by ietfa.amsl.com (Postfix) with ESMTP id 6CC3121F86BC for ; Sat, 30 Jul 2011 08:27:29 -0700 (PDT) Received: from SAM.InterDigital.com ([10.30.2.11]) by idcout.InterDigital.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 30 Jul 2011 11:27:30 -0400 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_01CC4ECD.31CE3345" Date: Sat, 30 Jul 2011 11:27:29 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Proposed CDMI summary text for DECADE Survey Thread-Index: AcxOzTHT9OYJTgNlRt20ftscLI/PaQ== From: "Rahman, Akbar" To: X-OriginalArrivalTime: 30 Jul 2011 15:27:30.0125 (UTC) FILETIME=[32036FD0:01CC4ECD] Subject: [decade] Proposed CDMI summary text for DECADE Survey X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jul 2011 15:27:30 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC4ECD.31CE3345 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, =20 =20 As per the suggestion during the Quebec IETF meeting, we have come up with the following proposed text for CDMI to add to the DECADE Survey. We would appreciate if you could write back to us with any comments by the end of Monday (August 1). We apologize for the short time frame, but since the Survey will be discussed in the IESG telechat on Aug. 11, we need to update the Survey with this item quickly. =20 =20 Sincerely, =20 Akbar/Rich/Richard =20 =20 P.S. We had a review of the proposed text by some CDMI experts and they were okay with the text.=20 =20 =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 =20 1.0. Cloud Data Management Interface =20 The Cloud Data Management Interface (CDMI) is a specification to access and manage cloud storage. CDMI is specified by the Storage Networking Industry Association (SNIA). =20 CDMI is a functional interface that applications can use to create, retrieve, update and delete data elements from the cloud. As part of this interface the client will be able to discover the capabilities of the cloud storage offering and use this interface to manage containers and the data that is placed in them. In addition, metadata can be set on containers and their contained data elements through this interface. [Reference: http://www.snia.org/cdmi] =20 =20 CDMI follows a traditional client server model, and operates over HTTP. Similar to Amazon S3 buckets, users may create containers into which data objects may be stored. Even though data objects may be accessed via a user-defined name within a container, it is also possible to access data objects by a storage-defined Object ID which is provided in the response upon creation of a Data Object. =20 1.0.1. Applicability to DECADE =20 CDMI is an important initiative to standardize storage interfaces for cloud services which are rapidly becoming an important storage service. In particular, it specifies a set of operations for creating, reading, writing, and managing data objects at a remote server (or set of servers) via a HTTP protocol. =20 1.0.2. Data Access Interface =20 Users can read and write data objects, and also update data in existing data objects. CDMI-specific operations are specified in which data objects are embedded as fields inside of a JSON Object, but the protocol also defines interfaces in which the contents of data objects can be written via simple HTTP GET/PUT operations. =20 1.0.3. Data Management Operations =20 Users can delete already-existing data objects. The create operation also supports modes in which the created object is copied or moved from an existing data object. =20 Data System Metadata also allows users to configure policies regarding time-to-live after which a data object is automatically deleted, as well as the redundancy with which a data object is stored. =20 1.0.4. Data Search Capability =20 Users may list the contents of containers to locate data objects matching any desired criteria. =20 1.0.5. Access Control Authorization =20 CDMI supports both public-unrestricted, public-restricted and private modes. =20 In particular CDMI allows access to data objects to be protected by ACLs which can allow or restrict access based on user, group, administrative status, or whether a user is authenticated or anonymous, =20 1.0.6. Resource Control Interface =20 CDMI supports attributes 'cdmi_max_latency' and 'cdmi_max_throughput' (set at either the level of containers, or a specific data object) which control the level of service offered to any users accessing a particular data object. =20 1.0.7. Discovery Mechanism =20 Users are provided a well-known DNS name. The DNS name is resolved to determine the IP address to which requests may be sent. =20 1.0.8. Storage Mode =20 Object-based, with the extension that objects can be organized into user-defined containers. =20 =20 =20 ------_=_NextPart_001_01CC4ECD.31CE3345 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi = All,

 

 

As per the = suggestion during the Quebec IETF meeting, we have come up with the = following proposed text for CDMI to add to the DECADE Survey.  We = would appreciate if you could write back to us with any comments by the = end of Monday (August 1).  We apologize for the short time frame, = but since the Survey will be discussed in the IESG telechat on Aug. 11, = we need to update the Survey with this item quickly.

 

 

Sincerely,

 

Akbar/Rich/Richard

 

 

P.S. We had = a review of the proposed text by some CDMI experts and they were okay = with the text.

 

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D

 

1.0.  Cloud Data = Management Interface

 <= /p>

  The Cloud Data = Management Interface (CDMI) is a specification to = access

  and manage cloud = storage.  CDMI is specified by the Storage  = Networking

  Industry = Association (SNIA).

 <= /p>

 CDMI is a = functional interface that applications can use to = create,

  retrieve, update = and delete data elements from the cloud.  As part = of

  this interface = the client will be able to discover the capabilities = of

  the cloud storage = offering and use this interface to manage = containers

  and the data that = is placed in them.  In addition, metadata can be = set

  on containers and = their contained data elements through this = interface.

  [Reference: http://www.snia.org/cdmi]

 <= /p>

  CDMI follows a = traditional client server model, and operates over = HTTP.

  Similar to Amazon = S3 buckets, users may create containers into = which

  data objects may = be stored.  Even though data objects may be = accessed

  via a = user-defined name within a container, it is also possible to = access

  data objects by a = storage-defined Object ID which is provided in = the

  response upon = creation of a Data Object.

 <= /p>

1.0.1.  = Applicability to DECADE

 <= /p>

  CDMI is an = important initiative to standardize storage interfaces = for

  cloud services = which are rapidly becoming an important storage = service.

  In particular, it = specifies a set of operations for creating, = reading,

  writing, and = managing data objects at a remote server (or set = of

  servers) via a = HTTP protocol.

 <= /p>

1.0.2.  Data Access = Interface

 <= /p>

  Users can read = and write data objects, and also update data in = existing

  data = objects.  CDMI-specific operations are

  specified in = which data objects are embedded as fields inside of = a

  JSON Object, but = the protocol also defines interfaces in which = the

  contents of data = objects can be written via simple HTTP GET/PUT

  = operations.

 <= /p>

1.0.3.  Data = Management Operations

 <= /p>

  Users can delete = already-existing data objects.  The create = operation

  also supports = modes in which the created object is copied or = moved

  from an existing = data object.

 <= /p>

  Data System = Metadata also allows users to configure policies = regarding

  time-to-live = after which a data object is automatically deleted, as = well

  as the redundancy = with which a data object is stored.

 <= /p>

1.0.4.  Data Search = Capability

 <= /p>

  Users may list = the contents of containers to locate data objects = matching

  any desired = criteria.

 <= /p>

1.0.5.  Access = Control Authorization

 <= /p>

  CDMI supports = both public-unrestricted, public-restricted and private = modes.

 <= /p>

  In particular = CDMI allows access to data objects to be protected = by

  ACLs which can = allow or restrict access based on user, group, = administrative

  status, or = whether a user is authenticated or anonymous,

 <= /p>

1.0.6.  Resource = Control Interface

 <= /p>

  CDMI supports = attributes 'cdmi_max_latency' and 'cdmi_max_throughput' = (set

  at either the = level of containers, or a specific data object) = which

  control the level = of service offered to any users accessing a = particular

  data = object.

 <= /p>

1.0.7.  Discovery = Mechanism

 <= /p>

  Users are = provided a well-known DNS name.  The DNS name is resolved = to

  determine the IP = address to which requests may be sent.

 <= /p>

1.0.8.  Storage = Mode

 <= /p>

  Object-based, = with the extension that objects can be organized = into

  user-defined = containers.

 

 

 

------_=_NextPart_001_01CC4ECD.31CE3345-- From Dirk.Kutscher@neclab.eu Sat Jul 30 11:14:38 2011 Return-Path: X-Original-To: decade@ietfa.amsl.com Delivered-To: decade@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B21C021F8ABC for ; Sat, 30 Jul 2011 11:14:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.424 X-Spam-Level: X-Spam-Status: No, score=-2.424 tagged_above=-999 required=5 tests=[AWL=0.174, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VtquZzbhHEGE for ; Sat, 30 Jul 2011 11:14:36 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 86F6921F8AA8 for ; Sat, 30 Jul 2011 11:14:35 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 15D4B28000332; Sat, 30 Jul 2011 20:14:35 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office.hd) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas1.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nS4ZIEUxQ-mq; Sat, 30 Jul 2011 20:14:34 +0200 (CEST) Received: from ENCELADUS.office.hd (ENCELADUS.office.hd [192.168.24.52]) by mailer1.neclab.eu (Postfix) with ESMTP id E223B28000198; Sat, 30 Jul 2011 20:14:24 +0200 (CEST) Received: from DAPHNIS.office.hd ([169.254.2.20]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0270.001; Sat, 30 Jul 2011 20:14:25 +0200 From: Dirk Kutscher To: "Rahman, Akbar" , "decade@ietf.org" Thread-Topic: Proposed CDMI summary text for DECADE Survey Thread-Index: AcxOzTHT9OYJTgNlRt20ftscLI/PaQAFu8/g Date: Sat, 30 Jul 2011 18:14:25 +0000 Message-ID: <82AB329A76E2484D934BBCA77E9F52491CCA3232@DAPHNIS.office.hd> References: In-Reply-To: Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.7.0.202] Content-Type: multipart/alternative; boundary="_000_82AB329A76E2484D934BBCA77E9F52491CCA3232DAPHNISofficehd_" MIME-Version: 1.0 Subject: Re: [decade] Proposed CDMI summary text for DECADE Survey X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jul 2011 18:14:38 -0000 --_000_82AB329A76E2484D934BBCA77E9F52491CCA3232DAPHNISofficehd_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Akbar, Rich, Richard, Thanks for coming up with this that fast! Text looks good - I think we should mention the word "RESTful" somewhere - = maybe in the third paragraph of 1.0. Thanks, Dirk From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.org] On Behalf Of= Rahman, Akbar Sent: Saturday, July 30, 2011 5:27 PM To: decade@ietf.org Subject: [decade] Proposed CDMI summary text for DECADE Survey Hi All, As per the suggestion during the Quebec IETF meeting, we have come up with = the following proposed text for CDMI to add to the DECADE Survey. We would= appreciate if you could write back to us with any comments by the end of M= onday (August 1). We apologize for the short time frame, but since the Sur= vey will be discussed in the IESG telechat on Aug. 11, we need to update th= e Survey with this item quickly. Sincerely, Akbar/Rich/Richard P.S. We had a review of the proposed text by some CDMI experts and they wer= e okay with the text. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 1.0. Cloud Data Management Interface The Cloud Data Management Interface (CDMI) is a specification to access and manage cloud storage. CDMI is specified by the Storage Networking Industry Association (SNIA). CDMI is a functional interface that applications can use to create, retrieve, update and delete data elements from the cloud. As part of this interface the client will be able to discover the capabilities of the cloud storage offering and use this interface to manage containers and the data that is placed in them. In addition, metadata can be set on containers and their contained data elements through this interface. [Reference: http://www.snia.org/cdmi] CDMI follows a traditional client server model, and operates over HTTP. Similar to Amazon S3 buckets, users may create containers into which data objects may be stored. Even though data objects may be accessed via a user-defined name within a container, it is also possible to access data objects by a storage-defined Object ID which is provided in the response upon creation of a Data Object. 1.0.1. Applicability to DECADE CDMI is an important initiative to standardize storage interfaces for cloud services which are rapidly becoming an important storage service. In particular, it specifies a set of operations for creating, reading, writing, and managing data objects at a remote server (or set of servers) via a HTTP protocol. 1.0.2. Data Access Interface Users can read and write data objects, and also update data in existing data objects. CDMI-specific operations are specified in which data objects are embedded as fields inside of a JSON Object, but the protocol also defines interfaces in which the contents of data objects can be written via simple HTTP GET/PUT operations. 1.0.3. Data Management Operations Users can delete already-existing data objects. The create operation also supports modes in which the created object is copied or moved from an existing data object. Data System Metadata also allows users to configure policies regarding time-to-live after which a data object is automatically deleted, as well as the redundancy with which a data object is stored. 1.0.4. Data Search Capability Users may list the contents of containers to locate data objects matching any desired criteria. 1.0.5. Access Control Authorization CDMI supports both public-unrestricted, public-restricted and private mod= es. In particular CDMI allows access to data objects to be protected by ACLs which can allow or restrict access based on user, group, administrat= ive status, or whether a user is authenticated or anonymous, 1.0.6. Resource Control Interface CDMI supports attributes 'cdmi_max_latency' and 'cdmi_max_throughput' (se= t at either the level of containers, or a specific data object) which control the level of service offered to any users accessing a particular data object. 1.0.7. Discovery Mechanism Users are provided a well-known DNS name. The DNS name is resolved to determine the IP address to which requests may be sent. 1.0.8. Storage Mode Object-based, with the extension that objects can be organized into user-defined containers. --_000_82AB329A76E2484D934BBCA77E9F52491CCA3232DAPHNISofficehd_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Akbar, Rich, Richar= d,

 

Thanks for coming up w= ith this that fast!

 

Text looks good –= ; I think we should mention the word “RESTful” somewhere –= ; maybe in the third paragraph of 1.0.

 

Thanks,

 

Dirk=

 

 

 

 

From: decade-b= ounces@ietf.org [mailto:decade-bounces@ietf.org] On Behalf Of Rahman, Akbar
Sent: Saturday, July 30, 2011 5:27 PM
To: decade@ietf.org
Subject: [decade] Proposed CDMI summary text for DECADE Survey<= /o:p>

 

Hi All,

 

 

As per the suggestion during the Quebec IETF meeting= , we have come up with the following proposed text for CDMI to add to the D= ECADE Survey.  We would appreciate if you could write back to us with = any comments by the end of Monday (August 1).  We apologize for the short time frame, but since the Survey will= be discussed in the IESG telechat on Aug. 11, we need to update the Survey= with this item quickly.

 

 

Sincerely,

 

Akbar/Rich/Richard

 

 

P.S. We had a review of the proposed text by some CD= MI experts and they were okay with the text.

 

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D

 

1.0.  Cloud Data Management Interface

 

  The Cloud Data Management Interface (CDMI) is a specification to a= ccess

  and manage cloud storage.  CDMI is specified by the Storage&n= bsp; Networking

  Industry Association (SNIA).

 

 CDMI is a functional interface that applications can use to create,=

  retrieve, update and delete data elements from the cloud.  As= part of

  this interface the client will be able to discover the capabilitie= s of

  the cloud storage offering and use this interface to manage contai= ners

  and the data that is placed in them.  In addition, metadata c= an be set

  on containers and their contained data elements through this inter= face.

  [Reference: http://www.snia.org/cdmi]=

 

  CDMI follows a traditional client server model, and operates over = HTTP.

  Similar to Amazon S3 buckets, users may create containers into whi= ch

  data objects may be stored.  Even though data objects may be = accessed

  via a user-defined name within a container, it is also possible to= access

  data objects by a storage-defined Object ID which is provided in t= he

  response upon creation of a Data Object.

 

1.0.1.  Applicability to DECADE

 

  CDMI is an important initiative to standardize storage interfaces = for

  cloud services which are rapidly becoming an important storage ser= vice.

  In particular, it specifies a set of operations for creating, read= ing,

  writing, and managing data objects at a remote server (or set of

  servers) via a HTTP protocol.

 

1.0.2.  Data Access Interface

 

  Users can read and write data objects, and also update data in exi= sting

  data objects.  CDMI-specific operations are=

  specified in which data objects are embedded as fields inside of a=

  JSON Object, but the protocol also defines interfaces in which the=

  contents of data objects can be written via simple HTTP GET/PUT

  operations.

 

1.0.3.  Data Management Operations

 

  Users can delete already-existing data objects.  The create o= peration

  also supports modes in which the created object is copied or moved=

  from an existing data object.

 

  Data System Metadata also allows users to configure policies regar= ding

  time-to-live after which a data object is automatically deleted, a= s well

  as the redundancy with which a data object is stored.

 

1.0.4.  Data Search Capability

 

  Users may list the contents of containers to locate data objects m= atching

  any desired criteria.

 

1.0.5.  Access Control Authorization

 

  CDMI supports both public-unrestricted, public-restricted and priv= ate modes.

 

  In particular CDMI allows access to data objects to be protected b= y

  ACLs which can allow or restrict access based on user, group, admi= nistrative

  status, or whether a user is authenticated or anonymous,

 

1.0.6.  Resource Control Interface

 

  CDMI supports attributes 'cdmi_max_latency' and 'cdmi_max_throughp= ut' (set

  at either the level of containers, or a specific data object) whic= h

  control the level of service offered to any users accessing a part= icular

  data object.

 

1.0.7.  Discovery Mechanism

 

  Users are provided a well-known DNS name.  The DNS name is re= solved to

  determine the IP address to which requests may be sent.=

 

1.0.8.  Storage Mode

 

  Object-based, with the extension that objects can be organized int= o

  user-defined containers.

 

 

 

--_000_82AB329A76E2484D934BBCA77E9F52491CCA3232DAPHNISofficehd_-- From Akbar.Rahman@InterDigital.com Sat Jul 30 12:52:48 2011 Return-Path: X-Original-To: decade@ietfa.amsl.com Delivered-To: decade@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5B8021F87AF for ; Sat, 30 Jul 2011 12:52:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lhtxnb2PT0xY for ; Sat, 30 Jul 2011 12:52:47 -0700 (PDT) Received: from idcout.InterDigital.com (idcexmail.interdigital.com [12.32.197.135]) by ietfa.amsl.com (Postfix) with ESMTP id A67E721F8753 for ; Sat, 30 Jul 2011 12:52:47 -0700 (PDT) Received: from SAM.InterDigital.com ([10.30.2.11]) by idcout.InterDigital.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 30 Jul 2011 15:52:48 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 X-OriginalArrivalTime: 30 Jul 2011 18:14:37.0094 (UTC) FILETIME=[8A8D7C60:01CC4EE4] Content-Language: en-US X-Barracuda-Start-Time: 1312049675 X-Barracuda-Connect: mailer1.neclab.eu[195.37.70.40] X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.70425Rule breakdown below pts rule name description---- ---------------------- --------------------------------------------------0.00 HTML_MESSAGE BODY: HTML included in message X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=2.0 KILL_LEVEL=2.8 tests=HTML_MESSAGE X-ASG-Orig-Subj: RE: Proposed CDMI summary text for DECADE Survey X-ASG-Debug-ID: 1312049675-01e5e55bdc364f80001-kUr72C X-Barracuda-URL: http://172.22.1.3:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at interdigital.com X-Originating-IP: [10.7.0.202] X-Barracuda-Envelope-From: Dirk.Kutscher@neclab.eu Accept-Language: de-DE, en-US X-Barracuda-Apparent-Source-IP: 195.37.70.40 Content-class: urn:content-classes:message Date: Sat, 30 Jul 2011 15:52:48 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Proposed CDMI summary text for DECADE Survey Thread-Index: AcxOzTHT9OYJTgNlRt20ftscLI/PaQAFu8/gAAOIOWU= References: From: "Rahman, Akbar" To: "Dirk Kutscher" , Subject: Re: [decade] Proposed CDMI summary text for DECADE Survey X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jul 2011 19:52:48 -0000 SGkgRGlyaywNCg0KVGhhbmtzLiBZZXMsIHRoYXQgaXMgYSBnb29kIHN1Z2dlc3Rpb24gYW5kIHdl IHdpbGwgYWRkIGluIHRoZSByZWZlcmVuY2UgdG8gUkVTVGZ1bCBpbnRlcmZhY2UgYXMgeW91IHN1 Z2dlc3RlZC4NCg0KQWtiYXINCg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9t OiBEaXJrIEt1dHNjaGVyIFtEaXJrLkt1dHNjaGVyQG5lY2xhYi5ldV0NClNlbnQ6IFNhdHVyZGF5 LCBKdWx5IDMwLCAyMDExIDAyOjE0IFBNIEVhc3Rlcm4gU3RhbmRhcmQgVGltZQ0KVG86IFJhaG1h biwgQWtiYXI7IGRlY2FkZUBpZXRmLm9yZw0KU3ViamVjdDogUkU6IFByb3Bvc2VkIENETUkgc3Vt bWFyeSB0ZXh0IGZvciBERUNBREUgU3VydmV5DQoNCg0KDQpIaSBBa2JhciwgUmljaCwgUmljaGFy ZCwNCg0KIA0KDQpUaGFua3MgZm9yIGNvbWluZyB1cCB3aXRoIHRoaXMgdGhhdCBmYXN0IQ0KDQog DQoNClRleHQgbG9va3MgZ29vZCDigJMgSSB0aGluayB3ZSBzaG91bGQgbWVudGlvbiB0aGUgd29y ZCDigJxSRVNUZnVs4oCdIHNvbWV3aGVyZSDigJMgbWF5YmUgaW4gdGhlIHRoaXJkIHBhcmFncmFw aCBvZiAxLjAuDQoNCiANCg0KVGhhbmtzLA0KDQogDQoNCkRpcmsNCg0KIA0KDQogDQoNCiANCg0K IA0KDQpGcm9tOiBkZWNhZGUtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmRlY2FkZS1ib3VuY2Vz QGlldGYub3JnXSBPbiBCZWhhbGYgT2YgUmFobWFuLCBBa2Jhcg0KU2VudDogU2F0dXJkYXksIEp1 bHkgMzAsIDIwMTEgNToyNyBQTQ0KVG86IGRlY2FkZUBpZXRmLm9yZw0KU3ViamVjdDogW2RlY2Fk ZV0gUHJvcG9zZWQgQ0RNSSBzdW1tYXJ5IHRleHQgZm9yIERFQ0FERSBTdXJ2ZXkNCg0KIA0KDQpI aSBBbGwsDQoNCiANCg0KIA0KDQpBcyBwZXIgdGhlIHN1Z2dlc3Rpb24gZHVyaW5nIHRoZSBRdWVi ZWMgSUVURiBtZWV0aW5nLCB3ZSBoYXZlIGNvbWUgdXAgd2l0aCB0aGUgZm9sbG93aW5nIHByb3Bv c2VkIHRleHQgZm9yIENETUkgdG8gYWRkIHRvIHRoZSBERUNBREUgU3VydmV5LiAgV2Ugd291bGQg YXBwcmVjaWF0ZSBpZiB5b3UgY291bGQgd3JpdGUgYmFjayB0byB1cyB3aXRoIGFueSBjb21tZW50 cyBieSB0aGUgZW5kIG9mIE1vbmRheSAoQXVndXN0IDEpLiAgV2UgYXBvbG9naXplIGZvciB0aGUg c2hvcnQgdGltZSBmcmFtZSwgYnV0IHNpbmNlIHRoZSBTdXJ2ZXkgd2lsbCBiZSBkaXNjdXNzZWQg aW4gdGhlIElFU0cgdGVsZWNoYXQgb24gQXVnLiAxMSwgd2UgbmVlZCB0byB1cGRhdGUgdGhlIFN1 cnZleSB3aXRoIHRoaXMgaXRlbSBxdWlja2x5Lg0KDQogDQoNCiANCg0KU2luY2VyZWx5LA0KDQog DQoNCkFrYmFyL1JpY2gvUmljaGFyZA0KDQogDQoNCiANCg0KUC5TLiBXZSBoYWQgYSByZXZpZXcg b2YgdGhlIHByb3Bvc2VkIHRleHQgYnkgc29tZSBDRE1JIGV4cGVydHMgYW5kIHRoZXkgd2VyZSBv a2F5IHdpdGggdGhlIHRleHQuIA0KDQogDQoNCiANCg0KPT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCg0KIA0K DQoxLjAuICBDbG91ZCBEYXRhIE1hbmFnZW1lbnQgSW50ZXJmYWNlDQoNCiANCg0KICBUaGUgQ2xv dWQgRGF0YSBNYW5hZ2VtZW50IEludGVyZmFjZSAoQ0RNSSkgaXMgYSBzcGVjaWZpY2F0aW9uIHRv IGFjY2Vzcw0KDQogIGFuZCBtYW5hZ2UgY2xvdWQgc3RvcmFnZS4gIENETUkgaXMgc3BlY2lmaWVk IGJ5IHRoZSBTdG9yYWdlICBOZXR3b3JraW5nDQoNCiAgSW5kdXN0cnkgQXNzb2NpYXRpb24gKFNO SUEpLg0KDQogDQoNCiBDRE1JIGlzIGEgZnVuY3Rpb25hbCBpbnRlcmZhY2UgdGhhdCBhcHBsaWNh dGlvbnMgY2FuIHVzZSB0byBjcmVhdGUsDQoNCiAgcmV0cmlldmUsIHVwZGF0ZSBhbmQgZGVsZXRl IGRhdGEgZWxlbWVudHMgZnJvbSB0aGUgY2xvdWQuICBBcyBwYXJ0IG9mDQoNCiAgdGhpcyBpbnRl cmZhY2UgdGhlIGNsaWVudCB3aWxsIGJlIGFibGUgdG8gZGlzY292ZXIgdGhlIGNhcGFiaWxpdGll cyBvZg0KDQogIHRoZSBjbG91ZCBzdG9yYWdlIG9mZmVyaW5nIGFuZCB1c2UgdGhpcyBpbnRlcmZh Y2UgdG8gbWFuYWdlIGNvbnRhaW5lcnMNCg0KICBhbmQgdGhlIGRhdGEgdGhhdCBpcyBwbGFjZWQg aW4gdGhlbS4gIEluIGFkZGl0aW9uLCBtZXRhZGF0YSBjYW4gYmUgc2V0DQoNCiAgb24gY29udGFp bmVycyBhbmQgdGhlaXIgY29udGFpbmVkIGRhdGEgZWxlbWVudHMgdGhyb3VnaCB0aGlzIGludGVy ZmFjZS4NCg0KICBbUmVmZXJlbmNlOiBodHRwOi8vd3d3LnNuaWEub3JnL2NkbWldIDxodHRwOi8v d3d3LnNuaWEub3JnL2NkbWklNWQ+IA0KDQogDQoNCiAgQ0RNSSBmb2xsb3dzIGEgdHJhZGl0aW9u YWwgY2xpZW50IHNlcnZlciBtb2RlbCwgYW5kIG9wZXJhdGVzIG92ZXIgSFRUUC4NCg0KICBTaW1p bGFyIHRvIEFtYXpvbiBTMyBidWNrZXRzLCB1c2VycyBtYXkgY3JlYXRlIGNvbnRhaW5lcnMgaW50 byB3aGljaA0KDQogIGRhdGEgb2JqZWN0cyBtYXkgYmUgc3RvcmVkLiAgRXZlbiB0aG91Z2ggZGF0 YSBvYmplY3RzIG1heSBiZSBhY2Nlc3NlZA0KDQogIHZpYSBhIHVzZXItZGVmaW5lZCBuYW1lIHdp dGhpbiBhIGNvbnRhaW5lciwgaXQgaXMgYWxzbyBwb3NzaWJsZSB0byBhY2Nlc3MNCg0KICBkYXRh IG9iamVjdHMgYnkgYSBzdG9yYWdlLWRlZmluZWQgT2JqZWN0IElEIHdoaWNoIGlzIHByb3ZpZGVk IGluIHRoZQ0KDQogIHJlc3BvbnNlIHVwb24gY3JlYXRpb24gb2YgYSBEYXRhIE9iamVjdC4NCg0K IA0KDQoxLjAuMS4gIEFwcGxpY2FiaWxpdHkgdG8gREVDQURFDQoNCiANCg0KICBDRE1JIGlzIGFu IGltcG9ydGFudCBpbml0aWF0aXZlIHRvIHN0YW5kYXJkaXplIHN0b3JhZ2UgaW50ZXJmYWNlcyBm b3INCg0KICBjbG91ZCBzZXJ2aWNlcyB3aGljaCBhcmUgcmFwaWRseSBiZWNvbWluZyBhbiBpbXBv cnRhbnQgc3RvcmFnZSBzZXJ2aWNlLg0KDQogIEluIHBhcnRpY3VsYXIsIGl0IHNwZWNpZmllcyBh IHNldCBvZiBvcGVyYXRpb25zIGZvciBjcmVhdGluZywgcmVhZGluZywNCg0KICB3cml0aW5nLCBh bmQgbWFuYWdpbmcgZGF0YSBvYmplY3RzIGF0IGEgcmVtb3RlIHNlcnZlciAob3Igc2V0IG9mDQoN CiAgc2VydmVycykgdmlhIGEgSFRUUCBwcm90b2NvbC4NCg0KIA0KDQoxLjAuMi4gIERhdGEgQWNj ZXNzIEludGVyZmFjZQ0KDQogDQoNCiAgVXNlcnMgY2FuIHJlYWQgYW5kIHdyaXRlIGRhdGEgb2Jq ZWN0cywgYW5kIGFsc28gdXBkYXRlIGRhdGEgaW4gZXhpc3RpbmcNCg0KICBkYXRhIG9iamVjdHMu ICBDRE1JLXNwZWNpZmljIG9wZXJhdGlvbnMgYXJlDQoNCiAgc3BlY2lmaWVkIGluIHdoaWNoIGRh dGEgb2JqZWN0cyBhcmUgZW1iZWRkZWQgYXMgZmllbGRzIGluc2lkZSBvZiBhDQoNCiAgSlNPTiBP YmplY3QsIGJ1dCB0aGUgcHJvdG9jb2wgYWxzbyBkZWZpbmVzIGludGVyZmFjZXMgaW4gd2hpY2gg dGhlDQoNCiAgY29udGVudHMgb2YgZGF0YSBvYmplY3RzIGNhbiBiZSB3cml0dGVuIHZpYSBzaW1w bGUgSFRUUCBHRVQvUFVUDQoNCiAgb3BlcmF0aW9ucy4NCg0KIA0KDQoxLjAuMy4gIERhdGEgTWFu YWdlbWVudCBPcGVyYXRpb25zDQoNCiANCg0KICBVc2VycyBjYW4gZGVsZXRlIGFscmVhZHktZXhp c3RpbmcgZGF0YSBvYmplY3RzLiAgVGhlIGNyZWF0ZSBvcGVyYXRpb24NCg0KICBhbHNvIHN1cHBv cnRzIG1vZGVzIGluIHdoaWNoIHRoZSBjcmVhdGVkIG9iamVjdCBpcyBjb3BpZWQgb3IgbW92ZWQN Cg0KICBmcm9tIGFuIGV4aXN0aW5nIGRhdGEgb2JqZWN0Lg0KDQogDQoNCiAgRGF0YSBTeXN0ZW0g TWV0YWRhdGEgYWxzbyBhbGxvd3MgdXNlcnMgdG8gY29uZmlndXJlIHBvbGljaWVzIHJlZ2FyZGlu Zw0KDQogIHRpbWUtdG8tbGl2ZSBhZnRlciB3aGljaCBhIGRhdGEgb2JqZWN0IGlzIGF1dG9tYXRp Y2FsbHkgZGVsZXRlZCwgYXMgd2VsbA0KDQogIGFzIHRoZSByZWR1bmRhbmN5IHdpdGggd2hpY2gg YSBkYXRhIG9iamVjdCBpcyBzdG9yZWQuDQoNCiANCg0KMS4wLjQuICBEYXRhIFNlYXJjaCBDYXBh YmlsaXR5DQoNCiANCg0KICBVc2VycyBtYXkgbGlzdCB0aGUgY29udGVudHMgb2YgY29udGFpbmVy cyB0byBsb2NhdGUgZGF0YSBvYmplY3RzIG1hdGNoaW5nDQoNCiAgYW55IGRlc2lyZWQgY3JpdGVy aWEuDQoNCiANCg0KMS4wLjUuICBBY2Nlc3MgQ29udHJvbCBBdXRob3JpemF0aW9uDQoNCiANCg0K ICBDRE1JIHN1cHBvcnRzIGJvdGggcHVibGljLXVucmVzdHJpY3RlZCwgcHVibGljLXJlc3RyaWN0 ZWQgYW5kIHByaXZhdGUgbW9kZXMuDQoNCiANCg0KICBJbiBwYXJ0aWN1bGFyIENETUkgYWxsb3dz IGFjY2VzcyB0byBkYXRhIG9iamVjdHMgdG8gYmUgcHJvdGVjdGVkIGJ5DQoNCiAgQUNMcyB3aGlj aCBjYW4gYWxsb3cgb3IgcmVzdHJpY3QgYWNjZXNzIGJhc2VkIG9uIHVzZXIsIGdyb3VwLCBhZG1p bmlzdHJhdGl2ZQ0KDQogIHN0YXR1cywgb3Igd2hldGhlciBhIHVzZXIgaXMgYXV0aGVudGljYXRl ZCBvciBhbm9ueW1vdXMsDQoNCiANCg0KMS4wLjYuICBSZXNvdXJjZSBDb250cm9sIEludGVyZmFj ZQ0KDQogDQoNCiAgQ0RNSSBzdXBwb3J0cyBhdHRyaWJ1dGVzICdjZG1pX21heF9sYXRlbmN5JyBh bmQgJ2NkbWlfbWF4X3Rocm91Z2hwdXQnIChzZXQNCg0KICBhdCBlaXRoZXIgdGhlIGxldmVsIG9m IGNvbnRhaW5lcnMsIG9yIGEgc3BlY2lmaWMgZGF0YSBvYmplY3QpIHdoaWNoDQoNCiAgY29udHJv bCB0aGUgbGV2ZWwgb2Ygc2VydmljZSBvZmZlcmVkIHRvIGFueSB1c2VycyBhY2Nlc3NpbmcgYSBw YXJ0aWN1bGFyDQoNCiAgZGF0YSBvYmplY3QuDQoNCiANCg0KMS4wLjcuICBEaXNjb3ZlcnkgTWVj aGFuaXNtDQoNCiANCg0KICBVc2VycyBhcmUgcHJvdmlkZWQgYSB3ZWxsLWtub3duIEROUyBuYW1l LiAgVGhlIEROUyBuYW1lIGlzIHJlc29sdmVkIHRvDQoNCiAgZGV0ZXJtaW5lIHRoZSBJUCBhZGRy ZXNzIHRvIHdoaWNoIHJlcXVlc3RzIG1heSBiZSBzZW50Lg0KDQogDQoNCjEuMC44LiAgU3RvcmFn ZSBNb2RlDQoNCiANCg0KICBPYmplY3QtYmFzZWQsIHdpdGggdGhlIGV4dGVuc2lvbiB0aGF0IG9i amVjdHMgY2FuIGJlIG9yZ2FuaXplZCBpbnRvDQoNCiAgdXNlci1kZWZpbmVkIGNvbnRhaW5lcnMu DQoNCiANCg0KIA0KDQogDQoNCg==