[icnrg] Comments on draft-zhang-icnrg-icniot-requirements

[David Oran <[e-mail]>]

<chair hat off>


- I don’t think this document contains requirements, nor should it. It should be re-titled and its content measured against a scope something like “design considerations in applying ICN approaches to the Internet of Things”.

- The initial section on IoT requirements could be considerably shortened and consist primarily of references to the very good literature describing the characteristics of IoT systems. Repeating all this here just bores the reader already familiar with the field. In fact, there is a tension between a solid research contribution and a tutorial document. In its current state, the material is very much tutorial in nature, and as such is not ideal for an ICNRG publication.

- detail: in section 2 2.9 ROLL is mischaracterized. While it is “tree-like, it permits multiple trees to be computed, which may be exactly what one may desire. It is unclear if the “rich communication patterns” talked about are at odds with multi-tree routing, and in fact one could argue that the communication patterns of IoT systems aren’t particularly rich at all!

- the division of the world into “infrastructure” and “ad hoc” mode is simplistic and doesn’t add guidance for any interesting research directions.

- The section on “Open API” adds no value. There is nothing specific to either IoT or ICN here

- The whole of section 3.2.1 is confused and this reviewer thinks many of the assertions are contrafactual. First of all, adopting the “overlay” terminology is quite unhelpful, as the term “overlay” tends to just mean realizing one kind of network on top of another kind of network (or an instance of the same kind of network). This obfuscates the many architectural tradeoffs about what functions get performed in what layers in a layered architecture. To just give one example, it is claimed that “the overlay approach cannot react to dynamic contextual changes in a timely fashion”. This is patently false, as has been shown many times where real networks violate the triangle inequality and an overlay in fact responds to changes faster than the underlay. Rather than belabor each of the points here please rethink the entire section.

- somewhere the DTN elephant-in-the-room needs to be covered. Some, but not all of the supposed advantages in section 4 can be achieved using DTN; others can be achieved without a wholesale shift to ICN.

- the section on caching/storage (5.3) is way to general and in desperate need of concrete examples

- section 5.7 on security and privacy are essentially tutorial and don’t provide much if any insight into an unusual or unique challenges. The claim that IoT-ICN introduces new threats is in fact falsified by the list of threats, none of which are in fact new.

- section 5.9 on communication reliability is just motherhood and adds no value. Either say something insightful or get rid of it.

- The sections on the individual vertical targets need review by experts in these areas. As it now stands the material is much too general to be of much value in guiding research or evaluating which of various ICN approaches work well for the corresponding use case.

——