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

[Songhaibin <[e-mail]>]

Hi Kostas,

Thank you for these detailed comments. While most of the document are editorial, and the document has been sent to our AD for evaluation, we can incorporate your valid comments when the AD think it needs to be revised, or during the RFC-editor's stage.

And at the same, I cannot agree with your proposal to remove section 7.6 and 9.1. The requirement in 7.6 is a MAY, is optional, but it is a very important optimization for streaming applications. Even a 2 or 3 seconds chunk size is not small. Not every streaming application sends data every 10ms or 20ms.

While for section 9.1, I'm unclear about the discussion result wr error 451. But it is very useful to use a technical message instead of the lawful message to indicate users why they cannot access the data.


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

...for Content Distribution Applications.

BR,
-Haibin


> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of
> Konstantinos Pentikousis
> Sent: Saturday, August 18, 2012 12:43 AM
> To: Rahman, Akbar; [e-mail]
> Subject: [decade] Review of draft-ietf-decade-reqs-08
> 
> 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
>