Re: [icnrg] Options for FLIC NameConstructor

"David R. Oran" <daveoran@orandom.net> Thu, 03 September 2020 14:27 UTC

Return-Path: <daveoran@orandom.net>
X-Original-To: icnrg@ietfa.amsl.com
Delivered-To: icnrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF8783A0D5C for <icnrg@ietfa.amsl.com>; Thu, 3 Sep 2020 07:27:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wjCNffDX-R7f for <icnrg@ietfa.amsl.com>; Thu, 3 Sep 2020 07:27:29 -0700 (PDT)
Received: from spark.crystalorb.net (spark.crystalorb.net [IPv6:2607:fca8:1530::c]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26FB83A0D52 for <icnrg@irtf.org>; Thu, 3 Sep 2020 07:27:29 -0700 (PDT)
Received: from [192.168.15.183] ([IPv6:2601:184:407f:80ce:d063:2511:be29:8f9e]) (authenticated bits=0) by spark.crystalorb.net (8.14.4/8.14.4/Debian-4+deb7u1) with ESMTP id 083ERPJB032758 (version=TLSv1/SSLv3 cipher=AES256-GCM-SHA384 bits=256 verify=NO); Thu, 3 Sep 2020 07:27:27 -0700
From: "David R. Oran" <daveoran@orandom.net>
To: "Marc Mosko" <mmosko@parc.com>
Cc: icnrg@irtf.org
Date: Thu, 03 Sep 2020 10:27:19 -0400
X-Mailer: MailMate (1.13.2r5712)
Message-ID: <FC88291B-D528-445A-95A5-A7002ABEA60C@orandom.net>
In-Reply-To: <D600CAC9-5496-46DF-8EFE-7600F5A805F2@parc.com>
References: <D600CAC9-5496-46DF-8EFE-7600F5A805F2@parc.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_MailMate_E5CC56B0-D2A4-4455-9881-0866DE773FB4_="
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/icnrg/C8ZcM4dPVKe7_qyMV9sM4Ru2bAg>
Subject: Re: [icnrg] Options for FLIC NameConstructor
X-BeenThere: icnrg@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Information-Centric Networking research group discussion list <icnrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/icnrg>, <mailto:icnrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/icnrg/>
List-Post: <mailto:icnrg@irtf.org>
List-Help: <mailto:icnrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/icnrg>, <mailto:icnrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Thu, 03 Sep 2020 14:27:31 -0000

This seems eminently reasonable.
Couple of things embedded.

On 2 Sep 2020, at 18:33, Marc Mosko wrote:

> All,
>
> Here are some options on refactored name constructors for FLIC 
> manifests.  We could allow only a single NameConstructor in a Manifest 
> (in which case both data and manifest objects would be in the same 
> namespace), or we could allow one NameConstructor per hash group (in 
> which case manifest and data could be in separate namespaces).
>
Let me check my understanding here. If we adopt the file system analogy, 
we’d lack “softlink” capability if we forced manifests to be in 
the same namespace as data? In which case I’d strongly advocate for 
allowing a NameConstructor per hash group.

> I’ve represented TLV structures more like nested procedures, 
> hopefully this is easily understandable.
>
> NameConstructor(type = TYPE_0, length = …) {
>                 # Whatever name was used in the Interest for this 
> Manifest,
> # use that name for the next Interest plus the hash restriction
>
> Optional RoutingHints(type = TYPE_9, length = …) {
>                 # list of routing hints, could use existing NDN type #
> }
>
I wonder if routing hints belong in a Manifest as opposed in some other 
machinery. Would be good to discuss the design implications a bit. It 
seems routing hints might want to change way more frequently than the 
structure and naming of data. Also, there may be some security questions 
raised by this, as one would think that routing hints would want to be 
signed by *both* the producer *and* the network operator, just like 
other routing information.

> Optional ProtocolFlags(type = TYPE_8, length = …) {
>                 # e.g. NDN must be fresh, Interest lifetime hints, 
> etc.
> }
> }
>
These make sense to me. Good inclusion from my point of view.

> NameConstructor(type = TYPE_1, length = …) {
>                 # Use any of these names in the Interest plus the hash 
> restriction
>                 UnorderedList(type = 0, length = …) {
>                                 # W could be the existing TLV type for 
> a name
>                                 Name(type = W, length = …) { … }
>                                 …
>                                 Name(type = W, length = …) { … }
>                 }
>
> Optional RoutingHints(type = TYPE_9, length = …) {
>                 # list of routing hints, could use existing NDN type #
> }
> Optional ProtocolFlags(type = TYPE_8, length = …) {
>                 # e.g. NDN must be fresh, Interest lifetime hints, 
> etc.
> }
> }
>
…as above…

> NameConstructor (type = TYPE_2, length = …) {
>                 # Use the name of this Manifest plus a hash 
> restriction
>                 # (does not apply to nameless objects)
>
> Optional RoutingHints(type = TYPE_9, length = …) {
>                 # list of routing hints, could use existing NDN type #
> }
> Optional ProtocolFlags(type = TYPE_8, length = …) {
>                 # e.g. NDN must be fresh, Interest lifetime hints, 
> etc.
> }
> }
>
…as above…

> NameConstructor (type = TYPE_3, length = …) {
>                 # Use any of these names, append the segment number 
> and
>                 # use the hash restriction.  The segment number is 
> computed sequentially
>                 # for each hash group number.  If you allow 
> NameConstructors per HashGroup, then
>                 # the manifest tree has its own segment # counter and 
> the Data tree has its
>                 # own segment # counter.  In this case, the 
> UnorderedList is likely of length 1.
>                 UnorderedList(type = 0, length = …) {
>                                 Name(type = W, length = …) { … }
>                                 …
>                                 Name(type = W, length = …) { … }
>                 }
>
> Optional RoutingHints(type = TYPE_9, length = …) {
>                 # list of routing hints, could use existing NDN type #
> }
> Optional ProtocolFlags(type = TYPE_8, length = …) {
>                 # e.g. NDN must be fresh, Interest lifetime hints, 
> etc.
> }
> }
…as above…

>
> Marc

> _______________________________________________
> icnrg mailing list
> icnrg@irtf.org
> https://www.irtf.org/mailman/listinfo/icnrg

DaveO