Subject: [icnrg] Comments on draft-zhang-icnrg-icniot-00

From: "David Oran" <[email-masked]>
Date: Thu, 20 Apr 2017 11:41:11 -0400

First, with </chair hat on>

At the meeting in Chicago, a number of people in the audience 
volunteered to review this draft. As a reminder, if you volunteered (we 
don’t “take names” :-) ) please make some time to review and 
comment, as this is a weighty document covering a lot of ground. The 
chairs plan on making a decision on whether to adopt this as an RG 
document well in advance of the interim ICNRG meeting in Prague, so as 
many eyes on it as possible would be much appreciated.

Now, with </chair hat off>

After a fairly comprehensive review, my personal assessment is that this 
work is improved, but still has not reached sufficient maturity for the 
-00 draft to be adopted. It needs a lot more input, which we can do 
either before or after adoption as long as the ICNRG participants 
demonstrate sufficient interest in continuing to progress the work by 
providing review and new/revised text.

The following are my technical comments on the draft.

General:

- Given the discussions in ICNRG that led to re-positioning the work and 
combining the two earlier specs, we gave guidance to avoid 
characterizing the work as “requirements”. This has been mostly 
accomplished, but some scrubbing is still needed here and there. This 
should be easy - search for the word “requirement” and check all 
uses to see if they are appropriate to the new emphasis, and if not, 
reword. I picked out a few for which I had an easy fix, but there are a 
lot more I didn’t take the time to suggest how to change.

- I have pointed out some specific places where the document assumes 
it’s a good idea to have a “unified IoT platform” and talks about 
what one would contain. As a more general recommendation, I think we 
need to eliminate this terminology, as the word “platform” is 
over-used and often misused even for technical areas that are well 
understood. In contrast for IoT, and particularly IoT realized with ICN, 
it is way premature to be talking about a “unified IoT-ICN 
platform”.

- there are lots of places, especially in the early sections, where you 
make sweeping generalizations. Some of these just need to be toned down, 
but others have good material and justifications later in the document. 
For the latter, forward references would be really helpful to the reader 
(especially the skeptical reader).

- Looking forward, the author list will wind up having to be trimmed. I 
suggest moving the people not actively contributing now to an 
acknowledgements section.

Abstract:

- this spec does not “propose to build” anything (or at least, it 
shouldn’t). Suggest rewording to: To address this mismatch, an 
Information Centric Network (ICN) architecture can provide a common set 
of protocols and services, called “ICN-IoT” which can be used to 
build IoT platforms,

- get rid of “requirements” language: perhaps change sentence to 
“This draft summarizes general IoT demands, and covers the challenges 
and design considerations ICN faces to realize a unified ICN-IoT 
framework”

- the rest of the abstract is actually a guide through the spec, and 
belongs a bit later in the introduction, where it already appears. 
Better to delete it from the Abstract.

1-IoT Motivation

- delete “standalone” from the first sentence. It’s un-necessarily 
pejorative.

- I’m not sure it’s either achievable or desirable to to have  
single IoT “platform”. The web, for example, is not one single 
“platform”. I’m equally nervous about having “globally 
unified” as a goal. I think the goal is to have a standard, 
comprehensive, architecturally-coherent toolset out of which many 
different but interoperable IoT systems can be built.

- don’t give the impression that **all** IoT applications are 
information centric. Hedge bets by saying “many IoT applications…”

- if you want to use the work “mote” here, define it, but just 
saying “sensor” is probably adequate

- Might want to start a new paragraph with “”Taking a general IoT 
perspective…”

2-Motivating ICN for IoT

- s/content object level security/content object security/

- what is “contextual networking”? Wikipedia defines 
“Context-aware network”, if you want to use a term like this, add a 
reference

- s/whose requirements match the features/whose characteristics we argue 
match the features/

o-Smart Mobility

- it’s unlikely that it is in fact “well known” that IoT and ICN 
is a marriage made in heaven. Since you are introducing scenarios in 
this section, I think you need an introductory paragraph before diving 
into a reference-laden, acronym-heavy argument in favor of ICN. To 
start, you could mode the material at the bottom of the paragraph to the 
beginning.

- some of the material in here belongs elsewhere, for example “ICN can 
significantly magnify the effectiveness of IoT deployments, in terms of: 
energy efficiency and bandwidth usage [48] [70][71]; scalability [72]; 
and flexibility of the name scheme [82][83] “ these are things more 
general than the specific scenario of smart mobility.

- what are “travel-centric services”? I don’t think you mean 
Expedia or Travelocity.

o-Smart building

- general: the writing here has quite a few grammar and English usage 
errors. Have somebody go over and fix these as it’s quite hard to 
read. It also gets quite informal and discursive in the middle, with 
sentences like “Many industrial companies have been working on the 
topic.  Anyway, this is leading to a highly fragmented market,…”

-  not all buildings are “domestic environment”. In fact, it would 
be good to clearly separate commercial/industrial from residential.

- what do you mean by “minimizing the number of intervention 
requested”?

- If you’re going to say “Buildings account for a very relevant 
quota of energy consumption; if not optimized, such a quantity might 
become even higher than that used in industrial field.”, you need a 
reference or references to justify this. Otherwise leave it at 
“Buildings use a lot of energy”.

- “A unified ICN-IoT platform would inter-connect these systems 
through the Internet, thus enabling interaction with and between each 
other and taking decisions at an aggregated level”. You don’t need 
ICN to do this.

- Try to avoid proposing a single “IoT platform”, especially as a 
pre-condition for believing the rest of the analysis in the spec, as it 
is not going to happen.

o-Smart Grid

- “Data flow and information management is also very important to 
smart grids.” In what application in any domain is this not true?

- “data collected from different smart grids can be integrated” what 
is the boundary of a smart grid? What does ICN help compared to any 
reasonable application ontology?

- the assertion that the issues listed are hard to address in IP-based 
systems is not supported anywhere; it’s just asserted.

- “Smart grids require names and name resolution system that can 
enable networked control loops…” I don’t get the connection 
between name resolution and control loops - doesn’t any stable 
identifier work equally well for driving control loops?

- “Smart grids may use in-network caching to back up valuable data” 
- caches do not satisfy even the loosest expectations for data backup. I 
think you mean something different than what this sentence says.

- “In smart grids, we often rely on in-network computing to  increase 
the scalability and efficiency of the system, putting computation closer 
to the data sources.” Can you give an example here? Are you thinking 
of conventional process-control computations like PID controllers, which 
are typically done at a very low level by fixed or micro-controller 
hardware? If so, where does ICN fit in?

- “In smart grids, energy consumptions profiles should never be 
disclosed at a fine granularity as it can be used to violate user 
privacy.” This comes out of nowhere, since it only applies at the 
consumer/energy-distribution boundary. It may be better to not try to 
cover all of smart-grids in one use case, as up until this point of 
reading I was thinking of the systems that go from generation through 
distribution, which is where most of the literature on smart grids 
concentrates. This could be helped by an introductory paragraph scoping 
the boundaries of this use case, or explaining there are multiple 
related use cases.

0-Smart industry

- general: is this an accepted term of art, or did you make it up? Seems 
you’re talking about industrial automation. Since I’m not familiar 
with “Smart Industry 4.0”, a reference here seems pretty important.

- “The network need to support a mobile workforce in a smart 
industry…” where does this mobile thing come from? Seems totally 
orthogonal. In fact, given the hazardous environment of many of the 
targets of this use case, remote diagnosis and possibly even 
bypass/repair could be needed.

- There’s a lot of text here which can be summed up as “sending lots 
of data end-to-end is not the best way to do things”, but what does 
this have to do with IP?

- “When using ICN, naming of data is simpler than knowing the address 
of the node that stores that data” - for some things yes, for others, 
no. Naming the data doesn’t tell you which sensor is producing that 
faulty reading.

- “Possibility to get either local high-resolution data or remote 
low-resolution data (no need to store all data centrally, which is maybe 
not even possible due to large data volumes). - Good point, but how do 
you do this? Most people put applications out at the edge to do the 
summarization, which blurs the advantages of classic ICN caching.

3-IoT Architectural Requirements

- general: I think this section needs to be re-formulated a bit although 
I’m less worried about the “requirement” terminology here than in 
other places. If we can get rid of it without standing on out heads that 
would be good. Also, I’ll reiterate my nervousness about thinking we 
need a “unified IoT platform” as opposed to something looser.

3.1-Naming

- why is assigning names a “First step toward realizing…”. I would 
think name assignment is one of the **last** things you’d do, not one 
of the first, since it’s highly dependent on the selection of the 
management system, the design of individual applications, etc.

- some names, like those of information content, need to be persistent 
over against dynamic changes; others do not, like device names surviving 
device replacement for maintenance, change of ownership, or other 
lifecycle events.

- what do you mean by “names need to be secure”? isn’t it the 
binding of the names to the content that needs to be secure?

- the goal of semantic meaningfulness is somewhat at odds with the goal 
of privacy. You need a more nuanced statement here.

- saying “names should be able to help realize scalable IoT system 
architecture and high performance network platform” isn’t very 
helpful by itself - it devolves to apple pie and motherhood. You need to 
get at least one more level of detail here in order to give the reader 
some sense of what architectural characteristics actually matter in 
reaching this goal. Proper hierarchical decomposition? Short names in 
order to not use a lot of bandwidth on low capacity infrastructure? 
Constructed to make time-series data easy to recover/compute? etc. etc.

3.2-Security and Privacy

- saying “trust is hard, let’s go shopping” in the introductory 
sentence here isn’t very helpful. You need a forward reference here, 
and it would help to pull together the later trust discussions, which 
are spread around many sections, into a focused section later.

- “Privacy means that both the content and the context around IoT data 
need to be protected.” I don’t think that’s the definition of 
privacy.

- “These requirements will be driven by various stake holders such as 
industry, government,  consumers etc.” True, but does this statement 
belong here? All system characteristics have stakeholders.

- “or may contact the NCS to acquire public keys.” hides a lair of 
dragons, the issue isn’t who generates the public key, but that 
whoever generates the public also is in possession of the private key 
and can impersonate the principal. Also, I don’t follow why you are 
trying to define an NCS here - it is certainly a major and important 
deign discussion as to whether (assuming one exists) it is responsible 
for things like “publishes approved cryptographic suites, object 
categories and object description formats”

3.3 Scalability

- this section is ok in the sense it doesn’t say anything I disagree 
with, but it could be beefed up by discussing the key elements of 
scalability: object count, state*rate of updates, garbage collection, 
etc.

3.4-Resource constraints

- “as it has been shown that communications consume more power than 
other activities for embedded devices” need a reference here.

- in addition to the admonition against “complex signaling 
protocols” it’s important to say that idle chatter in the background 
to maintain connectivity or other volatile state is strongly 
discouraged.

- I get why “satellite or other space based devices” are latency 
problem, but why a jitter problem? Even polar low-orbit devices aren’t 
moving so fast as to induce much jitter.

3.5-Traffic characteristics

- this section is nicely argued
- s/is between/is among/

3.6-Contextual Communication

- s /shall rely/rely/, also why just “initiate communication” why 
not also maintain?, or terminate?

- some of the things you call “contexts” are quasi-static, like 
shared ownership, while others are dynamic, like shared location, or 
shared state space conditions, like bounds alarms. I think we should 
reserve the use of contexts for the latter, as the former is the domain 
of classic network/system management techniques. The danger is that with 
your loose classification, nearly anything could be called a context.

3.7- Handling mobility

- there may be a lot more to say about mobility. What’s here is fine, 
but could be beefed up considerably, perhaps this is another example 
where we really need forward references

3.8-Storage and caching

- I’m wondering if it would be better to separate storage and caching.

- “content caching may or may not be policy driven” - when is it 
*not* policy driven? I think the distinction not whether there is 
policy, but whether the policy is set by the application, the system 
administration, the network administration (if different), and how they 
interact.

- it is far from clear that pervasive caching “can greatly reduce the 
content access latencies”, at least compared to other caching 
strategies.

- I have no idea what “ICN allows resolution to replicated cached 
copies, it should also strive for the balance between content 
security/privacy and regulations considering application 
requirements.” means. Try again?

3.9-Communication reliability

- Seamless mobility is nice, but I don’t think you need to demand 
mobility be entirely seamless in the face of “extreme disruptions”. 
Applications and sensors may be more effectively designed with 
“fallback modes” to deal with such disruptions.

- While “QoS aware routing” would be very cool to have, I don’t 
think it’s a hard requirement for mission critical applications.

- What is an “IoT domain”?

3.10-Self Organization

- Good section. The piece missing is not talking about actuators as well 
as sensors.

3.11-Ad hoc  and Infrastructure mode

- good section

3.12- Unified Architecture

- I’m not sure this section says anything useful enough to stay 
around.

3.13-IoT Platform management

- s/Towards this new/Towards this, new/   s/IoTdeployment/IoT 
deployment/

- what does “ephemeral nature to save power” mean?

4-State of the Art

- here, where you say “unified” I think you mean “horizontal”

- you say the approaches are based on “Internet overlays”. Is this 
true? If so, what kind? Application proxies? VPNs? Something else?

- your reference [8] to mobility first is too diffuse - you need to have 
a more specific reference to the parts of the reference that talk about 
inefficiencies in IP.

- since this was all written, things like T2TRG and COAP have made 
progress and don’t pitch IP. We need to be more nuanced here than 
simply saying Silo=IP, unified/horizontal=ICN. Forward reference needed 
to section 4.2?

4.1-Silo IoT Architecture

- BACnet, while at the lower layers is device-oriented, also provides a 
rich schema/ontology for content and other information at higher layers. 
We need to be more nuanced here.

4.2-Application-Layer Unified IoT solutions

- not sure what you mean by “could be provided by many different 
devices thus  requiring a different design rationale.” from what? To 
what?

- actually, the “trust model” in IP is really no different from what 
one would have in ICN for IoT. Trust is in keys that are bound to names 
through certificates whose private keys are held by the principals of 
the system. What’s different is the channel model of security rather 
than the object model.

- I don’t buy that session establishment inherently is less efficient 
than request/response. For channel security you need messages to 
exchange session keys; for ICN you need messages to fetch object 
signing/encryption keys. Depending on how persistent the sessions are 
and lifetime of the keys (it’s easier to throw away session keys), I 
could show tradeoffs that favor either in terms of message 
transmissions/receptions. The important differences lie elsewhere.

- I also don’t buy this: “The problem is amplified with the number 
of nodes the constrained device has to  interact with because a secure 
session would have to be established with every node.” because the 
main resource constraint is the number of keys each device needs to 
maintain, not the number of sessions (which can be juggled as needed)

- on “resource constraints” - what’s the alternative that ICN 
makes possible here?

- on “traffic characteristics” - IP supports multicast, including 
application-layer multicast, so what’s the point here? I think there 
actually is one, which is that IP multicast sucks in many ways, not that 
IoT requires multicast and IP can’t do it.

- you say “overlay-based approach lacks self-organization, and thus 
does not provide efficient support for the ad-hoc mode of 
communication.” you need to be more nuanced here, as there **are** 
self-organizing overlay approaches, going all the way back to Paul 
Francis’ work on HOPS 20 years ago.

4.2.2-Suitability of Delay tolerant NNetworking

- I suspect the DTN community would at least somewhat object other 
statement that “The DTN architecture is however still host centric”. 
It’s message endpoint-centric, which is not exactly the same thing.

5-Advantages of using ICN for IoT

- In “naming of devices”, it seems you’ve got it backwards; it’s 
not that IP forces applications to name services and content. ICN does 
that too. It’s that IP forces you to name hosts too, and that gets in 
the way. In fact, for IoT naming of devices (i.e. hosts) is important 
too, since you have to manage the physical system that provides the 
services. For me the advantage is getting rid of the levels of 
indirection that add complexity and limit flexibility in routing, 
failover, and caching. The fact that a communication channel is needed 
in IP is of course a difference that may be a disadvantage, but I think 
you are confounding that by putting it in a section about naming. One 
can do ICN naming with a channel-oriented communication model, as in the 
Pursuit design.

- “ICN advocates the model of trust in content  rather than trust in 
network hosts.” And the keys that are the actual embodiment of the 
trust are stored where? On hosts. I think starting with the trust swamp 
here isn’t helpful. I think we’d do better starting from the 
proposition that ICN protects data at rest and data in motion the same 
way, which simplifies the system and arguably provides higher security.

6-ICN Design Considerations for IoT

- “IoT framework over IoT” - not clear it’s “over”. Maybe say 
instead  “…when adopting an ICN design for IoT applications and 
systems”

6.1- Naming devices, data and services

- in “size of data” bullet, s/it is infeasible for use/it may be 
infeasible/

- on “hash-based names”, it’s true the data has to exist to create 
the hash, but it is *not* true this requires a directory service - 
Manifests could be used just as easily.

- I don’t have a clear idea what you are saying with “Metadata-based 
content name: Relying on metadata allows to  generate a name for an 
object before it is created.  However this mechanism requires metadata 
matching semantics.” Try again?

- It’s not true that a chain of trust **must** be hierarchical. You 
say so explicitly: “hierarchical chain-of-trust to a root”. what 
about the web-of-trust alternatives? they may not be a good match for 
IoT, but you’re overstating the case here I think.

- the bullet on control/scoping opens an interesting discussion which I 
don’t think is well served by the existing text. It seems to imply 
that scoping is not useful, when in fact it only says that scoping is 
not useful for privacy. it would be helpful to actually talk about 
scoping more generally and make the point that relying on scoping for 
security/privacy has been shown to not work all that well for IP, and is 
unlikely to work well for ICN either. However, scoping may be useful to 
limit interest propagation, provide a simple means to attain 
context-sensitive communication, etc.

- the short bullet on Confidentiality of names is wholely inadequate. At 
the very least include some references to recent work.

6.2-Name Resolution

- We may have to go back and start over in this section, given the 
parallel discussions we’re having in ICNRG on name resolution, whether 
you need a “name resolution service”, etc. There’s good material 
in here, but I’d prefer to wait to suggest detailed changes until we 
make some progress on the broader issue.

6.3-Security and Privacy

- I’m pretty certain that security is crucial for all the IoT 
applications/use cases cited, but not at all convinced that privacy is 
required in all cases. some examples:
	- international funds transfers are often required by law to be public
	- some safety-critical applications may tip the balance against privacy 
in favor of other goals. For example, take your tire pressure use case. 
It may be that it’s better for everyone if tire pressure readings were 
not private in order to provide better safety enforcement on highways 
(e.g. not allow a car with low tire pressure to enter a high-speed 
freeway).

- I’ve pointed this out earlier, but it needs to be fixed here too: 
“ICN advocates the model of trust in content rather than trust in 
network hosts.” In both cases the trust is in keys, which are 
ultimately held by hosts. the rest is OK, since you then go into 
channel-versus-object security, which is the real difference.

- small point, but limiting session security to “secure the 
communication channel between a pair of nodes.” is inaccurate, since 
it doesn’t cover multicast with either broadcast or group keying.

- 1- “In general, we feel that security and privacy protection in IoT 
systems should mainly focus on the following aspects: confidentiality, 
integrity, authentication and non-repudiation, and availability.” 
Isn’t this true of **all** systems? What are you getting at here? 
Perhaps that you need to rethink these things rather than blindly 
adopting techniques that were developed for systems based on channel 
security? Example: even when you want semantics that are session-like 
(e.g. CCNxKeyExchange) you want to do keying independently of the two 
directions of communication, rather than binding a single session key to 
both directions of information flow, as would happen with TLS).

- “measures are impossible to be implemented in the constrained 
part.” Impossible? Hardly. Perhaps “impractical”?

- 1“Below we list several possible attacks to a name resolution 
service that is critical to ICN-IoT:” this prejudges that there is a 
name resolution service. I think this and the following can be reworded 
without direct invocation of an NRS. Might be better to start over and 
rewrite this though.

- “attempts to associate it with  A's own network address NA-A,” 
network address? Huh? We’re supposed to be gettiing rid of those :-) I 
think you’re wading into what ICN facility binds announced prefixes to 
delivery points - in the case of Ethernet, these are MAC addresses, not 
network addresses. In other scenarios they might be tunnel endpoint 
identifiers (e.g. RLOCs in LISP).

- 2-the “stale mapping” attack presumes there is a directly 
manipulate mapping, separate from announcements done by routing. This 
could be the case, but could also not be the case, especially in 
constrained environments with scoped broadcast might work better.

- 5- I think you have to do better here. In a pure pull-based system an 
attacker can only inject false data if interests are misrouted to him.

- what about authenticated denial and denial-of-existence attacks?

- the goal of privacy preservation in application servers represents a 
tradeoff with other security-relevant goals, like auditing. Presuming 
that we need privacy-preserving machine learning algorithms (which is 
still in the very early stages of research) is likely to be a bridge too 
far. It’s fine to (and a good idea I think) to discuss the possibloe 
mitigation strategies without requiring any particular one.

6.4-Caching/Storage

- as mentioned earlier, I think the exposition would work better if you 
separated caching and storage into separate sections. In general, I 
think this section could benefit from a lot more meat, as of now it 
seems to be very general and superficial.

- “The main challenge is to determine which nodes on the routing path 
should cache the data.” Really? it’s just one of many.

- I was surprised that you ignore the benefits of short-term caching as 
an error control technique. Isn’t this pretty important?

6.5-Routing and forwarding

- “forwarded based upon the locater  of the destination node” - you 
need to define the term “locator” here. It could mean some 
lower-layer address, or a topologically-meaningful name to routing, or a 
routing hint, or something else. while the general ICN routing research 
area investigates all of these, some may or may not be appropriate for 
IoT systems. The value here would be to delve into those issues, rather 
than regurgitate general ICN routing material. I was hoping to see some 
insight on this, and was disappointed that the document doesn’t 
provide anything helpful.

6.6-Mobility Management

- again, as with routing/forwarding, I didn’t see much of anything 
that was IoT specific. These are general arguments for ICN approaches to 
mobility, which are adequately described and argued for elsewhere.

- small point: you say “When a consumer moves to a new location after 
sending out the  request for Data, the Data may get lost”. Actually, 
the Data isn’t lost (as it might be in a pure channel-oriented 
architecture) - only the Data message as the response winds up in the 
wrong place.

- “To this end, flooding techniques could be used, but an intra-domain 
level  only, otherwise the network stability would be seriously 
impaired.” Stabiity? or just scalability/efficiency?

6.7-Contextual Communication

- There’s some good stuff here - Mobility First has lots of material 
on this, and references might help.

6.8-In-network Computing

- I don’t have anything to add here, but I think you should have 
Christian Tschudin help beef this section up.

6.9-Self Organization

- I’m not sure this section says enough to bother having.

6.10-Communications Reliability

- This is OK for what it is, but again it’s only loosely associated 
with the particulars of an IoT system. Needs to be more focused.

6.11-Resource Constraints and Heterogeneity

- The middle of this paragraph has good material, but it’s couched in 
terms of a particular design rather than as a description of possible 
approaches. Needs rewriting, and possibly the addition of alternatives 
to translation at the edge (e.g. use fingerprints and exploit the crypto 
to detect aliasing).

Do we need:

- a security consideration section? Perhaps a small section with 
pointers in order to not run into trouble with the powers that be if 
this gets to publication stage.
- a conclusion?
- more explicit comparison to T2TRG-style approaches?

——End of Comments——

DaveO

---

From: Marie-Jose Montpetit <[email-masked]>
Date: Thu, 20 Apr 2017 12:06:10 -0400

I was part of the original review of this document. I am still very un-satisfied with the current document. The document still fails to convince anyone of why you need ICN for most of the use cases proposed: they are well served with current commercially available solutions in IOT.  What an ICN implementation would bring is still very much un-defined and why and ICN implementation would be better than current ones even more fuzzy.

You have a detailed review that I think highlights some of the main issues of the document. But the overarching question is: is this document making a point or not for ICN and IOT. I would tend to say not or at least not yet.

mjm
> On Apr 20, 2017, at 11:41 AM, David Oran <[email-masked]> wrote:
> 
> At the meeting in Chicago, a number of people in the audience volunteered to review this draft. As a reminder, if you volunteered (we don’t “take names” :-) ) please make some time to review and comment, as this is a weighty document covering a lot of ground. The chairs plan on making a decision on whether to adopt this as an RG document well in advance of the interim ICNRG meeting in Prague, so as many eyes on it as possible would be much appreciated.
> 
> After a fairly comprehensive review, my personal assessment is that this work is improved, but still has not reached sufficient maturity for the -00 draft to be adopted. It needs a lot more input, which we can do either before or after adoption as long as the ICNRG participants demonstrate sufficient interest in continuing to progress the work by providing review and new/revised text.
> 
> Given the discussions in ICNRG that led to re-positioning the work and combining the two earlier specs, we gave guidance to avoid characterizing the work as “requirements”. This has been mostly accomplished, but some scrubbing is still needed here and there. This should be easy - search for the word “requirement” and check all uses to see if they are appropriate to the new emphasis, and if not, reword. I picked out a few for which I had an easy fix, but there are a lot more I didn’t take the time to suggest how to change.
> 
> I have pointed out some specific places where the document assumes it’s a good idea to have a “unified IoT platform” and talks about what one would contain. As a more general recommendation, I think we need to eliminate this terminology, as the word “platform” is over-used and often misused even for technical areas that are well understood. In contrast for IoT, and particularly IoT realized with ICN, it is way premature to be talking about a “unified IoT-ICN platform”.
> 
> there are lots of places, especially in the early sections, where you make sweeping generalizations. Some of these just need to be toned down, but others have good material and justifications later in the document. For the latter, forward references would be really helpful to the reader (especially the skeptical reader).
> 
> Looking forward, the author list will wind up having to be trimmed. I suggest moving the people not actively contributing now to an acknowledgements section.
> 
> Abstract:
> 
> this spec does not “propose to build” anything (or at least, it shouldn’t). Suggest rewording to: To address this mismatch, an Information Centric Network (ICN) architecture can provide a common set of protocols and services, called “ICN-IoT” which can be used to build IoT platforms,
> 
> get rid of “requirements” language: perhaps change sentence to “This draft summarizes general IoT demands, and covers the challenges and design considerations ICN faces to realize a unified ICN-IoT framework”
> 
> the rest of the abstract is actually a guide through the spec, and belongs a bit later in the introduction, where it already appears. Better to delete it from the Abstract.
> 
> 1-IoT Motivation
> 
> delete “standalone” from the first sentence. It’s un-necessarily pejorative.
> 
> I’m not sure it’s either achievable or desirable to to have single IoT “platform”. The web, for example, is not one single “platform”. I’m equally nervous about having “globally unified” as a goal. I think the goal is to have a standard, comprehensive, architecturally-coherent toolset out of which many different but interoperable IoT systems can be built.
> 
> don’t give the impression that all IoT applications are information centric. Hedge bets by saying “many IoT applications…”
> 
> if you want to use the work “mote” here, define it, but just saying “sensor” is probably adequate
> 
> Might want to start a new paragraph with “”Taking a general IoT perspective…”
> 
> 2-Motivating ICN for IoT
> 
> s/content object level security/content object security/
> 
> what is “contextual networking”? Wikipedia defines “Context-aware network”, if you want to use a term like this, add a reference
> 
> s/whose requirements match the features/whose characteristics we argue match the features/
> 
> o-Smart Mobility
> 
> it’s unlikely that it is in fact “well known” that IoT and ICN is a marriage made in heaven. Since you are introducing scenarios in this section, I think you need an introductory paragraph before diving into a reference-laden, acronym-heavy argument in favor of ICN. To start, you could mode the material at the bottom of the paragraph to the beginning.
> 
> some of the material in here belongs elsewhere, for example “ICN can significantly magnify the effectiveness of IoT deployments, in terms of: energy efficiency and bandwidth usage [48] [70][71]; scalability [72]; and flexibility of the name scheme [82][83] “ these are things more general than the specific scenario of smart mobility.
> 
> what are “travel-centric services”? I don’t think you mean Expedia or Travelocity.
> 
> o-Smart building
> 
> general: the writing here has quite a few grammar and English usage errors. Have somebody go over and fix these as it’s quite hard to read. It also gets quite informal and discursive in the middle, with sentences like “Many industrial companies have been working on the topic. Anyway, this is leading to a highly fragmented market,…”
> 
> not all buildings are “domestic environment”. In fact, it would be good to clearly separate commercial/industrial from residential.
> 
> what do you mean by “minimizing the number of intervention requested”?
> 
> If you’re going to say “Buildings account for a very relevant quota of energy consumption; if not optimized, such a quantity might become even higher than that used in industrial field.”, you need a reference or references to justify this. Otherwise leave it at “Buildings use a lot of energy”.
> 
> “A unified ICN-IoT platform would inter-connect these systems through the Internet, thus enabling interaction with and between each other and taking decisions at an aggregated level”. You don’t need ICN to do this.
> 
> Try to avoid proposing a single “IoT platform”, especially as a pre-condition for believing the rest of the analysis in the spec, as it is not going to happen.
> 
> o-Smart Grid
> 
> “Data flow and information management is also very important to smart grids.” In what application in any domain is this not true?
> 
> “data collected from different smart grids can be integrated” what is the boundary of a smart grid? What does ICN help compared to any reasonable application ontology?
> 
> the assertion that the issues listed are hard to address in IP-based systems is not supported anywhere; it’s just asserted.
> 
> “Smart grids require names and name resolution system that can enable networked control loops…” I don’t get the connection between name resolution and control loops - doesn’t any stable identifier work equally well for driving control loops?
> 
> “Smart grids may use in-network caching to back up valuable data” - caches do not satisfy even the loosest expectations for data backup. I think you mean something different than what this sentence says.
> 
> “In smart grids, we often rely on in-network computing to increase the scalability and efficiency of the system, putting computation closer to the data sources.” Can you give an example here? Are you thinking of conventional process-control computations like PID controllers, which are typically done at a very low level by fixed or micro-controller hardware? If so, where does ICN fit in?
> 
> “In smart grids, energy consumptions profiles should never be disclosed at a fine granularity as it can be used to violate user privacy.” This comes out of nowhere, since it only applies at the consumer/energy-distribution boundary. It may be better to not try to cover all of smart-grids in one use case, as up until this point of reading I was thinking of the systems that go from generation through distribution, which is where most of the literature on smart grids concentrates. This could be helped by an introductory paragraph scoping the boundaries of this use case, or explaining there are multiple related use cases.
> 
> 0-Smart industry
> 
> general: is this an accepted term of art, or did you make it up? Seems you’re talking about industrial automation. Since I’m not familiar with “Smart Industry 4.0”, a reference here seems pretty important.
> 
> “The network need to support a mobile workforce in a smart industry…” where does this mobile thing come from? Seems totally orthogonal. In fact, given the hazardous environment of many of the targets of this use case, remote diagnosis and possibly even bypass/repair could be needed.
> 
> There’s a lot of text here which can be summed up as “sending lots of data end-to-end is not the best way to do things”, but what does this have to do with IP?
> 
> “When using ICN, naming of data is simpler than knowing the address of the node that stores that data” - for some things yes, for others, no. Naming the data doesn’t tell you which sensor is producing that faulty reading.
> 
> “Possibility to get either local high-resolution data or remote low-resolution data (no need to store all data centrally, which is maybe not even possible due to large data volumes). - Good point, but how do you do this? Most people put applications out at the edge to do the summarization, which blurs the advantages of classic ICN caching.
> 
> general: I think this section needs to be re-formulated a bit although I’m less worried about the “requirement” terminology here than in other places. If we can get rid of it without standing on out heads that would be good. Also, I’ll reiterate my nervousness about thinking we need a “unified IoT platform” as opposed to something looser.
> 3.1-Naming
> 
> why is assigning names a “First step toward realizing…”. I would think name assignment is one of the last things you’d do, not one of the first, since it’s highly dependent on the selection of the management system, the design of individual applications, etc.
> 
> some names, like those of information content, need to be persistent over against dynamic changes; others do not, like device names surviving device replacement for maintenance, change of ownership, or other lifecycle events.
> 
> what do you mean by “names need to be secure”? isn’t it the binding of the names to the content that needs to be secure?
> 
> the goal of semantic meaningfulness is somewhat at odds with the goal of privacy. You need a more nuanced statement here.
> 
> saying “names should be able to help realize scalable IoT system architecture and high performance network platform” isn’t very helpful by itself - it devolves to apple pie and motherhood. You need to get at least one more level of detail here in order to give the reader some sense of what architectural characteristics actually matter in reaching this goal. Proper hierarchical decomposition? Short names in order to not use a lot of bandwidth on low capacity infrastructure? Constructed to make time-series data easy to recover/compute? etc. etc.
> 
> 3.2-Security and Privacy
> 
> saying “trust is hard, let’s go shopping” in the introductory sentence here isn’t very helpful. You need a forward reference here, and it would help to pull together the later trust discussions, which are spread around many sections, into a focused section later.
> 
> “Privacy means that both the content and the context around IoT data need to be protected.” I don’t think that’s the definition of privacy.
> 
> “These requirements will be driven by various stake holders such as industry, government, consumers etc.” True, but does this statement belong here? All system characteristics have stakeholders.
> 
> “or may contact the NCS to acquire public keys.” hides a lair of dragons, the issue isn’t who generates the public key, but that whoever generates the public also is in possession of the private key and can impersonate the principal. Also, I don’t follow why you are trying to define an NCS here - it is certainly a major and important deign discussion as to whether (assuming one exists) it is responsible for things like “publishes approved cryptographic suites, object categories and object description formats”
> 
> 3.3 Scalability
> 
> this section is ok in the sense it doesn’t say anything I disagree with, but it could be beefed up by discussing the key elements of scalability: object count, state*rate of updates, garbage collection, etc.
> 3.4-Resource constraints
> 
> “as it has been shown that communications consume more power than other activities for embedded devices” need a reference here.
> 
> in addition to the admonition against “complex signaling protocols” it’s important to say that idle chatter in the background to maintain connectivity or other volatile state is strongly discouraged.
> 
> I get why “satellite or other space based devices” are latency problem, but why a jitter problem? Even polar low-orbit devices aren’t moving so fast as to induce much jitter.
> 
> this section is nicely argued
> s/is between/is among/
> s /shall rely/rely/, also why just “initiate communication” why not also maintain?, or terminate?
> 
> some of the things you call “contexts” are quasi-static, like shared ownership, while others are dynamic, like shared location, or shared state space conditions, like bounds alarms. I think we should reserve the use of contexts for the latter, as the former is the domain of classic network/system management techniques. The danger is that with your loose classification, nearly anything could be called a context.
> 
> 3.7- Handling mobility
> 
> there may be a lot more to say about mobility. What’s here is fine, but could be beefed up considerably, perhaps this is another example where we really need forward references
> 3.8-Storage and caching
> 
> I’m wondering if it would be better to separate storage and caching.
> 
> “content caching may or may not be policy driven” - when is it not policy driven? I think the distinction not whether there is policy, but whether the policy is set by the application, the system administration, the network administration (if different), and how they interact.
> 
> it is far from clear that pervasive caching “can greatly reduce the content access latencies”, at least compared to other caching strategies.
> 
> I have no idea what “ICN allows resolution to replicated cached copies, it should also strive for the balance between content security/privacy and regulations considering application requirements.” means. Try again?
> 
> Seamless mobility is nice, but I don’t think you need to demand mobility be entirely seamless in the face of “extreme disruptions”. Applications and sensors may be more effectively designed with “fallback modes” to deal with such disruptions.
> 
> While “QoS aware routing” would be very cool to have, I don’t think it’s a hard requirement for mission critical applications.
> 
> What is an “IoT domain”?
> 
> 3.10-Self Organization
> 
> Good section. The piece missing is not talking about actuators as well as sensors.
> good section
> I’m not sure this section says anything useful enough to stay around.
> s/Towards this new/Towards this, new/ s/IoTdeployment/IoT deployment/
> 
> what does “ephemeral nature to save power” mean?
> 
> 4-State of the Art
> 
> here, where you say “unified” I think you mean “horizontal”
> 
> you say the approaches are based on “Internet overlays”. Is this true? If so, what kind? Application proxies? VPNs? Something else?
> 
> your reference [8] to mobility first is too diffuse - you need to have a more specific reference to the parts of the reference that talk about inefficiencies in IP.
> 
> since this was all written, things like T2TRG and COAP have made progress and don’t pitch IP. We need to be more nuanced here than simply saying Silo=IP, unified/horizontal=ICN. Forward reference needed to section 4.2?
> 
> BACnet, while at the lower layers is device-oriented, also provides a rich schema/ontology for content and other information at higher layers. We need to be more nuanced here.
> not sure what you mean by “could be provided by many different devices thus requiring a different design rationale.” from what? To what?
> 
> actually, the “trust model” in IP is really no different from what one would have in ICN for IoT. Trust is in keys that are bound to names through certificates whose private keys are held by the principals of the system. What’s different is the channel model of security rather than the object model.
> 
> I don’t buy that session establishment inherently is less efficient than request/response. For channel security you need messages to exchange session keys; for ICN you need messages to fetch object signing/encryption keys. Depending on how persistent the sessions are and lifetime of the keys (it’s easier to throw away session keys), I could show tradeoffs that favor either in terms of message transmissions/receptions. The important differences lie elsewhere.
> 
> I also don’t buy this: “The problem is amplified with the number of nodes the constrained device has to interact with because a secure session would have to be established with every node.” because the main resource constraint is the number of keys each device needs to maintain, not the number of sessions (which can be juggled as needed)
> 
> on “resource constraints” - what’s the alternative that ICN makes possible here?
> 
> on “traffic characteristics” - IP supports multicast, including application-layer multicast, so what’s the point here? I think there actually is one, which is that IP multicast sucks in many ways, not that IoT requires multicast and IP can’t do it.
> 
> you say “overlay-based approach lacks self-organization, and thus does not provide efficient support for the ad-hoc mode of communication.” you need to be more nuanced here, as there are self-organizing overlay approaches, going all the way back to Paul Francis’ work on HOPS 20 years ago.
> 
> I suspect the DTN community would at least somewhat object other statement that “The DTN architecture is however still host centric”. It’s message endpoint-centric, which is not exactly the same thing.
> In “naming of devices”, it seems you’ve got it backwards; it’s not that IP forces applications to name services and content. ICN does that too. It’s that IP forces you to name hosts too, and that gets in the way. In fact, for IoT naming of devices (i.e. hosts) is important too, since you have to manage the physical system that provides the services. For me the advantage is getting rid of the levels of indirection that add complexity and limit flexibility in routing, failover, and caching. The fact that a communication channel is needed in IP is of course a difference that may be a disadvantage, but I think you are confounding that by putting it in a section about naming. One can do ICN naming with a channel-oriented communication model, as in the Pursuit design.
> 
> “ICN advocates the model of trust in content rather than trust in network hosts.” And the keys that are the actual embodiment of the trust are stored where? On hosts. I think starting with the trust swamp here isn’t helpful. I think we’d do better starting from the proposition that ICN protects data at rest and data in motion the same way, which simplifies the system and arguably provides higher security.
> 
> “IoT framework over IoT” - not clear it’s “over”. Maybe say instead “…when adopting an ICN design for IoT applications and systems”
> in “size of data” bullet, s/it is infeasible for use/it may be infeasible/
> 
> on “hash-based names”, it’s true the data has to exist to create the hash, but it is not true this requires a directory service - Manifests could be used just as easily.
> 
> I don’t have a clear idea what you are saying with “Metadata-based content name: Relying on metadata allows to generate a name for an object before it is created. However this mechanism requires metadata matching semantics.” Try again?
> 
> It’s not true that a chain of trust must be hierarchical. You say so explicitly: “hierarchical chain-of-trust to a root”. what about the web-of-trust alternatives? they may not be a good match for IoT, but you’re overstating the case here I think.
> 
> the bullet on control/scoping opens an interesting discussion which I don’t think is well served by the existing text. It seems to imply that scoping is not useful, when in fact it only says that scoping is not useful for privacy. it would be helpful to actually talk about scoping more generally and make the point that relying on scoping for security/privacy has been shown to not work all that well for IP, and is unlikely to work well for ICN either. However, scoping may be useful to limit interest propagation, provide a simple means to attain context-sensitive communication, etc.
> 
> the short bullet on Confidentiality of names is wholely inadequate. At the very least include some references to recent work.
> 
> 6.2-Name Resolution
> 
> We may have to go back and start over in this section, given the parallel discussions we’re having in ICNRG on name resolution, whether you need a “name resolution service”, etc. There’s good material in here, but I’d prefer to wait to suggest detailed changes until we make some progress on the broader issue.
> 6.3-Security and Privacy
> 
> I’m pretty certain that security is crucial for all the IoT applications/use cases cited, but not at all convinced that privacy is required in all cases. some examples:
> 
> international funds transfers are often required by law to be public
> some safety-critical applications may tip the balance against privacy in favor of other goals. For example, take your tire pressure use case. It may be that it’s better for everyone if tire pressure readings were not private in order to provide better safety enforcement on highways (e.g. not allow a car with low tire pressure to enter a high-speed freeway).
> I’ve pointed this out earlier, but it needs to be fixed here too: “ICN advocates the model of trust in content rather than trust in network hosts.” In both cases the trust is in keys, which are ultimately held by hosts. the rest is OK, since you then go into channel-versus-object security, which is the real difference.
> 
> small point, but limiting session security to “secure the communication channel between a pair of nodes.” is inaccurate, since it doesn’t cover multicast with either broadcast or group keying.
> 
> 1- “In general, we feel that security and privacy protection in IoT systems should mainly focus on the following aspects: confidentiality, integrity, authentication and non-repudiation, and availability.” Isn’t this true of all systems? What are you getting at here? Perhaps that you need to rethink these things rather than blindly adopting techniques that were developed for systems based on channel security? Example: even when you want semantics that are session-like (e.g. CCNxKeyExchange) you want to do keying independently of the two directions of communication, rather than binding a single session key to both directions of information flow, as would happen with TLS).
> 
> “measures are impossible to be implemented in the constrained part.” Impossible? Hardly. Perhaps “impractical”?
> 
> 1“Below we list several possible attacks to a name resolution service that is critical to ICN-IoT:” this prejudges that there is a name resolution service. I think this and the following can be reworded without direct invocation of an NRS. Might be better to start over and rewrite this though.
> 
> “attempts to associate it with A's own network address NA-A,” network address? Huh? We’re supposed to be gettiing rid of those :-) I think you’re wading into what ICN facility binds announced prefixes to delivery points - in the case of Ethernet, these are MAC addresses, not network addresses. In other scenarios they might be tunnel endpoint identifiers (e.g. RLOCs in LISP).
> 
> 2-the “stale mapping” attack presumes there is a directly manipulate mapping, separate from announcements done by routing. This could be the case, but could also not be the case, especially in constrained environments with scoped broadcast might work better.
> 
> 5- I think you have to do better here. In a pure pull-based system an attacker can only inject false data if interests are misrouted to him.
> 
> what about authenticated denial and denial-of-existence attacks?
> 
> the goal of privacy preservation in application servers represents a tradeoff with other security-relevant goals, like auditing. Presuming that we need privacy-preserving machine learning algorithms (which is still in the very early stages of research) is likely to be a bridge too far. It’s fine to (and a good idea I think) to discuss the possibloe mitigation strategies without requiring any particular one.
> 
> 6.4-Caching/Storage
> 
> as mentioned earlier, I think the exposition would work better if you separated caching and storage into separate sections. In general, I think this section could benefit from a lot more meat, as of now it seems to be very general and superficial.
> 
> “The main challenge is to determine which nodes on the routing path should cache the data.” Really? it’s just one of many.
> 
> I was surprised that you ignore the benefits of short-term caching as an error control technique. Isn’t this pretty important?
> 
> “forwarded based upon the locater of the destination node” - you need to define the term “locator” here. It could mean some lower-layer address, or a topologically-meaningful name to routing, or a routing hint, or something else. while the general ICN routing research area investigates all of these, some may or may not be appropriate for IoT systems. The value here would be to delve into those issues, rather than regurgitate general ICN routing material. I was hoping to see some insight on this, and was disappointed that the document doesn’t provide anything helpful.
> 6.6-Mobility Management
> 
> again, as with routing/forwarding, I didn’t see much of anything that was IoT specific. These are general arguments for ICN approaches to mobility, which are adequately described and argued for elsewhere.
> 
> small point: you say “When a consumer moves to a new location after sending out the request for Data, the Data may get lost”. Actually, the Data isn’t lost (as it might be in a pure channel-oriented architecture) - only the Data message as the response winds up in the wrong place.
> 
> “To this end, flooding techniques could be used, but an intra-domain level only, otherwise the network stability would be seriously impaired.” Stabiity? or just scalability/efficiency?
> 
> There’s some good stuff here - Mobility First has lots of material on this, and references might help.
> 6.8-In-network Computing
> 
> I don’t have anything to add here, but I think you should have Christian Tschudin help beef this section up.
> 6.9-Self Organization
> 
> I’m not sure this section says enough to bother having.
> This is OK for what it is, but again it’s only loosely associated with the particulars of an IoT system. Needs to be more focused.
> The middle of this paragraph has good material, but it’s couched in terms of a particular design rather than as a description of possible approaches. Needs rewriting, and possibly the addition of alternatives to translation at the edge (e.g. use fingerprints and exploit the crypto to detect aliasing).
> Do we need:
> 
> a security consideration section? Perhaps a small section with pointers in order to not run into trouble with the powers that be if this gets to publication stage.
> a conclusion?
> more explicit comparison to T2TRG-style approaches?
> ——End of Comments——
> 
> DaveO
> 
> _______________________________________________
> icnrg mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/icnrg

---

From: Börje Ohlman <[email-masked]>
Date: Fri, 21 Apr 2017 07:52:46 +0000

Hi Marie-Jose,

Your main point, as I understand it, is that this document does not convince you that ICN is better than any current technology for IoT. My personal view is that that should not be the primary purpose of this document. I think the focus should be on what opportunities and challenges lies ahead if one (for whatever reason) would like to use ICN for IoT. If the document, as a side effect, would convince someone that ICN is the best way to do IoT I, again personally, think that would be great.

Börje

On 20 apr. 2017, at 18:06, Marie-Jose Montpetit <[email-masked]<mailto:[email-masked]>> wrote:

mjm
On Apr 20, 2017, at 11:41 AM, David Oran <[email-masked]<mailto:[email-masked]>> wrote:

General:

  *   Given the discussions in ICNRG that led to re-positioning the work and combining the two earlier specs, we gave guidance to avoid characterizing the work as “requirements”. This has been mostly accomplished, but some scrubbing is still needed here and there. This should be easy - search for the word “requirement” and check all uses to see if they are appropriate to the new emphasis, and if not, reword. I picked out a few for which I had an easy fix, but there are a lot more I didn’t take the time to suggest how to change.

  *   I have pointed out some specific places where the document assumes it’s a good idea to have a “unified IoT platform” and talks about what one would contain. As a more general recommendation, I think we need to eliminate this terminology, as the word “platform” is over-used and often misused even for technical areas that are well understood. In contrast for IoT, and particularly IoT realized with ICN, it is way premature to be talking about a “unified IoT-ICN platform”.

  *   there are lots of places, especially in the early sections, where you make sweeping generalizations. Some of these just need to be toned down, but others have good material and justifications later in the document. For the latter, forward references would be really helpful to the reader (especially the skeptical reader).

  *   Looking forward, the author list will wind up having to be trimmed. I suggest moving the people not actively contributing now to an acknowledgements section.

Abstract:

  *   this spec does not “propose to build” anything (or at least, it shouldn’t). Suggest rewording to: To address this mismatch, an Information Centric Network (ICN) architecture can provide a common set of protocols and services, called “ICN-IoT” which can be used to build IoT platforms,

  *   get rid of “requirements” language: perhaps change sentence to “This draft summarizes general IoT demands, and covers the challenges and design considerations ICN faces to realize a unified ICN-IoT framework”

  *   the rest of the abstract is actually a guide through the spec, and belongs a bit later in the introduction, where it already appears. Better to delete it from the Abstract.

1-IoT Motivation

  *   delete “standalone” from the first sentence. It’s un-necessarily pejorative.

  *   I’m not sure it’s either achievable or desirable to to have single IoT “platform”. The web, for example, is not one single “platform”. I’m equally nervous about having “globally unified” as a goal. I think the goal is to have a standard, comprehensive, architecturally-coherent toolset out of which many different but interoperable IoT systems can be built.

  *   don’t give the impression that all IoT applications are information centric. Hedge bets by saying “many IoT applications…”

  *   if you want to use the work “mote” here, define it, but just saying “sensor” is probably adequate

  *   Might want to start a new paragraph with “”Taking a general IoT perspective…”

2-Motivating ICN for IoT

  *   s/content object level security/content object security/

  *   what is “contextual networking”? Wikipedia defines “Context-aware network”, if you want to use a term like this, add a reference

  *   s/whose requirements match the features/whose characteristics we argue match the features/

o-Smart Mobility

  *   it’s unlikely that it is in fact “well known” that IoT and ICN is a marriage made in heaven. Since you are introducing scenarios in this section, I think you need an introductory paragraph before diving into a reference-laden, acronym-heavy argument in favor of ICN. To start, you could mode the material at the bottom of the paragraph to the beginning.

  *   some of the material in here belongs elsewhere, for example “ICN can significantly magnify the effectiveness of IoT deployments, in terms of: energy efficiency and bandwidth usage [48] [70][71]; scalability [72]; and flexibility of the name scheme [82][83] “ these are things more general than the specific scenario of smart mobility.

  *   what are “travel-centric services”? I don’t think you mean Expedia or Travelocity.

o-Smart building

  *   general: the writing here has quite a few grammar and English usage errors. Have somebody go over and fix these as it’s quite hard to read. It also gets quite informal and discursive in the middle, with sentences like “Many industrial companies have been working on the topic. Anyway, this is leading to a highly fragmented market,…”

  *   not all buildings are “domestic environment”. In fact, it would be good to clearly separate commercial/industrial from residential.

  *   what do you mean by “minimizing the number of intervention requested”?

  *   If you’re going to say “Buildings account for a very relevant quota of energy consumption; if not optimized, such a quantity might become even higher than that used in industrial field.”, you need a reference or references to justify this. Otherwise leave it at “Buildings use a lot of energy”.

  *   “A unified ICN-IoT platform would inter-connect these systems through the Internet, thus enabling interaction with and between each other and taking decisions at an aggregated level”. You don’t need ICN to do this.

  *   Try to avoid proposing a single “IoT platform”, especially as a pre-condition for believing the rest of the analysis in the spec, as it is not going to happen.

o-Smart Grid

  *   “Data flow and information management is also very important to smart grids.” In what application in any domain is this not true?

  *   “data collected from different smart grids can be integrated” what is the boundary of a smart grid? What does ICN help compared to any reasonable application ontology?

  *   the assertion that the issues listed are hard to address in IP-based systems is not supported anywhere; it’s just asserted.

  *   “Smart grids require names and name resolution system that can enable networked control loops…” I don’t get the connection between name resolution and control loops - doesn’t any stable identifier work equally well for driving control loops?

  *   “Smart grids may use in-network caching to back up valuable data” - caches do not satisfy even the loosest expectations for data backup. I think you mean something different than what this sentence says.

  *   “In smart grids, we often rely on in-network computing to increase the scalability and efficiency of the system, putting computation closer to the data sources.” Can you give an example here? Are you thinking of conventional process-control computations like PID controllers, which are typically done at a very low level by fixed or micro-controller hardware? If so, where does ICN fit in?

  *   “In smart grids, energy consumptions profiles should never be disclosed at a fine granularity as it can be used to violate user privacy.” This comes out of nowhere, since it only applies at the consumer/energy-distribution boundary. It may be better to not try to cover all of smart-grids in one use case, as up until this point of reading I was thinking of the systems that go from generation through distribution, which is where most of the literature on smart grids concentrates. This could be helped by an introductory paragraph scoping the boundaries of this use case, or explaining there are multiple related use cases.

0-Smart industry

  *   general: is this an accepted term of art, or did you make it up? Seems you’re talking about industrial automation. Since I’m not familiar with “Smart Industry 4.0”, a reference here seems pretty important.

  *   “The network need to support a mobile workforce in a smart industry…” where does this mobile thing come from? Seems totally orthogonal. In fact, given the hazardous environment of many of the targets of this use case, remote diagnosis and possibly even bypass/repair could be needed.

  *   There’s a lot of text here which can be summed up as “sending lots of data end-to-end is not the best way to do things”, but what does this have to do with IP?

  *   “When using ICN, naming of data is simpler than knowing the address of the node that stores that data” - for some things yes, for others, no. Naming the data doesn’t tell you which sensor is producing that faulty reading.

  *   “Possibility to get either local high-resolution data or remote low-resolution data (no need to store all data centrally, which is maybe not even possible due to large data volumes). - Good point, but how do you do this? Most people put applications out at the edge to do the summarization, which blurs the advantages of classic ICN caching.

  *   general: I think this section needs to be re-formulated a bit although I’m less worried about the “requirement” terminology here than in other places. If we can get rid of it without standing on out heads that would be good. Also, I’ll reiterate my nervousness about thinking we need a “unified IoT platform” as opposed to something looser.

3.1-Naming

  *   why is assigning names a “First step toward realizing…”. I would think name assignment is one of the last things you’d do, not one of the first, since it’s highly dependent on the selection of the management system, the design of individual applications, etc.

  *   some names, like those of information content, need to be persistent over against dynamic changes; others do not, like device names surviving device replacement for maintenance, change of ownership, or other lifecycle events.

  *   what do you mean by “names need to be secure”? isn’t it the binding of the names to the content that needs to be secure?

  *   the goal of semantic meaningfulness is somewhat at odds with the goal of privacy. You need a more nuanced statement here.

  *   saying “names should be able to help realize scalable IoT system architecture and high performance network platform” isn’t very helpful by itself - it devolves to apple pie and motherhood. You need to get at least one more level of detail here in order to give the reader some sense of what architectural characteristics actually matter in reaching this goal. Proper hierarchical decomposition? Short names in order to not use a lot of bandwidth on low capacity infrastructure? Constructed to make time-series data easy to recover/compute? etc. etc.

3.2-Security and Privacy

  *   saying “trust is hard, let’s go shopping” in the introductory sentence here isn’t very helpful. You need a forward reference here, and it would help to pull together the later trust discussions, which are spread around many sections, into a focused section later.

  *   “Privacy means that both the content and the context around IoT data need to be protected.” I don’t think that’s the definition of privacy.

  *   “These requirements will be driven by various stake holders such as industry, government, consumers etc.” True, but does this statement belong here? All system characteristics have stakeholders.

  *   “or may contact the NCS to acquire public keys.” hides a lair of dragons, the issue isn’t who generates the public key, but that whoever generates the public also is in possession of the private key and can impersonate the principal. Also, I don’t follow why you are trying to define an NCS here - it is certainly a major and important deign discussion as to whether (assuming one exists) it is responsible for things like “publishes approved cryptographic suites, object categories and object description formats”

3.3 Scalability

  *   this section is ok in the sense it doesn’t say anything I disagree with, but it could be beefed up by discussing the key elements of scalability: object count, state*rate of updates, garbage collection, etc.

3.4-Resource constraints

  *   “as it has been shown that communications consume more power than other activities for embedded devices” need a reference here.

  *   in addition to the admonition against “complex signaling protocols” it’s important to say that idle chatter in the background to maintain connectivity or other volatile state is strongly discouraged.

  *   I get why “satellite or other space based devices” are latency problem, but why a jitter problem? Even polar low-orbit devices aren’t moving so fast as to induce much jitter.

  *   this section is nicely argued
  *   s/is between/is among/

  *   s /shall rely/rely/, also why just “initiate communication” why not also maintain?, or terminate?

  *   some of the things you call “contexts” are quasi-static, like shared ownership, while others are dynamic, like shared location, or shared state space conditions, like bounds alarms. I think we should reserve the use of contexts for the latter, as the former is the domain of classic network/system management techniques. The danger is that with your loose classification, nearly anything could be called a context.

3.7- Handling mobility

  *   there may be a lot more to say about mobility. What’s here is fine, but could be beefed up considerably, perhaps this is another example where we really need forward references

3.8-Storage and caching

  *   I’m wondering if it would be better to separate storage and caching.

  *   “content caching may or may not be policy driven” - when is it not policy driven? I think the distinction not whether there is policy, but whether the policy is set by the application, the system administration, the network administration (if different), and how they interact.

  *   it is far from clear that pervasive caching “can greatly reduce the content access latencies”, at least compared to other caching strategies.

  *   I have no idea what “ICN allows resolution to replicated cached copies, it should also strive for the balance between content security/privacy and regulations considering application requirements.” means. Try again?

  *   Seamless mobility is nice, but I don’t think you need to demand mobility be entirely seamless in the face of “extreme disruptions”. Applications and sensors may be more effectively designed with “fallback modes” to deal with such disruptions.

  *   While “QoS aware routing” would be very cool to have, I don’t think it’s a hard requirement for mission critical applications.

  *   What is an “IoT domain”?

3.10-Self Organization

  *   Good section. The piece missing is not talking about actuators as well as sensors.

  *   good section

  *   I’m not sure this section says anything useful enough to stay around.

  *   s/Towards this new/Towards this, new/ s/IoTdeployment/IoT deployment/

  *   what does “ephemeral nature to save power” mean?

4-State of the Art

  *   here, where you say “unified” I think you mean “horizontal”

  *   you say the approaches are based on “Internet overlays”. Is this true? If so, what kind? Application proxies? VPNs? Something else?

  *   your reference [8] to mobility first is too diffuse - you need to have a more specific reference to the parts of the reference that talk about inefficiencies in IP.

  *   since this was all written, things like T2TRG and COAP have made progress and don’t pitch IP. We need to be more nuanced here than simply saying Silo=IP, unified/horizontal=ICN. Forward reference needed to section 4.2?

  *   BACnet, while at the lower layers is device-oriented, also provides a rich schema/ontology for content and other information at higher layers. We need to be more nuanced here.

  *   not sure what you mean by “could be provided by many different devices thus requiring a different design rationale.” from what? To what?

  *   actually, the “trust model” in IP is really no different from what one would have in ICN for IoT. Trust is in keys that are bound to names through certificates whose private keys are held by the principals of the system. What’s different is the channel model of security rather than the object model.

  *   I don’t buy that session establishment inherently is less efficient than request/response. For channel security you need messages to exchange session keys; for ICN you need messages to fetch object signing/encryption keys. Depending on how persistent the sessions are and lifetime of the keys (it’s easier to throw away session keys), I could show tradeoffs that favor either in terms of message transmissions/receptions. The important differences lie elsewhere.

  *   I also don’t buy this: “The problem is amplified with the number of nodes the constrained device has to interact with because a secure session would have to be established with every node.” because the main resource constraint is the number of keys each device needs to maintain, not the number of sessions (which can be juggled as needed)

  *   on “resource constraints” - what’s the alternative that ICN makes possible here?

  *   on “traffic characteristics” - IP supports multicast, including application-layer multicast, so what’s the point here? I think there actually is one, which is that IP multicast sucks in many ways, not that IoT requires multicast and IP can’t do it.

  *   you say “overlay-based approach lacks self-organization, and thus does not provide efficient support for the ad-hoc mode of communication.” you need to be more nuanced here, as there are self-organizing overlay approaches, going all the way back to Paul Francis’ work on HOPS 20 years ago.

  *   I suspect the DTN community would at least somewhat object other statement that “The DTN architecture is however still host centric”. It’s message endpoint-centric, which is not exactly the same thing.

  *   In “naming of devices”, it seems you’ve got it backwards; it’s not that IP forces applications to name services and content. ICN does that too. It’s that IP forces you to name hosts too, and that gets in the way. In fact, for IoT naming of devices (i.e. hosts) is important too, since you have to manage the physical system that provides the services. For me the advantage is getting rid of the levels of indirection that add complexity and limit flexibility in routing, failover, and caching. The fact that a communication channel is needed in IP is of course a difference that may be a disadvantage, but I think you are confounding that by putting it in a section about naming. One can do ICN naming with a channel-oriented communication model, as in the Pursuit design.

  *   “ICN advocates the model of trust in content rather than trust in network hosts.” And the keys that are the actual embodiment of the trust are stored where? On hosts. I think starting with the trust swamp here isn’t helpful. I think we’d do better starting from the proposition that ICN protects data at rest and data in motion the same way, which simplifies the system and arguably provides higher security.

  *   “IoT framework over IoT” - not clear it’s “over”. Maybe say instead “…when adopting an ICN design for IoT applications and systems”

  *   in “size of data” bullet, s/it is infeasible for use/it may be infeasible/

  *   on “hash-based names”, it’s true the data has to exist to create the hash, but it is not true this requires a directory service - Manifests could be used just as easily.

  *   I don’t have a clear idea what you are saying with “Metadata-based content name: Relying on metadata allows to generate a name for an object before it is created. However this mechanism requires metadata matching semantics.” Try again?

  *   It’s not true that a chain of trust must be hierarchical. You say so explicitly: “hierarchical chain-of-trust to a root”. what about the web-of-trust alternatives? they may not be a good match for IoT, but you’re overstating the case here I think.

  *   the bullet on control/scoping opens an interesting discussion which I don’t think is well served by the existing text. It seems to imply that scoping is not useful, when in fact it only says that scoping is not useful for privacy. it would be helpful to actually talk about scoping more generally and make the point that relying on scoping for security/privacy has been shown to not work all that well for IP, and is unlikely to work well for ICN either. However, scoping may be useful to limit interest propagation, provide a simple means to attain context-sensitive communication, etc.

  *   the short bullet on Confidentiality of names is wholely inadequate. At the very least include some references to recent work.

6.2-Name Resolution

  *   We may have to go back and start over in this section, given the parallel discussions we’re having in ICNRG on name resolution, whether you need a “name resolution service”, etc. There’s good material in here, but I’d prefer to wait to suggest detailed changes until we make some progress on the broader issue.

6.3-Security and Privacy

  *   I’m pretty certain that security is crucial for all the IoT applications/use cases cited, but not at all convinced that privacy is required in all cases. some examples:

     *   international funds transfers are often required by law to be public
     *   some safety-critical applications may tip the balance against privacy in favor of other goals. For example, take your tire pressure use case. It may be that it’s better for everyone if tire pressure readings were not private in order to provide better safety enforcement on highways (e.g. not allow a car with low tire pressure to enter a high-speed freeway).
  *   I’ve pointed this out earlier, but it needs to be fixed here too: “ICN advocates the model of trust in content rather than trust in network hosts.” In both cases the trust is in keys, which are ultimately held by hosts. the rest is OK, since you then go into channel-versus-object security, which is the real difference.

  *   small point, but limiting session security to “secure the communication channel between a pair of nodes.” is inaccurate, since it doesn’t cover multicast with either broadcast or group keying.

  *   1- “In general, we feel that security and privacy protection in IoT systems should mainly focus on the following aspects: confidentiality, integrity, authentication and non-repudiation, and availability.” Isn’t this true of all systems? What are you getting at here? Perhaps that you need to rethink these things rather than blindly adopting techniques that were developed for systems based on channel security? Example: even when you want semantics that are session-like (e.g. CCNxKeyExchange) you want to do keying independently of the two directions of communication, rather than binding a single session key to both directions of information flow, as would happen with TLS).

  *   “measures are impossible to be implemented in the constrained part.” Impossible? Hardly. Perhaps “impractical”?

  *   1“Below we list several possible attacks to a name resolution service that is critical to ICN-IoT:” this prejudges that there is a name resolution service. I think this and the following can be reworded without direct invocation of an NRS. Might be better to start over and rewrite this though.

  *   “attempts to associate it with A's own network address NA-A,” network address? Huh? We’re supposed to be gettiing rid of those :-) I think you’re wading into what ICN facility binds announced prefixes to delivery points - in the case of Ethernet, these are MAC addresses, not network addresses. In other scenarios they might be tunnel endpoint identifiers (e.g. RLOCs in LISP).

  *   2-the “stale mapping” attack presumes there is a directly manipulate mapping, separate from announcements done by routing. This could be the case, but could also not be the case, especially in constrained environments with scoped broadcast might work better.

  *   5- I think you have to do better here. In a pure pull-based system an attacker can only inject false data if interests are misrouted to him.

  *   what about authenticated denial and denial-of-existence attacks?

  *   the goal of privacy preservation in application servers represents a tradeoff with other security-relevant goals, like auditing. Presuming that we need privacy-preserving machine learning algorithms (which is still in the very early stages of research) is likely to be a bridge too far. It’s fine to (and a good idea I think) to discuss the possibloe mitigation strategies without requiring any particular one.

6.4-Caching/Storage

  *   as mentioned earlier, I think the exposition would work better if you separated caching and storage into separate sections. In general, I think this section could benefit from a lot more meat, as of now it seems to be very general and superficial.

  *   “The main challenge is to determine which nodes on the routing path should cache the data.” Really? it’s just one of many.

  *   I was surprised that you ignore the benefits of short-term caching as an error control technique. Isn’t this pretty important?

  *   “forwarded based upon the locater of the destination node” - you need to define the term “locator” here. It could mean some lower-layer address, or a topologically-meaningful name to routing, or a routing hint, or something else. while the general ICN routing research area investigates all of these, some may or may not be appropriate for IoT systems. The value here would be to delve into those issues, rather than regurgitate general ICN routing material. I was hoping to see some insight on this, and was disappointed that the document doesn’t provide anything helpful.

6.6-Mobility Management

  *   again, as with routing/forwarding, I didn’t see much of anything that was IoT specific. These are general arguments for ICN approaches to mobility, which are adequately described and argued for elsewhere.

  *   small point: you say “When a consumer moves to a new location after sending out the request for Data, the Data may get lost”. Actually, the Data isn’t lost (as it might be in a pure channel-oriented architecture) - only the Data message as the response winds up in the wrong place.

  *   “To this end, flooding techniques could be used, but an intra-domain level only, otherwise the network stability would be seriously impaired.” Stabiity? or just scalability/efficiency?

  *   There’s some good stuff here - Mobility First has lots of material on this, and references might help.

6.8-In-network Computing

  *   I don’t have anything to add here, but I think you should have Christian Tschudin help beef this section up.

6.9-Self Organization

  *   I’m not sure this section says enough to bother having.

  *   This is OK for what it is, but again it’s only loosely associated with the particulars of an IoT system. Needs to be more focused.

  *   The middle of this paragraph has good material, but it’s couched in terms of a particular design rather than as a description of possible approaches. Needs rewriting, and possibly the addition of alternatives to translation at the edge (e.g. use fingerprints and exploit the crypto to detect aliasing).

Do we need:

  *   a security consideration section? Perhaps a small section with pointers in order to not run into trouble with the powers that be if this gets to publication stage.
  *   a conclusion?
  *   more explicit comparison to T2TRG-style approaches?

——End of Comments——

DaveO

_______________________________________________
icnrg mailing list
[email-masked]<mailto:[email-masked]>
https://www.irtf.org/mailman/listinfo/icnrg

_______________________________________________
icnrg mailing list
[email-masked]<mailto:[email-masked]>
https://www.irtf.org/mailman/listinfo/icnrg

---

From: Börje Ohlman <[email-masked]>
Date: Fri, 21 Apr 2017 07:59:44 +0000

</chair hat on>

Dave,
Thanks for your thorough review.

Authors,
As you now got quite a few comments it would be great if someone could commit to do a quick update based on these comments before further reviews are done, to avoid having the same comments multiple times. This is of course assuming that you agree with the comments, otherwise it is better to await further, possibly different comments.

Reviewers,
Can those that have plans to review this document let us know, so we know which reviews we (the chairs) should wait on before we decide on how to proceed with the document.

Börje

On 20 apr. 2017, at 17:41, David Oran <[email-masked]<mailto:[email-masked]>> wrote:

General:

Abstract:

1-IoT Motivation

2-Motivating ICN for IoT

o-Smart Mobility

o-Smart building

o-Smart Grid

0-Smart industry

3.1-Naming

3.2-Security and Privacy

3.3 Scalability

3.4-Resource constraints

3.7- Handling mobility

3.8-Storage and caching

3.10-Self Organization

  *   good section

4-State of the Art

6.2-Name Resolution

6.3-Security and Privacy

6.4-Caching/Storage

6.6-Mobility Management

6.8-In-network Computing

6.9-Self Organization

Do we need:

——End of Comments——

DaveO

---

From: Marie-Jose Montpetit <[email-masked]>
Date: Fri, 21 Apr 2017 08:07:51 -0400

Sorry to be a bit direct. Essentially what you say is that this document is about a potential new solution to an existing resolved problem. Can’t we look for problems and research that address problems that are uniquely solved by ICNs? If not why use them?

mjm

> On Apr 21, 2017, at 3:52 AM, Börje Ohlman <[email-masked]> wrote:
> 
> Hi Marie-Jose,
> 
>> On 20 apr. 2017, at 18:06, Marie-Jose Montpetit <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>>> On Apr 20, 2017, at 11:41 AM, David Oran <[email-masked] <mailto:[email-masked]>> wrote:
>>> 
>>> [email-masked] <mailto:[email-masked]>
>>> https://www.irtf.org/mailman/listinfo/icnrg <https://www.irtf.org/mailman/listinfo/icnrg>
>> 
>> [email-masked] <mailto:[email-masked]>

---

From: Ravi Ravindran <[email-masked]>
Date: Fri, 21 Apr 2017 18:10:46 +0000

Dave, thanks for the detailed review and comments.

Borje, sure we will post a revised draft addressing these comments. Considering the detailed review, I think it would be also be worthwhile to share a document on how these comments have been addressed, and if we have alternate views on this.  However, while we work on them,  if other reviewers can also provide their comments, that would be nice.

Regards,
Ravi

From: icnrg [mailto:[email-masked]] On Behalf Of Börje Ohlman
Sent: Friday, April 21, 2017 1:00 AM
To: David R Oran <[email-masked]>
Cc: icnrg <[email-masked]>
Subject: Re: [icnrg] Comments on draft-zhang-icnrg-icniot-00

</chair hat on>

Dave,

Authors,

Reviewers,

Börje

  *   good section

---

From: Ravi Ravindran <[email-masked]>
Date: Fri, 21 Apr 2017 18:16:16 +0000

Hi MJM,

We have Section 4 to exactly address your point on the inefficiencies of the current solutions, and Section 5 on why ICN would be a better candidate before we discuss the challenges and design considerations. It would be nice if you can provide more specific comments on these sections, and help us improve it.

Regards,
Ravi

From: icnrg [mailto:[email-masked]] On Behalf Of Marie-Jose Montpetit
Sent: Thursday, April 20, 2017 9:06 AM
To: David Oran <[email-masked]>
Cc: icnrg <[email-masked]>; Alessandro Bassi <[email-masked]>
Subject: Re: [icnrg] Comments on draft-zhang-icnrg-icniot-00

mjm

  *   good section