[decade] Object naming in -req and -arch

"Zhang Peng" <pzhang.thu@gmail.com> Tue, 03 July 2012 04:34 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 671D511E811D for <decade@ietfa.amsl.com>; Mon, 2 Jul 2012 21:34:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.845
X-Spam-Level:
X-Spam-Status: No, score=-1.845 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, 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 yc6bXZO8WoME for <decade@ietfa.amsl.com>; Mon, 2 Jul 2012 21:33:59 -0700 (PDT)
Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7C6A711E80EC for <DECADE@ietf.org>; Mon, 2 Jul 2012 21:33:59 -0700 (PDT)
Received: by qcac10 with SMTP id c10so2616629qca.31 for <DECADE@ietf.org>; Mon, 02 Jul 2012 21:34:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:reply-to:subject:x-priority:x-guid:x-mailer :mime-version:message-id:content-type; bh=xFezk3n5cEkJP/Oe+9Z+lW4efFv0jiQkU4W7i59gsxA=; b=rPo3nmk50APZPFcwBumM8/adjwELglUNb+0W6Nh20gLncHceZwgxlELqlxt8nIT8Nr qPGbSQiutH1vOevhDnksZ09m2YH9lI6fIEoKAd6oR1BMhQO7jVLTbDnXmaz6J0TjCTyQ 5RP1xeIpjztesTyr+Wv9Dg0Lc7FVBWm7096P3Mxy3lO3ckrtX8Yww8qGLdhUX9G9Qo0F QualAzwgyG9hDE4IqRrnPMbqpB8N6c83DSDs0hfvJ2WM4nNcBKQcKD5m0RslRaXhEddx 1mzWrrEQafi3F+yWYuMkJGBY02uW6K7fTyJJ7kxvUcb7rbH7rJvjRcxMY+gWjAtlTj51 beJw==
Received: by 10.224.175.8 with SMTP id v8mr16537379qaz.47.1341290046051; Mon, 02 Jul 2012 21:34:06 -0700 (PDT)
Received: from pzhang-PC (dhcp-130-132-249-182.central.yale.edu. [130.132.249.182]) by mx.google.com with ESMTPS id u20sm306689qao.16.2012.07.02.21.34.04 (version=SSLv3 cipher=OTHER); Mon, 02 Jul 2012 21:34:05 -0700 (PDT)
Date: Tue, 03 Jul 2012 00:34:02 -0500
From: Zhang Peng <pzhang.thu@gmail.com>
To: "DECADE@ietf.org" <DECADE@ietf.org>
X-Priority: 3
X-GUID: 2FB1883D-F73F-4DA5-868C-C6154AFEE9D3
X-Mailer: Foxmail 7.0.1.81[cn]
Mime-Version: 1.0
Message-ID: <20120703003402663560214@gmail.com>
Content-Type: multipart/alternative; boundary="----=_001_NextPart873856303855_=----"
Subject: [decade] Object naming in -req and -arch
X-BeenThere: decade@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: "pzhang.thu" <pzhang.thu@gmail.com>
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: Tue, 03 Jul 2012 04:34:00 -0000

Dear DECADE participants,

As pointed out by Richard in previous discussions, both the -req and -arch documents has some paragraphs describing content naming, and they need better organization: some generic requirements should be in -req, while some more specific ones should be in -arch. Here are some suggestions about how to split the content on naming in these two documents. 

The rationale for the following split is that I recognize there are two generic requirements, that is, uniqueness, and binding validation. They should be placed in the -req. In -arch, we should present the specific requirements to enable uniqueness, and binding validation, respectively. There are also some more requirements on how to improve the responsiveness of the system, i.e., the support of early name generation. See below for details (references to the original documents are given after each specific requirements):

Generic requirements (to be put in -req)

1. It SHOULD ensure that uniqueness of object names. 
2. It SHOULD support the validation of name-object binding.
3. It SHOULD support the operation of DECADE-compatible servers under diverse administrative domains with no coordination. (not sure about what operations are meant here)

Specific requirements (to be put in -arch)

Requirements to enable uniqueness: 
1. It MAY enable applications to construct unique names by themselves with a high probability (ref: last sentence, pp. 11, -arch). If this is the case, it SHOULD indicate conflicts when duplicate names are constructed (ref: first para, 4.5.1, -req).
2. It MAY support content-dependent hash-based schemes (for general immutable objects), and content-independent enumeration-based schemes (for live streaming) 
(ref: 2nd para, pp. 12, -arch)

Requirements to enable name-object binding validation:
3. Different name-object binding validation mechanisms MAY be supported, and an application can decide which mechanism to use. (ref: 2nd para, 4.4, -arch)
4. Names MAY be self-describing so that a receiving entity (Content Consumer) knows which mechanism is used (ref: 1st para, pp. 12, -arch)
5. It SHOULD provide the following name elements: (1) A "type" field, (2) Cryptographic data, (3) Application or publisher information. (ref: pp. 12, -arch)

More requirements about performance:
6. It SHOULD support the scenarios where a client needs to know the name of a data object before it is completely stored at the server. (This is to let clients advertise the object before having fully uploaded it) (ref: second last para, pp. 12, -arch)
7. It SHOULD support the scenarios where a client need to know the name of a data object before it is locally created. (This is to support live streaming) (ref: last para, pp. 12, -arch)

Any comments are welcome, thanks.

Peng.