From richard_woundy@cable.comcast.com Mon Jun 6 08:20:14 2011 Return-Path: X-Original-To: decade@ietfa.amsl.com Delivered-To: decade@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E72911E814D for ; Mon, 6 Jun 2011 08:20:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.734 X-Spam-Level: X-Spam-Status: No, score=-101.734 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OoTc0dkMtZeJ for ; Mon, 6 Jun 2011 08:20:14 -0700 (PDT) Received: from cable.comcast.com (copdcimo01.potomac.co.ndcwest.comcast.net [76.96.32.251]) by ietfa.amsl.com (Postfix) with ESMTP id B18A611E8137 for ; Mon, 6 Jun 2011 08:20:13 -0700 (PDT) Received: from ([24.40.55.42]) by copdcimo01.cable.comcast.com with ESMTP with TLS id 5503630.39200753; Mon, 06 Jun 2011 09:23:16 -0600 Received: from PACDCEXMB05.cable.comcast.com ([fe80::a5b0:e5c4:df1b:2367]) by PACDCEXHUB01.cable.comcast.com ([fe80::d1e7:20b5:9b63:21a6%12]) with mapi id 14.01.0289.001; Mon, 6 Jun 2011 11:20:06 -0400 From: "Woundy, Richard" To: "decade@ietf.org" Thread-Topic: Reviews of the Decade Requirements draft Thread-Index: AcwZWp9yz1TMEOznTwqwrd+Q8UHi6wLAeEsQ Date: Mon, 6 Jun 2011 15:20:05 +0000 Message-ID: <1CA25301D2219F40B3AA37201F0EACD11353569F@PACDCEXMB05.cable.comcast.com> References: <1CA25301D2219F40B3AA37201F0EACD113528EFB@PACDCEXMB05.cable.comcast.com> In-Reply-To: <1CA25301D2219F40B3AA37201F0EACD113528EFB@PACDCEXMB05.cable.comcast.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.163.75.13] Content-Type: multipart/alternative; boundary="_000_1CA25301D2219F40B3AA37201F0EACD11353569FPACDCEXMB05cabl_" MIME-Version: 1.0 Subject: Re: [decade] Reviews of the Decade Requirements draft X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2011 15:20:14 -0000 --_000_1CA25301D2219F40B3AA37201F0EACD11353569FPACDCEXMB05cabl_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Folks, just a reminder that we are looking for reviews of the DECADE Requir= ements draft to be posted to the mailing list by today. If you need a littl= e extra time, let me know. -- Rich From: Woundy, Richard Sent: Monday, May 23, 2011 11:04 AM To: decade@ietf.org Cc: Songhaibin; Woundy, Richard Subject: Reviews of the Decade Requirements draft Folks, We would like to prepare the requirements draft, draft-ietf-decade-reqs-02<= http://datatracker.ietf.org/doc/draft-ietf-decade-reqs/>, for working group= last call in late June / July. The chairs are looking for document reviews to be sent to the mailing list = by Monday June 6. We already have three volunteers from our session in Prag= ue. Additional draft reviews by the deadline would be timely and greatly ap= preciated. After the authors incorporate the feedback from the reviews in a new draft = iteration, the chairs expect to take the draft to WGLC. -- Rich --_000_1CA25301D2219F40B3AA37201F0EACD11353569FPACDCEXMB05cabl_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Folks, just a reminder= that we are looking for reviews of the DECADE Requirements draft to be pos= ted to the mailing list by today. If you need a little extra time, let me k= now.

 

-- Rich

 

From: Woundy, = Richard
Sent: Monday, May 23, 2011 11:04 AM
To: decade@ietf.org
Cc: Songhaibin; Woundy, Richard
Subject: Reviews of the Decade Requirements draft<= /p>

 

Folks,

 

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

 

The chairs are looking for document reviews to be se= nt to the mailing list by Monday June 6. We already have three volunteers f= rom our session in Prague. Additional draft reviews by the deadline would b= e timely and greatly appreciated.

 

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

 

-- Rich

--_000_1CA25301D2219F40B3AA37201F0EACD11353569FPACDCEXMB05cabl_-- From ietfdbh@comcast.net Mon Jun 6 12:37:53 2011 Return-Path: X-Original-To: decade@ietfa.amsl.com Delivered-To: decade@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A19141F0C51 for ; Mon, 6 Jun 2011 12:37:53 -0700 (PDT) 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=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eT77TPkmWl5Z for ; Mon, 6 Jun 2011 12:37:53 -0700 (PDT) Received: from qmta04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [76.96.62.40]) by ietfa.amsl.com (Postfix) with ESMTP id CB6621F0C44 for ; Mon, 6 Jun 2011 12:37:52 -0700 (PDT) Received: from omta13.westchester.pa.mail.comcast.net ([76.96.62.52]) by qmta04.westchester.pa.mail.comcast.net with comcast id sjNz1g00417dt5G54jdtaP; Mon, 06 Jun 2011 19:37:53 +0000 Received: from davidPC ([67.189.235.106]) by omta13.westchester.pa.mail.comcast.net with comcast id sjds1g00L2JQnJT3ZjdsE9; Mon, 06 Jun 2011 19:37:52 +0000 From: "David Harrington" To: Date: Mon, 6 Jun 2011 15:37:47 -0400 Message-ID: <8A0A58D7104A4FD2AF897BEC4507F5BB@davidPC> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MIMEOLE: Produced By Microsoft MimeOLE V6.1.7600.16776 Thread-Index: AcwkgTbKQRvjVmRzRLeV3Ijv2cFIAw== Cc: draft-ietf-decade-problem-statement@tools.ietf.org Subject: [decade] AD review: draft-ietf-decade-problem-statement 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, 06 Jun 2011 19:37:53 -0000 AD Review draft-ietf-decade-problem-statement My job as Responsible AD is to bring documents that one of my WGs has requested be published to the IESG. Part of my responsibility is to make sure the document is ready for IESG Evaluation. I have concerns with this document. I don't have technical concerns with the document, so much as editorial and process concerns. As Responsible AD, I request that the WG rewrite this document to be what it is supposed to be, and eliminate those parts that do not belong in a problem statement. I believe this will not take very long, since in many cases, it just requires some rewording. In other places it will require removing portions of the document, but they might be saved for other documents where the text would be more appropriate. Here are some of the IESG DISCUSS criteria that I think could be triggered on this document. - IETF process related to document advancement was not carried out; e.g., the document is outside the scope of the charter of the WG which requested its publication, and so on. - The specification would create serious security holes, or the described protocol has self-defeating security vulnerabilities (e.g. a protocol that cannot fulfill its purpose without security properties it does not provide). Below are concerns I feel need to be addressed before I can bring this document to the IESG. 1) There are Informative references that I think don't really need to be there. Some are to Internet-drafts. What happens if that ID never gets published? Having references to work in progress can delay publication of this document. Please make sure these references are REALLY needed in the text. 2) There are references to current IETF WGs, such as in 3.1. But WGs go away, and the RFC will outlast them. 3) This document has a title that says it is the problem statement for Decoupled Application Data Enroute. But throughout the document I find instances of proposed solutions. 4) There are many instances of marketing-like promises of what "DECADE" will provide. This is a problem statement, not a marketing document. DECADE is not a product, and despite what section4 says, the goal of the WG is NOT to design DECADE; it is to identify applications, describe the requirements, and develop an architecture. The WG is explicitly prevented from developing the protocol without going through a recharter. Here are some claims: "DECADE provides basic access mechanisms" "DECADE will provide access to storage and data transport services in the network to improve their efficiency and reduce the stress on the network infrastructure." "It also improves the availability of P2P contents because the in-network storage is always-on." So how does an architecture without a protocol do all these things? 5) in section 4, it says "(IAP), which is a standard, P2P-application-agnostic protocol ..." IAP is NOT a standard protocol. A document that is a work in progress that has not yet been approved should never claim it is a standard. And the WG is not even working on designing a protocol yet, just a problem statement, requirements, and an architecture, right? 6) Section 4 claims, IAP includes the following functionality (and then lists a number of things). But the WG is not authorized to work on protocols yet; how can you know what that protocol includes? and why is this description of a proposed solution in the "problem statement" document? You should be describing the problem, not the solution. 7) in section 5, there are lots of "A instructs its in-network storage to downlaod a block from B's in-network storage, and finally A itself retreives the block." How is this a problem statement? 8) in section 5.1, paragraph 5 discusses how B can attach its storage address in the message to its tracker. The WG is NOT designing a protocol. How can you possibly know what can be passed in the message? This problem statement can certainly tak about the problem to be solved, but should NOT be talking about the details of how a proposed protocol works. 9) Security Considerations should discuss the security threats/vulnerabilities that apply to in-network storage. You don't need to describe how to mitigate them here; that can be done in the requirments, architecture, and protocol documents. But you should include the problem description here. The chairs can ask me if they want a security advisor to help develop an appropriate threat analysis. David Harrington Director, IETF Transport Area ietfdbh@comcast.net (preferred for ietf) dbharrington@huaweisymantec.com +1 603 828 1401 (cell) From dave.mcdysan@verizon.com Mon Jun 6 14:06:14 2011 Return-Path: X-Original-To: decade@ietfa.amsl.com Delivered-To: decade@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2400621F8577 for ; Mon, 6 Jun 2011 14:06:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kAtQCU5VCsEQ for ; Mon, 6 Jun 2011 14:06:12 -0700 (PDT) Received: from sacmail4.verizon.com (sacmail4.verizon.com [192.76.84.42]) by ietfa.amsl.com (Postfix) with ESMTP id BF57E21F8576 for ; Mon, 6 Jun 2011 14:06:12 -0700 (PDT) Received: from fldsmtpi03.verizon.com (fldsmtpi03.verizon.com [166.68.71.145]) by sacmail4.verizon.com (8.13.7+Sun/8.13.3) with ESMTP id p56L69vW014838 for ; Mon, 6 Jun 2011 17:06:10 -0400 (EDT) From: "Mcdysan, David E" X-IronPort-AV: E=Sophos;i="4.65,328,1304294400"; d="scan'208";a="66628784" Received: from fhdp1lumxc7hb02.verizon.com (HELO FHDP1LUMXC7HB02.us.one.verizon.com) ([166.68.59.189]) by fldsmtpi03.verizon.com with ESMTP; 06 Jun 2011 21:06:09 +0000 Received: from fhdp1lumxc7v11.us.one.verizon.com ([169.254.1.241]) by FHDP1LUMXC7HB02.us.one.verizon.com ([2002:a644:3bbd::a644:3bbd]) with mapi; Mon, 6 Jun 2011 17:06:09 -0400 To: "decade@ietf.org" Date: Mon, 6 Jun 2011 17:06:07 -0400 Thread-Topic: Review of the Decade Requirements draft Thread-Index: AcwkjY6rkeRrJh3wRu+P75nwD4nZPg== Message-ID: In-Reply-To: <1CA25301D2219F40B3AA37201F0EACD113528EFB@PACDCEXMB05.cable.comcast.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.1.0.101012 acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [decade] Review of the Decade Requirements draft X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2011 21:06:14 -0000 Here is my review of the Decade requirements draft. There are numerous grammatical and wording suggestions that I have sent to the authors and chairs in a revision marked Word document. The comments are also placed in context Dave ---------------------------- Terminology=20 - Suggest defining what is meant by "data transport" (e.g., access to stored data) since the term "transport" has another meaning in the IETF. - Read, write used in many places; but other verb pairs also used (e.g., retrieve, store). Pick one set of verbs and use consistently. Section 2, last paragraph =AD define what is meant by "multipath." Section 2, last paragraph - Suggest deleting the last sentence. It adds no new thought. Section 4, Unnecessary level of indentation for 4.1 =AD suggest removal. 4.1.1.2.1. NATs and Firewalls =AD Suggest including Enterprises in list of users of firewalls. 4.1.1.2.2.=20 Connections to Clients =AD Describe the default behavior (e.g., block incoming connections) 4.1.1.3.1. Secure Transport Is there an option for the stored content to be encrypted? Is the assumption that access control provides adequate security? If so, then this should be stated. 4.1.1.3.2. Connections to Clients This text is almost identical to 4.1.1.2.2. Only need to state this in one place. 4.1.1.4.1. Overload Condition - First sentence of Rationale is same thought as requirement -- suggest deletion. 4.1.2.2. Indirect Transfer - Suggest adding "if authorized and authenticated as described in requirement (insert reference)" to the end of the requirement 4.1.3.2. Access by Other Users * Suggest there be a default mode where read access can be performed by any user. * Suggest stating that use of already standardized access control and authoritzation protocols is desirable. If this requires configuration of access control lists, this becomes a significant amount of configuration. (This differs from the architecture draft which focuses on token-based authentication, which would seem to scale better). 4.1.5.1. Unique Names Need to state the scope of uniqueness =AD a single storage provider or all storage providers? 4.1.6.2. Per-Remote-Client, Per-Data Control - Need to specify the types of quotas to be supported by the protocol in the requirement text, not just in the rationale. 4.1.6.3. Server Involvement Where are resource control policies specified? Is this the same as quotas? If so, suggest using only one term. 4.1.7. Authorization These requirements seem similar to 4.1.3.2.. Suggest merging these requirements. 6.1.1. Explicit Deletion of Stored Data Not sure how this relates to the unique naming requirement. Is this intended to replace a delete and write with a single operation to be more efficient? 6.1.6. Writing model Append implies ordering to me, while the rationale states the motivation for writing out of order data. Seems like you are specifying random (write) access to the object. 6.1.7. Storage Status Regarding information on resource usage by other clients; Is this on a per client basis, or a summation across all clients? (Summation would seem to scale better.) 6.2.1. No ability to update Unless the Overwrite flag is present? See 6.1.1. Section 7/8: Removal of Duplicate Records Across Servers: The circular references between sections 7 and 8 is unnecessary. Suggest picking one place to state this issue. Section 9: Suggest adding access control to this section with a discussion of its uses when scaling is not an issue. From: "Woundy, Richard" Date: Mon, 23 May 2011 11:03:50 -0400 To: "decade@ietf.org" Subject: [decade] Reviews of the Decade Requirements draft >Folks, >=20 >We would like to prepare the requirements draft, >draft-ietf-decade-reqs-02 >, for working >group last call in late June / July. >=20 >The chairs are looking for document reviews to be sent to the mailing >list by Monday June 6. We already have three volunteers from our session >in Prague. Additional draft reviews by the deadline would be timely and >greatly appreciated. >=20 >After the authors incorporate the feedback from the reviews in a new >draft iteration, the chairs expect to take the draft to WGLC. >=20 >-- Rich From borje.ohlman@ericsson.com Tue Jun 7 07:03:41 2011 Return-Path: X-Original-To: decade@ietfa.amsl.com Delivered-To: decade@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D84221F853D for ; Tue, 7 Jun 2011 07:03:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.298 X-Spam-Level: X-Spam-Status: No, score=-6.298 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TBGFwq96OLFQ for ; Tue, 7 Jun 2011 07:03:39 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id C94DE21F853E for ; Tue, 7 Jun 2011 07:03:38 -0700 (PDT) X-AuditID: c1b4fb3d-b7c17ae00000262e-1f-4dee2fb9f918 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 04.D6.09774.9BF2EED4; Tue, 7 Jun 2011 16:03:37 +0200 (CEST) Received: from abro.ki.sw.ericsson.se (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.137.0; Tue, 7 Jun 2011 16:03:36 +0200 Received: from [IPv6:::1] (abro.ki.sw.ericsson.se [147.214.177.159]) by abro.ki.sw.ericsson.se (Postfix) with ESMTP id 16D7227980; Tue, 7 Jun 2011 16:03:34 +0200 (CEST) From: =?iso-8859-1?Q?B=F6rje_Ohlman?= MIME-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary="Apple-Mail-1-583221478" Date: Tue, 7 Jun 2011 16:03:39 +0200 In-Reply-To: <1CA25301D2219F40B3AA37201F0EACD11352AFDF@PACDCEXMB05.cable.comcast.com> To: Richard Woundy , decade ietf References: <1CA25301D2219F40B3AA37201F0EACD113528EFB@PACDCEXMB05.cable.comcast.com> <1CA25301D2219F40B3AA37201F0EACD11352AFDF@PACDCEXMB05.cable.comcast.com> Message-ID: <201B28BD-9589-4A0C-AB56-84E5CFFC014B@ericsson.com> X-Mailer: Apple Mail (2.1084) X-Brightmail-Tracker: AAAAAA== Subject: Re: [decade] Reviews of the Decade Architecture draft X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2011 14:03:41 -0000 --Apple-Mail-1-583221478 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="windows-1252" Dear All, Here is my review of the Decade Architecture draft. Best regards, B=F6rje Overall comments ------------------------ The overall impression of the draft is very good. I find it clear and = coherent, on most accounts. It is also well structured and seems to be = fairly complete. I can see two types of management and charging operations in decade. One = type is when a decade client is managing its resources at a decade = server. Another type is when a decade service provider is managing the = resources at a decade server. I feel that these two types of management = and charging operations are not clearly separated in the current draft. There is a 'Data index' box in figure 1, but it is not described in the = current draft. Some explanation of its functionality and purpose would = help. In a number of places the concept 'index' is referred to, I assume = that are references to this 'Data index', but that is not clear from the = current draft. This also makes the paragraphs referring to the 'index' = hard to fully comprehend. There is a 'Data Search Capability' defined. To me the purpose of this = is unclear. It is especially unclear if this should be part of the = decade layer or if it should be part of the application layer. Maybe = this will be clearer when the 'Data index' is described as it seems that = the Search is using the index. Is it allowed for decade service providers to oversell the resources of = their servers (both bandwidth and storage), similar to airline = overbooking? I think overbooking should be allowed to maximize resource = utilization. Especially regarding bandwidth I think it is unavoidable. = It would be good if this was addressed in the draft, e.g. in 4.2. When decade accepts an object for storage, does it offer persistent = storage (e.g. in case of node failures) or not? This should be made = clear. If not, there should be a way to check if an object is still = there. How should that be done? Could the status message in 5.1.3 be = used for this? Another place where this should be explicitly mentioned = is in 5.2.1. Neither 'DECADE client' nor 'DECADE user' is defined in section 2. Specific comments ------------------------ Abstract: The abstract should be less p2p specific and make clear that decade can = well be used in other contexts than p2p. p5 =A71 Same comment as abstract. Please spell out abbreviations. s/On the other hand, it can be cheaper to upgrade the core = infrastructure, which involves fewer components that are shared by many = subscribers./Therefore, it can be cheaper to upgrade the core = infrastructure, which involves fewer components that are shared by many = subscribers./ 2.3 I suggest to add: "Content providers might be mobile." 2.6 =A72 It is unclear what this =A7 is trying to say, it is unclear what a = "swarm" is here. Please reformulate and explain or remove. 3.1 =A76 "By Application, we mean the broad sense that includes other control = plane protocols." It is unclear what this sentence is trying to say. = Please reformulate and explain or remove. 4.1.3.2 The concept 'index' needs to be explained, see overall comments. 4.2..1 =A72 Also lack of server resources could be a reason, at least if overbooking = is allowed, also see overall comments. 4.2.3 The draft should not refer to 'disks' as the only storage medium. A = technology neutral term should be used. 4.3 =A72 It is not clear what 'evolve' refers to, it could be decade, DRP or SDT. = I think all three are possible and it would be good to make this = explicit. 4.3.2 Mention explicitly that decade will allow for a limited number of = alternatives. 4.6 =A72 It is unclear to me what this =A7 is trying to say. Especially I don't = understand what 'complex behavior' is referring to. An example might = help. If =A7 not explained better remove it. 4.6.3 There is a 'Data Search Capability' defined. To me the purpose of this = is unclear. It is especially unclear if this should be part of the = decade layer or if it should be part of the application layer. Maybe = this will be clearer when the 'Data index' is described as it seems that = the Search is using the index. 4.6.4 "All methods of access control are supported: public-unrestricted, = public-restricted and private." Who must support them? Must all decade = instances support 'all' methods?. Is the three methods listed here the = only possible ones? It would be good with a reference defining these = methods. 4.6.5 To avoid confusion I think it would be good to mention very explicitly = that this interface is for the users to manage the server resources that = they have been allocated by the decade service provider and that how the = service provider is allocating the resources to the individual users is = done via a different interface. Also see overall comments. 4.6.6 "This is outside the scope of the DECADE architecture." Why is the = discovery mechanism out of scope? I would see it as a key architectural = component. Please provide a motivation why it is out of scope. 5.1 "and DRP allows one instance of such an application, e.g., an = application endpoint, to configure access control and resource sharing = policies on a set of servers." Does this imply that an operation can be = performed on 'a set of servers' at once or is the intention just to = state that one application instance can employ many servers? It would be = good to be clear if multiple servers can be configured with one = 'command' or if they have to be addressed individually. 5.1.2 "Expiration time" I think it also makes sense to have an "Earliest time" = when the token becomes valid, e.g. to make redistribution of large = numbers of tokens possible. I suggest to change "Expiration time" to = something like "Valid time", with both a start and a stop time, either = could of course be optional. One could even consider allowing for more = elaborate time schedules making tokens valid during certain parts of a = day or week (e.g. only during working hours). 5.1.3 =A71 "DRP provides a request service for status information that DECADE = clients can use to request information from a DECADE server." In 3.5.2 it is stated that resources are granted per user, not per = decade client. I think the terminology should be consistent and it = should be made clear the relationship between 'user' and 'decade = client'. Also it is unclear how the storage provider get information about the = status of a specific decade server. If that is out of scope (which I'm = not sure it should be) I think it would be good to mention that = explicitly. Neither 'DECADE client' nor 'DECADE user' is defined in section 2. 5.1.3=A72 "status information per application context on a specific server:" Either beginning of sentence is missing, or just a capital 'S'.=20 Also it would be good if 'application context' was defined, it is a term = that can be interpreted in many ways. 5.1.4 "TTL" I think, also here (see 5.1.2), that it also makes sense to have a = "Going live time" when the object becomes available, e.g. to make it = possible to pre-populate caches. I suggest to change "TTL" to something = like "Valid time", with both a start and a stop time, either could of = course be optional. One could even consider allowing for more elaborate = time schedules making objects available during certain parts of a day or = week (e.g. x-rated movies). 5.2.1 =A74 s/MUST not/MUST NOT/ 5.2.1 at the end=85 "OK: The object has been uploaded successfully and has replaced an existing object with the same name." Why should someone ever want to replace an immutable object with an = exact copy of the same object? See no reason to have this response. (Also see general comment on persistent storage of object and status = check of objects). 7.2.2 s/The same object might be uploaded for multiple times/The same object = might be uploaded multiple times/ A.1.2. =20 s/HTTP Support for DECADE Standard Transport Protocol Primitives/HTTP = Support for DECADE Standard Data Transport Protocol Primitives/ On 25 maj 2011, at 15.11, Woundy, Richard wrote: > Folks, > =20 > We would like to prepare the architecture draft, = draft-ietf-decade-arch-01, for working group last call in July. > =20 > The chairs are looking for document reviews to be sent to the mailing = list by Monday June 13. We already have three volunteers from our = session in Prague. Additional draft reviews by the deadline would be = timely and greatly appreciated. > =20 > After the authors incorporate the feedback from the reviews in a new = draft iteration, the chairs expect to take the draft to WGLC. > =20 > -- Rich > _______________________________________________ > decade mailing list > decade@ietf.org > https://www.ietf.org/mailman/listinfo/decade --Apple-Mail-1-583221478 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="windows-1252" Dear All,

Here is my review of = the Decade Architecture draft.

Best = regards,
B=F6rje

------------------------

The overall impression of the = draft is very good. I find it clear and coherent, on most accounts. It = is also well structured and seems to be fairly complete.

I can see two types of management = and charging operations in decade. One type is when a decade client is = managing its resources at a decade server. Another type is when a decade = service provider is managing the resources at a decade server. I feel = that these two types of management and charging operations are not = clearly separated in the current draft.
There is a 'Data index' box in figure 1, but it = is not described in the current draft. Some explanation of its = functionality and purpose would help. In a number of places the concept = 'index' is referred to, I assume that are references to this 'Data = index', but that is not clear from the current draft. This also makes = the paragraphs referring to the 'index' hard to fully = comprehend.


Is = it allowed for decade service providers to oversell the resources of = their servers (both bandwidth and storage), similar to airline = overbooking? I think overbooking should be allowed to maximize resource = utilization. Especially regarding bandwidth I think it is unavoidable. = It would be good if this was addressed in the draft, e.g. in = 4.2.



Specific comments

The abstract should be less p2p specific and = make clear that decade can well be used in other contexts than = p2p.

p5 = =A71
Same comment as abstract.
s/On the other hand, it can be = cheaper to upgrade the core infrastructure, which involves fewer = components that are shared by many subscribers./Therefore, it can be = cheaper to upgrade the core infrastructure, which involves fewer = components that are shared by many subscribers./

2.3
I suggest to add: "Content = providers might be mobile."

It is unclear what this =A7 is trying to say, = it is unclear what a "swarm" is here. Please reformulate and explain or = remove.

"By Application, we mean the broad sense that = includes other control plane protocols." It is unclear what this = sentence is trying to say. Please reformulate and explain or = remove.

The concept 'index' needs to be explained, see = overall comments.

Also lack of server resources could be a = reason, at least if overbooking is allowed, also see overall = comments.

The draft should not refer to 'disks' as the = only storage medium. A technology neutral term should be used.

4.3 =A72
It = is not clear what 'evolve' refers to, it could be decade, DRP or SDT. I = think all three are possible and it would be good to make this = explicit.

Mention explicitly that decade will allow for a = limited number of alternatives.

It is unclear to me what this =A7 is trying to = say. Especially I don't understand what 'complex behavior' is referring = to. An example might help. If =A7 not explained better remove = it.

There is a 'Data Search Capability' defined. To = me the purpose of this is unclear. It is especially unclear if this = should be part of the decade layer or if it should be part of the = application layer. Maybe this will be clearer when the 'Data index' is = described as it seems that the Search is using the index.

4.6.4

To avoid confusion I think it would be good to = mention very explicitly that this interface is for the users to manage = the server resources that they have been allocated by the decade service = provider and that how the service provider is allocating the resources = to the individual users is done via a different interface. Also see = overall comments.

"This is outside the scope of the DECADE = architecture." Why is the discovery mechanism out of scope? I would see = it as a key architectural component. Please provide a motivation why it = is out of scope.

"and DRP allows one instance of such an = application, e.g., an application endpoint, to configure access control = and resource sharing policies on a set of servers." Does this imply that = an operation can be performed on 'a set of servers' at once or is the = intention just to state that one application instance can employ many = servers? It would be good to be clear if multiple servers can be = configured with one 'command' or if they have to be addressed = individually.

"Expiration time" I think it also makes sense = to have an "Earliest time" when the token becomes valid, e.g. to make = redistribution of large numbers of tokens possible. I suggest to change = "Expiration time" to something like "Valid time", with both a start and = a stop time, either could of course be optional. One could even consider = allowing for more elaborate time schedules making tokens valid during = certain parts of a day or week (e.g. only during working = hours).

"DRP provides a request service for status = information that DECADE clients can use to request information from a = DECADE server."
In 3.5.2 it is stated that resources are = granted per user, not per decade client. I think the terminology should = be consistent and it should be made clear the relationship between = 'user' and 'decade client'.
Also it is unclear how the = storage provider get information about the status of a specific decade = server. If that is out of scope (which I'm not sure it should be) I = think it would be good to mention that explicitly.

5.1.3=A72
Either beginning of sentence is missing, or = just  a capital 'S'. 
Also it would be good if = 'application context' was defined, it is a term that can be interpreted = in many ways.

"TTL" I think, also here (see 5.1.2), that it = also makes sense to have a "Going live time" when the object becomes = available, e.g. to make it possible to pre-populate caches. I suggest to = change "TTL" to something like "Valid time", with both a start and a = stop time, either could of course be optional. One could even consider = allowing for more elaborate time schedules making objects available = during certain parts of a day or week (e.g. x-rated movies).

5.2.1 =A74

"OK:  The object has been uploaded = successfully and has replaced an
       =   existing object with the same name."
(Also see general comment on persistent storage = of object and status check of objects).
7.2.2
s/The same object might be = uploaded for multiple times/The same object might be uploaded multiple = times/

s/HTTP Support for DECADE Standard Transport = Protocol Primitives/HTTP Support for DECADE Standard Data Transport = Protocol Primitives/




On 25 maj 2011, at 15.11, = Woundy, Richard wrote:

Folks,
 
We would like to prepare the architecture draft, = draft-ietf-decade-arch-01, for working group last call in = July.
 
The chairs are looking for document reviews to be sent to = the mailing list by Monday June 13. We already have three volunteers = from our session in Prague. Additional draft reviews by the deadline = would be timely and greatly appreciated.
After the authors incorporate the feedback from the reviews = in a new draft iteration, the chairs expect to take the draft to = WGLC.
 
-- = Rich
________________________________________= _______
decade mailing list
Thread-Topic: DECADE Architecture Draft Thread-Index: AcwnUwiMJ24Uy8iiQqWSv7l+fuwMWA== Date: Fri, 10 Jun 2011 09:44:47 +0000 Message-ID: Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.1.67] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Fri, 10 Jun 2011 06:01:24 -0700 Subject: [decade] DECADE Architecture Draft X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2011 09:44:54 -0000 Hi all, I volunteered to review the DECADE architecture draft during the last IETF = meeting. I have reviewed it and I have a number of issues.=20 The high-level summary: I don't see the draft in a good shape, especially n= ot for people who are not actively participating in DECADE. However, I currently lack the time to get all the issues written up in an e= mail, but let's start with some issues here: My general comment about the architecture draft is that it is really hard t= o read, as it does miss some parts (or is unclear) somewhere which describe= d in other locations. This does not make it easier to read and understand t= he concepts.=20 A good example for this: Figure 1, a quite complex and huge figure, emphasizes the end point to serv= er architecture, but the also important server to server part is easily mis= sed. This isn't a comprehensive architecture figure. I was afterwards surpr= ised by Section 6 on server to server protocols.=20 Furthermore, the distinction between what is user data, what is control dat= a and what is management data is not made clear (at least to me). See Secti= ons 5.1.3 and 5.1.4. The status information is for information from the DECADE server. To my und= erstanding this would be general status information which are part of a MIB= (for instance). But the list on page 23 is more about per user or per cont= ent status information. This is my first point of confusion.=20 Furthermore, there seems to be a mixture between Sections 5.1.3 and 5.1.4, = as in 5.1.3 information about objects is stored, while the same information= is again stated in the object information, i.e, the access information.=20 This does not look like a set of clean data models or at least idea of data= models behind this.=20 This a first set of comments, I will write up more once I find a cycle for = this. Sorry for sending only an incomplete list of issues I have with the d= raft. Martin martin.stiemerling@neclab.eu NEC Laboratories Europe - Network Research Division NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London = W3 6BL | Registered in England 2832014=20 From richard_woundy@cable.comcast.com Fri Jun 10 07:19:42 2011 Return-Path: X-Original-To: decade@ietfa.amsl.com Delivered-To: decade@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 441AB11E818A for ; Fri, 10 Jun 2011 07:19:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.463 X-Spam-Level: X-Spam-Status: No, score=-108.463 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lxDlKXHKBgdI for ; Fri, 10 Jun 2011 07:19:41 -0700 (PDT) Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by ietfa.amsl.com (Postfix) with ESMTP id E61BA11E80CA for ; Fri, 10 Jun 2011 07:19:40 -0700 (PDT) Received: from ([24.40.55.40]) by pacdcimo01.cable.comcast.com with ESMTP with TLS id 5503620.130715246; Fri, 10 Jun 2011 10:19:32 -0400 Received: from PACDCEXMB05.cable.comcast.com ([fe80::a5b0:e5c4:df1b:2367]) by pacdcexhub03.cable.comcast.com ([fe80::d1dd:b302:b617:3755%12]) with mapi id 14.01.0289.001; Fri, 10 Jun 2011 10:19:32 -0400 From: "Woundy, Richard" To: David Harrington Thread-Topic: [decade] AD review: draft-ietf-decade-problem-statement Thread-Index: AcwkgTbKQRvjVmRzRLeV3Ijv2cFIAwC9pvNQ Date: Fri, 10 Jun 2011 14:19:31 +0000 Message-ID: <1CA25301D2219F40B3AA37201F0EACD11354A434@PACDCEXMB05.cable.comcast.com> References: <8A0A58D7104A4FD2AF897BEC4507F5BB@davidPC> In-Reply-To: <8A0A58D7104A4FD2AF897BEC4507F5BB@davidPC> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [76.96.111.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "decade@ietf.org" , "draft-ietf-decade-problem-statement@tools.ietf.org" Subject: Re: [decade] AD review: draft-ietf-decade-problem-statement 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, 10 Jun 2011 14:19:42 -0000 David, As document shepherd, I will work with the Problem Statement authors to cor= rect the deficiencies you have noted below. > IETF process related to document advancement was not carried out; e.g., t= he document is outside the scope of the charter of the WG which requested i= ts publication ... > I request that the WG rewrite this document to be what it is supposed to = be, and eliminate those parts that do not belong in a problem statement. While I believe the WG did not *intend* to go beyond its charter, I can see= why the current document text raises such concerns. I would tend to agree = that revising and/or deleting some of the current text would rectify this i= ssue. I can work on this revision with the authors. > The specification would create serious security holes, or the described protocol has self-defeating security vulnerabilities ... > The chairs can ask me if they want a security advisor to help develop an = appropriate threat analysis. I would like to request a security advisor to help. I think we may need som= e outside consultation to address this concern. I would rather not be surpr= ised by a DISCUSS from a Security AD during IESG evaluation. -- Rich -----Original Message----- From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.org] On Behalf Of= David Harrington Sent: Monday, June 06, 2011 3:38 PM To: decade@ietf.org Cc: draft-ietf-decade-problem-statement@tools.ietf.org Subject: [decade] AD review: draft-ietf-decade-problem-statement AD Review draft-ietf-decade-problem-statement My job as Responsible AD is to bring documents that one of my WGs has requested be published to the IESG. Part of my responsibility is to make sure the document is ready for IESG Evaluation. I have concerns with this document. I don't have technical concerns with the document, so much as editorial and process concerns.=20 As Responsible AD, I request that the WG rewrite this document to be what it is supposed to be, and eliminate those parts that do not belong in a problem statement. I believe this will not take very long, since in many cases, it just requires some rewording. In other places it will require removing portions of the document, but they might be saved for other documents where the text would be more appropriate. Here are some of the IESG DISCUSS criteria that I think could be triggered on this document.=20 - IETF process related to document advancement was not carried out; e.g., the document is outside the scope of the charter of the WG which requested its publication, and so on. - The specification would create serious security holes, or the described protocol has self-defeating security vulnerabilities (e.g. a protocol that cannot fulfill its purpose without security properties it does not provide).=20 Below are concerns I feel need to be addressed before I can bring this document to the IESG. 1) There are Informative references that I think don't really need to be there. Some are to Internet-drafts. What happens if that ID never gets published? Having references to work in progress can delay publication of this document. Please make sure these references are REALLY needed in the text. 2) There are references to current IETF WGs, such as in 3.1. But WGs go away, and the RFC will outlast them.=20 3) This document has a title that says it is the problem statement for Decoupled Application Data Enroute. But throughout the document I find instances of proposed solutions.=20 4) There are many instances of marketing-like promises of what "DECADE" will provide. This is a problem statement, not a marketing document. DECADE is not a product, and despite what section4 says, the goal of the WG is NOT to design DECADE; it is to identify applications, describe the requirements, and develop an architecture. The WG is explicitly prevented from developing the protocol without going through a recharter. Here are some claims: =20 "DECADE provides basic access mechanisms" "DECADE will provide access to storage and data transport services in the network to improve their efficiency and reduce the stress on the network infrastructure." "It also improves the availability of P2P contents because the in-network storage is always-on." So how does an architecture without a protocol do all these things? 5) in section 4, it says "(IAP), which is a standard, P2P-application-agnostic protocol ..." IAP is NOT a standard protocol. A document that is a work in progress that has not yet been approved should never claim it is a standard. And the WG is not even working on designing a protocol yet, just a problem statement, requirements, and an architecture, right? 6) Section 4 claims, IAP includes the following functionality (and then lists a number of things). But the WG is not authorized to work on protocols yet; how can you know what that protocol includes? and why is this description of a proposed solution in the "problem statement" document? You should be describing the problem, not the solution. 7) in section 5, there are lots of "A instructs its in-network storage to downlaod a block from B's in-network storage, and finally A itself retreives the block." How is this a problem statement? 8) in section 5.1, paragraph 5 discusses how B can attach its storage address in the message to its tracker. The WG is NOT designing a protocol. How can you possibly know what can be passed in the message? This problem statement can certainly tak about the problem to be solved, but should NOT be talking about the details of how a proposed protocol works. 9) Security Considerations should discuss the security threats/vulnerabilities that apply to in-network storage. You don't need to describe how to mitigate them here; that can be done in the requirments, architecture, and protocol documents. But you should include the problem description here. The chairs can ask me if they want a security advisor to help develop an appropriate threat analysis. David Harrington Director, IETF Transport Area ietfdbh@comcast.net (preferred for ietf) dbharrington@huaweisymantec.com +1 603 828 1401 (cell) _______________________________________________ decade mailing list decade@ietf.org https://www.ietf.org/mailman/listinfo/decade From dave.mcdysan@verizon.com Mon Jun 13 07:49:03 2011 Return-Path: X-Original-To: decade@ietfa.amsl.com Delivered-To: decade@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AA789E8017 for ; Mon, 13 Jun 2011 07:49:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_53=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RvUAPa9wu33k for ; Mon, 13 Jun 2011 07:49:02 -0700 (PDT) Received: from sacmail4.verizon.com (sacmail4.verizon.com [192.76.84.42]) by ietfa.amsl.com (Postfix) with ESMTP id B85129E8011 for ; Mon, 13 Jun 2011 07:49:02 -0700 (PDT) Received: from fldsmtpi03.verizon.com (fldsmtpi03.verizon.com [166.68.71.145]) by sacmail4.verizon.com (8.13.7+Sun/8.13.3) with ESMTP id p5DEmvWh029274 for ; Mon, 13 Jun 2011 10:49:02 -0400 (EDT) From: "Mcdysan, David E" X-IronPort-AV: E=Sophos;i="4.65,358,1304294400"; d="scan'208";a="71162495" Received: from fhdp1lumxc7hb01.verizon.com (HELO FHDP1LUMXC7HB01.us.one.verizon.com) ([166.68.59.188]) by fldsmtpi03.verizon.com with ESMTP; 13 Jun 2011 14:48:54 +0000 Received: from fhdp1lumxc7v11.us.one.verizon.com ([169.254.1.164]) by FHDP1LUMXC7HB01.us.one.verizon.com ([166.68.59.188]) with mapi; Mon, 13 Jun 2011 10:48:50 -0400 To: "decade@ietf.org" Date: Mon, 13 Jun 2011 10:48:48 -0400 Thread-Topic: [decade] Reviews of the Decade Architecture draft Thread-Index: Acwp2QFawq1KJEztSJegnFUa22GSsw== Message-ID: In-Reply-To: <1CA25301D2219F40B3AA37201F0EACD11352AFDF@PACDCEXMB05.cable.comcast.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.1.0.101012 acceptlanguage: en-US Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [decade] Reviews of the Decade Architecture draft X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jun 2011 14:49:03 -0000 Here is my review of the DECADE architecture draft. I plan to send minor edits, suggested rewording, etc, to the authors and cc the chairs in a revision marked Word Document. Dave ----------------- Overall comments: The draft is well written, but the structure of the text that covers Figure 1 is "flat" and may be difficult for first time readers to grasp the main concepts. A suggestion is to construct a simpler Figure that captures the main functional blocks that introduces the main features of the architecture and provides a roadmap and references to the sections which contain more detail. There are a number of instances in the document where statements of the form "=8A foo will be covered in a subsequent version of this document =8A.= " These need to be removed before a last call. Also, a decision needs to be made if any of this future work is actually needed for last call. (I think not, but this should be discussed on the list). Also, documents covering these areas in further detail may be a basis for WG rechartering. Suggest defining what is meant by "data transport" (e.g., access to stored data) since the term "transport" has another meaning in the IETF and make this consistent with the requirements draft. Specific Comments: 1. Introdcution, 1st para: Here, and in some other places where the scope is described as P2P applications, suggest making the applicable applications the same as stated in the requirements draft. That is, add IPTV and VoD to P2P. 3.2. Immutable Data Objects The definition for multipath (different blocks may be fetched from different content sources in parallel) should be added to the requirements draft. 3.5.2. User Delegations, 2nd para "Instead of granting resources to an application, the server grants a share of the resources to a user." Not clear what is meant by the first phrases. Suggest elaboration and giving a few examples. Is user synonymous with DECADE client? (If so, this should be changed to be consistent for all occurrences.) 4.2.2. Resource Scheduling, 2nd para "In order to access this data, another Application End-Point may use the granted access along with its own available resources to store or retrieve data from a DECADE Server." I agree with this, but don=B9t recall it being clearly stated in the requirements draft. 4.4.1. DECADE Data Object Naming Schema, 2nd bullet * Unique names (with high probability[DM1] Would really like to see more description of what is the behavior when non-unique names are generated. Is there a possible solution to ensure that object names can be unique within a certain scope?For example, could a disambiguating field be added to the name in the event of a collision? 4.5. Token-based Authentication and Resource Control, 3rd para "This is a simple scheme, but has multiple important advantages over an alternate approach in which a DECADE Client explicitly manipulates an Access Control List (ACL) associated with each DECADE data object." My reading of the requirements draft was that ACLs and some authentication method are mandatory. IMO, the token approach described in this draft is much more scalable and useful. Suggest making the ACL style controls in requirements as SHOULD for the reasons stated here. 5.1.2. Token-based Authentication and Resource Control, 4th list item "Priority for bandwidth" Not clear what this means. Suggest elaboration, give example(s). 5.1.3. Status Information The text of "access information per application context on a specific server:" references section 3.5. This needs some clarification, since 3.5 states that per user (and not per application) delegation is supported. From: "Woundy, Richard" Date: Wed, 25 May 2011 09:11:39 -0400 To: "decade@ietf.org" Subject: [decade] Reviews of the Decade Architecture draft >Folks, >=20 >We would like to prepare the architecture draft, >draft-ietf-decade-arch-01, for working group last call in July. >=20 >The chairs are looking for document reviews to be sent to the mailing >list by Monday June 13. We already have three volunteers from our session >in Prague. Additional draft reviews by the deadline would be timely > and greatly appreciated. >=20 >After the authors incorporate the feedback from the reviews in a new >draft iteration, the chairs expect to take the draft to WGLC. >=20 >-- Rich From haibin.song@huawei.com Wed Jun 15 23:49:30 2011 Return-Path: X-Original-To: decade@ietfa.amsl.com Delivered-To: decade@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED49911E807B for ; Wed, 15 Jun 2011 23:49:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uJg5xnGeXhI6 for ; Wed, 15 Jun 2011 23:49:30 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id AE83A11E8078 for ; Wed, 15 Jun 2011 23:49:29 -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 <0LMV00E0QEXRR2@szxga03-in.huawei.com> for decade@ietf.org; Thu, 16 Jun 2011 14:49:03 +0800 (CST) Received: from szxeml207-edg.china.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LMV00LTCEXRMI@szxga03-in.huawei.com> for decade@ietf.org; Thu, 16 Jun 2011 14:49:03 +0800 (CST) Received: from SZXEML408-HUB.china.huawei.com (10.82.67.95) by szxeml207-edg.china.huawei.com (172.24.2.59) with Microsoft SMTP Server (TLS) id 14.1.270.1; Thu, 16 Jun 2011 14:49:01 +0800 Received: from SZXEML505-MBX.china.huawei.com ([169.254.2.122]) by szxeml408-hub.china.huawei.com ([169.254.11.86]) with mapi id 14.01.0270.001; Thu, 16 Jun 2011 14:49:03 +0800 Date: Thu, 16 Jun 2011 06:49:02 +0000 From: Songhaibin In-reply-to: <8A0A58D7104A4FD2AF897BEC4507F5BB@davidPC> X-Originating-IP: [172.24.2.40] To: David Harrington , "decade@ietf.org" Message-id: MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: en-US Content-transfer-encoding: 7BIT Accept-Language: en-US, zh-CN Thread-topic: AD review: draft-ietf-decade-problem-statement Thread-index: AcwkgTbKQRvjVmRzRLeV3Ijv2cFIAwHb8AdP X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <8A0A58D7104A4FD2AF897BEC4507F5BB@davidPC> Cc: "draft-ietf-decade-problem-statement@tools.ietf.org" Subject: Re: [decade] AD review: draft-ietf-decade-problem-statement 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 Jun 2011 06:49:31 -0000 Dear David, Thank you very much for your review as the Area Director. Please see my reply in line. > -----Original Message----- > From: David Harrington [mailto:ietfdbh@comcast.net] > Sent: Tuesday, June 07, 2011 3:38 AM > To: decade@ietf.org > Cc: draft-ietf-decade-problem-statement@tools.ietf.org > Subject: AD review: draft-ietf-decade-problem-statement > > AD Review draft-ietf-decade-problem-statement > > My job as Responsible AD is to bring documents that one of my WGs has > requested be published to the IESG. Part of my responsibility is to > make sure the document is ready for IESG Evaluation. I have concerns > with this document. > > I don't have technical concerns with the document, so much as > editorial and process concerns. > > As Responsible AD, I request that the WG rewrite this document to be > what it is supposed to be, and eliminate those parts that do not > belong in a problem statement. > I believe this will not take very long, since in many cases, it just > requires some rewording. In other places it will require removing > portions of the document, but they might be saved for other documents > where the text would be more appropriate. > > Here are some of the IESG DISCUSS criteria that I think could be > triggered on this document. > - IETF process related to document advancement was not carried > out; e.g., the document is outside the scope of the charter of the WG > which requested its publication, and so on. > - The specification would create serious security holes, or the > described protocol has self-defeating security vulnerabilities (e.g. a > protocol that cannot fulfill its purpose without security properties > it does not provide). > > Below are concerns I feel need to be addressed before I can bring this > document to the IESG. > > 1) There are Informative references that I think don't really need to > be there. Some are to Internet-drafts. What happens if that ID never > gets published? Having references to work in progress can delay > publication of this document. Please make sure these references are > REALLY needed in the text. > Thanks, the authors will remove them. > 2) There are references to current IETF WGs, such as in 3.1. But WGs > go away, and the RFC will outlast them. OK. We will revise the doc to refer to RFCs instead of relative WGs. In 3.1, the authors will refer to ALTO problem statement RFC instead of ALTO WG. > > 3) This document has a title that says it is the problem statement for > Decoupled Application Data Enroute. But throughout the document I find > instances of proposed solutions. When I read the charter, it not only states the problems, but also the high level solution direction where this WG should go. Such as the first sentence in paragraph 3. "Both of these challenges can be effectively addressed by using open, standard protocols to access in-network storage. P2P applications can store and retrieve content in the in-network storage, as well as control resources (e.g., bandwidth, connections) consumed by peers in a P2P application." > > 4) There are many instances of marketing-like promises of what > "DECADE" will provide. Thanks. They will be revised. >This is a problem statement, not a marketing > document. DECADE is not a product, and despite what section4 says, the > goal of the WG is NOT to design DECADE; it is to identify > applications, describe the requirements, and develop an architecture. > The WG is explicitly prevented from developing the protocol without > going through a recharter. > Good comment. While DECADE WG is not chartered to develop the protocol at this moment, there are some basic functions needed to address the problems. When it cannot be called DECADE protocol, we just use the term "DECADE" for it. The protocols under this term might be the existing protocols, or existing protocols with extension, or some new protocol which are based on the requirements identified in DECADE WG. >Here are some claims: > > "DECADE provides basic access mechanisms" > "DECADE will provide access to storage and data transport > services in the network to improve their efficiency and reduce the > stress on the network infrastructure." > "It also improves the availability of P2P contents because the > in-network storage is always-on." > > So how does an architecture without a protocol do all these things? > > 5) in section 4, it says "(IAP), which is a standard, > P2P-application-agnostic protocol ..." > > IAP is NOT a standard protocol. A document that is a work in progress > that has not yet been approved should never claim it is a standard. > And the WG is not even working on designing a protocol yet, just a > problem statement, requirements, and an architecture, right? > You are right. Can we have a name(such as DECADE or anything else) for the assumed solution direction in the charter and use that name? > 6) Section 4 claims, IAP includes the following functionality (and > then lists a number of things). But the WG is not authorized to work > on protocols yet; how can you know what that protocol includes? and > why is this description of a proposed solution in the "problem > statement" document? You should be describing the problem, not the > solution. Section 4 actually describes requirements. We may move them to the requirements draft. > > 7) in section 5, there are lots of "A instructs its in-network storage > to downlaod a block from B's in-network storage, and finally A itself > retreives the block." How is this a problem statement? This is a usage scenario section which describes an example how the solution works. If you do not think this section is needed, we can remove it. > > 8) in section 5.1, paragraph 5 discusses how B can attach its storage > address in the message to its tracker. The WG is NOT designing a > protocol. How can you possibly know what can be passed in the message? > This problem statement can certainly tak about the problem to be > solved, but should NOT be talking about the details of how a proposed > protocol works. > As above. > 9) Security Considerations should discuss the security > threats/vulnerabilities that apply to in-network storage. You don't > need to describe how to mitigate them here; that can be done in the > requirments, architecture, and protocol documents. But you should > include the problem description here. The chairs can ask me if they > want a security advisor to help develop an appropriate threat > analysis. > If you can send a security advisor, that will be great and much appreciated! BR, -Haibin (as a co-author of problem statement draft) > > David Harrington > Director, IETF Transport Area > ietfdbh@comcast.net (preferred for ietf) > dbharrington@huaweisymantec.com > +1 603 828 1401 (cell) From haibin.song@huawei.com Mon Jun 20 01:01:50 2011 Return-Path: X-Original-To: decade@ietfa.amsl.com Delivered-To: decade@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E26C121F847F for ; Mon, 20 Jun 2011 01:01:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CrkuER0aohh9 for ; Mon, 20 Jun 2011 01:01:50 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id D804221F8478 for ; Mon, 20 Jun 2011 01:01:45 -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 <0LN2003H7WYNTT@szxga04-in.huawei.com> for decade@ietf.org; Mon, 20 Jun 2011 16:01:35 +0800 (CST) Received: from szxrg01-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 <0LN2001U9WXFUD@szxga04-in.huawei.com> for decade@ietf.org; Mon, 20 Jun 2011 16:01:35 +0800 (CST) Received: from 172.24.2.119 (EHLO szxeml206-edg.china.huawei.com) ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA FastPath queued) with ESMTP id ABT38838; Mon, 20 Jun 2011 16:01:34 +0800 (CST) Received: from SZXEML402-HUB.china.huawei.com (10.82.67.32) by szxeml206-edg.china.huawei.com (172.24.2.58) with Microsoft SMTP Server (TLS) id 14.1.270.1; Mon, 20 Jun 2011 15:54:02 +0800 Received: from SZXEML505-MBX.china.huawei.com ([169.254.2.122]) by SZXEML402-HUB.china.huawei.com ([10.82.67.32]) with mapi id 14.01.0270.001; Mon, 20 Jun 2011 15:54:04 +0800 Date: Mon, 20 Jun 2011 07:54:04 +0000 From: Songhaibin X-Originating-IP: [10.138.41.119] 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: re-chartering Thread-index: AcwvHzk/CEUPoBGIQN+FXNL3lyWv6A== X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected Subject: [decade] re-chartering 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 Jun 2011 08:01:51 -0000 Dear all, As we began our discussion about re-chartering from last IETF meeting. We would like to hear more thoughts and comments in the list. The topics include but not limit to what we talked at last meeting. 1. protocols 2. Mandatory underlying protocol 3. Mandatory naming scheme 4. service discovery and etc. What stuff should we work on in the next period in this WG in your opinion? Any special consideration? BR, -Haibin and Rich From buptxiaozhu@gmail.com Sun Jun 26 20:07:09 2011 Return-Path: X-Original-To: decade@ietfa.amsl.com Delivered-To: decade@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B434E11E807B for ; Sun, 26 Jun 2011 20:07:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.952 X-Spam-Level: **** X-Spam-Status: No, score=4.952 tagged_above=-999 required=5 tests=[BAYES_50=0.001, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zkld6jPA3J5r for ; Sun, 26 Jun 2011 20:07:07 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 90B9C11E809B for ; Sun, 26 Jun 2011 20:07:03 -0700 (PDT) Received: by yxp4 with SMTP id 4so19649yxp.31 for ; Sun, 26 Jun 2011 20:07:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=cF9w06Oz1xgnPjk28J+s70mUst/8SpJCATDLZkqdmkw=; b=KMXfqaUh6LjZV1YYtj0vbVXoJ9qbuH6ei+XZHxtUhhZYYILgduDhvUzaY938a4VwK+ jHvSSkKkA7E75riQV49SqdZhZ0qcrvuR9zYS8Gaa+Udk8d7c+LCf9WYSeD7w2S8Z6bYx gwFxUbyatN9VWqbhFgLdOrDi0XUVBLQljujpk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=B7IjwdswubHVK7yQR43Kmi4sMVVQRh1prN+5l0qjNIJqdw7i9imSuHoJMPgrzv5f+Y WYzaKnXGIoZATuL4n17oDoUYhnc/2WTG0O9msXE+3gI28UgjLEfVSgYRTAkJY9A6OWX3 285iOFOgo64p13Vn6fnoAJGrWwuHKqOKxpo+A= MIME-Version: 1.0 Received: by 10.150.114.11 with SMTP id m11mr1325193ybc.137.1309144022354; Sun, 26 Jun 2011 20:07:02 -0700 (PDT) Received: by 10.151.98.20 with HTTP; Sun, 26 Jun 2011 20:07:02 -0700 (PDT) In-Reply-To: References: <1CA25301D2219F40B3AA37201F0EACD11343C0AB@PACDCEXMB05.cable.comcast.com> Date: Mon, 27 Jun 2011 11:07:02 +0800 Message-ID: From: =?GB2312?B?1uzk7A==?= To: Richard Alimi Content-Type: multipart/alternative; boundary=000e0cd5d010698b2604a6a8d8b0 Cc: "decade@ietf.org" Subject: Re: [decade] draft-zhu-decade-additional-requirements 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 Jun 2011 03:07:09 -0000 --000e0cd5d010698b2604a6a8d8b0 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable hi, Richard and everybody The draft draft-zhu-decade-additional-requirements I submitted last year is about to expire. do you have some suggestions to update the version? and do the DECADE requirement draft has adopted some suggestions of my draft? 2011/3/14 Richard Alimi > Hi All, > > We've made all of these updates to the requirements document, with the > exception of: > > > - If an object is deleted as it is concurrently being read, then the > > server MAY continue to read it (lazy deletion), or it MAY discontinue > > reading the object and signal an error to the client reading the > > object. > > Upon looking at this again, it looks more like an implementation > detail. If anything, this would result in a "non-requirement" in the > document. However, it seems like a fairly low-level non-requirement to > state at this time. I'd propose to leave it out for now and revisit > this if it comes up again in the future. Thoughts? > > Thanks, > Rich > > 2011/3/2 Richard Alimi : > > Hi All, > > > > I'll offer a summary of this discussion. Let me know if I missed > > anything, or if there are objections/other thoughts on these proposed > > resolutions. > > > > Redirection: > > - We can add a requirement mentioning that DECADE may support > redirection. > > > > Data Classification: > > - I (personally) strongly disagree with attempting to classify access > > patterns or applications. We could add something saying that explicit > > hints (a la www.ietf.org/proceedings/78/slides/nfsv4-0.pdf) could be > > provided in DECADE. However, I don't think we need to do something > > new here. In particular, if the underlying storage/data transport > > supports hints, a DECADE client or server can use it. > > > > Storage Status: > > - Update section 5.1.6 to indicate that status information should > > include permissions of stored objects, if applicable. > > - Update 5.1.6 to indicate that status information should include > > other information about resource usage (the clients own resources, or > > resources used by other clients that have been authorized to > > read/write objects or open connections to one's storage). > > > > Requirements for object deletion/overwriting: > > - DECADE MAY have an overwrite flag (note that this may or may not be > > necessary depending on our naming, but the requirements document > > probably is not the place to take a stand on this at the current > > point.) > > - If an object is deleted as it is concurrently being read, then the > > server MAY continue to read it (lazy deletion), or it MAY discontinue > > reading the object and signal an error to the client reading the > > object. > > > > Would this be sufficient to merge in the points from > > draft-zhu-decade-additional-requirements-00 and this ensuing > > discussion? > > > > Thanks, > > Rich > > > > > > 2011/3/2 Woundy, Richard : > >> Folks, > >> > >> > >> > >> Do we have consensus yet about how the WG could have a single DECADE > >> requirements document going forward? I can't tell the state of our > >> requirements consolidation from the email thread below. > >> > >> > >> > >> It would be preferable if we could resolve this fully on the WG mailin= g > >> list, but this is important enough to allocate some time at our meetin= g > in > >> Prague. > >> > >> > >> > >> -- Rich > >> > >> > >> > >> From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.org] On > Behalf Of > >> ?? > >> Sent: Sunday, January 16, 2011 9:02 PM > >> To: Richard Alimi > >> Cc: decade@ietf.org > >> Subject: Re: [decade] draft-zhu-decade-additional-requirements > >> > >> > >> > >> hi, Richard: > >> > >> > >> > >> thanks for your reply:D > >> > >> additional discussion see inline:D > >> > >> > >> > >> 2011/1/14 Richard Alimi > >> > >> HI Xiao, > >> > >> 2011/1/12 =D6=EC=E4=EC : > >> > >>> hi, Richard > >>> see inline:D > >>> > >>> 2011/1/11 Richard Alimi > >>>> > >>>> Hi Xiao, > >>>> > >>>> On Mon, Jan 10, 2011 at 6:45 PM, =D6=EC=E4=EC wrote: > >>>> > > >>>> > hi, Richard, sorry for so late response because of be busy with > other > >>>> > projects. > >>>> > some discussion see inline:D marked by red. > >>>> > > >>>> > On Tue, Jan 4, 2011 at 4:06 AM, Richard Alimi > >>>> > wrote: > >>>> >> > >>>> >> Hi Xiao, > >>>> >> > >>>> >> Thank you for the draft. Some comments on the requirements: > >>>> >> > >>>> >> Request Redirects: > >>>> >> > >>>> >> This would provide some additional freedom for the storage > provider. > >>>> >> I think it is reasonable since it doesn't necessitate additional > >>>> >> complexity for the DECADE server, but allows it if desired. > However, > >>>> >> note that it may complicate some of the other components of the > >>>> >> design. In particular, if there is a per-user quota for storage, = is > >>>> >> the user made aware of the quota at each in-network storage (if > there > >>>> >> is no shared storage between them)? Resource sharing policies ma= y > be > >>>> >> impacted (e.g., if a bandwidth sharing weight of 1 may mean > something > >>>> >> different at DECADE server A than it does at DECADE server B). A= t > >>>> >> this point it may be best to just note these so they are > documented, > >>>> >> but since the specification of the resource sharing policies are > still > >>>> >> being contemplated for the basic case of a single server it may b= e > >>>> >> premature to even try and solve them for the case supporting > >>>> >> redirection. > >>>> >> > >>>> > actually, you mean two points, right? > >>>> > 1. whether or not to be ware of the content at each in-network > storage > >>>> > and of course resource sharing policies can be impact in the reque= st > >>>> > redirection. your suggestion"just to note these so they are > documented" > >>>> > will > >>>> > be ok, or DECADE server list with some parameters will be return f= or > >>>> > user to > >>>> > select the appropriate DECADE server, which can avoid the differen= t > >>>> > weighted > >>>> > of the same parameter in server decision. but the parameter used i= n > >>>> > select > >>>> > the best DECADE server will be known for DECADE servers, in which > other > >>>> > complexities will be added. anyway, all the solution are the > >>>> > implementation > >>>> > issue, which, i believe, does not impact the necessity of the > >>>> > requirement. > >>>> > >>>> In general, I'd agree that the decision about where to redirect woul= d > >>>> be an implementation issue. > >>>> > >>>> > > >>>> > 2. you mean "the resource sharing policies are still being > considered > >>>> > in > >>>> > a single server", so it may be premature to support redirection. > the > >>>> > architecture and protocol will be badly impacted if the requiremen= ts > >>>> > change. > >>>> > so the designing can be taken step by step, but the requirements > >>>> > should be > >>>> > overall considered. > >>>> > >>>> I said that it is probably premature to consider how resource sharin= g > >>>> policies works across servers (or even if we need to say anything > >>>> about it) since we have not determined how to specify them (or rathe= r, > >>>> how little we need to specify in protocol) for a single server. I di= d > >>>> not mean to imply that redirection could not be introduced as a > >>>> requirement. > >>>> > >>> > >>>> > >>>> > > >>>> > > >>>> >> > >>>> >> Multi-connection: > >>>> >> > >>>> >> I'm not quite clear on the intention of the requirement. My > >>>> >> understanding is that you wish the client to be able to have > multiple > >>>> >> connections open spanning multiple DECADE servers. Is that correc= t? > >>>> >> > >>>> >> If so, do we need this stated as a requirement or the protocol? O= r > is > >>>> >> this a policy that would be allowed/disallowed by the storage > >>>> >> provider? > >>>> >> > >>>> > yep, your understanding is right, the scenarios were just describe= d > in > >>>> > draft as "soft handover in wireless environment and delete operati= on > in > >>>> > multi-servers". under these consideration, the authentication and > >>>> > authorization need to be taken each time when setup connection wit= h > a > >>>> > new > >>>> > DECADE server, or just be taken only once during the service? > >>>> > >>>> The DECADE server should need to do some sort of check on each new > >>>> connection, regardless of whether the user has or previously had a > >>>> connection open to a different DECADE server, right? Note that the > >>>> requirements don't indicate how authentication or authorization is > >>>> done, and allow a server to make optimizations if it is enforcing th= e > >>>> same permissions. > >>>> > >>>> Can you indicate where the existing authorization-related requiremen= ts > >>>> (in particular, 4.1.6.3 of draft-ietf-decade-reqs-00) do not suffice > >>>> for the use case you are thinking of? > >> > >>> as considering the service continuity, the next serving DECADE serve= r > >>> should know the progress of the service, how does they know? > >> > >> By progress of the service, do you mean current user state (e.g., > >> quota, recent resource usage history, permissions, etc)? > >> > >> yes, and include data delivery proceeding. > >>> so if the > >>> service proceeding information should be known by the next serving > server, > >>> or different servers need to coordinate and schedule each other to > fulfill > >>> the user request, i believe the the 4.1.6.3 of the > >>> draft-ietf-decade-req-00 > >>> cannot satisfy the req. what do you think about? > >> > >> Note that the protocol that is covered here is the client-server > >> protocol. Some of the same protocol may be useful between DECADE > >> servers (especially in different administrative domains) for storing > >> and retrieving data, but that does not mean that there can't be > >> additional protocol(s) (not specified here) that are used between > >> DECADE servers as well. For example, if DECADE servers within an > >> administrative domain can certainly have their own mechanism to share > >> such information. If such capabilities were included in the DECADE > >> protocol (e.g., a need to do this between administrative domains), > >> that sounds like lots more complexity that we need at this point. > >> but the access between in-network storage also is included in IAP > described > >> in problem statement. i mean why not put this kind of function in > DECADE > >> since the IAP is defined just like that? > >> That said, it sounds to me like what is described in 4.1.6.3 would be > >> sufficient (from the perspective of the client-server protocol, > >> anyways) to implement what you're describing. If not, what > >> specifically is missing and what use-case does it not meet? > >> > >> so you mean the information you mentioned above, just like current use= r > >> state (e.g., > >> quota, recent resource usage history, permissions, etc) was already > included > >> in DECADE requirement? what about the data delivery proceeding > information? > >> can you specify the chapter for me ? thanks? > >>>> > > >>>> > > >>>> >> > >>>> >> Data Distribution: > >>>> >> > >>>> >> I'm also confused about the intent of this requirement. This > >>>> >> statement has me somewhat worried: "The distribution is transpare= nt > to > >>>> >> the users as they interact with the in-network storage as a singl= e > >>>> >> logical system." Does this mean that you are proposing for DECADE > >>>> >> servers to assume the responsibility for deciding how data is to = be > >>>> >> distributed throughout the network, including the path of the dat= a, > >>>> >> which servers act as intermediate caches, content expiration > policies, > >>>> >> etc? If this is true, I think it is missing one of the major > points > >>>> >> of DECADE. In particular, these decisions are application-depende= nt > >>>> >> and are not implemented within DECADE. Instead, DECADE provides t= he > >>>> >> basic capabilities and the functionality described above are > >>>> >> implemented by the applications using DECADE. > >>>> >> > >>>> >> Or, am I misinterpreting the intent of the requirement? > >>>> >> > >>>> > you mean DECADE provides the basic capabilities, so can you give > some > >>>> > specify explanations on DECADE capabilities in supporting data > >>>> > distribution? > >>>> >> > >>>> > >>>> The problem statement gives a couple of scenarios. The "Integration > >>>> Examples" presentation from IETF 79 also has more details of an > >>>> on-going effort at Yale. > >> > >>> okay, thx for your information, i will lookup and refer, actually, th= e > >>> content publisher described in problem statement remind me of the > >>> protocol requirements which i did not find in draft-ietf-decade-reqs-= 00 > to > >>> support content publish. or i miss some points? > >> > >> Which requirements do you think are missing? > >> > >>>> >> Service Assurance: > >>>> >> > >>>> >> It seems problematic to include "assurance" in a DECADE. Shouldn= 't > >>>> >> these instead be part of SLAs with a storage provider? Why shoul= d > >>>> >> they be DECADE's responsibility? > >>>> >> > >>>> >> Regarding "resource reservation", are you referring to an actual > >>>> >> reservation (which might be problematic -- see above) or do you > mean > >>>> >> that the resource share should able to be specified at the time t= he > >>>> >> connection opens and be assumed to be the same for the duration o= f > the > >>>> >> connection? > >>>> >> > >>>> >> Regarding Dynamic Feedback, is this orthogonal to the storage > >>>> >> protocol? It seems like what you want here is a generic "status" > >>>> >> service saying how loaded a server is? > >>>> >> > >>>> > thats right, actually, the flow control mechanism was under > discussion > >>>> > in writing the draft at first. what about your opinion in this > >>>> > requirements? > >>>> > > >>>> > >>>> I'm not sure what the typical way of providing such "load status" > >>>> information for IETF protocols, but my inclination is that it should > >>>> not be in the DECADE protocol itself. Maybe someone else with a > >>>> longer history in IETF could jump in here :) > >>> so can i understand that "load status" is kind of necessity > information > >>> for DECADE Server, but where and who collects the information are > >>> remain discussion? > >> > >> The storage provider is free to collect the information wherever and > >> however they wish. The DECADE server implementation could additional > >> export whatever status information it wishes. I don't think the DECADE > >> protocol needs to be concerned with that. > >> > >> Note that certain error conditions (e.g., overload, insufficient > >> resources) may be signaled by a DECADE server (there are already have > >> requirements for those). If you are referring to status for a user's > >> resources, there is already a requirement for that too. > >> > >> I'm just not convinced that the DECADE protocol needs to export its > >> current load status to clients. > >> > >> actually i am not sure which elements in DECADE needs the load > >> status,(DECADE client or network storage if the network storage needs = to > >> redirect the request or both?). > >> > >> > >> > >> And the requirement draft currently seems describe the overload > condition as > >> the event triggering. do you think if it is necessary to periodically > >> reporting of the DECADE network status to client for its network stora= ge > >> selection? > >> > >> > >> > >> and the requirement draft just describe DECADE which is busy to serve > other > >> requests must be able to reject requests, not consider how to handle t= he > >> user request after being rejected? > >> > >>>> >> > >>>> >> Data classification: > >>>> >> > >>>> >> Would it be better to instead have the client specify properties = of > >>>> >> the content instead of place it into ? See > >>>> >> www.ietf.org/proceedings/78/slides/nfsv4-0.pdf for an example of > this > >>>> >> approach for NFS. > >>>> >> > >>>> >> I think a problem with classifying applications is that it assume= s > >>>> >> that applications fit one of the supplied classifications. What i= f > it > >>>> >> may fit multiple classifications? or none? Another problem is it > >>>> >> assumes that servers assume based on indirect and assumed > information > >>>> >> that they know what to do with a particular piece of content. Why > not > >>>> >> have an application specify its desires directly? > >>>> >> > >>>> > > >>>> > > >>>> >> > >>>> >> Small Objects: > >>>> >> > >>>> >> What is the new requirement here? Why is the existing requiremen= t > in > >>>> >> draft-ietf-decade-reqs-00 insufficient? > >>>> >> > >>>> >> This also has me a bit worried: > >>>> >> "And the in-network storage has the limited storage capacity, wit= h > the > >>>> >> arrival of user requests and data distribution requirements, the > data > >>>> >> stored in the in-network storage will be replaced if the storage > >>>> >> reaches the limit and data arrivals continually." > >>>> >> > >>>> >> How does the server know what the proper replacement strategy is > for > >>>> >> an application? I think DECADE's philosophy is that applications > >>>> >> should decide this. A simple way to do this is explicit deletion = by > an > >>>> >> application, but perhaps a more efficient (yet more complex) > solution > >>>> >> is for an application to specify the replacement policy to the > server. > >>>> >> > >>>> > actually, the key in "the data classification and small objects " = is > >>>> > whether does it or not in P2P application? i did not find data > >>>> > classification was adopted in P2P application so far, let alone > DECADE > >>>> > need > >>>> > to classify the data used in all kinds of application. > >>>> > > >>>> > >>>> So, do you agree that it is problematic to try and classify each typ= e > >>>> of application and try to specify the typical workload for each clas= s? > >>>> > >>>> My point was that I don't think its necessary to do the classificati= on > >>>> at all. It is more extensible (and directly useful) for a server to > >>>> just give it direct hints about what would be preferable. > >>> > >>> yep, i believe it may be a little difficult, but worthy doing. > specially > >>> for improving the resource utilization within a single server and > reducing > >>> the response time for client. what about others opinion? > >> > >> Can you justify why giving classifications (e.g., "I'm a live > >> streaming application") would be better than giving specific hints > >> (e.g., "please don't bother persistent these objects to disk")? > >> > >> i mean data in different kind of operation mode and attribute should > have > >> different user patterns and storage rules, which may be help to improv= e > the > >> resource utilization and reduce the response time for request, what ar= e > you > >> understanding? > >>> >> > >>>> >> Removal of Expired Records: > >>>> >> > >>>> >> "However, the two scenarios did not mention how to handle the old > >>>> >> resource if the user distributes the new resource which is an > updated > >>>> >> copy of the old resource." > >>>> >> > >>>> >> Why does this need to be handled in the requirements? Are you > trying > >>>> >> to draw the distinction between immediate deletion of content and > lazy > >>>> >> deletion? > >>>> >> > >>>> > i mean the meaning of delete operation and how to handle the expir= ed > >>>> > records need to be clarify in requirements. > >>>> > >>>> My inclination is that "deleted" means that other requests the objec= t > >>>> of the same name should result an error, until another object with t= he > >>>> same name is stored. > >>> > >>> okay, under the scenario "client uploads the new version, and did not > >>> specify how to handle the old version", did DECADE server delete the > older > >>> version (or just label it unavailable, anyway, it is implementation > issue > >>> ) > >>> or not ? in another word, just replace the older version with the new > >>> version with the same name? > >> > >> In this case, I would think the "write" of the new object should be > >> rejected, or if desired, we could have an overwrite option. This > >> could be added to the requirements if it helps to clarify. > >> > >> yep, no matter which solution is chosen, let the understanding > unanimously:D > >>> how to handle the older version which is > >>> transferring from server to client? > >> > >> I think it would be cleaner to ask the server to continue sending an > >> object once it has been started, but ultimately this would be the > >> decision of the server's implementation I think. Maybe a "SHOULD" > >> requirement. This could be added if desired. > >> > >> Thank you for these questions. It helps design the requirements more > >> cleanly if there are specific scenarios in front of us :) > >> just discussion together:D and also thanks for your points to help me > >> understanding more! > >> Rich > >> > >>>> I think that the time the data is removed from disk (or memory) shou= ld > >>>> be up to the implementation. A storage provider might still have as > >>>> part of some agreement that deleted data will be removed within X > >>>> days/hours/minutes/whatever. > >>> > >>> agree with you. > >>>> > >>>> If people in the WG think it is necessary, we could have a requireme= nt > >>>> that says the protocol should support an argument indicating immedia= te > >>>> deletion, but it is not clear that we need this. > >>>> > >>>> Rich > >>>> > >>>> >> > >>>> >> Thanks! > >>>> >> Rich > >>>> >> > >>>> >> > >>>> >> On Mon, Dec 27, 2010 at 12:57 AM, =D6=EC=E4=EC > wrote: > >>>> >> > Dear all, > >>>> >> > > >>>> >> > There is a slightly updated version of the decade additional > >>>> >> > requirements > >>>> >> > draft. > >>>> >> > > >>>> >> > > >>>> >> > > https://datatracker.ietf.org/doc/draft-zhu-decade-additional-requirements= / > >>>> >> > > >>>> >> > Jin Peng, Yunfei Zhang and me are expecting to have a discussio= n > >>>> >> > with > >>>> >> > all of > >>>> >> > you. > >>>> >> > > >>>> >> > Any comments are appreciated! > >>>> >> > > >>>> >> > A new version of I-D, > >>>> >> > draft-zhu-decade-additional-requirements-00.txt > >>>> >> > has been successfully submitted by Xiao Zhu and posted to the > IETF > >>>> >> > repository. > >>>> >> > > >>>> >> > Filename: draft-zhu-decade-additional-requirements > >>>> >> > Revision: 00 > >>>> >> > Title: Additional protocol requirements on DECA= DE > >>>> >> > Creation_date: 2010-12-27 > >>>> >> > WG ID: Independent Submission > >>>> >> > Number_of_pages: 10 > >>>> >> > > >>>> >> > Abstract: > >>>> >> > The DECoupled Application Data Enroute(DECADE)working group is > >>>> >> > specifying standardized interfaces for accessing in-network > storage > >>>> >> > from applications to store, retrieve and manage data. The main > >>>> >> > object > >>>> >> > is to provide a framework that is useful to the applications, > >>>> >> > including P2P applications and other data-oriented applications= , > >>>> >> > possibly related applications that can benefit from accessing i= n- > >>>> >> > network storage. This memo focuses on some requirements such as > >>>> >> > request redirecting and so on which are on the central of > mobility, > >>>> >> > wireless network environment and CDN application. We present > these > >>>> >> > in > >>>> >> > this memo as additional requirements that should be considered > for > >>>> >> > the DECADE architecture and protocol specifications. > >>>> >> > > >>>> >> > > >>>> >> > > >>>> >> > The IETF Secretariat. > >>>> >> > > >>>> >> > -- > >>>> >> > Best wishes, > >>>> >> > > >>>> >> > Beijing University of Posts & Telecommunications (BUPT) > >>>> >> > Zhu Xiao ( =D6=EC=E4=EC ) > >>>> >> > E-mail: buptxiaozhu@gmail.com > >>>> >> > mobile:+86 134-8881-9004 > >>>> >> > > >>>> >> > _______________________________________________ > >>>> >> > decade mailing list > >>>> >> > decade@ietf.org > >>>> >> > https://www.ietf.org/mailman/listinfo/decade > >>>> >> > > >>>> >> > > >>>> > > >>>> > > >>>> > > >>>> > -- > >>>> > Best wishes, > >>>> > > >>>> > Beijing University of Posts & Telecommunications (BUPT) > >>>> > Zhu Xiao ( =D6=EC=E4=EC ) > >>>> > E-mail: buptxiaozhu@gmail.com > >>>> > mobile:+86 134-8881-9004 > >>> > >>> > >>> > >>> -- > >>> Best wishes, > >>> > >>> Beijing University of Posts & Telecommunications (BUPT) > >>> Zhu Xiao ( =D6=EC=E4=EC ) > >>> E-mail: buptxiaozhu@gmail.com > >>> mobile:+86 134-8881-9004 > >>> > >> > >> > >> -- > >> Best wishes, > >> > >> Beijing University of Posts & Telecommunications (BUPT) > >> Zhu Xiao ( =D6=EC=E4=EC ) > >> E-mail: buptxiaozhu@gmail.com > >> mobile:+86 134-8881-9004 > > > --=20 Best wishes, Beijing University of Posts & Telecommunications (BUPT) Zhu Xiao ( =D6=EC=E4=EC ) E-mail: buptxiaozhu@gmail.com mobile:+86 134-8881-9004 --000e0cd5d010698b2604a6a8d8b0 Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable hi, Richard and everybody

The draft draft-zhu-decad= e-additional-requirements I submitted last year is about to expire. do you = have some suggestions to update the version? and do the DECADE requirement = draft has adopted some suggestions of my draft?

2011/3/14 Richard Alimi &l= t;rich@velvetsea.net>
Hi All,

We've made all of these updates to the requirements document, with the<= br> exception of:

> - If an object is deleted as it is concurrently being read, then the > server MAY continue to read it (lazy deletion), or it MAY discontinue<= br> > reading the object and signal an error to the client reading the
> object.

Upon looking at this again, it looks more like an implementation
detail. If anything, this would result in a "non-requirement" in = the
document. However, it seems like a fairly low-level non-requirement to
state at this time. I'd propose to leave it out for now and revisit
this if it comes up again in the future.  Thoughts?

Thanks,
Rich

2011/3/2 Richard Alimi <rich@velve= tsea.net>:
> Hi All,
>
> I'll offer a summary of this discussion. Let me know if I missed > anything, or if there are objections/other thoughts on these proposed<= br> > resolutions.
>
> Redirection:
> - We can add a requirement mentioning that DECADE may support redirect= ion.
>
> Data Classification:
> - I (personally) strongly disagree with attempting to classify access<= br> > patterns or applications. We could add something saying that explicit<= br> > hints (a la www.ietf.org/proceedings/78/slides/nfsv4-0.pdf) could be
> provided in DECADE.  However, I don't think we need to do som= ething
> new here. In particular, if the underlying storage/data transport
> supports hints, a DECADE client or server can use it.
>
> Storage Status:
> - Update section 5.1.6 to indicate that status information should
> include permissions of stored objects, if applicable.
> - Update 5.1.6 to indicate that status information should include
> other information about resource usage (the clients own resources, or<= br> > resources used by other clients that have been authorized to
> read/write objects or open connections to one's storage).
>
> Requirements for object deletion/overwriting:
> - DECADE MAY have an overwrite flag (note that this may or may not be<= br> > necessary depending on our naming, but the requirements document
> probably is not the place to take a stand on this at the current
> point.)
> - If an object is deleted as it is concurrently being read, then the > server MAY continue to read it (lazy deletion), or it MAY discontinue<= br> > reading the object and signal an error to the client reading the
> object.
>
> Would this be sufficient to merge in the points from
> draft-zhu-decade-additional-requirements-00 and this ensuing
> discussion?
>
> Thanks,
> Rich
>
>
> 2011/3/2 Woundy, Richard <Richard_Woundy@cable.comcast.com>:
>> Folks,
>>
>>
>>
>> Do we have consensus yet about how the WG could have a single DECA= DE
>> requirements document going forward? I can't tell the state of= our
>> requirements consolidation from the email thread below.
>>
>>
>>
>> It would be preferable if we could resolve this fully on the WG ma= iling
>> list, but this is important enough to allocate some time at our me= eting in
>> Prague.
>>
>>
>>
>> -- Rich
>>
>>
>>
>> From: decade-bounces@ie= tf.org [mailto:decade-bounce= s@ietf.org] On Behalf Of
>> ??
>> Sent: Sunday, January 16, 2011 9:02 PM
>> To: Richard Alimi
>> Cc: decade@ietf.org
>> Subject: Re: [decade] draft-zhu-decade-additional-requirements
>>
>>
>>
>> hi, Richard:
>>
>>
>>
>> thanks for your reply:D
>>
>> additional discussion see inline:D
>>
>>
>>
>> 2011/1/14 Richard Alimi <= rich@velvetsea.net>
>>
>> HI Xiao,
>>
>> 2011/1/12 =D6=EC=E4=EC <buptxiaozhu@gmail.com>:
>>
>>> hi, Richard
>>> see inline:D
>>>
>>> 2011/1/11 Richard Alimi <rich@velvetsea.net>
>>>>
>>>> Hi Xiao,
>>>>
>>>> On Mon, Jan 10, 2011 at 6:45 PM, =D6=EC=E4=EC <buptxiaozhu@gmail.com> wrote:
>>>> >
>>>> > hi, Richard, sorry for so late response because of be= busy with other
>>>> > projects.
>>>> > some discussion see inline:D marked by red.
>>>> >
>>>> > On Tue, Jan 4, 2011 at 4:06 AM, Richard Alimi <rich@velvetsea.net>
>>>> > wrote:
>>>> >>
>>>> >> Hi Xiao,
>>>> >>
>>>> >> Thank you for the draft.  Some comments on t= he requirements:
>>>> >>
>>>> >> Request Redirects:
>>>> >>
>>>> >> This would provide some additional freedom for th= e storage provider.
>>>> >> I think it is reasonable since it doesn't nec= essitate additional
>>>> >> complexity for the DECADE server, but allows it i= f desired. However,
>>>> >> note that it may complicate some of the other com= ponents of the
>>>> >> design. In particular, if there is a per-user quo= ta for storage, is
>>>> >> the user made aware of the quota at each in-netwo= rk storage (if there
>>>> >> is no shared storage between them)?  Resourc= e sharing policies may be
>>>> >> impacted (e.g., if a bandwidth sharing weight of = 1 may mean something
>>>> >> different at DECADE server A than it does at DECA= DE server B).  At
>>>> >> this point it may be best to just note these so t= hey are documented,
>>>> >> but since the specification of the resource shari= ng policies are still
>>>> >> being contemplated for the basic case of a single= server it may be
>>>> >> premature to even try and solve them for the case= supporting
>>>> >> redirection.
>>>> >>
>>>> > actually, you mean two points, right?
>>>> > 1. whether or not to be ware of the content at each i= n-network storage
>>>> > and of course resource sharing policies can be impact= in the request
>>>> > redirection. your suggestion"just to note these = so they are documented"
>>>> > will
>>>> > be ok, or DECADE server list with some parameters wil= l be return for
>>>> > user to
>>>> > select the appropriate DECADE server, which can avoid= the different
>>>> > weighted
>>>> > of the same parameter in server decision. but the par= ameter used in
>>>> > select
>>>> > the best DECADE server will be known for DECADE serve= rs, in which other
>>>> > complexities will be added. anyway, all the solution = are the
>>>> > implementation
>>>> > issue, which, i believe, does not impact the necessit= y of the
>>>> > requirement.
>>>>
>>>> In general, I'd agree that the decision about where to= redirect would
>>>> be an implementation issue.
>>>>
>>>> >
>>>> > 2. you mean "the resource sharing policies are s= till being considered
>>>> > in
>>>> > a single server", so it may be premature to supp= ort redirection.  the
>>>> > architecture and protocol will be badly impacted if t= he requirements
>>>> > change.
>>>> > so the designing can be  taken  step by ste= p, but the requirements
>>>> > should be
>>>> > overall considered.
>>>>
>>>> I said that it is probably premature to consider how resou= rce sharing
>>>> policies works across servers (or even if we need to say a= nything
>>>> about it) since we have not determined how to specify them= (or rather,
>>>> how little we need to specify in protocol) for a single se= rver. I did
>>>> not mean to imply that redirection could not be introduced= as a
>>>> requirement.
>>>>
>>>
>>>>
>>>> >
>>>> >
>>>> >>
>>>> >> Multi-connection:
>>>> >>
>>>> >> I'm not quite clear on the intention of the r= equirement.  My
>>>> >> understanding is that you wish the client to be a= ble to have multiple
>>>> >> connections open spanning multiple DECADE servers= . Is that correct?
>>>> >>
>>>> >> If so, do we need this stated as a requirement or= the protocol? Or is
>>>> >> this a policy that would be allowed/disallowed by= the storage
>>>> >> provider?
>>>> >>
>>>> > yep, your understanding is right, the scenarios were = just described in
>>>> > draft as "soft handover in wireless environment = and delete operation in
>>>> > multi-servers". under these consideration, the a= uthentication and
>>>> > authorization need to be taken each time when setup c= onnection with a
>>>> > new
>>>> > DECADE server, or just be taken only once during &nbs= p;the service?
>>>>
>>>> The DECADE server should need to do some sort of check on = each new
>>>> connection, regardless of whether the user has or previous= ly had a
>>>> connection open to a different DECADE server, right?  = ;Note that the
>>>> requirements don't indicate how authentication or auth= orization is
>>>> done, and allow a server to make optimizations if it is en= forcing the
>>>> same permissions.
>>>>
>>>> Can you indicate where the existing authorization-related = requirements
>>>> (in particular, 4.1.6.3 of draft-ietf-decade-reqs-00) do n= ot suffice
>>>> for the use case you are thinking of?
>>
>>> as considering the service continuity, the next serving  = DECADE server
>>> should know the progress of the service, how does they know? >>
>> By progress of the service, do you mean current user state (e.g.,<= br> >> quota, recent resource usage history, permissions, etc)?
>>
>> yes, and include data delivery proceeding.
>>> so if the
>>> service proceeding information should be known by the next ser= ving server,
>>> or different servers need to coordinate and schedule each othe= r to fulfill
>>> the user request, i believe the the 4.1.6.3 of the
>>> draft-ietf-decade-req-00
>>> cannot satisfy the req. what do you think about?
>>
>> Note that the protocol that is covered here is the client-server >> protocol. Some of the same protocol may be useful between DECADE >> servers (especially in different administrative domains) for stori= ng
>> and retrieving data, but that does not mean that there can't b= e
>> additional protocol(s) (not specified here) that are used between<= br> >> DECADE servers as well.  For example, if DECADE servers withi= n an
>> administrative domain can certainly have their own mechanism to sh= are
>> such information.  If such capabilities were included in the = DECADE
>> protocol (e.g., a need to do this between administrative domains),=
>> that sounds like lots more complexity that we need at this point.<= br> >> but the access between in-network storage also is included in IAP = described
>> in problem statement.  i mean why not put this kind of functi= on in DECADE
>> since the IAP is defined just like that?
>> That said, it sounds to me like what is de= scribed in 4.1.6.3 would be
>> sufficient (from the perspective of the client-server protocol, >> anyways) to implement what you're describing. If not, what
>> specifically is missing and what use-case does it not meet?
>>
>> so you mean the information you mentioned above, just like current= user
>> state (e.g.,
>> quota, recent resource usage history, permissions, etc) was alread= y included
>> in DECADE requirement? what about the data delivery proceeding inf= ormation?
>> can you specify the chapter for me ? thanks?
>>>> >
>>>> >
>>>> >>
>>>> >> Data Dist= ribution:
>>>> >>
>>>> >> I'm also confused about the intent of this re= quirement.  This
>>>> >> statement has me somewhat worried: "The dist= ribution is transparent to
>>>> >> the users as they interact with the in-network st= orage as a single
>>>> >> logical system." Does this mean that you are= proposing for DECADE
>>>> >> servers to assume the responsibility for deciding= how data is to be
>>>> >> distributed throughout the network, including the= path of the data,
>>>> >> which servers act as intermediate caches, content= expiration policies,
>>>> >> etc?  If this is true, I think it is missing= one of the major points
>>>> >> of DECADE. In particular, these decisions are app= lication-dependent
>>>> >> and are not implemented within DECADE. Instead, D= ECADE provides the
>>>> >> basic capabilities and the functionality describe= d above are
>>>> >> implemented by the applications using DECADE.
>>>> >>
>>>> >> Or, am I misinterpreting the intent of the requir= ement?
>>>> >>
>>>> > you mean DECADE provides the basic capabilities, so c= an you give some
>>>> > specify explanations on DECADE capabilities in suppor= ting data
>>>> > distribution?
>>>> >>
>>>>
>>>> The problem statement gives a couple of scenarios. The &qu= ot;Integration
>>>> Examples" presentation from IETF 79 also has more det= ails of an
>>>> on-going effort at Yale.
>>
>>> okay, thx for your information, i will lookup and refer, actua= lly, the
>>> content publisher described in problem statement remind me of =  the
>>> protocol requirements which i did not find in draft-ietf-decad= e-reqs-00 to
>>> support content publish. or i miss some points?
>>
>> Which requirements do you think are missing?
>>
>>>> >> Service Assurance:
>>>> >>
>>>> >> It seems problematic to include "assurance&q= uot; in a DECADE.  Shouldn't
>>>> >> these instead be part of SLAs with a storage prov= ider?  Why should
>>>> >> they be DECADE's responsibility?
>>>> >>
>>>> >> Regarding "resource reservation", are y= ou referring to an actual
>>>> >> reservation (which might be problematic -- see ab= ove) or do you mean
>>>> >> that the resource share should able to be specifi= ed at the time the
>>>> >> connection opens and be assumed to be the same fo= r the duration of the
>>>> >> connection?
>>>> >>
>>>> >> Regarding Dynamic Feedback, is this orthogonal to= the storage
>>>> >> protocol?  It seems like what you want here = is a generic "status"
>>>> >> service saying how loaded a server is?
>>>> >>
>>>> > thats right, actually, the flow control mechanism was= under discussion
>>>> > in writing the draft at first. what about your opinio= n in this
>>>> > requirements?
>>>> >
>>>>
>>>> I'm not sure what the typical way of providing such &q= uot;load status"
>>>> information for IETF protocols, but my inclination is that= it should
>>>> not be in the DECADE protocol itself.  Maybe someone = else with a
>>>> longer history in IETF could jump in here :)
>>> so can i understand that "load status" is kind of ne= cessity  information
>>> for DECADE Server, but where and who collects the information = are
>>> remain discussion?
>>
>> The storage provider is free to collect the information wherever a= nd
>> however they wish.  The DECADE server implementation could ad= ditional
>> export whatever status information it wishes. I don't think th= e DECADE
>> protocol needs to be concerned with that.
>>
>> Note that certain error conditions (e.g., overload, insufficient >> resources) may be signaled by a DECADE server (there are already h= ave
>> requirements for those).  If you are referring to status for = a user's
>> resources, there is already a requirement for that too.
>>
>> I'm just not convinced that the DECADE protocol needs to expor= t its
>> current load status to clients.
>>
>> actually i am not sure which elements in DECADE needs the load
>> status,(DECADE client or network storage if the network storage ne= eds to
>> redirect the request or both?).
>>
>>
>>
>> And the requirement draft currently seems describe the overload co= ndition as
>> the event triggering. do you think if it is necessary to periodica= lly
>> reporting of the DECADE network status to client for its network s= torage
>> selection?
>>
>>
>>
>> and the requirement draft just descr= ibe DECADE which is busy to serve other
>> requests must be able to reject requests, not consider how to hand= le the
>> user request after being rejected?
>>
>>>> >>
>>>> >> Data clas= sification:
>>>> >>
>>>> >> Would it be better to instead have the client spe= cify properties of
>>>> >> the content instead of place it into ? See
>>>> >> www.ietf.org/proceedings/78/slides/nfsv4= -0.pdf for an example of this
>>>> >> approach for NFS.
>>>> >>
>>>> >> I think a problem with classifying applications i= s that it assumes
>>>> >> that applications fit one of the supplied classif= ications. What if it
>>>> >> may fit multiple classifications? or none?  = Another problem is it
>>>> >> assumes that servers assume based on indirect and= assumed information
>>>> >> that they know what to do with a particular piece= of content. Why not
>>>> >> have an application specify its desires directly?=
>>>> >>
>>>> >
>>>> >
>>>> >>
>>>> >> Small Objects:
>>>> >>
>>>> >> What is the new requirement here?  Why is th= e existing requirement in
>>>> >> draft-ietf-decade-reqs-00 insufficient?
>>>> >>
>>>> >> This also has me a bit worried:
>>>> >> "And the in-network storage has the limited = storage capacity, with the
>>>> >> arrival of user requests and data distribution re= quirements, the data
>>>> >> stored in the in-network storage will be replaced= if the storage
>>>> >> reaches the limit and data arrivals continually.&= quot;
>>>> >>
>>>> >> How does the server know what the proper replacem= ent strategy is for
>>>> >> an application? I think DECADE's philosophy i= s that applications
>>>> >> should decide this. A simple way to do this is ex= plicit deletion by an
>>>> >> application, but perhaps a more efficient (yet mo= re complex) solution
>>>> >> is for an application to specify the replacement = policy to the server.
>>>> >>
>>>> > actually, the key in "the data classification an= d small objects " is
>>>> > whether does it or not in P2P application? i did not = find data
>>>> > classification was adopted in P2P application so far,= let alone DECADE
>>>> > need
>>>> > to classify the data used in all kinds of application= .
>>>> >
>>>>
>>>> So, do you agree that it is problematic to try and classif= y each type
>>>> of application and try to specify the typical workload for= each class?
>>>>
>>>> My point was that I don't think its necessary to do th= e classification
>>>> at all.  It is more extensible (and directly useful) = for a server to
>>>> just give it direct hints about what would be preferable.<= br> >>>
>>> yep, i believe it may be a little difficult, but worthy doing.= specially
>>> for improving the resource utilization within a single server = and reducing
>>> the response time for client. what about others opinion?
>>
>> Can you justify why giving classifications (e.g., "I'm a = live
>> streaming application") would be better than giving specific = hints
>> (e.g., "please don't bother persistent these objects to d= isk")?
>>
>> i mean data in different kind of operation mode and attribute shou= ld have
>> different user patterns and storage rules, which may be help to im= prove the
>> resource utilization and reduce the response time for request, wha= t are you
>> understanding?
>>> >>
>>>> >> Rem= oval of Expired Records:
>>>> >>
>>>> >> "However, the two scenarios did not mention = how to handle the old
>>>> >> resource if the user distributes the new resource= which is an updated
>>>> >> copy of the old resource."
>>>> >>
>>>> >> Why does this need to be handled in the requireme= nts?  Are you trying
>>>> >> to draw the distinction between immediate deletio= n of content and lazy
>>>> >> deletion?
>>>> >>
>>>> > i mean the meaning of delete operation and how to han= dle the expired
>>>> > records need to be clarify in requirements.
>>>>
>>>> My inclination is that "deleted" means that othe= r requests the object
>>>> of the same name should result an error, until another obj= ect with the
>>>> same name is stored.
>>>
>>> okay, under the scenario "client uploads the new version,= and did not
>>> specify how to handle the old version", did DECADE server= delete the older
>>> version (or just label it unavailable, anyway, it is implement= ation issue
>>> )
>>> or not ? in another word, just replace the older version with = the new
>>> version with the same name?
>>
>> In this case, I would think the "write" of the new objec= t should be
>> rejected, or if desired, we could have an overwrite option.  = This
>> could be added to the requirements if it helps to clarify.
>>
>> yep, no matter which solution is chosen, let the understanding una= nimously:D
>>> how to handle the older version which is
>>> transferring from server to client?
>>
>> I think it would be cleaner to ask the server to continue sending = an
>> object once it has been started, but ultimately this would be the<= br> >> decision of the server's implementation I think.  Maybe a= "SHOULD"
>> requirement.  This could be added if desired.
>>
>> Thank you for these questions.  It helps design the requireme= nts more
>> cleanly if there are specific scenarios in front of us :)
>> just discussion together:D and also thanks for your points to help= me
>> understanding more!
>> Rich
>>
>>>> I think that the time the data is removed from disk (or me= mory) should
>>>> be up to the implementation. A storage provider might stil= l have as
>>>> part of some agreement that deleted data will be removed w= ithin X
>>>> days/hours/minutes/whatever.
>>>
>>>    agree with you.
>>>>
>>>> If people in the WG think it is necessary, we could have a= requirement
>>>> that says the protocol should support an argument indicati= ng immediate
>>>> deletion, but it is not clear that we need this.
>>>>
>>>> Rich
>>>>
>>>> >>
>>>> >> Thanks!
>>>> >> Rich
>>>> >>
>>>> >>
>>>> >> On Mon, Dec 27, 2010 at 12:57 AM, =D6=EC=E4=EC &l= t;buptxiaozhu@gmail.com> wr= ote:
>>>> >> > Dear all,
>>>> >> >
>>>> >> > There is a slightly updated version of the d= ecade additional
>>>> >> > requirements
>>>> >> > draft.
>>>> >> >
>>>> >> >
>>>> >> > https://datatr= acker.ietf.org/doc/draft-zhu-decade-additional-requirements/
>>>> >> >
>>>> >> > Jin Peng, Yunfei Zhang and me are expecting = to have a discussion
>>>> >> > with
>>>> >> > all of
>>>> >> > you.
>>>> >> >
>>>> >> > Any comments are appreciated!
>>>> >> >
>>>> >> > A new version of I-D,
>>>> >> > draft-zhu-decade-additional-requirements-00.= txt
>>>> >> > has been successfully submitted by Xiao Zhu = and posted to the IETF
>>>> >> > repository.
>>>> >> >
>>>> >> > Filename:      draft-zhu-deca= de-additional-requirements
>>>> >> > Revision:      00
>>>> >> > Title:           &n= bsp;     Additional protocol requirements on DECADE
>>>> >> > Creation_date:         2= 010-12-27
>>>> >> > WG ID:           &n= bsp;     Independent Submission
>>>> >> > Number_of_pages: 10
>>>> >> >
>>>> >> > Abstract:
>>>> >> > The DECoupled Application Data Enroute(DECAD= E)working group is
>>>> >> > specifying standardized interfaces for acces= sing in-network storage
>>>> >> > from applications to store, retrieve and man= age data. The main
>>>> >> > object
>>>> >> > is to provide a framework that is useful to = the applications,
>>>> >> > including P2P applications and other data-or= iented applications,
>>>> >> > possibly related applications that can benef= it from accessing in-
>>>> >> > network storage. This memo focuses on some r= equirements such as
>>>> >> > request redirecting and so on which are on t= he central of mobility,
>>>> >> > wireless network environment and CDN applica= tion. We present these
>>>> >> > in
>>>> >> > this memo as additional requirements that sh= ould be considered for
>>>> >> > the DECADE architecture and protocol specifi= cations.
>>>> >> >
>>>> >> >
>>>> >> >
>>>> >> > The IETF Secretariat.
>>>> >> >
>>>> >> > --
>>>> >> > Best wishes,
>>>> >> >
>>>> >> > Beijing University of Posts & Telecommun= ications (BUPT)
>>>> >> > Zhu Xiao  ( =D6=EC=E4=EC )
>>>> >> > E-mail: buptxiaozhu@gmail.com
>>>> >> > mobile:+86 134-8881-9004
>>>> >> >
>>>> >> > ____________________________________________= ___
>>>> >> > decade mailing list
>>>> >> > decade@ie= tf.org
>>>> >> > https://www.ietf.org/mailman/listinfo/decade=
>>>> >> >
>>>> >> >
>>>> >
>>>> >
>>>> >
>>>> > --
>>>> > Best wishes,
>>>> >
>>>> > Beijing University of Posts & Telecommunications = (BUPT)
>>>> > Zhu Xiao  ( =D6=EC=E4=EC )
>>>> > E-mail: bupt= xiaozhu@gmail.com
>>>> > mobile:+86 134-8881-9004
>>>
>>>
>>>
>>> --
>>> Best wishes,
>>>
>>> Beijing University of Posts & Telecommunications (BUPT) >>> Zhu Xiao  ( =D6=EC=E4=EC )
>>> E-mail: buptxiaozhu@g= mail.com
>>> mobile:+86 134-8881-9004
>>>
>>
>>
>> --
>> Best wishes,
>>
>> Beijing University of Posts & Telecommunications (BUPT)
>> Zhu Xiao  ( =D6=EC=E4=EC )
>> E-mail: buptxiaozhu@gmail= .com
>> mobile:+86 134-8881-9004
>



--
Best wishes= ,

Beijing University of Posts & Telecommunications (BUPT)
Zhu= Xiao  ( =D6=EC=E4=EC )
E-mail: buptxiaozhu@gmail.com
mobile:+86 134-8881-9004
--000e0cd5d010698b2604a6a8d8b0-- From buptxiaozhu@gmail.com Mon Jun 27 19:23:09 2011 Return-Path: X-Original-To: decade@ietfa.amsl.com Delivered-To: decade@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F71E11E8080 for ; Mon, 27 Jun 2011 19:23:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.652 X-Spam-Level: *** X-Spam-Status: No, score=3.652 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O4EtdDrnde76 for ; Mon, 27 Jun 2011 19:23:06 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id EA77311E8076 for ; Mon, 27 Jun 2011 19:23:02 -0700 (PDT) Received: by gxk19 with SMTP id 19so3147103gxk.31 for ; Mon, 27 Jun 2011 19:22:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Yfi20flqzz//UBwviaOHpvntKwukQ2LHXrVODp2aW4U=; b=U3xwUcVgxqY1hwcSCeWzt5s+d7P3Nj3f05ThH5JSf7x8PuiqMP/BWZwkdgVMoOSd13 IFNSofcpQPd6xtjBo3Oo8/WRgPq6DFAPOigVHG8WJvE6HcV+L6qyJO+7H5KPkacJw4Eb YqC4ngRyW9KEWE9Tq0P6TkVAX4p6YqzD5TxlI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Ps+tZSS6AdthGiNCzopGA4Hj+HGegp2EkNkIlG/KLnkmv6a9wqPh8FBrhK2b9CfFmT F0EUFcwlPHA4iqAl+x2h68rH2v6LI3sodkibCOOm7f3dcTTnHC5jXFwW/Zm6ahFnlsfa XhtYnrBSeEdeFMu9wrRlLOpDKWVGORGbsE46Q= MIME-Version: 1.0 Received: by 10.150.31.16 with SMTP id e16mr7754374ybe.422.1309227776633; Mon, 27 Jun 2011 19:22:56 -0700 (PDT) Received: by 10.151.98.20 with HTTP; Mon, 27 Jun 2011 19:22:56 -0700 (PDT) In-Reply-To: References: <1CA25301D2219F40B3AA37201F0EACD11343C0AB@PACDCEXMB05.cable.comcast.com> Date: Tue, 28 Jun 2011 10:22:56 +0800 Message-ID: From: =?GB2312?B?1uzk7A==?= To: Richard Alimi Content-Type: multipart/alternative; boundary=000e0cd359808e6af704a6bc5843 Cc: "decade@ietf.org" Subject: Re: [decade] draft-zhu-decade-additional-requirements X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2011 02:23:09 -0000 --000e0cd359808e6af704a6bc5843 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable hi, Richard and everybody The draft draft-zhu-decade-additional-requirements I submitted last year is about to expire. do you have some suggestions to update the version? and do the DECADE requirement draft has adopted some suggestions of my draft? 2011/6/27 =D6=EC=E4=EC > hi, Richard and everybody > > The draft draft-zhu-decade-additional-requirements I submitted last year = is > about to expire. do you have some suggestions to update the version? and = do > the DECADE requirement draft has adopted some suggestions of my draft? > > > 2011/3/14 Richard Alimi > >> Hi All, >> >> We've made all of these updates to the requirements document, with the >> exception of: >> >> > - If an object is deleted as it is concurrently being read, then the >> > server MAY continue to read it (lazy deletion), or it MAY discontinue >> > reading the object and signal an error to the client reading the >> > object. >> >> Upon looking at this again, it looks more like an implementation >> detail. If anything, this would result in a "non-requirement" in the >> document. However, it seems like a fairly low-level non-requirement to >> state at this time. I'd propose to leave it out for now and revisit >> this if it comes up again in the future. Thoughts? >> >> Thanks, >> Rich >> >> 2011/3/2 Richard Alimi : >> > Hi All, >> > >> > I'll offer a summary of this discussion. Let me know if I missed >> > anything, or if there are objections/other thoughts on these proposed >> > resolutions. >> > >> > Redirection: >> > - We can add a requirement mentioning that DECADE may support >> redirection. >> > >> > Data Classification: >> > - I (personally) strongly disagree with attempting to classify access >> > patterns or applications. We could add something saying that explicit >> > hints (a la www.ietf.org/proceedings/78/slides/nfsv4-0.pdf) could be >> > provided in DECADE. However, I don't think we need to do something >> > new here. In particular, if the underlying storage/data transport >> > supports hints, a DECADE client or server can use it. >> > >> > Storage Status: >> > - Update section 5.1.6 to indicate that status information should >> > include permissions of stored objects, if applicable. >> > - Update 5.1.6 to indicate that status information should include >> > other information about resource usage (the clients own resources, or >> > resources used by other clients that have been authorized to >> > read/write objects or open connections to one's storage). >> > >> > Requirements for object deletion/overwriting: >> > - DECADE MAY have an overwrite flag (note that this may or may not be >> > necessary depending on our naming, but the requirements document >> > probably is not the place to take a stand on this at the current >> > point.) >> > - If an object is deleted as it is concurrently being read, then the >> > server MAY continue to read it (lazy deletion), or it MAY discontinue >> > reading the object and signal an error to the client reading the >> > object. >> > >> > Would this be sufficient to merge in the points from >> > draft-zhu-decade-additional-requirements-00 and this ensuing >> > discussion? >> > >> > Thanks, >> > Rich >> > >> > >> > 2011/3/2 Woundy, Richard : >> >> Folks, >> >> >> >> >> >> >> >> Do we have consensus yet about how the WG could have a single DECADE >> >> requirements document going forward? I can't tell the state of our >> >> requirements consolidation from the email thread below. >> >> >> >> >> >> >> >> It would be preferable if we could resolve this fully on the WG maili= ng >> >> list, but this is important enough to allocate some time at our meeti= ng >> in >> >> Prague. >> >> >> >> >> >> >> >> -- Rich >> >> >> >> >> >> >> >> From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.org] On >> Behalf Of >> >> ?? >> >> Sent: Sunday, January 16, 2011 9:02 PM >> >> To: Richard Alimi >> >> Cc: decade@ietf.org >> >> Subject: Re: [decade] draft-zhu-decade-additional-requirements >> >> >> >> >> >> >> >> hi, Richard: >> >> >> >> >> >> >> >> thanks for your reply:D >> >> >> >> additional discussion see inline:D >> >> >> >> >> >> >> >> 2011/1/14 Richard Alimi >> >> >> >> HI Xiao, >> >> >> >> 2011/1/12 =D6=EC=E4=EC : >> >> >> >>> hi, Richard >> >>> see inline:D >> >>> >> >>> 2011/1/11 Richard Alimi >> >>>> >> >>>> Hi Xiao, >> >>>> >> >>>> On Mon, Jan 10, 2011 at 6:45 PM, =D6=EC=E4=EC wrote: >> >>>> > >> >>>> > hi, Richard, sorry for so late response because of be busy with >> other >> >>>> > projects. >> >>>> > some discussion see inline:D marked by red. >> >>>> > >> >>>> > On Tue, Jan 4, 2011 at 4:06 AM, Richard Alimi >> >>>> > wrote: >> >>>> >> >> >>>> >> Hi Xiao, >> >>>> >> >> >>>> >> Thank you for the draft. Some comments on the requirements: >> >>>> >> >> >>>> >> Request Redirects: >> >>>> >> >> >>>> >> This would provide some additional freedom for the storage >> provider. >> >>>> >> I think it is reasonable since it doesn't necessitate additional >> >>>> >> complexity for the DECADE server, but allows it if desired. >> However, >> >>>> >> note that it may complicate some of the other components of the >> >>>> >> design. In particular, if there is a per-user quota for storage, >> is >> >>>> >> the user made aware of the quota at each in-network storage (if >> there >> >>>> >> is no shared storage between them)? Resource sharing policies m= ay >> be >> >>>> >> impacted (e.g., if a bandwidth sharing weight of 1 may mean >> something >> >>>> >> different at DECADE server A than it does at DECADE server B). = At >> >>>> >> this point it may be best to just note these so they are >> documented, >> >>>> >> but since the specification of the resource sharing policies are >> still >> >>>> >> being contemplated for the basic case of a single server it may = be >> >>>> >> premature to even try and solve them for the case supporting >> >>>> >> redirection. >> >>>> >> >> >>>> > actually, you mean two points, right? >> >>>> > 1. whether or not to be ware of the content at each in-network >> storage >> >>>> > and of course resource sharing policies can be impact in the >> request >> >>>> > redirection. your suggestion"just to note these so they are >> documented" >> >>>> > will >> >>>> > be ok, or DECADE server list with some parameters will be return >> for >> >>>> > user to >> >>>> > select the appropriate DECADE server, which can avoid the differe= nt >> >>>> > weighted >> >>>> > of the same parameter in server decision. but the parameter used = in >> >>>> > select >> >>>> > the best DECADE server will be known for DECADE servers, in which >> other >> >>>> > complexities will be added. anyway, all the solution are the >> >>>> > implementation >> >>>> > issue, which, i believe, does not impact the necessity of the >> >>>> > requirement. >> >>>> >> >>>> In general, I'd agree that the decision about where to redirect wou= ld >> >>>> be an implementation issue. >> >>>> >> >>>> > >> >>>> > 2. you mean "the resource sharing policies are still being >> considered >> >>>> > in >> >>>> > a single server", so it may be premature to support redirection. >> the >> >>>> > architecture and protocol will be badly impacted if the >> requirements >> >>>> > change. >> >>>> > so the designing can be taken step by step, but the requirement= s >> >>>> > should be >> >>>> > overall considered. >> >>>> >> >>>> I said that it is probably premature to consider how resource shari= ng >> >>>> policies works across servers (or even if we need to say anything >> >>>> about it) since we have not determined how to specify them (or >> rather, >> >>>> how little we need to specify in protocol) for a single server. I d= id >> >>>> not mean to imply that redirection could not be introduced as a >> >>>> requirement. >> >>>> >> >>> >> >>>> >> >>>> > >> >>>> > >> >>>> >> >> >>>> >> Multi-connection: >> >>>> >> >> >>>> >> I'm not quite clear on the intention of the requirement. My >> >>>> >> understanding is that you wish the client to be able to have >> multiple >> >>>> >> connections open spanning multiple DECADE servers. Is that >> correct? >> >>>> >> >> >>>> >> If so, do we need this stated as a requirement or the protocol? = Or >> is >> >>>> >> this a policy that would be allowed/disallowed by the storage >> >>>> >> provider? >> >>>> >> >> >>>> > yep, your understanding is right, the scenarios were just describ= ed >> in >> >>>> > draft as "soft handover in wireless environment and delete >> operation in >> >>>> > multi-servers". under these consideration, the authentication and >> >>>> > authorization need to be taken each time when setup connection wi= th >> a >> >>>> > new >> >>>> > DECADE server, or just be taken only once during the service? >> >>>> >> >>>> The DECADE server should need to do some sort of check on each new >> >>>> connection, regardless of whether the user has or previously had a >> >>>> connection open to a different DECADE server, right? Note that the >> >>>> requirements don't indicate how authentication or authorization is >> >>>> done, and allow a server to make optimizations if it is enforcing t= he >> >>>> same permissions. >> >>>> >> >>>> Can you indicate where the existing authorization-related >> requirements >> >>>> (in particular, 4.1.6.3 of draft-ietf-decade-reqs-00) do not suffic= e >> >>>> for the use case you are thinking of? >> >> >> >>> as considering the service continuity, the next serving DECADE serv= er >> >>> should know the progress of the service, how does they know? >> >> >> >> By progress of the service, do you mean current user state (e.g., >> >> quota, recent resource usage history, permissions, etc)? >> >> >> >> yes, and include data delivery proceeding. >> >>> so if the >> >>> service proceeding information should be known by the next serving >> server, >> >>> or different servers need to coordinate and schedule each other to >> fulfill >> >>> the user request, i believe the the 4.1.6.3 of the >> >>> draft-ietf-decade-req-00 >> >>> cannot satisfy the req. what do you think about? >> >> >> >> Note that the protocol that is covered here is the client-server >> >> protocol. Some of the same protocol may be useful between DECADE >> >> servers (especially in different administrative domains) for storing >> >> and retrieving data, but that does not mean that there can't be >> >> additional protocol(s) (not specified here) that are used between >> >> DECADE servers as well. For example, if DECADE servers within an >> >> administrative domain can certainly have their own mechanism to share >> >> such information. If such capabilities were included in the DECADE >> >> protocol (e.g., a need to do this between administrative domains), >> >> that sounds like lots more complexity that we need at this point. >> >> but the access between in-network storage also is included in IAP >> described >> >> in problem statement. i mean why not put this kind of function in >> DECADE >> >> since the IAP is defined just like that? >> >> That said, it sounds to me like what is described in 4.1.6.3 would be >> >> sufficient (from the perspective of the client-server protocol, >> >> anyways) to implement what you're describing. If not, what >> >> specifically is missing and what use-case does it not meet? >> >> >> >> so you mean the information you mentioned above, just like current us= er >> >> state (e.g., >> >> quota, recent resource usage history, permissions, etc) was already >> included >> >> in DECADE requirement? what about the data delivery proceeding >> information? >> >> can you specify the chapter for me ? thanks? >> >>>> > >> >>>> > >> >>>> >> >> >>>> >> Data Distribution: >> >>>> >> >> >>>> >> I'm also confused about the intent of this requirement. This >> >>>> >> statement has me somewhat worried: "The distribution is >> transparent to >> >>>> >> the users as they interact with the in-network storage as a sing= le >> >>>> >> logical system." Does this mean that you are proposing for DECAD= E >> >>>> >> servers to assume the responsibility for deciding how data is to >> be >> >>>> >> distributed throughout the network, including the path of the >> data, >> >>>> >> which servers act as intermediate caches, content expiration >> policies, >> >>>> >> etc? If this is true, I think it is missing one of the major >> points >> >>>> >> of DECADE. In particular, these decisions are >> application-dependent >> >>>> >> and are not implemented within DECADE. Instead, DECADE provides >> the >> >>>> >> basic capabilities and the functionality described above are >> >>>> >> implemented by the applications using DECADE. >> >>>> >> >> >>>> >> Or, am I misinterpreting the intent of the requirement? >> >>>> >> >> >>>> > you mean DECADE provides the basic capabilities, so can you give >> some >> >>>> > specify explanations on DECADE capabilities in supporting data >> >>>> > distribution? >> >>>> >> >> >>>> >> >>>> The problem statement gives a couple of scenarios. The "Integration >> >>>> Examples" presentation from IETF 79 also has more details of an >> >>>> on-going effort at Yale. >> >> >> >>> okay, thx for your information, i will lookup and refer, actually, t= he >> >>> content publisher described in problem statement remind me of the >> >>> protocol requirements which i did not find in >> draft-ietf-decade-reqs-00 to >> >>> support content publish. or i miss some points? >> >> >> >> Which requirements do you think are missing? >> >> >> >>>> >> Service Assurance: >> >>>> >> >> >>>> >> It seems problematic to include "assurance" in a DECADE. >> Shouldn't >> >>>> >> these instead be part of SLAs with a storage provider? Why shou= ld >> >>>> >> they be DECADE's responsibility? >> >>>> >> >> >>>> >> Regarding "resource reservation", are you referring to an actual >> >>>> >> reservation (which might be problematic -- see above) or do you >> mean >> >>>> >> that the resource share should able to be specified at the time >> the >> >>>> >> connection opens and be assumed to be the same for the duration = of >> the >> >>>> >> connection? >> >>>> >> >> >>>> >> Regarding Dynamic Feedback, is this orthogonal to the storage >> >>>> >> protocol? It seems like what you want here is a generic "status= " >> >>>> >> service saying how loaded a server is? >> >>>> >> >> >>>> > thats right, actually, the flow control mechanism was under >> discussion >> >>>> > in writing the draft at first. what about your opinion in this >> >>>> > requirements? >> >>>> > >> >>>> >> >>>> I'm not sure what the typical way of providing such "load status" >> >>>> information for IETF protocols, but my inclination is that it shoul= d >> >>>> not be in the DECADE protocol itself. Maybe someone else with a >> >>>> longer history in IETF could jump in here :) >> >>> so can i understand that "load status" is kind of necessity >> information >> >>> for DECADE Server, but where and who collects the information are >> >>> remain discussion? >> >> >> >> The storage provider is free to collect the information wherever and >> >> however they wish. The DECADE server implementation could additional >> >> export whatever status information it wishes. I don't think the DECAD= E >> >> protocol needs to be concerned with that. >> >> >> >> Note that certain error conditions (e.g., overload, insufficient >> >> resources) may be signaled by a DECADE server (there are already have >> >> requirements for those). If you are referring to status for a user's >> >> resources, there is already a requirement for that too. >> >> >> >> I'm just not convinced that the DECADE protocol needs to export its >> >> current load status to clients. >> >> >> >> actually i am not sure which elements in DECADE needs the load >> >> status,(DECADE client or network storage if the network storage needs >> to >> >> redirect the request or both?). >> >> >> >> >> >> >> >> And the requirement draft currently seems describe the overload >> condition as >> >> the event triggering. do you think if it is necessary to periodically >> >> reporting of the DECADE network status to client for its network >> storage >> >> selection? >> >> >> >> >> >> >> >> and the requirement draft just describe DECADE which is busy to serve >> other >> >> requests must be able to reject requests, not consider how to handle >> the >> >> user request after being rejected? >> >> >> >>>> >> >> >>>> >> Data classification: >> >>>> >> >> >>>> >> Would it be better to instead have the client specify properties >> of >> >>>> >> the content instead of place it into ? See >> >>>> >> www.ietf.org/proceedings/78/slides/nfsv4-0.pdf for an example of >> this >> >>>> >> approach for NFS. >> >>>> >> >> >>>> >> I think a problem with classifying applications is that it assum= es >> >>>> >> that applications fit one of the supplied classifications. What = if >> it >> >>>> >> may fit multiple classifications? or none? Another problem is i= t >> >>>> >> assumes that servers assume based on indirect and assumed >> information >> >>>> >> that they know what to do with a particular piece of content. Wh= y >> not >> >>>> >> have an application specify its desires directly? >> >>>> >> >> >>>> > >> >>>> > >> >>>> >> >> >>>> >> Small Objects: >> >>>> >> >> >>>> >> What is the new requirement here? Why is the existing requireme= nt >> in >> >>>> >> draft-ietf-decade-reqs-00 insufficient? >> >>>> >> >> >>>> >> This also has me a bit worried: >> >>>> >> "And the in-network storage has the limited storage capacity, wi= th >> the >> >>>> >> arrival of user requests and data distribution requirements, the >> data >> >>>> >> stored in the in-network storage will be replaced if the storage >> >>>> >> reaches the limit and data arrivals continually." >> >>>> >> >> >>>> >> How does the server know what the proper replacement strategy is >> for >> >>>> >> an application? I think DECADE's philosophy is that applications >> >>>> >> should decide this. A simple way to do this is explicit deletion >> by an >> >>>> >> application, but perhaps a more efficient (yet more complex) >> solution >> >>>> >> is for an application to specify the replacement policy to the >> server. >> >>>> >> >> >>>> > actually, the key in "the data classification and small objects " >> is >> >>>> > whether does it or not in P2P application? i did not find data >> >>>> > classification was adopted in P2P application so far, let alone >> DECADE >> >>>> > need >> >>>> > to classify the data used in all kinds of application. >> >>>> > >> >>>> >> >>>> So, do you agree that it is problematic to try and classify each ty= pe >> >>>> of application and try to specify the typical workload for each >> class? >> >>>> >> >>>> My point was that I don't think its necessary to do the >> classification >> >>>> at all. It is more extensible (and directly useful) for a server t= o >> >>>> just give it direct hints about what would be preferable. >> >>> >> >>> yep, i believe it may be a little difficult, but worthy doing. >> specially >> >>> for improving the resource utilization within a single server and >> reducing >> >>> the response time for client. what about others opinion? >> >> >> >> Can you justify why giving classifications (e.g., "I'm a live >> >> streaming application") would be better than giving specific hints >> >> (e.g., "please don't bother persistent these objects to disk")? >> >> >> >> i mean data in different kind of operation mode and attribute should >> have >> >> different user patterns and storage rules, which may be help to impro= ve >> the >> >> resource utilization and reduce the response time for request, what a= re >> you >> >> understanding? >> >>> >> >> >>>> >> Removal of Expired Records: >> >>>> >> >> >>>> >> "However, the two scenarios did not mention how to handle the ol= d >> >>>> >> resource if the user distributes the new resource which is an >> updated >> >>>> >> copy of the old resource." >> >>>> >> >> >>>> >> Why does this need to be handled in the requirements? Are you >> trying >> >>>> >> to draw the distinction between immediate deletion of content an= d >> lazy >> >>>> >> deletion? >> >>>> >> >> >>>> > i mean the meaning of delete operation and how to handle the >> expired >> >>>> > records need to be clarify in requirements. >> >>>> >> >>>> My inclination is that "deleted" means that other requests the obje= ct >> >>>> of the same name should result an error, until another object with >> the >> >>>> same name is stored. >> >>> >> >>> okay, under the scenario "client uploads the new version, and did no= t >> >>> specify how to handle the old version", did DECADE server delete the >> older >> >>> version (or just label it unavailable, anyway, it is implementation >> issue >> >>> ) >> >>> or not ? in another word, just replace the older version with the ne= w >> >>> version with the same name? >> >> >> >> In this case, I would think the "write" of the new object should be >> >> rejected, or if desired, we could have an overwrite option. This >> >> could be added to the requirements if it helps to clarify. >> >> >> >> yep, no matter which solution is chosen, let the understanding >> unanimously:D >> >>> how to handle the older version which is >> >>> transferring from server to client? >> >> >> >> I think it would be cleaner to ask the server to continue sending an >> >> object once it has been started, but ultimately this would be the >> >> decision of the server's implementation I think. Maybe a "SHOULD" >> >> requirement. This could be added if desired. >> >> >> >> Thank you for these questions. It helps design the requirements more >> >> cleanly if there are specific scenarios in front of us :) >> >> just discussion together:D and also thanks for your points to help me >> >> understanding more! >> >> Rich >> >> >> >>>> I think that the time the data is removed from disk (or memory) >> should >> >>>> be up to the implementation. A storage provider might still have as >> >>>> part of some agreement that deleted data will be removed within X >> >>>> days/hours/minutes/whatever. >> >>> >> >>> agree with you. >> >>>> >> >>>> If people in the WG think it is necessary, we could have a >> requirement >> >>>> that says the protocol should support an argument indicating >> immediate >> >>>> deletion, but it is not clear that we need this. >> >>>> >> >>>> Rich >> >>>> >> >>>> >> >> >>>> >> Thanks! >> >>>> >> Rich >> >>>> >> >> >>>> >> >> >>>> >> On Mon, Dec 27, 2010 at 12:57 AM, =D6=EC=E4=EC >> wrote: >> >>>> >> > Dear all, >> >>>> >> > >> >>>> >> > There is a slightly updated version of the decade additional >> >>>> >> > requirements >> >>>> >> > draft. >> >>>> >> > >> >>>> >> > >> >>>> >> > >> https://datatracker.ietf.org/doc/draft-zhu-decade-additional-requirement= s/ >> >>>> >> > >> >>>> >> > Jin Peng, Yunfei Zhang and me are expecting to have a discussi= on >> >>>> >> > with >> >>>> >> > all of >> >>>> >> > you. >> >>>> >> > >> >>>> >> > Any comments are appreciated! >> >>>> >> > >> >>>> >> > A new version of I-D, >> >>>> >> > draft-zhu-decade-additional-requirements-00.txt >> >>>> >> > has been successfully submitted by Xiao Zhu and posted to the >> IETF >> >>>> >> > repository. >> >>>> >> > >> >>>> >> > Filename: draft-zhu-decade-additional-requirements >> >>>> >> > Revision: 00 >> >>>> >> > Title: Additional protocol requirements on >> DECADE >> >>>> >> > Creation_date: 2010-12-27 >> >>>> >> > WG ID: Independent Submission >> >>>> >> > Number_of_pages: 10 >> >>>> >> > >> >>>> >> > Abstract: >> >>>> >> > The DECoupled Application Data Enroute(DECADE)working group is >> >>>> >> > specifying standardized interfaces for accessing in-network >> storage >> >>>> >> > from applications to store, retrieve and manage data. The main >> >>>> >> > object >> >>>> >> > is to provide a framework that is useful to the applications, >> >>>> >> > including P2P applications and other data-oriented application= s, >> >>>> >> > possibly related applications that can benefit from accessing >> in- >> >>>> >> > network storage. This memo focuses on some requirements such a= s >> >>>> >> > request redirecting and so on which are on the central of >> mobility, >> >>>> >> > wireless network environment and CDN application. We present >> these >> >>>> >> > in >> >>>> >> > this memo as additional requirements that should be considered >> for >> >>>> >> > the DECADE architecture and protocol specifications. >> >>>> >> > >> >>>> >> > >> >>>> >> > >> >>>> >> > The IETF Secretariat. >> >>>> >> > >> >>>> >> > -- >> >>>> >> > Best wishes, >> >>>> >> > >> >>>> >> > Beijing University of Posts & Telecommunications (BUPT) >> >>>> >> > Zhu Xiao ( =D6=EC=E4=EC ) >> >>>> >> > E-mail: buptxiaozhu@gmail.com >> >>>> >> > mobile:+86 134-8881-9004 >> >>>> >> > >> >>>> >> > _______________________________________________ >> >>>> >> > decade mailing list >> >>>> >> > decade@ietf.org >> >>>> >> > https://www.ietf.org/mailman/listinfo/decade >> >>>> >> > >> >>>> >> > >> >>>> > >> >>>> > >> >>>> > >> >>>> > -- >> >>>> > Best wishes, >> >>>> > >> >>>> > Beijing University of Posts & Telecommunications (BUPT) >> >>>> > Zhu Xiao ( =D6=EC=E4=EC ) >> >>>> > E-mail: buptxiaozhu@gmail.com >> >>>> > mobile:+86 134-8881-9004 >> >>> >> >>> >> >>> >> >>> -- >> >>> Best wishes, >> >>> >> >>> Beijing University of Posts & Telecommunications (BUPT) >> >>> Zhu Xiao ( =D6=EC=E4=EC ) >> >>> E-mail: buptxiaozhu@gmail.com >> >>> mobile:+86 134-8881-9004 >> >>> >> >> >> >> >> >> -- >> >> Best wishes, >> >> >> >> Beijing University of Posts & Telecommunications (BUPT) >> >> Zhu Xiao ( =D6=EC=E4=EC ) >> >> E-mail: buptxiaozhu@gmail.com >> >> mobile:+86 134-8881-9004 >> > >> > > > > -- > Best wishes, > > Beijing University of Posts & Telecommunications (BUPT) > Zhu Xiao ( =D6=EC=E4=EC ) > E-mail: buptxiaozhu@gmail.com > mobile:+86 134-8881-9004 > --=20 Best wishes, Beijing University of Posts & Telecommunications (BUPT) Zhu Xiao ( =D6=EC=E4=EC ) E-mail: buptxiaozhu@gmail.com mobile:+86 134-8881-9004 --000e0cd359808e6af704a6bc5843 Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable hi, Richard and everybody

The draft draft-zhu-decad= e-additional-requirements I submitted last year is about to expire. do you = have some suggestions to update the version? and do the DECADE requirement = draft has adopted some suggestions of my draft?

2011/6/27 =D6=EC=E4=EC <= ;buptxiaozhu@gmail.com>
hi, Richard and everybody

The draft draft-zhu-decad= e-additional-requirements I submitted last year is about to expire. do you = have some suggestions to update the version? and do the DECADE requirement = draft has adopted some suggestions of my draft?


2011/3/14 Richard Alimi &l= t;rich@velvetsea.ne= t>
Hi All,

We've made all of these updates to the requirements document, with the<= br> exception of:

> - If an object is deleted as it is concurrently being read, then the > server MAY continue to read it (lazy deletion), or it MAY discontinue<= br> > reading the object and signal an error to the client reading the
> object.

Upon looking at this again, it looks more like an implementation
detail. If anything, this would result in a "non-requirement" in = the
document. However, it seems like a fairly low-level non-requirement to
state at this time. I'd propose to leave it out for now and revisit
this if it comes up again in the future.  Thoughts?

Thanks,
Rich

2011/3/2 Richard Alimi <rich@velvetsea.net>:
> Hi All,
>
> I'll offer a summary of this discussion. Let me know if I missed > anything, or if there are objections/other thoughts on these proposed<= br> > resolutions.
>
> Redirection:
> - We can add a requirement mentioning that DECADE may support redirect= ion.
>
> Data Classification:
> - I (personally) strongly disagree with attempting to classify access<= br> > patterns or applications. We could add something saying that explicit<= br> > hints (a la www.ietf.org/proceedings/78/slides/nfsv4-0.pdf) could be
> provided in DECADE.  However, I don't think we need to do som= ething
> new here. In particular, if the underlying storage/data transport
> supports hints, a DECADE client or server can use it.
>
> Storage Status:
> - Update section 5.1.6 to indicate that status information should
> include permissions of stored objects, if applicable.
> - Update 5.1.6 to indicate that status information should include
> other information about resource usage (the clients own resources, or<= br> > resources used by other clients that have been authorized to
> read/write objects or open connections to one's storage).
>
> Requirements for object deletion/overwriting:
> - DECADE MAY have an overwrite flag (note that this may or may not be<= br> > necessary depending on our naming, but the requirements document
> probably is not the place to take a stand on this at the current
> point.)
> - If an object is deleted as it is concurrently being read, then the > server MAY continue to read it (lazy deletion), or it MAY discontinue<= br> > reading the object and signal an error to the client reading the
> object.
>
> Would this be sufficient to merge in the points from
> draft-zhu-decade-additional-requirements-00 and this ensuing
> discussion?
>
> Thanks,
> Rich
>
>
> 2011/3/2 Woundy, Richard <Richard_Woundy@cable.comcast.com>:
>> Folks,
>>
>>
>>
>> Do we have consensus yet about how the WG could have a single DECA= DE
>> requirements document going forward? I can't tell the state of= our
>> requirements consolidation from the email thread below.
>>
>>
>>
>> It would be preferable if we could resolve this fully on the WG ma= iling
>> list, but this is important enough to allocate some time at our me= eting in
>> Prague.
>>
>>
>>
>> -- Rich
>>
>>
>>
>> From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.org] On Behalf Of
>> ??
>> Sent: Sunday, January 16, 2011 9:02 PM
>> To: Richard Alimi
>> Cc: decade@ie= tf.org
>> Subject: Re: [decade] draft-zhu-decade-additional-requirements
>>
>>
>>
>> hi, Richard:
>>
>>
>>
>> thanks for your reply:D
>>
>> additional discussion see inline:D
>>
>>
>>
>> 2011/1/14 Richard Alimi <rich@velvetsea.net>
>>
>> HI Xiao,
>>
>> 2011/1/12 =D6=EC=E4=EC <buptxiaozhu@gmail.com>:
>>
>>> hi, Richard
>>> see inline:D
>>>
>>> 2011/1/11 Richard Alimi <rich@velvetsea.net>
>>>>
>>>> Hi Xiao,
>>>>
>>>> On Mon, Jan 10, 2011 at 6:45 PM, =D6=EC=E4=EC <buptxiaozhu@gmail.com> wrote:
>>>> >
>>>> > hi, Richard, sorry for so late response because of be= busy with other
>>>> > projects.
>>>> > some discussion see inline:D marked by red.
>>>> >
>>>> > On Tue, Jan 4, 2011 at 4:06 AM, Richard Alimi <rich@velvetsea.net= >
>>>> > wrote:
>>>> >>
>>>> >> Hi Xiao,
>>>> >>
>>>> >> Thank you for the draft.  Some comments on t= he requirements:
>>>> >>
>>>> >> Request Redirects:
>>>> >>
>>>> >> This would provide some additional freedom for th= e storage provider.
>>>> >> I think it is reasonable since it doesn't nec= essitate additional
>>>> >> complexity for the DECADE server, but allows it i= f desired. However,
>>>> >> note that it may complicate some of the other com= ponents of the
>>>> >> design. In particular, if there is a per-user quo= ta for storage, is
>>>> >> the user made aware of the quota at each in-netwo= rk storage (if there
>>>> >> is no shared storage between them)?  Resourc= e sharing policies may be
>>>> >> impacted (e.g., if a bandwidth sharing weight of = 1 may mean something
>>>> >> different at DECADE server A than it does at DECA= DE server B).  At
>>>> >> this point it may be best to just note these so t= hey are documented,
>>>> >> but since the specification of the resource shari= ng policies are still
>>>> >> being contemplated for the basic case of a single= server it may be
>>>> >> premature to even try and solve them for the case= supporting
>>>> >> redirection.
>>>> >>
>>>> > actually, you mean two points, right?
>>>> > 1. whether or not to be ware of the content at each i= n-network storage
>>>> > and of course resource sharing policies can be impact= in the request
>>>> > redirection. your suggestion"just to note these = so they are documented"
>>>> > will
>>>> > be ok, or DECADE server list with some parameters wil= l be return for
>>>> > user to
>>>> > select the appropriate DECADE server, which can avoid= the different
>>>> > weighted
>>>> > of the same parameter in server decision. but the par= ameter used in
>>>> > select
>>>> > the best DECADE server will be known for DECADE serve= rs, in which other
>>>> > complexities will be added. anyway, all the solution = are the
>>>> > implementation
>>>> > issue, which, i believe, does not impact the necessit= y of the
>>>> > requirement.
>>>>
>>>> In general, I'd agree that the decision about where to= redirect would
>>>> be an implementation issue.
>>>>
>>>> >
>>>> > 2. you mean "the resource sharing policies are s= till being considered
>>>> > in
>>>> > a single server", so it may be premature to supp= ort redirection.  the
>>>> > architecture and protocol will be badly impacted if t= he requirements
>>>> > change.
>>>> > so the designing can be  taken  step by ste= p, but the requirements
>>>> > should be
>>>> > overall considered.
>>>>
>>>> I said that it is probably premature to consider how resou= rce sharing
>>>> policies works across servers (or even if we need to say a= nything
>>>> about it) since we have not determined how to specify them= (or rather,
>>>> how little we need to specify in protocol) for a single se= rver. I did
>>>> not mean to imply that redirection could not be introduced= as a
>>>> requirement.
>>>>
>>>
>>>>
>>>> >
>>>> >
>>>> >>
>>>> >> Multi-connection:
>>>> >>
>>>> >> I'm not quite clear on the intention of the r= equirement.  My
>>>> >> understanding is that you wish the client to be a= ble to have multiple
>>>> >> connections open spanning multiple DECADE servers= . Is that correct?
>>>> >>
>>>> >> If so, do we need this stated as a requirement or= the protocol? Or is
>>>> >> this a policy that would be allowed/disallowed by= the storage
>>>> >> provider?
>>>> >>
>>>> > yep, your understanding is right, the scenarios were = just described in
>>>> > draft as "soft handover in wireless environment = and delete operation in
>>>> > multi-servers". under these consideration, the a= uthentication and
>>>> > authorization need to be taken each time when setup c= onnection with a
>>>> > new
>>>> > DECADE server, or just be taken only once during &nbs= p;the service?
>>>>
>>>> The DECADE server should need to do some sort of check on = each new
>>>> connection, regardless of whether the user has or previous= ly had a
>>>> connection open to a different DECADE server, right?  = ;Note that the
>>>> requirements don't indicate how authentication or auth= orization is
>>>> done, and allow a server to make optimizations if it is en= forcing the
>>>> same permissions.
>>>>
>>>> Can you indicate where the existing authorization-related = requirements
>>>> (in particular, 4.1.6.3 of draft-ietf-decade-reqs-00) do n= ot suffice
>>>> for the use case you are thinking of?
>>
>>> as considering the service continuity, the next serving  = DECADE server
>>> should know the progress of the service, how does they know? >>
>> By progress of the service, do you mean current user state (e.g.,<= br> >> quota, recent resource usage history, permissions, etc)?
>>
>> yes, and include data delivery proceeding.
>>> so if the
>>> service proceeding information should be known by the next ser= ving server,
>>> or different servers need to coordinate and schedule each othe= r to fulfill
>>> the user request, i believe the the 4.1.6.3 of the
>>> draft-ietf-decade-req-00
>>> cannot satisfy the req. what do you think about?
>>
>> Note that the protocol that is covered here is the client-server >> protocol. Some of the same protocol may be useful between DECADE >> servers (especially in different administrative domains) for stori= ng
>> and retrieving data, but that does not mean that there can't b= e
>> additional protocol(s) (not specified here) that are used between<= br> >> DECADE servers as well.  For example, if DECADE servers withi= n an
>> administrative domain can certainly have their own mechanism to sh= are
>> such information.  If such capabilities were included in the = DECADE
>> protocol (e.g., a need to do this between administrative domains),=
>> that sounds like lots more complexity that we need at this point.<= br> >> but the access between in-network storage also is included in IAP = described
>> in problem statement.  i mean why not put this kind of functi= on in DECADE
>> since the IAP is defined just like that?
>> That said, it sounds to me like what is described in 4.= 1.6.3 would be
>> sufficient (from the perspective of the client-server protocol, >> anyways) to implement what you're describing. If not, what
>> specifically is missing and what use-case does it not meet?
>>
>> so you mean the information you mentioned above, just like current= user
>> state (e.g.,
>> quota, recent resource usage history, permissions, etc) was alread= y included
>> in DECADE requirement? what about the data delivery proceeding inf= ormation?
>> can you specify the chapter for me ? thanks?
>>>> >
>>>> >
>>>> >>
>>>> >> Data Distribution:
>>>> >>
>>>> >> I'm also confused about the intent of this re= quirement.  This
>>>> >> statement has me somewhat worried: "The dist= ribution is transparent to
>>>> >> the users as they interact with the in-network st= orage as a single
>>>> >> logical system." Does this mean that you are= proposing for DECADE
>>>> >> servers to assume the responsibility for deciding= how data is to be
>>>> >> distributed throughout the network, including the= path of the data,
>>>> >> which servers act as intermediate caches, content= expiration policies,
>>>> >> etc?  If this is true, I think it is missing= one of the major points
>>>> >> of DECADE. In particular, these decisions are app= lication-dependent
>>>> >> and are not implemented within DECADE. Instead, D= ECADE provides the
>>>> >> basic capabilities and the functionality describe= d above are
>>>> >> implemented by the applications using DECADE.
>>>> >>
>>>> >> Or, am I misinterpreting the intent of the requir= ement?
>>>> >>
>>>> > you mean DECADE provides the basic capabilities, so c= an you give some
>>>> > specify explanations on DECADE capabilities in suppor= ting data
>>>> > distribution?
>>>> >>
>>>>
>>>> The problem statement gives a couple of scenarios. The &qu= ot;Integration
>>>> Examples" presentation from IETF 79 also has more det= ails of an
>>>> on-going effort at Yale.
>>
>>> okay, thx for your information, i will lookup and refer, actua= lly, the
>>> content publisher described in problem statement remind me of =  the
>>> protocol requirements which i did not find in draft-ietf-decad= e-reqs-00 to
>>> support content publish. or i miss some points?
>>
>> Which requirements do you think are missing?
>>
>>>> >> Service Assurance:
>>>> >>
>>>> >> It seems problematic to include "assurance&q= uot; in a DECADE.  Shouldn't
>>>> >> these instead be part of SLAs with a storage prov= ider?  Why should
>>>> >> they be DECADE's responsibility?
>>>> >>
>>>> >> Regarding "resource reservation", are y= ou referring to an actual
>>>> >> reservation (which might be problematic -- see ab= ove) or do you mean
>>>> >> that the resource share should able to be specifi= ed at the time the
>>>> >> connection opens and be assumed to be the same fo= r the duration of the
>>>> >> connection?
>>>> >>
>>>> >> Regarding Dynamic Feedback, is this orthogonal to= the storage
>>>> >> protocol?  It seems like what you want here = is a generic "status"
>>>> >> service saying how loaded a server is?
>>>> >>
>>>> > thats right, actually, the flow control mechanism was= under discussion
>>>> > in writing the draft at first. what about your opinio= n in this
>>>> > requirements?
>>>> >
>>>>
>>>> I'm not sure what the typical way of providing such &q= uot;load status"
>>>> information for IETF protocols, but my inclination is that= it should
>>>> not be in the DECADE protocol itself.  Maybe someone = else with a
>>>> longer history in IETF could jump in here :)
>>> so can i understand that "load status" is kind of ne= cessity  information
>>> for DECADE Server, but where and who collects the information = are
>>> remain discussion?
>>
>> The storage provider is free to collect the information wherever a= nd
>> however they wish.  The DECADE server implementation could ad= ditional
>> export whatever status information it wishes. I don't think th= e DECADE
>> protocol needs to be concerned with that.
>>
>> Note that certain error conditions (e.g., overload, insufficient >> resources) may be signaled by a DECADE server (there are already h= ave
>> requirements for those).  If you are referring to status for = a user's
>> resources, there is already a requirement for that too.
>>
>> I'm just not convinced that the DECADE protocol needs to expor= t its
>> current load status to clients.
>>
>> actually i am not sure which elements in DECADE needs the load
>> status,(DECADE client or network storage if the network storage ne= eds to
>> redirect the request or both?).
>>
>>
>>
>> And the requirement draft currently seems describe the overload co= ndition as
>> the event triggering. do you think if it is necessary to periodica= lly
>> reporting of the DECADE network status to client for its network s= torage
>> selection?
>>
>>
>>
>> and the requirement draft just describe DECADE wh= ich is busy to serve other
>> requests must be able to reject requests, not consider how to hand= le the
>> user request after being rejected?
>>
>>>> >>
>>>> >> Data classification: >>>> >>
>>>> >> Would it be better to instead have the client spe= cify properties of
>>>> >> the content instead of place it into ? See
>>>> >> www.ietf.org/proceedings/78/slides/nfsv4= -0.pdf for an example of this
>>>> >> approach for NFS.
>>>> >>
>>>> >> I think a problem with classifying applications i= s that it assumes
>>>> >> that applications fit one of the supplied classif= ications. What if it
>>>> >> may fit multiple classifications? or none?  = Another problem is it
>>>> >> assumes that servers assume based on indirect and= assumed information
>>>> >> that they know what to do with a particular piece= of content. Why not
>>>> >> have an application specify its desires directly?=
>>>> >>
>>>> >
>>>> >
>>>> >>
>>>> >> Small Objects:
>>>> >>
>>>> >> What is the new requirement here?  Why is th= e existing requirement in
>>>> >> draft-ietf-decade-reqs-00 insufficient?
>>>> >>
>>>> >> This also has me a bit worried:
>>>> >> "And the in-network storage has the limited = storage capacity, with the
>>>> >> arrival of user requests and data distribution re= quirements, the data
>>>> >> stored in the in-network storage will be replaced= if the storage
>>>> >> reaches the limit and data arrivals continually.&= quot;
>>>> >>
>>>> >> How does the server know what the proper replacem= ent strategy is for
>>>> >> an application? I think DECADE's philosophy i= s that applications
>>>> >> should decide this. A simple way to do this is ex= plicit deletion by an
>>>> >> application, but perhaps a more efficient (yet mo= re complex) solution
>>>> >> is for an application to specify the replacement = policy to the server.
>>>> >>
>>>> > actually, the key in "the data classification an= d small objects " is
>>>> > whether does it or not in P2P application? i did not = find data
>>>> > classification was adopted in P2P application so far,= let alone DECADE
>>>> > need
>>>> > to classify the data used in all kinds of application= .
>>>> >
>>>>
>>>> So, do you agree that it is problematic to try and classif= y each type
>>>> of application and try to specify the typical workload for= each class?
>>>>
>>>> My point was that I don't think its necessary to do th= e classification
>>>> at all.  It is more extensible (and directly useful) = for a server to
>>>> just give it direct hints about what would be preferable.<= br> >>>
>>> yep, i believe it may be a little difficult, but worthy doing.= specially
>>> for improving the resource utilization within a single server = and reducing
>>> the response time for client. what about others opinion?
>>
>> Can you justify why giving classifications (e.g., "I'm a = live
>> streaming application") would be better than giving specific = hints
>> (e.g., "please don't bother persistent these objects to d= isk")?
>>
>> i mean data in different kind of operation mode and attribute shou= ld have
>> different user patterns and storage rules, which may be help to im= prove the
>> resource utilization and reduce the response time for request, wha= t are you
>> understanding?
>>> >>
>>>> >> Removal of Expir= ed Records:
>>>> >>
>>>> >> "However, the two scenarios did not mention = how to handle the old
>>>> >> resource if the user distributes the new resource= which is an updated
>>>> >> copy of the old resource."
>>>> >>
>>>> >> Why does this need to be handled in the requireme= nts?  Are you trying
>>>> >> to draw the distinction between immediate deletio= n of content and lazy
>>>> >> deletion?
>>>> >>
>>>> > i mean the meaning of delete operation and how to han= dle the expired
>>>> > records need to be clarify in requirements.
>>>>
>>>> My inclination is that "deleted" means that othe= r requests the object
>>>> of the same name should result an error, until another obj= ect with the
>>>> same name is stored.
>>>
>>> okay, under the scenario "client uploads the new version,= and did not
>>> specify how to handle the old version", did DECADE server= delete the older
>>> version (or just label it unavailable, anyway, it is implement= ation issue
>>> )
>>> or not ? in another word, just replace the older version with = the new
>>> version with the same name?
>>
>> In this case, I would think the "write" of the new objec= t should be
>> rejected, or if desired, we could have an overwrite option.  = This
>> could be added to the requirements if it helps to clarify.
>>
>> yep, no matter which solution is chosen, let the understanding una= nimously:D
>>> how to handle the older version which is
>>> transferring from server to client?
>>
>> I think it would be cleaner to ask the server to continue sending = an
>> object once it has been started, but ultimately this would be the<= br> >> decision of the server's implementation I think.  Maybe a= "SHOULD"
>> requirement.  This could be added if desired.
>>
>> Thank you for these questions.  It helps design the requireme= nts more
>> cleanly if there are specific scenarios in front of us :)
>> just discussion together:D and also thanks for your points to help= me
>> understanding more!
>> Rich
>>
>>>> I think that the time the data is removed from disk (or me= mory) should
>>>> be up to the implementation. A storage provider might stil= l have as
>>>> part of some agreement that deleted data will be removed w= ithin X
>>>> days/hours/minutes/whatever.
>>>
>>>    agree with you.
>>>>
>>>> If people in the WG think it is necessary, we could have a= requirement
>>>> that says the protocol should support an argument indicati= ng immediate
>>>> deletion, but it is not clear that we need this.
>>>>
>>>> Rich
>>>>
>>>> >>
>>>> >> Thanks!
>>>> >> Rich
>>>> >>
>>>> >>
>>>> >> On Mon, Dec 27, 2010 at 12:57 AM, =D6=EC=E4=EC &l= t;buptxiaozhu@gm= ail.com> wrote:
>>>> >> > Dear all,
>>>> >> >
>>>> >> > There is a slightly updated version of the d= ecade additional
>>>> >> > requirements
>>>> >> > draft.
>>>> >> >
>>>> >> >
>>>> >> > https://datatr= acker.ietf.org/doc/draft-zhu-decade-additional-requirements/
>>>> >> >
>>>> >> > Jin Peng, Yunfei Zhang and me are expecting = to have a discussion
>>>> >> > with
>>>> >> > all of
>>>> >> > you.
>>>> >> >
>>>> >> > Any comments are appreciated!
>>>> >> >
>>>> >> > A new version of I-D,
>>>> >> > draft-zhu-decade-additional-requirements-00.= txt
>>>> >> > has been successfully submitted by Xiao Zhu = and posted to the IETF
>>>> >> > repository.
>>>> >> >
>>>> >> > Filename:      draft-zhu-deca= de-additional-requirements
>>>> >> > Revision:      00
>>>> >> > Title:           &n= bsp;     Additional protocol requirements on DECADE
>>>> >> > Creation_date:         2= 010-12-27
>>>> >> > WG ID:           &n= bsp;     Independent Submission
>>>> >> > Number_of_pages: 10
>>>> >> >
>>>> >> > Abstract:
>>>> >> > The DECoupled Application Data Enroute(DECAD= E)working group is
>>>> >> > specifying standardized interfaces for acces= sing in-network storage
>>>> >> > from applications to store, retrieve and man= age data. The main
>>>> >> > object
>>>> >> > is to provide a framework that is useful to = the applications,
>>>> >> > including P2P applications and other data-or= iented applications,
>>>> >> > possibly related applications that can benef= it from accessing in-
>>>> >> > network storage. This memo focuses on some r= equirements such as
>>>> >> > request redirecting and so on which are on t= he central of mobility,
>>>> >> > wireless network environment and CDN applica= tion. We present these
>>>> >> > in
>>>> >> > this memo as additional requirements that sh= ould be considered for
>>>> >> > the DECADE architecture and protocol specifi= cations.
>>>> >> >
>>>> >> >
>>>> >> >
>>>> >> > The IETF Secretariat.
>>>> >> >
>>>> >> > --
>>>> >> > Best wishes,
>>>> >> >
>>>> >> > Beijing University of Posts & Telecommun= ications (BUPT)
>>>> >> > Zhu Xiao  ( =D6=EC=E4=EC )
>>>> >> > E-mail: buptxiaozhu@gmail.com
>>>> >> > mobile:+86 134-8881-9004
>>>> >> >
>>>> >> > ____________________________________________= ___
>>>> >> > decade mailing list
>>>> >> > decade@ietf.org
>>>> >> > https://www.ietf.org/mailman/listinfo/decade=
>>>> >> >
>>>> >> >
>>>> >
>>>> >
>>>> >
>>>> > --
>>>> > Best wishes,
>>>> >
>>>> > Beijing University of Posts & Telecommunications = (BUPT)
>>>> > Zhu Xiao  ( =D6=EC=E4=EC )
>>>> > E-mail: buptxiaozhu@gmail.com
>>>> > mobile:+86 134-8881-9004
>>>
>>>
>>>
>>> --
>>> Best wishes,
>>>
>>> Beijing University of Posts & Telecommunications (BUPT) >>> Zhu Xiao  ( =D6=EC=E4=EC )
>>> E-mail: buptxiaozhu@gmail.com
>>> mobile:+86 134-8881-9004
>>>
>>
>>
>> --
>> Best wishes,
>>
>> Beijing University of Posts & Telecommunications (BUPT)
>> Zhu Xiao  ( =D6=EC=E4=EC )
>> E-mail: buptxiaozhu@gmail.com
>> mobile:+86 134-8881-9004
>



--
Best wishes,

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



--
Best wishes,

Bei= jing University of Posts & Telecommunications (BUPT)
Zhu Xiao  = ( =D6=EC=E4=EC )
E-mail: buptxiaozhu@gmail.com
mobile:+86 134-8881-9004
--000e0cd359808e6af704a6bc5843-- From haibin.song@huawei.com Tue Jun 28 02:31:25 2011 Return-Path: X-Original-To: decade@ietfa.amsl.com Delivered-To: decade@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19DA021F85B4 for ; Tue, 28 Jun 2011 02:31:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1an4qfqVubYz for ; Tue, 28 Jun 2011 02:31:24 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id 77A8021F85B3 for ; Tue, 28 Jun 2011 02:31:24 -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 <0LNH00128UG9RD@szxga03-in.huawei.com> for decade@ietf.org; Tue, 28 Jun 2011 17:31:21 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LNH00JWDUFZBE@szxga03-in.huawei.com> for decade@ietf.org; Tue, 28 Jun 2011 17:31:21 +0800 (CST) Received: from 172.24.2.119 (EHLO szxeml207-edg.china.huawei.com) ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA FastPath queued) with ESMTP id ABO43876; Tue, 28 Jun 2011 17:31:19 +0800 (CST) Received: from SZXEML412-HUB.china.huawei.com (10.82.67.91) by szxeml207-edg.china.huawei.com (172.24.2.59) with Microsoft SMTP Server (TLS) id 14.1.270.1; Tue, 28 Jun 2011 17:31:16 +0800 Received: from SZXEML524-MBX.china.huawei.com ([169.254.4.32]) by szxeml412-hub.china.huawei.com ([169.254.226.192]) with mapi id 14.01.0270.001; Tue, 28 Jun 2011 17:31:18 +0800 Date: Tue, 28 Jun 2011 09:31:18 +0000 From: Songhaibin X-Originating-IP: [10.138.41.119] 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 at IETF 801 Thread-index: Acw1diGsJVVXZ+f0R7mTwTEePSdkCg== X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected Subject: [decade] DECADE Meeting at IETF 801 X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2011 09:31:25 -0000 Dear all, DECADE meeting is scheduled on Tuesday from 15:20 to 17:00, in the meeting room 206B. Please note that IETF agendas are subject to change. BR, -Haibin From richard_woundy@cable.comcast.com Tue Jun 28 09:20:15 2011 Return-Path: X-Original-To: decade@ietfa.amsl.com Delivered-To: decade@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CC0111E80E4 for ; Tue, 28 Jun 2011 09:20:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.231 X-Spam-Level: X-Spam-Status: No, score=-97.231 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jaaa0QyT-pWj for ; Tue, 28 Jun 2011 09:20:12 -0700 (PDT) Received: from cable.comcast.com (copdcimo01.potomac.co.ndcwest.comcast.net [76.96.32.251]) by ietfa.amsl.com (Postfix) with ESMTP id AF62921F85AD for ; Tue, 28 Jun 2011 09:20:02 -0700 (PDT) Received: from ([24.40.55.41]) by copdcimo01.cable.comcast.com with ESMTP with TLS id 5503630.42554345; Tue, 28 Jun 2011 10:23:49 -0600 Received: from PACDCEXMB05.cable.comcast.com ([fe80::a5b0:e5c4:df1b:2367]) by PACDCEXHUB02.cable.comcast.com ([fe80::11d4:f530:37a0:9f4e%12]) with mapi id 14.01.0289.001; Tue, 28 Jun 2011 12:19:57 -0400 From: "Woundy, Richard" To: =?gb2312?B?1uzk7A==?= , Richard Alimi Thread-Topic: [decade] draft-zhu-decade-additional-requirements Thread-Index: AQHMNHdMnjlmX1MqU0uAgHH8mrKscZTSTrQAgACd46A= Date: Tue, 28 Jun 2011 16:19:56 +0000 Message-ID: <1CA25301D2219F40B3AA37201F0EACD1135A2B0F@PACDCEXMB05.cable.comcast.com> References: <1CA25301D2219F40B3AA37201F0EACD11343C0AB@PACDCEXMB05.cable.comcast.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.163.75.13] Content-Type: multipart/alternative; boundary="_000_1CA25301D2219F40B3AA37201F0EACD1135A2B0FPACDCEXMB05cabl_" MIME-Version: 1.0 Cc: "decade@ietf.org" Subject: Re: [decade] draft-zhu-decade-additional-requirements X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2011 16:20:15 -0000 --_000_1CA25301D2219F40B3AA37201F0EACD1135A2B0FPACDCEXMB05cabl_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 WGlhbywNCg0KTXkgcGVyc29uYWwgcHJlZmVyZW5jZSB3b3VsZCBiZSB0byBsZXQgZHJhZnQtemh1 LWRlY2FkZS1hZGRpdGlvbmFsLXJlcXVpcmVtZW50cyBleHBpcmUsIGFuZCBlbnN1cmUgdGhhdCB0 aGUga2V5IHJlcXVpcmVtZW50cyBmcm9tIHlvdXIgZHJhZnQgYXJlIHJlZmxlY3RlZCBpbiBkcmFm dC1pZXRmLWRlY2FkZS1yZXFzIHdoaWNoIGlzIHRoZSBvZmZpY2lhbCBXRyBkcmFmdC4NCg0KRG8g eW91IGhhdmUgb2JqZWN0aW9ucyBhYm91dCBob3cgeW91ciByZXF1aXJlbWVudHMgd2VyZSByZWZs ZWN0ZWQgaW4gZHJhZnQtaWV0Zi1kZWNhZGUtcmVxcz8NCg0KLS0gUmljaA0KDQpGcm9tOiDW7OTs IFttYWlsdG86YnVwdHhpYW96aHVAZ21haWwuY29tXQ0KU2VudDogTW9uZGF5LCBKdW5lIDI3LCAy MDExIDEwOjIzIFBNDQpUbzogUmljaGFyZCBBbGltaQ0KQ2M6IFdvdW5keSwgUmljaGFyZDsgZGVj YWRlQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW2RlY2FkZV0gZHJhZnQtemh1LWRlY2FkZS1hZGRp dGlvbmFsLXJlcXVpcmVtZW50cw0KDQpoaSwgUmljaGFyZCBhbmQgZXZlcnlib2R5DQoNClRoZSBk cmFmdCBkcmFmdC16aHUtZGVjYWRlLWFkZGl0aW9uYWwtcmVxdWlyZW1lbnRzIEkgc3VibWl0dGVk IGxhc3QgeWVhciBpcyBhYm91dCB0byBleHBpcmUuIGRvIHlvdSBoYXZlIHNvbWUgc3VnZ2VzdGlv bnMgdG8gdXBkYXRlIHRoZSB2ZXJzaW9uPyBhbmQgZG8gdGhlIERFQ0FERSByZXF1aXJlbWVudCBk cmFmdCBoYXMgYWRvcHRlZCBzb21lIHN1Z2dlc3Rpb25zIG9mIG15IGRyYWZ0Pw0KDQoyMDExLzYv Mjcg1uzk7CA8YnVwdHhpYW96aHVAZ21haWwuY29tPG1haWx0bzpidXB0eGlhb3podUBnbWFpbC5j b20+Pg0KaGksIFJpY2hhcmQgYW5kIGV2ZXJ5Ym9keQ0KDQpUaGUgZHJhZnQgZHJhZnQtemh1LWRl Y2FkZS1hZGRpdGlvbmFsLXJlcXVpcmVtZW50cyBJIHN1Ym1pdHRlZCBsYXN0IHllYXIgaXMgYWJv dXQgdG8gZXhwaXJlLiBkbyB5b3UgaGF2ZSBzb21lIHN1Z2dlc3Rpb25zIHRvIHVwZGF0ZSB0aGUg dmVyc2lvbj8gYW5kIGRvIHRoZSBERUNBREUgcmVxdWlyZW1lbnQgZHJhZnQgaGFzIGFkb3B0ZWQg c29tZSBzdWdnZXN0aW9ucyBvZiBteSBkcmFmdD8NCg0KMjAxMS8zLzE0IFJpY2hhcmQgQWxpbWkg PHJpY2hAdmVsdmV0c2VhLm5ldDxtYWlsdG86cmljaEB2ZWx2ZXRzZWEubmV0Pj4NCkhpIEFsbCwN Cg0KV2UndmUgbWFkZSBhbGwgb2YgdGhlc2UgdXBkYXRlcyB0byB0aGUgcmVxdWlyZW1lbnRzIGRv Y3VtZW50LCB3aXRoIHRoZQ0KZXhjZXB0aW9uIG9mOg0KDQo+IC0gSWYgYW4gb2JqZWN0IGlzIGRl bGV0ZWQgYXMgaXQgaXMgY29uY3VycmVudGx5IGJlaW5nIHJlYWQsIHRoZW4gdGhlDQo+IHNlcnZl ciBNQVkgY29udGludWUgdG8gcmVhZCBpdCAobGF6eSBkZWxldGlvbiksIG9yIGl0IE1BWSBkaXNj b250aW51ZQ0KPiByZWFkaW5nIHRoZSBvYmplY3QgYW5kIHNpZ25hbCBhbiBlcnJvciB0byB0aGUg Y2xpZW50IHJlYWRpbmcgdGhlDQo+IG9iamVjdC4NCg0KVXBvbiBsb29raW5nIGF0IHRoaXMgYWdh aW4sIGl0IGxvb2tzIG1vcmUgbGlrZSBhbiBpbXBsZW1lbnRhdGlvbg0KZGV0YWlsLiBJZiBhbnl0 aGluZywgdGhpcyB3b3VsZCByZXN1bHQgaW4gYSAibm9uLXJlcXVpcmVtZW50IiBpbiB0aGUNCmRv Y3VtZW50LiBIb3dldmVyLCBpdCBzZWVtcyBsaWtlIGEgZmFpcmx5IGxvdy1sZXZlbCBub24tcmVx dWlyZW1lbnQgdG8NCnN0YXRlIGF0IHRoaXMgdGltZS4gSSdkIHByb3Bvc2UgdG8gbGVhdmUgaXQg b3V0IGZvciBub3cgYW5kIHJldmlzaXQNCnRoaXMgaWYgaXQgY29tZXMgdXAgYWdhaW4gaW4gdGhl IGZ1dHVyZS4gIFRob3VnaHRzPw0KDQpUaGFua3MsDQpSaWNoDQoNCjIwMTEvMy8yIFJpY2hhcmQg QWxpbWkgPHJpY2hAdmVsdmV0c2VhLm5ldDxtYWlsdG86cmljaEB2ZWx2ZXRzZWEubmV0Pj46DQo+ IEhpIEFsbCwNCj4NCj4gSSdsbCBvZmZlciBhIHN1bW1hcnkgb2YgdGhpcyBkaXNjdXNzaW9uLiBM ZXQgbWUga25vdyBpZiBJIG1pc3NlZA0KPiBhbnl0aGluZywgb3IgaWYgdGhlcmUgYXJlIG9iamVj dGlvbnMvb3RoZXIgdGhvdWdodHMgb24gdGhlc2UgcHJvcG9zZWQNCj4gcmVzb2x1dGlvbnMuDQo+ DQo+IFJlZGlyZWN0aW9uOg0KPiAtIFdlIGNhbiBhZGQgYSByZXF1aXJlbWVudCBtZW50aW9uaW5n IHRoYXQgREVDQURFIG1heSBzdXBwb3J0IHJlZGlyZWN0aW9uLg0KPg0KPiBEYXRhIENsYXNzaWZp Y2F0aW9uOg0KPiAtIEkgKHBlcnNvbmFsbHkpIHN0cm9uZ2x5IGRpc2FncmVlIHdpdGggYXR0ZW1w dGluZyB0byBjbGFzc2lmeSBhY2Nlc3MNCj4gcGF0dGVybnMgb3IgYXBwbGljYXRpb25zLiBXZSBj b3VsZCBhZGQgc29tZXRoaW5nIHNheWluZyB0aGF0IGV4cGxpY2l0DQo+IGhpbnRzIChhIGxhIHd3 dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy83OC9zbGlkZXMvbmZzdjQtMC5wZGY8aHR0cDovL3d3dy5p ZXRmLm9yZy9wcm9jZWVkaW5ncy83OC9zbGlkZXMvbmZzdjQtMC5wZGY+KSBjb3VsZCBiZQ0KPiBw cm92aWRlZCBpbiBERUNBREUuICBIb3dldmVyLCBJIGRvbid0IHRoaW5rIHdlIG5lZWQgdG8gZG8g c29tZXRoaW5nDQo+IG5ldyBoZXJlLiBJbiBwYXJ0aWN1bGFyLCBpZiB0aGUgdW5kZXJseWluZyBz dG9yYWdlL2RhdGEgdHJhbnNwb3J0DQo+IHN1cHBvcnRzIGhpbnRzLCBhIERFQ0FERSBjbGllbnQg b3Igc2VydmVyIGNhbiB1c2UgaXQuDQo+DQo+IFN0b3JhZ2UgU3RhdHVzOg0KPiAtIFVwZGF0ZSBz ZWN0aW9uIDUuMS42IHRvIGluZGljYXRlIHRoYXQgc3RhdHVzIGluZm9ybWF0aW9uIHNob3VsZA0K PiBpbmNsdWRlIHBlcm1pc3Npb25zIG9mIHN0b3JlZCBvYmplY3RzLCBpZiBhcHBsaWNhYmxlLg0K PiAtIFVwZGF0ZSA1LjEuNiB0byBpbmRpY2F0ZSB0aGF0IHN0YXR1cyBpbmZvcm1hdGlvbiBzaG91 bGQgaW5jbHVkZQ0KPiBvdGhlciBpbmZvcm1hdGlvbiBhYm91dCByZXNvdXJjZSB1c2FnZSAodGhl IGNsaWVudHMgb3duIHJlc291cmNlcywgb3INCj4gcmVzb3VyY2VzIHVzZWQgYnkgb3RoZXIgY2xp ZW50cyB0aGF0IGhhdmUgYmVlbiBhdXRob3JpemVkIHRvDQo+IHJlYWQvd3JpdGUgb2JqZWN0cyBv ciBvcGVuIGNvbm5lY3Rpb25zIHRvIG9uZSdzIHN0b3JhZ2UpLg0KPg0KPiBSZXF1aXJlbWVudHMg Zm9yIG9iamVjdCBkZWxldGlvbi9vdmVyd3JpdGluZzoNCj4gLSBERUNBREUgTUFZIGhhdmUgYW4g b3ZlcndyaXRlIGZsYWcgKG5vdGUgdGhhdCB0aGlzIG1heSBvciBtYXkgbm90IGJlDQo+IG5lY2Vz c2FyeSBkZXBlbmRpbmcgb24gb3VyIG5hbWluZywgYnV0IHRoZSByZXF1aXJlbWVudHMgZG9jdW1l bnQNCj4gcHJvYmFibHkgaXMgbm90IHRoZSBwbGFjZSB0byB0YWtlIGEgc3RhbmQgb24gdGhpcyBh dCB0aGUgY3VycmVudA0KPiBwb2ludC4pDQo+IC0gSWYgYW4gb2JqZWN0IGlzIGRlbGV0ZWQgYXMg aXQgaXMgY29uY3VycmVudGx5IGJlaW5nIHJlYWQsIHRoZW4gdGhlDQo+IHNlcnZlciBNQVkgY29u dGludWUgdG8gcmVhZCBpdCAobGF6eSBkZWxldGlvbiksIG9yIGl0IE1BWSBkaXNjb250aW51ZQ0K PiByZWFkaW5nIHRoZSBvYmplY3QgYW5kIHNpZ25hbCBhbiBlcnJvciB0byB0aGUgY2xpZW50IHJl YWRpbmcgdGhlDQo+IG9iamVjdC4NCj4NCj4gV291bGQgdGhpcyBiZSBzdWZmaWNpZW50IHRvIG1l cmdlIGluIHRoZSBwb2ludHMgZnJvbQ0KPiBkcmFmdC16aHUtZGVjYWRlLWFkZGl0aW9uYWwtcmVx dWlyZW1lbnRzLTAwIGFuZCB0aGlzIGVuc3VpbmcNCj4gZGlzY3Vzc2lvbj8NCj4NCj4gVGhhbmtz LA0KPiBSaWNoDQo+DQo+DQo+IDIwMTEvMy8yIFdvdW5keSwgUmljaGFyZCA8UmljaGFyZF9Xb3Vu ZHlAY2FibGUuY29tY2FzdC5jb208bWFpbHRvOlJpY2hhcmRfV291bmR5QGNhYmxlLmNvbWNhc3Qu Y29tPj46DQo+PiBGb2xrcywNCj4+DQo+Pg0KPj4NCj4+IERvIHdlIGhhdmUgY29uc2Vuc3VzIHll dCBhYm91dCBob3cgdGhlIFdHIGNvdWxkIGhhdmUgYSBzaW5nbGUgREVDQURFDQo+PiByZXF1aXJl bWVudHMgZG9jdW1lbnQgZ29pbmcgZm9yd2FyZD8gSSBjYW4ndCB0ZWxsIHRoZSBzdGF0ZSBvZiBv dXINCj4+IHJlcXVpcmVtZW50cyBjb25zb2xpZGF0aW9uIGZyb20gdGhlIGVtYWlsIHRocmVhZCBi ZWxvdy4NCj4+DQo+Pg0KPj4NCj4+IEl0IHdvdWxkIGJlIHByZWZlcmFibGUgaWYgd2UgY291bGQg cmVzb2x2ZSB0aGlzIGZ1bGx5IG9uIHRoZSBXRyBtYWlsaW5nDQo+PiBsaXN0LCBidXQgdGhpcyBp cyBpbXBvcnRhbnQgZW5vdWdoIHRvIGFsbG9jYXRlIHNvbWUgdGltZSBhdCBvdXIgbWVldGluZyBp bg0KPj4gUHJhZ3VlLg0KPj4NCj4+DQo+Pg0KPj4gLS0gUmljaA0KPj4NCj4+DQo+Pg0KPj4gRnJv bTogZGVjYWRlLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOmRlY2FkZS1ib3VuY2VzQGlldGYub3Jn PiBbbWFpbHRvOmRlY2FkZS1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpkZWNhZGUtYm91bmNlc0Bp ZXRmLm9yZz5dIE9uIEJlaGFsZiBPZg0KPj4gPz8NCj4+IFNlbnQ6IFN1bmRheSwgSmFudWFyeSAx NiwgMjAxMSA5OjAyIFBNDQo+PiBUbzogUmljaGFyZCBBbGltaQ0KPj4gQ2M6IGRlY2FkZUBpZXRm Lm9yZzxtYWlsdG86ZGVjYWRlQGlldGYub3JnPg0KPj4gU3ViamVjdDogUmU6IFtkZWNhZGVdIGRy YWZ0LXpodS1kZWNhZGUtYWRkaXRpb25hbC1yZXF1aXJlbWVudHMNCj4+DQo+Pg0KPj4NCj4+IGhp LCBSaWNoYXJkOg0KPj4NCj4+DQo+Pg0KPj4gdGhhbmtzIGZvciB5b3VyIHJlcGx5OkQNCj4+DQo+ PiBhZGRpdGlvbmFsIGRpc2N1c3Npb24gc2VlIGlubGluZTpEDQo+Pg0KPj4NCj4+DQo+PiAyMDEx LzEvMTQgUmljaGFyZCBBbGltaSA8cmljaEB2ZWx2ZXRzZWEubmV0PG1haWx0bzpyaWNoQHZlbHZl dHNlYS5uZXQ+Pg0KPj4NCj4+IEhJIFhpYW8sDQo+Pg0KPj4gMjAxMS8xLzEyINbs5OwgPGJ1cHR4 aWFvemh1QGdtYWlsLmNvbTxtYWlsdG86YnVwdHhpYW96aHVAZ21haWwuY29tPj46DQo+Pg0KPj4+ IGhpLCBSaWNoYXJkDQo+Pj4gc2VlIGlubGluZTpEDQo+Pj4NCj4+PiAyMDExLzEvMTEgUmljaGFy ZCBBbGltaSA8cmljaEB2ZWx2ZXRzZWEubmV0PG1haWx0bzpyaWNoQHZlbHZldHNlYS5uZXQ+Pg0K Pj4+Pg0KPj4+PiBIaSBYaWFvLA0KPj4+Pg0KPj4+PiBPbiBNb24sIEphbiAxMCwgMjAxMSBhdCA2 OjQ1IFBNLCDW7OTsIDxidXB0eGlhb3podUBnbWFpbC5jb208bWFpbHRvOmJ1cHR4aWFvemh1QGdt YWlsLmNvbT4+IHdyb3RlOg0KPj4+PiA+DQo+Pj4+ID4gaGksIFJpY2hhcmQsIHNvcnJ5IGZvciBz byBsYXRlIHJlc3BvbnNlIGJlY2F1c2Ugb2YgYmUgYnVzeSB3aXRoIG90aGVyDQo+Pj4+ID4gcHJv amVjdHMuDQo+Pj4+ID4gc29tZSBkaXNjdXNzaW9uIHNlZSBpbmxpbmU6RCBtYXJrZWQgYnkgcmVk Lg0KPj4+PiA+DQo+Pj4+ID4gT24gVHVlLCBKYW4gNCwgMjAxMSBhdCA0OjA2IEFNLCBSaWNoYXJk IEFsaW1pIDxyaWNoQHZlbHZldHNlYS5uZXQ8bWFpbHRvOnJpY2hAdmVsdmV0c2VhLm5ldD4+DQo+ Pj4+ID4gd3JvdGU6DQo+Pj4+ID4+DQo+Pj4+ID4+IEhpIFhpYW8sDQo+Pj4+ID4+DQo+Pj4+ID4+ IFRoYW5rIHlvdSBmb3IgdGhlIGRyYWZ0LiAgU29tZSBjb21tZW50cyBvbiB0aGUgcmVxdWlyZW1l bnRzOg0KPj4+PiA+Pg0KPj4+PiA+PiBSZXF1ZXN0IFJlZGlyZWN0czoNCj4+Pj4gPj4NCj4+Pj4g Pj4gVGhpcyB3b3VsZCBwcm92aWRlIHNvbWUgYWRkaXRpb25hbCBmcmVlZG9tIGZvciB0aGUgc3Rv cmFnZSBwcm92aWRlci4NCj4+Pj4gPj4gSSB0aGluayBpdCBpcyByZWFzb25hYmxlIHNpbmNlIGl0 IGRvZXNuJ3QgbmVjZXNzaXRhdGUgYWRkaXRpb25hbA0KPj4+PiA+PiBjb21wbGV4aXR5IGZvciB0 aGUgREVDQURFIHNlcnZlciwgYnV0IGFsbG93cyBpdCBpZiBkZXNpcmVkLiBIb3dldmVyLA0KPj4+ PiA+PiBub3RlIHRoYXQgaXQgbWF5IGNvbXBsaWNhdGUgc29tZSBvZiB0aGUgb3RoZXIgY29tcG9u ZW50cyBvZiB0aGUNCj4+Pj4gPj4gZGVzaWduLiBJbiBwYXJ0aWN1bGFyLCBpZiB0aGVyZSBpcyBh IHBlci11c2VyIHF1b3RhIGZvciBzdG9yYWdlLCBpcw0KPj4+PiA+PiB0aGUgdXNlciBtYWRlIGF3 YXJlIG9mIHRoZSBxdW90YSBhdCBlYWNoIGluLW5ldHdvcmsgc3RvcmFnZSAoaWYgdGhlcmUNCj4+ Pj4gPj4gaXMgbm8gc2hhcmVkIHN0b3JhZ2UgYmV0d2VlbiB0aGVtKT8gIFJlc291cmNlIHNoYXJp bmcgcG9saWNpZXMgbWF5IGJlDQo+Pj4+ID4+IGltcGFjdGVkIChlLmcuLCBpZiBhIGJhbmR3aWR0 aCBzaGFyaW5nIHdlaWdodCBvZiAxIG1heSBtZWFuIHNvbWV0aGluZw0KPj4+PiA+PiBkaWZmZXJl bnQgYXQgREVDQURFIHNlcnZlciBBIHRoYW4gaXQgZG9lcyBhdCBERUNBREUgc2VydmVyIEIpLiAg QXQNCj4+Pj4gPj4gdGhpcyBwb2ludCBpdCBtYXkgYmUgYmVzdCB0byBqdXN0IG5vdGUgdGhlc2Ug c28gdGhleSBhcmUgZG9jdW1lbnRlZCwNCj4+Pj4gPj4gYnV0IHNpbmNlIHRoZSBzcGVjaWZpY2F0 aW9uIG9mIHRoZSByZXNvdXJjZSBzaGFyaW5nIHBvbGljaWVzIGFyZSBzdGlsbA0KPj4+PiA+PiBi ZWluZyBjb250ZW1wbGF0ZWQgZm9yIHRoZSBiYXNpYyBjYXNlIG9mIGEgc2luZ2xlIHNlcnZlciBp dCBtYXkgYmUNCj4+Pj4gPj4gcHJlbWF0dXJlIHRvIGV2ZW4gdHJ5IGFuZCBzb2x2ZSB0aGVtIGZv ciB0aGUgY2FzZSBzdXBwb3J0aW5nDQo+Pj4+ID4+IHJlZGlyZWN0aW9uLg0KPj4+PiA+Pg0KPj4+ PiA+IGFjdHVhbGx5LCB5b3UgbWVhbiB0d28gcG9pbnRzLCByaWdodD8NCj4+Pj4gPiAxLiB3aGV0 aGVyIG9yIG5vdCB0byBiZSB3YXJlIG9mIHRoZSBjb250ZW50IGF0IGVhY2ggaW4tbmV0d29yayBz dG9yYWdlDQo+Pj4+ID4gYW5kIG9mIGNvdXJzZSByZXNvdXJjZSBzaGFyaW5nIHBvbGljaWVzIGNh biBiZSBpbXBhY3QgaW4gdGhlIHJlcXVlc3QNCj4+Pj4gPiByZWRpcmVjdGlvbi4geW91ciBzdWdn ZXN0aW9uImp1c3QgdG8gbm90ZSB0aGVzZSBzbyB0aGV5IGFyZSBkb2N1bWVudGVkIg0KPj4+PiA+ IHdpbGwNCj4+Pj4gPiBiZSBvaywgb3IgREVDQURFIHNlcnZlciBsaXN0IHdpdGggc29tZSBwYXJh bWV0ZXJzIHdpbGwgYmUgcmV0dXJuIGZvcg0KPj4+PiA+IHVzZXIgdG8NCj4+Pj4gPiBzZWxlY3Qg dGhlIGFwcHJvcHJpYXRlIERFQ0FERSBzZXJ2ZXIsIHdoaWNoIGNhbiBhdm9pZCB0aGUgZGlmZmVy ZW50DQo+Pj4+ID4gd2VpZ2h0ZWQNCj4+Pj4gPiBvZiB0aGUgc2FtZSBwYXJhbWV0ZXIgaW4gc2Vy dmVyIGRlY2lzaW9uLiBidXQgdGhlIHBhcmFtZXRlciB1c2VkIGluDQo+Pj4+ID4gc2VsZWN0DQo+ Pj4+ID4gdGhlIGJlc3QgREVDQURFIHNlcnZlciB3aWxsIGJlIGtub3duIGZvciBERUNBREUgc2Vy dmVycywgaW4gd2hpY2ggb3RoZXINCj4+Pj4gPiBjb21wbGV4aXRpZXMgd2lsbCBiZSBhZGRlZC4g YW55d2F5LCBhbGwgdGhlIHNvbHV0aW9uIGFyZSB0aGUNCj4+Pj4gPiBpbXBsZW1lbnRhdGlvbg0K Pj4+PiA+IGlzc3VlLCB3aGljaCwgaSBiZWxpZXZlLCBkb2VzIG5vdCBpbXBhY3QgdGhlIG5lY2Vz c2l0eSBvZiB0aGUNCj4+Pj4gPiByZXF1aXJlbWVudC4NCj4+Pj4NCj4+Pj4gSW4gZ2VuZXJhbCwg SSdkIGFncmVlIHRoYXQgdGhlIGRlY2lzaW9uIGFib3V0IHdoZXJlIHRvIHJlZGlyZWN0IHdvdWxk DQo+Pj4+IGJlIGFuIGltcGxlbWVudGF0aW9uIGlzc3VlLg0KPj4+Pg0KPj4+PiA+DQo+Pj4+ID4g Mi4geW91IG1lYW4gInRoZSByZXNvdXJjZSBzaGFyaW5nIHBvbGljaWVzIGFyZSBzdGlsbCBiZWlu ZyBjb25zaWRlcmVkDQo+Pj4+ID4gaW4NCj4+Pj4gPiBhIHNpbmdsZSBzZXJ2ZXIiLCBzbyBpdCBt YXkgYmUgcHJlbWF0dXJlIHRvIHN1cHBvcnQgcmVkaXJlY3Rpb24uICB0aGUNCj4+Pj4gPiBhcmNo aXRlY3R1cmUgYW5kIHByb3RvY29sIHdpbGwgYmUgYmFkbHkgaW1wYWN0ZWQgaWYgdGhlIHJlcXVp cmVtZW50cw0KPj4+PiA+IGNoYW5nZS4NCj4+Pj4gPiBzbyB0aGUgZGVzaWduaW5nIGNhbiBiZSAg dGFrZW4gIHN0ZXAgYnkgc3RlcCwgYnV0IHRoZSByZXF1aXJlbWVudHMNCj4+Pj4gPiBzaG91bGQg YmUNCj4+Pj4gPiBvdmVyYWxsIGNvbnNpZGVyZWQuDQo+Pj4+DQo+Pj4+IEkgc2FpZCB0aGF0IGl0 IGlzIHByb2JhYmx5IHByZW1hdHVyZSB0byBjb25zaWRlciBob3cgcmVzb3VyY2Ugc2hhcmluZw0K Pj4+PiBwb2xpY2llcyB3b3JrcyBhY3Jvc3Mgc2VydmVycyAob3IgZXZlbiBpZiB3ZSBuZWVkIHRv IHNheSBhbnl0aGluZw0KPj4+PiBhYm91dCBpdCkgc2luY2Ugd2UgaGF2ZSBub3QgZGV0ZXJtaW5l ZCBob3cgdG8gc3BlY2lmeSB0aGVtIChvciByYXRoZXIsDQo+Pj4+IGhvdyBsaXR0bGUgd2UgbmVl ZCB0byBzcGVjaWZ5IGluIHByb3RvY29sKSBmb3IgYSBzaW5nbGUgc2VydmVyLiBJIGRpZA0KPj4+ PiBub3QgbWVhbiB0byBpbXBseSB0aGF0IHJlZGlyZWN0aW9uIGNvdWxkIG5vdCBiZSBpbnRyb2R1 Y2VkIGFzIGENCj4+Pj4gcmVxdWlyZW1lbnQuDQo+Pj4+DQo+Pj4NCj4+Pj4NCj4+Pj4gPg0KPj4+ PiA+DQo+Pj4+ID4+DQo+Pj4+ID4+IE11bHRpLWNvbm5lY3Rpb246DQo+Pj4+ID4+DQo+Pj4+ID4+ IEknbSBub3QgcXVpdGUgY2xlYXIgb24gdGhlIGludGVudGlvbiBvZiB0aGUgcmVxdWlyZW1lbnQu ICBNeQ0KPj4+PiA+PiB1bmRlcnN0YW5kaW5nIGlzIHRoYXQgeW91IHdpc2ggdGhlIGNsaWVudCB0 byBiZSBhYmxlIHRvIGhhdmUgbXVsdGlwbGUNCj4+Pj4gPj4gY29ubmVjdGlvbnMgb3BlbiBzcGFu bmluZyBtdWx0aXBsZSBERUNBREUgc2VydmVycy4gSXMgdGhhdCBjb3JyZWN0Pw0KPj4+PiA+Pg0K Pj4+PiA+PiBJZiBzbywgZG8gd2UgbmVlZCB0aGlzIHN0YXRlZCBhcyBhIHJlcXVpcmVtZW50IG9y IHRoZSBwcm90b2NvbD8gT3IgaXMNCj4+Pj4gPj4gdGhpcyBhIHBvbGljeSB0aGF0IHdvdWxkIGJl IGFsbG93ZWQvZGlzYWxsb3dlZCBieSB0aGUgc3RvcmFnZQ0KPj4+PiA+PiBwcm92aWRlcj8NCj4+ Pj4gPj4NCj4+Pj4gPiB5ZXAsIHlvdXIgdW5kZXJzdGFuZGluZyBpcyByaWdodCwgdGhlIHNjZW5h cmlvcyB3ZXJlIGp1c3QgZGVzY3JpYmVkIGluDQo+Pj4+ID4gZHJhZnQgYXMgInNvZnQgaGFuZG92 ZXIgaW4gd2lyZWxlc3MgZW52aXJvbm1lbnQgYW5kIGRlbGV0ZSBvcGVyYXRpb24gaW4NCj4+Pj4g PiBtdWx0aS1zZXJ2ZXJzIi4gdW5kZXIgdGhlc2UgY29uc2lkZXJhdGlvbiwgdGhlIGF1dGhlbnRp Y2F0aW9uIGFuZA0KPj4+PiA+IGF1dGhvcml6YXRpb24gbmVlZCB0byBiZSB0YWtlbiBlYWNoIHRp bWUgd2hlbiBzZXR1cCBjb25uZWN0aW9uIHdpdGggYQ0KPj4+PiA+IG5ldw0KPj4+PiA+IERFQ0FE RSBzZXJ2ZXIsIG9yIGp1c3QgYmUgdGFrZW4gb25seSBvbmNlIGR1cmluZyAgdGhlIHNlcnZpY2U/ DQo+Pj4+DQo+Pj4+IFRoZSBERUNBREUgc2VydmVyIHNob3VsZCBuZWVkIHRvIGRvIHNvbWUgc29y dCBvZiBjaGVjayBvbiBlYWNoIG5ldw0KPj4+PiBjb25uZWN0aW9uLCByZWdhcmRsZXNzIG9mIHdo ZXRoZXIgdGhlIHVzZXIgaGFzIG9yIHByZXZpb3VzbHkgaGFkIGENCj4+Pj4gY29ubmVjdGlvbiBv cGVuIHRvIGEgZGlmZmVyZW50IERFQ0FERSBzZXJ2ZXIsIHJpZ2h0PyAgTm90ZSB0aGF0IHRoZQ0K Pj4+PiByZXF1aXJlbWVudHMgZG9uJ3QgaW5kaWNhdGUgaG93IGF1dGhlbnRpY2F0aW9uIG9yIGF1 dGhvcml6YXRpb24gaXMNCj4+Pj4gZG9uZSwgYW5kIGFsbG93IGEgc2VydmVyIHRvIG1ha2Ugb3B0 aW1pemF0aW9ucyBpZiBpdCBpcyBlbmZvcmNpbmcgdGhlDQo+Pj4+IHNhbWUgcGVybWlzc2lvbnMu DQo+Pj4+DQo+Pj4+IENhbiB5b3UgaW5kaWNhdGUgd2hlcmUgdGhlIGV4aXN0aW5nIGF1dGhvcml6 YXRpb24tcmVsYXRlZCByZXF1aXJlbWVudHMNCj4+Pj4gKGluIHBhcnRpY3VsYXIsIDQuMS42LjMg b2YgZHJhZnQtaWV0Zi1kZWNhZGUtcmVxcy0wMCkgZG8gbm90IHN1ZmZpY2UNCj4+Pj4gZm9yIHRo ZSB1c2UgY2FzZSB5b3UgYXJlIHRoaW5raW5nIG9mPw0KPj4NCj4+PiBhcyBjb25zaWRlcmluZyB0 aGUgc2VydmljZSBjb250aW51aXR5LCB0aGUgbmV4dCBzZXJ2aW5nICBERUNBREUgc2VydmVyDQo+ Pj4gc2hvdWxkIGtub3cgdGhlIHByb2dyZXNzIG9mIHRoZSBzZXJ2aWNlLCBob3cgZG9lcyB0aGV5 IGtub3c/DQo+Pg0KPj4gQnkgcHJvZ3Jlc3Mgb2YgdGhlIHNlcnZpY2UsIGRvIHlvdSBtZWFuIGN1 cnJlbnQgdXNlciBzdGF0ZSAoZS5nLiwNCj4+IHF1b3RhLCByZWNlbnQgcmVzb3VyY2UgdXNhZ2Ug aGlzdG9yeSwgcGVybWlzc2lvbnMsIGV0Yyk/DQo+Pg0KPj4geWVzLCBhbmQgaW5jbHVkZSBkYXRh IGRlbGl2ZXJ5IHByb2NlZWRpbmcuDQo+Pj4gc28gaWYgdGhlDQo+Pj4gc2VydmljZSBwcm9jZWVk aW5nIGluZm9ybWF0aW9uIHNob3VsZCBiZSBrbm93biBieSB0aGUgbmV4dCBzZXJ2aW5nIHNlcnZl ciwNCj4+PiBvciBkaWZmZXJlbnQgc2VydmVycyBuZWVkIHRvIGNvb3JkaW5hdGUgYW5kIHNjaGVk dWxlIGVhY2ggb3RoZXIgdG8gZnVsZmlsbA0KPj4+IHRoZSB1c2VyIHJlcXVlc3QsIGkgYmVsaWV2 ZSB0aGUgdGhlIDQuMS42LjMgb2YgdGhlDQo+Pj4gZHJhZnQtaWV0Zi1kZWNhZGUtcmVxLTAwDQo+ Pj4gY2Fubm90IHNhdGlzZnkgdGhlIHJlcS4gd2hhdCBkbyB5b3UgdGhpbmsgYWJvdXQ/DQo+Pg0K Pj4gTm90ZSB0aGF0IHRoZSBwcm90b2NvbCB0aGF0IGlzIGNvdmVyZWQgaGVyZSBpcyB0aGUgY2xp ZW50LXNlcnZlcg0KPj4gcHJvdG9jb2wuIFNvbWUgb2YgdGhlIHNhbWUgcHJvdG9jb2wgbWF5IGJl IHVzZWZ1bCBiZXR3ZWVuIERFQ0FERQ0KPj4gc2VydmVycyAoZXNwZWNpYWxseSBpbiBkaWZmZXJl bnQgYWRtaW5pc3RyYXRpdmUgZG9tYWlucykgZm9yIHN0b3JpbmcNCj4+IGFuZCByZXRyaWV2aW5n IGRhdGEsIGJ1dCB0aGF0IGRvZXMgbm90IG1lYW4gdGhhdCB0aGVyZSBjYW4ndCBiZQ0KPj4gYWRk aXRpb25hbCBwcm90b2NvbChzKSAobm90IHNwZWNpZmllZCBoZXJlKSB0aGF0IGFyZSB1c2VkIGJl dHdlZW4NCj4+IERFQ0FERSBzZXJ2ZXJzIGFzIHdlbGwuICBGb3IgZXhhbXBsZSwgaWYgREVDQURF IHNlcnZlcnMgd2l0aGluIGFuDQo+PiBhZG1pbmlzdHJhdGl2ZSBkb21haW4gY2FuIGNlcnRhaW5s eSBoYXZlIHRoZWlyIG93biBtZWNoYW5pc20gdG8gc2hhcmUNCj4+IHN1Y2ggaW5mb3JtYXRpb24u ICBJZiBzdWNoIGNhcGFiaWxpdGllcyB3ZXJlIGluY2x1ZGVkIGluIHRoZSBERUNBREUNCj4+IHBy b3RvY29sIChlLmcuLCBhIG5lZWQgdG8gZG8gdGhpcyBiZXR3ZWVuIGFkbWluaXN0cmF0aXZlIGRv bWFpbnMpLA0KPj4gdGhhdCBzb3VuZHMgbGlrZSBsb3RzIG1vcmUgY29tcGxleGl0eSB0aGF0IHdl IG5lZWQgYXQgdGhpcyBwb2ludC4NCj4+IGJ1dCB0aGUgYWNjZXNzIGJldHdlZW4gaW4tbmV0d29y ayBzdG9yYWdlIGFsc28gaXMgaW5jbHVkZWQgaW4gSUFQIGRlc2NyaWJlZA0KPj4gaW4gcHJvYmxl bSBzdGF0ZW1lbnQuICBpIG1lYW4gd2h5IG5vdCBwdXQgdGhpcyBraW5kIG9mIGZ1bmN0aW9uIGlu IERFQ0FERQ0KPj4gc2luY2UgdGhlIElBUCBpcyBkZWZpbmVkIGp1c3QgbGlrZSB0aGF0Pw0KPj4g VGhhdCBzYWlkLCBpdCBzb3VuZHMgdG8gbWUgbGlrZSB3aGF0IGlzIGRlc2NyaWJlZCBpbiA0LjEu Ni4zIHdvdWxkIGJlDQo+PiBzdWZmaWNpZW50IChmcm9tIHRoZSBwZXJzcGVjdGl2ZSBvZiB0aGUg Y2xpZW50LXNlcnZlciBwcm90b2NvbCwNCj4+IGFueXdheXMpIHRvIGltcGxlbWVudCB3aGF0IHlv dSdyZSBkZXNjcmliaW5nLiBJZiBub3QsIHdoYXQNCj4+IHNwZWNpZmljYWxseSBpcyBtaXNzaW5n IGFuZCB3aGF0IHVzZS1jYXNlIGRvZXMgaXQgbm90IG1lZXQ/DQo+Pg0KPj4gc28geW91IG1lYW4g dGhlIGluZm9ybWF0aW9uIHlvdSBtZW50aW9uZWQgYWJvdmUsIGp1c3QgbGlrZSBjdXJyZW50IHVz ZXINCj4+IHN0YXRlIChlLmcuLA0KPj4gcXVvdGEsIHJlY2VudCByZXNvdXJjZSB1c2FnZSBoaXN0 b3J5LCBwZXJtaXNzaW9ucywgZXRjKSB3YXMgYWxyZWFkeSBpbmNsdWRlZA0KPj4gaW4gREVDQURF IHJlcXVpcmVtZW50PyB3aGF0IGFib3V0IHRoZSBkYXRhIGRlbGl2ZXJ5IHByb2NlZWRpbmcgaW5m b3JtYXRpb24/DQo+PiBjYW4geW91IHNwZWNpZnkgdGhlIGNoYXB0ZXIgZm9yIG1lID8gdGhhbmtz Pw0KPj4+PiA+DQo+Pj4+ID4NCj4+Pj4gPj4NCj4+Pj4gPj4gRGF0YSBEaXN0cmlidXRpb246DQo+ Pj4+ID4+DQo+Pj4+ID4+IEknbSBhbHNvIGNvbmZ1c2VkIGFib3V0IHRoZSBpbnRlbnQgb2YgdGhp cyByZXF1aXJlbWVudC4gIFRoaXMNCj4+Pj4gPj4gc3RhdGVtZW50IGhhcyBtZSBzb21ld2hhdCB3 b3JyaWVkOiAiVGhlIGRpc3RyaWJ1dGlvbiBpcyB0cmFuc3BhcmVudCB0bw0KPj4+PiA+PiB0aGUg dXNlcnMgYXMgdGhleSBpbnRlcmFjdCB3aXRoIHRoZSBpbi1uZXR3b3JrIHN0b3JhZ2UgYXMgYSBz aW5nbGUNCj4+Pj4gPj4gbG9naWNhbCBzeXN0ZW0uIiBEb2VzIHRoaXMgbWVhbiB0aGF0IHlvdSBh cmUgcHJvcG9zaW5nIGZvciBERUNBREUNCj4+Pj4gPj4gc2VydmVycyB0byBhc3N1bWUgdGhlIHJl c3BvbnNpYmlsaXR5IGZvciBkZWNpZGluZyBob3cgZGF0YSBpcyB0byBiZQ0KPj4+PiA+PiBkaXN0 cmlidXRlZCB0aHJvdWdob3V0IHRoZSBuZXR3b3JrLCBpbmNsdWRpbmcgdGhlIHBhdGggb2YgdGhl IGRhdGEsDQo+Pj4+ID4+IHdoaWNoIHNlcnZlcnMgYWN0IGFzIGludGVybWVkaWF0ZSBjYWNoZXMs IGNvbnRlbnQgZXhwaXJhdGlvbiBwb2xpY2llcywNCj4+Pj4gPj4gZXRjPyAgSWYgdGhpcyBpcyB0 cnVlLCBJIHRoaW5rIGl0IGlzIG1pc3Npbmcgb25lIG9mIHRoZSBtYWpvciBwb2ludHMNCj4+Pj4g Pj4gb2YgREVDQURFLiBJbiBwYXJ0aWN1bGFyLCB0aGVzZSBkZWNpc2lvbnMgYXJlIGFwcGxpY2F0 aW9uLWRlcGVuZGVudA0KPj4+PiA+PiBhbmQgYXJlIG5vdCBpbXBsZW1lbnRlZCB3aXRoaW4gREVD QURFLiBJbnN0ZWFkLCBERUNBREUgcHJvdmlkZXMgdGhlDQo+Pj4+ID4+IGJhc2ljIGNhcGFiaWxp dGllcyBhbmQgdGhlIGZ1bmN0aW9uYWxpdHkgZGVzY3JpYmVkIGFib3ZlIGFyZQ0KPj4+PiA+PiBp bXBsZW1lbnRlZCBieSB0aGUgYXBwbGljYXRpb25zIHVzaW5nIERFQ0FERS4NCj4+Pj4gPj4NCj4+ Pj4gPj4gT3IsIGFtIEkgbWlzaW50ZXJwcmV0aW5nIHRoZSBpbnRlbnQgb2YgdGhlIHJlcXVpcmVt ZW50Pw0KPj4+PiA+Pg0KPj4+PiA+IHlvdSBtZWFuIERFQ0FERSBwcm92aWRlcyB0aGUgYmFzaWMg Y2FwYWJpbGl0aWVzLCBzbyBjYW4geW91IGdpdmUgc29tZQ0KPj4+PiA+IHNwZWNpZnkgZXhwbGFu YXRpb25zIG9uIERFQ0FERSBjYXBhYmlsaXRpZXMgaW4gc3VwcG9ydGluZyBkYXRhDQo+Pj4+ID4g ZGlzdHJpYnV0aW9uPw0KPj4+PiA+Pg0KPj4+Pg0KPj4+PiBUaGUgcHJvYmxlbSBzdGF0ZW1lbnQg Z2l2ZXMgYSBjb3VwbGUgb2Ygc2NlbmFyaW9zLiBUaGUgIkludGVncmF0aW9uDQo+Pj4+IEV4YW1w bGVzIiBwcmVzZW50YXRpb24gZnJvbSBJRVRGIDc5IGFsc28gaGFzIG1vcmUgZGV0YWlscyBvZiBh bg0KPj4+PiBvbi1nb2luZyBlZmZvcnQgYXQgWWFsZS4NCj4+DQo+Pj4gb2theSwgdGh4IGZvciB5 b3VyIGluZm9ybWF0aW9uLCBpIHdpbGwgbG9va3VwIGFuZCByZWZlciwgYWN0dWFsbHksIHRoZQ0K Pj4+IGNvbnRlbnQgcHVibGlzaGVyIGRlc2NyaWJlZCBpbiBwcm9ibGVtIHN0YXRlbWVudCByZW1p bmQgbWUgb2YgIHRoZQ0KPj4+IHByb3RvY29sIHJlcXVpcmVtZW50cyB3aGljaCBpIGRpZCBub3Qg ZmluZCBpbiBkcmFmdC1pZXRmLWRlY2FkZS1yZXFzLTAwIHRvDQo+Pj4gc3VwcG9ydCBjb250ZW50 IHB1Ymxpc2guIG9yIGkgbWlzcyBzb21lIHBvaW50cz8NCj4+DQo+PiBXaGljaCByZXF1aXJlbWVu dHMgZG8geW91IHRoaW5rIGFyZSBtaXNzaW5nPw0KPj4NCj4+Pj4gPj4gU2VydmljZSBBc3N1cmFu Y2U6DQo+Pj4+ID4+DQo+Pj4+ID4+IEl0IHNlZW1zIHByb2JsZW1hdGljIHRvIGluY2x1ZGUgImFz c3VyYW5jZSIgaW4gYSBERUNBREUuICBTaG91bGRuJ3QNCj4+Pj4gPj4gdGhlc2UgaW5zdGVhZCBi ZSBwYXJ0IG9mIFNMQXMgd2l0aCBhIHN0b3JhZ2UgcHJvdmlkZXI/ICBXaHkgc2hvdWxkDQo+Pj4+ ID4+IHRoZXkgYmUgREVDQURFJ3MgcmVzcG9uc2liaWxpdHk/DQo+Pj4+ID4+DQo+Pj4+ID4+IFJl Z2FyZGluZyAicmVzb3VyY2UgcmVzZXJ2YXRpb24iLCBhcmUgeW91IHJlZmVycmluZyB0byBhbiBh Y3R1YWwNCj4+Pj4gPj4gcmVzZXJ2YXRpb24gKHdoaWNoIG1pZ2h0IGJlIHByb2JsZW1hdGljIC0t IHNlZSBhYm92ZSkgb3IgZG8geW91IG1lYW4NCj4+Pj4gPj4gdGhhdCB0aGUgcmVzb3VyY2Ugc2hh cmUgc2hvdWxkIGFibGUgdG8gYmUgc3BlY2lmaWVkIGF0IHRoZSB0aW1lIHRoZQ0KPj4+PiA+PiBj b25uZWN0aW9uIG9wZW5zIGFuZCBiZSBhc3N1bWVkIHRvIGJlIHRoZSBzYW1lIGZvciB0aGUgZHVy YXRpb24gb2YgdGhlDQo+Pj4+ID4+IGNvbm5lY3Rpb24/DQo+Pj4+ID4+DQo+Pj4+ID4+IFJlZ2Fy ZGluZyBEeW5hbWljIEZlZWRiYWNrLCBpcyB0aGlzIG9ydGhvZ29uYWwgdG8gdGhlIHN0b3JhZ2UN Cj4+Pj4gPj4gcHJvdG9jb2w/ICBJdCBzZWVtcyBsaWtlIHdoYXQgeW91IHdhbnQgaGVyZSBpcyBh IGdlbmVyaWMgInN0YXR1cyINCj4+Pj4gPj4gc2VydmljZSBzYXlpbmcgaG93IGxvYWRlZCBhIHNl cnZlciBpcz8NCj4+Pj4gPj4NCj4+Pj4gPiB0aGF0cyByaWdodCwgYWN0dWFsbHksIHRoZSBmbG93 IGNvbnRyb2wgbWVjaGFuaXNtIHdhcyB1bmRlciBkaXNjdXNzaW9uDQo+Pj4+ID4gaW4gd3JpdGlu ZyB0aGUgZHJhZnQgYXQgZmlyc3QuIHdoYXQgYWJvdXQgeW91ciBvcGluaW9uIGluIHRoaXMNCj4+ Pj4gPiByZXF1aXJlbWVudHM/DQo+Pj4+ID4NCj4+Pj4NCj4+Pj4gSSdtIG5vdCBzdXJlIHdoYXQg dGhlIHR5cGljYWwgd2F5IG9mIHByb3ZpZGluZyBzdWNoICJsb2FkIHN0YXR1cyINCj4+Pj4gaW5m b3JtYXRpb24gZm9yIElFVEYgcHJvdG9jb2xzLCBidXQgbXkgaW5jbGluYXRpb24gaXMgdGhhdCBp dCBzaG91bGQNCj4+Pj4gbm90IGJlIGluIHRoZSBERUNBREUgcHJvdG9jb2wgaXRzZWxmLiAgTWF5 YmUgc29tZW9uZSBlbHNlIHdpdGggYQ0KPj4+PiBsb25nZXIgaGlzdG9yeSBpbiBJRVRGIGNvdWxk IGp1bXAgaW4gaGVyZSA6KQ0KPj4+IHNvIGNhbiBpIHVuZGVyc3RhbmQgdGhhdCAibG9hZCBzdGF0 dXMiIGlzIGtpbmQgb2YgbmVjZXNzaXR5ICBpbmZvcm1hdGlvbg0KPj4+IGZvciBERUNBREUgU2Vy dmVyLCBidXQgd2hlcmUgYW5kIHdobyBjb2xsZWN0cyB0aGUgaW5mb3JtYXRpb24gYXJlDQo+Pj4g cmVtYWluIGRpc2N1c3Npb24/DQo+Pg0KPj4gVGhlIHN0b3JhZ2UgcHJvdmlkZXIgaXMgZnJlZSB0 byBjb2xsZWN0IHRoZSBpbmZvcm1hdGlvbiB3aGVyZXZlciBhbmQNCj4+IGhvd2V2ZXIgdGhleSB3 aXNoLiAgVGhlIERFQ0FERSBzZXJ2ZXIgaW1wbGVtZW50YXRpb24gY291bGQgYWRkaXRpb25hbA0K Pj4gZXhwb3J0IHdoYXRldmVyIHN0YXR1cyBpbmZvcm1hdGlvbiBpdCB3aXNoZXMuIEkgZG9uJ3Qg dGhpbmsgdGhlIERFQ0FERQ0KPj4gcHJvdG9jb2wgbmVlZHMgdG8gYmUgY29uY2VybmVkIHdpdGgg dGhhdC4NCj4+DQo+PiBOb3RlIHRoYXQgY2VydGFpbiBlcnJvciBjb25kaXRpb25zIChlLmcuLCBv dmVybG9hZCwgaW5zdWZmaWNpZW50DQo+PiByZXNvdXJjZXMpIG1heSBiZSBzaWduYWxlZCBieSBh IERFQ0FERSBzZXJ2ZXIgKHRoZXJlIGFyZSBhbHJlYWR5IGhhdmUNCj4+IHJlcXVpcmVtZW50cyBm b3IgdGhvc2UpLiAgSWYgeW91IGFyZSByZWZlcnJpbmcgdG8gc3RhdHVzIGZvciBhIHVzZXIncw0K Pj4gcmVzb3VyY2VzLCB0aGVyZSBpcyBhbHJlYWR5IGEgcmVxdWlyZW1lbnQgZm9yIHRoYXQgdG9v Lg0KPj4NCj4+IEknbSBqdXN0IG5vdCBjb252aW5jZWQgdGhhdCB0aGUgREVDQURFIHByb3RvY29s IG5lZWRzIHRvIGV4cG9ydCBpdHMNCj4+IGN1cnJlbnQgbG9hZCBzdGF0dXMgdG8gY2xpZW50cy4N Cj4+DQo+PiBhY3R1YWxseSBpIGFtIG5vdCBzdXJlIHdoaWNoIGVsZW1lbnRzIGluIERFQ0FERSBu ZWVkcyB0aGUgbG9hZA0KPj4gc3RhdHVzLChERUNBREUgY2xpZW50IG9yIG5ldHdvcmsgc3RvcmFn ZSBpZiB0aGUgbmV0d29yayBzdG9yYWdlIG5lZWRzIHRvDQo+PiByZWRpcmVjdCB0aGUgcmVxdWVz dCBvciBib3RoPykuDQo+Pg0KPj4NCj4+DQo+PiBBbmQgdGhlIHJlcXVpcmVtZW50IGRyYWZ0IGN1 cnJlbnRseSBzZWVtcyBkZXNjcmliZSB0aGUgb3ZlcmxvYWQgY29uZGl0aW9uIGFzDQo+PiB0aGUg ZXZlbnQgdHJpZ2dlcmluZy4gZG8geW91IHRoaW5rIGlmIGl0IGlzIG5lY2Vzc2FyeSB0byBwZXJp b2RpY2FsbHkNCj4+IHJlcG9ydGluZyBvZiB0aGUgREVDQURFIG5ldHdvcmsgc3RhdHVzIHRvIGNs aWVudCBmb3IgaXRzIG5ldHdvcmsgc3RvcmFnZQ0KPj4gc2VsZWN0aW9uPw0KPj4NCj4+DQo+Pg0K Pj4gYW5kIHRoZSByZXF1aXJlbWVudCBkcmFmdCBqdXN0IGRlc2NyaWJlIERFQ0FERSB3aGljaCBp cyBidXN5IHRvIHNlcnZlIG90aGVyDQo+PiByZXF1ZXN0cyBtdXN0IGJlIGFibGUgdG8gcmVqZWN0 IHJlcXVlc3RzLCBub3QgY29uc2lkZXIgaG93IHRvIGhhbmRsZSB0aGUNCj4+IHVzZXIgcmVxdWVz dCBhZnRlciBiZWluZyByZWplY3RlZD8NCj4+DQo+Pj4+ID4+DQo+Pj4+ID4+IERhdGEgY2xhc3Np ZmljYXRpb246DQo+Pj4+ID4+DQo+Pj4+ID4+IFdvdWxkIGl0IGJlIGJldHRlciB0byBpbnN0ZWFk IGhhdmUgdGhlIGNsaWVudCBzcGVjaWZ5IHByb3BlcnRpZXMgb2YNCj4+Pj4gPj4gdGhlIGNvbnRl bnQgaW5zdGVhZCBvZiBwbGFjZSBpdCBpbnRvID8gU2VlDQo+Pj4+ID4+IHd3dy5pZXRmLm9yZy9w cm9jZWVkaW5ncy83OC9zbGlkZXMvbmZzdjQtMC5wZGY8aHR0cDovL3d3dy5pZXRmLm9yZy9wcm9j ZWVkaW5ncy83OC9zbGlkZXMvbmZzdjQtMC5wZGY+IGZvciBhbiBleGFtcGxlIG9mIHRoaXMNCj4+ Pj4gPj4gYXBwcm9hY2ggZm9yIE5GUy4NCj4+Pj4gPj4NCj4+Pj4gPj4gSSB0aGluayBhIHByb2Js ZW0gd2l0aCBjbGFzc2lmeWluZyBhcHBsaWNhdGlvbnMgaXMgdGhhdCBpdCBhc3N1bWVzDQo+Pj4+ ID4+IHRoYXQgYXBwbGljYXRpb25zIGZpdCBvbmUgb2YgdGhlIHN1cHBsaWVkIGNsYXNzaWZpY2F0 aW9ucy4gV2hhdCBpZiBpdA0KPj4+PiA+PiBtYXkgZml0IG11bHRpcGxlIGNsYXNzaWZpY2F0aW9u cz8gb3Igbm9uZT8gIEFub3RoZXIgcHJvYmxlbSBpcyBpdA0KPj4+PiA+PiBhc3N1bWVzIHRoYXQg c2VydmVycyBhc3N1bWUgYmFzZWQgb24gaW5kaXJlY3QgYW5kIGFzc3VtZWQgaW5mb3JtYXRpb24N Cj4+Pj4gPj4gdGhhdCB0aGV5IGtub3cgd2hhdCB0byBkbyB3aXRoIGEgcGFydGljdWxhciBwaWVj ZSBvZiBjb250ZW50LiBXaHkgbm90DQo+Pj4+ID4+IGhhdmUgYW4gYXBwbGljYXRpb24gc3BlY2lm eSBpdHMgZGVzaXJlcyBkaXJlY3RseT8NCj4+Pj4gPj4NCj4+Pj4gPg0KPj4+PiA+DQo+Pj4+ID4+ DQo+Pj4+ID4+IFNtYWxsIE9iamVjdHM6DQo+Pj4+ID4+DQo+Pj4+ID4+IFdoYXQgaXMgdGhlIG5l dyByZXF1aXJlbWVudCBoZXJlPyAgV2h5IGlzIHRoZSBleGlzdGluZyByZXF1aXJlbWVudCBpbg0K Pj4+PiA+PiBkcmFmdC1pZXRmLWRlY2FkZS1yZXFzLTAwIGluc3VmZmljaWVudD8NCj4+Pj4gPj4N Cj4+Pj4gPj4gVGhpcyBhbHNvIGhhcyBtZSBhIGJpdCB3b3JyaWVkOg0KPj4+PiA+PiAiQW5kIHRo ZSBpbi1uZXR3b3JrIHN0b3JhZ2UgaGFzIHRoZSBsaW1pdGVkIHN0b3JhZ2UgY2FwYWNpdHksIHdp dGggdGhlDQo+Pj4+ID4+IGFycml2YWwgb2YgdXNlciByZXF1ZXN0cyBhbmQgZGF0YSBkaXN0cmli dXRpb24gcmVxdWlyZW1lbnRzLCB0aGUgZGF0YQ0KPj4+PiA+PiBzdG9yZWQgaW4gdGhlIGluLW5l dHdvcmsgc3RvcmFnZSB3aWxsIGJlIHJlcGxhY2VkIGlmIHRoZSBzdG9yYWdlDQo+Pj4+ID4+IHJl YWNoZXMgdGhlIGxpbWl0IGFuZCBkYXRhIGFycml2YWxzIGNvbnRpbnVhbGx5LiINCj4+Pj4gPj4N Cj4+Pj4gPj4gSG93IGRvZXMgdGhlIHNlcnZlciBrbm93IHdoYXQgdGhlIHByb3BlciByZXBsYWNl bWVudCBzdHJhdGVneSBpcyBmb3INCj4+Pj4gPj4gYW4gYXBwbGljYXRpb24/IEkgdGhpbmsgREVD QURFJ3MgcGhpbG9zb3BoeSBpcyB0aGF0IGFwcGxpY2F0aW9ucw0KPj4+PiA+PiBzaG91bGQgZGVj aWRlIHRoaXMuIEEgc2ltcGxlIHdheSB0byBkbyB0aGlzIGlzIGV4cGxpY2l0IGRlbGV0aW9uIGJ5 IGFuDQo+Pj4+ID4+IGFwcGxpY2F0aW9uLCBidXQgcGVyaGFwcyBhIG1vcmUgZWZmaWNpZW50ICh5 ZXQgbW9yZSBjb21wbGV4KSBzb2x1dGlvbg0KPj4+PiA+PiBpcyBmb3IgYW4gYXBwbGljYXRpb24g dG8gc3BlY2lmeSB0aGUgcmVwbGFjZW1lbnQgcG9saWN5IHRvIHRoZSBzZXJ2ZXIuDQo+Pj4+ID4+ DQo+Pj4+ID4gYWN0dWFsbHksIHRoZSBrZXkgaW4gInRoZSBkYXRhIGNsYXNzaWZpY2F0aW9uIGFu ZCBzbWFsbCBvYmplY3RzICIgaXMNCj4+Pj4gPiB3aGV0aGVyIGRvZXMgaXQgb3Igbm90IGluIFAy UCBhcHBsaWNhdGlvbj8gaSBkaWQgbm90IGZpbmQgZGF0YQ0KPj4+PiA+IGNsYXNzaWZpY2F0aW9u IHdhcyBhZG9wdGVkIGluIFAyUCBhcHBsaWNhdGlvbiBzbyBmYXIsIGxldCBhbG9uZSBERUNBREUN Cj4+Pj4gPiBuZWVkDQo+Pj4+ID4gdG8gY2xhc3NpZnkgdGhlIGRhdGEgdXNlZCBpbiBhbGwga2lu ZHMgb2YgYXBwbGljYXRpb24uDQo+Pj4+ID4NCj4+Pj4NCj4+Pj4gU28sIGRvIHlvdSBhZ3JlZSB0 aGF0IGl0IGlzIHByb2JsZW1hdGljIHRvIHRyeSBhbmQgY2xhc3NpZnkgZWFjaCB0eXBlDQo+Pj4+ IG9mIGFwcGxpY2F0aW9uIGFuZCB0cnkgdG8gc3BlY2lmeSB0aGUgdHlwaWNhbCB3b3JrbG9hZCBm b3IgZWFjaCBjbGFzcz8NCj4+Pj4NCj4+Pj4gTXkgcG9pbnQgd2FzIHRoYXQgSSBkb24ndCB0aGlu ayBpdHMgbmVjZXNzYXJ5IHRvIGRvIHRoZSBjbGFzc2lmaWNhdGlvbg0KPj4+PiBhdCBhbGwuICBJ dCBpcyBtb3JlIGV4dGVuc2libGUgKGFuZCBkaXJlY3RseSB1c2VmdWwpIGZvciBhIHNlcnZlciB0 bw0KPj4+PiBqdXN0IGdpdmUgaXQgZGlyZWN0IGhpbnRzIGFib3V0IHdoYXQgd291bGQgYmUgcHJl ZmVyYWJsZS4NCj4+Pg0KPj4+IHllcCwgaSBiZWxpZXZlIGl0IG1heSBiZSBhIGxpdHRsZSBkaWZm aWN1bHQsIGJ1dCB3b3J0aHkgZG9pbmcuIHNwZWNpYWxseQ0KPj4+IGZvciBpbXByb3ZpbmcgdGhl IHJlc291cmNlIHV0aWxpemF0aW9uIHdpdGhpbiBhIHNpbmdsZSBzZXJ2ZXIgYW5kIHJlZHVjaW5n DQo+Pj4gdGhlIHJlc3BvbnNlIHRpbWUgZm9yIGNsaWVudC4gd2hhdCBhYm91dCBvdGhlcnMgb3Bp bmlvbj8NCj4+DQo+PiBDYW4geW91IGp1c3RpZnkgd2h5IGdpdmluZyBjbGFzc2lmaWNhdGlvbnMg KGUuZy4sICJJJ20gYSBsaXZlDQo+PiBzdHJlYW1pbmcgYXBwbGljYXRpb24iKSB3b3VsZCBiZSBi ZXR0ZXIgdGhhbiBnaXZpbmcgc3BlY2lmaWMgaGludHMNCj4+IChlLmcuLCAicGxlYXNlIGRvbid0 IGJvdGhlciBwZXJzaXN0ZW50IHRoZXNlIG9iamVjdHMgdG8gZGlzayIpPw0KPj4NCj4+IGkgbWVh biBkYXRhIGluIGRpZmZlcmVudCBraW5kIG9mIG9wZXJhdGlvbiBtb2RlIGFuZCBhdHRyaWJ1dGUg c2hvdWxkIGhhdmUNCj4+IGRpZmZlcmVudCB1c2VyIHBhdHRlcm5zIGFuZCBzdG9yYWdlIHJ1bGVz LCB3aGljaCBtYXkgYmUgaGVscCB0byBpbXByb3ZlIHRoZQ0KPj4gcmVzb3VyY2UgdXRpbGl6YXRp b24gYW5kIHJlZHVjZSB0aGUgcmVzcG9uc2UgdGltZSBmb3IgcmVxdWVzdCwgd2hhdCBhcmUgeW91 DQo+PiB1bmRlcnN0YW5kaW5nPw0KPj4+ID4+DQo+Pj4+ID4+IFJlbW92YWwgb2YgRXhwaXJlZCBS ZWNvcmRzOg0KPj4+PiA+Pg0KPj4+PiA+PiAiSG93ZXZlciwgdGhlIHR3byBzY2VuYXJpb3MgZGlk IG5vdCBtZW50aW9uIGhvdyB0byBoYW5kbGUgdGhlIG9sZA0KPj4+PiA+PiByZXNvdXJjZSBpZiB0 aGUgdXNlciBkaXN0cmlidXRlcyB0aGUgbmV3IHJlc291cmNlIHdoaWNoIGlzIGFuIHVwZGF0ZWQN Cj4+Pj4gPj4gY29weSBvZiB0aGUgb2xkIHJlc291cmNlLiINCj4+Pj4gPj4NCj4+Pj4gPj4gV2h5 IGRvZXMgdGhpcyBuZWVkIHRvIGJlIGhhbmRsZWQgaW4gdGhlIHJlcXVpcmVtZW50cz8gIEFyZSB5 b3UgdHJ5aW5nDQo+Pj4+ID4+IHRvIGRyYXcgdGhlIGRpc3RpbmN0aW9uIGJldHdlZW4gaW1tZWRp YXRlIGRlbGV0aW9uIG9mIGNvbnRlbnQgYW5kIGxhenkNCj4+Pj4gPj4gZGVsZXRpb24/DQo+Pj4+ ID4+DQo+Pj4+ID4gaSBtZWFuIHRoZSBtZWFuaW5nIG9mIGRlbGV0ZSBvcGVyYXRpb24gYW5kIGhv dyB0byBoYW5kbGUgdGhlIGV4cGlyZWQNCj4+Pj4gPiByZWNvcmRzIG5lZWQgdG8gYmUgY2xhcmlm eSBpbiByZXF1aXJlbWVudHMuDQo+Pj4+DQo+Pj4+IE15IGluY2xpbmF0aW9uIGlzIHRoYXQgImRl bGV0ZWQiIG1lYW5zIHRoYXQgb3RoZXIgcmVxdWVzdHMgdGhlIG9iamVjdA0KPj4+PiBvZiB0aGUg c2FtZSBuYW1lIHNob3VsZCByZXN1bHQgYW4gZXJyb3IsIHVudGlsIGFub3RoZXIgb2JqZWN0IHdp dGggdGhlDQo+Pj4+IHNhbWUgbmFtZSBpcyBzdG9yZWQuDQo+Pj4NCj4+PiBva2F5LCB1bmRlciB0 aGUgc2NlbmFyaW8gImNsaWVudCB1cGxvYWRzIHRoZSBuZXcgdmVyc2lvbiwgYW5kIGRpZCBub3QN Cj4+PiBzcGVjaWZ5IGhvdyB0byBoYW5kbGUgdGhlIG9sZCB2ZXJzaW9uIiwgZGlkIERFQ0FERSBz ZXJ2ZXIgZGVsZXRlIHRoZSBvbGRlcg0KPj4+IHZlcnNpb24gKG9yIGp1c3QgbGFiZWwgaXQgdW5h dmFpbGFibGUsIGFueXdheSwgaXQgaXMgaW1wbGVtZW50YXRpb24gaXNzdWUNCj4+PiApDQo+Pj4g b3Igbm90ID8gaW4gYW5vdGhlciB3b3JkLCBqdXN0IHJlcGxhY2UgdGhlIG9sZGVyIHZlcnNpb24g d2l0aCB0aGUgbmV3DQo+Pj4gdmVyc2lvbiB3aXRoIHRoZSBzYW1lIG5hbWU/DQo+Pg0KPj4gSW4g dGhpcyBjYXNlLCBJIHdvdWxkIHRoaW5rIHRoZSAid3JpdGUiIG9mIHRoZSBuZXcgb2JqZWN0IHNo b3VsZCBiZQ0KPj4gcmVqZWN0ZWQsIG9yIGlmIGRlc2lyZWQsIHdlIGNvdWxkIGhhdmUgYW4gb3Zl cndyaXRlIG9wdGlvbi4gIFRoaXMNCj4+IGNvdWxkIGJlIGFkZGVkIHRvIHRoZSByZXF1aXJlbWVu dHMgaWYgaXQgaGVscHMgdG8gY2xhcmlmeS4NCj4+DQo+PiB5ZXAsIG5vIG1hdHRlciB3aGljaCBz b2x1dGlvbiBpcyBjaG9zZW4sIGxldCB0aGUgdW5kZXJzdGFuZGluZyB1bmFuaW1vdXNseTpEDQo+ Pj4gaG93IHRvIGhhbmRsZSB0aGUgb2xkZXIgdmVyc2lvbiB3aGljaCBpcw0KPj4+IHRyYW5zZmVy cmluZyBmcm9tIHNlcnZlciB0byBjbGllbnQ/DQo+Pg0KPj4gSSB0aGluayBpdCB3b3VsZCBiZSBj bGVhbmVyIHRvIGFzayB0aGUgc2VydmVyIHRvIGNvbnRpbnVlIHNlbmRpbmcgYW4NCj4+IG9iamVj dCBvbmNlIGl0IGhhcyBiZWVuIHN0YXJ0ZWQsIGJ1dCB1bHRpbWF0ZWx5IHRoaXMgd291bGQgYmUg dGhlDQo+PiBkZWNpc2lvbiBvZiB0aGUgc2VydmVyJ3MgaW1wbGVtZW50YXRpb24gSSB0aGluay4g IE1heWJlIGEgIlNIT1VMRCINCj4+IHJlcXVpcmVtZW50LiAgVGhpcyBjb3VsZCBiZSBhZGRlZCBp ZiBkZXNpcmVkLg0KPj4NCj4+IFRoYW5rIHlvdSBmb3IgdGhlc2UgcXVlc3Rpb25zLiAgSXQgaGVs cHMgZGVzaWduIHRoZSByZXF1aXJlbWVudHMgbW9yZQ0KPj4gY2xlYW5seSBpZiB0aGVyZSBhcmUg c3BlY2lmaWMgc2NlbmFyaW9zIGluIGZyb250IG9mIHVzIDopDQo+PiBqdXN0IGRpc2N1c3Npb24g dG9nZXRoZXI6RCBhbmQgYWxzbyB0aGFua3MgZm9yIHlvdXIgcG9pbnRzIHRvIGhlbHAgbWUNCj4+ IHVuZGVyc3RhbmRpbmcgbW9yZSENCj4+IFJpY2gNCj4+DQo+Pj4+IEkgdGhpbmsgdGhhdCB0aGUg dGltZSB0aGUgZGF0YSBpcyByZW1vdmVkIGZyb20gZGlzayAob3IgbWVtb3J5KSBzaG91bGQNCj4+ Pj4gYmUgdXAgdG8gdGhlIGltcGxlbWVudGF0aW9uLiBBIHN0b3JhZ2UgcHJvdmlkZXIgbWlnaHQg c3RpbGwgaGF2ZSBhcw0KPj4+PiBwYXJ0IG9mIHNvbWUgYWdyZWVtZW50IHRoYXQgZGVsZXRlZCBk YXRhIHdpbGwgYmUgcmVtb3ZlZCB3aXRoaW4gWA0KPj4+PiBkYXlzL2hvdXJzL21pbnV0ZXMvd2hh dGV2ZXIuDQo+Pj4NCj4+PiAgICBhZ3JlZSB3aXRoIHlvdS4NCj4+Pj4NCj4+Pj4gSWYgcGVvcGxl IGluIHRoZSBXRyB0aGluayBpdCBpcyBuZWNlc3NhcnksIHdlIGNvdWxkIGhhdmUgYSByZXF1aXJl bWVudA0KPj4+PiB0aGF0IHNheXMgdGhlIHByb3RvY29sIHNob3VsZCBzdXBwb3J0IGFuIGFyZ3Vt ZW50IGluZGljYXRpbmcgaW1tZWRpYXRlDQo+Pj4+IGRlbGV0aW9uLCBidXQgaXQgaXMgbm90IGNs ZWFyIHRoYXQgd2UgbmVlZCB0aGlzLg0KPj4+Pg0KPj4+PiBSaWNoDQo+Pj4+DQo+Pj4+ID4+DQo+ Pj4+ID4+IFRoYW5rcyENCj4+Pj4gPj4gUmljaA0KPj4+PiA+Pg0KPj4+PiA+Pg0KPj4+PiA+PiBP biBNb24sIERlYyAyNywgMjAxMCBhdCAxMjo1NyBBTSwg1uzk7CA8YnVwdHhpYW96aHVAZ21haWwu Y29tPG1haWx0bzpidXB0eGlhb3podUBnbWFpbC5jb20+PiB3cm90ZToNCj4+Pj4gPj4gPiBEZWFy IGFsbCwNCj4+Pj4gPj4gPg0KPj4+PiA+PiA+IFRoZXJlIGlzIGEgc2xpZ2h0bHkgdXBkYXRlZCB2 ZXJzaW9uIG9mIHRoZSBkZWNhZGUgYWRkaXRpb25hbA0KPj4+PiA+PiA+IHJlcXVpcmVtZW50cw0K Pj4+PiA+PiA+IGRyYWZ0Lg0KPj4+PiA+PiA+DQo+Pj4+ID4+ID4NCj4+Pj4gPj4gPiBodHRwczov L2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC16aHUtZGVjYWRlLWFkZGl0aW9uYWwtcmVx dWlyZW1lbnRzLw0KPj4+PiA+PiA+DQo+Pj4+ID4+ID4gSmluIFBlbmcsIFl1bmZlaSBaaGFuZyBh bmQgbWUgYXJlIGV4cGVjdGluZyB0byBoYXZlIGEgZGlzY3Vzc2lvbg0KPj4+PiA+PiA+IHdpdGgN Cj4+Pj4gPj4gPiBhbGwgb2YNCj4+Pj4gPj4gPiB5b3UuDQo+Pj4+ID4+ID4NCj4+Pj4gPj4gPiBB bnkgY29tbWVudHMgYXJlIGFwcHJlY2lhdGVkIQ0KPj4+PiA+PiA+DQo+Pj4+ID4+ID4gQSBuZXcg dmVyc2lvbiBvZiBJLUQsDQo+Pj4+ID4+ID4gZHJhZnQtemh1LWRlY2FkZS1hZGRpdGlvbmFsLXJl cXVpcmVtZW50cy0wMC50eHQNCj4+Pj4gPj4gPiBoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0 dGVkIGJ5IFhpYW8gWmh1IGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYNCj4+Pj4gPj4gPiByZXBvc2l0 b3J5Lg0KPj4+PiA+PiA+DQo+Pj4+ID4+ID4gRmlsZW5hbWU6ICAgICAgZHJhZnQtemh1LWRlY2Fk ZS1hZGRpdGlvbmFsLXJlcXVpcmVtZW50cw0KPj4+PiA+PiA+IFJldmlzaW9uOiAgICAgIDAwDQo+ Pj4+ID4+ID4gVGl0bGU6ICAgICAgICAgICAgICAgICBBZGRpdGlvbmFsIHByb3RvY29sIHJlcXVp cmVtZW50cyBvbiBERUNBREUNCj4+Pj4gPj4gPiBDcmVhdGlvbl9kYXRlOiAgICAgICAgIDIwMTAt MTItMjcNCj4+Pj4gPj4gPiBXRyBJRDogICAgICAgICAgICAgICAgIEluZGVwZW5kZW50IFN1Ym1p c3Npb24NCj4+Pj4gPj4gPiBOdW1iZXJfb2ZfcGFnZXM6IDEwDQo+Pj4+ID4+ID4NCj4+Pj4gPj4g PiBBYnN0cmFjdDoNCj4+Pj4gPj4gPiBUaGUgREVDb3VwbGVkIEFwcGxpY2F0aW9uIERhdGEgRW5y b3V0ZShERUNBREUpd29ya2luZyBncm91cCBpcw0KPj4+PiA+PiA+IHNwZWNpZnlpbmcgc3RhbmRh cmRpemVkIGludGVyZmFjZXMgZm9yIGFjY2Vzc2luZyBpbi1uZXR3b3JrIHN0b3JhZ2UNCj4+Pj4g Pj4gPiBmcm9tIGFwcGxpY2F0aW9ucyB0byBzdG9yZSwgcmV0cmlldmUgYW5kIG1hbmFnZSBkYXRh LiBUaGUgbWFpbg0KPj4+PiA+PiA+IG9iamVjdA0KPj4+PiA+PiA+IGlzIHRvIHByb3ZpZGUgYSBm cmFtZXdvcmsgdGhhdCBpcyB1c2VmdWwgdG8gdGhlIGFwcGxpY2F0aW9ucywNCj4+Pj4gPj4gPiBp bmNsdWRpbmcgUDJQIGFwcGxpY2F0aW9ucyBhbmQgb3RoZXIgZGF0YS1vcmllbnRlZCBhcHBsaWNh dGlvbnMsDQo+Pj4+ID4+ID4gcG9zc2libHkgcmVsYXRlZCBhcHBsaWNhdGlvbnMgdGhhdCBjYW4g YmVuZWZpdCBmcm9tIGFjY2Vzc2luZyBpbi0NCj4+Pj4gPj4gPiBuZXR3b3JrIHN0b3JhZ2UuIFRo aXMgbWVtbyBmb2N1c2VzIG9uIHNvbWUgcmVxdWlyZW1lbnRzIHN1Y2ggYXMNCj4+Pj4gPj4gPiBy ZXF1ZXN0IHJlZGlyZWN0aW5nIGFuZCBzbyBvbiB3aGljaCBhcmUgb24gdGhlIGNlbnRyYWwgb2Yg bW9iaWxpdHksDQo+Pj4+ID4+ID4gd2lyZWxlc3MgbmV0d29yayBlbnZpcm9ubWVudCBhbmQgQ0RO IGFwcGxpY2F0aW9uLiBXZSBwcmVzZW50IHRoZXNlDQo+Pj4+ID4+ID4gaW4NCj4+Pj4gPj4gPiB0 aGlzIG1lbW8gYXMgYWRkaXRpb25hbCByZXF1aXJlbWVudHMgdGhhdCBzaG91bGQgYmUgY29uc2lk ZXJlZCBmb3INCj4+Pj4gPj4gPiB0aGUgREVDQURFIGFyY2hpdGVjdHVyZSBhbmQgcHJvdG9jb2wg c3BlY2lmaWNhdGlvbnMuDQo+Pj4+ID4+ID4NCj4+Pj4gPj4gPg0KPj4+PiA+PiA+DQo+Pj4+ID4+ ID4gVGhlIElFVEYgU2VjcmV0YXJpYXQuDQo+Pj4+ID4+ID4NCj4+Pj4gPj4gPiAtLQ0KPj4+PiA+ PiA+IEJlc3Qgd2lzaGVzLA0KPj4+PiA+PiA+DQo+Pj4+ID4+ID4gQmVpamluZyBVbml2ZXJzaXR5 IG9mIFBvc3RzICYgVGVsZWNvbW11bmljYXRpb25zIChCVVBUKQ0KPj4+PiA+PiA+IFpodSBYaWFv ICAoINbs5OwgKQ0KPj4+PiA+PiA+IEUtbWFpbDogYnVwdHhpYW96aHVAZ21haWwuY29tPG1haWx0 bzpidXB0eGlhb3podUBnbWFpbC5jb20+DQo+Pj4+ID4+ID4gbW9iaWxlOis4NiAxMzQtODg4MS05 MDA0DQo+Pj4+ID4+ID4NCj4+Pj4gPj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KPj4+PiA+PiA+IGRlY2FkZSBtYWlsaW5nIGxpc3QNCj4+Pj4gPj4g PiBkZWNhZGVAaWV0Zi5vcmc8bWFpbHRvOmRlY2FkZUBpZXRmLm9yZz4NCj4+Pj4gPj4gPiBodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RlY2FkZQ0KPj4+PiA+PiA+DQo+Pj4+ ID4+ID4NCj4+Pj4gPg0KPj4+PiA+DQo+Pj4+ID4NCj4+Pj4gPiAtLQ0KPj4+PiA+IEJlc3Qgd2lz aGVzLA0KPj4+PiA+DQo+Pj4+ID4gQmVpamluZyBVbml2ZXJzaXR5IG9mIFBvc3RzICYgVGVsZWNv bW11bmljYXRpb25zIChCVVBUKQ0KPj4+PiA+IFpodSBYaWFvICAoINbs5OwgKQ0KPj4+PiA+IEUt bWFpbDogYnVwdHhpYW96aHVAZ21haWwuY29tPG1haWx0bzpidXB0eGlhb3podUBnbWFpbC5jb20+ DQo+Pj4+ID4gbW9iaWxlOis4NiAxMzQtODg4MS05MDA0DQo+Pj4NCj4+Pg0KPj4+DQo+Pj4gLS0N Cj4+PiBCZXN0IHdpc2hlcywNCj4+Pg0KPj4+IEJlaWppbmcgVW5pdmVyc2l0eSBvZiBQb3N0cyAm IFRlbGVjb21tdW5pY2F0aW9ucyAoQlVQVCkNCj4+PiBaaHUgWGlhbyAgKCDW7OTsICkNCj4+PiBF LW1haWw6IGJ1cHR4aWFvemh1QGdtYWlsLmNvbTxtYWlsdG86YnVwdHhpYW96aHVAZ21haWwuY29t Pg0KPj4+IG1vYmlsZTorODYgMTM0LTg4ODEtOTAwNA0KPj4+DQo+Pg0KPj4NCj4+IC0tDQo+PiBC ZXN0IHdpc2hlcywNCj4+DQo+PiBCZWlqaW5nIFVuaXZlcnNpdHkgb2YgUG9zdHMgJiBUZWxlY29t bXVuaWNhdGlvbnMgKEJVUFQpDQo+PiBaaHUgWGlhbyAgKCDW7OTsICkNCj4+IEUtbWFpbDogYnVw dHhpYW96aHVAZ21haWwuY29tPG1haWx0bzpidXB0eGlhb3podUBnbWFpbC5jb20+DQo+PiBtb2Jp bGU6Kzg2IDEzNC04ODgxLTkwMDQNCj4NCg0KDQotLQ0KQmVzdCB3aXNoZXMsDQoNCkJlaWppbmcg VW5pdmVyc2l0eSBvZiBQb3N0cyAmIFRlbGVjb21tdW5pY2F0aW9ucyAoQlVQVCkNClpodSBYaWFv ICAoINbs5OwgKQ0KRS1tYWlsOiBidXB0eGlhb3podUBnbWFpbC5jb208bWFpbHRvOmJ1cHR4aWFv emh1QGdtYWlsLmNvbT4NCm1vYmlsZTorODYgMTM0LTg4ODEtOTAwNA0KDQoNCg0KLS0NCkJlc3Qg d2lzaGVzLA0KDQpCZWlqaW5nIFVuaXZlcnNpdHkgb2YgUG9zdHMgJiBUZWxlY29tbXVuaWNhdGlv bnMgKEJVUFQpDQpaaHUgWGlhbyAgKCDW7OTsICkNCkUtbWFpbDogYnVwdHhpYW96aHVAZ21haWwu Y29tPG1haWx0bzpidXB0eGlhb3podUBnbWFpbC5jb20+DQptb2JpbGU6Kzg2IDEzNC04ODgxLTkw MDQNCg== --_000_1CA25301D2219F40B3AA37201F0EACD1135A2B0FPACDCEXMB05cabl_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Xiao,

 

My personal preference would be to let draft-zhu-decade-ad= ditional-requirements expire, and ensure that the key requirements from you= r draft are reflected in draft-ietf-decade-reqs which is the official WG draft.

 

Do you have objections about how your requirements were re= flected in draft-ietf-decade-reqs?

 

-- Rich

 

From: =D6=EC=E4=EC<= span style=3D"font-size:10.0pt; font-family:"Tahoma","sans-serif""> [mailto:buptxiaozhu= @gmail.com]
Sent: Monday, June 27, 2011 10:23 PM
To: Richard Alimi
Cc: Woundy, Richard; decade@ietf.org
Subject: Re: [decade] draft-zhu-decade-additional-requirements<= /o:p>

 

hi, Richard and everybody

 

The draft draft-zhu-decade-additional-requir= ements I submitted last year is about to expire. do you have some suggestio= ns to update the version? and do the DECADE requirement draft has adopted some suggestions of my draft?

 

2011/6/27 =D6=EC=E4=EC &= lt;buptxiaozhu@gmail.com>

hi, Richard and everybody

 

The draft draft-zhu-decade-additional-requir= ements I submitted last year is about to expire. do you have some suggestio= ns to update the version? and do the DECADE requirement draft has adopted some suggestions of my draft?

 

2011/3/14 Richard Alimi <rich@velvetsea.net>

Hi All,

We've made all of these updates to the requirements document, with the
exception of:

> - If an object is deleted as it is concurrently being read, then the > server MAY continue to read it (lazy deletion), or it MAY discontinue<= br> > reading the object and signal an error to the client reading the
> object.

Upon looking at this again, it looks more like an implementation
detail. If anything, this would result in a "non-requirement" in = the
document. However, it seems like a fairly low-level non-requirement to
state at this time. I'd propose to leave it out for now and revisit
this if it comes up again in the future.  Thoughts?

Thanks,
Rich

2011/3/2 Richard Alimi <rich@velvetsea.net>:
> Hi All,
>
> I'll offer a summary of this discussion. Let me know if I missed
> anything, or if there are objections/other thoughts on these proposed<= br> > resolutions.
>
> Redirection:
> - We can add a requirement mentioning that DECADE may support redirect= ion.
>
> Data Classification:
> - I (personally) strongly disagree with attempting to classify access<= br> > patterns or applications. We could add something saying that explicit<= br> > hints (a la www.ietf.org/proceedings/78/slides/nfsv4-0.pdf) could be
> provided in DECADE.  However, I don't think we need to do some= thing
> new here. In particular, if the underlying storage/data transport
> supports hints, a DECADE client or server can use it.
>
> Storage Status:
> - Update section 5.1.6 to indicate that status information should
> include permissions of stored objects, if applicable.
> - Update 5.1.6 to indicate that status information should include
> other information about resource usage (the clients own resources, or<= br> > resources used by other clients that have been authorized to
> read/write objects or open connections to one's storage).
>
> Requirements for object deletion/overwriting:
> - DECADE MAY have an overwrite flag (note that this may or may not be<= br> > necessary depending on our naming, but the requirements document
> probably is not the place to take a stand on this at the current
> point.)
> - If an object is deleted as it is concurrently being read, then the > server MAY continue to read it (lazy deletion), or it MAY discontinue<= br> > reading the object and signal an error to the client reading the
> object.
>
> Would this be sufficient to merge in the points from
> draft-zhu-decade-additional-requirements-00 and this ensuing
> discussion?
>
> Thanks,
> Rich
>
>
> 2011/3/2 Woundy, Richard <Richard_Woundy@cable.comcast.com>:
>> Folks,
>>
>>
>>
>> Do we have consensus yet about how the WG could have a single DECA= DE
>> requirements document going forward? I can't tell the state of our=
>> requirements consolidation from the email thread below.
>>
>>
>>
>> It would be preferable if we could resolve this fully on the WG ma= iling
>> list, but this is important enough to allocate some time at our me= eting in
>> Prague.
>>
>>
>>
>> -- Rich
>>
>>
>>
>> From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.org] On Behalf Of
>> ??
>> Sent: Sunday, January 16, 2011 9:02 PM
>> To: Richard Alimi
>> Cc: decade@ie= tf.org
>> Subject: Re: [decade] draft-zhu-decade-additional-requirements

>>
>>
>>
>> hi, Richard:
>>
>>
>>
>> thanks for your reply:D
>>
>> additional discussion see inline:D
>>
>>
>>
>> 2011/1/14 Richard Alimi <rich@velvetsea.net>
>>
>> HI Xiao,
>>
>> 2011/1/12 =D6=EC=E4=EC <buptxiaozhu@gmail.com&g= t;:
>>
>>> hi, Richard
>>> see inline:D
>>>
>>> 2011/1/11 Richard Alimi <rich@velvetsea.net>
>>>>
>>>> Hi Xiao,
>>>>
>>>> On Mon, Jan 10, 2011 at 6:45 PM, =D6= =EC=E4=EC <buptxiaozhu@gmail.com> wrote:
>>>> >
>>>> > hi, Richard, sorry for so late response because of be= busy with other
>>>> > projects.
>>>> > some discussion see inline:D marked by red.
>>>> >
>>>> > On Tue, Jan 4, 2011 at 4:06 AM, Richard Alimi <rich@velvetsea.net= >
>>>> > wrote:
>>>> >>
>>>> >> Hi Xiao,
>>>> >>
>>>> >> Thank you for the draft.  Some comments on the requirements:
>>>> >>
>>>> >> Request Redirects:
>>>> >>
>>>> >> This would provide some additional freedom for th= e storage provider.
>>>> >> I think it is reasonable since it doesn't necessi= tate additional
>>>> >> complexity for the DECADE server, but allows it i= f desired. However,
>>>> >> note that it may complicate some of the other com= ponents of the
>>>> >> design. In particular, if there is a per-user quo= ta for storage, is
>>>> >> the user made aware of the quota at each in-netwo= rk storage (if there
>>>> >> is no shared storage between them)?  Resource sharing policies may be
>>>> >> impacted (e.g., if a bandwidth sharing weight of = 1 may mean something
>>>> >> different at DECADE server A than it does at DECA= DE server B).  At
>>>> >> this point it may be best to just note these so t= hey are documented,
>>>> >> but since the specification of the resource shari= ng policies are still
>>>> >> being contemplated for the basic case of a single= server it may be
>>>> >> premature to even try and solve them for the case= supporting
>>>> >> redirection.
>>>> >>
>>>> > actually, you mean two points, right?
>>>> > 1. whether or not to be ware of the content at each i= n-network storage
>>>> > and of course resource sharing policies can be impact= in the request
>>>> > redirection. your suggestion"just to note these = so they are documented"
>>>> > will
>>>> > be ok, or DECADE server list with some parameters wil= l be return for
>>>> > user to
>>>> > select the appropriate DECADE server, which can avoid= the different
>>>> > weighted
>>>> > of the same parameter in server decision. but the par= ameter used in
>>>> > select
>>>> > the best DECADE server will be known for DECADE serve= rs, in which other
>>>> > complexities will be added. anyway, all the solution = are the
>>>> > implementation
>>>> > issue, which, i believe, does not impact the necessit= y of the
>>>> > requirement.
>>>>
>>>> In general, I'd agree that the decision about where to red= irect would
>>>> be an implementation issue.
>>>>
>>>> >
>>>> > 2. you mean "the resource sharing policies are s= till being considered
>>>> > in
>>>> > a single server", so it may be premature to supp= ort redirection.  the
>>>> > architecture and protocol will be badly impacted if t= he requirements
>>>> > change.
>>>> > so the designing can be  taken &nbs= p;step by step, but the requirements
>>>> > should be
>>>> > overall considered.
>>>>
>>>> I said that it is probably premature to consider how resou= rce sharing
>>>> policies works across servers (or even if we need to say a= nything
>>>> about it) since we have not determined how to specify them= (or rather,
>>>> how little we need to specify in protocol) for a single se= rver. I did
>>>> not mean to imply that redirection could not be introduced= as a
>>>> requirement.
>>>>
>>>
>>>>
>>>> >
>>>> >
>>>> >>
>>>> >> Multi-connection:
>>>> >>
>>>> >> I'm not quite clear on the intention of the requi= rement.  My
>>>> >> understanding is that you wish the client to be a= ble to have multiple
>>>> >> connections open spanning multiple DECADE servers= . Is that correct?
>>>> >>
>>>> >> If so, do we need this stated as a requirement or= the protocol? Or is
>>>> >> this a policy that would be allowed/disallowed by= the storage
>>>> >> provider?
>>>> >>
>>>> > yep, your understanding is right, the scenarios were = just described in
>>>> > draft as "soft handover in wireless environment = and delete operation in
>>>> > multi-servers". under these consideration, the a= uthentication and
>>>> > authorization need to be taken each time when setup c= onnection with a
>>>> > new
>>>> > DECADE server, or just be taken only once during  the service?
>>>>
>>>> The DECADE server should need to do some sort of check on = each new
>>>> connection, regardless of whether the user has or previous= ly had a
>>>> connection open to a different DECADE server, right?  Note that the
>>>> requirements don't indicate how authentication or authoriz= ation is
>>>> done, and allow a server to make optimizations if it is en= forcing the
>>>> same permissions.
>>>>
>>>> Can you indicate where the existing authorization-related = requirements
>>>> (in particular, 4.1.6.3 of draft-ietf-decade-reqs-00) do n= ot suffice
>>>> for the use case you are thinking of?
>>
>>> as considering the service continuity, the next serving  DECADE server
>>> should know the progress of the service, how does they know? >>
>> By progress of the service, do you mean current user state (e.g.,<= br> >> quota, recent resource usage history, permissions, etc)?
>>
>> yes, and include data delivery proceeding.

>>> so if the
>>> service proceeding information should be known by the next ser= ving server,
>>> or different servers need to coordinate and schedule each othe= r to fulfill
>>> the user request, i believe the the 4.1.6.3 of the
>>> draft-ietf-decade-req-00
>>> cannot satisfy the req. what do you think about?
>>
>> Note that the protocol that is covered here is the client-server >> protocol. Some of the same protocol may be useful between DECADE >> servers (especially in different administrative domains) for stori= ng
>> and retrieving data, but that does not mean that there can't be >> additional protocol(s) (not specified here) that are used between<= br> >> DECADE servers as well.  For example, if DECADE servers wi= thin an
>> administrative domain can certainly have their own mechanism to sh= are
>> such information.  If such capabilities were included in t= he DECADE
>> protocol (e.g., a need to do this between administrative domains),=
>> that sounds like lots more complexity that we need at this point.<= br> >> but the access between in-network storage also is included in IAP = described
>> in problem statement.  i mean why not put this kind of fun= ction in DECADE
>> since the IAP is defined just like that?

>> That said, it sounds to me like what is des= cribed in 4.1.6.3 would be
>> sufficient (from the perspective of the client-server protocol, >> anyways) to implement what you're describing. If not, what
>> specifically is missing and what use-case does it not meet?
>>
>> so you mean the information you mentioned above, just like current= user
>> state (e.g.,
>> quota, recent resource usage history, permissions, etc) was alread= y included
>> in DECADE requirement? what about the data delivery proceeding inf= ormation?
>> can you specify the chapter for me ? thanks?
>>>> >
>>>> >
>>>> >>

>>>> >> Data Distribution:
>>>> >>
>>>> >> I'm also confused about the intent of this requir= ement.  This
>>>> >> statement has me somewhat worried: "The dist= ribution is transparent to
>>>> >> the users as they interact with the in-network st= orage as a single
>>>> >> logical system." Does this mean that you are= proposing for DECADE
>>>> >> servers to assume the responsibility for deciding= how data is to be
>>>> >> distributed throughout the network, including the= path of the data,
>>>> >> which servers act as intermediate caches, content= expiration policies,
>>>> >> etc?  If this is true, I think it is miss= ing one of the major points
>>>> >> of DECADE. In particular, these decisions are app= lication-dependent
>>>> >> and are not implemented within DECADE. Instead, D= ECADE provides the
>>>> >> basic capabilities and the functionality describe= d above are
>>>> >> implemented by the applications using DECADE.
>>>> >>
>>>> >> Or, am I misinterpreting the intent of the requir= ement?
>>>> >>
>>>> > you mean DECADE provides the basic capabilities, so c= an you give some
>>>> > specify explanations on DECADE capabilities in suppor= ting data
>>>> > distribution?
>>>> >>
>>>>
>>>> The problem statement gives a couple of scenarios. The &qu= ot;Integration
>>>> Examples" presentation from IETF 79 also has more det= ails of an
>>>> on-going effort at Yale.
>>
>>> okay, thx for your information, i will lookup and refer, actua= lly, the
>>> content publisher described in problem statement remind me of =  the
>>> protocol requirements which i did not find in draft-ietf-decad= e-reqs-00 to
>>> support content publish. or i miss some points?
>>
>> Which requirements do you think are missing?
>>
>>>> >> Service Assurance:
>>>> >>
>>>> >> It seems problematic to include "assurance&q= uot; in a DECADE.  Shouldn't
>>>> >> these instead be part of SLAs with a storage prov= ider?  Why should
>>>> >> they be DECADE's responsibility?
>>>> >>
>>>> >> Regarding "resource reservation", are y= ou referring to an actual
>>>> >> reservation (which might be problematic -- see ab= ove) or do you mean
>>>> >> that the resource share should able to be specifi= ed at the time the
>>>> >> connection opens and be assumed to be the same fo= r the duration of the
>>>> >> connection?
>>>> >>
>>>> >> Regarding Dynamic Feedback, is this orthogonal to= the storage
>>>> >> protocol?  It seems like what you want he= re is a generic "status"
>>>> >> service saying how loaded a server is?
>>>> >>
>>>> > thats right, actually, the flow control mechanism was= under discussion
>>>> > in writing the draft at first. what about your opinio= n in this
>>>> > requirements?
>>>> >
>>>>
>>>> I'm not sure what the typical way of providing such "= load status"
>>>> information for IETF protocols, but my inclination is that= it should
>>>> not be in the DECADE protocol itself.  Maybe someone else with a
>>>> longer history in IETF could jump in here :)
>>> so can i understand that "load status" is kind of ne= cessity  information
>>> for DECADE Server, but where and who collects the information = are
>>> remain discussion?
>>
>> The storage provider is free to collect the information wherever a= nd
>> however they wish.  The DECADE server implementation could= additional
>> export whatever status information it wishes. I don't think the DE= CADE
>> protocol needs to be concerned with that.
>>
>> Note that certain error conditions (e.g., overload, insufficient >> resources) may be signaled by a DECADE server (there are already h= ave
>> requirements for those).  If you are referring to status f= or a user's
>> resources, there is already a requirement for that too.
>>
>> I'm just not convinced that the DECADE protocol needs to export it= s
>> current load status to clients.
>>
>> actually i am not sure which elements in DECADE needs the load
>> status,(DECADE client or network storage if the network storage ne= eds to
>> redirect the request or both?).
>>
>>
>>
>> And the requirement draft currently seems describe the overload co= ndition as
>> the event triggering. do you think if it is necessary to periodica= lly
>> reporting of the DECADE network status to client for its network s= torage
>> selection?
>>
>>
>>

>> and the requirement draft just describe DEC= ADE which is busy to serve other
>> requests must be able to reject requests, not consider how to hand= le the
>> user request after being rejected?
>>
>>>> >>

>>>> >> Data classification:
>>>> >>
>>>> >> Would it be better to instead have the client spe= cify properties of
>>>> >> the content instead of place it into ? See
>>>> >> www.ietf.org/proceedings/78/slides/nfsv4-0.pdf for an example of this >>>> >> approach for NFS.
>>>> >>
>>>> >> I think a problem with classifying applications i= s that it assumes
>>>> >> that applications fit one of the supplied classif= ications. What if it
>>>> >> may fit multiple classifications? or none?  Another problem is it
>>>> >> assumes that servers assume based on indirect and= assumed information
>>>> >> that they know what to do with a particular piece= of content. Why not
>>>> >> have an application specify its desires directly?=
>>>> >>
>>>> >
>>>> >
>>>> >>
>>>> >> Small Objects:
>>>> >>
>>>> >> What is the new requirement here?  Why is the existing requirement in
>>>> >> draft-ietf-decade-reqs-00 insufficient?
>>>> >>
>>>> >> This also has me a bit worried:
>>>> >> "And the in-network storage has the limited = storage capacity, with the
>>>> >> arrival of user requests and data distribution re= quirements, the data
>>>> >> stored in the in-network storage will be replaced= if the storage
>>>> >> reaches the limit and data arrivals continually.&= quot;
>>>> >>
>>>> >> How does the server know what the proper replacem= ent strategy is for
>>>> >> an application? I think DECADE's philosophy is th= at applications
>>>> >> should decide this. A simple way to do this is ex= plicit deletion by an
>>>> >> application, but perhaps a more efficient (yet mo= re complex) solution
>>>> >> is for an application to specify the replacement = policy to the server.
>>>> >>
>>>> > actually, the key in "the data classification an= d small objects " is
>>>> > whether does it or not in P2P application? i did not = find data
>>>> > classification was adopted in P2P application so far,= let alone DECADE
>>>> > need
>>>> > to classify the data used in all kinds of application= .
>>>> >
>>>>
>>>> So, do you agree that it is problematic to try and classif= y each type
>>>> of application and try to specify the typical workload for= each class?
>>>>
>>>> My point was that I don't think its necessary to do the cl= assification
>>>> at all.  It is more extensible (and directly usefu= l) for a server to
>>>> just give it direct hints about what would be preferable.<= br> >>>
>>> yep, i believe it may be a little difficult, but worthy doing.= specially
>>> for improving the resource utilization within a single server = and reducing
>>> the response time for client. what about others opinion?
>>
>> Can you justify why giving classifications (e.g., "I'm a live=
>> streaming application") would be better than giving specific = hints
>> (e.g., "please don't bother persistent these objects to disk&= quot;)?
>>
>> i mean data in different kind of operation mode and attribute shou= ld have
>> different user patterns and storage rules, which may be help to im= prove the
>> resource utilization and reduce the response time for request, wha= t are you
>> understanding?
>>> >>

>>>> >> Removal of Expired Records= :
>>>> >>
>>>> >> "However, the two scenarios did not mention = how to handle the old
>>>> >> resource if the user distributes the new resource= which is an updated
>>>> >> copy of the old resource."
>>>> >>
>>>> >> Why does this need to be handled in the requireme= nts?  Are you trying
>>>> >> to draw the distinction between immediate deletio= n of content and lazy
>>>> >> deletion?
>>>> >>
>>>> > i mean the meaning of delete operation and how to han= dle the expired
>>>> > records need to be clarify in requirements.
>>>>
>>>> My inclination is that "deleted" means that othe= r requests the object
>>>> of the same name should result an error, until another obj= ect with the
>>>> same name is stored.
>>>
>>> okay, under the scenario "client uploads the new version,= and did not
>>> specify how to handle the old version", did DECADE server= delete the older
>>> version (or just label it unavailable, anyway, it is implement= ation issue
>>> )
>>> or not ? in another word, just replace the older version with = the new
>>> version with the same name?
>>
>> In this case, I would think the "write" of the new objec= t should be
>> rejected, or if desired, we could have an overwrite option.  This
>> could be added to the requirements if it helps to clarify.
>>
>> yep, no matter which solution is chosen, let the understanding una= nimously:D
>>> how to handle the older version which is
>>> transferring from server to client?
>>
>> I think it would be cleaner to ask the server to continue sending = an
>> object once it has been started, but ultimately this would be the<= br> >> decision of the server's implementation I think.  Maybe a "SHOULD"
>> requirement.  This could be added if desired.
>>
>> Thank you for these questions.  It helps design the requirements more
>> cleanly if there are specific scenarios in front of us :)
>> just discussion together:D and also thanks for your points to help= me
>> understanding more!

>> Rich
>>
>>>> I think that the time the data is removed from disk (or me= mory) should
>>>> be up to the implementation. A storage provider might stil= l have as
>>>> part of some agreement that deleted data will be removed w= ithin X
>>>> days/hours/minutes/whatever.
>>>
>>>    agree with you.
>>>>
>>>> If people in the WG think it is necessary, we could have a= requirement
>>>> that says the protocol should support an argument indicati= ng immediate
>>>> deletion, but it is not clear that we need this.
>>>>
>>>> Rich
>>>>
>>>> >>
>>>> >> Thanks!
>>>> >> Rich
>>>> >>
>>>> >>
>>>> >> On Mon, Dec 27, 2010 at 12:57 AM, =D6=EC=E4=EC <buptxiaozhu@gmail.com> wrote:
>>>> >> > Dear all,
>>>> >> >
>>>> >> > There is a slightly updated version of the d= ecade additional
>>>> >> > requirements
>>>> >> > draft.
>>>> >> >
>>>> >> >
>>>> >> > https://datatracker.ietf.org/doc/draft-zhu-decade-additional-requirements/<= /a>
>>>> >> >
>>>> >> > Jin Peng, Yunfei Zhang and me are expecting = to have a discussion
>>>> >> > with
>>>> >> > all of
>>>> >> > you.
>>>> >> >
>>>> >> > Any comments are appreciated!
>>>> >> >
>>>> >> > A new version of I-D,
>>>> >> > draft-zhu-decade-additional-requirements-00.= txt
>>>> >> > has been successfully submitted by Xiao Zhu = and posted to the IETF
>>>> >> > repository.
>>>> >> >
>>>> >> > Filename:      draft-zhu-decade-additional-requirements
>>>> >> > Revision:      00
>>>> >> > Title:                 Additional protocol requirements on DECADE
>>>> >> > Creation_date:   &nbs= p;     2010-12-27
>>>> >> > WG ID:                 Independent Submission
>>>> >> > Number_of_pages: 10
>>>> >> >
>>>> >> > Abstract:
>>>> >> > The DECoupled Application Data Enroute(DECAD= E)working group is
>>>> >> > specifying standardized interfaces for acces= sing in-network storage
>>>> >> > from applications to store, retrieve and man= age data. The main
>>>> >> > object
>>>> >> > is to provide a framework that is useful to = the applications,
>>>> >> > including P2P applications and other data-or= iented applications,
>>>> >> > possibly related applications that can benef= it from accessing in-
>>>> >> > network storage. This memo focuses on some r= equirements such as
>>>> >> > request redirecting and so on which are on t= he central of mobility,
>>>> >> > wireless network environment and CDN applica= tion. We present these
>>>> >> > in
>>>> >> > this memo as additional requirements that sh= ould be considered for
>>>> >> > the DECADE architecture and protocol specifi= cations.
>>>> >> >
>>>> >> >
>>>> >> >
>>>> >> > The IETF Secretariat.
>>>> >> >
>>>> >> > --
>>>> >> > Best wishes,
>>>> >> >
>>>> >> > Beijing University of Posts & Telecommun= ications (BUPT)
>>>> >> > Zhu Xiao  ( =D6=EC=E4=EC )
>>>> >> > E-mail: buptxiaozhu@gmail.com
>>>> >> > mobile:+86 134-8881-9004
>>>> >> >
>>>> >> > ____________________________________________= ___
>>>> >> > decade mailing list
>>>> >> > decade@ietf.org
>>>> >> > https://www.ietf.org/mailman/listinfo/decade
>>>> >> >
>>>> >> >
>>>> >
>>>> >
>>>> >
>>>> > --
>>>> > Best wishes,
>>>> >
>>>> > Beijing University of Posts & Telecommunications = (BUPT)
>>>> > Zhu Xiao  ( =D6=EC=E4=EC )
>>>> > E-mail: buptxiaozhu@gmail.com
>>>> > mobile:+86 134-8881-9004
>>>
>>>
>>>
>>> --
>>> Best wishes,
>>>
>>> Beijing University of Posts & Telecommunications (BUPT) >>> Zhu Xiao  ( =D6=EC=E4=EC )
>>> E-mail: buptxiaozhu@gmail.com
>>> mobile:+86 134-8881-9004
>>>
>>
>>
>> --
>> Best wishes,
>>
>> Beijing University of Posts & Telecommunications (BUPT)
>> Zhu Xiao  ( =D6=EC=E4=EC )
>> E-mail: buptxiaozhu@gmail.com
>> mobile:+86 134-8881-9004
>



--

Best wishes,

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




--
Best wishes,

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

--_000_1CA25301D2219F40B3AA37201F0EACD1135A2B0FPACDCEXMB05cabl_-- From richard_woundy@cable.comcast.com Tue Jun 28 14:49:33 2011 Return-Path: X-Original-To: decade@ietfa.amsl.com Delivered-To: decade@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2662C11E8167 for ; Tue, 28 Jun 2011 14:49:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.847 X-Spam-Level: X-Spam-Status: No, score=-102.847 tagged_above=-999 required=5 tests=[AWL=5.616, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5G2pTgc2twHW for ; Tue, 28 Jun 2011 14:49:32 -0700 (PDT) Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by ietfa.amsl.com (Postfix) with ESMTP id 8D8E911E8143 for ; Tue, 28 Jun 2011 14:49:32 -0700 (PDT) Received: from ([24.40.55.41]) by pacdcimo01.cable.comcast.com with ESMTP with TLS id 5503620.132601808; Tue, 28 Jun 2011 17:49:25 -0400 Received: from PACDCEXMB05.cable.comcast.com ([fe80::a5b0:e5c4:df1b:2367]) by PACDCEXHUB02.cable.comcast.com ([fe80::11d4:f530:37a0:9f4e%12]) with mapi id 14.01.0289.001; Tue, 28 Jun 2011 17:49:18 -0400 From: "Woundy, Richard" To: Songhaibin , "decade@ietf.org" Thread-Topic: DECADE Meeting at IETF 81 Thread-Index: AQHMNd068lc5Fo1ko0qu7f3AYmC7Fg== Date: Tue, 28 Jun 2011 21:49:16 +0000 Message-ID: <1CA25301D2219F40B3AA37201F0EACD1135A359A@PACDCEXMB05.cable.comcast.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.163.75.13] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [decade] DECADE Meeting at IETF 81 X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2011 21:49:33 -0000 Also note that the internet-draft cut-off dates are approaching quickly. * 2011-07-04 (Monday): Internet Draft Cut-off for initial document (-00) su= bmission by 17:00 PT (00:00 UTC) * 2011-07-11 (Monday): Internet Draft final submission cut-off by 17:00 PT = (00:00 UTC) -- Rich -----Original Message----- From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.org] On Behalf Of= Songhaibin Sent: Tuesday, June 28, 2011 5:31 AM To: decade@ietf.org Subject: [decade] DECADE Meeting at IETF 801 Dear all, DECADE meeting is scheduled on Tuesday from 15:20 to 17:00, in the meeting = room 206B. Please note that IETF agendas are subject to change. BR, -Haibin _______________________________________________ decade mailing list decade@ietf.org https://www.ietf.org/mailman/listinfo/decade From buptxiaozhu@gmail.com Wed Jun 29 00:02:47 2011 Return-Path: X-Original-To: decade@ietfa.amsl.com Delivered-To: decade@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FED721F85ED for ; Wed, 29 Jun 2011 00:02:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.002 X-Spam-Level: *** X-Spam-Status: No, score=3.002 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NPj23M1v-lLs for ; Wed, 29 Jun 2011 00:02:44 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 87C2621F85F2 for ; Wed, 29 Jun 2011 00:02:39 -0700 (PDT) Received: by gxk19 with SMTP id 19so467523gxk.31 for ; Wed, 29 Jun 2011 00:02:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=H3gXRiRSMwmrLaVtgggZeSAKoyUL2qwEqnhkuaZwsp0=; b=g8HR03YH0dpHWOkRTE4ZeOvjhmVXH1dpV4U2+OYt6Rts1DYr9ytHxrl+3CZh+noS7T mEj/ZHlYOX+EzyRks9j0rzcngkMqc9nZ5MGkAcnIZwKezE5SUKf0sUMYYvjMZLebEXmq 8ZzcesZ/g5pgy64Mzn9/KpXtfQUlol+vUGKH8= MIME-Version: 1.0 Received: by 10.151.149.4 with SMTP id b4mr352115ybo.365.1309330957931; Wed, 29 Jun 2011 00:02:37 -0700 (PDT) Received: by 10.151.98.20 with HTTP; Wed, 29 Jun 2011 00:02:37 -0700 (PDT) In-Reply-To: <1CA25301D2219F40B3AA37201F0EACD1135A2B0F@PACDCEXMB05.cable.comcast.com> References: <1CA25301D2219F40B3AA37201F0EACD11343C0AB@PACDCEXMB05.cable.comcast.com> <1CA25301D2219F40B3AA37201F0EACD1135A2B0F@PACDCEXMB05.cable.comcast.com> Date: Wed, 29 Jun 2011 15:02:37 +0800 Message-ID: From: =?GB2312?B?1uzk7A==?= To: "Woundy, Richard" Content-Type: multipart/alternative; boundary=001517511acea4147b04a6d45ecd Cc: "decade@ietf.org" Subject: Re: [decade] draft-zhu-decade-additional-requirements 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 Jun 2011 07:02:47 -0000 --001517511acea4147b04a6d45ecd Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable hi, Woundy okay. that`s a good idea. I remember we have a discussion on the additional requirements in the draft-zhu-decade-additional-requirement and we have reached agreement on the first points with Richard Alimi. I have no specia= l suggestion on how my requirements were reflected in draft-ietf-decade-reqs. But we, the writers of the draft could be added in the contributors of the draft-ieft-decade-reqs. What do you think of ? 2011/6/29 Woundy, Richard > Xiao,**** > > ** ** > > My personal preference would be to let > draft-zhu-decade-additional-requirements expire, and ensure that the key > requirements from your draft are reflected in draft-ietf-decade-reqs whic= h > is the official WG draft.**** > > ** ** > > Do you have objections about how your requirements were reflected in > draft-ietf-decade-reqs?**** > > ** ** > > -- Rich**** > > ** ** > > *From:* =D6=EC=E4=EC [mailto:buptxiaozhu@gmail.com] > *Sent:* Monday, June 27, 2011 10:23 PM > *To:* Richard Alimi > *Cc:* Woundy, Richard; decade@ietf.org > > *Subject:* Re: [decade] draft-zhu-decade-additional-requirements**** > > ** ** > > hi, Richard and everybody**** > > ** ** > > The draft draft-zhu-decade-additional-requirements I submitted last year > is about to expire. do you have some suggestions to update the version? a= nd > do the DECADE requirement draft has adopted some suggestions of my draft?= * > *** > > ** ** > > 2011/6/27 =D6=EC=E4=EC **** > > hi, Richard and everybody**** > > ** ** > > The draft draft-zhu-decade-additional-requirements I submitted last year > is about to expire. do you have some suggestions to update the version? a= nd > do the DECADE requirement draft has adopted some suggestions of my draft?= * > *** > > ** ** > > 2011/3/14 Richard Alimi **** > > Hi All, > > We've made all of these updates to the requirements document, with the > exception of: > > > - If an object is deleted as it is concurrently being read, then the > > server MAY continue to read it (lazy deletion), or it MAY discontinue > > reading the object and signal an error to the client reading the > > object. > > Upon looking at this again, it looks more like an implementation > detail. If anything, this would result in a "non-requirement" in the > document. However, it seems like a fairly low-level non-requirement to > state at this time. I'd propose to leave it out for now and revisit > this if it comes up again in the future. Thoughts? > > Thanks, > Rich > > 2011/3/2 Richard Alimi : > > Hi All, > > > > I'll offer a summary of this discussion. Let me know if I missed > > anything, or if there are objections/other thoughts on these proposed > > resolutions. > > > > Redirection: > > - We can add a requirement mentioning that DECADE may support > redirection. > > > > Data Classification: > > - I (personally) strongly disagree with attempting to classify access > > patterns or applications. We could add something saying that explicit > > hints (a la www.ietf.org/proceedings/78/slides/nfsv4-0.pdf) could be > > provided in DECADE. However, I don't think we need to do something > > new here. In particular, if the underlying storage/data transport > > supports hints, a DECADE client or server can use it. > > > > Storage Status: > > - Update section 5.1.6 to indicate that status information should > > include permissions of stored objects, if applicable. > > - Update 5.1.6 to indicate that status information should include > > other information about resource usage (the clients own resources, or > > resources used by other clients that have been authorized to > > read/write objects or open connections to one's storage). > > > > Requirements for object deletion/overwriting: > > - DECADE MAY have an overwrite flag (note that this may or may not be > > necessary depending on our naming, but the requirements document > > probably is not the place to take a stand on this at the current > > point.) > > - If an object is deleted as it is concurrently being read, then the > > server MAY continue to read it (lazy deletion), or it MAY discontinue > > reading the object and signal an error to the client reading the > > object. > > > > Would this be sufficient to merge in the points from > > draft-zhu-decade-additional-requirements-00 and this ensuing > > discussion? > > > > Thanks, > > Rich > > > > > > 2011/3/2 Woundy, Richard : > >> Folks, > >> > >> > >> > >> Do we have consensus yet about how the WG could have a single DECADE > >> requirements document going forward? I can't tell the state of our > >> requirements consolidation from the email thread below. > >> > >> > >> > >> It would be preferable if we could resolve this fully on the WG mailin= g > >> list, but this is important enough to allocate some time at our meetin= g > in > >> Prague. > >> > >> > >> > >> -- Rich > >> > >> > >> > >> From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.org] On > Behalf Of > >> ?? > >> Sent: Sunday, January 16, 2011 9:02 PM > >> To: Richard Alimi > >> Cc: decade@ietf.org > >> Subject: Re: [decade] draft-zhu-decade-additional-requirements**** > > >> > >> > >> > >> hi, Richard: > >> > >> > >> > >> thanks for your reply:D > >> > >> additional discussion see inline:D > >> > >> > >> > >> 2011/1/14 Richard Alimi > >> > >> HI Xiao, > >> > >> 2011/1/12 =D6=EC=E4=EC : > >> > >>> hi, Richard > >>> see inline:D > >>> > >>> 2011/1/11 Richard Alimi > >>>> > >>>> Hi Xiao, > >>>> > >>>> On Mon, Jan 10, 2011 at 6:45 PM, =D6=EC=E4=EC wrote: > >>>> > > >>>> > hi, Richard, sorry for so late response because of be busy with > other > >>>> > projects. > >>>> > some discussion see inline:D marked by red. > >>>> > > >>>> > On Tue, Jan 4, 2011 at 4:06 AM, Richard Alimi > >>>> > wrote: > >>>> >> > >>>> >> Hi Xiao, > >>>> >> > >>>> >> Thank you for the draft. Some comments on the requirements: > >>>> >> > >>>> >> Request Redirects: > >>>> >> > >>>> >> This would provide some additional freedom for the storage > provider. > >>>> >> I think it is reasonable since it doesn't necessitate additional > >>>> >> complexity for the DECADE server, but allows it if desired. > However, > >>>> >> note that it may complicate some of the other components of the > >>>> >> design. In particular, if there is a per-user quota for storage, = is > >>>> >> the user made aware of the quota at each in-network storage (if > there > >>>> >> is no shared storage between them)? Resource sharing policies ma= y > be > >>>> >> impacted (e.g., if a bandwidth sharing weight of 1 may mean > something > >>>> >> different at DECADE server A than it does at DECADE server B). A= t > >>>> >> this point it may be best to just note these so they are > documented, > >>>> >> but since the specification of the resource sharing policies are > still > >>>> >> being contemplated for the basic case of a single server it may b= e > >>>> >> premature to even try and solve them for the case supporting > >>>> >> redirection. > >>>> >> > >>>> > actually, you mean two points, right? > >>>> > 1. whether or not to be ware of the content at each in-network > storage > >>>> > and of course resource sharing policies can be impact in the reque= st > >>>> > redirection. your suggestion"just to note these so they are > documented" > >>>> > will > >>>> > be ok, or DECADE server list with some parameters will be return f= or > >>>> > user to > >>>> > select the appropriate DECADE server, which can avoid the differen= t > >>>> > weighted > >>>> > of the same parameter in server decision. but the parameter used i= n > >>>> > select > >>>> > the best DECADE server will be known for DECADE servers, in which > other > >>>> > complexities will be added. anyway, all the solution are the > >>>> > implementation > >>>> > issue, which, i believe, does not impact the necessity of the > >>>> > requirement. > >>>> > >>>> In general, I'd agree that the decision about where to redirect woul= d > >>>> be an implementation issue. > >>>> > >>>> > > >>>> > 2. you mean "the resource sharing policies are still being > considered > >>>> > in > >>>> > a single server", so it may be premature to support redirection. > the > >>>> > architecture and protocol will be badly impacted if the requiremen= ts > >>>> > change. > >>>> > so the designing can be taken step by step, but the requirements > >>>> > should be > >>>> > overall considered. > >>>> > >>>> I said that it is probably premature to consider how resource sharin= g > >>>> policies works across servers (or even if we need to say anything > >>>> about it) since we have not determined how to specify them (or rathe= r, > >>>> how little we need to specify in protocol) for a single server. I di= d > >>>> not mean to imply that redirection could not be introduced as a > >>>> requirement. > >>>> > >>> > >>>> > >>>> > > >>>> > > >>>> >> > >>>> >> Multi-connection: > >>>> >> > >>>> >> I'm not quite clear on the intention of the requirement. My > >>>> >> understanding is that you wish the client to be able to have > multiple > >>>> >> connections open spanning multiple DECADE servers. Is that correc= t? > >>>> >> > >>>> >> If so, do we need this stated as a requirement or the protocol? O= r > is > >>>> >> this a policy that would be allowed/disallowed by the storage > >>>> >> provider? > >>>> >> > >>>> > yep, your understanding is right, the scenarios were just describe= d > in > >>>> > draft as "soft handover in wireless environment and delete operati= on > in > >>>> > multi-servers". under these consideration, the authentication and > >>>> > authorization need to be taken each time when setup connection wit= h > a > >>>> > new > >>>> > DECADE server, or just be taken only once during the service? > >>>> > >>>> The DECADE server should need to do some sort of check on each new > >>>> connection, regardless of whether the user has or previously had a > >>>> connection open to a different DECADE server, right? Note that the > >>>> requirements don't indicate how authentication or authorization is > >>>> done, and allow a server to make optimizations if it is enforcing th= e > >>>> same permissions. > >>>> > >>>> Can you indicate where the existing authorization-related requiremen= ts > >>>> (in particular, 4.1.6.3 of draft-ietf-decade-reqs-00) do not suffice > >>>> for the use case you are thinking of? > >> > >>> as considering the service continuity, the next serving DECADE serve= r > >>> should know the progress of the service, how does they know? > >> > >> By progress of the service, do you mean current user state (e.g., > >> quota, recent resource usage history, permissions, etc)? > >> > >> yes, and include data delivery proceeding.**** > > >>> so if the > >>> service proceeding information should be known by the next serving > server, > >>> or different servers need to coordinate and schedule each other to > fulfill > >>> the user request, i believe the the 4.1.6.3 of the > >>> draft-ietf-decade-req-00 > >>> cannot satisfy the req. what do you think about? > >> > >> Note that the protocol that is covered here is the client-server > >> protocol. Some of the same protocol may be useful between DECADE > >> servers (especially in different administrative domains) for storing > >> and retrieving data, but that does not mean that there can't be > >> additional protocol(s) (not specified here) that are used between > >> DECADE servers as well. For example, if DECADE servers within an > >> administrative domain can certainly have their own mechanism to share > >> such information. If such capabilities were included in the DECADE > >> protocol (e.g., a need to do this between administrative domains), > >> that sounds like lots more complexity that we need at this point. > >> but the access between in-network storage also is included in IAP > described > >> in problem statement. i mean why not put this kind of function in > DECADE > >> since the IAP is defined just like that?**** > > >> That said, it sounds to me like what is described in 4.1.6.3 would be > >> sufficient (from the perspective of the client-server protocol, > >> anyways) to implement what you're describing. If not, what > >> specifically is missing and what use-case does it not meet? > >> > >> so you mean the information you mentioned above, just like current use= r > >> state (e.g., > >> quota, recent resource usage history, permissions, etc) was already > included > >> in DECADE requirement? what about the data delivery proceeding > information? > >> can you specify the chapter for me ? thanks? > >>>> > > >>>> > > >>>> >>**** > > >>>> >> Data Distribution: > >>>> >> > >>>> >> I'm also confused about the intent of this requirement. This > >>>> >> statement has me somewhat worried: "The distribution is transpare= nt > to > >>>> >> the users as they interact with the in-network storage as a singl= e > >>>> >> logical system." Does this mean that you are proposing for DECADE > >>>> >> servers to assume the responsibility for deciding how data is to = be > >>>> >> distributed throughout the network, including the path of the dat= a, > >>>> >> which servers act as intermediate caches, content expiration > policies, > >>>> >> etc? If this is true, I think it is missing one of the major > points > >>>> >> of DECADE. In particular, these decisions are application-depende= nt > >>>> >> and are not implemented within DECADE. Instead, DECADE provides t= he > >>>> >> basic capabilities and the functionality described above are > >>>> >> implemented by the applications using DECADE. > >>>> >> > >>>> >> Or, am I misinterpreting the intent of the requirement? > >>>> >> > >>>> > you mean DECADE provides the basic capabilities, so can you give > some > >>>> > specify explanations on DECADE capabilities in supporting data > >>>> > distribution? > >>>> >> > >>>> > >>>> The problem statement gives a couple of scenarios. The "Integration > >>>> Examples" presentation from IETF 79 also has more details of an > >>>> on-going effort at Yale. > >> > >>> okay, thx for your information, i will lookup and refer, actually, th= e > >>> content publisher described in problem statement remind me of the > >>> protocol requirements which i did not find in draft-ietf-decade-reqs-= 00 > to > >>> support content publish. or i miss some points? > >> > >> Which requirements do you think are missing? > >> > >>>> >> Service Assurance: > >>>> >> > >>>> >> It seems problematic to include "assurance" in a DECADE. > Shouldn't > >>>> >> these instead be part of SLAs with a storage provider? Why shoul= d > >>>> >> they be DECADE's responsibility? > >>>> >> > >>>> >> Regarding "resource reservation", are you referring to an actual > >>>> >> reservation (which might be problematic -- see above) or do you > mean > >>>> >> that the resource share should able to be specified at the time t= he > >>>> >> connection opens and be assumed to be the same for the duration o= f > the > >>>> >> connection? > >>>> >> > >>>> >> Regarding Dynamic Feedback, is this orthogonal to the storage > >>>> >> protocol? It seems like what you want here is a generic "status" > >>>> >> service saying how loaded a server is? > >>>> >> > >>>> > thats right, actually, the flow control mechanism was under > discussion > >>>> > in writing the draft at first. what about your opinion in this > >>>> > requirements? > >>>> > > >>>> > >>>> I'm not sure what the typical way of providing such "load status" > >>>> information for IETF protocols, but my inclination is that it should > >>>> not be in the DECADE protocol itself. Maybe someone else with a > >>>> longer history in IETF could jump in here :) > >>> so can i understand that "load status" is kind of necessity > information > >>> for DECADE Server, but where and who collects the information are > >>> remain discussion? > >> > >> The storage provider is free to collect the information wherever and > >> however they wish. The DECADE server implementation could additional > >> export whatever status information it wishes. I don't think the DECADE > >> protocol needs to be concerned with that. > >> > >> Note that certain error conditions (e.g., overload, insufficient > >> resources) may be signaled by a DECADE server (there are already have > >> requirements for those). If you are referring to status for a user's > >> resources, there is already a requirement for that too. > >> > >> I'm just not convinced that the DECADE protocol needs to export its > >> current load status to clients. > >> > >> actually i am not sure which elements in DECADE needs the load > >> status,(DECADE client or network storage if the network storage needs = to > >> redirect the request or both?). > >> > >> > >> > >> And the requirement draft currently seems describe the overload > condition as > >> the event triggering. do you think if it is necessary to periodically > >> reporting of the DECADE network status to client for its network stora= ge > >> selection? > >> > >> > >>**** > > >> and the requirement draft just describe DECADE which is busy to serve > other > >> requests must be able to reject requests, not consider how to handle t= he > >> user request after being rejected? > >> > >>>> >>**** > > >>>> >> Data classification: > >>>> >> > >>>> >> Would it be better to instead have the client specify properties = of > >>>> >> the content instead of place it into ? See > >>>> >> www.ietf.org/proceedings/78/slides/nfsv4-0.pdf for an example of > this > >>>> >> approach for NFS. > >>>> >> > >>>> >> I think a problem with classifying applications is that it assume= s > >>>> >> that applications fit one of the supplied classifications. What i= f > it > >>>> >> may fit multiple classifications? or none? Another problem is it > >>>> >> assumes that servers assume based on indirect and assumed > information > >>>> >> that they know what to do with a particular piece of content. Why > not > >>>> >> have an application specify its desires directly? > >>>> >> > >>>> > > >>>> > > >>>> >> > >>>> >> Small Objects: > >>>> >> > >>>> >> What is the new requirement here? Why is the existing requiremen= t > in > >>>> >> draft-ietf-decade-reqs-00 insufficient? > >>>> >> > >>>> >> This also has me a bit worried: > >>>> >> "And the in-network storage has the limited storage capacity, wit= h > the > >>>> >> arrival of user requests and data distribution requirements, the > data > >>>> >> stored in the in-network storage will be replaced if the storage > >>>> >> reaches the limit and data arrivals continually." > >>>> >> > >>>> >> How does the server know what the proper replacement strategy is > for > >>>> >> an application? I think DECADE's philosophy is that applications > >>>> >> should decide this. A simple way to do this is explicit deletion = by > an > >>>> >> application, but perhaps a more efficient (yet more complex) > solution > >>>> >> is for an application to specify the replacement policy to the > server. > >>>> >> > >>>> > actually, the key in "the data classification and small objects " = is > >>>> > whether does it or not in P2P application? i did not find data > >>>> > classification was adopted in P2P application so far, let alone > DECADE > >>>> > need > >>>> > to classify the data used in all kinds of application. > >>>> > > >>>> > >>>> So, do you agree that it is problematic to try and classify each typ= e > >>>> of application and try to specify the typical workload for each clas= s? > >>>> > >>>> My point was that I don't think its necessary to do the classificati= on > >>>> at all. It is more extensible (and directly useful) for a server to > >>>> just give it direct hints about what would be preferable. > >>> > >>> yep, i believe it may be a little difficult, but worthy doing. > specially > >>> for improving the resource utilization within a single server and > reducing > >>> the response time for client. what about others opinion? > >> > >> Can you justify why giving classifications (e.g., "I'm a live > >> streaming application") would be better than giving specific hints > >> (e.g., "please don't bother persistent these objects to disk")? > >> > >> i mean data in different kind of operation mode and attribute should > have > >> different user patterns and storage rules, which may be help to improv= e > the > >> resource utilization and reduce the response time for request, what ar= e > you > >> understanding? > >>> >>**** > > >>>> >> Removal of Expired Records: > >>>> >> > >>>> >> "However, the two scenarios did not mention how to handle the old > >>>> >> resource if the user distributes the new resource which is an > updated > >>>> >> copy of the old resource." > >>>> >> > >>>> >> Why does this need to be handled in the requirements? Are you > trying > >>>> >> to draw the distinction between immediate deletion of content and > lazy > >>>> >> deletion? > >>>> >> > >>>> > i mean the meaning of delete operation and how to handle the expir= ed > >>>> > records need to be clarify in requirements. > >>>> > >>>> My inclination is that "deleted" means that other requests the objec= t > >>>> of the same name should result an error, until another object with t= he > >>>> same name is stored. > >>> > >>> okay, under the scenario "client uploads the new version, and did not > >>> specify how to handle the old version", did DECADE server delete the > older > >>> version (or just label it unavailable, anyway, it is implementation > issue > >>> ) > >>> or not ? in another word, just replace the older version with the new > >>> version with the same name? > >> > >> In this case, I would think the "write" of the new object should be > >> rejected, or if desired, we could have an overwrite option. This > >> could be added to the requirements if it helps to clarify. > >> > >> yep, no matter which solution is chosen, let the understanding > unanimously:D > >>> how to handle the older version which is > >>> transferring from server to client? > >> > >> I think it would be cleaner to ask the server to continue sending an > >> object once it has been started, but ultimately this would be the > >> decision of the server's implementation I think. Maybe a "SHOULD" > >> requirement. This could be added if desired. > >> > >> Thank you for these questions. It helps design the requirements more > >> cleanly if there are specific scenarios in front of us :) > >> just discussion together:D and also thanks for your points to help me > >> understanding more!**** > > >> Rich > >> > >>>> I think that the time the data is removed from disk (or memory) shou= ld > >>>> be up to the implementation. A storage provider might still have as > >>>> part of some agreement that deleted data will be removed within X > >>>> days/hours/minutes/whatever. > >>> > >>> agree with you. > >>>> > >>>> If people in the WG think it is necessary, we could have a requireme= nt > >>>> that says the protocol should support an argument indicating immedia= te > >>>> deletion, but it is not clear that we need this. > >>>> > >>>> Rich > >>>> > >>>> >> > >>>> >> Thanks! > >>>> >> Rich > >>>> >> > >>>> >> > >>>> >> On Mon, Dec 27, 2010 at 12:57 AM, =D6=EC=E4=EC > wrote: > >>>> >> > Dear all, > >>>> >> > > >>>> >> > There is a slightly updated version of the decade additional > >>>> >> > requirements > >>>> >> > draft. > >>>> >> > > >>>> >> > > >>>> >> > > https://datatracker.ietf.org/doc/draft-zhu-decade-additional-requirements= / > >>>> >> > > >>>> >> > Jin Peng, Yunfei Zhang and me are expecting to have a discussio= n > >>>> >> > with > >>>> >> > all of > >>>> >> > you. > >>>> >> > > >>>> >> > Any comments are appreciated! > >>>> >> > > >>>> >> > A new version of I-D, > >>>> >> > draft-zhu-decade-additional-requirements-00.txt > >>>> >> > has been successfully submitted by Xiao Zhu and posted to the > IETF > >>>> >> > repository. > >>>> >> > > >>>> >> > Filename: draft-zhu-decade-additional-requirements > >>>> >> > Revision: 00 > >>>> >> > Title: Additional protocol requirements on > DECADE > >>>> >> > Creation_date: 2010-12-27 > >>>> >> > WG ID: Independent Submission > >>>> >> > Number_of_pages: 10 > >>>> >> > > >>>> >> > Abstract: > >>>> >> > The DECoupled Application Data Enroute(DECADE)working group is > >>>> >> > specifying standardized interfaces for accessing in-network > storage > >>>> >> > from applications to store, retrieve and manage data. The main > >>>> >> > object > >>>> >> > is to provide a framework that is useful to the applications, > >>>> >> > including P2P applications and other data-oriented applications= , > >>>> >> > possibly related applications that can benefit from accessing i= n- > >>>> >> > network storage. This memo focuses on some requirements such as > >>>> >> > request redirecting and so on which are on the central of > mobility, > >>>> >> > wireless network environment and CDN application. We present > these > >>>> >> > in > >>>> >> > this memo as additional requirements that should be considered > for > >>>> >> > the DECADE architecture and protocol specifications. > >>>> >> > > >>>> >> > > >>>> >> > > >>>> >> > The IETF Secretariat. > >>>> >> > > >>>> >> > -- > >>>> >> > Best wishes, > >>>> >> > > >>>> >> > Beijing University of Posts & Telecommunications (BUPT) > >>>> >> > Zhu Xiao ( =D6=EC=E4=EC ) > >>>> >> > E-mail: buptxiaozhu@gmail.com > >>>> >> > mobile:+86 134-8881-9004 > >>>> >> > > >>>> >> > _______________________________________________ > >>>> >> > decade mailing list > >>>> >> > decade@ietf.org > >>>> >> > https://www.ietf.org/mailman/listinfo/decade > >>>> >> > > >>>> >> > > >>>> > > >>>> > > >>>> > > >>>> > -- > >>>> > Best wishes, > >>>> > > >>>> > Beijing University of Posts & Telecommunications (BUPT) > >>>> > Zhu Xiao ( =D6=EC=E4=EC ) > >>>> > E-mail: buptxiaozhu@gmail.com > >>>> > mobile:+86 134-8881-9004 > >>> > >>> > >>> > >>> -- > >>> Best wishes, > >>> > >>> Beijing University of Posts & Telecommunications (BUPT) > >>> Zhu Xiao ( =D6=EC=E4=EC ) > >>> E-mail: buptxiaozhu@gmail.com > >>> mobile:+86 134-8881-9004 > >>> > >> > >> > >> -- > >> Best wishes, > >> > >> Beijing University of Posts & Telecommunications (BUPT) > >> Zhu Xiao ( =D6=EC=E4=EC ) > >> E-mail: buptxiaozhu@gmail.com > >> mobile:+86 134-8881-9004 > >**** > > > > **** > > -- **** > > Best wishes, > > Beijing University of Posts & Telecommunications (BUPT) > Zhu Xiao ( =D6=EC=E4=EC ) > E-mail: buptxiaozhu@gmail.com > mobile:+86 134-8881-9004**** > > > > > -- > Best wishes, > > Beijing University of Posts & Telecommunications (BUPT) > Zhu Xiao ( =D6=EC=E4=EC ) > E-mail: buptxiaozhu@gmail.com > mobile:+86 134-8881-9004**** > --=20 Best wishes, Beijing University of Posts & Telecommunications (BUPT) Zhu Xiao ( =D6=EC=E4=EC ) E-mail: buptxiaozhu@gmail.com mobile:+86 134-8881-9004 --001517511acea4147b04a6d45ecd Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable hi, Woundy

okay. that`s a good idea. I remember we = have a discussion on the additional requirements in the draft-zhu-decade-ad= ditional-requirement and we have reached agreement on the first points with= Richard Alimi.  I have no special suggestion on how my requireme= nts were reflected in draft-ietf-decade-reqs.  But we, the writers of = the draft could be added in the contributors of the draft-ieft-decade-reqs.= What do you think of ? 


2011/6/29 Woundy, R= ichard <Richard_Woundy@cable.comcast.com>

Xiao,

 

My personal preference would be to let draft-z= hu-decade-additional-requirements expire, and ensure that the key requireme= nts from your draft are reflected in draft-ietf-decade-reqs which is the official WG draft.

 

Do you have objections about how your requirem= ents were reflected in draft-ietf-decade-reqs?

 

-- Rich

 

From:= =D6=EC=E4=EC<= span style=3D"font-size:10.0pt"> [mailto:buptxiaozhu@gmail.com]
Sent: Monday, June 27, 2011 10:23 PM
To: Richard Alimi
Cc: Woundy, Richard; decade@ietf.org


Subject: Re: [decade] draft-zhu-decade-additional-requirements

 

hi, Richard and everybody

 

The draft draft-zhu-decade-additio= nal-requirements I submitted last year is about to expire. do you have some= suggestions to update the version? and do the DECADE requirement draft has adopted some suggestions of my draft?

 

2011/6/27 =D6=EC=E4=EC &= lt;buptxiaozhu@g= mail.com>

hi, Richard and everybody

 

The draft draft-zhu-decade-additio= nal-requirements I submitted last year is about to expire. do you have some= suggestions to update the version? and do the DECADE requirement draft has adopted some suggestions of my draft?

 <= /p>

2011/3/14 Richard Alimi <rich@velvetsea.net>

Hi All,

We've made all of these updates to the requirements document, with the<= br> exception of:

> - If an object is deleted as it is concurrently being read, then the > server MAY continue to read it (lazy deletion), or it MAY discontinue<= br> > reading the object and signal an error to the client reading the
> object.

Upon looking at this again, it looks more like an implementation
detail. If anything, this would result in a "non-requirement" in = the
document. However, it seems like a fairly low-level non-requirement to
state at this time. I'd propose to leave it out for now and revisit
this if it comes up again in the future.  Thoughts?

Thanks,
Rich

2011/3/2 Richard Alimi <rich@velvetsea.net>:
> Hi All,
>
> I'll offer a summary of this discussion. Let me know if I missed > anything, or if there are objections/other thoughts on these proposed<= br> > resolutions.
>
> Redirection:
> - We can add a requirement mentioning that DECADE may support redirect= ion.
>
> Data Classification:
> - I (personally) strongly disagree with attempting to classify access<= br> > patterns or applications. We could add something saying that explicit<= br> > hints (a la www.ietf.org/proceedings/78/slides/nfsv4-0.pdf) could be
> provided in DECADE.  However, I don't think we n= eed to do something
> new here. In particular, if the underlying storage/data transport
> supports hints, a DECADE client or server can use it.
>
> Storage Status:
> - Update section 5.1.6 to indicate that status information should
> include permissions of stored objects, if applicable.
> - Update 5.1.6 to indicate that status information should include
> other information about resource usage (the clients own resources, or<= br> > resources used by other clients that have been authorized to
> read/write objects or open connections to one's storage).
>
> Requirements for object deletion/overwriting:
> - DECADE MAY have an overwrite flag (note that this may or may not be<= br> > necessary depending on our naming, but the requirements document
> probably is not the place to take a stand on this at the current
> point.)
> - If an object is deleted as it is concurrently being read, then the > server MAY continue to read it (lazy deletion), or it MAY discontinue<= br> > reading the object and signal an error to the client reading the
> object.
>
> Would this be sufficient to merge in the points from
> draft-zhu-decade-additional-requirements-00 and this ensuing
> discussion?
>
> Thanks,
> Rich
>
>
> 2011/3/2 Woundy, Richard <Richard_Woundy@cable.comcast.com>:
>> Folks,
>>
>>
>>
>> Do we have consensus yet about how the WG could have a single DECA= DE
>> requirements document going forward? I can't tell the state of= our
>> requirements consolidation from the email thread below.
>>
>>
>>
>> It would be preferable if we could resolve this fully on the WG ma= iling
>> list, but this is important enough to allocate some time at our me= eting in
>> Prague.
>>
>>
>>
>> -- Rich
>>
>>
>>
>> From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.org] On Behalf Of
>> ??
>> Sent: Sunday, January 16, 2011 9:02 PM
>> To: Richard Alimi
>> Cc: decade@ie= tf.org
>> Subject: Re: [decade] draft-zhu-decade-additional-requirements<= /u>

>>
>>
>>
>> hi, Richard:
>>
>>
>>
>> thanks for your reply:D
>>
>> additional discussion see inline:D
>>
>>
>>
>> 2011/1/14 Richard Alimi <rich@velvetsea.net>
>>
>> HI Xiao,
>>
>> 2011/1/12 =D6=EC=E4=EC <buptxiaozhu@gmail.com&g= t;:
>>
>>> hi, Richard
>>> see inline:D
>>>
>>> 2011/1/11 Richard Alimi <rich@velvetsea.net>
>>>>
>>>> Hi Xiao,
>>>>
>>>> On Mon, Jan 10, 2011 at 6:45 PM, =D6= =EC=E4=EC <buptxiaozhu@gmail.com> wrote:
>>>> >
>>>> > hi, Richard, sorry for so late response because of be= busy with other
>>>> > projects.
>>>> > some discussion see inline:D marked by red.
>>>> >
>>>> > On Tue, Jan 4, 2011 at 4:06 AM, Richard Alimi <rich@velvetsea.net= >
>>>> > wrote:
>>>> >>
>>>> >> Hi Xiao,
>>>> >>
>>>> >> Thank you for the draft.  Some comments on the requirements:
>>>> >>
>>>> >> Request Redirects:
>>>> >>
>>>> >> This would provide some additional freedom for th= e storage provider.
>>>> >> I think it is reasonable since it doesn't nec= essitate additional
>>>> >> complexity for the DECADE server, but allows it i= f desired. However,
>>>> >> note that it may complicate some of the other com= ponents of the
>>>> >> design. In particular, if there is a per-user quo= ta for storage, is
>>>> >> the user made aware of the quota at each in-netwo= rk storage (if there
>>>> >> is no shared storage between them)?  Resource sharing policies may be
>>>> >> impacted (e.g., if a bandwidth sharing weight of = 1 may mean something
>>>> >> different at DECADE server A than it does at DECA= DE server B).  At
>>>> >> this point it may be best to just note these so t= hey are documented,
>>>> >> but since the specification of the resource shari= ng policies are still
>>>> >> being contemplated for the basic case of a single= server it may be
>>>> >> premature to even try and solve them for the case= supporting
>>>> >> redirection.
>>>> >>
>>>> > actually, you mean two points, right?
>>>> > 1. whether or not to be ware of the content at each i= n-network storage
>>>> > and of course resource sharing policies can be impact= in the request
>>>> > redirection. your suggestion"just to note these = so they are documented"
>>>> > will
>>>> > be ok, or DECADE server list with some parameters wil= l be return for
>>>> > user to
>>>> > select the appropriate DECADE server, which can avoid= the different
>>>> > weighted
>>>> > of the same parameter in server decision. but the par= ameter used in
>>>> > select
>>>> > the best DECADE server will be known for DECADE serve= rs, in which other
>>>> > complexities will be added. anyway, all the solution = are the
>>>> > implementation
>>>> > issue, which, i believe, does not impact the necessit= y of the
>>>> > requirement.
>>>>
>>>> In general, I'd agree that the decision about where to= redirect would
>>>> be an implementation issue.
>>>>
>>>> >
>>>> > 2. you mean "the resource sharing policies are s= till being considered
>>>> > in
>>>> > a single server", so it may be premature to supp= ort redirection.  the
>>>> > architecture and protocol will be badly impacted if t= he requirements
>>>> > change.
>>>> > so the designing can be  taken  step by step, but the requirements
>>>> > should be
>>>> > overall considered.
>>>>
>>>> I said that it is probably premature to consider how resou= rce sharing
>>>> policies works across servers (or even if we need to say a= nything
>>>> about it) since we have not determined how to specify them= (or rather,
>>>> how little we need to specify in protocol) for a single se= rver. I did
>>>> not mean to imply that redirection could not be introduced= as a
>>>> requirement.
>>>>
>>>
>>>>
>>>> >
>>>> >
>>>> >>
>>>> >> Multi-connection:
>>>> >>
>>>> >> I'm not quite clear on the intention of the r= equirement.  My
>>>> >> understanding is that you wish the client to be a= ble to have multiple
>>>> >> connections open spanning multiple DECADE servers= . Is that correct?
>>>> >>
>>>> >> If so, do we need this stated as a requirement or= the protocol? Or is
>>>> >> this a policy that would be allowed/disallowed by= the storage
>>>> >> provider?
>>>> >>
>>>> > yep, your understanding is right, the scenarios were = just described in
>>>> > draft as "soft handover in wireless environment = and delete operation in
>>>> > multi-servers". under these consideration, the a= uthentication and
>>>> > authorization need to be taken each time when setup c= onnection with a
>>>> > new
>>>> > DECADE server, or just be taken only once during  the service?
>>>>
>>>> The DECADE server should need to do some sort of check on = each new
>>>> connection, regardless of whether the user has or previous= ly had a
>>>> connection open to a different DECADE server, right?  Note that the
>>>> requirements don't indicate how authentication or auth= orization is
>>>> done, and allow a server to make optimizations if it is en= forcing the
>>>> same permissions.
>>>>
>>>> Can you indicate where the existing authorization-related = requirements
>>>> (in particular, 4.1.6.3 of draft-ietf-decade-reqs-00) do n= ot suffice
>>>> for the use case you are thinking of?
>>
>>> as considering the service continuity, the next serving  DECADE server
>>> should know the progress of the service, how does they know? >>
>> By progress of the service, do you mean current user state (e.g.,<= br> >> quota, recent resource usage history, permissions, etc)?
>>
>> yes, and include data delivery proceeding.

>>> so if the
>>> service proceeding information should be known by the next ser= ving server,
>>> or different servers need to coordinate and schedule each othe= r to fulfill
>>> the user request, i believe the the 4.1.6.3 of the
>>> draft-ietf-decade-req-00
>>> cannot satisfy the req. what do you think about?
>>
>> Note that the protocol that is covered here is the client-server >> protocol. Some of the same protocol may be useful between DECADE >> servers (especially in different administrative domains) for stori= ng
>> and retrieving data, but that does not mean that there can't b= e
>> additional protocol(s) (not specified here) that are used between<= br> >> DECADE servers as well.  For example, if DECADE = servers within an
>> administrative domain can certainly have their own mechanism to sh= are
>> such information.  If such capabilities were inc= luded in the DECADE
>> protocol (e.g., a need to do this between administrative domains),=
>> that sounds like lots more complexity that we need at this point.<= br> >> but the access between in-network storage also is included in IAP = described
>> in problem statement.  i mean why not put this k= ind of function in DECADE
>> since the IAP is defined just like that?

>> That said, it sounds to me like what is des= cribed in 4.1.6.3 would be
>> sufficient (from the perspective of the client-server protocol, >> anyways) to implement what you're describing. If not, what
>> specifically is missing and what use-case does it not meet?
>>
>> so you mean the information you mentioned above, just like current= user
>> state (e.g.,
>> quota, recent resource usage history, permissions, etc) was alread= y included
>> in DECADE requirement? what about the data delivery proceeding inf= ormation?
>> can you specify the chapter for me ? thanks?
>>>> >
>>>> >
>>>> >>

>>>> >> Data Distribution:
>>>> >>
>>>> >> I'm also confused about the intent of this re= quirement.  This
>>>> >> statement has me somewhat worried: "The dist= ribution is transparent to
>>>> >> the users as they interact with the in-network st= orage as a single
>>>> >> logical system." Does this mean that you are= proposing for DECADE
>>>> >> servers to assume the responsibility for deciding= how data is to be
>>>> >> distributed throughout the network, including the= path of the data,
>>>> >> which servers act as intermediate caches, content= expiration policies,
>>>> >> etc?  If this is true, I think = it is missing one of the major points
>>>> >> of DECADE. In particular, these decisions are app= lication-dependent
>>>> >> and are not implemented within DECADE. Instead, D= ECADE provides the
>>>> >> basic capabilities and the functionality describe= d above are
>>>> >> implemented by the applications using DECADE.
>>>> >>
>>>> >> Or, am I misinterpreting the intent of the requir= ement?
>>>> >>
>>>> > you mean DECADE provides the basic capabilities, so c= an you give some
>>>> > specify explanations on DECADE capabilities in suppor= ting data
>>>> > distribution?
>>>> >>
>>>>
>>>> The problem statement gives a couple of scenarios. The &qu= ot;Integration
>>>> Examples" presentation from IETF 79 also has more det= ails of an
>>>> on-going effort at Yale.
>>
>>> okay, thx for your information, i will lookup and refer, actua= lly, the
>>> content publisher described in problem statement remind me of =  the
>>> protocol requirements which i did not find in draft-ietf-decad= e-reqs-00 to
>>> support content publish. or i miss some points?
>>
>> Which requirements do you think are missing?
>>
>>>> >> Service Assurance:
>>>> >>
>>>> >> It seems problematic to include "assurance&q= uot; in a DECADE.  Shouldn't
>>>> >> these instead be part of SLAs with a storage prov= ider?  Why should
>>>> >> they be DECADE's responsibility?
>>>> >>
>>>> >> Regarding "resource reservation", are y= ou referring to an actual
>>>> >> reservation (which might be problematic -- see ab= ove) or do you mean
>>>> >> that the resource share should able to be specifi= ed at the time the
>>>> >> connection opens and be assumed to be the same fo= r the duration of the
>>>> >> connection?
>>>> >>
>>>> >> Regarding Dynamic Feedback, is this orthogonal to= the storage
>>>> >> protocol?  It seems like what y= ou want here is a generic "status"
>>>> >> service saying how loaded a server is?
>>>> >>
>>>> > thats right, actually, the flow control mechanism was= under discussion
>>>> > in writing the draft at first. what about your opinio= n in this
>>>> > requirements?
>>>> >
>>>>
>>>> I'm not sure what the typical way of providing such &q= uot;load status"
>>>> information for IETF protocols, but my inclination is that= it should
>>>> not be in the DECADE protocol itself.  Maybe someone else with a
>>>> longer history in IETF could jump in here :)
>>> so can i understand that "load status" is kind of ne= cessity  information
>>> for DECADE Server, but where and who collects the information = are
>>> remain discussion?
>>
>> The storage provider is free to collect the information wherever a= nd
>> however they wish.  The DECADE server implementa= tion could additional
>> export whatever status information it wishes. I don't think th= e DECADE
>> protocol needs to be concerned with that.
>>
>> Note that certain error conditions (e.g., overload, insufficient >> resources) may be signaled by a DECADE server (there are already h= ave
>> requirements for those).  If you are referring t= o status for a user's
>> resources, there is already a requirement for that too.
>>
>> I'm just not convinced that the DECADE protocol needs to expor= t its
>> current load status to clients.
>>
>> actually i am not sure which elements in DECADE needs the load
>> status,(DECADE client or network storage if the network storage ne= eds to
>> redirect the request or both?).
>>
>>
>>
>> And the requirement draft currently seems describe the overload co= ndition as
>> the event triggering. do you think if it is necessary to periodica= lly
>> reporting of the DECADE network status to client for its network s= torage
>> selection?
>>
>>
>>

>> and the requirement draft just describe DEC= ADE which is busy to serve other
>> requests must be able to reject requests, not consider how to hand= le the
>> user request after being rejected?
>>
>>>> >>

>>>> >> Data classification:
>>>> >>
>>>> >> Would it be better to instead have the client spe= cify properties of
>>>> >> the content instead of place it into ? See
>>>> >> www.ietf.org/proceedings/78/slides/nfsv4-0.pdf for an example of this >>>> >> approach for NFS.
>>>> >>
>>>> >> I think a problem with classifying applications i= s that it assumes
>>>> >> that applications fit one of the supplied classif= ications. What if it
>>>> >> may fit multiple classifications? or none?  Another problem is it
>>>> >> assumes that servers assume based on indirect and= assumed information
>>>> >> that they know what to do with a particular piece= of content. Why not
>>>> >> have an application specify its desires directly?=
>>>> >>
>>>> >
>>>> >
>>>> >>
>>>> >> Small Objects:
>>>> >>
>>>> >> What is the new requirement here?  Why is the existing requirement in
>>>> >> draft-ietf-decade-reqs-00 insufficient?
>>>> >>
>>>> >> This also has me a bit worried:
>>>> >> "And the in-network storage has the limited = storage capacity, with the
>>>> >> arrival of user requests and data distribution re= quirements, the data
>>>> >> stored in the in-network storage will be replaced= if the storage
>>>> >> reaches the limit and data arrivals continually.&= quot;
>>>> >>
>>>> >> How does the server know what the proper replacem= ent strategy is for
>>>> >> an application? I think DECADE's philosophy i= s that applications
>>>> >> should decide this. A simple way to do this is ex= plicit deletion by an
>>>> >> application, but perhaps a more efficient (yet mo= re complex) solution
>>>> >> is for an application to specify the replacement = policy to the server.
>>>> >>
>>>> > actually, the key in "the data classification an= d small objects " is
>>>> > whether does it or not in P2P application? i did not = find data
>>>> > classification was adopted in P2P application so far,= let alone DECADE
>>>> > need
>>>> > to classify the data used in all kinds of application= .
>>>> >
>>>>
>>>> So, do you agree that it is problematic to try and classif= y each type
>>>> of application and try to specify the typical workload for= each class?
>>>>
>>>> My point was that I don't think its necessary to do th= e classification
>>>> at all.  It is more extensible (and dire= ctly useful) for a server to
>>>> just give it direct hints about what would be preferable.<= br> >>>
>>> yep, i believe it may be a little difficult, but worthy doing.= specially
>>> for improving the resource utilization within a single server = and reducing
>>> the response time for client. what about others opinion?
>>
>> Can you justify why giving classifications (e.g., "I'm a = live
>> streaming application") would be better than giving specific = hints
>> (e.g., "please don't bother persistent these objects to d= isk")?
>>
>> i mean data in different kind of operation mode and attribute shou= ld have
>> different user patterns and storage rules, which may be help to im= prove the
>> resource utilization and reduce the response time for request, wha= t are you
>> understanding?
>>> >>

>>>> >> Removal of Expired Records= :
>>>> >>
>>>> >> "However, the two scenarios did not mention = how to handle the old
>>>> >> resource if the user distributes the new resource= which is an updated
>>>> >> copy of the old resource."
>>>> >>
>>>> >> Why does this need to be handled in the requireme= nts?  Are you trying
>>>> >> to draw the distinction between immediate deletio= n of content and lazy
>>>> >> deletion?
>>>> >>
>>>> > i mean the meaning of delete operation and how to han= dle the expired
>>>> > records need to be clarify in requirements.
>>>>
>>>> My inclination is that "deleted" means that othe= r requests the object
>>>> of the same name should result an error, until another obj= ect with the
>>>> same name is stored.
>>>
>>> okay, under the scenario "client uploads the new version,= and did not
>>> specify how to handle the old version", did DECADE server= delete the older
>>> version (or just label it unavailable, anyway, it is implement= ation issue
>>> )
>>> or not ? in another word, just replace the older version with = the new
>>> version with the same name?
>>
>> In this case, I would think the "write" of the new objec= t should be
>> rejected, or if desired, we could have an overwrite option.  This
>> could be added to the requirements if it helps to clarify.
>>
>> yep, no matter which solution is chosen, let the understanding una= nimously:D
>>> how to handle the older version which is
>>> transferring from server to client?
>>
>> I think it would be cleaner to ask the server to continue sending = an
>> object once it has been started, but ultimately this would be the<= br> >> decision of the server's implementation I think.  Maybe a "SHOULD"
>> requirement.  This could be added if desired. >>
>> Thank you for these questions.  It helps design the requirements more
>> cleanly if there are specific scenarios in front of us :)
>> just discussion together:D and also thanks for your points to help= me
>> understanding more!

>> Rich
>>
>>>> I think that the time the data is removed from disk (or me= mory) should
>>>> be up to the implementation. A storage provider might stil= l have as
>>>> part of some agreement that deleted data will be removed w= ithin X
>>>> days/hours/minutes/whatever.
>>>
>>>    agree with you.
>>>>
>>>> If people in the WG think it is necessary, we could have a= requirement
>>>> that says the protocol should support an argument indicati= ng immediate
>>>> deletion, but it is not clear that we need this.
>>>>
>>>> Rich
>>>>
>>>> >>
>>>> >> Thanks!
>>>> >> Rich
>>>> >>
>>>> >>
>>>> >> On Mon, Dec 27, 2010 at 12:57 AM, =D6=EC=E4=EC <buptxiaozhu@gmail.com> wrote:
>>>> >> > Dear all,
>>>> >> >
>>>> >> > There is a slightly updated version of the d= ecade additional
>>>> >> > requirements
>>>> >> > draft.
>>>> >> >
>>>> >> >
>>>> >> > https://datatracker.ietf.org/doc/draft-zhu-decade-additional-requirements/<= /a>
>>>> >> >
>>>> >> > Jin Peng, Yunfei Zhang and me are expecting = to have a discussion
>>>> >> > with
>>>> >> > all of
>>>> >> > you.
>>>> >> >
>>>> >> > Any comments are appreciated!
>>>> >> >
>>>> >> > A new version of I-D,
>>>> >> > draft-zhu-decade-additional-requirements-00.= txt
>>>> >> > has been successfully submitted by Xiao Zhu = and posted to the IETF
>>>> >> > repository.
>>>> >> >
>>>> >> > Filename:      draft-zhu-decade-additional-requirements >>>> >> > Revision:      00
>>>> >> > Title:                 Additional protocol requirements on DECADE
>>>> >> > Creation_date:         2010-12-27
>>>> >> > WG ID:                 Independent Submission
>>>> >> > Number_of_pages: 10
>>>> >> >
>>>> >> > Abstract:
>>>> >> > The DECoupled Application Data Enroute(DECAD= E)working group is
>>>> >> > specifying standardized interfaces for acces= sing in-network storage
>>>> >> > from applications to store, retrieve and man= age data. The main
>>>> >> > object
>>>> >> > is to provide a framework that is useful to = the applications,
>>>> >> > including P2P applications and other data-or= iented applications,
>>>> >> > possibly related applications that can benef= it from accessing in-
>>>> >> > network storage. This memo focuses on some r= equirements such as
>>>> >> > request redirecting and so on which are on t= he central of mobility,
>>>> >> > wireless network environment and CDN applica= tion. We present these
>>>> >> > in
>>>> >> > this memo as additional requirements that sh= ould be considered for
>>>> >> > the DECADE architecture and protocol specifi= cations.
>>>> >> >
>>>> >> >
>>>> >> >
>>>> >> > The IETF Secretariat.
>>>> >> >
>>>> >> > --
>>>> >> > Best wishes,
>>>> >> >
>>>> >> > Beijing University of Posts & Telecommun= ications (BUPT)
>>>> >> > Zhu Xiao  ( =D6=EC=E4=EC )
>>>> >> > E-mail: buptxiaozhu@gmail.com
>>>> >> > mobile:+86 134-8881-9004
>>>> >> >
>>>> >> > ____________________________________________= ___
>>>> >> > decade mailing list
>>>> >> > decade@ietf.org
>>>> >> > https://www.ietf.org/mailman/listinfo/decade
>>>> >> >
>>>> >> >
>>>> >
>>>> >
>>>> >
>>>> > --
>>>> > Best wishes,
>>>> >
>>>> > Beijing University of Posts & Telecommunications = (BUPT)
>>>> > Zhu Xiao  ( =D6=EC=E4=EC )
>>>> > E-mail: buptxiaozhu@gmail.com
>>>> > mobile:+86 134-8881-9004
>>>
>>>
>>>
>>> --
>>> Best wishes,
>>>
>>> Beijing University of Posts & Telecommunications (BUPT) >>> Zhu Xiao  ( =D6=EC=E4=EC )
>>> E-mail: buptxiaozhu@gmail.com
>>> mobile:+86 134-8881-9004
>>>
>>
>>
>> --
>> Best wishes,
>>
>> Beijing University of Posts & Telecommunications (BUPT)
>> Zhu Xiao  ( =D6=EC=E4=EC )
>> E-mail: buptxiaozhu@gmail.com
>> mobile:+86 134-8881-9004
>



--

Best wishes,

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




--
Best wishes,

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




--
Best wishes,

Bei= jing University of Posts & Telecommunications (BUPT)
Zhu Xiao  = ( =D6=EC=E4=EC )
E-mail: buptxiaozhu@gmail.com
mobile:+86 134-8881-9004
--001517511acea4147b04a6d45ecd-- From richard_woundy@cable.comcast.com Wed Jun 29 01:50:23 2011 Return-Path: X-Original-To: decade@ietfa.amsl.com Delivered-To: decade@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA4CD9E801F for ; Wed, 29 Jun 2011 01:50:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.404 X-Spam-Level: X-Spam-Status: No, score=-103.404 tagged_above=-999 required=5 tests=[AWL=0.556, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I9mr3UU+eCw9 for ; Wed, 29 Jun 2011 01:50:22 -0700 (PDT) Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by ietfa.amsl.com (Postfix) with ESMTP id 7465F9E801C for ; Wed, 29 Jun 2011 01:50:21 -0700 (PDT) Received: from ([24.40.55.42]) by pacdcimo01.cable.comcast.com with ESMTP with TLS id 5503620.132633292; Wed, 29 Jun 2011 04:50:18 -0400 Received: from PACDCEXMB05.cable.comcast.com ([fe80::a5b0:e5c4:df1b:2367]) by PACDCEXHUB01.cable.comcast.com ([fe80::d1e7:20b5:9b63:21a6%12]) with mapi id 14.01.0289.001; Wed, 29 Jun 2011 04:50:18 -0400 From: "Woundy, Richard" To: =?gb2312?B?1uzk7A==?= Thread-Topic: [decade] draft-zhu-decade-additional-requirements Thread-Index: AQHMNHdMnjlmX1MqU0uAgHH8mrKscZTSTrQAgACd46CAAUKWgP//2rFe Date: Wed, 29 Jun 2011 08:50:17 +0000 Message-ID: <1CA25301D2219F40B3AA37201F0EACD1135A3822@PACDCEXMB05.cable.comcast.com> References: <1CA25301D2219F40B3AA37201F0EACD11343C0AB@PACDCEXMB05.cable.comcast.com> <1CA25301D2219F40B3AA37201F0EACD1135A2B0F@PACDCEXMB05.cable.comcast.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [24.40.55.71] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "decade@ietf.org" Subject: Re: [decade] draft-zhu-decade-additional-requirements 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 Jun 2011 08:50:23 -0000 VGhlcmUgaXMgYSBsaW1pdCBvZiBmaXZlIGF1dGhvcnMgb24gYW4gSW50ZXJuZXQgZHJhZnQsIGJ1 dCB5b3UgY291bGQgYmUgbWVudGlvbmVkIGluIHRoZSBBY2tub3dsZWRnbWVudHMgc2VjdGlvbi4N Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkZyb206INbs5OwgW2J1 cHR4aWFvemh1QGdtYWlsLmNvbV0NClNlbnQ6IFdlZG5lc2RheSwgSnVuZSAyOSwgMjAxMSAzOjAy IEFNDQpUbzogV291bmR5LCBSaWNoYXJkDQpDYzogUmljaGFyZCBBbGltaTsgZGVjYWRlQGlldGYu b3JnDQpTdWJqZWN0OiBSZTogW2RlY2FkZV0gZHJhZnQtemh1LWRlY2FkZS1hZGRpdGlvbmFsLXJl cXVpcmVtZW50cw0KDQpoaSwgV291bmR5DQoNCm9rYXkuIHRoYXRgcyBhIGdvb2QgaWRlYS4gSSBy ZW1lbWJlciB3ZSBoYXZlIGEgZGlzY3Vzc2lvbiBvbiB0aGUgYWRkaXRpb25hbCByZXF1aXJlbWVu dHMgaW4gdGhlIGRyYWZ0LXpodS1kZWNhZGUtYWRkaXRpb25hbC1yZXF1aXJlbWVudCBhbmQgd2Ug aGF2ZSByZWFjaGVkIGFncmVlbWVudCBvbiB0aGUgZmlyc3QgcG9pbnRzIHdpdGggUmljaGFyZCBB bGltaS4gIEkgaGF2ZSBubyBzcGVjaWFsIHN1Z2dlc3Rpb24gb24gaG93IG15IHJlcXVpcmVtZW50 cyB3ZXJlIHJlZmxlY3RlZCBpbiBkcmFmdC1pZXRmLWRlY2FkZS1yZXFzLiAgQnV0IHdlLCB0aGUg d3JpdGVycyBvZiB0aGUgZHJhZnQgY291bGQgYmUgYWRkZWQgaW4gdGhlIGNvbnRyaWJ1dG9ycyBv ZiB0aGUgZHJhZnQtaWVmdC1kZWNhZGUtcmVxcy4gV2hhdCBkbyB5b3UgdGhpbmsgb2YgPw0KDQoN CjIwMTEvNi8yOSBXb3VuZHksIFJpY2hhcmQgPFJpY2hhcmRfV291bmR5QGNhYmxlLmNvbWNhc3Qu Y29tPG1haWx0bzpSaWNoYXJkX1dvdW5keUBjYWJsZS5jb21jYXN0LmNvbT4+DQpYaWFvLA0KDQpN eSBwZXJzb25hbCBwcmVmZXJlbmNlIHdvdWxkIGJlIHRvIGxldCBkcmFmdC16aHUtZGVjYWRlLWFk ZGl0aW9uYWwtcmVxdWlyZW1lbnRzIGV4cGlyZSwgYW5kIGVuc3VyZSB0aGF0IHRoZSBrZXkgcmVx dWlyZW1lbnRzIGZyb20geW91ciBkcmFmdCBhcmUgcmVmbGVjdGVkIGluIGRyYWZ0LWlldGYtZGVj YWRlLXJlcXMgd2hpY2ggaXMgdGhlIG9mZmljaWFsIFdHIGRyYWZ0Lg0KDQpEbyB5b3UgaGF2ZSBv YmplY3Rpb25zIGFib3V0IGhvdyB5b3VyIHJlcXVpcmVtZW50cyB3ZXJlIHJlZmxlY3RlZCBpbiBk cmFmdC1pZXRmLWRlY2FkZS1yZXFzPw0KDQotLSBSaWNoDQoNCkZyb206INbs5OwgW21haWx0bzpi dXB0eGlhb3podUBnbWFpbC5jb208bWFpbHRvOmJ1cHR4aWFvemh1QGdtYWlsLmNvbT5dDQpTZW50 OiBNb25kYXksIEp1bmUgMjcsIDIwMTEgMTA6MjMgUE0NClRvOiBSaWNoYXJkIEFsaW1pDQpDYzog V291bmR5LCBSaWNoYXJkOyBkZWNhZGVAaWV0Zi5vcmc8bWFpbHRvOmRlY2FkZUBpZXRmLm9yZz4N Cg0KU3ViamVjdDogUmU6IFtkZWNhZGVdIGRyYWZ0LXpodS1kZWNhZGUtYWRkaXRpb25hbC1yZXF1 aXJlbWVudHMNCg0KaGksIFJpY2hhcmQgYW5kIGV2ZXJ5Ym9keQ0KDQpUaGUgZHJhZnQgZHJhZnQt emh1LWRlY2FkZS1hZGRpdGlvbmFsLXJlcXVpcmVtZW50cyBJIHN1Ym1pdHRlZCBsYXN0IHllYXIg aXMgYWJvdXQgdG8gZXhwaXJlLiBkbyB5b3UgaGF2ZSBzb21lIHN1Z2dlc3Rpb25zIHRvIHVwZGF0 ZSB0aGUgdmVyc2lvbj8gYW5kIGRvIHRoZSBERUNBREUgcmVxdWlyZW1lbnQgZHJhZnQgaGFzIGFk b3B0ZWQgc29tZSBzdWdnZXN0aW9ucyBvZiBteSBkcmFmdD8NCg0KMjAxMS82LzI3INbs5OwgPGJ1 cHR4aWFvemh1QGdtYWlsLmNvbTxtYWlsdG86YnVwdHhpYW96aHVAZ21haWwuY29tPj4NCmhpLCBS aWNoYXJkIGFuZCBldmVyeWJvZHkNCg0KVGhlIGRyYWZ0IGRyYWZ0LXpodS1kZWNhZGUtYWRkaXRp b25hbC1yZXF1aXJlbWVudHMgSSBzdWJtaXR0ZWQgbGFzdCB5ZWFyIGlzIGFib3V0IHRvIGV4cGly ZS4gZG8geW91IGhhdmUgc29tZSBzdWdnZXN0aW9ucyB0byB1cGRhdGUgdGhlIHZlcnNpb24/IGFu ZCBkbyB0aGUgREVDQURFIHJlcXVpcmVtZW50IGRyYWZ0IGhhcyBhZG9wdGVkIHNvbWUgc3VnZ2Vz dGlvbnMgb2YgbXkgZHJhZnQ/DQoNCjIwMTEvMy8xNCBSaWNoYXJkIEFsaW1pIDxyaWNoQHZlbHZl dHNlYS5uZXQ8bWFpbHRvOnJpY2hAdmVsdmV0c2VhLm5ldD4+DQpIaSBBbGwsDQoNCldlJ3ZlIG1h ZGUgYWxsIG9mIHRoZXNlIHVwZGF0ZXMgdG8gdGhlIHJlcXVpcmVtZW50cyBkb2N1bWVudCwgd2l0 aCB0aGUNCmV4Y2VwdGlvbiBvZjoNCg0KPiAtIElmIGFuIG9iamVjdCBpcyBkZWxldGVkIGFzIGl0 IGlzIGNvbmN1cnJlbnRseSBiZWluZyByZWFkLCB0aGVuIHRoZQ0KPiBzZXJ2ZXIgTUFZIGNvbnRp bnVlIHRvIHJlYWQgaXQgKGxhenkgZGVsZXRpb24pLCBvciBpdCBNQVkgZGlzY29udGludWUNCj4g cmVhZGluZyB0aGUgb2JqZWN0IGFuZCBzaWduYWwgYW4gZXJyb3IgdG8gdGhlIGNsaWVudCByZWFk aW5nIHRoZQ0KPiBvYmplY3QuDQoNClVwb24gbG9va2luZyBhdCB0aGlzIGFnYWluLCBpdCBsb29r cyBtb3JlIGxpa2UgYW4gaW1wbGVtZW50YXRpb24NCmRldGFpbC4gSWYgYW55dGhpbmcsIHRoaXMg d291bGQgcmVzdWx0IGluIGEgIm5vbi1yZXF1aXJlbWVudCIgaW4gdGhlDQpkb2N1bWVudC4gSG93 ZXZlciwgaXQgc2VlbXMgbGlrZSBhIGZhaXJseSBsb3ctbGV2ZWwgbm9uLXJlcXVpcmVtZW50IHRv DQpzdGF0ZSBhdCB0aGlzIHRpbWUuIEknZCBwcm9wb3NlIHRvIGxlYXZlIGl0IG91dCBmb3Igbm93 IGFuZCByZXZpc2l0DQp0aGlzIGlmIGl0IGNvbWVzIHVwIGFnYWluIGluIHRoZSBmdXR1cmUuICBU aG91Z2h0cz8NCg0KVGhhbmtzLA0KUmljaA0KDQoyMDExLzMvMiBSaWNoYXJkIEFsaW1pIDxyaWNo QHZlbHZldHNlYS5uZXQ8bWFpbHRvOnJpY2hAdmVsdmV0c2VhLm5ldD4+Og0KPiBIaSBBbGwsDQo+ DQo+IEknbGwgb2ZmZXIgYSBzdW1tYXJ5IG9mIHRoaXMgZGlzY3Vzc2lvbi4gTGV0IG1lIGtub3cg aWYgSSBtaXNzZWQNCj4gYW55dGhpbmcsIG9yIGlmIHRoZXJlIGFyZSBvYmplY3Rpb25zL290aGVy IHRob3VnaHRzIG9uIHRoZXNlIHByb3Bvc2VkDQo+IHJlc29sdXRpb25zLg0KPg0KPiBSZWRpcmVj dGlvbjoNCj4gLSBXZSBjYW4gYWRkIGEgcmVxdWlyZW1lbnQgbWVudGlvbmluZyB0aGF0IERFQ0FE RSBtYXkgc3VwcG9ydCByZWRpcmVjdGlvbi4NCj4NCj4gRGF0YSBDbGFzc2lmaWNhdGlvbjoNCj4g LSBJIChwZXJzb25hbGx5KSBzdHJvbmdseSBkaXNhZ3JlZSB3aXRoIGF0dGVtcHRpbmcgdG8gY2xh c3NpZnkgYWNjZXNzDQo+IHBhdHRlcm5zIG9yIGFwcGxpY2F0aW9ucy4gV2UgY291bGQgYWRkIHNv bWV0aGluZyBzYXlpbmcgdGhhdCBleHBsaWNpdA0KPiBoaW50cyAoYSBsYSB3d3cuaWV0Zi5vcmcv cHJvY2VlZGluZ3MvNzgvc2xpZGVzL25mc3Y0LTAucGRmPGh0dHA6Ly93d3cuaWV0Zi5vcmcvcHJv Y2VlZGluZ3MvNzgvc2xpZGVzL25mc3Y0LTAucGRmPikgY291bGQgYmUNCj4gcHJvdmlkZWQgaW4g REVDQURFLiAgSG93ZXZlciwgSSBkb24ndCB0aGluayB3ZSBuZWVkIHRvIGRvIHNvbWV0aGluZw0K PiBuZXcgaGVyZS4gSW4gcGFydGljdWxhciwgaWYgdGhlIHVuZGVybHlpbmcgc3RvcmFnZS9kYXRh IHRyYW5zcG9ydA0KPiBzdXBwb3J0cyBoaW50cywgYSBERUNBREUgY2xpZW50IG9yIHNlcnZlciBj YW4gdXNlIGl0Lg0KPg0KPiBTdG9yYWdlIFN0YXR1czoNCj4gLSBVcGRhdGUgc2VjdGlvbiA1LjEu NiB0byBpbmRpY2F0ZSB0aGF0IHN0YXR1cyBpbmZvcm1hdGlvbiBzaG91bGQNCj4gaW5jbHVkZSBw ZXJtaXNzaW9ucyBvZiBzdG9yZWQgb2JqZWN0cywgaWYgYXBwbGljYWJsZS4NCj4gLSBVcGRhdGUg NS4xLjYgdG8gaW5kaWNhdGUgdGhhdCBzdGF0dXMgaW5mb3JtYXRpb24gc2hvdWxkIGluY2x1ZGUN Cj4gb3RoZXIgaW5mb3JtYXRpb24gYWJvdXQgcmVzb3VyY2UgdXNhZ2UgKHRoZSBjbGllbnRzIG93 biByZXNvdXJjZXMsIG9yDQo+IHJlc291cmNlcyB1c2VkIGJ5IG90aGVyIGNsaWVudHMgdGhhdCBo YXZlIGJlZW4gYXV0aG9yaXplZCB0bw0KPiByZWFkL3dyaXRlIG9iamVjdHMgb3Igb3BlbiBjb25u ZWN0aW9ucyB0byBvbmUncyBzdG9yYWdlKS4NCj4NCj4gUmVxdWlyZW1lbnRzIGZvciBvYmplY3Qg ZGVsZXRpb24vb3ZlcndyaXRpbmc6DQo+IC0gREVDQURFIE1BWSBoYXZlIGFuIG92ZXJ3cml0ZSBm bGFnIChub3RlIHRoYXQgdGhpcyBtYXkgb3IgbWF5IG5vdCBiZQ0KPiBuZWNlc3NhcnkgZGVwZW5k aW5nIG9uIG91ciBuYW1pbmcsIGJ1dCB0aGUgcmVxdWlyZW1lbnRzIGRvY3VtZW50DQo+IHByb2Jh Ymx5IGlzIG5vdCB0aGUgcGxhY2UgdG8gdGFrZSBhIHN0YW5kIG9uIHRoaXMgYXQgdGhlIGN1cnJl bnQNCj4gcG9pbnQuKQ0KPiAtIElmIGFuIG9iamVjdCBpcyBkZWxldGVkIGFzIGl0IGlzIGNvbmN1 cnJlbnRseSBiZWluZyByZWFkLCB0aGVuIHRoZQ0KPiBzZXJ2ZXIgTUFZIGNvbnRpbnVlIHRvIHJl YWQgaXQgKGxhenkgZGVsZXRpb24pLCBvciBpdCBNQVkgZGlzY29udGludWUNCj4gcmVhZGluZyB0 aGUgb2JqZWN0IGFuZCBzaWduYWwgYW4gZXJyb3IgdG8gdGhlIGNsaWVudCByZWFkaW5nIHRoZQ0K PiBvYmplY3QuDQo+DQo+IFdvdWxkIHRoaXMgYmUgc3VmZmljaWVudCB0byBtZXJnZSBpbiB0aGUg cG9pbnRzIGZyb20NCj4gZHJhZnQtemh1LWRlY2FkZS1hZGRpdGlvbmFsLXJlcXVpcmVtZW50cy0w MCBhbmQgdGhpcyBlbnN1aW5nDQo+IGRpc2N1c3Npb24/DQo+DQo+IFRoYW5rcywNCj4gUmljaA0K Pg0KPg0KPiAyMDExLzMvMiBXb3VuZHksIFJpY2hhcmQgPFJpY2hhcmRfV291bmR5QGNhYmxlLmNv bWNhc3QuY29tPG1haWx0bzpSaWNoYXJkX1dvdW5keUBjYWJsZS5jb21jYXN0LmNvbT4+Og0KPj4g Rm9sa3MsDQo+Pg0KPj4NCj4+DQo+PiBEbyB3ZSBoYXZlIGNvbnNlbnN1cyB5ZXQgYWJvdXQgaG93 IHRoZSBXRyBjb3VsZCBoYXZlIGEgc2luZ2xlIERFQ0FERQ0KPj4gcmVxdWlyZW1lbnRzIGRvY3Vt ZW50IGdvaW5nIGZvcndhcmQ/IEkgY2FuJ3QgdGVsbCB0aGUgc3RhdGUgb2Ygb3VyDQo+PiByZXF1 aXJlbWVudHMgY29uc29saWRhdGlvbiBmcm9tIHRoZSBlbWFpbCB0aHJlYWQgYmVsb3cuDQo+Pg0K Pj4NCj4+DQo+PiBJdCB3b3VsZCBiZSBwcmVmZXJhYmxlIGlmIHdlIGNvdWxkIHJlc29sdmUgdGhp cyBmdWxseSBvbiB0aGUgV0cgbWFpbGluZw0KPj4gbGlzdCwgYnV0IHRoaXMgaXMgaW1wb3J0YW50 IGVub3VnaCB0byBhbGxvY2F0ZSBzb21lIHRpbWUgYXQgb3VyIG1lZXRpbmcgaW4NCj4+IFByYWd1 ZS4NCj4+DQo+Pg0KPj4NCj4+IC0tIFJpY2gNCj4+DQo+Pg0KPj4NCj4+IEZyb206IGRlY2FkZS1i b3VuY2VzQGlldGYub3JnPG1haWx0bzpkZWNhZGUtYm91bmNlc0BpZXRmLm9yZz4gW21haWx0bzpk ZWNhZGUtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86ZGVjYWRlLWJvdW5jZXNAaWV0Zi5vcmc+XSBP biBCZWhhbGYgT2YNCj4+ID8/DQo+PiBTZW50OiBTdW5kYXksIEphbnVhcnkgMTYsIDIwMTEgOTow MiBQTQ0KPj4gVG86IFJpY2hhcmQgQWxpbWkNCj4+IENjOiBkZWNhZGVAaWV0Zi5vcmc8bWFpbHRv OmRlY2FkZUBpZXRmLm9yZz4NCj4+IFN1YmplY3Q6IFJlOiBbZGVjYWRlXSBkcmFmdC16aHUtZGVj YWRlLWFkZGl0aW9uYWwtcmVxdWlyZW1lbnRzDQo+Pg0KPj4NCj4+DQo+PiBoaSwgUmljaGFyZDoN Cj4+DQo+Pg0KPj4NCj4+IHRoYW5rcyBmb3IgeW91ciByZXBseTpEDQo+Pg0KPj4gYWRkaXRpb25h bCBkaXNjdXNzaW9uIHNlZSBpbmxpbmU6RA0KPj4NCj4+DQo+Pg0KPj4gMjAxMS8xLzE0IFJpY2hh cmQgQWxpbWkgPHJpY2hAdmVsdmV0c2VhLm5ldDxtYWlsdG86cmljaEB2ZWx2ZXRzZWEubmV0Pj4N Cj4+DQo+PiBISSBYaWFvLA0KPj4NCj4+IDIwMTEvMS8xMiDW7OTsIDxidXB0eGlhb3podUBnbWFp bC5jb208bWFpbHRvOmJ1cHR4aWFvemh1QGdtYWlsLmNvbT4+Og0KPj4NCj4+PiBoaSwgUmljaGFy ZA0KPj4+IHNlZSBpbmxpbmU6RA0KPj4+DQo+Pj4gMjAxMS8xLzExIFJpY2hhcmQgQWxpbWkgPHJp Y2hAdmVsdmV0c2VhLm5ldDxtYWlsdG86cmljaEB2ZWx2ZXRzZWEubmV0Pj4NCj4+Pj4NCj4+Pj4g SGkgWGlhbywNCj4+Pj4NCj4+Pj4gT24gTW9uLCBKYW4gMTAsIDIwMTEgYXQgNjo0NSBQTSwg1uzk 7CA8YnVwdHhpYW96aHVAZ21haWwuY29tPG1haWx0bzpidXB0eGlhb3podUBnbWFpbC5jb20+PiB3 cm90ZToNCj4+Pj4gPg0KPj4+PiA+IGhpLCBSaWNoYXJkLCBzb3JyeSBmb3Igc28gbGF0ZSByZXNw b25zZSBiZWNhdXNlIG9mIGJlIGJ1c3kgd2l0aCBvdGhlcg0KPj4+PiA+IHByb2plY3RzLg0KPj4+ PiA+IHNvbWUgZGlzY3Vzc2lvbiBzZWUgaW5saW5lOkQgbWFya2VkIGJ5IHJlZC4NCj4+Pj4gPg0K Pj4+PiA+IE9uIFR1ZSwgSmFuIDQsIDIwMTEgYXQgNDowNiBBTSwgUmljaGFyZCBBbGltaSA8cmlj aEB2ZWx2ZXRzZWEubmV0PG1haWx0bzpyaWNoQHZlbHZldHNlYS5uZXQ+Pg0KPj4+PiA+IHdyb3Rl Og0KPj4+PiA+Pg0KPj4+PiA+PiBIaSBYaWFvLA0KPj4+PiA+Pg0KPj4+PiA+PiBUaGFuayB5b3Ug Zm9yIHRoZSBkcmFmdC4gIFNvbWUgY29tbWVudHMgb24gdGhlIHJlcXVpcmVtZW50czoNCj4+Pj4g Pj4NCj4+Pj4gPj4gUmVxdWVzdCBSZWRpcmVjdHM6DQo+Pj4+ID4+DQo+Pj4+ID4+IFRoaXMgd291 bGQgcHJvdmlkZSBzb21lIGFkZGl0aW9uYWwgZnJlZWRvbSBmb3IgdGhlIHN0b3JhZ2UgcHJvdmlk ZXIuDQo+Pj4+ID4+IEkgdGhpbmsgaXQgaXMgcmVhc29uYWJsZSBzaW5jZSBpdCBkb2Vzbid0IG5l Y2Vzc2l0YXRlIGFkZGl0aW9uYWwNCj4+Pj4gPj4gY29tcGxleGl0eSBmb3IgdGhlIERFQ0FERSBz ZXJ2ZXIsIGJ1dCBhbGxvd3MgaXQgaWYgZGVzaXJlZC4gSG93ZXZlciwNCj4+Pj4gPj4gbm90ZSB0 aGF0IGl0IG1heSBjb21wbGljYXRlIHNvbWUgb2YgdGhlIG90aGVyIGNvbXBvbmVudHMgb2YgdGhl DQo+Pj4+ID4+IGRlc2lnbi4gSW4gcGFydGljdWxhciwgaWYgdGhlcmUgaXMgYSBwZXItdXNlciBx dW90YSBmb3Igc3RvcmFnZSwgaXMNCj4+Pj4gPj4gdGhlIHVzZXIgbWFkZSBhd2FyZSBvZiB0aGUg cXVvdGEgYXQgZWFjaCBpbi1uZXR3b3JrIHN0b3JhZ2UgKGlmIHRoZXJlDQo+Pj4+ID4+IGlzIG5v IHNoYXJlZCBzdG9yYWdlIGJldHdlZW4gdGhlbSk/ICBSZXNvdXJjZSBzaGFyaW5nIHBvbGljaWVz IG1heSBiZQ0KPj4+PiA+PiBpbXBhY3RlZCAoZS5nLiwgaWYgYSBiYW5kd2lkdGggc2hhcmluZyB3 ZWlnaHQgb2YgMSBtYXkgbWVhbiBzb21ldGhpbmcNCj4+Pj4gPj4gZGlmZmVyZW50IGF0IERFQ0FE RSBzZXJ2ZXIgQSB0aGFuIGl0IGRvZXMgYXQgREVDQURFIHNlcnZlciBCKS4gIEF0DQo+Pj4+ID4+ IHRoaXMgcG9pbnQgaXQgbWF5IGJlIGJlc3QgdG8ganVzdCBub3RlIHRoZXNlIHNvIHRoZXkgYXJl IGRvY3VtZW50ZWQsDQo+Pj4+ID4+IGJ1dCBzaW5jZSB0aGUgc3BlY2lmaWNhdGlvbiBvZiB0aGUg cmVzb3VyY2Ugc2hhcmluZyBwb2xpY2llcyBhcmUgc3RpbGwNCj4+Pj4gPj4gYmVpbmcgY29udGVt cGxhdGVkIGZvciB0aGUgYmFzaWMgY2FzZSBvZiBhIHNpbmdsZSBzZXJ2ZXIgaXQgbWF5IGJlDQo+ Pj4+ID4+IHByZW1hdHVyZSB0byBldmVuIHRyeSBhbmQgc29sdmUgdGhlbSBmb3IgdGhlIGNhc2Ug c3VwcG9ydGluZw0KPj4+PiA+PiByZWRpcmVjdGlvbi4NCj4+Pj4gPj4NCj4+Pj4gPiBhY3R1YWxs eSwgeW91IG1lYW4gdHdvIHBvaW50cywgcmlnaHQ/DQo+Pj4+ID4gMS4gd2hldGhlciBvciBub3Qg dG8gYmUgd2FyZSBvZiB0aGUgY29udGVudCBhdCBlYWNoIGluLW5ldHdvcmsgc3RvcmFnZQ0KPj4+ PiA+IGFuZCBvZiBjb3Vyc2UgcmVzb3VyY2Ugc2hhcmluZyBwb2xpY2llcyBjYW4gYmUgaW1wYWN0 IGluIHRoZSByZXF1ZXN0DQo+Pj4+ID4gcmVkaXJlY3Rpb24uIHlvdXIgc3VnZ2VzdGlvbiJqdXN0 IHRvIG5vdGUgdGhlc2Ugc28gdGhleSBhcmUgZG9jdW1lbnRlZCINCj4+Pj4gPiB3aWxsDQo+Pj4+ ID4gYmUgb2ssIG9yIERFQ0FERSBzZXJ2ZXIgbGlzdCB3aXRoIHNvbWUgcGFyYW1ldGVycyB3aWxs IGJlIHJldHVybiBmb3INCj4+Pj4gPiB1c2VyIHRvDQo+Pj4+ID4gc2VsZWN0IHRoZSBhcHByb3By aWF0ZSBERUNBREUgc2VydmVyLCB3aGljaCBjYW4gYXZvaWQgdGhlIGRpZmZlcmVudA0KPj4+PiA+ IHdlaWdodGVkDQo+Pj4+ID4gb2YgdGhlIHNhbWUgcGFyYW1ldGVyIGluIHNlcnZlciBkZWNpc2lv bi4gYnV0IHRoZSBwYXJhbWV0ZXIgdXNlZCBpbg0KPj4+PiA+IHNlbGVjdA0KPj4+PiA+IHRoZSBi ZXN0IERFQ0FERSBzZXJ2ZXIgd2lsbCBiZSBrbm93biBmb3IgREVDQURFIHNlcnZlcnMsIGluIHdo aWNoIG90aGVyDQo+Pj4+ID4gY29tcGxleGl0aWVzIHdpbGwgYmUgYWRkZWQuIGFueXdheSwgYWxs IHRoZSBzb2x1dGlvbiBhcmUgdGhlDQo+Pj4+ID4gaW1wbGVtZW50YXRpb24NCj4+Pj4gPiBpc3N1 ZSwgd2hpY2gsIGkgYmVsaWV2ZSwgZG9lcyBub3QgaW1wYWN0IHRoZSBuZWNlc3NpdHkgb2YgdGhl DQo+Pj4+ID4gcmVxdWlyZW1lbnQuDQo+Pj4+DQo+Pj4+IEluIGdlbmVyYWwsIEknZCBhZ3JlZSB0 aGF0IHRoZSBkZWNpc2lvbiBhYm91dCB3aGVyZSB0byByZWRpcmVjdCB3b3VsZA0KPj4+PiBiZSBh biBpbXBsZW1lbnRhdGlvbiBpc3N1ZS4NCj4+Pj4NCj4+Pj4gPg0KPj4+PiA+IDIuIHlvdSBtZWFu ICJ0aGUgcmVzb3VyY2Ugc2hhcmluZyBwb2xpY2llcyBhcmUgc3RpbGwgYmVpbmcgY29uc2lkZXJl ZA0KPj4+PiA+IGluDQo+Pj4+ID4gYSBzaW5nbGUgc2VydmVyIiwgc28gaXQgbWF5IGJlIHByZW1h dHVyZSB0byBzdXBwb3J0IHJlZGlyZWN0aW9uLiAgdGhlDQo+Pj4+ID4gYXJjaGl0ZWN0dXJlIGFu ZCBwcm90b2NvbCB3aWxsIGJlIGJhZGx5IGltcGFjdGVkIGlmIHRoZSByZXF1aXJlbWVudHMNCj4+ Pj4gPiBjaGFuZ2UuDQo+Pj4+ID4gc28gdGhlIGRlc2lnbmluZyBjYW4gYmUgIHRha2VuICBzdGVw IGJ5IHN0ZXAsIGJ1dCB0aGUgcmVxdWlyZW1lbnRzDQo+Pj4+ID4gc2hvdWxkIGJlDQo+Pj4+ID4g b3ZlcmFsbCBjb25zaWRlcmVkLg0KPj4+Pg0KPj4+PiBJIHNhaWQgdGhhdCBpdCBpcyBwcm9iYWJs eSBwcmVtYXR1cmUgdG8gY29uc2lkZXIgaG93IHJlc291cmNlIHNoYXJpbmcNCj4+Pj4gcG9saWNp ZXMgd29ya3MgYWNyb3NzIHNlcnZlcnMgKG9yIGV2ZW4gaWYgd2UgbmVlZCB0byBzYXkgYW55dGhp bmcNCj4+Pj4gYWJvdXQgaXQpIHNpbmNlIHdlIGhhdmUgbm90IGRldGVybWluZWQgaG93IHRvIHNw ZWNpZnkgdGhlbSAob3IgcmF0aGVyLA0KPj4+PiBob3cgbGl0dGxlIHdlIG5lZWQgdG8gc3BlY2lm eSBpbiBwcm90b2NvbCkgZm9yIGEgc2luZ2xlIHNlcnZlci4gSSBkaWQNCj4+Pj4gbm90IG1lYW4g dG8gaW1wbHkgdGhhdCByZWRpcmVjdGlvbiBjb3VsZCBub3QgYmUgaW50cm9kdWNlZCBhcyBhDQo+ Pj4+IHJlcXVpcmVtZW50Lg0KPj4+Pg0KPj4+DQo+Pj4+DQo+Pj4+ID4NCj4+Pj4gPg0KPj4+PiA+ Pg0KPj4+PiA+PiBNdWx0aS1jb25uZWN0aW9uOg0KPj4+PiA+Pg0KPj4+PiA+PiBJJ20gbm90IHF1 aXRlIGNsZWFyIG9uIHRoZSBpbnRlbnRpb24gb2YgdGhlIHJlcXVpcmVtZW50LiAgTXkNCj4+Pj4g Pj4gdW5kZXJzdGFuZGluZyBpcyB0aGF0IHlvdSB3aXNoIHRoZSBjbGllbnQgdG8gYmUgYWJsZSB0 byBoYXZlIG11bHRpcGxlDQo+Pj4+ID4+IGNvbm5lY3Rpb25zIG9wZW4gc3Bhbm5pbmcgbXVsdGlw bGUgREVDQURFIHNlcnZlcnMuIElzIHRoYXQgY29ycmVjdD8NCj4+Pj4gPj4NCj4+Pj4gPj4gSWYg c28sIGRvIHdlIG5lZWQgdGhpcyBzdGF0ZWQgYXMgYSByZXF1aXJlbWVudCBvciB0aGUgcHJvdG9j b2w/IE9yIGlzDQo+Pj4+ID4+IHRoaXMgYSBwb2xpY3kgdGhhdCB3b3VsZCBiZSBhbGxvd2VkL2Rp c2FsbG93ZWQgYnkgdGhlIHN0b3JhZ2UNCj4+Pj4gPj4gcHJvdmlkZXI/DQo+Pj4+ID4+DQo+Pj4+ ID4geWVwLCB5b3VyIHVuZGVyc3RhbmRpbmcgaXMgcmlnaHQsIHRoZSBzY2VuYXJpb3Mgd2VyZSBq dXN0IGRlc2NyaWJlZCBpbg0KPj4+PiA+IGRyYWZ0IGFzICJzb2Z0IGhhbmRvdmVyIGluIHdpcmVs ZXNzIGVudmlyb25tZW50IGFuZCBkZWxldGUgb3BlcmF0aW9uIGluDQo+Pj4+ID4gbXVsdGktc2Vy dmVycyIuIHVuZGVyIHRoZXNlIGNvbnNpZGVyYXRpb24sIHRoZSBhdXRoZW50aWNhdGlvbiBhbmQN Cj4+Pj4gPiBhdXRob3JpemF0aW9uIG5lZWQgdG8gYmUgdGFrZW4gZWFjaCB0aW1lIHdoZW4gc2V0 dXAgY29ubmVjdGlvbiB3aXRoIGENCj4+Pj4gPiBuZXcNCj4+Pj4gPiBERUNBREUgc2VydmVyLCBv ciBqdXN0IGJlIHRha2VuIG9ubHkgb25jZSBkdXJpbmcgIHRoZSBzZXJ2aWNlPw0KPj4+Pg0KPj4+ PiBUaGUgREVDQURFIHNlcnZlciBzaG91bGQgbmVlZCB0byBkbyBzb21lIHNvcnQgb2YgY2hlY2sg b24gZWFjaCBuZXcNCj4+Pj4gY29ubmVjdGlvbiwgcmVnYXJkbGVzcyBvZiB3aGV0aGVyIHRoZSB1 c2VyIGhhcyBvciBwcmV2aW91c2x5IGhhZCBhDQo+Pj4+IGNvbm5lY3Rpb24gb3BlbiB0byBhIGRp ZmZlcmVudCBERUNBREUgc2VydmVyLCByaWdodD8gIE5vdGUgdGhhdCB0aGUNCj4+Pj4gcmVxdWly ZW1lbnRzIGRvbid0IGluZGljYXRlIGhvdyBhdXRoZW50aWNhdGlvbiBvciBhdXRob3JpemF0aW9u IGlzDQo+Pj4+IGRvbmUsIGFuZCBhbGxvdyBhIHNlcnZlciB0byBtYWtlIG9wdGltaXphdGlvbnMg aWYgaXQgaXMgZW5mb3JjaW5nIHRoZQ0KPj4+PiBzYW1lIHBlcm1pc3Npb25zLg0KPj4+Pg0KPj4+ PiBDYW4geW91IGluZGljYXRlIHdoZXJlIHRoZSBleGlzdGluZyBhdXRob3JpemF0aW9uLXJlbGF0 ZWQgcmVxdWlyZW1lbnRzDQo+Pj4+IChpbiBwYXJ0aWN1bGFyLCA0LjEuNi4zIG9mIGRyYWZ0LWll dGYtZGVjYWRlLXJlcXMtMDApIGRvIG5vdCBzdWZmaWNlDQo+Pj4+IGZvciB0aGUgdXNlIGNhc2Ug eW91IGFyZSB0aGlua2luZyBvZj8NCj4+DQo+Pj4gYXMgY29uc2lkZXJpbmcgdGhlIHNlcnZpY2Ug Y29udGludWl0eSwgdGhlIG5leHQgc2VydmluZyAgREVDQURFIHNlcnZlcg0KPj4+IHNob3VsZCBr bm93IHRoZSBwcm9ncmVzcyBvZiB0aGUgc2VydmljZSwgaG93IGRvZXMgdGhleSBrbm93Pw0KPj4N Cj4+IEJ5IHByb2dyZXNzIG9mIHRoZSBzZXJ2aWNlLCBkbyB5b3UgbWVhbiBjdXJyZW50IHVzZXIg c3RhdGUgKGUuZy4sDQo+PiBxdW90YSwgcmVjZW50IHJlc291cmNlIHVzYWdlIGhpc3RvcnksIHBl cm1pc3Npb25zLCBldGMpPw0KPj4NCj4+IHllcywgYW5kIGluY2x1ZGUgZGF0YSBkZWxpdmVyeSBw cm9jZWVkaW5nLg0KPj4+IHNvIGlmIHRoZQ0KPj4+IHNlcnZpY2UgcHJvY2VlZGluZyBpbmZvcm1h dGlvbiBzaG91bGQgYmUga25vd24gYnkgdGhlIG5leHQgc2VydmluZyBzZXJ2ZXIsDQo+Pj4gb3Ig ZGlmZmVyZW50IHNlcnZlcnMgbmVlZCB0byBjb29yZGluYXRlIGFuZCBzY2hlZHVsZSBlYWNoIG90 aGVyIHRvIGZ1bGZpbGwNCj4+PiB0aGUgdXNlciByZXF1ZXN0LCBpIGJlbGlldmUgdGhlIHRoZSA0 LjEuNi4zIG9mIHRoZQ0KPj4+IGRyYWZ0LWlldGYtZGVjYWRlLXJlcS0wMA0KPj4+IGNhbm5vdCBz YXRpc2Z5IHRoZSByZXEuIHdoYXQgZG8geW91IHRoaW5rIGFib3V0Pw0KPj4NCj4+IE5vdGUgdGhh dCB0aGUgcHJvdG9jb2wgdGhhdCBpcyBjb3ZlcmVkIGhlcmUgaXMgdGhlIGNsaWVudC1zZXJ2ZXIN Cj4+IHByb3RvY29sLiBTb21lIG9mIHRoZSBzYW1lIHByb3RvY29sIG1heSBiZSB1c2VmdWwgYmV0 d2VlbiBERUNBREUNCj4+IHNlcnZlcnMgKGVzcGVjaWFsbHkgaW4gZGlmZmVyZW50IGFkbWluaXN0 cmF0aXZlIGRvbWFpbnMpIGZvciBzdG9yaW5nDQo+PiBhbmQgcmV0cmlldmluZyBkYXRhLCBidXQg dGhhdCBkb2VzIG5vdCBtZWFuIHRoYXQgdGhlcmUgY2FuJ3QgYmUNCj4+IGFkZGl0aW9uYWwgcHJv dG9jb2wocykgKG5vdCBzcGVjaWZpZWQgaGVyZSkgdGhhdCBhcmUgdXNlZCBiZXR3ZWVuDQo+PiBE RUNBREUgc2VydmVycyBhcyB3ZWxsLiAgRm9yIGV4YW1wbGUsIGlmIERFQ0FERSBzZXJ2ZXJzIHdp dGhpbiBhbg0KPj4gYWRtaW5pc3RyYXRpdmUgZG9tYWluIGNhbiBjZXJ0YWlubHkgaGF2ZSB0aGVp ciBvd24gbWVjaGFuaXNtIHRvIHNoYXJlDQo+PiBzdWNoIGluZm9ybWF0aW9uLiAgSWYgc3VjaCBj YXBhYmlsaXRpZXMgd2VyZSBpbmNsdWRlZCBpbiB0aGUgREVDQURFDQo+PiBwcm90b2NvbCAoZS5n LiwgYSBuZWVkIHRvIGRvIHRoaXMgYmV0d2VlbiBhZG1pbmlzdHJhdGl2ZSBkb21haW5zKSwNCj4+ IHRoYXQgc291bmRzIGxpa2UgbG90cyBtb3JlIGNvbXBsZXhpdHkgdGhhdCB3ZSBuZWVkIGF0IHRo aXMgcG9pbnQuDQo+PiBidXQgdGhlIGFjY2VzcyBiZXR3ZWVuIGluLW5ldHdvcmsgc3RvcmFnZSBh bHNvIGlzIGluY2x1ZGVkIGluIElBUCBkZXNjcmliZWQNCj4+IGluIHByb2JsZW0gc3RhdGVtZW50 LiAgaSBtZWFuIHdoeSBub3QgcHV0IHRoaXMga2luZCBvZiBmdW5jdGlvbiBpbiBERUNBREUNCj4+ IHNpbmNlIHRoZSBJQVAgaXMgZGVmaW5lZCBqdXN0IGxpa2UgdGhhdD8NCj4+IFRoYXQgc2FpZCwg aXQgc291bmRzIHRvIG1lIGxpa2Ugd2hhdCBpcyBkZXNjcmliZWQgaW4gNC4xLjYuMyB3b3VsZCBi ZQ0KPj4gc3VmZmljaWVudCAoZnJvbSB0aGUgcGVyc3BlY3RpdmUgb2YgdGhlIGNsaWVudC1zZXJ2 ZXIgcHJvdG9jb2wsDQo+PiBhbnl3YXlzKSB0byBpbXBsZW1lbnQgd2hhdCB5b3UncmUgZGVzY3Jp YmluZy4gSWYgbm90LCB3aGF0DQo+PiBzcGVjaWZpY2FsbHkgaXMgbWlzc2luZyBhbmQgd2hhdCB1 c2UtY2FzZSBkb2VzIGl0IG5vdCBtZWV0Pw0KPj4NCj4+IHNvIHlvdSBtZWFuIHRoZSBpbmZvcm1h dGlvbiB5b3UgbWVudGlvbmVkIGFib3ZlLCBqdXN0IGxpa2UgY3VycmVudCB1c2VyDQo+PiBzdGF0 ZSAoZS5nLiwNCj4+IHF1b3RhLCByZWNlbnQgcmVzb3VyY2UgdXNhZ2UgaGlzdG9yeSwgcGVybWlz c2lvbnMsIGV0Yykgd2FzIGFscmVhZHkgaW5jbHVkZWQNCj4+IGluIERFQ0FERSByZXF1aXJlbWVu dD8gd2hhdCBhYm91dCB0aGUgZGF0YSBkZWxpdmVyeSBwcm9jZWVkaW5nIGluZm9ybWF0aW9uPw0K Pj4gY2FuIHlvdSBzcGVjaWZ5IHRoZSBjaGFwdGVyIGZvciBtZSA/IHRoYW5rcz8NCj4+Pj4gPg0K Pj4+PiA+DQo+Pj4+ID4+DQo+Pj4+ID4+IERhdGEgRGlzdHJpYnV0aW9uOg0KPj4+PiA+Pg0KPj4+ PiA+PiBJJ20gYWxzbyBjb25mdXNlZCBhYm91dCB0aGUgaW50ZW50IG9mIHRoaXMgcmVxdWlyZW1l bnQuICBUaGlzDQo+Pj4+ID4+IHN0YXRlbWVudCBoYXMgbWUgc29tZXdoYXQgd29ycmllZDogIlRo ZSBkaXN0cmlidXRpb24gaXMgdHJhbnNwYXJlbnQgdG8NCj4+Pj4gPj4gdGhlIHVzZXJzIGFzIHRo ZXkgaW50ZXJhY3Qgd2l0aCB0aGUgaW4tbmV0d29yayBzdG9yYWdlIGFzIGEgc2luZ2xlDQo+Pj4+ ID4+IGxvZ2ljYWwgc3lzdGVtLiIgRG9lcyB0aGlzIG1lYW4gdGhhdCB5b3UgYXJlIHByb3Bvc2lu ZyBmb3IgREVDQURFDQo+Pj4+ID4+IHNlcnZlcnMgdG8gYXNzdW1lIHRoZSByZXNwb25zaWJpbGl0 eSBmb3IgZGVjaWRpbmcgaG93IGRhdGEgaXMgdG8gYmUNCj4+Pj4gPj4gZGlzdHJpYnV0ZWQgdGhy b3VnaG91dCB0aGUgbmV0d29yaywgaW5jbHVkaW5nIHRoZSBwYXRoIG9mIHRoZSBkYXRhLA0KPj4+ PiA+PiB3aGljaCBzZXJ2ZXJzIGFjdCBhcyBpbnRlcm1lZGlhdGUgY2FjaGVzLCBjb250ZW50IGV4 cGlyYXRpb24gcG9saWNpZXMsDQo+Pj4+ID4+IGV0Yz8gIElmIHRoaXMgaXMgdHJ1ZSwgSSB0aGlu ayBpdCBpcyBtaXNzaW5nIG9uZSBvZiB0aGUgbWFqb3IgcG9pbnRzDQo+Pj4+ID4+IG9mIERFQ0FE RS4gSW4gcGFydGljdWxhciwgdGhlc2UgZGVjaXNpb25zIGFyZSBhcHBsaWNhdGlvbi1kZXBlbmRl bnQNCj4+Pj4gPj4gYW5kIGFyZSBub3QgaW1wbGVtZW50ZWQgd2l0aGluIERFQ0FERS4gSW5zdGVh ZCwgREVDQURFIHByb3ZpZGVzIHRoZQ0KPj4+PiA+PiBiYXNpYyBjYXBhYmlsaXRpZXMgYW5kIHRo ZSBmdW5jdGlvbmFsaXR5IGRlc2NyaWJlZCBhYm92ZSBhcmUNCj4+Pj4gPj4gaW1wbGVtZW50ZWQg YnkgdGhlIGFwcGxpY2F0aW9ucyB1c2luZyBERUNBREUuDQo+Pj4+ID4+DQo+Pj4+ID4+IE9yLCBh bSBJIG1pc2ludGVycHJldGluZyB0aGUgaW50ZW50IG9mIHRoZSByZXF1aXJlbWVudD8NCj4+Pj4g Pj4NCj4+Pj4gPiB5b3UgbWVhbiBERUNBREUgcHJvdmlkZXMgdGhlIGJhc2ljIGNhcGFiaWxpdGll cywgc28gY2FuIHlvdSBnaXZlIHNvbWUNCj4+Pj4gPiBzcGVjaWZ5IGV4cGxhbmF0aW9ucyBvbiBE RUNBREUgY2FwYWJpbGl0aWVzIGluIHN1cHBvcnRpbmcgZGF0YQ0KPj4+PiA+IGRpc3RyaWJ1dGlv bj8NCj4+Pj4gPj4NCj4+Pj4NCj4+Pj4gVGhlIHByb2JsZW0gc3RhdGVtZW50IGdpdmVzIGEgY291 cGxlIG9mIHNjZW5hcmlvcy4gVGhlICJJbnRlZ3JhdGlvbg0KPj4+PiBFeGFtcGxlcyIgcHJlc2Vu dGF0aW9uIGZyb20gSUVURiA3OSBhbHNvIGhhcyBtb3JlIGRldGFpbHMgb2YgYW4NCj4+Pj4gb24t Z29pbmcgZWZmb3J0IGF0IFlhbGUuDQo+Pg0KPj4+IG9rYXksIHRoeCBmb3IgeW91ciBpbmZvcm1h dGlvbiwgaSB3aWxsIGxvb2t1cCBhbmQgcmVmZXIsIGFjdHVhbGx5LCB0aGUNCj4+PiBjb250ZW50 IHB1Ymxpc2hlciBkZXNjcmliZWQgaW4gcHJvYmxlbSBzdGF0ZW1lbnQgcmVtaW5kIG1lIG9mICB0 aGUNCj4+PiBwcm90b2NvbCByZXF1aXJlbWVudHMgd2hpY2ggaSBkaWQgbm90IGZpbmQgaW4gZHJh ZnQtaWV0Zi1kZWNhZGUtcmVxcy0wMCB0bw0KPj4+IHN1cHBvcnQgY29udGVudCBwdWJsaXNoLiBv ciBpIG1pc3Mgc29tZSBwb2ludHM/DQo+Pg0KPj4gV2hpY2ggcmVxdWlyZW1lbnRzIGRvIHlvdSB0 aGluayBhcmUgbWlzc2luZz8NCj4+DQo+Pj4+ID4+IFNlcnZpY2UgQXNzdXJhbmNlOg0KPj4+PiA+ Pg0KPj4+PiA+PiBJdCBzZWVtcyBwcm9ibGVtYXRpYyB0byBpbmNsdWRlICJhc3N1cmFuY2UiIGlu IGEgREVDQURFLiAgU2hvdWxkbid0DQo+Pj4+ID4+IHRoZXNlIGluc3RlYWQgYmUgcGFydCBvZiBT TEFzIHdpdGggYSBzdG9yYWdlIHByb3ZpZGVyPyAgV2h5IHNob3VsZA0KPj4+PiA+PiB0aGV5IGJl IERFQ0FERSdzIHJlc3BvbnNpYmlsaXR5Pw0KPj4+PiA+Pg0KPj4+PiA+PiBSZWdhcmRpbmcgInJl c291cmNlIHJlc2VydmF0aW9uIiwgYXJlIHlvdSByZWZlcnJpbmcgdG8gYW4gYWN0dWFsDQo+Pj4+ ID4+IHJlc2VydmF0aW9uICh3aGljaCBtaWdodCBiZSBwcm9ibGVtYXRpYyAtLSBzZWUgYWJvdmUp IG9yIGRvIHlvdSBtZWFuDQo+Pj4+ID4+IHRoYXQgdGhlIHJlc291cmNlIHNoYXJlIHNob3VsZCBh YmxlIHRvIGJlIHNwZWNpZmllZCBhdCB0aGUgdGltZSB0aGUNCj4+Pj4gPj4gY29ubmVjdGlvbiBv cGVucyBhbmQgYmUgYXNzdW1lZCB0byBiZSB0aGUgc2FtZSBmb3IgdGhlIGR1cmF0aW9uIG9mIHRo ZQ0KPj4+PiA+PiBjb25uZWN0aW9uPw0KPj4+PiA+Pg0KPj4+PiA+PiBSZWdhcmRpbmcgRHluYW1p YyBGZWVkYmFjaywgaXMgdGhpcyBvcnRob2dvbmFsIHRvIHRoZSBzdG9yYWdlDQo+Pj4+ID4+IHBy b3RvY29sPyAgSXQgc2VlbXMgbGlrZSB3aGF0IHlvdSB3YW50IGhlcmUgaXMgYSBnZW5lcmljICJz dGF0dXMiDQo+Pj4+ID4+IHNlcnZpY2Ugc2F5aW5nIGhvdyBsb2FkZWQgYSBzZXJ2ZXIgaXM/DQo+ Pj4+ID4+DQo+Pj4+ID4gdGhhdHMgcmlnaHQsIGFjdHVhbGx5LCB0aGUgZmxvdyBjb250cm9sIG1l Y2hhbmlzbSB3YXMgdW5kZXIgZGlzY3Vzc2lvbg0KPj4+PiA+IGluIHdyaXRpbmcgdGhlIGRyYWZ0 IGF0IGZpcnN0LiB3aGF0IGFib3V0IHlvdXIgb3BpbmlvbiBpbiB0aGlzDQo+Pj4+ID4gcmVxdWly ZW1lbnRzPw0KPj4+PiA+DQo+Pj4+DQo+Pj4+IEknbSBub3Qgc3VyZSB3aGF0IHRoZSB0eXBpY2Fs IHdheSBvZiBwcm92aWRpbmcgc3VjaCAibG9hZCBzdGF0dXMiDQo+Pj4+IGluZm9ybWF0aW9uIGZv ciBJRVRGIHByb3RvY29scywgYnV0IG15IGluY2xpbmF0aW9uIGlzIHRoYXQgaXQgc2hvdWxkDQo+ Pj4+IG5vdCBiZSBpbiB0aGUgREVDQURFIHByb3RvY29sIGl0c2VsZi4gIE1heWJlIHNvbWVvbmUg ZWxzZSB3aXRoIGENCj4+Pj4gbG9uZ2VyIGhpc3RvcnkgaW4gSUVURiBjb3VsZCBqdW1wIGluIGhl cmUgOikNCj4+PiBzbyBjYW4gaSB1bmRlcnN0YW5kIHRoYXQgImxvYWQgc3RhdHVzIiBpcyBraW5k IG9mIG5lY2Vzc2l0eSAgaW5mb3JtYXRpb24NCj4+PiBmb3IgREVDQURFIFNlcnZlciwgYnV0IHdo ZXJlIGFuZCB3aG8gY29sbGVjdHMgdGhlIGluZm9ybWF0aW9uIGFyZQ0KPj4+IHJlbWFpbiBkaXNj dXNzaW9uPw0KPj4NCj4+IFRoZSBzdG9yYWdlIHByb3ZpZGVyIGlzIGZyZWUgdG8gY29sbGVjdCB0 aGUgaW5mb3JtYXRpb24gd2hlcmV2ZXIgYW5kDQo+PiBob3dldmVyIHRoZXkgd2lzaC4gIFRoZSBE RUNBREUgc2VydmVyIGltcGxlbWVudGF0aW9uIGNvdWxkIGFkZGl0aW9uYWwNCj4+IGV4cG9ydCB3 aGF0ZXZlciBzdGF0dXMgaW5mb3JtYXRpb24gaXQgd2lzaGVzLiBJIGRvbid0IHRoaW5rIHRoZSBE RUNBREUNCj4+IHByb3RvY29sIG5lZWRzIHRvIGJlIGNvbmNlcm5lZCB3aXRoIHRoYXQuDQo+Pg0K Pj4gTm90ZSB0aGF0IGNlcnRhaW4gZXJyb3IgY29uZGl0aW9ucyAoZS5nLiwgb3ZlcmxvYWQsIGlu c3VmZmljaWVudA0KPj4gcmVzb3VyY2VzKSBtYXkgYmUgc2lnbmFsZWQgYnkgYSBERUNBREUgc2Vy dmVyICh0aGVyZSBhcmUgYWxyZWFkeSBoYXZlDQo+PiByZXF1aXJlbWVudHMgZm9yIHRob3NlKS4g IElmIHlvdSBhcmUgcmVmZXJyaW5nIHRvIHN0YXR1cyBmb3IgYSB1c2VyJ3MNCj4+IHJlc291cmNl cywgdGhlcmUgaXMgYWxyZWFkeSBhIHJlcXVpcmVtZW50IGZvciB0aGF0IHRvby4NCj4+DQo+PiBJ J20ganVzdCBub3QgY29udmluY2VkIHRoYXQgdGhlIERFQ0FERSBwcm90b2NvbCBuZWVkcyB0byBl eHBvcnQgaXRzDQo+PiBjdXJyZW50IGxvYWQgc3RhdHVzIHRvIGNsaWVudHMuDQo+Pg0KPj4gYWN0 dWFsbHkgaSBhbSBub3Qgc3VyZSB3aGljaCBlbGVtZW50cyBpbiBERUNBREUgbmVlZHMgdGhlIGxv YWQNCj4+IHN0YXR1cywoREVDQURFIGNsaWVudCBvciBuZXR3b3JrIHN0b3JhZ2UgaWYgdGhlIG5l dHdvcmsgc3RvcmFnZSBuZWVkcyB0bw0KPj4gcmVkaXJlY3QgdGhlIHJlcXVlc3Qgb3IgYm90aD8p Lg0KPj4NCj4+DQo+Pg0KPj4gQW5kIHRoZSByZXF1aXJlbWVudCBkcmFmdCBjdXJyZW50bHkgc2Vl bXMgZGVzY3JpYmUgdGhlIG92ZXJsb2FkIGNvbmRpdGlvbiBhcw0KPj4gdGhlIGV2ZW50IHRyaWdn ZXJpbmcuIGRvIHlvdSB0aGluayBpZiBpdCBpcyBuZWNlc3NhcnkgdG8gcGVyaW9kaWNhbGx5DQo+ PiByZXBvcnRpbmcgb2YgdGhlIERFQ0FERSBuZXR3b3JrIHN0YXR1cyB0byBjbGllbnQgZm9yIGl0 cyBuZXR3b3JrIHN0b3JhZ2UNCj4+IHNlbGVjdGlvbj8NCj4+DQo+Pg0KPj4NCj4+IGFuZCB0aGUg cmVxdWlyZW1lbnQgZHJhZnQganVzdCBkZXNjcmliZSBERUNBREUgd2hpY2ggaXMgYnVzeSB0byBz ZXJ2ZSBvdGhlcg0KPj4gcmVxdWVzdHMgbXVzdCBiZSBhYmxlIHRvIHJlamVjdCByZXF1ZXN0cywg bm90IGNvbnNpZGVyIGhvdyB0byBoYW5kbGUgdGhlDQo+PiB1c2VyIHJlcXVlc3QgYWZ0ZXIgYmVp bmcgcmVqZWN0ZWQ/DQo+Pg0KPj4+PiA+Pg0KPj4+PiA+PiBEYXRhIGNsYXNzaWZpY2F0aW9uOg0K Pj4+PiA+Pg0KPj4+PiA+PiBXb3VsZCBpdCBiZSBiZXR0ZXIgdG8gaW5zdGVhZCBoYXZlIHRoZSBj bGllbnQgc3BlY2lmeSBwcm9wZXJ0aWVzIG9mDQo+Pj4+ID4+IHRoZSBjb250ZW50IGluc3RlYWQg b2YgcGxhY2UgaXQgaW50byA/IFNlZQ0KPj4+PiA+PiB3d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3Mv Nzgvc2xpZGVzL25mc3Y0LTAucGRmPGh0dHA6Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvNzgv c2xpZGVzL25mc3Y0LTAucGRmPiBmb3IgYW4gZXhhbXBsZSBvZiB0aGlzDQo+Pj4+ID4+IGFwcHJv YWNoIGZvciBORlMuDQo+Pj4+ID4+DQo+Pj4+ID4+IEkgdGhpbmsgYSBwcm9ibGVtIHdpdGggY2xh c3NpZnlpbmcgYXBwbGljYXRpb25zIGlzIHRoYXQgaXQgYXNzdW1lcw0KPj4+PiA+PiB0aGF0IGFw cGxpY2F0aW9ucyBmaXQgb25lIG9mIHRoZSBzdXBwbGllZCBjbGFzc2lmaWNhdGlvbnMuIFdoYXQg aWYgaXQNCj4+Pj4gPj4gbWF5IGZpdCBtdWx0aXBsZSBjbGFzc2lmaWNhdGlvbnM/IG9yIG5vbmU/ ICBBbm90aGVyIHByb2JsZW0gaXMgaXQNCj4+Pj4gPj4gYXNzdW1lcyB0aGF0IHNlcnZlcnMgYXNz dW1lIGJhc2VkIG9uIGluZGlyZWN0IGFuZCBhc3N1bWVkIGluZm9ybWF0aW9uDQo+Pj4+ID4+IHRo YXQgdGhleSBrbm93IHdoYXQgdG8gZG8gd2l0aCBhIHBhcnRpY3VsYXIgcGllY2Ugb2YgY29udGVu dC4gV2h5IG5vdA0KPj4+PiA+PiBoYXZlIGFuIGFwcGxpY2F0aW9uIHNwZWNpZnkgaXRzIGRlc2ly ZXMgZGlyZWN0bHk/DQo+Pj4+ID4+DQo+Pj4+ID4NCj4+Pj4gPg0KPj4+PiA+Pg0KPj4+PiA+PiBT bWFsbCBPYmplY3RzOg0KPj4+PiA+Pg0KPj4+PiA+PiBXaGF0IGlzIHRoZSBuZXcgcmVxdWlyZW1l bnQgaGVyZT8gIFdoeSBpcyB0aGUgZXhpc3RpbmcgcmVxdWlyZW1lbnQgaW4NCj4+Pj4gPj4gZHJh ZnQtaWV0Zi1kZWNhZGUtcmVxcy0wMCBpbnN1ZmZpY2llbnQ/DQo+Pj4+ID4+DQo+Pj4+ID4+IFRo aXMgYWxzbyBoYXMgbWUgYSBiaXQgd29ycmllZDoNCj4+Pj4gPj4gIkFuZCB0aGUgaW4tbmV0d29y ayBzdG9yYWdlIGhhcyB0aGUgbGltaXRlZCBzdG9yYWdlIGNhcGFjaXR5LCB3aXRoIHRoZQ0KPj4+ PiA+PiBhcnJpdmFsIG9mIHVzZXIgcmVxdWVzdHMgYW5kIGRhdGEgZGlzdHJpYnV0aW9uIHJlcXVp cmVtZW50cywgdGhlIGRhdGENCj4+Pj4gPj4gc3RvcmVkIGluIHRoZSBpbi1uZXR3b3JrIHN0b3Jh Z2Ugd2lsbCBiZSByZXBsYWNlZCBpZiB0aGUgc3RvcmFnZQ0KPj4+PiA+PiByZWFjaGVzIHRoZSBs aW1pdCBhbmQgZGF0YSBhcnJpdmFscyBjb250aW51YWxseS4iDQo+Pj4+ID4+DQo+Pj4+ID4+IEhv dyBkb2VzIHRoZSBzZXJ2ZXIga25vdyB3aGF0IHRoZSBwcm9wZXIgcmVwbGFjZW1lbnQgc3RyYXRl Z3kgaXMgZm9yDQo+Pj4+ID4+IGFuIGFwcGxpY2F0aW9uPyBJIHRoaW5rIERFQ0FERSdzIHBoaWxv c29waHkgaXMgdGhhdCBhcHBsaWNhdGlvbnMNCj4+Pj4gPj4gc2hvdWxkIGRlY2lkZSB0aGlzLiBB IHNpbXBsZSB3YXkgdG8gZG8gdGhpcyBpcyBleHBsaWNpdCBkZWxldGlvbiBieSBhbg0KPj4+PiA+ PiBhcHBsaWNhdGlvbiwgYnV0IHBlcmhhcHMgYSBtb3JlIGVmZmljaWVudCAoeWV0IG1vcmUgY29t cGxleCkgc29sdXRpb24NCj4+Pj4gPj4gaXMgZm9yIGFuIGFwcGxpY2F0aW9uIHRvIHNwZWNpZnkg dGhlIHJlcGxhY2VtZW50IHBvbGljeSB0byB0aGUgc2VydmVyLg0KPj4+PiA+Pg0KPj4+PiA+IGFj dHVhbGx5LCB0aGUga2V5IGluICJ0aGUgZGF0YSBjbGFzc2lmaWNhdGlvbiBhbmQgc21hbGwgb2Jq ZWN0cyAiIGlzDQo+Pj4+ID4gd2hldGhlciBkb2VzIGl0IG9yIG5vdCBpbiBQMlAgYXBwbGljYXRp b24/IGkgZGlkIG5vdCBmaW5kIGRhdGENCj4+Pj4gPiBjbGFzc2lmaWNhdGlvbiB3YXMgYWRvcHRl ZCBpbiBQMlAgYXBwbGljYXRpb24gc28gZmFyLCBsZXQgYWxvbmUgREVDQURFDQo+Pj4+ID4gbmVl ZA0KPj4+PiA+IHRvIGNsYXNzaWZ5IHRoZSBkYXRhIHVzZWQgaW4gYWxsIGtpbmRzIG9mIGFwcGxp Y2F0aW9uLg0KPj4+PiA+DQo+Pj4+DQo+Pj4+IFNvLCBkbyB5b3UgYWdyZWUgdGhhdCBpdCBpcyBw cm9ibGVtYXRpYyB0byB0cnkgYW5kIGNsYXNzaWZ5IGVhY2ggdHlwZQ0KPj4+PiBvZiBhcHBsaWNh dGlvbiBhbmQgdHJ5IHRvIHNwZWNpZnkgdGhlIHR5cGljYWwgd29ya2xvYWQgZm9yIGVhY2ggY2xh c3M/DQo+Pj4+DQo+Pj4+IE15IHBvaW50IHdhcyB0aGF0IEkgZG9uJ3QgdGhpbmsgaXRzIG5lY2Vz c2FyeSB0byBkbyB0aGUgY2xhc3NpZmljYXRpb24NCj4+Pj4gYXQgYWxsLiAgSXQgaXMgbW9yZSBl eHRlbnNpYmxlIChhbmQgZGlyZWN0bHkgdXNlZnVsKSBmb3IgYSBzZXJ2ZXIgdG8NCj4+Pj4ganVz dCBnaXZlIGl0IGRpcmVjdCBoaW50cyBhYm91dCB3aGF0IHdvdWxkIGJlIHByZWZlcmFibGUuDQo+ Pj4NCj4+PiB5ZXAsIGkgYmVsaWV2ZSBpdCBtYXkgYmUgYSBsaXR0bGUgZGlmZmljdWx0LCBidXQg d29ydGh5IGRvaW5nLiBzcGVjaWFsbHkNCj4+PiBmb3IgaW1wcm92aW5nIHRoZSByZXNvdXJjZSB1 dGlsaXphdGlvbiB3aXRoaW4gYSBzaW5nbGUgc2VydmVyIGFuZCByZWR1Y2luZw0KPj4+IHRoZSBy ZXNwb25zZSB0aW1lIGZvciBjbGllbnQuIHdoYXQgYWJvdXQgb3RoZXJzIG9waW5pb24/DQo+Pg0K Pj4gQ2FuIHlvdSBqdXN0aWZ5IHdoeSBnaXZpbmcgY2xhc3NpZmljYXRpb25zIChlLmcuLCAiSSdt IGEgbGl2ZQ0KPj4gc3RyZWFtaW5nIGFwcGxpY2F0aW9uIikgd291bGQgYmUgYmV0dGVyIHRoYW4g Z2l2aW5nIHNwZWNpZmljIGhpbnRzDQo+PiAoZS5nLiwgInBsZWFzZSBkb24ndCBib3RoZXIgcGVy c2lzdGVudCB0aGVzZSBvYmplY3RzIHRvIGRpc2siKT8NCj4+DQo+PiBpIG1lYW4gZGF0YSBpbiBk aWZmZXJlbnQga2luZCBvZiBvcGVyYXRpb24gbW9kZSBhbmQgYXR0cmlidXRlIHNob3VsZCBoYXZl DQo+PiBkaWZmZXJlbnQgdXNlciBwYXR0ZXJucyBhbmQgc3RvcmFnZSBydWxlcywgd2hpY2ggbWF5 IGJlIGhlbHAgdG8gaW1wcm92ZSB0aGUNCj4+IHJlc291cmNlIHV0aWxpemF0aW9uIGFuZCByZWR1 Y2UgdGhlIHJlc3BvbnNlIHRpbWUgZm9yIHJlcXVlc3QsIHdoYXQgYXJlIHlvdQ0KPj4gdW5kZXJz dGFuZGluZz8NCj4+PiA+Pg0KPj4+PiA+PiBSZW1vdmFsIG9mIEV4cGlyZWQgUmVjb3JkczoNCj4+ Pj4gPj4NCj4+Pj4gPj4gIkhvd2V2ZXIsIHRoZSB0d28gc2NlbmFyaW9zIGRpZCBub3QgbWVudGlv biBob3cgdG8gaGFuZGxlIHRoZSBvbGQNCj4+Pj4gPj4gcmVzb3VyY2UgaWYgdGhlIHVzZXIgZGlz dHJpYnV0ZXMgdGhlIG5ldyByZXNvdXJjZSB3aGljaCBpcyBhbiB1cGRhdGVkDQo+Pj4+ID4+IGNv cHkgb2YgdGhlIG9sZCByZXNvdXJjZS4iDQo+Pj4+ID4+DQo+Pj4+ID4+IFdoeSBkb2VzIHRoaXMg bmVlZCB0byBiZSBoYW5kbGVkIGluIHRoZSByZXF1aXJlbWVudHM/ICBBcmUgeW91IHRyeWluZw0K Pj4+PiA+PiB0byBkcmF3IHRoZSBkaXN0aW5jdGlvbiBiZXR3ZWVuIGltbWVkaWF0ZSBkZWxldGlv biBvZiBjb250ZW50IGFuZCBsYXp5DQo+Pj4+ID4+IGRlbGV0aW9uPw0KPj4+PiA+Pg0KPj4+PiA+ IGkgbWVhbiB0aGUgbWVhbmluZyBvZiBkZWxldGUgb3BlcmF0aW9uIGFuZCBob3cgdG8gaGFuZGxl IHRoZSBleHBpcmVkDQo+Pj4+ID4gcmVjb3JkcyBuZWVkIHRvIGJlIGNsYXJpZnkgaW4gcmVxdWly ZW1lbnRzLg0KPj4+Pg0KPj4+PiBNeSBpbmNsaW5hdGlvbiBpcyB0aGF0ICJkZWxldGVkIiBtZWFu cyB0aGF0IG90aGVyIHJlcXVlc3RzIHRoZSBvYmplY3QNCj4+Pj4gb2YgdGhlIHNhbWUgbmFtZSBz aG91bGQgcmVzdWx0IGFuIGVycm9yLCB1bnRpbCBhbm90aGVyIG9iamVjdCB3aXRoIHRoZQ0KPj4+ PiBzYW1lIG5hbWUgaXMgc3RvcmVkLg0KPj4+DQo+Pj4gb2theSwgdW5kZXIgdGhlIHNjZW5hcmlv ICJjbGllbnQgdXBsb2FkcyB0aGUgbmV3IHZlcnNpb24sIGFuZCBkaWQgbm90DQo+Pj4gc3BlY2lm eSBob3cgdG8gaGFuZGxlIHRoZSBvbGQgdmVyc2lvbiIsIGRpZCBERUNBREUgc2VydmVyIGRlbGV0 ZSB0aGUgb2xkZXINCj4+PiB2ZXJzaW9uIChvciBqdXN0IGxhYmVsIGl0IHVuYXZhaWxhYmxlLCBh bnl3YXksIGl0IGlzIGltcGxlbWVudGF0aW9uIGlzc3VlDQo+Pj4gKQ0KPj4+IG9yIG5vdCA/IGlu IGFub3RoZXIgd29yZCwganVzdCByZXBsYWNlIHRoZSBvbGRlciB2ZXJzaW9uIHdpdGggdGhlIG5l dw0KPj4+IHZlcnNpb24gd2l0aCB0aGUgc2FtZSBuYW1lPw0KPj4NCj4+IEluIHRoaXMgY2FzZSwg SSB3b3VsZCB0aGluayB0aGUgIndyaXRlIiBvZiB0aGUgbmV3IG9iamVjdCBzaG91bGQgYmUNCj4+ IHJlamVjdGVkLCBvciBpZiBkZXNpcmVkLCB3ZSBjb3VsZCBoYXZlIGFuIG92ZXJ3cml0ZSBvcHRp b24uICBUaGlzDQo+PiBjb3VsZCBiZSBhZGRlZCB0byB0aGUgcmVxdWlyZW1lbnRzIGlmIGl0IGhl bHBzIHRvIGNsYXJpZnkuDQo+Pg0KPj4geWVwLCBubyBtYXR0ZXIgd2hpY2ggc29sdXRpb24gaXMg Y2hvc2VuLCBsZXQgdGhlIHVuZGVyc3RhbmRpbmcgdW5hbmltb3VzbHk6RA0KPj4+IGhvdyB0byBo YW5kbGUgdGhlIG9sZGVyIHZlcnNpb24gd2hpY2ggaXMNCj4+PiB0cmFuc2ZlcnJpbmcgZnJvbSBz ZXJ2ZXIgdG8gY2xpZW50Pw0KPj4NCj4+IEkgdGhpbmsgaXQgd291bGQgYmUgY2xlYW5lciB0byBh c2sgdGhlIHNlcnZlciB0byBjb250aW51ZSBzZW5kaW5nIGFuDQo+PiBvYmplY3Qgb25jZSBpdCBo YXMgYmVlbiBzdGFydGVkLCBidXQgdWx0aW1hdGVseSB0aGlzIHdvdWxkIGJlIHRoZQ0KPj4gZGVj aXNpb24gb2YgdGhlIHNlcnZlcidzIGltcGxlbWVudGF0aW9uIEkgdGhpbmsuICBNYXliZSBhICJT SE9VTEQiDQo+PiByZXF1aXJlbWVudC4gIFRoaXMgY291bGQgYmUgYWRkZWQgaWYgZGVzaXJlZC4N Cj4+DQo+PiBUaGFuayB5b3UgZm9yIHRoZXNlIHF1ZXN0aW9ucy4gIEl0IGhlbHBzIGRlc2lnbiB0 aGUgcmVxdWlyZW1lbnRzIG1vcmUNCj4+IGNsZWFubHkgaWYgdGhlcmUgYXJlIHNwZWNpZmljIHNj ZW5hcmlvcyBpbiBmcm9udCBvZiB1cyA6KQ0KPj4ganVzdCBkaXNjdXNzaW9uIHRvZ2V0aGVyOkQg YW5kIGFsc28gdGhhbmtzIGZvciB5b3VyIHBvaW50cyB0byBoZWxwIG1lDQo+PiB1bmRlcnN0YW5k aW5nIG1vcmUhDQo+PiBSaWNoDQo+Pg0KPj4+PiBJIHRoaW5rIHRoYXQgdGhlIHRpbWUgdGhlIGRh dGEgaXMgcmVtb3ZlZCBmcm9tIGRpc2sgKG9yIG1lbW9yeSkgc2hvdWxkDQo+Pj4+IGJlIHVwIHRv IHRoZSBpbXBsZW1lbnRhdGlvbi4gQSBzdG9yYWdlIHByb3ZpZGVyIG1pZ2h0IHN0aWxsIGhhdmUg YXMNCj4+Pj4gcGFydCBvZiBzb21lIGFncmVlbWVudCB0aGF0IGRlbGV0ZWQgZGF0YSB3aWxsIGJl IHJlbW92ZWQgd2l0aGluIFgNCj4+Pj4gZGF5cy9ob3Vycy9taW51dGVzL3doYXRldmVyLg0KPj4+ DQo+Pj4gICAgYWdyZWUgd2l0aCB5b3UuDQo+Pj4+DQo+Pj4+IElmIHBlb3BsZSBpbiB0aGUgV0cg dGhpbmsgaXQgaXMgbmVjZXNzYXJ5LCB3ZSBjb3VsZCBoYXZlIGEgcmVxdWlyZW1lbnQNCj4+Pj4g dGhhdCBzYXlzIHRoZSBwcm90b2NvbCBzaG91bGQgc3VwcG9ydCBhbiBhcmd1bWVudCBpbmRpY2F0 aW5nIGltbWVkaWF0ZQ0KPj4+PiBkZWxldGlvbiwgYnV0IGl0IGlzIG5vdCBjbGVhciB0aGF0IHdl IG5lZWQgdGhpcy4NCj4+Pj4NCj4+Pj4gUmljaA0KPj4+Pg0KPj4+PiA+Pg0KPj4+PiA+PiBUaGFu a3MhDQo+Pj4+ID4+IFJpY2gNCj4+Pj4gPj4NCj4+Pj4gPj4NCj4+Pj4gPj4gT24gTW9uLCBEZWMg MjcsIDIwMTAgYXQgMTI6NTcgQU0sINbs5OwgPGJ1cHR4aWFvemh1QGdtYWlsLmNvbTxtYWlsdG86 YnVwdHhpYW96aHVAZ21haWwuY29tPj4gd3JvdGU6DQo+Pj4+ID4+ID4gRGVhciBhbGwsDQo+Pj4+ ID4+ID4NCj4+Pj4gPj4gPiBUaGVyZSBpcyBhIHNsaWdodGx5IHVwZGF0ZWQgdmVyc2lvbiBvZiB0 aGUgZGVjYWRlIGFkZGl0aW9uYWwNCj4+Pj4gPj4gPiByZXF1aXJlbWVudHMNCj4+Pj4gPj4gPiBk cmFmdC4NCj4+Pj4gPj4gPg0KPj4+PiA+PiA+DQo+Pj4+ID4+ID4gaHR0cHM6Ly9kYXRhdHJhY2tl ci5pZXRmLm9yZy9kb2MvZHJhZnQtemh1LWRlY2FkZS1hZGRpdGlvbmFsLXJlcXVpcmVtZW50cy8N Cj4+Pj4gPj4gPg0KPj4+PiA+PiA+IEppbiBQZW5nLCBZdW5mZWkgWmhhbmcgYW5kIG1lIGFyZSBl eHBlY3RpbmcgdG8gaGF2ZSBhIGRpc2N1c3Npb24NCj4+Pj4gPj4gPiB3aXRoDQo+Pj4+ID4+ID4g YWxsIG9mDQo+Pj4+ID4+ID4geW91Lg0KPj4+PiA+PiA+DQo+Pj4+ID4+ID4gQW55IGNvbW1lbnRz IGFyZSBhcHByZWNpYXRlZCENCj4+Pj4gPj4gPg0KPj4+PiA+PiA+IEEgbmV3IHZlcnNpb24gb2Yg SS1ELA0KPj4+PiA+PiA+IGRyYWZ0LXpodS1kZWNhZGUtYWRkaXRpb25hbC1yZXF1aXJlbWVudHMt MDAudHh0DQo+Pj4+ID4+ID4gaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBYaWFv IFpodSBhbmQgcG9zdGVkIHRvIHRoZSBJRVRGDQo+Pj4+ID4+ID4gcmVwb3NpdG9yeS4NCj4+Pj4g Pj4gPg0KPj4+PiA+PiA+IEZpbGVuYW1lOiAgICAgIGRyYWZ0LXpodS1kZWNhZGUtYWRkaXRpb25h bC1yZXF1aXJlbWVudHMNCj4+Pj4gPj4gPiBSZXZpc2lvbjogICAgICAwMA0KPj4+PiA+PiA+IFRp dGxlOiAgICAgICAgICAgICAgICAgQWRkaXRpb25hbCBwcm90b2NvbCByZXF1aXJlbWVudHMgb24g REVDQURFDQo+Pj4+ID4+ID4gQ3JlYXRpb25fZGF0ZTogICAgICAgICAyMDEwLTEyLTI3DQo+Pj4+ ID4+ID4gV0cgSUQ6ICAgICAgICAgICAgICAgICBJbmRlcGVuZGVudCBTdWJtaXNzaW9uDQo+Pj4+ ID4+ID4gTnVtYmVyX29mX3BhZ2VzOiAxMA0KPj4+PiA+PiA+DQo+Pj4+ID4+ID4gQWJzdHJhY3Q6 DQo+Pj4+ID4+ID4gVGhlIERFQ291cGxlZCBBcHBsaWNhdGlvbiBEYXRhIEVucm91dGUoREVDQURF KXdvcmtpbmcgZ3JvdXAgaXMNCj4+Pj4gPj4gPiBzcGVjaWZ5aW5nIHN0YW5kYXJkaXplZCBpbnRl cmZhY2VzIGZvciBhY2Nlc3NpbmcgaW4tbmV0d29yayBzdG9yYWdlDQo+Pj4+ID4+ID4gZnJvbSBh cHBsaWNhdGlvbnMgdG8gc3RvcmUsIHJldHJpZXZlIGFuZCBtYW5hZ2UgZGF0YS4gVGhlIG1haW4N Cj4+Pj4gPj4gPiBvYmplY3QNCj4+Pj4gPj4gPiBpcyB0byBwcm92aWRlIGEgZnJhbWV3b3JrIHRo YXQgaXMgdXNlZnVsIHRvIHRoZSBhcHBsaWNhdGlvbnMsDQo+Pj4+ID4+ID4gaW5jbHVkaW5nIFAy UCBhcHBsaWNhdGlvbnMgYW5kIG90aGVyIGRhdGEtb3JpZW50ZWQgYXBwbGljYXRpb25zLA0KPj4+ PiA+PiA+IHBvc3NpYmx5IHJlbGF0ZWQgYXBwbGljYXRpb25zIHRoYXQgY2FuIGJlbmVmaXQgZnJv bSBhY2Nlc3NpbmcgaW4tDQo+Pj4+ID4+ID4gbmV0d29yayBzdG9yYWdlLiBUaGlzIG1lbW8gZm9j dXNlcyBvbiBzb21lIHJlcXVpcmVtZW50cyBzdWNoIGFzDQo+Pj4+ID4+ID4gcmVxdWVzdCByZWRp cmVjdGluZyBhbmQgc28gb24gd2hpY2ggYXJlIG9uIHRoZSBjZW50cmFsIG9mIG1vYmlsaXR5LA0K Pj4+PiA+PiA+IHdpcmVsZXNzIG5ldHdvcmsgZW52aXJvbm1lbnQgYW5kIENETiBhcHBsaWNhdGlv bi4gV2UgcHJlc2VudCB0aGVzZQ0KPj4+PiA+PiA+IGluDQo+Pj4+ID4+ID4gdGhpcyBtZW1vIGFz IGFkZGl0aW9uYWwgcmVxdWlyZW1lbnRzIHRoYXQgc2hvdWxkIGJlIGNvbnNpZGVyZWQgZm9yDQo+ Pj4+ID4+ID4gdGhlIERFQ0FERSBhcmNoaXRlY3R1cmUgYW5kIHByb3RvY29sIHNwZWNpZmljYXRp b25zLg0KPj4+PiA+PiA+DQo+Pj4+ID4+ID4NCj4+Pj4gPj4gPg0KPj4+PiA+PiA+IFRoZSBJRVRG IFNlY3JldGFyaWF0Lg0KPj4+PiA+PiA+DQo+Pj4+ID4+ID4gLS0NCj4+Pj4gPj4gPiBCZXN0IHdp c2hlcywNCj4+Pj4gPj4gPg0KPj4+PiA+PiA+IEJlaWppbmcgVW5pdmVyc2l0eSBvZiBQb3N0cyAm IFRlbGVjb21tdW5pY2F0aW9ucyAoQlVQVCkNCj4+Pj4gPj4gPiBaaHUgWGlhbyAgKCDW7OTsICkN Cj4+Pj4gPj4gPiBFLW1haWw6IGJ1cHR4aWFvemh1QGdtYWlsLmNvbTxtYWlsdG86YnVwdHhpYW96 aHVAZ21haWwuY29tPg0KPj4+PiA+PiA+IG1vYmlsZTorODYgMTM0LTg4ODEtOTAwNA0KPj4+PiA+ PiA+DQo+Pj4+ID4+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCj4+Pj4gPj4gPiBkZWNhZGUgbWFpbGluZyBsaXN0DQo+Pj4+ID4+ID4gZGVjYWRlQGll dGYub3JnPG1haWx0bzpkZWNhZGVAaWV0Zi5vcmc+DQo+Pj4+ID4+ID4gaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kZWNhZGUNCj4+Pj4gPj4gPg0KPj4+PiA+PiA+DQo+Pj4+ ID4NCj4+Pj4gPg0KPj4+PiA+DQo+Pj4+ID4gLS0NCj4+Pj4gPiBCZXN0IHdpc2hlcywNCj4+Pj4g Pg0KPj4+PiA+IEJlaWppbmcgVW5pdmVyc2l0eSBvZiBQb3N0cyAmIFRlbGVjb21tdW5pY2F0aW9u cyAoQlVQVCkNCj4+Pj4gPiBaaHUgWGlhbyAgKCDW7OTsICkNCj4+Pj4gPiBFLW1haWw6IGJ1cHR4 aWFvemh1QGdtYWlsLmNvbTxtYWlsdG86YnVwdHhpYW96aHVAZ21haWwuY29tPg0KPj4+PiA+IG1v YmlsZTorODYgMTM0LTg4ODEtOTAwNA0KPj4+DQo+Pj4NCj4+Pg0KPj4+IC0tDQo+Pj4gQmVzdCB3 aXNoZXMsDQo+Pj4NCj4+PiBCZWlqaW5nIFVuaXZlcnNpdHkgb2YgUG9zdHMgJiBUZWxlY29tbXVu aWNhdGlvbnMgKEJVUFQpDQo+Pj4gWmh1IFhpYW8gICgg1uzk7CApDQo+Pj4gRS1tYWlsOiBidXB0 eGlhb3podUBnbWFpbC5jb208bWFpbHRvOmJ1cHR4aWFvemh1QGdtYWlsLmNvbT4NCj4+PiBtb2Jp bGU6Kzg2IDEzNC04ODgxLTkwMDQNCj4+Pg0KPj4NCj4+DQo+PiAtLQ0KPj4gQmVzdCB3aXNoZXMs DQo+Pg0KPj4gQmVpamluZyBVbml2ZXJzaXR5IG9mIFBvc3RzICYgVGVsZWNvbW11bmljYXRpb25z IChCVVBUKQ0KPj4gWmh1IFhpYW8gICgg1uzk7CApDQo+PiBFLW1haWw6IGJ1cHR4aWFvemh1QGdt YWlsLmNvbTxtYWlsdG86YnVwdHhpYW96aHVAZ21haWwuY29tPg0KPj4gbW9iaWxlOis4NiAxMzQt ODg4MS05MDA0DQo+DQoNCg0KLS0NCkJlc3Qgd2lzaGVzLA0KDQpCZWlqaW5nIFVuaXZlcnNpdHkg b2YgUG9zdHMgJiBUZWxlY29tbXVuaWNhdGlvbnMgKEJVUFQpDQpaaHUgWGlhbyAgKCDW7OTsICkN CkUtbWFpbDogYnVwdHhpYW96aHVAZ21haWwuY29tPG1haWx0bzpidXB0eGlhb3podUBnbWFpbC5j b20+DQptb2JpbGU6Kzg2IDEzNC04ODgxLTkwMDQNCg0KDQoNCi0tDQpCZXN0IHdpc2hlcywNCg0K QmVpamluZyBVbml2ZXJzaXR5IG9mIFBvc3RzICYgVGVsZWNvbW11bmljYXRpb25zIChCVVBUKQ0K Wmh1IFhpYW8gICgg1uzk7CApDQpFLW1haWw6IGJ1cHR4aWFvemh1QGdtYWlsLmNvbTxtYWlsdG86 YnVwdHhpYW96aHVAZ21haWwuY29tPg0KbW9iaWxlOis4NiAxMzQtODg4MS05MDA0DQoNCg0KDQot LQ0KQmVzdCB3aXNoZXMsDQoNCkJlaWppbmcgVW5pdmVyc2l0eSBvZiBQb3N0cyAmIFRlbGVjb21t dW5pY2F0aW9ucyAoQlVQVCkNClpodSBYaWFvICAoINbs5OwgKQ0KRS1tYWlsOiBidXB0eGlhb3po dUBnbWFpbC5jb208bWFpbHRvOmJ1cHR4aWFvemh1QGdtYWlsLmNvbT4NCm1vYmlsZTorODYgMTM0 LTg4ODEtOTAwNA0K From richard.alimi@gmail.com Wed Jun 29 22:26:45 2011 Return-Path: X-Original-To: decade@ietfa.amsl.com Delivered-To: decade@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9E1721F85D9 for ; Wed, 29 Jun 2011 22:26:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.938 X-Spam-Level: X-Spam-Status: No, score=-2.938 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CdnK5VQqR-xf for ; Wed, 29 Jun 2011 22:26:43 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id A715B21F85D5 for ; Wed, 29 Jun 2011 22:26:43 -0700 (PDT) Received: by iwn39 with SMTP id 39so2106673iwn.31 for ; Wed, 29 Jun 2011 22:26:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=ilI92LfZUaivMiIe6zD8Mkr9WkUYHhfVQw1Tnjff/qY=; b=ZRTQKLCH7M2zF64PGmOzXLF5UBH35Ybx+jMIzlBeRm6ptlMnN1RcUBVPaDd9j+iS19 +URLaGelQh54sV2rNanslRXO3QHYROkdkEiz2uoa3J2w8gYP0ARvkDCDmMSO1thbI8+/ tG4c1M6UUppOJAfNnJkw1rHketQwi2A1fzKFw= Received: by 10.231.81.139 with SMTP id x11mr1375101ibk.143.1309411603126; Wed, 29 Jun 2011 22:26:43 -0700 (PDT) MIME-Version: 1.0 Sender: richard.alimi@gmail.com Received: by 10.231.0.155 with HTTP; Wed, 29 Jun 2011 22:26:23 -0700 (PDT) In-Reply-To: <1CA25301D2219F40B3AA37201F0EACD1135A3822@PACDCEXMB05.cable.comcast.com> References: <1CA25301D2219F40B3AA37201F0EACD11343C0AB@PACDCEXMB05.cable.comcast.com> <1CA25301D2219F40B3AA37201F0EACD1135A2B0F@PACDCEXMB05.cable.comcast.com> <1CA25301D2219F40B3AA37201F0EACD1135A3822@PACDCEXMB05.cable.comcast.com> From: Richard Alimi Date: Wed, 29 Jun 2011 22:26:23 -0700 X-Google-Sender-Auth: zRRbINaZ94HYIxtSRz8U-OGriGs Message-ID: To: "Woundy, Richard" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "decade@ietf.org" Subject: Re: [decade] draft-zhu-decade-additional-requirements X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.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, 30 Jun 2011 05:26:46 -0000 2011/6/29 Woundy, Richard : > There is a limit of five authors on an Internet draft, but you could be m= entioned in the Acknowledgments section. Adding the authors of draft-zhu-decade-additional-requirements in the Acknowledgments would be very reasonable I think. Thanks, Rich > ________________________________________ > From: =E6=9C=B1=E6=BD=87 [buptxiaozhu@gmail.com] > Sent: Wednesday, June 29, 2011 3:02 AM > To: Woundy, Richard > Cc: Richard Alimi; decade@ietf.org > Subject: Re: [decade] draft-zhu-decade-additional-requirements > > hi, Woundy > > okay. that`s a good idea. I remember we have a discussion on the addition= al requirements in the draft-zhu-decade-additional-requirement and we have = reached agreement on the first points with Richard Alimi. I have no specia= l suggestion on how my requirements were reflected in draft-ietf-decade-req= s. But we, the writers of the draft could be added in the contributors of = the draft-ieft-decade-reqs. What do you think of ? > > > 2011/6/29 Woundy, Richard > > Xiao, > > My personal preference would be to let draft-zhu-decade-additional-requir= ements expire, and ensure that the key requirements from your draft are ref= lected in draft-ietf-decade-reqs which is the official WG draft. > > Do you have objections about how your requirements were reflected in draf= t-ietf-decade-reqs? > > -- Rich > > From: =E6=9C=B1=E6=BD=87 [mailto:buptxiaozhu@gmail.com] > Sent: Monday, June 27, 2011 10:23 PM > To: Richard Alimi > Cc: Woundy, Richard; decade@ietf.org > > Subject: Re: [decade] draft-zhu-decade-additional-requirements > > hi, Richard and everybody > > The draft draft-zhu-decade-additional-requirements I submitted last year = is about to expire. do you have some suggestions to update the version? and= do the DECADE requirement draft has adopted some suggestions of my draft? > > 2011/6/27 =E6=9C=B1=E6=BD=87 > > hi, Richard and everybody > > The draft draft-zhu-decade-additional-requirements I submitted last year = is about to expire. do you have some suggestions to update the version? and= do the DECADE requirement draft has adopted some suggestions of my draft? > > 2011/3/14 Richard Alimi > > Hi All, > > We've made all of these updates to the requirements document, with the > exception of: > >> - If an object is deleted as it is concurrently being read, then the >> server MAY continue to read it (lazy deletion), or it MAY discontinue >> reading the object and signal an error to the client reading the >> object. > > Upon looking at this again, it looks more like an implementation > detail. If anything, this would result in a "non-requirement" in the > document. However, it seems like a fairly low-level non-requirement to > state at this time. I'd propose to leave it out for now and revisit > this if it comes up again in the future. Thoughts? > > Thanks, > Rich > > 2011/3/2 Richard Alimi >: >> Hi All, >> >> I'll offer a summary of this discussion. Let me know if I missed >> anything, or if there are objections/other thoughts on these proposed >> resolutions. >> >> Redirection: >> - We can add a requirement mentioning that DECADE may support redirectio= n. >> >> Data Classification: >> - I (personally) strongly disagree with attempting to classify access >> patterns or applications. We could add something saying that explicit >> hints (a la www.ietf.org/proceedings/78/slides/nfsv4-0.pdf) could be >> provided in DECADE. However, I don't think we need to do something >> new here. In particular, if the underlying storage/data transport >> supports hints, a DECADE client or server can use it. >> >> Storage Status: >> - Update section 5.1.6 to indicate that status information should >> include permissions of stored objects, if applicable. >> - Update 5.1.6 to indicate that status information should include >> other information about resource usage (the clients own resources, or >> resources used by other clients that have been authorized to >> read/write objects or open connections to one's storage). >> >> Requirements for object deletion/overwriting: >> - DECADE MAY have an overwrite flag (note that this may or may not be >> necessary depending on our naming, but the requirements document >> probably is not the place to take a stand on this at the current >> point.) >> - If an object is deleted as it is concurrently being read, then the >> server MAY continue to read it (lazy deletion), or it MAY discontinue >> reading the object and signal an error to the client reading the >> object. >> >> Would this be sufficient to merge in the points from >> draft-zhu-decade-additional-requirements-00 and this ensuing >> discussion? >> >> Thanks, >> Rich >> >> >> 2011/3/2 Woundy, Richard >: >>> Folks, >>> >>> >>> >>> Do we have consensus yet about how the WG could have a single DECADE >>> requirements document going forward? I can't tell the state of our >>> requirements consolidation from the email thread below. >>> >>> >>> >>> It would be preferable if we could resolve this fully on the WG mailing >>> list, but this is important enough to allocate some time at our meeting= in >>> Prague. >>> >>> >>> >>> -- Rich >>> >>> >>> >>> From: decade-bounces@ietf.org [mailto:d= ecade-bounces@ietf.org] On Behalf Of >>> ?? >>> Sent: Sunday, January 16, 2011 9:02 PM >>> To: Richard Alimi >>> Cc: decade@ietf.org >>> Subject: Re: [decade] draft-zhu-decade-additional-requirements >>> >>> >>> >>> hi, Richard: >>> >>> >>> >>> thanks for your reply:D >>> >>> additional discussion see inline:D >>> >>> >>> >>> 2011/1/14 Richard Alimi > >>> >>> HI Xiao, >>> >>> 2011/1/12 =E6=9C=B1=E6=BD=87 >: >>> >>>> hi, Richard >>>> see inline:D >>>> >>>> 2011/1/11 Richard Alimi = > >>>>> >>>>> Hi Xiao, >>>>> >>>>> On Mon, Jan 10, 2011 at 6:45 PM, =E6=9C=B1=E6=BD=87 > wrote: >>>>> > >>>>> > hi, Richard, sorry for so late response because of be busy with oth= er >>>>> > projects. >>>>> > some discussion see inline:D marked by red. >>>>> > >>>>> > On Tue, Jan 4, 2011 at 4:06 AM, Richard Alimi > >>>>> > wrote: >>>>> >> >>>>> >> Hi Xiao, >>>>> >> >>>>> >> Thank you for the draft. Some comments on the requirements: >>>>> >> >>>>> >> Request Redirects: >>>>> >> >>>>> >> This would provide some additional freedom for the storage provide= r. >>>>> >> I think it is reasonable since it doesn't necessitate additional >>>>> >> complexity for the DECADE server, but allows it if desired. Howeve= r, >>>>> >> note that it may complicate some of the other components of the >>>>> >> design. In particular, if there is a per-user quota for storage, i= s >>>>> >> the user made aware of the quota at each in-network storage (if th= ere >>>>> >> is no shared storage between them)? Resource sharing policies may= be >>>>> >> impacted (e.g., if a bandwidth sharing weight of 1 may mean someth= ing >>>>> >> different at DECADE server A than it does at DECADE server B). At >>>>> >> this point it may be best to just note these so they are documente= d, >>>>> >> but since the specification of the resource sharing policies are s= till >>>>> >> being contemplated for the basic case of a single server it may be >>>>> >> premature to even try and solve them for the case supporting >>>>> >> redirection. >>>>> >> >>>>> > actually, you mean two points, right? >>>>> > 1. whether or not to be ware of the content at each in-network stor= age >>>>> > and of course resource sharing policies can be impact in the reques= t >>>>> > redirection. your suggestion"just to note these so they are documen= ted" >>>>> > will >>>>> > be ok, or DECADE server list with some parameters will be return fo= r >>>>> > user to >>>>> > select the appropriate DECADE server, which can avoid the different >>>>> > weighted >>>>> > of the same parameter in server decision. but the parameter used in >>>>> > select >>>>> > the best DECADE server will be known for DECADE servers, in which o= ther >>>>> > complexities will be added. anyway, all the solution are the >>>>> > implementation >>>>> > issue, which, i believe, does not impact the necessity of the >>>>> > requirement. >>>>> >>>>> In general, I'd agree that the decision about where to redirect would >>>>> be an implementation issue. >>>>> >>>>> > >>>>> > 2. you mean "the resource sharing policies are still being consider= ed >>>>> > in >>>>> > a single server", so it may be premature to support redirection. t= he >>>>> > architecture and protocol will be badly impacted if the requirement= s >>>>> > change. >>>>> > so the designing can be taken step by step, but the requirements >>>>> > should be >>>>> > overall considered. >>>>> >>>>> I said that it is probably premature to consider how resource sharing >>>>> policies works across servers (or even if we need to say anything >>>>> about it) since we have not determined how to specify them (or rather= , >>>>> how little we need to specify in protocol) for a single server. I did >>>>> not mean to imply that redirection could not be introduced as a >>>>> requirement. >>>>> >>>> >>>>> >>>>> > >>>>> > >>>>> >> >>>>> >> Multi-connection: >>>>> >> >>>>> >> I'm not quite clear on the intention of the requirement. My >>>>> >> understanding is that you wish the client to be able to have multi= ple >>>>> >> connections open spanning multiple DECADE servers. Is that correct= ? >>>>> >> >>>>> >> If so, do we need this stated as a requirement or the protocol? Or= is >>>>> >> this a policy that would be allowed/disallowed by the storage >>>>> >> provider? >>>>> >> >>>>> > yep, your understanding is right, the scenarios were just described= in >>>>> > draft as "soft handover in wireless environment and delete operatio= n in >>>>> > multi-servers". under these consideration, the authentication and >>>>> > authorization need to be taken each time when setup connection with= a >>>>> > new >>>>> > DECADE server, or just be taken only once during the service? >>>>> >>>>> The DECADE server should need to do some sort of check on each new >>>>> connection, regardless of whether the user has or previously had a >>>>> connection open to a different DECADE server, right? Note that the >>>>> requirements don't indicate how authentication or authorization is >>>>> done, and allow a server to make optimizations if it is enforcing the >>>>> same permissions. >>>>> >>>>> Can you indicate where the existing authorization-related requirement= s >>>>> (in particular, 4.1.6.3 of draft-ietf-decade-reqs-00) do not suffice >>>>> for the use case you are thinking of? >>> >>>> as considering the service continuity, the next serving DECADE server >>>> should know the progress of the service, how does they know? >>> >>> By progress of the service, do you mean current user state (e.g., >>> quota, recent resource usage history, permissions, etc)? >>> >>> yes, and include data delivery proceeding. >>>> so if the >>>> service proceeding information should be known by the next serving ser= ver, >>>> or different servers need to coordinate and schedule each other to ful= fill >>>> the user request, i believe the the 4.1.6.3 of the >>>> draft-ietf-decade-req-00 >>>> cannot satisfy the req. what do you think about? >>> >>> Note that the protocol that is covered here is the client-server >>> protocol. Some of the same protocol may be useful between DECADE >>> servers (especially in different administrative domains) for storing >>> and retrieving data, but that does not mean that there can't be >>> additional protocol(s) (not specified here) that are used between >>> DECADE servers as well. For example, if DECADE servers within an >>> administrative domain can certainly have their own mechanism to share >>> such information. If such capabilities were included in the DECADE >>> protocol (e.g., a need to do this between administrative domains), >>> that sounds like lots more complexity that we need at this point. >>> but the access between in-network storage also is included in IAP descr= ibed >>> in problem statement. i mean why not put this kind of function in DECA= DE >>> since the IAP is defined just like that? >>> That said, it sounds to me like what is described in 4.1.6.3 would be >>> sufficient (from the perspective of the client-server protocol, >>> anyways) to implement what you're describing. If not, what >>> specifically is missing and what use-case does it not meet? >>> >>> so you mean the information you mentioned above, just like current user >>> state (e.g., >>> quota, recent resource usage history, permissions, etc) was already inc= luded >>> in DECADE requirement? what about the data delivery proceeding informat= ion? >>> can you specify the chapter for me ? thanks? >>>>> > >>>>> > >>>>> >> >>>>> >> Data Distribution: >>>>> >> >>>>> >> I'm also confused about the intent of this requirement. This >>>>> >> statement has me somewhat worried: "The distribution is transparen= t to >>>>> >> the users as they interact with the in-network storage as a single >>>>> >> logical system." Does this mean that you are proposing for DECADE >>>>> >> servers to assume the responsibility for deciding how data is to b= e >>>>> >> distributed throughout the network, including the path of the data= , >>>>> >> which servers act as intermediate caches, content expiration polic= ies, >>>>> >> etc? If this is true, I think it is missing one of the major poin= ts >>>>> >> of DECADE. In particular, these decisions are application-dependen= t >>>>> >> and are not implemented within DECADE. Instead, DECADE provides th= e >>>>> >> basic capabilities and the functionality described above are >>>>> >> implemented by the applications using DECADE. >>>>> >> >>>>> >> Or, am I misinterpreting the intent of the requirement? >>>>> >> >>>>> > you mean DECADE provides the basic capabilities, so can you give so= me >>>>> > specify explanations on DECADE capabilities in supporting data >>>>> > distribution? >>>>> >> >>>>> >>>>> The problem statement gives a couple of scenarios. The "Integration >>>>> Examples" presentation from IETF 79 also has more details of an >>>>> on-going effort at Yale. >>> >>>> okay, thx for your information, i will lookup and refer, actually, the >>>> content publisher described in problem statement remind me of the >>>> protocol requirements which i did not find in draft-ietf-decade-reqs-0= 0 to >>>> support content publish. or i miss some points? >>> >>> Which requirements do you think are missing? >>> >>>>> >> Service Assurance: >>>>> >> >>>>> >> It seems problematic to include "assurance" in a DECADE. Shouldn'= t >>>>> >> these instead be part of SLAs with a storage provider? Why should >>>>> >> they be DECADE's responsibility? >>>>> >> >>>>> >> Regarding "resource reservation", are you referring to an actual >>>>> >> reservation (which might be problematic -- see above) or do you me= an >>>>> >> that the resource share should able to be specified at the time th= e >>>>> >> connection opens and be assumed to be the same for the duration of= the >>>>> >> connection? >>>>> >> >>>>> >> Regarding Dynamic Feedback, is this orthogonal to the storage >>>>> >> protocol? It seems like what you want here is a generic "status" >>>>> >> service saying how loaded a server is? >>>>> >> >>>>> > thats right, actually, the flow control mechanism was under discuss= ion >>>>> > in writing the draft at first. what about your opinion in this >>>>> > requirements? >>>>> > >>>>> >>>>> I'm not sure what the typical way of providing such "load status" >>>>> information for IETF protocols, but my inclination is that it should >>>>> not be in the DECADE protocol itself. Maybe someone else with a >>>>> longer history in IETF could jump in here :) >>>> so can i understand that "load status" is kind of necessity informati= on >>>> for DECADE Server, but where and who collects the information are >>>> remain discussion? >>> >>> The storage provider is free to collect the information wherever and >>> however they wish. The DECADE server implementation could additional >>> export whatever status information it wishes. I don't think the DECADE >>> protocol needs to be concerned with that. >>> >>> Note that certain error conditions (e.g., overload, insufficient >>> resources) may be signaled by a DECADE server (there are already have >>> requirements for those). If you are referring to status for a user's >>> resources, there is already a requirement for that too. >>> >>> I'm just not convinced that the DECADE protocol needs to export its >>> current load status to clients. >>> >>> actually i am not sure which elements in DECADE needs the load >>> status,(DECADE client or network storage if the network storage needs t= o >>> redirect the request or both?). >>> >>> >>> >>> And the requirement draft currently seems describe the overload conditi= on as >>> the event triggering. do you think if it is necessary to periodically >>> reporting of the DECADE network status to client for its network storag= e >>> selection? >>> >>> >>> >>> and the requirement draft just describe DECADE which is busy to serve o= ther >>> requests must be able to reject requests, not consider how to handle th= e >>> user request after being rejected? >>> >>>>> >> >>>>> >> Data classification: >>>>> >> >>>>> >> Would it be better to instead have the client specify properties o= f >>>>> >> the content instead of place it into ? See >>>>> >> www.ietf.org/proceedings/78/slides/nfsv4-0.pdf for an example of this >>>>> >> approach for NFS. >>>>> >> >>>>> >> I think a problem with classifying applications is that it assumes >>>>> >> that applications fit one of the supplied classifications. What if= it >>>>> >> may fit multiple classifications? or none? Another problem is it >>>>> >> assumes that servers assume based on indirect and assumed informat= ion >>>>> >> that they know what to do with a particular piece of content. Why = not >>>>> >> have an application specify its desires directly? >>>>> >> >>>>> > >>>>> > >>>>> >> >>>>> >> Small Objects: >>>>> >> >>>>> >> What is the new requirement here? Why is the existing requirement= in >>>>> >> draft-ietf-decade-reqs-00 insufficient? >>>>> >> >>>>> >> This also has me a bit worried: >>>>> >> "And the in-network storage has the limited storage capacity, with= the >>>>> >> arrival of user requests and data distribution requirements, the d= ata >>>>> >> stored in the in-network storage will be replaced if the storage >>>>> >> reaches the limit and data arrivals continually." >>>>> >> >>>>> >> How does the server know what the proper replacement strategy is f= or >>>>> >> an application? I think DECADE's philosophy is that applications >>>>> >> should decide this. A simple way to do this is explicit deletion b= y an >>>>> >> application, but perhaps a more efficient (yet more complex) solut= ion >>>>> >> is for an application to specify the replacement policy to the ser= ver. >>>>> >> >>>>> > actually, the key in "the data classification and small objects " i= s >>>>> > whether does it or not in P2P application? i did not find data >>>>> > classification was adopted in P2P application so far, let alone DEC= ADE >>>>> > need >>>>> > to classify the data used in all kinds of application. >>>>> > >>>>> >>>>> So, do you agree that it is problematic to try and classify each type >>>>> of application and try to specify the typical workload for each class= ? >>>>> >>>>> My point was that I don't think its necessary to do the classificatio= n >>>>> at all. It is more extensible (and directly useful) for a server to >>>>> just give it direct hints about what would be preferable. >>>> >>>> yep, i believe it may be a little difficult, but worthy doing. special= ly >>>> for improving the resource utilization within a single server and redu= cing >>>> the response time for client. what about others opinion? >>> >>> Can you justify why giving classifications (e.g., "I'm a live >>> streaming application") would be better than giving specific hints >>> (e.g., "please don't bother persistent these objects to disk")? >>> >>> i mean data in different kind of operation mode and attribute should ha= ve >>> different user patterns and storage rules, which may be help to improve= the >>> resource utilization and reduce the response time for request, what are= you >>> understanding? >>>> >> >>>>> >> Removal of Expired Records: >>>>> >> >>>>> >> "However, the two scenarios did not mention how to handle the old >>>>> >> resource if the user distributes the new resource which is an upda= ted >>>>> >> copy of the old resource." >>>>> >> >>>>> >> Why does this need to be handled in the requirements? Are you try= ing >>>>> >> to draw the distinction between immediate deletion of content and = lazy >>>>> >> deletion? >>>>> >> >>>>> > i mean the meaning of delete operation and how to handle the expire= d >>>>> > records need to be clarify in requirements. >>>>> >>>>> My inclination is that "deleted" means that other requests the object >>>>> of the same name should result an error, until another object with th= e >>>>> same name is stored. >>>> >>>> okay, under the scenario "client uploads the new version, and did not >>>> specify how to handle the old version", did DECADE server delete the o= lder >>>> version (or just label it unavailable, anyway, it is implementation is= sue >>>> ) >>>> or not ? in another word, just replace the older version with the new >>>> version with the same name? >>> >>> In this case, I would think the "write" of the new object should be >>> rejected, or if desired, we could have an overwrite option. This >>> could be added to the requirements if it helps to clarify. >>> >>> yep, no matter which solution is chosen, let the understanding unanimou= sly:D >>>> how to handle the older version which is >>>> transferring from server to client? >>> >>> I think it would be cleaner to ask the server to continue sending an >>> object once it has been started, but ultimately this would be the >>> decision of the server's implementation I think. Maybe a "SHOULD" >>> requirement. This could be added if desired. >>> >>> Thank you for these questions. It helps design the requirements more >>> cleanly if there are specific scenarios in front of us :) >>> just discussion together:D and also thanks for your points to help me >>> understanding more! >>> Rich >>> >>>>> I think that the time the data is removed from disk (or memory) shoul= d >>>>> be up to the implementation. A storage provider might still have as >>>>> part of some agreement that deleted data will be removed within X >>>>> days/hours/minutes/whatever. >>>> >>>> agree with you. >>>>> >>>>> If people in the WG think it is necessary, we could have a requiremen= t >>>>> that says the protocol should support an argument indicating immediat= e >>>>> deletion, but it is not clear that we need this. >>>>> >>>>> Rich >>>>> >>>>> >> >>>>> >> Thanks! >>>>> >> Rich >>>>> >> >>>>> >> >>>>> >> On Mon, Dec 27, 2010 at 12:57 AM, =E6=9C=B1=E6=BD=87 > wrote: >>>>> >> > Dear all, >>>>> >> > >>>>> >> > There is a slightly updated version of the decade additional >>>>> >> > requirements >>>>> >> > draft. >>>>> >> > >>>>> >> > >>>>> >> > https://datatracker.ietf.org/doc/draft-zhu-decade-additional-req= uirements/ >>>>> >> > >>>>> >> > Jin Peng, Yunfei Zhang and me are expecting to have a discussion >>>>> >> > with >>>>> >> > all of >>>>> >> > you. >>>>> >> > >>>>> >> > Any comments are appreciated! >>>>> >> > >>>>> >> > A new version of I-D, >>>>> >> > draft-zhu-decade-additional-requirements-00.txt >>>>> >> > has been successfully submitted by Xiao Zhu and posted to the IE= TF >>>>> >> > repository. >>>>> >> > >>>>> >> > Filename: draft-zhu-decade-additional-requirements >>>>> >> > Revision: 00 >>>>> >> > Title: Additional protocol requirements on DECAD= E >>>>> >> > Creation_date: 2010-12-27 >>>>> >> > WG ID: Independent Submission >>>>> >> > Number_of_pages: 10 >>>>> >> > >>>>> >> > Abstract: >>>>> >> > The DECoupled Application Data Enroute(DECADE)working group is >>>>> >> > specifying standardized interfaces for accessing in-network stor= age >>>>> >> > from applications to store, retrieve and manage data. The main >>>>> >> > object >>>>> >> > is to provide a framework that is useful to the applications, >>>>> >> > including P2P applications and other data-oriented applications, >>>>> >> > possibly related applications that can benefit from accessing in= - >>>>> >> > network storage. This memo focuses on some requirements such as >>>>> >> > request redirecting and so on which are on the central of mobili= ty, >>>>> >> > wireless network environment and CDN application. We present the= se >>>>> >> > in >>>>> >> > this memo as additional requirements that should be considered f= or >>>>> >> > the DECADE architecture and protocol specifications. >>>>> >> > >>>>> >> > >>>>> >> > >>>>> >> > The IETF Secretariat. >>>>> >> > >>>>> >> > -- >>>>> >> > Best wishes, >>>>> >> > >>>>> >> > Beijing University of Posts & Telecommunications (BUPT) >>>>> >> > Zhu Xiao ( =E6=9C=B1=E6=BD=87 ) >>>>> >> > E-mail: buptxiaozhu@gmail.com >>>>> >> > mobile:+86 134-8881-9004 >>>>> >> > >>>>> >> > _______________________________________________ >>>>> >> > decade mailing list >>>>> >> > decade@ietf.org >>>>> >> > https://www.ietf.org/mailman/listinfo/decade >>>>> >> > >>>>> >> > >>>>> > >>>>> > >>>>> > >>>>> > -- >>>>> > Best wishes, >>>>> > >>>>> > Beijing University of Posts & Telecommunications (BUPT) >>>>> > Zhu Xiao ( =E6=9C=B1=E6=BD=87 ) >>>>> > E-mail: buptxiaozhu@gmail.com >>>>> > mobile:+86 134-8881-9004 >>>> >>>> >>>> >>>> -- >>>> Best wishes, >>>> >>>> Beijing University of Posts & Telecommunications (BUPT) >>>> Zhu Xiao ( =E6=9C=B1=E6=BD=87 ) >>>> E-mail: buptxiaozhu@gmail.com >>>> mobile:+86 134-8881-9004 >>>> >>> >>> >>> -- >>> Best wishes, >>> >>> Beijing University of Posts & Telecommunications (BUPT) >>> Zhu Xiao ( =E6=9C=B1=E6=BD=87 ) >>> E-mail: buptxiaozhu@gmail.com >>> mobile:+86 134-8881-9004 >> > > > -- > Best wishes, > > Beijing University of Posts & Telecommunications (BUPT) > Zhu Xiao ( =E6=9C=B1=E6=BD=87 ) > E-mail: buptxiaozhu@gmail.com > mobile:+86 134-8881-9004 > > > > -- > Best wishes, > > Beijing University of Posts & Telecommunications (BUPT) > Zhu Xiao ( =E6=9C=B1=E6=BD=87 ) > E-mail: buptxiaozhu@gmail.com > mobile:+86 134-8881-9004 > > > > -- > Best wishes, > > Beijing University of Posts & Telecommunications (BUPT) > Zhu Xiao ( =E6=9C=B1=E6=BD=87 ) > E-mail: buptxiaozhu@gmail.com > mobile:+86 134-8881-9004 >