Re: [icnrg] Comments on FLIC-03

[Dirk Kutscher <[e-mail]>]

Thanks a lot for the detailed comments, Ken!

Best regards,
Dirk


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 3.9.1.2 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 3.9.1.3 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
> [e-mail]
> https://www.irtf.org/mailman/listinfo/icnrg