Received: from postman.bayarea.net (postman.BAYAREA.NET [205.219.84.13]) by agitator.ibr.cs.tu-bs.de (8.12.1/8.12.1/Debian -2) with ESMTP id g6VGAUi7025437 for ; Wed, 31 Jul 2002 18:10:30 +0200 Received: from host.dsperkins.com (shell4.BAYAREA.NET [209.128.82.1]) by postman.bayarea.net (8.9.3/8.9.3) with ESMTP id JAA15676 for ; Wed, 31 Jul 2002 09:10:27 -0700 (PDT) (envelope-from dperkins@dsperkins.com) Message-Id: <5.1.0.14.2.20020731083647.02dac3c0@127.0.0.1> X-Sender: dperkins@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 31 Jul 2002 09:09:05 -0700 To: "nmrg@ibr.cs.tu-bs.de" From: "David T. Perkins" Subject: Re: [nmrg] Next meeting on web services In-Reply-To: <3D47E6E4.1000407@ctit.utwente.nl> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: nmrg-admin@ibr.cs.tu-bs.de Errors-To: nmrg-admin@ibr.cs.tu-bs.de X-BeenThere: nmrg@ibr.cs.tu-bs.de X-Mailman-Version: 2.0.6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: HI, On the managed system side, the meeting will really benefit from having Rob Enns and Phil Shafer from Juniper at the meeting. They are the engineers who developed and added the support for XML in Juniper's products. Juniper has been shipping a product with XML support for more than a year. The IETF XMLBOF was really a "bust" to me. The background documents comparing XML vs SNMP were like the ones I've seen in the past comparing CMIP vs SNMP. The authors did apple vs orange comparisons, and/or sort of knew one technology, but not the other and thus were filled with errors and omissions. That is, the authors just didn't understand the key issues. (However, the are many examples of book and article authors that just didn't get it either.) The presentations went like "Management app writers have problems cause by differences in managing different devices. .... And XML is the solution." Technical reasons why they came to this conclusion were not provided. In private conversations with a couple of attendees from SBC and WorldCom provided the following motivation: 1) you want a new management app written for a device and/or technology so you give app writers the appropriate MIB modules. 2) you get major push-back in both time and cost. That is, the app writers say that they cannot understand MIB modules and need time to take courses and the study them. The app writers are not motivated to learn some "obscure" format that will not lead to "real" career advancement. 3) The claim is that they "now" are already writing distributed programs that use an XML-based communications infrastructure (hey do I get bonus points for using this fancy terms) such as that from BEA or IBM. And that they can read XML (and XML schema), and if not, are motivated to learn this technology, since it is new and hot and career enhancing. So, use of XML is a "human factors" issue and not a technology issue. All of the above might be true and important, but on returning from IETF I had the opportunity to read over a request for proposal from a telcom. It was fantasy in many dimensions. In many ways it goes back to something I learned over 10 years ago, which is that app writers (and users) don't want to understand technology. The app writer just wants someone else to tell them want to do. And I understand this, because it is hard to describe the functionality of a management app. Getting back to the message below, I suggest that in addition to Rob and Phil, that users of BEA's and IBM's XML technology be invited. (Especially if they are using them for management applications.) On the logistics, please make it easy. The longer the time before the meeting, the better. Detailed hotel and train connection info would help. At 03:32 PM 7/31/2002 +0200, you wrote: >Hi all > >At the last NMRG meeting in Pisa we agreed to organize a special meeting on >"web services for management" (see >http://www.ibr.cs.tu-bs.de/projects/nmrg/minutes/minutes-010.txt). Although >the exact date is still not decided, I think it is time to confirm that the >meeting will actually be held in the second half of september in Osnabrueck >(Germany). Juergen will be our host, and inform us about all important >details (exact dates and time, location, how to get there, hotels etc.). Note >that Osnabrueck has a small airport, but is also easy to reach by train >or car from major airports like Frankfurt and Amsterdam. The meeting will >take 2 or 2.5 days. > >To get the meeting more productive we will invite some experts on web >services from outside the NMRG. If you have any suggestions for specific people, please let me know. > >Some of the questions that will be discussed at the meeting are: >- What are the fundamental reasons to use web-services technology. > How does this technology relate to other XML based technologies > (like XML-RPC) >- Should we consider SOAP / WSDL as just another mechanism to > transport management data, or will it have some impact on our > current manager-agent architecture? Particular questions are how > to deal with notifications and how to relate distributed > management (DISMAN). >- Will web services technology replace SNMP technology, or will > they live in parallel? Sub-questions: will web service technology > be equally suited for element, network and service management? > Will it be useful for monitoring as well as configuration? >- How to deal with security, in particular authentication and > authorization, in web services. Is there stable technology for > this, or will it remain a battlefield for many years > (see MS-Passport versus Liberty Alliance) >- Will UDDI, which is often presented as one of the core technologies > of web services, also play a role in case of management? >- What are the implementation consequences of web services. What > is the processing / network load (compared to SNMP). How easy is > it to develop web services for management. How easy is it to build > management applications that use these services? What tools are > available to implement web services and applications? > Would it be possible to use the same tools to develop CLI > and web services? >Note that this is not the final meeting agenda; feel free to add or modify questions. > >For the meeting it is important that everyone has some knowledge on web services. Relevant literature includes: >- W3C pages on web services (http://www.w3.org/2002/ws/). > In particular the SOAP and WSDL standards. >- xmlconf mailing list (xmlconf@ops.ietf.org) > Archive URL: http://ops.ietf.org/lists/xmlconf/ > To subscribe, send mail to majordomo@ops.ietf.org with > "subscribe xmlconf" in the body of the message. >- Web services tutorials: > http://java.sun.com/webservices/docs/ea1/tutorial/index.html > http://www-106.ibm.com/developerworks/webservices/?loc=dwmain >http://msdn.microsoft.com/library/?url=/library/en-us/dnwebsrv/html/webservbasics.asp?frame=true > http://www.gotdotnet.com/team/XMLwebservices/default.aspx > http://xml.apache.org/soap/ >- Critical analysis of web services: > http://www.nwfusion.com/columnists/2002/0520kaplan.html > http://www.prescod.net/rest/security.html >- XML-RPC vs. SOAP: > http://www.xml-rpc.com/ > http://weblog.masukomi.org/writings/xml-rpc_vs_soap.htm > >Please let us know if you will / will not attend. > >Bye > >Aiko Regards, /david t. perkins Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by agitator.ibr.cs.tu-bs.de (8.12.1/8.12.1/Debian -2) with ESMTP id g6VEgHi7021384; Wed, 31 Jul 2002 16:42:17 +0200 Received: from localhost ([127.0.0.1] helo=rip.psg.com.psg.com) by rip.psg.com with esmtp (Exim 4.10) id 17Zug4-000Hw4-00; Wed, 31 Jul 2002 07:42:16 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Aiko Pras Cc: "nmrg@ibr.cs.tu-bs.de" , Juergen Schoenwaelder Subject: Re: [nmrg] Next meeting on web services References: <3D47E6E4.1000407@ctit.utwente.nl> <3D47F661.9010803@ctit.utwente.nl> Message-Id: Date: Wed, 31 Jul 2002 07:42:16 -0700 X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: nmrg-admin@ibr.cs.tu-bs.de Errors-To: nmrg-admin@ibr.cs.tu-bs.de X-BeenThere: nmrg@ibr.cs.tu-bs.de X-Mailman-Version: 2.0.6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: > You mean the RIPE 9-13 September 2002 meeting at Rhodes? (nice place, > btw). In that case you propose to have the NMRG meeting 16 till 18 of > september? please, or even the weekend. but not the weekbefore ripe, as that is apnic in kyushu. randy Received: from netlx009.civ.utwente.nl (netlx009.civ.utwente.nl [130.89.1.91]) by agitator.ibr.cs.tu-bs.de (8.12.1/8.12.1/Debian -2) with ESMTP id g6VEcVi7021110; Wed, 31 Jul 2002 16:38:31 +0200 Received: from ctit.utwente.nl (utip250.cs.utwente.nl [130.89.12.39]) by netlx009.civ.utwente.nl (8.11.4/HKD) with ESMTP id g6VEcPG22126; Wed, 31 Jul 2002 16:38:25 +0200 Message-ID: <3D47F661.9010803@ctit.utwente.nl> Date: Wed, 31 Jul 2002 16:38:25 +0200 From: Aiko Pras User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: en-us MIME-Version: 1.0 To: Randy Bush CC: "nmrg@ibr.cs.tu-bs.de" , Juergen Schoenwaelder Subject: Re: [nmrg] Next meeting on web services References: <3D47E6E4.1000407@ctit.utwente.nl> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: nmrg-admin@ibr.cs.tu-bs.de Errors-To: nmrg-admin@ibr.cs.tu-bs.de X-BeenThere: nmrg@ibr.cs.tu-bs.de X-Mailman-Version: 2.0.6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: You mean the RIPE 9-13 September 2002 meeting at Rhodes? (nice place, btw). In that case you propose to have the NMRG meeting 16 till 18 of september? Aiko Randy Bush wrote: > it would be *much* appreciated if this was synchronized to be > immediately after ripe so the ops community from overseas > does not have to fly back and forth across the pond twice in > the same month. > > randy > > Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by agitator.ibr.cs.tu-bs.de (8.12.1/8.12.1/Debian -2) with ESMTP id g6VDtZi7019465; Wed, 31 Jul 2002 15:55:36 +0200 Received: from localhost ([127.0.0.1] helo=rip.psg.com.psg.com) by rip.psg.com with esmtp (Exim 4.10) id 17Ztwr-000Gcd-00; Wed, 31 Jul 2002 06:55:33 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Aiko Pras Cc: "nmrg@ibr.cs.tu-bs.de" , Juergen Schoenwaelder Subject: Re: [nmrg] Next meeting on web services References: <3D47E6E4.1000407@ctit.utwente.nl> Message-Id: Date: Wed, 31 Jul 2002 06:55:33 -0700 X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: nmrg-admin@ibr.cs.tu-bs.de Errors-To: nmrg-admin@ibr.cs.tu-bs.de X-BeenThere: nmrg@ibr.cs.tu-bs.de X-Mailman-Version: 2.0.6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: it would be *much* appreciated if this was synchronized to be immediately after ripe so the ops community from overseas does not have to fly back and forth across the pond twice in the same month. randy Received: from netlx009.civ.utwente.nl (netlx009.civ.utwente.nl [130.89.1.91]) by agitator.ibr.cs.tu-bs.de (8.12.1/8.12.1/Debian -2) with ESMTP id g6VDWWi7018552; Wed, 31 Jul 2002 15:32:32 +0200 Received: from ctit.utwente.nl (utip250.cs.utwente.nl [130.89.12.39]) by netlx009.civ.utwente.nl (8.11.4/HKD) with ESMTP id g6VDWKq13593; Wed, 31 Jul 2002 15:32:20 +0200 Message-ID: <3D47E6E4.1000407@ctit.utwente.nl> Date: Wed, 31 Jul 2002 15:32:20 +0200 From: Aiko Pras User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: en-us MIME-Version: 1.0 To: "nmrg@ibr.cs.tu-bs.de" CC: Aiko Pras , Juergen Schoenwaelder Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Subject: [nmrg] Next meeting on web services Sender: nmrg-admin@ibr.cs.tu-bs.de Errors-To: nmrg-admin@ibr.cs.tu-bs.de X-BeenThere: nmrg@ibr.cs.tu-bs.de X-Mailman-Version: 2.0.6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: Hi all At the last NMRG meeting in Pisa we agreed to organize a special meeting on "web services for management" (see http://www.ibr.cs.tu-bs.de/projects/nmrg/minutes/minutes-010.txt). Although the exact date is still not decided, I think it is time to confirm that the meeting will actually be held in the second half of september in Osnabrueck (Germany). Juergen will be our host, and inform us about all important details (exact dates and time, location, how to get there, hotels etc.). Note that Osnabrueck has a small airport, but is also easy to reach by train or car from major airports like Frankfurt and Amsterdam. The meeting will take 2 or 2.5 days. To get the meeting more productive we will invite some experts on web services from outside the NMRG. If you have any suggestions for specific people, please let me know. Some of the questions that will be discussed at the meeting are: - What are the fundamental reasons to use web-services technology. How does this technology relate to other XML based technologies (like XML-RPC) - Should we consider SOAP / WSDL as just another mechanism to transport management data, or will it have some impact on our current manager-agent architecture? Particular questions are how to deal with notifications and how to relate distributed management (DISMAN). - Will web services technology replace SNMP technology, or will they live in parallel? Sub-questions: will web service technology be equally suited for element, network and service management? Will it be useful for monitoring as well as configuration? - How to deal with security, in particular authentication and authorization, in web services. Is there stable technology for this, or will it remain a battlefield for many years (see MS-Passport versus Liberty Alliance) - Will UDDI, which is often presented as one of the core technologies of web services, also play a role in case of management? - What are the implementation consequences of web services. What is the processing / network load (compared to SNMP). How easy is it to develop web services for management. How easy is it to build management applications that use these services? What tools are available to implement web services and applications? Would it be possible to use the same tools to develop CLI and web services? Note that this is not the final meeting agenda; feel free to add or modify questions. For the meeting it is important that everyone has some knowledge on web services. Relevant literature includes: - W3C pages on web services (http://www.w3.org/2002/ws/). In particular the SOAP and WSDL standards. - xmlconf mailing list (xmlconf@ops.ietf.org) Archive URL: http://ops.ietf.org/lists/xmlconf/ To subscribe, send mail to majordomo@ops.ietf.org with "subscribe xmlconf" in the body of the message. - Web services tutorials: http://java.sun.com/webservices/docs/ea1/tutorial/index.html http://www-106.ibm.com/developerworks/webservices/?loc=dwmain http://msdn.microsoft.com/library/?url=/library/en-us/dnwebsrv/html/webservbasics.asp?frame=true http://www.gotdotnet.com/team/XMLwebservices/default.aspx http://xml.apache.org/soap/ - Critical analysis of web services: http://www.nwfusion.com/columnists/2002/0520kaplan.html http://www.prescod.net/rest/security.html - XML-RPC vs. SOAP: http://www.xml-rpc.com/ http://weblog.masukomi.org/writings/xml-rpc_vs_soap.htm Please let us know if you will / will not attend. Bye Aiko Received: from haerke.ibr.cs.tu-bs.de (IDENT:root@haerke.ibr.cs.tu-bs.de [134.169.34.84]) by agitator.ibr.cs.tu-bs.de (8.12.1/8.12.1/Debian -2) with ESMTP id g6QFOEDA022392; Fri, 26 Jul 2002 17:24:14 +0200 Received: (from schoenw@localhost) by haerke.ibr.cs.tu-bs.de (8.11.6/8.11.6) id g6QFOEW30612; Fri, 26 Jul 2002 17:24:14 +0200 Date: Fri, 26 Jul 2002 17:24:14 +0200 Message-Id: <200207261524.g6QFOEW30612@haerke.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: Network Management Research Group X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Subject: [nmrg] last call on draft-irtf-nmrg-im-dm-00.txt Sender: nmrg-admin@ibr.cs.tu-bs.de Errors-To: nmrg-admin@ibr.cs.tu-bs.de X-BeenThere: nmrg@ibr.cs.tu-bs.de X-Mailman-Version: 2.0.6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: The ID is now in the internet drafts repository. In order to move this document forward, I would like to start a last call period of three weeks ending on August 15th. So please read this document and list any comments you have by August 15th. I have already recorded Dave Sidor's last comment. /js -- Juergen Schoenwaelder Received: from haerke.ibr.cs.tu-bs.de (IDENT:root@haerke.ibr.cs.tu-bs.de [134.169.34.84]) by agitator.ibr.cs.tu-bs.de (8.12.1/8.12.1/Debian -2) with ESMTP id g6P8Mu15008521; Thu, 25 Jul 2002 10:22:56 +0200 Received: (from schoenw@localhost) by haerke.ibr.cs.tu-bs.de (8.11.6/8.11.6) id g6P8MuN08196; Thu, 25 Jul 2002 10:22:56 +0200 Date: Thu, 25 Jul 2002 10:22:56 +0200 Message-Id: <200207250822.g6P8MuN08196@haerke.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: dperkins@dsperkins.com CC: nmrg@ibr.cs.tu-bs.de In-reply-to: <5.1.0.14.2.20020724102056.03692730@127.0.0.1> (dperkins@dsperkins.com) Subject: Re: [nmrg] Model mismatch References: <5.1.0.14.2.20020724102056.03692730@127.0.0.1> X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: nmrg-admin@ibr.cs.tu-bs.de Errors-To: nmrg-admin@ibr.cs.tu-bs.de X-BeenThere: nmrg@ibr.cs.tu-bs.de X-Mailman-Version: 2.0.6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: >>>>> David T Perkins writes: David> I experienced in the past, and I was reminded again of the David> "model mismatch" that is occurring between the "IETF model" and David> the "ITU-T model" of management. Yes. But at least we have moved away from complete ignorance between the two camps over last few years... David> The "telco" model is LOOSELY based on TMN principles. The model David> uses ITU-T documents for device management (such as M.3100) and David> uses the alarm management as specified in X.733. The telco David> model is based on a "network management system" (NMS) using David> CORBA to communicate to an "element management system" David> (EMS). The EMS communicates to the "network elements" (NEs) David> using an unspecified management protocol. David> The problem is that the "management model" implemented by the David> NEs that are IP based, is formed by a combination of IETF David> standard MIB modules, proprietary MIB modules, and CLI. And it David> doesn't look anything like the ITU-T model. But the Telcos want David> the EMS to present a "telco" model to the NMS. They would like David> to believe that IP devices are just like telco devices, and all David> that is needed is a little addition of IP management. They David> don't understand that there is a mismatch of modeling, and that David> an EMS that would do the "remodeling" is a very complex piece David> of software. (I believe it is actually much more complex than David> the software running in the IP devices.) Well, they are probably used to rely on much more complex software than the traditional IP world is. David> Now, if the telco model was a good model, then I would be David> pushing for its adoption by the IETF. So far, my impression is David> that it is different. In general it does some things better, David> but many other things not as good as the IETF model. The most David> important principle of the Internet standards is that David> "Interoperability is the most important issue" does not seem to David> be so with the ITU-T approach. I have the impression (but not David> hard facts) that the telco approach and view of management is David> that "everything is customized". Use of "adaptors" is an David> expected part of adding support for a new device. This view David> affects the standards that specify the model. But the Internet world is no different, especially when we talk about configuration. Except some niches mainly in the Enterprise space (mainly layer two stuff), operators maintain hughe scripts to interact with proprietary CLIs. These are in fact adaptors or mediation devices. David> I don't have any solutions and would be skeptical of anyone David> would said there was a simple solution. However, understanding David> a problem is the first step in developing a workable solution, David> and it doesn't look like many people have an understanding of David> the problem. There is a cultural problem to solve. A few years back, I heard Internet operators to more or less laugh that telco operators have such hughe and complex software systems to run their networks. Now that some of the Internet operators have become much larger, I am surprised that some of them tell us now that they need a common software infrastructure to manage their networks since the home grown solutions are too costly to maintain. On the other hand, I still believe that the telco stuff is sometimes overly complex, especially the implementations. But again, most of this is relatively old stuff and we all know that software systems tend to get more complex and in general uglier over time and it is not really fair to compare it to the latest technologies. I think it is good and valuable that people more seriously talk to each other these days. I guess both sides have an opportunity to learn. /js -- Juergen Schoenwaelder Received: from postman.bayarea.net (postman.bayarea.net [205.219.84.13]) by agitator.ibr.cs.tu-bs.de (8.12.1/8.12.1/Debian -2) with ESMTP id g6OHvO15008653 for ; Wed, 24 Jul 2002 19:57:25 +0200 Received: from host.dsperkins.com (shell4.BAYAREA.NET [209.128.82.1]) by postman.bayarea.net (8.9.3/8.9.3) with ESMTP id KAA77777 for ; Wed, 24 Jul 2002 10:57:18 -0700 (PDT) (envelope-from dperkins@dsperkins.com) Message-Id: <5.1.0.14.2.20020724102056.03692730@127.0.0.1> X-Sender: dperkins@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 24 Jul 2002 10:56:18 -0700 To: nmrg@ibr.cs.tu-bs.de From: "David T. Perkins" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Subject: [nmrg] Model mismatch Sender: nmrg-admin@ibr.cs.tu-bs.de Errors-To: nmrg-admin@ibr.cs.tu-bs.de X-BeenThere: nmrg@ibr.cs.tu-bs.de X-Mailman-Version: 2.0.6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: HI, I experienced in the past, and I was reminded again of the "model mismatch" that is occurring between the "IETF model" and the "ITU-T model" of management. It is being forced by the RBOCs (and the people from that background) that are moving from managing "telco" networks to also managing "IP networks". Just this week I read through a "request for a proposal" from an RBOC that specified the requirements for management. Due to nondisclosure agreements, I cannot provide any details, so I'll describe the situation in high level terms. And please note that this is not the first time I've seen this approach. The "telco" model is LOOSELY based on TMN principles. The model uses ITU-T documents for device management (such as M.3100) and uses the alarm management as specified in X.733. The telco model is based on a "network management system" (NMS) using CORBA to communicate to an "element management system" (EMS). The EMS communicates to the "network elements" (NEs) using an unspecified management protocol. The problem is that the "management model" implemented by the NEs that are IP based, is formed by a combination of IETF standard MIB modules, proprietary MIB modules, and CLI. And it doesn't look anything like the ITU-T model. But the Telcos want the EMS to present a "telco" model to the NMS. They would like to believe that IP devices are just like telco devices, and all that is needed is a little addition of IP management. They don't understand that there is a mismatch of modeling, and that an EMS that would do the "remodeling" is a very complex piece of software. (I believe it is actually much more complex than the software running in the IP devices.) Now, if the telco model was a good model, then I would be pushing for its adoption by the IETF. So far, my impression is that it is different. In general it does some things better, but many other things not as good as the IETF model. The most important principle of the Internet standards is that "Interoperability is the most important issue" does not seem to be so with the ITU-T approach. I have the impression (but not hard facts) that the telco approach and view of management is that "everything is customized". Use of "adaptors" is an expected part of adding support for a new device. This view affects the standards that specify the model. I don't have any solutions and would be skeptical of anyone would said there was a simple solution. However, understanding a problem is the first step in developing a workable solution, and it doesn't look like many people have an understanding of the problem. Regards, /david t. perkins Received: from haerke.ibr.cs.tu-bs.de (IDENT:root@haerke.ibr.cs.tu-bs.de [134.169.34.84]) by agitator.ibr.cs.tu-bs.de (8.12.1/8.12.1/Debian -2) with ESMTP id g6OH9h15006576; Wed, 24 Jul 2002 19:09:43 +0200 Received: (from schoenw@localhost) by haerke.ibr.cs.tu-bs.de (8.11.6/8.11.6) id g6OH9ho31081; Wed, 24 Jul 2002 19:09:43 +0200 Date: Wed, 24 Jul 2002 19:09:43 +0200 Message-Id: <200207241709.g6OH9ho31081@haerke.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: djsidor@nortelnetworks.com CC: pras@cs.utwente.nl, nmrg@ibr.cs.tu-bs.de, boros@cs.utwente.nl, parhonyi@cs.utwente.nl In-reply-to: <3D3EE021.ED49B8FD@americasm01.nt.com> (djsidor@nortelnetworks.com) Subject: Re: [nmrg] Draft version of Information - Data Model RFC References: <3D1C87FF.4050608@ctit.utwente.nl> <3D22129E.CEA331AD@americasm01.nt.com> <200207111000.g6BA0d725693@haerke.ibr.cs.tu-bs.de> <3D3D654E.1060202@ctit.utwente.nl> <3D3EE021.ED49B8FD@americasm01.nt.com> X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: nmrg-admin@ibr.cs.tu-bs.de Errors-To: nmrg-admin@ibr.cs.tu-bs.de X-BeenThere: nmrg@ibr.cs.tu-bs.de X-Mailman-Version: 2.0.6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: >>>>> Dave Sidor writes: Dave> Thanks for the added text, though I would argue that it is not a Dave> given that a DM is constrained by the IM. Thus I would prefer an Dave> explicit statement in any methodology. Aiko, shall we add a general statement that IMs typically constrain the scope of DMs? Any proposals? Dave> However, since Juergen has sent the ID, let it go. And ID is just an ID and we can easily have another one... /js -- Juergen Schoenwaelder Received: from zrtps0kp.nortelnetworks.com (zrtps0kp.nortelnetworks.com [47.140.192.56]) by agitator.ibr.cs.tu-bs.de (8.12.1/8.12.1/Debian -2) with ESMTP id g6OH2c15006160; Wed, 24 Jul 2002 19:02:39 +0200 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps0kp.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g6OH21I04734; Wed, 24 Jul 2002 13:02:02 -0400 (EDT) Received: from zrtpd0j9.us.nortel.com ([47.140.203.27]) by zrtpd0jn.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id P3R31MR2; Wed, 24 Jul 2002 13:01:58 -0400 Received: from americasm01.nt.com (djsidor-2.us.nortel.com [47.142.213.225]) by zrtpd0j9.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id P12FVMDA; Wed, 24 Jul 2002 13:01:58 -0400 Message-ID: <3D3EE021.ED49B8FD@americasm01.nt.com> Date: Wed, 24 Jul 2002 13:13:05 -0400 X-Sybari-Space: 00000000 00000000 00000000 From: "Dave Sidor" Organization: Nortel Networks X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Aiko Pras CC: Juergen Schoenwaelder , Aiko Pras , nmrg@ibr.cs.tu-bs.de, boros@cs.utwente.nl, parhonyi@cs.utwente.nl Subject: Re: [nmrg] Draft version of Information - Data Model RFC References: <3D1C87FF.4050608@ctit.utwente.nl> <3D22129E.CEA331AD@americasm01.nt.com> <200207111000.g6BA0d725693@haerke.ibr.cs.tu-bs.de> <3D3D654E.1060202@ctit.utwente.nl> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: nmrg-admin@ibr.cs.tu-bs.de Errors-To: nmrg-admin@ibr.cs.tu-bs.de X-BeenThere: nmrg@ibr.cs.tu-bs.de X-Mailman-Version: 2.0.6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: Aiko, Thanks for the added text, though I would argue that it is not a given that a DM is constrained by the IM. Thus I would prefer an explicit statement in any methodology. However, since Juergen has sent the ID, let it go. Dave Aiko Pras wrote: > > Hi Dave (and others) > > Thanks for the comments. Below I've included suggestions for textual > changes. Feel free to comment. > > Aiko > --------------------------------------------------------------------- > > Juergen Schoenwaelder wrote: > > >>>>>>Dave Sidor writes: > > Dave> - A minor point: Though ISO/IEC continue to publish GDMO-based > > Dave> information models in partnership with the ITU-T, they have > > Dave> stopped all work on them and as a result the ITU-T in effect > > Dave> "owns", maintains, and continues to enhance these specifications > > Dave> found in the X.700 series of Recommendations (your reference 8 > > Dave> is equivalent to X.722). > > > > I guess you are saying that we should reword the second bullet in > > section 4 to better explain the joint work situation between ISO/IEC > > and ITU-T. I am fine with that. Aiko, do you agree? If yes, can you > > draft some words? > > What about: > - Management Information Bases (MIBs), as originally defined by ISO > and nowadays maintained and enhanced by the ITU-T. > These DMs use the syntax as defined by the "Guidelines for the > Definition of Managed Objects" (GDMO) [8]. GDMO MIBs make also use > of object-oriented principles. > > with reference: > [8] International Telecommunication Union - SG4 - > Telecommunication Management, "Information technology - > Open Systems Interconnection - Structure of Management > Information: Guidelines for the definition of managed > objects", X.722, 1992 > > > Dave> - As the telecom and IP worlds have much more in common these > > Dave> days, I am somewhat disappointed that the moves in telecom > > Dave> management (ITU-T SG 4, 3GPP SA5, TeleManagement Forum, and ATM > > Dave> Forum) to UML-based protocol-neutral information modelling which > > Dave> I described at the IRTF workshop are not given any > > Dave> recognition. As I hopefully noted then, these protocol-neutral > > Dave> models are of interest to more than designers and managers: > > Dave> their contents delimit the functionality that can be included in > > Dave> the protocol-specific information models (or data models as you > > Dave> call them). > > > > OK. If I understand you correctly, we should add text to section 3 > > which explains that information models are used in other places as > > well. We should also add text that the purpose of an information model > > can also be to delimit the functionality of data models. Aiko, do you > > agree? If yes, can you draft some words? > > I agree with adding the references to these other organizations (since I'm > not too familiar with their work, I forgot to mention them. Sorry). > I also agree that these information models delimit the functionality of data > models. However, this seems to be straightforward for me: every higher level > specification delimits the functionality of derived, lower level > specifications (unless the lower level specification is wrong). I therefore > do not know if we have to deal with this in the text. > > What about the following text > (rewording of the third paragraph of section 3): > Optionally IMs can also be defined "formally", using some kind of > (semi) formal language. One of the possibilities to "formally" > specify IMs is to use UML class diagrams. Although such diagrams > are not standardized by the IETF, there are several other > organizations that use UML class diagrams for their IMs. > Examples of such organizations are the DMTF, the ITU-T SG 4, > 3GPP SA5, TeleManagement Forum, and the ATM Forum. > An important advantage of UML class diagrams is that they > represent objects and the relationship between them in a > graphical way. Because of this graphical representation, > designers and operators may find it easier to understand the > underlying management model. Although there are other techniques to > graphically represent objects and the relationship between them > (like, for example, entity-relationship diagrams), UML has the > advantage that it is widely accepted by the industry and > universities. Because of this, there are also many tools that > support the manipulation of UML diagrams. UML itself is standardized > by the Object Management Group (OMG) [10]. > > I'm not sure if we should add the references of UML class diagram examples > defined by the various organizations. Any ideas / proposals? > > > > > Another issue: We should probably reference RFC 3198 somewhere because > > it defines the terms information model and data model: > > > > $ data model > > (T) A mapping of the contents of an information model into a form > > that is specific to a particular type of data store or > > repository. A "data model" is basically the rendering of an > > information model according to a specific set of mechanisms > > for representing, organizing, storing and handling data. It > > has three parts [DecSupp]: > > - A collection of data structures such as lists, tables, > > relations, etc. > > - A collection of operations that can be applied to the > > structures such as retrieval, update, summation, etc. > > - A collection of integrity rules that define the legal > > states (set of values) or changes of state (operations on > > values). > > (See also "information model".) > > > > $ information model > > (T) An abstraction and representation of the entities in a managed > > environment, their properties, attributes and operations, and > > the way that they relate to each other. It is independent of > > any specific repository, software usage, protocol, or > > platform. > > > > We should at least state how the document relates to these definitions. > > Fortunately it seems that our definitions and RFC 3198 do not conflict. > The definitions of IM are in fact quite similar; there are more differences > between both data model definitions. RFC 3198 is probably more aligned with > traditional database terminology, whereas our definition / explanation is > more tailored to management terminology. > > I propose to add some text below the last paragraph of section 1. We should > also include a reference to RFC3198. > > In an attempt to stop this controversy and harmonize terminology, the > IRTF Network Management Research Group (NMRG) [9] organized in > December 2000 a special workshop. For this workshop the IRTF-NMRG > invited leading experts from the IETF, DMTF, ITU as well as the > academic world (see the acknowledgements section for a list of > participants). The workshop was quite successful and its outcome, > which is a better understanding of the terms "Information Model" and > "Data Model", is presented in this document. > > It should be noted that short definitions of both terms can also be found > > within other documents (see for example RFC 3198 [X]). Compared to these > > other documents this document also provides background information > > and examples. > > [X] Westerinen, A., Schnizlein, J., Strassner, J., Scherling, M., Quinn, > B., Herzog, S., Huynh, A., Carlson, M., Perry, J., Waldbusser, S., > "Terminology for Policy-Based Management", RFC 3198, November 2001. Received: from haerke.ibr.cs.tu-bs.de (IDENT:root@haerke.ibr.cs.tu-bs.de [134.169.34.84]) by agitator.ibr.cs.tu-bs.de (8.12.1/8.12.1/Debian -2) with ESMTP id g6NG88Aa027106; Tue, 23 Jul 2002 18:08:08 +0200 Received: (from schoenw@localhost) by haerke.ibr.cs.tu-bs.de (8.11.6/8.11.6) id g6NG88U11508; Tue, 23 Jul 2002 18:08:08 +0200 Date: Tue, 23 Jul 2002 18:08:08 +0200 Message-Id: <200207231608.g6NG88U11508@haerke.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: internet-drafts@ietf.org CC: Network Management Research Group X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Subject: [nmrg] please post draft-irtf-nmrg-im-dm-00.txt Sender: nmrg-admin@ibr.cs.tu-bs.de Errors-To: nmrg-admin@ibr.cs.tu-bs.de X-BeenThere: nmrg@ibr.cs.tu-bs.de X-Mailman-Version: 2.0.6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: Please post the following document as Internet Draft: Thanks, /js -- Juergen Schoenwaelder Received: from haerke.ibr.cs.tu-bs.de (IDENT:root@haerke.ibr.cs.tu-bs.de [134.169.34.84]) by agitator.ibr.cs.tu-bs.de (8.12.1/8.12.1/Debian -2) with ESMTP id g6NFlDAa026265; Tue, 23 Jul 2002 17:47:13 +0200 Received: (from schoenw@localhost) by haerke.ibr.cs.tu-bs.de (8.11.6/8.11.6) id g6NFlD611327; Tue, 23 Jul 2002 17:47:13 +0200 Date: Tue, 23 Jul 2002 17:47:13 +0200 Message-Id: <200207231547.g6NFlD611327@haerke.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: pras@ctit.utwente.nl CC: djsidor@nortelnetworks.com, pras@cs.utwente.nl, nmrg@ibr.cs.tu-bs.de, boros@cs.utwente.nl, parhonyi@cs.utwente.nl In-reply-to: <3D3D654E.1060202@ctit.utwente.nl> (message from Aiko Pras on Tue, 23 Jul 2002 16:16:46 +0200) Subject: Re: [nmrg] Draft version of Information - Data Model RFC References: <3D1C87FF.4050608@ctit.utwente.nl> <3D22129E.CEA331AD@americasm01.nt.com> <200207111000.g6BA0d725693@haerke.ibr.cs.tu-bs.de> <3D3D654E.1060202@ctit.utwente.nl> X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: nmrg-admin@ibr.cs.tu-bs.de Errors-To: nmrg-admin@ibr.cs.tu-bs.de X-BeenThere: nmrg@ibr.cs.tu-bs.de X-Mailman-Version: 2.0.6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: >>>>> Aiko Pras writes: Aiko> Thanks for the comments. Below I've included suggestions for Aiko> textual changes. Feel free to comment. [...] Looks good to me. I have updated the document and I will post the updated as an ID in a few minutes. Once in place, we can start a last call. /js -- Juergen Schoenwaelder Received: from netlx010.civ.utwente.nl (netlx010.civ.utwente.nl [130.89.1.92]) by agitator.ibr.cs.tu-bs.de (8.12.1/8.12.1/Debian -2) with ESMTP id g6NEGrAa022099; Tue, 23 Jul 2002 16:16:54 +0200 Received: from ctit.utwente.nl (utip250.cs.utwente.nl [130.89.12.39]) by netlx010.civ.utwente.nl (8.11.4/HKD) with ESMTP id g6NEGl816349; Tue, 23 Jul 2002 16:16:47 +0200 Message-ID: <3D3D654E.1060202@ctit.utwente.nl> Date: Tue, 23 Jul 2002 16:16:46 +0200 From: Aiko Pras User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: en-us MIME-Version: 1.0 To: Juergen Schoenwaelder , djsidor@nortelnetworks.com CC: Aiko Pras , nmrg@ibr.cs.tu-bs.de, boros@cs.utwente.nl, parhonyi@cs.utwente.nl Subject: Re: [nmrg] Draft version of Information - Data Model RFC References: <3D1C87FF.4050608@ctit.utwente.nl> <3D22129E.CEA331AD@americasm01.nt.com> <200207111000.g6BA0d725693@haerke.ibr.cs.tu-bs.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.5 required=5.0 tests=RCVD_IN_RFCI version=2.20 X-Spam-Level: Sender: nmrg-admin@ibr.cs.tu-bs.de Errors-To: nmrg-admin@ibr.cs.tu-bs.de X-BeenThere: nmrg@ibr.cs.tu-bs.de X-Mailman-Version: 2.0.6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: Hi Dave (and others) Thanks for the comments. Below I've included suggestions for textual changes. Feel free to comment. Aiko --------------------------------------------------------------------- Juergen Schoenwaelder wrote: >>>>>>Dave Sidor writes: > Dave> - A minor point: Though ISO/IEC continue to publish GDMO-based > Dave> information models in partnership with the ITU-T, they have > Dave> stopped all work on them and as a result the ITU-T in effect > Dave> "owns", maintains, and continues to enhance these specifications > Dave> found in the X.700 series of Recommendations (your reference 8 > Dave> is equivalent to X.722). > > I guess you are saying that we should reword the second bullet in > section 4 to better explain the joint work situation between ISO/IEC > and ITU-T. I am fine with that. Aiko, do you agree? If yes, can you > draft some words? What about: - Management Information Bases (MIBs), as originally defined by ISO and nowadays maintained and enhanced by the ITU-T. These DMs use the syntax as defined by the "Guidelines for the Definition of Managed Objects" (GDMO) [8]. GDMO MIBs make also use of object-oriented principles. with reference: [8] International Telecommunication Union - SG4 - Telecommunication Management, "Information technology - Open Systems Interconnection - Structure of Management Information: Guidelines for the definition of managed objects", X.722, 1992 > Dave> - As the telecom and IP worlds have much more in common these > Dave> days, I am somewhat disappointed that the moves in telecom > Dave> management (ITU-T SG 4, 3GPP SA5, TeleManagement Forum, and ATM > Dave> Forum) to UML-based protocol-neutral information modelling which > Dave> I described at the IRTF workshop are not given any > Dave> recognition. As I hopefully noted then, these protocol-neutral > Dave> models are of interest to more than designers and managers: > Dave> their contents delimit the functionality that can be included in > Dave> the protocol-specific information models (or data models as you > Dave> call them). > > OK. If I understand you correctly, we should add text to section 3 > which explains that information models are used in other places as > well. We should also add text that the purpose of an information model > can also be to delimit the functionality of data models. Aiko, do you > agree? If yes, can you draft some words? I agree with adding the references to these other organizations (since I'm not too familiar with their work, I forgot to mention them. Sorry). I also agree that these information models delimit the functionality of data models. However, this seems to be straightforward for me: every higher level specification delimits the functionality of derived, lower level specifications (unless the lower level specification is wrong). I therefore do not know if we have to deal with this in the text. What about the following text (rewording of the third paragraph of section 3): Optionally IMs can also be defined "formally", using some kind of (semi) formal language. One of the possibilities to "formally" specify IMs is to use UML class diagrams. Although such diagrams are not standardized by the IETF, there are several other organizations that use UML class diagrams for their IMs. Examples of such organizations are the DMTF, the ITU-T SG 4, 3GPP SA5, TeleManagement Forum, and the ATM Forum. An important advantage of UML class diagrams is that they represent objects and the relationship between them in a graphical way. Because of this graphical representation, designers and operators may find it easier to understand the underlying management model. Although there are other techniques to graphically represent objects and the relationship between them (like, for example, entity-relationship diagrams), UML has the advantage that it is widely accepted by the industry and universities. Because of this, there are also many tools that support the manipulation of UML diagrams. UML itself is standardized by the Object Management Group (OMG) [10]. I'm not sure if we should add the references of UML class diagram examples defined by the various organizations. Any ideas / proposals? > > Another issue: We should probably reference RFC 3198 somewhere because > it defines the terms information model and data model: > > $ data model > (T) A mapping of the contents of an information model into a form > that is specific to a particular type of data store or > repository. A "data model" is basically the rendering of an > information model according to a specific set of mechanisms > for representing, organizing, storing and handling data. It > has three parts [DecSupp]: > - A collection of data structures such as lists, tables, > relations, etc. > - A collection of operations that can be applied to the > structures such as retrieval, update, summation, etc. > - A collection of integrity rules that define the legal > states (set of values) or changes of state (operations on > values). > (See also "information model".) > > $ information model > (T) An abstraction and representation of the entities in a managed > environment, their properties, attributes and operations, and > the way that they relate to each other. It is independent of > any specific repository, software usage, protocol, or > platform. > > We should at least state how the document relates to these definitions. Fortunately it seems that our definitions and RFC 3198 do not conflict. The definitions of IM are in fact quite similar; there are more differences between both data model definitions. RFC 3198 is probably more aligned with traditional database terminology, whereas our definition / explanation is more tailored to management terminology. I propose to add some text below the last paragraph of section 1. We should also include a reference to RFC3198. In an attempt to stop this controversy and harmonize terminology, the IRTF Network Management Research Group (NMRG) [9] organized in December 2000 a special workshop. For this workshop the IRTF-NMRG invited leading experts from the IETF, DMTF, ITU as well as the academic world (see the acknowledgements section for a list of participants). The workshop was quite successful and its outcome, which is a better understanding of the terms "Information Model" and "Data Model", is presented in this document. It should be noted that short definitions of both terms can also be found within other documents (see for example RFC 3198 [X]). Compared to these other documents this document also provides background information and examples. [X] Westerinen, A., Schnizlein, J., Strassner, J., Scherling, M., Quinn, B., Herzog, S., Huynh, A., Carlson, M., Perry, J., Waldbusser, S., "Terminology for Policy-Based Management", RFC 3198, November 2001. Received: from haerke.ibr.cs.tu-bs.de (IDENT:root@haerke.ibr.cs.tu-bs.de [134.169.34.84]) by agitator.ibr.cs.tu-bs.de (8.12.1/8.12.1/Debian -2) with ESMTP id g6MHHOSP031056; Mon, 22 Jul 2002 19:17:24 +0200 Received: (from schoenw@localhost) by haerke.ibr.cs.tu-bs.de (8.11.6/8.11.6) id g6MHHOC27223; Mon, 22 Jul 2002 19:17:24 +0200 Date: Mon, 22 Jul 2002 19:17:24 +0200 Message-Id: <200207221717.g6MHHOC27223@haerke.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: ajaysingh@india.tejasnetworks.com CC: Network Management Research Group In-reply-to: <3D3C5D78.8ED8BC24@india.tejasnetworks.com> (message from Ajay Kumar singh on Tue, 23 Jul 2002 01:01:04 +0530) References: <3D3C5D78.8ED8BC24@india.tejasnetworks.com> X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Subject: [nmrg] Re: SNMP Payload Compression Sender: nmrg-admin@ibr.cs.tu-bs.de Errors-To: nmrg-admin@ibr.cs.tu-bs.de X-BeenThere: nmrg@ibr.cs.tu-bs.de X-Mailman-Version: 2.0.6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: >>>>> Ajay Kumar singh writes: Ajay> I am working in a group which is doing research on SNMP based Ajay> solution for network management. Presently, I am involved in Ajay> efficient transfer of data over SNMP. One of the technique being Ajay> explored is to employ compression. Ajay> It will be of great help to me if you can provide latest work Ajay> SNMP payload compression (I have got refernce from the minutes Ajay> of nmrg meetings). The ID describing the NMRG proposal has expired. You can still find a copy at: http://www.ibr.cs.tu-bs.de/~schoenw/draft-irtf-nmrg-snmp-compression-01.txt There was recently a message on the EOS working group list that someone implemented this scheme and another scheme on the NET-SNMP stack. /js -- Juergen Schoenwaelder Received: from haerke.ibr.cs.tu-bs.de (IDENT:root@haerke.ibr.cs.tu-bs.de [134.169.34.84]) by agitator.ibr.cs.tu-bs.de (8.12.1/8.12.1/Debian -2) with ESMTP id g6HDlUR0002265; Wed, 17 Jul 2002 15:47:30 +0200 Received: (from schoenw@localhost) by haerke.ibr.cs.tu-bs.de (8.11.6/8.11.6) id g6HDlUx12347; Wed, 17 Jul 2002 15:47:30 +0200 Date: Wed, 17 Jul 2002 15:47:30 +0200 Message-Id: <200207171347.g6HDlUx12347@haerke.ibr.cs.tu-bs.de> X-Authentication-Warning: haerke.ibr.cs.tu-bs.de: schoenw set sender to schoenw@ibr.cs.tu-bs.de using -f From: Juergen Schoenwaelder To: dperkins@dsperkins.com CC: Network Management Research Group In-reply-to: <5.1.0.14.2.20020717061656.0343dbd0@127.0.0.1> (dperkins@dsperkins.com) Subject: Re: [nmrg] next nmrg meeting References: <5.1.0.14.2.20020717061656.0343dbd0@127.0.0.1> Sender: nmrg-admin@ibr.cs.tu-bs.de Errors-To: nmrg-admin@ibr.cs.tu-bs.de X-BeenThere: nmrg@ibr.cs.tu-bs.de X-Mailman-Version: 2.0.6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: >>>>> David T Perkins writes: David> What major city is osnabrueck near? And, how would one get to David> osnabrueck? I guess the answer to this question might be interesting for more people so I am sending the response to the NMRG list. For those who have to fly in, there are basically two options: (1) The nearest airport is called Muenster/Osnabrueck with shuttle buses running between Osnabrueck and the airport. There are however only a few direct international flights, so you probably need a connecting flight from one of the major European hubs. See for details. (2) The nearest major European hubs are Frankfurt and Amsterdam. A train from Frankfurt to Osnabrueck takes about 4 hours while a train from Amsterdam to Osnabrueck takes about 3 hours. See and for details on the airports. You can get German train schedules from . /js -- Juergen Schoenwaelder Received: from mail.ietf54.wide.ad.jp (www.ietf54.wide.ad.jp [133.93.192.80]) by agitator.ibr.cs.tu-bs.de (8.12.1/8.12.1/Debian -2) with ESMTP id g6HCp7R0028539; Wed, 17 Jul 2002 14:51:08 +0200 Received: from ccrle.nec.de (PRAK.dyn.ietf54.wide.ad.jp [133.93.79.94]) by mail.ietf54.wide.ad.jp (8.11.6/8.11.6) with ESMTP id g6HCp0u14523; Wed, 17 Jul 2002 21:51:00 +0900 (JST) Message-ID: <3D35680F.6040502@ccrle.nec.de> Date: Wed, 17 Jul 2002 21:50:23 +0900 From: Marcus Brunner User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: en-us MIME-Version: 1.0 To: Juergen Schoenwaelder CC: Network Management Research Group Subject: Re: [nmrg] next nmrg meeting References: <200207162139.g6GLdBH02829@haerke.ibr.cs.tu-bs.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: nmrg-admin@ibr.cs.tu-bs.de Errors-To: nmrg-admin@ibr.cs.tu-bs.de X-BeenThere: nmrg@ibr.cs.tu-bs.de X-Mailman-Version: 2.0.6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: I am interested in joining. Evenmore after having discussed the XML for Configuration BoF and OpsArea meeting at th IETF. The only thing I can provide is some information what we did with XML on a Service-to-network management interface. Marcus Juergen Schoenwaelder wrote: >In April, we decided that it would be useful to have a meeting to >discuss how web technologies (XML, SOAP, WSDL, ...) can be used for >management. I offered to host such a meeting in Osnabrueck sometime in >September if that is practical for those interested to join. I think >Aiko was the guy left with a token to follow up on this and to make >the meeting happen. > >Aiko, what is the current plan/status? > >/js > Received: from haerke.ibr.cs.tu-bs.de (IDENT:root@haerke.ibr.cs.tu-bs.de [134.169.34.84]) by agitator.ibr.cs.tu-bs.de (8.12.1/8.12.1/Debian -2) with ESMTP id g6GLdBR0029040; Tue, 16 Jul 2002 23:39:11 +0200 Received: (from schoenw@localhost) by haerke.ibr.cs.tu-bs.de (8.11.6/8.11.6) id g6GLdBH02829; Tue, 16 Jul 2002 23:39:11 +0200 Date: Tue, 16 Jul 2002 23:39:11 +0200 Message-Id: <200207162139.g6GLdBH02829@haerke.ibr.cs.tu-bs.de> X-Authentication-Warning: haerke.ibr.cs.tu-bs.de: schoenw set sender to schoenw@ibr.cs.tu-bs.de using -f From: Juergen Schoenwaelder To: Network Management Research Group Subject: [nmrg] next nmrg meeting Sender: nmrg-admin@ibr.cs.tu-bs.de Errors-To: nmrg-admin@ibr.cs.tu-bs.de X-BeenThere: nmrg@ibr.cs.tu-bs.de X-Mailman-Version: 2.0.6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: In April, we decided that it would be useful to have a meeting to discuss how web technologies (XML, SOAP, WSDL, ...) can be used for management. I offered to host such a meeting in Osnabrueck sometime in September if that is practical for those interested to join. I think Aiko was the guy left with a token to follow up on this and to make the meeting happen. Aiko, what is the current plan/status? /js -- Juergen Schoenwaelder Received: from haerke.ibr.cs.tu-bs.de (IDENT:root@haerke.ibr.cs.tu-bs.de [134.169.34.84]) by agitator.ibr.cs.tu-bs.de (8.12.1/8.12.1/Debian -2) with ESMTP id g6BA0dR0030229; Thu, 11 Jul 2002 12:00:39 +0200 Received: (from schoenw@localhost) by haerke.ibr.cs.tu-bs.de (8.11.6/8.11.6) id g6BA0d725693; Thu, 11 Jul 2002 12:00:39 +0200 Date: Thu, 11 Jul 2002 12:00:39 +0200 Message-Id: <200207111000.g6BA0d725693@haerke.ibr.cs.tu-bs.de> X-Authentication-Warning: haerke.ibr.cs.tu-bs.de: schoenw set sender to schoenw@ibr.cs.tu-bs.de using -f From: Juergen Schoenwaelder To: djsidor@nortelnetworks.com, Aiko Pras CC: nmrg@ibr.cs.tu-bs.de, boros@cs.utwente.nl, parhonyi@cs.utwente.nl In-reply-to: <3D22129E.CEA331AD@americasm01.nt.com> (djsidor@nortelnetworks.com) Subject: Re: [nmrg] Draft version of Information - Data Model RFC References: <3D1C87FF.4050608@ctit.utwente.nl> <3D22129E.CEA331AD@americasm01.nt.com> Sender: nmrg-admin@ibr.cs.tu-bs.de Errors-To: nmrg-admin@ibr.cs.tu-bs.de X-BeenThere: nmrg@ibr.cs.tu-bs.de X-Mailman-Version: 2.0.6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: >>>>> Dave Sidor writes: Dave> Here are few comments on your draft: Dave> - I agree the distinction between information and data modeling Dave> made in the draft is one that needs greater exposure, Dave> understanding and application in the near term. Great. Dave> - A minor point: Though ISO/IEC continue to publish GDMO-based Dave> information models in partnership with the ITU-T, they have Dave> stopped all work on them and as a result the ITU-T in effect Dave> "owns", maintains, and continues to enhance these specifications Dave> found in the X.700 series of Recommendations (your reference 8 Dave> is equivalent to X.722). I guess you are saying that we should reword the second bullet in section 4 to better explain the joint work situation between ISO/IEC and ITU-T. I am fine with that. Aiko, do you agree? If yes, can you draft some words? Dave> - As the telecom and IP worlds have much more in common these Dave> days, I am somewhat disappointed that the moves in telecom Dave> management (ITU-T SG 4, 3GPP SA5, TeleManagement Forum, and ATM Dave> Forum) to UML-based protocol-neutral information modelling which Dave> I described at the IRTF workshop are not given any Dave> recognition. As I hopefully noted then, these protocol-neutral Dave> models are of interest to more than designers and managers: Dave> their contents delimit the functionality that can be included in Dave> the protocol-specific information models (or data models as you Dave> call them). OK. If I understand you correctly, we should add text to section 3 which explains that information models are used in other places as well. We should also add text that the purpose of an information model can also be to delimit the functionality of data models. Aiko, do you agree? If yes, can you draft some words? Another issue: We should probably reference RFC 3198 somewhere because it defines the terms information model and data model: $ data model (T) A mapping of the contents of an information model into a form that is specific to a particular type of data store or repository. A "data model" is basically the rendering of an information model according to a specific set of mechanisms for representing, organizing, storing and handling data. It has three parts [DecSupp]: - A collection of data structures such as lists, tables, relations, etc. - A collection of operations that can be applied to the structures such as retrieval, update, summation, etc. - A collection of integrity rules that define the legal states (set of values) or changes of state (operations on values). (See also "information model".) $ information model (T) An abstraction and representation of the entities in a managed environment, their properties, attributes and operations, and the way that they relate to each other. It is independent of any specific repository, software usage, protocol, or platform. We should at least state how the document relates to these definitions. /js -- Juergen Schoenwaelder Received: from zrtps0kn.nortelnetworks.com (zrtps0kn.nortelnetworks.com [47.140.192.55]) by agitator.ibr.cs.tu-bs.de (8.12.1/8.12.1/Debian -2) with ESMTP id g62KhjT8018293; Tue, 2 Jul 2002 22:43:48 +0200 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps0kn.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g62Kh0602571; Tue, 2 Jul 2002 16:43:01 -0400 (EDT) Received: from zrtpd0j9.us.nortel.com ([47.140.203.27]) by zrtpd0jn.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id MZJ9WTBK; Tue, 2 Jul 2002 16:43:01 -0400 Received: from americasm01.nt.com (djsidor-2.us.nortel.com [47.142.213.225]) by zrtpd0j9.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id N7LB5630; Tue, 2 Jul 2002 16:43:01 -0400 Message-ID: <3D22129E.CEA331AD@americasm01.nt.com> Date: Tue, 02 Jul 2002 16:52:46 -0400 X-Sybari-Space: 00000000 00000000 00000000 From: "Dave Sidor" Organization: Nortel Networks X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Aiko Pras CC: "nmrg@ibr.cs.tu-bs.de" , Juergen Schoenwaelder , szabolcs boros , Robert Parhonyi Subject: Re: [nmrg] Draft version of Information - Data Model RFC References: <3D1C87FF.4050608@ctit.utwente.nl> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: nmrg-admin@ibr.cs.tu-bs.de Errors-To: nmrg-admin@ibr.cs.tu-bs.de X-BeenThere: nmrg@ibr.cs.tu-bs.de X-Mailman-Version: 2.0.6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: Aiko, Here are few comments on your draft: - I agree the distinction between information and data modeling made in the draft is one that needs greater exposure, understanding and application in the near term. - A minor point: Though ISO/IEC continue to publish GDMO-based information models in partnership with the ITU-T, they have stopped all work on them and as a result the ITU-T in effect "owns", maintains, and continues to enhance these specifications found in the X.700 series of Recommendations (your reference 8 is equivalent to X.722). - As the telecom and IP worlds have much more in common these days, I am somewhat disappointed that the moves in telecom management (ITU-T SG 4, 3GPP SA5, TeleManagement Forum, and ATM Forum) to UML-based protocol-neutral information modelling which I described at the IRTF workshop are not given any recognition. As I hopefully noted then, these protocol-neutral models are of interest to more than designers and managers: their contents delimit the functionality that can be included in the protocol-specific information models (or data models as you call them). Thanks Dave Received: from tokyo.ccrle.nec.de (tokyo.ccrle.nec.de [195.37.70.2]) by agitator.ibr.cs.tu-bs.de (8.12.1/8.12.1/Debian -2) with ESMTP id g62AYDiY016627; Tue, 2 Jul 2002 12:34:13 +0200 Received: from wallace.heidelberg.ccrle.nec.de (root@wallace.heidelberg.ccrle.nec.de [192.168.102.1]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g62AY8I97397; Tue, 2 Jul 2002 12:34:08 +0200 (CEST) (envelope-from brunner@ccrle.nec.de) Received: from imap.heidelberg.ccrle.nec.de (imap.heidelberg.ccrle.nec.de [192.168.102.11]) by wallace.heidelberg.ccrle.nec.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id MAA15395; Tue, 2 Jul 2002 12:28:43 +0200 Received: from [192.168.102.207] (marcus.heidelberg.ccrle.nec.de [192.168.102.207]) by imap.heidelberg.ccrle.nec.de (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id C96C1491B7; Tue, 2 Jul 2002 12:28:42 +0200 (CEST) Date: Tue, 02 Jul 2002 12:28:44 +0200 From: Marcus Brunner Reply-To: brunner@ccrle.nec.de To: Aiko Pras , "nmrg@ibr.cs.tu-bs.de" Cc: Juergen Schoenwaelder , szabolcs boros , Robert Parhonyi Subject: Re: [nmrg] Draft version of Information - Data Model RFC Message-ID: <6514637.1025612924@[192.168.102.207]> In-Reply-To: <3D1C87FF.4050608@ctit.utwente.nl> References: <3D1C87FF.4050608@ctit.utwente.nl> X-Mailer: Mulberry/2.2.0 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: nmrg-admin@ibr.cs.tu-bs.de Errors-To: nmrg-admin@ibr.cs.tu-bs.de X-BeenThere: nmrg@ibr.cs.tu-bs.de X-Mailman-Version: 2.0.6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: Aiko, Juergen, Thanks a lot for your work. I like it very much. It covers in general also my view. What I found useful in the DMTF was the modeling of relationships in a much easier way then with indexing etc. And they are really available then in the MOF (data model according to your definition). Marcus --On Freitag, 28. Juni 2002 17:59 +0200 Aiko Pras wrote: > Hi everyone > > Below you'll find the draft text Juergen and I have written for an > informational RFC that should explain the differences between Information > and Data models. This RFC is the outcome of our IRTF-NMRG meeting in > december 2000, which was held in Austin (yes, you're right, I'm a little > bit late). Before distributing this document outside the NMRG, I would > like to give all of you the oppertunity to comment on it. Note that I > will be away next week, so don't expect immediate answers. > > Have a nice weekend > > Aiko > > -------------------------------------------------------------------- > Network Working Group A. Pras > Internet-Draft University of Twente > Expires: December 27, 2002 J. Schoenwaelder > University of Osnabrueck > June 28, 2002 > > > On the Difference between Information Models and Data Models > draft-irtf-nmrg-im-dm-00.txt > > Status of this Memo > > This document is an Internet-Draft and is in full conformance with > all provisions of Section 10 of RFC2026. > > Internet-Drafts are working documents of the Internet Engineering > Task Force (IETF), its areas, and its working groups. Note that > other groups may also distribute working documents as Internet- > Drafts. > > Internet-Drafts are draft documents valid for a maximum of six months > and may be updated, replaced, or obsoleted by other documents at any > time. It is inappropriate to use Internet-Drafts as reference > material or to cite them other than as "work in progress." > > The list of current Internet-Drafts can be accessed at > http://www.ietf.org/ietf/1id-abstracts.txt. > > The list of Internet-Draft Shadow Directories can be accessed at > http://www.ietf.org/shadow.html. > > This Internet-Draft will expire on December 27, 2002. > > Copyright Notice > > Copyright (C) The Internet Society (2002). All Rights Reserved. > > Abstract > > There has been ongoing confusion about the differences between > Information Models and Data Models. This document explains the > differences between these terms by analyzing how existing network > management model specifications (from the IETF and other bodies such > as the ITU or the DMTF) fit into the universe of Information Models > and Data Models. > > This memo documents the main results of the 8th workshop of the > Network Management Research Group (NMRG) of the Internet Research > Task Force (IRTF). > > > > Pras & Schoenwaelder Expires December 27, 2002 [Page 1] > > Internet-Draft Information Models vs. Data Models June 2002 > > > Table of Contents > > 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3 > 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 > 3. Information Models . . . . . . . . . . . . . . . . . . . . . . . 4 > 4. Data Models . . . . . . . . . . . . . . . . . . . . . . . . . . 5 > 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 6 > References . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 > Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 > Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 9 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Pras & Schoenwaelder Expires December 27, 2002 [Page 2] > > Internet-Draft Information Models vs. Data Models June 2002 > > > 1. Introduction > > Currently multiple "languages" exist to define "managed" objects. > Examples of such languages are the "Structure of Management > Information" (SMI) [1], the "Structure of Policy Provisioning > Information" (SPPI) [2] and, within the DMTF, the "Managed Object > Format" (MOF) [3]. Despite the fact that multiple languages exist, > there are still some feelings that none of these languages really > suites all needs. To discuss these feelings, the IETF organized for > example at its 48th meeting (summer 2000) a BoF meeting on "Network > Information Modeling" (NIM). > > To understand the advantages and disadvantages, as well as the main > differences between the various languages, there have been many > discussions, also outside the IETF. Unfortunately these discussions > were not always fruitful, primarily because it appeared that people > had different understanding of main terms. In particularly the terms > "Information Model" (IM) and "Data Model" (DM) turned out to be > controversial. > > In an attempt to stop this controversy and harmonize terminology, the > IRTF Network Management Research Group (NMRG) [9] organized in > December 2000 a special workshop. For this workshop the IRTF-NMRG > invited leading experts from the IETF, DMTF, ITU as well as the > academic world (see the acknowledgements section for a list of > participants). The workshop was quite successful and its outcome, > which is a better understanding of the terms "Information Model" and > "Data Model", as presented in this document. > > 2. Overview > > One of the interesting observations at the IRTF-NMRG workshop was > that IMs and DMs are different since they serve different purposes. > The purpose of an IM is to model managed objects at a high conceptual > level, which is easy to understand for the human designer or human > manager. In order to present the overall design as clear as > possible, IMs try to abstract from protocol and implementation > specific details. One important aspect of an IM is that it also > focuses on the relationships between managed objects. > > Compared to IMs, DMs are defined at a lower level of abstraction and > with much more detail. DMs are more intended for implementors, and > include lower level and protocol specific constructs. > > > > > > > > > Pras & Schoenwaelder Expires December 27, 2002 [Page 3] > > Internet-Draft Information Models vs. Data Models June 2002 > > > IM --> conceptual / abstract model > | targeted to the designer and > +----------+---------+ human manager > | | | > DM DM DM --> concrete / detailed model > targeted to the implementor > > The relationship between an IM and DM is shown in the Figure above. > Since conceptual models can be implemented in several different ways, > multiple DMs can be derived from the same IM. > > Although IMs and DMs serve different purposes, it is not possible to > precisely define what details should be expressed in the IM and what > in the DM. Therefore no principle difference exists between both > models; in fact there is a grey area between both which makes it in > certain cases impossible to determine if something is an IM or a DM. > > 3. Information Models > > An IM is primarily useful for designers and managers. The terms > "conceptual models" or "abstract models", which are often used in > literature, relate to IMs. An IM can be implemented in different > ways and mapped upon different protocols; IMs are therefore protocol > neutral. An important characteristic of an IM is that it specifies > the relationship between objects. > > IMs can be defined in an informal way, using natural languages like > English. A good example of an IM is provided by RFC 3290: "An > Informal Management Model for Diffserv Routers" [4]. This RFC > describes a conceptual model of a Diffserv Router, including the > relationship between the components of such a router that need to be > managed. Within the IETF it is quite exceptional that an IM is > described within a separate RFC, however; in such cases the status of > such documents is usually "Informational" and not "Standards Track" > [5]. In general most RFCs that define a MIB module also include some > kind of informal description explaining the model behind that MIB > module. Such a model can be considered as an IM. A good example of > this is RFC 2863, which defines "The Interfaces Group MIB" [6]. Note > that most RFCs include just a rudimentary, incomplete description of > the underlying IM. > > Optionally IMs can also be defined "formally", using some kind of > (semi) formal language. Such formal definitions are not developed > within the IETF. The DMTF, however, uses UML class diagrams to > define IMs in a semi-formal way. An important advantage of UML class > diagrams is that they represent objects and the relationship between > them in a graphical way. Because of this graphical representation, > designers and operators may find it easier to understand the > > > > Pras & Schoenwaelder Expires December 27, 2002 [Page 4] > > Internet-Draft Information Models vs. Data Models June 2002 > > > underlying management model. Although there are other techniques to > graphically represent objects and the relationship between them > (like, for example, entity-relationship diagrams), UML has the > advantage that it is widely accepted by the industry and > universities. Because of this, there are also many tools that > support the manipulation of UML diagrams. UML itself is standardized > by the Object Management Group (OMG) [10]. > > In general, it seems advisable to use object-oriented techniques to > describe an IM. In particular the notions of abstraction and > encapsulation, as well as the possibility that object definitions > include methods are considered to be important. > > 4. Data Models > > Compared to IMs, DMs define managed objects at a lower level of > abstraction. They include implementation and protocol specific > details like, for example, rules that explain how to map managed > objects on lower level protocol constructs. > > The MIB modules defined within the IETF are in fact DMs. The > language (syntax) used to define these DMs is called the "Structure > of Management Information" (SMI) [1], which in turn is based on ASN.1 > [7]. > > Not only IETF MIBs, but also most other standardized management > models are DMs. Examples are: > > o Policy Information Bases (PIBs), which are also developed within > the IETF. PIBs use as syntax the "Structure of Policy > Provisioning Information" (SPPI) [2], which is similar to the SMI > and is also based on ASN.1. > > o Management Information Bases (MIBs), as defined by ISO. These DMs > use the syntax as defined by the "Guidelines for the Definition of > Managed Objects" (GDMO) [8]. ISO MIBs make also use of object- > oriented principles. > > o CIM Schemas, as developed within the DMTF. These DMs use the > syntax as defined by the "Managed Object Formats (MOFs)" [3]. The > DMTF publishes CIM Schemas in the form of graphical UML documents > in addition to this MOF syntax. Because of this graphical > notation, designers and managers may find it easier to understand > CIM Schemas than IETF MIBs. One could therefore argue that CIM > Schemas are closer to IMs then IETF MIBs, which lack such > graphical notation. The UML diagrams can be downloaded from the > DMTF website in PDF as well as VISIO format. (VISIO is one of the > tools to draw UML class diagrams). Note that, in contrast to IETF > > > > Pras & Schoenwaelder Expires December 27, 2002 [Page 5] > > Internet-Draft Information Models vs. Data Models June 2002 > > > MIBS, CIM Schemas make use of object-oriented principles. > > The Figure below shows these examples. The languages that are used > to define the DMs are shown between brackets. > > IM --> IM > | > +----------+-------+-------+--------------+ > | | | | > MIB PIB CIM schema OSI-MIBs --> DM > (SMI) (SPPI) (MOF) (GDMO) > > To illustrate what details are included in a DM, let us consider the > example of IETF MIB modules. As opposed to IMs, IETF MIB modules > include details like OID assignments and indexing structures. The > "relationships" that existed at the IM level are now "implemented" in > terms of OID pointers and indexing relationships manifested in INDEX > clauses. Also many other implementation specific details are > included, like for example MAX-ACCESS and STATUS clauses and > conformance statements. > > A special kind of DM language is the SMIng language designed by the > NMRG. This language was particularly designed at a higher conceptual > level then SMIv1/SMIv2 and SPPI. In fact one of the intentions > behind SMIng was to stop the proliferation of different DM languages > and harmonize the various models. As a result MIBs/PIBs defined in > SMIng can be mapped on different underlying protocols; there is a > mapping on SNMP and there is a mapping on COPS-PR. SMIng is > therefore more protocol neutral than other IETF approaches. SMIng > also supports some object-oriented principles and provides an > extension mechanism which allows to add more features such as support > for methods when the protocols support them without breaking SMIng > implementations. Still SMIng should be considered as a DM; to > express for example the relationship between managed objects, > techniques like UML or ER diagrams give still better results since > these diagrams are easier to understand. > > It should be noted that the SMIng working group within the IETF > decided to not adapt the SMIng language defined by the NMRG. > Instead, the SMIng working group currently focusses resources on > developing a third version of the SMI (SMIv3) which is primarily > targeted towards SNMP and which only incorporates some of the ideas > developed within the NMRG. > > 5. Acknowledgments > > The authors would like to thank everyone who participated at the 8th > IRTF-NMRG meeting (in alphabetic order): Szabolcs Boros, Mark > > > > Pras & Schoenwaelder Expires December 27, 2002 [Page 6] > > Internet-Draft Information Models vs. Data Models June 2002 > > > Brunner, David Durham, Dave Harrington, Jean-Philippe Martin-Flatin, > George Pavlou, Robert Parhonyi, David Perkins, David Sidor, Andrea > Westerinen and Bert Wijnen. > > References > > [1] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, > M. and S. Waldbusser, "Structure of Management Information > Version 2 (SMIv2)", RFC 2578, STD 59, April 1999. > > [2] McCloghrie, K., Fine, M., Seligson, J., Chan, K., Hahn, S., > Sahita, R., Smith, A. and F. Reichmeyer, "Structure of Policy > Provisioning Information (SPPI)", RFC 3159, August 2001. > > [3] Distributed Management Task Force, "Common Information Model > (CIM) Specification Version 2.2", DSP 0004, June 1999. > > [4] Bernet, Y., Blake, S., Grossman, D. and A. Smith, "An Informal > Management Model for Diffserv Routers", RFC 3290, May 2002. > > [5] Bradner, S., "The Internet Standards Process -- Revision 3", RFC > 2026, October 1996. > > [6] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", > RFC 2863, June 2000. > > [7] International Organization for Standardization, "Information > processing systems - Open Systems Interconnection - > Specification of Abstract Syntax Notation One (ASN.1)", > International Standard 8824, December 1987. > > [8] International Organization for Standardization, "Information > technology - Open Systems Interconnection - Structure of > Management Information - Part 4: Guidelines for the Definition > of Managed Objects", International Standard 10165-4, 1992. > > [9] > > [10] > > > > > > > > > > > > > Pras & Schoenwaelder Expires December 27, 2002 [Page 7] > > Internet-Draft Information Models vs. Data Models June 2002 > > > Authors' Addresses > > Aiko Pras > University of Twente > PO Box 217 > 7500 AE Enschede > The Netherlands > > Phone: +31 53 4893778 > EMail: pras@ctit.utwente.nl > > > Juergen Schoenwaelder > University of Osnabrueck > Albrechtstr. 28 > 49069 Osnabrueck > Germany > > Phone: +49 541 969-2483 > EMail: schoenw@informatik.uni-osnabrueck.de > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Pras & Schoenwaelder Expires December 27, 2002 [Page 8] > > Internet-Draft Information Models vs. Data Models June 2002 > > > Full Copyright Statement > > Copyright (C) The Internet Society (2002). All Rights Reserved. > > This document and translations of it may be copied and furnished to > others, and derivative works that comment on or otherwise explain it > or assist in its implementation may be prepared, copied, published > and distributed, in whole or in part, without restriction of any > kind, provided that the above copyright notice and this paragraph are > included on all such copies and derivative works. However, this > document itself may not be modified in any way, such as by removing > the copyright notice or references to the Internet Society or other > Internet organizations, except as needed for the purpose of > developing Internet standards in which case the procedures for > copyrights defined in the Internet Standards process must be > followed, or as required to translate it into languages other than > English. > > The limited permissions granted above are perpetual and will not be > revoked by the Internet Society or its successors or assigns. > > This document and the information contained herein is provided on an > "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING > TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING > BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION > HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF > MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. > > Acknowledgement > > Funding for the RFC Editor function is currently provided by the > Internet Society. > > > > > > > > > > > > > > > > > > > > Pras & Schoenwaelder Expires December 27, 2002 [Page 9] > > > -- > !! This message is brought to you via the `nmrg' mailing list. > !! Please do not reply to this message to unsubscribe. To unsubscribe or > adjust !! your settings, send a mail message to > !! or look at > https://www.ibr.cs.tu-bs.de/mailman/listinfo/nmrg. -------------------------------------- Dr. Marcus Brunner Network Laboratories NEC Europe Ltd. E-Mail: brunner@ccrle.nec.de WWW: http://www.ccrle.nec.de/ personal home page: http://www.brubers.org/marcus