Re: [decade] reorganized -req

Zhang Peng <pzhang.thu@gmail.com> Mon, 09 July 2012 17:46 UTC

Return-Path: <pzhang.thu@gmail.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 795F011E81C0 for <decade@ietfa.amsl.com>; Mon, 9 Jul 2012 10:46:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level:
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vPTM6QfowZGl for <decade@ietfa.amsl.com>; Mon, 9 Jul 2012 10:46:04 -0700 (PDT)
Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id AB13E11E81BE for <DECADE@ietf.org>; Mon, 9 Jul 2012 10:46:04 -0700 (PDT)
Received: by qaea16 with SMTP id a16so1754367qae.10 for <DECADE@ietf.org>; Mon, 09 Jul 2012 10:46:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=wNSYj4JV0FaYB4z7RNJ8khDFpxhrm2X358ykb3gNGIo=; b=aBX97/Z4badZWfiTIENoyhWA5NySKh7+QuEtzkNbv0KewDgq6llwSt0a8IdeB6JvXm 52NKdTgjlauPdtwpiBGkHZhcpYsK1Fg/AzzYF/4IKdfyFavDXbzxlaY8bPoUUusoX8Gr 6yBSTxYGodKpNXSaio2aDx3fIkGGK2K8KdccqT5cYaClTGk2ZECCOqm0n8DZcSBSUIjw 37C0D06Mh4y65qhATKIlQWR0OKJ/uK/cccV8lHHTQ1/HB6dC2VvoXB2+36X7doIp673Q jiCPsq5ShX/qbGlNqlJNu+ZCR1p0s+dbm/NJrtx2ZNoTQvi2PAegYFz974HfVdAylO7Z TwCw==
Received: by 10.224.109.196 with SMTP id k4mr73640291qap.92.1341855989706; Mon, 09 Jul 2012 10:46:29 -0700 (PDT)
Received: from dhcp-128-36-159-196.central.yale.edu (dhcp-128-36-159-196.central.yale.edu. [128.36.159.196]) by mx.google.com with ESMTPS id f14sm40876607qak.20.2012.07.09.10.46.28 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 09 Jul 2012 10:46:28 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1278)
Content-Type: text/plain; charset="iso-8859-1"
From: Zhang Peng <pzhang.thu@gmail.com>
In-Reply-To: <4FF867DE.7020609@cs.yale.edu>
Date: Mon, 09 Jul 2012 13:46:27 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <374C8630-A970-4AE1-91DB-EAB9041C0980@gmail.com>
References: <4FF867DE.7020609@cs.yale.edu>
To: "Y. Richard Yang" <yry@cs.yale.edu>
X-Mailer: Apple Mail (2.1278)
Cc: "DECADE@ietf.org" <DECADE@ietf.org>
Subject: Re: [decade] reorganized -req
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: Mon, 09 Jul 2012 17:46:05 -0000

Hi Richard and All,

	Here are some comments on the recently revised version of -req document.

	First, I noticed that the protocol flow including DRP and SDT is included in -req. I wonder if this is a good choice, since it is more like a design rather than a requirement. Could someone explain the rationale? 

	For the naming requirements, I suggest that the "the naming scheme should support that consumer can validate the name-object binding, i.e., can check that the object content is what the name claims to be". The rationale is that consumer now obtains the object from DECADE server, and in turn is uploaded by some content provider that is not trustworthy.
	 
	I suggest that the terminology 2.5 "Provider" should better be "content provider". Otherwise, it may be confused with "DECADE storage provider" of 2.3. Also, 2.9 is referring to "content provider", not "provider". Correspondingly, "consumer" should be "content consumer". But we should also comment that we would use shorter term "provider" and "consumer" if there is no ambiguity.

	Section 7.2 is not so clear to me. The rationale has not stated the reason for this very well. 
	
	In section 8.1, the term "user" is not defined by us. Should we use "client" instead?

	In Section 9, should we also include "overload condition" which appear in section 4.1.3.1 of current version?
	
	Some minor revisions: 
	
		- Section 2.3: "that" should be removed;
		- Section 6.1:  Should be "After a DECADE-compatible client owns an account on a DECADE-compatible server, it should be able to read data from and write data to the server once authorized by the server.", and it should be following section 6.2.
		- Section 6.2: I think it is better to be "Access to an account on a server MUST be granted to a provider based on cryptographic security"
		- Section 6.3 "resoutces" -> "resources"
		- Section 6.9 "disovery" -> "discovery"
		- Section 7.5 "enerate" -> "generate"
		- Section 8.4 "stoarge" -> "storage"
		


	I would like to help revise if you don't have time.

B,

Peng.


On Jul 7, 2012, at 12:46 PM, Y. Richard Yang wrote:

> Dear all,
> 
> We did a substantial reorganization of the -req documents. It is attached to this email. Any early feedback will be greatly appreciated.
> 
> Thanks!
> 
> Richard
> <draft-ietf-decade-reqs-all_v06.txt><draft-ietf-decade-reqs-all_v06.xml>