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

From: Ulrich Herberg <[email-masked]>
Date: Wed, 2 Jul 2014 11:53:45 -0700

Hi Mehmet,

I finally got to reading your response, and I appreciate having
addressed all my comments. I am looking forward to see the new
revision.

Regards
Ulrich

On Tue, Jun 24, 2014 at 2:56 AM, Ersue, Mehmet (NSN - DE/Munich)
<[email-masked]> wrote:
> 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]
> 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