Subject: Re: [icnrg] [irsg] Final IRSG poll on draft-irtf-icnrg-terminology-06

From: "David R. Oran" <[email-masked]>
Date: Thu, 24 Oct 2019 08:49:27 -0400

Hi, and thanks to Vincent, Brian, Marie-Jose, and Spencer, who took the 
time to read and comment on this work during IRSG Last Poll,

I’m sorry for the delay in responding, but I wanted to get all the 
comments assembled and check with the co-authors before replying (none 
of the co-authors had anything to add). Below find my proposed responses 
to the comments and the plan for an update to the document. In a couple 
of cases I have a question as the reply to the comment, so please take a 
look and give further guidance if you think it appropriate.

I’ll hold off editing resubmitting the document for a few days in case 
you have further thoughts or other IRSG members want to weigh in for the 
poll.

I’ve snipped out headers and such and grouped the comments by the 
person who made them. This makes a couple of the responses a bit 
redundant.

##Vincent Roca wrote:##

> * section 2: the FIB, PIT and CS definitions are key to ICN but are 
> not visible (hidden inside the « forwarding plane » definition).
>   They deserve more visibility.
>
We expect the usage model for this document to be more 
“lookup/search” rather than “Read end-to-end”, so there isn’t 
a lot of general exposition or attention to the order of the definitions 
part from the category groupings. By this logic the three data 
structures are all forwarding-related (as opposed to end-to-end 
semantics) so that’s where we put them. Unless you feel strongly about 
this, I’d prefer to leave this as is.

> * section 3.4, « Manifest » definition.
>   Is this facility used when a content is split into several Data 
> packets? An example of its possible use would be welcome I think.
>
Yes, and potentially also for “directory-like” functions for 
multiple content object under the same prefix. The current Manifest 
specification (FLIC - an expired draft we are refreshing any day now) is 
mostly oriented toward the former usage. While we want to err on the 
side of being general and not biasing with particular concrete examples, 
it may be appropriate to add something here. Would the following rewrite 
be better?

Old:
“A type of Data packet that contains Full Name Links to one or more 
Data Packets. Manifests group collections of related Data packets under 
a single Name. This has the additional benefit of amortizing the 
signature verification cost for each Data packet referenced by the inner 
Links. Manifests typically contain additional metadata, e.g., the size 
(in bytes) of each linked Data packet and the cryptographic hash digest 
of all Data contained in the linked Data packets.”

New:
“A type of Data packet that contains Full Name Links to one or more 
Data Packets. Manifests group collections of related Data packets under 
a single Name. Manifests allow both large Data objects to be 
conveniently split into individual Content Objects under one name, and 
to represent sets of related Content Objects as a form of 
“directory”. Manifests have the additional benefit of amortizing the 
signature verification cost for each Data packet referenced by the inner 
Links. Manifests typically contain additional metadata, e.g., the size 
(in bytes) of each linked Data packet and the cryptographic hash digest 
of all Data contained in the linked Data packets.”

> * section 3.5:
>   A figure is missing to explain the relationships between the « Name 
> » (defined as a « Data packet identifier ») and the « Packet ID »
>   (that is also a « unique crypto identifier for a Data packet ») 
> which includes the « Name » in the hashed information, and the
>   relationships between the « Exact Name » and « Full Name ».
>   There are concurrent Data packets identifiers, with additional 
> properties for the Packet ID, all of this being a bit confusing.
>
Perhaps this is all a bit confusing without the context of understanding 
many pieces of the NDN or CCNx architecture. No disagreement on that. 
However, there are two downsides of trying to fix this with a figure: 
(a) it would likely need a whole bunch of additional explanation, 
winding up recapitulating things that are already documented in detail 
in specifications like RFC8569, (b) the relationships are not neatly 
captured graphically without slipping into specifying an algorithm by 
which you ascertain how, for example, to derive an Exact Name from the 
Full Name, or how Packet-ids are used in particular forwarding/matching 
algorithms.

Again, our usage model for this document is that you’d start with some 
other specification, and get pointed here for formal definition terms 
used, as opposed to having this be the first thing you pick up when 
wanting to learn about CCNx or NDN.

If you feel that we really need to “show our work” here, we’ll be 
happy to take a crack.

> * section 6 « security considerations »
>   Instead of saying there’s nothing new, I’d rather point to the 
> security considerations of already existing documents. This is more
>   constructive since this type of architecture raises many security 
> questions.
>
Agree that the architecture does have lots new, and Stephen Farrell 
brought up a bunch of good points about the specifics of the 
crypto-related definitions (which we addressed in the current version). 
We can of course add references beyond the ones already in the document 
(especially RFC8569 and RFC8609) if you think that helps and 
cross-reference them in the Security Considerations section.

Given that the terse language in the existing text raise a red flag for 
you, perhaps we could write the following for the security 
considerations:

“While the terms defined in this specification do not in and of 
themselves present new security considerations, the architectures which 
utilize the terms most certainly do. Readers should look at those 
specifications (e.g. RFC8569, NDN) where various security considerations 
are addressed in detail”.

What do you think? Adequate?

>
>
> Typo and minor comments:
>
> * intro: « in this draft… » => « in this document » seems 
> preferable
>
yes, will fix

> * section 3.1: « without that hange being detected » => change
>
yes, will fix

> * section 3.2: I don’t understand sentence « Note do not have all 
> the properties of data mules… »
>   Missing word?
>
Yes, should be “Note that such ICN data mules do not have all the 
properties of data mules as employed in the Delay Tolerant Networking 
(DTN) [RFC4838] specifications.”

> * section 3.3, « interest match in FIB » item: this is the first 
> time the notion of prefix is mentioned, please add a link to
>   section 3.5 where it is defined.
>
ok, will do. Good idea.

> * Section 3.6, « fragmentation » definition.
>   « A process of splitting PDUs into frames «  => Frames as it 
> refers to the « Frame » definition.
>
assuming you mean just fix the capitalization of “Frames”, yes, will 
fix.

##Brian Trammell wrote:##

> A terminology document, as a potential landing place of someone trying 
> to get their head around a new area, should at least have security 
> considerations by redirection. In particular, the definition of 
> "trust" refers to the context of a trust model but makes no reference 
> to trust models typically used within ICN deployments; I looked to the 
> security considerations section for this and was disappointed.

In the interest of being general, we don’t point to particular trust 
models or schemes to support them. However, there is a lot of good work 
here and that seems to be the common direction for both CCNx and NDN, so 
it’s probably appropriate to add a sentence on this and a reference to 
the Trust Schema paper for NDN. Would that alleviate your concern?

> The use of Packet, Segment, and Frame is a little weird for people 
> with a traditional TCP/IP background. Differences in applicability 
> between segmentation and fragmentation an an ICN are not really clear 
> to me after reading this document. Additional discussion would be 
> useful.

Could you elaborate a bit on this? Packet is an L3 object understood by 
forwarders. Segment is a piece of a content object that had been 
fragmented to place in a Packet. Frame is the L2 thing you stuff packets 
in. Is this different from your understanding of either what the 
terminology doc says, or what the usage in for TCP/IP?

##Spencer Dawkins wrote##
> referencing Brian’s comment above on security considerations:
> I think Brian has this exactly right - if the answer is "This document 
> introduces no new security considerations", the next question from a 
> reader who's new to the topic is likely to be "no new security 
> considerations beyond what baseline, exactly?". In a perfect world, 
> the baseline could be limited to references, with little or no 
> expansion in this document.

Would the approach suggested above alleviate your concern too?

##Marie-Jose Montpetit wrote:##
> I have another nit in section 3.1
> Data packet immutability
> Everywhere else the titles are with uppercase so  "Data Packet 
> Immutability" Section 3.3 also has mixed title cases. Just decide on 1 
> way?

Will fix - go with upper case consistently (unless RRC editor prefers 
something different)

[End]

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Thu, 24 Oct 2019 22:09:51 -0500

Hi, David,

Top-posting, just to say that the proposed change to the Security
Considerations section provides the pointers I was hoping for, AND provides
the reminder that the relevant security considerations aren't the result of
terminology, but of the specifications that use that terminology.

So what you suggested was better than what I was thinking of. Thanks for
that.

Spencer

On Thu, Oct 24, 2019 at 7:49 AM David R. Oran <[email-masked]> wrote:

> comments assembled and check with the co-authors before replying (none of
> the co-authors had anything to add). Below find my proposed responses to
> the comments and the plan for an update to the document. In a couple of
> cases I have a question as the reply to the comment, so please take a look
> and give further guidance if you think it appropriate.
>
> I’ll hold off editing resubmitting the document for a few days in case you
> have further thoughts or other IRSG members want to weigh in for the poll.
>
> I’ve snipped out headers and such and grouped the comments by the person
> who made them. This makes a couple of the responses a bit redundant.
> Vincent Roca wrote:
>
> * section 2: the FIB, PIT and CS definitions are key to ICN but are not
> visible (hidden inside the « forwarding plane » definition).
> We expect the usage model for this document to be more “lookup/search”
> rather than “Read end-to-end”, so there isn’t a lot of general exposition
> or attention to the order of the definitions part from the category
> groupings. By this logic the three data structures are all
> forwarding-related (as opposed to end-to-end semantics) so that’s where we
> put them. Unless you feel strongly about this, I’d prefer to leave this as
> is.
>
> Is this facility used when a content is split into several Data packets?
> An example of its possible use would be welcome I think.
>
> Yes, and potentially also for “directory-like” functions for multiple
> content object under the same prefix. The current Manifest specification
> (FLIC - an expired draft we are refreshing any day now) is mostly oriented
> toward the former usage. While we want to err on the side of being general
> and not biasing with particular concrete examples, it may be appropriate to
> add something here. Would the following rewrite be better?
>
> Old:
> “A type of Data packet that contains Full Name Links to one or more Data
> Packets. Manifests group collections of related Data packets under a single
> Name. This has the additional benefit of amortizing the signature
> verification cost for each Data packet referenced by the inner Links.
> Manifests typically contain additional metadata, e.g., the size (in bytes)
> of each linked Data packet and the cryptographic hash digest of all Data
> contained in the linked Data packets.”
>
> New:
> “A type of Data packet that contains Full Name Links to one or more Data
> Packets. Manifests group collections of related Data packets under a single
> Name. Manifests allow both large Data objects to be conveniently split into
> individual Content Objects under one name, and to represent sets of related
> Content Objects as a form of “directory”. Manifests have the additional
> benefit of amortizing the signature verification cost for each Data packet
> referenced by the inner Links. Manifests typically contain additional
> metadata, e.g., the size (in bytes) of each linked Data packet and the
> cryptographic hash digest of all Data contained in the linked Data packets.”
>
> * section 3.5:
> A figure is missing to explain the relationships between the « Name »
> (defined as a « Data packet identifier ») and the « Packet ID »
> (that is also a « unique crypto identifier for a Data packet ») which
> includes the « Name » in the hashed information, and the
> There are concurrent Data packets identifiers, with additional properties
> for the Packet ID, all of this being a bit confusing.
>
> However, there are two downsides of trying to fix this with a figure: (a)
> it would likely need a whole bunch of additional explanation, winding up
> recapitulating things that are already documented in detail in
> specifications like RFC8569, (b) the relationships are not neatly captured
> graphically without slipping into specifying an algorithm by which you
> ascertain how, for example, to derive an Exact Name from the Full Name, or
> how Packet-ids are used in particular forwarding/matching algorithms.
>
> other specification, and get pointed here for formal definition terms used,
> as opposed to having this be the first thing you pick up when wanting to
> learn about CCNx or NDN.
>
> If you feel that we really need to “show our work” here, we’ll be happy to
> take a crack.
>
> Instead of saying there’s nothing new, I’d rather point to the security
> considerations of already existing documents. This is more
> brought up a bunch of good points about the specifics of the crypto-related
> definitions (which we addressed in the current version). We can of course
> add references beyond the ones already in the document (especially RFC8569
> and RFC8609) if you think that helps and cross-reference them in the
> Security Considerations section.
>
> you, perhaps we could write the following for the security considerations:
>
> “While the terms defined in this specification do not in and of themselves
> present new security considerations, the architectures which utilize the
> terms most certainly do. Readers should look at those specifications (e.g.
> RFC8569, NDN) where various security considerations are addressed in
> detail”.
>
> * intro: « in this draft… » => « in this document » seems preferable
>
> yes, will fix
>
> * section 3.2: I don’t understand sentence « Note do not have all the
> properties of data mules… »
> Missing word?
>
> properties of data mules as employed in the Delay Tolerant Networking (DTN)
> [RFC4838] specifications.”
>
> * section 3.3, « interest match in FIB » item: this is the first time the
> notion of prefix is mentioned, please add a link to
> « A process of splitting PDUs into frames « => Frames as it refers to the
> « Frame » definition.
>
> assuming you mean just fix the capitalization of “Frames”, yes, will fix.
> Brian Trammell wrote:
>
> A terminology document, as a potential landing place of someone trying to
> get their head around a new area, should at least have security
> considerations by redirection. In particular, the definition of "trust"
> refers to the context of a trust model but makes no reference to trust
> models typically used within ICN deployments; I looked to the security
> considerations section for this and was disappointed.
>
> it’s probably appropriate to add a sentence on this and a reference to the
> Trust Schema paper for NDN. Would that alleviate your concern?
>
> The use of Packet, Segment, and Frame is a little weird for people with a
> traditional TCP/IP background. Differences in applicability between
> segmentation and fragmentation an an ICN are not really clear to me after
> reading this document. Additional discussion would be useful.
>
> forwarders. Segment is a piece of a content object that had been fragmented
> to place in a Packet. Frame is the L2 thing you stuff packets in. Is this
> different from your understanding of either what the terminology doc says,
> or what the usage in for TCP/IP?
> Spencer Dawkins wrote
>
> introduces no new security considerations", the next question from a reader
> who's new to the topic is likely to be "no new security considerations
> beyond what baseline, exactly?". In a perfect world, the baseline could be
> limited to references, with little or no expansion in this document.
>
> Marie-Jose Montpetit wrote:
>
> Immutability" Section 3.3 also has mixed title cases. Just decide on 1 way?
>

---

From: "David R. Oran" <[email-masked]>
Date: Wed, 30 Oct 2019 09:55:06 -0400

Hi,  to thanks to Canrste and Ari, who also took the time to read and 
comment on this work during IRSG Poll. I’ll fold the changes resulting 
from these comments into the revised draft, which hopefully will be done 
by early next week.

Below find my proposed responses to these additional comments and the 
associated additional plan for the updates. In a couple of cases I have 
a question as the reply to the comment, so please take a look and give 
further guidance if you think it appropriate.

person who made them.

##Ari Keränen wrote:##
> 4.5. (Remote Procedure Call). It seems to just repeat verbatim parts 
> of section 3.3 without giving much useful extra information.

In looking this over, I (mostly) agree. I think this section could be 
removed without losing much useful. In fact, there’s been a lot of 
work done on remote invocation with ICN since all this was written and 
pretty much obsoletes anything we would have said here. Given the 
increasing importance of distributed computing stuff for ICN, what I 
propose here is to get rid fo the individual definitions, retain the 
section heading, and replace the text with a general statement about the 
terminology being applicable to RPC, with references to some of the 
recent work (most notably RICE from ICN’18, CFN from ICN’19 and the 
design for network management paper also from ICN’19. Unless I hear 
otherwise from ICNRG folks or IRSG folks, this is what I’ll do.

> Would be useful to provide references for NDN and CCNx.
Yes. Already in the update plan.

> The asterisks around the terms and three empty lines before common 
> aliases looked weird to me.  I'd remove the asterisks and have just 
> single empty line before the common aliases.
This is an xml2rfc artifact for how the .txt rendering is done for XML 
constructs like <spanx>. The HTML output is much prettier. I’m going 
to leave this - maybe the version3 text renderer will be better :-)

> Section 2: colon missing for "Packet and Content Names"
Will fix.

> Typo in Section 3.4: sigtnature
Will fix.

##Carsten Bormann wrote:##

> I am not an ICN expert, but I find a bit weird that the document lists 
> two architectures (NDN and CCNx) and then goes ahead and defines 
> exactly the same terms for them (except apparently for “nonce”).  
> This may be exactly as intended, but probably begs for some 
> explanation.

Insightful comment. The explanation below is probably TL;DR:

The genesis of this terminology effort was back around 2014-15 when NDN 
and CCNx were different in some important ways, but the two sets of 
advocates were having difficulty communicating and crystalizing the 
differences. Part of getting through this was meeting and coming up with 
common terminology so that the differences could be explained (one 
example was the essential use of “exact names” in CCNx, but only 
having “name prefixes” in NDN). The terminology work did go a long 
way in fostering both communication and analysis of the differences. 
What has happened since, especially in the last 2 years or so, is that 
the two designs have changed due to implementation and deployment 
experience to be much closer to one another, to the point now that (at 
least in my opinion) the two differ mostly in aesthetic choices for 
packet encoding and some smallish details; the major differences have 
been erased. So, now we are in a state where the we can just say, for 
nearly all ICNRG work, “this applies equally to NDN and CCNx”. In 
the case of “nonce” mentioned above, CCNx had nonces and got rid of 
them. NDN still has them, but has added hop limits because the nonces 
turned out to not be a viable loop suppression mechanism as previously 
thought.

I would not recommend that we try to explain this in the terminology 
draft - it risks opening old wounds.

> (Please do add non-RFC references; you probably don’t want people to 
> read RFC 90 to learn about CCN.)
Based on these and other comments, we will be adding a bunch of 
references to the NDN documentation and to the relevant academic papers, 
etc.

> Maybe warn the reader early that terms are not defined before use.
Good idea. We’ll add a sentence in the introduction to this end.

> (I note the usual confusion between trustworthiness and trust, but 
> this is maybe not the place to clean this up.)
I would rather not wander into this rabbit warren, so I proposed no 
change for this.

> The term “link” is unfortunate.  How do you call the L2 things?  
> (“Link”, apparently.)
Ouch. I think you’ve uncovered a potential source of confusion, 
between the ICN-specific meaning of “Link” (a signed name->name 
reference in the L3 ICN protocols) and the colloquial use for layer 2 
interfaces. Unless somebody has a better idea, rather than mess with the 
consensus for the ICN terminology, I suggest changing the L2 references 
to say “layer 2 interface” rather than “link”.

> It’s 2019 and this still uses “octets”.  Please use “bytes”.
Okay…

> Note that integrity/authenticity needs to link data names to the data 
> packets (says so in 2, not in 3.7).
On the description of binding name<->content, section 2 is the 
definitive terminology. The terms in 3.7 are intended to be more general 
and apply to more than that binding. Is this ok as is?

> [There is also no discussion how freshness is assured for access to 
> the newest version of versioned content; this may be out of scope.]
I think it’s out of scope. CCNx and NDN used to be quite different how 
they approached immutability and the relationship with versioning and 
“freshness”. Now they are closer, although there are still some 
difference - some subtle, some not so subtle. What we do hopefully have 
is terminology that can be used to describe the differences!

> I would expect the security considerations section to contain 
> references to the existing security considerations, even if there 
> aren’t new ones.
I proposed some text to address the same comment some others. I’ll 
assume that’s ok unless you have some followup.

> Nits:
> “disambiguation of coordination” what?
Yeah. Should not have missed that. What we mean is: “This allows 
disambiguation of various versions of content such that coordination 
among the various instances in a distributed system can be achieved.” 
Better?

> “Note do not have all the properties”
Right, should be “Note: these do not have all the properties of…”

> “sigtnature”
Got it.

> ” has a common prefix and additional component representing”
Right, should be “has a common prefix and an additional component 
representing”

> “ a through IRSG review”
Will fix.

> More nits (right out of idnits):
(Maybe identify the unused references as further bibliography.)
>  == Unused Reference: 'I-D.irtf-icnrg-disaster' is defined on line 
> 724, but
>     no explicit reference was found in the text
I like the suggestion. A bunch of the references I’ll be adding might 
not have xrefs in the text, so if there’s no objection I’ll create a 
separate references section titled “Bibliography”.

[End]