Subject: Re: [OPSAWG] Review of draft-ietf-opsawg-coman-use-cases-01

From: "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]>
Date: Tue, 24 Jun 2014 09:56:42 +0000

Hi Ulrich,

sorry for the delay. Thank You for your valuable comments.

Please find below a few answers to your questions on draft-ietf-opsawg-coman-use-cases-01.
I hope we can converge as it costs some time to discuss so many comments. Please ignore those where you accept my response.
We are going to update the draft now along these lines.

1) 2.  Access Technologies
UH> The abstract of this document states "This document discusses the use cases concerning the management of networks, where constrained devices are involved."
How is this section 2 related to the use cases? What is the purpose of this section?
ME: We think this section is useful as an introduction to the technologies mentioned in this draft.

2) 2.2.  Mobile Access Technologies
UH> Why is mobile access technologies a different classification from constrained access technologies? First, I would say that the access technology itself (e.g., 802.15.4) is not mobile, it's the devices that are mobile. Are these two sets distinct, i.e., is a device either mobile or constrained? Most likely it could be in both. Also, how is the mobility relevant? I understand that a dynamic topology can have an impact on management, but dynamicity can be caused by other factors than mobility, e.g., because of fluctuation of link quality.
ME: Assumedly we both read something else under "Mobile Access Technologies". While I think on 3G and 4G at the first place, you probably think on any access that allows some form of mobility. May be the title "Cellular Access Technologies" would be more appropriate.

3) 3.  Use Cases
UH> Maybe add a sentence that it is not claimed that this is a complete list. There could be more use cases unknown to the WG.
ME: Agree. Also change in the Abstract and the Introduction: s/the use cases/use cases/

4) 3.1.  Environmental Monitoring
UH> What about monitoring? That seems also important in this use case.
ME: This section particularly talks about monitoring.

5) Since these monitoring applications must be designed to tolerate a number of failures, the time scale for detecting and recording failures is for some of these applications likely measured in hours and repairs might easily take days.
UH> Are we talking about "hardware" failures? I assume that in such scenarios, it may not be cost-effective (or in case of a natural disaster, not feasible) to repair the devices. If there are enough devices deployed, a defective device could just be left without being repaired. That also means that the topology is created fully autonomously.
ME: Any kind of failures. We also don't recommend repairing such devices.

6) However, for certain environmental monitoring applications, much tighter time scales may exist and might be enforced by regulations (e.g., monitoring of nuclear radiation).
UH> In this text, and in general for the draft, maybe more explanations could be provided for each use case why classic Internet management is not possible, e.g., why can't I just use SNMP/Netconf in this case?

ME: This is discussed in ProbState draft. It can be mentioned here though. We think that we should focus on describing use cases and avoid discussing all possible options per use case.

7) As such, the network in use might be based on a combination of fixed and wireless technologies,  which use robust networking equipment and support reliable communication.
UH> If wireless technologies are used, how can robustness and reliable communication be guaranteed?
ME/JS: Robust in a sense that the equipment is not affected by the environment. We think it is about 'reliability'. For sure with an inherently unreliable link, you can only achieve a certain level of reliability. However the text does not say 'guarantee', this is something you added.
Reliable communication can be achieved via application layer transactions.

8) Devices that have energy management capability are defined as Energy Devices
UH> Where is that defined? In the eman-framework draft?

ME:  This has been defined in an early EMAN I-D and later got removed. It is mentioned in RFC 6988 but not in draft-ietf-eman-framework. Perhaps we can use "devices in the context of energy management".

9) It is assumed that Energy Management will apply to a large range of devices of all classes and networks topologies.
UH> assumed by whom?
ME: It is a general assumption of the editors. Change to: "it is generally assumed"

10) . . . Specific energy management applications or network islands use their own management mechanisms.
UH> This above text is well written and informative. But it is quite detailed about properties of energy management systems (could be shorted), but does not talk much about management.
ME: Agree, that it could be shortened.

11) 3.5.  Medical Applications
UH> Again, there is little text about specific management requirements (and why classic management tools cannot be used). This text only mentions privacy and fault detection. There are many more aspects (see my previous comment above). Would it be helpful to have a more systematic approach throughout the draft? e.g., a list of management properties that each use case lists and discusses? (e.g., - delay: this use case has no specific delay requirements - fault tolerance: this use case... etc.)

ME/JS: Such an approach might actually make sense but is also a lot of work. On the other hand, this would likely be more informative than the long list of requirements we have in the other I-D (and then we would be back to square one, merging the two documents at the end).

12) A building network can be composed of subnets, where a subnet covers a floor, an area on the floor, or a given functionality (e.g., security cameras).
UH> I would be careful using the word subnet. Is this used as the IP subnet (i.e., IP prefix)?
ME: I think the text is self-explanatory on its level. We can replace subnets with "network segments" (but then this might sound too
layer two specific). Though we prefer network segments.

13) This leads to the need that some components and subsystems operate in constrained conditions and are separately certified.
UH> I don't understand the meaning of the previous sentence.

ME: I don't know anymore who wrote this section but it could be probably reworded as:
"This leads to the need to certify components and subsystems operating in such constrained conditions based on specific requirements."

14) In the first case, there is a broader range of
   possible solutions, which can be planned for the infrastructure of
   the building.  In the second case the solution needs to be deployed
   over an existing structure taking into account factors like existing
   wiring, distance limitations, the propagation of radio signals over
   walls and floors.  As a result, some of the existing WLAN solutions
   (e.g., IEEE 802.11 or IEEE 802.15) may be deployed.
UH> What is the relevance of the two cases? Even in the first case of a newly designed building, WLAN solutions may be deployed.
ME: s/ structure / infra-structure /
The issues in the second case, where an existing infra-structure existing wiring, distance limitations, etc. makes the deployment difficult.

15) During installation, the setting of parameters to common values to enable interoperability may occur (e.g., Trickle parameter values).
UH> This needs more explanation how Trickle is used here (I am not sure it is relevant here, but if so, needs to be explained).
UH> Isn't installation a short, one-time occurrence compared to the long life-time of the network? Why is this relevant for the use case?
ME: s/ to enable interoperability may occur (e.g., Trickle parameter values)./ to enable interoperability may be required./

16) UH> See previous comments for other use cases; there is not much text about management, and no systematic analysis regarding different management properties.
ME: We will try to address this.

17) However, unlike a building automation system, the infrastructure in a home is operated in a considerably more ad-hoc manner, with no centralized management system akin to a Building Automation System (BAS) available.
UH> It depends. There are commercial systems available on the market with a centralized controller (e.g., Lowes Iris). Often, cloud-based controllers are used as well.
ME/JS/AS: Needs a rewording. However, this is an evolving market compared to building automation. And yes, it is likely outsourced and cloud based while adoption of such an approach for classic building automation is likely much slower because of more complicated legal and responsibility issues.

It seems that home automation infrastructures are now deployed in a more ad-hoc manner, but most likely managed by a central management server (either at home or in the cloud).

18) Management responsibility typically rests within the organization running the transport application.
UH> Who is that? Which transport application? In the example of an in-car network, I assume there is a variety of different sensors communicating with a variety of different servers and operators (e.g., safety sensors communicate with emergency services, entertainment devices with streaming / content providers
ME/JS: Transport systems and transport applications have been described at the beginning of the section. In-car network is only a specifc part of it.

In general Transport Applications need an IT infrastructure to run on e.g. in a train, bus or metro. We need to clarify this.

19) Scenarios consisting of vehicle-to-vehicle ad-hoc networks, a wired backbone with wireless last hops,
UH> What is a "last hop"?
ME/JS/AS: Change to "Scenarios consisting of vehicle-to-vehicle ad-hoc networks, which use a wired backbone with wireless access to vehicles."

20) it would be important for a NMS to be able to function with different architectures, since different manufacturers might have their own proprietary systems.
UH> What kind of architectures? Do you mean management protocols?
ME: s/ might have their own proprietary systems / might have their own proprietary systems relying on a specific Management Topology Option as described in [COM-REQ]./

21) Unlike some mobile networks, most vehicular networks are expected to have specific patterns in the mobility of the nodes.  Such patterns could possibly be exploited, managed and monitored by the NMS.
UH> How so? Why?
ME/JS: We can change: "mobile networks" to "general cellular networks" and if needed add "(people commuting to work)".
You have a point that cell phones also have these patterns but likely more noise, since people also move without cars.

22) Constant changes in topology must also be contended with.
UH> Is that the task of the NMS? Or rather the routing protocol?
ME/JS: Constantly changing topology is an issue since topology needs to be tracked in order to do management.

23) Auto-configuration of nodes in a vehicular network remains a challenge since based on location, and access network, the vehicle might have different configurations that must be obtained from its management system.
UH> Are we talking about auto-configuration of IP addresses? That was not addresses in any of the other use cases, and is a different (although indeed challenging) kind of management (pre-deployment vs management during operation), likely not involving an NMS.

ME: The text does not say anything on IP addresses. This is configuration on application level. It could be reworded as "autimatic configuration".

24) 5.  Security Considerations
UH> This is a short section. Would be good to talk to someone from the SEC directorate ahead of a WGLC, to make sure this is sufficient.
ME: The draft is Informational. We will seek for feedback on how to extend the current section during WGLC.

Cheers,
Mehmet

From: OPSAWG [mailto:[email-masked]] On Behalf Of ext Ulrich Herberg
Sent: Tuesday, March 04, 2014 12:57 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [OPSAWG] Review of draft-ietf-opsawg-coman-use-cases-01

Hello,
I have reviewed the draft in the subject (see attachment). It is interesting to read and provides insights into management of constrained devices. Again, I am glad to see that the COMAN work has found a home in OPSAWG.
I believe the draft needs some more work. I understand that the different sections have been written by different contributors, and each of them is very interesting to read. However, the draft would benefit from having the editors unify the description of management properties and challenges. Each use case picks a few different properties for management of the use case (e.g., acceptable delay, privacy etc). Maybe it would be beneficial to agree on a list of properties that each of the use cases must discuss. Also, it would be helpful for each use case to understand why we can't just use SMTP/Netconf.
Use cases 3.8 and 3.9 seem redundant.

Best regards
Ulrich

---

From: Ulrich Herberg <[email-masked]>
Date: Tue, 24 Jun 2014 11:47:16 -0700

Hi Mehmet,

Thanks for your detailed answers. I will look at it in detail in the
next few days and then reply to the list.

Best regards
Ulrich

On Tue, Jun 24, 2014 at 2:56 AM, Ersue, Mehmet (NSN - DE/Munich)
<[email-masked]> wrote:
> I hope we can converge as it costs some time to discuss so many comments.
> Please ignore those where you accept my response.
>
> UH> The abstract of this document states "This document discusses the use
> cases concerning the management of networks, where constrained devices are
> involved."
>
> UH> Why is mobile access technologies a different classification from
> constrained access technologies? First, I would say that the access
> technology itself (e.g., 802.15.4) is not mobile, it's the devices that are
> mobile. Are these two sets distinct, i.e., is a device either mobile or
> constrained? Most likely it could be in both. Also, how is the mobility
> relevant? I understand that a dynamic topology can have an impact on
> management, but dynamicity can be caused by other factors than mobility,
> e.g., because of fluctuation of link quality.
>
> ME: Assumedly we both read something else under “Mobile Access
> Technologies”. While I think on 3G and 4G at the first place, you probably
> think on any access that allows some form of mobility. May be the title
> "Cellular Access Technologies" would be more appropriate.
>
>
>
> 3) 3.  Use Cases
>
> UH> Maybe add a sentence that it is not claimed that this is a complete
> list. There could be more use cases unknown to the WG.
>
> 5) Since these monitoring applications must be designed to tolerate a number
> of failures, the time scale for detecting and recording failures is for some
> of these applications likely measured in hours and repairs might easily take
> days.
>
> UH> Are we talking about "hardware" failures? I assume that in such
> scenarios, it may not be cost-effective (or in case of a natural disaster,
> not feasible) to repair the devices. If there are enough devices deployed, a
> defective device could just be left without being repaired. That also means
> that the topology is created fully autonomously.
>
> ME: Any kind of failures. We also don’t recommend repairing such devices.
>
>
>
> 6) However, for certain environmental monitoring applications, much tighter
> time scales may exist and might be enforced by regulations (e.g., monitoring
> of nuclear radiation).
>
> UH> In this text, and in general for the draft, maybe more explanations
> could be provided for each use case why classic Internet management is not
> possible, e.g., why can't I just use SNMP/Netconf in this case?
>
> ME: This is discussed in ProbState draft. It can be mentioned here though.
> We think that we should focus on describing use cases and avoid discussing
> all possible options per use case.
>
>
>
> 7) As such, the network in use might be based on a combination of fixed and
> wireless technologies,  which use robust networking equipment and support
> reliable communication.
>
> ME/JS: Robust in a sense that the equipment is not affected by the
> environment. We think it is about 'reliability'. For sure with an inherently
> unreliable link, you can only achieve a certain level of reliability.
> However the text does not say 'guarantee', this is something you added.
>
> ME:  This has been defined in an early EMAN I-D and later got removed. It is
> mentioned in RFC 6988 but not in draft-ietf-eman-framework. Perhaps we can
> use “devices in the context of energy management”.
>
>
>
> 9) It is assumed that Energy Management will apply to a large range of
> devices of all classes and networks topologies.
>
> UH> assumed by whom?
>
> UH> This above text is well written and informative. But it is quite
> detailed about properties of energy management systems (could be shorted),
> but does not talk much about management.
>
> UH> Again, there is little text about specific management requirements (and
> why classic management tools cannot be used). This text only mentions
> privacy and fault detection. There are many more aspects (see my previous
> comment above). Would it be helpful to have a more systematic approach
> throughout the draft? e.g., a list of management properties that each use
> case lists and discusses? (e.g., - delay: this use case has no specific
> delay requirements - fault tolerance: this use case... etc.)
>
>
>
> ME/JS: Such an approach might actually make sense but is also a lot of work.
> On the other hand, this would likely be more informative than the long list
> of requirements we have in the other I-D (and then we would be back to
> square one, merging the two documents at the end).
>
>
>
> 12) A building network can be composed of subnets, where a subnet covers a
> floor, an area on the floor, or a given functionality (e.g., security
> cameras).
>
> ME: I think the text is self-explanatory on its level. We can replace
> subnets with "network segments" (but then this might sound too
>
> 13) This leads to the need that some components and subsystems operate in
> constrained conditions and are separately certified.
>
> ME: I don’t know anymore who wrote this section but it could be probably
> reworded as:
>
> “This leads to the need to certify components and subsystems operating in
> such constrained conditions based on specific requirements.”
>
>
>
> UH> What is the relevance of the two cases? Even in the first case of a
> newly designed building, WLAN solutions may be deployed.
>
> The issues in the second case, where an existing infra-structure existing
> wiring, distance limitations, etc. makes the deployment difficult.
>
>
>
> 15) During installation, the setting of parameters to common values to
> enable interoperability may occur (e.g., Trickle parameter values).
>
> UH> This needs more explanation how Trickle is used here (I am not sure it
> is relevant here, but if so, needs to be explained).
>
> UH> Isn't installation a short, one-time occurrence compared to the long
> life-time of the network? Why is this relevant for the use case?
>
> ME: s/ to enable interoperability may occur (e.g., Trickle parameter
> values)./ to enable interoperability may be required./
>
>
>
> 16) UH> See previous comments for other use cases; there is not much text
> about management, and no systematic analysis regarding different management
> properties.
>
> 17) However, unlike a building automation system, the infrastructure in a
> home is operated in a considerably more ad-hoc manner, with no centralized
> management system akin to a Building Automation System (BAS) available.
>
> UH> It depends. There are commercial systems available on the market with a
> centralized controller (e.g., Lowes Iris). Often, cloud-based controllers
> are used as well.
>
> ME/JS/AS: Needs a rewording. However, this is an evolving market compared to
> building automation. And yes, it is likely outsourced and cloud based while
> adoption of such an approach for classic building automation is likely much
> slower because of more complicated legal and responsibility issues.
>
> It seems that home automation infrastructures are now deployed in a more
> ad-hoc manner, but most likely managed by a central management server
> (either at home or in the cloud).
>
>
>
> UH> Who is that? Which transport application? In the example of an in-car
> network, I assume there is a variety of different sensors communicating with
> a variety of different servers and operators (e.g., safety sensors
> communicate with emergency services, entertainment devices with streaming /
> content providers
>
> ME/JS: Transport systems and transport applications have been described at
> the beginning of the section. In-car network is only a specifc part of it.
>
> In general Transport Applications need an IT infrastructure to run on e.g.
> in a train, bus or metro. We need to clarify this.
>
>
>
> ME/JS/AS: Change to "Scenarios consisting of vehicle-to-vehicle ad-hoc
> networks, which use a wired backbone with wireless access to vehicles."
>
>
>
> 20) it would be important for a NMS to be able to function with different
> architectures, since different manufacturers might have their own
> proprietary systems.
>
> ME: s/ might have their own proprietary systems / might have their own
> proprietary systems relying on a specific Management Topology Option as
> described in [COM-REQ]./
>
>
>
> 21) Unlike some mobile networks, most vehicular networks are expected to
> have specific patterns in the mobility of the nodes.  Such patterns could
> possibly be exploited, managed and monitored by the NMS.
>
> UH> How so? Why?
>
> ME/JS: We can change: “mobile networks” to “general cellular networks” and
> if needed add "(people commuting to work)".
>
> You have a point that cell phones also have these patterns but likely more
> noise, since people also move without cars.
>
>
>
> 23) Auto-configuration of nodes in a vehicular network remains a challenge
> since based on location, and access network, the vehicle might have
> different configurations that must be obtained from its management system.
>
> UH> Are we talking about auto-configuration of IP addresses? That was not
> addresses in any of the other use cases, and is a different (although indeed
> challenging) kind of management (pre-deployment vs management during
> operation), likely not involving an NMS.
>
>
>
> ME: The text does not say anything on IP addresses. This is configuration on
> application level. It could be reworded as “autimatic configuration”.
>
>
>
> UH> This is a short section. Would be good to talk to someone from the SEC
> directorate ahead of a WGLC, to make sure this is sufficient.
>
> To: [email-masked]
> I have reviewed the draft in the subject (see attachment). It is interesting
> to read and provides insights into management of constrained devices. Again,
> I am glad to see that the COMAN work has found a home in OPSAWG.
>
> I believe the draft needs some more work. I understand that the different
> sections have been written by different contributors, and each of them is
> very interesting to read. However, the draft would benefit from having the
> editors unify the description of management properties and challenges. Each
> use case picks a few different properties for management of the use case
> (e.g., acceptable delay, privacy etc). Maybe it would be beneficial to agree
> on a list of properties that each of the use cases must discuss. Also, it
> would be helpful for each use case to understand why we can't just use
> SMTP/Netconf.
>