Hi,


The DECADE Architecture authors were contacted off list by Kostas who
provided the following relevant and useful comments on the
draft-ietf-decade-arch-07.  We intend to address these comments in the
next revision of the architecture I-D after the WGLC ends.  

1) Figure 1: 
This figure and the accompanying text (as-is right now) leaves quite
some room for interpretation. For example,  two distinct
"DECADE-compatible" systems deployed by two different operators may have
DRP1 vs. DPR2, in addition to having multiple SDTxyz's. Is this what you
have in mind?


2) Section 4.2, Referring to the word "multipath":  
I think you mean multi-source here? Multipath is mostly related with two
(multihomed) end nodes and routing in the network rather than one node
getting bits and pieces of a data object from different sources (as in
P2P). You can still have multipath and single-source.


3) Section 4.2, third paragraph, first sentence:
As per the sec. 2.8, a "data object is a string of raw bytes".
Therefore, in this sentence we need s/SHOULD/MUST.


4) Section 4.2, third paragraph, second sentence:
This may introduce the issue of MDO discovery (max data object), when
one connects to different DECADE Servers, perhaps along the lines of MTU
discovery. Content resegmentation is not covered in this section, esp.
since a DECADE server may store/maintain DOs from completely different
apps.


5) Section 4.2, last paragraph:
The introduction of the "block" may be redundant here. A block is,
similarly to a DO, "a string of raw bytes", isn't it? If not, we need a
formal definition for it. Of course, the key aspect here is what can you
name and locate in a DECADE Server, and my reading of the ID so far is
that you have settled on the use of the DO, irrespective of the
application semantics. The repeated use of "block" here and there simply
confuses the uninitiated reader.


6) Section 4.4, 2nd to last paragraph:
I think the optimization described in this paragraph is not particularly
suited for the Architecture document. And it opens up all kinds of
questions.  E.G. what if the host advertizing an object crashes before
it uploads the object? What if the host changes its mind during the
upload? Since we're talking about immutable objects, shouldn't we wait
until an object is "committed". In the end, this optimization could be
counter-productive in these cases. Let alone the fact that the scenarios
for which DECADE is envisaged (and motivated from I would add) tend to
have asymmetric capacities in down/uplink, perhaps of a ratio of 10:1.
Thus, downloading is not typically the performance bottleneck. Perhaps I
am wrong in thinking of this as a premature optimization though. Can you
provide examples from exisiting apps that follow this proposal (and how
do they handle error cases)? 

Moreover, using SHOULD for such a optimization may not be a good idea in
the general case.


7) Figure 3:
This figure implies that multiple applications will need to implement
their own DECADE client, which cannot be shared at run time with other
apps. Of course one could see this as including/linking to a library,
but perhaps a more flexible implementation could also be thought of,
based, for example, on a DECADE "platform", shared by many apps at run
time.


8) Section 6.1.2, second to last paragraph:
This proposed optimization need not be part of the "architecture"


9) Section 6.1.3:
Wouldn't it be better to skip this section altogether and consider an ID
on management aspects instead? For example, why not simply define an MIB
for DECADE and use existing methods to obtain this status info? Why add
more complexity in DRP implementations?


10) Section 10.2:
http://dx.doi.org/10.1145/1544012.1544078 should also be added here, as
it motivates well the domain considered in this architecture, including
the DO.


11) Various editorial and grammatical fixes (which were provided to the
authors off line).


Many thanks to Kostas for providing these excellent comments.


Akbar


-----Original Message-----
From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.org] On Behalf
Of Songhaibin
Sent: Wednesday, June 20, 2012 10:06 PM
To: decade@ietf.org
Subject: [decade] Working Group Last Call: draft-ietf-decade-arch-07

Dear folks,

After the first round of the last call, the architecture document has
many changes to resolve comments from reviewers as well as area director
and experts from other areas. Thanks to the reviewers and the authors.

So Rich and I now start another round of WGLC on
draft-ietf-decade-arch-07, ending Friday, July 6th. Please review the
document and reply with your comments.

Thanks,

-Haibin and Rich (co-chairs)