Experimental Scenarios of Information-Centric Networking (ICN) Integration in 4G Mobile Networks
draft-irtf-icnrg-icn-lte-4g-12
Yes
Mallory Knodel
No Objection
Recuse
Note: This ballot was opened for revision 08 and is now closed.
Ballot question: "Is this draft ready for publication in the IRTF stream?"
Mallory Knodel
Yes
Spencer Dawkins
Yes
Comment
(2020-08-10 for -08)
Sent
Thanks for doing this work. I like it, and it's well-written. I have a couple of comments you might take into account. "Dual stack IP or ICN" seems to be an unfortunate choice of terms - "dual stack" is used to refer to "IP or ICN", but that's confusing, and even more confusing when it's used for "Dual stack IP (IPv4/IPv6) or ICN", which I guess should be read as nested "Dual stack (Dual stack (IP (IPv4/IPv6)) or ICN)", since both IPv4/IPv6 and the combination of IP or ICN are "dual stacks". Is there any other term you could use that wouldn't collide with a term that's been in wide use for at least 25 years (it's in https://tools.ietf.org/html/rfc1933)? This text LTE uses IP transport in its mobile backhaul (between eNodeB and core network). In case of provider-owned backhaul, it may not be necessary to implement any security mechanisms because the entire IP transport is owned by service provider. Deployment of security gateways and encryption might be necessary when IP transport is provided by other provider as shared media or leased lines. seems awfully optimistic in 2020. Even if true, I'd have concerns about saying it out loud - I was getting objections to similar text in the early 2000s. Fortunately, I think you can drop the second and third sentences with no lack of coherence, and no one with a 4G/LTE network is going to be reading this document to find out how to secure their IP networks, anyway. Do the right thing, of course.
Mat Ford
No Objection
Comment
(2020-08-17 for -08)
Sent
I have no objection to this document being published in the IRTF stream. I agree with others that the charter of the ICNRG may be due for an update to take account of the ICN-over-foo, uses of ICN and ICN applications work that is all underway now. I also agree that the audience for this document may be closer to 3GPP than the IETF, but there is quite some history of publishing 3GPP-related information in the IETF so again I don't see that as a big problem here (if the IRTF has an ICN research group, then (modulo charter update) ICN-over-foo research seems like fair game to me).
Mirja Kühlewind
No Objection
Comment
(2020-08-12 for -08)
Sent
I entered "no objection" as ballot position because I don't think there is any harm in publishing this document in the RFC series but looking at Lars' comment I wonder what the intend of the document is and if the RFC series is the right place to publish. I guess the question is who is the intended audience? I guess it's more for the 3GPP community to read than for the IETF/IRTF community as such it would make more sense to publish this information in one of their venues. Also, are people in 3GPP aware? And how is the relation of the content of this document to on-going effects in this space in 3GPP? Connected to this, I also looked at the charter and my reading is that it is mainly focused on comparing different approaches proposed in research. I believe the group went already far beyond that and maybe it's time to consider rechartering. I also wonder about this sentence in the abstract: "Multicast and broadcast technologies have recently emerged for mobile networks, but their deployments are very limited or at an experimental stage. " Isn't that also true for ICN? As such I find the motivation why ICN is beneficial in mobile networks rather weak... One more concrete comment: In section 3.2. you mention type of service (ToS). Please note that RFC1349 is obsoleted by RFC2474, therefore I recommend strongly to remove any notion of ToS from this document. However, I do find this section anyway rather weak as you say ICN is intended to solve this but then just say it needs further research. I'd potentially rather remove the whole section. And one minor comment: Maybe spell out TCO in section 3.4?
Lars Eggert
Recuse
Comment
(2020-08-11 for -08)
Sent
> Native Deployment of ICN in LTE, 4G Mobile Networks I don't quite understand why the IRTF (where the I is for Internet) should be publishing a document that describes how to deploy a non-Internet networking technology in another SDO's non-Internet architecture... Has 3GPP reviewed this document? Would they be surprised to see this published by the IRTF? s/IPSec/IPsec/g > This transport > convergence layer helps determine the type of transport (such as ICN > or IP), as well as the type of radio interface (LTE or WiFi or both) > used to send and receive traffic based on preference (e.g., content > location, content type, content publisher, congestion, cost, QoS). Where will this TCL come from and what are the incremental incentives for applications to move to it?
Shivan Sahib
Recuse
Comment
(2020-08-11 for -08)
Sent
Not an expert on ICN, but I looked at the new privacy considerations section (thanks for including it). There are several risks introduced specific to the deployment models as outlined in this section. Both the security and privacy sections end with "more research is needed". While this would always be true, it would be good to not punt these important discussions down the road too much - it would be great to see expansion of the points brought up; for e.g. "[ICNoICN scenario] ... forwarder in the path could be a potential risk for privacy attack" could be expanded more - what would this attack look like? How could it be mitigated? Can it be mitigated? Are there censorship and anonymity attacks possible for point 3? I'm also having trouble understanding some of the conclusions. For instance, "... a mere presence of the TCL does not present increased risk and vulnerability." But it does, right? If the TCL did not exist there wouldn't be any privacy risks related to ICN. Also, "introduction of TCL as a vehicle to implement ICN in LTE does not present additional privacy risk beyond issues already identified as they apply to ICN in general" - but now because of the deployments mentioned in this document those privacy risks would apply to LTE/4G as well. It's great that the point that privacy issues have a way of compounding rather than being additive seems to be well understood - it's worthwhile to examine the privacy risks not just from an ICN-specific point of view but also the privacy risks that are unique to the combination of ICN+4G/LTE.