Subject: Re: [icnrg] Review of "Using ICN in Disaster Scenarios" (draft-irtf-icnrg-disaster-01)

From: Jan Seedorf <[email-masked]>
Date: Mon, 3 Jul 2017 23:48:38 +0200

Dear Akbar,

thank you for much for the thorough review of our draft and the good 
comments you provided below. We have finally addressed these comments 
and just uploaded a new version of the draft (-02 version). Please have 
a look and see the diff with the previous version to see the text we 
added according to your comments (we agree with most of them and added 
quite a bit of text). Let me just briefly point out a few things 
(essentially, all the other comments we fully agree with and we have 
added corresponding text):

> 4)Section 3.2 (How ICN can be Beneficial)
>
> ·The section seems to be a nice listing of general ICN properties, but 
> somehow lacking further specificity regarding relation to disaster 
> scenarios in many of the bullets.  Perhaps one way to correct that is 
> to have some further correlation between section 3.2 or 3.1.  For example:
>
> oIt is not clear how routing-by-name (section 3.2) will overcome 
> congested networks (section 3.1)
Jan: Actually, on each bullet in 3.2. there is specific text that refers 
to the disaster scenario / fragmented networks scenario. Do you have any 
specific bullets where you think some more text would be needed? If so, 
please let us know.

> but it still requires further updates (e.g. as already self-identified 
> at the end of the key section 3.2).
Jan: As pointed out at the last IETF meeting when I presented the draft: 
the goal is not to have a complete list of solutions/challenges/etc. 
Rather, the draft tries to argue that ICN is a good baseline for 
disaster-aftermath communication, giving some (but not a complete list) 
benefits/use-cases/solution-examples. Accordingly, we have removed the 
text saying "future revisions of this document intend to add more 
considerations to the list", it was actually very old text form an early 
version of the document,

Again, thanks for the detailed and good comments!

Looking forward to seeing you soon in Prague,

Jan

On 03.05.17 20:35, Rahman, Akbar wrote:
>
> Hello Chairs and all,
>
> I took an action at the Chicago meeting to provide a review for:
>
> https://tools.ietf.org/html/draft-irtf-icnrg-disaster-01
>
> Following are my comments:
>
> 1)General
>
> ·Overall, I found the draft useful and well written, but it still 
> requires further updates (e.g. as already self-identified at the end 
> of the key section 3.2).
>
> ·Should the title include “Research Directions” or “Research 
> Challenges”?  I’m not adamant on this but just got the feeling that 
> perhaps this would make the title more descriptive.  Just a thought 
> and I will leave it to the authors to decide.
>
> 2)Section 2 (Disaster Scenarios)
>
> ·In paragraph 1 or 2, there should probably be an explicit reference 
> to the existing cellular network disaster SMS notification mechanism 
> (instead of just a general mention to “mobile phones”).  This is, for 
> example, the most commonly used notification method for disaster 
> scenarios today and should be referenced.  There are many pointers on 
> the Web for this and here is one (randomly selected):
>
> ohttp://thehub.smsglobal.com/emergency-sms-alerts-notifications
>
> 3)Section 3.1 (High-Level Research Challenges)
>
> ·For the decentralized authentication bullet.  Should note that 
> cellular SMS notification does not require central authentication.  
> Also, most cellular systems allow emergency calls (e.g. 911) without 
> full authentication.
>
> 4)Section 3.2 (How ICN can be Beneficial)
>
> ·The section seems to be a nice listing of general ICN properties, but 
> somehow lacking further specificity regarding relation to disaster 
> scenarios in many of the bullets.  Perhaps one way to correct that is 
> to have some further correlation between section 3.2 or 3.1.  For example:
>
> oIt is not clear how routing-by-name (section 3.2) will overcome 
> congested networks (section 3.1)
>
> 5)Section 5 (Solution Design)
>
> ·Overall, very nice section!
>
> ·One of the common-sense requirements for disaster scenarios is to be 
> able to make emergency calls (voice/VoIP/Video).  How this is 
> supported should be clarified in this section.
>
> ·There was references for most bullets except for the 1^st (data 
> mules).  Was there a reason for this?
>
> 6)Section 6 (Conclusion)
>
> ·Should clarify if more standardization work (e.g. IETF) is required 
> to enable the ideas in section 5
>
> ·Also, are there still open research areas (or is it as per the last 
> sentence which says concrete solution examples are already there – and 
> so no more research needs to be done)?
>
> Best Regards,
>
> Akbar
>
>
>
>
> <http://ir.interdigital.com/File/Index?KeyFile=37447876>
>
> This e-mail is intended only for the use of the individual or entity 
> to which it is addressed, and may contain information that is 
> privileged, confidential and/or otherwise protected from disclosure to 
> anyone other than its intended recipient. Unintended transmission 
> shall not constitute waiver of any privilege or confidentiality 
> obligation. If you received this communication in error, please do not 
> review, copy or distribute it, notify me immediately by email, and 
> delete the original message and any attachments. Unless expressly 
> stated in this e-mail, nothing in this message or any attachment 
> should be construed as a digital or electronic signature.
>
>
>
>
> _______________________________________________
> icnrg mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/icnrg

---

From: Marie-Jose Montpetit <[email-masked]>
Date: Mon, 3 Jul 2017 17:52:26 -0400

In the same vein it would be great to compare how ICN would be better than for example peer to peer or opportunistic networking. 

> On Jul 3, 2017, at 5:48 PM, Jan Seedorf <[email-masked]> wrote:
> 
> Dear Akbar,
> 
> thank you for much for the thorough review of our draft and the good comments you provided below. We have finally addressed these comments and just uploaded a new version of the draft (-02 version). Please have a look and see the diff with the previous version to see the text we added according to your comments (we agree with most of them and added quite a bit of text). Let me just briefly point out a few things (essentially, all the other comments we fully agree with and we have added corresponding text):
> 
> 
>> 4)     Section 3.2 (How ICN can be Beneficial)
>> ·        The section seems to be a nice listing of general ICN properties, but somehow lacking further specificity regarding relation to disaster scenarios in many of the bullets.  Perhaps one way to correct that is to have some further correlation between section 3.2 or 3.1.  For example:
>> o It is not clear how routing-by-name (section 3.2) will overcome congested networks (section 3.1)
> Jan: Actually, on each bullet in 3.2. there is specific text that refers to the disaster scenario / fragmented networks scenario. Do you have any specific bullets where you think some more text would be needed? If so, please let us know.
> 
> 
>> but it still requires further updates (e.g. as already self-identified at the end of the key section 3.2).
> Jan: As pointed out at the last IETF meeting when I presented the draft: the goal is not to have a complete list of solutions/challenges/etc. Rather, the draft tries to argue that ICN is a good baseline for disaster-aftermath communication, giving some (but not a complete list) benefits/use-cases/solution-examples. Accordingly, we have removed the text saying "future revisions of this document intend to add more considerations to the list", it was actually very old text form an early version of the document,
> 
>> https://tools.ietf.org/html/draft-irtf-icnrg-disaster-01 <https://tools.ietf.org/html/draft-irtf-icnrg-disaster-01>
>>  
>>  
>> 1)     General
>> ·        Overall, I found the draft useful and well written, but it still requires further updates (e.g. as already self-identified at the end of the key section 3.2).
>> ·        Should the title include “Research Directions” or “Research Challenges”?  I’m not adamant on this but just got the feeling that perhaps this would make the title more descriptive.  Just a thought and I will leave it to the authors to decide.
>>  
>> 2)     Section 2 (Disaster Scenarios)
>> ·        In paragraph 1 or 2, there should probably be an explicit reference to the existing cellular network disaster SMS notification mechanism (instead of just a general mention to “mobile phones”).  This is, for example, the most commonly used notification method for disaster scenarios today and should be referenced.  There are many pointers on the Web for this and here is one (randomly selected):
>> o http://thehub.smsglobal.com/emergency-sms-alerts-notifications <http://thehub.smsglobal.com/emergency-sms-alerts-notifications>
>>  
>> 3)     Section 3.1 (High-Level Research Challenges)
>> ·        For the decentralized authentication bullet.  Should note that cellular SMS notification does not require central authentication.  Also, most cellular systems allow emergency calls (e.g. 911) without full authentication.
>>  
>> 4)     Section 3.2 (How ICN can be Beneficial)
>> ·        The section seems to be a nice listing of general ICN properties, but somehow lacking further specificity regarding relation to disaster scenarios in many of the bullets.  Perhaps one way to correct that is to have some further correlation between section 3.2 or 3.1.  For example:
>> o It is not clear how routing-by-name (section 3.2) will overcome congested networks (section 3.1)
>>  
>> 5)     Section 5 (Solution Design)
>> ·        Overall, very nice section!
>> ·        One of the common-sense requirements for disaster scenarios is to be able to make emergency calls (voice/VoIP/Video).  How this is supported should be clarified in this section.
>> ·        There was references for most bullets except for the 1st (data mules).  Was there a reason for this?
>>  
>> 6)     Section 6 (Conclusion)
>> ·        Should clarify if more standardization work (e.g. IETF) is required to enable the ideas in section 5
>> ·        Also, are there still open research areas (or is it as per the last sentence which says concrete solution examples are already there – and so no more research needs to be done)?
>>  
>>  
>> Best Regards,
>>  
>> Akbar
>> 
>> 
>> <Mail Attachment.png>
>> <Mail Attachment.png> <http://ir.interdigital.com/File/Index?KeyFile=37447876>
>> 
>> This e-mail is intended only for the use of the individual or entity to which it is addressed, and may contain information that is privileged, confidential and/or otherwise protected from disclosure to anyone other than its intended recipient. Unintended transmission shall not constitute waiver of any privilege or confidentiality obligation. If you received this communication in error, please do not review, copy or distribute it, notify me immediately by email, and delete the original message and any attachments. Unless expressly stated in this e-mail, nothing in this message or any attachment should be construed as a digital or electronic signature.
>> 
>> 
>> 
>> 
>> [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>