Subject: [icnrg] F2F Seoul for Terminology on 17th of November

From: "Wissingh, B.F. (Bastiaan)" <[email-masked]>
Date: Sun, 13 Nov 2016 08:55:57 +0000

Hi All,

This Thursday 17th of November at 1:30pm we are planning to have a F2F to discuss and work on the ICNRG Terminology document.

For everyone that wants to participate in the discussion, we are meeting at 1:30pm at the IETF Registration desk.

Best,
Bastiaan
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: Börje Ohlman <[email-masked]>
Date: Tue, 15 Nov 2016 01:43:47 +0000

Hi,

If there is an updated working version of the draft that has not yet been posted you might want to send it to the mailing list before the meeting on Thursday so that people have a chance to look at before the meeting.

Börje

On 13 nov. 2016, at 09:55, Wissingh, B.F. (Bastiaan) <[email-masked]<mailto:[email-masked]>> wrote:

Hi All,

Best,
Bastiaan

_______________________________________________
icnrg mailing list
[email-masked]<mailto:[email-masked]>
https://www.irtf.org/mailman/listinfo/icnrg

---

From: "Wissingh, B.F. (Bastiaan)" <[email-masked]>
Date: Tue, 15 Nov 2016 07:08:07 +0000

Hi Börje, all,

As mentioned during the interim on Sunday, we did not make that much progress (at least in writing) since the version submitted before Berlin, however the latest version can be found on the GitHub: https://github.com/icnrg/draft-irtf-icnrg-terminology

Best,
Bastiaan

Op 15 nov. 2016 om 10:50 heeft Börje Ohlman <[email-masked]<mailto:[email-masked]>> het volgende geschreven:

Hi,

Börje

Hi All,

Best,
Bastiaan

---

From: <[email-masked]>
Date: Tue, 15 Nov 2016 08:40:10 +0000

I have a few comments on the draft in the git repo as of today.  First let me say ICN terminology is a really tough nut to crack, as the words are all over the place and competing ICN architectures vary wildly, so thank you for working on it.  I will try to make the Thursday meeting.

1) Scope of ICN.  It seems that the definition of ICN in this document narrows it pretty much to CCN/NDN.  What about NetInf, XIA, Mobility First?  I would say those do not really directly name content, the user name is indirect via (usually) hash transformations.  What about CBN or TagNet or Haggle?  If you want the document to be specific to CCN/NDN style protocols, I would just say that.

2) Again, very specific to CCN/NDN.  And even in CCN/NDN, not every packet is cryptographically signed, it can be indirectly signed or not cryptographically signed at all.  Also, if all packets need to be directly signed, why not just say “signed” as there’s no indirect….

3) Data naming: neither CCN or NDN requires that data be fragmented to network packet sizes.  They use a fragmentation layer.  Usually the fragmentation is not represented in the name (though Chris and I did a paper like that for secure fragment chains).  Even when segmentation is used, the segment number is not always a sequential number, sometimes a byte offset is used.

4) Data-centric security:  I think it is usually concerned with provenance not authentication.  Perhaps I’m confused on the exact cryptographic definitions of these terms.  I usually think of authentication as a more immediate proof of identity, as opposed to a historical assertion of identity.  I think one needs to discuss identity in this section.  Also, for non-self-certifying names one cannot assert the validity of data with out a trust model to the keys, can one?

5) Stateful forwarding: Again, very specific to CCN/NDN.

6) Data Packet paragraph (sec 3.1).  Does it need to be directly secured?  Must it be globally uniquely named, i.e. a GUID, or is that a desired feature or is that a side effect of including an implicit digest as part of the name?

7) Interest packet paragraph (sec 3.1): need to define name types (prefix, exact, full) outside this paragraph.

8) Data packet immutability (sec 3.1): I would clarify that it is immutable because it’s full name includes its digest.  It is not immutable because of some other mechanism, is it?

9) Sec 3.2, self-certifying name + packet Id paragraphs.  I think these do not clearly describe how self-certifying names are used in CCN/NDN.  A full name only exists as an explicit name in an Interest.  In all other situations, it is an implicit name constructed from a data’s exact name plus its cryptographic digest.

10) Sec 3.2 Segmentation paragraph: This might be confusing by saying “data packets” when in fact the packets do not map one-to-one to emitted PDUs due to fragmentation.

11) Sec 3.2 Versioning: it is a revision to the larger application content, not the content of a data packet.  You can have two data packets with different versions but same payload, it’s the larger series of segments that is versioned.

12) Sec 3.3 I’d call it provenance not authenticity throughout this section.

13) Section 3.3 Data confidentiality, I’d remove the “authorized consumers.”  Nothing here determines authorization.

14) Sec 3.3 ICN public key and ICN key owners and Trust model: I’m not certain that these paragraphs correctly describe the assertion of ownership of a private key and how that maps to identity and trust.  An implicit transformation may have issues with causality of identity assertion.  The proof of private key ownership is, as I understand it, a complex issue.  In the context of ICN, we are often concerned with a historical provenance where we only have indirect set of evidence of private key ownership.  I can’t put my finger on exactly what is striking me as off here, except that it seems to simplify these topics too much.

15) Sec 3.4 ICN Interface (face): I believe a “face” is usually used more like a socket, i.e. something that is associating a source and destination, whereas a network interface is usually just associating a source.  I think overloading “interface” to mean a source destination pair is confusing.

16) Sec 3.4 Data Mule: Does it need to be distance?  Can it not be just time?

17) Sec 3.5 ICn Routing plane: I don’t think in general they talk about data packet availability, but rather about name space reachability.

18) Sec 3.5 Satisfying an Interest: I consider this the predicate algebra of matching a data to an interest.  That is, Satisfying an Interest is the matching rules, not the reverse path forwarding.

19) Sec 3.5 FIB: I think the FIB points to next hops, not interfaces.  See prior comment #15 about ICN Interface.

Marc

On Nov 15, 2016, at 4:08 PM, Wissingh, B.F. (Bastiaan) <[email-masked]<mailto:[email-masked]>> wrote:

Hi Börje, all,

Best,
Bastiaan

Hi,

Börje

Hi All,

Best,
Bastiaan

---

From: "Wissingh, B.F. (Bastiaan)" <[email-masked]>
Date: Wed, 16 Nov 2016 01:51:37 +0000

Hi Marc,

Thanks for your comments! Regarding your first point Scope of ICN, we received that comment from a few others as well and have some ideas on that which I think is good to discuss during the F2F tomorrow.

Best,
Bastiaan

Van: "[email-masked]" <[email-masked]>
Datum: dinsdag 15 november 2016 17:40
Aan: Bastiaan Wissingh <[email-masked]>
CC: Borje Ohlman <[email-masked]>, "[email-masked]" <[email-masked]>
Onderwerp: Re: [icnrg] F2F Seoul for Terminology on 17th of November

Marc

Hi Börje, all,

Best,
Bastiaan

Börje

Hi All,

Best,
Bastiaan