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