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