[decade] Review of draft-ietf-decade-arch-09

[Konstantinos Pentikousis <[e-mail]>]

Dear Richard, Akbar, All,

I've gone through -arch-09 and I would like to commend the authors, as this version is significantly improved from -07. However, I find that there is still room for improvement and perhaps a bit more attention is needed on some of the subtle aspects. I also found a few inconsistencies between -reqs and this draft, which I list below.

Current inconsistencies between -reqs and -arch
-----------------------------------------------
With respect to discovery mechanisms, there is a slight divergence between the two documents:
  -reqs-08/Sec. 6.9: A mechanism for a Provider to discover and connect to its assigned server MUST be supported.
  -arch-09/Sec 5.5: A DECADE-compatible system SHOULD include a discovery mechanism through which clients locate an appropriate server.

Similarly, -reqs/Sec. 5.4 requires (MUST) the following locally-scoped attributes: TTL, creation timestamp, object size and type. But, -arch/Sec. 6.1.4 recommends (SHOULD): expiration time, object size and type (here explicitly as per RFC 4288, while no such mention is found in -reqs), and "access statistics".

In Sec. 6.1.3.1 the ID mentions "List of associated data objects (with properties)". I guess you need to s/(with properties)/and their attributes/ to keep it in sync with the -reqs ID. That is, you point to -reqs/Sec. 5.4 and -arch/Sec. 6.1.4, not -reqs/Sec. 5.5 ;)

-reqs describes a set of requirements on error handling (Sec. 9 mainly, plus tidbits here and there in other sections), while -arch mentions (Sec. 6.2.2) that "Specifics regarding error handling, [...] are deferred to eventual protocol specification." I think this latter approach is better. I expressed this opinion on -reqs/Sec. 9 in my review of that document a couple of weeks ago.

Wrt to redirection of transport:
  -reqs-08/Sec. 7.7: A DECADE-compatible server SHOULD be able to redirect requests to another DECADE-compatible server.
  -arch-09/Sec 7.1: SDT therefore MUST provide a redirection mechanism as described as a requirement in [I-D.ietf-decade-reqs]. Duh.

As a general comment, there are several places in the draft where "see below/above/Sec. XX" appear. Often, they point to sections that do not provide substantially more details (sigh). But they always make reading cumbersome and they should be minimized. 

Other comments and nits, listed by section, follow.

Section 4
---------
Nit:
s/resources Section 6.1.1/resources *OR*
s/resources Section 6.1.1/resources (see Section 6.1.1)


Section 5
---------
s/the document details/this document details

There is something missing in Section 5.3.1, which is effectively empty: "Details of the naming scheme are discussed in Section 5.3." Well, we are in Sec. 5.3 and the naming scheme is not actually _detailed_...

In addition, in sec. 5.3.* there are a couple of references to sec. 5.1.1, which is now "Data Assembly". I have the vague impression that the reference to 5.1.1 is no longer valid.

Sec. 5.3.3 does not provide an example for the case where the DO needs to be fragmented to accommodate server maximum object size restrictions. In addition, since -arch leaves to particular protocols to set the restrictions on min and max sizes (and I agree to this), it is possible that two different implementations may have different container sizes. How does this affect naming as described in 5.3? 

s/A token-based authorization scheme is used/A token-based authorization scheme can be used

The sentence "[I-D.ietf-decade-reqs] details specific requirements of the discovery mechanism;" in Sec. 5.5 is not really reflecting the extent that discovery is covered in -reqs-08. See also the inconsistency mentioned at the beginning of this review.


Section 6
---------
Nits:

s/the DRP and the SDT protocol/DRP and SDT/

s/Provider and trusted by the client/Provider and trusted by the client and the server

Section 6.1.1 is a bit unclear. Since this is part of the DRP description, I would imagine that this refers to a (single) client/app managing its own (account) resources on the DECADE server. But, as it's written now, it can also refer to the total resources on a server (to be shared between all clients). It's best to remove this ambiguity from the text.

Section 6 effectively prescribes a token-based authentication scheme for DECADE. This goes beyond the examples presented in Sec. 3.2 & 5.4 and is an important design choice that should be explicitly included in the abstract of the doc as well as early on in the introduction etc. It's also worth noting that the word "token" appears once in -reqs-08 (Sec. 8.3), and about 60 times in -arch-09.

A point that is not covered currently is how does token-based AAA work with partial/chunk downloads. Once DECADE is widely deployed, a client may wish to obtain different DOs/chunks/frames/what-have-you from different peers, thus their corresponding servers in a DECADE-capable system. What kind of tokens would the content provider distribute in this case of dynamic download request environment? Maybe you could add a few sentences to clarify this aspect as well.

Nits:

s/SHOULD based on/SHOULD be based on

s/and for how/and how

s/a server as seen/a server has seen

s/to other client/to another client

s/cannot be delivered the server/cannot be delivered, the server

s/an corresponding/a corresponding


In Sec. 6.2.1, "The name can be used to access (download) the object later; for example, the client can pass the name as a reference to other client that can then refer to the object." The draft just explained that the whole access model is based on tokens, not names alone. Further, the reference to Sec. 5.3 is not particularly enlightening.

The text in Sec. 6.2.2 implies that all clients (including the one that uploaded the DO) will need the name+token to get access. Over-engineered?

The sentence "Data objects can be self-contained objects [..]" should reiterate the fundamental premise of object immutability in DECADE. Suggestion: "Data objects are immutable and can be self-contained objects [..]"

I am not sure why server-to-server (s2s) communication deserves its own section (Sec. 6.3) or lengthy consideration at the -arch level for that matter. How different is s2s communication? For example, why can't a client C instruct server B to obtain a DO from server A exactly the same way it instructs client D (Sec. 6.2)? The key feature here may be the definition of the proxy function for the DECADE architecture. If so, then the section should be reworked to reflect this. Thoughts?

In the same section, the sentence "Object attributes (see Section 6.1.4) might also be specified in the request to the remote server" is a bit at odds with the fact that said attributes are locally scoped.


Section 7
---------
Overall, I find this section a bit weak and more often than not particularly informal. Small editorial suggestions follow:

s/the effective security of this approach/the effectiveness of this approach

s/that the DRP has/that DRP has

s/and the SDT and DRP/and SDT and DRP

s/faked/forged

s/that is has/that it has

"A DECADE-compatible systems fundamental mechanism [..]" Rework sentence?

s/For those/For these


Section A
---------
Nits: 
s/of a SDT/of SDT/g

s/Immutable data objects might be stored at a server./Immutable data objects are stored at a server.

s/storing in/storing them in


Best regards,

Kostas