From richard.alimi@gmail.com Mon Jan 3 12:04:02 2011 Return-Path: X-Original-To: decade@core3.amsl.com Delivered-To: decade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 04F543A6B5C for ; Mon, 3 Jan 2011 12:04:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.327 X-Spam-Level: X-Spam-Status: No, score=-2.327 tagged_above=-999 required=5 tests=[AWL=-0.650, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bCmXfGoyZE2D for ; Mon, 3 Jan 2011 12:04:00 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id 680E63A6B5A for ; Mon, 3 Jan 2011 12:04:00 -0800 (PST) Received: by iyi42 with SMTP id 42so13503196iyi.31 for ; Mon, 03 Jan 2011 12:06:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=nH51c5Rdsz8yrxtfM5s9IefVpREQKuYyPU++OxePd0M=; b=lsEhUJCzIeafoWGa5K5/XG/1SOO4gcU7DUAkwL8uB5AjoEy2O7scbBqxNs3syMeeXM 4XLhxDEscYG2/YS3Rf/CILEXjOXrEGqoyt6Hzh9/I1nGwAkTFhXB/1BxLAr9sLUuurlw UWTBqQR0fVvEosY6CMVvTLkgKM7sh6JnjP6II= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=VPn86BlBUyhbFUxlWyB+1EwVsFfXpGpEDZpETuX7oEaMJD6KSBg5YSj9Xg01y/XDGV kPqdTn/vcLWHYh3hnlOiHTVuNKzStMpJ3ZoIaNlL+brUixEAogREw8loZL3vK4g6TVyW ZTPBxv1zUwtoY33GEYcZePrRp8591peuizXeM= MIME-Version: 1.0 Received: by 10.231.13.133 with SMTP id c5mr12007875iba.39.1294085166861; Mon, 03 Jan 2011 12:06:06 -0800 (PST) Sender: richard.alimi@gmail.com Received: by 10.231.31.8 with HTTP; Mon, 3 Jan 2011 12:06:06 -0800 (PST) In-Reply-To: References: Date: Mon, 3 Jan 2011 12:06:06 -0800 X-Google-Sender-Auth: vJ-s57_DlVMdXiENeQpNPrPYPCc Message-ID: From: Richard Alimi To: =?UTF-8?B?5pyx5r2H?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: decade@ietf.org Subject: Re: [decade] draft-zhu-decade-additional-requirements X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jan 2011 20:04:02 -0000 Hi Xiao, Thank you for the draft. Some comments on the requirements: Request Redirects: This would provide some additional freedom for the storage provider. I think it is reasonable since it doesn't necessitate additional complexity for the DECADE server, but allows it if desired. However, note that it may complicate some of the other components of the design. In particular, if there is a per-user quota for storage, is the user made aware of the quota at each in-network storage (if there is no shared storage between them)? Resource sharing policies may be impacted (e.g., if a bandwidth sharing weight of 1 may mean something different at DECADE server A than it does at DECADE server B). At this point it may be best to just note these so they are documented, but since the specification of the resource sharing policies are still being contemplated for the basic case of a single server it may be premature to even try and solve them for the case supporting redirection. Multi-connection: I'm not quite clear on the intention of the requirement. My understanding is that you wish the client to be able to have multiple connections open spanning multiple DECADE servers. Is that correct? If so, do we need this stated as a requirement or the protocol? Or is this a policy that would be allowed/disallowed by the storage provider? Data Distribution: I'm also confused about the intent of this requirement. This statement has me somewhat worried: "The distribution is transparent to the users as they interact with the in-network storage as a single logical system." Does this mean that you are proposing for DECADE servers to assume the responsibility for deciding how data is to be distributed throughout the network, including the path of the data, which servers act as intermediate caches, content expiration policies, etc? If this is true, I think it is missing one of the major points of DECADE. In particular, these decisions are application-dependent and are not implemented within DECADE. Instead, DECADE provides the basic capabilities and the functionality described above are implemented by the applications using DECADE. Or, am I misinterpreting the intent of the requirement? Service Assurance: It seems problematic to include "assurance" in a DECADE. Shouldn't these instead be part of SLAs with a storage provider? Why should they be DECADE's responsibility? Regarding "resource reservation", are you referring to an actual reservation (which might be problematic -- see above) or do you mean that the resource share should able to be specified at the time the connection opens and be assumed to be the same for the duration of the connection? Regarding Dynamic Feedback, is this orthogonal to the storage protocol? It seems like what you want here is a generic "status" service saying how loaded a server is? Data classification: Would it be better to instead have the client specify properties of the content instead of place it into ? See www.ietf.org/proceedings/78/slides/nfsv4-0.pdf for an example of this approach for NFS. I think a problem with classifying applications is that it assumes that applications fit one of the supplied classifications. What if it may fit multiple classifications? or none? Another problem is it assumes that servers assume based on indirect and assumed information that they know what to do with a particular piece of content. Why not have an application specify its desires directly? Small Objects: What is the new requirement here? Why is the existing requirement in draft-ietf-decade-reqs-00 insufficient? This also has me a bit worried: "And the in-network storage has the limited storage capacity, with the arrival of user requests and data distribution requirements, the data stored in the in-network storage will be replaced if the storage reaches the limit and data arrivals continually." How does the server know what the proper replacement strategy is for an application? I think DECADE's philosophy is that applications should decide this. A simple way to do this is explicit deletion by an application, but perhaps a more efficient (yet more complex) solution is for an application to specify the replacement policy to the server. Removal of Expired Records: "However, the two scenarios did not mention how to handle the old resource if the user distributes the new resource which is an updated copy of the old resource." Why does this need to be handled in the requirements? Are you trying to draw the distinction between immediate deletion of content and lazy deletion? Thanks! Rich On Mon, Dec 27, 2010 at 12:57 AM, =E6=9C=B1=E6=BD=87 wrote: > Dear all, > > There is a slightly updated version of the decade additional requirements > draft. > https://datatracker.ietf.org/doc/draft-zhu-decade-additional-requirements= / > > Jin Peng, Yunfei Zhang and me are expecting to have a=C2=A0discussion=C2= =A0with all of > you. > > Any comments are appreciated! > > A=C2=A0new=C2=A0version=C2=A0of=C2=A0I-D,=C2=A0draft-zhu-decade-additiona= l-requirements-00.txt=C2=A0has=C2=A0been=C2=A0successfully=C2=A0submitted= =C2=A0by=C2=A0Xiao=C2=A0Zhu=C2=A0and=C2=A0posted=C2=A0to=C2=A0the=C2=A0IETF= =C2=A0repository. > > Filename: =C2=A0draft-zhu-decade-additional-requirements > Revision: =C2=A000 > Title: =C2=A0Additional=C2=A0protocol=C2=A0requirements=C2=A0on=C2=A0DEC= ADE > Creation_date: =C2=A02010-12-27 > WG=C2=A0ID: =C2=A0Independent=C2=A0Submission > Number_of_pages:=C2=A010 > > Abstract: > The=C2=A0DECoupled=C2=A0Application=C2=A0Data=C2=A0Enroute(DECADE)working= =C2=A0group=C2=A0is > specifying=C2=A0standardized=C2=A0interfaces=C2=A0for=C2=A0accessing=C2= =A0in-network=C2=A0storage > from=C2=A0applications=C2=A0to=C2=A0store,=C2=A0retrieve=C2=A0and=C2=A0ma= nage=C2=A0data.=C2=A0The=C2=A0main=C2=A0object > is=C2=A0to=C2=A0provide=C2=A0a=C2=A0framework=C2=A0that=C2=A0is=C2=A0usef= ul=C2=A0to=C2=A0the=C2=A0applications, > including=C2=A0P2P=C2=A0applications=C2=A0and=C2=A0other=C2=A0data-orient= ed=C2=A0applications, > possibly=C2=A0related=C2=A0applications=C2=A0that=C2=A0can=C2=A0benefit= =C2=A0from=C2=A0accessing=C2=A0in- > network=C2=A0storage.=C2=A0This=C2=A0memo=C2=A0focuses=C2=A0on=C2=A0some= =C2=A0requirements=C2=A0such=C2=A0as > request=C2=A0redirecting=C2=A0and=C2=A0so=C2=A0on=C2=A0which=C2=A0are=C2= =A0on=C2=A0the=C2=A0central=C2=A0of=C2=A0mobility, > wireless=C2=A0network=C2=A0environment=C2=A0and=C2=A0CDN=C2=A0application= .=C2=A0We=C2=A0present=C2=A0these=C2=A0in > this=C2=A0memo=C2=A0as=C2=A0additional=C2=A0requirements=C2=A0that=C2=A0s= hould=C2=A0be=C2=A0considered=C2=A0for > the=C2=A0DECADE=C2=A0architecture=C2=A0and=C2=A0protocol=C2=A0specificati= ons. > > > > The=C2=A0IETF=C2=A0Secretariat. > > -- > Best wishes, > > Beijing University of Posts & Telecommunications (BUPT) > Zhu Xiao=C2=A0 ( =E6=9C=B1=E6=BD=87 ) > E-mail: buptxiaozhu@gmail.com > mobile:+86 134-8881-9004 > > _______________________________________________ > decade mailing list > decade@ietf.org > https://www.ietf.org/mailman/listinfo/decade > > From richard.alimi@gmail.com Mon Jan 3 14:53:00 2011 Return-Path: X-Original-To: decade@core3.amsl.com Delivered-To: decade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4047B3A6CCC for ; Mon, 3 Jan 2011 14:53:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.76 X-Spam-Level: X-Spam-Status: No, score=-2.76 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HWZDJXuhaKMr for ; Mon, 3 Jan 2011 14:52:59 -0800 (PST) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 248C53A6CCD for ; Mon, 3 Jan 2011 14:52:59 -0800 (PST) Received: by iwn40 with SMTP id 40so14748860iwn.31 for ; Mon, 03 Jan 2011 14:55:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=9nfmqhmbFKV/warYcJ833VfmEMKYCeLZ43HcHUOwhss=; b=d0d8DcBtNxRjYImvR7BMyluJ1xvE4dDg5gFxEOEyr6XXjTAcXehBbckzYiVTwF7fVM gJspTUMpYQX+kRLiayQrMtdRBPiyHidodgRXG+alcMUevtk885fAenMaPJ29Tek5LTT5 U3wxZu1QCLEbsLlgYDdn0iBg3pjIKBsTiGvu4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=eFGVVRd7OXWOcCRtRPU7lMee/SWcoRKwKW9Zi/XBdCikxOlcXcWV3SnioENUB43Zcm IbcskU3qZauJaCQLZJu5Qr2TxE7Uw41CNuacXL28y/q/D8tLFkojVRk5WitDmoYcQORc AP4V7bSFvytId/VqccDDbdHTQPurlQlnCHYgA= MIME-Version: 1.0 Received: by 10.231.13.133 with SMTP id c5mr12157215iba.39.1294095306166; Mon, 03 Jan 2011 14:55:06 -0800 (PST) Sender: richard.alimi@gmail.com Received: by 10.231.31.8 with HTTP; Mon, 3 Jan 2011 14:55:06 -0800 (PST) In-Reply-To: <000001cba668$bfede680$3fc9b380$@com> References: <000001cba668$bfede680$3fc9b380$@com> Date: Mon, 3 Jan 2011 14:55:06 -0800 X-Google-Sender-Auth: JrncIhkJbhXiXQhVYbd6G3vU5U0 Message-ID: From: Richard Alimi To: Ning Zong Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: decade@ietf.org Subject: Re: [decade] WG review of draft-ietf-decade-problem-statement-01 X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jan 2011 22:53:00 -0000 Hi Ning, Thank you for providing a review. Some responses inline: On Tue, Dec 28, 2010 at 12:25 AM, Ning Zong wrote: > (As a reviewer) > > > > Just a few update suggestions: > > 1)=A0=A0=A0=A0=A0=A0 In clause 1, paragraph 5, it would be better to brie= fly introduce > what DECADE is before using this term. We can add some text before paragr= aph > 5 as follows: > > =93In this document, DECADE is defined as a standard interface for variou= s P2P > applications to access storage and data transport services in the network= to > improve their efficiency and reduce the stress on the network > infrastructure.=94 I agree that an introduction is needed here. As a slight modification to your suggestion, I've added the following text to the to-be-released-next-version of the document. "This document introduces DECADE, a standard interface for various P2P applications to access storage and data transport services in the network to improve their efficiency and reduce load on the network infrastructure." How does that sound? > > > > 2)=A0=A0=A0=A0=A0=A0 In clause 4, it would be better to explicitly clarif= y =93DECADE=94 and > =93IAP=94 in some places to reduce the potential confusion to new readers= . We > can update some text as follows: > > 2.1) paragraph 1 changes to: > > =93The objective of this working group is to design DECADE, which mainly > consists of an in-network storage access protocol (IAP) to address the > problems discussed in the preceding section.=94 Done. > > 2.2) clause 4.1, the first sentence changes to: > > =93P2P application clients use the IAP protocol to read data from an > in-network storage, store data to an in-network storage, or remove data f= rom > an in-network storage.=94 Done. > 2.3) clause 4.3, the first sentence changes to: > > =93A user uses the IAP protocol to manage the resources on in-network sto= rage > that can be used by other peers, e.g., the bandwidth or connections.=94 Done. > 3)=A0=A0=A0=A0=A0=A0 In clause 9.2, we need to update the fourth referenc= e to: > > [I-D.ietf-ppsp-problem-statement] Zhang, Y., Zong, N., Camarillo, G., Sen= g, > J., and Y. Yang, "Problem Statement of P2P Streaming Protocol (PPSP)", > draft-ietf-ppsp-problem-statement-00 (work in progress), October 2010. Done. Thanks for the comments! Rich From richard.alimi@gmail.com Mon Jan 3 14:56:02 2011 Return-Path: X-Original-To: decade@core3.amsl.com Delivered-To: decade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BFCDF3A6CDC for ; Mon, 3 Jan 2011 14:56:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.315 X-Spam-Level: X-Spam-Status: No, score=-2.315 tagged_above=-999 required=5 tests=[AWL=-0.338, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VOcBA8kA+m4H for ; Mon, 3 Jan 2011 14:56:01 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id 81D5C3A6CDB for ; Mon, 3 Jan 2011 14:56:01 -0800 (PST) Received: by iyi42 with SMTP id 42so13628844iyi.31 for ; Mon, 03 Jan 2011 14:58:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=YSLQukoDxfsWIEgd24cGG9rfriHpEsUbZOxNutaLMzc=; b=W7YBgdeYaLkELfQJZ9hx70Dl13jcTCRp4diULMj7gWeoVL1eKbHXTbpc3WK0mI0d9N ZkNJcwv5OkpRoJCpvLoJkXj4WCD6wg5P2iXINtWMob6MTiMmfjL+DvOXtozQZIyAsZ1f 31irx8d8gzNkT8Q0rmCKGYKD9kP13fe/Qd0J4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=t3nsCjMI9JQdgpGr5C5AM2CVy7liIriiH8cuuyOSkzCZxh56cj4jwqp6sQXsJ/TjEY JxNwzTi6sO2/xKaVOJ20riPzaDuBNKtYseNY7VlpGUYABNz5m0cRQOVOJ2kluQW0hcS1 yYNIqGVzkZe38PxNvYH7w1xEWdRjLF9avrLTk= MIME-Version: 1.0 Received: by 10.42.175.69 with SMTP id az5mr21552384icb.381.1294095488672; Mon, 03 Jan 2011 14:58:08 -0800 (PST) Sender: richard.alimi@gmail.com Received: by 10.231.31.8 with HTTP; Mon, 3 Jan 2011 14:58:08 -0800 (PST) In-Reply-To: <057E4696615D964AB8053E9EE5DCD3D494E150@szxeml507-mbx.china.huawei.com> References: <057E4696615D964AB8053E9EE5DCD3D494E150@szxeml507-mbx.china.huawei.com> Date: Mon, 3 Jan 2011 14:58:08 -0800 X-Google-Sender-Auth: aEN9wU8t6wgvZBYlRC48iINAU1w Message-ID: From: Richard Alimi To: Songhaibin Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: "decade@ietf.org" Subject: Re: [decade] Comments on Decade Problem Statement X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jan 2011 22:56:03 -0000 Apologies for the delay in getting back to this. Thank you for the reviews. One comment inline: On Wed, Nov 24, 2010 at 6:31 PM, Songhaibin wrote: > Hi Akbar, > > Thank you very much for the review. Please see inline. > > > ________________________________________ > From: Rahman, Akbar [Akbar.Rahman@InterDigital.com] > Sent: Thursday, November 25, 2010 4:26 > To: Songhaibin > Cc: decade@ietf.org > Subject: Comments on Decade Problem Statement > > Hi Haibin, > > > As per my action from the IETF Beijing meeting, here are my comments (as = 1 of the 3 volunteer reviewers) on draft-song-decade-problem-statement-00. > > Overall, the document looks in very good shape. =A0However, I did have th= e following comments: > > > Technical questions: > > 1. =A0 =A0 =A0 I read the reference [weaver-alto-edge-caches] given in se= ctions 1 and 3 and got the impression that [weaver-alto-edge-caches] stress= es that the P2P cache should be specifically located at the =93edge=94 for = best performance. =A0I did not see this point stressed in the PS, was there= a specific reason for not stressing this point? =A0I am not advocating tha= t we do so, but I am just trying to understand as the reference was stresse= d in the PS as a good justification for DECADE. > > [Haibin] Good question. It makes sense to discuss the location of the P2P= Cache or DECADE storage in the draft. They should be located at the edge o= f ISP's network for better performance. We will add some sentences in the n= ext version if people like. > I'm not sure that the problem statement needs to advocate a particular placement. There are multiple tradeoffs here. For example, though placing a storage server near the edge can reduce latency, depending on your definition of "edge" and how many subscribers are covered, it also may mean less opportunity for de-duplication, increased equipment costs (more servers), and more-difficult physical access to the machines for maintenance. Because of the complexity of this problem, it seems better to stay silent on the issue in the problem statement with regards to recommendations (and perhaps just note that placement of servers has both cost and performance implications). Thanks, Rich From richard.alimi@gmail.com Mon Jan 3 15:31:54 2011 Return-Path: X-Original-To: decade@core3.amsl.com Delivered-To: decade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D5ECB3A6D6F for ; Mon, 3 Jan 2011 15:31:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.247 X-Spam-Level: X-Spam-Status: No, score=-2.247 tagged_above=-999 required=5 tests=[AWL=-0.270, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xv1x6+1Va-AF for ; Mon, 3 Jan 2011 15:31:53 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id 660943A6D6E for ; Mon, 3 Jan 2011 15:31:53 -0800 (PST) Received: by iyi42 with SMTP id 42so13649672iyi.31 for ; Mon, 03 Jan 2011 15:34:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=z4vVdu905kMOzFFugQEpOSWk98pjnuAR2HdH6FmKt2c=; b=Zu11jWjHjMF/8ARS6MeXrNKp/C5ntg3unoEnGLH+w8ZKP3RdSpvEGhGkWHTGLubUkY xwFJ98nd0B/LdJjIL6S5j95odhR7vPsArUkmwItoUMqfvWlDYLWYft7TqC5hyxeHuTEQ 3xDPI9y4JndvFh5n+Ib69OHyPgpUPw7ss/cWc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=rSoMseqV62Gf5YMr3YiLplnfn7B2PMMur5aY8AI3c3o2HJ7fXBm9i47qun3llUnrof ss/yw6hpLhRtmybBbkuDZUyZiqWD+YyqpFELCk4xE71FyULr7jMqjHSwSBCQL20DQ7d1 Q4Hrfh5NwgGira8hPrYSfXM4DAAhwJs/hoDrs= MIME-Version: 1.0 Received: by 10.231.30.73 with SMTP id t9mr10898763ibc.64.1294097640508; Mon, 03 Jan 2011 15:34:00 -0800 (PST) Sender: richard.alimi@gmail.com Received: by 10.231.31.8 with HTTP; Mon, 3 Jan 2011 15:34:00 -0800 (PST) In-Reply-To: <201012271733266711931@chinamobile.com> References: <1CA25301D2219F40B3AA37201F0EACD104E84F@PACDCEXMB05.cable.comcast.com> <201012271733266711931@chinamobile.com> Date: Mon, 3 Jan 2011 15:34:00 -0800 X-Google-Sender-Auth: rGzDI-Zhx1RrIABAQTRlamQ8vSA Message-ID: From: Richard Alimi To: zhangyunfei Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable Cc: "decade@ietf.org" Subject: Re: [decade] WG Reviews of the Decade Survey draft X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jan 2011 23:31:55 -0000 Hi Yunfei, Thank you for the review. Some responses inline: 2010/12/27 zhangyunfei : > First of all happy new year to everybody! > > > > The following is my WG review of draft-ietf-decade-survey-02. > > > > Summary: > > > > This document surveys thoroughly deployed, experimental and on-research > in-network storage and cache systems/ sub-systems > > and describes their applicability for DECADE. It provides rich references > for knowing what the existing systems have and > > what they lack of. Therefore the designing space of DECADE is explicated = for > better understanding. The draft is well written and > > conveys the group's intent well. > > The authors are suggested to categorize the surveyed systems/sub-systems = as > user-controlled (individual) services (in scope of DECADE) > > and network-controlled (mass) services (out of scope of DECADE) to make i= t > more focus on DECADE type services. > > > > Specific comments and concerns: > > 1=A3=AE The organization of section 4: In this section the authors surve= y > thoroughly deployed, experimental and on-research in-network storage > > and cache systems/ sub-systems. However some of them are > user-controlled (individual) services like section 4.1, 4.2,4.9,4.10 and > > part of 4.12, which are in scope of DECADE; others are network > controlled(mass) services where the users have no rights to operate > > the in-network storage or caches, which are out of scope of DECADE. T= he > current organization is a little bit messy and it's suggested > > to separate the two parts and focus on the DECADE type services. I would agree that Section 4 is somewhat long and that it would be good to have subcategories for the systems. This has been discussed a couple of times amongst the authors but it was unclear as to the proper way to do such a categorization. For example, your classification above, why is BranchCache (4.2) user-controlled/individual? S3 can both be used for individual and mass usage. It seemed that any attempt at categorization that we've discussed thus far has counterexamples which would be debatable by a reader. To me, it seems a proper way to categorize them would be a feature matrix, but that doesn't work well with the hierarchical sections of the document. We are more than happy to discuss this again amongst the authors, but do you have some additional ideas on an appropriate scheme? > > 2=A3=AE Difference between cache and storage: In section 4, there are ma= ny > places to mention in-network caches. In network-controlled > > caches, it's hard to introduce DECADE service because some of the > operations defined in DECADE like data deletion in DECADE > > server (if we use the current cache as the DECADE server) may raise > confliction with the existing cache update mechanism > > by Cache operators when dealing with a certain data. In section 4.14 > the authors state the possible inapplicability for the cache scenarios > > in using DECADE mechanism. But to make the draft more clear, it's > better to state explicit the scope of DECADE ahead of this section. > > And also more discussions on whether and how much degree we need the > cache system/subsystem description in this draft are needed in the group. That makes sense. If the section 4.14 of the Survey draft is updated to reference the scope DECADE (perhaps via a reference to the problem statement), do you think it would serve as good input to that discussion? > 3. In section 2, the No.1 effect of DECADE, to my understanding, is to > improve P2P application experience in up-band constraint environment like > > cellular mobile networks. The current draft lacks of this although th= is > is highlighted in the PS. Makes sense. We can add a reference to this discussion in the problem statement in the introduction. > > 4. Data Search Capability described in section 3.3 seems irrelevant to > DECADE protocols. I agree that most (if not all) aspects of "Search" could reside outside of DECADE, but I think it still makes sense to cover them in the survey. At the very least, it can highlight the different features for each storage system, particular the distributed ones. Some additional discussion in the "Observations" section could talk about this. > > 5. In section 3.8 the authors propose three types of storage modes witho= ut > explicit description. And the following echoes in section 4 still pose an > > ambiguous image esp. between file and object oriented mode. Agreed that the draft should define the terms, and that we should clarify the distinction between "file-based" and "object-based" (perhaps by renaming "file-based" to something like "hierarchical filesystem" or "directory-based"). Thanks again for the review! Rich From richard.alimi@gmail.com Mon Jan 3 15:38:03 2011 Return-Path: X-Original-To: decade@core3.amsl.com Delivered-To: decade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 506DC3A6D8A for ; Mon, 3 Jan 2011 15:38:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.202 X-Spam-Level: X-Spam-Status: No, score=-2.202 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QNgHbeqzWdPC for ; Mon, 3 Jan 2011 15:38:02 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id 5886B3A6D8D for ; Mon, 3 Jan 2011 15:38:02 -0800 (PST) Received: by iyi42 with SMTP id 42so13653419iyi.31 for ; Mon, 03 Jan 2011 15:40:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=JrSpPJJ5K9RoL+PFu+nB/MYUygzKTCgiYaVDsnfxTaA=; b=QXt0U0DDNIHCK/jU2Gy8ppOguBmWLXmTJAzrcADWLcoOU5umFd4kCamTnD+/AhwkUL JRfvxnAQAm1MmEfezYioBBI4I7lBasNUhMGfDNIxK2o8BPaRkklJt2wgVrJkqF+PQVFe RyrGmvkbTqepZp2kGc5UvMTy0eb+ua8pmWeNU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=XE8uUCPvxW6QVJC/i7HP/8aCl770SYqocJFLSRr0dIztu1aRGn5cwZRhSXesQxxwNF 6FRt9FhBCGu6a0VAgj+TJEG1f4nf+4Y7Siqd16Oh3x7jJHhhWQlR+Pno7tR1J7TtuPkS 4NW6ZM7/wjI9bA/MuE4jFtTGcaqs7BiBjNHhU= MIME-Version: 1.0 Received: by 10.231.34.200 with SMTP id m8mr8191405ibd.89.1294098009371; Mon, 03 Jan 2011 15:40:09 -0800 (PST) Sender: richard.alimi@gmail.com Received: by 10.231.31.8 with HTTP; Mon, 3 Jan 2011 15:40:09 -0800 (PST) In-Reply-To: References: Date: Mon, 3 Jan 2011 15:40:09 -0800 X-Google-Sender-Auth: 6zg4HNV443DbQAPU2V5DVwDNKDE Message-ID: From: Richard Alimi To: "David A. Bryan" Content-Type: text/plain; charset=ISO-8859-1 Cc: "Woundy, Richard" , DECADE Subject: Re: [decade] WG review of draft-ietf-decade-survey-02 X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jan 2011 23:38:03 -0000 Hi David, Thanks for the review. As Akbar mentioned we will incorporate these into the next revision of the draft. Just one response inline: On Tue, Dec 28, 2010 at 9:18 AM, David A. Bryan wrote: ... > The author list at the end and the list on the header don't agree. The > header has 3 authors, the end has 6. These are editors in the header, with the full list of authors at the end. We used the same approach for the draft-ietf-alto-protocol as suggested by the ALTO WG chairs, and the DECADE WG chairs said we could use the same here. Rich From zongning@huawei.com Mon Jan 3 18:08:00 2011 Return-Path: X-Original-To: decade@core3.amsl.com Delivered-To: decade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD1F73A690B for ; Mon, 3 Jan 2011 18:08:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.935 X-Spam-Level: X-Spam-Status: No, score=-101.935 tagged_above=-999 required=5 tests=[AWL=2.108, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1, SARE_SUB_ENC_UTF8=0.152, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hTV+s2JYz4Jq for ; Mon, 3 Jan 2011 18:07:59 -0800 (PST) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 8F1213A6907 for ; Mon, 3 Jan 2011 18:07:59 -0800 (PST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LEH0040W78YU0@szxga03-in.huawei.com> for decade@ietf.org; Tue, 04 Jan 2011 10:07:46 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LEH00L1178XW5@szxga03-in.huawei.com> for decade@ietf.org; Tue, 04 Jan 2011 10:07:45 +0800 (CST) Received: from z63316a ([10.138.41.69]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LEH005EA78TJL@szxml04-in.huawei.com> for decade@ietf.org; Tue, 04 Jan 2011 10:07:45 +0800 (CST) Date: Tue, 04 Jan 2011 10:07:41 +0800 From: Ning Zong In-reply-to: To: 'Richard Alimi' Message-id: <004201cbabb4$2b538d30$81faa790$@com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=utf-8 Content-language: zh-cn Content-transfer-encoding: quoted-printable Thread-index: AcurmUZr7XC3q/fsTy+z74CWIfzuPQAGrR+Q References: <000001cba668$bfede680$3fc9b380$@com> Cc: decade@ietf.org Subject: [decade] =?utf-8?b?562U5aSNOiAgV0cgcmV2aWV3IG9mIGRyYWZ0LWlldGYt?= =?utf-8?q?decade-problem-statement-01?= X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jan 2011 02:08:00 -0000 Hi Rich, It looks good. Thank you for editing. BR, Ning Zong -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- =E5=8F=91=E4=BB=B6=E4=BA=BA: richard.alimi@gmail.com = [mailto:richard.alimi@gmail.com] =E4=BB=A3=E8=A1=A8 Richard Alimi =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2011=E5=B9=B41=E6=9C=884=E6=97=A5 = 6:55 =E6=94=B6=E4=BB=B6=E4=BA=BA: Ning Zong =E6=8A=84=E9=80=81: decade@ietf.org =E4=B8=BB=E9=A2=98: Re: [decade] WG review of = draft-ietf-decade-problem-statement-01 Hi Ning, Thank you for providing a review. Some responses inline: On Tue, Dec 28, 2010 at 12:25 AM, Ning Zong wrote: > (As a reviewer) > > > > Just a few update suggestions: > > 1) In clause 1, paragraph 5, it would be better to briefly = introduce > what DECADE is before using this term. We can add some text before = paragraph > 5 as follows: > > =E2=80=9CIn this document, DECADE is defined as a standard interface = for various P2P > applications to access storage and data transport services in the = network to > improve their efficiency and reduce the stress on the network > infrastructure.=E2=80=9D I agree that an introduction is needed here. As a slight modification to your suggestion, I've added the following text to the to-be-released-next-version of the document. "This document introduces DECADE, a standard interface for various P2P applications to access storage and data transport services in the network to improve their efficiency and reduce load on the network infrastructure." How does that sound? > > > > 2) In clause 4, it would be better to explicitly clarify = =E2=80=9CDECADE=E2=80=9D and > =E2=80=9CIAP=E2=80=9D in some places to reduce the potential confusion = to new readers. We > can update some text as follows: > > 2.1) paragraph 1 changes to: > > =E2=80=9CThe objective of this working group is to design DECADE, = which mainly > consists of an in-network storage access protocol (IAP) to address the > problems discussed in the preceding section.=E2=80=9D Done. > > 2.2) clause 4.1, the first sentence changes to: > > =E2=80=9CP2P application clients use the IAP protocol to read data = from an > in-network storage, store data to an in-network storage, or remove = data from > an in-network storage.=E2=80=9D Done. > 2.3) clause 4.3, the first sentence changes to: > > =E2=80=9CA user uses the IAP protocol to manage the resources on = in-network storage > that can be used by other peers, e.g., the bandwidth or = connections.=E2=80=9D Done. > 3) In clause 9.2, we need to update the fourth reference to: > > [I-D.ietf-ppsp-problem-statement] Zhang, Y., Zong, N., Camarillo, G., = Seng, > J., and Y. Yang, "Problem Statement of P2P Streaming Protocol (PPSP)", > draft-ietf-ppsp-problem-statement-00 (work in progress), October 2010. Done. Thanks for the comments! Rich From zhangyunfei@chinamobile.com Mon Jan 3 18:09:10 2011 Return-Path: X-Original-To: decade@core3.amsl.com Delivered-To: decade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B2E293A690F for ; Mon, 3 Jan 2011 18:09:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.768 X-Spam-Level: X-Spam-Status: No, score=-95.768 tagged_above=-999 required=5 tests=[AWL=0.405, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RELAY_IS_221=2.222, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qp4SnYhIz7UY for ; Mon, 3 Jan 2011 18:09:09 -0800 (PST) Received: from hqmta.chinamobile.com (hqmta.chinamobile.com [221.130.253.171]) by core3.amsl.com (Postfix) with ESMTP id B43E03A690E for ; Mon, 3 Jan 2011 18:09:08 -0800 (PST) Received: from hqmta.chinamobile.com (localhost [127.0.0.1]) by localhost.imsstest.com (Postfix) with ESMTP id B343A20F9F; Tue, 4 Jan 2011 10:11:05 +0800 (CST) Received: from mail.chinamobile.com (unknown [10.1.28.22]) by hqmta.chinamobile.com (Postfix) with ESMTP id A164420DF0; Tue, 4 Jan 2011 10:11:05 +0800 (CST) Received: from zyf ([10.2.2.169]) by mail.chinamobile.com (Lotus Domino Release 6.5.6) with ESMTP id 2011010410110350-4739 ; Tue, 4 Jan 2011 10:11:03 +0800 Date: Tue, 4 Jan 2011 10:11:01 +0800 From: "zhangyunfei" To: "Richard Alimi" References: < 1CA25301D2219F40B3AA37201F0EACD104E84F@PACDCEXMB05.cable.comcast.com><201012271733266711931@chinamobile.com> Message-ID: <201101041011014068900@chinamobile.com> X-mailer: Foxmail 6, 2, 103, 20 [cn] Mime-Version: 1.0 X-MIMETrack: Itemize by SMTP Server on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2011-01-04 10:11:03, Serialize by Router on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2011-01-04 10:11:05, Serialize complete at 2011-01-04 10:11:05 Content-Type: multipart/alternative; boundary="=====003_Dragon813565022156_=====" X-TM-AS-Product-Ver: IMSS-7.0.0.8231-6.5.0.1024-17872.003 X-TM-AS-Result: No--43.665-5.0-31-10 X-imss-scan-details: No--43.665-5.0-31-10;No--43.665-5.0-31-10 Cc: "decade@ietf.org" Subject: Re: [decade] WG Reviews of the Decade Survey draft X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jan 2011 02:09:10 -0000 This is a multi-part message in MIME format. --=====003_Dragon813565022156_===== Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="gb2312" SGkgUmljaCwNCiAgIEhhcHB5IG5ldyB5ZWFyIGFuZCBwbGVhc2Ugc2VlIGlubGluZSBmb3IgdGhl IGRldGFpbC4NCkJSDQpZdW5mZWkNCg0KDQoNCg0Kemhhbmd5dW5mZWkNCjIwMTEtMDEtMDQNCg0K DQoNCreivP7Iy6O6IFJpY2hhcmQgQWxpbWkNCreiy83Ksbzko7ogMjAxMS0wMS0wNCAwNzozNDow Mg0KytW8/sjLo7ogemhhbmd5dW5mZWkNCrOty82juiBkZWNhZGVAaWV0Zi5vcmcNCtb3zOKjuiBS ZTogW2RlY2FkZV0gV0cgUmV2aWV3cyBvZiB0aGUgRGVjYWRlIFN1cnZleSBkcmFmdA0KDQpIaSAg WXVuZmVpLA0KDQpUaGFuayAgeW91ICBmb3IgIHRoZSAgcmV2aWV3LiAgU29tZSAgcmVzcG9uc2Vz ICBpbmxpbmU6DQoNCjIwMTAvMTIvMjcgIHpoYW5neXVuZmVpICAgPHpoYW5neXVuZmVpQGNoaW5h bW9iaWxlLmNvbSA+Og0KPiAgRmlyc3QgIG9mICBhbGwgIGhhcHB5ICBuZXcgIHllYXIgIHRvICBl dmVyeWJvZHkhDQo+DQo+DQo+DQo+ICBUaGUgIGZvbGxvd2luZyAgaXMgIG15ICBXRyAgcmV2aWV3 ICBvZiAgZHJhZnQtaWV0Zi1kZWNhZGUtc3VydmV5LTAyLg0KPg0KPg0KPg0KPiAgU3VtbWFyeToN Cj4NCj4NCj4NCj4gIFRoaXMgIGRvY3VtZW50ICBzdXJ2ZXlzICB0aG9yb3VnaGx5ICBkZXBsb3ll ZCwgIGV4cGVyaW1lbnRhbCAgYW5kICBvbi1yZXNlYXJjaA0KPiAgaW4tbmV0d29yayAgc3RvcmFn ZSAgYW5kICBjYWNoZSAgc3lzdGVtcy8gIHN1Yi1zeXN0ZW1zDQo+DQo+ICBhbmQgIGRlc2NyaWJl cyAgdGhlaXIgIGFwcGxpY2FiaWxpdHkgIGZvciAgREVDQURFLiAgSXQgIHByb3ZpZGVzICByaWNo ICByZWZlcmVuY2VzDQo+ICBmb3IgIGtub3dpbmcgIHdoYXQgIHRoZSAgZXhpc3RpbmcgIHN5c3Rl bXMgIGhhdmUgIGFuZA0KPg0KPiAgd2hhdCAgdGhleSAgbGFjayAgb2YuICBUaGVyZWZvcmUgIHRo ZSAgZGVzaWduaW5nICBzcGFjZSAgb2YgIERFQ0FERSAgaXMgIGV4cGxpY2F0ZWQgIGZvcg0KPiAg YmV0dGVyICB1bmRlcnN0YW5kaW5nLiAgVGhlICBkcmFmdCAgaXMgIHdlbGwgIHdyaXR0ZW4gIGFu ZA0KPg0KPiAgY29udmV5cyAgdGhlICBncm91cCdzICBpbnRlbnQgIHdlbGwuDQo+DQo+ICBUaGUg IGF1dGhvcnMgIGFyZSAgc3VnZ2VzdGVkICB0byAgY2F0ZWdvcml6ZSAgdGhlICBzdXJ2ZXllZCAg c3lzdGVtcy9zdWItc3lzdGVtcyAgYXMNCj4gIHVzZXItY29udHJvbGxlZCAgKGluZGl2aWR1YWwp ICBzZXJ2aWNlcyAgKGluICBzY29wZSAgb2YgIERFQ0FERSkNCj4NCj4gIGFuZCAgbmV0d29yay1j b250cm9sbGVkICAobWFzcykgIHNlcnZpY2VzICAob3V0ICBvZiAgc2NvcGUgIG9mICBERUNBREUp ICB0byAgbWFrZSAgaXQNCj4gIG1vcmUgIGZvY3VzICBvbiAgREVDQURFICB0eXBlICBzZXJ2aWNl cy4NCj4NCj4NCj4NCj4gIFNwZWNpZmljICBjb21tZW50cyAgYW5kICBjb25jZXJuczoNCj4NCj4g IDGjriAgICBUaGUgIG9yZ2FuaXphdGlvbiAgb2YgIHNlY3Rpb24gIDQ6ICBJbiAgdGhpcyAgc2Vj dGlvbiAgdGhlICBhdXRob3JzICBzdXJ2ZXkNCj4gIHRob3JvdWdobHkgIGRlcGxveWVkLCAgZXhw ZXJpbWVudGFsICBhbmQgIG9uLXJlc2VhcmNoICBpbi1uZXR3b3JrICBzdG9yYWdlDQo+DQo+ICAg ICAgICAgICAgICBhbmQgIGNhY2hlICBzeXN0ZW1zLyAgc3ViLXN5c3RlbXMuICBIb3dldmVyICBz b21lICBvZiAgdGhlbSAgYXJlDQo+ICB1c2VyLWNvbnRyb2xsZWQgIChpbmRpdmlkdWFsKSAgc2Vy dmljZXMgIGxpa2UgIHNlY3Rpb24gIDQuMSwgIDQuMiw0LjksNC4xMCAgYW5kDQo+DQo+ICAgICAg ICAgICAgcGFydCAgb2YgIDQuMTIsICB3aGljaCAgYXJlICBpbiAgc2NvcGUgIG9mICBERUNBREU7 ICBvdGhlcnMgIGFyZSAgbmV0d29yaw0KPiAgY29udHJvbGxlZChtYXNzKSAgc2VydmljZXMgIHdo ZXJlICB0aGUgIHVzZXJzICBoYXZlICBubyAgcmlnaHRzICB0byAgb3BlcmF0ZQ0KPg0KPiAgICAg ICAgICB0aGUgIGluLW5ldHdvcmsgIHN0b3JhZ2UgIG9yICBjYWNoZXMsICB3aGljaCAgYXJlICBv dXQgIG9mICBzY29wZSAgb2YgIERFQ0FERS4gIFRoZQ0KPiAgY3VycmVudCAgb3JnYW5pemF0aW9u ICBpcyAgYSAgbGl0dGxlICBiaXQgIG1lc3N5ICBhbmQgIGl0J3MgIHN1Z2dlc3RlZA0KPg0KPiAg ICAgICAgICB0byAgc2VwYXJhdGUgIHRoZSAgdHdvICBwYXJ0cyAgYW5kICBmb2N1cyAgb24gIHRo ZSAgREVDQURFICB0eXBlICBzZXJ2aWNlcy4NCg0KSSAgd291bGQgIGFncmVlICB0aGF0ICBTZWN0 aW9uICA0ICBpcyAgc29tZXdoYXQgIGxvbmcgIGFuZCAgdGhhdCAgaXQgIHdvdWxkICBiZQ0KZ29v ZCAgdG8gIGhhdmUgIHN1YmNhdGVnb3JpZXMgIGZvciAgdGhlICBzeXN0ZW1zLiAgICBUaGlzICBo YXMgIGJlZW4gIGRpc2N1c3NlZCAgYQ0KY291cGxlICBvZiAgdGltZXMgIGFtb25nc3QgIHRoZSAg YXV0aG9ycyAgYnV0ICBpdCAgd2FzICB1bmNsZWFyICBhcyAgdG8gIHRoZQ0KcHJvcGVyICB3YXkg IHRvICBkbyAgc3VjaCAgYSAgY2F0ZWdvcml6YXRpb24uICAgIEZvciAgZXhhbXBsZSwgIHlvdXIN CmNsYXNzaWZpY2F0aW9uICBhYm92ZSwgIHdoeSAgaXMgIEJyYW5jaENhY2hlICAoNC4yKQ0KdXNl ci1jb250cm9sbGVkL2luZGl2aWR1YWw/ICAgIFMzICBjYW4gIGJvdGggIGJlICB1c2VkICBmb3Ig IGluZGl2aWR1YWwgIGFuZA0KbWFzcyAgdXNhZ2UuICAgIEl0ICBzZWVtZWQgIHRoYXQgIGFueSAg YXR0ZW1wdCAgYXQgIGNhdGVnb3JpemF0aW9uICB0aGF0ICB3ZSd2ZQ0KZGlzY3Vzc2VkICB0aHVz ICBmYXIgIGhhcyAgY291bnRlcmV4YW1wbGVzICB3aGljaCAgd291bGQgIGJlICBkZWJhdGFibGUg IGJ5ICBhDQpyZWFkZXIuDQpJIG1ha2UgdGhlIGF0dGVtcHQgdG8gY2F0ZWdvcml6ZSB0aGUgc3lz dGVtcyBhY2NvcmRpbmcgdG8gdGhlIHRleHQgYW5kIG15IHVuZGVyc3RhbmRpbmcuDQpJdCdzIHJl YWxseSBhIGhhcmQgam9iIHRvIHNvbHZlIHRoZSBtYXRyaXggcGVyZmVjdGx5Lg0KDQpUbyAgbWUs ICBpdCAgc2VlbXMgIGEgIHByb3BlciAgd2F5ICB0byAgY2F0ZWdvcml6ZSAgdGhlbSAgd291bGQg IGJlICBhICBmZWF0dXJlDQptYXRyaXgsICBidXQgIHRoYXQgIGRvZXNuJ3QgIHdvcmsgIHdlbGwg IHdpdGggIHRoZSAgaGllcmFyY2hpY2FsICBzZWN0aW9ucyAgb2YNCnRoZSAgZG9jdW1lbnQuDQoN CldlICBhcmUgIG1vcmUgIHRoYW4gIGhhcHB5ICB0byAgZGlzY3VzcyAgdGhpcyAgYWdhaW4gIGFt b25nc3QgIHRoZSAgYXV0aG9ycywgIGJ1dA0KZG8gIHlvdSAgaGF2ZSAgc29tZSAgYWRkaXRpb25h bCAgaWRlYXMgIG9uICBhbiAgYXBwcm9wcmlhdGUgIHNjaGVtZT8NCg0KU291bmQgZ29vZCBhbmQg SSdsbCBsZXQgeW91IGtub3cgaWYgSSBoYXZlIGdvb2QgaWRlYXMgb24gc29sdmluZyB0aGlzLg0K DQo+DQo+ICAyo64gICAgRGlmZmVyZW5jZSAgYmV0d2VlbiAgY2FjaGUgIGFuZCAgc3RvcmFnZTog IEluICBzZWN0aW9uICA0LCAgdGhlcmUgIGFyZSAgbWFueQ0KPiAgcGxhY2VzICB0byAgbWVudGlv biAgaW4tbmV0d29yayAgY2FjaGVzLiAgSW4gIG5ldHdvcmstY29udHJvbGxlZA0KPg0KPiAgICAg ICAgICAgIGNhY2hlcywgIGl0J3MgIGhhcmQgIHRvICBpbnRyb2R1Y2UgIERFQ0FERSAgc2Vydmlj ZSAgYmVjYXVzZSAgc29tZSAgb2YgIHRoZQ0KPiAgb3BlcmF0aW9ucyAgZGVmaW5lZCAgaW4gIERF Q0FERSAgbGlrZSAgZGF0YSAgZGVsZXRpb24gIGluICBERUNBREUNCj4NCj4gICAgICAgICAgICBz ZXJ2ZXIgIChpZiAgd2UgIHVzZSAgdGhlICBjdXJyZW50ICBjYWNoZSAgYXMgIHRoZSAgREVDQURF ICBzZXJ2ZXIpICBtYXkgIHJhaXNlDQo+ICBjb25mbGljdGlvbiAgd2l0aCAgdGhlICBleGlzdGlu ZyAgY2FjaGUgIHVwZGF0ZSAgbWVjaGFuaXNtDQo+DQo+ICAgICAgICAgICAgYnkgIENhY2hlICBv cGVyYXRvcnMgIHdoZW4gIGRlYWxpbmcgIHdpdGggIGEgIGNlcnRhaW4gIGRhdGEuICBJbiAgc2Vj dGlvbiAgNC4xNA0KPiAgdGhlICBhdXRob3JzICBzdGF0ZSAgdGhlICBwb3NzaWJsZSAgaW5hcHBs aWNhYmlsaXR5ICBmb3IgIHRoZSAgY2FjaGUgIHNjZW5hcmlvcw0KPg0KPiAgICAgICAgICAgIGlu ICB1c2luZyAgREVDQURFICBtZWNoYW5pc20uICBCdXQgIHRvICBtYWtlICB0aGUgIGRyYWZ0ICBt b3JlICBjbGVhciwgIGl0J3MNCj4gIGJldHRlciAgdG8gIHN0YXRlICBleHBsaWNpdCAgdGhlICBz Y29wZSAgb2YgIERFQ0FERSAgYWhlYWQgIG9mICB0aGlzICBzZWN0aW9uLg0KPg0KPiAgICAgICAg ICBBbmQgIGFsc28gIG1vcmUgIGRpc2N1c3Npb25zICBvbiAgd2hldGhlciAgYW5kICBob3cgIG11 Y2ggIGRlZ3JlZSAgd2UgIG5lZWQgIHRoZQ0KPiAgY2FjaGUgIHN5c3RlbS9zdWJzeXN0ZW0gIGRl c2NyaXB0aW9uICBpbiAgdGhpcyAgZHJhZnQgIGFyZSAgbmVlZGVkICBpbiAgdGhlICBncm91cC4N Cg0KVGhhdCAgbWFrZXMgIHNlbnNlLiAgSWYgIHRoZSAgc2VjdGlvbiAgNC4xNCAgb2YgIHRoZSAg U3VydmV5ICBkcmFmdCAgaXMgIHVwZGF0ZWQNCnRvICByZWZlcmVuY2UgIHRoZSAgc2NvcGUgIERF Q0FERSAgKHBlcmhhcHMgIHZpYSAgYSAgcmVmZXJlbmNlICB0byAgdGhlICBwcm9ibGVtDQpzdGF0 ZW1lbnQpLCAgZG8gIHlvdSAgdGhpbmsgIGl0ICB3b3VsZCAgc2VydmUgIGFzICBnb29kICBpbnB1 dCAgdG8gIHRoYXQNCmRpc2N1c3Npb24/DQoNClllcywgaXQgd291bGQgYmUuDQoNCj4gIDMuICAg IEluICBzZWN0aW9uICAyLCAgdGhlICBOby4xICBlZmZlY3QgIG9mICBERUNBREUsICB0byAgbXkg IHVuZGVyc3RhbmRpbmcsICBpcyAgdG8NCj4gIGltcHJvdmUgIFAyUCAgYXBwbGljYXRpb24gIGV4 cGVyaWVuY2UgIGluICB1cC1iYW5kICBjb25zdHJhaW50ICBlbnZpcm9ubWVudCAgbGlrZQ0KPg0K PiAgICAgICAgICBjZWxsdWxhciAgbW9iaWxlICBuZXR3b3Jrcy4gIFRoZSAgY3VycmVudCAgZHJh ZnQgIGxhY2tzICBvZiAgdGhpcyAgYWx0aG91Z2ggIHRoaXMNCj4gIGlzICBoaWdobGlnaHRlZCAg aW4gIHRoZSAgUFMuDQoNCk1ha2VzICBzZW5zZS4gICAgV2UgIGNhbiAgYWRkICBhICByZWZlcmVu Y2UgIHRvICB0aGlzICBkaXNjdXNzaW9uICBpbiAgdGhlICBwcm9ibGVtDQpzdGF0ZW1lbnQgIGlu ICB0aGUgIGludHJvZHVjdGlvbi4NCg0KPg0KPiAgNC4gICAgRGF0YSAgU2VhcmNoICBDYXBhYmls aXR5ICBkZXNjcmliZWQgIGluICBzZWN0aW9uICAzLjMgIHNlZW1zICBpcnJlbGV2YW50ICB0bw0K PiAgREVDQURFICBwcm90b2NvbHMuDQoNCkkgIGFncmVlICB0aGF0ICBtb3N0ICAoaWYgIG5vdCAg YWxsKSAgYXNwZWN0cyAgb2YgICJTZWFyY2giICBjb3VsZCAgcmVzaWRlDQpvdXRzaWRlICBvZiAg REVDQURFLCAgYnV0ICBJICB0aGluayAgaXQgIHN0aWxsICBtYWtlcyAgc2Vuc2UgIHRvICBjb3Zl ciAgdGhlbSAgaW4NCnRoZSAgc3VydmV5LiAgICBBdCAgdGhlICB2ZXJ5ICBsZWFzdCwgIGl0ICBj YW4gIGhpZ2hsaWdodCAgdGhlICBkaWZmZXJlbnQNCmZlYXR1cmVzICBmb3IgIGVhY2ggIHN0b3Jh Z2UgIHN5c3RlbSwgIHBhcnRpY3VsYXIgIHRoZSAgZGlzdHJpYnV0ZWQgIG9uZXMuDQpTb21lICBh ZGRpdGlvbmFsICBkaXNjdXNzaW9uICBpbiAgdGhlICAiT2JzZXJ2YXRpb25zIiAgc2VjdGlvbiAg Y291bGQgIHRhbGsNCmFib3V0ICB0aGlzLg0KDQpJdCdzIGFsc28gb2theSB0byBzdGF0ZSBjbGVh cmx5IHRoaXMgcGFydCBpcyBvdXQgb2YgREVDQURFIHNjb3BlLg0KDQo+DQo+ICA1LiAgICBJbiAg c2VjdGlvbiAgMy44ICB0aGUgIGF1dGhvcnMgIHByb3Bvc2UgIHRocmVlICB0eXBlcyAgb2YgIHN0 b3JhZ2UgIG1vZGVzICB3aXRob3V0DQo+ICBleHBsaWNpdCAgZGVzY3JpcHRpb24uICBBbmQgIHRo ZSAgZm9sbG93aW5nICBlY2hvZXMgIGluICBzZWN0aW9uICA0ICBzdGlsbCAgcG9zZSAgYW4NCj4N Cj4gICAgICAgICAgICBhbWJpZ3VvdXMgIGltYWdlICBlc3AuICBiZXR3ZWVuICBmaWxlICBhbmQg IG9iamVjdCAgb3JpZW50ZWQgIG1vZGUuDQoNCkFncmVlZCAgdGhhdCAgdGhlICBkcmFmdCAgc2hv dWxkICBkZWZpbmUgIHRoZSAgdGVybXMsICBhbmQgIHRoYXQgIHdlICBzaG91bGQNCmNsYXJpZnkg IHRoZSAgZGlzdGluY3Rpb24gIGJldHdlZW4gICJmaWxlLWJhc2VkIiAgYW5kICAib2JqZWN0LWJh c2VkIg0KKHBlcmhhcHMgIGJ5ICByZW5hbWluZyAgImZpbGUtYmFzZWQiICB0byAgc29tZXRoaW5n ICBsaWtlICAiaGllcmFyY2hpY2FsDQpmaWxlc3lzdGVtIiAgb3IgICJkaXJlY3RvcnktYmFzZWQi KS4NCg0KVGhhbmtzICBhZ2FpbiAgZm9yICB0aGUgIHJldmlldyENClJpY2gNCg== --=====003_Dragon813565022156_===== Content-Transfer-Encoding: base64 Content-Type: text/html; charset="gb2312" PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWdiMjMxMiI+DQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNi4w MC42MDAwLjE3MDgwIiBuYW1lPUdFTkVSQVRPUj4NCjxTVFlMRT4NCjwhLS0NCiAvKiBGb250IERl ZmluaXRpb25zICovDQogQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTrLzszlOw0KCXBhbm9zZS0x OjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpWZXJkYW5h Ow0KCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1m YW1pbHk6IlxAy87M5SI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQogLyogU3R5 bGUgRGVmaW5pdGlvbnMgKi8NCiBwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9y bWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCXRleHQtYWxpZ246 anVzdGlmeTsNCgl0ZXh0LWp1c3RpZnk6aW50ZXItaWRlb2dyYXBoOw0KCWZvbnQtc2l6ZToxMC41 cHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5 cGVybGluaw0KCXtjb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2 aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe2NvbG9yOnB1cnBsZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10 eXBlOnBlcnNvbmFsLWNvbXBvc2U7DQoJZm9udC1mYW1pbHk6VmVyZGFuYTsNCgljb2xvcjp3aW5k b3d0ZXh0Ow0KCWZvbnQtd2VpZ2h0Om5vcm1hbDsNCglmb250LXN0eWxlOm5vcm1hbDsNCgl0ZXh0 LWRlY29yYXRpb246bm9uZSBub25lO30NCiAvKiBQYWdlIERlZmluaXRpb25zICovDQogQHBhZ2Ug U2VjdGlvbjENCgl7c2l6ZTo1OTUuM3B0IDg0MS45cHQ7DQoJbWFyZ2luOjcyLjBwdCA5MC4wcHQg NzIuMHB0IDkwLjBwdDsNCglsYXlvdXQtZ3JpZDoxNS42cHQ7fQ0KZGl2LlNlY3Rpb24xDQoJe3Bh Z2U6U2VjdGlvbjE7fQ0KLS0+DQo8L1NUWUxFPg0KPC9IRUFEPg0KPEJPRFk+DQo8RElWPjxGT05U IGZhY2U9VmVyZGFuYSBjb2xvcj0jMDAwMGZmIHNpemU9Mj5IaSBSaWNoLDwvRk9OVD48L0RJVj4N CjxESVY+PEZPTlQgZmFjZT1WZXJkYW5hIGNvbG9yPSMwMDAwZmYgc2l6ZT0yPiZuYnNwOyZuYnNw OyBIYXBweSBuZXcgeWVhciBhbmQgDQpwbGVhc2Ugc2VlIGlubGluZSBmb3IgdGhlIGRldGFpbC48 L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9VmVyZGFuYSBjb2xvcj0jMDAwMGZmIHNpemU9 Mj5CUjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1WZXJkYW5hIGNvbG9yPSMwMDAwZmYg c2l6ZT0yPll1bmZlaTwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1WZXJkYW5hIHNpemU9 Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWIGFsaWduPWxlZnQ+DQo8RElWIGFsaWduPWxlZnQ+ PEZPTlQgZmFjZT1WZXJkYW5hIHNpemU9Mj4NCjxIUiBzdHlsZT0iV0lEVEg6IDEyMnB4OyBIRUlH SFQ6IDJweCIgU0laRT0yPg0KPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBjb2xvcj0jYzBjMGMw PjxGT05UIGZhY2U9VmVyZGFuYSBzaXplPTI+emhhbmd5dW5mZWk8L0ZPTlQ+PC9ESVY+DQo8RElW PjxGT05UIGZhY2U9VmVyZGFuYSBzaXplPTI+MjAxMS0wMS0wNDwvRk9OVD48L0ZPTlQ+PC9ESVY+ PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9VmVyZGFuYSBzaXplPTI+DQo8SFI+DQo8L0ZPTlQ+PC9E SVY+DQo8RElWPjxGT05UIGZhY2U9VmVyZGFuYT48Rk9OVCBzaXplPTI+PFNUUk9ORz63orz+yMuj ujwvU1RST05HPiBSaWNoYXJkIA0KQWxpbWk8L0ZPTlQ+PC9GT05UPjwvRElWPg0KPERJVj48Rk9O VCBmYWNlPVZlcmRhbmE+PEZPTlQgc2l6ZT0yPjxTVFJPTkc+t6LLzcqxvOSjujwvU1RST05HPiAN CjIwMTEtMDEtMDQmbmJzcDswNzozNDowMjwvRk9OVD48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05U IGZhY2U9VmVyZGFuYT48Rk9OVCBzaXplPTI+PFNUUk9ORz7K1bz+yMujujwvU1RST05HPiANCnpo YW5neXVuZmVpPC9GT05UPjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1WZXJkYW5hPjxG T05UIHNpemU9Mj48U1RST05HPrOty82jujwvU1RST05HPiANCmRlY2FkZUBpZXRmLm9yZzwvRk9O VD48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9VmVyZGFuYT48Rk9OVCBzaXplPTI+PFNU Uk9ORz7W98zio7o8L1NUUk9ORz4gUmU6IFtkZWNhZGVdIFdHIA0KUmV2aWV3cyBvZiB0aGUgRGVj YWRlIFN1cnZleSBkcmFmdDwvRk9OVD48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9VmVy ZGFuYSBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPVZlcmRhbmEg c2l6ZT0yPg0KPERJVj5IaSAmbmJzcDtZdW5mZWksPC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0K PERJVj5UaGFuayAmbmJzcDt5b3UgJm5ic3A7Zm9yICZuYnNwO3RoZSAmbmJzcDtyZXZpZXcuICZu YnNwO1NvbWUgDQombmJzcDtyZXNwb25zZXMgJm5ic3A7aW5saW5lOjwvRElWPg0KPERJVj4mbmJz cDs8L0RJVj4NCjxESVY+MjAxMC8xMi8yNyAmbmJzcDt6aGFuZ3l1bmZlaSAmbmJzcDsgJmx0O3po YW5neXVuZmVpQGNoaW5hbW9iaWxlLmNvbSANCiZndDs6PC9ESVY+DQo8RElWPiZndDsgJm5ic3A7 Rmlyc3QgJm5ic3A7b2YgJm5ic3A7YWxsICZuYnNwO2hhcHB5ICZuYnNwO25ldyAmbmJzcDt5ZWFy IA0KJm5ic3A7dG8gJm5ic3A7ZXZlcnlib2R5ITwvRElWPg0KPERJVj4mZ3Q7PC9ESVY+DQo8RElW PiZndDs8L0RJVj4NCjxESVY+Jmd0OzwvRElWPg0KPERJVj4mZ3Q7ICZuYnNwO1RoZSAmbmJzcDtm b2xsb3dpbmcgJm5ic3A7aXMgJm5ic3A7bXkgJm5ic3A7V0cgJm5ic3A7cmV2aWV3IA0KJm5ic3A7 b2YgJm5ic3A7ZHJhZnQtaWV0Zi1kZWNhZGUtc3VydmV5LTAyLjwvRElWPg0KPERJVj4mZ3Q7PC9E SVY+DQo8RElWPiZndDs8L0RJVj4NCjxESVY+Jmd0OzwvRElWPg0KPERJVj4mZ3Q7ICZuYnNwO1N1 bW1hcnk6PC9ESVY+DQo8RElWPiZndDs8L0RJVj4NCjxESVY+Jmd0OzwvRElWPg0KPERJVj4mZ3Q7 PC9ESVY+DQo8RElWPiZndDsgJm5ic3A7VGhpcyAmbmJzcDtkb2N1bWVudCAmbmJzcDtzdXJ2ZXlz ICZuYnNwO3Rob3JvdWdobHkgDQombmJzcDtkZXBsb3llZCwgJm5ic3A7ZXhwZXJpbWVudGFsICZu YnNwO2FuZCAmbmJzcDtvbi1yZXNlYXJjaDwvRElWPg0KPERJVj4mZ3Q7ICZuYnNwO2luLW5ldHdv cmsgJm5ic3A7c3RvcmFnZSAmbmJzcDthbmQgJm5ic3A7Y2FjaGUgJm5ic3A7c3lzdGVtcy8gDQom bmJzcDtzdWItc3lzdGVtczwvRElWPg0KPERJVj4mZ3Q7PC9ESVY+DQo8RElWPiZndDsgJm5ic3A7 YW5kICZuYnNwO2Rlc2NyaWJlcyAmbmJzcDt0aGVpciAmbmJzcDthcHBsaWNhYmlsaXR5ICZuYnNw O2ZvciANCiZuYnNwO0RFQ0FERS4gJm5ic3A7SXQgJm5ic3A7cHJvdmlkZXMgJm5ic3A7cmljaCAm bmJzcDtyZWZlcmVuY2VzPC9ESVY+DQo8RElWPiZndDsgJm5ic3A7Zm9yICZuYnNwO2tub3dpbmcg Jm5ic3A7d2hhdCAmbmJzcDt0aGUgJm5ic3A7ZXhpc3RpbmcgDQombmJzcDtzeXN0ZW1zICZuYnNw O2hhdmUgJm5ic3A7YW5kPC9ESVY+DQo8RElWPiZndDs8L0RJVj4NCjxESVY+Jmd0OyAmbmJzcDt3 aGF0ICZuYnNwO3RoZXkgJm5ic3A7bGFjayAmbmJzcDtvZi4gJm5ic3A7VGhlcmVmb3JlICZuYnNw O3RoZSANCiZuYnNwO2Rlc2lnbmluZyAmbmJzcDtzcGFjZSAmbmJzcDtvZiAmbmJzcDtERUNBREUg Jm5ic3A7aXMgJm5ic3A7ZXhwbGljYXRlZCANCiZuYnNwO2ZvcjwvRElWPg0KPERJVj4mZ3Q7ICZu YnNwO2JldHRlciAmbmJzcDt1bmRlcnN0YW5kaW5nLiAmbmJzcDtUaGUgJm5ic3A7ZHJhZnQgJm5i c3A7aXMgDQombmJzcDt3ZWxsICZuYnNwO3dyaXR0ZW4gJm5ic3A7YW5kPC9ESVY+DQo8RElWPiZn dDs8L0RJVj4NCjxESVY+Jmd0OyAmbmJzcDtjb252ZXlzICZuYnNwO3RoZSAmbmJzcDtncm91cCdz ICZuYnNwO2ludGVudCAmbmJzcDt3ZWxsLjwvRElWPg0KPERJVj4mZ3Q7PC9ESVY+DQo8RElWPiZn dDsgJm5ic3A7VGhlICZuYnNwO2F1dGhvcnMgJm5ic3A7YXJlICZuYnNwO3N1Z2dlc3RlZCAmbmJz cDt0byANCiZuYnNwO2NhdGVnb3JpemUgJm5ic3A7dGhlICZuYnNwO3N1cnZleWVkICZuYnNwO3N5 c3RlbXMvc3ViLXN5c3RlbXMgDQombmJzcDthczwvRElWPg0KPERJVj4mZ3Q7ICZuYnNwO3VzZXIt Y29udHJvbGxlZCAmbmJzcDsoaW5kaXZpZHVhbCkgJm5ic3A7c2VydmljZXMgJm5ic3A7KGluIA0K Jm5ic3A7c2NvcGUgJm5ic3A7b2YgJm5ic3A7REVDQURFKTwvRElWPg0KPERJVj4mZ3Q7PC9ESVY+ DQo8RElWPiZndDsgJm5ic3A7YW5kICZuYnNwO25ldHdvcmstY29udHJvbGxlZCAmbmJzcDsobWFz cykgJm5ic3A7c2VydmljZXMgDQombmJzcDsob3V0ICZuYnNwO29mICZuYnNwO3Njb3BlICZuYnNw O29mICZuYnNwO0RFQ0FERSkgJm5ic3A7dG8gJm5ic3A7bWFrZSANCiZuYnNwO2l0PC9ESVY+DQo8 RElWPiZndDsgJm5ic3A7bW9yZSAmbmJzcDtmb2N1cyAmbmJzcDtvbiAmbmJzcDtERUNBREUgJm5i c3A7dHlwZSANCiZuYnNwO3NlcnZpY2VzLjwvRElWPg0KPERJVj4mZ3Q7PC9ESVY+DQo8RElWPiZn dDs8L0RJVj4NCjxESVY+Jmd0OzwvRElWPg0KPERJVj4mZ3Q7ICZuYnNwO1NwZWNpZmljICZuYnNw O2NvbW1lbnRzICZuYnNwO2FuZCAmbmJzcDtjb25jZXJuczo8L0RJVj4NCjxESVY+Jmd0OzwvRElW Pg0KPERJVj4mZ3Q7ICZuYnNwOzGjriAmbmJzcDsgJm5ic3A7VGhlICZuYnNwO29yZ2FuaXphdGlv biAmbmJzcDtvZiAmbmJzcDtzZWN0aW9uIA0KJm5ic3A7NDogJm5ic3A7SW4gJm5ic3A7dGhpcyAm bmJzcDtzZWN0aW9uICZuYnNwO3RoZSAmbmJzcDthdXRob3JzIA0KJm5ic3A7c3VydmV5PC9ESVY+ DQo8RElWPiZndDsgJm5ic3A7dGhvcm91Z2hseSAmbmJzcDtkZXBsb3llZCwgJm5ic3A7ZXhwZXJp bWVudGFsICZuYnNwO2FuZCANCiZuYnNwO29uLXJlc2VhcmNoICZuYnNwO2luLW5ldHdvcmsgJm5i c3A7c3RvcmFnZTwvRElWPg0KPERJVj4mZ3Q7PC9ESVY+DQo8RElWPiZndDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7YW5kICZuYnNwO2NhY2hlIA0KJm5i c3A7c3lzdGVtcy8gJm5ic3A7c3ViLXN5c3RlbXMuICZuYnNwO0hvd2V2ZXIgJm5ic3A7c29tZSAm bmJzcDtvZiAmbmJzcDt0aGVtIA0KJm5ic3A7YXJlPC9ESVY+DQo8RElWPiZndDsgJm5ic3A7dXNl ci1jb250cm9sbGVkICZuYnNwOyhpbmRpdmlkdWFsKSAmbmJzcDtzZXJ2aWNlcyAmbmJzcDtsaWtl IA0KJm5ic3A7c2VjdGlvbiAmbmJzcDs0LjEsICZuYnNwOzQuMiw0LjksNC4xMCAmbmJzcDthbmQ8 L0RJVj4NCjxESVY+Jmd0OzwvRElWPg0KPERJVj4mZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7cGFydCAmbmJzcDtvZiAmbmJzcDs0LjEyLCANCiZuYnNwO3doaWNo ICZuYnNwO2FyZSAmbmJzcDtpbiAmbmJzcDtzY29wZSAmbmJzcDtvZiAmbmJzcDtERUNBREU7ICZu YnNwO290aGVycyANCiZuYnNwO2FyZSAmbmJzcDtuZXR3b3JrPC9ESVY+DQo8RElWPiZndDsgJm5i c3A7Y29udHJvbGxlZChtYXNzKSAmbmJzcDtzZXJ2aWNlcyAmbmJzcDt3aGVyZSAmbmJzcDt0aGUg DQombmJzcDt1c2VycyAmbmJzcDtoYXZlICZuYnNwO25vICZuYnNwO3JpZ2h0cyAmbmJzcDt0byAm bmJzcDtvcGVyYXRlPC9ESVY+DQo8RElWPiZndDs8L0RJVj4NCjxESVY+Jmd0OyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7dGhlICZuYnNwO2luLW5ldHdvcmsgJm5ic3A7c3RvcmFn ZSANCiZuYnNwO29yICZuYnNwO2NhY2hlcywgJm5ic3A7d2hpY2ggJm5ic3A7YXJlICZuYnNwO291 dCAmbmJzcDtvZiAmbmJzcDtzY29wZSANCiZuYnNwO29mICZuYnNwO0RFQ0FERS4gJm5ic3A7VGhl PC9ESVY+DQo8RElWPiZndDsgJm5ic3A7Y3VycmVudCAmbmJzcDtvcmdhbml6YXRpb24gJm5ic3A7 aXMgJm5ic3A7YSAmbmJzcDtsaXR0bGUgDQombmJzcDtiaXQgJm5ic3A7bWVzc3kgJm5ic3A7YW5k ICZuYnNwO2l0J3MgJm5ic3A7c3VnZ2VzdGVkPC9ESVY+DQo8RElWPiZndDs8L0RJVj4NCjxESVY+ Jmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7dG8gJm5ic3A7c2VwYXJhdGUg Jm5ic3A7dGhlIA0KJm5ic3A7dHdvICZuYnNwO3BhcnRzICZuYnNwO2FuZCAmbmJzcDtmb2N1cyAm bmJzcDtvbiAmbmJzcDt0aGUgJm5ic3A7REVDQURFIA0KJm5ic3A7dHlwZSAmbmJzcDtzZXJ2aWNl cy48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPkkgJm5ic3A7d291bGQgJm5ic3A7YWdy ZWUgJm5ic3A7dGhhdCAmbmJzcDtTZWN0aW9uICZuYnNwOzQgJm5ic3A7aXMgDQombmJzcDtzb21l d2hhdCAmbmJzcDtsb25nICZuYnNwO2FuZCAmbmJzcDt0aGF0ICZuYnNwO2l0ICZuYnNwO3dvdWxk IA0KJm5ic3A7YmU8L0RJVj4NCjxESVY+Z29vZCAmbmJzcDt0byAmbmJzcDtoYXZlICZuYnNwO3N1 YmNhdGVnb3JpZXMgJm5ic3A7Zm9yICZuYnNwO3RoZSANCiZuYnNwO3N5c3RlbXMuICZuYnNwOyAm bmJzcDtUaGlzICZuYnNwO2hhcyAmbmJzcDtiZWVuICZuYnNwO2Rpc2N1c3NlZCANCiZuYnNwO2E8 L0RJVj4NCjxESVY+Y291cGxlICZuYnNwO29mICZuYnNwO3RpbWVzICZuYnNwO2Ftb25nc3QgJm5i c3A7dGhlICZuYnNwO2F1dGhvcnMgJm5ic3A7YnV0IA0KJm5ic3A7aXQgJm5ic3A7d2FzICZuYnNw O3VuY2xlYXIgJm5ic3A7YXMgJm5ic3A7dG8gJm5ic3A7dGhlPC9ESVY+DQo8RElWPnByb3BlciAm bmJzcDt3YXkgJm5ic3A7dG8gJm5ic3A7ZG8gJm5ic3A7c3VjaCAmbmJzcDthICZuYnNwO2NhdGVn b3JpemF0aW9uLiANCiZuYnNwOyAmbmJzcDtGb3IgJm5ic3A7ZXhhbXBsZSwgJm5ic3A7eW91cjwv RElWPg0KPERJVj5jbGFzc2lmaWNhdGlvbiAmbmJzcDthYm92ZSwgJm5ic3A7d2h5ICZuYnNwO2lz ICZuYnNwO0JyYW5jaENhY2hlIA0KJm5ic3A7KDQuMik8L0RJVj4NCjxESVY+dXNlci1jb250cm9s bGVkL2luZGl2aWR1YWw/ICZuYnNwOyAmbmJzcDtTMyAmbmJzcDtjYW4gJm5ic3A7Ym90aCAmbmJz cDtiZSANCiZuYnNwO3VzZWQgJm5ic3A7Zm9yICZuYnNwO2luZGl2aWR1YWwgJm5ic3A7YW5kPC9E SVY+DQo8RElWPm1hc3MgJm5ic3A7dXNhZ2UuICZuYnNwOyAmbmJzcDtJdCAmbmJzcDtzZWVtZWQg Jm5ic3A7dGhhdCAmbmJzcDthbnkgDQombmJzcDthdHRlbXB0ICZuYnNwO2F0ICZuYnNwO2NhdGVn b3JpemF0aW9uICZuYnNwO3RoYXQgJm5ic3A7d2UndmU8L0RJVj4NCjxESVY+ZGlzY3Vzc2VkICZu YnNwO3RodXMgJm5ic3A7ZmFyICZuYnNwO2hhcyAmbmJzcDtjb3VudGVyZXhhbXBsZXMgJm5ic3A7 d2hpY2ggDQombmJzcDt3b3VsZCAmbmJzcDtiZSAmbmJzcDtkZWJhdGFibGUgJm5ic3A7YnkgJm5i c3A7YTwvRElWPg0KPERJVj5yZWFkZXIuPC9ESVY+DQo8RElWPg0KPERJVj48Rk9OVCBjb2xvcj0j ZmYwMDAwPkkgbWFrZSB0aGUgYXR0ZW1wdCB0byBjYXRlZ29yaXplIHRoZSBzeXN0ZW1zIGFjY29y ZGluZyANCnRvIHRoZSB0ZXh0IGFuZCBteSB1bmRlcnN0YW5kaW5nLjwvRk9OVD48L0RJVj4NCjxE SVY+PEZPTlQgY29sb3I9I2ZmMDAwMD5JdCdzIHJlYWxseSBhIGhhcmQgam9iIHRvIHNvbHZlIHRo ZSBtYXRyaXggDQpwZXJmZWN0bHkuPC9GT05UPjwvRElWPjwvRElWPg0KPERJVj4mbmJzcDs8L0RJ Vj4NCjxESVY+VG8gJm5ic3A7bWUsICZuYnNwO2l0ICZuYnNwO3NlZW1zICZuYnNwO2EgJm5ic3A7 cHJvcGVyICZuYnNwO3dheSAmbmJzcDt0byANCiZuYnNwO2NhdGVnb3JpemUgJm5ic3A7dGhlbSAm bmJzcDt3b3VsZCAmbmJzcDtiZSAmbmJzcDthICZuYnNwO2ZlYXR1cmU8L0RJVj4NCjxESVY+bWF0 cml4LCAmbmJzcDtidXQgJm5ic3A7dGhhdCAmbmJzcDtkb2Vzbid0ICZuYnNwO3dvcmsgJm5ic3A7 d2VsbCAmbmJzcDt3aXRoIA0KJm5ic3A7dGhlICZuYnNwO2hpZXJhcmNoaWNhbCAmbmJzcDtzZWN0 aW9ucyAmbmJzcDtvZjwvRElWPg0KPERJVj50aGUgJm5ic3A7ZG9jdW1lbnQuPC9ESVY+DQo8RElW PiZuYnNwOzwvRElWPg0KPERJVj5XZSAmbmJzcDthcmUgJm5ic3A7bW9yZSAmbmJzcDt0aGFuICZu YnNwO2hhcHB5ICZuYnNwO3RvICZuYnNwO2Rpc2N1c3MgDQombmJzcDt0aGlzICZuYnNwO2FnYWlu ICZuYnNwO2Ftb25nc3QgJm5ic3A7dGhlICZuYnNwO2F1dGhvcnMsICZuYnNwO2J1dDwvRElWPg0K PERJVj5kbyAmbmJzcDt5b3UgJm5ic3A7aGF2ZSAmbmJzcDtzb21lICZuYnNwO2FkZGl0aW9uYWwg Jm5ic3A7aWRlYXMgJm5ic3A7b24gDQombmJzcDthbiAmbmJzcDthcHByb3ByaWF0ZSAmbmJzcDtz Y2hlbWU/PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBjb2xvcj0jZmYwMDAw PlNvdW5kIGdvb2QgYW5kIEknbGwgbGV0IHlvdSBrbm93IGlmIEkgaGF2ZSBnb29kIGlkZWFzIA0K b24gc29sdmluZyB0aGlzLjwvRk9OVD48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPiZn dDs8L0RJVj4NCjxESVY+Jmd0OyAmbmJzcDsyo64gJm5ic3A7ICZuYnNwO0RpZmZlcmVuY2UgJm5i c3A7YmV0d2VlbiAmbmJzcDtjYWNoZSAmbmJzcDthbmQgDQombmJzcDtzdG9yYWdlOiAmbmJzcDtJ biAmbmJzcDtzZWN0aW9uICZuYnNwOzQsICZuYnNwO3RoZXJlICZuYnNwO2FyZSANCiZuYnNwO21h bnk8L0RJVj4NCjxESVY+Jmd0OyAmbmJzcDtwbGFjZXMgJm5ic3A7dG8gJm5ic3A7bWVudGlvbiAm bmJzcDtpbi1uZXR3b3JrICZuYnNwO2NhY2hlcy4gDQombmJzcDtJbiAmbmJzcDtuZXR3b3JrLWNv bnRyb2xsZWQ8L0RJVj4NCjxESVY+Jmd0OzwvRElWPg0KPERJVj4mZ3Q7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Y2FjaGVzLCAmbmJzcDtpdCdzICZuYnNwO2hhcmQg DQombmJzcDt0byAmbmJzcDtpbnRyb2R1Y2UgJm5ic3A7REVDQURFICZuYnNwO3NlcnZpY2UgJm5i c3A7YmVjYXVzZSAmbmJzcDtzb21lIA0KJm5ic3A7b2YgJm5ic3A7dGhlPC9ESVY+DQo8RElWPiZn dDsgJm5ic3A7b3BlcmF0aW9ucyAmbmJzcDtkZWZpbmVkICZuYnNwO2luICZuYnNwO0RFQ0FERSAm bmJzcDtsaWtlIA0KJm5ic3A7ZGF0YSAmbmJzcDtkZWxldGlvbiAmbmJzcDtpbiAmbmJzcDtERUNB REU8L0RJVj4NCjxESVY+Jmd0OzwvRElWPg0KPERJVj4mZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7c2VydmVyICZuYnNwOyhpZiAmbmJzcDt3ZSANCiZuYnNwO3Vz ZSAmbmJzcDt0aGUgJm5ic3A7Y3VycmVudCAmbmJzcDtjYWNoZSAmbmJzcDthcyAmbmJzcDt0aGUg Jm5ic3A7REVDQURFIA0KJm5ic3A7c2VydmVyKSAmbmJzcDttYXkgJm5ic3A7cmFpc2U8L0RJVj4N CjxESVY+Jmd0OyAmbmJzcDtjb25mbGljdGlvbiAmbmJzcDt3aXRoICZuYnNwO3RoZSAmbmJzcDtl eGlzdGluZyAmbmJzcDtjYWNoZSANCiZuYnNwO3VwZGF0ZSAmbmJzcDttZWNoYW5pc208L0RJVj4N CjxESVY+Jmd0OzwvRElWPg0KPERJVj4mZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7YnkgJm5ic3A7Q2FjaGUgDQombmJzcDtvcGVyYXRvcnMgJm5ic3A7d2hlbiAm bmJzcDtkZWFsaW5nICZuYnNwO3dpdGggJm5ic3A7YSAmbmJzcDtjZXJ0YWluIA0KJm5ic3A7ZGF0 YS4gJm5ic3A7SW4gJm5ic3A7c2VjdGlvbiAmbmJzcDs0LjE0PC9ESVY+DQo8RElWPiZndDsgJm5i c3A7dGhlICZuYnNwO2F1dGhvcnMgJm5ic3A7c3RhdGUgJm5ic3A7dGhlICZuYnNwO3Bvc3NpYmxl IA0KJm5ic3A7aW5hcHBsaWNhYmlsaXR5ICZuYnNwO2ZvciAmbmJzcDt0aGUgJm5ic3A7Y2FjaGUg Jm5ic3A7c2NlbmFyaW9zPC9ESVY+DQo8RElWPiZndDs8L0RJVj4NCjxESVY+Jmd0OyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2luICZuYnNwO3VzaW5nICZuYnNwO0RF Q0FERSANCiZuYnNwO21lY2hhbmlzbS4gJm5ic3A7QnV0ICZuYnNwO3RvICZuYnNwO21ha2UgJm5i c3A7dGhlICZuYnNwO2RyYWZ0ICZuYnNwO21vcmUgDQombmJzcDtjbGVhciwgJm5ic3A7aXQnczwv RElWPg0KPERJVj4mZ3Q7ICZuYnNwO2JldHRlciAmbmJzcDt0byAmbmJzcDtzdGF0ZSAmbmJzcDtl eHBsaWNpdCAmbmJzcDt0aGUgJm5ic3A7c2NvcGUgDQombmJzcDtvZiAmbmJzcDtERUNBREUgJm5i c3A7YWhlYWQgJm5ic3A7b2YgJm5ic3A7dGhpcyAmbmJzcDtzZWN0aW9uLjwvRElWPg0KPERJVj4m Z3Q7PC9ESVY+DQo8RElWPiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO0Fu ZCAmbmJzcDthbHNvICZuYnNwO21vcmUgDQombmJzcDtkaXNjdXNzaW9ucyAmbmJzcDtvbiAmbmJz cDt3aGV0aGVyICZuYnNwO2FuZCAmbmJzcDtob3cgJm5ic3A7bXVjaCANCiZuYnNwO2RlZ3JlZSAm bmJzcDt3ZSAmbmJzcDtuZWVkICZuYnNwO3RoZTwvRElWPg0KPERJVj4mZ3Q7ICZuYnNwO2NhY2hl ICZuYnNwO3N5c3RlbS9zdWJzeXN0ZW0gJm5ic3A7ZGVzY3JpcHRpb24gJm5ic3A7aW4gDQombmJz cDt0aGlzICZuYnNwO2RyYWZ0ICZuYnNwO2FyZSAmbmJzcDtuZWVkZWQgJm5ic3A7aW4gJm5ic3A7 dGhlIA0KJm5ic3A7Z3JvdXAuPC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj5UaGF0ICZu YnNwO21ha2VzICZuYnNwO3NlbnNlLiAmbmJzcDtJZiAmbmJzcDt0aGUgJm5ic3A7c2VjdGlvbiAm bmJzcDs0LjE0IA0KJm5ic3A7b2YgJm5ic3A7dGhlICZuYnNwO1N1cnZleSAmbmJzcDtkcmFmdCAm bmJzcDtpcyAmbmJzcDt1cGRhdGVkPC9ESVY+DQo8RElWPnRvICZuYnNwO3JlZmVyZW5jZSAmbmJz cDt0aGUgJm5ic3A7c2NvcGUgJm5ic3A7REVDQURFICZuYnNwOyhwZXJoYXBzIA0KJm5ic3A7dmlh ICZuYnNwO2EgJm5ic3A7cmVmZXJlbmNlICZuYnNwO3RvICZuYnNwO3RoZSAmbmJzcDtwcm9ibGVt PC9ESVY+DQo8RElWPnN0YXRlbWVudCksICZuYnNwO2RvICZuYnNwO3lvdSAmbmJzcDt0aGluayAm bmJzcDtpdCAmbmJzcDt3b3VsZCAmbmJzcDtzZXJ2ZSANCiZuYnNwO2FzICZuYnNwO2dvb2QgJm5i c3A7aW5wdXQgJm5ic3A7dG8gJm5ic3A7dGhhdDwvRElWPg0KPERJVj5kaXNjdXNzaW9uPzwvRElW Pg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgY29sb3I9I2ZmMDAwMD5ZZXMsIGl0IHdv dWxkIGJlLjwvRk9OVD48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPiZndDsgJm5ic3A7 My4gJm5ic3A7ICZuYnNwO0luICZuYnNwO3NlY3Rpb24gJm5ic3A7MiwgJm5ic3A7dGhlICZuYnNw O05vLjEgDQombmJzcDtlZmZlY3QgJm5ic3A7b2YgJm5ic3A7REVDQURFLCAmbmJzcDt0byAmbmJz cDtteSAmbmJzcDt1bmRlcnN0YW5kaW5nLCANCiZuYnNwO2lzICZuYnNwO3RvPC9ESVY+DQo8RElW PiZndDsgJm5ic3A7aW1wcm92ZSAmbmJzcDtQMlAgJm5ic3A7YXBwbGljYXRpb24gJm5ic3A7ZXhw ZXJpZW5jZSAmbmJzcDtpbiANCiZuYnNwO3VwLWJhbmQgJm5ic3A7Y29uc3RyYWludCAmbmJzcDtl bnZpcm9ubWVudCAmbmJzcDtsaWtlPC9ESVY+DQo8RElWPiZndDs8L0RJVj4NCjxESVY+Jmd0OyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Y2VsbHVsYXIgJm5ic3A7bW9iaWxlIA0K Jm5ic3A7bmV0d29ya3MuICZuYnNwO1RoZSAmbmJzcDtjdXJyZW50ICZuYnNwO2RyYWZ0ICZuYnNw O2xhY2tzICZuYnNwO29mIA0KJm5ic3A7dGhpcyAmbmJzcDthbHRob3VnaCAmbmJzcDt0aGlzPC9E SVY+DQo8RElWPiZndDsgJm5ic3A7aXMgJm5ic3A7aGlnaGxpZ2h0ZWQgJm5ic3A7aW4gJm5ic3A7 dGhlICZuYnNwO1BTLjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+TWFrZXMgJm5ic3A7 c2Vuc2UuICZuYnNwOyAmbmJzcDtXZSAmbmJzcDtjYW4gJm5ic3A7YWRkICZuYnNwO2EgDQombmJz cDtyZWZlcmVuY2UgJm5ic3A7dG8gJm5ic3A7dGhpcyAmbmJzcDtkaXNjdXNzaW9uICZuYnNwO2lu ICZuYnNwO3RoZSANCiZuYnNwO3Byb2JsZW08L0RJVj4NCjxESVY+c3RhdGVtZW50ICZuYnNwO2lu ICZuYnNwO3RoZSAmbmJzcDtpbnRyb2R1Y3Rpb24uPC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0K PERJVj4mZ3Q7PC9ESVY+DQo8RElWPiZndDsgJm5ic3A7NC4gJm5ic3A7ICZuYnNwO0RhdGEgJm5i c3A7U2VhcmNoICZuYnNwO0NhcGFiaWxpdHkgDQombmJzcDtkZXNjcmliZWQgJm5ic3A7aW4gJm5i c3A7c2VjdGlvbiAmbmJzcDszLjMgJm5ic3A7c2VlbXMgJm5ic3A7aXJyZWxldmFudCANCiZuYnNw O3RvPC9ESVY+DQo8RElWPiZndDsgJm5ic3A7REVDQURFICZuYnNwO3Byb3RvY29scy48L0RJVj4N CjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPkkgJm5ic3A7YWdyZWUgJm5ic3A7dGhhdCAmbmJzcDtt b3N0ICZuYnNwOyhpZiAmbmJzcDtub3QgJm5ic3A7YWxsKSANCiZuYnNwO2FzcGVjdHMgJm5ic3A7 b2YgJm5ic3A7IlNlYXJjaCIgJm5ic3A7Y291bGQgJm5ic3A7cmVzaWRlPC9ESVY+DQo8RElWPm91 dHNpZGUgJm5ic3A7b2YgJm5ic3A7REVDQURFLCAmbmJzcDtidXQgJm5ic3A7SSAmbmJzcDt0aGlu ayAmbmJzcDtpdCANCiZuYnNwO3N0aWxsICZuYnNwO21ha2VzICZuYnNwO3NlbnNlICZuYnNwO3Rv ICZuYnNwO2NvdmVyICZuYnNwO3RoZW0gDQombmJzcDtpbjwvRElWPg0KPERJVj50aGUgJm5ic3A7 c3VydmV5LiAmbmJzcDsgJm5ic3A7QXQgJm5ic3A7dGhlICZuYnNwO3ZlcnkgJm5ic3A7bGVhc3Qs IA0KJm5ic3A7aXQgJm5ic3A7Y2FuICZuYnNwO2hpZ2hsaWdodCAmbmJzcDt0aGUgJm5ic3A7ZGlm ZmVyZW50PC9ESVY+DQo8RElWPmZlYXR1cmVzICZuYnNwO2ZvciAmbmJzcDtlYWNoICZuYnNwO3N0 b3JhZ2UgJm5ic3A7c3lzdGVtLCAmbmJzcDtwYXJ0aWN1bGFyIA0KJm5ic3A7dGhlICZuYnNwO2Rp c3RyaWJ1dGVkICZuYnNwO29uZXMuPC9ESVY+DQo8RElWPlNvbWUgJm5ic3A7YWRkaXRpb25hbCAm bmJzcDtkaXNjdXNzaW9uICZuYnNwO2luICZuYnNwO3RoZSANCiZuYnNwOyJPYnNlcnZhdGlvbnMi ICZuYnNwO3NlY3Rpb24gJm5ic3A7Y291bGQgJm5ic3A7dGFsazwvRElWPg0KPERJVj5hYm91dCAm bmJzcDt0aGlzLjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgY29sb3I9I2Zm MDAwMD5JdCdzIGFsc28gb2theSB0byBzdGF0ZSBjbGVhcmx5IHRoaXMgcGFydCBpcyBvdXQgb2Yg DQpERUNBREUgc2NvcGUuPC9GT05UPjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+Jmd0 OzwvRElWPg0KPERJVj4mZ3Q7ICZuYnNwOzUuICZuYnNwOyAmbmJzcDtJbiAmbmJzcDtzZWN0aW9u ICZuYnNwOzMuOCAmbmJzcDt0aGUgDQombmJzcDthdXRob3JzICZuYnNwO3Byb3Bvc2UgJm5ic3A7 dGhyZWUgJm5ic3A7dHlwZXMgJm5ic3A7b2YgJm5ic3A7c3RvcmFnZSANCiZuYnNwO21vZGVzICZu YnNwO3dpdGhvdXQ8L0RJVj4NCjxESVY+Jmd0OyAmbmJzcDtleHBsaWNpdCAmbmJzcDtkZXNjcmlw dGlvbi4gJm5ic3A7QW5kICZuYnNwO3RoZSAmbmJzcDtmb2xsb3dpbmcgDQombmJzcDtlY2hvZXMg Jm5ic3A7aW4gJm5ic3A7c2VjdGlvbiAmbmJzcDs0ICZuYnNwO3N0aWxsICZuYnNwO3Bvc2UgDQom bmJzcDthbjwvRElWPg0KPERJVj4mZ3Q7PC9ESVY+DQo8RElWPiZndDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDthbWJpZ3VvdXMgJm5ic3A7aW1hZ2UgDQombmJzcDtl c3AuICZuYnNwO2JldHdlZW4gJm5ic3A7ZmlsZSAmbmJzcDthbmQgJm5ic3A7b2JqZWN0ICZuYnNw O29yaWVudGVkIA0KJm5ic3A7bW9kZS48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPkFn cmVlZCAmbmJzcDt0aGF0ICZuYnNwO3RoZSAmbmJzcDtkcmFmdCAmbmJzcDtzaG91bGQgJm5ic3A7 ZGVmaW5lICZuYnNwO3RoZSANCiZuYnNwO3Rlcm1zLCAmbmJzcDthbmQgJm5ic3A7dGhhdCAmbmJz cDt3ZSAmbmJzcDtzaG91bGQ8L0RJVj4NCjxESVY+Y2xhcmlmeSAmbmJzcDt0aGUgJm5ic3A7ZGlz dGluY3Rpb24gJm5ic3A7YmV0d2VlbiAmbmJzcDsiZmlsZS1iYXNlZCIgDQombmJzcDthbmQgJm5i c3A7Im9iamVjdC1iYXNlZCI8L0RJVj4NCjxESVY+KHBlcmhhcHMgJm5ic3A7YnkgJm5ic3A7cmVu YW1pbmcgJm5ic3A7ImZpbGUtYmFzZWQiICZuYnNwO3RvIA0KJm5ic3A7c29tZXRoaW5nICZuYnNw O2xpa2UgJm5ic3A7ImhpZXJhcmNoaWNhbDwvRElWPg0KPERJVj5maWxlc3lzdGVtIiAmbmJzcDtv ciAmbmJzcDsiZGlyZWN0b3J5LWJhc2VkIikuPC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJ Vj5UaGFua3MgJm5ic3A7YWdhaW4gJm5ic3A7Zm9yICZuYnNwO3RoZSAmbmJzcDtyZXZpZXchPC9E SVY+DQo8RElWPlJpY2g8L0RJVj48L0ZPTlQ+PC9ESVY+PC9CT0RZPjwvSFRNTD4NCg== --=====003_Dragon813565022156_=====-- From richard.alimi@gmail.com Mon Jan 3 21:31:35 2011 Return-Path: X-Original-To: decade@core3.amsl.com Delivered-To: decade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 254163A6B1E for ; Mon, 3 Jan 2011 21:31:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.445 X-Spam-Level: X-Spam-Status: No, score=-1.445 tagged_above=-999 required=5 tests=[AWL=-0.918, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uFaNdUiCsx79 for ; Mon, 3 Jan 2011 21:31:33 -0800 (PST) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 7A6313A6B1D for ; Mon, 3 Jan 2011 21:31:33 -0800 (PST) Received: by iwn40 with SMTP id 40so14961052iwn.31 for ; Mon, 03 Jan 2011 21:33:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=dTfcWqRXu+Rmnd52Bllb4iPzMSQuMdxXK4y9keOHklQ=; b=CbQUiqqg8Lqno7Sdhva6VDQC0OxL0xPNI97w3LrWODkVg6DLn87hyXds7vfMYW76H/ 5cF3h81YYNcIsEnL9/mHB0ZxobWa3AZ5ZacqvVUitzz8UkpgFpCgUEgaa6L7lCA67z9+ 8IjGT0OmSj5m96BPVKXwwX+MDr4NbcvZk+RrA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=Wwq5iHxMVNvP+AUYxTg5078jYcR+CT1FIrL90b9kwm4Gwvhoud1Kpmy6amwolRRMt9 mMP2sIHl1Wxw6KTibMRl0ZyIHhY1sew/L4aeqdMtfyYCrXrgBhNIS6BqsiSizicEc41u ARjPahEg4uVcmJylhlUsj7WKveDm2EQatlNU0= MIME-Version: 1.0 Received: by 10.231.11.139 with SMTP id t11mr11262926ibt.189.1294119220421; Mon, 03 Jan 2011 21:33:40 -0800 (PST) Sender: richard.alimi@gmail.com Received: by 10.231.31.8 with HTTP; Mon, 3 Jan 2011 21:33:40 -0800 (PST) In-Reply-To: <201101041011014068900@chinamobile.com> References: <201012271733266711931@chinamobile.com> <201101041011014068900@chinamobile.com> Date: Mon, 3 Jan 2011 21:33:40 -0800 X-Google-Sender-Auth: 1702ouR5_gxX6ZE6zd6bEcxIYas Message-ID: From: Richard Alimi To: zhangyunfei Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable Cc: "decade@ietf.org" Subject: Re: [decade] WG Reviews of the Decade Survey draft X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jan 2011 05:31:35 -0000 Hi Yunfei, 2011/1/3 zhangyunfei : > Hi Rich, > Happy new year and please see inline for the detail. Happy new year :) Thanks for the feedback and we will make the modifications in the next revision. Rich > BR > Yunfei > > ________________________________ > zhangyunfei > 2011-01-04 > ________________________________ > =B7=A2=BC=FE=C8=CB=A3=BA Richard Alimi > =B7=A2=CB=CD=CA=B1=BC=E4=A3=BA 2011-01-04 07:34:02 > =CA=D5=BC=FE=C8=CB=A3=BA zhangyunfei > =B3=AD=CB=CD=A3=BA decade@ietf.org > =D6=F7=CC=E2=A3=BA Re: [decade] WG Reviews of the Decade Survey draft > > Hi Yunfei, > > Thank you for the review. Some responses inline: > > 2010/12/27 zhangyunfei : >> First of all happy new year to everybody! >> >> >> >> The following is my WG review of draft-ietf-decade-survey-02. >> >> >> >> Summary: >> >> >> >> This document surveys thoroughly deployed, experimental and >> on-research >> in-network storage and cache systems/ sub-systems >> >> and describes their applicability for DECADE. It provides rich >> references >> for knowing what the existing systems have and >> >> what they lack of. Therefore the designing space of DECADE is >> explicated for >> better understanding. The draft is well written and >> >> conveys the group's intent well. >> >> The authors are suggested to categorize the surveyed >> systems/sub-systems as >> user-controlled (individual) services (in scope of DECADE) >> >> and network-controlled (mass) services (out of scope of DECADE) >> to make it >> more focus on DECADE type services. >> >> >> >> Specific comments and concerns: >> >> 1=A3=AE The organization of section 4: In this section the = authors >> survey >> thoroughly deployed, experimental and on-research in-network >> storage >> >> and cache systems/ sub-systems. However some of them >> are >> user-controlled (individual) services like section 4.1, >> 4.2,4.9,4.10 and >> >> part of 4.12, which are in scope of DECADE; others >> are network >> controlled(mass) services where the users have no rights to >> operate >> >> the in-network storage or caches, which are out of sco= pe >> of DECADE. The >> current organization is a little bit messy and it's suggested >> >> to separate the two parts and focus on the DECADE typ= e >> services. > > I would agree that Section 4 is somewhat long and that it wou= ld > be > good to have subcategories for the systems. This has been > discussed a > couple of times amongst the authors but it was unclear as to = the > proper way to do such a categorization. For example, your > classification above, why is BranchCache (4.2) > user-controlled/individual? S3 can both be used for individual = and > mass usage. It seemed that any attempt at categorization that > we've > discussed thus far has counterexamples which would be debatable = by > a > reader. > I make the attempt to categorize the systems according to the text and my > understanding. > It's really a hard job to solve the matrix perfectly. > > To me, it seems a proper way to categorize them would be a > feature > matrix, but that doesn't work well with the hierarchical section= s > of > the document. > > We are more than happy to discuss this again amongst the autho= rs, > but > do you have some additional ideas on an appropriate scheme? > > Sound good and I'll let you know if I have good ideas on solving this. > >> >> 2=A3=AE Difference between cache and storage: In section 4, = there >> are many >> places to mention in-network caches. In network-controlled >> >> caches, it's hard to introduce DECADE service because >> some of the >> operations defined in DECADE like data deletion in DECADE >> >> server (if we use the current cache as the DECADE >> server) may raise >> confliction with the existing cache update mechanism >> >> by Cache operators when dealing with a certain data. >> In section 4.14 >> the authors state the possible inapplicability for the cache >> scenarios >> >> in using DECADE mechanism. But to make the draft mor= e >> clear, it's >> better to state explicit the scope of DECADE ahead of this >> section. >> >> And also more discussions on whether and how much degr= ee >> we need the >> cache system/subsystem description in this draft are needed in >> the group. > > That makes sense. If the section 4.14 of the Survey draft is > updated > to reference the scope DECADE (perhaps via a reference to the > problem > statement), do you think it would serve as good input to that > discussion? > > Yes, it would be. > >> 3. In section 2, the No.1 effect of DECADE, to my >> understanding, is to >> improve P2P application experience in up-band constraint >> environment like >> >> cellular mobile networks. The current draft lacks of th= is >> although this >> is highlighted in the PS. > > Makes sense. We can add a reference to this discussion in th= e > problem > statement in the introduction. > >> >> 4. Data Search Capability described in section 3.3 seems >> irrelevant to >> DECADE protocols. > > I agree that most (if not all) aspects of "Search" could resid= e > outside of DECADE, but I think it still makes sense to cover > them in > the survey. At the very least, it can highlight the different > features for each storage system, particular the distributed ones= . > Some additional discussion in the "Observations" section could ta= lk > about this. > > It's also okay to state clearly this part is out of DECADE scope. > >> >> 5. In section 3.8 the authors propose three types of storag= e >> modes without >> explicit description. And the following echoes in section 4 >> still pose an >> >> ambiguous image esp. between file and object oriented >> mode. > > Agreed that the draft should define the terms, and that we sho= uld > clarify the distinction between "file-based" and "object-based" > (perhaps by renaming "file-based" to something like "hierarchical > filesystem" or "directory-based"). > > Thanks again for the review! > Rich From abcdmatao@gmail.com Tue Jan 4 02:13:54 2011 Return-Path: X-Original-To: decade@core3.amsl.com Delivered-To: decade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0CA843A6B5A for ; Tue, 4 Jan 2011 02:13:54 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ILlIMhZ40r2n for ; Tue, 4 Jan 2011 02:13:53 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id B0A8B3A6AFA for ; Tue, 4 Jan 2011 02:13:52 -0800 (PST) Received: by wwa36 with SMTP id 36so14197535wwa.13 for ; Tue, 04 Jan 2011 02:15:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:cc:content-type; bh=g6oSCw0p04vWT6DiRsTN6o2UTFL+M+6Qm78JWpzTejk=; b=G0vtyh5BHfd1HU3pTgfzvBt240U5RDzdxiqk8pcdRMPkahXNyy8DkQZ+prMOWn02nN rN2eEL+cWieE/t0wdPxSWu9LRGXCIfIfn2uHzfoVzCjsvLps85bi1QBOY01c9gGvjIam fnvjDAt0UTU05MLiuyque5bFCLmPghWbuxpMI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=L1wUb3a80OFpYRTOT5jnV0r/Rz+VZdAO4z9RQp5J+kfBSuNqu39uOIBiTt+cz66HmZ GPnrEJmuXkWGeYTd4+FHhm3GdZCOM4J5WPjovxqcGH+8av/O+Pm1cVLgBF79REKv+/3Q zLuGRoiysulAuKhDvyhJZ68eUsP41+uAb86Mc= MIME-Version: 1.0 Received: by 10.216.16.21 with SMTP id g21mr7271543weg.6.1294136158767; Tue, 04 Jan 2011 02:15:58 -0800 (PST) Received: by 10.216.47.12 with HTTP; Tue, 4 Jan 2011 02:15:58 -0800 (PST) Date: Tue, 4 Jan 2011 18:15:58 +0800 Message-ID: From: Tao Ma To: decade@ietf.org, haibin.song@huawei.com Content-Type: multipart/alternative; boundary=0015176f16f608c8b80499028e86 Cc: qiuxiaofeng@gmail.com, ch zhang Subject: [decade] review of draft-ietf-decade-problem-statement-01 X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jan 2011 10:13:54 -0000 --0015176f16f608c8b80499028e86 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi, I have carefully read the problem statement draft. It=92s clear and concise= to describe the motivation and goal of DECADE. However, I have some confusion about its details as follows: 1 In section 3.1-P2P infrastructural stress and inefficiency, the third paragraph about the comparion with LEDBAT, there is a sentence =93Also, whe= n adopted, these techniques do not remove all inefficiencies, such as those associated with traffic being sent upstream as many times as there are remote peers interested in getting the corresponding information.=94 I don= =92t catch the main idea of this sentence. What is =93those associated with traf= fic being sent upstream as many times as there are remote peers=94? What is =93corresponding information?=94Do you mean LEDBAT only considers peers in = local network? I think this sentence is quite hard to understand. 2 The section 3 describes the problems that would be targeted by DECADE. On= e side is to reduce the stress on infrastructure, which benefits ISP. The other side is to increase flexibility on content sharing, which benefits users. However, I don=92t think the titile of section 3.3 =93ineffective integration of P2P applications=94 is very appropriate. In my opinion, this section describes the requirements for P2P applications to utilize infrastructural resources, which doesn=92t match the =93ineffective integration=94. I suggest a more appropriate title to highlight the need of infrastructural resources for P2P applications. Besides, I think DECADE is a very promising service to transfer the storage and management of content into the cloud, which envisions the future P2P applications. Can we add the hot concept of =93cloud=94 into the draft? My = 2 cents. Tao Ma Beijing University of Posts and Telecommunications, Mobile life and new media lab --0015176f16f608c8b80499028e86 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

Hi= ,

I have carefully read the problem statement draft. It=92s cle= ar and concise to describe the motivation and goal of DECADE. However, I have some confusion about its details as follows:

1 = In section 3.1-P2P infrastructural stress and inefficiency, the third paragrap= h about the comparion with LEDBAT, there is a sentence =93Also, when adopted,= these techniques do not remove all inefficiencies, such as those associated with traffic being sent upstream as many times as there are remote peers interes= ted in getting the corresponding information.=94 I don=92t catch the main idea = of this sentence. What is =93those associated with traffic being sent upstream as m= any times as there are remote peers=94? What is =93corresponding information?= =94Do you mean LEDBAT only considers peers in local network? I think this sentence is quit= e hard to understand.

2 = The section 3 describes the problems that would be targeted by DECADE. One side is to reduce the stress on infrastructure, which benefits = ISP. The other side is to increase flexibility on content sharing, which benefit= s users. However, I don=92t think the titile of section 3.3 =93ineffective integration of P2P applications=94 is very appropriate. In my opinion, this section describes the requirements for P2P applications to utilize infrastructural resources, which doesn=92t match the =93ineffective integra= tion=94. I suggest a more appropriate title to highlight the need of infrastructural resources for P2P applications.

Be= sides, I think DECADE is a very promising service to transfer the storage and management of content into the cloud, which envisions the futur= e P2P applications. Can we add the hot concept of =93cloud=94 into the draft? My = 2 cents.


Tao Ma

Beijing University of Posts and Telecommunications, Mobile life and new media lab

--0015176f16f608c8b80499028e86-- From richard_woundy@cable.comcast.com Wed Jan 5 15:00:22 2011 Return-Path: X-Original-To: decade@core3.amsl.com Delivered-To: decade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B66E63A6D0B for ; Wed, 5 Jan 2011 15:00:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.668 X-Spam-Level: X-Spam-Status: No, score=-106.668 tagged_above=-999 required=5 tests=[AWL=1.794, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qG6n36w4j3Kb for ; Wed, 5 Jan 2011 15:00:21 -0800 (PST) Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by core3.amsl.com (Postfix) with ESMTP id D2B5E3A6D1C for ; Wed, 5 Jan 2011 15:00:20 -0800 (PST) Received: from ([24.40.55.40]) by pacdcimo01.cable.comcast.com with ESMTP with TLS id 5503620.110081133; Wed, 05 Jan 2011 18:03:18 -0500 Received: from PACDCEXMB05.cable.comcast.com ([fe80::a5b0:e5c4:df1b:2367]) by pacdcexhub03.cable.comcast.com ([fe80::d1dd:b302:b617:3755%12]) with mapi id 14.01.0270.001; Wed, 5 Jan 2011 18:02:21 -0500 From: "Woundy, Richard" To: "decade@ietf.org" Thread-Topic: DECADE meeting minutes for IETF 79 Thread-Index: AcubOIgTbLFuHbJhTQGazbvKS5gjCgR8sysg Date: Wed, 5 Jan 2011 23:02:20 +0000 Message-ID: <1CA25301D2219F40B3AA37201F0EACD1063F0B@PACDCEXMB05.cable.comcast.com> References: <057E4696615D964AB8053E9EE5DCD3D40196BCCC@szxeml508-mbx.china.huawei.com> In-Reply-To: <057E4696615D964AB8053E9EE5DCD3D40196BCCC@szxeml508-mbx.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.191.223.118] Content-Type: multipart/alternative; boundary="_000_1CA25301D2219F40B3AA37201F0EACD1063F0BPACDCEXMB05cablec_" MIME-Version: 1.0 Subject: Re: [decade] DECADE meeting minutes for IETF 79 X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jan 2011 23:00:23 -0000 --_000_1CA25301D2219F40B3AA37201F0EACD1063F0BPACDCEXMB05cablec_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Folks, I have edited our meeting minutes for IETF 79, after listening carefully to= the audio recording of our session. The final meeting minutes can be found at http://www.ietf.org/proceedings/7= 9/minutes/decade.txt. Note that there are several discussions that we agreed to take to this mail= ing list: * Reviews of the problem statement and survey drafts * Discussion of the resource control model in the architecture draf= t * Adoption of the architecture draft (already completed) * Should content in storage be deleted when the owner goes offline * Should there be a consolidated Integration Example draft, or (say= ) one draft per example * What is the WG scope with regards to router interaction with DECA= DE storage systems, and router storage of content in general Thanks for your patience. -- Rich From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.org] On Behalf Of= Songhaibin Sent: Monday, December 13, 2010 9:42 PM To: decade@ietf.org Subject: [decade] DECADE meeting minutes for IETF 79 Dear all, The meeting minutes for IETF 79 have been uploaded. Please let Rich and I k= now if you have any questions. We will give an updated version before Janua= ry 5. Thanks to Christian for taking the notes. http://www.ietf.org/proceedings/79/minutes/decade.txt Thanks, Haibin and Rich --_000_1CA25301D2219F40B3AA37201F0EACD1063F0BPACDCEXMB05cablec_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Folks,

 

I have edited our meeting minutes for IETF 79, after listeni= ng carefully to the audio recording of our session.

 

The final meeting minutes can be found at http://ww= w.ietf.org/proceedings/79/minutes/decade.txt.

 

Note that there are several discussions that we agreed to ta= ke to this mailing list:

·      = ;   Reviews of the problem statement and survey drafts

·      = ;   Discussion of the resource control model in the architecture= draft

·      = ;   Adoption of the architecture draft (already completed)<= /o:p>

·      = ;   Should content in storage be deleted when the owner goes off= line

·      = ;   Should there be a consolidated Integration Example draft, or= (say) one draft per example

·      = ;   What is the WG scope with regards to router interaction with= DECADE storage systems, and router storage of content in general

 

Thanks for your patience.

 

-- Rich

 

From: decade-b= ounces@ietf.org [mailto:decade-bounces@ietf.org] On Behalf Of Songhaibin
Sent: Monday, December 13, 2010 9:42 PM
To: decade@ietf.org
Subject: [decade] DECADE meeting minutes for IETF 79

 

Dear all,

 

The meeting minutes for IETF 79 have been upload= ed. Please let Rich and I know if you have any questions. We will give an u= pdated version before January 5. Thanks to Christian for taking the notes.

 

http://www.ietf.org/proceedings/79/minutes/decade.txt=

 

Thanks,

Haibin and Rich

--_000_1CA25301D2219F40B3AA37201F0EACD1063F0BPACDCEXMB05cablec_-- From richard_woundy@cable.comcast.com Wed Jan 5 15:17:07 2011 Return-Path: X-Original-To: decade@core3.amsl.com Delivered-To: decade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 610243A6E23 for ; Wed, 5 Jan 2011 15:17:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.78 X-Spam-Level: X-Spam-Status: No, score=-106.78 tagged_above=-999 required=5 tests=[AWL=1.682, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9uPbC-n4vyIG for ; Wed, 5 Jan 2011 15:17:06 -0800 (PST) Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by core3.amsl.com (Postfix) with ESMTP id D7D353A6DD4 for ; Wed, 5 Jan 2011 15:17:05 -0800 (PST) Received: from ([24.40.55.41]) by pacdcimo01.cable.comcast.com with ESMTP with TLS id 5503620.110082650; Wed, 05 Jan 2011 18:20:06 -0500 Received: from PACDCEXMB05.cable.comcast.com ([fe80::a5b0:e5c4:df1b:2367]) by PACDCEXHUB02.cable.comcast.com ([fe80::11d4:f530:37a0:9f4e%12]) with mapi id 14.01.0270.001; Wed, 5 Jan 2011 18:19:09 -0500 From: "Woundy, Richard" To: "'decade@ietf.org'" Thread-Topic: Reviews of the Decade Problem Statement draft Thread-Index: AcuclJZz4nxTPrqtT4uUeAAn8W9WtgQmIOEQ Date: Wed, 5 Jan 2011 23:19:08 +0000 Message-ID: <1CA25301D2219F40B3AA37201F0EACD1063F46@PACDCEXMB05.cable.comcast.com> References: <1CA25301D2219F40B3AA37201F0EACD104CB1B@PACDCEXMB05.cable.comcast.com> In-Reply-To: <1CA25301D2219F40B3AA37201F0EACD104CB1B@PACDCEXMB05.cable.comcast.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.191.223.118] Content-Type: multipart/alternative; boundary="_000_1CA25301D2219F40B3AA37201F0EACD1063F46PACDCEXMB05cablec_" MIME-Version: 1.0 Subject: Re: [decade] Reviews of the Decade Problem Statement draft X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jan 2011 23:17:07 -0000 --_000_1CA25301D2219F40B3AA37201F0EACD1063F46PACDCEXMB05cablec_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I would like to express my thanks to the reviewers of the problem statement= draft! Tao Ma http://www.ietf.org/mail-archive/web/decade/current/msg00356.html Ning Zong http://www.ietf.org/mail-archive/web/decade/current/msg00341.html Roni Even http://www.ietf.org/mail-archive/web/decade/current/msg00336.html David Bryan http://www.ietf.org/mail-archive/web/decade/current/msg00334.html Akbar Rahman http://www.ietf.org/mail-archive/web/decade/current/msg00313.html I believe we have a sufficient number of reviews for the authors to incorpo= rate this feedback, and to produce a new revision for WGLC. -- Rich From: Woundy, Richard Sent: Wednesday, December 15, 2010 3:14 PM To: 'decade@ietf.org' Cc: Songhaibin; Woundy, Richard Subject: Reviews of the Decade Problem Statement draft Folks, We would like to prepare the problem statement draft, draft-ietf-decade-pro= blem-statement-00, for working group last call in January. The chairs are looking for document reviews to be sent to the mailing list = by Wednesday December 29. We already have three volunteers from our session= in Beijing (and thanks to Akbar Rahman for already posting his review to t= his list). Additional draft reviews by the deadline would be timely and gre= atly appreciated. After the authors incorporate the feedback from the reviews in a new draft = iteration, the chairs expect to take the draft to WGLC. -- Rich --_000_1CA25301D2219F40B3AA37201F0EACD1063F46PACDCEXMB05cablec_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I would like to expres= s my thanks to the reviewers of the problem statement draft!

 

Tao Ma=

http://www.ietf.org= /mail-archive/web/decade/current/msg00356.html

Ning Zong

http://www.ietf.org= /mail-archive/web/decade/current/msg00341.html

Roni Even

http://www.ietf.org= /mail-archive/web/decade/current/msg00336.html

David Bryan

http://www.ietf.org= /mail-archive/web/decade/current/msg00334.html

Akbar Rahman<= /span>

http://www.ietf.org= /mail-archive/web/decade/current/msg00313.html

 

I believe we have a su= fficient number of reviews for the authors to incorporate this feedback, an= d to produce a new revision for WGLC.

 

-- Rich

 

From: Woundy, = Richard
Sent: Wednesday, December 15, 2010 3:14 PM
To: 'decade@ietf.org'
Cc: Songhaibin; Woundy, Richard
Subject: Reviews of the Decade Problem Statement draft

 

Folks,

 

We would like to prepare the problem statement draft= , draft-ietf-decade-problem-statement-00, for working group last call in = January.

 

The chairs are looking for document reviews to be se= nt to the mailing list by Wednesday December 29. We already have three volu= nteers from our session in Beijing (and thanks to Akbar Rahman for already = posting his review to this list). Additional draft reviews by the deadline would be timely and greatly appre= ciated.

 

After the authors incorporate the feedback from the = reviews in a new draft iteration, the chairs expect to take the draft to WG= LC.

 

-- Rich

--_000_1CA25301D2219F40B3AA37201F0EACD1063F46PACDCEXMB05cablec_-- From richard_woundy@cable.comcast.com Wed Jan 5 15:37:01 2011 Return-Path: X-Original-To: decade@core3.amsl.com Delivered-To: decade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E03CF3A6E12 for ; Wed, 5 Jan 2011 15:37:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.879 X-Spam-Level: X-Spam-Status: No, score=-106.879 tagged_above=-999 required=5 tests=[AWL=1.583, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ub525idL+-ch for ; Wed, 5 Jan 2011 15:36:55 -0800 (PST) Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by core3.amsl.com (Postfix) with ESMTP id 791F83A6D0E for ; Wed, 5 Jan 2011 15:36:55 -0800 (PST) Received: from ([24.40.55.41]) by pacdcimo01.cable.comcast.com with ESMTP with TLS id 5503620.110084181; Wed, 05 Jan 2011 18:39:54 -0500 Received: from PACDCEXMB05.cable.comcast.com ([fe80::a5b0:e5c4:df1b:2367]) by PACDCEXHUB02.cable.comcast.com ([fe80::11d4:f530:37a0:9f4e%12]) with mapi id 14.01.0270.001; Wed, 5 Jan 2011 18:38:57 -0500 From: "Woundy, Richard" To: "'decade@ietf.org'" Thread-Topic: Reviews of the Decade Problem Statement draft Thread-Index: AcuclJZz4nxTPrqtT4uUeAAn8W9WtgQmIOEQAADH11A= Date: Wed, 5 Jan 2011 23:38:55 +0000 Message-ID: <1CA25301D2219F40B3AA37201F0EACD1063F8D@PACDCEXMB05.cable.comcast.com> References: <1CA25301D2219F40B3AA37201F0EACD104CB1B@PACDCEXMB05.cable.comcast.com> <1CA25301D2219F40B3AA37201F0EACD1063F46@PACDCEXMB05.cable.comcast.com> In-Reply-To: <1CA25301D2219F40B3AA37201F0EACD1063F46@PACDCEXMB05.cable.comcast.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.191.223.118] Content-Type: multipart/alternative; boundary="_000_1CA25301D2219F40B3AA37201F0EACD1063F8DPACDCEXMB05cablec_" MIME-Version: 1.0 Subject: Re: [decade] Reviews of the Decade Problem Statement draft X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jan 2011 23:37:02 -0000 --_000_1CA25301D2219F40B3AA37201F0EACD1063F8DPACDCEXMB05cablec_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Folks, Below is my own "idnits review" based on the output of http://tools.ietf.or= g/idnits?url=3Dhttp://tools.ietf.org/id/draft-ietf-decade-problem-statement= -01.txt. =3D=3D The document doesn't use any RFC 2119 keywords, yet seems to have = RFC 2119 boilerplate text. See the first paragraph of section 2, and the lack of MUST/SHOULD/MAY langu= age in the draft. Maybe delete the boilerplate and RFC 2119 reference? =3D=3D Missing Reference: 'CNN' is mentioned on line 182, but not defined I'm not sure that the draft needs a reference to the CNN report, since it d= oesn't have a reference to the PPLive example. But if a reference is still = desired, consider this one: http://gigaom.com/video/cnn-inauguration-p2p-st= ream-a-success-despite-backlash/. =3D=3D Unused Reference: 'RFC3720' is defined on line 682, but no explici= t reference was found in the text =3D=3D Unused Reference: 'RFC5661' is defined on line 686, but no explici= t reference was found in the text =3D=3D Unused Reference: 'RFC2616' is defined on line 690, but no explici= t reference was found in the text The draft probably should either incorporate these references into the text= , or delete them. -- Rich From: Woundy, Richard Sent: Wednesday, January 05, 2011 6:19 PM To: 'decade@ietf.org' Cc: Songhaibin; Woundy, Richard Subject: RE: Reviews of the Decade Problem Statement draft I would like to express my thanks to the reviewers of the problem statement= draft! Tao Ma http://www.ietf.org/mail-archive/web/decade/current/msg00356.html Ning Zong http://www.ietf.org/mail-archive/web/decade/current/msg00341.html Roni Even http://www.ietf.org/mail-archive/web/decade/current/msg00336.html David Bryan http://www.ietf.org/mail-archive/web/decade/current/msg00334.html Akbar Rahman http://www.ietf.org/mail-archive/web/decade/current/msg00313.html I believe we have a sufficient number of reviews for the authors to incorpo= rate this feedback, and to produce a new revision for WGLC. -- Rich From: Woundy, Richard Sent: Wednesday, December 15, 2010 3:14 PM To: 'decade@ietf.org' Cc: Songhaibin; Woundy, Richard Subject: Reviews of the Decade Problem Statement draft Folks, We would like to prepare the problem statement draft, draft-ietf-decade-pro= blem-statement-00, for working group last call in January. The chairs are looking for document reviews to be sent to the mailing list = by Wednesday December 29. We already have three volunteers from our session= in Beijing (and thanks to Akbar Rahman for already posting his review to t= his list). Additional draft reviews by the deadline would be timely and gre= atly appreciated. After the authors incorporate the feedback from the reviews in a new draft = iteration, the chairs expect to take the draft to WGLC. -- Rich --_000_1CA25301D2219F40B3AA37201F0EACD1063F8DPACDCEXMB05cablec_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Folks,

 

Below is my own “= ;idnits review” based on the output of http://tools.ietf.org/idnits?url=3Dhttp://tools.ietf.org/id/draft-ietf-deca= de-problem-statement-01.txt.

 

  =3D=3D The docu= ment doesn't use any RFC 2119 keywords, yet seems to have RFC

   &nbs= p; 2119 boilerplate text.

 

See the first paragrap= h of section 2, and the lack of MUST/SHOULD/MAY language in the draft. Mayb= e delete the boilerplate and RFC 2119 reference?

 

  =3D=3D Missing = Reference: 'CNN' is mentioned on line 182, but not defined

 

I’m not sure tha= t the draft needs a reference to the CNN report, since it doesn’t hav= e a reference to the PPLive example. But if a reference is still desired, c= onsider this one: http://gigaom.com/video/cnn-inauguration-p2p-stream-a-success-despite-backl= ash/.

 

  =3D=3D Unused R= eference: 'RFC3720' is defined on line 682, but no explicit

    &nb= sp;reference was found in the text

  =3D=3D Unused R= eference: 'RFC5661' is defined on line 686, but no explicit

   &nbs= p; reference was found in the text

  =3D=3D Unused R= eference: 'RFC2616' is defined on line 690, but no explicit

   &nbs= p; reference was found in the text

 

The draft probably sho= uld either incorporate these references into the text, or delete them.=

 

-- Rich

 

From: Woundy, = Richard
Sent: Wednesday, January 05, 2011 6:19 PM
To: 'decade@ietf.org'
Cc: Songhaibin; Woundy, Richard
Subject: RE: Reviews of the Decade Problem Statement draft

 

I would like to expres= s my thanks to the reviewers of the problem statement draft!

 

Tao Ma=

http://www.ietf.org= /mail-archive/web/decade/current/msg00356.html

Ning Zong

http://www.ietf.org= /mail-archive/web/decade/current/msg00341.html

Roni Even

http://www.ietf.org= /mail-archive/web/decade/current/msg00336.html

David Bryan

http://www.ietf.org= /mail-archive/web/decade/current/msg00334.html

Akbar Rahman<= /span>

http://www.ietf.org= /mail-archive/web/decade/current/msg00313.html

 

I believe we have a su= fficient number of reviews for the authors to incorporate this feedback, an= d to produce a new revision for WGLC.

 

-- Rich

 

From: Woundy, = Richard
Sent: Wednesday, December 15, 2010 3:14 PM
To: 'decade@ietf.org'
Cc: Songhaibin; Woundy, Richard
Subject: Reviews of the Decade Problem Statement draft

 

Folks,

 

We would like to prepare the problem statement draft= , draft-ietf-decade-problem-statement-00, for working group last call in = January.

 

The chairs are looking for document reviews to be se= nt to the mailing list by Wednesday December 29. We already have three volu= nteers from our session in Beijing (and thanks to Akbar Rahman for already = posting his review to this list). Additional draft reviews by the deadline would be timely and greatly appre= ciated.

 

After the authors incorporate the feedback from the = reviews in a new draft iteration, the chairs expect to take the draft to WG= LC.

 

-- Rich

--_000_1CA25301D2219F40B3AA37201F0EACD1063F8DPACDCEXMB05cablec_-- From richard_woundy@cable.comcast.com Wed Jan 5 15:44:34 2011 Return-Path: X-Original-To: decade@core3.amsl.com Delivered-To: decade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 19C013A6E3B for ; Wed, 5 Jan 2011 15:44:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.967 X-Spam-Level: X-Spam-Status: No, score=-106.967 tagged_above=-999 required=5 tests=[AWL=1.495, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yktg4BR3kAtI for ; Wed, 5 Jan 2011 15:44:33 -0800 (PST) Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by core3.amsl.com (Postfix) with ESMTP id CAA4F3A6D0E for ; Wed, 5 Jan 2011 15:44:32 -0800 (PST) Received: from ([24.40.55.41]) by pacdcimo01.cable.comcast.com with ESMTP with TLS id 5503620.110084771; Wed, 05 Jan 2011 18:47:31 -0500 Received: from PACDCEXMB05.cable.comcast.com ([fe80::a5b0:e5c4:df1b:2367]) by PACDCEXHUB02.cable.comcast.com ([fe80::11d4:f530:37a0:9f4e%12]) with mapi id 14.01.0270.001; Wed, 5 Jan 2011 18:46:34 -0500 From: "Woundy, Richard" To: "'decade@ietf.org'" Thread-Topic: Reviews of the Decade Survey draft Thread-Index: AcuclJdof7II0b1bR9GixOWzuqDcEAQnUi7g Date: Wed, 5 Jan 2011 23:46:33 +0000 Message-ID: <1CA25301D2219F40B3AA37201F0EACD1063FAD@PACDCEXMB05.cable.comcast.com> References: <1CA25301D2219F40B3AA37201F0EACD104CB25@PACDCEXMB05.cable.comcast.com> In-Reply-To: <1CA25301D2219F40B3AA37201F0EACD104CB25@PACDCEXMB05.cable.comcast.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.191.223.118] Content-Type: multipart/alternative; boundary="_000_1CA25301D2219F40B3AA37201F0EACD1063FADPACDCEXMB05cablec_" MIME-Version: 1.0 Subject: Re: [decade] Reviews of the Decade Survey draft X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jan 2011 23:44:34 -0000 --_000_1CA25301D2219F40B3AA37201F0EACD1063FADPACDCEXMB05cablec_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I would like to express my thanks to the reviewers of the survey draft! David Bryan http://www.ietf.org/mail-archive/web/decade/current/msg00342.html Yunfei Zhang http://www.ietf.org/mail-archive/web/decade/current/msg00340.html I would like to see at least one more review posted to the mailing list, be= fore the authors incorporate this feedback into the next draft. I check this draft with idnits (http://tools.ietf.org/idnits?url=3Dhttp://t= ools.ietf.org/id/draft-ietf-decade-survey-02.txt), and I believe the only s= ignificant issue there has already identified by David Bryan: =3D=3D Outdated reference: A later version (-01) exists of draft-ietf-decade-problem-statement-00 -- Rich From: Woundy, Richard Sent: Wednesday, December 15, 2010 3:14 PM To: 'decade@ietf.org' Cc: Songhaibin; Woundy, Richard Subject: Reviews of the Decade Survey draft Folks, We would like to prepare the survey draft, draft-ietf-decade-survey-01, for working group l= ast call in January. The chairs are looking for document reviews to be sent to the mailing list = by Wednesday December 29. We already have three volunteers from our session= in Beijing. Additional draft reviews by the deadline would be timely and g= reatly appreciated. After the authors incorporate the feedback from the reviews in a new draft = iteration, the chairs expect to take the draft to WGLC. -- Rich --_000_1CA25301D2219F40B3AA37201F0EACD1063FADPACDCEXMB05cablec_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I would like to expres= s my thanks to the reviewers of the survey draft!

 

David Bryan

http://www.ietf.org= /mail-archive/web/decade/current/msg00342.html

Yunfei Zhang<= /span>

http://www.ietf.org= /mail-archive/web/decade/current/msg00340.html

 

I would like to see at= least one more review posted to the mailing list, before the authors incor= porate this feedback into the next draft.

 

I check this draft wit= h idnits (http://tools.ietf.org/idnits?url=3Dh= ttp://tools.ietf.org/id/draft-ietf-decade-survey-02.txt), and I believe the only significant issue there has already identified by D= avid Bryan:

 

  =3D=3D Outdated= reference: A later version (-01) exists of

   &nbs= p; draft-ietf-decade-problem-statement-00

 

-- Rich

 

From: Woundy, = Richard
Sent: Wednesday, December 15, 2010 3:14 PM
To: 'decade@ietf.org'
Cc: Songhaibin; Woundy, Richard
Subject: Reviews of the Decade Survey draft

 

Folks,

 

We would like to prepare the survey draft, draft-ietf-decade-survey-01, for working group last call in January.

 

The chairs are looking for document reviews to be se= nt to the mailing list by Wednesday December 29. We already have three volu= nteers from our session in Beijing. Additional draft reviews by the deadlin= e would be timely and greatly appreciated.

 

After the authors incorporate the feedback from the = reviews in a new draft iteration, the chairs expect to take the draft to WG= LC.

 

-- Rich

--_000_1CA25301D2219F40B3AA37201F0EACD1063FADPACDCEXMB05cablec_-- From buptxiaozhu@gmail.com Mon Jan 10 18:43:26 2011 Return-Path: X-Original-To: decade@core3.amsl.com Delivered-To: decade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DCB5D28C1C9 for ; Mon, 10 Jan 2011 18:43:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.091 X-Spam-Level: X-Spam-Status: No, score=-2.091 tagged_above=-999 required=5 tests=[AWL=1.207, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2rWfEABFeSDG for ; Mon, 10 Jan 2011 18:43:24 -0800 (PST) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by core3.amsl.com (Postfix) with ESMTP id 4FCA528C1C8 for ; Mon, 10 Jan 2011 18:43:24 -0800 (PST) Received: by ewy8 with SMTP id 8so9290876ewy.31 for ; Mon, 10 Jan 2011 18:45:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=nuGwkK97V+Sc2CUM2crg9j6i5GTOp3mdUBtiEleSQkI=; b=If5ExhOB4IS8jgPZW1Ha/84gdjnSqjBJw07rtZkwBo5X5mjoVZcTqCW8VPx5Rg/1Xg kkW1B8bSRFWoeaLGuTRabgQk4A6MyL9UTRx/Q90+8pSHZ3fOoU/G530vf1YlFQd3pbUl mROaa/qyvR1RA9p8IJ2/VfIGu7wbiUQJLy4dM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=piaCJCefRK125zRs+5j/JPbYpDRbYMEoyQTqiW4JmiZuKtcjUZQaJBNbiGKKxtu38E VzLC9tFIH5xV6D+C+NoyY+VKVVrJUkyDTfhEyQmHUOKgcteKpXt3739mwPPtvVS/8Ugc ZOAKUqkRzngvdvV59uxI6Cn/IgIVTiA/tPxpU= MIME-Version: 1.0 Received: by 10.213.25.134 with SMTP id z6mr2457797ebb.41.1294713938734; Mon, 10 Jan 2011 18:45:38 -0800 (PST) Received: by 10.14.29.71 with HTTP; Mon, 10 Jan 2011 18:45:38 -0800 (PST) In-Reply-To: References: Date: Tue, 11 Jan 2011 10:45:38 +0800 Message-ID: From: =?UTF-8?B?5pyx5r2H?= To: Richard Alimi Content-Type: multipart/alternative; boundary=0015174c441c676f4d049989148e Cc: decade@ietf.org Subject: Re: [decade] draft-zhu-decade-additional-requirements X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jan 2011 02:43:27 -0000 --0015174c441c676f4d049989148e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable hi, Richard, sorry for so late response because of be busy with other projects. some discussion see inline:D marked by red. On Tue, Jan 4, 2011 at 4:06 AM, Richard Alimi wrote: > Hi Xiao, > > Thank you for the draft. Some comments on the requirements: > > Request Redirects: > > This would provide some additional freedom for the storage provider. > I think it is reasonable since it doesn't necessitate additional > complexity for the DECADE server, but allows it if desired. However, > note that it may complicate some of the other components of the > design. In particular, if there is a per-user quota for storage, is > the user made aware of the quota at each in-network storage (if there > is no shared storage between them)? Resource sharing policies may be > impacted (e.g., if a bandwidth sharing weight of 1 may mean something > different at DECADE server A than it does at DECADE server B). At > this point it may be best to just note these so they are documented, > but since the specification of the resource sharing policies are still > being contemplated for the basic case of a single server it may be > premature to even try and solve them for the case supporting > redirection. > > actually, you mean two points, right? 1. whether or not to be ware of the content at each in-network storage and of course resource sharing policies can be impact in the request redirection. your suggestion"just to note these so they are documented" wil= l be ok, or DECADE server list with some parameters will be return for user t= o select the appropriate DECADE server, which can avoid the different weighte= d of the same parameter in server decision. but the parameter used in select the best DECADE server will be known for DECADE servers, in which other complexities will be added. anyway, all the solution are the implementation issue, which, i believe, does not impact the necessity o= f the requirement. 2. you mean "the resource sharing policies are still being considered in a single server", so it may be premature to support redirection. the architecture and protocol will be badly impacted if the requirements change= . so the designing can be taken step by step, but the requirements should b= e overall considered. > Multi-connection: > > I'm not quite clear on the intention of the requirement. My > understanding is that you wish the client to be able to have multiple > connections open spanning multiple DECADE servers. Is that correct? > > If so, do we need this stated as a requirement or the protocol? Or is > this a policy that would be allowed/disallowed by the storage > provider? > > yep, your understanding is right, the scenarios were just described in draft as "soft handover in wireless environment and delete operation in multi-servers". under these consideration, the authentication and authorization need to be taken each time when setup connection with a new DECADE server, or just be taken only once during the service? > Data Distribution: > > I'm also confused about the intent of this requirement. This > statement has me somewhat worried: "The distribution is transparent to > the users as they interact with the in-network storage as a single > logical system." Does this mean that you are proposing for DECADE > servers to assume the responsibility for deciding how data is to be > distributed throughout the network, including the path of the data, > which servers act as intermediate caches, content expiration policies, > etc? If this is true, I think it is missing one of the major points > of DECADE. In particular, these decisions are application-dependent > and are not implemented within DECADE. Instead, DECADE provides the > basic capabilities and the functionality described above are > implemented by the applications using DECADE. > > Or, am I misinterpreting the intent of the requirement? > > you mean DECADE provides the basic capabilities, so can you give some specify explanations on DECADE capabilities in supporting data distribution? Service Assurance: > > It seems problematic to include "assurance" in a DECADE. Shouldn't > these instead be part of SLAs with a storage provider? Why should > they be DECADE's responsibility? > > Regarding "resource reservation", are you referring to an actual > reservation (which might be problematic -- see above) or do you mean > that the resource share should able to be specified at the time the > connection opens and be assumed to be the same for the duration of the > connection? > > Regarding Dynamic Feedback, is this orthogonal to the storage > protocol? It seems like what you want here is a generic "status" > service saying how loaded a server is? > > thats right, actually, the flow control mechanism was under discussion in writing the draft at first. what about your opinion in this requirements? > Data classification: > > Would it be better to instead have the client specify properties of > the content instead of place it into ? See > www.ietf.org/proceedings/78/slides/nfsv4-0.pdf for an example of this > approach for NFS. > > I think a problem with classifying applications is that it assumes > that applications fit one of the supplied classifications. What if it > may fit multiple classifications? or none? Another problem is it > assumes that servers assume based on indirect and assumed information > that they know what to do with a particular piece of content. Why not > have an application specify its desires directly? > > > Small Objects: > > What is the new requirement here? Why is the existing requirement in > draft-ietf-decade-reqs-00 insufficient? > > This also has me a bit worried: > "And the in-network storage has the limited storage capacity, with the > arrival of user requests and data distribution requirements, the data > stored in the in-network storage will be replaced if the storage > reaches the limit and data arrivals continually." > > How does the server know what the proper replacement strategy is for > an application? I think DECADE's philosophy is that applications > should decide this. A simple way to do this is explicit deletion by an > application, but perhaps a more efficient (yet more complex) solution > is for an application to specify the replacement policy to the server. > > actually, the key in "the data classification and small objects " is whether does it or not in P2P application? i did not find data classification was adopted in P2P application so far, let alone DECADE need to classify the data used in all kinds of application. > Removal of Expired Records: > > "However, the two scenarios did not mention how to handle the old > resource if the user distributes the new resource which is an updated > copy of the old resource." > > Why does this need to be handled in the requirements? Are you trying > to draw the distinction between immediate deletion of content and lazy > deletion? > > i mean the meaning of delete operation and how to handle the expired records need to be clarify in requirements. > Thanks! > Rich > > > On Mon, Dec 27, 2010 at 12:57 AM, =E6=9C=B1=E6=BD=87 wrote: > > Dear all, > > > > There is a slightly updated version of the decade additional requiremen= ts > > draft. > > > https://datatracker.ietf.org/doc/draft-zhu-decade-additional-requirements= / > > > > Jin Peng, Yunfei Zhang and me are expecting to have a discussion with a= ll > of > > you. > > > > Any comments are appreciated! > > > > > A new version of I-D, draft-zhu-decade-additional-requirements-00.txt has= been successfully submitted by Xiao Zhu and posted to the IETF repository. > > > > Filename: draft-zhu-decade-additional-requirements > > Revision: 00 > > Title: Additional protocol requirements on DECADE > > Creation_date: 2010-12-27 > > WG ID: Independent Submission > > Number_of_pages: 10 > > > > Abstract: > > The DECoupled Application Data Enroute(DECADE)working group is > > specifying standardized interfaces for accessing in-network storage > > from applications to store, retrieve and manage data. The main object > > is to provide a framework that is useful to the applications, > > including P2P applications and other data-oriented applications, > > possibly related applications that can benefit from accessing in- > > network storage. This memo focuses on some requirements such as > > request redirecting and so on which are on the central of mobility, > > wireless network environment and CDN application. We present these in > > this memo as additional requirements that should be considered for > > the DECADE architecture and protocol specifications. > > > > > > > > The IETF Secretariat. > > > > -- > > Best wishes, > > > > Beijing University of Posts & Telecommunications (BUPT) > > Zhu Xiao ( =E6=9C=B1=E6=BD=87 ) > > E-mail: buptxiaozhu@gmail.com > > mobile:+86 134-8881-9004 > > > > _______________________________________________ > > decade mailing list > > decade@ietf.org > > https://www.ietf.org/mailman/listinfo/decade > > > > > --=20 Best wishes, Beijing University of Posts & Telecommunications (BUPT) Zhu Xiao ( =E6=9C=B1=E6=BD=87 ) E-mail: buptxiaozhu@gmail.com mobile:+86 134-8881-9004 --0015174c441c676f4d049989148e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable hi, Richard, sorry for so late response because of be busy with other proje= cts.

some=C2=A0discussion=C2=A0see inline:D marked by re= d.


On Tue, Jan 4, 2= 011 at 4:06 AM, Richard Alimi <rich@velvetsea.net> wrote:
Hi Xiao,

Thank you for the draft. =C2=A0Some comments on the requirements:

Request Redirects:

This would provide some additional freedom for the storage provider.
I think it is reasonable since it doesn't necessitate additional
complexity for the DECADE server, but allows it if desired. However,
note that it may complicate some of the other components of the
design. In particular, if there is a per-user quota for storage, is
the user made aware of the quota at each in-network storage (if there
is no shared storage between them)? =C2=A0Resource sharing policies may be<= br> impacted (e.g., if a bandwidth sharing weight of 1 may mean something
different at DECADE server A than it does at DECADE server B). =C2=A0At
this point it may be best to just note these so they are documented,
but since the specification of the resource sharing policies are still
being contemplated for the basic case of a single server it may be
premature to even try and solve them for the case supporting
redirection.

actual= ly, you mean two points, right?
1. whether or not to be ware of the content at eac= h in-network storage and of course resource sharing policies can be impact = in the request redirection. your suggestion"just to note these so they= are documented" will be ok, or DECADE server list with some parameter= s will be return for user to select the=C2=A0appropriate DECADE server, whi= ch can avoid the different weighted of the same parameter in server=C2=A0de= cision. but the parameter used in select the best DECADE server will be kno= wn for DECADE servers, in which other complexities will be added. anyway, a= ll the solution are the=C2=A0implementation=C2=A0issue, which, i believe, d= oes not impact the necessity of the requirement.
2. you mean "t= he resource sharing policies are still being considered in a single server&= quot;, so it may be premature to support redirection. =C2=A0the architectur= e and protocol will be badly impacted if the=C2=A0requirements change. so t= he designing can be =C2=A0taken =C2=A0step by step, but the requirements sh= ould be overall considered.

=C2=A0
Multi-connection:

I'm not quite clear on the intention of the requirement. =C2=A0My
understanding is that you wish the client to be able to have multiple
connections open spanning multiple DECADE servers. Is that correct?

If so, do we need this stated as a requirement or the protocol? Or is
this a policy that would be allowed/disallowed by the storage
provider?

ye= p, your understanding is right, the=C2=A0scenarios were just described in d= raft as "soft handover in wireless=C2=A0environment=C2=A0and delete op= eration in multi-servers". under these consideration, the authenticati= on and=C2=A0authorization=C2=A0need to be taken each time when setup connec= tion with a new DECADE server, or just be taken only once during =C2=A0the = service?
=C2=A0
Data Distribution:

I'm also confused about the intent of this requirement. =C2=A0This
statement has me somewhat worried: "The distribution is transparent to=
the users as they interact with the in-network storage as a single
logical system." Does this mean that you are proposing for DECADE
servers to assume the responsibility for deciding how data is to be
distributed throughout the network, including the path of the data,
which servers act as intermediate caches, content expiration policies,
etc? =C2=A0If this is true, I think it is missing one of the major points of DECADE. In particular, these decisions are application-dependent
and are not implemented within DECADE. Instead, DECADE provides the
basic capabilities and the functionality described above are
implemented by the applications using DECADE.

Or, am I misinterpreting the intent of the requirement?

you mean DECADE pr= ovides the basic capabilities, so can you give some=C2=A0specify=C2=A0expla= nations=C2=A0on D= ECADE capabilities in supporting data distribution?

Service Assurance:

It seems problematic to include "assurance" in a DECADE. =C2=A0Sh= ouldn't
these instead be part of SLAs with a storage provider? =C2=A0Why should
they be DECADE's responsibility?

Regarding "resource reservation", are you referring to an actual<= br> reservation (which might be problematic -- see above) or do you mean
that the resource share should able to be specified at the time the
connection opens and be assumed to be the same for the duration of the
connection?

Regarding Dynamic Feedback, is this orthogonal to the storage
protocol? =C2=A0It seems like what you want here is a generic "status&= quot;
service saying how loaded a server is?

th= ats right,=C2=A0actually, the flow control=C2=A0mechanism was under=C2=A0di= scussion=C2=A0in writing the draft at first. what about your=C2=A0opinion i= n this requirements?=C2=A0
=C2=A0
Data classification:

Would it be better to instead have the client specify properties of
the content instead of place it into ? See
www.ietf.org/proceedings/78/slides/nfsv4-0.pdf for an example = of this
approach for NFS.

I think a problem with classifying applications is that it assumes
that applications fit one of the supplied classifications. What if it
may fit multiple classifications? or none? =C2=A0Another problem is it
assumes that servers assume based on indirect and assumed information
that they know what to do with a particular piece of content. Why not
have an application specify its desires directly?

=C2=A0

=C2=A0
Small Objects:

What is the new requirement here? =C2=A0Why is the existing requirement in<= br> draft-ietf-decade-reqs-00 insufficient?

This also has me a bit worried:
"And the in-network storage has the limited storage capacity, with the=
arrival of user requests and data distribution requirements, the data
stored in the in-network storage will be replaced if the storage
reaches the limit and data arrivals continually."

How does the server know what the proper replacement strategy is for
an application? I think DECADE's philosophy is that applications
should decide this. A simple way to do this is explicit deletion by an
application, but perhaps a more efficient (yet more complex) solution
is for an application to specify the replacement policy to the server.

ac= tually, the key in "the data classification and small objects " i= s whether does it or not in P2P application? i did not find data classifica= tion was=C2=A0adopted=C2=A0in P2P application so far, let alone DECADE need= to classify the data used in all kinds of application.

=C2=A0
Removal of Expired Records:

"However, the two scenarios did not mention how to handle the old
resource if the user distributes the new resource which is an updated
copy of the old resource."

Why does this need to be handled in the requirements? =C2=A0Are you trying<= br> to draw the distinction between immediate deletion of content and lazy
deletion?

i = mean the meaning of delete operation and how to handle the expired records = need to be clarify in=C2=A0requirements.=C2=A0
Thanks!
Rich


On Mon, Dec 27, 2010 at 12:57 AM, =E6=9C=B1=E6=BD=87 <buptxiaozhu@gmail.com> wrote:
> Dear all,
>
> There is a slightly updated version of the decade additional requireme= nts
> draft.
> https://datatracker.ietf.org/doc/draft-z= hu-decade-additional-requirements/
>
> Jin Peng, Yunfei Zhang and me are expecting to have a=C2=A0discussion= =C2=A0with all of
> you.
>
> Any comments are appreciated!
>
> A=C2=A0new=C2=A0version=C2=A0of=C2=A0I-D,=C2=A0draft-zhu-decade-additi= onal-requirements-00.txt=C2=A0has=C2=A0been=C2=A0successfully=C2=A0submitte= d=C2=A0by=C2=A0Xiao=C2=A0Zhu=C2=A0and=C2=A0posted=C2=A0to=C2=A0the=C2=A0IET= F=C2=A0repository.
>
> Filename: =C2=A0 =C2=A0 =C2=A0draft-zhu-decade-additional-requirements=
> Revision: =C2=A0 =C2=A0 =C2=A000
> Title: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0Ad= ditional=C2=A0protocol=C2=A0requirements=C2=A0on=C2=A0DECADE
> Creation_date: =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A02010-12-27
> WG=C2=A0ID: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2= =A0Independent=C2=A0Submission
> Number_of_pages:=C2=A010
>
> Abstract:
> The=C2=A0DECoupled=C2=A0Application=C2=A0Data=C2=A0Enroute(DECADE)work= ing=C2=A0group=C2=A0is
> specifying=C2=A0standardized=C2=A0interfaces=C2=A0for=C2=A0accessing= =C2=A0in-network=C2=A0storage
> from=C2=A0applications=C2=A0to=C2=A0store,=C2=A0retrieve=C2=A0and=C2= =A0manage=C2=A0data.=C2=A0The=C2=A0main=C2=A0object
> is=C2=A0to=C2=A0provide=C2=A0a=C2=A0framework=C2=A0that=C2=A0is=C2=A0u= seful=C2=A0to=C2=A0the=C2=A0applications,
> including=C2=A0P2P=C2=A0applications=C2=A0and=C2=A0other=C2=A0data-ori= ented=C2=A0applications,
> possibly=C2=A0related=C2=A0applications=C2=A0that=C2=A0can=C2=A0benefi= t=C2=A0from=C2=A0accessing=C2=A0in-
> network=C2=A0storage.=C2=A0This=C2=A0memo=C2=A0focuses=C2=A0on=C2=A0so= me=C2=A0requirements=C2=A0such=C2=A0as
> request=C2=A0redirecting=C2=A0and=C2=A0so=C2=A0on=C2=A0which=C2=A0are= =C2=A0on=C2=A0the=C2=A0central=C2=A0of=C2=A0mobility,
> wireless=C2=A0network=C2=A0environment=C2=A0and=C2=A0CDN=C2=A0applicat= ion.=C2=A0We=C2=A0present=C2=A0these=C2=A0in
> this=C2=A0memo=C2=A0as=C2=A0additional=C2=A0requirements=C2=A0that=C2= =A0should=C2=A0be=C2=A0considered=C2=A0for
> the=C2=A0DECADE=C2=A0architecture=C2=A0and=C2=A0protocol=C2=A0specific= ations.
>
>
>
> The=C2=A0IETF=C2=A0Secretariat.
>
> --
> Best wishes,
>
> Beijing University of Posts & Telecommunications (BUPT)
> Zhu Xiao=C2=A0 ( =E6=9C=B1=E6=BD=87 )
> E-mail: buptxiaozhu@gmail.com=
> mobile:+86 134-8881-9004
>
> _______________________________________________
> decade mailing list
> decade@ietf.org
> https://www.ietf.org/mailman/listinfo/decade
>
>



--
Best wishes,

Bei= jing University of Posts & Telecommunications (BUPT)
Zhu Xiao=C2=A0 = ( =E6=9C=B1=E6=BD=87 )
E-mail: buptxiaozhu@gmail.com
mobile:+86 134-8881-9004
--0015174c441c676f4d049989148e-- From richard.alimi@gmail.com Mon Jan 10 22:15:28 2011 Return-Path: X-Original-To: decade@core3.amsl.com Delivered-To: decade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD9C93A6998 for ; Mon, 10 Jan 2011 22:15:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.222 X-Spam-Level: X-Spam-Status: No, score=-1.222 tagged_above=-999 required=5 tests=[AWL=-0.995, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a0DlAQ7Z6KBF for ; Mon, 10 Jan 2011 22:15:24 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id 18FC73A6992 for ; Mon, 10 Jan 2011 22:15:24 -0800 (PST) Received: by iyi42 with SMTP id 42so20123483iyi.31 for ; Mon, 10 Jan 2011 22:17:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=GjSGZRUgLXNnXxdza/N4RRClk4AoOvk2tiAcaosqL/w=; b=LGogC3XFF73Km/abX6FyaMFK8LWLncatmFvHM5YM9Cvx5sYy+u4qJce4k0IUpLPvOB wvE+HQmNixnO6pJMdxhk4PSRoEHoZMd9JeD2dIPCLERbbE5EfORo2M8zxPFADUnPKt1V A5OqlRm56vganzr3Dbpftgmd9vR7k8D4CcfCo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=YL90sXUV6/sGDQeNocEJq2Hut0XQ4rD5QDL8dJZbFk4MiPa6pbmjwVQ7ls7fNYgJeS n644qPfhDIMCmyyVq4wmZcHdPTZmZOftGu2NaGAKQNX0lW8iAX13M5eb891INmJavZGH TzU2fh4ejdskcIT2wYAJAAHAtgPLs/iwcvtG8= MIME-Version: 1.0 Received: by 10.231.11.139 with SMTP id t11mr19653876ibt.189.1294726659045; Mon, 10 Jan 2011 22:17:39 -0800 (PST) Sender: richard.alimi@gmail.com Received: by 10.231.11.66 with HTTP; Mon, 10 Jan 2011 22:17:38 -0800 (PST) In-Reply-To: References: Date: Mon, 10 Jan 2011 22:17:38 -0800 X-Google-Sender-Auth: 8ljkjtote8Gjh8PxgfDcomtW1HI Message-ID: From: Richard Alimi To: =?UTF-8?B?5pyx5r2H?= Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable Cc: decade@ietf.org Subject: Re: [decade] draft-zhu-decade-additional-requirements X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jan 2011 06:15:28 -0000 Hi Xiao, On Mon, Jan 10, 2011 at 6:45 PM, =D6=EC=E4=EC wrote= : > > hi, Richard, sorry for so late response because of be busy with other pro= jects. > some discussion see inline:D marked by red. > > On Tue, Jan 4, 2011 at 4:06 AM, Richard Alimi wrote: >> >> Hi Xiao, >> >> Thank you for the draft. Some comments on the requirements: >> >> Request Redirects: >> >> This would provide some additional freedom for the storage provider. >> I think it is reasonable since it doesn't necessitate additional >> complexity for the DECADE server, but allows it if desired. However, >> note that it may complicate some of the other components of the >> design. In particular, if there is a per-user quota for storage, is >> the user made aware of the quota at each in-network storage (if there >> is no shared storage between them)? Resource sharing policies may be >> impacted (e.g., if a bandwidth sharing weight of 1 may mean something >> different at DECADE server A than it does at DECADE server B). At >> this point it may be best to just note these so they are documented, >> but since the specification of the resource sharing policies are still >> being contemplated for the basic case of a single server it may be >> premature to even try and solve them for the case supporting >> redirection. >> > actually, you mean two points, right? > 1. whether or not to be ware of the content at each in-network storage an= d of course resource sharing policies can be impact in the request redirect= ion. your suggestion"just to note these so they are documented" will be ok,= or DECADE server list with some parameters will be return for user to sele= ct the appropriate DECADE server, which can avoid the different weighted of= the same parameter in server decision. but the parameter used in select th= e best DECADE server will be known for DECADE servers, in which other compl= exities will be added. anyway, all the solution are the implementation issu= e, which, i believe, does not impact the necessity of the requirement. In general, I'd agree that the decision about where to redirect would be an implementation issue. > > 2. you mean "the resource sharing policies are still being considered in = a single server", so it may be premature to support redirection. the archi= tecture and protocol will be badly impacted if the requirements change. so = the designing can be taken step by step, but the requirements should be o= verall considered. I said that it is probably premature to consider how resource sharing policies works across servers (or even if we need to say anything about it) since we have not determined how to specify them (or rather, how little we need to specify in protocol) for a single server. I did not mean to imply that redirection could not be introduced as a requirement. > > >> >> Multi-connection: >> >> I'm not quite clear on the intention of the requirement. My >> understanding is that you wish the client to be able to have multiple >> connections open spanning multiple DECADE servers. Is that correct? >> >> If so, do we need this stated as a requirement or the protocol? Or is >> this a policy that would be allowed/disallowed by the storage >> provider? >> > yep, your understanding is right, the scenarios were just described in dr= aft as "soft handover in wireless environment and delete operation in multi= -servers". under these consideration, the authentication and authorization = need to be taken each time when setup connection with a new DECADE server, = or just be taken only once during the service? The DECADE server should need to do some sort of check on each new connection, regardless of whether the user has or previously had a connection open to a different DECADE server, right? Note that the requirements don't indicate how authentication or authorization is done, and allow a server to make optimizations if it is enforcing the same permissions. Can you indicate where the existing authorization-related requirements (in particular, 4.1.6.3 of draft-ietf-decade-reqs-00) do not suffice for the use case you are thinking of? > > >> >> Data Distribution: >> >> I'm also confused about the intent of this requirement. This >> statement has me somewhat worried: "The distribution is transparent to >> the users as they interact with the in-network storage as a single >> logical system." Does this mean that you are proposing for DECADE >> servers to assume the responsibility for deciding how data is to be >> distributed throughout the network, including the path of the data, >> which servers act as intermediate caches, content expiration policies, >> etc? If this is true, I think it is missing one of the major points >> of DECADE. In particular, these decisions are application-dependent >> and are not implemented within DECADE. Instead, DECADE provides the >> basic capabilities and the functionality described above are >> implemented by the applications using DECADE. >> >> Or, am I misinterpreting the intent of the requirement? >> > you mean DECADE provides the basic capabilities, so can you give some spe= cify explanations on DECADE capabilities in supporting data distribution? >> The problem statement gives a couple of scenarios. The "Integration Examples" presentation from IETF 79 also has more details of an on-going effort at Yale. >> Service Assurance: >> >> It seems problematic to include "assurance" in a DECADE. Shouldn't >> these instead be part of SLAs with a storage provider? Why should >> they be DECADE's responsibility? >> >> Regarding "resource reservation", are you referring to an actual >> reservation (which might be problematic -- see above) or do you mean >> that the resource share should able to be specified at the time the >> connection opens and be assumed to be the same for the duration of the >> connection? >> >> Regarding Dynamic Feedback, is this orthogonal to the storage >> protocol? It seems like what you want here is a generic "status" >> service saying how loaded a server is? >> > thats right, actually, the flow control mechanism was under discussion in= writing the draft at first. what about your opinion in this requirements? > I'm not sure what the typical way of providing such "load status" information for IETF protocols, but my inclination is that it should not be in the DECADE protocol itself. Maybe someone else with a longer history in IETF could jump in here :) >> >> Data classification: >> >> Would it be better to instead have the client specify properties of >> the content instead of place it into ? See >> www.ietf.org/proceedings/78/slides/nfsv4-0.pdf for an example of this >> approach for NFS. >> >> I think a problem with classifying applications is that it assumes >> that applications fit one of the supplied classifications. What if it >> may fit multiple classifications? or none? Another problem is it >> assumes that servers assume based on indirect and assumed information >> that they know what to do with a particular piece of content. Why not >> have an application specify its desires directly? >> > > >> >> Small Objects: >> >> What is the new requirement here? Why is the existing requirement in >> draft-ietf-decade-reqs-00 insufficient? >> >> This also has me a bit worried: >> "And the in-network storage has the limited storage capacity, with the >> arrival of user requests and data distribution requirements, the data >> stored in the in-network storage will be replaced if the storage >> reaches the limit and data arrivals continually." >> >> How does the server know what the proper replacement strategy is for >> an application? I think DECADE's philosophy is that applications >> should decide this. A simple way to do this is explicit deletion by an >> application, but perhaps a more efficient (yet more complex) solution >> is for an application to specify the replacement policy to the server. >> > actually, the key in "the data classification and small objects " is whet= her does it or not in P2P application? i did not find data classification w= as adopted in P2P application so far, let alone DECADE need to classify the= data used in all kinds of application. > So, do you agree that it is problematic to try and classify each type of application and try to specify the typical workload for each class? My point was that I don't think its necessary to do the classification at all. It is more extensible (and directly useful) for a server to just give it direct hints about what would be preferable. >> >> Removal of Expired Records: >> >> "However, the two scenarios did not mention how to handle the old >> resource if the user distributes the new resource which is an updated >> copy of the old resource." >> >> Why does this need to be handled in the requirements? Are you trying >> to draw the distinction between immediate deletion of content and lazy >> deletion? >> > i mean the meaning of delete operation and how to handle the expired reco= rds need to be clarify in requirements. My inclination is that "deleted" means that other requests the object of the same name should result an error, until another object with the same name is stored. I think that the time the data is removed from disk (or memory) should be up to the implementation. A storage provider might still have as part of some agreement that deleted data will be removed within X days/hours/minutes/whatever. If people in the WG think it is necessary, we could have a requirement that says the protocol should support an argument indicating immediate deletion, but it is not clear that we need this. Rich >> >> Thanks! >> Rich >> >> >> On Mon, Dec 27, 2010 at 12:57 AM, =D6=EC=E4=EC w= rote: >> > Dear all, >> > >> > There is a slightly updated version of the decade additional requireme= nts >> > draft. >> > https://datatracker.ietf.org/doc/draft-zhu-decade-additional-requireme= nts/ >> > >> > Jin Peng, Yunfei Zhang and me are expecting to have a discussion with = all of >> > you. >> > >> > Any comments are appreciated! >> > >> > A new version of I-D, draft-zhu-decade-additional-requirements-00.txt = has been successfully submitted by Xiao Zhu and posted to the IETF reposito= ry. >> > >> > Filename: draft-zhu-decade-additional-requirements >> > Revision: 00 >> > Title: Additional protocol requirements on DECADE >> > Creation_date: 2010-12-27 >> > WG ID: Independent Submission >> > Number_of_pages: 10 >> > >> > Abstract: >> > The DECoupled Application Data Enroute(DECADE)working group is >> > specifying standardized interfaces for accessing in-network storage >> > from applications to store, retrieve and manage data. The main object >> > is to provide a framework that is useful to the applications, >> > including P2P applications and other data-oriented applications, >> > possibly related applications that can benefit from accessing in- >> > network storage. This memo focuses on some requirements such as >> > request redirecting and so on which are on the central of mobility, >> > wireless network environment and CDN application. We present these in >> > this memo as additional requirements that should be considered for >> > the DECADE architecture and protocol specifications. >> > >> > >> > >> > The IETF Secretariat. >> > >> > -- >> > Best wishes, >> > >> > Beijing University of Posts & Telecommunications (BUPT) >> > Zhu Xiao ( =D6=EC=E4=EC ) >> > E-mail: buptxiaozhu@gmail.com >> > mobile:+86 134-8881-9004 >> > >> > _______________________________________________ >> > decade mailing list >> > decade@ietf.org >> > https://www.ietf.org/mailman/listinfo/decade >> > >> > > > > > -- > Best wishes, > > Beijing University of Posts & Telecommunications (BUPT) > Zhu Xiao ( =D6=EC=E4=EC ) > E-mail: buptxiaozhu@gmail.com > mobile:+86 134-8881-9004 From ove.strandberg@nsn.com Wed Jan 12 04:02:16 2011 Return-Path: X-Original-To: decade@core3.amsl.com Delivered-To: decade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0904628C10C for ; Wed, 12 Jan 2011 04:02:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JiWp9JFoSpqb for ; Wed, 12 Jan 2011 04:02:12 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id 5250F28C0FE for ; Wed, 12 Jan 2011 04:02:10 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id p0CC4Qmu022316 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 12 Jan 2011 13:04:26 +0100 Received: from demuexc025.nsn-intra.net (demuexc025.nsn-intra.net [10.159.32.12]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id p0CC4M5P012506; Wed, 12 Jan 2011 13:04:25 +0100 Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Wed, 12 Jan 2011 13:04:21 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CBB250.D8B9C895" Date: Wed, 12 Jan 2011 14:04:16 +0200 Message-ID: In-Reply-To: <1CA25301D2219F40B3AA37201F0EACD1063FAD@PACDCEXMB05.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [decade] Reviews of the Decade Survey draft Thread-Index: AcuclJdof7II0b1bR9GixOWzuqDcEAQnUi7gAUbpC0A= References: <1CA25301D2219F40B3AA37201F0EACD104CB25@PACDCEXMB05.cable.comcast.com> <1CA25301D2219F40B3AA37201F0EACD1063FAD@PACDCEXMB05.cable.comcast.com> From: "Strandberg, Ove (NSN - FI/Espoo)" To: "ext Woundy, Richard" , X-OriginalArrivalTime: 12 Jan 2011 12:04:21.0355 (UTC) FILETIME=[D8BC7BB0:01CBB250] Subject: Re: [decade] Reviews of the Decade Survey draft X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jan 2011 12:02:16 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBB250.D8B9C895 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Decaders, =20 I would like to add additional review of the survey document with this email. Thanks for a good survey document! Further the previous reviews have been very good and my additions are few.=20 =20 Generally in section Discovery Mechanism there could be a mention that DNS is ultimately used as way to configure data access. This is could be stated for instance when the section describes the use of host name, here the addition of DNS is easy. However, not all systems use DNS and an explicit way to make this clear would be beneficial.=20 =20 I am unsure of the right "protocol" for authorship, in Acknowledgement section is a bunch of names that more or less has text directly in the survey document. Should these names be included as authors? My perception has been that Acknowledgement is used for other purposes. =20 Nits: =20 4.7, para 3, line 3: "ued" should be "used" 4.7.2, line 3: "ID make" should be "ID to make" =20 Regarding the review comment of user-controlled / network-controlled, the concern might be better to address in other documents like design documents etc.. =20 Br, =20 +Ove =20 From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.org] On Behalf Of ext Woundy, Richard Sent: 06 January, 2011 01:47 To: 'decade@ietf.org' Subject: Re: [decade] Reviews of the Decade Survey draft =20 I would like to express my thanks to the reviewers of the survey draft! =20 David Bryan http://www.ietf.org/mail-archive/web/decade/current/msg00342.html Yunfei Zhang http://www.ietf.org/mail-archive/web/decade/current/msg00340.html =20 I would like to see at least one more review posted to the mailing list, before the authors incorporate this feedback into the next draft. =20 I check this draft with idnits (http://tools.ietf.org/idnits?url=3Dhttp://tools.ietf.org/id/draft-ietf-d= e cade-survey-02.txt), and I believe the only significant issue there has already identified by David Bryan: =20 =3D=3D Outdated reference: A later version (-01) exists of draft-ietf-decade-problem-statement-00 =20 -- Rich =20 From: Woundy, Richard=20 Sent: Wednesday, December 15, 2010 3:14 PM To: 'decade@ietf.org' Cc: Songhaibin; Woundy, Richard Subject: Reviews of the Decade Survey draft =20 Folks, =20 We would like to prepare the survey draft, draft-ietf-decade-survey-01 , for working group last call in January. =20 The chairs are looking for document reviews to be sent to the mailing list by Wednesday December 29. We already have three volunteers from our session in Beijing. Additional draft reviews by the deadline would be timely and greatly appreciated. =20 After the authors incorporate the feedback from the reviews in a new draft iteration, the chairs expect to take the draft to WGLC. =20 -- Rich ------_=_NextPart_001_01CBB250.D8B9C895 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Decaders,

 

I would like to add = additional review of the survey document with this email. Thanks for a = good survey document! Further the previous reviews have been very good = and my additions are few.

 

Generally in section = Discovery Mechanism there could be a mention that DNS is ultimately used = as way to configure data access. This is could be stated for instance = when the section describes the use of host name, here the addition of = DNS is easy. However, not all systems use DNS and an explicit way to = make this clear would be beneficial.

 

I am unsure of the right = “protocol” for authorship, in Acknowledgement section is a = bunch of names that more or less has text directly in the survey = document. Should these names be included as authors? My perception has = been that Acknowledgement is used for other = purposes.

 

Nits:

 

4.7, para 3, line 3: “ued” should be = “used”

4.7.2, line 3: = “ID make” should be “ID to = make”

 

Regarding the review = comment of user-controlled / network-controlled, the concern might be = better to address in other documents like design documents = etc..

 

Br,

 

+Ove

 

From:= = decade-bounces@ietf.org [mailto:decade-bounces@ietf.org] On Behalf Of = ext Woundy, Richard
Sent: 06 January, 2011 = 01:47
To: 'decade@ietf.org'
Subject: Re: [decade] = Reviews of the Decade Survey draft

 

I would like to express my thanks to the = reviewers of the survey draft!

 

David = Bryan

http://www.ietf.org/mail-archive/web/decade/current/msg00342.html

Yunfei Zhang

http://www.ietf.org/mail-archive/web/decade/current/msg00340.html

 

I would like to see at = least one more review posted to the mailing list, before the authors = incorporate this feedback into the next draft.

 

I check this draft with = idnits (http://tools.ietf.org/idnits?url=3Dhttp://too= ls.ietf.org/id/draft-ietf-decade-survey-02.txt), and I believe the = only significant issue there has already identified by David = Bryan:

 

  =3D=3D Outdated = reference: A later version (-01) exists of

     = draft-ietf-decade-problem-statement-00

 

-- = Rich

 

From:= = Woundy, Richard
Sent: Wednesday, December 15, 2010 3:14 = PM
To: 'decade@ietf.org'
Cc: Songhaibin; Woundy, = Richard
Subject: Reviews of the Decade Survey = draft

 

Folks,

 

We would = like to prepare the survey draft, draft-= ietf-decade-survey-01, for working group last call in = January.

 

The chairs are looking for document reviews to be sent = to the mailing list by Wednesday December 29. We already have three = volunteers from our session in Beijing. Additional draft reviews by the = deadline would be timely and greatly appreciated.

 

After the = authors incorporate the feedback from the reviews in a new draft = iteration, the chairs expect to take the draft to WGLC.

 

-- = Rich

------_=_NextPart_001_01CBB250.D8B9C895-- From richard_woundy@cable.comcast.com Wed Jan 12 08:18:22 2011 Return-Path: X-Original-To: decade@core3.amsl.com Delivered-To: decade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D8F3F28C0EE for ; Wed, 12 Jan 2011 08:18:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.046 X-Spam-Level: X-Spam-Status: No, score=-107.046 tagged_above=-999 required=5 tests=[AWL=1.416, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FCN9h9+wHup3 for ; Wed, 12 Jan 2011 08:18:18 -0800 (PST) Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by core3.amsl.com (Postfix) with ESMTP id D22293A6A4B for ; Wed, 12 Jan 2011 08:18:17 -0800 (PST) Received: from ([24.40.55.41]) by pacdcimo01.cable.comcast.com with ESMTP with TLS id 5503620.110664878; Wed, 12 Jan 2011 11:21:44 -0500 Received: from PACDCEXMB05.cable.comcast.com ([fe80::a5b0:e5c4:df1b:2367]) by PACDCEXHUB02.cable.comcast.com ([fe80::11d4:f530:37a0:9f4e%12]) with mapi id 14.01.0270.001; Wed, 12 Jan 2011 11:20:35 -0500 From: "Woundy, Richard" To: "Strandberg, Ove (NSN - FI/Espoo)" Thread-Topic: [decade] Reviews of the Decade Survey draft Thread-Index: AcuclJdof7II0b1bR9GixOWzuqDcEAQnUi7gAUbpC0AACbp5oA== Date: Wed, 12 Jan 2011 16:20:34 +0000 Message-ID: <1CA25301D2219F40B3AA37201F0EACD1067043@PACDCEXMB05.cable.comcast.com> References: <1CA25301D2219F40B3AA37201F0EACD104CB25@PACDCEXMB05.cable.comcast.com> <1CA25301D2219F40B3AA37201F0EACD1063FAD@PACDCEXMB05.cable.comcast.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [76.96.111.6] Content-Type: multipart/alternative; boundary="_000_1CA25301D2219F40B3AA37201F0EACD1067043PACDCEXMB05cablec_" MIME-Version: 1.0 Cc: "decade@ietf.org" Subject: Re: [decade] Reviews of the Decade Survey draft X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jan 2011 16:18:23 -0000 --_000_1CA25301D2219F40B3AA37201F0EACD1067043PACDCEXMB05cablec_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Ove, thanks for the review! I believe we have a sufficient number of reviews for the authors to incorpo= rate this feedback, and to produce a new revision for WGLC. -- Rich From: Strandberg, Ove (NSN - FI/Espoo) [mailto:ove.strandberg@nsn.com] Sent: Wednesday, January 12, 2011 7:04 AM To: Woundy, Richard; decade@ietf.org Subject: RE: [decade] Reviews of the Decade Survey draft Hi Decaders, I would like to add additional review of the survey document with this emai= l. Thanks for a good survey document! Further the previous reviews have bee= n very good and my additions are few. Generally in section Discovery Mechanism there could be a mention that DNS = is ultimately used as way to configure data access. This is could be stated= for instance when the section describes the use of host name, here the add= ition of DNS is easy. However, not all systems use DNS and an explicit way = to make this clear would be beneficial. I am unsure of the right "protocol" for authorship, in Acknowledgement sect= ion is a bunch of names that more or less has text directly in the survey d= ocument. Should these names be included as authors? My perception has been = that Acknowledgement is used for other purposes. Nits: 4.7, para 3, line 3: "ued" should be "used" 4.7.2, line 3: "ID make" should be "ID to make" Regarding the review comment of user-controlled / network-controlled, the c= oncern might be better to address in other documents like design documents = etc.. Br, +Ove From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.org] On Behalf Of= ext Woundy, Richard Sent: 06 January, 2011 01:47 To: 'decade@ietf.org' Subject: Re: [decade] Reviews of the Decade Survey draft I would like to express my thanks to the reviewers of the survey draft! David Bryan http://www.ietf.org/mail-archive/web/decade/current/msg00342.html Yunfei Zhang http://www.ietf.org/mail-archive/web/decade/current/msg00340.html I would like to see at least one more review posted to the mailing list, be= fore the authors incorporate this feedback into the next draft. I check this draft with idnits (http://tools.ietf.org/idnits?url=3Dhttp://t= ools.ietf.org/id/draft-ietf-decade-survey-02.txt), and I believe the only s= ignificant issue there has already identified by David Bryan: =3D=3D Outdated reference: A later version (-01) exists of draft-ietf-decade-problem-statement-00 -- Rich From: Woundy, Richard Sent: Wednesday, December 15, 2010 3:14 PM To: 'decade@ietf.org' Cc: Songhaibin; Woundy, Richard Subject: Reviews of the Decade Survey draft Folks, We would like to prepare the survey draft, draft-ietf-decade-survey-01, for working group l= ast call in January. The chairs are looking for document reviews to be sent to the mailing list = by Wednesday December 29. We already have three volunteers from our session= in Beijing. Additional draft reviews by the deadline would be timely and g= reatly appreciated. After the authors incorporate the feedback from the reviews in a new draft = iteration, the chairs expect to take the draft to WGLC. -- Rich --_000_1CA25301D2219F40B3AA37201F0EACD1067043PACDCEXMB05cablec_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Ove, thanks for the re= view!

 

I believe we have a su= fficient number of reviews for the authors to incorporate this feedback, an= d to produce a new revision for WGLC.

 

-- Rich

 

From: Strandbe= rg, Ove (NSN - FI/Espoo) [mailto:ove.strandberg@nsn.com]
Sent: Wednesday, January 12, 2011 7:04 AM
To: Woundy, Richard; decade@ietf.org
Subject: RE: [decade] Reviews of the Decade Survey draft<= /span>

 

Hi Decaders,

 

I would like to add ad= ditional review of the survey document with this email. Thanks for a good s= urvey document! Further the previous reviews have been very good and my add= itions are few.

 

Generally in section D= iscovery Mechanism there could be a mention that DNS is ultimately used as = way to configure data access. This is could be stated for instance when the= section describes the use of host name, here the addition of DNS is easy. However, not all systems use DNS and an = explicit way to make this clear would be beneficial.

 

I am unsure of the rig= ht “protocol” for authorship, in Acknowledgement section is a b= unch of names that more or less has text directly in the survey document. S= hould these names be included as authors? My perception has been that Acknowledgement is used for other purposes.

 

Nits:

 

4.7, para 3, line 3: “ued” should be = 220;used”

4.7.2, line 3: “ID make” should be ̶= 0;ID to make”

 

Regarding the review c= omment of user-controlled / network-controlled, the concern might be better= to address in other documents like design documents etc..

 

Br,<= /p>

 

+Ove

 

From: decade-b= ounces@ietf.org [mailto:decade-bounces@ietf.org] On Behalf Of ext Woundy, Richard
Sent: 06 January, 2011 01:47
To: 'decade@ietf.org'
Subject: Re: [decade] Reviews of the Decade Survey draft<= /span>

 

I would like to expres= s my thanks to the reviewers of the survey draft!

 

David Bryan

http://www.ietf.org= /mail-archive/web/decade/current/msg00342.html

Yunfei Zhang<= /span>

http://www.ietf.org= /mail-archive/web/decade/current/msg00340.html

 

I would like to see at= least one more review posted to the mailing list, before the authors incor= porate this feedback into the next draft.

 

I check this draft wit= h idnits (http://tools.ietf.org/idnits?url=3Dh= ttp://tools.ietf.org/id/draft-ietf-decade-survey-02.txt), and I believe the only significant issue there has already identified by D= avid Bryan:

 

  =3D=3D Outdated= reference: A later version (-01) exists of

   &nbs= p; draft-ietf-decade-problem-statement-00

 

-- Rich

 

From: Woundy, = Richard
Sent: Wednesday, December 15, 2010 3:14 PM
To: 'decade@ietf.org'
Cc: Songhaibin; Woundy, Richard
Subject: Reviews of the Decade Survey draft

 

Folks,

 

We would like to prepare the survey draft, draft-ietf-decade-survey-01, for working group last call in January.

 

The chairs are looking for document reviews to be se= nt to the mailing list by Wednesday December 29. We already have three volu= nteers from our session in Beijing. Additional draft reviews by the deadlin= e would be timely and greatly appreciated.

 

After the authors incorporate the feedback from the = reviews in a new draft iteration, the chairs expect to take the draft to WG= LC.

 

-- Rich

--_000_1CA25301D2219F40B3AA37201F0EACD1067043PACDCEXMB05cablec_-- From abcdmatao@gmail.com Wed Jan 12 17:34:36 2011 Return-Path: X-Original-To: decade@core3.amsl.com Delivered-To: decade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF4923A67B1 for ; Wed, 12 Jan 2011 17:34:36 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v1-BzXFjEelu for ; Wed, 12 Jan 2011 17:34:35 -0800 (PST) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 3E7BF3A6778 for ; Wed, 12 Jan 2011 17:34:35 -0800 (PST) Received: by wyf23 with SMTP id 23so1278847wyf.31 for ; Wed, 12 Jan 2011 17:36:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to:cc :content-type; bh=ydu0Xx+GkgD1f9XXoqBR9F/R2WvZN5lH9PvtQe2AhLQ=; b=Ty8Yaz1MY1NiGdAWDKbyy+GZmBma26W66o7Dk2y5szSW9CE+QkHv/zck7B7EYrX1i3 mau9LLeNLBE0Zx+zhYuFOGa8NAS5fmXk58qBO4aeydl9VPhTMXFhaQ1e4OleF3dn5OsB 7ZNZWLCNdDNtY+T/oZY6CMgQeCcJoIDvRag2Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=FtDpoW7kPMdsDawiXZ9vuhLTw43+GRQaWy7nJM3ZWouu2GieFE0MZ4B54YU4eXf8AR DLUpYwqyTxm182Kmpnis4vwz2qjcGDavKOLURv7qzw1EwFwwBvSrc2KK4RYLWzve6OnI jopyR6EY+BhUStO6j83x0Ogd3xo9MxyP1Rey8= MIME-Version: 1.0 Received: by 10.216.16.21 with SMTP id g21mr1514749weg.6.1294882615552; Wed, 12 Jan 2011 17:36:55 -0800 (PST) Received: by 10.216.47.12 with HTTP; Wed, 12 Jan 2011 17:36:55 -0800 (PST) Date: Thu, 13 Jan 2011 09:36:55 +0800 Message-ID: From: Tao Ma To: decade@ietf.org Content-Type: multipart/alternative; boundary=0015176f16f6536c8b0499b05a00 Cc: qiuxiaofeng@gmail.com, ch zhang Subject: Re: [decade] Reviews of the Decade Survey draft X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2011 01:34:36 -0000 --0015176f16f6536c8b0499b05a00 Content-Type: text/plain; charset=ISO-8859-1 Hi, all I'd also like to add some reviews on the survey draft. I think it a very comprehensive survey of current in-network storage system.I have some minor comments: 1 In section 2.2 "Historical Context", it mainly mentioned web cache and CDN as the historical predecessor of DECADE. However, I believe "P2P cache" should be mentioned here too, which is highlighted in problem statement draft. 2 As yunfei zhang has mentioned in *** http://www.ietf.org/mail-archive/web/decade/current/msg00340.html*, I also agree to emphasize the mobile scenarios which is not sufficiently described in current survey draft. 3 In the first line of secion 4.3.1, "sysem" should be "system" 4 In section 4.5.4, "Not applicable" should be "Not provided" as the other system described for uniform reason Tao Ma Beijing University of Posts and Telecommunications, MINElab --0015176f16f6536c8b0499b05a00 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, all
=A0=A0=A0 I'd also like to add some reviews on the survey dr= aft. I think it a very comprehensive survey of current in-network storage s= ystem.I have some minor comments:
=A0=A0=A0 1 In section 2.2 "Histo= rical Context", it mainly mentioned web cache and CDN as the historica= l predecessor of DECADE. However, I believe "P2P cache" should be= mentioned here too, which is highlighted in problem statement draft.
=A0=A0=A0 2 As yunfei zhang has mentioned in http://www.ietf.org/mail-archive/web/de= cade/current/msg00340.html, I also agree to emphasize the mobile sc= enarios which is not sufficiently described in current survey draft.
=A0=A0=A0 3 In the first line of secion 4.3.1, "sysem" should be = "system"
=A0=A0=A0 4 In section 4.5.4, "Not applicable&qu= ot; should be "Not provided" as the other system described for un= iform reason

Tao Ma
Beijing University of Posts and Telecommunications, MINElab=A0=A0
--0015176f16f6536c8b0499b05a00-- From buptxiaozhu@gmail.com Wed Jan 12 17:57:45 2011 Return-Path: X-Original-To: decade@core3.amsl.com Delivered-To: decade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B3A9C3A67B1 for ; Wed, 12 Jan 2011 17:57:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.131 X-Spam-Level: X-Spam-Status: No, score=0.131 tagged_above=-999 required=5 tests=[AWL=-2.221, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QJ8K9-d78jrw for ; Wed, 12 Jan 2011 17:57:43 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id B24EE3A67D1 for ; Wed, 12 Jan 2011 17:57:42 -0800 (PST) Received: by iyi42 with SMTP id 42so1192839iyi.31 for ; Wed, 12 Jan 2011 18:00:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=4XlRVOJSAIO5gyuLLI+083cUfr0PxKDDE9w6sVYAAj0=; b=Zexg349qWlWj7xt6y/UzLogZgh3VeBp1XryL/HQm+PsTXBFwMt5+KyEY6Du8hRFwKP DxokSIZXuS+SAyJ2XIqcpwqkO9SZ67wDubFbhOkNOry1IRY0ZZIG8MFhO/368Raxcsj7 /IUjfGngSCCKEtzhbgbB7dBbf0WDIF6ySYKss= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=UdwqiPaxlE35dOU0blmEo7Ul+CRFsr5TkQfBB5eBXvA9SeKvOPnRznSQcSeqQnm0tZ Sv5Hep4Na4MMfR/sifIntSx5tMsEQVYlspl8bk+r4A1sv0F1hDSzvEGSQLfM9qfarePl zJMapxgIvkNIPAosF7SCSX6FUi3L5BJWSQqro= MIME-Version: 1.0 Received: by 10.42.225.134 with SMTP id is6mr1873397icb.338.1294884003591; Wed, 12 Jan 2011 18:00:03 -0800 (PST) Received: by 10.42.12.212 with HTTP; Wed, 12 Jan 2011 18:00:03 -0800 (PST) In-Reply-To: References: Date: Thu, 13 Jan 2011 10:00:03 +0800 Message-ID: From: =?GB2312?B?1uzk7A==?= To: decade@ietf.org Content-Type: multipart/alternative; boundary=20cf30549a6f0f36690499b0ad74 Subject: [decade] Fwd: draft-zhu-decade-additional-requirements X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2011 01:57:45 -0000 --20cf30549a6f0f36690499b0ad74 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable ---------- Forwarded message ---------- From: =D6=EC=E4=EC Date: 2011/1/13 Subject: Re: [decade] draft-zhu-decade-additional-requirements To: Richard Alimi hi, Richard see inline:D 2011/1/11 Richard Alimi Hi Xiao, > > On Mon, Jan 10, 2011 at 6:45 PM, =D6=EC=E4=EC wro= te: > > > > hi, Richard, sorry for so late response because of be busy with other > projects. > > some discussion see inline:D marked by red. > > > > On Tue, Jan 4, 2011 at 4:06 AM, Richard Alimi > wrote: > >> > >> Hi Xiao, > >> > >> Thank you for the draft. Some comments on the requirements: > >> > >> Request Redirects: > >> > >> This would provide some additional freedom for the storage provider. > >> I think it is reasonable since it doesn't necessitate additional > >> complexity for the DECADE server, but allows it if desired. However, > >> note that it may complicate some of the other components of the > >> design. In particular, if there is a per-user quota for storage, is > >> the user made aware of the quota at each in-network storage (if there > >> is no shared storage between them)? Resource sharing policies may be > >> impacted (e.g., if a bandwidth sharing weight of 1 may mean something > >> different at DECADE server A than it does at DECADE server B). At > >> this point it may be best to just note these so they are documented, > >> but since the specification of the resource sharing policies are still > >> being contemplated for the basic case of a single server it may be > >> premature to even try and solve them for the case supporting > >> redirection. > >> > > actually, you mean two points, right? > > 1. whether or not to be ware of the content at each in-network storage > and of course resource sharing policies can be impact in the request > redirection. your suggestion"just to note these so they are documented" w= ill > be ok, or DECADE server list with some parameters will be return for user= to > select the appropriate DECADE server, which can avoid the different weigh= ted > of the same parameter in server decision. but the parameter used in selec= t > the best DECADE server will be known for DECADE servers, in which other > complexities will be added. anyway, all the solution are the implementati= on > issue, which, i believe, does not impact the necessity of the requirement= . > > In general, I'd agree that the decision about where to redirect would > be an implementation issue. > > > > > 2. you mean "the resource sharing policies are still being considered i= n > a single server", so it may be premature to support redirection. the > architecture and protocol will be badly impacted if the requirements chan= ge. > so the designing can be taken step by step, but the requirements should= be > overall considered. > > I said that it is probably premature to consider how resource sharing > policies works across servers (or even if we need to say anything > about it) since we have not determined how to specify them (or rather, > how little we need to specify in protocol) for a single server. I did > not mean to imply that redirection could not be introduced as a > requirement. > > > > > > > >> > >> Multi-connection: > >> > >> I'm not quite clear on the intention of the requirement. My > >> understanding is that you wish the client to be able to have multiple > >> connections open spanning multiple DECADE servers. Is that correct? > >> > >> If so, do we need this stated as a requirement or the protocol? Or is > >> this a policy that would be allowed/disallowed by the storage > >> provider? > >> > > yep, your understanding is right, the scenarios were just described in > draft as "soft handover in wireless environment and delete operation in > multi-servers". under these consideration, the authentication and > authorization need to be taken each time when setup connection with a new > DECADE server, or just be taken only once during the service? > > The DECADE server should need to do some sort of check on each new > connection, regardless of whether the user has or previously had a > connection open to a different DECADE server, right? Note that the > requirements don't indicate how authentication or authorization is > done, and allow a server to make optimizations if it is enforcing the > same permissions. > > Can you indicate where the existing authorization-related requirements > (in particular, 4.1.6.3 of draft-ietf-decade-reqs-00) do not suffice > for the use case you are thinking of? > as considering the service continuity, the next serving DECADE server > should know the progress of the service, how does they know? so if the > service proceeding information should be known by the next serving server= , > or different servers need to coordinate and schedule each other to fulfil= l > the user request, i believe the the 4.1.6.3 of the draft-ietf-decade-req-= 00 > cannot satisfy the req. what do you think about? > > > > > > >> > >> Data Distribution: > >> > >> I'm also confused about the intent of this requirement. This > >> statement has me somewhat worried: "The distribution is transparent to > >> the users as they interact with the in-network storage as a single > >> logical system." Does this mean that you are proposing for DECADE > >> servers to assume the responsibility for deciding how data is to be > >> distributed throughout the network, including the path of the data, > >> which servers act as intermediate caches, content expiration policies, > >> etc? If this is true, I think it is missing one of the major points > >> of DECADE. In particular, these decisions are application-dependent > >> and are not implemented within DECADE. Instead, DECADE provides the > >> basic capabilities and the functionality described above are > >> implemented by the applications using DECADE. > >> > >> Or, am I misinterpreting the intent of the requirement? > >> > > you mean DECADE provides the basic capabilities, so can you give some > specify explanations on DECADE capabilities in supporting data distributi= on? > >> > > The problem statement gives a couple of scenarios. The "Integration > Examples" presentation from IETF 79 also has more details of an > on-going effort at Yale. > okay, thx for your information, i will lookup and refer, actually, the > content publisher described in problem statement remind me of the > protocol requirements which i did not find in draft-ietf-decade-reqs-00 t= o > support content publish. or i miss some points? > > >> Service Assurance: > >> > >> It seems problematic to include "assurance" in a DECADE. Shouldn't > >> these instead be part of SLAs with a storage provider? Why should > >> they be DECADE's responsibility? > >> > >> Regarding "resource reservation", are you referring to an actual > >> reservation (which might be problematic -- see above) or do you mean > >> that the resource share should able to be specified at the time the > >> connection opens and be assumed to be the same for the duration of the > >> connection? > >> > >> Regarding Dynamic Feedback, is this orthogonal to the storage > >> protocol? It seems like what you want here is a generic "status" > >> service saying how loaded a server is? > >> > > thats right, actually, the flow control mechanism was under discussion = in > writing the draft at first. what about your opinion in this requirements? > > > > I'm not sure what the typical way of providing such "load status" > information for IETF protocols, but my inclination is that it should > not be in the DECADE protocol itself. Maybe someone else with a > longer history in IETF could jump in here :) > so can i understand that "load status" is kind of necessity information > for DECADE Server, but where and who collects the information are > remain discussion? > > >> > >> Data classification: > >> > >> Would it be better to instead have the client specify properties of > >> the content instead of place it into ? See > >> www.ietf.org/proceedings/78/slides/nfsv4-0.pdf for an example of this > >> approach for NFS. > >> > >> I think a problem with classifying applications is that it assumes > >> that applications fit one of the supplied classifications. What if it > >> may fit multiple classifications? or none? Another problem is it > >> assumes that servers assume based on indirect and assumed information > >> that they know what to do with a particular piece of content. Why not > >> have an application specify its desires directly? > >> > > > > > >> > >> Small Objects: > >> > >> What is the new requirement here? Why is the existing requirement in > >> draft-ietf-decade-reqs-00 insufficient? > >> > >> This also has me a bit worried: > >> "And the in-network storage has the limited storage capacity, with the > >> arrival of user requests and data distribution requirements, the data > >> stored in the in-network storage will be replaced if the storage > >> reaches the limit and data arrivals continually." > >> > >> How does the server know what the proper replacement strategy is for > >> an application? I think DECADE's philosophy is that applications > >> should decide this. A simple way to do this is explicit deletion by an > >> application, but perhaps a more efficient (yet more complex) solution > >> is for an application to specify the replacement policy to the server. > >> > > actually, the key in "the data classification and small objects " is > whether does it or not in P2P application? i did not find data > classification was adopted in P2P application so far, let alone DECADE ne= ed > to classify the data used in all kinds of application. > > > > So, do you agree that it is problematic to try and classify each type > of application and try to specify the typical workload for each class? > > My point was that I don't think its necessary to do the classification > at all. It is more extensible (and directly useful) for a server to > just give it direct hints about what would be preferable. > yep, i believe it may be a little difficult, but worthy doing. specially > for improving the resource utilization within a single server and reducin= g > the response time for client. what about others opinion? > > >> > >> Removal of Expired Records: > >> > >> "However, the two scenarios did not mention how to handle the old > >> resource if the user distributes the new resource which is an updated > >> copy of the old resource." > >> > >> Why does this need to be handled in the requirements? Are you trying > >> to draw the distinction between immediate deletion of content and lazy > >> deletion? > >> > > i mean the meaning of delete operation and how to handle the expired > records need to be clarify in requirements. > > My inclination is that "deleted" means that other requests the object > of the same name should result an error, until another object with the > same name is stored. > okay, under the scenario "client uploads the new version, and did not > specify how to handle the old version", did DECADE server delete the olde= r > version (or just label it unavailable, anyway, it is implementation issue= ) > or not ? in another word, just replace the older version with the new > version with the same name? how to handle the older version which is > transferring from server to client? > > I think that the time the data is removed from disk (or memory) should > be up to the implementation. A storage provider might still have as > part of some agreement that deleted data will be removed within X > days/hours/minutes/whatever. > agree with you. > > If people in the WG think it is necessary, we could have a requirement > that says the protocol should support an argument indicating immediate > deletion, but it is not clear that we need this. > > Rich > > >> > >> Thanks! > >> Rich > >> > >> > >> On Mon, Dec 27, 2010 at 12:57 AM, =D6=EC=E4=EC = wrote: > >> > Dear all, > >> > > >> > There is a slightly updated version of the decade additional > requirements > >> > draft. > >> > > https://datatracker.ietf.org/doc/draft-zhu-decade-additional-requirements= / > >> > > >> > Jin Peng, Yunfei Zhang and me are expecting to have a discussion wit= h > all of > >> > you. > >> > > >> > Any comments are appreciated! > >> > > >> > A new version of I-D, draft-zhu-decade-additional-requirements-00.tx= t > has been successfully submitted by Xiao Zhu and posted to the IETF > repository. > >> > > >> > Filename: draft-zhu-decade-additional-requirements > >> > Revision: 00 > >> > Title: Additional protocol requirements on DECADE > >> > Creation_date: 2010-12-27 > >> > WG ID: Independent Submission > >> > Number_of_pages: 10 > >> > > >> > Abstract: > >> > The DECoupled Application Data Enroute(DECADE)working group is > >> > specifying standardized interfaces for accessing in-network storage > >> > from applications to store, retrieve and manage data. The main objec= t > >> > is to provide a framework that is useful to the applications, > >> > including P2P applications and other data-oriented applications, > >> > possibly related applications that can benefit from accessing in- > >> > network storage. This memo focuses on some requirements such as > >> > request redirecting and so on which are on the central of mobility, > >> > wireless network environment and CDN application. We present these i= n > >> > this memo as additional requirements that should be considered for > >> > the DECADE architecture and protocol specifications. > >> > > >> > > >> > > >> > The IETF Secretariat. > >> > > >> > -- > >> > Best wishes, > >> > > >> > Beijing University of Posts & Telecommunications (BUPT) > >> > Zhu Xiao ( =D6=EC=E4=EC ) > >> > E-mail: buptxiaozhu@gmail.com > >> > mobile:+86 134-8881-9004 > >> > > >> > _______________________________________________ > >> > decade mailing list > >> > decade@ietf.org > >> > https://www.ietf.org/mailman/listinfo/decade > >> > > >> > > > > > > > > > -- > > Best wishes, > > > > Beijing University of Posts & Telecommunications (BUPT) > > Zhu Xiao ( =D6=EC=E4=EC ) > > E-mail: buptxiaozhu@gmail.com > > mobile:+86 134-8881-9004 > --=20 Best wishes, Beijing University of Posts & Telecommunications (BUPT) Zhu Xiao ( =D6=EC=E4=EC ) E-mail: buptxiaozhu@gmail.com mobile:+86 134-8881-9004 --=20 Best wishes, Beijing University of Posts & Telecommunications (BUPT) Zhu Xiao ( =D6=EC=E4=EC ) E-mail: buptxiaozhu@gmail.com mobile:+86 134-8881-9004 --20cf30549a6f0f36690499b0ad74 Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable

---------- Forwarded message ----------<= br>From: =D6=EC=E4=EC &= lt;buptxiaozhu@gmail.com>
Date: 2011/1/13
Subject: Re: [decade] draft-zhu-decade-additional-requirements
To: Richa= rd Alimi <rich@velvetsea.net&g= t;


hi, Richard

see inline:D

2011/1/11 Richard Alimi <rich@velvetsea.net>

Hi Xiao,

On Mon, Jan 10, 2011 at 6:45 PM, =D6=EC=E4=EC <buptxiaozhu@gmail.com> wrote:
>
> hi, Richard, sorry for so late response because of be busy with other = projects.
> some discussion see inline:D marked by red.
>
> On Tue, Jan 4, 2011 at 4:06 AM, Richard Alimi <rich@velvetsea.net> wrote:
>>
>> Hi Xiao,
>>
>> Thank you for the draft.  Some comments on the requirements:<= br> >>
>> Request Redirects:
>>
>> This would provide some additional freedom for the storage provide= r.
>> I think it is reasonable since it doesn't necessitate addition= al
>> complexity for the DECADE server, but allows it if desired. Howeve= r,
>> note that it may complicate some of the other components of the >> design. In particular, if there is a per-user quota for storage, i= s
>> the user made aware of the quota at each in-network storage (if th= ere
>> is no shared storage between them)?  Resource sharing policie= s may be
>> impacted (e.g., if a bandwidth sharing weight of 1 may mean someth= ing
>> different at DECADE server A than it does at DECADE server B). &nb= sp;At
>> this point it may be best to just note these so they are documente= d,
>> but since the specification of the resource sharing policies are s= till
>> being contemplated for the basic case of a single server it may be=
>> premature to even try and solve them for the case supporting
>> redirection.
>>
> actually, you mean two points, right?
> 1. whether or not to be ware of the content at each in-network storage= and of course resource sharing policies can be impact in the request redir= ection. your suggestion"just to note these so they are documented"= ; will be ok, or DECADE server list with some parameters will be return for= user to select the appropriate DECADE server, which can avoid the differen= t weighted of the same parameter in server decision. but the parameter used= in select the best DECADE server will be known for DECADE servers, in whic= h other complexities will be added. anyway, all the solution are the implem= entation issue, which, i believe, does not impact the necessity of the requ= irement.

In general, I'd agree that the decision about where to redirect w= ould
be an implementation issue.

>
> 2. you mean "the resource sharing policies are still being consid= ered in a single server", so it may be premature to support redirectio= n.  the architecture and protocol will be badly impacted if the requir= ements change. so the designing can be  taken  step by step, but = the requirements should be overall considered.

I said that it is probably premature to consider how resource sharing=
policies works across servers (or even if we need to say anything
about it) since we have not determined how to specify them (or rather,
how little we need to specify in protocol) for a single server. I did
not mean to imply that redirection could not be introduced as a
requirement.

 
>
>
>>
>> Multi-connection:
>>
>> I'm not quite clear on the intention of the requirement.  = ;My
>> understanding is that you wish the client to be able to have multi= ple
>> connections open spanning multiple DECADE servers. Is that correct= ?
>>
>> If so, do we need this stated as a requirement or the protocol? Or= is
>> this a policy that would be allowed/disallowed by the storage
>> provider?
>>
> yep, your understanding is right, the scenarios were just described in= draft as "soft handover in wireless environment and delete operation = in multi-servers". under these consideration, the authentication and a= uthorization need to be taken each time when setup connection with a new DE= CADE server, or just be taken only once during  the service?

The DECADE server should need to do some sort of check on each new connection, regardless of whether the user has or previously had a
connection open to a different DECADE server, right?  Note that the requirements don't indicate how authentication or authorization is
done, and allow a server to make optimizations if it is enforcing the
same permissions.

Can you indicate where the existing authorization-related requirements
(in particular, 4.1.6.3 of draft-ietf-decade-reqs-00) do not suffice
for the use case you are thinking of?
as considering the service co= ntinuity, the next serving  DECADE server should know the progress of = the service, how does they know? so if = the service proceeding information should be known by the next serving serv= er, or different servers need to coordinate and schedule each other to= fulfill the user request, i believe the the 4.1.6.3 of the draft-ietf-deca= de-req-00 cannot satisfy the req. what do you think about? <= /font>

>
>
>>
>> Data Distribution:
>>
>> I'm also confused about the intent of this requirement.  = This
>> statement has me somewhat worried: "The distribution is trans= parent to
>> the users as they interact with the in-network storage as a single=
>> logical system." Does this mean that you are proposing for DE= CADE
>> servers to assume the responsibility for deciding how data is to b= e
>> distributed throughout the network, including the path of the data= ,
>> which servers act as intermediate caches, content expiration polic= ies,
>> etc?  If this is true, I think it is missing one of the major= points
>> of DECADE. In particular, these decisions are application-dependen= t
>> and are not implemented within DECADE. Instead, DECADE provides th= e
>> basic capabilities and the functionality described above are
>> implemented by the applications using DECADE.
>>
>> Or, am I misinterpreting the intent of the requirement?
>>
> you mean DECADE provides the basic capabilities, so can you give some = specify explanations on DECADE capabilities in supporting data distribution= ?
>>

The problem statement gives a couple of scena= rios. The "Integration
Examples" presentation from IETF 79 also has more details of an
on-going effort at Yale.
okay, thx for your information, i w= ill lookup and refer, actually, the content publisher described in pro= blem statement remind me of  the p= rotocol requirements which i did not find in draft-ietf-decade-re= qs-00 to support content publish. or i miss some points?

>> Service Assurance:
>>
>> It seems problematic to include "assurance" in a DECADE.=  Shouldn't
>> these instead be part of SLAs with a storage provider?  Why s= hould
>> they be DECADE's responsibility?
>>
>> Regarding "resource reservation", are you referring to a= n actual
>> reservation (which might be problematic -- see above) or do you me= an
>> that the resource share should able to be specified at the time th= e
>> connection opens and be assumed to be the same for the duration of= the
>> connection?
>>
>> Regarding Dynamic Feedback, is this orthogonal to the storage
>> protocol?  It seems like what you want here is a generic &quo= t;status"
>> service saying how loaded a server is?
>>
> thats right, actually, the flow control mechanism was under discussion= in writing the draft at first. what about your opinion in this requirement= s?
>

I'm not sure what the typical way of prov= iding such "load status"
information for IETF protocols, but my inclination is that it should
not be in the DECADE protocol itself.  Maybe someone else with a
longer history in IETF could jump in here :)
so can i understand that= "load status" is kind of necessity  information for DE= CADE Server, but where and who collects the information are remain dis= cussion?

>>
>> Data classification:
>>
>> Would it be better to instead have the client specify properties o= f
>> the content instead of place it into ? See
>> www.ietf.org/proceedings/78/slides/nfsv4-0.pdf for an= example of this
>> approach for NFS.
>>
>> I think a problem with classifying applications is that it assumes=
>> that applications fit one of the supplied classifications. What if= it
>> may fit multiple classifications? or none?  Another problem i= s it
>> assumes that servers assume based on indirect and assumed informat= ion
>> that they know what to do with a particular piece of content. Why = not
>> have an application specify its desires directly?
>>
>
>
>>
>> Small Objects:
>>
>> What is the new requirement here?  Why is the existing requir= ement in
>> draft-ietf-decade-reqs-00 insufficient?
>>
>> This also has me a bit worried:
>> "And the in-network storage has the limited storage capacity,= with the
>> arrival of user requests and data distribution requirements, the d= ata
>> stored in the in-network storage will be replaced if the storage >> reaches the limit and data arrivals continually."
>>
>> How does the server know what the proper replacement strategy is f= or
>> an application? I think DECADE's philosophy is that applicatio= ns
>> should decide this. A simple way to do this is explicit deletion b= y an
>> application, but perhaps a more efficient (yet more complex) solut= ion
>> is for an application to specify the replacement policy to the ser= ver.
>>
> actually, the key in "the data classification and small objects &= quot; is whether does it or not in P2P application? i did not find data cla= ssification was adopted in P2P application so far, let alone DECADE need to= classify the data used in all kinds of application.
>

So, do you agree = that it is problematic to try and classify each type
of application and try to specify the typical workload for each class?

My point was that I don't think its necessary to do the classification<= br> at all.  It is more extensible (and directly useful) for a server to just give it direct hints about what would be preferable.
yep, i believe it may be a little = difficult, but worthy doing. specially for improving the resource util= ization within a single server and reducing the response time for client. w= hat about others opinion? 

>>
>> Removal of Expired Records:
>>
>> "However, the two scenarios did not mention how to handle the= old
>> resource if the user distributes the new resource which is an upda= ted
>> copy of the old resource."
>>
>> Why does this need to be handled in the requirements?  Are yo= u trying
>> to draw the distinction between immediate deletion of content and = lazy
>> deletion?
>>
> i mean the meaning of delete operation and how to handle the expired r= ecords need to be clarify in requirements.

My inclination is that "deleted" me= ans that other requests the object
of the same name should result an error, until another object with the
same name is stored.
okay, under the scenario "= ;client uploads the new version, and did not specify how to handle the old = version", did DECADE server delete the older version (or just label it= unavailable, anyway, it is implementation issue ) or not ? = in another word, just replace the older version with the new version with t= he same name? how to handle the older version which is transferring from se= rver to client?

I think that the time the data is removed from disk (or memory) should
be up to the implementation. A storage provider might still have as
part of some agreement that deleted data will be removed within X
days/hours/minutes/whatever.
   agree with you. 

If people in the WG think it is necessary, we could have a requirement
that says the protocol should support an argument indicating immediate
deletion, but it is not clear that we need this.

Rich

>>
>> Thanks!
>> Rich
>>
>>
>> On Mon, Dec 27, 2010 at 12:57 AM, =D6=EC=E4=EC <buptxiaozhu@gmail.com> w= rote:
>> > Dear all,
>> >
>> > There is a slightly updated version of the decade additional = requirements
>> > draft.
>> > https://datatracker.ietf.org/do= c/draft-zhu-decade-additional-requirements/
>> >
>> > Jin Peng, Yunfei Zhang and me are expecting to have a discuss= ion with all of
>> > you.
>> >
>> > Any comments are appreciated!
>> >
>> > A new version of I-D, draft-zhu-decade-additional-requirement= s-00.txt has been successfully submitted by Xiao Zhu and posted to the IETF= repository.
>> >
>> > Filename:      draft-zhu-decade-additional-req= uirements
>> > Revision:      00
>> > Title:                = ; Additional protocol requirements on DECADE
>> > Creation_date:         2010-12-27
>> > WG ID:                = ; Independent Submission
>> > Number_of_pages: 10
>> >
>> > Abstract:
>> > The DECoupled Application Data Enroute(DECADE)working group i= s
>> > specifying standardized interfaces for accessing in-network s= torage
>> > from applications to store, retrieve and manage data. The mai= n object
>> > is to provide a framework that is useful to the applications,=
>> > including P2P applications and other data-oriented applicatio= ns,
>> > possibly related applications that can benefit from accessing= in-
>> > network storage. This memo focuses on some requirements such = as
>> > request redirecting and so on which are on the central of mob= ility,
>> > wireless network environment and CDN application. We present = these in
>> > this memo as additional requirements that should be considere= d for
>> > the DECADE architecture and protocol specifications.
>> >
>> >
>> >
>> > The IETF Secretariat.
>> >
>> > --
>> > Best wishes,
>> >
>> > Beijing University of Posts & Telecommunications (BUPT) >> > Zhu Xiao  ( =D6=EC=E4=EC )
>> > E-mail: buptxiaozhu@gmail.com
>> > mobile:+86 134-8881-9004
>> >
>> > _______________________________________________
>> > decade mailing list
>> > decade@i= etf.org
>> > https://www.ietf.org/mailman/listinfo/decade
>> >
>> >
>
>
>
> --
> Best wishes,
>
> Beijing University of Posts & Telecommunications (BUPT)
> Zhu Xiao  ( =D6=EC=E4=EC )
> E-mail: bup= txiaozhu@gmail.com
> mobile:+86 134-8881-9004



--
Best wishes,

Beijing University of Posts & Te= lecommunications (BUPT)
Zhu Xiao  ( =D6=EC=E4=EC )
E-mail: buptxiaozhu@gmail.com=
mobile:+86 134-8881-9004



--
Best wishes,

Beijing Universi= ty of Posts & Telecommunications (BUPT)
Zhu Xiao  ( =D6=EC=E4= =EC )
E-mail: buptxiaozhu@gmail.com
mobile:+86 134-8881-9004
--20cf30549a6f0f36690499b0ad74-- From richard_woundy@cable.comcast.com Wed Jan 12 17:58:26 2011 Return-Path: X-Original-To: decade@core3.amsl.com Delivered-To: decade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 27F693A67D1 for ; Wed, 12 Jan 2011 17:58:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.753 X-Spam-Level: X-Spam-Status: No, score=-103.753 tagged_above=-999 required=5 tests=[AWL=-2.019, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I+CQ9Ly3HTGa for ; Wed, 12 Jan 2011 17:58:25 -0800 (PST) Received: from cable.comcast.com (copdcimo01.potomac.co.ndcwest.comcast.net [76.96.32.251]) by core3.amsl.com (Postfix) with ESMTP id 2A9CE3A67B1 for ; Wed, 12 Jan 2011 17:58:25 -0800 (PST) Received: from ([24.40.55.41]) by copdcimo01.cable.comcast.com with ESMTP with TLS id 5503630.22010187; Wed, 12 Jan 2011 19:11:02 -0700 Received: from PACDCEXMB05.cable.comcast.com ([fe80::a5b0:e5c4:df1b:2367]) by PACDCEXHUB02.cable.comcast.com ([fe80::11d4:f530:37a0:9f4e%12]) with mapi id 14.01.0270.001; Wed, 12 Jan 2011 21:00:39 -0500 From: "Woundy, Richard" To: "'abcdmatao@gmail.com'" , "'decade@ietf.org'" Thread-Topic: [decade] Reviews of the Decade Survey draft Thread-Index: AQHLssWsENEjNAVH50KNU8O5FTTTKg== Date: Thu, 13 Jan 2011 02:00:37 +0000 Message-ID: <1CA25301D2219F40B3AA37201F0EACD10675B5@PACDCEXMB05.cable.comcast.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [24.40.50.241] Content-Type: multipart/alternative; boundary="_000_1CA25301D2219F40B3AA37201F0EACD10675B5PACDCEXMB05cablec_" MIME-Version: 1.0 Cc: "'zhangch.bupt.001@gmail.com'" , "'qiuxiaofeng@gmail.com'" Subject: Re: [decade] Reviews of the Decade Survey draft X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2011 01:58:26 -0000 --_000_1CA25301D2219F40B3AA37201F0EACD10675B5PACDCEXMB05cablec_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzIGZvciB0aGUgYWRkaXRpb25hbCByZXZpZXchDQoNCi0tIFJpY2gNCg0KDQpGcm9tOiBU YW8gTWEgW21haWx0bzphYmNkbWF0YW9AZ21haWwuY29tXQ0KU2VudDogV2VkbmVzZGF5LCBKYW51 YXJ5IDEyLCAyMDExIDA4OjM2IFBNDQpUbzogZGVjYWRlQGlldGYub3JnIDxkZWNhZGVAaWV0Zi5v cmc+DQpDYzogcWl1eGlhb2ZlbmdAZ21haWwuY29tIDxxaXV4aWFvZmVuZ0BnbWFpbC5jb20+OyBj aCB6aGFuZyA8emhhbmdjaC5idXB0LjAwMUBnbWFpbC5jb20+DQpTdWJqZWN0OiBSZTogW2RlY2Fk ZV0gUmV2aWV3cyBvZiB0aGUgRGVjYWRlIFN1cnZleSBkcmFmdA0KDQpIaSwgYWxsDQogICAgSSdk IGFsc28gbGlrZSB0byBhZGQgc29tZSByZXZpZXdzIG9uIHRoZSBzdXJ2ZXkgZHJhZnQuIEkgdGhp bmsgaXQgYSB2ZXJ5IGNvbXByZWhlbnNpdmUgc3VydmV5IG9mIGN1cnJlbnQgaW4tbmV0d29yayBz dG9yYWdlIHN5c3RlbS5JIGhhdmUgc29tZSBtaW5vciBjb21tZW50czoNCiAgICAxIEluIHNlY3Rp b24gMi4yICJIaXN0b3JpY2FsIENvbnRleHQiLCBpdCBtYWlubHkgbWVudGlvbmVkIHdlYiBjYWNo ZSBhbmQgQ0ROIGFzIHRoZSBoaXN0b3JpY2FsIHByZWRlY2Vzc29yIG9mIERFQ0FERS4gSG93ZXZl ciwgSSBiZWxpZXZlICJQMlAgY2FjaGUiIHNob3VsZCBiZSBtZW50aW9uZWQgaGVyZSB0b28sIHdo aWNoIGlzIGhpZ2hsaWdodGVkIGluIHByb2JsZW0gc3RhdGVtZW50IGRyYWZ0Lg0KICAgIDIgQXMg eXVuZmVpIHpoYW5nIGhhcyBtZW50aW9uZWQgaW4gaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFy Y2hpdmUvd2ViL2RlY2FkZS9jdXJyZW50L21zZzAwMzQwLmh0bWwsIEkgYWxzbyBhZ3JlZSB0byBl bXBoYXNpemUgdGhlIG1vYmlsZSBzY2VuYXJpb3Mgd2hpY2ggaXMgbm90IHN1ZmZpY2llbnRseSBk ZXNjcmliZWQgaW4gY3VycmVudCBzdXJ2ZXkgZHJhZnQuDQogICAgMyBJbiB0aGUgZmlyc3QgbGlu ZSBvZiBzZWNpb24gNC4zLjEsICJzeXNlbSIgc2hvdWxkIGJlICJzeXN0ZW0iDQogICAgNCBJbiBz ZWN0aW9uIDQuNS40LCAiTm90IGFwcGxpY2FibGUiIHNob3VsZCBiZSAiTm90IHByb3ZpZGVkIiBh cyB0aGUgb3RoZXIgc3lzdGVtIGRlc2NyaWJlZCBmb3IgdW5pZm9ybSByZWFzb24NCg0KVGFvIE1h DQpCZWlqaW5nIFVuaXZlcnNpdHkgb2YgUG9zdHMgYW5kIFRlbGVjb21tdW5pY2F0aW9ucywgTUlO RWxhYg0KDQo= --_000_1CA25301D2219F40B3AA37201F0EACD10675B5PACDCEXMB05cablec_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5Pg0KPGZvbnQgc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoYW5rcyBmb3IgdGhlIGFkZGl0aW9uYWwg cmV2aWV3ITxicj4NCjxicj4NCi0tIFJpY2g8YnI+DQo8L2ZvbnQ+PGJyPg0KJm5ic3A7PGJyPg0K PGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3Bh ZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPGZvbnQgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxi PkZyb208L2I+OiBUYW8gTWEgW21haWx0bzphYmNkbWF0YW9AZ21haWwuY29tXQ0KPGJyPg0KPGI+ U2VudDwvYj46IFdlZG5lc2RheSwgSmFudWFyeSAxMiwgMjAxMSAwODozNiBQTTxicj4NCjxiPlRv PC9iPjogZGVjYWRlQGlldGYub3JnICZsdDtkZWNhZGVAaWV0Zi5vcmcmZ3Q7IDxicj4NCjxiPkNj PC9iPjogcWl1eGlhb2ZlbmdAZ21haWwuY29tICZsdDtxaXV4aWFvZmVuZ0BnbWFpbC5jb20mZ3Q7 OyBjaCB6aGFuZyAmbHQ7emhhbmdjaC5idXB0LjAwMUBnbWFpbC5jb20mZ3Q7DQo8YnI+DQo8Yj5T dWJqZWN0PC9iPjogUmU6IFtkZWNhZGVdIFJldmlld3Mgb2YgdGhlIERlY2FkZSBTdXJ2ZXkgZHJh ZnQgPGJyPg0KPC9mb250PiZuYnNwOzxicj4NCjwvZGl2Pg0KSGksIGFsbDxicj4NCiZuYnNwOyZu YnNwOyZuYnNwOyBJJ2QgYWxzbyBsaWtlIHRvIGFkZCBzb21lIHJldmlld3Mgb24gdGhlIHN1cnZl eSBkcmFmdC4gSSB0aGluayBpdCBhIHZlcnkgY29tcHJlaGVuc2l2ZSBzdXJ2ZXkgb2YgY3VycmVu dCBpbi1uZXR3b3JrIHN0b3JhZ2Ugc3lzdGVtLkkgaGF2ZSBzb21lIG1pbm9yIGNvbW1lbnRzOjxi cj4NCiZuYnNwOyZuYnNwOyZuYnNwOyAxIEluIHNlY3Rpb24gMi4yICZxdW90O0hpc3RvcmljYWwg Q29udGV4dCZxdW90OywgaXQgbWFpbmx5IG1lbnRpb25lZCB3ZWIgY2FjaGUgYW5kIENETiBhcyB0 aGUgaGlzdG9yaWNhbCBwcmVkZWNlc3NvciBvZiBERUNBREUuIEhvd2V2ZXIsIEkgYmVsaWV2ZSAm cXVvdDtQMlAgY2FjaGUmcXVvdDsgc2hvdWxkIGJlIG1lbnRpb25lZCBoZXJlIHRvbywgd2hpY2gg aXMgaGlnaGxpZ2h0ZWQgaW4gcHJvYmxlbSBzdGF0ZW1lbnQgZHJhZnQuPGJyPg0KJm5ic3A7Jm5i c3A7Jm5ic3A7IDIgQXMgeXVuZmVpIHpoYW5nIGhhcyBtZW50aW9uZWQgaW4gPHU+PHNwYW4gc3R5 bGU9ImNvbG9yOiBibHVlOyI+PC9zcGFuPjwvdT48dT48YSByZWw9Im5vZm9sbG93IiBocmVmPSJo dHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvZGVjYWRlL2N1cnJlbnQvbXNnMDAz NDAuaHRtbCI+aHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL2RlY2FkZS9jdXJy ZW50L21zZzAwMzQwLmh0bWw8L2E+PC91PiwgSSBhbHNvIGFncmVlDQogdG8gZW1waGFzaXplIHRo ZSBtb2JpbGUgc2NlbmFyaW9zIHdoaWNoIGlzIG5vdCBzdWZmaWNpZW50bHkgZGVzY3JpYmVkIGlu IGN1cnJlbnQgc3VydmV5IGRyYWZ0Ljxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyAzIEluIHRoZSBm aXJzdCBsaW5lIG9mIHNlY2lvbiA0LjMuMSwgJnF1b3Q7c3lzZW0mcXVvdDsgc2hvdWxkIGJlICZx dW90O3N5c3RlbSZxdW90Ozxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyA0IEluIHNlY3Rpb24gNC41 LjQsICZxdW90O05vdCBhcHBsaWNhYmxlJnF1b3Q7IHNob3VsZCBiZSAmcXVvdDtOb3QgcHJvdmlk ZWQmcXVvdDsgYXMgdGhlIG90aGVyIHN5c3RlbSBkZXNjcmliZWQgZm9yIHVuaWZvcm0gcmVhc29u PGJyPg0KPGJyPg0KVGFvIE1hPGJyPg0KQmVpamluZyBVbml2ZXJzaXR5IG9mIFBvc3RzIGFuZCBU ZWxlY29tbXVuaWNhdGlvbnMsIE1JTkVsYWI8YnI+DQombmJzcDsmbmJzcDsgPGJyPg0KPC9ib2R5 Pg0KPC9odG1sPg0K --_000_1CA25301D2219F40B3AA37201F0EACD10675B5PACDCEXMB05cablec_-- From haibin.song@huawei.com Thu Jan 13 04:23:45 2011 Return-Path: X-Original-To: decade@core3.amsl.com Delivered-To: decade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 568973A6AB4 for ; Thu, 13 Jan 2011 04:23:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.039 X-Spam-Level: X-Spam-Status: No, score=-3.039 tagged_above=-999 required=5 tests=[AWL=1.455, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NnpGKgcagW8r for ; Thu, 13 Jan 2011 04:23:40 -0800 (PST) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id B72693A6A0B for ; Thu, 13 Jan 2011 04:23:39 -0800 (PST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LEY001KCNV38T@szxga03-in.huawei.com> for decade@ietf.org; Thu, 13 Jan 2011 20:25:51 +0800 (CST) Received: from szxeml202-edg.china.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LEY001R2NV3K2@szxga03-in.huawei.com> for decade@ietf.org; Thu, 13 Jan 2011 20:25:51 +0800 (CST) Received: from SZXEML404-HUB.china.huawei.com (10.82.67.59) by szxeml202-edg.china.huawei.com (172.24.2.42) with Microsoft SMTP Server (TLS) id 14.1.218.12; Thu, 13 Jan 2011 20:24:15 +0800 Received: from SZXEML505-MBX.china.huawei.com ([169.254.2.249]) by szxeml404-hub.china.huawei.com ([fe80::75b7:3db9:fedc:a56d%13]) with mapi id 14.01.0218.012; Thu, 13 Jan 2011 20:25:50 +0800 Date: Thu, 13 Jan 2011 12:25:50 +0000 From: Songhaibin In-reply-to: X-Originating-IP: [10.138.41.70] To: Tao Ma , "decade@ietf.org" Message-id: MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_r0N1CotbusyJlF7rLVdZFA)" Content-language: zh-CN Accept-Language: en-US, zh-CN Thread-topic: [decade]review of draft-ietf-decade-problem-statement-01 Thread-index: AQHLq/iytMpE0CvKDEmbMzyNhSK7VZPO3cpw X-MS-Has-Attach: X-MS-TNEF-Correlator: References: Cc: "qiuxiaofeng@gmail.com" , ch zhang Subject: Re: [decade] review of draft-ietf-decade-problem-statement-01 X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2011 12:23:45 -0000 --Boundary_(ID_r0N1CotbusyJlF7rLVdZFA) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi Tao, Thanks for the review. I'm sorry for the late reply. Please see in line. From: Tao Ma [mailto:abcdmatao@gmail.com] Sent: Tuesday, January 04, 2011 6:16 PM To: decade@ietf.org; Songhaibin Cc: ch zhang; qiuxiaofeng@gmail.com Subject: [decade]review of draft-ietf-decade-problem-statement-01 Hi, I have carefully read the problem statement draft. It's clear and concise to describe the motivation and goal of DECADE. However, I have some confusion about its details as follows: 1 In section 3.1-P2P infrastructural stress and inefficiency, the third paragraph about the comparion with LEDBAT, there is a sentence "Also, when adopted, these techniques do not remove all inefficiencies, such as those associated with traffic being sent upstream as many times as there are remote peers interested in getting the corresponding information." I don't catch the main idea of this sentence. What is "those associated with traffic being sent upstream as many times as there are remote peers"? What is "corresponding information?"Do you mean LEDBAT only considers peers in local network? I think this sentence is quite hard to understand. [Haibin] That sentence means other technique like LEDBAT does not solve the problem, that the content is sent upstream as many times as there are requests for it. "corresponding information" means the shared content itself. 2 The section 3 describes the problems that would be targeted by DECADE. One side is to reduce the stress on infrastructure, which benefits ISP. The other side is to increase flexibility on content sharing, which benefits users. However, I don't think the titile of section 3.3 "ineffective integration of P2P applications" is very appropriate. In my opinion, this section describes the requirements for P2P applications to utilize infrastructural resources, which doesn't match the "ineffective integration". I suggest a more appropriate title to highlight the need of infrastructural resources for P2P applications. [Haibin] I want to say all subsections in Section 3 are to state the problems. When you read the last sentence, you can understand what is the main idea of section 3.3. "Existing techniques for P2P application in-network storage lack these capabilities." Besides, I think DECADE is a very promising service to transfer the storage and management of content into the cloud, which envisions the future P2P applications. Can we add the hot concept of "cloud" into the draft? My 2 cents. [Haibin] "Cloud" is a very interesting and popular concept. But different people have different mind on it, which may confuse the readers BR, Haibin Tao Ma Beijing University of Posts and Telecommunications, Mobile life and new media lab --Boundary_(ID_r0N1CotbusyJlF7rLVdZFA) Content-type: text/html; charset=us-ascii Content-transfer-encoding: quoted-printable

Hi Tao,

 = ;

Thanks for= the review. I’m sorry for the late reply. Please see in line.

 = ;

From: Tao Ma [mailto:abcdmatao@gmail.com]
Sent: Tuesday, January 04, 2011 6:16 PM
To: decade@ietf.org; Songhaibin
Cc: ch zhang; qiuxiaofeng@gmail.com
Subject: [decade]review of draft-ietf-decade-problem-statement-01

 

Hi,

I have carefully read the problem statement draft. It&= #8217;s clear and concise to describe the motivation and goal of DECADE. Ho= wever, I have some confusion about its details as follows:

1 In section 3.1-P2P infrastructural stress and ineffi= ciency, the third paragraph about the comparion with LEDBAT, there is a sen= tence “Also, when adopted, these techniques do not remove all ineffic= iencies, such as those associated with traffic being sent upstream as many times as there are remote peers interested in = getting the corresponding information.” I don’t catch the main = idea of this sentence. What is “those associated with traffic being s= ent upstream as many times as there are remote peers”? What is “corresponding information?”Do you mean LEDBAT only co= nsiders peers in local network? I think this sentence is quite hard to unde= rstand.

[Haibin] That sentence m= eans other technique like LEDBAT does not solve the problem, that the content is sent upstream as many times as there are requests for = it. “corresponding information” means the shared content itself= .

2 The section 3 describes the problems that would be t= argeted by DECADE. One side is to reduce the stress on infrastructure, whic= h benefits ISP. The other side is to increase flexibility on content sharin= g, which benefits users. However, I don’t think the titile of section 3.3 “ineffective integrati= on of P2P applications” is very appropriate. In my opinion, this sect= ion describes the requirements for P2P applications to utilize infrastructu= ral resources, which doesn’t match the “ineffective integration”. I suggest a more appropriate title to highlight the ne= ed of infrastructural resources for P2P applications.

[Haibin] I want to say a= ll subsections in Section 3 are to state the problems. When you read the last sentence, you can understand what is the main idea of se= ction 3.3. “Existing techniques for P2P application in-network storag= e lack these capabilities.”

Besides, I think DECADE is a very promising service to= transfer the storage and management of content into the cloud, which envis= ions the future P2P applications. Can we add the hot concept of “clou= d” into the draft? My 2 cents.

[Haibin] “Cloud= ” is a very interesting and popular concept. But different people hav= e different mind on it, which may confuse the readers

BR,

Haibin=

 =

 =

 =

 =

 =

Tao Ma

Beijing University of Posts and Telecommunica= tions, Mobile life and new media lab

--Boundary_(ID_r0N1CotbusyJlF7rLVdZFA)-- From haibin.song@huawei.com Thu Jan 13 04:30:12 2011 Return-Path: X-Original-To: decade@core3.amsl.com Delivered-To: decade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2AF9A3A6ABB for ; Thu, 13 Jan 2011 04:30:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.171 X-Spam-Level: X-Spam-Status: No, score=-1.171 tagged_above=-999 required=5 tests=[AWL=-0.677, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SaquUyBA8-KL for ; Thu, 13 Jan 2011 04:30:04 -0800 (PST) Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id 299A83A6A0B for ; Thu, 13 Jan 2011 04:30:04 -0800 (PST) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LEY00HZYO5SU6@szxga05-in.huawei.com> for decade@ietf.org; Thu, 13 Jan 2011 20:32:16 +0800 (CST) Received: from szxeml201-edg.china.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LEY0033FO5RVE@szxga05-in.huawei.com> for decade@ietf.org; Thu, 13 Jan 2011 20:32:16 +0800 (CST) Received: from SZXEML404-HUB.china.huawei.com (10.82.67.59) by szxeml201-edg.china.huawei.com (172.24.2.39) with Microsoft SMTP Server (TLS) id 14.1.218.12; Thu, 13 Jan 2011 20:32:07 +0800 Received: from SZXEML505-MBX.china.huawei.com ([169.254.2.249]) by szxeml404-hub.china.huawei.com ([fe80::75b7:3db9:fedc:a56d%13]) with mapi id 14.01.0218.012; Thu, 13 Jan 2011 20:32:14 +0800 Date: Thu, 13 Jan 2011 12:32:13 +0000 From: Songhaibin In-reply-to: <1CA25301D2219F40B3AA37201F0EACD1063F8D@PACDCEXMB05.cable.comcast.com> X-Originating-IP: [10.138.41.70] To: "Woundy, Richard" , "'decade@ietf.org'" Message-id: MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_KlzJebA3wqz46AizvvbxSA)" Content-language: zh-CN Accept-Language: en-US, zh-CN Thread-topic: Reviews of the Decade Problem Statement draft Thread-index: AcuclJZz4nxTPrqtT4uUeAAn8W9WtgQmIOEQAADH11ABe0Qn4A== X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <1CA25301D2219F40B3AA37201F0EACD104CB1B@PACDCEXMB05.cable.comcast.com> <1CA25301D2219F40B3AA37201F0EACD1063F46@PACDCEXMB05.cable.comcast.com> <1CA25301D2219F40B3AA37201F0EACD1063F8D@PACDCEXMB05.cable.comcast.com> Subject: Re: [decade] Reviews of the Decade Problem Statement draft X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2011 12:30:12 -0000 --Boundary_(ID_KlzJebA3wqz46AizvvbxSA) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi Rich, Thank you very much. What you mentioned should be addressed in the new version. The authors are editing on the draft now. We probably will give a new version by the end of this week or early next week. BR, Haibin From: Woundy, Richard [mailto:Richard_Woundy@cable.comcast.com] Sent: Thursday, January 06, 2011 7:39 AM To: 'decade@ietf.org' Cc: Songhaibin; Woundy, Richard Subject: RE: Reviews of the Decade Problem Statement draft Folks, Below is my own "idnits review" based on the output of http://tools.ietf.org/idnits?url=http://tools.ietf.org/id/draft-ietf-decade-problem-statement-01.txt. == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. See the first paragraph of section 2, and the lack of MUST/SHOULD/MAY language in the draft. Maybe delete the boilerplate and RFC 2119 reference? == Missing Reference: 'CNN' is mentioned on line 182, but not defined I'm not sure that the draft needs a reference to the CNN report, since it doesn't have a reference to the PPLive example. But if a reference is still desired, consider this one: http://gigaom.com/video/cnn-inauguration-p2p-stream-a-success-despite-backlash/. == Unused Reference: 'RFC3720' is defined on line 682, but no explicit reference was found in the text == Unused Reference: 'RFC5661' is defined on line 686, but no explicit reference was found in the text == Unused Reference: 'RFC2616' is defined on line 690, but no explicit reference was found in the text The draft probably should either incorporate these references into the text, or delete them. -- Rich From: Woundy, Richard Sent: Wednesday, January 05, 2011 6:19 PM To: 'decade@ietf.org' Cc: Songhaibin; Woundy, Richard Subject: RE: Reviews of the Decade Problem Statement draft I would like to express my thanks to the reviewers of the problem statement draft! Tao Ma http://www.ietf.org/mail-archive/web/decade/current/msg00356.html Ning Zong http://www.ietf.org/mail-archive/web/decade/current/msg00341.html Roni Even http://www.ietf.org/mail-archive/web/decade/current/msg00336.html David Bryan http://www.ietf.org/mail-archive/web/decade/current/msg00334.html Akbar Rahman http://www.ietf.org/mail-archive/web/decade/current/msg00313.html I believe we have a sufficient number of reviews for the authors to incorporate this feedback, and to produce a new revision for WGLC. -- Rich From: Woundy, Richard Sent: Wednesday, December 15, 2010 3:14 PM To: 'decade@ietf.org' Cc: Songhaibin; Woundy, Richard Subject: Reviews of the Decade Problem Statement draft Folks, We would like to prepare the problem statement draft, draft-ietf-decade-problem-statement-00, for working group last call in January. The chairs are looking for document reviews to be sent to the mailing list by Wednesday December 29. We already have three volunteers from our session in Beijing (and thanks to Akbar Rahman for already posting his review to this list). Additional draft reviews by the deadline would be timely and greatly appreciated. After the authors incorporate the feedback from the reviews in a new draft iteration, the chairs expect to take the draft to WGLC. -- Rich --Boundary_(ID_KlzJebA3wqz46AizvvbxSA) Content-type: text/html; charset=us-ascii Content-transfer-encoding: quoted-printable

Hi Rich,

 

Thank you very much. What you mentioned should be addressed in th= e new version. The authors are editing on the draft now. We probably will g= ive a new version by the end of this week or early next week.

 

BR,

Haibin

 

From: Woundy, Richard [mailto:Richard_Woundy@cable.comcast.= com]
Sent: Thursday, January 06, 2011 7:39 AM
To: 'decade@ietf.org'
Cc: Songhaibin; Woundy, Richard
Subject: RE: Reviews of the Decade Problem Statement draft

 

Folks,<= o:p>

&n= bsp;

Below i= s my own “idnits review” based on the output of http://tools.ietf.org/idnits?url=3Dhttp://tools.ietf.org/id/draft-ietf-deca= de-problem-statement-01.txt.

&n= bsp;

  = =3D=3D The document doesn't use any RFC 2119 keywords, yet seems to have RF= C

 &= nbsp;   2119 boilerplate text.

&n= bsp;

See the= first paragraph of section 2, and the lack of MUST/SHOULD/MAY language in = the draft. Maybe delete the boilerplate and RFC 2119 reference?<= /span>

&n= bsp;

  = =3D=3D Missing Reference: 'CNN' is mentioned on line 182, but not defined

&n= bsp;

I’= ;m not sure that the draft needs a reference to the CNN report, since it do= esn’t have a reference to the PPLive example. But if a reference is s= till desired, consider this one: http://gigaom.com/video/cnn-inauguration-p2p-stream-a-success-despite-backl= ash/.

&n= bsp;

  = =3D=3D Unused Reference: 'RFC3720' is defined on line 682, but no explicit<= o:p>

 &= nbsp;   reference was found in the text

  = =3D=3D Unused Reference: 'RFC5661' is defined on line 686, but no explicit<= o:p>

 &= nbsp;   reference was found in the text

  = =3D=3D Unused Reference: 'RFC2616' is defined on line 690, but no explicit<= o:p>

 &= nbsp;   reference was found in the text

&n= bsp;

The dra= ft probably should either incorporate these references into the text, or de= lete them.

&n= bsp;

-- Rich=

&n= bsp;

From: Woundy, Richard
Sent: Wednesday, January 05, 2011 6:19 PM
To: 'decade@ietf.org'
Cc: Songhaibin; Woundy, Richard
Subject: RE: Reviews of the Decade Problem Statement draft

 

I would= like to express my thanks to the reviewers of the problem statement draft!=

&n= bsp;

Tao Ma

http= ://www.ietf.org/mail-archive/web/decade/current/msg00356.html

Ning Zong=

http= ://www.ietf.org/mail-archive/web/decade/current/msg00341.html

Roni Even=

http= ://www.ietf.org/mail-archive/web/decade/current/msg00336.html

David Bry= an

http= ://www.ietf.org/mail-archive/web/decade/current/msg00334.html

Akbar Rah= man

http= ://www.ietf.org/mail-archive/web/decade/current/msg00313.html

&n= bsp;

I belie= ve we have a sufficient number of reviews for the authors to incorporate th= is feedback, and to produce a new revision for WGLC.

&n= bsp;

-- Rich=

&n= bsp;

From: Woundy, Richard
Sent: Wednesday, December 15, 2010 3:14 PM
To: 'decade@ietf.org'
Cc: Songhaibin; Woundy, Richard
Subject: Reviews of the Decade Problem Statement draft

 

Folks,

 

We would like to prepare the pr= oblem statement draft, draft-ietf-decade-problem-statement-00, for working group last ca= ll in January.

 

The chairs are looking for docu= ment reviews to be sent to the mailing list by Wednesday December 29. We al= ready have three volunteers from our session in Beijing (and thanks to Akba= r Rahman for already posting his review to this list). Additional draft reviews by the deadline would be timely an= d greatly appreciated.

 

After the authors incorporate t= he feedback from the reviews in a new draft iteration, the chairs expect to= take the draft to WGLC.

 

-- Rich

--Boundary_(ID_KlzJebA3wqz46AizvvbxSA)-- From Akbar.Rahman@InterDigital.com Thu Jan 13 07:29:11 2011 Return-Path: X-Original-To: decade@core3.amsl.com Delivered-To: decade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E4FF13A6B9A for ; Thu, 13 Jan 2011 07:29:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.049 X-Spam-Level: X-Spam-Status: No, score=-2.049 tagged_above=-999 required=5 tests=[AWL=0.549, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UKdgNUAAWsZN for ; Thu, 13 Jan 2011 07:29:09 -0800 (PST) Received: from idcout.InterDigital.com (idcexmail.interdigital.com [12.32.197.135]) by core3.amsl.com (Postfix) with ESMTP id AA5AA3A6BA8 for ; Thu, 13 Jan 2011 07:29:01 -0800 (PST) Received: from SAM.InterDigital.com ([10.30.2.11]) by idcout.InterDigital.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 13 Jan 2011 10:31:24 -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_01CBB336.EFA4F48C" Date: Thu, 13 Jan 2011 10:31:22 -0500 Message-ID: In-Reply-To: <1CA25301D2219F40B3AA37201F0EACD10675B5@PACDCEXMB05.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [decade] Reviews of the Decade Survey draft Thread-Index: AQHLssWsENEjNAVH50KNU8O5FTTTKpPPBxow References: <1CA25301D2219F40B3AA37201F0EACD10675B5@PACDCEXMB05.cable.comcast.com> From: "Rahman, Akbar" To: "Woundy, Richard" X-OriginalArrivalTime: 13 Jan 2011 15:31:24.0186 (UTC) FILETIME=[EFBBCFA0:01CBB336] Cc: decade@ietf.org Subject: Re: [decade] Reviews of the Decade Survey draft X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2011 15:29:12 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBB336.EFA4F48C Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgUmljaCwNCg0KIA0KDQogDQoNClRoZSBhdXRob3JzIGFyZSB3b3JraW5nIG9uIHRoZSB1cGRh dGUgdG8gdGhlIFN1cnZleSBiYXNlZCBvbiB0aGUgY29tbWVudHMgZnJvbSBUYW8gTWEsIE92ZSBT dHJhbmRiZXJnLCBZdW5mZWkgWmhhbmcgYW5kIERhdmlkIEJyeWFuLiAgV2UgZXhwZWN0IHRvIHN1 Ym1pdCBhbiB1cGRhdGVkIEktRCBzb21ldGltZSBuZXh0IHdlZWsuDQoNCiANCg0KU2luY2VyZWx5 LA0KDQogDQoNCkFrYmFyDQoNCiANCg0KRnJvbTogZGVjYWRlLWJvdW5jZXNAaWV0Zi5vcmcgW21h aWx0bzpkZWNhZGUtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFdvdW5keSwgUmljaGFy ZA0KU2VudDogV2VkbmVzZGF5LCBKYW51YXJ5IDEyLCAyMDExIDk6MDEgUE0NClRvOiAnYWJjZG1h dGFvQGdtYWlsLmNvbSc7ICdkZWNhZGVAaWV0Zi5vcmcnDQpDYzogJ3poYW5nY2guYnVwdC4wMDFA Z21haWwuY29tJzsgJ3FpdXhpYW9mZW5nQGdtYWlsLmNvbScNClN1YmplY3Q6IFJlOiBbZGVjYWRl XSBSZXZpZXdzIG9mIHRoZSBEZWNhZGUgU3VydmV5IGRyYWZ0DQoNCiANCg0KVGhhbmtzIGZvciB0 aGUgYWRkaXRpb25hbCByZXZpZXchDQoNCi0tIFJpY2gNCg0KIA0KDQpGcm9tOiBUYW8gTWEgW21h aWx0bzphYmNkbWF0YW9AZ21haWwuY29tXSANClNlbnQ6IFdlZG5lc2RheSwgSmFudWFyeSAxMiwg MjAxMSAwODozNiBQTQ0KVG86IGRlY2FkZUBpZXRmLm9yZyA8ZGVjYWRlQGlldGYub3JnPiANCkNj OiBxaXV4aWFvZmVuZ0BnbWFpbC5jb20gPHFpdXhpYW9mZW5nQGdtYWlsLmNvbT47IGNoIHpoYW5n IDx6aGFuZ2NoLmJ1cHQuMDAxQGdtYWlsLmNvbT4gDQpTdWJqZWN0OiBSZTogW2RlY2FkZV0gUmV2 aWV3cyBvZiB0aGUgRGVjYWRlIFN1cnZleSBkcmFmdCANCiANCg0KSGksIGFsbA0KICAgIEknZCBh bHNvIGxpa2UgdG8gYWRkIHNvbWUgcmV2aWV3cyBvbiB0aGUgc3VydmV5IGRyYWZ0LiBJIHRoaW5r IGl0IGEgdmVyeSBjb21wcmVoZW5zaXZlIHN1cnZleSBvZiBjdXJyZW50IGluLW5ldHdvcmsgc3Rv cmFnZSBzeXN0ZW0uSSBoYXZlIHNvbWUgbWlub3IgY29tbWVudHM6DQogICAgMSBJbiBzZWN0aW9u IDIuMiAiSGlzdG9yaWNhbCBDb250ZXh0IiwgaXQgbWFpbmx5IG1lbnRpb25lZCB3ZWIgY2FjaGUg YW5kIENETiBhcyB0aGUgaGlzdG9yaWNhbCBwcmVkZWNlc3NvciBvZiBERUNBREUuIEhvd2V2ZXIs IEkgYmVsaWV2ZSAiUDJQIGNhY2hlIiBzaG91bGQgYmUgbWVudGlvbmVkIGhlcmUgdG9vLCB3aGlj aCBpcyBoaWdobGlnaHRlZCBpbiBwcm9ibGVtIHN0YXRlbWVudCBkcmFmdC4NCiAgICAyIEFzIHl1 bmZlaSB6aGFuZyBoYXMgbWVudGlvbmVkIGluIGh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNo aXZlL3dlYi9kZWNhZGUvY3VycmVudC9tc2cwMDM0MC5odG1sLCBJIGFsc28gYWdyZWUgdG8gZW1w aGFzaXplIHRoZSBtb2JpbGUgc2NlbmFyaW9zIHdoaWNoIGlzIG5vdCBzdWZmaWNpZW50bHkgZGVz Y3JpYmVkIGluIGN1cnJlbnQgc3VydmV5IGRyYWZ0Lg0KICAgIDMgSW4gdGhlIGZpcnN0IGxpbmUg b2Ygc2VjaW9uIDQuMy4xLCAic3lzZW0iIHNob3VsZCBiZSAic3lzdGVtIg0KICAgIDQgSW4gc2Vj dGlvbiA0LjUuNCwgIk5vdCBhcHBsaWNhYmxlIiBzaG91bGQgYmUgIk5vdCBwcm92aWRlZCIgYXMg dGhlIG90aGVyIHN5c3RlbSBkZXNjcmliZWQgZm9yIHVuaWZvcm0gcmVhc29uDQoNClRhbyBNYQ0K QmVpamluZyBVbml2ZXJzaXR5IG9mIFBvc3RzIGFuZCBUZWxlY29tbXVuaWNhdGlvbnMsIE1JTkVs YWINCiAgIA0KDQo= ------_=_NextPart_001_01CBB336.EFA4F48C Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQoNCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9R2VuZXJhdG9y IGNvbnRlbnQ9Ik1pY3Jvc29mdCBXb3JkIDEyIChmaWx0ZXJlZCBtZWRpdW0pIj4NCjxzdHlsZT4N CjwhLS0NCiAvKiBGb250IERlZmluaXRpb25zICovDQogQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6VGFob21hOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30N CiAvKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KIHAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRp di5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9u dC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30N CmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNv bG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4u TXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1 cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJ e21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwi c2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5 bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0 aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4w aW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT4NCjwvc3R5 bGU+DQo8IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCiA8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJl ZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNv IDldPjx4bWw+DQogPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KICA8bzppZG1hcCB2OmV4 dD0iZWRpdCIgZGF0YT0iMSIgLz4NCiA8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+ DQo8L2hlYWQ+DQoNCjxib2R5IGxhbmc9RU4tVVMgbGluaz1ibHVlIHZsaW5rPXB1cnBsZT4NCg0K PGRpdiBjbGFzcz1Xb3JkU2VjdGlvbjE+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHls ZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0K Y29sb3I6IzFGNDk3RCc+SGkgUmljaCw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNz PU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2Fs aWJyaSIsInNhbnMtc2VyaWYiOw0KY29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCmNvbG9yOiMxRjQ5N0QnPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0 eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7 DQpjb2xvcjojMUY0OTdEJz5UaGUgYXV0aG9ycyBhcmUgd29ya2luZyBvbiB0aGUgdXBkYXRlIHRv IHRoZSBTdXJ2ZXkgYmFzZWQgb24gdGhlDQpjb21tZW50cyBmcm9tIFRhbyBNYSwgT3ZlIFN0cmFu ZGJlcmcsIFl1bmZlaSBaaGFuZyBhbmQgRGF2aWQgQnJ5YW4uwqAgV2UgZXhwZWN0DQp0byBzdWJt aXQgYW4gdXBkYXRlZCBJLUQgc29tZXRpbWUgbmV4dCB3ZWVrLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQpjb2xvcjojMUY0OTdEJz48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0n Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KY29s b3I6IzFGNDk3RCc+U2luY2VyZWx5LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9 TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxp YnJpIiwic2Fucy1zZXJpZiI7DQpjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KY29sb3I6IzFGNDk3RCc+QWti YXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHls ZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0K Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KDQo8ZGl2Pg0KDQo8 ZGl2IHN0eWxlPSdib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFk ZGluZzozLjBwdCAwaW4gMGluIDBpbic+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Yj48c3BhbiBz dHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiIn PkZyb206PC9zcGFuPjwvYj48c3Bhbg0Kc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz4NCmRlY2FkZS1ib3VuY2VzQGlldGYub3JnIFttYWls dG86ZGVjYWRlLWJvdW5jZXNAaWV0Zi5vcmddIDxiPk9uIEJlaGFsZiBPZiA8L2I+V291bmR5LA0K UmljaGFyZDxicj4NCjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXksIEphbnVhcnkgMTIsIDIwMTEgOTow MSBQTTxicj4NCjxiPlRvOjwvYj4gJ2FiY2RtYXRhb0BnbWFpbC5jb20nOyAnZGVjYWRlQGlldGYu b3JnJzxicj4NCjxiPkNjOjwvYj4gJ3poYW5nY2guYnVwdC4wMDFAZ21haWwuY29tJzsgJ3FpdXhp YW9mZW5nQGdtYWlsLmNvbSc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtkZWNhZGVdIFJldmll d3Mgb2YgdGhlIERlY2FkZSBTdXJ2ZXkgZHJhZnQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjwv ZGl2Pg0KDQo8L2Rpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCmNvbG9yOiMxRjQ5N0QnPlRoYW5rcyBm b3IgdGhlIGFkZGl0aW9uYWwgcmV2aWV3ITxicj4NCjxicj4NCi0tIFJpY2g8YnI+DQo8L3NwYW4+ PGJyPg0KJm5ic3A7PG86cD48L286cD48L3A+DQoNCjxkaXYgc3R5bGU9J2JvcmRlcjpub25lO2Jv cmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluJz4N Cg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxiPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+RnJvbTwvc3Bhbj48L2I+PHNwYW4NCnN0 eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+ OiBUYW8gTWENClttYWlsdG86YWJjZG1hdGFvQGdtYWlsLmNvbV0gPGJyPg0KPGI+U2VudDwvYj46 IFdlZG5lc2RheSwgSmFudWFyeSAxMiwgMjAxMSAwODozNiBQTTxicj4NCjxiPlRvPC9iPjogZGVj YWRlQGlldGYub3JnICZsdDtkZWNhZGVAaWV0Zi5vcmcmZ3Q7IDxicj4NCjxiPkNjPC9iPjogcWl1 eGlhb2ZlbmdAZ21haWwuY29tICZsdDtxaXV4aWFvZmVuZ0BnbWFpbC5jb20mZ3Q7OyBjaCB6aGFu ZyAmbHQ7emhhbmdjaC5idXB0LjAwMUBnbWFpbC5jb20mZ3Q7DQo8YnI+DQo8Yj5TdWJqZWN0PC9i PjogUmU6IFtkZWNhZGVdIFJldmlld3Mgb2YgdGhlIERlY2FkZSBTdXJ2ZXkgZHJhZnQgPGJyPg0K PC9zcGFuPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KDQo8L2Rpdj4NCg0KPHAgY2xhc3M9TXNvTm9y bWFsPkhpLCBhbGw8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsgSSdkIGFsc28gbGlrZSB0byBhZGQg c29tZSByZXZpZXdzIG9uIHRoZSBzdXJ2ZXkgZHJhZnQuIEkNCnRoaW5rIGl0IGEgdmVyeSBjb21w cmVoZW5zaXZlIHN1cnZleSBvZiBjdXJyZW50IGluLW5ldHdvcmsgc3RvcmFnZSBzeXN0ZW0uSQ0K aGF2ZSBzb21lIG1pbm9yIGNvbW1lbnRzOjxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyAxIEluIHNl Y3Rpb24gMi4yICZxdW90O0hpc3RvcmljYWwgQ29udGV4dCZxdW90OywgaXQgbWFpbmx5DQptZW50 aW9uZWQgd2ViIGNhY2hlIGFuZCBDRE4gYXMgdGhlIGhpc3RvcmljYWwgcHJlZGVjZXNzb3Igb2Yg REVDQURFLiBIb3dldmVyLCBJDQpiZWxpZXZlICZxdW90O1AyUCBjYWNoZSZxdW90OyBzaG91bGQg YmUgbWVudGlvbmVkIGhlcmUgdG9vLCB3aGljaCBpcw0KaGlnaGxpZ2h0ZWQgaW4gcHJvYmxlbSBz dGF0ZW1lbnQgZHJhZnQuPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7IDIgQXMgeXVuZmVpIHpoYW5n IGhhcyBtZW50aW9uZWQgaW4gPHU+PGENCmhyZWY9Imh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1h cmNoaXZlL3dlYi9kZWNhZGUvY3VycmVudC9tc2cwMDM0MC5odG1sIj5odHRwOi8vd3d3LmlldGYu b3JnL21haWwtYXJjaGl2ZS93ZWIvZGVjYWRlL2N1cnJlbnQvbXNnMDAzNDAuaHRtbDwvYT48L3U+ LA0KSSBhbHNvIGFncmVlIHRvIGVtcGhhc2l6ZSB0aGUgbW9iaWxlIHNjZW5hcmlvcyB3aGljaCBp cyBub3Qgc3VmZmljaWVudGx5DQpkZXNjcmliZWQgaW4gY3VycmVudCBzdXJ2ZXkgZHJhZnQuPGJy Pg0KJm5ic3A7Jm5ic3A7Jm5ic3A7IDMgSW4gdGhlIGZpcnN0IGxpbmUgb2Ygc2VjaW9uIDQuMy4x LCAmcXVvdDtzeXNlbSZxdW90Ow0Kc2hvdWxkIGJlICZxdW90O3N5c3RlbSZxdW90Ozxicj4NCiZu YnNwOyZuYnNwOyZuYnNwOyA0IEluIHNlY3Rpb24gNC41LjQsICZxdW90O05vdCBhcHBsaWNhYmxl JnF1b3Q7IHNob3VsZCBiZQ0KJnF1b3Q7Tm90IHByb3ZpZGVkJnF1b3Q7IGFzIHRoZSBvdGhlciBz eXN0ZW0gZGVzY3JpYmVkIGZvciB1bmlmb3JtIHJlYXNvbjxicj4NCjxicj4NClRhbyBNYTxicj4N CkJlaWppbmcgVW5pdmVyc2l0eSBvZiBQb3N0cyBhbmQgVGVsZWNvbW11bmljYXRpb25zLCBNSU5F bGFiPGJyPg0KJm5ic3A7Jm5ic3A7IDxvOnA+PC9vOnA+PC9wPg0KDQo8L2Rpdj4NCg0KPC9ib2R5 Pg0KDQo8L2h0bWw+DQo= ------_=_NextPart_001_01CBB336.EFA4F48C-- From richard.alimi@gmail.com Sat Jan 15 04:43:49 2011 Return-Path: X-Original-To: decade@core3.amsl.com Delivered-To: decade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 99F403A6B61 for ; Sat, 15 Jan 2011 04:43:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.514 X-Spam-Level: X-Spam-Status: No, score=-2.514 tagged_above=-999 required=5 tests=[AWL=0.462, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2z-GR-vzpyQS for ; Sat, 15 Jan 2011 04:43:48 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id 9783A3A6B49 for ; Sat, 15 Jan 2011 04:43:48 -0800 (PST) Received: by iyi42 with SMTP id 42so3584652iyi.31 for ; Sat, 15 Jan 2011 04:46:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=orXmtF1h9B30TV6wkqhB5rSpL0B4eE/aadK1DS+ap20=; b=Tpz64QJaGBMHP5Y6UtrprXgNhSipXes3DzDzP411XsgNE5oSoeLKvLs1QFpobpk6G1 HHpJPyZki4XUB5Dqboo3ZSaTKXQUYNDI7rePJ/FRMol1eJa6qSpDm2sbRJBFWzn5lJ7W RmVHe8rKg5xpta1wWstyHS3t7mRmZirawnnhQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=Pi4en+PyOCE9206BotD3EBqqBEzpYttXnkuVvVTzphV5LJRT5xcIMduh6CqHNQWQP6 Ag8b+8HnSlomOXhVPhA+uOS5sQC/R07/f4TcM9KgSx71OZjbhdm8bCxVjp5t6E8smPds bmhCQ/TuXZdMrwCxGppqmIoOzCtLXEyfcey00= MIME-Version: 1.0 Received: by 10.231.30.73 with SMTP id t9mr1921618ibc.64.1295095576662; Sat, 15 Jan 2011 04:46:16 -0800 (PST) Sender: richard.alimi@gmail.com Received: by 10.231.11.66 with HTTP; Sat, 15 Jan 2011 04:46:16 -0800 (PST) In-Reply-To: References: Date: Sat, 15 Jan 2011 04:46:16 -0800 X-Google-Sender-Auth: Ke7Nj3KZIxQ9iH1BIua7hkkbDvc Message-ID: From: Richard Alimi To: Tao Ma Content-Type: multipart/alternative; boundary=0022152d607dcc14280499e1eff5 Cc: decade@ietf.org, ch zhang , qiuxiaofeng@gmail.com Subject: Re: [decade] Reviews of the Decade Survey draft X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Jan 2011 12:43:49 -0000 --0022152d607dcc14280499e1eff5 Content-Type: text/plain; charset=ISO-8859-1 Hi Tao, Thank you very much for the review. We are currently addressing the comments, and had one question. Please see inline: On Wed, Jan 12, 2011 at 5:36 PM, Tao Ma wrote: > > 2 As yunfei zhang has mentioned in *** > http://www.ietf.org/mail-archive/web/decade/current/msg00340.html*, I also > agree to emphasize the mobile scenarios which is not sufficiently described > in current survey draft. > We addressed Yunfei's comment by referencing the discussion in the problem statement. Do you have anything else in mind? I think a draft such as the problem statement (or even a separate draft) would probably be a better place to talk about particular usage scenarios. Thanks! Rich > 3 In the first line of secion 4.3.1, "sysem" should be "system" > 4 In section 4.5.4, "Not applicable" should be "Not provided" as the > other system described for uniform reason > > Tao Ma > Beijing University of Posts and Telecommunications, MINElab > > > _______________________________________________ > decade mailing list > decade@ietf.org > https://www.ietf.org/mailman/listinfo/decade > > --0022152d607dcc14280499e1eff5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Tao,

Thank you very much for the review. =A0We are cu= rrently addressing the comments, and had one question. Please see inline:
On Wed, Jan 12, 2011 at 5:36 PM, Tao Ma <abcdmatao@gmail.= com> wrote:
=A0=A0=A0 2 As yunfei zhang has mentioned in = http://www.ietf.org/mai= l-archive/web/decade/current/msg00340.html, I also agree to emphasi= ze the mobile scenarios which is not sufficiently described in current surv= ey draft.

We addressed Yunfei's comment by refer= encing the discussion in the problem statement. Do you have anything else i= n mind? =A0I think a draft such as the problem statement (or even a separat= e draft) would probably be a better place to talk about particular usage sc= enarios.

Thanks!
Rich
=A0
=A0=A0=A0 3 In the first line of secion 4.3.1, "sysem" should be = "system"
=A0=A0=A0 4 In section 4.5.4, "Not applicable&qu= ot; should be "Not provided" as the other system described for un= iform reason

Tao Ma
Beijing University of Posts and Telecommunications, MINElab=A0=A0

_______________________________________________
decade mailing list
decade@ietf.org
= https://www.ietf.org/mailman/listinfo/decade


--0022152d607dcc14280499e1eff5-- From buptxiaozhu@gmail.com Sun Jan 16 17:59:28 2011 Return-Path: X-Original-To: decade@core3.amsl.com Delivered-To: decade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 605EA28C0D0 for ; Sun, 16 Jan 2011 17:59:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.871 X-Spam-Level: X-Spam-Status: No, score=0.871 tagged_above=-999 required=5 tests=[AWL=-1.481, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dh+yqhdSAadG for ; Sun, 16 Jan 2011 17:59:25 -0800 (PST) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by core3.amsl.com (Postfix) with ESMTP id 63F6228C0E4 for ; Sun, 16 Jan 2011 17:59:24 -0800 (PST) Received: by eyd10 with SMTP id 10so2434471eyd.31 for ; Sun, 16 Jan 2011 18:01:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=NyedAVIN/BHuOcLTcOnkPNeoa5uR7DDggIcKygFnwWg=; b=dHekR7Eiw2SbfXAlFyt+qPdxGbwUbjDNmiHWYZfAJFL0NJ1M0bQwvDNf1npRdf6vbL JhBsxoRp27tD7dNeXPeOe/Z4uyQRpmFQ7fkF3VApaJ8l9phPPw51EcnlJKl3k62sa3Gf 7olhPsgcSRJwaS4kLHmNBvmPdfBPZcHXJkiss= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=OYzrE6BXZVjVP8evmWr/XSKV/LB2e4godVKGg5YBfJ1qY66FtbTtfDHEch7cxYS8Os mSgpqGlmRBAVCh/b7uHu0IvWb28RnqwIR+qNVIMWxccoq31z9w2rWdQwl8rJQ5tSDF0F Rum7sYjzr9mMCS9Jt9Nh3K1+PTZiQ+Y/7V4E0= MIME-Version: 1.0 Received: by 10.14.10.19 with SMTP id 19mr2681881eeu.42.1295229715427; Sun, 16 Jan 2011 18:01:55 -0800 (PST) Received: by 10.14.29.71 with HTTP; Sun, 16 Jan 2011 18:01:55 -0800 (PST) In-Reply-To: References: Date: Mon, 17 Jan 2011 10:01:55 +0800 Message-ID: From: =?GB2312?B?1uzk7A==?= To: Richard Alimi Content-Type: multipart/alternative; boundary=0016364c75661731ea049a012bf0 Cc: decade@ietf.org Subject: Re: [decade] draft-zhu-decade-additional-requirements X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jan 2011 01:59:28 -0000 --0016364c75661731ea049a012bf0 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable hi, Richard: thanks for your reply:D additional discussion see inline:D 2011/1/14 Richard Alimi > HI Xiao, > > 2011/1/12 =D6=EC=E4=EC : > > hi, Richard > > see inline:D > > > > 2011/1/11 Richard Alimi > >> > >> Hi Xiao, > >> > >> On Mon, Jan 10, 2011 at 6:45 PM, =D6=EC=E4=EC = wrote: > >> > > >> > hi, Richard, sorry for so late response because of be busy with othe= r > >> > projects. > >> > some discussion see inline:D marked by red. > >> > > >> > On Tue, Jan 4, 2011 at 4:06 AM, Richard Alimi > >> > wrote: > >> >> > >> >> Hi Xiao, > >> >> > >> >> Thank you for the draft. Some comments on the requirements: > >> >> > >> >> Request Redirects: > >> >> > >> >> This would provide some additional freedom for the storage provider= . > >> >> I think it is reasonable since it doesn't necessitate additional > >> >> complexity for the DECADE server, but allows it if desired. However= , > >> >> note that it may complicate some of the other components of the > >> >> design. In particular, if there is a per-user quota for storage, is > >> >> the user made aware of the quota at each in-network storage (if the= re > >> >> is no shared storage between them)? Resource sharing policies may = be > >> >> impacted (e.g., if a bandwidth sharing weight of 1 may mean somethi= ng > >> >> different at DECADE server A than it does at DECADE server B). At > >> >> this point it may be best to just note these so they are documented= , > >> >> but since the specification of the resource sharing policies are > still > >> >> being contemplated for the basic case of a single server it may be > >> >> premature to even try and solve them for the case supporting > >> >> redirection. > >> >> > >> > actually, you mean two points, right? > >> > 1. whether or not to be ware of the content at each in-network stora= ge > >> > and of course resource sharing policies can be impact in the request > >> > redirection. your suggestion"just to note these so they are > documented" will > >> > be ok, or DECADE server list with some parameters will be return for > user to > >> > select the appropriate DECADE server, which can avoid the different > weighted > >> > of the same parameter in server decision. but the parameter used in > select > >> > the best DECADE server will be known for DECADE servers, in which > other > >> > complexities will be added. anyway, all the solution are the > implementation > >> > issue, which, i believe, does not impact the necessity of the > requirement. > >> > >> In general, I'd agree that the decision about where to redirect would > >> be an implementation issue. > >> > >> > > >> > 2. you mean "the resource sharing policies are still being considere= d > in > >> > a single server", so it may be premature to support redirection. th= e > >> > architecture and protocol will be badly impacted if the requirements > change. > >> > so the designing can be taken step by step, but the requirements > should be > >> > overall considered. > >> > >> I said that it is probably premature to consider how resource sharing > >> policies works across servers (or even if we need to say anything > >> about it) since we have not determined how to specify them (or rather, > >> how little we need to specify in protocol) for a single server. I did > >> not mean to imply that redirection could not be introduced as a > >> requirement. > >> > > > >> > >> > > >> > > >> >> > >> >> Multi-connection: > >> >> > >> >> I'm not quite clear on the intention of the requirement. My > >> >> understanding is that you wish the client to be able to have multip= le > >> >> connections open spanning multiple DECADE servers. Is that correct? > >> >> > >> >> If so, do we need this stated as a requirement or the protocol? Or = is > >> >> this a policy that would be allowed/disallowed by the storage > >> >> provider? > >> >> > >> > yep, your understanding is right, the scenarios were just described = in > >> > draft as "soft handover in wireless environment and delete operation > in > >> > multi-servers". under these consideration, the authentication and > >> > authorization need to be taken each time when setup connection with = a > new > >> > DECADE server, or just be taken only once during the service? > >> > >> The DECADE server should need to do some sort of check on each new > >> connection, regardless of whether the user has or previously had a > >> connection open to a different DECADE server, right? Note that the > >> requirements don't indicate how authentication or authorization is > >> done, and allow a server to make optimizations if it is enforcing the > >> same permissions. > >> > >> Can you indicate where the existing authorization-related requirements > >> (in particular, 4.1.6.3 of draft-ietf-decade-reqs-00) do not suffice > >> for the use case you are thinking of? > > > as considering the service continuity, the next serving DECADE server > > should know the progress of the service, how does they know? > > By progress of the service, do you mean current user state (e.g., > quota, recent resource usage history, permissions, etc)? > yes, and include data delivery proceeding. > > so if the > > service proceeding information should be known by the next serving > server, > > or different servers need to coordinate and schedule each other to > fulfill > > the user request, i believe the the 4.1.6.3 of the > draft-ietf-decade-req-00 > > cannot satisfy the req. what do you think about? > > Note that the protocol that is covered here is the client-server > protocol. Some of the same protocol may be useful between DECADE > servers (especially in different administrative domains) for storing > and retrieving data, but that does not mean that there can't be > additional protocol(s) (not specified here) that are used between > DECADE servers as well. For example, if DECADE servers within an > administrative domain can certainly have their own mechanism to share > such information. If such capabilities were included in the DECADE > protocol (e.g., a need to do this between administrative domains), > that sounds like lots more complexity that we need at this point. > but the access between in-network storage also is included in IAP describ= ed > in problem statement. i mean why not put this kind of function in DECADE > since the IAP is defined just like that? > That said, it sounds to me like what is described in 4.1.6.3 would be > sufficient (from the perspective of the client-server protocol, > anyways) to implement what you're describing. If not, what > specifically is missing and what use-case does it not meet? > so you mean the information you mentioned above, just like current user > state (e.g., > quota, recent resource usage history, permissions, etc) was already > included in DECADE requirement? what about the data delivery proceeding > information? can you specify the chapter for me ? thanks? > >> > > >> > > >> >> > >> >> Data Distribution: > >> >> > >> >> I'm also confused about the intent of this requirement. This > >> >> statement has me somewhat worried: "The distribution is transparent > to > >> >> the users as they interact with the in-network storage as a single > >> >> logical system." Does this mean that you are proposing for DECADE > >> >> servers to assume the responsibility for deciding how data is to be > >> >> distributed throughout the network, including the path of the data, > >> >> which servers act as intermediate caches, content expiration > policies, > >> >> etc? If this is true, I think it is missing one of the major point= s > >> >> of DECADE. In particular, these decisions are application-dependent > >> >> and are not implemented within DECADE. Instead, DECADE provides the > >> >> basic capabilities and the functionality described above are > >> >> implemented by the applications using DECADE. > >> >> > >> >> Or, am I misinterpreting the intent of the requirement? > >> >> > >> > you mean DECADE provides the basic capabilities, so can you give som= e > >> > specify explanations on DECADE capabilities in supporting data > distribution? > >> >> > >> > >> The problem statement gives a couple of scenarios. The "Integration > >> Examples" presentation from IETF 79 also has more details of an > >> on-going effort at Yale. > > > okay, thx for your information, i will lookup and refer, actually, the > > content publisher described in problem statement remind me of the > > protocol requirements which i did not find in draft-ietf-decade-reqs-00 > to > > support content publish. or i miss some points? > > Which requirements do you think are missing? > > >> >> Service Assurance: > >> >> > >> >> It seems problematic to include "assurance" in a DECADE. Shouldn't > >> >> these instead be part of SLAs with a storage provider? Why should > >> >> they be DECADE's responsibility? > >> >> > >> >> Regarding "resource reservation", are you referring to an actual > >> >> reservation (which might be problematic -- see above) or do you mea= n > >> >> that the resource share should able to be specified at the time the > >> >> connection opens and be assumed to be the same for the duration of > the > >> >> connection? > >> >> > >> >> Regarding Dynamic Feedback, is this orthogonal to the storage > >> >> protocol? It seems like what you want here is a generic "status" > >> >> service saying how loaded a server is? > >> >> > >> > thats right, actually, the flow control mechanism was under discussi= on > >> > in writing the draft at first. what about your opinion in this > requirements? > >> > > >> > >> I'm not sure what the typical way of providing such "load status" > >> information for IETF protocols, but my inclination is that it should > >> not be in the DECADE protocol itself. Maybe someone else with a > >> longer history in IETF could jump in here :) > > so can i understand that "load status" is kind of necessity informatio= n > > for DECADE Server, but where and who collects the information are > > remain discussion? > > The storage provider is free to collect the information wherever and > however they wish. The DECADE server implementation could additional > export whatever status information it wishes. I don't think the DECADE > protocol needs to be concerned with that. > > Note that certain error conditions (e.g., overload, insufficient > resources) may be signaled by a DECADE server (there are already have > requirements for those). If you are referring to status for a user's > resources, there is already a requirement for that too. > > I'm just not convinced that the DECADE protocol needs to export its > current load status to clients. > actually i am not sure which elements in DECADE needs the load > status,(DECADE client or network storage if the network storage needs to > redirect the request or both?). > > And the requirement draft currently seems describe the overload condition > as the event triggering. do you think if it is necessary to periodically > reporting of the DECADE network status to client for its network storage > selection? > > and the requirement draft just describe DECADE which is busy to serve oth= er > requests must be able to reject requests, not consider how to handle the > user request after being rejected? > >> >> > >> >> Data classification: > >> >> > >> >> Would it be better to instead have the client specify properties of > >> >> the content instead of place it into ? See > >> >> www.ietf.org/proceedings/78/slides/nfsv4-0.pdf for an example of > this > >> >> approach for NFS. > >> >> > >> >> I think a problem with classifying applications is that it assumes > >> >> that applications fit one of the supplied classifications. What if = it > >> >> may fit multiple classifications? or none? Another problem is it > >> >> assumes that servers assume based on indirect and assumed informati= on > >> >> that they know what to do with a particular piece of content. Why n= ot > >> >> have an application specify its desires directly? > >> >> > >> > > >> > > >> >> > >> >> Small Objects: > >> >> > >> >> What is the new requirement here? Why is the existing requirement = in > >> >> draft-ietf-decade-reqs-00 insufficient? > >> >> > >> >> This also has me a bit worried: > >> >> "And the in-network storage has the limited storage capacity, with > the > >> >> arrival of user requests and data distribution requirements, the da= ta > >> >> stored in the in-network storage will be replaced if the storage > >> >> reaches the limit and data arrivals continually." > >> >> > >> >> How does the server know what the proper replacement strategy is fo= r > >> >> an application? I think DECADE's philosophy is that applications > >> >> should decide this. A simple way to do this is explicit deletion by > an > >> >> application, but perhaps a more efficient (yet more complex) soluti= on > >> >> is for an application to specify the replacement policy to the > server. > >> >> > >> > actually, the key in "the data classification and small objects " is > >> > whether does it or not in P2P application? i did not find data > >> > classification was adopted in P2P application so far, let alone DECA= DE > need > >> > to classify the data used in all kinds of application. > >> > > >> > >> So, do you agree that it is problematic to try and classify each type > >> of application and try to specify the typical workload for each class? > >> > >> My point was that I don't think its necessary to do the classification > >> at all. It is more extensible (and directly useful) for a server to > >> just give it direct hints about what would be preferable. > > > > yep, i believe it may be a little difficult, but worthy doing. speciall= y > > for improving the resource utilization within a single server and > reducing > > the response time for client. what about others opinion? > > Can you justify why giving classifications (e.g., "I'm a live > streaming application") would be better than giving specific hints > (e.g., "please don't bother persistent these objects to disk")? > i mean data in different kind of operation mode and attribute should have > different user patterns and storage rules, which may be help to improve t= he > resource utilization and reduce the response time for request, what are y= ou > understanding? > > >> > >> >> Removal of Expired Records: > >> >> > >> >> "However, the two scenarios did not mention how to handle the old > >> >> resource if the user distributes the new resource which is an updat= ed > >> >> copy of the old resource." > >> >> > >> >> Why does this need to be handled in the requirements? Are you tryi= ng > >> >> to draw the distinction between immediate deletion of content and > lazy > >> >> deletion? > >> >> > >> > i mean the meaning of delete operation and how to handle the expired > >> > records need to be clarify in requirements. > >> > >> My inclination is that "deleted" means that other requests the object > >> of the same name should result an error, until another object with the > >> same name is stored. > > > > okay, under the scenario "client uploads the new version, and did not > > specify how to handle the old version", did DECADE server delete the > older > > version (or just label it unavailable, anyway, it is implementation iss= ue > ) > > or not ? in another word, just replace the older version with the new > > version with the same name? > > In this case, I would think the "write" of the new object should be > rejected, or if desired, we could have an overwrite option. This > could be added to the requirements if it helps to clarify. > yep, no matter which solution is chosen, let the understanding unanimousl= y > :D > > how to handle the older version which is > > transferring from server to client? > > I think it would be cleaner to ask the server to continue sending an > object once it has been started, but ultimately this would be the > decision of the server's implementation I think. Maybe a "SHOULD" > requirement. This could be added if desired. > > Thank you for these questions. It helps design the requirements more > cleanly if there are specific scenarios in front of us :) > just discussion together:D and also thanks for your points to help me > understanding more! > Rich > > >> I think that the time the data is removed from disk (or memory) should > >> be up to the implementation. A storage provider might still have as > >> part of some agreement that deleted data will be removed within X > >> days/hours/minutes/whatever. > > > > agree with you. > >> > >> If people in the WG think it is necessary, we could have a requirement > >> that says the protocol should support an argument indicating immediate > >> deletion, but it is not clear that we need this. > >> > >> Rich > >> > >> >> > >> >> Thanks! > >> >> Rich > >> >> > >> >> > >> >> On Mon, Dec 27, 2010 at 12:57 AM, =D6=EC=E4=EC wrote: > >> >> > Dear all, > >> >> > > >> >> > There is a slightly updated version of the decade additional > >> >> > requirements > >> >> > draft. > >> >> > > >> >> > > https://datatracker.ietf.org/doc/draft-zhu-decade-additional-requirements= / > >> >> > > >> >> > Jin Peng, Yunfei Zhang and me are expecting to have a discussion > with > >> >> > all of > >> >> > you. > >> >> > > >> >> > Any comments are appreciated! > >> >> > > >> >> > A new version of I-D, > draft-zhu-decade-additional-requirements-00.txt > >> >> > has been successfully submitted by Xiao Zhu and posted to the IET= F > >> >> > repository. > >> >> > > >> >> > Filename: draft-zhu-decade-additional-requirements > >> >> > Revision: 00 > >> >> > Title: Additional protocol requirements on DECADE > >> >> > Creation_date: 2010-12-27 > >> >> > WG ID: Independent Submission > >> >> > Number_of_pages: 10 > >> >> > > >> >> > Abstract: > >> >> > The DECoupled Application Data Enroute(DECADE)working group is > >> >> > specifying standardized interfaces for accessing in-network stora= ge > >> >> > from applications to store, retrieve and manage data. The main > object > >> >> > is to provide a framework that is useful to the applications, > >> >> > including P2P applications and other data-oriented applications, > >> >> > possibly related applications that can benefit from accessing in- > >> >> > network storage. This memo focuses on some requirements such as > >> >> > request redirecting and so on which are on the central of mobilit= y, > >> >> > wireless network environment and CDN application. We present thes= e > in > >> >> > this memo as additional requirements that should be considered fo= r > >> >> > the DECADE architecture and protocol specifications. > >> >> > > >> >> > > >> >> > > >> >> > The IETF Secretariat. > >> >> > > >> >> > -- > >> >> > Best wishes, > >> >> > > >> >> > Beijing University of Posts & Telecommunications (BUPT) > >> >> > Zhu Xiao ( =D6=EC=E4=EC ) > >> >> > E-mail: buptxiaozhu@gmail.com > >> >> > mobile:+86 134-8881-9004 > >> >> > > >> >> > _______________________________________________ > >> >> > decade mailing list > >> >> > decade@ietf.org > >> >> > https://www.ietf.org/mailman/listinfo/decade > >> >> > > >> >> > > >> > > >> > > >> > > >> > -- > >> > Best wishes, > >> > > >> > Beijing University of Posts & Telecommunications (BUPT) > >> > Zhu Xiao ( =D6=EC=E4=EC ) > >> > E-mail: buptxiaozhu@gmail.com > >> > mobile:+86 134-8881-9004 > > > > > > > > -- > > Best wishes, > > > > Beijing University of Posts & Telecommunications (BUPT) > > Zhu Xiao ( =D6=EC=E4=EC ) > > E-mail: buptxiaozhu@gmail.com > > mobile:+86 134-8881-9004 > > > --=20 Best wishes, Beijing University of Posts & Telecommunications (BUPT) Zhu Xiao ( =D6=EC=E4=EC ) E-mail: buptxiaozhu@gmail.com mobile:+86 134-8881-9004 --0016364c75661731ea049a012bf0 Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable hi, Richard:

thanks for your reply:D
additiona= l discussion see inline:D

2011/1/14 Rich= ard Alimi <rich@= velvetsea.net>
HI Xiao,

2011/1/12 =D6=EC=E4=EC <buptxia= ozhu@gmail.com>:
> hi, Richard
> see inline:D
>
> 2011/1/11 Richard Alimi <rich= @velvetsea.net>
>>
>> Hi Xiao,
>>
>> On Mon, Jan 10, 2011 at 6:45 PM, =D6=EC=E4=EC <buptxiaozhu@gmail.com> wrote:
>> >
>> > hi, Richard, sorry for so late response because of be busy wi= th other
>> > projects.
>> > some discussion see inline:D marked by red.
>> >
>> > On Tue, Jan 4, 2011 at 4:06 AM, Richard Alimi <rich@velvetsea.net>
>> > wrote:
>> >>
>> >> Hi Xiao,
>> >>
>> >> Thank you for the draft.  Some comments on the requi= rements:
>> >>
>> >> Request Redirects:
>> >>
>> >> This would provide some additional freedom for the storag= e provider.
>> >> I think it is reasonable since it doesn't necessitate= additional
>> >> complexity for the DECADE server, but allows it if desire= d. However,
>> >> note that it may complicate some of the other components = of the
>> >> design. In particular, if there is a per-user quota for s= torage, is
>> >> the user made aware of the quota at each in-network stora= ge (if there
>> >> is no shared storage between them)?  Resource sharin= g policies may be
>> >> impacted (e.g., if a bandwidth sharing weight of 1 may me= an something
>> >> different at DECADE server A than it does at DECADE serve= r B).  At
>> >> this point it may be best to just note these so they are = documented,
>> >> but since the specification of the resource sharing polic= ies are still
>> >> being contemplated for the basic case of a single server = it may be
>> >> premature to even try and solve them for the case support= ing
>> >> redirection.
>> >>
>> > actually, you mean two points, right?
>> > 1. whether or not to be ware of the content at each in-networ= k storage
>> > and of course resource sharing policies can be impact in the = request
>> > redirection. your suggestion"just to note these so they = are documented" will
>> > be ok, or DECADE server list with some parameters will be ret= urn for user to
>> > select the appropriate DECADE server, which can avoid the dif= ferent weighted
>> > of the same parameter in server decision. but the parameter u= sed in select
>> > the best DECADE server will be known for DECADE servers, in w= hich other
>> > complexities will be added. anyway, all the solution are the = implementation
>> > issue, which, i believe, does not impact the necessity of the= requirement.
>>
>> In general, I'd agree that the decision about where to redirec= t would
>> be an implementation issue.
>>
>> >
>> > 2. you mean "the resource sharing policies are still bei= ng considered in
>> > a single server", so it may be premature to support redi= rection.  the
>> > architecture and protocol will be badly impacted if the requi= rements change.
>> > so the designing can be  taken  step by step, but t= he requirements should be
>> > overall considered.
>>
>> I said that it is probably premature to consider how resource shar= ing
>> policies works across servers (or even if we need to say anything<= br> >> about it) since we have not determined how to specify them (or rat= her,
>> how little we need to specify in protocol) for a single server. I = did
>> not mean to imply that redirection could not be introduced as a >> requirement.
>>
>
>>
>> >
>> >
>> >>
>> >> Multi-connection:
>> >>
>> >> I'm not quite clear on the intention of the requireme= nt.  My
>> >> understanding is that you wish the client to be able to h= ave multiple
>> >> connections open spanning multiple DECADE servers. Is tha= t correct?
>> >>
>> >> If so, do we need this stated as a requirement or the pro= tocol? Or is
>> >> this a policy that would be allowed/disallowed by the sto= rage
>> >> provider?
>> >>
>> > yep, your understanding is right, the scenarios were just des= cribed in
>> > draft as "soft handover in wireless environment and dele= te operation in
>> > multi-servers". under these consideration, the authentic= ation and
>> > authorization need to be taken each time when setup connectio= n with a new
>> > DECADE server, or just be taken only once during  the se= rvice?
>>
>> The DECADE server should need to do some sort of check on each new=
>> connection, regardless of whether the user has or previously had a=
>> connection open to a different DECADE server, right?  Note th= at the
>> requirements don't indicate how authentication or authorizatio= n is
>> done, and allow a server to make optimizations if it is enforcing = the
>> same permissions.
>>
>> Can you indicate where the existing authorization-related requirem= ents
>> (in particular, 4.1.6.3 of draft-ietf-decade-reqs-00) do not suffi= ce
>> for the use case you are thinking of?

> as considering the service continuity, the next serving  DECADE s= erver
> should know the progress of the service, how does they know?

By progress of the service, do you mean current user state (e.g= .,
quota, recent resource usage history, permissions, etc)?
yes, a= nd include data delivery proceeding.
> so if the
> service proceeding information should be known by the next serving ser= ver,
> or different servers need to coordinate and schedule each other to ful= fill
> the user request, i believe the the 4.1.6.3 of the draft-ietf-decade-r= eq-00
> cannot satisfy the req. what do you think about?

Note that the protocol that is covered here is the client-server
protocol. Some of the same protocol may be useful between DECADE
servers (especially in different administrative domains) for storing
and retrieving data, but that does not mean that there can't be
additional protocol(s) (not specified here) that are used between
DECADE servers as well.  For example, if DECADE servers within an
administrative domain can certainly have their own mechanism to share
such information.  If such capabilities were included in the DECADE protocol (e.g., a need to do this between administrative domains),
that sounds like lots more complexity that we need at this point.
but the access between i= n-network storage also is included in IAP described in problem statement. &= nbsp;i mean why not put this kind of function in DECADE since the IAP is de= fined just like that?
That said, it sounds to me like what is described in 4.1.6.3 would be
sufficient (from the perspective of the client-server protocol,
anyways) to implement what you're describing. If not, what
specifically is missing and what use-case does it not meet?
so you= mean the information you mentioned above, just like current user stat= e (e.g.,
quota, recent resource usage history, permissions, etc) was alr= eady included in DECADE requirement? what about the data delivery proceedin= g information? can you specify the chapter for me ? thanks?  >> >
>> >
>> >>
>> >> Data Distribution:
>> >>
>> >> I'm also confused about the intent of this requiremen= t.  This
>> >> statement has me somewhat worried: "The distribution= is transparent to
>> >> the users as they interact with the in-network storage as= a single
>> >> logical system." Does this mean that you are proposi= ng for DECADE
>> >> servers to assume the responsibility for deciding how dat= a is to be
>> >> distributed throughout the network, including the path of= the data,
>> >> which servers act as intermediate caches, content expirat= ion policies,
>> >> etc?  If this is true, I think it is missing one of = the major points
>> >> of DECADE. In particular, these decisions are application= -dependent
>> >> and are not implemented within DECADE. Instead, DECADE pr= ovides the
>> >> basic capabilities and the functionality described above = are
>> >> implemented by the applications using DECADE.
>> >>
>> >> Or, am I misinterpreting the intent of the requirement? >> >>
>> > you mean DECADE provides the basic capabilities, so can you g= ive some
>> > specify explanations on DECADE capabilities in supporting dat= a distribution?
>> >>
>>
>> The problem statement gives a couple of scenarios. The "Integ= ration
>> Examples" presentation from IETF 79 also has more details of = an
>> on-going effort at Yale.

> okay, thx for your information, i will lookup and refer, actually, the=
> content publisher described in problem statement remind me of  th= e
> protocol requirements which i did not find in draft-ietf-decade-reqs-0= 0 to
> support content publish. or i miss some points?

Which requirements do you think are missing?

>> >> Service Assurance:
>> >>
>> >> It seems problematic to include "assurance" in = a DECADE.  Shouldn't
>> >> these instead be part of SLAs with a storage provider? &n= bsp;Why should
>> >> they be DECADE's responsibility?
>> >>
>> >> Regarding "resource reservation", are you refer= ring to an actual
>> >> reservation (which might be problematic -- see above) or = do you mean
>> >> that the resource share should able to be specified at th= e time the
>> >> connection opens and be assumed to be the same for the du= ration of the
>> >> connection?
>> >>
>> >> Regarding Dynamic Feedback, is this orthogonal to the sto= rage
>> >> protocol?  It seems like what you want here is a gen= eric "status"
>> >> service saying how loaded a server is?
>> >>
>> > thats right, actually, the flow control mechanism was under d= iscussion
>> > in writing the draft at first. what about your opinion in thi= s requirements?
>> >
>>
>> I'm not sure what the typical way of providing such "load= status"
>> information for IETF protocols, but my inclination is that it shou= ld
>> not be in the DECADE protocol itself.  Maybe someone else wit= h a
>> longer history in IETF could jump in here :)
> so can i understand that "load status" is kind of necessity =  information
> for DECADE Server, but where and who collects the information are
> remain discussion?

The storage provider is free to collect the information wherever and<= br> however they wish.  The DECADE server implementation could additional<= br> export whatever status information it wishes. I don't think the DECADE<= br> protocol needs to be concerned with that.

 Note that certain error conditions (e.g., overload, insufficient
resources) may be signaled by a DECADE server (there are already have
requirements for those).  If you are referring to status for a user= 9;s
resources, there is already a requirement for that too.

I'm just not convinced that the DECADE protocol needs to export its
current load status to clients.
actually i am not sure which elements in DECADE needs the load st= atus,(DECADE client or network storage if the network storage needs to redi= rect the request or both?).
 
And the = requirement draft currently seems describe the overload condition as the ev= ent triggering. do you think if it is necessary to periodically r= eporting of the DECADE network status to client for its network storage sel= ection?
 
and the = requirement draft just describe DECADE which is busy to serve other request= s must be able to reject requests, not consider how to handle the user requ= est after being rejected? 
 >> >>
>> >> Data classification:
>> >>
>> >> Would it be better to instead have the client specify pro= perties of
>> >> the content instead of place it into ? See
>> >> www.ietf.org/proceedings/78/slides/nfsv4-0.pdf for an example of this
>> >> approach for NFS.
>> >>
>> >> I think a problem with classifying applications is that i= t assumes
>> >> that applications fit one of the supplied classifications= . What if it
>> >> may fit multiple classifications? or none?  Another = problem is it
>> >> assumes that servers assume based on indirect and assumed= information
>> >> that they know what to do with a particular piece of cont= ent. Why not
>> >> have an application specify its desires directly?
>> >>
>> >
>> >
>> >>
>> >> Small Objects:
>> >>
>> >> What is the new requirement here?  Why is the existi= ng requirement in
>> >> draft-ietf-decade-reqs-00 insufficient?
>> >>
>> >> This also has me a bit worried:
>> >> "And the in-network storage has the limited storage = capacity, with the
>> >> arrival of user requests and data distribution requiremen= ts, the data
>> >> stored in the in-network storage will be replaced if the = storage
>> >> reaches the limit and data arrivals continually." >> >>
>> >> How does the server know what the proper replacement stra= tegy is for
>> >> an application? I think DECADE's philosophy is that a= pplications
>> >> should decide this. A simple way to do this is explicit d= eletion by an
>> >> application, but perhaps a more efficient (yet more compl= ex) solution
>> >> is for an application to specify the replacement policy t= o the server.
>> >>
>> > actually, the key in "the data classification and small = objects " is
>> > whether does it or not in P2P application? i did not find dat= a
>> > classification was adopted in P2P application so far, let alo= ne DECADE need
>> > to classify the data used in all kinds of application.
>> >
>>
>> So, do you agree that it is problematic to try and classify each t= ype
>> of application and try to specify the typical workload for each cl= ass?
>>
>> My point was that I don't think its necessary to do the classi= fication
>> at all.  It is more extensible (and directly useful) for a se= rver to
>> just give it direct hints about what would be preferable.
>
> yep, i believe it may be a little difficult, but worthy doing. special= ly
> for improving the resource utilization within a single server and redu= cing
> the response time for client. what about others opinion?

Can you justify why giving classifications (e.g., "I'm= a live
streaming application") would be better than giving specific hints
(e.g., "please don't bother persistent these objects to disk"= )?
i mean= data in different kind of operation mode and attribute should have differe= nt user patterns and storage rules, which may be help to improve the resour= ce utilization and reduce the response time for request, what are you under= standing?
> >>
>> >> Removal of Expired Records:
>> >>
>> >> "However, the two scenarios did not mention how to h= andle the old
>> >> resource if the user distributes the new resource which i= s an updated
>> >> copy of the old resource."
>> >>
>> >> Why does this need to be handled in the requirements? &nb= sp;Are you trying
>> >> to draw the distinction between immediate deletion of con= tent and lazy
>> >> deletion?
>> >>
>> > i mean the meaning of delete operation and how to handle the = expired
>> > records need to be clarify in requirements.
>>
>> My inclination is that "deleted" means that other reques= ts the object
>> of the same name should result an error, until another object with= the
>> same name is stored.
>
> okay, under the scenario "client uploads the new version, and did= not
> specify how to handle the old version", did DECADE server delete = the older
> version (or just label it unavailable, anyway, it is implementation is= sue )
> or not ? in another word, just replace the older version with the new<= br> > version with the same name?

In this case, I would think the "write" of the new object s= hould be
rejected, or if desired, we could have an overwrite option.  This
could be added to the requirements if it helps to clarify.
yep, n= o matter which solution is chosen, let the understanding unanimously:= D
> how to handle the older version which is
> transferring from server to client?

I think it would be cleaner to ask the server to continue sending an<= br> object once it has been started, but ultimately this would be the
decision of the server's implementation I think.  Maybe a "SH= OULD"
requirement.  This could be added if desired.

Thank you for these questions.  It helps design the requirements more<= br> cleanly if there are specific scenarios in front of us :)
just discussion together:D and also th= anks for your points to help me understanding more!
Rich

>> I think that the time the data is removed from disk (or memory) sh= ould
>> be up to the implementation. A storage provider might still have a= s
>> part of some agreement that deleted data will be removed within X<= br> >> days/hours/minutes/whatever.
>
>    agree with you.
>>
>> If people in the WG think it is necessary, we could have a require= ment
>> that says the protocol should support an argument indicating immed= iate
>> deletion, but it is not clear that we need this.
>>
>> Rich
>>
>> >>
>> >> Thanks!
>> >> Rich
>> >>
>> >>
>> >> On Mon, Dec 27, 2010 at 12:57 AM, =D6=EC=E4=EC <buptxiaozhu@gmail.com> wrote:
>> >> > Dear all,
>> >> >
>> >> > There is a slightly updated version of the decade ad= ditional
>> >> > requirements
>> >> > draft.
>> >> >
>> >> > https://datatracker.ie= tf.org/doc/draft-zhu-decade-additional-requirements/
>> >> >
>> >> > Jin Peng, Yunfei Zhang and me are expecting to have = a discussion with
>> >> > all of
>> >> > you.
>> >> >
>> >> > Any comments are appreciated!
>> >> >
>> >> > A new version of I-D, draft-zhu-decade-additional-re= quirements-00.txt
>> >> > has been successfully submitted by Xiao Zhu and post= ed to the IETF
>> >> > repository.
>> >> >
>> >> > Filename:      draft-zhu-decade-addit= ional-requirements
>> >> > Revision:      00
>> >> > Title:             &nb= sp;   Additional protocol requirements on DECADE
>> >> > Creation_date:         2010-12-2= 7
>> >> > WG ID:             &nb= sp;   Independent Submission
>> >> > Number_of_pages: 10
>> >> >
>> >> > Abstract:
>> >> > The DECoupled Application Data Enroute(DECADE)workin= g group is
>> >> > specifying standardized interfaces for accessing in-= network storage
>> >> > from applications to store, retrieve and manage data= . The main object
>> >> > is to provide a framework that is useful to the appl= ications,
>> >> > including P2P applications and other data-oriented a= pplications,
>> >> > possibly related applications that can benefit from = accessing in-
>> >> > network storage. This memo focuses on some requireme= nts such as
>> >> > request redirecting and so on which are on the centr= al of mobility,
>> >> > wireless network environment and CDN application. We= present these in
>> >> > this memo as additional requirements that should be = considered for
>> >> > the DECADE architecture and protocol specifications.=
>> >> >
>> >> >
>> >> >
>> >> > The IETF Secretariat.
>> >> >
>> >> > --
>> >> > Best wishes,
>> >> >
>> >> > Beijing University of Posts & Telecommunications= (BUPT)
>> >> > Zhu Xiao  ( =D6=EC=E4=EC )
>> >> > E-mail: bup= txiaozhu@gmail.com
>> >> > mobile:+86 134-8881-9004
>> >> >
>> >> > _______________________________________________
>> >> > decade mailing list
>> >> > decade@ietf.org
>> >> > https://www.ietf.org/mailman/listinfo/decade
>> >> >
>> >> >
>> >
>> >
>> >
>> > --
>> > Best wishes,
>> >
>> > Beijing University of Posts & Telecommunications (BUPT) >> > Zhu Xiao  ( =D6=EC=E4=EC )
>> > E-mail: buptxiaozhu@= gmail.com
>> > mobile:+86 134-8881-9004
>
>
>
> --
> Best wishes,
>
> Beijing University of Posts & Telecommunications (BUPT)
> Zhu Xiao  ( =D6=EC=E4=EC )
> E-mail: buptxiaozhu@gmail.com=
> mobile:+86 134-8881-9004
>



--
Best wishes= ,

Beijing University of Posts & Telecommunications (BUPT)
Zhu= Xiao  ( =D6=EC=E4=EC )
E-mail: buptxiaozhu@gmail.com
mobile:+86 134-8881-9004
--0016364c75661731ea049a012bf0-- From abcdmatao@gmail.com Sun Jan 16 18:28:18 2011 Return-Path: X-Original-To: decade@core3.amsl.com Delivered-To: decade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9DF8428C0EB for ; Sun, 16 Jan 2011 18:28:18 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ujRehsNX8D1c for ; Sun, 16 Jan 2011 18:28:17 -0800 (PST) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 45D7928C0E3 for ; Sun, 16 Jan 2011 18:28:17 -0800 (PST) Received: by wyf23 with SMTP id 23so4908369wyf.31 for ; Sun, 16 Jan 2011 18:30:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Hp+D5IQj4899YHHxkQeDpKgRB2rYhXKaoNPAd3LztyU=; b=ZA0aJ/r/iuAjTWrZ2KNQ6Uf8P2gOzAXvuGE7KhxMB/BfYY+Ls2LmvO2sEPoXGfHQwU KNB18h0NimnaYJIh/YuL3pvVGaGCxuX0hQeShlQnehYOeKqlFSh2K8gpyA0FW/ZqopRU py3Ag5HoACmU70Y/VZVyLI59JtFDcDY7jX6kc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=gcZWPg6U8TwFuvZVUi0IBUCAHo5WJNwDaHz3+nqMPHSFOyZL0HExuxQ+I13j8HJuvn NYEAm3lzrPjqVUfoBFsuesb00YScLDRGEs1Fzj3om1OiVWx8zj1vGcN0+MN2LG7U3Sfx om6nzZ6u+EeFBMKfM/TM+hrf8Jummodh4wsWE= MIME-Version: 1.0 Received: by 10.216.16.21 with SMTP id g21mr2829161weg.6.1295231449509; Sun, 16 Jan 2011 18:30:49 -0800 (PST) Received: by 10.216.47.12 with HTTP; Sun, 16 Jan 2011 18:30:49 -0800 (PST) In-Reply-To: References: Date: Mon, 17 Jan 2011 10:30:49 +0800 Message-ID: From: Tao Ma To: Richard Alimi Content-Type: multipart/alternative; boundary=0015176f16f67330cc049a0192e6 Cc: decade@ietf.org, ch zhang , qiuxiaofeng@gmail.com Subject: Re: [decade] Reviews of the Decade Survey draft X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jan 2011 02:28:19 -0000 --0015176f16f67330cc049a0192e6 Content-Type: text/plain; charset=ISO-8859-1 Hi, If it can be discussed thoroughly in problem statement draft or other drafts, I agree to address it elsewhere. Tao Ma Beijing University of Posts and Telecommunications 2011/1/15 Richard Alimi > Hi Tao, > > Thank you very much for the review. We are currently addressing the > comments, and had one question. Please see inline: > > On Wed, Jan 12, 2011 at 5:36 PM, Tao Ma wrote: >> >> 2 As yunfei zhang has mentioned in *** >> http://www.ietf.org/mail-archive/web/decade/current/msg00340.html*, I >> also agree to emphasize the mobile scenarios which is not sufficiently >> described in current survey draft. >> > > We addressed Yunfei's comment by referencing the discussion in the problem > statement. Do you have anything else in mind? I think a draft such as the > problem statement (or even a separate draft) would probably be a better > place to talk about particular usage scenarios. > > Thanks! > Rich > > >> 3 In the first line of secion 4.3.1, "sysem" should be "system" >> 4 In section 4.5.4, "Not applicable" should be "Not provided" as the >> other system described for uniform reason >> >> Tao Ma >> Beijing University of Posts and Telecommunications, MINElab >> >> >> _______________________________________________ >> decade mailing list >> decade@ietf.org >> https://www.ietf.org/mailman/listinfo/decade >> >> > --0015176f16f67330cc049a0192e6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,
=A0=A0=A0 If it can be discussed thoroughly in problem statement dr= aft or other drafts, I agree to address it elsewhere.
Tao Ma
Beijing = University of Posts and Telecommunications

2011/1/15 Richard Alimi <rich@velvetsea.net>
Hi Tao,

<= /div>
Thank you very much for the review. =A0We are currently addressin= g the comments, and had one question. Please see inline:

On Wed, Jan 12, 2011 at 5:36 PM, Tao Ma= <abcdmatao@gmail.com> wrote:
=A0=A0=A0 2 As yunfei zhang has mentioned in http://www.ietf.org/m= ail-archive/web/decade/current/msg00340.html, I also agree to empha= size the mobile scenarios which is not sufficiently described in current su= rvey draft.

We addressed Yunfei's comment by= referencing the discussion in the problem statement. Do you have anything = else in mind? =A0I think a draft such as the problem statement (or even a s= eparate draft) would probably be a better place to talk about particular us= age scenarios.

Thanks!
Rich
=A0
=A0=A0=A0 3 In the first line of secion 4.3.1, "sysem" should be = "system"
=A0=A0=A0 4 In section 4.5.4, "Not applicable&qu= ot; should be "Not provided" as the other system described for un= iform reason

Tao Ma
Beijing University of Posts and Telecommunications, MINElab=A0=A0

_______________________________________________
decade mailing list
decade@ietf.org = https://www.ietf.org/mailman/listinfo/decade



--0015176f16f67330cc049a0192e6-- From Jan.Seedorf@neclab.eu Tue Jan 18 02:28:51 2011 Return-Path: X-Original-To: decade@core3.amsl.com Delivered-To: decade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F1D963A6FBE; Tue, 18 Jan 2011 02:28:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.056 X-Spam-Level: X-Spam-Status: No, score=-101.056 tagged_above=-999 required=5 tests=[AWL=-1.221, BAYES_40=-0.185, HELO_EQ_DE=0.35, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MRLMP12JBzmv; Tue, 18 Jan 2011 02:28:50 -0800 (PST) Received: from smtp0.netlab.nec.de (smtp0.netlab.nec.de [195.37.70.40]) by core3.amsl.com (Postfix) with ESMTP id A27213A6FB8; Tue, 18 Jan 2011 02:28:49 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 08619280001AA; Tue, 18 Jan 2011 11:32:34 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office.hd) Received: from smtp0.netlab.nec.de ([127.0.0.1]) by localhost (atlas1.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zl6g+p7O7lTV; Tue, 18 Jan 2011 11:32:33 +0100 (CET) Received: from ENCELADUS.office.hd (ENCELADUS.office.hd [192.168.24.52]) by smtp0.netlab.nec.de (Postfix) with ESMTP id D773D2800017C; Tue, 18 Jan 2011 11:32:08 +0100 (CET) Received: from PALLENE.office.hd ([169.254.1.59]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0270.001; Tue, 18 Jan 2011 11:31:00 +0100 From: Jan Seedorf To: "p2prg@irtf.org" , P2PSIP WG , "ppsp@ietf.org" , 'alto' , "decade@ietf.org" Thread-Topic: Live streaming of NAPA-WINE P2P-TV workshop with P2P software Thread-Index: Acu2+sxB9abvF+YITYupvh0rusVDHQ== Date: Tue, 18 Jan 2011 10:30:59 +0000 Message-ID: <2779C9F0771F974CAD742BAE6D9904FE7E96AF@PALLENE.office.hd> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.2.226] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [decade] Live streaming of NAPA-WINE P2P-TV workshop with P2P software X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jan 2011 10:28:51 -0000 P2P folks at IETF, To help people interested in the P2P-TV workshop we are hosting, the NAPA-WINE project's final workshop will be *broadcasted live* with the P2P Live Streaming Software developed by the NAPA-WINE project. The workshop opens on Thursday 20th January at 2.30PM CET and closes on Friday 21th January afternoon at 6.00PM CET. Recordings of the workshop will be made available from the project web site few days after the event too. For people interested in following the workshop/talks live via P2P video stream, we have prepared a page with Quick-Start instructions on how to download, install, and use the software to follow the event live. If you are interested, please go to http://www.napa-wine.eu/cgi-bin/twiki/view/Public/NapaWineWorkshopLive If you have any questions regarding the use of the software or following the final workshop live with it, please use the mailing list (napalive@tlc.= polito.it). A demo activity of the software is scheduled at 5.30PM (and yes! you will be part of the demo if you join the channel!)=20 *Workshop Program*=20 The final NAPA-WINE workshop is intended as an informal forum for lively discussions on current and future trends in peer-to-peer live streaming. Th= e program comprises four talks presenting the main NAPA-WINE achievements (an= d a demo of NAPA-WINE's network-aware P2P live streaming system) as well as nin= e talks from external highly qualified researchers from both academia and industry, providing a broad and articulated perspective on the main challen= ges and solutions on the topic. There will be external presentations provided b= y (see http://www.napa-wine.eu/workshop/program.html for agenda details): - Presentations from other on-going European projects on P2P-TV/CDN: * Future Media Networks (FMN) cluster and ENVISION (David Griffin, UCL, G= B) * COAST/SEA (Emanuele Quacchio, ST Microelectronics, IT) * P2P-NEXT (Raul Jimenez, KTH, SE) - Presentations from the industrial world (the operator/content provider vi= sion): * Nikolaos Laoutaris, Telefonica Research, ES * Enrico Marocco, Chair of IETF ALTO, Telecom Italia, IT - Presentations from academia (technical challenges) * Ernst Biersack, Eurecom, FR * Phuoc Tran-Gia, Tobias Hossfeld, University of Wuerzburg, DE * Yong Liu, Polytechnic Institute of NYU, US * Victoria Fodor, Gyorgy Dan, KTH, SE For further workshop program details, please see http://www.napa-wine.eu/wo= rkshop/ - Jan =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Jan Seedorf Senior Researcher NEC Europe Ltd., NEC Laboratories Europe, Network Division=A0=A0=A0=A0=A0 Kurfuerstenanlage 36, D-69115 Heidelberg Tel.=A0=A0=A0=A0 +49 (0)6221 4342-221 Fax:=A0=A0=A0=A0 +49 (0)6221 4342-155 e-mail:=A0 jan.seedorf@neclab.eu =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D NEC Europe Limited Registered Office: NEC House, 1 Victoria Road, London W3 6BL Registered in England 2832014=20 From henry.sinnreich@gmail.com Tue Jan 18 09:22:03 2011 Return-Path: X-Original-To: decade@core3.amsl.com Delivered-To: decade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0641D28C21E; Tue, 18 Jan 2011 09:22:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.558 X-Spam-Level: X-Spam-Status: No, score=-2.558 tagged_above=-999 required=5 tests=[AWL=-0.355, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dsrDTm765kcj; Tue, 18 Jan 2011 09:22:01 -0800 (PST) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id 3D00E28C0F1; Tue, 18 Jan 2011 09:22:01 -0800 (PST) Received: by gwj17 with SMTP id 17so2684081gwj.31 for ; Tue, 18 Jan 2011 09:24:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:user-agent:date:subject:from:to:message-id :thread-topic:thread-index:in-reply-to:mime-version:content-type :content-transfer-encoding; bh=tPAeerIR9mRtJIio14cxeZyREDxSaVBRN51soh7VdUw=; b=hKaVMQxtGDm7kDl+0Qvt8OwyEt2h7zqHs0IKvXbK2Xi1oEcsBiSFK4hx1Jc2Ifwrl4 XyBU31SPN3aMn51FO6jTPPDIradZhsYkBkTrQ6jsR6b8RK2KIFv+FWqX0rMlSBA4QH0h T6lqx91JW8Lp1X+vfIdWhrJNo6b6O69cI1D6M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=user-agent:date:subject:from:to:message-id:thread-topic :thread-index:in-reply-to:mime-version:content-type :content-transfer-encoding; b=n1vAXLuWFm310RkOZcNAqbOpp32metpPEOGoAIJLdgacoIJX64FzfpiW8essKyJwfm IqrQk/OcNfER2qfkJxpn6hdmV6m3RYD156CC4/lGu5JPgMF5waq0uvCptwQqX6vKYtuE arQ5YJcIJ9f2pkqT0qyBbiooyHCZS/NzoZpAs= Received: by 10.100.137.3 with SMTP id k3mr955644and.112.1295371477613; Tue, 18 Jan 2011 09:24:37 -0800 (PST) Received: from [10.0.1.5] (cpe-76-184-225-135.tx.res.rr.com [76.184.225.135]) by mx.google.com with ESMTPS id c30sm7224115anc.0.2011.01.18.09.24.26 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 18 Jan 2011 09:24:28 -0800 (PST) User-Agent: Microsoft-Entourage/12.28.0.101117 Date: Tue, 18 Jan 2011 11:24:23 -0600 From: Henry Sinnreich To: Jan Seedorf , "p2prg@irtf.org" , P2PSIP WG , "ppsp@ietf.org" , 'alto' , "decade@ietf.org" Message-ID: Thread-Topic: [decade] Live streaming of NAPA-WINE P2P-TV workshop with P2P software Thread-Index: Acu2+sxB9abvF+YITYupvh0rusVDHQAOcAJn In-Reply-To: <2779C9F0771F974CAD742BAE6D9904FE7E96AF@PALLENE.office.hd> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Subject: Re: [decade] Live streaming of NAPA-WINE P2P-TV workshop with P2P software X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jan 2011 17:22:03 -0000 This spam is highly unwelcome. Also quite surprising, since your spam has already been called out on another list. Thanks, Henry On 1/18/11 4:30 AM, "Jan Seedorf" wrote: > P2P folks at IETF, >=20 > To help people interested in the P2P-TV workshop we are hosting, > the NAPA-WINE project's final workshop will be *broadcasted live* > with the P2P Live Streaming Software developed by the NAPA-WINE project. >=20 > The workshop opens on Thursday 20th January at 2.30PM CET and closes > on Friday 21th January afternoon at 6.00PM CET. > Recordings of the workshop will be made available from the project web si= te > few days after the event too. >=20 > For people interested in following the workshop/talks live > via P2P video stream, we have prepared a page with Quick-Start > instructions on how to download, install, and use the software > to follow the event live. If you are interested, please go to >=20 > http://www.napa-wine.eu/cgi-bin/twiki/view/Public/NapaWineWorkshopLive >=20 > If you have any questions regarding the use of the software or following > the final workshop live with it, please use the mailing list > (napalive@tlc.polito.it). >=20 > A demo activity of the software is scheduled at 5.30PM (and yes! you > will be part of the demo if you join the channel!) >=20 > *Workshop Program* > The final NAPA-WINE workshop is intended as an informal forum for lively > discussions on current and future trends in peer-to-peer live streaming. = The > program comprises four talks presenting the main NAPA-WINE achievements (= and a > demo of NAPA-WINE's network-aware P2P live streaming system) as well as n= ine > talks from external highly qualified researchers from both academia and > industry, providing a broad and articulated perspective on the main chall= enges > and solutions on the topic. There will be external presentations provided= by > (see http://www.napa-wine.eu/workshop/program.html for agenda details): >=20 > - Presentations from other on-going European projects on P2P-TV/CDN: > * Future Media Networks (FMN) cluster and ENVISION (David Griffin, UCL,= GB) > * COAST/SEA (Emanuele Quacchio, ST Microelectronics, IT) > * P2P-NEXT (Raul Jimenez, KTH, SE) > - Presentations from the industrial world (the operator/content provider > vision): > * Nikolaos Laoutaris, Telefonica Research, ES > * Enrico Marocco, Chair of IETF ALTO, Telecom Italia, IT > - Presentations from academia (technical challenges) > * Ernst Biersack, Eurecom, FR > * Phuoc Tran-Gia, Tobias Hossfeld, University of Wuerzburg, DE > * Yong Liu, Polytechnic Institute of NYU, US > * Victoria Fodor, Gyorgy Dan, KTH, SE >=20 > For further workshop program details, please see > http://www.napa-wine.eu/workshop/ >=20 > - Jan >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Jan Seedorf > Senior Researcher > NEC Europe Ltd., NEC Laboratories Europe, Network Division=A0=A0=A0=A0=A0 > Kurfuerstenanlage 36, D-69115 Heidelberg > Tel.=A0=A0=A0=A0 +49 (0)6221 4342-221 > Fax:=A0=A0=A0=A0 +49 (0)6221 4342-155 > e-mail:=A0 jan.seedorf@neclab.eu > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > NEC Europe Limited Registered Office: NEC House, > 1 Victoria Road, London W3 6BL Registered in England 2832014 >=20 >=20 > _______________________________________________ > decade mailing list > decade@ietf.org > https://www.ietf.org/mailman/listinfo/decade From Internet-Drafts@ietf.org Tue Jan 18 11:30:03 2011 Return-Path: X-Original-To: decade@core3.amsl.com Delivered-To: decade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5DC773A7066; Tue, 18 Jan 2011 11:30:03 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Gd2ON4ipyGj; Tue, 18 Jan 2011 11:30:02 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C81C3A7021; Tue, 18 Jan 2011 11:30:02 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.10 Message-ID: <20110118193002.1590.57863.idtracker@localhost> Date: Tue, 18 Jan 2011 11:30:02 -0800 Cc: decade@ietf.org Subject: [decade] I-D Action:draft-ietf-decade-survey-03.txt X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jan 2011 19:30:03 -0000 --NextPart 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 : A Survey of In-network Storage Systems Author(s) : R. Alimi, et al. Filename : draft-ietf-decade-survey-03.txt Pages : 41 Date : 2011-01-18 This document surveys deployed and experimental in-network storage systems and describes their applicability for DECADE. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-decade-survey-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-decade-survey-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-01-18112553.I-D@ietf.org> --NextPart-- From Akbar.Rahman@InterDigital.com Tue Jan 18 11:32:40 2011 Return-Path: X-Original-To: decade@core3.amsl.com Delivered-To: decade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 326C728C108 for ; Tue, 18 Jan 2011 11:32:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.094 X-Spam-Level: X-Spam-Status: No, score=-2.094 tagged_above=-999 required=5 tests=[AWL=0.504, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tz5uOQfJ-0I4 for ; Tue, 18 Jan 2011 11:32:39 -0800 (PST) Received: from idcout.InterDigital.com (idcexmail.interdigital.com [12.32.197.135]) by core3.amsl.com (Postfix) with ESMTP id 98C263A7028 for ; Tue, 18 Jan 2011 11:32:38 -0800 (PST) Received: from SAM.InterDigital.com ([10.30.2.11]) by idcout.InterDigital.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 18 Jan 2011 14:35:16 -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_01CBB746.D4FB8048" Date: Tue, 18 Jan 2011 14:35:15 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [decade] Reviews of the Decade Survey draft Thread-Index: AQHLssWsENEjNAVH50KNU8O5FTTTKpPPBxowgAgfY8A= References: <1CA25301D2219F40B3AA37201F0EACD10675B5@PACDCEXMB05.cable.comcast.com> From: "Rahman, Akbar" To: "Woundy, Richard" X-OriginalArrivalTime: 18 Jan 2011 19:35:16.0099 (UTC) FILETIME=[D5194D30:01CBB746] Cc: decade@ietf.org Subject: Re: [decade] Reviews of the Decade Survey draft X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jan 2011 19:32:40 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBB746.D4FB8048 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgUmljaCwNCg0KIA0KDQogDQoNClRoZSBhdXRob3JzIGhhdmUgc3VibWl0dGVkIGFuIHVwZGF0 ZWQgZHJhZnQgY292ZXJpbmcgdGhlIHJldmlldyBjb21tZW50cyBmcm9tIFRhbyBNYSwgT3ZlIFN0 cmFuZGJlcmcsIFl1bmZlaSBaaGFuZyBhbmQgRGF2aWQgQnJ5YW4uIA0KDQogDQoNCmh0dHA6Ly93 d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWlldGYtZGVjYWRlLXN1cnZleS0wMy50 eHQNCg0KIA0KDQogDQoNClNpbmNlcmVseSwNCg0KIA0KDQogDQoNCkFrYmFyDQoNCiANCg0KIA0K DQpGcm9tOiBkZWNhZGUtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmRlY2FkZS1ib3VuY2VzQGll dGYub3JnXSBPbiBCZWhhbGYgT2YgUmFobWFuLCBBa2Jhcg0KU2VudDogVGh1cnNkYXksIEphbnVh cnkgMTMsIDIwMTEgMTA6MzEgQU0NClRvOiBXb3VuZHksIFJpY2hhcmQNCkNjOiBkZWNhZGVAaWV0 Zi5vcmcNClN1YmplY3Q6IFJlOiBbZGVjYWRlXSBSZXZpZXdzIG9mIHRoZSBEZWNhZGUgU3VydmV5 IGRyYWZ0DQoNCiANCg0KSGkgUmljaCwNCg0KIA0KDQogDQoNClRoZSBhdXRob3JzIGFyZSB3b3Jr aW5nIG9uIHRoZSB1cGRhdGUgdG8gdGhlIFN1cnZleSBiYXNlZCBvbiB0aGUgY29tbWVudHMgZnJv bSBUYW8gTWEsIE92ZSBTdHJhbmRiZXJnLCBZdW5mZWkgWmhhbmcgYW5kIERhdmlkIEJyeWFuLiAg V2UgZXhwZWN0IHRvIHN1Ym1pdCBhbiB1cGRhdGVkIEktRCBzb21ldGltZSBuZXh0IHdlZWsuDQoN CiANCg0KU2luY2VyZWx5LA0KDQogDQoNCkFrYmFyDQoNCiANCg0KRnJvbTogZGVjYWRlLWJvdW5j ZXNAaWV0Zi5vcmcgW21haWx0bzpkZWNhZGUtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9m IFdvdW5keSwgUmljaGFyZA0KU2VudDogV2VkbmVzZGF5LCBKYW51YXJ5IDEyLCAyMDExIDk6MDEg UE0NClRvOiAnYWJjZG1hdGFvQGdtYWlsLmNvbSc7ICdkZWNhZGVAaWV0Zi5vcmcnDQpDYzogJ3po YW5nY2guYnVwdC4wMDFAZ21haWwuY29tJzsgJ3FpdXhpYW9mZW5nQGdtYWlsLmNvbScNClN1Ympl Y3Q6IFJlOiBbZGVjYWRlXSBSZXZpZXdzIG9mIHRoZSBEZWNhZGUgU3VydmV5IGRyYWZ0DQoNCiAN Cg0KVGhhbmtzIGZvciB0aGUgYWRkaXRpb25hbCByZXZpZXchDQoNCi0tIFJpY2gNCg0KIA0KDQpG cm9tOiBUYW8gTWEgW21haWx0bzphYmNkbWF0YW9AZ21haWwuY29tXSANClNlbnQ6IFdlZG5lc2Rh eSwgSmFudWFyeSAxMiwgMjAxMSAwODozNiBQTQ0KVG86IGRlY2FkZUBpZXRmLm9yZyA8ZGVjYWRl QGlldGYub3JnPiANCkNjOiBxaXV4aWFvZmVuZ0BnbWFpbC5jb20gPHFpdXhpYW9mZW5nQGdtYWls LmNvbT47IGNoIHpoYW5nIDx6aGFuZ2NoLmJ1cHQuMDAxQGdtYWlsLmNvbT4gDQpTdWJqZWN0OiBS ZTogW2RlY2FkZV0gUmV2aWV3cyBvZiB0aGUgRGVjYWRlIFN1cnZleSBkcmFmdCANCiANCg0KSGks IGFsbA0KICAgIEknZCBhbHNvIGxpa2UgdG8gYWRkIHNvbWUgcmV2aWV3cyBvbiB0aGUgc3VydmV5 IGRyYWZ0LiBJIHRoaW5rIGl0IGEgdmVyeSBjb21wcmVoZW5zaXZlIHN1cnZleSBvZiBjdXJyZW50 IGluLW5ldHdvcmsgc3RvcmFnZSBzeXN0ZW0uSSBoYXZlIHNvbWUgbWlub3IgY29tbWVudHM6DQog ICAgMSBJbiBzZWN0aW9uIDIuMiAiSGlzdG9yaWNhbCBDb250ZXh0IiwgaXQgbWFpbmx5IG1lbnRp b25lZCB3ZWIgY2FjaGUgYW5kIENETiBhcyB0aGUgaGlzdG9yaWNhbCBwcmVkZWNlc3NvciBvZiBE RUNBREUuIEhvd2V2ZXIsIEkgYmVsaWV2ZSAiUDJQIGNhY2hlIiBzaG91bGQgYmUgbWVudGlvbmVk IGhlcmUgdG9vLCB3aGljaCBpcyBoaWdobGlnaHRlZCBpbiBwcm9ibGVtIHN0YXRlbWVudCBkcmFm dC4NCiAgICAyIEFzIHl1bmZlaSB6aGFuZyBoYXMgbWVudGlvbmVkIGluIGh0dHA6Ly93d3cuaWV0 Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9kZWNhZGUvY3VycmVudC9tc2cwMDM0MC5odG1sLCBJIGFs c28gYWdyZWUgdG8gZW1waGFzaXplIHRoZSBtb2JpbGUgc2NlbmFyaW9zIHdoaWNoIGlzIG5vdCBz dWZmaWNpZW50bHkgZGVzY3JpYmVkIGluIGN1cnJlbnQgc3VydmV5IGRyYWZ0Lg0KICAgIDMgSW4g dGhlIGZpcnN0IGxpbmUgb2Ygc2VjaW9uIDQuMy4xLCAic3lzZW0iIHNob3VsZCBiZSAic3lzdGVt Ig0KICAgIDQgSW4gc2VjdGlvbiA0LjUuNCwgIk5vdCBhcHBsaWNhYmxlIiBzaG91bGQgYmUgIk5v dCBwcm92aWRlZCIgYXMgdGhlIG90aGVyIHN5c3RlbSBkZXNjcmliZWQgZm9yIHVuaWZvcm0gcmVh c29uDQoNClRhbyBNYQ0KQmVpamluZyBVbml2ZXJzaXR5IG9mIFBvc3RzIGFuZCBUZWxlY29tbXVu aWNhdGlvbnMsIE1JTkVsYWINCiAgIA0KDQo= ------_=_NextPart_001_01CBB746.D4FB8048 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOnA9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206 b2ZmaWNlOnBvd2VycG9pbnQiIHhtbG5zOmE9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2Zm aWNlOmFjY2VzcyIgeG1sbnM6ZHQ9InV1aWQ6QzJGNDEwMTAtNjVCMy0xMWQxLUEyOUYtMDBBQTAw QzE0ODgyIiB4bWxuczpzPSJ1dWlkOkJEQzZFM0YwLTZEQTMtMTFkMS1BMkEzLTAwQUEwMEMxNDg4 MiIgeG1sbnM6cnM9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206cm93c2V0IiB4bWxuczp6PSIj Um93c2V0U2NoZW1hIiB4bWxuczpiPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpw dWJsaXNoZXIiIHhtbG5zOnNzPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpzcHJl YWRzaGVldCIgeG1sbnM6Yz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6Y29tcG9u ZW50OnNwcmVhZHNoZWV0IiB4bWxuczpvZGM9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2Zm aWNlOm9kYyIgeG1sbnM6b2E9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOmFjdGl2 YXRpb24iIHhtbG5zOmh0bWw9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1odG1sNDAiIHhtbG5z OnE9Imh0dHA6Ly9zY2hlbWFzLnhtbHNvYXAub3JnL3NvYXAvZW52ZWxvcGUvIiB4bWxuczpydGM9 Imh0dHA6Ly9taWNyb3NvZnQuY29tL29mZmljZW5ldC9jb25mZXJlbmNpbmciIHhtbG5zOkQ9IkRB VjoiIHhtbG5zOlJlcGw9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vcmVwbC8iIHhtbG5z Om10PSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29hcC9tZWV0aW5n cy8iIHhtbG5zOngyPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS9leGNlbC8y MDAzL3htbCIgeG1sbnM6cHBkYT0iaHR0cDovL3d3dy5wYXNzcG9ydC5jb20vTmFtZVNwYWNlLnhz ZCIgeG1sbnM6b2lzPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29h cC9vaXMvIiB4bWxuczpkaXI9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2lu dC9zb2FwL2RpcmVjdG9yeS8iIHhtbG5zOmRzPSJodHRwOi8vd3d3LnczLm9yZy8yMDAwLzA5L3ht bGRzaWcjIiB4bWxuczpkc3A9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2lu dC9kc3AiIHhtbG5zOnVkYz0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9kYXRhL3VkYyIg eG1sbnM6eHNkPSJodHRwOi8vd3d3LnczLm9yZy8yMDAxL1hNTFNjaGVtYSIgeG1sbnM6c3ViPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29hcC8yMDAyLzEvYWxlcnRz LyIgeG1sbnM6ZWM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDEvMDQveG1sZW5jIyIgeG1sbnM6c3A9 Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2ludC8iIHhtbG5zOnNwcz0iaHR0 cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9zaGFyZXBvaW50L3NvYXAvIiB4bWxuczp4c2k9Imh0 dHA6Ly93d3cudzMub3JnLzIwMDEvWE1MU2NoZW1hLWluc3RhbmNlIiB4bWxuczp1ZGNzPSJodHRw Oi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL2RhdGEvdWRjL3NvYXAiIHhtbG5zOnVkY3hmPSJodHRw Oi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL2RhdGEvdWRjL3htbGZpbGUiIHhtbG5zOnVkY3AycD0i aHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9kYXRhL3VkYy9wYXJ0dG9wYXJ0IiB4bWxuczp3 Zj0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9zaGFyZXBvaW50L3NvYXAvd29ya2Zsb3cv IiB4bWxuczpkc3NzPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA2L2Rp Z3NpZy1zZXR1cCIgeG1sbnM6ZHNzaT0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9vZmZp Y2UvMjAwNi9kaWdzaWciIHhtbG5zOm1kc3NpPSJodHRwOi8vc2NoZW1hcy5vcGVueG1sZm9ybWF0 cy5vcmcvcGFja2FnZS8yMDA2L2RpZ2l0YWwtc2lnbmF0dXJlIiB4bWxuczptdmVyPSJodHRwOi8v c2NoZW1hcy5vcGVueG1sZm9ybWF0cy5vcmcvbWFya3VwLWNvbXBhdGliaWxpdHkvMjAwNiIgeG1s bnM6bT0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4 bWxuczptcmVscz0iaHR0cDovL3NjaGVtYXMub3BlbnhtbGZvcm1hdHMub3JnL3BhY2thZ2UvMjAw Ni9yZWxhdGlvbnNoaXBzIiB4bWxuczpzcHdwPSJodHRwOi8vbWljcm9zb2Z0LmNvbS9zaGFyZXBv aW50L3dlYnBhcnRwYWdlcyIgeG1sbnM6ZXgxMnQ9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j b20vZXhjaGFuZ2Uvc2VydmljZXMvMjAwNi90eXBlcyIgeG1sbnM6ZXgxMm09Imh0dHA6Ly9zY2hl bWFzLm1pY3Jvc29mdC5jb20vZXhjaGFuZ2Uvc2VydmljZXMvMjAwNi9tZXNzYWdlcyIgeG1sbnM6 cHB0c2w9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2ludC9zb2FwL1NsaWRl TGlicmFyeS8iIHhtbG5zOnNwc2w9Imh0dHA6Ly9taWNyb3NvZnQuY29tL3dlYnNlcnZpY2VzL1No YXJlUG9pbnRQb3J0YWxTZXJ2ZXIvUHVibGlzaGVkTGlua3NTZXJ2aWNlIiB4bWxuczpaPSJ1cm46 c2NoZW1hcy1taWNyb3NvZnQtY29tOiIgeG1sbnM6c3Q9IiYjMTsiIHhtbG5zPSJodHRwOi8vd3d3 LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PUNvbnRl bnQtVHlwZSBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1ldGEgbmFtZT1H ZW5lcmF0b3IgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0K PHN0eWxlPg0KPCEtLQ0KIC8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCiBAZm9udC1mYWNlDQoJe2Zv bnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZv bnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQg NCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToy IDExIDYgOSAyIDIgNCAzIDIgNDt9DQogLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCiBwLk1zb05v cm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2lu LWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVz IE5ldyBSb21hbiIsInNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQpwLk1zb1BsYWluVGV4dCwgbGkuTXNvUGxhaW5UZXh0LCBkaXYuTXNvUGxhaW5UZXh0DQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiUGxhaW4gVGV4dCBDaGFyIjsN CgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuNXB0 Ow0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzO30NCnAuTXNvQWNldGF0ZSwgbGkuTXNvQWNldGF0ZSwg ZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5r OiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAx cHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlm Ijt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250 LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5F bWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uQmFsbG9v blRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQiOw0KCWZvbnQt ZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLlBsYWluVGV4dENoYXINCgl7bXNv LXN0eWxlLW5hbWU6IlBsYWluIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CW1zby1zdHlsZS1saW5rOiJQbGFpbiBUZXh0IjsNCglmb250LWZhbWlseTpDb25zb2xhczt9DQou TXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6 MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJn aW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldv cmRTZWN0aW9uMTt9DQotLT4NCjwvc3R5bGU+DQo8IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCiA8 bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFb ZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQogPG86c2hhcGVsYXlvdXQgdjpleHQ9 ImVkaXQiPg0KICA8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCiA8L286c2hhcGVs YXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQoNCjxib2R5IGxhbmc9RU4tVVMgbGlu az1ibHVlIHZsaW5rPXB1cnBsZT4NCg0KPGRpdiBjbGFzcz1Xb3JkU2VjdGlvbjE+DQoNCjxwIGNs YXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToi Q2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KY29sb3I6IzFGNDk3RCc+SGkgUmljaCw8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KY29sb3I6IzFGNDk3 RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNl cmlmIjsNCmNvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAg Y2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQpjb2xvcjojMUY0OTdEJz5UaGUgYXV0aG9ycyBoYXZl IHN1Ym1pdHRlZCBhbiB1cGRhdGVkIGRyYWZ0IGNvdmVyaW5nIHRoZSByZXZpZXcgPC9zcGFuPjxz cGFuDQpzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMt c2VyaWYiO2NvbG9yOiMxRjQ5N0QnPmNvbW1lbnRzDQpmcm9tIFRhbyBNYSwgT3ZlIFN0cmFuZGJl cmcsIFl1bmZlaSBaaGFuZyBhbmQgRGF2aWQgQnJ5YW4uJm5ic3A7PG86cD48L286cD48L3NwYW4+ PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCmNvbG9yOiMxRjQ5N0QnPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvUGxhaW5UZXh0PjxhDQpocmVm PSJodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1pZXRmLWRlY2FkZS1z dXJ2ZXktMDMudHh0Ij5odHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1p ZXRmLWRlY2FkZS1zdXJ2ZXktMDMudHh0PC9hPjxvOnA+PC9vOnA+PC9wPg0KDQo8cCBjbGFzcz1N c29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIjsNCmNvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQpjb2xvcjojMUY0OTdEJz48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHls ZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0K Y29sb3I6IzFGNDk3RCc+U2luY2VyZWx5LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xh c3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJD YWxpYnJpIiwic2Fucy1zZXJpZiI7DQpjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KY29sb3I6IzFGNDk3RCc+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4g c3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlm IjsNCmNvbG9yOiMxRjQ5N0QnPkFrYmFyPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFz cz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNh bGlicmkiLCJzYW5zLXNlcmlmIjsNCmNvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQpjb2xvcjojMUY0OTdEJz48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQoNCjxkaXY+DQoNCjxkaXYgc3R5bGU9J2JvcmRl cjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAw aW4gMGluJz4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxiPjxzcGFuIHN0eWxlPSdmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+RnJvbTo8L3NwYW4+PC9i PjxzcGFuDQpzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fu cy1zZXJpZiInPiA8YQ0KaHJlZj0ibWFpbHRvOmRlY2FkZS1ib3VuY2VzQGlldGYub3JnIj5kZWNh ZGUtYm91bmNlc0BpZXRmLm9yZzwvYT4gPGENCmhyZWY9Im1haWx0bzpbbWFpbHRvOmRlY2FkZS1i b3VuY2VzQGlldGYub3JnXSI+W21haWx0bzpkZWNhZGUtYm91bmNlc0BpZXRmLm9yZ108L2E+DQo8 Yj5PbiBCZWhhbGYgT2YgPC9iPlJhaG1hbiwgQWtiYXI8YnI+DQo8Yj5TZW50OjwvYj4gVGh1cnNk YXksIEphbnVhcnkgMTMsIDIwMTEgMTA6MzEgQU08YnI+DQo8Yj5Ubzo8L2I+IFdvdW5keSwgUmlj aGFyZDxicj4NCjxiPkNjOjwvYj4gPGEgaHJlZj0ibWFpbHRvOmRlY2FkZUBpZXRmLm9yZyI+ZGVj YWRlQGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW2RlY2FkZV0gUmV2aWV3 cyBvZiB0aGUgRGVjYWRlIFN1cnZleSBkcmFmdDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPC9k aXY+DQoNCjwvZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+ DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KY29sb3I6IzFGNDk3RCc+SGkgUmljaCw8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0n Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KY29s b3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29O b3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmki LCJzYW5zLXNlcmlmIjsNCmNvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQpjb2xvcjojMUY0OTdEJz5UaGUgYXV0 aG9ycyBhcmUgd29ya2luZyBvbiB0aGUgdXBkYXRlIHRvIHRoZSBTdXJ2ZXkgYmFzZWQgb24gdGhl DQpjb21tZW50cyBmcm9tIFRhbyBNYSwgT3ZlIFN0cmFuZGJlcmcsIFl1bmZlaSBaaGFuZyBhbmQg RGF2aWQgQnJ5YW4uJm5ic3A7IFdlDQpleHBlY3QgdG8gc3VibWl0IGFuIHVwZGF0ZWQgSS1EIHNv bWV0aW1lIG5leHQgd2Vlay48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05v cm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIs InNhbnMtc2VyaWYiOw0KY29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCmNvbG9yOiMxRjQ5N0QnPlNpbmNlcmVs eSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHls ZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0K Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1N c29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIjsNCmNvbG9yOiMxRjQ5N0QnPkFrYmFyPG86cD48L286cD48L3NwYW4+ PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCmNvbG9yOiMxRjQ5N0QnPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCg0KPGRpdj4NCg0KPGRpdiBzdHlsZT0nYm9yZGVyOm5v bmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAw aW4nPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz5Gcm9tOjwvc3Bhbj48L2I+PHNw YW4NCnN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNl cmlmIic+IDxhDQpocmVmPSJtYWlsdG86ZGVjYWRlLWJvdW5jZXNAaWV0Zi5vcmciPmRlY2FkZS1i b3VuY2VzQGlldGYub3JnPC9hPiA8YQ0KaHJlZj0ibWFpbHRvOlttYWlsdG86ZGVjYWRlLWJvdW5j ZXNAaWV0Zi5vcmddIj5bbWFpbHRvOmRlY2FkZS1ib3VuY2VzQGlldGYub3JnXTwvYT4NCjxiPk9u IEJlaGFsZiBPZiA8L2I+V291bmR5LCBSaWNoYXJkPGJyPg0KPGI+U2VudDo8L2I+IFdlZG5lc2Rh eSwgSmFudWFyeSAxMiwgMjAxMSA5OjAxIFBNPGJyPg0KPGI+VG86PC9iPiAnYWJjZG1hdGFvQGdt YWlsLmNvbSc7ICdkZWNhZGVAaWV0Zi5vcmcnPGJyPg0KPGI+Q2M6PC9iPiAnemhhbmdjaC5idXB0 LjAwMUBnbWFpbC5jb20nOyAncWl1eGlhb2ZlbmdAZ21haWwuY29tJzxicj4NCjxiPlN1YmplY3Q6 PC9iPiBSZTogW2RlY2FkZV0gUmV2aWV3cyBvZiB0aGUgRGVjYWRlIFN1cnZleSBkcmFmdDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCg0KPC9kaXY+DQoNCjwvZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3Jt YWw+PG86cD4mbmJzcDs8L286cD48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHls ZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0K Y29sb3I6IzFGNDk3RCc+VGhhbmtzIGZvciB0aGUgYWRkaXRpb25hbCByZXZpZXchPGJyPg0KPGJy Pg0KLS0gUmljaDxicj4NCjwvc3Bhbj48YnI+DQombmJzcDs8bzpwPjwvbzpwPjwvcD4NCg0KPGRp diBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRp bmc6My4wcHQgMGluIDBpbiAwaW4nPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGI+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz5G cm9tPC9zcGFuPjwvYj48c3Bhbg0Kc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 IlRhaG9tYSIsInNhbnMtc2VyaWYiJz46IFRhbyBNYSA8YQ0KaHJlZj0ibWFpbHRvOlttYWlsdG86 YWJjZG1hdGFvQGdtYWlsLmNvbV0iPlttYWlsdG86YWJjZG1hdGFvQGdtYWlsLmNvbV08L2E+IDxi cj4NCjxiPlNlbnQ8L2I+OiBXZWRuZXNkYXksIEphbnVhcnkgMTIsIDIwMTEgMDg6MzYgUE08YnI+ DQo8Yj5UbzwvYj46IDxhIGhyZWY9Im1haWx0bzpkZWNhZGVAaWV0Zi5vcmciPmRlY2FkZUBpZXRm Lm9yZzwvYT4gJmx0OzxhDQpocmVmPSJtYWlsdG86ZGVjYWRlQGlldGYub3JnIj5kZWNhZGVAaWV0 Zi5vcmc8L2E+Jmd0OyA8YnI+DQo8Yj5DYzwvYj46IDxhIGhyZWY9Im1haWx0bzpxaXV4aWFvZmVu Z0BnbWFpbC5jb20iPnFpdXhpYW9mZW5nQGdtYWlsLmNvbTwvYT4NCiZsdDs8YSBocmVmPSJtYWls dG86cWl1eGlhb2ZlbmdAZ21haWwuY29tIj5xaXV4aWFvZmVuZ0BnbWFpbC5jb208L2E+Jmd0Ozsg Y2gNCnpoYW5nICZsdDs8YSBocmVmPSJtYWlsdG86emhhbmdjaC5idXB0LjAwMUBnbWFpbC5jb20i PnpoYW5nY2guYnVwdC4wMDFAZ21haWwuY29tPC9hPiZndDsNCjxicj4NCjxiPlN1YmplY3Q8L2I+ OiBSZTogW2RlY2FkZV0gUmV2aWV3cyBvZiB0aGUgRGVjYWRlIFN1cnZleSBkcmFmdCA8YnI+DQo8 L3NwYW4+Jm5ic3A7PG86cD48L286cD48L3A+DQoNCjwvZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3Jt YWw+SGksIGFsbDxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyBJJ2QgYWxzbyBsaWtlIHRvIGFkZCBz b21lIHJldmlld3Mgb24gdGhlIHN1cnZleSBkcmFmdC4gSQ0KdGhpbmsgaXQgYSB2ZXJ5IGNvbXBy ZWhlbnNpdmUgc3VydmV5IG9mIGN1cnJlbnQgaW4tbmV0d29yayBzdG9yYWdlIHN5c3RlbS5JDQpo YXZlIHNvbWUgbWlub3IgY29tbWVudHM6PGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7IDEgSW4gc2Vj dGlvbiAyLjIgJnF1b3Q7SGlzdG9yaWNhbCBDb250ZXh0JnF1b3Q7LCBpdCBtYWlubHkNCm1lbnRp b25lZCB3ZWIgY2FjaGUgYW5kIENETiBhcyB0aGUgaGlzdG9yaWNhbCBwcmVkZWNlc3NvciBvZiBE RUNBREUuIEhvd2V2ZXIsIEkNCmJlbGlldmUgJnF1b3Q7UDJQIGNhY2hlJnF1b3Q7IHNob3VsZCBi ZSBtZW50aW9uZWQgaGVyZSB0b28sIHdoaWNoIGlzDQpoaWdobGlnaHRlZCBpbiBwcm9ibGVtIHN0 YXRlbWVudCBkcmFmdC48YnI+DQombmJzcDsmbmJzcDsmbmJzcDsgMiBBcyB5dW5mZWkgemhhbmcg aGFzIG1lbnRpb25lZCBpbiA8dT48YQ0KaHJlZj0iaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFy Y2hpdmUvd2ViL2RlY2FkZS9jdXJyZW50L21zZzAwMzQwLmh0bWwiPmh0dHA6Ly93d3cuaWV0Zi5v cmcvbWFpbC1hcmNoaXZlL3dlYi9kZWNhZGUvY3VycmVudC9tc2cwMDM0MC5odG1sPC9hPjwvdT4s DQpJIGFsc28gYWdyZWUgdG8gZW1waGFzaXplIHRoZSBtb2JpbGUgc2NlbmFyaW9zIHdoaWNoIGlz IG5vdCBzdWZmaWNpZW50bHkNCmRlc2NyaWJlZCBpbiBjdXJyZW50IHN1cnZleSBkcmFmdC48YnI+ DQombmJzcDsmbmJzcDsmbmJzcDsgMyBJbiB0aGUgZmlyc3QgbGluZSBvZiBzZWNpb24gNC4zLjEs ICZxdW90O3N5c2VtJnF1b3Q7DQpzaG91bGQgYmUgJnF1b3Q7c3lzdGVtJnF1b3Q7PGJyPg0KJm5i c3A7Jm5ic3A7Jm5ic3A7IDQgSW4gc2VjdGlvbiA0LjUuNCwgJnF1b3Q7Tm90IGFwcGxpY2FibGUm cXVvdDsgc2hvdWxkIGJlDQomcXVvdDtOb3QgcHJvdmlkZWQmcXVvdDsgYXMgdGhlIG90aGVyIHN5 c3RlbSBkZXNjcmliZWQgZm9yIHVuaWZvcm0gcmVhc29uPGJyPg0KPGJyPg0KVGFvIE1hPGJyPg0K QmVpamluZyBVbml2ZXJzaXR5IG9mIFBvc3RzIGFuZCBUZWxlY29tbXVuaWNhdGlvbnMsIE1JTkVs YWI8YnI+DQombmJzcDsmbmJzcDsgPG86cD48L286cD48L3A+DQoNCjwvZGl2Pg0KDQo8L2JvZHk+ DQoNCjwvaHRtbD4NCg== ------_=_NextPart_001_01CBB746.D4FB8048-- From Jan.Seedorf@neclab.eu Wed Jan 19 06:30:24 2011 Return-Path: X-Original-To: decade@core3.amsl.com Delivered-To: decade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C052D3A7146; Wed, 19 Jan 2011 06:30:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.367 X-Spam-Level: X-Spam-Status: No, score=-102.367 tagged_above=-999 required=5 tests=[AWL=0.232, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZovOkvjMYj2v; Wed, 19 Jan 2011 06:30:23 -0800 (PST) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 39EC53A7145; Wed, 19 Jan 2011 06:30:23 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 3DA712C000349; Wed, 19 Jan 2011 15:33:23 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office.hd) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qC4v+gEIa0XP; Wed, 19 Jan 2011 15:33:23 +0100 (CET) Received: from ENCELADUS.office.hd (ENCELADUS.office.hd [192.168.24.52]) by smtp0.neclab.eu (Postfix) with ESMTP id 1EFA22C0001AF; Wed, 19 Jan 2011 15:32:53 +0100 (CET) Received: from PALLENE.office.hd ([169.254.1.59]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0270.001; Wed, 19 Jan 2011 15:32:32 +0100 From: Jan Seedorf To: Henry Sinnreich , "p2prg@irtf.org" , P2PSIP WG , "ppsp@ietf.org" , 'alto' , "decade@ietf.org" Thread-Topic: [decade] Live streaming of NAPA-WINE P2P-TV workshop with P2P software Thread-Index: Acu2+sxB9abvF+YITYupvh0rusVDHQAOcAJnACv7d1A= Date: Wed, 19 Jan 2011 14:32:31 +0000 Message-ID: <2779C9F0771F974CAD742BAE6D9904FE7E9ECC@PALLENE.office.hd> References: <2779C9F0771F974CAD742BAE6D9904FE7E96AF@PALLENE.office.hd> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.7.0.199] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [decade] Live streaming of NAPA-WINE P2P-TV workshop with P2P software X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jan 2011 14:30:24 -0000 Dear Henry, all, I apologize for abusing the mailing lists. Many IETF people had told me individually that they are highly interested i= n our workshop but cannot attend in person. I had received many emails with= questions on how to access workshop material after the event. Thus, I thou= ght it is of interest to this community that we are streaming the workshop = live with P2P software and everybody can join the P2P swarm to watch the ta= lks. Sorry if my mail was perceived as spam, - Jan > -----Original Message----- > From: Henry Sinnreich [mailto:henry.sinnreich@gmail.com] > Sent: Dienstag, 18. Januar 2011 18:24 > To: Jan Seedorf; p2prg@irtf.org; P2PSIP WG; ppsp@ietf.org; 'alto'; > decade@ietf.org > Subject: Re: [decade] Live streaming of NAPA-WINE P2P-TV workshop with P2= P > software >=20 > This spam is highly unwelcome. > Also quite surprising, since your spam has already been called out on > another list. >=20 > Thanks, Henry >=20 >=20 > On 1/18/11 4:30 AM, "Jan Seedorf" wrote: >=20 > > P2P folks at IETF, > > > > To help people interested in the P2P-TV workshop we are hosting, > > the NAPA-WINE project's final workshop will be *broadcasted live* > > with the P2P Live Streaming Software developed by the NAPA-WINE project= . > > > > The workshop opens on Thursday 20th January at 2.30PM CET and closes > > on Friday 21th January afternoon at 6.00PM CET. > > Recordings of the workshop will be made available from the project web = site > > few days after the event too. > > > > For people interested in following the workshop/talks live > > via P2P video stream, we have prepared a page with Quick-Start > > instructions on how to download, install, and use the software > > to follow the event live. If you are interested, please go to > > > > http://www.napa-wine.eu/cgi-bin/twiki/view/Public/NapaWineWorkshopLive > > > > If you have any questions regarding the use of the software or followin= g > > the final workshop live with it, please use the mailing list > > (napalive@tlc.polito.it). > > > > A demo activity of the software is scheduled at 5.30PM (and yes! you > > will be part of the demo if you join the channel!) > > > > *Workshop Program* > > The final NAPA-WINE workshop is intended as an informal forum for livel= y > > discussions on current and future trends in peer-to-peer live streaming= . The > > program comprises four talks presenting the main NAPA-WINE achievements= (and > a > > demo of NAPA-WINE's network-aware P2P live streaming system) as well as= nine > > talks from external highly qualified researchers from both academia and > > industry, providing a broad and articulated perspective on the main > challenges > > and solutions on the topic. There will be external presentations provid= ed by > > (see http://www.napa-wine.eu/workshop/program.html for agenda details): > > > > - Presentations from other on-going European projects on P2P-TV/CDN: > > * Future Media Networks (FMN) cluster and ENVISION (David Griffin, UC= L, > GB) > > * COAST/SEA (Emanuele Quacchio, ST Microelectronics, IT) > > * P2P-NEXT (Raul Jimenez, KTH, SE) > > - Presentations from the industrial world (the operator/content provide= r > > vision): > > * Nikolaos Laoutaris, Telefonica Research, ES > > * Enrico Marocco, Chair of IETF ALTO, Telecom Italia, IT > > - Presentations from academia (technical challenges) > > * Ernst Biersack, Eurecom, FR > > * Phuoc Tran-Gia, Tobias Hossfeld, University of Wuerzburg, DE > > * Yong Liu, Polytechnic Institute of NYU, US > > * Victoria Fodor, Gyorgy Dan, KTH, SE > > > > For further workshop program details, please see > > http://www.napa-wine.eu/workshop/ > > > > - Jan > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > Jan Seedorf > > Senior Researcher > > NEC Europe Ltd., NEC Laboratories Europe, Network Division > > Kurfuerstenanlage 36, D-69115 Heidelberg > > Tel.=A0=A0=A0=A0 +49 (0)6221 4342-221 > > Fax:=A0=A0=A0=A0 +49 (0)6221 4342-155 > > e-mail:=A0 jan.seedorf@neclab.eu > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > NEC Europe Limited Registered Office: NEC House, > > 1 Victoria Road, London W3 6BL Registered in England 2832014 > > > > > > _______________________________________________ > > decade mailing list > > decade@ietf.org > > https://www.ietf.org/mailman/listinfo/decade >=20 From Internet-Drafts@ietf.org Fri Jan 21 23:15:03 2011 Return-Path: X-Original-To: decade@core3.amsl.com Delivered-To: decade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 100963A68B1; Fri, 21 Jan 2011 23:15:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.343 X-Spam-Level: X-Spam-Status: No, score=-102.343 tagged_above=-999 required=5 tests=[AWL=0.256, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uL51qvaV1jPQ; Fri, 21 Jan 2011 23:15:01 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EBC753A6864; Fri, 21 Jan 2011 23:15:01 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.10 Message-ID: <20110122071501.8565.97682.idtracker@localhost> Date: Fri, 21 Jan 2011 23:15:01 -0800 Cc: decade@ietf.org Subject: [decade] I-D Action:draft-ietf-decade-problem-statement-02.txt X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Jan 2011 07:15:03 -0000 --NextPart 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 : DECoupled Application Data Enroute (DECADE) Problem Statement Author(s) : H. Song, et al. Filename : draft-ietf-decade-problem-statement-02.txt Pages : 18 Date : 2011-01-21 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 total amount of P2P traffic is to introduce storage capabilities within the network. Traditional caches (e.g., P2P and Web caches) provide such storage, but they are complex (due to explicitly supporting individual P2P application protocols) and they do not allow users to manage access to content in the cache. For example, Content Providers cannot easily control access and resource usage policies to satisfy their own requirements. This document discusses the introduction of in-network storage for P2P applications, shows the need for a standard protocol for accessing this storage, and identifies the scope of this protocol. The accessing protocol can also be used by other applications with similar requirements. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-decade-problem-statement-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-decade-problem-statement-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-01-21230805.I-D@ietf.org> --NextPart-- From richard_woundy@cable.comcast.com Fri Jan 28 06:23:13 2011 Return-Path: X-Original-To: decade@core3.amsl.com Delivered-To: decade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B52C23A689D for ; Fri, 28 Jan 2011 06:23:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.656 X-Spam-Level: X-Spam-Status: No, score=-103.656 tagged_above=-999 required=5 tests=[AWL=-1.922, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qg4HRYjhOJ1n for ; Fri, 28 Jan 2011 06:23:13 -0800 (PST) Received: from cable.comcast.com (copdcimo01.potomac.co.ndcwest.comcast.net [76.96.32.251]) by core3.amsl.com (Postfix) with ESMTP id C9AAB3A689B for ; Fri, 28 Jan 2011 06:23:12 -0800 (PST) Received: from ([24.40.55.42]) by copdcimo01.cable.comcast.com with ESMTP with TLS id 5503630.23741268; Fri, 28 Jan 2011 07:37:05 -0700 Received: from PACDCEXMB05.cable.comcast.com ([fe80::a5b0:e5c4:df1b:2367]) by PACDCEXHUB01.cable.comcast.com ([fe80::d1e7:20b5:9b63:21a6%12]) with mapi id 14.01.0270.001; Fri, 28 Jan 2011 09:26:13 -0500 From: "Woundy, Richard" To: "decade@ietf.org" Thread-Topic: Start of WGLC for draft-ietf-decade-problem-statement-02 Thread-Index: Acu+91Byr8CuZlwMSYaaxFnqkg41Dw== Date: Fri, 28 Jan 2011 14:26:12 +0000 Message-ID: <1CA25301D2219F40B3AA37201F0EACD113400ECC@PACDCEXMB05.cable.comcast.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [76.96.111.6] Content-Type: multipart/alternative; boundary="_000_1CA25301D2219F40B3AA37201F0EACD113400ECCPACDCEXMB05cabl_" MIME-Version: 1.0 Subject: [decade] Start of WGLC for draft-ietf-decade-problem-statement-02 X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jan 2011 14:23:13 -0000 --_000_1CA25301D2219F40B3AA37201F0EACD113400ECCPACDCEXMB05cabl_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Folks, Haibin and I are starting the working group last call for draft-ietf-decade= -problem-statement-02, http://datatracker.ietf.org/doc/draft-ietf-decade-pr= oblem-statement/, to be completed by Monday February 14. Please send all co= ncerns, suggestions and comments about this internet-draft to the DECADE ma= iling list, decade@ietf.org. Authors, please do not make any additional changes to the internet-draft un= less directed by the WG chairs. Draft reviewers, it would be helpful to get your confirmation that your pre= vious review comments have been correctly reflected in this version. Thanks. -- Rich and Haibin --_000_1CA25301D2219F40B3AA37201F0EACD113400ECCPACDCEXMB05cabl_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Folks,

 

Haibin and I are starting the working group last cal= l for draft-ietf-decade-problem-statement-02, http://datatracker.ietf.org/doc/draft-ietf-decade-problem-statement/<= /a>, to be completed by Monday February 14. Please send all concerns, sugge= stions and comments about this internet-draft to the DECADE mailing list, decade@ietf= .org.

 

Authors, please do not make any additional changes t= o the internet-draft unless directed by the WG chairs.

 

Draft reviewers, it would be helpful to get your con= firmation that your previous review comments have been correctly reflected = in this version.

 

Thanks.

 

-- Rich and Haibin

--_000_1CA25301D2219F40B3AA37201F0EACD113400ECCPACDCEXMB05cabl_-- From richard_woundy@cable.comcast.com Fri Jan 28 06:35:07 2011 Return-Path: X-Original-To: decade@core3.amsl.com Delivered-To: decade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD3253A686A for ; Fri, 28 Jan 2011 06:35:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.569 X-Spam-Level: X-Spam-Status: No, score=-102.569 tagged_above=-999 required=5 tests=[AWL=-2.836, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001, SARE_HEXOCTDWORD=2, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j9uDJjP+qDho for ; Fri, 28 Jan 2011 06:34:57 -0800 (PST) Received: from cable.comcast.com (copdcimo01.potomac.co.ndcwest.comcast.net [76.96.32.251]) by core3.amsl.com (Postfix) with ESMTP id C70123A67B3 for ; Fri, 28 Jan 2011 06:34:56 -0800 (PST) Received: from ([24.40.55.40]) by copdcimo01.cable.comcast.com with ESMTP with TLS id 5503630.23743259; Fri, 28 Jan 2011 07:48:21 -0700 Received: from PACDCEXMB05.cable.comcast.com ([fe80::a5b0:e5c4:df1b:2367]) by pacdcexhub03.cable.comcast.com ([fe80::d1dd:b302:b617:3755%12]) with mapi id 14.01.0270.001; Fri, 28 Jan 2011 09:37:42 -0500 From: "Woundy, Richard" To: "decade@ietf.org" Thread-Topic: Start of WGLC for draft-ietf-decade-survey-03 Thread-Index: Acu+95/VNNTNV6GpSgeYCeTmt9YMAgAACFcQ Date: Fri, 28 Jan 2011 14:37:41 +0000 Message-ID: <1CA25301D2219F40B3AA37201F0EACD113400EFA@PACDCEXMB05.cable.comcast.com> References: <1CA25301D2219F40B3AA37201F0EACD113400EE3@PACDCEXMB05.cable.comcast.com> In-Reply-To: <1CA25301D2219F40B3AA37201F0EACD113400EE3@PACDCEXMB05.cable.comcast.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [76.96.111.6] Content-Type: multipart/alternative; boundary="_000_1CA25301D2219F40B3AA37201F0EACD113400EFAPACDCEXMB05cabl_" MIME-Version: 1.0 Subject: Re: [decade] Start of WGLC for draft-ietf-decade-survey-03 X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jan 2011 14:35:07 -0000 --_000_1CA25301D2219F40B3AA37201F0EACD113400EFAPACDCEXMB05cabl_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Below are my personal comments on the DECADE Survey draft. Please do not ma= ke any changes to the draft at this time; I would like the authors to incor= porate these comments after WGLC. Should the name of section 4.4 be "Content Delivery Network" instead of "CD= N"? The other sections in this part of the draft use full names in the sect= ion titles. Section 4.7 (Network of Information) uses the URL http://123.345.678.90/inf= ormaionobject.txt. First, '123.345.678.90' doesn't look like a legitimate I= P address; is it supposed to be? If so, could a better IP address be found?= If you don't need an IP address here, you might want to consider using a R= FC2606-compliant FQDN instead. Also, should the resource be called 'informa= tionobject.txt' (with a 't')? Mispelled words identified from the Idspell Tool, http://tools.ietf.org/too= ls/idspell/webservice. Section 4. s/architecutres/architectures Section 4.1.1. s/hierarchichal/hierarchical Section 4.4.1. s/existance/e= xistence Section 4.6.1. s/sysem/system Section 4.8.1. s/sysem/system Section 4.8.5. s/nework/network Section 4.9.1. s/sysem/system Section 4.9.5. s/avaialable= /available Section 4.10. s/mulitmedia/= multimedia Section 4.11.1. s/existance/= existence Section 4.13.1. s/existance/= existence Section 4.14. s/primitves/pr= imitives Section 5.5.4. s/beyon/beyond Section 5.6. s/classicaly/c= lassically, s/capabilites/= capabilities Section 6. s/desgined/designe= d >From idnits, http://tools.ietf.org/tools/idnits/ idnits 2.12.05 tmp/draft-ietf-decade-survey-03.txt: tmp/draft-ietf-decade-survey-03.txt(294): Found possible FQDN 'www.wikipedi= a.org' in position 27; this doesn't match RFC 2606's suggested ".example" o= r ".example.(com|org|net)". [Rich - this might be OK as the particular website is the example. But it m= ight make more sense to refer to Wikipedia as a service, instead of www.wik= ipedia.org as a website.] Checking boilerplate required by RFC 5378 and the IETF Trust (see http://trustee.ietf.org/license-info): -------------------------------------------------------------------------= --- No issues found here. Checking nits according to http://www.ietf.org/id-info/1id-guidelines.txt= : -------------------------------------------------------------------------= --- No issues found here. Checking nits according to http://www.ietf.org/id-info/checklist : -------------------------------------------------------------------------= --- =3D=3D There are 1 instance of lines with non-RFC2606-compliant FQDNs in = the document. Miscellaneous warnings: -------------------------------------------------------------------------= --- -- The document date (January 18, 2011) is 6 days in the past. Is this intentional? [Rich - ignore this.] Checking references for intended status: Informational -------------------------------------------------------------------------= --- =3D=3D Outdated reference: A later version (-02) exists of draft-ietf-decade-problem-statement-01 [Rich - please fix this. Since the problem statement is also going through = WGLC, let's coordinate this change. It may make sense to change to version = -03.] Summary: 0 errors (**), 2 warnings (=3D=3D), 1 comment (--). ---------------------------------------------------------------------------= ----- -- Rich From: Woundy, Richard Sent: Friday, January 28, 2011 9:28 AM To: decade@ietf.org Cc: Songhaibin; Woundy, Richard Subject: Start of WGLC for draft-ietf-decade-survey-03 Folks, Haibin and I are starting the working group last call for draft-ietf-decade= -survey-03, http://datatracker.ietf.org/doc/draft-ietf-decade-survey/, to b= e completed by Monday February 14. Please send all concerns, suggestions an= d comments about this internet-draft to the DECADE mailing list, decade@iet= f.org. Authors, please do not make any additional changes to the internet-draft un= less directed by the WG chairs. Draft reviewers, it would be helpful to get your confirmation that your pre= vious review comments have been correctly reflected in this version. Thanks. -- Rich and Haibin --_000_1CA25301D2219F40B3AA37201F0EACD113400EFAPACDCEXMB05cabl_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Below are my personal = comments on the DECADE Survey draft. Please do not make any changes to the = draft at this time; I would like the authors to incorporate these comments = after WGLC.

 

Should the name of sec= tion 4.4 be “Content Delivery Network” instead of “CDN= 221;? The other sections in this part of the draft use full names in the se= ction titles.

 

Section 4.7 (Network o= f Information) uses the URL http://123.345.678.9= 0/informaionobject.txt. First, ‘123.345.678.90’ doesn’= ;t look like a legitimate IP address; is it supposed to be? If so, could a = better IP address be found? If you don’t need an IP address here, you might want to consider using a RFC2606-compliant FQDN in= stead. Also, should the resource be called ‘informationobject.txtR= 17; (with a ‘t’)?

 

Mispelled words identi= fied from the Idspell Tool, http://tools.iet= f.org/tools/idspell/webservice.

 

Section 4. s/architecutres/architectures

Section 4.1.1. s/hierarchichal/hierarchica= l

Section 4.4.1. s/exista= nce/existence

Section 4.6.1. s/sysem/system

Section 4.8.1. s/sysem/system

Section 4.8.5. s/nework/netwo= rk

Section 4.9.1. s/sysem/system

Section 4.9.5. s/avaial= able/available

Section 4.10. s/mulitmed= ia/multimedia

Section 4.11.1. s/exista= nce/existence

Section 4.13.1. s/exista= nce/existence

Section 4.14. s/primitves<= /a>/primitives

Section 5.5.4. s/beyon/beyond

Section 5.6. s/classicaly/classically, s/capabilites/capabiliti= es

Section 6. s/desgined/designed

 

From idnits, http://tools.ietf.org/tools/idnits/

 

idnits 2.12.05

 

tmp/draft-ietf-decade-= survey-03.txt:

tmp/draft-ietf-decade-= survey-03.txt(294): Found possible FQDN 'www.wikipedia.org' in position 27;= this doesn't match RFC 2606's suggested ".example" or ".exa= mple.(com|org|net)".

 

[Rich – this mig= ht be OK as the particular website is the example. But it might make more s= ense to refer to Wikipedia as a service, instead of www.wikipedia.org as a website.]

 

  Checking boiler= plate required by RFC 5378 and the IETF Trust (see

  http://trustee.ietf.org/license-info):

  ---------------= -------------------------------------------------------------

 

   &nbs= p; No issues found here.

 

  Checking nits a= ccording to http://www.ietf.org/id-info/1id-guidelines.txt:

  ---------------= -------------------------------------------------------------

 

   &nbs= p; No issues found here.

 

  Checking nits a= ccording to http://www.ietf.org/id-info/checklist :

  ---------------= -------------------------------------------------------------

 

  =3D=3D There ar= e 1 instance of lines with non-RFC2606-compliant FQDNs in the

   &nbs= p; document.

 

 

  Miscellaneous w= arnings:

  ---------------= -------------------------------------------------------------

 

  -- The document= date (January 18, 2011) is 6 days in the past.  Is this

   &nbs= p; intentional?

 

[Rich – ignore t= his.]

 

  Checking refere= nces for intended status: Informational

  ---------------= -------------------------------------------------------------

 

  =3D=3D Outdated= reference: A later version (-02) exists of

   &nbs= p; draft-ietf-decade-problem-statement-01

 

[Rich – please f= ix this. Since the problem statement is also going through WGLC, let’= s coordinate this change. It may make sense to change to version -03.]=

 

   &nbs= p; Summary: 0 errors (**), 2 warnings (=3D=3D), 1 comment (--).<= /span>

----------------------= ----------------------------------------------------------

 

-- Rich

 

From: Woundy, = Richard
Sent: Friday, January 28, 2011 9:28 AM
To: decade@ietf.org
Cc: Songhaibin; Woundy, Richard
Subject: Start of WGLC for draft-ietf-decade-survey-03

 

Folks,

 

Haibin and I are starting the working group last cal= l for draft-ietf-decade-survey-03, http:= //datatracker.ietf.org/doc/draft-ietf-decade-survey/, to be completed b= y Monday February 14. Please send all concerns, suggestions and comments ab= out this internet-draft to the DECADE mailing list, decade@ietf.org.=

 

Authors, please do not make any additional changes t= o the internet-draft unless directed by the WG chairs.

 

Draft reviewers, it would be helpful to get your con= firmation that your previous review comments have been correctly reflected = in this version.

 

Thanks.

 

-- Rich and Haibin

--_000_1CA25301D2219F40B3AA37201F0EACD113400EFAPACDCEXMB05cabl_-- From richard_woundy@cable.comcast.com Fri Jan 28 06:38:35 2011 Return-Path: X-Original-To: decade@core3.amsl.com Delivered-To: decade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F9463A6872 for ; Fri, 28 Jan 2011 06:38:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.81 X-Spam-Level: X-Spam-Status: No, score=-106.81 tagged_above=-999 required=5 tests=[AWL=1.652, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n0CRtzEmPkp1 for ; Fri, 28 Jan 2011 06:38:34 -0800 (PST) Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by core3.amsl.com (Postfix) with ESMTP id BA3AD3A686A for ; Fri, 28 Jan 2011 06:38:33 -0800 (PST) Received: from ([24.40.55.42]) by pacdcimo01.cable.comcast.com with ESMTP with TLS id 5503620.112074711; Fri, 28 Jan 2011 09:41:32 -0500 Received: from PACDCEXMB05.cable.comcast.com ([fe80::a5b0:e5c4:df1b:2367]) by PACDCEXHUB01.cable.comcast.com ([fe80::d1e7:20b5:9b63:21a6%12]) with mapi id 14.01.0270.001; Fri, 28 Jan 2011 09:41:32 -0500 From: "Woundy, Richard" To: "decade@ietf.org" Thread-Topic: Start of WGLC for draft-ietf-decade-problem-statement-02 Thread-Index: Acu+91Byr8CuZlwMSYaaxFnqkg41DwAAarbg Date: Fri, 28 Jan 2011 14:41:31 +0000 Message-ID: <1CA25301D2219F40B3AA37201F0EACD113400F18@PACDCEXMB05.cable.comcast.com> References: <1CA25301D2219F40B3AA37201F0EACD113400ECC@PACDCEXMB05.cable.comcast.com> In-Reply-To: <1CA25301D2219F40B3AA37201F0EACD113400ECC@PACDCEXMB05.cable.comcast.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [76.96.111.6] Content-Type: multipart/alternative; boundary="_000_1CA25301D2219F40B3AA37201F0EACD113400F18PACDCEXMB05cabl_" MIME-Version: 1.0 Subject: Re: [decade] Start of WGLC for draft-ietf-decade-problem-statement-02 X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jan 2011 14:38:35 -0000 --_000_1CA25301D2219F40B3AA37201F0EACD113400F18PACDCEXMB05cabl_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Below are my personal comments on the DECADE Problem Statement draft. Pleas= e do not make any changes to the draft at this time; I would like the autho= rs to incorporate these comments after WGLC. Misspelled words identified from the Idspell Tool, http://tools.ietf.org/to= ols/idspell/webservice. Section 3. s/acess/access, s/cha= nllenge/challenge Section 5.4.2. s/Firgure/Figur= e Appendix A. s/hetergeneous/heterogeneous >From idnits, http://tools.ietf.org/tools/idnits/ idnits 2.12.05 tmp/draft-ietf-decade-problem-statement-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see http://trustee.ietf.org/license-info): -------------------------------------------------------------------------= --- No issues found here. Checking nits according to http://www.ietf.org/id-info/1id-guidelines.txt= : -------------------------------------------------------------------------= --- No issues found here. Checking nits according to http://www.ietf.org/id-info/checklist : -------------------------------------------------------------------------= --- No issues found here. Miscellaneous warnings: -------------------------------------------------------------------------= --- No issues found here. Checking references for intended status: Proposed Standard -------------------------------------------------------------------------= --- (See RFCs 3967 and 4897 for information about using normative referenc= es to lower-maturity documents in RFCs) No issues found here. No nits found. ---------------------------------------------------------------------------= ----- -- Rich From: Woundy, Richard Sent: Friday, January 28, 2011 9:26 AM To: decade@ietf.org Cc: Songhaibin; Woundy, Richard Subject: Start of WGLC for draft-ietf-decade-problem-statement-02 Folks, Haibin and I are starting the working group last call for draft-ietf-decade= -problem-statement-02, http://datatracker.ietf.org/doc/draft-ietf-decade-pr= oblem-statement/, to be completed by Monday February 14. Please send all co= ncerns, suggestions and comments about this internet-draft to the DECADE ma= iling list, decade@ietf.org. Authors, please do not make any additional changes to the internet-draft un= less directed by the WG chairs. Draft reviewers, it would be helpful to get your confirmation that your pre= vious review comments have been correctly reflected in this version. Thanks. -- Rich and Haibin --_000_1CA25301D2219F40B3AA37201F0EACD113400F18PACDCEXMB05cabl_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Below are my personal = comments on the DECADE Problem Statement draft. Please do not make any chan= ges to the draft at this time; I would like the authors to incorporate thes= e comments after WGLC.

 

Misspelled words ident= ified from the Idspell Tool, http://tools.iet= f.org/tools/idspell/webservice.

 

Section 3. s/acess/access, s/chanllenge/challenge

Section 5.4.2. s/Firgure/Figure<= o:p>

Appendix A. s/hetergeneous/heterogeneous

 

From idnits, http://tools.ietf.org/tools/idnits/

 

idnits 2.12.05

 

tmp/draft-ietf-decade-= problem-statement-02.txt:

 

  Checking boiler= plate required by RFC 5378 and the IETF Trust (see

  http://trustee.ietf.org/license-info):

  ---------------= -------------------------------------------------------------

 

   &nbs= p; No issues found here.

 

  Checking nits a= ccording to http://www.ietf.org/id-info/1id-guidelines.txt:

  ---------------= -------------------------------------------------------------

 

   &nbs= p; No issues found here.

 

  Checking nits a= ccording to http://www.ietf.org/id-info/checklist :

  ---------------= -------------------------------------------------------------

 

   &nbs= p; No issues found here.

 

  Miscellaneous w= arnings:

  ---------------= -------------------------------------------------------------

 

   &nbs= p; No issues found here.

 

  Checking refere= nces for intended status: Proposed Standard

  ---------------= -------------------------------------------------------------

 

   &nbs= p; (See RFCs 3967 and 4897 for information about using normative references=

   &nbs= p; to lower-maturity documents in RFCs)

 

   &nbs= p; No issues found here.

 

   &nbs= p; No nits found.

----------------------= ----------------------------------------------------------

 

-- Rich

 

From: Woundy, = Richard
Sent: Friday, January 28, 2011 9:26 AM
To: decade@ietf.org
Cc: Songhaibin; Woundy, Richard
Subject: Start of WGLC for draft-ietf-decade-problem-statement-02

 

Folks,

 

Haibin and I are starting the working group last cal= l for draft-ietf-decade-problem-statement-02, http://datatracker.ietf.org/doc/draft-ietf-decade-problem-statement/<= /a>, to be completed by Monday February 14. Please send all concerns, sugge= stions and comments about this internet-draft to the DECADE mailing list, decade@ietf= .org.

 

Authors, please do not make any additional changes t= o the internet-draft unless directed by the WG chairs.

 

Draft reviewers, it would be helpful to get your con= firmation that your previous review comments have been correctly reflected = in this version.

 

Thanks.

 

-- Rich and Haibin

--_000_1CA25301D2219F40B3AA37201F0EACD113400F18PACDCEXMB05cabl_-- From richard_woundy@cable.comcast.com Fri Jan 28 06:58:45 2011 Return-Path: X-Original-To: decade@core3.amsl.com Delivered-To: decade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 102E63A688F for ; Fri, 28 Jan 2011 06:58:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.879 X-Spam-Level: X-Spam-Status: No, score=-106.879 tagged_above=-999 required=5 tests=[AWL=1.583, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9whIcDopN1q6 for ; Fri, 28 Jan 2011 06:58:44 -0800 (PST) Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by core3.amsl.com (Postfix) with ESMTP id D50423A6407 for ; Fri, 28 Jan 2011 06:58:43 -0800 (PST) Received: from ([24.40.55.42]) by pacdcimo01.cable.comcast.com with ESMTP with TLS id 5503620.112073420; Fri, 28 Jan 2011 09:28:32 -0500 Received: from PACDCEXMB05.cable.comcast.com ([fe80::a5b0:e5c4:df1b:2367]) by PACDCEXHUB01.cable.comcast.com ([fe80::d1e7:20b5:9b63:21a6%12]) with mapi id 14.01.0270.001; Fri, 28 Jan 2011 09:28:25 -0500 From: "Woundy, Richard" To: "decade@ietf.org" Thread-Topic: Start of WGLC for draft-ietf-decade-survey-03 Thread-Index: Acu+95/VNNTNV6GpSgeYCeTmt9YMAg== Date: Fri, 28 Jan 2011 14:28:24 +0000 Message-ID: <1CA25301D2219F40B3AA37201F0EACD113400EE3@PACDCEXMB05.cable.comcast.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [76.96.111.6] Content-Type: multipart/alternative; boundary="_000_1CA25301D2219F40B3AA37201F0EACD113400EE3PACDCEXMB05cabl_" MIME-Version: 1.0 Subject: [decade] Start of WGLC for draft-ietf-decade-survey-03 X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jan 2011 14:58:45 -0000 --_000_1CA25301D2219F40B3AA37201F0EACD113400EE3PACDCEXMB05cabl_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Folks, Haibin and I are starting the working group last call for draft-ietf-decade= -survey-03, http://datatracker.ietf.org/doc/draft-ietf-decade-survey/, to b= e completed by Monday February 14. Please send all concerns, suggestions an= d comments about this internet-draft to the DECADE mailing list, decade@iet= f.org. Authors, please do not make any additional changes to the internet-draft un= less directed by the WG chairs. Draft reviewers, it would be helpful to get your confirmation that your pre= vious review comments have been correctly reflected in this version. Thanks. -- Rich and Haibin --_000_1CA25301D2219F40B3AA37201F0EACD113400EE3PACDCEXMB05cabl_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Folks,

 

Haibin and I are starting the working group last cal= l for draft-ietf-decade-survey-03, http:= //datatracker.ietf.org/doc/draft-ietf-decade-survey/, to be completed b= y Monday February 14. Please send all concerns, suggestions and comments ab= out this internet-draft to the DECADE mailing list, decade@ietf.org.=

 

Authors, please do not make any additional changes t= o the internet-draft unless directed by the WG chairs.

 

Draft reviewers, it would be helpful to get your con= firmation that your previous review comments have been correctly reflected = in this version.

 

Thanks.

 

-- Rich and Haibin

--_000_1CA25301D2219F40B3AA37201F0EACD113400EE3PACDCEXMB05cabl_-- From ben@niven-jenkins.co.uk Fri Jan 28 07:56:54 2011 Return-Path: X-Original-To: decade@core3.amsl.com Delivered-To: decade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C222D3A67A8 for ; Fri, 28 Jan 2011 07:56:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.539 X-Spam-Level: X-Spam-Status: No, score=-103.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WV5+1wyuAOsC for ; Fri, 28 Jan 2011 07:56:54 -0800 (PST) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.61]) by core3.amsl.com (Postfix) with ESMTP id CEBB13A6872 for ; Fri, 28 Jan 2011 07:56:53 -0800 (PST) Received: from host1.cachelogic.com ([212.44.43.80] helo=dhcp-113-devlan.cachelogic.com) by mail11.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from ) id 1Piqjv-0000wr-OL; Fri, 28 Jan 2011 15:59:59 +0000 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=windows-1252 From: Ben Niven-Jenkins In-Reply-To: <1CA25301D2219F40B3AA37201F0EACD113400EFA@PACDCEXMB05.cable.comcast.com> Date: Fri, 28 Jan 2011 15:59:59 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <786107B4-FD98-4A1C-964D-147B417201D9@niven-jenkins.co.uk> References: <1CA25301D2219F40B3AA37201F0EACD113400EE3@PACDCEXMB05.cable.comcast.com> <1CA25301D2219F40B3AA37201F0EACD113400EFA@PACDCEXMB05.cable.comcast.com> To: "Woundy, Richard" X-Mailer: Apple Mail (2.1082) X-Mailcore-Auth: 9600544 X-Mailcore-Domain: 172912 Cc: "decade@ietf.org" Subject: Re: [decade] Start of WGLC for draft-ietf-decade-survey-03 X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jan 2011 15:56:54 -0000 On 28 Jan 2011, at 14:37, Woundy, Richard wrote: > Section 4.7 (Network of Information) uses the = URLhttp://123.345.678.90/informaionobject.txt. First, =91123.345.678.90=92= doesn=92t look like a legitimate IP address; is it supposed to be? If = so, could a better IP address be found? If you don=92t need an IP = address here, you might want to consider using a RFC2606-compliant FQDN = instead. Also, should the resource be called =91informationobject.txt=92 = (with a =91t=92)? If you're going to use an IP address I'd strongly suggest picking one = from one of the reserved for documentation blocks listed in rfc5737. Ben =20 From wes@mti-systems.com Fri Jan 28 08:56:07 2011 Return-Path: X-Original-To: decade@core3.amsl.com Delivered-To: decade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CEFB73A68F8 for ; Fri, 28 Jan 2011 08:56:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ux5YMzGmGhAv for ; Fri, 28 Jan 2011 08:56:07 -0800 (PST) Received: from omr9.networksolutionsemail.com (omr9.networksolutionsemail.com [205.178.146.59]) by core3.amsl.com (Postfix) with ESMTP id DD5793A6811 for ; Fri, 28 Jan 2011 08:56:06 -0800 (PST) Received: from cm-omr7 (mail.networksolutionsemail.com [205.178.146.50]) by omr9.networksolutionsemail.com (8.13.6/8.13.6) with ESMTP id p0SGxC49009421 for ; Fri, 28 Jan 2011 11:59:12 -0500 Authentication-Results: cm-omr7 smtp.user=wes@mti-systems.com; auth=pass (PLAIN) X-Authenticated-UID: wes@mti-systems.com Received: from [108.98.159.173] ([108.98.159.173:59547] helo=[192.168.9.2]) by cm-omr7 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id 3A/C0-10500-DC5F24D4; Fri, 28 Jan 2011 11:59:12 -0500 Message-ID: <4D42F5BC.2030900@mti-systems.com> Date: Fri, 28 Jan 2011 11:58:36 -0500 From: Wesley Eddy Organization: MTI Systems User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: "Woundy, Richard" , decade@ietf.org References: <1CA25301D2219F40B3AA37201F0EACD113400ECC@PACDCEXMB05.cable.comcast.com> In-Reply-To: <1CA25301D2219F40B3AA37201F0EACD113400ECC@PACDCEXMB05.cable.comcast.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [decade] Start of WGLC for draft-ietf-decade-problem-statement-02 X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jan 2011 16:56:07 -0000 On 1/28/2011 9:26 AM, Woundy, Richard wrote: > Folks, > > Haibin and I are starting the working group last call for > draft-ietf-decade-problem-statement-02, > http://datatracker.ietf.org/doc/draft-ietf-decade-problem-statement/, to > be completed by Monday February 14. Please send all concerns, > suggestions and comments about this internet-draft to the DECADE mailing > list, decade@ietf.org . > Here are some comments: The intended status should be "Informational" and not "Standards Track". This document is more than just a problem statement; it also includes description of the solution approach that DECADE is pursuing. The document needs to provide more context about what "in-network" means, since in the context of the document it seems to specifically mean resources provided by an ISP. I'm not sure if the work is applicable to nodes that are merely "on a network" providing services, rather than "inside a network". This is important to understand, as it is central to the entire document (and DECADE) and it influences applicability. (editorial) Section 1, paragraph 2 - "to effectively utilize" -> "from effectively utilizing" (editorial) Make sure "P2P" and "p2p" are used consistently (one or the other). (editorial) "flash crowd" versus "flash crowds" should be checked for usage in multiple places -- Wes Eddy MTI Systems From Akbar.Rahman@InterDigital.com Sat Jan 29 07:19:13 2011 Return-Path: X-Original-To: decade@core3.amsl.com Delivered-To: decade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B2F233A67D8 for ; Sat, 29 Jan 2011 07:19:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.166 X-Spam-Level: X-Spam-Status: No, score=-1.166 tagged_above=-999 required=5 tests=[AWL=-0.568, BAYES_00=-2.599, NORMAL_HTTP_TO_IP=0.001, SARE_HEXOCTDWORD=2] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JqxcP5nHhWTg for ; Sat, 29 Jan 2011 07:19:12 -0800 (PST) Received: from idcout.InterDigital.com (idcexmail.interdigital.com [12.32.197.135]) by core3.amsl.com (Postfix) with ESMTP id 9738D3A677E for ; Sat, 29 Jan 2011 07:19:12 -0800 (PST) Received: from SAM.InterDigital.com ([10.30.2.11]) by idcout.InterDigital.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 29 Jan 2011 10:22:21 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sat, 29 Jan 2011 10:22:16 -0500 Message-ID: In-Reply-To: <786107B4-FD98-4A1C-964D-147B417201D9@niven-jenkins.co.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [decade] Start of WGLC for draft-ietf-decade-survey-03 Thread-Index: Acu/BHGiWhE4sgJcQEWwYwG1L0UYOwAwuvxA References: <1CA25301D2219F40B3AA37201F0EACD113400EE3@PACDCEXMB05.cable.comcast.com><1CA25301D2219F40B3AA37201F0EACD113400EFA@PACDCEXMB05.cable.comcast.com> <786107B4-FD98-4A1C-964D-147B417201D9@niven-jenkins.co.uk> From: "Rahman, Akbar" To: "Ben Niven-Jenkins" X-OriginalArrivalTime: 29 Jan 2011 15:22:21.0818 (UTC) FILETIME=[531105A0:01CBBFC8] Cc: decade@ietf.org Subject: Re: [decade] Start of WGLC for draft-ietf-decade-survey-03 X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Jan 2011 15:19:13 -0000 Hi Ben, Yes, we agree that our current example needs to be changed. We propose to make the change in section 4.7 as follows: FROM: In today's network the information objects are named relative to the hosts they are stored on (e.g., http://123.345.678.90/informaionobject.txt). TO: In today's network the information objects are named relative to the hosts they are stored on (e.g. http://www.example.com/information-object.txt). Does this address your concern? Sincerely, Akbar -----Original Message----- From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.org] On Behalf Of Ben Niven-Jenkins Sent: Friday, January 28, 2011 11:00 AM To: Woundy, Richard Cc: decade@ietf.org Subject: Re: [decade] Start of WGLC for draft-ietf-decade-survey-03 On 28 Jan 2011, at 14:37, Woundy, Richard wrote: > Section 4.7 (Network of Information) uses the URLhttp://123.345.678.90/informaionobject.txt. First, '123.345.678.90' doesn't look like a legitimate IP address; is it supposed to be? If so, could a better IP address be found? If you don't need an IP address here, you might want to consider using a RFC2606-compliant FQDN instead. Also, should the resource be called 'informationobject.txt' (with a 't')? If you're going to use an IP address I'd strongly suggest picking one from one of the reserved for documentation blocks listed in rfc5737. Ben =20 _______________________________________________ decade mailing list decade@ietf.org https://www.ietf.org/mailman/listinfo/decade From Akbar.Rahman@InterDigital.com Sat Jan 29 07:31:46 2011 Return-Path: X-Original-To: decade@core3.amsl.com Delivered-To: decade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3153D3A67E2 for ; Sat, 29 Jan 2011 07:31:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.128 X-Spam-Level: X-Spam-Status: No, score=-1.128 tagged_above=-999 required=5 tests=[AWL=-0.531, BAYES_00=-2.599, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001, SARE_HEXOCTDWORD=2] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cqSaVVO9MMDp for ; Sat, 29 Jan 2011 07:31:36 -0800 (PST) Received: from idcout.InterDigital.com (idcexmail.interdigital.com [12.32.197.135]) by core3.amsl.com (Postfix) with ESMTP id 9862A3A677E for ; Sat, 29 Jan 2011 07:31:35 -0800 (PST) Received: from SAM.InterDigital.com ([10.30.2.11]) by idcout.InterDigital.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 29 Jan 2011 10:34:45 -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_01CBBFCA.0DA60AF4" Date: Sat, 29 Jan 2011 10:34:40 -0500 Message-ID: In-Reply-To: <1CA25301D2219F40B3AA37201F0EACD113400EFA@PACDCEXMB05.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [decade] Start of WGLC for draft-ietf-decade-survey-03 Thread-Index: Acu+95/VNNTNV6GpSgeYCeTmt9YMAgAACFcQADQtPQA= References: <1CA25301D2219F40B3AA37201F0EACD113400EE3@PACDCEXMB05.cable.comcast.com> <1CA25301D2219F40B3AA37201F0EACD113400EFA@PACDCEXMB05.cable.comcast.com> From: "Rahman, Akbar" To: "Woundy, Richard" X-OriginalArrivalTime: 29 Jan 2011 15:34:45.0053 (UTC) FILETIME=[0E11AED0:01CBBFCA] Cc: decade@ietf.org Subject: Re: [decade] Start of WGLC for draft-ietf-decade-survey-03 X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Jan 2011 15:31:46 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBBFCA.0DA60AF4 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Rich, =20 Thanks for your comments. We will until after the WGLC to make the changes as per your direction. In the meantime, please see below for my feedback (identified by "*** AKBAR: Comment answer. ****") to your comments. =20 Sincerely, =20 =20 Akbar =20 From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.org] On Behalf Of Woundy, Richard Sent: Friday, January 28, 2011 9:38 AM To: decade@ietf.org Subject: Re: [decade] Start of WGLC for draft-ietf-decade-survey-03 =20 Below are my personal comments on the DECADE Survey draft. Please do not make any changes to the draft at this time; I would like the authors to incorporate these comments after WGLC. =20 *** AKBAR: Okay we will wait until after the WGLC before making any changes to the draft **** =20 Should the name of section 4.4 be "Content Delivery Network" instead of "CDN"? The other sections in this part of the draft use full names in the section titles. =20 *** AKBAR: Okay. (We will leave the titles of section 5 as is because they are names of protocols.) **** =20 Section 4.7 (Network of Information) uses the URL http://123.345.678.90/informaionobject.txt. First, '123.345.678.90' doesn't look like a legitimate IP address; is it supposed to be? If so, could a better IP address be found? If you don't need an IP address here, you might want to consider using a RFC2606-compliant FQDN instead. Also, should the resource be called 'informationobject.txt' (with a 't')? =20 *** AKBAR: Okay. Please see my answer to Ben Niven-Jenkins for our proposed change. ****=20 =20 Mispelled words identified from the Idspell Tool, http://tools.ietf.org/tools/idspell/webservice. =20 *** AKBAR: Thanks for catching these typos! We definitely have to use this tool next time. **** =20 Section 4. s/architecutres /architectures Section 4.1.1. s/hierarchichal /hierarchical Section 4.4.1. s/existance = /existence Section 4.6.1. s/sysem = /system Section 4.8.1. s/sysem = /system Section 4.8.5. s/nework /network Section 4.9.1. s/sysem = /system Section 4.9.5. s/avaialable /available Section 4.10. s/mulitmedia /multimedia Section 4.11.1. s/existance /existence Section 4.13.1. s/existance /existence Section 4.14. s/primitves = /primitives Section 5.5.4. s/beyon = /beyond Section 5.6. s/classicaly = /classically, s/capabilites /capabilities Section 6. s/desgined /designed =20 >From idnits, http://tools.ietf.org/tools/idnits/ =20 idnits 2.12.05=20 =20 tmp/draft-ietf-decade-survey-03.txt: tmp/draft-ietf-decade-survey-03.txt(294): Found possible FQDN 'www.wikipedia.org' in position 27; this doesn't match RFC 2606's suggested ".example" or ".example.(com|org|net)". =20 [Rich - this might be OK as the particular website is the example. But it might make more sense to refer to Wikipedia as a service, instead of www.wikipedia.org as a website.] =20 =20 *** AKBAR: Okay, we will just refer to "Wikipedia" as a service. **** =20 =20 Checking boilerplate required by RFC 5378 and the IETF Trust (see http://trustee.ietf.org/license-info): =20 ------------------------------------------------------------------------ ---- =20 No issues found here. =20 Checking nits according to http://www.ietf.org/id-info/1id-guidelines.txt: =20 ------------------------------------------------------------------------ ---- =20 No issues found here. =20 Checking nits according to http://www.ietf.org/id-info/checklist : =20 ------------------------------------------------------------------------ ---- =20 =3D=3D There are 1 instance of lines with non-RFC2606-compliant FQDNs = in the document. =20 =20 Miscellaneous warnings: =20 ------------------------------------------------------------------------ ---- =20 -- The document date (January 18, 2011) is 6 days in the past. Is this intentional? =20 [Rich - ignore this.] =20 Checking references for intended status: Informational =20 ------------------------------------------------------------------------ ---- =20 =3D=3D Outdated reference: A later version (-02) exists of draft-ietf-decade-problem-statement-01 =20 [Rich - please fix this. Since the problem statement is also going through WGLC, let's coordinate this change. It may make sense to change to version -03.] =20 *** AKBAR: Okay. Currently these reference numbers are generated automatically by the XML2RFC tool. So we may have to manually change the version of the reference if it is not in the IETF database at the time. ***** =20 =20 Summary: 0 errors (**), 2 warnings (=3D=3D), 1 comment (--). ------------------------------------------------------------------------ -------- =20 -- Rich =20 From: Woundy, Richard=20 Sent: Friday, January 28, 2011 9:28 AM To: decade@ietf.org Cc: Songhaibin; Woundy, Richard Subject: Start of WGLC for draft-ietf-decade-survey-03 =20 Folks, =20 Haibin and I are starting the working group last call for draft-ietf-decade-survey-03, http://datatracker.ietf.org/doc/draft-ietf-decade-survey/, to be completed by Monday February 14. Please send all concerns, suggestions and comments about this internet-draft to the DECADE mailing list, decade@ietf.org. =20 Authors, please do not make any additional changes to the internet-draft unless directed by the WG chairs. =20 Draft reviewers, it would be helpful to get your confirmation that your previous review comments have been correctly reflected in this version. =20 Thanks. =20 -- Rich and Haibin ------_=_NextPart_001_01CBBFCA.0DA60AF4 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi = Rich,

 

Thanks for your = comments.  We will until after the WGLC to make the changes as per your = direction.  In the meantime, please see below for my feedback (identified by = “*** AKBAR: Comment answer. ****”) to your = comments.

 

Sincerely,

 

 

Akbar

 

From:= decade-bounces@ietf.org [mailto:decade-bounces@ietf.org] On Behalf Of = Woundy, Richard
Sent: Friday, January 28, 2011 9:38 AM
To: decade@ietf.org
Subject: Re: [decade] Start of WGLC for = draft-ietf-decade-survey-03

 

Below are my personal = comments on the DECADE Survey draft. Please do not make any changes to the draft = at this time; I would like the authors to incorporate these comments after = WGLC.

 

*** AKBAR: Okay we = will wait until after the WGLC before making any changes to the draft = ****

 

Should the name of = section 4.4 be “Content Delivery Network” instead of “CDN”? = The other sections in this part of the draft use full names in the section = titles.

 

*** AKBAR: = Okay.  (We will leave the titles of section 5 as is because they are names of = protocols.) ****

 

Section 4.7 (Network = of Information) uses the URL http://123.345.678.90= /informaionobject.txt. First, ‘123.345.678.90’ doesn’t look like a legitimate = IP address; is it supposed to be? If so, could a better IP address be = found? If you don’t need an IP address here, you might want to consider = using a RFC2606-compliant FQDN instead. Also, should the resource be called ‘informationobject.txt’ (with a = ‘t’)?

 

*** AKBAR: = Okay.  Please see my answer to Ben Niven-Jenkins for our proposed change. **** =

 

Mispelled words = identified from the Idspell Tool, http://tools.ietf= .org/tools/idspell/webservice.

 

*** AKBAR: Thanks for = catching these typos!  We definitely have to use this tool next time. = ****

 

Section 4. s/architecutres/architectures

Section 4.1.1. s/hierarchichal/hierarchical

Section 4.4.1. s/existance/existence

Section 4.6.1. s/sysem/system

Section 4.8.1. s/sysem/system

Section 4.8.5. s/nework/network

Section 4.9.1. s/sysem/system

Section 4.9.5. s/avaialable/available

Section 4.10. s/mulitmedia/multimedia

Section 4.11.1. s/existance/existence

Section 4.13.1. s/existance/existence

Section 4.14. s/primitves/primitives

Section 5.5.4. s/beyon/beyond

Section 5.6. s/classicaly/classically, s/capabilites/capabilities

Section 6. s/desgined/designed

 

From idnits, http://tools.ietf.org/tools/= idnits/

 

idnits 2.12.05 =

 

tmp/draft-ietf-decade-survey-03.txt:

tmp/draft-ietf-decade-survey-03.txt(294): Found possible FQDN 'www.wikipedia.org' in position 27; this doesn't = match RFC 2606's suggested ".example" or = ".example.(com|org|net)".

 

[Rich – this = might be OK as the particular website is the example. But it might make more sense = to refer to Wikipedia as a service, instead of www.wikipedia.org as a website.]

 

 

*** AKBAR: Okay, we = will just refer to “Wikipedia” as a service. = ****

 

 

  Checking = boilerplate required by RFC 5378 and the IETF Trust (see

  http://trustee.ietf.org/lic= ense-info):

  = -------------------------------------------------------------------------= ---

 

     No issues found here.

 

  Checking nits = according to http://www.ietf.o= rg/id-info/1id-guidelines.txt:

  = -------------------------------------------------------------------------= ---

 

     No issues found here.

 

  Checking nits = according to http://www.ietf.org/id-inf= o/checklist :

  -------------------------------------------------------------------------= ---

 

  =3D=3D There = are 1 instance of lines with non-RFC2606-compliant FQDNs in the

     document.

 

 

  Miscellaneous = warnings:

  -------------------------------------------------------------------------= ---

 

  -- The = document date (January 18, 2011) is 6 days in the past.  Is = this

     intentional?

 

[Rich – ignore = this.]

 

  Checking = references for intended status: Informational

  -------------------------------------------------------------------------= ---

 

  =3D=3D = Outdated reference: A later version (-02) exists of

     draft-ietf-decade-problem-statement-01

 

[Rich – please = fix this. Since the problem statement is also going through WGLC, let’s = coordinate this change. It may make sense to change to version = -03.]

 

*** AKBAR: = Okay.  Currently these reference numbers are generated automatically by the XML2RFC = tool.  So we may have to manually change the version of the reference if it is = not in the IETF database at the time. *****

 

 

     Summary: 0 errors (**), 2 warnings (=3D=3D), 1 comment = (--).

-------------------------------------------------= -------------------------------

 

-- = Rich

 

From:= Woundy, = Richard
Sent: Friday, January 28, 2011 9:28 AM
To: decade@ietf.org
Cc: Songhaibin; Woundy, Richard
Subject: Start of WGLC for = draft-ietf-decade-survey-03

 

Folks,

 

Haibin and I are starting the working group last = call for draft-ietf-decade-survey-03, http:/= /datatracker.ietf.org/doc/draft-ietf-decade-survey/, to be completed by Monday February 14. Please send all concerns, = suggestions and comments about this internet-draft to the DECADE mailing list, decade@ietf.org.

 

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

 

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

 

Thanks.

 

-- Rich and Haibin

------_=_NextPart_001_01CBBFCA.0DA60AF4-- From ben@niven-jenkins.co.uk Sat Jan 29 10:04:25 2011 Return-Path: X-Original-To: decade@core3.amsl.com Delivered-To: decade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF3D23A6840 for ; Sat, 29 Jan 2011 10:04:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.515 X-Spam-Level: X-Spam-Status: No, score=-103.515 tagged_above=-999 required=5 tests=[AWL=-1.917, BAYES_00=-2.599, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HEXOCTDWORD=2, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fKSdpGCw5Ybt for ; Sat, 29 Jan 2011 10:04:25 -0800 (PST) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.61]) by core3.amsl.com (Postfix) with ESMTP id C960D3A683F for ; Sat, 29 Jan 2011 10:04:24 -0800 (PST) Received: from cpc22-cmbg15-2-0-cust173.5-4.cable.virginmedia.com ([86.27.176.174] helo=[192.168.0.203]) by mail6.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from ) id 1PjFCu-0007SF-H9; Sat, 29 Jan 2011 18:07:33 +0000 References: <1CA25301D2219F40B3AA37201F0EACD113400EE3@PACDCEXMB05.cable.comcast.com><1CA25301D2219F40B3AA37201F0EACD113400EFA@PACDCEXMB05.cable.comcast.com> <786107B4-FD98-4A1C-964D-147B417201D9@niven-jenkins.co.uk> In-Reply-To: Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii Message-Id: Content-Transfer-Encoding: quoted-printable From: Benjamin Niven-Jenkins Date: Sat, 29 Jan 2011 18:07:28 +0000 To: "Rahman, Akbar" X-Mailer: Apple Mail (2.1078) X-Mailcore-Auth: 9600544 X-Mailcore-Domain: 172912 Cc: decade@ietf.org Subject: Re: [decade] Start of WGLC for draft-ietf-decade-survey-03 X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Jan 2011 18:04:26 -0000 Akbar, It was actually Richard's comment I really just chipped in with the RFC = reference, but yes changing to www.example.com is an acceptable = alternative. Ben On 29 Jan 2011, at 15:22, Rahman, Akbar wrote: > Hi Ben, >=20 >=20 > Yes, we agree that our current example needs to be changed. We = propose > to make the change in section 4.7 as follows: >=20 > FROM: > In today's network the information objects are named relative to the > hosts they are stored on (e.g., > http://123.345.678.90/informaionobject.txt). >=20 >=20 > TO: > In today's network the information objects are named relative to the > hosts they are stored on (e.g. > http://www.example.com/information-object.txt). >=20 >=20 > Does this address your concern? >=20 >=20 > Sincerely, >=20 > Akbar >=20 > -----Original Message----- > From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.org] On = Behalf > Of Ben Niven-Jenkins > Sent: Friday, January 28, 2011 11:00 AM > To: Woundy, Richard > Cc: decade@ietf.org > Subject: Re: [decade] Start of WGLC for draft-ietf-decade-survey-03 >=20 >=20 > On 28 Jan 2011, at 14:37, Woundy, Richard wrote: >> Section 4.7 (Network of Information) uses the > URLhttp://123.345.678.90/informaionobject.txt. First, '123.345.678.90' > doesn't look like a legitimate IP address; is it supposed to be? If = so, > could a better IP address be found? If you don't need an IP address > here, you might want to consider using a RFC2606-compliant FQDN = instead. > Also, should the resource be called 'informationobject.txt' (with a > 't')? >=20 > If you're going to use an IP address I'd strongly suggest picking one > from one of the reserved for documentation blocks listed in rfc5737. >=20 > Ben >=20 >=20 > _______________________________________________ > decade mailing list > decade@ietf.org > https://www.ietf.org/mailman/listinfo/decade From Akbar.Rahman@InterDigital.com Sun Jan 30 07:09:13 2011 Return-Path: X-Original-To: decade@core3.amsl.com Delivered-To: decade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5121E3A67B7 for ; Sun, 30 Jan 2011 07:09:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.095 X-Spam-Level: X-Spam-Status: No, score=-2.095 tagged_above=-999 required=5 tests=[AWL=0.503, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ac-daYelwf8V for ; Sun, 30 Jan 2011 07:09:12 -0800 (PST) Received: from idcout.InterDigital.com (idcexmail.interdigital.com [12.32.197.135]) by core3.amsl.com (Postfix) with ESMTP id 14E443A67B4 for ; Sun, 30 Jan 2011 07:09:11 -0800 (PST) Received: from SAM.InterDigital.com ([10.30.2.11]) by idcout.InterDigital.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 30 Jan 2011 10:12:23 -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_01CBC090.18CFD0F4" Date: Sun, 30 Jan 2011 10:12:16 -0500 Message-ID: In-Reply-To: <1CA25301D2219F40B3AA37201F0EACD113400ECC@PACDCEXMB05.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [decade] Start of WGLC for draft-ietf-decade-problem-statement-02 Thread-Index: Acu+91Byr8CuZlwMSYaaxFnqkg41DwBmBSzw References: <1CA25301D2219F40B3AA37201F0EACD113400ECC@PACDCEXMB05.cable.comcast.com> From: "Rahman, Akbar" To: "Woundy, Richard" X-OriginalArrivalTime: 30 Jan 2011 15:12:23.0636 (UTC) FILETIME=[18EF7140:01CBC090] Cc: decade@ietf.org Subject: Re: [decade] Start of WGLC for draft-ietf-decade-problem-statement-02 X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Jan 2011 15:09:13 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBC090.18CFD0F4 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Rich, =20 =20 I have reviewed the decade problem statement (rev. 02) and confirm that it addresses all the comments that I had raised in my review of the document (rev. 00). Thanks to all the authors of the draft for doing a good job on the update. =20 =20 Sincerely, =20 Akbar =20 From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.org] On Behalf Of Woundy, Richard Sent: Friday, January 28, 2011 9:26 AM To: decade@ietf.org Subject: [decade] Start of WGLC for draft-ietf-decade-problem-statement-02 =20 Folks, =20 Haibin and I are starting the working group last call for draft-ietf-decade-problem-statement-02, http://datatracker.ietf.org/doc/draft-ietf-decade-problem-statement/, to be completed by Monday February 14. Please send all concerns, suggestions and comments about this internet-draft to the DECADE mailing list, decade@ietf.org. =20 Authors, please do not make any additional changes to the internet-draft unless directed by the WG chairs. =20 Draft reviewers, it would be helpful to get your confirmation that your previous review comments have been correctly reflected in this version. =20 Thanks. =20 -- Rich and Haibin ------_=_NextPart_001_01CBC090.18CFD0F4 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi = Rich,

 

 

I have reviewed the = decade problem statement (rev. 02) and confirm that it addresses all the = comments that I had raised in my review of the document (rev. 00).  Thanks to all = the authors of the draft for doing a good job on the = update.

 

 

Sincerely,

 

Akbar

 

From:= = decade-bounces@ietf.org [mailto:decade-bounces@ietf.org] On Behalf Of Woundy, Richard
Sent: Friday, January 28, 2011 9:26 AM
To: decade@ietf.org
Subject: [decade] Start of WGLC for draft-ietf-decade-problem-statement-02

 

Folks,

 

Haibin and I are starting the working group last = call for draft-ietf-decade-problem-statement-02, http://datatracker.ietf.org/doc/draft-ietf-decade-problem-statement/= , to be completed by Monday February 14. Please send all concerns, = suggestions and comments about this internet-draft to the DECADE mailing list, decade@ietf.org.

 

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

 

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

 

Thanks.

 

-- Rich and Haibin

------_=_NextPart_001_01CBC090.18CFD0F4--