DECoupled Application Data Enroute (DECADE) Problem Statement
draft-ietf-decade-problem-statement-06

I have no objection to the publication of this document.

I wondered whether Section 5 should discuss the problem that in-network
storage may result in false data being supplied either through the
data on a legitimate store being modified, or through a bogus store
being introduced into the network. The material in Section 5 seems to
cover the security of the protocol itself (and that may be enough)
without describing these risks. Sis I miss something?

This is a well-written document. The first paragraph of Section 3 reads like marketing text. Is it needed?

Here are some suggestions that might make this document more useful to the working group:

Much of this document states the problem is that there's no standardized network storage solution. That's the solution you want to pursue, not the problem. A reader can get that the problem is some peer-to-peer protocols put stress on access networks. A potential solution that might treat the network as a whole more nicely would be to make it possible for peers that were on bandwidth constrained access to put things in a place that is both not bandwidth constrained and accessible by other peers. A secondary problem is that if existing protocols each tried to make this possible in their own way, it's harder for middleboxes that aren't explicitly part of that protocol to inject themselves to "help", and that could be avoided by giving all of the existing (and potentially any new) p2p protocols a common way to minimize moving content across the constrained barrier. A reader can get this message, but they have to read deeply and infer some of it. Please consider making the problem the main point of the text, and clearly identifying that network storage is the proposed solution path.

The document speaks of a service "inside a network". It would help to be more precise. Do you mean "in the relatively bandwidth-unconstrained part of the network" or "in an access-regulated single administrative domain" or something else?

The document asserts several times that using in-network resources will help, but doesn't support the assertion. Are
there studies you can point to that show it's likely to help?

The second paragraph quotes some reports on p2p traffic on access networks, using it to motivate reducing access traffic, but then claims it also motivates reducing "cross-domain and backbone traffic". While reducing traffic in general is probably a good idea the argument presented doesn't support the conclusion.

The document says a P2P cache is likely to be much better connected to end hosts than to remote peers. The remote
peers _are_ end hosts. What are you actually trying to distinguish here?

Section 5.2 (Copyright and Legal Issues) puts filtering and DRM out of scope for this document. It would be better to say something like "is not in scope for the problem this document proposes solving".

I agree with Peter's thought about para 1 of s3 sounding a lot like marketing.

I was surprised by the references to RFC 3414 in s5.4-5.7.  Is that where the solution is expected to come from or where the definition came from?  If it's the later wouldn't RFC 4949 be a better reference - it's the Internet Security Glossary, Version 2.   Also are there any privacy considerations to be worried about?

I also found myself thinking along the same lines as Ron and Robert.