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

From: IESG Secretary <[email-masked]>
Date: Wed, 19 Sep 2012 16:03:13 -0700

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 ([email-masked]) will remain open.

---

From: Martin Stiemerling <[email-masked]>
Date: Thu, 20 Sep 2012 11:53:24 +0200

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

[email-masked]

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

---

From: Konstantinos Pentikousis <[email-masked]>
Date: Fri, 21 Sep 2012 12:15:06 +0000

Dear Martin, 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

Indeed, it has been a surprise.

  | but it should not be a surprise for the working drafts authors

That's fine, but I think some sort of announcement (and even better a discussion) should have been circulated prior to the IESG announcement. I'm not interested into _who_ should have done this. It's too late and, in the end, irrelevant at this stage. But there's an order of magnitude more people on this mailing list than in the author line of all drafts together. I would consider this a breakdown in communication between the inner- and outer-circle. This was far from what, in general, I would call a "graceful teardown".

  | Both drafts do leave any number of key questions unanswered

I do agree with most of your technical comments. I sent reviews on both documents earlier. That said, imo, this action was a bit abrupt. I do recall a few groups that were much later in their timelines than decade is now, and they still managed to do decent work after a (prolonged) slow start.

In any case, I respect your decision, but I do not second it.

Best Regards,

Kostas

---

From: "Rahman, Akbar" <[email-masked]>
Date: Fri, 21 Sep 2012 09:21:25 -0400

To All,

I also want to make some points for the record:

- As an author, I do NOT feel that I was part of any extensive discussions regarding potential shutting down of the DECADE WG and especially stopping the current active WG drafts (especially the Architecture I-D where I was an author).  

- We did have one lunch meeting in Vancouver with Martin and the chairs but that was publicly announced and open to all in the WG.  At that meeting, I recall Martin asking the attendees if there was industry interest for the DECADE work.  From what I recall, everyone there did express various levels of interest and support.  I didn’t hear anyone say that DECADE was a "wasted effort". So, frankly I was surprised and disappointed to see the WG shut down so suddenly.  If there really is no community support to continue with the activity, then so be it.  But you cannot conclude that there is not interest without first having an open discussion.

- In terms of the document quality.  The first draft of the Architecture I-D was in March 2011.  Since then we have gotten extensive comments from various excellent reviewers.  But as is often the case when you have multiple reviewers, you sometimes get conflicting directions.  Some reviewers wanted a high level abstract architecture that avoided all "implementation" details.  Other reviewers wanted a more detailed approach that got more into the details of the protocols and inner workings of the nodes.  I personally tried in a good faith effort to address all the comments and to try to strike a balance in addressing the philosophies of the different reviewers.

- I agree with Kostas that many documents in other WGs go through similar issues but at the end still managed to produce good work.

- To conclude, I devoted in good faith a fair amount of my energy to participate in advancing the topics in the WG since the first session back in Anaheim.  I defer to the higher powers to make the decision on closing the DECADE WG or not.  However, I clearly want to state that I think it was unfortunate to also suddenly terminate the DECADE Architecture I-D which was being extensively revised whenever we got reviewer comments.  I understand if people are saying that more work has to be done to get it to publication state.  But that does not warrant, in my opinion, to just shut down the work.  Honestly, if you use that criteria there would be many WG documents in other groups that should also be abruptly shut down.

Respectfully,

Akbar

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Konstantinos Pentikousis
Sent: Friday, September 21, 2012 8:15 AM
To: Martin Stiemerling; [email-masked]
Subject: Re: [decade] WG Action: Conclusion of Decoupled Application Data Enroute (decade)

Dear Martin, All,

Best Regards,

Kostas

---

From: Konstantinos Pentikousis <[email-masked]>
Date: Fri, 21 Sep 2012 13:27:08 +0000

Hi Akbar, All,

<snip>
  |At that meeting, I recall Martin asking the attendees if there was
  |industry interest for the DECADE work.
<snip>

For the record, how many folks attended this "lunch meeting"?

Best Regards,

Kostas

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 21 Sep 2012 15:33:28 +0200

On Sep 20, 2012, at 11:53, Martin Stiemerling <[email-masked]> wrote:

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

Let me just say that, although I haven't had much time to invest in this work after my initial review, I'm certainly available for continued review.
Maybe the authors can take the closure of the WG as an opportunity to relieve themselves of some of the too many strings pulling on this.

Focus more sharply, nail things down, and it may still work out.

If you need some cheering up, consider that -- outside the confines of the WG -- draft-farrell-decade-ni did work out, as it did exactly this focusing and nailing down.

Grüße, Carsten

---

From: Martin Stiemerling <[email-masked]>
Date: Fri, 21 Sep 2012 16:08:51 +0200

Hi Akbar,

> - As an author, I do NOT feel that I was part of any extensive discussions regarding potential shutting down of the DECADE WG and especially stopping the current active WG drafts (especially the Ar…

Talk to your chairs and consider that the requirements went from 
publication requested (i.e., on the way to the IESG) back to the WG 
(i.e., not on the way to the IESG).

The same is true for the architecture draft.

> - We did have one lunch meeting in Vancouver with Martin and the chairs but that was publicly announced and open to all in the WG.  At that meeting, I recall Martin asking the attendees if there wa…

To be honestly, but expressing interest and transforming interest to 
technical progress are two very distinct actions.

I have seen a lot of 'expressing interest', but the technical progress 
was and is just not there.

I also told at the lunch meeting in Vancouver that I want to see actions 
on the two main drafts in the WG, i.e., the requirements and the 
architecture. Yes there has been action, but the technical quality of 
the drafts is far from being useful for any further protocol development.
See also my email with 2 examples on issues not addressed in neither the 
requirements nor the architecture draft.

> - In terms of the document quality.  The first draft of the Architecture I-D was in March 2011.  Since then we have gotten extensive comments from various excellent reviewers.  But as is often the…

The architecture drafts clearly fails to show the architecture of the 
DECADE protocols. See my AD review.

You have indeed received extensive reviews, but it is up to date not 
clear if and how they were addressed.

You can see also this, as the draft talks about the DECADE system which 
is not equal to the protocols.

> - I agree with Kostas that many documents in other WGs go through similar issues but at the end still managed to produce good work.

Yes and no. There are examples in both directions, so it doesn't help 
here in this particular case.

> - To conclude, I devoted in good faith a fair amount of my energy to participate in advancing the topics in the WG since the first session back in Anaheim.  I defer to the higher powers to make the…

I wonder why there is so much care about other groups? This is about 
DECADE not any other arbitrary group somewhere else.

With respect to the energy:
If people still believe in DECADE, take the documents, address the 
reviews, get reviews and go for the Independent Stream submission with 
the RFC editor.

Regards,

   Martin

---

From: Martin Stiemerling <[email-masked]>
Date: Fri, 21 Sep 2012 16:10:01 +0200

> For the record, how many folks attended this "lunch meeting"?

I cannot remember the exact number anymore, but it should have been 6 to 
8 people.

---

From: "Y. Richard Yang" <[email-masked]>
Date: Fri, 21 Sep 2012 10:19:30 -0400

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

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

> 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.
>
> protocol development, you may consider to submit the drafts via the 
> RFC editor's Independent Stream.
>
>

---

From: Konstantinos Pentikousis <[email-masked]>
Date: Fri, 21 Sep 2012 14:22:01 +0000

|>    |At that meeting, I recall Martin asking the attendees if there was
  |>    |industry interest for the DECADE work.
  |> <snip>
  |>
  |> For the record, how many folks attended this "lunch meeting"?
  |
  |I cannot remember the exact number anymore, but it should have been 6
  |to 8 people.

So, basically, 3-6 folks besides the chair(s) and the AD.

Many thanks,

Kostas

---

From: "Rahman, Akbar" <[email-masked]>
Date: Fri, 21 Sep 2012 10:23:53 -0400

Hi Martin,

Thanks for the feedback.  I will talk to the other authors and see if they agree to use the Independent Stream submission.

On your point:

	-- snip ---

	-- snip ---

Please note that the nomenclature of "DECADE system" was specifically agreed in the WG to address the comments from the previous AD Dave Harrington.  Also the WG charter specifically prohibited us from selecting and specifying the details of the protocols.  Perhaps this is the cause of some of the confusion for you.

Sincerely,

Akbar

-----Original Message-----
From: Martin Stiemerling [mailto:[email-masked]] 
Sent: Friday, September 21, 2012 10:09 AM
To: Rahman, Akbar
Cc: Konstantinos Pentikousis; [email-masked]
Subject: Re: [decade] WG Action: Conclusion of Decoupled Application Data Enroute (decade)

Hi Akbar,

Regards,

   Martin

---

From: "Rahman, Akbar" <[email-masked]>
Date: Fri, 21 Sep 2012 10:24:47 -0400

Yes.  And note that it was advertised as an informal lunch and not much more.

-----Original Message-----
From: Konstantinos Pentikousis [mailto:[email-masked]] 
Sent: Friday, September 21, 2012 10:22 AM
To: Martin Stiemerling
Cc: Rahman, Akbar; [email-masked]
Subject: RE: [decade] WG Action: Conclusion of Decoupled Application Data Enroute (decade)

Many thanks,

Kostas

---

From: "Y. Richard Yang" <[email-masked]>
Date: Fri, 21 Sep 2012 12:42:57 -0400

Hi Carsten,

Thanks a lot for the offer of continued feedback and the "cheering up" 
to the authors.

As I see it, the WG was guided to work on high-level (-req and -arch) 
documents, and then was killed because the documents do not provide 
sufficient lower-level details. As a result, I do not see them surviving 
the IETF process. Thanks for the good draft-farrell-decade-ni example. 
But the example is a specific design document, and the killed docs are 
design-guideline documents. Hence, I am quite pessimistic on they they 
may go through the IETF process. A specific protocol/component design 
document might be more possible. Does this make sense?

Thanks!

Richard

On 9/21/12 9:33 AM, Carsten Bormann wrote:
> On Sep 20, 2012, at 11:53, Martin Stiemerling<[email-masked]>  wrote:
>

---

From: "Rahman, Akbar" <[email-masked]>
Date: Fri, 21 Sep 2012 19:52:25 -0400

Hi Martin,

Regarding your point below.  Unfortunately, I think that you are factually wrong.  Otherwise prove me wrong by showing me where on the I-D State Diagram http://datatracker.ietf.org/images/state_diagram.png it specifies that sending an I-D back to the authors with comments equals shutting down the WG and stopping a WG approved I-D.

-- snip --

-- snip --

BR

/Akbar

-----Original Message-----
From: Martin Stiemerling [mailto:[email-masked]] 
Sent: Friday, September 21, 2012 10:09 AM
To: Rahman, Akbar
Cc: Konstantinos Pentikousis; [email-masked]
Subject: Re: [decade] WG Action: Conclusion of Decoupled Application Data Enroute (decade)

Hi Akbar,

Regards,

   Martin

---

From: Songhaibin <[email-masked]>
Date: Sat, 22 Sep 2012 05:48:50 +0000

> The same is true for the architecture draft.

I was notified in June about the energy of the working group, but I was also surprised about the abrupt notification of the closure of the WG with the email from Martin on Monday, I saw a good list discussion, new I-D submission and was preparing for the Atlanta meeting when I received this notification. I also expressed my disagree to the comment of lack of technical substances. Before Martin became the AD for the DECADE WG, the architecture document was intended to remove a lot of technical details according to comments received, it's not a protocol draft.

The extensive comments from Martin to these two IDs are mostly effective, but editorial. They could be addressed together with Kostas's comments in the next version . Again, I do not think these two documents are extremely bad and lack of technical substances. 

BR,
-Haibin

---

From: Songhaibin <[email-masked]>
Date: Sat, 22 Sep 2012 09:13:46 +0000

>Again, I do not think these two documents are extremely bad and lack
> of technical substances.

Just to make a clarification, I wanted to express these two documents are not perfect, but they are good. And I admit the documents could have been written elaborate if we paid more attention to the editing work.

BR,
-Haibin

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Songhaibin
> Sent: Saturday, September 22, 2012 1:49 PM
> To: Martin Stiemerling; Rahman, Akbar
> Cc: [email-masked]; Konstantinos Pentikousis
> I was notified in June about the energy of the working group, but I was also
> surprised about the abrupt notification of the closure of the WG with the email
> from Martin on Monday, I saw a good list discussion, new I-D submission and was
> preparing for the Atlanta meeting when I received this notification. I also
> expressed my disagree to the comment of lack of technical substances. Before
> Martin became the AD for the DECADE WG, the architecture document was
> intended to remove a lot of technical details according to comments received, it's
> not a protocol draft.
> 
> The extensive comments from Martin to these two IDs are mostly effective, but
> editorial. They could be addressed together with Kostas's comments in the next
> version . Again, I do not think these two documents are extremely bad and lack
> of technical substances.
> 
> BR,
> -Haibin

---

From: "Rahman, Akbar" <[email-masked]>
Date: Sat, 22 Sep 2012 22:47:25 -0400

For the record, here is the internal Word tracking document from June 2012 that the authors used to ensure that we addressed all the comments that we received from Carsten (Apps Area Reviewer) and Dave Harrington (Previous AD) on the Architecture I-D Rev. 04.  All these comments were incorporated into the subsequent versions of the Architecture I-D.  The authors had kept the chairs in the loop with the tracking document.

This is part of the reason that the authors take offense to (and are puzzled by) the suggestion that we did not seriously address the comments that we got from various reviewers.

/Akbar

-----Original Message-----
From: Songhaibin [mailto:[email-masked]] 
Sent: Saturday, September 22, 2012 1:49 AM
To: Martin Stiemerling; Rahman, Akbar
Cc: [email-masked]; Konstantinos Pentikousis
Subject: RE: [decade] WG Action: Conclusion of Decoupled Application Data Enroute (decade)

BR,
-Haibin

---

From: "Guyingjie (Yingjie)" <[email-masked]>
Date: Mon, 24 Sep 2012 06:54:37 +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

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

Dear all,

To give 2 examples:
1)

2)

To conclude this email:

Regards,

   Martin

---

From: Martin Stiemerling <[email-masked]>
Date: Mon, 24 Sep 2012 11:36:23 +0200

Hi Richard,

On 09/21/2012 04:19 PM, Y. Richard Yang wrote:
[...]
> 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 and also many 
requirements are not correct or incomplete.
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.

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

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

>     resources granted by a server is called a User Delegation."

Sure, that seems to be a glimpse of a concept, but how does the DECADE 
server distinguish the applications? Or this is handled solely by the 
client?
Each of these paragraphs opens up many questions, which are never answered.

>     application which are running concurrently."

Again nice, but how is this done on a conceptual level? What the 
measures in the requirements to ensure this?
For instance, how would expect that an ISP subscriber is identified?

>
> In -req:
> - Multiple Applications Sharing Resources
>
>

But how exactly does the client indicate this and where? How are the 
target applications announced to the server and distinguished during 
operations?
It is clear that the requirements do not specify all the bits and bytes 
of the protocol, but writing a high-level requirement is not sufficient 
at all.

>         network storage within a particular range of time."

This is underspecified: What is the policy for bandwidth share that is 
expected to be implemented by a protocol? Is it 10 % of my outgoing link 
capacity or is it a maximum throughput in x bits per second? What is 
expected here?

And does this related to multiple customers? How is such a customer 
identified?

>> architecture, but it is not documented in a comprehensive way.

You say it correctly: 'vague way' and 'not documented in a comprehensive 
way.'
This is one of the main points that it is all to vague.

> intentionally left them over to allow a larger design space to allow

The requirements and the architecture can get specific without detailing 
what the bits and bytes of the protocol are. This is what it is actually 
needed to design a proper protocol later on!

>         control on the granularity of individual clients, individual data

Those are really high-level requirements that do not saying too much 
about how the protocol should look like in the end. For instance, a main 
use case for this is bittorrent. There are no clients that can be easily 
identified and authorized. How is this handled?

One way would be that the management protocol, which is not specified in 
the requirements or architecture, is used to limited the IP addresses 
that are allowed to access such a DECADE server. This would be a 
requirement!

>         configured to suppress Illegal Data Object responses for security

Those requirements do not answer my question about access control is 
divided between the parties.

   Martin

---

From: Martin Stiemerling <[email-masked]>
Date: Mon, 24 Sep 2012 14:09:51 +0200

> Please note that the nomenclature of "DECADE system" was specifically agreed in the WG to address the comments from the previous AD Dave Harrington.  Also the WG charter specifically prohibited us…

The term "DECADE system" is not necessarily causing confusion to me, it 
is the content of the requirements and the architecture draft. The term 
DECADE system is summarizing nicely what the documents try to achieve, 
although they should discuss requirements and an architecture for DECADE 
protocols.

I would appreciate a point to the conclusion that Dave's comments, or 
anything else. lead to "DECADE system".

Thanks,

   Martin

---

From: Martin Stiemerling <[email-masked]>
Date: Mon, 24 Sep 2012 14:14:41 +0200

Akbar,

> Regarding your point below.  Unfortunately, I think that you are factually wrong.  Otherwise prove me wrong by showing me where on the I-D State Diagram http://datatracker.ietf.org/images/state_dia…

You are referring the state diagram for Internet drafts and this state 
diagram does have no relationship to what happens with a WG.

However, for termination of WGs, please refer to RFC 2418, Section 4, 
copied here for your convenience:

4. Working Group Termination

    Working groups are typically chartered to accomplish a specific task
    or tasks.  After the tasks are complete, the group will be disbanded.
    However, if a WG produces a Proposed or Draft Standard, the WG will
    frequently become dormant rather than disband (i.e., the WG will no
    longer conduct formal activities, but the mailing list will remain
    available to review the work as it moves to Draft Standard and
    Standard status.)

    If, at some point, it becomes evident that a working group is unable
    to complete the work outlined in the charter, or if the assumptions
    which that work was based have been modified in discussion or by
    experience, the Area Director, in consultation with the working group
    can either:

    1. Recharter to refocus its tasks,
    2. Choose new Chair(s), or
    3. Disband.

    If the working group disagrees with the Area Director's choice, it
    may appeal to the IESG (see section 3.4).

and cite the email announcing the termination of the DECADE WG
"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 drafts do not show that the WG is completing its technical work.

   Martin

---

From: Martin Stiemerling <[email-masked]>
Date: Mon, 24 Sep 2012 14:22:01 +0200

Hi Yingjie, all,

The quantity of changes does not matter, it is the quality of the 
changes that matter.

Actually, one part of my conclusion that there is lack of technical 
progress is exactly the amount of energy spent to address the reviewer's 
comments and the outcome as we have it right now.

So, if the majority in this group believes that you have good content, 
why are you not progressing the drafts by addressing the reviewer's 
comments (also by replying to the reviewers)?

   Martin

---

From: Martin Stiemerling <[email-masked]>
Date: Mon, 24 Sep 2012 14:30:41 +0200

Haibin,

> Just to make a clarification, I wanted to express these two documents are not perfect, but they are good. And I admit the documents could have been written elaborate if we paid more attention to th…

To reinforce my reviews:
Both drafts need a major overhaul, as many requirements have been 
spilled over into the architecture draft. Furthermore, the architecture 
draft should clearly lay out the protocol components used and what each 
of the component is intended to do.

The architecture draft can be used to double-check if all requirements 
are there, but it should not list new requirements beyond the ones in 
the requirements draft.

The requirements draft itself needs to have **technical** requirements. 
See for instance one part out of the AD review which needs still some work:
- Section 5.1, head of page 10

    REQUIREMENT(S):  Each Data Object should be named to allow access.
        DECADE-compatible protocol(s) MUST support a data object naming
        scheme that ensures a high probability of uniqueness, with no
        coordination among multiple Storage Providers.  In other words,
        two Data Objects with the same name should be the same content
        with high probability.  A DECADE-compatible server SHOULD be able
        to respond to a DECADE-compatible client with an error indicating
        potential name conflicts.
This requirement is actually a set of *four* requirements all stuffed 
together.
1) Each object must be associated with a name.
2) the naming scheme for those names must support a high probability of 
uniqueness
3) no coordination between multiple decade servers required
4) The error handling. Which is, by the way, not related to data name 
uniqueness whatsoever.

The 'rational' sub-part is not doing its job. E.g., there can be 
collisions on the name space between different objects that have 
different content. However, it is not clear, i.e., the rational, why 
this is ok for your system. The rational is solely motivating the 
collision detection mechanism.
By the way, there is no real requirements that says that such a 
collision detection mechanism is required on the server, as one could 
also implement this on the client, right?

The 'exception' part is actually generating a new requirement which is 
also listed later on. This text isn't consistent and it is really hard 
to read and understand.

---

From: Martin Stiemerling <[email-masked]>
Date: Mon, 24 Sep 2012 14:34:27 +0200

> This is part of the reason that the authors take offense to (and are puzzled by) the suggestion that we did not seriously address the comments that we got from various reviewers.

Where is the publicly accessible record of this?
Any email to the reviewers would good, just in order to see what 
comments you have addressed and how.

   Martin

---

From: "Rahman, Akbar" <[email-masked]>
Date: Mon, 24 Sep 2012 10:55:42 -0400

Dear Martin,

> (i.e., not on the way to the IESG).

At least one of the chairs has written back and said he was very surprised as well that the WG was being closed.  And I pointed to the I-D state diagram to show that sending the I-D back to the authors with comments was part of the process and so could not have flagged to me that the WG was being closed.  So your argument does not hold water.

Now you bring up the RFC 2418 but that has nothing to with the original point.  In fact it certainly seems to be a surprise to everyone BUT you that the WG is being shut down (as evidenced by the avalanche of emails on the list).  So please just concede the point or just move on.

Respectfully yours,

Akbar

-----Original Message-----
From: Martin Stiemerling [mailto:[email-masked]] 
Sent: Monday, September 24, 2012 8:15 AM
To: Rahman, Akbar
Cc: Konstantinos Pentikousis; [email-masked]
Subject: Re: [decade] WG Action: Conclusion of Decoupled Application Data Enroute (decade)

Akbar,

   Martin

---

From: "Y. Richard Yang" <[email-masked]>
Date: Mon, 24 Sep 2012 11:16:24 -0400

On 9/24/12 5:36 AM, Martin Stiemerling wrote:
> 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.

> and also many requirements are not correct or incomplete.

It can helpful if you point out which part is "not correct".

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

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

      8.3 Distributed Resource Sharing Specification

RATIONALE:  One important consideration for a DECADE-compatible
        server is scalability, since a single storage element may be used
        to support many users.  Many Target Applications use small chunk
        sizes and frequent data exchanges.  If such an application
        employed resource control and contacted the DECADE-compatible
        server for each data exchange, this could present a scalability
        challenge for the server as well as additional latency for
        clients.

        The preferred way is to let requesting clients obtain signed
        resource control policies (in the form of a token) from the
        owning client, and then requesting clients can present the policy
        to a DECADE-compatible server directly.  This can result in
        reduced messaging handled by the DECADE-compatible server.

As another example, see Figure 2 of -arch.

> server distinguish the applications? Or this is handled solely by the 
There are multiple design options: distinguish between the apps, or not 
(app is a higher level concept that needs to be managed by an App only). 
A first design distinguished (by explicitly introducing App ID), and a 
later did not. Either way can work. We do not rule out such design options.
> Each of these paragraphs opens up many questions, which are never 
I look at it differently: they specify requirements/goals, now how. What 
is opened up is not questions, are design options. Like I said: My 
personal design approach is that if I can see two reasonable approaches 
to satisfy one req, I will resist strongly to specify one.

> For instance, how would expect that an ISP subscriber is identified?

      2.4 DECADE Account

    An account of a DECADE-compatible server has associated cryptographic
    credentials for access control, and resource allocation attributes on
    the server.

> target applications announced to the server and distinguished during 
There are multiple options: a control channel, or piggy backed on data 
requests.  See preceding text for Sec. 8.3. Regarding the need to 
distinguish apps or not, see preceding on the two design options.

> It is clear that the requirements do not specify all the bits and 
> bytes of the protocol, but writing a high-level requirement is not 
> sufficient at all.
>
>>
> expected to be implemented by a protocol? Is it 10 % of my outgoing 
> link capacity or is it a maximum throughput in x bits per second? What 
> is expected here?
This is very intentionally left open. The authors tried hard to leave 
the design space open. A design option considered your quesions is:
http://conferences.sigcomm.org/sigcomm/2012/paper/icn/p25.pdf
co-authors by the doc authors. See Sec. 4 of the paper. The authors felt 
strongly that IETF should allow other design options, instead of their 
own designs. Hence, they publish a paper on there design, instead of 
putting them in -req so that only their design is OK.
> And does this related to multiple customers? How is such a customer 
See preceding text on Sec. 2.4 DECADE account and the mention on crypto 
credential.
> You say it correctly: 'vague way' and 'not documented in a 
> comprehensive way.'
Like I said. I have different opinions on how -req and -arch should be 
specified.
I am a minimalist and prefer a larger design space for protocol.

>> The documents intentionally stayed vague as the understanding was that
If I could, I would change:
s/stayed vague/leave as much design space as possible/

> The requirements and the architecture can get specific without 
> detailing what the bits and bytes of the protocol are. 

I share this point, and I think that the docs tried to get as specific 
as possible, and but leave as much design space possible as well. It is 
a tradeoff. If you have strong opinions, please discuss on the mailing 
list. Constructive opinions can be particularly valuable, e.g., you feel 
strongly that each client/app is assigned a unique clientID/AppID and 
then we can discuss.

> This is what it is actually needed to design a proper protocol later on!

> about how the protocol should look like in the end. 
It does say a lot and answered your question: by an unlimited set of 
clients or limited set. There are multiple design options, control 
channel setting ACL or token, etc. The doc suggested token, but did not 
make it a requirement.

> For instance, a main use case for this is bittorrent. There are no 
> clients that can be easily identified and authorized. How is this 
> handled?
>
The bittorren software client needs to be changed (e.g., with a plugin) 
and the user needs to specify DECADE account(s) that the software client 
can use. A recent design option being evaluated is to use OAuth.

> One way would be that the management protocol, which is not specified 
> in the requirements or architecture, is used to limited the IP 
> addresses that are allowed to access such a DECADE server. This would 
> be a requirement!
>
Setting up allowed IP address is an approximate way to implement the 
specified client-level access-control requirement.  The existing 
requirement is checkable.

> divided between the parties.
I think it does. User Delegation means that users are the boss. Storage 
Provider can interject but need to provide error messages. This was 
discussed in the WG and agreed upon.

Richard

---

From: "Y. Richard Yang" <[email-masked]>
Date: Mon, 24 Sep 2012 11:19:43 -0400

On 9/24/12 8:14 AM, Martin Stiemerling wrote:
>> Regarding your point below.  Unfortunately, I think that you are 
>> factually wrong.  Otherwise prove me wrong by showing me where on the 
>> I-D State Diagram 
>> http://datatracker.ietf.org/images/state_diagram.png it specifies 
>> that sending an I-D back to the authors with comments equals shutting 
>> down the WG and stopping a WG approved I-D.
>
I am wondering this large number of emails in the last few days is the 
"consultation with the working group" part or not.

Richard
>>> - As an author, I do NOT feel that I was part of any extensive 
>>> discussions regarding potential shutting down of the DECADE WG and 
>>> especially stopping the current active WG drafts (especially the 
>>> Architecture I-D where I was an author).
>>
>>> - As an author, I do NOT feel that I was part of any extensive 
>>> discussions regarding potential shutting down of the DECADE WG and 
>>> especially stopping the current active WG drafts (especially the 
>>> Architecture I-D where I was an author).
>>
>>> - We did have one lunch meeting in Vancouver with Martin and the 
>>> chairs but that was publicly announced and open to all in the WG.  
>>> At that meeting, I recall Martin asking the attendees if there was 
>>> industry interest for the DECADE work.  From what I recall, everyone 
>>> there did express various levels of interest and support.  I didn’t 
>>> hear anyone say that DECADE was a "wasted effort". So, frankly I was 
>>> surprised and disappointed to see the WG shut down so suddenly.  If 
>>> there really is no community support to continue with the activity, 
>>> then so be it.  But you cannot conclude that there is not interest 
>>> without first having an open discussion.
>>
>>> - In terms of the document quality.  The first draft of the 
>>> Architecture I-D was in March 2011.  Since then we have gotten 
>>> extensive comments from various excellent reviewers.  But as is 
>>> often the case when you have multiple reviewers, you sometimes get 
>>> conflicting directions.  Some reviewers wanted a high level abstract 
>>> architecture that avoided all "implementation" details.  Other 
>>> reviewers wanted a more detailed approach that got more into the 
>>> details of the protocols and inner workings of the nodes.  I 
>>> personally tried in a good faith effort to address all the comments 
>>> and to try to strike a balance in addressing the philosophies of the 
>>> different reviewers.
>>
>>> - I agree with Kostas that many documents in other WGs go through 
>>> similar issues but at the end still managed to produce good work.
>>
>>> - To conclude, I devoted in good faith a fair amount of my energy to 
>>> participate in advancing the topics in the WG since the first 
>>> session back in Anaheim.  I defer to the higher powers to make the 
>>> decision on closing the DECADE WG or not. However, I clearly want to 
>>> state that I think it was unfortunate to also suddenly terminate the 
>>> DECADE Architecture I-D which was being extensively revised whenever 
>>> we got reviewer comments.  I understand if people are saying that 
>>> more work has to be done to get it to publication state.  But that 
>>> does not warrant, in my opinion, to just shut down the work.  
>>> Honestly, if you use that criteria there would be many WG documents 
>>> in other groups that should also be abruptly shut down.
>>
>>> That's fine, but I think some sort of announcement (and even better 
>>> a discussion) should have been circulated prior to the IESG 
>>> announcement. I'm not interested into _who_ should have done this. 
>>> It's too late and, in the end, irrelevant at this stage. But there's 
>>> an order of magnitude more people on this mailing list than in the 
>>> author line of all drafts together. I would consider this a 
>>> breakdown in communication between the inner- and outer-circle. This 
>>> was far from what, in general, I would call a "graceful teardown".
>>>
>>> I do agree with most of your technical comments. I sent reviews on 
>>> both documents earlier. That said, imo, this action was a bit 
>>> abrupt. I do recall a few groups that were much later in their 
>>> timelines than decade is now, and they still managed to do decent 
>>> work after a (prolonged) slow start.
>>>

---

From: Martin Stiemerling <[email-masked]>
Date: Wed, 26 Sep 2012 12:42:27 +0200

Hi Akbar,

The decision has been made and there are ways forward for the drafts 
described in my original email. If you believe that there have been 
errors in the process, you can also follow what's written in my original 
email.

If DECADE is really important, take your time and get the drafts 
progressed by solving the technical challenges.

  Martin

---

From: Martin Stiemerling <[email-masked]>
Date: Wed, 26 Sep 2012 13:24:42 +0200

Hi Richard,

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

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

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

>         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

---

From: "Y. Richard Yang" <[email-masked]>
Date: Thu, 27 Sep 2012 19:10:12 -0400

> contacting the server? This is completely impossible!

This is possible! A provider can indicate the policies in a token. Hence,
the consumer contacts the server and the provider does not!

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

I gave one example how abve. There can be other smart approaches that I may
not foresee. The documents specify what but now how.

> Is this done via the SDT or DRP or something else?
>
> Either way can work. Depend on the design.

> draft,

I look it diferrently. This is an excellent example of giving requirements,
but not limiting the design space!

Richard

> why it has been pushed back to the WG, and why this is one piece of the
> puzzle why the DECADE was closed.
>
>   Martin
>
> --

---

From: "Y. Richard Yang" <[email-masked]>
Date: Thu, 27 Sep 2012 19:44:00 -0400

On Thursday, September 27, 2012, Y. Richard Yang wrote:

> I gave one example how abve. There can be other smart approaches that I
> may not foresee. The documents specify what but now how.
>
>
> I look it diferrently. This is an excellent example of giving
> requirements, but not limiting the design space!
>

Let me add to this. As a researcher, I am always impressed by human
ingeninuity.  As an example, in my today's lecture on wireless
networks/mobile computing, we discussed how to handle ISI. After so many
years, I am still impressed by the endless human ingenuity in handling the
problem, wave shaping, vertibi, ofdm, rake receiver... You learn to be
humble. One key research strategy in my group is also to come up with
surprising solutions. This approach works well and we are the few who
consistently publish in sigcomm, the most competitive networking
conference. Hence, in the requirement specification setting, we make sure
that it is possible, by coming up with a solution ourself, and then post
the requirement. We are humble, but not incapable. I am puzzled that you
did not ask these questions in your tenure as the AD so that we can
help/clarify. This is one piece of the puzzle why we were hugely surprised
by the unexpected closure.

Richard

---

From: "Y. Richard Yang" <[email-masked]>
Date: Thu, 27 Sep 2012 21:07:24 -0400

> "consultation with the working group" part or not.

A timer just fired time out. So let me resend the procedure question. Can
someone clarify where, when, and with whom did the "in consultation with
the working group" happen?

Thanks!

Richard

> - As an author, I do NOT feel that I was part of any extensive discussions
> regarding potential shutting down of the DECADE WG and especially stopping
> the current active WG drafts (especially the Architecture I-D where I was
> an author).
>
>
> - We did have one lunch meeting in Vancouver with Martin and the chairs
> but that was publicly announced and open to all in the WG.  At that
> meeting, I recall Martin asking the attendees if there was industry
> interest for the DECADE work.  From what I recall, everyone there did
> express various levels of interest and support.  I didn’t hear anyone say
> that DECADE was a "wasted effort". So, frankly I was surprised and
> disappointed to see the WG shut down so suddenly.  If there really is no
> community support to continue with the activity, then so be it.  But you
> cannot conclude that there is not interest without first having an open
> discussion.
>
>
> - In terms of the document quality.  The first draft of the Architecture
> I-D was in March 2011.  Since then we have gotten extensive comments from
> various excellent reviewers.  But as is often the case when you have
> multiple reviewers, you sometimes get conflicting directions.  Some
> reviewers wanted a high level abstract architecture that avoided all
> "implementation" details.  Other reviewers wanted a more detailed approach
> that got more into the details of the protocols and inner workings of the
> nodes.  I personally tried in a good faith effort to address all the
> comments and to try to strike a balance in addressing the philosophies of
> the different reviewers.
>
>
> You have indeed received extensive review
>
>

---

From: Martin Stiemerling <[email-masked]>
Date: Fri, 28 Sep 2012 15:34:11 +0200

On 09/28/2012 01:10 AM, Y. Richard Yang wrote:
> This is possible! A provider can indicate the policies in a token.
> Hence, the consumer contacts the server and the provider does not!

Right, but than I do have the question on how the DECADE server is able 
to verify that the token is correct?

>
>
>     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.
>
>     This is an excellent example about what is wrong with the
>     requirements draft,
>
>

No, it is limiting the space to the use of tokens and it requires 
modifications to the application protocol, e.g., to the 2p filesharing 
protocol where the tokens would need to be exchanged.

It is necessary to take design choices at the beginning and I would 
expect that the architecture draft would do this. For instance, 
explicitly arguing for tokens and introducing it. Such decisions do 
influence a lot in the design and also in the requirements.

For instance, if you use tokens, you need a management interface where 
you can configure, for instance, public keys which are used to verify if 
a token has been issued by a known and trusted party. This assumes that 
the token is signed with the private key.

   Martin

>
> Richard
>
>     why it has been pushed back to the WG, and why this is one piece of
>     the puzzle why the DECADE was closed.
>
>        Martin
>
>     --

---

From: Martin Stiemerling <[email-masked]>
Date: Fri, 28 Sep 2012 15:37:46 +0200

On 09/28/2012 03:07 AM, Y. Richard Yang wrote:
>     I am wondering this large number of emails in the last few days is
>     the "consultation with the working group" part or not.
>
>
> A timer just fired time out. So let me resend the procedure question.
> Can someone clarify where, when, and with whom did the "in consultation
> with the working group" happen?

I did discuss with the chairs and they are my first contact to the WG.
The operation of the WG is the duty of the chairs.

Again what I have said before and to save everybody's energy and time:
Write an appeal, if you believe that DECADE has done technical progress 
and it was closed without any good reason, or if you see procedural 
mistakes.

   Martin

>                 - As an author, I do NOT feel that I was part of any
>                 extensive discussions regarding potential shutting down
>                 of the DECADE WG and especially stopping the current
>                 active WG drafts (especially the Architecture I-D where
>                 I was an author).
>
>
>                 - As an author, I do NOT feel that I was part of any
>                 extensive discussions regarding potential shutting down
>                 of the DECADE WG and especially stopping the current
>                 active WG drafts (especially the Architecture I-D where
>                 I was an author).
>
>
>                 - We did have one lunch meeting in Vancouver with Martin
>                 and the chairs but that was publicly announced and open
>                 to all in the WG.  At that meeting, I recall Martin
>                 asking the attendees if there was industry interest for
>                 the DECADE work.  From what I recall, everyone there did
>                 express various levels of interest and support.  I
>                 didn’t hear anyone say that DECADE was a "wasted
>                 effort". So, frankly I was surprised and disappointed to
>                 see the WG shut down so suddenly.  If there really is no
>                 community support to continue with the activity, then so
>                 be it.  But you cannot conclude that there is not
>                 interest without first having an open discussion.
>
>
>                 - In terms of the document quality.  The first draft of
>                 the Architecture I-D was in March 2011.  Since then we
>                 have gotten extensive comments from various excellent
>                 reviewers.  But as is often the case when you have
>                 multiple reviewers, you sometimes get conflicting
>                 directions.  Some reviewers wanted a high level abstract
>                 architecture that avoided all "implementation" details.
>                   Other reviewers wanted a more detailed approach that
>                 got more into the details of the protocols and inner
>                 workings of the nodes.  I personally tried in a good
>                 faith effort to address all the comments and to try to
>                 strike a balance in addressing the philosophies of the
>                 different reviewers.
>
>

---

From: "Y. Richard Yang" <[email-masked]>
Date: Fri, 28 Sep 2012 10:22:00 -0400

On 9/28/12 9:34 AM, Martin Stiemerling wrote:
> Right, but than I do have the question on how the DECADE server is 
> able to verify that the token is correct?
The requirement has the following sentence: "The DECADE-compatible 
server MUST be able to authenticate the resource control policies". Like 
I repeatedly said, I do not feel that it is wise to specify how to 
authenticate: there are so many variations, shared key, public key, from 
standard textbooks.

> No, it is limiting the space to the use of tokens 
It is not clear that we have to be limited to the use of tokens. The 
-req authors have thought through that tokens work and hence it is a 
feasible requirement. But there is no "proof" that it is a necessary 
condition.

> and it requires modifications to the application protocol, e.g., to 
> the 2p filesharing protocol where the tokens would need to be exchanged.
>
Yes. This is consistent.

> It is necessary to take design choices at the beginning 
It depends on what you mean by "it is necessary". Personally, I prefer a 
minimal (late-binding) approach, i.e., give more design choices at the 
beginning.

> and I would expect that the architecture draft would do this. For 
> instance, explicitly arguing for tokens and introducing it. Such 
> decisions do influence a lot in the design and also in the requirements.
>
> you can configure, for instance, public keys 
It does not have to use a public-key system. It can be a symmetric key 
system. Either way can go through, as I think through, and why not leave 
this space to the protocol designer so that they can come up with a 
coherent design? This is IETF design, not a class homework assignment 
where the instructor already has a solution in mind and prefers that the 
students just say the right answer.

Thanks.

Richard

> which are used to verify if a token has been issued by a known and 
> trusted party. This assumes that the token is signed with the private 
> key.
>
>   Martin
>
>>
>> Richard
>>