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 protected]> 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 protected]] On Behalf Of ext Ulrich > Herberg > Sent: Tuesday, March 04, 2014 12:57 PM > To: [email protected] > 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 _______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
