Network Working Group A. Pras Request for Comments: 3444 University of Twente Category: Informational J. Schoenwaelder University of Osnabrueck January 2003 On the Difference between Information Models and Data Models Status of this Memo This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved.
AbstractThere has been ongoing confusion about the differences between Information Models and Data Models for defining managed objects in network management. 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 International Telecommunication Union (ITU) or the Distributed Management Task Force (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) hosted by the University of Texas at Austin. 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 3. Information Models . . . . . . . . . . . . . . . . . . . . . . 3 4. Data Models . . . . . . . . . . . . . . . . . . . . . . . . . 4 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6 7. Normative References . . . . . . . . . . . . . . . . . . . . . 6 8. Informative References . . . . . . . . . . . . . . . . . . . . 7 9. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 7 10. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 8
1], the Structure of Policy Provisioning Information (SPPI)  and, within the DMTF, the Managed Object Format (MOF) . Despite the fact that multiple languages exist, a number of people still believe that none of these languages really suits all needs. There have been many discussions to understand the advantages and disadvantages, as well as the main differences, between various languages. For instance, the IETF organized a BoF on "Network Information Modeling" (NIM) at its 48th meeting (Pittsburgh, August 2000). During these discussions, it turned out that people had a different understanding of the main terms, which caused confusion and long arguments. In particular, the meaning of the terms "Information Model" (IM) and "Data Model" (DM) turned out to be controversial. In an attempt to address this issue, the IRTF Network Management Research Group (NMRG) dedicated its 8th workshop (Austin, December 2000) to harmonizing the terminology used in information and data modeling. Attendees included experts from the IETF, DMTF and ITU, as well as academics who do research in this field (see the Acknowledgments section for a list of participants). The main outcome of this successful workshop -- a better understanding of the terms "Information Model" and "Data Model" -- is presented in this document. Short definitions of these terms can also be found elsewhere (e.g., in RFC 3198 ). Compared to most other documents, this one explains the rationale behind the proposed definitions and provides examples.
DMs, conversely, are defined at a lower level of abstraction and include many details. They are intended for implementors and include protocol-specific constructs. IM --> conceptual/abstract model | for designers and operators +----------+---------+ | | | DM DM DM --> concrete/detailed model for implementors The relationship between an IM and DM is shown in the Figure above. Since conceptual models can be implemented in different ways, multiple DMs can be derived from a single IM. Although IMs and DMs serve different purposes, it is not always possible to precisely define what kind of details should be expressed in an IM and which ones belong in a DM. There is a gray area where IMs and DMs overlap -- just like there are gray areas between the models produced during the analysis, high-level design and low-level design phases in object-oriented software engineering. In some cases, it is very difficult to determine whether an abstraction belongs to an IM or a DM. RFC 3290 , which describes a conceptual model of a Diffserv Router and specifies the relationships between the components of such a router that need to be managed. Within the IETF, however, it is exceptional that an IM be explicitly described, and even more that the IM and DM be specified in separate RFCs. In such cases, the document specifying the IM is usually an Informational RFC whereas the document defining the DM usually follows the Standards Track . In general, most of
the RFCs that define an SNMP Management Information Base (MIB) module also include some kind of informal description explaining parts of the model behind that MIB module. Such a model can be considered as a document of an IM. An example of this is RFC 2863, which defines "The Interfaces Group MIB" . But most MIB modules published to date include only a rudimentary and incomplete description of the underlying IM. Alternatively, IMs can be defined using a formal language or a semi- formal structured language. One of the possibilities to formally specify IMs is to use class diagrams of the Unified Modeling Language (UML). Although such diagrams are still rarely used within the IETF, several other organizations routinely use them for defining IMs, including the DMTF, the ITU-T SG 4, 3GPP SA5, the TeleManagement Forum, and the ATM Forum. An important advantage of UML class diagrams is that they represent objects and the relationships between them in a standard 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 relationships (e.g., Entity-Relationship (ER) diagrams), UML presents the advantage of being widely adopted in the industry and taught in universities. Also, many tools for editing UML diagrams are now available. UML is standardized by the Object Management Group (OMG) . 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. 1] and is derived from ASN.1 .
o Policy Information Base (PIB) modules, developed within the IETF. Their syntax is defined by the "Structure of Policy Provisioning Information" (SPPI) , which is close to SMI and is also derived from ASN.1 . o Management Information Base (MIB) modules, originally defined by the ISO and currently maintained and enhanced by the ITU-T. The syntax of these DMs is specified in the "Guidelines for the Definition of Managed Objects" (GDMO) . GDMO MIB modules make use of object-oriented principles. o CIM Schemas, developed within the DMTF. The DMTF publishes them in two forms: graphical and textual. The graphical forms use UML diagrams and are not normative (because not all details can be represented graphically). They can be downloaded from the DMTF Web site in PDF and Visio formats. (Visio is a tool to draw UML class diagrams.) The textual forms are normative and written in a language called the "Managed Object Format" (MOF) . CIM Schemas are object-oriented. Because CIM Schemas support a graphical notation whereas IETF MIB modules do not, designers and operators may find it easier to understand CIM Schemas than IETF MIB modules. One could therefore argue that CIM Schemas are closer to IMs than IETF MIB modules. The Figure below summarizes these examples. The languages that are used to define the DMs are shown between brackets. IM --> IM | +----------+-------+-------+--------------+ | | | | MIB PIB CIM schema OSI-MIB --> 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 such as OID assignments and indexing structures. The relationships defined in the IM are implemented as OID pointers or realized through indexing relationships specified in INDEX clauses. Many other implementation-specific details are included, such as MAX- ACCESS and STATUS clauses and conformance statements. A special kind of DM language is the SMIng language defined by the NMRG. This language was designed at a higher conceptual level than SMIv1/SMIv2 and SPPI. In fact, one of the intentions behind SMIng was to stop the proliferation of different DM languages within the IETF and to harmonize the various models. As a result, MIB and PIB
modules defined in SMIng can be mapped on different underlying protocols. There is a mapping on SNMP and another mapping on COPS- PR. SMIng is therefore more protocol neutral than other IETF approaches. It also supports some object-oriented principles and provides extension mechanisms that allow the addition of new features (e.g., the support for methods). New features can then be used when they are supported by the underlying protocols, without breaking SMIng implementations. Still, SMIng should be considered a DM. For instance, to express relationships between managed objects, techniques such as UML and ER diagrams still give better results because these diagrams are easier to understand. Note that the IETF SMING Working Group took a different approach and decided not to use the SMIng language defined by the NMRG. Instead, the SMING Working Group is developing a third version of SMI (SMIv3) that is primarily targeted towards SNMP, and which incorporates only some of the ideas developed within the NMRG.  McCloghrie, K., Perkins, D. and J. Schoenwaelder, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999.  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.  Distributed Management Task Force, "Common Information Model (CIM) Specification Version 2.2", DSP 0004, June 1999.  Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
 Object Management Group, "Unified Modeling Language (UML), Version 1.4", formal/2001-09-67, September 2001.  International Organization for Standardization, "Information processing systems - Open Systems Interconnection - Specification of Abstract Syntax Notation One (ASN.1)", International Standard 8824, December 1987.  International Telecommunication Union, "Information technology - Open Systems Interconnection - Structure of Management Information: Guidelines for the Definition of Managed Objects", Recommendation X.722, 1992.  Westerinen, A., Schnizlein, J., Strassner, J., Scherling, M., Quinn, B., Herzog, S., Huynh, A., Carlson, M., Perry, J. and S. Waldbusser, "Terminology for Policy-Based Management", RFC 3198, November 2001.  Bernet, Y., Blake, S., Grossman, D. and A. Smith, "An Informal Management Model for Diffserv Routers", RFC 3290, May 2002.  McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", RFC 2863, June 2000.
Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society.