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

"Rahman, Akbar" <Akbar.Rahman@InterDigital.com> Thu, 30 August 2012 20:26 UTC

Return-Path: <Akbar.Rahman@InterDigital.com>
X-Original-To: decade@ietfa.amsl.com
Delivered-To: decade@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F78721F8585 for <decade@ietfa.amsl.com>; Thu, 30 Aug 2012 13:26:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.815
X-Spam-Level:
X-Spam-Status: No, score=-0.815 tagged_above=-999 required=5 tests=[AWL=-1.416, BAYES_50=0.001, J_CHICKENPOX_45=0.6]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZAO9SHUq5bn0 for <decade@ietfa.amsl.com>; Thu, 30 Aug 2012 13:26:48 -0700 (PDT)
Received: from idcout.InterDigital.com (smtp-out1.interdigital.com [64.208.228.135]) by ietfa.amsl.com (Postfix) with ESMTP id E9D7B21F857D for <decade@ietf.org>; Thu, 30 Aug 2012 13:26:47 -0700 (PDT)
Received: from SAM.InterDigital.com ([10.30.2.11]) by idcout.InterDigital.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 30 Aug 2012 16:26:46 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: base64
Date: Thu, 30 Aug 2012 16:26:45 -0400
Message-ID: <D60519DB022FFA48974A25955FFEC08C04A787C8@SAM.InterDigital.com>
In-Reply-To: <8D38716F0C1A444BA0CD7E96454366C23A4CED4A@szxeml545-mbx.china.huawei.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: Review of draft-ietf-decade-arch-09
Thread-Index: AQHNek8z8EPY51qPJkSQQkFEGaFsWpdtyAGAgAUHthA=
References: <20120813210341.19554.81722.idtracker@ietfa.amsl.com> <8D38716F0C1A444BA0CD7E96454366C23A4CED4A@szxeml545-mbx.china.huawei.com>
From: "Rahman, Akbar" <Akbar.Rahman@InterDigital.com>
To: "Konstantinos Pentikousis" <k.pentikousis@huawei.com>
X-OriginalArrivalTime: 30 Aug 2012 20:26:46.0972 (UTC) FILETIME=[C71F97C0:01CD86ED]
Cc: ralimi@google.com, decade@ietf.org
Subject: Re: [decade] Review of draft-ietf-decade-arch-09
X-BeenThere: decade@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" <decade.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/decade>, <mailto:decade-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/decade>
List-Post: <mailto:decade@ietf.org>
List-Help: <mailto:decade-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/decade>, <mailto:decade-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 30 Aug 2012 20:26:49 -0000

Hi Kostas,


Thank you very much for the thorough re-review.  Sorry that I have been a bit slow in responding lately because of the summer holidays.  I have embedded some initial RESPONSES below to your first section on "Current inconsistencies between -reqs and -arch".  I will keep reading your "other comments and nits" and get back to you on those later.


Sincerely,


Akbar

-----Original Message-----
From: Konstantinos Pentikousis [mailto:k.pentikousis@huawei.com] 
Sent: Monday, August 27, 2012 10:29 AM
To: ralimi@google.com; Rahman, Akbar; decade@ietf.org
Subject: Review of draft-ietf-decade-arch-09

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.


(1) [AKBAR] OKAY.  THEY SHOULD BOTH BE "MUST" THEN TO BE CONSISTENT.


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

(2) [AKBAR]  OKAY, THEY SHOULD BOTH BE "MUST" THEN TO BE CONSISTENT.  BUT, I THINK IT IS OKAY THAT THERE IS NO REFERENCE TO RFC 4288 AND ACCESS STATS IN REQUIREMENTS, AS THE SPECIFICATION OF THESE CAN BE VIEWED AS A NATURAL 'DESIGN' STEP WHICH IS APPROPRIATE FOR THE ARCHITECTURE I-D.  DO YOU AGREE?


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

(3) [AKBAR] SOMEHOW YOU LOST ME HERE WITH THE DIFFERENT SECTION REFERENCES.  CAN YOU PLEASE RE-WORD YOUR COMMENT?


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

(4) [AKBAR]  AS ONE OF THE AUTHORS OF THE ARCHITECTURE I-D, I  HAD AGREED WITH YOUR ORIGINAL SUGGESTION AND THAT IS WHY THE ARCHITECTURE DOCUMENT WAS SIMPLIFIED WRT TO ERROR HANDLING.  I AM NOT AN AUTHOR ON THE REQUIREMENTS I-D AND SO CANNOT SPEAK FOR THEM.  HOWEVER, I DO SEE THAT A CASE COULD BE MADE THAT THESE ERROR CASES BE EXPLICITLY IDENTIFIED IN THE REQUIREMENTS I-D BECAUSE (I IMAGINE) THAT SOME PREVIOUS RESEARCH/THINKING HAS SHOWN THEM TO BE IMPORTANT ENOUGH TO BE LISTED AS EXPLICIT REQUIREMENTS SO THAT WHOEVER SPECIFIES THE PROTOCOL DOES NOT FORGET ABOUT THEM.  THIS AT LEAST HAS BEEN MY PERSONAL EXPERIENCE.  BUT I WILL LET ONE OF THE REQUIREMENTS I-D AUTHORS GIVE THE FINAL WORD ON THIS.


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.

(5) [AKBAR] AS AN EDITORIAL POINT, I UNDESTAND THAT YOU POINT OUT THAT THE REFERENCE BACK TO THE REQS I-D FROM SECTION 5.5 AND 7.1 ARE REDUNDANT (/TRIVIAL/USELESS).  I AGREE. 

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. 

(6) [AKBAR] I AGREE AS PER (5) ABOVE AND WILL DO A SCRUB OF THE ARCHITECTURE I-D TO CLEAN THEM UP.


(7) [AKBAR] FYI - WE PLAN TO IMPLEMENT YOUR COMMENTS ABOVE AS PART OF ANY UPDATES TO RESOLVE IESG COMMENT.  I  HOPE THAT YOU ARE AMENABLE TO THIS!




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