On Tue, Nov 15, 2011 at 10:30 PM, Dirk K= utscher <Di= rk.Kutscher@neclab.eu> wrote:

Hi Harry,

Thank you very much for your comments.

> =A0 =A0 =A0 -- Grouping. We have discussed about the objects grouping = in
> DECADE-Arch design. A group might be only a property. I think this pro= perty
> is one of the query item with "?", e.g. group?movie-1. But I= do not think it is
> clean because the group here is not a query.

Yes, my general thinking is that grouping needs some discussion, i.e.= , to what degree DECADE needs a grouping concept.

I can imagine that *applications* would benefit from grouping, but we need = to decide whether this needs to reflected on the protocol / naming level.
For example, if you want to group objects (say chunks) into an application = context you could employ index files (think torrent files) and reference th= e individual chunks by names -- but the names would not need to expose any = grouping information.

I could imagine that it may be interesting to have the publisher / user inf= ormation exposed in DECADE names -- the NI scheme has an optional authority= element for this:

ni://example.com/sha-256;B_K97zTtFuOhug27fke4_Zgc= 4Myz4b_lZNgsQjy6fkc

There are really tw= o separate sets of technical requirements. The first being when we are deal= ing with static data and the second when the data is dynamic and the link i= s to a concept rather than a specific sequence of bytes.

Lets leave the second set of requirements on the stack = for the time being. At the end of the road every request has to be satisfie= d by either an error response or some sequence of bytes...

In the first case we can adopt a layered approach= . The outer digest links to a file that contains a sequence of digests for = the inner digests or to the root element in a Merkle tree or similar scheme= .=A0

In this case the only thing that is different is that t= he content type is now 'list of digests'.

Another cute trick that has been proposed in the past that w= e could use if someone can be bothered to go through the IP search is that = the chain of digests can be embedded in the content in such a way that the = verifier can check the data before reading the whole stream.

For example.

Digest0 =3D H ( B= lock 0 + Digest1)

Digest1 =3D H (Block 1 + Digest2 )

..=

Digestn =3D H (Block n)

Stream =3D =A0D= igest0 +=A0Block0 +=A0Digest1=A0+ Block1 + ... + Digestn + .. + Blockn

This digest can only be calculated by reading in the wh= ole stream because Digest0 depends on every byte that follows. But Digest 0= can be verified by reading only up to Digest1.=A0

Alternatively, this type of option could be considered = to be an encoding variation or even a signature option.

--=A0

Website: http= ://hallambaker.com/

--f46d044470d3a22df304b1d24be9-- From lampson0505@gmail.com Wed Nov 16 22:58:45 2011 Return-Path: X-Original-To: decade@ietfa.amsl.com Delivered-To: decade@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E5CB1F0C6E for ; Wed, 16 Nov 2011 22:58:45 -0800 (PST) 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 3919gGKrfjMY for ; Wed, 16 Nov 2011 22:58:44 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4ACD11F0C69 for ; Wed, 16 Nov 2011 22:58:44 -0800 (PST) Received: by iaeo4 with SMTP id o4so2067636iae.31 for ; Wed, 16 Nov 2011 22:58:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=references:in-reply-to:mime-version:content-type:message-id :content-transfer-encoding:cc:from:subject:date:to:x-mailer; bh=6WCA5UglTCCZw3IaO60N/5bYOR6xq26in5B01SVgL8M=; b=vgBGtSysVB897GfvIBFJIY+tU6AxFq2AvWYlkYXZf72CxQQtWFRe0xaX0md2CPnZWx DWltdb1XSE2E77Xkj4IpkTbA1RnIWtekzvpU0PpnSlkFMzhEX0SvTwDE3a2FZ045nGZl 2yrTCNdDmxNavjze9dg4qmWHJDSXXX8w992+g= Received: by 10.42.41.143 with SMTP id p15mr39418428ice.9.1321513122680; Wed, 16 Nov 2011 22:58:42 -0800 (PST) Received: from dhcp-128-36-159-249.central.yale.edu (dhcp-128-36-159-249.central.yale.edu. [128.36.159.249]) by mx.google.com with ESMTPS id dd36sm54268239ibb.7.2011.11.16.22.58.39 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 16 Nov 2011 22:58:42 -0800 (PST) References: <82AB329A76E2484D934BBCA77E9F524924B74297@PALLENE.office.hd> <82AB329A76E2484D934BBCA77E9F524924B940AB@Polydeuces.office.hd> In-Reply-To: <82AB329A76E2484D934BBCA77E9F524924B940AB@Polydeuces.office.hd> Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii Message-Id: Content-Transfer-Encoding: quoted-printable From: Harry Date: Thu, 17 Nov 2011 01:58:35 -0500 To: Dirk Kutscher X-Mailer: Apple Mail (2.1084) Cc: decade ietf , "Christian Dannewitz \(cdannewitz@uni-paderborn.de\)" , "Rob Stradling \(rob.stradling@comodo.com\)" , "philliph@comodo.com" Subject: Re: [decade] URIs for DECADE -- Named Information URI Scheme 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, 17 Nov 2011 06:58:45 -0000 Hi Dirk Thank you for your replies. Please see my comments inline. On Nov 15, 2011, at 10:30 PM, Dirk Kutscher wrote: > Hi Harry, >=20 > Thank you very much for your comments. >=20 >> -- Grouping. We have discussed about the objects grouping in >> DECADE-Arch design. A group might be only a property. I think this = property >> is one of the query item with "?", e.g. group?movie-1. But I do not = think it is >> clean because the group here is not a query. >=20 > Yes, my general thinking is that grouping needs some discussion, i.e., = to what degree DECADE needs a grouping concept. >=20 > I can imagine that *applications* would benefit from grouping, but we = need to decide whether this needs to reflected on the protocol / naming = level. >=20 > For example, if you want to group objects (say chunks) into an = application context you could employ index files (think torrent files) = and reference the individual chunks by names -- but the names would not = need to expose any grouping information.=20 It is a good idea but I am thinking about how to maintain the meta = files. These indexing files can also be very large and updated = frequently.=20 >=20 > I could imagine that it may be interesting to have the publisher / = user information exposed in DECADE names -- the NI scheme has an = optional authority element for this: >=20 > ni://example.com/sha-256;B_K97zTtFuOhug27fke4_Zgc4Myz4b_lZNgsQjy6fkc >=20 >=20 >> -- Batching. It is not clear that how to perform batch request = with this >> scheme. If a request has multiple objects, we might need to specify = their >> authority, algorithm and other properties together or separately. I = think >> batch requests might be important for delay sensitive applications = such as >> live streaming. >=20 > Interesting point. >=20 > In general, I'd say that being able to do batch requests rather = depends on the protocol. I am not sure about the additional costs that = would be incurred by having to specify authority, algorithm etc. >=20 > If we are working on the basis that each object is individually named, = then you have to specify the name. >=20 > For the protocol, I think we ought to look into this. For example, for = an HTTP-based DECADE protocol, we might want to make HTTP Pipelining = mandatory. I remember that Apple is using play lists. Shall we do a similar thing? >=20 > Thanks again, >=20 > Dirk >=20 >=20 >=20 >=20 >=20 >>=20 >> Thank you very much >>=20 >> Harry Liu >>=20 >>=20 >> On Oct 26, 2011, at 9:06 AM, Dirk Kutscher wrote: >>=20 >>> Dear all, >>>=20 >>> We have updated the Named Information URI scheme that we presented >> at IETF-81. >>>=20 >>> It turned out that the WEBSEC folks (Phillip Hallam-Baker and = colleagues) >> had started a parallel effort on a very similar approach, and -- = fortunately -- >> we have been able to combine our efforts and have advanced the spec = so >> that it would be useful for DECADE, WEBSEC and potentially other >> applications. >>>=20 >>> We still think that DECADE could benefit most at this time, so we = submitted >> this (as an individual submission) to DECADE now. >>>=20 >>> We found a, IMO, nice way to have a concise base specification = without >> excluding extensions for future application requirements. Basically, = there is >> an extension mechanism that allows applications to specify additional >> parameters. >>>=20 >>> To make this manageable, we have split the specification into two = pieces: >>>=20 >>> The base spec: >>>=20 >>> http://tools.ietf.org/html/draft-farrell-decade-ni-00 >>>=20 >>> This document defines a URI-based name form that identifies a named >>> object via hash-based binding. The URI name form defined is = intended >>> for use in applications that need to uniquely identify resources in = a >>> location-independent way such as accessing in-network storage >>> (DECADE), information-centric networking and more generally. The >>> format is designed to support a strong link to the referenced object >>> such that the referenced object may be authenticated to the same >>> degree as the reference to it. >>>=20 >>> The base spec has a set of useful general features (in addition to = the actual >> syntax definition), such as processing rules (testing for equality), = and an >> algorithm that can be used to map NI URIs to HTTP(S) automatically -- = which I >> believe could be useful for DECADE, too. The base spec also defines = the >> fundamentals of the extension mechanism. >>>=20 >>>=20 >>> A spec that defines a set of extension parameters and their = semantics: >>>=20 >>> http://tools.ietf.org/html/draft-hallambaker-decade-ni-params-00 >>> This document specifies some optional algorithms and parameters that >>> may be used in the query string of ni URIs. >>>=20 >>> One of the parameters that we have introduced here would allow you = to >> specify additional locators for resources -- again, that is expected = to be useful >> for DECADE. >>>=20 >>> Looking forward, we envision that DECADE protocols may need = additional >> parameters. Investigating this and specifying the parameters could be = done >> in DECADE (should we decide to re-charter for that). >>>=20 >>> Please note that these two are individual submissions only -- i.e., = merely >> proposals that the group of authors are offering at this point. >>>=20 >>> Nevertheless, we would be happy for any feedback. >>>=20 >>> Best regards, >>>=20 >>> Dirk >>>=20 >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> decade mailing list >>> decade@ietf.org >>> https://www.ietf.org/mailman/listinfo/decade >=20 From lampson0505@gmail.com Wed Nov 16 23:22:34 2011 Return-Path: X-Original-To: decade@ietfa.amsl.com Delivered-To: decade@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC5401F0CD2 for ; Wed, 16 Nov 2011 23:22:34 -0800 (PST) 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 vIqDRwPy4T7Z for ; Wed, 16 Nov 2011 23:22:33 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id A59831F0CBE for ; Wed, 16 Nov 2011 23:22:33 -0800 (PST) Received: by iaeo4 with SMTP id o4so2094164iae.31 for ; Wed, 16 Nov 2011 23:22:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=references:in-reply-to:mime-version:content-type:message-id:cc:from :subject:date:to:x-mailer; bh=vze/zAtUY1kK5rs2s8kghazOWmD3kRmvqUyac9cOXSc=; b=qD8GYwD4oAtIE/7LiyGYv0m+PYQgrBtjqokCZrvJNvYBRor9x4WW1L189tz2zzKHLc 8fu3yjMOGE1gp6FTRFxgvXb9+v0axyqYnw5IyuU70VX33VmOrxwtv14m2WMEarh+lCPe AhjVDWSOv6G28ZllW7lbKgm7vY0k/XG9I+M5k= Received: by 10.42.136.196 with SMTP id v4mr39366546ict.3.1321514553050; Wed, 16 Nov 2011 23:22:33 -0800 (PST) Received: from dhcp-128-36-159-249.central.yale.edu (dhcp-128-36-159-249.central.yale.edu. [128.36.159.249]) by mx.google.com with ESMTPS id n30sm54513459ibl.4.2011.11.16.23.22.30 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 16 Nov 2011 23:22:32 -0800 (PST) References: <82AB329A76E2484D934BBCA77E9F524924B74297@PALLENE.office.hd> <82AB329A76E2484D934BBCA77E9F524924B940AB@Polydeuces.office.hd> In-Reply-To: Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-1--390037000 Message-Id: <4ADCDD40-1308-4621-B2DB-75F4124D0684@gmail.com> From: Harry Date: Thu, 17 Nov 2011 02:22:26 -0500 To: Phillip Hallam-Baker X-Mailer: Apple Mail (2.1084) Cc: "philliph@comodo.com" , decade ietf , "Christian Dannewitz \(cdannewitz@uni-paderborn.de\)" , "Rob Stradling \(rob.stradling@comodo.com\)" Subject: Re: [decade] URIs for DECADE -- Named Information URI Scheme 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, 17 Nov 2011 07:22:35 -0000 --Apple-Mail-1--390037000 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Nov 15, 2011, at 11:11 PM, Phillip Hallam-Baker wrote: >=20 >=20 > On Tue, Nov 15, 2011 at 10:30 PM, Dirk Kutscher = wrote: > Hi Harry, >=20 > Thank you very much for your comments. >=20 > > -- Grouping. We have discussed about the objects grouping in > > DECADE-Arch design. A group might be only a property. I think this = property > > is one of the query item with "?", e.g. group?movie-1. But I do not = think it is > > clean because the group here is not a query. >=20 > Yes, my general thinking is that grouping needs some discussion, i.e., = to what degree DECADE needs a grouping concept. >=20 > I can imagine that *applications* would benefit from grouping, but we = need to decide whether this needs to reflected on the protocol / naming = level. >=20 > For example, if you want to group objects (say chunks) into an = application context you could employ index files (think torrent files) = and reference the individual chunks by names -- but the names would not = need to expose any grouping information. >=20 > I could imagine that it may be interesting to have the publisher / = user information exposed in DECADE names -- the NI scheme has an = optional authority element for this: >=20 > ni://example.com/sha-256;B_K97zTtFuOhug27fke4_Zgc4Myz4b_lZNgsQjy6fkc >=20 > There are really two separate sets of technical requirements. The = first being when we are dealing with static data and the second when the = data is dynamic and the link is to a concept rather than a specific = sequence of bytes. >=20 > Lets leave the second set of requirements on the stack for the time = being. At the end of the road every request has to be satisfied by = either an error response or some sequence of bytes... >=20 >=20 > In the first case we can adopt a layered approach. The outer digest = links to a file that contains a sequence of digests for the inner = digests or to the root element in a Merkle tree or similar scheme.=20 >=20 > In this case the only thing that is different is that the content type = is now 'list of digests'. >=20 >=20 > Another cute trick that has been proposed in the past that we could = use if someone can be bothered to go through the IP search is that the = chain of digests can be embedded in the content in such a way that the = verifier can check the data before reading the whole stream. >=20 > For example. >=20 > Digest0 =3D H ( Block 0 + Digest1) > Digest1 =3D H (Block 1 + Digest2 ) > .. > Digestn =3D H (Block n) >=20 > Stream =3D Digest0 + Block0 + Digest1 + Block1 + ... + Digestn + .. + = Blockn >=20 > This digest can only be calculated by reading in the whole stream = because Digest0 depends on every byte that follows. But Digest 0 can be = verified by reading only up to Digest1.=20 >=20 This is a good solution for streaming. But I think grouping is still = needed for object aggregation (for purpose such as content routing). >=20 > Alternatively, this type of option could be considered to be an = encoding variation or even a signature option. >=20 >=20 > --=20 > Website: http://hallambaker.com/ >=20 --Apple-Mail-1--390037000 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii

On Nov 15, 2011, at 11:11 PM, Phillip Hallam-Baker wrote:

On Tue, Nov 15, 2011 at 10:30 PM, Dirk Kutscher <Dirk.Kutscher@neclab.eu> wrote:
Hi Harry,

Thank you very much for your comments.

> -- Grouping. We have discussed about the objects grouping in
> DECADE-Arch design. A group might be only a property. I think this property
> is one of the query item with "?", e.g. group?movie-1. But I do not think it is
> clean because the group here is not a query.

Yes, my general thinking is that grouping needs some discussion, i.e., to what degree DECADE needs a grouping concept.

I can imagine that *applications* would benefit from grouping, but we need to decide whether this needs to reflected on the protocol / naming level.

For example, if you want to group objects (say chunks) into an application context you could employ index files (think torrent files) and reference the individual chunks by names -- but the names would not need to expose any grouping information.

I could imagine that it may be interesting to have the publisher / user information exposed in DECADE names -- the NI scheme has an optional authority element for this:

ni://example.com/sha-256;B_K97zTtFuOhug27fke4_Zgc4Myz4b_lZNgsQjy6fkc

There are really two separate sets of technical requirements. The first being when we are dealing with static data and the second when the data is dynamic and the link is to a concept rather than a specific sequence of bytes.

Lets leave the second set of requirements on the stack for the time being. At the end of the road every request has to be satisfied by either an error response or some sequence of bytes...

In the first case we can adopt a layered approach. The outer digest links to a file that contains a sequence of digests for the inner digests or to the root element in a Merkle tree or similar scheme.

In this case the only thing that is different is that the content type is now 'list of digests'.

Another cute trick that has been proposed in the past that we could use if someone can be bothered to go through the IP search is that the chain of digests can be embedded in the content in such a way that the verifier can check the data before reading the whole stream.

For example.

Digest0 = H ( Block 0 + Digest1)
Digest1 = H (Block 1 + Digest2 )
..
Digestn = H (Block n)

Stream = Digest0 + Block0 + Digest1 + Block1 + ... + Digestn + .. + Blockn

This digest can only be calculated by reading in the whole stream because Digest0 depends on every byte that follows. But Digest 0 can be verified by reading only up to Digest1.

This is a good solution for streaming. But I think grouping is still needed for object aggregation (for purpose such as content routing).

Alternatively, this type of option could be considered to be an encoding variation or even a signature option.

--
Website: http://hallambaker.com/

--Apple-Mail-1--390037000-- From Akbar.Rahman@InterDigital.com Mon Nov 28 23:16:44 2011 Return-Path: X-Original-To: decade@ietfa.amsl.com Delivered-To: decade@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86FC121F8BB5 for ; Mon, 28 Nov 2011 23:16:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_46=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 NyHNMHb4aYXv for ; Mon, 28 Nov 2011 23:16:42 -0800 (PST) Received: from idcout.InterDigital.com (idcexmail.interdigital.com [12.32.197.135]) by ietfa.amsl.com (Postfix) with ESMTP id CC9DF11E8082 for ; Mon, 28 Nov 2011 23:16:41 -0800 (PST) Received: from SAM.InterDigital.com ([10.30.2.12]) by idcout.InterDigital.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 29 Nov 2011 02:16:40 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CCAE66.D738B578" Date: Tue, 29 Nov 2011 02:16:30 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-topic: WG review of draft-ietf-decade-integration-example-02 Thread-index: AcyuZtEyTmdUAfuhRiaQ6hx2V/nY9Q== From: "Rahman, Akbar" To: X-OriginalArrivalTime: 29 Nov 2011 07:16:40.0732 (UTC) FILETIME=[D7342DC0:01CCAE66] Subject: [decade] WG review of draft-ietf-decade-integration-example-02 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, 29 Nov 2011 07:16:44 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CCAE66.D738B578 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, =20 =20 As per the request of the DECADE chairs in IETF 82, I did a review of = the "Integration Examples of DECADE System" = (draft-ietf-decade-integration-example-02) and have the following = comments: =20 =B7 Overall, I found the document very useful in providing = excellent insights into how DECADE could be used in a real network. = Also, I took it as a good example of "running code" for DECADE. Thanks = for the good work! =20 =B7 I think the document could generally be improved if the = following information were added (or expanded): =20 o Some more details of the actual protocols used in the different = integration scenarios should be given. For example, what were the = underlying protocols for the "P2P LiveStreaming Client (P2PLS)"? As an = example, HTTP/TCP are the protocols used for web browsing. What were = the protocols for P2PLS? Also some details for the protocols should be = given even for the "BitTorrent" example. As not all readers will have = knowledge of how BitTorrent works. =20 o Some more details of the file/object naming scheme used in the = different integration scenarios should be given. This is a critical = part of DECADE and the approached used in the experiments for naming = must be given for a complete understanding of what was done. =20 o In the Intro (and elsewhere) there needs to be some clear references = to DECADE WG documents such as the Problem Statement, Requirements or = Architecture (and the associated concepts defined in those documents). = Note that there can be deviations from the concepts defined in the = DECADE WG documents, but these need to be clearly explained. =20 =20 =B7 Some detailed comments on specific sections: o The Abstract is a bit detailed and it is hard to understand. For = example there should not be a list (points 1-6) in an abstract. =20 o In section 2.9 (Remote Controller), I did not understand what "a = major operating platform" meant? =20 o I did not understand the "limited connection slot" issue (sec. = 4.2.1). My understanding is that a DECADE client will have an = association with a given DECADE server, and not every other possible = server. Is this the assumption that was used in the integration? =20 o Editorial: The word DECADE is spelled incorrectly in Figure 2 and 3. =20 o I did not understand the relation between a DECADE client and server = in the ALTO + DECADE integration (section 6)? Does ALTO get invoked for = both PUT and GET from a DECADE client? Or is it only for a GET? =A7 Similarly, I did not understand the Performance Analysis of the = ALTO+DECADE Performance Analysis (section 8.2.3). =20 o Should better define what a "small instance" is in the Amazon EC2 = framework (section 7.2.1) =20 o A short Conclusion section should be added to the document briefly = summarizing the lessons learned and some suggestions for the DECADE = design. As right now the conclusions are spread over several sections. =20 o The Security section (sec. 9) should not be empty as there must have = been some security related assumptions in the integration. For example, = was any DECADE client able to read from any DECADE server without = authentication? Yes or No? Either way this should be described. (In = section 5.3, for example, there was a reference to an "authorization = token"). =20 =20 That's all. =20 =20 Akbar ------_=_NextPart_001_01CCAE66.D738B578 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi,

As per the = request of the DECADE chairs in IETF 82, I did a review of the = “Integration Examples of DECADE System” = (draft-ietf-decade-integration-example-02) and have the following = comments:

=B7 = Overall, I found the document very useful = in providing excellent insights into how DECADE could be used in a real = network.=A0 Also, I took it as a good example of “running = code” for DECADE.=A0 Thanks for the good work!

=B7 = I think the document could generally be = improved if the following information were added (or = expanded):

o Some more = details of the actual protocols used in the different integration = scenarios should be given.=A0 For example, what were the underlying = protocols for the “P2P LiveStreaming Client (P2PLS)”? = =A0=A0As an example, HTTP/TCP are the protocols used for web = browsing.=A0 What were the protocols for P2PLS?=A0 Also some details for = the protocols should be given even for the “BitTorrent” = example.=A0 As not all readers will have knowledge of how BitTorrent = works.

o Some more = details of the file/object naming scheme used in the different = integration scenarios should be given.=A0 This is a critical part of = DECADE and the approached used in the experiments for naming must be = given for a complete understanding of what was done.

o In the Intro = (and elsewhere) there needs to be some clear references to DECADE WG = documents such as the Problem Statement, Requirements or Architecture = (and the associated concepts defined in those documents).=A0 Note that = there can be deviations from the concepts defined in the DECADE WG = documents, but these need to be clearly explained.

=B7 = Some detailed comments on specific = sections:

o The Abstract is = a bit detailed and it is hard to understand.=A0 For example there should = not be a list (points 1-6) in an abstract.

o In section 2.9 = (Remote Controller), I did not understand what “a major operating = platform” meant?

o I did not = understand the “limited connection slot” issue (sec. = 4.2.1).=A0 My understanding is that a DECADE client will have an = association with a given DECADE server, and not every other possible = server.=A0 Is this the assumption that was used in the = integration?

o Editorial: The = word DECADE is spelled incorrectly in Figure 2 and 3.

o I did not = understand the relation between a DECADE client and server in the ALTO + = DECADE integration (section 6)?=A0 Does ALTO get invoked for both PUT = and GET from a DECADE client?=A0 Or is it only for a = GET?

=A7 Similarly, I did not = understand the Performance Analysis of the ALTO+DECADE Performance = Analysis (section 8.2.3).

o Should better = define what a “small instance” is in the Amazon EC2 = framework (section 7.2.1)

o A short = Conclusion section should be added to the document briefly summarizing = the lessons learned and some suggestions for the DECADE design.=A0 As = right now the conclusions are spread over several = sections.

o The Security = section (sec. 9) should not be empty as there must have been some = security related assumptions in the integration.=A0 For example, was any = DECADE client able to read from any DECADE server without = authentication?=A0 Yes or No?=A0 Either way this should be described.=A0 = (In section 5.3, for example, there was a reference to an = “authorization token”).

That’s = all.

Akbar

------_=_NextPart_001_01CCAE66.D738B578--