From strufe.pub@googlemail.com Mon Oct 12 10:20:24 2009 Return-Path: X-Original-To: decade@core3.amsl.com Delivered-To: decade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4033C28C24F for ; Mon, 12 Oct 2009 10:20:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SaWqG0+tJ3Gq for ; Mon, 12 Oct 2009 10:20:23 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.153]) by core3.amsl.com (Postfix) with ESMTP id CDC483A67A6 for ; Mon, 12 Oct 2009 10:20:19 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id 19so815757fgg.13 for ; Mon, 12 Oct 2009 10:20:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:content-type :content-transfer-encoding; bh=UBF2jwRXLPJ6TkVEEemtiGkURKMYe84HqX2CsTfuK4w=; b=Mk6DtntA9pt9rc4rVgmH0ZFgV9jGGikRtwIQ1geb05USYT/cF2I1jdHXN8D7E26fH0 7seeN7VNR84XDxtUZr1MOrMtf/32ocHF/WKQTfFDmTrcsL+xtMhTh2YSsvHhYY1cnnqp B5Z9SQJRLd2t9Nb/Zpyx/qBNXGKyrP1H+Naqw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; b=sD1q1uzh3efBP53Ha0Yi10+C+Mbc3x6xkwGqc1Lj+leGvGNTuZ5fwm1pMk5+EVyxWf m6Sl9TDVID0dWE8kS+SBzTDeT06mFOU2gENPK/3H2wM1PJ/tnaiQ83yNnmju8PK0jngd fwvzMvnazmYaOSWxnciF0VDiqe4HjB470Bpes= Received: by 10.86.231.15 with SMTP id d15mr5430036fgh.74.1255368016181; Mon, 12 Oct 2009 10:20:16 -0700 (PDT) Received: from ?130.83.163.220? (dyn28.tk.informatik.tu-darmstadt.de [130.83.163.220]) by mx.google.com with ESMTPS id e20sm23336fga.15.2009.10.12.10.20.15 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 12 Oct 2009 10:20:15 -0700 (PDT) Message-ID: <4AD36547.9050800@gmail.com> Date: Mon, 12 Oct 2009 19:20:07 +0200 From: Thorsten Strufe User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: decade@ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Subject: [decade] Only 6 days left! CfP: PerCom Workshop on Security and Social Networking (SESOC) X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Oct 2009 17:20:24 -0000 [ apologies for cross-posting ] [ please circulate to interested researchers ] |-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=| ( ( ) SESOC 2010 ) ( ( ) International Workshop on ) ( SECurity and SOCial Networking ( ) ) ( March 29 / April 2 2010 ( ) Mannheim, Germany ) ( (as part of IEEE PerCom 2010) ( ) ) ( http://www.sesoc.org ( ) ) |-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=| Future pervasive communication systems aim at supporting social and collaborative communications: the evolving topologies are expected to resemble the actual social networks of the communicating users and information on their characteristics can be a powerful aid for any network operation. New emerging technologies that use information on the social characteristics of their participants raise entirely new privacy concerns and require new reflections on security problems such as trust establishment, cooperation enforcement or key management. The aim of this workshop is to encompass research advances in all areas of security, trust and privacy in pervasive communication systems, integrating the social structure of the network as well. ============================= Topics of Interest ============================= - new aspects of trust - privacy concerns - availability and resilience - community based secure communication - data confidentiality, data integrity - anonymity, pseudonymity - key management - secure bootstrapping - security issues in forwarding, routing - security aspects regarding cooperation - new reputation systems - new attack paradigms - new requirements for software security - malware The key note: “Threats to the Social Web”, will be given by Ryan McGeehan [1] of facebook Inc. It deals with real world threats against the social web and highlights the perspective of the provider of one of the largest online social networks of today. ============================= Important Dates ============================= Submission deadline: October 18, 2009 Notification date: December 21, 2010 Camera ready submission: January 29, 2010 ============================= Submission instructions ============================= Submitted papers must be unpublished and not considered elsewhere for publication. Camera-ready versions of accepted papers will be limited to 6 pages in IEEE 8.5x11 conference format, and formatted in accordance with the IEEE Computer Society author guidelines. The link for the templates and further guidelines for preparing and submitting the manuscript are available on the workshop website. All papers are managed electronically through easychair, the submission website is: http://www.easychair.org/conferences/?conf=sesoc2010 Submitted papers will undergo a rigorous and double-blind review process handled by the Technical Program Committee. Authors' names must not appear in the paper. All accepted papers need to have a full registration to the PerCom 2010 Conference (There is no workshop only registration). Moreover, no-shows of accepted papers at the workshop will result in those papers not being included in the IEEE Digital Library. ============================= Committee ============================= General Chairs: Refik Molva EURECOM, France Gene Tsudik University of California Irvine, USA Organizing Chairs: Melek Önen EURECOM, France Thorsten Strufe Technische Universität Darmstadt, Germany Technical Program Committee: Imad Aad Nokia, Switzerland Davide Balzarotti EURECOM, France Erik-Oliver Blass EURECOM, France Jens-Matthias Bohli NEC Europe, Germany Michael Brinkmeier TU Ilmenau, Germany Sonja Buchegger Deutsche Telekom Laboratories, Germany Levente Buttyán BUTE, Hungary Claude Castelluccia INRIA, France Lorenzo Cavallaro UCSB, USA Ahmet Çamtepe TU Berlin, Germany Mauro Conti Vrije Universiteit, The Netherlands Jon Crowcroft Computer Lab Cambridge University, UK Marc Dacier Symantec Europe, France Anwitaman Datta NTU, Singapore Roberto Di Pietro Università di Roma, La Sapenzia, Italy Alexander Eichhorn Simula, Norway Stephen Farrell NewBay Software, Ireland Artur Hecker Telecom ParisTech, France Sotiris Ioannidis FORTH, Greece Stefan Katzenbeisser CASED, Germany Albert Levi Sabanci University, Turkey Mark Manulis CASED, Germany Jörn Müller-Quade Uni Karlsruhe, Germany Guevara Noubir North Eastern University, USA Christian Rohner Uppsala Universitet, Sweden Günter Schäfer TU Ilmenau, Germany Dirk Westhoff NEC Europe, Germany [1] Bio: Ryan McGeehan is the Security Manager for Incident Response at Facebook. He has been at Facebook since early 2007 (~40 million users), and is responsible for research and response into threats to Facebook. He is also involved with the Honeynet Project with research around web application threats and honeypot development. -- Thorsten Strufe Peer-to-Peer Networks Technische Universität Darmstadt http://www.p2p.tu-darmstadt.de/ From melodysong@huawei.com Thu Oct 15 19:07:57 2009 Return-Path: X-Original-To: decade@core3.amsl.com Delivered-To: decade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A434528C16E for ; Thu, 15 Oct 2009 19:07:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.994 X-Spam-Level: X-Spam-Status: No, score=0.994 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u4u7XHFheAUj for ; Thu, 15 Oct 2009 19:07:57 -0700 (PDT) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id C160028C12C for ; Thu, 15 Oct 2009 19:07:56 -0700 (PDT) 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 <0KRL00BVL4KXRG@szxga04-in.huawei.com> for decade@ietf.org; Fri, 16 Oct 2009 10:07:45 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KRL00LU64KXE0@szxga04-in.huawei.com> for decade@ietf.org; Fri, 16 Oct 2009 10:07:45 +0800 (CST) Received: from s64081 ([10.164.12.29]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KRL00HOG4KXAX@szxml04-in.huawei.com> for decade@ietf.org; Fri, 16 Oct 2009 10:07:45 +0800 (CST) Date: Fri, 16 Oct 2009 10:07:41 +0800 From: Song Haibin To: decade@ietf.org Message-id: <00bd01ca4e05$718b7b90$1d0ca40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcpOA98y5le93EERRrmYJYZUAax+xwAADKSg Subject: [decade] Notification for draft-song-decade-problem-statement-00 X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2009 02:07:57 -0000 Hi all, We just submit the DECADE problem statement draft. Any comments are appreciated! Abstract: Peer-to-peer (P2P) applications have become widely used on the Internet today and make up a large portion of the traffic in many networks. In P2P applications, one technique for reducing the total amount of P2P traffic is to introduce storage capabilities within the network. Traditional caches (e.g., P2P and Web caches) provide such storage, but they are complex (due to explicitly supporting individual P2P application protocols) and they do not allow users to manage access to content in the cache. For example, Content Providers cannot easily control access and resource usage policies to satisfy their own requirements. This document discusses the introduction of in-network storage for P2P applications, shows the need for a standard protocol for accessing this storage, and identifies the scope of this protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-song-decade-problem-statement-00.t xt Best Regards, Haibin From guyingjie@huawei.com Mon Oct 19 19:28:38 2009 Return-Path: X-Original-To: decade@core3.amsl.com Delivered-To: decade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F11F3A67E2 for ; Mon, 19 Oct 2009 19:28:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.513 X-Spam-Level: X-Spam-Status: No, score=-0.513 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bFvjLcRZrMk5 for ; Mon, 19 Oct 2009 19:28:37 -0700 (PDT) Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id 755AB3A672F for ; Mon, 19 Oct 2009 19:28:37 -0700 (PDT) Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KRS000CLK7KLO@szxga02-in.huawei.com> for decade@ietf.org; Tue, 20 Oct 2009 10:28:32 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KRS00MRUK7KFF@szxga02-in.huawei.com> for decade@ietf.org; Tue, 20 Oct 2009 10:28:32 +0800 (CST) Received: from g00107907 ([10.164.12.64]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KRS00FVNK7JDG@szxml04-in.huawei.com> for decade@ietf.org; Tue, 20 Oct 2009 10:28:32 +0800 (CST) Date: Tue, 20 Oct 2009 10:28:30 +0800 From: "Y.J. Gu" To: decade@ietf.org Message-id: <001f01ca512d$039c17e0$400ca40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcpQoQ4Z3dull/fTRzWKnXAwfhRhlQAiuR1A Subject: [decade] Notification for draft-gu-decade-reqs-00 X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2009 02:28:38 -0000 Hi everybody, We submitted a draft about DECADE requirements. Abstract: DECoupled Application Data Enroute (DECADE) is going to develop a protocol that is used by a P2P application client to control its shared resource in the in-network storage, as well as store/retrieve the resource to/from the in-network storage. This document enumerates requirements for this protocol, which should be considered when designing and implementation. Regards Yingjie Gu From guyingjie@huawei.com Mon Oct 19 19:42:28 2009 Return-Path: X-Original-To: decade@core3.amsl.com Delivered-To: decade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C75D53A681D for ; Mon, 19 Oct 2009 19:42:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.698 X-Spam-Level: X-Spam-Status: No, score=-0.698 tagged_above=-999 required=5 tests=[AWL=0.185, BAYES_05=-1.11, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QwWkrnT9nL8w for ; Mon, 19 Oct 2009 19:42:28 -0700 (PDT) Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id E9B743A67FA for ; Mon, 19 Oct 2009 19:42:27 -0700 (PDT) Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KRS000MFKUXLO@szxga02-in.huawei.com> for decade@ietf.org; Tue, 20 Oct 2009 10:42:33 +0800 (CST) Received: from huawei.com ([172.24.1.33]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KRS00MY7KUXFF@szxga02-in.huawei.com> for decade@ietf.org; Tue, 20 Oct 2009 10:42:33 +0800 (CST) Received: from g00107907 ([10.164.12.64]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KRS00KN5KUX0S@szxml06-in.huawei.com> for decade@ietf.org; Tue, 20 Oct 2009 10:42:33 +0800 (CST) Date: Tue, 20 Oct 2009 10:42:32 +0800 From: "Y.J. Gu" In-reply-to: <001f01ca512d$039c17e0$400ca40a@china.huawei.com> To: decade@ietf.org Message-id: <002001ca512e$f9ad9a90$400ca40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcpQoQ4Z3dull/fTRzWKnXAwfhRhlQAiuR1AAAB6JUA= Subject: Re: [decade] Notification for draft-gu-decade-reqs-00 X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2009 02:42:29 -0000 The URL for this draft is : http://www.ietf.org/id/draft-gu-decade-reqs-00.txt We appreciate your comments. Thanks. Regards Yingjie Gu > -----Original Message----- > From: decade-bounces@ietf.org > [mailto:decade-bounces@ietf.org] On Behalf Of Y.J. Gu > Sent: Tuesday, October 20, 2009 10:29 AM > To: decade@ietf.org > Subject: [decade] Notification for draft-gu-decade-reqs-00 > > Hi everybody, > > We submitted a draft about DECADE requirements. > > Abstract: > DECoupled Application Data Enroute (DECADE) is going to > develop a protocol that is used by a P2P application client > to control its shared resource in the in-network storage, as > well as store/retrieve the resource to/from the in-network > storage. This document enumerates requirements for this > protocol, which should be considered when designing and > implementation. > > Regards > > Yingjie Gu > > > > _______________________________________________ > decade mailing list > decade@ietf.org > https://www.ietf.org/mailman/listinfo/decade From guyingjie@huawei.com Wed Oct 21 02:50:37 2009 Return-Path: X-Original-To: decade@core3.amsl.com Delivered-To: decade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 755443A6A03 for ; Wed, 21 Oct 2009 02:50:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.114 X-Spam-Level: X-Spam-Status: No, score=-0.114 tagged_above=-999 required=5 tests=[AWL=-0.586, BAYES_20=-0.74, SARE_OBFU_PART_IVE=0.985, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id trPMJk0I+TRP for ; Wed, 21 Oct 2009 02:50:36 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id A8CBD3A69F3 for ; Wed, 21 Oct 2009 02:50:36 -0700 (PDT) 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 <0KRU002FXZCJ7W@szxga03-in.huawei.com> for decade@ietf.org; Wed, 21 Oct 2009 17:50:43 +0800 (CST) Received: from huawei.com ([172.24.1.33]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KRU009E0ZCJV4@szxga03-in.huawei.com> for decade@ietf.org; Wed, 21 Oct 2009 17:50:43 +0800 (CST) Received: from g00107907 ([10.164.12.64]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KRU00K5NZCI6J@szxml06-in.huawei.com> for decade@ietf.org; Wed, 21 Oct 2009 17:50:43 +0800 (CST) Date: Wed, 21 Oct 2009 17:50:42 +0800 From: "Y.J. Gu" In-reply-to: <00bd01ca4e05$718b7b90$1d0ca40a@china.huawei.com> To: decade@ietf.org Message-id: <003701ca5233$f422ede0$400ca40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcpOA98y5le93EERRrmYJYZUAax+xwAADKSgAQuf6BA= Subject: [decade] Notification of updated version for draft-gu-decade-reqs X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2009 09:50:37 -0000 Hi all, We have updated the requirement draft (draft-gu-decade-reqs) to -01version. The URL for this internet-draft is http://www.ietf.org/id/draft-gu-decade-reqs-01.txt We made editorial revision and also made changes to some functional requirements. We appreciate your comments on the draft. Regards Yingjie Gu From melodysong@huawei.com Thu Oct 22 19:59:49 2009 Return-Path: X-Original-To: decade@core3.amsl.com Delivered-To: decade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D19333A689F for ; Thu, 22 Oct 2009 19:59:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.765 X-Spam-Level: * X-Spam-Status: No, score=1.765 tagged_above=-999 required=5 tests=[AWL=-0.340, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UxWFiiJg7Uls for ; Thu, 22 Oct 2009 19:59:49 -0700 (PDT) Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id 188A53A683B for ; Thu, 22 Oct 2009 19:59:49 -0700 (PDT) Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KRY00CRB5NLQ9@szxga01-in.huawei.com> for decade@ietf.org; Fri, 23 Oct 2009 10:59:45 +0800 (CST) Received: from huawei.com ([172.24.1.33]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KRY00IFK5NL5R@szxga01-in.huawei.com> for decade@ietf.org; Fri, 23 Oct 2009 10:59:45 +0800 (CST) Received: from s64081 ([10.164.12.29]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KRY002DH5NKUN@szxml06-in.huawei.com> for decade@ietf.org; Fri, 23 Oct 2009 10:59:45 +0800 (CST) Date: Fri, 23 Oct 2009 10:59:44 +0800 From: Song Haibin To: decade@ietf.org Message-id: <00f401ca538c$dfeb7f40$1d0ca40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcpTjN+o8YZHEBTITVeQG3S4yyp3hQ== Subject: [decade] DECADE BOF session at IETF 76 will be on Thursday 9am X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Oct 2009 02:59:49 -0000 Hi all, For your information, DECADE BOF has been scheduled on Thursday 9am, in the Room Cattleya East. Please make it in your agenda if you are going to attend this BOF. See you in Hiroshima. Best Regards, Haibin Skype: alexsonghw From lin.xiao@nsn.com Tue Oct 27 02:55:29 2009 Return-Path: X-Original-To: decade@core3.amsl.com Delivered-To: decade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 710BE28C1D4 for ; Tue, 27 Oct 2009 02:55:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.845 X-Spam-Level: X-Spam-Status: No, score=-1.845 tagged_above=-999 required=5 tests=[AWL=0.755, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K19GU-PSdB4M for ; Tue, 27 Oct 2009 02:55:28 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id 0D5E828C179 for ; Tue, 27 Oct 2009 02:55:27 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n9R9taaL008475 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 27 Oct 2009 10:55:36 +0100 Received: from demuexc023.nsn-intra.net (demuexc023.nsn-intra.net [10.150.128.36]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n9R9tZOE029977; Tue, 27 Oct 2009 10:55:36 +0100 Received: from CNBEEXC007.nsn-intra.net ([10.159.192.12]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 27 Oct 2009 10:55:35 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 27 Oct 2009 17:55:32 +0800 Message-ID: <5D84FDD8D5DC8646B9F73CF1EFD1BFA4DC4EFC@CNBEEXC007.nsn-intra.net> In-Reply-To: <00bd01ca4e05$718b7b90$1d0ca40a@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [decade] Notification for draft-song-decade-problem-statement-00 Thread-Index: AcpOA98y5le93EERRrmYJYZUAax+xwAADKSgAje0FaA= From: "Xiao, Lin (NSN - CN/Beijing)" To: "ext Song Haibin" , X-OriginalArrivalTime: 27 Oct 2009 09:55:35.0784 (UTC) FILETIME=[A15A6680:01CA56EB] Subject: Re: [decade] Notification for draft-song-decade-problem-statement-00 X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2009 09:55:29 -0000 Hi Haibin, Well done. It's a good base for further discussion of DECADE. There are some comments from my side.=20 1. In section 3.1, you compared the DECADE to ALTO. IMHO, The need of DECADE besides ALTO is that the tree like underlayer network topology is widely implemented for access network. ALTO does solve the unnecessary backbone transit and localize the traffic with topology information. If the access network has mesh connection, it seems that ALTO can solve the traffic optimization alone. The problem here is that most access networks have tree like topology, so that even local traffics between selected peers by ALTO must go through some center point which give chance for DECADE to do further optimization. So, the key here is the unmatched overlay topology with the tree like underlayer topology. 2. In section 3.2, you regards cache as complex storage. However, if the cache is only for one P2P application, where it is looked as a peer for the application, I don't think the whole protocol could be more complex. The key here, I think, is that if we use a single cache server for multiple applications, the complexity is increased. That's why we need a application independent storage. 3. In section 3.3, I'm not sure what you mean here. Do you mean the storage will also take part in the peer selection as a peer with good performance? IMHO, the storage and DECADE protocol should be totally invisible from the P2P application. But if you mean the deployment position of the storage (considering the underlayer topology and bandwidth structure) can help traffic optimization, I think, section 3.1 should have already mentioned it. The last question is that do we really need include solutions and detailed usage scenarios in a problem statement draft. Br Xiao, Lin -----Original Message----- From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.org] On Behalf Of ext Song Haibin Sent: Friday, October 16, 2009 10:08 AM To: decade@ietf.org Subject: [decade] Notification for draft-song-decade-problem-statement-00 Hi all, We just submit the DECADE problem statement draft. Any comments are appreciated! Abstrac Peer-to-peer (P2P) applications have become widely used on the Internet today and make up a large portion of the traffic in many networks. In P2P applications, one technique for reducing the total amount of P2P traffic is to introduce storage capabilities within the network. Traditional caches (e.g., P2P and Web caches) provide such storage, but they are complex (due to explicitly supporting individual P2P application protocols) and they do not allow users to manage access to content in the cache. For example, Content Providers cannot easily control access and resource usage policies to satisfy their own requirements. This document discusses the introduction of in-network storage for P2P applications, shows the need for a standard protocol for accessing this storage, and identifies the scope of this protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-song-decade-problem-statement- 00.t xt Best Regards, Haibin _______________________________________________ decade mailing list decade@ietf.org https://www.ietf.org/mailman/listinfo/decade From melodysong@huawei.com Tue Oct 27 18:59:23 2009 Return-Path: X-Original-To: decade@core3.amsl.com Delivered-To: decade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4900E28C174 for ; Tue, 27 Oct 2009 18:59:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.228 X-Spam-Level: X-Spam-Status: No, score=0.228 tagged_above=-999 required=5 tests=[AWL=0.723, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cF0Izef-Vqqc for ; Tue, 27 Oct 2009 18:59:22 -0700 (PDT) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 0396628C178 for ; Tue, 27 Oct 2009 18:59:22 -0700 (PDT) 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 <0KS700FKCC7237@szxga04-in.huawei.com> for decade@ietf.org; Wed, 28 Oct 2009 09:59:26 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KS700ME0C728S@szxga04-in.huawei.com> for decade@ietf.org; Wed, 28 Oct 2009 09:59:26 +0800 (CST) Received: from s64081 ([10.164.12.29]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KS7002FUC717N@szxml04-in.huawei.com> for decade@ietf.org; Wed, 28 Oct 2009 09:59:26 +0800 (CST) Date: Wed, 28 Oct 2009 09:59:21 +0800 From: Song Haibin In-reply-to: <5D84FDD8D5DC8646B9F73CF1EFD1BFA4DC4EFC@CNBEEXC007.nsn-intra.net> To: "'Xiao, Lin (NSN - CN/Beijing)'" , decade@ietf.org Message-id: <007101ca5772$441c8b10$1d0ca40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcpOA98y5le93EERRrmYJYZUAax+xwAADKSgAje0FaAAIdA40A== Subject: Re: [decade] Notification for draft-song-decade-problem-statement-00 X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2009 01:59:23 -0000 Hi Lin, Thanks for your comments. See in line. >-----Original Message----- >From: Xiao, Lin (NSN - CN/Beijing) [mailto:lin.xiao@nsn.com] >Sent: Tuesday, October 27, 2009 5:56 PM >To: ext Song Haibin; decade@ietf.org >Subject: RE: [decade] Notification for >draft-song-decade-problem-statement-00 > >Hi Haibin, > >Well done. It's a good base for further discussion of DECADE. >There are some comments from my side. > >1. In section 3.1, you compared the DECADE to ALTO. IMHO, The >need of DECADE besides ALTO is that the tree like underlayer >network topology is widely implemented for access network. >ALTO does solve the unnecessary backbone transit and localize >the traffic with topology information. If the access network >has mesh connection, it seems that ALTO can solve the traffic >optimization alone. The problem here is that most access >networks have tree like topology, so that even local traffics >between selected peers by ALTO must go through some center >point which give chance for DECADE to do further optimization. >So, the key here is the unmatched overlay topology with the >tree like underlayer topology. > With implementing in-network storage for p2p applications, most of the data traffic will transport from the in-network storage to customer endpoint, instead of from endpoint to endpoint. The use of uplink bandwidth will be greatly reduced, and p2p application performance can be improved. While ALTO can be used to localize the p2p traffic, DECADE and ALTO can be complementary to each other. >2. In section 3.2, you regards cache as complex storage. >However, if the cache is only for one P2P application, where >it is looked as a peer for the application, I don't think the >whole protocol could be more complex. >The key here, I think, is that if we use a single cache server >for multiple applications, the complexity is increased. That's >why we need a application independent storage. > You are right. To support many evolving p2p application protocols makes the cache server rather complicated. To support only one P2P application is much simpler, but the cache server still needs to keep updating with the p2p application protocol change. If the P2P application protocol is proprietary, things will get complicated (e.g. if you use DPI to detect the traffic and redirect the message to p2p cache). >3. In section 3.3, I'm not sure what you mean here. Do you >mean the storage will also take part in the peer selection as >a peer with good performance? In-network storage could be seen as a better peer when you do peer selection, but that is out of scope in the draft charter I sent out weeks ago. The In-network storage Access Protocol ( IAP) will be the key output of DECADE. In section 3.3, we stated that the in-network storage should have the capability to be effectively integrated with P2P applications while keep the flexibility of P2P applications to implement their specific policies. IMHO, the storage and DECADE >protocol should be totally invisible from the P2P application. >But if you mean the deployment position of the storage >(considering the underlayer topology and bandwidth structure) >can help traffic optimization, I think, section >3.1 should have already mentioned it. > I don't think it can be totally invisible because a P2P application client should have the capability to control how its resources in the in-network storage can be accessed by others. >The last question is that do we really need include solutions >and detailed usage scenarios in a problem statement draft. > The usage scenarios are just used to give you a picture on how P2P applications and content publishers can use DECADE. Thanks, Haibin >Br >Xiao, Lin > >-----Original Message----- >From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.org] >On Behalf Of ext Song Haibin >Sent: Friday, October 16, 2009 10:08 AM >To: decade@ietf.org >Subject: [decade] Notification for >draft-song-decade-problem-statement-00 > >Hi all, > >We just submit the DECADE problem statement draft. Any >comments are appreciated! > >Abstrac >Peer-to-peer (P2P) applications have become widely used on the >Internet today and make up a large portion of the traffic in >many networks. In P2P applications, one technique for >reducing the total amount of P2P traffic is to introduce >storage capabilities within the network. >Traditional caches (e.g., P2P and Web caches) provide such >storage, but they are complex (due to explicitly supporting >individual P2P application protocols) and they do not allow >users to manage access to content in the cache. For example, >Content Providers cannot easily control access and resource >usage policies to satisfy their own requirements. This >document discusses the introduction of in-network storage for >P2P applications, shows the need for a standard protocol for >accessing this storage, and identifies the scope of this protocol. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-song-decade-problem-s >tatement- >00.t >xt > >Best Regards, >Haibin > >_______________________________________________ >decade mailing list >decade@ietf.org >https://www.ietf.org/mailman/listinfo/decade > From melodysong@huawei.com Fri Oct 30 18:56:08 2009 Return-Path: X-Original-To: decade@core3.amsl.com Delivered-To: decade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E2243A68AD for ; Fri, 30 Oct 2009 18:56:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.892 X-Spam-Level: X-Spam-Status: No, score=0.892 tagged_above=-999 required=5 tests=[AWL=-0.102, BAYES_05=-1.11, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lQZ2NbmINhyA for ; Fri, 30 Oct 2009 18:56:07 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id BA4F83A6781 for ; Fri, 30 Oct 2009 18:56:07 -0700 (PDT) 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 <0KSC003KPW1QSU@szxga03-in.huawei.com> for decade@ietf.org; Sat, 31 Oct 2009 09:56:15 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KSC005APW1QK7@szxga03-in.huawei.com> for decade@ietf.org; Sat, 31 Oct 2009 09:56:14 +0800 (CST) Received: from s64081 ([10.164.12.29]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KSC00IX8W1PIH@szxml04-in.huawei.com> for decade@ietf.org; Sat, 31 Oct 2009 09:56:13 +0800 (CST) Date: Sat, 31 Oct 2009 09:56:12 +0800 From: Song Haibin To: decade@ietf.org Message-id: <002401ca59cd$533dfea0$1d0ca40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcpZzVLvPpPJ4sVZT5yOyZuvMNYf0g== Subject: [decade] Draft agenda for DECADE BOF @IETF76 X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Oct 2009 01:56:08 -0000 Hi Folks, I just updated our draft agenda for DECADE BOF in Hiroshima. http://trac.tools.ietf.org/area/app/trac/wiki/DecadeAgenda Best Regards, Haibin Skype: alexsonghw From enrico.marocco@telecomitalia.it Sat Oct 31 01:53:49 2009 Return-Path: X-Original-To: decade@core3.amsl.com Delivered-To: decade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1AB483A6885 for ; Sat, 31 Oct 2009 01:53:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.552 X-Spam-Level: X-Spam-Status: No, score=0.552 tagged_above=-999 required=5 tests=[AWL=-0.218, BAYES_05=-1.11, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nH5ggOXnV-GD for ; Sat, 31 Oct 2009 01:53:48 -0700 (PDT) Received: from GRFEDG701BA020.telecomitalia.it (grfedg701ba020.telecomitalia.it [156.54.233.200]) by core3.amsl.com (Postfix) with ESMTP id DC2403A67C2 for ; Sat, 31 Oct 2009 01:53:47 -0700 (PDT) Received: from GRFHUB701BA020.griffon.local (10.188.101.111) by GRFEDG701BA020.telecomitalia.it (10.188.45.100) with Microsoft SMTP Server (TLS) id 8.2.176.0; Sat, 31 Oct 2009 09:54:03 +0100 Received: from [172.16.82.18] (163.162.180.246) by smtp.telecomitalia.it (10.188.101.114) with Microsoft SMTP Server (TLS) id 8.2.176.0; Sat, 31 Oct 2009 09:54:02 +0100 Message-ID: <4AEBFB28.5050403@telecomitalia.it> Date: Sat, 31 Oct 2009 09:54:00 +0100 From: Enrico Marocco User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Song Haibin References: <002401ca59cd$533dfea0$1d0ca40a@china.huawei.com> In-Reply-To: <002401ca59cd$533dfea0$1d0ca40a@china.huawei.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030205030800070408040304" Cc: "decade@ietf.org" Subject: Re: [decade] Draft agenda for DECADE BOF @IETF76 X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Oct 2009 08:53:49 -0000 --------------ms030205030800070408040304 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Song Haibin wrote: > I just updated our draft agenda for DECADE BOF in Hiroshima. > > http://trac.tools.ietf.org/area/app/trac/wiki/DecadeAgenda The agenda looks good, but I'd suggest to move the charter discussion after the problem statement and the other introductory presentations. After all, this is the first time the topic is presented to the wider community and it seems a bit odd to start a meeting discussing how to address the problem without first telling what the problem is. -- Ciao, Enrico --------------ms030205030800070408040304 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJOzCC AvgwggJhoAMCAQICEBtZixsKeF4i2Os0viEP+ncwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDMyOTE2Mjg1OVoX DTEwMDMyOTE2Mjg1OVowUTEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEuMCwG CSqGSIb3DQEJARYfZW5yaWNvLm1hcm9jY29AdGVsZWNvbWl0YWxpYS5pdDCCASIwDQYJKoZI hvcNAQEBBQADggEPADCCAQoCggEBALhn5sIqd2hv7B6UBs4823vUHLamD/+tFSXZKQ4Yw5oQ 5hOdPUoJazGMDOyB9tWcqXdJxt0WqHxdgeCeAS0zV85Uf6cQcvkSe//umVkZvPuAYTKWRBJw 8rLfVuYhk9t2KraXyVfWIdoceZP0/v4eIoLyPw2/wQS3AvxujvkyL2N94S7IOmPCP6WXZmmW zNRzabSLLl50UA2jKbcYcWpKfQUFma9B1S3hAZTDiQTvXIJVmRdwYmnuwId9QTsm+7RB7oiy EC7+zeOORQk1Y6NjKinZmLb/C0tq40NIIPpBqNaZ+V6UmQ0jtYIlBQrlG6OpSPgjAS9IWsMg 7mbratVpsNkCAwEAAaM8MDowKgYDVR0RBCMwIYEfZW5yaWNvLm1hcm9jY29AdGVsZWNvbWl0 YWxpYS5pdDAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBADfh68XGwHIccDd0a+Fw D7LEP2QxLEqgP/gR73fsvT6y1COD7vGZY4BkYvryiU5sPkW4ulizN1ASSMJJIVMkQdzzKS+H e4dR5CpiPqz8b1LJdae8G7CUsBZ9KHYN4n6pGpdcq9YsGtfELp1W25MMppJcpKniscResCQF BWmw3EsAMIIC+DCCAmGgAwIBAgIQG1mLGwp4XiLY6zS+IQ/6dzANBgkqhkiG9w0BAQUFADBi MQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEs MCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDkwMzI5 MTYyODU5WhcNMTAwMzI5MTYyODU5WjBRMR8wHQYDVQQDExZUaGF3dGUgRnJlZW1haWwgTWVt YmVyMS4wLAYJKoZIhvcNAQkBFh9lbnJpY28ubWFyb2Njb0B0ZWxlY29taXRhbGlhLml0MIIB IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuGfmwip3aG/sHpQGzjzbe9QctqYP/60V JdkpDhjDmhDmE509SglrMYwM7IH21Zypd0nG3RaofF2B4J4BLTNXzlR/pxBy+RJ7/+6ZWRm8 +4BhMpZEEnDyst9W5iGT23YqtpfJV9Yh2hx5k/T+/h4igvI/Db/BBLcC/G6O+TIvY33hLsg6 Y8I/pZdmaZbM1HNptIsuXnRQDaMptxhxakp9BQWZr0HVLeEBlMOJBO9cglWZF3Biae7Ah31B Oyb7tEHuiLIQLv7N445FCTVjo2MqKdmYtv8LS2rjQ0gg+kGo1pn5XpSZDSO1giUFCuUbo6lI +CMBL0hawyDuZutq1Wmw2QIDAQABozwwOjAqBgNVHREEIzAhgR9lbnJpY28ubWFyb2Njb0B0 ZWxlY29taXRhbGlhLml0MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEFBQADgYEAN+HrxcbA chxwN3Rr4XAPssQ/ZDEsSqA/+BHvd+y9PrLUI4Pu8ZljgGRi+vKJTmw+Rbi6WLM3UBJIwkkh UyRB3PMpL4d7h1HkKmI+rPxvUsl1p7wbsJSwFn0odg3ifqkal1yr1iwa18QunVbbkwymklyk qeKxxF6wJAUFabDcSwAwggM/MIICqKADAgECAgENMA0GCSqGSIb3DQEBBQUAMIHRMQswCQYD VQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAY BgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZp Y2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgQ0ExKzAp BgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcNMDMwNzE3MDAw MDAwWhcNMTMwNzE2MjM1OTU5WjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENv bnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWls IElzc3VpbmcgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMSmPFVzVftOucqZWh5o wHUEcJ3f6f+jHuy9zfVb8hp2vX8MOmHyv1HOAdTlUAow1wJjWiyJFXCO3cnwK4Vaqj9xVsuv PAsH5/EfkTYkKhPPK9Xzgnc9A74r/rsYPge/QIACZNenprufZdHFKlSFD0gEf6e20TxhBEAe ZBlyYLf7AgMBAAGjgZQwgZEwEgYDVR0TAQH/BAgwBgEB/wIBADBDBgNVHR8EPDA6MDigNqA0 hjJodHRwOi8vY3JsLnRoYXd0ZS5jb20vVGhhd3RlUGVyc29uYWxGcmVlbWFpbENBLmNybDAL BgNVHQ8EBAMCAQYwKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDItMTM4 MA0GCSqGSIb3DQEBBQUAA4GBAEiM0VCD6gsuzA2jZqxnD3+vrL7CF6FDlpSdf0whuPg2H6ot nzYvwPQcUCCTcDz9reFhYsPZOhl+hLGZGwDFGguCdJ4lUJRix9sncVcljd2pnDmOjCBPZV+V 2vf3h9bGCE6u9uo05RAaWzVNd+NWIXiC3CEZNd4ksdMdRv9dX2VPMYIDcTCCA20CAQEwdjBi MQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEs MCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEBtZixsKeF4i 2Os0viEP+ncwCQYFKw4DAhoFAKCCAdAwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkq hkiG9w0BCQUxDxcNMDkxMDMxMDg1NDAwWjAjBgkqhkiG9w0BCQQxFgQUluCYEjB0ur/HSFau thRB/9wv+QEwXwYJKoZIhvcNAQkPMVIwUDALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYI KoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGF BgkrBgEEAYI3EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3Vs dGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNz dWluZyBDQQIQG1mLGwp4XiLY6zS+IQ/6dzCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNV BAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQD EyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQG1mLGwp4XiLY6zS+IQ/6 dzANBgkqhkiG9w0BAQEFAASCAQBTQ4aKwqWb5QwursbtgDVM9I+T4K/ElRZuzWWAMiJjjeMV NbShaVVYhoMu+lIpsG4eH9X0o53TX+EseVxArYoCL2xPxYCn+2BxX1HcevZSxbAEYHlmlUoX /AB2cVtAsGPYrNRdMKy8OCDeRqxIb7xnRk3DV+5SWlj8xFl8vq9GAv3bpOZeg6aRUwYE1N1E LPRl/Mncd/8tPdIkjB4RHpnuNjXfmTzS58D8cOSlFl5gNHc5+Tsgk8GwcoGjLONO4swupfpQ RJTM9xvMfuqvzUmuk1RnhQIkj5CIvWN16tXkSMsPBS4D4RMTIWyhOnH0XmiPNv8TpBLkhPA9 587fV5YLAAAAAAAA --------------ms030205030800070408040304--