Subject: Re: [icnrg] next stepd for draft-zhang-icnrg-icniot-requirements

From: Ravi Ravindran <[email-masked]>
Date: Fri, 4 Nov 2016 18:07:37 +0000

Hi,

It will be nice to know the decision on this draft. We can address the comments raised by Marie-Jose, Lixia and Thomas as an RG contribution.

Many comments raised in the last call for comments have already been addressed in the current revision. 

https://www.ietf.org/archive/id/draft-zhang-icnrg-icniot-requirements-01.txt

Regards,
Ravi

-----Original Message-----
From: icnrg [mailto:[email-masked]] On Behalf Of Moustafa, Hassnaa
Sent: Friday, September 23, 2016 5:30 PM
To: [email-masked]'; Cedric Westphal
Cc: Lixia Zhang; Marie-Jose Montpetit; [email-masked]; Dirk Kutscher
Subject: Re: [icnrg] next stepd for draft-zhang-icnrg-icniot-requirements

I support the adoption of this draft as a WG document. This draft is a very good basis and be a very useful guideline for ICN deployment for IOT. And the comments below are so useful to consider. It would be also of value to show examples for delay sensitive applications in IOT and how ICN can be a better solution.

Thanks
Hassnaa

-----Original Message-----
From: icnrg [mailto:[email-masked]] On Behalf Of Gennaro Boggia
Sent: Wednesday, September 21, 2016 1:34 AM
To: Cedric Westphal <[email-masked]>
Cc: Dirk Kutscher <[email-masked]>; Marie-Jose Montpetit <[email-masked]>; [email-masked]; Lixia Zhang <[email-masked]>
Subject: Re: [icnrg] next stepd for draft-zhang-icnrg-icniot-requirements

I agree with the previous comments and I support the adoption of it as a WG document

Best Regards
Gennaro

--
Gennaro Boggia, PhD
Associate Professor
DEI - Politecnico di Bari
v. Orabona 4
70125 Bari (Italy)
Tel. +39 080 5963913
Fax +39 080 5963410
Skype: g.boggia
e-mail: [email-masked]; [email-masked]
web: http://telematics.poliba.it/boggia

2016-09-19 22:29 GMT+02:00 Cedric Westphal <[email-masked]>:
> I agree with Lixia and Marie-Jose that this draft would benefit from 
> being worked on by the  RG. I support adoption as a WG document.
>
> Best,
>
>
>
> C.
>
>
>
> From: icnrg [mailto:[email-masked]] On Behalf Of Marie-Jose 
> Montpetit
> Sent: Saturday, September 17, 2016 9:06 AM
> To: Lixia Zhang
> Cc: [email-masked]; Dirk Kutscher
> Subject: Re: [icnrg] next stepd for 
> draft-zhang-icnrg-icniot-requirements
>
>
>
> I agree with Lixia. This needs more focus. Security is yes weak and 
> should not be an afterthought. But I think the justification of ICN 
> for IOT needs more in-depth descriptions and use cases. I can see many 
> reasons to use ICN in IOT (flexibility in caching, storage and 
> retrieval, naming abstraction, abstracted functionalities) but almost 
> as many reasons not too (added complexity, lack of backward 
> compatibility, firmware development in sensor
> networks) etc. A few solid examples and I would say solid 
> implementations comparing the advantages of ICN vs. current implementations would be great.
> Our houses are already filled with IOT apps; how will ICN make them better?
>
>
>
> I am not saying the draft is bad. Just that it needs more work before 
> truly reflecting the gains that ICN will bring to IOT.
>
>
>
> Marie-José
>
>
>
>
>
>
>
> On Sep 17, 2016, at 11:54 AM, Lixia Zhang <[email-masked]> wrote:
>
>
>
>
>
> On Sep 16, 2016, at 9:00 AM, Dirk Kutscher <[email-masked]> wrote:
>
>
>
> Hi all,
>
>
>
> This may have fallen between the cracks during the summer break – so 
> this is a friendly reminder:
>
>
>
> Please let us have your opinion on how to pursue with this draft. Do 
> you support adopting it as an RG document?
>
>
>
> I just had a quick look over the draft: it seems to me that this draft 
> still left lots rooms for improvements, not the least is its treatment 
> on security.  The current draft seems reflecting the common mindset 
> that security is something one has to mention, not that security is an 
> integral component in all aspects of a system.
>
>
>
> Section 2: would it be more appropriate to move security from section 
> 2.8 to section 2.2, right after naming?  given security needs crypto 
> protection, crypto is directly related to identities
>
>
>
> Section 4 on Advantages of using ICN for IoT has no mentioning about 
> security.
>
>
>
> Section 5, like section 2, puts security discussions much later after  
> other subjects that may be felt more familiar with, like name 
> resolution, caching and storage, routing/forwarding, etc.--aren't al 
> these components need security as well?
>
> There seem also discussions on trust that seems separate from security ...
>
>
>
> Another comment is a wish: the draft looks really 
> abstract/motherhood-and-applepie to me, I wonder whether it would be 
> possible to ground the description with some specific examples.
>
>
>
> my 2 cents from a *super* quick flip through (so please take with a 
> big grain of salt!)
>
>
>
> Lixia
>
>
>
> From: Dirk Kutscher
> Sent: Montag, 8. August 2016 17:33
> To: [email-masked]
> Subject: next stepd for draft-zhang-icnrg-icniot-requirements
>
>
>
> Hi all,
>
>
>
> at the Berlin meeting, we concluded that we’d use the mailing list to 
> agree on next steps for draft-zhang-icnrg-icniot-requirements [1].
>
>
>
> In case you don’t remember, this draft is the result of a merger of
> draft-zhang-iot-icn-challenges-02 [2] and
> draft-lindgren-icnrg-efficientiot-03 [3], focusing on the scenario, 
> requirements and challenges aspects of both input drafts.
>
>
>
> After the merger, the authors have submitted another version, 
> reflecting some community feedback.
>
>
>
> Please see 
> https://www.ietf.org/proceedings/96/slides/slides-96-icnrg-3.pdf
> for a summary of the genesis and the current content.
>
>
>
> The chairs would like to get an understanding whether the ICNRG has an 
> interest in pursuing this draft as a RG activity (“adoption”). We 
> normally do this for drafts where there is a critical mass of 
> interested people that would like to see this progressing within ICNRG 
> and eventually be published as an (in this case, Informational)  RFC. 
> This would also require a critical mass of people that would be 
> interested to spend cycles for reviewing the draft and future revisions.
>
>
>
> Could you please let us know whether you think this draft a) should be 
> adopted as a RG item and b) whether you’d be able to help reviewing it?
>
>
>
> Thanks,
>
> Börje, Dave, Dirk (ICNRG chairs)
>
>
>
> [1] 
> https://datatracker.ietf.org/doc/draft-zhang-icnrg-icniot-requirements
> /
>
> [2] https://tools.ietf.org/html/draft-zhang-iot-icn-challenges-02
>
> [3] 
> https://datatracker.ietf.org/doc/draft-lindgren-icnrg-efficientiot/03/
>
>
>
>
>
> _______________________________________________
> icnrg mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/icnrg
>
>
>
> _______________________________________________
> icnrg mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/icnrg
>
>
>
>
> _______________________________________________
> icnrg mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/icnrg
>

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

---

From: Dirk Kutscher <[email-masked]>
Date: Thu, 10 Nov 2016 18:05:49 +0100

Hi Ravi and all,

thanks for the reminder and apologies for the longer processing time.

The chairs have reviewed draft-zhang-icnrg-icniot-requirements and 
considered the nature and breadth of the commentary from the RG 
participants. While our joint assessment is that the draft has some 
value and could be published after a reasonable amount of additional 
technical improvement, we are concerned that the level of engagement of 
the RG beyond the authors has not been sufficient to have a consensus to 
adopt the the draft and continue to work on it as an RG-sponsored 
document. The chairs have made multiple consensus calls and not found 
much enthusiasm. We therefore propose that ICNRG not adopt this document 
but do not object to it proceeding as an individual RFC candidate. 
However, if by the end of the two ICNRG sessions at IETF 97 at least 2 
non-author RG participants indicate willingness to invest time to work 
with the authors to solicit further comments and make editorial 
improvements we will reconsider this decision.

Let us know in case of any question or comment.

Best regards,

Dave, Börje, Dirk (ICNRG chairs)

---

From: Ravi Ravindran <[email-masked]>
Date: Fri, 11 Nov 2016 01:43:41 +0000

Dear Chairs,

Thanks for update on the draft. Sure we would like to work with others to improve it. If folks want to collaborate on this, I'll be available at the interim and main session for more discussion.

Another comment on the support for this draft, to be fair to all those who took time to provide us their feedback; even with the slow pace of activity in this mailing list, we received ~10 responses, mostly either support for adoption or technical comments to the draft. To validate, in addition to the recent comments, the attachment has the previous comments that were provided on the mailing list and that were addressed in the last revision. So I'm not sure if this number isn't a show of enthusiasm for adoption ?.

Regards,
Ravi

-----Original Message-----
From: icnrg [mailto:[email-masked]] On Behalf Of Dirk Kutscher
Sent: Thursday, November 10, 2016 9:06 AM
To: [email-masked]
Cc: Börje Ohlman <[email-masked]>; David R Oran <[email-masked]>
Subject: Re: [icnrg] next stepd for draft-zhang-icnrg-icniot-requirements

Hi Ravi and all,

The chairs have reviewed draft-zhang-icnrg-icniot-requirements and considered the nature and breadth of the commentary from the RG participants. While our joint assessment is that the draft has some value and could be published after a reasonable amount of additional technical improvement, we are concerned that the level of engagement of the RG beyond the authors has not been sufficient to have a consensus to adopt the the draft and continue to work on it as an RG-sponsored document. The chairs have made multiple consensus calls and not found much enthusiasm. We therefore propose that ICNRG not adopt this document but do not object to it proceeding as an individual RFC candidate. 
However, if by the end of the two ICNRG sessions at IETF 97 at least 2 non-author RG participants indicate willingness to invest time to work with the authors to solicit further comments and make editorial improvements we will reconsider this decision.

Best regards,

On 04.11.2016 19:07, Ravi Ravindran wrote:
> Cc: Dirk Kutscher <[email-masked]>; Marie-Jose Montpetit 
> <[email-masked]>; [email-masked]; Lixia Zhang 
> <[email-masked]>
>> for IOT needs more in-depth descriptions and use cases. I can see 
>> many reasons to use ICN in IOT (flexibility in caching, storage and 
>> I just had a quick look over the draft: it seems to me that this 
>> draft still left lots rooms for improvements, not the least is its 
>> treatment on security.  The current draft seems reflecting the common 
>> mindset that security is something one has to mention, not that 
>> security is an integral component in all aspects of a system.
>>
>>
>>
>> The chairs would like to get an understanding whether the ICNRG has 
>> an interest in pursuing this draft as a RG activity (“adoption”). We 
>> interested people that would like to see this progressing within 
>> ICNRG and eventually be published as an (in this case, Informational)  RFC.
>> Could you please let us know whether you think this draft a) should 
>> be adopted as a RG item and b) whether you’d be able to help reviewing it?
>>
>>
>>
>> Thanks,
>>

---

From: Marie-Jose Montpetit <[email-masked]>
Date: Thu, 10 Nov 2016 20:47:51 -0500

I think a lot of us are still looking for the draft to show how ICN is improving on non-ICN IoT. I have Nest, Hue and Alexa and Siri and got a few of of the Amazon Dash for fun - and getting the Google Home soon. How can ICN improve on this? I agree they all have their own app. But what else?

mjm
> On Nov 10, 2016, at 8:43 PM, Ravi Ravindran <[email-masked]> wrote:
> 
> Dear Chairs,
> 
> <Comment-and-Changes.docx>_______________________________________________
> icnrg mailing list
> [email-masked]

---

From: Ravi Ravindran <[email-masked]>
Date: Fri, 11 Nov 2016 02:17:08 +0000

IMO, If we are just considering the home IoT scenario, the scenario is very similar to why ICN is not a replacement for a CDN system ?, probably there is no much scope for significant improvements in these already  optimized commercial environments. But name based systems can offer significant benefits in large enterprise environments, which are currently being supported by many vertical stacks.
So in the draft we argue ICN-IoT as a unified platform to serve heterogeneous IoT environments including infrastructure, wireless, and ad hoc environments with all the features that ICN offers, while also highlighting the challenges ICN-IoT has to address with respect to these functions.
Also as you had already pointed out, it will be good to have a new section on use cases to clearly distinguish benefits of ICN-IoT versus non ICN-IoT deployments considering the various scenarios considered in the draft.

Regards,
Ravi

-----Original Message-----
From: Marie-Jose Montpetit [mailto:[email-masked]] 
Sent: Thursday, November 10, 2016 5:48 PM
To: Ravi Ravindran <[email-masked]>
Cc: Dirk Kutscher <[email-masked]>; [email-masked]; Börje Ohlman <[email-masked]>; David Oran <[email-masked]>
Subject: Re: [icnrg] next stepd for draft-zhang-icnrg-icniot-requirements

mjm
>> https://www.ietf.org/archive/id/draft-zhang-icnrg-icniot-requirements
>> -
>> 01.txt
>> 
>> 
>> Regards,
>> Ravi
>> 
>>> retrieval, naming abstraction, abstracted functionalities) but 
>>> almost as many reasons not too (added complexity, lack of backward 
>>> I am not saying the draft is bad. Just that it needs more work 
>>> before truly reflecting the gains that ICN will bring to IOT.
>>> 
>>> 
>>> 
>>> Marie-José
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> treatment on security.  The current draft seems reflecting the 
>>> common mindset that security is something one has to mention, not 
>>> that security is an integral component in all aspects of a system.
>>> 
>>> 
>>> 
>>> Section 5, like section 2, puts security discussions much later 
>>> after other subjects that may be felt more familiar with, like name 
>>> at the Berlin meeting, we concluded that we’d use the mailing list 
>>> to agree on next steps for draft-zhang-icnrg-icniot-requirements [1].
>>> 
>>> 
>>> 
>>> https://datatracker.ietf.org/doc/draft-zhang-icnrg-icniot-requiremen
>>> t
>>> s
>>> /
>>> 
>>> https://datatracker.ietf.org/doc/draft-lindgren-icnrg-efficientiot/0
>>> 3
>>> /
>>> 
>>> 
>>> 
>>> 
>>>

---

From: Syed Hassan Ahmed <[email-masked]>
Date: Fri, 11 Nov 2016 02:25:13 +0000

Prof. Ravi and all,

I wonder that how ICN is going to improve the energy efficiency issues in
IoT devices that are mostly assumed as battery operated? Any information or
future directions in the draft?

Also, I'm not sure that can we have ICN for sensor networks as a
replacement of current IEEE 802.15.4 protocol stacks. For instance, only
forwarding strategies are been applied?

On Fri, Nov 11, 2016 at 11:17 AM Ravi Ravindran <[email-masked]>
wrote:

> IMO, If we are just considering the home IoT scenario, the scenario is
> very similar to why ICN is not a replacement for a CDN system ?, probably
> there is no much scope for significant improvements in these already
> optimized commercial environments. But name based systems can offer
> significant benefits in large enterprise environments, which are currently
> being supported by many vertical stacks.
> So in the draft we argue ICN-IoT as a unified platform to serve
> heterogeneous IoT environments including infrastructure, wireless, and ad
> hoc environments with all the features that ICN offers, while also
> highlighting the challenges ICN-IoT has to address with respect to these
> functions.
> Also as you had already pointed out, it will be good to have a new section
> on use cases to clearly distinguish benefits of ICN-IoT versus non ICN-IoT
> deployments considering the various scenarios considered in the draft.
>
> Regards,
> Ravi
>
> Cc: Dirk Kutscher <[email-masked]>; [email-masked]; Börje Ohlman <
> [email-masked]>; David Oran <[email-masked]>
> I think a lot of us are still looking for the draft to show how ICN is
> improving on non-ICN IoT. I have Nest, Hue and Alexa and Siri and got a few
> of of the Amazon Dash for fun - and getting the Google Home soon. How can
> ICN improve on this? I agree they all have their own app. But what else?
>
> mjm
> > Thanks for update on the draft. Sure we would like to work with others
> to improve it. If folks want to collaborate on this, I'll be available at
> the interim and main session for more discussion.
> >
> > Another comment on the support for this draft, to be fair to all those
> who took time to provide us their feedback; even with the slow pace of
> activity in this mailing list, we received ~10 responses, mostly either
> support for adoption or technical comments to the draft. To validate, in
> addition to the recent comments, the attachment has the previous comments
> that were provided on the mailing list and that were addressed in the last
> revision. So I'm not sure if this number isn't a show of enthusiasm for
> adoption ?.
> >
> > Regards,
> > Ravi
> >
> participants. While our joint assessment is that the draft has some value
> and could be published after a reasonable amount of additional technical
> improvement, we are concerned that the level of engagement of the RG beyond
> the authors has not been sufficient to have a consensus to adopt the the
> draft and continue to work on it as an RG-sponsored document. The chairs
> have made multiple consensus calls and not found much enthusiasm. We
> therefore propose that ICNRG not adopt this document but do not object to
> it proceeding as an individual RFC candidate.
> non-author RG participants indicate willingness to invest time to work with
> the authors to solicit further comments and make editorial improvements we
> will reconsider this decision.
> >
> >> It will be nice to know the decision on this draft. We can address the
> comments raised by Marie-Jose, Lixia and Thomas as an RG contribution.
> >>
> >> I support the adoption of this draft as a WG document. This draft is a
> very good basis and be a very useful guideline for ICN deployment for IOT.
> And the comments below are so useful to consider. It would be also of value
> to show examples for delay sensitive applications in IOT and how ICN can be
> a better solution.
> >>
> >> Thanks
> >> Hassnaa
> >>
> >> 2016-09-19 22:29 GMT+02:00 Cedric Westphal <[email-masked]
> >:
-- 
Best Regards, Syed Hassan Ahmed. (하산) Kyungpook National University, Daegu,
Republic of Korea. https://sites.google.com/site/shahmedknu/

---

From: Ravi Ravindran <[email-masked]>
Date: Fri, 11 Nov 2016 03:54:51 +0000

Sure Hassan, we have  Section 5.10 on this topic, but it refers to the other architectural aspects of ICN such as discovery, security, naming, in-network computing, caching etc to achieve better energy efficiency. We can elaborate on this topic further considering more recent work such as this one that appeared in recent ICN Sigcomm (“OnboardICNg: a Secure Protocol for On-boarding IoT Devices in ICN”)

Regards,
Ravi

From: icnrg [mailto:[email-masked]] On Behalf Of Syed Hassan Ahmed
Sent: Thursday, November 10, 2016 6:25 PM
To: Marie-Jose Montpetit <[email-masked]>; Ravi Ravindran <[email-masked]>
Cc: Börje Ohlman <[email-masked]>; [email-masked]; David Oran <[email-masked]>; Dirk Kutscher <[email-masked]>
Subject: Re: [icnrg] next stepd for draft-zhang-icnrg-icniot-requirements

Prof. Ravi and all,

I wonder that how ICN is going to improve the energy efficiency issues in IoT devices that are mostly assumed as battery operated? Any information or future directions in the draft?

Also, I'm not sure that can we have ICN for sensor networks as a replacement of current IEEE 802.15.4 protocol stacks. For instance, only forwarding strategies are been applied?

On Fri, Nov 11, 2016 at 11:17 AM Ravi Ravindran <[email-masked]<mailto:[email-masked]>> wrote:
IMO, If we are just considering the home IoT scenario, the scenario is very similar to why ICN is not a replacement for a CDN system ?, probably there is no much scope for significant improvements in these already  optimized commercial environments. But name based systems can offer significant benefits in large enterprise environments, which are currently being supported by many vertical stacks.
So in the draft we argue ICN-IoT as a unified platform to serve heterogeneous IoT environments including infrastructure, wireless, and ad hoc environments with all the features that ICN offers, while also highlighting the challenges ICN-IoT has to address with respect to these functions.
Also as you had already pointed out, it will be good to have a new section on use cases to clearly distinguish benefits of ICN-IoT versus non ICN-IoT deployments considering the various scenarios considered in the draft.

Regards,
Ravi

-----Original Message-----
From: Marie-Jose Montpetit [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Thursday, November 10, 2016 5:48 PM
To: Ravi Ravindran <[email-masked]<mailto:[email-masked]>>
Cc: Dirk Kutscher <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Börje Ohlman <[email-masked]<mailto:[email-masked]>>; David Oran <[email-masked]<mailto:[email-masked]>>
Subject: Re: [icnrg] next stepd for draft-zhang-icnrg-icniot-requirements

mjm
> On Nov 10, 2016, at 8:43 PM, Ravi Ravindran <[email-masked]<mailto:[email-masked]>> wrote:
>
> Dear Chairs,
>
> From: icnrg [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Dirk Kutscher
> To: [email-masked]<mailto:[email-masked]>
> Cc: Börje Ohlman <[email-masked]<mailto:[email-masked]>>; David R Oran
> <[email-masked]<mailto:[email-masked]>>
>> From: icnrg [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Moustafa,
>> Hassnaa
>> To: [email-masked]<mailto:[email-masked]>'; Cedric Westphal
>> Cc: Lixia Zhang; Marie-Jose Montpetit; [email-masked]<mailto:[email-masked]>; Dirk Kutscher
>> From: icnrg [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Gennaro
>> Boggia
>> To: Cedric Westphal <[email-masked]<mailto:[email-masked]>>
>> Cc: Dirk Kutscher <[email-masked]<mailto:[email-masked]>>; Marie-Jose Montpetit
>> <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Lixia Zhang
>> <[email-masked]<mailto:[email-masked]>>
>> e-mail: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
>> 2016-09-19 22:29 GMT+02:00 Cedric Westphal <[email-masked]<mailto:[email-masked]>>:
>>> From: icnrg [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Marie-Jose
>>> Montpetit
>>> Cc: [email-masked]<mailto:[email-masked]>; Dirk Kutscher
>>> On Sep 17, 2016, at 11:54 AM, Lixia Zhang <[email-masked]<mailto:[email-masked]>> wrote:
>>>
>>>
>>>
>>>
>>>
>>> On Sep 16, 2016, at 9:00 AM, Dirk Kutscher <[email-masked]<mailto:[email-masked]>> wrote:
>>>
>>>
>>>
>>> Hi all,
>>>
>>>
>>>
>>> To: [email-masked]<mailto:[email-masked]>
>>> [email-masked]<mailto:[email-masked]>
>>> [email-masked]<mailto:[email-masked]>
>>> [email-masked]<mailto:[email-masked]>
>> [email-masked]<mailto:[email-masked]>
>> [email-masked]<mailto:[email-masked]>
>> [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>

_______________________________________________
icnrg mailing list
[email-masked]<mailto:[email-masked]>
https://www.irtf.org/mailman/listinfo/icnrg
--
Best Regards, Syed Hassan Ahmed. (하산) Kyungpook National University, Daegu, Republic of Korea. https://sites.google.com/site/shahmedknu/

---

From: Alfredo Grieco <[email-masked]>
Date: Fri, 11 Nov 2016 09:04:31 +0100

Dear mjm, Chairs, and all

the point here is that today we can get hundreds of different IoT technologies which hardly interoperate and make them work together thanks to a de-verticalizing middlewares based on ICN principles.

This is not my opinion -only- but what current literature on the subject says. Furthermore, we set up within the H2020 Bonvoyage project an experimental demonstrator that shows that the design principles stated in the draft can become reality. As a matter of fact, in that project we set up a de-verticalizing middleware based on ICN primitives that support IoT applications in Intelligent Transportation Systems. Very recently, we adopted the same middleware in an international Galileo project with LAAS - CNRS (FR) to demonstrate that the same ICN-IoT middleware (the one of the H2020 Bonvoyage project) can serve to smart building applications.

If a Reseach Group should consider the status of the art (and not only personal opinions) I believe this draft did it. We are aware that there is much space for improvements but ICN-IoT by itself is a branch of ICN research that exists in literature and projects so that it would be the case to cover it somehow within the icnrg: am I missing something ?

Many thanks all for the feedbacks.

Sincerely

Alfredo

—
Luigi Alfredo Grieco, PhD 
Associate Professor
Editor-in-Chief, ETT
IEEE VTS - Distinguished Lecturer
Dep. of Electrical and Information Engineering (DEI)
Politecnico di Bari
Via Orabona, 4
70125 - Bari - Italy
Phone: +39 080 5963 911
url: telematics.poliba.it
mail: [email-masked]
linkedin: it.linkedin.com/in/alfredogrieco
> Il giorno 11 nov 2016, alle ore 02:47, Marie-Jose Montpetit <[email-masked]> ha scritto:
> 

-- 
Luigi Alfredo Grieco, PhD 
Associate Professor
Editor-in-Chief, ETT
IEEE VTS - Distinguished Lecturer
Dep. of Electrical and Information Engineering (DEI)
Politecnico di Bari
Via Orabona, 4
70125 - Bari - Italy
Phone: +39 080 5963 911
url: telematics.poliba.it
mail: [email-masked]
linkedin: it.linkedin.com/in/alfredogrieco

---

From: "Trossen, Dirk" <[email-masked]>
Date: Fri, 11 Nov 2016 10:47:26 +0000

Marie-Jose,

The EC-funded POINT project is developing solutions that expand its IpoverICN story to CoAP with different scenarios:
1. pure CoAP-CoAP over IP (over ICN), which works out of the box
2. pure CoAP to CoAP over ICN, which requires a dedicated protocol mapping
3. HTTP (over ICN) to HTTP (over ICN) to CoAP, via an HTTP/CoAP proxy

Now, of course, this story is based on the general migration story of the POINT project that preserves the IP/HTTP/CoAP abstractions.

Dirk

-----Original Message-----
From: icnrg [mailto:[email-masked]] On Behalf Of Marie-Jose Montpetit
Sent: 11 November 2016 01:48
To: Ravi Ravindran <[email-masked]>
Cc: Börje Ohlman <[email-masked]>; [email-masked]; David Oran <[email-masked]>; Dirk Kutscher <[email-masked]>
Subject: Re: [icnrg] next stepd for draft-zhang-icnrg-icniot-requirements

mjm

---

From: Dirk Kutscher <[email-masked]>
Date: Thu, 17 Nov 2016 04:20:22 +0100

Hi Alfredo and all,

thanks -- I think that many of us have some intuition that ICN be useful 
in IoT scenarios.

It would be great to hear more about the technical solutions that people 
have developed for IoT/ICN, what problems they ran into etc.,

I think we should dive deeper into these technical discussions.

Best regards,

Dirk

---

From: Ravi Ravindran <[email-masked]>
Date: Thu, 17 Nov 2016 07:07:50 +0000

Hi Dirk,

The draft's objective is not to propose a particular ICN-IoT solution or dive into one, but to layout the challenges in this emerging area of research. Also the draft has been in works since IETF 90 or so, when there was hardly any work in this space.

Now considering the work in this space, we can definitely add a new section on ICN-IoT solutions and some lessons learnt and challenges that needs to be addressed. Also there were some items that were identified during the joint meeting with the T2TRG group such as applicability of ICN-IoT in the IP-IoT world and inter-operating with it.

I'll summarize these inputs and things that came up in the mailing list in the meeting tomorrow, hope we can come to some consensus on how to proceed with the draft.

Regards,
Ravi

-----Original Message-----
From: icnrg [mailto:[email-masked]] On Behalf Of Dirk Kutscher
Sent: Thursday, November 17, 2016 12:20 PM
To: [email-masked]
Subject: Re: [icnrg] next stepd for draft-zhang-icnrg-icniot-requirements

Hi Alfredo and all,

thanks -- I think that many of us have some intuition that ICN be useful in IoT scenarios.

It would be great to hear more about the technical solutions that people have developed for IoT/ICN, what problems they ran into etc.,

Best regards,

Dirk

On 11.11.2016 09:04, Alfredo Grieco wrote:
> Dep. of Electrical and Information Engineering (DEI) Politecnico di 
> Bari Via Orabona, 4
> 70125 - Bari - Italy
> Phone: +39 080 5963 911
>>>> https://www.ietf.org/archive/id/draft-zhang-icnrg-icniot-requiremen
>>>> ts-
>>>> 01.txt
>>>>
>>>>
>>>> Regards,
>>>> Ravi
>>>>
>>>>> I agree with Lixia and Marie-Jose that this draft would benefit 
>>>>> from being worked on by the  RG. I support adoption as a WG document.
>>>>>
>>>>> Best,
>>>>>
>>>>>
>>>>>
>>>>> C.
>>>>>
>>>>>
>>>>>
>>>>> I agree with Lixia. This needs more focus. Security is yes weak 
>>>>> and should not be an afterthought. But I think the justification 
>>>>> of ICN for IOT needs more in-depth descriptions and use cases. I 
>>>>> can see many reasons to use ICN in IOT (flexibility in caching, 
>>>>> storage and retrieval, naming abstraction, abstracted 
>>>>> functionalities) but almost as many reasons not too (added 
>>>>> complexity, lack of backward compatibility, firmware development 
>>>>> in sensor
>>>>> This may have fallen between the cracks during the summer break – 
>>>>> so this is a friendly reminder:
>>>>>
>>>>>
>>>>>
>>>>> Please let us have your opinion on how to pursue with this draft. 
>>>>> Do you support adopting it as an RG document?
>>>>>
>>>>>
>>>>>
>>>>> 2.8 to section 2.2, right after naming?  given security needs 
>>>>> crypto protection, crypto is directly related to identities
>>>>>
>>>>>
>>>>>
>>>>> Section 4 on Advantages of using ICN for IoT has no mentioning 
>>>>> about security.
>>>>>
>>>>>
>>>>>
>>>>> after other subjects that may be felt more familiar with, like 
>>>>> name resolution, caching and storage, routing/forwarding, 
>>>>> etc.--aren't al these components need security as well?
>>>>>
>>>>> abstract/motherhood-and-applepie to me, I wonder whether it would 
>>>>> be possible to ground the description with some specific examples.
>>>>>
>>>>>
>>>>>
>>>>> my 2 cents from a *super* quick flip through (so please take with 
>>>>> a big grain of salt!)
>>>>>
>>>>>
>>>>>
>>>>> Lixia
>>>>>
>>>>>
>>>>>
>>>>> From: Dirk Kutscher
>>>>> draft-lindgren-icnrg-efficientiot-03 [3], focusing on the 
>>>>> scenario, requirements and challenges aspects of both input drafts.
>>>>>
>>>>>
>>>>>
>>>>> The chairs would like to get an understanding whether the ICNRG 
>>>>> has an interest in pursuing this draft as a RG activity 
>>>>> (“adoption”). We normally do this for drafts where there is a 
>>>>> critical mass of interested people that would like to see this 
>>>>> progressing within ICNRG and eventually be published as an (in this case, Informational)  RFC.
>>>>> Could you please let us know whether you think this draft a) 
>>>>> should be adopted as a RG item and b) whether you’d be able to help reviewing it?
>>>>>
>>>>>
>>>>>
>>>>> Thanks,
>>>>>
>>>>> https://datatracker.ietf.org/doc/draft-zhang-icnrg-icniot-requirem
>>>>> ent
>>>>> s
>>>>> /
>>>>>
>>>>> https://datatracker.ietf.org/doc/draft-lindgren-icnrg-efficientiot
>>>>> /03
>>>>> /
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>

---

From: David Oran <[email-masked]>
Date: Thu, 17 Nov 2016 09:10:29 -0500

> On Nov 17, 2016, at 2:07 AM, Ravi Ravindran <[email-masked]> wrote:
> 
> Hi Dirk,
> 
> Now considering the work in this space, we can definitely add a new section on ICN-IoT solutions and some lessons learnt and challenges that needs to be addressed.
I would shy away from including any solutions in the document. Citing research results would be appropriate though.

> Also there were some items that were identified during the joint meeting with the T2TRG group such as applicability of ICN-IoT in the IP-IoT world and inter-operating with it.
> 
This seems a pretty big expansion of scope. I’d lean toward putting this in a separate document on interworking.