DECoupled Application Data Enroute (DECADE) Problem Statement
RFC 6646

[Ballot comment] I have no objection to the publication of this document. I wondered whether Section 5 should discuss the problem that in-network storage may ...

[Ballot comment]
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?

[Ballot comment] I agree with Peter's thought about para 1 of s3 sounding a lot like marketing. I was surprised by the references to ...

[Ballot comment]
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.

[Ballot discuss] The document may be conflating the following issues: - Problems that P2P applications present - How those problems can be solved by in-network caching - Deficiencies ...

[Ballot discuss]
The document may be conflating the following issues:

- Problems that P2P applications present
- How those problems can be solved by in-network caching
- Deficiencies in currently deployed in-network caching solution.

Deficiencies in currently deployed in-network caching solution might include:
- lack of standardized singling protocols
- lack of access control mechanisms
- etc

While the first first two issues are interesting, I think that the WG wants:
- for the reader of this document to focus on deficiencies in currently deployed caching strategies
- to address  deficiencies in currently deployed caching strategies

Would it be possible to make that more clear? One thing that you could do to focus the reader's attention is to remove text that isn't relevant to the point that you are making.

State changed to AD Evaluation::Revised ID Needed from AD Evaluation::AD Followup. Updated AD Review for draft-ietf-decade-problem-statement-04 My job as Responsible AD is to ...

State changed to AD Evaluation::Revised ID Needed from AD Evaluation::AD Followup.
Updated AD Review for draft-ietf-decade-problem-statement-04

My job as Responsible AD is to bring documents that one of my WGs has requested
be published to the IESG. Part of my responsibility is to make sure the document
is ready for IESG Evaluation. I still have concerns with this document.

PPSP WG submitted a problem statement, and it drew four DISCUSSes because it talkss about things not appropriate to a problem statement document.  I don't want to see the same thing happen with this document. Please rewrite this document to be a statement of the problem, and eliminate those parts that do not belong in a problem statement. This is NOT marketing literature for the wonderful things that DECADE will do.

Below are concerns I feel need to be addressed before I can bring this document
to the IESG.
1) There are references to current IETF WGs, such as in 3.1. WGs go away,
and this RFC will outlast them. Please eliminate them from the text.
The discussion in appendix A, which discusses related work in IETF is acceptable. The IESG may prefer that this be removed upon publication, but it is useful for the IESG to understand how decade fits with the other efforts. Puitting all references to working groups in one place would make this easy to remove them.
Please move the discussion of ALTO and LEDBAT from 3.1 into Appendix A.  ALTO or LEDBAT WGs may be working on related technologies, but THIS document is concerned with the PROBLEMS that in-network storage addresses. So, for example, you are NOT chartered to "complement the ALTO effort", but you are chartered to describe the need to reduce upload access traffic.
/it becomes increasingly important to complement the ALTO effort and reduce upload access traffic/it becomes increasingly important to reduce upload access traffic/
If it is really important to discuss work going on in the IETF, please use "The IETF is working on ..." rather than "The XXX WG is working on ...". If the work has been published as an RFC then you can refer to the IETF technology.

4) There are many instances of marketing-like promises of what "DECADE" will
provide. This is a problem statement, not a marketing document. DECADE is not a
product, or a standard.
Please stop talking about DECADE and talk about the problem.
in 1, "This document introduces DECADE, a standard interface ..."; That is NOT what this document is for. There is no DECADE standard interface, so you cannot introduce it. You should be talking about the problem(s) that in-network storage will address, and what problems decoupling will address.
OLD:
This document introduces DECADE, a standard interface for various P2P applications to access storage and data transport services in the network to improve their efficiency and reduce load on the network infrastructure.
With DECADE, P2P applications can still use their native protocols for signaling and data transport. However, they may use a standard protocol for data access incorporating in-network storage, and fall back to their native data transport protocols if in-network storage is not available or not used.
NEW:
P2P applications suffer decreased efficiency, and the network infrastructure suffers increased load because there is no standardized interface for accessing storage and data transport services in the Internet.
OLD: "With DECADE, P2P applications can still use their native protocols for signaling and data transport. However, they may use a standard protocol for data access incorporating in-network storage, and fall back to their native data transport protocols if in-network storage is not available or not used.";  This is not a problem description; it seems to be a solution description. Maybe fallback is a requirement (which means it belongs in the requirements document, not here).
OLD: "In essence, an open, standard protocol to access in-network storage provides an alternative mechanism for P2P application data access that is decoupled from P2P application control and signaling. This decoupling leads to many advantages, which is explained further in Section 4. " This sound slike a description of a design decision in developing a protocol. Maybe it's a requirement. It is NOT a problem as far as I can see.
If coupling is a problem. then describe what coupling is and why it is problematic.
OLD: "And further, either the existing P2P cache or any new type of in- network storage should be deployed near the edge of the ISP's network so as to gain better performance." sounds like part of a proposed soltuion rather than a description of the PROBLEM.
in 4,
OLD: "DECADE aims to ..." sounds like a proposed solution, not a description of the PROBLEM. You might try rewriting this to disucss how existing P2P caching works, and why it is insufficient to meet the needs of operators today. But please resist the urge to explain how DECADE fixes it.
in 5, these use cases should be discussing the PROBLEMS that occur in thise use cases, not how to integrate with DECADE.
Everyplace you mention DECADE in the text as a solution, it doesn't belong in this document. Please change DECADE server to "in-network storage server"
in 5.2, "If it desires, a content publisher may still apply DRM to the payload. This is independent of any authentication or authorization provided by DECADE." Since DECADE doesn't exist, you shouldn't be discussing the authentication, authorization, or payload of DECADE. The PROBLEMs  of authentication, authorization, and DRM can be discussed (although you probably don't want to get into a deep discussion o fthese until you get into develooping a protocol. I suggest mentioning these in Security Considerations.
9) Security Considerations should discuss the security threats/vulnerabilities
that apply to in-network storage. These ARE part of the PROBLEM space, and these things DO belong in this document.
Saying "they are too numerous to mention" will not get your docuent approved. You need to consider what the thteats to in-network storage are, and document the problem they present.
I suggest looking at RFC3414's description of some standard threats in section 1.1.  I recommend describing the threats, and stating whether they are primary, secondary, or of lesser importance to in-network storage.
You can also look at RFC3553, BCP 72, on writing security considerations. It is important to recognize that your document is a PROBLEM STATEMENT, so all you need to do is document the security problems of in-network storage, not document how DECADE will mitigate those problems. When we get to requirements, we can document what a decade protocol must be able to mitigate, and when we develop a protocol, we can document how the threats are mitigated.
You might want to break the security considerations down into data-at-rest issues versus data-in-motion issues.
new:
10) in 5.3, there is no such things as a decade server because there is no such thing as a decade protocol !!!!!!!! please call it an in-network storage server.
11) it is generally not useful to capitalize terms like Content Publisher unless the term is very specifically defined in the document as part of a protocol. You are not defining a protocol, so I think using lower case (just plain old English) is adequate.
12) in 5.1, it says can copy to storage and then upload from its network storage, "again avoiding usage of the last-mile uplink", but this only avoids using B's last-mile uplink, right? It does however use A's last-mile uplink, doesn't it? I think the wording could be a bit clearer.

AD Review draft-ietf-decade-problem-statement My job as Responsible AD is to bring documents that one of my WGs has requested be published to the IESG. Part ...

AD Review draft-ietf-decade-problem-statement

My job as Responsible AD is to bring documents that one of my WGs has requested be published to the IESG. Part of my responsibility is to make sure the document is ready for IESG Evaluation. I have concerns with this document.

I don't have technical concerns with the document, so much as editorial and process concerns.

As Responsible AD, I request that the WG rewrite this document to be what it is supposed to be, and eliminate those parts that do not belong in a problem statement.
I believe this will not take very long, since in many cases, it just requires some rewording. In other places it will require removing portions of the document, but they might be saved for other documents where the text would be more appropriate.

Here are some of the IESG DISCUSS criteria that I think could be triggered on this document.
- IETF process related to document advancement was not carried out; e.g., the document is outside the scope of the charter of the WG which requested its publication, and so on.
- The specification would create serious security holes, or the described protocol has self-defeating security vulnerabilities (e.g. a protocol that cannot fulfill its purpose without security properties it does not provide).

Below are concerns I feel need to be addressed before I can bring this document to the IESG.

1) There are Informative references that I think don't really need to be there. Some are to Internet-drafts. What happens if that ID never gets published? Having references to work in progress can delay publication of this document. Please make sure these references are REALLY needed in the text.

2) There are references to current IETF WGs, such as in 3.1. But WGs go away, and the RFC will outlast them. Please make sure these references are REALLY needed in the text.

3) This document has a title that says it is the problem statement for Decoupled Application Data Enroute. But throughout the document I find instances of proposed solutions.

4) There are many instances of marketing-like promises of what "DECADE" will provide. This is a problem statement, not a marketing document. DECADE is not a product, and despite what section4 says, the goal of the WG is NOT to design DECADE; it is to identify applications, describe the requirements, and develop an architecture. The WG is explicitly prevented from developing the protocol without going through a recharter. Here are some claims:

"DECADE provides basic access mechanisms"
"DECADE will provide access to storage and data transport services in the network to improve their efficiency and reduce the stress on the network infrastructure."
"It also improves the availability of P2P contents because the in-network storage is always-on."

So how does an architecture without a protocol do all these things?

5) in section 4, it says "(IAP), which is a standard, P2P-application-agnostic protocol ..."

IAP is NOT a standard protocol. A document that is a work in progress that has not yet been approved should never claim it is a standard. And the WG is not even working on designing a protocol yet, just a problem statement, requirements, and an architecture, right?

6) Section 4 claims, IAP includes the following functionality (and then lists a number of things). But the WG is not authorized to work on protocols yet; how can you know what that protocol includes? and why is this description of a proposed solution in the "problem statement" document? You should be describing the problem, not the solution.

7) in section 5, there are lots of "A instructs its in-network storage to downlaod a block from B's in-network storage, and finally A itself retreives the block." How is this a problem statement?

8) in section 5.1, paragraph 5 discusses how B can attach its storage address in the message to its tracker. The WG is NOT designing a protocol. How can you possibly know what can be passed in the message? This problem statement can certainly tak about the problem to be solved, but should NOT be talking about the details of how a proposed protocol works.

9) Security Considerations should discuss the security threats/vulnerabilities that apply to in-network storage. You don't need to describe how to mitigate them here; that can be done in the requirments, architecture, and protocol documents. But you should include the problem description here. The chairs can ask me if they want a security advisor to help develop an appropriate threat analysis.

David Harrington
Director, IETF Transport Area
ietfdbh@comcast.net (preferred for ietf)
dbharrington@huaweisymantec.com
+1 603 828 1401 (cell)