Re: [decade] WG Action: Conclusion of Decoupled Application Data Enroute (decade)

Martin Stiemerling <martin.stiemerling@neclab.eu> Wed, 26 September 2012 11:25 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 0006F21F87DB for <decade@ietfa.amsl.com>; Wed, 26 Sep 2012 04:25:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.45
X-Spam-Level:
X-Spam-Status: No, score=-102.45 tagged_above=-999 required=5 tests=[AWL=0.149, 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 ou6o4RZdHL7e for <decade@ietfa.amsl.com>; Wed, 26 Sep 2012 04:25:15 -0700 (PDT)
Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 0A95A21F86E0 for <decade@ietf.org>; Wed, 26 Sep 2012 04:25:15 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 70F3A101F84; Wed, 26 Sep 2012 13:25:14 +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 xJeJ5inm2jzZ; Wed, 26 Sep 2012 13:25:14 +0200 (CEST)
Received: from ENCELADUS.office.hd (enceladus.office.hd [192.168.24.52]) by mailer1.neclab.eu (Postfix) with ESMTP id 53582101F53; Wed, 26 Sep 2012 13:25:04 +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; Wed, 26 Sep 2012 13:24:13 +0200
Message-ID: <5062E5FA.7030405@neclab.eu>
Date: Wed, 26 Sep 2012 13:24:42 +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: "Y. Richard Yang" <yry@cs.yale.edu>
References: <20120919230313.17329.44102.idtracker@ietfa.amsl.com> <505AE794.8070304@neclab.eu> <505C7772.3070503@cs.yale.edu> <50602997.6090201@neclab.eu> <50607948.6060002@cs.yale.edu>
In-Reply-To: <50607948.6060002@cs.yale.edu>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Originating-IP: [10.1.1.190]
Cc: decade@ietf.org
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: Wed, 26 Sep 2012 11:25:16 -0000

Hi Richard,

On 09/24/2012 05:16 PM, Y. Richard Yang wrote:
> On 9/24/12 5:36 AM, Martin Stiemerling wrote:
>> Hi Richard,
>>
>> On 09/21/2012 04:19 PM, Y. Richard Yang wrote:
>> [...]
>>>
>>>> though there are a number of issues that should have been discussed.
>>>>
>>>> The WG chairs were explicitly notified in mid of June that there are
>>>> severe issues and the WG had time to address those issues. However, it
>>>> must have been obvious even before mid of June that there are severe
>>>> issues, i.e., there has been sufficient time to fix it.
>>>>
>>>> Furthermore, the requirements and architecture draft were submitted to
>>>> the IESG for publication and both drafts have been returned to the WG,
>>>> as both are not ready to be published as RFC.
>>>> You can find the AD review in the datatracker:
>>>> - https://datatracker.ietf.org/doc/draft-ietf-decade-reqs/history/
>>>> - https://datatracker.ietf.org/doc/draft-ietf-decade-arch/history/
>>>>
>>> Your preceding AD reviews are extensive. But I think the main criticism
>>> is writing/English/organization problems, not technical problems.
>>
>> No, it isn't!
>> The criticisms are about technical issues in the sense that it is not
>> clear what DECADE is exactly looking like in many parts
> This could be a useful discussion on the mailing list, before the
> closure of the WG. From my personal point of view, requirements and
> architecture do not specify "exactly looking". My personal design
> approach is that if I can see two reasonable design approaches to
> satisfy one req, I will resist strongly to specify one.

There have been criticism by other reviewers before. Those reviewers 
wrote it in their reviews sent to the draft authors and also in emails 
to the chairs and the responsible AD.

I believe the DECADE had time to work on their drafts and did also 
receive sufficient feedback to change things.

>
>> and also many requirements are not correct or incomplete.
>
> It can helpful if you point out which part is "not correct".
>
>> This is not about language or organizational issues, but it is about
>> technical issues, though that there are organizational issues, e.g.,
>> listing new requirements in the architecture.
>>
>>>
>>>> Both drafts do leave any number of key questions unanswered, i.e.,
>>>> they are far away from being technically useful to be the base for the
>>>> next steps in the protocol development.
>>>>
>>>> To give 2 examples:
>>>> 1)
>>>> It is completely unclear how the resources on a DECADE server are
>>>> supposed to be managed
>>> The basic design principles are stated in Sec. 4.4 and 4.5 of -arch:
>>> Explicit Control and Delegation, with sentences such as
>>>
>>> "Storage Providers will have the ability to explicitly manage the
>>>     entities allowed to utilize the resources at a DECADE-compatible
>>>     server.  This capability is needed for reasons such as capacity-
>>>     planning and legal considerations in certain deployment scenarios."
>>
>> This is a high-level description that does not add anything to
>> question on how it will be managed.
>>
> This is not an empty requirement--it rules out non-managed caches, and
> hence is a step in answering the management issue.

Right, it is one step in answering the management issue. But defining a 
managed cache is not a trivial task, i.e., this needs much more attention.

>
>>>
>>> "Content Providers are able to explicitly and independently manage their
>>> own shares of resources on a server."
>>
>> Nice, but how? The 'how' is about how on the conceptual level and not
>> yet on the protocol detail level.
>>
> We list requirements, not how to satisfy the requirements. We resisted
> strongly to specify how. But even so, the documents suggested some
> 'how'. A related 'how' for this:

Well, requirements must say how they can be satisfied in the sense that 
it must be feasible to test a protocol against the requirements on a 
technical level.

>
>
>       8.3 Distributed Resource Sharing Specification
>
>
>
>     REQUIREMENT(S):  A Provider MUST be able to indicate to its DECADE-
>         compatible server, without itself contacting the server, resource
>         control policies for a Consumer.  The DECADE-compatible server
>         MUST be able to authenticate the resource control policies.

How can the provider indicate its policies to a DECADE server w/o 
contacting the server? This is completely impossible!

Probably you can see from where I coming, by comparing the text in the 
RATIONAL with the REQUIREMENT(S) text. While the rational gives a hint 
to what is expected by this requirement, the requirement itself is not 
useful at all.

And, this requirement does still not say how this is done. Is this done 
via the SDT or DRP or something else?

This is an excellent example about what is wrong with the requirements 
draft, why it has been pushed back to the WG, and why this is one piece 
of the puzzle why the DECADE was closed.

   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 283