[icnrg] Updates to the ICNRG Terminology Document: draft-irtf-icnrg-terminology

["David R. Oran" <[e-mail]>]

Many thanks to Benjamin and Mirja for their comments on the -07 draft 
that went through IESG conflict Review. I have produced a -08 version 
that hopefully addresses the comments adequately. Below please find my 
responses with notation of the consequent changes.

These are also captured in the Issue Tracker section of the document’s 
Github repository: 
https://github.com/icnrg/draft-irtf-icnrg-terminology/issues

The -08 version is available through the data tracker at 
https://datatracker.ietf.org/doc/draft-irtf-icnrg-terminology/.

Note: I did not copy either the whole IESG nor the IRSG on this message 
to reduce noise. If any of you think they should see it, please redirect 
or forward.

Thanks!!!


###Comments from Mirja###

- Sec 3.3. defines *Interest aggregation* and says "Not the same as 
Interest suppression.”, however, Interest suppression is not 
defined…?

Ah: good catch. This is a bit of a historical hangover from when the 
architecture talked about suppression and aggregation as different in 
some ways. It turns out that aggregation is the more general and more 
accurate way to describe the designs. So, I’m getting rid of that 
sentence.

- Nit in sec 4.4: s/can be turned into into a database/can be turned 
into a database/ -> 2x into

Fixed.

###Comments from Benjamin###

####Section 2####

- Trust: “Data authenticity is distinct from data trustworthiness, 
though the two concepts are related.  A packet is authentic if it has a 
valid name-to-content binding.  A packet is trustworthy, i.e., it  comes 
from a reputable or trusted origin, if this binding is valid in the 
context of a trust model.  Section 6 discusses this further.” I think 
I see what is intended here, but distinguishing between "valid" and 
"valid in the context of a trust model" is a pretty subtle 
differentiation. Some more discussion about a given named entity being 
expected to produce certain content might help (but then again, might 
not).

I was inclined to leave this as is, but perhaps adding something like 
what you suggest is actually helpful. So, I added the sentence before 
the reference section 6: “The trust model provides assurance that the 
name used for a given piece of content is appropriate for the value of 
the content”. We can remove or further change this during RFC editor 
processing if you think this doesn’t help (or further obfuscates).


- Forwarding Plane: The canonical way of implementing packet forwarding 
in an ICN network relies on three data structures that capture a node's 
state: a Forwarding Interest Table (FIB), a Pending Interest  Table 
(PIT), and a Content Store (CS).  It also utilizes Interest forwarding 
strategies which takes input from both FIB and measurements to make 
Interest forwarding decisions.  When a node”
nit: "take input" to match "strategies" plural.

Fixed.

####Section 3.1####

Data packet Immutability: “After a data packet is created, the 
cryptographic hash binding the name to the content ensures that if 
either the content or the name changes, that change will be detected and 
the packet discarded.
nit: previous discussion referred to the name-to-content binding as a 
"signature", not as a "hash".

Right, changed to “signature”

####Section 3.5####

Nonce:”A field of an Interest packet that transiently names an 
Interest instance (instance of Interest for a given name).  Note: the 
use "nonce" as defined here for NDN does not imply semantics that 
satisfy all the properties of a cryptographic nonce as defined in, e.g.  
[RFC4949].” RFC 4949 does not have a definition for "cryptographic 
nonce", so I assume just the regular definition for "nonce" is the 
intended reference. The only required attribute there is "random or 
non-repeating", with liveness
guarantee and replay protection being only the "usual usage" (i.e., not 
required). While I assume I don't fully understand the nuance of ICNRG 
nonce usage, my understanding is that they are intended to be 
non-repeating, at least within some time window, and serve to tie 
specific expressions of interest to data responses. That is not exactly 
the "replay protection" of RFC 4949, though it is closely related, and I 
would argue that even the "non-repeating within a time window" property 
suffices to keep the ICN usage within the RFC 4949 definition. Which is 
a long way of saying that I don't think this much disclaimer is needed.

The concern was that NDN is very loose in their nonce requirements. For 
example with guessable nonces an attacker could cause some PIT state to 
be created by one incoming interest which might inappropriately cause 
aggregation of interests from a victim that should have been forwarded. 
The point about RFC4949 not defining cryptographic nonces is well taken 
however. I toned down the disclaimed to “Note: the specification 
defining nonces in NDN do not necessarily satisfy all the properties of 
nonces as discussed in RFC4949”.

Is that better?


####Section 6####

- “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.” This is a great formulation; 
thank you!

We appreciate the vote of confidence!