Re: [icnrg] Review of draft-irtf-icnrg-flic-00

[Christopher Wood <[e-mail]>]

Thanks for the feedback, Dave. Please see inline below for my response.

On Fri, Jul 28, 2017 at 8:07 AM, David Oran <[e-mail]> wrote:
> This draft was adopted as an ICNRG working document prior to the Prague
> meetings. The original individual contribution had been hanging around for
> quite some time, and was considered mature enough by the ICNRG participants
> to begin active work on it to progress it towards experimental RFC status.
>
> This is my initial review of the official ICNRG draft. First,I offer some
> general comments with <Chair Hat On>. The bottom line is that this draft
> needs a fair bit of editing work in order to meet IRTF document quality
> expectations. Then I offer some specific technical comments and suggestions
> for improvement as an individual with <Chair Hat Off>.
>
> General Comments <chair hat on>
>
> The technical content of the draft seems mostly solid. It has indeed been
> implemented successfully, although it is not clear if there are multiple
> interoperable implementations yet. However, as a solid specification of a
> protocol/data-structure it leaves a lot to be desired. It is likely only
> completely understandable by the authors and people who have implemented it.
> There needs to be a lot more introductory text to cover the role FLIC plays
> in the overall CCNx design, some material on the use of manifest in both
> CCNx and NDN, and explanatory text motivating the various features.
> Specifically:
>
> The document starts with a figure which is next to impossible to grasp due
> to the lack of explanation. The specification needs a real introduction.
> the design goals section is too terse and needs both more explanation and
> more justification for the choices.

That's fair. We can add some explanatory text before the figure.

> an IRTF document with a security consideration section that says “none”?
> Give me a break.

This was our way of testing the audience. :-)

(But in all seriousness, now that it's adopted, we'll invest more than
4 characters to this section.)

> There’s lots to cover here, including:
>
> hash agility (e.g. what if we have hashes more than 8 bytes)
> when is it appropriate (or not) to encrypt manifests. With what keys? Does
> it make sense to do partial encryption so that caches can use manifests for
> pre-placement and pre-fetching?
> how to do partial re-signing on either replacement or append.
> etc. etc.

Those are all fine things to include, though the second (encryption)
is a bit of a rabbit hole. I'll add some text to address these and
other issues.

>
> the references are not formatted correctly, are out of date, and missing a
> bunch of important ones.

We'll fix this. If you would like specific references included, please
list them here.

> One of the (not clearly stated) design goals is extensibility, yet the
> extensibility mechanism is not clearly laid out. This is extremely important
> in my view as FLIC as it stands is indeed “bare bones” and hence will, to be
> successful, need some rich extensions.

Yep -- we can expand on this too.

>
> Technical Comments <chair hat off>
>
> In design goals, saying you use hash values instead of block numbers, while
> true, isn’t a design goal. In general, a lot of the design goals aren’t
> really design goals. This section needs a fair bit of fleshing out.

Agreed. I'll fix this.

> It isn’t clear what you are referring to when you say “advantages (over
> non-manifest collections).” What exactly do you have in mind? Perhaps it
> would be better to come up with a clear definition of what you consider to
> be a “manifest” first.

Or strike that comparison altogether. I'll see what can be done.

> The design goal of extensibility is good, but the rest of the spec does not
> deliver on providing a architecturally clean extension mechanism. Is it just
> new TLVs? If so, what’s the allocation scheme? Is there a need to have
> different extensibility set to help consumers from the ones to help caches?
> Need an IANA registry? The specific examples of extensions don’t seem to be
> the high runners. I think we need to come up with more and better examples.

Noted.

> The limitation of all data leaves being present seems to exclude cut/paste
> or append. Is this supposed to be forever, or is there some future extension
> envisioned that would relax this?

As of now, forever. We should revisit this.

> Expand the acronym “EBN”

Noted.

> Why is this called a “ManifestMsg”? It isn’t a CCNx or NDN message, it’s
> just the data content part of one.

That is not true. Currently, it is a new message (not packet) type,
alongside interest and data. I remember there being some debate that
led us to this decision, but I don't recall the specifics. I don't see
a reason why it couldn't just be a content object message with a
manifest payload type.

> The stuff about “A Hashgroup can contain a metadata section…” is
> underspecified. At least I couldn’t find any place this is laid out in
> detail.

Noted.

> You assume the reader knows the nuance of what it means for an object to be
> “chunked” so you can say than neither the ICN objects pointed to by a FLIC
> manifest, nor the FLIC itself, can be “chunked”. This needs more explanation
> and background, especially since both NDN and CCNx today talk a lot about
> how to chunk objects.

Noted.

> Section 2.1 (Use of hash-valued pointers) might be a lot better if it was
> moved into the introduction.

Noted.

> Is it actually a requirement that FLIC use “nameless objects”? The fetch
> could also use the name of the Manifest as a prefix with the hash as the
> name suffix, although doing it with the Name prefix for routing and a
> content hash restriction field to select the object is more in keeping with
> the current direction of CCNx. Just in general I find the term “nameless
> objects” to be infelicitous and more confusing to people than saying objects
> are fetched by name prefix plus hash restriction.

Fair point. This was largely written in the context of CCNx. We can
generalize this text so that either of the techniques you describe
work.

> on page 6, you talk about “download”, when I think you probably mean
> “fetch”.

Noted.

> I didn’t get the restriction in 2.3 that “the receiver sequentially works
> through all entires found in the Hashgroups…” what constrains the traversal
> to be sequential?
> A little further down you say the traversal order is DFS, with pre-order DFS
> bing the only supported strategy. Is this an actual restriction of the
> specification, or only the current implementation?

It's part of the specification. The point of FLIC is to encode a
large, contiguous piece of data that can't fit within a single content
object. One of the extensions could be to specify a traversal
algorithm to override the DFS requirement.

>
> Under 2.4, you have an informal list of metadata in hash groups. This needs
> to be tightened up, and the encoding specified. Is it TLV? Can you have
> sub-TLVs?

I'll clean this up.

>
> In particular, the “OverallDataDigest” metadata field needs more
> explanation.

Agreed. It's vague.

>
> I’m not getting the bit about “the optional name of a manifest is a mere
> decoration and has no locator functionality”. If that’s the case, why have
> it? Seems a recipe for programmers to screw up.

This ties back to the nameless content object comment above. I'll see
what can be done about this.

>
> Section 3.4 on re-publishing needs some work. Switching of serve provider is
> only one cases and perhaps not the most interesting one. A simple use case
> is the same data published under multiple names (aliases, hard-links, etc.).
> The following paragraph that starts “This example points out…” us pretty
> hard to follow - try a rewrite?

Agreed!

>
> Section 4 on encoding is pretty confusing. I wasn’t getting the
> “SymbolicName/Tvalue” scheme at all.

Yes, we need to elaborate on that section, or rewrite it entirely.

>
> end of comments

end of response. :-)

Best,
Chris