Re: [icnrg] Comments on FLIC-03

Dirk Kutscher <> Mon, 04 April 2022 11:45 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EFA283A20FC; Mon, 4 Apr 2022 04:45:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.905
X-Spam-Status: No, score=-1.905 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 6jp1mIZrze7e; Mon, 4 Apr 2022 04:45:36 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 36BC73A20FA; Mon, 4 Apr 2022 04:45:34 -0700 (PDT)
Received: from [] ([]) by (mreue010 []) with ESMTPSA (Nemesis) id 1N95Rn-1o6mGx22zv-0164xI; Mon, 04 Apr 2022 13:45:32 +0200
From: Dirk Kutscher <>
To: Ken Calvert <>
Date: Mon, 04 Apr 2022 13:45:28 +0200
X-Mailer: MailMate (1.14r5852)
Message-ID: <>
In-Reply-To: <>
References: <>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=_MailMate_60813289-F778-4082-9508-3F875347B39E_="; micalg="pgp-sha1"; protocol="application/pgp-signature"
X-Provags-ID: V03:K1:V0EgvslsfQk5KIjZi3j0JJ1vSWyd2BX+AvLtJS0TosnfzW8xcGM WBfnigAZpMXkmiYTA/YjnuWvh9DuOdUgwzAueILP+Mx8A6sBh21iIcbjecucR8pzzbYMbgc ewB82tdvS7y9cfdEQkIM8hBd+EJ7IUZHj1xAan7Z/2b5TnTJ9IwtC6AiYybSGGOB3pR66zK tjXvn5USqjadxS9Y9yNQw==
X-UI-Out-Filterresults: notjunk:1;V03:K0:Jbs7CGmvONU=:iVEqq2e+iqv9kt0tElDRVW bUZzt6cQoclPKxTijMwhKwgqp6mAGLfZQHfa5iuD4Ysjy8YFXvB0sk13nKTX61E7DgRooQqjt pZRSdSvesBfgKJ58ZWyBg+LvTdfh+Qfzz2FQA2QV17dMdXei6CCeKuuOX5KwnjtiQ5amQzP6T Mw3eBZuerWaUa2WT22IMlhXW2ri/y3LU/3XXqQYRZxacslwx1V48TBBCRkQDFeX9Pvz8gTky/ +AFA9MbkVdPAMIVujkxmWFc2uJ6Vib5a/Rq9Ogx05spyAXa37q1D79HYi0g2rWfeSYAix/d6x ndJMRYgaEWATQ8zC92Lq5hDkpCr6vtOpSerGeRwxtnqtfI1RlfuLWya2mvJvNBKRCmNlJH89c nvyjq5NIXM3vNju7kEAqSSN8rkqJL5pJx30GAxQ+NK3XZ5fMIQxt1Iel2tkTGOsFSU5FWokFh C5Kvl/d4UD/PR1L0iadkOqOmcfQbvPwOrLPy+kjQTjVmccup2oP3w5ZbB6/doziy7mAPEK5Mu NcBLX1UYZgi0obmghA0HiPJ3CFNsALvyfIT3fqQKxuJmzLrJyKOa68LuxUUYyp72IoyqbrUtz 93jwB7C8xH8grxGXQYD9fj75GI9sw5hPB4z3CVYslGts/V26g0OGRWTzGn9VKlxOcKTIuGkL8 B7THLJtIxjiRrLbDwayddzA6XpROHXWCUuqGCjh4x4BHH/tHXfaqiWs7v4KQJrBo0+9g=
Archived-At: <>
Subject: Re: [icnrg] Comments on FLIC-03
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Information-Centric Networking research group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 04 Apr 2022 11:45:41 -0000

Thanks a lot for the detailed comments, Ken!

Best regards,

On 1 Apr 2022, at 23:00, Ken Calvert wrote:

> Thanks for this update; sorry it took so long to go through it.  I think FLIC is quite important, and I read this as a potential implementor.  This version represents progress, though I don't think it's quite at the point yet where I could implement it.  (BTW, do implementations exist?)
> High-level comments============
> 0. There are several places where the document says essentially "there are no constraints, but the convention is to do it this way..."
> No motivation or justification is mentioned for the convention.  Since an implementation must be prepared for any allowed approach, a convention should offer some benefit, e.g., in a certain class of applications.  Such benefit should be spelled out wherever a convention is stated.
> (Example: "Internal Manifest:  some or all pointers are indirect.  The order and number of each [direct/indirect pointers(?)] is up to the manifest builder. By convention, all the direct manifests [sic - should be 'pointers'?] come first, then the indirect.")
> 1. One of the important motivations for using manifests is covering lots of data with a single signature.  Do any of the name construction approaches have implication for trusting the Root manifest signer vs. signers of other internal manifests?  (See question below about top manifests.)
> Editorial comments=============
> Section 3.1 Terminology - suggest adding "Hash group" to the defined terms, or a forward pointer to the glossary in 3.6.
> Top manifest - I confess I still don't understand the motivation for the "Root+top manifests" approach.  What does the additional level of indirection buy you?
> Manifest Waste - This term isn't used anywhere in the document as far as I can tell (the word "waste" appears nowhere else).  Suggest removing it, as it requires assumptions about MTUs, presence/absence of metadata, etc.
> Section 3.2 Locators
> - This is a nit, but "node/Node" are used with completely different meanings in each of the two paragraphs of this section.  One is capitalized, but perhaps the first could be replaced with "forwarder" or something.
> - In the second paragraph: "A manifest Node may define one or more Locator prefixes that can be used in the construction of Interests from pointers in the manifest".  Is this referring to Name Constructors?  If so, suggest saying so and including a forward pointer to the next section.  If not, how is what is described here different from a Name Constructor?
> Secion 3.3 Name Constructor
> - First paragraph on p.9 "The advantage of ... the default name constructor is that any hash groups that use it..." - this is the first occurrence of the term "hash group" in the document, except for Figure 1.  On first reading the figure was enough to get the basic idea, but if I were implementing this a more complete description before the grammar would help.  Maybe add to the glossary in 3.1?
> - I don't understand the difference between Type 0 and Type 1 Name Constructors.
> One says "Use the name from the Interest that retrieved this Manifest", and the other says "Use the Manifest Name". My understanding is that these cannot differ in CCNx. Do I have that wrong?  Or is it that in NDN, with Type 0 the Name in the Interest might be a proper prefix of the Name in the Manifest Object? If that is the only difference, it would help to be explicit here.
> Also, the phrasing "less a hash component ... append the desired hash value" seems both vague ("less") and over-specific ("append").  How about something like "replace the hash component in the [Interest/Manifest] Name (if any) with the hash of the desired object" - if that is the intent?
> - Type 3 Segmented Naming - "The consumer must maintain a 0-based counter for each NCID associated with the *in-order* index of each hash and use that as a segment number".  I found this confusing since 3.7.1 "Traversal" specifies *pre-order* traversal, seemingly for all manifests.  Also Section 3.5 says "annotations may give hints about a desirable traversal order", suggesting that other orders are possible.  Here again is a situation where it's not clear what an application library should do.  Maybe 3.7.1 should say the *default* is pre-order traversal.
> Overall, it would be really helpful to have a concrete example (as in Section 5.7.1) IN THIS SECTION, highlighting the differences in how each approach is used to construct names.
> Section CCNx Single Prefix - first paragraph says "Note that in CCNx, using a SinglePrefix name means the Locators are not used."  The next paragraph says "It has a set of Locators used to fetch the remainder of the manifest".  That's contradictory.  Also, what is "remainder of the manifest"?  Should be "manifest tree"?
> Section CCNx Segmented Prefix - starts out "The Segmented Prefix schema uses a different name in all Content Objects and distinguishes them via the ContentObjectHash."  I interpret "names" here to mean "hierarchical [routable] names", but then why do they need to be distinguished with hashes?  Also, previous comment applies here as well.
> Section 5
> Figure 9, there is a missing right paren that makes the schematic hard to parse. I believe it goes after "(ptr=h2)".
> Figure 10, two errors:
>   (i) "P > offset + P_i.size" should be "P < ..."
>   (ii) "offset += P_i.size" should be in the body of the for loop.  Current indentation indicates it is outside, which is incorrect.
> Ken
> _______________________________________________
> icnrg mailing list