Subject: [icnrg] Comments on terminology draft

From: Cedric Westphal <[email-masked]>
Date: Fri, 4 Nov 2016 04:38:39 +0000

Hi Bastiaan,

I would agree with Borje's comment, namely that this is more a CCN/NDN
terminology than a ICN terminology.

On the one hand, there are no mention of solutions that use a
rendez-vous server or pub/sub methods. On the other hands, it goes
into a lot of details that are not Information-Centric per se, but
CCN/NDN related. For instance, PIT and stateful forwarding are
mentioned, which offer certain benefits, but are more about creating
symmetric routing or new congestion management tools than defining
Information-Centric properties. You could have name-based routing
without a PIT.

I think renaming the document to CCN/NDN terminology would be more
accurate. It's probably an easier path than to try to be ICN
architecture agnostic.

Here are some more specific comments about this draft:

3.1. "This allows disambiguation of coordination" is an ambiguously
coordinated sentence;-)

3.2. The discussion on hierarchy never specifies, but implies an
ordering of the components (for instance, in the prefix applying "from
the beginning"). Maybe better to make it explicit that you go
root/leaf/leaf/... rather than the other way around.

Segmentation: I'm used to SAR from my days in header compression, so I
am a bit surprised to see this segmentation as chunking. Is it
accepted universally?

3.3. The "data confidentiality credientials" are used to ensure the
"confidential data" can be decrypted by the consumer. But I'm a bit
confused as to what "confidential data" is. Is it a payload that is
encrypted, or is it a part of the data that is confidential?

ICN public key and ICN public key owner don't seem to be related to
content. The ICN public key is a data packet; the key owner owns the
private key. It's all fine, but why is it ICN related? Where is that
ICN public key used? There is a glimpse of an explanation later in the
trust model, but it conflates both key and key owner. It should say
somewhere that there is a signature (or is it a "Packet ID" in this
terminology) which is generated by the content producer ("ICN key
owner"?) with a public key ("ICN public key"). Or if the ICN key owner
is not the conte3/nt producer, then who is she?

3.4 I think the term "face" is totaly unnecessary and should be
deprecated. Interface is fine.

ICN producer is defined as an entity that "creates data packet." This
is abused later on to include caches, which do not create data packet,
but only store them.

3.5 Stateful forwarding is not the same as ICN forwarding. There are
other flavors of ICN, and there are even stateless flavors of CCN/NDN
(see the literature on PITless forwarding).

"Data match in PIT (all match)" I'm unclear as to what "all match" refers to.

Interest match in CS (any match) -> I'm unclear as to what it's "any."
There may - be a preference ordering if you have multiple matches, and
you would return, say, the latest version. You would not return "any"
version.

Interest aggregation is NOT the same as interest suppression. I can
suppress interests because of, say, congestion on a link, or
mismatched security attributes, and not just because I'm aggregating
with a previous identically named interest.

FIB -> mapping that represent "a candidate interface" should maybe be
"candidate interfaces?"

Upstream forwarding: I find it strange that in an ICN terminology, the
route goes from consumer to producer, and not from consumer to
CONTENT. In any case, this precludes routes from consumer to cache.

Same with downstream forwarding: it goes from content (or some
producer/cache combination) down to consumer.

"in routers opportunistic on-path caches" is a bit an oxymoron, since
opportunistic caches are defined as routers memory that are on-path.
So "in opportunistic caches" should suffice.

the patent attorney in me would disagree with narrowing the router's
memory to "disk or RAM". Maybe someone will figure a way to do optical
buffering, or tape may be an option for "data mules".

"temporarily, permanently, or scheduled storing" of data seems also a
bit redundant, since temporarily and permanently cover all bases
already. I see that scheduled seems to capture a bit more of the
"managed" aspect in this definition, but that aspect is actually a bit
unclear anyway. "a process of populating the cache of off-path routers
with a selected (set of) data packet(s) according to a caching policy"
maybe?

managed in-network storage acts as an ICN producer: that is confusing.
Again, the producer creates the packets. The managed in-network
storage does not create them. It may request them and receive them.
But that does not qualify as producer.

I would like to see "manifest" explained...

---

From: David Oran <[email-masked]>
Date: Fri, 4 Nov 2016 09:47:44 -0400

Thanks for the great comments, Cedric. On one of the good issues you raise I have my own view which I’d like to share.
I’m not sure if this is with chair hat on or off - I can’t disentangle my personal technical view from my chair role in this case.

Renaming the document and narrowing its scope to only cover CCN/NDN is certainly a possibility but I think that would be a mistake. Since a major role of the ICNRG is to foster communication and collaboration among researchers working in the field of ICN, it seems both premature and a narrowing of our mission to constrain a terminology document to only talk about how terms are used in one sub-class of ICN architecture.

I have viewed the terminology document’s role as primarily a means to clarify and remove confusion in terminology that is at times used in either sloppy or inconsistent ways in different ICN approaches. This should have the salutary effect of also being clearer in defining and describing terms for individual architectures like CCN and NDN, but that is only part of the goal.

A secondary positive effect of keeping the scope general and covering terminology not used in CCN or NDN as well as describing meanings of these terms that are different/inconsistent with NDN and CCN when used by other schemes will be to help researchers reading papers and experimenting with implementations of these different schemes It will also help more casual readers who are looking for a set of documents that include things like our survey and research challenges RFCs to get educated about the field.

Thanks,
DaveO.

> On Nov 4, 2016, at 12:38 AM, Cedric Westphal <[email-masked]> wrote:
> 
> Hi Bastiaan,
> 
> _______________________________________________
> icnrg mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/icnrg