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

Martin Stiemerling <> Thu, 20 September 2012 09:53 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 25DBF21F8773 for <>; Thu, 20 Sep 2012 02:53:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.387
X-Spam-Status: No, score=-102.387 tagged_above=-999 required=5 tests=[AWL=0.212, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id DmOSA+W+6sk4 for <>; Thu, 20 Sep 2012 02:53:31 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id ADDDA21F846F for <>; Thu, 20 Sep 2012 02:53:30 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id AFE87101ECA for <>; Thu, 20 Sep 2012 11:53:29 +0200 (CEST)
X-Virus-Scanned: Amavisd on Debian GNU/Linux (
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id GNUHOLNDRFvi for <>; Thu, 20 Sep 2012 11:53:29 +0200 (CEST)
Received: from ( []) by (Postfix) with ESMTP id 972E5101EC8 for <>; Thu, 20 Sep 2012 11:53:24 +0200 (CEST)
Received: from [] ( by ( with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 20 Sep 2012 11:53:21 +0200
Message-ID: <>
Date: Thu, 20 Sep 2012 11:53:24 +0200
From: Martin Stiemerling <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0
MIME-Version: 1.0
To: <>
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit
X-Originating-IP: []
Subject: Re: [decade] WG Action: Conclusion of Decoupled Application Data Enroute (decade)
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, 20 Sep 2012 09:53:33 -0000

Dear all,

The DECADE working group has just been closed by your responsible Area 

This may come as a surprise to some in the WG, but it should not be a 
surprise for the working drafts authors. The chairs have been notified 
in advance about this action.

There has been significant feedback from the community that questioned 
the technical status of DECADE in the recent past. These concerns were 
not been taken up and were not addressed.

The working group did made only small progress in the last six months, 
which was visible in the low amount of emails on the list, 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:

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:
It is completely unclear how the resources on a DECADE server are 
supposed to be managed and how this management is mapped to the protocol 
split of SDT, DRP, and other management protocols.
Parts of it, such as setting the permissions of data objects clearly 
belongs to the DRP, and it is sort of stated in a vague way in the 
architecture, but it is not documented in a comprehensive way. Other 
parts, such as the accounting is probably not part of the the DRP nor 
SDT, but there is supposedly another interface that is needed for this.

What is the model how data objects are handled on the server in the 
sense about who is allowed to do what? The drafts solely talk about 
tokens to be used to do access control. But there other aspects, for 
instance, who is controlling what on a DECADE server: The DECADE server 
can be operated by an ISP, but the content is provided by a content 
provider and it is access by an unlimited set of clients or limited set 
of clients. How is the access control divided between those parties?

To conclude this email:
The DECADE group started its work in end of April 2010 and is now 
working for more than 2 years on the milestones and drafts. The time 
isn't a big deal, but after 2 years I would have expected that the 
documents are on a good technical level where the WG can build on top of.

Some of you probably ask how the remaining drafts are handled:
First of all, they are not working groups drafts anymore.

But you may resubmit those drafts as individual submissions, address the 
review received so far, e.g., Dave Crocker's, Carsten Bormann's, and the 
AD reviews. Ask for feedback again, if you have addressed the reviews in 
your updated drafts.

If you believe that the drafts are solid work, with a base for further 
protocol development, you may consider to submit the drafts via the RFC 
editor's Independent Stream.

The decisions to close the WG can be of course appealed via the IETF 
appeal process:
See 'Appeals and PR-Actions' under and RFC 2026.



IETF Transport Area Director

NEC Laboratories Europe - Network Research Division NEC Europe Limited
Registered Office: NEC House, 1 Victoria Road, London W3 6BL
Registered in England 283

On 09/20/2012 01:03 AM, IESG Secretary wrote:
> The Decoupled Application Data Enroute (decade) working group in the
> Transport Area has concluded. The IESG contact persons are Martin
> Stiemerling and Wesley Eddy.
> The DECADE working group will be closed after having completed the below
> listed RFCs, but before finishing all of its chartered documents.
> The DECADE WG has reached the point where it is evident that the
> chartered work cannot be completed at a technical level suitable for the
> coming steps of the protocol definition and also within an appropriate
> time frame.
> The list of published RFCs:
> - RFC 6392
> - RFC 6646
> Thank you to all contributors, draft authors, and the chairs.
> The DECADE mailing list ( will remain open.