From haibin.song@huawei.com Wed Dec 14 07:03:13 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 D272621F8B01 for ; Wed, 14 Dec 2011 07:03:13 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zwn2wZ0ww0Ad for ; Wed, 14 Dec 2011 07:03:13 -0800 (PST) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id 3C13B21F8A96 for ; Wed, 14 Dec 2011 07:03:13 -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 <0LW700DNQ8EZU1@szxga03-in.huawei.com> for decade@ietf.org; Wed, 14 Dec 2011 23:01:47 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LW7003NP8ARDL@szxga03-in.huawei.com> for decade@ietf.org; Wed, 14 Dec 2011 23:01:47 +0800 (CST) Received: from szxeml207-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AFV25031; Wed, 14 Dec 2011 23:01:29 +0800 Received: from SZXEML423-HUB.china.huawei.com (10.82.67.162) by szxeml207-edg.china.huawei.com (172.24.2.59) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 14 Dec 2011 23:01:24 +0800 Received: from SZXEML524-MBX.china.huawei.com ([169.254.4.28]) by szxeml423-hub.china.huawei.com ([10.82.67.162]) with mapi id 14.01.0323.003; Wed, 14 Dec 2011 23:01:28 +0800 Date: Wed, 14 Dec 2011 15:01:28 +0000 From: Songhaibin X-Originating-IP: [172.24.1.67] To: "decade@ietf.org" Message-id: MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_C3duCRb0EUiDArgWJMWYhw)" Content-language: en-US Accept-Language: en-US, zh-CN Thread-topic: draft meeting minutes posted Thread-index: Acy6cUHWbG2/Zh9pQVCSw2p7P6mRPQ== X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected Subject: [decade] draft meeting minutes posted 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, 14 Dec 2011 15:03:13 -0000 --Boundary_(ID_C3duCRb0EUiDArgWJMWYhw) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Dear folks, The meeting minutes have been posted to IETF website. Here is the link for it. http://www.ietf.org/proceedings/82/minutes/decade.txt Thanks again to Rich Alimi for taking the notes. Please check with your own memory and send email to the chairs if you want to make any corrections. BR, -Haibin & Rich --Boundary_(ID_C3duCRb0EUiDArgWJMWYhw) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: 7BIT

Dear folks,

 

The meeting minutes have been posted to IETF website. Here is the link for it.

http://www.ietf.org/proceedings/82/minutes/decade.txt

 

Thanks again to Rich Alimi for taking the notes. Please check with your own memory and send email to the chairs if you want to make any corrections.

 

BR,

-Haibin & Rich

--Boundary_(ID_C3duCRb0EUiDArgWJMWYhw)-- From zongning@huawei.com Tue Dec 20 00:12:09 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 D109621F847F for ; Tue, 20 Dec 2011 00:12:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.998 X-Spam-Level: X-Spam-Status: No, score=-105.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_46=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2smu1RDaooIj for ; Tue, 20 Dec 2011 00:12:08 -0800 (PST) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 3076121F8479 for ; Tue, 20 Dec 2011 00:12:07 -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 <0LWH00EIGTFYXO@szxga05-in.huawei.com> for decade@ietf.org; Tue, 20 Dec 2011 16:11:58 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LWH00L46TFF23@szxga05-in.huawei.com> for decade@ietf.org; Tue, 20 Dec 2011 16:11:57 +0800 (CST) Received: from szxeml201-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AFX66145; Tue, 20 Dec 2011 16:11:43 +0800 Received: from SZXEML421-HUB.china.huawei.com (10.82.67.160) by szxeml201-edg.china.huawei.com (172.24.2.39) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 20 Dec 2011 16:11:40 +0800 Received: from SZXEML504-MBX.china.huawei.com ([169.254.4.151]) by szxeml421-hub.china.huawei.com ([10.82.67.160]) with mapi id 14.01.0323.003; Tue, 20 Dec 2011 16:11:41 +0800 Date: Tue, 20 Dec 2011 08:11:39 +0000 From: ZongNing X-Originating-IP: [10.138.41.128] To: "decade@ietf.org" Message-id: MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_J8lU5AbzbSUsaHWsCf1U2A)" Content-language: zh-CN Accept-Language: en-US, zh-CN Thread-topic: Review of draft-ietf-decade-integration-example-02 Thread-index: Acy+7wATATnL0gO8RmiuICeHZYBvxg== X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected Subject: [decade] Review of draft-ietf-decade-integration-example-02 X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2011 08:12:10 -0000 --Boundary_(ID_J8lU5AbzbSUsaHWsCf1U2A) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi, I did a quick review of draft-ietf-decade-integration-example-02. First of all, I believe this draft provides some concrete examples of applying DECADE to existing P2P applications to achieve improved performance. I'd like to see this draft to move forward. I also have following comments & suggestions: 1) In Section 1 "Introduction", it seems that only P2P live streaming is mentioned. We should also mention file sharing application (e.g. Vuze) and Content Distribution Platform for CP; 2) In Section 2, "DECADE Module" and "DECADE Plugin" should be the same. We should merge these two definition and use one term in the whole draft. 3) In Section 2, "DECADE-Enabled Vuze" is covered by "DECADE Client". In the whole draft, we could either use two terms - "DECADE-enabled Vuze" & "DECADE-enable PPLS", or just use "DECADE Client" for general purpose. 4) I think Section 6 needs more editorial work. 5) In Section 6, I think we'd better to call it "content distribution platform for CP" rather than "ALTO+DECADE platform", as we don't focus on describing an ALTO+DECADE architecture in this draft. 6) In Section 6, we'd better to use DECADE service provider rather than ISP in Figure 4. We also need more explanation to Figure 4, as the connections are unclear, e.g. are these data or signaling links? Do we need more components such as ALTO server and content origins? 7) In Section 7, test settings for distribution platform for CP is missing, e.g. how many and which types of servers are used, which CPs are tested? 8) In Section 8, I think we'd better to give a content distribution performance example, e.g. how long to complete a content distribution, to how many users, how about the bandwidth usage? BR, Ning Zong --Boundary_(ID_J8lU5AbzbSUsaHWsCf1U2A) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Hi,

 

I did a quick review of draft-ietf-decade-integration-example-02.

First of all, I believe this draft provides some concrete examples of applying DECADE to existing P2P applications to achieve improved performance. I’d like to see this draft to move forward.

I also have following comments & suggestions:

1)       In Section 1 “Introduction”, it seems that only P2P live streaming is mentioned. We should also mention file sharing application (e.g. Vuze) and Content Distribution Platform for CP;

2)       In Section 2, “DECADE Module” and “DECADE Plugin” should be the same. We should merge these two definition and use one term in the whole draft.

3)       In Section 2, “DECADE-Enabled Vuze” is covered by “DECADE Client”. In the whole draft, we could either use two terms – “DECADE-enabled Vuze” & “DECADE-enable PPLS”, or just use “DECADE Client” for general purpose.

4)       I think Section 6 needs more editorial work.

5)       In Section 6, I think we’d better to call it “content distribution platform for CP” rather than “ALTO+DECADE platform”, as we don’t focus on describing an ALTO+DECADE architecture in this draft.

6)       In Section 6, we’d better to use DECADE service provider rather than ISP in Figure 4. We also need more explanation to Figure 4, as the connections are unclear, e.g. are these data or signaling links? Do we need more components such as ALTO server and content origins?

7)       In Section 7, test settings for distribution platform for CP is missing, e.g. how many and which types of servers are used, which CPs are tested?

8)       In Section 8, I think we’d better to give a content distribution performance example, e.g. how long to complete a content distribution, to how many users, how about the bandwidth usage?

 

BR,

Ning Zong

 

--Boundary_(ID_J8lU5AbzbSUsaHWsCf1U2A)-- From haibin.song@huawei.com Thu Dec 22 17:50:45 2011 Return-Path: X-Original-To: decade@ietfa.amsl.com Delivered-To: decade@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B2DC21F84AA for ; Thu, 22 Dec 2011 17:50:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uplkozGZaedf for ; Thu, 22 Dec 2011 17:50:41 -0800 (PST) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 259A521F84A9 for ; Thu, 22 Dec 2011 17:50:41 -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 <0LWM007GRVS4D3@szxga05-in.huawei.com> for decade@ietf.org; Fri, 23 Dec 2011 09:50:28 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LWM00EJ8VS46L@szxga05-in.huawei.com> for decade@ietf.org; Fri, 23 Dec 2011 09:50:28 +0800 (CST) Received: from szxeml202-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AFZ33579; Fri, 23 Dec 2011 09:50:23 +0800 Received: from SZXEML414-HUB.china.huawei.com (10.82.67.153) by szxeml202-edg.china.huawei.com (172.24.2.42) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 23 Dec 2011 09:50:11 +0800 Received: from SZXEML534-MBS.china.huawei.com ([169.254.6.210]) by SZXEML414-HUB.china.huawei.com ([10.82.67.153]) with mapi id 14.01.0323.003; Fri, 23 Dec 2011 09:50:18 +0800 Date: Fri, 23 Dec 2011 01:50:17 +0000 From: Songhaibin X-Originating-IP: [10.138.41.129] To: decade ietf Message-id: MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_sfy6nDGg2t23mnxaQcRvjw)" Content-language: zh-CN Accept-Language: en-US, zh-CN Thread-topic: [alto] Call for Papers for the "International Workshop on Cross-Stratum Optimization for Cloud Computing and Distributed Networked Applications" Thread-index: AczAIDG58OQ3/aJORk+S8Eiy29vosgAG6YuQAAAVmkAANjqFIA== X-MS-Has-Attach: yes X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected Subject: [decade] FW: [alto] Call for Papers for the "International Workshop on Cross-Stratum Optimization for Cloud Computing and Distributed Networked Applications" X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Dec 2011 01:50:45 -0000 --Boundary_(ID_sfy6nDGg2t23mnxaQcRvjw) Content-type: multipart/alternative; boundary="Boundary_(ID_PfhlS6VFtnqqrw/iwOS5rA)" --Boundary_(ID_PfhlS6VFtnqqrw/iwOS5rA) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable For those who may be interested. -Haibin From: alto-bounces@ietf.org [mailto:alto-bounces@ietf.org] On Behalf Of Lee= young Sent: Thursday, December 22, 2011 7:57 AM To: alto@ietf.org Subject: [alto] Call for Papers for the "International Workshop on Cross-St= ratum Optimization for Cloud Computing and Distributed Networked Applicatio= ns" [Apologies if you receive multiple copies of this message] First Call for Papers for the "International Workshop on Cross-Stratum Opti= mization for Cloud Computing and Distributed Networked Applications" http://cccso.net/ Co-located with the 10th IEEE International Symposium on Parallel and Distr= ibuted Processing with Applications, ISPA 2012 http://www.arcos.inf.uc3m.es/ispa12/index.shtml July 10-13, 2012 Leganes, Madrid, Spain Aims and Scope =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D The current lack of interaction between networked applications and the unde= rlying network during service provisioning cause inefficiencies on the use = of network resources which can negatively impact the quality expectations o= f the final consumers of those applications. Typical networked applications are offered through Information Technology (= IT) resources (as computing and storage facilities) residing in data center= s. Data centers then provide the physical and virtual infrastructure in whi= ch applications and services are provided. Since the data centers are usual= ly distributed geographically around a network, many decisions made in the = control and management of application services, such as where to instantiat= e another service instance, or which data center out of several is assigned= to a new customer, can have a significant impact on the state of the netwo= rk. In the same way, the capabilities and state of the network can have a m= ajor impact on application performance. Cross-stratum optimization (CSO) is referred to the combined optimization o= f both the application and the network components that aims to provide join= t resource optimization, responsiveness to quickly changing demands from/to= application to/from network, enhanced service resilience using cooperative= recovery techniques, and quality of experience assurance by a better use o= f existing network and application resources, among others. The CSO involves the overall optimization of application layer and network = resources by envisioning next generation architecture for interactions and = exchanges between the two layers to improve service continuity, performance= guarantees, scalability and manageability. The goal of this workshop is to= promote the research interest on the optimal integration of application an= d network resources. This workshop aims to explore the challenges and issues faced by cloud comp= uting and data center integration with networks. Among the key areas of inv= estigation to be discussed in the workshop are as follows: .- Application/network integration architectures and subsystems .- Use cases, business models and requirements for application/network inte= gration .- Control/management issues for application/network integration .- Network virtualization and its impact for application/network integratio= n .- Network-aware application/cloud computing .- Flexible and scalable networking solutions for distributed Data Centers .- Joint application/network reliability and security .- Experimental/trial experience .- Scalability .- Joint/shared performance and fault monitoring .- Multi-domain issues Important Dates =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Paper Submission Deadline: 03 February 2012 Paper Acceptance Notification: 30 March 2012 Camera-ready Paper Submissions: 13 April 2012 Tentative workshop day: 10 July 2012 (to be confirmed) Venue =3D=3D=3D=3D=3D Universidad Carlos III de Madrid, Leganes, Spain Submision guidelines =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Target papers should describe original and unpublished work. The submission= process will be done online by using EasyChair submission system: http://www.easychair.org/conferences/?conf=3Dispa2012 choosing this workshop among the various workshops held in conjunction with= ISPA-2012 Details on the paper format and length will be provided soon. Technical Program Committee =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 Richard Alimi (Google, USA) Greg Bernstein (Grotto Networking, USA) TaeSang Choi (ETRI, Korea) Nicola Ciulli (Nextworks, Italy) Oscar Gonzalez de Dios (Telef=F3nica I+D, Spain) Volker Hilt (Bell Labs, USA) Giada Landi (Nextworks, Italy) Dan Li (Huawei, China) Thomas D. Nadeau (CA Technologies, USA) Kohei Shiomoto (NTT, Japan) Ning So (Verizon, USA) Hui Yang (Beijing University Post and Telecommunication (BUPT), China) Yang Richard Yang (Yale University, USA) Workshop Organizing Committee =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 Young Lee, Huawei Technologies (leeyoung (at) huawei.com) Luis M. Contreras, Telef=F3nica I+D (lmcm (at) tid.es) Andrea Fumagalli, The University of Texas at Dallas (andreaf (at) utdallas.= edu) ______________ Young Lee Huawei Technologies --Boundary_(ID_PfhlS6VFtnqqrw/iwOS5rA) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: quoted-printable

For those who may be interested.

 

-Haibin

 

 

From: alto-bounces@ietf.org [mailto:alto-bounces@ietf.org] On Behalf Of Leeyoung
Sent: Thursday, December 22, 2011 7:57 AM
To: alto@ietf.org
Subject: [alto] Call for Papers for the "International Workshop= on Cross-Stratum Optimization for Cloud Computing and Distributed Networke= d Applications"

 

[Apologies if you receive multi= ple copies of this message]

 

First Call for Papers for the &= #8220;International Workshop on Cross-Stratum Optimization for Cloud Comput= ing and Distributed Networked Applications”

http://cccso.net/

 

Co-located with the 10th IEEE I= nternational Symposium on Parallel and Distributed Processing with Applicat= ions, ISPA 2012

http://www.arcos.inf.uc3m.es/is= pa12/index.shtml

July 10-13, 2012

Leganes, Madrid, Spain

 

Aims and Scope

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D

The current lack of interaction= between networked applications and the underlying network during service p= rovisioning cause inefficiencies on the use of network resources which can = negatively impact the quality expectations of the final consumers of those applications.

 

Typical networked applications = are offered through Information Technology (IT) resources (as computing and= storage facilities) residing in data centers. Data centers then provide th= e physical and virtual infrastructure in which applications and services are provided. Since the data centers ar= e usually distributed geographically around a network, many decisions made = in the control and management of application services, such as where to ins= tantiate another service instance, or which data center out of several is assigned to a new customer, can hav= e a significant impact on the state of the network. In the same way, the ca= pabilities and state of the network can have a major impact on application = performance.

 

Cross-stratum optimization (CSO= ) is referred to the combined optimization of both the application and the = network components that aims to provide joint resource optimization, respon= siveness to quickly changing demands from/to application to/from network, enhanced service resilience using coo= perative recovery techniques, and quality of experience assurance by a bett= er use of existing network and application resources, among others.

 

The CSO involves the overall op= timization of application layer and network resources by envisioning next g= eneration architecture for interactions and exchanges between the two layer= s to improve service continuity, performance guarantees, scalability and manageability. The goal of this workshop is to= promote the research interest on the optimal integration of application an= d network resources.

 

This workshop aims to explore t= he challenges and issues faced by cloud computing and data center integrati= on with networks. Among the key areas of investigation to be discussed in t= he workshop are as follows:        =      

 

.- Application/network integrat= ion architectures and subsystems

.- Use cases, business models a= nd requirements for application/network integration

.- Control/management issues fo= r application/network integration

.- Network virtualization and i= ts impact for application/network integration

.- Network-aware application/cl= oud computing

.- Flexible and scalable networ= king solutions for distributed Data Centers

.- Joint application/network re= liability and security

.- Experimental/trial experienc= e

.- Scalability

.- Joint/shared performance and= fault monitoring

.- Multi-domain issues

 

Important Dates

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D

Paper Submission Deadline: 03 F= ebruary 2012

Paper Acceptance Notification: = 30 March 2012

Camera-ready Paper Submissions:= 13 April 2012

Tentative workshop day: 10 July= 2012 (to be confirmed)

 

Venue<= o:p>

=3D=3D=3D=3D=3D

Universidad Carlos III de Madrid, = Leganes, Spain

 =

Submision guidelines=

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Target papers should describe o= riginal and unpublished work. The submission process will be done online by= using EasyChair submission system:

http://www.easychair.org/confer= ences/?conf=3Dispa2012

choosing this workshop among th= e various workshops held in conjunction with ISPA-2012

Details on the paper format and= length will be provided soon.

 

Technical Program Committee

=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

Richard Alimi (Google, USA)

Greg Bernstein (Grotto Networki= ng, USA)

TaeSang Choi (ETRI, Korea)<= span lang=3D"EN-US">

Nicola Ciulli (Nextworks, Italy)

Oscar Gonzalez de Dios (Telef=F3ni= ca I+D, Spain)

Volker Hilt (Bell Labs, USA)

Giada Landi (Nextworks, Italy)<= o:p>

Dan Li (Huawei, China)

Thomas D. Nadeau (CA Technologi= es, USA)

Kohei Shiomoto (NTT, Japan)

Ning So (Verizon, USA)

Hui Yang (Beijing University Po= st and Telecommunication (BUPT), China)

Yang Richard Yang (Yale Univers= ity, USA)

 

Workshop Organizing Committee

=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=

Young Lee, Huawei Technologies = (leeyoung (at) huawei.com)

Luis M. Contreras, Telef=F3nica I&= #43;D (lmcm (at) tid.es)

Andrea Fumagalli, The Universit= y of Texas at Dallas (andreaf (at) utdallas.edu)

 

______________

Young Lee<= /span>

Huawei Tec= hnologies

--Boundary_(ID_PfhlS6VFtnqqrw/iwOS5rA)-- --Boundary_(ID_sfy6nDGg2t23mnxaQcRvjw) Content-id: <2A17FB6C54FC5E48B6CBFBEA7C816569@huawei.com> Content-type: text/plain; name=ATT00001.txt Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=ATT00001.txt; size=127; creation-date="Thu, 22 Dec 2011 00:00:19 GMT"; modification-date="Thu, 22 Dec 2011 00:00:19 GMT" Content-description: ATT00001.txt _______________________________________________ alto mailing list alto@ietf.org https://www.ietf.org/mailman/listinfo/alto --Boundary_(ID_sfy6nDGg2t23mnxaQcRvjw)-- From haibin.song@huawei.com Fri Dec 23 01:07:59 2011 Return-Path: X-Original-To: decade@ietfa.amsl.com Delivered-To: decade@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D09F21F8B16 for ; Fri, 23 Dec 2011 01:07:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.298 X-Spam-Level: X-Spam-Status: No, score=-6.298 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_46=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15X4ZNbbOepF for ; Fri, 23 Dec 2011 01:07:57 -0800 (PST) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id C7C0421F8AF5 for ; Fri, 23 Dec 2011 01:07:56 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LWN009T8G0QYG@szxga04-in.huawei.com> for decade@ietf.org; Fri, 23 Dec 2011 17:07:38 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LWN00CTGG0QEY@szxga04-in.huawei.com> for decade@ietf.org; Fri, 23 Dec 2011 17:07:38 +0800 (CST) Received: from szxeml205-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AFX15904; Fri, 23 Dec 2011 17:07:38 +0800 Received: from SZXEML403-HUB.china.huawei.com (10.82.67.35) by szxeml205-edg.china.huawei.com (172.24.2.57) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 23 Dec 2011 17:07:30 +0800 Received: from SZXEML534-MBS.china.huawei.com ([169.254.6.210]) by szxeml403-hub.china.huawei.com ([10.82.67.35]) with mapi id 14.01.0323.003; Fri, 23 Dec 2011 17:07:28 +0800 Date: Fri, 23 Dec 2011 09:07:28 +0000 From: Songhaibin In-reply-to: X-Originating-IP: [10.138.41.129] To: ZongNing , "decade@ietf.org" Message-id: MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_VCJppA7VvI7VVOLZswsb6Q)" Content-language: zh-CN Accept-Language: en-US, zh-CN Thread-topic: Review of draft-ietf-decade-integration-example-02 Thread-index: Acy+7wATATnL0gO8RmiuICeHZYBvxgCYywAQ X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: Cc: "draft-ietf-decade-integration-example@tools.ietf.org" Subject: Re: [decade] Review of draft-ietf-decade-integration-example-02 X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Dec 2011 09:07:59 -0000 --Boundary_(ID_VCJppA7VvI7VVOLZswsb6Q) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thank you Ning for the comments. The authors please discuss/address these comments. -Haibin From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.org] On Behalf Of ZongNing Sent: Tuesday, December 20, 2011 4:12 PM To: decade@ietf.org Subject: [decade] Review of draft-ietf-decade-integration-example-02 Hi, I did a quick review of draft-ietf-decade-integration-example-02. First of all, I believe this draft provides some concrete examples of applying DECADE to existing P2P applications to achieve improved performance. I'd like to see this draft to move forward. I also have following comments & suggestions: 1) In Section 1 "Introduction", it seems that only P2P live streaming is mentioned. We should also mention file sharing application (e.g. Vuze) and Content Distribution Platform for CP; 2) In Section 2, "DECADE Module" and "DECADE Plugin" should be the same. We should merge these two definition and use one term in the whole draft. 3) In Section 2, "DECADE-Enabled Vuze" is covered by "DECADE Client". In the whole draft, we could either use two terms - "DECADE-enabled Vuze" & "DECADE-enable PPLS", or just use "DECADE Client" for general purpose. 4) I think Section 6 needs more editorial work. 5) In Section 6, I think we'd better to call it "content distribution platform for CP" rather than "ALTO+DECADE platform", as we don't focus on describing an ALTO+DECADE architecture in this draft. 6) In Section 6, we'd better to use DECADE service provider rather than ISP in Figure 4. We also need more explanation to Figure 4, as the connections are unclear, e.g. are these data or signaling links? Do we need more components such as ALTO server and content origins? 7) In Section 7, test settings for distribution platform for CP is missing, e.g. how many and which types of servers are used, which CPs are tested? 8) In Section 8, I think we'd better to give a content distribution performance example, e.g. how long to complete a content distribution, to how many users, how about the bandwidth usage? BR, Ning Zong --Boundary_(ID_VCJppA7VvI7VVOLZswsb6Q) Content-type: text/html; charset=us-ascii Content-transfer-encoding: quoted-printable

Thank y= ou Ning for the comments. The authors please discuss/address these comments= .

&n= bsp;

-Haibin=

&n= bsp;

From: decade-bounc= es@ietf.org [mailto:decade-bounces@ietf.org] On Behalf Of ZongNing
Sent: Tuesday, December 20, 2011 4:12 PM
To: decade@ietf.org
Subject: [decade] Review of draft-ietf-decade-integration-example-02=

 

Hi,

 

I did a quick review of draft-i= etf-decade-integration-example-02.

First of all, I believe this dr= aft provides some concrete examples of applying DECADE to existing P2P appl= ications to achieve improved performance. I’d like to see this draft = to move forward.

I also have following comments = & suggestions:

1= )   &= nbsp;   In Section 1 “Int= roduction”, it seems that only P2P live streaming is mentioned. We sh= ould also mention file sharing application (e.g. Vuze) and Content Distribu= tion Platform for CP;

2= )   &= nbsp;   In Section 2, “DE= CADE Module” and “DECADE Plugin” should be the same. We s= hould merge these two definition and use one term in the whole draft.<= /o:p>

3= )   &= nbsp;   In Section 2, “DE= CADE-Enabled Vuze” is covered by “DECADE Client”. In the = whole draft, we could either use two terms – “DECADE-enabled Vu= ze” & “DECADE-enable PPLS”, or just use “DECADE= Client” for general purpose.

4= )   &= nbsp;   I think Section 6 needs= more editorial work.

5= )   &= nbsp;   In Section 6, I think w= e’d better to call it “content distribution platform for CPR= 21; rather than “ALTO+DECADE platform”, as we don’t f= ocus on describing an ALTO+DECADE architecture in this draft.

6= )   &= nbsp;   In Section 6, we’= d better to use DECADE service provider rather than ISP in Figure 4. We als= o need more explanation to Figure 4, as the connections are unclear, e.g. a= re these data or signaling links? Do we need more components such as ALTO server and content origins?

7= )   &= nbsp;   In Section 7, test sett= ings for distribution platform for CP is missing, e.g. how many and which t= ypes of servers are used, which CPs are tested?

8= )   &= nbsp;   In Section 8, I think w= e’d better to give a content distribution performance example, e.g. h= ow long to complete a content distribution, to how many users, how about th= e bandwidth usage?

 

BR,

Ning Zong

 

--Boundary_(ID_VCJppA7VvI7VVOLZswsb6Q)-- From haibin.song@huawei.com Fri Dec 23 01:08:05 2011 Return-Path: X-Original-To: decade@ietfa.amsl.com Delivered-To: decade@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 070C621F8B0B for ; Fri, 23 Dec 2011 01:08:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.198 X-Spam-Level: X-Spam-Status: No, score=-6.198 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_46=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DOCfzbfiCtmG for ; Fri, 23 Dec 2011 01:08:02 -0800 (PST) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id 013E821F8B44 for ; Fri, 23 Dec 2011 01:08:02 -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 <0LWN00DEEG00J8@szxga03-in.huawei.com> for decade@ietf.org; Fri, 23 Dec 2011 17:07:12 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LWN005RYFZZW9@szxga03-in.huawei.com> for decade@ietf.org; Fri, 23 Dec 2011 17:07:12 +0800 (CST) Received: from szxeml203-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AFX15791; Fri, 23 Dec 2011 17:06:32 +0800 Received: from SZXEML409-HUB.china.huawei.com (10.82.67.136) by szxeml203-edg.china.huawei.com (172.24.2.55) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 23 Dec 2011 17:06:30 +0800 Received: from SZXEML534-MBS.china.huawei.com ([169.254.6.210]) by szxeml409-hub.china.huawei.com ([10.82.67.136]) with mapi id 14.01.0323.003; Fri, 23 Dec 2011 17:06:30 +0800 Date: Fri, 23 Dec 2011 09:06:30 +0000 From: Songhaibin In-reply-to: X-Originating-IP: [10.138.41.129] To: "Rahman, Akbar" , "decade@ietf.org" Message-id: MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_rKioleR6119aXalB8BgBuA)" Content-language: zh-CN Accept-Language: en-US, zh-CN Thread-topic: WG review of draft-ietf-decade-integration-example-02 Thread-index: AcyuZtEyTmdUAfuhRiaQ6hx2V/nY9QS6uC+g X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: Subject: Re: [decade] WG review of draft-ietf-decade-integration-example-02 X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Dec 2011 09:08:05 -0000 --Boundary_(ID_rKioleR6119aXalB8BgBuA) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Hi Akbar, Thanks for the comments. The authors please discuss/address these comments. BR, -Haibin From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.org] On Behalf Of= Rahman, Akbar Sent: Tuesday, November 29, 2011 3:17 PM To: decade@ietf.org Subject: [decade] WG review of draft-ietf-decade-integration-example-02 Hi, As per the request of the DECADE chairs in IETF 82, I did a review of the "= Integration Examples of DECADE System" (draft-ietf-decade-integration-examp= le-02) and have the following comments: =B7 Overall, I found the document very useful in providing excellen= t insights into how DECADE could be used in a real network. Also, I took i= t as a good example of "running code" for DECADE. Thanks for the good work= ! =B7 I think the document could generally be improved if the followi= ng information were added (or expanded): o Some more details of the actual protocols used in the different integra= tion scenarios should be given. For example, what were the underlying prot= ocols for the "P2P LiveStreaming Client (P2PLS)"? As an example, HTTP/TCP= are the protocols used for web browsing. What were the protocols for P2PL= S? Also some details for the protocols should be given even for the "BitTo= rrent" example. As not all readers will have knowledge of how BitTorrent w= orks. o Some more details of the file/object naming scheme used in the differen= t integration scenarios should be given. This is a critical part of DECADE= and the approached used in the experiments for naming must be given for a = complete understanding of what was done. o In the Intro (and elsewhere) there needs to be some clear references to= DECADE WG documents such as the Problem Statement, Requirements or Archite= cture (and the associated concepts defined in those documents). Note that = there can be deviations from the concepts defined in the DECADE WG document= s, but these need to be clearly explained. =B7 Some detailed comments on specific sections: o The Abstract is a bit detailed and it is hard to understand. For examp= le there should not be a list (points 1-6) in an abstract. o In section 2.9 (Remote Controller), I did not understand what "a major = operating platform" meant? o I did not understand the "limited connection slot" issue (sec. 4.2.1). = My understanding is that a DECADE client will have an association with a g= iven DECADE server, and not every other possible server. Is this the assum= ption that was used in the integration? o Editorial: The word DECADE is spelled incorrectly in Figure 2 and 3. o I did not understand the relation between a DECADE client and server in= the ALTO + DECADE integration (section 6)? Does ALTO get invoked for both= PUT and GET from a DECADE client? Or is it only for a GET? =A7 Similarly, I did not understand the Performance Analysis of the ALTO+D= ECADE Performance Analysis (section 8.2.3). o Should better define what a "small instance" is in the Amazon EC2 frame= work (section 7.2.1) o A short Conclusion section should be added to the document briefly summ= arizing the lessons learned and some suggestions for the DECADE design. As= right now the conclusions are spread over several sections. o The Security section (sec. 9) should not be empty as there must have be= en some security related assumptions in the integration. For example, was = any DECADE client able to read from any DECADE server without authenticatio= n? Yes or No? Either way this should be described. (In section 5.3, for = example, there was a reference to an "authorization token"). That's all. Akbar --Boundary_(ID_rKioleR6119aXalB8BgBuA) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: quoted-printable

Hi Akbar,

 

Thanks for the comments. The authors please discuss/address these= comments.

 

BR,

-Haibin

 

From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.o= rg] On Behalf Of Rahman, Akbar
Sent: Tuesday, November 29, 2011 3:17 PM
To: decade@ietf.org
Subject: [decade] WG review of draft-ietf-decade-integration-example= -02

 

Hi,

 

 

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

 

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

 

=B7         I think the document co= uld generally be improved if the following information were added (or expan= ded):

 =

o   Some more details of th= e actual protocols used in the different integration scenarios should be gi= ven.  For example, what were the underlying protocols for the “P= 2P LiveStreaming Client (P2PLS)”?   As an example, HTTP/TCP are the protocols used for web browsing.  What were the prot= ocols for P2PLS?  Also some details for the protocols should be given = even for the “BitTorrent” example.  As not all readers wil= l have knowledge of how BitTorrent works.

 

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

 

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

 

 =

=B7         Some detailed comments = on specific sections:

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

 

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

 

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

 =

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

 

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

<= span style=3D"mso-list:Ignore">=A7  Similarly, I did not un= derstand the Performance Analysis of the ALTO+DECADE Performance Analys= is (section 8.2.3).

 =

o   Should better define wh= at a “small instance” is in the Amazon EC2 framework (section 7= .2.1)

 =

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

 =

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

 

 

That’s all.

 

 

Akbar

--Boundary_(ID_rKioleR6119aXalB8BgBuA)-- From Akbar.Rahman@InterDigital.com Sun Dec 25 10:10:44 2011 Return-Path: X-Original-To: decade@ietfa.amsl.com Delivered-To: decade@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59A9F21F8457 for ; Sun, 25 Dec 2011 10:10:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.371 X-Spam-Level: X-Spam-Status: No, score=-2.371 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eUqJ+m9eJBJ0 for ; Sun, 25 Dec 2011 10:10:42 -0800 (PST) Received: from idcout.InterDigital.com (idcexmail.interdigital.com [12.32.197.135]) by ietfa.amsl.com (Postfix) with ESMTP id 5690521F84B3 for ; Sun, 25 Dec 2011 10:10:02 -0800 (PST) Received: from SAM.InterDigital.com ([10.30.2.11]) by idcout.InterDigital.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 25 Dec 2011 13:09:58 -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_01CCC330.69EBFA4C" Date: Sun, 25 Dec 2011 13:09:58 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Document Shepherd Write-Up for DECADE WG ID: draft-ietf-decade-reqs-05 Thread-Index: AczDMASTc/Obd9qJSeqXeCzZ8m0qywAADsBA From: "Rahman, Akbar" To: X-OriginalArrivalTime: 25 Dec 2011 18:09:58.0967 (UTC) FILETIME=[69E9AC70:01CCC330] Subject: [decade] FW: Document Shepherd Write-Up for DECADE WG ID: draft-ietf-decade-reqs-05 X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Dec 2011 18:10:44 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CCC330.69EBFA4C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable FYI=20 =20 From: Rahman, Akbar=20 Sent: Sunday, December 25, 2011 1:07 PM To: David Harrington; iesg-secretary@ietf.org Cc: Songhaibin; Woundy, Richard Subject: Document Shepherd Write-Up for DECADE WG ID: draft-ietf-decade-reqs-05 =20 =20 The DECADE WG I-D mentioned below is ready for IESG review and approval. Please find below the document shepherd write-up. I-D: DECADE Requirements /Akbar =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=3D=3D=3D=3D=3D=3D=3D=3D =20 (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the=20 document and, in particular, does he or she believe this=20 version is ready for forwarding to the IESG for publication? =20 Document shepherd: Akbar Rahman (as per request from DECADE chairs). Yes, I have personally reviewed this version of the document and I believe it is ready for IESG review and publication. =20 =20 (1.b) Has the document had adequate review both from key WG members=20 and from key non-WG members? Does the Document Shepherd have=20 any concerns about the depth or breadth of the reviews that=20 have been performed? =20 The document has had extensive reviews from both key and other WG members. I am satisfied with the depth and breadth of the reviews. =20 =20 (1.c) Does the Document Shepherd have concerns that the document=20 needs more review from a particular or broader perspective,=20 e.g., security, operational complexity, someone familiar with=20 AAA, internationalization or XML?=20 =20 I do not have concerns. The document is covering DECADE requirements and the WG has had quite extensive reviews of the document. =20 =20 (1.d) Does the Document Shepherd have any specific concerns or=20 issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he=20 or she is uncomfortable with certain parts of the document, or=20 has concerns whether there really is a need for it. In any=20 event, if the WG has discussed those issues and has indicated=20 that it still wishes to advance the document, detail those=20 concerns here. Has an IPR disclosure related to this document=20 been filed? If so, please include a reference to the=20 disclosure and summarize the WG discussion and conclusion on=20 this issue. =20 I do not have any specific concerns at this time regarding this document. The document has been presented and discussed adequately in previous WG meetings and on the mailing list.=20 I am NOT aware of any IPR disclosures related to this document. =20 =20 (1.e) How solid is the WG consensus behind this document? Does it=20 represent the strong concurrence of a few individuals, with=20 others being silent, or does the WG as a whole understand and=20 agree with it? =20 =20 There is good concurrence among active participants on the subject. I believe the majority of the WG understands the document and do not object. =20 =20 (1.f) Has anyone threatened an appeal or otherwise indicated extreme=20 discontent? If so, please summarise the areas of conflict in=20 separate email messages to the Responsible Area Director. (It=20 should be in a separate email because this questionnaire is=20 entered into the ID Tracker.) =20 No threats of appeal or extreme discontent have been expressed regarding this I-D. =20 =20 (1.g) Has the Document Shepherd personally verified that the=20 document satisfies all ID nits? (See the Internet-Drafts Checklist =20 and http://tools.ietf.org/tools/idnits/). Boilerplate checks are not enough; this check needs to be thorough. Has the document=20 met all formal review criteria it needs to, such as the MIB=20 Doctor, media type and URI type reviews?=20 =20 Yes. I have run the I-D through the ID nits tool and found no major issues. The only minor warning that I received was regarding version numbers of some informative references (see below). I believe these can be=20 fixed when any IESG comments are addressed. =20 =3D=3D Outdated reference: A later version (-04) exists of draft-ietf-decade-problem-statement-03 =20 =3D=3D Outdated reference: A later version (-04) exists of draft-ietf-decade-arch-02 =20 =20 (1.h) Has the document split its references into normative and=20 informative? Are there normative references to documents that=20 are not ready for advancement or are otherwise in an unclear=20 state? If such normative references exist, what is the=20 strategy for their completion? Are there normative references=20 that are downward references, as described in [RFC3967]? If=20 so, list these downward references to support the Area=20 Director in the Last Call procedure for them [RFC3967].=20 =20 References are split into normative and informative sections. The normative references are published RFCs. =20 =20 (1.i) Has the Document Shepherd verified that the document IANA=20 consideration section exists and is consistent with the body=20 of the document? If the document specifies protocol=20 extensions, are reservations requested in appropriate IANA=20 registries? Are the IANA registries clearly identified? If=20 the document creates a new registry, does it define the=20 proposed initial contents of the registry and an allocation=20 procedure for future registrations? Does it suggest a=20 reasonable name for the new registry? See [RFC5226]. If the=20 document describes an Expert Review process has Shepherd=20 conferred with the Responsible Area Director so that the IESG=20 can appoint the needed Expert during the IESG Evaluation? =20 Yes, I have verified the IANA Considerations Section. There are no IANA impacts as this is a Requirements document =20 =20 (1.j) Has the Document Shepherd verified that sections of the=20 document that are written in a formal language, such as XML=20 code, BNF rules, MIB definitions, etc., validate correctly in=20 an automated checker? =20 Not applicable. =20 =20 (1.k) The IESG approval announcement includes a Document=20 Announcement Write-Up. Please provide such a Document=20 Announcement Write-Up? Recent examples can be found in the "Action" announcements for approved documents. The approval=20 announcement contains the following sections: =20 Technical Summary=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 (peer-to-peer) applications, to store, retrieve and manage their data. This draft enumerates and explains requirements, not only for storage and retrieval, but also for data management, access control and resource control, that should be considered during the design and implementation of a DECADE system. These are requirements on the entire system; some of the requirements may eventually be implemented by an existing protocol with/without some extensions (e.g., a protocol used to read and write data from the storage system). The requirements in this document are intended to ensure that the DECADE architecture includes all of the desired functionality for intended applications. =20 =20 Working Group Summary=20 Was there anything in WG process that is worth noting? For=20 example, was there controversy about particular points or=20 were there decisions where the consensus was particularly=20 rough?=20 =20 There is support in the WG to advance this work. There has not been any major controversy. =20 =20 Document Quality=20 Are there existing implementations of the protocol? Have a=20 significant number of vendors indicated their plan to=20 implement the specification? =20 This is a requirements document for the DECADE protocol. There is no DECADE protocol I-D specified yet. So there is no existing implementations of DECADE. However, there have been some early experimental work by the research community in the space of DECADE type in-network storage as, for example, captured by:=20 =20 http://datatracker.ietf.org/doc/draft-ietf-decade-integration-example/ =20 =20 =20 =20 ------_=_NextPart_001_01CCC330.69EBFA4C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

FYI

 

From:= = Rahman, Akbar
Sent: Sunday, December 25, 2011 1:07 = PM
To: David Harrington; iesg-secretary@ietf.org
Cc: = Songhaibin; Woundy, Richard
Subject: Document Shepherd = Write-Up for DECADE WG ID: = draft-ietf-decade-reqs-05

 

  

The DECADE WG I-D mentioned below = is ready for IESG review and approval.
Please find below the = document shepherd write
-up.

I-D: =
DECADE = Requirements
   &nb= sp; <
draft-ietf-decade-reqs-05>

/Akbar
 
=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=3D=3D=3D=3D=3D=3D=3D=
=3D
 
  (1.a) Who is the Document Shepherd for this =
document? Has the
        =
Document Shepherd personally reviewed this version of the =
        doc=
ument and, in particular, does he or she believe this =
        ver=
sion is ready for forwarding to the IESG for =
publication?
 
Document shepherd: Akbar Rahman (as per =
request from DECADE chairs).
Yes, I have personally reviewed this = version of the document and I believe it is
ready for IESG review and = publication.
 
 
  (1.b) Has the document had adequate =
review both from key WG members 
        and=
 from key non-WG members? Does the Document Shepherd have =
        any=
 concerns about the depth or breadth of the reviews that =
        hav=
e been performed?
 
The document has had extensive reviews =
from both key and other WG members.
I am satisfied with the depth and = breadth of the reviews.
 
  
  (1.c) Does the Document Shepherd have =
concerns that the document 
        nee=
ds more review from a particular or broader perspective, =
        e.g=
., security, operational complexity, someone familiar with =
        AAA=
, internationalization or XML? 
 
I do not have concerns.  The =
document is covering DECADE requirements =
and
the WG has had quite =
extensive reviews of the document.
 
 
  (1.d) Does the Document Shepherd have any =
specific concerns or 
        iss=
ues with this document that the Responsible Area =
Director
        and/or =
the IESG should be aware of? For example, perhaps he =
        or =
she is uncomfortable with certain parts of the document, or =
        has=
 concerns whether there really is a need for it. In any =
        eve=
nt, if the WG has discussed those issues and has indicated =
        tha=
t it still wishes to advance the document, detail those =
        con=
cerns here. Has an IPR disclosure related to this document =
        bee=
n filed? If so, please include a reference to the =
        dis=
closure and summarize the WG discussion and conclusion on =
        thi=
s issue.
 
I do not have any specific concerns at =
this time regarding this document.
The document has been presented = and discussed adequately in previous = WG
meetings and on the mailing list. =


I am NOT aware of any IPR disclosures related to this = document.
 
 
  (1.e) How solid is the WG consensus =
behind this document? Does it 
        rep=
resent the strong concurrence of a few individuals, with =
        oth=
ers being silent, or does the WG as a whole understand and =
        agr=
ee with it?   
 
There is good concurrence among active =
participants on the subject.
I believe the majority of the WG =
understands the document and do not object.
 
 
  (1.f) Has anyone threatened an appeal or =
otherwise indicated extreme 
        dis=
content? If so, please summarise the areas of conflict in =
        sep=
arate email messages to the Responsible Area Director. (It =
        sho=
uld be in a separate email because this questionnaire is =
        ent=
ered into the ID Tracker.)
 
No threats of appeal or extreme =
discontent have been expressed
regarding this = I-D.
 
 
  (1.g) Has the Document Shepherd =
personally verified that the 
        doc=
ument satisfies all ID nits? (See the Internet-Drafts =
Checklist 
        and=
 http://tools.ietf.org/tools/=
idnits/). Boilerplate checks are 
        not=
 enough; this check needs to be thorough. Has the document =
        met=
 all formal review criteria it needs to, such as the MIB =
        Doc=
tor, media type and URI type reviews? 
 
Yes. I have run the I-D through the ID =
nits tool and found no major issues.
The only minor warning that I =
received was regarding version numbers
of some informative =
references (see below).  I believe these can be =
fixed when any IESG comments =
are addressed.

 <= /p>

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

     = draft-ietf-decade-problem-statement-03

 <= /p>

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

     = draft-ietf-decade-arch-02

 

 
  (1.h) Has the document split its references =
into normative and 
        inf=
ormative? Are there normative references to documents that =
        are=
 not ready for advancement or are otherwise in an unclear =
        sta=
te? If such normative references exist, what is the =
        str=
ategy for their completion? Are there normative references =
        tha=
t are downward references, as described in [RFC3967]? If =
        so,=
 list these downward references to support the Area =
        Dir=
ector in the Last Call procedure for them [RFC3967]. =
 
References are split into normative and =
informative sections.
The normative references are published = RFCs.
 
 
  (1.i) Has the Document Shepherd verified =
that the document IANA 
        con=
sideration section exists and is consistent with the body =
        of =
the document? If the document specifies protocol =
        ext=
ensions, are reservations requested in appropriate IANA =
        reg=
istries? Are the IANA registries clearly identified? If =
        the=
 document creates a new registry, does it define the =
        pro=
posed initial contents of the registry and an allocation =
        pro=
cedure for future registrations? Does it suggest a =
        rea=
sonable name for the new registry? See [RFC5226]. If the =
        doc=
ument describes an Expert Review process has Shepherd =
        con=
ferred with the Responsible Area Director so that the IESG =
        can=
 appoint the needed Expert during the IESG =
Evaluation?
 
Yes, I have verified the IANA =
Considerations Section.  There are =
no
IANA =
impacts as this is a Requirements =
document
 
 
  (1.j) Has the Document Shepherd =
verified that sections of the 
        doc=
ument that are written in a formal language, such as XML =
        cod=
e, BNF rules, MIB definitions, etc., validate correctly in =
        an =
automated checker?
 
Not =
applicable.
 
 
  (1.k) The IESG approval announcement =
includes a Document 
        Ann=
ouncement Write-Up. Please provide such a Document =
        Ann=
ouncement Write-Up? Recent examples can be found in =
the
        =
"Action" announcements for approved documents. The approval =
        ann=
ouncement contains the following =
sections:
 =
     Technical Summary =

 

The target of DECoupled = Application Data Enroute (DECADE) is to

provide an open and = standard in-network storage system for

applications, primarily = P2P (peer-to-peer) applications, to store,

retrieve and manage = their data.  This draft enumerates and = explains

requirements, not only = for storage and retrieval, but also for data

management, access = control and resource control, that should be

considered during the = design and implementation of a DECADE system.

These are requirements = on the entire system; some of the requirements

may eventually be = implemented by an existing protocol with/without

some extensions (e.g., a = protocol used to read and write data from

the storage = system).  The requirements in this document are = intended

to ensure that the = DECADE architecture includes all of the desired

functionality for = intended applications.

 

 
     Working Group Summary =
        Was=
 there anything in WG process that is worth noting? For =
        exa=
mple, was there controversy about particular points or =
        wer=
e there decisions where the consensus was particularly =
        rou=
gh? 
 
There is support in the WG to advance =
this work. There has not been any
major controversy.
 
 
     Document Quality =
        Are=
 there existing implementations of the protocol? Have a =
        sig=
nificant number of vendors indicated their plan to =
        imp=
lement the specification?

 

This is a requirements document for the =
DECADE protocol.  There is no
DECADE protocol I-D specified yet.  =
So there is no existing =
implementations
of DECADE.  However, there have been =
some early experimental work by
the research community in the space of =
DECADE type in-network storage
as, for example, captured by: =
 
http://datatracker.ietf.org/doc/draft-ietf-decade-integration-exam=
ple/
 

 

 

 

------_=_NextPart_001_01CCC330.69EBFA4C-- From trac+decade@trac.tools.ietf.org Sun Dec 25 10:36:23 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 7E3DD21F84A6 for ; Sun, 25 Dec 2011 10:36:23 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nZjvnfGYnnpN for ; Sun, 25 Dec 2011 10:36:22 -0800 (PST) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 5706321F84A2 for ; Sun, 25 Dec 2011 10:36:21 -0800 (PST) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1ResvF-0006pC-E6; Sun, 25 Dec 2011 13:35:49 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "decade issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-decade-reqs@tools.ietf.org, akbar.rahman@interdigital.com X-Trac-Project: decade Date: Sun, 25 Dec 2011 18:35:49 -0000 X-URL: http://tools.ietf.org/decade/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/decade/trac/ticket/1 Message-ID: <070.240ab73ad34a03ca79be0e7d044066b5@trac.tools.ietf.org> X-Trac-Ticket-ID: 1 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-decade-reqs@tools.ietf.org, akbar.rahman@interdigital.com, decade@ietf.org X-SA-Exim-Mail-From: trac+decade@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Resent-To: Resent-Message-Id: <20111225183622.5706321F84A2@ietfa.amsl.com> Resent-Date: Sun, 25 Dec 2011 10:36:21 -0800 (PST) Resent-From: trac+decade@trac.tools.ietf.org X-Mailman-Approved-At: Sun, 25 Dec 2011 17:44:48 -0800 Cc: decade@ietf.org Subject: [decade] #1: Document Shepherd Write-UP X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 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, 25 Dec 2011 18:36:23 -0000 #1: Document Shepherd Write-UP The DECADE WG I-D mentioned below is ready for IESG review and approval. Please find below the document shepherd write-up. I-D: DECADE Requirements /Akbar ==================================================================== (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? Document shepherd: Akbar Rahman (as per request from DECADE chairs). Yes, I have personally reviewed this version of the document and I believe it is ready for IESG review and publication. (1.b) Has the document had adequate review both from key WG members and from key non-WG members? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? The document has had extensive reviews from both key and other WG members. I am satisfied with the depth and breadth of the reviews. (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization or XML? I do not have concerns. The document is covering DECADE requirements and the WG has had quite extensive reviews of the document. (1.d) Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. Has an IPR disclosure related to this document been filed? If so, please include a reference to the disclosure and summarize the WG discussion and conclusion on this issue. I do not have any specific concerns at this time regarding this document. The document has been presented and discussed adequately in previous WG meetings and on the mailing list. I am NOT aware of any IPR disclosures related to this document. (1.e) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? There is good concurrence among active participants on the subject. I believe the majority of the WG understands the document and do not object. (1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is entered into the ID Tracker.) No threats of appeal or extreme discontent have been expressed regarding this I-D. (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See the Internet-Drafts Checklist and http://tools.ietf.org/tools/idnits/). Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type and URI type reviews? Yes. I have run the I-D through the ID nits tool and found no major issues. The only minor warning that I received was regarding version numbers of some informative references (see below). I believe these can be fixed when any IESG comments are addressed. == Outdated reference: A later version (-04) exists of draft-ietf-decade-problem-statement-03 == Outdated reference: A later version (-04) exists of draft-ietf-decade-arch-02 (1.h) Has the document split its references into normative and informative? Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the strategy for their completion? Are there normative references that are downward references, as described in [RFC3967]? If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967]. References are split into normative and informative sections. The normative references are published RFCs. (1.i) Has the Document Shepherd verified that the document IANA consideration section exists and is consistent with the body of the document? If the document specifies protocol extensions, are reservations requested in appropriate IANA registries? Are the IANA registries clearly identified? If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? Does it suggest a reasonable name for the new registry? See [RFC5226]. If the document describes an Expert Review process has Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during the IESG Evaluation? Yes, I have verified the IANA Considerations Section. There are no IANA impacts as this is a Requirements document (1.j) Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker? Not applicable. (1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up? Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary The target of DECoupled Application Data Enroute (DECADE) is to provide an open and standard in-network storage system for applications, primarily P2P (peer-to-peer) applications, to store, retrieve and manage their data. This draft enumerates and explains requirements, not only for storage and retrieval, but also for data management, access control and resource control, that should be considered during the design and implementation of a DECADE system. These are requirements on the entire system; some of the requirements may eventually be implemented by an existing protocol with/without some extensions (e.g., a protocol used to read and write data from the storage system). The requirements in this document are intended to ensure that the DECADE architecture includes all of the desired functionality for intended applications. Working Group Summary Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? There is support in the WG to advance this work. There has not been any major controversy. Document Quality Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? This is a requirements document for the DECADE protocol. There is no DECADE protocol I-D specified yet. So there is no existing implementations of DECADE. However, there have been some early experimental work by the research community in the space of DECADE type in-network storage as, for example, captured by: http://datatracker.ietf.org/doc/draft-ietf-decade-integration-example/ -- ----------------------------+-------------------------------------- Reporter: akbar.rahman@… | Owner: draft-ietf-decade-reqs@… Type: task | Status: new Priority: minor | Milestone: Component: reqs | Version: Severity: - | Keywords: ----------------------------+-------------------------------------- Ticket URL: decade