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

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

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.

I’ve snipped out headers and such and grouped the comments by the 
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]