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

From: "Wissingh, B.F. (Bastiaan)" <[email-masked]>
Date: Wed, 2 Nov 2016 09:26:49 +0000

Hi All,

Before the previous IETF meeting in Berlin, we submitted a first version of the ICN Terminology draft and so far, we received comments from Dirk, Börje and Ravi which we are currently trying to address. 

While we are working on that, I would encourage people to have a look at the draft (if not done already) and provide us with your thoughts.

Best,
Bastiaan

Op 08-07-16 22:32 heeft icnrg namens Wissingh, B.F. (Bastiaan) <[email-masked] namens [email-masked]> geschreven:

    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.
    _______________________________________________
    icnrg mailing list
    [email-masked]
    https://www.irtf.org/mailman/listinfo/icnrg

---

From: "Wissingh, B.F. (Bastiaan)" <[email-masked]>
Date: Wed, 2 Nov 2016 09:49:32 +0000

Hi Börje,

Thanks for your comments! Could you clarify a bit what you mean with your section 3 remark? Do you mean for example, that the terms Name Component and Name Segment both refer to the same thing, but are given different terms in different implementations? And that the draft should clarify a bit more where these terms are coming from?

Best,
Bastiaan

Op 17-07-16 07:06 heeft Börje Ohlman <[email-masked]> geschreven:

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