Subject: Re: [icnrg] I-D Action: draft-irtf-icnrg-icniot-00.txt

From: Marie-Jose Montpetit <[email-masked]>
Date: Thu, 11 Jan 2018 09:58:58 -0500

I will sound like the eponymic broken record but I have the impression that some of the issues I raised with this document in the past have not been addressed.

It is still not clear to me why we need a unified ICN-based architecture for all IoT applications. I actually see the power of ICN in IoT as completely the opposite: giving the opportunity to create application(infomation)-specific solutions that move away from the current conundrum of web based solutions and are thus tailored not unified. 

Actually the document still does not make a good case for that unified architecture. The document still has the “architecture looking for a problem” flavor that I pushed back against in the past. 

mjm

> Begin forwarded message:
> 
> From: [email-masked] <mailto:[email-masked]>
> Subject: [icnrg] I-D Action: draft-irtf-icnrg-icniot-00.txt
> Date: January 5, 2018 at 1:44:54 PM EST
> To: <[email-masked] <mailto:[email-masked]>>
> Cc: [email-masked] <mailto:[email-masked]>
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Information-Centric Networking RG of the IRTF.
> 
>        Title           : Design Considerations for Applying ICN to IoT
>        Authors         : Ravishankar Ravindran
>                          Prof.Yanyong Zhang
>                          Prof. Luigi Alfredo Grieco
>                          Anders Lindgren
>                          Prof. Dipankar Raychadhuri
>                          Prof. Emmanuel Baccelli
>                          Jeff Burke
>                          Guoqiang Wang
>                          Bengt Ahlgren
>                          Olov Schelen
> 	Filename        : draft-irtf-icnrg-icniot-00.txt
> 	Pages           : 50
> 	Date            : 2018-01-05
> 
> Abstract:
>   The Internet of Things (IoT) promises to connect billions of objects
>   to the Internet.  After deploying many stand-alone IoT systems in
>   different domains, the current trend is to develop a common, "thin
>   waist" of protocols over a horizontal unified, defragmented IoT
>   architecture.  Such an architecture will make objects accessible to
>   applications across organizations and domains.  Towards this goal,
>   quite a few proposals have been made to build an application-layer
>   based unified IoT platform on top of today's host-centric Internet.
>   However, there is a fundamental mismatch between the host-centric
>   nature of todays Internet and mostly information-centric nature of
>   the IoT system.  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.
>   ICN-IoT leverages the salient features of ICN, and thus provides
>   naming, security, mobility support,scalability, and efficient content
>   and service delivery.
> 
>   This draft summarizes general IoT demands, and covers the challenges
>   and design considerations ICN faces to realize a ICN-IoT framework
>   based on ICN architecture.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-irtf-icnrg-icniot/ <https://datatracker.ietf.org/doc/draft-irtf-icnrg-icniot/>
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-irtf-icnrg-icniot-00 <https://tools.ietf.org/html/draft-irtf-icnrg-icniot-00>
> https://datatracker.ietf.org/doc/html/draft-irtf-icnrg-icniot-00 <https://datatracker.ietf.org/doc/html/draft-irtf-icnrg-icniot-00>
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> _______________________________________________
> icnrg mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/icnrg

---

From: "David Oran" <[email-masked]>
Date: Thu, 11 Jan 2018 10:08:27 -0500

On 11 Jan 2018, at 9:58, Marie-Jose Montpetit wrote:

> I will sound like the eponymic broken record but I have the impression 
> that some of the issues I raised with this document in the past have 
> not been addressed.
>
Then post them again.

> It is still not clear to me why we need a unified ICN-based 
> architecture for all IoT applications.
We don’t, which is why the chairs worked hard to have the authors 
re-write/re-position the document as “design considerations”. 
Clearly we didn’t do a thorough enough job.

> I actually see the power of ICN in IoT as completely the opposite: 
> giving the opportunity to create application(infomation)-specific 
> solutions that move away from the current conundrum of web based 
> solutions and are thus tailored not unified.
>
Maybe. There is still the quesion of not re-inventing everything for 
each application and having common elements (perhaps just as application 
layer libraries). For example, there are only a few interaction 
paradigms (polling, phone-home, etc.) and a few state-transfer paradigms 
(idempotent, monotonic, etc.) which can be done right once and then 
re-used. Similarly, for many security-related issues, allowing each 
application to roll its own is a really bad idea. That’s why things 
like the trust-schema stuff based on name matching are so important.

> Actually the document still does not make a good case for that unified 
> architecture. The document still has the “architecture looking for a 
> problem” flavor that I pushed back against in the past.
>
To the extent it still reads as a unified architecture position paper I 
agree entirely. I guess I’ll have to go back and look again to get it 
fixed (or find somebody else to do it).

>> https://datatracker.ietf.org/doc/draft-irtf-icnrg-icniot/ 
>> <https://datatracker.ietf.org/doc/draft-irtf-icnrg-icniot/>
>>
>> https://tools.ietf.org/html/draft-irtf-icnrg-icniot-00 
>> <https://tools.ietf.org/html/draft-irtf-icnrg-icniot-00>
>> https://datatracker.ietf.org/doc/html/draft-irtf-icnrg-icniot-00 
>> <https://datatracker.ietf.org/doc/html/draft-irtf-icnrg-icniot-00>
>>
>>

DaveO

---

From: Marie-Jose Montpetit <[email-masked]>
Date: Thu, 11 Jan 2018 10:16:37 -0500

See inline.
> On Jan 11, 2018, at 10:08 AM, David Oran <[email-masked]> wrote:
> 
Need to look through my mail archive :) 
> 
>> It is still not clear to me why we need a unified ICN-based architecture for all IoT applications.
> We don’t, which is why the chairs worked hard to have the authors re-write/re-position the document as “design considerations”. Clearly we didn’t do a thorough enough job.
I would not comment on your job but on the premise of the document to start with.
> 
>> I actually see the power of ICN in IoT as completely the opposite: giving the opportunity to create application(infomation)-specific solutions that move away from the current conundrum of web based solutions and are thus tailored not unified.
>> 
> Maybe. There is still the quesion of not re-inventing everything for each application and having common elements (perhaps just as application layer libraries). For example, there are only a few interaction paradigms (polling, phone-home, etc.) and a few state-transfer paradigms (idempotent, monotonic, etc.) which can be done right once and then re-used. Similarly, for many security-related issues, allowing each application to roll its own is a really bad idea. That’s why things like the trust-schema stuff based on name matching are so important.
I am all for "common toolkits" from which you can craft an architecture and I have supported such efforts in other groups. But I think the document mixes the need for some common librairies and APIs to perform basic operations with “unified architecture”. 
> To the extent it still reads as a unified architecture position paper I agree entirely. I guess I’ll have to go back and look again to get it fixed (or find somebody else to do it).
And have other IoT experts chime in?

mjm

---

From: Ravi Ravindran <[email-masked]>
Date: Thu, 11 Jan 2018 19:39:59 +0000

Hi MJM,

Please see for my comments inline.

Regards,
Ravi

From: icnrg [mailto:[email-masked]] On Behalf Of Marie-Jose Montpetit
Sent: Thursday, January 11, 2018 6:59 AM
To: icnrg <[email-masked]>
Cc: Alessandro Bassi <[email-masked]>
Subject: Re: [icnrg] I-D Action: draft-irtf-icnrg-icniot-00.txt

Ravi > As Dave mentioned, please do resend your specific concerns for us to address.

Ravi > If there is anything unified this draft should discuss, it should be about the ICN network layer which offers features like name-based APIs, security, in-network computing, caching etc. This flexibility allows one to build efficient middleware components and architect the services based on their individual needs, one of the reasons why we motivate ICN-IoT applications in the initial part of the draft. So at some point if it implies otherwise, please point out and we will address that.

We do discuss about application level unified architecture in the current state-of-art section, which is required to make the sensors, gateways, IoT servers etc. inter-operate with one another, but not a  requirement for heterogeneous ICN-IoT applications to interact with one another.

mjm

Begin forwarded message:

From: [email-masked]<mailto:[email-masked]>
Subject: [icnrg] I-D Action: draft-irtf-icnrg-icniot-00.txt
Date: January 5, 2018 at 1:44:54 PM EST
To: <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>

Abstract:

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org>.

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

---

From: Alessandro Bassi <[email-masked]>
Date: Thu, 11 Jan 2018 23:18:42 +0100

Hi Ravi, (and, Marie-Jo, David)

as a very first note, I am missing clear definitions. When I was leading IoT-A, we spent 6 months in coming up with clear definitions of what we were talking about: Reference Model, Reference Architecture, Domain Model, Views, Perspectives, … . In this draft, when I read “Unified IoT Architecture”, I’m not sure what is it. Is it a Reference Architecture - as defined with OASIS, IoT-A or … ? Does this mean that any conceivable IoT system should follow its blueprints? 

Now, when you write: 
>  After deploying many stand-alone IoT systems in
>   architecture.  
Which “thin waist” are you referring to? While It sounds like the hourglass concept for Internet (with IP in the middle), there is no such thing AFAIK for IoT. Actually, I see a multiplication of different protocols (Sigfox, Lora, NB-IoT, Dash7 … -  all of them pretty “young”, less than 10 years old), plus evolution of existing ones (BLE, Zigbee, KNX, wireless HART … ). What do you mean exactly by a “horizontal unified IoT architecture”? You say there’s a current trend: are there some metrics to show that this is what is happening? 

> Such an architecture will make objects accessible to
>   applications across organizations and domains.
This is debatable. Besides, if objects are accessible across organisations, a criminal one would be very happy as they have access to virtually all objects developed with such architecture. I believe “interoperable“ would be a better term to use in this context. 

>  Towards this goal,
>   the IoT system.
here you use “the IoT System” as if it was a single one. Not to enter a complex taxonomy of IoT systems, we can say that a basic distinction is critical and non-critical IoT systems. This is NOT domain based: a car, which is a complex integration of a number of systems - which we can assume smart for the purpose of this discussion - has A/C and active safety systems (such as automatic braking to avoid hitting pedestrians, for instance). A/C is clearly non-critical - if it doesn’t work, you keep your coat on or open the windows, and complain bitterly to the car dealer. If active safety does not work, you may kill a human being. Do you mean that ALL IoT systems are information-centric by nature? Besides, I don’t see this duality (host-centric Internet Vs Information-centric IoT). In my opinion, you are mixing two different perspectives (infrastructural one for Internet and Information one for IoT). At the end of the day, IoT simply means that common objects have computational and communication capabilities. I don’t have any hard fact, but given that our smartphones today are millions of times more powerful than the computers used to send the man on the moon, I would imagine that the computational capability of my precision cooker is similar to the one of a computer when the internet was invented. Therefore, it is even hard to classify the objects belonging to IoT or not (constrained / unconstrained), as today unconstrained will probably look ridiculously powerless in 10+ years. 

>  To address this mismatch, an information-centric
To my knowledge, there are more than 400 IoT platforms currently … 
>   based on ICN architecture.

What is an "ICN-IoT framework" in this context? is it an architecture? a reference architecture? an implementation of an architectural blueprint? 

regards, 

—alex

> On Jan 11, 2018, at 20:39, Ravi Ravindran <[email-masked]> wrote:
> 
> Hi MJM,
>  
> From: icnrg [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of Marie-Jose Montpetit
> To: icnrg <[email-masked] <mailto:[email-masked]>>
> Cc: Alessandro Bassi <[email-masked] <mailto:[email-masked]>>
> until the htmlized version and diff are available at tools.ietf.org <http://tools.ietf.org/>.
> 
> ftp://ftp.ietf.org/internet-drafts/ <ftp://ftp.ietf.org/internet-drafts/>
> 
> [email-masked] <mailto:[email-masked]>
> https://www.irtf.org/mailman/listinfo/icnrg <https://www.irtf.org/mailman/listinfo/icnrg>
>  
> [email-masked] <mailto:[email-masked]>
> https://www.irtf.org/mailman/listinfo/icnrg <https://www.irtf.org/mailman/listinfo/icnrg>

---

From: Marie-Jose Montpetit <[email-masked]>
Date: Thu, 11 Jan 2018 18:07:20 -0500

See inline.

Marie-José Montpetit
[email-masked]
[email-masked]

> On Jan 11, 2018, at 2:39 PM, Ravi Ravindran <[email-masked]> wrote:
> 
> Hi MJM,
>  
> Ravi > If there is anything unified this draft should discuss, it should be about the ICN network layer which offers features like name-based APIs, security, in-network computing, caching etc.

But this is not an architecture. It is a number of standardized elements one can use to build and architecture.
> This flexibility allows one to build efficient middleware components and architect the services based on their individual needs, one of the reasons why we motivate ICN-IoT applications in the initial part of the draft. So at some point if it implies otherwise, please point out and we will address that.
>  
> We do discuss about application level unified architecture in the current state-of-art section, which is required to make the sensors, gateways, IoT servers etc. inter-operate with one another,

I agree with interoperability. But it’s not the same as unified.

> but not a  requirement for heterogeneous ICN-IoT applications to interact with one another.

What do you mean?
>  
> mjm
> 
> 
> 
> Begin forwarded message:
> 
> From: [email-masked]
> To: <[email-masked]>
> Cc: [email-masked]
> 
>

---

From: Ravi Ravindran <[email-masked]>
Date: Fri, 12 Jan 2018 01:28:37 +0000

Hi Allessandro,

Thanks for your comments, please see for my response inline.

Regards,
Ravi

Ravi > The goal of this draft is to not to offer any architectural reference design, but to discuss the design challenges of enabling IoT services over ICN. The term “unified iot architecture” has only been used in the context to explain current approaches and not for the ICN discussion.

The abstract reads:

Now, when you write:

Ravi > In this context the thin waist refers to IP, these lines in the abstract refers to the discussion we have in Section 4, highlighting the fragmented IoT space and how IP-IoT standards are trying to address them. Please let me know if there are more concerns that needs to be addressed in Section 4.

Ravi > Sure, we do discuss the need to for security and privacy in different parts of the design discussion in Section 6 related to Naming, Name-resolution, Caching etc. Regarding the shareability of resource objects, the point here is that the unification based on name based abstractions enabled through ICN- of course considering the security considerations- that allows disparate IoT applications to talk to each other over ICN. We can make the change to ensure security and privacy concerns are mentioned here, will aslso discuss with the co-authors on if using the term “interoperable” makes more sense here.

 Towards this goal,
  quite a few proposals have been made to build an application-layer
  based unified IoT platform
on top of today's host-centric Internet.
  However, there is a fundamental mismatch between the host-centric
  nature of todays Internet and mostly information-centric nature of
  the IoT system.
here you use “the IoT System” as if it was a single one.
Not to enter a complex taxonomy of IoT systems, we can say that a basic distinction is critical and non-critical IoT systems. This is NOT domain based: a car, which is a complex integration of a number of systems - which we can assume smart for the purpose of this discussion - has A/C and active safety systems (such as automatic braking to avoid hitting pedestrians, for instance). A/C is clearly non-critical - if it doesn’t work, you keep your coat on or open the windows, and complain bitterly to the car dealer. If active safety does not work, you may kill a human being. Do you mean that ALL IoT systems are information-centric by nature? Besides, I don’t see this duality (host-centric Internet Vs Information-centric IoT). In my opinion, you are mixing two different perspectives (infrastructural one for Internet and Information one for IoT). At the end of the day, IoT simply means that common objects have computational and communication capabilities. I don’t have any hard fact, but given that our smartphones today are millions of times more powerful than the computers used to send the man on the moon, I would imagine that the computational capability of my precision cooker is similar to the one of a computer when the internet was invented. Therefore, it is even hard to classify the objects belonging to IoT or not (constrained / unconstrained), as today unconstrained will probably look ridiculously powerless in 10+ years.

Ravi >  The term “IoT system” can be seen from the perspective of a specific IoT application which as many parts, like the vehicle system you have mentioned, but the vehicle itself is part of a larger IoT service. Also, in the draft, we don’t say all system are ICN by nature, we rather say most of them are, as the services are interested in a specific IoT content rather than who produced it. On the topic of using the term constrained or unconstrained, this is a standard terminology based on the hardware resources over which the IoT applications run, so sensor nodes are considered constrained as they are generally closed embedded microcontroller based system with few KB of memory, battery operated, etc. Sure, these resources could evolve over time.

Ravi > Here we use ICN-IoT framework (again may not be unified and be per application based) to refer to middleware, service, control, management plane components required to support IoT applications over ICN. Again the goal of this draft is not to discuss any specific proposal in this regard.

---

From: Ravi Ravindran <[email-masked]>
Date: Fri, 12 Jan 2018 02:07:00 +0000

Regards,
Ravi

From: Marie-Jose Montpetit [mailto:[email-masked]]
Sent: Thursday, January 11, 2018 3:07 PM
To: Ravi Ravindran <[email-masked]>
Cc: icnrg <[email-masked]>; Alessandro Bassi <[email-masked]>
Subject: Re: [icnrg] I-D Action: draft-irtf-icnrg-icniot-00.txt

See inline.
Marie-José Montpetit
[email-masked]<mailto:[email-masked]>
[email-masked]<mailto:[email-masked]>

On Jan 11, 2018, at 2:39 PM, Ravi Ravindran <[email-masked]<mailto:[email-masked]>> wrote:
Hi MJM,

Regards,
Ravi

From: icnrg [mailto:[email-masked]] On Behalf Of Marie-Jose Montpetit
Sent: Thursday, January 11, 2018 6:59 AM
To: icnrg <[email-masked]<mailto:[email-masked]>>
Cc: Alessandro Bassi <[email-masked]<mailto:[email-masked]>>
Subject: Re: [icnrg] I-D Action: draft-irtf-icnrg-icniot-00.txt

                Ravi  > Not sure about your comment. The above mentioned features are part of an ICN network architecture. Again the draft doesn’t intend to propose any specific service/control/management plane architecture to support IoT services, but to understand the challenges to support them

Ravi > As mentioned to my response to Alessandro, we use the term unified only to explain current IoT systems. But we can think about using some other terminology here.

What do you mean?

Ravi > This comment is in the context of current systems, which interoperates at service level ; while ICN offers a common name based abstraction substrate to interoperate that would enable efficient routing, leveraging caching/computing etc.

mjm

Begin forwarded message:

Abstract:

---

From: Alessandro Bassi <[email-masked]>
Date: Wed, 17 Jan 2018 12:21:15 +0100

Hi Ravi, 

please see inline,

> On Jan 12, 2018, at 02:28, Ravi Ravindran <[email-masked]> wrote:
> 
> Hi Allessandro,
>  

Still, sorry to insist, but what is your definition of “Unified IoT Architecture”? 

> Ravi > In this context the thin waist refers to IP, these lines in the abstract refers to the discussion we have in Section 4, highlighting the fragmented IoT space and how IP-IoT standards are try…

It’s somehow normal that the IETF is IP-centric :) In the IoT world, however, the number of domains and applications is so large that some of them cannot run on a protocol that provides an “unreliable, connectionless" delivery of packets. (as per IP definition) - hard-real time and critical systems, for instance. So the IP-centricity, while true for many (if not most) applications, cannot be used for an “unified IoT Architecture” as there are cases where it cannot apply. This is why I am insisting in this as, in my opinion, there simply cannot exist a unique architecture overarching all possible IoT applications and domains. 

Besides, my question still stands: if you say there’s a trend, you should be able to provide data points that show that there is a consistent pattern; which metric are you using for this? 

> Ravi >  The term “IoT system” can be seen from the perspective of a specific IoT application which as many parts, like the vehicle system you have mentioned, but the vehicle itself is part of a larger IoT service.

I’m sorry but I don’t understand this. Which is the larger IoT system that a vehicle is part of? 

> Also, in the draft, we don’t say all system are ICN by nature, we rather say most of them are, as the services are interested in a specific IoT content rather than who produced it. On the topic of using the term constrained or unconstrained, this is a standard terminology based on the hardware resources over which the IoT applications run, so sensor nodes are considered constrained as they are generally closed embedded microcontroller based system with few KB of memory, battery operated, etc. Sure, these resources could evolve over time.  
>  

Please don’t get me wrong: I’m all for an ICN approach to IoT; just that it’s important, in my opinion, to be very precise when it comes to defining the boundaries as the sharper the image, the easier is to see how it can be used in practice. 

Thanks, best, 

—alex

---

From: Marie-Jose Montpetit <[email-masked]>
Date: Wed, 17 Jan 2018 06:44:41 -0500

I think that what this draft needs is a sentence saying: This draft presents an ICN proposal to create a set of tools such as APIS that will enable the creation of IoT systems. No architecture and surely not a unified one. Tools to make these systems easier to create in an ICN world.

mjm

Marie-José Montpetit
[email-masked]
[email-masked]

> On Jan 17, 2018, at 6:21 AM, Alessandro Bassi <[email-masked]> wrote:
> 
> Hi Ravi, 
> 
> please see inline,
> 
>

---

From: GTS <[email-masked]>
Date: Wed, 17 Jan 2018 09:19:32 -0800

Just my $0.02:  I agree fully with this statement.
Cheers,
Gene

On 1/17/18 3:44 AM, Marie-Jose Montpetit wrote:
> I think that what this draft needs is a sentence saying: This draft 
> presents an ICN proposal to create a set of tools such as APIS that 
> will enable the creation of IoT systems. No architecture and surely 
> not a unified one. Tools to make these systems easier to create in an 
> ICN world.
>
>
> mjm
>
> Marie-José Montpetit
> [email-masked] <mailto:[email-masked]>
> [email-masked] <mailto:[email-masked]>
>
> On Jan 17, 2018, at 6:21 AM, Alessandro Bassi 
> <[email-masked] <mailto:[email-masked]>> 
> wrote:
>
>> Hi Ravi,
>>
>> please see inline,
>>
>>
>>> On Jan 12, 2018, at 02:28, Ravi Ravindran <[email-masked] 
>>> <mailto:[email-masked]>> wrote:
>>>
>>> Hi Allessandro,
>>> as a very first note, I am missing clear definitions. When I was 
>>> leading IoT-A, we spent 6 months in coming up with clear definitions 
>>> of what we were talking about: Reference Model, Reference 
>>> Architecture, Domain Model, Views, Perspectives, … . In this draft, 
>>> when I read “Unified IoT Architecture”, I’m not sure what is it. Is 
>>> it a Reference Architecture - as defined with OASIS, IoT-A or … ? 
>>> Does this mean that any conceivable IoT system should follow its 
>>> blueprints?
>>> Ravi > The goal of this draft is to not to offer any architectural 
>>> reference design, but to discuss the design challenges of enabling 
>>> IoT services over ICN. The term “unified iot architecture” has only 
>>> been used in the context to explain current approaches and not for 
>>> the ICN discussion.
>>
>>> Which “thin waist” are you referring to? While It sounds like the 
>>> hourglass concept for Internet (with IP in the middle), there is no 
>>> such thing AFAIK for IoT. Actually, I see a multiplication of 
>>> different protocols (Sigfox, Lora, NB-IoT, Dash7 … -  all of them 
>>> pretty “young”, less than 10 years old), plus evolution of existing 
>>> ones (BLE, Zigbee, KNX, wireless HART … ). What do you mean exactly 
>>> by a “horizontal unified IoT architecture”? You say there’s a 
>>> current trend: are there some metrics to show that this is what is 
>>> happening?
>>> Ravi > In this context the thin waist refers to IP, these lines in 
>>> the abstract refers to the discussion we have in Section 4, 
>>> highlighting the fragmented IoT space and how IP-IoT standards are 
>>> trying to address them. Please let me know if there are more 
>>> concerns that needs to be addressed in Section 4.
>>
>> It’s somehow normal that the IETF is IP-centric :) In the IoT world, 
>> however, the number of domains and applications is so large that some 
>> of them cannot run on a protocol that provides an “unreliable, 
>> connectionless" delivery of packets. (as per IP definition) - 
>> hard-real time and critical systems, for instance. So the 
>> IP-centricity, while true for many (if not most) applications, cannot 
>> be used for an “unified IoT Architecture” as there are cases where it 
>> cannot apply. This is why I am insisting in this as, in my opinion, 
>> there simply cannot exist a unique architecture overarching all 
>> possible IoT applications and domains.
>>
>> Besides, my question still stands: if you say there’s a trend, you 
>> should be able to provide data points that show that there is a 
>> consistent pattern; which metric are you using for this?
>>
>>> This is debatable. Besides, if objects are accessible across 
>>> organisations, a criminal one would be very happy as they have 
>>> access to virtually all objects developed with such architecture. I 
>>> believe “interoperable“ would be a better term to use in this context.
>>> Ravi > Sure, we do discuss the need to for security and privacy in 
>>> different parts of the design discussion in Section 6 related to 
>>> Naming, Name-resolution, Caching etc. Regarding the shareability of 
>>> resource objects, the point here is that the unification based on 
>>> name based abstractions enabled through ICN- of course considering 
>>> the security considerations- that allows disparate IoT applications 
>>> to talk to each other over ICN. We can make the change to ensure 
>>> security and privacy concerns are mentioned here, will aslso discuss 
>>> with the co-authors on if using the term “interoperable” makes more 
>>> sense here.
>>>
>>>
>>>  Towards this goal,
>>> Not to enter a complex taxonomy of IoT systems, we can say that a 
>>> basic distinction is critical and non-critical IoT systems. This is 
>>> NOT domain based: a car, which is a complex integration of a number 
>>> of systems - which we can assume smart for the purpose of this 
>>> discussion - has A/C and active safety systems (such as automatic 
>>> braking to avoid hitting pedestrians, for instance). A/C is clearly 
>>> non-critical - if it doesn’t work, you keep your coat on or open the 
>>> windows, and complain bitterly to the car dealer. If active safety 
>>> does not work, you may kill a human being. Do you mean that ALL IoT 
>>> systems are information-centric by nature? Besides, I don’t see this 
>>> duality (host-centric Internet Vs Information-centric IoT). In my 
>>> opinion, you are mixing two different perspectives (infrastructural 
>>> one for Internet and Information one for IoT). At the end of the 
>>> day, IoT simply means that common objects have computational and 
>>> communication capabilities. I don’t have any hard fact, but given 
>>> that our smartphones today are millions of times more powerful than 
>>> the computers used to send the man on the moon, I would imagine that 
>>> the computational capability of my precision cooker is similar to 
>>> the one of a computer when the internet was invented. Therefore, it 
>>> is even hard to classify the objects belonging to IoT or not 
>>> (constrained / unconstrained), as today unconstrained will probably 
>>> look ridiculously powerless in 10+ years.
>>> Ravi >  The term “IoT system” can be seen from the perspective of a 
>>> specific IoT application which as many parts, like the vehicle 
>>> system you have mentioned, but the vehicle itself is part of a 
>>> larger IoT service.
>>
>>> Also, in the draft, we don’t say all system are ICN by nature, we 
>>> rather say most of them are, as the services are interested in a 
>>> specific IoT content rather than who produced it. On the topic of 
>>> using the term constrained or unconstrained, this is a standard 
>>> terminology based on the hardware resources over which the IoT 
>>> applications run, so sensor nodes are considered constrained as they 
>>> are generally closed embedded microcontroller based system with few 
>>> KB of memory, battery operated, etc. Sure, these resources could 
>>> evolve over time.
>>> What is an "ICN-IoT framework" in this context? is it an 
>>> architecture? a reference architecture? an implementation of an 
>>> architectural blueprint?
>>> Ravi > Here we use ICN-IoT framework (again may not be unified and 
>>> be per application based) to refer to middleware, service, control, 
>>> management plane components required to support IoT applications 
>>> over ICN. Again the goal of this draft is not to discuss any 
>>> specific proposal in this regard.
>>
>> Please don’t get me wrong: I’m all for an ICN approach to IoT; just 
>> that it’s important, in my opinion, to be very precise when it comes 
>> to defining the boundaries as the sharper the image, the easier is to 
>> see how it can be used in practice.
>>
>> Thanks, best,
>>
>> —alex
>>
>>

---

From: Ravi Ravindran <[email-masked]>
Date: Wed, 17 Jan 2018 17:24:58 +0000

Sure MJM, we will take that comment, specifically we will go over the use of terms unified and unified architecture used mostly in the introduction and the IoT architectural requirements of the draft.

Regards,
Ravi

From: Marie-Jose Montpetit [mailto:[email-masked]]
Sent: Wednesday, January 17, 2018 3:45 AM
To: Alessandro Bassi <[email-masked]>
Cc: Ravi Ravindran <[email-masked]>; icnrg <[email-masked]>
Subject: Re: [icnrg] I-D Action: draft-irtf-icnrg-icniot-00.txt

mjm

Marie-José Montpetit

On Jan 17, 2018, at 6:21 AM, Alessandro Bassi <[email-masked]<mailto:[email-masked]>> wrote:
Hi Ravi,

please see inline,

On Jan 12, 2018, at 02:28, Ravi Ravindran <[email-masked]<mailto:[email-masked]>> wrote:

Hi Allessandro,

Regards,
Ravi

The abstract reads:

Now, when you write:

 Towards this goal,

Thanks, best,

—alex

---

From: Ravi Ravindran <[email-masked]>
Date: Wed, 17 Jan 2018 17:42:38 +0000

HI Alex,

Please see for my response inline.

Regards,
Ravi

From: Alessandro Bassi [mailto:[email-masked]]
Sent: Wednesday, January 17, 2018 3:21 AM
To: Ravi Ravindran <[email-masked]>
Cc: Marie-Jose Montpetit <[email-masked]>; icnrg <[email-masked]>
Subject: Re: [icnrg] I-D Action: draft-irtf-icnrg-icniot-00.txt

Hi Ravi,

please see inline,

Hi Allessandro,

Regards,
Ravi

Ravi > We used this term to identify the common set of abstractions required to enable efficient operation of an IoT domain, and inter-connection between them. As responded to MJM, we will go over the use of this terminology and get back with a revision.

The abstract reads:

Now, when you write:

Ravi > Sure, as for the data points are the efforts we have cited such as ETSI/oneM2M and IETF/CORE. Do you think we need more here ?

 Towards this goal,

Ravi> What I was getting at is that vehicle itself Could be part of a larger service such as traffic monitoring/management system (ITS), or its data used towards environmental applications, we have Smart Mobility as one of the use cases in Section 2 that provides a broader perspective.

Ravi > Sure Alex, your inputs are very valuable to set the expectations right, so it will be nice to give us more feedback on this.

Thanks, best,

—alex