notes-ietf-97-icnrg

Dirk: Short summary, in Berlin CCN and NDN team as well as interested companies working with those flavors got together to see what the comonalities and differences are. Discussions continued in bi-weekly confcalls. Outcome of discussions being documented, see corresponding link on ICNRG wiki page.

Marc giving a summary of what is currently in the draft and where to find it: https://github.com/icnrg/draft-icnrg-harmonization

Hitoshi: Can you support multiple flavors on same router? Like, if CCN packets arrives do x, if NDN packet arrives do y.

Marc: if you would have the two implementations at the same router, I'm not sure how that would work.

Lixia: what is the purpose of that?

Hitoshi: integrate ndn and ccn

Lixia: there is actually no product yet, harmonization is to understand difference in protocol not yet implementation

Marc: so that we can come up with common foundation

Hitoshi: sounds difficult, both already have implementation

Börje: for the way forward, usually we have an interim in Januari and then next IETF (with possible interim) in March. We could use those slots

Marc: would people like to have compiled version on Github?

Alex: compiled version is on github

== Contrace: Traceroute Facility for Content-Centric Network - Hitoshi Asaeda (20 min)

Hitoshi presenting slides

??: name_prifix mandatory option?

Hitoshi: Yes

??: then the text is a bit confusion, as mandatory does not seem to be an option, right?

Hitoshi: -p for name_prefix is an option. name_prefix itself is mandatory.

Mathias: -w does that mean router delays response?

Hitoshi: just an option, router could ignore

Mathias: to me this is not a good option, otherwise this can lead to dos attacks

Mathias: clarification, how does user know whether time synchronisation is enabled

Hitoshi: does not know

Mathias: according to what you present the user needs to know, otherwise hop-by-hop is not meaningful

Hitoshi: they do not need to know, it can be usefull

Mathias: a network measurement tool should only show numbers that are meaningful. If the user does not know whether time between nodes is synchronized, it is not meaningful

??: can we just use the roundtrip time? why do we need time synchronisation?

Hitoshi: requester calculates RTT between consumer and reply sender based on timestamp request sent and timestamp packet received.

??: it seems you are assuming that time is synchronized within network, which is not always the case. Hop-by-hop could be valueable but it needs to be correct.

Al Morton: maybe what's missing, is routers need to have some synchronisation to have synchronized timestamps

Hitoshi: I'll mention it in the revised draft.

Mathias: does your design support any check of security?

Hitoshi: hop-by-hop security is TBD. but there are already validation algorithm and validation payload defined in CCNx message format, which may help.

Mathias: there is another draft out there (cisco traceroute) that seems similiar, what is the difference with yours?

Hitoshi: more conceptual, do not specify detail metrics in the message.

Mathias: it is not only conception work, but also specify packet formats. but maybe no implementation

Mathias: could be helpful to have in depth comparison between drafts

Marc: this draft is more regarding finding content, while cisco draft is more of finding routers

Dirk: (chair-hat on) you will do anyway next version?

Hitoshi: yes

Dirk: (chair-hat off) does your work do 1-to-1 mapping between request and source. what is multiple sources?

Hitoshi: to me, multiple caches and/or multiple producers seems same

== RG documents status (5 min)

=== CCNx Messages in TLV Format: https://datatracker.ietf.org/doc/draft-irtf-icnrg-ccnxmessages/

=== CCNx Semantics: https://datatracker.ietf.org/doc/draft-irtf-icnrg-ccnxsemantics/

Marc presenting slides, documents on hold during harmonization. Expire december '16.

These are currently held up by the harmonization effort.

=== CCNx Content Object Chunking - Marc Mosko (5 min): https://datatracker.ietf.org/doc/draft-mosko-icnrg-ccnxchunking/

=== The CCNx URI Scheme - Marc Mosko (5 min): https://datatracker.ietf.org/doc/draft-mosko-icnrg-ccnxurischeme/

=== CCNx Key Exchange Protocol Version 1.0 - Marc Mosko (5 min): https://www.ietf.org/id/draft-wood-icnrg-ccnxkeyexchange-01.txt

Dirk: we are leaning towards adopting these documents. will take it to the mailinglist

== Individual drafts

=== Enabling Network Identifier (NI) in Information Centric Networks to Support Optimized Forwarding: https://www.ietf.org/internet-drafts/draft-azgin-icnrg-ni-00.txt - Ravi Ravindran (15 min)

Marc: do you think that the lookup/resolution service is going to operate on only names? Or also network identifiers?

Ravi: if you have something like this you need to have kind of publishing service.

Marc: but like the consumer at their house will need to go a resolver

Marc: for example in ndn name takes priority over network identifiers

Ravi: yes, names would be the starting point.

=== Summarize of the comments to the merged ICN-IoT requirements draft based on the feedback on the mailing list - Ravi Ravindran (10 min): https://tools.ietf.org/html/draft-zhang-icnrg-icniot-requirements-01. A new version of the draft will be produced based on the comments. The draft will also be reviewed by the T2TRG.

=== Terminology draft - Bastiaan Wissingh (10 min): https://github.com/icnrg/draft-irtf-icnrg-terminology

Baastiaan presented the slides giving background to and history of the terminology draft.

F2F meeting of terminology document group yesterday, Thursday. Broader scope of the document agreed, include more approaches. Volunteers wanted! Biweekly phoncalls. Update planned for Chicago meeting. Contact Bastiaan if you are interested.

== Wrap up, Next meetings - Chairs (10 min)

Regarding the harmonization work the hope is to have the difference document completed by the end of the year. Then the work on sorting out the difference could be started at the beginning of next year. By IETF in Chicago we should have a good idea of if harmonization seems feasible.

Future interim meetings. Possibly in January 2017 in Bay area, details TBD. Co-location proposals? Host offers welcome!

Next regular meeting: IETF98 Chicago, 26-31 March 2017, Probably a Sunday Interim.