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

From: "Wissingh, B.F. (Bastiaan)" <[email-masked]>
Date: Fri, 8 Jul 2016 20:32:54 +0000

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 [email-masked] <[email-masked]> 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.

---

From: Dirk Kutscher <[email-masked]>
Date: Sun, 10 Jul 2016 11:21:16 +0000

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:[email-masked]] On Behalf Of Wissingh, B.F.
> (Bastiaan)
> Sent: Freitag, 8. Juli 2016 22:33
> To: [email-masked]
> 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
> 
> has been successfully submitted by Bastiaan Wissingh and posted to the IETF
> repository.
> 
> 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
> [email-masked]
> https://www.irtf.org/mailman/listinfo/icnrg

---

From: Ravi Ravindran <[email-masked]>
Date: Fri, 15 Jul 2016 01:43:29 +0000

Hi,

Few comment in Section 3.2 on the many Name definitions. The 'Name' definition begins by saying that it uniquely identifies a Interest/Data packet. The definition then states name is an identifier, and then we also say name can also be a locator. Seems contradictory to me ?
At a minimum we should separate the two notions. I would suggest to use identifier/locator terminology, they both can be names. Names for me is something that is a human friendly identifier. More importantly identifiers have to be persistent, I don’t see that as a attribute being mentioned in any of those definitions.
Then self-certifying name should also include hashes of public key just like MobilityFirst does. For PacketId, it says, there is a name, then why do you need another PacketId ?. 
Also, do we really need that many definitions for Name ?

Regards,
Ravi

-----Original Message-----
From: icnrg [mailto:[email-masked]] On Behalf Of Wissingh, B.F. (Bastiaan)
Sent: Friday, July 08, 2016 1:33 PM
To: [email-masked]
Subject: [icnrg] FW: New Version Notification for draft-wissingh-icnrg-terminology-00.txt

Hi All,

Best,
Bastiaan

Abstract:

The IETF Secretariat

---

From: Börje Ohlman <[email-masked]>
Date: Sun, 17 Jul 2016 05:06:59 +0000

<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 <[email-masked]> wrote:
>