[icnrg] Comments on FLIC-03

Ken Calvert <calvert@netlab.uky.edu> Fri, 01 April 2022 21:01 UTC

Return-Path: <calvert@netlab.uky.edu>
X-Original-To: icnrg@ietfa.amsl.com
Delivered-To: icnrg@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 7A3143A08BE for <icnrg@ietfa.amsl.com>; Fri, 1 Apr 2022 14:01:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.008
X-Spam-Status: No, score=-2.008 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=netlab.uky.edu
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id lphWBDf_Bgen for <icnrg@ietfa.amsl.com>; Fri, 1 Apr 2022 14:00:55 -0700 (PDT)
Received: from mail.netlab.uky.edu (mail.netlab.uky.edu []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E563C3A0937 for <icnrg@irtf.org>; Fri, 1 Apr 2022 14:00:47 -0700 (PDT)
Received: from smtpclient.apple (calvert1.netlab.uky.edu []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.netlab.uky.edu (Postfix) with ESMTPSA id 15BC01813D for <icnrg@irtf.org>; Fri, 1 Apr 2022 17:00:45 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netlab.uky.edu; s=default; t=1648846845; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=5IR06mgk7OuzNr3H8F9vyLbxvwTko8mukF7d856GVJY=; b=XnaUVr0GvJeu7AYbXBxTvmGd5sjwXNawSzUYOQZdrmZXxMlC+tJjjLIoTxOAXU+QK7UBX3 zO6FLJ8RNt6u/JHZOa4RRnqIoe2xp1B8a6l4nus1aLnQon5ZGS/jhdcLrpg/Z82K8NvbLV So08yC6p0lR1+NXeiHDPn9aFnCVTVULecG8YEl/jh1G8dXcTQMrtZ+55J4Es3km1YveMvH GEGZBh0lK/Ppd5F81oASmvrMNAAii4zgi0cfc58NL1t5M47LM3PAQq8Rvxn20rmgIP/+l/ EcgXSXHY8PrNC2sd1m02IpoYJQNBDwRRcOfjEgraLVtSPWTkHtsfwXtyH66S5g==
From: Ken Calvert <calvert@netlab.uky.edu>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.\))
Message-Id: <FC8AF078-45E4-47FE-96F8-3F5FB40EFFE9@netlab.uky.edu>
Date: Fri, 01 Apr 2022 17:00:44 -0400
To: icnrg@irtf.org
X-Mailer: Apple Mail (2.3654.
ARC-Authentication-Results: i=1; mail.netlab.uky.edu; auth=pass smtp.auth=calvert@netlab.uky.edu smtp.mailfrom=calvert@netlab.uky.edu
ARC-Seal: i=1; s=default; d=netlab.uky.edu; t=1648846845; a=rsa-sha256; cv=none; b=DmgK101MJUJZQlOliZZA1uDAfCyKThbg99kBCf/q7qnGOb7tzeOCsC2MoWEALlsf04kBbs kKPe+Mpnv0HCcYgzFNJcuMwL7/OfkQ406N4pgNcI1qu89Hr+Vsbwd3oFvKGgfqTp1OOCbP iRlO2mNIeWhpF/dgPpXBVy/F2gQkNShnqOrW7zLZO+K7hPSbAvNYgXunnLGiqkAqGjFO0R iACP4rm9T0zD/m7+UimcGWLEQmmkogVAYPXp5/48/ZcWf52CRyUccxt2gAWDl8uCnKxzav Rz8zKfiIRRvysQSi0Pf/Wu50t3RMGEJOV9z8DzkATwLoRKGYLcahOZnCmuF2Zw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=netlab.uky.edu; s=default; t=1648846845; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=5IR06mgk7OuzNr3H8F9vyLbxvwTko8mukF7d856GVJY=; b=JMzdw4QyVlhucteWIjKNpXFqfZkuaIcOrQy2LJkKjZmCGCH9aQeWqIMF62BavDiucXzjYD tFO8PCRqzvfDK4QotZUhH6MURpViN/1j8niGgvc5uRoot2FXTRlsz9lJAzmdAQ6XAZAJI3 jwMxXnmqBHkE8YLYRPlaCMguPVNWvglx3FD426mBhOR5z8eifscwGVqd12NfqRULa9uXfM tFoGNjT1SivjCsz8KNHIu6ay+gcjtgdObaaVKe3tvmlyY6KV6zcEYRhVRxce1y9hI9KfoC a6zWfhMHbQgRqCNpsQ/vzkf/8+NYdFaHH+PXrFEhkkzR+M1JX9A8RQ0Ul6D+AA==
Archived-At: <https://mailarchive.ietf.org/arch/msg/icnrg/XzDMBq2Zj9sv-BWwbNtoI4I1rXA>
Subject: [icnrg] Comments on FLIC-03
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: Fri, 01 Apr 2022 21:01:05 -0000

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.