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

From: "David Oran" <[email-masked]>
Date: Fri, 28 Jul 2017 11:07:39 -0400

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.
- an IRTF document with a security consideration section that says 
“none”? Give me a break. 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.
- the references are not formatted correctly, are out of date, and 
missing a bunch of important ones.
- 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.

####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.
- 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.
- 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.
- 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?
- Expand the acronym “EBN”
- Why is this called a “ManifestMsg”? It isn’t a CCNx or NDN 
message, it’s just the data content part of one.
- 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.
- 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.
- Section 2.1 (Use of hash-valued pointers) might be a lot better if it 
was moved into the introduction.
- 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.
- on page 6, you talk about “download”, when I think you probably 
mean “fetch”.
- 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?
- 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?
	- In particular, the “OverallDataDigest” metadata field needs more 
explanation.

- 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.
- 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?
- Section 4 on encoding is pretty confusing. I wasn’t getting the 
“SymbolicName/Tvalue” scheme at all.

#####end of comments#####

David R. Oran
Network Systems Research & Design
4 Shady Hill Square
Cambridge, MA 02138 USA

---

From: Christopher Wood <[email-masked]>
Date: Sat, 29 Jul 2017 08:41:24 -0700

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

On Fri, Jul 28, 2017 at 8:07 AM, David Oran <[email-masked]> wrote:
> 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

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

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

> end of comments

end of response. :-)

Best,
Chris