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

["Y. Richard Yang" <[e-mail]>]

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
>