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

From: Konstantinos Pentikousis <[email-masked]>
Date: Mon, 3 Sep 2012 16:42:30 +0000

Hi Akbar,

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

Thank you for your kind words.

<snip>

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

Sure, I guess this goes into the text of [5.3] then.

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

I understand what you have in mind, but it will be a bit strange to put, let me call it, a "forward reference" to a protocol that does not exist. Just my $0.02.

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

Well, I agree that a few terms in sec 2.* have some overlap and perhaps could be simplified a bit, but I tried to have the cheat sheet summary as close as possible to the definitions in Sec 2.* and the -reqs text. For example, in 6.7 (copy and paste):

REQUIREMENT(S): Unless read or write access is granted by a Provider, the default permission MUST be no access.
RATIONALE: This requirement is to protect client privacy by default. 

I guess that means s/client/provider in the rationale part, and the cheat sheet summary becomes "Provider data on a server are by default private [6.7]"

On the other hand, in the sentence "It is the client... [6.8, 6.9]", "client" (as per sec. 2.1) is the right term, not "provider".

Best regards,

Kostas

---

From: Martin Stiemerling <[email-masked]>
Date: Wed, 5 Sep 2012 17:17:22 +0200

Hi there,

I am reading the -08 version of the requirements draft and do wonder if 
and how the apps area review comments of Dave Crocker have been addressed.

Here is the link to his review:
http://www.ietf.org/mail-archive/web/apps-discuss/current/msg04704.html

   Martin

On 08/13/2012 09:50 PM, [email-masked] wrote:
>
> 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/
>

-- 
[email-masked]

NEC Laboratories Europe - Network Research Division NEC Europe Limited
Registered Office: NEC House, 1 Victoria Road, London W3 6BL
Registered in England 283

---

From: "Rahman, Akbar" <[email-masked]>
Date: Wed, 5 Sep 2012 11:45:16 -0400

Hi Martin,

Nominally all the comments from Dave Crocker were addressed by the -06 to -08 versions of the Requirements drafts.  Did you notice any specific issues that you felt were not addressed?

/Akbar (as Document Shepherd)

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Martin Stiemerling
Sent: Wednesday, September 05, 2012 11:17 AM
To: [email-masked]
Subject: Re: [decade] I-D Action: draft-ietf-decade-reqs-08.txt

Hi there,

   Martin

---

From: Martin Stiemerling <[email-masked]>
Date: Fri, 7 Sep 2012 12:17:24 +0200

Akbar,

I cannot link his comments and the changes. It would be good to get this 
documented by email, e.g., a change list.

He had a number of comments and would be really good to answer to him, 
to show what has happened with his comments.

Thanks,

  Martin

---

From: "Rahman, Akbar" <[email-masked]>
Date: Fri, 7 Sep 2012 11:40:53 -0400

Hi Martin,

Okay.  I have suggested to the authors to make this change list as part of their plan to address the outstanding comments on the Requirements document.

-----Original Message-----
From: Martin Stiemerling [mailto:[email-masked]] 
Sent: Friday, September 07, 2012 6:17 AM
To: Rahman, Akbar
Cc: [email-masked]
Subject: Re: [decade] I-D Action: draft-ietf-decade-reqs-08.txt

Akbar,

Thanks,

  Martin

---

From: Songhaibin <[email-masked]>
Date: Mon, 10 Sep 2012 08:26:29 +0000

Hi Kostas and Akbar,

Thank you for the good comments and discussion.

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Konstantinos Pentikousis
> Sent: Tuesday, September 04, 2012 12:43 AM
> To: Rahman, Akbar
> Cc: [email-masked]
> Subject: Re: [decade] Review of draft-ietf-decade-reqs-08
> 
> Hi Akbar,
> 
> I understand what you have in mind, but it will be a bit strange to put, let me call
> it, a "forward reference" to a protocol that does not exist. Just my $0.02.

As long as the explanation for DRP exists in the document, I do not think this is a problem.

-Haibin

> Well, I agree that a few terms in sec 2.* have some overlap and perhaps could be
> simplified a bit, but I tried to have the cheat sheet summary as close as possible
> to the definitions in Sec 2.* and the -reqs text. For example, in 6.7 (copy and
> paste):
> 
> I guess that means s/client/provider in the rationale part, and the cheat sheet
> summary becomes "Provider data on a server are by default private [6.7]"
> 
> On the other hand, in the sentence "It is the client... [6.8, 6.9]", "client" (as per
> sec. 2.1) is the right term, not "provider".
> 
> Best regards,
> 
> Kostas