doc: Add RFC documents

1 files changed, 451 insertions, 0 deletions

diff --git a/doc/rfc/rfc3444.txt b/doc/rfc/rfc3444.txt
new file mode 100644
index 0000000..127d772
--- /dev/null
+++ b/doc/rfc/rfc3444.txt
@@ -0,0 +1,451 @@
+
+
+
+
+
+
+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.
+
+Abstract
+
+   There 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.
+
+Table of Contents
+
+   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
+
+
+
+
+Pras & Schoenwaelder         Informational                      [Page 1]
+
+RFC 3444           Information Models and Data Models       January 2003
+
+
+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, 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 [8]).  Compared to most other documents, this one
+   explains the rationale behind the proposed definitions and provides
+   examples.
+
+2. Overview
+
+   One of the key observations made at the NMRG workshop was that IMs
+   and DMs are different because they serve different purposes.
+
+   The main purpose of an IM is to model managed objects at a conceptual
+   level, independent of any specific implementations or protocols used
+   to transport the data.  The degree of specificity (or detail) of the
+   abstractions defined in the IM depends on the modeling needs of its
+   designers.  In order to make the overall design as clear as possible,
+   an IM should hide all protocol and implementation details.  Another
+   important characteristic of an IM is that it defines relationships
+   between managed objects.
+
+
+
+
+Pras & Schoenwaelder         Informational                      [Page 2]
+
+RFC 3444           Information Models and Data Models       January 2003
+
+
+   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.
+
+3. Information Models
+
+   IMs are primarily useful for designers to describe the managed
+   environment, for operators to understand the modeled objects, and for
+   implementors as a guide to the functionality that must be described
+   and coded in the DMs.  The terms "conceptual models" and "abstract
+   models", which are often used in the literature, relate to IMs.  IMs
+   can be implemented in different ways and mapped on different
+   protocols.  They are protocol neutral.
+
+   An important characteristic of IMs is that they can (and generally
+   should) specify relationships between objects.  Organizations may use
+   the contents of an IM to delimit the functionality that can be
+   included in a DM.
+
+   IMs can be defined in an informal way, using natural languages such
+   as English.  An example of such an IM is provided by RFC 3290 [9],
+   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 [4].  In general, most of
+
+
+
+Pras & Schoenwaelder         Informational                      [Page 3]
+
+RFC 3444           Information Models and Data Models       January 2003
+
+
+   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" [10].  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) [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, e.g. rules that explain how to map managed objects onto
+   lower-level protocol constructs.
+
+   Most of the management models standardized to date are DMs.  Examples
+   include:
+
+   o  Management Information Base (MIB) modules defined within the IETF.
+      The language (syntax) used to define these DMs is called the
+      "Structure of Management Information" (SMI) [1] and is derived
+      from ASN.1 [6].
+
+
+
+
+
+
+
+Pras & Schoenwaelder         Informational                      [Page 4]
+
+RFC 3444           Information Models and Data Models       January 2003
+
+
+   o  Policy Information Base (PIB) modules, developed within the IETF.
+      Their syntax is defined by the "Structure of Policy Provisioning
+      Information" (SPPI) [2], which is close to SMI and is also derived
+      from ASN.1 [6].
+
+   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) [7].  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) [3].  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
+
+
+
+Pras & Schoenwaelder         Informational                      [Page 5]
+
+RFC 3444           Information Models and Data Models       January 2003
+
+
+   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.
+
+5. Security Considerations
+
+   The meaning of the terms Information Model and Data Model has no
+   direct security impact on the Internet.
+
+6. Acknowledgments
+
+   The authors would like to thank everyone who participated in the 8th
+   NMRG workshop (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.
+
+7. Normative References
+
+   [1]  McCloghrie, K., Perkins, D. and J. Schoenwaelder, "Structure of
+        Management Information Version 2 (SMIv2)", STD 58, RFC 2578,
+        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", BCP
+        9, RFC 2026, October 1996.
+
+
+
+
+
+Pras & Schoenwaelder         Informational                      [Page 6]
+
+RFC 3444           Information Models and Data Models       January 2003
+
+
+   [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.
+
+8. 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.
+
+9. 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
+
+
+
+
+
+Pras & Schoenwaelder         Informational                      [Page 7]
+
+RFC 3444           Information Models and Data Models       January 2003
+
+
+10.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (2003).  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         Informational                      [Page 8]
+