From iesg-secretary@ietf.org Thu Sep 1 15:44:31 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 7813A21F97A0; Thu, 1 Sep 2011 15:44:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7WUltDW1j3NT; Thu, 1 Sep 2011 15:44:30 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A273721F97AA; Thu, 1 Sep 2011 15:44:30 -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.60 Message-ID: <20110901224430.10357.24338.idtracker@ietfa.amsl.com> Date: Thu, 01 Sep 2011 15:44:30 -0700 Cc: decade mailing list , decade chair , RFC Editor Subject: [decade] Document Action: 'A Survey of In-network Storage Systems' to Informational RFC (draft-ietf-decade-survey-06.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: Thu, 01 Sep 2011 22:44:31 -0000 The IESG has approved the following document: - 'A Survey of In-network Storage Systems' (draft-ietf-decade-survey-06.txt) as an Informational RFC This document is the product of the Decoupled Application Data Enroute Working Group. The IESG contact persons are David Harrington and Wesley Eddy. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-decade-survey/ Technical Summary This document surveys deployed and experimental in-network storage systems and describes their applicability for DECADE. This document analyzes the systems from several perspectives such as data access, data management, data search, access control, resource control, etc. The document also analyze from the protocol level to see if the relevant protocol meets DECADE requirements. Working Group Summary This document is a product of the DECADE WG, and was reviewed in working group meetings and via the decade@ietf.org list. The WG supported this document for publication. Many WG members have read and agree with it. Document Quality This is an informational survey, not a protocol specification, so there are no implementations of the specification. The survey documents existing proprietary solutions. The document was reviewed by the WG members, WG Chairs, and key WG and non WG members. Richard Alimi (ralimi@google.com) and Akbar Rahman (Akbar.Rahman@InterDigital.com) contributed a lot to solve the comments and refine the text. This document uses URLs in the References section, but they are all Informative References. Personnel Document Shepherd: Haibin Song (haibin.song@huawei.com) Responsible Area Director: David Harrington (ietfdbh@comcast.net) This document does not have any IANA considerations. No Expert Review process is needed. From dave.mcdysan@verizon.com Fri Sep 2 05:45: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 10B6021F8EDA for ; Fri, 2 Sep 2011 05:45:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.464 X-Spam-Level: X-Spam-Status: No, score=-2.464 tagged_above=-999 required=5 tests=[AWL=0.135, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U18DpaTuvN8K for ; Fri, 2 Sep 2011 05:45:43 -0700 (PDT) Received: from fldsmtpe01.verizon.com (fldsmtpe01.verizon.com [140.108.26.140]) by ietfa.amsl.com (Postfix) with ESMTP id 62A3421F8ED9 for ; Fri, 2 Sep 2011 05:45:42 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: false Received: from unknown (HELO fldsmtpi01.verizon.com) ([166.68.71.143]) by fldsmtpe01.verizon.com with ESMTP; 02 Sep 2011 12:47:16 +0000 From: "Mcdysan, David E" X-IronPort-AV: E=Sophos;i="4.68,319,1312156800"; d="scan'208";a="127184015" Received: from fhdp1lumxc7hb01.verizon.com (HELO FHDP1LUMXC7HB01.us.one.verizon.com) ([166.68.59.188]) by fldsmtpi01.verizon.com with ESMTP; 02 Sep 2011 12:47:14 +0000 Received: from fhdp1lumxc7v11.us.one.verizon.com ([169.254.1.15]) by FHDP1LUMXC7HB01.us.one.verizon.com ([166.68.59.188]) with mapi; Fri, 2 Sep 2011 08:47:10 -0400 To: "Rahman, Akbar" , Songhaibin Date: Fri, 2 Sep 2011 08:47:08 -0400 Thread-Topic: [decade] Remaining issue: meta data issue Thread-Index: Acxpbm1zK5by5AZqQFGfCeGG7RwoVA== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.1.0.101012 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "decade@ietf.org" Subject: Re: [decade] Remaining issue: meta data issue 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: Fri, 02 Sep 2011 12:45:44 -0000 Hi Rahman, In your point 2 below is it actually an "Access Control List" or some form of authentication token? Thanks, Dave On Tuesday8/23/11 11:44 AM, "Rahman, Akbar" wrote: >Hi Haibin, > > >From the Quebec city minutes > >http://www.ietf.org/proceedings/81/minutes/decade.txt > > >I understood that the following issues were open for DECADE metadata: >1) Do we make metadata immutable? >2) What is contained in the metadata? > > >My feedback is as follows: >1) Yes, make metadata immutable >2) Define a minimum set of information for the metadata. So far, Time >To Live (TTL) and Access Control List (ACL) were discussed and seem to >be two items that are logical to include in the metadata > > >I would be interested in hearing feedback from other members of the WG. > > >Akbar > > >-----Original Message----- >From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.org] On Behalf >Of Songhaibin >Sent: Monday, August 22, 2011 4:50 AM >To: decade@ietf.org >Subject: [decade] Remaining issue: meta data issue > >Dear all, > >I would suggest to have more discussion about the remaining issue from >the past IETF meeting. We may continue the discussion about meta data. >If we can solve it here in the list, we can update the architecture >draft (maybe the reqs draft as well) and start the WGLC for them. > >BR, >-Haibin >_______________________________________________ >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 Akbar.Rahman@InterDigital.com Fri Sep 2 07:56:33 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 56CD621F856A for ; Fri, 2 Sep 2011 07:56:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.446 X-Spam-Level: X-Spam-Status: No, score=-2.446 tagged_above=-999 required=5 tests=[AWL=0.153, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4pAZRjvKqXrY for ; Fri, 2 Sep 2011 07:56:32 -0700 (PDT) Received: from idcout.InterDigital.com (idcexmail.interdigital.com [12.32.197.135]) by ietfa.amsl.com (Postfix) with ESMTP id 8656321F8519 for ; Fri, 2 Sep 2011 07:56:32 -0700 (PDT) Received: from SAM.InterDigital.com ([10.30.2.12]) by idcout.InterDigital.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 2 Sep 2011 10:58:07 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 2 Sep 2011 10:58:07 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-topic: [decade] Remaining issue: meta data issue Thread-index: Acxpbm1zK5by5AZqQFGfCeGG7RwoVAAEIFOg References: From: "Rahman, Akbar" To: "Mcdysan, David E" X-OriginalArrivalTime: 02 Sep 2011 14:58:07.0821 (UTC) FILETIME=[B9A4AFD0:01CC6980] Cc: decade@ietf.org Subject: Re: [decade] Remaining issue: meta data issue 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: Fri, 02 Sep 2011 14:56:33 -0000 Hi Dave, My understanding is that the DECADE authentication token will be passed separately from the metadata by the DECADE Resource Protocol (DRP). So I am proposing that the ACL would be a separate item from the authentication token, and that the ACL would be included as part of the metadata (which would be sent on the SDT). My thinking is that a lot of VoD type content today has some sort of ACL type data associated with it today and that philosophy should carry forward in DECADE. I would be interested to hear any counter arguments though. Akbar -----Original Message----- From: Mcdysan, David E [mailto:dave.mcdysan@verizon.com]=20 Sent: Friday, September 02, 2011 8:47 AM To: Rahman, Akbar; Songhaibin Cc: decade@ietf.org Subject: Re: [decade] Remaining issue: meta data issue Hi Rahman, In your point 2 below is it actually an "Access Control List" or some form of authentication token? Thanks, Dave On Tuesday8/23/11 11:44 AM, "Rahman, Akbar" wrote: >Hi Haibin, > > >From the Quebec city minutes > >http://www.ietf.org/proceedings/81/minutes/decade.txt > > >I understood that the following issues were open for DECADE metadata: >1) Do we make metadata immutable? >2) What is contained in the metadata? > > >My feedback is as follows: >1) Yes, make metadata immutable >2) Define a minimum set of information for the metadata. So far, Time >To Live (TTL) and Access Control List (ACL) were discussed and seem to >be two items that are logical to include in the metadata > > >I would be interested in hearing feedback from other members of the WG. > > >Akbar > > >-----Original Message----- >From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.org] On Behalf >Of Songhaibin >Sent: Monday, August 22, 2011 4:50 AM >To: decade@ietf.org >Subject: [decade] Remaining issue: meta data issue > >Dear all, > >I would suggest to have more discussion about the remaining issue from >the past IETF meeting. We may continue the discussion about meta data. >If we can solve it here in the list, we can update the architecture >draft (maybe the reqs draft as well) and start the WGLC for them. > >BR, >-Haibin >_______________________________________________ >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 guyingjie@huawei.com Tue Sep 6 07:31:34 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 46FAD21F86A1 for ; Tue, 6 Sep 2011 07:31:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.788 X-Spam-Level: X-Spam-Status: No, score=-102.788 tagged_above=-999 required=5 tests=[AWL=0.422, BAYES_00=-2.599, CN_BODY_35=0.339, J_CHICKENPOX_41=0.6, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id krePvKbk08Wa for ; Tue, 6 Sep 2011 07:31:33 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 7187121F866A for ; Tue, 6 Sep 2011 07:31:33 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LR300I40V3IZS@szxga04-in.huawei.com> for decade@ietf.org; Tue, 06 Sep 2011 22:33:19 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LR300A4LV3ICI@szxga04-in.huawei.com> for decade@ietf.org; Tue, 06 Sep 2011 22:33:18 +0800 (CST) Received: from szxeml203-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id ADV20993; Tue, 06 Sep 2011 22:33:18 +0800 Received: from SZXEML404-HUB.china.huawei.com (10.82.67.59) by szxeml203-edg.china.huawei.com (172.24.2.55) with Microsoft SMTP Server (TLS) id 14.1.270.1; Tue, 06 Sep 2011 22:33:15 +0800 Received: from g00107907 (10.138.41.134) by szxeml404-hub.china.huawei.com (10.82.67.59) with Microsoft SMTP Server (TLS) id 14.1.270.1; Tue, 06 Sep 2011 22:33:17 +0800 Date: Tue, 06 Sep 2011 22:35:03 +0800 From: "Yingjie Gu(yingjie)" In-reply-to: X-Originating-IP: [10.138.41.134] To: "'Rahman, Akbar'" , "'Mcdysan, David E'" Message-id: <004601cc6ca2$2a9855b0$7fc90110$@com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=gb2312 Content-language: zh-cn Content-transfer-encoding: quoted-printable Thread-index: Acxpbm1zK5by5AZqQFGfCeGG7RwoVAAEIFOgAMhfqkA= X-CFilter-Loop: Reflected References: Cc: decade@ietf.org Subject: Re: [decade] Remaining issue: meta data issue 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, 06 Sep 2011 14:31:34 -0000 First of all, I think the ACL is a good use case for metadata.=20 But since the ACL could change with time, e.g. Client A can access now = but is denied after a while, the metadata couldn't be immutable. If I understand correctly, ACL and token are two ways to get to the same purpose: access control. You can either use ACL by metadata or use Token transferred by DRP, or even use them at the same time(I don't see the = reason for doing this for now).=20 If we want to support both, at least one of them should be mandatory.=20 Best Regards Gu Yingjie -----=D3=CA=BC=FE=D4=AD=BC=FE----- =B7=A2=BC=FE=C8=CB: decade-bounces@ietf.org = [mailto:decade-bounces@ietf.org] =B4=FA=B1=ED Rahman, Akbar =B7=A2=CB=CD=CA=B1=BC=E4: 2011=C4=EA9=D4=C22=C8=D5 =C0=D6=C0=D622:58 =CA=D5=BC=FE=C8=CB: Mcdysan, David E =B3=AD=CB=CD: decade@ietf.org =D6=F7=CC=E2: Re: [decade] Remaining issue: meta data issue Hi Dave, My understanding is that the DECADE authentication token will be passed separately from the metadata by the DECADE Resource Protocol (DRP). So I am proposing that the ACL would be a separate item from the authentication token, and that the ACL would be included as part of the metadata (which would be sent on the SDT). My thinking is that a lot of VoD type content today has some sort of ACL type data associated with it today and that philosophy should carry forward in DECADE. I would be interested to hear any counter arguments though. Akbar -----Original Message----- From: Mcdysan, David E [mailto:dave.mcdysan@verizon.com]=20 Sent: Friday, September 02, 2011 8:47 AM To: Rahman, Akbar; Songhaibin Cc: decade@ietf.org Subject: Re: [decade] Remaining issue: meta data issue Hi Rahman, In your point 2 below is it actually an "Access Control List" or some form of authentication token? Thanks, Dave On Tuesday8/23/11 11:44 AM, "Rahman, Akbar" wrote: >Hi Haibin, > > >From the Quebec city minutes > >http://www.ietf.org/proceedings/81/minutes/decade.txt > > >I understood that the following issues were open for DECADE metadata: >1) Do we make metadata immutable? >2) What is contained in the metadata? > > >My feedback is as follows: >1) Yes, make metadata immutable >2) Define a minimum set of information for the metadata. So far, Time >To Live (TTL) and Access Control List (ACL) were discussed and seem to >be two items that are logical to include in the metadata > > >I would be interested in hearing feedback from other members of the WG. > > >Akbar > > >-----Original Message----- >From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.org] On Behalf >Of Songhaibin >Sent: Monday, August 22, 2011 4:50 AM >To: decade@ietf.org >Subject: [decade] Remaining issue: meta data issue > >Dear all, > >I would suggest to have more discussion about the remaining issue from >the past IETF meeting. We may continue the discussion about meta data. >If we can solve it here in the list, we can update the architecture >draft (maybe the reqs draft as well) and start the WGLC for them. > >BR, >-Haibin >_______________________________________________ >decade mailing list >decade@ietf.org >https://www.ietf.org/mailman/listinfo/decade >_______________________________________________ >decade mailing list >decade@ietf.org >https://www.ietf.org/mailman/listinfo/decade _______________________________________________ decade mailing list decade@ietf.org https://www.ietf.org/mailman/listinfo/decade From Akbar.Rahman@InterDigital.com Wed Sep 7 11:24:56 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 819F621F8D41 for ; Wed, 7 Sep 2011 11:24:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.768 X-Spam-Level: X-Spam-Status: No, score=-0.768 tagged_above=-999 required=5 tests=[AWL=-1.558, BAYES_00=-2.599, CN_BODY_35=0.339, J_CHICKENPOX_41=0.6, MIME_CHARSET_FARAWAY=2.45] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P-IWaBDoG8GC for ; Wed, 7 Sep 2011 11:24:55 -0700 (PDT) Received: from idcout.InterDigital.com (idcexmail.interdigital.com [12.32.197.135]) by ietfa.amsl.com (Postfix) with ESMTP id 0916521F8D2A for ; Wed, 7 Sep 2011 11:24:54 -0700 (PDT) Received: from SAM.InterDigital.com ([10.30.2.12]) by idcout.InterDigital.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 7 Sep 2011 14:26:40 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Date: Wed, 7 Sep 2011 14:26:39 -0400 Message-ID: In-Reply-To: <004601cc6ca2$2a9855b0$7fc90110$@com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-topic: [decade] Remaining issue: meta data issue Thread-index: Acxpbm1zK5by5AZqQFGfCeGG7RwoVAAEIFOgAMhfqkAAOrjaYA== References: <004601cc6ca2$2a9855b0$7fc90110$@com> From: "Rahman, Akbar" To: "Yingjie Gu(yingjie)" X-OriginalArrivalTime: 07 Sep 2011 18:26:40.0699 (UTC) FILETIME=[AFF718B0:01CC6D8B] Cc: decade@ietf.org Subject: Re: [decade] Remaining issue: meta data issue 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, 07 Sep 2011 18:24:56 -0000 Hi Yingjie, Thanks for the comment. With regards to your comment on the potential = for ACL to change over time. I think that Haibin made a similar comment = for TTL (i.e. only take the hash over the data and do NOT include = metadata): http://www.ietf.org/mail-archive/web/decade/current/msg00483.html Akbar -----Original Message----- From: Yingjie Gu(yingjie) [mailto:guyingjie@huawei.com]=20 Sent: Tuesday, September 06, 2011 10:35 AM To: Rahman, Akbar; 'Mcdysan, David E' Cc: decade@ietf.org Subject: RE: [decade] Remaining issue: meta data issue First of all, I think the ACL is a good use case for metadata.=20 But since the ACL could change with time, e.g. Client A can access now = but is denied after a while, the metadata couldn't be immutable. If I understand correctly, ACL and token are two ways to get to the same purpose: access control. You can either use ACL by metadata or use Token transferred by DRP, or even use them at the same time(I don't see the = reason for doing this for now).=20 If we want to support both, at least one of them should be mandatory.=20 Best Regards Gu Yingjie -----=D3=CA=BC=FE=D4=AD=BC=FE----- =B7=A2=BC=FE=C8=CB: decade-bounces@ietf.org = [mailto:decade-bounces@ietf.org] =B4=FA=B1=ED Rahman, Akbar =B7=A2=CB=CD=CA=B1=BC=E4: 2011=C4=EA9=D4=C22=C8=D5 =C0=D6=C0=D622:58 =CA=D5=BC=FE=C8=CB: Mcdysan, David E =B3=AD=CB=CD: decade@ietf.org =D6=F7=CC=E2: Re: [decade] Remaining issue: meta data issue Hi Dave, My understanding is that the DECADE authentication token will be passed separately from the metadata by the DECADE Resource Protocol (DRP). So I am proposing that the ACL would be a separate item from the authentication token, and that the ACL would be included as part of the metadata (which would be sent on the SDT). My thinking is that a lot of VoD type content today has some sort of ACL type data associated with it today and that philosophy should carry forward in DECADE. I would be interested to hear any counter arguments though. Akbar -----Original Message----- From: Mcdysan, David E [mailto:dave.mcdysan@verizon.com]=20 Sent: Friday, September 02, 2011 8:47 AM To: Rahman, Akbar; Songhaibin Cc: decade@ietf.org Subject: Re: [decade] Remaining issue: meta data issue Hi Rahman, In your point 2 below is it actually an "Access Control List" or some form of authentication token? Thanks, Dave On Tuesday8/23/11 11:44 AM, "Rahman, Akbar" wrote: >Hi Haibin, > > >From the Quebec city minutes > >http://www.ietf.org/proceedings/81/minutes/decade.txt > > >I understood that the following issues were open for DECADE metadata: >1) Do we make metadata immutable? >2) What is contained in the metadata? > > >My feedback is as follows: >1) Yes, make metadata immutable >2) Define a minimum set of information for the metadata. So far, Time >To Live (TTL) and Access Control List (ACL) were discussed and seem to >be two items that are logical to include in the metadata > > >I would be interested in hearing feedback from other members of the WG. > > >Akbar > > >-----Original Message----- >From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.org] On Behalf >Of Songhaibin >Sent: Monday, August 22, 2011 4:50 AM >To: decade@ietf.org >Subject: [decade] Remaining issue: meta data issue > >Dear all, > >I would suggest to have more discussion about the remaining issue from >the past IETF meeting. We may continue the discussion about meta data. >If we can solve it here in the list, we can update the architecture >draft (maybe the reqs draft as well) and start the WGLC for them. > >BR, >-Haibin >_______________________________________________ >decade mailing list >decade@ietf.org >https://www.ietf.org/mailman/listinfo/decade >_______________________________________________ >decade mailing list >decade@ietf.org >https://www.ietf.org/mailman/listinfo/decade _______________________________________________ decade mailing list decade@ietf.org https://www.ietf.org/mailman/listinfo/decade From Akbar.Rahman@InterDigital.com Tue Sep 13 07:04:45 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 3F72321F8AE9 for ; Tue, 13 Sep 2011 07:04:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.307 X-Spam-Level: X-Spam-Status: No, score=-2.307 tagged_above=-999 required=5 tests=[AWL=0.292, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T0PbQcPQOteQ for ; Tue, 13 Sep 2011 07:04:44 -0700 (PDT) Received: from idcout.InterDigital.com (idcexmail.interdigital.com [12.32.197.135]) by ietfa.amsl.com (Postfix) with ESMTP id AB42621F8AE1 for ; Tue, 13 Sep 2011 07:04:44 -0700 (PDT) Received: from SAM.InterDigital.com ([10.30.2.12]) by idcout.InterDigital.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 13 Sep 2011 10:06:50 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 13 Sep 2011 10:06:49 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-topic: [decade] Remaining issue: meta data issue Thread-index: AcxgqId3hwBp3yEdQ32bcG9H5LPNwgRdbVUg References: From: "Rahman, Akbar" To: "Songhaibin" X-OriginalArrivalTime: 13 Sep 2011 14:06:50.0263 (UTC) FILETIME=[61D1DA70:01CC721E] Cc: decade@ietf.org Subject: Re: [decade] Remaining issue: meta data issue 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, 13 Sep 2011 14:04:45 -0000 Hi Haibin, We have had some discussion on this topic on the list. Do you consider the issue resolved, and can we update the architecture draft to start the WGLC? Akbar -----Original Message----- From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.org] On Behalf Of Songhaibin Sent: Monday, August 22, 2011 4:50 AM To: decade@ietf.org Subject: [decade] Remaining issue: meta data issue Dear all, I would suggest to have more discussion about the remaining issue from the past IETF meeting. We may continue the discussion about meta data. If we can solve it here in the list, we can update the architecture draft (maybe the reqs draft as well) and start the WGLC for them. BR, -Haibin _______________________________________________ decade mailing list decade@ietf.org https://www.ietf.org/mailman/listinfo/decade From richard.alimi@gmail.com Sun Sep 18 13:28:49 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 6248321F8801 for ; Sun, 18 Sep 2011 13:28:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.269 X-Spam-Level: X-Spam-Status: No, score=-1.269 tagged_above=-999 required=5 tests=[AWL=-1.681, BAYES_00=-2.599, CN_BODY_35=0.339, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_41=0.6, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ncU7YcRNb05o for ; Sun, 18 Sep 2011 13:28:48 -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 AFE7321F87F0 for ; Sun, 18 Sep 2011 13:28:48 -0700 (PDT) Received: by iaby26 with SMTP id y26so5764638iab.31 for ; Sun, 18 Sep 2011 13:31:09 -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 :content-transfer-encoding; bh=Buc+bNT820FW/NebJAqn1m2IYK7nfveBD88+tcn2ito=; b=tuJ+ddh8pq86iRq8Hj3uO1yA88iUn1Cn/EO3OURxK+c/QM7dVKivPFzdTWtRrTGDC9 nLSeCWXHmCSHmDWWsNVDn1317NjlKHCrZiJl1F3WMjOn9I19CaAjEiFsJGFQIVWyebhc mTw9cQV14kfNgeGq0VnTcvztlDLQHKTnuy2O0= Received: by 10.42.145.129 with SMTP id f1mr3186064icv.64.1316377869121; Sun, 18 Sep 2011 13:31:09 -0700 (PDT) MIME-Version: 1.0 Sender: richard.alimi@gmail.com Received: by 10.231.161.207 with HTTP; Sun, 18 Sep 2011 13:30:49 -0700 (PDT) In-Reply-To: <004601cc6ca2$2a9855b0$7fc90110$@com> References: <004601cc6ca2$2a9855b0$7fc90110$@com> From: Richard Alimi Date: Sun, 18 Sep 2011 13:30:49 -0700 X-Google-Sender-Auth: S2EUa72lf2MBUtmT4J-mUtZF_RA Message-ID: To: "Yingjie Gu(yingjie)" Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable Cc: decade@ietf.org Subject: Re: [decade] Remaining issue: meta data issue 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: Sun, 18 Sep 2011 20:28:49 -0000 2011/9/6 Yingjie Gu(yingjie) : > First of all, I think the ACL is a good use case for metadata. > But since the ACL could change with time, e.g. Client A can access now bu= t > is denied after a while, the metadata couldn't be immutable. > If I understand correctly, ACL and token are two ways to get to the same > purpose: access control. You can either use ACL by metadata or use Token > transferred by DRP, or even use them at the same time(I don't see the rea= son > for doing this for now). > If we want to support both, at least one of them should be mandatory. It was probably a poor choice for us to refer to "ACL" in the past for this as an abstract way to refer to the entities that may potentially access an object at any point of time. Understandably, the connotation of "ACL" was that there was an explicit set of users/groups configured at the server with permissions for a particular object. The latest revisions of the architecture and requirements should have be much more clear that an ACL is an alternative approach, but the token-based mechanism to be used in DECADE. I would agree that we should stick with token-based for now, but I would be hesitant to mention an explicit ACL as a potential future improvement because of how that might force us to complicate the protocol (it requires identifying users and administrative domains). How does that sound? Rich > > > > Best Regards > Gu Yingjie > > -----=D3=CA=BC=FE=D4=AD=BC=FE----- > =B7=A2=BC=FE=C8=CB: decade-bounces@ietf.org [mailto:decade-bounces@ietf.o= rg] =B4=FA=B1=ED > Rahman, Akbar > =B7=A2=CB=CD=CA=B1=BC=E4: 2011=C4=EA9=D4=C22=C8=D5 =C0=D6=C0=D622:58 > =CA=D5=BC=FE=C8=CB: Mcdysan, David E > =B3=AD=CB=CD: decade@ietf.org > =D6=F7=CC=E2: Re: [decade] Remaining issue: meta data issue > > Hi Dave, > > > My understanding is that the DECADE authentication token will be passed > separately from the metadata by the DECADE Resource Protocol (DRP). So > I am proposing that the ACL would be a separate item from the > authentication token, and that the ACL would be included as part of the > metadata (which would be sent on the SDT). My thinking is that a lot of > VoD type content today has some sort of ACL type data associated with it > today and that philosophy should carry forward in DECADE. > > I would be interested to hear any counter arguments though. > > > > Akbar > > -----Original Message----- > From: Mcdysan, David E [mailto:dave.mcdysan@verizon.com] > Sent: Friday, September 02, 2011 8:47 AM > To: Rahman, Akbar; Songhaibin > Cc: decade@ietf.org > Subject: Re: [decade] Remaining issue: meta data issue > > Hi Rahman, > > In your point 2 below is it actually an "Access Control List" or some > form > of authentication token? > > Thanks, > > Dave > > On Tuesday8/23/11 11:44 AM, "Rahman, Akbar" > wrote: > >>Hi Haibin, >> >> > >From the Quebec city minutes >> >>http://www.ietf.org/proceedings/81/minutes/decade.txt >> >> >>I understood that the following issues were open for DECADE metadata: >>1) Do we make metadata immutable? >>2) What is contained in the metadata? >> >> >>My feedback is as follows: >>1) Yes, make metadata immutable >>2) Define a minimum set of information for the metadata. So far, Time >>To Live (TTL) and Access Control List (ACL) were discussed and seem to >>be two items that are logical to include in the metadata >> >> >>I would be interested in hearing feedback from other members of the WG. >> >> >>Akbar >> >> >>-----Original Message----- >>From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.org] On > Behalf >>Of Songhaibin >>Sent: Monday, August 22, 2011 4:50 AM >>To: decade@ietf.org >>Subject: [decade] Remaining issue: meta data issue >> >>Dear all, >> >>I would suggest to have more discussion about the remaining issue from >>the past IETF meeting. We may continue the discussion about meta data. >>If we can solve it here in the list, we can update the architecture >>draft (maybe the reqs draft as well) and start the WGLC for them. >> >>BR, >>-Haibin >>_______________________________________________ >>decade mailing list >>decade@ietf.org >>https://www.ietf.org/mailman/listinfo/decade >>_______________________________________________ >>decade mailing list >>decade@ietf.org >>https://www.ietf.org/mailman/listinfo/decade > > _______________________________________________ > decade mailing list > decade@ietf.org > https://www.ietf.org/mailman/listinfo/decade > > _______________________________________________ > decade mailing list > decade@ietf.org > https://www.ietf.org/mailman/listinfo/decade > From richard.alimi@gmail.com Sun Sep 18 13:34:31 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 B71CC21F8880 for ; Sun, 18 Sep 2011 13:34:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.893 X-Spam-Level: X-Spam-Status: No, score=-2.893 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j2w8sM4Uucs1 for ; Sun, 18 Sep 2011 13:34:31 -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 04C3921F87F0 for ; Sun, 18 Sep 2011 13:34:30 -0700 (PDT) Received: by iaby26 with SMTP id y26so5769212iab.31 for ; Sun, 18 Sep 2011 13:36:52 -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 :content-transfer-encoding; bh=b9aLlJvSDWlc95D+9UrRWGu3/zsLeC4OtGJlth541HU=; b=cou4FrwXb+OMn0MFeoH4D1P3Z+GVAXab9AnQbGn++/BRQF45R7s1JfdsfcRXZs3Uz3 G2cXcriiPkxmclgC4U11U2NU4Ini3YRNgdBaVFeGzHmF8SEKvNMOs3ryYR7dl226lPFT HmXVkCEZC1acHq4WSC8N90qzgrkdqCrcZt39Q= Received: by 10.231.8.154 with SMTP id h26mr1342792ibh.6.1316378212096; Sun, 18 Sep 2011 13:36:52 -0700 (PDT) MIME-Version: 1.0 Sender: richard.alimi@gmail.com Received: by 10.231.161.207 with HTTP; Sun, 18 Sep 2011 13:36:32 -0700 (PDT) In-Reply-To: References: From: Richard Alimi Date: Sun, 18 Sep 2011 13:36:32 -0700 X-Google-Sender-Auth: gUiFl0Pi2svEDye0ekZY8k1jWJw Message-ID: To: Songhaibin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "decade@ietf.org" Subject: Re: [decade] Remaining issue: meta data issue 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: Sun, 18 Sep 2011 20:34:31 -0000 On Wed, Aug 24, 2011 at 7:48 PM, Songhaibin wrote: > Hi Akbar, > > IMO, even the metadata is immutable, the content publisher may still chan= ge it with new metadata, for example, refresh the TTL. In this case, if the= object itself is not changed, both the content publisher and content reque= ster do not need a new hash string for the object, and the content publishe= r does not need to redistribute the new object identity to the content requ= ester. Does that make sense? > I agree with the sentiment, but it might be clearer to word the document along these lines (in order to be more specific about what we mean and don't mean by the word "metadata"): (1) DECADE does not allow clients to attach user-defined metadata to an object. If clients wish to do this, they may use a mechanism such as storing their desired metadata inside the data object itself, or within a different data object. (2) There may be additional DECADE-layer or storage-layer attributes associated with a data object. The protocol may be defined such that additional attributes can be added in the future. These attributes have a scope that is local to a single DECADE server -- these attributes will not be transmitted when a data object is copied to another DECADE server or client. How does that sound? If it sounds good, then we can go ahead and update the document and post a new version. Thanks, Rich > BR, > -Haibin > >> -----Original Message----- >> From: Rahman, Akbar [mailto:Akbar.Rahman@InterDigital.com] >> Sent: Thursday, August 25, 2011 10:36 AM >> To: Songhaibin >> Cc: decade@ietf.org >> Subject: RE: [decade] Remaining issue: meta data issue >> >> Hi Haibin, >> >> I agree with your point to allow the metadata to be extensible in the fu= ture. On >> your suggestion for taking the hash, I have a question. If the metadata = is >> immutable, why would you not include it for the hash calculation? >> >> Akbar >> >> >> >> -----Original Message----- >> From: Songhaibin [haibin.song@huawei.com] >> Sent: Wednesday, August 24, 2011 09:52 PM Eastern Standard Time >> To: Rahman, Akbar >> Cc: decade@ietf.org >> Subject: RE: [decade] Remaining issue: meta data issue >> >> >> >> Hi Akbar, >> >> Speak as an individual, I agree with you on 1). For 2), we should make a >> minimum set of metadata at the beginning, but I think we should allow >> extensibility. >> >> I think that the hash should NOT be made over the metadata, but only ove= r the >> object itself. Because the metadata may change. >> >> BR, >> -Haibin >> >> > -----Original Message----- >> > From: Rahman, Akbar [mailto:Akbar.Rahman@InterDigital.com] >> > Sent: Tuesday, August 23, 2011 11:44 PM >> > To: Songhaibin >> > Cc: decade@ietf.org >> > Subject: RE: [decade] Remaining issue: meta data issue >> > >> > Hi Haibin, >> > >> > >> > From the Quebec city minutes >> > >> > http://www.ietf.org/proceedings/81/minutes/decade.txt >> > >> > >> > I understood that the following issues were open for DECADE metadata: >> > 1) Do we make metadata immutable? >> > 2) What is contained in the metadata? >> > >> > >> > My feedback is as follows: >> > 1) Yes, make metadata immutable >> > 2) Define a minimum set of information for the metadata. =A0So far, Ti= me >> > To Live (TTL) and Access Control List (ACL) were discussed and seem to >> > be two items that are logical to include in the metadata >> > >> > >> > I would be interested in hearing feedback from other members of the WG= . >> > >> > >> > Akbar >> > >> > >> > -----Original Message----- >> > From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.org] On Beha= lf >> > Of Songhaibin >> > Sent: Monday, August 22, 2011 4:50 AM >> > To: decade@ietf.org >> > Subject: [decade] Remaining issue: meta data issue >> > >> > Dear all, >> > >> > I would suggest to have more discussion about the remaining issue from >> > the past IETF meeting. We may continue the discussion about meta data. >> > If we can solve it here in the list, we can update the architecture >> > draft (maybe the reqs draft as well) and start the WGLC for them. >> > >> > BR, >> > -Haibin >> > _______________________________________________ >> > 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 Akbar.Rahman@InterDigital.com Sun Sep 18 19:08:49 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 3FFA721F8B72 for ; Sun, 18 Sep 2011 19:08:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.333 X-Spam-Level: X-Spam-Status: No, score=-2.333 tagged_above=-999 required=5 tests=[AWL=0.266, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n9XagPPkPPgD for ; Sun, 18 Sep 2011 19:08:48 -0700 (PDT) Received: from idcout.InterDigital.com (idcexmail.interdigital.com [12.32.197.135]) by ietfa.amsl.com (Postfix) with ESMTP id 319D921F8B6D for ; Sun, 18 Sep 2011 19:08:48 -0700 (PDT) Received: from SAM.InterDigital.com ([10.30.2.12]) by idcout.InterDigital.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 18 Sep 2011 22:11:05 -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: 18 Sep 2011 20:36:53.0775 (UTC) FILETIME=[B37721F0:01CC7642] X-Barracuda-Start-Time: 1316378212 X-Barracuda-Connect: mail-iy0-f182.google.com[209.85.210.182] X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.74911Rule breakdown below pts rule name description---- ---------------------- -------------------------------------------------- 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= X-ASG-Orig-Subj: Re: [decade] Remaining issue: meta data issue X-ASG-Debug-ID: 1316378212-01e5e556d97e440001-r1BGa4 X-Barracuda-URL: http://172.22.1.3:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at interdigital.com X-Barracuda-Envelope-From: richard.alimi@gmail.com 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 :content-transfer-encoding; bh=b9aLlJvSDWlc95D+9UrRWGu3/zsLeC4OtGJlth541HU=; b=cou4FrwXb+OMn0MFeoH4D1P3Z+GVAXab9AnQbGn++/BRQF45R7s1JfdsfcRXZs3Uz3 G2cXcriiPkxmclgC4U11U2NU4Ini3YRNgdBaVFeGzHmF8SEKvNMOs3ryYR7dl226lPFT HmXVkCEZC1acHq4WSC8N90qzgrkdqCrcZt39Q= X-Barracuda-Encrypted: RC4-SHA X-Google-Sender-Auth: gUiFl0Pi2svEDye0ekZY8k1jWJw X-Barracuda-Apparent-Source-IP: 209.85.210.182 Content-class: urn:content-classes:message Date: Sun, 18 Sep 2011 22:11:05 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-topic: [decade] Remaining issue: meta data issue Thread-index: Acx2QrO7Eg5jgektQ7eP9t6ochcECgALq+RO References: From: "Rahman, Akbar" To: , Cc: decade@ietf.org Subject: Re: [decade] Remaining issue: meta data issue 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, 19 Sep 2011 02:08:49 -0000 SGkgUmljaCwNCg0KSSB0aGluayB5b3VyIHN1Z2dlc3Rpb25zIGFyZSB2ZXJ5IHdlbGwgd29yZGVk Lg0KDQorMQ0KDQpBa2Jhcg0KDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206 IFJpY2hhcmQgQWxpbWkgW3JpY2hAdmVsdmV0c2VhLm5ldF0NClNlbnQ6IFN1bmRheSwgU2VwdGVt YmVyIDE4LCAyMDExIDA0OjM2IFBNIEVhc3Rlcm4gU3RhbmRhcmQgVGltZQ0KVG86IFNvbmdoYWli aW4NCkNjOiBSYWhtYW4sIEFrYmFyOyBkZWNhZGVAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbZGVj YWRlXSBSZW1haW5pbmcgaXNzdWU6IG1ldGEgZGF0YSBpc3N1ZQ0KDQoNCg0KT24gV2VkLCBBdWcg MjQsIDIwMTEgYXQgNzo0OCBQTSwgU29uZ2hhaWJpbiA8aGFpYmluLnNvbmdAaHVhd2VpLmNvbT4g d3JvdGU6DQo+IEhpIEFrYmFyLA0KPg0KPiBJTU8sIGV2ZW4gdGhlIG1ldGFkYXRhIGlzIGltbXV0 YWJsZSwgdGhlIGNvbnRlbnQgcHVibGlzaGVyIG1heSBzdGlsbCBjaGFuZ2UgaXQgd2l0aCBuZXcg bWV0YWRhdGEsIGZvciBleGFtcGxlLCByZWZyZXNoIHRoZSBUVEwuIEluIHRoaXMgY2FzZSwgaWYg dGhlIG9iamVjdCBpdHNlbGYgaXMgbm90IGNoYW5nZWQsIGJvdGggdGhlIGNvbnRlbnQgcHVibGlz aGVyIGFuZCBjb250ZW50IHJlcXVlc3RlciBkbyBub3QgbmVlZCBhIG5ldyBoYXNoIHN0cmluZyBm b3IgdGhlIG9iamVjdCwgYW5kIHRoZSBjb250ZW50IHB1Ymxpc2hlciBkb2VzIG5vdCBuZWVkIHRv IHJlZGlzdHJpYnV0ZSB0aGUgbmV3IG9iamVjdCBpZGVudGl0eSB0byB0aGUgY29udGVudCByZXF1 ZXN0ZXIuIERvZXMgdGhhdCBtYWtlIHNlbnNlPw0KPg0KDQpJIGFncmVlIHdpdGggdGhlIHNlbnRp bWVudCwgYnV0IGl0IG1pZ2h0IGJlIGNsZWFyZXIgdG8gd29yZCB0aGUNCmRvY3VtZW50IGFsb25n IHRoZXNlIGxpbmVzIChpbiBvcmRlciB0byBiZSBtb3JlIHNwZWNpZmljIGFib3V0IHdoYXQgd2UN Cm1lYW4gYW5kIGRvbid0IG1lYW4gYnkgdGhlIHdvcmQgIm1ldGFkYXRhIik6DQooMSkgREVDQURF IGRvZXMgbm90IGFsbG93IGNsaWVudHMgdG8gYXR0YWNoIHVzZXItZGVmaW5lZCBtZXRhZGF0YSB0 bw0KYW4gb2JqZWN0LiBJZiBjbGllbnRzIHdpc2ggdG8gZG8gdGhpcywgdGhleSBtYXkgdXNlIGEg bWVjaGFuaXNtIHN1Y2gNCmFzIHN0b3JpbmcgdGhlaXIgZGVzaXJlZCBtZXRhZGF0YSBpbnNpZGUg dGhlIGRhdGEgb2JqZWN0IGl0c2VsZiwgb3INCndpdGhpbiBhIGRpZmZlcmVudCBkYXRhIG9iamVj dC4NCigyKSBUaGVyZSBtYXkgYmUgYWRkaXRpb25hbCBERUNBREUtbGF5ZXIgb3Igc3RvcmFnZS1s YXllciBhdHRyaWJ1dGVzDQphc3NvY2lhdGVkIHdpdGggYSBkYXRhIG9iamVjdC4gIFRoZSBwcm90 b2NvbCBtYXkgYmUgZGVmaW5lZCBzdWNoIHRoYXQNCmFkZGl0aW9uYWwgYXR0cmlidXRlcyBjYW4g YmUgYWRkZWQgaW4gdGhlIGZ1dHVyZS4gIFRoZXNlIGF0dHJpYnV0ZXMNCmhhdmUgYSBzY29wZSB0 aGF0IGlzIGxvY2FsIHRvIGEgc2luZ2xlIERFQ0FERSBzZXJ2ZXIgLS0gdGhlc2UNCmF0dHJpYnV0 ZXMgd2lsbCBub3QgYmUgdHJhbnNtaXR0ZWQgd2hlbiBhIGRhdGEgb2JqZWN0IGlzIGNvcGllZCB0 bw0KYW5vdGhlciBERUNBREUgc2VydmVyIG9yIGNsaWVudC4NCg0KSG93IGRvZXMgdGhhdCBzb3Vu ZD8gIElmIGl0IHNvdW5kcyBnb29kLCB0aGVuIHdlIGNhbiBnbyBhaGVhZCBhbmQNCnVwZGF0ZSB0 aGUgZG9jdW1lbnQgYW5kIHBvc3QgYSBuZXcgdmVyc2lvbi4NCg0KVGhhbmtzLA0KUmljaA0KDQo+ IEJSLA0KPiAtSGFpYmluDQo+DQo+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4gRnJv bTogUmFobWFuLCBBa2JhciBbbWFpbHRvOkFrYmFyLlJhaG1hbkBJbnRlckRpZ2l0YWwuY29tXQ0K Pj4gU2VudDogVGh1cnNkYXksIEF1Z3VzdCAyNSwgMjAxMSAxMDozNiBBTQ0KPj4gVG86IFNvbmdo YWliaW4NCj4+IENjOiBkZWNhZGVAaWV0Zi5vcmcNCj4+IFN1YmplY3Q6IFJFOiBbZGVjYWRlXSBS ZW1haW5pbmcgaXNzdWU6IG1ldGEgZGF0YSBpc3N1ZQ0KPj4NCj4+IEhpIEhhaWJpbiwNCj4+DQo+ PiBJIGFncmVlIHdpdGggeW91ciBwb2ludCB0byBhbGxvdyB0aGUgbWV0YWRhdGEgdG8gYmUgZXh0 ZW5zaWJsZSBpbiB0aGUgZnV0dXJlLiBPbg0KPj4geW91ciBzdWdnZXN0aW9uIGZvciB0YWtpbmcg dGhlIGhhc2gsIEkgaGF2ZSBhIHF1ZXN0aW9uLiBJZiB0aGUgbWV0YWRhdGEgaXMNCj4+IGltbXV0 YWJsZSwgd2h5IHdvdWxkIHlvdSBub3QgaW5jbHVkZSBpdCBmb3IgdGhlIGhhc2ggY2FsY3VsYXRp b24/DQo+Pg0KPj4gQWtiYXINCj4+DQo+Pg0KPj4NCj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQo+PiBGcm9tOiBTb25naGFpYmluIFtoYWliaW4uc29uZ0BodWF3ZWkuY29tXQ0KPj4gU2Vu dDogV2VkbmVzZGF5LCBBdWd1c3QgMjQsIDIwMTEgMDk6NTIgUE0gRWFzdGVybiBTdGFuZGFyZCBU aW1lDQo+PiBUbzogUmFobWFuLCBBa2Jhcg0KPj4gQ2M6IGRlY2FkZUBpZXRmLm9yZw0KPj4gU3Vi amVjdDogUkU6IFtkZWNhZGVdIFJlbWFpbmluZyBpc3N1ZTogbWV0YSBkYXRhIGlzc3VlDQo+Pg0K Pj4NCj4+DQo+PiBIaSBBa2JhciwNCj4+DQo+PiBTcGVhayBhcyBhbiBpbmRpdmlkdWFsLCBJIGFn cmVlIHdpdGggeW91IG9uIDEpLiBGb3IgMiksIHdlIHNob3VsZCBtYWtlIGENCj4+IG1pbmltdW0g c2V0IG9mIG1ldGFkYXRhIGF0IHRoZSBiZWdpbm5pbmcsIGJ1dCBJIHRoaW5rIHdlIHNob3VsZCBh bGxvdw0KPj4gZXh0ZW5zaWJpbGl0eS4NCj4+DQo+PiBJIHRoaW5rIHRoYXQgdGhlIGhhc2ggc2hv dWxkIE5PVCBiZSBtYWRlIG92ZXIgdGhlIG1ldGFkYXRhLCBidXQgb25seSBvdmVyIHRoZQ0KPj4g b2JqZWN0IGl0c2VsZi4gQmVjYXVzZSB0aGUgbWV0YWRhdGEgbWF5IGNoYW5nZS4NCj4+DQo+PiBC UiwNCj4+IC1IYWliaW4NCj4+DQo+PiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+PiA+ IEZyb206IFJhaG1hbiwgQWtiYXIgW21haWx0bzpBa2Jhci5SYWhtYW5ASW50ZXJEaWdpdGFsLmNv bV0NCj4+ID4gU2VudDogVHVlc2RheSwgQXVndXN0IDIzLCAyMDExIDExOjQ0IFBNDQo+PiA+IFRv OiBTb25naGFpYmluDQo+PiA+IENjOiBkZWNhZGVAaWV0Zi5vcmcNCj4+ID4gU3ViamVjdDogUkU6 IFtkZWNhZGVdIFJlbWFpbmluZyBpc3N1ZTogbWV0YSBkYXRhIGlzc3VlDQo+PiA+DQo+PiA+IEhp IEhhaWJpbiwNCj4+ID4NCj4+ID4NCj4+ID4gRnJvbSB0aGUgUXVlYmVjIGNpdHkgbWludXRlcw0K Pj4gPg0KPj4gPiBodHRwOi8vd3d3LmlldGYub3JnL3Byb2NlZWRpbmdzLzgxL21pbnV0ZXMvZGVj YWRlLnR4dA0KPj4gPg0KPj4gPg0KPj4gPiBJIHVuZGVyc3Rvb2QgdGhhdCB0aGUgZm9sbG93aW5n IGlzc3VlcyB3ZXJlIG9wZW4gZm9yIERFQ0FERSBtZXRhZGF0YToNCj4+ID4gMSkgRG8gd2UgbWFr ZSBtZXRhZGF0YSBpbW11dGFibGU/DQo+PiA+IDIpIFdoYXQgaXMgY29udGFpbmVkIGluIHRoZSBt ZXRhZGF0YT8NCj4+ID4NCj4+ID4NCj4+ID4gTXkgZmVlZGJhY2sgaXMgYXMgZm9sbG93czoNCj4+ ID4gMSkgWWVzLCBtYWtlIG1ldGFkYXRhIGltbXV0YWJsZQ0KPj4gPiAyKSBEZWZpbmUgYSBtaW5p bXVtIHNldCBvZiBpbmZvcm1hdGlvbiBmb3IgdGhlIG1ldGFkYXRhLiAgU28gZmFyLCBUaW1lDQo+ PiA+IFRvIExpdmUgKFRUTCkgYW5kIEFjY2VzcyBDb250cm9sIExpc3QgKEFDTCkgd2VyZSBkaXNj dXNzZWQgYW5kIHNlZW0gdG8NCj4+ID4gYmUgdHdvIGl0ZW1zIHRoYXQgYXJlIGxvZ2ljYWwgdG8g aW5jbHVkZSBpbiB0aGUgbWV0YWRhdGENCj4+ID4NCj4+ID4NCj4+ID4gSSB3b3VsZCBiZSBpbnRl cmVzdGVkIGluIGhlYXJpbmcgZmVlZGJhY2sgZnJvbSBvdGhlciBtZW1iZXJzIG9mIHRoZSBXRy4N Cj4+ID4NCj4+ID4NCj4+ID4gQWtiYXINCj4+ID4NCj4+ID4NCj4+ID4gLS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS0NCj4+ID4gRnJvbTogZGVjYWRlLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpk ZWNhZGUtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmDQo+PiA+IE9mIFNvbmdoYWliaW4NCj4+ ID4gU2VudDogTW9uZGF5LCBBdWd1c3QgMjIsIDIwMTEgNDo1MCBBTQ0KPj4gPiBUbzogZGVjYWRl QGlldGYub3JnDQo+PiA+IFN1YmplY3Q6IFtkZWNhZGVdIFJlbWFpbmluZyBpc3N1ZTogbWV0YSBk YXRhIGlzc3VlDQo+PiA+DQo+PiA+IERlYXIgYWxsLA0KPj4gPg0KPj4gPiBJIHdvdWxkIHN1Z2dl c3QgdG8gaGF2ZSBtb3JlIGRpc2N1c3Npb24gYWJvdXQgdGhlIHJlbWFpbmluZyBpc3N1ZSBmcm9t DQo+PiA+IHRoZSBwYXN0IElFVEYgbWVldGluZy4gV2UgbWF5IGNvbnRpbnVlIHRoZSBkaXNjdXNz aW9uIGFib3V0IG1ldGEgZGF0YS4NCj4+ID4gSWYgd2UgY2FuIHNvbHZlIGl0IGhlcmUgaW4gdGhl IGxpc3QsIHdlIGNhbiB1cGRhdGUgdGhlIGFyY2hpdGVjdHVyZQ0KPj4gPiBkcmFmdCAobWF5YmUg dGhlIHJlcXMgZHJhZnQgYXMgd2VsbCkgYW5kIHN0YXJ0IHRoZSBXR0xDIGZvciB0aGVtLg0KPj4g Pg0KPj4gPiBCUiwNCj4+ID4gLUhhaWJpbg0KPj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KPj4gPiBkZWNhZGUgbWFpbGluZyBsaXN0DQo+PiA+IGRl Y2FkZUBpZXRmLm9yZw0KPj4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L2RlY2FkZQ0KPj4NCj4NCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCj4gZGVjYWRlIG1haWxpbmcgbGlzdA0KPiBkZWNhZGVAaWV0Zi5vcmcNCj4gaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kZWNhZGUNCj4NCg0KDQo= From haibin.song@huawei.com Mon Sep 19 18:58:33 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 6C0D821F84D4 for ; Mon, 19 Sep 2011 18:58:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=0.350, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Q8K+tg-TNQA for ; Mon, 19 Sep 2011 18:58:32 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 4466F21F8AEC for ; Mon, 19 Sep 2011 18:58:32 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LRS00G7MTL3IS@szxga04-in.huawei.com> for decade@ietf.org; Tue, 20 Sep 2011 10:00:39 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LRS00GEITL2EK@szxga04-in.huawei.com> for decade@ietf.org; Tue, 20 Sep 2011 10:00:39 +0800 (CST) Received: from szxeml201-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AEB08353; Tue, 20 Sep 2011 10:00:38 +0800 Received: from SZXEML402-HUB.china.huawei.com (10.82.67.32) by szxeml201-edg.china.huawei.com (172.24.2.39) with Microsoft SMTP Server (TLS) id 14.1.270.1; Tue, 20 Sep 2011 10:00:34 +0800 Received: from SZXEML524-MBS.china.huawei.com ([169.254.5.19]) by szxeml402-hub.china.huawei.com ([10.82.67.32]) with mapi id 14.01.0270.001; Tue, 20 Sep 2011 10:00:33 +0800 Date: Tue, 20 Sep 2011 02:00:34 +0000 From: Songhaibin In-reply-to: X-Originating-IP: [10.138.41.129] To: "Rahman, Akbar" , "rich@velvetsea.net" Message-id: MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-language: zh-CN Content-transfer-encoding: 7BIT Accept-Language: en-US, zh-CN Thread-topic: [decade] Remaining issue: meta data issue Thread-index: AcxgqId3hwBp3yEdQ32bcG9H5LPNwgBAVL8AADi3G4AAEOwOYATXe2yAAEKngVA= X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: Cc: "decade@ietf.org" Subject: Re: [decade] Remaining issue: meta data issue 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, 20 Sep 2011 01:58:33 -0000 The description also looks good to me. BR, -Haibin > -----Original Message----- > From: Rahman, Akbar [mailto:Akbar.Rahman@InterDigital.com] > Sent: Monday, September 19, 2011 10:11 AM > To: rich@velvetsea.net; Songhaibin > Cc: decade@ietf.org > Subject: RE: [decade] Remaining issue: meta data issue > > Hi Rich, > > I think your suggestions are very well worded. > > +1 > > Akbar > > > > -----Original Message----- > From: Richard Alimi [rich@velvetsea.net] > Sent: Sunday, September 18, 2011 04:36 PM Eastern Standard Time > To: Songhaibin > Cc: Rahman, Akbar; decade@ietf.org > Subject: Re: [decade] Remaining issue: meta data issue > > > > On Wed, Aug 24, 2011 at 7:48 PM, Songhaibin > wrote: > > Hi Akbar, > > > > IMO, even the metadata is immutable, the content publisher may still change > it with new metadata, for example, refresh the TTL. In this case, if the object > itself is not changed, both the content publisher and content requester do not > need a new hash string for the object, and the content publisher does not need > to redistribute the new object identity to the content requester. Does that > make sense? > > > > I agree with the sentiment, but it might be clearer to word the > document along these lines (in order to be more specific about what we > mean and don't mean by the word "metadata"): > (1) DECADE does not allow clients to attach user-defined metadata to > an object. If clients wish to do this, they may use a mechanism such > as storing their desired metadata inside the data object itself, or > within a different data object. > (2) There may be additional DECADE-layer or storage-layer attributes > associated with a data object. The protocol may be defined such that > additional attributes can be added in the future. These attributes > have a scope that is local to a single DECADE server -- these > attributes will not be transmitted when a data object is copied to > another DECADE server or client. > > How does that sound? If it sounds good, then we can go ahead and > update the document and post a new version. > > Thanks, > Rich > > > BR, > > -Haibin > > > >> -----Original Message----- > >> From: Rahman, Akbar [mailto:Akbar.Rahman@InterDigital.com] > >> Sent: Thursday, August 25, 2011 10:36 AM > >> To: Songhaibin > >> Cc: decade@ietf.org > >> Subject: RE: [decade] Remaining issue: meta data issue > >> > >> Hi Haibin, > >> > >> I agree with your point to allow the metadata to be extensible in the future. > On > >> your suggestion for taking the hash, I have a question. If the metadata is > >> immutable, why would you not include it for the hash calculation? > >> > >> Akbar > >> > >> > >> > >> -----Original Message----- > >> From: Songhaibin [haibin.song@huawei.com] > >> Sent: Wednesday, August 24, 2011 09:52 PM Eastern Standard Time > >> To: Rahman, Akbar > >> Cc: decade@ietf.org > >> Subject: RE: [decade] Remaining issue: meta data issue > >> > >> > >> > >> Hi Akbar, > >> > >> Speak as an individual, I agree with you on 1). For 2), we should make a > >> minimum set of metadata at the beginning, but I think we should allow > >> extensibility. > >> > >> I think that the hash should NOT be made over the metadata, but only over > the > >> object itself. Because the metadata may change. > >> > >> BR, > >> -Haibin > >> > >> > -----Original Message----- > >> > From: Rahman, Akbar [mailto:Akbar.Rahman@InterDigital.com] > >> > Sent: Tuesday, August 23, 2011 11:44 PM > >> > To: Songhaibin > >> > Cc: decade@ietf.org > >> > Subject: RE: [decade] Remaining issue: meta data issue > >> > > >> > Hi Haibin, > >> > > >> > > >> > From the Quebec city minutes > >> > > >> > http://www.ietf.org/proceedings/81/minutes/decade.txt > >> > > >> > > >> > I understood that the following issues were open for DECADE metadata: > >> > 1) Do we make metadata immutable? > >> > 2) What is contained in the metadata? > >> > > >> > > >> > My feedback is as follows: > >> > 1) Yes, make metadata immutable > >> > 2) Define a minimum set of information for the metadata. So far, Time > >> > To Live (TTL) and Access Control List (ACL) were discussed and seem to > >> > be two items that are logical to include in the metadata > >> > > >> > > >> > I would be interested in hearing feedback from other members of the WG. > >> > > >> > > >> > Akbar > >> > > >> > > >> > -----Original Message----- > >> > From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.org] On > Behalf > >> > Of Songhaibin > >> > Sent: Monday, August 22, 2011 4:50 AM > >> > To: decade@ietf.org > >> > Subject: [decade] Remaining issue: meta data issue > >> > > >> > Dear all, > >> > > >> > I would suggest to have more discussion about the remaining issue from > >> > the past IETF meeting. We may continue the discussion about meta data. > >> > If we can solve it here in the list, we can update the architecture > >> > draft (maybe the reqs draft as well) and start the WGLC for them. > >> > > >> > BR, > >> > -Haibin > >> > _______________________________________________ > >> > 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 wangdanhua@huawei.com Thu Sep 22 23:43:29 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 E103421F8ABD for ; Thu, 22 Sep 2011 23:43:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.598 X-Spam-Level: X-Spam-Status: No, score=-4.598 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aKPK3md2JbqU for ; Thu, 22 Sep 2011 23:43:29 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id 07F1921F8ABC for ; Thu, 22 Sep 2011 23:43:29 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LRY00H73QS74Y@szxga03-in.huawei.com> for decade@ietf.org; Fri, 23 Sep 2011 14:45:43 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LRY00JTJQS5MS@szxga03-in.huawei.com> for decade@ietf.org; Fri, 23 Sep 2011 14:45:43 +0800 (CST) Received: from szxeml207-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AEC85947; Fri, 23 Sep 2011 14:45:41 +0800 Received: from SZXEML407-HUB.china.huawei.com (10.82.67.94) by szxeml207-edg.china.huawei.com (172.24.2.59) with Microsoft SMTP Server (TLS) id 14.1.270.1; Fri, 23 Sep 2011 14:45:35 +0800 Received: from SZXEML507-MBS.china.huawei.com ([169.254.7.243]) by szxeml407-hub.china.huawei.com ([10.82.67.94]) with mapi id 14.01.0270.001; Fri, 23 Sep 2011 14:45:37 +0800 Date: Fri, 23 Sep 2011 06:45:35 +0000 From: wangdanhua X-Originating-IP: [10.138.41.132] To: "decade@ietf.org" Message-id: MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_AXwDAiOqowV17VIBsU5B8A)" Content-language: zh-CN Accept-Language: zh-CN, en-US Thread-topic: One more question about metadata :) Thread-index: Acx5vGWKfHq0uN3XSJKvT/peFTGHeQ== X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected Subject: [decade] One more question about metadata :) 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: Fri, 23 Sep 2011 06:43:30 -0000 --Boundary_(ID_AXwDAiOqowV17VIBsU5B8A) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi all, I have a question related to "metadata issue". Besides the items we discussed before (e.g., TTL and owner information), is it necessary to include two more items in the metadata: 1)an item to indicate whether the object is cacheable or not; 2)an item to indicate the DECADE Server Provider, distinguishing among different management domains that each DECADE Server belongs to. I'm appreciated for any feedback. Best wishes, Danhua --Boundary_(ID_AXwDAiOqowV17VIBsU5B8A) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Hi all,

 

I have a question related to “metadata issue”. Besides the items we discussed before (e.g., TTL and owner information), is it necessary to include two more items in the metadata:

1)an item to indicate whether the object is cacheable or not;

2)an item to indicate the DECADE Server Provider, distinguishing among different management domains that each DECADE Server belongs to.

I’m appreciated for any feedback.

 

Best wishes,

Danhua

 

--Boundary_(ID_AXwDAiOqowV17VIBsU5B8A)-- From haibin.song@huawei.com Fri Sep 23 00:24: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 4BDE921F8B29 for ; Fri, 23 Sep 2011 00:24:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.267 X-Spam-Level: X-Spam-Status: No, score=-6.267 tagged_above=-999 required=5 tests=[AWL=0.332, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dk1hTfJYzror for ; Fri, 23 Sep 2011 00:24:26 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 399C021F8B18 for ; Fri, 23 Sep 2011 00:24:26 -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 <0LRY007B0SJG3X@szxga05-in.huawei.com> for decade@ietf.org; Fri, 23 Sep 2011 15:23:40 +0800 (CST) Received: from szxrg01-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 <0LRY00GS2SJ20K@szxga05-in.huawei.com> for decade@ietf.org; Fri, 23 Sep 2011 15:23:40 +0800 (CST) Received: from szxeml207-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AEC88791; Fri, 23 Sep 2011 15:23:03 +0800 Received: from SZXEML404-HUB.china.huawei.com (10.82.67.59) by szxeml207-edg.china.huawei.com (172.24.2.59) with Microsoft SMTP Server (TLS) id 14.1.270.1; Fri, 23 Sep 2011 15:22:52 +0800 Received: from SZXEML524-MBS.china.huawei.com ([169.254.5.19]) by szxeml404-hub.china.huawei.com ([::1]) with mapi id 14.01.0270.001; Fri, 23 Sep 2011 15:22:58 +0800 Date: Fri, 23 Sep 2011 07:22:58 +0000 From: Songhaibin In-reply-to: X-Originating-IP: [10.138.41.129] To: "Rahman, Akbar" 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: [decade] Remaining issue: meta data issue Thread-index: AcxgqId3hwBp3yEdQ32bcG9H5LPNwgRdbVUgAei7aSA= X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: Cc: "decade@ietf.org" Subject: Re: [decade] Remaining issue: meta data issue 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: Fri, 23 Sep 2011 07:24:27 -0000 Hi Akbar, Yes. In the architecture level, I think we solved the issue. The details can be done in the next step protocol work IMO. BR, -Haibin > -----Original Message----- > From: Rahman, Akbar [mailto:Akbar.Rahman@InterDigital.com] > Sent: Tuesday, September 13, 2011 10:07 PM > To: Songhaibin > Cc: decade@ietf.org > Subject: RE: [decade] Remaining issue: meta data issue > > Hi Haibin, > > > We have had some discussion on this topic on the list. Do you consider > the issue resolved, and can we update the architecture draft to start > the WGLC? > > > Akbar > > -----Original Message----- > From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.org] On Behalf > Of Songhaibin > Sent: Monday, August 22, 2011 4:50 AM > To: decade@ietf.org > Subject: [decade] Remaining issue: meta data issue > > Dear all, > > I would suggest to have more discussion about the remaining issue from > the past IETF meeting. We may continue the discussion about meta data. > If we can solve it here in the list, we can update the architecture > draft (maybe the reqs draft as well) and start the WGLC for them. > > BR, > -Haibin > _______________________________________________ > decade mailing list > decade@ietf.org > https://www.ietf.org/mailman/listinfo/decade From haibin.song@huawei.com Fri Sep 23 00:39: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 CBF5921F8B5A for ; Fri, 23 Sep 2011 00:39:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.284 X-Spam-Level: X-Spam-Status: No, score=-6.284 tagged_above=-999 required=5 tests=[AWL=0.315, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9MAy6yammTuz for ; Fri, 23 Sep 2011 00:39:11 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 3734E21F8B58 for ; Fri, 23 Sep 2011 00:39:11 -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 <0LRY007ONTBB3I@szxga05-in.huawei.com> for decade@ietf.org; Fri, 23 Sep 2011 15:40:23 +0800 (CST) Received: from szxrg01-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 <0LRY00B3ATA6IT@szxga05-in.huawei.com> for decade@ietf.org; Fri, 23 Sep 2011 15:40:23 +0800 (CST) Received: from szxeml207-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AEC90153; Fri, 23 Sep 2011 15:40:22 +0800 Received: from SZXEML407-HUB.china.huawei.com (10.82.67.94) by szxeml207-edg.china.huawei.com (172.24.2.59) with Microsoft SMTP Server (TLS) id 14.1.270.1; Fri, 23 Sep 2011 15:40:16 +0800 Received: from SZXEML524-MBS.china.huawei.com ([169.254.5.19]) by szxeml407-hub.china.huawei.com ([10.82.67.94]) with mapi id 14.01.0270.001; Fri, 23 Sep 2011 15:40:20 +0800 Date: Fri, 23 Sep 2011 07:40:20 +0000 From: Songhaibin X-Originating-IP: [10.138.41.129] 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: CDMI Thread-index: Acx5xAr74MsDa0HzSc2FXCEqj+EZmA== X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected Subject: [decade] CDMI 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: Fri, 23 Sep 2011 07:39:11 -0000 Dear folks, When I was reading CDMI protocol, it seems that the objects should be created within a "container". Then I had a question in mind. If we do not have the "container" concept in DECADE, the CDMI protocol needs change if we want to use it for DECADE. If there are many places need changes, I am not sure whether it is a good sign. BR, -Haibin (as individual) From richard.alimi@gmail.com Fri Sep 23 01:35:47 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 E392921F8BC5 for ; Fri, 23 Sep 2011 01:35:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.908 X-Spam-Level: X-Spam-Status: No, score=-2.908 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TeHwwB56nUQn for ; Fri, 23 Sep 2011 01:35:47 -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 6258021F8BB0 for ; Fri, 23 Sep 2011 01:35:47 -0700 (PDT) Received: by iaby26 with SMTP id y26so4647127iab.31 for ; Fri, 23 Sep 2011 01:38:21 -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 :content-transfer-encoding; bh=N9HKAd8RSdJeiye69nFA8SZXrff7TlGg+gKSmqynSGQ=; b=fIehueT1oLmMTrxVt0RnhGdsUMAiRpm8E61Y9AkOkqFpHstGwbNsov2VcUCf4NixsY z2zTc+RNnVo/umGe4Pq6ilNSq/GuYsLa5MARN4uUXKAHk37F3aaEuqC9U2aEYQ4NTLp4 mwzuti5D5GuAzaY8jwXKaIpKJuoytbD+n+p1o= Received: by 10.42.75.194 with SMTP id b2mr3817735ick.62.1316767101086; Fri, 23 Sep 2011 01:38:21 -0700 (PDT) MIME-Version: 1.0 Sender: richard.alimi@gmail.com Received: by 10.231.148.203 with HTTP; Fri, 23 Sep 2011 01:38:01 -0700 (PDT) In-Reply-To: References: From: Richard Alimi Date: Fri, 23 Sep 2011 01:38:01 -0700 X-Google-Sender-Auth: -Vtno_bjYx_RZwovHjz_1tuhpPE Message-ID: To: wangdanhua Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: "decade@ietf.org" Subject: Re: [decade] One more question about metadata :) 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: Fri, 23 Sep 2011 08:35:48 -0000 On Thu, Sep 22, 2011 at 11:45 PM, wangdanhua wrote: > Hi all, > > > > I have a question related to =93metadata issue=94. Besides the items we > discussed before (e.g., TTL and owner information), is it necessary to > include two more items in the metadata: > > 1)an item to indicate whether the object is cacheable or not; > Cacheable by whom? The Client who ends up downloading the data, or a DECADE server? > 2)an item to indicate the DECADE Server Provider, distinguishing among > different management domains that each DECADE Server belongs to. > I might imagine a server having some sort of identifier that optionally lets it identify whether its part of some administrative domain, but its not clear to me what the use cases would be. Regardless, is there a reason that such an identifier should be a property of a data object? Thanks, Rich > I=92m appreciated for any feedback. > > > > Best wishes, > > Danhua > > > > _______________________________________________ > decade mailing list > decade@ietf.org > https://www.ietf.org/mailman/listinfo/decade > > From richard.alimi@gmail.com Fri Sep 23 01:36:56 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 05A6D21F85CE for ; Fri, 23 Sep 2011 01:36:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.91 X-Spam-Level: X-Spam-Status: No, score=-2.91 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZkAsTjUmyCJf for ; Fri, 23 Sep 2011 01:36:55 -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 7D77121F854D for ; Fri, 23 Sep 2011 01:36:55 -0700 (PDT) Received: by iaby26 with SMTP id y26so4648452iab.31 for ; Fri, 23 Sep 2011 01:39:29 -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 :content-transfer-encoding; bh=N26sg1VtpxXz8l58bkPzq8qR86/kh+kGfJJ5VKd8Dow=; b=Fm4n02wGzJZMnrHtPRmI+9LYQiSC4wkjYpLAaFjpSgSYtM/8BDj0RV/FEbnM/eLgzA KZL6o4GP4o5CrF48J0EKCv/8ohIwlF3PL7WV8HTZsTqfvXhvNyVBDgB2KnjczHbldeI0 4ZAzY82wtb5NXmzfBwDiMAwPHZ6GS5MVLA+ms= Received: by 10.231.81.70 with SMTP id w6mr5278604ibk.51.1316767168197; Fri, 23 Sep 2011 01:39:28 -0700 (PDT) MIME-Version: 1.0 Sender: richard.alimi@gmail.com Received: by 10.231.148.203 with HTTP; Fri, 23 Sep 2011 01:39:08 -0700 (PDT) In-Reply-To: References: From: Richard Alimi Date: Fri, 23 Sep 2011 01:39:08 -0700 X-Google-Sender-Auth: 75cyZJL8qZGttaubdZ2lfm_I9ng Message-ID: To: Songhaibin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "decade@ietf.org" Subject: Re: [decade] CDMI 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: Fri, 23 Sep 2011 08:36:56 -0000 On Fri, Sep 23, 2011 at 12:40 AM, Songhaibin wrote= : > Dear folks, > > When I was reading CDMI protocol, it seems that the objects should be cre= ated within a "container". Then I had a question in mind. If we do not have= the "container" concept in DECADE, the CDMI protocol needs change if we wa= nt to use it for DECADE. If there are many places need changes, I am not su= re whether it is a good sign. > Could we put all objects in a container named "decade"? > BR, > -Haibin (as individual) > _______________________________________________ > decade mailing list > decade@ietf.org > https://www.ietf.org/mailman/listinfo/decade > From haibin.song@huawei.com Fri Sep 23 02:19: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 BE70921F8BA7 for ; Fri, 23 Sep 2011 02:19:17 -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=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o7Hc2LflJiql for ; Fri, 23 Sep 2011 02:19:17 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id 247F821F8B95 for ; Fri, 23 Sep 2011 02:19:17 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LRY00H8WY0B9R@szxga03-in.huawei.com> for decade@ietf.org; Fri, 23 Sep 2011 17:21:48 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LRY00FFTY0AKT@szxga03-in.huawei.com> for decade@ietf.org; Fri, 23 Sep 2011 17:21:47 +0800 (CST) Received: from szxeml205-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id ADV85667; Fri, 23 Sep 2011 17:21:30 +0800 Received: from SZXEML401-HUB.china.huawei.com (10.82.67.31) by szxeml205-edg.china.huawei.com (172.24.2.57) with Microsoft SMTP Server (TLS) id 14.1.270.1; Fri, 23 Sep 2011 17:21:23 +0800 Received: from SZXEML524-MBS.china.huawei.com ([169.254.5.19]) by szxeml401-hub.china.huawei.com ([10.82.67.31]) with mapi id 14.01.0270.001; Fri, 23 Sep 2011 17:21:27 +0800 Date: Fri, 23 Sep 2011 09:21:28 +0000 From: Songhaibin In-reply-to: X-Originating-IP: [10.138.41.129] To: Richard Alimi 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: [decade] CDMI Thread-index: Acx5xAr74MsDa0HzSc2FXCEqj+EZmP//ilIA//92UtA= X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: Cc: "decade@ietf.org" Subject: Re: [decade] CDMI 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: Fri, 23 Sep 2011 09:19:17 -0000 Hi Rich, Thanks for the interesting answer. Then I still have doubts. Who creates this container? Who has the right to operate on this container? Maybe the DECADE service provider? BR, -Haibin(as individual) > -----Original Message----- > From: richard.alimi@gmail.com [mailto:richard.alimi@gmail.com] On Behalf Of > Richard Alimi > Sent: Friday, September 23, 2011 4:39 PM > To: Songhaibin > Cc: decade@ietf.org > Subject: Re: [decade] CDMI > > On Fri, Sep 23, 2011 at 12:40 AM, Songhaibin > wrote: > > Dear folks, > > > > When I was reading CDMI protocol, it seems that the objects should be > created within a "container". Then I had a question in mind. If we do not have > the "container" concept in DECADE, the CDMI protocol needs change if we > want to use it for DECADE. If there are many places need changes, I am not > sure whether it is a good sign. > > > > Could we put all objects in a container named "decade"? > > > BR, > > -Haibin (as individual) > > _______________________________________________ > > decade mailing list > > decade@ietf.org > > https://www.ietf.org/mailman/listinfo/decade > > From richard_woundy@cable.comcast.com Fri Sep 23 03:17:06 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 42FAB21F85F7 for ; Fri, 23 Sep 2011 03:17:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.393 X-Spam-Level: X-Spam-Status: No, score=-102.393 tagged_above=-999 required=5 tests=[AWL=-0.658, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CmV4xq31h2yc for ; Fri, 23 Sep 2011 03:17:05 -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 E98F621F84BD for ; Fri, 23 Sep 2011 03:16:59 -0700 (PDT) Received: from ([24.40.55.40]) by copdcimo01.cable.comcast.com with ESMTP id 5503630.54172096; Fri, 23 Sep 2011 04:26:03 -0600 Received: from PACDCEXMB05.cable.comcast.com ([fe80::a5b0:e5c4:df1b:2367]) by pacdcexhub03.cable.comcast.com ([fe80::d1dd:b302:b617:3755%11]) with mapi id 14.01.0289.001; Fri, 23 Sep 2011 06:19:25 -0400 From: "Woundy, Richard" To: "'haibin.song@huawei.com'" , "'rich@velvetsea.net'" Thread-Topic: [decade] CDMI Thread-Index: Acx5xAr74MsDa0HzSc2FXCEqj+EZmAAKb5oAAAF6fQAABlu07A== Date: Fri, 23 Sep 2011 10:19:24 +0000 Message-ID: <1CA25301D2219F40B3AA37201F0EACD113690980@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.241] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "'decade@ietf.org'" Subject: Re: [decade] CDMI 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: Fri, 23 Sep 2011 10:17:06 -0000 Or does the container correspond to the user? Do CDMI access controls deriv= e from a container? -- Rich (as individual) ----- Original Message ----- From: Songhaibin [mailto:haibin.song@huawei.com] Sent: Friday, September 23, 2011 05:21 AM=0A= To: Richard Alimi Cc: decade@ietf.org Subject: Re: [decade] CDMI Hi Rich, Thanks for the interesting answer. Then I still have doubts. Who creates th= is container? Who has the right to operate on this container? Maybe the DEC= ADE service provider? BR, -Haibin(as individual) > -----Original Message----- > From: richard.alimi@gmail.com [mailto:richard.alimi@gmail.com] On Behalf = Of > Richard Alimi > Sent: Friday, September 23, 2011 4:39 PM > To: Songhaibin > Cc: decade@ietf.org > Subject: Re: [decade] CDMI >=20 > On Fri, Sep 23, 2011 at 12:40 AM, Songhaibin > wrote: > > Dear folks, > > > > When I was reading CDMI protocol, it seems that the objects should be > created within a "container". Then I had a question in mind. If we do not= have > the "container" concept in DECADE, the CDMI protocol needs change if we > want to use it for DECADE. If there are many places need changes, I am no= t > sure whether it is a good sign. > > >=20 > Could we put all objects in a container named "decade"? >=20 > > BR, > > -Haibin (as individual) > > _______________________________________________ > > 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 Akbar.Rahman@InterDigital.com Fri Sep 23 07:12: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 C030321F8B5A for ; Fri, 23 Sep 2011 07:12:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.356 X-Spam-Level: X-Spam-Status: No, score=-2.356 tagged_above=-999 required=5 tests=[AWL=0.243, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CsKtt-8GBjXj for ; Fri, 23 Sep 2011 07:12:58 -0700 (PDT) Received: from idcout.InterDigital.com (idcexmail.interdigital.com [12.32.197.135]) by ietfa.amsl.com (Postfix) with ESMTP id C4C5021F8C53 for ; Fri, 23 Sep 2011 07:12:57 -0700 (PDT) Received: from SAM.InterDigital.com ([10.30.2.12]) by idcout.InterDigital.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 23 Sep 2011 10:15:31 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 23 Sep 2011 10:15:28 -0400 Message-ID: In-Reply-To: <1CA25301D2219F40B3AA37201F0EACD113690980@PACDCEXMB05.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-topic: [decade] CDMI Thread-index: Acx5xAr74MsDa0HzSc2FXCEqj+EZmAAKb5oAAAF6fQAABlu07AAFvZBA References: <1CA25301D2219F40B3AA37201F0EACD113690980@PACDCEXMB05.cable.comcast.com> From: "Rahman, Akbar" To: "Woundy, Richard" , , X-OriginalArrivalTime: 23 Sep 2011 14:15:31.0483 (UTC) FILETIME=[409F36B0:01CC79FB] Cc: decade@ietf.org Subject: Re: [decade] CDMI 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: Fri, 23 Sep 2011 14:12:59 -0000 Hi Rich/Haibin/Rich, My understanding is as follows from reading the CDMI SNIA spec http://snia.org/sites/default/files/CDMI_SNIA_Architecture_v1.0.pdf 1)A container is a grouping of individual data objects. All data objects must be placed inside at least one level of container. (See data model in Fig. 6 on pg 13) 2) A user can create either an individual data object or a container containing multiple data objects (see sec. 5.5 on pg. 11, and 1st paragraph of pg. 14). Similarly a user can read either the whole container, or an individual object in the container (see sec. 5.5 on pg. 15). Finally, the access control for the user can be applied to both the individual data object level or the container level through the metadata concept. 3) The HTTP PUT command used to create a new container is shown in (sec 6.2 on pg. 19). The HTTP PUT command used to create a data object in a container is shown in (sec. 6.3 on pg. 19). Finally, the WEBDAV protocol also supports a concept called "collections" (of resources) which is similar to the CDMI "container" object (see http://tools.ietf.org/html/rfc4918#section-5). So I think this points to the fact that we should support some concept in DECADE similar to a container. Any feedback would be appreciated. Akbar -----Original Message----- From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.org] On Behalf Of Woundy, Richard Sent: Friday, September 23, 2011 6:19 AM To: 'haibin.song@huawei.com'; 'rich@velvetsea.net' Cc: 'decade@ietf.org' Subject: Re: [decade] CDMI Or does the container correspond to the user? Do CDMI access controls derive from a container? -- Rich (as individual) ----- Original Message ----- From: Songhaibin [mailto:haibin.song@huawei.com] Sent: Friday, September 23, 2011 05:21 AM To: Richard Alimi Cc: decade@ietf.org Subject: Re: [decade] CDMI Hi Rich, Thanks for the interesting answer. Then I still have doubts. Who creates this container? Who has the right to operate on this container? Maybe the DECADE service provider? BR, -Haibin(as individual) > -----Original Message----- > From: richard.alimi@gmail.com [mailto:richard.alimi@gmail.com] On Behalf Of > Richard Alimi > Sent: Friday, September 23, 2011 4:39 PM > To: Songhaibin > Cc: decade@ietf.org > Subject: Re: [decade] CDMI >=20 > On Fri, Sep 23, 2011 at 12:40 AM, Songhaibin > wrote: > > Dear folks, > > > > When I was reading CDMI protocol, it seems that the objects should be > created within a "container". Then I had a question in mind. If we do not have > the "container" concept in DECADE, the CDMI protocol needs change if we > want to use it for DECADE. If there are many places need changes, I am not > sure whether it is a good sign. > > >=20 > Could we put all objects in a container named "decade"? >=20 > > BR, > > -Haibin (as individual) > > _______________________________________________ > > decade mailing list > > decade@ietf.org > > https://www.ietf.org/mailman/listinfo/decade > > _______________________________________________ decade mailing list decade@ietf.org https://www.ietf.org/mailman/listinfo/decade _______________________________________________ decade mailing list decade@ietf.org https://www.ietf.org/mailman/listinfo/decade From wangdanhua@huawei.com Fri Sep 23 20:36:05 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 CF26521F8C99 for ; Fri, 23 Sep 2011 20:36:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.075 X-Spam-Level: X-Spam-Status: No, score=-1.075 tagged_above=-999 required=5 tests=[AWL=-3.523, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CljKPnrpS4bK for ; Fri, 23 Sep 2011 20:36:05 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 395B621F8C98 for ; Fri, 23 Sep 2011 20:36:05 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LS000H3SCSG3Q@szxga04-in.huawei.com> for decade@ietf.org; Sat, 24 Sep 2011 11:38:40 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LS0003BSCS6ZT@szxga04-in.huawei.com> for decade@ietf.org; Sat, 24 Sep 2011 11:38:40 +0800 (CST) Received: from szxeml206-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id ADW05822; Sat, 24 Sep 2011 11:38:39 +0800 Received: from SZXEML404-HUB.china.huawei.com (10.82.67.59) by szxeml206-edg.china.huawei.com (172.24.2.58) with Microsoft SMTP Server (TLS) id 14.1.270.1; Sat, 24 Sep 2011 11:38:30 +0800 Received: from SZXEML507-MBS.china.huawei.com ([169.254.7.243]) by szxeml404-hub.china.huawei.com ([::1]) with mapi id 14.01.0270.001; Sat, 24 Sep 2011 11:38:35 +0800 Date: Sat, 24 Sep 2011 03:38:34 +0000 From: wangdanhua In-reply-to: X-Originating-IP: [10.138.41.132] To: Richard Alimi Message-id: MIME-version: 1.0 Content-type: text/plain; charset=gb2312 Content-language: zh-CN Content-transfer-encoding: base64 Accept-Language: zh-CN, en-US Thread-topic: [decade] One more question about metadata :) Thread-index: Acx5vGWKfHq0uN3XSJKvT/peFTGHef//mU2A//49ODA= X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: Cc: "decade@ietf.org" Subject: [decade] =?gb2312?b?tPC4tDogIE9uZSBtb3JlIHF1ZXN0aW9uIGFib3V0IG1l?= =?gb2312?b?dGFkYXRhIDop?= 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, 24 Sep 2011 03:36:05 -0000 SGkgUmljaCwNCg0KPk9uIFRodSwgU2VwIDIyLCAyMDExIGF0IDExOjQ1IFBNLCB3YW5nZGFuaHVh IDx3YW5nZGFuaHVhQGh1YXdlaS5jb20+IHdyb3RlOg0KPiBIaSBhbGwsDQo+DQo+DQo+DQo+IEkg aGF2ZSBhIHF1ZXN0aW9uIHJlbGF0ZWQgdG8gobBtZXRhZGF0YSBpc3N1ZaGxLiBCZXNpZGVzIHRo ZSBpdGVtcyB3ZQ0KPiBkaXNjdXNzZWQgYmVmb3JlIChlLmcuLCBUVEwgYW5kIG93bmVyIGluZm9y bWF0aW9uKSwgaXMgaXQgbmVjZXNzYXJ5IHRvDQo+IGluY2x1ZGUgdHdvIG1vcmUgaXRlbXMgaW4g dGhlIG1ldGFkYXRhOg0KPg0KPiAxKWFuIGl0ZW0gdG8gaW5kaWNhdGUgd2hldGhlciB0aGUgb2Jq ZWN0IGlzIGNhY2hlYWJsZSBvciBub3Q7DQo+DQoNCj5DYWNoZWFibGUgYnkgd2hvbT8gIFRoZSBD bGllbnQgd2hvIGVuZHMgdXAgZG93bmxvYWRpbmcgdGhlIGRhdGEsIG9yIGENCj5ERUNBREUgc2Vy dmVyPw0KDQoNCkUuZy4sIHdoZXRoZXIgYmUgY2FjaGVhYmxlIGJ5IG1pZGRsZWJveGVzLCBzdWNo IGFzIHByb3h5Lg0KDQoNCj4gMilhbiBpdGVtIHRvIGluZGljYXRlIHRoZSBERUNBREUgU2VydmVy IFByb3ZpZGVyLCBkaXN0aW5ndWlzaGluZyBhbW9uZw0KPiBkaWZmZXJlbnQgbWFuYWdlbWVudCBk b21haW5zIHRoYXQgZWFjaCBERUNBREUgU2VydmVyIGJlbG9uZ3MgdG8uDQoNCg0KPkkgbWlnaHQg aW1hZ2luZSBhIHNlcnZlciBoYXZpbmcgc29tZSBzb3J0IG9mIGlkZW50aWZpZXIgdGhhdA0KPm9w dGlvbmFsbHkgbGV0cyBpdCBpZGVudGlmeSB3aGV0aGVyIGl0cyBwYXJ0IG9mIHNvbWUgYWRtaW5p c3RyYXRpdmUNCj5kb21haW4sIGJ1dCBpdHMgbm90IGNsZWFyIHRvIG1lIHdoYXQgdGhlIHVzZSBj YXNlcyB3b3VsZCBiZS4NCj5SZWdhcmRsZXNzLCBpcyB0aGVyZSBhIHJlYXNvbiB0aGF0IHN1Y2gg YW4gaWRlbnRpZmllciBzaG91bGQgYmUgYQ0KPnByb3BlcnR5IG9mIGEgZGF0YSBvYmplY3Q/DQoN Cg0KSSBkbyBhZ3JlZSBpdCdzIHRoZSBwcm9wZXJ0eSBvZiB0aGUgc2VydmVyLCBub3Qgb2YgdGhl IGRhdGEgb2JqZWN0LiBJdCB3b3VsZCBiZSBpbnRlcmVzdGluZyB0byBsb29rIGZvciBzb21lIHVz ZSBjYXNlcyB0byBleHBsb3JlIHRoZSB3YXkgdG8gbWFrZSB1c2Ugb2YgdGhpcyBpbmZvcm1hdGlv bi4gSSdsbCBsZXQgeW91IGtub3cgd2hlbiBJIGNvbWUgdXAgd2l0aCBtb3JlIGNvbmNyZXRlIGNv bnNpZGVyYXRpb25zIG9yIGNvbnZpY3RpdmUgc2NlbmFyaW9zLg0KDQoNClRoYW5rIHlvdSBmb3Ig eW91ciBjb21tZW50cy4NCg0KQmVzdCB3aXNoZXMsDQpEYW5odWENCg== From guyingjie@huawei.com Sat Sep 24 01:43:21 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 C3C1821F8B79 for ; Sat, 24 Sep 2011 01:43:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.677 X-Spam-Level: X-Spam-Status: No, score=-100.677 tagged_above=-999 required=5 tests=[AWL=-1.712, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IAa5+R+y9IVP for ; Sat, 24 Sep 2011 01:43:21 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id DF03021F8B16 for ; Sat, 24 Sep 2011 01:43:20 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LS0007XIR0KUS@szxga04-in.huawei.com> for decade@ietf.org; Sat, 24 Sep 2011 16:45:57 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LS000MS9R0BH5@szxga04-in.huawei.com> for decade@ietf.org; Sat, 24 Sep 2011 16:45:56 +0800 (CST) Received: from szxeml201-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AED29737; Sat, 24 Sep 2011 16:45:56 +0800 Received: from SZXEML412-HUB.china.huawei.com (10.82.67.91) by szxeml201-edg.china.huawei.com (172.24.2.39) with Microsoft SMTP Server (TLS) id 14.1.270.1; Sat, 24 Sep 2011 16:45:44 +0800 Received: from g00107907 (10.138.41.134) by szxeml412-hub.china.huawei.com (10.82.67.91) with Microsoft SMTP Server (TLS) id 14.1.270.1; Sat, 24 Sep 2011 16:45:48 +0800 Date: Sat, 24 Sep 2011 16:47:34 +0800 From: "Yingjie Gu(yingjie)" In-reply-to: X-Originating-IP: [10.138.41.134] To: 'wangdanhua' , 'Richard Alimi' Message-id: <001401cc7a96$9ac4e5e0$d04eb1a0$@com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=gb2312 Content-language: zh-cn Content-transfer-encoding: quoted-printable Thread-index: Acx5vGWKfHq0uN3XSJKvT/peFTGHef//mU2A//49ODD//CU9cA== X-CFilter-Loop: Reflected References: Cc: decade@ietf.org Subject: [decade] =?gb2312?b?tPC4tDogILTwuLQ6ICBPbmUgbW9yZSBxdWVzdGlvbiBh?= =?gb2312?b?Ym91dCBtZXRhZGF0YSA6KQ==?= 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, 24 Sep 2011 08:43:21 -0000 Hi Danhua, As for Cachable: Proxy is not aware of either the content or the = metadata I think. I am not sure about this, but I think proxy only be aware of protocols, e.g. transport protocol and application protocols. Only DPI/IDS/IPS be aware of content, but they doesn't cache content. And = what's the meaning of caching content on proxy if we decide to define content token(authentication). It violates authentication mechanism. =20 If you mean client who ends up downloading the data, I think this is = sort of reasonable. But I doubt how can we monitor whether a client has cached a "not-allowed-to-cache" content.=20 If you mean Decade server, I think it doesn't make sense, because Decade server store the content already. Best Regards Gu Yingjie -----=D3=CA=BC=FE=D4=AD=BC=FE----- =B7=A2=BC=FE=C8=CB: decade-bounces@ietf.org = [mailto:decade-bounces@ietf.org] =B4=FA=B1=ED wangdanhua =B7=A2=CB=CD=CA=B1=BC=E4: 2011=C4=EA9=D4=C224=C8=D5 =C0=D6=C0=D611:39 =CA=D5=BC=FE=C8=CB: Richard Alimi =B3=AD=CB=CD: decade@ietf.org =D6=F7=CC=E2: [decade] =B4=F0=B8=B4: One more question about metadata :) Hi Rich, >On Thu, Sep 22, 2011 at 11:45 PM, wangdanhua = wrote: > Hi all, > > > > I have a question related to =A1=B0metadata issue=A1=B1. Besides the = items we > discussed before (e.g., TTL and owner information), is it necessary to > include two more items in the metadata: > > 1)an item to indicate whether the object is cacheable or not; > >Cacheable by whom? The Client who ends up downloading the data, or a >DECADE server? E.g., whether be cacheable by middleboxes, such as proxy. > 2)an item to indicate the DECADE Server Provider, distinguishing among > different management domains that each DECADE Server belongs to. >I might imagine a server having some sort of identifier that >optionally lets it identify whether its part of some administrative >domain, but its not clear to me what the use cases would be. >Regardless, is there a reason that such an identifier should be a >property of a data object? I do agree it's the property of the server, not of the data object. It = would be interesting to look for some use cases to explore the way to make use = of this information. I'll let you know when I come up with more concrete considerations or convictive scenarios. Thank you for your comments. Best wishes, Danhua _______________________________________________ decade mailing list decade@ietf.org https://www.ietf.org/mailman/listinfo/decade From richard.alimi@gmail.com Sun Sep 25 21:36: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 E2CA621F84B5 for ; Sun, 25 Sep 2011 21:36:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.86 X-Spam-Level: X-Spam-Status: No, score=-2.86 tagged_above=-999 required=5 tests=[AWL=0.117, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zGVkH9RuVY2I for ; Sun, 25 Sep 2011 21:36:51 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id AA30821F84B4 for ; Sun, 25 Sep 2011 21:36:51 -0700 (PDT) Received: by gxk19 with SMTP id 19so5016692gxk.31 for ; Sun, 25 Sep 2011 21:39:33 -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=w4ysR6PhyRDWLTZNY6/dtyIcplLEhVGuI3ls3pbGN1Y=; b=A1HL1lWQ8xO8F9JQX6nOMmBjlx22wyARjp9QlWs7RTzuejqugvNiImU/vGjjat6K6O rc46nlHlBm5m4zph7zXAzhN9d0HDUxFJTIj7s5oMAlNvNHpItW020/7jHHmMxt1XOq2x qcu9zF/OmDOkZQot6hi5rEh8+cNLmiiYDyHF0= Received: by 10.231.28.36 with SMTP id k36mr7977388ibc.12.1317011973131; Sun, 25 Sep 2011 21:39:33 -0700 (PDT) MIME-Version: 1.0 Sender: richard.alimi@gmail.com Received: by 10.231.148.203 with HTTP; Sun, 25 Sep 2011 21:39:13 -0700 (PDT) In-Reply-To: <1CA25301D2219F40B3AA37201F0EACD113690980@PACDCEXMB05.cable.comcast.com> References: <1CA25301D2219F40B3AA37201F0EACD113690980@PACDCEXMB05.cable.comcast.com> From: Richard Alimi Date: Sun, 25 Sep 2011 21:39:13 -0700 X-Google-Sender-Auth: 8EfDLVe3EHpBhtzKr_3-3GWIuZw Message-ID: To: "Woundy, Richard" Content-Type: text/plain; charset=ISO-8859-1 Cc: "decade@ietf.org" Subject: Re: [decade] CDMI 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, 26 Sep 2011 04:36:53 -0000 So, here's my two cents :) Conceptually DECADE Object IDs form a flat namespace, so that's why I was proposing to have a single "/decade" container beneath which all of the objects could be stored and referenced. The container could be created at installation time or on-demand, as determined by the DECADE server implementation. Then, one way to think about what we are proposing is for each user to have a "view" into the set of data objects at each particular DECADE Server. In that sense, Rich Woundy's suggestion of having one container per user makes sense. Then, data objects could be addressed by something like "//". I think that either of these addressing schemes could work. Consider a DECADE server receiving a request with a token "userid=A,object=1234". Using the flat namespace approach, a client would know to make a request for "/decade/1234" and present the token. The server could then internally validate the token and that user A does indeed have object 1234. Using the container-per-user approach, the DECADE client would know to make a request for "/A/1234" and the server then validate the token. The benefit of the container-per-user approach is that we'd get the check "does user A have object 1234" for free from CDMI. As another point, one thing we should consider is how traditional CDMI access controls interact with DECADE tokens. One way to think about it is that we are adding a way to bypass the normal ACL check in CDMI. Another, perhaps cleaner, to think about it is that we're adding a new "validate DECADE token" entry to each object's CDMI ACL. Rich On Fri, Sep 23, 2011 at 3:19 AM, Woundy, Richard wrote: > Or does the container correspond to the user? Do CDMI access controls derive from a container? > > -- Rich (as individual) > > ----- Original Message ----- > From: Songhaibin [mailto:haibin.song@huawei.com] > Sent: Friday, September 23, 2011 05:21 AM > To: Richard Alimi > Cc: decade@ietf.org > Subject: Re: [decade] CDMI > > Hi Rich, > > Thanks for the interesting answer. Then I still have doubts. Who creates this container? Who has the right to operate on this container? Maybe the DECADE service provider? > > BR, > -Haibin(as individual) > >> -----Original Message----- >> From: richard.alimi@gmail.com [mailto:richard.alimi@gmail.com] On Behalf Of >> Richard Alimi >> Sent: Friday, September 23, 2011 4:39 PM >> To: Songhaibin >> Cc: decade@ietf.org >> Subject: Re: [decade] CDMI >> >> On Fri, Sep 23, 2011 at 12:40 AM, Songhaibin >> wrote: >> > Dear folks, >> > >> > When I was reading CDMI protocol, it seems that the objects should be >> created within a "container". Then I had a question in mind. If we do not have >> the "container" concept in DECADE, the CDMI protocol needs change if we >> want to use it for DECADE. If there are many places need changes, I am not >> sure whether it is a good sign. >> > >> >> Could we put all objects in a container named "decade"? >> >> > BR, >> > -Haibin (as individual) >> > _______________________________________________ >> > 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 Sun Sep 25 21:45:26 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 5C0E921F84DC for ; Sun, 25 Sep 2011 21:45:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.864 X-Spam-Level: X-Spam-Status: No, score=-2.864 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RtOLwdN-HTAS for ; Sun, 25 Sep 2011 21:45:24 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id B010E21F84DB for ; Sun, 25 Sep 2011 21:45:23 -0700 (PDT) Received: by ywa6 with SMTP id 6so5021211ywa.31 for ; Sun, 25 Sep 2011 21:48:05 -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 :content-transfer-encoding; bh=Hg2yXOLv/l6Z5gSKjZjgGF9qhNGZ2uPDamrJUk70t8Y=; b=jHsgEMr5pz0z3JkzW8rl6uskplWxmX4ZnaKdHP9wlzatOGTY90EtceUOyxOKx+1fLZ nVyNgcIijhVheldtpB7FfEwFEl9bZ/bTZWrx295L4LXvvHhskhaOvGqXhsjsJRZE+7pj Be6LX3EfiPoV8Bg8LsUlljvHiR5Qx7l3PBP+s= Received: by 10.231.28.36 with SMTP id k36mr7982512ibc.12.1317012485196; Sun, 25 Sep 2011 21:48:05 -0700 (PDT) MIME-Version: 1.0 Sender: richard.alimi@gmail.com Received: by 10.231.148.203 with HTTP; Sun, 25 Sep 2011 21:47:45 -0700 (PDT) In-Reply-To: References: <1CA25301D2219F40B3AA37201F0EACD113690980@PACDCEXMB05.cable.comcast.com> From: Richard Alimi Date: Sun, 25 Sep 2011 21:47:45 -0700 X-Google-Sender-Auth: sf11XA5qzXFO0-9mEbHOUQi4L38 Message-ID: To: "Rahman, Akbar" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: decade@ietf.org Subject: Re: [decade] CDMI 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, 26 Sep 2011 04:45:26 -0000 Hi Akbar, On Fri, Sep 23, 2011 at 7:15 AM, Rahman, Akbar wrote: > Hi Rich/Haibin/Rich, > > > My understanding is as follows from reading the CDMI SNIA spec > http://snia.org/sites/default/files/CDMI_SNIA_Architecture_v1.0.pdf > > > 1)A container is a grouping of individual data objects. =A0All data > objects must be placed inside at least one level of container. =A0(See > data model in Fig. 6 on pg 13) > > 2) A user can create either an individual data object or a container > containing multiple data objects (see sec. 5.5 on pg. 11, and 1st > paragraph of pg. 14). =A0Similarly a user can read either the whole > container, or an individual object in the container (see sec. 5.5 on pg. > 15). =A0Finally, the access control for the user can be applied to both > the individual data object level or the container level through the > metadata concept. > > 3) The HTTP PUT command used to create a new container is shown in (sec > 6.2 on pg. 19). =A0The HTTP PUT command used to create a data object in a > container is shown in (sec. 6.3 on pg. 19). > > > Finally, the WEBDAV protocol also supports a concept called > "collections" (of resources) which is similar to the CDMI "container" > object (see http://tools.ietf.org/html/rfc4918#section-5). =A0So I think > this points to the fact that we should support some concept in DECADE > similar to a container. > I think we should be very careful when adding containers. For example, if we were to follow the approach of allowing arbitrary containers to be created, then we run into issues with naming. In particular, referring to an object by its name (content hash) no longer makes quite as much sense since the requesting client also need to know its path. Following that reasoning one step further, I think it would be better to avoid passing full paths within DRP tokens or the applications' native protocols since that then binds their implementations to a particular the DECADE data transport. It seems preferable to only need to pass around a DECADE object ID (and perhaps a userid that has local scope to a DECADE server), and then generate actual names in the data transport from only those components. Then the protocol could (eventually) evolve to allow one client to write an object using CDMI, and another client could receive a token and read the same object using NFS-with-RDMA. (Note that even though I did mention multiple data transports above, I still think we should only do one for now as mandatory - I just don't think we should create a design which makes it hard to add a new one later on.) Now, that said, I do think that containers might be useful for organizing the data objects within a *single* DECADE server. For example, have one container per user (as mentioned by Rich Woundy). Rich > > Any feedback would be appreciated. > > > Akbar > > -----Original Message----- > From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.org] On Behalf > Of Woundy, Richard > Sent: Friday, September 23, 2011 6:19 AM > To: 'haibin.song@huawei.com'; 'rich@velvetsea.net' > Cc: 'decade@ietf.org' > Subject: Re: [decade] CDMI > > Or does the container correspond to the user? Do CDMI access controls > derive from a container? > > -- Rich (as individual) > > ----- Original Message ----- > From: Songhaibin [mailto:haibin.song@huawei.com] > Sent: Friday, September 23, 2011 05:21 AM > To: Richard Alimi > Cc: decade@ietf.org > Subject: Re: [decade] CDMI > > Hi Rich, > > Thanks for the interesting answer. Then I still have doubts. Who creates > this container? Who has the right to operate on this container? Maybe > the DECADE service provider? > > BR, > -Haibin(as individual) > >> -----Original Message----- >> From: richard.alimi@gmail.com [mailto:richard.alimi@gmail.com] On > Behalf Of >> Richard Alimi >> Sent: Friday, September 23, 2011 4:39 PM >> To: Songhaibin >> Cc: decade@ietf.org >> Subject: Re: [decade] CDMI >> >> On Fri, Sep 23, 2011 at 12:40 AM, Songhaibin >> wrote: >> > Dear folks, >> > >> > When I was reading CDMI protocol, it seems that the objects should > be >> created within a "container". Then I had a question in mind. If we do > not have >> the "container" concept in DECADE, the CDMI protocol needs change if > we >> want to use it for DECADE. If there are many places need changes, I am > not >> sure whether it is a good sign. >> > >> >> Could we put all objects in a container named "decade"? >> >> > BR, >> > -Haibin (as individual) >> > _______________________________________________ >> > decade mailing list >> > decade@ietf.org >> > https://www.ietf.org/mailman/listinfo/decade >> > > _______________________________________________ > decade mailing list > decade@ietf.org > https://www.ietf.org/mailman/listinfo/decade > _______________________________________________ > decade mailing list > decade@ietf.org > https://www.ietf.org/mailman/listinfo/decade > From Dirk.Kutscher@neclab.eu Mon Sep 26 05:56:21 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 EB7F121F8C09 for ; Mon, 26 Sep 2011 05:56:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.511 X-Spam-Level: X-Spam-Status: No, score=-2.511 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T1MSa2B+kcTx for ; Mon, 26 Sep 2011 05:56:20 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 6B64E21F8C04 for ; Mon, 26 Sep 2011 05:56:20 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 668E5280001AA; Mon, 26 Sep 2011 14:59:02 +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 yhZp8IATGSOv; Mon, 26 Sep 2011 14:59:02 +0200 (CEST) Received: from METHONE.office.hd (Methone.office.hd [192.168.24.54]) by mailer1.neclab.eu (Postfix) with ESMTP id 43122280001C3; Mon, 26 Sep 2011 14:58:47 +0200 (CEST) Received: from DAPHNIS.office.hd ([169.254.2.240]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0323.003; Mon, 26 Sep 2011 14:58:47 +0200 From: Dirk Kutscher To: Richard Alimi , "Rahman, Akbar" Thread-Topic: [decade] CDMI Thread-Index: Acx5xAr74MsDa0HzSc2FXCEqj+EZmP//7ucAgAAL1ACAABAwAIAAQfUAgAQYYID//1YpIA== Date: Mon, 26 Sep 2011 12:58:46 +0000 Message-ID: <82AB329A76E2484D934BBCA77E9F52491CCE2719@DAPHNIS.office.hd> References: <1CA25301D2219F40B3AA37201F0EACD113690980@PACDCEXMB05.cable.comcast.com> 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.1.2.209] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "decade@ietf.org" Subject: Re: [decade] CDMI 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, 26 Sep 2011 12:56:22 -0000 Hi all, I think I agree to Rich A. here. I have not seen a strong requirement for c= ontainers in DECADE and would be hesitant to introduce the concept just bec= ause WEBDAV and CDMI support corresponding abstractions. Also, I do agree that DECADE identifiers should be independent from the DEC= ADE transport protocol for the reasons that Rich mentioned. Best regards, Dirk > -----Original Message----- > From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.org] On > Behalf Of Richard Alimi > Sent: Montag, 26. September 2011 06:48 > To: Rahman, Akbar > Cc: decade@ietf.org > Subject: Re: [decade] CDMI >=20 > Hi Akbar, >=20 > On Fri, Sep 23, 2011 at 7:15 AM, Rahman, Akbar > wrote: > > Hi Rich/Haibin/Rich, > > > > > > My understanding is as follows from reading the CDMI SNIA spec > > http://snia.org/sites/default/files/CDMI_SNIA_Architecture_v1.0.pdf > > > > > > 1)A container is a grouping of individual data objects. =A0All data > > objects must be placed inside at least one level of container. =A0(See > > data model in Fig. 6 on pg 13) > > > > 2) A user can create either an individual data object or a container > > containing multiple data objects (see sec. 5.5 on pg. 11, and 1st > > paragraph of pg. 14). =A0Similarly a user can read either the whole > > container, or an individual object in the container (see sec. 5.5 on pg= . > > 15). =A0Finally, the access control for the user can be applied to both > > the individual data object level or the container level through the > > metadata concept. > > > > 3) The HTTP PUT command used to create a new container is shown in > > (sec > > 6.2 on pg. 19). =A0The HTTP PUT command used to create a data object in > > a container is shown in (sec. 6.3 on pg. 19). > > > > > > Finally, the WEBDAV protocol also supports a concept called > > "collections" (of resources) which is similar to the CDMI "container" > > object (see http://tools.ietf.org/html/rfc4918#section-5). =A0So I thin= k > > this points to the fact that we should support some concept in DECADE > > similar to a container. > > >=20 > I think we should be very careful when adding containers. For example, i= f we > were to follow the approach of allowing arbitrary containers to be create= d, > then we run into issues with naming. In particular, referring to an obje= ct by > its name (content hash) no longer makes quite as much sense since the > requesting client also need to know its path. Following that reasoning o= ne > step further, I think it would be better to avoid passing full paths with= in DRP > tokens or the applications' native protocols since that then binds their > implementations to a particular the DECADE data transport. It seems > preferable to only need to pass around a DECADE object ID (and perhaps a > userid that has local scope to a DECADE server), and then generate actual > names in the data transport from only those components. Then the protoco= l > could (eventually) evolve to allow one client to write an object using CD= MI, > and another client could receive a token and read the same object using N= FS- > with-RDMA. >=20 > (Note that even though I did mention multiple data transports above, I st= ill > think we should only do one for now as mandatory - I just don't think we > should create a design which makes it hard to add a new one later on.) >=20 > Now, that said, I do think that containers might be useful for organizing= the > data objects within a *single* DECADE server. For example, have one > container per user (as mentioned by Rich Woundy). >=20 > Rich >=20 > > > > Any feedback would be appreciated. > > > > > > Akbar > > > > -----Original Message----- > > From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.org] On > > Behalf Of Woundy, Richard > > Sent: Friday, September 23, 2011 6:19 AM > > To: 'haibin.song@huawei.com'; 'rich@velvetsea.net' > > Cc: 'decade@ietf.org' > > Subject: Re: [decade] CDMI > > > > Or does the container correspond to the user? Do CDMI access controls > > derive from a container? > > > > -- Rich (as individual) > > > > ----- Original Message ----- > > From: Songhaibin [mailto:haibin.song@huawei.com] > > Sent: Friday, September 23, 2011 05:21 AM > > To: Richard Alimi > > Cc: decade@ietf.org > > Subject: Re: [decade] CDMI > > > > Hi Rich, > > > > Thanks for the interesting answer. Then I still have doubts. Who > > creates this container? Who has the right to operate on this > > container? Maybe the DECADE service provider? > > > > BR, > > -Haibin(as individual) > > > >> -----Original Message----- > >> From: richard.alimi@gmail.com [mailto:richard.alimi@gmail.com] On > > Behalf Of > >> Richard Alimi > >> Sent: Friday, September 23, 2011 4:39 PM > >> To: Songhaibin > >> Cc: decade@ietf.org > >> Subject: Re: [decade] CDMI > >> > >> On Fri, Sep 23, 2011 at 12:40 AM, Songhaibin > >> wrote: > >> > Dear folks, > >> > > >> > When I was reading CDMI protocol, it seems that the objects should > > be > >> created within a "container". Then I had a question in mind. If we do > > not have > >> the "container" concept in DECADE, the CDMI protocol needs change if > > we > >> want to use it for DECADE. If there are many places need changes, I > >> am > > not > >> sure whether it is a good sign. > >> > > >> > >> Could we put all objects in a container named "decade"? > >> > >> > BR, > >> > -Haibin (as individual) > >> > _______________________________________________ > >> > decade mailing list > >> > decade@ietf.org > >> > https://www.ietf.org/mailman/listinfo/decade > >> > > > _______________________________________________ > > decade mailing list > > decade@ietf.org > > https://www.ietf.org/mailman/listinfo/decade > > _______________________________________________ > > decade mailing list > > decade@ietf.org > > https://www.ietf.org/mailman/listinfo/decade > > > _______________________________________________ > decade mailing list > decade@ietf.org > https://www.ietf.org/mailman/listinfo/decade From Akbar.Rahman@InterDigital.com Mon Sep 26 09:12:36 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 3846A21F84A2 for ; Mon, 26 Sep 2011 09:12:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.374 X-Spam-Level: X-Spam-Status: No, score=-2.374 tagged_above=-999 required=5 tests=[AWL=0.225, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eQsrU6NCeGzF for ; Mon, 26 Sep 2011 09:12:34 -0700 (PDT) Received: from idcout.InterDigital.com (idcexmail.interdigital.com [12.32.197.135]) by ietfa.amsl.com (Postfix) with ESMTP id 1915321F8494 for ; Mon, 26 Sep 2011 09:12:33 -0700 (PDT) Received: from SAM.InterDigital.com ([10.30.2.12]) by idcout.InterDigital.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 26 Sep 2011 12:15:15 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 26 Sep 2011 12:15:14 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-topic: [decade] CDMI Thread-index: Acx8B32QQbCdZ1pqQxiOYOiE5G8X0QAXlBxw References: <1CA25301D2219F40B3AA37201F0EACD113690980@PACDCEXMB05.cable.comcast.com> From: "Rahman, Akbar" To: "Richard Alimi" X-OriginalArrivalTime: 26 Sep 2011 16:15:15.0540 (UTC) FILETIME=[79E49140:01CC7C67] Cc: decade@ietf.org Subject: Re: [decade] CDMI 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, 26 Sep 2011 16:12:36 -0000 Hi Rich, Thanks for your insights. One practical issue that I want to restate = for CDMI is that a root and/or container seems to be mandatory. That = is, even if you have only one object, it must be first placed within a = root and/or container. This means for example that you must to have = some knowledge of the URI path of the root and/or container in all cases = (i.e. knowledge of the URI beyond the authority part). So the object ID = itself is not enough to retrieve the object in CDMI (as you correctly = pointed out in your reasoning below). See for example section 8.2 of = http://snia.org/sites/default/files/CDMI_SNIA_Architecture_v1.0.pdf So if we wanted to re-use CDMI this implies that we would have to do = fairly major changes to it. I am not saying this is good or bad, I am = just pointing it out! Akbar -----Original Message----- From: richard.alimi@gmail.com [mailto:richard.alimi@gmail.com] On Behalf = Of Richard Alimi Sent: Monday, September 26, 2011 12:48 AM To: Rahman, Akbar Cc: Woundy, Richard; haibin.song@huawei.com; decade@ietf.org Subject: Re: [decade] CDMI Hi Akbar, On Fri, Sep 23, 2011 at 7:15 AM, Rahman, Akbar wrote: > Hi Rich/Haibin/Rich, > > > My understanding is as follows from reading the CDMI SNIA spec > http://snia.org/sites/default/files/CDMI_SNIA_Architecture_v1.0.pdf > > > 1)A container is a grouping of individual data objects. =A0All data > objects must be placed inside at least one level of container. =A0(See > data model in Fig. 6 on pg 13) > > 2) A user can create either an individual data object or a container > containing multiple data objects (see sec. 5.5 on pg. 11, and 1st > paragraph of pg. 14). =A0Similarly a user can read either the whole > container, or an individual object in the container (see sec. 5.5 on = pg. > 15). =A0Finally, the access control for the user can be applied to = both > the individual data object level or the container level through the > metadata concept. > > 3) The HTTP PUT command used to create a new container is shown in = (sec > 6.2 on pg. 19). =A0The HTTP PUT command used to create a data object = in a > container is shown in (sec. 6.3 on pg. 19). > > > Finally, the WEBDAV protocol also supports a concept called > "collections" (of resources) which is similar to the CDMI "container" > object (see http://tools.ietf.org/html/rfc4918#section-5). =A0So I = think > this points to the fact that we should support some concept in DECADE > similar to a container. > I think we should be very careful when adding containers. For example, if we were to follow the approach of allowing arbitrary containers to be created, then we run into issues with naming. In particular, referring to an object by its name (content hash) no longer makes quite as much sense since the requesting client also need to know its path. Following that reasoning one step further, I think it would be better to avoid passing full paths within DRP tokens or the applications' native protocols since that then binds their implementations to a particular the DECADE data transport. It seems preferable to only need to pass around a DECADE object ID (and perhaps a userid that has local scope to a DECADE server), and then generate actual names in the data transport from only those components. Then the protocol could (eventually) evolve to allow one client to write an object using CDMI, and another client could receive a token and read the same object using NFS-with-RDMA. (Note that even though I did mention multiple data transports above, I still think we should only do one for now as mandatory - I just don't think we should create a design which makes it hard to add a new one later on.) Now, that said, I do think that containers might be useful for organizing the data objects within a *single* DECADE server. For example, have one container per user (as mentioned by Rich Woundy). Rich > > Any feedback would be appreciated. > > > Akbar > > -----Original Message----- > From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.org] On = Behalf > Of Woundy, Richard > Sent: Friday, September 23, 2011 6:19 AM > To: 'haibin.song@huawei.com'; 'rich@velvetsea.net' > Cc: 'decade@ietf.org' > Subject: Re: [decade] CDMI > > Or does the container correspond to the user? Do CDMI access controls > derive from a container? > > -- Rich (as individual) > > ----- Original Message ----- > From: Songhaibin [mailto:haibin.song@huawei.com] > Sent: Friday, September 23, 2011 05:21 AM > To: Richard Alimi > Cc: decade@ietf.org > Subject: Re: [decade] CDMI > > Hi Rich, > > Thanks for the interesting answer. Then I still have doubts. Who = creates > this container? Who has the right to operate on this container? Maybe > the DECADE service provider? > > BR, > -Haibin(as individual) > >> -----Original Message----- >> From: richard.alimi@gmail.com [mailto:richard.alimi@gmail.com] On > Behalf Of >> Richard Alimi >> Sent: Friday, September 23, 2011 4:39 PM >> To: Songhaibin >> Cc: decade@ietf.org >> Subject: Re: [decade] CDMI >> >> On Fri, Sep 23, 2011 at 12:40 AM, Songhaibin >> wrote: >> > Dear folks, >> > >> > When I was reading CDMI protocol, it seems that the objects should > be >> created within a "container". Then I had a question in mind. If we do > not have >> the "container" concept in DECADE, the CDMI protocol needs change if > we >> want to use it for DECADE. If there are many places need changes, I = am > not >> sure whether it is a good sign. >> > >> >> Could we put all objects in a container named "decade"? >> >> > BR, >> > -Haibin (as individual) >> > _______________________________________________ >> > decade mailing list >> > decade@ietf.org >> > https://www.ietf.org/mailman/listinfo/decade >> > > _______________________________________________ > decade mailing list > decade@ietf.org > https://www.ietf.org/mailman/listinfo/decade > _______________________________________________ > decade mailing list > decade@ietf.org > https://www.ietf.org/mailman/listinfo/decade > From richard.alimi@gmail.com Mon Sep 26 09:42:08 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 3940211E80A6 for ; Mon, 26 Sep 2011 09:42:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.873 X-Spam-Level: X-Spam-Status: No, score=-2.873 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CJCauaX6AVxf for ; Mon, 26 Sep 2011 09:42:07 -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 2A3CE11E80A0 for ; Mon, 26 Sep 2011 09:42:07 -0700 (PDT) Received: by iaby26 with SMTP id y26so5905992iab.31 for ; Mon, 26 Sep 2011 09:44:50 -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 :content-transfer-encoding; bh=R0WbP1JDJjqCRPGY1HdKLR2rMT+L6QWnb2aq5HijuCc=; b=H0sK/uQKQHo8KJH0Kor+ZTufcpkgBlbpFsNNn8tCI9m9A1o7eLnoDU1+cvcHyQvgR6 n3VRTI0BuiMG1g9QuDYNxn0mga+CSpTxyUOuhoo1+l08FhZryDlxGYChlDdHMUVt5I9J XZSM3cXwC2cyusXnVdDRkhXB9EJNdPDVJMw1A= Received: by 10.231.81.70 with SMTP id w6mr8761220ibk.51.1317055490078; Mon, 26 Sep 2011 09:44:50 -0700 (PDT) MIME-Version: 1.0 Sender: richard.alimi@gmail.com Received: by 10.231.148.203 with HTTP; Mon, 26 Sep 2011 09:44:30 -0700 (PDT) In-Reply-To: References: <1CA25301D2219F40B3AA37201F0EACD113690980@PACDCEXMB05.cable.comcast.com> From: Richard Alimi Date: Mon, 26 Sep 2011 09:44:30 -0700 X-Google-Sender-Auth: YgzHORoxyRne0F_aNF75MNon5HY Message-ID: To: "Rahman, Akbar" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: decade@ietf.org Subject: Re: [decade] CDMI 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, 26 Sep 2011 16:42:08 -0000 On Mon, Sep 26, 2011 at 9:15 AM, Rahman, Akbar wrote: > Hi Rich, > > > Thanks for your insights. =A0One practical issue that I want to restate f= or CDMI is that a root and/or container seems to be mandatory. =A0That is, = even if you have only one object, it must be first placed within a root and= /or container. =A0This means for example that you must to have some knowled= ge of the URI path of the root and/or container in all cases (i.e. knowledg= e of the URI beyond the authority part). =A0So the object ID itself is not = enough to retrieve the object in CDMI (as you correctly pointed out in your= reasoning below). > Right - the DECADE client would need to be told (presumably by a DECADE specification) how to construct the URI for a particular DECADE data object. The same kind of thing would have had to be done if we went with WebDAV or HTTP. > See for example section 8.2 of http://snia.org/sites/default/files/CDMI_S= NIA_Architecture_v1.0.pdf > > > So if we wanted to re-use CDMI this implies that we would have to do fair= ly major changes to it. =A0I am not saying this is good or bad, I am just p= ointing it out! > Well, so I don't think we need to make use of all mechanisms that CDMI provides. For example, just because a CDMI server implementation also gives data objects their own unique Object ID that is unrelated to DECADE doesn't mean we need to refer to objects under that ID. Thanks, Rich > > > Akbar > > > > -----Original Message----- > From: richard.alimi@gmail.com [mailto:richard.alimi@gmail.com] On Behalf = Of Richard Alimi > Sent: Monday, September 26, 2011 12:48 AM > To: Rahman, Akbar > Cc: Woundy, Richard; haibin.song@huawei.com; decade@ietf.org > Subject: Re: [decade] CDMI > > Hi Akbar, > > On Fri, Sep 23, 2011 at 7:15 AM, Rahman, Akbar > wrote: >> Hi Rich/Haibin/Rich, >> >> >> My understanding is as follows from reading the CDMI SNIA spec >> http://snia.org/sites/default/files/CDMI_SNIA_Architecture_v1.0.pdf >> >> >> 1)A container is a grouping of individual data objects. =A0All data >> objects must be placed inside at least one level of container. =A0(See >> data model in Fig. 6 on pg 13) >> >> 2) A user can create either an individual data object or a container >> containing multiple data objects (see sec. 5.5 on pg. 11, and 1st >> paragraph of pg. 14). =A0Similarly a user can read either the whole >> container, or an individual object in the container (see sec. 5.5 on pg. >> 15). =A0Finally, the access control for the user can be applied to both >> the individual data object level or the container level through the >> metadata concept. >> >> 3) The HTTP PUT command used to create a new container is shown in (sec >> 6.2 on pg. 19). =A0The HTTP PUT command used to create a data object in = a >> container is shown in (sec. 6.3 on pg. 19). >> >> >> Finally, the WEBDAV protocol also supports a concept called >> "collections" (of resources) which is similar to the CDMI "container" >> object (see http://tools.ietf.org/html/rfc4918#section-5). =A0So I think >> this points to the fact that we should support some concept in DECADE >> similar to a container. >> > > I think we should be very careful when adding containers. =A0For > example, if we were to follow the approach of allowing arbitrary > containers to be created, then we run into issues with naming. =A0In > particular, referring to an object by its name (content hash) no > longer makes quite as much sense since the requesting client also need > to know its path. =A0Following that reasoning one step further, I think > it would be better to avoid passing full paths within DRP tokens or > the applications' native protocols since that then binds their > implementations to a particular the DECADE data transport. =A0It seems > preferable to only need to pass around a DECADE object ID (and perhaps > a userid that has local scope to a DECADE server), and then generate > actual names in the data transport from only those components. =A0Then > the protocol could (eventually) evolve to allow one client to write an > object using CDMI, and another client could receive a token and read > the same object using NFS-with-RDMA. > > (Note that even though I did mention multiple data transports above, I > still think we should only do one for now as mandatory - I just don't > think we should create a design which makes it hard to add a new one > later on.) > > Now, that said, I do think that containers might be useful for > organizing the data objects within a *single* DECADE server. For > example, have one container per user (as mentioned by Rich Woundy). > > Rich > >> >> Any feedback would be appreciated. >> >> >> Akbar >> >> -----Original Message----- >> From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.org] On Behalf >> Of Woundy, Richard >> Sent: Friday, September 23, 2011 6:19 AM >> To: 'haibin.song@huawei.com'; 'rich@velvetsea.net' >> Cc: 'decade@ietf.org' >> Subject: Re: [decade] CDMI >> >> Or does the container correspond to the user? Do CDMI access controls >> derive from a container? >> >> -- Rich (as individual) >> >> ----- Original Message ----- >> From: Songhaibin [mailto:haibin.song@huawei.com] >> Sent: Friday, September 23, 2011 05:21 AM >> To: Richard Alimi >> Cc: decade@ietf.org >> Subject: Re: [decade] CDMI >> >> Hi Rich, >> >> Thanks for the interesting answer. Then I still have doubts. Who creates >> this container? Who has the right to operate on this container? Maybe >> the DECADE service provider? >> >> BR, >> -Haibin(as individual) >> >>> -----Original Message----- >>> From: richard.alimi@gmail.com [mailto:richard.alimi@gmail.com] On >> Behalf Of >>> Richard Alimi >>> Sent: Friday, September 23, 2011 4:39 PM >>> To: Songhaibin >>> Cc: decade@ietf.org >>> Subject: Re: [decade] CDMI >>> >>> On Fri, Sep 23, 2011 at 12:40 AM, Songhaibin >>> wrote: >>> > Dear folks, >>> > >>> > When I was reading CDMI protocol, it seems that the objects should >> be >>> created within a "container". Then I had a question in mind. If we do >> not have >>> the "container" concept in DECADE, the CDMI protocol needs change if >> we >>> want to use it for DECADE. If there are many places need changes, I am >> not >>> sure whether it is a good sign. >>> > >>> >>> Could we put all objects in a container named "decade"? >>> >>> > BR, >>> > -Haibin (as individual) >>> > _______________________________________________ >>> > decade mailing list >>> > decade@ietf.org >>> > https://www.ietf.org/mailman/listinfo/decade >>> > >> _______________________________________________ >> decade mailing list >> decade@ietf.org >> https://www.ietf.org/mailman/listinfo/decade >> _______________________________________________ >> decade mailing list >> decade@ietf.org >> https://www.ietf.org/mailman/listinfo/decade >> > From internet-drafts@ietf.org Wed Sep 28 08:25:08 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 CFF621F0C65; Wed, 28 Sep 2011 08:25:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.473 X-Spam-Level: X-Spam-Status: No, score=-102.473 tagged_above=-999 required=5 tests=[AWL=-0.101, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tlygf0+KaDga; Wed, 28 Sep 2011 08:25:08 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD9FD1F0C60; Wed, 28 Sep 2011 08:25:07 -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.60 Message-ID: <20110928152507.32118.28713.idtracker@ietfa.amsl.com> Date: Wed, 28 Sep 2011 08:25:07 -0700 Cc: decade@ietf.org Subject: [decade] I-D Action: draft-ietf-decade-reqs-04.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: Wed, 28 Sep 2011 15:25:09 -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-04.txt Pages : 23 Date : 2011-09-28 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 storage and retrieval, 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). The requirements in this document are intended to ensure that the DECADE architecture includes all of the desired functionality for intended applications. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-decade-reqs-04.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-04.txt From internet-drafts@ietf.org Wed Sep 28 09:07: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 E080E11E80B2; Wed, 28 Sep 2011 09:07:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.586 X-Spam-Level: X-Spam-Status: No, score=-102.586 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qV-dgvMQHeQ6; Wed, 28 Sep 2011 09:07:17 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FE2611E8073; Wed, 28 Sep 2011 09:07:17 -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.60 Message-ID: <20110928160717.11537.29766.idtracker@ietfa.amsl.com> Date: Wed, 28 Sep 2011 09:07:17 -0700 Cc: decade@ietf.org Subject: [decade] I-D Action: draft-ietf-decade-arch-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: Wed, 28 Sep 2011 16:07:18 -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-03.txt Pages : 44 Date : 2011-09-28 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 is the capability to be provided by DECADE (DECoupled Application Data Enroute). This document presents an architecture for DECADE, 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-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-arch-03.txt From haibin.song@huawei.com Wed Sep 28 18:28:16 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 56A6311E80CC for ; Wed, 28 Sep 2011 18:28:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.975 X-Spam-Level: ** X-Spam-Status: No, score=2.975 tagged_above=-999 required=5 tests=[AWL=-9.026, BAYES_50=0.001, GB_I_INVITATION=-2, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-4, URIBL_SBL=20] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T1AMp3w930Af for ; Wed, 28 Sep 2011 18:28:15 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id 3A39811E80B0 for ; Wed, 28 Sep 2011 18:28:15 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LS90009ZG7SDE@szxga03-in.huawei.com> for decade@ietf.org; Thu, 29 Sep 2011 09:31:04 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LS90086QG7SY2@szxga03-in.huawei.com> for decade@ietf.org; Thu, 29 Sep 2011 09:31:04 +0800 (CST) Received: from szxeml208-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AEF14062; Thu, 29 Sep 2011 09:31:03 +0800 Received: from SZXEML402-HUB.china.huawei.com (10.82.67.32) by szxeml208-edg.china.huawei.com (172.24.2.60) with Microsoft SMTP Server (TLS) id 14.1.270.1; Thu, 29 Sep 2011 09:30:58 +0800 Received: from SZXEML524-MBS.china.huawei.com ([169.254.5.19]) by szxeml402-hub.china.huawei.com ([10.82.67.32]) with mapi id 14.01.0270.001; Thu, 29 Sep 2011 09:30:55 +0800 Date: Thu, 29 Sep 2011 01:30:55 +0000 From: Songhaibin X-Originating-IP: [10.138.41.129] 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: IETF 82 - Hotel Reservations - REMINDER Thread-index: AQHMfkH3Q18KX1gN5EK0fAT8wNqEbpVjki3w X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected Subject: [decade] FW: IETF 82 - Hotel Reservations - REMINDER 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, 29 Sep 2011 01:28:16 -0000 > -----Original Message----- > From: ietf-announce-bounces@ietf.org [mailto:ietf-announce-bounces@ietf.org] > On Behalf Of IETF Secretariat > Sent: Thursday, September 29, 2011 8:48 AM > To: IETF Announcement list > Cc: wgchairs@ietf.org; 82all@ietf.org; irsg@irtf.org > Subject: IETF 82 - Hotel Reservations - REMINDER > > 82nd IETF Meeting > Taipei, Taiwan > November 13-18, 2011 > Host: Taiwan Network Information Center (TWNIC) > Host Website: http://ietf82.tw/ > Meeting venue: Taipei International Convention Center (TICC) > http://www.ticc.com.tw/index_en.aspx > > Register online at: http://www.ietf.org/meetings/82/ > > 1. Registration > 2. Visas & Letters of Invitation > 3. Accommodations > 4. Host City Special Offer > 5. Companion Program > > 1. Registration > A. Early-Bird Registration - USD 650.00 Pay by Friday, 11 November > 2011 1700 PT (00:00 UTC) > B. After Early-Bird cutoff - USD 800.00 > C. Full-time Student Registrations - USD 150.00 (with proper ID) > D. One Day Pass Registration - USD 350.00 > E. Registration Cancellation > Cut-off for registration cancellation is Monday, > 07 November 2011 at 1700 PT (0000 UTC). > Cancellations are subject to a 10% (ten percent) > cancellation fee if requested by that date and time. > F. Online Registration and Payment ends Friday, 11 November 2011, > 1700 local Taipei time. > G. On-site Registration starting Sunday, 13 November 2011 at 1100 > local Taipei time. > > 2. Visas & Letters of Invitation: > Information on Visiting Taiwan, please visit: > http://ietf82.tw/info.html#h1 > and > http://www.boca.gov.tw/np.asp?ctNode=529&mp=2 > > After you complete the registration process, you will be given > the option of requesting a Letter of Invitation. You can request > the Letter of Invitation as soon as you finish registration, or > at a later time by following the link provided in the > confirmation email. > > 3. Accommodations - Please note cutoff dates > The IETF is holding blocks of guest rooms at 3 hotels in Taipei: > Grand Hyatt Taipei (Headquarter Hotel - adjacent to the TICC > and approximately a 3 minute walk); > Grand Room (single): NTD 7,000; USD 239; EUR 166; JPY 18,346 > Shangri-La Far Eastern Plaza Hotel (Overflow Hotel - approximately > 5-10 minute taxi ride, it is not accessible by walking, shuttle to > TICC daily at 8:15 AM with reservation); > Deluxe Room (single): NTD 6,300; USD 215; EUR 150; JPY 16,511 > Howard Plaza Hotel (Overflow Hotel - approximately 10 minute taxi ride, > approximately a 30 minute walk, accessible by subway and bus) > Superior Room (single): NTD 4,800; USD 164; EUR 114; JPY 12,580 > > Room rates include one complimentary daily buffet breakfast and > complimentary in-room high-speed Internet access. VAT of 5% is > included in the prices, VAT rates are subject to change. 10% service > charge is NOT included in the guest room rates. > > NOTE: Continental Breakfast will NOT be served at the meeting > venue since it is included in the guest room rate at the hotels > IETF is holding a block. > > Reservations Cut off Date: 12 October 2011 at the Grand Hyatt and > Shangri-La, 19 October 2011 at the Howard Plaza Hotel > > For additional information on rates and policies, please visit: > http://www.ietf.org/meeting/82/hotel.html > > 4. Host City Special Offer > Taiwan's Bureau of Foreign Trade kindly provides all participants > of international meetings held in Taipei (including IETF 82) a MEET > TAIWAN CARD, which offers free wireless Internet service and various > discounts for shopping, dining, accommodation, transportation, leisure, > entertainment, communication, and other services during the meeting. > The MEET TAIWAN CARD is free of charge. For more details, please visit > http://card.meettaiwan.com/welcome.aspx > You can also access this information through the Host's Web Page at: > http://ietf82.tw/ > > For those who need free wireless Internet service, we would like to > recommend to apply one as soon as possible. > > 5. Companion Program > If you are traveling with a friend or family member over 18 years > of age you can register them for the IETF Companion Program for > only USD 15.00 > > Benefits include: > - A special welcome reception for companions from 1630-1730 on > Sunday, 13 November > - Ability to attend the official Welcome Reception from 1700-1900 > on Sunday, 13 November > - A distinctive meeting badge that grants access to the venue > (not to be used to attend working sessions) > - Participation in a separate companion email list if you choose > to help communicate and make plans with other IETF Companions. > > You can register your companion at any time via the IETF website > or onsite at the meeting. > > To join the 82 companions mailing list see: > https://www.ietf.org/mailman/listinfo/82companions > > Only 45 days until the Taipei IETF! > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-announce From richard_woundy@cable.comcast.com Thu Sep 29 05:10:33 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 29A6721F8C94 for ; Thu, 29 Sep 2011 05:10:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.79 X-Spam-Level: X-Spam-Status: No, score=-101.79 tagged_above=-999 required=5 tests=[AWL=-0.283, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wfVdz8dfY9om for ; Thu, 29 Sep 2011 05:10:32 -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 9409121F85B5 for ; Thu, 29 Sep 2011 05:10:32 -0700 (PDT) Received: from ([24.40.55.40]) by copdcimo01.cable.comcast.com with ESMTP id 5503630.54956511; Thu, 29 Sep 2011 06:19:34 -0600 Received: from PACDCEXMB05.cable.comcast.com ([fe80::a5b0:e5c4:df1b:2367]) by pacdcexhub03.cable.comcast.com ([fe80::d1dd:b302:b617:3755%11]) with mapi id 14.01.0289.001; Thu, 29 Sep 2011 08:12:44 -0400 From: "Woundy, Richard" To: "decade@ietf.org" Thread-Topic: Start of WGLC for draft-ietf-decade-reqs-04 Thread-Index: Acu+91Byr8CuZlwMSYaaxFnqkg41Dy/qW7BQ Date: Thu, 29 Sep 2011 12:12:42 +0000 Message-ID: <1CA25301D2219F40B3AA37201F0EACD1136984EA@PACDCEXMB05.cable.comcast.com> References: <1CA25301D2219F40B3AA37201F0EACD113400ECC@PACDCEXMB05.cable.comcast.com> In-Reply-To: <1CA25301D2219F40B3AA37201F0EACD113400ECC@PACDCEXMB05.cable.comcast.com> 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: multipart/alternative; boundary="_000_1CA25301D2219F40B3AA37201F0EACD1136984EAPACDCEXMB05cabl_" MIME-Version: 1.0 Subject: [decade] Start of WGLC for draft-ietf-decade-reqs-04 X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Sep 2011 12:10:33 -0000 --_000_1CA25301D2219F40B3AA37201F0EACD1136984EAPACDCEXMB05cabl_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Folks, Haibin and I are starting the working group last call for draft-ietf-decade= -reqs-04, http://datatracker.ietf.org/doc/draft-ietf-decade-reqs/, to be co= mpleted by Monday October 17. Please send all concerns, suggestions and com= ments about this internet-draft to the DECADE mailing list, decade@ietf.org= . Authors, please do not make any additional changes to the internet-draft un= less directed by the WG chairs. Draft reviewers, it would be helpful to get your confirmation that your pre= vious review comments have been correctly reflected in this version. Thanks. -- Rich and Haibin --_000_1CA25301D2219F40B3AA37201F0EACD1136984EAPACDCEXMB05cabl_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Folks,

 

Haibin and I are start= ing the working group last call for draft-ietf-decade-reqs-04, http://= datatracker.ietf.org/doc/draft-ietf-decade-reqs/, to be completed by Mo= nday October 17. Please send all concerns, suggestions and comments about t= his internet-draft to the DECADE mailing list, decade@ietf.org.

 

Authors, please do not= make any additional changes to the internet-draft unless directed by the W= G chairs.

 

Draft reviewers, it wo= uld be helpful to get your confirmation that your previous review comments = have been correctly reflected in this version.

 

Thanks.

 

-- Rich and Haibin

--_000_1CA25301D2219F40B3AA37201F0EACD1136984EAPACDCEXMB05cabl_-- From richard_woundy@cable.comcast.com Thu Sep 29 05:11: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 9827E21F8CCA for ; Thu, 29 Sep 2011 05:11:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.878 X-Spam-Level: X-Spam-Status: No, score=-101.878 tagged_above=-999 required=5 tests=[AWL=-0.144, 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zY-4Cf1Ji4s5 for ; Thu, 29 Sep 2011 05:11: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 0D7F921F8C94 for ; Thu, 29 Sep 2011 05:11:27 -0700 (PDT) Received: from ([24.40.55.40]) by copdcimo01.cable.comcast.com with ESMTP id 5503630.54956649; Thu, 29 Sep 2011 06:20:30 -0600 Received: from PACDCEXMB05.cable.comcast.com ([fe80::a5b0:e5c4:df1b:2367]) by pacdcexhub03.cable.comcast.com ([fe80::d1dd:b302:b617:3755%11]) with mapi id 14.01.0289.001; Thu, 29 Sep 2011 08:13:57 -0400 From: "Woundy, Richard" To: "decade@ietf.org" Thread-Topic: Start of WGLC for draft-ietf-decade-arch-03 Thread-Index: AQHMfqFCTxqrA0OtdEywpt6h+qbSYw== Date: Thu, 29 Sep 2011 12:13:56 +0000 Message-ID: <1CA25301D2219F40B3AA37201F0EACD113698505@PACDCEXMB05.cable.comcast.com> References: <1CA25301D2219F40B3AA37201F0EACD113400ECC@PACDCEXMB05.cable.comcast.com> <1CA25301D2219F40B3AA37201F0EACD1136984EA@PACDCEXMB05.cable.comcast.com> In-Reply-To: <1CA25301D2219F40B3AA37201F0EACD1136984EA@PACDCEXMB05.cable.comcast.com> 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: multipart/alternative; boundary="_000_1CA25301D2219F40B3AA37201F0EACD113698505PACDCEXMB05cabl_" MIME-Version: 1.0 Subject: [decade] Start of WGLC for draft-ietf-decade-arch-03 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, 29 Sep 2011 12:11:28 -0000 --_000_1CA25301D2219F40B3AA37201F0EACD113698505PACDCEXMB05cabl_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Folks, Haibin and I are starting the working group last call for draft-ietf-decade= -arch-03, http://datatracker.ietf.org/doc/draft-ietf-decade-arch/, to be co= mpleted by Monday October 17. Please send all concerns, suggestions and com= ments about this internet-draft to the DECADE mailing list, decade@ietf.org= . Authors, please do not make any additional changes to the internet-draft un= less directed by the WG chairs. Draft reviewers, it would be helpful to get your confirmation that your pre= vious review comments have been correctly reflected in this version. Thanks. -- Rich and Haibin --_000_1CA25301D2219F40B3AA37201F0EACD113698505PACDCEXMB05cabl_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Folks,

 

Haibin and I are start= ing the working group last call for draft-ietf-decade-arch-03, http://datatracker.ietf.org/doc/draft-ietf-de= cade-arch/, to be completed by Mon= day October 17. Please send all concerns, suggestions and comments about this internet-draft to the DECADE mailing l= ist, decade@ietf.org.

 

Authors, please do not= make any additional changes to the internet-draft unless directed by the W= G chairs.

 

Draft reviewers, it wo= uld be helpful to get your confirmation that your previous review comments = have been correctly reflected in this version.

 

Thanks.

 

-- Rich and Haibin

--_000_1CA25301D2219F40B3AA37201F0EACD113698505PACDCEXMB05cabl_-- From haibin.song@huawei.com Fri Sep 30 01:47:01 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 29B4621F84F9 for ; Fri, 30 Sep 2011 01:47:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.835 X-Spam-Level: X-Spam-Status: No, score=-5.835 tagged_above=-999 required=5 tests=[AWL=0.536, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8OxhTfV3qcNx for ; Fri, 30 Sep 2011 01:46:59 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id 050A321F84D9 for ; Fri, 30 Sep 2011 01:46:59 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LSB000SJV61NT@szxga03-in.huawei.com> for decade@ietf.org; Fri, 30 Sep 2011 16:49:13 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LSB00KNWV61W3@szxga03-in.huawei.com> for decade@ietf.org; Fri, 30 Sep 2011 16:49:13 +0800 (CST) Received: from szxeml207-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AEA19276; Fri, 30 Sep 2011 16:49:12 +0800 Received: from SZXEML402-HUB.china.huawei.com (10.82.67.32) by szxeml207-edg.china.huawei.com (172.24.2.59) with Microsoft SMTP Server (TLS) id 14.1.270.1; Fri, 30 Sep 2011 16:48:55 +0800 Received: from SZXEML524-MBS.china.huawei.com ([169.254.5.19]) by szxeml402-hub.china.huawei.com ([10.82.67.32]) with mapi id 14.01.0270.001; Fri, 30 Sep 2011 16:47:53 +0800 Date: Fri, 30 Sep 2011 08:47:54 +0000 From: Songhaibin In-reply-to: <1CA25301D2219F40B3AA37201F0EACD1136984EA@PACDCEXMB05.cable.comcast.com> X-Originating-IP: [10.138.41.129] To: "Woundy, Richard" , "decade@ietf.org" Message-id: MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_jlcaGsfJKRQpwYL+EHlYFw)" Content-language: zh-CN Accept-Language: en-US, zh-CN Thread-topic: Start of WGLC for draft-ietf-decade-reqs-04 Thread-index: AQHMfqEvDjbZqaVGCUm/ijxtVozW4pVlmnkg X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <1CA25301D2219F40B3AA37201F0EACD113400ECC@PACDCEXMB05.cable.comcast.com> <1CA25301D2219F40B3AA37201F0EACD1136984EA@PACDCEXMB05.cable.comcast.com> Subject: Re: [decade] Start of WGLC for draft-ietf-decade-reqs-04 X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Sep 2011 08:47:01 -0000 --Boundary_(ID_jlcaGsfJKRQpwYL+EHlYFw) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thanks to the authors for the hard work to give this update. This document is in good shape. I only have a few comments. Section 3, Paragraph 2, last sentence, "...to be defined within the DECADE Working Group." Comment: Please note that a working group is not a long term body. But this document will last. So please do not refer to a working group in the document. Section 4.2.1 Paragraph 1, "DECADE MUST allow clients to specify at least two classes of services for service: lowest possible latency and latency non-critical." Comment: May need to change "two classes of services for service" to another description, this sentence seems a little awkward with "services/service". Section 6.1.1 Paragraph 2, last sentence, "it may still read/write data a DECADE Server if authorized by another DECADE Client." Comment: Need "from/to" before "a DECADE Server if...". BR, -Haibin From: Woundy, Richard [mailto:Richard_Woundy@cable.comcast.com] Sent: Thursday, September 29, 2011 8:13 PM To: decade@ietf.org Cc: Songhaibin; Woundy, Richard Subject: Start of WGLC for draft-ietf-decade-reqs-04 Folks, Haibin and I are starting the working group last call for draft-ietf-decade-reqs-04, http://datatracker.ietf.org/doc/draft-ietf-decade-reqs/, to be completed by Monday October 17. Please send all concerns, suggestions and comments about this internet-draft to the DECADE mailing list, decade@ietf.org. Authors, please do not make any additional changes to the internet-draft unless directed by the WG chairs. Draft reviewers, it would be helpful to get your confirmation that your previous review comments have been correctly reflected in this version. Thanks. -- Rich and Haibin --Boundary_(ID_jlcaGsfJKRQpwYL+EHlYFw) Content-type: text/html; charset=us-ascii Content-transfer-encoding: quoted-printable

 

Thanks to the authors for the hard work to give this update. This= document is in good shape. I only have a few comments.

 

Section 3, Paragraph 2, last sentence, “…to be define= d within the DECADE Working Group.”   

 

Comment: Please note that a working group is not a long term body= . But this document will last. So please do not refer to a working group in= the document.

 

Section 4.2.1 Paragraph 1, “DECADE MUST allow clients to sp= ecify at least two classes of services for service: lowest possible latency= and latency non-critical.”  

 

Comment: May need to change “two classes of services for se= rvice” to another description,  this sentence seems a little awk= ward with “services/service”.

 

 

Section 6.1.1 Paragraph 2,  last sentence, “it may sti= ll read/write data a DECADE Server if authorized by another DECADE Client.&= #8221;

 

Comment: Need “from/to” before “a DECADE Server= if…”.

 

BR,

-Haibin

 

 

From: Woundy, Richard [mailto:Richard_Woundy@cable.comcast.= com]
Sent: Thursday, September 29, 2011 8:13 PM
To: decade@ietf.org
Cc: Songhaibin; Woundy, Richard
Subject: Start of WGLC for draft-ietf-decade-reqs-04

 

Folks,<= o:p>

&n= bsp;

Haibin = and I are starting the working group last call for draft-ietf-decade-reqs-0= 4, http://= datatracker.ietf.org/doc/draft-ietf-decade-reqs/, to be completed by Mo= nday October 17. Please send all concerns, suggestions and comments about t= his internet-draft to the DECADE mailing list, decade@ietf.org.

&n= bsp;

Authors= , please do not make any additional changes to the internet-draft unless di= rected by the WG chairs.

&n= bsp;

Draft r= eviewers, it would be helpful to get your confirmation that your previous r= eview comments have been correctly reflected in this version.

&n= bsp;

Thanks.=

&n= bsp;

-- Rich= and Haibin

--Boundary_(ID_jlcaGsfJKRQpwYL+EHlYFw)--