Re: [nmrg] Draft version of Information - Data Model RFC

[Marcus Brunner <[e-mail]>]

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 <[e-mail]> 
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: [phone]
>     EMail: [e-mail]
>
>
>     Juergen Schoenwaelder
>     University of Osnabrueck
>     Albrechtstr. 28
>     49069 Osnabrueck
>     Germany
>
>     Phone: [phone]
>     EMail: [e-mail]
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> 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
> <[e-mail]> !! or look at
> https://www.ibr.cs.tu-bs.de/mailman/listinfo/nmrg.



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

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