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

["Ersue, Mehmet (NSN - DE/Munich)" <[e-mail]>]

Dear Anuj,

sorry for this late response and thank you for your thorough review. 
See my comments below.

Cheers, 
Mehmet 

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of ext
> Sehgal, Anuj
> Sent: Thursday, April 11, 2013 12:34 AM
> To: <[e-mail]>
> Subject: [coman] Review of draft-ersue-constrained-mgmt-03
> 
> 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.

The document talks on "Constrained devices, which are connected directly to the Internet or an IP network" and 
"Constrained devices, which are connected to the Internet or an IP network via a gateway/proxy".
As such it is not important whether the "very constrained" devices, which need the help of a proxy, are themselves able to use IP stack or not.

> 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?

It is true that they are defined and used in section 1.3. I think they should be used through 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.

Sure. At the time where this draft has been submitted, the LWIG terminology draft was not available.

> 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.

I still have the opinion that "the current management protocols seem to be too heavyweight compared to the capabilities the constrained devices". If we say "current management protocols" we mean actually the current version of the protocol. And the current version of SNMP is version 3, which is btw strongly recommended to use by RFC 3410.
 
>    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.

There are different reasons why I wouldn't support SNMPv1 for constrained devices, however this is my personal opinion. Others might have other opinions. 
The fact that SNMPv1 is simple and easy to implement does not mean it is a state-of-the-art network management protocol.
 
> 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.

Agree, the use case sections need to be improved. Do you have any concrete suggestions for editing?
 
> 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...".

Agree, text revision makes sense. Any concrete suggestions for new text?
 
> 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 don't think so. Different people with mobile background were agreeing that such a section listing and summarizing the mobility scenarios as well as their technologies makes sense.
 
> 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.

Interesting proposal, which could be discussed on the maillist. BTW: The use case sections have been always contributor-driven.

> 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.

Please read 2nd paragraph of section 4. May be we should change the sentence as:

NEW:
A device might be able to provide only a particular profile of requirements (i.e. selected set of requirements) and might not be capable to provide all requirements in this document at once.
 
> 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.

Agree, the requirement types should be defined and the usage should be cross-checked for correctness.
 
> 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.

I tend to agree. Different device vendors might see different requirements as must-have.
 
> 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.

The title could be changed as: "Reliable unicast transport of messages". This was actually meant with the current version. 
What would be your proposal for a more precise and clearly worded description?
 
> 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.

This sentence needs a reformulation as the first part does not fit the second part.
 
> 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.

What you mean as the 2nd sentence is actually the 3rd sentence. And the 3rd sentence builds on the 2nd sentence. 
Or is there anything else 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.

I see here an issue of clarity and it can be solved somewhat easily.
 
> If I find more issues upon reading the document again, I shall post
> them to the mailing list as well.

Thank you again for your detailed review. I hope you can further contribute with text proposals.

> Warm regards,
> Anuj Sehgal
>
> _______________________________________________
> coman mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/coman