Subject: [decade] I-D Action: draft-ietf-decade-reqs-08.txt

From: [email-masked]
Date: Mon, 13 Aug 2012 12:50:06 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Decoupled Application Data Enroute Working Group of the IETF.

	Title           : DECADE Requirements
	Author(s)       : Yingjie Gu
                          David A. Bryan
                          Yang Richard Yang
                          Peng Zhang
                          Richard Alimi
	Filename        : draft-ietf-decade-reqs-08.txt
	Pages           : 21
	Date            : 2012-08-13

Abstract:
   The target of the DECoupled Application Data Enroute (DECADE) system
   is to provide an open and standard in-network storage system for
   applications, primarily P2P (peer-to-peer) applications, to store,
   retrieve and manage their data.  This draft enumerates and explains
   requirements, not only for storage and retrieval, but also for data
   management, access control and resource control, that should be
   considered during the design and implementation of a DECADE-
   compatible system.  These are requirements on the entire system; some
   of the requirements may eventually be implemented by an existing
   protocol with/without some extensions (e.g., a protocol used to read
   and write data from the storage system).  The requirements in this
   document are intended to ensure that a DECADE-compatible system
   architecture includes all of the desired functionality for intended
   applications.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-decade-reqs

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-decade-reqs-08

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-decade-reqs-08

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: "Rahman, Akbar" <[email-masked]>
Date: Mon, 13 Aug 2012 16:43:02 -0400

Thanks to the authors for the quick update as it will help progress the document through IESG.

/Akbar (as Document Shepherd)

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Monday, August 13, 2012 3:50 PM
To: [email-masked]
Cc: [email-masked]
Subject: [decade] I-D Action: draft-ietf-decade-reqs-08.txt

Abstract:

---

From: Konstantinos Pentikousis <[email-masked]>
Date: Fri, 17 Aug 2012 16:42:45 +0000

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

---

From: Songhaibin <[email-masked]>
Date: Thu, 23 Aug 2012 08:01:53 +0000

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

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Konstantinos Pentikousis
> Sent: Saturday, August 18, 2012 12:43 AM
> To: Rahman, Akbar; [email-masked]
> Subject: [decade] Review of draft-ietf-decade-reqs-08
> 
> 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
> --------
> 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".
> 
> 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:
> 
> 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.
> 
> 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
> ---------
> 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.
> 
> 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...")
> 
> 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?
> 
> 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?)
> 
> 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
> ---------
> 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
> ----------
> 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).
> 
> 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]
> 
> * 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
>

---

From: Konstantinos Pentikousis <[email-masked]>
Date: Thu, 23 Aug 2012 09:21:03 +0000

Hi Haibin,

<snip>

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

Well, then we need to change the opening sentence in the abstract:

"The target of the DECoupled Application Data Enroute (DECADE) system is to provide an open and standard in-network storage system for applications, primarily P2P (peer-to-peer) applications, to store, retrieve and manage their data."

The term CDA per se does not appear in the abstract.

Best Regards,

Kostas

---

From: Songhaibin <[email-masked]>
Date: Fri, 24 Aug 2012 01:26:24 +0000

That looks good to me.

-Haibin

> From: Konstantinos Pentikousis
> Sent: Thursday, August 23, 2012 5:21 PM
> To: Songhaibin; Rahman, Akbar; [email-masked]
> Subject: RE: Review of draft-ietf-decade-reqs-08
> 
> Hi Haibin,
> 
> <snip>
> 
> "The target of the DECoupled Application Data Enroute (DECADE) system is to
> provide an open and standard in-network storage system for applications,
> primarily P2P (peer-to-peer) applications, to store, retrieve and manage their
> data."
>

---

From: "Rahman, Akbar" <[email-masked]>
Date: Fri, 31 Aug 2012 14:58:18 -0400

Hi Kostas,

Thanks, your comments and analysis are always very thought provoking!

I am providing some initial FEEDBACK below on your very nice summary (as the Document Shepherd and an interested WG member).

------- SNIP ------------------

Requirements Cheat Sheet
------------------------

In a DECADE system, efficient storage and data transfer of small data objects is required [5.3]. 

[AKBAR] AND WE SHOULD ADD THE PHRASE "... AND DATA TRANSFER OF LARGE DATA OBJECTS IS ALSO INHERENTLY SUPPORTED."

The data transport protocol can be negotiated but must be secure [7.1, 7.3]. 

[AKBAR] AND I WOULD ADD TWO MORE POINTS APPLICABLE TO THE NEXT PARAGRAPH:
- ALL CONTROL FUNCTIONS ARE ACCOMPLISHED USING THE DECADE RESOURCE PROTOCOL (DRP)
- ADD "9.2" TO THE LIST OF "fine-grained access control policies"

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]

[AKBAR] IN THE EXPLANATION YOU SWITCH TERMS BETWEEN "PROVIDER" AND "CLIENT".  IT WOULD BE CLEARER I THINK IF YOU STUCK TO JUST "PROVIDER" AND "CONSUMER".

------- SNIP ------------------

Sincerely,

Akbar

-----Original Message-----
From: Konstantinos Pentikousis [mailto:[email-masked]] 
Sent: Friday, August 17, 2012 12:43 PM
To: Rahman, Akbar; [email-masked]
Subject: Review of draft-ietf-decade-reqs-08

Abstract
--------

Section 2
---------

Furthermore:

Section 3
---------

Section 4
---------

Section 5
---------

Section 6
---------

Section 7
---------

Section 8
---------

Section 9
---------

Section 10
----------

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

 

Requirements Cheat Sheet
------------------------

Best Regards,

Kostas