[coman] Review of draft-ersue-constrained-mgmt-03

["Sehgal, Anuj" <[e-mail]>]

Hi,

After reading draft-ersue-constrained-mgmt-03 there are a few
questions that came up in my mind. There also some general editorial
things I would like to point out, and as such, I will break up the
email into two sections for readability.

1. Questions Regarding draft-ersue-constrained-mgmt-03

a. From reading the document, it is not completely clear whether
   end-to-end IP connectivity is assumed in all cases? Or is it
   possible that the gateways in between act as translators for
   different protocols? In general there seems to be an implied
   understanding that end-to-end IP connectivity exists, but it might
   be useful to make this clear in the document.

b. Section 1.3 focuses on the class of networks that are within the
   scope of this document but the terminology defined here (CN0, CN1,
   etc.) is not used elsewhere in the document. Since it is not used
   in the document, is it still relevant? Maybe it is better to just
   remove this from the document?

c. It might be best to check all the terminology against the LWIG
   document once since things could have changed there and to make
   sure that all the terminologies are still relevant.

d. Section 2 makes a claim that "the current management protocols seem
   to be too heavyweight compared to the capabilities the constrained
   devices". It would seem that at least SNMPv1 performs decently
   within the resource constraints of the environment.

   As such, either this needs a reference to solidify this position or
   needs to be expanded in order to make it clear that this not
   necessarily a resource usage issue but more of an issue related to
   the fact that the IoT protocol stack (e.g. CoAP) is what should
   be/people like to reuse in this environment for management and
   application.

e. The Industrial Application examples provided in Section 3.3 may not
   be the best ones. Things like centralized control of energy, HVAC,
   lighting and access control can also be categorized under Home
   Automation, Building Automation or Energy Management. On the other
   hand use cases like manufacturing, assembly lines and etc. do fit
   well within this section. It would seem that this section needs
   some examples to be changed and improved.

f. Currently there is a big intersect between the Industrial
   Application, Home Automation and Building Automation use cases. The
   examples and text in these sections needs to be clarified in order
   to make sure that the differences between these closely related use
   cases is clear to the reader.

g. In Section 3.5 it is stated that "Contrary to home automation in
   building management all devices are known to a set of commissioning
   tools and a data storage...".

   I suggest changing the language a little bit to say that this is
   expected, rather than always being the ground truth. While normally
   assets might be tightly managed in such an environment, it may not
   necessarily be so. Maybe writing, "Contrary to home automation in
   building management all devices are expected to be managed assets,
   and as such, known to a set of commissioning tools and a data
   storage...".

h. The whole use case of Mobile Applications in Section 3.10 seems to
   be not really a use case, but rather special cases related to
   access technologies. All the issues discussed here seem to be use
   case issues that should be part of other use case sections. It
   might be better to merge this section into the previous sections.

i. Section 3.12, MANET Concept of Operations (CONOPS) in Military, is
   considerably more detailed than any of the other use case
   sections. Furthermore, it would likely make more sense to shift the
   focus of this use case from MANET and CONOPS to purely military
   applications, since the use case here is not specifically MANETs,
   but rather the special conditions that come with military
   operations. Also, in light of increased international military unit
   cooperation it makes even more sense to have a section focusing
   specifically on military applications since in these scenarios it
   is quite likely that multiple different standards, best practices
   and implementation approaches may conflict/contradict, thereby
   needing special management of such networks.

j. It is stated in Section 4 that the document does not recommend the
   realization of a profile of requirements. What does "profile of
   requirements" refer to? This is quite unclear because a list of
   requirements, that seem to be a profile, is present in the document
   as well.

k. From reading the document it is quite unclear what Functional
   Requirement, Non-Functional Requirement and Design Constraint
   exactly mean. For example, Requirement 4.1.004 is marked as
   non-functional, however, it could be argued that due to the
   resource constraints on devices, minimizing state maintained on
   them should be a functional requirement, or even a design
   constraint since it is forced by the platform. An explicit
   clarification between these requirement types in the document would
   be useful.

l. After reading Requirement 4.3.001, I have the feeling that using
   Mandatory and Optional as priorities is likely not
   appropriate. Making something mandatory makes it an absolute
   requirement, and in case of constrained devices making
   self-configuration mandatory for C0 and C1 devices might be
   overkill. As such, I propose that the terminology for priorities be
   changed to using "High, Medium and Low" since that more accurately
   represents the importance of implementing a requirement.

m. Requirement 4.10.002, regarding reliable unicast transport has a
   title that is a bit ambiguous. Just by reading the title an
   impression is had that the requirement might apply to the transport
   protocol, which would make CoAP, for example, not usable. However,
   reading the description provides a bit of inferred clarity that
   reliability applies to the message transport, and not the transport
   protocol. As such, I suggest replacing the title with the current
   description, which is quite short; it would then make sense to have
   a more precise and clearly worded description, which would not lead
   to this ambiguity or misinterpretation.

2. Editorial Issues

a. In Section 1.6, the statement, "Faults in network operation
   including hardware and software errors, failures detected by the
   transport protocol and other self-monitoring mechanisms can be used
   to provide fault tolerance.", is unclear. This needs to be reworded
   to clearly explain the goal.

b. In Section 2, the paragraph starting with, "The terminology for the
   "Internet of Things" is still nascent, and...", is unclear and not
   easy to read. Specifically, the second sentence, "In this context,
   we need to differentiate between...", does not make sense and when
   taken in context of the first one, it is plain confusing.

c. The statement, "Hence, the management of a network with constrained
   devices might...", in Section 2 needs to be reworded as it is
   grammatically incorrect.

If I find more issues upon reading the document again, I shall post
them to the mailing list as well.

Warm regards,
Anuj Sehgal