Minutes IETF105: icnrg
minutes-105-icnrg-00

##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]