From internet-drafts@ietf.org Tue Feb 7 18:14:28 2012 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 0946621F8569; Tue, 7 Feb 2012 18:14:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.581 X-Spam-Level: X-Spam-Status: No, score=-102.581 tagged_above=-999 required=5 tests=[AWL=0.018, 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 CRCvrAH-5CNd; Tue, 7 Feb 2012 18:14:27 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D08E21F8565; Tue, 7 Feb 2012 18:14:09 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.64p1 Message-ID: <20120208021409.26012.70106.idtracker@ietfa.amsl.com> Date: Tue, 07 Feb 2012 18:14:09 -0800 Cc: decade@ietf.org Subject: [decade] I-D Action: draft-ietf-decade-problem-statement-05.txt X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2012 02:14:28 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Decoupled Application Data Enroute Wo= rking Group of the IETF. Title : DECoupled Application Data Enroute (DECADE) Problem Stat= ement Author(s) : Haibin Song Ning Zong Y. Richard Yang Richard Alimi Filename : draft-ietf-decade-problem-statement-05.txt Pages : 13 Date : 2012-02-07 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 transit and uplink 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 cache refresh mechanisms) and they do not allow users to manage access to content in the cache. For example, content providers wishing to use in- network storage cannot easily control cache access and resource usage policies to satisfy their own requirements. This document discusses the introduction of in-network storage for P2P applications, and shows the need for a standard protocol for accessing this storage. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-decade-problem-statement-05.= txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-decade-problem-statement-05.t= xt From richard_woundy@cable.comcast.com Thu Feb 16 09:11:02 2012 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 91CF121F886B for ; Thu, 16 Feb 2012 09:11:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.364 X-Spam-Level: X-Spam-Status: No, score=-105.364 tagged_above=-999 required=5 tests=[AWL=3.098, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Riiq+BUu2GAV for ; Thu, 16 Feb 2012 09:10:57 -0800 (PST) Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by ietfa.amsl.com (Postfix) with ESMTP id E009F21F87D4 for ; Thu, 16 Feb 2012 09:10:56 -0800 (PST) Received: from ([24.40.56.114]) by pacdcimo01.cable.comcast.com with ESMTP id 5503620.151632258; Thu, 16 Feb 2012 12:10:48 -0500 Received: from PACDCEXMB05.cable.comcast.com ([fe80::a5b0:e5c4:df1b:2367]) by PACDCEXHUB01.cable.comcast.com ([fe80::d1e7:20b5:9b63:21a6%11]) with mapi id 14.01.0355.002; Thu, 16 Feb 2012 12:10:48 -0500 From: "Woundy, Richard" To: "decade@ietf.org" Thread-Topic: Trends in DECADE reviews Thread-Index: AczszebunDqf4R+jTeCTItMzY/HeLQ== Date: Thu, 16 Feb 2012 17:10:46 +0000 Message-ID: <1CA25301D2219F40B3AA37201F0EACD11509335D@PACDCEXMB05.cable.comcast.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [24.40.56.178] Content-Type: multipart/alternative; boundary="_000_1CA25301D2219F40B3AA37201F0EACD11509335DPACDCEXMB05cabl_" MIME-Version: 1.0 Subject: [decade] Trends in DECADE reviews X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 17:11:03 -0000 --_000_1CA25301D2219F40B3AA37201F0EACD11509335DPACDCEXMB05cabl_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Decade WG document editors, There are a few trends in our document style that we need to fix ASAP. Whil= e these comments below were taken from the AD review of requirements, I hav= e seen similar comments for all the documents we have sent to our AD. In short, we need to stop referring to DECADE as an actor (a person or thin= g), we need to avoid discussing DECADE "protocols", and we need to avoid re= ferring to the DECADE working group (or other IETF working groups as they a= re all temporary). > A major problem of this document is that it uses DECADE as an actor, and = specifies what DECADE must do. But DECADE is not an actor. The document rea= lly needs to be written in terms of the components of the system, and the s= pecification of compliant behaviors. DECADE is really only a set of documen= ts specifying compliance rules. The actors are decade-compatible servers, d= ecade-compatible clients, decade-compatible protocols and the specification= must describe what those actors are required to do, not what DECADE must d= o. > is this use of decade a reference to the WG or the system? DECADE does no= t exist >"DECADE does not intend". DECADE is not a concrete thing, so it cannot "do= " anything. It is not sentient, so it cannot "intend". The closest you come= to decade being concrete it that is a WG, but a WG is a temporary thing an= d the document will outlast its lifetime; you should write in terms of the = specifications; the specifications are real things. > The WG has explicitly NOT been authorized to create a new protocol (i.e. = a new messaging protocol). That was very deliberate. Many of the tasks requ= ired of a "decade system" can be done using existing open, standard protoco= ls. The WG is chartered to explore the problem space, and to develop an abs= tract architecture to break the problem into manageable parts, and to ident= ify the requirements for those parts to work together. A gap analysis ident= ifying how existing protocols cannot meet the requirements can be part of t= he outcome, but creating a protocol is explicitly out of scope of this WG. -- Rich --_000_1CA25301D2219F40B3AA37201F0EACD11509335DPACDCEXMB05cabl_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Decade WG document editors,

 

There are a few trends in our document style that we= need to fix ASAP. While these comments below were taken from the AD review= of requirements, I have seen similar comments for all the documents we hav= e sent to our AD.

 

In short, we need to stop referring to DECADE as an = actor (a person or thing), we need to avoid discussing DECADE “protoc= ols”, and we need to avoid referring to the DECADE working group (or = other IETF working groups as they are all temporary).

 

> A major problem of this document is that it = uses DECADE as an actor, and specifies what DECADE must do. But DECADE is n= ot an actor. The document really needs to be written in terms of the compon= ents of the system, and the specification of compliant behaviors. DECADE is really only a set of documents specifyin= g compliance rules. The actors are decade-compatible servers, decade-compat= ible clients, decade-compatible protocols and the specification must descri= be what those actors are required to do, not what DECADE must do.

 

> is this use of decade a reference to the WG or = the system? DECADE does not exist

 

>"DECADE does not intend". DECADE is no= t a concrete thing, so it cannot "do" anything. It is not sentien= t, so it cannot "intend". The closest you come to decade being co= ncrete it that is a WG, but a WG is a temporary thing and the document will outlast its lifetime; you should write in terms of the specifications= ; the specifications are real things.

 

> The WG has explicitly NOT been authorized to cr= eate a new protocol (i.e. a new messaging protocol). That was very delibera= te. Many of the tasks required of a "decade system" can be done u= sing existing open, standard protocols. The WG is chartered to explore the problem space, and to develop an abstract arch= itecture to break the problem into manageable parts, and to identify the re= quirements for those parts to work together. A gap analysis identifying how= existing protocols cannot meet the requirements can be part of the outcome, but creating a protocol is ex= plicitly out of scope of this WG.

 

-- Rich

--_000_1CA25301D2219F40B3AA37201F0EACD11509335DPACDCEXMB05cabl_-- From dhc2@dcrocker.net Thu Feb 16 11:26:41 2012 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 4BF8F21E8049 for ; Thu, 16 Feb 2012 11:26:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.879 X-Spam-Level: X-Spam-Status: No, score=-5.879 tagged_above=-999 required=5 tests=[AWL=0.720, BAYES_00=-2.599, 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 eEGxsDVc6gur for ; Thu, 16 Feb 2012 11:26:38 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id E1FDC21E800C for ; Thu, 16 Feb 2012 11:26:38 -0800 (PST) Received: from [192.168.1.11] (adsl-67-127-58-62.dsl.pltn13.pacbell.net [67.127.58.62]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q1GJQUJY015450 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 16 Feb 2012 11:26:36 -0800 Message-ID: <4F3D5864.90508@dcrocker.net> Date: Thu, 16 Feb 2012 11:26:28 -0800 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.1) Gecko/20120208 Thunderbird/10.0.1 MIME-Version: 1.0 To: "Woundy, Richard" References: <1CA25301D2219F40B3AA37201F0EACD11509335D@PACDCEXMB05.cable.comcast.com> In-Reply-To: <1CA25301D2219F40B3AA37201F0EACD11509335D@PACDCEXMB05.cable.comcast.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Thu, 16 Feb 2012 11:26:36 -0800 (PST) Cc: "decade@ietf.org" Subject: Re: [decade] Trends in DECADE reviews X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 19:26:41 -0000 fwiw, I'm gearing up to do the apps directorate review for some of your docs and would heartily concur with the kinds of issues Richard is raising. d/ On 2/16/2012 9:10 AM, Woundy, Richard wrote: > Decade WG document editors, > > There are a few trends in our document style that we need to fix ASAP. While > these comments below were taken from the AD review of requirements, I have seen > similar comments for all the documents we have sent to our AD. > > In short, we need to stop referring to DECADE as an actor (a person or thing), > we need to avoid discussing DECADE “protocols”, and we need to avoid referring > to the DECADE working group (or other IETF working groups as they are all > temporary). > > > A major problem of this document is that it uses DECADE as an actor, and > specifies what DECADE must do. But DECADE is not an actor. The document really > needs to be written in terms of the components of the system, and the > specification of compliant behaviors. DECADE is really only a set of documents > specifying compliance rules. The actors are decade-compatible servers, > decade-compatible clients, decade-compatible protocols and the specification > must describe what those actors are required to do, not what DECADE must do. > > > is this use of decade a reference to the WG or the system? DECADE does not exist > > >"DECADE does not intend". DECADE is not a concrete thing, so it cannot "do" > anything. It is not sentient, so it cannot "intend". The closest you come to > decade being concrete it that is a WG, but a WG is a temporary thing and the > document will outlast its lifetime; you should write in terms of the > specifications; the specifications are real things. > > > The WG has explicitly NOT been authorized to create a new protocol (i.e. a > new messaging protocol). That was very deliberate. Many of the tasks required of > a "decade system" can be done using existing open, standard protocols. The WG is > chartered to explore the problem space, and to develop an abstract architecture > to break the problem into manageable parts, and to identify the requirements for > those parts to work together. A gap analysis identifying how existing protocols > cannot meet the requirements can be part of the outcome, but creating a protocol > is explicitly out of scope of this WG. > > -- Rich > -- Dave Crocker Brandenburg InternetWorking bbiw.net From cabo@tzi.org Thu Feb 16 11:47:42 2012 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 0CE3721E8089 for ; Thu, 16 Feb 2012 11:47:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.082 X-Spam-Level: X-Spam-Status: No, score=-106.082 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 Ndnj9VysyrEB for ; Thu, 16 Feb 2012 11:47:41 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id D499B21F8617 for ; Thu, 16 Feb 2012 11:47:40 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id q1GJlHhZ015375; Thu, 16 Feb 2012 20:47:17 +0100 (CET) Received: from [192.168.217.103] (p5B3E6073.dip.t-dialin.net [91.62.96.115]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 7A6F78A3; Thu, 16 Feb 2012 20:47:17 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: <1CA25301D2219F40B3AA37201F0EACD11509335D@PACDCEXMB05.cable.comcast.com> Date: Thu, 16 Feb 2012 20:47:16 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <197AFF4A-258F-4348-9D46-A467AB5BD713@tzi.org> References: <1CA25301D2219F40B3AA37201F0EACD11509335D@PACDCEXMB05.cable.comcast.com> To: "Woundy, Richard" X-Mailer: Apple Mail (2.1257) Cc: "decade@ietf.org" Subject: Re: [decade] Trends in DECADE reviews X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 19:47:42 -0000 On Feb 16, 2012, at 18:10, Woundy, Richard wrote: > trends in our document style that we need to fix ASAP Can I generalize on that a bit, with a certain danger of being a bit = offensive? You (WG during document reviewing, document authors) really need to turn = down your tolerance of muddled thinking. I really like your work, but good work is not enough: you have to clean = up the documents, too. Thank your for tolerating this little public service announcement. Gr=FC=DFe, Carsten From Akbar.Rahman@InterDigital.com Sun Feb 19 20:45:47 2012 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 80B3421F8664 for ; Sun, 19 Feb 2012 20:45:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.886 X-Spam-Level: X-Spam-Status: No, score=-0.886 tagged_above=-999 required=5 tests=[AWL=-1.714, BAYES_50=0.001, J_CHICKENPOX_102=0.6, 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 dh34SpOUFbWv for ; Sun, 19 Feb 2012 20:45:46 -0800 (PST) Received: from idcout.InterDigital.com (smtp-out1.interdigital.com [64.208.228.135]) by ietfa.amsl.com (Postfix) with ESMTP id 0672521F8661 for ; Sun, 19 Feb 2012 20:45:16 -0800 (PST) Received: from SAM.InterDigital.com ([10.30.2.11]) by idcout.InterDigital.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 19 Feb 2012 23:45:15 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Date: Sun, 19 Feb 2012 23:45:16 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AD review of draft-ietf-decade-reqs-05.txt Thread-Index: AczsexGDL/zMas9iRsmUjYgSMzwm/gDDrMjA From: "Rahman, Akbar" To: X-OriginalArrivalTime: 20 Feb 2012 04:45:15.0488 (UTC) FILETIME=[70433600:01CCEF8A] Subject: [decade] AD review of draft-ietf-decade-reqs-05.txt X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2012 04:45:47 -0000 RllJIC0gSGVyZSBpcyB0aGUgQUQgcmV2aWV3IG9mIHRoZSBERUNBREUgcmVxdWlyZW1lbnRzIEkt RC4NCg0KDQpBa2JhciAoYXMgZG9jdW1lbnQgc2hlcGhlcmQpDQoNCg0KLS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS0NCkZyb206IElFVEYgU2VjcmV0YXJpYXQgW21haWx0bzppZXRmLXNlY3JldGFy aWF0LXJlcGx5QGlldGYub3JnXSANClNlbnQ6IFRodXJzZGF5LCBGZWJydWFyeSAxNiwgMjAxMiAx MjowNyBBTQ0KVG86IGRlY2FkZS1jaGFpcnNAdG9vbHMuaWV0Zi5vcmc7IGRyYWZ0LWlldGYtZGVj YWRlLXJlcXNAdG9vbHMuaWV0Zi5vcmc7IFJhaG1hbiwgQWtiYXINClN1YmplY3Q6IElEIFRyYWNr ZXIgU3RhdGUgVXBkYXRlIE5vdGljZTogPGRyYWZ0LWlldGYtZGVjYWRlLXJlcXMtMDUudHh0Pg0K DQpTdGF0ZSBjaGFuZ2VkIHRvIEFEIEV2YWx1YXRpb246OlJldmlzZWQgSUQgTmVlZGVkIGZyb20g QUQgRXZhbHVhdGlvbi5BRCBSZXZpZXcgZm9yIGRyYWZ0LWlldGYtZGVjYWRlLXJlcXMtMDUNCg0K MSkgQSBtYWpvciBwcm9ibGVtIG9mIHRoaXMgZG9jdW1lbnQgaXMgdGhhdCBpdCB1c2VzIERFQ0FE RSBhcyBhbiBhY3RvciwgYW5kIHNwZWNpZmllcyB3aGF0IERFQ0FERSBtdXN0IGRvLiBCdXQgREVD QURFIGlzIG5vdCBhbiBhY3Rvci4gVGhlIGRvY3VtZW50IHJlYWxseSBuZWVkcyB0byBiZSB3cml0 dGVuIGluIHRlcm1zIG9mIHRoZSBjb21wb25lbnRzIG9mIHRoZSBzeXN0ZW0sIGFuZCB0aGUgc3Bl Y2lmaWNhdGlvbiBvZiBjb21wbGlhbnQgYmVoYXZpb3JzLiBERUNBREUgaXMgcmVhbGx5IG9ubHkg YSBzZXQgb2YgZG9jdW1lbnRzIHNwZWNpZnlpbmcgY29tcGxpYW5jZSBydWxlcy4gVGhlIGFjdG9y cyBhcmUgZGVjYWRlLWNvbXBhdGlibGUgc2VydmVycywgZGVjYWRlLWNvbXBhdGlibGUgY2xpZW50 cywgZGVjYWRlLWNvbXBhdGlibGUgcHJvdG9jb2xzIGFuZCB0aGUgc3BlY2lmaWNhdGlvbiBtdXN0 IGRlc2NyaWJlIHdoYXQgdGhvc2UgYWN0b3JzIGFyZSByZXF1aXJlZCB0byBkbywgbm90IHdoYXQg REVDQURFIG11c3QgZG8uIA0KDQoyKSBpbiAxLCAidGhlIG9iamVjdCBvZiBERUNBREUgaXMiOyBp cyB0aGlzIHVzZSBvZiBkZWNhZGUgYSByZWZlcmVuY2UgdG8gdGhlIFdHIG9yIHRoZSBzeXN0ZW0/ IERFQ0FERSBkb2VzIG5vdCBleGlzdC4gDQoNCjMpIGluIDEsIHMvYmVoaW5kIFNQRUNJRklDIHJl cXVpcmVtZW50cy9iZWhpbmQgcmVxdWlyZW1lbnRzLw0Kcy9ET0VTIE5PVC9kb2VzIG5vdC8NCnMv REVDQURFIHByb3RvY29scy9ERUNBREUtY29tcGF0aWJsZSBwcm90b2NvbHMvDQoNCjQpIGluIDIs IFlvdSBzaG91bGQgaGF2ZSBhIHRlcm1pbm9sb2d5IHNlY3Rpb24gdGhhdCBkZWZpbmVzIHdoYXQg YSBkZWNhZGUgc2VydmVyIGlzL2RvZXMsIGFuZCB3aGF0IGEgZGVjYWRlIGNsaWVudCBpcy9kb2Vz Lg0KSSByZWNvbW1lbmQgdGhhdCB0aGlzIGRvY3VtZW50IHNwZWNpZmllcyAqKndoaWNoKiogdGVy bXMgaXQgdXNlcyBmcm9tIHByb2JsZW0tc3RhdGVtZW50Lg0KDQpzbyB3aGF0IGlzIHRoZSBkaWZm ZXJlbmNlIGJldHdlZW4gYSB0YXJnZXQgYXBwbGljYXRpb24gYW5kIGEgZGVjYWRlIGNsaWVudD8N Cg0KNSkgaW4gMiwgcy9kZWxpdmVyIGNvbnRlbnQgdG8gYSBsYXJnZSBudW1iZXIgb2YgdXNlcnMv ZGVsaXZlciBjb250ZW50IHRvIHVzZXJzLw0KDQo2KSBpbiAyICJ0eXBpY2FsbHkgaW1tdXRhYmxl IiBpcyBhIGJpdCBwcm9ibGVtYXRpYy4gSW4gdGhlIGRlY2FkZSBkb2NzLCBpbW11dGFibGUgaXMg c29tZXRpbWVzIGRlc2NyaWJlZCBhcyBhIHJlcXVpcmVtZW50IG9mIHRoZSBzeXN0ZW0sIGJ1dCB0 aGVuIG90aGVyIHBsYWNlcyB0YWxrIGFib3V0ICJ0eXBpY2FsbHkiLCBhbmQgIm1heSBiZSBtb2Rp ZmllZCIuIFlvdSBjYW5ubyB0aGFuZSBpdCBib3RoIHdheXMuIEVpdGhlciB0aGUgZGF0YSBpcyBp bW11dGFibGUgb3IgaXQgaXMgbm90LCBhbmQgdGhhdCBoYXMgYSBzaWduaWZpY2FudCBlZmZlY3Qg b24gdGhlIHJlcXVpcmVtZW50cyBhbmQgdGhlIGFiaWxpdHkgdG8gdXNlIGV4aXN0aW5nIHByb3Rv Y29scyB0aGF0IGRvIG5vdCBtZWV0IHRoYXQgcmVxdWlyZW1lbnQuIE15IGltcHJlc3Npb24gaXMg dGhhdCByZXF1aXJpbmcgaW1tdXRhYmlsaXR5IHNldmVyZWx5IGNvbnRyYWlucyB0aGUgZGVjYWRl IGFwcHJvYWNoLCBhbmQgaXMgYSBiYWQgdGhpbmcgdG8gcmVxdWlyZS4NCg0KPT0gaW4gMyA9PQ0K NykgImEgYmFjay1lbmQgc3RvcmFnZSBzeXN0ZW0iIC0gd2hhdCBpcyBhIGJhY2sgZW5kPw0KDQo4 KSAiREVDQURFIGRvZXMgbm90IGludGVuZCIuIERFQ0FERSBpcyBub3QgYSBjb25jcmV0ZSB0aGlu Zywgc28gaXQgY2Fubm90ICJkbyIgYW55dGhpbmcuIEl0IGlzIG5vdCBzZW50aWVudCwgc28gaXQg Y2Fubm90ICJpbnRlbmQiLiBUaGUgY2xvc2VzdCB5b3UgY29tZSB0byBkZWNhZGUgYmVpbmcgY29u Y3JldGUgaXQgdGhhdCBpcyBpcyBhIFdHLCBidXQgYSBXRyBpcyBhIHRlbXBvcmFyeSB0aGluZyBh bmQgdGhlIGRvY3VtZW50IHdpbGwgb3V0bGFzdCBpdHMgbGlmZXRpbWU7IHlvdSBzaG91bGQgd3Jp dGUgaW4gdGVybXMgb2YgdGhlIHNwZWNpZmljYXRpb25zOyB0aGUgc3BlY2lmaWNhdGlvbnMgYXJl IHJlYWwgdGhpbmdzLg0KDQo5KSBbaW50ZW5kc10gInRvIGNyZWF0ZSBhIHByb3RvY29sIi4gVGhl IFdHIGhhcyBleHBsaWNpdGx5IE5PVCBiZWVuIGF1dGhvcml6ZWQgdG8gY3JlYXRlIGEgbmV3IHBy b3RvY29sIChpLmUuIGEgbmV3IG1lc3NhZ2luZyBwcm90b2NvbCkuIFRoYXQgd2FzIHZlcnkgZGVs aWJlcmF0ZS4gTWFueSBvZiB0aGUgdGFza3MgcmVxdWlyZWQgb2YgYSAiZGVjYWRlIHN5c3RlbSIg Y2FuIGJlIGRvbmUgdXNpbmcgZXhpc3Rpbmcgb3Blbiwgc3RhbmRhcmQgcHJvdG9jb2xzLiBUaGUg V0cgaXMgY2hhcnRlcmVkIHRvIGV4cGxvcmUgdGhlIHByb2JsZW0gc3BhY2UsIGFuZCB0byBkZXZl bG9wIGFuIGFic3RyYWN0IGFyY2hpdGVjdHVyZSB0byBicmVhayB0aGUgcHJvYmxlbSBpbnRvIG1h bmFnZWFibGUgcGFydHMsIGFuZCB0byBpZGVudGlmeSB0aGUgcmVxdWlyZW1lbnRzIGZvciB0aG9z ZSBwYXJ0cyB0byB3b3JrIHRvZ2V0aGVyLiBBIGdhcCBhbmFseXNpcyBpZGVudGlmeWluZyBob3cg ZXhpc3RpbmcgcHJvdG9jb2xzIGNhbm5vdCBtZWV0IHRoZSByZXF1aXJlbWVudHMgY2FuIGJlIHBh cnQgb2YgdGhlIG91dGNvbWUsIGJ1dCBjcmVhdGluZyBhIHByb3RvY29sIGlzIGV4cGxpY2l0bHkg b3V0IG9mIHNjb3BlIG9mIHRoaXMgV0cuDQoNCjEwKSBpbiAzLCBmaXJzdCBwYXJhZ3JhcGgsICJp bXBsZW1lbnRhdGlvbiBvZiB0aGUgREVDQURFIHNlcnZlcnMiOyBJIHRoaW5rIHRoZXJlIGlzIGEg ZGlzdGluY3Rpb24gdGhhdCBzaG91bGQgYmUgbWFkZSBiZXR3ZWVuIHRoZSBmdW5jdGlvbmFsaXR5 IGluIGFuIGltcGxlbWVudGF0aW9uIGZvciBkZWNhZGUgc3VwcG9ydCwgYW5kIGEgc3RvcmFnZSBz ZXJ2ZXIuIFRoZXJlZm9yZSwgSSB0aGluayAiREVDQURFIHNlcnZlcnMgYXMgbXVjaCBhcyBwb3Nz aWJsZSIgcmVhbGx5IHNob3VsZCBiZSAic3RvcmFnZSBzZXJ2ZXJzIGFzIG11Y2ggYXMgcG9zc2li bGUiDQoNCjExKSBhIG5pdCB0aGF0IGRyaXZlcyBtZSBjcmF6eSAtICJJdCBzaG91bGQgYmUgbWFk ZSBjbGVhciB0aGF0IOKApiI7IFlvdSBhcmUgYWJzb2x1dGVseSByaWdodC4gYW5kIGFzIGVkaXRv ciBvZiB0aGlzIGRyYWZ0LCB5b3Ugc2hvdWxkIGFscmVhZHkgYmUgbWFraW5nIHRoaXMgY2xlYXIg YnkgZG9jdW1lbnRpbmcgaXQgY2xlYXJseS4gdGhlcmVmb3JlLCB0aGVyZSBpcyBubyBuZWVkIHRv IHNheSAiSXQgc2hvdWxkIGJlIG1hZGUgY2xlYXIgdGhhdCDigKYiLiBJIGFsc28gcmVjb21tZW5k IGF2b2lkaW5nIHRoZSB1c2Ugb2YgIk5vdGUgdGhhdCDigKYiLCAiSXQgc2hvdWxkIGJlIG5vdGVk IHRoYXQg4oCmIiBhbmQgc28gb24uIFRIYXQgaXMgZXhhY3RseSB3aGVhdCB5b3UgYXMgZWRpdG9y IGFyZSBkb2luZyAtIG5vdGluZyB0aGUgaW1wb3J0YW50IHBvaW50cy4gDQoNCjEyKSAidGhlIGFw cHJvYWNoIGlzIHRvIG1ha2UgREVDQURFIGEgc2ltcGxlIHByb3RvY29sIi4gU2ltaWxhciB0byB0 aGUgV0csIHRoaXMgImFwcHJvYWNoIiBpcyBhIHRlbXBvcmFyeSB0aGluZy4gQnV0IHlvdSBhcmUg d3JpdGluZyBzcGVjaWZpY2F0aW9ucyB0aGF0IHdpbGwgbGFzdCBhcyBsb25nIGFzIHRoZSBSRkMg c2VyaWVzIGxhc3RzLiBUaGlzIHdob2xlIHBhcmFncmFwaCBjYW4gYmUgc3VtbWFyaXplZCBpbiBh Ym91dCBvbmUgc2VudGVuY2UuICJUaGlzIHNwZWNpZmljYXRpb24gZGlzY3Vzc2VzIHRoZSByZXF1 aXJlbWVudHMgb2YgZnVuY3Rpb25hbGl0eSBpbXBsZW1lbnRlZCB3aXRoIGEgc3RvcmFnZSBzeXN0 ZW0gYW5kIHdpdGhpbiBhcHBsaWNhdGlvbnMsIHRvIHBlcm1pdCBpbnRlcm9wZXJhYmxlIGNvbW11 bmljYXRpb25zIGNvbmNlcm5pbmcgdGhlIG1hbmlwdWxhdGlvbiBvZiBzdG9yZWQgY29udGVudC4i DQoNCjEzKSBpbiA0LCAiVGhpcyBzZWN0aW9uIGRldGFpbHMgdGhlIHJlcXVpcmVtZW50cyBvZiBE RUNBREUgcHJvdG9jb2wocykiLiBJcyB0aGlzIHRoZSByZXF1aXJlbWVudHMgYXBwbGllZCB0byBh bGwgcHJvdG9jb2xzIHVzZWQgd2l0aCB0aGUgZGVjYWRlIGFyY2hpdGVjdHVyZSAoaW5jbHVkaW5n IGZvciBleGFtcGxlIGV4aXN0aW5nIHByb3RvY29scyk/IG9yIGFyZSB0aGVzZSByZXF1aXJlbWVu dHMgb2YgZnV0dXJlIHByb3RvY29sIHNwZWNpZmljYXRpb25zPyBvciBhcmUgdGhlc2UgcmVxdWly ZW1lbnRzIG9mIHByb3RvY29sIGltcGxlbWVudGF0aW9ucz8gVGhvc2UgYXJlIGRpZmZlcmVudCB0 aGluZ3MuIA0KSWYgeW91IGFyZSByZXF1aXJpbmcgc29tZXRoaW5nLCB0aGVuIHlvdSBzaG91bGQg YmUgdXNpbmcgYWN0aXZlIHZvaWNlIHRvIHNwZWNpZmljICJ3aG8gbXVzdCBkbyB3aGF0Ii4gU28g aXMgdGhlIHdobyBhIHByb3RvY29sIHRoYXQgZml0cyB3aXRoaW4gdGhlIGFyY2hpdGVjdHVyZSAo YW4gZXhpc3RpbmcgcHJvdG9jb2wgdXNlZCB3aXRoaW4gdGhlIGRlY2FkZSBhcmNoaXRlY3R1cmUg bXVzdCBiZSBhYmxlIHRvIHBhc3MgIGluZm9ybWF0aW9uIGZyb20gdGhlIGNsaWVudCB0byB0aGUg c2VydmVyKT8gb3IgaXMgaXQgYSBkZWNhZGUgY2xpZW50IGltcGxlbWVudGF0aW9uICh0aGUgaW1w bGVtZW50YXRpb24gTVVTVCBpbmNsdWRlIHN1cHBvcnQgZm9yIFRMUzEuMCk/IG9yIGlzIGl0IHRo ZSBlZGl0b3Igb2YgZnV0dXJlIHNwZWNpZmljYXRpb25zIGRlc2lnbmVkIHRvIGZpdCB3aXRoaW4g dGhlIGFyY2hpdGVjdHVyZSAobmV3IHByb3RvY29sIGRlc2lnbnMgTVVTVCBzdXBwb3J0IFNIQS0y NTYpPw0KDQoxNCkgaW4gNC4xLjEuMSAiU0hPVUxEIGJlIHVzYWJsZSI7IHdoZW5ldmVyIHlvdSB1 c2UgU0hPVUxELCB5b3UgaW1wbHkgdGhlcmUgYXJlIGFjY2VwdGFibGUgZXhjZXB0aW9ucyB0byBh IE1VU1QuIFBsZWFzZSBpZGVudGlmeSB3aGF0IHRoZSBhY2NlcHRhYmxlIGV4Y2VwdGlvbnMgYXJl Lg0KDQoxNSkgaW4gNC4xLjEuMSwgInNob3VsZCBiZSB1c2FibGUgYWNyb3NzIGZpcmV3YWxscyDi gKYgW3dpdGhvdXQgQUxHcykiIEkgdGhpbmsgdGhpcyBjb3VsZCBiZSBzcGVjaWZpZWQgbW9yZSBh Y2N1cmF0ZWx5IGFzICJBIGRlY2FkZSBjbGllbnQgU0hPVUxEIE5PVCByZXF1aXJlIEFMR3MgdG8g d29yayBhY3Jvc3MgTkFUcyBhbmQgZmlyZXdhbGxzIi4gSSBhbSBub3Qgc3VyZSBob3cgdXNlZnVs IHRoaXMgaXMgYXMgYSByZXF1aXJlbWVudC4gVGhlcmUgYXJlIGNlcnRhaW4gdGhpbmdzIHRoYXQg cmVxdWlyZSBBTEdzIHRvIGJlIHVzZWQsIHN1Y2ggYXMgcGFzc2luZyBhbiBJUCBhZGRyZXNzIGxp dGVyYWwgaW4gYSBtZXNzYWdlLiBBIGdvb2QgcmVxdWlyZW1lbnQsIHRoZW4sIGlzICJhIGRlY2Fk ZSBwcm90b2NvbCBzaG91bGQgbm90IHBhc3MgbGl0ZXJhbCBJUCBhZGRyZXNzZXMgaW4gbWVzc2Fn ZXMuIg0KDQoxNikgaW4gNC4xLjEuMiAiREVDQURFIFNIT1VMRCByZXF1aXJlIHRoYXQg4oCmIiBE RUNBREUgZG9lcyBub3QgZXhpc3QuIFRoZSBjbG9zZXN0IHRoaW5nIHlvdSBoYXZlIHRvIERFQ0FE RSByZXF1aXJpbmcgc29tZXRoaW5nIGlzIGRvY3VtZW50aW5nIGl0IGluIHRoaXMgcmVxdWlyZW1l bnRzIGRvY3VtZW50LiBTbyBpZiBpdCByZWFsbHkgaXMgYSBSRVFVSVJFTUVOVCwgdGhlbiB3cml0 ZSBhIHJlcXVpcmVtZW50LiBCdXQgeW91IHNob3VsZCBiZSBhYmxlIHRvIGp1c3RpZnkgV0hZIHRo aXMgaXMgYSByZXF1aXJlbWVudC4NCg0KSXMgdGhlcmUgYW4gYXNzdW1wdGlvbiBoZXJlIHRoYXQg dGhlIHNlcnZlciBpcyBwdWJsaWNseSBhY2Nlc3NpYmxlLCBhbmQgdGhlIGNsaWVudCBpcyBiZWhp bmQgYSBOQVQ/IFdoYXQgaWYgdGhlIHNlcnZlciBpcyBiZWhpbmQgYSBmaXJld2FsbCwgYW5kIHRo ZSBjbGllbnQgaXMgbm90PyBXaGF0IGlmIHRoZSBjbGllbnQgYW5kIHRoZSBzZXJ2ZXIgYXJlIGJv dGggYmVoaW5kIGZpcmV3YWxscz8gV2hhdCBpZiBhIHByb3RvY29sIGhhcyBhIGNhbGxiYWNrIGZl YXR1cmUgaW4gb3JkZXIgdG8gd29yayBhcm91bmQgdGhpcyBzaXR1YXRpb24gKHRoZSBjbGllbnQg Y2FuIHNlbmQgYSBtZXNzYWdlIG91dCBvZiBiYW5kIGFza2luZyB0aGUgc2VydmVyIHRvIGluaXRp YXRlIHRoZSBjb25uZWN0aW9uKT8NCg0KMTcpIGluIDQuMS4yLjEgIkRFQ0FERSBNVVNUIGNvbnRh aW4gYSBtb2RlIiAtIHdoYXQgaXMgREVDQURFPyBhcmUgeW91IHJlZmVycmluZyB0byBhIGNsaWVu dC1zZXJ2ZXIgcHJvdG9jb2w/DQpXaGF0IE1VU1QgYmUgaW1wbGVtZW50ZWQ/IA0KDQoxOCkgaW4g NC4xLjIuMSwgREVDQURFIE1VU1QgY29udGFpbiBhIFtzZWN1cmVdIG1vZGUiLiBQbGVhc2Ugc2Vl IFJGQzM2NjguIEkgdGhpbmsgYW55IG5ldyBwcm90b2NvbCBNVVNUIGJlIGltcGxlbWVudGVkIHdp dGggc3Ryb25nIHNlY3VyaXR5LiBTdGFuZGFyZCBzZWN1cml0eSBwcm90b2NvbHMgdHlwaWNhbGx5 IGhhdmUgbm9uLXNlY3VyZSBjcnlwdG8gYWxnb3JpdGhtcyB0aGF0IGFuIG9wZXJhdG9yIGNhbiBj aG9vc2UgdG8gdXNlLiBEZWZpbmluZyAibW9kZXMiIG1ha2VzIGEgcHJvdG9jb2wgbW9yZSBjb21w bGV4Lg0KDQoxOSkgaW4gNC4xLjMuMSBzYXlzIFthIHN0b3JhZ2Ugc3lzdGVtXSAibXVzdCBub3Qg YmUgcmVxdWlyZWQgdG8gZ2VuZXJhdGUgcmVzcG9uc2VzIjsgNC4xLjMuMiBzYXlzICJNVVNUIFtp bmRpY2F0ZSB0b10gYSBERUNBREUgY2xpZW50IjsgU28gaXNuJ3QgdGhpcyByZXF1aXJpbmcgYSBy ZXNwb25zZT8NCg0KMjApIDQuMS4zLjIgInNpbmNlIHRoZSByZXNvdXJjZXMg4oCmIGFyZSBub3Qg ZGlyZWN0bHkgYXR0YWNoZWQiOyBob3cgZG8gd2Uga25vdyB0aGV5IGFyZSBub3QgZGlyZWN0bHkg YXR0YWNoZWQ/IFdoYXQgaWYgc29tZSBvZiB0aGUgcmVzb3VyY2VzIGFyZSBkaXJlY3RseSBhdHRh Y2hlZCBhbmQgb3RoZXJzIGFyZSBub3QsIGFzIGluIE5GUyBvciBTQ1NJPw0KDQoyMSkgaW4gNC4x LjMuMiwgd2h5IG5vdCBtYWtlIHVzYWdlIG9uIHJlbW90ZSBzdG9yYWdlIGRpc2NvdmVyYWJsZSwg c3VjaCBhcyB3aXRoIHRoZSBIb3N0IFJlc291cmNlcyBNSUIgW1JGQzI3OTBdPyANCg0KMjIpIDQu MS4zLjMgaWYgYWNjZXNzIHRvIHRoZSBkYXRhIGhhcyBiZWVuIGlkZW50aWZpZWQgYXMgaWxsZWdh bCwgdGhlbiB0aGUgcmVxdWVzdG9yIGlzIHByZXN1bWFibHkgYWN0aW5nIGlsbGVnYWxseS4gd2h5 IGFyZSB3ZSByZXF1aXJlZCB0byByZXNwb25kIHRvIGlsbGVnYWwgcmVxdWVzdHM/IENvdWxkbid0 IHRoaXMgaGVscCBhbiBhdHRhY2tlciBkZXRlcm1pbmUgdGhhdCB0aGUgZGF0YSBleGlzdHMgYW5k IHBvc3NpYmx5IG90aGVyIGF0dHJpYnV0ZXMgb2YgdGhlIGRhdGE/DQoNCjIzKSBpbiA0LjEuMy40 IE5vdGUgdGhhdCAiTm90ZSB0aGF0IiBpc24ndCBuZWVkZWQuIDstKQ0KDQoyNCkgaW4gNC4yLjEs IHRoZSBzZW50ZW5jZSBzdGFydGluZyAiQWRkaXRpb25hbGx5LCIgLSBpcyB0aGlzIGEgc2VwYXJh dGUgcmVxdWlyZW1lbnQ/IGlzIHRoaXMgcmVhbGx5IGEgcmVxdWlyZW1lbnQ/IA0Kd2hhdCBpZiBh IHVzZXIgaGFzIHR3byB3YXlzIHRvIGRlbGl2ZXIgY29udGVudCwgb25lIHVzaW5nIGluLW5ldHdv cmsgc3RvcmFnZSBvdmVyIGFuIGluZXhwZW5zaXZlIG5ldHdvcmsgc3VjaCBhcyB3aWZpLCBhbmQg YW4gZXhwZW5zaXZlIHVwbGluayBzdWNoIGFzIDNHLiBDYW4gdGhlIG9wZXJhdG9yIGNob29zZSB0 byBhbGxvdyBsYXRlbmN5IGluIGRlbGl2ZXJ5IG92ZXIgdGhlIHdpZmkgbmV0d29yayB0aGF0IGV4 Y2VlZHMgdGhlIGxhdGVuY3kgb2YgdGhlIDNHIG5ldHdvcms/DQoNCjI1KSBpbiA0LjIuMSwgIkRF Q0FERSBNVVNUIGFsbG93IGNsaWVudHMgdG8gc3BlY2lmeSDigKYiIEhvdyBhYm91dCByZXdvcmRp bmcgdGhpcyB0byBiZSBhYm91dCB0aGUgcmVxdWlyZW1lbnRzIG9mIHRoZSBjbGllbnQgYWxsb3dp bmcgdGhlIHVzZXIgdG8gc3BlY2lmeSBwb2xpY3ksIHRoZSBwcm90b2NvbCBjYXJyeWluZyB0aGUg KHBvbGljeSkgc3BlY2lmaWNhdGlvbiwgYW5kIHRoZSByZXF1aXJlbWVudHMgb2YgdGhlIHNlcnZl ciB0byBlbmZvcmNlIHN1Y2ggKHBvbGljeSkgc3BlY2lmaWNhdGlvbnMuIERFQ0FERSBkb2Vzbid0 IGV4aXN0IGFuZCBjYW5ub3QgYWxsb3cgYSBjbGllbnQgdG8gZG8gYW55dGhpbmcuDQoNCjI2KSA0 LjIuMiB0YWxrcyBhYm91dCBlZmZpY2llbnQgZGVsaXZlcnkgYW5kIGxhdGVuY3kgYW5kIGhhbmRs aW5nIHNtYWxsIGFuZCBsYXJnZSBvYmplY3RzLiBUaGUgRkVDIGZyYW1ld29yayAoUkZDNjM2Mykg YWxsb3dzIGRpZmZlcmVudCBGRUMgc2NoZW1lcyB0byBhY2NvbW1vZGF0ZSBkaWZmZXJlbnQgc2Nl bmFyaW9zIHRoYXQgaGF2ZSBkaWZmZXJlbnQgcmVxdWlyZW1lbnRzIG9uIGxhdGVuY3ksIGJsb2Nr IHNpemVzLCBldGMuIFBsZWFzZSBjb25zaWRlciB0aGlzIElFVEYgc3RhbmRhcmQgd2l0aGluIHRo ZSBwcm9wb3NlZCBkZWNhZGUgc3lzdGVtLg0KDQoyNykgNC4yLjMgYWxsb3dzIHNlcnZlcnMgdG8g dHJhbnNmZXIgZGF0YSBkaXJlY3RseSwgc3ViamVjdCB0byB0aGUgYXV0aG9yaXphdGlvbiBpbiA0 LjcuIEkgZG9uJ3Qgc2VlIGhvdyB0aGUgcmVxdWlyZW1lbnRzIGluIDQuNyBmaXQgdGhpcyBzcGVj aWZpYyBjYXNlLiBDYW4geW91IG1ha2UgdGhpcyBjbGVhcmVyPyANCg0KMjgpIDQuMi4zIHJhdGlv bmFsZSAtIGhvdyBkb2VzIHRoaXMgYWZmZWN0IHRoZSByZXF1aXJlbWVudHMgZm9yLCBzYXksIHBy b3RvY29scz8gYW5kIHNlcnZlcnM/DQoNCjI5KSA0LjMuMSAiREVDQURFIE1VU1Qgc3VwcG9ydCIg LSB3aGF0IG11c3QgdGhlIGNsaWVudCBhbmQgdGhlIHNlcnZlciBhbmQgdGhlIHByb3RvY29sIHN1 cHBvcnQ/IFBsZWFzZSBiZSBzcGVjaWZpYy4NCg0KMzApIDQuMy4yICJERUNBREUgTVVTVCBzdXBw b3J0Ijsgbm8sIHRoZSBzZXJ2ZXIgbXVzdCBiZSBhYmxlIHRvIGJlIGNvbmZpZ3VyZWQgdG8gYWNj ZXB0IGFuZCBlbmZvcmNlIGFjY2VzcyBjb250cm9sIHBvbGljZXMgdGhhdCBwZXJtaXQg4oCmOyBN VVNUIHRoZSBjbGllbnQgKHRoZSBhcHBsaWNhdGlvbiBJIGd1ZXNzKSBwZXJtaXQgdXNlcnMgdG8g c3BlY2lmeSBwb2xpY2llcyBhcyBwYXJ0IG9mIGl0cyB1c2VyIGludGVyZmFjZT8gb3IgY291bGQg dGhpcyBiZSBkb25lIHVzaW5nIGEgbm9uLWRlY2FkZSBwcm90b2NvbCwgc3VjaCBhcyBTTk1QIG9y IG5ldGNvbmYgb3IgdGhlIGNsaT8gTVVTVCB0aGUgZGVjYWRlIHByb3RvY29sIGJlIGRlc2lnbmVk IHRvIGNhcnJ5IHRoZSBwb2xpY2llcyBmcm9tIGNsaWVudCB0byBzZXJ2ZXI/IFdoeSBub3QgdXNl IHNvbWV0aGluZyBsaWtlIEFBQSBpbnN0ZWFkLCBzbyB0aGUgaW1wbGVtZW50YXRpb24gb2YgYSBk ZWNhZGUtc3BlY2lmaWMgZnVuY3Rpb25hbGl0eSBpbiB0aGUgY2xpZW50IGFuZCBwcm90b2NvbCBh bmQgc2VydmVyIGlzIHNpbXBsaWZpZWQ/DQoNCjMxKSBhcyBhIG1lbWJlciBvZiB0aGUgc2VjdXJp dHkgZGlyZWN0b3JhdGUsIEkgcXVlc3Rpb24gd2hldGhlciA0LjMuMiBzcGVjaWZpZXMgYSBnb29k IHJlcXVpcmVtZW50IC0gIkRFQ0FERSBhbGxvd3MgYSB1c2VyIHRvIGltcGxlbWVudCBhY2Nlc3Mg Y29udHJvbCBwb2xpY2llcyBmb3IgdXNlcnMgdGhhdCBtYXkgb3IgbWF5IG5vdCBiZSBrbm93biB0 byB0aGUgc3RvcmFnZSBwcm92aWRlci4iIFRoaXMgc2hvdWxkIGJlIHNwZWNpZmllZCBtb3JlIGNs ZWFybHkuIEkgdGhpbmsgd2hhdCB5b3Ugd2FudCB0byBzYXkgaXMgdGhhdCBhIHVzZXIgY2FuIGJl IGF1dGhlbnRpY2F0ZWQgYW5kIGF1dGhvcml6ZWQgYnkgYW5vdGhlciB1c2VyLiBUaGUgc2VydmVy IGFjY2VwdHMgdGhlIGF1dGhlbnRpY2F0aW9uIG9mIGEgdXNlciBub3Qga25vd24gdG8gaXQsIGRv bmUgYnkgYSB1c2VyIGtub3duIHRvIGl0LCBhbmQgZ3JhbnRzIGFjY2VzcyBiYXNlZCBvbiB0aGUg YXV0aG9yaXphdGlvbiBwcm92aWRlZCBieSB0aGUga25vd24gdXNlci4NCg0KUGxlYXNlIG1ha2Ug c3VyZSB0aGVzZSBhY2Nlc3MgcG9saWNpZXMgYW5kIHJlZmVycmFscyBhcmUgY29uc2lzdGVudCB3 aXRoIG90aGVyIElFVEYgcHJvdG9jb2xzLCBzdWNoIGFzIE5GUyBhbmQgSFRUUC4NCg0KMzIpIDQu My40IFtwcm90b2NvbHNdICJNVVNUIG9ubHkgcHJvdmlkZSBhIG1pbmltYWwgc2V0IjsgSSB0aGlu ayB0aGlzIGlzIHBocmFzZWQgaW5jb3JyZWN0bHkuIE11c3QgcHJvdmlkZSBhIG1pbmltYWwgc2V0 IGFuZCBNQVkgcHJvdmlkZSBhZGRpdGlvbmFsIA0KDQpJIHRoaW5rIHdlIG1pZ2h0IGJlIHNwZWNp ZnlpbmcgY29tcGxpYW5jZSB0aGUgd3Jvbmcgd2F5LiBUaGUgcmVxdWlyZW1lbnQgaXMgdGhhdCB0 aGUgc3BlY2lmaWNhdGlvbnMgbXVzdCBwcm92aWRlIGNvcmUgZnVuY3Rpb25hbGl0eSBidXQgbWF5 IGFsbG93IGZsZXhpYmlsaXR5IGZvciBleHRlbnNpb25zLg0KDQozMykgNC40LjEgIkRFQ0FERSBT SE9VTEQgcmVtYWluIGFnbm9zdGljLiIgYWdhaW4sIGRlY2FkZSBkb2Vzbid0IGRvIGFueXRoaW5n LiBhbmQgSSBoYXZlIG5vIGlkZWEgaG93IEkgd291bGQganVkZ2Ugd2hldGhlciBhbiBpbXBsZW1l bnRhdGlvbiB3YXMgY29tcGxpYW50IHRvIHRoaXMgcmVxdWlyZW1lbnQuDQoNCjM0KSA0LjQuMSAi YSBjb21wbGlhbnQgY2xpZW50ICJzaG91bGQgYmUgYWJsZSB0byB1c2UiOyBsZXQncyB0dXJuIHRo aXMgYXJvdW5kLiB3aGF0IE1VU1QgYSBjb21wbGlhbnQgY2xpZW50IGltcGxlbWVudGF0aW9uIHN1 cHBvcnQgc28gdGhhdCBhIHVzZXIgY2FuIHVzZSDigKY/IE1VU1QgaXMgZm9yIGltcGxlbWVudGVy czsgU0hPVUxEIGlzIGZvciB1c2Vycy4gQSB1c2VyIGNhbm5vdCB1c2Ugc29tZXRoaW5nIHRoYXQg YW4gaW1wbGVtZW50ZXIgZGlkbid0IGJvdGhlciB0byBpbXBsZW1lbnQuIFNvIHdoYXQgTVVTVCBh biBpbXBsZW1lbnRlciBwcm92aWRlIHNvIGEgdXNlciBjYW4gdXNlPw0KDQphbmQgYmUgY2FyZWZ1 bDsgaWYgeW91IHNheSBhbiBpbXBsZW1lbnRlciBNVVNUIHN1cHBvcnQgYSBidW5jaCBvZiBvcHRp b25hbCBzZXJ2aWNlcywgaG93IHdpbGwgeW91IGFjaGlldmUgaW50ZXJvcGVyYWJpbGl0eSBhY3Jv c3MgZGlmZmVyZW50IGltcGxlbWVudGF0aW9ucyBpZiB2ZW5kb3IgQSBpbXBsZW1lbnRzIG9ubHkg b3B0aW9uIDEsIGJ1dCB2ZW5kb3IgQiBpbXBsZW1lbnQgb25seSBvcHRpb24gMj8NCg0KMzUpIGlu IDQuNC4yLCAiREVDQURFIHByb3RvY29sKHMpIG11c3QgYmUgZGVzaWduZWQiOyAiSWYgdGhlcmUg aXMgYSBuZWVkIHRvIGRlc2lnbiBhbnkgREVDQURFIHByb3RvY29scywgdGhleSBTSE9VTEQgYmUg ZGVzaWduZWQgc3VjaCB0aGF0IOKApiINCg0KMzYpIDQuNC4zLCA0LjQuNCAiREVDQURFIE1VU1Qi LCAiREVDQURFIE1BWSIgLSBwdXQgdGhpcyBpbnRvIGNsaWVudC9zZXJ2ZXIvcHJvdG9jb2wgZm9y bSBwbGVhc2UuDQoNCjM3KSA0LjUuMSAiaGlnaCBwcm9iYWJpbGl0eSBvZiB1bmlxdWVuZXNzIiAt IHdoYXQgaGFwcG5lcyBpIHRoZXJlIGlzIGEgY29sbGlzaW9uPyBzcGVsbCBvdXQgdGhlIHBvdGVu dGlhbCBpbXBhY3QgaWYgdGhlcmUgaXMgYSBjb2xsaXNpb24uIA0KDQozOCkgNC41LjEgIndpdGgg bm8gY29vcmRpbmF0aW9uIjsgSSBkaXNhZ3JlZSB3aXRoIHRoaXMuIFlvdSBhcmUgcHJlc3VtYWJs eSB0YWxraW5nIGFib3V0IHBvbGljeS1iYXNlZCBjb29yZGluYXRpb24sIHdpdGggbm8gcmVhbHRp bWUgdXNlciBjb29yZGluYXRpb24uDQoNCjM5KSA0LjYuMSB3aGVyZSBpcyB0ZSBlbmZvcmNlbWVu dCBkb25lPyB3aGljaCBhY3RvcnMgbXVzdCBkbyB3aGF0PyBob3cgaXMgdGhlIG11bHRpcGxlLWFw cGxpY2F0aW9uIHBvbGljeSBjb25maWd1cmVkPyB3aGF0IGRhdGEgc2hvdWxkIGJlIGNvbmZpZ3Vy YWJsZT8gaWYgeW91IHVzZSBvdXQtb2YtYmFuZCBtZWNoYW5pc21zLCBob3cgd2lsbCB5b3UgYWNo aWV2ZSBpbnRlcm9wZXJhYmlsaXR5IGFjcm9zcyB2ZW5kb3JzPw0KDQo0MCkgNC42LjIsICJvbmx5 IGEgY2VydGFpbiBhbW91bnQgb2YgZGF0YSIgaXMgdGhpcyByZWZlcnJpbmcgdG8gdGhlIHRvdGFs IGFtb3VudCBvZiBkYXRhLCBvciBibG9jayBzaXplcywgb3IgcGVyLW9wZXJhdGlvbj8NCg0KNDEp IEkgdGhpbmsgaW4gbWFueSBvZiB0aGVzZSByZXF1aXJlbWVudHMsIGl0IHdvdWxkIGJlIGhlbHBm dWwgdG8gcG9pbnQgb3V0IHRoZSBhcHBsaWNhYmlsaXR5IG9mIGV4aXN0aW5nIHByb3RvY29scyBs aWtlIERpYW1ldGVyLg0KDQo0MikgNC43LjQgSSBxdWVzdGlvbiB3aGV0aGVyIG9wdGltaXphdGlv bnMgc2hvdWxkIHBlcm1pdCBhIHNlcnZlciB0byBub3QgY2hlY2sgYXV0aG9yaXphdGlvbi4gWW91 IHNob3VsZCBiZSBzcGVjaWZ5aW5nIHdoYXQgaXMgcmVxdWlyZWQgZm9yIGNvbXBsaWFuY2UuIElm IHVuYXV0aG9yaXplZCByZXF1ZXN0cyBhciBub3QgZGVuaWVkLCB0aGVuIHlvdSBhcmUgZGVhbGlu ZyB3aXRoIGEgbm9uLWRlY2FkZS1jb21wbGlhbnQgc2VydmVyLiBQbGVhc2UgZG9uJ3Qgd3JpdGUg cmVxdWlyZW1lbnRzIHNheWluZyBpdCBpcyBhY2NlcHRhYmxlIGZvciBzZXJ2ZXJzIHRvIG5vdCBk ZW55IGFjY2VzcyBmb3IgdW5hdXRob3JpemVkIHJlcXVlc3RzLg0KDQo0MykgNC43LjUgIm5vdCBz aW1wbHkgYnkgdHlpbmcgYWNjZXNzIHRvIElQIGFkZHJlc3NlcyIgLSBJIHRoaW5rIHR5aW5nIGFj Y2VzcyB0byBhIGxpdGVyYWwgSVAgYWRkcmVzcyBpcyBhIGJhZCBpZGVhIGFuZCBzaG91bGQgYmUg YSBTSE9VTEQgTk9UIChpZiBub3QgYSBNVVNUIE5PVCkuIEFsbG93aW5nIHRoZSB1c2Ugb2YgbGl0 ZXJhbCBhZGRyZXNzZXMgY291bGQgbGVhZCB0byB0aGUgbmVlZCBmb3IgQUxHcy4NCg0KNDQpIDQu Ny42IHNvIHdoYXQgaXMgdGhlIGRpZmZlcmVuY2UgYmV0d2VlbiB0aGlzIGFuZCA0LjYuMz8gDQoN CjQ1KSA0LjggaXMgIm5vbi1yZXF1aXJlbWVudHMiLCBidXQgNC44LjEgc3RhdGVzIGEgcmVxdWly ZW1lbnQgKE1VU1QgTk9UKS4gW2FuZCBwbGVhc2UgZ2V0IHJpZCBvZiB0aGUgIkRFQ0FERSBNVVNU IiBmb3JtdWxhdGlvbnMuIHNpZ2guDQoNCjQ2KSA1LjEgIk1VU1Qgb25seSBzdG9yZSBhbmQgbWFu YWdlIGRhdGEiIC0gSSB0aGluayB5b3UgbWVhbiAiTVVTVCBzdG9yZSBhbmQgbWFuYWdlIG9ubHkg ZGF0YSINCg0KNDcpIDUuMSBoZXJlIGltbXV0YWJsZSBvYmplY3RzIGFyZSBNVVNULCBjb21wYXJl ZCB0byBzZWN0aW9uIDEgd2hlcmUgaW1tdXRhYmlsaXR5IGlzIHR5cGljYWwuIA0KDQo0OCkgNS4x IGlmIGltbXV0YWJpbGl0eSBpcyBhIHJlcXVpcmVtZW50LCBob3cgd2VsbCB3aWxsIHRoYXQgd29y ayB3aXRoIGV4aXN0aW5nIHByb3RvY29scz8gRG8gYW55IG9mIHRoZSBleGlzdGluZyBzdG9yYWdl IHByb3RvY29scyByZXF1aXJlIGltbXV0YWJpbGl0eT8gZGF0YSB0cmFuc3BvcnQgcHJvdG9jb2xz PyBzdG9yYWdlIHByb3RvY29sIHN0YW5kYXJkcyBmdW5jdGlvbmFsaXR5IGxpa2UgZGVkdXA/DQoN CjQ5KSA1LjMgRG8gZXhpc3Rpbmcgc3RhbmRhcmRzIGhhdmUgc3VjaCBhIHJ1bGUsIG9yIGhhdmUg dGhleSBhbHJlYWR5IGRlYWx0IHdpdGggdGhlIGNvbXBsZXhpdHkgb2YgbXVsdGlwbGUgd3JpdGlu Zz8gSXQgaXMgYSBjb21tb24gc2NlbmFyaW8gaW4gdGhlIElFVEYgdGhhdCBhIG5ldyBwcm90b2Nv bCBkZXNpZ24gdHJpZXMgdG8gc2ltcGxpZnksIGJ1dCBpbiB0aGUgZW5kIHlvdSBlbmQgdW8gcmVp bnZlbnRpbmcgdGhlIHdob2xlIGJhbGwgb2Ygd2F4IHRvIGRlYWwgd2l0aCByZWFsLXdvcmxkIG5l ZWRzLg0KDQo1MCkgNS41LiBTbyBvdGhlciByZXF1aXJlbWVudHMgYXIgaGVyZSBleHBsaWNpdGx5 IHRvIGF2b2lkIGNvbXBsZXhpdHksIGJ1dCBpbiB0aGlzIHNpbXBsZXN0IG9mIHNjZW5hcmlvcywg eW91IGFkZCBjb21wbGV4aXR5IGJ5IGFsbG93aW5nIHJlYWRzIGJlZm9yZSB0aGUgd3JpdGUgaXMg Y29tcGxldGUuIEdvIGZpZ3VyZS4gVGhpcyBtYXkgc2ltcGxpZnkgdGhlIHNlcnZlciBzaWRlLCBi dXQgeW91IHdpbGwgaW5jcmVhc2UgdGhlIGNvbXBsZXhpdHkgb2YgdGhlIGNsaWVudCBzaWRlIHdo ZW4gdGhlIHdyaXQgZmFpbHMgYW5kIHRoZSBzdWJzZXF1ZW50IHJlYWQgaXMgYWJvcnRlZCBtaWQt cmVhZCwgYW5kIHNvIG9uLg0KDQo1MSkgNS42IGFsbG93cyBhcHBsaWNhdGlvbnMgdG8gcHJvdmlk ZSBhcHBsaWNhdGlvbi1zcGVjaWZpYyBoaW50cyBhYm91dCB0aGUgZGF0YSwgZXZlbiB0aG91Z2gg NC44LjEgc2F5cyBERUNBREUgTVVTVCBOT1QgcHJvdmlkZSBhIG1lY2hhbmlzbSBmb3IgYXNzb2Np YXRpbmcgYXBwbGljYXRpb24tZGVmaW5lZCBtZXRhZHRhIHByb3BlcnRpZXMgd2l0aCBkYXRhLg0K DQo1Mikgd2hhdCBoYXBwZW5zIGlmIGRhdGEgYXJyaXZlcyBvdXQgb2Ygb3JkZXIgZHVlIHRvIGNv bmdlc3Rpb24gb3Igb3RoZXIgbmV0d29yayBpc3N1ZXM/IFNob3VsZCB0aGUgYXBwZW5kIGFwcGVu ZCB0aGUgZGF0YSBpbiB0aGUgb3JkZXIgcmVjZWl2ZWQ/IFlvdSBrbm93LCBtYW55IGV4aXN0aW5n IHN0YW5kYXJkIHByb3RvY29scyBhbHJlYWR5IGtub3cgaG93IHRvIGhhbmRsZSBzaXR1YXRpb25z IGxpa2UgdGhpcy4gV2h5IHJlaW52ZW50IHRoZSB3aGVlbD8gb3IgZG8geW91IHdhbnQgdG8gUkVR VUlSRSBpbi1vcmRlciBkZWxpdmVyeT8NCg0KNTMpIDUuOCAiTVVTVCBzdXBwb3J0IFthZ2dyZWdh dGVkXSBkYXRhLiIgWW91IGFyZSByZWludmVudGluZyBtb25pdG9yaW5nLiBUaGUgSUVURiBtb2Rl bCwgc3VjaCBhcyBTTk1QLCB0eXBpY2FsbHkgc2F5cyB0aGUgY2xpZW50IG9wZXJhdGVzIG9uIGEg aG9zdCwgd2hlcmUgdGhlcmUgYXJlIHR5cGljYWxseSBwbGVudHkgb2YgcmVzb3VyY2VzLiBUaGUg c2VydmVyIHJ1bnMgaW4gYW4gZW52aXJvbm1lbnQgc2F0aXNmeWluZyBwb3RlbnRpYWxseSBtYW55 IHVzZXJzLCBhbmQgcmVzb3VyY2VzIGNhbiBiZWNvbWUgc2NhcmNlLiBUaGUgc2VydmVyIHNob3Vs ZCBwcm92aWRlIHRoZSBiYXNlIHN0YXRpc3RpY3MgYW5kIGxldCB0aGUgY2xpZW50IGRvIHRoZSBh Z2dyZWdhdGlvbiwgc28gd2UgZG9uJ3Qgd2FzdGUgc2NhcmNlIHJlc291cmNlcyAoQ1BVLCBtZW1v cnksIGV0Yy4pIGRvaW5nIGFnZ3JlZ2F0aW9uIGNhbGN1bGF0aW9ucyBhdCB0aGUgc2VydmVyLg0K DQo1NCkgNS44ICdUaGUgcmV0dXJuZWQgaW5mb3JtYXRpb24gTVVTVCBpbmNsdWRlIHJlc291cmNl IHVzYWdlIG9mIFtzZWxmXSBhbmQgW290aGVyc10iLiBXaHkgbXVzdCBlYWNoIHJldHVybiBpbmNs dWRlIGFsbCB0aGlzIGluZm8/IHdoeSBub3QgbWFrZSBpdCBwb3NzaWJsZSB0byByZXF1ZXN0IHRo ZSBkYXRhIG5lZWRlZCBieSB0aGUgYXBwbGljYXRpb24gdGhhdCB3aWxsIHVzZSBpdD8gYW5kIHlv dSBzaG91bGQgTk9UIGFzc3VtZSB0aGF0IG9ubHkgb25lIGFwcGxpY2F0aW9uIC0gYSBzcGVjaWZp YyBkZWNhZGUgY2xpZW50IC0gd2lsbCB3YW50IHRoaXMgaW5mb3JtYXRpb24uIE5ldHdvcmsgYWRt aW5zIG1pZ2h0IHdhbnQgdGhpcyB0byBzZWUgd2hhdCBpbXBhY3QgdGhpcyBzdG9yYWdlIGlzIGhh dmluZyBvbiBuZXR3b3JrIGNvbmdlc3Rpb247IHN0b3JhZ2UgYWRtaW5zIG1pZ2h0IHdhbnQgdG8g bW9uaXRvciAoYW5kIGJpbGwpIGZvciB1c2FnZTsgbG9jYWwgYWRtaW5zIG1pZ2h0IHdhbnQgaXQg dG8gYmlsbDsgcmVtb3RlIGFkbWlucyBtaWdodCB3YW50IHRpIGNvbXBhcmUgdG8gU0xBcywgYW5k IHNvIG9uLiBBbmQgc29tZSB0b29scyBtaWdodCB3YW50IHRvIHRha2UgdGhlIGRlY2FkZSBzdGF0 cyBhbmQgY29tcGFyZSB0aGVtIHRvIHN0YXRzIG9mIHJhdGhlciBhc3BlY3RzIG9mIHRoZSBuZXR3 b3JrLiBTbyB0aGlzIGluZm8gc2hvdWxkIHByb2JhYmx5IHVzZSBhIHN0YW5kYXJkIHRlY2hub2xv Z3kgc3VjaCBhcyBhIE1JQiByYXRoZXIgdGhhbiByZWludmVudGluZyBhbGwgb2YgdGhpcyBhcyBi ZWluZyBkZWNhZGUtc3BlY2lmaWMuIA0KDQo1NSkgIDUuOCAiaXQgaXMgbm90IHJlcXVpcmVkIHRo YXQgZGVjYWRlIHN1cHBvcnQgcmV0dXJuaW5nIGluZm8gYnJva2VuIGRvd24gYnkgW2NsaWVudF0i IC0gd2h5IG5vdD8gdGhpcyBhZ2FpbiBnZXRzIGludG8gbWFuZGF0b3J5LXRvLWltcGxlbWVudCwg YW5kIGludGVyb3BlcmFiaWxpdHkuIElmIHNvbWUgdmVuZG9ycyBjaG9vc2Ugbm90IHRvIHByb3Zp ZGUgdGhlIGluZm8gbXkgY2xpZW50LCBhbmQgc29tZSBkbywgaG93IHdpbGwgeW91IGFjaGlldmUg aW50ZXJvcGVyYWJpbGl0eSBhY3Jvc3MgaW1wbGVtZW50YXRpb25zPyBIb3cgdXNlZnVsIGlzIHRo ZSBpbmZvIGlmIGEgdG9vbCB3YW50cyB0byBhY2NvdW50IGZvciBhbGwgdGhlIHVzYWdlIGZyb20g YSBnaXZlbiBjbGllbnQsIGJ1dCBzb21lIGNvbXBsaWFudCBzZXJ2ZXJzIHByb3ZpZGUgdGhpcyBh bmQgb3RoZXJzIGRvIG5vdD8NCg0KNTYpIDYuLjEuMiBuZWVkcyBtb3JlIGRldGFpbCBhcyB0byB3 aHkgdGhpcyBpcyBhIHJlcXVpcmVtZW50LiBFdmVyeWJvZHkga25vd3MgdGhhdCBBTEdzIGNhbiBt YWtlIHByb2Nlc3NpbmcgbW9yZSBkaWZmaWN1bHQsIGJ1dCBpcyB0aGlzIGFjdHVhbGx5IGEgIk1V U1QgTk9UIGFsbG93IHRoZSB1c2Ugb2YgYWRkaXRpb25hbCBuZXR3b3JrIHN1cHBvcnQiPyAgSXQg Y2VydGFpbmx5IG1ha2VzIHNlbnNlIHRvIG1ha2Ugc3VwcG9ydCBmb3IgTkFUcyBhbmQgZmlyZXdh bGxzIGEgcmVxdWlyZW1lbnQsIGJ1dCB0byB0aGVuIHNheSBhZGRpdGlvbmFsIG5ldHdvcmsgc3Vw cG9ydCBpcyBub3QgYWxsb3dlZCBtYWtlcyBsaXR0bGUgc2Vuc2UgaWYgdGhlIHN0YW5kYXJkIG1l Y2hhbmlzbSBpcyB0byBoYXZlIGFkZGl0aW9uYWwgbmV0d29yayBzdXBwb3J0LiBFc3BlY2lhbGx5 IGZvciBlbnZpcm9ubWVudHMgd2hlcmUgdGhhdCBjb250ZW50IG1pZ2h0IG5lZWQgdG8gY3Jvc3Mg b25lIG9yIG1vcmUgdjR2NiBib3VuZGFyaWVzLCB0aGF0IGFkZGl0aW9uYWwgbmV0d29yayBzdXBw b3J0IGlzIGxpa2VseSB0byBiZSBjcml0aWNhbC4NCg0KNTcpIDcuMSwgdGhlIHN0b3JhZ2UgYWRt aW4gc2hvdWxkIGJlIGFibGUgdG8gYXNzaWduIHF1b3RhcyBhbmQgc28gb24sIGJ1dCBpdCBpcyBu b3QgbmVjZXNzYXJpbHkgZHJpdmVuIGJ5IGZhaXJuZXNzLiBNYXliZSBpdCBoYXMgdG8gZG8gd2l0 aCB0aGUgbmVnb3RpYXRlZCBTTEEsIHByZW1pdW0gc2VydmljZXMsIGFuZCBzbyBvbi4gVW5sZXNz IHlvdSBhcmUgZ29pbmcgdG8gZGVmaW5lIHRlY2huaWNhbCBtZWNoYW5pc21zIHRvIGRldGVybWlu ZSBmYWlybmVzcywgdGhpcyBkb2Vzbid0IHJlYWxseSBiZWxvbmcgaW4gYW4gSUVURiBkb2N1bWVu dC4gDQoNCjU4KSBJIHF1ZXN0aW9uIHdoZXRoZXIgc2VjdCA3IGlzIHJlYWxseSB1c2VmdWwuIEVp dGhlciB5b3UgaGF2ZSBhIHJlcXVpcmVtZW50IG9yIHlvdSBkb24ndC4gVGhlc2UgZG9uJ3QgbG9v ayBsaWtlIHJlcXVpcmVtZW50cyB0byBtZS4gSWYgdGhpcyBzZWN0aW9uIGxpc3RzIHRoaW5ncyB0 aGF0IGFyZSBvdXQgb2Ygc2NvcGUsIHRoZW4geW91IHByb2JhYmx5IHNob3VsZCBhbHNvIGJlIGxp c3RpbmcgRFJNIGFzIGEgZnV0dXJlIGNvbnNpZGVyYXRpb24gdGhhdCBpcyBvdXQtb2Ytc2NvcGUu IEdhbWluZyB0aGUgc3lzdGVtIHNob3VsZCBiZSBpbmNsdWRlZCBpbiB0aGUgc2VjdXJpdHkgY29u c2lkZXJhdGlvbnMsIGJ1dCByZWFsbHkgdGhlcmUgc2hvdWxkIGJlIHJlcXVpcmVtZW50cyB0aGF0 IHByZXZlbnQgZ2FtaW5nIHRoZSBzeXN0ZW0uIA0KDQo1OSkgInByb3RvY29scyBhbmQgaW1wbGVt ZW50YXRpb25zIHNob3VsZCBiZSBhd2FyZSIgLSB0aGVzZSBhcmUgbm90IHNlbnRpZW50IHRoaW5n czsgdGhleSBkbyBub3QgaGF2ZSBhd2FyZW5lc3MuIE9wZXJhdG9ycy9hZG1pbnMgaGF2ZSBhd2Fy ZW5lc3MuIA0KDQo2MCkgOC4xLCBhcyBwb2ludGVkIG91dCBlYXJsaWVyLCBzZXJ2ZXJzIERPIGhh dmUgdG8gYXV0aGVudGljYXRlIHVzZXJzLiB0aGV5IGRvIHNvIGJ5IGFjY2VwdGluZyBhdXRoZW50 aWNhdGlvbiBhbmQgYXV0aG9yaXphdGlvbiByZWZlcnJhbCBieSBhbm90aGVyIGVudGl0eS4gDQoN CjYxKSA4LjIgIkRFQ0FERSBpdHNlbGYgZG9lcyBub3QgcHJvdmlkZSIgLSBkZWNhZGUgZG9lcyBu b3QgZXhpc3QuIGl0IGNhbm5vdCBwcm92aWRlIGFueXRoaW5nLiBCdXQgaWYgdGhlIHJlcXVpcmVt ZW50cyBmb3IgZGVjYWRlLWNvbXBsaWFuY2UgaXMgYSBwcm90b2NvbCB0aGF0IHByb3ZpZGVzIGVu Y3J5cHRpb24gYW5kIHRoZSBwcm90b2NvbCBpcyBwYXJ0IG9mIHRoZSBkZWNhZGUgc3lzdGVtLCB0 aGVuIGFwcGFyZW50bHkgZGVjYWRlIGRvZXMgcHJvdmlkZSBlbmNyeXB0aW9uLiBVc2luZyBERUNB REUgYXMgYW4gYWN0b3IgbWFrZXMgdGhpbmcgYW1iaWd1b3VzLiBUYWxrIGluIHRlcm1zIG9mIGNs aWVudHMsIHNlcnZlcnMsIGFuZCBwcm90b2NvbHMgcGxlYXNlLg0KDQo2MikgMTAuMiwgaWYgeW91 IGFyZSByZWZlcmVuY2luZyBkZWZpbml0aW9ucyBpbiBwcm9ibGVtLXN0YXRlbWVudCB0aGF0IG11 c3QgYmUgdW5kZXJzdG9vZCB0byB1bmRlcnN0YW5kIHRoaXMgZG9jdW1lbnQsIHRoZW4gdGhlIHJl ZmVyZW5jZSBpcyBub3JtYXRpdmUuDQoNCg0KSUQgVHJhY2tlciBVUkw6IGh0dHA6Ly9kYXRhdHJh Y2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1kZWNhZGUtcmVxcy8NCg0K From iesg-secretary@ietf.org Tue Feb 21 06:27:52 2012 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 45A7D21F87F2; Tue, 21 Feb 2012 06:27:52 -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 BfkQ8R9dl-sX; Tue, 21 Feb 2012 06:27:47 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2DFC21F87F4; Tue, 21 Feb 2012 06:27:47 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.64p2 Message-ID: <20120221142747.26077.47680.idtracker@ietfa.amsl.com> Date: Tue, 21 Feb 2012 06:27:47 -0800 Cc: decade@ietf.org Subject: [decade] Last Call: (DECoupled Application Data Enroute (DECADE) Problem Statement) to Informational RFC X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org 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, 21 Feb 2012 14:27:52 -0000 The IESG has received a request from the Decoupled Application Data Enroute WG (decade) to consider the following document: - 'DECoupled Application Data Enroute (DECADE) Problem Statement' as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-03-06. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. 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 transit and uplink 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 cache refresh mechanisms) and they do not allow users to manage access to content in the cache. For example, content providers wishing to use in- network storage cannot easily control cache access and resource usage policies to satisfy their own requirements. This document discusses the introduction of in-network storage for P2P applications, and shows the need for a standard protocol for accessing this storage. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-decade-problem-statement/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-decade-problem-statement/ No IPR declarations have been submitted directly on this I-D. From haibin.song@huawei.com Thu Feb 23 18:20:30 2012 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 019A711E8096 for ; Thu, 23 Feb 2012 18:20:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.547 X-Spam-Level: X-Spam-Status: No, score=-6.547 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, 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 sZUx3EKjo7iE for ; Thu, 23 Feb 2012 18:20:29 -0800 (PST) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 5AFF621F86CB for ; Thu, 23 Feb 2012 18:20:27 -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 <0LZV00BQXL5VJ3@szxga05-in.huawei.com> for decade@ietf.org; Fri, 24 Feb 2012 10:20:20 +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 <0LZV00J9RL5V2T@szxga05-in.huawei.com> for decade@ietf.org; Fri, 24 Feb 2012 10:20:19 +0800 (CST) Received: from szxeml214-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AHA55341; Fri, 24 Feb 2012 10:20:13 +0800 Received: from SZXEML411-HUB.china.huawei.com (10.82.67.138) by szxeml214-edg.china.huawei.com (172.24.2.29) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 24 Feb 2012 10:19:39 +0800 Received: from SZXEML534-MBX.china.huawei.com ([169.254.2.222]) by szxeml411-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.003; Fri, 24 Feb 2012 10:19:55 +0800 Date: Fri, 24 Feb 2012 02:20:47 +0000 From: Songhaibin X-Originating-IP: [10.138.41.129] To: "decade@ietf.org" Message-id: MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: zh-CN Content-transfer-encoding: 7BIT Accept-Language: en-US, zh-CN Thread-topic: DECADE meeting in Paris Thread-index: Aczymsq4zXoEHNA8R56CjGM/wJfN1w== X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected Subject: [decade] DECADE meeting in Paris 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, 24 Feb 2012 02:20:30 -0000 Hi all, Our WG meeting at IETF 83 is scheduled as the following. Please note that this schedule is subject to change. Look forward to seeing you in Paris! decade Session 1 (2 hours) Thursday, Afternoon Session II 1520-1720 Room Name: 253 Best Regards, -Haibin (co-chair) From haibin.song@huawei.com Fri Feb 24 00:46:40 2012 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 35CE721F87BF for ; Fri, 24 Feb 2012 00:46:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.25 X-Spam-Level: X-Spam-Status: No, score=-6.25 tagged_above=-999 required=5 tests=[AWL=-0.251, BAYES_00=-2.599, J_CHICKENPOX_62=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 xHwz72diqwwD for ; Fri, 24 Feb 2012 00:46:39 -0800 (PST) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id 6FFD621F87BE for ; Fri, 24 Feb 2012 00:46:39 -0800 (PST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LZW00GIN2XS8X@szxga03-in.huawei.com> for decade@ietf.org; Fri, 24 Feb 2012 16:44:17 +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 <0LZW00KEJ2XST3@szxga03-in.huawei.com> for decade@ietf.org; Fri, 24 Feb 2012 16:44:16 +0800 (CST) Received: from szxeml211-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AHA79303; Fri, 24 Feb 2012 16:44:06 +0800 Received: from SZXEML407-HUB.china.huawei.com (10.82.67.94) by szxeml211-edg.china.huawei.com (172.24.2.182) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 24 Feb 2012 16:43:44 +0800 Received: from SZXEML534-MBX.china.huawei.com ([169.254.2.222]) by szxeml407-hub.china.huawei.com ([10.82.67.94]) with mapi id 14.01.0323.003; Fri, 24 Feb 2012 16:44:04 +0800 Date: Fri, 24 Feb 2012 08:45:04 +0000 From: Songhaibin X-Originating-IP: [10.138.41.129] To: "decade@ietf.org" Message-id: MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: zh-CN Content-transfer-encoding: 7BIT Accept-Language: en-US, zh-CN Thread-topic: Kerberos protocol for DECADE? Thread-index: Aczy0HQ9qFccbmyOS26G2cSDQbWKuQ== X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: EiU= A2l1 Bz6r Cd4A CwCR DlzO Dmph EDmb FT/N Gl4W G0l6 HcHr IaQj JRzP JmIV KoZ3; 1; ZABlAGMAYQBkAGUAQABpAGUAdABmAC4AbwByAGcA; Sosha1_v1; 7; {98C71375-3D9D-4F4E-9D05-DA8C3241F0C1}; aABhAGkAYgBpAG4ALgBzAG8AbgBnAEAAaAB1AGEAdwBlAGkALgBjAG8AbQA=; Fri, 24 Feb 2012 08:44:00 GMT; SwBlAHIAYgBlAHIAbwBzACAAcAByAG8AdABvAGMAbwBsACAAZgBvAHIAIABEAEUAQwBBAEQARQA/AA== x-cr-puzzleid: {98C71375-3D9D-4F4E-9D05-DA8C3241F0C1} X-CFilter-Loop: Reflected Subject: [decade] Kerberos protocol for DECADE? 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, 24 Feb 2012 08:46:40 -0000 Hi all, I heard some voice about using Kerberos protocol for the authentication and resource control in DECADE. So I spend some time reading RFC4120, and find Kerberos is useful in insecure domain to establish a secure channel between a client and server. The Kerberos server assigns a shared session key, which will be responded from Kerberos authentication server(or Ticket granting server) to the client (there are two copies of the session key. One copy is embedded Ticket and encrypted with the server's key, together with the client's ID, and another copy is encrypted in the client's key.) The client and server will use that session key to secure their communication. So my conclusion is Kerberos is to build a secure channel between a client and server in a single domain, while inter-domain will get difficult. It does not look like a good candidate to assign network resources from the in-network storage server for content distribution to DECADE compatible application clients. BR, -Haibin (as individual) From ietfdbh@comcast.net Fri Feb 24 11:19:16 2012 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 0D04121F8853 for ; Fri, 24 Feb 2012 11:19:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.92 X-Spam-Level: X-Spam-Status: No, score=-101.92 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, J_CHICKENPOX_62=0.6, 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 ANR2rLC3B0E3 for ; Fri, 24 Feb 2012 11:19:15 -0800 (PST) Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [76.96.59.243]) by ietfa.amsl.com (Postfix) with ESMTP id 1AC7221F8847 for ; Fri, 24 Feb 2012 11:19:15 -0800 (PST) Received: from omta18.westchester.pa.mail.comcast.net ([76.96.62.90]) by qmta13.westchester.pa.mail.comcast.net with comcast id doUJ1i0061wpRvQ5DvKFuA; Fri, 24 Feb 2012 19:19:15 +0000 Received: from [192.168.1.33] ([71.233.85.150]) by omta18.westchester.pa.mail.comcast.net with comcast id dvJv1i00D3Ecudz3evK97a; Fri, 24 Feb 2012 19:19:15 +0000 User-Agent: Microsoft-MacOutlook/14.14.0.111121 Date: Fri, 24 Feb 2012 14:18:52 -0500 From: David Harrington To: Songhaibin , "decade@ietf.org" Message-ID: Thread-Topic: [decade] Kerberos protocol for DECADE? In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Re: [decade] Kerberos protocol for DECADE? 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, 24 Feb 2012 19:19:16 -0000 I recommend asking the security area directors to provide a security advisor, who can consider your requirements and point you toward an applicable solution. -- David Harrington Director, Transport Area Internet Engineering Task Force (IETF) Ietfdbh@comcast.net +1-603-828-1401 On 2/24/12 3:45 AM, "Songhaibin" wrote: >Hi all, > >I heard some voice about using Kerberos protocol for the authentication >and resource control in DECADE. So I spend some time reading RFC4120, and >find Kerberos is useful in insecure domain to establish a secure channel >between a client and server. The Kerberos server assigns a shared session >key, which will be responded from Kerberos authentication server(or >Ticket granting server) to the client (there are two copies of the >session key. One copy is embedded Ticket and encrypted with the server's >key, together with the client's ID, and another copy is encrypted in the >client's key.) The client and server will use that session key to secure >their communication. > >So my conclusion is Kerberos is to build a secure channel between a >client and server in a single domain, while inter-domain will get >difficult. It does not look like a good candidate to assign network >resources from the in-network storage server for content distribution to >DECADE compatible application clients. > >BR, >-Haibin (as individual) > From haibin.song@huawei.com Sun Feb 26 23:29:55 2012 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 DE55E21F851D; Sun, 26 Feb 2012 23:29:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.536 X-Spam-Level: X-Spam-Status: No, score=-6.536 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, 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 H-5JCWrTzaIz; Sun, 26 Feb 2012 23:29:55 -0800 (PST) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 29B4C21F8501; Sun, 26 Feb 2012 23:29:55 -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 <0M010001PJHO7K@szxga04-in.huawei.com>; Mon, 27 Feb 2012 15:29:49 +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 <0M01006LPJH6ZG@szxga04-in.huawei.com>; Mon, 27 Feb 2012 15:29:48 +0800 (CST) Received: from szxeml209-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AHK81527; Mon, 27 Feb 2012 15:29:48 +0800 Received: from SZXEML430-HUB.china.huawei.com (10.72.61.38) by szxeml209-edg.china.huawei.com (172.24.2.184) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 27 Feb 2012 15:29:18 +0800 Received: from SZXEML534-MBX.china.huawei.com ([169.254.2.222]) by szxeml430-hub.china.huawei.com ([10.72.61.38]) with mapi id 14.01.0323.003; Mon, 27 Feb 2012 15:29:41 +0800 Date: Mon, 27 Feb 2012 07:30:11 +0000 From: Songhaibin In-reply-to: <201202261717.q1QHHE0r072883@givry.fdupont.fr> X-Originating-IP: [10.138.41.129] To: "Francis.Dupont@fdupont.fr" , "gen-art@ietf.org" Message-id: MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: zh-CN Content-transfer-encoding: 7BIT Accept-Language: en-US, zh-CN Thread-topic: review of draft-ietf-decade-problem-statement-05.txt Thread-index: AQHM9KqHGEiLFvsSxkqKVT/NIeFzUJZQWP3w X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <201202261717.q1QHHE0r072883@givry.fdupont.fr> Cc: "decade@ietf.org" , "draft-ietf-decade-problem-statement.all@tools.ietf.org" Subject: Re: [decade] review of draft-ietf-decade-problem-statement-05.txt X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2012 07:29:56 -0000 Hi Francis, Thank you very much for the Gen-ART review. The nits will be resolved before publication. BR, -Haibin (as individual) > -----Original Message----- > From: Francis.Dupont@fdupont.fr [mailto:Francis.Dupont@fdupont.fr] > Sent: Monday, February 27, 2012 1:17 AM > To: gen-art@ietf.org > Cc: draft-ietf-decade-problem-statement.all@tools.ietf.org > Subject: review of draft-ietf-decade-problem-statement-05.txt > > I am the assigned Gen-ART reviewer for this draft. For background on > Gen-ART, please see the FAQ at > . > > Please resolve these comments along with any other Last Call comments > you may receive. > > Document: draft-ietf-decade-problem-statement-05.txt > Reviewer: Francis Dupont > Review Date: 20120224 > IETF LC End Date: 20120306 > IESG Telechat date: unknown > > Summary: Ready > > Major issues: None > > > Minor issues: None > > Nits/editorial comments: > - 1 page 3: P2P and CDN are not in the list of well known abbrevs > (IMHO for the first one because P2P means Point-to-Point too) > so should be introduced at the first use in the body (and for CDN > IMHO as soon as possible, this is why I put this in 1) > > - 1 page 3: in the networks. -> in networks. ? > > - 3.1 page 4: IMHO [Internet Study 2008/2009] should be removed to > leave only the reference, i.e., [Internet_Study_2008-2009] > > - 4.1 page 7: 'nor can they manage access' is a wording which could > (so should) be improved a bit, IMHO 'nor access' is enough > > - A pages 11 and 12: e.g. -> e.g., (also at end of line but it is > in an appendix 'to be removed by the RFC Editor'...) > > Regards > > Francis.Dupont@fdupont.fr > > PS: my dictionary dislikes 'infrastructural'? From haibin.song@huawei.com Tue Feb 28 17:36:50 2012 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 53D9521F8747 for ; Tue, 28 Feb 2012 17:36:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.239 X-Spam-Level: X-Spam-Status: No, score=-6.239 tagged_above=-999 required=5 tests=[AWL=-0.241, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_62=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 JDpsg2HztJzw for ; Tue, 28 Feb 2012 17:36:48 -0800 (PST) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id A26F821F8745 for ; Tue, 28 Feb 2012 17:36:47 -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 <0M04001A2SH3A1@szxga03-in.huawei.com> for decade@ietf.org; Wed, 29 Feb 2012 09:36:40 +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 <0M04004CISH3ZN@szxga03-in.huawei.com> for decade@ietf.org; Wed, 29 Feb 2012 09:36:39 +0800 (CST) Received: from szxeml211-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AHC99612; Wed, 29 Feb 2012 09:36:39 +0800 Received: from SZXEML435-HUB.china.huawei.com (10.72.61.63) by szxeml211-edg.china.huawei.com (172.24.2.182) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 29 Feb 2012 09:36:10 +0800 Received: from SZXEML534-MBX.china.huawei.com ([169.254.2.222]) by szxeml435-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.003; Wed, 29 Feb 2012 09:36:34 +0800 Date: Wed, 29 Feb 2012 01:37:58 +0000 From: Songhaibin In-reply-to: X-Originating-IP: [10.138.41.129] To: Alexey Melnikov Message-id: MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_lrwxjsrP1qIGcrcaFOKiEQ)" Content-language: zh-CN Accept-Language: en-US, zh-CN Thread-topic: [decade] Kerberos protocol for DECADE? Thread-index: Aczy0HQ9qFccbmyOS26G2cSDQbWKuQDOB6SAAB3h3VA= X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: Cc: "decade@ietf.org" Subject: Re: [decade] Kerberos protocol for DECADE? 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, 29 Feb 2012 01:36:50 -0000 --Boundary_(ID_lrwxjsrP1qIGcrcaFOKiEQ) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thank you for the reply and the pointer, Alexey. I think extending existing IETF protocol for resource control in DECADE is reasonable, for example, IMO OAuth can be used for granting third party to access the data objects owned by the resource owner in the DECADE server. I'm not familiar with ABFAB. It seems that federation solution is only designed for non-http use? But I will spend time to read those documents in that working group. BR, -Haibin (as individual) From: lunohod.baikonur@gmail.com [mailto:lunohod.baikonur@gmail.com] On Behalf Of Alexey Melnikov Sent: Wednesday, February 29, 2012 3:03 AM To: Songhaibin Cc: decade@ietf.org Subject: Re: [decade] Kerberos protocol for DECADE? On Fri, Feb 24, 2012 at 8:45 AM, Songhaibin > wrote: Hi all, Hi, I heard some voice about using Kerberos protocol for the authentication and resource control in DECADE. So I spend some time reading RFC4120, and find Kerberos is useful in insecure domain to establish a secure channel between a client and server. The Kerberos server assigns a shared session key, which will be responded from Kerberos authentication server(or Ticket granting server) to the client (there are two copies of the session key. One copy is embedded Ticket and encrypted with the server's key, together with the client's ID, and another copy is encrypted in the client's key.) The client and server will use that session key to secure their communication. So my conclusion is Kerberos is to build a secure channel between a client and server in a single domain, while inter-domain will get difficult. It does not look like a good candidate to assign network resources from the in-network storage server for content distribution to DECADE compatible application clients. I am not saying that Kerberos is the right thing here, but I suggest you look at what ABFAB WG is doing for cross-domain authentication. BR, -Haibin (as individual) --Boundary_(ID_lrwxjsrP1qIGcrcaFOKiEQ) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Thank you for the reply and the pointer, Alexey.

 

I think extending existing IETF protocol for resource control in DECADE is reasonable, for example, IMO OAuth can be used for granting third party to access the data objects owned by the resource owner in the DECADE server.  I’m not familiar with ABFAB.  It seems that federation solution is only designed for non-http use? But I will spend time to read those documents in that working group.

 

BR,

-Haibin (as individual)

 

 

From: lunohod.baikonur@gmail.com [mailto:lunohod.baikonur@gmail.com] On Behalf Of Alexey Melnikov
Sent: Wednesday, February 29, 2012 3:03 AM
To: Songhaibin
Cc: decade@ietf.org
Subject: Re: [decade] Kerberos protocol for DECADE?

 

On Fri, Feb 24, 2012 at 8:45 AM, Songhaibin <haibin.song@huawei.com> wrote:

Hi all,

Hi, 


I heard some voice about using Kerberos protocol for the authentication and resource control in DECADE. So I spend some time reading RFC4120, and find Kerberos is useful in insecure domain to establish a secure channel between a client and server. The Kerberos server assigns a shared session key, which will be responded from Kerberos authentication server(or Ticket granting server) to the client (there are two copies of the session key. One copy is embedded Ticket and encrypted with the server's key, together with the client's ID, and another copy is encrypted in the client's key.) The client and server will use that session key to secure their communication.

So my conclusion is Kerberos is to build a secure channel between a client and server in a single domain, while inter-domain will get difficult. It does not look like a good candidate to assign network resources from the in-network storage server for content distribution to DECADE compatible application clients.

 

I am not saying that Kerberos is the right thing here, but I suggest you look at what ABFAB WG is doing for cross-domain authentication. 


BR,
-Haibin (as individual)

 

--Boundary_(ID_lrwxjsrP1qIGcrcaFOKiEQ)--