Re: [decade] WG Action: Conclusion of Decoupled Application Data Enroute (decade)
"Y. Richard Yang" <yry@cs.yale.edu> Fri, 21 September 2012 14:19 UTC
Return-Path: <yry@cs.yale.edu>
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 8BE3421F8831 for <decade@ietfa.amsl.com>; Fri, 21 Sep 2012 07:19:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001]
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 7yHZsfMvJ4L5 for <decade@ietfa.amsl.com>; Fri, 21 Sep 2012 07:19:33 -0700 (PDT)
Received: from vm-emlprdomr-10.its.yale.edu (vm-emlprdomr-10.its.yale.edu [130.132.50.176]) by ietfa.amsl.com (Postfix) with ESMTP id 18BCB21F86FD for <decade@ietf.org>; Fri, 21 Sep 2012 07:19:33 -0700 (PDT)
Received: from Faculty-Supports-MacBook-Pro-2.local ([128.36.46.181]) (authenticated bits=0) by vm-emlprdomr-10.its.yale.edu (8.14.4/8.14.4) with ESMTP id q8LEJU6H022138 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 21 Sep 2012 10:19:31 -0400
Message-ID: <505C7772.3070503@cs.yale.edu>
Date: Fri, 21 Sep 2012 10:19:30 -0400
From: "Y. Richard Yang" <yry@cs.yale.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1
MIME-Version: 1.0
To: decade@ietf.org
References: <20120919230313.17329.44102.idtracker@ietfa.amsl.com> <505AE794.8070304@neclab.eu>
In-Reply-To: <505AE794.8070304@neclab.eu>
Content-Type: multipart/alternative; boundary="------------020706060909090002060705"
X-Scanned-By: MIMEDefang 2.71 on 130.132.50.176
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: Fri, 21 Sep 2012 14:19:36 -0000
Hi Martin, Since IETF wants paper records on decision. Just for the record, I was and am still very disappointed in the close of the DECADE WG and very surprised by the decision. Please see below. On 9/20/12 5:53 AM, Martin Stiemerling wrote: > 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. An a co-author, I am very surprised to receive the email notification. > 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. Yes. The authors appreciate the feedback! > These concerns were not been taken up and were not addressed. As far as I know, they have been considered. The authors of the Arch document was scheduling a conference call *this week* to discuss the comments, and then were surprised by the announcement that the WG has been closed. > > 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, I think the WG has reasonable amount of email lately. The announcement of close was made on Sept. 20, and two days before the announcement, Sept. 18, there were 5 emails on the mailing 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/ > Your preceding AD reviews are extensive. But I think the main criticism is writing/English/organization problems, not technical problems. > 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." "Content Providers are able to explicitly and independently manage their own shares of resources on a server." "The client can in turn share the granted resources amongst its multiple applications. The share of resources granted by a server is called a User Delegation." "As a simple example, a DECADE-compatible server operated by an ISP might be configured to grant each ISP Subscriber 1.5 Mbit/s of bandwidth. The ISP Subscriber might in turn divide this share of resources amongst a video streaming application and file-sharing application which are running concurrently." In -req: -Multiple Applications Sharing Resources "REQUIREMENT(S): A client MUST be able to indicate to a DECADE- compatible server about resource sharing policies among multiple Target Applications being run/managed by the same client." - Per-Client Resource Policy "REQUIREMENT(S): A Provider MUST be able to specify resource policies (bandwidth share, storage quota, and network connection quota) to individual Consumers for reading from and writing data to its in- network storage within a particular range of time." - 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. - Resource Set REQUIREMENT(S): A DECADE-compatible server MUST allow specification on the following resources: storage, bandwidth, and number of connections, and MAY allow additional types of resources to be specified. ... > 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. The documents intentionally stayed vague as the understanding was that they are not solution-specifying protocol documents. Some authors have a lot more details on resource management, e.g., the recent SIGCOMM ICN'12 paper (http://conferences.sigcomm.org/sigcomm/2012/paper/icn/p25.pdf) discusses using a hierarchical weighted sharing scheme for resource sharing and how to encode them in tokens. But the authors discussed the issues intensively, considered this to be too solution specific, and intentionally left them over to allow a larger design space to allow better participation. > 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. Limited set of clients. See -req: " REQUIREMENT(S): A Provider MUST be able to control which individual clients are authorized to read/write which particular data objects from/to its in-network storage. RATIONALE: A Target Application should able to conduct access control on the granularity of individual clients, individual data objects." > How is the access control divided between those parties? Mostly by clients, but with the exception that ISP has a say when: -req Sec. 9: 9.1. Illegal Data Object REQUIREMENT(S): A DECADE-compatible server SHOULD provide an error indicating that (1) data was rejected from being written, (2) deleted, or (3) marked unavailable. RATIONALE: DECADE Storage Providers may require the ability to (1) avoid storing, (2) delete, or (3) quarantine certain data that has been identified as illegal (or otherwise prohibited). It is not specified how such data is identified, but applications employing DECADE-compatible servers should not break if a Storage Provider is obligated to enforce such policies. Appropriate error conditions should be indicated to applications. EXCEPTION: A DECADE-compatible server should be able to be configured to suppress Illegal Data Object responses for security reasons. Again, I found the decision surprising, abrupt, and disappointing. Richard 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 >
- [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