Hi, the recent discussions about the network model enticed me to share some thoughts about modeling with you. There are two approaches to modeling, bottom-up or top-down. Bottom-up here means starting with a blank sheet of paper and design as it fits the requirements. With top-down, I'm referring to starting with an existing model, stripping and refactoring it until it fits. Both approaches have their pros and cons, neither is 'right' or 'wrong' per-se. It all depends. And modeling is hard, sometimes very hard if you have widely spread requirements. Grasping the result can be equaly hard, esp. if the requirements which led to the model are not known. In this situation, doing the bottom-up approach is the easiest and most rewarding as it leads quickly to a result matching current requirements. However, one has to be very aware of the limitations and that extending the model to fit additional needs might be very hard or even impossible. About two years ago, the Open Management Consortium (http://www.openmanagement.org, offline since months) was formed to unify the various open source system management approaches. Founding members included the 'big four', namely Zenoss, Hyperic, GroundWorks, and openQRM. Their initial goal was to agree on a protocol and eventually a single client daemon. So they organized a BarCamp and discussed protocols and models. Someone even showed a presentation bragging about how useless and bloated CIM was. Understandable, knowing that their main focus was on monitoring. Their collaboration approach never resulted in any concrete project. The Open Management Consortium seems to have dissolved in the meantime, I haven't seen any traffic on the mailing list for months. But there's more to system management than just monitoring. A lot more. If the monitoring console shows something red, you want to manage it (restart, re-configure, update, ...) and bring it back to green. If a network router failed, you need to know where it is (physically), what services the outage affects, and how to order a replacement unit. All this is covered in a CIM model. It tries to encompass all requirements of system management, which are many. (ITIL, http://en.wikipedia.org/wiki/Information_Technology_Infrastructure_Library, gives a nice glimpse into this whole area.) And CIM is a fully normalized model, which is not really helping to make it easily understandable. But its helping to make it flexible and useful for a lot of use cases. (For the curious, here is a nice introduction into CIM modeling: http://www.cisl.ucar.edu/nets/intro/staff/siemsen/nandisc/dmtf/cim-2.5/tutor...) Its interesting to note that all major computing vendors build their management solutions on top of the CIM model. Microsoft, IBM, Dell, HP, Sun, Intel, Cisco, Apple, just to name a few. Now how does all this apply to WebYaST ? Going the easy path of bottom-up is acceptable, if the limitations and consequences for future extensions are known and documented. Its also harder to reuse upstream work. As WebYaST grows and implements more functionality, such a (self-designed) model might quickly reach its limits. Going the harder path of top-down will be more work up front but make it easier in the future to extend it and reuse upstream work. If WebYaST is successful, requirements will come to support discovery, inventory, root cause analysis, more network types, routing, etc. All this is already taken care of in the CIM model, we could be standing on the shoulders of giants. Klaus --- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org