From haibin.song@huawei.com Sun Jul 1 19:18:05 2012 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 A4AEC11E8101 for ; Sun, 1 Jul 2012 19:18:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.543 X-Spam-Level: X-Spam-Status: No, score=-5.543 tagged_above=-999 required=5 tests=[AWL=-0.236, BAYES_00=-2.599, MISSING_HEADERS=1.292, 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 3z5BXRb8YJlZ for ; Sun, 1 Jul 2012 19:18:05 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id E881411E8141 for ; Sun, 1 Jul 2012 19:18:04 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AHJ05547; Sun, 01 Jul 2012 22:18:08 -0400 (EDT) Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Sun, 1 Jul 2012 19:17:40 -0700 Received: from SZXEML414-HUB.china.huawei.com (10.82.67.153) by dfweml407-hub.china.huawei.com (10.193.5.132) with Microsoft SMTP Server (TLS) id 14.1.323.3; Sun, 1 Jul 2012 19:17:40 -0700 Received: from SZXEML534-MBX.china.huawei.com ([169.254.2.243]) by SZXEML414-HUB.china.huawei.com ([10.82.67.153]) with mapi id 14.01.0323.003; Mon, 2 Jul 2012 10:17:34 +0800 From: Songhaibin CC: "decade@ietf.org" Thread-Topic: [decade] I-D Action: draft-ietf-decade-integration-example-04.txt Thread-Index: AQHNT1ve7h+hzXN3OkG0Mpo80yBHF5cVUqFg Date: Mon, 2 Jul 2012 02:17:33 +0000 Message-ID: References: <20120621031333.24814.83113.idtracker@ietfa.amsl.com> In-Reply-To: <20120621031333.24814.83113.idtracker@ietfa.amsl.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.73] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [decade] I-D Action: draft-ietf-decade-integration-example-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: Mon, 02 Jul 2012 02:18:05 -0000 VGhlIGV4cGVydCByZXZpZXdlcnMgcGxlYXNlIGNoZWNrIGlmIHRoaXMgdmVyc2lvbiByZXNvbHZl ZCB5b3VyIGNvbW1lbnRzLg0KDQotSGFpYmluDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0NCj4gRnJvbTogZGVjYWRlLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpkZWNhZGUtYm91bmNl c0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mDQo+IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZw0KPiBT ZW50OiBUaHVyc2RheSwgSnVuZSAyMSwgMjAxMiAxMToxNCBBTQ0KPiBUbzogaS1kLWFubm91bmNl QGlldGYub3JnDQo+IENjOiBkZWNhZGVAaWV0Zi5vcmcNCj4gU3ViamVjdDogW2RlY2FkZV0gSS1E IEFjdGlvbjogZHJhZnQtaWV0Zi1kZWNhZGUtaW50ZWdyYXRpb24tZXhhbXBsZS0wNC50eHQNCj4g DQo+IA0KPiBBIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0aGUgb24tbGlu ZSBJbnRlcm5ldC1EcmFmdHMgZGlyZWN0b3JpZXMuDQo+ICBUaGlzIGRyYWZ0IGlzIGEgd29yayBp dGVtIG9mIHRoZSBEZWNvdXBsZWQgQXBwbGljYXRpb24gRGF0YSBFbnJvdXRlIFdvcmtpbmcNCj4g R3JvdXAgb2YgdGhlIElFVEYuDQo+IA0KPiAJVGl0bGUgICAgICAgICAgIDogSW50ZWdyYXRpb24g RXhhbXBsZXMgb2YgREVDQURFIFN5c3RlbQ0KPiAJQXV0aG9yKHMpICAgICAgIDogTmluZyBab25n DQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgWGlhb2h1aSBDaGVuDQo+ICAgICAgICAgICAg ICAgICAgICAgICAgICAgWmhpZ2FuZyBIdWFuZw0KPiAgICAgICAgICAgICAgICAgICAgICAgICAg IExpamlhbmcgQ2hlbg0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgIEhvbmdxaWFuZyBMaXUN Cj4gCUZpbGVuYW1lICAgICAgICA6IGRyYWZ0LWlldGYtZGVjYWRlLWludGVncmF0aW9uLWV4YW1w bGUtMDQudHh0DQo+IAlQYWdlcyAgICAgICAgICAgOiAyMw0KPiAJRGF0ZSAgICAgICAgICAgIDog MjAxMi0wNi0yMA0KPiANCj4gQWJzdHJhY3Q6DQo+ICAgIERlY291cGxlZCBBcHBsaWNhdGlvbiBE YXRhIEVucm91dGUgKERFQ0FERSkgc3lzdGVtIGlzIGFuIGluLW5ldHdvcmsNCj4gICAgc3RvcmFn ZSBpbmZyYXN0cnVjdHVyZSB3aGljaCBpcyBzdGlsbCB1bmRlciBkaXNjdXNzaW9uIGluIElFVEYu ICBUaGlzDQo+ICAgIGRvY3VtZW50IHByZXNlbnRzIHR3byBkZXRhaWxlZCBleGFtcGxlcyBvZiBo b3cgdG8gaW50ZWdyYXRlIHN1Y2ggaW4tDQo+ICAgIG5ldHdvcmsgc3RvcmFnZSBpbmZyYXN0cnVj dHVyZSBpbnRvIHBlZXItdG8tcGVlciAoUDJQKSBhcHBsaWNhdGlvbnMNCj4gICAgdG8gYWNoaWV2 ZSBtb3JlIGVmZmljaWVudCBjb250ZW50IGRpc3RyaWJ1dGlvbiwgYW5kIEFwcGxpY2F0aW9uIExh eWVyDQo+ICAgIFRyYWZmaWMgT3B0aW1pemF0aW9uIChBTFRPKSBzeXN0ZW0gdG8gYnVpbGQgYSBj b250ZW50IGRpc3RyaWJ1dGlvbg0KPiAgICBwbGF0Zm9ybSBmb3IgQ29udGVudCBQcm92aWRlcnMg KENQcykuDQo+IA0KPiANCj4gVGhlIElFVEYgZGF0YXRyYWNrZXIgc3RhdHVzIHBhZ2UgZm9yIHRo aXMgZHJhZnQgaXM6DQo+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWll dGYtZGVjYWRlLWludGVncmF0aW9uLWV4YW1wbGUNCj4gDQo+IFRoZXJlJ3MgYWxzbyBhIGh0bWxp emVkIHZlcnNpb24gYXZhaWxhYmxlIGF0Og0KPiBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k cmFmdC1pZXRmLWRlY2FkZS1pbnRlZ3JhdGlvbi1leGFtcGxlLTA0DQo+IA0KPiBBIGRpZmYgZnJv bSBwcmV2aW91cyB2ZXJzaW9uIGlzIGF2YWlsYWJsZSBhdDoNCj4gaHR0cDovL3Rvb2xzLmlldGYu b3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLWRlY2FkZS1pbnRlZ3JhdGlvbi1leGFtcGxlLTA0 DQo+IA0KPiANCj4gSW50ZXJuZXQtRHJhZnRzIGFyZSBhbHNvIGF2YWlsYWJsZSBieSBhbm9ueW1v dXMgRlRQIGF0Og0KPiBmdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLw0KDQo= From alex7822@163.com Sun Jul 1 21:28:05 2012 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 002E721F85B5 for ; Sun, 1 Jul 2012 21:28:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.347 X-Spam-Level: ** X-Spam-Status: No, score=2.347 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, RELAY_IS_220=2.118, 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 XEvrMKeJw2CR for ; Sun, 1 Jul 2012 21:28:04 -0700 (PDT) Received: from m13-89.163.com (m13-89.163.com [220.181.13.89]) by ietfa.amsl.com (Postfix) with ESMTP id AF73521F864D for ; Sun, 1 Jul 2012 21:28:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=163.com; s=s110527; h=Received:Date:From:To:Subject:In-Reply-To: References:Content-Type:MIME-Version:Message-ID; bh=70vJfIMcqahR Z9uPQ7sHrQ428IRInW5HX3ou1poq6M8=; b=PWsoVeI9kr1nSnqTNxiL7ZjM+KbX OSTbAhXKeLQkxNWwK3kFreCMEV1kkNcLkvNwmKvzlLfz7XxByaLyiF2NciaWjvgW pNFiD2cZL5MBEoYZHjZHEgLLhqNTu6ywjR5sXeEsCJO9T+BomFzQEV/YbLSFiZ07 phAGcvpPwOLJmrQ= Received: from alex7822$163.com ( [130.132.249.187] ) by ajax-webmail-wmsvr89 (Coremail) ; Mon, 2 Jul 2012 12:27:58 +0800 (CST) X-Originating-IP: [130.132.249.187] Date: Mon, 2 Jul 2012 12:27:58 +0800 (CST) From: ALEX To: decade@ietf.org X-Priority: 3 X-Mailer: Coremail Webmail Server Version SP_ntes V3.5 build 20120507(18390.4657.4663) Copyright (c) 2002-2012 www.mailtech.cn 163com In-Reply-To: <20120312204723.544.17954.idtracker@ietfa.amsl.com> References: <20120312204723.544.17954.idtracker@ietfa.amsl.com> X-CM-CTRLDATA: NkyakmZvb3Rlcl9odG09NDUzNjo4MQ== Content-Type: multipart/alternative; boundary="----=_Part_202103_307839140.1341203278944" MIME-Version: 1.0 Message-ID: <4a2ce023.1291f.13845f1ec61.Coremail.alex7822@163.com> X-CM-TRANSID: WcGowEB5RUBPI_FP7zJ7AA--.3292W X-CM-SenderInfo: xdoh5lqyssqiywtou0bp/xtbBFA-fyU9oqnE4vwAAs2 X-Coremail-Antispam: 1U5529EdanIXcx71UUUUU7vcSsGvfC2KfnxnUU== Subject: Re: [decade] I-D Action: draft-ietf-decade-reqs-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: Mon, 02 Jul 2012 04:28:05 -0000 ------=_Part_202103_307839140.1341203278944 Content-Type: text/plain; charset=GBK Content-Transfer-Encoding: 7bit A quick question needs clarification: "4.4.5. Offline Usage REQUIREMENT(S): A DECADE-compatible client MAY provide authorized access from remote clients to its in-network storage even if the DECADE client is actively running or connected to a DECADE- compatible server." Should it be " ....even if the DECADE client is NOT actively running or connected to a DECADE- compatible server...." ? Or I mis-understood the point here? At 2012-03-13 04:47:23,internet-drafts@ietf.org wrote: > >A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Decoupled Application Data Enroute Working Group of the IETF. > > Title : DECADE Requirements > Author(s) : Yingjie Gu > David A. Bryan > Yang Richard Yang > Richard Alimi > Filename : draft-ietf-decade-reqs-06.txt > Pages : 23 > Date : 2012-03-12 > > The target of the DECoupled Application Data Enroute (DECADE) system > 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- > compatible 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 a DECADE-compatible system > 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-06.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-06.txt > ------=_Part_202103_307839140.1341203278944 Content-Type: text/html; charset=GBK Content-Transfer-Encoding: 7bit
A quick question needs clarification:
 
"4.4.5.  Offline Usage
   REQUIREMENT(S):  A DECADE-compatible client MAY provide authorized
       access from remote clients to its in-network storage even if the
       DECADE client is actively running or connected to a DECADE-
       compatible server."
 
Should it be  " ....even if the DECADE client is NOT actively running or connected to a DECADE-
compatible server...." ? Or I mis-understood the point here?

At 2012-03-13 04:47:23,internet-drafts@ietf.org wrote:
>
>A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Decoupled Application Data Enroute Working Group of the IETF.
>
>	Title           : DECADE Requirements
>	Author(s)       : Yingjie Gu
>                          David A. Bryan
>                          Yang Richard Yang
>                          Richard Alimi
>	Filename        : draft-ietf-decade-reqs-06.txt
>	Pages           : 23
>	Date            : 2012-03-12
>
>   The target of the DECoupled Application Data Enroute (DECADE) system
>   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-
>   compatible 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 a DECADE-compatible system
>   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-06.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-06.txt
>


------=_Part_202103_307839140.1341203278944-- From pzhang.thu@gmail.com Sun Jul 1 22:01:36 2012 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 211BC11E8140 for ; Sun, 1 Jul 2012 22:01:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.845 X-Spam-Level: X-Spam-Status: No, score=-1.845 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, 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 D7wym5-NXuQ1 for ; Sun, 1 Jul 2012 22:01:34 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id D129911E8159 for ; Sun, 1 Jul 2012 22:01:33 -0700 (PDT) Received: by qcac10 with SMTP id c10so1901730qca.31 for ; Sun, 01 Jul 2012 22:01:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:reply-to:subject:references:x-priority:x-guid:x-mailer :mime-version:message-id:content-type; bh=N06HK7lH9CmxMkJtC06/8YqfNBAEd+Jv7Fk+clqTG1w=; b=F7+IeRDAL/+8B2HZdYN42dvKHWMG878ivmH4Qfdzii/UpsOF9Pp+4/ZIDbPeRtj+OI GZoFALIWyKGMiqGIwGKu5StiG7XwnLs97RByKTnblLHEefW2MQyNN5FntMaNAO03wclW /J8ny1bMDbgmAK7PWSiRbik6At6sJhDvlv3SpjZQSlQpJVwmVCVZNrWw9haQ97LownnQ UfFI48kCbJzuZrPOyQ4KPAkcHFNjw/zDG4RLlOEk9AGiGRw5RLU7VS//KfEQUTYrheEa 0UWK7oZ84Ahi3FwijSL+i8+e4P1fOsZzQYSf3mo9Vz1+9AI+fZXD7tcu9VROmC4AX1E8 T/lA== Received: by 10.229.135.17 with SMTP id l17mr5761784qct.124.1341205297118; Sun, 01 Jul 2012 22:01:37 -0700 (PDT) Received: from pzhang-PC (dhcp-130-132-249-182.central.yale.edu. [130.132.249.182]) by mx.google.com with ESMTPS id bh13sm28942809qab.21.2012.07.01.22.01.35 (version=SSLv3 cipher=OTHER); Sun, 01 Jul 2012 22:01:36 -0700 (PDT) Date: Mon, 2 Jul 2012 01:01:34 -0500 From: "Zhang Peng" To: yry , "DECADE@ietf.org" References: <4FEED79A.1090906@cs.yale.edu> X-Priority: 3 X-GUID: 748EE6AE-D031-4B69-8ECC-2E6CD0024576 X-Mailer: Foxmail 7.0.1.81[cn] Mime-Version: 1.0 Message-ID: <2012070201013396821769@gmail.com> Content-Type: multipart/alternative; boundary="----=_001_NextPart351113878362_=----" Subject: Re: [decade] -req and -arch documents X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "pzhang.thu" 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, 02 Jul 2012 05:01:36 -0000 This is a multi-part message in MIME format. ------=_001_NextPart351113878362_=---- Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 SGkgUmljaGFyZCwNCg0KVGhhbmtzIGZvciB5b3VyIGVmZm9ydC4gSGVyZSBhcmUgc29tZSBzdWdn ZXN0aW9uIGFib3V0IHRoZSByZXZpc2lvbiBvZiAtcmVxIGRvY3VtZW50cy4NCg0KRmlyc3QsIHJl Z2FyZGluZyBRMSwgSSB0aGluayB0aGVyZSBhcmUgaW5kZWVkIHNvbWUgb3ZlcmxhcHMgb24gdGVy bSBkZWZpbml0aW9ucyBpbiAtcmVxIGFuZCAtYXJjaCBkb2N1bWVudHMuIEluIGFkZGl0aW9uLCB0 aGV5IGFyZSBldmVuIG5vdCBjb25zaXN0ZW50LiBJIHRoaW5rIHdlIGNhbiBqdXN0IHB1dCB0aGVt IGluIHRoZSAtcmVxIGRvY3VtZW50LCBhbmQgZ2l2ZSBhIHBvaW50ZXIgaW4gLWFyY2ggZG9jdW1l bnQuIA0KUmVnYXJkaW5nIFEyLCBJIGFncmVlIHRoYXQgaW4gLWFyY2gsIHRoZXJlIGFyZSBzb21l IHBhcmFncmFwaHMgdGhhdCBhbHNvIGRvIHRoZSBqb2Igb2YgZGVmaW5lIHJlcXVpcmVtZW50cywg YW5kIG1heSBiZXR0ZXIgYmUgcHV0IGluIC1yZXEuIEZvciBuYW1pbmcsIHRoZSByZXFpaW4gLXJl cXVpcmVtZW50cyBnaXZlbiBpbiAtcmVxIGFyZSByYXRoZXIgc2ltcGxpc3RpYywgYW5kIHdlIGNh biBtb3ZlIHRoZSBtb3ZlIHRoZSBkZXRhaWxlZCByZXF1aXJlbWVudHMgdG8gLXJlcS4gQnV0IGZv ciAiaW1tdXRhYmxlIG9iamVjdCIsIEkgdGhpbmsgaXQgaXMgbW9yZSBsaWtlIGEgZGVzaWduIG9w dGlvbiBmb3IgdGhlIGFyY2hpdGVjdHVyZSAoc28gdGhhdCB0aGUgZGVzaWduIHdvdWxkIGJlIG11 Y2ggc2ltcGxpZmllZCksIHJhdGhlciB0aGFuIGEgc3lzdGVtIHJlcXVpcmVtZW50cyBmb3IgREVD QURFIHRvIGZ1bmN0aW9uLiAgVGh1cywgSSBzdWdnZXN0IHdlIGRvbid0IG1vdmUgdGhlIGltbXV0 YWJsZSBkYXRhIG9iamVjdHMgaW4gLWFyY2ggdG8gLXJlcSwgYW5kIHdlIGNhbiBldmVuIGRlbGV0 ZSB0aGVtIGluIC1yZXEuIEZpbmFsbHksIEkgd291bGQgc2F5IHRoYXQgdGhlcmUgaXMgbm8gY2xl YXIgY3V0IGZvciByZXF1aXJlbWVudCBhbmQgYXJjaGl0ZWN0dXJlLCBzaW5jZSB3aGVuIHdlIHNw ZWNpZnkgdGhlIHJlcXVpcmVtZW50cywgd2UgaGF2ZSBzb21lIGRlc2lnbiByYXRpb25hbGUgaW4g bWluZDsgYW5kIHdoZW4gd2UgZGVzaWduIHRoZSBhcmNoaXRlY3R1cmUsIHdlIHdvdWxkIGZpbmQg bW9yZSBjbGVhciByZXF1aXJlbWVudHMgZm9yIHRoZSBzcGVjaWZpYyBkZXNpZ24uIEl0IGlzIG5v dCBlYXN5IHRvIGZ1bGx5IGRlY291cGxlIHRoZW0uDQpSZWdhcmRpbmcgUTMsIEkgdGhpbmsgdGhl IG5ldyBvdXRsaW5lIG9mIHRoZSAtcmVxIGRvY3VtZW50IHNlZW1zIGJldHRlciwgYnV0IEkgdGhp bmsgaXQgaXMgYmV0dGVyIHRvIG9yZ2FuaXplIGl0IGludG8gdGhyZWUgcGFydHM6IGFjY2Vzcy9h dXRob3JpemF0aW9uLCByZXNvdXJjZSBjb250cm9sLCBkYXRhIHN0b3JhZ2UvdHJhbnNmZXIsIGZh aWx1cmUgaGFuZGxpbmcvZ2FtaW5nIHByZXZlbnRpb24uIFRoZSByYXRpb25hbGUgaXMgdGhhdCB0 aGUgZmlyc3QgcGFydCBpcyBhYm91dCBob3cgY2xpZW50IGFjY2VzcyB0aGUgc2VydmVyLCB0aGUg c2Vjb25kIHBhcnQgY29ycmVzcG9uZHMgdG8gRFJQLCB0aGUgdGhpcmQgcGFydCBjb3JyZXNwb25k cyB0byBTRFQsIGFuZCB0aGUgbGFzdCB0d28gcGFydHMgYXJlIGFib3V0IHJlbGlhYmlsaXR5L3Nl Y3VyaXR5LiBUaGUgZm9sbG93aW5nIGlzIHRoZSBvdXRsaW5lIGluIG15IG1pbmQuIEkgd291bGQg bGlrZSB0byBkaXNjdXNzIHdpdGggeW91IGFib3V0IHRoZSBvcmdhbml6YXRpb24gZnVydGhlci4g QW5kIEkgd291bGQgbGlrZSB0byBoZWxwIHJldmlzZSB0aGUgLXJlcSBkb2N1bWVudC4gIFRoYW5r cy4NCg0KQmVzdCwNCg0KUGVuZy4NCg0KMS4gSW50cm9kdWN0aW9uIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gNQ0KMi4gVGVybWlub2xvZ3kgYW5kIENv bmNlcHRzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gNg0KMy4gU3lzdGVt L0Z1bmN0aW9uYWwgQ29tcG9uZW50cw0KNC4gUmVxdWlyZW1lbnRzIFN0cnVjdHVyZSAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gNw0KDQo1LiBEYXRhIE9iamVjdCBSZXF1 aXJlbWVudHMNCjQuNS4xLiBEYXRhIE5hbWluZyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuMTQNCk1vdmUgcGFydCBvZiBBcmNoIDQuNCB0byAtcmVxDQo0LjIuMS4g RGF0YSBPYmplY3QgU2l6ZSAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTENCjQu NC4yLiBTeXN0ZW0gRGF0YSBPYmplY3QgQXR0cmlidXRlcyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuMTMNCjQuNC4zLiBUaW1lLXRvLWxpdmUgZm9yIFdyaXR0ZW4gRGF0YSBPYmplY3RzIC4gLiAu IC4gLiAuIDEzDQo0LjQuNC4gQXBwbGljYXRpb24tZGVmaW5lZCBQcm9wZXJ0aWVzIGFuZCBNZXRh ZGF0YSAuIC4gLiAuIC4gMTMNCg0KNi4gQXV0aGVudGljYXRpb24gYW5kIEFjY2VzcyBSZXF1aXJl bWVudHMNCjQuNy4xLiBQZXItUmVtb3RlLUNsaWVudCwgUGVyLURhdGEgUmVhZCBBY2Nlc3MgLiAu IC4gLiAuIC4gLiAxNg0KNC43LjIuIFBlci1Vc2VyIFdyaXRlIEFjY2VzcyAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIDE3DQo0LjcuMy4gRGVmYXVsdCBBY2Nlc3MgUGVybWlzc2lvbnMg LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDE3DQo0LjcuNC4gQXV0aG9yaXphdGlvbiBDaGVj a3MgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDE3DQo0LjcuNS4gQ3J5cHRvZ3Jh cGhpYyBDcmVkZW50aWFscyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTcNCjQuNy42LiBT ZXJ2ZXIgSW52b2x2ZW1lbnQgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTgN CjQuNy43LiBQcm90b2NvbCBSZXVzZSAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gMTgNCjQuMy4xLiBSZWFkL1dyaXRlIE93biBTdG9yYWdlIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuLiAxMQ0KNC4zLjIuIFJlYWQvV3JpdGUgYnkgUmVtb3RlIENsaWVudHMgLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxMQ0KNC40LjUuIE9mZmxpbmUgQWNjZXNzIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTQNCg0KNy4gRGF0YSBUcmFuc2ZlciBSZXF1 aXJlbWVudHMgDQo0LjEuMS4xLiBOQVRzIGFuZCBGaXJld2FsbHMgVFJhdmVyc2FsIC4gLiAuLiAu IC4gLiAuIC4gLiAuIC4gOA0KQ29ubmVjdGlvbnMgdG8gQ2xpZW50cyAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIDgNCjYuMS4xLiBTdXBwb3J0IGZvciBDbGllbnRzIEJlaGlu ZCBOQVRzIGFuZCBGaXJld2FsbHMgLiAuIC4gMjENCjQuMy4zLiBOZWdvdGlhYmxlIERhdGEgVHJh bnNwb3J0IFByb3RvY29sIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTINCjQuMS4yLjEuIFNlY3VyZSBU cmFuc3BvcnQgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gOA0KDQo4LiBSZXNv dXJjZSBDb250cm9sIFJlcXVpcmVtZW50cy4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAxNQ0KNC42LjEuIE11bHRpcGxlIEFwcGxpY2F0aW9ucyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIDE1DQo0LjYuMi4gUGVyLVJlbW90ZS1DbGllbnQsIFBlci1EYXRhIENvbnRyb2wg LiAuIC4gLiAuIC4gLiAuIC4gMTUNCjQuNi4zLiBSZXNvdXJjZSBDb250cm9sIFNldCAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTYNCjQuNi40LiBTZXJ2ZXIgSW52b2x2ZW1lbnQg LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTYNCjguIEF1dGhvcml6YXRpb24g UmVxdWlyZW1lbnRzDQoNCjkuIEVycm9yIGFuZCBGYWlsdXJlIEhhbmRsaW5nIFJlcXVpcmVtZW50 cy4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDkNCjQuMS4zLjIuIEluc3VmZmljaWVudCBSZXNvdXJj ZXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gOQ0KNC4xLjMuMS4gT3ZlcmxvYWQgQ29u ZGl0aW9uIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDkNCjQuMS4zLjMuIFVuYXZhaWxh YmxlIGFuZCBEZWxldGVkIERhdGEgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTANCjQuMS4zLjQu IEluc3VmZmljaWVudCBQZXJtaXNzaW9ucyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTAN CjQuMS4zLjUuIFJlZGlyZWN0aW9uIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAxMA0KNC4xLjIuMi4gR2FtaW5nIFByZXZlbnRpb24gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC44DQo0LjQuMS4gU2VydmVyIHJlbGlhYmlsaXR5IChBZ25vc3RpYyBvZiBy ZWxpYWJpbGl0eSkgLiAuIC4gLiAuIDEyDQoNCjEwLiBTZXJ2ZXIgU3RhdHVzIFF1ZXJ5IFJlcXVp cmVtZW50cyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxOA0KNS43LiBTdG9yYWdlIFN0 YXR1cyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAyMA0KLi4uLg0K DQoxMS4gU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAyMQ0KNy4xLiBBdXRoZW50aWNhdGlvbiBhbmQgQXV0aG9yaXphdGlvbiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAyMQ0KNy4yLiBFbmNyeXB0ZWQgRGF0YSAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAyMg0KNy4zLiBQcm90ZWN0aW9uIGFnYWluc3Qg R2FtaW5nIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDIyDQoNCg0KDQoNClpoYW5nIFBl bmcNCg0KRnJvbTogWS4gUmljaGFyZCBZYW5nDQpEYXRlOiAyMDEyLTA2LTMwIDA2OjQwDQpUbzog REVDQURFQGlldGYub3JnDQpTdWJqZWN0OiBbZGVjYWRlXSAtcmVxIGFuZCAtYXJjaCBkb2N1bWVu dHMNCkRlYXIgREVDQURFIHBhcnRpY2lwYW50cywNCg0KQm90aCAtcmVxIGFuZCAtYXJjaCBkb2N1 bWVudHMgaGF2ZSByZWNlaXZlZCBleHRlbnNpdmUsIGV4Y2VsbGVudCANCnJldmlld3MuIEluIHRo ZSBwcm9jZXNzIG9mIHJldmlzaW5nIHRoZSBkb2N1bWVudHMgYW5kIGxvb2tpbmcgYXQgdGhlIHR3 byANCmRvY3VtZW50cywgd2UgaGF2ZSBzb21lIHF1ZXN0aW9ucyB0byBzZWVrIGlucHV0IGZyb20g dGhlIHBhcnRpY2lwYW50czoNCg0KUTEuIEJvdGggLXJlcSBhbmQgLWFyY2ggZGVmaW5lIHNvbWUg dGVybXMsIGluY2x1ZGluZyBERUNBREUtY29tcGF0aWJsZSANCmNsaWVudCwgREVDQURFLWNvbXBh dGlibGUgc2VydmVyLCBldGMuIFRoaXMgYXBwZWFycyB0byBiZSByZWR1bmRhbnQuIA0KU2hvdWxk IHN1Y2ggdGVybXMgYmUgZGVmaW5lZCBpbiAtcmVxIG9yIC1hcmNoPyBUaGUgY3VycmVudCB0aGlu a2luZyBpcyANCi1yZXEuIEFueSBjb21tZW50cz8NCg0KUTIuIFRoZXJlIGFyZSBtdWx0aXBsZSBw YXJhZ3JhcGhzIGRlZmluaW5nIHJlcXVpcmVtZW50cyBpbiAtYXJjaCwgZS5nLiwgDQpTZWMuIDQu NCBvbiBuYW1pbmcuIFNob3VsZCB0aGVzZSBiZSBtb3ZlZCB0byAtcmVxPyBBIG1vcmUgZ2VuZXJh bCANCnF1ZXN0aW9uIGlzIG9uIHRoZSBkZXBlbmRlbmN5IGJldHdlZW4gLXJlcSBhbmQgLWFyY2gu IE9uIG9uZSBoYW5kLCBpdCBpcyANCmlkZWFsIHRvIGRlZmluZSAtcmVxIGZpcnN0IHdpdGhvdXQg YSBwYXJ0aWN1bGFyIGFyY2hpdGVjdHVyZSB0byBhbGxvdyANCmNvbXBldGluZy9hbHRlcm5hdGl2 ZSBhcmNoaXRlY3R1cmVzIHNhdGlzZnlpbmcgdGhlIHJlcXVpcmVtZW50cy4gT24gdGhlIA0Kb3Ro ZXIgaGFuZCwgaXQgYXBwZWFycyB0aGF0IHRoZSAtYXJjaCBkb2N1bWVudCBjb250YWlucyBjb250 ZW50LCBpbiANCnBhcnRpY3VsYXIsIHN5c3RlbXMvZnVuY3Rpb24gY29tcG9uZW50cywgdGhhdCBj YW4gYmUgaGVscGZ1bCB0byBiZXR0ZXIgDQp1bmRlcnN0YW5kIHRoZSAtcmVxIGRvY3VtZW50LiBU aGUgY3VycmVudCB0aGlua2luZyBpcyBzdGlsbCB0byBtYWtlIC1yZXEgDQppbmRlcGVuZGVudCBv ZiAtYXJjaCwgYW5kIG1vdmUgc29tZSBnZW5lcmFsIHJlcXVpcmVtZW50cyBpbiAtYXJjaCB0byAN Ci1yZXEuIEFueSBjb21tZW50cz8NCg0KUTM6IFRoZXJlIGFyZSBzb21lIGdvb2QgY29tbWVudHMg b24gcmVvcmdhbml6aW5nIHRoZSAtcmVxIGRvY3VtZW50cy4gDQpCZWxvdyBpcyBhIG5ldyBzdHJ1 Y3R1cmUgKHNlY29uZCBsZXZlbCBzZWN0aW9uICMncyBhbmQgcGFnZSBudW1iZXJzIGFyZSANCmZy b20gdGhlIGN1cnJlbnQgLXJlcSBzbyB0aGF0IG90aGVycyBjYW4gc2VlIGhvdyB3ZSByZS1vcmdh bml6ZSB0aGUgDQpkb2N1bWVudCkuIEFueSBjb21tZW50cy9mZWVkYmFjayBiZWZvcmUgd2Ugc3Rh cnQgdGhlIHJldmlzaW9uIHdpbGwgYmUgDQpncmVhdGx5IGFwcHJlY2lhdGVkLg0KDQpBbHNvLCBh bnlvbmUgd2hvIGNhbiBoZWxwIHdpdGggZGlyZWN0IHJldmlzaW9ucyBvZiB0aGUgLXJlcSBkb2N1 bWVudCANCndpbGwgYmUgbW9yZSB0aGFuIHdlbGNvbWUhDQoNClRoYW5rcy4NCg0KLS0gDQpSaWNo YXJkDQoNCjEuICBJbnRyb2R1Y3Rpb24gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAgNQ0KMi4gIFRlcm1pbm9sb2d5IGFuZCBDb25jZXB0cyAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA2DQozLiAgU3lzdGVtL0Z1bmN0aW9uYWwg Q29tcG9uZW50cw0KNC4gIFJlcXVpcmVtZW50cyBTdHJ1Y3R1cmUgLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuICA3DQoNCjUuICBEYXRhIE9iamVjdCBSZXF1aXJlbWVudHMN CiAgICAgNC41LjEuICBEYXRhIE5hbWluZyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuMTQNCiAgICAgICAgICAgICBNb3ZlIHBhcnQgb2YgQXJjaCA0LjQgdG8gLXJl cQ0KICAgICA1LjEuICAtLUltbXV0YWJsZSBEYXRhIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAxOA0KICAgICA0LjQuMi4gIFN5c3RlbSBEYXRhIE9iamVjdCBBdHRyaWJ1 dGVzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4xMw0KICAgICAgICAgNC4yLjEuICBEYXRhIE9i amVjdCBTaXplIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxMQ0KICAgICAgICAg NC40LjMuICBUaW1lLXRvLWxpdmUgZm9yIFdyaXR0ZW4gRGF0YSBPYmplY3RzICAuIC4gLiAuIC4g LiAxMw0KICAgICA0LjQuNC4gIEFwcGxpY2F0aW9uLWRlZmluZWQgUHJvcGVydGllcyBhbmQgTWV0 YWRhdGEgIC4gLiAuIC4gLiAxMw0KDQo2LiAgQWNjZXNzIHRvIFNlcnZlciBSZXF1aXJlbWVudHMN CiAgICAgNC4zLjEuICBSZWFkL1dyaXRlIE93biBTdG9yYWdlICAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLi4gMTENCiAgICAgNC4zLjIuICBSZWFkL1dyaXRlIGJ5IFJlbW90ZSBDbGllbnRz IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTENCiAgICAgNC40LjUuICBPZmZsaW5lIEFjY2Vz cyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgLiAuIC4gMTQNCiAgICAgNC4xLjEu MS4gIE5BVHMgYW5kIEZpcmV3YWxscyBUUmF2ZXJzYWwgLiAuIC4uIC4gLiAgLiAuIC4gLiAuIC4g IDgNCiAgICAgICBDb25uZWN0aW9ucyB0byBDbGllbnRzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gIDgNCiAgICAgICA2LjEuMS4gIFN1cHBvcnQgZm9yIENsaWVudHMgQmVo aW5kIE5BVHMgYW5kIEZpcmV3YWxscyAgLiAuIC4gMjENCiAgICAgNC4zLjMuICBOZWdvdGlhYmxl IERhdGEgVHJhbnNwb3J0IFByb3RvY29sIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTINCiAgICAgNS4y LiAgRXhwbGljaXQgRGVsZXRpb24gb2YgRGF0YSAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gMTkNCiAgICAgNS4zLiAgQ29uY3VycmVudCBXcml0ZSAoTXVsdGlwbGUgd3JpdGluZykuIC4g LiAuIC4gLiAuIC4gLiAuIC4gMTkNCiAgICAgNS40LiAgQ29uY3VycmVudCBSZWFkIChNdWx0aXBs ZSByZWFkaW5nKSAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTkNCiAgICAgNS41LiAgUmVhZCBXaGls ZSBXcml0ZSAuIC4gLiAuIC4gLiAuIC4gICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTkNCiAgICAg NS42LiAgUGFydGlhbCBXcml0ZSAoV3JpdGluZyBtb2RlbCkgLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAyMA0KICAgICA0LjEuMi4xLiAgU2VjdXJlIFRyYW5zcG9ydCAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAgOA0KDQo3LiAgUmVzb3VyY2UgQ29udHJvbCBSZXF1aXJlbWVu dHMuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTUNCiAgICAgNC42LjEuICBNdWx0 aXBsZSBBcHBsaWNhdGlvbnMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTUNCiAg ICAgNC42LjIuICBQZXItUmVtb3RlLUNsaWVudCwgUGVyLURhdGEgQ29udHJvbCAgLiAuIC4gLiAu IC4gLiAuIC4gMTUNCiAgICAgNC42LjMuICBSZXNvdXJjZSBDb250cm9sIFNldCAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTYNCiAgICAgNC42LjQuICBTZXJ2ZXIgSW52b2x2ZW1l bnQgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTYNCg0KOC4gIEF1dGhvcml6 YXRpb24gUmVxdWlyZW1lbnRzDQogICAgIDQuNy4xLiAgUGVyLVJlbW90ZS1DbGllbnQsIFBlci1E YXRhIFJlYWQgQWNjZXNzICAuIC4gLiAuIC4gLiAuIDE2DQogICAgIDQuNy4yLiAgUGVyLVVzZXIg V3JpdGUgQWNjZXNzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDE3DQogICAgIDQu Ny4zLiAgRGVmYXVsdCBBY2Nlc3MgUGVybWlzc2lvbnMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIDE3DQogICAgIDQuNy40LiAgQXV0aG9yaXphdGlvbiBDaGVja3MgLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIDE3DQogICAgIDQuNy41LiAgQ3J5cHRvZ3JhcGhpYyBDcmVkZW50 aWFscyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDE3DQogICAgIDQuNy42LiAgU2VydmVy IEludm9sdmVtZW50IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDE4DQogICAg IDQuNy43LiAgUHJvdG9jb2wgUmV1c2UgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIDE4DQoNCjkuICBFcnJvciBhbmQgRmFpbHVyZSBIYW5kbGluZyBSZXF1aXJlbWVudHMu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgOQ0KICAgICA0LjEuMy4yLiAgSW5zdWZmaWNpZW50IFJl c291cmNlcyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgOQ0KICAgICAgICAgNC4xLjMu MS4gIE92ZXJsb2FkIENvbmRpdGlvbiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgOQ0K ICAgICA0LjEuMy4zLiAgVW5hdmFpbGFibGUgYW5kIERlbGV0ZWQgRGF0YSAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAxMA0KICAgICA0LjEuMy40LiAgSW5zdWZmaWNpZW50IFBlcm1pc3Npb25zIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxMA0KICAgICA0LjEuMy41LiAgUmVkaXJlY3Rpb24g IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxMA0KICAgICA0LjEuMi4y LiAgR2FtaW5nIFByZXZlbnRpb24gIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu OA0KICAgICA0LjQuMS4gIFNlcnZlciByZWxpYWJpbGl0eSAoQWdub3N0aWMgb2YgcmVsaWFiaWxp dHkpIC4gLiAuIC4gLiAxMg0KDQoxMC4gU2VydmVyIFN0YXR1cyBRdWVyeSBSZXF1aXJlbWVudHMg LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTgNCiAgICAgNS43LiAgU3RvcmFnZSBTdGF0 dXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMjANCiAgICAgLi4u Lg0KDQoxMS4gU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gMjENCiAgICAgNy4xLiAgQXV0aGVudGljYXRpb24gYW5kIEF1dGhvcml6 YXRpb24gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMjENCiAgICAgNy4yLiAgRW5jcnlwdGVkIERh dGEgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMjINCiAgICAgNy4z LiAgUHJvdGVjdGlvbiBhZ2FpbnN0IEdhbWluZyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gMjI= ------=_001_NextPart351113878362_=---- Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Richard,
 
Thanks for your effort. Here are some sugg= estion=20 about the revision of -req documents.
 
First, regarding Q1, I think there are ind= eed some=20 overlaps on term definitions in -req and -arch documents. In addition= , they=20 are even not consistent. I think we can just put them in the -req document= , and give a pointer in -arch document.
Regarding Q2, I agree that in -arch, there= are=20 some paragraphs that also do the job of define requirements, and may bette= r be=20 put in -req. For naming, the reqiin -requirements given in -req are r= ather=20 simplistic, and we can move the move the detailed requirements to -req.&nb= sp;But=20 for "immutable object", I think it is more like a design option for the=20 architecture (so that the design would be much simplified), rather than a = system=20 requirements for DECADE to function.  Thus, I suggest we don't move t= he=20 immutable data objects in -arch to -req, and we can even delete them in -r= eq.=20 Finally, I would say that there is no clear cut for requirement and=20 architecture, since when we specify the requirements, we have some design=20 rationale in mind; and when we design the architecture, we would find more= clear=20 requirements for the specific design. It is not easy to fully decouple=20 them.
Regarding Q3, I think the new outline of t= he -req=20 document seems better, but I think it is better to organize it into three = parts:=20 access/authorization, resource control, data storage/transfer, failure=20 handling/gaming prevention. The rationale is that the first part is about = how=20 client access the server, the second part corresponds to DRP, the third pa= rt=20 corresponds to SDT, and the last two parts are about reliability/security.= The=20 following is the outline in my mind. I would like to discuss with you abou= t the=20 organization further. And I would like to help revise the -req document.&n= bsp;=20 Thanks.
 
Best,
 
Peng.
 
1. Introduction . . . . . . . . . . . . .= . . . .=20 . . . . . . . . 5
2. Terminology and Concepts . . . . . . .= . . . .=20 . . . . . . . . 6
3. System/Functional Components
4. Requirements Structure . . . . . . . .= . . . .=20 . . . . . . . . 7
 
5. Data Object Requirements
4.5.1. Data Naming . . . . . . . . . . . . . . . . . . . . . .14
Move part of Arch 4.4 to -req
4.2.1. Data Object Size . . . . . . . . . . . . . . . . . 11
4.4.2. System Data Object Attributes . . . . . . . . . . . . .13
4.4.3. Time-to-live for Written Data Objects . . . . . . 13
4.4.4. Application-defined Properties and Metadata . . . . . 13
 
6. Authentication and Access Requirements=
4.7.1. Per-Remote-Client, Per-Data Read Access . . . . . . . 16
4.7.2. Per-User Write Access . . . . . . . . . . . . . . . . 17
4.7.3. Default Access Permissions . . . . . . . . . . . . . . 17
4.7.4. Authorization Checks . . . . . . . . . . . . . . . . . 17
4.7.5. Cryptographic Credentials . . . . . . . . . . . . . . 17
4.7.6. Server Involvement . . . . . . . . . . . . . . . . . . 18
4.7.7. Protocol Reuse . . . . . . . . . . . . . . . . . . . .=20 18
4.3.1. Read/Write Own Storage . . . . . . . . . . . . . . .. 11
4.3.2. Read/Write by Remote Clients . . . . . . . . . . . . . 11
4.4.5. Offline Access . . . . . . . . . . . . . . . . . . . 14
 
7. Data Transfer Requirements 
=
4.1.1.1. NATs and Firewalls TRaversal . . .. . . . . . . . . 8
Connections to Clients . . . . . . . . . . . . . . . . . . . 8
6.1.1. Support for Clients Behind NATs and Firewalls . . . 21
4.3.3. Negotiable Data Transport Protocol . . . . . . . . . . 12
4.1.2.1. Secure Transport . . . . . . . . . . . . . . . . . . 8
 
8. Resource Control Requirements. . . . .= . . . .=20 . . . . . . . . 15
4.6.1. Multiple Applications . . . . . . . . . . . . . . . . 15
4.6.2. Per-Remote-Client, Per-Data Control . . . . . . . . . 15
4.6.3. Resource Control Set . . . . . . . . . . . . . . . . . 16
4.6.4. Server Involvement . . . . . . . . . . . . . . . . . . 16
8. Authorization Requirements
 
9. Error and Failure Handling Requirement= s. . . .=20 . . . . . . . . 9
4.1.3.2. Insufficient Resources . . . . . . . . . . . . . . . 9
4.1.3.1. Overload Condition . . . . . . . . . . . . . . . 9
4.1.3.3. Unavailable and Deleted Data . . . . . . . . . . . . 10
4.1.3.4. Insufficient Permissions . . . . . . . . . . . . . . 10
4.1.3.5. Redirection . . . . . . . . . . . . . . . . . . . . 10
4.1.2.2. Gaming Prevention . . . . . . . . . . . . . . . . . .8
4.4.1. Server reliability (Agnostic of reliability) . . . . . 12
 
10. Server Status Query Requirements . . = . . . .=20 . . . . . . . . . 18
5.7. Storage Status . . . . . . . . . . . . . . . . . . . . . 20
....
 
11. Security Considerations . . . . . . .= . . . .=20 . . . . . . . . 21
7.1. Authentication and Authorization . . . . . . . . . . . . 21
7.2. Encrypted Data . . . . . . . . . . . . . . . . . . . . . 22
7.3. Protection against Gaming . . . . . . . . . . . . . . . 22
=
 
Zhang Peng
 
Date: 2012-06-30 06:40
Subject: [decade] -req and -arch documents
Dear DECADE participants,
 
Both -req and -arch documents have rece= ived extensive, excellent 
reviews. In the process of revising the=  documents and looking at the two 
documents, we have some questions to se= ek input from the participants:
 
Q1. Both -req and -arch define some&nbs= p;terms, including DECADE-compatible 
client, DECADE-compatible server, etc. This = appears to be redundant. 
Should such terms be defined in -req&nb= sp;or -arch? The current thinking is 
-req. Any comments?
 
Q2. There are multiple paragraphs defining&n= bsp;requirements in -arch, e.g., 
Sec. 4.4 on naming. Should these be&nbs= p;moved to -req? A more general 
question is on the dependency between -= req and -arch. On one hand, it is =
ideal to define -req first without a&nb= sp;particular architecture to allow 
competing/alternative architectures satisfying the&nbs= p;requirements. On the 
other hand, it appears that the -arch&n= bsp;document contains content, in 
particular, systems/function components, that can=  be helpful to better 
understand the -req document. The current&nb= sp;thinking is still to make -req 
independent of -arch, and move some gen= eral requirements in -arch to 
-req. Any comments?
 
Q3: There are some good comments on&nbs= p;reorganizing the -req documents. 
Below is a new structure (second level&= nbsp;section #'s and page numbers are 
from the current -req so that others&nb= sp;can see how we re-organize the 
document). Any comments/feedback before we s= tart the revision will be 
greatly appreciated.
 
Also, anyone who can help with direct&n= bsp;revisions of the -req document 
will be more than welcome!
 
Thanks.
 
-- 
Richard
 
1.  Introduction . . . . . .&= nbsp;. . . . . . . . . . = ;. . . . . . . . .  5
2.  Terminology and Concepts . . .=  . . . . . . . . . .&nbs= p;. . . . . .  6
3.  System/Functional Components
4.  Requirements Structure . . . .=  . . . . . . . . . .&nbs= p;. . . . . .  7
 
5.  Data Object Requirements
     4.5.1.  Data Naming = ;. . . . . . . . . . .&n= bsp;. . . . . . . . . . = .14
           &nb= sp; Move part of Arch 4.4 to -req
     5.1.  --Immutable Data&n= bsp;. . . . . . . . . . = . . . . . . . . . . 18
     4.4.2.  System Data = ;Object Attributes . . . . . . .&n= bsp;. . . . . .13
         4.2.1. &nb= sp;Data Object Size . . . . . .&nb= sp;. . . . . . . . . . .=  11
         4.4.3. &nb= sp;Time-to-live for Written Data Objects  .&= nbsp;. . . . . 13
     4.4.4.  Application-defined&n= bsp;Properties and Metadata  . . . .&nb= sp;. 13
 
6.  Access to Server Requirements
     4.3.1.  Read/Write Own&n= bsp;Storage  . . . . . . . .&= nbsp;. . . . . . .. 11
     4.3.2.  Read/Write by&nb= sp;Remote Clients . . . . . . .&nb= sp;. . . . . . 11
     4.4.5.  Offline Access&n= bsp; . . . . . . . . . .=  . . . . . .  . . . = ;14
     4.1.1.1.  NATs and = Firewalls TRaversal . . .. . .  .&= nbsp;. . . . .  8
       Connections to Cl= ients . . . . . . . . . = . . . . . . . . . . &nbs= p;8
       6.1.1.  Support&n= bsp;for Clients Behind NATs and Firewalls &n= bsp;. . . 21
     4.3.3.  Negotiable Data&= nbsp;Transport Protocol . . . . . .&nbs= p;. . . . 12
     5.2.  Explicit Deletion&= nbsp;of Data  . . . . . . .&n= bsp;. . . . . . . . 19
     5.3.  Concurrent Write&n= bsp;(Multiple writing). . . . . . .&nbs= p;. . . . 19
     5.4.  Concurrent Read&nb= sp;(Multiple reading) . . . . . . = . . . . . 19
     5.5.  Read While Wr= ite . . . . . . . .  &nb= sp;. . . . . . . . . . .=  19
     5.6.  Partial Write = ;(Writing model) . . . . . . .&nbs= p;. . . . . . 20
     4.1.2.1.  Secure Transpo= rt . . . . . . . . . .&n= bsp;. . . . . . . .  8
 
7.  Resource Control Requirements. . .&= nbsp;. . . . . . . . . . = ;. . . . 15
     4.6.1.  Multiple Applica= tions  . . . . . . . . .=  . . . . . . . 15
     4.6.2.  Per-Remote-Client,&nb= sp;Per-Data Control  . . . . . .&n= bsp;. . . 15
     4.6.3.  Resource Control=  Set . . . . . . . . .&n= bsp;. . . . . . . . 16
     4.6.4.  Server Involveme= nt . . . . . . . . . .&n= bsp;. . . . . . . . 16
 
8.  Authorization Requirements
     4.7.1.  Per-Remote-Client,&nb= sp;Per-Data Read Access  . . . . .=  . . 16
     4.7.2.  Per-User Write&n= bsp;Access  . . . . . . . .&n= bsp;. . . . . . . . 17
     4.7.3.  Default Access&n= bsp;Permissions . . . . . . . .&nb= sp;. . . . . . 17
     4.7.4.  Authorization Ch= ecks . . . . . . . . . .=  . . . . . . . 17
     4.7.5.  Cryptographic Cr= edentials  . . . . . . . .&nb= sp;. . . . . . 17
     4.7.6.  Server Involveme= nt . . . . . . . . . .&n= bsp;. . . . . . . . 18
     4.7.7.  Protocol Reuse&n= bsp;. . . . . . . . . . = . . . . . . . . . . 18
 
9.  Error and Failure Handling Requirem= ents. . . . . . . . . . = . .  9
     4.1.3.2.  Insufficient R= esources . . . . . . . . .&nb= sp;. . . . . .  9
         4.1.3.1. &= nbsp;Overload Condition . . . . . .&nbs= p;. . . . . . . . .  9
     4.1.3.3.  Unavailable an= d Deleted Data . . . . . . .&= nbsp;. . . . . 10
     4.1.3.4.  Insufficient P= ermissions . . . . . . . . .&= nbsp;. . . . . 10
     4.1.3.5.  Redirection &n= bsp;. . . . . . . . . . = . . . . . . . . . . 10
     4.1.2.2.  Gaming Prevent= ion  . . . . . . . . .&n= bsp;. . . . . . . . .8
     4.4.1.  Server reliabili= ty (Agnostic of reliability) . . . .&nb= sp;. 12
 
10. Server Status Query Requirements . = . . . . . . . . . . .&nb= sp;. . . 18
     5.7.  Storage Status&nbs= p;. . . . . . . . . . .&= nbsp;. . . . . . . . . . = ;20
     ....
 
11. Security Considerations  . . . = ;. . . . . . . . . . .&n= bsp;. . . . . 21
     7.1.  Authentication and=  Authorization . . . . . . . = . . . . . 21
     7.2.  Encrypted Data&nbs= p;. . . . . . . . . . .&= nbsp;. . . . . . . . . . = ;22
     7.3.  Protection against=  Gaming  . . . . . . . .=  . . . . . . . 22
 
 
------=_001_NextPart351113878362_=------ From yang.r.yang@gmail.com Sun Jul 1 22:48:25 2012 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 7EB9F11E8089 for ; Sun, 1 Jul 2012 22:48:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.862 X-Spam-Level: X-Spam-Status: No, score=-2.862 tagged_above=-999 required=5 tests=[AWL=-0.113, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, 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 LP5nOkQcw3CA for ; Sun, 1 Jul 2012 22:48:24 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id B1A8811E816C for ; Sun, 1 Jul 2012 22:48:23 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so8883119obb.31 for ; Sun, 01 Jul 2012 22:48:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=Bm1Iu6UOTBDMPWm5RC18g4lDh6MZeslcnR4Aiib3jFk=; b=CDX1Dntu2PE7n086JAmFD3Sixd+cWaCDLwP0Mkmezhoe6ZVsUkuSI8snU84p+crmEU HwB9QiuHNdorySE6nJUcOMi44Y1QirFvOyh7iUUgFoog7qLxx0rSKLYjwTP6fT+7r+k7 vC8H28GwUbz6Emi01cUZw3GbzNvNzP3sa1avx6e0BJpvdT5Edo/vr6daHf75EyAxuKbj F3gQsCFUTiSoKWgqxmevuNkegl+xQJ6AvxOmUNF6nUz3npICDnFzJ8/5QpkaP1+V4luy FQ5BCEOaDpNs4bnGbE8lutHnQEYwg4t4DpfEUuOA38B6oZiOzTMWkMy68Z9JZM6DFvpF f9aQ== MIME-Version: 1.0 Received: by 10.182.231.6 with SMTP id tc6mr6488647obc.63.1341208107712; Sun, 01 Jul 2012 22:48:27 -0700 (PDT) Sender: yang.r.yang@gmail.com Received: by 10.76.86.136 with HTTP; Sun, 1 Jul 2012 22:48:27 -0700 (PDT) In-Reply-To: <4a2ce023.1291f.13845f1ec61.Coremail.alex7822@163.com> References: <20120312204723.544.17954.idtracker@ietfa.amsl.com> <4a2ce023.1291f.13845f1ec61.Coremail.alex7822@163.com> Date: Mon, 2 Jul 2012 13:48:27 +0800 X-Google-Sender-Auth: w0IafPbJ_5Jq-Xs13GXYSs_0r9o Message-ID: From: "Y. Richard Yang" To: ALEX Content-Type: multipart/alternative; boundary=f46d0446312cd4829004c3d25842 Cc: "decade@ietf.org" Subject: Re: [decade] I-D Action: draft-ietf-decade-reqs-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: Mon, 02 Jul 2012 05:48:25 -0000 --f46d0446312cd4829004c3d25842 Content-Type: text/plain; charset=ISO-8859-1 Dear Alex, On Monday, July 2, 2012, ALEX wrote: > A quick question needs clarification: > > "4.4.5. Offline Usage > REQUIREMENT(S): A DECADE-compatible client MAY provide authorized > access from remote clients to its in-network storage even if the > DECADE client is actively running or connected to a DECADE- > compatible server." > > Should it be " ....even if the DECADE client is NOT actively running or > connected to a DECADE- > compatible server...." ? Or I mis-understood the point here? > You are right. It is a typo that we will fix. Thanks for pointing it out. Richard > > At 2012-03-13 04:47:23,internet-drafts@ietf.org wrote: > > > >A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Decoupled Application Data Enroute Working Group of the IETF. > > > > Title : DECADE Requirements > > Author(s) : Yingjie Gu > > David A. Bryan > > Yang Richard Yang > > Richard Alimi > > Filename : draft-ietf-decade-reqs-06.txt > > Pages : 23 > > Date : 2012-03-12 > > > > The target of the DECoupled Application Data Enroute (DECADE) system > > 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- > > compatible 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 a DECADE-compatible system > > 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-06.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-06.txt > > > > It --f46d0446312cd4829004c3d25842 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear Alex,

On Monday, July 2, 2012, ALEX wrote:
A quic= k question needs clarification:
=A0
"4.4.5.=A0 Off= line Usage
=A0=A0 REQUIREMENT(S):=A0 A DECADE-compatible client M= AY provide authorized
=A0=A0=A0=A0=A0=A0 access from remote clients to its in-network storage eve= n if the
=A0=A0=A0=A0=A0=A0 DECADE client is actively running or connect= ed to a DECADE-
=A0=A0=A0=A0=A0=A0 compatible server."
= =A0
Should it be =A0" ....even if the=A0DECADE client is NOT= actively running or connected to a DECADE-
compatible server...." ? Or I mis-understood the point here?

You are right. It is a typo= that we will fix. Thanks for pointing it out.

Richard=A0

At=A02012-03-13=A004:47:23,internet-draf=
ts@ietf.org=A0wrote:
>
>A=A0New=A0Internet-Draft=A0is=A0available=A0from=A0the=A0on-line=A0Inte=
rnet-Drafts=A0directories.=A0This=A0draft=A0is=A0a=A0work=A0item=A0of=A0the=
=A0Decoupled=A0Application=A0Data=A0Enroute=A0Working=A0Group=A0of=A0the=A0=
IETF.
>
>	Title=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0:=A0DECADE=A0Requirements
>	Author(s)=A0=A0=A0=A0=A0=A0=A0:=A0Yingjie=A0Gu
>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0David=A0A.=A0Bryan
>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0Yang=A0Richard=A0Yang
>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0Richard=A0Alimi
>	Filename=A0=A0=A0=A0=A0=A0=A0=A0:=A0draft-ietf-decade-reqs-06.txt
>	Pages=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0:=A023
>	Date=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0:=A02012-03-12
>
>=A0=A0=A0The=A0target=A0of=A0the=A0DECoupled=A0Application=A0Data=A0Enr=
oute=A0(DECADE)=A0system
>=A0=A0=A0is=A0to=A0provide=A0an=A0open=A0and=A0standard=A0in-network=A0=
storage=A0system=A0for
>=A0=A0=A0applications,=A0primarily=A0P2P=A0(peer-to-peer)=A0application=
s,=A0to=A0store,
>=A0=A0=A0retrieve=A0and=A0manage=A0their=A0data.=A0=A0This=A0draft=A0en=
umerates=A0and=A0explains
>=A0=A0=A0requirements,=A0not=A0only=A0for=A0storage=A0and=A0retrieval,=
=A0but=A0also=A0for=A0data
>=A0=A0=A0management,=A0access=A0control=A0and=A0resource=A0control,=A0t=
hat=A0should=A0be
>=A0=A0=A0considered=A0during=A0the=A0design=A0and=A0implementation=A0of=
=A0a=A0DECADE-
>=A0=A0=A0compatible=A0system.=A0=A0These=A0are=A0requirements=A0on=A0th=
e=A0entire=A0system;=A0some
>=A0=A0=A0of=A0the=A0requirements=A0may=A0eventually=A0be=A0implemented=
=A0by=A0an=A0existing
>=A0=A0=A0protocol=A0with/without=A0some=A0extensions=A0(e.g.,=A0a=A0pro=
tocol=A0used=A0to=A0read
>=A0=A0=A0and=A0write=A0data=A0from=A0the=A0storage=A0system).=A0=A0The=
=A0requirements=A0in=A0this
>=A0=A0=A0document=A0are=A0intended=A0to=A0ensure=A0that=A0a=A0DECADE-co=
mpatible=A0system
>=A0=A0=A0architecture=A0includes=A0all=A0of=A0the=A0desired=A0functiona=
lity=A0for=A0intended
>=A0=A0=A0applications.
>
>
>
>A=A0URL=A0for=A0this=A0Internet-Draft=A0is:
>http://www.ietf.org/internet-drafts/draft-ietf-dec=
ade-reqs-06.txt
>
>Internet-Drafts=A0are=A0also=A0available=A0by=A0anonymous=A0FTP=A0at:
>ftp:/=
/ftp.ietf.org/internet-drafts/
>
>This=A0Internet-Draft=A0can=A0be=A0retrieved=A0at:
>ftp://ftp.ietf.org/internet-drafts/draft-ietf-decad=
e-reqs-06.txt
>
It=A0
--f46d0446312cd4829004c3d25842-- From alex7822@163.com Sun Jul 1 23:27:45 2012 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 6EE8121F8582 for ; Sun, 1 Jul 2012 23:27:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.233 X-Spam-Level: ** X-Spam-Status: No, score=2.233 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_50=0.001, HTML_MESSAGE=0.001, RELAY_IS_220=2.118] 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 bgm6t6tWF8Sw for ; Sun, 1 Jul 2012 23:27:44 -0700 (PDT) Received: from m13-89.163.com (m13-89.163.com [220.181.13.89]) by ietfa.amsl.com (Postfix) with ESMTP id 0B08B21F8507 for ; Sun, 1 Jul 2012 23:27:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=163.com; s=s110527; h=Received:Date:From:To:Cc:Subject:In-Reply-To: References:Content-Type:MIME-Version:Message-ID; bh=CncCxfDqxuwF xzeemJX1n1MJ/8f+0++IsxWFLspX1qQ=; b=CKuMqtfFQQctSIgJXT9h+dLZ3W4m wonw93l6+G60Owy+TSN7XQFjTopAEGnwvrZnTO0k8d3pOkSolkiP6fxHSkB66Xdd bEjEsWTiyEXkejBoQZsPtx2YxsWFRRKmzOLuMuzaKUs4LL1GUbH6vNE3Q24i0s7n 1pFKuK1vQC634n4= Received: from alex7822$163.com ( [130.132.249.187] ) by ajax-webmail-wmsvr89 (Coremail) ; Mon, 2 Jul 2012 14:27:37 +0800 (CST) X-Originating-IP: [130.132.249.187] Date: Mon, 2 Jul 2012 14:27:37 +0800 (CST) From: "C. Alexandre Tian" To: "Y. Richard Yang" X-Priority: 3 X-Mailer: Coremail Webmail Server Version SP_ntes V3.5 build 20120507(18390.4657.4663) Copyright (c) 2002-2012 www.mailtech.cn 163com In-Reply-To: <4FEED79A.1090906@cs.yale.edu> References: <4FEED79A.1090906@cs.yale.edu> X-CM-CTRLDATA: XE/Ra2Zvb3Rlcl9odG09MTM4MTU6ODE= Content-Type: multipart/alternative; boundary="----=_Part_228053_1101806223.1341210457132" MIME-Version: 1.0 Message-ID: <4494f820.14fc0.138465f742c.Coremail.alex7822@163.com> X-CM-TRANSID: WcGowEA5gkZZP_FP9Wh7AA--.318W X-CM-SenderInfo: xdoh5lqyssqiywtou0bp/1tbiUBTfyU9o0c4klwAAsZ X-Coremail-Antispam: 1U5529EdanIXcx71UUUUU7vcSsGvfC2KfnxnUU== Cc: "DECADE@ietf.org" Subject: Re: [decade] -req and -arch documents 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, 02 Jul 2012 06:27:45 -0000 ------=_Part_228053_1101806223.1341210457132 Content-Type: text/plain; charset=GBK Content-Transfer-Encoding: 7bit Regards Q2: To me, all subsections in -arch "4. Architectural Principles" can be considered as candidates, which can be carefully re-organized and moved to -req. For example, similar content in "4.1. Decoupled Control/Metadata and Data Planes - Resource Scheduling Algorithms" has already appeared in problem statement doc "3.3 Ineffective integration of P2P applications". If we want to repeat/emphasize this information, the best place is -req. At 2012-06-30 18:40:26,"Y. Richard Yang" wrote: >Dear DECADE participants, > >Both -req and -arch documents have received extensive, excellent >reviews. In the process of revising the documents and looking at the two >documents, we have some questions to seek input from the participants: > >Q1. Both -req and -arch define some terms, including DECADE-compatible >client, DECADE-compatible server, etc. This appears to be redundant. >Should such terms be defined in -req or -arch? The current thinking is >-req. Any comments? > >Q2. There are multiple paragraphs defining requirements in -arch, e.g., >Sec. 4.4 on naming. Should these be moved to -req? A more general >question is on the dependency between -req and -arch. On one hand, it is >ideal to define -req first without a particular architecture to allow >competing/alternative architectures satisfying the requirements. On the >other hand, it appears that the -arch document contains content, in >parti cular, systems/function components, that can be helpful to better >understand the -req document. The current thinking is still to make -req >independent of -arch, and move some general requirements in -arch to >-req. Any comments? > >Q3: There are some good comments on reorganizing the -req documents. >Below is a new structure (second level section #'s and page numbers are >from the current -req so that others can see how we re-organize the >document). Any comments/feedback before we start the revision will be >greatly appreciated. > >Also, anyone who can help with direct revisions of the -req document >will be more than welcome! > >Thanks. > >-- >Richard > >1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 >2. Terminology and Concepts . . . . . . . . . . . . . . . . . . . 6 >3. System/Functional Components >4. Requirements Structure . . . . . . . . . . . . . . . . . . . . 7 > >5. Data Object Requirements > 4.5.1. Data Naming . . . . . . . . . . . . . . . . . . . . . .14 > Move part of Arch 4.4 to -req > 5.1. --Immutable Data . . . . . . . . . . . . . . . . . . . . 18 > 4.4.2. System Data Object Attributes . . . . . . . . . . . . .13 > 4.2.1. Data Object Size . . . . . . . . . . . . . . . . . 11 > 4.4.3. Time-to-live for Written Data Objects . . . . . . 13 > 4.4.4. Application-defined Properties and Metadata . . . . . 13 > >6. Access to Server Requirements > 4.3.1. Read/Write Own Storage . . . . . . . . . . . . . . .. 11 > 4.3.2. Read/Write by Remote Clients . . . . . . . . . . . . . 11 > 4.4.5. Offline Access . . . . . . . . . . . . . . . . . . . 14 > 4.1.1.1. NATs and Firewalls TRaversal . . .. . . . . . . . . 8 > Connections to Clients . . . . . . . . . . . . . . . . . . . 8 > 6.1.1. Support for Clients Behind NATs and Firewalls . . . 21 > 4.3.3. Negotiable Data Transport Protocol . . . . . . . . . . 12 > 5 .2. Explicit Deletion of Data . . . . . . . . . . . . . . . 19 > 5.3. Concurrent Write (Multiple writing). . . . . . . . . . . 19 > 5.4. Concurrent Read (Multiple reading) . . . . . . . . . . . 19 > 5.5. Read While Write . . . . . . . . . . . . . . . . . . . 19 > 5.6. Partial Write (Writing model) . . . . . . . . . . . . . 20 > 4.1.2.1. Secure Transport . . . . . . . . . . . . . . . . . . 8 > >7. Resource Control Requirements. . . . . . . . . . . . . . . . . 15 > 4.6.1. Multiple Applications . . . . . . . . . . . . . . . . 15 > 4.6.2. Per-Remote-Client, Per-Data Control . . . . . . . . . 15 > 4.6.3. Resource Control Set . . . . . . . . . . . . . . . . . 16 > 4.6.4. Server Involvement . . . . . . . . . . . . . . . . . . 16 > >8. Authorization Requirements > 4.7.1. Per-Remote-Client, Per-Data Read Access . . . . . . . 16 > 4.7.2. Per-User Write Access . . . . . . . . . . . . . . . . 17 > 4.7.3. Default Acce ss Permissions . . . . . . . . . . . . . . 17 > 4.7.4. Authorization Checks . . . . . . . . . . . . . . . . . 17 > 4.7.5. Cryptographic Credentials . . . . . . . . . . . . . . 17 > 4.7.6. Server Involvement . . . . . . . . . . . . . . . . . . 18 > 4.7.7. Protocol Reuse . . . . . . . . . . . . . . . . . . . . 18 > >9. Error and Failure Handling Requirements. . . . . . . . . . . . 9 > 4.1.3.2. Insufficient Resources . . . . . . . . . . . . . . . 9 > 4.1.3.1. Overload Condition . . . . . . . . . . . . . . . 9 > 4.1.3.3. Unavailable and Deleted Data . . . . . . . . . . . . 10 > 4.1.3.4. Insufficient Permissions . . . . . . . . . . . . . . 10 > 4.1.3.5. Redirection . . . . . . . . . . . . . . . . . . . . 10 > 4.1.2.2. Gaming Prevention . . . . . . . . . . . . . . . . . .8 > 4.4.1. Server reliability (Agnostic of reliability) . . . . . 12 > >10. Server Status Query Requirements . . . . . . . . . . . . . . . 18 > 5.7. Storage Status . . . . . . . . . . . . . . . . . . . . . 20 > .... > >11. Security Considerations . . . . . . . . . . . . . . . . . . . 21 > 7.1. Authentication and Authorization . . . . . . . . . . . . 21 > 7.2. Encrypted Data . . . . . . . . . . . . . . . . . . . . . 22 > 7.3. Protection against Gaming . . . . . . . . . . . . . . . 22 > > ------=_Part_228053_1101806223.1341210457132 Content-Type: text/html; charset=GBK Content-Transfer-Encoding: 7bit
Regards Q2:
 
To me, all subsections in -arch "4.  Architectural Principles" can be considered
as candidates, which can be carefully re-organized and moved to -req.
 
For example, similar content in "4.1.  Decoupled Control/Metadata and Data Planes
- Resource Scheduling Algorithms" has already appeared in problem statement doc
"3.3 Ineffective integration of P2P applications". If we want to repeat/emphasize
this information, the best place is -req.

At 2012-06-30 18:40:26,"Y. Richard Yang" <yry@cs.yale.edu> wrote: >Dear DECADE participants, > >Both -req and -arch documents have received extensive, excellent  >reviews. In the process of revising the documents and looking at the two  >documents, we have some questions to seek input from the participants: > >Q1. Both -req and -arch define some terms, including DECADE-compatible  >client, DECADE-compatible server, etc. This appears to be redundant.  >Should such terms be defined in -req or -arch? The current thinking is  >-req. Any comments? > >Q2. There are multiple paragraphs defining requirements in -arch, e.g.,  >Sec. 4.4 on naming. Should these be moved to -req? A more general  >question is on the dependency between -req and -arch. On one hand, it is  >ideal to define -req first without a particular architecture to allow  >competing/alternative architectures satisfying the requirements. On the  >other hand, it appears that the -arch document contains content, in  >particular, systems/function components, that can be helpful to better  >understand the -req document. The current thinking is still to make -req  >independent of -arch, and move some general requirements in -arch to  >-req. Any comments? > >Q3: There are some good comments on reorganizing the -req documents.  >Below is a new structure (second level section #'s and page numbers are  >from the current -req so that others can see how we re-organize the  >document). Any comments/feedback before we start the revision will be  >greatly appreciated. > >Also, anyone who can help with direct revisions of the -req document  >will be more than welcome! > >Thanks. > >--  >Richard > >1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  5 >2.  Terminology and Concepts . . . . . . . . . . . . . . . . . . .  6 >3.  System/Functional Components >4.  Requirements Structure . . . . . . . . . . . . . . . . . . . .  7 > >5.  Data Object Requirements >     4.5.1.  Data Naming . . . . . . . . . . . . . . . . . . . . . .14 >             Move part of Arch 4.4 to -req >     5.1.  --Immutable Data . . . . . . . . . . . . . . . . . . . . 18 >     4.4.2.  System Data Object Attributes . . . . . . . . . . . . .13 >         4.2.1.  Data Object Size . . . . . . . . . . . . . . . . . 11 >         4.4.3.  Time-to-live for Written Data Objects  . . . . . . 13 >     4.4.4.  Application-defined Properties and Metadata  . . . . . 13 > >6.  Access to Server Requirements >     4.3.1.  Read/Write Own Storage  . . . . . . . . . . . . . . .. 11 >     4.3.2.  Read/Write by Remote Clients . . . . . . . . . . . . . 11 >     4.4.5.  Offline Access  . . . . . . . . . . . . . . . .  . . . 14 >     4.1.1.1.  NATs and Firewalls TRaversal . . .. . .  . . . . . .  8 >       Connections to Clients . . . . . . . . . . . . . . . . . . .  8 >       6.1.1.  Support for Clients Behind NATs and Firewalls  . . . 21 >     4.3.3.  Negotiable Data Transport Protocol . . . . . . . . . . 12 >     5.2.  Explicit Deletion of Data  . . . . . . . . . . . . . . . 19 >     5.3.  Concurrent Write (Multiple writing). . . . . . . . . . . 19 >     5.4.  Concurrent Read (Multiple reading) . . . . . . . . . . . 19 >     5.5.  Read While Write . . . . . . . .   . . . . . . . . . . . 19 >     5.6.  Partial Write (Writing model) . . . . . . . . . . . . . 20 >     4.1.2.1.  Secure Transport . . . . . . . . . . . . . . . . . .  8 > >7.  Resource Control Requirements. . . . . . . . . . . . . . . . . 15 >     4.6.1.  Multiple Applications  . . . . . . . . . . . . . . . . 15 >     4.6.2.  Per-Remote-Client, Per-Data Control  . . . . . . . . . 15 >     4.6.3.  Resource Control Set . . . . . . . . . . . . . . . . . 16 >     4.6.4.  Server Involvement . . . . . . . . . . . . . . . . . . 16 > >8.  Authorization Requirements >     4.7.1.  Per-Remote-Client, Per-Data Read Access  . . . . . . . 16 >     4.7.2.  Per-User Write Access  . . . . . . . . . . . . . . . . 17 >     4.7.3.  Default Access Permissions . . . . . . . . . . . . . . 17 >     4.7.4.  Authorization Checks . . . . . . . . . . . . . . . . . 17 >     4.7.5.  Cryptographic Credentials  . . . . . . . . . . . . . . 17 >     4.7.6.  Server Involvement . . . . . . . . . . . . . . . . . . 18 >     4.7.7.  Protocol Reuse . . . . . . . . . . . . . . . . . . . . 18 > >9.  Error and Failure Handling Requirements. . . . . . . . . . . .  9 >     4.1.3.2.  Insufficient Resources . . . . . . . . . . . . . . .  9 >         4.1.3.1.  Overload Condition . . . . . . . . . . . . . . .  9 >     4.1.3.3.  Unavailable and Deleted Data . . . . . . . . . . . . 10 >     4.1.3.4.  Insufficient Permissions . . . . . . . . . . . . . . 10 >     4.1.3.5.  Redirection  . . . . . . . . . . . . . . . . . . . . 10 >     4.1.2.2.  Gaming Prevention  . . . . . . . . . . . . . . . . . .8 >     4.4.1.  Server reliability (Agnostic of reliability) . . . . . 12 > >10. Server Status Query Requirements . . . . . . . . . . . . . . . 18 >     5.7.  Storage Status . . . . . . . . . . . . . . . . . . . . . 20 >     .... > >11. Security Considerations  . . . . . . . . . . . . . . . . . . . 21 >     7.1.  Authentication and Authorization . . . . . . . . . . . . 21 >     7.2.  Encrypted Data . . . . . . . . . . . . . . . . . . . . . 22 >     7.3.  Protection against Gaming  . . . . . . . . . . . . . . . 22 > >


------=_Part_228053_1101806223.1341210457132-- From heavyxue@gmail.com Mon Jul 2 06:43:23 2012 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 7136421F85C2 for ; Mon, 2 Jul 2012 06:43:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 gNQ7neLY8fdg for ; Mon, 2 Jul 2012 06:43:22 -0700 (PDT) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1C23E21F85A2 for ; Mon, 2 Jul 2012 06:43:22 -0700 (PDT) Received: by ggnc4 with SMTP id c4so4552079ggn.31 for ; Mon, 02 Jul 2012 06:43:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=l3zeM1D339dUbkTyatxHuBxRlhHKRxp2N3Z6V18WTuU=; b=ZTrh86+Q/5IutoROJEoxwBykh0O3x4ourO19s5FC2brmJnx76+jU9tEjvx0rDrlQOg Y7zWOCk74oxuGJhdgrG3UmOeiP3ZJVKqUIVCCBwiLgfxzNWR7NwkF2fh9XQnavB73zqx FJYg+ZTauVJpd8JN044u8EjABFNMckuwxJAT/LjrvNF447YrEe/tF2swBJitEX6hg3gs eHrtJl88yVBAKSp8Lu3xg6RoUtfVnR0HMPjlMI4JDcsfMEKNOTzWezrh5FQvoqWl15np HJzUi9gMlg6rHXM3Md33H42zDKlCNYZ2Im9oOtdX5cCXQ6GaMNDhc8nHOeFaLjcjY8B6 d5UQ== Received: by 10.42.130.68 with SMTP id u4mr6162735ics.17.1341236606732; Mon, 02 Jul 2012 06:43:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.56.99 with HTTP; Mon, 2 Jul 2012 06:42:55 -0700 (PDT) In-Reply-To: <4FEED79A.1090906@cs.yale.edu> References: <4FEED79A.1090906@cs.yale.edu> From: Haiwei Xue Date: Mon, 2 Jul 2012 09:42:55 -0400 Message-ID: To: "Y. Richard Yang" Content-Type: multipart/alternative; boundary=90e6ba6134f4810ae804c3d8fbe7 Cc: "DECADE@ietf.org" Subject: Re: [decade] -req and -arch documents 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, 02 Jul 2012 13:43:23 -0000 --90e6ba6134f4810ae804c3d8fbe7 Content-Type: text/plain; charset=ISO-8859-1 Hi Richard, Here are some of my comments. Thanks. Haiwei On Sat, Jun 30, 2012 at 6:40 AM, Y. Richard Yang wrote: > Dear DECADE participants, > > Both -req and -arch documents have received extensive, excellent reviews. > In the process of revising the documents and looking at the two documents, > we have some questions to seek input from the participants: > > Q1. Both -req and -arch define some terms, including DECADE-compatible > client, DECADE-compatible server, etc. This appears to be redundant. Should > such terms be defined in -req or -arch? The current thinking is -req. Any > comments? > [Haiwei] 1. I think the current definition is good if we add some explanation in -arch, e.g. we can add a sentence in Sec. 2 (-arch) at the begin of definitions: some terms are already defined in '-req'. [Haiwei] 2. If you think it is still redundant, then you can remove the definition from -arch, and then reference the terms from -req. I agree with you to leave the def. in -req, because if let me choose the documents which I want to read first, I will choose -req. So -req should keep dependent. BTW, I like the style of terminology definition in -arch, because it is very clear in the "Table of Contents". > > Q2. There are multiple paragraphs defining requirements in -arch, e.g., > Sec. 4.4 on naming. Should these be moved to -req? A more general question > is on the dependency between -req and -arch. On one hand, it is ideal to > define -req first without a particular architecture to allow > competing/alternative architectures satisfying the requirements. On the > other hand, it appears that the -arch document contains content, in > particular, systems/function components, that can be helpful to better > understand the -req document. The current thinking is still to make -req > independent of -arch, and move some general requirements in -arch to -req. > Any comments? > [Haiwei] Point 1: If we leave the requirements on naming in -arch, would that broke the dependency of -req? I don't think so. [Haiwei] Point 2: In the -req you proposed the naming question, they are high level consideration, and in -arch based on the data-object oriented architecture and the design details you proposed some new requirements on naming. This sounds reasonable. And if you move those requirements from -arch to -req, it will let the readers confused: which documents should they read first. So I think the requirements on details should keep int -arch. > > Q3: There are some good comments on reorganizing the -req documents. Below > is a new structure (second level section #'s and page numbers are from the > current -req so that others can see how we re-organize the document). Any > comments/feedback before we start the revision will be greatly appreciated. > Also, anyone who can help with direct revisions of the -req document will > be more than welcome! > > Thanks. > > -- > Richard > > 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 > 2. Terminology and Concepts . . . . . . . . . . . . . . . . . . . 6 > 3. System/Functional Components > 4. Requirements Structure . . . . . . . . . . . . . . . . . . . . 7 > > 5. Data Object Requirements > 4.5.1. Data Naming . . . . . . . . . . . . . . . . . . . . . .14 > Move part of Arch 4.4 to -req > 5.1. --Immutable Data . . . . . . . . . . . . . . . . . . . . 18 > 4.4.2. System Data Object Attributes . . . . . . . . . . . . .13 > 4.2.1. Data Object Size . . . . . . . . . . . . . . . . . 11 > 4.4.3. Time-to-live for Written Data Objects . . . . . . 13 > 4.4.4. Application-defined Properties and Metadata . . . . . 13 > > 6. Access to Server Requirements > 4.3.1. Read/Write Own Storage . . . . . . . . . . . . . . .. 11 > 4.3.2. Read/Write by Remote Clients . . . . . . . . . . . . . 11 > 4.4.5. Offline Access . . . . . . . . . . . . . . . . . . . 14 > 4.1.1.1. NATs and Firewalls TRaversal . . .. . . . . . . . . 8 > Connections to Clients . . . . . . . . . . . . . . . . . . . 8 > 6.1.1. Support for Clients Behind NATs and Firewalls . . . 21 > 4.3.3. Negotiable Data Transport Protocol . . . . . . . . . . 12 > 5.2. Explicit Deletion of Data . . . . . . . . . . . . . . . 19 > 5.3. Concurrent Write (Multiple writing). . . . . . . . . . . 19 > 5.4. Concurrent Read (Multiple reading) . . . . . . . . . . . 19 > 5.5. Read While Write . . . . . . . . . . . . . . . . . . . 19 > 5.6. Partial Write (Writing model) . . . . . . . . . . . . . 20 > 4.1.2.1. Secure Transport . . . . . . . . . . . . . . . . . . 8 > > 7. Resource Control Requirements. . . . . . . . . . . . . . . . . 15 > 4.6.1. Multiple Applications . . . . . . . . . . . . . . . . 15 > 4.6.2. Per-Remote-Client, Per-Data Control . . . . . . . . . 15 > 4.6.3. Resource Control Set . . . . . . . . . . . . . . . . . 16 > 4.6.4. Server Involvement . . . . . . . . . . . . . . . . . . 16 > > 8. Authorization Requirements > 4.7.1. Per-Remote-Client, Per-Data Read Access . . . . . . . 16 > 4.7.2. Per-User Write Access . . . . . . . . . . . . . . . . 17 > 4.7.3. Default Access Permissions . . . . . . . . . . . . . . 17 > 4.7.4. Authorization Checks . . . . . . . . . . . . . . . . . 17 > 4.7.5. Cryptographic Credentials . . . . . . . . . . . . . . 17 > 4.7.6. Server Involvement . . . . . . . . . . . . . . . . . . 18 > 4.7.7. Protocol Reuse . . . . . . . . . . . . . . . . . . . . 18 > > 9. Error and Failure Handling Requirements. . . . . . . . . . . . 9 > 4.1.3.2. Insufficient Resources . . . . . . . . . . . . . . . 9 > 4.1.3.1. Overload Condition . . . . . . . . . . . . . . . 9 > 4.1.3.3. Unavailable and Deleted Data . . . . . . . . . . . . 10 > 4.1.3.4. Insufficient Permissions . . . . . . . . . . . . . . 10 > 4.1.3.5. Redirection . . . . . . . . . . . . . . . . . . . . 10 > 4.1.2.2. Gaming Prevention . . . . . . . . . . . . . . . . . .8 > 4.4.1. Server reliability (Agnostic of reliability) . . . . . 12 > > 10. Server Status Query Requirements . . . . . . . . . . . . . . . 18 > 5.7. Storage Status . . . . . . . . . . . . . . . . . . . . . 20 > .... > > 11. Security Considerations . . . . . . . . . . . . . . . . . . . 21 > 7.1. Authentication and Authorization . . . . . . . . . . . . 21 > 7.2. Encrypted Data . . . . . . . . . . . . . . . . . . . . . 22 > 7.3. Protection against Gaming . . . . . . . . . . . . . . . 22 > > > --90e6ba6134f4810ae804c3d8fbe7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Richard,

Here are some of my comments.

Thanks.=

Haiwei

On Sat, = Jun 30, 2012 at 6:40 AM, Y. Richard Yang <yry@cs.yale.edu> wro= te:
Dear DECADE participants,

Both -req and -arch documents have received extensive, excellent reviews. I= n the process of revising the documents and looking at the two documents, w= e have some questions to seek input from the participants:

Q1. Both -req and -arch define some terms, including DECADE-compatible clie= nt, DECADE-compatible server, etc. This appears to be redundant. Should suc= h terms be defined in -req or -arch? The current thinking is -req. Any comm= ents?

[Haiwei] 1. I think the current definition= is good if we add some explanation in -arch, e.g. we can add a=A0sentence = in Sec. 2 (-arch) at the begin of definitions: some terms are already defin= ed in '-req'.

[Haiwei] 2. If you think it is still=A0redundant, then = you can remove the definition from -arch, and then=A0reference the terms fr= om -req.=A0
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 I agree with you to l= eave the def. in -req, because if let me choose the documents which I want = to read first, I will choose -req. So -req=A0should keep dependent.

BTW, I like the style of terminology=A0definition in -a= rch, because it is very clear in the "Table of Contents".
=A0

Q2. There are multiple paragraphs defining requirements in -arch, e.g., Sec= . 4.4 on naming. Should these be moved to -req? A more general question is = on the dependency between -req and -arch. On one hand, it is ideal to defin= e -req first without a particular architecture to allow competing/alternati= ve architectures satisfying the requirements. On the other hand, it appears= that the -arch document contains content, in particular, systems/function = components, that can be helpful to better understand the -req document. The= current thinking is still to make -req independent of -arch, and move some= general requirements in -arch to -req. Any comments?

[Haiwei] Point 1: If we leave the=A0 requirements=A0on naming in -arch, would that broke the=A0dependency of -re= q? I don't think so.

[Haiwei] Point 2: In the = -req you proposed the naming question, they are high level consideration, a= nd in -arch based on the=A0data-object=A0oriented=A0architecture and the de= sign details you proposed some new=A0requirements on naming. This sounds=A0= reasonable. And if you move those=A0=A0requirements=A0 from -arch to -req, = it will let the readers confused: which documents should they read first.

So I think the=A0requirements=A0on details should keep = int -arch.
=A0

Q3: There are some good comments on reorganizing the -req documents. Below = is a new structure (second level section #'s and page numbers are from = the current -req so that others can see how we re-organize the document). A= ny comments/feedback before we start the revision will be greatly appreciat= ed.
=A0
Also, anyone who can help with direct revisions of the -req document will b= e more than welcome!

Thanks.

--
Richard

1. =A0Introduction . . . . . . . . . . . . . . . . . . . . . . . . . =A05 2. =A0Terminology and Concepts . . . . . . . . . . . . . . . . . . . =A06 3. =A0System/Functional Components
4. =A0Requirements Structure . . . . . . . . . . . . . . . . . . . . =A07
5. =A0Data Object Requirements
=A0 =A0 4.5.1. =A0Data Naming . . . . . . . . . . . . . . . . . . . . . .14=
=A0 =A0 =A0 =A0 =A0 =A0 Move part of Arch 4.4 to -req
=A0 =A0 5.1. =A0--Immutable Data . . . . . . . . . . . . . . . . . . . . 18=
=A0 =A0 4.4.2. =A0System Data Object Attributes . . . . . . . . . . . . .13=
=A0 =A0 =A0 =A0 4.2.1. =A0Data Object Size . . . . . . . . . . . . . . . . = . 11
=A0 =A0 =A0 =A0 4.4.3. =A0Time-to-live for Written Data Objects =A0. . . . = . . 13
=A0 =A0 4.4.4. =A0Application-defined Properties and Metadata =A0. . . . . = 13

6. =A0Access to Server Requirements
=A0 =A0 4.3.1. =A0Read/Write Own Storage =A0. . . . . . . . . . . . . . .. = 11
=A0 =A0 4.3.2. =A0Read/Write by Remote Clients . . . . . . . . . . . . . 11=
=A0 =A0 4.4.5. =A0Offline Access =A0. . . . . . . . . . . . . . . . =A0. . = . 14
=A0 =A0 4.1.1.1. =A0NATs and Firewalls TRaversal . . .. . . =A0. . . . . . = =A08
=A0 =A0 =A0 Connections to Clients . . . . . . . . . . . . . . . . . . . = =A08
=A0 =A0 =A0 6.1.1. =A0Support for Clients Behind NATs and Firewalls =A0. . = . 21
=A0 =A0 4.3.3. =A0Negotiable Data Transport Protocol . . . . . . . . . . 12=
=A0 =A0 5.2. =A0Explicit Deletion of Data =A0. . . . . . . . . . . . . . . = 19
=A0 =A0 5.3. =A0Concurrent Write (Multiple writing). . . . . . . . . . . 19=
=A0 =A0 5.4. =A0Concurrent Read (Multiple reading) . . . . . . . . . . . 19=
=A0 =A0 5.5. =A0Read While Write . . . . . . . . =A0 . . . . . . . . . . . = 19
=A0 =A0 5.6. =A0Partial Write (Writing model) . . . . . . . . . . . . . 20<= br> =A0 =A0 4.1.2.1. =A0Secure Transport . . . . . . . . . . . . . . . . . . = =A08

7. =A0Resource Control Requirements. . . . . . . . . . . . . . . . . 15
=A0 =A0 4.6.1. =A0Multiple Applications =A0. . . . . . . . . . . . . . . . = 15
=A0 =A0 4.6.2. =A0Per-Remote-Client, Per-Data Control =A0. . . . . . . . . = 15
=A0 =A0 4.6.3. =A0Resource Control Set . . . . . . . . . . . . . . . . . 16=
=A0 =A0 4.6.4. =A0Server Involvement . . . . . . . . . . . . . . . . . . 16=

8. =A0Authorization Requirements
=A0 =A0 4.7.1. =A0Per-Remote-Client, Per-Data Read Access =A0. . . . . . . = 16
=A0 =A0 4.7.2. =A0Per-User Write Access =A0. . . . . . . . . . . . . . . . = 17
=A0 =A0 4.7.3. =A0Default Access Permissions . . . . . . . . . . . . . . 17=
=A0 =A0 4.7.4. =A0Authorization Checks . . . . . . . . . . . . . . . . . 17=
=A0 =A0 4.7.5. =A0Cryptographic Credentials =A0. . . . . . . . . . . . . . = 17
=A0 =A0 4.7.6. =A0Server Involvement . . . . . . . . . . . . . . . . . . 18=
=A0 =A0 4.7.7. =A0Protocol Reuse . . . . . . . . . . . . . . . . . . . . 18=

9. =A0Error and Failure Handling Requirements. . . . . . . . . . . . =A09 =A0 =A0 4.1.3.2. =A0Insufficient Resources . . . . . . . . . . . . . . . = =A09
=A0 =A0 =A0 =A0 4.1.3.1. =A0Overload Condition . . . . . . . . . . . . . . = . =A09
=A0 =A0 4.1.3.3. =A0Unavailable and Deleted Data . . . . . . . . . . . . 10=
=A0 =A0 4.1.3.4. =A0Insufficient Permissions . . . . . . . . . . . . . . 10=
=A0 =A0 4.1.3.5. =A0Redirection =A0. . . . . . . . . . . . . . . . . . . . = 10
=A0 =A0 4.1.2.2. =A0Gaming Prevention =A0. . . . . . . . . . . . . . . . . = .8
=A0 =A0 4.4.1. =A0Server reliability (Agnostic of reliability) . . . . . 12=

10. Server Status Query Requirements . . . . . . . . . . . . . . . 18
=A0 =A0 5.7. =A0Storage Status . . . . . . . . . . . . . . . . . . . . . 20=
=A0 =A0 ....

11. Security Considerations =A0. . . . . . . . . . . . . . . . . . . 21
=A0 =A0 7.1. =A0Authentication and Authorization . . . . . . . . . . . . 21=
=A0 =A0 7.2. =A0Encrypted Data . . . . . . . . . . . . . . . . . . . . . 22=
=A0 =A0 7.3. =A0Protection against Gaming =A0. . . . . . . . . . . . . . . = 22



--90e6ba6134f4810ae804c3d8fbe7-- From yang.r.yang@gmail.com Mon Jul 2 07:11:14 2012 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 79D5021F861B for ; Mon, 2 Jul 2012 07:11:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.938 X-Spam-Level: X-Spam-Status: No, score=-2.938 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 eZcXynGIihUz for ; Mon, 2 Jul 2012 07:11:12 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id B0E7F21F8530 for ; Mon, 2 Jul 2012 07:11:12 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so9604459obb.31 for ; Mon, 02 Jul 2012 07:11:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=gSj5oxbPwmQaM/x+o0ktMg6PkXCys2qM6JVI2TfNFCk=; b=Dlb+lvn7juraGe0nCdOMeQnISGuKyDXe3gDvbigQd7DVrv9P3G3Th+HA2fhAIQXdPK QxQXHPdrGs6QObMweljcLhh8IuuJsRt/BeWBnzgMaMVTXQ8n3cSXES2whq9TDWHe2z6a 9PSr9mtpaokczkB203c3qCtB9GkzhEBZWbDM/t4EyTQFWazXvV0/CPZB4z2eKXF8K7kM rlhMi1JTA6ffe16jeu6zbIMi7xzicRBQsHbvwkUE4VQ30LgN03tXgjh04mL6mYDNigbC dyyJqbv5y+s8YUSoRLH10HjOttL/Tj8bnBSQxZBe9smApHu1kPR4D+8akR6N3KCGWqW9 VNnQ== MIME-Version: 1.0 Received: by 10.182.231.6 with SMTP id tc6mr8385521obc.63.1341238277438; Mon, 02 Jul 2012 07:11:17 -0700 (PDT) Sender: yang.r.yang@gmail.com Received: by 10.76.86.136 with HTTP; Mon, 2 Jul 2012 07:11:17 -0700 (PDT) In-Reply-To: <2012070201013396821769@gmail.com> References: <4FEED79A.1090906@cs.yale.edu> <2012070201013396821769@gmail.com> Date: Mon, 2 Jul 2012 22:11:17 +0800 X-Google-Sender-Auth: ZxAxIZHkXevTjzyphnPGXaSSrCk Message-ID: From: "Y. Richard Yang" To: "pzhang.thu" Content-Type: multipart/alternative; boundary=f46d0446312c15fd2704c3d95f40 Cc: "DECADE@ietf.org" Subject: Re: [decade] -req and -arch documents 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, 02 Jul 2012 14:11:14 -0000 --f46d0446312c15fd2704c3d95f40 Content-Type: text/plain; charset=ISO-8859-1 Hi Peng, Thanks a lot for the feedback! Please see below. On Monday, July 2, 2012, Zhang Peng wrote: > ** > Hi Richard, > > Thanks for your effort. Here are some suggestion about the revision of > -req documents. > > First, regarding Q1, I think there are indeed some overlaps on term > definitions in -req and -arch documents. In addition, they are even not > consistent. I think we can just put them in the -req document, and give a > pointer in -arch document. > Good to see your point. I am wondering what the other authors think? > Regarding Q2, I agree that in -arch, there are some paragraphs that also > do the job of define requirements, and may better be put in -req. For > naming, the reqiin -requirements given in -req are rather simplistic, and > we can move the move the detailed requirements to -req. But for "immutable > object", I think it is more like a design option for the architecture (so > that the design would be much simplified), rather than a system > requirements for DECADE to function. Thus, I suggest we don't move the > immutable data objects in -arch to -req, and we can even delete them in > -req. Finally, I would say that there is no clear cut for requirement and > architecture, since when we specify the requirements, we have some design > rationale in mind; and when we design the architecture, we would find more > clear requirements for the specific design. It is not easy to fully > decouple them. > I tend to agree on your proposed split: naming reqs in -arch to -req; immutable keeps in -arch. It appears that you think immutable PBS should not at all be in -req. Introducing immutable objects was an assumption to simplify potential design. So it is not a req but a design point. I tend to agree but want to see if others have a different opinion. Regarding Q3, I think the new outline of the -req document seems better, > but I think it is better to organize it into three parts: > access/authorization, resource control, data storage/transfer, failure > handling/gaming prevention. The rationale is that the first part is about > how client access the server, the second part corresponds to DRP, the third > part corresponds to SDT, and the last two parts are about > reliability/security. The following is the outline in my mind. I would like > to discuss with you about the organization further. And I would like to > help revise the -req document. Thanks. > > Sounds interesting. Could you please give a more detailed list on the outline? Thanks a lot! Richard > Best, > > Peng. > > 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 > 2. Terminology and Concepts . . . . . . . . . . . . . . . . . . . 6 > 3. System/Functional Components > 4. Requirements Structure . . . . . . . . . . . . . . . . . . . . 7 > > 5. Data Object Requirements > 4.5.1. Data Naming . . . . . . . . . . . . . . . . . . . . . .14 > Move part of Arch 4.4 to -req > 4.2.1. Data Object Size . . . . . . . . . . . . . . . . . 11 > 4.4.2. System Data Object Attributes . . . . . . . . . . . . .13 > 4.4.3. Time-to-live for Written Data Objects . . . . . . 13 > 4.4.4. Application-defined Properties and Metadata . . . . . 13 > > 6. Authentication and Access Requirements > 4.7.1. Per-Remote-Client, Per-Data Read Access . . . . . . . 16 > 4.7.2. Per-User Write Access . . . . . . . . . . . . . . . . 17 > 4.7.3. Default Access Permissions . . . . . . . . . . . . . . 17 > 4.7.4. Authorization Checks . . . . . . . . . . . . . . . . . 17 > 4.7.5. Cryptographic Credentials . . . . . . . . . . . . . . 17 > 4.7.6. Server Involvement . . . . . . . . . . . . . . . . . . 18 > 4.7.7. Protocol Reuse . . . . . . . . . . . . . . . . . . . . 18 > 4.3.1. Read/Write Own Storage . . . . . . . . . . . . . . .. 11 > 4.3.2. Read/Write by Remote Clients . . . . . . . . . . . . . 11 > 4.4.5. Offline Access . . . . . . . . . . . . . . . . . . . 14 > > 7. Data Transfer Requirements > 4.1.1.1. NATs and Firewalls TRaversal . . .. . . . . . . . . 8 > Connections to Clients . . . . . . . . . . . . . . . . . . . 8 > 6.1.1. Support for Clients Behind NATs and Firewalls . . . 21 > 4.3.3. Negotiable Data Transport Protocol . . . . . . . . . . 12 > 4.1.2.1. Secure Transport . . . . . . . . . . . . . . . . . . 8 > > 8. Resource Control Requirements. . . . . . . . . . . . . . . . . 15 > 4.6.1. Multiple Applications . . . . . . . . . . . . . . . . 15 > 4.6.2. Per-Remote-Client, Per-Data Control . . . . . . . . . 15 > 4.6.3. Resource Control Set . . . . . . . . . . . . . . . . . 16 > 4.6.4. Server Involvement . . . . . . . . . . . . . . . . . . 16 > 8. Authorization Requirements > > 9. Error and Failure Handling Requirements. . . . . . . . . . . . 9 > 4.1.3.2. Insufficient Resources . . . . . . . . . . . . . . . 9 > 4.1.3.1. Overload Condition . . . . . . . . . . . . . . . 9 > 4.1.3.3. Unavailable and Deleted Data . . . . . . . . . . . . 10 > 4.1.3.4. Insufficient Permissions . . . . . . . . . . . . . . 10 > 4.1.3.5. Redirection . . . . . . . . . . . . . . . . . . . . 10 > 4.1.2.2. Gaming Prevention . . . . . . . . . . . . . . . . . .8 > 4.4.1. Server reliability (Agnostic of reliability) . . . . . 12 > > 10. Server Status Query Requirements . . . . . . . . . . . . . . . 18 > 5.7. Storage Status . . . . . . . . . . . . . . . . . . . . . 20 > .... > > 11. Security Considerations . . . . . . . . . . . . . . . . . . . 21 > 7.1. Authentication and Authorization . . . . . . . . . . . . 21 > 7.2. Encrypted Data . . . . . . . . . . . . . . . . . . . . . 22 > 7.3. Protection against Gaming . . . . . . . . . . . . . . . 22 > > ------------------------------ > Zhang Peng > > *From:* Y. Richard Yang > *Date:* 2012-06-30 06:40 > *To:* DECADE@ietf.org > *Subject:* [decade] -req and -arch documents > Dear DECADE participants, > > Both -req and -arch documents have received extensive, excellent > reviews. In the process of revising the documents and looking at the two > documents, we have some questions to seek input from the participants: > > Q1. Both -req and -arch define some terms, including DECADE-compatible > client, DECADE-compatible server, etc. This appears to be redundant. > Should such terms be defined in -req or -arch? The current thinking is > -req. Any comments? > > Q2. There are multiple paragraphs defining requirements in -arch, e.g., > Sec. 4.4 on naming. Should these be moved to -req? A more general > question is on the dependency between -req and -arch. On one hand, it is > ideal to define -req first without a particular architecture to allow > competing/alternative architectures satisfying the requirements. On the > other hand, it appears that the -arch document contains content, in > particular, systems/function components, that can be helpful to better > understand the -req document. The current thinking is still to make -req > independent of -arch, and move some general requirements in -arch to > -req. Any comments? > > Q3: There are some good comments on reorganizing the -req documents. > Below is a new structure (second level section #'s and page numbers are > from the current -req so that others can see how we re-organize the > document). Any comments/feedback before we start the revision will be > greatly appreciated. > > Also, anyone who can help with direct revisions of the -req document > will be more than welcome! > > Thanks. > > -- > Richard > > 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 > 2. Terminology and Concepts . . . . . . . . . . . . . . . . . . . 6 > 3. System/Functional Components > 4. Requirements Structure . . . . . . . . . . . . . . . . . . . . 7 > > 5. Data Object Requirements > 4.5.1. Data Naming . . . . . . . . . . . . . . . . . . . . . .14 > Move part of Arch 4.4 to -req > 5.1. --Immutable Data . . . . . . . . . . . . . . . . . . . . 18 > 4.4.2. System Data Object Attributes . . . . . . . . . . . . .13 > 4.2.1. Data Object Size . . . . . . . . . . . . . . . . . 11 > 4.4.3. Time-to-live for Written Data Objects . . . . . . 13 > 4.4.4. Application-defined Properties and Metadata . . . . . 13 > > 6. Access to Server Requirements > 4.3.1. Read/Write Own Storage . . . . . . . . . . . . . . .. 11 > 4.3.2. Read/Write by Remote Clients . . . . . . . . . . . . . 11 > 4.4.5. Offline Access . . . . . . . . . . . . . . . . . . . 14 > 4.1.1.1. NATs and Firewalls TRaversal . . .. . . . . . . . . 8 > Connections to Clients . . . . . . . . . . . . . . . . . . . 8 > 6.1.1. Support for Clients Behind NATs and Firewalls . . . 21 > 4.3.3. Negotiable Data Transport Protocol . . . . . . . . . . 12 > 5.2. Explicit Deletion of Data . . . . . . . . . . . . . . . 19 > 5.3. Concurrent Write (Multiple writing). . . . . . . . . . . 19 > 5.4. Concurrent Read (Multiple reading) . . . . . . . . . . . 19 > 5.5. Read While Write . . . . . . . . . . . . . . . . . . . 19 > 5.6. Partial Write (Writing model) . . . . . . . . . . . . . 20 > 4.1.2.1. Secure Transport . . . . . . . . . . . . . . . . . . 8 > > 7. Resource Control Requirements. . . . . . . . . . . . . . . . . 15 > 4.6.1. Multiple Applications . . . . . . . . . . . . . . . . 15 > 4.6.2. Per-Remote-Client, Per-Data Control . . . . . . . . . 15 > 4.6.3. Resource Control Set . . . . . . . . . . . . . . . . . 16 > 4.6.4. Server Involvement . . . . . . . . . . . . . . . . . . 16 > > 8. Authorization Requirements > 4.7.1. Per-Remote-Client, Per-Data Read Access . . . . . . . 16 > 4.7.2. Per-User Write Access . . . . . . . . . . . . . . > --f46d0446312c15fd2704c3d95f40 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Peng,

Thanks a lot for the feedback! Please see below= .

On Monday, July 2, 2012, Zhang Peng wrote:
Hi Richard,
=A0
Thanks for your effort. Here are some sugges= tion=20 about the revision of -req documents.
=A0
First, regarding Q1, I think there are indee= d some=20 overlaps on term definitions=A0in -req and -arch documents. In addition, th= ey=20 are even not consistent. I think we can just put them in the -req document,= and=20 give a pointer in -arch document.

<= div>Good to see your point. I am wondering what the other authors think?
=A0
Regarding Q2, I agree that in -arch, there a= re=20 some paragraphs that also do the job of define requirements, and may better= be=20 put in -req. For naming, the reqiin -requirements given in -req=A0are rathe= r=20 simplistic, and we can move the move the detailed requirements to -req.=A0B= ut=20 for "immutable object", I think it is more like a design option f= or the=20 architecture (so that the design would be much simplified), rather than a s= ystem=20 requirements for DECADE to function.=A0 Thus, I suggest we don't move t= he=20 immutable data objects in -arch to -req, and we can even delete them in -re= q.=20 Finally, I would say that there is no clear cut for requirement and=20 architecture, since when we specify the requirements, we have some design= =20 rationale in mind; and when we design the architecture, we would find more = clear=20 requirements for the specific design. It is not easy to fully decouple=20 them.

I tend to agree on your p= roposed split: naming reqs in -arch to -req; immutable keeps in -arch. It a= ppears that you think immutable PBS should not at all be in -req. =A0Introd= ucing immutable objects was an assumption to simplify potential design. So = it is not a req but a design point. I tend to agree but want to see if othe= rs have a different opinion.

Regarding Q3, I think the new outline of the= -req=20 document seems better, but I think it is better to organize it into three p= arts:=20 access/authorization, resource control, data storage/transfer, failure=20 handling/gaming prevention. The rationale is that the first part is about h= ow=20 client access the server, the second part corresponds to DRP, the third par= t=20 corresponds to SDT, and the last two parts are about reliability/security. = The=20 following is the outline in my mind. I would like to discuss with you about= the=20 organization further. And I would like to help revise the -req document.=A0= =20 Thanks.
=A0

<= div>Sounds interesting. Could you please give a more detailed list on the o= utline?

Thanks a lot!

Ric= hard
=A0
Best,
=A0
Peng.
=A0
1. Introduction . . . . . . . . . . . . . .= . . .=20 . . . . . . . . 5
2. Terminology and Concepts . . . . . . . .= . . .=20 . . . . . . . . 6
3. System/Functional Components
4. Requirements Structure . . . . . . . . .= . . .=20 . . . . . . . . 7
=A0
5. Data Object Requirements
4.5.1. Data Naming . . . . . . . . . . . . . . . . . . . . . .14
Move part of Arch 4.4 to -req
4.2.1. Data Object Size . . . . . . . . . . . . . . . . . 11
4.4.2. System Data Object Attributes . . . . . . . . . . . . .13
4.4.3. Time-to-live for Written Data Objects . . . . . . 13
4.4.4. Application-defined Properties and Metadata . . . . . 13
=A0
6. Authentication and Access Requirements
4.7.1. Per-Remote-Client, Per-Data Read Access . . . . . . . 16
4.7.2. Per-User Write Access . . . . . . . . . . . . . . . . 17
4.7.3. Default Access Permissions . . . . . . . . . . . . . . 17
4.7.4. Authorization Checks . . . . . . . . . . . . . . . . . 17
4.7.5. Cryptographic Credentials . . . . . . . . . . . . . . 17
4.7.6. Server Involvement . . . . . . . . . . . . . . . . . . 18
4.7.7. Protocol Reuse . . . . . . . . . . . . . . . . . . . .=20 18
4.3.1. Read/Write Own Storage . . . . . . . . . . . . . . .. 11
4.3.2. Read/Write by Remote Clients . . . . . . . . . . . . . 11
4.4.5. Offline Access . . . . . . . . . . . . . . . . . . . 14
=A0
7. Data Transfer Requirements=A0
4.1.1.1. NATs and Firewalls TRaversal . . .. . . . . . . . . 8
Connections to Clients . . . . . . . . . . . . . . . . . . . 8
6.1.1. Support for Clients Behind NATs and Firewalls . . . 21
4.3.3. Negotiable Data Transport Protocol . . . . . . . . . . 12
4.1.2.1. Secure Transport . . . . . . . . . . . . . . . . . . 8
=A0
8. Resource Control Requirements. . . . . .= . . .=20 . . . . . . . . 15
4.6.1. Multiple Applications . . . . . . . . . . . . . . . . 15
4.6.2. Per-Remote-Client, Per-Data Control . . . . . . . . . 15
4.6.3. Resource Control Set . . . . . . . . . . . . . . . . . 16
4.6.4. Server Involvement . . . . . . . . . . . . . . . . . . 16
8. Authorization Requirements
=A0
9. Error and Failure Handling Requirements.= . . .=20 . . . . . . . . 9
4.1.3.2. Insufficient Resources . . . . . . . . . . . . . . . 9
4.1.3.1. Overload Condition . . . . . . . . . . . . . . . 9
4.1.3.3. Unavailable and Deleted Data . . . . . . . . . . . . 10
4.1.3.4. Insufficient Permissions . . . . . . . . . . . . . . 10
4.1.3.5. Redirection . . . . . . . . . . . . . . . . . . . . 10
4.1.2.2. Gaming Prevention . . . . . . . . . . . . . . . . . .8
4.4.1. Server reliability (Agnostic of reliability) . . . . . 12
=A0
10. Server Status Query Requirements . . . = . . .=20 . . . . . . . . . 18
5.7. Storage Status . . . . . . . . . . . . . . . . . . . . . 20
....
=A0
11. Security Considerations . . . . . . . .= . . .=20 . . . . . . . . 21
7.1. Authentication and Authorization . . . . . . . . . . . . 21
7.2. Encrypted Data . . . . . . . . . . . . . . . . . . . . . 22
7.3. Protection against Gaming . . . . . . . . . . . . . . . 22
<= /div>
=A0
Zhang Peng
=A0
Date:=A02012-06-30=A006:40
Subject:=A0[decade] -req and -arch documents
Dear=A0DECADE=A0participants,
=A0
Both=A0-req=A0and=A0-arch=A0documents=A0have=A0received=A0extensive,= =A0excellent=A0
reviews.=A0In=A0the=A0process=A0of=A0revising=A0the=A0documents=A0and= =A0looking=A0at=A0the=A0two=A0
documents,=A0we=A0have=A0some=A0questions=A0to=A0seek=A0input=A0from= =A0the=A0participants:
=A0
Q1.=A0Both=A0-req=A0and=A0-arch=A0define=A0some=A0terms,=A0including= =A0DECADE-compatible=A0
client,=A0DECADE-compatible=A0server,=A0etc.=A0This=A0appears=A0to=A0b= e=A0redundant.=A0
Should=A0such=A0terms=A0be=A0defined=A0in=A0-req=A0or=A0-arch?=A0The= =A0current=A0thinking=A0is=A0
-req.=A0Any=A0comments?
=A0
Q2.=A0There=A0are=A0multiple=A0paragraphs=A0defining=A0requirements=A0= in=A0-arch,=A0e.g.,=A0
Sec.=A04.4=A0on=A0naming.=A0Should=A0these=A0be=A0moved=A0to=A0-req?= =A0A=A0more=A0general=A0
question=A0is=A0on=A0the=A0dependency=A0between=A0-req=A0and=A0-arch.= =A0On=A0one=A0hand,=A0it=A0is=A0
ideal=A0to=A0define=A0-req=A0first=A0without=A0a=A0particular=A0archit= ecture=A0to=A0allow=A0
competing/alternative=A0architectures=A0satisfying=A0the=A0requirement= s.=A0On=A0the=A0
other=A0hand,=A0it=A0appears=A0that=A0the=A0-arch=A0document=A0contain= s=A0content,=A0in=A0
particular,=A0systems/function=A0components,=A0that=A0can=A0be=A0helpf= ul=A0to=A0better=A0
understand=A0the=A0-req=A0document.=A0The=A0current=A0thinking=A0is=A0= still=A0to=A0make=A0-req=A0
independent=A0of=A0-arch,=A0and=A0move=A0some=A0general=A0requirements= =A0in=A0-arch=A0to=A0
-req.=A0Any=A0comments?
=A0
Q3:=A0There=A0are=A0some=A0good=A0comments=A0on=A0reorganizing=A0the= =A0-req=A0documents.=A0
Below=A0is=A0a=A0new=A0structure=A0(second=A0level=A0section=A0#'s= =A0and=A0page=A0numbers=A0are=A0
from=A0the=A0current=A0-req=A0so=A0that=A0others=A0can=A0see=A0how=A0w= e=A0re-organize=A0the=A0
document).=A0Any=A0comments/feedback=A0before=A0we=A0start=A0the=A0rev= ision=A0will=A0be=A0
greatly=A0appreciated.
=A0
Also,=A0anyone=A0who=A0can=A0help=A0with=A0direct=A0revisions=A0of=A0t= he=A0-req=A0document=A0
will=A0be=A0more=A0than=A0welcome!
=A0
Thanks.
=A0
--=A0
Richard
=A0
1.=A0=A0Introduction=A0.=A0.=A0.=A0.=A0.=A0.=A0.=A0.=A0.=A0.=A0.=A0.= =A0.=A0.=A0.=A0.=A0.=A0.=A0.=A0.=A0.=A0.=A0.=A0.=A0.=A0=A05
2.=A0=A0Terminology=A0and=A0Concepts=A0.=A0.=A0.=A0.=A0.=A0.=A0.=A0.= =A0.=A0.=A0.=A0.=A0.=A0.=A0.=A0.=A0.=A0.=A0.=A0=A06
3.=A0=A0System/Functional=A0Components
4.=A0=A0Requirements=A0Structure=A0.=A0.=A0.=A0.=A0.=A0.=A0.=A0.=A0.= =A0.=A0.=A0.=A0.=A0.=A0.=A0.=A0.=A0.=A0.=A0.=A0=A07
=A0
5.=A0=A0Data=A0Object=A0Requirements
=A0=A0=A0=A0=A04.5.1.=A0=A0Data=A0Naming=A0.=A0.=A0.=A0.=A0.=A0.=A0.= =A0.=A0.=A0.=A0.=A0.=A0.=A0.=A0.=A0.=A0.=A0.=A0.=A0.=A0.=A0.14
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0Move=A0part=A0of=A0Arch=A04.4= =A0to=A0-req
=A0=A0=A0=A0=A05.1.=A0=A0--Immutable=A0Data=A0.=A0.=A0.=A0.=A0.=A0.=A0= .=A0.=A0.=A0.=A0.=A0.=A0.=A0.=A0.=A0.=A0.=A0.=A0.=A0.=A018
=A0=A0=A0=A0=A04.4.2.=A0=A0System=A0Data=A0Object=A0Attributes=A0.=A0.= =A0.=A0.=A0.=A0.=A0.=A0.=A0.=A0.=A0.=A0.=A0.13
=A0=A0=A0=A0=A0=A0=A0=A0=A04.2.1.=A0=A0Data=A0Object=A0Size=A0.=A0.=A0= .=A0.=A0.=A0.=A0.=A0.=A0.=A0.=A0.=A0.=A0.=A0.=A0.=A0.=A0.=A011
=A0=A0=A0=A0=A0=A0=A0=A0=A04.4.3.=A0=A0Time-to-live=A0for=A0Written=A0= Data=A0Objects=A0=A0.=A0.=A0.=A0.=A0.=A0.=A013
=A0=A0=A0=A0=A04.4.4.=A0=A0Application-defined=A0Properties=A0and=A0Me= tadata=A0=A0.=A0.=A0.=A0.=A0.=A013
=A0
6.=A0=A0Access=A0to=A0Server=A0Requirements
=A0=A0=A0=A0=A04.3.1.=A0=A0Read/Write=A0Own=A0Storage=A0=A0.=A0.=A0.= =A0.=A0.=A0.=A0.=A0.=A0.=A0.=A0.=A0.=A0.=A0.=A0..=A011
=A0=A0=A0=A0=A04.3.2.=A0=A0Read/Write=A0by=A0Remote=A0Clients=A0.=A0.= =A0.=A0.=A0.=A0.=A0.=A0.=A0.=A0.=A0.=A0.=A0.=A011
=A0=A0=A0=A0=A04.4.5.=A0=A0Offline=A0Access=A0=A0.=A0.=A0.=A0.=A0.=A0.= =A0.=A0.=A0.=A0.=A0.=A0.=A0.=A0.=A0.=A0.=A0=A0.=A0.=A0.=A014
=A0=A0=A0=A0=A04.1.1.1.=A0=A0NATs=A0and=A0Firewalls=A0TRaversal=A0.=A0= .=A0..=A0.=A0.=A0=A0.=A0.=A0.=A0.=A0.=A0.=A0=A08
=A0=A0=A0=A0=A0=A0=A0Connections=A0to=A0Clients=A0.=A0.=A0.=A0.=A0.=A0= .=A0.=A0.=A0.=A0.=A0.=A0.=A0.=A0.=A0.=A0.=A0.=A0.=A0.=A0=A08
=A0=A0=A0=A0=A0=A0=A06.1.1.=A0=A0Support=A0for=A0Clients=A0Behind=A0NA= Ts=A0and=A0Firewalls=A0=A0.=A0.=A0.=A021
=A0=A0=A0=A0=A04.3.3.=A0=A0Negotiable=A0Data=A0Transport=A0Protocol=A0= .=A0.=A0.=A0.=A0.=A0.=A0.=A0.=A0.=A0.=A012
=A0=A0=A0=A0=A05.2.=A0=A0Explicit=A0Deletion=A0of=A0Data=A0=A0.=A0.=A0= .=A0.=A0.=A0.=A0.=A0.=A0.=A0.=A0.=A0.=A0.=A0.=A0.=A019
=A0=A0=A0=A0=A05.3.=A0=A0Concurrent=A0Write=A0(Multiple=A0writing).=A0= .=A0.=A0.=A0.=A0.=A0.=A0.=A0.=A0.=A0.=A019
=A0=A0=A0=A0=A05.4.=A0=A0Concurrent=A0Read=A0(Multiple=A0reading)=A0.= =A0.=A0.=A0.=A0.=A0.=A0.=A0.=A0.=A0.=A0.=A019
=A0=A0=A0=A0=A05.5.=A0=A0Read=A0While=A0Write=A0.=A0.=A0.=A0.=A0.=A0.= =A0.=A0.=A0=A0=A0.=A0.=A0.=A0.=A0.=A0.=A0.=A0.=A0.=A0.=A0.=A019
=A0=A0=A0=A0=A05.6.=A0=A0Partial=A0Write=A0(Writing=A0model)=A0.=A0.= =A0.=A0.=A0.=A0.=A0.=A0.=A0.=A0.=A0.=A0.=A0.=A020
=A0=A0=A0=A0=A04.1.2.1.=A0=A0Secure=A0Transport=A0.=A0.=A0.=A0.=A0.=A0= .=A0.=A0.=A0.=A0.=A0.=A0.=A0.=A0.=A0.=A0.=A0.=A0.=A0=A08
=A0
7.=A0=A0Resource=A0Control=A0Requirements.=A0.=A0.=A0.=A0.=A0.=A0.=A0.= =A0.=A0.=A0.=A0.=A0.=A0.=A0.=A0.=A0.=A015
=A0=A0=A0=A0=A04.6.1.=A0=A0Multiple=A0Applications=A0=A0.=A0.=A0.=A0.= =A0.=A0.=A0.=A0.=A0.=A0.=A0.=A0.=A0.=A0.=A0.=A0.=A015
=A0=A0=A0=A0=A04.6.2.=A0=A0Per-Remote-Client,=A0Per-Data=A0Control=A0= =A0.=A0.=A0.=A0.=A0.=A0.=A0.=A0.=A0.=A015
=A0=A0=A0=A0=A04.6.3.=A0=A0Resource=A0Control=A0Set=A0.=A0.=A0.=A0.=A0= .=A0.=A0.=A0.=A0.=A0.=A0.=A0.=A0.=A0.=A0.=A0.=A0.=A016
=A0=A0=A0=A0=A04.6.4.=A0=A0Server=A0Involvement=A0.=A0.=A0.=A0.=A0.=A0= .=A0.=A0.=A0.=A0.=A0.=A0.=A0.=A0.=A0.=A0.=A0.=A0.=A016
=A0
8.=A0=A0Authorization=A0Requirements
=A0=A0=A0=A0=A04.7.1.=A0=A0Per-Remote-Client,=A0Per-Data=A0Read=A0Acce= ss=A0=A0.=A0.=A0.=A0.=A0.=A0.=A0.=A016
=A0=A0=A0=A0=A04.7.2.=A0=A0Per-User=A0Write=A0Access=A0=A0.=A0.=A0.=A0= .=A0.=A0.=A0.=A0.=A0.=A0.=A0.=A0.=A0.=A0.=A0
--f46d0446312c15fd2704c3d95f40-- From yang.r.yang@gmail.com Mon Jul 2 07:16:18 2012 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 7398C21F859E for ; Mon, 2 Jul 2012 07:16:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.071 X-Spam-Level: X-Spam-Status: No, score=-2.071 tagged_above=-999 required=5 tests=[AWL=-0.848, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, 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 zLwJxDxOZePl for ; Mon, 2 Jul 2012 07:16:17 -0700 (PDT) Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id 4BA3121F8636 for ; Mon, 2 Jul 2012 07:16:17 -0700 (PDT) Received: by qaea16 with SMTP id a16so1873030qae.10 for ; Mon, 02 Jul 2012 07:16:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=lsnpQ0FAwRaMEE0T8ng6I/JzoAcDhlv9O83MRXmudGc=; b=erqhpEuL1KchjkoOa10InAwT7d4VZe2L4uXOpFZ62IAKlO0DRthpw/N7yQ9XMb/vFF eofZBeZZiYayATuLHzgX7R3KSX9ZavjFju0D+Qa0E9tRRHyrdX+bRkGrOpeZ5cTS9W+4 OldTuXRH/mcFI8stLFy2JkE9aVgeQX3Y99/LfC0xeynSnllli9RrWYeR4jmUzChb02Bh dGaSCL50Y326M7MWiT5Om2kSBqKv5H0kJznGNEvH6koXQxV9V4Obtqis/jk6GOTZXjQu A9df5z+62EzsqWQ1UvzgyrIkVOzDrSWR6VYzoYDS9ok5vvFlo7WNQHBYXc0tIWQc+Opl a2+Q== MIME-Version: 1.0 Received: by 10.60.172.236 with SMTP id bf12mr9554152oec.23.1341238581787; Mon, 02 Jul 2012 07:16:21 -0700 (PDT) Sender: yang.r.yang@gmail.com Received: by 10.76.86.136 with HTTP; Mon, 2 Jul 2012 07:16:21 -0700 (PDT) In-Reply-To: <4494f820.14fc0.138465f742c.Coremail.alex7822@163.com> References: <4FEED79A.1090906@cs.yale.edu> <4494f820.14fc0.138465f742c.Coremail.alex7822@163.com> Date: Mon, 2 Jul 2012 22:16:21 +0800 X-Google-Sender-Auth: 5oyj6A2Hyoeu7gyV8TNydycKAhs Message-ID: From: "Y. Richard Yang" To: "C. Alexandre Tian" Content-Type: multipart/alternative; boundary=bcaec54d476839fbe704c3d97164 Cc: "DECADE@ietf.org" Subject: Re: [decade] -req and -arch documents 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, 02 Jul 2012 14:16:18 -0000 --bcaec54d476839fbe704c3d97164 Content-Type: text/plain; charset=ISO-8859-1 Ho Alexander, On Monday, July 2, 2012, C. Alexandre Tian wrote: > Regards Q2: > > To me, all subsections in -arch "4. Architectural Principles" can be > considered > as candidates, which can be carefully re-organized and moved to -req. > I think your proposal is a bit extreme. I agree with the example topics blow, but they are not fully developed, e.g., what properties of resource sharing to satisfy. Also, for example, the preceding discussion was to to leave immutable objects to arch. What do you think? Thanks! Richard > > For example, similar content in "4.1. Decoupled Control/Metadata and Data > Planes > - Resource Scheduling Algorithms" has already appeared in problem > statement doc > "3.3 Ineffective integration of P2P applications". If we want to > repeat/emphasize > this information, the best place is -req. > > > > > > At 2012-06-30 18:40:26,"Y. Richard Yang" > wrote: > >Dear DECADE participants, > > >Both -req and -arch documents have received extensive, excellent > >reviews. In the process of revising the documents and looking at the two > >documents, we have some questions to seek input from the participants: > > >Q1. Both -req and -arch define some terms, including DECADE-compatible > >client, DECADE-compatible server, etc. This appears to be redundant. > >Should such terms be defined in -req or -arch? The current thinking is > >-req. Any comments? > > >Q2. There are multiple paragraphs defining requirements in -arch, e.g., > >Sec. 4.4 on naming. Should these be moved to -req? A more general > >question is on the dependency between -req and -arch. On one hand, it is > >ideal to define -req first without a particular architecture to allow > >competing/alternative architectures satisfying the requirements. On the > >other hand, it appears that the -arch document contains content, in > >particular, systems/function components, that can be helpful to better > >understand the -req document. The current thinking is still to make -req > >independent of -arch, and move some general requirements in -arch to > >-req. Any comments? > > >Q3: There are some good comments on reorganizing the -req documents. > >Below is a new structure (second level section #'s and page numbers are > >from the current -req so that others can see how we re-organize the > >document). Any comments/feedback before we start the revision will be > >greatly appreciated. > > >Also, anyone who can help with direct revisions of the -req document > >will be more than welcome! > >Thanks. > >-- >Richard > > >1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 > >2. Terminology and Concepts . . . . . . . . . . . . . . . . . . . 6 > >3. System/Functional Components > >4. Requirements Structure . . . . . . . . . . . . . . . . . . . . 7 > > >5. Data Object Requirements > > 4.5.1. Data Naming . . . . . . . . . . . . . . . . . . . . . .14 > > Move part of Arch 4.4 to -req > > 5.1. --Immutable Data . . . . . . . . . . . . . . . . . . . . 18 > > 4.4.2. System Data Object Attributes . . . . . . . . . . . . .13 > > 4.2.1. Data Object Size . . . . . . . . . . . . . . . . . 11 > > 4.4.3. Time-to-live for Written Data Objects . . . . . . 13 > > 4.4.4. Application-defined Properties and Metadata . . . . . 13 > > >6. Access to Server Requirements > > 4.3.1. Read/Write Own Storage . . . . . . . . . . . . . . .. 11 > > 4.3.2. Read/Write by Remote Clients . . . . . . . . . . . . . 11 > > 4.4.5. Offline Access . . . . . . . . . . . . . . . . . . . 14 > > 4.1.1.1. NATs and Firewalls TRaversal . . .. . . . . . . . . 8 > > Connections to Clients . . . . . . . . . . . . . . . . . . . 8 > > 6.1.1. Support for Clients Behind NATs and Firewalls . . . 21 > > 4.3.3. Negotiable Data Transport Protocol . . . . . . . . . . 12 > > 5.2. Explicit Deletion of Data . . . . . . . . . . . . . . . 19 > > 5.3. Concurrent Write (Multiple writing). . . . . . . . . . . 19 > > 5.4. Concurrent Read (Multiple reading) . . . . . . . . . . . 19 > > 5.5. Read While Write . . . . . . . . . . . . . . . . . . . 19 > > 5.6. Partial Write (Writing model) . . . . . . . . . . . . . 20 > > 4.1.2.1. Secure Transport . . . . . . . . . . . . . . . . . . 8 > > >7. Resource Control Requirements. . . . . . . . . . . . . . . . . 15 > > 4.6.1. Multiple Applications . . . . . . . . . . . . . . . . 15 > > 4.6.2. Per-Remote-Client, Per-Data Control . . . . . . . . . 15 > > 4.6.3. Resource Control Set . . . . . . . . . . . . . . . . . 16 > > 4.6.4. Server Involvement . . . . . . . . . . . . . . . . . . 16 > > >8. Authorization Requirements > > 4.7.1. Per-Remote-Client, Per-Data Read Access . . . . . . . 16 > > 4.7.2. Per-User Write Access . . . . . . . . . . . . . . . . 17 > > 4.7.3. Default Access Permissions . . . . . . . . . . . . . . 17 > > 4.7.4. Authorization Checks . . . . . . . . . . . . . . . . . 17 > > 4.7.5. Cryptographic Credentials . . . . . . . . . . . . . . 17 > > 4.7.6. Server Involvement . . . . . . . . . . . . . . . . . . 18 > > 4.7.7. Protocol Reuse . . . . . . . . . . . . . . . . . . . . 18 > > >9. Error and Failure Handling Requirements. . . . . . . . . . . . 9 > > 4.1.3.2. Insufficient Resources . . . . . . . . . . . . . . . 9 > > 4.1.3.1. Overload Condition . . . . . . . . . . . . . . . 9 > > 4.1.3.3. Unavailable and Deleted Data . . . . . . . . . . . . 10 > > 4.1.3.4. Insufficient Permissions . . . . . . . . . . . . . . 10 > > 4.1.3.5. Redirection . . . . . . . . . . . . . . . . . . . . 10 > > 4.1.2.2. Gaming Prevention . . . . . . . . . . . . . . . . . .8 > > 4.4.1. Server reliability (Agnostic of reliability) . . . . . 12 > > >10. Server Status Query Requirements . . . . . . . . . . . . . . . 18 > > 5.7. Storage Status . . . . . . . . . . . . . . . . . . . . . 20 > > .... > > >11. Security Considerations . . . . . . . . . . . . . . . . . . . 21 > > 7.1. Authentication and Authorization . . . . . . . . . . . . 21 > > 7.2. Encrypted Data . . . . . . . . . . . . . . . . . . . . . 22 > > 7.3. Protection against Gaming . . . . . . . . . . . . . . . 22 > > > --bcaec54d476839fbe704c3d97164 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: base64 SG8gQWxleGFuZGVyLDxicj48YnI+T24gTW9uZGF5LCBKdWx5IDIsIDIwMTIsIEMuIEFsZXhhbmRy ZSBUaWFuICB3cm90ZTo8YnI+PGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0i bWFyZ2luOjAgMCAwIC44ZXg7Ym9yZGVyLWxlZnQ6MXB4ICNjY2Mgc29saWQ7cGFkZGluZy1sZWZ0 OjFleCI+PGRpdiBzdHlsZT0ibGluZS1oZWlnaHQ6MS43O2ZvbnQtc2l6ZToxNHB4O2ZvbnQtZmFt aWx5OmFyaWFsIj4KPGRpdiBzdHlsZT0ibGluZS1oZWlnaHQ6MS43O2ZvbnQtc2l6ZToxNHB4O2Zv bnQtZmFtaWx5OmFyaWFsIj48ZGl2PlJlZ2FyZHMgUTI6IDwvZGl2PjxkaXY+oDwvZGl2PjxkaXY+ VG8gbWUsoGFsbCBzdWJzZWN0aW9uc6BpbiAtYXJjaCAmcXVvdDs0LqAgQXJjaGl0ZWN0dXJhbCBQ cmluY2lwbGVzJnF1b3Q7IGNhbiBiZSBjb25zaWRlcmVkPC9kaXY+PGRpdj5hcyBjYW5kaWRhdGVz LCB3aGljaCBjYW4gYmWgY2FyZWZ1bGx5IHJlLW9yZ2FuaXplZCBhbmQgbW92ZWQgdG8gLXJlcS48 L2Rpdj4KPC9kaXY+PC9kaXY+PC9ibG9ja3F1b3RlPjxkaXY+PGJyPjwvZGl2PjxkaXY+SSB0aGlu ayB5b3VyIHByb3Bvc2FsIGlzIGEgYml0IGV4dHJlbWUuIEkgYWdyZWUgd2l0aCB0aGUgZXhhbXBs ZSB0b3BpY3MgYmxvdywgYnV0IHRoZXkgYXJlIG5vdDwvZGl2PjxkaXY+ZnVsbHkgZGV2ZWxvcGVk LCBlLmcuLCB3aGF0IHByb3BlcnRpZXMgb2YgcmVzb3VyY2Ugc2hhcmluZyB0byBzYXRpc2Z5LiBB bHNvLCBmb3IgZXhhbXBsZSwgdGhloDwvZGl2PgpwcmVjZWRpbmcgZGlzY3Vzc2lvbiB3YXMgdG+g PHNwYW4gY2xhc3M9IkFwcGxlLXN0eWxlLXNwYW4iIHN0eWxlPnRvIGxlYXZlIKBpbW11dGFibGUg b2JqZWN0cyB0byBhcmNoLiBXaGF0IGRvIHlvdSB0aGluaz88L3NwYW4+PGRpdj48c3BhbiBjbGFz cz0iQXBwbGUtc3R5bGUtc3BhbiIgc3R5bGU+PGJyPjwvc3Bhbj48L2Rpdj48ZGl2PjxzcGFuIGNs YXNzPSJBcHBsZS1zdHlsZS1zcGFuIiBzdHlsZT5UaGFua3MhPHNwYW4+PC9zcGFuPjxicj4KPC9z cGFuPjxkaXY+PGJyPjwvZGl2PjxkaXY+UmljaGFyZDwvZGl2PjxibG9ja3F1b3RlIGNsYXNzPSJn bWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdpbjowIDAgMCAuOGV4O2JvcmRlci1sZWZ0OjFweCAjY2Nj IHNvbGlkO3BhZGRpbmctbGVmdDoxZXgiPjxkaXYgc3R5bGU9ImxpbmUtaGVpZ2h0OjEuNztmb250 LXNpemU6MTRweDtmb250LWZhbWlseTphcmlhbCI+PGRpdiBzdHlsZT0ibGluZS1oZWlnaHQ6MS43 O2ZvbnQtc2l6ZToxNHB4O2ZvbnQtZmFtaWx5OmFyaWFsIj4KPGRpdj6gPC9kaXY+PGRpdj5Gb3Ig ZXhhbXBsZSygc2ltaWxhciBjb250ZW50IGluICZxdW90OzQuMS6gIERlY291cGxlZCBDb250cm9s L01ldGFkYXRhIGFuZCBEYXRhIFBsYW5lczxicj4tIFJlc291cmNlIFNjaGVkdWxpbmcgQWxnb3Jp dGhtcyZxdW90O6BoYXMgYWxyZWFkeSBhcHBlYXJlZCBpbiBwcm9ibGVtIHN0YXRlbWVudCBkb2M8 L2Rpdj48ZGl2PiZxdW90OzMuMyBJbmVmZmVjdGl2ZSBpbnRlZ3JhdGlvbiBvZiBQMlAgYXBwbGlj YXRpb25zJnF1b3Q7LiBJZiB3ZSB3YW50IHRvIHJlcGVhdC9lbXBoYXNpemUgPC9kaXY+CjxkaXY+ dGhpcyBpbmZvcm1hdGlvbiwgdGhlIGJlc3QgcGxhY2UgaXMgLXJlcS48L2Rpdj48L2Rpdj48L2Rp dj48L2Jsb2NrcXVvdGU+PHNwYW4gY2xhc3M9IkFwcGxlLXN0eWxlLXNwYW4iIHN0eWxlPqA8L3Nw YW4+PGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjAgMCAwIC44 ZXg7Ym9yZGVyLWxlZnQ6MXB4ICNjY2Mgc29saWQ7cGFkZGluZy1sZWZ0OjFleCI+CjxkaXYgc3R5 bGU9ImxpbmUtaGVpZ2h0OjEuNztmb250LXNpemU6MTRweDtmb250LWZhbWlseTphcmlhbCI+PGRp diBzdHlsZT0ibGluZS1oZWlnaHQ6MS43O2ZvbnQtc2l6ZToxNHB4O2ZvbnQtZmFtaWx5OmFyaWFs Ij48ZGl2Pjxicj48YnI+PGJyPkF0oDIwMTItMDYtMzCgMTg6NDA6MjYsJnF1b3Q7WS6gUmljaGFy ZKBZYW5nJnF1b3Q7oCZsdDs8YSBocmVmPSJqYXZhc2NyaXB0Ol9lKHt9LCAmIzM5O2N2bWwmIzM5 OywgJiMzOTt5cnlAY3MueWFsZS5lZHUmIzM5Oyk7IiB0YXJnZXQ9Il9ibGFuayI+eXJ5QGNzLnlh bGUuZWR1PC9hPiZndDugd3JvdGU6CiZndDtEZWFyoERFQ0FERaBwYXJ0aWNpcGFudHMsCiZndDsK Jmd0O0JvdGigLXJlcaBhbmSgLWFyY2igZG9jdW1lbnRzoGhhdmWgcmVjZWl2ZWSgZXh0ZW5zaXZl LKBleGNlbGxlbnSgCiZndDtyZXZpZXdzLqBJbqB0aGWgcHJvY2Vzc6BvZqByZXZpc2luZ6B0aGWg ZG9jdW1lbnRzoGFuZKBsb29raW5noGF0oHRoZaB0d2+gCiZndDtkb2N1bWVudHMsoHdloGhhdmWg c29tZaBxdWVzdGlvbnOgdG+gc2Vla6BpbnB1dKBmcm9toHRoZaBwYXJ0aWNpcGFudHM6CiZndDsK Jmd0O1ExLqBCb3RooC1yZXGgYW5koC1hcmNooGRlZmluZaBzb21loHRlcm1zLKBpbmNsdWRpbmeg REVDQURFLWNvbXBhdGlibGWgCiZndDtjbGllbnQsoERFQ0FERS1jb21wYXRpYmxloHNlcnZlciyg ZXRjLqBUaGlzoGFwcGVhcnOgdG+gYmWgcmVkdW5kYW50LqAKJmd0O1Nob3VsZKBzdWNooHRlcm1z oGJloGRlZmluZWSgaW6gLXJlcaBvcqAtYXJjaD+gVGhloGN1cnJlbnSgdGhpbmtpbmegaXOgCiZn dDstcmVxLqBBbnmgY29tbWVudHM/CiZndDsKJmd0O1EyLqBUaGVyZaBhcmWgbXVsdGlwbGWgcGFy YWdyYXBoc6BkZWZpbmluZ6ByZXF1aXJlbWVudHOgaW6gLWFyY2gsoGUuZy4soAomZ3Q7U2VjLqA0 LjSgb26gbmFtaW5nLqBTaG91bGSgdGhlc2WgYmWgbW92ZWSgdG+gLXJlcT+gQaBtb3JloGdlbmVy YWygCiZndDtxdWVzdGlvbqBpc6BvbqB0aGWgZGVwZW5kZW5jeaBiZXR3ZWVuoC1yZXGgYW5koC1h cmNoLqBPbqBvbmWgaGFuZCygaXSgaXOgCiZndDtpZGVhbKB0b6BkZWZpbmWgLXJlcaBmaXJzdKB3 aXRob3V0oGGgcGFydGljdWxhcqBhcmNoaXRlY3R1cmWgdG+gYWxsb3egCiZndDtjb21wZXRpbmcv YWx0ZXJuYXRpdmWgYXJjaGl0ZWN0dXJlc6BzYXRpc2Z5aW5noHRoZaByZXF1aXJlbWVudHMuoE9u oHRoZaAKJmd0O290aGVyoGhhbmQsoGl0oGFwcGVhcnOgdGhhdKB0aGWgLWFyY2igZG9jdW1lbnSg Y29udGFpbnOgY29udGVudCygaW6gCiZndDtwYXJ0aWN1bGFyLKBzeXN0ZW1zL2Z1bmN0aW9uoGNv bXBvbmVudHMsoHRoYXSgY2FuoGJloGhlbHBmdWygdG+gYmV0dGVyoAomZ3Q7dW5kZXJzdGFuZKB0 aGWgLXJlcaBkb2N1bWVudC6gVGhloGN1cnJlbnSgdGhpbmtpbmegaXOgc3RpbGygdG+gbWFrZaAt cmVxoAomZ3Q7aW5kZXBlbmRlbnSgb2agLWFyY2gsoGFuZKBtb3ZloHNvbWWgZ2VuZXJhbKByZXF1 aXJlbWVudHOgaW6gLWFyY2igdG+gCiZndDstcmVxLqBBbnmgY29tbWVudHM/CiZndDsKJmd0O1Ez OqBUaGVyZaBhcmWgc29tZaBnb29koGNvbW1lbnRzoG9uoHJlb3JnYW5pemluZ6B0aGWgLXJlcaBk b2N1bWVudHMuoAomZ3Q7QmVsb3egaXOgYaBuZXegc3RydWN0dXJloChzZWNvbmSgbGV2ZWygc2Vj dGlvbqAjJiMzOTtzoGFuZKBwYWdloG51bWJlcnOgYXJloAomZ3Q7ZnJvbaB0aGWgY3VycmVudKAt cmVxoHNvoHRoYXSgb3RoZXJzoGNhbqBzZWWgaG93oHdloHJlLW9yZ2FuaXploHRoZaAKJmd0O2Rv Y3VtZW50KS6gQW55oGNvbW1lbnRzL2ZlZWRiYWNroGJlZm9yZaB3ZaBzdGFydKB0aGWgcmV2aXNp b26gd2lsbKBiZaAKJmd0O2dyZWF0bHmgYXBwcmVjaWF0ZWQuCiZndDsKJmd0O0Fsc28soGFueW9u ZaB3aG+gY2FuoGhlbHCgd2l0aKBkaXJlY3SgcmV2aXNpb25zoG9moHRoZaAtcmVxoGRvY3VtZW50 oAomZ3Q7d2lsbKBiZaBtb3JloHRoYW6gd2VsY29tZSEKJmd0OwomZ3Q7VGhhbmtzLgomZ3Q7CiZn dDstLaAKJmd0O1JpY2hhcmQKJmd0OwomZ3Q7MS6goEludHJvZHVjdGlvbqAuoC6gLqAuoC6gLqAu oC6gLqAuoC6gLqAuoC6gLqAuoC6gLqAuoC6gLqAuoC6gLqAuoKA1CiZndDsyLqCgVGVybWlub2xv Z3mgYW5koENvbmNlcHRzoC6gLqAuoC6gLqAuoC6gLqAuoC6gLqAuoC6gLqAuoC6gLqAuoC6goDYK Jmd0OzMuoKBTeXN0ZW0vRnVuY3Rpb25hbKBDb21wb25lbnRzCiZndDs0LqCgUmVxdWlyZW1lbnRz oFN0cnVjdHVyZaAuoC6gLqAuoC6gLqAuoC6gLqAuoC6gLqAuoC6gLqAuoC6gLqAuoC6goDcKJmd0 OwomZ3Q7NS6goERhdGGgT2JqZWN0oFJlcXVpcmVtZW50cwomZ3Q7oKCgoKA0LjUuMS6goERhdGGg TmFtaW5noC6gLqAuoC6gLqAuoC6gLqAuoC6gLqAuoC6gLqAuoC6gLqAuoC6gLqAuoC4xNAomZ3Q7 oKCgoKCgoKCgoKCgoE1vdmWgcGFydKBvZqBBcmNooDQuNKB0b6AtcmVxCiZndDugoKCgoDUuMS6g oC0tSW1tdXRhYmxloERhdGGgLqAuoC6gLqAuoC6gLqAuoC6gLqAuoC6gLqAuoC6gLqAuoC6gLqAu oDE4CiZndDugoKCgoDQuNC4yLqCgU3lzdGVtoERhdGGgT2JqZWN0oEF0dHJpYnV0ZXOgLqAuoC6g LqAuoC6gLqAuoC6gLqAuoC6gLjEzCiZndDugoKCgoKCgoKA0LjIuMS6goERhdGGgT2JqZWN0oFNp emWgLqAuoC6gLqAuoC6gLqAuoC6gLqAuoC6gLqAuoC6gLqAuoDExCiZndDugoKCgoKCgoKA0LjQu My6goFRpbWUtdG8tbGl2ZaBmb3KgV3JpdHRlbqBEYXRhoE9iamVjdHOgoC6gLqAuoC6gLqAuoDEz CiZndDugoKCgoDQuNC40LqCgQXBwbGljYXRpb24tZGVmaW5lZKBQcm9wZXJ0aWVzoGFuZKBNZXRh ZGF0YaCgLqAuoC6gLqAuoDEzCiZndDsKJmd0OzYuoKBBY2Nlc3OgdG+gU2VydmVyoFJlcXVpcmVt ZW50cwomZ3Q7oKCgoKA0LjMuMS6goFJlYWQvV3JpdGWgT3duoFN0b3JhZ2WgoC6gLqAuoC6gLqAu oC6gLqAuoC6gLqAuoC6gLqAuLqAxMQomZ3Q7oKCgoKA0LjMuMi6goFJlYWQvV3JpdGWgYnmgUmVt b3RloENsaWVudHOgLqAuoC6gLqAuoC6gLqAuoC6gLqAuoC6gLqAxMQomZ3Q7oKCgoKA0LjQuNS6g oE9mZmxpbmWgQWNjZXNzoKAuoC6gLqAuoC6gLqAuoC6gLqAuoC6gLqAuoC6gLqAuoKAuoC6gLqAx NAomZ3Q7oKCgoKA0LjEuMS4xLqCgTkFUc6BhbmSgRmlyZXdhbGxzoFRSYXZlcnNhbKAuoC6gLi6g LqAuoKAuoC6gLqAuoC6gLqCgOAomZ3Q7oKCgoKCgoENvbm5lY3Rpb25zoHRvoENsaWVudHOgLqAu oC6gLqAuoC6gLqAuoC6gLqAuoC6gLqAuoC6gLqAuoC6gLqCgOAomZ3Q7oKCgoKCgoDYuMS4xLqCg U3VwcG9ydKBmb3KgQ2xpZW50c6BCZWhpbmSgTkFUc6BhbmSgRmlyZXdhbGxzoKAuoC6gLqAyMQom Z3Q7oKCgoKA0LjMuMy6goE5lZ290aWFibGWgRGF0YaBUcmFuc3BvcnSgUHJvdG9jb2ygLqAuoC6g LqAuoC6gLqAuoC6gLqAxMgomZ3Q7oKCgoKA1LjIuoKBFeHBsaWNpdKBEZWxldGlvbqBvZqBEYXRh oKAuoC6gLqAuoC6gLqAuoC6gLqAuoC6gLqAuoC6gLqAxOQomZ3Q7oKCgoKA1LjMuoKBDb25jdXJy ZW50oFdyaXRloChNdWx0aXBsZaB3cml0aW5nKS6gLqAuoC6gLqAuoC6gLqAuoC6gLqAxOQomZ3Q7 oKCgoKA1LjQuoKBDb25jdXJyZW50oFJlYWSgKE11bHRpcGxloHJlYWRpbmcpoC6gLqAuoC6gLqAu oC6gLqAuoC6gLqAxOQomZ3Q7oKCgoKA1LjUuoKBSZWFkoFdoaWxloFdyaXRloC6gLqAuoC6gLqAu oC6gLqCgoC6gLqAuoC6gLqAuoC6gLqAuoC6gLqAxOQomZ3Q7oKCgoKA1LjYuoKBQYXJ0aWFsoFdy aXRloChXcml0aW5noG1vZGVsKaAuoC6gLqAuoC6gLqAuoC6gLqAuoC6gLqAuoDIwCiZndDugoKCg oDQuMS4yLjEuoKBTZWN1cmWgVHJhbnNwb3J0oC6gLqAuoC6gLqAuoC6gLqAuoC6gLqAuoC6gLqAu oC6gLqAuoKA4CiZndDsKJmd0OzcuoKBSZXNvdXJjZaBDb250cm9soFJlcXVpcmVtZW50cy6gLqAu oC6gLqAuoC6gLqAuoC6gLqAuoC6gLqAuoC6gLqAxNQomZ3Q7oKCgoKA0LjYuMS6goE11bHRpcGxl oEFwcGxpY2F0aW9uc6CgLqAuoC6gLqAuoC6gLqAuoC6gLqAuoC6gLqAuoC6gLqAxNQomZ3Q7oKCg oKA0LjYuMi6goFBlci1SZW1vdGUtQ2xpZW50LKBQZXItRGF0YaBDb250cm9soKAuoC6gLqAuoC6g LqAuoC6gLqAxNQomZ3Q7oKCgoKA0LjYuMy6goFJlc291cmNloENvbnRyb2ygU2V0oC6gLqAuoC6g LqAuoC6gLqAuoC6gLqAuoC6gLqAuoC6gLqAxNgomZ3Q7oKCgoKA0LjYuNC6goFNlcnZlcqBJbnZv bHZlbWVudKAuoC6gLqAuoC6gLqAuoC6gLqAuoC6gLqAuoC6gLqAuoC6gLqAxNgomZ3Q7CiZndDs4 LqCgQXV0aG9yaXphdGlvbqBSZXF1aXJlbWVudHMKJmd0O6CgoKCgNC43LjEuoKBQZXItUmVtb3Rl LUNsaWVudCygUGVyLURhdGGgUmVhZKBBY2Nlc3OgoC6gLqAuoC6gLqAuoC6gMTYKJmd0O6CgoKCg NC43LjIuoKBQZXItVXNlcqBXcml0ZaBBY2Nlc3OgoC6gLqAuoC6gLqAuoC6gLqAuoC6gLqAuoC6g LqAuoC6gMTcKJmd0O6CgoKCgNC43LjMuoKBEZWZhdWx0oEFjY2Vzc6BQZXJtaXNzaW9uc6AuoC6g LqAuoC6gLqAuoC6gLqAuoC6gLqAuoC6gMTcKJmd0O6CgoKCgNC43LjQuoKBBdXRob3JpemF0aW9u oENoZWNrc6AuoC6gLqAuoC6gLqAuoC6gLqAuoC6gLqAuoC6gLqAuoC6gMTcKJmd0O6CgoKCgNC43 LjUuoKBDcnlwdG9ncmFwaGljoENyZWRlbnRpYWxzoKAuoC6gLqAuoC6gLqAuoC6gLqAuoC6gLqAu oC6gMTcKJmd0O6CgoKCgNC43LjYuoKBTZXJ2ZXKgSW52b2x2ZW1lbnSgLqAuoC6gLqAuoC6gLqAu oC6gLqAuoC6gLqAuoC6gLqAuoC6gMTgKJmd0O6CgoKCgNC43LjcuoKBQcm90b2NvbKBSZXVzZaAu oC6gLqAuoC6gLqAuoC6gLqAuoC6gLqAuoC6gLqAuoC6gLqAuoC6gMTgKJmd0OwomZ3Q7OS6goEVy cm9yoGFuZKBGYWlsdXJloEhhbmRsaW5noFJlcXVpcmVtZW50cy6gLqAuoC6gLqAuoC6gLqAuoC6g LqAuoKA5CiZndDugoKCgoDQuMS4zLjIuoKBJbnN1ZmZpY2llbnSgUmVzb3VyY2VzoC6gLqAuoC6g LqAuoC6gLqAuoC6gLqAuoC6gLqAuoKA5CiZndDugoKCgoKCgoKA0LjEuMy4xLqCgT3ZlcmxvYWSg Q29uZGl0aW9uoC6gLqAuoC6gLqAuoC6gLqAuoC6gLqAuoC6gLqAuoKA5CiZndDugoKCgoDQuMS4z LjMuoKBVbmF2YWlsYWJsZaBhbmSgRGVsZXRlZKBEYXRhoC6gLqAuoC6gLqAuoC6gLqAuoC6gLqAu oDEwCiZndDugoKCgoDQuMS4zLjQuoKBJbnN1ZmZpY2llbnSgUGVybWlzc2lvbnOgLqAuoC6gLqAu oC6gLqAuoC6gLqAuoC6gLqAuoDEwCiZndDugoKCgoDQuMS4zLjUuoKBSZWRpcmVjdGlvbqCgLqAu oC6gLqAuoC6gLqAuoC6gLqAuoC6gLqAuoC6gLqAuoC6gLqAuoDEwCiZndDugoKCgoDQuMS4yLjIu oKBHYW1pbmegUHJldmVudGlvbqCgLqAuoC6gLqAuoC6gLqAuoC6gLqAuoC6gLqAuoC6gLqAuoC44 CiZndDugoKCgoDQuNC4xLqCgU2VydmVyoHJlbGlhYmlsaXR5oChBZ25vc3RpY6BvZqByZWxpYWJp bGl0eSmgLqAuoC6gLqAuoDEyCiZndDsKJmd0OzEwLqBTZXJ2ZXKgU3RhdHVzoFF1ZXJ5oFJlcXVp cmVtZW50c6AuoC6gLqAuoC6gLqAuoC6gLqAuoC6gLqAuoC6gLqAxOAomZ3Q7oKCgoKA1LjcuoKBT dG9yYWdloFN0YXR1c6AuoC6gLqAuoC6gLqAuoC6gLqAuoC6gLqAuoC6gLqAuoC6gLqAuoC6gLqAy MAomZ3Q7oKCgoKAuLi4uCiZndDsKJmd0OzExLqBTZWN1cml0eaBDb25zaWRlcmF0aW9uc6CgLqAu oC6gLqAuoC6gLqAuoC6gLqAuoC6gLqAuoC6gLqAuoC6gLqAyMQomZ3Q7oKCgoKA3LjEuoKBBdXRo ZW50aWNhdGlvbqBhbmSgQXV0aG9yaXphdGlvbqAuoC6gLqAuoC6gLqAuoC6gLqAuoC6gLqAyMQom Z3Q7oKCgoKA3LjIuoKBFbmNyeXB0ZWSgRGF0YaAuoC6gLqAuoC6gLqAuoC6gLqAuoC6gLqAuoC6g LqAuoC6gLqAuoC6gLqAyMgomZ3Q7oKCgoKA3LjMuoKBQcm90ZWN0aW9uoGFnYWluc3SgR2FtaW5n oKAuoC6gLqAuoC6gLqAuoC6gLqAuoC6gLqAuoC6gLqAyMgomZ3Q7CiZndDs8L2Rpdj48L2Rpdj48 L2Rpdj48L2Jsb2NrcXVvdGU+PGRpdj48L2Rpdj48c3BhbiBjbGFzcz0iQXBwbGUtc3R5bGUtc3Bh biIgc3R5bGU+oDwvc3Bhbj48ZGl2PjwvZGl2PjwvZGl2Pgo= --bcaec54d476839fbe704c3d97164-- From yang.r.yang@gmail.com Mon Jul 2 07:21:55 2012 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 CB9EA21F8690 for ; Mon, 2 Jul 2012 07:21:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.778 X-Spam-Level: X-Spam-Status: No, score=-2.778 tagged_above=-999 required=5 tests=[AWL=0.198, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 kl8lrRaXfzZs for ; Mon, 2 Jul 2012 07:21:53 -0700 (PDT) Received: from mail-yw0-f53.google.com (mail-yw0-f53.google.com [209.85.213.53]) by ietfa.amsl.com (Postfix) with ESMTP id 9A98221F8636 for ; Mon, 2 Jul 2012 07:21:52 -0700 (PDT) Received: by yhp26 with SMTP id 26so5724030yhp.26 for ; Mon, 02 Jul 2012 07:21:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=yPdXV+T9mz3L+Y4mWpdFRSj3izcBNATJ6aJx+0EovVY=; b=vO2vRp/9DCUN+LEGLCucBEoE0gx6jpLynO4j+xSEorZqhGI8REAI3ceLrKJADkb1xF I49COMCmteGBXjTfJkm+fsFQshhnGBWyC/w6jd6ddce80Z+EhVU6fkPvWjtwntc0HMj0 Mex1XiJEyKBF6C96H50sfj+ogs05UwOcOtItUIUtT/LlU+QHc8VCIswvoMiYB5acHxKY um6m3fJ9SF2gq1ThiyeVxB+36u+VS1YS1gh16zEP1VOTZzOmnSBUjgA1/OGUpuHNOJqP DcXWt4RhkexJQT7jvoiI2BvCsrNyyP7EQzLzIDGuhS4AKR4XU8SJ2D7mmrlDF1mRLt3R V9og== MIME-Version: 1.0 Received: by 10.60.172.236 with SMTP id bf12mr9585547oec.23.1341238917156; Mon, 02 Jul 2012 07:21:57 -0700 (PDT) Sender: yang.r.yang@gmail.com Received: by 10.76.86.136 with HTTP; Mon, 2 Jul 2012 07:21:57 -0700 (PDT) In-Reply-To: References: <4FEED79A.1090906@cs.yale.edu> Date: Mon, 2 Jul 2012 22:21:57 +0800 X-Google-Sender-Auth: 1drcAjpPIuH02Vj-CQb-dFmPf5U Message-ID: From: "Y. Richard Yang" To: Haiwei Xue Content-Type: multipart/alternative; boundary=bcaec54d476837508604c3d9855f Cc: "DECADE@ietf.org" Subject: Re: [decade] -req and -arch documents 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, 02 Jul 2012 14:21:55 -0000 --bcaec54d476837508604c3d9855f Content-Type: text/plain; charset=ISO-8859-1 On Monday, July 2, 2012, Haiwei Xue wrote: > Hi Richard, > > Here are some of my comments. > > Thanks. > > Haiwei > > On Sat, Jun 30, 2012 at 6:40 AM, Y. Richard Yang > > wrote: > >> Dear DECADE participants, >> >> Both -req and -arch documents have received extensive, excellent reviews. >> In the process of revising the documents and looking at the two documents, >> we have some questions to seek input from the participants: >> >> Q1. Both -req and -arch define some terms, including DECADE-compatible >> client, DECADE-compatible server, etc. This appears to be redundant. Should >> such terms be defined in -req or -arch? The current thinking is -req. Any >> comments? >> > > [Haiwei] 1. I think the current definition is good if we add some > explanation in -arch, e.g. we can add a sentence in Sec. 2 (-arch) at the > begin of definitions: some terms are already defined in '-req'. > > Ok. > [Haiwei] 2. If you think it is still redundant, then you can remove the > definition from -arch, and then reference the terms from -req. > I agree with you to leave the def. in -req, because if let > me choose the documents which I want to read first, I will choose -req. So > -req should keep dependent. > > BTW, I like the style of terminology definition in -arch, because it is > very clear in the "Table of Contents". > Thanks for the feedback. We will do so for -req. > > >> >> Q2. There are multiple paragraphs defining requirements in -arch, e.g., >> Sec. 4.4 on naming. Should these be moved to -req? A more general question >> is on the dependency between -req and -arch. On one hand, it is ideal to >> define -req first without a particular architecture to allow >> competing/alternative architectures satisfying the requirements. On the >> other hand, it appears that the -arch document contains content, in >> particular, systems/function components, that can be helpful to better >> understand the -req document. The current thinking is still to make -req >> independent of -arch, and move some general requirements in -arch to -req. >> Any comments? >> > > [Haiwei] Point 1: If we leave the requirements on naming in -arch, would > that broke the dependency of -req? I don't think so. > > [Haiwei] Point 2: In the -req you proposed the naming question, they are > high level consideration, and in -arch based on > the data-object oriented architecture and the design details you proposed > some new requirements on naming. This sounds reasonable. And if you move > those requirements from -arch to -req, it will let the readers confused: > which documents should they read first. > > So what you want is some general req in -req, and specific reqs in -arch. I tend to agree with this split, but will need a detailed look to see this such a split is possible. Any volunteer to propose a split related on naming? Thanks! Richard > So I think the requirements on details should keep int -arch. > > >> >> Q3: There are some good comments on reorganizing the -req documents. >> Below is a new structure (second level section #'s and page numbers are >> from the current -req so that others can see how we re-organize the >> document). Any comments/feedback before we start the revision will be >> greatly appreciated. >> > > Also, anyone who can help with direct revisions of the -req document will >> be more than welcome! >> >> Thanks. >> >> -- >> Richard >> >> 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 >> 2. Terminology and Concepts . . . . . . . . . . . . . . . . . . . 6 >> 3. System/Functional Components >> 4. Requirements Structure . . . . . . . . . . . . . . . . . . . . 7 >> >> 5. Data Object Requirements >> 4.5.1. Data Naming . . . . . . . . . . . . . . . . . . . . . .14 >> Move part of Arch 4.4 to -req >> 5.1. --Immutable Data . . . . . . . . . . . . . . . . . . . . 18 >> 4.4.2. System Data Object Attributes . . . . . . . . . . . . .13 >> 4.2.1. Data Object Size . . . . . . . . . . . . . . . . . 11 >> 4.4.3. Time-to-live for Written Data Objects . . . . . . 13 >> 4.4.4. Application-defined Properties and Metadata . . . . . 13 >> >> 6. Access to Server Requirements >> 4.3.1. Read/Write Own Storage . . . . . . . . . . . . . . .. 11 >> 4.3.2. Read/Write by Remote Clients . . . . . . . . . . . . . 11 >> 4.4.5. Offline Access . . . . . . . . . . . . . . . . . . . 14 >> 4.1.1.1. NATs and Firewalls TRaversal . . .. . . . . . . . . 8 >> Connections to Clients . . . . . . . . . . . . . . . . . . . 8 >> 6.1.1. Support for Clients Behind NATs and Firewalls . . . 21 >> 4.3.3. Negotiable Data Transport Protocol . . . . . . . . . . 12 >> 5.2. Explicit Deletion of Data . . . . . . . . . . . . . . . 19 >> 5.3. Concurrent Write (Multiple writing). . . . . . . . . . . 19 >> 5.4. Concurrent Read (Multiple reading) . . . . . . . . . . . 19 >> 5.5. Read While Write . . . . . . . . . . . . . . . . . . . 19 >> 5.6. Partial Write (Writing model) . . . . . . . . . . . . . 20 >> 4.1.2.1. Secure Transport . . . . . . . . . . . . . . . . . . 8 >> >> 7. Resource Control Requirements. . . . . . . . . . . . . . . . . 15 >> 4.6.1. Multiple Applications . . . . . . . . . . . . . . . . 15 >> 4.6.2. Per-Remote-Client, Per-Data Control . . . . . . . . . 15 >> 4.6.3. Resource Control Set . . . . . . . . . . . . . . . . . 16 >> 4.6.4. Server Involvement . . . . . . . . . . . . . . . . . . 16 >> >> 8. Authorization Requirements >> 4.7.1. Per-Remote-Client, Per-Data Read Access . . . . . . . 16 >> 4.7.2. Per-User Write Access . . . . . . . . . . . . . . . . 17 >> 4.7.3. Default Access Permissions . . . . . . . . . . . . . . 17 >> 4.7.4. Authorization Checks . . . . . . . . . . . . . . . . . 17 >> 4.7.5. Cryptographic Credentials . . . . . . . . . . . . . . 17 >> 4.7.6. Server Involvement . . . . . . . . . . . . . . . . . . 18 >> 4.7.7. Protocol Reuse . . . . . . . . . . . . . . . . . . . . 18 >> >> 9. Error and Failure Handling Requirements. . . . . . . . . . . . 9 >> 4.1.3.2. Insufficient Resources . . . . . . . . . . . . . . . 9 >> 4.1.3.1. Overload Condition . . . . . . . . . . . . . . . 9 >> 4.1.3.3. Unavailable and Deleted Data . . . . . . . . . . . . 10 >> 4.1.3.4. Insufficient Permissions . . . . . . . . . . . . . . 10 >> 4.1.3.5. Redirection . . . . . . . . . . . . . . . . . . . . 10 >> 4.1.2.2. Gaming Prevention . . . . . . . . . . . . . . . . . .8 >> 4.4.1. Server reliability (Agnostic of reliability) . . . . . 12 >> >> 10. Server Status Query Requirements . . . . . . . . . . . . . . . 18 >> 5.7. Storage Status . . . . . . . . . . . . . . . . . . . . . 20 >> .... >> >> 11. Security Considerations . . . . . . . . . . . . . . . . . . . 21 >> 7.1. Authentication and Authorization . . . . . . . . . . . . 21 >> 7.2. Encrypted Data . . . . . . . . . . . . . . . . . . . . . 22 >> 7.3. Protection against Gaming . . . . . . . . . . . . . . . 22 >> >> >> > --bcaec54d476837508604c3d9855f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Monday, July 2, 2012, Haiwei Xue wrote:
Hi Richard,

Here are some of my comments.
=
Thanks.

Haiwei

O= n Sat, Jun 30, 2012 at 6:40 AM, Y. Richard Yang <yry@cs.yale.edu> wrote:
Dear DECADE participants,

Both -req and -arch documents have received extensive, excellent reviews. I= n the process of revising the documents and looking at the two documents, w= e have some questions to seek input from the participants:

Q1. Both -req and -arch define some terms, including DECADE-compatible clie= nt, DECADE-compatible server, etc. This appears to be redundant. Should suc= h terms be defined in -req or -arch? The current thinking is -req. Any comm= ents?

[Haiwei] 1. I think the current definition= is good if we add some explanation in -arch, e.g. we can add a=A0sentence = in Sec. 2 (-arch) at the begin of definitions: some terms are already defin= ed in '-req'.

Ok.
=A0
[Haiwei] 2. If= you think it is still=A0redundant, then you can remove the definition from= -arch, and then=A0reference the terms from -req.=A0
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 I agree with you to leave the def. in = -req, because if let me choose the documents which I want to read first, I = will choose -req. So -req=A0should keep dependent.

BTW, I like the style of terminology=A0definition in -a= rch, because it is very clear in the "Table of Contents".

Thanks for the feedback. We will= do so for -req.
=A0
=A0

Q2. There are multiple paragraphs defining requirements in -arch, e.g., Sec= . 4.4 on naming. Should these be moved to -req? A more general question is = on the dependency between -req and -arch. On one hand, it is ideal to defin= e -req first without a particular architecture to allow competing/alternati= ve architectures satisfying the requirements. On the other hand, it appears= that the -arch document contains content, in particular, systems/function = components, that can be helpful to better understand the -req document. The= current thinking is still to make -req independent of -arch, and move some= general requirements in -arch to -req. Any comments?

[Haiwei] Point 1: If we leave the=A0 requirements=A0on naming in -arch, would that broke the=A0dependency of -re= q? I don't think so.

[Haiwei] Point 2: In the = -req you proposed the naming question, they are high level consideration, a= nd in -arch based on the=A0data-object=A0oriented=A0architecture and the de= sign details you proposed some new=A0requirements on naming. This sounds=A0= reasonable. And if you move those=A0=A0requirements=A0 from -arch to -req, = it will let the readers confused: which documents should they read first.

So what you want is some gener= al req in -req, and specific reqs in -arch. I tend to agree with this split= , but will need a detailed look to see this such a split is possible. Any v= olunteer to propose a split related on naming?

Thanks!

Richard
=A0<= /div>
So= I think the=A0requirements=A0on details should keep int -arch.
=A0

Q3: There are some good comments on reorganizing the -req documents. Below = is a new structure (second level section #'s and page numbers are from = the current -req so that others can see how we re-organize the document). A= ny comments/feedback before we start the revision will be greatly appreciat= ed.
=A0
Also, anyone who can help with direct revisions of the -req document will b= e more than welcome!

Thanks.

--
Richard

1. =A0Introduction . . . . . . . . . . . . . . . . . . . . . . . . . =A05 2. =A0Terminology and Concepts . . . . . . . . . . . . . . . . . . . =A06 3. =A0System/Functional Components
4. =A0Requirements Structure . . . . . . . . . . . . . . . . . . . . =A07
5. =A0Data Object Requirements
=A0 =A0 4.5.1. =A0Data Naming . . . . . . . . . . . . . . . . . . . . . .14=
=A0 =A0 =A0 =A0 =A0 =A0 Move part of Arch 4.4 to -req
=A0 =A0 5.1. =A0--Immutable Data . . . . . . . . . . . . . . . . . . . . 18=
=A0 =A0 4.4.2. =A0System Data Object Attributes . . . . . . . . . . . . .13=
=A0 =A0 =A0 =A0 4.2.1. =A0Data Object Size . . . . . . . . . . . . . . . . = . 11
=A0 =A0 =A0 =A0 4.4.3. =A0Time-to-live for Written Data Objects =A0. . . . = . . 13
=A0 =A0 4.4.4. =A0Application-defined Properties and Metadata =A0. . . . . = 13

6. =A0Access to Server Requirements
=A0 =A0 4.3.1. =A0Read/Write Own Storage =A0. . . . . . . . . . . . . . .. = 11
=A0 =A0 4.3.2. =A0Read/Write by Remote Clients . . . . . . . . . . . . . 11=
=A0 =A0 4.4.5. =A0Offline Access =A0. . . . . . . . . . . . . . . . =A0. . = . 14
=A0 =A0 4.1.1.1. =A0NATs and Firewalls TRaversal . . .. . . =A0. . . . . . = =A08
=A0 =A0 =A0 Connections to Clients . . . . . . . . . . . . . . . . . . . = =A08
=A0 =A0 =A0 6.1.1. =A0Support for Clients Behind NATs and Firewalls =A0. . = . 21
=A0 =A0 4.3.3. =A0Negotiable Data Transport Protocol . . . . . . . . . . 12=
=A0 =A0 5.2. =A0Explicit Deletion of Data =A0. . . . . . . . . . . . . . . = 19
=A0 =A0 5.3. =A0Concurrent Write (Multiple writing). . . . . . . . . . . 19=
=A0 =A0 5.4. =A0Concurrent Read (Multiple reading) . . . . . . . . . . . 19=
=A0 =A0 5.5. =A0Read While Write . . . . . . . . =A0 . . . . . . . . . . . = 19
=A0 =A0 5.6. =A0Partial Write (Writing model) . . . . . . . . . . . . . 20<= br> =A0 =A0 4.1.2.1. =A0Secure Transport . . . . . . . . . . . . . . . . . . = =A08

7. =A0Resource Control Requirements. . . . . . . . . . . . . . . . . 15
=A0 =A0 4.6.1. =A0Multiple Applications =A0. . . . . . . . . . . . . . . . = 15
=A0 =A0 4.6.2. =A0Per-Remote-Client, Per-Data Control =A0. . . . . . . . . = 15
=A0 =A0 4.6.3. =A0Resource Control Set . . . . . . . . . . . . . . . . . 16=
=A0 =A0 4.6.4. =A0Server Involvement . . . . . . . . . . . . . . . . . . 16=

8. =A0Authorization Requirements
=A0 =A0 4.7.1. =A0Per-Remote-Client, Per-Data Read Access =A0. . . . . . . = 16
=A0 =A0 4.7.2. =A0Per-User Write Access =A0. . . . . . . . . . . . . . . . = 17
=A0 =A0 4.7.3. =A0Default Access Permissions . . . . . . . . . . . . . . 17=
=A0 =A0 4.7.4. =A0Authorization Checks . . . . . . . . . . . . . . . . . 17=
=A0 =A0 4.7.5. =A0Cryptographic Credentials =A0. . . . . . . . . . . . . . = 17
=A0 =A0 4.7.6. =A0Server Involvement . . . . . . . . . . . . . . . . . . 18=
=A0 =A0 4.7.7. =A0Protocol Reuse . . . . . . . . . . . . . . . . . . . . 18=

9. =A0Error and Failure Handling Requirements. . . . . . . . . . . . =A09 =A0 =A0 4.1.3.2. =A0Insufficient Resources . . . . . . . . . . . . . . . = =A09
=A0 =A0 =A0 =A0 4.1.3.1. =A0Overload Condition . . . . . . . . . . . . . . = . =A09
=A0 =A0 4.1.3.3. =A0Unavailable and Deleted Data . . . . . . . . . . . . 10=
=A0 =A0 4.1.3.4. =A0Insufficient Permissions . . . . . . . . . . . . . . 10=
=A0 =A0 4.1.3.5. =A0Redirection =A0. . . . . . . . . . . . . . . . . . . . = 10
=A0 =A0 4.1.2.2. =A0Gaming Prevention =A0. . . . . . . . . . . . . . . . . = .8
=A0 =A0 4.4.1. =A0Server reliability (Agnostic of reliability) . . . . . 12=

10. Server Status Query Requirements . . . . . . . . . . . . . . . 18
=A0 =A0 5.7. =A0Storage Status . . . . . . . . . . . . . . . . . . . . . 20=
=A0 =A0 ....

11. Security Considerations =A0. . . . . . . . . . . . . . . . . . . 21
=A0 =A0 7.1. =A0Authentication and Authorization . . . . . . . . . . . . 21=
=A0 =A0 7.2. =A0Encrypted Data . . . . . . . . . . . . . . . . . . . . . 22=
=A0 =A0 7.3. =A0Protection against Gaming =A0. . . . . . . . . . . . . . . = 22



--bcaec54d476837508604c3d9855f-- From heavyxue@gmail.com Mon Jul 2 20:59:20 2012 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 6B90C11E811C for ; Mon, 2 Jul 2012 20:59:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.298 X-Spam-Level: X-Spam-Status: No, score=-3.298 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_51=0.6, 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 mpiQ6WRCFWqG for ; Mon, 2 Jul 2012 20:59:19 -0700 (PDT) Received: from mail-yw0-f53.google.com (mail-yw0-f53.google.com [209.85.213.53]) by ietfa.amsl.com (Postfix) with ESMTP id 6FDE111E8116 for ; Mon, 2 Jul 2012 20:59:19 -0700 (PDT) Received: by yhp26 with SMTP id 26so6761269yhp.26 for ; Mon, 02 Jul 2012 20:59:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=DJQPiMSvRkmDT3yCQoeAOs0ji3O5Wk4XufTPs100qu0=; b=CTKMSKJtr8R7Ukfao8zmylnGF0q1e0KEbA/ZnSEEVGime8jlkCbwZEmtRf6Io4/l4u w47Ume0Yw+yKabTDEM+F3L3Zjofll0QMhLlmeXz4xMZThwuHAhLuabWgaomg97cFZ12B 3KV8IA2WATnP7m+aHN7UhgOud18W/0ItdJVExCR2ZlbGhswHmylkKevqAqk5jhQG5Lc1 GBDwLrUybpO+i30hOiPLOxkdnH9834AVwsOZxQn4SDFTxYZktNe6bfzSpZXQTjFNetFB nLHS9OuyNKpcugkPZf1GjRMkSV06lNE8cmzN+VnyMvMyZ4f6PU173U+1km1eunKnG9yp Pl2Q== Received: by 10.43.92.67 with SMTP id bp3mr7501524icc.16.1341287965760; Mon, 02 Jul 2012 20:59:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.56.99 with HTTP; Mon, 2 Jul 2012 20:58:55 -0700 (PDT) In-Reply-To: References: From: Haiwei Xue Date: Mon, 2 Jul 2012 23:58:55 -0400 Message-ID: To: decade@ietf.org Content-Type: multipart/alternative; boundary=bcaec5186a16bd9bd304c3e4f0bb Subject: [decade] Fwd: [yale_lans] Decade naming req 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, 03 Jul 2012 03:59:20 -0000 --bcaec5186a16bd9bd304c3e4f0bb Content-Type: text/plain; charset=ISO-8859-1 Dear list The follows are my comments on the split of req's related with naming in -req and -arch. Thanks. ---------- Forwarded message ---------- From: Haiwei Xue Date: Mon, Jul 2, 2012 at 5:04 PM Subject: Re: [yale_lans] Decade naming req To: yale_lans@googlegroups.com Cc: Ning Zong Hi Richard, I have dug out all the naming requirements in the two documents: In -req: R1. DECADE-compatible protocol must support naming scheme. R2. Naming scheme should keep uniqueness. R3. Naming operations on diverse DECADE-compatible servers should have no coordination. R4. Naming scheme should provide collision handling mechanism. R5. DECADE-compatible server SHOULD be able to give a respond to DECADE-compatible client to indicate the result of naming operation. In -arch A1. Should be able to validate Name-object binding A2. Should support different binding validation A3. Content Distribution Applications can decide which validation to use. A4. App. can be able to construct unique names without coordination. A5. Names should be self-describing. A6. Names should be Uniqueness A7. Names should be Flexibility. A8. Naming scheme SHOULD provide the (following) elements A8-1. A "type" field that indicates the name-object validation function type. A8-2. Cryptographic data (such as an object hash) that corresponds to the type information A8-3. Application or publisher information. A9. Should make object visible in the namespace as soon as they are created (not closed) A10. Not sure yet. ( I don't fully understand the last paragraph of Sec.4.4 in -arch. ) Base on these requirements. I would like to give the following comments: 1. A1, A2, A3 are talking about the same quesion: validation. I think A1 and A2 are more general, A3 is somehow in detail, So How about move A1 and A2 to -req. 2. R3, A4 are talking naming should independent without coordination of servers or applications. I would like to merge the two requirements move put it into -req. 3. A5, A6 and A7 are more general, so it may be better to move them to -req. 4. A8, A8-1, A8-2 and A8-3 are talking about elements in naming 'field'. These requirements may stay in -arch, and I don't think it is essential to mention 'elements' in -req, because everybody know that naming scheme should provide some 'elements ' to carry on some specific information. 5. A9 is general, and it is better to move it to -req. 6. R1-5 are good I think, you can leave them in -req. But you may need merge some of them with requirements in -arch. E.g. R2 can merger with A6. BTW: I like the way you call the naming problem: name-object binding. But the term 'name-object binding' are first appeared in -arch. I think it may be better to give a clear definition of naming problem by using 'name-object binding'. Thanks. Haiwei On Mon, Jul 2, 2012 at 10:26 AM, Y. Richard Yang wrote: > Hi Haiwei, Peng, > > Are you able to help with the split of req's related with naming in -req > and -arch? General reqs should be in -req (before design), and specific > reqs in -arch as they depend on a particular arch. What do you think?n > > Can you send out a proposal by Tuesday? > > Thanks! > > Richard > --bcaec5186a16bd9bd304c3e4f0bb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Dear list
=A0
The follows are my comments on = the split of req's related with naming in -req and -arch.

Thanks.

---------- Forwarded m= essage ----------
From: Haiwei Xue <= heavyxue@gmail.com>
Date: Mon, Jul 2, 2012 at 5:04 PM
Subject: Re: [yale_lans] Decade naming req
To: yale_lans@googlegroups.com
Cc= : Ning Zong <zo= ngning@huawei.com>


Hi Richard,

I have dug out all the naming req= uirements in the two documents:

In -req:

R1.=A0DECADE-compatible protocol must support naming scheme= .

R2. Naming scheme should keep=A0uniqueness.
<= br>
R3. Naming operations on diverse=A0DECADE-compatible=A0server= s should have no coordination.

R4.=A0Naming scheme= should provide=A0collision handling=A0mechanism.

R5.=A0DECADE-compatible server SHOULD be able to give a= respond=A0to DECADE-compatible client to=A0indicate the result of naming o= peration.

In -arch

A1. Sh= ould be able to validate Name-object binding

A2. Should support different binding validation

A3. Content Distribution Applications can decide which va= lidation to use.

A4. App. can be able to construct= unique names without coordination.

A5. Names should be self-describing.

A6.=A0Names should be=A0Uniqueness

A7.=A0Na= mes should be=A0Flexibility.

A8. Naming scheme SHO= ULD provide the (following)=A0elements

A8-1.=A0A "type" field that indicates the nam= e-object validation function=A0type.

A8-2.=A0Crypt= ographic data (such as an object hash) that corresponds to=A0the type infor= mation=A0

A8-3.=A0Application or publisher information.

A9. Should make object visible in the namespace as soon as = they are created (not closed)

A10. Not sure yet. (= I don't fully understand the last paragraph of Sec.4.4 in -arch. )

Base on these requirements. I would like to give the fo= llowing comments:

1.=A0A1, A2, A3 are talking abou= t the same quesion: validation. I think A1 and A2 are more general, A3 is s= omehow in detail, So How about move A1 and A2 to -req.

2. R3, A4 are talking naming should independent=A0witho= ut coordination of servers or applications. I would like to merge the two= =A0requirements move put it into -req.

3. A5, A6 a= nd A7 are more general, so it may be better to move them to -req.

4. A8, A8-1, =A0A8-2 and A8-3 are talking about element= s in naming 'field'. These=A0requirements=A0may stay in -arch, and = I don't think it is essential to mention 'elements' in -req, be= cause everybody know that=A0naming=A0scheme should provide some 'elemen= ts=A0' to carry on some specific information.

5. A9 is general, and it is better to move it to -req.<= /div>

6. R1-5 are good I think, you can leave them in -r= eq. But you may need merge some of them with requirements in -arch. E.g. R2= can merger with A6.

BTW: I like the way you call the naming problem:=A0name= -object binding. But the term 'name-object binding' are first=A0app= eared in -arch. I think it may be better to give a clear=A0definition of na= ming problem by using 'name-object binding'.

Thanks.

Haiwei




<= /div>



On Mon, Jul 2, 2012 at 10:26 AM, Y. Richard Yang <= ;yry@cs.yale.edu&g= t; wrote:
Hi Haiwei, Peng,

Are you able to help with the split of req's related with namin= g in -req and -arch? General reqs should be in -req (before design), and sp= ecific reqs in -arch as they depend on a particular arch. What do you think= ?n

Can you send out a proposal by Tuesday?

<= /div>
Thanks!

Ri= chard


--bcaec5186a16bd9bd304c3e4f0bb-- From pzhang.thu@gmail.com Mon Jul 2 21:34:00 2012 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 671D511E811D for ; Mon, 2 Jul 2012 21:34:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.845 X-Spam-Level: X-Spam-Status: No, score=-1.845 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, 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 yc6bXZO8WoME for ; Mon, 2 Jul 2012 21:33:59 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7C6A711E80EC for ; Mon, 2 Jul 2012 21:33:59 -0700 (PDT) Received: by qcac10 with SMTP id c10so2616629qca.31 for ; Mon, 02 Jul 2012 21:34:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:reply-to:subject:x-priority:x-guid:x-mailer :mime-version:message-id:content-type; bh=xFezk3n5cEkJP/Oe+9Z+lW4efFv0jiQkU4W7i59gsxA=; b=rPo3nmk50APZPFcwBumM8/adjwELglUNb+0W6Nh20gLncHceZwgxlELqlxt8nIT8Nr qPGbSQiutH1vOevhDnksZ09m2YH9lI6fIEoKAd6oR1BMhQO7jVLTbDnXmaz6J0TjCTyQ 5RP1xeIpjztesTyr+Wv9Dg0Lc7FVBWm7096P3Mxy3lO3ckrtX8Yww8qGLdhUX9G9Qo0F QualAzwgyG9hDE4IqRrnPMbqpB8N6c83DSDs0hfvJ2WM4nNcBKQcKD5m0RslRaXhEddx 1mzWrrEQafi3F+yWYuMkJGBY02uW6K7fTyJJ7kxvUcb7rbH7rJvjRcxMY+gWjAtlTj51 beJw== Received: by 10.224.175.8 with SMTP id v8mr16537379qaz.47.1341290046051; Mon, 02 Jul 2012 21:34:06 -0700 (PDT) Received: from pzhang-PC (dhcp-130-132-249-182.central.yale.edu. [130.132.249.182]) by mx.google.com with ESMTPS id u20sm306689qao.16.2012.07.02.21.34.04 (version=SSLv3 cipher=OTHER); Mon, 02 Jul 2012 21:34:05 -0700 (PDT) Date: Tue, 3 Jul 2012 00:34:02 -0500 From: "Zhang Peng" To: "DECADE@ietf.org" X-Priority: 3 X-GUID: 2FB1883D-F73F-4DA5-868C-C6154AFEE9D3 X-Mailer: Foxmail 7.0.1.81[cn] Mime-Version: 1.0 Message-ID: <20120703003402663560214@gmail.com> Content-Type: multipart/alternative; boundary="----=_001_NextPart873856303855_=----" Subject: [decade] Object naming in -req and -arch X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "pzhang.thu" 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, 03 Jul 2012 04:34:00 -0000 This is a multi-part message in MIME format. ------=_001_NextPart873856303855_=---- Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: base64 RGVhciBERUNBREUgcGFydGljaXBhbnRzLA0KDQpBcyBwb2ludGVkIG91dCBieSBSaWNoYXJkIGlu IHByZXZpb3VzIGRpc2N1c3Npb25zLCBib3RoIHRoZSAtcmVxIGFuZCAtYXJjaCBkb2N1bWVudHMg aGFzIHNvbWUgcGFyYWdyYXBocyBkZXNjcmliaW5nIGNvbnRlbnQgbmFtaW5nLCBhbmQgdGhleSBu ZWVkIGJldHRlciBvcmdhbml6YXRpb246IHNvbWUgZ2VuZXJpYyByZXF1aXJlbWVudHMgc2hvdWxk IGJlIGluIC1yZXEsIHdoaWxlIHNvbWUgbW9yZSBzcGVjaWZpYyBvbmVzIHNob3VsZCBiZSBpbiAt YXJjaC4gSGVyZSBhcmUgc29tZSBzdWdnZXN0aW9ucyBhYm91dCBob3cgdG8gc3BsaXQgdGhlIGNv bnRlbnQgb24gbmFtaW5nIGluIHRoZXNlIHR3byBkb2N1bWVudHMuIA0KDQpUaGUgcmF0aW9uYWxl IGZvciB0aGUgZm9sbG93aW5nIHNwbGl0IGlzIHRoYXQgSSByZWNvZ25pemUgdGhlcmUgYXJlIHR3 byBnZW5lcmljIHJlcXVpcmVtZW50cywgdGhhdCBpcywgdW5pcXVlbmVzcywgYW5kIGJpbmRpbmcg dmFsaWRhdGlvbi4gVGhleSBzaG91bGQgYmUgcGxhY2VkIGluIHRoZSAtcmVxLiBJbiAtYXJjaCwg d2Ugc2hvdWxkIHByZXNlbnQgdGhlIHNwZWNpZmljIHJlcXVpcmVtZW50cyB0byBlbmFibGUgdW5p cXVlbmVzcywgYW5kIGJpbmRpbmcgdmFsaWRhdGlvbiwgcmVzcGVjdGl2ZWx5LiBUaGVyZSBhcmUg YWxzbyBzb21lIG1vcmUgcmVxdWlyZW1lbnRzIG9uIGhvdyB0byBpbXByb3ZlIHRoZSByZXNwb25z aXZlbmVzcyBvZiB0aGUgc3lzdGVtLCBpLmUuLCB0aGUgc3VwcG9ydCBvZiBlYXJseSBuYW1lIGdl bmVyYXRpb24uIFNlZSBiZWxvdyBmb3IgZGV0YWlscyAocmVmZXJlbmNlcyB0byB0aGUgb3JpZ2lu YWwgZG9jdW1lbnRzIGFyZSBnaXZlbiBhZnRlciBlYWNoIHNwZWNpZmljIHJlcXVpcmVtZW50cyk6 DQoNCkdlbmVyaWMgcmVxdWlyZW1lbnRzICh0byBiZSBwdXQgaW4gLXJlcSkNCg0KMS4gSXQgU0hP VUxEIGVuc3VyZSB0aGF0IHVuaXF1ZW5lc3Mgb2Ygb2JqZWN0IG5hbWVzLiANCjIuIEl0IFNIT1VM RCBzdXBwb3J0IHRoZSB2YWxpZGF0aW9uIG9mIG5hbWUtb2JqZWN0IGJpbmRpbmcuDQozLiBJdCBT SE9VTEQgc3VwcG9ydCB0aGUgb3BlcmF0aW9uIG9mIERFQ0FERS1jb21wYXRpYmxlIHNlcnZlcnMg dW5kZXIgZGl2ZXJzZSBhZG1pbmlzdHJhdGl2ZSBkb21haW5zIHdpdGggbm8gY29vcmRpbmF0aW9u LiAobm90IHN1cmUgYWJvdXQgd2hhdCBvcGVyYXRpb25zIGFyZSBtZWFudCBoZXJlKQ0KDQpTcGVj aWZpYyByZXF1aXJlbWVudHMgKHRvIGJlIHB1dCBpbiAtYXJjaCkNCg0KUmVxdWlyZW1lbnRzIHRv IGVuYWJsZSB1bmlxdWVuZXNzOiANCjEuIEl0IE1BWSBlbmFibGUgYXBwbGljYXRpb25zIHRvIGNv bnN0cnVjdCB1bmlxdWUgbmFtZXMgYnkgdGhlbXNlbHZlcyB3aXRoIGEgaGlnaCBwcm9iYWJpbGl0 eSAocmVmOiBsYXN0IHNlbnRlbmNlLCBwcC4gMTEsIC1hcmNoKS4gSWYgdGhpcyBpcyB0aGUgY2Fz ZSwgaXQgU0hPVUxEIGluZGljYXRlIGNvbmZsaWN0cyB3aGVuIGR1cGxpY2F0ZSBuYW1lcyBhcmUg Y29uc3RydWN0ZWQgKHJlZjogZmlyc3QgcGFyYSwgNC41LjEsIC1yZXEpLg0KMi4gSXQgTUFZIHN1 cHBvcnQgY29udGVudC1kZXBlbmRlbnQgaGFzaC1iYXNlZCBzY2hlbWVzIChmb3IgZ2VuZXJhbCBp bW11dGFibGUgb2JqZWN0cyksIGFuZCBjb250ZW50LWluZGVwZW5kZW50IGVudW1lcmF0aW9uLWJh c2VkIHNjaGVtZXMgKGZvciBsaXZlIHN0cmVhbWluZykgDQoocmVmOiAybmQgcGFyYSwgcHAuIDEy LCAtYXJjaCkNCg0KUmVxdWlyZW1lbnRzIHRvIGVuYWJsZSBuYW1lLW9iamVjdCBiaW5kaW5nIHZh bGlkYXRpb246DQozLiBEaWZmZXJlbnQgbmFtZS1vYmplY3QgYmluZGluZyB2YWxpZGF0aW9uIG1l Y2hhbmlzbXMgTUFZIGJlIHN1cHBvcnRlZCwgYW5kIGFuIGFwcGxpY2F0aW9uIGNhbiBkZWNpZGUg d2hpY2ggbWVjaGFuaXNtIHRvIHVzZS4gKHJlZjogMm5kIHBhcmEsIDQuNCwgLWFyY2gpDQo0LiBO YW1lcyBNQVkgYmUgc2VsZi1kZXNjcmliaW5nIHNvIHRoYXQgYSByZWNlaXZpbmcgZW50aXR5IChD b250ZW50IENvbnN1bWVyKSBrbm93cyB3aGljaCBtZWNoYW5pc20gaXMgdXNlZCAocmVmOiAxc3Qg cGFyYSwgcHAuIDEyLCAtYXJjaCkNCjUuIEl0IFNIT1VMRCBwcm92aWRlIHRoZSBmb2xsb3dpbmcg bmFtZSBlbGVtZW50czogKDEpIEEgInR5cGUiIGZpZWxkLCAoMikgQ3J5cHRvZ3JhcGhpYyBkYXRh LCAoMykgQXBwbGljYXRpb24gb3IgcHVibGlzaGVyIGluZm9ybWF0aW9uLiAocmVmOiBwcC4gMTIs IC1hcmNoKQ0KDQpNb3JlIHJlcXVpcmVtZW50cyBhYm91dCBwZXJmb3JtYW5jZToNCjYuIEl0IFNI T1VMRCBzdXBwb3J0IHRoZSBzY2VuYXJpb3Mgd2hlcmUgYSBjbGllbnQgbmVlZHMgdG8ga25vdyB0 aGUgbmFtZSBvZiBhIGRhdGEgb2JqZWN0IGJlZm9yZSBpdCBpcyBjb21wbGV0ZWx5IHN0b3JlZCBh dCB0aGUgc2VydmVyLiAoVGhpcyBpcyB0byBsZXQgY2xpZW50cyBhZHZlcnRpc2UgdGhlIG9iamVj dCBiZWZvcmUgaGF2aW5nIGZ1bGx5IHVwbG9hZGVkIGl0KSAocmVmOiBzZWNvbmQgbGFzdCBwYXJh LCBwcC4gMTIsIC1hcmNoKQ0KNy4gSXQgU0hPVUxEIHN1cHBvcnQgdGhlIHNjZW5hcmlvcyB3aGVy ZSBhIGNsaWVudCBuZWVkIHRvIGtub3cgdGhlIG5hbWUgb2YgYSBkYXRhIG9iamVjdCBiZWZvcmUg aXQgaXMgbG9jYWxseSBjcmVhdGVkLiAoVGhpcyBpcyB0byBzdXBwb3J0IGxpdmUgc3RyZWFtaW5n KSAocmVmOiBsYXN0IHBhcmEsIHBwLiAxMiwgLWFyY2gpDQoNCkFueSBjb21tZW50cyBhcmUgd2Vs Y29tZSwgdGhhbmtzLg0KDQpQZW5nLg== ------=_001_NextPart873856303855_=---- Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear DECADE participants,
 
As pointed out by Richard in previous discussions, both the = ;-req=20 and -arch documents has some paragraphs describing content naming, and they need better=20 organization: some generic requirements should be in -req, while some more= =20 specific ones should be in -arch. Here are some suggestions about how to s= plit=20 the content on naming in these two documents.
 
The rationale for the following split is that I recognize there = are=20 two generic requirements, that is, uniqueness, and binding validation. The= y=20 should be placed in the -req. In -arch, we should present the specifi= c=20 requirements to enable uniqueness, and binding validation,=20 respectively. There are also some more requirements on how to improve= the=20 responsiveness of the system, i.e., the support of early name generation.=20 See below for details (references to the original documents are given= after=20 each specific requirements):
 
Generic requirements (to be put in -req)
 
1. It SHOULD ensure that uniquenes= s=20 of object names.
2. It SHOULD support the validatio= n of=20 name-object binding.
3. It SHOULD support the operation of=20 DECADE-compatible servers under diverse administrative domains with no coordination. (not = sure=20 about what operations are meant here)
 
Specific requirements (to be put in -arch)
 
Requirements to enable uniqueness:
1. It MAY enable applications to construct unique names by themselves= with=20 a high probability (ref: last sentence, pp. 11, -arch). If this is the cas= e, it=20 SHOULD indicate conflicts when duplicate names are constructed (ref: first= para,=20 4.5.1, -req).
2. It MAY support content-dependent hash-based schemes (for general=20 immutable objects), and content-independent enumeration-based schemes = ;(for=20 live streaming) 
(ref: 2nd para, pp. 12, -arch)
 
Requirements to enable name-object binding validation:
3. Different name-object binding validation mechanisms MAY be=20 supported, and an application can decide which mechanism to use. (ref: 2nd= para,=20 4.4, -arch)
4. Names MAY be self-describing so that a receiving entity (Content=20 Consumer) knows which mechanism is used (ref: 1st para, pp. 12, -arch)
5. It SHOULD provide the following name elements: (1) A "type" field,= (2)=20 Cryptographic data, (3) Application or publisher information. (ref: pp. 12= ,=20 -arch)
 
More requirements about performance:
6. It SHOULD support the scenarios where a client needs to know the n= ame of=20 a data object before it is completely stored at the server. (This is to le= t=20 clients advertise the object before having fully uploaded it) (ref: second= last=20 para, pp. 12, -arch)
7. It SHOULD support the scenarios where a client need to know=20 the name of a data object before it&nbs= p;is locally created.=20 (This is to support live streaming) (ref: last para, pp. 12, -arch)
<= /DIV>
 
Any comments are welcome, thanks.
 
Peng.
 
 
------=_001_NextPart873856303855_=------ From stephen.farrell@cs.tcd.ie Tue Jul 3 01:26:58 2012 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 589D521F8789 for ; Tue, 3 Jul 2012 01:26:58 -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 a6yqQwMAYBeX for ; Tue, 3 Jul 2012 01:26:44 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 1AC6321F84D5 for ; Tue, 3 Jul 2012 01:26:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 0E0AE171819; Tue, 3 Jul 2012 09:26:48 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1341304007; bh=UpD24TuK1/A9W8 k9cA844lhaetWbaZpHh7n0VwvclqE=; b=BifknSeDCfciFlOHtQVB/Uz0O1tKMF xyqfvtAXkBlt6OSkVoQglydH59fxU0/fw8IaOXzCltajdkHr/tVzQVpasIOCsfXq XbEvUyzRXDqgazxGNu1/R1sm7J0b+RQ5cJHrVF9qt9SFSnp3SGgEI6jRqfZb59r3 ao4ncejtqI+cuT0YVajwhcGifJhnpKanokJxDiVrWDKtVuESAx2J91bc5i2NNZs4 +ba5es6z9D1MfrK+QqEOYHbfaDFc7S0P/THSclsHGb7LWQ7PwYFeACtVS3trUAOr 5syEt9LTn8vj4+Q5mizwe7c4KYX273Uld1sSERc9ZK2jjuG03EbjE/PA== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id k+lp8mMapkpn; Tue, 3 Jul 2012 09:26:47 +0100 (IST) Received: from [192.168.88.68] (089-101-131130.ntlworld.ie [89.101.131.130]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 86BEA171838; Tue, 3 Jul 2012 09:26:43 +0100 (IST) Message-ID: <4FF2ACC3.1020004@cs.tcd.ie> Date: Tue, 03 Jul 2012 09:26:43 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: "pzhang.thu" References: <20120703003402663560214@gmail.com> In-Reply-To: <20120703003402663560214@gmail.com> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "DECADE@ietf.org" Subject: Re: [decade] Object naming in -req and -arch 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, 03 Jul 2012 08:26:58 -0000 Hiya, I guess I hope that our draft (just exited IETF LC) meets these requirements. If not, I'd be interested in what's missing. Cheers, S. [1] http://tools.ietf.org/html/draft-farrell-decade-ni On 07/03/2012 06:34 AM, Zhang Peng wrote: > Dear DECADE participants, > > As pointed out by Richard in previous discussions, both the -req and -arch documents has some paragraphs describing content naming, and they need better organization: some generic requirements should be in -req, while some more specific ones should be in -arch. Here are some suggestions about how to split the content on naming in these two documents. > > The rationale for the following split is that I recognize there are two generic requirements, that is, uniqueness, and binding validation. They should be placed in the -req. In -arch, we should present the specific requirements to enable uniqueness, and binding validation, respectively. There are also some more requirements on how to improve the responsiveness of the system, i.e., the support of early name generation. See below for details (references to the original documents are given after each specific requirements): > > Generic requirements (to be put in -req) > > 1. It SHOULD ensure that uniqueness of object names. > 2. It SHOULD support the validation of name-object binding. > 3. It SHOULD support the operation of DECADE-compatible servers under diverse administrative domains with no coordination. (not sure about what operations are meant here) > > Specific requirements (to be put in -arch) > > Requirements to enable uniqueness: > 1. It MAY enable applications to construct unique names by themselves with a high probability (ref: last sentence, pp. 11, -arch). If this is the case, it SHOULD indicate conflicts when duplicate names are constructed (ref: first para, 4.5.1, -req). > 2. It MAY support content-dependent hash-based schemes (for general immutable objects), and content-independent enumeration-based schemes (for live streaming) > (ref: 2nd para, pp. 12, -arch) > > Requirements to enable name-object binding validation: > 3. Different name-object binding validation mechanisms MAY be supported, and an application can decide which mechanism to use. (ref: 2nd para, 4.4, -arch) > 4. Names MAY be self-describing so that a receiving entity (Content Consumer) knows which mechanism is used (ref: 1st para, pp. 12, -arch) > 5. It SHOULD provide the following name elements: (1) A "type" field, (2) Cryptographic data, (3) Application or publisher information. (ref: pp. 12, -arch) > > More requirements about performance: > 6. It SHOULD support the scenarios where a client needs to know the name of a data object before it is completely stored at the server. (This is to let clients advertise the object before having fully uploaded it) (ref: second last para, pp. 12, -arch) > 7. It SHOULD support the scenarios where a client need to know the name of a data object before it is locally created. (This is to support live streaming) (ref: last para, pp. 12, -arch) > > Any comments are welcome, thanks. > > Peng. > From haibin.song@huawei.com Tue Jul 3 20:31:09 2012 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 3BC4B11E80EA for ; Tue, 3 Jul 2012 20:31:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.2 X-Spam-Level: X-Spam-Status: No, score=-6.2 tagged_above=-999 required=5 tests=[AWL=0.399, 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 Xtrlpt7LXXWX for ; Tue, 3 Jul 2012 20:31:08 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 99C9611E80E9 for ; Tue, 3 Jul 2012 20:31:08 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AHR75626; Tue, 03 Jul 2012 23:31:18 -0400 (EDT) Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 3 Jul 2012 20:30:09 -0700 Received: from SZXEML423-HUB.china.huawei.com (10.82.67.162) by dfweml407-hub.china.huawei.com (10.193.5.132) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 3 Jul 2012 20:30:13 -0700 Received: from SZXEML534-MBX.china.huawei.com ([169.254.2.243]) by szxeml423-hub.china.huawei.com ([10.82.67.162]) with mapi id 14.01.0323.003; Wed, 4 Jul 2012 11:29:44 +0800 From: Songhaibin To: "decade@ietf.org" Thread-Topic: Skip Vancouver meeting Thread-Index: Ac1ZlUFPUFsFOro2R0W8lFYqJ2aynQ== Date: Wed, 4 Jul 2012 03:29:45 +0000 Message-ID: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.73] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [decade] Skip Vancouver meeting 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, 04 Jul 2012 03:31:09 -0000 Dear folks, As there are not many open issues on the current deliverables of DECADE WG,= the working group is NOT going to have a meeting in Vancouver. But if you = are interested in joining a side meeting for a next step discussion, please= contact the chairs. BR, -Haibin (as a co-chair) From wangdanhua@huawei.com Wed Jul 4 02:14:43 2012 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 2B7A521F873E for ; Wed, 4 Jul 2012 02:14:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.924 X-Spam-Level: X-Spam-Status: No, score=-1.924 tagged_above=-999 required=5 tests=[AWL=-4.374, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, 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 GZx7VMGwHFIA for ; Wed, 4 Jul 2012 02:14:42 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 172D621F8720 for ; Wed, 4 Jul 2012 02:14:42 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AHR91847; Wed, 04 Jul 2012 05:14:52 -0400 (EDT) Received: from DFWEML403-HUB.china.huawei.com (10.193.5.151) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 4 Jul 2012 02:14:25 -0700 Received: from SZXEML416-HUB.china.huawei.com (10.82.67.155) by dfweml403-hub.china.huawei.com (10.193.5.151) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 4 Jul 2012 02:14:18 -0700 Received: from SZXEML507-MBS.china.huawei.com ([169.254.7.110]) by szxeml416-hub.china.huawei.com ([10.82.67.155]) with mapi id 14.01.0323.003; Wed, 4 Jul 2012 17:14:14 +0800 From: Wangdanhua To: pzhang.thu , "DECADE@ietf.org" Thread-Topic: [decade] Object naming in -req and -arch Thread-Index: AQHNWNUbyNbHw+cbqUmayHoYgFM2YJcY0BzA Date: Wed, 4 Jul 2012 09:14:13 +0000 Message-ID: References: <20120703003402663560214@gmail.com> In-Reply-To: <20120703003402663560214@gmail.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.177] Content-Type: multipart/alternative; boundary="_000_AFD688AF30E249418739DBDC55B9C75B34D62851SZXEML507MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [decade] =?gb2312?b?tPC4tDogIE9iamVjdCBuYW1pbmcgaW4gLXJlcSBhbmQg?= =?gb2312?b?LWFyY2g=?= 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, 04 Jul 2012 09:14:43 -0000 --_000_AFD688AF30E249418739DBDC55B9C75B34D62851SZXEML507MBSchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgUGVuZywNCg0KQXMgdG8gUTIsIEkgYWdyZWUgd2l0aCB5b3UgdGhhdCB0aGUgY29udGVudCBu YW1pbmcgcmVxdWlyZW1lbnQgcGFydCBpbiCoQ2FyY2ggaGFkIGJldHRlciBiZSBtb3ZlZCB0byCo Q3JlcSwgYW5kIHRoZSChsGltbXV0YWJsZSBkYXRhIG9iamVjdKGxIHNob3VsZCBiZSByZW1haW5l ZCBpbiCoQ2FyY2guDQoNCkFzIHRvIHRoZSBnZW5lcmljIHJlcXVpcmVtZW50cyB2cy4gc3BlY2lm aWMgcmVxdWlyZW1lbnRzIHlvdSBlbnVtZXJhdGVkLCBJoa9tIGEgbGl0dGxlIGNvbmZ1c2VkLiBG b3IgZXhhbXBsZSwgYXMgdG8gdGhlIKGwUmVxdWlyZW1lbnRzIHRvIGVuYWJsZSB1bmlxdWVuZXNz obEsIEkgdGhpbmsgobBpdCBTSE9VTEQgaW5kaWNhdGUgY29uZmxpY3RzIHdoZW4gZHVwbGljYXRl IG5hbWVzIGFyZSBjb25zdHJ1Y3RlZCAocmVmOiBmaXJzdCBwYXJhLCA0LjUuMSwgLXJlcSmhsSBp cyBhbHNvIHRoZSBkZXRhaWxlZCBkZXNjcmlwdGlvbi9kZW1hbmQgb2YgdGhlIGdlbmVyaWMgcmVx dWlyZW1lbnQgobBlbnN1cmUgdGhlIHVuaXF1ZW5lc3Mgb2Ygb2JqZWN0IG5hbWVzobEuIEluIG15 IG9waW5pb24sIHN1Y2ggcmVxdWlyZW1lbnRzIHNob3VsZCBhbHNvIGJlIHByZXNlbnRlZCBpbiCo Q3JlcS4gSSB3b25kZXIgaWYgbXkgdW5kZXJzdGFuZGluZyBpcyByaWdodC4NCg0KQmVzdCB3aXNo ZXMsDQpEYW5odWENCg0KDQq3orz+yMs6IGRlY2FkZS1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86 ZGVjYWRlLWJvdW5jZXNAaWV0Zi5vcmddILT6se0gWmhhbmcgUGVuZw0Kt6LLzcqxvOQ6IDIwMTLE 6jfUwjPI1SAxMzozNA0KytW8/sjLOiBERUNBREVAaWV0Zi5vcmcNCtb3zOI6IFtkZWNhZGVdIE9i amVjdCBuYW1pbmcgaW4gLXJlcSBhbmQgLWFyY2gNCg0KRGVhciBERUNBREUgcGFydGljaXBhbnRz LA0KDQpBcyBwb2ludGVkIG91dCBieSBSaWNoYXJkIGluIHByZXZpb3VzIGRpc2N1c3Npb25zLCBi b3RoIHRoZSAtcmVxIGFuZCAtYXJjaCBkb2N1bWVudHMgaGFzIHNvbWUgcGFyYWdyYXBocyBkZXNj cmliaW5nIGNvbnRlbnQgbmFtaW5nLCBhbmQgdGhleSBuZWVkIGJldHRlciBvcmdhbml6YXRpb246 IHNvbWUgZ2VuZXJpYyByZXF1aXJlbWVudHMgc2hvdWxkIGJlIGluIC1yZXEsIHdoaWxlIHNvbWUg bW9yZSBzcGVjaWZpYyBvbmVzIHNob3VsZCBiZSBpbiAtYXJjaC4gSGVyZSBhcmUgc29tZSBzdWdn ZXN0aW9ucyBhYm91dCBob3cgdG8gc3BsaXQgdGhlIGNvbnRlbnQgb24gbmFtaW5nIGluIHRoZXNl IHR3byBkb2N1bWVudHMuDQoNClRoZSByYXRpb25hbGUgZm9yIHRoZSBmb2xsb3dpbmcgc3BsaXQg aXMgdGhhdCBJIHJlY29nbml6ZSB0aGVyZSBhcmUgdHdvIGdlbmVyaWMgcmVxdWlyZW1lbnRzLCB0 aGF0IGlzLCB1bmlxdWVuZXNzLCBhbmQgYmluZGluZyB2YWxpZGF0aW9uLiBUaGV5IHNob3VsZCBi ZSBwbGFjZWQgaW4gdGhlIC1yZXEuIEluIC1hcmNoLCB3ZSBzaG91bGQgcHJlc2VudCB0aGUgc3Bl Y2lmaWMgcmVxdWlyZW1lbnRzIHRvIGVuYWJsZSB1bmlxdWVuZXNzLCBhbmQgYmluZGluZyB2YWxp ZGF0aW9uLCByZXNwZWN0aXZlbHkuIFRoZXJlIGFyZSBhbHNvIHNvbWUgbW9yZSByZXF1aXJlbWVu dHMgb24gaG93IHRvIGltcHJvdmUgdGhlIHJlc3BvbnNpdmVuZXNzIG9mIHRoZSBzeXN0ZW0sIGku ZS4sIHRoZSBzdXBwb3J0IG9mIGVhcmx5IG5hbWUgZ2VuZXJhdGlvbi4gU2VlIGJlbG93IGZvciBk ZXRhaWxzIChyZWZlcmVuY2VzIHRvIHRoZSBvcmlnaW5hbCBkb2N1bWVudHMgYXJlIGdpdmVuIGFm dGVyIGVhY2ggc3BlY2lmaWMgcmVxdWlyZW1lbnRzKToNCg0KR2VuZXJpYyByZXF1aXJlbWVudHMg KHRvIGJlIHB1dCBpbiAtcmVxKQ0KDQoxLiBJdCBTSE9VTEQgZW5zdXJlIHRoYXQgdW5pcXVlbmVz cyBvZiBvYmplY3QgbmFtZXMuDQoyLiBJdCBTSE9VTEQgc3VwcG9ydCB0aGUgdmFsaWRhdGlvbiBv ZiBuYW1lLW9iamVjdCBiaW5kaW5nLg0KMy4gSXQgU0hPVUxEIHN1cHBvcnQgdGhlIG9wZXJhdGlv biBvZiBERUNBREUtY29tcGF0aWJsZSBzZXJ2ZXJzIHVuZGVyIGRpdmVyc2UgYWRtaW5pc3RyYXRp dmUgZG9tYWlucyB3aXRoIG5vIGNvb3JkaW5hdGlvbi4gKG5vdCBzdXJlIGFib3V0IHdoYXQgb3Bl cmF0aW9ucyBhcmUgbWVhbnQgaGVyZSkNCg0KU3BlY2lmaWMgcmVxdWlyZW1lbnRzICh0byBiZSBw dXQgaW4gLWFyY2gpDQoNClJlcXVpcmVtZW50cyB0byBlbmFibGUgdW5pcXVlbmVzczoNCjEuIEl0 IE1BWSBlbmFibGUgYXBwbGljYXRpb25zIHRvIGNvbnN0cnVjdCB1bmlxdWUgbmFtZXMgYnkgdGhl bXNlbHZlcyB3aXRoIGEgaGlnaCBwcm9iYWJpbGl0eSAocmVmOiBsYXN0IHNlbnRlbmNlLCBwcC4g MTEsIC1hcmNoKS4gSWYgdGhpcyBpcyB0aGUgY2FzZSwgaXQgU0hPVUxEIGluZGljYXRlIGNvbmZs aWN0cyB3aGVuIGR1cGxpY2F0ZSBuYW1lcyBhcmUgY29uc3RydWN0ZWQgKHJlZjogZmlyc3QgcGFy YSwgNC41LjEsIC1yZXEpLg0KMi4gSXQgTUFZIHN1cHBvcnQgY29udGVudC1kZXBlbmRlbnQgaGFz aC1iYXNlZCBzY2hlbWVzIChmb3IgZ2VuZXJhbCBpbW11dGFibGUgb2JqZWN0cyksIGFuZCBjb250 ZW50LWluZGVwZW5kZW50IGVudW1lcmF0aW9uLWJhc2VkIHNjaGVtZXMgKGZvciBsaXZlIHN0cmVh bWluZykNCihyZWY6IDJuZCBwYXJhLCBwcC4gMTIsIC1hcmNoKQ0KDQpSZXF1aXJlbWVudHMgdG8g ZW5hYmxlIG5hbWUtb2JqZWN0IGJpbmRpbmcgdmFsaWRhdGlvbjoNCjMuIERpZmZlcmVudCBuYW1l LW9iamVjdCBiaW5kaW5nIHZhbGlkYXRpb24gbWVjaGFuaXNtcyBNQVkgYmUgc3VwcG9ydGVkLCBh bmQgYW4gYXBwbGljYXRpb24gY2FuIGRlY2lkZSB3aGljaCBtZWNoYW5pc20gdG8gdXNlLiAocmVm OiAybmQgcGFyYSwgNC40LCAtYXJjaCkNCjQuIE5hbWVzIE1BWSBiZSBzZWxmLWRlc2NyaWJpbmcg c28gdGhhdCBhIHJlY2VpdmluZyBlbnRpdHkgKENvbnRlbnQgQ29uc3VtZXIpIGtub3dzIHdoaWNo IG1lY2hhbmlzbSBpcyB1c2VkIChyZWY6IDFzdCBwYXJhLCBwcC4gMTIsIC1hcmNoKQ0KNS4gSXQg U0hPVUxEIHByb3ZpZGUgdGhlIGZvbGxvd2luZyBuYW1lIGVsZW1lbnRzOiAoMSkgQSAidHlwZSIg ZmllbGQsICgyKSBDcnlwdG9ncmFwaGljIGRhdGEsICgzKSBBcHBsaWNhdGlvbiBvciBwdWJsaXNo ZXIgaW5mb3JtYXRpb24uIChyZWY6IHBwLiAxMiwgLWFyY2gpDQoNCk1vcmUgcmVxdWlyZW1lbnRz IGFib3V0IHBlcmZvcm1hbmNlOg0KNi4gSXQgU0hPVUxEIHN1cHBvcnQgdGhlIHNjZW5hcmlvcyB3 aGVyZSBhIGNsaWVudCBuZWVkcyB0byBrbm93IHRoZSBuYW1lIG9mIGEgZGF0YSBvYmplY3QgYmVm b3JlIGl0IGlzIGNvbXBsZXRlbHkgc3RvcmVkIGF0IHRoZSBzZXJ2ZXIuIChUaGlzIGlzIHRvIGxl dCBjbGllbnRzIGFkdmVydGlzZSB0aGUgb2JqZWN0IGJlZm9yZSBoYXZpbmcgZnVsbHkgdXBsb2Fk ZWQgaXQpIChyZWY6IHNlY29uZCBsYXN0IHBhcmEsIHBwLiAxMiwgLWFyY2gpDQo3LiBJdCBTSE9V TEQgc3VwcG9ydCB0aGUgc2NlbmFyaW9zIHdoZXJlIGEgY2xpZW50IG5lZWQgdG8ga25vdyB0aGUg bmFtZSBvZiBhIGRhdGEgb2JqZWN0IGJlZm9yZSBpdCBpcyBsb2NhbGx5IGNyZWF0ZWQuIChUaGlz IGlzIHRvIHN1cHBvcnQgbGl2ZSBzdHJlYW1pbmcpIChyZWY6IGxhc3QgcGFyYSwgcHAuIDEyLCAt YXJjaCkNCg0KQW55IGNvbW1lbnRzIGFyZSB3ZWxjb21lLCB0aGFua3MuDQoNClBlbmcuDQoNCg0K --_000_AFD688AF30E249418739DBDC55B9C75B34D62851SZXEML507MBSchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi= Peng,

 

As= to Q2, I agree with you that the content naming requirement part in =A8Carch had be= tter be moved to =A8Creq, and th= e =A1=B0immutable= data object=A1=B1 should be remained in =A8Carch.

 

As= to the generic requirements vs. specific requirements you enumerated, I=A1=AFm a little confused. For example, as to the =A1=B0Requirements to enable uniqueness=A1=B1, I think =A1=B0= it SHOULD indicate conflicts when duplicate names are constructed (ref: fir= st para, 4.5.1, -req)=A1=B1 is also the detailed description/demand of the generic requirement = =A1=B0ensure the uniqu= eness of object names=A1=B1. In my opinion, such requirements should also be presented in =A8Creq. I wonder i= f my understanding is right.

 =

Best wishes,=

Danhua=

 =

 =

=B7=A2=BC=FE=C8=CB: decade-bounces@ietf.org [mailto:decade-bo= unces@ietf.org] =B4=FA= =B1=ED Zhang Peng
=B7=A2= =CB=CD=CA=B1=BC=E4: 2012=C4=EA7=D4=C23=C8=D5 13:34
=CA=D5=BC=FE=C8=CB: DECADE@ietf.org
=D6=F7=CC=E2: [decade] Object naming in -req and -arch

 

Dear DECADE participants,

 

As pointed out by Richard in previous discu= ssions, both the -req and -arch documents has some para= graphs describing content naming, and they need better organization: some = generic requirements should be in -req, while some more specific ones shoul= d be in -arch. Here are some suggestions about how to split the content on = naming in these two documents.

 

The rationale for the following split is th= at I recognize there are two generic requirements, that is, uniqueness, and binding validation. They should be placed in the -req.&nbs= p;In -arch, we should present the specific requirements to enable uniq= ueness, and binding validation, respectively. There are also some more= requirements on how to improve the responsiveness of the system, i.e., the support of early name generation. See below = for details (references to the original documents are given after each spec= ific requirements):

 

Generic requirements (to be put in -req)

 

1. It SHOULD ensure that uniqueness of object names.

2. It SHOULD support the validation of name-object binding.

3. It SHOULD support the operation of DECADE= -compatible servers under diverse administrative domains with no coordination. (not sure about what operations are meant here)

 

Specific requirements (to be put in -arch)<= o:p>

 

Requirements to enable uniqueness:

1. It MAY enable applications to construct = unique names by themselves with a high probability (ref: last sentence, pp. 11, -arch). If this is the case, it SHOULD indicate conflict= s when duplicate names are constructed (ref: first para, 4.5.1, -req).=

2. It MAY support content-dependent hash-ba= sed schemes (for general immutable objects), and content-independent enumeration-based schemes (for live streaming) 

(ref: 2nd para, pp. 12, -arch)

 

Requirements to enable name-object binding = validation:

3. Different name-object binding validation= mechanisms MAY be supported, and an application can decide which mechanism to use. (ref: 2nd para, 4.4, -arch)

4. Names MAY be self-describing so that a r= eceiving entity (Content Consumer) knows which mechanism is used (ref: 1st para, pp. 12, -arch)

5. It SHOULD provide the following name ele= ments: (1) A "type" field, (2) Cryptographic data, (3) Applicatio= n or publisher information. (ref: pp. 12, -arch)

 

More requirements about performance:

6. It SHOULD support the scenarios where a = client needs to know the name of a data object before it is completely stored at the server. (This is to let clients advertise the obj= ect before having fully uploaded it) (ref: second last para, pp. 12, -arch)=

7. It SHOULD support the scenarios whe= re a client need to know the name of a data object=  before it is locally created. (This is to support live streaming) (ref: last para, pp. 12, -arch)

 

Any comments are welcome, thanks.

 

Peng.

 

 

--_000_AFD688AF30E249418739DBDC55B9C75B34D62851SZXEML507MBSchi_-- From pzhang.thu@gmail.com Wed Jul 4 11:23:56 2012 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 82AF621F869F for ; Wed, 4 Jul 2012 11:23:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.803 X-Spam-Level: * X-Spam-Status: No, score=1.803 tagged_above=-999 required=5 tests=[AWL=-3.647, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1, 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 RmC3HA+Wkiyy for ; Wed, 4 Jul 2012 11:23:55 -0700 (PDT) Received: from mail-qa0-f44.google.com (mail-qa0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4CB2521F869C for ; Wed, 4 Jul 2012 11:23:55 -0700 (PDT) Received: by qadz3 with SMTP id z3so3352901qad.10 for ; Wed, 04 Jul 2012 11:24:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:reply-to:subject:references:x-priority:x-guid:x-mailer :mime-version:message-id:content-type; bh=Vi/TrSYBLPqH/yKXm6wKn69+aMchgMzxqbiSmG/PM0k=; b=c78bfA2VezEfkhS7dux0WYyg9KidJWHjH/PQN+oOGqpG5wZ+6X6L4ZxTSqIbL3fQyC ymGr0JE+Q7iF0SDJQtGosvRx9EuoIfkRRkYbKqxKlK9MU1tZNoxeghHdOEGesoHu6S7M 7/OeepjbBtxSxmhigr8zBno/gVTQFmlX1xXaP2naolo0m/vbZmoGvyc3kyo2pA+DTGTo lFe1gel0z6R1gWWZv+Rvi8R76P0l9UFscrCYGcwGFr05ykqyPLtupPucIZMDjuENl2Co x7pKYRWkpATs/4L72+naPqoCCdceVokhNzh/0pknENtnDoU4m60PMkWiRe9hNFe/8Qna hnmw== Received: by 10.224.191.3 with SMTP id dk3mr39748218qab.99.1341426246121; Wed, 04 Jul 2012 11:24:06 -0700 (PDT) Received: from pzhang-PC (dhcp-130-132-249-182.central.yale.edu. [130.132.249.182]) by mx.google.com with ESMTPS id eb10sm687964qab.4.2012.07.04.11.24.05 (version=SSLv3 cipher=OTHER); Wed, 04 Jul 2012 11:24:05 -0700 (PDT) Date: Wed, 4 Jul 2012 14:24:04 -0400 From: "Zhang Peng" To: Wangdanhua , "DECADE@ietf.org" References: <20120703003402663560214@gmail.com>, X-Priority: 3 X-GUID: 1C9DE152-BB6E-4A87-83CE-9E194F199F92 X-Mailer: Foxmail 7.0.1.81[cn] Mime-Version: 1.0 Message-ID: <20120704142404303001237@gmail.com> Content-Type: multipart/alternative; boundary="----=_001_NextPart158640653382_=----" Subject: [decade] =?gb2312?b?u9i4tDogtPC4tDogIE9iamVjdCBuYW1pbmcgaW4gLXJl?= =?gb2312?b?cSBhbmQgLWFyY2g=?= X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "pzhang.thu" 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, 04 Jul 2012 18:23:56 -0000 This is a multi-part message in MIME format. ------=_001_NextPart158640653382_=---- Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgRGFuaHVhLA0KDQpUaGFua3MgZm9yIHlvdXIgY29tbWVudHMuIEkgdGhpbmsgeW91ciBjb21t ZW50cyBhcmUgdmVyeSByZWFzb25hYmxlLiBCdXQgSSBzdGlsbCB0aGluayB0aGUgcmVxdWlyZW1l bnQgIkl0IE1BWSBlbmFibGUgYXBwbGljYXRpb25zIHRvIGNvbnN0cnVjdCB1bmlxdWUgbmFtZXMg dy5oLnAuIiArICJ0aGUgbmFtaW5nIHNjaGVtZSBzaG91bGQgaW5kaWNhdGVkIGNvbmZsaWN0cyIg aXMganVzdCBvbmUgYXBwcm9hY2ggdG8gZW5zdXJlIHVuaXF1ZW5lc3MuIEl0IGlzIGJlY2F1c2Ug d2UgY2FuIGFsc28gbGV0IHRoZSBERUNBREUgc2VydmljZSBwcm92aWRlcnMgYXNzaWduIHRoZSBu YW1lIHRvIGVuc3VyZSB1bmlxdWVuZXNzLiBUaHVzLCBJIHRoaW5rIHdlIGJldHRlciBqdXN0IHN0 YXRlIHRoZSBnZW5lcmljIHJlcXVpcmVtZW50IHRoYXQgIm5hbWVzIHNob3VsZCBiZSB1bmlxdWUi IHdpdGhvdXQgZ29pbmcgaW50byBkZXRhaWxzIG9mIHRoZSBkZXNpZ24gaW4gLXJlcSwgYW5kIGdp dmUgdGhlIGRldGFpbGVkIHJlcXVpcmVtZW50cyBmb3Igb3VyIGRlc2lnbiAoaS5lLiwgZW5hYmxl IGFwcHMgdG8gZ2l2ZW4gbmFtZXMgdy5oLnAuLCBhbmQgaW5kaWNhdGUgY29uZmxpY3RzIHdoZW4g bmVjZXNzYXJ5KSBpbiAtYXJjaC4gV2hhdCB3b3VsZCB5b3UgdGhpbms/IA0KDQpUaGFua3MsDQoN ClBlbmcuICANCg0Kt6K8/sjLo7ogV2FuZ2Rhbmh1YQ0Kt6LLzcqxvOSjuiAyMDEyLTA3LTA0IDA1 OjE0DQrK1bz+yMujuiBwemhhbmcudGh1OyBERUNBREVAaWV0Zi5vcmcNCtb3zOKjuiC08Li0OiBb ZGVjYWRlXSBPYmplY3QgbmFtaW5nIGluIC1yZXEgYW5kIC1hcmNoDQpIaSBQZW5nLA0KIA0KQXMg dG8gUTIsIEkgYWdyZWUgd2l0aCB5b3UgdGhhdCB0aGUgY29udGVudCBuYW1pbmcgcmVxdWlyZW1l bnQgcGFydCBpbiCoQ2FyY2ggaGFkIGJldHRlciBiZSBtb3ZlZCB0byCoQ3JlcSwgYW5kIHRoZSCh sGltbXV0YWJsZSBkYXRhIG9iamVjdKGxIHNob3VsZCBiZSByZW1haW5lZCBpbiCoQ2FyY2guDQog DQpBcyB0byB0aGUgZ2VuZXJpYyByZXF1aXJlbWVudHMgdnMuIHNwZWNpZmljIHJlcXVpcmVtZW50 cyB5b3UgZW51bWVyYXRlZCwgSaGvbSBhIGxpdHRsZSBjb25mdXNlZC4gRm9yIGV4YW1wbGUsIGFz IHRvIHRoZSChsFJlcXVpcmVtZW50cyB0byBlbmFibGUgdW5pcXVlbmVzc6GxLCBJIHRoaW5rIKGw aXQgU0hPVUxEIGluZGljYXRlIGNvbmZsaWN0cyB3aGVuIGR1cGxpY2F0ZSBuYW1lcyBhcmUgY29u c3RydWN0ZWQgKHJlZjogZmlyc3QgcGFyYSwgNC41LjEsIC1yZXEpobEgaXMgYWxzbyB0aGUgZGV0 YWlsZWQgZGVzY3JpcHRpb24vZGVtYW5kIG9mIHRoZSBnZW5lcmljIHJlcXVpcmVtZW50IKGwZW5z dXJlIHRoZSB1bmlxdWVuZXNzIG9mIG9iamVjdCBuYW1lc6GxLiBJbiBteSBvcGluaW9uLCBzdWNo IHJlcXVpcmVtZW50cyBzaG91bGQgYWxzbyBiZSBwcmVzZW50ZWQgaW4gqENyZXEuIEkgd29uZGVy IGlmIG15IHVuZGVyc3RhbmRpbmcgaXMgcmlnaHQuDQogDQpCZXN0IHdpc2hlcywNCkRhbmh1YQ0K IA0KIA0Kt6K8/sjLOiBkZWNhZGUtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmRlY2FkZS1ib3Vu Y2VzQGlldGYub3JnXSC0+rHtIFpoYW5nIFBlbmcNCreiy83KsbzkOiAyMDEyxOo31MIzyNUgMTM6 MzQNCsrVvP7IyzogREVDQURFQGlldGYub3JnDQrW98ziOiBbZGVjYWRlXSBPYmplY3QgbmFtaW5n IGluIC1yZXEgYW5kIC1hcmNoDQogDQpEZWFyIERFQ0FERSBwYXJ0aWNpcGFudHMsIA0KIA0KQXMg cG9pbnRlZCBvdXQgYnkgUmljaGFyZCBpbiBwcmV2aW91cyBkaXNjdXNzaW9ucywgYm90aCB0aGUg LXJlcSBhbmQgLWFyY2ggZG9jdW1lbnRzIGhhcyBzb21lIHBhcmFncmFwaHMgZGVzY3JpYmluZyBj b250ZW50IG5hbWluZywgYW5kIHRoZXkgbmVlZCBiZXR0ZXIgb3JnYW5pemF0aW9uOiBzb21lIGdl bmVyaWMgcmVxdWlyZW1lbnRzIHNob3VsZCBiZSBpbiAtcmVxLCB3aGlsZSBzb21lIG1vcmUgc3Bl Y2lmaWMgb25lcyBzaG91bGQgYmUgaW4gLWFyY2guIEhlcmUgYXJlIHNvbWUgc3VnZ2VzdGlvbnMg YWJvdXQgaG93IHRvIHNwbGl0IHRoZSBjb250ZW50IG9uIG5hbWluZyBpbiB0aGVzZSB0d28gZG9j dW1lbnRzLiANCiANClRoZSByYXRpb25hbGUgZm9yIHRoZSBmb2xsb3dpbmcgc3BsaXQgaXMgdGhh dCBJIHJlY29nbml6ZSB0aGVyZSBhcmUgdHdvIGdlbmVyaWMgcmVxdWlyZW1lbnRzLCB0aGF0IGlz LCB1bmlxdWVuZXNzLCBhbmQgYmluZGluZyB2YWxpZGF0aW9uLiBUaGV5IHNob3VsZCBiZSBwbGFj ZWQgaW4gdGhlIC1yZXEuIEluIC1hcmNoLCB3ZSBzaG91bGQgcHJlc2VudCB0aGUgc3BlY2lmaWMg cmVxdWlyZW1lbnRzIHRvIGVuYWJsZSB1bmlxdWVuZXNzLCBhbmQgYmluZGluZyB2YWxpZGF0aW9u LCByZXNwZWN0aXZlbHkuIFRoZXJlIGFyZSBhbHNvIHNvbWUgbW9yZSByZXF1aXJlbWVudHMgb24g aG93IHRvIGltcHJvdmUgdGhlIHJlc3BvbnNpdmVuZXNzIG9mIHRoZSBzeXN0ZW0sIGkuZS4sIHRo ZSBzdXBwb3J0IG9mIGVhcmx5IG5hbWUgZ2VuZXJhdGlvbi4gU2VlIGJlbG93IGZvciBkZXRhaWxz IChyZWZlcmVuY2VzIHRvIHRoZSBvcmlnaW5hbCBkb2N1bWVudHMgYXJlIGdpdmVuIGFmdGVyIGVh Y2ggc3BlY2lmaWMgcmVxdWlyZW1lbnRzKToNCiANCkdlbmVyaWMgcmVxdWlyZW1lbnRzICh0byBi ZSBwdXQgaW4gLXJlcSkNCiANCjEuIEl0IFNIT1VMRCBlbnN1cmUgdGhhdCB1bmlxdWVuZXNzIG9m IG9iamVjdCBuYW1lcy4gDQoyLiBJdCBTSE9VTEQgc3VwcG9ydCB0aGUgdmFsaWRhdGlvbiBvZiBu YW1lLW9iamVjdCBiaW5kaW5nLg0KMy4gSXQgU0hPVUxEIHN1cHBvcnQgdGhlIG9wZXJhdGlvbiBv ZiBERUNBREUtY29tcGF0aWJsZSBzZXJ2ZXJzIHVuZGVyIGRpdmVyc2UgYWRtaW5pc3RyYXRpdmUg ZG9tYWlucyB3aXRoIG5vIGNvb3JkaW5hdGlvbi4gKG5vdCBzdXJlIGFib3V0IHdoYXQgb3BlcmF0 aW9ucyBhcmUgbWVhbnQgaGVyZSkNCiANClNwZWNpZmljIHJlcXVpcmVtZW50cyAodG8gYmUgcHV0 IGluIC1hcmNoKQ0KIA0KUmVxdWlyZW1lbnRzIHRvIGVuYWJsZSB1bmlxdWVuZXNzOiANCjEuIEl0 IE1BWSBlbmFibGUgYXBwbGljYXRpb25zIHRvIGNvbnN0cnVjdCB1bmlxdWUgbmFtZXMgYnkgdGhl bXNlbHZlcyB3aXRoIGEgaGlnaCBwcm9iYWJpbGl0eSAocmVmOiBsYXN0IHNlbnRlbmNlLCBwcC4g MTEsIC1hcmNoKS4gSWYgdGhpcyBpcyB0aGUgY2FzZSwgaXQgU0hPVUxEIGluZGljYXRlIGNvbmZs aWN0cyB3aGVuIGR1cGxpY2F0ZSBuYW1lcyBhcmUgY29uc3RydWN0ZWQgKHJlZjogZmlyc3QgcGFy YSwgNC41LjEsIC1yZXEpLg0KMi4gSXQgTUFZIHN1cHBvcnQgY29udGVudC1kZXBlbmRlbnQgaGFz aC1iYXNlZCBzY2hlbWVzIChmb3IgZ2VuZXJhbCBpbW11dGFibGUgb2JqZWN0cyksIGFuZCBjb250 ZW50LWluZGVwZW5kZW50IGVudW1lcmF0aW9uLWJhc2VkIHNjaGVtZXMgKGZvciBsaXZlIHN0cmVh bWluZykgDQoocmVmOiAybmQgcGFyYSwgcHAuIDEyLCAtYXJjaCkNCiANClJlcXVpcmVtZW50cyB0 byBlbmFibGUgbmFtZS1vYmplY3QgYmluZGluZyB2YWxpZGF0aW9uOg0KMy4gRGlmZmVyZW50IG5h bWUtb2JqZWN0IGJpbmRpbmcgdmFsaWRhdGlvbiBtZWNoYW5pc21zIE1BWSBiZSBzdXBwb3J0ZWQs IGFuZCBhbiBhcHBsaWNhdGlvbiBjYW4gZGVjaWRlIHdoaWNoIG1lY2hhbmlzbSB0byB1c2UuIChy ZWY6IDJuZCBwYXJhLCA0LjQsIC1hcmNoKQ0KNC4gTmFtZXMgTUFZIGJlIHNlbGYtZGVzY3JpYmlu ZyBzbyB0aGF0IGEgcmVjZWl2aW5nIGVudGl0eSAoQ29udGVudCBDb25zdW1lcikga25vd3Mgd2hp Y2ggbWVjaGFuaXNtIGlzIHVzZWQgKHJlZjogMXN0IHBhcmEsIHBwLiAxMiwgLWFyY2gpDQo1LiBJ dCBTSE9VTEQgcHJvdmlkZSB0aGUgZm9sbG93aW5nIG5hbWUgZWxlbWVudHM6ICgxKSBBICJ0eXBl IiBmaWVsZCwgKDIpIENyeXB0b2dyYXBoaWMgZGF0YSwgKDMpIEFwcGxpY2F0aW9uIG9yIHB1Ymxp c2hlciBpbmZvcm1hdGlvbi4gKHJlZjogcHAuIDEyLCAtYXJjaCkNCiANCk1vcmUgcmVxdWlyZW1l bnRzIGFib3V0IHBlcmZvcm1hbmNlOg0KNi4gSXQgU0hPVUxEIHN1cHBvcnQgdGhlIHNjZW5hcmlv cyB3aGVyZSBhIGNsaWVudCBuZWVkcyB0byBrbm93IHRoZSBuYW1lIG9mIGEgZGF0YSBvYmplY3Qg YmVmb3JlIGl0IGlzIGNvbXBsZXRlbHkgc3RvcmVkIGF0IHRoZSBzZXJ2ZXIuIChUaGlzIGlzIHRv IGxldCBjbGllbnRzIGFkdmVydGlzZSB0aGUgb2JqZWN0IGJlZm9yZSBoYXZpbmcgZnVsbHkgdXBs b2FkZWQgaXQpIChyZWY6IHNlY29uZCBsYXN0IHBhcmEsIHBwLiAxMiwgLWFyY2gpDQo3LiBJdCBT SE9VTEQgc3VwcG9ydCB0aGUgc2NlbmFyaW9zIHdoZXJlIGEgY2xpZW50IG5lZWQgdG8ga25vdyB0 aGUgbmFtZSBvZiBhIGRhdGEgb2JqZWN0IGJlZm9yZSBpdCBpcyBsb2NhbGx5IGNyZWF0ZWQuIChU aGlzIGlzIHRvIHN1cHBvcnQgbGl2ZSBzdHJlYW1pbmcpIChyZWY6IGxhc3QgcGFyYSwgcHAuIDEy LCAtYXJjaCkNCiANCkFueSBjb21tZW50cyBhcmUgd2VsY29tZSwgdGhhbmtzLg0KIA0KUGVuZy4N CiANCiA= ------=_001_NextPart158640653382_=---- Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
Hi Danhua,
 
Thanks for your comments. I think your com= ments=20 are very reasonable. But I still think the requirement "It MAY enable=20 applications to construct unique names w.h.p." + "the naming scheme should= =20 indicated conflicts" is just one approach to ensure uniqueness. It is= =20 because we can also let the DECADE service providers assign the name = to=20 ensure uniqueness. Thus, I think we better just state = the=20 generic requirement that "names should be unique" without going into=20 details of the design in -req, and give the detailed requirements for= our=20 design (i.e., enable apps to given names w.h.p., and indicate conflicts wh= en=20 necessary) in -arch. What would you think?
 
Thanks,
 
Peng.  
 
=B7=A2=BC=FE=C8=CB=A3=BA Wangdanhua
=B7=A2=CB=CD=CA=B1=BC=E4=A3=BA 2012-07-04 05:14
=CA=D5=BC=FE=C8=CB=A3=BA pzhang.thu; DECADE@ietf.org
=D6=F7=CC=E2=A3=BA =B4=F0=B8=B4: [decade] Object naming i= n -req and=20 -arch

Hi=20 Peng,

&nb= sp;

As to Q2= , I agree with you=20 that the content naming requirement part in =A8Carch had better be moved to =A8Creq, and the =A1=B0immutable data object=A1=B1=20 should be remained in =A8Carch.

&nb= sp;

As to th= e generic=20 requirements vs. specific requirements you enumerated, I=A1=AFm a litt= le confused. For=20 example, as to the =A1= =B0Requirem= ents to enable=20 uniqueness=A1=B1, I thin= k =A1=B0it SHOUL= D indicate conflicts=20 when duplicate names are constructed (ref: first para, 4.5.1, -req)= =A1=B1 is also= the detailed=20 description/demand of the generic requirement =A1=B0ensure t= he uniqueness of=20 object names=A1=B1. In my = opinion, such=20 requirements should also be presented in =A8Creq. I wonder=20 if my understanding is right.

 

Best wishes,

Danhua

 

 

=B7=A2=BC=FE=C8=CB: decade-bounces@ietf.org [mailto:decade-bounces@ietf.org]=20 =B4= =FA=B1=ED Zhang=20 Peng
=B7=A2=CB=CD=CA=B1=BC=E4: 2012=C4=EA7=D4=C23=C8=D5=20 13:34
=CA=D5=BC=FE=C8=CB:=20 DECADE@ietf.org
=D6=F7=CC=E2:=20 [decade] Object naming in -req and=20 -arch

 

Dear DECADE participants,

 

As pointed out by Richard in previous discussions, both=20 the -req and -arch documents has some paragraphs describing= =20 content naming, and they need better organization: some generic=20 requirements should be in -req, while some more specific ones should be in= =20 -arch. Here are some suggestions about how to split the content on naming = in=20 these two documents.

 

The rationale for the following split is that I recogniz= e there=20 are two generic requirements, that is, uniqueness, and binding validation.= They=20 should be placed in the -req. In -arch, we should present the specifi= c=20 requirements to enable uniqueness, and binding validation,=20 respectively. There are also some more requirements on how to improve= the=20 responsiveness of the system, i.e., the support of early name generation.=20 See below for details (references to the original documents are given= after=20 each specific requirements):

 

Generic requirements (to be put in -req)

 

1. It SHOULD ensure that uniqueness of object names.=20

2. It SHOULD support the validation of name-object=20 binding.

3. It SHOULD support the operation of DECADE-compatible serve= rs under=20 diverse administrative domains with no coordination. (not sure abou= t what=20 operations are meant here)

 

Specific requirements (to be put in=20 -arch)

 

Requirements to enable uniqueness:

1. It MAY enable applications to construct unique names by th= emselves=20 with a high probability (ref: last sentence, pp. 11, -arch). If this is th= e=20 case, it SHOULD indicate conflicts when duplicate names are constructed (r= ef:=20 first para, 4.5.1, -req).

2. It MAY support content-dependent hash-based schemes (for g= eneral=20 immutable objects), and content-independent enumeration-based schemes = ;(for=20 live streaming) 

(ref: 2nd para, pp. 12, -arch)

 

Requirements to enable name-object binding=20 validation:

3. Different name-object binding validation mechanisms M= AY be=20 supported, and an application can decide which mechanism to use. (ref: 2nd= para,=20 4.4, -arch)

4. Names MAY be self-describing so that a receiving entity (C= ontent=20 Consumer) knows which mechanism is used (ref: 1st para, pp. 12,=20 -arch)

5. It SHOULD provide the following name elements: (1) A "type= " field,=20 (2) Cryptographic data, (3) Application or publisher information. (ref: pp= . 12,=20 -arch)

 

More requirements about performance:

6. It SHOULD support the scenarios where a client needs to kn= ow the=20 name of a data object before it is completely stored at the server. (This = is to=20 let clients advertise the object before having fully uploaded it) (ref: se= cond=20 last para, pp. 12, -arch)

7. It SHOULD support the scenarios where a client need t= o know=20 the name of a data object before it&nbs= p;is locally created.=20 (This is to support live streaming) (ref: last para, pp. 12,=20 -arch)

 

Any comments are welcome, thanks.

 

Peng.

 

 

------=_001_NextPart158640653382_=------ From pzhang.thu@gmail.com Wed Jul 4 13:05:33 2012 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 CD89E21F85D5 for ; Wed, 4 Jul 2012 13:05:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.329 X-Spam-Level: X-Spam-Status: No, score=-0.329 tagged_above=-999 required=5 tests=[AWL=0.916, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_63=0.6, MIME_BASE64_TEXT=1.753, 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 rcYvmDshbqgn for ; Wed, 4 Jul 2012 13:05:32 -0700 (PDT) Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id 92A4A21F85D4 for ; Wed, 4 Jul 2012 13:05:32 -0700 (PDT) Received: by qaea16 with SMTP id a16so3388177qae.10 for ; Wed, 04 Jul 2012 13:05:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:reply-to:subject:references:x-priority:x-guid :x-mailer:mime-version:message-id:content-type; bh=898PWlKOeAx2hnhOOqRSLE3m8oqEzwcnQDgEFv+GL6I=; b=Yto8fsRkycqn0zyo4idvx+cqLTJlpMgmsduibRud8ooVp6zMrx4HUj6KbCMJgPB3eI hMN7IaaUARAWUYzIzo/okckWv0Otg60StAS+ktJA+mghRHH+0TWGhFbzaej3yKlujr5E ASflzuTgXfhWjso4UrkbkoA2+Aeo1r2FZVQKgkG4VIaS19T0UW0S9l9dXP+5rd5P+4dl 7eRcH885IrEVkyWGRYzlq2vuD8TzP2i7Wj8Hrd1aTh5fznZvCmb9yokKpS78amU3SzZP YSpq7byTk6fxGnSRKlNObDkFS5xicLxwSKCK49ujtUoSwK5OyVAddxdaL7qZROy5BtQp Vygw== Received: by 10.224.178.141 with SMTP id bm13mr25666294qab.28.1341432343341; Wed, 04 Jul 2012 13:05:43 -0700 (PDT) Received: from pzhang-PC (dhcp-130-132-249-182.central.yale.edu. [130.132.249.182]) by mx.google.com with ESMTPS id bh13sm43367439qab.21.2012.07.04.13.05.42 (version=SSLv3 cipher=OTHER); Wed, 04 Jul 2012 13:05:42 -0700 (PDT) Date: Wed, 4 Jul 2012 16:05:41 -0400 From: "Zhang Peng" To: "Stephen Farrell" References: <20120703003402663560214@gmail.com>, <4FF2ACC3.1020004@cs.tcd.ie> X-Priority: 3 X-GUID: 022BAB15-242B-48C6-B644-6E8ABB7E07B3 X-Mailer: Foxmail 7.0.1.81[cn] Mime-Version: 1.0 Message-ID: <20120704160541638826251@gmail.com> Content-Type: multipart/alternative; boundary="----=_001_NextPart035206176774_=----" Cc: "DECADE@ietf.org" Subject: Re: [decade] Object naming in -req and -arch X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "pzhang.thu" 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, 04 Jul 2012 20:05:34 -0000 This is a multi-part message in MIME format. ------=_001_NextPart035206176774_=---- Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 SGkgU3RlcGhlbiwNCg0KSSBoYXZlIHJlYWQgeW91ciBkb2N1bWVudHMgb24gaGFzaC1iYXNlZCBu YW1pbmcuIEl0IGRlc2lnbnMgYSBnb29kIFVSSSBmb3JtYXQgYW5kIG1hcHBpbmcgc2NoZW1lIHRv IEhUVFAgVVJMLiBGb3IgREVDQURFLCBzaW5jZSBvdXIgcmVxdWlyZW1lbnRzIGluY2x1ZGUgdW5p cXVlbmVzcywgbmFtZS1vYmplY3QgYmluZGluZyB2YWxpZGF0aW9uLCBJIHdvbmRlciBob3cgd2Ug Y2FuIGFwcGx5IHlvdXIgc2NoZW1lIHRvIG1lZXQgdGhlbS4gDQpCVFcsIGNhbiB5b3UgZ2l2ZSBt b3JlIGRldGFpbHMgb24gd2hhdCB5b3UgbWVhbiBieSAibWVldHMgdGhlc2UgcmVxdWlyZW1lbnRz Ij8gVGhhbmtzLg0KDQpCLA0KDQpQZW5nLg0KDQpGcm9tOiBTdGVwaGVuIEZhcnJlbGwNCkRhdGU6 IDIwMTItMDctMDMgMDM6MjYNClRvOiBwemhhbmcudGh1DQpDQzogREVDQURFQGlldGYub3JnDQpT dWJqZWN0OiBSZTogW2RlY2FkZV0gT2JqZWN0IG5hbWluZyBpbiAtcmVxIGFuZCAtYXJjaA0KDQpI aXlhLA0KDQpJIGd1ZXNzIEkgaG9wZSB0aGF0IG91ciBkcmFmdCAoanVzdCBleGl0ZWQgSUVURiBM QykgbWVldHMNCnRoZXNlIHJlcXVpcmVtZW50cy4gSWYgbm90LCBJJ2QgYmUgaW50ZXJlc3RlZCBp biB3aGF0J3MNCm1pc3NpbmcuDQoNCkNoZWVycywNClMuDQoNClsxXSBodHRwOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9kcmFmdC1mYXJyZWxsLWRlY2FkZS1uaQ0KDQpPbiAwNy8wMy8yMDEyIDA2OjM0 IEFNLCBaaGFuZyBQZW5nIHdyb3RlOg0KPiBEZWFyIERFQ0FERSBwYXJ0aWNpcGFudHMsDQo+IA0K PiBBcyBwb2ludGVkIG91dCBieSBSaWNoYXJkIGluIHByZXZpb3VzIGRpc2N1c3Npb25zLCBib3Ro IHRoZSAtcmVxIGFuZCAtYXJjaCBkb2N1bWVudHMgaGFzIHNvbWUgcGFyYWdyYXBocyBkZXNjcmli aW5nIGNvbnRlbnQgbmFtaW5nLCBhbmQgdGhleSBuZWVkIGJldHRlciBvcmdhbml6YXRpb246IHNv bWUgZ2VuZXJpYyByZXF1aXJlbWVudHMgc2hvdWxkIGJlIGluIC1yZXEsIHdoaWxlIHNvbWUgbW9y ZSBzcGVjaWZpYyBvbmVzIHNob3VsZCBiZSBpbiAtYXJjaC4gSGVyZSBhcmUgc29tZSBzdWdnZXN0 aW9ucyBhYm91dCBob3cgdG8gc3BsaXQgdGhlIGNvbnRlbnQgb24gbmFtaW5nIGluIHRoZXNlIHR3 byBkb2N1bWVudHMuIA0KPiANCj4gVGhlIHJhdGlvbmFsZSBmb3IgdGhlIGZvbGxvd2luZyBzcGxp dCBpcyB0aGF0IEkgcmVjb2duaXplIHRoZXJlIGFyZSB0d28gZ2VuZXJpYyByZXF1aXJlbWVudHMs IHRoYXQgaXMsIHVuaXF1ZW5lc3MsIGFuZCBiaW5kaW5nIHZhbGlkYXRpb24uIFRoZXkgc2hvdWxk IGJlIHBsYWNlZCBpbiB0aGUgLXJlcS4gSW4gLWFyY2gsIHdlIHNob3VsZCBwcmVzZW50IHRoZSBz cGVjaWZpYyByZXF1aXJlbWVudHMgdG8gZW5hYmxlIHVuaXF1ZW5lc3MsIGFuZCBiaW5kaW5nIHZh bGlkYXRpb24sIHJlc3BlY3RpdmVseS4gVGhlcmUgYXJlIGFsc28gc29tZSBtb3JlIHJlcXVpcmVt ZW50cyBvbiBob3cgdG8gaW1wcm92ZSB0aGUgcmVzcG9uc2l2ZW5lc3Mgb2YgdGhlIHN5c3RlbSwg aS5lLiwgdGhlIHN1cHBvcnQgb2YgZWFybHkgbmFtZSBnZW5lcmF0aW9uLiBTZWUgYmVsb3cgZm9y IGRldGFpbHMgKHJlZmVyZW5jZXMgdG8gdGhlIG9yaWdpbmFsIGRvY3VtZW50cyBhcmUgZ2l2ZW4g YWZ0ZXIgZWFjaCBzcGVjaWZpYyByZXF1aXJlbWVudHMpOg0KPiANCj4gR2VuZXJpYyByZXF1aXJl bWVudHMgKHRvIGJlIHB1dCBpbiAtcmVxKQ0KPiANCj4gMS4gSXQgU0hPVUxEIGVuc3VyZSB0aGF0 IHVuaXF1ZW5lc3Mgb2Ygb2JqZWN0IG5hbWVzLiANCj4gMi4gSXQgU0hPVUxEIHN1cHBvcnQgdGhl IHZhbGlkYXRpb24gb2YgbmFtZS1vYmplY3QgYmluZGluZy4NCj4gMy4gSXQgU0hPVUxEIHN1cHBv cnQgdGhlIG9wZXJhdGlvbiBvZiBERUNBREUtY29tcGF0aWJsZSBzZXJ2ZXJzIHVuZGVyIGRpdmVy c2UgYWRtaW5pc3RyYXRpdmUgZG9tYWlucyB3aXRoIG5vIGNvb3JkaW5hdGlvbi4gKG5vdCBzdXJl IGFib3V0IHdoYXQgb3BlcmF0aW9ucyBhcmUgbWVhbnQgaGVyZSkNCj4gDQo+IFNwZWNpZmljIHJl cXVpcmVtZW50cyAodG8gYmUgcHV0IGluIC1hcmNoKQ0KPiANCj4gUmVxdWlyZW1lbnRzIHRvIGVu YWJsZSB1bmlxdWVuZXNzOiANCj4gMS4gSXQgTUFZIGVuYWJsZSBhcHBsaWNhdGlvbnMgdG8gY29u c3RydWN0IHVuaXF1ZSBuYW1lcyBieSB0aGVtc2VsdmVzIHdpdGggYSBoaWdoIHByb2JhYmlsaXR5 IChyZWY6IGxhc3Qgc2VudGVuY2UsIHBwLiAxMSwgLWFyY2gpLiBJZiB0aGlzIGlzIHRoZSBjYXNl LCBpdCBTSE9VTEQgaW5kaWNhdGUgY29uZmxpY3RzIHdoZW4gZHVwbGljYXRlIG5hbWVzIGFyZSBj b25zdHJ1Y3RlZCAocmVmOiBmaXJzdCBwYXJhLCA0LjUuMSwgLXJlcSkuDQo+IDIuIEl0IE1BWSBz dXBwb3J0IGNvbnRlbnQtZGVwZW5kZW50IGhhc2gtYmFzZWQgc2NoZW1lcyAoZm9yIGdlbmVyYWwg aW1tdXRhYmxlIG9iamVjdHMpLCBhbmQgY29udGVudC1pbmRlcGVuZGVudCBlbnVtZXJhdGlvbi1i YXNlZCBzY2hlbWVzIChmb3IgbGl2ZSBzdHJlYW1pbmcpIA0KPiAocmVmOiAybmQgcGFyYSwgcHAu IDEyLCAtYXJjaCkNCj4gDQo+IFJlcXVpcmVtZW50cyB0byBlbmFibGUgbmFtZS1vYmplY3QgYmlu ZGluZyB2YWxpZGF0aW9uOg0KPiAzLiBEaWZmZXJlbnQgbmFtZS1vYmplY3QgYmluZGluZyB2YWxp ZGF0aW9uIG1lY2hhbmlzbXMgTUFZIGJlIHN1cHBvcnRlZCwgYW5kIGFuIGFwcGxpY2F0aW9uIGNh biBkZWNpZGUgd2hpY2ggbWVjaGFuaXNtIHRvIHVzZS4gKHJlZjogMm5kIHBhcmEsIDQuNCwgLWFy Y2gpDQo+IDQuIE5hbWVzIE1BWSBiZSBzZWxmLWRlc2NyaWJpbmcgc28gdGhhdCBhIHJlY2Vpdmlu ZyBlbnRpdHkgKENvbnRlbnQgQ29uc3VtZXIpIGtub3dzIHdoaWNoIG1lY2hhbmlzbSBpcyB1c2Vk IChyZWY6IDFzdCBwYXJhLCBwcC4gMTIsIC1hcmNoKQ0KPiA1LiBJdCBTSE9VTEQgcHJvdmlkZSB0 aGUgZm9sbG93aW5nIG5hbWUgZWxlbWVudHM6ICgxKSBBICJ0eXBlIiBmaWVsZCwgKDIpIENyeXB0 b2dyYXBoaWMgZGF0YSwgKDMpIEFwcGxpY2F0aW9uIG9yIHB1Ymxpc2hlciBpbmZvcm1hdGlvbi4g KHJlZjogcHAuIDEyLCAtYXJjaCkNCj4gDQo+IE1vcmUgcmVxdWlyZW1lbnRzIGFib3V0IHBlcmZv cm1hbmNlOg0KPiA2LiBJdCBTSE9VTEQgc3VwcG9ydCB0aGUgc2NlbmFyaW9zIHdoZXJlIGEgY2xp ZW50IG5lZWRzIHRvIGtub3cgdGhlIG5hbWUgb2YgYSBkYXRhIG9iamVjdCBiZWZvcmUgaXQgaXMg Y29tcGxldGVseSBzdG9yZWQgYXQgdGhlIHNlcnZlci4gKFRoaXMgaXMgdG8gbGV0IGNsaWVudHMg YWR2ZXJ0aXNlIHRoZSBvYmplY3QgYmVmb3JlIGhhdmluZyBmdWxseSB1cGxvYWRlZCBpdCkgKHJl Zjogc2Vjb25kIGxhc3QgcGFyYSwgcHAuIDEyLCAtYXJjaCkNCj4gNy4gSXQgU0hPVUxEIHN1cHBv cnQgdGhlIHNjZW5hcmlvcyB3aGVyZSBhIGNsaWVudCBuZWVkIHRvIGtub3cgdGhlIG5hbWUgb2Yg YSBkYXRhIG9iamVjdCBiZWZvcmUgaXQgaXMgbG9jYWxseSBjcmVhdGVkLiAoVGhpcyBpcyB0byBz dXBwb3J0IGxpdmUgc3RyZWFtaW5nKSAocmVmOiBsYXN0IHBhcmEsIHBwLiAxMiwgLWFyY2gpDQo+ IA0KPiBBbnkgY29tbWVudHMgYXJlIHdlbGNvbWUsIHRoYW5rcy4NCj4gDQo+IFBlbmcuDQo+IA== ------=_001_NextPart035206176774_=---- Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Stephen,
 
I have read your documents on hash-based n= aming.=20 It designs a good URI format and mapping scheme to HTTP URL. For DECADE, s= ince=20 our requirements include uniqueness, name-object binding validation, I won= der=20 how we can apply your scheme to meet them.
BTW, can you give more details on what you= mean by=20 "meets these requirements"? Thanks.
 
B,
 
Peng.
 
Date: 2012-07-03 03:26
Subject: Re: [decade] Object naming in -req and=20 -arch
 
Hiya,
 
I guess I hope that our draft (jus= t exited IETF LC) meets
these requirements. If not, I'd be inte= rested in what's
missing.
 
Cheers,
S.
 
[1] http://tools.ietf.org/html/draft-farrell-decade-ni
 
On 07/03/2012 06:34 AM, Zhang Peng wrot= e:
> Dear DECADE participants,
> 
> As pointed out by Richard in = previous discussions, both the -req and -arc= h documents has some paragraphs describing c= ontent naming, and they need better organiza= tion: some generic requirements should be in=  -req, while some more specific ones sh= ould be in -arch. Here are some suggest= ions about how to split the content on&= nbsp;naming in these two documents. 
> 
> The rationale for the following sp= lit is that I recognize there are two&n= bsp;generic requirements, that is, uniqueness, an= d binding validation. They should be placed&= nbsp;in the -req. In -arch, we should p= resent the specific requirements to enable u= niqueness, and binding validation, respectively. = There are also some more requirements on&nbs= p;how to improve the responsiveness of the&n= bsp;system, i.e., the support of early name&= nbsp;generation. See below for details (reference= s to the original documents are given a= fter each specific requirements):
> 
> Generic requirements (to be put in=  -req)
> 
> 1. It SHOULD ensure that uniquenes= s of object names. 
> 2. It SHOULD support the validatio= n of name-object binding.
> 3. It SHOULD support the operation=  of DECADE-compatible servers under diverse = administrative domains with no coordination. (not=  sure about what operations are meant h= ere)
> 
> Specific requirements (to be put i= n -arch)
> 
> Requirements to enable uniqueness: 
> 1. It MAY enable applications to&n= bsp;construct unique names by themselves with&nbs= p;a high probability (ref: last sentence, pp= . 11, -arch). If this is the case, = ;it SHOULD indicate conflicts when duplicate = ;names are constructed (ref: first para, 4.5= .1, -req).
> 2. It MAY support content-dependent&nbs= p;hash-based schemes (for general immutable objec= ts), and content-independent enumeration-based schemes=  (for live streaming) 
> (ref: 2nd para, pp. 12, -arch)
> 
> Requirements to enable name-object bind= ing validation:
> 3. Different name-object binding valida= tion mechanisms MAY be supported, and an&nbs= p;application can decide which mechanism to = use. (ref: 2nd para, 4.4, -arch)
> 4. Names MAY be self-describing so=  that a receiving entity (Content Consumer)&= nbsp;knows which mechanism is used (ref: 1st=  para, pp. 12, -arch)
> 5. It SHOULD provide the following=  name elements: (1) A "type" field, (2)=  Cryptographic data, (3) Application or publ= isher information. (ref: pp. 12, -arch)
> 
> More requirements about performance:
> 6. It SHOULD support the scenarios=  where a client needs to know the = name of a data object before it is = ;completely stored at the server. (This is&n= bsp;to let clients advertise the object befo= re having fully uploaded it) (ref: second&nb= sp;last para, pp. 12, -arch)
> 7. It SHOULD support the scenarios=  where a client need to know the n= ame of a data object before it is = locally created. (This is to support live&nb= sp;streaming) (ref: last para, pp. 12, -arch= )
> 
> Any comments are welcome, thanks.
> 
> Peng.
> 
 
------=_001_NextPart035206176774_=------ From stephen.farrell@cs.tcd.ie Wed Jul 4 14:08:28 2012 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 220EC21F84F3 for ; Wed, 4 Jul 2012 14:08:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_63=0.6, 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 L6+b0wV7A0En for ; Wed, 4 Jul 2012 14:08:27 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 1BD6721F84F6 for ; Wed, 4 Jul 2012 14:08:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 5182815754B; Wed, 4 Jul 2012 22:08:38 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1341436117; bh=5WpOk/pQjplhnU LHvCCFG1+Wwb856N5OXDawBM6TuCg=; b=WMLtKK19IwywfMVnE9kdoN9gmZhU2Y 3RmQ9tyig1Dz3/q1LYaOcFMMBIrhFZGXuVmNi1rh5IxKb+y04FMRS800FFDsyS+X uCg0CtcXMU6YTwmYa+GzQoPOBRbbUEOrX63NVFctS8f0hU6Yv5/xsKVinMMuBbin ey0TiXPjdkb9sX8tvX5MmS34O1M+CCPoyFw0B6qszM3HtIS4u8+ssGm9e1c2U8Mq rKuOIwPKryofewZeVlZbj/22RbmXpEFk4Xs2khlMtHVAUGIfVhfzIZWCqx2IRPhn WUVqRxuPxn0ineYnGr4KL7owhglGB01LCXvYoxAyMmPl0o9UnYvMVfRg== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id N-qqq9HRBzQj; Wed, 4 Jul 2012 22:08:37 +0100 (IST) Received: from [10.87.48.11] (unknown [86.41.15.232]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id B7F0B17147F; Wed, 4 Jul 2012 22:08:37 +0100 (IST) Message-ID: <4FF4B0D5.40906@cs.tcd.ie> Date: Wed, 04 Jul 2012 22:08:37 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: "pzhang.thu" References: <20120703003402663560214@gmail.com>, <4FF2ACC3.1020004@cs.tcd.ie> <20120704160541638826251@gmail.com> In-Reply-To: <20120704160541638826251@gmail.com> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "DECADE@ietf.org" Subject: Re: [decade] Object naming in -req and -arch 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, 04 Jul 2012 21:08:28 -0000 On 07/04/2012 09:05 PM, Zhang Peng wrote: > Hi Stephen, > > I have read your documents on hash-based naming. It designs a good URI format and mapping scheme to HTTP URL. For DECADE, since our requirements include uniqueness, name-object binding validation, I wonder how we can apply your scheme to meet them. ni URIs are as unique as the collision resistance of your hash function supports basically. If you pick sha-256 that won't be an issue. ni URis support name-data integrity (incl. in the code we've released) which I think is the same as what you're calling name-object binding validation. So my answer for both is: just use ni URIs to meet these requirements:-) > BTW, can you give more details on what you mean by "meets these requirements"? Thanks. I meant: if there's some requirement that can't be met using ni URIs, then I'd like to know about that before its too late. (I realise that the decade WG might still change reqs of course but wanted to check now before we're done with our doc.) S > B, > > Peng. > > From: Stephen Farrell > Date: 2012-07-03 03:26 > To: pzhang.thu > CC: DECADE@ietf.org > Subject: Re: [decade] Object naming in -req and -arch > > Hiya, > > I guess I hope that our draft (just exited IETF LC) meets > these requirements. If not, I'd be interested in what's > missing. > > Cheers, > S. > > [1] http://tools.ietf.org/html/draft-farrell-decade-ni > > On 07/03/2012 06:34 AM, Zhang Peng wrote: >> Dear DECADE participants, >> >> As pointed out by Richard in previous discussions, both the -req and -arch documents has some paragraphs describing content naming, and they need better organization: some generic requirements should be in -req, while some more specific ones should be in -arch. Here are some suggestions about how to split the content on naming in these two documents. >> >> The rationale for the following split is that I recognize there are two generic requirements, that is, uniqueness, and binding validation. They should be placed in the -req. In -arch, we should present the specific requirements to enable uniqueness, and binding validation, respectively. There are also some more requirements on how to improve the responsiveness of the system, i.e., the support of early name generation. See below for details (references to the original documents are given after each specific requirements): >> >> Generic requirements (to be put in -req) >> >> 1. It SHOULD ensure that uniqueness of object names. >> 2. It SHOULD support the validation of name-object binding. >> 3. It SHOULD support the operation of DECADE-compatible servers under diverse administrative domains with no coordination. (not sure about what operations are meant here) >> >> Specific requirements (to be put in -arch) >> >> Requirements to enable uniqueness: >> 1. It MAY enable applications to construct unique names by themselves with a high probability (ref: last sentence, pp. 11, -arch). If this is the case, it SHOULD indicate conflicts when duplicate names are constructed (ref: first para, 4.5.1, -req). >> 2. It MAY support content-dependent hash-based schemes (for general immutable objects), and content-independent enumeration-based schemes (for live streaming) >> (ref: 2nd para, pp. 12, -arch) >> >> Requirements to enable name-object binding validation: >> 3. Different name-object binding validation mechanisms MAY be supported, and an application can decide which mechanism to use. (ref: 2nd para, 4.4, -arch) >> 4. Names MAY be self-describing so that a receiving entity (Content Consumer) knows which mechanism is used (ref: 1st para, pp. 12, -arch) >> 5. It SHOULD provide the following name elements: (1) A "type" field, (2) Cryptographic data, (3) Application or publisher information. (ref: pp. 12, -arch) >> >> More requirements about performance: >> 6. It SHOULD support the scenarios where a client needs to know the name of a data object before it is completely stored at the server. (This is to let clients advertise the object before having fully uploaded it) (ref: second last para, pp. 12, -arch) >> 7. It SHOULD support the scenarios where a client need to know the name of a data object before it is locally created. (This is to support live streaming) (ref: last para, pp. 12, -arch) >> >> Any comments are welcome, thanks. >> >> Peng. From pzhang.thu@gmail.com Wed Jul 4 14:40:15 2012 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 A903A11E8089 for ; Wed, 4 Jul 2012 14:40:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.558 X-Spam-Level: X-Spam-Status: No, score=-0.558 tagged_above=-999 required=5 tests=[AWL=0.687, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_63=0.6, MIME_BASE64_TEXT=1.753, 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 Bns6U-2cYfjl for ; Wed, 4 Jul 2012 14:40:14 -0700 (PDT) Received: from mail-qa0-f44.google.com (mail-qa0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id EE92A11E807F for ; Wed, 4 Jul 2012 14:40:13 -0700 (PDT) Received: by qadz3 with SMTP id z3so3416429qad.10 for ; Wed, 04 Jul 2012 14:40:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:reply-to:subject:references:x-priority:x-guid :x-mailer:mime-version:message-id:content-type; bh=Rwr9PJXfCUeKscQa7ZeNTWTyG9CeP8S3ntDpN+QXUkI=; b=umH2g9otwmTey1PHFy1LDzQdORD5FR01QbzMhkjvgIhUgSXqEB+8oSiyYkwfSpMspZ JAlwRRA4Ineg9kcfYnnOohj56+ChMfy2teZJWz+BvsMY4rGEJYmpW+gWXKSeoVq7pgTX /M9+UI1Yy0sHDlnP22iTkyqzOl9hgP3H3WQT4jgud6GL/K3L/uwkaYMmh5QuFbKWzuHA lmmNEGuFRPP2rFl0TuOlaTKEISvpdfuNJ3f1Tds2MvO63hQBYTrOD2u9sdV9sIhGFugv a9HTTbXFaJXalvO01iILTbVMTETAPxWOGjHInVajnP2aoRsryjR2OFMmInPChWazColm XSjg== Received: by 10.224.32.7 with SMTP id a7mr40926870qad.23.1341438024517; Wed, 04 Jul 2012 14:40:24 -0700 (PDT) Received: from pzhang-PC (dhcp-130-132-249-182.central.yale.edu. [130.132.249.182]) by mx.google.com with ESMTPS id cn9sm22635648qab.15.2012.07.04.14.40.23 (version=SSLv3 cipher=OTHER); Wed, 04 Jul 2012 14:40:24 -0700 (PDT) Date: Wed, 4 Jul 2012 17:40:22 -0400 From: "Zhang Peng" To: "Stephen Farrell" References: <20120703003402663560214@gmail.com>, <4FF2ACC3.1020004@cs.tcd.ie> <20120704160541638826251@gmail.com>, <4FF4B0D5.40906@cs.tcd.ie> X-Priority: 3 X-GUID: F9DF7577-1FBA-41C0-9081-EF1F4D8CF170 X-Mailer: Foxmail 7.0.1.81[cn] Mime-Version: 1.0 Message-ID: <20120704174022735010267@gmail.com> Content-Type: multipart/alternative; boundary="----=_001_NextPart347350785854_=----" Cc: "DECADE@ietf.org" Subject: Re: [decade] Object naming in -req and -arch X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "pzhang.thu" 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, 04 Jul 2012 21:40:15 -0000 This is a multi-part message in MIME format. ------=_001_NextPart347350785854_=---- Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 SGkgU3RlcGhlbiwNCg0KWWVzLCBmb3IgbW9zdCBjYXNlcywgaGFzaC1iYXNlZCBuYW1pbmcgc2No ZW1lIGlzIG9rIGZvciBpbi1uZXR3b3JrIHN0b3JhZ2Ugc3lzdGVtIHdoaWNoIGhvbGRzIGltbXV0 YWJsZSBvYmplY3RzLiANCkJ1ciBmb3Igc29tZSBhcHBsaWNhdGlvbiBzdWNoIGFzIGxpdmUgc3Ry ZWFtaW5nLCB3ZSBleHBlY3QgdGhhdCB0aGUgdXBsb2FkZXIvc3RyZWFtZXIgY2FuIGtub3cgdGhl IG9iamVjdCBuYW1lIGJlZm9yZSBpdCB1cGxvYWRzIHRoZSBvYmplY3QgdG8gZGVjYWRlIHNlcnZl ci4gVGhpcyB3aWxsIGFsbG93IHRoZSBzdHJlYW1lciB0byBhZHZlcnRpc2UgdGhlIGZpbGUgYmVm b3JlIGZ1bGx5IHVwbG9hZGluZyBpdCwgYW5kIHRoZW4gdGhlIHZpZXdlciBjYW4gZmV0Y2ggdGhl IG9iamVjdCB1c2luZyB0aGUgYWR2ZXJ0aXNlZCBuYW1lLiBJZiBlYWNoIG9iamVjdCBjb250YWlu cyBzZXZlcmFsIHNlY29uZHMgb2YgdmlkZW8gZGF0YSwgdGhpcyBmZWF0dXJlIGNhbiBjb25zaWRl cmFibHkgcmVkdWNlIHRoZSBsYXRlbmN5LiBUaHVzLCB3ZSBtYXkgbmVlZCBhIGVudW1lcmF0aW9u LWJhc2VkIHNjaGVtZSBiZXNpZGVzIHRoZSBoYXNoLWJhc2VkIG9uZS4gQ2FuIHdlIGFkZCB0aGlz IGZlYXR1cmUgaW4geW91ciBwcm9wb3NlZCBkZXNpZ24/IFRoYW5rcy4NCg0KQiwNCg0KUGVuZy4N Cg0KRnJvbTogU3RlcGhlbiBGYXJyZWxsDQpEYXRlOiAyMDEyLTA3LTA0IDE3OjA4DQpUbzogcHpo YW5nLnRodQ0KQ0M6IERFQ0FERUBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtkZWNhZGVdIE9iamVj dCBuYW1pbmcgaW4gLXJlcSBhbmQgLWFyY2gNCg0KDQpPbiAwNy8wNC8yMDEyIDA5OjA1IFBNLCBa aGFuZyBQZW5nIHdyb3RlOg0KPiBIaSBTdGVwaGVuLA0KPiANCj4gSSBoYXZlIHJlYWQgeW91ciBk b2N1bWVudHMgb24gaGFzaC1iYXNlZCBuYW1pbmcuIEl0IGRlc2lnbnMgYSBnb29kIFVSSSBmb3Jt YXQgYW5kIG1hcHBpbmcgc2NoZW1lIHRvIEhUVFAgVVJMLiBGb3IgREVDQURFLCBzaW5jZSBvdXIg cmVxdWlyZW1lbnRzIGluY2x1ZGUgdW5pcXVlbmVzcywgbmFtZS1vYmplY3QgYmluZGluZyB2YWxp ZGF0aW9uLCBJIHdvbmRlciBob3cgd2UgY2FuIGFwcGx5IHlvdXIgc2NoZW1lIHRvIG1lZXQgdGhl bS4gDQoNCm5pIFVSSXMgYXJlIGFzIHVuaXF1ZSBhcyB0aGUgY29sbGlzaW9uIHJlc2lzdGFuY2Ug b2YgeW91ciBoYXNoDQpmdW5jdGlvbiBzdXBwb3J0cyBiYXNpY2FsbHkuIElmIHlvdSBwaWNrIHNo YS0yNTYgdGhhdCB3b24ndCBiZQ0KYW4gaXNzdWUuDQoNCm5pIFVSaXMgc3VwcG9ydCBuYW1lLWRh dGEgaW50ZWdyaXR5IChpbmNsLiBpbiB0aGUgY29kZSB3ZSd2ZQ0KcmVsZWFzZWQpIHdoaWNoIEkg dGhpbmsgaXMgdGhlIHNhbWUgYXMgd2hhdCB5b3UncmUgY2FsbGluZw0KbmFtZS1vYmplY3QgYmlu ZGluZyB2YWxpZGF0aW9uLg0KDQpTbyBteSBhbnN3ZXIgZm9yIGJvdGggaXM6IGp1c3QgdXNlIG5p IFVSSXMgdG8gbWVldCB0aGVzZQ0KcmVxdWlyZW1lbnRzOi0pDQoNCj4gQlRXLCBjYW4geW91IGdp dmUgbW9yZSBkZXRhaWxzIG9uIHdoYXQgeW91IG1lYW4gYnkgIm1lZXRzIHRoZXNlIHJlcXVpcmVt ZW50cyI/IFRoYW5rcy4NCg0KSSBtZWFudDogaWYgdGhlcmUncyBzb21lIHJlcXVpcmVtZW50IHRo YXQgY2FuJ3QgYmUgbWV0IHVzaW5nIG5pIFVSSXMsDQp0aGVuIEknZCBsaWtlIHRvIGtub3cgYWJv dXQgdGhhdCBiZWZvcmUgaXRzIHRvbyBsYXRlLiAoSSByZWFsaXNlDQp0aGF0IHRoZSBkZWNhZGUg V0cgbWlnaHQgc3RpbGwgY2hhbmdlIHJlcXMgb2YgY291cnNlIGJ1dCB3YW50ZWQgdG8NCmNoZWNr IG5vdyBiZWZvcmUgd2UncmUgZG9uZSB3aXRoIG91ciBkb2MuKQ0KDQpTDQoNCj4gQiwNCj4gDQo+ IFBlbmcuDQo+IA0KPiBGcm9tOiBTdGVwaGVuIEZhcnJlbGwNCj4gRGF0ZTogMjAxMi0wNy0wMyAw MzoyNg0KPiBUbzogcHpoYW5nLnRodQ0KPiBDQzogREVDQURFQGlldGYub3JnDQo+IFN1YmplY3Q6 IFJlOiBbZGVjYWRlXSBPYmplY3QgbmFtaW5nIGluIC1yZXEgYW5kIC1hcmNoDQo+IA0KPiBIaXlh LA0KPiANCj4gSSBndWVzcyBJIGhvcGUgdGhhdCBvdXIgZHJhZnQgKGp1c3QgZXhpdGVkIElFVEYg TEMpIG1lZXRzDQo+IHRoZXNlIHJlcXVpcmVtZW50cy4gSWYgbm90LCBJJ2QgYmUgaW50ZXJlc3Rl ZCBpbiB3aGF0J3MNCj4gbWlzc2luZy4NCj4gDQo+IENoZWVycywNCj4gUy4NCj4gDQo+IFsxXSBo dHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1mYXJyZWxsLWRlY2FkZS1uaQ0KPiANCj4g T24gMDcvMDMvMjAxMiAwNjozNCBBTSwgWmhhbmcgUGVuZyB3cm90ZToNCj4+IERlYXIgREVDQURF IHBhcnRpY2lwYW50cywNCj4+DQo+PiBBcyBwb2ludGVkIG91dCBieSBSaWNoYXJkIGluIHByZXZp b3VzIGRpc2N1c3Npb25zLCBib3RoIHRoZSAtcmVxIGFuZCAtYXJjaCBkb2N1bWVudHMgaGFzIHNv bWUgcGFyYWdyYXBocyBkZXNjcmliaW5nIGNvbnRlbnQgbmFtaW5nLCBhbmQgdGhleSBuZWVkIGJl dHRlciBvcmdhbml6YXRpb246IHNvbWUgZ2VuZXJpYyByZXF1aXJlbWVudHMgc2hvdWxkIGJlIGlu IC1yZXEsIHdoaWxlIHNvbWUgbW9yZSBzcGVjaWZpYyBvbmVzIHNob3VsZCBiZSBpbiAtYXJjaC4g SGVyZSBhcmUgc29tZSBzdWdnZXN0aW9ucyBhYm91dCBob3cgdG8gc3BsaXQgdGhlIGNvbnRlbnQg b24gbmFtaW5nIGluIHRoZXNlIHR3byBkb2N1bWVudHMuIA0KPj4NCj4+IFRoZSByYXRpb25hbGUg Zm9yIHRoZSBmb2xsb3dpbmcgc3BsaXQgaXMgdGhhdCBJIHJlY29nbml6ZSB0aGVyZSBhcmUgdHdv IGdlbmVyaWMgcmVxdWlyZW1lbnRzLCB0aGF0IGlzLCB1bmlxdWVuZXNzLCBhbmQgYmluZGluZyB2 YWxpZGF0aW9uLiBUaGV5IHNob3VsZCBiZSBwbGFjZWQgaW4gdGhlIC1yZXEuIEluIC1hcmNoLCB3 ZSBzaG91bGQgcHJlc2VudCB0aGUgc3BlY2lmaWMgcmVxdWlyZW1lbnRzIHRvIGVuYWJsZSB1bmlx dWVuZXNzLCBhbmQgYmluZGluZyB2YWxpZGF0aW9uLCByZXNwZWN0aXZlbHkuIFRoZXJlIGFyZSBh bHNvIHNvbWUgbW9yZSByZXF1aXJlbWVudHMgb24gaG93IHRvIGltcHJvdmUgdGhlIHJlc3BvbnNp dmVuZXNzIG9mIHRoZSBzeXN0ZW0sIGkuZS4sIHRoZSBzdXBwb3J0IG9mIGVhcmx5IG5hbWUgZ2Vu ZXJhdGlvbi4gU2VlIGJlbG93IGZvciBkZXRhaWxzIChyZWZlcmVuY2VzIHRvIHRoZSBvcmlnaW5h bCBkb2N1bWVudHMgYXJlIGdpdmVuIGFmdGVyIGVhY2ggc3BlY2lmaWMgcmVxdWlyZW1lbnRzKToN Cj4+DQo+PiBHZW5lcmljIHJlcXVpcmVtZW50cyAodG8gYmUgcHV0IGluIC1yZXEpDQo+Pg0KPj4g MS4gSXQgU0hPVUxEIGVuc3VyZSB0aGF0IHVuaXF1ZW5lc3Mgb2Ygb2JqZWN0IG5hbWVzLiANCj4+ IDIuIEl0IFNIT1VMRCBzdXBwb3J0IHRoZSB2YWxpZGF0aW9uIG9mIG5hbWUtb2JqZWN0IGJpbmRp bmcuDQo+PiAzLiBJdCBTSE9VTEQgc3VwcG9ydCB0aGUgb3BlcmF0aW9uIG9mIERFQ0FERS1jb21w YXRpYmxlIHNlcnZlcnMgdW5kZXIgZGl2ZXJzZSBhZG1pbmlzdHJhdGl2ZSBkb21haW5zIHdpdGgg bm8gY29vcmRpbmF0aW9uLiAobm90IHN1cmUgYWJvdXQgd2hhdCBvcGVyYXRpb25zIGFyZSBtZWFu dCBoZXJlKQ0KPj4NCj4+IFNwZWNpZmljIHJlcXVpcmVtZW50cyAodG8gYmUgcHV0IGluIC1hcmNo KQ0KPj4NCj4+IFJlcXVpcmVtZW50cyB0byBlbmFibGUgdW5pcXVlbmVzczogDQo+PiAxLiBJdCBN QVkgZW5hYmxlIGFwcGxpY2F0aW9ucyB0byBjb25zdHJ1Y3QgdW5pcXVlIG5hbWVzIGJ5IHRoZW1z ZWx2ZXMgd2l0aCBhIGhpZ2ggcHJvYmFiaWxpdHkgKHJlZjogbGFzdCBzZW50ZW5jZSwgcHAuIDEx LCAtYXJjaCkuIElmIHRoaXMgaXMgdGhlIGNhc2UsIGl0IFNIT1VMRCBpbmRpY2F0ZSBjb25mbGlj dHMgd2hlbiBkdXBsaWNhdGUgbmFtZXMgYXJlIGNvbnN0cnVjdGVkIChyZWY6IGZpcnN0IHBhcmEs IDQuNS4xLCAtcmVxKS4NCj4+IDIuIEl0IE1BWSBzdXBwb3J0IGNvbnRlbnQtZGVwZW5kZW50IGhh c2gtYmFzZWQgc2NoZW1lcyAoZm9yIGdlbmVyYWwgaW1tdXRhYmxlIG9iamVjdHMpLCBhbmQgY29u dGVudC1pbmRlcGVuZGVudCBlbnVtZXJhdGlvbi1iYXNlZCBzY2hlbWVzIChmb3IgbGl2ZSBzdHJl YW1pbmcpIA0KPj4gKHJlZjogMm5kIHBhcmEsIHBwLiAxMiwgLWFyY2gpDQo+Pg0KPj4gUmVxdWly ZW1lbnRzIHRvIGVuYWJsZSBuYW1lLW9iamVjdCBiaW5kaW5nIHZhbGlkYXRpb246DQo+PiAzLiBE aWZmZXJlbnQgbmFtZS1vYmplY3QgYmluZGluZyB2YWxpZGF0aW9uIG1lY2hhbmlzbXMgTUFZIGJl IHN1cHBvcnRlZCwgYW5kIGFuIGFwcGxpY2F0aW9uIGNhbiBkZWNpZGUgd2hpY2ggbWVjaGFuaXNt IHRvIHVzZS4gKHJlZjogMm5kIHBhcmEsIDQuNCwgLWFyY2gpDQo+PiA0LiBOYW1lcyBNQVkgYmUg c2VsZi1kZXNjcmliaW5nIHNvIHRoYXQgYSByZWNlaXZpbmcgZW50aXR5IChDb250ZW50IENvbnN1 bWVyKSBrbm93cyB3aGljaCBtZWNoYW5pc20gaXMgdXNlZCAocmVmOiAxc3QgcGFyYSwgcHAuIDEy LCAtYXJjaCkNCj4+IDUuIEl0IFNIT1VMRCBwcm92aWRlIHRoZSBmb2xsb3dpbmcgbmFtZSBlbGVt ZW50czogKDEpIEEgInR5cGUiIGZpZWxkLCAoMikgQ3J5cHRvZ3JhcGhpYyBkYXRhLCAoMykgQXBw bGljYXRpb24gb3IgcHVibGlzaGVyIGluZm9ybWF0aW9uLiAocmVmOiBwcC4gMTIsIC1hcmNoKQ0K Pj4NCj4+IE1vcmUgcmVxdWlyZW1lbnRzIGFib3V0IHBlcmZvcm1hbmNlOg0KPj4gNi4gSXQgU0hP VUxEIHN1cHBvcnQgdGhlIHNjZW5hcmlvcyB3aGVyZSBhIGNsaWVudCBuZWVkcyB0byBrbm93IHRo ZSBuYW1lIG9mIGEgZGF0YSBvYmplY3QgYmVmb3JlIGl0IGlzIGNvbXBsZXRlbHkgc3RvcmVkIGF0 IHRoZSBzZXJ2ZXIuIChUaGlzIGlzIHRvIGxldCBjbGllbnRzIGFkdmVydGlzZSB0aGUgb2JqZWN0 IGJlZm9yZSBoYXZpbmcgZnVsbHkgdXBsb2FkZWQgaXQpIChyZWY6IHNlY29uZCBsYXN0IHBhcmEs IHBwLiAxMiwgLWFyY2gpDQo+PiA3LiBJdCBTSE9VTEQgc3VwcG9ydCB0aGUgc2NlbmFyaW9zIHdo ZXJlIGEgY2xpZW50IG5lZWQgdG8ga25vdyB0aGUgbmFtZSBvZiBhIGRhdGEgb2JqZWN0IGJlZm9y ZSBpdCBpcyBsb2NhbGx5IGNyZWF0ZWQuIChUaGlzIGlzIHRvIHN1cHBvcnQgbGl2ZSBzdHJlYW1p bmcpIChyZWY6IGxhc3QgcGFyYSwgcHAuIDEyLCAtYXJjaCkNCj4+DQo+PiBBbnkgY29tbWVudHMg YXJlIHdlbGNvbWUsIHRoYW5rcy4NCj4+DQo+PiBQZW5nLg== ------=_001_NextPart347350785854_=---- Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Stephen,
 
Yes, for most cases, hash-based naming sch= eme is=20 ok for in-network storage system which holds immutable objects. 
Bur for some application such as live stre= aming,=20 we expect that the uploader/streamer can know the object name before it up= loads=20 the object to decade server. This will allow the streamer to advertise the= file=20 before fully uploading it, and then the viewer can fetch the object using = the=20 advertised name. If each object contains several seconds of video dat= a,=20 this feature can considerably reduce the latency. Thus, we may need a= =20 enumeration-based scheme besides the hash-based one. Can we add this featu= re in=20 your proposed design? Thanks.
 
B,
 
Peng.
 
Date: 2012-07-04 17:08
Subject: Re: [decade] Object naming in -req and=20 -arch
 
 
On 07/04/2012 09:05 PM, Zhang Peng wrot= e:
> Hi Stephen,
> 
> I have read your documents on = ;hash-based naming. It designs a good URI&nb= sp;format and mapping scheme to HTTP URL.&nb= sp;For DECADE, since our requirements include&nbs= p;uniqueness, name-object binding validation, I w= onder how we can apply your scheme to&n= bsp;meet them. 
 
ni URIs are as unique as the colli= sion resistance of your hash
function supports basically. If you pick&nbs= p;sha-256 that won't be
an issue.
 
ni URis support name-data integrity (incl.&n= bsp;in the code we've
released) which I think is the same&nbs= p;as what you're calling
name-object binding validation.
 
So my answer for both is: just use=  ni URIs to meet these
requirements:-)
 
> BTW, can you give more details&nbs= p;on what you mean by "meets these requ= irements"? Thanks.
 
I meant: if there's some requirement th= at can't be met using ni URIs,
then I'd like to know about that b= efore its too late. (I realise
that the decade WG might still change&n= bsp;reqs of course but wanted to
check now before we're done with our&nb= sp;doc.)
 
S
 
> B,
> 
> Peng.
> 
> From: Stephen Farrell
> Date: 2012-07-03 03:26
> To: pzhang.thu
> CC: DECADE@ietf.org
> Subject: Re: [decade] Object naming&nbs= p;in -req and -arch
> 
> Hiya,
> 
> I guess I hope that our draft=  (just exited IETF LC) meets
> these requirements. If not, I'd be=  interested in what's
> missing.
> 
> Cheers,
> S.
> 
> [1] http://tools.ietf.org/html/draft-farrell-decade-ni=
> 
> On 07/03/2012 06:34 AM, Zhang Peng=  wrote:
>> Dear DECADE participants,
>>
>> As pointed out by Richard in&n= bsp;previous discussions, both the -req and = -arch documents has some paragraphs describing&nb= sp;content naming, and they need better orga= nization: some generic requirements should be&nbs= p;in -req, while some more specific ones&nbs= p;should be in -arch. Here are some sug= gestions about how to split the content = ;on naming in these two documents. 
>>
>> The rationale for the following&nbs= p;split is that I recognize there are t= wo generic requirements, that is, uniqueness,&nbs= p;and binding validation. They should be pla= ced in the -req. In -arch, we should&nb= sp;present the specific requirements to enable&nb= sp;uniqueness, and binding validation, respectively.&n= bsp;There are also some more requirements on=  how to improve the responsiveness of t= he system, i.e., the support of early n= ame generation. See below for details (refer= ences to the original documents are given&nb= sp;after each specific requirements):
>>
>> Generic requirements (to be put&nbs= p;in -req)
>>
>> 1. It SHOULD ensure that uniqu= eness of object names. 
>> 2. It SHOULD support the valid= ation of name-object binding.
>> 3. It SHOULD support the opera= tion of DECADE-compatible servers under diverse&n= bsp;administrative domains with no coordination. = (not sure about what operations are meant&nb= sp;here)
>>
>> Specific requirements (to be put&nb= sp;in -arch)
>>
>> Requirements to enable uniqueness: =
>> 1. It MAY enable applications = to construct unique names by themselves with=  a high probability (ref: last sentence,&nbs= p;pp. 11, -arch). If this is the case,&= nbsp;it SHOULD indicate conflicts when duplicate&= nbsp;names are constructed (ref: first para, = ;4.5.1, -req).
>> 2. It MAY support content-dependent=  hash-based schemes (for general immutable o= bjects), and content-independent enumeration-based sch= emes (for live streaming) 
>> (ref: 2nd para, pp. 12, -arch)=
>>
>> Requirements to enable name-object = binding validation:
>> 3. Different name-object binding va= lidation mechanisms MAY be supported, and an=  application can decide which mechanism to&n= bsp;use. (ref: 2nd para, 4.4, -arch)
>> 4. Names MAY be self-describing&nbs= p;so that a receiving entity (Content Consum= er) knows which mechanism is used (ref: = ;1st para, pp. 12, -arch)
>> 5. It SHOULD provide the follo= wing name elements: (1) A "type" field, = ;(2) Cryptographic data, (3) Application or = publisher information. (ref: pp. 12, -arch)
>>
>> More requirements about performance:
>> 6. It SHOULD support the scena= rios where a client needs to know the&n= bsp;name of a data object before it is&= nbsp;completely stored at the server. (This = is to let clients advertise the object = before having fully uploaded it) (ref: secon= d last para, pp. 12, -arch)
>> 7. It SHOULD support the scena= rios where a client need to know the&nb= sp;name of a data object before it is&n= bsp;locally created. (This is to support liv= e streaming) (ref: last para, pp. 12, -= arch)
>>
>> Any comments are welcome, thanks.
>>
>> Peng.
 
------=_001_NextPart347350785854_=------ From stephen.farrell@cs.tcd.ie Wed Jul 4 14:42:18 2012 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 2B88C11E8088 for ; Wed, 4 Jul 2012 14:42:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.199 X-Spam-Level: X-Spam-Status: No, score=-102.199 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, J_CHICKENPOX_63=0.6, 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 uk3IPKO9TBq0 for ; Wed, 4 Jul 2012 14:42:16 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 772B511E807F for ; Wed, 4 Jul 2012 14:42:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id BF2E315754B; Wed, 4 Jul 2012 22:42:27 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1341438147; bh=Oxv0YJ2lvd/mAD WcotX4SibH+YoB7elBk+4Dy0I3VDE=; b=42n0S6NCxKWoHk0Rt/QCCb2fSZlIB2 1GSIvTnGtqx1JlUSuWSujIG4KvBqPqaFVpDAFcvBvQJS/gGkA2YelAyZSnOGFklq fhwOpZTqmhYPOg+91AZj9sgTdznp9/7qYVPLf6P/bkvhqtRcGa04ny9OWjVz1vgl A7ph5ufYT8ABrd//fnbxRW/PJkMC/Ksxvm1/9b1fz1C63uWVKEjbjjRkK9amO6/e /4D/+VzirwRNKoaxl79YxcJCskJv8wctFisEB2ecKFwD2Pm46H49uvJHEzBwUiEq PDEChulZ0DDqqw18PuYEqROhOgJ4ciQPMtAAfMto2zpysYsrcNFcraxQ== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id cp+tUXvCFYXL; Wed, 4 Jul 2012 22:42:27 +0100 (IST) Received: from [10.87.48.11] (unknown [86.41.15.232]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id E7E6C17147F; Wed, 4 Jul 2012 22:42:26 +0100 (IST) Message-ID: <4FF4B8C2.7090702@cs.tcd.ie> Date: Wed, 04 Jul 2012 22:42:26 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: "pzhang.thu" References: <20120703003402663560214@gmail.com>, <4FF2ACC3.1020004@cs.tcd.ie> <20120704160541638826251@gmail.com>, <4FF4B0D5.40906@cs.tcd.ie> <20120704174022735010267@gmail.com> In-Reply-To: <20120704174022735010267@gmail.com> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "DECADE@ietf.org" Subject: Re: [decade] Object naming in -req and -arch 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, 04 Jul 2012 21:42:18 -0000 On 07/04/2012 10:40 PM, Zhang Peng wrote: > Hi Stephen, > > Yes, for most cases, hash-based naming scheme is ok for in-network storage system which holds immutable objects. > Bur for some application such as live streaming, we expect that the uploader/streamer can know the object name before it uploads the object to decade server. This will allow the streamer to advertise the file before fully uploading it, and then the viewer can fetch the object using the advertised name. If each object contains several seconds of video data, this feature can considerably reduce the latency. Thus, we may need a enumeration-based scheme besides the hash-based one. Can we add this feature in your proposed design? Thanks. Ah gotcha. Yes there are ways, basically by defining a new hash alg and using a signature. There's one documented in draft-hallambaker-decade-ni-params [1] section 2.1. Cheers, S. [1] http://tools.ietf.org/html/draft-hallambaker-decade-ni-params-03 > B, > > Peng. > > From: Stephen Farrell > Date: 2012-07-04 17:08 > To: pzhang.thu > CC: DECADE@ietf.org > Subject: Re: [decade] Object naming in -req and -arch > > > On 07/04/2012 09:05 PM, Zhang Peng wrote: >> Hi Stephen, >> >> I have read your documents on hash-based naming. It designs a good URI format and mapping scheme to HTTP URL. For DECADE, since our requirements include uniqueness, name-object binding validation, I wonder how we can apply your scheme to meet them. > > ni URIs are as unique as the collision resistance of your hash > function supports basically. If you pick sha-256 that won't be > an issue. > > ni URis support name-data integrity (incl. in the code we've > released) which I think is the same as what you're calling > name-object binding validation. > > So my answer for both is: just use ni URIs to meet these > requirements:-) > >> BTW, can you give more details on what you mean by "meets these requirements"? Thanks. > > I meant: if there's some requirement that can't be met using ni URIs, > then I'd like to know about that before its too late. (I realise > that the decade WG might still change reqs of course but wanted to > check now before we're done with our doc.) > > S > >> B, >> >> Peng. >> >> From: Stephen Farrell >> Date: 2012-07-03 03:26 >> To: pzhang.thu >> CC: DECADE@ietf.org >> Subject: Re: [decade] Object naming in -req and -arch >> >> Hiya, >> >> I guess I hope that our draft (just exited IETF LC) meets >> these requirements. If not, I'd be interested in what's >> missing. >> >> Cheers, >> S. >> >> [1] http://tools.ietf.org/html/draft-farrell-decade-ni >> >> On 07/03/2012 06:34 AM, Zhang Peng wrote: >>> Dear DECADE participants, >>> >>> As pointed out by Richard in previous discussions, both the -req and -arch documents has some paragraphs describing content naming, and they need better organization: some generic requirements should be in -req, while some more specific ones should be in -arch. Here are some suggestions about how to split the content on naming in these two documents. >>> >>> The rationale for the following split is that I recognize there are two generic requirements, that is, uniqueness, and binding validation. They should be placed in the -req. In -arch, we should present the specific requirements to enable uniqueness, and binding validation, respectively. There are also some more requirements on how to improve the responsiveness of the system, i.e., the support of early name generation. See below for details (references to the original documents are given after each specific requirements): >>> >>> Generic requirements (to be put in -req) >>> >>> 1. It SHOULD ensure that uniqueness of object names. >>> 2. It SHOULD support the validation of name-object binding. >>> 3. It SHOULD support the operation of DECADE-compatible servers under diverse administrative domains with no coordination. (not sure about what operations are meant here) >>> >>> Specific requirements (to be put in -arch) >>> >>> Requirements to enable uniqueness: >>> 1. It MAY enable applications to construct unique names by themselves with a high probability (ref: last sentence, pp. 11, -arch). If this is the case, it SHOULD indicate conflicts when duplicate names are constructed (ref: first para, 4.5.1, -req). >>> 2. It MAY support content-dependent hash-based schemes (for general immutable objects), and content-independent enumeration-based schemes (for live streaming) >>> (ref: 2nd para, pp. 12, -arch) >>> >>> Requirements to enable name-object binding validation: >>> 3. Different name-object binding validation mechanisms MAY be supported, and an application can decide which mechanism to use. (ref: 2nd para, 4.4, -arch) >>> 4. Names MAY be self-describing so that a receiving entity (Content Consumer) knows which mechanism is used (ref: 1st para, pp. 12, -arch) >>> 5. It SHOULD provide the following name elements: (1) A "type" field, (2) Cryptographic data, (3) Application or publisher information. (ref: pp. 12, -arch) >>> >>> More requirements about performance: >>> 6. It SHOULD support the scenarios where a client needs to know the name of a data object before it is completely stored at the server. (This is to let clients advertise the object before having fully uploaded it) (ref: second last para, pp. 12, -arch) >>> 7. It SHOULD support the scenarios where a client need to know the name of a data object before it is locally created. (This is to support live streaming) (ref: last para, pp. 12, -arch) >>> >>> Any comments are welcome, thanks. >>> >>> Peng. From pzhang.thu@gmail.com Wed Jul 4 14:57:31 2012 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 3E9AF21F861D for ; Wed, 4 Jul 2012 14:57:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.696 X-Spam-Level: X-Spam-Status: No, score=-0.696 tagged_above=-999 required=5 tests=[AWL=0.550, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_63=0.6, MIME_BASE64_TEXT=1.753, 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 1qQ8R+G3osE2 for ; Wed, 4 Jul 2012 14:57:30 -0700 (PDT) Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id F045C21F8615 for ; Wed, 4 Jul 2012 14:57:29 -0700 (PDT) Received: by qaea16 with SMTP id a16so3423536qae.10 for ; Wed, 04 Jul 2012 14:57:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:reply-to:subject:references:x-priority:x-guid :x-mailer:mime-version:message-id:content-type; bh=ZHAkkmclLAckuG/y6gh0y6D24qFRhQ05GTPkSETnP4s=; b=UxZwaKyOwkIRGF8yW0KCeYiUw71REs/w3Km7FwFEKXJd0KlOe1rMTAg87bAk3GCwze 080ru+ufNR1i3tSXzVVY0j68uiTqJn39RC2JLCTcUNrRur6Orw3kIAvpaKBUhzcqrmdw RMYMp5TGLRKSRpDYKyhtGpVgy/Y29nCIKMobQ5sM3avDKzWTMml3H0RNoxU1lyHOtdbx Rcdrpq0AtwakFOjAQyQl4SPEcHV64zBWi7f4aQi4WHcJscLuDnrdtf0ces6HDDgRDHHc T2CxZXuus0gCjuKi13GWkQ7C8xe6xewVnO+Vwxs9gHUAICgeWQ8EammA9/emYeBjQ+ZZ KMiQ== Received: by 10.224.59.19 with SMTP id j19mr41046296qah.25.1341439061388; Wed, 04 Jul 2012 14:57:41 -0700 (PDT) Received: from pzhang-PC (dhcp-130-132-249-182.central.yale.edu. [130.132.249.182]) by mx.google.com with ESMTPS id cn9sm22685435qab.15.2012.07.04.14.57.40 (version=SSLv3 cipher=OTHER); Wed, 04 Jul 2012 14:57:40 -0700 (PDT) Date: Wed, 4 Jul 2012 17:57:39 -0400 From: "Zhang Peng" To: "Stephen Farrell" References: <20120703003402663560214@gmail.com>, <4FF2ACC3.1020004@cs.tcd.ie> <20120704160541638826251@gmail.com>, <4FF4B0D5.40906@cs.tcd.ie> <20120704174022735010267@gmail.com>, <4FF4B8C2.7090702@cs.tcd.ie> X-Priority: 3 X-GUID: 756F93EE-74DA-4E06-99C2-DD4631390851 X-Mailer: Foxmail 7.0.1.81[cn] Mime-Version: 1.0 Message-ID: <20120704175739679926274@gmail.com> Content-Type: multipart/alternative; boundary="----=_001_NextPart235124076331_=----" Cc: "DECADE@ietf.org" Subject: Re: [decade] Object naming in -req and -arch X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "pzhang.thu" 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, 04 Jul 2012 21:57:31 -0000 This is a multi-part message in MIME format. ------=_001_NextPart235124076331_=---- Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 T2ssIGl0IHNlZW1zIHRvIHdvcmsuIEJ1dCBpdCBqdXN0IGluY2x1ZGVzIHRoZSBoYXNoIG9mIHB1 YmxpYyBrZXkuIEhvdyB0byBuYW1lIGEgc2VxdWVuY2Ugb2YgZHluYW1pYyBuYW1lcz8gRm9yIGV4 YW1wbGUsIHRoZSBzdHJlYW0gaXMgZGl2aWRlZCBpbnRvIG9iamVjdCBieSBzZWNvbmRzOiAxcywg MnMsIDNzLC4uLj8gDQoNCkIsDQoNClBlbmcuDQpGcm9tOiBTdGVwaGVuIEZhcnJlbGwNCkRhdGU6 IDIwMTItMDctMDQgMTc6NDINClRvOiBwemhhbmcudGh1DQpDQzogREVDQURFQGlldGYub3JnDQpT dWJqZWN0OiBSZTogW2RlY2FkZV0gT2JqZWN0IG5hbWluZyBpbiAtcmVxIGFuZCAtYXJjaA0KDQoN Ck9uIDA3LzA0LzIwMTIgMTA6NDAgUE0sIFpoYW5nIFBlbmcgd3JvdGU6DQo+IEhpIFN0ZXBoZW4s DQo+IA0KPiBZZXMsIGZvciBtb3N0IGNhc2VzLCBoYXNoLWJhc2VkIG5hbWluZyBzY2hlbWUgaXMg b2sgZm9yIGluLW5ldHdvcmsgc3RvcmFnZSBzeXN0ZW0gd2hpY2ggaG9sZHMgaW1tdXRhYmxlIG9i amVjdHMuIA0KPiBCdXIgZm9yIHNvbWUgYXBwbGljYXRpb24gc3VjaCBhcyBsaXZlIHN0cmVhbWlu Zywgd2UgZXhwZWN0IHRoYXQgdGhlIHVwbG9hZGVyL3N0cmVhbWVyIGNhbiBrbm93IHRoZSBvYmpl Y3QgbmFtZSBiZWZvcmUgaXQgdXBsb2FkcyB0aGUgb2JqZWN0IHRvIGRlY2FkZSBzZXJ2ZXIuIFRo aXMgd2lsbCBhbGxvdyB0aGUgc3RyZWFtZXIgdG8gYWR2ZXJ0aXNlIHRoZSBmaWxlIGJlZm9yZSBm dWxseSB1cGxvYWRpbmcgaXQsIGFuZCB0aGVuIHRoZSB2aWV3ZXIgY2FuIGZldGNoIHRoZSBvYmpl Y3QgdXNpbmcgdGhlIGFkdmVydGlzZWQgbmFtZS4gSWYgZWFjaCBvYmplY3QgY29udGFpbnMgc2V2 ZXJhbCBzZWNvbmRzIG9mIHZpZGVvIGRhdGEsIHRoaXMgZmVhdHVyZSBjYW4gY29uc2lkZXJhYmx5 IHJlZHVjZSB0aGUgbGF0ZW5jeS4gVGh1cywgd2UgbWF5IG5lZWQgYSBlbnVtZXJhdGlvbi1iYXNl ZCBzY2hlbWUgYmVzaWRlcyB0aGUgaGFzaC1iYXNlZCBvbmUuIENhbiB3ZSBhZGQgdGhpcyBmZWF0 dXJlIGluIHlvdXIgcHJvcG9zZWQgZGVzaWduPyBUaGFua3MuDQoNCkFoIGdvdGNoYS4gWWVzIHRo ZXJlIGFyZSB3YXlzLCBiYXNpY2FsbHkgYnkgZGVmaW5pbmcgYSBuZXcNCmhhc2ggYWxnIGFuZCB1 c2luZyBhIHNpZ25hdHVyZS4gVGhlcmUncyBvbmUgZG9jdW1lbnRlZCBpbg0KZHJhZnQtaGFsbGFt YmFrZXItZGVjYWRlLW5pLXBhcmFtcyBbMV0gc2VjdGlvbiAyLjEuDQoNCkNoZWVycywNClMuDQoN ClsxXSBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1oYWxsYW1iYWtlci1kZWNhZGUt bmktcGFyYW1zLTAzDQoNCj4gQiwNCj4gDQo+IFBlbmcuDQo+IA0KPiBGcm9tOiBTdGVwaGVuIEZh cnJlbGwNCj4gRGF0ZTogMjAxMi0wNy0wNCAxNzowOA0KPiBUbzogcHpoYW5nLnRodQ0KPiBDQzog REVDQURFQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbZGVjYWRlXSBPYmplY3QgbmFtaW5nIGlu IC1yZXEgYW5kIC1hcmNoDQo+IA0KPiANCj4gT24gMDcvMDQvMjAxMiAwOTowNSBQTSwgWmhhbmcg UGVuZyB3cm90ZToNCj4+IEhpIFN0ZXBoZW4sDQo+Pg0KPj4gSSBoYXZlIHJlYWQgeW91ciBkb2N1 bWVudHMgb24gaGFzaC1iYXNlZCBuYW1pbmcuIEl0IGRlc2lnbnMgYSBnb29kIFVSSSBmb3JtYXQg YW5kIG1hcHBpbmcgc2NoZW1lIHRvIEhUVFAgVVJMLiBGb3IgREVDQURFLCBzaW5jZSBvdXIgcmVx dWlyZW1lbnRzIGluY2x1ZGUgdW5pcXVlbmVzcywgbmFtZS1vYmplY3QgYmluZGluZyB2YWxpZGF0 aW9uLCBJIHdvbmRlciBob3cgd2UgY2FuIGFwcGx5IHlvdXIgc2NoZW1lIHRvIG1lZXQgdGhlbS4g DQo+IA0KPiBuaSBVUklzIGFyZSBhcyB1bmlxdWUgYXMgdGhlIGNvbGxpc2lvbiByZXNpc3RhbmNl IG9mIHlvdXIgaGFzaA0KPiBmdW5jdGlvbiBzdXBwb3J0cyBiYXNpY2FsbHkuIElmIHlvdSBwaWNr IHNoYS0yNTYgdGhhdCB3b24ndCBiZQ0KPiBhbiBpc3N1ZS4NCj4gDQo+IG5pIFVSaXMgc3VwcG9y dCBuYW1lLWRhdGEgaW50ZWdyaXR5IChpbmNsLiBpbiB0aGUgY29kZSB3ZSd2ZQ0KPiByZWxlYXNl ZCkgd2hpY2ggSSB0aGluayBpcyB0aGUgc2FtZSBhcyB3aGF0IHlvdSdyZSBjYWxsaW5nDQo+IG5h bWUtb2JqZWN0IGJpbmRpbmcgdmFsaWRhdGlvbi4NCj4gDQo+IFNvIG15IGFuc3dlciBmb3IgYm90 aCBpczoganVzdCB1c2UgbmkgVVJJcyB0byBtZWV0IHRoZXNlDQo+IHJlcXVpcmVtZW50czotKQ0K PiANCj4+IEJUVywgY2FuIHlvdSBnaXZlIG1vcmUgZGV0YWlscyBvbiB3aGF0IHlvdSBtZWFuIGJ5 ICJtZWV0cyB0aGVzZSByZXF1aXJlbWVudHMiPyBUaGFua3MuDQo+IA0KPiBJIG1lYW50OiBpZiB0 aGVyZSdzIHNvbWUgcmVxdWlyZW1lbnQgdGhhdCBjYW4ndCBiZSBtZXQgdXNpbmcgbmkgVVJJcywN Cj4gdGhlbiBJJ2QgbGlrZSB0byBrbm93IGFib3V0IHRoYXQgYmVmb3JlIGl0cyB0b28gbGF0ZS4g KEkgcmVhbGlzZQ0KPiB0aGF0IHRoZSBkZWNhZGUgV0cgbWlnaHQgc3RpbGwgY2hhbmdlIHJlcXMg b2YgY291cnNlIGJ1dCB3YW50ZWQgdG8NCj4gY2hlY2sgbm93IGJlZm9yZSB3ZSdyZSBkb25lIHdp dGggb3VyIGRvYy4pDQo+IA0KPiBTDQo+IA0KPj4gQiwNCj4+DQo+PiBQZW5nLg0KPj4NCj4+IEZy b206IFN0ZXBoZW4gRmFycmVsbA0KPj4gRGF0ZTogMjAxMi0wNy0wMyAwMzoyNg0KPj4gVG86IHB6 aGFuZy50aHUNCj4+IENDOiBERUNBREVAaWV0Zi5vcmcNCj4+IFN1YmplY3Q6IFJlOiBbZGVjYWRl XSBPYmplY3QgbmFtaW5nIGluIC1yZXEgYW5kIC1hcmNoDQo+Pg0KPj4gSGl5YSwNCj4+DQo+PiBJ IGd1ZXNzIEkgaG9wZSB0aGF0IG91ciBkcmFmdCAoanVzdCBleGl0ZWQgSUVURiBMQykgbWVldHMN Cj4+IHRoZXNlIHJlcXVpcmVtZW50cy4gSWYgbm90LCBJJ2QgYmUgaW50ZXJlc3RlZCBpbiB3aGF0 J3MNCj4+IG1pc3NpbmcuDQo+Pg0KPj4gQ2hlZXJzLA0KPj4gUy4NCj4+DQo+PiBbMV0gaHR0cDov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtZmFycmVsbC1kZWNhZGUtbmkNCj4+DQo+PiBPbiAw Ny8wMy8yMDEyIDA2OjM0IEFNLCBaaGFuZyBQZW5nIHdyb3RlOg0KPj4+IERlYXIgREVDQURFIHBh cnRpY2lwYW50cywNCj4+Pg0KPj4+IEFzIHBvaW50ZWQgb3V0IGJ5IFJpY2hhcmQgaW4gcHJldmlv dXMgZGlzY3Vzc2lvbnMsIGJvdGggdGhlIC1yZXEgYW5kIC1hcmNoIGRvY3VtZW50cyBoYXMgc29t ZSBwYXJhZ3JhcGhzIGRlc2NyaWJpbmcgY29udGVudCBuYW1pbmcsIGFuZCB0aGV5IG5lZWQgYmV0 dGVyIG9yZ2FuaXphdGlvbjogc29tZSBnZW5lcmljIHJlcXVpcmVtZW50cyBzaG91bGQgYmUgaW4g LXJlcSwgd2hpbGUgc29tZSBtb3JlIHNwZWNpZmljIG9uZXMgc2hvdWxkIGJlIGluIC1hcmNoLiBI ZXJlIGFyZSBzb21lIHN1Z2dlc3Rpb25zIGFib3V0IGhvdyB0byBzcGxpdCB0aGUgY29udGVudCBv biBuYW1pbmcgaW4gdGhlc2UgdHdvIGRvY3VtZW50cy4gDQo+Pj4NCj4+PiBUaGUgcmF0aW9uYWxl IGZvciB0aGUgZm9sbG93aW5nIHNwbGl0IGlzIHRoYXQgSSByZWNvZ25pemUgdGhlcmUgYXJlIHR3 byBnZW5lcmljIHJlcXVpcmVtZW50cywgdGhhdCBpcywgdW5pcXVlbmVzcywgYW5kIGJpbmRpbmcg dmFsaWRhdGlvbi4gVGhleSBzaG91bGQgYmUgcGxhY2VkIGluIHRoZSAtcmVxLiBJbiAtYXJjaCwg d2Ugc2hvdWxkIHByZXNlbnQgdGhlIHNwZWNpZmljIHJlcXVpcmVtZW50cyB0byBlbmFibGUgdW5p cXVlbmVzcywgYW5kIGJpbmRpbmcgdmFsaWRhdGlvbiwgcmVzcGVjdGl2ZWx5LiBUaGVyZSBhcmUg YWxzbyBzb21lIG1vcmUgcmVxdWlyZW1lbnRzIG9uIGhvdyB0byBpbXByb3ZlIHRoZSByZXNwb25z aXZlbmVzcyBvZiB0aGUgc3lzdGVtLCBpLmUuLCB0aGUgc3VwcG9ydCBvZiBlYXJseSBuYW1lIGdl bmVyYXRpb24uIFNlZSBiZWxvdyBmb3IgZGV0YWlscyAocmVmZXJlbmNlcyB0byB0aGUgb3JpZ2lu YWwgZG9jdW1lbnRzIGFyZSBnaXZlbiBhZnRlciBlYWNoIHNwZWNpZmljIHJlcXVpcmVtZW50cyk6 DQo+Pj4NCj4+PiBHZW5lcmljIHJlcXVpcmVtZW50cyAodG8gYmUgcHV0IGluIC1yZXEpDQo+Pj4N Cj4+PiAxLiBJdCBTSE9VTEQgZW5zdXJlIHRoYXQgdW5pcXVlbmVzcyBvZiBvYmplY3QgbmFtZXMu IA0KPj4+IDIuIEl0IFNIT1VMRCBzdXBwb3J0IHRoZSB2YWxpZGF0aW9uIG9mIG5hbWUtb2JqZWN0 IGJpbmRpbmcuDQo+Pj4gMy4gSXQgU0hPVUxEIHN1cHBvcnQgdGhlIG9wZXJhdGlvbiBvZiBERUNB REUtY29tcGF0aWJsZSBzZXJ2ZXJzIHVuZGVyIGRpdmVyc2UgYWRtaW5pc3RyYXRpdmUgZG9tYWlu cyB3aXRoIG5vIGNvb3JkaW5hdGlvbi4gKG5vdCBzdXJlIGFib3V0IHdoYXQgb3BlcmF0aW9ucyBh cmUgbWVhbnQgaGVyZSkNCj4+Pg0KPj4+IFNwZWNpZmljIHJlcXVpcmVtZW50cyAodG8gYmUgcHV0 IGluIC1hcmNoKQ0KPj4+DQo+Pj4gUmVxdWlyZW1lbnRzIHRvIGVuYWJsZSB1bmlxdWVuZXNzOiAN Cj4+PiAxLiBJdCBNQVkgZW5hYmxlIGFwcGxpY2F0aW9ucyB0byBjb25zdHJ1Y3QgdW5pcXVlIG5h bWVzIGJ5IHRoZW1zZWx2ZXMgd2l0aCBhIGhpZ2ggcHJvYmFiaWxpdHkgKHJlZjogbGFzdCBzZW50 ZW5jZSwgcHAuIDExLCAtYXJjaCkuIElmIHRoaXMgaXMgdGhlIGNhc2UsIGl0IFNIT1VMRCBpbmRp Y2F0ZSBjb25mbGljdHMgd2hlbiBkdXBsaWNhdGUgbmFtZXMgYXJlIGNvbnN0cnVjdGVkIChyZWY6 IGZpcnN0IHBhcmEsIDQuNS4xLCAtcmVxKS4NCj4+PiAyLiBJdCBNQVkgc3VwcG9ydCBjb250ZW50 LWRlcGVuZGVudCBoYXNoLWJhc2VkIHNjaGVtZXMgKGZvciBnZW5lcmFsIGltbXV0YWJsZSBvYmpl Y3RzKSwgYW5kIGNvbnRlbnQtaW5kZXBlbmRlbnQgZW51bWVyYXRpb24tYmFzZWQgc2NoZW1lcyAo Zm9yIGxpdmUgc3RyZWFtaW5nKSANCj4+PiAocmVmOiAybmQgcGFyYSwgcHAuIDEyLCAtYXJjaCkN Cj4+Pg0KPj4+IFJlcXVpcmVtZW50cyB0byBlbmFibGUgbmFtZS1vYmplY3QgYmluZGluZyB2YWxp ZGF0aW9uOg0KPj4+IDMuIERpZmZlcmVudCBuYW1lLW9iamVjdCBiaW5kaW5nIHZhbGlkYXRpb24g bWVjaGFuaXNtcyBNQVkgYmUgc3VwcG9ydGVkLCBhbmQgYW4gYXBwbGljYXRpb24gY2FuIGRlY2lk ZSB3aGljaCBtZWNoYW5pc20gdG8gdXNlLiAocmVmOiAybmQgcGFyYSwgNC40LCAtYXJjaCkNCj4+ PiA0LiBOYW1lcyBNQVkgYmUgc2VsZi1kZXNjcmliaW5nIHNvIHRoYXQgYSByZWNlaXZpbmcgZW50 aXR5IChDb250ZW50IENvbnN1bWVyKSBrbm93cyB3aGljaCBtZWNoYW5pc20gaXMgdXNlZCAocmVm OiAxc3QgcGFyYSwgcHAuIDEyLCAtYXJjaCkNCj4+PiA1LiBJdCBTSE9VTEQgcHJvdmlkZSB0aGUg Zm9sbG93aW5nIG5hbWUgZWxlbWVudHM6ICgxKSBBICJ0eXBlIiBmaWVsZCwgKDIpIENyeXB0b2dy YXBoaWMgZGF0YSwgKDMpIEFwcGxpY2F0aW9uIG9yIHB1Ymxpc2hlciBpbmZvcm1hdGlvbi4gKHJl ZjogcHAuIDEyLCAtYXJjaCkNCj4+Pg0KPj4+IE1vcmUgcmVxdWlyZW1lbnRzIGFib3V0IHBlcmZv cm1hbmNlOg0KPj4+IDYuIEl0IFNIT1VMRCBzdXBwb3J0IHRoZSBzY2VuYXJpb3Mgd2hlcmUgYSBj bGllbnQgbmVlZHMgdG8ga25vdyB0aGUgbmFtZSBvZiBhIGRhdGEgb2JqZWN0IGJlZm9yZSBpdCBp cyBjb21wbGV0ZWx5IHN0b3JlZCBhdCB0aGUgc2VydmVyLiAoVGhpcyBpcyB0byBsZXQgY2xpZW50 cyBhZHZlcnRpc2UgdGhlIG9iamVjdCBiZWZvcmUgaGF2aW5nIGZ1bGx5IHVwbG9hZGVkIGl0KSAo cmVmOiBzZWNvbmQgbGFzdCBwYXJhLCBwcC4gMTIsIC1hcmNoKQ0KPj4+IDcuIEl0IFNIT1VMRCBz dXBwb3J0IHRoZSBzY2VuYXJpb3Mgd2hlcmUgYSBjbGllbnQgbmVlZCB0byBrbm93IHRoZSBuYW1l IG9mIGEgZGF0YSBvYmplY3QgYmVmb3JlIGl0IGlzIGxvY2FsbHkgY3JlYXRlZC4gKFRoaXMgaXMg dG8gc3VwcG9ydCBsaXZlIHN0cmVhbWluZykgKHJlZjogbGFzdCBwYXJhLCBwcC4gMTIsIC1hcmNo KQ0KPj4+DQo+Pj4gQW55IGNvbW1lbnRzIGFyZSB3ZWxjb21lLCB0aGFua3MuDQo+Pj4NCj4+PiBQ ZW5nLg== ------=_001_NextPart235124076331_=---- Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Ok, it seems to work. But it just includes the hash of public key. Ho= w to=20 name a sequence of dynamic names? For example, the stream is divided into = object=20 by seconds: 1s, 2s, 3s,...?
 
B,
 
Peng.
Date: 2012-07-04 17:42
Subject: Re: [decade] Object naming in -req and=20 -arch
 
 
On 07/04/2012 10:40 PM, Zhang Peng wrot= e:
> Hi Stephen,
> 
> Yes, for most cases, hash-based na= ming scheme is ok for in-network storage&nbs= p;system which holds immutable objects. 
> Bur for some application such as&n= bsp;live streaming, we expect that the uploa= der/streamer can know the object name before=  it uploads the object to decade server= . This will allow the streamer to adver= tise the file before fully uploading it,&nbs= p;and then the viewer can fetch the obj= ect using the advertised name. If each = object contains several seconds of video dat= a, this feature can considerably reduce the&= nbsp;latency. Thus, we may need a enumeratio= n-based scheme besides the hash-based one. C= an we add this feature in your proposed=  design? Thanks.
 
Ah gotcha. Yes there are ways, basicall= y by defining a new
hash alg and using a signature. There's=  one documented in
draft-hallambaker-decade-ni-params [1] section 2.1.
 
Cheers,
S.
 
[1] http://tools.ietf.org/html/draft-hallambaker-decade-ni-param= s-03
 
> B,
> 
> Peng.
> 
> From: Stephen Farrell
> Date: 2012-07-04 17:08
> To: pzhang.thu
> CC: DECADE@ietf.org
> Subject: Re: [decade] Object naming&nbs= p;in -req and -arch
> 
> 
> On 07/04/2012 09:05 PM, Zhang Peng=  wrote:
>> Hi Stephen,
>>
>> I have read your documents on&= nbsp;hash-based naming. It designs a good UR= I format and mapping scheme to HTTP URL= . For DECADE, since our requirements include=  uniqueness, name-object binding validation, I&nb= sp;wonder how we can apply your scheme = to meet them. 
> 
> ni URIs are as unique as the&= nbsp;collision resistance of your hash
> function supports basically. If you&nbs= p;pick sha-256 that won't be
> an issue.
> 
> ni URis support name-data integrity&nbs= p;(incl. in the code we've
> released) which I think is the&nbs= p;same as what you're calling
> name-object binding validation.
> 
> So my answer for both is: jus= t use ni URIs to meet these
> requirements:-)
> 
>> BTW, can you give more details=  on what you mean by "meets these = requirements"? Thanks.
> 
> I meant: if there's some requireme= nt that can't be met using ni URIs,
> then I'd like to know about t= hat before its too late. (I realise
> that the decade WG might still&nbs= p;change reqs of course but wanted to
> check now before we're done with&n= bsp;our doc.)
> 
> S
> 
>> B,
>>
>> Peng.
>>
>> From: Stephen Farrell
>> Date: 2012-07-03 03:26
>> To: pzhang.thu
>> CC: DECADE@ietf.org
>> Subject: Re: [decade] Object naming=  in -req and -arch
>>
>> Hiya,
>>
>> I guess I hope that our d= raft (just exited IETF LC) meets
>> these requirements. If not, I'd&nbs= p;be interested in what's
>> missing.
>>
>> Cheers,
>> S.
>>
>> [1] http://tools.ietf.org/html/draft-farrell-decad= e-ni
>>
>> On 07/03/2012 06:34 AM, Zhang = Peng wrote:
>>> Dear DECADE participants,
>>>
>>> As pointed out by Richard = in previous discussions, both the -req and&n= bsp;-arch documents has some paragraphs describin= g content naming, and they need better = organization: some generic requirements should be=  in -req, while some more specific ones=  should be in -arch. Here are some = ;suggestions about how to split the content&= nbsp;on naming in these two documents. 
>>>
>>> The rationale for the following=  split is that I recognize there are&nb= sp;two generic requirements, that is, uniqueness,=  and binding validation. They should be = ;placed in the -req. In -arch, we shoul= d present the specific requirements to enabl= e uniqueness, and binding validation, respectivel= y. There are also some more requirements&nbs= p;on how to improve the responsiveness of&nb= sp;the system, i.e., the support of early&nb= sp;name generation. See below for details (r= eferences to the original documents are give= n after each specific requirements):
>>>
>>> Generic requirements (to be put=  in -req)
>>>
>>> 1. It SHOULD ensure that u= niqueness of object names. 
>>> 2. It SHOULD support the v= alidation of name-object binding.
>>> 3. It SHOULD support the o= peration of DECADE-compatible servers under diver= se administrative domains with no coordination.&n= bsp;(not sure about what operations are mean= t here)
>>>
>>> Specific requirements (to be pu= t in -arch)
>>>
>>> Requirements to enable uniqueness:&n= bsp;
>>> 1. It MAY enable applications&n= bsp;to construct unique names by themselves = with a high probability (ref: last sentence,=  pp. 11, -arch). If this is the ca= se, it SHOULD indicate conflicts when duplic= ate names are constructed (ref: first para,&= nbsp;4.5.1, -req).
>>> 2. It MAY support content-depen= dent hash-based schemes (for general immutable&nb= sp;objects), and content-independent enumeration-based = ;schemes (for live streaming) 
>>> (ref: 2nd para, pp. 12, -a= rch)
>>>
>>> Requirements to enable name-object&n= bsp;binding validation:
>>> 3. Different name-object binding&nbs= p;validation mechanisms MAY be supported, and&nbs= p;an application can decide which mechanism = to use. (ref: 2nd para, 4.4, -arch)
>>> 4. Names MAY be self-describing=  so that a receiving entity (Content Co= nsumer) knows which mechanism is used (ref:&= nbsp;1st para, pp. 12, -arch)
>>> 5. It SHOULD provide the f= ollowing name elements: (1) A "type" field,&= nbsp;(2) Cryptographic data, (3) Application or&n= bsp;publisher information. (ref: pp. 12, -arch)
>>>
>>> More requirements about performance:=
>>> 6. It SHOULD support the s= cenarios where a client needs to know t= he name of a data object before it = ;is completely stored at the server. (This&n= bsp;is to let clients advertise the object&n= bsp;before having fully uploaded it) (ref: s= econd last para, pp. 12, -arch)
>>> 7. It SHOULD support the s= cenarios where a client need to know th= e name of a data object before it = is locally created. (This is to support = ;live streaming) (ref: last para, pp. 12,&nb= sp;-arch)
>>>
>>> Any comments are welcome, thank= s.
>>>
>>> Peng.
 
------=_001_NextPart235124076331_=------ From stephen.farrell@cs.tcd.ie Wed Jul 4 15:01:22 2012 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 2C7A421F859F for ; Wed, 4 Jul 2012 15:01:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.149 X-Spam-Level: X-Spam-Status: No, score=-102.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_63=0.6, 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 dcQS3U4dDLu9 for ; Wed, 4 Jul 2012 15:01:20 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 6FEA521F8615 for ; Wed, 4 Jul 2012 15:01:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id EFDC4171819; Wed, 4 Jul 2012 23:01:30 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1341439290; bh=vKZmDoXYj9owrM 8cS9T7asK80m7mS+Y4f1wkNWixOFk=; b=Cp5KlkfUuoIqaa4k1l6dROb0Rg6Qwq x+tNCxGRNC8mbYTKFAQx/lI0hSvu10fcafb4kjLD7yEH5nZYZIzKG0iuFGPkkQpK S8xdYJNOoi50wdI4xi8twc6LWN8u1PQebyiOhQ1GmA687G1HU9sRxPS/FVa+Mfvx Zmzm+uddGEHWCALJoj+x3xydSe4mB+gJGy3EamY8ZBbmvUgbM5TECwxelbBGgrX8 /ZtrYHz8SI8V4eP0rG0AdvaP+ErVcZv95/SAhh5+h2Qa6Q3xc+z4RJJeTfOGBWey hjzgJPR7UaK2rxrDbbGWLBxSCawEgDO3yb5bsAZfZOGH4ea8zHeq9WuQ== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id JTBtbFvA4pOB; Wed, 4 Jul 2012 23:01:30 +0100 (IST) Received: from [10.87.48.11] (unknown [86.41.15.232]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id CF95A17147F; Wed, 4 Jul 2012 23:01:29 +0100 (IST) Message-ID: <4FF4BD39.7050907@cs.tcd.ie> Date: Wed, 04 Jul 2012 23:01:29 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: "pzhang.thu" References: <20120703003402663560214@gmail.com>, <4FF2ACC3.1020004@cs.tcd.ie> <20120704160541638826251@gmail.com>, <4FF4B0D5.40906@cs.tcd.ie> <20120704174022735010267@gmail.com>, <4FF4B8C2.7090702@cs.tcd.ie> <20120704175739679926274@gmail.com> In-Reply-To: <20120704175739679926274@gmail.com> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "DECADE@ietf.org" Subject: Re: [decade] Object naming in -req and -arch 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, 04 Jul 2012 22:01:22 -0000 On 07/04/2012 10:57 PM, Zhang Peng wrote: > Ok, it seems to work. But it just includes the hash of public key. How to name a sequence of dynamic names? For example, the stream is divided into object by seconds: 1s, 2s, 3s,...? Some work TBD:-) I suspect that the details will need work in the decade WG. I'm confident that once we know we can handle dynamic content as in draft-hallambaker, then we can use the same approach for whatever decade-specifics are needed later. In the case you mention, maybe a chain of ni URIs might be needed included as some decade metadata with each 1s chunk and perhaps giving the name of the next chunk. But I suspect you've gone beyond naming requirements when you start to consider sets of related (parts of) objects. S. > B, > > Peng. > From: Stephen Farrell > Date: 2012-07-04 17:42 > To: pzhang.thu > CC: DECADE@ietf.org > Subject: Re: [decade] Object naming in -req and -arch > > > On 07/04/2012 10:40 PM, Zhang Peng wrote: >> Hi Stephen, >> >> Yes, for most cases, hash-based naming scheme is ok for in-network storage system which holds immutable objects. >> Bur for some application such as live streaming, we expect that the uploader/streamer can know the object name before it uploads the object to decade server. This will allow the streamer to advertise the file before fully uploading it, and then the viewer can fetch the object using the advertised name. If each object contains several seconds of video data, this feature can considerably reduce the latency. Thus, we may need a enumeration-based scheme besides the hash-based one. Can we add this feature in your proposed design? Thanks. > > Ah gotcha. Yes there are ways, basically by defining a new > hash alg and using a signature. There's one documented in > draft-hallambaker-decade-ni-params [1] section 2.1. > > Cheers, > S. > > [1] http://tools.ietf.org/html/draft-hallambaker-decade-ni-params-03 > >> B, >> >> Peng. >> >> From: Stephen Farrell >> Date: 2012-07-04 17:08 >> To: pzhang.thu >> CC: DECADE@ietf.org >> Subject: Re: [decade] Object naming in -req and -arch >> >> >> On 07/04/2012 09:05 PM, Zhang Peng wrote: >>> Hi Stephen, >>> >>> I have read your documents on hash-based naming. It designs a good URI format and mapping scheme to HTTP URL. For DECADE, since our requirements include uniqueness, name-object binding validation, I wonder how we can apply your scheme to meet them. >> >> ni URIs are as unique as the collision resistance of your hash >> function supports basically. If you pick sha-256 that won't be >> an issue. >> >> ni URis support name-data integrity (incl. in the code we've >> released) which I think is the same as what you're calling >> name-object binding validation. >> >> So my answer for both is: just use ni URIs to meet these >> requirements:-) >> >>> BTW, can you give more details on what you mean by "meets these requirements"? Thanks. >> >> I meant: if there's some requirement that can't be met using ni URIs, >> then I'd like to know about that before its too late. (I realise >> that the decade WG might still change reqs of course but wanted to >> check now before we're done with our doc.) >> >> S >> >>> B, >>> >>> Peng. >>> >>> From: Stephen Farrell >>> Date: 2012-07-03 03:26 >>> To: pzhang.thu >>> CC: DECADE@ietf.org >>> Subject: Re: [decade] Object naming in -req and -arch >>> >>> Hiya, >>> >>> I guess I hope that our draft (just exited IETF LC) meets >>> these requirements. If not, I'd be interested in what's >>> missing. >>> >>> Cheers, >>> S. >>> >>> [1] http://tools.ietf.org/html/draft-farrell-decade-ni >>> >>> On 07/03/2012 06:34 AM, Zhang Peng wrote: >>>> Dear DECADE participants, >>>> >>>> As pointed out by Richard in previous discussions, both the -req and -arch documents has some paragraphs describing content naming, and they need better organization: some generic requirements should be in -req, while some more specific ones should be in -arch. Here are some suggestions about how to split the content on naming in these two documents. >>>> >>>> The rationale for the following split is that I recognize there are two generic requirements, that is, uniqueness, and binding validation. They should be placed in the -req. In -arch, we should present the specific requirements to enable uniqueness, and binding validation, respectively. There are also some more requirements on how to improve the responsiveness of the system, i.e., the support of early name generation. See below for details (references to the original documents are given after each specific requirements): >>>> >>>> Generic requirements (to be put in -req) >>>> >>>> 1. It SHOULD ensure that uniqueness of object names. >>>> 2. It SHOULD support the validation of name-object binding. >>>> 3. It SHOULD support the operation of DECADE-compatible servers under diverse administrative domains with no coordination. (not sure about what operations are meant here) >>>> >>>> Specific requirements (to be put in -arch) >>>> >>>> Requirements to enable uniqueness: >>>> 1. It MAY enable applications to construct unique names by themselves with a high probability (ref: last sentence, pp. 11, -arch). If this is the case, it SHOULD indicate conflicts when duplicate names are constructed (ref: first para, 4.5.1, -req). >>>> 2. It MAY support content-dependent hash-based schemes (for general immutable objects), and content-independent enumeration-based schemes (for live streaming) >>>> (ref: 2nd para, pp. 12, -arch) >>>> >>>> Requirements to enable name-object binding validation: >>>> 3. Different name-object binding validation mechanisms MAY be supported, and an application can decide which mechanism to use. (ref: 2nd para, 4.4, -arch) >>>> 4. Names MAY be self-describing so that a receiving entity (Content Consumer) knows which mechanism is used (ref: 1st para, pp. 12, -arch) >>>> 5. It SHOULD provide the following name elements: (1) A "type" field, (2) Cryptographic data, (3) Application or publisher information. (ref: pp. 12, -arch) >>>> >>>> More requirements about performance: >>>> 6. It SHOULD support the scenarios where a client needs to know the name of a data object before it is completely stored at the server. (This is to let clients advertise the object before having fully uploaded it) (ref: second last para, pp. 12, -arch) >>>> 7. It SHOULD support the scenarios where a client need to know the name of a data object before it is locally created. (This is to support live streaming) (ref: last para, pp. 12, -arch) >>>> >>>> Any comments are welcome, thanks. >>>> >>>> Peng. From yang.r.yang@gmail.com Wed Jul 4 19:37:25 2012 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 C1E7921F8543 for ; Wed, 4 Jul 2012 19:37:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.492 X-Spam-Level: X-Spam-Status: No, score=-2.492 tagged_above=-999 required=5 tests=[AWL=-0.116, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_63=0.6, 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 NiRPNNczURGj for ; Wed, 4 Jul 2012 19:37:24 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id B619B21F8504 for ; Wed, 4 Jul 2012 19:37:24 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so14186671obb.31 for ; Wed, 04 Jul 2012 19:37:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=audG+vAZsXUqTaD94T4FgYoX8hmiOa++7pN6jb0NuLc=; b=wyI7+FpFunMpc4I9lY/UTUOt3I0tq1LoydgT6AIPcxkIIzq0CTN5CsUoVbvwQNBW1Q ZEv6pjtk06CLmbpwVItekFRYqAOW3NhMt8+3PjDuRmBY5oqdpYMLID1uMOk4qJj+qils ZmC+nX39493gGPgspSgOIebO904QjROLpOIBXzN7L8hVrTteQAWUZcfBBvdtq6DNoEHv I6WTey3D/heie9Cc5YJAW4/wMR4izzLifxgfFFZ+S+IW03ey6yWX9Q0nKZcNQOwhmBSw QcztaIKqtaKb5ZXs0jD/ZicEImRV9DyedURQ/xICLq2FcuYNm1C/eavMUDOBP1vWPToZ 0jzA== MIME-Version: 1.0 Received: by 10.60.26.134 with SMTP id l6mr24807525oeg.40.1341455856680; Wed, 04 Jul 2012 19:37:36 -0700 (PDT) Sender: yang.r.yang@gmail.com Received: by 10.76.86.136 with HTTP; Wed, 4 Jul 2012 19:37:36 -0700 (PDT) In-Reply-To: <4FF4BD39.7050907@cs.tcd.ie> References: <20120703003402663560214@gmail.com> <4FF2ACC3.1020004@cs.tcd.ie> <20120704160541638826251@gmail.com> <4FF4B0D5.40906@cs.tcd.ie> <20120704174022735010267@gmail.com> <4FF4B8C2.7090702@cs.tcd.ie> <20120704175739679926274@gmail.com> <4FF4BD39.7050907@cs.tcd.ie> Date: Thu, 5 Jul 2012 10:37:36 +0800 X-Google-Sender-Auth: y_eFdp5sgMhLLMzxvzHEa1e2W20 Message-ID: From: "Y. Richard Yang" To: Stephen Farrell Content-Type: multipart/alternative; boundary=e89a8ff1c63cd1bf7404c40c0774 Cc: "DECADE@ietf.org" , arno@cs.vu.nl Subject: Re: [decade] Object naming in -req and -arch 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, 05 Jul 2012 02:37:25 -0000 --e89a8ff1c63cd1bf7404c40c0774 Content-Type: text/plain; charset=ISO-8859-1 Hi Stephen, Peng, On Thursday, July 5, 2012, Stephen Farrell wrote: > > > On 07/04/2012 10:57 PM, Zhang Peng wrote: > > Ok, it seems to work. But it just includes the hash of public key. How > to name a sequence of dynamic names? For example, the stream is divided > into object by seconds: 1s, 2s, 3s,...? > > Some work TBD:-) > > I suspect that the details will need work in the decade WG. > > I'm confident that once we know we can handle dynamic > content as in draft-hallambaker, then we can use the same > approach for whatever decade-specifics are needed later. > > In the case you mention, maybe a chain of ni URIs might > be needed included as some decade metadata with each > 1s chunk and perhaps giving the name of the next chunk. PPSP uses Merkle Hash tree for (integrity check on) a sequence of data: http://tools.ietf.org/html/draft-ietf-ppsp-peer-protocol-02 Section 5. How relevant is this for decade naming? But I suspect you've gone beyond naming requirements > when you start to consider sets of related (parts of) > objects. > > Personally, I agree. But I am not sure any feedback from iesg or the > general community. > > -yry > > B, > > > > Peng. > > From: Stephen Farrell > > Date: 2012-07-04 17:42 > > To: pzhang.thu > > CC: DECADE@ietf.org > > Subject: Re: [decade] Object naming in -req and -arch > > > > > > On 07/04/2012 10:40 PM, Zhang Peng wrote: > >> Hi Stephen, > >> > >> Yes, for most cases, hash-based naming scheme is ok for in-network > storage system which holds immutable objects. > >> Bur for some application such as live streaming, we expect that the > uploader/streamer can know the object name before it uploads the object to > decade server. This will allow the streamer to advertise the file before > fully uploading it, and then the viewer can fetch the object using the > advertised name. If each object contains several seconds of video data, > this feature can considerably reduce the latency. Thus, we may need a > enumeration-based scheme besides the hash-based one. Can we add this > feature in your proposed design? Thanks. > > > > Ah gotcha. Yes there are ways, basically by defining a new > > hash alg and using a signature. There's one documented in > > draft-hallambaker-decade-ni-params [1] section 2.1. > > > > Cheers, > > S. > > > > [1] http://tools.ietf.org/html/draft-hallambaker-decade-ni-params-03 > > > >> B, > >> > >> Peng. > >> > >> From: Stephen Farrell > >> Date: 2012-07-04 17:08 > >> To: pzhang.thu > >> CC: DECADE@ietf.org > >> Subject: Re: [decade] Object naming in -req and -arch > >> > >> > >> On 07/04/2012 09:05 PM, Zhang Peng wrote: > >>> Hi Stephen, > >>> > >>> I have read your documents on hash-based naming. It designs a good URI > format and mapping scheme to HTTP URL. For DECADE, since our requirements > include uniqueness, name-object binding validation, I wonder how we can > apply your scheme to meet them. > >> > >> ni URIs are as unique as the collision resistance of your hash > >> function supports basically. If you pick sha-256 that won't be > >> an issue. > >> > >> ni URis support name-data integrity (incl. in the code we've > >> released) which I think is the same as what you're calling > >> name-object binding validation. > >> > >> So my answer for both is: just use ni URIs to meet these > >> requirements:-) > >> > >>> BTW, can you give more details on what you mean by "meets these > requirements"? Thanks. > >> > >> I meant: if there's some requirement that can't be met using ni URIs, > >> then I'd like to know about that before its too late. (I realise > >> that the decade WG might still change reqs of course but wanted to > >> check now before we're done with our doc.) > >> > >> S > >> > >>> B, > >>> > >>> Peng. > >>> > >>> From: Stephen Farrell > >>> Date: 2012-07-03 03:26 > >>> To: pzhang.thu > >>> CC: DECADE@ietf.org > >>> Subject: Re: [decade] Object naming in -req and -arch > >>> > >>> Hiya, > >>> > >>> I guess I hope that our draft (just exited IETF LC) meets > >>> these requirements. If not, I'd be interested in what's > >>> missing. > >>> > >>> Cheers, > >>> S. > >>> > >>> [1] http://tools.ietf.org/html/draft-farrell-decade-ni > >>> > >>> On 07/03/2012 06:34 AM, Zhang Peng wrote: > >>>> Dear DECADE participants, > >>>> > >>>> As pointed out by Richard in previous discussions, both the -req and > -arch documents has some paragraphs describing content naming, and they > need better organization: some generic requirements should be in -req, > while some more specific ones should be in -arch. Here are some suggestions > about how to split the content on naming in these two documents. > >>>> > >>>> The rationale for the following split is that I recognize there are > two generic requirements, that is, uniqueness, and binding validation. They > should be placed in the -req. In -arch, we should present the specific > requirements to enable uniqueness, and binding validation, respectively. > There are also so > --e89a8ff1c63cd1bf7404c40c0774 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Stephen, Peng,

On Thursday, July 5, 2012, Stephe= n Farrell wrote:


On 07/04/2012 10:57 PM, Zhang Peng wrote:
> Ok, it seems to work. But it just includes the hash of public key. How= to name a sequence of dynamic names? For example, the stream is divided in= to object by seconds: 1s, 2s, 3s,...?

Some work TBD:-)

I suspect that the details will need work in the decade WG.

I'm confident that once we know we can handle dynamic
content as in draft-hallambaker, then we can use the same
approach for whatever decade-specifics are needed later.

In the case you mention, maybe a chain of ni URIs might
be needed included as some decade metadata with each
1s chunk and perhaps giving the name of the next chunk.
PPSP uses Merkle Hash tree f= or (integrity check on) a sequence of data:
=A0
Section 5.

<= div> How relevant is this for decade naming?

But I suspect you've gone beyon= d naming requirements
when you start to consider sets of related (parts of)
objects.

Personally, I agree. But I am n= ot sure any feedback from iesg or the general community.

-yry
> B,
>
> Peng.
> From: Stephen Farrell
> Date: 2012-07-04 17:42
> To: pzhang.thu
> CC: DECADE@ietf.org
> Subject: Re: [decade] Object naming in -req and -arch
>
>
> On 07/04/2012 10:40 PM, Zhang Peng wrote:
>> Hi Stephen,
>>
>> Yes, for most cases, hash-based naming scheme is ok for in-network= storage system which holds immutable objects.
>> Bur for some application such as live streaming, we expect that th= e uploader/streamer can know the object name before it uploads the object t= o decade server. This will allow the streamer to advertise the file before = fully uploading it, and then the viewer can fetch the object using the adve= rtised name. If each object contains several seconds of video data, this fe= ature can considerably reduce the latency. Thus, we may need a enumeration-= based scheme besides the hash-based one. Can we add this feature in your pr= oposed design? Thanks.
>
> Ah gotcha. Yes there are ways, basically by defining a new
> hash alg and using a signature. There's one documented in
> draft-hallambaker-decade-ni-params [1] section 2.1.
>
> Cheers,
> S.
>
> [1] http://tools.ietf.org/html/draft-hallambaker-d= ecade-ni-params-03
>
>> B,
>>
>> Peng.
>>
>> From: Stephen Farrell
>> Date: 2012-07-04 17:08
>> To: pzhang.thu
>> CC: DECADE@ietf.org
>> Subject: Re: [decade] Object naming in -req and -arch
>>
>>
>> On 07/04/2012 09:05 PM, Zhang Peng wrote:
>>> Hi Stephen,
>>>
>>> I have read your documents on hash-based naming. It designs a = good URI format and mapping scheme to HTTP URL. For DECADE, since our requi= rements include uniqueness, name-object binding validation, I wonder how we= can apply your scheme to meet them.
>>
>> ni URIs are as unique as the collision resistance of your hash
>> function supports basically. If you pick sha-256 that won't be=
>> an issue.
>>
>> ni URis support name-data integrity (incl. in the code we've >> released) which I think is the same as what you're calling
>> name-object binding validation.
>>
>> So my answer for both is: just use ni URIs to meet these
>> requirements:-)
>>
>>> BTW, can you give more details on what you mean by "meets= these requirements"? Thanks.
>>
>> I meant: if there's some requirement that can't be met usi= ng ni URIs,
>> then I'd like to know about that before its too late. (I reali= se
>> that the decade WG might still change reqs of course but wanted to=
>> check now before we're done with our doc.)
>>
>> S
>>
>>> B,
>>>
>>> Peng.
>>>
>>> From: Stephen Farrell
>>> Date: 2012-07-03 03:26
>>> To: pzhang.thu
>>> CC: DECADE@ietf.org
>>> Subject: Re: [decade] Object naming in -req and -arch
>>>
>>> Hiya,
>>>
>>> I guess I hope that our draft (just exited IETF LC) meets
>>> these requirements. If not, I'd be interested in what'= s
>>> missing.
>>>
>>> Cheers,
>>> S.
>>>
>>> [1] http://tools.ietf.org/html/draft-farrell-decade-ni
>>>
>>> On 07/03/2012 06:34 AM, Zhang Peng wrote:
>>>> Dear DECADE participants,
>>>>
>>>> As pointed out by Richard in previous discussions, both th= e -req and -arch documents has some paragraphs describing content naming, a= nd they need better organization: some generic requirements should be in -r= eq, while some more specific ones should be in -arch. Here are some suggest= ions about how to split the content on naming in these two documents.
>>>>
>>>> The rationale for the following split is that I recognize = there are two generic requirements, that is, uniqueness, and binding valida= tion. They should be placed in the -req. In -arch, we should present the sp= ecific requirements to enable uniqueness, and binding validation, respectiv= ely. There are also so
=
=

=A0

=A0
--e89a8ff1c63cd1bf7404c40c0774-- From haibin.song@huawei.com Wed Jul 4 20:00:20 2012 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 5E1CD11E8099 for ; Wed, 4 Jul 2012 20:00:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.223 X-Spam-Level: X-Spam-Status: No, score=-6.223 tagged_above=-999 required=5 tests=[AWL=0.376, 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 NC-JDUfOGDoM for ; Wed, 4 Jul 2012 20:00:19 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id AAD7111E808D for ; Wed, 4 Jul 2012 20:00:19 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AHS44556; Wed, 04 Jul 2012 23:00:32 -0400 (EDT) Received: from DFWEML406-HUB.china.huawei.com (10.193.5.131) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 4 Jul 2012 19:58:25 -0700 Received: from SZXEML407-HUB.china.huawei.com (10.82.67.94) by dfweml406-hub.china.huawei.com (10.193.5.131) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 4 Jul 2012 19:58:23 -0700 Received: from SZXEML534-MBX.china.huawei.com ([169.254.2.243]) by szxeml407-hub.china.huawei.com ([10.82.67.94]) with mapi id 14.01.0323.003; Thu, 5 Jul 2012 10:58:15 +0800 From: Songhaibin To: "decade@ietf.org" Thread-Topic: [decade] I-D Action: draft-ietf-decade-integration-example-04.txt Thread-Index: AQHNT1ve7h+hzXN3OkG0Mpo80yBHF5caE82A Date: Thu, 5 Jul 2012 02:58:15 +0000 Message-ID: References: <20120621031333.24814.83113.idtracker@ietfa.amsl.com> In-Reply-To: <20120621031333.24814.83113.idtracker@ietfa.amsl.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.73] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [decade] I-D Action: draft-ietf-decade-integration-example-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: Thu, 05 Jul 2012 03:00:20 -0000 SSBqdXN0IGNoZWNrZWQgdGhpcyBkb2N1bWVudC4gTW9zdCBvZiBteSBjb21tZW50cyBhcmUgYWRk cmVzc2VkIGluIHRoaXMgdmVyc2lvbi4gQnV0IHRoZSBhdXRob3JzIGRpZCBub3QgY2hhbmdlIHRo ZSBGaWd1cmUgNCAoRmlndXJlIDUgaW4gcHJldmlvdXMgdmVyc2lvbiksIGFuZCBkaWQgbm90IHJl bW92ZSBleHRyYSBzcGFjZXMgYmVmb3JlIHNvbWUgc2VudGVuY2VzIGluIHRoZSBwYXJhZ3JhcGhz LiBZb3UgY2FuIHNlYXJjaCBmb3IgdHdvIHNwYWNlcyB0byBmaW5kIHRoZW0gYW5kIHJlcGxhY2Ug d2l0aCBvbmx5IG9uZSBzcGFjZTopDQoNCkJSLA0KLUhhaWJpbg0KDQoNCj4gLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogZGVjYWRlLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpk ZWNhZGUtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mDQo+IGludGVybmV0LWRyYWZ0c0Bp ZXRmLm9yZw0KPiBTZW50OiBUaHVyc2RheSwgSnVuZSAyMSwgMjAxMiAxMToxNCBBTQ0KPiBUbzog aS1kLWFubm91bmNlQGlldGYub3JnDQo+IENjOiBkZWNhZGVAaWV0Zi5vcmcNCj4gU3ViamVjdDog W2RlY2FkZV0gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1kZWNhZGUtaW50ZWdyYXRpb24tZXhhbXBs ZS0wNC50eHQNCj4gDQo+IA0KPiBBIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJv bSB0aGUgb24tbGluZSBJbnRlcm5ldC1EcmFmdHMgZGlyZWN0b3JpZXMuDQo+ICBUaGlzIGRyYWZ0 IGlzIGEgd29yayBpdGVtIG9mIHRoZSBEZWNvdXBsZWQgQXBwbGljYXRpb24gRGF0YSBFbnJvdXRl IFdvcmtpbmcNCj4gR3JvdXAgb2YgdGhlIElFVEYuDQo+IA0KPiAJVGl0bGUgICAgICAgICAgIDog SW50ZWdyYXRpb24gRXhhbXBsZXMgb2YgREVDQURFIFN5c3RlbQ0KPiAJQXV0aG9yKHMpICAgICAg IDogTmluZyBab25nDQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgWGlhb2h1aSBDaGVuDQo+ ICAgICAgICAgICAgICAgICAgICAgICAgICAgWmhpZ2FuZyBIdWFuZw0KPiAgICAgICAgICAgICAg ICAgICAgICAgICAgIExpamlhbmcgQ2hlbg0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgIEhv bmdxaWFuZyBMaXUNCj4gCUZpbGVuYW1lICAgICAgICA6IGRyYWZ0LWlldGYtZGVjYWRlLWludGVn cmF0aW9uLWV4YW1wbGUtMDQudHh0DQo+IAlQYWdlcyAgICAgICAgICAgOiAyMw0KPiAJRGF0ZSAg ICAgICAgICAgIDogMjAxMi0wNi0yMA0KPiANCj4gQWJzdHJhY3Q6DQo+ICAgIERlY291cGxlZCBB cHBsaWNhdGlvbiBEYXRhIEVucm91dGUgKERFQ0FERSkgc3lzdGVtIGlzIGFuIGluLW5ldHdvcmsN Cj4gICAgc3RvcmFnZSBpbmZyYXN0cnVjdHVyZSB3aGljaCBpcyBzdGlsbCB1bmRlciBkaXNjdXNz aW9uIGluIElFVEYuICBUaGlzDQo+ICAgIGRvY3VtZW50IHByZXNlbnRzIHR3byBkZXRhaWxlZCBl eGFtcGxlcyBvZiBob3cgdG8gaW50ZWdyYXRlIHN1Y2ggaW4tDQo+ICAgIG5ldHdvcmsgc3RvcmFn ZSBpbmZyYXN0cnVjdHVyZSBpbnRvIHBlZXItdG8tcGVlciAoUDJQKSBhcHBsaWNhdGlvbnMNCj4g ICAgdG8gYWNoaWV2ZSBtb3JlIGVmZmljaWVudCBjb250ZW50IGRpc3RyaWJ1dGlvbiwgYW5kIEFw cGxpY2F0aW9uIExheWVyDQo+ICAgIFRyYWZmaWMgT3B0aW1pemF0aW9uIChBTFRPKSBzeXN0ZW0g dG8gYnVpbGQgYSBjb250ZW50IGRpc3RyaWJ1dGlvbg0KPiAgICBwbGF0Zm9ybSBmb3IgQ29udGVu dCBQcm92aWRlcnMgKENQcykuDQo+IA0KPiANCj4gVGhlIElFVEYgZGF0YXRyYWNrZXIgc3RhdHVz IHBhZ2UgZm9yIHRoaXMgZHJhZnQgaXM6DQo+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv ZG9jL2RyYWZ0LWlldGYtZGVjYWRlLWludGVncmF0aW9uLWV4YW1wbGUNCj4gDQo+IFRoZXJlJ3Mg YWxzbyBhIGh0bWxpemVkIHZlcnNpb24gYXZhaWxhYmxlIGF0Og0KPiBodHRwOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWRlY2FkZS1pbnRlZ3JhdGlvbi1leGFtcGxlLTA0DQo+IA0K PiBBIGRpZmYgZnJvbSBwcmV2aW91cyB2ZXJzaW9uIGlzIGF2YWlsYWJsZSBhdDoNCj4gaHR0cDov L3Rvb2xzLmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLWRlY2FkZS1pbnRlZ3JhdGlv bi1leGFtcGxlLTA0DQo+IA0KPiANCj4gSW50ZXJuZXQtRHJhZnRzIGFyZSBhbHNvIGF2YWlsYWJs ZSBieSBhbm9ueW1vdXMgRlRQIGF0Og0KPiBmdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJh ZnRzLw0KDQo= From Akbar.Rahman@InterDigital.com Wed Jul 4 22:21:07 2012 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 0E18A21F8579 for ; Wed, 4 Jul 2012 22:21:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 Z36vXPn1i05Z for ; Wed, 4 Jul 2012 22:21:03 -0700 (PDT) Received: from idcout.InterDigital.com (smtp-out1.interdigital.com [64.208.228.135]) by ietfa.amsl.com (Postfix) with ESMTP id C926021F8573 for ; Wed, 4 Jul 2012 22:21:01 -0700 (PDT) Received: from SAM.InterDigital.com ([10.30.2.11]) by idcout.InterDigital.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 5 Jul 2012 01:21:13 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Thu, 5 Jul 2012 01:21:12 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [decade] Working Group Last Call: draft-ietf-decade-arch-07 Thread-Index: Ac1PUmra8pF/55OcSfCOdrGa28N+SwLFn0TQ References: From: "Rahman, Akbar" To: X-OriginalArrivalTime: 05 Jul 2012 05:21:13.0297 (UTC) FILETIME=[FE98BC10:01CD5A6D] Cc: Konstantinos Pentikousis Subject: Re: [decade] Working Group Last Call: draft-ietf-decade-arch-07 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, 05 Jul 2012 05:21:07 -0000 Hi, The DECADE Architecture authors were contacted off list by Kostas who provided the following relevant and useful comments on the draft-ietf-decade-arch-07. We intend to address these comments in the next revision of the architecture I-D after the WGLC ends. =20 1) Figure 1:=20 This figure and the accompanying text (as-is right now) leaves quite some room for interpretation. For example, two distinct "DECADE-compatible" systems deployed by two different operators may have DRP1 vs. DPR2, in addition to having multiple SDTxyz's. Is this what you have in mind? 2) Section 4.2, Referring to the word "multipath": =20 I think you mean multi-source here? Multipath is mostly related with two (multihomed) end nodes and routing in the network rather than one node getting bits and pieces of a data object from different sources (as in P2P). You can still have multipath and single-source. 3) Section 4.2, third paragraph, first sentence: As per the sec. 2.8, a "data object is a string of raw bytes". Therefore, in this sentence we need s/SHOULD/MUST. 4) Section 4.2, third paragraph, second sentence: This may introduce the issue of MDO discovery (max data object), when one connects to different DECADE Servers, perhaps along the lines of MTU discovery. Content resegmentation is not covered in this section, esp. since a DECADE server may store/maintain DOs from completely different apps. 5) Section 4.2, last paragraph: The introduction of the "block" may be redundant here. A block is, similarly to a DO, "a string of raw bytes", isn't it? If not, we need a formal definition for it. Of course, the key aspect here is what can you name and locate in a DECADE Server, and my reading of the ID so far is that you have settled on the use of the DO, irrespective of the application semantics. The repeated use of "block" here and there simply confuses the uninitiated reader. 6) Section 4.4, 2nd to last paragraph: I think the optimization described in this paragraph is not particularly suited for the Architecture document. And it opens up all kinds of questions. E.G. what if the host advertizing an object crashes before it uploads the object? What if the host changes its mind during the upload? Since we're talking about immutable objects, shouldn't we wait until an object is "committed". In the end, this optimization could be counter-productive in these cases. Let alone the fact that the scenarios for which DECADE is envisaged (and motivated from I would add) tend to have asymmetric capacities in down/uplink, perhaps of a ratio of 10:1. Thus, downloading is not typically the performance bottleneck. Perhaps I am wrong in thinking of this as a premature optimization though. Can you provide examples from exisiting apps that follow this proposal (and how do they handle error cases)?=20 Moreover, using SHOULD for such a optimization may not be a good idea in the general case. 7) Figure 3: This figure implies that multiple applications will need to implement their own DECADE client, which cannot be shared at run time with other apps. Of course one could see this as including/linking to a library, but perhaps a more flexible implementation could also be thought of, based, for example, on a DECADE "platform", shared by many apps at run time. 8) Section 6.1.2, second to last paragraph: This proposed optimization need not be part of the "architecture" 9) Section 6.1.3: Wouldn't it be better to skip this section altogether and consider an ID on management aspects instead? For example, why not simply define an MIB for DECADE and use existing methods to obtain this status info? Why add more complexity in DRP implementations? 10) Section 10.2: http://dx.doi.org/10.1145/1544012.1544078 should also be added here, as it motivates well the domain considered in this architecture, including the DO. 11) Various editorial and grammatical fixes (which were provided to the authors off line). Many thanks to Kostas for providing these excellent comments. Akbar -----Original Message----- From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.org] On Behalf Of Songhaibin Sent: Wednesday, June 20, 2012 10:06 PM To: decade@ietf.org Subject: [decade] Working Group Last Call: draft-ietf-decade-arch-07 Dear folks, After the first round of the last call, the architecture document has many changes to resolve comments from reviewers as well as area director and experts from other areas. Thanks to the reviewers and the authors. So Rich and I now start another round of WGLC on draft-ietf-decade-arch-07, ending Friday, July 6th. Please review the document and reply with your comments. Thanks, -Haibin and Rich (co-chairs) From wangdanhua@huawei.com Thu Jul 5 01:50:09 2012 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 56BCF21F85D6 for ; Thu, 5 Jul 2012 01:50:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.263 X-Spam-Level: X-Spam-Status: No, score=0.263 tagged_above=-999 required=5 tests=[AWL=-2.187, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, 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 R-ackjFhRkLu for ; Thu, 5 Jul 2012 01:50:08 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 66B5D21F84FF for ; Thu, 5 Jul 2012 01:50:07 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AHL37079; Thu, 05 Jul 2012 04:50:20 -0400 (EDT) Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 5 Jul 2012 01:47:59 -0700 Received: from SZXEML411-HUB.china.huawei.com (10.82.67.138) by dfweml405-hub.china.huawei.com (10.193.5.102) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 5 Jul 2012 01:47:57 -0700 Received: from SZXEML507-MBS.china.huawei.com ([169.254.7.110]) by szxeml411-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.003; Thu, 5 Jul 2012 16:47:51 +0800 From: Wangdanhua To: pzhang.thu , "DECADE@ietf.org" Thread-Topic: =?gb2312?B?tPC4tDogW2RlY2FkZV0gT2JqZWN0IG5hbWluZyBpbiAtcmVxIGFuZCAtYXJj?= =?gb2312?Q?h?= Thread-Index: AQHNWNUbyNbHw+cbqUmayHoYgFM2YJcZcsHugAB7ebA= Date: Thu, 5 Jul 2012 08:47:51 +0000 Message-ID: References: <20120703003402663560214@gmail.com>, <20120704142404303001237@gmail.com> In-Reply-To: <20120704142404303001237@gmail.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.177] Content-Type: multipart/alternative; boundary="_000_AFD688AF30E249418739DBDC55B9C75B34D628EDSZXEML507MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [decade] =?gb2312?b?tPC4tDogtPC4tDogIE9iamVjdCBuYW1pbmcgaW4gLXJl?= =?gb2312?b?cSBhbmQgLWFyY2g=?= 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, 05 Jul 2012 08:50:09 -0000 --_000_AFD688AF30E249418739DBDC55B9C75B34D628EDSZXEML507MBSchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgUGVuZywNCllvdXIgZXhwbGFuYXRpb24gbWFrZXMgc2Vuc2UgdG8gbWUuIFRoYW5rcyBhIGxv dC4NCg0KQmVzdCB3aXNoZXMsDQpEYW5odWENCg0Kt6K8/sjLOiBaaGFuZyBQZW5nIFttYWlsdG86 cHpoYW5nLnRodUBnbWFpbC5jb21dPG1haWx0bzpbbWFpbHRvOnB6aGFuZy50aHVAZ21haWwuY29t XT4NCreiy83KsbzkOiAyMDEyxOo31MI1yNUgMjoyNA0KytW8/sjLOiBXYW5nZGFuaHVhOyBERUNB REVAaWV0Zi5vcmc8bWFpbHRvOkRFQ0FERUBpZXRmLm9yZz4NCtb3zOI6ILvYuLQ6ILTwuLQ6IFtk ZWNhZGVdIE9iamVjdCBuYW1pbmcgaW4gLXJlcSBhbmQgLWFyY2gNCg0KSGkgRGFuaHVhLA0KDQpU aGFua3MgZm9yIHlvdXIgY29tbWVudHMuIEkgdGhpbmsgeW91ciBjb21tZW50cyBhcmUgdmVyeSBy ZWFzb25hYmxlLiBCdXQgSSBzdGlsbCB0aGluayB0aGUgcmVxdWlyZW1lbnQgIkl0IE1BWSBlbmFi bGUgYXBwbGljYXRpb25zIHRvIGNvbnN0cnVjdCB1bmlxdWUgbmFtZXMgdy5oLnAuIiArICJ0aGUg bmFtaW5nIHNjaGVtZSBzaG91bGQgaW5kaWNhdGVkIGNvbmZsaWN0cyIgaXMganVzdCBvbmUgYXBw cm9hY2ggdG8gZW5zdXJlIHVuaXF1ZW5lc3MuIEl0IGlzIGJlY2F1c2Ugd2UgY2FuIGFsc28gbGV0 IHRoZSBERUNBREUgc2VydmljZSBwcm92aWRlcnMgYXNzaWduIHRoZSBuYW1lIHRvIGVuc3VyZSB1 bmlxdWVuZXNzLiBUaHVzLCBJIHRoaW5rIHdlIGJldHRlciBqdXN0IHN0YXRlIHRoZSBnZW5lcmlj IHJlcXVpcmVtZW50IHRoYXQgIm5hbWVzIHNob3VsZCBiZSB1bmlxdWUiIHdpdGhvdXQgZ29pbmcg aW50byBkZXRhaWxzIG9mIHRoZSBkZXNpZ24gaW4gLXJlcSwgYW5kIGdpdmUgdGhlIGRldGFpbGVk IHJlcXVpcmVtZW50cyBmb3Igb3VyIGRlc2lnbiAoaS5lLiwgZW5hYmxlIGFwcHMgdG8gZ2l2ZW4g bmFtZXMgdy5oLnAuLCBhbmQgaW5kaWNhdGUgY29uZmxpY3RzIHdoZW4gbmVjZXNzYXJ5KSBpbiAt YXJjaC4gV2hhdCB3b3VsZCB5b3UgdGhpbms/DQoNClRoYW5rcywNCg0KUGVuZy4NCg0Kt6K8/sjL o7ogV2FuZ2Rhbmh1YTxtYWlsdG86d2FuZ2Rhbmh1YUBodWF3ZWkuY29tPg0Kt6LLzcqxvOSjuiAy MDEyLTA3LTA0IDA1OjE0DQrK1bz+yMujuiBwemhhbmcudGh1PG1haWx0bzpwemhhbmcudGh1QGdt YWlsLmNvbT47IERFQ0FERUBpZXRmLm9yZzxtYWlsdG86REVDQURFQGlldGYub3JnPg0K1vfM4qO6 ILTwuLQ6IFtkZWNhZGVdIE9iamVjdCBuYW1pbmcgaW4gLXJlcSBhbmQgLWFyY2gNCkhpIFBlbmcs DQoNCkFzIHRvIFEyLCBJIGFncmVlIHdpdGggeW91IHRoYXQgdGhlIGNvbnRlbnQgbmFtaW5nIHJl cXVpcmVtZW50IHBhcnQgaW4gqENhcmNoIGhhZCBiZXR0ZXIgYmUgbW92ZWQgdG8gqENyZXEsIGFu ZCB0aGUgobBpbW11dGFibGUgZGF0YSBvYmplY3ShsSBzaG91bGQgYmUgcmVtYWluZWQgaW4gqENh cmNoLg0KDQpBcyB0byB0aGUgZ2VuZXJpYyByZXF1aXJlbWVudHMgdnMuIHNwZWNpZmljIHJlcXVp cmVtZW50cyB5b3UgZW51bWVyYXRlZCwgSaGvbSBhIGxpdHRsZSBjb25mdXNlZC4gRm9yIGV4YW1w bGUsIGFzIHRvIHRoZSChsFJlcXVpcmVtZW50cyB0byBlbmFibGUgdW5pcXVlbmVzc6GxLCBJIHRo aW5rIKGwaXQgU0hPVUxEIGluZGljYXRlIGNvbmZsaWN0cyB3aGVuIGR1cGxpY2F0ZSBuYW1lcyBh cmUgY29uc3RydWN0ZWQgKHJlZjogZmlyc3QgcGFyYSwgNC41LjEsIC1yZXEpobEgaXMgYWxzbyB0 aGUgZGV0YWlsZWQgZGVzY3JpcHRpb24vZGVtYW5kIG9mIHRoZSBnZW5lcmljIHJlcXVpcmVtZW50 IKGwZW5zdXJlIHRoZSB1bmlxdWVuZXNzIG9mIG9iamVjdCBuYW1lc6GxLiBJbiBteSBvcGluaW9u LCBzdWNoIHJlcXVpcmVtZW50cyBzaG91bGQgYWxzbyBiZSBwcmVzZW50ZWQgaW4gqENyZXEuIEkg d29uZGVyIGlmIG15IHVuZGVyc3RhbmRpbmcgaXMgcmlnaHQuDQoNCkJlc3Qgd2lzaGVzLA0KRGFu aHVhDQoNCg0Kt6K8/sjLOiBkZWNhZGUtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86ZGVjYWRlLWJv dW5jZXNAaWV0Zi5vcmc+IFttYWlsdG86ZGVjYWRlLWJvdW5jZXNAaWV0Zi5vcmddPG1haWx0bzpb bWFpbHRvOmRlY2FkZS1ib3VuY2VzQGlldGYub3JnXT4gtPqx7SBaaGFuZyBQZW5nDQq3osvNyrG8 5DogMjAxMsTqN9TCM8jVIDEzOjM0DQrK1bz+yMs6IERFQ0FERUBpZXRmLm9yZzxtYWlsdG86REVD QURFQGlldGYub3JnPg0K1vfM4jogW2RlY2FkZV0gT2JqZWN0IG5hbWluZyBpbiAtcmVxIGFuZCAt YXJjaA0KDQpEZWFyIERFQ0FERSBwYXJ0aWNpcGFudHMsDQoNCkFzIHBvaW50ZWQgb3V0IGJ5IFJp Y2hhcmQgaW4gcHJldmlvdXMgZGlzY3Vzc2lvbnMsIGJvdGggdGhlIC1yZXEgYW5kIC1hcmNoIGRv Y3VtZW50cyBoYXMgc29tZSBwYXJhZ3JhcGhzIGRlc2NyaWJpbmcgY29udGVudCBuYW1pbmcsIGFu ZCB0aGV5IG5lZWQgYmV0dGVyIG9yZ2FuaXphdGlvbjogc29tZSBnZW5lcmljIHJlcXVpcmVtZW50 cyBzaG91bGQgYmUgaW4gLXJlcSwgd2hpbGUgc29tZSBtb3JlIHNwZWNpZmljIG9uZXMgc2hvdWxk IGJlIGluIC1hcmNoLiBIZXJlIGFyZSBzb21lIHN1Z2dlc3Rpb25zIGFib3V0IGhvdyB0byBzcGxp dCB0aGUgY29udGVudCBvbiBuYW1pbmcgaW4gdGhlc2UgdHdvIGRvY3VtZW50cy4NCg0KVGhlIHJh dGlvbmFsZSBmb3IgdGhlIGZvbGxvd2luZyBzcGxpdCBpcyB0aGF0IEkgcmVjb2duaXplIHRoZXJl IGFyZSB0d28gZ2VuZXJpYyByZXF1aXJlbWVudHMsIHRoYXQgaXMsIHVuaXF1ZW5lc3MsIGFuZCBi aW5kaW5nIHZhbGlkYXRpb24uIFRoZXkgc2hvdWxkIGJlIHBsYWNlZCBpbiB0aGUgLXJlcS4gSW4g LWFyY2gsIHdlIHNob3VsZCBwcmVzZW50IHRoZSBzcGVjaWZpYyByZXF1aXJlbWVudHMgdG8gZW5h YmxlIHVuaXF1ZW5lc3MsIGFuZCBiaW5kaW5nIHZhbGlkYXRpb24sIHJlc3BlY3RpdmVseS4gVGhl cmUgYXJlIGFsc28gc29tZSBtb3JlIHJlcXVpcmVtZW50cyBvbiBob3cgdG8gaW1wcm92ZSB0aGUg cmVzcG9uc2l2ZW5lc3Mgb2YgdGhlIHN5c3RlbSwgaS5lLiwgdGhlIHN1cHBvcnQgb2YgZWFybHkg bmFtZSBnZW5lcmF0aW9uLiBTZWUgYmVsb3cgZm9yIGRldGFpbHMgKHJlZmVyZW5jZXMgdG8gdGhl IG9yaWdpbmFsIGRvY3VtZW50cyBhcmUgZ2l2ZW4gYWZ0ZXIgZWFjaCBzcGVjaWZpYyByZXF1aXJl bWVudHMpOg0KDQpHZW5lcmljIHJlcXVpcmVtZW50cyAodG8gYmUgcHV0IGluIC1yZXEpDQoNCjEu IEl0IFNIT1VMRCBlbnN1cmUgdGhhdCB1bmlxdWVuZXNzIG9mIG9iamVjdCBuYW1lcy4NCjIuIEl0 IFNIT1VMRCBzdXBwb3J0IHRoZSB2YWxpZGF0aW9uIG9mIG5hbWUtb2JqZWN0IGJpbmRpbmcuDQoz LiBJdCBTSE9VTEQgc3VwcG9ydCB0aGUgb3BlcmF0aW9uIG9mIERFQ0FERS1jb21wYXRpYmxlIHNl cnZlcnMgdW5kZXIgZGl2ZXJzZSBhZG1pbmlzdHJhdGl2ZSBkb21haW5zIHdpdGggbm8gY29vcmRp bmF0aW9uLiAobm90IHN1cmUgYWJvdXQgd2hhdCBvcGVyYXRpb25zIGFyZSBtZWFudCBoZXJlKQ0K DQpTcGVjaWZpYyByZXF1aXJlbWVudHMgKHRvIGJlIHB1dCBpbiAtYXJjaCkNCg0KUmVxdWlyZW1l bnRzIHRvIGVuYWJsZSB1bmlxdWVuZXNzOg0KMS4gSXQgTUFZIGVuYWJsZSBhcHBsaWNhdGlvbnMg dG8gY29uc3RydWN0IHVuaXF1ZSBuYW1lcyBieSB0aGVtc2VsdmVzIHdpdGggYSBoaWdoIHByb2Jh YmlsaXR5IChyZWY6IGxhc3Qgc2VudGVuY2UsIHBwLiAxMSwgLWFyY2gpLiBJZiB0aGlzIGlzIHRo ZSBjYXNlLCBpdCBTSE9VTEQgaW5kaWNhdGUgY29uZmxpY3RzIHdoZW4gZHVwbGljYXRlIG5hbWVz IGFyZSBjb25zdHJ1Y3RlZCAocmVmOiBmaXJzdCBwYXJhLCA0LjUuMSwgLXJlcSkuDQoyLiBJdCBN QVkgc3VwcG9ydCBjb250ZW50LWRlcGVuZGVudCBoYXNoLWJhc2VkIHNjaGVtZXMgKGZvciBnZW5l cmFsIGltbXV0YWJsZSBvYmplY3RzKSwgYW5kIGNvbnRlbnQtaW5kZXBlbmRlbnQgZW51bWVyYXRp b24tYmFzZWQgc2NoZW1lcyAoZm9yIGxpdmUgc3RyZWFtaW5nKQ0KKHJlZjogMm5kIHBhcmEsIHBw LiAxMiwgLWFyY2gpDQoNClJlcXVpcmVtZW50cyB0byBlbmFibGUgbmFtZS1vYmplY3QgYmluZGlu ZyB2YWxpZGF0aW9uOg0KMy4gRGlmZmVyZW50IG5hbWUtb2JqZWN0IGJpbmRpbmcgdmFsaWRhdGlv biBtZWNoYW5pc21zIE1BWSBiZSBzdXBwb3J0ZWQsIGFuZCBhbiBhcHBsaWNhdGlvbiBjYW4gZGVj aWRlIHdoaWNoIG1lY2hhbmlzbSB0byB1c2UuIChyZWY6IDJuZCBwYXJhLCA0LjQsIC1hcmNoKQ0K NC4gTmFtZXMgTUFZIGJlIHNlbGYtZGVzY3JpYmluZyBzbyB0aGF0IGEgcmVjZWl2aW5nIGVudGl0 eSAoQ29udGVudCBDb25zdW1lcikga25vd3Mgd2hpY2ggbWVjaGFuaXNtIGlzIHVzZWQgKHJlZjog MXN0IHBhcmEsIHBwLiAxMiwgLWFyY2gpDQo1LiBJdCBTSE9VTEQgcHJvdmlkZSB0aGUgZm9sbG93 aW5nIG5hbWUgZWxlbWVudHM6ICgxKSBBICJ0eXBlIiBmaWVsZCwgKDIpIENyeXB0b2dyYXBoaWMg ZGF0YSwgKDMpIEFwcGxpY2F0aW9uIG9yIHB1Ymxpc2hlciBpbmZvcm1hdGlvbi4gKHJlZjogcHAu IDEyLCAtYXJjaCkNCg0KTW9yZSByZXF1aXJlbWVudHMgYWJvdXQgcGVyZm9ybWFuY2U6DQo2LiBJ dCBTSE9VTEQgc3VwcG9ydCB0aGUgc2NlbmFyaW9zIHdoZXJlIGEgY2xpZW50IG5lZWRzIHRvIGtu b3cgdGhlIG5hbWUgb2YgYSBkYXRhIG9iamVjdCBiZWZvcmUgaXQgaXMgY29tcGxldGVseSBzdG9y ZWQgYXQgdGhlIHNlcnZlci4gKFRoaXMgaXMgdG8gbGV0IGNsaWVudHMgYWR2ZXJ0aXNlIHRoZSBv YmplY3QgYmVmb3JlIGhhdmluZyBmdWxseSB1cGxvYWRlZCBpdCkgKHJlZjogc2Vjb25kIGxhc3Qg cGFyYSwgcHAuIDEyLCAtYXJjaCkNCjcuIEl0IFNIT1VMRCBzdXBwb3J0IHRoZSBzY2VuYXJpb3Mg d2hlcmUgYSBjbGllbnQgbmVlZCB0byBrbm93IHRoZSBuYW1lIG9mIGEgZGF0YSBvYmplY3QgYmVm b3JlIGl0IGlzIGxvY2FsbHkgY3JlYXRlZC4gKFRoaXMgaXMgdG8gc3VwcG9ydCBsaXZlIHN0cmVh bWluZykgKHJlZjogbGFzdCBwYXJhLCBwcC4gMTIsIC1hcmNoKQ0KDQpBbnkgY29tbWVudHMgYXJl IHdlbGNvbWUsIHRoYW5rcy4NCg0KUGVuZy4NCg0KDQo= --_000_AFD688AF30E249418739DBDC55B9C75B34D628EDSZXEML507MBSchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi Peng,

Your expla= nation makes sense to me. Thanks a lot.

 = ;

Best wishe= s,

Danhua

 = ;

=B7=A2=BC=FE=C8=CB: Zhang Peng [mailto:pzhang.thu@gmail.c= om]
=B7=A2= =CB=CD=CA=B1=BC=E4: 2012=C4=EA7=D4=C25=C8=D5 2:24
=CA=D5=BC=FE=C8=CB: Wangdanhua; DECADE@ietf.org
=D6=F7=CC=E2: =BB=D8=B8=B4: =B4=F0=B8=B4: [decade] Object naming in -req an= d -arch

 

Hi Danhua,

 

Thanks for your comments. I think y= our comments are very reasonable. But I still think the requirement "I= t MAY enable applications to construct unique names w.h.p." + "the naming scheme should indicated conflicts" is just one = approach to ensure uniqueness. It is because we can also let the DECADE ser= vice providers assign the name to ensure uniqueness. Thus, I= think we better just state the generic requirement that &qu= ot;names should be unique" without going into details of the design in -req,&n= bsp;and give the detailed requirements for our design (i.e., enable apps to= given names w.h.p., and indicate conflicts when necessary) in -arch. = What would you think?

 

Thanks,

 

Peng.  

 

=B7= =A2=BC=FE=C8=CB=A3=BA&nb= sp;Wangdanhua

=B7= =A2=CB=CD=CA=B1=BC=E4=A3=BA 2012-07-04 05:14

=CA= =D5=BC=FE=C8=CB=A3=BA&nb= sp;pzhang.thu; DECADE@ietf.org

=D6= =F7=CC=E2=A3=BA = =B4=F0=B8=B4: [decade] Object naming in -req and -arch

Hi Peng,

 

As to Q2, I agree with you that the conten= t naming requirement part in =A8Carch had better be moved to =A8Creq, and the =A1=B0immutable data object=A1=B1 should be remained in =A8Carch.

 

As to the generic requirements vs. specifi= c requirements you enumerated, I=A1=AFm a little confused. For example, as to the =A1=B0Requirements to = enable uniqueness=A1=B1, I think =A1=B0it SHOULD indicate conflicts when duplicate names= are constructed (ref: first para, 4.5.1, -req)=A1=B1 is also the detailed description/demand of the generic requirement = =A1=B0ensure the uniqueness of object names=A1=B1. In my opinion, such requirements should also be presented in =A8C= req. I wonder if my understanding is right.

 

Best wishes,

Danhua

 

 

=B7=A2=BC= =FE=C8=CB: decade-bounces@ietf.org [mailto:decade-bounces@ietf.org] =B4=FA=B1=ED Zhang Peng
=B7=A2=CB=CD=CA=B1=BC=E4: 2012=C4=EA7=D4=C23<= /span>=C8=D5 13:34
=CA=D5=BC=FE=C8=CB: DECADE@ietf.org
=D6=F7=CC=E2: [decade] Object naming in -req and -arch

&nbs= p;

Dear DECADE participants,

 

As pointed out by Richard in previous discu= ssions, both the -req and -arch documents has some para= graphs describing content naming, and they need better organization: some = generic requirements should be in -req, while some more specific ones shoul= d be in -arch. Here are some suggestions about how to split the content on = naming in these two documents.

 

The rationale for the following split is th= at I recognize there are two generic requirements, that is, uniqueness, and binding validation. They should be placed in the -req.&nbs= p;In -arch, we should present the specific requirements to enable uniq= ueness, and binding validation, respectively. There are also some more= requirements on how to improve the responsiveness of the system, i.e., the support of early name generation. See below = for details (references to the original documents are given after each spec= ific requirements):

 

Generic requirements (to be put in -req)

 

1. It SHOULD ensure that uniqueness of object names.

2. It SHOULD support the validation of name-object binding.

3. It SHOULD support the operation of DECADE= -compatible servers under diverse administrative domains with no coordination. (not sure about what operations are meant here)

 

Specific requirements (to be put in -arch)<= o:p>

 

Requirements to enable uniqueness:

1. It MAY enable applications to construct = unique names by themselves with a high probability (ref: last sentence, pp. 11, -arch). If this is the case, it SHOULD indicate conflict= s when duplicate names are constructed (ref: first para, 4.5.1, -req).=

2. It MAY support content-dependent hash-ba= sed schemes (for general immutable objects), and content-independent enumeration-based schemes (for live streaming) 

(ref: 2nd para, pp. 12, -arch)

 

Requirements to enable name-object binding = validation:

3. Different name-object binding validation= mechanisms MAY be supported, and an application can decide which mechanism to use. (ref: 2nd para, 4.4, -arch)

4. Names MAY be self-describing so that a r= eceiving entity (Content Consumer) knows which mechanism is used (ref: 1st para, pp. 12, -arch)

5. It SHOULD provide the following name ele= ments: (1) A "type" field, (2) Cryptographic data, (3) Applicatio= n or publisher information. (ref: pp. 12, -arch)

 

More requirements about performance:

6. It SHOULD support the scenarios where a = client needs to know the name of a data object before it is completely stored at the server. (This is to let clients advertise the obj= ect before having fully uploaded it) (ref: second last para, pp. 12, -arch)=

7. It SHOULD support the scenarios whe= re a client need to know the name of a data object=  before it is locally created. (This is to support live streaming) (ref: last para, pp. 12, -arch)

 

Any comments are welcome, thanks.

 

Peng.

 

 

--_000_AFD688AF30E249418739DBDC55B9C75B34D628EDSZXEML507MBSchi_-- From pzhang.thu@gmail.com Thu Jul 5 18:15:46 2012 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 83BC011E810B for ; Thu, 5 Jul 2012 18:15:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.087 X-Spam-Level: X-Spam-Status: No, score=-1.087 tagged_above=-999 required=5 tests=[AWL=0.758, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, 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 s2vK05zbr8PV for ; Thu, 5 Jul 2012 18:15:44 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 78D3811E8106 for ; Thu, 5 Jul 2012 18:15:44 -0700 (PDT) Received: by qcac10 with SMTP id c10so4656093qca.31 for ; Thu, 05 Jul 2012 18:15:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:reply-to:subject:references:x-priority:x-guid :x-mailer:mime-version:message-id:content-type; bh=roSfcotRRu8UCi/PuugyA99u3RIUed5oxUtf/kRBiIQ=; b=oSkHND4D6yh7DAnj/iC0lfmjvrtFaLN/ZvBMbjUXoDdQpjyDLt29LTaZJ22yetSVVe D38HnwEQ4JC9W4n2u7XujL0HC2KpIELuTnqtqznvfuQeKWdv1QXOLZiY86PnhPQ6gYsD 9J+IFZ8sNgOvRBH5BCxtyGxWXtpMZnUnzIshj9AhrPu9iEjlfPvRrgytXvNpInegGTds LZ+SqQ8p2LffjJ2+4vnUBIzC85If+7X8cyYZAQrzDG53T8p89N1KgOmv0hC22KnpVWoW g/G/2exTCvYakF0E1NgVh4EISMHLPiuMhCwNIzULuNDBFQm7cGcy0hk05yk5wt5bopld IHFw== Received: by 10.224.116.203 with SMTP id n11mr49376770qaq.61.1341537359024; Thu, 05 Jul 2012 18:15:59 -0700 (PDT) Received: from pzhang-PC (dhcp-130-132-249-182.central.yale.edu. [130.132.249.182]) by mx.google.com with ESMTPS id u20sm12700744qao.16.2012.07.05.18.15.57 (version=SSLv3 cipher=OTHER); Thu, 05 Jul 2012 18:15:58 -0700 (PDT) Date: Thu, 5 Jul 2012 21:15:56 -0400 From: "Zhang Peng" To: =?gb2312?B?UmFobWFuLCBBa2Jhcg==?= , "DECADE@ietf.org" References: , X-Priority: 3 X-GUID: BED8BD84-C447-4A84-8DF9-5AC8B330DCDD X-Mailer: Foxmail 7.0.1.81[cn] Mime-Version: 1.0 Message-ID: <20120705211556235011353@gmail.com> Content-Type: multipart/alternative; boundary="----=_001_NextPart642325035108_=----" Cc: Konstantinos Pentikousis Subject: Re: [decade] Working Group Last Call: draft-ietf-decade-arch-07 X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "pzhang.thu" 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, 06 Jul 2012 01:15:46 -0000 This is a multi-part message in MIME format. ------=_001_NextPart642325035108_=---- Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGksDQoNCkFzIGZvciB0aGUgY29tbWVudCAoNikgcmVnYXJkaW5nIG9wdGltaXphdGlvbiBhYm91 dCBuYW1pbmcsIEkgdGhpbmsgd2UgbmVlZCBmdXJ0aGVyIGRpc2N1c3Npb24uDQoNClRoZSBxdWVz dGlvbiBpcyB0aGF0IHdoZXRoZXIgdGhlIG5hbWUgU0hPVUxEIGJlIGdlbmVyYXRlZCBhbmQgcmV0 dXJuZWQgdG8gdGhlIGNsaWVudCBiZWZvcmUgY29tbWl0bWVudCB0byB0aGUgdXBsb2FkaW5nLg0K DQpGaXJzdCwgd2Ugc2hvdWxkIGV2YWx1YXRlIHRoZSBnYWluIGJ5IHVzaW5nIHRoaXMgd2hhdCBp IHRlcm0gYXMgImVhcmx5IG5hbWUgZ2VuZXJhdGlvbiIuIENvbnNpZGVyIHRoYXQgYSBjbGllbnQg QSBpcyB1cGxvYWRpbmcgYSBvYmplY3QgRiB0byBERUNBREUgc2VydmVyIEQsIGFuZCBhbm90aGVy IGNsaWVudCBCIG5lZWRzIHRvIGRvd25sb2FkIGl0IGZyb20gRC4gQmVsb3cgaXMgdGhlIHN0YWdl cyB0byBiZSB0YWtlbiB3aXRob3V0IGNvbnNpZGVyaW5nIGF1dGhlbnRpY2F0aW9uLCBhbmQgYWNj ZXNzIGNvbnRyb2wuIA0KDQoxLiBBIHNlbmRzIHVwbG9hZCByZXF1ZXN0IHRvIEQsIHdoaWNoIHJl c3BvbnNlcyB3aXRoIGEgcGVybWlzc2lvbg0KMi4gQSB1cGxvYWRzIEYgdG8gRA0KMy4gRCByZXR1 cm5zIHRoZSBvYmplY3QgbmFtZSB0byBBDQo0LiBBIGFkdmVydGlzZXMgdGhlIG9iamVjdCANCjUu IEIga25vd3MgdGhlIGZpbGUgbmFtZSBhbmQgcmVxdWVzdCB0aGUgb2JqZWN0IGZyb20gRA0KNi4g RCBzZW5kcyB0aGUgb2JqZWN0IHRvIEINCg0KSGVyZSAxLDMsNCw1IG1heSBjb3N0IGNvbnN0YW50 IHNtYWxsIGFtb3VudCBvZiB0aW1lLCB3aGlsZSAyLDYsIGRlcGVuZCBvbiB0aGUgc2l6ZSBvZiBv YmplY3QgYW5kIHRlbmQgdG8gY29zdCBtb3JlIHRpbWUuIFRoZSBiZW5lZml0IG9mIHB1dHRpbmcg MyBiZWZvcmUgMiBpcyB0aGF0IDQgYW5kIDUgY2FuIGJlIGNhcnJpZWQgb3V0IGluIHBhcmFsbGVs IHdpdGggMi4gVGh1cyBpdCBzZWVtcyB0aGF0IHdlIGNhbiBqdXN0IHNhdmUgdGhlIHRpbWUgb2Yg NCBhbmQgNSBpbiB0aGlzIHByb2Nlc3MuIEJ1dCBjb25zaWRlcmluZyB0aGF0IEIgaXMgaW4gZGlm ZmVyZW50IGxvY2F0aW9ucywgYW5kIHVzaW5nIGFub3RoZXIgREVDQURFIHNldmVyIEUsIHRoZW4g d2UgY2FuIGFsc28gc2F2ZSB0aGUgdGltZSBmb3IgRSByZXF1ZXN0IHRoZSBvYmplY3QgZnJvbSBE LiBJbiBhZGRpdGlvbiwgSXQgbWF5IGFsc28gdGFrZSBtb3JlIHRpbWUgaWYgd2UgY29uc2lkZXIg dGhlIGNhc2UgdGhhdCBBIHNob3VsZCBhZHZlcnRpc2UgdG8gYSBsb3Qgb2YgaW50ZXJlc3RlZCBy ZWNlaXZlcnMsIHdoaWNoIG1heSBjb25zdW1lIG1vcmUgdGltZS4gV2l0aG91dCB0aGlzIG5vbi1x dWFudGl0YXRpdmUgYW5hbHlzaXMsIGl0IHNlZW1zIHRoYXQgaXQgY2FuIGJlbmVmaXRzIHRoZSBs aXZlIGFwcGxpY2F0aW9ucyB0byByZWR1Y2UgdGhlIGxhdGVuY3kuIEJ1dCB0aGUgYmVuZWZpdHMg YXJlIG5vdCBzbyBjbGVhciwgYW5kIG1heSBkZXBlbmQgb24gYXBwbGljYXRpb25zLiANCg0KSWYg d2Ugd291bGQgaW5jbHVkZSB0aGlzIGluIC1hcmNoIGFzIGEgZGVzaWduIHJlcXVpcmVtZW50cywg d2UgbmVlZCB0byBoYW5kbGUgc29tZSBlcnJvbmVvdXMgc2l0dWF0aW9ucywganVzdCBhcyBtZW50 aW9uZWQgYnkgS29zdGFzLiBXaGVuIHRoZSBjbGllbnQgYWR2ZXJ0aXNlcyBhIG9iamVjdCwgYnV0 IGRvZXMgbm90IHVwbG9hZCBvciBmaW5pc2ggdGhlIHVwbG9hZGluZywgdGhlIERFQ0FERSBzZXJ2 ZXIsIGhvd2V2ZXIsIG1heSBoYXZlIGFscmVhZHkgZ3JhbnQgdGhlIG9iamVjdCBvciBzZW5kIHRo ZSBwYXJ0IG9mIHRoZSBvYmplY3QgdG8gc29tZSByZWNlaXZlci4gVGhlbiB0aGUgc2VydmVyIHNo b3VsZCBqdXN0IHNlbmRzIGEgZXJyb3Igc2lnbmFsIHRvIHRoZSBncmFudGVkIHJlY2VpdmVycywg b3IgbGV0IHRoZSByZWNlaXZlcnMgdGltZW91dCB0aGVtc2VsdmVzLCBhbmQgZGVsZXRlIHRoZSBv YmplY3QuIFJldHJhbnNtaXNzaW9uIG1heSBvciBtYXkgbm90IGhhcHBlbiwgZGVwZW5kaW5nIG9u IHRoZSBhcHBsaWNhdGlvbiBpbXBsZW1lbnRhdGlvbi4gIA0KDQpJIGFtIHN0aWxsIG5vdCBxdWl0 ZSBzdXJlIHdoZXRoZXIgdGhlIHBvdGVudGlhbCBiZW5lZml0cyBvZiB0aGlzIG9wdGltaXphdGlv biB3b3J0aCB0aGUgY29tcGxpY2F0aW9uIGl0IGJyaW5ncy4gTW9yZSBkaXNjdXNzaW9uIG1heSBi ZSBuZWVkZWQuIFRoYW5rcy4NCg0KQiwNCg0KUGVuZy4NCg0KDQpGcm9tOiBSYWhtYW4sIEFrYmFy DQpEYXRlOiAyMDEyLTA3LTA1IDAxOjIxDQpUbzogZGVjYWRlQGlldGYub3JnDQpDQzogS29uc3Rh bnRpbm9zIFBlbnRpa291c2lzDQpTdWJqZWN0OiBSZTogW2RlY2FkZV0gV29ya2luZyBHcm91cCBM YXN0IENhbGw6IGRyYWZ0LWlldGYtZGVjYWRlLWFyY2gtMDcNCkhpLA0KDQoNClRoZSBERUNBREUg QXJjaGl0ZWN0dXJlIGF1dGhvcnMgd2VyZSBjb250YWN0ZWQgb2ZmIGxpc3QgYnkgS29zdGFzIHdo bw0KcHJvdmlkZWQgdGhlIGZvbGxvd2luZyByZWxldmFudCBhbmQgdXNlZnVsIGNvbW1lbnRzIG9u IHRoZQ0KZHJhZnQtaWV0Zi1kZWNhZGUtYXJjaC0wNy4gIFdlIGludGVuZCB0byBhZGRyZXNzIHRo ZXNlIGNvbW1lbnRzIGluIHRoZQ0KbmV4dCByZXZpc2lvbiBvZiB0aGUgYXJjaGl0ZWN0dXJlIEkt RCBhZnRlciB0aGUgV0dMQyBlbmRzLiAgDQoNCjEpIEZpZ3VyZSAxOiANClRoaXMgZmlndXJlIGFu ZCB0aGUgYWNjb21wYW55aW5nIHRleHQgKGFzLWlzIHJpZ2h0IG5vdykgbGVhdmVzIHF1aXRlDQpz b21lIHJvb20gZm9yIGludGVycHJldGF0aW9uLiBGb3IgZXhhbXBsZSwgIHR3byBkaXN0aW5jdA0K IkRFQ0FERS1jb21wYXRpYmxlIiBzeXN0ZW1zIGRlcGxveWVkIGJ5IHR3byBkaWZmZXJlbnQgb3Bl cmF0b3JzIG1heSBoYXZlDQpEUlAxIHZzLiBEUFIyLCBpbiBhZGRpdGlvbiB0byBoYXZpbmcgbXVs dGlwbGUgU0RUeHl6J3MuIElzIHRoaXMgd2hhdCB5b3UNCmhhdmUgaW4gbWluZD8NCg0KDQoyKSBT ZWN0aW9uIDQuMiwgUmVmZXJyaW5nIHRvIHRoZSB3b3JkICJtdWx0aXBhdGgiOiAgDQpJIHRoaW5r IHlvdSBtZWFuIG11bHRpLXNvdXJjZSBoZXJlPyBNdWx0aXBhdGggaXMgbW9zdGx5IHJlbGF0ZWQg d2l0aCB0d28NCihtdWx0aWhvbWVkKSBlbmQgbm9kZXMgYW5kIHJvdXRpbmcgaW4gdGhlIG5ldHdv cmsgcmF0aGVyIHRoYW4gb25lIG5vZGUNCmdldHRpbmcgYml0cyBhbmQgcGllY2VzIG9mIGEgZGF0 YSBvYmplY3QgZnJvbSBkaWZmZXJlbnQgc291cmNlcyAoYXMgaW4NClAyUCkuIFlvdSBjYW4gc3Rp bGwgaGF2ZSBtdWx0aXBhdGggYW5kIHNpbmdsZS1zb3VyY2UuDQoNCg0KMykgU2VjdGlvbiA0LjIs IHRoaXJkIHBhcmFncmFwaCwgZmlyc3Qgc2VudGVuY2U6DQpBcyBwZXIgdGhlIHNlYy4gMi44LCBh ICJkYXRhIG9iamVjdCBpcyBhIHN0cmluZyBvZiByYXcgYnl0ZXMiLg0KVGhlcmVmb3JlLCBpbiB0 aGlzIHNlbnRlbmNlIHdlIG5lZWQgcy9TSE9VTEQvTVVTVC4NCg0KDQo0KSBTZWN0aW9uIDQuMiwg dGhpcmQgcGFyYWdyYXBoLCBzZWNvbmQgc2VudGVuY2U6DQpUaGlzIG1heSBpbnRyb2R1Y2UgdGhl IGlzc3VlIG9mIE1ETyBkaXNjb3ZlcnkgKG1heCBkYXRhIG9iamVjdCksIHdoZW4NCm9uZSBjb25u ZWN0cyB0byBkaWZmZXJlbnQgREVDQURFIFNlcnZlcnMsIHBlcmhhcHMgYWxvbmcgdGhlIGxpbmVz IG9mIE1UVQ0KZGlzY292ZXJ5LiBDb250ZW50IHJlc2VnbWVudGF0aW9uIGlzIG5vdCBjb3ZlcmVk IGluIHRoaXMgc2VjdGlvbiwgZXNwLg0Kc2luY2UgYSBERUNBREUgc2VydmVyIG1heSBzdG9yZS9t YWludGFpbiBET3MgZnJvbSBjb21wbGV0ZWx5IGRpZmZlcmVudA0KYXBwcy4NCg0KDQo1KSBTZWN0 aW9uIDQuMiwgbGFzdCBwYXJhZ3JhcGg6DQpUaGUgaW50cm9kdWN0aW9uIG9mIHRoZSAiYmxvY2si IG1heSBiZSByZWR1bmRhbnQgaGVyZS4gQSBibG9jayBpcywNCnNpbWlsYXJseSB0byBhIERPLCAi YSBzdHJpbmcgb2YgcmF3IGJ5dGVzIiwgaXNuJ3QgaXQ/IElmIG5vdCwgd2UgbmVlZCBhDQpmb3Jt YWwgZGVmaW5pdGlvbiBmb3IgaXQuIE9mIGNvdXJzZSwgdGhlIGtleSBhc3BlY3QgaGVyZSBpcyB3 aGF0IGNhbiB5b3UNCm5hbWUgYW5kIGxvY2F0ZSBpbiBhIERFQ0FERSBTZXJ2ZXIsIGFuZCBteSBy ZWFkaW5nIG9mIHRoZSBJRCBzbyBmYXIgaXMNCnRoYXQgeW91IGhhdmUgc2V0dGxlZCBvbiB0aGUg dXNlIG9mIHRoZSBETywgaXJyZXNwZWN0aXZlIG9mIHRoZQ0KYXBwbGljYXRpb24gc2VtYW50aWNz LiBUaGUgcmVwZWF0ZWQgdXNlIG9mICJibG9jayIgaGVyZSBhbmQgdGhlcmUgc2ltcGx5DQpjb25m dXNlcyB0aGUgdW5pbml0aWF0ZWQgcmVhZGVyLg0KDQoNCjYpIFNlY3Rpb24gNC40LCAybmQgdG8g bGFzdCBwYXJhZ3JhcGg6DQpJIHRoaW5rIHRoZSBvcHRpbWl6YXRpb24gZGVzY3JpYmVkIGluIHRo aXMgcGFyYWdyYXBoIGlzIG5vdCBwYXJ0aWN1bGFybHkNCnN1aXRlZCBmb3IgdGhlIEFyY2hpdGVj dHVyZSBkb2N1bWVudC4gQW5kIGl0IG9wZW5zIHVwIGFsbCBraW5kcyBvZg0KcXVlc3Rpb25zLiAg RS5HLiB3aGF0IGlmIHRoZSBob3N0IGFkdmVydGl6aW5nIGFuIG9iamVjdCBjcmFzaGVzIGJlZm9y ZQ0KaXQgdXBsb2FkcyB0aGUgb2JqZWN0PyBXaGF0IGlmIHRoZSBob3N0IGNoYW5nZXMgaXRzIG1p bmQgZHVyaW5nIHRoZQ0KdXBsb2FkPyBTaW5jZSB3ZSdyZSB0YWxraW5nIGFib3V0IGltbXV0YWJs ZSBvYmplY3RzLCBzaG91bGRuJ3Qgd2Ugd2FpdA0KdW50aWwgYW4gb2JqZWN0IGlzICJjb21taXR0 ZWQiLiBJbiB0aGUgZW5kLCB0aGlzIG9wdGltaXphdGlvbiBjb3VsZCBiZQ0KY291bnRlci1wcm9k dWN0aXZlIGluIHRoZXNlIGNhc2VzLiBMZXQgYWxvbmUgdGhlIGZhY3QgdGhhdCB0aGUgc2NlbmFy aW9zDQpmb3Igd2hpY2ggREVDQURFIGlzIGVudmlzYWdlZCAoYW5kIG1vdGl2YXRlZCBmcm9tIEkg d291bGQgYWRkKSB0ZW5kIHRvDQpoYXZlIGFzeW1tZXRyaWMgY2FwYWNpdGllcyBpbiBkb3duL3Vw bGluaywgcGVyaGFwcyBvZiBhIHJhdGlvIG9mIDEwOjEuDQpUaHVzLCBkb3dubG9hZGluZyBpcyBu b3QgdHlwaWNhbGx5IHRoZSBwZXJmb3JtYW5jZSBib3R0bGVuZWNrLiBQZXJoYXBzIEkNCmFtIHdy b25nIGluIHRoaW5raW5nIG9mIHRoaXMgYXMgYSBwcmVtYXR1cmUgb3B0aW1pemF0aW9uIHRob3Vn aC4gQ2FuIHlvdQ0KcHJvdmlkZSBleGFtcGxlcyBmcm9tIGV4aXNpdGluZyBhcHBzIHRoYXQgZm9s bG93IHRoaXMgcHJvcG9zYWwgKGFuZCBob3cNCmRvIHRoZXkgaGFuZGxlIGVycm9yIGNhc2VzKT8g DQoNCk1vcmVvdmVyLCB1c2luZyBTSE9VTEQgZm9yIHN1Y2ggYSBvcHRpbWl6YXRpb24gbWF5IG5v dCBiZSBhIGdvb2QgaWRlYSBpbg0KdGhlIGdlbmVyYWwgY2FzZS4NCg0KDQo3KSBGaWd1cmUgMzoN ClRoaXMgZmlndXJlIGltcGxpZXMgdGhhdCBtdWx0aXBsZSBhcHBsaWNhdGlvbnMgd2lsbCBuZWVk IHRvIGltcGxlbWVudA0KdGhlaXIgb3duIERFQ0FERSBjbGllbnQsIHdoaWNoIGNhbm5vdCBiZSBz aGFyZWQgYXQgcnVuIHRpbWUgd2l0aCBvdGhlcg0KYXBwcy4gT2YgY291cnNlIG9uZSBjb3VsZCBz ZWUgdGhpcyBhcyBpbmNsdWRpbmcvbGlua2luZyB0byBhIGxpYnJhcnksDQpidXQgcGVyaGFwcyBh IG1vcmUgZmxleGlibGUgaW1wbGVtZW50YXRpb24gY291bGQgYWxzbyBiZSB0aG91Z2h0IG9mLA0K YmFzZWQsIGZvciBleGFtcGxlLCBvbiBhIERFQ0FERSAicGxhdGZvcm0iLCBzaGFyZWQgYnkgbWFu eSBhcHBzIGF0IHJ1bg0KdGltZS4NCg0KDQo4KSBTZWN0aW9uIDYuMS4yLCBzZWNvbmQgdG8gbGFz dCBwYXJhZ3JhcGg6DQpUaGlzIHByb3Bvc2VkIG9wdGltaXphdGlvbiBuZWVkIG5vdCBiZSBwYXJ0 IG9mIHRoZSAiYXJjaGl0ZWN0dXJlIg0KDQoNCjkpIFNlY3Rpb24gNi4xLjM6DQpXb3VsZG4ndCBp dCBiZSBiZXR0ZXIgdG8gc2tpcCB0aGlzIHNlY3Rpb24gYWx0b2dldGhlciBhbmQgY29uc2lkZXIg YW4gSUQNCm9uIG1hbmFnZW1lbnQgYXNwZWN0cyBpbnN0ZWFkPyBGb3IgZXhhbXBsZSwgd2h5IG5v dCBzaW1wbHkgZGVmaW5lIGFuIE1JQg0KZm9yIERFQ0FERSBhbmQgdXNlIGV4aXN0aW5nIG1ldGhv ZHMgdG8gb2J0YWluIHRoaXMgc3RhdHVzIGluZm8/IFdoeSBhZGQNCm1vcmUgY29tcGxleGl0eSBp biBEUlAgaW1wbGVtZW50YXRpb25zPw0KDQoNCjEwKSBTZWN0aW9uIDEwLjI6DQpodHRwOi8vZHgu ZG9pLm9yZy8xMC4xMTQ1LzE1NDQwMTIuMTU0NDA3OCBzaG91bGQgYWxzbyBiZSBhZGRlZCBoZXJl LCBhcw0KaXQgbW90aXZhdGVzIHdlbGwgdGhlIGRvbWFpbiBjb25zaWRlcmVkIGluIHRoaXMgYXJj aGl0ZWN0dXJlLCBpbmNsdWRpbmcNCnRoZSBETy4NCg0KDQoxMSkgVmFyaW91cyBlZGl0b3JpYWwg YW5kIGdyYW1tYXRpY2FsIGZpeGVzICh3aGljaCB3ZXJlIHByb3ZpZGVkIHRvIHRoZQ0KYXV0aG9y cyBvZmYgbGluZSkuDQoNCg0KTWFueSB0aGFua3MgdG8gS29zdGFzIGZvciBwcm92aWRpbmcgdGhl c2UgZXhjZWxsZW50IGNvbW1lbnRzLg0KDQoNCkFrYmFyDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCkZyb206IGRlY2FkZS1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86ZGVjYWRlLWJv dW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZg0KT2YgU29uZ2hhaWJpbg0KU2VudDogV2VkbmVzZGF5 LCBKdW5lIDIwLCAyMDEyIDEwOjA2IFBNDQpUbzogZGVjYWRlQGlldGYub3JnDQpTdWJqZWN0OiBb ZGVjYWRlXSBXb3JraW5nIEdyb3VwIExhc3QgQ2FsbDogZHJhZnQtaWV0Zi1kZWNhZGUtYXJjaC0w Nw0KDQpEZWFyIGZvbGtzLA0KDQpBZnRlciB0aGUgZmlyc3Qgcm91bmQgb2YgdGhlIGxhc3QgY2Fs bCwgdGhlIGFyY2hpdGVjdHVyZSBkb2N1bWVudCBoYXMNCm1hbnkgY2hhbmdlcyB0byByZXNvbHZl IGNvbW1lbnRzIGZyb20gcmV2aWV3ZXJzIGFzIHdlbGwgYXMgYXJlYSBkaXJlY3Rvcg0KYW5kIGV4 cGVydHMgZnJvbSBvdGhlciBhcmVhcy4gVGhhbmtzIHRvIHRoZSByZXZpZXdlcnMgYW5kIHRoZSBh dXRob3JzLg0KDQpTbyBSaWNoIGFuZCBJIG5vdyBzdGFydCBhbm90aGVyIHJvdW5kIG9mIFdHTEMg b24NCmRyYWZ0LWlldGYtZGVjYWRlLWFyY2gtMDcsIGVuZGluZyBGcmlkYXksIEp1bHkgNnRoLiBQ bGVhc2UgcmV2aWV3IHRoZQ0KZG9jdW1lbnQgYW5kIHJlcGx5IHdpdGggeW91ciBjb21tZW50cy4N Cg0KVGhhbmtzLA0KDQotSGFpYmluIGFuZCBSaWNoIChjby1jaGFpcnMp ------=_001_NextPart642325035108_=---- Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
Hi,
 
As for the comment (6) regarding optimizat= ion=20 about naming, I think we need further discussion.
 
The question is that whether the name SHOU= LD be=20 generated and returned to the client before commitment to the uploading.
 
First, we should evaluate the gain by usin= g this=20 what i term as "early name generation". Consider that a client A is upload= ing a=20 object F to DECADE server D, and another client B needs to download it fro= m D.=20 Below is the stages to be taken without considering authentication, and ac= cess=20 control.
 
1. A sends upload request to D, which resp= onses=20 with a permission
2. A uploads F to D
3. D returns the object name to A
4. A advertises the object
5. B knows the file name and request the o= bject=20 from D
6. D sends the object to B
 
Here 1,3,4,5 may cost constant small amount of time, while = 2,6,=20 depend on the size of object and tend to cost more time. The benefit = of=20 putting 3 before 2 is that 4 and 5 can be carried out in=20 parallel with 2. Thus it seems that we can just save the ti= me of=20 4 and 5 in this process. But considering that B is in diffe= rent=20 locations, and using another DECADE sever E, then we can also sa= ve the=20 time for E request the object from D. In addition, It may also take m= ore=20 time if we consider the case that A should advertise to a lot of inte= rested=20 receivers, which may consume more time. Without this=20 non-quantitative analysis, it seems that it can benefits the live=20 applications to reduce the latency. But the benefits are not&nbs= p;so=20 clear, and may depend on applications.
 
If we would include this in -arch as a design requirem= ents,=20 we need to handle some erroneous situations, just as mentioned=20 by Kostas. When the client advertises a object, but do= es not=20 upload or finish the uploading, the DECADE server, however, = ;may=20 have already grant the object or send the part of the object to some=20 receiver. Then the server should just sends a error signal to the gra= nted=20 receivers, or let the receivers timeout themselves, and delete the ob= ject.=20 Retransmission may or may not happen, depending on the application=20 implementation.  
 
I am still not quite sure whether the potential benefits of this=20 optimization worth the complication it brings. More discussion may be need= ed.=20 Thanks.
 
B,
 
Peng.
 
 
Date: 2012-07-05 01:21
Subject: Re: [decade] Working Group Last Call:=20 draft-ietf-decade-arch-07
Hi,
 
 
The DECADE Architecture authors were contact= ed off list by Kostas who
provided the following relevant and useful&n= bsp;comments on the
draft-ietf-decade-arch-07.  We intend to add= ress these comments in the
next revision of the architecture I-D a= fter the WGLC ends.  
 
1) Figure 1: 
This figure and the accompanying text (= as-is right now) leaves quite
some room for interpretation. For example,&n= bsp; two distinct
"DECADE-compatible" systems deployed by two = different operators may have
DRP1 vs. DPR2, in addition to having&nb= sp;multiple SDTxyz's. Is this what you
have in mind?
 
 
2) Section 4.2, Referring to the word&n= bsp;"multipath":  
I think you mean multi-source here? Mul= tipath is mostly related with two
(multihomed) end nodes and routing in t= he network rather than one node
getting bits and pieces of a data = object from different sources (as in
P2P). You can still have multipath and&= nbsp;single-source.
 
 
3) Section 4.2, third paragraph, first = sentence:
As per the sec. 2.8, a "data objec= t is a string of raw bytes".
Therefore, in this sentence we need s/S= HOULD/MUST.
 
 
4) Section 4.2, third paragraph, second = ;sentence:
This may introduce the issue of MDO&nbs= p;discovery (max data object), when
one connects to different DECADE Servers,&nb= sp;perhaps along the lines of MTU
discovery. Content resegmentation is not cov= ered in this section, esp.
since a DECADE server may store/maintain&nbs= p;DOs from completely different
apps.
 
 
5) Section 4.2, last paragraph:
The introduction of the "block" may be&= nbsp;redundant here. A block is,
similarly to a DO, "a string of ra= w bytes", isn't it? If not, we need&nbs= p;a
formal definition for it. Of course, th= e key aspect here is what can you
name and locate in a DECADE Server,&nbs= p;and my reading of the ID so far = is
that you have settled on the use o= f the DO, irrespective of the
application semantics. The repeated use of&n= bsp;"block" here and there simply
confuses the uninitiated reader.
 
 
6) Section 4.4, 2nd to last paragraph:<= /DIV>
I think the optimization described in t= his paragraph is not particularly
suited for the Architecture document. And&nb= sp;it opens up all kinds of
questions.  E.G. what if the host = advertizing an object crashes before
it uploads the object? What if the = ;host changes its mind during the
upload? Since we're talking about immutable&= nbsp;objects, shouldn't we wait
until an object is "committed". In the&= nbsp;end, this optimization could be
counter-productive in these cases. Let alone=  the fact that the scenarios
for which DECADE is envisaged (and moti= vated from I would add) tend to
have asymmetric capacities in down/uplink, p= erhaps of a ratio of 10:1.
Thus, downloading is not typically the = performance bottleneck. Perhaps I
am wrong in thinking of this as a&= nbsp;premature optimization though. Can you
provide examples from exisiting apps that&nb= sp;follow this proposal (and how
do they handle error cases)? 
 
Moreover, using SHOULD for such a optim= ization may not be a good idea in
the general case.
 
 
7) Figure 3:
This figure implies that multiple applicatio= ns will need to implement
their own DECADE client, which cannot b= e shared at run time with other
apps. Of course one could see this = ;as including/linking to a library,
but perhaps a more flexible implementation&n= bsp;could also be thought of,
based, for example, on a DECADE "platfo= rm", shared by many apps at run
time.
 
 
8) Section 6.1.2, second to last paragr= aph:
This proposed optimization need not be = part of the "architecture"
 
 
9) Section 6.1.3:
Wouldn't it be better to skip this = ;section altogether and consider an ID
on management aspects instead? For example,&= nbsp;why not simply define an MIB
for DECADE and use existing methods to&= nbsp;obtain this status info? Why add
more complexity in DRP implementations?
 
 
10) Section 10.2:
http://dx.doi.org/10.1145/1544012.1544078 should also = be added here, as
it motivates well the domain considered = ;in this architecture, including
the DO.
 
 
11) Various editorial and grammatical fixes&= nbsp;(which were provided to the
authors off line).
 
 
Many thanks to Kostas for providing the= se excellent comments.
 
 
Akbar
 
 
-----Original Message-----
From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.o= rg] On Behalf
Of Songhaibin
Sent: Wednesday, June 20, 2012 10:06 PM=
To: decade@ietf.org
Subject: [decade] Working Group Last Call:&n= bsp;draft-ietf-decade-arch-07
 
Dear folks,
 
After the first round of the last = call, the architecture document has
many changes to resolve comments from r= eviewers as well as area director
and experts from other areas. Thanks to=  the reviewers and the authors.
 
So Rich and I now start another ro= und of WGLC on
draft-ietf-decade-arch-07, ending Friday, July 6t= h. Please review the
document and reply with your comments.
 
Thanks,
 
-Haibin and Rich (co-chairs)
------=_001_NextPart642325035108_=------ From haibin.song@huawei.com Fri Jul 6 02:15:51 2012 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 A7E3121F8750 for ; Fri, 6 Jul 2012 02:15:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.243 X-Spam-Level: X-Spam-Status: No, score=-6.243 tagged_above=-999 required=5 tests=[AWL=0.355, 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 YsOJ5ipcU7eG for ; Fri, 6 Jul 2012 02:15:49 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 7F41621F86DD for ; Fri, 6 Jul 2012 02:15:49 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AHM38842; Fri, 06 Jul 2012 05:16:05 -0400 (EDT) Received: from DFWEML404-HUB.china.huawei.com (10.193.5.203) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 6 Jul 2012 02:13:49 -0700 Received: from SZXEML433-HUB.china.huawei.com (10.72.61.61) by dfweml404-hub.china.huawei.com (10.193.5.203) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 6 Jul 2012 02:13:46 -0700 Received: from SZXEML534-MBX.china.huawei.com ([169.254.2.243]) by szxeml433-hub.china.huawei.com ([10.72.61.61]) with mapi id 14.01.0323.003; Fri, 6 Jul 2012 17:12:13 +0800 From: Songhaibin To: pzhang.thu , yry , "DECADE@ietf.org" Thread-Topic: [decade] -req and -arch documents Thread-Index: AQHNVqzZgLDT4PDJR0OHTNS85avOkJcVcj3wgAaO1vA= Date: Fri, 6 Jul 2012 09:12:13 +0000 Message-ID: References: <4FEED79A.1090906@cs.yale.edu> <2012070201013396821769@gmail.com> In-Reply-To: <2012070201013396821769@gmail.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.73] Content-Type: multipart/alternative; boundary="_000_E33E01DFD5BEA24B9F3F18671078951F23AE871Bszxeml534mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [decade] -req and -arch documents 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, 06 Jul 2012 09:15:51 -0000 --_000_E33E01DFD5BEA24B9F3F18671078951F23AE871Bszxeml534mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Peng, I tend to agree with all your proposals. Thanks, -Haibin From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.org] On Behalf Of= Zhang Peng Sent: Monday, July 02, 2012 2:02 PM To: yry; DECADE@ietf.org Subject: Re: [decade] -req and -arch documents Hi Richard, Thanks for your effort. Here are some suggestion about the revision of -req= documents. First, regarding Q1, I think there are indeed some overlaps on term definit= ions in -req and -arch documents. In addition, they are even not consistent= . I think we can just put them in the -req document, and give a pointer in = -arch document. Regarding Q2, I agree that in -arch, there are some paragraphs that also do= the job of define requirements, and may better be put in -req. For naming,= the reqiin -requirements given in -req are rather simplistic, and we can m= ove the move the detailed requirements to -req. But for "immutable object",= I think it is more like a design option for the architecture (so that the = design would be much simplified), rather than a system requirements for DEC= ADE to function. Thus, I suggest we don't move the immutable data objects = in -arch to -req, and we can even delete them in -req. Finally, I would say= that there is no clear cut for requirement and architecture, since when we= specify the requirements, we have some design rationale in mind; and when = we design the architecture, we would find more clear requirements for the s= pecific design. It is not easy to fully decouple them. Regarding Q3, I think the new outline of the -req document seems better, bu= t I think it is better to organize it into three parts: access/authorizatio= n, resource control, data storage/transfer, failure handling/gaming prevent= ion. The rationale is that the first part is about how client access the se= rver, the second part corresponds to DRP, the third part corresponds to SDT= , and the last two parts are about reliability/security. The following is t= he outline in my mind. I would like to discuss with you about the organizat= ion further. And I would like to help revise the -req document. Thanks. Best, Peng. 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology and Concepts . . . . . . . . . . . . . . . . . . . 6 3. System/Functional Components 4. Requirements Structure . . . . . . . . . . . . . . . . . . . . 7 5. Data Object Requirements 4.5.1. Data Naming . . . . . . . . . . . . . . . . . . . . . .14 Move part of Arch 4.4 to -req 4.2.1. Data Object Size . . . . . . . . . . . . . . . . . 11 4.4.2. System Data Object Attributes . . . . . . . . . . . . .13 4.4.3. Time-to-live for Written Data Objects . . . . . . 13 4.4.4. Application-defined Properties and Metadata . . . . . 13 6. Authentication and Access Requirements 4.7.1. Per-Remote-Client, Per-Data Read Access . . . . . . . 16 4.7.2. Per-User Write Access . . . . . . . . . . . . . . . . 17 4.7.3. Default Access Permissions . . . . . . . . . . . . . . 17 4.7.4. Authorization Checks . . . . . . . . . . . . . . . . . 17 4.7.5. Cryptographic Credentials . . . . . . . . . . . . . . 17 4.7.6. Server Involvement . . . . . . . . . . . . . . . . . . 18 4.7.7. Protocol Reuse . . . . . . . . . . . . . . . . . . . . 18 4.3.1. Read/Write Own Storage . . . . . . . . . . . . . . .. 11 4.3.2. Read/Write by Remote Clients . . . . . . . . . . . . . 11 4.4.5. Offline Access . . . . . . . . . . . . . . . . . . . 14 7. Data Transfer Requirements 4.1.1.1. NATs and Firewalls TRaversal . . .. . . . . . . . . 8 Connections to Clients . . . . . . . . . . . . . . . . . . . 8 6.1.1. Support for Clients Behind NATs and Firewalls . . . 21 4.3.3. Negotiable Data Transport Protocol . . . . . . . . . . 12 4.1.2.1. Secure Transport . . . . . . . . . . . . . . . . . . 8 8. Resource Control Requirements. . . . . . . . . . . . . . . . . 15 4.6.1. Multiple Applications . . . . . . . . . . . . . . . . 15 4.6.2. Per-Remote-Client, Per-Data Control . . . . . . . . . 15 4.6.3. Resource Control Set . . . . . . . . . . . . . . . . . 16 4.6.4. Server Involvement . . . . . . . . . . . . . . . . . . 16 8. Authorization Requirements 9. Error and Failure Handling Requirements. . . . . . . . . . . . 9 4.1.3.2. Insufficient Resources . . . . . . . . . . . . . . . 9 4.1.3.1. Overload Condition . . . . . . . . . . . . . . . 9 4.1.3.3. Unavailable and Deleted Data . . . . . . . . . . . . 10 4.1.3.4. Insufficient Permissions . . . . . . . . . . . . . . 10 4.1.3.5. Redirection . . . . . . . . . . . . . . . . . . . . 10 4.1.2.2. Gaming Prevention . . . . . . . . . . . . . . . . . .8 4.4.1. Server reliability (Agnostic of reliability) . . . . . 12 10. Server Status Query Requirements . . . . . . . . . . . . . . . 18 5.7. Storage Status . . . . . . . . . . . . . . . . . . . . . 20 .... 11. Security Considerations . . . . . . . . . . . . . . . . . . . 21 7.1. Authentication and Authorization . . . . . . . . . . . . 21 7.2. Encrypted Data . . . . . . . . . . . . . . . . . . . . . 22 7.3. Protection against Gaming . . . . . . . . . . . . . . . 22 ________________________________ Zhang Peng From: Y. Richard Yang Date: 2012-06-30 06:40 To: DECADE@ietf.org Subject: [decade] -req and -arch documents Dear DECADE participants, Both -req and -arch documents have received extensive, excellent reviews. In the process of revising the documents and looking at the two documents, we have some questions to seek input from the participants: Q1. Both -req and -arch define some terms, including DECADE-compatible client, DECADE-compatible server, etc. This appears to be redundant. Should such terms be defined in -req or -arch? The current thinking is -req. Any comments? Q2. There are multiple paragraphs defining requirements in -arch, e.g., Sec. 4.4 on naming. Should these be moved to -req? A more general question is on the dependency between -req and -arch. On one hand, it is ideal to define -req first without a particular architecture to allow competing/alternative architectures satisfying the requirements. On the other hand, it appears that the -arch document contains content, in particular, systems/function components, that can be helpful to better understand the -req document. The current thinking is still to make -req independent of -arch, and move some general requirements in -arch to -req. Any comments? Q3: There are some good comments on reorganizing the -req documents. Below is a new structure (second level section #'s and page numbers are from the current -req so that others can see how we re-organize the document). Any comments/feedback before we start the revision will be greatly appreciated. Also, anyone who can help with direct revisions of the -req document will be more than welcome! Thanks. -- Richard 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology and Concepts . . . . . . . . . . . . . . . . . . . 6 3. System/Functional Components 4. Requirements Structure . . . . . . . . . . . . . . . . . . . . 7 5. Data Object Requirements 4.5.1. Data Naming . . . . . . . . . . . . . . . . . . . . . .14 Move part of Arch 4.4 to -req 5.1. --Immutable Data . . . . . . . . . . . . . . . . . . . . 18 4.4.2. System Data Object Attributes . . . . . . . . . . . . .13 4.2.1. Data Object Size . . . . . . . . . . . . . . . . . 11 4.4.3. Time-to-live for Written Data Objects . . . . . . 13 4.4.4. Application-defined Properties and Metadata . . . . . 13 6. Access to Server Requirements 4.3.1. Read/Write Own Storage . . . . . . . . . . . . . . .. 11 4.3.2. Read/Write by Remote Clients . . . . . . . . . . . . . 11 4.4.5. Offline Access . . . . . . . . . . . . . . . . . . . 14 4.1.1.1. NATs and Firewalls TRaversal . . .. . . . . . . . . 8 Connections to Clients . . . . . . . . . . . . . . . . . . . 8 6.1.1. Support for Clients Behind NATs and Firewalls . . . 21 4.3.3. Negotiable Data Transport Protocol . . . . . . . . . . 12 5.2. Explicit Deletion of Data . . . . . . . . . . . . . . . 19 5.3. Concurrent Write (Multiple writing). . . . . . . . . . . 19 5.4. Concurrent Read (Multiple reading) . . . . . . . . . . . 19 5.5. Read While Write . . . . . . . . . . . . . . . . . . . 19 5.6. Partial Write (Writing model) . . . . . . . . . . . . . 20 4.1.2.1. Secure Transport . . . . . . . . . . . . . . . . . . 8 7. Resource Control Requirements. . . . . . . . . . . . . . . . . 15 4.6.1. Multiple Applications . . . . . . . . . . . . . . . . 15 4.6.2. Per-Remote-Client, Per-Data Control . . . . . . . . . 15 4.6.3. Resource Control Set . . . . . . . . . . . . . . . . . 16 4.6.4. Server Involvement . . . . . . . . . . . . . . . . . . 16 8. Authorization Requirements 4.7.1. Per-Remote-Client, Per-Data Read Access . . . . . . . 16 4.7.2. Per-User Write Access . . . . . . . . . . . . . . . . 17 4.7.3. Default Access Permissions . . . . . . . . . . . . . . 17 4.7.4. Authorization Checks . . . . . . . . . . . . . . . . . 17 4.7.5. Cryptographic Credentials . . . . . . . . . . . . . . 17 4.7.6. Server Involvement . . . . . . . . . . . . . . . . . . 18 4.7.7. Protocol Reuse . . . . . . . . . . . . . . . . . . . . 18 9. Error and Failure Handling Requirements. . . . . . . . . . . . 9 4.1.3.2. Insufficient Resources . . . . . . . . . . . . . . . 9 4.1.3.1. Overload Condition . . . . . . . . . . . . . . . 9 4.1.3.3. Unavailable and Deleted Data . . . . . . . . . . . . 10 4.1.3.4. Insufficient Permissions . . . . . . . . . . . . . . 10 4.1.3.5. Redirection . . . . . . . . . . . . . . . . . . . . 10 4.1.2.2. Gaming Prevention . . . . . . . . . . . . . . . . . .8 4.4.1. Server reliability (Agnostic of reliability) . . . . . 12 10. Server Status Query Requirements . . . . . . . . . . . . . . . 18 5.7. Storage Status . . . . . . . . . . . . . . . . . . . . . 20 .... 11. Security Considerations . . . . . . . . . . . . . . . . . . . 21 7.1. Authentication and Authorization . . . . . . . . . . . . 21 7.2. Encrypted Data . . . . . . . . . . . . . . . . . . . . . 22 7.3. Protection against Gaming . . . . . . . . . . . . . . . 22 --_000_E33E01DFD5BEA24B9F3F18671078951F23AE871Bszxeml534mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Peng,

I tend to = agree with all your proposals.

Thanks,

-Haibin

From: decade-bou= nces@ietf.org [mailto:decade-bounces@ietf.org] On Behalf Of Zhang Peng
Sent: Monday, July 02, 2012 2:02 PM
To: yry; DECADE@ietf.org
Subject: Re: [decade] -req and -arch documents

 

Hi Richard,

 

Thanks for your effort. Here are so= me suggestion about the revision of -req documents.

 

First, regarding Q1, I think there = are indeed some overlaps on term definitions in -req and -arch documen= ts. In addition, they are even not consistent. I think we can just put them in the -req document, and give a pointer in -arch document. =

Regarding Q2, I agree that in -arch= , there are some paragraphs that also do the job of define requirements, an= d may better be put in -req. For naming, the reqiin -requirements given in -req are rather simplistic, and we can move the move the det= ailed requirements to -req. But for "immutable object", I th= ink it is more like a design option for the architecture (so that the desig= n would be much simplified), rather than a system requirements for DECADE to function.  Thus, I suggest we don't move the immutable = data objects in -arch to -req, and we can even delete them in -req. Finally= , I would say that there is no clear cut for requirement and architecture, = since when we specify the requirements, we have some design rationale in mind; and when we design the architecture= , we would find more clear requirements for the specific design. It is not = easy to fully decouple them.

Regarding Q3, I think the new outli= ne of the -req document seems better, but I think it is better to organize = it into three parts: access/authorization, resource control, data storage/transfer, failure handling/gaming prevention. The rationale i= s that the first part is about how client access the server, the second par= t corresponds to DRP, the third part corresponds to SDT, and the last two p= arts are about reliability/security. The following is the outline in my mind. I would like to discuss with you = about the organization further. And I would like to help revise the -req do= cument.  Thanks.

 

Best,

 

Peng.

 

1. Introduction . . . . . . . . . . . . .= . . . . . . . . . . . . 5

2. Terminology and Concepts . . . . . . .= . . . . . . . . . . . . 6

3. System/Functional Components

4. Requirements Structure . . . . . . . .= . . . . . . . . . . . . 7

 

5. Data Object Requirements

4.5.1. Data Naming . . . . . . . . . . . . .= . . . . . . . . .14

Move part of Arch 4.4 to -req

4.2.1. Data Object Size . . . . . . . . . . = . . . . . . . 11

4.4.2. System Data Object Attributes . . . .= . . . . . . . . .13

4.4.3. Time-to-live for Written Data Objects= . . . . . . 13

4.4.4. Application-defined Properties and Me= tadata . . . . . 13

 

6. Authentication and Access Requirements=

4.7.1. Per-Remote-Client, Per-Data Read Acce= ss . . . . . . . 16

4.7.2. Per-User Write Access . . . . . . . .= . . . . . . . . 17

4.7.3. Default Access Permissions . . . . . = . . . . . . . . . 17

4.7.4. Authorization Checks . . . . . . . . = . . . . . . . . . 17

4.7.5. Cryptographic Credentials . . . . . .= . . . . . . . . 17

4.7.6. Server Involvement . . . . . . . . . = . . . . . . . . . 18

4.7.7. Protocol Reuse . . . . . . . . . . . = . . . . . . . . . 18

4.3.1. Read/Write Own Storage . . . . . . . = . . . . . . . .. 11

4.3.2. Read/Write by Remote Clients . . . . = . . . . . . . . . 11

4.4.5. Offline Access . . . . . . . . . . . = . . . . . . . . 14

 

7. Data Transfer Requirements <= /o:p>

4.1.1.1. NATs and Firewalls TRaversal . . ..= . . . . . . . . 8

Connections to Clients . . . . . . . . . . .= . . . . . . . . 8

6.1.1. Support for Clients Behind NATs and F= irewalls . . . 21

4.3.3. Negotiable Data Transport Protocol . = . . . . . . . . . 12

4.1.2.1. Secure Transport . . . . . . . . . = . . . . . . . . . 8

 

8. Resource Control Requirements. . . . .= . . . . . . . . . . . . 15

4.6.1. Multiple Applications . . . . . . . .= . . . . . . . . 15

4.6.2. Per-Remote-Client, Per-Data Control .= . . . . . . . . 15

4.6.3. Resource Control Set . . . . . . . . = . . . . . . . . . 16

4.6.4. Server Involvement . . . . . . . . . = . . . . . . . . . 16

8. Authorization Requirements

 

9. Error and Failure Handling Requirement= s. . . . . . . . . . . . 9

4.1.3.2. Insufficient Resources . . . . . . = . . . . . . . . . 9

4.1.3.1. Overload Condition . . . . . . . . = . . . . . . . 9

4.1.3.3. Unavailable and Deleted Data . . . = . . . . . . . . . 10

4.1.3.4. Insufficient Permissions . . . . . = . . . . . . . . . 10

4.1.3.5. Redirection . . . . . . . . . . . .= . . . . . . . . 10

4.1.2.2. Gaming Prevention . . . . . . . . .= . . . . . . . . .8

4.4.1. Server reliability (Agnostic of relia= bility) . . . . . 12

 

10. Server Status Query Requirements . . = . . . . . . . . . . . . . 18

5.7. Storage Status . . . . . . . . . . . . = . . . . . . . . . 20

....

 

11. Security Considerations . . . . . . .= . . . . . . . . . . . . 21

7.1. Authentication and Authorization . . . = . . . . . . . . . 21

7.2. Encrypted Data . . . . . . . . . . . . = . . . . . . . . . 22

7.3. Protection against Gaming . . . . . . .= . . . . . . . . 22

 

Zhang Peng

 

Date: 2012-06-30 06:40

Subject: [decade] -req and -arch documents

Dear DECADE participants,

 

Both -req and -arch docu= ments have received extensive, excellent 

reviews. In the process = of revising the documents and looking at = ;the two 

documents, we have some = questions to seek input from the participants= :

 

Q1. Both -req and -arch&= nbsp;define some terms, including DECADE-compatible&nbs= p;

client, DECADE-compatible server,&= nbsp;etc. This appears to be redundant. =

Should such terms be def= ined in -req or -arch? The current think= ing is 

-req. Any comments?

 

Q2. There are multiple p= aragraphs defining requirements in -arch, e.g.,&nb= sp;

Sec. 4.4 on naming. Shou= ld these be moved to -req? A more g= eneral 

question is on the depen= dency between -req and -arch. On one han= d, it is 

ideal to define -req fir= st without a particular architecture to allow=  

competing/alternative architectures&nbs= p;satisfying the requirements. On the <= /span>

other hand, it appears t= hat the -arch document contains content, in&n= bsp;

particular, systems/function compo= nents, that can be helpful to better 

understand the -req document.=  The current thinking is still to make&n= bsp;-req 

independent of -arch, and&nbs= p;move some general requirements in -arch to&= nbsp;

-req. Any comments?

 

Q3: There are some good&= nbsp;comments on reorganizing the -req documents.&= nbsp;

Below is a new structure=  (second level section #'s and page numb= ers are 

from the current -req so=  that others can see how we re-organize&= nbsp;the 

document). Any comments/feedback&n= bsp;before we start the revision will be = ;

greatly appreciated.<= /p>

 

Also, anyone who can hel= p with direct revisions of the -req docu= ment 

will be more than welcom= e!

 

Thanks.

 

-- 

Richard

 

1.  Introduction . .&nbs= p;. . . . . . . . . . .&n= bsp;. . . . . . . . . . .=  .  5

2.  Terminology and Conc= epts . . . . . . . . . .&= nbsp;. . . . . . . . .  6=

3.  System/Functional Compone= nts

4.  Requirements Structure&nb= sp;. . . . . . . . . . .&= nbsp;. . . . . . . . .  7=

 

5.  Data Object Requirem= ents

     4.5.1. &n= bsp;Data Naming . . . . . . . = . . . . . . . . . . .&nbs= p;. . . .14

       &n= bsp;     Move part of Arch 4.4=  to -req

     5.1. &nbs= p;--Immutable Data . . . . . . .&nb= sp;. . . . . . . . . . .&= nbsp;. . 18

     4.4.2. &n= bsp;System Data Object Attributes . . . = . . . . . . . . . .13

       &n= bsp; 4.2.1.  Data Object Size . . .=  . . . . . . . . . . = ;. . . . 11

       &n= bsp; 4.4.3.  Time-to-live for Written Data&nb= sp;Objects  . . . . . . 13

     4.4.4. &n= bsp;Application-defined Properties and Metadata  .=  . . . . 13

 

6.  Access to Server&nbs= p;Requirements

     4.3.1. &n= bsp;Read/Write Own Storage  . . . . = ;. . . . . . . . . . ..&n= bsp;11

     4.3.2. &n= bsp;Read/Write by Remote Clients . . . .=  . . . . . . . . . 11

     4.4.5. &n= bsp;Offline Access  . . . . . .&nbs= p;. . . . . . . . . . &nb= sp;. . . 14

     4.1.1.1. =  NATs and Firewalls TRaversal . . ..&nbs= p;. .  . . . . . .  8

       Co= nnections to Clients . . . . . .&nb= sp;. . . . . . . . . . .&= nbsp;. .  8

       6.= 1.1.  Support for Clients Behind NATs an= d Firewalls  . . . 21

     4.3.3. &n= bsp;Negotiable Data Transport Protocol . . .&= nbsp;. . . . . . . 12<= /p>

     5.2. &nbs= p;Explicit Deletion of Data  . . . = . . . . . . . . . . .&nbs= p;. 19

     5.3. &nbs= p;Concurrent Write (Multiple writing). . . .&= nbsp;. . . . . . . 19<= /p>

     5.4. &nbs= p;Concurrent Read (Multiple reading) . . .&nb= sp;. . . . . . . . 19

     5.5. &nbs= p;Read While Write . . . . . . = ;. .   . . . . . . . = ;. . . . 19

     5.6. &nbs= p;Partial Write (Writing model) . . . .&= nbsp;. . . . . . . . . 20=

     4.1.2.1. =  Secure Transport . . . . . . = . . . . . . . . . . .&nbs= p;.  8

 

7.  Resource Control Req= uirements. . . . . . . . . .&n= bsp;. . . . . . . 15

     4.6.1. &n= bsp;Multiple Applications  . . . . .&nbs= p;. . . . . . . . . . .&n= bsp;15

     4.6.2. &n= bsp;Per-Remote-Client, Per-Data Control  . . = . . . . . . . 15

     4.6.3. &n= bsp;Resource Control Set . . . . . = . . . . . . . . . . .&nbs= p;. 16

     4.6.4. &n= bsp;Server Involvement . . . . . . = . . . . . . . . . . .&nbs= p;. 16

 

8.  Authorization Requirement= s

     4.7.1. &n= bsp;Per-Remote-Client, Per-Data Read Access  .&nbs= p;. . . . . . 16

     4.7.2. &n= bsp;Per-User Write Access  . . . . = . . . . . . . . . . .&nbs= p;. 17

     4.7.3. &n= bsp;Default Access Permissions . . . . .=  . . . . . . . . . 17

     4.7.4. &n= bsp;Authorization Checks . . . . . .&nbs= p;. . . . . . . . . . .&n= bsp;17

     4.7.5. &n= bsp;Cryptographic Credentials  . . . . .=  . . . . . . . . . 17

     4.7.6. &n= bsp;Server Involvement . . . . . . = . . . . . . . . . . .&nbs= p;. 18

     4.7.7. &n= bsp;Protocol Reuse . . . . . . .&nb= sp;. . . . . . . . . . .&= nbsp;. . 18

 

9.  Error and Failure&nb= sp;Handling Requirements. . . . . . .&nb= sp;. . . . .  9

     4.1.3.2. =  Insufficient Resources . . . . . .=  . . . . . . . . .  = 9

       &n= bsp; 4.1.3.1.  Overload Condition . . .&= nbsp;. . . . . . . . . . = . .  9

     4.1.3.3. =  Unavailable and Deleted Data . . . = ;. . . . . . . . . 10

     4.1.3.4. =  Insufficient Permissions . . . . . = ;. . . . . . . . . 10

     4.1.3.5. =  Redirection  . . . . . . .&nb= sp;. . . . . . . . . . .&= nbsp;. . 10

     4.1.2.2. =  Gaming Prevention  . . . . . = . . . . . . . . . . .&nbs= p;. .8

     4.4.1. &n= bsp;Server reliability (Agnostic of reliability) .=  . . . . 12

 

10. Server Status Query = Requirements . . . . . . . . .=  . . . . . . 18

     5.7. &nbs= p;Storage Status . . . . . . . = ;. . . . . . . . . . .&nb= sp;. . . 20

     ....

 

11. Security Considerations &= nbsp;. . . . . . . . . . = . . . . . . . . . 21

     7.1. &nbs= p;Authentication and Authorization . . . .&nb= sp;. . . . . . . . 21

     7.2. &nbs= p;Encrypted Data . . . . . . . = ;. . . . . . . . . . .&nb= sp;. . . 22

     7.3. &nbs= p;Protection against Gaming  . . . .&nbs= p;. . . . . . . . . . .&n= bsp;22

 

 

--_000_E33E01DFD5BEA24B9F3F18671078951F23AE871Bszxeml534mbxchi_-- From haibin.song@huawei.com Fri Jul 6 02:31:48 2012 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 AFCDE21F8752 for ; Fri, 6 Jul 2012 02:31:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.263 X-Spam-Level: X-Spam-Status: No, score=-6.263 tagged_above=-999 required=5 tests=[AWL=0.336, 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 ZqOOPS42AoO0 for ; Fri, 6 Jul 2012 02:31:47 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 0BA8B21F8738 for ; Fri, 6 Jul 2012 02:31:47 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AHT41434; Fri, 06 Jul 2012 05:32:02 -0400 (EDT) Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 6 Jul 2012 02:30:56 -0700 Received: from SZXEML424-HUB.china.huawei.com (10.82.67.163) by dfweml405-hub.china.huawei.com (10.193.5.102) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 6 Jul 2012 02:30:54 -0700 Received: from SZXEML534-MBX.china.huawei.com ([169.254.2.243]) by szxeml424-hub.china.huawei.com ([10.82.67.163]) with mapi id 14.01.0323.003; Fri, 6 Jul 2012 17:30:42 +0800 From: Songhaibin To: "Rahman, Akbar" , "decade@ietf.org" Thread-Topic: [decade] Working Group Last Call: draft-ietf-decade-arch-07 Thread-Index: Ac1PUmra8pF/55OcSfCOdrGa28N+SwLFn0TQADupEBA= Date: Fri, 6 Jul 2012 09:30:42 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.73] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: Konstantinos Pentikousis Subject: Re: [decade] Working Group Last Call: draft-ietf-decade-arch-07 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, 06 Jul 2012 09:31:48 -0000 Thanks to Akbar for posting Kostas's comments to the list. > -----Original Message----- > From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.org] On Behalf = Of > Rahman, Akbar > Sent: Thursday, July 05, 2012 1:21 PM > To: decade@ietf.org > Cc: Konstantinos Pentikousis > Subject: Re: [decade] Working Group Last Call: draft-ietf-decade-arch-07 >=20 > Hi, >=20 >=20 > The DECADE Architecture authors were contacted off list by Kostas who > provided the following relevant and useful comments on the > draft-ietf-decade-arch-07. We intend to address these comments in the > next revision of the architecture I-D after the WGLC ends. >=20 > 1) Figure 1: > This figure and the accompanying text (as-is right now) leaves quite > some room for interpretation. For example, two distinct > "DECADE-compatible" systems deployed by two different operators may have > DRP1 vs. DPR2, in addition to having multiple SDTxyz's. Is this what you > have in mind? >=20 I think this needs clarification in the text. IMO DRP is one protocol that = allows variable parameters, so there should be no interoperation problems. = For SDT, in early discussion in the working group and also in the Charter, = it allows multiple SDTs, so one mandatory SDT would be specified in a proto= col document for interoperation. (The mandatory SDT was specified in the ar= chitecture document, but the consensus in the WG was to remove it as this d= ocument is the architecture.) >=20 > 2) Section 4.2, Referring to the word "multipath": > I think you mean multi-source here? Multipath is mostly related with two > (multihomed) end nodes and routing in the network rather than one node > getting bits and pieces of a data object from different sources (as in > P2P). You can still have multipath and single-source. >=20 IMO the understanding is right. >=20 > 3) Section 4.2, third paragraph, first sentence: > As per the sec. 2.8, a "data object is a string of raw bytes". > Therefore, in this sentence we need s/SHOULD/MUST. >=20 >=20 > 4) Section 4.2, third paragraph, second sentence: > This may introduce the issue of MDO discovery (max data object), when > one connects to different DECADE Servers, perhaps along the lines of MTU > discovery. Content resegmentation is not covered in this section, esp. > since a DECADE server may store/maintain DOs from completely different > apps. > Make sense to me. IP packet segmentation may cause problems for NAT travers= al. But I'm still not sure. Any thoughts from others? BR, -Haibin >=20 > 5) Section 4.2, last paragraph: > The introduction of the "block" may be redundant here. A block is, > similarly to a DO, "a string of raw bytes", isn't it? If not, we need a > formal definition for it. Of course, the key aspect here is what can you > name and locate in a DECADE Server, and my reading of the ID so far is > that you have settled on the use of the DO, irrespective of the > application semantics. The repeated use of "block" here and there simply > confuses the uninitiated reader. >=20 >=20 > 6) Section 4.4, 2nd to last paragraph: > I think the optimization described in this paragraph is not particularly > suited for the Architecture document. And it opens up all kinds of > questions. E.G. what if the host advertizing an object crashes before > it uploads the object? What if the host changes its mind during the > upload? Since we're talking about immutable objects, shouldn't we wait > until an object is "committed". In the end, this optimization could be > counter-productive in these cases. Let alone the fact that the scenarios > for which DECADE is envisaged (and motivated from I would add) tend to > have asymmetric capacities in down/uplink, perhaps of a ratio of 10:1. > Thus, downloading is not typically the performance bottleneck. Perhaps I > am wrong in thinking of this as a premature optimization though. Can you > provide examples from exisiting apps that follow this proposal (and how > do they handle error cases)? >=20 > Moreover, using SHOULD for such a optimization may not be a good idea in > the general case. >=20 >=20 > 7) Figure 3: > This figure implies that multiple applications will need to implement > their own DECADE client, which cannot be shared at run time with other > apps. Of course one could see this as including/linking to a library, > but perhaps a more flexible implementation could also be thought of, > based, for example, on a DECADE "platform", shared by many apps at run > time. >=20 >=20 > 8) Section 6.1.2, second to last paragraph: > This proposed optimization need not be part of the "architecture" >=20 >=20 > 9) Section 6.1.3: > Wouldn't it be better to skip this section altogether and consider an ID > on management aspects instead? For example, why not simply define an MIB > for DECADE and use existing methods to obtain this status info? Why add > more complexity in DRP implementations? >=20 >=20 > 10) Section 10.2: > http://dx.doi.org/10.1145/1544012.1544078 should also be added here, as > it motivates well the domain considered in this architecture, including > the DO. >=20 >=20 > 11) Various editorial and grammatical fixes (which were provided to the > authors off line). >=20 >=20 > Many thanks to Kostas for providing these excellent comments. >=20 >=20 > Akbar >=20 >=20 > -----Original Message----- > From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.org] On Behalf > Of Songhaibin > Sent: Wednesday, June 20, 2012 10:06 PM > To: decade@ietf.org > Subject: [decade] Working Group Last Call: draft-ietf-decade-arch-07 >=20 > Dear folks, >=20 > After the first round of the last call, the architecture document has > many changes to resolve comments from reviewers as well as area director > and experts from other areas. Thanks to the reviewers and the authors. >=20 > So Rich and I now start another round of WGLC on > draft-ietf-decade-arch-07, ending Friday, July 6th. Please review the > document and reply with your comments. >=20 > Thanks, >=20 > -Haibin and Rich (co-chairs) From stephen.farrell@cs.tcd.ie Fri Jul 6 02:52:34 2012 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 A9DF821F8768 for ; Fri, 6 Jul 2012 02:52:34 -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 X5paWUBD7G60 for ; Fri, 6 Jul 2012 02:52:33 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 4619921F8764 for ; Fri, 6 Jul 2012 02:52:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 3614B1714F5; Fri, 6 Jul 2012 10:52:47 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1341568366; bh=w7Qywdkkj/hHPK 7AdQPpNXxf8CQvsq9GxbeLORvvx54=; b=3MXsJN1uC+zV4MpxJx0PqTR9bFTpgM olmABFT2jDII4d6SBRS5CFdPc2TKd6PVx7Si2AOi6WAyPdQry7KFf7S5XU7WETXd 7z3w3OtyVrwfFqlYj6vXplTxw+vLLUCnbwKEWyq8oMFR+1kMM2MRLIfi9St5kpOD rZN/4KzIh46AaM1/Ha6O/nRM2BrX7qj9nKg62xhJQM/hBpeO+frrS3V7CH/MPxpn LHuHNqLoAqfqoRRd+SeTltXjPHAH81A7CBenI7aZYjF0Nme4nqh0uCij1fm22jiW tA45W1isvPa2SUmZz/MzQRgutTNNHbW2/V5Byu/+k0q38fPE2FYR9EQw== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id 9lfwvCFCbZix; Fri, 6 Jul 2012 10:52:46 +0100 (IST) Received: from [IPv6:2001:770:10:203:e993:2cab:e0c2:33e7] (unknown [IPv6:2001:770:10:203:e993:2cab:e0c2:33e7]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id D882E1714F3; Fri, 6 Jul 2012 10:52:38 +0100 (IST) Message-ID: <4FF6B567.90100@cs.tcd.ie> Date: Fri, 06 Jul 2012 10:52:39 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: "pzhang.thu" References: , <20120705211556235011353@gmail.com> In-Reply-To: <20120705211556235011353@gmail.com> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "DECADE@ietf.org" , Konstantinos Pentikousis Subject: Re: [decade] Working Group Last Call: draft-ietf-decade-arch-07 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, 06 Jul 2012 09:52:34 -0000 I'm not sure if designing optimisations is best done when considering requirements. It sounds like something liable to lead to premature optimisation. On 07/06/2012 02:15 AM, Zhang Peng wrote: > Hi, > > As for the comment (6) regarding optimization about naming, I think we need further discussion. > > The question is that whether the name SHOULD be generated and returned to the client before commitment to the uploading. > > First, we should evaluate the gain by using this what i term as "early name generation". Consider that a client A is uploading a object F to DECADE server D, and another client B needs to download it from D. Below is the stages to be taken without considering authentication, and access control. > > 1. A sends upload request to D, which responses with a permission > 2. A uploads F to D > 3. D returns the object name to A > 4. A advertises the object > 5. B knows the file name and request the object from D > 6. D sends the object to B > > Here 1,3,4,5 may cost constant small amount of time, while 2,6, depend on the size of object and tend to cost more time. The benefit of putting 3 before 2 is that 4 and 5 can be carried out in parallel with 2. Thus it seems that we can just save the time of 4 and 5 in this process. But considering that B is in different locations, and using another DECADE sever E, then we can also save the time for E request the object from D. In addition, It may also take more time if we consider the case that A should advertise to a lot of interested receivers, which may consume more time. Without this non-quantitative analysis, it seems that it can benefits the live applications to reduce the latency. But the benefits are not so clear, and may depend on applications. Putting "3 before 2" wouldn't be the only option though. For example, A could upload Hash(F) which might be used in generating the object name at step 1. There are many ways to do things, setting up requirements that things be done in one way seems like a bad plan to me. S. > If we would include this in -arch as a design requirements, we need to handle some erroneous situations, just as mentioned by Kostas. When the client advertises a object, but does not upload or finish the uploading, the DECADE server, however, may have already grant the object or send the part of the object to some receiver. Then the server should just sends a error signal to the granted receivers, or let the receivers timeout themselves, and delete the object. Retransmission may or may not happen, depending on the application implementation. > > I am still not quite sure whether the potential benefits of this optimization worth the complication it brings. More discussion may be needed. Thanks. > > B, > > Peng. > > > From: Rahman, Akbar > Date: 2012-07-05 01:21 > To: decade@ietf.org > CC: Konstantinos Pentikousis > Subject: Re: [decade] Working Group Last Call: draft-ietf-decade-arch-07 > Hi, > > > The DECADE Architecture authors were contacted off list by Kostas who > provided the following relevant and useful comments on the > draft-ietf-decade-arch-07. We intend to address these comments in the > next revision of the architecture I-D after the WGLC ends. > > 1) Figure 1: > This figure and the accompanying text (as-is right now) leaves quite > some room for interpretation. For example, two distinct > "DECADE-compatible" systems deployed by two different operators may have > DRP1 vs. DPR2, in addition to having multiple SDTxyz's. Is this what you > have in mind? > > > 2) Section 4.2, Referring to the word "multipath": > I think you mean multi-source here? Multipath is mostly related with two > (multihomed) end nodes and routing in the network rather than one node > getting bits and pieces of a data object from different sources (as in > P2P). You can still have multipath and single-source. > > > 3) Section 4.2, third paragraph, first sentence: > As per the sec. 2.8, a "data object is a string of raw bytes". > Therefore, in this sentence we need s/SHOULD/MUST. > > > 4) Section 4.2, third paragraph, second sentence: > This may introduce the issue of MDO discovery (max data object), when > one connects to different DECADE Servers, perhaps along the lines of MTU > discovery. Content resegmentation is not covered in this section, esp. > since a DECADE server may store/maintain DOs from completely different > apps. > > > 5) Section 4.2, last paragraph: > The introduction of the "block" may be redundant here. A block is, > similarly to a DO, "a string of raw bytes", isn't it? If not, we need a > formal definition for it. Of course, the key aspect here is what can you > name and locate in a DECADE Server, and my reading of the ID so far is > that you have settled on the use of the DO, irrespective of the > application semantics. The repeated use of "block" here and there simply > confuses the uninitiated reader. > > > 6) Section 4.4, 2nd to last paragraph: > I think the optimization described in this paragraph is not particularly > suited for the Architecture document. And it opens up all kinds of > questions. E.G. what if the host advertizing an object crashes before > it uploads the object? What if the host changes its mind during the > upload? Since we're talking about immutable objects, shouldn't we wait > until an object is "committed". In the end, this optimization could be > counter-productive in these cases. Let alone the fact that the scenarios > for which DECADE is envisaged (and motivated from I would add) tend to > have asymmetric capacities in down/uplink, perhaps of a ratio of 10:1. > Thus, downloading is not typically the performance bottleneck. Perhaps I > am wrong in thinking of this as a premature optimization though. Can you > provide examples from exisiting apps that follow this proposal (and how > do they handle error cases)? > > Moreover, using SHOULD for such a optimization may not be a good idea in > the general case. > > > 7) Figure 3: > This figure implies that multiple applications will need to implement > their own DECADE client, which cannot be shared at run time with other > apps. Of course one could see this as including/linking to a library, > but perhaps a more flexible implementation could also be thought of, > based, for example, on a DECADE "platform", shared by many apps at run > time. > > > 8) Section 6.1.2, second to last paragraph: > This proposed optimization need not be part of the "architecture" > > > 9) Section 6.1.3: > Wouldn't it be better to skip this section altogether and consider an ID > on management aspects instead? For example, why not simply define an MIB > for DECADE and use existing methods to obtain this status info? Why add > more complexity in DRP implementations? > > > 10) Section 10.2: > http://dx.doi.org/10.1145/1544012.1544078 should also be added here, as > it motivates well the domain considered in this architecture, including > the DO. > > > 11) Various editorial and grammatical fixes (which were provided to the > authors off line). > > > Many thanks to Kostas for providing these excellent comments. > > > Akbar > > > -----Original Message----- > From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.org] On Behalf > Of Songhaibin > Sent: Wednesday, June 20, 2012 10:06 PM > To: decade@ietf.org > Subject: [decade] Working Group Last Call: draft-ietf-decade-arch-07 > > Dear folks, > > After the first round of the last call, the architecture document has > many changes to resolve comments from reviewers as well as area director > and experts from other areas. Thanks to the reviewers and the authors. > > So Rich and I now start another round of WGLC on > draft-ietf-decade-arch-07, ending Friday, July 6th. Please review the > document and reply with your comments. > > Thanks, > > -Haibin and Rich (co-chairs) > From pzhang.thu@gmail.com Fri Jul 6 08:35:27 2012 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 BAED321F85A5 for ; Fri, 6 Jul 2012 08:35:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.895 X-Spam-Level: X-Spam-Status: No, score=-0.895 tagged_above=-999 required=5 tests=[AWL=0.350, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_63=0.6, MIME_BASE64_TEXT=1.753, 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 6EUHODDlu8lH for ; Fri, 6 Jul 2012 08:35:26 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id C307621F85A0 for ; Fri, 6 Jul 2012 08:35:25 -0700 (PDT) Received: by yenq13 with SMTP id q13so9572260yen.31 for ; Fri, 06 Jul 2012 08:35:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:reply-to:subject:references:x-priority:x-guid :x-mailer:mime-version:message-id:content-type; bh=NiH9W9Dbfg2oNP6rtUyPSbZnv4kRs1YmUBhAGo9dahg=; b=Wv361h93uVRqAiKhH0TwFqr79KzBm0JK4drq9sJNW5uurmzm/bX6MIPn3WLxphww5W Ygz+FRLvg6jeYiQHNTq1jso6ct7cdPEzfF9Cr1Y/ypyK+UVi6ZC19r/PYQoYommAcg0i E3NPutWIv/nSFb647+ddNTLnQ6aT2skf9moXpcg/rfD7WkE60Tpyt+Nl6w4GLq/WDtK8 +NvdHIHFqy0LO2s9E1wyQ5gUHri7h4PDAjOzA9fveNnNW24PJ26RaVQivoYcrbEl9Q/d rgucU1kZkbofcsx2jlFpC1OjX/5MVMmPKHlsbUkhFTLmN0QyfVhvCHkBJLHaUTOByjU1 Rlhg== Received: by 10.236.75.232 with SMTP id z68mr36407760yhd.90.1341588942161; Fri, 06 Jul 2012 08:35:42 -0700 (PDT) Received: from pzhang-PC (dhcp-130-132-249-182.central.yale.edu. [130.132.249.182]) by mx.google.com with ESMTPS id u23sm46460504yhl.21.2012.07.06.08.35.41 (version=SSLv3 cipher=OTHER); Fri, 06 Jul 2012 08:35:41 -0700 (PDT) Date: Fri, 6 Jul 2012 11:35:39 -0400 From: "Zhang Peng" To: "Stephen Farrell" References: , <20120705211556235011353@gmail.com>, <4FF6B567.90100@cs.tcd.ie> X-Priority: 3 X-GUID: 9D61A127-04F5-4345-87FF-CFBA0D65FD53 X-Mailer: Foxmail 7.0.1.81[cn] Mime-Version: 1.0 Message-ID: <20120706113539320678363@gmail.com> Content-Type: multipart/alternative; boundary="----=_001_NextPart431821146361_=----" Cc: "DECADE@ietf.org" , Konstantinos Pentikousis Subject: Re: [decade] Working Group Last Call: draft-ietf-decade-arch-07 X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "pzhang.thu" 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, 06 Jul 2012 15:35:27 -0000 This is a multi-part message in MIME format. ------=_001_NextPart431821146361_=---- Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 SGkgU3RlcGhlbiwNCg0KSSBhZ3JlZSB3aXRoIHlvdSwgYW5kIHN1Z2dlc3QgdGhhdCB0aGlzIG9w dGltaXphdGlvbiBzaG91bGQgbm90IGFwcGVhciBpbiAtYXJjaCBkb2N1bWVudCwgc2luY2UgaXQg aXMgdG9vIGRldGFpbGVkLCBhbmQgbWF5IHJhaXNlIG1vcmUgY29uY2VybnMgdGhhbiBpdCBzb2x2 ZXMuIE9yIHdlIGNhbiB1c2UgTUFZIGluc3RlYWQgb2YgU0hPVUxEIHRvIGluZGljYXRlIHRoYXQg dGhpcyBpcyBhIG9wdGlvbmFsIGZlYXR1cmUgdGhhdCBhcmUgcHJlZmVyYWJsZSwgYW5kIHN0YXRl IGNsZWFybHkgdGhlIGlzc3VlcyB0aGF0IG1heSBhcmlzZSAoaS5lLiwgaG93IHRvIGRlYWwgd2l0 aCBjbGllbnQgYWJvcnRpb24pLiBIb3cgd291bGQgb3RoZXJzIHRoaW5rPyBUaGFua3MuDQoNCkIs DQoNClBlbmcuDQoNCg0KDQpGcm9tOiBTdGVwaGVuIEZhcnJlbGwNCkRhdGU6IDIwMTItMDctMDYg MDU6NTINClRvOiBwemhhbmcudGh1DQpDQzogUmFobWFuLCBBa2JhcjsgREVDQURFQGlldGYub3Jn OyBLb25zdGFudGlub3MgUGVudGlrb3VzaXMNClN1YmplY3Q6IFJlOiBbZGVjYWRlXSBXb3JraW5n IEdyb3VwIExhc3QgQ2FsbDogZHJhZnQtaWV0Zi1kZWNhZGUtYXJjaC0wNw0KDQpJJ20gbm90IHN1 cmUgaWYgZGVzaWduaW5nIG9wdGltaXNhdGlvbnMgaXMgYmVzdCBkb25lDQp3aGVuIGNvbnNpZGVy aW5nIHJlcXVpcmVtZW50cy4gSXQgc291bmRzIGxpa2Ugc29tZXRoaW5nDQpsaWFibGUgdG8gbGVh ZCB0byBwcmVtYXR1cmUgb3B0aW1pc2F0aW9uLg0KDQpPbiAwNy8wNi8yMDEyIDAyOjE1IEFNLCBa aGFuZyBQZW5nIHdyb3RlOg0KPiBIaSwNCj4gDQo+IEFzIGZvciB0aGUgY29tbWVudCAoNikgcmVn YXJkaW5nIG9wdGltaXphdGlvbiBhYm91dCBuYW1pbmcsIEkgdGhpbmsgd2UgbmVlZCBmdXJ0aGVy IGRpc2N1c3Npb24uDQo+IA0KPiBUaGUgcXVlc3Rpb24gaXMgdGhhdCB3aGV0aGVyIHRoZSBuYW1l IFNIT1VMRCBiZSBnZW5lcmF0ZWQgYW5kIHJldHVybmVkIHRvIHRoZSBjbGllbnQgYmVmb3JlIGNv bW1pdG1lbnQgdG8gdGhlIHVwbG9hZGluZy4NCj4gDQo+IEZpcnN0LCB3ZSBzaG91bGQgZXZhbHVh dGUgdGhlIGdhaW4gYnkgdXNpbmcgdGhpcyB3aGF0IGkgdGVybSBhcyAiZWFybHkgbmFtZSBnZW5l cmF0aW9uIi4gQ29uc2lkZXIgdGhhdCBhIGNsaWVudCBBIGlzIHVwbG9hZGluZyBhIG9iamVjdCBG IHRvIERFQ0FERSBzZXJ2ZXIgRCwgYW5kIGFub3RoZXIgY2xpZW50IEIgbmVlZHMgdG8gZG93bmxv YWQgaXQgZnJvbSBELiBCZWxvdyBpcyB0aGUgc3RhZ2VzIHRvIGJlIHRha2VuIHdpdGhvdXQgY29u c2lkZXJpbmcgYXV0aGVudGljYXRpb24sIGFuZCBhY2Nlc3MgY29udHJvbC4gDQo+IA0KPiAxLiBB IHNlbmRzIHVwbG9hZCByZXF1ZXN0IHRvIEQsIHdoaWNoIHJlc3BvbnNlcyB3aXRoIGEgcGVybWlz c2lvbg0KPiAyLiBBIHVwbG9hZHMgRiB0byBEDQo+IDMuIEQgcmV0dXJucyB0aGUgb2JqZWN0IG5h bWUgdG8gQQ0KPiA0LiBBIGFkdmVydGlzZXMgdGhlIG9iamVjdCANCj4gNS4gQiBrbm93cyB0aGUg ZmlsZSBuYW1lIGFuZCByZXF1ZXN0IHRoZSBvYmplY3QgZnJvbSBEDQo+IDYuIEQgc2VuZHMgdGhl IG9iamVjdCB0byBCDQo+IA0KPiBIZXJlIDEsMyw0LDUgbWF5IGNvc3QgY29uc3RhbnQgc21hbGwg YW1vdW50IG9mIHRpbWUsIHdoaWxlIDIsNiwgZGVwZW5kIG9uIHRoZSBzaXplIG9mIG9iamVjdCBh bmQgdGVuZCB0byBjb3N0IG1vcmUgdGltZS4gVGhlIGJlbmVmaXQgb2YgcHV0dGluZyAzIGJlZm9y ZSAyIGlzIHRoYXQgNCBhbmQgNSBjYW4gYmUgY2FycmllZCBvdXQgaW4gcGFyYWxsZWwgd2l0aCAy LiBUaHVzIGl0IHNlZW1zIHRoYXQgd2UgY2FuIGp1c3Qgc2F2ZSB0aGUgdGltZSBvZiA0IGFuZCA1 IGluIHRoaXMgcHJvY2Vzcy4gQnV0IGNvbnNpZGVyaW5nIHRoYXQgQiBpcyBpbiBkaWZmZXJlbnQg bG9jYXRpb25zLCBhbmQgdXNpbmcgYW5vdGhlciBERUNBREUgc2V2ZXIgRSwgdGhlbiB3ZSBjYW4g YWxzbyBzYXZlIHRoZSB0aW1lIGZvciBFIHJlcXVlc3QgdGhlIG9iamVjdCBmcm9tIEQuIEluIGFk ZGl0aW9uLCBJdCBtYXkgYWxzbyB0YWtlIG1vcmUgdGltZSBpZiB3ZSBjb25zaWRlciB0aGUgY2Fz ZSB0aGF0IEEgc2hvdWxkIGFkdmVydGlzZSB0byBhIGxvdCBvZiBpbnRlcmVzdGVkIHJlY2VpdmVy cywgd2hpY2ggbWF5IGNvbnN1bWUgbW9yZSB0aW1lLiBXaXRob3V0IHRoaXMgbm9uLXF1YW50aXRh dGl2ZSBhbmFseXNpcywgaXQgc2VlbXMgdGhhdCBpdCBjYW4gYmVuZWZpdHMgdGhlIGxpdmUgYXBw bGljYXRpb25zIHRvIHJlZHVjZSB0aGUgbGF0ZW5jeS4gQnV0IHRoZSBiZW5lZml0cyBhcmUgbm90 IHNvIGNsZWFyLCBhbmQgbWF5IGRlcGVuZCBvbiBhcHBsaWNhdGlvbnMuIA0KDQpQdXR0aW5nICIz IGJlZm9yZSAyIiB3b3VsZG4ndCBiZSB0aGUgb25seSBvcHRpb24gdGhvdWdoLg0KRm9yIGV4YW1w bGUsIEEgY291bGQgdXBsb2FkIEhhc2goRikgd2hpY2ggbWlnaHQgYmUgdXNlZCBpbg0KZ2VuZXJh dGluZyB0aGUgb2JqZWN0IG5hbWUgYXQgc3RlcCAxLiBUaGVyZSBhcmUgbWFueSB3YXlzDQp0byBk byB0aGluZ3MsIHNldHRpbmcgdXAgcmVxdWlyZW1lbnRzIHRoYXQgdGhpbmdzIGJlIGRvbmUNCmlu IG9uZSB3YXkgc2VlbXMgbGlrZSBhIGJhZCBwbGFuIHRvIG1lLg0KDQpTLg0KDQo+IElmIHdlIHdv dWxkIGluY2x1ZGUgdGhpcyBpbiAtYXJjaCBhcyBhIGRlc2lnbiByZXF1aXJlbWVudHMsIHdlIG5l ZWQgdG8gaGFuZGxlIHNvbWUgZXJyb25lb3VzIHNpdHVhdGlvbnMsIGp1c3QgYXMgbWVudGlvbmVk IGJ5IEtvc3Rhcy4gV2hlbiB0aGUgY2xpZW50IGFkdmVydGlzZXMgYSBvYmplY3QsIGJ1dCBkb2Vz IG5vdCB1cGxvYWQgb3IgZmluaXNoIHRoZSB1cGxvYWRpbmcsIHRoZSBERUNBREUgc2VydmVyLCBo b3dldmVyLCBtYXkgaGF2ZSBhbHJlYWR5IGdyYW50IHRoZSBvYmplY3Qgb3Igc2VuZCB0aGUgcGFy dCBvZiB0aGUgb2JqZWN0IHRvIHNvbWUgcmVjZWl2ZXIuIFRoZW4gdGhlIHNlcnZlciBzaG91bGQg anVzdCBzZW5kcyBhIGVycm9yIHNpZ25hbCB0byB0aGUgZ3JhbnRlZCByZWNlaXZlcnMsIG9yIGxl dCB0aGUgcmVjZWl2ZXJzIHRpbWVvdXQgdGhlbXNlbHZlcywgYW5kIGRlbGV0ZSB0aGUgb2JqZWN0 LiBSZXRyYW5zbWlzc2lvbiBtYXkgb3IgbWF5IG5vdCBoYXBwZW4sIGRlcGVuZGluZyBvbiB0aGUg YXBwbGljYXRpb24gaW1wbGVtZW50YXRpb24uICANCj4gDQo+IEkgYW0gc3RpbGwgbm90IHF1aXRl IHN1cmUgd2hldGhlciB0aGUgcG90ZW50aWFsIGJlbmVmaXRzIG9mIHRoaXMgb3B0aW1pemF0aW9u IHdvcnRoIHRoZSBjb21wbGljYXRpb24gaXQgYnJpbmdzLiBNb3JlIGRpc2N1c3Npb24gbWF5IGJl IG5lZWRlZC4gVGhhbmtzLg0KPiANCj4gQiwNCj4gDQo+IFBlbmcuDQo+IA0KPiANCj4gRnJvbTog UmFobWFuLCBBa2Jhcg0KPiBEYXRlOiAyMDEyLTA3LTA1IDAxOjIxDQo+IFRvOiBkZWNhZGVAaWV0 Zi5vcmcNCj4gQ0M6IEtvbnN0YW50aW5vcyBQZW50aWtvdXNpcw0KPiBTdWJqZWN0OiBSZTogW2Rl Y2FkZV0gV29ya2luZyBHcm91cCBMYXN0IENhbGw6IGRyYWZ0LWlldGYtZGVjYWRlLWFyY2gtMDcN Cj4gSGksDQo+IA0KPiANCj4gVGhlIERFQ0FERSBBcmNoaXRlY3R1cmUgYXV0aG9ycyB3ZXJlIGNv bnRhY3RlZCBvZmYgbGlzdCBieSBLb3N0YXMgd2hvDQo+IHByb3ZpZGVkIHRoZSBmb2xsb3dpbmcg cmVsZXZhbnQgYW5kIHVzZWZ1bCBjb21tZW50cyBvbiB0aGUNCj4gZHJhZnQtaWV0Zi1kZWNhZGUt YXJjaC0wNy4gIFdlIGludGVuZCB0byBhZGRyZXNzIHRoZXNlIGNvbW1lbnRzIGluIHRoZQ0KPiBu ZXh0IHJldmlzaW9uIG9mIHRoZSBhcmNoaXRlY3R1cmUgSS1EIGFmdGVyIHRoZSBXR0xDIGVuZHMu ICANCj4gDQo+IDEpIEZpZ3VyZSAxOiANCj4gVGhpcyBmaWd1cmUgYW5kIHRoZSBhY2NvbXBhbnlp bmcgdGV4dCAoYXMtaXMgcmlnaHQgbm93KSBsZWF2ZXMgcXVpdGUNCj4gc29tZSByb29tIGZvciBp bnRlcnByZXRhdGlvbi4gRm9yIGV4YW1wbGUsICB0d28gZGlzdGluY3QNCj4gIkRFQ0FERS1jb21w YXRpYmxlIiBzeXN0ZW1zIGRlcGxveWVkIGJ5IHR3byBkaWZmZXJlbnQgb3BlcmF0b3JzIG1heSBo YXZlDQo+IERSUDEgdnMuIERQUjIsIGluIGFkZGl0aW9uIHRvIGhhdmluZyBtdWx0aXBsZSBTRFR4 eXoncy4gSXMgdGhpcyB3aGF0IHlvdQ0KPiBoYXZlIGluIG1pbmQ/DQo+IA0KPiANCj4gMikgU2Vj dGlvbiA0LjIsIFJlZmVycmluZyB0byB0aGUgd29yZCAibXVsdGlwYXRoIjogIA0KPiBJIHRoaW5r IHlvdSBtZWFuIG11bHRpLXNvdXJjZSBoZXJlPyBNdWx0aXBhdGggaXMgbW9zdGx5IHJlbGF0ZWQg d2l0aCB0d28NCj4gKG11bHRpaG9tZWQpIGVuZCBub2RlcyBhbmQgcm91dGluZyBpbiB0aGUgbmV0 d29yayByYXRoZXIgdGhhbiBvbmUgbm9kZQ0KPiBnZXR0aW5nIGJpdHMgYW5kIHBpZWNlcyBvZiBh IGRhdGEgb2JqZWN0IGZyb20gZGlmZmVyZW50IHNvdXJjZXMgKGFzIGluDQo+IFAyUCkuIFlvdSBj YW4gc3RpbGwgaGF2ZSBtdWx0aXBhdGggYW5kIHNpbmdsZS1zb3VyY2UuDQo+IA0KPiANCj4gMykg U2VjdGlvbiA0LjIsIHRoaXJkIHBhcmFncmFwaCwgZmlyc3Qgc2VudGVuY2U6DQo+IEFzIHBlciB0 aGUgc2VjLiAyLjgsIGEgImRhdGEgb2JqZWN0IGlzIGEgc3RyaW5nIG9mIHJhdyBieXRlcyIuDQo+ IFRoZXJlZm9yZSwgaW4gdGhpcyBzZW50ZW5jZSB3ZSBuZWVkIHMvU0hPVUxEL01VU1QuDQo+IA0K PiANCj4gNCkgU2VjdGlvbiA0LjIsIHRoaXJkIHBhcmFncmFwaCwgc2Vjb25kIHNlbnRlbmNlOg0K PiBUaGlzIG1heSBpbnRyb2R1Y2UgdGhlIGlzc3VlIG9mIE1ETyBkaXNjb3ZlcnkgKG1heCBkYXRh IG9iamVjdCksIHdoZW4NCj4gb25lIGNvbm5lY3RzIHRvIGRpZmZlcmVudCBERUNBREUgU2VydmVy cywgcGVyaGFwcyBhbG9uZyB0aGUgbGluZXMgb2YgTVRVDQo+IGRpc2NvdmVyeS4gQ29udGVudCBy ZXNlZ21lbnRhdGlvbiBpcyBub3QgY292ZXJlZCBpbiB0aGlzIHNlY3Rpb24sIGVzcC4NCj4gc2lu Y2UgYSBERUNBREUgc2VydmVyIG1heSBzdG9yZS9tYWludGFpbiBET3MgZnJvbSBjb21wbGV0ZWx5 IGRpZmZlcmVudA0KPiBhcHBzLg0KPiANCj4gDQo+IDUpIFNlY3Rpb24gNC4yLCBsYXN0IHBhcmFn cmFwaDoNCj4gVGhlIGludHJvZHVjdGlvbiBvZiB0aGUgImJsb2NrIiBtYXkgYmUgcmVkdW5kYW50 IGhlcmUuIEEgYmxvY2sgaXMsDQo+IHNpbWlsYXJseSB0byBhIERPLCAiYSBzdHJpbmcgb2YgcmF3 IGJ5dGVzIiwgaXNuJ3QgaXQ/IElmIG5vdCwgd2UgbmVlZCBhDQo+IGZvcm1hbCBkZWZpbml0aW9u IGZvciBpdC4gT2YgY291cnNlLCB0aGUga2V5IGFzcGVjdCBoZXJlIGlzIHdoYXQgY2FuIHlvdQ0K PiBuYW1lIGFuZCBsb2NhdGUgaW4gYSBERUNBREUgU2VydmVyLCBhbmQgbXkgcmVhZGluZyBvZiB0 aGUgSUQgc28gZmFyIGlzDQo+IHRoYXQgeW91IGhhdmUgc2V0dGxlZCBvbiB0aGUgdXNlIG9mIHRo ZSBETywgaXJyZXNwZWN0aXZlIG9mIHRoZQ0KPiBhcHBsaWNhdGlvbiBzZW1hbnRpY3MuIFRoZSBy ZXBlYXRlZCB1c2Ugb2YgImJsb2NrIiBoZXJlIGFuZCB0aGVyZSBzaW1wbHkNCj4gY29uZnVzZXMg dGhlIHVuaW5pdGlhdGVkIHJlYWRlci4NCj4gDQo+IA0KPiA2KSBTZWN0aW9uIDQuNCwgMm5kIHRv IGxhc3QgcGFyYWdyYXBoOg0KPiBJIHRoaW5rIHRoZSBvcHRpbWl6YXRpb24gZGVzY3JpYmVkIGlu IHRoaXMgcGFyYWdyYXBoIGlzIG5vdCBwYXJ0aWN1bGFybHkNCj4gc3VpdGVkIGZvciB0aGUgQXJj aGl0ZWN0dXJlIGRvY3VtZW50LiBBbmQgaXQgb3BlbnMgdXAgYWxsIGtpbmRzIG9mDQo+IHF1ZXN0 aW9ucy4gIEUuRy4gd2hhdCBpZiB0aGUgaG9zdCBhZHZlcnRpemluZyBhbiBvYmplY3QgY3Jhc2hl cyBiZWZvcmUNCj4gaXQgdXBsb2FkcyB0aGUgb2JqZWN0PyBXaGF0IGlmIHRoZSBob3N0IGNoYW5n ZXMgaXRzIG1pbmQgZHVyaW5nIHRoZQ0KPiB1cGxvYWQ/IFNpbmNlIHdlJ3JlIHRhbGtpbmcgYWJv dXQgaW1tdXRhYmxlIG9iamVjdHMsIHNob3VsZG4ndCB3ZSB3YWl0DQo+IHVudGlsIGFuIG9iamVj dCBpcyAiY29tbWl0dGVkIi4gSW4gdGhlIGVuZCwgdGhpcyBvcHRpbWl6YXRpb24gY291bGQgYmUN Cj4gY291bnRlci1wcm9kdWN0aXZlIGluIHRoZXNlIGNhc2VzLiBMZXQgYWxvbmUgdGhlIGZhY3Qg dGhhdCB0aGUgc2NlbmFyaW9zDQo+IGZvciB3aGljaCBERUNBREUgaXMgZW52aXNhZ2VkIChhbmQg bW90aXZhdGVkIGZyb20gSSB3b3VsZCBhZGQpIHRlbmQgdG8NCj4gaGF2ZSBhc3ltbWV0cmljIGNh cGFjaXRpZXMgaW4gZG93bi91cGxpbmssIHBlcmhhcHMgb2YgYSByYXRpbyBvZiAxMDoxLg0KPiBU aHVzLCBkb3dubG9hZGluZyBpcyBub3QgdHlwaWNhbGx5IHRoZSBwZXJmb3JtYW5jZSBib3R0bGVu ZWNrLiBQZXJoYXBzIEkNCj4gYW0gd3JvbmcgaW4gdGhpbmtpbmcgb2YgdGhpcyBhcyBhIHByZW1h dHVyZSBvcHRpbWl6YXRpb24gdGhvdWdoLiBDYW4geW91DQo+IHByb3ZpZGUgZXhhbXBsZXMgZnJv bSBleGlzaXRpbmcgYXBwcyB0aGF0IGZvbGxvdyB0aGlzIHByb3Bvc2FsIChhbmQgaG93DQo+IGRv IHRoZXkgaGFuZGxlIGVycm9yIGNhc2VzKT8gDQo+IA0KPiBNb3Jlb3ZlciwgdXNpbmcgU0hPVUxE IGZvciBzdWNoIGEgb3B0aW1pemF0aW9uIG1heSBub3QgYmUgYSBnb29kIGlkZWEgaW4NCj4gdGhl IGdlbmVyYWwgY2FzZS4NCj4gDQo+IA0KPiA3KSBGaWd1cmUgMzoNCj4gVGhpcyBmaWd1cmUgaW1w bGllcyB0aGF0IG11bHRpcGxlIGFwcGxpY2F0aW9ucyB3aWxsIG5lZWQgdG8gaW1wbGVtZW50DQo+ IHRoZWlyIG93biBERUNBREUgY2xpZW50LCB3aGljaCBjYW5ub3QgYmUgc2hhcmVkIGF0IHJ1biB0 aW1lIHdpdGggb3RoZXINCj4gYXBwcy4gT2YgY291cnNlIG9uZSBjb3VsZCBzZWUgdGhpcyBhcyBp bmNsdWRpbmcvbGlua2luZyB0byBhIGxpYnJhcnksDQo+IGJ1dCBwZXJoYXBzIGEgbW9yZSBmbGV4 aWJsZSBpbXBsZW1lbnRhdGlvbiBjb3VsZCBhbHNvIGJlIHRob3VnaHQgb2YsDQo+IGJhc2VkLCBm b3IgZXhhbXBsZSwgb24gYSBERUNBREUgInBsYXRmb3JtIiwgc2hhcmVkIGJ5IG1hbnkgYXBwcyBh dCBydW4NCj4gdGltZS4NCj4gDQo+IA0KPiA4KSBTZWN0aW9uIDYuMS4yLCBzZWNvbmQgdG8gbGFz dCBwYXJhZ3JhcGg6DQo+IFRoaXMgcHJvcG9zZWQgb3B0aW1pemF0aW9uIG5lZWQgbm90IGJlIHBh cnQgb2YgdGhlICJhcmNoaXRlY3R1cmUiDQo+IA0KPiANCj4gOSkgU2VjdGlvbiA2LjEuMzoNCj4g V291bGRuJ3QgaXQgYmUgYmV0dGVyIHRvIHNraXAgdGhpcyBzZWN0aW9uIGFsdG9nZXRoZXIgYW5k IGNvbnNpZGVyIGFuIElEDQo+IG9uIG1hbmFnZW1lbnQgYXNwZWN0cyBpbnN0ZWFkPyBGb3IgZXhh bXBsZSwgd2h5IG5vdCBzaW1wbHkgZGVmaW5lIGFuIE1JQg0KPiBmb3IgREVDQURFIGFuZCB1c2Ug ZXhpc3RpbmcgbWV0aG9kcyB0byBvYnRhaW4gdGhpcyBzdGF0dXMgaW5mbz8gV2h5IGFkZA0KPiBt b3JlIGNvbXBsZXhpdHkgaW4gRFJQIGltcGxlbWVudGF0aW9ucz8NCj4gDQo+IA0KPiAxMCkgU2Vj dGlvbiAxMC4yOg0KPiBodHRwOi8vZHguZG9pLm9yZy8xMC4xMTQ1LzE1NDQwMTIuMTU0NDA3OCBz aG91bGQgYWxzbyBiZSBhZGRlZCBoZXJlLCBhcw0KPiBpdCBtb3RpdmF0ZXMgd2VsbCB0aGUgZG9t YWluIGNvbnNpZGVyZWQgaW4gdGhpcyBhcmNoaXRlY3R1cmUsIGluY2x1ZGluZw0KPiB0aGUgRE8u DQo+IA0KPiANCj4gMTEpIFZhcmlvdXMgZWRpdG9yaWFsIGFuZCBncmFtbWF0aWNhbCBmaXhlcyAo d2hpY2ggd2VyZSBwcm92aWRlZCB0byB0aGUNCj4gYXV0aG9ycyBvZmYgbGluZSkuDQo+IA0KPiAN Cj4gTWFueSB0aGFua3MgdG8gS29zdGFzIGZvciBwcm92aWRpbmcgdGhlc2UgZXhjZWxsZW50IGNv bW1lbnRzLg0KPiANCj4gDQo+IEFrYmFyDQo+IA0KPiANCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCj4gRnJvbTogZGVjYWRlLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpkZWNhZGUtYm91 bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmDQo+IE9mIFNvbmdoYWliaW4NCj4gU2VudDogV2VkbmVz ZGF5LCBKdW5lIDIwLCAyMDEyIDEwOjA2IFBNDQo+IFRvOiBkZWNhZGVAaWV0Zi5vcmcNCj4gU3Vi amVjdDogW2RlY2FkZV0gV29ya2luZyBHcm91cCBMYXN0IENhbGw6IGRyYWZ0LWlldGYtZGVjYWRl LWFyY2gtMDcNCj4gDQo+IERlYXIgZm9sa3MsDQo+IA0KPiBBZnRlciB0aGUgZmlyc3Qgcm91bmQg b2YgdGhlIGxhc3QgY2FsbCwgdGhlIGFyY2hpdGVjdHVyZSBkb2N1bWVudCBoYXMNCj4gbWFueSBj aGFuZ2VzIHRvIHJlc29sdmUgY29tbWVudHMgZnJvbSByZXZpZXdlcnMgYXMgd2VsbCBhcyBhcmVh IGRpcmVjdG9yDQo+IGFuZCBleHBlcnRzIGZyb20gb3RoZXIgYXJlYXMuIFRoYW5rcyB0byB0aGUg cmV2aWV3ZXJzIGFuZCB0aGUgYXV0aG9ycy4NCj4gDQo+IFNvIFJpY2ggYW5kIEkgbm93IHN0YXJ0 IGFub3RoZXIgcm91bmQgb2YgV0dMQyBvbg0KPiBkcmFmdC1pZXRmLWRlY2FkZS1hcmNoLTA3LCBl bmRpbmcgRnJpZGF5LCBKdWx5IDZ0aC4gUGxlYXNlIHJldmlldyB0aGUNCj4gZG9jdW1lbnQgYW5k IHJlcGx5IHdpdGggeW91ciBjb21tZW50cy4NCj4gDQo+IFRoYW5rcywNCj4gDQo+IC1IYWliaW4g YW5kIFJpY2ggKGNvLWNoYWlycykNCj4g ------=_001_NextPart431821146361_=---- Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Stephen,
 
I agree with you, and suggest that this=20 optimization should not appear in -arch document, since it is too detailed= , and=20 may raise more concerns than it solves. Or we can use MAY instead of SHOUL= D to=20 indicate that this is a optional feature that are preferable, and state cl= early=20 the issues that may arise (i.e., how to deal with client abortion). How=20 would others think? Thanks.
 
B,
 
Peng.
 
 
 
Date: 2012-07-06 05:52
CC: Rahm= an,=20 Akbar; DECADE@ietf.org; Konstantinos Pentikousis
Subject: Re: [decade] Working Group Last Call:=20 draft-ietf-decade-arch-07
 
I'm not sure if designing optimisations = ;is best done
when considering requirements. It sounds lik= e something
liable to lead to premature optimisation.
 
On 07/06/2012 02:15 AM, Zhang Peng wrot= e:
> Hi,
> 
> As for the comment (6) regarding&n= bsp;optimization about naming, I think we ne= ed further discussion.
> 
> The question is that whether the&n= bsp;name SHOULD be generated and returned to=  the client before commitment to the up= loading.
> 
> First, we should evaluate the gain=  by using this what i term as "ear= ly name generation". Consider that a client&= nbsp;A is uploading a object F to DECAD= E server D, and another client B needs&= nbsp;to download it from D. Below is th= e stages to be taken without considering&nbs= p;authentication, and access control. 
> 
> 1. A sends upload request to = D, which responses with a permission
> 2. A uploads F to D
> 3. D returns the object name = to A
> 4. A advertises the object 
> 5. B knows the file name and&= nbsp;request the object from D
> 6. D sends the object to B
> 
> Here 1,3,4,5 may cost constant sma= ll amount of time, while 2,6, depend on=  the size of object and tend to co= st more time. The benefit of putting 3&= nbsp;before 2 is that 4 and 5 can = be carried out in parallel with 2. Thus=  it seems that we can just save th= e time of 4 and 5 in this process.=  But considering that B is in different=  locations, and using another DECADE sever&n= bsp;E, then we can also save the time&n= bsp;for E request the object from D. In=  addition, It may also take more time&n= bsp;if we consider the case that A shou= ld advertise to a lot of interested rec= eivers, which may consume more time. Without=  this non-quantitative analysis, it seems th= at it can benefits the live applications&nbs= p;to reduce the latency. But the benefits&nb= sp;are not so clear, and may depend on&= nbsp;applications. 
 
Putting "3 before 2" wouldn't be the&nb= sp;only option though.
For example, A could upload Hash(F) whi= ch might be used in
generating the object name at step 1.&n= bsp;There are many ways
to do things, setting up requirements t= hat things be done
in one way seems like a bad plan&n= bsp;to me.
 
S.
 
> If we would include this in -= arch as a design requirements, we need = to handle some erroneous situations, just as=  mentioned by Kostas. When the client a= dvertises a object, but does not upload = ;or finish the uploading, the DECADE server,=  however, may have already grant the ob= ject or send the part of the object&nbs= p;to some receiver. Then the server should&n= bsp;just sends a error signal to the gr= anted receivers, or let the receivers timeou= t themselves, and delete the object. Retrans= mission may or may not happen, depending&nbs= p;on the application implementation.  
> 
> I am still not quite sure whe= ther the potential benefits of this optimiza= tion worth the complication it brings. More&= nbsp;discussion may be needed. Thanks.
> 
> B,
> 
> Peng.
> 
> 
> From: Rahman, Akbar
> Date: 2012-07-05 01:21
> To: decade@ietf.org
> CC: Konstantinos Pentikousis
> Subject: Re: [decade] Working Group&nbs= p;Last Call: draft-ietf-decade-arch-07
> Hi,
> 
> 
> The DECADE Architecture authors were&nb= sp;contacted off list by Kostas who
> provided the following relevant and&nbs= p;useful comments on the
> draft-ietf-decade-arch-07.  We intend t= o address these comments in the
> next revision of the architecture = I-D after the WGLC ends.  
> 
> 1) Figure 1: 
> This figure and the accompanying t= ext (as-is right now) leaves quite
> some room for interpretation. For = example,  two distinct
> "DECADE-compatible" systems deployed by = ;two different operators may have
> DRP1 vs. DPR2, in addition to = ;having multiple SDTxyz's. Is this what you<= /DIV>
> have in mind?
> 
> 
> 2) Section 4.2, Referring to the&n= bsp;word "multipath":  
> I think you mean multi-source here= ? Multipath is mostly related with two
> (multihomed) end nodes and routing = ;in the network rather than one node
> getting bits and pieces of a = data object from different sources (as in
> P2P). You can still have multipath=  and single-source.
> 
> 
> 3) Section 4.2, third paragraph, f= irst sentence:
> As per the sec. 2.8, a "data&= nbsp;object is a string of raw bytes".
> Therefore, in this sentence we nee= d s/SHOULD/MUST.
> 
> 
> 4) Section 4.2, third paragraph, s= econd sentence:
> This may introduce the issue of&nb= sp;MDO discovery (max data object), when
> one connects to different DECADE S= ervers, perhaps along the lines of MTU
> discovery. Content resegmentation is no= t covered in this section, esp.
> since a DECADE server may store/ma= intain DOs from completely different
> apps.
> 
> 
> 5) Section 4.2, last paragraph:
> The introduction of the "block" ma= y be redundant here. A block is,
> similarly to a DO, "a string = of raw bytes", isn't it? If not, we&nbs= p;need a
> formal definition for it. Of cours= e, the key aspect here is what can = ;you
> name and locate in a DECADE S= erver, and my reading of the ID so = ;far is
> that you have settled on the = use of the DO, irrespective of the
> application semantics. The repeated use=  of "block" here and there simply
> confuses the uninitiated reader.
> 
> 
> 6) Section 4.4, 2nd to last p= aragraph:
> I think the optimization described = ;in this paragraph is not particularly
> suited for the Architecture document.&n= bsp;And it opens up all kinds of
> questions.  E.G. what if the = host advertizing an object crashes before
> it uploads the object? What if&nbs= p;the host changes its mind during the
> upload? Since we're talking about = immutable objects, shouldn't we wait
> until an object is "committed". In=  the end, this optimization could be
> counter-productive in these cases. Let&= nbsp;alone the fact that the scenarios
> for which DECADE is envisaged (and=  motivated from I would add) tend to
> have asymmetric capacities in down/upli= nk, perhaps of a ratio of 10:1.
> Thus, downloading is not typically = ;the performance bottleneck. Perhaps I
> am wrong in thinking of this = as a premature optimization though. Can you<= /DIV>
> provide examples from exisiting apps&nb= sp;that follow this proposal (and how
> do they handle error cases)? 
> 
> Moreover, using SHOULD for such a&= nbsp;optimization may not be a good idea&nbs= p;in
> the general case.
> 
> 
> 7) Figure 3:
> This figure implies that multiple = applications will need to implement
> their own DECADE client, which can= not be shared at run time with other
> apps. Of course one could see = ;this as including/linking to a library,
> but perhaps a more flexible implem= entation could also be thought of,
> based, for example, on a DECADE&nb= sp;"platform", shared by many apps at run
> time.
> 
> 
> 8) Section 6.1.2, second to last&n= bsp;paragraph:
> This proposed optimization need not&nbs= p;be part of the "architecture"
> 
> 
> 9) Section 6.1.3:
> Wouldn't it be better to skip = ;this section altogether and consider an ID<= /DIV>
> on management aspects instead? For = ;example, why not simply define an MIB
> for DECADE and use existing method= s to obtain this status info? Why add
> more complexity in DRP implementations?=
> 
> 
> 10) Section 10.2:
> http://dx.doi.org/10.1145/1544012.1544078 should = also be added here, as
> it motivates well the domain consi= dered in this architecture, including
> the DO.
> 
> 
> 11) Various editorial and grammatical&n= bsp;fixes (which were provided to the
> authors off line).
> 
> 
> Many thanks to Kostas for providin= g these excellent comments.
> 
> 
> Akbar
> 
> 
> -----Original Message-----
> From: decade-bounces@ietf.org [mailto:decade-boun= ces@ietf.org] On Behalf
> Of Songhaibin
> Sent: Wednesday, June 20, 2012 10:= 06 PM
> To: decade@ietf.org
> Subject: [decade] Working Group Last&nb= sp;Call: draft-ietf-decade-arch-07
> 
> Dear folks,
> 
> After the first round of the = last call, the architecture document has
> many changes to resolve comments f= rom reviewers as well as area director
> and experts from other areas. Than= ks to the reviewers and the authors.
> 
> So Rich and I now start anoth= er round of WGLC on
> draft-ietf-decade-arch-07, ending Friday, Ju= ly 6th. Please review the
> document and reply with your comme= nts.
> 
> Thanks,
> 
> -Haibin and Rich (co-chairs)
> 
 
------=_001_NextPart431821146361_=------ From pzhang.thu@gmail.com Fri Jul 6 19:34:56 2012 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 E73F611E808C for ; Fri, 6 Jul 2012 19:34:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.939 X-Spam-Level: X-Spam-Status: No, score=-0.939 tagged_above=-999 required=5 tests=[AWL=0.306, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_63=0.6, MIME_BASE64_TEXT=1.753, 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 07RtD9d7Utue for ; Fri, 6 Jul 2012 19:34:55 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id AA02911E8072 for ; Fri, 6 Jul 2012 19:34:54 -0700 (PDT) Received: by qcac10 with SMTP id c10so5309679qca.31 for ; Fri, 06 Jul 2012 19:35:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:reply-to:subject:references:x-priority:x-guid :x-mailer:mime-version:message-id:content-type; bh=W+WEejoANgfzm1IQI9Y7rScPlqPK+Yn+CjASTe9w1P0=; b=Kj3FNVpezQ7mbHECSL2XMUBuDtVMTU9fFWtIW7natSd8kOFtYuPQ5937pWe/Cw10rH h4yPrNPiZUdCyDRub/Z1O3jlMgaihQqSEtz1BAxH2EmkiGp5/hg9+LdpjRTpyr0BlWj6 limW3iQQXv+vgnWfi3Fs4JY292rYgpY+cr9PcD8jkaYccOPT8GxC9wBrOn/d7Ukk0y5f C8ZbD8HHp5T209dsDOP4/7j0sdh33KL2Xy2AO13GSPxW3Kxs8TGxiUNtiRdGjBk95+I0 88AI1RB56HyyBtvn09N/qCJOD4ffzwuGeXjebc58CsNN8Y56KM3pyr0aUW6dYgsEOzxc rrqw== Received: by 10.229.137.147 with SMTP id w19mr12782520qct.44.1341628512212; Fri, 06 Jul 2012 19:35:12 -0700 (PDT) Received: from pzhang-PC (dhcp-130-132-249-182.central.yale.edu. [130.132.249.182]) by mx.google.com with ESMTPS id gb7sm52665778qab.12.2012.07.06.19.35.10 (version=SSLv3 cipher=OTHER); Fri, 06 Jul 2012 19:35:11 -0700 (PDT) Date: Fri, 6 Jul 2012 22:35:08 -0400 From: "Zhang Peng" To: "Stephen Farrell" References: <20120703003402663560214@gmail.com>, <4FF2ACC3.1020004@cs.tcd.ie> <20120704160541638826251@gmail.com>, <4FF4B0D5.40906@cs.tcd.ie> <20120704174022735010267@gmail.com>, <4FF4B8C2.7090702@cs.tcd.ie> <20120704175739679926274@gmail.com>, <4FF4BD39.7050907@cs.tcd.ie> X-Priority: 3 X-GUID: AF65F12C-793F-47F7-AEC2-5D482D015B83 X-Mailer: Foxmail 7.0.1.81[cn] Mime-Version: 1.0 Message-ID: <20120706223508854218405@gmail.com> Content-Type: multipart/alternative; boundary="----=_001_NextPart877674171020_=----" Cc: "DECADE@ietf.org" Subject: Re: [decade] Object naming in -req and -arch X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "pzhang.thu" 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, 07 Jul 2012 02:34:57 -0000 This is a multi-part message in MIME format. ------=_001_NextPart877674171020_=---- Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 V2l0aG91dCBjb25zaWRlcmluZyB0aGUgb3B0aW1pemF0aW9uIG9mIG5hbWluZyAoaS5lLiwgbGV0 dGluZyBhcHBsaWNhdGlvbnMga25vdyB0aGUgb2JqZWN0IG5hbWUgYmVmb3JlIGNvbW1pdG1lbnQg b2YgdXBsb2FkaW5nKSwgSSB0aGluayB0aGUgaGFzaC1iYXNlZCB5b3UgcHJvcG9zZWQgaXMgZ29v ZCBlbm91Z2ggZm9yIHRoZSByZXF1aXJlbWVudHMgKGkuZS4sIHVuaXF1ZW5lc3MsIGFuZCBvYmpl Y3QtaWQgYmluZGluZykuIE9uZSBwcm9ibGVtLCB3aGljaCBpcyBhbHNvIGNyaXRpY2l6ZWQgaW4g Q29udGVudC1DZW50cmljIE5ldHdvcmtpbmcsIGlzIHRoYXQgc3VjaCBmbGF0IG5hbWVzIGFyZSBu b3QgaHVtYW4tcmVhZGFibGUsIGFuZCBhcmUgbm90IHN1aXRhYmxlIGZvciBhZ2dyZWdhdGlvbnMu ICBUaGVyZSBzaG91bGQgYmUgYSBtYXBwaW5nIGZyb20gbWVhbmluZ2Z1bCBuYW1lcyB0byB0aGVt LiBXZSBjYW4gbGVhdmUgdGhpcyBwYXJ0IHRvIGFwcGxpY2F0aW9ucy4NCg0KT24gdGhlIG90aGVy IGhhbmQsIGlmIHdlIGFyZSBlbmNvdXJhZ2luZyB0aGUgb3B0aW1pemF0aW9uLCB3ZSBzaG91bGQg bW9yZSBzb3BoaXN0aWNhdGVkIG5hbWluZyBzY2hlbWVzLiBTaW5jZSB3ZSB3b3VsZCBsaWtlIHRv IGdpdmUgdGhlIG5hbWUgZm9yIHRoZSBvYmplY3QgdGhhdCBpcyBub3QgZnVsbHkgdXBsb2FkZWQs IHRoZW4gd2Ugc2hvdWxkIHVzZSB0aGUgZm9sbG93aW5nIHNjaGVtZSBpbnNwaXJlZCBieSB0aGUg bmFtaW5nIHNjaGVtZXMgb2YgQ29udGVudC1DZW50cmljIE5ldHdvcmtpbmcuIA0KDQpXZSBhc3N1 bWUgdGhhdCB0aGUgdXBsb2FkaW5nIGNsaWVudCBvciBhIHB1Ymxpc2hlciBob2xkcyBhIHByaXZh dGUvcHVibGljIGtleSBwYWlyLg0KKDEpIFRoZSBvYmplY3QgbmFtZSBpcyBhIHRoZSBoYXNoIG9m IHRoZSBwdWJsaWMga2V5IG9mIHRoZSB1cGxvYWRpbmcgY2xpZW50LCB0b2dldGhlciB3aXRoIHRo ZSBsb2NhbGx5IHVuaXF1ZSBpZGVudGlmaWVyIGFzc2lnbmVkIHRvIHRoZSBvYmplY3QuDQooMikg VGhlIG9iamVjdCBjb250ZW50IGFuZCB0aGUgbmFtZSBhcmUgc2lnbmVkIHRvZ2V0aGVyIHVzaW5n IHRoZSBwcml2YXRlIGtleSBvZiB0aGUgdXBsb2FkaW5nIGNsaWVudC4gDQooMykgU29tZSBpbmZv cm1hdGlvbiBhYm91dCB0aGUgbG9jYXRpb24gb2YgdGhlIGtleSBtYXkgYmUgaW5jbHVkZWQgaW4g dGhlIG9iamVjdCwgc28gdGhhdCBhIGNsaWVudCB0aGF0IHJlcXVlc3RzIHRoZSBvYmplY3QgY2Fu IHJldHJpZXZlIHRoZSBwdWJsaWMga2V5IHRvIHZlcmlmeSB0aGUgbmFtZS1vYmplY3QgYmluZGlu Zy4NCg0KcmVmOiAgWzFdIE5hbWluZyBpbiBDb250ZW50LU9yaWVudGVkIEFyY2hpdGVjdHVyZXMs IElDTjExDQpbMl0gTmV0d29ya2luZyBOYW1lZCBDb250ZW50LCBDb25leHQwOQ0KDQoNCkIsDQoN ClBlbmcuDQoNCkZyb206IFN0ZXBoZW4gRmFycmVsbA0KRGF0ZTogMjAxMi0wNy0wNCAxODowMQ0K VG86IHB6aGFuZy50aHUNCkNDOiBERUNBREVAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbZGVjYWRl XSBPYmplY3QgbmFtaW5nIGluIC1yZXEgYW5kIC1hcmNoDQoNCg0KT24gMDcvMDQvMjAxMiAxMDo1 NyBQTSwgWmhhbmcgUGVuZyB3cm90ZToNCj4gT2ssIGl0IHNlZW1zIHRvIHdvcmsuIEJ1dCBpdCBq dXN0IGluY2x1ZGVzIHRoZSBoYXNoIG9mIHB1YmxpYyBrZXkuIEhvdyB0byBuYW1lIGEgc2VxdWVu Y2Ugb2YgZHluYW1pYyBuYW1lcz8gRm9yIGV4YW1wbGUsIHRoZSBzdHJlYW0gaXMgZGl2aWRlZCBp bnRvIG9iamVjdCBieSBzZWNvbmRzOiAxcywgMnMsIDNzLC4uLj8gDQoNClNvbWUgd29yayBUQkQ6 LSkNCg0KSSBzdXNwZWN0IHRoYXQgdGhlIGRldGFpbHMgd2lsbCBuZWVkIHdvcmsgaW4gdGhlIGRl Y2FkZSBXRy4NCg0KSSdtIGNvbmZpZGVudCB0aGF0IG9uY2Ugd2Uga25vdyB3ZSBjYW4gaGFuZGxl IGR5bmFtaWMNCmNvbnRlbnQgYXMgaW4gZHJhZnQtaGFsbGFtYmFrZXIsIHRoZW4gd2UgY2FuIHVz ZSB0aGUgc2FtZQ0KYXBwcm9hY2ggZm9yIHdoYXRldmVyIGRlY2FkZS1zcGVjaWZpY3MgYXJlIG5l ZWRlZCBsYXRlci4NCg0KSW4gdGhlIGNhc2UgeW91IG1lbnRpb24sIG1heWJlIGEgY2hhaW4gb2Yg bmkgVVJJcyBtaWdodA0KYmUgbmVlZGVkIGluY2x1ZGVkIGFzIHNvbWUgZGVjYWRlIG1ldGFkYXRh IHdpdGggZWFjaA0KMXMgY2h1bmsgYW5kIHBlcmhhcHMgZ2l2aW5nIHRoZSBuYW1lIG9mIHRoZSBu ZXh0IGNodW5rLg0KQnV0IEkgc3VzcGVjdCB5b3UndmUgZ29uZSBiZXlvbmQgbmFtaW5nIHJlcXVp cmVtZW50cw0Kd2hlbiB5b3Ugc3RhcnQgdG8gY29uc2lkZXIgc2V0cyBvZiByZWxhdGVkIChwYXJ0 cyBvZikNCm9iamVjdHMuDQoNClMuDQoNCj4gQiwNCj4gDQo+IFBlbmcuDQo+IEZyb206IFN0ZXBo ZW4gRmFycmVsbA0KPiBEYXRlOiAyMDEyLTA3LTA0IDE3OjQyDQo+IFRvOiBwemhhbmcudGh1DQo+ IENDOiBERUNBREVAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFtkZWNhZGVdIE9iamVjdCBuYW1p bmcgaW4gLXJlcSBhbmQgLWFyY2gNCj4gDQo+IA0KPiBPbiAwNy8wNC8yMDEyIDEwOjQwIFBNLCBa aGFuZyBQZW5nIHdyb3RlOg0KPj4gSGkgU3RlcGhlbiwNCj4+DQo+PiBZZXMsIGZvciBtb3N0IGNh c2VzLCBoYXNoLWJhc2VkIG5hbWluZyBzY2hlbWUgaXMgb2sgZm9yIGluLW5ldHdvcmsgc3RvcmFn ZSBzeXN0ZW0gd2hpY2ggaG9sZHMgaW1tdXRhYmxlIG9iamVjdHMuIA0KPj4gQnVyIGZvciBzb21l IGFwcGxpY2F0aW9uIHN1Y2ggYXMgbGl2ZSBzdHJlYW1pbmcsIHdlIGV4cGVjdCB0aGF0IHRoZSB1 cGxvYWRlci9zdHJlYW1lciBjYW4ga25vdyB0aGUgb2JqZWN0IG5hbWUgYmVmb3JlIGl0IHVwbG9h ZHMgdGhlIG9iamVjdCB0byBkZWNhZGUgc2VydmVyLiBUaGlzIHdpbGwgYWxsb3cgdGhlIHN0cmVh bWVyIHRvIGFkdmVydGlzZSB0aGUgZmlsZSBiZWZvcmUgZnVsbHkgdXBsb2FkaW5nIGl0LCBhbmQg dGhlbiB0aGUgdmlld2VyIGNhbiBmZXRjaCB0aGUgb2JqZWN0IHVzaW5nIHRoZSBhZHZlcnRpc2Vk IG5hbWUuIElmIGVhY2ggb2JqZWN0IGNvbnRhaW5zIHNldmVyYWwgc2Vjb25kcyBvZiB2aWRlbyBk YXRhLCB0aGlzIGZlYXR1cmUgY2FuIGNvbnNpZGVyYWJseSByZWR1Y2UgdGhlIGxhdGVuY3kuIFRo dXMsIHdlIG1heSBuZWVkIGEgZW51bWVyYXRpb24tYmFzZWQgc2NoZW1lIGJlc2lkZXMgdGhlIGhh c2gtYmFzZWQgb25lLiBDYW4gd2UgYWRkIHRoaXMgZmVhdHVyZSBpbiB5b3VyIHByb3Bvc2VkIGRl c2lnbj8gVGhhbmtzLg0KPiANCj4gQWggZ290Y2hhLiBZZXMgdGhlcmUgYXJlIHdheXMsIGJhc2lj YWxseSBieSBkZWZpbmluZyBhIG5ldw0KPiBoYXNoIGFsZyBhbmQgdXNpbmcgYSBzaWduYXR1cmUu IFRoZXJlJ3Mgb25lIGRvY3VtZW50ZWQgaW4NCj4gZHJhZnQtaGFsbGFtYmFrZXItZGVjYWRlLW5p LXBhcmFtcyBbMV0gc2VjdGlvbiAyLjEuDQo+IA0KPiBDaGVlcnMsDQo+IFMuDQo+IA0KPiBbMV0g aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaGFsbGFtYmFrZXItZGVjYWRlLW5pLXBh cmFtcy0wMw0KPiANCj4+IEIsDQo+Pg0KPj4gUGVuZy4NCj4+DQo+PiBGcm9tOiBTdGVwaGVuIEZh cnJlbGwNCj4+IERhdGU6IDIwMTItMDctMDQgMTc6MDgNCj4+IFRvOiBwemhhbmcudGh1DQo+PiBD QzogREVDQURFQGlldGYub3JnDQo+PiBTdWJqZWN0OiBSZTogW2RlY2FkZV0gT2JqZWN0IG5hbWlu ZyBpbiAtcmVxIGFuZCAtYXJjaA0KPj4NCj4+DQo+PiBPbiAwNy8wNC8yMDEyIDA5OjA1IFBNLCBa aGFuZyBQZW5nIHdyb3RlOg0KPj4+IEhpIFN0ZXBoZW4sDQo+Pj4NCj4+PiBJIGhhdmUgcmVhZCB5 b3VyIGRvY3VtZW50cyBvbiBoYXNoLWJhc2VkIG5hbWluZy4gSXQgZGVzaWducyBhIGdvb2QgVVJJ IGZvcm1hdCBhbmQgbWFwcGluZyBzY2hlbWUgdG8gSFRUUCBVUkwuIEZvciBERUNBREUsIHNpbmNl IG91ciByZXF1aXJlbWVudHMgaW5jbHVkZSB1bmlxdWVuZXNzLCBuYW1lLW9iamVjdCBiaW5kaW5n IHZhbGlkYXRpb24sIEkgd29uZGVyIGhvdyB3ZSBjYW4gYXBwbHkgeW91ciBzY2hlbWUgdG8gbWVl dCB0aGVtLiANCj4+DQo+PiBuaSBVUklzIGFyZSBhcyB1bmlxdWUgYXMgdGhlIGNvbGxpc2lvbiBy ZXNpc3RhbmNlIG9mIHlvdXIgaGFzaA0KPj4gZnVuY3Rpb24gc3VwcG9ydHMgYmFzaWNhbGx5LiBJ ZiB5b3UgcGljayBzaGEtMjU2IHRoYXQgd29uJ3QgYmUNCj4+IGFuIGlzc3VlLg0KPj4NCj4+IG5p IFVSaXMgc3VwcG9ydCBuYW1lLWRhdGEgaW50ZWdyaXR5IChpbmNsLiBpbiB0aGUgY29kZSB3ZSd2 ZQ0KPj4gcmVsZWFzZWQpIHdoaWNoIEkgdGhpbmsgaXMgdGhlIHNhbWUgYXMgd2hhdCB5b3UncmUg Y2FsbGluZw0KPj4gbmFtZS1vYmplY3QgYmluZGluZyB2YWxpZGF0aW9uLg0KPj4NCj4+IFNvIG15 IGFuc3dlciBmb3IgYm90aCBpczoganVzdCB1c2UgbmkgVVJJcyB0byBtZWV0IHRoZXNlDQo+PiBy ZXF1aXJlbWVudHM6LSkNCj4+DQo+Pj4gQlRXLCBjYW4geW91IGdpdmUgbW9yZSBkZXRhaWxzIG9u IHdoYXQgeW91IG1lYW4gYnkgIm1lZXRzIHRoZXNlIHJlcXVpcmVtZW50cyI/IFRoYW5rcy4NCj4+ DQo+PiBJIG1lYW50OiBpZiB0aGVyZSdzIHNvbWUgcmVxdWlyZW1lbnQgdGhhdCBjYW4ndCBiZSBt ZXQgdXNpbmcgbmkgVVJJcywNCj4+IHRoZW4gSSdkIGxpa2UgdG8ga25vdyBhYm91dCB0aGF0IGJl Zm9yZSBpdHMgdG9vIGxhdGUuIChJIHJlYWxpc2UNCj4+IHRoYXQgdGhlIGRlY2FkZSBXRyBtaWdo dCBzdGlsbCBjaGFuZ2UgcmVxcyBvZiBjb3Vyc2UgYnV0IHdhbnRlZCB0bw0KPj4gY2hlY2sgbm93 IGJlZm9yZSB3ZSdyZSBkb25lIHdpdGggb3VyIGRvYy4pDQo+Pg0KPj4gUw0KPj4NCj4+PiBCLA0K Pj4+DQo+Pj4gUGVuZy4NCj4+Pg0KPj4+IEZyb206IFN0ZXBoZW4gRmFycmVsbA0KPj4+IERhdGU6 IDIwMTItMDctMDMgMDM6MjYNCj4+PiBUbzogcHpoYW5nLnRodQ0KPj4+IENDOiBERUNBREVAaWV0 Zi5vcmcNCj4+PiBTdWJqZWN0OiBSZTogW2RlY2FkZV0gT2JqZWN0IG5hbWluZyBpbiAtcmVxIGFu ZCAtYXJjaA0KPj4+DQo+Pj4gSGl5YSwNCj4+Pg0KPj4+IEkgZ3Vlc3MgSSBob3BlIHRoYXQgb3Vy IGRyYWZ0IChqdXN0IGV4aXRlZCBJRVRGIExDKSBtZWV0cw0KPj4+IHRoZXNlIHJlcXVpcmVtZW50 cy4gSWYgbm90LCBJJ2QgYmUgaW50ZXJlc3RlZCBpbiB3aGF0J3MNCj4+PiBtaXNzaW5nLg0KPj4+ DQo+Pj4gQ2hlZXJzLA0KPj4+IFMuDQo+Pj4NCj4+PiBbMV0gaHR0cDovL3Rvb2xzLmlldGYub3Jn L2h0bWwvZHJhZnQtZmFycmVsbC1kZWNhZGUtbmkNCj4+Pg0KPj4+IE9uIDA3LzAzLzIwMTIgMDY6 MzQgQU0sIFpoYW5nIFBlbmcgd3JvdGU6DQo+Pj4+IERlYXIgREVDQURFIHBhcnRpY2lwYW50cywN Cj4+Pj4NCj4+Pj4gQXMgcG9pbnRlZCBvdXQgYnkgUmljaGFyZCBpbiBwcmV2aW91cyBkaXNjdXNz aW9ucywgYm90aCB0aGUgLXJlcSBhbmQgLWFyY2ggZG9jdW1lbnRzIGhhcyBzb21lIHBhcmFncmFw aHMgZGVzY3JpYmluZyBjb250ZW50IG5hbWluZywgYW5kIHRoZXkgbmVlZCBiZXR0ZXIgb3JnYW5p emF0aW9uOiBzb21lIGdlbmVyaWMgcmVxdWlyZW1lbnRzIHNob3VsZCBiZSBpbiAtcmVxLCB3aGls ZSBzb21lIG1vcmUgc3BlY2lmaWMgb25lcyBzaG91bGQgYmUgaW4gLWFyY2guIEhlcmUgYXJlIHNv bWUgc3VnZ2VzdGlvbnMgYWJvdXQgaG93IHRvIHNwbGl0IHRoZSBjb250ZW50IG9uIG5hbWluZyBp biB0aGVzZSB0d28gZG9jdW1lbnRzLiANCj4+Pj4NCj4+Pj4gVGhlIHJhdGlvbmFsZSBmb3IgdGhl IGZvbGxvd2luZyBzcGxpdCBpcyB0aGF0IEkgcmVjb2duaXplIHRoZXJlIGFyZSB0d28gZ2VuZXJp YyByZXF1aXJlbWVudHMsIHRoYXQgaXMsIHVuaXF1ZW5lc3MsIGFuZCBiaW5kaW5nIHZhbGlkYXRp b24uIFRoZXkgc2hvdWxkIGJlIHBsYWNlZCBpbiB0aGUgLXJlcS4gSW4gLWFyY2gsIHdlIHNob3Vs ZCBwcmVzZW50IHRoZSBzcGVjaWZpYyByZXF1aXJlbWVudHMgdG8gZW5hYmxlIHVuaXF1ZW5lc3Ms IGFuZCBiaW5kaW5nIHZhbGlkYXRpb24sIHJlc3BlY3RpdmVseS4gVGhlcmUgYXJlIGFsc28gc29t ZSBtb3JlIHJlcXVpcmVtZW50cyBvbiBob3cgdG8gaW1wcm92ZSB0aGUgcmVzcG9uc2l2ZW5lc3Mg b2YgdGhlIHN5c3RlbSwgaS5lLiwgdGhlIHN1cHBvcnQgb2YgZWFybHkgbmFtZSBnZW5lcmF0aW9u LiBTZWUgYmVsb3cgZm9yIGRldGFpbHMgKHJlZmVyZW5jZXMgdG8gdGhlIG9yaWdpbmFsIGRvY3Vt ZW50cyBhcmUgZ2l2ZW4gYWZ0ZXIgZWFjaCBzcGVjaWZpYyByZXF1aXJlbWVudHMpOg0KPj4+Pg0K Pj4+PiBHZW5lcmljIHJlcXVpcmVtZW50cyAodG8gYmUgcHV0IGluIC1yZXEpDQo+Pj4+DQo+Pj4+ IDEuIEl0IFNIT1VMRCBlbnN1cmUgdGhhdCB1bmlxdWVuZXNzIG9mIG9iamVjdCBuYW1lcy4gDQo+ Pj4+IDIuIEl0IFNIT1VMRCBzdXBwb3J0IHRoZSB2YWxpZGF0aW9uIG9mIG5hbWUtb2JqZWN0IGJp bmRpbmcuDQo+Pj4+IDMuIEl0IFNIT1VMRCBzdXBwb3J0IHRoZSBvcGVyYXRpb24gb2YgREVDQURF LWNvbXBhdGlibGUgc2VydmVycyB1bmRlciBkaXZlcnNlIGFkbWluaXN0cmF0aXZlIGRvbWFpbnMg d2l0aCBubyBjb29yZGluYXRpb24uIChub3Qgc3VyZSBhYm91dCB3aGF0IG9wZXJhdGlvbnMgYXJl IG1lYW50IGhlcmUpDQo+Pj4+DQo+Pj4+IFNwZWNpZmljIHJlcXVpcmVtZW50cyAodG8gYmUgcHV0 IGluIC1hcmNoKQ0KPj4+Pg0KPj4+PiBSZXF1aXJlbWVudHMgdG8gZW5hYmxlIHVuaXF1ZW5lc3M6 IA0KPj4+PiAxLiBJdCBNQVkgZW5hYmxlIGFwcGxpY2F0aW9ucyB0byBjb25zdHJ1Y3QgdW5pcXVl IG5hbWVzIGJ5IHRoZW1zZWx2ZXMgd2l0aCBhIGhpZ2ggcHJvYmFiaWxpdHkgKHJlZjogbGFzdCBz ZW50ZW5jZSwgcHAuIDExLCAtYXJjaCkuIElmIHRoaXMgaXMgdGhlIGNhc2UsIGl0IFNIT1VMRCBp bmRpY2F0ZSBjb25mbGljdHMgd2hlbiBkdXBsaWNhdGUgbmFtZXMgYXJlIGNvbnN0cnVjdGVkIChy ZWY6IGZpcnN0IHBhcmEsIDQuNS4xLCAtcmVxKS4NCj4+Pj4gMi4gSXQgTUFZIHN1cHBvcnQgY29u dGVudC1kZXBlbmRlbnQgaGFzaC1iYXNlZCBzY2hlbWVzIChmb3IgZ2VuZXJhbCBpbW11dGFibGUg b2JqZWN0cyksIGFuZCBjb250ZW50LWluZGVwZW5kZW50IGVudW1lcmF0aW9uLWJhc2VkIHNjaGVt ZXMgKGZvciBsaXZlIHN0cmVhbWluZykgDQo+Pj4+IChyZWY6IDJuZCBwYXJhLCBwcC4gMTIsIC1h cmNoKQ0KPj4+Pg0KPj4+PiBSZXF1aXJlbWVudHMgdG8gZW5hYmxlIG5hbWUtb2JqZWN0IGJpbmRp bmcgdmFsaWRhdGlvbjoNCj4+Pj4gMy4gRGlmZmVyZW50IG5hbWUtb2JqZWN0IGJpbmRpbmcgdmFs aWRhdGlvbiBtZWNoYW5pc21zIE1BWSBiZSBzdXBwb3J0ZWQsIGFuZCBhbiBhcHBsaWNhdGlvbiBj YW4gZGVjaWRlIHdoaWNoIG1lY2hhbmlzbSB0byB1c2UuIChyZWY6IDJuZCBwYXJhLCA0LjQsIC1h cmNoKQ0KPj4+PiA0LiBOYW1lcyBNQVkgYmUgc2VsZi1kZXNjcmliaW5nIHNvIHRoYXQgYSByZWNl aXZpbmcgZW50aXR5IChDb250ZW50IENvbnN1bWVyKSBrbm93cyB3aGljaCBtZWNoYW5pc20gaXMg dXNlZCAocmVmOiAxc3QgcGFyYSwgcHAuIDEyLCAtYXJjaCkNCj4+Pj4gNS4gSXQgU0hPVUxEIHBy b3ZpZGUgdGhlIGZvbGxvd2luZyBuYW1lIGVsZW1lbnRzOiAoMSkgQSAidHlwZSIgZmllbGQsICgy KSBDcnlwdG9ncmFwaGljIGRhdGEsICgzKSBBcHBsaWNhdGlvbiBvciBwdWJsaXNoZXIgaW5mb3Jt YXRpb24uIChyZWY6IHBwLiAxMiwgLWFyY2gpDQo+Pj4+DQo+Pj4+IE1vcmUgcmVxdWlyZW1lbnRz IGFib3V0IHBlcmZvcm1hbmNlOg0KPj4+PiA2LiBJdCBTSE9VTEQgc3VwcG9ydCB0aGUgc2NlbmFy aW9zIHdoZXJlIGEgY2xpZW50IG5lZWRzIHRvIGtub3cgdGhlIG5hbWUgb2YgYSBkYXRhIG9iamVj dCBiZWZvcmUgaXQgaXMgY29tcGxldGVseSBzdG9yZWQgYXQgdGhlIHNlcnZlci4gKFRoaXMgaXMg dG8gbGV0IGNsaWVudHMgYWR2ZXJ0aXNlIHRoZSBvYmplY3QgYmVmb3JlIGhhdmluZyBmdWxseSB1 cGxvYWRlZCBpdCkgKHJlZjogc2Vjb25kIGxhc3QgcGFyYSwgcHAuIDEyLCAtYXJjaCkNCj4+Pj4g Ny4gSXQgU0hPVUxEIHN1cHBvcnQgdGhlIHNjZW5hcmlvcyB3aGVyZSBhIGNsaWVudCBuZWVkIHRv IGtub3cgdGhlIG5hbWUgb2YgYSBkYXRhIG9iamVjdCBiZWZvcmUgaXQgaXMgbG9jYWxseSBjcmVh dGVkLiAoVGhpcyBpcyB0byBzdXBwb3J0IGxpdmUgc3RyZWFtaW5nKSAocmVmOiBsYXN0IHBhcmEs IHBwLiAxMiwgLWFyY2gpDQo+Pj4+DQo+Pj4+IEFueSBjb21tZW50cyBhcmUgd2VsY29tZSwgdGhh bmtzLg0KPj4+Pg0KPj4+PiBQZW5nLg== ------=_001_NextPart877674171020_=---- Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Without considering the optimization of naming (i.e., letting applica= tions=20 know the object name before commitment of uploading), I think the=20 hash-based you proposed is good enough for the requirements (i.e., uniquen= ess,=20 and object-id binding). One problem, which is also criticized in=20 Content-Centric Networking, is that such flat names are not human-rea= dable,=20 and are not suitable for aggregations.  There should be a mappin= g from=20 meaningful names to them. We can leave this part to applications.
 
On the other hand, if we are encouraging the optimization, we should = more=20 sophisticated naming schemes. Since we would like to give the name for the= =20 object that is not fully uploaded, then we should use the following scheme= =20 inspired by the naming schemes of Content-Centric Networking.
 
We assume that the uploading client or a publisher holds a private/pu= blic=20 key pair.
(1) The object name is a the hash of the public key of the uploading=20 client, together with the locally unique identifier assigned to the=20 object.
(2) The object content and the name are signed together using th= e=20 private key of the uploading client.
(3) Some information about the location of the key may be included in= the=20 object, so that a client that requests the object can retrieve the public = key to=20 verify the name-object binding.
 
ref:  [1] Naming=20 in Content-Oriented Architectures, ICN11
[2] Net= working=20 Named Content, Conext09
 
 
B,
 
Peng.
 
Date: 2012-07-04 18:01
Subject: Re: [decade] Object naming in -req and=20 -arch
 
 
On 07/04/2012 10:57 PM, Zhang Peng wrot= e:
> Ok, it seems to work. But it&= nbsp;just includes the hash of public key.&n= bsp;How to name a sequence of dynamic n= ames? For example, the stream is divided&nbs= p;into object by seconds: 1s, 2s, 3s,...?&nb= sp;
 
Some work TBD:-)
 
I suspect that the details will need&nb= sp;work in the decade WG.
 
I'm confident that once we know we = ;can handle dynamic
content as in draft-hallambaker, then we&nbs= p;can use the same
approach for whatever decade-specifics are n= eeded later.
 
In the case you mention, maybe a c= hain of ni URIs might
be needed included as some decade metad= ata with each
1s chunk and perhaps giving the name&nb= sp;of the next chunk.
But I suspect you've gone beyond naming=  requirements
when you start to consider sets of = ;related (parts of)
objects.
 
S.
 
> B,
> 
> Peng.
> From: Stephen Farrell
> Date: 2012-07-04 17:42
> To: pzhang.thu
> CC: DECADE@ietf.org
> Subject: Re: [decade] Object naming&nbs= p;in -req and -arch
> 
> 
> On 07/04/2012 10:40 PM, Zhang Peng=  wrote:
>> Hi Stephen,
>>
>> Yes, for most cases, hash-based&nbs= p;naming scheme is ok for in-network storage=  system which holds immutable objects. 
>> Bur for some application such = as live streaming, we expect that the u= ploader/streamer can know the object name be= fore it uploads the object to decade se= rver. This will allow the streamer to a= dvertise the file before fully uploading it,=  and then the viewer can fetch the = ;object using the advertised name. If each&n= bsp;object contains several seconds of video = ;data, this feature can considerably reduce = the latency. Thus, we may need a enumer= ation-based scheme besides the hash-based one.&nb= sp;Can we add this feature in your prop= osed design? Thanks.
> 
> Ah gotcha. Yes there are ways,&nbs= p;basically by defining a new
> hash alg and using a signature.&nb= sp;There's one documented in
> draft-hallambaker-decade-ni-params [1] section&nb= sp;2.1.
> 
> Cheers,
> S.
> 
> [1] http://tools.ietf.org/html/draft-hallambaker-decad= e-ni-params-03
> 
>> B,
>>
>> Peng.
>>
>> From: Stephen Farrell
>> Date: 2012-07-04 17:08
>> To: pzhang.thu
>> CC: DECADE@ietf.org
>> Subject: Re: [decade] Object naming=  in -req and -arch
>>
>>
>> On 07/04/2012 09:05 PM, Zhang = Peng wrote:
>>> Hi Stephen,
>>>
>>> I have read your documents = ;on hash-based naming. It designs a good&nbs= p;URI format and mapping scheme to HTTP = ;URL. For DECADE, since our requirements inc= lude uniqueness, name-object binding validation, = I wonder how we can apply your scheme&n= bsp;to meet them. 
>>
>> ni URIs are as unique as = the collision resistance of your hash
>> function supports basically. If you=  pick sha-256 that won't be
>> an issue.
>>
>> ni URis support name-data integrity=  (incl. in the code we've
>> released) which I think is the=  same as what you're calling
>> name-object binding validation.
>>
>> So my answer for both is: = ;just use ni URIs to meet these
>> requirements:-)
>>
>>> BTW, can you give more det= ails on what you mean by "meets these&n= bsp;requirements"? Thanks.
>>
>> I meant: if there's some requi= rement that can't be met using ni URIs,=
>> then I'd like to know about&nb= sp;that before its too late. (I realise
>> that the decade WG might still=  change reqs of course but wanted to
>> check now before we're done wi= th our doc.)
>>
>> S
>>
>>> B,
>>>
>>> Peng.
>>>
>>> From: Stephen Farrell
>>> Date: 2012-07-03 03:26
>>> To: pzhang.thu
>>> CC: DECADE@ietf.org
>>> Subject: Re: [decade] Object na= ming in -req and -arch
>>>
>>> Hiya,
>>>
>>> I guess I hope that our&nb= sp;draft (just exited IETF LC) meets
>>> these requirements. If not, I'd=  be interested in what's
>>> missing.
>>>
>>> Cheers,
>>> S.
>>>
>>> [1] http://tools.ietf.org/html/draft-farrell-d= ecade-ni
>>>
>>> On 07/03/2012 06:34 AM, Zhang&n= bsp;Peng wrote:
>>>> Dear DECADE participants,
>>>>
>>>> As pointed out by Richard&n= bsp;in previous discussions, both the -req a= nd -arch documents has some paragraphs descr= ibing content naming, and they need better&n= bsp;organization: some generic requirements should&nbs= p;be in -req, while some more specific = ones should be in -arch. Here are some&= nbsp;suggestions about how to split the cont= ent on naming in these two documents. <= /DIV>
>>>>
>>>> The rationale for the follo= wing split is that I recognize there ar= e two generic requirements, that is, uniquen= ess, and binding validation. They should be&= nbsp;placed in the -req. In -arch, we s= hould present the specific requirements to e= nable uniqueness, and binding validation, respect= ively. There are also some more requirements=  on how to improve the responsiveness o= f the system, i.e., the support of earl= y name generation. See below for details&nbs= p;(references to the original documents are = given after each specific requirements):
>>>>
>>>> Generic requirements (to be = ;put in -req)
>>>>
>>>> 1. It SHOULD ensure that&nb= sp;uniqueness of object names. 
>>>> 2. It SHOULD support the&nb= sp;validation of name-object binding.
>>>> 3. It SHOULD support the&nb= sp;operation of DECADE-compatible servers under d= iverse administrative domains with no coordinatio= n. (not sure about what operations are = meant here)
>>>>
>>>> Specific requirements (to be&nbs= p;put in -arch)
>>>>
>>>> Requirements to enable uniquenes= s: 
>>>> 1. It MAY enable applicatio= ns to construct unique names by themselves&n= bsp;with a high probability (ref: last sente= nce, pp. 11, -arch). If this is the&nbs= p;case, it SHOULD indicate conflicts when du= plicate names are constructed (ref: first pa= ra, 4.5.1, -req).
>>>> 2. It MAY support content-d= ependent hash-based schemes (for general immutabl= e objects), and content-independent enumeration-based&= nbsp;schemes (for live streaming) 
>>>> (ref: 2nd para, pp. 12,&nbs= p;-arch)
>>>>
>>>> Requirements to enable name-obje= ct binding validation:
>>>> 3. Different name-object binding=  validation mechanisms MAY be supported, and=  an application can decide which mechanism&n= bsp;to use. (ref: 2nd para, 4.4, -arch)
>>>> 4. Names MAY be self-descri= bing so that a receiving entity (Content&nbs= p;Consumer) knows which mechanism is used (r= ef: 1st para, pp. 12, -arch)
>>>> 5. It SHOULD provide the&nb= sp;following name elements: (1) A "type" fie= ld, (2) Cryptographic data, (3) Application = or publisher information. (ref: pp. 12, -arc= h)
>>>>
>>>> More requirements about performa= nce:
>>>> 6. It SHOULD support the&nb= sp;scenarios where a client needs to know&nb= sp;the name of a data object before it&= nbsp;is completely stored at the server. (Th= is is to let clients advertise the obje= ct before having fully uploaded it) (ref:&nb= sp;second last para, pp. 12, -arch)
>>>> 7. It SHOULD support the&nb= sp;scenarios where a client need to know&nbs= p;the name of a data object before it&n= bsp;is locally created. (This is to support&= nbsp;live streaming) (ref: last para, pp. 12= , -arch)
>>>>
>>>> Any comments are welcome, t= hanks.
>>>>
>>>> Peng.
 
------=_001_NextPart877674171020_=------ From alex7822@163.com Fri Jul 6 22:25:28 2012 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 79B9521F850B for ; Fri, 6 Jul 2012 22:25:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.053 X-Spam-Level: *** X-Spam-Status: No, score=3.053 tagged_above=-999 required=5 tests=[AWL=-0.820, BAYES_50=0.001, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, RELAY_IS_220=2.118] 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 52bMRMBJ43nk for ; Fri, 6 Jul 2012 22:25:27 -0700 (PDT) Received: from m13-17.163.com (m13-17.163.com [220.181.13.17]) by ietfa.amsl.com (Postfix) with ESMTP id EA6AA21F8504 for ; Fri, 6 Jul 2012 22:25:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=163.com; s=s110527; h=Received:Date:From:To:Cc:Subject:In-Reply-To: References:Content-Type:MIME-Version:Message-ID; bh=r7e2hKRjY4al 1GMKKvj658iPfk9YCuRVV28d593V0RI=; b=NRqk2wgX25eAwoUfKTwd/Jobdq48 sKKunBjgH1X42dl9plkE6Y72LQY8Gc/ngRdLpjZEe7w38Z0VzYlLHH+K8SgrZb2Z 8p6NYDMgu0fzRmxuz1zTM7ONrEt15N0jxdF4M3JkHnq3EnondpG2FiwLe8yzx1d2 8eel9kUkCAj92ek= Received: from alex7822$163.com ( [130.132.249.141] ) by ajax-webmail-wmsvr17 (Coremail) ; Sat, 7 Jul 2012 13:25:35 +0800 (CST) X-Originating-IP: [130.132.249.141] Date: Sat, 7 Jul 2012 13:25:35 +0800 (CST) From: "C. Alexandre Tian" To: Zongning X-Priority: 3 X-Mailer: Coremail Webmail Server Version SP_ntes V3.5 build 20120507(18390.4657.4663) Copyright (c) 2002-2012 www.mailtech.cn 163com In-Reply-To: References: X-CM-CTRLDATA: t8L93WZvb3Rlcl9odG09MTA3ODY6ODE= Content-Type: multipart/alternative; boundary="----=_Part_41826_2142993466.1341638735814" MIME-Version: 1.0 Message-ID: <42ee4e66.3caf.1385fe677c6.Coremail.alex7822@163.com> X-CM-TRANSID: EcGowGCJMEJQyPdPHaZjAA--.3717W X-CM-SenderInfo: xdoh5lqyssqiywtou0bp/1tbiLAvkyU9oz9A5+wAAsw X-Coremail-Antispam: 1U5529EdanIXcx71UUUUU7vcSsGvfC2KfnxnUU== Cc: "decade@ietf.org" Subject: Re: [decade] FW: I-D Action: draft-ietf-decade-integration-example-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: Sat, 07 Jul 2012 05:25:28 -0000 ------=_Part_41826_2142993466.1341638735814 Content-Type: text/plain; charset=GBK Content-Transfer-Encoding: base64 SGkgTmluZywKCgpJIGp1c3QgcmV2aWV3ZWQgdGhlIG5ldyByZXZpc2lvbi4gVGhhbmtzIGZvciB0 aGUgZWZmb3J0cyEKCiAKCkEgcXVpY2sgY29tbWVudCBmb3IgIjYuIEludGVncmF0aW9uIG9mIEFM VE8gYW5kIElOUyBTeXN0ZW0gZm9yIEZpbGUgRGlzdHJpYnV0aW9uIiBpcyB0aGF0OiB0aGUgc2Nl bmFyaW8gc2V0dGluZyBzZWVtcyBxdWl0IGNvbXBsZXgsIHdoaWNoIGluY2x1ZGVzIGJvdGggQUxU TyBhbmQgSU5TIGV4dGVuc2lvbiBpbiBicm93c2Vycy4gVGhlIGNvbXBsZXhpdHkgZGlyZWN0bHkg bWFrZXMgdGhlIHJlYWRlcnMgd29uZGVyaW5nOiB3aGF0IGlzIHRoZSBraWxsZXItYXBwIHRoYXQg Y291bGQgc2VydmUgYXMgdGhlIG1vdGl2YXRpb24gb2Ygc3VjaCBhIGNvbXBsZXggc3lzdGVtPyBN eSBvcGluaW9uIGlzIHRoYXQgYSBzaW1wbGUgc2V0dGluZyB3b3VsZCBoZWxwIHRoZSBhdWRpZW5j ZSB1bmRlcnN0YW5kaW5nIHRoZSBicm9hZC1hcHBsaWNhYmlsaXR5IGFuZCBiZW5lZml0cyBvZiBE RUNBREUuCgogCgpMZXShr3MgZXhwbG9pdCB0aGUgdmFsdWUgb2YgREVDQURFIGZyb20gdGhlIHJl dmVyc2UgZGlyZWN0aW9uOiBjaGVjayB0aGUgc3RhdGUtb2YtYXJ0IG9mIGEgc3BlY2lmaWMgY29u dGVudCBkaXN0cmlidXRpb24gdGVjaG5vbG9neTsgZmlndXJlIG91dCB3aHkgREVDQURFIGNvdWxk IG1ha2UgaXRzIGRlc2lnbiBtdWNoIGJldHRlci4KCiAKCkhlcmVieSBJIGdpdmUgYW4gZXhhbXBs ZS4gSSBoYXZlIGJlZW4gaW52b2x2ZWQgaW4gYSChsHRyYW5zcGFyZW50IGNhY2hlobEgcHJvamVj dC4gVG8gcmVkdWNlIHRoZSBiYWNrYm9uZSB0cmFmZmljLCBJU1AgZGVwbG95cyChsHRyYW5zcGFy ZW50IGNhY2hlobEgZm9yIGEgbGVhZGluZyBWb0QgQ1AgaW4gbmV0d29yayBlZGdlLiBOb3RlIHRo YXQgdGhpcyB0ZWNobmlxdWUgaGFzIGJlY29tZSBtb3JlIGFuZCBtb3JlIHByZXZhbGVudC4gSG93 ZXZlciwgZHVlIHRvIHRoZSBpbmZvcm1hdGlvbiBpc29sYXRpb24gYmV0d2VlbiBJU1AgYW5kIENQ LCB0aGlzIGluLW5ldHdvcmsgc3RvcmFnZSBkb2VzIG5vdCBwZXJmb3JtIHdlbGwgYXMgaXQgc2hv dWxkIGJlLiBJIGFtIHRoaW5raW5nIG9mIGNoYW5naW5nIHRoZSB0cmFuc3BhcmVudCBjYWNoZXMg dG8gSU5TIHNlcnZlcnMuIFRoZSBDUCBjYW4gZGlyZWN0bHkgd3JpdGUvY29uZmlndXJlIHRoZSBz dG9yYWdlOyBDUCB0aGVuIHVzZSBodHRwLXJlZGlyZWN0aW9uIHRvIGRpcmVjdCBjbGllbnRzIHRv IElOUyBzZXJ2ZXJzLgoKIAoKSW4gdGhpcyBleGFtcGxlLCBDUCwgaW5zdGVhZCBvZiBJTlMsIGlu dGVyYWN0IHcvd28gQUxUTyBzZXJ2aWNlLiAgSU5TIHNlcnZlcnMgYmVjb21lIGR1bXAgU29mdHdh cmUtRGVmaW5hYmxlLU5ldHdvcmstU3RvcmFnZS4gSXQgb25seSBuZWVkcyB0byBzdXBwb3J0IHRo ZSBJTlMgc2VydmVyIGludGVyZmFjZSBhbmQgc3RhbmRhcmQgSFRUUCBwcm90b2NvbC4gSU5TIGNs aWVudCBpbiBFbmQtVXNlciBjb3VsZCBiZSBza2lwcGVkIGluIHRoaXMgc2NlbmFyaW8uCgogCgpU aGUgZXhhbXBsZSBjYW4gY29udmV5IHR3byBpbmZvcm1hdGlvbiAod2hpY2ggSSB0aGluayBhbHNv IHJlbGF0ZXMgd2l0aCBXRyByZWNoYXJ0ZXIpCgooMSkgIElOUyBDbGllbnQgaXMgb25seSBvcHRp b25hbAoKKDIpIEJlc2lkZXMgUDJQIGFwcGxpY2F0aW9ucywgREVDQURFIGhhcyBhIGdyZWF0IHZh bHVlIHRvIGdlbmVyYWwgY29udGVudCBkaXN0cmlidXRpb24gbmV0d29ya3MsIHdoaWNoIGlzIG1v cmUgaW1wb3J0YW50IGluIG5vd2FkYXlzIEludGVybmV0LiAgCgpBbGV4YW5kcmUKCkF0IDIwMTIt MDYtMjEgMTE6MTg6MTcsWm9uZ25pbmcgPHpvbmduaW5nQGh1YXdlaS5jb20+IHdyb3RlOgo+SGks IEZvbGtzLAo+Cj5QbGVhc2Ugc2VlIHRoZSBuZXcgcmV2aXNpb24gb2YgREVDQURFIGludGVncmF0 aW9uIGV4YW1wbGVzIGRyYWZ0Lgo+VGhhbmtzIHRvIFJpY2guIEFsaW1pLCBBa2JhciwgSGFpYmlu IGZvciB5b3VyIHZhbHVhYmxlIGNvbW1lbnRzLiBQbGVhc2UgbGV0IG1lIGtub3cgaWYgYW55IGNv bW1lbnRzIGFyZSBzdGlsbCBub3QgYWRkcmVzc2VkIGluIHRoZSBuZXcgcmV2aXNpb24uCj4KPi1O aW5nCj4KPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0KPj4gRnJvbTogZGVjYWRlLWJvdW5j ZXNAaWV0Zi5vcmcgW21haWx0bzpkZWNhZGUtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmCj4+ IE9mIGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZwo+PiBTZW50OiBUaHVyc2RheSwgSnVuZSAyMSwg MjAxMiAxMToxNCBBTQo+PiBUbzogaS1kLWFubm91bmNlQGlldGYub3JnCj4+IENjOiBkZWNhZGVA aWV0Zi5vcmcKPj4gU3ViamVjdDogW2RlY2FkZV0gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1kZWNh ZGUtaW50ZWdyYXRpb24tZXhhbXBsZS0wNC50eHQKPj4gCj4+IAo+PiBBIE5ldyBJbnRlcm5ldC1E cmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0aGUgb24tbGluZSBJbnRlcm5ldC1EcmFmdHMgZGlyZWN0 b3JpZXMuCj4+ICBUaGlzIGRyYWZ0IGlzIGEgd29yayBpdGVtIG9mIHRoZSBEZWNvdXBsZWQgQXBw bGljYXRpb24gRGF0YSBFbnJvdXRlIFdvcmtpbmcKPj4gR3JvdXAgb2YgdGhlIElFVEYuCj4+IAo+ PiAJVGl0bGUgICAgICAgICAgIDogSW50ZWdyYXRpb24gRXhhbXBsZXMgb2YgREVDQURFIFN5c3Rl bQo+PiAJQXV0aG9yKHMpICAgICAgIDogTmluZyBab25nCj4+ICAgICAgICAgICAgICAgICAgICAg ICAgICAgWGlhb2h1aSBDaGVuCj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgWmhpZ2FuZyBI dWFuZwo+PiAgICAgICAgICAgICAgICAgICAgICAgICAgIExpamlhbmcgQ2hlbgo+PiAgICAgICAg ICAgICAgICAgICAgICAgICAgIEhvbmdxaWFuZyBMaXUKPj4gCUZpbGVuYW1lICAgICAgICA6IGRy YWZ0LWlldGYtZGVjYWRlLWludGVncmF0aW9uLWV4YW1wbGUtMDQudHh0Cj4+IAlQYWdlcyAgICAg ICAgICAgOiAyMwo+PiAJRGF0ZSAgICAgICAgICAgIDogMjAxMi0wNi0yMAo+PiAKPj4gQWJzdHJh Y3Q6Cj4+ICAgIERlY291cGxlZCBBcHBsaWNhdGlvbiBEYXRhIEVucm91dGUgKERFQ0FERSkgc3lz dGVtIGlzIGFuIGluLW5ldHdvcmsKPj4gICAgc3RvcmFnZSBpbmZyYXN0cnVjdHVyZSB3aGljaCBp cyBzdGlsbCB1bmRlciBkaXNjdXNzaW9uIGluIElFVEYuICBUaGlzCj4+ICAgIGRvY3VtZW50IHBy ZXNlbnRzIHR3byBkZXRhaWxlZCBleGFtcGxlcyBvZiBob3cgdG8gaW50ZWdyYXRlIHN1Y2ggaW4t Cj4+ICAgIG5ldHdvcmsgc3RvcmFnZSBpbmZyYXN0cnVjdHVyZSBpbnRvIHBlZXItdG8tcGVlciAo UDJQKSBhcHBsaWNhdGlvbnMKPj4gICAgdG8gYWNoaWV2ZSBtb3JlIGVmZmljaWVudCBjb250ZW50 IGRpc3RyaWJ1dGlvbiwgYW5kIEFwcGxpY2F0aW9uIExheWVyCj4+ICAgIFRyYWZmaWMgT3B0aW1p emF0aW9uIChBTFRPKSBzeXN0ZW0gdG8gYnVpbGQgYSBjb250ZW50IGRpc3RyaWJ1dGlvbgo+PiAg ICBwbGF0Zm9ybSBmb3IgQ29udGVudCBQcm92aWRlcnMgKENQcykuCj4+IAo+PiAKPj4gVGhlIElF VEYgZGF0YXRyYWNrZXIgc3RhdHVzIHBhZ2UgZm9yIHRoaXMgZHJhZnQgaXM6Cj4+IGh0dHBzOi8v ZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtZGVjYWRlLWludGVncmF0aW9uLWV4 YW1wbGUKPj4gCj4+IFRoZXJlJ3MgYWxzbyBhIGh0bWxpemVkIHZlcnNpb24gYXZhaWxhYmxlIGF0 Ogo+PiBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWRlY2FkZS1pbnRlZ3Jh dGlvbi1leGFtcGxlLTA0Cj4+IAo+PiBBIGRpZmYgZnJvbSBwcmV2aW91cyB2ZXJzaW9uIGlzIGF2 YWlsYWJsZSBhdDoKPj4gaHR0cDovL3Rvb2xzLmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1p ZXRmLWRlY2FkZS1pbnRlZ3JhdGlvbi1leGFtcGxlLTA0Cj4+IAo+PiAKPj4gSW50ZXJuZXQtRHJh ZnRzIGFyZSBhbHNvIGF2YWlsYWJsZSBieSBhbm9ueW1vdXMgRlRQIGF0Ogo+PiBmdHA6Ly9mdHAu aWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLwo+Cg== ------=_Part_41826_2142993466.1341638735814 Content-Type: text/html; charset=GBK Content-Transfer-Encoding: base64 PGRpdiBzdHlsZT0ibGluZS1oZWlnaHQ6MS43O2NvbG9yOiMwMDAwMDA7Zm9udC1zaXplOjE0cHg7 Zm9udC1mYW1pbHk6YXJpYWwiPjxkaXYgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGxpbmUt aGVpZ2h0OiAxLjc7IGZvbnQtZmFtaWx5OiBhcmlhbDsgZm9udC1zaXplOiAxNHB4OyI+PGRpdj5I aSBOaW5nLDxicj48L2Rpdj48ZGl2Pjxmb250IHNpemU9IjMiIGZhY2U9IlRpbWVzIE5ldyBSb21h biI+Cgo8L2ZvbnQ+PHAgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwcHQ7IGxpbmUtaGVpZ2h0OiBu b3JtYWw7IiBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IGJsYWNrOyBmb250 LWZhbWlseTogJnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsgZm9udC1z aXplOiAxMC41cHQ7IG1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiAmcXVvdDtUaW1lcyBOZXcgUm9t YW4mcXVvdDs7Ij5JIGp1c3QgcmV2aWV3ZWQgdGhlIG5ldwpyZXZpc2lvbi4gVGhhbmtzIGZvciB0 aGUgZWZmb3J0cyE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PGZvbnQgc2l6ZT0iMyIgZmFjZT0iVGlt ZXMgTmV3IFJvbWFuIj4KCjwvZm9udD48cCBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDBwdDsgbGlu ZS1oZWlnaHQ6IG5vcm1hbDsiIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjog YmxhY2s7IGZvbnQtZmFtaWx5OiAmcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7OyBmb250LXNpemU6IDEwLjVwdDsgbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6ICZxdW90O1Rp bWVzIE5ldyBSb21hbiZxdW90OzsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48Zm9udCBz aXplPSIzIiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPgoKPC9mb250PjxwIHN0eWxlPSJtYXJnaW46 IDBpbiAwaW4gMHB0OyBsaW5lLWhlaWdodDogbm9ybWFsOyIgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImNvbG9yOiBibGFjazsgZm9udC1mYW1pbHk6ICZxdW90O0FyaWFsJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7IGZvbnQtc2l6ZTogMTAuNXB0OyBtc28tZmFyZWFzdC1mb250 LWZhbWlseTogJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7OyI+QSBxdWljayBjb21tZW50IGZv ciAiNi4KSW50ZWdyYXRpb24gb2YgQUxUTyBhbmQgSU5TIFN5c3RlbSBmb3IgRmlsZSBEaXN0cmli dXRpb24iIGlzIHRoYXQ6IHRoZQpzY2VuYXJpbyBzZXR0aW5nIHNlZW1zIHF1aXQgY29tcGxleCwg d2hpY2ggaW5jbHVkZXMgYm90aCBBTFRPIGFuZCBJTlMgZXh0ZW5zaW9uCmluIGJyb3dzZXJzLiBU aGUgY29tcGxleGl0eSBkaXJlY3RseSBtYWtlcyB0aGUgcmVhZGVycyB3b25kZXJpbmc6IHdoYXQg aXMgdGhlCmtpbGxlci1hcHAgdGhhdCBjb3VsZCBzZXJ2ZSBhcyB0aGUgbW90aXZhdGlvbiBvZiBz dWNoIGEgY29tcGxleCBzeXN0ZW0/IE15Cm9waW5pb24gaXMgdGhhdCBhIHNpbXBsZSBzZXR0aW5n IHdvdWxkIGhlbHAgdGhlIGF1ZGllbmNlIHVuZGVyc3RhbmRpbmcgdGhlCmJyb2FkLWFwcGxpY2Fi aWxpdHkgYW5kIGJlbmVmaXRzIG9mIERFQ0FERS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PGZvbnQg c2l6ZT0iMyIgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4KCjwvZm9udD48cCBzdHlsZT0ibWFyZ2lu OiAwaW4gMGluIDBwdDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsiIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJjb2xvcjogYmxhY2s7IGZvbnQtZmFtaWx5OiAmcXVvdDtBcmlhbCZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7OyBmb250LXNpemU6IDEwLjVwdDsgbXNvLWZhcmVhc3QtZm9u dC1mYW1pbHk6ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OzsiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD48Zm9udCBzaXplPSIzIiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPgoKPC9mb250 PjxwIHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMHB0OyBsaW5lLWhlaWdodDogbm9ybWFsOyIgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiBibGFjazsgZm9udC1mYW1pbHk6ICZx dW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7IGZvbnQtc2l6ZTogMTAuNXB0 OyBtc28tZmFyZWFzdC1mb250LWZhbWlseTogJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7OyI+ TGV0oa9zIGV4cGxvaXQgdGhlIHZhbHVlCm9mIERFQ0FERSBmcm9tIHRoZSByZXZlcnNlIGRpcmVj dGlvbjogY2hlY2sgdGhlIHN0YXRlLW9mLWFydCBvZiBhIHNwZWNpZmljIGNvbnRlbnQKZGlzdHJp YnV0aW9uIHRlY2hub2xvZ3k7IGZpZ3VyZSBvdXQgd2h5IERFQ0FERSBjb3VsZCBtYWtlIGl0cyBk ZXNpZ24gbXVjaCBiZXR0ZXIuPG86cD48L286cD48L3NwYW4+PC9wPjxmb250IHNpemU9IjMiIGZh Y2U9IlRpbWVzIE5ldyBSb21hbiI+Cgo8L2ZvbnQ+PHAgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAw cHQ7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IiBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Y29sb3I6IGJsYWNrOyBmb250LWZhbWlseTogJnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OzsgZm9udC1zaXplOiAxMC41cHQ7IG1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiAm cXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDs7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ PGZvbnQgc2l6ZT0iMyIgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4KCjwvZm9udD48cCBzdHlsZT0i bWFyZ2luOiAwaW4gMGluIDBwdDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsiIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJjb2xvcjogYmxhY2s7IGZvbnQtZmFtaWx5OiAmcXVvdDtBcmlhbCZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7OyBmb250LXNpemU6IDEwLjVwdDsgbXNvLWZhcmVh c3QtZm9udC1mYW1pbHk6ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OzsiPkhlcmVieSBJIGdp dmUgYW4KZXhhbXBsZS4gSSBoYXZlIGJlZW4gaW52b2x2ZWQgaW4gYSChsHRyYW5zcGFyZW50IGNh Y2hlobEgcHJvamVjdC4gVG8gcmVkdWNlIHRoZQpiYWNrYm9uZSB0cmFmZmljLCBJU1AgZGVwbG95 cyChsHRyYW5zcGFyZW50IGNhY2hlobEgZm9yIGEgbGVhZGluZyBWb0QgQ1AgaW4KbmV0d29yayBl ZGdlLiBOb3RlIHRoYXQgdGhpcyB0ZWNobmlxdWUgaGFzIGJlY29tZSBtb3JlIGFuZCBtb3JlIHBy ZXZhbGVudC4gSG93ZXZlciwKZHVlIHRvIHRoZSBpbmZvcm1hdGlvbiBpc29sYXRpb24gYmV0d2Vl biBJU1AgYW5kIENQLCB0aGlzIGluLW5ldHdvcmsgc3RvcmFnZQpkb2VzIG5vdCBwZXJmb3JtIHdl bGwgYXMgaXQgc2hvdWxkIGJlLiBJIGFtIHRoaW5raW5nIG9mIGNoYW5naW5nIHRoZSB0cmFuc3Bh cmVudApjYWNoZXMgdG8gSU5TIHNlcnZlcnMuIFRoZSBDUCBjYW4gZGlyZWN0bHkgd3JpdGUvY29u ZmlndXJlIHRoZSBzdG9yYWdlOyBDUCB0aGVuCnVzZSBodHRwLXJlZGlyZWN0aW9uIHRvIGRpcmVj dCBjbGllbnRzIHRvIElOUyBzZXJ2ZXJzLiA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PGZvbnQgc2l6 ZT0iMyIgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4KCjwvZm9udD48cCBzdHlsZT0ibWFyZ2luOiAw aW4gMGluIDBwdDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsiIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJjb2xvcjogYmxhY2s7IGZvbnQtZmFtaWx5OiAmcXVvdDtBcmlhbCZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7OyBmb250LXNpemU6IDEwLjVwdDsgbXNvLWZhcmVhc3QtZm9udC1m YW1pbHk6ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OzsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD48Zm9udCBzaXplPSIzIiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPgoKPC9mb250Pjxw IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMHB0OyBsaW5lLWhlaWdodDogbm9ybWFsOyIgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiBibGFjazsgZm9udC1mYW1pbHk6ICZxdW90 O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7IGZvbnQtc2l6ZTogMTAuNXB0OyBt c28tZmFyZWFzdC1mb250LWZhbWlseTogJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7OyI+SW4g dGhpcyBleGFtcGxlLCBDUCwKaW5zdGVhZCBvZiBJTlMsIGludGVyYWN0IHcvd28gQUxUTyBzZXJ2 aWNlLiA8c3BhbiBzdHlsZT0ibXNvLXNwYWNlcnVuOiB5ZXM7Ij4mbmJzcDs8L3NwYW4+SU5TIHNl cnZlcnMgYmVjb21lIGR1bXAKU29mdHdhcmUtRGVmaW5hYmxlLU5ldHdvcmstU3RvcmFnZS4gSXQg b25seSBuZWVkcyB0byBzdXBwb3J0IHRoZSBJTlMgc2VydmVyCmludGVyZmFjZSBhbmQgc3RhbmRh cmQgSFRUUCBwcm90b2NvbC4gSU5TIGNsaWVudCBpbiBFbmQtVXNlciBjb3VsZCBiZSBza2lwcGVk CmluIHRoaXMgc2NlbmFyaW8uIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48Zm9udCBzaXplPSIzIiBm YWNlPSJUaW1lcyBOZXcgUm9tYW4iPgoKPC9mb250PjxwIHN0eWxlPSJtYXJnaW46IDBpbiAwaW4g MHB0OyBsaW5lLWhlaWdodDogbm9ybWFsOyIgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImNvbG9yOiBibGFjazsgZm9udC1mYW1pbHk6ICZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7IGZvbnQtc2l6ZTogMTAuNXB0OyBtc28tZmFyZWFzdC1mb250LWZhbWlseTog JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pjxmb250IHNpemU9IjMiIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+Cgo8L2ZvbnQ+PHAgc3R5bGU9 Im1hcmdpbjogMGluIDBpbiAwcHQ7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IiBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IGJsYWNrOyBmb250LWZhbWlseTogJnF1b3Q7QXJpYWwm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsgZm9udC1zaXplOiAxMC41cHQ7IG1zby1mYXJl YXN0LWZvbnQtZmFtaWx5OiAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDs7Ij5UaGUgZXhhbXBs ZSBjYW4gY29udmV5CnR3byBpbmZvcm1hdGlvbiAod2hpY2ggSSB0aGluayBhbHNvIHJlbGF0ZXMg d2l0aCBXRyByZWNoYXJ0ZXIpPG86cD48L286cD48L3NwYW4+PC9wPjxmb250IHNpemU9IjMiIGZh Y2U9IlRpbWVzIE5ldyBSb21hbiI+Cgo8L2ZvbnQ+PHAgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAw cHQ7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IiBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Y29sb3I6IGJsYWNrOyBmb250LWZhbWlseTogJnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OzsgZm9udC1zaXplOiAxMC41cHQ7IG1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiAm cXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDs7Ij4oMSk8c3BhbiBzdHlsZT0ibXNvLXNwYWNlcnVu OiB5ZXM7Ij4mbmJzcDsgPC9zcGFuPklOUyBDbGllbnQgaXMgb25seSBvcHRpb25hbDxvOnA+PC9v OnA+PC9zcGFuPjwvcD48Zm9udCBzaXplPSIzIiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPgoKPC9m b250PjxwIHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMHB0OyBsaW5lLWhlaWdodDogbm9ybWFsOyIg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiBibGFjazsgZm9udC1mYW1pbHk6 ICZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7IGZvbnQtc2l6ZTogMTAu NXB0OyI+KDIpIEJlc2lkZXMgUDJQIGFwcGxpY2F0aW9ucywgREVDQURFIGhhcyBhIGdyZWF0IHZh bHVlIHRvIGdlbmVyYWwKY29udGVudCBkaXN0cmlidXRpb24gbmV0d29ya3MsIHdoaWNoIGlzIG1v cmUgaW1wb3J0YW50IGluIG5vd2FkYXlzIEludGVybmV0LiA8c3BhbiBzdHlsZT0ibXNvLXNwYWNl cnVuOiB5ZXM7Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3NwYW4+PC9wPjxmb250IHNpemU9 IjMiIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+Cgo8L2ZvbnQ+PC9kaXY+PGRpdiBpZD0iZGl2TmV0 ZWFzZU1haWxDYXJkIj48L2Rpdj48ZGl2PkFsZXhhbmRyZTwvZGl2PjxwcmU+PGJyPkF0Jm5ic3A7 MjAxMi0wNi0yMSZuYnNwOzExOjE4OjE3LFpvbmduaW5nJm5ic3A7Jmx0OzxhIGhyZWY9Im1haWx0 bzp6b25nbmluZ0BodWF3ZWkuY29tIj56b25nbmluZ0BodWF3ZWkuY29tPC9hPiZndDsmbmJzcDt3 cm90ZToKJmd0O0hpLCZuYnNwO0ZvbGtzLAomZ3Q7CiZndDtQbGVhc2UmbmJzcDtzZWUmbmJzcDt0 aGUmbmJzcDtuZXcmbmJzcDtyZXZpc2lvbiZuYnNwO29mJm5ic3A7REVDQURFJm5ic3A7aW50ZWdy YXRpb24mbmJzcDtleGFtcGxlcyZuYnNwO2RyYWZ0LgomZ3Q7VGhhbmtzJm5ic3A7dG8mbmJzcDtS aWNoLiZuYnNwO0FsaW1pLCZuYnNwO0FrYmFyLCZuYnNwO0hhaWJpbiZuYnNwO2ZvciZuYnNwO3lv dXImbmJzcDt2YWx1YWJsZSZuYnNwO2NvbW1lbnRzLiZuYnNwO1BsZWFzZSZuYnNwO2xldCZuYnNw O21lJm5ic3A7a25vdyZuYnNwO2lmJm5ic3A7YW55Jm5ic3A7Y29tbWVudHMmbmJzcDthcmUmbmJz cDtzdGlsbCZuYnNwO25vdCZuYnNwO2FkZHJlc3NlZCZuYnNwO2luJm5ic3A7dGhlJm5ic3A7bmV3 Jm5ic3A7cmV2aXNpb24uCiZndDsKJmd0Oy1OaW5nCiZndDsKJmd0OyZndDsmbmJzcDstLS0tLU9y aWdpbmFsJm5ic3A7TWVzc2FnZS0tLS0tCiZndDsmZ3Q7Jm5ic3A7RnJvbTombmJzcDs8YSBocmVm PSJtYWlsdG86ZGVjYWRlLWJvdW5jZXNAaWV0Zi5vcmciPmRlY2FkZS1ib3VuY2VzQGlldGYub3Jn PC9hPiZuYnNwO1ttYWlsdG86PGEgaHJlZj0ibWFpbHRvOmRlY2FkZS1ib3VuY2VzQGlldGYub3Jn Ij5kZWNhZGUtYm91bmNlc0BpZXRmLm9yZzwvYT5dJm5ic3A7T24mbmJzcDtCZWhhbGYKJmd0OyZn dDsmbmJzcDtPZiZuYnNwOzxhIGhyZWY9Im1haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmci PmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZzwvYT4KJmd0OyZndDsmbmJzcDtTZW50OiZuYnNwO1Ro dXJzZGF5LCZuYnNwO0p1bmUmbmJzcDsyMSwmbmJzcDsyMDEyJm5ic3A7MTE6MTQmbmJzcDtBTQom Z3Q7Jmd0OyZuYnNwO1RvOiZuYnNwOzxhIGhyZWY9Im1haWx0bzppLWQtYW5ub3VuY2VAaWV0Zi5v cmciPmktZC1hbm5vdW5jZUBpZXRmLm9yZzwvYT4KJmd0OyZndDsmbmJzcDtDYzombmJzcDs8YSBo cmVmPSJtYWlsdG86ZGVjYWRlQGlldGYub3JnIj5kZWNhZGVAaWV0Zi5vcmc8L2E+CiZndDsmZ3Q7 Jm5ic3A7U3ViamVjdDombmJzcDtbZGVjYWRlXSZuYnNwO0ktRCZuYnNwO0FjdGlvbjombmJzcDtk cmFmdC1pZXRmLWRlY2FkZS1pbnRlZ3JhdGlvbi1leGFtcGxlLTA0LnR4dAomZ3Q7Jmd0OyZuYnNw OwomZ3Q7Jmd0OyZuYnNwOwomZ3Q7Jmd0OyZuYnNwO0EmbmJzcDtOZXcmbmJzcDtJbnRlcm5ldC1E cmFmdCZuYnNwO2lzJm5ic3A7YXZhaWxhYmxlJm5ic3A7ZnJvbSZuYnNwO3RoZSZuYnNwO29uLWxp bmUmbmJzcDtJbnRlcm5ldC1EcmFmdHMmbmJzcDtkaXJlY3Rvcmllcy4KJmd0OyZndDsmbmJzcDsm bmJzcDtUaGlzJm5ic3A7ZHJhZnQmbmJzcDtpcyZuYnNwO2EmbmJzcDt3b3JrJm5ic3A7aXRlbSZu YnNwO29mJm5ic3A7dGhlJm5ic3A7RGVjb3VwbGVkJm5ic3A7QXBwbGljYXRpb24mbmJzcDtEYXRh Jm5ic3A7RW5yb3V0ZSZuYnNwO1dvcmtpbmcKJmd0OyZndDsmbmJzcDtHcm91cCZuYnNwO29mJm5i c3A7dGhlJm5ic3A7SUVURi4KJmd0OyZndDsmbmJzcDsKJmd0OyZndDsmbmJzcDsJVGl0bGUmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDs6Jm5ic3A7SW50ZWdyYXRpb24mbmJzcDtFeGFtcGxlcyZuYnNwO29mJm5ic3A7REVDQURF Jm5ic3A7U3lzdGVtCiZndDsmZ3Q7Jm5ic3A7CUF1dGhvcihzKSZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOzombmJzcDtOaW5nJm5ic3A7Wm9uZwomZ3Q7Jmd0OyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO1hpYW9odWkmbmJzcDtD aGVuCiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7WmhpZ2FuZyZuYnNwO0h1YW5nCiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7TGlqaWFuZyZuYnNwO0NoZW4KJmd0OyZndDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtIb25ncWlhbmcmbmJzcDtMaXUK Jmd0OyZndDsmbmJzcDsJRmlsZW5hbWUmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDs6Jm5ic3A7ZHJhZnQtaWV0Zi1kZWNhZGUtaW50ZWdyYXRpb24tZXhhbXBs ZS0wNC50eHQKJmd0OyZndDsmbmJzcDsJUGFnZXMmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs6Jm5ic3A7MjMKJmd0OyZndDsm bmJzcDsJRGF0ZSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzombmJzcDsyMDEyLTA2LTIwCiZndDsmZ3Q7Jm5ic3A7 CiZndDsmZ3Q7Jm5ic3A7QWJzdHJhY3Q6CiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 RGVjb3VwbGVkJm5ic3A7QXBwbGljYXRpb24mbmJzcDtEYXRhJm5ic3A7RW5yb3V0ZSZuYnNwOyhE RUNBREUpJm5ic3A7c3lzdGVtJm5ic3A7aXMmbmJzcDthbiZuYnNwO2luLW5ldHdvcmsKJmd0OyZn dDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtzdG9yYWdlJm5ic3A7aW5mcmFzdHJ1Y3R1cmUmbmJz cDt3aGljaCZuYnNwO2lzJm5ic3A7c3RpbGwmbmJzcDt1bmRlciZuYnNwO2Rpc2N1c3Npb24mbmJz cDtpbiZuYnNwO0lFVEYuJm5ic3A7Jm5ic3A7VGhpcwomZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwO2RvY3VtZW50Jm5ic3A7cHJlc2VudHMmbmJzcDt0d28mbmJzcDtkZXRhaWxlZCZuYnNw O2V4YW1wbGVzJm5ic3A7b2YmbmJzcDtob3cmbmJzcDt0byZuYnNwO2ludGVncmF0ZSZuYnNwO3N1 Y2gmbmJzcDtpbi0KJmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtuZXR3b3JrJm5ic3A7 c3RvcmFnZSZuYnNwO2luZnJhc3RydWN0dXJlJm5ic3A7aW50byZuYnNwO3BlZXItdG8tcGVlciZu YnNwOyhQMlApJm5ic3A7YXBwbGljYXRpb25zCiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7dG8mbmJzcDthY2hpZXZlJm5ic3A7bW9yZSZuYnNwO2VmZmljaWVudCZuYnNwO2NvbnRlbnQm bmJzcDtkaXN0cmlidXRpb24sJm5ic3A7YW5kJm5ic3A7QXBwbGljYXRpb24mbmJzcDtMYXllcgom Z3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO1RyYWZmaWMmbmJzcDtPcHRpbWl6YXRpb24m bmJzcDsoQUxUTykmbmJzcDtzeXN0ZW0mbmJzcDt0byZuYnNwO2J1aWxkJm5ic3A7YSZuYnNwO2Nv bnRlbnQmbmJzcDtkaXN0cmlidXRpb24KJmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtw bGF0Zm9ybSZuYnNwO2ZvciZuYnNwO0NvbnRlbnQmbmJzcDtQcm92aWRlcnMmbmJzcDsoQ1BzKS4K Jmd0OyZndDsmbmJzcDsKJmd0OyZndDsmbmJzcDsKJmd0OyZndDsmbmJzcDtUaGUmbmJzcDtJRVRG Jm5ic3A7ZGF0YXRyYWNrZXImbmJzcDtzdGF0dXMmbmJzcDtwYWdlJm5ic3A7Zm9yJm5ic3A7dGhp cyZuYnNwO2RyYWZ0Jm5ic3A7aXM6CiZndDsmZ3Q7Jm5ic3A7aHR0cHM6Ly9kYXRhdHJhY2tlci5p ZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1kZWNhZGUtaW50ZWdyYXRpb24tZXhhbXBsZQomZ3Q7Jmd0 OyZuYnNwOwomZ3Q7Jmd0OyZuYnNwO1RoZXJlJ3MmbmJzcDthbHNvJm5ic3A7YSZuYnNwO2h0bWxp emVkJm5ic3A7dmVyc2lvbiZuYnNwO2F2YWlsYWJsZSZuYnNwO2F0OgomZ3Q7Jmd0OyZuYnNwO2h0 dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtZGVjYWRlLWludGVncmF0aW9uLWV4 YW1wbGUtMDQKJmd0OyZndDsmbmJzcDsKJmd0OyZndDsmbmJzcDtBJm5ic3A7ZGlmZiZuYnNwO2Zy b20mbmJzcDtwcmV2aW91cyZuYnNwO3ZlcnNpb24mbmJzcDtpcyZuYnNwO2F2YWlsYWJsZSZuYnNw O2F0OgomZ3Q7Jmd0OyZuYnNwO2h0dHA6Ly90b29scy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJh ZnQtaWV0Zi1kZWNhZGUtaW50ZWdyYXRpb24tZXhhbXBsZS0wNAomZ3Q7Jmd0OyZuYnNwOwomZ3Q7 Jmd0OyZuYnNwOwomZ3Q7Jmd0OyZuYnNwO0ludGVybmV0LURyYWZ0cyZuYnNwO2FyZSZuYnNwO2Fs c28mbmJzcDthdmFpbGFibGUmbmJzcDtieSZuYnNwO2Fub255bW91cyZuYnNwO0ZUUCZuYnNwO2F0 OgomZ3Q7Jmd0OyZuYnNwO2Z0cDovL2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvCiZndDsK PC9wcmU+PC9kaXY+PC9kaXY+PGJyPjxicj48c3BhbiB0aXRsZT0ibmV0ZWFzZWZvb3RlciI+PHNw YW4gaWQ9Im5ldGVhc2VfbWFpbF9mb290ZXIiPjwvc3Bhbj48L3NwYW4+ ------=_Part_41826_2142993466.1341638735814-- From stephen.farrell@cs.tcd.ie Sat Jul 7 05:31:12 2012 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 40EDA21F8617 for ; Sat, 7 Jul 2012 05:31:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_63=0.6, 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 a6c0sWHyY9Oq for ; Sat, 7 Jul 2012 05:31:11 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 8640121F8618 for ; Sat, 7 Jul 2012 05:30:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 50DFC1714EF; Sat, 7 Jul 2012 13:31:12 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1341664271; bh=zT+zTH21LuFK3Z 5DAPIwWbq8wJhr/Zd5FD30EGNoKRM=; b=zazcw1hUa4iqE+D+4gErkdXKCmCtae 57/nDrcMO7sJlH1gGzNp6Jarr84DGvbmdt+0CjHJ05ulTPUU6CGUwCkTidSOL2GP xTKPRMkTkaFcn9+HVoEgEV5SzzRHvxFHip7Is6gjTMWcKfIuJ++HhXRqGjzHJSzE 3tGFFs2GdGEYhCu3DY6E4/eWo3h0RLqV5qnjMsz00ODeExU3RGGWJh2mFo/jB0xZ fDcbpuc6LUlF9LV2u15KDBY+0QtnWMrL6H1fYD1sru+FUPWz8WAjX+NVEfkGq72t 5UWQp6ZYXeUtBJrwZznf5a/YdQn04Apo9TW+5yJzfXigSJT/hLqgbhjQ== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id E5o+BAgV16xG; Sat, 7 Jul 2012 13:31:11 +0100 (IST) Received: from [10.87.48.11] (unknown [86.45.52.217]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id C1ED51714EE; Sat, 7 Jul 2012 13:31:10 +0100 (IST) Message-ID: <4FF82C0E.5020809@cs.tcd.ie> Date: Sat, 07 Jul 2012 13:31:10 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: "pzhang.thu" References: <20120703003402663560214@gmail.com>, <4FF2ACC3.1020004@cs.tcd.ie> <20120704160541638826251@gmail.com>, <4FF4B0D5.40906@cs.tcd.ie> <20120704174022735010267@gmail.com>, <4FF4B8C2.7090702@cs.tcd.ie> <20120704175739679926274@gmail.com>, <4FF4BD39.7050907@cs.tcd.ie> <20120706223508854218405@gmail.com> In-Reply-To: <20120706223508854218405@gmail.com> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "DECADE@ietf.org" Subject: Re: [decade] Object naming in -req and -arch 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, 07 Jul 2012 12:31:12 -0000 Hiya, On 07/07/2012 03:35 AM, Zhang Peng wrote: > Without considering the optimization of naming (i.e., letting applications know the object name before commitment of uploading), I think the hash-based you proposed is good enough for the requirements (i.e., uniqueness, and object-id binding). One problem, which is also criticized in Content-Centric Networking, is that such flat names are not human-readable, and are not suitable for aggregations. There should be a mapping from meaningful names to them. We can leave this part to applications. > > On the other hand, if we are encouraging the optimization, we should more sophisticated naming schemes. Since we would like to give the name for the object that is not fully uploaded, then we should use the following scheme inspired by the naming schemes of Content-Centric Networking. > > We assume that the uploading client or a publisher holds a private/public key pair. > (1) The object name is a the hash of the public key of the uploading client, together with the locally unique identifier assigned to the object. > (2) The object content and the name are signed together using the private key of the uploading client. > (3) Some information about the location of the key may be included in the object, so that a client that requests the object can retrieve the public key to verify the name-object binding. I think that scheme is the same as the one in draft-hallambaker I mentioned before (if not, please tell me what I've missed), and, in our case, is based on previous work (mainly by Christian) in the FP7 4WARD project. So the ideas have been around for a while in various places for how to handle name-data integrity for dynamic content using asymmetric keys. However, I'm not actually that fond of those schemes, mainly because they create an often-ignored requirement for public key revocation, which is an essentially unsolved problem in this space, and is still problematic even in X.509 based PKIs where we've had real difficulty getting clients to hard-fail. Those schemes also of course add a requirement for private key maintenance, which is considerably more burdensome compared to just using hashes. IMO, we're getting very close to research topics with such schemes and it might be better to focus on static content cases for now where easier and more practical solutions clearly exist. Having said that, I could understand the wg might not want to focus in like that, but I suspect solving the clearer, better scoped problem might be a better approach in the first instance. Cheers, S. PS: I hope, if there's time, to start some discussion on the use of crypto in names in the icnrg meeting in Vancouver. > ref: [1] Naming in Content-Oriented Architectures, ICN11 > [2] Networking Named Content, Conext09 > > > B, > > Peng. > > From: Stephen Farrell > Date: 2012-07-04 18:01 > To: pzhang.thu > CC: DECADE@ietf.org > Subject: Re: [decade] Object naming in -req and -arch > > > On 07/04/2012 10:57 PM, Zhang Peng wrote: >> Ok, it seems to work. But it just includes the hash of public key. How to name a sequence of dynamic names? For example, the stream is divided into object by seconds: 1s, 2s, 3s,...? > > Some work TBD:-) > > I suspect that the details will need work in the decade WG. > > I'm confident that once we know we can handle dynamic > content as in draft-hallambaker, then we can use the same > approach for whatever decade-specifics are needed later. > > In the case you mention, maybe a chain of ni URIs might > be needed included as some decade metadata with each > 1s chunk and perhaps giving the name of the next chunk. > But I suspect you've gone beyond naming requirements > when you start to consider sets of related (parts of) > objects. > > S. > >> B, >> >> Peng. >> From: Stephen Farrell >> Date: 2012-07-04 17:42 >> To: pzhang.thu >> CC: DECADE@ietf.org >> Subject: Re: [decade] Object naming in -req and -arch >> >> >> On 07/04/2012 10:40 PM, Zhang Peng wrote: >>> Hi Stephen, >>> >>> Yes, for most cases, hash-based naming scheme is ok for in-network storage system which holds immutable objects. >>> Bur for some application such as live streaming, we expect that the uploader/streamer can know the object name before it uploads the object to decade server. This will allow the streamer to advertise the file before fully uploading it, and then the viewer can fetch the object using the advertised name. If each object contains several seconds of video data, this feature can considerably reduce the latency. Thus, we may need a enumeration-based scheme besides the hash-based one. Can we add this feature in your proposed design? Thanks. >> >> Ah gotcha. Yes there are ways, basically by defining a new >> hash alg and using a signature. There's one documented in >> draft-hallambaker-decade-ni-params [1] section 2.1. >> >> Cheers, >> S. >> >> [1] http://tools.ietf.org/html/draft-hallambaker-decade-ni-params-03 >> >>> B, >>> >>> Peng. >>> >>> From: Stephen Farrell >>> Date: 2012-07-04 17:08 >>> To: pzhang.thu >>> CC: DECADE@ietf.org >>> Subject: Re: [decade] Object naming in -req and -arch >>> >>> >>> On 07/04/2012 09:05 PM, Zhang Peng wrote: >>>> Hi Stephen, >>>> >>>> I have read your documents on hash-based naming. It designs a good URI format and mapping scheme to HTTP URL. For DECADE, since our requirements include uniqueness, name-object binding validation, I wonder how we can apply your scheme to meet them. >>> >>> ni URIs are as unique as the collision resistance of your hash >>> function supports basically. If you pick sha-256 that won't be >>> an issue. >>> >>> ni URis support name-data integrity (incl. in the code we've >>> released) which I think is the same as what you're calling >>> name-object binding validation. >>> >>> So my answer for both is: just use ni URIs to meet these >>> requirements:-) >>> >>>> BTW, can you give more details on what you mean by "meets these requirements"? Thanks. >>> >>> I meant: if there's some requirement that can't be met using ni URIs, >>> then I'd like to know about that before its too late. (I realise >>> that the decade WG might still change reqs of course but wanted to >>> check now before we're done with our doc.) >>> >>> S >>> >>>> B, >>>> >>>> Peng. >>>> >>>> From: Stephen Farrell >>>> Date: 2012-07-03 03:26 >>>> To: pzhang.thu >>>> CC: DECADE@ietf.org >>>> Subject: Re: [decade] Object naming in -req and -arch >>>> >>>> Hiya, >>>> >>>> I guess I hope that our draft (just exited IETF LC) meets >>>> these requirements. If not, I'd be interested in what's >>>> missing. >>>> >>>> Cheers, >>>> S. >>>> >>>> [1] http://tools.ietf.org/html/draft-farrell-decade-ni >>>> >>>> On 07/03/2012 06:34 AM, Zhang Peng wrote: >>>>> Dear DECADE participants, >>>>> >>>>> As pointed out by Richard in previous discussions, both the -req and -arch documents has some paragraphs describing content naming, and they need better organization: some generic requirements should be in -req, while some more specific ones should be in -arch. Here are some suggestions about how to split the content on naming in these two documents. >>>>> >>>>> The rationale for the following split is that I recognize there are two generic requirements, that is, uniqueness, and binding validation. They should be placed in the -req. In -arch, we should present the specific requirements to enable uniqueness, and binding validation, respectively. There are also some more requirements on how to improve the responsiveness of the system, i.e., the support of early name generation. See below for details (references to the original documents are given after each specific requirements): >>>>> >>>>> Generic requirements (to be put in -req) >>>>> >>>>> 1. It SHOULD ensure that uniqueness of object names. >>>>> 2. It SHOULD support the validation of name-object binding. >>>>> 3. It SHOULD support the operation of DECADE-compatible servers under diverse administrative domains with no coordination. (not sure about what operations are meant here) >>>>> >>>>> Specific requirements (to be put in -arch) >>>>> >>>>> Requirements to enable uniqueness: >>>>> 1. It MAY enable applications to construct unique names by themselves with a high probability (ref: last sentence, pp. 11, -arch). If this is the case, it SHOULD indicate conflicts when duplicate names are constructed (ref: first para, 4.5.1, -req). >>>>> 2. It MAY support content-dependent hash-based schemes (for general immutable objects), and content-independent enumeration-based schemes (for live streaming) >>>>> (ref: 2nd para, pp. 12, -arch) >>>>> >>>>> Requirements to enable name-object binding validation: >>>>> 3. Different name-object binding validation mechanisms MAY be supported, and an application can decide which mechanism to use. (ref: 2nd para, 4.4, -arch) >>>>> 4. Names MAY be self-describing so that a receiving entity (Content Consumer) knows which mechanism is used (ref: 1st para, pp. 12, -arch) >>>>> 5. It SHOULD provide the following name elements: (1) A "type" field, (2) Cryptographic data, (3) Application or publisher information. (ref: pp. 12, -arch) >>>>> >>>>> More requirements about performance: >>>>> 6. It SHOULD support the scenarios where a client needs to know the name of a data object before it is completely stored at the server. (This is to let clients advertise the object before having fully uploaded it) (ref: second last para, pp. 12, -arch) >>>>> 7. It SHOULD support the scenarios where a client need to know the name of a data object before it is locally created. (This is to support live streaming) (ref: last para, pp. 12, -arch) >>>>> >>>>> Any comments are welcome, thanks. >>>>> >>>>> Peng. From yry@cs.yale.edu Sat Jul 7 09:47:00 2012 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 E5C3B21F86AF for ; Sat, 7 Jul 2012 09:47:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.925 X-Spam-Level: X-Spam-Status: No, score=-0.925 tagged_above=-999 required=5 tests=[AWL=-0.926, BAYES_50=0.001] 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 F1J8txFPTvQb for ; Sat, 7 Jul 2012 09:46:53 -0700 (PDT) Received: from vm-emlprdomr-05.its.yale.edu (vm-emlprdomr-05.its.yale.edu [130.132.50.146]) by ietfa.amsl.com (Postfix) with ESMTP id D89FA21F869E for ; Sat, 7 Jul 2012 09:46:51 -0700 (PDT) Received: from [192.168.1.108] ([221.221.18.179]) (authenticated bits=0) by vm-emlprdomr-05.its.yale.edu (8.14.4/8.14.4) with ESMTP id q67GkOQ9020497 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 7 Jul 2012 12:46:26 -0400 Message-ID: <4FF867DE.7020609@cs.yale.edu> Date: Sun, 08 Jul 2012 00:46:22 +0800 From: "Y. Richard Yang" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: "DECADE@ietf.org" Content-Type: multipart/mixed; boundary="------------050204020004060507090201" X-Scanned-By: MIMEDefang 2.71 on 130.132.50.146 Subject: [decade] reorganized -req 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, 07 Jul 2012 16:47:01 -0000 This is a multi-part message in MIME format. --------------050204020004060507090201 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear all, We did a substantial reorganization of the -req documents. It is attached to this email. Any early feedback will be greatly appreciated. Thanks! Richard --------------050204020004060507090201 Content-Type: text/plain; charset=UTF-8; name="draft-ietf-decade-reqs-all_v06.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="draft-ietf-decade-reqs-all_v06.txt" DECADE Y. Gu Internet-Draft Huawei Intended status: Informational D. Bryan Expires: January 7, 2013 Polycom, Inc. Y. Yang Yale University R. Alimi Google July 6, 2012 DECADE Requirements draft-ietf-decade-reqs-06 Abstract The target of the DECoupled Application Data Enroute (DECADE) system 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- compatible 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 a DECADE-compatible system architecture includes all of the desired functionality for intended applications. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months Gu, et al. Expires January 7, 2013 [Page 1] Internet-Draft DECADE Requirements July 2012 and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on January 7, 2013. Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Gu, et al. Expires January 7, 2013 [Page 2] Internet-Draft DECADE Requirements July 2012 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.1. DECADE-compatible Client . . . . . . . . . . . . . . . . . 6 2.2. DECADE-compatible Server . . . . . . . . . . . . . . . . . 6 2.3. DECADE Storage Provider . . . . . . . . . . . . . . . . . 6 2.4. DECADE Account . . . . . . . . . . . . . . . . . . . . . . 6 2.5. Provider . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.6. Consumer . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.7. Content Distribution Application . . . . . . . . . . . . . 6 2.8. Target Application . . . . . . . . . . . . . . . . . . . . 7 2.9. Application End-Point . . . . . . . . . . . . . . . . . . 7 2.10. Data Object . . . . . . . . . . . . . . . . . . . . . . . 7 2.11. DECADE-compatible System . . . . . . . . . . . . . . . . . 7 2.12. DECADE Resource Protocol (DRP) . . . . . . . . . . . . . . 7 2.13. DECADE Standard Data Transfer Protocol (SDT) . . . . . . . 7 3. System and Protocol Components . . . . . . . . . . . . . . . . 7 4. Requirements Structure . . . . . . . . . . . . . . . . . . . . 9 5. Data Object Requirements . . . . . . . . . . . . . . . . . . . 9 5.1. Data Name Uniqueness . . . . . . . . . . . . . . . . . . . 9 5.2. Data Object Size . . . . . . . . . . . . . . . . . . . . . 10 5.3. Data Object Attributes . . . . . . . . . . . . . . . . . . 10 5.4. Application-defined Object Properties and Metadata . . . . 11 6. Access and Authorization Requirements . . . . . . . . . . . . 11 6.1. Provider Access . . . . . . . . . . . . . . . . . . . . . 11 6.2. Secure Authorization . . . . . . . . . . . . . . . . . . . 11 6.3. Consumer Access . . . . . . . . . . . . . . . . . . . . . 12 6.4. Provider Authorization When Offline . . . . . . . . . . . 12 6.5. Local Authorization . . . . . . . . . . . . . . . . . . . 12 6.6. Access Control Granularity . . . . . . . . . . . . . . . . 12 6.7. Default Access Permissions . . . . . . . . . . . . . . . . 12 6.8. Connectivity Supporting NAT and Firewall Traversal . . . . 13 6.9. DECADE Server Discovery . . . . . . . . . . . . . . . . . 13 7. Data Transfer Requirements . . . . . . . . . . . . . . . . . . 13 7.1. Negotiable Standard Data Transport Protocol . . . . . . . 13 7.2. Atomic or Partial Read/Write . . . . . . . . . . . . . . . 14 7.3. Secure Data Transport . . . . . . . . . . . . . . . . . . 14 7.4. Concurrent Read . . . . . . . . . . . . . . . . . . . . . 14 7.5. Concurrent Write . . . . . . . . . . . . . . . . . . . . . 14 7.6. Read Before Write Complete . . . . . . . . . . . . . . . . 15 7.7. Redirection of Transport . . . . . . . . . . . . . . . . . 15 8. Resource Control Requirements . . . . . . . . . . . . . . . . 16 8.1. Multiple Applications Sharing Resources . . . . . . . . . 16 8.2. Per-Client Resource Policy . . . . . . . . . . . . . . . . 16 8.3. Distributed Resource Sharing Specification . . . . . . . . 16 8.4. Resource Set . . . . . . . . . . . . . . . . . . . . . . . 17 9. Error and Failure Handling Requirements . . . . . . . . . . . 17 Gu, et al. Expires January 7, 2013 [Page 3] Internet-Draft DECADE Requirements July 2012 9.1. Illegal Data Object . . . . . . . . . . . . . . . . . . . 17 9.2. Invalid Access Authorization . . . . . . . . . . . . . . . 18 9.3. Insufficient Resources . . . . . . . . . . . . . . . . . . 18 9.4. Attack Mitigation . . . . . . . . . . . . . . . . . . . . 18 10. Management Info Requirements . . . . . . . . . . . . . . . . . 19 10.1. Account Status . . . . . . . . . . . . . . . . . . . . . . 19 11. Security Considerations . . . . . . . . . . . . . . . . . . . 19 11.1. Authentication and Authorization . . . . . . . . . . . . . 19 11.2. Confidentiality . . . . . . . . . . . . . . . . . . . . . 19 11.3. Attack Mitigation . . . . . . . . . . . . . . . . . . . . 19 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 13.1. Normative References . . . . . . . . . . . . . . . . . . . 20 13.2. Informative References . . . . . . . . . . . . . . . . . . 20 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 Gu, et al. Expires January 7, 2013 [Page 4] Internet-Draft DECADE Requirements July 2012 1. Introduction The object of the DECoupled Application Data Enroute (DECADE) system is to provide an open and standard in-network storage for content distribution applications, where data is typically broken into one or more chunks and then distributed. This may already include many types of applications including P2P applications, IPTV (Internet Protocol Television), and VoD (Video on Demand). (For a precise definition of the applications targeted in DECADE system, see the definition for Target Application in Section 2.) Instead of always transferring data directly from a source/owner client to a requesting client, the source/owner client can write to and manage its content on its in-network storage. The requesting client can get the address of the in-network storage pertaining to the source/owner client and read data from the storage. This draft enumerates and explains the rationale behind specific requirements on the protocol design and on any data store implementation that may be used to implement DECADE servers that should be considered during the design and implementation of a DECADE-compatible system. As such, it does not include general guiding principles. General design considerations, explanation of the problem being addressed, and enumeration of the types of applications to which a DECADE-compatible system may be suited is not considered in this document. For general information, please see [I-D.ietf-decade-problem-statement] and [I-D.ietf-decade-arch]. This document enumerates the requirements to enable target applications to utilize in-network storage. In this context, using storage resources includes not only basic capabilities such as writing, reading, and managing data, but also controlling access for particular remote clients with which it is sharing data. Additionally, we also consider controlling the resources used by remote clients when they access data as an integral part of utilizing the network storage. This document discusses requirements pertaining to DECADE-compatible protocol(s). In certain deployments, several logical in-network storage systems could be deployed (e.g., within the same administrative domain). These in-network storage systems can communicate and transfer data through internal or non-standard communication messages that are outside of the scope of these requirements, but they should use DECADE-compatible protocol(s) when communicating with other DECADE-compatible in-network storage systems. Gu, et al. Expires January 7, 2013 [Page 5] Internet-Draft DECADE Requirements July 2012 2. Terminology This document uses the term 'In-network storage' which is defined in [I-D.ietf-decade-problem-statement]. This document also defines these additional terms: 2.1. DECADE-compatible Client A DECADE-compatible client uploads and/or retrieves data from DECADE- compatible servers. We use the shorter term "client" if there is no ambiguity. 2.2. DECADE-compatible Server A DECADE-compatible server stores data inside the network, and thereafter manages both the stored data and access to those data. We use the shorter term "server" if there is no ambiguity. 2.3. DECADE Storage Provider A DECADE Storage Provider, or Storage Provider for short, that deploys and/or manages DECADE-compatible server(s) within a network. 2.4. DECADE Account An account of a DECADE-compatible server has associated cryptographic credentials for access control, and resource allocation attributes on the server. 2.5. Provider A client which has the account cryptographic credentials of a DECADE account at a DECADE-compatible server. 2.6. Consumer A client which tries to access a DECADE account but does not have the account's cryptographic credentials. 2.7. Content Distribution Application A Content Distribution Application is an application (e.g., P2P, traditional CDN, or hybrid P2P/CDN) designed for dissemination of a large amounts of content (e.g., files, or video streams) to multiple content consumers. Content Distribution Applications may divide content into smaller blocks for dissemination. Gu, et al. Expires January 7, 2013 [Page 6] Internet-Draft DECADE Requirements July 2012 2.8. Target Application An application with that includes a DECADE-compatible client along with other application functionalities to explicitly control the usage of resources of DECADE-compatible servers to deliver content to other users. A primary type of Target Application we consider is Content Distribution Applications. A Target Application divides content into smaller blocks for more flexible distribution (e.g., over multiple application-level paths). We use the term Target Application to refer to the type of applications that are explicitly (but not exclusively) supported by DECADE system. 2.9. Application End-Point An Application End-Point is an instance of a Target Application. A particular Application End-Point might be a Content Provider, a Content Consumer, or both. For example, an Application End-Point might be an instance of a video streaming client, or it might be the source providing the video to a set of clients. 2.10. Data Object A data object is the unit of data stored and retrieved from a DECADE- compatible server. The data object is a string of raw bytes. The server maintains metadata associated with each data object, but the metadata is not included in the data object. 2.11. DECADE-compatible System A system which is composed of DECADE-compatible clients, DECADE- compatible servers and in-network storage. A DECADE-compatible system MUST obey all the requirements defined in this document. 2.12. DECADE Resource Protocol (DRP) A protocol that is responsible for communication of access control and resource scheduling policies from a DECADE client to a server, as well as between servers. 2.13. DECADE Standard Data Transfer Protocol (SDT) A protocol to be used to transfer data objects to and from a DECADE server. 3. System and Protocol Components Thus, to support such Target Applications, these behaviors must be Gu, et al. Expires January 7, 2013 [Page 7] Internet-Draft DECADE Requirements July 2012 logically separated from the data transfer operations (e.g., read, write).To organize the requirements, we consider that a DECADE- compatible system consists of two logical sets of functions, as shown in Figure 1. The first set of functions, which we refer to as the DECADE Resource Protocol (DRP), is responsible for communication of access control and resource scheduling policies from a client to a server, as well as between servers. A DECADE-compatible system will include exactly one DRP for interoperability and a common format through which these policies can be communicated. Native Application .-------------. Protocol(s) .-------------. | Application | <------------------> | Application | | End-Point | | End-Point | | | | | | .--------. | | .--------. | | | DECADE | | | | DECADE | | | | Client | | | | Client | | | `--------' | | `--------' | `-------------' `-------------' | ^ | ^ DECADE | | Standard | | Resource | | Data DRP | | SDT Protocol | | Transfer | | (DRP) | | (SDT) | | | | | | | | | | | | | | | | | | | | | | | | | | v V v V .=============. DRP .=============. | DECADE | <------------------> | DECADE | | Server | <------------------> | Server | `=============' SDT `=============' Figure 1: Protocol Components and Genenric Flow Second, the second set of functions, referred to as the Standard Data Transfer (SDT) protocol, will be used to transfer data objects to and from a server. A DECADE-compatible system may support multiple SDT's. If there are multiple SDT's, a negotiation mechanism will be used to determine a suitable SDT between the client and server. The two protocols (DRP and SDT) will be either separate or combined on the wire. If they are combined, DRP messages can be piggy-backed within some extension fields provided by certain SDT protocols. In Gu, et al. Expires January 7, 2013 [Page 8] Internet-Draft DECADE Requirements July 2012 such a scenario, DRP is technically a data structure (transported by other protocols), but it can still be considered as a logical protocol that provides the services of configuring DECADE-compatible resource usage. If the protocols are physically separate on the wire, DRP can take the form of a separate control connection open between the a DECADE-compatible client and server. Hence, this document considers SDT and DRP as two separate, logical functional components for clarity. 4. Requirements Structure This document specifies the requirements for the DECADE DRP and SDT protocols, either existing ones or new ones, and storage system to enable Target Applications to make use of storage within the network, leaving specific storage system considerations to the implementation of the storage servers as much as possible. For this reason, we consider two primary categories of requirements: o Protocol Requirements: Protocol requirements for Target Applications to make use of in-network storage within their own data dissemination schemes. Development of these requirements is guided by a study of data access, search and management capabilities used by Target Applications. These requirements may be met by a combination of existing protocols and new protocols. o Storage Requirements: Functional requirements necessary for the back-end storage system employed by the DECADE server. Development of these requirements is guided by a study of the data access patterns used by Target Applications. These requirements should be met by the underlying data transport used by DECADE system. In this document, we use "data transport" to refer to a protocol used to read and write data from in-network storage. This specification discusses the requirements of functionality implemented with a storage system and within applications, to permit interoperable communications concerning the manipulation of stored content. 5. Data Object Requirements 5.1. Data Name Uniqueness Gu, et al. Expires January 7, 2013 [Page 9] Internet-Draft DECADE Requirements July 2012 REQUIREMENT(S): Each Data Object should be named to allow access. DECADE-compatible protocol(s) MUST support a data object naming scheme that ensures a high probability of uniqueness, with no coordination among multiple Storage Providers. In other words, two Data Objects with the same name should be the same content with high probability. A DECADE-compatible server SHOULD be able to respond to a DECADE-compatible client with an error indicating potential name conflicts. RATIONALE: Although the intention of unique names is to avoid name collisions, it does not have to be an absolutely zero possibility. Hence, it is required to provide a collision handling mechanism. EXCEPTION: While a DECADE-compatible server is overloaded or consider a request as an attack, it does not to generate a response to indicate name collisions. 5.2. Data Object Size REQUIREMENT(S): DECADE MUST allow for efficient storage and data transfer of small data objects (e.g., 16KB) without large control overhead. RATIONALE: Though Target Applications are frequently used to share large amounts of data (e.g., continuous streams or large files), the data itself is typically subdivided into smaller data objects (chunks) for flexibility (e.g., reliability and multi-path transmission). 5.3. Data Object Attributes REQUIREMENT(S): DECADE MUST support the ability to associate a set of system attributes with a data object with a scope local to a DECADE-compatible server. In particular, the set MUST include time-to-live (or expiration time), creation timestamp, object size, and object type. A DECADE-compatible client, with access permission, MUST be able to query the set of system attributes. The transmission of the attributes MUST use an operating system- independent and architecture-independent standard format. An ability to extend the set of attributes MUST exist. RATIONALE: The values of attributes associated with a data object are local to a particular DECADE-compatible server. These attributes may be used as hints to the storage system, internal optimizations, or as additional information query-able by DECADE- compatible clients. The particular requirement for including time-to-live (TTL) is that a data object written by a DECADE- Gu, et al. Expires January 7, 2013 [Page 10] Internet-Draft DECADE Requirements July 2012 compatible client may be usable only within a certain window of time, such as in a live-streaming P2P application. Providing a time-to-live value for a data object (e.g., at the time it is written) can reduce management overhead by avoiding many 'delete' commands sent to DECADE-compatible server. The server may still retain a data object for bandwidth optimization, but this should be guided by the privacy policy of the DECADE Storage Provider. 5.4. Application-defined Object Properties and Metadata REQUIREMENT(S): DECADE-compatible clients and DECADE-compatible servers MUST NOT be able to associate Application-defined properties (metadata) with data objects beyond what is provided by Section 5.3. RATIONALE: Associating key-value pairs that are defined by Target Applications with data objects introduces substantial complexity. If Target Applications wish to associate additional metadata with a data object, possible alternatives include (1) managing such metadata within the Target Application itself, (2) storing metadata inside the data object, or (3) storing metadata in a different data object at the DECADE-compatible server. 6. Access and Authorization Requirements 6.1. Provider Access REQUIREMENT(S): A Provider MUST be able to access the resources of its account. RATIONALE: After a DECADE-compatible client that owns an account on a DECADE-compatible server should be able to read data from and write data to the server. 6.2. Secure Authorization REQUIREMENT(S): Access authorization by a client to an account on a server MUST be based on cryptographic security. RATIONALE: DECADE-compatible clients may be operating on hosts without constant network connectivity or without a permanent attachment address (e.g., mobile devices). To support access control with such hosts, DECADE-compatible servers must support access control policies that use cryptographic credentials, not simply by tying access to IP addresses. Gu, et al. Expires January 7, 2013 [Page 11] Internet-Draft DECADE Requirements July 2012 6.3. Consumer Access REQUIREMENT(S): A Provider MUST be able to indicate to its server on whether a Consumer can access its subscribed resources. RATIONALE: Endpoints in Target Applications may choose different servers. Thus, to be useful by Target Applications, a DECADE- compatible client must be able to specify policies on whether other DECADE-compatible clients can access its resoutces. The other clients may or may not be known to the server. 6.4. Provider Authorization When Offline REQUIREMENT(S): A Provider MUST be able to grant access to a Consumer even if the Provider is not actively running or connected to its DECADE-compatible server. RATIONALE: If an application desires, it can authorize other clients to access its storage even after the application exits or network connectivity is lost. An example use case is mobile scenarios, where a client can lose and regain network connectivity often. 6.5. Local Authorization REQUIREMENT(S): A Provider MUST be able to indicate, without contacting its server, access control policies for Consumers. DECADE-compatible server MUST be able to authenticate the access control policies in this situation. RATIONALE: This requirement is related with the preceding requirement, but in a perspective (i.e., protocol design). See discussions in Section 8.3. 6.6. Access Control Granularity REQUIREMENT(S): A Provider MUST be able to control which individual clients are authorized to read/write which particular data objects from/to its in-network storage. RATIONALE: A Target Application should able to conduct access control on the granularity of individual clients, individual data objects. 6.7. Default Access Permissions Gu, et al. Expires January 7, 2013 [Page 12] Internet-Draft DECADE Requirements July 2012 REQUIREMENT(S): Unless read or write access is granted by a Provider, the default permission MUST be no access. RATIONALE: This requirement is to protect client privacy by default. 6.8. Connectivity Supporting NAT and Firewall Traversal REQUIREMENT(S): A client that is authorized to access a server MUST be supported to conduct NAT (Network Address Translation) and firewall traversal. In particular, network connections between a DECADE-compatible client and a DECADE-compatible server MUST be initiated by the client (i.e., the server must not initiate a connection to the client). RATIONALE: Firewalls and NATs are widely used in the Internet today, both in ISP (Internet Service Provider) and Enterprise networks and by consumers. Many firewalls and NATs are configured by default to block incoming connections, which helps to mitigate security risks. Deployment of a DECADE-compatible system must not require manual modifications to such devices. This requirement applies to both potential new protocol that may be developed by the DECADE Working Group and any data transport used with DECADE protocol. 6.9. DECADE Server Discovery REQUIREMENT(S): A mechanism for a Provider to discover and connect to its assigned server MUST be supported. The disovery SHOULD leverage existing mechanisms and protocols wherever possible. No new discovery mechanism will be defined unless there is enough evidence that no existing mechanism can work. RATIONALE: Existing protocols such as DNS and DHCP are widespread. Using existing protocols, or combinations of the protocols that have been specified in other contexts, is strictly preferred over developing a new discovery protocol. 7. Data Transfer Requirements 7.1. Negotiable Standard Data Transport Protocol REQUIREMENT(S): A DECADE-compatible client MUST be able to negotiate with a DECADE-compatible server about which protocol it can use to read data from and write data. DECADE MUST specify at least one mandatory transport protocol to be supported by implementations; usage of a different protocol may be selected via negotiation. Gu, et al. Expires January 7, 2013 [Page 13] Internet-Draft DECADE Requirements July 2012 RATIONALE: Since typical data transport protocols (e.g., NFS and WebDAV) already provide read and write operations for network storage, it may not be necessary to define such operations in a new DECADE protocol. However, because of the particular application requirements and deployment considerations, different applications may support different protocols. Thus, a DECADE client must be able to select an appropriate protocol also supported by the in-network storage. 7.2. Atomic or Partial Read/Write REQUIREMENT(S): A DECADE-compatible server MUST support the ability to read/write a complete data object in one request. It MAY support range read/write. RATIONALE: Depending on the object size (e.g., chunk size) used by a Target Application, the application may need to send data to the DECADE-compatible server in multiple round. 7.3. Secure Data Transport REQUIREMENT(S): A secure transport MUST be implemented for all communications between a DECADE-compatible client and DECADE- compatible server. RATIONALE: Target Applications may wish to write sensitive data. To satisfy this use case, the communication between a DECADE- compatible client and DECADE-compatible server must be transported over a secure transport protocol (e.g., SSL/TLS). 7.4. Concurrent Read REQUIREMENT(S): A DECADE-compatible server MUST allow for multiple simultaneous readers for a data object. RATIONALE: One characteristic of Target Applications is the ability to upload an object to multiple clients. Thus, it is natural for DECADE-compatible server to allow multiple readers to read the same object concurrently. 7.5. Concurrent Write REQUIREMENT(S): A DECADE-compatible server MUST NOT allow multiple simultaneous writers for the same object. A DECADE-compatible server SHOULD respond to each of the writers with an error. Gu, et al. Expires January 7, 2013 [Page 14] Internet-Draft DECADE Requirements July 2012 RATIONALE: This avoids data corruption in a simple way while remaining efficient. Alternately, the DECADE-compatible server would need to either manage locking, handle write collisions, or merge data, all of which reduce efficiency and increase complexity. EXCEPTION: While a DECADE-compatible server is overloaded or considers a request as an attack, it does not enerate a response. 7.6. Read Before Write Complete REQUIREMENT(S): A DECADE-compatible server MAY allow readers to read a data object before it has been completely written. In case of a write error in such a case, the DECADE-compatible server SHOULD respond to the reading client with an error indicating that the write has failed. RATIONALE: Some Target Applications (in particular, P2P streaming) can be sensitive to latency. A technique to reduce latency is to remove store-and-forward delays for data objects (e.g., make the object available before it is completely written). Appropriate handling for error conditions (e.g., a disappearing writer) needs to be specified. EXCEPTION: While a DECADE-compatible server is overloaded or considers a request as an attack, it does not generate a response. 7.7. Redirection of Transport REQUIREMENT(S): A DECADE-compatible server SHOULD be able to redirect requests to another DECADE-compatible server. This may either be in response to an error, failure, overload, or to support capabilities such as load balancing. RATIONALE: A DECADE-compatible server may opt to redirect requests to another server to support capabilities such as load balancing, or if the implementation decides that another DECADE-compatible server is in a better position to handle the request due to either its location in the network, server status, or other consideration. EXCEPTION: A DECADE-compatible server can be configured by its service provider to support or not support redirection functionality. Gu, et al. Expires January 7, 2013 [Page 15] Internet-Draft DECADE Requirements July 2012 8. Resource Control Requirements 8.1. Multiple Applications Sharing Resources REQUIREMENT(S): A user MUST be able to indicate to a DECADE- compatible server about resource sharing policies among multiple Target Applications being run/managed by the same user. RATIONALE: A user owning a DECADE account may provide the account's cryptographic credentials to multiple Providers of multiple target applications. For example, the user may run one or more video-on-demand application(s) and a live-streaming application(s) which both make use of the user's in-network storage. The concurrently running applications may be running on different machines (e.g., multiple machines at the same home network) and may not directly communicate, except through user coordination 8.2. Per-Client Resource Policy REQUIREMENT(S): A Provider MUST be able to specify resource policies (bandwidth share, storage quota, and network connection quota) to individual Consumers for reading from and writing data to its in- network storage within a particular range of time. RATIONALE: Target Applications can rely on control of resources on a per-client basis. For example, application policy may indicate that certain remote clients have a higher bandwidth share for receiving data [LLSB08]. Additionally, bandwidth share for receiving data [LLSB08]. Additionally, certain data (e.g., chunks) may be distributed with a higher priority. As another example, when allowing a remote client to write data to a user's in-network storage, the remote client may be restricted to write less than 100MB of data in total. Since the client may need to manage multiple clients accessing its data, it should be able to indicate the time over which the granted resources are usable. For example, an expiration time for the access could be indicated to the DECADE-compatible server after which no resources are granted (e.g., indicate error as access denied). 8.3. Distributed Resource Sharing Specification REQUIREMENT(S): A Provider MUST be able to indicate to its DECADE- compatible server, without itself contacting the server, resource control policies for a Consumer. The DECADE-compatible server MUST be able to authenticate the resource control policies. Gu, et al. Expires January 7, 2013 [Page 16] Internet-Draft DECADE Requirements July 2012 RATIONALE: One important consideration for a DECADE-compatible server is scalability, since a single storage element may be used to support many users. Many Target Applications use small chunk sizes and frequent data exchanges. If such an application employed resource control and contacted the DECADE-compatible server for each data exchange, this could present a scalability challenge for the server as well as additional latency for clients. The preferred way is to let requesting clients obtain signed resource control policies (in the form of a token) from the owning client, and then requesting clients can present the policy to a DECADE-compatible server directly. This can result in reduced messaging handled by the DECADE-compatible server. 8.4. Resource Set REQUIREMENT(S): A DECADE-compatible server MUST allow specification on the following resources: stoarge, bandwidth, and number of connections, and MAY allow additional types of resources to be specified. RATIONALE: The minimum set of resources need to include the most common resources. 9. Error and Failure Handling Requirements 9.1. Illegal Data Object REQUIREMENT(S): A DECADE-compatible server SHOULD provide an error indicating that (1) data was rejected from being written, (2) deleted, or (3) marked unavailable. RATIONALE: DECADE Storage Providers may require the ability to (1) avoid storing, (2) delete, or (3) quarantine certain data that has been identified as illegal (or otherwise prohibited). It is not specified how such data is identified, but applications employing DECADE-compatible servers should not break if a Storage Provider is obligated to enforce such policies. Appropriate error conditions should be indicated to applications. EXCEPTION: A DECADE-compatible server should be able to be configured to suppress Illegal Data Object responses for security reasons. Gu, et al. Expires January 7, 2013 [Page 17] Internet-Draft DECADE Requirements July 2012 9.2. Invalid Access Authorization REQUIREMENT(S): A DECADE-compatible server SHOULD provide an error indicating that the request does not have a valid access authorization. RATIONALE: DECADE-compatible clients may request data objects to which they do not have a valid authorization, and DECADE- compatible servers should be able to signal that this has occurred. Invalid authorization may be due to a combination of credential issues as well as additional policies defined by a Storage Provider. EXCEPTION: A DECADE-compatible server should be able to be configured to suppress Invalid Authorization responses for security reasons. 9.3. Insufficient Resources REQUIREMENT(S): A DECADE-compatible server SHOULD provide a response indicating to a DECADE-compatible client that resources (e.g., storage space) were not available to service its request (e.g., storage quota exceeded when attempting to write data). RATIONALE: The Insufficient Resources response allows a client to back off, free up necessary resources or waiting for such resources to be freed. EXCEPTION: A DECADE-compatible server may not provide such a response if doing so increases the load or due to security concerns. 9.4. Attack Mitigation REQUIREMENT(S): A DECADE-compatible server MUST be permitted to reject suspicious requests and not be required to generate responses (e.g., if a client's rate of requests exceeds a pre- defined threshold). RATIONALE: Malicious clients may attempt to attack a DECADE- compatible server by specifying many chunks to increase total throughput or inciting overload conditions. A DECADE-compatible server is permitted to reject or ignore requests that are deemed suspicious according to policies set by its DECADE service provider. Gu, et al. Expires January 7, 2013 [Page 18] Internet-Draft DECADE Requirements July 2012 10. Management Info Requirements 10.1. Account Status REQUIREMENT(S): A Provider MUST be able to query the resource quota as well the current usage. The response from the server MUST include resource usage resulting from both the client's own usage and usage by other clients that have been authorized to read/ write objects on that client's account. RATIONALE: The resources used by a client are not necessarily directly-attached (e.g., disk, network interface, etc). Thus, the client cannot locally determine how much resources are being used. Before storing and retrieving data, a client should be able to determine which data is available (e.g., after an application restart). 11. Security Considerations The security model is an important component of a DECADE-compatible system. It is crucial for users to be able to manage and limit distribution of content to only authorized parties, and the mechanism needs to work on the general Internet which spans multiple administrative and security domains. Previous sections have enumerated detailed requirements, but this section discusses the overall approach and other considerations that do not merit requirements. 11.1. Authentication and Authorization A DECADE-compatible server must validate an request to access the in- network storage. 11.2. Confidentiality DECADE-compatible Servers provide the ability to write raw data objects (subject to any policies instituted by the owner/ administrator of the Storage Provider). Thus, DECADE-compatible clients may opt to encrypt data before it is transported to the server. 11.3. Attack Mitigation The particular resource control policy may be open to certain attacks by clients. For example by specifying many small chunks to increase total throughput or inciting overload conditions are techniques that may be used by a client. Gu, et al. Expires January 7, 2013 [Page 19] Internet-Draft DECADE Requirements July 2012 12. IANA Considerations There are no IANA considerations with this document. 13. References 13.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [I-D.ietf-decade-problem-statement] Song, H., Zong, N., Yang, Y., and R. Alimi, "DECoupled Application Data Enroute (DECADE) Problem Statement", draft-ietf-decade-problem-statement-03 (work in progress), March 2011. 13.2. Informative References [I-D.ietf-decade-arch] Alimi, R., Yang, Y., Rahman, A., Kutscher, D., and H. Liu, "DECADE Architecture", draft-ietf-decade-arch-02 (work in progress), July 2011. [LLSB08] Levin, D., LaCurts, K., Spring, N., and B. Bhattacharjee, "BitTorrent is an Auction: Analyzing and Improving BitTorrent's Incentives", SIGCOMM 2008, August 2008. [PPLive] "PPLive", . Appendix A. Acknowledgments We would also like to thank Haibin Song for substantial contributions to earlier versions of this document. We would also like to thank Reinaldo Penno, Alexey Melnikov, Rich Woundy, Ning Zong, Roni Even, David McDysan, Borje Ohlman, Dirk Kutscher, Akbar Rahman, Xiao Zhu, Yunfei Zhang, and Jin Peng for contributions and general feedback. Gu, et al. Expires January 7, 2013 [Page 20] Internet-Draft DECADE Requirements July 2012 Authors' Addresses Yingjie Gu Huawei No. 101 Software Avenue Nanjing, Jiangsu Province 210012 P.R.China Phone: +86-25-56624760 Email: guyingjie@huawei.com David A. Bryan Polycom, Inc. Email: dbryan@ethernot.org Yang Richard Yang Yale University Email: yry@cs.yale.edu Richard Alimi Google Email: ralimi@google.com Gu, et al. Expires January 7, 2013 [Page 21] --------------050204020004060507090201 Content-Type: text/xml; name="draft-ietf-decade-reqs-all_v06.xml" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="draft-ietf-decade-reqs-all_v06.xml" ]> DECADE Requirements Huawei
No. 101 Software Avenue Nanjing Jiangsu Province 210012 P.R.China +86-25-56624760 guyingjie@huawei.com
Polycom, Inc.
dbryan@ethernot.org
Yale University
yry@cs.yale.edu
Google
ralimi@google.com
Applications Area DECADE In-network storage P2P CDN Video on Demand VoD The target of the DECoupled Application Data Enroute (DECADE) system 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-compatible 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 a DECADE-compatible system architecture includes all of the desired functionality for intended applications. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in .
The object of the DECoupled Application Data Enroute (DECADE) system is to provide an open and standard in-network storage for content distribution applications, where data is typically broken into one or more chunks and then distributed. This may already include many types of applications including P2P applications, IPTV (Internet Protocol Television), and VoD (Video on Demand). (For a precise definition of the applications targeted in DECADE system, see the definition for Target Application in .) Instead of always transferring data directly from a source/owner client to a requesting client, the source/owner client can write to and manage its content on its in-network storage. The requesting client can get the address of the in-network storage pertaining to the source/owner client and read data from the storage. This draft enumerates and explains the rationale behind specific requirements on the protocol design and on any data store implementation that may be used to implement DECADE servers that should be considered during the design and implementation of a DECADE-compatible system. As such, it does not include general guiding principles. General design considerations, explanation of the problem being addressed, and enumeration of the types of applications to which a DECADE-compatible system may be suited is not considered in this document. For general information, please see and . This document enumerates the requirements to enable target applications to utilize in-network storage. In this context, using storage resources includes not only basic capabilities such as writing, reading, and managing data, but also controlling access for particular remote clients with which it is sharing data. Additionally, we also consider controlling the resources used by remote clients when they access data as an integral part of utilizing the network storage. This document discusses requirements pertaining to DECADE-compatible protocol(s). In certain deployments, several logical in-network storage systems could be deployed (e.g., within the same administrative domain). These in-network storage systems can communicate and transfer data through internal or non-standard communication messages that are outside of the scope of these requirements, but they should use DECADE-compatible protocol(s) when communicating with other DECADE-compatible in-network storage systems.
This document uses the term 'In-network storage' which is defined in . This document also defines these additional terms:
A DECADE-compatible client uploads and/or retrieves data from DECADE-compatible servers. We use the shorter term "client" if there is no ambiguity.
A DECADE-compatible server stores data inside the network, and thereafter manages both the stored data and access to those data. We use the shorter term "server" if there is no ambiguity.
A DECADE Storage Provider, or Storage Provider for short, that deploys and/or manages DECADE-compatible server(s) within a network.
An account of a DECADE-compatible server has associated cryptographic credentials for access control, and resource allocation attributes on the server.
A client which has the account cryptographic credentials of a DECADE account at a DECADE-compatible server.
A client which tries to access a DECADE account but does not have the account's cryptographic credentials.
A Content Distribution Application is an application (e.g., P2P, traditional CDN, or hybrid P2P/CDN) designed for dissemination of a large amounts of content (e.g., files, or video streams) to multiple content consumers. Content Distribution Applications may divide content into smaller blocks for dissemination.
An application with that includes a DECADE-compatible client along with other application functionalities to explicitly control the usage of resources of DECADE-compatible servers to deliver content to other users. A primary type of Target Application we consider is Content Distribution Applications. A Target Application divides content into smaller blocks for more flexible distribution (e.g., over multiple application-level paths). We use the term Target Application to refer to the type of applications that are explicitly (but not exclusively) supported by DECADE system.
An Application End-Point is an instance of a Target Application. A particular Application End-Point might be a Content Provider, a Content Consumer, or both. For example, an Application End-Point might be an instance of a video streaming client, or it might be the source providing the video to a set of clients.
A data object is the unit of data stored and retrieved from a DECADE-compatible server. The data object is a string of raw bytes. The server maintains metadata associated with each data object, but the metadata is not included in the data object.
A system which is composed of DECADE-compatible clients, DECADE-compatible servers and in-network storage. A DECADE-compatible system MUST obey all the requirements defined in this document.
A protocol that is responsible for communication of access control and resource scheduling policies from a DECADE client to a server, as well as between servers.
A protocol to be used to transfer data objects to and from a DECADE server.
Thus, to support such Target Applications, these behaviors must be logically separated from the data transfer operations (e.g., read, write).To organize the requirements, we consider that a DECADE-compatible system consists of two logical sets of functions, as shown in . The first set of functions, which we refer to as the DECADE Resource Protocol (DRP), is responsible for communication of access control and resource scheduling policies from a client to a server, as well as between servers. A DECADE-compatible system will include exactly one DRP for interoperability and a common format through which these policies can be communicated.
Native Application .-------------. Protocol(s) .-------------. | Application | <------------------> | Application | | End-Point | | End-Point | | | | | | .--------. | | .--------. | | | DECADE | | | | DECADE | | | | Client | | | | Client | | | `--------' | | `--------' | `-------------' `-------------' | ^ | ^ DECADE | | Standard | | Resource | | Data DRP | | SDT Protocol | | Transfer | | (DRP) | | (SDT) | | | | | | | | | | | | | | | | | | | | | | | | | | v V v V .=============. DRP .=============. | DECADE | <------------------> | DECADE | | Server | <------------------> | Server | `=============' SDT `============='
Second, the second set of functions, referred to as the Standard Data Transfer (SDT) protocol, will be used to transfer data objects to and from a server. A DECADE-compatible system may support multiple SDT's. If there are multiple SDT's, a negotiation mechanism will be used to determine a suitable SDT between the client and server. The two protocols (DRP and SDT) will be either separate or combined on the wire. If they are combined, DRP messages can be piggy-backed within some extension fields provided by certain SDT protocols. In such a scenario, DRP is technically a data structure (transported by other protocols), but it can still be considered as a logical protocol that provides the services of configuring DECADE-compatible resource usage. If the protocols are physically separate on the wire, DRP can take the form of a separate control connection open between the a DECADE-compatible client and server. Hence, this document considers SDT and DRP as two separate, logical functional components for clarity.
This document specifies the requirements for the DECADE DRP and SDT protocols, either existing ones or new ones, and storage system to enable Target Applications to make use of storage within the network, leaving specific storage system considerations to the implementation of the storage servers as much as possible. For this reason, we consider two primary categories of requirements: Protocol Requirements: Protocol requirements for Target Applications to make use of in-network storage within their own data dissemination schemes. Development of these requirements is guided by a study of data access, search and management capabilities used by Target Applications. These requirements may be met by a combination of existing protocols and new protocols. Storage Requirements: Functional requirements necessary for the back-end storage system employed by the DECADE server. Development of these requirements is guided by a study of the data access patterns used by Target Applications. These requirements should be met by the underlying data transport used by DECADE system. In this document, we use "data transport" to refer to a protocol used to read and write data from in-network storage. This specification discusses the requirements of functionality implemented with a storage system and within applications, to permit interoperable communications concerning the manipulation of stored content.
Each Data Object should be named to allow access. DECADE-compatible protocol(s) MUST support a data object naming scheme that ensures a high probability of uniqueness, with no coordination among multiple Storage Providers. In other words, two Data Objects with the same name should be the same content with high probability. A DECADE-compatible server SHOULD be able to respond to a DECADE-compatible client with an error indicating potential name conflicts. Although the intention of unique names is to avoid name collisions, it does not have to be an absolutely zero possibility. Hence, it is required to provide a collision handling mechanism. While a DECADE-compatible server is overloaded or consider a request as an attack, it does not to generate a response to indicate name collisions.
DECADE MUST allow for efficient storage and data transfer of small data objects (e.g., 16KB) without large control overhead. Though Target Applications are frequently used to share large amounts of data (e.g., continuous streams or large files), the data itself is typically subdivided into smaller data objects (chunks) for flexibility (e.g., reliability and multi-path transmission).
DECADE MUST support the ability to associate a set of system attributes with a data object with a scope local to a DECADE-compatible server. In particular, the set MUST include time-to-live (or expiration time), creation timestamp, object size, and object type. A DECADE-compatible client, with access permission, MUST be able to query the set of system attributes. The transmission of the attributes MUST use an operating system-independent and architecture-independent standard format. An ability to extend the set of attributes MUST exist. The values of attributes associated with a data object are local to a particular DECADE-compatible server. These attributes may be used as hints to the storage system, internal optimizations, or as additional information query-able by DECADE-compatible clients. The particular requirement for including time-to-live (TTL) is that a data object written by a DECADE-compatible client may be usable only within a certain window of time, such as in a live-streaming P2P application. Providing a time-to-live value for a data object (e.g., at the time it is written) can reduce management overhead by avoiding many 'delete' commands sent to DECADE-compatible server. The server may still retain a data object for bandwidth optimization, but this should be guided by the privacy policy of the DECADE Storage Provider.
DECADE-compatible clients and DECADE-compatible servers MUST NOT be able to associate Application-defined properties (metadata) with data objects beyond what is provided by . Associating key-value pairs that are defined by Target Applications with data objects introduces substantial complexity. If Target Applications wish to associate additional metadata with a data object, possible alternatives include (1) managing such metadata within the Target Application itself, (2) storing metadata inside the data object, or (3) storing metadata in a different data object at the DECADE-compatible server.
A Provider MUST be able to access the resources of its account. After a DECADE-compatible client that owns an account on a DECADE-compatible server should be able to read data from and write data to the server.
Access authorization by a client to an account on a server MUST be based on cryptographic security. DECADE-compatible clients may be operating on hosts without constant network connectivity or without a permanent attachment address (e.g., mobile devices). To support access control with such hosts, DECADE-compatible servers must support access control policies that use cryptographic credentials, not simply by tying access to IP addresses.
A Provider MUST be able to indicate to its server on whether a Consumer can access its subscribed resources. Endpoints in Target Applications may choose different servers. Thus, to be useful by Target Applications, a DECADE-compatible client must be able to specify policies on whether other DECADE-compatible clients can access its resoutces. The other clients may or may not be known to the server.
A Provider MUST be able to grant access to a Consumer even if the Provider is not actively running or connected to its DECADE-compatible server. If an application desires, it can authorize other clients to access its storage even after the application exits or network connectivity is lost. An example use case is mobile scenarios, where a client can lose and regain network connectivity often.
A Provider MUST be able to indicate, without contacting its server, access control policies for Consumers. DECADE-compatible server MUST be able to authenticate the access control policies in this situation. This requirement is related with the preceding requirement, but in a perspective (i.e., protocol design). See discussions in .
A Provider MUST be able to control which individual clients are authorized to read/write which particular data objects from/to its in-network storage. A Target Application should able to conduct access control on the granularity of individual clients, individual data objects.
Unless read or write access is granted by a Provider, the default permission MUST be no access. This requirement is to protect client privacy by default.
A client that is authorized to access a server MUST be supported to conduct NAT (Network Address Translation) and firewall traversal. In particular, network connections between a DECADE-compatible client and a DECADE-compatible server MUST be initiated by the client (i.e., the server must not initiate a connection to the client). Firewalls and NATs are widely used in the Internet today, both in ISP (Internet Service Provider) and Enterprise networks and by consumers. Many firewalls and NATs are configured by default to block incoming connections, which helps to mitigate security risks. Deployment of a DECADE-compatible system must not require manual modifications to such devices. This requirement applies to both potential new protocol that may be developed by the DECADE Working Group and any data transport used with DECADE protocol.
A mechanism for a Provider to discover and connect to its assigned server MUST be supported. The disovery SHOULD leverage existing mechanisms and protocols wherever possible. No new discovery mechanism will be defined unless there is enough evidence that no existing mechanism can work. Existing protocols such as DNS and DHCP are widespread. Using existing protocols, or combinations of the protocols that have been specified in other contexts, is strictly preferred over developing a new discovery protocol.
A DECADE-compatible client MUST be able to negotiate with a DECADE-compatible server about which protocol it can use to read data from and write data. DECADE MUST specify at least one mandatory transport protocol to be supported by implementations; usage of a different protocol may be selected via negotiation. Since typical data transport protocols (e.g., NFS and WebDAV) already provide read and write operations for network storage, it may not be necessary to define such operations in a new DECADE protocol. However, because of the particular application requirements and deployment considerations, different applications may support different protocols. Thus, a DECADE client must be able to select an appropriate protocol also supported by the in-network storage.
A DECADE-compatible server MUST support the ability to read/write a complete data object in one request. It MAY support range read/write. Depending on the object size (e.g., chunk size) used by a Target Application, the application may need to send data to the DECADE-compatible server in multiple round.
A secure transport MUST be implemented for all communications between a DECADE-compatible client and DECADE-compatible server. Target Applications may wish to write sensitive data. To satisfy this use case, the communication between a DECADE-compatible client and DECADE-compatible server must be transported over a secure transport protocol (e.g., SSL/TLS).
A DECADE-compatible server MUST allow for multiple simultaneous readers for a data object. One characteristic of Target Applications is the ability to upload an object to multiple clients. Thus, it is natural for DECADE-compatible server to allow multiple readers to read the same object concurrently.
A DECADE-compatible server MUST NOT allow multiple simultaneous writers for the same object. A DECADE-compatible server SHOULD respond to each of the writers with an error. This avoids data corruption in a simple way while remaining efficient. Alternately, the DECADE-compatible server would need to either manage locking, handle write collisions, or merge data, all of which reduce efficiency and increase complexity. While a DECADE-compatible server is overloaded or considers a request as an attack, it does not enerate a response.
A DECADE-compatible server MAY allow readers to read a data object before it has been completely written. In case of a write error in such a case, the DECADE-compatible server SHOULD respond to the reading client with an error indicating that the write has failed. Some Target Applications (in particular, P2P streaming) can be sensitive to latency. A technique to reduce latency is to remove store-and-forward delays for data objects (e.g., make the object available before it is completely written). Appropriate handling for error conditions (e.g., a disappearing writer) needs to be specified. While a DECADE-compatible server is overloaded or considers a request as an attack, it does not generate a response.
A DECADE-compatible server SHOULD be able to redirect requests to another DECADE-compatible server. This may either be in response to an error, failure, overload, or to support capabilities such as load balancing. A DECADE-compatible server may opt to redirect requests to another server to support capabilities such as load balancing, or if the implementation decides that another DECADE-compatible server is in a better position to handle the request due to either its location in the network, server status, or other consideration. A DECADE-compatible server can be configured by its service provider to support or not support redirection functionality.
A user MUST be able to indicate to a DECADE-compatible server about resource sharing policies among multiple Target Applications being run/managed by the same user. A user owning a DECADE account may provide the account's cryptographic credentials to multiple Providers of multiple target applications. For example, the user may run one or more video-on-demand application(s) and a live-streaming application(s) which both make use of the user's in-network storage. The concurrently running applications may be running on different machines (e.g., multiple machines at the same home network) and may not directly communicate, except through user coordination
A Provider MUST be able to specify resource policies (bandwidth share, storage quota, and network connection quota) to individual Consumers for reading from and writing data to its in-network storage within a particular range of time. Target Applications can rely on control of resources on a per-client basis. For example, application policy may indicate that certain remote clients have a higher bandwidth share for receiving data . Additionally, bandwidth share for receiving data [LLSB08]. Additionally, certain data (e.g., chunks) may be distributed with a higher priority. As another example, when allowing a remote client to write data to a user's in-network storage, the remote client may be restricted to write less than 100MB of data in total. Since the client may need to manage multiple clients accessing its data, it should be able to indicate the time over which the granted resources are usable. For example, an expiration time for the access could be indicated to the DECADE-compatible server after which no resources are granted (e.g., indicate error as access denied).
A Provider MUST be able to indicate to its DECADE-compatible server, without itself contacting the server, resource control policies for a Consumer. The DECADE-compatible server MUST be able to authenticate the resource control policies. One important consideration for a DECADE-compatible server is scalability, since a single storage element may be used to support many users. Many Target Applications use small chunk sizes and frequent data exchanges. If such an application employed resource control and contacted the DECADE-compatible server for each data exchange, this could present a scalability challenge for the server as well as additional latency for clients. The preferred way is to let requesting clients obtain signed resource control policies (in the form of a token) from the owning client, and then requesting clients can present the policy to a DECADE-compatible server directly. This can result in reduced messaging handled by the DECADE-compatible server.
A DECADE-compatible server MUST allow specification on the following resources: stoarge, bandwidth, and number of connections, and MAY allow additional types of resources to be specified. The minimum set of resources need to include the most common resources.
A DECADE-compatible server SHOULD provide an error indicating that (1) data was rejected from being written, (2) deleted, or (3) marked unavailable. DECADE Storage Providers may require the ability to (1) avoid storing, (2) delete, or (3) quarantine certain data that has been identified as illegal (or otherwise prohibited). It is not specified how such data is identified, but applications employing DECADE-compatible servers should not break if a Storage Provider is obligated to enforce such policies. Appropriate error conditions should be indicated to applications. A DECADE-compatible server should be able to be configured to suppress Illegal Data Object responses for security reasons.
A DECADE-compatible server SHOULD provide an error indicating that the request does not have a valid access authorization. DECADE-compatible clients may request data objects to which they do not have a valid authorization, and DECADE-compatible servers should be able to signal that this has occurred. Invalid authorization may be due to a combination of credential issues as well as additional policies defined by a Storage Provider. A DECADE-compatible server should be able to be configured to suppress Invalid Authorization responses for security reasons.
A DECADE-compatible server SHOULD provide a response indicating to a DECADE-compatible client that resources (e.g., storage space) were not available to service its request (e.g., storage quota exceeded when attempting to write data). The Insufficient Resources response allows a client to back off, free up necessary resources or waiting for such resources to be freed. A DECADE-compatible server may not provide such a response if doing so increases the load or due to security concerns.
A DECADE-compatible server MUST be permitted to reject suspicious requests and not be required to generate responses (e.g., if a client's rate of requests exceeds a pre-defined threshold). Malicious clients may attempt to attack a DECADE-compatible server by specifying many chunks to increase total throughput or inciting overload conditions. A DECADE-compatible server is permitted to reject or ignore requests that are deemed suspicious according to policies set by its DECADE service provider.
A Provider MUST be able to query the resource quota as well the current usage. The response from the server MUST include resource usage resulting from both the client's own usage and usage by other clients that have been authorized to read/write objects on that client's account. The resources used by a client are not necessarily directly-attached (e.g., disk, network interface, etc). Thus, the client cannot locally determine how much resources are being used. Before storing and retrieving data, a client should be able to determine which data is available (e.g., after an application restart).
The security model is an important component of a DECADE-compatible system. It is crucial for users to be able to manage and limit distribution of content to only authorized parties, and the mechanism needs to work on the general Internet which spans multiple administrative and security domains. Previous sections have enumerated detailed requirements, but this section discusses the overall approach and other considerations that do not merit requirements.
A DECADE-compatible server must validate an request to access the in-network storage.
DECADE-compatible Servers provide the ability to write raw data objects (subject to any policies instituted by the owner/administrator of the Storage Provider). Thus, DECADE-compatible clients may opt to encrypt data before it is transported to the server.
The particular resource control policy may be open to certain attacks by clients. For example by specifying many small chunks to increase total throughput or inciting overload conditions are techniques that may be used by a client.
There are no IANA considerations with this document.
&RFC2119; &decadeproblem; &decadearch; BitTorrent is an Auction: Analyzing and Improving BitTorrent's Incentives PPLive --------------050204020004060507090201-- From pzhang.thu@gmail.com Sat Jul 7 21:17:29 2012 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 70BA021F85AA for ; Sat, 7 Jul 2012 21:17:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 A7Z9GAbvnl-d for ; Sat, 7 Jul 2012 21:17:28 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3DDD921F85B6 for ; Sat, 7 Jul 2012 21:17:28 -0700 (PDT) Received: by qcac10 with SMTP id c10so5658124qca.31 for ; Sat, 07 Jul 2012 21:17:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer; bh=r7euKtMIlhE34464iALlxeN3xW8vKnOlkIk4rXyhEzQ=; b=bpnegr1JljUUTM5BMSOnUWBrW5yzJl6Tvl4Vc4Aup7tiNi6COc4+pDi3FMMeS+GSWM J50IGihBAHSJG+tyN05iSXYbU1JMj0BUwwU47vrhDHyGnGlCXHkNqbDs9mWEP3D25fgL Bfla5jZOJa6K+dGqD5OQfFhgFhn7MQNXtUJbj7j/ufaoX+8u8Nq69hn5SdB7cxTB/x83 60ac99+8gYGTvb11kqB35KHyziDupS+0/5sv1b8JtzmMeNfgxrmw5x+Xna4LLbh+mcXz xmp+OOo4zm39DnF+w0pPerVqYS4dLaOEkEXEYYUo9NCbDXsSYDdPmmt+trwR1O4krFZd seIA== Received: by 10.229.137.135 with SMTP id w7mr4615606qct.48.1341721068789; Sat, 07 Jul 2012 21:17:48 -0700 (PDT) Received: from [192.168.1.12] (c-71-235-82-82.hsd1.ct.comcast.net. [71.235.82.82]) by mx.google.com with ESMTPS id cn9sm35687317qab.15.2012.07.07.21.17.47 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 07 Jul 2012 21:17:48 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/alternative; boundary="Apple-Mail=_AC4B164C-6B12-4730-BB70-70170C93C5FB" From: Zhang Peng In-Reply-To: <4FF82C0E.5020809@cs.tcd.ie> Date: Sun, 8 Jul 2012 00:17:46 -0400 Message-Id: References: <20120703003402663560214@gmail.com>, <4FF2ACC3.1020004@cs.tcd.ie> <20120704160541638826251@gmail.com>, <4FF4B0D5.40906@cs.tcd.ie> <20120704174022735010267@gmail.com>, <4FF4B8C2.7090702@cs.tcd.ie> <20120704175739679926274@gmail.com>, <4FF4BD39.7050907@cs.tcd.ie> <20120706223508854218405@gmail.com> <4FF82C0E.5020809@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.1278) Cc: "DECADE@ietf.org" Subject: Re: [decade] Object naming in -req and -arch 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, 08 Jul 2012 04:17:29 -0000 --Apple-Mail=_AC4B164C-6B12-4730-BB70-70170C93C5FB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Yes, I think the scheme I listed is basically the same with that you = mentioned. It is more detailed in that it says that the client can use = the hash of the public key as a global unique identifier and then attach = it with a locally unique label to name the object. It is not a big = issue, and I think it is also considered in = draft-hallambaker-decade-ni-params. For the self-verifying scheme in which public key is hashed in the name, = it may have some concerns about the key management problems, but they = may be inherent in the public-key cryptosystems, and I don't quite agree = that we should abandon the use of it because it has some vulnerability. = But I agree that we should not go too far in the naming scheme design. = Since we are focused on immutable objects in the DECADE, we may just = claim the basic design of hash-based flat naming scheme in the -arch = documents.=20 Thanks, Peng.=20 On Jul 7, 2012, at 8:31 AM, Stephen Farrell wrote: > project --Apple-Mail=_AC4B164C-6B12-4730-BB70-70170C93C5FB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 Yes, = I think the scheme I listed is basically the same with that you = mentioned. It is more detailed in that it says that the client can use = the hash of the public key as a global unique identifier and then attach = it with a locally unique label to name the object. It is not a big = issue, and I think it is also considered in draft-hallambaker-decade-ni-params.

For the self-verifying scheme in which public key is hashed in the = name, it may have some concerns about the key management problems, but = they may be inherent in the public-key cryptosystems, and I don't = quite agree that we should abandon the use of it because it has some = vulnerability. But I agree that we should not go too far in the naming = scheme design. Since we are focused on immutable objects in the DECADE, = we may just claim the basic design of hash-based flat naming scheme in = the -arch documents. 

Thanks,

Peng.


On Jul 7, 2012, at 8:31 = AM, Stephen Farrell wrote:

Thread-Topic: Re:[decade] FW: I-D Action: draft-ietf-decade-integration-example-04.txt Thread-Index: AQHNXAD0Mf0p/fhfFUCNCwVBL78jqpcgcsiA Date: Mon, 9 Jul 2012 06:10:20 +0000 Message-ID: References: <42ee4e66.3caf.1385fe677c6.Coremail.alex7822@163.com> In-Reply-To: <42ee4e66.3caf.1385fe677c6.Coremail.alex7822@163.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.35] Content-Type: multipart/alternative; boundary="_000_B0D29E0424F2DE47A0B36779EC66677924AB4DB8szxeml504mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "decade@ietf.org" Subject: Re: [decade] FW: I-D Action: draft-ietf-decade-integration-example-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: Mon, 09 Jul 2012 06:10:26 -0000 --_000_B0D29E0424F2DE47A0B36779EC66677924AB4DB8szxeml504mbschi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Chen, Thank you for your valuable comments. Please see in-line. From: C. Alexandre Tian [mailto:alex7822@163.com] Sent: Saturday, July 07, 2012 1:26 PM To: Zongning Cc: decade@ietf.org Subject: Re:[decade] FW: I-D Action: draft-ietf-decade-integration-example-= 04.txt Hi Ning, I just reviewed the new revision. Thanks for the efforts! A quick comment for "6. Integration of ALTO and INS System for File Distrib= ution" is that: the scenario setting seems quit complex, which includes bot= h ALTO and INS extension in browsers. The complexity directly makes the rea= ders wondering: what is the killer-app that could serve as the motivation o= f such a complex system? My opinion is that a simple setting would help the= audience understanding the broad-applicability and benefits of DECADE. [Ning]: In the draft, the end-user browser only needs to support INS extens= ion, and the ALTO is between INS portal and ALTO server. Anyway I agree tha= t what you have suggested - simple decoupled structure is very beneficial t= o DECADE. Let's exploit the value of DECADE from the reverse direction: check the sta= te-of-art of a specific content distribution technology; figure out why DEC= ADE could make its design much better. [Ning]: This is good design pattern indeed... Hereby I give an example. I have been involved in a "transparent cache" pro= ject. To reduce the backbone traffic, ISP deploys "transparent cache" for a= leading VoD CP in network edge. Note that this technique has become more a= nd more prevalent. However, due to the information isolation between ISP an= d CP, this in-network storage does not perform well as it should be. I am t= hinking of changing the transparent caches to INS servers. The CP can direc= tly write/configure the storage; CP then use http-redirection to direct cli= ents to INS servers. In this example, CP, instead of INS, interact w/wo ALTO service. INS serve= rs become dump Software-Definable-Network-Storage. It only needs to support= the INS server interface and standard HTTP protocol. INS client in End-Use= r could be skipped in this scenario. [Ning]: One open issue of the integration of ALTO and INS system is who wil= l deploy which part of the system. There could be multiple options includin= g 1) ISP deploys dumb INS servers + CP controls whole content distribution;= 2) ISP deploys and manages INS servers and provides portal + CP talks to t= he portal; 3) third-party broker deploys the INS system + CP talks to the b= roker; etc. Which one of these options is most suitable to ISP/CP could be = interesting question and we welcome more discussions on this list. The example can convey two information (which I think also relates with WG = recharter) (1) INS Client is only optional (2) Besides P2P applications, DECADE has a great value to general content d= istribution networks, which is more important in nowadays Internet. [Ning]: I agree that how DECADE could be valuable to more general content d= istribution system is important to DECADE re-charter discussion. Designing = DECADE as a software-definable content distribution platform is an interest= ing direction. Alexandre At 2012-06-21 11:18:17,Zongning > wrote: >Hi, Folks, > >Please see the new revision of DECADE integration examples draft. >Thanks to Rich. Alimi, Akbar, Haibin for your valuable comments. Please le= t me know if any comments are still not addressed in the new revision. > >-Ning > >> -----Original Message----- >> From: decade-bounces@ietf.org [mailto:de= cade-bounces@ietf.org] On Behalf >> Of internet-drafts@ietf.org >> Sent: Thursday, June 21, 2012 11:14 AM >> To: i-d-announce@ietf.org >> Cc: decade@ietf.org >> Subject: [decade] I-D Action: draft-ietf-decade-integration-example-04.t= xt >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts direc= tories. >> This draft is a work item of the Decoupled Application Data Enroute Wor= king >> Group of the IETF. >> >> Title : Integration Examples of DECADE System >> Author(s) : Ning Zong >> Xiaohui Chen >> Zhigang Huang >> Lijiang Chen >> Hongqiang Liu >> Filename : draft-ietf-decade-integration-example-04.txt >> Pages : 23 >> Date : 2012-06-20 >> >> Abstract: >> Decoupled Application Data Enroute (DECADE) system is an in-network >> storage infrastructure which is still under discussion in IETF. This >> document presents two detailed examples of how to integrate such in- >> network storage infrastructure into peer-to-peer (P2P) applications >> to achieve more efficient content distribution, and Application Layer >> Traffic Optimization (ALTO) system to build a content distribution >> platform for Content Providers (CPs). >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-decade-integration-example >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-decade-integration-example-04 >> >> A diff from previous version is available at: >> http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-decade-integration-examp= le-04 >> >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ > --_000_B0D29E0424F2DE47A0B36779EC66677924AB4DB8szxeml504mbschi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi, Chen,<= o:p>

 = ;

Thank you = for your valuable comments. Please see in-line.

 = ;

From: C. Alexandre Tian [mailto:alex7822@163.com]
Sent: Saturday, July 07, 2012 1:26 PM
To: Zongning
Cc: decade@ietf.org
Subject: Re:[decade] FW: I-D Action: draft-ietf-decade-integration-e= xample-04.txt

 

Hi Ning,<= /o:p>

I just reviewe= d the new revision. Thanks for the efforts!

 <= span lang=3D"EN-US" style=3D"color:black">

A quick commen= t for "6. Integration of ALTO and INS System for File Distribution&quo= t; is that: the scenario setting seems quit complex, which includes both ALTO and INS extension in browsers. The complexity directly makes the= readers wondering: what is the killer-app that could serve as the motivati= on of such a complex system? My opinion is that a simple setting would help= the audience understanding the broad-applicability and benefits of DECADE.

 = ;

[Ning]: In= the draft, the end-user browser only needs to support INS extension, and t= he ALTO is between INS portal and ALTO server. Anyway I agree that what you have suggested – simple decoupled structure is very be= neficial to DECADE.

 <= span lang=3D"EN-US" style=3D"color:black">

Let’s ex= ploit the value of DECADE from the reverse direction: check the state-of-ar= t of a specific content distribution technology; figure out why DECADE could make its design much better.

 = ;

[Ning]: Th= is is good design pattern indeed…

 <= span lang=3D"EN-US" style=3D"color:black">

Hereby I give = an example. I have been involved in a “transparent cache” proje= ct. To reduce the backbone traffic, ISP deploys “transparent cache= 221; for a leading VoD CP in network edge. Note that this technique has become more= and more prevalent. However, due to the information isolation between ISP = and CP, this in-network storage does not perform well as it should be. I am= thinking of changing the transparent caches to INS servers. The CP can directly write/configure the storage; CP= then use http-redirection to direct clients to INS servers.

 <= span lang=3D"EN-US" style=3D"color:black">

In this exampl= e, CP, instead of INS, interact w/wo ALTO service.  INS servers become= dump Software-Definable-Network-Storage. It only needs to support the INS server interface and standard HTTP protocol. INS client in End-Use= r could be skipped in this scenario.

 = ;

[Ning]: On= e open issue of the integration of ALTO and INS system is who will deploy w= hich part of the system. There could be multiple options including 1) ISP deploys dumb INS servers + CP controls whole content distributi= on; 2) ISP deploys and manages INS servers and provides portal + CP tal= ks to the portal; 3) third-party broker deploys the INS system + CP tal= ks to the broker; etc. Which one of these options is most suitable to ISP/CP could be interesting question and we welcome mo= re discussions on this list.

 <= span lang=3D"EN-US" style=3D"color:black">

The example ca= n convey two information (which I think also relates with WG recharter)

(1)  INS = Client is only optional

(2) Besides P2= P applications, DECADE has a great value to general content distribution ne= tworks, which is more important in nowadays Internet.

 = ;

[Ning]: I = agree that how DECADE could be valuable to more general content distributio= n system is important to DECADE re-charter discussion. Designing DECADE as a software-definable content distribution platform is an interes= ting direction.

 = ;

Alexandre= 


At 2012-06-21 =
;11:18:17,Zongning <zongning=
@huawei.com> wrote:
>Hi, Folks,
> 
>Please see th=
e new revision of DECADE integration examples=
 draft.
>Thanks to Ric=
h. Alimi, Akbar, Haibin for your valuable&nbs=
p;comments. Please let me know if any co=
mments are still not addressed in the ne=
w revision.
> 
>-Ning=

> 
>> -----Original=
 Message-----
>> From: decade-bounces@ietf.org [=
mailto:decade-bounces@ietf.org] On Behalf
>> Of internet-drafts@ietf.org
>> Sent: Th=
ursday, June 21, 2012 11:14 AM

>> To: i-d-announce@ietf.org


>> Cc: decade@ietf.org


>> Subject: =
;[decade] I-D Action: draft-ietf-decade-integration-example-=
04.txt


>> 


>> 


>> A New&nb=
sp;Internet-Draft is available from the on-line&nb=
sp;Internet-Drafts directories.


>>  This&nb=
sp;draft is a work item of the Decoupled=
 Application Data Enroute Working

>> Group of=
 the IETF.


>> 


>>   &=
nbsp; Title          &nbs=
p;: Integration Examples of DECADE System


>>   &=
nbsp; Author(s)       : Ning Z=
ong


>>   &=
nbsp;           &nbs=
p;           Xiaohui=
 Chen


>>   &=
nbsp;           &nbs=
p;           Zhigang=
 Huang


>>   &=
nbsp;           &nbs=
p;           Lijiang=
 Chen


>>   &=
nbsp;           &nbs=
p;           Hongqia=
ng Liu


>>   &=
nbsp; Filename        : draft-=
ietf-decade-integration-example-04.txt


>>   &=
nbsp; Pages          &nbs=
p;: 23


>>   &=
nbsp; Date           =
; : 2012-06-20


>> 


>> Abstract:


>>   &=
nbsp;Decoupled Application Data Enroute (DECADE) s=
ystem is an in-network


>>   &=
nbsp;storage infrastructure which is still under&n=
bsp;discussion in IETF.  This


>>   &=
nbsp;document presents two detailed examples of&nb=
sp;how to integrate such in-


>>   &=
nbsp;network storage infrastructure into peer-to-peer&n=
bsp;(P2P) applications


>>   &=
nbsp;to achieve more efficient content distributio=
n, and Application Layer


>>   &=
nbsp;Traffic Optimization (ALTO) system to build&n=
bsp;a content distribution


>>   &=
nbsp;platform for Content Providers (CPs).


>> 


>> 


>> The IETF=
 datatracker status page for this draft =
is:


>> https://datat=
racker.ietf.org/doc/draft-ietf-decade-integration-example=



>> 


>> There's =
also a htmlized version available at:


>> http://tools.=
ietf.org/html/draft-ietf-decade-integration-example-04

>> 


>> A diff&n=
bsp;from previous version is available at:


>> http://tools.=
ietf.org/rfcdiff?url2=3Ddraft-ietf-decade-integration-example-04=



>> 


>> 


>> Internet-Draf=
ts are also available by anonymous FTP a=
t:


>> ftp://ftp.iet=
f.org/internet-drafts/


> 

=  

--_000_B0D29E0424F2DE47A0B36779EC66677924AB4DB8szxeml504mbschi_-- From internet-drafts@ietf.org Mon Jul 9 09:03:16 2012 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 CF28D11E80A5; Mon, 9 Jul 2012 09:03:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.563 X-Spam-Level: X-Spam-Status: No, score=-102.563 tagged_above=-999 required=5 tests=[AWL=0.036, 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 as46EdB7m7q8; Mon, 9 Jul 2012 09:03:16 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6794011E808C; Mon, 9 Jul 2012 09:03:16 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.30p3 Message-ID: <20120709160316.8454.60436.idtracker@ietfa.amsl.com> Date: Mon, 09 Jul 2012 09:03:16 -0700 Cc: decade@ietf.org Subject: [decade] I-D Action: draft-ietf-decade-integration-example-05.txt X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2012 16:03:17 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Decoupled Application Data Enroute Workin= g Group of the IETF. Title : Integration Examples of DECADE System Author(s) : Ning Zong Xiaohui Chen Zhigang Huang Lijiang Chen Hongqiang Liu Filename : draft-ietf-decade-integration-example-05.txt Pages : 23 Date : 2012-07-09 Abstract: Decoupled Application Data Enroute (DECADE) system is an in-network storage infrastructure which is still under discussion in IETF. This document presents two detailed examples of how to integrate such in- network storage infrastructure into peer-to-peer (P2P) applications to achieve more efficient content distribution, and Application Layer Traffic Optimization (ALTO) system to build a content distribution platform for Content Providers (CPs). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-decade-integration-example There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-decade-integration-example-05 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-decade-integration-example-= 05 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From Dirk.Kutscher@neclab.eu Mon Jul 9 09:33:17 2012 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 882AE21F844A for ; Mon, 9 Jul 2012 09:33:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.353 X-Spam-Level: X-Spam-Status: No, score=-2.353 tagged_above=-999 required=5 tests=[AWL=0.245, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 sNJA5P4bx-dw for ; Mon, 9 Jul 2012 09:33:15 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 068AA11E813E for ; Mon, 9 Jul 2012 09:33:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id A1AF61017B3; Mon, 9 Jul 2012 18:35:18 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iI8p-LeJdhQ2; Mon, 9 Jul 2012 18:35:18 +0200 (CEST) Received: from METHONE.office.hd (methone.office.hd [192.168.24.54]) by mailer1.neclab.eu (Postfix) with ESMTP id 818C41017AC; Mon, 9 Jul 2012 18:35:03 +0200 (CEST) Received: from PALLENE.office.hd ([169.254.1.191]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0323.003; Mon, 9 Jul 2012 18:35:14 +0200 From: Dirk Kutscher To: Zhang Peng , Stephen Farrell Thread-Topic: [decade] Object naming in -req and -arch Thread-Index: AQHNWNVORuTyFUORtEmZrQYnfZyHsZcXF/WAgAJ3rEuAABp3IIAABNM6gANyRRCAAIRlAIABCHoAgAJof4A= Date: Mon, 9 Jul 2012 16:35:14 +0000 Message-ID: <82AB329A76E2484D934BBCA77E9F524924D0ECB1@PALLENE.office.hd> References: <20120703003402663560214@gmail.com>, <4FF2ACC3.1020004@cs.tcd.ie> <20120704160541638826251@gmail.com>, <4FF4B0D5.40906@cs.tcd.ie> <20120704174022735010267@gmail.com>, <4FF4B8C2.7090702@cs.tcd.ie> <20120704175739679926274@gmail.com>, <4FF4BD39.7050907@cs.tcd.ie> <20120706223508854218405@gmail.com> <4FF82C0E.5020809@cs.tcd.ie> 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.1] Content-Type: multipart/alternative; boundary="_000_82AB329A76E2484D934BBCA77E9F524924D0ECB1PALLENEofficehd_" MIME-Version: 1.0 Cc: "DECADE@ietf.org" Subject: Re: [decade] Object naming in -req and -arch 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, 09 Jul 2012 16:33:17 -0000 --_000_82AB329A76E2484D934BBCA77E9F524924D0ECB1PALLENEofficehd_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Peng and all, Thanks for the discussion. So, I think it's good to check the requirements and assess draft-farrell-de= cade-ni accordingly. I personally that it meets the ones you listed in your= earlier message. One of the interesting features is that the NI specification defines a comm= on format that enables the integration of hashes (or other cryptographic fu= nctions' output) into names and corresponding validation steps on nodes. Th= e explicit signaling of the function that is actually used allows for appli= cation-specific usage (if so needed) and for some agility regarding crypto = algorithms. A DECADE protocol specification could specify the usage of the = scheme, MANDATORY to implement algorithms etc more specifically. One of the, IMO, important things that have not been discussed sufficiently= is the question about PPSP compatibility that Richard Yang brought up. My view on this is as follows: the PPSP Merkle Hash Tree approach for stati= c and live content has requirements on the *object* and *meta-data* format.= For example, chunks have to carry sibling and uncle hashes. Specifically,= for live streaming with dynamic trees, chunks have to provide chunk signat= ures (block signature, chunk position in the block, and the digests of the = sibling to the way to the root). For both static object and live streaming with PPSP, I think, a hash-based = naming scheme could be employed. Now, it can be worthwhile to employ a nami= ng scheme that signals the existence of the specific object format (to aid = receiving nodes). This would all be feasible with the scheme in draft-farre= ll-decade-ni - but it could be good to extend this discussion to PPSP. Best regards, Dirk From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.org] On Behalf Of= Zhang Peng Sent: Sonntag, 8. Juli 2012 06:18 To: Stephen Farrell Cc: DECADE@ietf.org Subject: Re: [decade] Object naming in -req and -arch Yes, I think the scheme I listed is basically the same with that you mentio= ned. It is more detailed in that it says that the client can use the hash o= f the public key as a global unique identifier and then attach it with a lo= cally unique label to name the object. It is not a big issue, and I think i= t is also considered in draft-hallambaker-decade-ni-params. For the self-verifying scheme in which public key is hashed in the name, it= may have some concerns about the key management problems, but they may be = inherent in the public-key cryptosystems, and I don't quite agree that we s= hould abandon the use of it because it has some vulnerability. But I agree = that we should not go too far in the naming scheme design. Since we are foc= used on immutable objects in the DECADE, we may just claim the basic design= of hash-based flat naming scheme in the -arch documents. Thanks, Peng. On Jul 7, 2012, at 8:31 AM, Stephen Farrell wrote: project --_000_82AB329A76E2484D934BBCA77E9F524924D0ECB1PALLENEofficehd_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Peng and all,

 <= /p>

Thanks for= the discussion.

 = ;

So, I thin= k it’s good to check the requirements and assess draft-farrell-decade= -ni accordingly. I personally that it meets the ones you listed in your earlier message.

 = ;

One of the= interesting features is that the NI specification defines a common format = that enables the integration of hashes (or other cryptographic functions’ output) into names and corresponding validation steps on = nodes. The explicit signaling of the function that is actually used allows = for application-specific usage (if so needed) and for some agility regardin= g crypto algorithms. A DECADE protocol specification could specify the usage of the scheme, MANDATORY to implemen= t algorithms etc more specifically.

 = ;

One of the= , IMO, important things that have not been discussed sufficiently is the qu= estion about PPSP compatibility that Richard Yang brought up.

 = ;

My view on= this is as follows: the PPSP Merkle Hash Tree approach for static and live= content has requirements on the *object* and *meta-data* format.  For example, chunks have to carry sibling and uncle hashes. = Specifically, for live streaming with dynamic trees, chunks have to provide= chunk signatures (block signature, chunk position in the block, and the di= gests of the sibling to the way to the root).

 = ;

For both s= tatic object and live streaming with PPSP, I think, a hash-based naming sch= eme could be employed. Now, it can be worthwhile to employ a naming scheme that signals the existence of the specific object format (= to aid receiving nodes). This would all be feasible with the scheme in draf= t-farrell-decade-ni – but it could be good to extend this discussion = to PPSP.

 = ;

Best regar= ds,

Dirk<= /o:p>

 = ;

 = ;

From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.o= rg] On Behalf Of Zhang Peng
Sent: Sonntag, 8. Juli 2012 06:18
To: Stephen Farrell
Cc: DECADE@ietf.org
Subject: Re: [decade] Object naming in -req and -arch

 

Yes, I think the scheme I listed is basically the sa= me with that you mentioned. It is more detailed in that it says that the cl= ient can use the hash of the public key as a global unique identifier and t= hen attach it with a locally unique label to name the object. It is not a big issue, and I think it is also co= nsidered in draft-hallambaker-decade-ni-par= ams.



For the self-verifying sc= heme in which public key is hashed in the name, it may have some concerns a= bout the key management problems, but they may be inherent in the public-key cryptosystems, and I don't quite agree tha= t we should abandon the use of it because it has some vulnerability. But I = agree that we should not go too far in the naming scheme design. Since we a= re focused on immutable objects in the DECADE, we may just claim the basic design of hash-based flat naming schem= e in the -arch documents. 



Thanks,



Peng.



 

On Jul 7, 2012, at 8:31 AM, Stephen Farrell wrote:



project

 

--_000_82AB329A76E2484D934BBCA77E9F524924D0ECB1PALLENEofficehd_-- From pzhang.thu@gmail.com Mon Jul 9 10:46:05 2012 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 795F011E81C0 for ; Mon, 9 Jul 2012 10:46:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 vPTM6QfowZGl for ; Mon, 9 Jul 2012 10:46:04 -0700 (PDT) Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id AB13E11E81BE for ; Mon, 9 Jul 2012 10:46:04 -0700 (PDT) Received: by qaea16 with SMTP id a16so1754367qae.10 for ; Mon, 09 Jul 2012 10:46:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=wNSYj4JV0FaYB4z7RNJ8khDFpxhrm2X358ykb3gNGIo=; b=aBX97/Z4badZWfiTIENoyhWA5NySKh7+QuEtzkNbv0KewDgq6llwSt0a8IdeB6JvXm 52NKdTgjlauPdtwpiBGkHZhcpYsK1Fg/AzzYF/4IKdfyFavDXbzxlaY8bPoUUusoX8Gr 6yBSTxYGodKpNXSaio2aDx3fIkGGK2K8KdccqT5cYaClTGk2ZECCOqm0n8DZcSBSUIjw 37C0D06Mh4y65qhATKIlQWR0OKJ/uK/cccV8lHHTQ1/HB6dC2VvoXB2+36X7doIp673Q jiCPsq5ShX/qbGlNqlJNu+ZCR1p0s+dbm/NJrtx2ZNoTQvi2PAegYFz974HfVdAylO7Z TwCw== Received: by 10.224.109.196 with SMTP id k4mr73640291qap.92.1341855989706; Mon, 09 Jul 2012 10:46:29 -0700 (PDT) Received: from dhcp-128-36-159-196.central.yale.edu (dhcp-128-36-159-196.central.yale.edu. [128.36.159.196]) by mx.google.com with ESMTPS id f14sm40876607qak.20.2012.07.09.10.46.28 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 09 Jul 2012 10:46:28 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: Zhang Peng In-Reply-To: <4FF867DE.7020609@cs.yale.edu> Date: Mon, 9 Jul 2012 13:46:27 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <374C8630-A970-4AE1-91DB-EAB9041C0980@gmail.com> References: <4FF867DE.7020609@cs.yale.edu> To: Y. Richard Yang X-Mailer: Apple Mail (2.1278) Cc: "DECADE@ietf.org" Subject: Re: [decade] reorganized -req 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, 09 Jul 2012 17:46:05 -0000 Hi Richard and All, Here are some comments on the recently revised version of -req = document. First, I noticed that the protocol flow including DRP and SDT is = included in -req. I wonder if this is a good choice, since it is more = like a design rather than a requirement. Could someone explain the = rationale?=20 For the naming requirements, I suggest that the "the naming = scheme should support that consumer can validate the name-object = binding, i.e., can check that the object content is what the name claims = to be". The rationale is that consumer now obtains the object from = DECADE server, and in turn is uploaded by some content provider that is = not trustworthy. =20 I suggest that the terminology 2.5 "Provider" should better be = "content provider". Otherwise, it may be confused with "DECADE storage = provider" of 2.3. Also, 2.9 is referring to "content provider", not = "provider". Correspondingly, "consumer" should be "content consumer". = But we should also comment that we would use shorter term "provider" and = "consumer" if there is no ambiguity. Section 7.2 is not so clear to me. The rationale has not stated = the reason for this very well.=20 =09 In section 8.1, the term "user" is not defined by us. Should we = use "client" instead? In Section 9, should we also include "overload condition" which = appear in section 4.1.3.1 of current version? =09 Some minor revisions:=20 =09 - Section 2.3: "that" should be removed; - Section 6.1: Should be "After a DECADE-compatible = client owns an account on a DECADE-compatible server, it should be able = to read data from and write data to the server once authorized by the = server.", and it should be following section 6.2. - Section 6.2: I think it is better to be "Access to an = account on a server MUST be granted to a provider based on cryptographic = security" - Section 6.3 "resoutces" -> "resources" - Section 6.9 "disovery" -> "discovery" - Section 7.5 "enerate" -> "generate" - Section 8.4 "stoarge" -> "storage" =09 I would like to help revise if you don't have time. B, Peng. On Jul 7, 2012, at 12:46 PM, Y. Richard Yang wrote: > Dear all, >=20 > We did a substantial reorganization of the -req documents. It is = attached to this email. Any early feedback will be greatly appreciated. >=20 > Thanks! >=20 > Richard > = From internet-drafts@ietf.org Mon Jul 9 13:38:16 2012 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 113C111E81D4; Mon, 9 Jul 2012 13:38:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.543 X-Spam-Level: X-Spam-Status: No, score=-102.543 tagged_above=-999 required=5 tests=[AWL=0.056, 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 AyBCobs3drVM; Mon, 9 Jul 2012 13:38:15 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A667C11E80CC; Mon, 9 Jul 2012 13:38:15 -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: 4.30p3 Message-ID: <20120709203815.18916.9161.idtracker@ietfa.amsl.com> Date: Mon, 09 Jul 2012 13:38:15 -0700 Cc: decade@ietf.org Subject: [decade] I-D Action: draft-ietf-decade-integration-example-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: Mon, 09 Jul 2012 20:38:16 -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 Workin= g Group of the IETF. Title : Integration Examples of DECADE System Author(s) : Ning Zong Xiaohui Chen Zhigang Huang Lijiang Chen Hongqiang Liu Filename : draft-ietf-decade-integration-example-06.txt Pages : 23 Date : 2012-07-09 Abstract: Decoupled Application Data Enroute (DECADE) system is an in-network storage infrastructure which is still under discussion in IETF. This document presents two detailed examples of how to integrate such in- network storage infrastructure into peer-to-peer (P2P) applications to achieve more efficient content distribution, and Application Layer Traffic Optimization (ALTO) system to build a content distribution platform for Content Providers (CPs). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-decade-integration-example There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-decade-integration-example-06 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-decade-integration-example-= 06 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From wwwrun@rfc-editor.org Mon Jul 9 17:07:20 2012 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 5F3F711E8111; Mon, 9 Jul 2012 17:07:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.203 X-Spam-Level: X-Spam-Status: No, score=-102.203 tagged_above=-999 required=5 tests=[AWL=0.397, BAYES_00=-2.599, NO_RELAYS=-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 Nnv+P-DryKfU; Mon, 9 Jul 2012 17:07:19 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id AFAA811E8100; Mon, 9 Jul 2012 17:07:19 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 4CA20B1E004; Mon, 9 Jul 2012 17:07:42 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20120710000742.4CA20B1E004@rfc-editor.org> Date: Mon, 9 Jul 2012 17:07:42 -0700 (PDT) Cc: decade@ietf.org, rfc-editor@rfc-editor.org Subject: [decade] RFC 6646 on DECoupled Application Data Enroute (DECADE) Problem Statement 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, 10 Jul 2012 00:07:20 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6646 Title: DECoupled Application Data Enroute (DECADE) Problem Statement Author: H. Song, N. Zong, Y. Yang, R. Alimi Status: Informational Stream: IETF Date: July 2012 Mailbox: haibin.song@huawei.com, zongning@huawei.com, yry@cs.yale.edu, ralimi@google.com Pages: 12 Characters: 25124 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-decade-problem-statement-06.txt URL: http://www.rfc-editor.org/rfc/rfc6646.txt Peer-to-peer (P2P) applications have become widely used on the Internet today and make up a large portion of the traffic in many networks. In P2P applications, one technique for reducing the transit and uplink P2P traffic is to introduce storage capabilities within the network. Traditional caches (e.g., P2P and Web caches) provide such storage, but they can be complex (e.g., P2P caches need to explicitly support individual P2P application protocols), and do not allow users to manage resource usage policies for content in the cache. This document discusses the introduction of in-network storage for P2P applications and shows the need for a standard protocol for accessing this storage. This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the Decoupled Application Data Enroute Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From yang.r.yang@gmail.com Mon Jul 9 20:33:55 2012 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 E1D8211E8110 for ; Mon, 9 Jul 2012 20:33:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.799 X-Spam-Level: X-Spam-Status: No, score=-2.799 tagged_above=-999 required=5 tests=[AWL=0.177, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 46JRwQ-SjA3O for ; Mon, 9 Jul 2012 20:33:55 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0314511E8114 for ; Mon, 9 Jul 2012 20:33:54 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so1567174obb.31 for ; Mon, 09 Jul 2012 20:34:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=vuX/fHcBQrgwDH8RReLa7TBkkIur5MoUoMGiLDq1C5Q=; b=brfnJWAWYGl1rDqckWlglDUVmxxTQ7Jh2QMGLRDLXCnM5/I5fWzunCSYSx3vXe6O4C MceLQ3SwTh1ynwPBW9DzS5zPoMXFLMZRU3/cvQRhZm1hwMiabSJlmHETgkNAiGFcAOpQ GYxI9ER1SZWwD7++0LdeTc64/vkhzoC7ilNYOaZK2wZjC8HtKf0kIATTi9s385uFT8mI ffNl54r1J9sqF6+7cBl1R6+/Pi1Wt7/xpXLwy9BLTXn43P5X7YtjuleyolD/asYl1WBC 9cZA60sp15drai3MbUh2nXozI6V9f9/Q09rfGRiPCGSzMlEKqECF1r2eOLLmsftvW5yc AohQ== MIME-Version: 1.0 Received: by 10.182.13.74 with SMTP id f10mr38634401obc.36.1341891260972; Mon, 09 Jul 2012 20:34:20 -0700 (PDT) Sender: yang.r.yang@gmail.com Received: by 10.76.86.136 with HTTP; Mon, 9 Jul 2012 20:34:20 -0700 (PDT) In-Reply-To: <374C8630-A970-4AE1-91DB-EAB9041C0980@gmail.com> References: <4FF867DE.7020609@cs.yale.edu> <374C8630-A970-4AE1-91DB-EAB9041C0980@gmail.com> Date: Tue, 10 Jul 2012 11:34:20 +0800 X-Google-Sender-Auth: kdXP1Ant-tsWlC9YMOrmPSUcf-s Message-ID: From: "Y. Richard Yang" To: Zhang Peng Content-Type: multipart/alternative; boundary=f46d0444ee3df0002204c471675d Cc: "DECADE@ietf.org" , "Prof. Chuang Lin" Subject: Re: [decade] reorganized -req 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, 10 Jul 2012 03:33:56 -0000 --f46d0444ee3df0002204c471675d Content-Type: text/plain; charset=ISO-8859-1 Hi Peng, Thanks a lot for the feedback! Please see below. On Tuesday, July 10, 2012, Zhang Peng wrote: > Hi Richard and All, > > Here are some comments on the recently revised version of -req > document. > > First, I noticed that the protocol flow including DRP and SDT is > included in -req. I wonder if this is a good choice, since it is more like > a design rather than a requirement. Could someone explain the rationale? > > I feel that they represent a group of functions (and hence represent two functional components). They help to organize the conceptual model. The requirements do not use SDT and DRP. What do you think? For the naming requirements, I suggest that the "the naming scheme > should support that consumer can validate the name-object binding, i.e., > can check that the object content is what the name claims to be". The > rationale is that consumer now obtains the object from DECADE server, and > in turn is uploaded by some content provider that is not trustworthy. > > Sounds good. > I suggest that the terminology 2.5 "Provider" should better be > "content provider". Otherwise, it may be confused with "DECADE storage > provider" of 2.3. Also, 2.9 is referring to "content provider", not > "provider". Correspondingly, "consumer" should be "content consumer". But > we should also comment that we would use shorter term "provider" and > "consumer" if there is no ambiguity. > > I thought about this. It is not content provider but rather resource provider, because A could allow B to upload to A's account, where A owns the account resource. I am fine to go with Resource Provider though. Section 7.2 is not so clear to me. The rationale has not stated the > reason for this very well. I will take a look and get back soon. > > In section 8.1, the term "user" is not defined by us. Should we > use "client" instead? Sounds good. > > In Section 9, should we also include "overload condition" which > appear in section 4.1.3.1 of current version? I feel that overload is a type of insufficient resources. One possibility is to distinguish between system overload and insufficient inividual provider resources. What do you think? But this can be tricky in that the system can be oversubscribed. So the error message may need to indicate such. > Some minor revisions: > > - Section 2.3: "that" should be removed; > - Section 6.1: Should be "After a DECADE-compatible > client owns an account on a DECADE-compatible server, it should be able to > read data from and write data to the server once authorized by the > server.", and it should be following section 6.2. > - Section 6.2: I think it is better to be "Access to an > account on a server MUST be granted to a provider based on cryptographic > security" > - Section 6.3 "resoutces" -> "resources" > - Section 6.9 "disovery" -> "discovery" > - Section 7.5 "enerate" -> "generate" > - Section 8.4 "stoarge" -> "storage" > > > It will be great if you can take a pass. Thanks a bunch! Richard > > I would like to help revise if you don't have time. > > B, > > Peng. > > > On Jul 7, 2012, at 12:46 PM, Y. Richard Yang wrote: > > > Dear all, > > > > We did a substantial reorganization of the -req documents. It is > attached to this email. Any early feedback will be greatly appreciated. > > > > Thanks! > > > > Richard > > > > --f46d0444ee3df0002204c471675d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Peng,

Thanks a lot for the feedback! Please see below= .

On Tuesday, July 10, 2012, Zhang Peng wrote:
Hi Richard and All,

=A0 =A0 =A0 =A0 Here are some comments on the recently revised version of -= req document.

=A0 =A0 =A0 =A0 First, I noticed that the protocol flow including DRP and S= DT is included in -req. I wonder if this is a good choice, since it is more= like a design rather than a requirement. Could someone explain the rationa= le?

I feel that they represent a group of functions (and = hence represent two functional components). They help to organize the conce= ptual model. The requirements do not use SDT and DRP. What do you think?

=A0 =A0 =A0 =A0 For the naming requirements, I suggest that the "the n= aming scheme should support that consumer can validate the name-object bind= ing, i.e., can check that the object content is what the name claims to be&= quot;. The rationale is that consumer now obtains the object from DECADE se= rver, and in turn is uploaded by some content provider that is not trustwor= thy.

Sounds good.
=A0
=A0 =A0 =A0 =A0 I suggest that the terminology 2.5 "Provider" sho= uld better be "content provider". Otherwise, it may be confused w= ith "DECADE storage provider" of 2.3. Also, 2.9 is referring to &= quot;content provider", not "provider". Correspondingly, &qu= ot;consumer" should be "content consumer". But we should als= o comment that we would use shorter term "provider" and "con= sumer" if there is no ambiguity.

I thought about this. It is not content provider but = rather resource provider, because A could allow B to upload to A's acco= unt, where A owns the account resource. I am fine to go with Resource Provi= der though.=A0

=A0 =A0 =A0 =A0 Section 7.2 is not so clear to me. The rationale has not st= ated the reason for this very well.

I will = take a look and get back soon.
=A0

=A0 =A0 =A0 =A0 In section 8.1, the term "user" is not defined by= us. Should we use "client" instead?

<= div>Sounds good.=A0

=A0 =A0 =A0 =A0 In Section 9, should we also include "overload conditi= on" which appear in section 4.1.3.1 of current version?

I feel that overload is a type of insufficient resources.= One possibility is to distinguish between system overload and insufficient= inividual provider resources. What do you think? But this can be tricky in= that the system can be oversubscribed. So the error message may need to in= dicate such.=A0


=A0 =A0 =A0 =A0 Some minor revisions:

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 - Section 2.3: "that" should be r= emoved;
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 - Section 6.1: =A0Should be "After a D= ECADE-compatible client owns an account on a DECADE-compatible server, it s= hould be able to read data from and write data to the server once authorize= d by the server.", and it should be following section 6.2.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 - Section 6.2: I think it is better to be &= quot;Access to an account on a server MUST be granted to a provider based o= n cryptographic security"
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 - Section 6.3 "resoutces" -> &= quot;resources"
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 - Section 6.9 "disovery" -> &q= uot;discovery"
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 - Section 7.5 "enerate" -> &qu= ot;generate"
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 - Section 8.4 "stoarge" -> &qu= ot;storage"


It will be great if you can take a pass. Thanks a bun= ch!

Richard=A0

=A0 =A0 =A0 =A0 I would like to help revise if you don't have time.

B,

Peng.


On Jul 7, 2012, at 12:46 PM, Y. Richard Yang wrote:

> Dear all,
>
> We did a substantial reorganization of the -req documents. It is attac= hed to this email. Any early feedback will be greatly appreciated.
>
> Thanks!
>
> Richard
> <draft-ietf-decade-reqs-all_v06.txt><draft-ietf-decade-reqs-a= ll_v06.xml>

--f46d0444ee3df0002204c471675d-- From pzhang.thu@gmail.com Mon Jul 9 21:13:15 2012 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 9133021F855E for ; Mon, 9 Jul 2012 21:13:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 l4fXTFHGHXP8 for ; Mon, 9 Jul 2012 21:13:14 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 835B021F855A for ; Mon, 9 Jul 2012 21:13:14 -0700 (PDT) Received: by qcac10 with SMTP id c10so6719608qca.31 for ; Mon, 09 Jul 2012 21:13:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer; bh=dSneyW0bdaZG2CbOOovQjHf5lF10Lj2PUI43+rmkvu0=; b=vit4DRDDfvT1e8F88Mmpr9JyOHdPoc15uUvZaNwlIuhunnvGR/zAhzfMP6QItngi/u 3Vrhp/YUIjD1FkFrAe3aOH1ALX/62vitp28Bp66UdbBe30/BNunq/n8Eirlh6vuAP0y7 uN/QhSyolbMrtoX2JyJ6Lb4mATENccFb8YePv3VBA4pnfRMkWCd+kh2RhqYgPuKr9oCs NTAiYhiP9tbfixICXc63ao3ZEe2xZgK64WWPZRy0fXPDPGyCjMoowc8rWO3/iz0XGhO/ aDoUjEbY0eKhZIsTuWXtz5E7ZwAHiyGiCPc7ltj9/ZkJeJFuVVWUZglkGtoYlDsRfRPY MEHg== Received: by 10.224.214.193 with SMTP id hb1mr64438597qab.43.1341893620675; Mon, 09 Jul 2012 21:13:40 -0700 (PDT) Received: from dhcp-128-36-159-196.central.yale.edu (dhcp-128-36-159-196.central.yale.edu. [128.36.159.196]) by mx.google.com with ESMTPS id cg7sm64255287qab.19.2012.07.09.21.13.39 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 09 Jul 2012 21:13:40 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/alternative; boundary="Apple-Mail=_8CDE541B-CBCD-4C21-AE22-EDB8179E178B" From: Peng Zhang In-Reply-To: Date: Tue, 10 Jul 2012 00:13:38 -0400 Message-Id: <1A84DDEF-D3C0-48A1-AC3D-DC0E908861C2@gmail.com> References: <4FF867DE.7020609@cs.yale.edu> <374C8630-A970-4AE1-91DB-EAB9041C0980@gmail.com> To: "Y. Richard Yang" X-Mailer: Apple Mail (2.1278) Cc: "DECADE@ietf.org" , "Prof. Chuang Lin" Subject: Re: [decade] reorganized -req 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, 10 Jul 2012 04:13:15 -0000 --Apple-Mail=_8CDE541B-CBCD-4C21-AE22-EDB8179E178B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On Jul 9, 2012, at 11:34 PM, Y. Richard Yang wrote: > Hi Peng, >=20 > Thanks a lot for the feedback! Please see below. >=20 > On Tuesday, July 10, 2012, Zhang Peng wrote: > Hi Richard and All, >=20 > Here are some comments on the recently revised version of -req = document. >=20 > First, I noticed that the protocol flow including DRP and SDT = is included in -req. I wonder if this is a good choice, since it is more = like a design rather than a requirement. Could someone explain the = rationale? >=20 > I feel that they represent a group of functions (and hence represent = two functional components). They help to organize the conceptual model. = The requirements do not use SDT and DRP. What do you think? I still don't quite see the necessity of putting the design model here. = It is a little detailed to be here. >=20 > For the naming requirements, I suggest that the "the naming = scheme should support that consumer can validate the name-object = binding, i.e., can check that the object content is what the name claims = to be". The rationale is that consumer now obtains the object from = DECADE server, and in turn is uploaded by some content provider that is = not trustworthy. >=20 > Sounds good. > =20 > I suggest that the terminology 2.5 "Provider" should better be = "content provider". Otherwise, it may be confused with "DECADE storage = provider" of 2.3. Also, 2.9 is referring to "content provider", not = "provider". Correspondingly, "consumer" should be "content consumer". = But we should also comment that we would use shorter term "provider" and = "consumer" if there is no ambiguity. >=20 > I thought about this. It is not content provider but rather resource = provider, because A could allow B to upload to A's account, where A owns = the account resource. I am fine to go with Resource Provider though. Yes, I think "resource provider" is a more precise definition. > =20 >=20 > Section 7.2 is not so clear to me. The rationale has not = stated the reason for this very well. >=20 > I will take a look and get back soon. > =20 >=20 > In section 8.1, the term "user" is not defined by us. Should = we use "client" instead? >=20 > Sounds good.=20 >=20 > In Section 9, should we also include "overload condition" = which appear in section 4.1.3.1 of current version? >=20 > I feel that overload is a type of insufficient resources. One = possibility is to distinguish between system overload and insufficient = inividual provider resources. What do you think? But this can be tricky = in that the system can be oversubscribed. So the error message may need = to indicate such.=20 Maybe we should distinguish between them. For the insufficient resource, = it is due to not enough resources are allocated. By returning this error = message, the server may cause the consumer to ask for more resource from = the provider. While if it is due to system overload, the error message = may cause a redirection to other servers.=20 >=20 >=20 > Some minor revisions: >=20 > - Section 2.3: "that" should be removed; > - Section 6.1: Should be "After a DECADE-compatible = client owns an account on a DECADE-compatible server, it should be able = to read data from and write data to the server once authorized by the = server.", and it should be following section 6.2. > - Section 6.2: I think it is better to be "Access to = an account on a server MUST be granted to a provider based on = cryptographic security" > - Section 6.3 "resoutces" -> "resources" > - Section 6.9 "disovery" -> "discovery" > - Section 7.5 "enerate" -> "generate" > - Section 8.4 "stoarge" -> "storage" >=20 >=20 > It will be great if you can take a pass. Thanks a bunch! You mean that I revise directly on .xml file? Thanks. Best,=20 Peng. >=20 > Richard=20 >=20 > I would like to help revise if you don't have time. >=20 > B, >=20 > Peng. >=20 >=20 > On Jul 7, 2012, at 12:46 PM, Y. Richard Yang wrote: >=20 > > Dear all, > > > > We did a substantial reorganization of the -req documents. It is = attached to this email. Any early feedback will be greatly appreciated. > > > > Thanks! > > > > Richard > > = >=20 --Apple-Mail=_8CDE541B-CBCD-4C21-AE22-EDB8179E178B Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=iso-8859-1
On Jul 9, 2012, at 11:34 PM, Y. Richard Yang wrote:

Hi Peng,

Thanks a lot for the feedback! Please see below.

On Tuesday, July 10, 2012, Zhang Peng wrote:
Hi Richard and All,

        Here are some comments on the recently revised version of -req document.

        First, I noticed that the protocol flow including DRP and SDT is included in -req. I wonder if this is a good choice, since it is more like a design rather than a requirement. Could someone explain the rationale?

I feel that they represent a group of functions (and hence represent two functional components). They help to organize the conceptual model. The requirements do not use SDT and DRP. What do you think?
I still don't quite see the necessity of putting the design model here. It is a little detailed to be here.

        For the naming requirements, I suggest that the "the naming scheme should support that consumer can validate the name-object binding, i.e., can check that the object content is what the name claims to be". The rationale is that consumer now obtains the object from DECADE server, and in turn is uploaded by some content provider that is not trustworthy.

Sounds good.
 
        I suggest that the terminology 2.5 "Provider" should better be "content provider". Otherwise, it may be confused with "DECADE storage provider" of 2.3. Also, 2.9 is referring to "content provider", not "provider". Correspondingly, "consumer" should be "content consumer". But we should also comment that we would use shorter term "provider" and "consumer" if there is no ambiguity.

I thought about this. It is not content provider but rather resource provider, because A could allow B to upload to A's account, where A owns the account resource. I am fine to go with Resource Provider though.
Yes, I think "resource provider" is a more precise definition.
 

        Section 7.2 is not so clear to me. The rationale has not stated the reason for this very well.

I will take a look and get back soon.
 

        In section 8.1, the term "user" is not defined by us. Should we use "client" instead?

Sounds good. 

        In Section 9, should we also include "overload condition" which appear in section 4.1.3.1 of current version?

I feel that overload is a type of insufficient resources. One possibility is to distinguish between system overload and insufficient inividual provider resources. What do you think? But this can be tricky in that the system can be oversubscribed. So the error message may need to indicate such. 
Maybe we should distinguish between them. For the insufficient resource, it is due to not enough resources are allocated. By returning this error message, the server may cause the consumer to ask for more resource from the provider. While if it is due to system overload, the error message may cause a redirection to other servers. 



        Some minor revisions:

                - Section 2.3: "that" should be removed;
                - Section 6.1:  Should be "After a DECADE-compatible client owns an account on a DECADE-compatible server, it should be able to read data from and write data to the server once authorized by the server.", and it should be following section 6.2.
                - Section 6.2: I think it is better to be "Access to an account on a server MUST be granted to a provider based on cryptographic security"
                - Section 6.3 "resoutces" -> "resources"
                - Section 6.9 "disovery" -> "discovery"
                - Section 7.5 "enerate" -> "generate"
                - Section 8.4 "stoarge" -> "storage"


It will be great if you can take a pass. Thanks a bunch!
You mean that I revise directly on .xml file? Thanks.

Best, 

Peng.


Richard 

        I would like to help revise if you don't have time.

B,

Peng.


On Jul 7, 2012, at 12:46 PM, Y. Richard Yang wrote:

> Dear all,
>
> We did a substantial reorganization of the -req documents. It is attached to this email. Any early feedback will be greatly appreciated.
>
> Thanks!
>
> Richard
> <draft-ietf-decade-reqs-all_v06.txt><draft-ietf-decade-reqs-all_v06.xml>


--Apple-Mail=_8CDE541B-CBCD-4C21-AE22-EDB8179E178B-- From pzhang.thu@gmail.com Mon Jul 9 21:32:41 2012 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 9BCAC11E814C for ; Mon, 9 Jul 2012 21:32:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 xMjBbEs+u1sL for ; Mon, 9 Jul 2012 21:32:40 -0700 (PDT) Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id 9BE4611E813E for ; Mon, 9 Jul 2012 21:32:40 -0700 (PDT) Received: by qaea16 with SMTP id a16so2009050qae.10 for ; Mon, 09 Jul 2012 21:33:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer; bh=5PTEE6lLCCdf3f/7/PrKPPLVmzgSS3SCOFXDEz4umsg=; b=GHoedUndn2EVa71dfnFAOxlTDM65NQegOdUwCdOqwkc5ruY45Rm7rDpZ9mpavWbARZ KjfoFyH0ygfmLLaS6C9cR/56RVe9PqBzzbi4YrL/o1QFkpWFjvYOH3MruTuXC+RTKXFa AWRXEfDa65/ZdrHYl0LwGMRBpowxn23g5LSsjNtXuSl62Mw9uBT1MpJwDLbjJa/njEAl 2fh6F729KDGf/Y9Kiwu1kqYmF1MzO9NlqZ5MEtrZWREtmEYT00eDhcXO99dPicdo2Pm1 0FaCNAJ+pPwIC7lHAMefYSqbv01Vgq41jFKj24z0YR+JjsJpI//2UHc6FD3KCv8n8ocz rtzw== Received: by 10.229.111.74 with SMTP id r10mr16926383qcp.24.1341894786970; Mon, 09 Jul 2012 21:33:06 -0700 (PDT) Received: from dhcp-128-36-159-196.central.yale.edu (dhcp-128-36-159-196.central.yale.edu. [128.36.159.196]) by mx.google.com with ESMTPS id et8sm8359394qab.9.2012.07.09.21.33.05 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 09 Jul 2012 21:33:06 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/alternative; boundary="Apple-Mail=_AF7FC25E-97D0-471D-B9F6-8CD19FB806D5" From: Peng Zhang In-Reply-To: <82AB329A76E2484D934BBCA77E9F524924D0ECB1@PALLENE.office.hd> Date: Tue, 10 Jul 2012 00:33:04 -0400 Message-Id: <4651C731-C630-4E8F-8FF2-697F32EBA86F@gmail.com> References: <20120703003402663560214@gmail.com>, <4FF2ACC3.1020004@cs.tcd.ie> <20120704160541638826251@gmail.com>, <4FF4B0D5.40906@cs.tcd.ie> <20120704174022735010267@gmail.com>, <4FF4B8C2.7090702@cs.tcd.ie> <20120704175739679926274@gmail.com>, <4FF4BD39.7050907@cs.tcd.ie> <20120706223508854218405@gmail.com> <4FF82C0E.5020809@cs.tcd.ie> <82AB329A76E2484D934BBCA77E9F524924D0ECB1@PALLENE.office.hd> To: Dirk Kutscher X-Mailer: Apple Mail (2.1278) Cc: "DECADE@ietf.org" Subject: Re: [decade] Object naming in -req and -arch 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, 10 Jul 2012 04:32:41 -0000 --Apple-Mail=_AF7FC25E-97D0-471D-B9F6-8CD19FB806D5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Dirk and all, I agree that the NI specification meets the basic requirement of = DECADE (without optimization on "early name generation").=20 As for the Merkle Hash Tree, or MTH, it is a integrity-assurance = method for a sequence of objects. It is critical to the PPSP protocol. = But i wonder wether we should incorporate it in our design: First, DECADE is targeted at general content distribution = applications, and for applications other than P2P streaming, there is no = great value of using Merkle Hash Tree. It may cause high overhead to = these applications due "meta data" including signatures and full hashes = should be exchanged.=20 Still, we can discuss more on how to better incorporate PPSP = based on NI without hurting the general application of DECADE. Thanks. B, Peng. On Jul 9, 2012, at 12:35 PM, Dirk Kutscher wrote: > Hi Peng and all, > =20 > Thanks for the discussion. > =20 > So, I think it=92s good to check the requirements and assess = draft-farrell-decade-ni accordingly. I personally that it meets the ones = you listed in your earlier message. > =20 > One of the interesting features is that the NI specification defines a = common format that enables the integration of hashes (or other = cryptographic functions=92 output) into names and corresponding = validation steps on nodes. The explicit signaling of the function that = is actually used allows for application-specific usage (if so needed) = and for some agility regarding crypto algorithms. A DECADE protocol = specification could specify the usage of the scheme, MANDATORY to = implement algorithms etc more specifically. > =20 > One of the, IMO, important things that have not been discussed = sufficiently is the question about PPSP compatibility that Richard Yang = brought up. > =20 > My view on this is as follows: the PPSP Merkle Hash Tree approach for = static and live content has requirements on the *object* and *meta-data* = format. For example, chunks have to carry sibling and uncle hashes. = Specifically, for live streaming with dynamic trees, chunks have to = provide chunk signatures (block signature, chunk position in the block, = and the digests of the sibling to the way to the root). > =20 > For both static object and live streaming with PPSP, I think, a = hash-based naming scheme could be employed. Now, it can be worthwhile to = employ a naming scheme that signals the existence of the specific object = format (to aid receiving nodes). This would all be feasible with the = scheme in draft-farrell-decade-ni =96 but it could be good to extend = this discussion to PPSP. > =20 > Best regards, > Dirk --Apple-Mail=_AF7FC25E-97D0-471D-B9F6-8CD19FB806D5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hi = Dirk and all,

I agree that the NI specification = meets the basic requirement of DECADE (without optimization on "early = name generation"). 

As for = the Merkle Hash Tree, or MTH, it is a integrity-assurance method for a = sequence of objects. It is critical to the PPSP protocol. But i wonder = wether we should incorporate it in our = design:

First, DECADE is targeted at = general content distribution applications, and for applications other = than P2P streaming, there is no great value of using Merkle Hash Tree. = It may cause high overhead to these applications due "meta data" = including signatures and full hashes should be = exchanged. 

Still, we can discuss more on how = to better incorporate PPSP based on NI without hurting the general = application of DECADE. = Thanks.

B,

Peng.


On Jul 9, 2012, at 12:35 PM, Dirk = Kutscher wrote:

Hi Peng and = all,
Thanks for the = discussion.
 
So, I think = it=92s good to check the requirements and assess draft-farrell-decade-ni = accordingly. I personally that it meets the ones you listed in your = earlier message.
 
One of the = interesting features is that the NI specification defines a common = format that enables the integration of hashes (or other cryptographic = functions=92 output) into names and corresponding validation steps on = nodes. The explicit signaling of the function that is actually used = allows for application-specific usage (if so needed) and for some = agility regarding crypto algorithms. A DECADE protocol specification = could specify the usage of the scheme, MANDATORY to implement algorithms = etc more specifically.
One of the, IMO, important things that have not been = discussed sufficiently is the question about PPSP compatibility that = Richard Yang brought up.
My view on this is as follows: the PPSP Merkle Hash = Tree approach for static and live content has requirements on the = *object* and *meta-data* format.  For example, chunks = have to carry sibling and uncle hashes. Specifically, for live streaming = with dynamic trees, chunks have to provide chunk signatures (block = signature, chunk position in the block, and the digests of the sibling = to the way to the root).
For both static object and live streaming with PPSP, = I think, a hash-based naming scheme could be employed. Now, it can be = worthwhile to employ a naming scheme that signals the existence of the = specific object format (to aid receiving nodes). This would all be = feasible with the scheme in draft-farrell-decade-ni =96 but it could be = good to extend this discussion to PPSP.
Best regards,
To: Peng Zhang Content-Type: multipart/alternative; boundary=f46d04479559fc8f8904c47290f8 Cc: "DECADE@ietf.org" , "Prof. Chuang Lin" Subject: Re: [decade] reorganized -req 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, 10 Jul 2012 04:57:01 -0000 --f46d04479559fc8f8904c47290f8 Content-Type: text/plain; charset=ISO-8859-1 Hi Peng, On Tuesday, July 10, 2012, Peng Zhang wrote: > > On Jul 9, 2012, at 11:34 PM, Y. Richard Yang wrote: > > Hi Peng, > > Thanks a lot for the feedback! Please see below. > > On Tuesday, July 10, 2012, Zhang Peng wrote: > >> Hi Richard and All, >> >> Here are some comments on the recently revised version of -req >> document. >> >> First, I noticed that the protocol flow including DRP and SDT is >> included in -req. I wonder if this is a good choice, since it is more like >> a design rather than a requirement. Could someone explain the rationale? >> >> I feel that they represent a group of functions (and hence represent two > functional components). They help to organize the conceptual model. The > requirements do not use SDT and DRP. What do you think? > > I still don't quite see the necessity of putting the design model here. It > is a little detailed to be here. > Then how about change the wording to say two functional components? I can change it after you take a pass. Please revise .xml if you can. Thanks! Richard > > For the naming requirements, I suggest that the "the naming scheme >> should support that consumer can validate the name-object binding, i.e., >> can check that the object content is what the name claims to be". The >> rationale is that consumer now obtains the object from DECADE server, and >> in turn is uploaded by some content provider that is not trustworthy. >> >> Sounds good. > > >> I suggest that the terminology 2.5 "Provider" should better be >> "content provider". Otherwise, it may be confused with "DECADE storage >> provider" of 2.3. Also, 2.9 is referring to "content provider", not >> "provider". Correspondingly, "consumer" should be "content consumer". But >> we should also comment that we would use shorter term "provider" and >> "consumer" if there is no ambiguity. >> >> I thought about this. It is not content provider but rather resource > provider, because A could allow B to upload to A's account, where A owns > the account resource. I am fine to go with Resource Provider though. > > Yes, I think "resource provider" is a more precise definition. > > > > Section 7.2 is not so clear to me. The rationale has not stated >> the reason for this very well. > > > I will take a look and get back soon. > > >> >> In section 8.1, the term "user" is not defined by us. Should we >> use "client" instead? > > > Sounds good. > >> >> In Section 9, should we also include "overload condition" which >> appear in section 4.1.3.1 of current version? > > > I feel that overload is a type of insufficient resources. One possibility > is to distinguish between system overload and insufficient inividual > provider resources. What do you think? But this can be tricky in that the > system can be oversubscribed. So the error message may need to indicate > such. > > Maybe we should distinguish between them. For the insufficient resource, > it is due to not enough resources are allocated. By returning this error > message, the server may cause the consumer to ask for more resource from > the provider. While if it is due to system overload, the error message may > cause a redirection to other servers. > > > >> Some minor revisions: >> >> - Section 2.3: "that" should be removed; >> - Section 6.1: Should be "After a DECADE-compatible >> client owns an account on a DECADE-compatible server, it should be able to >> read data from and write data to the server once authorized by the >> server.", and it should be following section 6.2. >> - Section 6.2: I think it is better to be "Access to an >> account on a server MUST be granted to a provider based on cryptographic >> security" >> - Section 6.3 "resoutces" -> "resources" >> - Section 6.9 "disovery" -> "discovery" >> - Section 7.5 "enerate" -> "generate" >> - Section 8.4 "stoarge" -> "storage" >> >> >> It will be great if you can take a pass. Thanks a bunch! > > You mean that I revise directly on .xml file? Thanks. > > Best, > > Peng. > > > Richard > >> >> I would like to help revise if you don't have time. >> >> B, >> >> Peng. >> >> >> On Jul 7, 2012, at 12:46 PM, Y. Richard Yang wrote: >> >> > Dear all, >> > >> > We did a substantial reorganization of the -req documents. It is >> attached to this email. Any early feedback will be greatly appreciated. >> > >> > Thanks! >> > >> > Richard >> > >> >> > --f46d04479559fc8f8904c47290f8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Peng,

On Tuesday, July 10, 2012, Peng Zhang wrote:

On = Jul 9, 2012, at 11:34 PM, Y. Richard Yang wrote:

Hi Peng,

Thanks a lot for = the feedback! Please see below.

On Tuesday, July 10, 2012, Zhang Pen= g wrote:
Hi Richard and All,

=A0 =A0 =A0 =A0 Here are some comments on the recently revised version of -= req document.

=A0 =A0 =A0 =A0 First, I noticed that the protocol flow including DRP and S= DT is included in -req. I wonder if this is a good choice, since it is more= like a design rather than a requirement. Could someone explain the rationa= le?

I feel that they represent a group of functions (and = hence represent two functional components). They help to organize the conce= ptual model. The requirements do not use SDT and DRP. What do you think?
I still don't quite see the necessity of puttin= g the design model here. It is a little detailed to be here.

Then how about change the wording to say two functional components? I can c= hange it after you take a pass. Please revise .xml if you can.

Thanks!

Richard=A0

=A0 =A0 =A0 =A0 For the naming requirements, I suggest that the "the n= aming scheme should support that consumer can validate the name-object bind= ing, i.e., can check that the object content is what the name claims to be&= quot;. The rationale is that consumer now obtains the object from DECADE se= rver, and in turn is uploaded by some content provider that is not trustwor= thy.

Sounds good.
=A0
=A0 =A0 =A0 =A0 I suggest that the terminology 2.5 "Provider" sho= uld better be "content provider". Otherwise, it may be confused w= ith "DECADE storage provider" of 2.3. Also, 2.9 is referring to &= quot;content provider", not "provider". Correspondingly, &qu= ot;consumer" should be "content consumer". But we should als= o comment that we would use shorter term "provider" and "con= sumer" if there is no ambiguity.

I thought about this. It is not content provider but = rather resource provider, because A could allow B to upload to A's acco= unt, where A owns the account resource. I am fine to go with Resource Provi= der though.
Yes, I think "resource provider" is a more pre= cise definition.
=A0

=A0 =A0 =A0 =A0 Section 7.2 is not so clear to me. The rationale has not st= ated the reason for this very well.

I will = take a look and get back soon.
=A0

=A0 =A0 =A0 =A0 In section 8.1, the term "user" is not defined by= us. Should we use "client" instead?

<= div>Sounds good.=A0

=A0 =A0 =A0 =A0 In Section 9, should we also include "overload conditi= on" which appear in section 4.1.3.1 of current version?

I feel that overload is a type of insufficient resources.= One possibility is to distinguish between system overload and insufficient= inividual provider resources. What do you think? But this can be tricky in= that the system can be oversubscribed. So the error message may need to in= dicate such.=A0
Maybe we should distinguish between them. For the insuff= icient resource, it is due to not enough resources are allocated. By return= ing this error message, the server may cause the consumer to ask for more r= esource from the provider. While if it is due to system overload, the error= message may cause a redirection to other servers.=A0



=A0 =A0 =A0 =A0 Some minor revisions:

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 - Section 2.3: "that" should be r= emoved;
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 - Section 6.1: =A0Should be "After a D= ECADE-compatible client owns an account on a DECADE-compatible server, it s= hould be able to read data from and write data to the server once authorize= d by the server.", and it should be following section 6.2.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 - Section 6.2: I think it is better to be &= quot;Access to an account on a server MUST be granted to a provider based o= n cryptographic security"
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 - Section 6.3 "resoutces" -> &= quot;resources"
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 - Section 6.9 "disovery" -> &q= uot;discovery"
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 - Section 7.5 "enerate" -> &qu= ot;generate"
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 - Section 8.4 "stoarge" -> &qu= ot;storage"


It will be great if you can take a pass. Thanks a bun= ch!
You mean that I revise directly on .xml fi= le? Thanks.

Best,=A0

Peng= .


Richard= =A0

=A0 =A0 =A0 =A0 I would like to help revise if you don't have time.

B,

Peng.


On Jul 7, 2012, at 12:46 PM, Y. Richard Yang wrote:

> Dear all,
>
> We did a substantial reorganization of the -req documents. It is attac= hed to this email. Any early feedback will be greatly appreciated.
>
> Thanks!
>
> Richard
> <draft-ietf-decade-reqs-all_v06.txt><draft-ietf-decade-reqs-a= ll_v06.xml>


--f46d04479559fc8f8904c47290f8-- From yang.r.yang@gmail.com Mon Jul 9 22:22:39 2012 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 C3DD411E8117; Mon, 9 Jul 2012 22:22:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.531 X-Spam-Level: X-Spam-Status: No, score=-2.531 tagged_above=-999 required=5 tests=[AWL=-0.155, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6, 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 9D43dnHE1Env; Mon, 9 Jul 2012 22:22:39 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id C43C011E80F6; Mon, 9 Jul 2012 22:22:38 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so1707301obb.31 for ; Mon, 09 Jul 2012 22:23:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=D87iwea/XVb4pasH2W9pia4sx0awppRYHWa2iwgYUgc=; b=Fno9HxOlEdPXANB3HYEe5K6q1o+sEypIjB5WpjDy+cGiEbdQsDPkZVnU/xnxPjlY0e TVz6+SesQ5ABaJZEAb8mC3Ud9NlxProSZ9KlUVnymU10u5/DFupOYKC3e/9s5+hJTsMT UDDTsRPyyITTy0kzpHzloJkDPhc4B6J6e3ASVHwPSgOgeQ6GgTAjrTnnH9Beh7qpXscc im5pRvcMyMwjUDupn2lUjzDoPgIsUL/EvD0Ud4A6Sc3NGM/ChsqeXK+ysJT62dBZLdaI h2WNZZXLvdXZaSq5jukVUjT3JOOEd+7WU8Isz/s6V4PfkslWbwN0XQxT5ecQpTYTWAiV HQEQ== MIME-Version: 1.0 Received: by 10.182.85.8 with SMTP id d8mr12228009obz.70.1341897785291; Mon, 09 Jul 2012 22:23:05 -0700 (PDT) Sender: yang.r.yang@gmail.com Received: by 10.76.86.136 with HTTP; Mon, 9 Jul 2012 22:23:05 -0700 (PDT) In-Reply-To: <4651C731-C630-4E8F-8FF2-697F32EBA86F@gmail.com> References: <20120703003402663560214@gmail.com> <4FF2ACC3.1020004@cs.tcd.ie> <20120704160541638826251@gmail.com> <4FF4B0D5.40906@cs.tcd.ie> <20120704174022735010267@gmail.com> <4FF4B8C2.7090702@cs.tcd.ie> <20120704175739679926274@gmail.com> <4FF4BD39.7050907@cs.tcd.ie> <20120706223508854218405@gmail.com> <4FF82C0E.5020809@cs.tcd.ie> <82AB329A76E2484D934BBCA77E9F524924D0ECB1@PALLENE.office.hd> <4651C731-C630-4E8F-8FF2-697F32EBA86F@gmail.com> Date: Tue, 10 Jul 2012 13:23:05 +0800 X-Google-Sender-Auth: XHtBnwLIxGBVn17PzxTx3VEvnZs Message-ID: From: "Y. Richard Yang" To: Peng Zhang Content-Type: multipart/alternative; boundary=f46d04479559d1356104c472ec52 Cc: "ppsp@ietf.org" , "DECADE@ietf.org" Subject: Re: [decade] Object naming in -req and -arch 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, 10 Jul 2012 05:22:39 -0000 --f46d04479559d1356104c472ec52 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Peng, Dirk, I am cc'ing the ppsp list as well. You raised a good point on the distinction between one object and a sequence of objects. To generalize, we can discuss even a set of objects (no ordering), and a set of equivalence objects (dynamic streaming that interleaves different resolutions). Your arguement against MTH is higher overhead in the general case (end to end arguements). How much exactly is the overhead? Decade may benefit from the analysis from ppsp. Since streaming is considered as the main app, how much overhead if decade has to build on top? Thanks! Richard On Tuesday, July 10, 2012, Peng Zhang wrote: > Hi Dirk and all, > > I agree that the NI specification meets the basic requirement of DECADE > (without optimization on "early name generation"). > > As for the Merkle Hash Tree, or MTH, it is a integrity-assurance method > for a sequence of objects. It is critical to the PPSP protocol. But i > wonder wether we should incorporate it in our design: > > First, DECADE is targeted at general content distribution applications, > and for applications other than P2P streaming, there is no great value of > using Merkle Hash Tree. It may cause high overhead to these applications > due "meta data" including signatures and full hashes should be exchanged. > > Still, we can discuss more on how to better incorporate PPSP based on NI > without hurting the general application of DECADE. Thanks. > > B, > > Peng. > > > On Jul 9, 2012, at 12:35 PM, Dirk Kutscher wrote: > > Hi Peng and all,**** > ** ** > Thanks for the discussion.**** > ** ** > So, I think it=92s good to check the requirements and assess > draft-farrell-decade-ni accordingly. I personally that it meets the ones > you listed in your earlier message.**** > ** ** > One of the interesting features is that the NI specification defines a > common format that enables the integration of hashes (or other > cryptographic functions=92 output) into names and corresponding validatio= n > steps on nodes. The explicit signaling of the function that is actually > used allows for application-specific usage (if so needed) and for some > agility regarding crypto algorithms. A DECADE protocol specification coul= d > specify the usage of the scheme, MANDATORY to implement algorithms etc mo= re > specifically.**** > ** ** > One of the, IMO, important things that have not been discussed > sufficiently is the question about PPSP compatibility that Richard Yang > brought up.**** > ** ** > My view on this is as follows: the PPSP Merkle Hash Tree approach for > static and live content has requirements on the **object** and **meta-dat= a > ** format. For example, chunks have to carry sibling and uncle hashes. > Specifically, for live streaming with dynamic trees, chunks have to provi= de > chunk signatures (block signature, chunk position in the block, and the > digests of the sibling to the way to the root).**** > ** ** > For both static object and live streaming with > > --f46d04479559d1356104c472ec52 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Peng, Dirk,

I am cc'ing the ppsp list as well. Yo= u raised a good point on the distinction between one object and a sequence = of objects. To generalize, we can discuss even a set of objects (no orderin= g), and a set of equivalence objects (dynamic streaming that interleaves di= fferent resolutions). Your arguement against MTH is higher overhead in the = general case (end to end arguements). How much exactly is the overhead? Dec= ade may benefit from the analysis from ppsp. Since streaming is considered = as the main app, how much overhead if decade has to build on top?

Thanks!

Richard

On= Tuesday, July 10, 2012, Peng Zhang wrote:
Hi Dirk and all,

I agree that the NI specification= meets the basic requirement of DECADE (without optimization on "early= name generation").=A0

As for the= Merkle Hash Tree, or MTH, it is a integrity-assurance method for a sequenc= e of objects. It is critical to the PPSP protocol. But i wonder wether we s= hould incorporate it in our design:

First, DEC= ADE is targeted at general content distribution applications, and for appli= cations other than P2P streaming, there is no great value of using Merkle H= ash Tree. It may cause high overhead to these applications due "meta d= ata" including signatures and full hashes should be exchanged.=A0

Still, we = can discuss more on how to better incorporate PPSP based on NI without hurt= ing the general application of DECADE. Thanks.

B,<= /div>

Peng.


On Jul 9, = 2012, at 12:35 PM, Dirk Kutscher wrote:

=
Hi Peng and all,
=A0
Thanks for the discussion.
=A0
So, I think it=92s good to check the requirements an= d assess draft-farrell-decade-ni accordingly. I personally that it meets th= e ones you listed in your earlier message.
=A0
One of the interesting features is that the NI specificat= ion defines a common format that enables the integration of hashes (or othe= r cryptographic functions=92 output) into names and corresponding validatio= n steps on nodes. The explicit signaling of the function that is actually u= sed allows for application-specific usage (if so needed) and for some agili= ty regarding crypto algorithms. A DECADE protocol specification could speci= fy the usage of the scheme, MANDATORY to implement algorithms etc more spec= ifically.
=A0
One of the, IMO, important things that have not been disc= ussed sufficiently is the question about PPSP compatibility that Richard Ya= ng brought up.
=A0
My view on this is as follows: the PPSP Merkle Hash Tree = approach for static and live content has requirements on the *object= * and *meta-data* format. =A0For example, chunks have to carry sibli= ng and uncle hashes. Specifically, for live streaming with dynamic trees, c= hunks have to provide chunk signatures (block signature, chunk position in = the block, and the digests of the sibling to the way to the root).
=A0
For both static object and live streaming with
--f46d04479559d1356104c472ec52-- From zhangyunfei@chinamobile.com Tue Jul 10 01:25:46 2012 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 5C0D921F86CB for ; Tue, 10 Jul 2012 01:25:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.736 X-Spam-Level: X-Spam-Status: No, score=-97.736 tagged_above=-999 required=5 tests=[AWL=0.287, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6, MIME_BASE64_TEXT=1.753, RELAY_IS_221=2.222, 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 cnpI12VTfUgC for ; Tue, 10 Jul 2012 01:25:45 -0700 (PDT) Received: from imss.chinamobile.com (imss.chinamobile.com [221.130.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id E224F21F86C9 for ; Tue, 10 Jul 2012 01:25:44 -0700 (PDT) Received: from imss.chinamobile.com (localhost [127.0.0.1]) by localhost.chinamobile.com (Postfix) with ESMTP id 77B59E902; Tue, 10 Jul 2012 16:26:12 +0800 (CST) Received: from mail.chinamobile.com (unknown [10.1.28.22]) by imss.chinamobile.com (Postfix) with ESMTP id 688CAE8F3; Tue, 10 Jul 2012 16:26:12 +0800 (CST) Received: from zyf-PC ([10.1.5.3]) by mail.chinamobile.com (Lotus Domino Release 6.5.6) with ESMTP id 2012071016260877-40726 ; Tue, 10 Jul 2012 16:26:08 +0800 Date: Tue, 10 Jul 2012 16:26:06 +0800 From: zhangyunfei To: decade , "arno@cs.vu.nl" X-Priority: 3 (Normal) X-Mailer: Foxmail 7.0.1.85[cn] Mime-Version: 1.0 Message-ID: <20120710162606039401143@chinamobile.com> X-MIMETrack: Itemize by SMTP Server on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2012-07-10 16:26:08, Serialize by Router on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2012-07-10 16:26:11, Serialize complete at 2012-07-10 16:26:11 Content-Type: multipart/alternative; boundary="----=_001_NextPart002337256328_=----" X-TM-AS-Product-Ver: IMSS-7.0.0.8231-6.8.0.1017-19030.004 X-TM-AS-Result: No--17.592-7.0-31-10 X-imss-scan-details: No--17.592-7.0-31-10;No--17.592-7.0-31-10 X-TM-AS-User-Approved-Sender: No;No X-TM-AS-User-Blocked-Sender: No;No Subject: [decade] Fw: Re: [ppsp] Object naming in -req and -arch X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: zhangyunfei 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, 10 Jul 2012 08:25:46 -0000 This is a multi-part message in MIME format. ------=_001_NextPart002337256328_=---- Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="gb2312" QXJubydzIHJlcGx5IG9uIE1IVC4NCg0KQlINCll1bmZlaQ0KDQoNCg0KDQp6aGFuZ3l1bmZlaQ0K DQpGcm9tOiBBcm5vIEJha2tlcg0KRGF0ZTogMjAxMi0wNy0xMCAxNTo0OQ0KVG86IHBwc3BAaWV0 Zi5vcmcNClN1YmplY3Q6IFJlOiBbcHBzcF0gW2RlY2FkZV0gT2JqZWN0IG5hbWluZyBpbiAtcmVx IGFuZCAtYXJjaA0KSGkgYWxsDQoNCkknbGwgdHJ5IHRvIGNsYXJpZnkgdGhlIHJhdGlvbmFsZSBh bmQgcHJhY3RpY2FsIG92ZXJoZWFkIG9mIHRoZSBNZXJrbGUgDQpIYXNoIFRyZWVzIGluIFBQU1Au IEZvciBzdGF0aWMgY29udGVudCwgTUhUcyBlbmFibGUgY29udGVudCBpbnRlZ3JpdHkgDQpwcm90 ZWN0aW9uIHVzaW5nIHNlbGYtY2VydGlmaWVkIG5hbWluZy4gVXNpbmcgYSBoYXNoIHRyZWUgaW5z dGVhZCBvZiBhIA0Kc2luZ2xlIGhhc2ggaXMgdXNlZnVsIGluIGFsbCBzaXR1YXRpb25zIHdoZXJl IHRoZSBjb250ZW50IGlzIGRpc3RyaWJ1dGVkDQppbiBwYXJ0cyAoPWEgc2VxdWVuY2Ugb2Ygb2Jq ZWN0cyBhcyB5b3UgbWVudGlvbiBpdCkgdGhhdCBhcmUgaW1tZWRpYXRlbHkgDQp1c2VkLiBJbiBw YXJ0aWN1bGFyLCB3aGVuIHRoZSBwYXJ0cyBhcmUgZGVsaXZlcmVkIHRvIGEgaGlnaGVyIGxldmVs IGFwcCANCnVwb24gcmVjZWlwdCB0aGV5IG11c3QgYmUgaW50ZWdyaXR5IGNoZWNrZWQgYmVmb3Jl aGFuZC4gVGhpcyBhcHBsaWVzIHRvIA0Kc3RyZWFtaW5nLCBidXQgcGVyaGFwcyBhbHNvIHRvIG90 aGVyIFAyUCBhcHBzIHVzaW5nIERFQ0FERS4NCg0KRXZlbiBpZiBwYXJ0cyBhcmUgbm90IGltbWVk aWF0ZWx5IHVzZWQsIGFuIGludGVncml0eSBjaGVjayBvbiBwYXJ0cyBjYW4gDQpoZWxwIHRvIGlt cHJvdmUgZWZmaWNpZW5jeSBpbiBhIFAyUCBjb250ZXh0LiBBbiBlbmQtdG8tZW5kIGludGVncml0 eSANCmNoZWNrIHdoZW4gdGhlIGNvbnRlbnQgaXMgY29tcGxldGVseSBkb3dubG9hZGVkIGlzIHN1 ZmZpY2llbnQsIGJ1dCBmb3INCmVmZmljaWVuY3kgaXQgd291bGQgYmUgbmljZSB0byBrbm93IGlm IHRoZSBpbmRpdmlkdWFsIHBhcnRzIGFyZSBjb3JyZWN0DQppbnN0ZWFkIG9mIGZpbmRpbmcgb3V0 IGF0IHRoZSBlbmQsIGVzcGVjaWFsbHkgZm9yIGxhcmdlIGNvbnRlbnQuDQoNCk5vdGUgdGhhdCBN ZXJrbGUgSGFzaCBUcmVlcyBzdXBwb3J0IGJvdGggcGFydGlhbCBhbmQgZW5kLXRvLWVuZCANCmlu dGVncml0eSBjaGVja3MuIFdoZW4gYSBwZWVyIGhhcyBhIGNvcHkgb2YgdGhlIGNvbnRlbnQgYW5k IHRoZSBuYW1lIG9mIA0KdGhlIG9iamVjdCAoPWl0cyByb290IGhhc2ggaW4gdGhlIE1IVCkgaGUg Y2FuIGNhbGN1bGF0ZSB0aGUgTUhUIGZyb20gdGhlIA0KY29udGVudCBhbmQgY29tcGFyZSB0aGUg Y2FsY3VsYXRlZCByb290IGhhc2ggdG8gdGhlIG5hbWUuIEhlIGRvZXMgbm90IA0KbmVlZCB0byBy ZWNlaXZlIGFueSBvZiB0aGUgaW50ZXJtZWRpYXJ5IGhhc2hlcyBmcm9tIG90aGVycywgaWYgdGhh dCBpcyANCm5vdCByZXF1aXJlZC4NCg0KV2hpY2ggYnJpbmdzIHVzIHRvIHRoZSB0b3BpYyBvZiBv dmVyaGVhZC4gQXMgZGlzY3Vzc2VkIGluIFNlYy4gNS41IG9mDQpodHRwOi8vd3d3LmlldGYub3Jn L2lkL2RyYWZ0LWlldGYtcHBzcC1wZWVyLXByb3RvY29sLTAyLnR4dA0KdGhlIHNpemUgb2YgdGhl IE1IVCBkZXBlbmRzIG9uIHRoZSBudW1iZXIgb2YgY2h1bmtzIChvYmplY3RzKSBhdCB0aGUgDQpi YXNlIG9mIHRoZSB0cmVlLiBUaGF0IG51bWJlciBkZXBlbmRzIG9uIHRoZSBzaXplIG9mIHRoZSBj aHVua3MgdGhhdCBhcmUgDQpwcm9jZXNzZWQgaW1tZWRpYXRlbHkgaW4gdGhlIFAyUCBhcHBsaWNh dGlvbi4gRm9yIFBQU1Agb3ZlciBVRFAgb3ZlciANCkV0aGVybmV0IHRoZXNlIGNodW5rcyBhcmUg c21hbGwuIEZvciBvdGhlciBQMlAgYXBwcyB0aGUgY2h1bmtzIG1heSBiZSANCmJpZ2dlci4NCg0K SG93IG11Y2ggb2YgdGhlIE1IVCB0cmVlIGFjdHVhbGx5IG5lZWRzIHRvIGJlIHNlbnQgb3ZlciB0 aGUgd2lyZSB0byBhIA0KcmVjZWl2aW5nIHBlZXIgZGVwZW5kcyBvbiB0aGUgZG93bmxvYWQgcG9s aWN5IHVzZWQuIEZvciBhIGxpbmVhciANCmRvd25sb2FkIG9ubHkgcGFydCBvZiB0aGUgdHJlZSBu ZWVkcyB0byBiZSB0cmFuc21pdHRlZCwgYXMgdGhlIG90aGVyIA0KcGFydCBvZiB0aGUgdHJlZSBp cyBjYWxjdWxhdGVkIGJ5IHRoZSByZWNlaXZpbmcgcGVlciB3aGlsZSBkb3dubG9hZGluZy4NCklu IHRoZSBleGFtcGxlIGluIFNlYy4gNS41LCBvbmx5IDcgb2YgdGhlIDE2IGhhc2hlcyBpbiB0aGUg dHJlZSBhcmUgDQphY3R1YWxseSB0cmFuc21pdHRlZC4NCg0KTm90ZSB0aGF0IHN3aWZ0LCB0aGUg cHJvdG9jb2wgb24gd2hpY2ggdGhlIFBQU1AgcGVlciBwcm90b2NvbCBpcyBiYXNlZCANCndhcyBh Y3R1YWxseSBkZXNpZ25lZCBhcyBhIGdlbmVyaWMgdHJhbnNwb3J0IHByb3RvY29sLCB1bmlmeWlu ZyByZWd1bGFyIA0KZG93bmxvYWRzLCBWT0QgYW5kIGxpdmUgc3RyZWFtaW5nLiBTbyBpdCBzdGls bCBzdXBwb3J0cyBlZmZpY2llbnQgDQpub24tc3RyZWFtaW5nIGRvd25sb2FkIHBvbGljaWVzIGxp a2UgQml0VG9ycmVudCdzIHJhcmVzdCBmaXJzdC4gSW4gb3RoZXIgDQp3b3JkcywgaXRzIG9yaWdp bnMgZml0cyB0aGUgZ2VuZXJhbCBkaXN0cmlidXRpb24gbmF0dXJlIG9mIERFQ0FERS4NCg0KUmVn YXJkcywNCiAgICAgIEFybm8NCg0KDQpPbiAxMC8wNy8yMDEyIDA3OjIzLCBZLiBSaWNoYXJkIFlh bmcgd3JvdGU6DQo+IEhpIFBlbmcsIERpcmssDQo+DQo+IEkgYW0gY2MnaW5nIHRoZSBwcHNwIGxp c3QgYXMgd2VsbC4gWW91IHJhaXNlZCBhIGdvb2QgcG9pbnQgb24gdGhlDQo+IGRpc3RpbmN0aW9u IGJldHdlZW4gb25lIG9iamVjdCBhbmQgYSBzZXF1ZW5jZSBvZiBvYmplY3RzLiBUbyBnZW5lcmFs aXplLA0KPiB3ZSBjYW4gZGlzY3VzcyBldmVuIGEgc2V0IG9mIG9iamVjdHMgKG5vIG9yZGVyaW5n KSwgYW5kIGEgc2V0IG9mDQo+IGVxdWl2YWxlbmNlIG9iamVjdHMgKGR5bmFtaWMgc3RyZWFtaW5n IHRoYXQgaW50ZXJsZWF2ZXMgZGlmZmVyZW50DQo+IHJlc29sdXRpb25zKS4gWW91ciBhcmd1ZW1l bnQgYWdhaW5zdCBNVEggaXMgaGlnaGVyIG92ZXJoZWFkIGluIHRoZQ0KPiBnZW5lcmFsIGNhc2Ug KGVuZCB0byBlbmQgYXJndWVtZW50cykuIEhvdyBtdWNoIGV4YWN0bHkgaXMgdGhlIG92ZXJoZWFk Pw0KPiBEZWNhZGUgbWF5IGJlbmVmaXQgZnJvbSB0aGUgYW5hbHlzaXMgZnJvbSBwcHNwLiBTaW5j ZSBzdHJlYW1pbmcgaXMNCj4gY29uc2lkZXJlZCBhcyB0aGUgbWFpbiBhcHAsIGhvdyBtdWNoIG92 ZXJoZWFkIGlmIGRlY2FkZSBoYXMgdG8gYnVpbGQgb24gdG9wPw0KPg0KPiBUaGFua3MhDQo+DQo+ IFJpY2hhcmQNCj4NCj4gT24gVHVlc2RheSwgSnVseSAxMCwgMjAxMiwgUGVuZyBaaGFuZyB3cm90 ZToNCj4NCj4gICAgIEhpIERpcmsgYW5kIGFsbCwNCj4NCj4gICAgIEkgYWdyZWUgdGhhdCB0aGUg Tkkgc3BlY2lmaWNhdGlvbiBtZWV0cyB0aGUgYmFzaWMgcmVxdWlyZW1lbnQgb2YNCj4gICAgIERF Q0FERSAod2l0aG91dCBvcHRpbWl6YXRpb24gb24gImVhcmx5IG5hbWUgZ2VuZXJhdGlvbiIpLg0K Pg0KPiAgICAgQXMgZm9yIHRoZSBNZXJrbGUgSGFzaCBUcmVlLCBvciBNVEgsIGl0IGlzIGEgaW50 ZWdyaXR5LWFzc3VyYW5jZQ0KPiAgICAgbWV0aG9kIGZvciBhIHNlcXVlbmNlIG9mIG9iamVjdHMu IEl0IGlzIGNyaXRpY2FsIHRvIHRoZSBQUFNQDQo+ICAgICBwcm90b2NvbC4gQnV0IGkgd29uZGVy IHdldGhlciB3ZSBzaG91bGQgaW5jb3Jwb3JhdGUgaXQgaW4gb3VyIGRlc2lnbjoNCj4NCj4gICAg IEZpcnN0LCBERUNBREUgaXMgdGFyZ2V0ZWQgYXQgZ2VuZXJhbCBjb250ZW50IGRpc3RyaWJ1dGlv bg0KPiAgICAgYXBwbGljYXRpb25zLCBhbmQgZm9yIGFwcGxpY2F0aW9ucyBvdGhlciB0aGFuIFAy UCBzdHJlYW1pbmcsIHRoZXJlDQo+ICAgICBpcyBubyBncmVhdCB2YWx1ZSBvZiB1c2luZyBNZXJr bGUgSGFzaCBUcmVlLiBJdCBtYXkgY2F1c2UgaGlnaA0KPiAgICAgb3ZlcmhlYWQgdG8gdGhlc2Ug YXBwbGljYXRpb25zIGR1ZSAibWV0YSBkYXRhIiBpbmNsdWRpbmcgc2lnbmF0dXJlcw0KPiAgICAg YW5kIGZ1bGwgaGFzaGVzIHNob3VsZCBiZSBleGNoYW5nZWQuDQo+DQo+ICAgICBTdGlsbCwgd2Ug Y2FuIGRpc2N1c3MgbW9yZSBvbiBob3cgdG8gYmV0dGVyIGluY29ycG9yYXRlIFBQU1AgYmFzZWQN Cj4gICAgIG9uIE5JIHdpdGhvdXQgaHVydGluZyB0aGUgZ2VuZXJhbCBhcHBsaWNhdGlvbiBvZiBE RUNBREUuIFRoYW5rcy4NCj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQpwcHNwIG1haWxpbmcgbGlzdA0KcHBzcEBpZXRmLm9yZw0KaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wcHNw ------=_001_NextPart002337256328_=---- Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="gb2312"
Arno's reply on MHT.
 
BR
Yunfei
 
zhangyunfei
 
From: Arno Bakker
Date: 2012-07-10 15:49
To: ppsp@ietf.org
Subject: Re: [ppsp] [decade] Object naming in -req and=20 -arch
Hi all
 
I'll try to clarify the rationale and&n= bsp;practical overhead of the Merkle 
Hash Trees in PPSP. For static content,=  MHTs enable content integrity 
protection using self-certified naming. Using&nbs= p;a hash tree instead of a 
single hash is useful in all situations=  where the content is distributed
in parts (=3Da sequence of objects as&n= bsp;you mention it) that are immediately 
used. In particular, when the parts are=  delivered to a higher level app 
upon receipt they must be integrity che= cked beforehand. This applies to 
streaming, but perhaps also to other P2= P apps using DECADE.
 
Even if parts are not immediately used,=  an integrity check on parts can 
help to improve efficiency in a P2P&nbs= p;context. An end-to-end integrity 
check when the content is completely do= wnloaded is sufficient, but for
efficiency it would be nice to know&nbs= p;if the individual parts are correct
instead of finding out at the end, = ;especially for large content.
 
Note that Merkle Hash Trees support bot= h partial and end-to-end 
integrity checks. When a peer has a&nbs= p;copy of the content and the name of&n= bsp;
the object (=3Dits root hash in the&nbs= p;MHT) he can calculate the MHT from th= e 
content and compare the calculated root = ;hash to the name. He does not 
need to receive any of the intermediary=  hashes from others, if that is 
not required.
 
Which brings us to the topic of ov= erhead. As discussed in Sec. 5.5 of
http://www.ietf.org/id/draft-ietf-ppsp-peer-protocol-02.txt
the size of the MHT depends on the=  number of chunks (objects) at the 
base of the tree. That number depends&n= bsp;on the size of the chunks that are&= nbsp;
processed immediately in the P2P application= . For PPSP over UDP over 
Ethernet these chunks are small. For ot= her P2P apps the chunks may be 
bigger.
 
How much of the MHT tree actually = needs to be sent over the wire to = a 
receiving peer depends on the download = policy used. For a linear 
download only part of the tree needs&nb= sp;to be transmitted, as the other 
part of the tree is calculated by = the receiving peer while downloading.
In the example in Sec. 5.5, only 7=  of the 16 hashes in the tree are&= nbsp;
actually transmitted.
 
Note that swift, the protocol on which&= nbsp;the PPSP peer protocol is based 
was actually designed as a generic tran= sport protocol, unifying regular 
downloads, VOD and live streaming. So i= t still supports efficient 
non-streaming download policies like BitTorrent's=  rarest first. In other 
words, its origins fits the general dis= tribution nature of DECADE.
 
Regards,
      Arno
 
 
On 10/07/2012 07:23, Y. Richard Yang wr= ote:
> Hi Peng, Dirk,
>
> I am cc'ing the ppsp list as&= nbsp;well. You raised a good point on t= he
> distinction between one object and = ;a sequence of objects. To generalize,
> we can discuss even a set of&= nbsp;objects (no ordering), and a set of
> equivalence objects (dynamic streaming = that interleaves different
> resolutions). Your arguement against MT= H is higher overhead in the
> general case (end to end arguement= s). How much exactly is the overhead?
> Decade may benefit from the analys= is from ppsp. Since streaming is
> considered as the main app, how&nb= sp;much overhead if decade has to build = ;on top?
>
> Thanks!
>
> Richard
>
> On Tuesday, July 10, 2012, Peng&nb= sp;Zhang wrote:
>
>     Hi Dirk and all,
>
>     I agree that the&nbs= p;NI specification meets the basic requirement&nb= sp;of
>     DECADE (without optimizat= ion on "early name generation").
>
>     As for the Merkle&nb= sp;Hash Tree, or MTH, it is a integrity= -assurance
>     method for a sequenc= e of objects. It is critical to the&nbs= p;PPSP
>     protocol. But i wond= er wether we should incorporate it in o= ur design:
>
>     First, DECADE is tar= geted at general content distribution
>     applications, and for&nbs= p;applications other than P2P streaming, there
>     is no great value&nb= sp;of using Merkle Hash Tree. It may ca= use high
>     overhead to these ap= plications due "meta data" including signatures
>     and full hashes shou= ld be exchanged.
>
>     Still, we can discus= s more on how to better incorporate PPS= P based
>     on NI without hurtin= g the general application of DECADE. Thanks.=
>
_______________________________________________
ppsp mailing list
ppsp@ietf.org
https://www.ietf.org/mailman/listinfo/ppsp
------=_001_NextPart002337256328_=------ From pzhang.thu@gmail.com Tue Jul 10 11:57:05 2012 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 2B27A11E80A2 for ; Tue, 10 Jul 2012 11:57:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.423 X-Spam-Level: X-Spam-Status: No, score=-2.423 tagged_above=-999 required=5 tests=[AWL=-1.175, BAYES_00=-2.599, HTML_MESSAGE=0.001, MPART_ALT_DIFF_COUNT=1.11, RCVD_IN_DNSWL_LOW=-1, SARE_LWSHORTT=1.24] 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 Qp7WuvrMDjNj for ; Tue, 10 Jul 2012 11:56:36 -0700 (PDT) Received: from mail-qa0-f44.google.com (mail-qa0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6720F21F86DF for ; Tue, 10 Jul 2012 11:56:36 -0700 (PDT) Received: by qadz3 with SMTP id z3so2520775qad.10 for ; Tue, 10 Jul 2012 11:57:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer; bh=7ROsthzOEGmxl/m6JToLgTNPDwb3d8ZIU7ry1gOoxI4=; b=y/7ZY9HAa7IYTymqi9eU8hmqPIzjFc1x2oH7LiK5Xmz5U1GGyPPREb/f4mMBu/1i5a rZ5ip/w91orcRD4FFyyFWLwlafZkn96IsEMHvNKtZgYiNTfZ08J5cbF4qfkw2s3cmsy0 UKc7em7zkF7LKNTOMZfX423dHjE9AkDfYNqIiMav6TwwL2Mq0LGZeSgyF2tPm6xOUqhP 0i9yr8JuRbmobpWBdn+2Qr7g78HSaB+fFj0tQso6rPAXIs9fW3A6+ghA6o5Gi0zkFIOT sWZE3jAx8PXgO/B0mxzvmTUEN/ejQiesamfORBJfYuGEoItih68CPporE7sAZSwIrKAC KWGQ== Received: by 10.224.70.195 with SMTP id e3mr4515276qaj.86.1341946624230; Tue, 10 Jul 2012 11:57:04 -0700 (PDT) Received: from dhcp-128-36-159-196.central.yale.edu (dhcp-128-36-159-196.central.yale.edu. [128.36.159.196]) by mx.google.com with ESMTPS id ea5sm150055qab.2.2012.07.10.11.57.02 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 10 Jul 2012 11:57:03 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/alternative; boundary="Apple-Mail=_31A532B4-9764-49DB-9321-19798EB35C9B" From: Peng Zhang In-Reply-To: Date: Tue, 10 Jul 2012 14:57:01 -0400 Message-Id: References: <4FF867DE.7020609@cs.yale.edu> <374C8630-A970-4AE1-91DB-EAB9041C0980@gmail.com> <1A84DDEF-D3C0-48A1-AC3D-DC0E908861C2@gmail.com> To: Y. Richard Yang X-Mailer: Apple Mail (2.1278) Cc: "DECADE@ietf.org" , "Prof. Chuang Lin" Subject: Re: [decade] reorganized -req 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, 10 Jul 2012 18:57:05 -0000 --Apple-Mail=_31A532B4-9764-49DB-9321-19798EB35C9B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Hi Richard, Here is the revised version by me. I address my comments in this = version, please take a look. The txt file is that without acknowledgement included since i = don't have the ack.xml file. Please include it in the xml directly if = you revise it again. Thanks. Best, Peng. On Jul 10, 2012, at 12:57 AM, Y. Richard Yang wrote: > Hi Peng, >=20 > On Tuesday, July 10, 2012, Peng Zhang wrote: >=20 > On Jul 9, 2012, at 11:34 PM, Y. Richard Yang wrote: >=20 >> Hi Peng, >>=20 >> Thanks a lot for the feedback! Please see below. >>=20 >> On Tuesday, July 10, 2012, Zhang Peng wrote: >> Hi Richard and All, >>=20 >> Here are some comments on the recently revised version of = -req document. >>=20 >> First, I noticed that the protocol flow including DRP and SDT = is included in -req. I wonder if this is a good choice, since it is more = like a design rather than a requirement. Could someone explain the = rationale? >>=20 >> I feel that they represent a group of functions (and hence represent = two functional components). They help to organize the conceptual model. = The requirements do not use SDT and DRP. What do you think? > I still don't quite see the necessity of putting the design model = here. It is a little detailed to be here. >=20 > Then how about change the wording to say two functional components? I = can change it after you take a pass. Please revise .xml if you can. >=20 > Thanks! >=20 > Richard=20 >>=20 >> For the naming requirements, I suggest that the "the naming = scheme should support that consumer can validate the name-object = binding, i.e., can check that the object content is what the name claims = to be". The rationale is that consumer now obtains the object from = DECADE server, and in turn is uploaded by some content provider that is = not trustworthy. >>=20 >> Sounds good. >> =20 >> I suggest that the terminology 2.5 "Provider" should better = be "content provider". Otherwise, it may be confused with "DECADE = storage provider" of 2.3. Also, 2.9 is referring to "content provider", = not "provider". Correspondingly, "consumer" should be "content = consumer". But we should also comment that we would use shorter term = "provider" and "consumer" if there is no ambiguity. >>=20 >> I thought about this. It is not content provider but rather resource = provider, because A could allow B to upload to A's account, where A owns = the account resource. I am fine to go with Resource Provider though. > Yes, I think "resource provider" is a more precise definition. >> =20 >>=20 >> Section 7.2 is not so clear to me. The rationale has not = stated the reason for this very well. >>=20 >> I will take a look and get back soon. >> =20 >>=20 >> In section 8.1, the term "user" is not defined by us. Should = we use "client" instead? >>=20 >> Sounds good.=20 >>=20 >> In Section 9, should we also include "overload condition" = which appear in section 4.1.3.1 of current version? >>=20 >> I feel that overload is a type of insufficient resources. One = possibility is to distinguish between system overload and insufficient = inividual provider resources. What do you think? But this can be tricky = in that the system can be oversubscribed. So the error message may need = to indicate such.=20 > Maybe we should distinguish between them. For the insufficient = resource, it is due to not enough resources are allocated. By returning = this error message, the server may cause the consumer to ask for more = resource from the provider. While if it is due to system overload, the = error message may cause a redirection to other servers.=20 >=20 >>=20 >>=20 >> Some minor revisions: >>=20 >> - Section 2.3: "that" should be removed; >> - Section 6.1: Should be "After a DECADE-compatible = client owns an account on a DECADE-compatible server, it should be able = to read data from and write data to the server once authorized by the = server.", and it should be following section 6.2. >> - Section 6.2: I think it is better to be "Access to = an account on a server MUST be granted to a provider based on = cryptographic security" >> - Section 6.3 "resoutces" -> "resources" >> - Section 6.9 "disovery" -> "discovery" >> - Section 7.5 "enerate" -> "generate" >> - Section 8.4 "stoarge" -> "storage" >>=20 >>=20 >> It will be great if you can take a pass. Thanks a bunch! > You mean that I revise directly on .xml file? Thanks. >=20 > Best,=20 >=20 > Peng. >=20 >>=20 >> Richard=20 >>=20 >> I would like to help revise if you don't have time. >>=20 >> B, >>=20 >> Peng. >>=20 >>=20 >> On Jul 7, 2012, at 12:46 PM, Y. Richard Yang wrote: >>=20 >> > Dear all, >> > >> > We did a substantial reorganization of the -req documents. It is = attached to this email. Any early feedback will be greatly appreciated. >> > >> > Thanks! >> > >> > Richard >> > = >>=20 >=20 --Apple-Mail=_31A532B4-9764-49DB-9321-19798EB35C9B Content-Type: multipart/mixed; boundary="Apple-Mail=_163F196A-7DAC-432E-B474-893298549807" --Apple-Mail=_163F196A-7DAC-432E-B474-893298549807 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=iso-8859-1 Hi Richard,

Here is the revised version by me. I address my comments in this version, please take a look.
The txt file is that without acknowledgement included since i don't have the ack.xml file. Please include it in the xml directly if you revise it again. Thanks.

Best,

Peng.
--Apple-Mail=_163F196A-7DAC-432E-B474-893298549807 Content-Disposition: attachment; filename=draft-ietf-decade-reqs-all_v06.xml Content-Type: application/xml; name="draft-ietf-decade-reqs-all_v06.xml" Content-Transfer-Encoding: 7bit ]> DECADE Requirements Huawei
No. 101 Software Avenue Nanjing Jiangsu Province 210012 P.R.China +86-25-56624760 guyingjie@huawei.com
Polycom, Inc.
dbryan@ethernot.org
Yale University
yry@cs.yale.edu
Google
ralimi@google.com
Applications Area DECADE In-network storage P2P CDN Video on Demand VoD The target of the DECoupled Application Data Enroute (DECADE) system 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-compatible 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 a DECADE-compatible system architecture includes all of the desired functionality for intended applications. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in .
The object of the DECoupled Application Data Enroute (DECADE) system is to provide an open and standard in-network storage for content distribution applications, where data is typically broken into one or more chunks and then distributed. This may already include many types of applications including P2P applications, IPTV (Internet Protocol Television), and VoD (Video on Demand). (For a precise definition of the applications targeted in DECADE system, see the definition for Target Application in .) Instead of always transferring data directly from a source/owner client to a requesting client, the source/owner client can write to and manage its content on its in-network storage. The requesting client can get the address of the in-network storage pertaining to the source/owner client and read data from the storage. This draft enumerates and explains the rationale behind specific requirements on the protocol design and on any data store implementation that may be used to implement DECADE servers that should be considered during the design and implementation of a DECADE-compatible system. As such, it does not include general guiding principles. General design considerations, explanation of the problem being addressed, and enumeration of the types of applications to which a DECADE-compatible system may be suited is not considered in this document. For general information, please see and . This document enumerates the requirements to enable target applications to utilize in-network storage. In this context, using storage resources includes not only basic capabilities such as writing, reading, and managing data, but also controlling access for particular remote clients with which it is sharing data. Additionally, we also consider controlling the resources used by remote clients when they access data as an integral part of utilizing the network storage. This document discusses requirements pertaining to DECADE-compatible protocol(s). In certain deployments, several logical in-network storage systems could be deployed (e.g., within the same administrative domain). These in-network storage systems can communicate and transfer data through internal or non-standard communication messages that are outside of the scope of these requirements, but they should use DECADE-compatible protocol(s) when communicating with other DECADE-compatible in-network storage systems.
This document uses the term 'In-network storage' which is defined in . This document also defines these additional terms:
A DECADE-compatible client uploads and/or retrieves data from DECADE-compatible servers. We use the shorter term "client" if there is no ambiguity.
A DECADE-compatible server stores data inside the network, and thereafter manages both the stored data and access to those data. We use the shorter term "server" if there is no ambiguity.
A DECADE Storage Provider, or Storage Provider for short, deploys and/or manages DECADE-compatible server(s) within a network.
An account of a DECADE-compatible server has associated cryptographic credentials for access control, and resource allocation attributes on the server.
A client which has the account cryptographic credentials of a DECADE account at a DECADE-compatible server. We use the short term "provider" if there is no ambiguity.
A client which tries to access a DECADE account but does not have the account's cryptographic credentials. We use the short term "consumer" if there is no ambiguity.
A Content Distribution Application is an application (e.g., P2P, traditional CDN, or hybrid P2P/CDN) designed for dissemination of a large amounts of content (e.g., files, or video streams) to multiple content consumers. Content Distribution Applications may divide content into smaller blocks for dissemination.
An application with that includes a DECADE-compatible client along with other application functionalities to explicitly control the usage of resources of DECADE-compatible servers to deliver content to other users. A primary type of Target Application we consider is Content Distribution Applications. A Target Application divides content into smaller blocks for more flexible distribution (e.g., over multiple application-level paths). We use the term Target Application to refer to the type of applications that are explicitly (but not exclusively) supported by DECADE system.
An Application End-Point is an instance of a Target Application. A particular Application End-Point might be a Provider, a Consumer, or both. For example, an Application End-Point might be an instance of a video streaming client, or it might be the source providing the video to a set of clients.
A data object is the unit of data stored and retrieved from a DECADE-compatible server. The data object is a string of raw bytes. The server maintains metadata associated with each data object, but the metadata is not included in the data object.
A system which is composed of DECADE-compatible clients, DECADE-compatible servers and in-network storage. A DECADE-compatible system MUST obey all the requirements defined in this document.
A protocol that is responsible for communication of access control and resource scheduling policies from a DECADE client to a server, as well as between servers.
A protocol to be used to transfer data objects to and from a DECADE server.
Thus, to support such Target Applications, these behaviors must be logically separated from the data transfer operations (e.g., read, write).To organize the requirements, we consider that a DECADE-compatible system consists of two logical sets of functions, as shown in . The first set of functions, which we refer to as the DECADE Resource Protocol (DRP), is responsible for communication of access control and resource scheduling policies from a client to a server, as well as between servers. A DECADE-compatible system will include exactly one DRP for interoperability and a common format through which these policies can be communicated.
Native Application .-------------. Protocol(s) .-------------. | Application | <------------------> | Application | | End-Point | | End-Point | | | | | | .--------. | | .--------. | | | DECADE | | | | DECADE | | | | Client | | | | Client | | | `--------' | | `--------' | `-------------' `-------------' | ^ | ^ DECADE | | Standard | | Resource | | Data DRP | | SDT Protocol | | Transfer | | (DRP) | | (SDT) | | | | | | | | | | | | | | | | | | | | | | | | | | v V v V .=============. DRP .=============. | DECADE | <------------------> | DECADE | | Server | <------------------> | Server | `=============' SDT `============='
Second, the second set of functions, referred to as the Standard Data Transfer (SDT) protocol, will be used to transfer data objects to and from a server. A DECADE-compatible system may support multiple SDT's. If there are multiple SDT's, a negotiation mechanism will be used to determine a suitable SDT between the client and server. The two protocols (DRP and SDT) will be either separate or combined on the wire. If they are combined, DRP messages can be piggy-backed within some extension fields provided by certain SDT protocols. In such a scenario, DRP is technically a data structure (transported by other protocols), but it can still be considered as a logical protocol that provides the services of configuring DECADE-compatible resource usage. If the protocols are physically separate on the wire, DRP can take the form of a separate control connection open between the a DECADE-compatible client and server. Hence, this document considers SDT and DRP as two separate, logical functional components for clarity.
This document specifies the requirements for the DECADE DRP and SDT protocols, either existing ones or new ones, and storage system to enable Target Applications to make use of storage within the network, leaving specific storage system considerations to the implementation of the storage servers as much as possible. For this reason, we consider two primary categories of requirements: Protocol Requirements: Protocol requirements for Target Applications to make use of in-network storage within their own data dissemination schemes. Development of these requirements is guided by a study of data access, search and management capabilities used by Target Applications. These requirements may be met by a combination of existing protocols and new protocols. Storage Requirements: Functional requirements necessary for the back-end storage system employed by the DECADE server. Development of these requirements is guided by a study of the data access patterns used by Target Applications. These requirements should be met by the underlying data transport used by DECADE system. In this document, we use "data transport" to refer to a protocol used to read and write data from in-network storage. This specification discusses the requirements of functionality implemented with a storage system and within applications, to permit interoperable communications concerning the manipulation of stored content.
Each Data Object should be named to allow access. DECADE-compatible protocol(s) MUST support a data object naming scheme that ensures a high probability of uniqueness, with no coordination among multiple Storage Providers. In other words, two Data Objects with the same name should be the same content with high probability. A DECADE-compatible server SHOULD be able to respond to a DECADE-compatible client with an error indicating potential name conflicts. Although the intention of unique names is to avoid name collisions, it does not have to be an absolutely zero possibility. Hence, it is required to provide a collision handling mechanism. While a DECADE-compatible server is overloaded or consider a request as an attack, it does not to generate a response to indicate name collisions.
The name of each object SHOULD support the verification of the name-object binding, i.e., the object really corresponds to the name that was used for requesting it. The object requested by the client may not be directly uploaded by the original publisher, but by other untrustworthy clients (e.g., via P2P).
DECADE MUST allow for efficient storage and data transfer of small data objects (e.g., 16KB) without large control overhead. Though Target Applications are frequently used to share large amounts of data (e.g., continuous streams or large files), the data itself is typically subdivided into smaller data objects (chunks) for flexibility (e.g., reliability and multi-path transmission).
DECADE MUST support the ability to associate a set of system attributes with a data object with a scope local to a DECADE-compatible server. In particular, the set MUST include time-to-live (or expiration time), creation timestamp, object size, and object type. A DECADE-compatible client, with access permission, MUST be able to query the set of system attributes. The transmission of the attributes MUST use an operating system-independent and architecture-independent standard format. An ability to extend the set of attributes MUST exist. The values of attributes associated with a data object are local to a particular DECADE-compatible server. These attributes may be used as hints to the storage system, internal optimizations, or as additional information query-able by DECADE-compatible clients. The particular requirement for including time-to-live (TTL) is that a data object written by a DECADE-compatible client may be usable only within a certain window of time, such as in a live-streaming P2P application. Providing a time-to-live value for a data object (e.g., at the time it is written) can reduce management overhead by avoiding many 'delete' commands sent to DECADE-compatible server. The server may still retain a data object for bandwidth optimization, but this should be guided by the privacy policy of the DECADE Storage Provider.
DECADE-compatible clients and DECADE-compatible servers MUST NOT be able to associate Application-defined properties (metadata) with data objects beyond what is provided by . Associating key-value pairs that are defined by Target Applications with data objects introduces substantial complexity. If Target Applications wish to associate additional metadata with a data object, possible alternatives include (1) managing such metadata within the Target Application itself, (2) storing metadata inside the data object, or (3) storing metadata in a different data object at the DECADE-compatible server.
A Provider MUST be able to access the resources of its account. After a DECADE-compatible client owns an account on a DECADE-compatible server, it should be able to read data from and write data to the server.
Access to an account on a server MUST be granted to a provider based on cryptographic security. DECADE-compatible clients may be operating on hosts without constant network connectivity or without a permanent attachment address (e.g., mobile devices). To support access control with such hosts, DECADE-compatible servers must support access control policies that use cryptographic credentials, not simply by tying access to IP addresses.
A Provider MUST be able to indicate to its server on whether a Consumer can access its subscribed resources. Endpoints in Target Applications may choose different servers. Thus, to be useful by Target Applications, a DECADE-compatible client must be able to specify policies on whether other DECADE-compatible clients can access its resources. The other clients may or may not be known to the server.
A Provider MUST be able to grant access to a Consumer even if the Provider is not actively running or connected to its DECADE-compatible server. If an application desires, it can authorize other clients to access its storage even after the application exits or network connectivity is lost. An example use case is mobile scenarios, where a client can lose and regain network connectivity often.
A Provider MUST be able to indicate, without contacting its server, access control policies for Consumers. DECADE-compatible server MUST be able to authenticate the access control policies in this situation. This requirement is related with the preceding requirement, but in a perspective (i.e., protocol design). See discussions in .
A Provider MUST be able to control which individual clients are authorized to read/write which particular data objects from/to its in-network storage. A Target Application should able to conduct access control on the granularity of individual clients, individual data objects.
Unless read or write access is granted by a Provider, the default permission MUST be no access. This requirement is to protect client privacy by default.
A client that is authorized to access a server MUST be supported to conduct NAT (Network Address Translation) and firewall traversal. In particular, network connections between a DECADE-compatible client and a DECADE-compatible server MUST be initiated by the client (i.e., the server must not initiate a connection to the client). Firewalls and NATs are widely used in the Internet today, both in ISP (Internet Service Provider) and Enterprise networks and by consumers. Many firewalls and NATs are configured by default to block incoming connections, which helps to mitigate security risks. Deployment of a DECADE-compatible system must not require manual modifications to such devices. This requirement applies to both potential new protocol that may be developed by the DECADE Working Group and any data transport used with DECADE protocol.
A mechanism for a Provider to discover and connect to its assigned server MUST be supported. The discovery SHOULD leverage existing mechanisms and protocols wherever possible. No new discovery mechanism will be defined unless there is enough evidence that no existing mechanism can work. Existing protocols such as DNS and DHCP are widespread. Using existing protocols, or combinations of the protocols that have been specified in other contexts, is strictly preferred over developing a new discovery protocol.
A DECADE-compatible client MUST be able to negotiate with a DECADE-compatible server about which protocol it can use to read data from and write data. DECADE MUST specify at least one mandatory transport protocol to be supported by implementations; usage of a different protocol may be selected via negotiation. Since typical data transport protocols (e.g., NFS and WebDAV) already provide read and write operations for network storage, it may not be necessary to define such operations in a new DECADE protocol. However, because of the particular application requirements and deployment considerations, different applications may support different protocols. Thus, a DECADE client must be able to select an appropriate protocol also supported by the in-network storage.
A DECADE-compatible server MUST support the ability to read/write a complete data object in one request. It MAY support range read/write. Depending on the object size (e.g., chunk size) used by a Target Application, the application may need to send data to the DECADE-compatible server in multiple round.
A secure transport MUST be implemented for all communications between a DECADE-compatible client and DECADE-compatible server. Target Applications may wish to write sensitive data. To satisfy this use case, the communication between a DECADE-compatible client and DECADE-compatible server must be transported over a secure transport protocol (e.g., SSL/TLS).
A DECADE-compatible server MUST allow for multiple simultaneous readers for a data object. One characteristic of Target Applications is the ability to upload an object to multiple clients. Thus, it is natural for DECADE-compatible server to allow multiple readers to read the same object concurrently.
A DECADE-compatible server MUST NOT allow multiple simultaneous writers for the same object. A DECADE-compatible server SHOULD respond to each of the writers with an error. This avoids data corruption in a simple way while remaining efficient. Alternately, the DECADE-compatible server would need to either manage locking, handle write collisions, or merge data, all of which reduce efficiency and increase complexity. While a DECADE-compatible server is overloaded or considers a request as an attack, it does not generate a response.
A DECADE-compatible server MAY allow readers to read a data object before it has been completely written. In case of a write error in such a case, the DECADE-compatible server SHOULD respond to the reading client with an error indicating that the write has failed. Some Target Applications (in particular, P2P streaming) can be sensitive to latency. A technique to reduce latency is to remove store-and-forward delays for data objects (e.g., make the object available before it is completely written). Appropriate handling for error conditions (e.g., a disappearing writer) needs to be specified. While a DECADE-compatible server is overloaded or considers a request as an attack, it does not generate a response.
A DECADE-compatible server SHOULD be able to redirect requests to another DECADE-compatible server. This may either be in response to an error, failure, overload, or to support capabilities such as load balancing. A DECADE-compatible server may opt to redirect requests to another server to support capabilities such as load balancing, or if the implementation decides that another DECADE-compatible server is in a better position to handle the request due to either its location in the network, server status, or other consideration. A DECADE-compatible server can be configured by its service provider to support or not support redirection functionality.
A client MUST be able to indicate to a DECADE-compatible server about resource sharing policies among multiple Target Applications being run/managed by the same client. A client owning a DECADE account may provide the account's cryptographic credentials to multiple Providers of multiple target applications. For example, the client may run one or more video-on-demand application(s) and a live-streaming application(s) which both make use of the client's in-network storage. The concurrently running applications may be running on different machines (e.g., multiple machines at the same home network) and may not directly communicate, except through user coordination
A Provider MUST be able to specify resource policies (bandwidth share, storage quota, and network connection quota) to individual Consumers for reading from and writing data to its in-network storage within a particular range of time. Target Applications can rely on control of resources on a per-client basis. For example, application policy may indicate that certain remote clients have a higher bandwidth share for receiving data . Additionally, bandwidth share for receiving data [LLSB08]. Additionally, certain data (e.g., chunks) may be distributed with a higher priority. As another example, when allowing a remote client to write data to a user's in-network storage, the remote client may be restricted to write less than 100MB of data in total. Since the client may need to manage multiple clients accessing its data, it should be able to indicate the time over which the granted resources are usable. For example, an expiration time for the access could be indicated to the DECADE-compatible server after which no resources are granted (e.g., indicate error as access denied).
A Provider MUST be able to indicate to its DECADE-compatible server, without itself contacting the server, resource control policies for a Consumer. The DECADE-compatible server MUST be able to authenticate the resource control policies. One important consideration for a DECADE-compatible server is scalability, since a single storage element may be used to support many users. Many Target Applications use small chunk sizes and frequent data exchanges. If such an application employed resource control and contacted the DECADE-compatible server for each data exchange, this could present a scalability challenge for the server as well as additional latency for clients. The preferred way is to let requesting clients obtain signed resource control policies (in the form of a token) from the owning client, and then requesting clients can present the policy to a DECADE-compatible server directly. This can result in reduced messaging handled by the DECADE-compatible server.
A DECADE-compatible server MUST allow specification on the following resources: storage, bandwidth, and number of connections, and MAY allow additional types of resources to be specified. The minimum set of resources need to include the most common resources.
A DECADE-compatible server SHOULD provide an error indicating that (1) data was rejected from being written, (2) deleted, or (3) marked unavailable. DECADE Storage Providers may require the ability to (1) avoid storing, (2) delete, or (3) quarantine certain data that has been identified as illegal (or otherwise prohibited). It is not specified how such data is identified, but applications employing DECADE-compatible servers should not break if a Storage Provider is obligated to enforce such policies. Appropriate error conditions should be indicated to applications. A DECADE-compatible server should be able to be configured to suppress Illegal Data Object responses for security reasons.
A DECADE-compatible server SHOULD provide an error indicating that the request does not have a valid access authorization. DECADE-compatible clients may request data objects to which they do not have a valid authorization, and DECADE-compatible servers should be able to signal that this has occurred. Invalid authorization may be due to a combination of credential issues as well as additional policies defined by a Storage Provider. A DECADE-compatible server should be able to be configured to suppress Invalid Authorization responses for security reasons.
A DECADE-compatible server SHOULD provide a response indicating to a DECADE-compatible client that resources (e.g., storage space) were not available to service its request (e.g., storage quota exceeded when attempting to write data). The Insufficient Resources response allows a client to back off, free up necessary resources or waiting for such resources to be freed. A DECADE-compatible server may not provide such a response if doing so increases the load or due to security concerns.
A DECADE-compatible server, which is operating close to its capacity limit (e.g., too busy servicing other requests), MUST be permitted to reject requests and not be required to generate response to additional requests. A DECADE-compatible server MUST also be permitted to redirect requests (see Section 4.1.3.5) as a load-shedding technique. The Insufficient Resources response allows a client to back off, free up necessary resources or waiting for such resources to be freed. A DECADE-compatible server may not provide such a response if doing so increases the load or due to security concerns.
A DECADE-compatible server MUST be permitted to reject suspicious requests and not be required to generate responses (e.g., if a client's rate of requests exceeds a pre-defined threshold). Malicious clients may attempt to attack a DECADE-compatible server by specifying many chunks to increase total throughput or inciting overload conditions. A DECADE-compatible server is permitted to reject or ignore requests that are deemed suspicious according to policies set by its DECADE service provider.
A Provider MUST be able to query the resource quota as well the current usage. The response from the server MUST include resource usage resulting from both the client's own usage and usage by other clients that have been authorized to read/write objects on that client's account. The resources used by a client are not necessarily directly-attached (e.g., disk, network interface, etc). Thus, the client cannot locally determine how much resources are being used. Before storing and retrieving data, a client should be able to determine which data is available (e.g., after an application restart).
The security model is an important component of a DECADE-compatible system. It is crucial for users to be able to manage and limit distribution of content to only authorized parties, and the mechanism needs to work on the general Internet which spans multiple administrative and security domains. Previous sections have enumerated detailed requirements, but this section discusses the overall approach and other considerations that do not merit requirements.
A DECADE-compatible server must validate an request to access the in-network storage.
DECADE-compatible Servers provide the ability to write raw data objects (subject to any policies instituted by the owner/administrator of the Storage Provider). Thus, DECADE-compatible clients may opt to encrypt data before it is transported to the server.
The particular resource control policy may be open to certain attacks by clients. For example by specifying many small chunks to increase total throughput or inciting overload conditions are techniques that may be used by a client.
There are no IANA considerations with this document.
&RFC2119; &decadeproblem; &decadearch; BitTorrent is an Auction: Analyzing and Improving BitTorrent's Incentives PPLive --Apple-Mail=_163F196A-7DAC-432E-B474-893298549807 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=iso-8859-1
--Apple-Mail=_163F196A-7DAC-432E-B474-893298549807 Content-Disposition: attachment; filename=draft-ietf-decade-reqs-all_v06.txt Content-Type: text/plain; name="draft-ietf-decade-reqs-all_v06.txt" Content-Transfer-Encoding: quoted-printable DECADE Y. Gu Internet-Draft Huawei Intended status: Informational D. Bryan Expires: January 7, 2013 Polycom, Inc. Y. Yang Yale University R. Alimi Google July 6, 2012 DECADE Requirements draft-ietf-decade-reqs-06 Abstract The target of the DECoupled Application Data Enroute (DECADE) system 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- compatible 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 a DECADE-compatible system architecture includes all of the desired functionality for intended applications. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months Gu, et al. Expires January 7, 2013 [Page 1] =0C Internet-Draft DECADE Requirements July 2012 and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on January 7, 2013. Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Gu, et al. Expires January 7, 2013 [Page 2] =0C Internet-Draft DECADE Requirements July 2012 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.1. DECADE-compatible Client . . . . . . . . . . . . . . . . . 6 2.2. DECADE-compatible Server . . . . . . . . . . . . . . . . . 6 2.3. DECADE Storage Provider . . . . . . . . . . . . . . . . . 6 2.4. DECADE Account . . . . . . . . . . . . . . . . . . . . . . 6 2.5. Resource Provider . . . . . . . . . . . . . . . . . . . . 6 2.6. Resource Consumer . . . . . . . . . . . . . . . . . . . . 6 2.7. Content Distribution Application . . . . . . . . . . . . . 6 2.8. Target Application . . . . . . . . . . . . . . . . . . . . 7 2.9. Application End-Point . . . . . . . . . . . . . . . . . . 7 2.10. Data Object . . . . . . . . . . . . . . . . . . . . . . . 7 2.11. DECADE-compatible System . . . . . . . . . . . . . . . . . 7 2.12. DECADE Resource Protocol (DRP) . . . . . . . . . . . . . . 7 2.13. DECADE Standard Data Transfer Protocol (SDT) . . . . . . . 7 3. System and Protocol Components . . . . . . . . . . . . . . . . 8 4. Requirements Structure . . . . . . . . . . . . . . . . . . . . 9 5. Data Object Requirements . . . . . . . . . . . . . . . . . . . 9 5.1. Data Name Uniqueness . . . . . . . . . . . . . . . . . . . 10 5.2. Verifiable Name-Object Binding . . . . . . . . . . . . . . 10 5.3. Data Object Size . . . . . . . . . . . . . . . . . . . . . 10 5.4. Data Object Attributes . . . . . . . . . . . . . . . . . . 10 5.5. Application-defined Object Properties and Metadata . . . . 11 6. Access and Authorization Requirements . . . . . . . . . . . . 11 6.1. Provider Access . . . . . . . . . . . . . . . . . . . . . 11 6.2. Secure Authorization . . . . . . . . . . . . . . . . . . . 12 6.3. Consumer Access . . . . . . . . . . . . . . . . . . . . . 12 6.4. Provider Authorization When Offline . . . . . . . . . . . 12 6.5. Local Authorization . . . . . . . . . . . . . . . . . . . 12 6.6. Access Control Granularity . . . . . . . . . . . . . . . . 13 6.7. Default Access Permissions . . . . . . . . . . . . . . . . 13 6.8. Connectivity Supporting NAT and Firewall Traversal . . . . 13 6.9. DECADE Server Discovery . . . . . . . . . . . . . . . . . 13 7. Data Transfer Requirements . . . . . . . . . . . . . . . . . . 14 7.1. Negotiable Standard Data Transport Protocol . . . . . . . 14 7.2. Atomic or Partial Read/Write . . . . . . . . . . . . . . . 14 7.3. Secure Data Transport . . . . . . . . . . . . . . . . . . 14 7.4. Concurrent Read . . . . . . . . . . . . . . . . . . . . . 15 7.5. Concurrent Write . . . . . . . . . . . . . . . . . . . . . 15 7.6. Read Before Write Complete . . . . . . . . . . . . . . . . 15 7.7. Redirection of Transport . . . . . . . . . . . . . . . . . 16 8. Resource Control Requirements . . . . . . . . . . . . . . . . 16 8.1. Multiple Applications Sharing Resources . . . . . . . . . 16 8.2. Per-Client Resource Policy . . . . . . . . . . . . . . . . 16 8.3. Distributed Resource Sharing Specification . . . . . . . . 17 8.4. Resource Set . . . . . . . . . . . . . . . . . . . . . . . 17 Gu, et al. Expires January 7, 2013 [Page 3] =0C Internet-Draft DECADE Requirements July 2012 9. Error and Failure Handling Requirements . . . . . . . . . . . 17 9.1. Illegal Data Object . . . . . . . . . . . . . . . . . . . 18 9.2. Invalid Access Authorization . . . . . . . . . . . . . . . 18 9.3. Insufficient Resources . . . . . . . . . . . . . . . . . . 18 9.4. Overload Condition . . . . . . . . . . . . . . . . . . . . 19 9.5. Attack Mitigation . . . . . . . . . . . . . . . . . . . . 19 10. Management Info Requirements . . . . . . . . . . . . . . . . . 19 10.1. Account Status . . . . . . . . . . . . . . . . . . . . . . 19 11. Security Considerations . . . . . . . . . . . . . . . . . . . 20 11.1. Authentication and Authorization . . . . . . . . . . . . . 20 11.2. Confidentiality . . . . . . . . . . . . . . . . . . . . . 20 11.3. Attack Mitigation . . . . . . . . . . . . . . . . . . . . 20 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 13.1. Normative References . . . . . . . . . . . . . . . . . . . 21 13.2. Informative References . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 Gu, et al. Expires January 7, 2013 [Page 4] =0C Internet-Draft DECADE Requirements July 2012 1. Introduction The object of the DECoupled Application Data Enroute (DECADE) system is to provide an open and standard in-network storage for content distribution applications, where data is typically broken into one or more chunks and then distributed. This may already include many types of applications including P2P applications, IPTV (Internet Protocol Television), and VoD (Video on Demand). (For a precise definition of the applications targeted in DECADE system, see the definition for Target Application in Section 2.) Instead of always transferring data directly from a source/owner client to a requesting client, the source/owner client can write to and manage its content on its in-network storage. The requesting client can get the address of the in-network storage pertaining to the source/owner client and read data from the storage. This draft enumerates and explains the rationale behind specific requirements on the protocol design and on any data store implementation that may be used to implement DECADE servers that should be considered during the design and implementation of a DECADE-compatible system. As such, it does not include general guiding principles. General design considerations, explanation of the problem being addressed, and enumeration of the types of applications to which a DECADE-compatible system may be suited is not considered in this document. For general information, please see [I-D.ietf-decade-problem-statement] and [I-D.ietf-decade-arch]. This document enumerates the requirements to enable target applications to utilize in-network storage. In this context, using storage resources includes not only basic capabilities such as writing, reading, and managing data, but also controlling access for particular remote clients with which it is sharing data. Additionally, we also consider controlling the resources used by remote clients when they access data as an integral part of utilizing the network storage. This document discusses requirements pertaining to DECADE-compatible protocol(s). In certain deployments, several logical in-network storage systems could be deployed (e.g., within the same administrative domain). These in-network storage systems can communicate and transfer data through internal or non-standard communication messages that are outside of the scope of these requirements, but they should use DECADE-compatible protocol(s) when communicating with other DECADE-compatible in-network storage systems. Gu, et al. Expires January 7, 2013 [Page 5] =0C Internet-Draft DECADE Requirements July 2012 2. Terminology This document uses the term 'In-network storage' which is defined in [I-D.ietf-decade-problem-statement]. This document also defines these additional terms: 2.1. DECADE-compatible Client A DECADE-compatible client uploads and/or retrieves data from DECADE- compatible servers. We use the shorter term "client" if there is no ambiguity. 2.2. DECADE-compatible Server A DECADE-compatible server stores data inside the network, and thereafter manages both the stored data and access to those data. We use the shorter term "server" if there is no ambiguity. 2.3. DECADE Storage Provider A DECADE Storage Provider, or Storage Provider for short, deploys and/or manages DECADE-compatible server(s) within a network. 2.4. DECADE Account An account of a DECADE-compatible server has associated cryptographic credentials for access control, and resource allocation attributes on the server. 2.5. Resource Provider A client which has the account cryptographic credentials of a DECADE account at a DECADE-compatible server. We use the short term "provider" if there is no ambiguity. 2.6. Resource Consumer A client which tries to access a DECADE account but does not have the account's cryptographic credentials. We use the short term "consumer" if there is no ambiguity. 2.7. Content Distribution Application A Content Distribution Application is an application (e.g., P2P, traditional CDN, or hybrid P2P/CDN) designed for dissemination of a large amounts of content (e.g., files, or video streams) to multiple content consumers. Content Distribution Applications may divide Gu, et al. Expires January 7, 2013 [Page 6] =0C Internet-Draft DECADE Requirements July 2012 content into smaller blocks for dissemination. 2.8. Target Application An application with that includes a DECADE-compatible client along with other application functionalities to explicitly control the usage of resources of DECADE-compatible servers to deliver content to other users. A primary type of Target Application we consider is Content Distribution Applications. A Target Application divides content into smaller blocks for more flexible distribution (e.g., over multiple application-level paths). We use the term Target Application to refer to the type of applications that are explicitly (but not exclusively) supported by DECADE system. 2.9. Application End-Point An Application End-Point is an instance of a Target Application. A particular Application End-Point might be a Provider, a Consumer, or both. For example, an Application End-Point might be an instance of a video streaming client, or it might be the source providing the video to a set of clients. 2.10. Data Object A data object is the unit of data stored and retrieved from a DECADE- compatible server. The data object is a string of raw bytes. The server maintains metadata associated with each data object, but the metadata is not included in the data object. 2.11. DECADE-compatible System A system which is composed of DECADE-compatible clients, DECADE- compatible servers and in-network storage. A DECADE-compatible system MUST obey all the requirements defined in this document. 2.12. DECADE Resource Protocol (DRP) A protocol that is responsible for communication of access control and resource scheduling policies from a DECADE client to a server, as well as between servers. 2.13. DECADE Standard Data Transfer Protocol (SDT) A protocol to be used to transfer data objects to and from a DECADE server. Gu, et al. Expires January 7, 2013 [Page 7] =0C Internet-Draft DECADE Requirements July 2012 3. System and Protocol Components Thus, to support such Target Applications, these behaviors must be logically separated from the data transfer operations (e.g., read, write).To organize the requirements, we consider that a DECADE- compatible system consists of two logical sets of functions, as shown in Figure 1. The first set of functions, which we refer to as the DECADE Resource Protocol (DRP), is responsible for communication of access control and resource scheduling policies from a client to a server, as well as between servers. A DECADE-compatible system will include exactly one DRP for interoperability and a common format through which these policies can be communicated. Native Application .-------------. Protocol(s) .-------------. | Application | <------------------> | Application | | End-Point | | End-Point | | | | | | .--------. | | .--------. | | | DECADE | | | | DECADE | | | | Client | | | | Client | | | `--------' | | `--------' | `-------------' `-------------' | ^ | ^ DECADE | | Standard | | Resource | | Data DRP | | SDT Protocol | | Transfer | | (DRP) | | (SDT) | | | | | | | | | | | | | | | | | | | | | | | | | | v V v V .=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D. DRP = .=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D. | DECADE | <------------------> | DECADE | | Server | <------------------> | Server | `=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D' SDT = `=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D' Figure 1: Protocol Components and Generic Flow Second, the second set of functions, referred to as the Standard Data Transfer (SDT) protocol, will be used to transfer data objects to and from a server. A DECADE-compatible system may support multiple SDT's. If there are multiple SDT's, a negotiation mechanism will be used to determine a suitable SDT between the client and server. Gu, et al. Expires January 7, 2013 [Page 8] =0C Internet-Draft DECADE Requirements July 2012 The two protocols (DRP and SDT) will be either separate or combined on the wire. If they are combined, DRP messages can be piggy-backed within some extension fields provided by certain SDT protocols. In such a scenario, DRP is technically a data structure (transported by other protocols), but it can still be considered as a logical protocol that provides the services of configuring DECADE-compatible resource usage. If the protocols are physically separate on the wire, DRP can take the form of a separate control connection open between the a DECADE-compatible client and server. Hence, this document considers SDT and DRP as two separate, logical functional components for clarity. 4. Requirements Structure This document specifies the requirements for the DECADE DRP and SDT protocols, either existing ones or new ones, and storage system to enable Target Applications to make use of storage within the network, leaving specific storage system considerations to the implementation of the storage servers as much as possible. For this reason, we consider two primary categories of requirements: o Protocol Requirements: Protocol requirements for Target Applications to make use of in-network storage within their own data dissemination schemes. Development of these requirements is guided by a study of data access, search and management capabilities used by Target Applications. These requirements may be met by a combination of existing protocols and new protocols. o Storage Requirements: Functional requirements necessary for the back-end storage system employed by the DECADE server. Development of these requirements is guided by a study of the data access patterns used by Target Applications. These requirements should be met by the underlying data transport used by DECADE system. In this document, we use "data transport" to refer to a protocol used to read and write data from in-network storage. This specification discusses the requirements of functionality implemented with a storage system and within applications, to permit interoperable communications concerning the manipulation of stored content. 5. Data Object Requirements Gu, et al. Expires January 7, 2013 [Page 9] =0C Internet-Draft DECADE Requirements July 2012 5.1. Data Name Uniqueness REQUIREMENT(S): Each Data Object should be named to allow access. DECADE-compatible protocol(s) MUST support a data object naming scheme that ensures a high probability of uniqueness, with no coordination among multiple Storage Providers. In other words, two Data Objects with the same name should be the same content with high probability. A DECADE-compatible server SHOULD be able to respond to a DECADE-compatible client with an error indicating potential name conflicts. RATIONALE: Although the intention of unique names is to avoid name collisions, it does not have to be an absolutely zero possibility. Hence, it is required to provide a collision handling mechanism. EXCEPTION: While a DECADE-compatible server is overloaded or consider a request as an attack, it does not to generate a response to indicate name collisions. 5.2. Verifiable Name-Object Binding REQUIREMENT(S): The name of each object SHOULD support the verification of the name-object binding, i.e., the object really corresponds to the name that was used for requesting it. RATIONALE: The object requested by the client may not be directly uploaded by the original publisher, but by other untrustworthy clients (e.g., via P2P). 5.3. Data Object Size REQUIREMENT(S): DECADE MUST allow for efficient storage and data transfer of small data objects (e.g., 16KB) without large control overhead. RATIONALE: Though Target Applications are frequently used to share large amounts of data (e.g., continuous streams or large files), the data itself is typically subdivided into smaller data objects (chunks) for flexibility (e.g., reliability and multi-path transmission). 5.4. Data Object Attributes Gu, et al. Expires January 7, 2013 [Page 10] =0C Internet-Draft DECADE Requirements July 2012 REQUIREMENT(S): DECADE MUST support the ability to associate a set of system attributes with a data object with a scope local to a DECADE-compatible server. In particular, the set MUST include time-to-live (or expiration time), creation timestamp, object size, and object type. A DECADE-compatible client, with access permission, MUST be able to query the set of system attributes. The transmission of the attributes MUST use an operating system- independent and architecture-independent standard format. An ability to extend the set of attributes MUST exist. RATIONALE: The values of attributes associated with a data object are local to a particular DECADE-compatible server. These attributes may be used as hints to the storage system, internal optimizations, or as additional information query-able by DECADE- compatible clients. The particular requirement for including time-to-live (TTL) is that a data object written by a DECADE- compatible client may be usable only within a certain window of time, such as in a live-streaming P2P application. Providing a time-to-live value for a data object (e.g., at the time it is written) can reduce management overhead by avoiding many 'delete' commands sent to DECADE-compatible server. The server may still retain a data object for bandwidth optimization, but this should be guided by the privacy policy of the DECADE Storage Provider. 5.5. Application-defined Object Properties and Metadata REQUIREMENT(S): DECADE-compatible clients and DECADE-compatible servers MUST NOT be able to associate Application-defined properties (metadata) with data objects beyond what is provided by Section 5.4. RATIONALE: Associating key-value pairs that are defined by Target Applications with data objects introduces substantial complexity. If Target Applications wish to associate additional metadata with a data object, possible alternatives include (1) managing such metadata within the Target Application itself, (2) storing metadata inside the data object, or (3) storing metadata in a different data object at the DECADE-compatible server. 6. Access and Authorization Requirements 6.1. Provider Access Gu, et al. Expires January 7, 2013 [Page 11] =0C Internet-Draft DECADE Requirements July 2012 REQUIREMENT(S): A Provider MUST be able to access the resources of its account. RATIONALE: After a DECADE-compatible client owns an account on a DECADE-compatible server, it should be able to read data from and write data to the server. 6.2. Secure Authorization REQUIREMENT(S): Access to an account on a server MUST be granted to a provider based on cryptographic security. RATIONALE: DECADE-compatible clients may be operating on hosts without constant network connectivity or without a permanent attachment address (e.g., mobile devices). To support access control with such hosts, DECADE-compatible servers must support access control policies that use cryptographic credentials, not simply by tying access to IP addresses. 6.3. Consumer Access REQUIREMENT(S): A Provider MUST be able to indicate to its server on whether a Consumer can access its subscribed resources. RATIONALE: Endpoints in Target Applications may choose different servers. Thus, to be useful by Target Applications, a DECADE- compatible client must be able to specify policies on whether other DECADE-compatible clients can access its resources. The other clients may or may not be known to the server. 6.4. Provider Authorization When Offline REQUIREMENT(S): A Provider MUST be able to grant access to a Consumer even if the Provider is not actively running or connected to its DECADE-compatible server. RATIONALE: If an application desires, it can authorize other clients to access its storage even after the application exits or network connectivity is lost. An example use case is mobile scenarios, where a client can lose and regain network connectivity often. 6.5. Local Authorization REQUIREMENT(S): A Provider MUST be able to indicate, without contacting its server, access control policies for Consumers. DECADE-compatible server MUST be able to authenticate the access control policies in this situation. Gu, et al. Expires January 7, 2013 [Page 12] =0C Internet-Draft DECADE Requirements July 2012 RATIONALE: This requirement is related with the preceding requirement, but in a perspective (i.e., protocol design). See discussions in Section 8.3. 6.6. Access Control Granularity REQUIREMENT(S): A Provider MUST be able to control which individual clients are authorized to read/write which particular data objects from/to its in-network storage. RATIONALE: A Target Application should able to conduct access control on the granularity of individual clients, individual data objects. 6.7. Default Access Permissions REQUIREMENT(S): Unless read or write access is granted by a Provider, the default permission MUST be no access. RATIONALE: This requirement is to protect client privacy by default. 6.8. Connectivity Supporting NAT and Firewall Traversal REQUIREMENT(S): A client that is authorized to access a server MUST be supported to conduct NAT (Network Address Translation) and firewall traversal. In particular, network connections between a DECADE-compatible client and a DECADE-compatible server MUST be initiated by the client (i.e., the server must not initiate a connection to the client). RATIONALE: Firewalls and NATs are widely used in the Internet today, both in ISP (Internet Service Provider) and Enterprise networks and by consumers. Many firewalls and NATs are configured by default to block incoming connections, which helps to mitigate security risks. Deployment of a DECADE-compatible system must not require manual modifications to such devices. This requirement applies to both potential new protocol that may be developed by the DECADE Working Group and any data transport used with DECADE protocol. 6.9. DECADE Server Discovery REQUIREMENT(S): A mechanism for a Provider to discover and connect to its assigned server MUST be supported. The discovery SHOULD leverage existing mechanisms and protocols wherever possible. No new discovery mechanism will be defined unless there is enough evidence that no existing mechanism can work. Gu, et al. Expires January 7, 2013 [Page 13] =0C Internet-Draft DECADE Requirements July 2012 RATIONALE: Existing protocols such as DNS and DHCP are widespread. Using existing protocols, or combinations of the protocols that have been specified in other contexts, is strictly preferred over developing a new discovery protocol. 7. Data Transfer Requirements 7.1. Negotiable Standard Data Transport Protocol REQUIREMENT(S): A DECADE-compatible client MUST be able to negotiate with a DECADE-compatible server about which protocol it can use to read data from and write data. DECADE MUST specify at least one mandatory transport protocol to be supported by implementations; usage of a different protocol may be selected via negotiation. RATIONALE: Since typical data transport protocols (e.g., NFS and WebDAV) already provide read and write operations for network storage, it may not be necessary to define such operations in a new DECADE protocol. However, because of the particular application requirements and deployment considerations, different applications may support different protocols. Thus, a DECADE client must be able to select an appropriate protocol also supported by the in-network storage. 7.2. Atomic or Partial Read/Write REQUIREMENT(S): A DECADE-compatible server MUST support the ability to read/write a complete data object in one request. It MAY support range read/write. RATIONALE: Depending on the object size (e.g., chunk size) used by a Target Application, the application may need to send data to the DECADE-compatible server in multiple round. 7.3. Secure Data Transport REQUIREMENT(S): A secure transport MUST be implemented for all communications between a DECADE-compatible client and DECADE- compatible server. RATIONALE: Target Applications may wish to write sensitive data. To satisfy this use case, the communication between a DECADE- compatible client and DECADE-compatible server must be transported over a secure transport protocol (e.g., SSL/TLS). Gu, et al. Expires January 7, 2013 [Page 14] =0C Internet-Draft DECADE Requirements July 2012 7.4. Concurrent Read REQUIREMENT(S): A DECADE-compatible server MUST allow for multiple simultaneous readers for a data object. RATIONALE: One characteristic of Target Applications is the ability to upload an object to multiple clients. Thus, it is natural for DECADE-compatible server to allow multiple readers to read the same object concurrently. 7.5. Concurrent Write REQUIREMENT(S): A DECADE-compatible server MUST NOT allow multiple simultaneous writers for the same object. A DECADE-compatible server SHOULD respond to each of the writers with an error. RATIONALE: This avoids data corruption in a simple way while remaining efficient. Alternately, the DECADE-compatible server would need to either manage locking, handle write collisions, or merge data, all of which reduce efficiency and increase complexity. EXCEPTION: While a DECADE-compatible server is overloaded or considers a request as an attack, it does not generate a response. 7.6. Read Before Write Complete REQUIREMENT(S): A DECADE-compatible server MAY allow readers to read a data object before it has been completely written. In case of a write error in such a case, the DECADE-compatible server SHOULD respond to the reading client with an error indicating that the write has failed. RATIONALE: Some Target Applications (in particular, P2P streaming) can be sensitive to latency. A technique to reduce latency is to remove store-and-forward delays for data objects (e.g., make the object available before it is completely written). Appropriate handling for error conditions (e.g., a disappearing writer) needs to be specified. EXCEPTION: While a DECADE-compatible server is overloaded or considers a request as an attack, it does not generate a response. Gu, et al. Expires January 7, 2013 [Page 15] =0C Internet-Draft DECADE Requirements July 2012 7.7. Redirection of Transport REQUIREMENT(S): A DECADE-compatible server SHOULD be able to redirect requests to another DECADE-compatible server. This may either be in response to an error, failure, overload, or to support capabilities such as load balancing. RATIONALE: A DECADE-compatible server may opt to redirect requests to another server to support capabilities such as load balancing, or if the implementation decides that another DECADE-compatible server is in a better position to handle the request due to either its location in the network, server status, or other consideration. EXCEPTION: A DECADE-compatible server can be configured by its service provider to support or not support redirection functionality. 8. Resource Control Requirements 8.1. Multiple Applications Sharing Resources REQUIREMENT(S): A client MUST be able to indicate to a DECADE- compatible server about resource sharing policies among multiple Target Applications being run/managed by the same client. RATIONALE: A client owning a DECADE account may provide the account's cryptographic credentials to multiple Providers of multiple target applications. For example, the client may run one or more video-on-demand application(s) and a live-streaming application(s) which both make use of the client's in-network storage. The concurrently running applications may be running on different machines (e.g., multiple machines at the same home network) and may not directly communicate, except through user coordination 8.2. Per-Client Resource Policy REQUIREMENT(S): A Provider MUST be able to specify resource policies (bandwidth share, storage quota, and network connection quota) to individual Consumers for reading from and writing data to its in- network storage within a particular range of time. RATIONALE: Target Applications can rely on control of resources on a per-client basis. For example, application policy may indicate that certain remote clients have a higher bandwidth share for receiving data [LLSB08]. Additionally, bandwidth share for Gu, et al. Expires January 7, 2013 [Page 16] =0C Internet-Draft DECADE Requirements July 2012 receiving data [LLSB08]. Additionally, certain data (e.g., chunks) may be distributed with a higher priority. As another example, when allowing a remote client to write data to a user's in-network storage, the remote client may be restricted to write less than 100MB of data in total. Since the client may need to manage multiple clients accessing its data, it should be able to indicate the time over which the granted resources are usable. For example, an expiration time for the access could be indicated to the DECADE-compatible server after which no resources are granted (e.g., indicate error as access denied). 8.3. Distributed Resource Sharing Specification REQUIREMENT(S): A Provider MUST be able to indicate to its DECADE- compatible server, without itself contacting the server, resource control policies for a Consumer. The DECADE-compatible server MUST be able to authenticate the resource control policies. RATIONALE: One important consideration for a DECADE-compatible server is scalability, since a single storage element may be used to support many users. Many Target Applications use small chunk sizes and frequent data exchanges. If such an application employed resource control and contacted the DECADE-compatible server for each data exchange, this could present a scalability challenge for the server as well as additional latency for clients. The preferred way is to let requesting clients obtain signed resource control policies (in the form of a token) from the owning client, and then requesting clients can present the policy to a DECADE-compatible server directly. This can result in reduced messaging handled by the DECADE-compatible server. 8.4. Resource Set REQUIREMENT(S): A DECADE-compatible server MUST allow specification on the following resources: storage, bandwidth, and number of connections, and MAY allow additional types of resources to be specified. RATIONALE: The minimum set of resources need to include the most common resources. 9. Error and Failure Handling Requirements Gu, et al. Expires January 7, 2013 [Page 17] =0C Internet-Draft DECADE Requirements July 2012 9.1. Illegal Data Object REQUIREMENT(S): A DECADE-compatible server SHOULD provide an error indicating that (1) data was rejected from being written, (2) deleted, or (3) marked unavailable. RATIONALE: DECADE Storage Providers may require the ability to (1) avoid storing, (2) delete, or (3) quarantine certain data that has been identified as illegal (or otherwise prohibited). It is not specified how such data is identified, but applications employing DECADE-compatible servers should not break if a Storage Provider is obligated to enforce such policies. Appropriate error conditions should be indicated to applications. EXCEPTION: A DECADE-compatible server should be able to be configured to suppress Illegal Data Object responses for security reasons. 9.2. Invalid Access Authorization REQUIREMENT(S): A DECADE-compatible server SHOULD provide an error indicating that the request does not have a valid access authorization. RATIONALE: DECADE-compatible clients may request data objects to which they do not have a valid authorization, and DECADE- compatible servers should be able to signal that this has occurred. Invalid authorization may be due to a combination of credential issues as well as additional policies defined by a Storage Provider. EXCEPTION: A DECADE-compatible server should be able to be configured to suppress Invalid Authorization responses for security reasons. 9.3. Insufficient Resources REQUIREMENT(S): A DECADE-compatible server SHOULD provide a response indicating to a DECADE-compatible client that resources (e.g., storage space) were not available to service its request (e.g., storage quota exceeded when attempting to write data). RATIONALE: The Insufficient Resources response allows a client to back off, free up necessary resources or waiting for such resources to be freed. Gu, et al. Expires January 7, 2013 [Page 18] =0C Internet-Draft DECADE Requirements July 2012 EXCEPTION: A DECADE-compatible server may not provide such a response if doing so increases the load or due to security concerns. 9.4. Overload Condition REQUIREMENT(S): A DECADE-compatible server, which is operating close to its capacity limit (e.g., too busy servicing other requests), MUST be permitted to reject requests and not be required to generate response to additional requests. A DECADE-compatible server MUST also be permitted to redirect requests (see Section 4.1.3.5) as a load-shedding technique. RATIONALE: The Insufficient Resources response allows a client to back off, free up necessary resources or waiting for such resources to be freed. EXCEPTION: A DECADE-compatible server may not provide such a response if doing so increases the load or due to security concerns. 9.5. Attack Mitigation REQUIREMENT(S): A DECADE-compatible server MUST be permitted to reject suspicious requests and not be required to generate responses (e.g., if a client's rate of requests exceeds a pre- defined threshold). RATIONALE: Malicious clients may attempt to attack a DECADE- compatible server by specifying many chunks to increase total throughput or inciting overload conditions. A DECADE-compatible server is permitted to reject or ignore requests that are deemed suspicious according to policies set by its DECADE service provider. 10. Management Info Requirements 10.1. Account Status REQUIREMENT(S): A Provider MUST be able to query the resource quota as well the current usage. The response from the server MUST include resource usage resulting from both the client's own usage and usage by other clients that have been authorized to read/ write objects on that client's account. Gu, et al. Expires January 7, 2013 [Page 19] =0C Internet-Draft DECADE Requirements July 2012 RATIONALE: The resources used by a client are not necessarily directly-attached (e.g., disk, network interface, etc). Thus, the client cannot locally determine how much resources are being used. Before storing and retrieving data, a client should be able to determine which data is available (e.g., after an application restart). 11. Security Considerations The security model is an important component of a DECADE-compatible system. It is crucial for users to be able to manage and limit distribution of content to only authorized parties, and the mechanism needs to work on the general Internet which spans multiple administrative and security domains. Previous sections have enumerated detailed requirements, but this section discusses the overall approach and other considerations that do not merit requirements. 11.1. Authentication and Authorization A DECADE-compatible server must validate an request to access the in- network storage. 11.2. Confidentiality DECADE-compatible Servers provide the ability to write raw data objects (subject to any policies instituted by the owner/ administrator of the Storage Provider). Thus, DECADE-compatible clients may opt to encrypt data before it is transported to the server. 11.3. Attack Mitigation The particular resource control policy may be open to certain attacks by clients. For example by specifying many small chunks to increase total throughput or inciting overload conditions are techniques that may be used by a client. 12. IANA Considerations There are no IANA considerations with this document. 13. References Gu, et al. Expires January 7, 2013 [Page 20] =0C Internet-Draft DECADE Requirements July 2012 13.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [I-D.ietf-decade-problem-statement] Song, H., Zong, N., Yang, Y., and R. Alimi, "DECoupled Application Data Enroute (DECADE) Problem Statement", draft-ietf-decade-problem-statement-03 (work in progress), March 2011. 13.2. Informative References [I-D.ietf-decade-arch] Alimi, R., Yang, Y., Rahman, A., Kutscher, D., and H. Liu, "DECADE Architecture", draft-ietf-decade-arch-02 (work in progress), July 2011. [LLSB08] Levin, D., LaCurts, K., Spring, N., and B. Bhattacharjee, "BitTorrent is an Auction: Analyzing and Improving BitTorrent's Incentives", SIGCOMM 2008, August 2008. [PPLive] "PPLive", . Authors' Addresses Yingjie Gu Huawei No. 101 Software Avenue Nanjing, Jiangsu Province 210012 P.R.China Phone: +86-25-56624760 Email: guyingjie@huawei.com David A. Bryan Polycom, Inc. Email: dbryan@ethernot.org Yang Richard Yang Yale University Email: yry@cs.yale.edu Gu, et al. Expires January 7, 2013 [Page 21] =0C Internet-Draft DECADE Requirements July 2012 Richard Alimi Google Email: ralimi@google.com Gu, et al. Expires January 7, 2013 [Page 22] =0C --Apple-Mail=_163F196A-7DAC-432E-B474-893298549807 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=iso-8859-1

On Jul 10, 2012, at 12:57 AM, Y. Richard Yang wrote:

Hi Peng,

On Tuesday, July 10, 2012, Peng Zhang wrote:

On Jul 9, 2012, at 11:34 PM, Y. Richard Yang wrote:

Hi Peng,

Thanks a lot for the feedback! Please see below.

On Tuesday, July 10, 2012, Zhang Peng wrote:
Hi Richard and All,

        Here are some comments on the recently revised version of -req document.

        First, I noticed that the protocol flow including DRP and SDT is included in -req. I wonder if this is a good choice, since it is more like a design rather than a requirement. Could someone explain the rationale?

I feel that they represent a group of functions (and hence represent two functional components). They help to organize the conceptual model. The requirements do not use SDT and DRP. What do you think?
I still don't quite see the necessity of putting the design model here. It is a little detailed to be here.

Then how about change the wording to say two functional components? I can change it after you take a pass. Please revise .xml if you can.

Thanks!

Richard 

        For the naming requirements, I suggest that the "the naming scheme should support that consumer can validate the name-object binding, i.e., can check that the object content is what the name claims to be". The rationale is that consumer now obtains the object from DECADE server, and in turn is uploaded by some content provider that is not trustworthy.

Sounds good.
 
        I suggest that the terminology 2.5 "Provider" should better be "content provider". Otherwise, it may be confused with "DECADE storage provider" of 2.3. Also, 2.9 is referring to "content provider", not "provider". Correspondingly, "consumer" should be "content consumer". But we should also comment that we would use shorter term "provider" and "consumer" if there is no ambiguity.

I thought about this. It is not content provider but rather resource provider, because A could allow B to upload to A's account, where A owns the account resource. I am fine to go with Resource Provider though.
Yes, I think "resource provider" is a more precise definition.
 

        Section 7.2 is not so clear to me. The rationale has not stated the reason for this very well.

I will take a look and get back soon.
 

        In section 8.1, the term "user" is not defined by us. Should we use "client" instead?

Sounds good. 

        In Section 9, should we also include "overload condition" which appear in section 4.1.3.1 of current version?

I feel that overload is a type of insufficient resources. One possibility is to distinguish between system overload and insufficient inividual provider resources. What do you think? But this can be tricky in that the system can be oversubscribed. So the error message may need to indicate such. 
Maybe we should distinguish between them. For the insufficient resource, it is due to not enough resources are allocated. By returning this error message, the server may cause the consumer to ask for more resource from the provider. While if it is due to system overload, the error message may cause a redirection to other servers. 



        Some minor revisions:

                - Section 2.3: "that" should be removed;
                - Section 6.1:  Should be "After a DECADE-compatible client owns an account on a DECADE-compatible server, it should be able to read data from and write data to the server once authorized by the server.", and it should be following section 6.2.
                - Section 6.2: I think it is better to be "Access to an account on a server MUST be granted to a provider based on cryptographic security"
                - Section 6.3 "resoutces" -> "resources"
                - Section 6.9 "disovery" -> "discovery"
                - Section 7.5 "enerate" -> "generate"
                - Section 8.4 "stoarge" -> "storage"


It will be great if you can take a pass. Thanks a bunch!
You mean that I revise directly on .xml file? Thanks.

Best, 

Peng.


Richard 

        I would like to help revise if you don't have time.

B,

Peng.


On Jul 7, 2012, at 12:46 PM, Y. Richard Yang wrote:

> Dear all,
>
> We did a substantial reorganization of the -req documents. It is attached to this email. Any early feedback will be greatly appreciated.
>
> Thanks!
>
> Richard
> <draft-ietf-decade-reqs-all_v06.txt><draft-ietf-decade-reqs-all_v06.xml>



--Apple-Mail=_163F196A-7DAC-432E-B474-893298549807-- --Apple-Mail=_31A532B4-9764-49DB-9321-19798EB35C9B-- From pzhang.thu@gmail.com Wed Jul 11 14:24:36 2012 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 9B49D11E80EC for ; Wed, 11 Jul 2012 14:24:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.004 X-Spam-Level: X-Spam-Status: No, score=-3.004 tagged_above=-999 required=5 tests=[AWL=-0.006, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6, 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 PWLt0qyeOmIU for ; Wed, 11 Jul 2012 14:24:35 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1D8A611E80EA for ; Wed, 11 Jul 2012 14:24:35 -0700 (PDT) Received: by qcac10 with SMTP id c10so1179967qca.31 for ; Wed, 11 Jul 2012 14:25:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:x-priority:in-reply-to:date :cc:message-id:references:to:x-mailer; bh=K5wqYAmrcc8HHNraYHs8CFTUnV9iiTL5+VNdxhC7svQ=; b=JpdQu9k8H6AFqDY2EztEz0e/wUOr6LH+MHF/tMXG8xjzDOailU6bXgrKmfSojxqXDe Aq0ubS9iRrRwMTZT21elgzWrFVw0AqJAAxhgd+Um5oVwjvF6HRprWAjs9M4coJJzsH5M jeiFAi45mi9qcVSxprQCpYJ84PAeEXhpCJp2/aFv9OcX7yQIsy+LCWSj7xwjUlea+g9c JRk3+xfZ+jZGkFIA4HrKbxoqsJt1lcG9WF4JcRolKv7O3wkLMGb7SzFcVtbcfvFKTRbF GqDJIfCKZdFS6EuuBlITR3ezi6AXUgYLHYqrgUaWnMpv6kgAjtRs8thmQOQ6IZ5aCs7w tLTg== Received: by 10.229.111.78 with SMTP id r14mr10663024qcp.100.1342041906209; Wed, 11 Jul 2012 14:25:06 -0700 (PDT) Received: from dhcp-128-36-159-196.central.yale.edu (dhcp-128-36-159-196.central.yale.edu. [128.36.159.196]) by mx.google.com with ESMTPS id z9sm4490439qae.15.2012.07.11.14.25.04 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 11 Jul 2012 14:25:05 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/alternative; boundary="Apple-Mail=_1D44633D-74D8-451E-94C5-2E602888A4A5" From: Peng Zhang X-Priority: 3 (Normal) In-Reply-To: <20120710162606039401143@chinamobile.com> Date: Wed, 11 Jul 2012 17:25:03 -0400 Message-Id: <2039343B-5F6B-4777-864E-B4F00B5A258E@gmail.com> References: <20120710162606039401143@chinamobile.com> To: zhangyunfei X-Mailer: Apple Mail (2.1278) Cc: decade , arno@cs.vu.nl Subject: Re: [decade] [ppsp] Object naming in -req and -arch 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, 11 Jul 2012 21:24:36 -0000 --Apple-Mail=_1D44633D-74D8-451E-94C5-2E602888A4A5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=GB2312 Hi Arno, Thanks for the clarification. In my understanding, MHT over = single hash can enable immediate integrity check before the whole media = file is received, which is critical for streaming applications. But the = client can also download hashes of every piece, just like in BitTorrent. = Does it reduce a lot startup latency or server load by using MHT? = Thanks. For DECADE, It supports integrity check on piece/chunk level, so = that client can verify that the received piece corresponds to the piece = name. DECADE is unaware of what file this piece belongs to, and thus = does not provide end-to-end integrity check. For file level, we leave = the integrity check to applications. Thus, imo, we should not include = MHT in the design of DECADE. But MHT can be built on top of DECADE, = which means applications can still use MHT to implement integrity check = for themselves. B, Peng. On Jul 10, 2012, at 4:26 AM, zhangyunfei wrote: > Arno's reply on MHT. > =20 > BR > Yunfei > =20 > zhangyunfei > =20 > From: Arno Bakker > Date: 2012-07-10 15:49 > To: ppsp@ietf.org > Subject: Re: [ppsp] [decade] Object naming in -req and -arch > Hi all > =20 > I'll try to clarify the rationale and practical overhead of the Merkle=20= > Hash Trees in PPSP. For static content, MHTs enable content integrity=20= > protection using self-certified naming. Using a hash tree instead of a=20= > single hash is useful in all situations where the content is = distributed > in parts (=3Da sequence of objects as you mention it) that are = immediately=20 > used. In particular, when the parts are delivered to a higher level = app=20 > upon receipt they must be integrity checked beforehand. This applies = to=20 > streaming, but perhaps also to other P2P apps using DECADE > Even if parts are not immediately used, an integrity check on parts = can=20 > help to improve efficiency in a P2P context. An end-to-end integrity=20= > check when the content is completely downloaded is sufficient, but for > efficiency it would be nice to know if the individual parts are = correct > instead of finding out at the end, especially for large content. > =20 > Note that Merkle Hash Trees support both partial and end-to-end=20 > integrity checks. When a peer has a copy of the content and the name = of=20 > the object (=3Dits root hash in the MHT) he can calculate the MHT from = the=20 > content and compare the calculated root hash to the name. He does not=20= > need to receive any of the intermediary hashes from others, if that is=20= > not required. > =20 > Which brings us to the topic of overhead. As discussed in Sec. 5.5 of > http://www.ietf.org/id/draft-ietf-ppsp-peer-protocol-02.txt > the size of the MHT depends on the number of chunks (objects) at the=20= > base of the tree. That number depends on the size of the chunks that = are=20 > processed immediately in the P2P application. For PPSP over UDP over=20= > Ethernet these chunks are small. For other P2P apps the chunks may be=20= > bigger. > =20 > How much of the MHT tree actually needs to be sent over the wire to a=20= > receiving peer depends on the download policy used. For a linear=20 > download only part of the tree needs to be transmitted, as the other=20= > part of the tree is calculated by the receiving peer while = downloading. > In the example in Sec. 5.5, only 7 of the 16 hashes in the tree are=20 > actually transmitted. > =20 > Note that swift, the protocol on which the PPSP peer protocol is based=20= > was actually designed as a generic transport protocol, unifying = regular=20 > downloads, VOD and live streaming. So it still supports efficient=20 > non-streaming download policies like BitTorrent's rarest first. In = other=20 > words, its origins fits the general distribution nature of DECADE. > =20 > Regards, > Arno > =20 > =20 > On 10/07/2012 07:23, Y. Richard Yang wrote: > > Hi Peng, Dirk, > > > > I am cc'ing the ppsp list as well. You raised a good point on the > > distinction between one object and a sequence of objects. To = generalize, > > we can discuss even a set of objects (no ordering), and a set of > > equivalence objects (dynamic streaming that interleaves different > > resolutions). Your arguement against MTH is higher overhead in the > > general case (end to end arguements). How much exactly is the = overhead? > > Decade may benefit from the analysis from ppsp. Since streaming is > > considered as the main app, how much overhead if decade has to build = on top? > > > > Thanks! > > > > Richard > > > > On Tuesday, July 10, 2012, Peng Zhang wrote: > > > > Hi Dirk and all, > > > > I agree that the NI specification meets the basic requirement of > > DECADE (without optimization on "early name generation"). > > > > As for the Merkle Hash Tree, or MTH, it is a integrity-assurance > > method for a sequence of objects. It is critical to the PPSP > > protocol. But i wonder wether we should incorporate it in our = design: > > > > First, DECADE is targeted at general content distribution > > applications, and for applications other than P2P streaming, = there > > is no great value of using Merkle Hash Tree. It may cause high > > overhead to these applications due "meta data" including = signatures > > and full hashes should be exchanged. > > > > Still, we can discuss more on how to better incorporate PPSP = based > > on NI without hurting the general application of DECADE. Thanks. > > > _______________________________________________ > ppsp mailing list > ppsp@ietf.org > https://www.ietf.org/mailman/listinfo/ppsp --Apple-Mail=_1D44633D-74D8-451E-94C5-2E602888A4A5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=GB2312 Hi Arno,

Thanks = for the clarification. In my understanding, MHT over single hash = can enable immediate integrity check before the whole media file is = received, which is critical for streaming applications. But the = client can also download hashes of every piece, just like in BitTorrent. = Does it reduce a lot startup latency or server load by using = MHT? Thanks.

For DECADE, It supports integrity = check on piece/chunk level, so that client can verify that the received = piece corresponds to the piece name. DECADE is unaware of what file this = piece belongs to, and thus does not provide end-to-end integrity check. =  For file level, we leave the integrity check to applications. = Thus, imo, we should not include MHT in the design of DECADE. But MHT = can be built on top of DECADE, which means applications can still use = MHT to implement integrity check for = themselves.


B,

Peng.

On Jul 10, 2012, at 4:26 AM, = zhangyunfei wrote:

Arno's reply on = MHT.
 
BR
Yunfei
 
=
zhangyunfei
 
Date: 2012-07-10 15:49
Subject:&= nbsp;Re: [ppsp] [decade] Object naming in -req and = -arch
Hi all
 
I'= ll try to clarify the rationale and pra= ctical overhead of the Merkle 
Hash&nbs= p;Trees in PPSP. For static content, MHTs&nb= sp;enable content integrity 
protection usin= g self-certified naming. Using a hash tree&n= bsp;instead of a 
single hash is u= seful in all situations where the content&nb= sp;is distributed
in parts (=3Da sequence&nb= sp;of objects as you mention it) that a= re immediately 
used. In particular, wh= en the parts are delivered to a higher&= nbsp;level app 
upon receipt they must&= nbsp;be integrity checked beforehand. This applie= s to 
streaming, but perhaps also = to other P2P apps using DECADE
<= /span>
http:= //www.ietf.org/id/draft-ietf-ppsp-peer-protocol-02.txt
the&n= bsp;size of the MHT depends on the numb= er of chunks (objects) at the 
bas= e of the tree. That number depends on&n= bsp;the size of the chunks that are 
processed immediately in the P2P applicat= ion. For PPSP over UDP over 
Ether= net these chunks are small. For other P= 2P apps the chunks may be 
bigger.=
 
How much of the MHT t= ree actually needs to be sent over the&= nbsp;wire to a 
receiving peer depends&= nbsp;on the download policy used. For a = ;linear 
download only part of the = ;tree needs to be transmitted, as the o= ther 
part of the tree is calculat= ed by the receiving peer while downloading.<= /div>
In the example in Sec. 5.5, only&n= bsp;7 of the 16 hashes in the tree = ;are 
actually transmitted.
 
Note that swift, the protocol on which = ;the PPSP peer protocol is based 
= was actually designed as a generic transport=  protocol, unifying regular 
downloads, = ;VOD and live streaming. So it still su= pports efficient 
non-streaming download pol= icies like BitTorrent's rarest first. In oth= er 
words, its origins fits the ge= neral distribution nature of DECADE.
 <= /div>
Regards,
      Arno
 
 
On 10/07/2012 07:23,&nbs= p;Y. Richard Yang wrote:
> Hi Peng,&= nbsp;Dirk,
>
> I am cc'ing t= he ppsp list as well. You raised a = ;good point on the
> distinction bet= ween one object and a sequence of objec= ts. To generalize,
> we can discuss&= nbsp;even a set of objects (no ordering),&nb= sp;and a set of
> equivalence object= s (dynamic streaming that interleaves different
> resolutions). Your arguement against&nbs= p;MTH is higher overhead in the
>&nb= sp;general case (end to end arguements). How=  much exactly is the overhead?
>&nbs= p;Decade may benefit from the analysis from&= nbsp;ppsp. Since streaming is
> considere= d as the main app, how much overhead&nb= sp;if decade has to build on top?
= >
> Thanks!
>
> Richar= d
>
> On Tuesday, July 10,&n= bsp;2012, Peng Zhang wrote:
>
>&n= bsp;    Hi Dirk and all,
>=
>     I agree that t= he NI specification meets the basic requirem= ent of
>     DECADE (witho= ut optimization on "early name generation").
>
>     As for th= e Merkle Hash Tree, or MTH, it is = a integrity-assurance
>     met= hod for a sequence of objects. It is&nb= sp;critical to the PPSP
>   &nb= sp; protocol. But i wonder wether we sh= ould incorporate it in our design:
>=
>     First, DECADE is&nb= sp;targeted at general content distribution
= >     applications, and for app= lications other than P2P streaming, there
>     is no great value = ;of using Merkle Hash Tree. It may caus= e high
>     overhead to&n= bsp;these applications due "meta data" including&= nbsp;signatures
>     and full&= nbsp;hashes should be exchanged.
>
&= gt;     Still, we can discuss = ;more on how to better incorporate PPSP = ;based
>     on NI without=  hurting the general application of DECADE.&= nbsp;Thanks.
>
____________________________________= ___________
ppsp mailing list

= --Apple-Mail=_1D44633D-74D8-451E-94C5-2E602888A4A5-- From haibin.song@huawei.com Wed Jul 11 18:23:09 2012 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 61B6A21F84BD for ; Wed, 11 Jul 2012 18:23:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.308 X-Spam-Level: X-Spam-Status: No, score=-6.308 tagged_above=-999 required=5 tests=[AWL=0.291, 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 iSc6h1MLmnlB for ; Wed, 11 Jul 2012 18:23:08 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 832E921F84B6 for ; Wed, 11 Jul 2012 18:23:08 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AHR30090; Wed, 11 Jul 2012 21:23:40 -0400 (EDT) Received: from DFWEML403-HUB.china.huawei.com (10.193.5.151) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 11 Jul 2012 18:21:13 -0700 Received: from SZXEML436-HUB.china.huawei.com (10.72.61.64) by dfweml403-hub.china.huawei.com (10.193.5.151) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 11 Jul 2012 18:21:18 -0700 Received: from SZXEML534-MBX.china.huawei.com ([169.254.2.243]) by szxeml436-hub.china.huawei.com ([10.72.61.64]) with mapi id 14.01.0323.003; Thu, 12 Jul 2012 09:21:16 +0800 From: Songhaibin To: "decade@ietf.org" Thread-Topic: NomCom 2012-13 Call for Volunteers Thread-Index: AQHNW7yR5UYmdVRVtUq1ugS+tkxCtpcdWxiAgAeGfLA= Date: Thu, 12 Jul 2012 01:21:15 +0000 Message-ID: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.73] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [decade] FW: NomCom 2012-13 Call for Volunteers 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, 12 Jul 2012 01:23:09 -0000 > -------- Original Message -------- > Subject: NomCom 2012-13 Call for Volunteers > Date: Fri, 06 Jul 2012 14:15:33 -0700 > From: NomCom Chair > To: IETF Announcement List >=20 > The IETF nominating committee process for 2012-13 has begun. The IETF > nominating committee appoints folks to fill the open slots on the > IAOC, the IAB, and the IESG. The 10 nominating committee members are > selected randomly from a pool of volunteers. The more volunteers, the > better chance we have of choosing a random yet representative cross > section of the IETF population. The details of the operation of the > nomcom can be found in RFC 3777. >=20 > To be eligible, volunteers for the nomcom need to have attended 3 of > the past 5 IETF meetings as of the time this announcement goes out. > That is, 3 meetings from IETF 79 (Beijing) - IETF 83 (Paris). If you > qualify, and if you will not be seeking appointment to any of the open > positions that this nomcom will be filling, please consider > volunteering. >=20 > The list of people whose terms end with the March 2013 IETF meeting, > and thus the positions for which the nominating committee is > responsible for filling, are as follows: >=20 > IAOC: > -------- > Dave Crocker >=20 > IAB: > -------- > Alissa Cooper > Joel Halpern > David Kessens > Danny McPherson > Jon Peterson > Dave Thaler >=20 > IESG: > -------- > Russ Housley (General Area) > Pete Resnick (Applications Area) > Ralph Droms (Internet Area) > Ronald Bonica (Operations and Management Area) > Robert Sparks (Real-Time Applications and Infrastructure Area) > Adrian Farrel (Routing Area) > Stephen Farrell (Security Area) > Wesley Eddy (Transport Area) >=20 > The primary activity for this nomcom will begin in August 2012 and > should be completed in January 2013. The nomcom will be collecting > requirements from the community, as well as talking to candidates and > obtaining feedback from community members about candidates. There will > be regularly scheduled conference calls to ensure progress. Thus, > being a nomcom member does require some time commitment. >=20 > Please volunteer by sending an email before 11:59 pm EDT (UTC - 4 > hours) August 5, 2012 as follows: >=20 > To: mlepinski.ietf@gmail.com > Subject: Nomcom 2012-13 Volunteer >=20 > Please include the following information in the body: >=20 > // As you enter in the IETF Registration Form, > // First/Given name followed by Last/Family Name > > // typically what goes in the Company field > // in the IETF Registration Form > [] > // > // For confirmation if selected >=20 > Please expect an email response from me within 3 business days stating > whether or not you are qualified. If you don't receive a response, > please re-send your email with the tag "RESEND:" added to the subject > line. >=20 > If you are not yet sure you would like to volunteer, please consider > that nomcom members play a very important role in shaping the > leadership of the IETF. Ensuring the leadership of the IETF is fair > and balanced and comprised of those who can lead the IETF in the right > direction is an important responsibility that rests on the IETF > participants at large. Volunteering for the nomcom is a good way of > contributing toward that goal. >=20 > I will be publishing a more detailed timetable for nomcom activities, > as well as details of the randomness seeds to be used for the RFC 3797 > selection process, within the next couple weeks. >=20 > Thank you, > Matthew Lepinski > mlepinski.ietf@gmail.com > nomcom-chair@ietf.org From zhangyunfei@chinamobile.com Wed Jul 11 18:52:34 2012 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 3EB7211E8123; Wed, 11 Jul 2012 18:52:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -94.115 X-Spam-Level: X-Spam-Status: No, score=-94.115 tagged_above=-999 required=5 tests=[AWL=-3.387, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RELAY_IS_221=2.222, 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 fcsJis3oZP1E; Wed, 11 Jul 2012 18:52:33 -0700 (PDT) Received: from imss.chinamobile.com (imss.chinamobile.com [221.130.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id A336811E8120; Wed, 11 Jul 2012 18:52:32 -0700 (PDT) Received: from imss.chinamobile.com (localhost [127.0.0.1]) by localhost.chinamobile.com (Postfix) with ESMTP id DFC32E564; Thu, 12 Jul 2012 09:53:04 +0800 (CST) Received: from mail.chinamobile.com (unknown [10.1.28.22]) by imss.chinamobile.com (Postfix) with ESMTP id C89CCE3CA; Thu, 12 Jul 2012 09:53:04 +0800 (CST) Received: from zyf-PC ([10.2.53.144]) by mail.chinamobile.com (Lotus Domino Release 6.5.6) with ESMTP id 2012071209530277-23539 ; Thu, 12 Jul 2012 09:53:02 +0800 Date: Thu, 12 Jul 2012 09:52:57 +0800 From: zhangyunfei To: ppsp , pzhang.thu X-Priority: 3 (Normal) X-Mailer: Foxmail 7.0.1.85[cn] Mime-Version: 1.0 Message-ID: <2012071209525775716926@chinamobile.com> X-MIMETrack: Itemize by SMTP Server on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2012-07-12 09:53:02, Serialize by Router on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2012-07-12 09:53:04, Serialize complete at 2012-07-12 09:53:04 Content-Type: multipart/alternative; boundary="----=_001_NextPart023273532476_=----" X-TM-AS-Product-Ver: IMSS-7.0.0.8231-6.8.0.1017-19034.003 X-TM-AS-Result: No--33.041-7.0-31-10 X-imss-scan-details: No--33.041-7.0-31-10;No--33.041-7.0-31-10 X-TM-AS-User-Approved-Sender: No;No X-TM-AS-User-Blocked-Sender: No;No Cc: decade , "arno@cs.vu.nl" Subject: [decade] =?gb2312?b?16q3ojogUmU6ICBbcHBzcF0gIE9iamVjdCBuYW1pbmcg?= =?gb2312?b?aW4gLXJlcSBhbmQgLWFyY2g=?= X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: zhangyunfei 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, 12 Jul 2012 01:52:34 -0000 This is a multi-part message in MIME format. ------=_001_NextPart023273532476_=---- Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="gb2312" SGkgUGVuZywNCiAgICBXb3VsZCB5b3UgcGxlYXNlIGFsc28gY2MgdGhlIGRpc2N1c3Npb24gdG8g cHBzcCBmb3Igc3luYywgYXMgUmljaGFyZCBzdWdnZXN0ZWQuIFRob3JvdWdoIERpc2N1c3Npb24g b24gdGhlIG5hbWluZyBvZiBNSFQgaW4gUFBTUCBpcyBhbHNvIG5lZWRlZCwgYXMgaW4gREVDQURF LiBUaGFua3MuDQoNCkJSDQp5dW5mZWkNCg0KDQoNCg0Kemhhbmd5dW5mZWkNCg0Kt6K8/sjLo7og UGVuZyBaaGFuZw0Kt6LLzcqxvOSjuiAyMDEyLTA3LTEyIDA1OjI1DQrK1bz+yMujuiB6aGFuZ3l1 bmZlaQ0Ks63LzaO6IGRlY2FkZTsgYXJubw0K1vfM4qO6IFJlOiBbZGVjYWRlXSBbcHBzcF0gT2Jq ZWN0IG5hbWluZyBpbiAtcmVxIGFuZCAtYXJjaA0KSGkgQXJubywNCg0KDQpUaGFua3MgZm9yIHRo ZSBjbGFyaWZpY2F0aW9uLiBJbiBteSB1bmRlcnN0YW5kaW5nLCBNSFQgb3ZlciBzaW5nbGUgaGFz aCBjYW4gZW5hYmxlIGltbWVkaWF0ZSBpbnRlZ3JpdHkgY2hlY2sgYmVmb3JlIHRoZSB3aG9sZSBt ZWRpYSBmaWxlIGlzIHJlY2VpdmVkLCB3aGljaCBpcyBjcml0aWNhbCBmb3Igc3RyZWFtaW5nIGFw cGxpY2F0aW9ucy4gQnV0IHRoZSBjbGllbnQgY2FuIGFsc28gZG93bmxvYWQgaGFzaGVzIG9mIGV2 ZXJ5IHBpZWNlLCBqdXN0IGxpa2UgaW4gQml0VG9ycmVudC4gRG9lcyBpdCByZWR1Y2UgYSBsb3Qg c3RhcnR1cCBsYXRlbmN5IG9yIHNlcnZlciBsb2FkIGJ5IHVzaW5nIE1IVD8gVGhhbmtzLg0KDQoN CkZvciBERUNBREUsIEl0IHN1cHBvcnRzIGludGVncml0eSBjaGVjayBvbiBwaWVjZS9jaHVuayBs ZXZlbCwgc28gdGhhdCBjbGllbnQgY2FuIHZlcmlmeSB0aGF0IHRoZSByZWNlaXZlZCBwaWVjZSBj b3JyZXNwb25kcyB0byB0aGUgcGllY2UgbmFtZS4gREVDQURFIGlzIHVuYXdhcmUgb2Ygd2hhdCBm aWxlIHRoaXMgcGllY2UgYmVsb25ncyB0bywgYW5kIHRodXMgZG9lcyBub3QgcHJvdmlkZSBlbmQt dG8tZW5kIGludGVncml0eSBjaGVjay4gIEZvciBmaWxlIGxldmVsLCB3ZSBsZWF2ZSB0aGUgaW50 ZWdyaXR5IGNoZWNrIHRvIGFwcGxpY2F0aW9ucy4gVGh1cywgaW1vLCB3ZSBzaG91bGQgbm90IGlu Y2x1ZGUgTUhUIGluIHRoZSBkZXNpZ24gb2YgREVDQURFLiBCdXQgTUhUIGNhbiBiZSBidWlsdCBv biB0b3Agb2YgREVDQURFLCB3aGljaCBtZWFucyBhcHBsaWNhdGlvbnMgY2FuIHN0aWxsIHVzZSBN SFQgdG8gaW1wbGVtZW50IGludGVncml0eSBjaGVjayBmb3IgdGhlbXNlbHZlcy4NCg0KDQoNCg0K QiwNCg0KDQpQZW5nLg0KDQoNCk9uIEp1bCAxMCwgMjAxMiwgYXQgNDoyNiBBTSwgemhhbmd5dW5m ZWkgd3JvdGU6DQoNCg0KQXJubydzIHJlcGx5IG9uIE1IVC4NCg0KQlINCll1bmZlaQ0KDQoNCg0K DQp6aGFuZ3l1bmZlaQ0KDQpGcm9tOiBBcm5vIEJha2tlcg0KRGF0ZTogMjAxMi0wNy0xMCAxNTo0 OQ0KVG86IHBwc3BAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbcHBzcF0gW2RlY2FkZV0gT2JqZWN0 IG5hbWluZyBpbiAtcmVxIGFuZCAtYXJjaA0KSGkgYWxsDQoNCkknbGwgdHJ5IHRvIGNsYXJpZnkg dGhlIHJhdGlvbmFsZSBhbmQgcHJhY3RpY2FsIG92ZXJoZWFkIG9mIHRoZSBNZXJrbGUgDQpIYXNo IFRyZWVzIGluIFBQU1AuIEZvciBzdGF0aWMgY29udGVudCwgTUhUcyBlbmFibGUgY29udGVudCBp bnRlZ3JpdHkgDQpwcm90ZWN0aW9uIHVzaW5nIHNlbGYtY2VydGlmaWVkIG5hbWluZy4gVXNpbmcg YSBoYXNoIHRyZWUgaW5zdGVhZCBvZiBhIA0Kc2luZ2xlIGhhc2ggaXMgdXNlZnVsIGluIGFsbCBz aXR1YXRpb25zIHdoZXJlIHRoZSBjb250ZW50IGlzIGRpc3RyaWJ1dGVkDQppbiBwYXJ0cyAoPWEg c2VxdWVuY2Ugb2Ygb2JqZWN0cyBhcyB5b3UgbWVudGlvbiBpdCkgdGhhdCBhcmUgaW1tZWRpYXRl bHkgDQp1c2VkLiBJbiBwYXJ0aWN1bGFyLCB3aGVuIHRoZSBwYXJ0cyBhcmUgZGVsaXZlcmVkIHRv IGEgaGlnaGVyIGxldmVsIGFwcCANCnVwb24gcmVjZWlwdCB0aGV5IG11c3QgYmUgaW50ZWdyaXR5 IGNoZWNrZWQgYmVmb3JlaGFuZC4gVGhpcyBhcHBsaWVzIHRvIA0Kc3RyZWFtaW5nLCBidXQgcGVy aGFwcyBhbHNvIHRvIG90aGVyIFAyUCBhcHBzIHVzaW5nIERFQ0FERQ0KRXZlbiBpZiBwYXJ0cyBh cmUgbm90IGltbWVkaWF0ZWx5IHVzZWQsIGFuIGludGVncml0eSBjaGVjayBvbiBwYXJ0cyBjYW4g DQpoZWxwIHRvIGltcHJvdmUgZWZmaWNpZW5jeSBpbiBhIFAyUCBjb250ZXh0LiBBbiBlbmQtdG8t ZW5kIGludGVncml0eSANCmNoZWNrIHdoZW4gdGhlIGNvbnRlbnQgaXMgY29tcGxldGVseSBkb3du bG9hZGVkIGlzIHN1ZmZpY2llbnQsIGJ1dCBmb3INCmVmZmljaWVuY3kgaXQgd291bGQgYmUgbmlj ZSB0byBrbm93IGlmIHRoZSBpbmRpdmlkdWFsIHBhcnRzIGFyZSBjb3JyZWN0DQppbnN0ZWFkIG9m IGZpbmRpbmcgb3V0IGF0IHRoZSBlbmQsIGVzcGVjaWFsbHkgZm9yIGxhcmdlIGNvbnRlbnQuDQoN Ck5vdGUgdGhhdCBNZXJrbGUgSGFzaCBUcmVlcyBzdXBwb3J0IGJvdGggcGFydGlhbCBhbmQgZW5k LXRvLWVuZCANCmludGVncml0eSBjaGVja3MuIFdoZW4gYSBwZWVyIGhhcyBhIGNvcHkgb2YgdGhl IGNvbnRlbnQgYW5kIHRoZSBuYW1lIG9mIA0KdGhlIG9iamVjdCAoPWl0cyByb290IGhhc2ggaW4g dGhlIE1IVCkgaGUgY2FuIGNhbGN1bGF0ZSB0aGUgTUhUIGZyb20gdGhlIA0KY29udGVudCBhbmQg Y29tcGFyZSB0aGUgY2FsY3VsYXRlZCByb290IGhhc2ggdG8gdGhlIG5hbWUuIEhlIGRvZXMgbm90 IA0KbmVlZCB0byByZWNlaXZlIGFueSBvZiB0aGUgaW50ZXJtZWRpYXJ5IGhhc2hlcyBmcm9tIG90 aGVycywgaWYgdGhhdCBpcyANCm5vdCByZXF1aXJlZC4NCg0KV2hpY2ggYnJpbmdzIHVzIHRvIHRo ZSB0b3BpYyBvZiBvdmVyaGVhZC4gQXMgZGlzY3Vzc2VkIGluIFNlYy4gNS41IG9mDQpodHRwOi8v d3d3LmlldGYub3JnL2lkL2RyYWZ0LWlldGYtcHBzcC1wZWVyLXByb3RvY29sLTAyLnR4dA0KdGhl IHNpemUgb2YgdGhlIE1IVCBkZXBlbmRzIG9uIHRoZSBudW1iZXIgb2YgY2h1bmtzIChvYmplY3Rz KSBhdCB0aGUgDQpiYXNlIG9mIHRoZSB0cmVlLiBUaGF0IG51bWJlciBkZXBlbmRzIG9uIHRoZSBz aXplIG9mIHRoZSBjaHVua3MgdGhhdCBhcmUgDQpwcm9jZXNzZWQgaW1tZWRpYXRlbHkgaW4gdGhl IFAyUCBhcHBsaWNhdGlvbi4gRm9yIFBQU1Agb3ZlciBVRFAgb3ZlciANCkV0aGVybmV0IHRoZXNl IGNodW5rcyBhcmUgc21hbGwuIEZvciBvdGhlciBQMlAgYXBwcyB0aGUgY2h1bmtzIG1heSBiZSAN CmJpZ2dlci4NCg0KSG93IG11Y2ggb2YgdGhlIE1IVCB0cmVlIGFjdHVhbGx5IG5lZWRzIHRvIGJl IHNlbnQgb3ZlciB0aGUgd2lyZSB0byBhIA0KcmVjZWl2aW5nIHBlZXIgZGVwZW5kcyBvbiB0aGUg ZG93bmxvYWQgcG9saWN5IHVzZWQuIEZvciBhIGxpbmVhciANCmRvd25sb2FkIG9ubHkgcGFydCBv ZiB0aGUgdHJlZSBuZWVkcyB0byBiZSB0cmFuc21pdHRlZCwgYXMgdGhlIG90aGVyIA0KcGFydCBv ZiB0aGUgdHJlZSBpcyBjYWxjdWxhdGVkIGJ5IHRoZSByZWNlaXZpbmcgcGVlciB3aGlsZSBkb3du bG9hZGluZy4NCkluIHRoZSBleGFtcGxlIGluIFNlYy4gNS41LCBvbmx5IDcgb2YgdGhlIDE2IGhh c2hlcyBpbiB0aGUgdHJlZSBhcmUgDQphY3R1YWxseSB0cmFuc21pdHRlZC4NCg0KTm90ZSB0aGF0 IHN3aWZ0LCB0aGUgcHJvdG9jb2wgb24gd2hpY2ggdGhlIFBQU1AgcGVlciBwcm90b2NvbCBpcyBi YXNlZCANCndhcyBhY3R1YWxseSBkZXNpZ25lZCBhcyBhIGdlbmVyaWMgdHJhbnNwb3J0IHByb3Rv Y29sLCB1bmlmeWluZyByZWd1bGFyIA0KZG93bmxvYWRzLCBWT0QgYW5kIGxpdmUgc3RyZWFtaW5n LiBTbyBpdCBzdGlsbCBzdXBwb3J0cyBlZmZpY2llbnQgDQpub24tc3RyZWFtaW5nIGRvd25sb2Fk IHBvbGljaWVzIGxpa2UgQml0VG9ycmVudCdzIHJhcmVzdCBmaXJzdC4gSW4gb3RoZXIgDQp3b3Jk cywgaXRzIG9yaWdpbnMgZml0cyB0aGUgZ2VuZXJhbCBkaXN0cmlidXRpb24gbmF0dXJlIG9mIERF Q0FERS4NCg0KUmVnYXJkcywNCiAgICAgIEFybm8NCg0KDQpPbiAxMC8wNy8yMDEyIDA3OjIzLCBZ LiBSaWNoYXJkIFlhbmcgd3JvdGU6DQo+IEhpIFBlbmcsIERpcmssDQo+DQo+IEkgYW0gY2MnaW5n IHRoZSBwcHNwIGxpc3QgYXMgd2VsbC4gWW91IHJhaXNlZCBhIGdvb2QgcG9pbnQgb24gdGhlDQo+ IGRpc3RpbmN0aW9uIGJldHdlZW4gb25lIG9iamVjdCBhbmQgYSBzZXF1ZW5jZSBvZiBvYmplY3Rz LiBUbyBnZW5lcmFsaXplLA0KPiB3ZSBjYW4gZGlzY3VzcyBldmVuIGEgc2V0IG9mIG9iamVjdHMg KG5vIG9yZGVyaW5nKSwgYW5kIGEgc2V0IG9mDQo+IGVxdWl2YWxlbmNlIG9iamVjdHMgKGR5bmFt aWMgc3RyZWFtaW5nIHRoYXQgaW50ZXJsZWF2ZXMgZGlmZmVyZW50DQo+IHJlc29sdXRpb25zKS4g WW91ciBhcmd1ZW1lbnQgYWdhaW5zdCBNVEggaXMgaGlnaGVyIG92ZXJoZWFkIGluIHRoZQ0KPiBn ZW5lcmFsIGNhc2UgKGVuZCB0byBlbmQgYXJndWVtZW50cykuIEhvdyBtdWNoIGV4YWN0bHkgaXMg dGhlIG92ZXJoZWFkPw0KPiBEZWNhZGUgbWF5IGJlbmVmaXQgZnJvbSB0aGUgYW5hbHlzaXMgZnJv bSBwcHNwLiBTaW5jZSBzdHJlYW1pbmcgaXMNCj4gY29uc2lkZXJlZCBhcyB0aGUgbWFpbiBhcHAs IGhvdyBtdWNoIG92ZXJoZWFkIGlmIGRlY2FkZSBoYXMgdG8gYnVpbGQgb24gdG9wPw0KPg0KPiBU aGFua3MhDQo+DQo+IFJpY2hhcmQNCj4NCj4gT24gVHVlc2RheSwgSnVseSAxMCwgMjAxMiwgUGVu ZyBaaGFuZyB3cm90ZToNCj4NCj4gICAgIEhpIERpcmsgYW5kIGFsbCwNCj4NCj4gICAgIEkgYWdy ZWUgdGhhdCB0aGUgTkkgc3BlY2lmaWNhdGlvbiBtZWV0cyB0aGUgYmFzaWMgcmVxdWlyZW1lbnQg b2YNCj4gICAgIERFQ0FERSAod2l0aG91dCBvcHRpbWl6YXRpb24gb24gImVhcmx5IG5hbWUgZ2Vu ZXJhdGlvbiIpLg0KPg0KPiAgICAgQXMgZm9yIHRoZSBNZXJrbGUgSGFzaCBUcmVlLCBvciBNVEgs IGl0IGlzIGEgaW50ZWdyaXR5LWFzc3VyYW5jZQ0KPiAgICAgbWV0aG9kIGZvciBhIHNlcXVlbmNl IG9mIG9iamVjdHMuIEl0IGlzIGNyaXRpY2FsIHRvIHRoZSBQUFNQDQo+ICAgICBwcm90b2NvbC4g QnV0IGkgd29uZGVyIHdldGhlciB3ZSBzaG91bGQgaW5jb3Jwb3JhdGUgaXQgaW4gb3VyIGRlc2ln bjoNCj4NCj4gICAgIEZpcnN0LCBERUNBREUgaXMgdGFyZ2V0ZWQgYXQgZ2VuZXJhbCBjb250ZW50 IGRpc3RyaWJ1dGlvbg0KPiAgICAgYXBwbGljYXRpb25zLCBhbmQgZm9yIGFwcGxpY2F0aW9ucyBv dGhlciB0aGFuIFAyUCBzdHJlYW1pbmcsIHRoZXJlDQo+ICAgICBpcyBubyBncmVhdCB2YWx1ZSBv ZiB1c2luZyBNZXJrbGUgSGFzaCBUcmVlLiBJdCBtYXkgY2F1c2UgaGlnaA0KPiAgICAgb3Zlcmhl YWQgdG8gdGhlc2UgYXBwbGljYXRpb25zIGR1ZSAibWV0YSBkYXRhIiBpbmNsdWRpbmcgc2lnbmF0 dXJlcw0KPiAgICAgYW5kIGZ1bGwgaGFzaGVzIHNob3VsZCBiZSBleGNoYW5nZWQuDQo+DQo+ICAg ICBTdGlsbCwgd2UgY2FuIGRpc2N1c3MgbW9yZSBvbiBob3cgdG8gYmV0dGVyIGluY29ycG9yYXRl IFBQU1AgYmFzZWQNCj4gICAgIG9uIE5JIHdpdGhvdXQgaHVydGluZyB0aGUgZ2VuZXJhbCBhcHBs aWNhdGlvbiBvZiBERUNBREUuIFRoYW5rcy4NCj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQpwcHNwIG1haWxpbmcgbGlzdA0KcHBzcEBpZXRmLm9yZw0K aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wcHNw ------=_001_NextPart023273532476_=---- Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="gb2312"
Hi Peng,
    Would you please also cc the discussion to ppsp fo= r=20 sync, as Richard suggested. Thorough Discussion on the naming of MHT = in=20 PPSP is also needed, as in DECADE. Thanks.
 
BR
yunfei
 
zhangyunfei
 
=B7=A2=BC=FE=C8=CB=A3=BA Peng Zhang
=B7=A2=CB=CD=CA=B1=BC=E4=A3=BA 2012-07-12 05:25
=CA=D5=BC=FE=C8=CB=A3=BA zhangyunfei
=B3=AD=CB=CD=A3=BA dec= ade; arno
=D6=F7=CC=E2=A3=BA Re: [decade] [ppsp] Object naming in -= req and=20 -arch
Hi Arn= o,

Thanks= for the=20 clarification. In my understanding, MHT over single hash can enable=20 immediate integrity check before the whole media file is received, wh= ich is=20 critical for streaming applications. But the client can also download= =20 hashes of every piece, just like in BitTorrent. Does it reduce a lot start= up=20 latency or server load by using MHT? Thanks.

For DE= CADE, It=20 supports integrity check on piece/chunk level, so that client can verify t= hat=20 the received piece corresponds to the piece name. DECADE is unaware of wha= t file=20 this piece belongs to, and thus does not provide end-to-end integrity chec= k.=20  For file level, we leave the integrity check to applications. Thus, = imo,=20 we should not include MHT in the design of DECADE. But MHT can be built on= top=20 of DECADE, which means applications can still use MHT to implement integri= ty=20 check for themselves.


B,

Peng.

On Jul 10, 2012, at 4:26 AM, zhangyunfei wrote:
Arno's reply on MHT.
 
BR
Yunfei
 
zhangyunfei
 
From: Arno Bakker<= /DIV>
Date: 2012-07-10 15:49
To: ppsp@ietf.org<= /DIV>
Subject: Re: [ppsp] [decade] Object naming in -req and=20 -arch
Hi all
 
I'll try to clarify the rationale and=  practical overhead of the Merkle 
Hash Trees in PPSP. For static conten= t, MHTs enable content integrity 
protection using self-certified naming. Using&n= bsp;a hash tree instead of a 
single hash is useful in all situatio= ns where the content is distributed
in parts (=3Da sequence of objects as=  you mention it) that are immediately <= /DIV>
used. In particular, when the parts a= re delivered to a higher level app 
upon receipt they must be integrity c= hecked beforehand. This applies to 
streaming, but perhaps also to other = P2P apps using DECADE
=
Even if parts are not immediately use= d, an integrity check on parts can 
help to improve efficiency in a P2P&n= bsp;context. An end-to-end integrity 
check when the content is completely = downloaded is sufficient, but for
efficiency it would be nice to know&n= bsp;if the individual parts are correct
instead of finding out at the end,&nb= sp;especially for large content.
 
Note that Merkle Hash Trees support b= oth partial and end-to-end 
integrity checks. When a peer has a&n= bsp;copy of the content and the name of=  
the object (=3Dits root hash in the&n= bsp;MHT) he can calculate the MHT from = the 
content and compare the calculated root&nb= sp;hash to the name. He does not 
need to receive any of the intermedia= ry hashes from others, if that is 
not required.
 
Which brings us to the topic of = overhead. As discussed in Sec. 5.5 of
htt= p://www.ietf.org/id/draft-ietf-ppsp-peer-protocol-02.txt
the size of the MHT depends on t= he number of chunks (objects) at the 
base of the tree. That number depends=  on the size of the chunks that ar= e 
processed immediately in the P2P applicati= on. For PPSP over UDP over 
Ethernet these chunks are small. For = other P2P apps the chunks may be 
bigger.
 
How much of the MHT tree actually&nbs= p;needs to be sent over the wire to&nbs= p;a 
receiving peer depends on the download&nbs= p;policy used. For a linear 
download only part of the tree needs&= nbsp;to be transmitted, as the other 
part of the tree is calculated by&nbs= p;the receiving peer while downloading.
In the example in Sec. 5.5, only = ;7 of the 16 hashes in the tree ar= e 
actually transmitted.
 
Note that swift, the protocol on whic= h the PPSP peer protocol is based 
was actually designed as a generic tr= ansport protocol, unifying regular 
downloads, VOD and live streaming. So = ;it still supports efficient 
non-streaming download policies like BitTorrent= 's rarest first. In other 
words, its origins fits the general d= istribution nature of DECADE.
 
Regards,
      Arno
 
 
On 10/07/2012 07:23, Y. Richard Yang = wrote:
> Hi Peng, Dirk,
>
> I am cc'ing the ppsp list a= s well. You raised a good point on = ;the
> distinction between one object and&nb= sp;a sequence of objects. To generalize,
> we can discuss even a set o= f objects (no ordering), and a set of
> equivalence objects (dynamic streaming&nbs= p;that interleaves different
> resolutions). Your arguement against = MTH is higher overhead in the
> general case (end to end argueme= nts). How much exactly is the overhead?
> Decade may benefit from the anal= ysis from ppsp. Since streaming is
> considered as the main app, how&= nbsp;much overhead if decade has to build&nb= sp;on top?
>
> Thanks!
>
> Richard
>
> On Tuesday, July 10, 2012, Peng&= nbsp;Zhang wrote:
>
>     Hi Dirk and all,
>
>     I agree that the&n= bsp;NI specification meets the basic requirement&= nbsp;of
>     DECADE (without optimiz= ation on "early name generation").
>
>     As for the Merkle&= nbsp;Hash Tree, or MTH, it is a integri= ty-assurance
>     method for a seque= nce of objects. It is critical to the&n= bsp;PPSP
>     protocol. But i wo= nder wether we should incorporate it in = ;our design:
>
>     First, DECADE is t= argeted at general content distribution
>     applications, and for&n= bsp;applications other than P2P streaming, there<= /DIV>
>     is no great value&= nbsp;of using Merkle Hash Tree. It may = cause high
>     overhead to these = applications due "meta data" including signatures=
>     and full hashes sh= ould be exchanged.
>
>     Still, we can disc= uss more on how to better incorporate P= PSP based
>     on NI without hurt= ing the general application of DECADE. Thank= s.
>
_______________________________________________
ppsp mailing list
https://www.ietf.org= /mailman/listinfo/ppsp

=
------=_001_NextPart023273532476_=------ From Akbar.Rahman@InterDigital.com Thu Jul 12 07:17:37 2012 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 3AAB421F87B0 for ; Thu, 12 Jul 2012 07:17:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_63=0.6] 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 WKdubkhRcIao for ; Thu, 12 Jul 2012 07:17:35 -0700 (PDT) Received: from idcout.InterDigital.com (smtp-out1.interdigital.com [64.208.228.135]) by ietfa.amsl.com (Postfix) with ESMTP id DE72C21F8778 for ; Thu, 12 Jul 2012 07:17:34 -0700 (PDT) Received: from SAM.InterDigital.com ([10.30.2.11]) by idcout.InterDigital.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 12 Jul 2012 10:18:07 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD6039.28801944" X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Thu, 12 Jul 2012 10:18:05 -0400 Message-ID: In-Reply-To: <20120706113539320678363@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Re: [decade] Working Group Last Call: draft-ietf-decade-arch-07 Thread-Index: Ac1bjQJ+dFpVWfqGRy2h3nUoid+2DQEqvvPQ References: , <20120705211556235011353@gmail.com>, <4FF6B567.90100@cs.tcd.ie> <20120706113539320678363@gmail.com> From: "Rahman, Akbar" To: "pzhang.thu" , "Stephen Farrell" X-OriginalArrivalTime: 12 Jul 2012 14:18:07.0613 (UTC) FILETIME=[28B782D0:01CD6039] Cc: "DECADE@ietf.org" , Konstantinos Pentikousis Subject: Re: [decade] Working Group Last Call: draft-ietf-decade-arch-07 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, 12 Jul 2012 14:17:37 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD6039.28801944 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 Sorry for my delay in responding. After thinking about it, I agree with all of you that optimizations are not appropriate for a base architecture document. So I propose that we delete the following optimizations from the Arch I-D: - Section 4.4, 2nd to last paragraph (as initially identified by Kostas in his comment (6)) - Section 6.1.2, 2nd to last paragraph (as initially identified by Kostas in his comment (8)) - Section 5.2.3, lasts sentence Does anyone have any objections to this approach? =20 /Akbar From: Zhang Peng [mailto:pzhang.thu@gmail.com]=20 Sent: Friday, July 06, 2012 11:36 AM To: Stephen Farrell Cc: Rahman, Akbar; DECADE@ietf.org; Konstantinos Pentikousis Subject: Re: Re: [decade] Working Group Last Call: draft-ietf-decade-arch-07 =20 Hi Stephen, =20 I agree with you, and suggest that this optimization should not appear in -arch document, since it is too detailed, and may raise more concerns than it solves. Or we can use MAY instead of SHOULD to indicate that this is a optional feature that are preferable, and state clearly the issues that may arise (i.e., how to deal with client abortion). How would others think? Thanks. =20 B, =20 Peng. =20 =20 =20 From: Stephen Farrell =20 Date: 2012-07-06 05:52 To: pzhang.thu =20 CC: Rahman, Akbar ; DECADE@ietf.org; Konstantinos Pentikousis =20 Subject: Re: [decade] Working Group Last Call: draft-ietf-decade-arch-07 =20 I'm not sure if designing optimisations is best done when considering requirements. It sounds like something liable to lead to premature optimisation. =20 On 07/06/2012 02:15 AM, Zhang Peng wrote: > Hi, >=20 > As for the comment (6) regarding optimization about naming, I think we need further discussion. >=20 > The question is that whether the name SHOULD be generated and returned to the client before commitment to the uploading. >=20 > First, we should evaluate the gain by using this what i term as "early name generation". Consider that a client A is uploading a object F to DECADE server D, and another client B needs to download it from D. Below is the stages to be taken without considering authentication, and access control.=20 >=20 > 1. A sends upload request to D, which responses with a permission > 2. A uploads F to D > 3. D returns the object name to A > 4. A advertises the object=20 > 5. B knows the file name and request the object from D > 6. D sends the object to B >=20 > Here 1,3,4,5 may cost constant small amount of time, while 2,6, depend on the size of object and tend to cost more time. The benefit of putting 3 before 2 is that 4 and 5 can be carried out in parallel with 2. Thus it seems that we can just save the time of 4 and 5 in this process. But considering that B is in different locations, and using another DECADE sever E, then we can also save the time for E request the object from D. In addition, It may also take more time if we consider the case that A should advertise to a lot of interested receivers, which may consume more time. Without this non-quantitative analysis, it seems that it can benefits the live applications to reduce the latency. But the benefits are not so clear, and may depend on applications.=20 =20 Putting "3 before 2" wouldn't be the only option though. For example, A could upload Hash(F) which might be used in generating the object name at step 1. There are many ways to do things, setting up requirements that things be done in one way seems like a bad plan to me. =20 S. =20 > If we would include this in -arch as a design requirements, we need to handle some erroneous situations, just as mentioned by Kostas. When the client advertises a object, but does not upload or finish the uploading, the DECADE server, however, may have already grant the object or send the part of the object to some receiver. Then the server should just sends a error signal to the granted receivers, or let the receivers timeout themselves, and delete the object. Retransmission may or may not happen, depending on the application implementation. =20 >=20 > I am still not quite sure whether the potential benefits of this optimization worth the complication it brings. More discussion may be needed. Thanks. >=20 > B, >=20 > Peng. >=20 >=20 > From: Rahman, Akbar > Date: 2012-07-05 01:21 > To: decade@ietf.org > CC: Konstantinos Pentikousis > Subject: Re: [decade] Working Group Last Call: draft-ietf-decade-arch-07 > Hi, >=20 >=20 > The DECADE Architecture authors were contacted off list by Kostas who > provided the following relevant and useful comments on the > draft-ietf-decade-arch-07. We intend to address these comments in the > next revision of the architecture I-D after the WGLC ends. =20 >=20 > 1) Figure 1:=20 > This figure and the accompanying text (as-is right now) leaves quite > some room for interpretation. For example, two distinct > "DECADE-compatible" systems deployed by two different operators may have > DRP1 vs. DPR2, in addition to having multiple SDTxyz's. Is this what you > have in mind? >=20 >=20 > 2) Section 4.2, Referring to the word "multipath": =20 > I think you mean multi-source here? Multipath is mostly related with two > (multihomed) end nodes and routing in the network rather than one node > getting bits and pieces of a data object from different sources (as in > P2P). You can still have multipath and single-source. >=20 >=20 > 3) Section 4.2, third paragraph, first sentence: > As per the sec. 2.8, a "data object is a string of raw bytes". > Therefore, in this sentence we need s/SHOULD/MUST. >=20 >=20 > 4) Section 4.2, third paragraph, second sentence: > This may introduce the issue of MDO discovery (max data object), when > one connects to different DECADE Servers, perhaps along the lines of MTU > discovery. Content resegmentation is not covered in this section, esp. > since a DECADE server may store/maintain DOs from completely different > apps. >=20 >=20 > 5) Section 4.2, last paragraph: > The introduction of the "block" may be redundant here. A block is, > similarly to a DO, "a string of raw bytes", isn't it? If not, we need a > formal definition for it. Of course, the key aspect here is what can you > name and locate in a DECADE Server, and my reading of the ID so far is > that you have settled on the use of the DO, irrespective of the > application semantics. The repeated use of "block" here and there simply > confuses the uninitiated reader. >=20 >=20 > 6) Section 4.4, 2nd to last paragraph: > I think the optimization described in this paragraph is not particularly > suited for the Architecture document. And it opens up all kinds of > questions. E.G. what if the host advertizing an object crashes before > it uploads the object? What if the host changes its mind during the > upload? Since we're talking about immutable objects, shouldn't we wait > until an object is "committed". In the end, this optimization could be > counter-productive in these cases. Let alone the fact that the scenarios > for which DECADE is envisaged (and motivated from I would add) tend to > have asymmetric capacities in down/uplink, perhaps of a ratio of 10:1. > Thus, downloading is not typically the performance bottleneck. Perhaps I > am wrong in thinking of this as a premature optimization though. Can you > provide examples from exisiting apps that follow this proposal (and how > do they handle error cases)?=20 >=20 > Moreover, using SHOULD for such a optimization may not be a good idea in > the general case. >=20 >=20 > 7) Figure 3: > This figure implies that multiple applications will need to implement > their own DECADE client, which cannot be shared at run time with other > apps. Of course one could see this as including/linking to a library, > but perhaps a more flexible implementation could also be thought of, > based, for example, on a DECADE "platform", shared by many apps at run > time. >=20 >=20 > 8) Section 6.1.2, second to last paragraph: > This proposed optimization need not be part of the "architecture" >=20 >=20 > 9) Section 6.1.3: > Wouldn't it be better to skip this section altogether and consider an ID > on management aspects instead? For example, why not simply define an MIB > for DECADE and use existing methods to obtain this status info? Why add > more complexity in DRP implementations? >=20 >=20 > 10) Section 10.2: > http://dx.doi.org/10.1145/1544012.1544078 should also be added here, as > it motivates well the domain considered in this architecture, including > the DO. >=20 >=20 > 11) Various editorial and grammatical fixes (which were provided to the > authors off line). >=20 >=20 > Many thanks to Kostas for providing these excellent comments. >=20 >=20 > Akbar >=20 >=20 > -----Original Message----- > From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.org] On Behalf > Of Songhaibin > Sent: Wednesday, June 20, 2012 10:06 PM > To: decade@ietf.org > Subject: [decade] Working Group Last Call: draft-ietf-decade-arch-07 >=20 > Dear folks, >=20 > After the first round of the last call, the architecture document has > many changes to resolve comments from reviewers as well as area director > and experts from other areas. Thanks to the reviewers and the authors. >=20 > So Rich and I now start another round of WGLC on > draft-ietf-decade-arch-07, ending Friday, July 6th. Please review the > document and reply with your comments. >=20 > Thanks, >=20 > -Haibin and Rich (co-chairs) >=20 =20 ------_=_NextPart_001_01CD6039.28801944 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

Sorry for my delay in responding.  After thinking about it, I = agree with all of you that optimizations are not appropriate for a base = architecture document.  So I propose that we delete the following = optimizations from the Arch I-D:

-          = Section 4.4, 2nd to last=  paragraph (as initially identified by Kostas in his comment = (6))

= -          = Section 6.1.2, 2nd to la= st paragraph (as initially identified by Kostas in his comment = (8))

-          = Section 5.2.3, lasts sentence

Does anyone have any objections to this = approach?

 

/Akbar

From:= = Zhang Peng [mailto:pzhang.thu@gmail.com]
Sent: Friday, July = 06, 2012 11:36 AM
To: Stephen Farrell
Cc: Rahman, = Akbar; DECADE@ietf.org; Konstantinos Pentikousis
Subject: Re: = Re: [decade] Working Group Last Call: = draft-ietf-decade-arch-07

 

Hi = Stephen,

 

I agree with you, and suggest that this = optimization should not appear in -arch document, since it is too = detailed, and may raise more concerns than it solves. Or we can use MAY = instead of SHOULD to indicate that this is a optional feature that are = preferable, and state clearly the issues that may arise (i.e., how to = deal with client abortion). How would others think? = Thanks.

 

B,

 

Peng.

 

 

 

Date: 2012-07-06 05:52

To: pzhang.thu

=

Subject: Re: [decade] Working Group Last = Call: = draft-ietf-decade-arch-07

 

I'm not sure if designin= g optimisations is best done

when considering requirements.&nbs= p;It sounds like something

liable to lead to premat= ure optimisation.

 

On 07/06/2012 02:15 AM, = Zhang Peng wrote:

> Hi,

> 

<= p class=3DMsoNormal style=3D'margin:0in;margin-bottom:.0001pt'>> As for the comment&= nbsp;(6) regarding optimization about naming, I&= nbsp;think we need further discussion.

> 

<= p class=3DMsoNormal style=3D'margin:0in;margin-bottom:.0001pt'>> The question is tha= t whether the name SHOULD be generated = ;and returned to the client before commitme= nt to the uploading.

> 

<= p class=3DMsoNormal style=3D'margin:0in;margin-bottom:.0001pt'>> First, we should ev= aluate the gain by using this what i&n= bsp;term as "early name generation". C= onsider that a client A is uploading a=  object F to DECADE server D, and = ;another client B needs to download it = ;from D. Below is the stages to be&nbs= p;taken without considering authentication, and = access control. 

> 

<= p class=3DMsoNormal style=3D'margin:0in;margin-bottom:.0001pt'>> 1. A sends upload&n= bsp;request to D, which responses with a&nb= sp;permission

> 2. A uploads F = ;to D

> 3. D returns the&nb= sp;object name to A

> 4. A advertises the=  object 

> 5. B knows the = ;file name and request the object from = ;D

> 6. D sends the = ;object to B

> 

<= p class=3DMsoNormal style=3D'margin:0in;margin-bottom:.0001pt'>> Here 1,3,4,5 may co= st constant small amount of time, while&nbs= p;2,6, depend on the size of object an= d tend to cost more time. The benefit&= nbsp;of putting 3 before 2 is that 4&n= bsp;and 5 can be carried out in parall= el with 2. Thus it seems that we = can just save the time of 4 and 5=  in this process. But considering that = ;B is in different locations, and using&nbs= p;another DECADE sever E, then we can = also save the time for E request the&n= bsp;object from D. In addition, It may = ;also take more time if we consider th= e case that A should advertise to a&nb= sp;lot of interested receivers, which may c= onsume more time. Without this non-quantitative&= nbsp;analysis, it seems that it can benefit= s the live applications to reduce the = latency. But the benefits are not so c= lear, and may depend on applications. =

 

Putting "3 before 2"= ; wouldn't be the only option though.<= /o:p>

For example, A could upl= oad Hash(F) which might be used in

generating the object name&nb= sp;at step 1. There are many ways

to do things, setting up=  requirements that things be done

in one way seems like&nb= sp;a bad plan to me.

=

 

S.

 

> If we would include=  this in -arch as a design requirement= s, we need to handle some erroneous si= tuations, just as mentioned by Kostas. When=  the client advertises a object, but d= oes not upload or finish the uploading,&nbs= p;the DECADE server, however, may have alre= ady grant the object or send the part&= nbsp;of the object to some receiver. Then&n= bsp;the server should just sends a error&nb= sp;signal to the granted receivers, or let&= nbsp;the receivers timeout themselves, and delet= e the object. Retransmission may or may&nbs= p;not happen, depending on the application = implementation.  

> 

<= p class=3DMsoNormal style=3D'margin:0in;margin-bottom:.0001pt'>> I am still not = ;quite sure whether the potential benefits = of this optimization worth the complication = ;it brings. More discussion may be needed.&= nbsp;Thanks.

> 

<= p class=3DMsoNormal style=3D'margin:0in;margin-bottom:.0001pt'>> B,

> 

<= p class=3DMsoNormal style=3D'margin:0in;margin-bottom:.0001pt'>> Peng.

<= div>

> 

<= p class=3DMsoNormal style=3D'margin:0in;margin-bottom:.0001pt'>> 

<= p class=3DMsoNormal style=3D'margin:0in;margin-bottom:.0001pt'>> From: Rahman, Akbar=

> Date: 2012-07-05 01:21

> To: decade@ietf.org

> CC: Konstantinos Pentiko= usis

> Subject: Re: [decade]&nb= sp;Working Group Last Call: draft-ietf-decade-arch-07=

> Hi,

> 

<= p class=3DMsoNormal style=3D'margin:0in;margin-bottom:.0001pt'>> 

<= p class=3DMsoNormal style=3D'margin:0in;margin-bottom:.0001pt'>> The DECADE Architecture&= nbsp;authors were contacted off list by Kos= tas who

> provided the following&n= bsp;relevant and useful comments on the

> draft-ietf-decade-arch-07. &n= bsp;We intend to address these comments in&= nbsp;the

> next revision of th= e architecture I-D after the WGLC ends.&nbs= p; 

> 

<= p class=3DMsoNormal style=3D'margin:0in;margin-bottom:.0001pt'>> 1) Figure 1: <= /o:p>

> This figure and the=  accompanying text (as-is right now) leaves=  quite

> some room for inter= pretation. For example,  two distinct=

> "DECADE-compatible" = ;systems deployed by two different operators&nbs= p;may have

> DRP1 vs. DPR2, in&n= bsp;addition to having multiple SDTxyz's. Is&nbs= p;this what you

> have in mind?=

> 

<= p class=3DMsoNormal style=3D'margin:0in;margin-bottom:.0001pt'>> 

<= p class=3DMsoNormal style=3D'margin:0in;margin-bottom:.0001pt'>> 2) Section 4.2, Ref= erring to the word "multipath":  =

> I think you mean&nb= sp;multi-source here? Multipath is mostly relate= d with two

> (multihomed) end nodes&n= bsp;and routing in the network rather than&= nbsp;one node

> getting bits and pi= eces of a data object from different s= ources (as in

> P2P). You can still=  have multipath and single-source.<= /p>

> 

<= p class=3DMsoNormal style=3D'margin:0in;margin-bottom:.0001pt'>> 

<= p class=3DMsoNormal style=3D'margin:0in;margin-bottom:.0001pt'>> 3) Section 4.2, thi= rd paragraph, first sentence:

<= div>

> As per the sec.&nbs= p;2.8, a "data object is a string = ;of raw bytes".

> Therefore, in this = sentence we need s/SHOULD/MUST.

> 

<= p class=3DMsoNormal style=3D'margin:0in;margin-bottom:.0001pt'>> 

<= p class=3DMsoNormal style=3D'margin:0in;margin-bottom:.0001pt'>> 4) Section 4.2, thi= rd paragraph, second sentence:

=

> This may introduce = the issue of MDO discovery (max data o= bject), when

> one connects to dif= ferent DECADE Servers, perhaps along the li= nes of MTU

> discovery. Content reseg= mentation is not covered in this section,&n= bsp;esp.

> since a DECADE serv= er may store/maintain DOs from completely d= ifferent

> apps.

<= div>

> 

<= p class=3DMsoNormal style=3D'margin:0in;margin-bottom:.0001pt'>> 

<= p class=3DMsoNormal style=3D'margin:0in;margin-bottom:.0001pt'>> 5) Section 4.2, las= t paragraph:

> The introduction of = ;the "block" may be redundant here.&nb= sp;A block is,

> similarly to a DO,&= nbsp;"a string of raw bytes", isn't&nb= sp;it? If not, we need a

> formal definition for&nb= sp;it. Of course, the key aspect here = is what can you

> name and locate in&= nbsp;a DECADE Server, and my reading of&nbs= p;the ID so far is

> that you have settl= ed on the use of the DO, irrespective&= nbsp;of the

> application semantics. T= he repeated use of "block" here a= nd there simply

> confuses the uninitiated=  reader.

> 

<= p class=3DMsoNormal style=3D'margin:0in;margin-bottom:.0001pt'>> 

<= p class=3DMsoNormal style=3D'margin:0in;margin-bottom:.0001pt'>> 6) Section 4.4, 2nd=  to last paragraph:

> I think the optimiz= ation described in this paragraph is not&nb= sp;particularly

> suited for the Arch= itecture document. And it opens up all = ;kinds of

> questions.  E.G. wh= at if the host advertizing an object c= rashes before

> it uploads the obje= ct? What if the host changes its mind&= nbsp;during the

> upload? Since we're = ;talking about immutable objects, shouldn't we&n= bsp;wait

> until an object is&= nbsp;"committed". In the end, this opt= imization could be

> counter-productive in th= ese cases. Let alone the fact that the=  scenarios

> for which DECADE is=  envisaged (and motivated from I would = ;add) tend to

> have asymmetric capaciti= es in down/uplink, perhaps of a ratio = of 10:1.

> Thus, downloading is&nbs= p;not typically the performance bottleneck. Perh= aps I

> am wrong in thinkin= g of this as a premature optimization = though. Can you

> provide examples from&nb= sp;exisiting apps that follow this proposal = ;(and how

> do they handle erro= r cases)? 

> 

<= p class=3DMsoNormal style=3D'margin:0in;margin-bottom:.0001pt'>> Moreover, using SHOULD&n= bsp;for such a optimization may not be = ;a good idea in

> the general case.

> 

<= p class=3DMsoNormal style=3D'margin:0in;margin-bottom:.0001pt'>> 

<= p class=3DMsoNormal style=3D'margin:0in;margin-bottom:.0001pt'>> 7) Figure 3:<= /span>

> This figure implies = ;that multiple applications will need to im= plement

> their own DECADE cl= ient, which cannot be shared at run ti= me with other

> apps. Of course one=  could see this as including/linking to&nbs= p;a library,

> but perhaps a more&= nbsp;flexible implementation could also be thoug= ht of,

> based, for example, = ;on a DECADE "platform", shared by&nbs= p;many apps at run

> time.

<= div>

> 

<= p class=3DMsoNormal style=3D'margin:0in;margin-bottom:.0001pt'>> 

<= p class=3DMsoNormal style=3D'margin:0in;margin-bottom:.0001pt'>> 8) Section 6.1.2, s= econd to last paragraph:

<= p class=3DMsoNormal style=3D'margin:0in;margin-bottom:.0001pt'>> This proposed optimizati= on need not be part of the "archi= tecture"

> 

<= p class=3DMsoNormal style=3D'margin:0in;margin-bottom:.0001pt'>> 

<= p class=3DMsoNormal style=3D'margin:0in;margin-bottom:.0001pt'>> 9) Section 6.1.3:

> Wouldn't it be bett= er to skip this section altogether and = ;consider an ID

> on management aspects&nb= sp;instead? For example, why not simply def= ine an MIB

> for DECADE and use&= nbsp;existing methods to obtain this status = ;info? Why add

> more complexity in = DRP implementations?

> 

<= p class=3DMsoNormal style=3D'margin:0in;margin-bottom:.0001pt'>> 

<= p class=3DMsoNormal style=3D'margin:0in;margin-bottom:.0001pt'>> 10) Section 10.2:

> http://dx.doi.org/10.1145/1544012.= 1544078 should also be added here, as<= /o:p>

> it motivates well t= he domain considered in this architecture, = including

> the DO.

=

> 

<= p class=3DMsoNormal style=3D'margin:0in;margin-bottom:.0001pt'>> 

<= p class=3DMsoNormal style=3D'margin:0in;margin-bottom:.0001pt'>> 11) Various editorial&nb= sp;and grammatical fixes (which were provided&nb= sp;to the

> authors off line).<= /o:p>

> 

<= p class=3DMsoNormal style=3D'margin:0in;margin-bottom:.0001pt'>> 

<= p class=3DMsoNormal style=3D'margin:0in;margin-bottom:.0001pt'>> Many thanks to Kost= as for providing these excellent comments.<= /o:p>

> 

<= p class=3DMsoNormal style=3D'margin:0in;margin-bottom:.0001pt'>> 

<= p class=3DMsoNormal style=3D'margin:0in;margin-bottom:.0001pt'>> Akbar

<= div>

> 

<= p class=3DMsoNormal style=3D'margin:0in;margin-bottom:.0001pt'>> 

<= p class=3DMsoNormal style=3D'margin:0in;margin-bottom:.0001pt'>> -----Original Message-----

> From: decade-bounces@ietf.org=  [mailto:decade-bounces@ietf.org] On Behalf

> Of Songhaibin

> Sent: Wednesday, June&nb= sp;20, 2012 10:06 PM

> To: decade@ietf.org

> Subject: [decade] Workin= g Group Last Call: draft-ietf-decade-arch-07

> 

<= p class=3DMsoNormal style=3D'margin:0in;margin-bottom:.0001pt'>> Dear folks,=

> 

<= p class=3DMsoNormal style=3D'margin:0in;margin-bottom:.0001pt'>> After the first rou= nd of the last call, the architecture = document has

> many changes to res= olve comments from reviewers as well as&nbs= p;area director

> and experts from ot= her areas. Thanks to the reviewers and = ;the authors.

> 

<= p class=3DMsoNormal style=3D'margin:0in;margin-bottom:.0001pt'>> So Rich and I = now start another round of WGLC on

> draft-ietf-decade-arch-07, en= ding Friday, July 6th. Please review the

> document and reply = with your comments.

> 

<= p class=3DMsoNormal style=3D'margin:0in;margin-bottom:.0001pt'>> Thanks,

> 

<= p class=3DMsoNormal style=3D'margin:0in;margin-bottom:.0001pt'>> -Haibin and Rich (c= o-chairs)

> 

<= p class=3DMsoNormal style=3D'margin:0in;margin-bottom:.0001pt'> 

------_=_NextPart_001_01CD6039.28801944-- From a.bakker@vu.nl Wed Jul 11 23:23:09 2012 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 3968321F854E; Wed, 11 Jul 2012 23:23:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.543 X-Spam-Level: X-Spam-Status: No, score=-1.543 tagged_above=-999 required=5 tests=[AWL=-0.039, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, 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 IcVisQMk2yKO; Wed, 11 Jul 2012 23:23:08 -0700 (PDT) Received: from mailin.vu.nl (mailin.vu.nl [130.37.164.18]) by ietfa.amsl.com (Postfix) with ESMTP id 70CEC21F8522; Wed, 11 Jul 2012 23:23:08 -0700 (PDT) Received: from PEXHB012B.vu.local (130.37.236.67) by mailin.vu.nl (130.37.164.18) with Microsoft SMTP Server (TLS) id 14.2.298.4; Thu, 12 Jul 2012 08:23:38 +0200 Received: from [109.37.58.145] (130.37.238.20) by mails.vu.nl (130.37.236.67) with Microsoft SMTP Server (TLS) id 14.2.298.4; Thu, 12 Jul 2012 08:23:37 +0200 Message-ID: <4FFE6D67.80705@cs.vu.nl> Date: Thu, 12 Jul 2012 08:23:35 +0200 From: Arno Bakker User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: Peng Zhang References: <20120710162606039401143@chinamobile.com> <2039343B-5F6B-4777-864E-B4F00B5A258E@gmail.com> In-Reply-To: <2039343B-5F6B-4777-864E-B4F00B5A258E@gmail.com> Content-Type: text/plain; charset="ISO-8859-15"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [130.37.238.20] X-Mailman-Approved-At: Thu, 12 Jul 2012 07:57:33 -0700 Cc: ppsp , decade Subject: Re: [decade] [ppsp] Object naming in -req and -arch X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: arno@cs.vu.nl 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, 12 Jul 2012 06:23:09 -0000 Hi Peng On 11/07/2012 23:25, Peng Zhang wrote: > Hi Arno, > > Thanks for the clarification. In my understanding, MHT over single hash > can enable immediate integrity check before the whole media file is > received, which is critical for streaming applications. But the client > can also download hashes of every piece, just like in BitTorrent. Does > it reduce a lot startup latency or server load by using MHT? Thanks. > The gains of using MHT depend on the chunk size. For PPSP we prefer chunks of 1K that fit in an UDP packet carried over Ethernet. In that case, for a 4 GB file, there are 4 M chunks, resulting in 80 MB of leaf hashes when SHA1 is used. Transferring that beforehand as in BitTorrent definitely increases latency ;o) > For DECADE, It supports integrity check on piece/chunk level, so that > client can verify that the received piece corresponds to the piece name. > DECADE is unaware of what file this piece belongs to, and thus does not > provide end-to-end integrity check. For file level, we leave the > integrity check to applications. Thus, imo, we should not include MHT in > the design of DECADE. But MHT can be built on top of DECADE, which means > applications can still use MHT to implement integrity check for themselves. > You are right, if DECADE doesn't provide "links" between chunks, MHTs at the DECADE level make no sense. Using MHTs at the app level instead as you say does make sense and is easy, just build all the piece names/piece hashes into a tree. Regards, Arno From yry@cs.yale.edu Thu Jul 12 08:26:01 2012 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 7D7DE21F876F for ; Thu, 12 Jul 2012 08:26:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.493 X-Spam-Level: X-Spam-Status: No, score=-0.493 tagged_above=-999 required=5 tests=[AWL=-0.895, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, J_CHICKENPOX_16=0.6, J_CHICKENPOX_33=0.6, J_CHICKENPOX_43=0.6, J_CHICKENPOX_63=0.6] 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 auGctVJLo0ce for ; Thu, 12 Jul 2012 08:25:59 -0700 (PDT) Received: from vm-emlprdomr-03.its.yale.edu (vm-emlprdomr-03.its.yale.edu [130.132.50.144]) by ietfa.amsl.com (Postfix) with ESMTP id B1CC421F8723 for ; Thu, 12 Jul 2012 08:25:58 -0700 (PDT) Received: from [192.168.1.108] ([221.221.18.192]) (authenticated bits=0) by vm-emlprdomr-03.its.yale.edu (8.14.4/8.14.4) with ESMTP id q6CFPQX2011443 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 12 Jul 2012 11:25:35 -0400 Message-ID: <4FFEEC61.1020901@cs.yale.edu> Date: Thu, 12 Jul 2012 23:25:21 +0800 From: "Y. Richard Yang" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: "Rahman, Akbar" References: , <20120705211556235011353@gmail.com>, <4FF6B567.90100@cs.tcd.ie> <20120706113539320678363@gmail.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------020603090002020607070101" X-Scanned-By: MIMEDefang 2.71 on 130.132.50.144 Cc: Konstantinos Pentikousis , "DECADE@ietf.org" Subject: Re: [decade] Working Group Last Call: draft-ietf-decade-arch-07 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, 12 Jul 2012 15:26:02 -0000 This is a multi-part message in MIME format. --------------020603090002020607070101 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 7/12/12 10:18 PM, Rahman, Akbar wrote: > > Hi, > > Sorry for my delay in responding. After thinking about it, I agree > with all of you that optimizations are not appropriate for a base > architecture document. So I propose that we delete the following > optimizations from the Arch I-D: > > -Section 4.4, 2nd to last paragraph (as initially identified by Kostas > in his comment (6)) > I am fine with removing this "optimization". The effect of the proposed feature is to remove the "store-and-forward" delay. The word of "SHOULD" is a bit strong. But we may need to keep in mind that it can be an important feature. Such opportunistic Write/Read may not be too difficult to handle failures, as Kostas pointed out, if there is a name-data binding to validate. > -Section 6.1.2, 2nd to last paragraph (as initially identified by > Kostas in his comment (8)) > Agreed. Batch may not be necessary as in an arch doc. > -Section 5.2.3, lasts sentence > Agree. One can think of multiple ways to optimize, and may not be limited to temporary data (e.g., write log). Richard > Does anyone have any objections to this approach? > > /Akbar > > *From:*Zhang Peng [mailto:pzhang.thu@gmail.com] > *Sent:* Friday, July 06, 2012 11:36 AM > *To:* Stephen Farrell > *Cc:* Rahman, Akbar; DECADE@ietf.org; Konstantinos Pentikousis > *Subject:* Re: Re: [decade] Working Group Last Call: > draft-ietf-decade-arch-07 > > Hi Stephen, > > I agree with you, and suggest that this optimization should not appear > in -arch document, since it is too detailed, and may raise more > concerns than it solves. Or we can use MAY instead of SHOULD to > indicate that this is a optional feature that are preferable, and > state clearly the issues that may arise (i.e., how to deal with client > abortion). How would others think? Thanks. > > B, > > Peng. > > *From:*Stephen Farrell > > *Date:* 2012-07-06 05:52 > > *To:*pzhang.thu > > *CC:*Rahman, Akbar ; > DECADE@ietf.org ; Konstantinos Pentikousis > > > *Subject:* Re: [decade] Working Group Last Call: draft-ietf-decade-arch-07 > > I'm not sure if designing optimisations is best done > > when considering requirements. It sounds like something > > liable to lead to premature optimisation. > > On 07/06/2012 02:15 AM, Zhang Peng wrote: > > > Hi, > > > > > > As for the comment (6) regarding optimization about naming, I think we need further discussion. > > > > > > The question is that whether the name SHOULD be generated and returned to the client before commitment to the uploading. > > > > > > First, we should evaluate the gain by using this what i term as "early name generation". Consider that a client A is uploading a object F to DECADE server D, and another client B needs to download it from D. Below is the stages to be taken without considering authentication, and access control. > > > > > > 1. A sends upload request to D, which responses with a permission > > > 2. A uploads F to D > > > 3. D returns the object name to A > > > 4. A advertises the object > > > 5. B knows the file name and request the object from D > > > 6. D sends the object to B > > > > > > Here 1,3,4,5 may cost constant small amount of time, while 2,6, depend on the size of object and tend to cost more time. The benefit of putting 3 before 2 is that 4 and 5 can be carried out in parallel with 2. Thus it seems that we can just save the time of 4 and 5 in this process. But considering that B is in different locations, and using another DECADE sever E, then we can also save the time for E request the object from D. In addition, It may also take more time if we consider the case that A should advertise to a lot of interested receivers, which may consume more time. Without this non-quantitative analysis, it seems that it can benefits the live applications to reduce the latency. But the benefits are not so clear, and may depend on applications. > > Putting "3 before 2" wouldn't be the only option though. > > For example, A could upload Hash(F) which might be used in > > generating the object name at step 1. There are many ways > > to do things, setting up requirements that things be done > > in one way seems like a bad plan to me. > > S. > > > If we would include this in -arch as a design requirements, we need to handle some erroneous situations, just as mentioned by Kostas. When the client advertises a object, but does not upload or finish the uploading, the DECADE server, however, may have already grant the object or send the part of the object to some receiver. Then the server should just sends a error signal to the granted receivers, or let the receivers timeout themselves, and delete the object. Retransmission may or may not happen, depending on the application implementation. > > > > > > I am still not quite sure whether the potential benefits of this optimization worth the complication it brings. More discussion may be needed. Thanks. > > > > > > B, > > > > > > Peng. > > > > > > > > > From: Rahman, Akbar > > > Date: 2012-07-05 01:21 > > > To: decade@ietf.org > > > CC: Konstantinos Pentikousis > > > Subject: Re: [decade] Working Group Last Call: draft-ietf-decade-arch-07 > > > Hi, > > > > > > > > > The DECADE Architecture authors were contacted off list by Kostas who > > > provided the following relevant and useful comments on the > > > draft-ietf-decade-arch-07. We intend to address these comments in the > > > next revision of the architecture I-D after the WGLC ends. > > > > > > 1) Figure 1: > > > This figure and the accompanying text (as-is right now) leaves quite > > > some room for interpretation. For example, two distinct > > > "DECADE-compatible" systems deployed by two different operators may have > > > DRP1 vs. DPR2, in addition to having multiple SDTxyz's. Is this what you > > > have in mind? > > > > > > > > > 2) Section 4.2, Referring to the word "multipath": > > > I think you mean multi-source here? Multipath is mostly related with two > > > (multihomed) end nodes and routing in the network rather than one node > > > getting bits and pieces of a data object from different sources (as in > > > P2P). You can still have multipath and single-source. > > > > > > > > > 3) Section 4.2, third paragraph, first sentence: > > > As per the sec. 2.8, a "data object is a string of raw bytes". > > > Therefore, in this sentence we need s/SHOULD/MUST. > > > > > > > > > 4) Section 4.2, third paragraph, second sentence: > > > This may introduce the issue of MDO discovery (max data object), when > > > one connects to different DECADE Servers, perhaps along the lines of MTU > > > discovery. Content resegmentation is not covered in this section, esp. > > > since a DECADE server may store/maintain DOs from completely different > > > apps. > > > > > > > > > 5) Section 4.2, last paragraph: > > > The introduction of the "block" may be redundant here. A block is, > > > similarly to a DO, "a string of raw bytes", isn't it? If not, we need a > > > formal definition for it. Of course, the key aspect here is what can you > > > name and locate in a DECADE Server, and my reading of the ID so far is > > > that you have settled on the use of the DO, irrespective of the > > > application semantics. The repeated use of "block" here and there simply > > > confuses the uninitiated reader. > > > > > > > > > 6) Section 4.4, 2nd to last paragraph: > > > I think the optimization described in this paragraph is not particularly > > > suited for the Architecture document. And it opens up all kinds of > > > questions. E.G. what if the host advertizing an object crashes before > > > it uploads the object? What if the host changes its mind during the > > > upload? Since we're talking about immutable objects, shouldn't we wait > > > until an object is "committed". In the end, this optimization could be > > > counter-productive in these cases. Let alone the fact that the scenarios > > > for which DECADE is envisaged (and motivated from I would add) tend to > > > have asymmetric capacities in down/uplink, perhaps of a ratio of 10:1. > > > Thus, downloading is not typically the performance bottleneck. Perhaps I > > > am wrong in thinking of this as a premature optimization though. Can you > > > provide examples from exisiting apps that follow this proposal (and how > > > do they handle error cases)? > > > > > > Moreover, using SHOULD for such a optimization may not be a good idea in > > > the general case. > > > > > > > > > 7) Figure 3: > > > This figure implies that multiple applications will need to implement > > > their own DECADE client, which cannot be shared at run time with other > > > apps. Of course one could see this as including/linking to a library, > > > but perhaps a more flexible implementation could also be thought of, > > > based, for example, on a DECADE "platform", shared by many apps at run > > > time. > > > > > > > > > 8) Section 6.1.2, second to last paragraph: > > > This proposed optimization need not be part of the "architecture" > > > > > > > > > 9) Section 6.1.3: > > > Wouldn't it be better to skip this section altogether and consider an ID > > > on management aspects instead? For example, why not simply define an MIB > > > for DECADE and use existing methods to obtain this status info? Why add > > > more complexity in DRP implementations? > > > > > > > > > 10) Section 10.2: > > > http://dx.doi.org/10.1145/1544012.1544078 should also be added here, as > > > it motivates well the domain considered in this architecture, including > > > the DO. > > > > > > > > > 11) Various editorial and grammatical fixes (which were provided to the > > > authors off line). > > > > > > > > > Many thanks to Kostas for providing these excellent comments. > > > > > > > > > Akbar > > > > > > > > > -----Original Message----- > > > From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.org] On Behalf > > > Of Songhaibin > > > Sent: Wednesday, June 20, 2012 10:06 PM > > > To: decade@ietf.org > > > Subject: [decade] Working Group Last Call: draft-ietf-decade-arch-07 > > > > > > Dear folks, > > > > > > After the first round of the last call, the architecture document has > > > many changes to resolve comments from reviewers as well as area director > > > and experts from other areas. Thanks to the reviewers and the authors. > > > > > > So Rich and I now start another round of WGLC on > > > draft-ietf-decade-arch-07, ending Friday, July 6th. Please review the > > > document and reply with your comments. > > > > > > Thanks, > > > > > > -Haibin and Rich (co-chairs) > > > > --------------020603090002020607070101 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 7/12/12 10:18 PM, Rahman, Akbar wrote:

Hi,

 

Sorry for my delay in responding.  After thinking about it, I agree with all of you that optimizations are not appropriate for a base architecture document.  So I propose that we delete the following optimizations from the Arch I-D:

-          Section 4.4, 2nd to last paragraph (as initially identified by Kostas in his comment (6))

I am fine with removing this "optimization". The effect of the proposed feature is to remove the "store-and-forward" delay. The word of "SHOULD" is a bit strong. But we may need to keep in mind that it can be an important feature. Such opportunistic Write/Read may not be too difficult to handle failures, as Kostas pointed out, if there is a name-data binding to validate.

-          Section 6.1.2, 2nd to last paragraph (as initially identified by Kostas in his comment (8))

Agreed. Batch may not be necessary as in an arch doc.

-          Section 5.2.3, lasts sentence

Agree. One can think of multiple ways to optimize, and may not be limited to temporary data (e.g., write log).

Richard

Does anyone have any objections to this approach?

 

/Akbar

From: Zhang Peng [mailto:pzhang.thu@gmail.com]
Sent: Friday, July 06, 2012 11:36 AM
To: Stephen Farrell
Cc: Rahman, Akbar; DECADE@ietf.org; Konstantinos Pentikousis
Subject: Re: Re: [decade] Working Group Last Call: draft-ietf-decade-arch-07

 

Hi Stephen,

 

I agree with you, and suggest that this optimization should not appear in -arch document, since it is too detailed, and may raise more concerns than it solves. Or we can use MAY instead of SHOULD to indicate that this is a optional feature that are preferable, and state clearly the issues that may arise (i.e., how to deal with client abortion). How would others think? Thanks.

 

B,

 

Peng.

 

 

 

Date: 2012-07-06 05:52

To: pzhang.thu

Subject: Re: [decade] Working Group Last Call: draft-ietf-decade-arch-07

 

I'm not sure if designing optimisations is best done

when considering requirements. It sounds like something

liable to lead to premature optimisation.

 

On 07/06/2012 02:15 AM, Zhang Peng wrote:

> Hi,

> 

> As for the comment (6) regarding optimization about naming, I think we need further discussion.

> 

> The question is that whether the name SHOULD be generated and returned to the client before commitment to the uploading.

> 

> First, we should evaluate the gain by using this what i term as "early name generation". Consider that a client A is uploading a object F to DECADE server D, and another client B needs to download it from D. Below is the stages to be taken without considering authentication, and access control. 

> 

> 1. A sends upload request to D, which responses with a permission

> 2. A uploads F to D

> 3. D returns the object name to A

> 4. A advertises the object 

> 5. B knows the file name and request the object from D

> 6. D sends the object to B

> 

> Here 1,3,4,5 may cost constant small amount of time, while 2,6, depend on the size of object and tend to cost more time. The benefit of putting 3 before 2 is that 4 and 5 can be carried out in parallel with 2. Thus it seems that we can just save the time of 4 and 5 in this process. But considering that B is in different locations, and using another DECADE sever E, then we can also save the time for E request the object from D. In addition, It may also&nbs! p;take&nbs p;more time if we consider the case that A should advertise to a lot of interested receivers, which may consume more time. Without this non-quantitative analysis, it seems that it can benefits the live applications to reduce the latency. But the benefits are not so clear, and may depend on applications. 

 

Putting "3 before 2" wouldn't be the only option though.

For example, A could upload Hash(F) which might be used in

generating the object name at step 1. There are many ways

to do things, setting up requirements that things be done

in one way seems like a bad plan to me.

 

S.

 

> If we would include this in -arch as a design requirements, we need to handle some erroneous situations, just as mentioned by Kostas. When the client advertises a object, but does not upload or finish the uploading, the DECADE server, however, may have already grant the object or send the part of the object to some receiver. Then the server should just sends a error signal to the granted receivers, or let the receivers timeout themselves, and delete the object. Retransmission may or may not&nbs! p;happen,& nbsp;depending on the application implementation.  

> 

> I am still not quite sure whether the potential benefits of this optimization worth the complication it brings. More discussion may be needed. Thanks.

> 

> B,

> 

> Peng.

> 

> 

> From: Rahman, Akbar

> Date: 2012-07-05 01:21

> To: decade@ietf.org

> CC: Konstantinos Pentikousis

> Subject: Re: [decade] Working Group Last Call: draft-ietf-decade-arch-07

> Hi,

> 

> 

> The DECADE Architecture authors were contacted off list by Kostas who

> provided the following relevant and useful comments on the

> draft-ietf-decade-arch-07.  We intend to address these comments in the

> next revision of the architecture I-D after the WGLC ends.  

> 

> 1) Figure 1: 

> This figure and the accompanying text (as-is right now) leaves quite

> some room for interpretation. For example,  two distinct

> "DECADE-compatible" systems deployed by two different operators may have

> DRP1 vs. DPR2, in addition to having multiple SDTxyz's. Is this what you

> have in mind?

> 

> 

> 2) Section 4.2, Referring to the word "multipath":  

> I think you mean multi-source here? Multipath is mostly related with two

> (multihomed) end nodes and routing in the network rather than one node

> getting bits and pieces of a data object from different sources (as in

> P2P). You can still have multipath and single-source.

> 

> 

> 3) Section 4.2, third paragraph, first sentence:

> As per the sec. 2.8, a "data object is a string of raw bytes".

> Therefore, in this sentence we need s/SHOULD/MUST.

> 

> 

> 4) Section 4.2, third paragraph, second sentence:

> This may introduce the issue of MDO discovery (max data object), when

> one connects to different DECADE Servers, perhaps along the lines of MTU

> discovery. Content resegmentation is not covered in this section, esp.

> since a DECADE server may store/maintain DOs from completely different

> apps.

> 

> 

> 5) Section 4.2, last paragraph:

> The introduction of the "block" may be redundant here. A block is,

> similarly to a DO, "a string of raw bytes", isn't it? If not, we need a

> formal definition for it. Of course, the key aspect here is what can you

> name and locate in a DECADE Server, and my reading of the ID so far is

> that you have settled on the use of the DO, irrespective of the

> application semantics. The repeated use of "block" here and there simply

> confuses the uninitiated reader.

> 

> 

> 6) Section 4.4, 2nd to last paragraph:

> I think the optimization described in this paragraph is not particularly

> suited for the Architecture document. And it opens up all kinds of

> questions.  E.G. what if the host advertizing an object crashes before

> it uploads the object? What if the host changes its mind during the

> upload? Since we're talking about immutable objects, shouldn't we wait

> until an object is "committed". In the end, this optimization could be

> counter-productive in these cases. Let alone the fact that the scenarios

> for which DECADE is envisaged (and motivated from I would add) tend to

> have asymmetric capacities in down/uplink, perhaps of a ratio of 10:1.

> Thus, downloading is not typically the performance bottleneck. Perhaps I

> am wrong in thinking of this as a premature optimization though. Can you

> provide examples from exisiting apps that follow this proposal (and how

> do they handle error cases)? 

> 

> Moreover, using SHOULD for such a optimization may not be a good idea in

> the general case.

> 

> 

> 7) Figure 3:

> This figure implies that multiple applications will need to implement

> their own DECADE client, which cannot be shared at run time with other

> apps. Of course one could see this as including/linking to a library,

> but perhaps a more flexible implementation could also be thought of,

> based, for example, on a DECADE "platform", shared by many apps at run

> time.

> 

> 

> 8) Section 6.1.2, second to last paragraph:

> This proposed optimization need not be part of the "architecture"

> 

> 

> 9) Section 6.1.3:

> Wouldn't it be better to skip this section altogether and consider an ID

> on management aspects instead? For example, why not simply define an MIB

> for DECADE and use existing methods to obtain this status info? Why add

> more complexity in DRP implementations?

> 

> 

> 10) Section 10.2:

> http://dx.doi.org/10.1145/1544012.1544078 should also be added here, as

> it motivates well the domain considered in this architecture, including

> the DO.

> 

> 

> 11) Various editorial and grammatical fixes (which were provided to the

> authors off line).

> 

> 

> Many thanks to Kostas for providing these excellent comments.

> 

> 

> Akbar

> 

> 

> -----Original Message-----

> Of Songhaibin

> Sent: Wednesday, June 20, 2012 10:06 PM

> To: decade@ietf.org

> Subject: [decade] Working Group Last Call: draft-ietf-decade-arch-07

> 

> Dear folks,

> 

> After the first round of the last call, the architecture document has

> many changes to resolve comments from reviewers as well as area director

> and experts from other areas. Thanks to the reviewers and the authors.

> 

> So Rich and I now start another round of WGLC on

> draft-ietf-decade-arch-07, ending Friday, July 6th. Please review the

> document and reply with your comments.

> 

> Thanks,

> 

> -Haibin and Rich (co-chairs)

> 

 


--------------020603090002020607070101-- From Akbar.Rahman@InterDigital.com Thu Jul 12 08:59:31 2012 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 6E00F21F8734 for ; Thu, 12 Jul 2012 08:59:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.048 X-Spam-Level: X-Spam-Status: No, score=-1.048 tagged_above=-999 required=5 tests=[AWL=-1.450, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, J_CHICKENPOX_16=0.6, J_CHICKENPOX_33=0.6, J_CHICKENPOX_43=0.6, J_CHICKENPOX_63=0.6] 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 T4mtH+Dcfkjv for ; Thu, 12 Jul 2012 08:59:29 -0700 (PDT) Received: from idcout.InterDigital.com (smtp-out1.interdigital.com [64.208.228.135]) by ietfa.amsl.com (Postfix) with ESMTP id 46A2421F8732 for ; Thu, 12 Jul 2012 08:59:29 -0700 (PDT) Received: from SAM.InterDigital.com ([10.30.2.11]) by idcout.InterDigital.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 12 Jul 2012 12:00:02 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD6047.65236348" X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Thu, 12 Jul 2012 12:00:01 -0400 Message-ID: In-Reply-To: <4FFEEC61.1020901@cs.yale.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [decade] Working Group Last Call: draft-ietf-decade-arch-07 Thread-Index: Ac1gQrpU711TjA9nTMWI5xfLRlMHqgABJIPg References: , <20120705211556235011353@gmail.com>, <4FF6B567.90100@cs.tcd.ie> <20120706113539320678363@gmail.com> <4FFEEC61.1020901@cs.yale.edu> From: "Rahman, Akbar" To: "Y. Richard Yang" X-OriginalArrivalTime: 12 Jul 2012 16:00:02.0207 (UTC) FILETIME=[654C82F0:01CD6047] Cc: Konstantinos Pentikousis , "DECADE@ietf.org" Subject: Re: [decade] Working Group Last Call: draft-ietf-decade-arch-07 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, 12 Jul 2012 15:59:31 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD6047.65236348 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thank you, Richard, for confirming and supporting the change. =20 Akbar =20 From: Y. Richard Yang [mailto:yry@cs.yale.edu]=20 Sent: Thursday, July 12, 2012 11:25 AM To: Rahman, Akbar Cc: pzhang.thu; Stephen Farrell; DECADE@ietf.org; Konstantinos Pentikousis Subject: Re: [decade] Working Group Last Call: draft-ietf-decade-arch-07 =20 On 7/12/12 10:18 PM, Rahman, Akbar wrote: Hi, =20 Sorry for my delay in responding. After thinking about it, I agree with all of you that optimizations are not appropriate for a base architecture document. So I propose that we delete the following optimizations from the Arch I-D: - Section 4.4, 2nd to last paragraph (as initially identified by Kostas in his comment (6)) I am fine with removing this "optimization". The effect of the proposed feature is to remove the "store-and-forward" delay. The word of "SHOULD" is a bit strong. But we may need to keep in mind that it can be an important feature. Such opportunistic Write/Read may not be too difficult to handle failures, as Kostas pointed out, if there is a name-data binding to validate. Section 6.1.2, 2nd to last paragraph (as initially identified by Kostas in his comment (8)) Agreed. Batch may not be necessary as in an arch doc. Section 5.2.3, lasts sentence Agree. One can think of multiple ways to optimize, and may not be limited to temporary data (e.g., write log). Richard Does anyone have any objections to this approach? =20 /Akbar From: Zhang Peng [mailto:pzhang.thu@gmail.com]=20 Sent: Friday, July 06, 2012 11:36 AM To: Stephen Farrell Cc: Rahman, Akbar; DECADE@ietf.org; Konstantinos Pentikousis Subject: Re: Re: [decade] Working Group Last Call: draft-ietf-decade-arch-07 =20 Hi Stephen, =20 I agree with you, and suggest that this optimization should not appear in -arch document, since it is too detailed, and may raise more concerns than it solves. Or we can use MAY instead of SHOULD to indicate that this is a optional feature that are preferable, and state clearly the issues that may arise (i.e., how to deal with client abortion). How would others think? Thanks. =20 B, =20 Peng. =20 =20 =20 From: Stephen Farrell =20 Date: 2012-07-06 05:52 To: pzhang.thu =20 CC: Rahman, Akbar ; DECADE@ietf.org; Konstantinos Pentikousis =20 Subject: Re: [decade] Working Group Last Call: draft-ietf-decade-arch-07 =20 I'm not sure if designing optimisations is best done when considering requirements. It sounds like something liable to lead to premature optimisation. =20 On 07/06/2012 02:15 AM, Zhang Peng wrote: > Hi, >=20 > As for the comment (6) regarding optimization about naming, I think we need further discussion. >=20 > The question is that whether the name SHOULD be generated and returned to the client before commitment to the uploading. >=20 > First, we should evaluate the gain by using this what i term as "early name generation". Consider that a client A is uploading a object F to DECADE server D, and another client B needs to download it from D. Below is the stages to be taken without considering authentication, and access control.=20 >=20 > 1. A sends upload request to D, which responses with a permission > 2. A uploads F to D > 3. D returns the object name to A > 4. A advertises the object=20 > 5. B knows the file name and request the object from D > 6. D sends the object to B >=20 > Here 1,3,4,5 may cost constant small amount of time, while 2,6, depend on the size of object and tend to cost more time. The benefit of putting 3 before 2 is that 4 and 5 can be carried out in parallel with 2. Thus it seems that we can just save the time of 4 and 5 in this process. But considering that B is in different locations, and using another DECADE sever E, then we can also save the time for E request the object from D. In addition, It may also&nbs! p;take&nbs p;more time if we consider the case that A should advertise to a lot of interested receivers, which may consume more time. Without this non-quantitative analysis, it seems that it can benefits the live applications to reduce the latency. But the benefits are not so clear, and may depend on applications.=20 =20 Putting "3 before 2" wouldn't be the only option though. For example, A could upload Hash(F) which might be used in generating the object name at step 1. There are many ways to do things, setting up requirements that things be done in one way seems like a bad plan to me. =20 S. =20 > If we would include this in -arch as a design requirements, we need to handle some erroneous situations, just as mentioned by Kostas. When the client advertises a object, but does not upload or finish the uploading, the DECADE server, however, may have already grant the object or send the part of the object to some receiver. Then the server should just sends a error signal to the granted receivers, or let the receivers timeout themselves, and delete the object. Retransmission may or may not&nbs! p;happen,& nbsp;depending on the application implementation. =20 >=20 > I am still not quite sure whether the potential benefits of this optimization worth the complication it brings. More discussion may be needed. Thanks. >=20 > B, >=20 > Peng. >=20 >=20 > From: Rahman, Akbar > Date: 2012-07-05 01:21 > To: decade@ietf.org > CC: Konstantinos Pentikousis > Subject: Re: [decade] Working Group Last Call: draft-ietf-decade-arch-07 > Hi, >=20 >=20 > The DECADE Architecture authors were contacted off list by Kostas who > provided the following relevant and useful comments on the > draft-ietf-decade-arch-07. We intend to address these comments in the > next revision of the architecture I-D after the WGLC ends. =20 >=20 > 1) Figure 1:=20 > This figure and the accompanying text (as-is right now) leaves quite > some room for interpretation. For example, two distinct > "DECADE-compatible" systems deployed by two different operators may have > DRP1 vs. DPR2, in addition to having multiple SDTxyz's. Is this what you > have in mind? >=20 >=20 > 2) Section 4.2, Referring to the word "multipath": =20 > I think you mean multi-source here? Multipath is mostly related with two > (multihomed) end nodes and routing in the network rather than one node > getting bits and pieces of a data object from different sources (as in > P2P). You can still have multipath and single-source. >=20 >=20 > 3) Section 4.2, third paragraph, first sentence: > As per the sec. 2.8, a "data object is a string of raw bytes". > Therefore, in this sentence we need s/SHOULD/MUST. >=20 >=20 > 4) Section 4.2, third paragraph, second sentence: > This may introduce the issue of MDO discovery (max data object), when > one connects to different DECADE Servers, perhaps along the lines of MTU > discovery. Content resegmentation is not covered in this section, esp. > since a DECADE server may store/maintain DOs from completely different > apps. >=20 >=20 > 5) Section 4.2, last paragraph: > The introduction of the "block" may be redundant here. A block is, > similarly to a DO, "a string of raw bytes", isn't it? If not, we need a > formal definition for it. Of course, the key aspect here is what can you > name and locate in a DECADE Server, and my reading of the ID so far is > that you have settled on the use of the DO, irrespective of the > application semantics. The repeated use of "block" here and there simply > confuses the uninitiated reader. >=20 >=20 > 6) Section 4.4, 2nd to last paragraph: > I think the optimization described in this paragraph is not particularly > suited for the Architecture document. And it opens up all kinds of > questions. E.G. what if the host advertizing an object crashes before > it uploads the object? What if the host changes its mind during the > upload? Since we're talking about immutable objects, shouldn't we wait > until an object is "committed". In the end, this optimization could be > counter-productive in these cases. Let alone the fact that the scenarios > for which DECADE is envisaged (and motivated from I would add) tend to > have asymmetric capacities in down/uplink, perhaps of a ratio of 10:1. > Thus, downloading is not typically the performance bottleneck. Perhaps I > am wrong in thinking of this as a premature optimization though. Can you > provide examples from exisiting apps that follow this proposal (and how > do they handle error cases)?=20 >=20 > Moreover, using SHOULD for such a optimization may not be a good idea in > the general case. >=20 >=20 > 7) Figure 3: > This figure implies that multiple applications will need to implement > their own DECADE client, which cannot be shared at run time with other > apps. Of course one could see this as including/linking to a library, > but perhaps a more flexible implementation could also be thought of, > based, for example, on a DECADE "platform", shared by many apps at run > time. >=20 >=20 > 8) Section 6.1.2, second to last paragraph: > This proposed optimization need not be part of the "architecture" >=20 >=20 > 9) Section 6.1.3: > Wouldn't it be better to skip this section altogether and consider an ID > on management aspects instead? For example, why not simply define an MIB > for DECADE and use existing methods to obtain this status info? Why add > more complexity in DRP implementations? >=20 >=20 > 10) Section 10.2: > http://dx.doi.org/10.1145/1544012.1544078 should also be added here, as > it motivates well the domain considered in this architecture, including > the DO. >=20 >=20 > 11) Various editorial and grammatical fixes (which were provided to the > authors off line). >=20 >=20 > Many thanks to Kostas for providing these excellent comments. >=20 >=20 > Akbar >=20 >=20 > -----Original Message----- > From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.org] On Behalf > Of Songhaibin > Sent: Wednesday, June 20, 2012 10:06 PM > To: decade@ietf.org > Subject: [decade] Working Group Last Call: draft-ietf-decade-arch-07 >=20 > Dear folks, >=20 > After the first round of the last call, the architecture document has > many changes to resolve comments from reviewers as well as area director > and experts from other areas. Thanks to the reviewers and the authors. >=20 > So Rich and I now start another round of WGLC on > draft-ietf-decade-arch-07, ending Friday, July 6th. Please review the > document and reply with your comments. >=20 > Thanks, >=20 > -Haibin and Rich (co-chairs) >=20 =20 =20 ------_=_NextPart_001_01CD6047.65236348 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thank you, Richard, for confirming and supporting the = change.

 

Akbar

 

From: Y. Richard Yang [mailto:yry@cs.yale.edu]
Sent: = Thursday, July 12, 2012 11:25 AM
To: Rahman, = Akbar
Cc: pzhang.thu; Stephen Farrell; DECADE@ietf.org; = Konstantinos Pentikousis
Subject: Re: [decade] Working Group = Last Call: draft-ietf-decade-arch-07

 

On = 7/12/12 10:18 PM, Rahman, Akbar wrote:

Hi,

 

Sorry for my delay in responding.  After thinking about it, I = agree with all of you that optimizations are not appropriate for a base = architecture document.  So I propose that we delete the following = optimizations from the Arch I-D:

-          = Section 4.4, 2nd to last&n= bsp;paragraph (as initially identified by Kostas in his comment = (6))

I am fine with removing this = "optimization". The effect of the proposed feature is to = remove the "store-and-forward" delay. The word of = "SHOULD" is a bit strong. But we may need to keep in mind that = it can be an important feature. Such opportunistic Write/Read may not be = too difficult to handle failures, as Kostas pointed out, if there is a = name-data binding to validate.


Section 6.1.2, 2nd to last=  paragraph (as initially identified by Kostas in his comment = (8))

Agreed. Batch may not be = necessary as in an arch doc.


Section = 5.2.3, lasts sentence

Agree. One can think of = multiple ways to optimize, and may not be limited to temporary data = (e.g., write log).

Richard


Does anyone have any objections to this = approach?

 

/Akbar

From:= = Zhang Peng [mailto:pzhang.thu@gmail.com] =
Sent: Friday, July 06, 2012 11:36 AM
To: Stephen = Farrell
Cc: Rahman, Akbar; DECADE@ietf.org; Konstantinos = Pentikousis
Subject: Re: Re: [decade] Working Group Last Call: = draft-ietf-decade-arch-07

 

Hi = Stephen,

 

I agree with you, and suggest that this = optimization should not appear in -arch document, since it is too = detailed, and may raise more concerns than it solves. Or we can use MAY = instead of SHOULD to indicate that this is a optional feature that are = preferable, and state clearly the issues that may arise (i.e., how to = deal with client abortion). How would others think? = Thanks.

 

B,

 

Peng.

 

 

 

Date: 2012-07-06 05:52

To: pzhang.thu

=

Subject: Re: [decade] Working Group Last Call: = draft-ietf-decade-arch-07

 

I'm not sure if designing&= nbsp;optimisations is best done

when considering requirements. = It sounds like something

<= p class=3DMsoNormal style=3D'margin:0in;margin-bottom:.0001pt'>liable to lead to prematur= e optimisation.

 

On 07/06/2012 02:15 AM, Zh= ang Peng wrote:

> Hi,

=

> 

> As for the comment&nb= sp;(6) regarding optimization about naming, I&nb= sp;think we need further discussion.

> 

> The question is that&= nbsp;whether the name SHOULD be generated a= nd returned to the client before commitment=  to the uploading.

> 

> First, we should eval= uate the gain by using this what i&nbs= p;term as "early name generation". Con= sider that a client A is uploading a&n= bsp;object F to DECADE server D, and a= nother client B needs to download it f= rom D. Below is the stages to be = taken without considering authentication, and ac= cess control. 

> 

> 1. A sends upload&nbs= p;request to D, which responses with a = ;permission

> 2. A uploads F t= o D

> 3. D returns the = ;object name to A

> 4. A advertises the&n= bsp;object 

> 5. B knows the f= ile name and request the object from D=

> 6. D sends the o= bject to B

> 

> Here 1,3,4,5 may cost=  constant small amount of time, while = 2,6, depend on the size of object and&= nbsp;tend to cost more time. The benefit&nb= sp;of putting 3 before 2 is that 4&nbs= p;and 5 can be carried out in parallel=  with 2. Thus it seems that we ca= n just save the time of 4 and 5&n= bsp;in this process. But considering that B=  is in different locations, and using = another DECADE sever E, then we can al= so save the time for E request the&nbs= p;object from D. In addition, It may a= lso&nbs! p;take&nbs = p;more time if we consider the case th= at A should advertise to a lot of = ;interested receivers, which may consume more&nb= sp;time. Without this non-quantitative analysis, = ;it seems that it can benefits the liv= e applications to reduce the latency. But&n= bsp;the benefits are not so clear, and = ;may depend on applications. 

 

Putting "3 before 2"&= nbsp;wouldn't be the only option though.<= o:p>

For example, A could uploa= d Hash(F) which might be used in

generating the object name = ;at step 1. There are many ways=

to do things, setting up&n= bsp;requirements that things be done

in one way seems like = ;a bad plan to me.

 

S.

 

> If we would include&n= bsp;this in -arch as a design requirements,=  we need to handle some erroneous situ= ations, just as mentioned by Kostas. When&n= bsp;the client advertises a object, but doe= s not upload or finish the uploading, = the DECADE server, however, may have alread= y grant the object or send the part&nb= sp;of the object to some receiver. Then&nbs= p;the server should just sends a error = ;signal to the granted receivers, or let&nb= sp;the receivers timeout themselves, and delete&= nbsp;the object. Retransmission may or may = not&nbs! p;happen,& = nbsp;depending on the application implementation.&nbs= p; 

> 

> I am still not q= uite sure whether the potential benefits of=  this optimization worth the complication i= t brings. More discussion may be needed.&nb= sp;Thanks.

> 

> B,

<= p class=3DMsoNormal style=3D'margin:0in;margin-bottom:.0001pt'>> 

> Peng.

> 

> 

> From: Rahman, Akbar=

> Date: 2012-07-05 01:21

> To: decade@ietf.org

=

> CC: Konstantinos Pentikous= is

> Subject: Re: [decade] = ;Working Group Last Call: draft-ietf-decade-arch-07

> Hi,

=

> 

> 

> The DECADE Architecture&nb= sp;authors were contacted off list by Kosta= s who

> provided the following&nbs= p;relevant and useful comments on the

> draft-ietf-decade-arch-07. &nbs= p;We intend to address these comments in&nb= sp;the

> next revision of the&= nbsp;architecture I-D after the WGLC ends. =  

> 

> 1) Figure 1: <= o:p>

> This figure and the&n= bsp;accompanying text (as-is right now) leaves&n= bsp;quite

> some room for interpr= etation. For example,  two distinct<= /o:p>

> "DECADE-compatible" s= ystems deployed by two different operators = may have

> DRP1 vs. DPR2, in&nbs= p;addition to having multiple SDTxyz's. Is = this what you

> have in mind?<= /o:p>

> 

> 

> 2) Section 4.2, Refer= ring to the word "multipath":  

> I think you mean = ;multi-source here? Multipath is mostly related&= nbsp;with two

> (multihomed) end nodes&nbs= p;and routing in the network rather than&nb= sp;one node

> getting bits and piec= es of a data object from different sou= rces (as in

> P2P). You can still&n= bsp;have multipath and single-source.

> 

> 

> 3) Section 4.2, third=  paragraph, first sentence:

> As per the sec. = 2.8, a "data object is a string o= f raw bytes".

> Therefore, in this se= ntence we need s/SHOULD/MUST.

<= div>

> 

> 

> 4) Section 4.2, third=  paragraph, second sentence:

> This may introduce th= e issue of MDO discovery (max data obj= ect), when

> one connects to diffe= rent DECADE Servers, perhaps along the line= s of MTU

> discovery. Content resegme= ntation is not covered in this section,&nbs= p;esp.

> since a DECADE server=  may store/maintain DOs from completely dif= ferent

> apps.

> 

> 

> 5) Section 4.2, last&= nbsp;paragraph:

> The introduction of t= he "block" may be redundant here. = ;A block is,

> similarly to a DO,&nb= sp;"a string of raw bytes", isn't = ;it? If not, we need a

> formal definition for = ;it. Of course, the key aspect here is=  what can you

> name and locate in&nb= sp;a DECADE Server, and my reading of = the ID so far is

> that you have settled=  on the use of the DO, irrespective&nb= sp;of the

> application semantics. The=  repeated use of "block" here and=  there simply

> confuses the uninitiated&n= bsp;reader.

> 

> 

> 6) Section 4.4, 2nd&n= bsp;to last paragraph:

> I think the optimizat= ion described in this paragraph is not = ;particularly

> suited for the Archit= ecture document. And it opens up all k= inds of

> questions.  E.G. what=  if the host advertizing an object cra= shes before

> it uploads the object= ? What if the host changes its mind&nb= sp;during the

> upload? Since we're t= alking about immutable objects, shouldn't we&nbs= p;wait

> until an object is&nb= sp;"committed". In the end, this optim= ization could be

> counter-productive in thes= e cases. Let alone the fact that the&n= bsp;scenarios

> for which DECADE is&n= bsp;envisaged (and motivated from I would a= dd) tend to

> have asymmetric capacities=  in down/uplink, perhaps of a ratio of=  10:1.

> Thus, downloading is = not typically the performance bottleneck. Perhap= s I

> am wrong in thinking&= nbsp;of this as a premature optimization th= ough. Can you

> provide examples from = ;exisiting apps that follow this proposal (= and how

> do they handle error&= nbsp;cases)? 

> 

> Moreover, using SHOULD&nbs= p;for such a optimization may not be a=  good idea in

> the general case.

> 

> 

> 7) Figure 3:

> This figure implies t= hat multiple applications will need to impl= ement

> their own DECADE clie= nt, which cannot be shared at run time=  with other

> apps. Of course one&n= bsp;could see this as including/linking to = a library,

> but perhaps a more&nb= sp;flexible implementation could also be thought=  of,

> based, for example, o= n a DECADE "platform", shared by = many apps at run

> time.

> 

> 

> 8) Section 6.1.2, sec= ond to last paragraph:

> This proposed optimization=  need not be part of the "archite= cture"

> 

> 

> 9) Section 6.1.3:

> Wouldn't it be better=  to skip this section altogether and c= onsider an ID

> on management aspects = ;instead? For example, why not simply defin= e an MIB

> for DECADE and use&nb= sp;existing methods to obtain this status i= nfo? Why add

> more complexity in DR= P implementations?

> 

> 

> 10) Section 10.2:

> http://dx.doi.org/10.1= 145/1544012.1544078 should also be added her= e, as

> it motivates well the=  domain considered in this architecture, in= cluding

> the DO.

> 

> 

> 11) Various editorial = ;and grammatical fixes (which were provided = ;to the

> authors off line).<= o:p>

> 

> 

> Many thanks to Kostas=  for providing these excellent comments.<= o:p>

> 

> 

> Akbar

> 

> 

> -----Original Message-----

> Subject: [decade] Working&= nbsp;Group Last Call: draft-ietf-decade-arch-07

> 

> Dear folks,

> 

> After the first round=  of the last call, the architecture do= cument has

> many changes to resol= ve comments from reviewers as well as = area director

> and experts from othe= r areas. Thanks to the reviewers and t= he authors.

> 

> So Rich and I no= w start another round of WGLC on

> draft-ietf-decade-arch-07, endi= ng Friday, July 6th. Please review the

> document and reply wi= th your comments.

> 

> Thanks,

<= div>

> 

> -Haibin and Rich (co-= chairs)

> 

 

 

------_=_NextPart_001_01CD6047.65236348-- From pzhang.thu@gmail.com Thu Jul 12 13:28:20 2012 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 2CBBE11E8096; Thu, 12 Jul 2012 13:28:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.304 X-Spam-Level: X-Spam-Status: No, score=-3.304 tagged_above=-999 required=5 tests=[AWL=0.295, BAYES_00=-2.599, 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 edR6Ao8qCdjY; Thu, 12 Jul 2012 13:28:19 -0700 (PDT) Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id 18F9F11E8080; Thu, 12 Jul 2012 13:28:19 -0700 (PDT) Received: by qaea16 with SMTP id a16so1929456qae.10 for ; Thu, 12 Jul 2012 13:28:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=wT7m4tPFgv3SqXzFZ+I+dR7he8wP5J2g2KzPRXVw0KE=; b=eY4fKZurtz/hSkeKU40jPZB68EgyqoIkSDfJjbdEorJkjEIE0gSD+xLnK5fFe66YS9 PmALRsD7qKHNUYkf0MCbmaILKUsQp+AtCRsyeO3v5cvNg1f5W+phuFvVA6ssYZFZjRlA qrM6LYuRh2SsvQ/h7Qsf2XvUEkyW/0q0bTHVBfDadSi1exCaiEYEctBWF3A5HcCClfGL jgPmE/GGhHbQTvRgnxs2k2qA/EtXdMYviwC5YTHKbC6Oh3wY7+O3ktaa/tMvd4RJ6Byw K3bTgxHilX13u1gs4tn5x4k67rLL9DnuH5CFBcedDLNgaa+G4Yl2kQ1kapF+TYUe1/gL 9cjw== Received: by 10.229.135.75 with SMTP id m11mr28743911qct.74.1342124932891; Thu, 12 Jul 2012 13:28:52 -0700 (PDT) Received: from [128.36.160.220] ([128.36.160.220]) by mx.google.com with ESMTPS id w14sm3730489qaz.17.2012.07.12.13.28.51 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 12 Jul 2012 13:28:52 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Peng Zhang In-Reply-To: <4FFE6D67.80705@cs.vu.nl> Date: Thu, 12 Jul 2012 16:28:50 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120710162606039401143@chinamobile.com> <2039343B-5F6B-4777-864E-B4F00B5A258E@gmail.com> <4FFE6D67.80705@cs.vu.nl> To: X-Mailer: Apple Mail (2.1278) Cc: ppsp , decade Subject: Re: [decade] [ppsp] Object naming in -req and -arch 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, 12 Jul 2012 20:28:20 -0000 On Jul 12, 2012, at 2:23 AM, Arno Bakker wrote: > Hi Peng >=20 > On 11/07/2012 23:25, Peng Zhang wrote: >> Hi Arno, >>=20 >> Thanks for the clarification. In my understanding, MHT over single = hash >> can enable immediate integrity check before the whole media file is >> received, which is critical for streaming applications. But the = client >> can also download hashes of every piece, just like in BitTorrent. = Does >> it reduce a lot startup latency or server load by using MHT? Thanks. >>=20 >=20 > The gains of using MHT depend on the chunk size. For PPSP we prefer = chunks of 1K that fit in an UDP packet carried over Ethernet. In that = case, for a 4 GB file, there are 4 M chunks, resulting in 80 MB of leaf = hashes when SHA1 is used. Transferring that beforehand as in BitTorrent = definitely increases latency ;o) Yes, if the chunk size is only 1KB, and each chunk is verified = individually, we cannot afford to send all hashes beforehand. While in = the worst case without optimization, almost 2*80M =3D 160M hashes needs = to be sent to the receiver, will that be a large overhead compared to = 4G? Do we really need such a small chunk size? Maybe I miss some = previous discussion on this. >=20 >=20 >> For DECADE, It supports integrity check on piece/chunk level, so that >> client can verify that the received piece corresponds to the piece = name. >> DECADE is unaware of what file this piece belongs to, and thus does = not >> provide end-to-end integrity check. For file level, we leave the >> integrity check to applications. Thus, imo, we should not include MHT = in >> the design of DECADE. But MHT can be built on top of DECADE, which = means >> applications can still use MHT to implement integrity check for = themselves. >>=20 >=20 > You are right, if DECADE doesn't provide "links" between chunks, MHTs = at the DECADE level make no sense. Using MHTs at the app level instead = as you say does make sense and is easy, just build all the piece = names/piece hashes into a tree. Yes, Exactly. >=20 > Regards, > Arno From a.bakker@vu.nl Fri Jul 13 00:12:01 2012 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 7E4F421F8795; Fri, 13 Jul 2012 00:12:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.535 X-Spam-Level: X-Spam-Status: No, score=-1.535 tagged_above=-999 required=5 tests=[AWL=-0.031, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, 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 2UasvDiPPu2y; Fri, 13 Jul 2012 00:12:00 -0700 (PDT) Received: from mailin.vu.nl (mailin.vu.nl [130.37.164.18]) by ietfa.amsl.com (Postfix) with ESMTP id 870D021F8790; Fri, 13 Jul 2012 00:12:00 -0700 (PDT) Received: from PEXHB012A.vu.local (130.37.236.66) by mailin.vu.nl (130.37.164.18) with Microsoft SMTP Server (TLS) id 14.2.298.4; Fri, 13 Jul 2012 09:12:32 +0200 Received: from [192.168.0.104] (130.37.238.20) by mails.vu.nl (130.37.236.66) with Microsoft SMTP Server (TLS) id 14.2.298.4; Fri, 13 Jul 2012 09:12:34 +0200 Message-ID: <4FFFCA6D.7060306@cs.vu.nl> Date: Fri, 13 Jul 2012 09:12:45 +0200 From: Arno Bakker User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: Peng Zhang References: <20120710162606039401143@chinamobile.com> <2039343B-5F6B-4777-864E-B4F00B5A258E@gmail.com> <4FFE6D67.80705@cs.vu.nl> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [130.37.238.20] Cc: ppsp , decade Subject: Re: [decade] [ppsp] Object naming in -req and -arch X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: arno@cs.vu.nl 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, 13 Jul 2012 07:12:01 -0000 On 12/07/2012 22:28, Peng Zhang wrote: > > On Jul 12, 2012, at 2:23 AM, Arno Bakker wrote: > >> The gains of using MHT depend on the chunk size. For PPSP we prefer >> chunks of 1K that fit in an UDP packet carried over Ethernet. In >> that case, for a 4 GB file, there are 4 M chunks, resulting in 80 >> MB of leaf hashes when SHA1 is used. Transferring that beforehand >> as in BitTorrent definitely increases latency ;o) > Yes, if the chunk size is only 1KB, and each chunk is verified > individually, we cannot afford to send all hashes beforehand. While > in the worst case without optimization, almost 2*80M = 160M hashes > needs to be sent to the receiver, will that be a large overhead > compared to 4G? Do we really need such a small chunk size? Maybe I > miss some previous discussion on this. Hi For PPSP we want to use UDP as we don't need the in-order and reliability features of TCP, and want flexibility to use differnet congestion control algorithms and handle NATs. With Ethernet as the dominant MAC layer at present and an unreliable transport we don't want datagrams to exceed the Ethernet MTU, otherwise the chance of losing a datagram increases (an UDP packet taking N IP packets will not be delivered when only 1 IP packet is lost). Hence, we use chunks of ~1K. A good practice in P2P networks is to not forward data you have not verified. So to forward the 1K chunks directly we need to be able to verify their integrity at this granularity, enter Merkle Hash Trees. We think the resulting overhead due to the size of the tree is acceptable, as it is easy to optimize the number of hashes transmitted in our use cases. CU, Arno From internet-drafts@ietf.org Fri Jul 13 17:54:56 2012 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 7A9AF11E80EC; Fri, 13 Jul 2012 17:54:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.515 X-Spam-Level: X-Spam-Status: No, score=-102.515 tagged_above=-999 required=5 tests=[AWL=0.084, 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 kFb-yYVCXgia; Fri, 13 Jul 2012 17:54:55 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5D0411E80A4; Fri, 13 Jul 2012 17:54:55 -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: 4.30p3 Message-ID: <20120714005455.9377.62786.idtracker@ietfa.amsl.com> Date: Fri, 13 Jul 2012 17:54:55 -0700 Cc: decade@ietf.org Subject: [decade] I-D Action: draft-ietf-decade-arch-08.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: Sat, 14 Jul 2012 00:54:56 -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 Workin= g Group of the IETF. Title : DECADE Architecture Author(s) : Richard Alimi Akbar Rahman Dirk Kutscher Y. Richard Yang Filename : draft-ietf-decade-arch-08.txt Pages : 30 Date : 2012-07-13 Abstract: 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 provided by a DECADE (DECoupled Application Data Enroute) compatible system. This document presents an architecture, discusses the underlying principles, and identifies key functionalities in the architecture for introducing a DECADE- compatible in-network storage system. In addition, some examples are given to illustrate these concepts. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-decade-arch There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-decade-arch-08 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-decade-arch-08 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From Akbar.Rahman@InterDigital.com Fri Jul 13 18:00:25 2012 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 BB0AE21F8766 for ; Fri, 13 Jul 2012 18:00:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.342 X-Spam-Level: X-Spam-Status: No, score=-2.342 tagged_above=-999 required=5 tests=[AWL=0.257, 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 Jy6XU43ojrD1 for ; Fri, 13 Jul 2012 18:00:24 -0700 (PDT) Received: from idcout.InterDigital.com (smtp-out1.interdigital.com [64.208.228.135]) by ietfa.amsl.com (Postfix) with ESMTP id 8502421F8764 for ; Fri, 13 Jul 2012 18:00:24 -0700 (PDT) Received: from SAM.InterDigital.com ([10.30.2.11]) by idcout.InterDigital.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 13 Jul 2012 21:01:01 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Date: Fri, 13 Jul 2012 21:00:59 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Message-ID: In-Reply-To: <20120714005455.9377.62786.idtracker@ietfa.amsl.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [decade] I-D Action: draft-ietf-decade-arch-08.txt Thread-Index: Ac1hW2Z4yC27nuMpRt+EZpxZAI0gGAAAB5ng References: <20120714005455.9377.62786.idtracker@ietfa.amsl.com> From: "Rahman, Akbar" To: X-OriginalArrivalTime: 14 Jul 2012 01:01:01.0489 (UTC) FILETIME=[22F3A210:01CD615C] Cc: Konstantinos Pentikousis Subject: Re: [decade] I-D Action: draft-ietf-decade-arch-08.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: Sat, 14 Jul 2012 01:00:25 -0000 SGksDQoNCg0KV2UgaGF2ZSBkb25lIGFuIHVwZGF0ZSBiYXNlZCBvbiB0aGUgZXhjZWxsZW50IFdH TEMgY29tbWVudHMgZnJvbSBLb3N0YXMuICBQbGVhc2UgcmV2aWV3IGFuZCB3cml0ZSBiYWNrIGlm IHlvdSBoYXZlIGFueSBtb3JlIHF1ZXN0aW9ucy9jb21tZW50cy4NCg0KDQpTaW5jZXJlbHksDQoN Cg0KQWtiYXINCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogZGVjYWRlLWJv dW5jZXNAaWV0Zi5vcmcgW21haWx0bzpkZWNhZGUtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxm IE9mIGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZw0KU2VudDogRnJpZGF5LCBKdWx5IDEzLCAyMDEy IDg6NTUgUE0NClRvOiBpLWQtYW5ub3VuY2VAaWV0Zi5vcmcNCkNjOiBkZWNhZGVAaWV0Zi5vcmcN ClN1YmplY3Q6IFtkZWNhZGVdIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtZGVjYWRlLWFyY2gtMDgu dHh0DQoNCg0KQSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhlIG9uLWxp bmUgSW50ZXJuZXQtRHJhZnRzIGRpcmVjdG9yaWVzLg0KIFRoaXMgZHJhZnQgaXMgYSB3b3JrIGl0 ZW0gb2YgdGhlIERlY291cGxlZCBBcHBsaWNhdGlvbiBEYXRhIEVucm91dGUgV29ya2luZyBHcm91 cCBvZiB0aGUgSUVURi4NCg0KCVRpdGxlICAgICAgICAgICA6IERFQ0FERSBBcmNoaXRlY3R1cmUN CglBdXRob3IocykgICAgICAgOiBSaWNoYXJkIEFsaW1pDQogICAgICAgICAgICAgICAgICAgICAg ICAgIEFrYmFyIFJhaG1hbg0KICAgICAgICAgICAgICAgICAgICAgICAgICBEaXJrIEt1dHNjaGVy DQogICAgICAgICAgICAgICAgICAgICAgICAgIFkuIFJpY2hhcmQgWWFuZw0KCUZpbGVuYW1lICAg ICAgICA6IGRyYWZ0LWlldGYtZGVjYWRlLWFyY2gtMDgudHh0DQoJUGFnZXMgICAgICAgICAgIDog MzANCglEYXRlICAgICAgICAgICAgOiAyMDEyLTA3LTEzDQoNCkFic3RyYWN0Og0KICAgQ29udGVu dCBEaXN0cmlidXRpb24gQXBwbGljYXRpb25zIChlLmcuLCBQMlAgYXBwbGljYXRpb25zKSBhcmUg d2lkZWx5DQogICB1c2VkIG9uIHRoZSBJbnRlcm5ldCBhbmQgbWFrZSB1cCBhIGxhcmdlIHBvcnRp b24gb2YgdGhlIHRyYWZmaWMgaW4NCiAgIG1hbnkgbmV0d29ya3MuICBPbmUgdGVjaG5pcXVlIHRv IGltcHJvdmUgdGhlIG5ldHdvcmsgZWZmaWNpZW5jeSBvZg0KICAgdGhlc2UgYXBwbGljYXRpb25z IGlzIHRvIGludHJvZHVjZSBzdG9yYWdlIGNhcGFiaWxpdGllcyB3aXRoaW4gdGhlDQogICBuZXR3 b3JrczsgdGhpcyBpcyB0aGUgY2FwYWJpbGl0eSBwcm92aWRlZCBieSBhIERFQ0FERSAoREVDb3Vw bGVkDQogICBBcHBsaWNhdGlvbiBEYXRhIEVucm91dGUpIGNvbXBhdGlibGUgc3lzdGVtLiAgVGhp cyBkb2N1bWVudCBwcmVzZW50cw0KICAgYW4gYXJjaGl0ZWN0dXJlLCBkaXNjdXNzZXMgdGhlIHVu ZGVybHlpbmcgcHJpbmNpcGxlcywgYW5kIGlkZW50aWZpZXMNCiAgIGtleSBmdW5jdGlvbmFsaXRp ZXMgaW4gdGhlIGFyY2hpdGVjdHVyZSBmb3IgaW50cm9kdWNpbmcgYSBERUNBREUtDQogICBjb21w YXRpYmxlIGluLW5ldHdvcmsgc3RvcmFnZSBzeXN0ZW0uICBJbiBhZGRpdGlvbiwgc29tZSBleGFt cGxlcyBhcmUNCiAgIGdpdmVuIHRvIGlsbHVzdHJhdGUgdGhlc2UgY29uY2VwdHMuDQoNCg0KDQpU aGUgSUVURiBkYXRhdHJhY2tlciBzdGF0dXMgcGFnZSBmb3IgdGhpcyBkcmFmdCBpczoNCmh0dHBz Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtZGVjYWRlLWFyY2gNCg0KVGhl cmUncyBhbHNvIGEgaHRtbGl6ZWQgdmVyc2lvbiBhdmFpbGFibGUgYXQ6DQpodHRwOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWRlY2FkZS1hcmNoLTA4DQoNCkEgZGlmZiBmcm9tIHBy ZXZpb3VzIHZlcnNpb24gaXMgYXZhaWxhYmxlIGF0Og0KaHR0cDovL3Rvb2xzLmlldGYub3JnL3Jm Y2RpZmY/dXJsMj1kcmFmdC1pZXRmLWRlY2FkZS1hcmNoLTA4DQoNCg0KSW50ZXJuZXQtRHJhZnRz IGFyZSBhbHNvIGF2YWlsYWJsZSBieSBhbm9ueW1vdXMgRlRQIGF0Og0KZnRwOi8vZnRwLmlldGYu b3JnL2ludGVybmV0LWRyYWZ0cy8NCg0K From wangdanhua@huawei.com Mon Jul 16 02:28:59 2012 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 A2FAA21F86C3 for ; Mon, 16 Jul 2012 02:28:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.299 X-Spam-Level: X-Spam-Status: No, score=-4.299 tagged_above=-999 required=5 tests=[AWL=2.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 yNSj64r4tE97 for ; Mon, 16 Jul 2012 02:28:59 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 0E67021F86C2 for ; Mon, 16 Jul 2012 02:28:59 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AIB21865; Mon, 16 Jul 2012 05:29:43 -0400 (EDT) Received: from DFWEML404-HUB.china.huawei.com (10.193.5.203) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 16 Jul 2012 02:27:09 -0700 Received: from SZXEML420-HUB.china.huawei.com (10.82.67.159) by dfweml404-hub.china.huawei.com (10.193.5.203) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 16 Jul 2012 02:27:09 -0700 Received: from SZXEML507-MBS.china.huawei.com ([169.254.7.110]) by szxeml420-hub.china.huawei.com ([10.82.67.159]) with mapi id 14.01.0323.003; Mon, 16 Jul 2012 17:26:23 +0800 From: Wangdanhua To: "DECADE@ietf.org" Thread-Topic: Forward: New Version Notification for draft-wang-decade-drp-04.txt Thread-Index: AQHNYzUQ9TWKOFgkYUqJXaH3+SgVxQ== Date: Mon, 16 Jul 2012 09:26:22 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.177] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [decade] Forward: New Version Notification for draft-wang-decade-drp-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: Mon, 16 Jul 2012 09:28:59 -0000 SGkgYWxsLA0KDQpXZSBqdXN0IHVwbG9hZGVkIGEgbmV3IHZlcnNpb24gb2YgdGhlIGRyYWZ0LXdh bmctZGVjYWRlLWRycC4gQW55IGNvbW1lbnRzIG9yIHN1Z2dlc3Rpb25zIGFyZSBhcHByZWNpYXRl ZC4NCg0KQmVzdCB3aXNoZXMsDQpEYW5odWEgV2FuZw0KDQotLS0tLemCruS7tuWOn+S7ti0tLS0t DQrlj5Hku7bkuro6IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmludGVybmV0LWRy YWZ0c0BpZXRmLm9yZ10gDQrlj5HpgIHml7bpl7Q6IDIwMTLlubQ35pyIMTbml6UgMTQ6MTcNCuaU tuS7tuS6ujogV2FuZ2Rhbmh1YQ0K5oqE6YCBOiBob25ncWlhbmcubGl1QHlhbGUuZWR1OyB5cnlA Y3MueWFsZS5lZHUNCuS4u+mimDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC13 YW5nLWRlY2FkZS1kcnAtMDQudHh0DQoNCg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LXdh bmctZGVjYWRlLWRycC0wNC50eHQNCmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkg V2FuZyBEYW5odWEgYW5kIHBvc3RlZCB0byB0aGUNCklFVEYgcmVwb3NpdG9yeS4NCg0KRmlsZW5h bWU6CSBkcmFmdC13YW5nLWRlY2FkZS1kcnANClJldmlzaW9uOgkgMDQNClRpdGxlOgkJIEFuIEhU VFAtYmFzZWQgRGVjYWRlIFJlc291cmNlIFByb3RvY29sDQpDcmVhdGlvbiBkYXRlOgkgMjAxMi0w Ny0xNg0KV0cgSUQ6CQkgSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQpOdW1iZXIgb2YgcGFnZXM6IDIz DQpVUkw6ICAgICAgICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2Ry YWZ0LXdhbmctZGVjYWRlLWRycC0wNC50eHQNClN0YXR1czogICAgICAgICAgaHR0cDovL2RhdGF0 cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC13YW5nLWRlY2FkZS1kcnANCkh0bWxpemVkOiAgICAg ICAgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtd2FuZy1kZWNhZGUtZHJwLTA0DQpE aWZmOiAgICAgICAgICAgIGh0dHA6Ly90b29scy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQt d2FuZy1kZWNhZGUtZHJwLTA0DQoNCkFic3RyYWN0Og0KICAgVGhpcyBkb2N1bWVudCBleHBsb3Jl cnMgdGhlIGRlc2lnbiBvZiBhbiBIVFRQLWJhc2VkIERFQ0FERSBSZXNvdXJjZQ0KICAgUHJvdG9j b2wgKERSUCksIHdoaWNoIGNhbiBiZSB1c2VkIGZvciBjb250ZW50IGFuZCByZXNvdXJjZSBtYW5h Z2VtZW50DQogICBiZXR3ZWVuIGEgREVDQURFIENsaWVudCBhbmQgYSBERUNBREUgU2VydmVyLCBv ciBiZXR3ZWVuIHR3byBERUNBREUNCiAgIFNlcnZlcnMuICBXZSBpZGVudGlmeSB0aGUgZnVuY3Rp b24gZW50aXRpZXMsIGFuZCBwcmVzZW50IGluaXRpYWwNCiAgIHByb3RvY29sIG1lc3NhZ2UgZmxv dyBhbmQgc3ludGF4IGRlc2lnbi4gIFRoZSBwdXJwb3NlIG9mIHRoaXMNCiAgIGRvY3VtZW50IGlz IHRvIGdldCBkZXNpZ24gZGlzY3Vzc2lvbiBzdGFydGVkLCBub3QgdG8gcHJvdmlkZSBhDQogICBj b21wbGV0ZSBzb2x1dGlvbi4NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KDQoNClRoZSBJ RVRGIFNlY3JldGFyaWF0DQo= From haibin.song@huawei.com Wed Jul 18 19:07:02 2012 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 7F95021F86B9 for ; Wed, 18 Jul 2012 19:07:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.333 X-Spam-Level: X-Spam-Status: No, score=-6.333 tagged_above=-999 required=5 tests=[AWL=0.266, 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 zDGixneBSY50 for ; Wed, 18 Jul 2012 19:07:01 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 4573C21F86B7 for ; Wed, 18 Jul 2012 19:07:01 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AHW55955; Wed, 18 Jul 2012 22:07:53 -0400 (EDT) Received: from DFWEML403-HUB.china.huawei.com (10.193.5.151) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 18 Jul 2012 19:05:36 -0700 Received: from SZXEML436-HUB.china.huawei.com (10.72.61.64) by dfweml403-hub.china.huawei.com (10.193.5.151) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 18 Jul 2012 19:05:41 -0700 Received: from SZXEML534-MBX.china.huawei.com ([169.254.2.243]) by szxeml436-hub.china.huawei.com ([10.72.61.64]) with mapi id 14.01.0323.003; Thu, 19 Jul 2012 10:05:34 +0800 From: Songhaibin To: "decade@ietf.org" Thread-Topic: test Thread-Index: Ac1lUvlERja/r/XNSwWnxFkt0p5Duw== Date: Thu, 19 Jul 2012 02:05:34 +0000 Message-ID: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: Kp4= BVWh BtNo Bzrx FfiO FmgL HRgx H8+N IYNM JGpw JRZO J6H8 J8o3 Km7N K8tE LWgc; 1; ZABlAGMAYQBkAGUAQABpAGUAdABmAC4AbwByAGcA; Sosha1_v1; 7; {61F37C6C-3F50-46D2-A337-148707DD8F7C}; aABhAGkAYgBpAG4ALgBzAG8AbgBnAEAAaAB1AGEAdwBlAGkALgBjAG8AbQA=; Thu, 19 Jul 2012 02:05:30 GMT;dABlAHMAdAA= x-cr-puzzleid: {61F37C6C-3F50-46D2-A337-148707DD8F7C} x-originating-ip: [10.138.41.73] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [decade] test 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, 19 Jul 2012 02:07:02 -0000 Please ignore this email. -haibin From haibin.song@huawei.com Wed Jul 18 19:37:56 2012 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 D8DFE21F8680; Wed, 18 Jul 2012 19:37:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.353 X-Spam-Level: X-Spam-Status: No, score=-6.353 tagged_above=-999 required=5 tests=[AWL=0.246, 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 INLHuw4t4Spa; Wed, 18 Jul 2012 19:37:56 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 22C8A21F84EA; Wed, 18 Jul 2012 19:37:56 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AHW57758; Wed, 18 Jul 2012 22:38:48 -0400 (EDT) Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 18 Jul 2012 19:35:47 -0700 Received: from SZXEML408-HUB.china.huawei.com (10.82.67.95) by dfweml407-hub.china.huawei.com (10.193.5.132) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 18 Jul 2012 19:35:46 -0700 Received: from SZXEML534-MBX.china.huawei.com ([169.254.2.243]) by szxeml408-hub.china.huawei.com ([10.82.67.95]) with mapi id 14.01.0323.003; Thu, 19 Jul 2012 10:35:28 +0800 From: Songhaibin To: "arno@cs.vu.nl" , Peng Zhang Thread-Topic: [decade] [ppsp] Object naming in -req and -arch Thread-Index: AQHNYGz9SgP+UqsLmUq+tORnpn0WHZcmRtaAgAmX1jA= Date: Thu, 19 Jul 2012 02:35:29 +0000 Message-ID: References: <20120710162606039401143@chinamobile.com> <2039343B-5F6B-4777-864E-B4F00B5A258E@gmail.com> <4FFE6D67.80705@cs.vu.nl> <4FFFCA6D.7060306@cs.vu.nl> In-Reply-To: <4FFFCA6D.7060306@cs.vu.nl> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.73] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: ppsp , decade Subject: Re: [decade] [ppsp] Object naming in -req and -arch 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, 19 Jul 2012 02:37:57 -0000 I know little about Merkle Hash Tree. So I searched and learned some from t= he Internet. My feeling is MHT is useful for pre-stored objects. But it is = less useful for live contents. IMO, the co-relation of the objects besides = naming the object itself adds extra complexity in DECADE environment. Or is= there any good reason to use it? Just my 2 cents, -Haibin > -----Original Message----- > From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.org] On Behalf = Of > Arno Bakker > Sent: Friday, July 13, 2012 3:13 PM > To: Peng Zhang > Cc: ppsp; decade > Subject: Re: [decade] [ppsp] Object naming in -req and -arch >=20 > On 12/07/2012 22:28, Peng Zhang wrote: > > > > On Jul 12, 2012, at 2:23 AM, Arno Bakker wrote: > > > >> The gains of using MHT depend on the chunk size. For PPSP we prefer > >> chunks of 1K that fit in an UDP packet carried over Ethernet. In > >> that case, for a 4 GB file, there are 4 M chunks, resulting in 80 > >> MB of leaf hashes when SHA1 is used. Transferring that beforehand > >> as in BitTorrent definitely increases latency ;o) > > Yes, if the chunk size is only 1KB, and each chunk is verified > > individually, we cannot afford to send all hashes beforehand. While > > in the worst case without optimization, almost 2*80M =3D 160M hashes > > needs to be sent to the receiver, will that be a large overhead > > compared to 4G? Do we really need such a small chunk size? Maybe I > > miss some previous discussion on this. >=20 > Hi >=20 > For PPSP we want to use UDP as we don't need the in-order and > reliability features of TCP, and want flexibility to use differnet > congestion control algorithms and handle NATs. With Ethernet as the > dominant MAC layer at present and an unreliable transport we don't want > datagrams to exceed the Ethernet MTU, otherwise the chance of losing a > datagram increases (an UDP packet taking N IP packets will not be > delivered when only 1 IP packet is lost). Hence, we use chunks of ~1K. >=20 > A good practice in P2P networks is to not forward data you have not > verified. So to forward the 1K chunks directly we need to be able to > verify their integrity at this granularity, enter Merkle Hash Trees. > We think the resulting overhead due to the size of the tree is > acceptable, as it is easy to optimize the number of hashes transmitted > in our use cases. >=20 > CU, > Arno From haibin.song@huawei.com Thu Jul 19 18:14:02 2012 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 7F55911E80DC for ; Thu, 19 Jul 2012 18:14:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.362 X-Spam-Level: X-Spam-Status: No, score=-6.362 tagged_above=-999 required=5 tests=[AWL=0.237, 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 Dva2xYVTbfd6 for ; Thu, 19 Jul 2012 18:14:02 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id DF17511E80CA for ; Thu, 19 Jul 2012 18:14:01 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AHX36008; Thu, 19 Jul 2012 21:14:56 -0400 (EDT) Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 19 Jul 2012 18:13:07 -0700 Received: from SZXEML404-HUB.china.huawei.com (10.82.67.59) by dfweml407-hub.china.huawei.com (10.193.5.132) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 19 Jul 2012 18:13:05 -0700 Received: from SZXEML534-MBX.china.huawei.com ([169.254.2.243]) by szxeml404-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.003; Fri, 20 Jul 2012 09:13:00 +0800 From: Songhaibin To: decade Thread-Topic: test Thread-Index: Ac1mFMyVMZ814VlAR2alou0NvBhedA== Date: Fri, 20 Jul 2012 01:12:59 +0000 Message-ID: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: BEFD CWW9 DQXG EPpb FazP GEHV HTpi HbPH ILTm I+Cf JLdD Jlpj KBG+ KRWn Kmd0 KoJs; 1; ZABlAGMAYQBkAGUAQABpAGUAdABmAC4AbwByAGcA; Sosha1_v1; 7; {4B93E8A3-6645-40E2-BD18-FD98580FF26A}; aABhAGkAYgBpAG4ALgBzAG8AbgBnAEAAaAB1AGEAdwBlAGkALgBjAG8AbQA=; Fri, 20 Jul 2012 01:12:58 GMT;dABlAHMAdAA= x-cr-puzzleid: {4B93E8A3-6645-40E2-BD18-FD98580FF26A} x-originating-ip: [10.138.41.73] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [decade] test 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, 20 Jul 2012 01:14:02 -0000 Just a test, please ignore. From haibin.song@huawei.com Thu Jul 26 18:16:26 2012 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 4B08521F84F2 for ; Thu, 26 Jul 2012 18:16:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.379 X-Spam-Level: X-Spam-Status: No, score=-6.379 tagged_above=-999 required=5 tests=[AWL=0.220, 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 QzNL5YOi0Zc3 for ; Thu, 26 Jul 2012 18:16:25 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id CD4BA21F84E2 for ; Thu, 26 Jul 2012 18:16:25 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AIC61283; Thu, 26 Jul 2012 21:16:25 -0400 (EDT) Received: from DFWEML403-HUB.china.huawei.com (10.193.5.151) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 26 Jul 2012 18:14:46 -0700 Received: from SZXEML403-HUB.china.huawei.com (10.82.67.35) by dfweml403-hub.china.huawei.com (10.193.5.151) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 26 Jul 2012 18:14:52 -0700 Received: from SZXEML534-MBX.china.huawei.com ([169.254.2.243]) by szxeml403-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.003; Fri, 27 Jul 2012 09:14:49 +0800 From: Songhaibin To: decade Thread-Topic: Side meeting on DECADE Thread-Index: Ac1rlTbOgS9TkZ1lRXWfUJ3mupn7BA== Date: Fri, 27 Jul 2012 01:14:48 +0000 Message-ID: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.73] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "martin.stiemerling@neclab.eu" Subject: [decade] Side meeting on DECADE 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, 27 Jul 2012 01:16:26 -0000 Dear guys, We will have an informal side meeting during this IETF in Vancouver. The ti= me is Wednesday. We will get together after the Morning Session I at the re= gistration desk, and then head for lunch. Anyone interested in the discussi= on is welcome to join us. BR, -Haibin From Martin.Stiemerling@neclab.eu Fri Jul 27 02:08:52 2012 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 33CFF21F8615 for ; Fri, 27 Jul 2012 02:08:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.517 X-Spam-Level: X-Spam-Status: No, score=-102.517 tagged_above=-999 required=5 tests=[AWL=0.082, 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 iWKVmqXnSn+a for ; Fri, 27 Jul 2012 02:08:51 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 905BB21F8613 for ; Fri, 27 Jul 2012 02:08:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 549D11018A9; Fri, 27 Jul 2012 11:13:28 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D8U+7uossWeG; Fri, 27 Jul 2012 11:13:28 +0200 (CEST) Received: from METHONE.office.hd (methone.office.hd [192.168.24.54]) by mailer1.neclab.eu (Postfix) with ESMTP id 3541B1018A1; Fri, 27 Jul 2012 11:13:13 +0200 (CEST) Received: from PALLENE.office.hd ([169.254.1.252]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0323.003; Fri, 27 Jul 2012 11:08:35 +0200 From: Martin Stiemerling To: Songhaibin Thread-Topic: Side meeting on DECADE Thread-Index: Ac1rlTbOgS9TkZ1lRXWfUJ3mupn7BAAQi/NW Date: Fri, 27 Jul 2012 09:08:41 +0000 Message-ID: <95EFFBAE-6742-4D1A-9C2B-23AFD882D104@office.hd> References: In-Reply-To: Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: decade , Martin Stiemerling Subject: Re: [decade] Side meeting on DECADE 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, 27 Jul 2012 09:08:52 -0000 I won't make it, as this is the slot of Ppsp. Martin On 27.07.2012, at 03:16, "Songhaibin" wrote: > Dear guys, >=20 > We will have an informal side meeting during this IETF in Vancouver. The = time is Wednesday. We will get together after the Morning Session I at the = registration desk, and then head for lunch. Anyone interested in the discus= sion is welcome to join us. >=20 > BR, > -Haibin From haibin.song@huawei.com Fri Jul 27 03:19:22 2012 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 D69DF21F864F for ; Fri, 27 Jul 2012 03:19:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.386 X-Spam-Level: X-Spam-Status: No, score=-6.386 tagged_above=-999 required=5 tests=[AWL=0.213, 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 Ay3yjZHqPPLz for ; Fri, 27 Jul 2012 03:19:22 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 4FCEF21F8645 for ; Fri, 27 Jul 2012 03:19:22 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AIC93343; Fri, 27 Jul 2012 06:19:22 -0400 (EDT) Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 27 Jul 2012 03:17:16 -0700 Received: from SZXEML429-HUB.china.huawei.com (10.72.61.37) by dfweml405-hub.china.huawei.com (10.193.5.102) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 27 Jul 2012 03:17:23 -0700 Received: from SZXEML534-MBX.china.huawei.com ([169.254.2.243]) by SZXEML429-HUB.china.huawei.com ([10.72.61.37]) with mapi id 14.01.0323.003; Fri, 27 Jul 2012 18:17:15 +0800 From: Songhaibin To: Martin Stiemerling Thread-Topic: Side meeting on DECADE Thread-Index: Ac1rlTbOgS9TkZ1lRXWfUJ3mupn7BAAQi/NWAAJVgYA= Date: Fri, 27 Jul 2012 10:17:15 +0000 Message-ID: References: <95EFFBAE-6742-4D1A-9C2B-23AFD882D104@office.hd> In-Reply-To: <95EFFBAE-6742-4D1A-9C2B-23AFD882D104@office.hd> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.73] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: decade Subject: Re: [decade] Side meeting on DECADE 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, 27 Jul 2012 10:19:22 -0000 Dear Martin, I mean the lunch slot after Morning Session I, i.e. after PPSP session. Hop= e you are available then. -Haibin > -----Original Message----- > From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.org] On Behalf = Of > Martin Stiemerling > Sent: Friday, July 27, 2012 5:09 PM > To: Songhaibin > Cc: decade; Martin Stiemerling > Subject: Re: [decade] Side meeting on DECADE >=20 > I won't make it, as this is the slot of Ppsp. >=20 > Martin >=20 >=20 >=20 > On 27.07.2012, at 03:16, "Songhaibin" wrote: >=20 > > Dear guys, > > > > We will have an informal side meeting during this IETF in Vancouver. Th= e time is > Wednesday. We will get together after the Morning Session I at the regist= ration > desk, and then head for lunch. Anyone interested in the discussion is wel= come to > join us. > > > > BR, > > -Haibin From Martin.Stiemerling@neclab.eu Fri Jul 27 03:26:24 2012 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 432E821F8631 for ; Fri, 27 Jul 2012 03:26:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.518 X-Spam-Level: X-Spam-Status: No, score=-102.518 tagged_above=-999 required=5 tests=[AWL=0.081, 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 bRT4XKCxFAXL for ; Fri, 27 Jul 2012 03:26:23 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id AA54F21F862F for ; Fri, 27 Jul 2012 03:26:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 6817310196C; Fri, 27 Jul 2012 12:31:01 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dRRD1XM1Kfwr; Fri, 27 Jul 2012 12:31:01 +0200 (CEST) Received: from ENCELADUS.office.hd (enceladus.office.hd [192.168.24.52]) by mailer1.neclab.eu (Postfix) with ESMTP id 4FE6E101977; Fri, 27 Jul 2012 12:30:51 +0200 (CEST) Received: from PALLENE.office.hd ([169.254.1.252]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0323.003; Fri, 27 Jul 2012 12:25:59 +0200 From: Martin Stiemerling To: Songhaibin Thread-Topic: Side meeting on DECADE Thread-Index: Ac1rlTbOgS9TkZ1lRXWfUJ3mupn7BAAQi/NWAAJVgYAAAF1THw== Date: Fri, 27 Jul 2012 10:25:58 +0000 Message-ID: References: <95EFFBAE-6742-4D1A-9C2B-23AFD882D104@office.hd>, In-Reply-To: Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: decade Subject: Re: [decade] Side meeting on DECADE 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, 27 Jul 2012 10:26:24 -0000 Ah - yes I will make it. Thanks, Martin On 27.07.2012, at 12:19, "Songhaibin" wrote: > Dear Martin, >=20 > I mean the lunch slot after Morning Session I, i.e. after PPSP session. H= ope you are available then. >=20 > -Haibin >=20 >> -----Original Message----- >> From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.org] On Behalf= Of >> Martin Stiemerling >> Sent: Friday, July 27, 2012 5:09 PM >> To: Songhaibin >> Cc: decade; Martin Stiemerling >> Subject: Re: [decade] Side meeting on DECADE >>=20 >> I won't make it, as this is the slot of Ppsp. >>=20 >> Martin >>=20 >>=20 >>=20 >> On 27.07.2012, at 03:16, "Songhaibin" wrote: >>=20 >>> Dear guys, >>>=20 >>> We will have an informal side meeting during this IETF in Vancouver. Th= e time is >> Wednesday. We will get together after the Morning Session I at the regis= tration >> desk, and then head for lunch. Anyone interested in the discussion is we= lcome to >> join us. >>>=20 >>> BR, >>> -Haibin