wdiff draft-irtf-nmrg-im-dm-01.txt draft-irtf-nmrg-im-dm-02.txt

NMRG A. Pras
Internet-Draft University of Twente
Expires: March 4, 2003 J. Schoenwaelder
University of Osnabrueck
September 3, 2002A new Request for Comments is now available in online RFC libraries.

RFC 3444

Title: On the Difference between Information Models and
Data Models
draft-irtf-nmrg-im-dm-01.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 March 4, 2003.

Abstract
Author(s): A. Pras, J. Schoenwaelder
Status: Informational
Date: January 2003
Mailbox: pras@ctit.utwente.nl,
schoenw@informatik.uni-osnabrueck.de
Pages: 8
Characters: 18596
Updates/Obsoletes/SeeAlso: None

I-D Tag: draft-irtf-nmrg-im-dm-02.txt

URL: ftp://ftp.rfc-editor.org/in-notes/rfc3444.txt

There has been ongoing confusion about the differences between
Information Models and Data Models. 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 ITU
International Telecommunication Union (ITU) or the DMTF) 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 on
December 8-9 2000.

Table of Contents

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Information Models . . . . . . . . . . . . . . . . . . . . . . . 4
4. Data Models . . . . . . . . . . . . . . . . . . . . . . . . . . 5
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 7
Normative References . . . . . . . . . . . . . . . . . . . . . . 7
Informative References . . . . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 9

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
suits all needs. To discuss these feelings, the IETF organized Austin.

This memo provides information 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 Internet community. It does
not always fruitful, primarily because it appeared that people
had different understanding of main terms. In particular, the terms
"Information Model" (IM) and "Data Model" (DM) turned out to be
controversial.

In specify an attempt to stop this controversy and harmonize terminology, the
IRTF Network Management Research Group (NMRG) 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 Internet standard of the terms "Information Model" and "Data Model", is
presented in this document.

Short definitions any kind. Distribution of both terms can also be found within other
documents (see for example RFC 3198 [8]). Compared to these other
documents this document also provides background information and
examples.

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
memo is to model managed objects at a conceptual
level as abstractions, independent of specific implementations or
protocols used to transport the data. The degree of specificity (or
detail) of the IM unlimited.

This announcement is dependent on the modeling needs of its
designers. In order sent 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 IETF list and protocol specific constructs.

IM --> conceptual / abstract model
| targeted to the designer and
+----------+---------+ human manager
| | |
DM DM DM --> concrete / detailed model
targeted RFC-DIST list.
Requests 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 added to or deleted from the same IM.

Although IMs and DMs serve different purposes, it is not possible to
precisely define what details IETF distribution list
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 to describe the managed
environment, for managers sent to understand the modeled objects, and for
implementors as a guide IETF-REQUEST@IETF.ORG. Requests to the functionality that must be described
and coded in their DMs. The terms "conceptual models" or "abstract
models", which are often used in literature, relate
added 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. Organizations may use the contents of an information model
to delimit or deleted from the functionality that can be included in a data model.

IMs can RFC-DIST distribution list should
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" [9]. This RFC
describes a conceptual model of a Diffserv Router, including the
relationship between the components of such a router that need sent 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"
[4]. In general most RFCs that define a Management Information Base
(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" [10]. Note that most RFC-DIST-REQUEST@RFC-EDITOR.ORG.

Details on obtaining 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. 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 via FTP or EMAIL 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) [5].

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
[6].

Not only IETF MIB modules, but also most other standardized
management models are DMs. Examples are:

o Policy Information Base (PIB) modules, which are also developed
within the IETF. PIB modules 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 Base (MIB) modules, as originally defined obtained 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) [7]. GDMO MIB modules make
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 MIB modules. One could therefore argue that
CIM Schemas are closer to IMs then IETF MIB modules, 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 MIB modules, 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.

To illustrate what details are included in a DM, let us consider the
example of IETF MIB modules. As opposed sending
an EMAIL message to IMs, IETF MIB modules
include details like OID assignments and indexing structures. The
"relationships" that existed at rfc-info@RFC-EDITOR.ORG with 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 message body
help: ways_to_get_rfcs. For example:

To: rfc-info@RFC-EDITOR.ORG
Subject: getting rfcs

help: ways_to_get_rfcs

Requests 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 distribution should be addressed to stop either the proliferation
author of different DM languages
and harmonize the various models. As a result MIB/PIB modules
defined RFC 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 extension
mechanisms allowing the addition of new features (such as support for
methods). New features can then be used when supported by underlying
protocols, without breaking SMIng implementations. Still SMIng
should be considered as a DM; to express for example the relationship
between managed objects, techniques like UML question, or ER diagrams give
still better results since these diagrams are easier to understand.

It should be RFC-Manager@RFC-EDITOR.ORG. Unless
specifically 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 is 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. Security Considerations

This document discusses the terms Information Model and Data Model.
These terms themself do not have any security impact otherwise on the Internet.

6. Acknowledgments

The authors would like to thank everyone who participated at the 8th
IRTF-NMRG meeting (in alphabetic order): Szabolcs Boros, Marcus
Brunner, David Durham, Dave Harrington, Jean-Philippe Martin-Flatin,
George Pavlou, Robert Parhonyi, David Perkins, David Sidor, Andrea
Westerinen and Bert Wijnen.

Normative 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] Bradner, S., "The Internet Standards Process -- Revision 3", RFC
2026, October 1996.

[5] Object Management Group, "Unified Modeling Language (UML),
Version 1.4", formal/2001-09-67, September 2001.

[6] International Organization for Standardization, "Information
processing systems - Open Systems Interconnection -
Specification of Abstract Syntax Notation One (ASN.1)",
International Standard 8824, December 1987.

[7] International Telecommunication Union, "Information technology -
Open Systems Interconnection - Structure of Management
Information: Guidelines itself, all RFCs are for the Definition of Managed Objects",
Recommendation X.722, 1992.

Informative References

[8] Westerinen, A., Schnizlein, J., Strassner, J., Scherling, M.,
Quinn, B., Herzog, S., Huynh, A., Carlson, M., Perry, J. and S.
Waldbusser, "Terminology
unlimited distribution.echo
Submissions for Policy-Based Management", RFC
3198, November 2001.

[9] Bernet, Y., Blake, S., Grossman, D. and A. Smith, "An Informal
Management Model Requests for Diffserv Routers", RFC 3290, May 2002.

[10] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB",
RFC 2863, June 2000.

Authors' Addresses

Aiko Pras
University of Twente
PO Box 217
7500 AE Enschede
The Netherlands

Phone: +31 53 4893778
EMail: pras@ctit.utwente.nl

Juergen Schoenwaelder
University of Osnabrueck
Albrechtstr. 28
49069 Osnabrueck
Germany

Phone: +49 541 969-2483
EMail: schoenw@informatik.uni-osnabrueck.de

Full Copyright Statement

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 Comments should be modified in any way, such as by removing
the copyright notice or references sent 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
RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions 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.
Authors, for further information.