Re: [OPSAWG] Review of draft-ietf-opsawg-coman-probstate-reqs-01

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

Hi Ulrich,

I'm sorry for being late. Thank You for your valuable comments.

Please find below some answers to your questions on draft-ietf-opsawg-probstate-reqs-01.
I hope we can converge soon. Please ignore those where you accept my response.
We are going to update the draft along these lines.


1) "Such a network of constrained devices itself may be constrained or challenged, e.g. with unreliable or lossy channels, wireless technologies with limited bandwidth and a dynamic topology, needing the service of a gateway or proxy to connect to the Internet."
UH> I wonder about the reason for adding the last part of the sentence, starting with "needing the service...". Is that a consequence of constraint networks? What is "connecting to the Internet" anyway? Do you mean application-layer translation between protocols especially designed for constrained devices/networks and standard IP protocols?
ME: It is actually exactly what the sentence lists at the beginning. The network might be constrained such that it is not possible to connect directly to the Internet. A gateway or proxy might be needed, which provides a network card using standard IP protocols. I agree application-layer translation between protocols (such as CoAP vs. HTTP) might be also necessary but this is more an issue for the device.

2) "The traditional network management application periodically collects information from a set of elements that are needed to manage, processes the data, and presents them to the network management users."
UH> What is the "traditional network management application"? Is that a particular protocol? Does it have to be periodically? Could be on-demand as well. Maybe it would also be helpful to differentiate between management and monitoring as two different actions.
ME/JS: I agree the term "traditional network management application" is not accurate enough. It could be changed to "traditional network monitoring application". For the On-demand case the application can poll the device as needed. Many traditional network management applications do periodic polls and if it is just to check whether devices are still there.

3) "Constrained devices, however, often have limited power, low transmission range, and might be unreliable."
UH> Is the device unreliable (e.g., because it often crashes?) or the communication medium? (i.e., high loss rate)
ME: The device is unreliable in a sense that it might use unreliable or lossy channels or is only active 5% of the time and sleeping the rest.

4) "They might also need to work in hostile environments with advanced security requirements"
UH> I wonder whether that is so different from "classical" IP-based management. I would consider management via the Internet to be a hostile environment. Is this really related to management of constrained devices?
ME/JS: These advanced security requirements might be the same in the classical IP networks. The point here is that in hostile environments devices are usually placed outside of a nice (server) room in an environment that by itself is difficult to secure and the protection of the device is much harder.

5) "Due to such constraints, the management of a network with constrained devices offers different"
UH> maybe "face" challenges, instead of "offer" challenges?
ME: OK.

6) "Note that the requirements in Section 3 need to be seen as standalone, where different implementer may decide to realize a different set of requirements."
UH> I don't understad the last sentence. What does it mean to "be seen as standalone"?
ME/JS: We do not provide a profile of requirements, i.e. a set of requirements which fit together and can be implemented as a set.
The requirements need to be discussed standalone i.e. one-by-one. It could be rephrased as below:


"Note that the requirements listed in Section 3 have been separated

from the context in which they may appear. Depending on the

concrete circumstances, an implementer may decide to address only a

certain relevant subset of the requirements listed."


7) "AMI:  (Advanced Metering Infrastructure) A system including hardware,
      software, and networking technologies that measures, collects, and
      analyzes energy usage, and communicates with a hierarchically
      deployed network of metering devices, either on request or on a
      schedule."
UH> Is there no existing definition that we can re-use? If not by IETF, maybe from FERC or elsewhere? This definition lacks several aspects that could potentially be important for the management, such as low-bandwidth medium, lossy channel, multi-hop communication, traffic patterns (P2MP, MP2P), typical number of routers, limited MTU, etc. I am not sure whether these are relevant for this draft or not, I just think that we should check whether the definition here is sufficient.
[ME] The term definition for AMI comes from the Smart Grid environment and as such does not have to do necessarily with constrained networks. AMI does not necessarily imply a low-bandwidth medium or a lossy channel etc.

8) "Network of Constrained Devices:  A network to which constrained devices are connected"
UH> I'd say that devices are not connected to a network, but that they "form" a network.
[ME] What you say is true for wireless adhoc networks. In general there might be a network connection point (e.g. a base station) where devices have to connect.

9) " M2M:  (Machine to Machine) stands for the automatic data transfer
      between devices of different kind.  In M2M scenarios a device
      (such as a sensor or meter) captures an event, which is relayed
      through a network (wireless, wired or hybrid) to an application.
UH> I haven't checked, but it seems that this might already have been defined somewhere else.
[ME] I am sure there are better sources. May be we should add a reference saying: " As defined in". Do you have a concrete proposal for a reference?

10) "MANET:  Mobile Ad-hoc Networks, a self-configuring and
      infrastructureless network of mobile devices connected by wireless
      technologies."
UH> In the MANET WG, RFC2501 is often cited as definition of a MANET (although worthy of updating)
[ME] A reference to RFC2501 would be good.

11) "Smart Grid:  An electrical grid that uses communication technologies
      to gather and act on information in an automated fashion to
      improve the efficiency, reliability and sustainability of the
      production and distribution of electricity."
UH> Again, were there considerations to reuse existing definitions? There could be said more about smart grid, although I realize you wanted to provide a very short definition. Maybe replace "production and distribution of" by "generation, transmission and distribution of"?
[ME] OK for your proposal. Unfortunately I don't know anymore where I got this. We should give a reference.

12) In this document we differentiate following type of networks
UH> s/type/types/
ME: OK

13) Note that a network in general can involve constrained and non-constrained devices.
UH> This sentence seems somehow misplaced (after the previous sentence with the colon, I expected the list right away).
ME: We should put this in parenthesis.

14) UH> In general, I find the following classification a bit arbitrary. I could easily imagine splitting some of the categories up, or merging them. The classification mixes traffic flows, link layer types, routing protocol vs static route etc. I don't understand what purpose this section has.
ME: It aims to discuss different type of networks in focus and their characteristics. There might be indeed different classifications possible. Do you have a proposal for improvement?

15)   2.  A combination of wireline and wireless networks, which may or may
       not be mesh-based but have a multi-hop connectivity between
       constrained devices, utilizing dynamic routing in both the
       wireless and wireline portions of the network.
UH> The sentence is complicated to understand. What is the relevance for mesh-based or not? The sentence mixes different link layer types, different connectivity architectures and routing protocol vs static routes in a single sentence. Would a network with both a few static routes and a routing protocol together be out of scope?
ME: I suggest to delete the mesh-based part and change as: "A combination of wireline and wireless networks, possibly with a multi-hop connectivity between constrained devices, utilizing dynamic routing in both the wireless and wireline portions of the network."

16)  Such networks usually support highly distributed applications with many nodes (e.g. environmental monitoring) and tend to deal with large-scale multipoint-to-point systems with massive data flows.
UH> I am not sure about that. In a MANET with a connected wired network, I would still not expect large-scale massive data flows inside the MANET.

ME: We should remove "massive data flows" since 'massive' is undefined anyway.

17) Wireless Mesh Networks (WMN), as a specific variant
UH> How is a WMN (which is the same as a MANET in my opinion) a variant of a "combination of wireline and wireless networks"? Wouldn't it typically be only a wireless network?
ME: Wireless Mesh Networks might be centrally managed or controlled, which differentiates from MANET. We introduced the term "Self-configuring infrastructure-less networks" as an umbrella term and avoid to use MANET.


18) have often a more planned deployment to provide dynamic and cost effective connectivity over a certain geographic area.
UH> That depends on the use case, in my opinion. They may offer various degrees of redundancy, reliability and pre-planned deployment. How is "cost-effective" relevant for management?

ME: We are describing the network types and not the management. Note that 'often' does not mean 'always'.

19) UH> Again, I don't see why the above section is relevant. And if so, I am not convinced about the classification.
ME: Agree, there might different type of classifications. This is one of them.

20) o  Constrained devices, which are connected to the Internet or an IP network via a gateway/proxy
UH> Again, sounds like the same case as the previous two cases
ME: This can be indeed deleted.

21) UH> I am a bit puzzled about the purpose of this section, as well as the particular selection of classifications.
ME: The different deployment options might require a specific management support. I'm fine if this section is not needed.

22)   o  might possibly generate a huge amount of redundant reporting data,
      i.e. the intermediary management entity (see [I-D.ietf-core-coap])
      should be able to filter and aggregate redundant data.
UH> This is quite an interesting and long list. Should we add classifications? Or add a note that this list is just a few examples and does not claim completeness?
ME: This indeed a long list of examples and should be named as such.

23) manual configuration is typically not feasible.
UH> Manual configuration of what?

ME/JS: should read: "configuration device-by-device" or similar.

s/manual configuration/manual configuration of nodes/

24)   CL6:  Devices support configuration change transactions across devices.
UH> Interesting classification! Does it mean that increasing levels include the lower levels, e.g., that CL5 is a subset of CL6?
ME: Some are a superset of the former. Some can be realized independently though the implementation complexity is increasing.

25)   Devices often also provide different levels of monitoring support:
UH> I would change that sentence to something like "This document defines a classification of devices with regards to different levels of monitoring support. If a device supports monitoring, it can be classified in one of the following levels. Levels are constructed in a hierarchy, i.e., higher levels are a superset of lower levels (e.g., an ML1 device is automatically also M0)."
If there is no hierarchy, then maybe we should add that a device may be in several of the groups.
ME/JS: In general higher levels are not a superset of lower levels. ML1 does not require to have support for ML0. We can to state that a device may be in several of the groups.

26)   Constrained devices often implement a combination of one of FL0-FL2 with one of ML0-ML1.
UH> If the previous sentence is required, add something like "as of 2014", since the RFC (if this document is approved) will be around for some time, and observations such as these may change over time.
ME: I prefer to say: At the time of this writing.
s/FL0-FL2/CL0-CL2/

27) As of today this document does not recommend the realization of a profile of requirements.
UH> What does this sentence mean?
ME: A "profile of requirements" are a set of requirements which are supposed to fit together and build a useful package.

28) UH> The below numbers have four digits, e.g., "1.003". What's the meaning of the dot between the 1 and 003?
ME: The digit before the dot is the subsection number. It helps to build packages of requirements.

29) A functional requirement is related to a proposed function or component.
UH> Proposed where? For what? (device / protocol?)
ME: s/proposed//

30) Hence, the management architecture must be applicable to networks
UH> is this a must or a MUST? That applies to all of the requirements below
ME/JS: As this is an Informational document, we need to be careful with capital letter MUST. Unless forced by the IESG, we prefer to not use any MUST / SHOULD language.

31) entity is able to handle huge amount of device monitoring data and
UH> How is "huge amounts" defined? Is that 1MB? 1GB? Does it depend on the time (1MB in 1 second or in one minute?)
UH> Is the "managing entity" the NMS? Or does it also apply to the "managed device", i.e., the device that is managed by the NMS?
ME: I don't have concrete numbers for the expected amount of data.
ME: NMS is usally defined on a higher level. It is meant to be the entity where the management application is connected to the managed device.
The scalability within a device is kept out here.
s/huge/large/ throughout the document.

32) the management protocol is not sensitive to the decrease of the time between two client requests.
UH> "not sensitive" (at all?); does it mean if I send a trillion requests within a nano-second, the device should still be able to handle it? At some point, this would always become a problem, even for non-constrained devices.
UH> For me as implementer, it would be hard to verify whether an implementation is scalable, based on this definition. The definition is a bit vague, and so I don't know at what point an implementation of a probable is scalable.
ME: There is always a worst case which breaks the system. It is meant to be a functional decrease.
ME: I think such a requirement cannot be very concrete providing min-max values.

33)   Source:  Use cases where a huge amount of devices are deployed with a hierarchical topology.
UH> How is "huge" defined?
ME: Huge such that a hierarchical management makes sense and using aggregation and caching mechanisms would be valuable to reduce the amount of management data.

34)   Priority:  Medium
UH> How did you define the priority? Doesn't that depend on the use case? If I want to manage 20 devices, I assume priority for hierarchies is low. For 1,000,000 devices, it may be high.
ME: We are talking here on use cases where a huge amount of devices are deployed.

35)   Title:  Minimize state maintained on constrained devices.
UH> Do we need to quantify that? At what point is the state "minimized"? 1kB? 1MB?
ME: I would prefer to keep it as general requirement without quantifying with numbers.

36)   Title:  Support for lossy links and unreachable devices.
UH> Is lossy links not a property of constrained networks (vs constrained devices)? So far, the text addressed constrained devices.
ME: Yes. The devices can be unreachable because of lossy links.

37)   Title:  Modular implementation of management protocols
UH> Isn't that generally a good idea in software engineering? Why is this specific to management for constrained devices?
ME/JS: The idea here is to provide standards which define optional modules to implement.
While modularity may be a good software engineering practice, modularity is crucial to fit things on constrained devices and hence this should be spelled out. Also note that good software engineering practice modularity may not be the modularity needed on constrained devices. While you can easily achieve modularity by breaking things into multiple processes on a Unix platform, this may be a bad approach for an embedded device where a single event-driven
process may be much less resource consuming.

38)   Source:  Use cases where it is beneficial to reduce transmission time and bandwith, e.g. mobile applications which require to save on- air bandwith.
UH> Transmission time reduction and bandwidth reduction is a different thing. For example, it may be desirable to reduce a message from 2kB to 500 bytes so that it is lower than the MTU of the channel and therefore to avoid fragmentation. In terms of transmission time, it may not really make much of a difference.
ME: I agree it is not a linear function but in general reducing msg size helps to reduce transmission time and bandwidth.

39)   Title:  Consistency of data models with the underlying information model.
UH> Can you explain this requirement a bit more? What does "consistent" mean? A subset? What if new elements are required in a data model for constrained devices (e.g., duty cycle); how can that be represented in the data model, assuming it is not part of a data model of management protocols for non-constrained devices? (BTW, is this constrained network or device in the above paragraph?)
ME: The aim here is to use the same information model  (as the basis) for data models of both constrained and non-constrained devices to enable interoperability e.g. exchange of management information. The the same information model  used as a basis such that the constrained device can skip model elements though it is very useful if data model elements have the same data type.

40)   Title:  Loss-less mapping of management data models.
UH> How is this different from requirement 2.005? What does "loss-less" mean? Where can any loss happen?
ME: It is not the same. The mapping is not loss-less e.g. if you use two modeling languages where the data types of one language are not possible to construct with the available data types of the other language. There might be also a mapping loss on the level of any other language construct which cannot be mapped to any construct of the second language.

41)   Title:  Protocol extensibility
UH> Why is that specific to constrained device management? Wouldn't that also be a good idea in general for software that communicates over a network?
ME: You are right, this is generally interesting for (management) protocols.

42)   Description:  Provide a means of iterative network reconfiguration in order to recover the network functionality from node and
UH> How is "network functionality" defined?
ME: it would be good to delete the word "functionality"

43)   Title:  Energy status monitoring
UH> How is this different from 4.001? Couldn't device status also include energy status? (same question for following requirements)
ME: 4.001 is a generic requirement. This requirement focuses specifically on the monitoring of energy status.

44)   Title:  Network status monitoring
UH> What is the status of a network?
ME: There is no exhaustive definition of network status I know. It is meant to be network load, amount of faults etc. which are seen as an indication of the network functionality. One can look at some MIBs which are used for network (performance) monitoring, e.g. RMON2: RFC 4502 - Remote Network Monitoring Management Information Base Version 2 using SMIv2

45)   Title:  Self-monitoring
UH> What kinds of faults? Hardware? Or software bugs? Or network connectivity issues?
ME: This can anything which can be monitored by the device itself.

46)   Req-ID:  4.007 Title:  Fault detection monitoring
UH> How is this different from 4.005?
ME: This is a generic requirement mostly based on monitoring data device sends to the management applications without interpreting what it is.

47) The system collects information about network states in order to identify whether faults have occurred.
UH> Which states?
ME: This is the same issue like network status.

48)   Title:  Recovery
UH> How is this different from 4.005?
ME: The ability to recover from a faulty situation does not have to do with self-monitoring of the device.

49)   Req-ID:  5.001 Title:  Self-management - Self-healing
UH> This seems similar to some of the 4.00x requirements for recovery from faults. How is this different?
ME: I agree 5.001 is a super-set of 4.005

50) It might be necessary to downscale EMAN MIBs for the use in C1 and C2 devices.
UH> define "downscale"?
ME: A subset of. We could also simply remove this sentence.

51)   Req-ID:  9.002 Title:  Redirect traffic
UH> Is this only network management traffic? Or general traffic? How would this be done? Using ICMP redirects? This seems like a complicated thing to do in a distributed system.
ME: Traffic in general. The requirement does not provide solutions.

Perhaps title should be changed from 'redirect traffic' to 'reroute traffic' to avoid associations with ICMP redirects.

52)   Title:  Traffic delay schemes.
UH> Can you provide an example here for such a delay scheme?

ME: The title could be changed to: 'Traffic Shaping',

Description: Provide the ability to apply traffic shaping policies to incoming

            and outgoing links on an overloaded intermediary node as necessary

            in order to reduce the amount of traffic in the network.

53)   Req-ID:  10.001 Title:  Scalable transport layer
UH> How is "scalable" defined? Is TCP scalable?
ME: E.g. CoAP has a scalable transport behavior as it is not sensitive to the decrease of the time between two client requests, e.g. useful for applications requiring frequent access to device data.
TCP is not scalable because of the because of its slow response with large congestion windows. But there is research on how to get TCP scalable: http://datatag.web.cern.ch/datatag/papers/pfldnet2003-ctk.pdf

54) Req-ID:  10.002 Title:  Reliable unicast transport of messages
UH> What kind of acknowledgment? application layer? TCP? L2?
ME: Comparable with CoAP message acknowledgement on application layer.

55) Req-ID:  10.003 Title:  Best-effort multicast
UH> Can you define "best-effort multicast" in more detail?
ME: What we mean here is comparable with CoAP multicast. Best effort as in "no guarantee that data will be delivered".

56) Req-ID:  10.004 Title:  Secure message transport.
UH> What is the definition of "small footprint"? TLS is not necessarily a small footprint, I would say.
ME/JS: As long as you do crypto in software, there is no difference between the security protocols since the big hit are the crypto functions, both in runtime as well as code size. If you have hardware crypto on board (which is indeed preferable), then the main difference between say TLS and SSH is that SSH requires much more round trips than TLS. "small footprint" should be avoided. Remove 'with small footprint'.

57) Req-ID:  11.001 Title:  Avoid complex application layer transactions requiring large application layer messages.
UH> What kind of layer transactions do you have in mind? Isn't this requirement in general (even for non-constrained devices) a good software engineering practice?
Req-ID:  11.002 Title:  Avoid reassembly of messages at multiple layers in the protocol stack.
UH> Isn't this requirement in general (even for non-constrained devices) a good software engineering practice?
ME/JS: Yes but in case of constrained devices these requirements become more obvious. On regular platforms, for efficiency reasons, you often go for larger messages. But on constrained devices, due to a serious lack of memory, it is crucial to avoid buffering and in extreme cases, it is important to be able to make useful progress with every IP datagram received.

58) 5.  Security Considerations
UH> I think there could be said more about security here. Not sure that this will fly with the SEC ADs, so maybe a heads-up before a WGLC would be good to make sure this does not require more work.
ME: This is an open issue. The use case draft has a better Secuirty Considerations section.

Cheers,
Mehmet

From: OPSAWG [mailto:[e-mail]] On Behalf Of ext Ulrich Herberg
Sent: Tuesday, March 04, 2014 11:33 AM
To: [e-mail]<mailto:[e-mail]>
Subject: [OPSAWG] Review of draft-ietf-opsawg-coman-probstate-reqs-01

Hello,
I just joined the mailing list, so I apologize if I have missed some previous reviews of the draft in the subject.
I think the draft is quite interesting and that the COMAN topic is relevant for the IETF. I have been previously assisting in drafting some text for the two COMAN drafts from Mehmet, and I am glad to see that the OPSAWG is interested.
See the attachment for my review (or should I copy & paste it into the email?). Overall, I think the draft needs some more work, but is interesting to read and provides a lot of insight into management of constrained devices.
Best regards
Ulrich