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

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

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]