##Minutes of ICRNG @ IETF 105, Tuesday July 22, 2019## Names Abbreviations: DT - Dirk Trossen JS - Jan Seedorf DK - Dirk Kutscher JW - John Wroclawski ES - Eve Schooler MMcC - Michael McCool DO - Dave Oran MM - Marc Mosko JH - Jungha Hong BO - Börje Ohlman KS - Karen Sollins 'ICN over 5G’ Document Link: https://datatracker.ietf.org/doc/draft-ravi-icnrg-5gc-icn/ Slides Link: https://datatracker.ietf.org/doc/slides-105-icnrg-ip-based-services-over-icn-in-5g-lan-environments/00/ Presenter: Dirk Trossen JS: 5G standardisation is still ongoing. Do you expect this to be a living doc until 5G standardisation is completed? DT: Yes, it will have to be a living doc and be updated as we go along. It's a moving target at the moment JS: Any relation of this draft to 3GPP? DT: we focused on the baseline LAN communication for now. Will have to be updated later. DK: This is useful output from this group, as it highlights relation of ICN to 5G. DK: Objections to adopting this draft? (None) Generally positive and will carry on. ‘IP-over-ICN-5GLAN’ Document Link: https://datatracker.ietf.org/doc/draft-trossen-icnrg-ip-icn-5glan/ Slides Link: https://datatracker.ietf.org/doc/slides-105-icnrg-ip-based-services-over-icn-in-5g-lan-environments/00/ Presenter: Dirk Trossen DT: Content of this has been presented before, but there hasn't been a draft before. JW: Is this for IP-based services or for services that run over IP? DT: Yes, it is for IP-based services ES: The name of the draft is misleading. DT: Noted, will do. JW: I would stick with HTTP-based services. Outside this room, people will understand better HTTP DT: It makes sense. JS: we had a paper in the ICN conference (ref inserted by DO: https://conferences.sigcomm.org/acm-icn/2014/papers/p87.pdf). Lots of things we have in the Internet today are difficult to do over ICN. DT: I'm aware of the paper. MMcC: Are you doing HTTPS? Or micro-services? As an extra use-case, could you do CoAP? DT: We have a separate draft in the COIN RG in Thursday, where we do micro-services, where we deliver micro-services over this technology DK (message from chairs): How to do web over ICN - that's an interesting and important thing to address in this group. Update to the CCNinfo draft Document Link: https://datatracker.ietf.org/doc/draft-irtf-icnrg-ccninfo/ Slides Link: https://datatracker.ietf.org/meeting/105/materials/slides-105-icnrg-ccninfo-discovering-content-and-network-information-in-content-centric-networks-00 Presenter: Hitoshi Asaeda DO: Very important work - needs more eyes in the room to get feedback. How do you continue to achieve flow balance with a scheme like this? Is work like this promoting work on path steering and multipath? JS: In the IP world there are many caches and the DNS has to decide where to send you. How does this relate to ICN in terms of security? Who decides where to forward the request to? In this case, do you trust the ISP to do this? DO: You have to trust the router owners to handle this, although ISPs can lie. DO: It was easy in NDN to do cache exploration. Whatever we do, we should not bring this back and allow cache exploration via CCInfo to compromise privacy. In ICN a cache should never return something that the producer wouldn't. JS: If the ISP wants, they can just drop it and not reply. DO: this is not a good idea. Similarly it was a bad idea for ISPs to drop traceroute requests. This makes bug fixing much more difficult. DK: now that we got the CCNx drafts out, it's good to focus on tooling. ICNLoWPAN: Ready for RG Last Call? Document Link: https://datatracker.ietf.org/doc/draft-irtf-icnrg-icnlowpan/ Slides Link: https://datatracker.ietf.org/doc/slides-105-icnrg-icn-lowpan/00/ Presenter - Thomas Schmidth (was: Cenk Gündoğan) JS: Floating point encoding has traditionally been difficult. TS: The situation is similar here. If you miss the checksum, you have to redo it. JS: If there was a gateway in the middle, you would miss this information. TS: The information is not lost. DO: there is an IANA registry, which you can make use of, e.g., chunk number. MM: when we did the compression for the CCNx before, we used a dictionary approach, where you use state from the hope before (stateful approach). This way I was able to combine the number of bits with the type. TS: There is enough compression the way we do it, but need to see alternatives. MMcC: we had a discussion in the 6LoWPAN group and we had IPv6 addresses with prefixes. This way you would add prefixes to names. DK: this is very nice work that shows the benefits of ICN in constrained environments and in 6LoWPAN environments, where ICN really makes a difference. Karen to comment on the document, but would be really nice to have more people looking into this. NRS documents: Ready for RG Last Call? Document Link: https://datatracker.ietf.org/doc/draft-irtf-icnrg-nrs-requirements/ Document Link: https://datatracker.ietf.org/doc/draft-irtf-icnrg-nrsarch-considerations/ Slides Link: https://datatracker.ietf.org/doc/slides-105-icnrg-updates-on-nrs-documents/00/ Presenter: Jungha Hong MM: My understanding is that resolution can be done based on the prefix Jungha: We didnt assume any specific type of name. Any type of name you can register and depending how you use it, it can mean different things. Marc Mosko: In the interim meeting we discussed about the idea of giving a name and some extra info on the services we want to access. Will you consider putting something similar to your version of the NRS and the document? This is a name to a name resolution, as opposed to a name to locator Karen Sollins: ++? JH: We tried to include all types of name resolution and tried not to dive too deep intentionally in order not to be restrictive. We tried to avoid talking about a very specific system or type of systems system. DT: It would be good to honour those two different approaches (name-based routing and name-resolution based routing). Question was: ?+? BO: The way these drafts are written is that they’re non-restrictive. KS: Especially in MobilityFirst, there are different types of resolution. You need to have one name that is globally resolvable and then once you choose the resolution system based on the name, you go with that. BO: there is a difference between name resolution system and name resolution service. [End of Meeting]