[decade] Review of draft-ietf-decade-reqs-08

[Konstantinos Pentikousis <[e-mail]>]

Dear Akbar, Yingjie, David, All,

I went through the draft (-08) and I find that there's a significant improvement compared to -06. Well done! However, there are still some things that should be addressed, as I explain below. The general comment I have about the whole draft is that it's a bit long and does not get to the main point early on. If I am going to use this document as a checklist against which I will evaluate my proposed implementation of DECADE I have to spend significant effort, when perhaps things could be a bit simpler. Terminology has improved a lot in this version but some inflation of terms remains. Since no real implementation exists so far, I reckon that only high-level requirements can be set at this stage. I tried to summarize all reqs in a cheat sheet at the end of this email. More comments and suggestions below.

Abstract
--------
s/The target of the DECoupled/The goal of the DECoupled


Section 2
---------
In terms of style, I do not see why each term needs its own 2nd level section, besides providing a shorthand for referring to the definitions :)

The Resource Provider/Consumer definitions effectively point to roles that a DECADE client can play. As such, it would be better, imo, to fold them into the client definition instead of having them standout. Suggestion--remove Sec. 2.5-6 and add the following at the end of Sec. 2.1: "A DECADE client can act as a resource provider and/or consumer. In the former role, a client uses his credentials with a server to distribute content to other clients, which act as consumers".

No real need for including the definition of Sec. 2.7. The term is not used later on.

Section 2.8: I would propose to s/Target Application/DECADE-compatible Application/, or simply application. The ID does not actually talk about or differentiate against other apps (i.e. non-DECADE-compatible).

Furthermore:

s/application with that/application which

s/Application divides/Application may divide

Finally, the last sentence of Sec. 2.8 ("We use the term ... supported by DECADE system") is a bit confusing. If an app does not include a client, how is it supported by the DECADE system? If it does include a client, then isn't it a Target App anyway? Do you refer to apps that share the same client? What other apps do you have in mind? I propose to remove this last sentence unless it becomes more clear.

Similarly with Sec. 2.7, the definition of Sec. 2.9 is likely redundant. The term is used only where it is defined and in Fig. 1. I propose to remove it altogether. 

s/The data object is a string/In practice, the data object is a string

s/all the requirements/all requirements


Section 3
---------
Wrt to Fig. 1, just as an observation, I see that there is a hidden app-to-client API, which is not mentioned at all. Second, as I think of implementation, I could imagine that two (or more) apps on the same host could use the same DECADE client. This is alluded to by Req. 8.1 as well, but it's not illustrated here. I think it should. Finally, I would imagine, for instance, that the app/client on the right-hand side could also directly talk to the left-hand side server. In other words, a NE-SW diagonal is missing from Fig. 1 right now. Perhaps this is for keeping the Fig. simple, but it may give the wrong impression to uninitiated readers (i.e. that you always need the 2nd server in the middle to relay the DOs). I guess this is not what you mean.

Moreover, do you foresee the use case where the right-hand side client downloads the DOs to his own server rather than to the local host? (kind of scheduled mirroring case, for example).


Section 4
---------
s/existing ones or new ones/existing or new ones

The term Target Applications is used here, and I think it would be better to use DECADE-compatible Application, or simply application; see above. "Target" does not mean much in this context.

s/existing protocols and new protocols/existing and new protocols


Section 5
---------
Req. 5.1 is very fuzzy. It does not make a case for global uniqueness, neither for local uniqueness (in the confines of a single provider). It's not clear how a provider/server detects that the name is not unique. It's also a bit convoluted. On the one hand, I think the main requirement is that "two objects with the same name should be the same content". One the other hand, RATIONALE calls for a collision handling mechanism. This is a subtle requirement (i.e. it is not a SHOULD, but a MUST--"it is required to provide...")

s/among multiple/between different

This "Exception" text seems to apply to several requirements and it's repeated (7.5, 7.6). Why not group all "exceptions" in one place? And, isn't this covered by Req. 9.5 anyway?

Sec. 5.2 is empty. Accident?

s/flexibility (e.g.,/flexibility,/  and then remove the matching parenthesis.

s/query-able/that can be queried

s/MUST NOT be able to associate/MUST NOT associate

s/what is provided by Section 5.4/what is required by Section 5.4


Section 6
---------
Req. 6.1: what exactly does this add?

"based on cryptographic security". This is not very clear to me. What exactly is this requirement mandating? 

s/its server on whether a Consumer/its server that a Consumer

I think req. 6.5 could be folded into 6.4 

s/should able to/should be able to

s/individual clients, individual data objects/individual clients and data objects

In req. 6.8, what about the case where a server is behind a NAT/firewall?


Section 7
---------
"DECADE MUST specify at least...": I gather you refer to the DECADE WG here, not the DECADE system.

Perhaps you could explain what a "range read/write" is. And what about uploading least popular chunks first, or in any order for that matter? (I guess this not range read/write, right?)

s/in multiple round/in multiple rounds

Req. 7.2 (partial write) and 7.5 (concurrent write) seem to be at odds with each other as the text stands now. I think 7.5 should be modified to address locking a data object, and then it can be folded into Req 7.2 (atomic).

I am not in favor of Req. 7.6 and propose to remove it. The fact that the req. also points to how to handle the error cases popping up once you follow this requirement is not a good thing either :) To some degree this is included in Req. 7.2 as well ("It MAY support range read/write"). But, imo, more importantly the way that this is phrased reads more like an optimization, not a requirement. The motivation behind it (RATIONALE) is also weak, if not wrong. Streaming is not the case for a "data object that has been completely written". Streaming could be perpetual, and the client would typically upload self-contained chunks/frames/etc. If you're talking about the case where the client starts uploading some chunks of a data object to the server and while doing so starts to distribute them to its peers through the decade server, then it's best to include this aspect in Req. 7.2 (partial read/write).


Section 8
---------
See comment about Fig. 1.

Req. 8.2 could be actually part of Section 6 (if it's not already covered by what was said there, e.g. Req. 6.3). Ditto for Req. 8.3 and Req. 6.4.


Section 9
---------

I'm not really in favor of Req. 9.1. I guess you must be familiar with the discussion in httpbis (and elsewhere :) re: error 451. What is the purpose of this requirement from a _technical_ perspective?

More generally, Sec. 9 is a bit more protocol-oriented than it needs to be (a slight resemblance to the error codes of HTTP, for example, could be detected). Reqs 9.3 and 9.4, for instance, could be simply folded under Req. 7.7. Req. 9.2 is part of Req. 6.2, imo.


Section 10
----------
No manageability aspects/requirements from the DECADE Storage Provider pov are listed.


Section 11
----------

Perhaps this section should be based on the 5-tuple (Privacy, Authentication, Identification, Trust, Verification).

Sec. 11.2 reads slightly contradictory to Req. 7.3 ("DECADE-compatible clients may opt to encrypt data before it is transported to the server" vs. "A secure transport MUST be implemented for all communications between a DECADE-compatible client and DECADE-compatible server", respectively).
 
I'm not sure about the added value of Sec. 11.3, which could have been folded into Req. 9.5 anyway.


Requirements Cheat Sheet
------------------------
After reading the ID a couple times I prepared the following cheat sheet, taking some text from the draft in verbatim and adding/rephrasing text (when needed) based on my understanding of the requirements. Please correct me where I'm wrong.
 
The goal of the DECoupled Application Data Enroute (DECADE) system is to provide an open and standard in-network storage system primarily for peer-to-peer applications.

In a DECADE system, efficient storage and data transfer of small data objects is required [5.3]. The data transport protocol can be negotiated but must be secure [7.1, 7.3]. Security is based on cryptographic methods which allow a DECADE provider to access system resources, distribute content to content consumers of its choosing, even when offline, using (if needed) fine-grained access control policies [6.2, 6.3, 6.4, 6.5, 6.6, 8.2, 8.3]. Client data on a server are by default private [6.7]. It is the client that always discovers and initiates a connection to a server [6.8, 6.9], not vice versa. Data objects can be written by a provider in one go or several rounds and can be read by multiple consumers simultaneously [7.2, 7.4]. Every provider is given the means to obtain resource usage stats and quotas [10.1]. Overall, attack mitigation is a MUST [9.5] and transport redirection SHOULD be supported [7.7]

A DECADE system is application independent: 
* two data objects with the same name should be the same content [5.1]
* attributes associated with a data object, such as object creation time, TTL, size, and type have local (server) scope only [5.4]
* application-defined properties (metadata) of data objects are not to be related with the objects themselves within the DECADE system [5.5]

Best Regards,

Kostas