From Internet-Drafts@ietf.org Fri May 6 10:45:03 2011 Return-Path: X-Original-To: decade@ietfa.amsl.com Delivered-To: decade@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E239E0775; Fri, 6 May 2011 10:45:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.576 X-Spam-Level: X-Spam-Status: No, score=-102.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4HvwYckIxi+X; Fri, 6 May 2011 10:45:02 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FA76E0779; Fri, 6 May 2011 10:45:02 -0700 (PDT) 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.53 Message-ID: <20110506174502.10048.49070.idtracker@ietfa.amsl.com> Date: Fri, 06 May 2011 10:45:02 -0700 Cc: decade@ietf.org Subject: [decade] I-D ACTION:draft-ietf-decade-integration-example-00.txt X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2011 17:45: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 : Leveraging In-network Storage in P2P LiveStreaming Author(s) : L. Chen, et al Filename : draft-ietf-decade-integration-example-00.txt Pages : 11 Date : 2011-04-29 DECADE is an in-network storage infrastructure which is under discussions and constructions. It can be integrated into Peer-to- Peer (P2P) applications to achieve more efficient content distributions. This document represents a detailed example of how to integrate DECADE into P2P live streaming (a popular P2P application). Specifically, it describes mainly about: 1) a preliminary DECADE client API; 2) a P2P live streaming integration with DECADE; 3) a testing on our DECADE integrarion and 4) an application performance analysis from the test. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-decade-integration-example-00.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-integration-example-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-05-06103657.I-D@ietf.org> --NextPart-- From internet-drafts@ietf.org Mon May 16 06:14:57 2011 Return-Path: X-Original-To: decade@ietfa.amsl.com Delivered-To: decade@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA6A7E0772; Mon, 16 May 2011 06:14:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.555 X-Spam-Level: X-Spam-Status: No, score=-102.555 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ocx6Yo4JfxNh; Mon, 16 May 2011 06:14:57 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AFD0E0669; Mon, 16 May 2011 06:14:57 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.54 Message-ID: <20110516131457.12038.37165.idtracker@ietfa.amsl.com> Date: Mon, 16 May 2011 06:14:57 -0700 Cc: decade@ietf.org Subject: [decade] I-D Action: draft-ietf-decade-integration-example-01.txt X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 May 2011 13:14:57 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Decoupled Application Data Enroute Wo= rking Group of the IETF. Title : Integration Examples of DECADE System Author(s) : Lijiang Chen Hongqiang Liu Zhigang Huang Xiaohui Chen Filename : draft-ietf-decade-integration-example-01.txt Pages : 20 Date : 2011-05-16 DECADE is an in-network storage infrastructure which is under discussions and constructions. It can be integrated into Peer-to- Peer (P2P) applications to achieve more efficient content distributions. This document represents two detailed examples of how to integrate DECADE into P2P applications (live streaming and file sharing). Specifically, it describes mainly about: 1) a preliminary DECADE client API; 2) a P2P live streaming integration with DECADE; 3) a P2P file sharing integration with DECADE; 4) tests on our DECADE integrarions and 5) an application performance analysis from the tests. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-decade-integration-example-0= 1.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-decade-integration-example-01= .txt From Internet-Drafts@ietf.org Fri May 20 09:30:04 2011 Return-Path: X-Original-To: decade@ietfa.amsl.com Delivered-To: decade@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 966BBE0710; Fri, 20 May 2011 09:30:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.457 X-Spam-Level: X-Spam-Status: No, score=-102.457 tagged_above=-999 required=5 tests=[AWL=-0.085, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 40pwuxi8rkgW; Fri, 20 May 2011 09:30:03 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF672E07CA; Fri, 20 May 2011 09:30:03 -0700 (PDT) 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.54 Message-ID: <20110520163003.18466.7193.idtracker@ietfa.amsl.com> Date: Fri, 20 May 2011 09:30:03 -0700 Cc: decade@ietf.org Subject: [decade] I-D ACTION:draft-ietf-decade-reqs-02.txt X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 May 2011 16:30:04 -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 : DECADE Requirements Author(s) : G. Yingjie, et al Filename : draft-ietf-decade-reqs-02.txt Pages : 23 Date : 2011-05-20 The target of DECoupled Application Data Enroute (DECADE) is to provide an open and standard in-network storage system for applications, primarily P2P applications, to store, retrieve and manage their data. This draft enumerates and explains requirements, not only for store and retrieve, but also for data management, access control and resource control, that should be considered during the design and implementation of a DECADE system. These are requirements on the entire system; some of the requirements may eventually be implemented by an existing protocol with/without some extensions (e.g., the data transport level). A user of DECADE as a complete architecture would be guaranteed complete functionality. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-decade-reqs-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-reqs-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-05-20092931.I-D@ietf.org> --NextPart-- From richard_woundy@cable.comcast.com Fri May 20 14:59:41 2011 Return-Path: X-Original-To: decade@ietfa.amsl.com Delivered-To: decade@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90991E0677 for ; Fri, 20 May 2011 14:59:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.349 X-Spam-Level: X-Spam-Status: No, score=-108.349 tagged_above=-999 required=5 tests=[AWL=-0.113, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_HI=-8, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MMYHEuUurHJT for ; Fri, 20 May 2011 14:59:40 -0700 (PDT) Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by ietfa.amsl.com (Postfix) with ESMTP id 7EAE8E06BE for ; Fri, 20 May 2011 14:59:40 -0700 (PDT) Received: from ([24.40.55.41]) by pacdcimo01.cable.comcast.com with ESMTP with TLS id 5503620.124774102; Fri, 20 May 2011 17:59:37 -0400 Received: from PACDCEXMB05.cable.comcast.com ([fe80::a5b0:e5c4:df1b:2367]) by PACDCEXHUB02.cable.comcast.com ([fe80::11d4:f530:37a0:9f4e%12]) with mapi id 14.01.0289.001; Fri, 20 May 2011 17:59:37 -0400 From: "Woundy, Richard" To: "decade@ietf.org" Thread-Topic: [decade] I-D ACTION:draft-ietf-decade-reqs-02.txt Thread-Index: AQHMFws8vQP/SRZESU+yhd5Mm3DtUpSWQy+Q Date: Fri, 20 May 2011 21:59:36 +0000 Message-ID: <1CA25301D2219F40B3AA37201F0EACD113527102@PACDCEXMB05.cable.comcast.com> References: <20110520163003.18466.7193.idtracker@ietfa.amsl.com> In-Reply-To: <20110520163003.18466.7193.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.163.75.13] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [decade] I-D ACTION:draft-ietf-decade-reqs-02.txt X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 May 2011 21:59:41 -0000 I would like to thank the authors for their updated version of the DECADE R= equirements draft. I am reaching out to the folks that volunteered to review this draft at IET= F 80 in Prague. Any other reviews of this draft are welcomed. I found one minor nit: an outdated reference to the -00 version of the prob= lem statement draft. [I-D.ietf-decade-problem-statement] Yongchao, S., Zong, N., Yang, Y., and R. Alimi, "DECoupled Application Data Enroute (DECADE) Problem Statement", draft-ietf-decade-problem-statement-00 (work in progress), August 2010. -- Rich -----Original Message----- From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.org] On Behalf Of= Internet-Drafts@ietf.org Sent: Friday, May 20, 2011 12:30 PM To: i-d-announce@ietf.org Cc: decade@ietf.org Subject: [decade] I-D ACTION:draft-ietf-decade-reqs-02.txt A new Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Decoupled Application Data Enroute Working= Group of the IETF. Title : DECADE Requirements Author(s) : G. Yingjie, et al Filename : draft-ietf-decade-reqs-02.txt Pages : 23 Date : 2011-05-20 =20 The target of DECoupled Application Data Enroute (DECADE) is to provide an open and standard in-network storage system for applications, primarily P2P applications, to store, retrieve and manage their data. This draft enumerates and explains requirements, not only for store and retrieve, but also for data management, access control and resource control, that should be considered during the design and implementation of a DECADE system. These are requirements on the entire system; some of the requirements may eventually be implemented by an existing protocol with/without some extensions (e.g., the data transport level). A user of DECADE as a complete architecture would be guaranteed complete functionality. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-decade-reqs-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 implementa= tion to automatically retrieve the ASCII version of the Internet-Draft. From internet-drafts@ietf.org Sat May 21 06:43:40 2011 Return-Path: X-Original-To: decade@ietfa.amsl.com Delivered-To: decade@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04CC2E06CD; Sat, 21 May 2011 06:43:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.571 X-Spam-Level: X-Spam-Status: No, score=-102.571 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DuhuDqcNzIya; Sat, 21 May 2011 06:43:39 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B68AE06BC; Sat, 21 May 2011 06:43:39 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.54 Message-ID: <20110521134339.4097.19471.idtracker@ietfa.amsl.com> Date: Sat, 21 May 2011 06:43:39 -0700 Cc: decade@ietf.org Subject: [decade] I-D Action: draft-ietf-decade-arch-01.txt X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 May 2011 13:43:40 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Decoupled Application Data Enroute Wo= rking Group of the IETF. Title : DECADE Architecture Author(s) : Richard Alimi Y. Richard Yang Akbar Rahman Dirk Kutscher Hongqiang Liu Filename : draft-ietf-decade-arch-01.txt Pages : 37 Date : 2011-05-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. One technique to improve the network efficiency of P2P applications is to introduce storage capabilities within the networks. The DECADE Working Group has been formed with the goal of developing an architecture to provide this capability. This document presents an architecture, discusses the underlying principles, and identifies core components and protocols supporting the architecture. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-decade-arch-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-decade-arch-01.txt From richard.alimi@gmail.com Sat May 21 14:55:36 2011 Return-Path: X-Original-To: decade@ietfa.amsl.com Delivered-To: decade@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CFB0E0700 for ; Sat, 21 May 2011 14:55:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.818 X-Spam-Level: X-Spam-Status: No, score=-2.818 tagged_above=-999 required=5 tests=[AWL=-0.068, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eHj6C9Z+Ixor for ; Sat, 21 May 2011 14:55:35 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6ED31E06B9 for ; Sat, 21 May 2011 14:55:35 -0700 (PDT) Received: by iyn15 with SMTP id 15so4808076iyn.31 for ; Sat, 21 May 2011 14:55:34 -0700 (PDT) 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:from :date:x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=kJ3nQJ1UgFkeg9K9rrSu18EHnAlk+E/3dV2jjD8gXPo=; b=hYRTDRaUOIDubogNuVGq6igB8z+BVgmOtxIQVABDTdzLKcBzzts1XIYXpLvHg8c2TW HrYhTQdrxhyHeUngvstyeVi6rNEy7tZ6KCPrjnP2hOYxif/se474xW5SR0OmmGjVzCsq EzLZjJLhOAxiD+/4XNMJErlC0/Tw3rGMmgRqo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; b=jLDXoC7PNNnl90esk0lUtAdRXG5xLpFdKrBq/k7iFSt12LM5t4wfd2hTyyzrvZMcjX YVe5GNtzRfS8hYJEFu5qeqVPJWLr9JnyL67M9DfWB2ZJm882wnheKwCH5xN+gL8z5XVC lcNRtU7YtfY7Ca2Zj3oZ1wPo6AHYihlpy3c9g= Received: by 10.231.186.26 with SMTP id cq26mr682757ibb.133.1306014933078; Sat, 21 May 2011 14:55:33 -0700 (PDT) MIME-Version: 1.0 Sender: richard.alimi@gmail.com Received: by 10.231.91.145 with HTTP; Sat, 21 May 2011 14:55:13 -0700 (PDT) In-Reply-To: <1CA25301D2219F40B3AA37201F0EACD113527102@PACDCEXMB05.cable.comcast.com> References: <20110520163003.18466.7193.idtracker@ietfa.amsl.com> <1CA25301D2219F40B3AA37201F0EACD113527102@PACDCEXMB05.cable.comcast.com> From: Richard Alimi Date: Sat, 21 May 2011 14:55:13 -0700 X-Google-Sender-Auth: jzYDgu5SghYIOgVelk7leXHw3mk Message-ID: To: "Woundy, Richard" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "decade@ietf.org" Subject: Re: [decade] I-D ACTION:draft-ietf-decade-reqs-02.txt X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 May 2011 21:55:36 -0000 On Fri, May 20, 2011 at 2:59 PM, Woundy, Richard wrote: > I would like to thank the authors for their updated version of the DECADE= Requirements draft. > > I am reaching out to the folks that volunteered to review this draft at I= ETF 80 in Prague. Any other reviews of this draft are welcomed. > > I found one minor nit: an outdated reference to the -00 version of the pr= oblem statement draft. > > =A0 [I-D.ietf-decade-problem-statement] > =A0 =A0 =A0 =A0 =A0 =A0 =A0Yongchao, S., Zong, N., Yang, Y., and R. Alimi= , "DECoupled > =A0 =A0 =A0 =A0 =A0 =A0 =A0Application Data Enroute (DECADE) Problem Stat= ement", > =A0 =A0 =A0 =A0 =A0 =A0 =A0draft-ietf-decade-problem-statement-00 (work i= n progress), > =A0 =A0 =A0 =A0 =A0 =A0 =A0August 2010. Thanks - we have now fixed this in our local copy. Rich > > -- Rich > > -----Original Message----- > From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.org] On Behalf = Of Internet-Drafts@ietf.org > Sent: Friday, May 20, 2011 12:30 PM > To: i-d-announce@ietf.org > Cc: decade@ietf.org > Subject: [decade] I-D ACTION:draft-ietf-decade-reqs-02.txt > > A new Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Decoupled Application Data Enroute Worki= ng Group of the IETF. > > =A0 =A0Title =A0 =A0 =A0 =A0 : DECADE Requirements > =A0 =A0Author(s) =A0 =A0 : G. Yingjie, et al > =A0 =A0Filename =A0 =A0 =A0: draft-ietf-decade-reqs-02.txt > =A0 =A0Pages =A0 =A0 =A0 =A0 : 23 > =A0 =A0Date =A0 =A0 =A0 =A0 =A0: 2011-05-20 > > =A0 The target of DECoupled Application Data Enroute (DECADE) is to > =A0 provide an open and standard in-network storage system for > =A0 applications, primarily P2P applications, to store, retrieve and > =A0 manage their data. =A0This draft enumerates and explains requirements= , > =A0 not only for store and retrieve, but also for data management, access > =A0 control and resource control, that should be considered during the > =A0 design and implementation of a DECADE system. =A0These are requiremen= ts > =A0 on the entire system; some of the requirements may eventually be > =A0 implemented by an existing protocol with/without some extensions > =A0 (e.g., the data transport level). =A0A user of DECADE as a complete > =A0 architecture would be guaranteed complete functionality. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-decade-reqs-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 implemen= tation to automatically retrieve the ASCII version of the Internet-Draft. > _______________________________________________ > decade mailing list > decade@ietf.org > https://www.ietf.org/mailman/listinfo/decade > From richard_woundy@cable.comcast.com Mon May 23 12:15:08 2011 Return-Path: X-Original-To: decade@ietfa.amsl.com Delivered-To: decade@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1394E0817 for ; Mon, 23 May 2011 12:15:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.462 X-Spam-Level: X-Spam-Status: No, score=-108.462 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v2jBn6F6q42V for ; Mon, 23 May 2011 12:15:08 -0700 (PDT) Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by ietfa.amsl.com (Postfix) with ESMTP id C0FC2E07E0 for ; Mon, 23 May 2011 12:15:07 -0700 (PDT) Received: from ([24.40.55.42]) by pacdcimo01.cable.comcast.com with ESMTP with TLS id 5503620.125183197; Mon, 23 May 2011 11:05:19 -0400 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.0289.001; Mon, 23 May 2011 11:03:51 -0400 From: "Woundy, Richard" To: "decade@ietf.org" Thread-Topic: Reviews of the Decade Requirements draft Thread-Index: AcwZWp9yz1TMEOznTwqwrd+Q8UHi6w== Date: Mon, 23 May 2011 15:03:50 +0000 Message-ID: <1CA25301D2219F40B3AA37201F0EACD113528EFB@PACDCEXMB05.cable.comcast.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [76.96.69.4] Content-Type: multipart/alternative; boundary="_000_1CA25301D2219F40B3AA37201F0EACD113528EFBPACDCEXMB05cabl_" MIME-Version: 1.0 Subject: [decade] Reviews of the Decade Requirements draft X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2011 19:15:08 -0000 --_000_1CA25301D2219F40B3AA37201F0EACD113528EFBPACDCEXMB05cabl_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Folks, We would like to prepare the requirements draft, draft-ietf-decade-reqs-02<= http://datatracker.ietf.org/doc/draft-ietf-decade-reqs/>, for working group= last call in late June / July. The chairs are looking for document reviews to be sent to the mailing list = by Monday June 6. We already have three volunteers from our session in Prag= ue. Additional draft reviews by the deadline would be timely and greatly ap= preciated. 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_1CA25301D2219F40B3AA37201F0EACD113528EFBPACDCEXMB05cabl_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Folks,

 

We would like to prepare the requirements draft, draft-ietf-decade-reqs-02, for working group last call in late June / J= uly.

 

The chairs are looking for document reviews to be se= nt to the mailing list by Monday June 6. We already have three volunteers f= rom our session in Prague. Additional draft reviews by the deadline would b= e 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_1CA25301D2219F40B3AA37201F0EACD113528EFBPACDCEXMB05cabl_-- From richard_woundy@cable.comcast.com Wed May 25 06:12:36 2011 Return-Path: X-Original-To: decade@ietfa.amsl.com Delivered-To: decade@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92E05E0721 for ; Wed, 25 May 2011 06:12:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.462 X-Spam-Level: X-Spam-Status: No, score=-108.462 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rykyxM27adfT for ; Wed, 25 May 2011 06:12:36 -0700 (PDT) Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by ietfa.amsl.com (Postfix) with ESMTP id B6AB1E071A for ; Wed, 25 May 2011 06:12:35 -0700 (PDT) Received: from ([24.40.55.42]) by pacdcimo01.cable.comcast.com with ESMTP with TLS id 5503620.125834917; Wed, 25 May 2011 09:11:41 -0400 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.0289.001; Wed, 25 May 2011 09:11:41 -0400 From: "Woundy, Richard" To: "decade@ietf.org" Thread-Topic: Reviews of the Decade Architecture draft Thread-Index: AQHMGt1InEV0iJHOz0u2lMeOCfQATw== Date: Wed, 25 May 2011 13:11:39 +0000 Message-ID: <1CA25301D2219F40B3AA37201F0EACD11352AFDF@PACDCEXMB05.cable.comcast.com> References: <1CA25301D2219F40B3AA37201F0EACD113528EFB@PACDCEXMB05.cable.comcast.com> In-Reply-To: <1CA25301D2219F40B3AA37201F0EACD113528EFB@PACDCEXMB05.cable.comcast.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.191.223.245] Content-Type: multipart/alternative; boundary="_000_1CA25301D2219F40B3AA37201F0EACD11352AFDFPACDCEXMB05cabl_" MIME-Version: 1.0 Subject: [decade] Reviews of the Decade Architecture draft X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 13:12:36 -0000 --_000_1CA25301D2219F40B3AA37201F0EACD11352AFDFPACDCEXMB05cabl_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Folks, We would like to prepare the architecture draft, draft-ietf-decade-arch-01,= for working group last call in July. The chairs are looking for document reviews to be sent to the mailing list = by Monday June 13. We already have three volunteers from our session in Pra= gue. Additional draft reviews by the deadline would be timely and greatly a= ppreciated. 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_1CA25301D2219F40B3AA37201F0EACD11352AFDFPACDCEXMB05cabl_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Folks,

 

We would like to prepa= re the architecture draft, draft-ietf-decade-arch-01, for working group las= t call in July.

 

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

 

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

 

-- Rich

--_000_1CA25301D2219F40B3AA37201F0EACD11352AFDFPACDCEXMB05cabl_-- From Akbar.Rahman@InterDigital.com Mon May 30 12:39:40 2011 Return-Path: X-Original-To: decade@ietfa.amsl.com Delivered-To: decade@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C868BE06CF for ; Mon, 30 May 2011 12:39:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HyCnEz4-TMcL for ; Mon, 30 May 2011 12:39:34 -0700 (PDT) Received: from idcout.InterDigital.com (idcexmail.interdigital.com [12.32.197.135]) by ietfa.amsl.com (Postfix) with ESMTP id 2EB97E06AB for ; Mon, 30 May 2011 12:39:34 -0700 (PDT) Received: from SAM.InterDigital.com ([10.30.2.11]) by idcout.InterDigital.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 30 May 2011 15:39:32 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC1F01.4C8DE93F" Date: Mon, 30 May 2011 15:39:28 -0400 Message-ID: In-Reply-To: <1CA25301D2219F40B3AA37201F0EACD113528EFB@PACDCEXMB05.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [decade] Reviews of the Decade Requirements draft Thread-Index: AcwZWp9yz1TMEOznTwqwrd+Q8UHi6wFddggA References: <1CA25301D2219F40B3AA37201F0EACD113528EFB@PACDCEXMB05.cable.comcast.com> From: "Rahman, Akbar" To: X-OriginalArrivalTime: 30 May 2011 19:39:32.0938 (UTC) FILETIME=[4CB6D2A0:01CC1F01] Subject: Re: [decade] Reviews of the Decade Requirements draft X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 May 2011 19:39:40 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC1F01.4C8DE93F Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 =20 Here is my review of the DECADE Requirements draft (draft-ietf-decade-reqs-02 ): =20 =20 * Overall, the document was well thought out, informative and well written. I did, however, have the following comments: =20 General Editorial Comments: * For readability, all acronyms should be defined on first usage (e.g. VoD, CDN) * Should each requirement be given a simple label (e.g. PR1, SR1)? This will help in any future analysis of requirements compliance tracking (or reference) in other documents. * The use of the key term of "IAP" (In-network storage Access Protocol) is not consistent. I would have expected IAP to be referred to in each of the individual requirements in section 4.1.1. (Overall Protocol Requirements). But it was only used a few times. Or did I misunderstand the meaning of the term? Either way this should be clarified (i.e. the term used consistently throughout the document or not used at all).=20 =20 =20 Detailed Comments: * Section 1 (Introduction) o In the first paragraph there is a reference to "..primarily applications that could be implemented using a content distribution paradigm...". =20 o This statement invoked a classical web CDN (Content Distribution Network) model to my mind. However, in the next sentence it referred to "... applications including P2P applications, IPTV, and VoD" but did not include any type of CDN. =20 o So my question to the authors is, what did they have in mind when referring to "a content distribution paradigm"? And can they please clarify the text in this section to be more precise in this regard (as I do agree that it is good to have a clear model or paradigm in mind for the DECADE requirements) =20 * Section 2 (Terminology and Concepts) o With regard to the reference to the fact that the "distributed content is typically immutable". Does this also apply to the metadata? And the larger question, shouldn't there be an explicit requirement on the "immutability" data since this appears to be an underlying requirement for the system to work? o I did note, however, that there was a Non-Requirement for "No ability to update "(6.2.1) which seemed to cover the issue somewhat (but I did find the logic a bit confusing since it was a double negative type thinking). Couldn't you just eliminate 6.2.1 and have an explicit requirement for immutability? Again, I might be missing something so please feel free to rebut my argument.=20 =20 * Section 3 (Requirements Structure) o The word "underlying" is spelled incorrectly as "underling"=20 =20 * Section 4.1.1.2.2 and 4.1.1.3.2 o These two requirements for "Connections to Clients" look identical o One should be eliminated or else the reason for having them duplicated should be explicitly spelled out =20 * Sections 4.1.2.2 and 4.1.2.4 o The requirement in 4.1.2.2 (Indirect Transfer) looks to be logically a subset of the requirement in 4.1.2.4 (Communication among In-network Storage Elements) o Can 4.1.2.2 be eliminated? I am okay however if you feel strongly about keeping both of them =20 * Sections 4.1.2.4 and 4.1.3.4=20 o In the HTML view, the hyper links from the TOC do not work for these sections. Probably because the titles are too long. =20 * Section 4.1.7.4 (Credentials Not IP-Based) o IP addresses are dynamically and temporally assigned for nearly all devices today (and not just mobile devices). So in a way it seems nearly trivial to state that the credentials should not be based on IP addresses. Can you re-write the requirement to make it stronger? For example, mandating that the credential should be cryptographically secure? * Section 5 (Discovery Requirements) o Why is the Discovery requirement not listed under either the Protocol or Storage requirements? =20 o Note that section 3 (Requirements Structure) implies that all the requirements will fall under either Protocol or Storage categories. =20 * Section 6.1.2 (Multiple Writing) o Does it really make sense for "Implementations [to] raise an error to one of the writers"? Is it really an error? Also we had discussed off line the attack scenario where a user wants to steal some existing data by indicating that he wants to write the same data (though he does not actually have it) because he expects the DECADE server to come back and ask him not to bother writing it since the server already has it. Effectively letting him steal the data. o Thus I think the requirement needs to be clarified =20 * Section 7 (Implementation Considerations) o The introductory paragraph implies that the section is not finished (i.e. "The content of this section will be migrated to an appropriate place as the document and the Working Group progress") =20 * Section 8.2 (Open Issues) o All of these issues should be closed (or otherwise it does not make sense to go to WGLC) =20 * Section 9 (Security Considerations) o The section was a bit confusing =20 o It only refers to authorization though other items were obviously covered in the document (e.g. section 4.1.1.3) o Then it seems to introduce another requirement (in the 2nd paragraph). If this is really a requirement then it should be put in one of the previous sections (e.g. section 4.1.1.3) o My suggestion is that this section cover on a high level the philosophy to be used by DECADE for security, and all detailed requirements should be covered in previous sections =20 * Section 11.2 (Informative References) o The reference to DECADE Problem Statement needs to be updated to the correct revision (i.e. Rev. -03 instead of -00) o Also, when I click on the PPLive reference (i.e. http://www.pplive.com) from my office in Canada, it automatically redirects me to http://www.pptv.com and then seems to hang there (i.e. page never loads even after several minutes so I finally just gave up). Was this your experience as well? =20 =20 Sincerely, =20 =20 Akbar =20 =20 From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.org] On Behalf Of Woundy, Richard Sent: Monday, May 23, 2011 11:04 AM To: decade@ietf.org Subject: [decade] Reviews of the Decade Requirements draft =20 Folks, =20 We would like to prepare the requirements draft, draft-ietf-decade-reqs-02 , for working group last call in late June / July. =20 The chairs are looking for document reviews to be sent to the mailing list by Monday June 6. We already have three volunteers from our session in Prague. 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_01CC1F01.4C8DE93F Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

 

Here is my review of the = DECADE Requirements draft (draft-ie= tf-decade-reqs-02):

 

 

·         = Overall, = the document was well thought out, informative and well written.  I = did, however, have the following comments:

 

General = Editorial Comments:

·         = For = readability, all  acronyms should be defined on first usage (e.g. = VoD, CDN)

·         = Should each = requirement be given a simple label (e.g. PR1, SR1)?  This will = help in any future analysis of requirements compliance tracking (or = reference) in other documents.

·         = The use of = the key term of “IAP” (In-network storage Access Protocol) = is not consistent.  I would have expected IAP to be referred to in = each of the individual requirements in section 4.1.1. (Overall Protocol = Requirements).  But it was only used a few times.  Or did I = misunderstand the meaning of the term?  Either way this should be = clarified (i.e. the term used consistently throughout the document or = not used at all).

 

 

Detailed = Comments:

·         = Section 1 = (Introduction)

o   = In the = first paragraph there is a reference to “..primarily applications = that could be implemented using a content distribution = paradigm…”. 

o   = This = statement invoked a classical web CDN (Content Distribution Network) = model to my mind.  However, in the next sentence it referred to = “… applications including P2P applications, IPTV, and = VoD” but did not include any type of CDN.  =

o   = So my = question to the authors is, what did they have in mind when referring to = “a content distribution paradigm”?  And can they please = clarify the text in this section to be more precise in this regard (as I = do agree that it is good to have a clear model or paradigm in mind for = the DECADE requirements)

 

·         = Section 2 = (Terminology and Concepts)

o   = With regard = to the reference to the fact that the “distributed content is = typically immutable”.  Does this also apply to the = metadata?  And the larger question, shouldn’t there be an = explicit requirement on the “immutability” data since this = appears to be an underlying requirement for the system to = work?

o   = I did note, = however, that there was a Non-Requirement for “No ability to = update “(6.2.1) which seemed to cover the issue somewhat (but I = did find the logic a bit confusing since it was a double negative type = thinking).  Couldn’t you just eliminate 6.2.1 and have an = explicit requirement for immutability?  Again, I might be missing = something so please feel free to rebut my argument. =

 

·         = Section 3 = (Requirements Structure)

o   = The word = “underlying” is spelled incorrectly as = “underling”

 

·         = Section = 4.1.1.2.2 and 4.1.1.3.2

o   = These two = requirements for “Connections to Clients” look = identical

o   = One should = be eliminated or else the reason for having them duplicated should be = explicitly spelled out

 

·         = Sections = 4.1.2.2 and 4.1.2.4

o   = The = requirement in 4.1.2.2 (Indirect Transfer) looks to be logically a = subset of the requirement in 4.1.2.4 (Communication among In-network = Storage Elements)

o   = Can 4.1.2.2 = be eliminated?  I am okay however if you feel strongly about = keeping both of them

 

·         = Sections = 4.1.2.4 and 4.1.3.4

o   = In the HTML = view, the hyper links from the TOC do not work for these sections.  = Probably because the titles are too long.

 

·         = Section = 4.1.7.4 (Credentials Not IP-Based)

o   = IP = addresses are dynamically and temporally assigned for nearly all devices = today (and not just mobile devices).  So in a way it seems nearly = trivial to state that the credentials should not be based on IP = addresses.  Can you re-write the requirement to make it = stronger?  For example, mandating that the credential should be = cryptographically secure?

=

·         = Section 5 = (Discovery Requirements)

o   = Why is the = Discovery requirement not listed under either the Protocol or Storage = requirements? 

o   = Note that = section 3 (Requirements Structure) implies that all the requirements = will fall under either Protocol or Storage = categories.

 

·         = Section = 6.1.2 (Multiple Writing)

o   = Does it = really make sense for “Implementations [to] raise an error to one = of the writers”?  Is it really an error?   Also we = had discussed off line the attack scenario where a user wants to steal = some existing data by indicating that he wants to write the same data = (though he does not actually have it) because he expects the DECADE = server to come back and ask him not to bother writing it since the = server already has it.  Effectively letting him steal the = data.

o   = Thus I = think the requirement needs to be clarified

 

·         = Section 7 = (Implementation Considerations)

o   = The = introductory paragraph implies that the section is not finished (i.e. = “The content of this section will be migrated to an appropriate = place as the document and the Working Group = progress”)

 

·         = Section 8.2 = (Open Issues)

o   = All of = these issues should be closed (or otherwise it does not make sense to go = to WGLC)

 

·         = Section 9 = (Security Considerations)

o   = The section = was a bit confusing 

o   = It only = refers to authorization though other items were obviously covered in the = document (e.g. section 4.1.1.3)

o   = Then it = seems to introduce another requirement (in the 2nd = paragraph).  If this is really a requirement then it should be put = in one of the previous sections (e.g. section = 4.1.1.3)

o   = My = suggestion is that this section cover on a high level the philosophy to = be used by DECADE for security, and all detailed requirements should be = covered in previous sections

 

·         = Section = 11.2 (Informative References)

o   = The = reference to DECADE Problem Statement needs to be updated to the correct = revision (i.e. Rev. -03 instead of -00)

o   = Also, when = I click on the PPLive reference (i.e. http://www.pplive.com) from my office = in Canada, it automatically redirects me to http://www.pptv.com and then seems to = hang there (i.e. page never loads even after several minutes so I = finally just gave up).  Was this your experience as = well?

 

 

Sincerely,

 

 

Akbar

 

 

From:= = decade-bounces@ietf.org [mailto:decade-bounces@ietf.org] On Behalf Of = Woundy, Richard
Sent: Monday, May 23, 2011 11:04 = AM
To: decade@ietf.org
Subject: [decade] Reviews of = the Decade Requirements draft

 

Folks,

 

We would = like to prepare the requirements draft, draft-ie= tf-decade-reqs-02, for working group last call in late June / = July.

 

The chairs are looking for document reviews to be sent = to the mailing list by Monday June 6. We already have three volunteers = from our session in Prague. 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_01CC1F01.4C8DE93F--