Hi Richard,

Thanks for your effort. Here are some suggestion about the revision of -req documents.

First, regarding Q1, I think there are indeed some overlaps on term definitions in -req and -arch documents. In addition, they are even not consistent. I think we can just put them in the -req document, and give a pointer in -arch document. 
Regarding Q2, I agree that in -arch, there are some paragraphs that also do the job of define requirements, and may better be put in -req. For naming, the reqiin -requirements given in -req are rather simplistic, and we can move the move the detailed requirements to -req. But for "immutable object", I think it is more like a design option for the architecture (so that the design would be much simplified), rather than a system requirements for DECADE to function.  Thus, I suggest we don't move the immutable data objects in -arch to -req, and we can even delete them in -req. Finally, I would say that there is no clear cut for requirement and architecture, since when we specify the requirements, we have some design rationale in mind; and when we design the architecture, we would find more clear requirements for the specific design. It is not easy to fully decouple them.
Regarding Q3, I think the new outline of the -req document seems better, but I think it is better to organize it into three parts: access/authorization, resource control, data storage/transfer, failure handling/gaming prevention. The rationale is that the first part is about how client access the server, the second part corresponds to DRP, the third part corresponds to SDT, and the last two parts are about reliability/security. The following is the outline in my mind. I would like to discuss with you about the organization further. And I would like to help revise the -req document.  Thanks.

Best,

Peng.

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Terminology and Concepts . . . . . . . . . . . . . . . . . . . 6
3. System/Functional Components
4. Requirements Structure . . . . . . . . . . . . . . . . . . . . 7

5. Data Object Requirements
4.5.1. Data Naming . . . . . . . . . . . . . . . . . . . . . .14
Move part of Arch 4.4 to -req
4.2.1. Data Object Size . . . . . . . . . . . . . . . . . 11
4.4.2. System Data Object Attributes . . . . . . . . . . . . .13
4.4.3. Time-to-live for Written Data Objects . . . . . . 13
4.4.4. Application-defined Properties and Metadata . . . . . 13

6. Authentication and Access Requirements
4.7.1. Per-Remote-Client, Per-Data Read Access . . . . . . . 16
4.7.2. Per-User Write Access . . . . . . . . . . . . . . . . 17
4.7.3. Default Access Permissions . . . . . . . . . . . . . . 17
4.7.4. Authorization Checks . . . . . . . . . . . . . . . . . 17
4.7.5. Cryptographic Credentials . . . . . . . . . . . . . . 17
4.7.6. Server Involvement . . . . . . . . . . . . . . . . . . 18
4.7.7. Protocol Reuse . . . . . . . . . . . . . . . . . . . . 18
4.3.1. Read/Write Own Storage . . . . . . . . . . . . . . .. 11
4.3.2. Read/Write by Remote Clients . . . . . . . . . . . . . 11
4.4.5. Offline Access . . . . . . . . . . . . . . . . . . . 14

7. Data Transfer Requirements 
4.1.1.1. NATs and Firewalls TRaversal . . .. . . . . . . . . 8
Connections to Clients . . . . . . . . . . . . . . . . . . . 8
6.1.1. Support for Clients Behind NATs and Firewalls . . . 21
4.3.3. Negotiable Data Transport Protocol . . . . . . . . . . 12
4.1.2.1. Secure Transport . . . . . . . . . . . . . . . . . . 8

8. Resource Control Requirements. . . . . . . . . . . . . . . . . 15
4.6.1. Multiple Applications . . . . . . . . . . . . . . . . 15
4.6.2. Per-Remote-Client, Per-Data Control . . . . . . . . . 15
4.6.3. Resource Control Set . . . . . . . . . . . . . . . . . 16
4.6.4. Server Involvement . . . . . . . . . . . . . . . . . . 16
8. Authorization Requirements

9. Error and Failure Handling Requirements. . . . . . . . . . . . 9
4.1.3.2. Insufficient Resources . . . . . . . . . . . . . . . 9
4.1.3.1. Overload Condition . . . . . . . . . . . . . . . 9
4.1.3.3. Unavailable and Deleted Data . . . . . . . . . . . . 10
4.1.3.4. Insufficient Permissions . . . . . . . . . . . . . . 10
4.1.3.5. Redirection . . . . . . . . . . . . . . . . . . . . 10
4.1.2.2. Gaming Prevention . . . . . . . . . . . . . . . . . .8
4.4.1. Server reliability (Agnostic of reliability) . . . . . 12

10. Server Status Query Requirements . . . . . . . . . . . . . . . 18
5.7. Storage Status . . . . . . . . . . . . . . . . . . . . . 20
....

11. Security Considerations . . . . . . . . . . . . . . . . . . . 21
7.1. Authentication and Authorization . . . . . . . . . . . . 21
7.2. Encrypted Data . . . . . . . . . . . . . . . . . . . . . 22
7.3. Protection against Gaming . . . . . . . . . . . . . . . 22




Zhang Peng

From: Y. Richard Yang
Date: 2012-06-30 06:40
To: DECADE@ietf.org
Subject: [decade] -req and -arch documents
Dear DECADE participants,

Both -req and -arch documents have received extensive, excellent 
reviews. In the process of revising the documents and looking at the two 
documents, we have some questions to seek input from the participants:

Q1. Both -req and -arch define some terms, including DECADE-compatible 
client, DECADE-compatible server, etc. This appears to be redundant. 
Should such terms be defined in -req or -arch? The current thinking is 
-req. Any comments?

Q2. There are multiple paragraphs defining requirements in -arch, e.g., 
Sec. 4.4 on naming. Should these be moved to -req? A more general 
question is on the dependency between -req and -arch. On one hand, it is 
ideal to define -req first without a particular architecture to allow 
competing/alternative architectures satisfying the requirements. On the 
other hand, it appears that the -arch document contains content, in 
particular, systems/function components, that can be helpful to better 
understand the -req document. The current thinking is still to make -req 
independent of -arch, and move some general requirements in -arch to 
-req. Any comments?

Q3: There are some good comments on reorganizing the -req documents. 
Below is a new structure (second level section #'s and page numbers are 
from the current -req so that others can see how we re-organize the 
document). Any comments/feedback before we start the revision will be 
greatly appreciated.

Also, anyone who can help with direct revisions of the -req document 
will be more than welcome!

Thanks.

-- 
Richard

1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  5
2.  Terminology and Concepts . . . . . . . . . . . . . . . . . . .  6
3.  System/Functional Components
4.  Requirements Structure . . . . . . . . . . . . . . . . . . . .  7

5.  Data Object Requirements
     4.5.1.  Data Naming . . . . . . . . . . . . . . . . . . . . . .14
             Move part of Arch 4.4 to -req
     5.1.  --Immutable Data . . . . . . . . . . . . . . . . . . . . 18
     4.4.2.  System Data Object Attributes . . . . . . . . . . . . .13
         4.2.1.  Data Object Size . . . . . . . . . . . . . . . . . 11
         4.4.3.  Time-to-live for Written Data Objects  . . . . . . 13
     4.4.4.  Application-defined Properties and Metadata  . . . . . 13

6.  Access to Server Requirements
     4.3.1.  Read/Write Own Storage  . . . . . . . . . . . . . . .. 11
     4.3.2.  Read/Write by Remote Clients . . . . . . . . . . . . . 11
     4.4.5.  Offline Access  . . . . . . . . . . . . . . . .  . . . 14
     4.1.1.1.  NATs and Firewalls TRaversal . . .. . .  . . . . . .  8
       Connections to Clients . . . . . . . . . . . . . . . . . . .  8
       6.1.1.  Support for Clients Behind NATs and Firewalls  . . . 21
     4.3.3.  Negotiable Data Transport Protocol . . . . . . . . . . 12
     5.2.  Explicit Deletion of Data  . . . . . . . . . . . . . . . 19
     5.3.  Concurrent Write (Multiple writing). . . . . . . . . . . 19
     5.4.  Concurrent Read (Multiple reading) . . . . . . . . . . . 19
     5.5.  Read While Write . . . . . . . .   . . . . . . . . . . . 19
     5.6.  Partial Write (Writing model) . . . . . . . . . . . . . 20
     4.1.2.1.  Secure Transport . . . . . . . . . . . . . . . . . .  8

7.  Resource Control Requirements. . . . . . . . . . . . . . . . . 15
     4.6.1.  Multiple Applications  . . . . . . . . . . . . . . . . 15
     4.6.2.  Per-Remote-Client, Per-Data Control  . . . . . . . . . 15
     4.6.3.  Resource Control Set . . . . . . . . . . . . . . . . . 16
     4.6.4.  Server Involvement . . . . . . . . . . . . . . . . . . 16

8.  Authorization Requirements
     4.7.1.  Per-Remote-Client, Per-Data Read Access  . . . . . . . 16
     4.7.2.  Per-User Write Access  . . . . . . . . . . . . . . . . 17
     4.7.3.  Default Access Permissions . . . . . . . . . . . . . . 17
     4.7.4.  Authorization Checks . . . . . . . . . . . . . . . . . 17
     4.7.5.  Cryptographic Credentials  . . . . . . . . . . . . . . 17
     4.7.6.  Server Involvement . . . . . . . . . . . . . . . . . . 18
     4.7.7.  Protocol Reuse . . . . . . . . . . . . . . . . . . . . 18

9.  Error and Failure Handling Requirements. . . . . . . . . . . .  9
     4.1.3.2.  Insufficient Resources . . . . . . . . . . . . . . .  9
         4.1.3.1.  Overload Condition . . . . . . . . . . . . . . .  9
     4.1.3.3.  Unavailable and Deleted Data . . . . . . . . . . . . 10
     4.1.3.4.  Insufficient Permissions . . . . . . . . . . . . . . 10
     4.1.3.5.  Redirection  . . . . . . . . . . . . . . . . . . . . 10
     4.1.2.2.  Gaming Prevention  . . . . . . . . . . . . . . . . . .8
     4.4.1.  Server reliability (Agnostic of reliability) . . . . . 12

10. Server Status Query Requirements . . . . . . . . . . . . . . . 18
     5.7.  Storage Status . . . . . . . . . . . . . . . . . . . . . 20
     ....

11. Security Considerations  . . . . . . . . . . . . . . . . . . . 21
     7.1.  Authentication and Authorization . . . . . . . . . . . . 21
     7.2.  Encrypted Data . . . . . . . . . . . . . . . . . . . . . 22
     7.3.  Protection against Gaming  . . . . . . . . . . . . . . . 22