Return-Path: Received: by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) id EAA26076 for nmrg-outgoing; Thu, 30 Mar 2000 04:06:05 +0200 (MET DST) Received: from rerun.lucentctc.com (rerun.lucentctc.com [199.93.237.2]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) with ESMTP id EAA25926 for ; Thu, 30 Mar 2000 04:05:31 +0200 (MET DST) Received: by rerun.lucentctc.com with Internet Mail Service (5.5.2448.0) id ; Wed, 29 Mar 2000 21:04:47 -0500 Message-ID: <75ADD7496F0BD211ADC000104B8846CF01911683@rerun.lucentctc.com> From: "Weiss, Walter" To: "'J.P. Martin-Flatin'" Cc: Network Management Research Group , "'David.Durham@intel.com'" , "'td@snia.org'" Subject: [nmrg] RE: Comments on Date: Wed, 29 Mar 2000 21:04:46 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-nmrg@ibr.cs.tu-bs.de Precedence: bulk Status: RO Jean-Philippe, Comments Inline... > > 2) [...] > > > > [Walter] I won't disagree with you here. This is purely a > terminology > > question. The fact is that on the Mumble list, we had a > debate about the > > merits of creating yet another model in the form of PIBs. > There was some > > confusion about terminology, so John Strassner proposed > that we use the term > > "Information Model" to refer to any paradigm independent > model and "Data > > Model" to refer to the application of an information model > to a specific > > paradigm. After some consensus around these terms, it was > agreed that these > > terms would be incorporated in the policy terminology doc. > If you prefer a > > different term or set of terms, I would encourage you to > raise your concerns > > in the context of the policy terminology draft. > > Walter, > > I guess the draft you are referring to is > . > This I-D was unfortunately obsoleted on March 20; it has now > disappeared > from all the usual archives. I didn't find it either at > . Could you > please send me a > copy? > > What is the "Mumble list"? Is it a nickname of the mailing > list used by > the IETF Policy Framework WG? > > Do you think I stand a chance to convince the IETF Policy WG > to change its > terminology or is this a lost cause? The meaning given above > to a "data > model" is different from that taught in all > software-engineering classes > worldwide. Ditto for "information model". Why did you guys > redefine these > well-established phrases? > I agree with all of Juergen's comments here. I would think it is possible to change the terminology here since this is still an active discussion. I would encourage you to get involved. > > 6) [...] > > > > [Walter] I can say with certainty that the DMTF does not > have the subject > > matter experts from the networking community to produce a > viable information > > model (for networks). > > Supposing you are right, this information is by definition > short-lived. > By the time your I-D becomes an RFC, experts might have > joined the DMTF > Network WG. Therefore, you should not write this in my view. > I disagree. The DMTF attracts modelers. It does not attract QoS or Address Management, or Routing experts. The fact of the matter is that working groups like DiffServ, DHCP, etc. are the ones who need to specify conceptual components and the attributes necessary to manage a cross-section of different devices. If we did this in the DMTF, then we might as well combine the DMTF and IETF meetings. > > 14) A general comment on section 3: Why don't you mandate that the > > information model be object-oriented? You render mandatory all the > > characteristics of an object model, but you don't exlicitly mandate > > object orientation. Why? > > > > [Walter] We probably should be explicit. However, the > authors are not > > entirely in agreement that all the elements that constitute > the definition > > of object-oriented should be incorporated in the model. We > chose to include > > them anyway for the sake of completeness and to encourage > discussion. > > Therefore, when all is said and done, we may not be true to > the definition. > > Aren't you splitting hair, here? Why not call it > object-oriented, to help > general understanding, and then give some nuances? There's no > consensus in > the software-engineering community on what is mandatory in an > OO model and > what isn't (if you aren't convinced, just attend ECOOP or > OOPSLA once). And > there's so much OO stuff in your model that I don't see a > good reason not > to call it OO. This time, you would not break a well-accepted > definition, > for sure! > I would suggest that we first review the requirements and develop consensus on the subset we want to adopt. Then we can decide whether indeed the term OO would clarify or confuse what we are doing. regards, -Walter Return-Path: Received: by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) id RAA29078 for nmrg-outgoing; Tue, 28 Mar 2000 17:20:14 +0200 (MET DST) 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 RAA29053; Tue, 28 Mar 2000 17:20:00 +0200 (MET DST) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id RAA27310; Tue, 28 Mar 2000 17:19:54 +0200 Date: Tue, 28 Mar 2000 17:19:54 +0200 Message-Id: <200003281519.RAA27310@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: jp.martin-flatin@ieee.org CC: WWeiss@lucentctc.com, nmrg@ibr.cs.tu-bs.de, jp.martin-flatin@ieee.org In-reply-to: <200003281501.RAA22150@icasun1.epfl.ch> (jp.martin-flatin@ieee.org) Subject: Re: [nmrg] Re: Comments on References: <200003281501.RAA22150@icasun1.epfl.ch> Sender: owner-nmrg@ibr.cs.tu-bs.de Precedence: bulk Status: RO >>>>> J P Martin-Flatin writes: JP> I guess the draft you are referring to is JP> . This I-D was unfortunately JP> obsoleted on March 20; it has now disappeared from all the usual JP> archives. I didn't find it either at JP> . Could you please JP> send me a copy? Look instead into . There is a policy terminology design team which is responsible to clear up the terminology across several IETF WGs. JP> What is the "Mumble list"? Is it a nickname of the mailing list JP> used by the IETF Policy Framework WG? The right place for policy terminology discussions is . JP> Do you think I stand a chance to convince the IETF Policy WG to JP> change its terminology or is this a lost cause? The meaning given JP> above to a "data model" is different from that taught in all JP> software-engineering classes worldwide. Ditto for "information JP> model". Why did you guys redefine these well-established phrases? Can you please tell us (and the IETF folks) what is teached on all software-engineering classes worldwide? It has been a real problem that people use terms such as data model, schema, information model, meta model with different interpretations which has been a great source of mis-understandings within the IETF. /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 RAA28061 for nmrg-outgoing; Tue, 28 Mar 2000 17:02:22 +0200 (MET DST) Received: from icasun1.epfl.ch (root@icasun1.epfl.ch [128.178.151.148]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) with ESMTP id RAA28033 for ; Tue, 28 Mar 2000 17:02:10 +0200 (MET DST) Received: from ica.epfl.ch (jpmf@tcomhp33.epfl.ch [128.178.151.24]) by icasun1.epfl.ch (8.8.X/EPFL-8.1d for ICA) with ESMTP id RAA22150; Tue, 28 Mar 2000 17:01:21 +0200 (MET DST) Message-Id: <200003281501.RAA22150@icasun1.epfl.ch> X-Mailer: exmh version 2.1.1 10/15/1999 From: "J.P. Martin-Flatin" To: "Weiss, Walter" Cc: Network Management Research Group , "J.P. Martin-Flatin" Reply-To: "J.P. Martin-Flatin" Subject: [nmrg] Re: Comments on In-reply-to: Your message of "Fri, 24 Mar 2000 00:37:09 MET." <75ADD7496F0BD211ADC000104B8846CF01E85DF9@rerun.lucentctc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 28 Mar 2000 17:01:20 +0200 Sender: owner-nmrg@ibr.cs.tu-bs.de Precedence: bulk Status: RO On Fri, 24 Mar 2000 00:37:09 -0500, "Weiss, Walter" wrote: > > 2) [...] > > [Walter] I won't disagree with you here. This is purely a terminology > question. The fact is that on the Mumble list, we had a debate about the > merits of creating yet another model in the form of PIBs. There was some > confusion about terminology, so John Strassner proposed that we use the term > "Information Model" to refer to any paradigm independent model and "Data > Model" to refer to the application of an information model to a specific > paradigm. After some consensus around these terms, it was agreed that these > terms would be incorporated in the policy terminology doc. If you prefer a > different term or set of terms, I would encourage you to raise your concerns > in the context of the policy terminology draft. Walter, I guess the draft you are referring to is . This I-D was unfortunately obsoleted on March 20; it has now disappeared from all the usual archives. I didn't find it either at . Could you please send me a copy? What is the "Mumble list"? Is it a nickname of the mailing list used by the IETF Policy Framework WG? Do you think I stand a chance to convince the IETF Policy WG to change its terminology or is this a lost cause? The meaning given above to a "data model" is different from that taught in all software-engineering classes worldwide. Ditto for "information model". Why did you guys redefine these well-established phrases? > 6) [...] > > [Walter] I can say with certainty that the DMTF does not have the subject > matter experts from the networking community to produce a viable information > model (for networks). Supposing you are right, this information is by definition short-lived. By the time your I-D becomes an RFC, experts might have joined the DMTF Network WG. Therefore, you should not write this in my view. > 14) A general comment on section 3: Why don't you mandate that the > information model be object-oriented? You render mandatory all the > characteristics of an object model, but you don't exlicitly mandate > object orientation. Why? > > [Walter] We probably should be explicit. However, the authors are not > entirely in agreement that all the elements that constitute the definition > of object-oriented should be incorporated in the model. We chose to include > them anyway for the sake of completeness and to encourage discussion. > Therefore, when all is said and done, we may not be true to the definition. Aren't you splitting hair, here? Why not call it object-oriented, to help general understanding, and then give some nuances? There's no consensus in the software-engineering community on what is mandatory in an OO model and what isn't (if you aren't convinced, just attend ECOOP or OOPSLA once). And there's so much OO stuff in your model that I don't see a good reason not to call it OO. This time, you would not break a well-accepted definition, for sure! Jean-Philippe ____________________________________________________________ J.P. Martin-Flatin, EPFL-DSC-ICA, 1015 Lausanne, Switzerland Email: jp.martin-flatin@ieee.org Fax: +41-21-693-66-10 Web: http://icawww.epfl.ch/~jpmf/ Return-Path: Received: by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) id RAA24092 for nmrg-outgoing; Mon, 27 Mar 2000 17:33:52 +0200 (MET DST) 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 RAA24084; Mon, 27 Mar 2000 17:33:50 +0200 (MET DST) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id RAA05876; Mon, 27 Mar 2000 17:33:44 +0200 Date: Mon, 27 Mar 2000 17:33:44 +0200 Message-Id: <200003271533.RAA05876@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: Network Management Research Group Subject: [nmrg] FWD: RE: Comments on Sender: owner-nmrg@ibr.cs.tu-bs.de Precedence: bulk Status: RO I am forwarding the attached message, which is a response to JP's comments. I have added Walter Weiss to the nmrg.posters list so that subsequent mails from Walter will go directly to the nmrg list. /js ------- Start of forwarded message ------- Date: Fri, 24 Mar 2000 06:37:52 +0100 (MET) From: owner-nmrg@ibr.cs.tu-bs.de To: owner-nmrg@ibr.cs.tu-bs.de Subject: BOUNCE nmrg@ibr.cs.tu-bs.de: Non-member submission from ["Weiss, Walter" ] >From schoenw Fri Mar 24 06:37:50 2000 Received: from rerun.lucentctc.com (rerun.lucentctc.com [199.93.237.2]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) with ESMTP id GAA24291 for ; Fri, 24 Mar 2000 06:37:49 +0100 (MET) Received: by rerun.lucentctc.com with Internet Mail Service (5.5.2448.0) id ; Fri, 24 Mar 2000 00:37:14 -0500 Message-ID: <75ADD7496F0BD211ADC000104B8846CF01E85DF9@rerun.lucentctc.com> From: "Weiss, Walter" To: "J.P. Martin-Flatin" , David.Durham@intel.com, td@snia.org Cc: Network Management Research Group Subject: RE: Comments on Date: Fri, 24 Mar 2000 00:37:09 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" JP, Thanks for the thorough review. Comments in two parts below and to your text doc (embedded). regards, - -Walter > > Please find enclosed some comments on > (release of March 9, 2000). I fully agree with the point you make in > the abstract. I think there are many good things in your I-D. Have > you looked at ODMA and the work done by the OMG? Truth be told, we are aware of a number of activities by a variety of standards bodies and consortia in this space (including TIPHON, Parley, and the TMF). I have not kept abreast of all these activities. However, I am compiling a rather large list of additional activities that need to be monitored more closely. > I am not following > these efforts closely, but I think they could be useful to you. You > might also be interested in reading this article: > > A.I. Riviere and M. Sibilla. "Management Information Models > Integration: From Existing Approaches to New Unifying Guidelines". > Journal of Network and Systems Management, 6(3):333-356, 1998. > This sounds interesting. I will take a look. - ----------------- 1) Page 3, lines 2-4, you say that in Web-based management, "data structures are defined in the absence of standards". I disagree: The DMTF is working precisely on this. The CIM schemas that are expected to come out of the different working groups this year should be considered as "standards", if we call an IETF MIB a standard. I don't think the IETF should implicitly deny the work done by the DMTF. [Walter] What we were refering to was not the WBEM activity but rather the popular use web-based management applications embedded in web servers on networking devices. 2) I think you should define your terminology in the abstract. Page 3, you state: "What is required is a common representation of data (an "information model"). A few lines further, you say: "The purpose of an information model is to represent data in a manner that is independent of technology and implementation.". Stricto sensu, this is wrong because you show only part of the picture. Defining an information model encompasses three things: * First and foremost, the definition of the management data itself; e.g., SNMP MIBs and CIM schemas. * Second, the definition of a metamodel which governs the expressive- ness of your information model; e.g., SMIv2 with SNMP. * Third, the representation of data; e.g., with SNMP, MIB variables are organized as an inverted hierarchical tree; e.g., in MIB-II, the error rate for inbound traffic through interface #3 is represented as 1.3.6.1.2.1.2.2.1.14.3; e.g., Java objects with JMX. In the SNMP realm, the definition of an information model is primarily concerned with the definition of the entities in the MIB (which is difficult), and secondarily with the representation of these entities (which is often very easy). There seems to be some confusion about the meaning of the phrase "information model" within the IETF community. I already pointed out a similar confusion to Juergen Schoenwaelder, who is one of the driving forces in the SNMPv3 WG. In the SNMP world, the information model consists of all the MIBs, SMIv1, and SMIv2. In WBEM, it consists of all CIM schemas and MOF. [Walter] I won't disagree with you here. This is purely a terminology question. The fact is that on the Mumble list, we had a debate about the merits of creating yet another model in the form of PIBs. There was some confusion about terminology, so John Strassner proposed that we use the term "Information Model" to refer to any paradigm independent model and "Data Model" to refer to the application of an information model to a specific paradigm. After some consensus around these terms, it was agreed that these terms would be incorporated in the policy terminology doc. If you prefer a different term or set of terms, I would encourage you to raise your concerns in the context of the policy terminology draft. 3) Page 3, you state: "The purpose of an information model *is* to represent data in a manner that is independent of technology and implementation". I would rephrase this sentence as follows: "We claim that the purpose of an information model should be to define and represent data in a manner that is independent of technology and implementation". Your verb "is" is wrong: Typically, information models are not technology-independent today. But I agree that it would be a good idea to change habits and make information models technology- independent. [Walter] As I said in 2 above, we were using the terms referenced in the terminology draft. However, it is reasonable to reference the terminology draft explicictly in this context to make this clearer. 4) Page 3, at the end of the abstract, you state: "that describe the conventions for the information model and the information model itself". I find it confusing. If I understand you correctly, I suggest you rephrase it as follows: "that describe the information model and its metamodel". [Walter] We had discussions amoung the authors because some thought it was too vague. As I recall, conventions referred to the equivalent of SMI while the information model itself referred to the actual data structures being defined. 5) Page 4, you state: "This will in turn produce domain-specific data models that are all derived from a common network information model". Later, you say: "transforming the information model into specific data models". I don't like your terminology here. For you, a data model is a particular instance of an information model: It is technology and implementation dependent. Usually, in computer science, "data model" is opposed to "object model". A typical criticism of information modeling in the SNMP world is that it aims at producing data models, whereas most people would rather use object models (this is addressed by the DMTF with CIM). I therefore suggest you use "generic information model" and "specific information model" instead. [Walter] See comments to 2 and 3 above. As a side note, I would agree that the term domain-specific was a poor choice. In my mind this could be interpreted to mean either technologies (DiffServ, DHCP) or management paradigms (COPS, SNMP, HTTP, CORBA, LDAP, etc.) This should be fixed. 6) Page 5, you should delete: "Finally, the DMTF does not have the subject matter experts in networking, as does the IETF". It is polemic, wrong, and useless. Some companies have moved their experts from the IETF to the DMTF because they thought that the IETF was deadlocked with SNMP. I would rather the IETF and DMTF work together than criticize each other. This is not a U.S. presidential election... :-) [Walter] I can say with certainty that the DMTF does not have the subject matter experts from the networking community to produce a viable information model (for networks). That is not to say that the DMTF does not have subject matter experts. There is a strong representation from the host community that has done some good work in the area of systems and devices. However, in networks, the number of subject matter experts are virtually non-existent. I started participating a year and a half ago and David started six months ago, and the two of us have a good understanding of QoS. There is noone else that I could point to that understands the other aspects of networking to the same extent we have an understanding of QoS. The main point here is not to critize the DMTF but rather to recognize that the IETF needs to take more responsibility to define these models as part of the process of standardizing new technologies. I have little confidence that the DMTF is going to attract the expertise necessary to do this work independently. If I am wrong, it will be with a smile on my face because I don't care were the work is done. However, I have attended virtually every meeting of the networks working group of the DMTF, so I know what it will take to change the situation. 7) Page 5, at the beginning of section 3.1, replace "complimentary" with "complementary" (twice). [Walter] Ok. 8) Page 6, section 3.2, what are these "keys"? Those used for strong security? [Walter] This requires a bit of context. In CIM, keys are used as identifiers for object instances. There are many rules in CIM to deal with maintaining addressing consistency and backwards compatibility. Within the DMTF, the application of keys and the semantics surrounding keys have been the source for many arguements. Because it makes the model more complicated and polarizes the vendors whose implementations of CIM assume specific restrictions on the use of keys, it was felt that specifying it in the model would add controversy and slow standards development. 9) Page 6, section 3.3, line 1, delete "such". [Walter] Ok. 10) Page 6, section 3.3, you leave it to the working group to decide on the definition language for the textual representation of the information model. What about suggesting (but not imposing) to use XML? [Walter] I am agnostic on this because there are too many with opinions. If there is broad consensus around XML, that is great. However, effort has also been expended on MIB and CIM representations and I don't want to be dismissive of these alternatives. 11) Page 6, section 3.4, you use the NIM acronym but you forgot to define it before. [Walter] We may have only covered this in the abstract. Sorry. 12) Page 7, bullet "constraints for classes", there is a typo after "Class B": A quote was replaced by an 8-bit character. [Walter] Ok. 13) Page 8, a carriage return is missing between sections 3.9 and 3.10. [Walter] Ok. 14) A general comment on section 3: Why don't you mandate that the information model be object-oriented? You render mandatory all the characteristics of an object model, but you don't exlicitly mandate object orientation. Why? [Walter] We probably should be explicit. However, the authors are not entirely in agreement that all the elements that constitute the definition of object-oriented should be incorporated in the model. We chose to include them anyway for the sake of completeness and to encourage discussion. Therefore, when all is said and done, we may not be true to the definition. 15) Page 9, section 3.12: I totally disagree. Subscription to subsets of data is desirable, but it has nothing to do with the definition of an information model. This section should be deleted. [Walter] This was one of the elements that we decided deserved broader discussion before a disposition was reached. Therefore, we will keep it in until we have a quorum one way or the other. 16) Page 9, section 3.13: Means for testing compliance should be recommended, not mandated. [Walter] This was wishful thinking. For all intents, this activity would fall outside the purview of the IETF. However, it is a crucial component to the long term success of this approach. 17) Page 10, section 3.15, same typo as described above after "Class XYZ". [Walter] Ok. 18) Page 10, replace "Where IPADDRESSMASK" with "where IPADDRESSMASK". [Walter] Ok. 19) Page 12, definition of CIM: Replace "Mangement" with "Management" and delete extra white space before "Common". [Walter] Ok. 20) Page 13, reference for CIM: You should refer to a specific document instead of simply giving a URL pointing to the latest specification of CIM. CIM is regularly updated by the DMTF, and some of your statements may be wrong in 2-3 years. [Walter] Fair enough. Thanks again for all the comments. ------- End of forwarded message ------- Return-Path: Received: by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) id QAA20191 for nmrg-outgoing; Mon, 27 Mar 2000 16:31:15 +0200 (MET DST) 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 QAA20186 for ; Mon, 27 Mar 2000 16:31:14 +0200 (MET DST) Received: from cs.utwente.nl (utip074.cs.utwente.nl [130.89.12.43]) by utrhcs.cs.utwente.nl (8.9.3/8.9.3) with ESMTP id QAA13527; Mon, 27 Mar 2000 16:31:06 +0200 (MET DST) Message-ID: <38DF708A.183F4C03@cs.utwente.nl> Date: Mon, 27 Mar 2000 16:30:34 +0200 From: Ron Sprenkels Organization: University of Twente X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Network Management Research Group Subject: [nmrg] Re: Policy 2001 References: <4.3.1.2.20000327122227.00b703a0@dse-mail.doc.ic.ac.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-nmrg@ibr.cs.tu-bs.de Precedence: bulk Status: RO > Policy 2001: Workshop on Policies for Distributed Systems and Networks > 29-31 January 2001 > Hosted by: HP Laboratories, Bristol, UK I've added this one to the events page. Looks interesting. Ron. -------------------------------------------------------------------------- Ron Sprenkels sprenkel@cs.utwente.nl http://www.cs.utwente.nl/~sprenkel University of Twente, Department of Computer Science, TSS Management group P.O. Box 217, 7500 AE Enschede, The Netherlands. (Tel. +31 53 489 4663) Return-Path: Received: by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) id PAA16641 for nmrg-outgoing; Mon, 27 Mar 2000 15:19:33 +0200 (MET DST) 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 PAA16636 for ; Mon, 27 Mar 2000 15:19:32 +0200 (MET DST) Received: from cs.utwente.nl (utip074.cs.utwente.nl [130.89.12.43]) by utrhcs.cs.utwente.nl (8.9.3/8.9.3) with ESMTP id PAA10621; Mon, 27 Mar 2000 15:19:23 +0200 (MET DST) Message-ID: <38DF5FBC.21C2E7B6@cs.utwente.nl> Date: Mon, 27 Mar 2000 15:18:52 +0200 From: Ron Sprenkels Organization: University of Twente X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Network Management Research Group Subject: [nmrg] Minutes of the 6th NMRG meeting held March 16-17 at the University of Twente, Enschede, The Netherlands. Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-nmrg@ibr.cs.tu-bs.de Precedence: bulk Status: RO Minutes of the 6th Network Management Research Group meeting, held at the University of Twente in Enschede, The Netherlands on march 16-17, 2000. Present: Juergen Schoenwaelder (JS), Frank Strauss (FS), Aiko Pras (AP), Szabolcs Boros (SB), Robert Parhonyi (RP), Ron Sprenkels (RS, minutes), Bert-Jan van Beijnum (BB), Bert Wijnen (BW) Agenda 1) Data modeling 2) SMIng and operations 3) SNMP architecture extensions for operations 4) SNMP protocol extensions for operations Agenda Item #1: Data modeling Discussion of on Network Information Model Requirements. The draft proposes to develop a technology independent network information model, and map it to existing data models. AP has strong doubts if this idea will work. He mentions a few earlier attempts at this that failed. Issue: Only the lowest common denominator of the target data models can be used effectively. Issue: How does an architecture relate to an information model. - Every formally expressed information model is technology dependent, which contradicts the goal to be technology independent. - What is the problem an information model is trying to solve? (a) industry cost reduction (b) IETF cost reduction You only get only a cost reduction if the - costs for developing the NIM - costs for learning how to use the NIM - costs for tools etc. balance the savings from having a NIM. BW: Do we need a network information model? Is this still timely work? (RS: no notes on the answer) AP: Information or data models are at different levels. SMI is at lowest level, SPPI is slightly higher, GDMO yet higher, CIM highest level. Above all that, the general to be defined information model, that should map to the listed lower level concrete models. AP: SMI and CIM are the key models. BW: What about CORBA. Security, is it the thing that causes the problem? BW: I don't think so: SNMPv3 added security to the Internet Management Framework, but still v3 is not widely implemented, deployed or used. Groups like ETSI, typhoon (an IP telephony project), ITU, do work on information modeling. Is OSI management still used? JS: It is used e.g. to manage GSM networks or SDH networks. Is SNMP used for systems management? AP: no, BW, JS: yes. There is the host resources MIB, and proprietary MIBs are used for systems management, although the big market is using proprietary protocols. JS: IETF only has limited human resources to do actual work. The IETF may reach a point where everybody is spending all his time monitoring everybody else and nobody is doing actual work anymore. Starting a IETF working group on information modeling can be seen as a political statement against DMTF/CIM. is the mailinglist for the NIM discussions. It was announced at the ietf-announce mailinglist. BW suggests to post comments on draft-durham-nim-req-00.txt to this list. Problem why cooperation DMTF and policy framework does not go well: One experience is that mapping CIM to LDAP is difficult. -- coffee break -- There is a big book on CORBA specification translations and interactions translations. (RS: I think this was mentioned by JS, no notes on the context) The mapping from SMIv2 to IDL works, but has a versioning problem. JS implemented it. The SPPI basically adds two operations (install/remove) to the SMIv2. JS: Common LDAP schemas are not widely deployed or standardized. JS: The main goal of the SMIng work is to be able to map SMIng to SMIv2, and obsoleting the need for SPPI. In addition, design decisions should be made taking into account existing mappings (e.g. SMIv2 to CORBA IDL). (Don't make them more complicated if it can be avoided.) It has not been a goal so far to define new mappings. AP: Readability and reusability of specifications work against each other. (The example of the GDMO registration tree, and references to it from MIB specs in GDMO was discussed shortly.) Requirement no. 15 is about compound data types: not mappable to SMIv2 right now. BW: similar issue was counter64. 'We' made constraints when it could be used. Maybe it is OK to add compound types even if they can't be mapped to SMIv2 or the current flavor of SNMPv3. -- lunch break -- Summary of the debate of this morning on the information models. - Defining a high level information model without taking lower level models to map to into account will not likely succeed. - The level of SMIng was moved slightly up to prevent the need for SPPI and to evolve the SNMP framework. - How to decide what goes into SMIng and what not? - Naming within SMIng: Classes versus Tables. SMIng solves the SMI part of the 64 bit integer problem. Issue: Where to limit the scope of the SMIng effort to. To SMIv2 and SPPI (lowest level) or include IDL, and or LDAP. Supporting policies in the repository could give support from the groups that define them; Opening up SMIng to include a mapping to LDAP could improve support. BW: Could you express a Policy Framework schema in SMIng? JS: SMIng was not designed for that... AP proposes to do a feasibility study to a SMIng to LDAP mapping. JS: Need an SMIng "guru" and an LDAP "guru". Potentially takes a week per person. JS: What is the purpose, technical or political? Consensus: for the better part political. JS: Are there LDAP experts in Europe? BW knows one in Norway; and maybe Harald Alvestrand. And there might be more in Scandinavia; Eric Huizer might know a few people that have this kind of knowledge. When doing the exercise of a SMIng to LDAP Schema mapping, since SMIng is not fixed yet, this would also mean revising some of the SMIng design decisions. For the feasibility study, probably FS or JS should be involved. More data models to map to? BW: WMI Web-based Management Interface (of Microsoft)? : This draft is on a MIB object dependency expression language. AP thinks its too complex, you lose more than you gain. JS: Some of the issues raised by the draft will go away by adding operations to SMIng. The draft helps to automatically generate management applications. The draft is mainly useful for boxes that have writable objects. JS: This type of extension could be supported in the form of an SMIng extension rather than being a core language feature. The SMIng already supports an extension mechanism. What is still needed is an annotation mechanism. BW: What to advise the writer of the document (dacosta)? JS: Advise to use SMIng. It solves some of the problems already (operations) and can solve the rest (by using extensions). BW: Annotations could also be used to add semantic annotations to objects. Counter value x means this, value between y and z means that, and you should take this action, and so on. Action Item: BW will send dacosta a response, mentioning the possible future of SMIng and how it addresses the issues in his draft. -- coffee break -- Agenda Item #2: SMIng AP: Could you also define SMIng in XML? JS: No, because XML uses tags, and SMIng uses keywords. ;-) JS: You can define a DTD to define the same information. You can write a backend that generates XML. However, the real purpose of such an XML representation is IMHO to use it as an exchange format because it will not be easily human readable. JS: Don't mix up representing actual instances of information in XML and describing the structure of information in XML. AP: XML is fashionable, so it might be a selling point for SMIng. XML format could be good for making modules accessible easily, because there are lots of tools (like parsers, embedded in different packages) for XML, and you don't depend on libsmi being available everywhere. Issues: Is it useful to have compound types? And are they useful even without operations that work on compound types. Do you require a mapping to SMIv2? Issue: Discriminated union types (for sparse tables) are also needed. Issue: Compound data types. Put them in right away? Consensus: Put them in at the first go, then make the mapping to a protocol that doesn't know about them an issue, or assume that the underlying protocol can ship them and make that the issue. How to get the SMIng accepted in IETF? You need tools. Tools are there, libsmi. Libsmi is getting popular. SMIng parser is currently not as fully tested as the SMIv1/SMIv2 one. Issue: Motivation for using agent caps as an example for the extension mechanism. It is useful to put in some motivating text in the document for this. The SMIng document is a large document. If you compare it to its SMIv2 counterparts including the ASN.1 definition, this is to be expected of course. Proposed additions to the document: o A section in the introduction on how to read the document, something like "If you are reader type X , you can skip these parts..." o A section that lists the differences between SMIv2 and SMIng. Some issues with SMIng: - Display hints for unsigneds (cannot be mapped back and forth to SMIv2, since SMIv2 does not support them). - Compliance groups for notifications and objects: SMIv2 has separate constructs for these, whereas SMIng does not. This gives problems if a SMIng document puts notifications and objects into the same compliance group. - IpAddress type is now deprecated, as are some other types of v2. SMIng relaxed some restrictions, e.g. putting index objects in groups. Pretty soon in the IETF, the long-term solution for 64 integer data types will be addressed and a WG started. At that point the SMIng work should be submitted to the IETF. How this will be accepted in the SNMP community in the IETF is an open question; there might be some problems there. -- coffee break -- Agenda item: Operation types in SMIng Issues: o creates and deletes clauses (constructors and destructors) o where can operations be defined (bound to single table, multiple tables or not to tables at all) o returning of results (single result, vector of results) o returning of errors (restricted to enumerations currently) o sequences of operations to get a device in a defined state. Get the state from a device, something to send it back to get back into the current state. o What are the invocation semantics of operations? At most once, exactly once, at least once. o synchronous or asynchronous operations Transport and operations: Do we need to support the invocation of operations over UDP? Lets seriously consider not supporting operations over UDP. UDP gives some problems in case of operations, including arbitrary sized responses. Second day of the meeting (March 17, 2000) ========================================== Bert Wijnen is not present today at the meeting. Announcement: JS wrote an experimental XML back-end to libsmi yesterday after dinner and beer. More work is needed to formally define this. issue: constructors and destructors. Do we need to provide special language constructs to support them? In SMIv2, the RowStatus is usually bound to a single table entry. Do operations need to be bound to data structures? Examples: traceroute, reboot system, remote ping. JS: Scalars in SMI should not have been invented; a set of scalars with a common root is a degenerated case of a table. Having scalars as a special language construct just makes the world more complex. COPS gives every 'table' its own create and destroy 'method'. Discussion on where to bind operations to. OO binds operations always to classes; in a one on one manner. Side-effects are still allowed. UML develops into the 'lingua franca' of modeling (JS) and UML has no notion of operations without objects; every operation is bound to an object class. Options for binding are - operations not bound to anything - bound to exactly one table (or group of scalars) - bound to one or more tables There is no complete consensus on where (if anywhere) to bind operations to: AP supports unbound operations, JS and others support operations bound to a single table (or group of scalars). -- coffee break (Bert-Jan leaves the meeting) -- Example of an operation: Testing an interface. operation ifTest { oid ifMIBOperations.2; arguments (ifIndex InterfaceIndex, testType Enumeration (test1(1), test2(2)); errors (ifIndexInvalid(1), ifIndexInUse(2)); results (result Enumeration (success(1), failed(2), aborted(3)); description "....."; }; The usual OID registration tree structure of a MIB specification is below, extended with a branch to locate Operations in. | +- xxxObjects | +- xxxNotification | +- xxxCompliance | +- xxxOperations Where to define operations? (a) First option to bind the operation to the ifTable: table ifTable { ... the operation definition ... }; (b) Second option is to add to the operation definition a reference that identifies the scope: operation ifTest { scope ifTable; ... the rest of the operation definition ... }; (c) Third option is to use SMIng annotations: annotation ifTableAnnotatation1 { oid .... scope ifTable; ... the operation definition ... }; Consensus: Put operations inside table definitions, and allow the annotation mechanism to add operations in separate documents to existing tables. Asynchronous example with a separate test table: table ifTestTable { ... normal table definitions ... operation runTest { oid ifMIBOperations.1; arguments (ifIndex InterfaceIndex, testType Enumeration (t1(1), t2(2)), errors ... description "... says that the result is shipped via a notification ..."; result(ifTestTableIndex Unsigned32); }; operation stopTest { ... the rest of the operation definition ... }; operation purgeTest { oid ifMIBOperations.3; arguments (ifTestIndex Unsigned32); error (invalidIndex(0)); description "..."; }; } Second example of an operation: Rebooting a system. option 1: annotation systemAnnot1 { oid snmpMIBOperations.1; scope system; operation reboot { ... }; }; option 2: operation reboot { oid snmpMIBOperations.1; arguments (when DateAndTime); errors (invalidDateAndTime(1)); ... } Reboot turns out to be a table after all. If you want to be able to schedule reboots in advance (reboot in 24 hours)), you probably also want to be able to cancel scheduled reboots. -- lunch break -- Multiple results should be supported. We need a way to indicate how many results may be returned (exactly one, 1 or more, 0 or more, ...). Enumerations are sufficient as error codes. We assume 'at most once' or better semantics for operation invocations. Strange reboot example: An operation invoker invokes the reboot operation on a device, and the device immediately reboots, before even confirming the proper reception of the operation invocation. We do not support the strange reboot example; operation invocations are confirmed. The invoker can tell that the invocation actually succeeded. Agenda point #3: SNMP architecture extensions for operations Two additional architectural function blocks: Operation Invoker (OI) and Operation Performer (OP). Access control is an issue; where to call isAccessAllowed ASI? AgentX consequences: If operations are in different subagents than the data they operate on, who calls isAccessAllowed? Agenda item on SNMP protocol operations not covered (lack of time). Action items: o JS and FS take up the action item to update SMIng spec: to add annotations as a core feature to SMIng instead of having it as an extension (as described in the DSOM '99 paper). o JS and FS: Add a rationale why agentcaps are not handled as a core feature of the language and may be better handled as an extension of the core SMIng language. o JS: Work on architecture extensions for SNMP; what goes into and what comes out of the Operation Performer (OP) and Operation Invoker (OI) blocks. Need to specify the relevant ASIs. o Implementation experience on operations would be really cool. AP: Twente will work on it; in particular SB and Bert Helthuis. o Item: Small example MIB with operations. Use this to get implementation experience. o Item: Real MIB with operations. Potential candidate: Diffserv Policy PIB, turn it into SMIng MIB with operations. o Work item: Extend SMIng parser to understand operations, extend libsmi data structures, possibly generate code stubs from that. -- meeting closed -- Ron. -------------------------------------------------------------------------- Ron Sprenkels sprenkel@cs.utwente.nl http://www.cs.utwente.nl/~sprenkel University of Twente, Department of Computer Science, TSS Management group P.O. Box 217, 7500 AE Enschede, The Netherlands. (Tel. +31 53 489 4663) Return-Path: Received: by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) id LAA13542 for nmrg-outgoing; Wed, 22 Mar 2000 11:47:07 +0100 (MET) Received: from icasun1.epfl.ch (root@icasun1.epfl.ch [128.178.151.148]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) with ESMTP id LAA13535 for ; Wed, 22 Mar 2000 11:47:04 +0100 (MET) Received: from ica.epfl.ch (jpmf@tcomhp33.epfl.ch [128.178.151.24]) by icasun1.epfl.ch (8.8.X/EPFL-8.1d for ICA) with ESMTP id LAA27065; Wed, 22 Mar 2000 11:46:49 +0100 (MET) Message-Id: <200003221046.LAA27065@icasun1.epfl.ch> X-Mailer: exmh version 2.1.1 10/15/1999 From: "J.P. Martin-Flatin" To: wweiss@lucent.com, David.Durham@intel.com, td@snia.org cc: Network Management Research Group , "J.P. Martin-Flatin" Reply-To: "J.P. Martin-Flatin" Subject: [nmrg] Comments on Mime-Version: 1.0 Content-Type: multipart/mixed ; boundary="==_Exmh_3667946560" Date: Wed, 22 Mar 2000 11:46:32 +0100 Sender: owner-nmrg@ibr.cs.tu-bs.de Precedence: bulk Status: RO This is a multipart MIME message. --==_Exmh_3667946560 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Copy: IRTF NMRG RG Walter, David, and Andrea, Please find enclosed some comments on (release of March 9, 2000). I fully agree with the point you make in the abstract. I think there are many good things in your I-D. Have you looked at ODMA and the work done by the OMG? I am not following these efforts closely, but I think they could be useful to you. You might also be interested in reading this article: A.I. Riviere and M. Sibilla. "Management Information Models Integration: From Existing Approaches to New Unifying Guidelines". Journal of Network and Systems Management, 6(3):333-356, 1998. JP ____________________________________________________________ J.P. Martin-Flatin, EPFL-DSC-ICA, 1015 Lausanne, Switzerland Email: jp.martin-flatin@ieee.org Fax: +41-21-693-66-10 Web: http://icawww.epfl.ch/~jpmf/ --==_Exmh_3667946560 Content-Type: text/plain ; name="nim.txt"; charset=iso-8859-1 Content-Description: nim.txt Content-Disposition: attachment; filename="nim.txt" Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable 1) Page 3, lines 2-4, you say that in Web-based management, "data structures are defined in the absence of standards". I disagree: The DMTF is working precisely on this. The CIM schemas that are expected to come out of the different working groups this year should be considered as "standards", if we call an IETF MIB a standard. I don't think the IETF should implicitly deny the work done by the DMTF. 2) I think you should define your terminology in the abstract. Page 3, you state: "What is required is a common representation of data (an "information model"). A few lines further, you say: "The purpose of an information model is to represent data in a manner that is independent of technology and implementation.". Stricto sensu, this is wrong because you show only part of the picture. Defining an information model encompasses three things: * First and foremost, the definition of the management data itself; e.g., SNMP MIBs and CIM schemas. * Second, the definition of a metamodel which governs the expressive- ness of your information model; e.g., SMIv2 with SNMP. * Third, the representation of data; e.g., with SNMP, MIB variables are organized as an inverted hierarchical tree; e.g., in MIB-II, the error rate for inbound traffic through interface #3 is represented as 1.3.6.1.2.1.2.2.1.14.3; e.g., Java objects with JMX. In the SNMP realm, the definition of an information model is primarily concerned with the definition of the entities in the MIB (which is difficult), and secondarily with the representation of these entities (which is often very easy). There seems to be some confusion about the meaning of the phrase "information model" within the IETF community. I already pointed out a similar confusion to Juergen Schoenwaelder, who is one of the driving forces in the SNMPv3 WG. In the SNMP world, the information model consists of all the MIBs, SMIv1, and SMIv2. In WBEM, it consists of all CIM schemas and MOF. 3) Page 3, you state: "The purpose of an information model *is* to represent data in a manner that is independent of technology and implementation". I would rephrase this sentence as follows: "We claim that the purpose of an information model should be to define and represent data in a manner that is independent of technology and implementation". Your verb "is" is wrong: Typically, information models are not technology-independent today. But I agree that it would be a good idea to change habits and make information models technology- independent. 4) Page 3, at the end of the abstract, you state: "that describe the conventions for the information model and the information model itself". I find it confusing. If I understand you correctly, I suggest you rephrase it as follows: "that describe the information model and its metamodel". 5) Page 4, you state: "This will in turn produce domain-specific data models that are all derived from a common network information model". Later, you say: "transforming the information model into specific data = models". I don't like your terminology here. For you, a data model is a particular instance of an information model: It is technology and implementation dependent. Usually, in computer science, "data model" is opposed to "object model". A typical criticism of information modeling in the SNMP world is that it aims at producing data models, whereas most people would rather use object models (this is addressed by the DMTF with CIM). I therefore suggest you use "generic information model" and "specific information model" instead. 6) Page 5, you should delete: "Finally, the DMTF does not have the subject matter experts in networking, as does the IETF". It is polemic, wrong, and useless. Some companies have moved their experts from the IETF to the DMTF because they thought that the IETF was deadlocked with SNMP. I would rather the IETF and DMTF work together than criticize each other. This is not a U.S. presidential election... :-) 7) Page 5, at the beginning of section 3.1, replace "complimentary" with "complementary" (twice). 8) Page 6, section 3.2, what are these "keys"? Those used for strong security? 9) Page 6, section 3.3, line 1, delete "such". 10) Page 6, section 3.3, you leave it to the working group to decide on the definition language for the textual representation of the information model. What about suggesting (but not imposing) to use XML? 11) Page 6, section 3.4, you use the NIM acronym but you forgot to define it before. 12) Page 7, bullet "constraints for classes", there is a typo after "Class B": A quote was replaced by an 8-bit character. 13) Page 8, a carriage return is missing between sections 3.9 and 3.10. 14) A general comment on section 3: Why don't you mandate that the information model be object-oriented? You render mandatory all the characteristics of an object model, but you don't exlicitly mandate object orientation. Why? 15) Page 9, section 3.12: I totally disagree. Subscription to subsets of data is desirable, but it has nothing to do with the definition of an information model. This section should be deleted. 16) Page 9, section 3.13: Means for testing compliance should be recommended, not mandated. 17) Page 10, section 3.15, same typo as described above after "Class XYZ". 18) Page 10, replace "Where IPADDRESSMASK" with "where IPADDRESSMASK". 19) Page 12, definition of CIM: Replace "Mangement" with "Management" and delete extra white space before "Common". 20) Page 13, reference for CIM: You should refer to a specific document instead of simply giving a URL pointing to the latest specification of CIM. CIM is regularly updated by the DMTF, and some of your statements may be wrong in 2-3 years. --==_Exmh_3667946560-- Return-Path: Received: by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) id SAA24903 for nmrg-outgoing; Mon, 13 Mar 2000 18:37:02 +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 SAA24895; Mon, 13 Mar 2000 18:37:01 +0100 (MET) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id SAA13454; Mon, 13 Mar 2000 18:37:01 +0100 Date: Mon, 13 Mar 2000 18:37:01 +0100 Message-Id: <200003131737.SAA13454@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: Network Management Research Group Subject: [nmrg] meeting preparation Sender: owner-nmrg@ibr.cs.tu-bs.de Precedence: bulk Status: RO Here are a few IDs that you should read in order to prepare yourself for the meeting at the end of this week: In the light of , we need to discuss what our research group's position on future information modeling and/or data modeling work is. So I would like to add that discussion to our agenda as the first item since the outcome may influence the other agenda items. /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