Re: [icnrg] New Version Notification for draft-wissingh-icnrg-terminology-00.txt

[Börje Ohlman <[e-mail]>]

Hi Bastiaan and co-authors,

<chair hat off>

I also think it is good that we get some progress on this work. Some initial comments from my side. I agree with Dirk’s comments below, in particular regarding the use of the term “packet”.

The major comment I have is that I think it is important that this terminology document gives the full view of ICN technology and is not limited to the CCN/NDN view of ICN. A lot of the text in the document seems to assume ICN=CCN=NDN which I think might confuse many readers. 

For section 2 I would like to see a bit broader perspective of ICN. I understand that we need to keep this section short and that it should be a very high level overview, but we should make sure what is in there is generic to ICN. One example of what should be stated differently is “ Every data packet must be cryptographically signed which binds its name and content together.”, this is not necessarily true, there are other ways of achieving name data integrity.

In section 3 I think we should try to find a way to indicate to the reader which terms are truly generic ICN terms that the ICN community at large has agreed on and which terms are specific to a certain approach. We also have a third category of terms, which probably is the most problematic, and it is the terms that are used in several approaches but might have slightly different semantics in the respective approach.

While I do hope that we one day have only one agreed ICN approach and associated terminology, I don’t think we are there quite yet. To help us get there I think it is important that this document reflect the efforts we have made to get there in a correct way.


	Börje




> On 10 juli 2016, at 13:21, Dirk Kutscher <[e-mail]> wrote:
> 
> Hi Bastiaan and co-authors,
> 
> <chair hat off>
> 
> Thanks for working on this. I have some comments:
> 
> 1) Naming packets:
> 
> I find the text on naming packets unnecessarily restrictive. In ICN the network is IMO delivering named data objects. These are the units of communication that are authenticated etc. For communication, they may be split up (fragmented) -- it's IMO an implementation detail whether name granularity then applies to a per-packet basis. Especially when you think of running ICN on top of protocols such as UDP, QUIC etc -- the packet analogy does not work.
> 
> Useful terminology in that context is IMO:
> 
> Named Data Object -- objects that a requestor asked for and that the network delivers. These are the units to validate name-content bindings for and to authenticate.
> 
> Messages: interests for NDOs and corresponding responses that may carry requested NDOs. (In general, I'd s/packet/message/ in the draft.)
> 
> 2) ICN node:
> 
> I don't think distinguishing "real-time" forwarding from "packet mule" operation is the best possible characterization. I'd probably say something like "an ICN node can apply different strategies to forwarding ICN Interests messages and NDOs. In general, Interest message are forwarded over suitable faces according to forwarding information, and NDOs are forwarded according to Pending Interest information. However ICN node may chose other strategies, for example store-and-forward like operation for both Interest and NDO messages."
> 
> 3) Segmentation/Chunking:
> 
> I don't think you need to prescribe the naming scheme for that in a terminology draft. In general, I think it is important to say that chunks are just NDOs, i.e, unique Named Data Objects. They may be part of a larger logical application data unit, for example a video stream/file.
> 
> 
> 4) Self-Certifying Name:
> 
> That's really a problematic term that we should avoid, because it's unclear WHAT you are actually certifying. You are merely using a hash (of a potentially signed message) that allows you to validate name-content binding and to potentially ascertain an object creator's identity.
> 
> I have some additional comments -- but perhaps this can start off some discussion already.
> 
> Cheers,
> Dirk
> 
> </chair hat off>
> 
>> -----Original Message-----
>> From: icnrg [mailto:[e-mail]] On Behalf Of Wissingh, B.F.
>> (Bastiaan)
>> Sent: Freitag, 8. Juli 2016 22:33
>> To: [e-mail]
>> Subject: [icnrg] FW: New Version Notification for draft-wissingh-icnrg-
>> terminology-00.txt
>> 
>> Hi All,
>> 
>> We’ve just submitted a first version of the draft regarding ICN Terminology, as
>> discussed during the Buenos Aires meeting. The goal of this document is to
>> provide a complete collection of ICN related terms with their corresponding
>> definition.
>> 
>> Best,
>> Bastiaan
>> 
>> Op 08-07-16 22:25 heeft [e-mail] <[e-mail]>
>> geschreven:
>> 
>> 
>> A new version of I-D, draft-wissingh-icnrg-terminology-00.txt
>> has been successfully submitted by Bastiaan Wissingh and posted to the IETF
>> repository.
>> 
>> Name:		draft-wissingh-icnrg-terminology
>> Revision:	00
>> Title:		Information-Centric Networking: Terminology
>> Document date:	2016-07-08
>> Group:		Individual Submission
>> Pages:		11
>> URL:            https://www.ietf.org/internet-drafts/draft-wissingh-icnrg-
>> terminology-00.txt
>> Status:         https://datatracker.ietf.org/doc/draft-wissingh-icnrg-terminology/
>> Htmlized:       https://tools.ietf.org/html/draft-wissingh-icnrg-terminology-00
>> 
>> 
>> Abstract:
>>   Information Centric Networking (ICN) is a new paradigm where network
>>   communications are accomplished by requesting named content, instead
>>   of sending packets to destination addresses.  This document provides
>>   an overview of the terminology and definitions that have been used in
>>   describing this new paradigm.  This document is a product of the IRTF
>>   Information-Centric Networking Research Group (ICNRG).
>> 
>> 
>> 
>> 
>> Please note that it may take a couple of minutes from the time of submission
>> until the htmlized version and diff are available at tools.ietf.org.
>> 
>> The IETF Secretariat
>> 
>> 
>> 
>> This message may contain information that is not intended for you. If you are
>> not the addressee or if this message was sent to you by mistake, you are
>> requested to inform the sender and delete the message. TNO accepts no liability
>> for the content of this e-mail, for the manner in which you use it and for damage
>> of any kind resulting from the risks inherent to the electronic transmission of
>> messages.
>> _______________________________________________
>> icnrg mailing list
>> [e-mail]
>> https://www.irtf.org/mailman/listinfo/icnrg
> _______________________________________________
> icnrg mailing list
> [e-mail]
> https://www.irtf.org/mailman/listinfo/icnrg