Re: [decade] WG Action: Conclusion of Decoupled Application Data Enroute (decade)
Martin Stiemerling <martin.stiemerling@neclab.eu> Mon, 24 September 2012 12:31 UTC
Return-Path: <Martin.Stiemerling@neclab.eu>
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 60A5121F8618 for <decade@ietfa.amsl.com>; Mon, 24 Sep 2012 05:31:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.438
X-Spam-Level:
X-Spam-Status: No, score=-102.438 tagged_above=-999 required=5 tests=[AWL=0.161, 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 KtzYAcQNilVD for <decade@ietfa.amsl.com>; Mon, 24 Sep 2012 05:31:02 -0700 (PDT)
Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 6E6B721F8615 for <decade@ietf.org>; Mon, 24 Sep 2012 05:31:02 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 80E6C101F1B; Mon, 24 Sep 2012 14:31:01 +0200 (CEST)
X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de)
Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8rlBgUAwegAG; Mon, 24 Sep 2012 14:31:01 +0200 (CEST)
Received: from ENCELADUS.office.hd (enceladus.office.hd [192.168.24.52]) by mailer1.neclab.eu (Postfix) with ESMTP id 61D04101EFA; Mon, 24 Sep 2012 14:30:41 +0200 (CEST)
Received: from [10.1.1.190] (10.1.1.190) by skoll.office.hd (192.168.125.11) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 24 Sep 2012 14:30:06 +0200
Message-ID: <50605271.7030105@neclab.eu>
Date: Mon, 24 Sep 2012 14:30:41 +0200
From: Martin Stiemerling <martin.stiemerling@neclab.eu>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0
MIME-Version: 1.0
To: Songhaibin <haibin.song@huawei.com>
References: <20120919230313.17329.44102.idtracker@ietfa.amsl.com><505AE794.8070304@neclab.eu> <8D38716F0C1A444BA0CD7E96454366C23A4DDEF6@szxeml545-mbx.china.huawei.com> <D60519DB022FFA48974A25955FFEC08C04B138D2@SAM.InterDigital.com> <505C74F3.7060002@neclab.eu> <E33E01DFD5BEA24B9F3F18671078951F23B33F6F@szxeml534-mbx.china.huawei.com> <E33E01DFD5BEA24B9F3F18671078951F23B34011@szxeml534-mbx.china.huawei.com>
In-Reply-To: <E33E01DFD5BEA24B9F3F18671078951F23B34011@szxeml534-mbx.china.huawei.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Originating-IP: [10.1.1.190]
Cc: "decade@ietf.org" <decade@ietf.org>, Konstantinos Pentikousis <k.pentikousis@huawei.com>
Subject: Re: [decade] WG Action: Conclusion of Decoupled Application Data Enroute (decade)
X-BeenThere: decade@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" <decade.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/decade>, <mailto:decade-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/decade>
List-Post: <mailto:decade@ietf.org>
List-Help: <mailto:decade-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/decade>, <mailto:decade-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 24 Sep 2012 12:31:03 -0000
Haibin, On 09/22/2012 11:13 AM, Songhaibin wrote: >> Again, I do not think these two documents are extremely bad and lack >> of technical substances. > > Just to make a clarification, I wanted to express these two documents are not perfect, but they are good. And I admit the documents could have been written elaborate if we paid more attention to the editing work. To reinforce my reviews: Both drafts need a major overhaul, as many requirements have been spilled over into the architecture draft. Furthermore, the architecture draft should clearly lay out the protocol components used and what each of the component is intended to do. The architecture draft can be used to double-check if all requirements are there, but it should not list new requirements beyond the ones in the requirements draft. The requirements draft itself needs to have **technical** requirements. See for instance one part out of the AD review which needs still some work: - Section 5.1, head of page 10 REQUIREMENT(S): Each Data Object should be named to allow access. DECADE-compatible protocol(s) MUST support a data object naming scheme that ensures a high probability of uniqueness, with no coordination among multiple Storage Providers. In other words, two Data Objects with the same name should be the same content with high probability. A DECADE-compatible server SHOULD be able to respond to a DECADE-compatible client with an error indicating potential name conflicts. This requirement is actually a set of *four* requirements all stuffed together. 1) Each object must be associated with a name. 2) the naming scheme for those names must support a high probability of uniqueness 3) no coordination between multiple decade servers required 4) The error handling. Which is, by the way, not related to data name uniqueness whatsoever. The 'rational' sub-part is not doing its job. E.g., there can be collisions on the name space between different objects that have different content. However, it is not clear, i.e., the rational, why this is ok for your system. The rational is solely motivating the collision detection mechanism. By the way, there is no real requirements that says that such a collision detection mechanism is required on the server, as one could also implement this on the client, right? The 'exception' part is actually generating a new requirement which is also listed later on. This text isn't consistent and it is really hard to read and understand. > > BR, > -Haibin > >> -----Original Message----- >> From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.org] On Behalf Of >> Songhaibin >> Sent: Saturday, September 22, 2012 1:49 PM >> To: Martin Stiemerling; Rahman, Akbar >> Cc: decade@ietf.org; Konstantinos Pentikousis >> Subject: Re: [decade] WG Action: Conclusion of Decoupled Application Data >> Enroute (decade) >> >>> Talk to your chairs and consider that the requirements went from >>> publication requested (i.e., on the way to the IESG) back to the WG >>> (i.e., not on the way to the IESG). >>> >>> The same is true for the architecture draft. >> >> I was notified in June about the energy of the working group, but I was also >> surprised about the abrupt notification of the closure of the WG with the email >> from Martin on Monday, I saw a good list discussion, new I-D submission and was >> preparing for the Atlanta meeting when I received this notification. I also >> expressed my disagree to the comment of lack of technical substances. Before >> Martin became the AD for the DECADE WG, the architecture document was >> intended to remove a lot of technical details according to comments received, it's >> not a protocol draft. >> >> The extensive comments from Martin to these two IDs are mostly effective, but >> editorial. They could be addressed together with Kostas's comments in the next >> version . Again, I do not think these two documents are extremely bad and lack >> of technical substances. >> >> BR, >> -Haibin -- 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 283
- [decade] WG Action: Conclusion of Decoupled Appli… IESG Secretary
- Re: [decade] WG Action: Conclusion of Decoupled A… Martin Stiemerling
- Re: [decade] WG Action: Conclusion of Decoupled A… Konstantinos Pentikousis
- Re: [decade] WG Action: Conclusion of Decoupled A… Rahman, Akbar
- Re: [decade] WG Action: Conclusion of Decoupled A… Konstantinos Pentikousis
- Re: [decade] WG Action: Conclusion of Decoupled A… Carsten Bormann
- Re: [decade] WG Action: Conclusion of Decoupled A… Martin Stiemerling
- Re: [decade] WG Action: Conclusion of Decoupled A… Martin Stiemerling
- Re: [decade] WG Action: Conclusion of Decoupled A… Y. Richard Yang
- Re: [decade] WG Action: Conclusion of Decoupled A… Konstantinos Pentikousis
- Re: [decade] WG Action: Conclusion of Decoupled A… Rahman, Akbar
- Re: [decade] WG Action: Conclusion of Decoupled A… Rahman, Akbar
- Re: [decade] WG Action: Conclusion of Decoupled A… Y. Richard Yang
- Re: [decade] WG Action: Conclusion of Decoupled A… Rahman, Akbar
- Re: [decade] WG Action: Conclusion of Decoupled A… Songhaibin
- Re: [decade] WG Action: Conclusion of Decoupled A… Songhaibin
- Re: [decade] WG Action: Conclusion of Decoupled A… Rahman, Akbar
- [decade] 答复: WG Action: Conclusion of Decoupled A… Guyingjie (Yingjie)
- Re: [decade] WG Action: Conclusion of Decoupled A… Martin Stiemerling
- Re: [decade] WG Action: Conclusion of Decoupled A… Martin Stiemerling
- Re: [decade] WG Action: Conclusion of Decoupled A… Martin Stiemerling
- Re: [decade] 答复: WG Action: Conclusion of Decoupl… Martin Stiemerling
- Re: [decade] WG Action: Conclusion of Decoupled A… Martin Stiemerling
- Re: [decade] WG Action: Conclusion of Decoupled A… Martin Stiemerling
- Re: [decade] WG Action: Conclusion of Decoupled A… Rahman, Akbar
- Re: [decade] WG Action: Conclusion of Decoupled A… Y. Richard Yang
- Re: [decade] WG Action: Conclusion of Decoupled A… Y. Richard Yang
- Re: [decade] WG Action: Conclusion of Decoupled A… Martin Stiemerling
- Re: [decade] WG Action: Conclusion of Decoupled A… Martin Stiemerling
- Re: [decade] WG Action: Conclusion of Decoupled A… Y. Richard Yang
- Re: [decade] WG Action: Conclusion of Decoupled A… Y. Richard Yang
- Re: [decade] WG Action: Conclusion of Decoupled A… Y. Richard Yang
- Re: [decade] WG Action: Conclusion of Decoupled A… Martin Stiemerling
- Re: [decade] WG Action: Conclusion of Decoupled A… Martin Stiemerling
- Re: [decade] WG Action: Conclusion of Decoupled A… Y. Richard Yang