Subject: [decade] AD review: draft-ietf-decade-problem-statement

From: "David Harrington" <[email-masked]>
Date: Mon, 6 Jun 2011 15:37:47 -0400

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. 

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
[email-masked] (preferred for ietf)
[email-masked]
+1 603 828 1401 (cell)

---

From: "Woundy, Richard" <[email-masked]>
Date: Fri, 10 Jun 2011 14:19:31 +0000

David,

As document shepherd, I will work with the Problem Statement authors to correct the deficiencies you have noted below.

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

While I believe the WG did not *intend* to go beyond its charter, I can see why the current document text raises such concerns. I would tend to agree that revising and/or deleting some of the current text would rectify this issue. I can work on this revision with the authors.

> The specification would create serious security holes, or the
described protocol has self-defeating security vulnerabilities
...
> The chairs can ask me if they want a security advisor to help develop an appropriate threat analysis.

I would like to request a security advisor to help. I think we may need some outside consultation to address this concern. I would rather not be surprised by a DISCUSS from a Security AD during IESG evaluation.

-- Rich

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of David Harrington
Sent: Monday, June 06, 2011 3:38 PM
To: [email-masked]
Cc: [email-masked]
Subject: [decade] AD review: draft-ietf-decade-problem-statement

 

David Harrington

_______________________________________________
decade mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/decade

---

From: Songhaibin <[email-masked]>
Date: Thu, 16 Jun 2011 06:49:02 +0000

Dear David,

Thank you very much for your review as the Area Director. Please see my reply in line.

> From: David Harrington [mailto:[email-masked]]
> Sent: Tuesday, June 07, 2011 3:38 AM
> To: [email-masked]
> Subject: AD review: draft-ietf-decade-problem-statement
> 

Thanks, the authors will remove them.

> go away, and the RFC will outlast them.
OK. We will revise the doc to refer to RFCs instead of relative WGs. In 3.1, the authors will refer to ALTO problem statement RFC instead of ALTO WG.
> instances of proposed solutions.

When I read the charter, it not only states the problems, but also the high level solution direction where this WG should go. Such as the first sentence in paragraph 3. "Both of these challenges can be effectively addressed by using open, standard protocols to access in-network storage. P2P applications can store and retrieve content in the in-network storage, as well as control resources (e.g., bandwidth, connections) consumed by peers in a P2P application." 

> "DECADE" will provide.
Thanks. They will be revised.
>This is a problem statement, not a marketing
> going through a recharter. 
>

Good comment. While DECADE WG is not chartered to develop the protocol at this moment, there are some basic functions needed to address the problems. When it cannot be called DECADE protocol, we just use the term "DECADE" for it. The protocols under this term might be the existing protocols, or existing protocols with extension, or some new protocol which are based on the requirements identified in DECADE WG.

>Here are some claims:

You are right. Can we have a name(such as DECADE or anything else) for the assumed solution direction in the charter and use that name? 

> statement" document? You should be describing the problem, not the

Section 4 actually describes requirements. We may move them to the requirements draft.

> retreives the block." How is this a problem statement?

This is a usage scenario section which describes an example how the solution works. If you do not think this section is needed, we can remove it.

> solved, but should NOT be talking about the details of how a proposed

As above.

> want a security advisor to help develop an appropriate threat

If you can send a security advisor, that will be great and much appreciated!

BR,
-Haibin (as a co-author of problem statement draft)