Subject: Re: [nmrg] Next meeting on web services
From: "David T. Perkins" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Wed, 31 Jul 2002 09:09:05 -0700
List-Id: Network Management Research Group <nmrg.ibr.cs.tu-bs.de>

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 ([email-masked])
>  Archive URL: http://ops.ietf.org/lists/xmlconf/
>  To subscribe, send mail to [email-masked] 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

From: Randy Bush <[email-masked]>
To: Aiko Pras <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, Juergen Schoenwaelder <[email-masked]>
Subject: Re: [nmrg] Next meeting on web services
Date: Wed, 31 Jul 2002 07:42:16 -0700
Sender: [email-masked]

> 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

Date: Wed, 31 Jul 2002 16:38:25 +0200
From: Aiko Pras <[email-masked]>
To: Randy Bush <[email-masked]>
CC: "[email-masked]" <[email-masked]>, Juergen Schoenwaelder <[email-masked]>
Subject: Re: [nmrg] Next meeting on web services
Sender: [email-masked]

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
> 
> 

From: Randy Bush <[email-masked]>
To: Aiko Pras <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, Juergen Schoenwaelder <[email-masked]>
Subject: Re: [nmrg] Next meeting on web services
Date: Wed, 31 Jul 2002 06:55:33 -0700
Sender: [email-masked]

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

Date: Wed, 31 Jul 2002 15:32:20 +0200
From: Aiko Pras <[email-masked]>
To: "[email-masked]" <[email-masked]>
CC: Aiko Pras <[email-masked]>, Juergen Schoenwaelder <[email-masked]>
Subject: [nmrg] Next meeting on web services
Sender: [email-masked]

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 ([email-masked])
   Archive URL: http://ops.ietf.org/lists/xmlconf/
   To subscribe, send mail to [email-masked] 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

Date: Fri, 26 Jul 2002 17:24:14 +0200
From: Juergen Schoenwaelder <[email-masked]>
To: Network Management Research Group <[email-masked]>
Subject: [nmrg] last call on draft-irtf-nmrg-im-dm-00.txt
Sender: [email-masked]

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    <http://www.informatik.uni-osnabrueck.de/schoenw/>

Date: Thu, 25 Jul 2002 10:22:56 +0200
From: Juergen Schoenwaelder <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: Re: [nmrg] Model mismatch
Sender: [email-masked]

>>>>> 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    <http://www.informatik.uni-osnabrueck.de/schoenw/>

Date: Wed, 24 Jul 2002 10:56:18 -0700
To: [email-masked]
From: "David T. Perkins" <[email-masked]>
Subject: [nmrg] Model mismatch
Sender: [email-masked]

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

Date: Wed, 24 Jul 2002 19:09:43 +0200
From: Juergen Schoenwaelder <[email-masked]>
To: [email-masked]
CC: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: [nmrg] Draft version of Information - Data Model RFC
Sender: [email-masked]

>>>>> 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    <http://www.informatik.uni-osnabrueck.de/schoenw/>

Date: Wed, 24 Jul 2002 13:13:05 -0400
From: "Dave Sidor" <[email-masked]>
Organization: Nortel Networks
To: Aiko Pras <[email-masked]>
CC: Juergen Schoenwaelder <[email-masked]>, Aiko Pras <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: [nmrg] Draft version of Information - Data Model RFC
Sender: [email-masked]

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.

Date: Tue, 23 Jul 2002 18:08:08 +0200
From: Juergen Schoenwaelder <[email-masked]>
To: [email-masked]
CC: Network Management Research Group <[email-masked]>
Subject: [nmrg] please post draft-irtf-nmrg-im-dm-00.txt
Sender: [email-masked]

Please post the following document as Internet Draft:

<http://www.ibr.cs.tu-bs.de/~schoenw/draft-irtf-nmrg-im-dm-00.txt>

Thanks,

/js

-- 
Juergen Schoenwaelder    <http://www.informatik.uni-osnabrueck.de/schoenw/>

Date: Tue, 23 Jul 2002 17:47:13 +0200
From: Juergen Schoenwaelder <[email-masked]>
To: [email-masked]
CC: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: [nmrg] Draft version of Information - Data Model RFC
Sender: [email-masked]

>>>>> 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    <http://www.informatik.uni-osnabrueck.de/schoenw/>

Date: Tue, 23 Jul 2002 16:16:46 +0200
From: Aiko Pras <[email-masked]>
To: Juergen Schoenwaelder <[email-masked]>, [email-masked]
CC: Aiko Pras <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: [nmrg] Draft version of Information - Data Model RFC
Sender: [email-masked]

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.

Date: Mon, 22 Jul 2002 19:17:24 +0200
From: Juergen Schoenwaelder <[email-masked]>
To: [email-masked]
CC: Network Management Research Group <[email-masked]>
Subject: [nmrg] Re: SNMP Payload Compression
Sender: [email-masked]

>>>>> 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    <http://www.informatik.uni-osnabrueck.de/schoenw/>

Date: Wed, 17 Jul 2002 15:47:30 +0200
From: Juergen Schoenwaelder <[email-masked]>
To: [email-masked]
CC: Network Management Research Group <[email-masked]>
Subject: Re: [nmrg] next nmrg meeting
Sender: [email-masked]

>>>>> 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 <http://www.flughafen-fmo.de/> 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 <http://www.flughafen-frankfurt.de/> and
    <http://www.schiphol.nl/> for details on the airports. You can get
    German train schedules from <http://www.bahn.de/>.

/js

-- 
Juergen Schoenwaelder    <http://www.informatik.uni-osnabrueck.de/schoenw/>

Date: Wed, 17 Jul 2002 21:50:23 +0900
From: Marcus Brunner <[email-masked]>
To: Juergen Schoenwaelder <[email-masked]>
CC: Network Management Research Group <[email-masked]>
Subject: Re: [nmrg] next nmrg meeting
Sender: [email-masked]

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
>

Date: Tue, 16 Jul 2002 23:39:11 +0200
From: Juergen Schoenwaelder <[email-masked]>
To: Network Management Research Group <[email-masked]>
Subject: [nmrg] next nmrg meeting
Sender: [email-masked]

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    <http://www.informatik.uni-osnabrueck.de/schoenw/>

Date: Thu, 11 Jul 2002 12:00:39 +0200
From: Juergen Schoenwaelder <[email-masked]>
To: [email-masked], Aiko Pras <[email-masked]>
CC: [email-masked], [email-masked], [email-masked]
Subject: Re: [nmrg] Draft version of Information - Data Model RFC
Sender: [email-masked]

>>>>> 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    <http://www.informatik.uni-osnabrueck.de/schoenw/>

Date: Tue, 02 Jul 2002 16:52:46 -0400
From: "Dave Sidor" <[email-masked]>
Organization: Nortel Networks
To: Aiko Pras <[email-masked]>
CC: "[email-masked]" <[email-masked]>, Juergen Schoenwaelder <[email-masked]>, szabolcs boros <[email-masked]>, Robert Parhonyi <[email-masked]>
Subject: Re: [nmrg] Draft version of Information - Data Model RFC
Sender: [email-masked]

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

Date: Tue, 02 Jul 2002 12:28:44 +0200
From: Marcus Brunner <[email-masked]>
Reply-To: [email-masked]
To: Aiko Pras <[email-masked]>, "[email-masked]" <[email-masked]>
Cc: Juergen Schoenwaelder <[email-masked]>, szabolcs boros <[email-masked]>, Robert Parhonyi <[email-masked]>
Subject: Re: [nmrg] Draft version of Information - Data Model RFC
Sender: [email-masked]

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 <[email-masked]> 
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]   <http://www.irtf.org/>
>
>     [10]  <http://www.omg.org/>
>
>
>
>
>
>
>
>
>
>
>
>
> 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: [email-masked]
>
>
>     Juergen Schoenwaelder
>     University of Osnabrueck
>     Albrechtstr. 28
>     49069 Osnabrueck
>     Germany
>
>     Phone: +49 541 969-2483
>     EMail: [email-masked]
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> 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
> <[email-masked]> !! or look at
> https://www.ibr.cs.tu-bs.de/mailman/listinfo/nmrg.

--------------------------------------
Dr. Marcus Brunner
Network Laboratories
NEC Europe Ltd.

E-Mail: [email-masked]
WWW:    http://www.ccrle.nec.de/
personal home page: http://www.brubers.org/marcus