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

"Guyingjie (Yingjie)" <guyingjie@huawei.com> Mon, 24 September 2012 06:55 UTC

Return-Path: <guyingjie@huawei.com>
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 D4BE321E8043 for <decade@ietfa.amsl.com>; Sun, 23 Sep 2012 23:55:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.471
X-Spam-Level:
X-Spam-Status: No, score=-103.471 tagged_above=-999 required=5 tests=[AWL=2.676, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_UTF8=0.152, 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 xQ08gs4CHpXU for <decade@ietfa.amsl.com>; Sun, 23 Sep 2012 23:55:17 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id A4AC021E803C for <decade@ietf.org>; Sun, 23 Sep 2012 23:55:16 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AKZ12910; Mon, 24 Sep 2012 06:55:14 +0000 (GMT)
Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 24 Sep 2012 07:54:38 +0100
Received: from SZXEML422-HUB.china.huawei.com (10.82.67.161) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 24 Sep 2012 07:55:13 +0100
Received: from SZXEML511-MBS.china.huawei.com ([169.254.4.129]) by szxeml422-hub.china.huawei.com ([10.82.67.161]) with mapi id 14.01.0323.003; Mon, 24 Sep 2012 14:54:37 +0800
From: "Guyingjie (Yingjie)" <guyingjie@huawei.com>
To: Martin Stiemerling <martin.stiemerling@neclab.eu>, "decade@ietf.org" <decade@ietf.org>
Thread-Topic: [decade] WG Action: Conclusion of Decoupled Application Data Enroute (decade)
Thread-Index: AQHNlxXQTgOvNeYw70eyG/03qRmw6JeZEILw
Date: Mon, 24 Sep 2012 06:54:37 +0000
Message-ID: <A27496C192613C44A82D819E1B98DB573405ACA3@SZXEML511-MBS.china.huawei.com>
References: <20120919230313.17329.44102.idtracker@ietfa.amsl.com> <505AE794.8070304@neclab.eu>
In-Reply-To: <505AE794.8070304@neclab.eu>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.138.122.31]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Subject: [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 06:55:19 -0000

I am a bit surprised by the announcement. 

Richard Alimi and I made a lot of revision in -06 according to David Harrington's comments at this Feb. and after that we have made another 2 versions, -07 and -08, both with quite a bit progress to the previous version. So I think this draft is in decent activity, and the authors are trying their best to improve the draft. 

Best Regards
Gu Yingjie


-----邮件原件-----
发件人: decade-bounces@ietf.org [mailto:decade-bounces@ietf.org] 代表 Martin Stiemerling
发送时间: 2012年9月20日 乐乐17:53
收件人: decade@ietf.org
主题: Re: [decade] WG Action: Conclusion of Decoupled Application Data Enroute (decade)

Dear all,

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

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:
- https://datatracker.ietf.org/doc/draft-ietf-decade-reqs/history/
- https://datatracker.ietf.org/doc/draft-ietf-decade-arch/history/

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 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.

2)
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 http://www.ietf.org/iesg/ and RFC 2026.

Regards,

   Martin

-- 
IETF Transport Area Director

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


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 (decade@ietf.org) will remain open.
>