Re: [icnrg] review of draft-choi-icnrg-aiot-02

["David R. Oran" <[e-mail]>]

Thanks so much for the timely review.
We now have two reviews, which is great. More would of course be appreciated.

Authors - what’s your plan for working on this draft?

DaveO.


On 5 May 2020, at 4:40, Rute Sofia wrote:

> Dear All,
>
> a review of draft-choi-icnrg-aiot-02 (https://datatracker.ietf.org/doc/draft-choi-icnrg-aiot/).
>
> The draft is relevant as it handles the need of applying AI to IoT environments. However, the connection to ICNRG is not clear IMO. Also, the draft is still in a very early stage of development, which requires a lot more thought; a good look into available related work on the field. Some sections should IMO be re-written and merged.
>
> Overall comments follow.
>
> Best Regards,
> Rute Sofia
>
>
> Global comments:
> ------------------------------------------------------------------
> There is something wrong with the formatting, please check it as several words are cut, aspect which difficults the reading.
>
> The motivation (intro) should be re-written to explain better the problem. The application in the context of ICNRG is not completely clear.
>
> The wide use of "IoT service" is tricky. Perhaps IoT end-to-end system is better. An IoT service environment simply refers to what we usually use on the Cloud/Edge. I believe the authors are also considering the IoT devices, i.e.: all of the IoT ecosystem.
> There is the need for a terminology section where all of the different terms are described.
> It is also relevant not to focus the topic of IoT on consumer IoT only, as it is now drafted. In fact, AI is highly important in Industrial IoT environments.
>
> Concerning the IoT challenges, there are 2 main aspects which are not addressed and should be: the need for mobility support; intermittent and asynchronous communication.
>
>
> Comments per section:
> ---------------------------------------------------
> Abstract
>
>
> intends to present a right direction to empower AI - a "right direction" should be replaced by other terms, for instance, a potential direction.
>
>
>
> 1.  Introduction
>
>
>
> The way the motivation has been described is quite confusing, again with some confusion on the terms. Also, the description of how data sources work require more explanation. For instance data sources do send small packets,but the volume can be high. Then, it is explicitely stated that the data sources communicate with a server (client/server) thus eliminating the possibility of direct communication (Thing to Thing) and Pub/Sub communication.
>
>
>
> 2.      Challenges
> There are 2 main challenges missing: mobility, and intermittent connectivity. In terms of security and concerning both hw and sw: accountability.
>
>
> 2.1   Untrusted and incorrect devices
> What is meant with "incorrect device"
> Also, this section is focused on hw and PHY aspects.
>
> In shop-floors and industrial environments, devices are certified. It is not usual to deploy uncertified sensors. However, a problem that can arise is the fact that other sensing devices, such as rugged tablets, may be used for maintenance. While the hw has been certified, software/app and user accountability is required.
>
>
> 2.2   traffic burstiness
>
> The claims stated should be backed up with specific references. There are specific guidelines being provided, for instance, by IIC or by the IEEE concerning different IoT environments and traffic profiles. Also, the assumptions stated, that for "normal IoT traffic" (what is this) the "normal bandwidth" (what is this) is very small is not accurate. In IIoT, these devices are connected via Ethernet and soon with WiFi 6. In consumer IIoT, we are connected via the internet, with often a wireless or LTE "bottleneck" at the last hop to the end-user.
>
>
> 2.3   management overhead of IoT devices
> Is this about configuration or onboarding? Or both? Also, please notice that smartphones and rugged devices are actually sensing devices which have also to be accounted for in IoT environments.
>
>
> 3.      AI/ML based IoT services should be named as examples of AI application per domain sectors.
> The idea of describing the potential application of AI in different domains is relevant. However, its current status is confusing. There is a quick description of different sectors. Perhaps organizing this in a similar fashion, with specific aspects such as: description; problem solved with AI; main techniques applied; expected impact.
>
>
>
> 4.      Requirements
>
> This section should have a list of requirements based on section 3. At this stage, it is still confusing. It is also too little, so either it is removed (a subsection of 3 could be added instead).
>
> 4.2
> Context-awareness is suddenly addressed in this section without actually describing it anywhere else. On which layers, which indicators are being considered, etc.? This needs to be addressed up front in the draft.
>
> Section 4 and 5 do not add much in comparison to related literature. What is the purpose of these 2 sections? Could they be merged? Also, the introduction on different ML methods can be done by recurring to relevant related work in the field.
>
> The application of neuromorphic computing should also be cited (SNN and IoT).
>
> Section 6 and 3 are somewhat repeating. The content of 3 could be placed in 6, use-cases.
>
>
> Rute Sofia
>
> --
> fortiss · Landesforschungsinstitut des Freistaats Bayern
> An-Institut Technische Universität München
> Guerickestraße 25
> 80805 München
> Germany
> Tel.: [phone]
> Fax: [phone]
> E-Mail: [e-mail]<mailto:[e-mail]>
> https://www.fortiss.org/
>
> Amtsgericht München: HRB: 176633
> USt-IdNr.: DE263907002, Steuer-Nr.: 143/237/25900
> Rechtsform: gemeinnützige GmbH
> Sitz der Gesellschaft: München
> Geschäftsführer: Dr. Harald Rueß, Thomas Vallon
> Vorsitzender des Aufsichtsrats: Dr. Manfred Wolter


> _______________________________________________
> icnrg mailing list
> [e-mail]
> https://www.irtf.org/mailman/listinfo/icnrg

DaveO