Return-Path: Received: by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) id MAA09544 for nmrg-outgoing; Mon, 29 Jan 2001 12:12:28 +0100 (MET) Received: from henkell.ibr.cs.tu-bs.de (schoenw@henkell [134.169.34.191]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) with ESMTP id MAA09537; Mon, 29 Jan 2001 12:12:25 +0100 (MET) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id MAA05486; Mon, 29 Jan 2001 12:12:25 +0100 Date: Mon, 29 Jan 2001 12:12:25 +0100 Message-Id: <200101291112.MAA05486@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: nmrg@ibr.cs.tu-bs.de CC: boros@cs.utwente.nl In-reply-to: <200101262327.AAA29168@henkell.ibr.cs.tu-bs.de> (message from Juergen Schoenwaelder on Sat, 27 Jan 2001 00:27:46 +0100) Subject: Re: [nmrg] Minutes of 8th NMRG meeting References: <3A6EA4B9.946A5D6@cs.utwente.nl> <200101262327.AAA29168@henkell.ibr.cs.tu-bs.de> Sender: owner-nmrg@ibr.cs.tu-bs.de Precedence: bulk >>>>> Juergen Schoenwaelder writes: Juergen> Thanks very much to szabi and boros for writing up the Juergen> minutes. I have put them on the NMRG web site now. The thanks go of course to Szabolcs Boros and Robert Parhonyi. I am sorry for mixing up these two names. /js Return-Path: Received: by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) id AAA17128 for nmrg-outgoing; Sat, 27 Jan 2001 00:27:48 +0100 (MET) Received: from henkell.ibr.cs.tu-bs.de (schoenw@henkell [134.169.34.191]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) with ESMTP id AAA17123; Sat, 27 Jan 2001 00:27:46 +0100 (MET) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id AAA29168; Sat, 27 Jan 2001 00:27:46 +0100 Date: Sat, 27 Jan 2001 00:27:46 +0100 Message-Id: <200101262327.AAA29168@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: boros@cs.utwente.nl CC: nmrg@ibr.cs.tu-bs.de In-reply-to: <3A6EA4B9.946A5D6@cs.utwente.nl> (message from Szabolcs Boros on Wed, 24 Jan 2001 10:47:37 +0100) Subject: Re: [nmrg] Minutes of 8th NMRG meeting References: <3A6EA4B9.946A5D6@cs.utwente.nl> Sender: owner-nmrg@ibr.cs.tu-bs.de Precedence: bulk >>>>> Szabolcs Boros writes: Szabolcs> Below are the minutes from the 8th NMRG meeting in Austin, Szabolcs> TX. szabi boros Thanks very much to szabi and boros for writing up the minutes. I have put them on the NMRG web site now. /js Return-Path: Received: by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) id KAA06243 for nmrg-outgoing; Wed, 24 Jan 2001 10:56:21 +0100 (MET) Received: from utrhcs.cs.utwente.nl (utrhcs.cs.utwente.nl [130.89.10.247]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) with ESMTP id KAA06239 for ; Wed, 24 Jan 2001 10:56:20 +0100 (MET) Received: from zeus.cs.utwente.nl (zeus.cs.utwente.nl [130.89.10.12]) by utrhcs.cs.utwente.nl (8.9.3/8.9.3) with ESMTP id KAA01853 for ; Wed, 24 Jan 2001 10:56:17 +0100 (MET) Received: from cs.utwente.nl by zeus.cs.utwente.nl (8.8.8+Sun/csrelay-Sol1.4/RB) id KAA20338; Wed, 24 Jan 2001 10:56:18 +0100 (MET) Message-ID: <3A6EA6C7.CCBA73B1@cs.utwente.nl> Date: Wed, 24 Jan 2001 10:56:23 +0100 From: Szabolcs Boros Organization: UTwente X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: hu,en,ro,nl MIME-Version: 1.0 To: Network Management Research Group Subject: [nmrg] Minutes of 8th NMRG meeting References: <3A6EA4B9.946A5D6@cs.utwente.nl> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-nmrg@ibr.cs.tu-bs.de Precedence: bulk Szabolcs Boros wrote: > > Below are the minutes from the 8th NMRG meeting in Austin, TX. > szabi boros > Comments are, of course, welcome... szabi Return-Path: Received: by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) id KAA05841 for nmrg-outgoing; Wed, 24 Jan 2001 10:47:35 +0100 (MET) Received: from utrhcs.cs.utwente.nl (utrhcs.cs.utwente.nl [130.89.10.247]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) with ESMTP id KAA05836 for ; Wed, 24 Jan 2001 10:47:34 +0100 (MET) Received: from zeus.cs.utwente.nl (zeus.cs.utwente.nl [130.89.10.12]) by utrhcs.cs.utwente.nl (8.9.3/8.9.3) with ESMTP id KAA01491 for ; Wed, 24 Jan 2001 10:47:31 +0100 (MET) Received: from cs.utwente.nl by zeus.cs.utwente.nl (8.8.8+Sun/csrelay-Sol1.4/RB) id KAA16816; Wed, 24 Jan 2001 10:47:32 +0100 (MET) Message-ID: <3A6EA4B9.946A5D6@cs.utwente.nl> Date: Wed, 24 Jan 2001 10:47:37 +0100 From: Szabolcs Boros Organization: UTwente X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: hu,en,ro,nl MIME-Version: 1.0 To: Network Management Research Group Subject: [nmrg] Minutes of 8th NMRG meeting Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-nmrg@ibr.cs.tu-bs.de Precedence: bulk Below are the minutes from the 8th NMRG meeting in Austin, TX. szabi boros IRTF - NMRG meeting Austin, Texas J.J. Pickle Research Campus December 8-9, 2000 List of Participants (in alphabetical order) 1. Sz. Boros (SB) - Univ. of Twente (minute taker) - boros@cs.utwente.nl 2. M. Brunner (MB) - NEC Europe Ltd. - brunner@ccrle.nec.de 3. D. Durham (DD) - Intel Corp. - david.durham@intel.com 4. D. Harrington (DH) - Enterasys - dbh@enterasys.com 5. J.P. Martin-Flatin (JP) - AT&T Research Lab - jp.martin-flatin@ieee.org *. G. Pavlou - University of Surrey - g.pavlou@ee.surrey.ac.uk (2000-12-09) 6. R. Parhonyi (RP) - Univ. of Twente (minute taker) - parhonyi@cs.utwente.nl 7. D. Perkins (DP) - SNMPinfo - dperkins@snmpinfo.com 8. A. Pras (AP) - Univ. of Twente (chair) - pras@ctit.utwente.nl 9. J. Schoenwaelder (JP) - TU Braunschweig - schoenw@ibr.cs.tu-bs.de 10. D. Sidor (DS) - Nortel Networks - djsidor@nortelnetworks.com 11. A. Westerinen (AW)- Cisco Systems - andeaw@cisco.com 12. B. Wijnen (BW) - Lucent - bwijnen@lucent.com **************************************** 08-12-2000 **************************************** The purpose of the meeting was defined as learning from each other, discuss high level things and do not go into details. The title of the meeting can be formulated as follows: Network Information Modeling Workshop. There is a need to define a set of terms: - information model (IM) - data model (DM) - interface - conceptual model - object oriented (OO) model and also to answer some questions/issues: - IM vs. protocol. Should the IM be protocol independent/neutral? - IM vs. API - What is the scope of IM? - How many models do we need? One or more? - What are the benefits of IM? Users of IM? Standards. - Should we use OO techniques to describe an IM/DM? Proposal for the IM definition: (a) conceptual model: list of keywords (defines entities) (b) structuring all the information keywords (c) naming scheme for all the entities (d) meta model defined in the entities An IM should contain: - abstracts (conceptual model - modeling the world in abstract objects) - structure: - data model - object model - inverted tree - ... - naming - meta model (also some COPS documents deal with IM) The DM is related more to object repository. There are other approaches for an IM: 1. IM / | \ / | \ / | \ --> Conceptual -------------------------------------------- / | \ --> Computational - as opposed to conceptual (term was removed later from the board) DM DM DM ... (this can be implemented (MIB, LDAP schema), it's technology specific and standardizable) (This model is close to the ITU-T approach.) 2. ODP approach (open distributed processing) - Enterprise viewpoint - Information viewpoint - Computation viewpoint - Engineering viewpoint - Technology viewpoint Question: How can the two approaches be mapped? How can this be done? Structure and meta model belong together. IM - protocol independent DM - protocol specific +--------------------------------+ | | MAPPING: | v v +------------------+ +---------------+ data m. | abstracts | | |--> obj. m. <--| structure | | IM | inverted tree | naming (1) | | | | meta model | +---------------+ +------------------+ / | \ \ ^ \ / | \ \ | IM / | \ -----------------------------+ / | \ naming DM DM protocol (HTTP) encoding (XML) (1) not yet defined in IETF, but CIM has it. SMIv2 is a data model. SMIng tries to do the converging of data models. SMIng is more than a DM, and it has IM flavour. No functionality can be put into a DM that is not in the IM. 11:00 - 11:30 Coffie break OMG people try to implement everything valuable of TINA-C. TINA uses UML for information view, uses CORBA at computational view. The IM is conceptual, but it has to be encoded somehow. The encoding carries the protocol. The DM is more like an encoding. The IM is independent of CMIP, MIB. The IM is more static. The Computational model is running on this static IM. Discussion about the terms: conceptual and computational. Maybe "computational" is not the right term because it is not opposed to "conceptual". What should be instead of "computational"? Isn't "protocol specific" enough for the DM layer? There were pros and cons. Though this is not the ideal solution, this is what we have in IETF at this moment and our goal is to stay within the range of IETF, we don't define a model for the entire world. A common proposal for both IETF and DMTF can be pictured: IM / | \ +------> SMI / ASN.1 / | \ / / | \ / / | +--------------------------+ CIM PIB | | /MOF/ /SPPI/ | | Data Model / | | SNMP MIBs | / | | | ---------------------------|--------------------------|-- wire / | | | | | | | XML BER | | encoding for HTTP | | for LDAP +--------------------------+ (DMTF) (IETF) ASN.1 was designed to describe protocols (e.g. PDUs). CMIP includes actions not just values, MIBs have two operations. IM includes the operations. DTD and XML schema operate at the same level. XML schema is broad, is more suited to complex problems. DTD is a simplified form. Summarized picture: IM / | \ / | \ / | \ CIM PIB MIB data models schema /SPPI/ /SMI, XML/ / | \ / | \ ------------------------------------------------------- wire /|\ | /|\ / | \ | / | \ XML for BER BER encoding HTTP How important are the BER for Information Modeling? There is a difference between "expressing a concept" and "the way to transmit it over the wire". "Protocol" encompasses both bottom levels of the picture; i.e. protocol = actions + encoding. Mapping MIB into BER, or CIM into XML is not a 1:1 mapping. XML is more powerful and can be used to describe different levels (DM level and encoding level). Different Data Models can be expressed in different ways: we use schemas for CIM, SPPI for PIBs and SMI for MIBs. But XML can be also used to express a MIB on the DM level. Even more, XML can be used also for the IM level. In DMTF the data model is fully Object Oriented. In SNMP the object model has to be translated into a DM which is not an OO model. The question is whether DM does contain information or only the way how the information is encoded. The Data Model Language (SMI, XML, SPPI or MOF) is the way to express the information, the DM is only the content. 12:30-13:40 Lunch break A discussion went on upon the term: "interface". The term was heavily used in IETF, but with a different meaning than in ITU-T where interface is part of the functional architecture and it is the boundary between managed and management entities, while in SNMP world interface was mostly used in the IF-MIB tables. In the view of ITU interfaces are between and/or within the Network Element - Network - Service - Business layers. Interface is different between each of these levels (interfaces between layers or between elements in the same layer). Discussion over introducing OO in IM/DM or not. MIBs of OSI defined with GDMO look OO. At IM level could be anything, but typically there should be an OO approach at this layer. The DM layer doesn't have to be necessarily OO. However, if DM can be OO, then IM has to map to various DMs, therefore IM has to be OO. Otherwise how do you map something that is not OO to a DM that is OO, which is a superset. If one uses an OO language to have an IM and uses a non-OO language for DM -> that will not work necessarilly well. One looses information of a OO model while mapping it to a non-OO model. It won't work necessarily well if using an non-OO IM and an OO based DM. OOness is represented in UML; core concepts of UML are inheritance, classes, attributes and methods, associations and cardinality. UML is a graphical notation and has a state model. ITU-T decided that they want to use things that were considered important (eg. UML). There could be used the existing languages and not defining a new one. UML is not the perfect language. ITU-T has another language: SDL (Specification and Definition Language), it is combined in a project UML and SDL. What is an OO model? The key concepts of an OO model are: - abstraction & encapsulation - classes (attributes, methods, notifications, behaviour are included) & instances - inheritance - relationships - naming Benefits and drawbacks of these characteristics were discussed. Is it necessary that IM is OO? Yes, because then it is easier to map it to the OO Data Model. The formal representation of IM (whether it is UML or a structured English) is OO, including all features. There was a consensus upon the fact that people SHOULD use OO techniques for specifying the IM (specification tools must be able to do OO). Since the DM is to be choosen based on the protocol, it is not necessarily OO. Discussion over the definition of "control model". (CM) What is a CM? Where it comes from? ITU-T world. ITU has a data - control - management model. It's a term to see if there's distinction between action and data. Control means modifying the characteristics of specific data. CM should be put in the "methods", instead of having it between the other models (IM/DM). 15-15:30 Break Discussions over the characteristics of IM: - scope - reusability - ease of use - focus is on customer - how easy you can define? - how easy you can implement? Is there any experience what a good/bad scope is? Can we give examples for good scope? It is to be noticed that CIM has a very large scope (tries to model a large spectrum of things). Eventually it was agreed upon that scope can be any of the following: DiffServ, element, networks/services, generic high level base model, arbitrary systems, networks/services/business, etc. IM means reusability of terms, implementation doesn't count here. If focusing on standards, implementing is not necessarily relevant. Ease of implementation is indirectly useful. Question: Is "ease to define" the following explanation: if you can define high-level concepts can people on lower levels make implementations? If you have good tools then it's an easy way, but the model is also important. What about ease of use? Is it for customers, managers of operators? Customers demand that you have a consistent model for similar things on the network to be managed. Ease of use is for the customer. Is this important to have it embedded in such a high level model? It is not necessarily part of it but it can be added without changing the underlying protocol. Discussion over the benefits of OO. Reusability? Is it such a great attribute of OO? In theory yes, in practice it's a question. On a long term it seems to be not so great, because in the beginning there are a few classes and you can use whatever you want, but on a long term when there are classes everywhere it would take you too much time to find the base class that you need and add an attribute. You just have to construct your own new class. OO may bring lots of other benefits. For example, an OO model can be structured. Summarizing the benefits of OO approach we could say that in general OO is good, but we should not oversell it. - modularity - encapsulation: you can modify your implementation without affecting your interface. - inheritance: may not be the strongest benefit, it's a nice thing to have as long as you got very clear control over it. If the networking environment changes quickly then inheritance could be a problem. Inheritance adds dependencies and complexity. But it still can be a powerful tool. It is necesary to specify explicitly that it is dangerous. - abstraction - naming (in OO terms naming is scoped -> this is an advantage) - classes - instances - relationships: may be benefical - methods. Relationships/methods: Question: Would it be a good idea to have relationships like in OO technology? A relationship in a model documents that there is something between two entities. One can have relationships just to point out to attributes, or some other attributes of other entities. An IM could define classes and relationships, in implementation you have to define instances and pointers. In IM we don't have pointers but we have relationships, in a DM we have pointers. Mapping between these two can be difficult. Summarizing relationships: Juergen said that if you start doing it top down it's nice, but if you have a list of existing things then it can be difficult. You run into the risk that if you have methods in the IM then they would be heavily used, creating in your system a lot of code and interactions. That is something that we should be aware of. SNMP was designed not to do methods. SNMP was developed from CMIP and the action capability was deliberately removed because it added such a complexity. One reason why methods are not in SNMP is because by limiting the operation improves interoperability, which allows us to define standards decently. Adding methods will impact interoperability. Methods at IM level are different from methods at DM level. Interoperability issues arise only when adding methods at DM level. In the process of mapping IM to a specific DM (eg. SNMP) we get rid of the methods and map them to some (SNMP) specific mechanisms. But if we are going to define methods in the IM, SNMP will be extended to support methods. There are now some MIBs that really need methods and operations. And SMIng is extensible, this is one of its features. Methods have to be added to SNMP, because they bring some ease of use, or else, CORBA will take over. Scenario: Suppose you have methods in both models, the result would be lots of code and inefficient communication. Assume people would really like the methods in the IM then they start using them, so you have problems because of the inefficient code and communication. That would be a good reason to convince the people to go to the new version of SNMP. **************************************** 09-12-2000 **************************************** Discussion about the 3rd agenda item: is SMIng suited for an IM? The abstract of the SMIng document states that it is a data model. SMIng has classes, inheritance, attributes, but no methods. There are events that map to SNMP notifications. An event is part of a class, while in SMI it is a standalone thing. The current SMI was not written for IM. Is SMIng usable for information modeling? - SMIng is a data definition language to replace SMIv2 and SPPI; the underlaying protocols at this moment do not allow method invocation; - a replacement that merges two different languages; - it is not the goal of the language to be suited for IM, but it is benefical; - it is a protocol independent data definition language. Q: Does SMIng conform to the definition of IM that we had yesterday? A: No, because there is no abstract representation of relationships. Q: Would be difficult to map SMIng to IDL? A: Not more than the mapping of SMIv2 to IDL. When SMIng was designed one of the things we had in mind was to make mappings to other DM and protocols such as CORBA IDL not harder. Reusability is needed in data definitions. SMIng was designed OO to provide this. Another reason was structuring and ease of use. Reusability was the main reason to make SMIng OO. An IM language should be OO, and SMIng does not include methods. SMIng is a good candidate for DM, but does not qualify for IM. In IM, it is clear what is a method. We have clear parameters and we know their semantics. In DM the clarity can be taken and mapped in whatever is needed. However SMIng is moving to the right direction, and it can become good IM. The key elements for an IM should be: - OO - methods - relationships. Q: What does an IM require in order to model relationships? A: IM has a concept to describe relationships. You need more than pointers, you need a way to formally express relationships. You need something to describe and document the relationships. Relationships should not only be simulated, but they should be built into the language. Q: Suppose relationships are easy to map to DM. Do we really need methods? A: Methods would be something that you can always map to the DM, on the other hand Jurgen left it out from the SMIng because it would be inefficient with current IETF management protocols. DMTF uses UML to present graphically the entities. Use UML to represent something then discuss it, define the MOF. UML is the basics (class diagrams & relationships, no sequence diagrams). For modeling protocols we need sequence diagrams. Sequence diagrams are useful for identifying the methods. +---------------+ | | / "informal"/English _____ class diagram | IM |/ / | |\ / +---------------+ \ "formal"/UML ------------ sequence diagram /|\ \ / | \ \_____ use cases ... | \ | \ SMIv2| \SPPI | \ MIBs PIBs / \ / \ DM ---------------------------------------- / \ BER BER It is difficult to do UML without tools. OMG has copyright for UML. We need ASCII representation of the UML diagrams, IETF has requirement for ASCII. If the diagrams could be represented in ASCII many people would be happy. Also need public domain implementations. Q: Do we have to standardize the IM in the IETF? A: Yes, IM should be standardized. And it has to be done in ASCII file for IETF. 10:45-11:30 Coffie break Some UML-related ITU-T documents: M.3020 - TMN methodology focused on UML M.3208.3 - IM using UML M.3108.3 - DM using UML ITU-T 564/IETF ftp site ip address: 47.234.32.16 user id: anon path: /itu_to_ietf/56 DMTF documents: www.dmtf.org/spec/cims.html (click on Schema v2.4) www.dmtf.org/educ/whit.html (white papers, recommended The CORE Model). Pointers to IETF? Some relevant documents? WGs? SPPI draft, SMIng - RFCs. Policy Framework WG, SMIng WG, RAP WG (SPPI), IPSP WG. OMG with CORBA: OMG has Telecom Domain Task Force: TMN with CORBA activities. "CORBA notification service" was produced. OMG did not produce network models. - created corba models for trouble ticketing. - study group 4 has some proposals to use CORBA models. - docs are going for approval in january 2001. OMG document: Common Information Structure 3GPP group approved a set of specification for config+fault mgmt, they created DMs based on CORBA: 32.016, 32.111 docs. 3GPP uses aspects of class diagrams, but the large part is their own creation, using structured English. ATM Forum has a protocol neutral model. ATM Forum uses structured English. TINA-C has some docs from 1996. Network Resource IM - TINA. SUN has some work there (in 3 groups), has created an infrastructure with object manager. MS: Win Mgt Info: took the CIM schema and added OO design in a strange way. CISCO: have DMTF models + extensions: CIM models are used. There was a demo. www.snia.org Intel, IBM are working also implementing CIM. Enterasys is also working with CIM-LDAP stuff, but no success yet. Q: How much of the work is used in the world? What was implemented and being used (deployment)? A: Some ITU-T docs were just finished, no implementation yet. Telco's in Europe implement and extend proprietary GMDO-CMIP stuff in an inconsistent way. Conclusion: On IM level ITU-T has docs, but they are too new, no implementations. 12:35-13:20 Lunch break JS: =presentation of SMIng= example: module INET-FILTER { ... class Filter { attribute DisplayString255 name ... } } class InetFilter:Filter { attribute InetSubnet src; attribute InetSubnet dst; ... } class InetSubnet { attribute InetNetworkEndpoint endpoint; attribute InetMask mask; ... } - multiple inheritance is not allowed (it is way to complicated for the benefits it brings) - attributes can be overwritten (there are some restrictions) The XML schema is very similar to SMIng. General discussion about SMIv2 and SMIng. Similarities and differences, notifications, events, mappings to CMIP, DIAMETER, SNMP. snmp { table ifTable { oid interfaces 2; index (); implements Interface { object ifIndex index; ... } } } There was a research proposal: mapping to CORBA. 14:50-15:20 Break Finalization of the meeting: - questions answered, - issues discussed. Q: What to do with the output of this meeting? Are there other issues to be addressed? A: Write an article for the SimpleTimes. It could be a good idea to use this output as an input for the NIM group. IM requirements document, discuss it on the mailing list. 15:50 Closing of the meeting. Return-Path: Received: by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) id MAA25449 for nmrg-outgoing; Mon, 15 Jan 2001 12:56:29 +0100 (MET) Received: from henkell.ibr.cs.tu-bs.de (schoenw@henkell [134.169.34.191]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) with ESMTP id MAA25444; Mon, 15 Jan 2001 12:56:24 +0100 (MET) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id MAA15628; Mon, 15 Jan 2001 12:56:24 +0100 Date: Mon, 15 Jan 2001 12:56:24 +0100 Message-Id: <200101151156.MAA15628@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: andreaw@cisco.com CC: jp.martin-flatin@ieee.org, nmrg@ibr.cs.tu-bs.de In-reply-to: Subject: Re: [nmrg] Proposed topics for the 9th NMRG meeting References: Sender: owner-nmrg@ibr.cs.tu-bs.de Precedence: bulk >>>>> Andrea Westerinen writes: Andrea> Juergen, I am already working on a BOF request for SMIng at Andrea> IM2001. I will get this submitted by Monday (the deadline). Thanks for the info. So I stop my efforts of submitting a similar proposal. ;-) Andrea> Regarding policy-based networking, I worked on a prototype Andrea> system a few years back at Intel, that used events as triggers Andrea> to evaluate rules. [...] Andrea> I too am personally interested in this and would love to Andrea> discuss it. Thanks for your feedback. /js -- Juergen Schoenwaelder Technical University Braunschweig Dept. Operating Systems & Computer Networks Phone: +49 531 391 3289 Bueltenweg 74/75, 38106 Braunschweig, Germany Fax: +49 531 391 5936 Return-Path: Received: by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) id IAA04100 for nmrg-outgoing; Sun, 14 Jan 2001 08:13:13 +0100 (MET) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) with ESMTP id IAA04095; Sun, 14 Jan 2001 08:13:10 +0100 (MET) Received: from mira-sjcm-1.cisco.com (mira-sjcm-1.cisco.com [171.69.2.212]) by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id XAA12447; Sat, 13 Jan 2001 23:12:39 -0800 (PST) Received: from jstrassnlap ([171.69.108.130]) by mira-sjcm-1.cisco.com (Mirapoint) with SMTP id AJM03442; Sat, 13 Jan 2001 23:12:34 -0800 (PST) Message-ID: <001101c07df9$ea35b190$826c45ab@cisco.com> Reply-To: "John Strassner" From: "John Strassner" To: "Juergen Schoenwaelder" , Cc: References: <200101121147.MAA06137@henkell.ibr.cs.tu-bs.de> Subject: Re: [nmrg] FW: Meeting at the Bellevue office? Date: Sat, 13 Jan 2001 05:35:39 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-nmrg@ibr.cs.tu-bs.de Precedence: bulk Sat-Sun would be easier for me regards, John ----- Original Message ----- From: "Juergen Schoenwaelder" To: Cc: Sent: Friday, January 12, 2001 3:47 AM Subject: Re: [nmrg] FW: Meeting at the Bellevue office? > > >>>>> Andrea Westerinen writes: > > Andrea> We could meet at the Cisco sales office in Bellevue. The main > Andrea> conference room holds 20. > > This sounds great to me. IM 2001 is 14-18 May 2001 (Mo - Fr). I would > personally prefer to hold the meeting at the end of the week before IM > or even over the weekend (since I will have to stay the weekend in > Seattle anyway in order to get an affordable flight). > > So what about meeting on May 11-12 (Fr - Sa)? Would everybody be happy > with this? > > /js > > -- > Juergen Schoenwaelder Technical University Braunschweig > Dept. Operating Systems & Computer Networks > Phone: +49 531 391 3289 Bueltenweg 74/75, 38106 Braunschweig, Germany > Fax: +49 531 391 5936 > > Return-Path: Received: by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) id GAA06387 for nmrg-outgoing; Sat, 13 Jan 2001 06:08:24 +0100 (MET) Received: from cisco.com (sigma.cisco.com [171.69.63.142]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) with ESMTP id GAA06382; Sat, 13 Jan 2001 06:08:20 +0100 (MET) Received: from andreawlap (andreaw-frame1.cisco.com [10.19.253.186]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with SMTP id VAA06269; Fri, 12 Jan 2001 21:07:48 -0800 (PST) From: "Andrea Westerinen" To: "Juergen Schoenwaelder" , Cc: Subject: RE: [nmrg] Proposed topics for the 9th NMRG meeting Date: Fri, 12 Jan 2001 21:09:08 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 In-reply-to: <200101121154.MAA06167@henkell.ibr.cs.tu-bs.de> Sender: owner-nmrg@ibr.cs.tu-bs.de Precedence: bulk Juergen, I am already working on a BOF request for SMIng at IM2001. I will get this submitted by Monday (the deadline). Regarding policy-based networking, I worked on a prototype system a few years back at Intel, that used events as triggers to evaluate rules. The events were specified as simple expressions where the variables were the properties of CIM objects and/or were infrastructure events (ie, instance creation/deletion). In this way, we were able to generally specify the rules, deploy this to systems, and still tie back to specific low-level objects in the management system. Initial tests were pretty successful. The really hard thing was figuring out the right actions - either they were simple actions/scripts, or you entered an AI engine and did forward/backward chaining of rules (really hard to get right). I too am personally interested in this and would love to discuss it. Andrea -----Original Message----- From: owner-nmrg@ibr.cs.tu-bs.de [mailto:owner-nmrg@ibr.cs.tu-bs.de]On Behalf Of Juergen Schoenwaelder Sent: Friday, January 12, 2001 3:55 AM To: jp.martin-flatin@ieee.org Cc: nmrg@ibr.cs.tu-bs.de Subject: Re: [nmrg] Proposed topics for the 9th NMRG meeting >>>>> J P Martin-Flatin writes: JP> I suggest we assess where we stand w.r.t. information modeling. I JP> have already begun working on this. Perhaps others would like to JP> contribute, too. Fine with me. I think we should first get the article on the table which folks wanted to write about the last meeting. Based on the article (which I think should be completed way before the May meeting), we can see where we want to go next. JP> I guess an update by Juergen on SMIng and SNMP over TCP would also JP> be a good idea. I hope that SNMP over TCP is done by May and in the RFC editor queue. Similarily, SMIng is not an NMRG issue anymore. You should really follow (and perhaps contribute to) the SMIng IETF working group. On the other hand, I can imagine that there are many people who usually do not go to IETF meetings and who do not follow WG mailing lists that may want to chat about the SMIng project. Perhaps it makes sense to schedule an SMIng BOF at IM 2001 itself? JP> I would be interested in discussing policy-based networking, JP> especially how to link high-level policy MIBs/schemata with JP> low-level network and systems management MIBs/schemata. Is this JP> interest shared by other members of this group? This is IMHO a tough question and something I am personally interested in. I guess you can make $$$ if you have an answer to this problem. ;-) /js -- Juergen Schoenwaelder Technical University Braunschweig Dept. Operating Systems & Computer Networks Phone: +49 531 391 3289 Bueltenweg 74/75, 38106 Braunschweig, Germany Fax: +49 531 391 5936 Return-Path: Received: by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) id MAA22353 for nmrg-outgoing; Fri, 12 Jan 2001 12:54:58 +0100 (MET) Received: from henkell.ibr.cs.tu-bs.de (schoenw@henkell [134.169.34.191]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) with ESMTP id MAA22345; Fri, 12 Jan 2001 12:54:54 +0100 (MET) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id MAA06167; Fri, 12 Jan 2001 12:54:53 +0100 Date: Fri, 12 Jan 2001 12:54:53 +0100 Message-Id: <200101121154.MAA06167@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: jp.martin-flatin@ieee.org CC: nmrg@ibr.cs.tu-bs.de In-reply-to: <3A5DD2F0.3000508@ieee.org> (jp.martin-flatin@ieee.org) Subject: Re: [nmrg] Proposed topics for the 9th NMRG meeting References: <3A5DD2F0.3000508@ieee.org> Sender: owner-nmrg@ibr.cs.tu-bs.de Precedence: bulk >>>>> J P Martin-Flatin writes: JP> I suggest we assess where we stand w.r.t. information modeling. I JP> have already begun working on this. Perhaps others would like to JP> contribute, too. Fine with me. I think we should first get the article on the table which folks wanted to write about the last meeting. Based on the article (which I think should be completed way before the May meeting), we can see where we want to go next. JP> I guess an update by Juergen on SMIng and SNMP over TCP would also JP> be a good idea. I hope that SNMP over TCP is done by May and in the RFC editor queue. Similarily, SMIng is not an NMRG issue anymore. You should really follow (and perhaps contribute to) the SMIng IETF working group. On the other hand, I can imagine that there are many people who usually do not go to IETF meetings and who do not follow WG mailing lists that may want to chat about the SMIng project. Perhaps it makes sense to schedule an SMIng BOF at IM 2001 itself? JP> I would be interested in discussing policy-based networking, JP> especially how to link high-level policy MIBs/schemata with JP> low-level network and systems management MIBs/schemata. Is this JP> interest shared by other members of this group? This is IMHO a tough question and something I am personally interested in. I guess you can make $$$ if you have an answer to this problem. ;-) /js -- Juergen Schoenwaelder Technical University Braunschweig Dept. Operating Systems & Computer Networks Phone: +49 531 391 3289 Bueltenweg 74/75, 38106 Braunschweig, Germany Fax: +49 531 391 5936 Return-Path: Received: by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) id MAA21997 for nmrg-outgoing; Fri, 12 Jan 2001 12:47:28 +0100 (MET) Received: from henkell.ibr.cs.tu-bs.de (schoenw@henkell [134.169.34.191]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) with ESMTP id MAA21991; Fri, 12 Jan 2001 12:47:25 +0100 (MET) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id MAA06137; Fri, 12 Jan 2001 12:47:25 +0100 Date: Fri, 12 Jan 2001 12:47:25 +0100 Message-Id: <200101121147.MAA06137@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: andreaw@cisco.com CC: nmrg@ibr.cs.tu-bs.de In-reply-to: Subject: Re: [nmrg] FW: Meeting at the Bellevue office? References: Sender: owner-nmrg@ibr.cs.tu-bs.de Precedence: bulk >>>>> Andrea Westerinen writes: Andrea> We could meet at the Cisco sales office in Bellevue. The main Andrea> conference room holds 20. This sounds great to me. IM 2001 is 14-18 May 2001 (Mo - Fr). I would personally prefer to hold the meeting at the end of the week before IM or even over the weekend (since I will have to stay the weekend in Seattle anyway in order to get an affordable flight). So what about meeting on May 11-12 (Fr - Sa)? Would everybody be happy with this? /js -- Juergen Schoenwaelder Technical University Braunschweig Dept. Operating Systems & Computer Networks Phone: +49 531 391 3289 Bueltenweg 74/75, 38106 Braunschweig, Germany Fax: +49 531 391 5936 Return-Path: Received: by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) id QAA20165 for nmrg-outgoing; Thu, 11 Jan 2001 16:35:45 +0100 (MET) Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.30.102]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) with ESMTP id QAA20161 for ; Thu, 11 Jan 2001 16:35:43 +0100 (MET) Received: from bigmail.research.att.com (bigmail.research.att.com [135.207.30.101]) by mail-blue.research.att.com (Postfix) with ESMTP id 84E384CE35 for ; Thu, 11 Jan 2001 10:35:38 -0500 (EST) Received: from ieee.org (jpmf@pc-jpmf.research.att.com [135.207.26.73]) by bigmail.research.att.com (8.8.8/8.8.8) with ESMTP id KAA22972 for ; Thu, 11 Jan 2001 10:35:38 -0500 (EST) Message-ID: <3A5DD2F0.3000508@ieee.org> Date: Thu, 11 Jan 2001 10:36:16 -0500 From: "J.P. Martin-Flatin" Reply-To: "J.P. Martin-Flatin" Organization: AT&T Labs Research User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.14-5.0 i686; en-US; m18) Gecko/20001107 Netscape6/6.0 X-Accept-Language: en, fr-FR MIME-Version: 1.0 To: NMRG Subject: [nmrg] Proposed topics for the 9th NMRG meeting Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-nmrg@ibr.cs.tu-bs.de Precedence: bulk Hi, I suggest we assess where we stand w.r.t. information modeling. I have already begun working on this. Perhaps others would like to contribute, too. I guess an update by Juergen on SMIng and SNMP over TCP would also be a good idea. I would be interested in discussing policy-based networking, especially how to link high-level policy MIBs/schemata with low-level network and systems management MIBs/schemata. Is this interest shared by other members of this group? JP Juergen Schoenwaelder wrote: > > We also agreed in Austin to organize a meeting next to the IM 2001 > conference in May 2001. If some of you have concrete proposals where > and when to meet or topics we should address, please let me know so > that we can plan ahead. Return-Path: Received: by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) id PAA06999 for nmrg-outgoing; Tue, 9 Jan 2001 15:20:21 +0100 (MET) Received: from henkell.ibr.cs.tu-bs.de (schoenw@henkell [134.169.34.191]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) with ESMTP id PAA06994; Tue, 9 Jan 2001 15:20:18 +0100 (MET) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id PAA20634; Tue, 9 Jan 2001 15:20:18 +0100 Date: Tue, 9 Jan 2001 15:20:18 +0100 Message-Id: <200101091420.PAA20634@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: Network Management Research Group Subject: [nmrg] New Visions for Large-Scale Networks: Research and Applications Sender: owner-nmrg@ibr.cs.tu-bs.de Precedence: bulk Those of you interested in long-term visions and research directions may want to take a look at: The IRSG chair would actually like to see contributions from the IRTF on that meeting. So if someone has a vision to write up... /js -- Juergen Schoenwaelder Technical University Braunschweig Dept. Operating Systems & Computer Networks Phone: +49 531 391 3289 Bueltenweg 74/75, 38106 Braunschweig, Germany Fax: +49 531 391 5936 Return-Path: Received: by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) id EAA29822 for nmrg-outgoing; Wed, 3 Jan 2001 04:22:25 +0100 (MET) Received: from cisco.com (sigma.cisco.com [171.69.63.142]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) with ESMTP id EAA29815 for ; Wed, 3 Jan 2001 04:22:23 +0100 (MET) Received: from andreawlap (rtp-dial-1-18.cisco.com [10.83.97.18]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with SMTP id TAA13744 for ; Tue, 2 Jan 2001 19:21:50 -0800 (PST) From: "Andrea Westerinen" To: "Network Management Research Group" Subject: [nmrg] FW: Meeting at the Bellevue office? Date: Tue, 2 Jan 2001 19:23:10 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-nmrg@ibr.cs.tu-bs.de Precedence: bulk Status: O Content-Length: 1175 Lines: 36 We could meet at the Cisco sales office in Bellevue. The main conference room holds 20. Andrea -----Original Message----- From: owner-nmrg@ibr.cs.tu-bs.de [mailto:owner-nmrg@ibr.cs.tu-bs.de]On Behalf Of Juergen Schoenwaelder Sent: Wednesday, December 20, 2000 3:59 AM To: Network Management Research Group Subject: [nmrg] welcome new list members I just added George Pavlou, Dave Sidor, Marcus Brunner and John Strassner to the NMRG mailing list. One of the next things we have to do is to get the minutes from the last meeting finalzed and to start work on a paper which makes the results produced by the last meeting accessible to a larger audience. We also agreed in Austin to organize a meeting next to the IM 2001 conference in May 2001. If some of you have concrete proposals where and when to meet or topics we should address, please let me know so that we can plan ahead. /js -- Juergen Schoenwaelder Technical University Braunschweig Dept. Operating Systems & Computer Networks Phone: +49 531 391 3289 Bueltenweg 74/75, 38106 Braunschweig, Germany Fax: +49 531 391 5936 Return-Path: Received: by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) id EAA29673 for nmrg-outgoing; Wed, 3 Jan 2001 04:16:31 +0100 (MET) Received: from femail6.sdc1.sfba.home.com (femail6.sdc1.sfba.home.com [24.0.95.86]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) with ESMTP id EAA29668 for ; Wed, 3 Jan 2001 04:16:30 +0100 (MET) Received: from dperkins-nb2.dsperkins.com ([24.15.219.251]) by femail6.sdc1.sfba.home.com (InterMail vM.4.01.03.00 201-229-121) with ESMTP id <20010103031628.UWAH15927.femail6.sdc1.sfba.home.com@dperkins-nb2.dsperkins.com> for ; Tue, 2 Jan 2001 19:16:28 -0800 Message-Id: <5.0.2.1.2.20010102190651.02555ec0@mail.scruznet.com> X-Sender: dperkins@mail.scruznet.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Tue, 02 Jan 2001 19:16:22 -0800 To: nmrg@ibr.cs.tu-bs.de From: "David T. Perkins" Subject: [nmrg] Alarms, Events, and Notifications Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-nmrg@ibr.cs.tu-bs.de Precedence: bulk Status: O Content-Length: 648 Lines: 19 HI, The DISMAN WG is trying to add a new work item to their charter to create a MIB module for alarm reporting based on X.733. I believe that this is an important addition, but one that is difficult due in a large part to terminology (and one that should not try to map X.733 to SNMP). Are there any good papers or books on management via exception reporting? Are there any reviews or critiques of X.733? Does anyone know of any EXACT implementation of X.733? (I've seen several MIB modules based on concepts from X.733, and I've even defined one myself. However, none I've seen were a direct translation of X.733.) Regards, /david t. perkins