[icnrg] Comments to draft-zhang-icnrg-icniot-requirements-01

[Börje Ohlman <[e-mail]>]

Here are some comments on draft-zhang-icnrg-icniot-requirements-01

Börje
<Chair hat off>

—————————————————

Overall comments:

  *
Whenever it is stated the ICN is better than IP or that something is hard to do with IP that should be substantiated and references provided, e.g. Sec. 6.3 §2
  *
Why is not MQTT mentioned in the document? It is one of the more commonly used IoT protocols today.

Detailed comments:
Sec. 2.1
“The first step towards realizing a unified IoT platform is the
ability to assign names that are unique within the scope and lifetime
of each device, data items generated by these devices, or a group of
devices towards a common objective.”


  *
What names, devices and/or data?
  *
Should names be device dependent and be limited by the lifetime of a device?

“names need to be persistent (within one or more
contexts) against dynamic features that are common in IoT systems,
such as lifetime, mobility or migration”

  *
Why should persistence be context dependent?

“names should provide
advantages to application authors in comparison with traditional host
address based schemes”

  *
What type of advantages?

Sec. 2.3
“IoT devices can be broadly classified into two groups: resource-sufficient
and resource-constrained.”

  *
Why not use the type 1, type 2 & type 3 classes that is commonly referred to in IoT discussion

Sec. 5.3
“Caching in constrained networks is limited to small amounts
in the order of 10KB, while caching in infrastructure part of the
network can allow much larger chunks.”

  *
I think this type of document should refrain from stating specific numbers on what certain type of devices can or can’t do as this will certainly change over time.
  *
In addition, it is unclear from the formulation if the number refers to size of individual chunks or total device caching capability

Sec. 5.4

  *
The discussion on mobility, starting in the second bullet with “Finally, another challenge is to quantify the cost associated with mobility management, especially static binding vs. dynamic binding.” should be made into a separate sub-section. That way it will be visible in the table of contents.
  *
In the last bullet it should be mentioned that hierarchical names are a problem for mobility as it is stated that they are an advantage in the scalability discussion.
  *
In the last bullet it is stated “For handling mobility across different domains, more sophisticated approaches could be used, including the adoption of a SDN-based control plane.” If this should be stated, it should be substantiated by some example and reference.
  *
Editorial - second bullet:
     *
s/main/maintain/

Sec. 5.6

  *
§3, Editorial: s/Another is challenge is/Another challenge is/

Sec. 5.7

  *
First bullet:
Once again, I think this type of document should refrain from stating specific numbers on what certain type of devices can or can’t do as this will certainly change over time. Just one example: http://science.sciencemag.org/content/354/6310/302


  *
Second bullet:
The items in the numbered list not specific for infrastructure and/or too general to be meaningful.

Sec. 5.10

  *   Should be expanded to say something meaningful or removed.