< draft-irtf-nmrg-im-dm-01.txt		draft-irtf-nmrg-im-dm-02.txt >
			A new Request for Comments is now available in online RFC libraries.
	NMRG A. Pras		RFC 3444
	Internet-Draft University of Twente
	Expires: March 4, 2003 J. Schoenwaelder
	University of Osnabrueck
	September 3, 2002
	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.
	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) 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 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 particular, 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) 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.
	Short definitions 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 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 is dependent on the modeling needs of its
	designers. 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.
	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 to describe the managed
	environment, for managers to understand the modeled objects, and for
	implementors as a guide 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 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 the functionality that can be included in a data model.
	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" [9]. 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"
	[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 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 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
	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.
	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 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 MIB/PIB modules
	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 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 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 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 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 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 for Policy-Based Management", RFC
	3198, November 2001.
	[9] Bernet, Y., Blake, S., Grossman, D. and A. Smith, "An Informal
	Management Model 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		Title: On the Difference between Information Models and
	University of Twente		Data Models
	PO Box 217		Author(s): A. Pras, J. Schoenwaelder
	7500 AE Enschede		Status: Informational
	The Netherlands		Date: January 2003
			Mailbox: pras@ctit.utwente.nl,
			schoenw@informatik.uni-osnabrueck.de
			Pages: 8
			Characters: 18596
			Updates/Obsoletes/SeeAlso: None
	Phone: +31 53 4893778		I-D Tag: draft-irtf-nmrg-im-dm-02.txt
	EMail: pras@ctit.utwente.nl
	Juergen Schoenwaelder		URL: ftp://ftp.rfc-editor.org/in-notes/rfc3444.txt
	University of Osnabrueck
	Albrechtstr. 28
	49069 Osnabrueck
	Germany
	Phone: +49 541 969-2483		There has been ongoing confusion about the differences between
	EMail: schoenw@informatik.uni-osnabrueck.de		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.
	Full Copyright Statement		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.
	Copyright (C) The Internet Society (2002). All Rights Reserved.		This memo provides information for the Internet community. It does
			not specify an Internet standard of any kind. Distribution of this
			memo is unlimited.
	This document and translations of it may be copied and furnished to		This announcement is sent to the IETF list and the RFC-DIST list.
	others, and derivative works that comment on or otherwise explain it		Requests to be added to or deleted from the IETF distribution list
	or assist in its implementation may be prepared, copied, published		should be sent to IETF-REQUEST@IETF.ORG. Requests to be
	and distributed, in whole or in part, without restriction of any		added to or deleted from the RFC-DIST distribution list should
	kind, provided that the above copyright notice and this paragraph are		be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG.
	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		Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
	revoked by the Internet Society or its successors or assigns.		an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body
			help: ways_to_get_rfcs. For example:
	This document and the information contained herein is provided on an		To: rfc-info@RFC-EDITOR.ORG
	"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING		Subject: getting rfcs
	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		help: ways_to_get_rfcs
	Funding for the RFC Editor function is currently provided by the		Requests for special distribution should be addressed to either the
	Internet Society.		author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless
			specifically noted otherwise on the RFC itself, all RFCs are for
			unlimited distribution.echo
			Submissions for Requests for Comments should be sent to
			RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC
			Authors, for further information.
End of changes. 13 change blocks.
	356 lines changed or deleted		39 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/