Internet DRAFT - draft-xiao-evaluate-dml

draft-xiao-evaluate-dml





Network Working Group                                              H. Xu
Internet-Draft                                                  DB. Xiao
Intended status: Experimental                                   CCNU INC
Expires: October 30, 2010                                 April 28, 2010


     An Evaluation Framework for Data Modeling Languages in Network
                           Management Domain
                       draft-xiao-evaluate-dml-06

Abstract

   With rapid development of next generation networks, it is expected
   that a separate effort to study data modeling languages in the
   interest of network management should be undertaken.  Based on a good
   understanding of the requirements of data modeling in next generation
   network management domain, evaluation on management data modeling
   languages becomes an essential way for the purpose of standardization
   to replace proprietary data models in the near future.  Our project
   aims to establish a framework for evaluation to measure the
   capabilities of management data modeling languages in meeting those
   requirements by a set of criteria, which are modeling approaches,
   interoperability, conformance, extensibility, readability, data
   representations and security considerations.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   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."

   This Internet-Draft will expire on October 30, 2010.

Copyright Notice

   Copyright (c) 2010 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal



Xu & Xiao               Expires October 30, 2010                [Page 1]

Internet-Draft    Evaluation on Data Modeling Languages       April 2010


   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Proposed Evaluation Framework  . . . . . . . . . . . . . . . .  4
     2.1.  Modeling Approaches  . . . . . . . . . . . . . . . . . . .  4
     2.2.  Interoperability . . . . . . . . . . . . . . . . . . . . .  4
       2.2.1.  Protocol Independence  . . . . . . . . . . . . . . . .  5
       2.2.2.  Naming Independence  . . . . . . . . . . . . . . . . .  5
     2.3.  Conformance  . . . . . . . . . . . . . . . . . . . . . . .  5
       2.3.1.  Backward Compatibility . . . . . . . . . . . . . . . .  5
       2.3.2.  Versioning . . . . . . . . . . . . . . . . . . . . . .  5
       2.3.3.  Definition of Event Notification Messages  . . . . . .  6
       2.3.4.  Definition of Error Messages . . . . . . . . . . . . .  6
     2.4.  Extensibility  . . . . . . . . . . . . . . . . . . . . . .  6
       2.4.1.  Extensibility of Data Structures . . . . . . . . . . .  6
       2.4.2.  Extensibility of Data Types  . . . . . . . . . . . . .  6
       2.4.3.  Extensibility of Elements and Attributes . . . . . . .  7
     2.5.  Readability  . . . . . . . . . . . . . . . . . . . . . . .  7
       2.5.1.  Human Readability  . . . . . . . . . . . . . . . . . .  7
       2.5.2.  Machine Readability  . . . . . . . . . . . . . . . . .  7
     2.6.  Data Representations . . . . . . . . . . . . . . . . . . .  8
       2.6.1.  Support of Hierarchical Data . . . . . . . . . . . . .  8
       2.6.2.  Specification of Configuration Data, State Data
               and Statistics Data  . . . . . . . . . . . . . . . . .  8
     2.7.  Security Considerations  . . . . . . . . . . . . . . . . .  8
       2.7.1.  Granularity of Access Control  . . . . . . . . . . . .  9
       2.7.2.  Lock Mechanism . . . . . . . . . . . . . . . . . . . .  9
   3.  Validation . . . . . . . . . . . . . . . . . . . . . . . . . . 10
   4.  Application of Proposed Framework to NETCONF-based Data
       Modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
   5.  Conclusions  . . . . . . . . . . . . . . . . . . . . . . . . . 19
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 20
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 21
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 22
     8.2.  Informative References . . . . . . . . . . . . . . . . . . 23
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24




Xu & Xiao               Expires October 30, 2010                [Page 2]

Internet-Draft    Evaluation on Data Modeling Languages       April 2010


1.  Introduction

   The definition of Information Model (IM) and Data Model (DM) should
   be seriously considered for network management solutions.  IMs always
   model Managed Objects (MOs) at a conceptual level and are protocol-
   neutral, while DMs are defined at a concrete level, implementing in
   different ways and are protocol-specific.  As for each network
   management model, a data modeling language is quite necessary for the
   description of the managed resources.

   Obviously, the work on evaluating data modeling languages for the
   sake of next generation network management is comparatively
   indispensable.  However, the fact is that a reused evaluation
   framework for management data modeling languages is still greatly
   lacking.  The aim of our project is then to establish an evaluation
   framework to measure the capabilities of management data modeling
   languages in adapting to the requirements of ever-evolving network
   management and apply it to examine existing languages for validation.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].





























Xu & Xiao               Expires October 30, 2010                [Page 3]

Internet-Draft    Evaluation on Data Modeling Languages       April 2010


2.  Proposed Evaluation Framework

   Nowadays data modeling is under hot research, but it is still a
   preparatory period for corresponding research on network management.
   It becomes necessary to put forward a universal evaluation framework
   for data modeling languages to level their capabilities in satisfying
   the requirements of future network management.  Proposed evaluation
   framework is based on a set of criteria, and through criteria
   aggregation, these criteria are adjusted into protocol-independent
   ones that are modeling approaches, interoperability, conformance and
   extensibility, and protocol-specific ones that are readability, data
   representation and security considerations.

2.1.  Modeling Approaches

   Four main modeling approaches should be considered, including data-
   oriented one, command-oriented one, object-oriented/object-based one
   and document-oriented one.  The data-oriented approach models all
   management aspects through data objects, and at least two operations
   ("get" and "set") should be defined.  The command-oriented approach
   defines a large number of management operations, specifying not the
   details but the commands to get/set selected information.  The
   object-oriented/object-based approach combines the data-oriented
   approach and the command-oriented approach in view of integration.
   The document-oriented approach represents state information,
   statistics information and configuration information of a device as a
   structured document.

   Future management data modeling language should implement an
   integration of various modeling approaches, a possible scenario of
   which is a data-oriented view for monitoring, a command-oriented view
   for operations and a document-oriented view for configuration.  Note
   that, the very language should avoid implementing the same function
   with simple combination of these approaches.

2.2.  Interoperability

   With the development of next generation networks, management in an
   environment with a heterogeneous set of devices becomes a trend.
   Hence, standardization of DMs for network management should work at a
   higher level, making them more close to IMs.  Following this way,
   data modeling languages should accordingly provide interoperability,
   which is consistent with the understanding of MOs already learned by
   network operators.







Xu & Xiao               Expires October 30, 2010                [Page 4]

Internet-Draft    Evaluation on Data Modeling Languages       April 2010


2.2.1.  Protocol Independence

   Protocol independence means that the language defines management data
   supporting any protocol instead of belonging to some specific
   protocol.  In other words, the DM defined by this language can be
   implemented on any platform that installs different protocols.

   In order to integrate with existing network management technologies,
   DMs should be defined by protocol-neutral modeling languages that can
   be mapped on different underlying protocols.

2.2.2.  Naming Independence

   Naming independence is a desired mechanism provided by the language
   that specifies how name collisions are handled, and thus uniquely
   identifies attributes, groups of attributes, and events.

   Since a data modeling language for network management is required to
   be protocol-independent, and protocols typically use different
   approaches to name instances, it has to support multiple instance
   naming systems.  Being naming independence, the language needs to
   think about the relationships between DMs.  More efforts should then
   be made to ensure implementation of the language not being interfered
   by problems of different objects from multiple modules with the same
   name.

2.3.  Conformance

   When defining MOs, it is also quite necessary to describe machine-
   readable conformance for the DM.

2.3.1.  Backward Compatibility

   Backward compatibility illuminates that new versions of the data
   modeling language can be used to define the relevant DM for the
   purpose of network management as the older one used to do.

   This capability is quite important, for the reason that it eliminates
   the need to start over when a new data modeling language is used.
   From the viewpoint of network management, it means that new versions
   of the data modeling language that define management content can be
   rolled out in a way that does not break existing supporters.

2.3.2.  Versioning

   Versioning explains that each version of the data modeling language
   is complete, thus easy to control.  This capability promotes the
   maintenance of backwards compatibility and does not need to change to



Xu & Xiao               Expires October 30, 2010                [Page 5]

Internet-Draft    Evaluation on Data Modeling Languages       April 2010


   the new language if it is also backwards compatible.

2.3.3.  Definition of Event Notification Messages

   Definition of event notification messages needs to be ensured by the
   data modeling language to allow a single definition of notification
   content to be sent either asynchronously or synchronously.

   Network management protocols are desired to support asynchronous
   notifications, and with regard to a future data modeling language,
   not only notification messages but also types of the events should be
   clearly identified.

2.3.4.  Definition of Error Messages

   Definition of error messages indicates that error messages generated
   by network management applications should be recognized by the data
   modeling language.

   Error messages, which are created by applications as a result of
   performing network management operations against the related DM, need
   to be included in the modeling language.

2.4.  Extensibility

   With increase of isomerization and complexity of the Internet, there
   is a great need for data modeling languages to have the ability to
   extend data structures, data types, elements and attributes easily
   for the practice of developing related software or systems to manage
   future heterogeneous networks.

2.4.1.  Extensibility of Data Structures

   Extensibility of data structures shows that the data modeling
   language has the capability to add new data structures with no need
   to affect available ones, and thus expresses the relations among data
   effectively and operates on data effortlessly.

2.4.2.  Extensibility of Data Types

   Extensibility of data types reveals that data types defined by the
   modeling language can be extended easily, so that the language can
   support various kinds of management data both simply and clearly.

   Considering application of future protocols to manage next generation
   networks, especially for the use of configuration management, more
   and more new data types should be added to satisfy different
   presentation needs.



Xu & Xiao               Expires October 30, 2010                [Page 6]

Internet-Draft    Evaluation on Data Modeling Languages       April 2010


2.4.3.  Extensibility of Elements and Attributes

   Extensibility of elements and attributes means that types of element
   nodes and attributes defined by the data modeling language shouldn't
   be too fixed to extend.  When there is a need to add new types of
   elements or new attributes for existing elements, the operation of
   "creation" should be done properly conveniently.

   Objects of great variety need to be managed in next generation
   network management, which means the demand of adding object types.
   Hence, the data modeling language should have this capability, in
   order that everyone can manage the objects both simply and
   effectively.

2.5.  Readability

   It is desired that management data modeling languages should be
   easily understood by both operators and computers.  Human readability
   is necessary for convenient study and use.  And machine readability
   is required to accelerate automatic process of network management,
   since both DMs and IMs are now being complemented by semantic models,
   where the meaning of concepts used in network management and
   relationships existing between them are made explicit.

2.5.1.  Human Readability

   Human readability is the capability by which administrators can
   directly read and understand representations including input and
   output (requirements, responses, error messages, etc).

   Only if administrators conveniently read and understand meanings of
   the DM, can they efficiently write and use it.  This also does favor
   to the interoperation between DMs and administrators.  It is then
   desirable that all DMs used for a network management solution are
   well formed according to the data modeling language.

2.5.2.  Machine Readability

   Machine readability refers to the feature that description of the
   relevant DM can be understood by computers, thus related applications
   can be quickly developed.  Its implementation largely depends on
   semantic expressiveness, and its speed also has very close relation
   with the parse-ability of machines.  Note that, each data modeling
   language has a different level of semantic expressiveness, which
   includes several facets like concepts, relations and behaviors, and
   it is not easy to measure semantic expressiveness.  Nowadays, this
   problem can be temporally reduced to a problem of integrating
   different management data modeling languages.



Xu & Xiao               Expires October 30, 2010                [Page 7]

Internet-Draft    Evaluation on Data Modeling Languages       April 2010


   Future network management protocol aims in enabling the system to
   automate its management process.  From this point of view, semantic
   expressiveness is quite essential for better machine readability.
   For example, the behavior defined by data modeling languages should
   be well understood, so that the automation requirements towards
   network management can be promoted and become much more promising.

2.6.  Data Representations

   Traditional network management solutions are often not strong in
   configuration management mostly as a result of modeling problems
   related to data representation, such as configuration objects being
   not easily identified.  Consequently, the level of data
   representation ability should be taken into consideration.

2.6.1.  Support of Hierarchical Data

   Support of hierarchical data implies that hierarchical data can be
   clearly described by the modeling language so that it can be easily
   understood by both operators and computers.

   It is said to be better that management data defined by a modeling
   language should be hierarchical and emphasis should be placed on
   creating application-level ones especially for the configuration.

2.6.2.  Specification of Configuration Data, State Data and Statistics
        Data

   Configuration data is the set of read-write data, while both state
   data and statistic data are read-only, only different in the scope of
   practical use.  The DM specified for a network device should identify
   what is configuration data, what is state data and what is statistic
   data, without the trouble to separate container elements.

   When a device is performing configuration operations, a number of
   problems would arise if state data and statistic data were included
   in configuration data, and in order to account for these issues,
   future network management protocol should recognize the differences
   among state data, statistic data and configuration data, and provides
   operations for each.  Thus as for the data modeling language, it then
   becomes necessary to make a clear distinction between (a)
   configuration data and (b) state data and statistic data.

2.7.  Security Considerations

   Security cannot be ignored by modeling languages to ensure
   confidentiality and integrity of management data.




Xu & Xiao               Expires October 30, 2010                [Page 8]

Internet-Draft    Evaluation on Data Modeling Languages       April 2010


2.7.1.  Granularity of Access Control

   Granularity of access control refers to the precision of accessing
   data from the relevant DM.  There are mainly two levels of
   granularity, which are coarse one and fine one.  Using coarse
   granularity of access control, a bulk of data can be retrieved and
   edited from the DM, such as getting the whole data from MIB.  And
   fine granularity refers to a detailed operation to a small part of
   data, such as elements.

   Both coarse granularity and fine granularity have their advantages
   and disadvantages.  For example, implementation of coarse granularity
   is simple, while reusability is very poor.  Hence, the tradeoff
   between coarse granularity and fine granularity becomes quite
   necessary for data modeling especially when merging and mapping
   information across multiple systems or data stores, since granularity
   may not match in the process of mapping.

2.7.2.  Lock Mechanism

   Lock mechanism cannot be ignored by management data modeling
   languages in order to guarantee security of the configuration.

   As to some devices, it is quite hard to determine which parameters
   are administratively configured and which are obtained via mechanisms
   such as routing protocols.  Taking configuration management into
   consideration, an implementation should figure out how users lock an
   entire configuration database, even if users do not have "write"
   access to the entire database.  Furthermore, it is also of great
   importance to a partial lock of a configuration data store.  Although
   it's not clear how serious this problem is, the solution is now an
   open issue.



















Xu & Xiao               Expires October 30, 2010                [Page 9]

Internet-Draft    Evaluation on Data Modeling Languages       April 2010


3.  Validation

   The languages being measured are Guidelines for the Definition of
   Managed Objects (GDMO) for CMIP, Structure of Management Information
   version 2 (SMIv2) for SNMP, Management Information Format (MIF) for
   DMI, Managed Object Format/Common Information Model (MOF/CIM) for
   WBEM, and Structure of Management Information, next generation
   (SMIng) for both SNMP and COPS-PR, all of which are available
   nowadays in the field of network management.

   First, Table 1 shows which modeling approach each language adopts in
   the interest of network management.  As is indicated in Table 1,
   object-based approach is especially distinguished from object-
   oriented approach, since the former one is an incomplete version of
   the latter one.

   +----------------------------+------+-------+-----+---------+-------+
   |                            | GDMO | SMIv2 | MIF | MOF/CIM | SMIng |
   +----------------------------+------+-------+-----+---------+-------+
   |   Data-Oriented Approach   |      |   #   |     |         |       |
   |                            |      |       |     |         |       |
   |  Command-Oriented Approach |      |       |     |         |       |
   |                            |      |       |     |         |       |
   |    Object-Based Approach   |      |       |  #  |         |   #   |
   |                            |      |       |     |         |       |
   |  Object-Oriented Approach  |   #  |       |     |    #    |       |
   |                            |      |       |     |         |       |
   | Document-Oriented Approach |      |       |     |         |       |
   +----------------------------+------+-------+-----+---------+-------+

            Table 1: Modeling approach adopted by each language

   Second, Table 2 illustrates the comparison result in terms of the
   evaluation criteria listed in Section 2 except for modeling
   approaches, the comparison on which has been presented in Table 1.
   Note that, our measurement is classified as the following four
   levels.

   a.  A minus sign (-) means that the language does not have such a
       capability.

   b.  An asterisk sign (*) denotes that the language is weak in this
       capability.

   c.  A plus sign (+) is used when the language is good at this
       capability.





Xu & Xiao               Expires October 30, 2010               [Page 10]

Internet-Draft    Evaluation on Data Modeling Languages       April 2010


   d.  Two plus sign (++) is placed when the language completely
       possesses this capability.

   It can be concluded from Table 2 that, SMIng is the language with
   best implementation of most criteria, while SMIv2 and MOF/CIM are
   near SMIng capabilities.













































Xu & Xiao               Expires October 30, 2010               [Page 11]

Internet-Draft    Evaluation on Data Modeling Languages       April 2010


   +----------------------------+------+-------+-----+---------+-------+
   | Language                   | GDMO | SMIv2 | MIF | MOF/CIM | SMIng |
   +----------------------------+------+-------+-----+---------+-------+
   | Interoperability           |      |       |     |         |       |
   |                            |      |       |     |         |       |
   |   Protocol Independence    |   -  |   -   |  +  |    -    |   *   |
   |                            |      |       |     |         |       |
   |   Naming Independence      |   -  |   -   |  -  |    -    |   -   |
   |                            |      |       |     |         |       |
   | Conformance                |      |       |     |         |       |
   |                            |      |       |     |         |       |
   |   Backward Compatibility   |   -  |   +   |  *  |    *    |   -   |
   |                            |      |       |     |         |       |
   |   Versioning               |   -  |   -   |  -  |    +    |   *   |
   |                            |      |       |     |         |       |
   |   Definition of Event      |   -  |   ++  |  -  |    -    |   ++  |
   | Notification Messages      |      |       |     |         |       |
   |                            |      |       |     |         |       |
   |   Definition of Error      |   -  |   -   |  -  |    -    |   -   |
   | Messages                   |      |       |     |         |       |
   |                            |      |       |     |         |       |
   | Extensibility              |      |       |     |         |       |
   |                            |      |       |     |         |       |
   |   Extensibility of Data    |   -  |   -   |  -  |    -    |   -   |
   | Structures                 |      |       |     |         |       |
   |                            |      |       |     |         |       |
   |   Extensibility of Data    |   -  |   +   |  -  |    +    |   +   |
   | Types                      |      |       |     |         |       |
   |                            |      |       |     |         |       |
   |   Extensibility of         |   -  |   -   |  -  |    -    |   +   |
   | Elements and Attributes    |      |       |     |         |       |
   |                            |      |       |     |         |       |
   | Readability                |      |       |     |         |       |
   |                            |      |       |     |         |       |
   |   Human Readability        |   *  |   *   |  *  |    *    |   +   |
   |                            |      |       |     |         |       |
   |   Machine Readability      |   +  |   *   |  *  |    +    |   +   |
   |                            |      |       |     |         |       |
   | Data Representations       |      |       |     |         |       |
   |                            |      |       |     |         |       |
   |   Support of Hierarchical  |   -  |   *   |  -  |    -    |   -   |
   | Data                       |      |       |     |         |       |
   |                            |      |       |     |         |       |
   |   Specification of         |   -  |   -   |  -  |    -    |   -   |
   | Configuration Data,State   |      |       |     |         |       |
   | Data and Statistics Data   |      |       |     |         |       |
   |                            |      |       |     |         |       |
   | Security Considerations    |      |       |     |         |       |



Xu & Xiao               Expires October 30, 2010               [Page 12]

Internet-Draft    Evaluation on Data Modeling Languages       April 2010


   |   Granularity of Access    |   -  |   +   |  -  |    -    |   +   |
   | Control                    |      |       |     |         |       |
   |                            |      |       |     |         |       |
   |   Lock Mechanism           |   -  |   -   |  -  |    -    |   -   |
   +----------------------------+------+-------+-----+---------+-------+

             Table 2: Summary of the compared characteristics

   Undoubtedly, existing data modeling languages play an important role
   in traditional network management.  Especially, SMIv2 has commendably
   implemented performance management in SNMP-based network management.
   However, networks have become more and more complex and heterogeneous
   as well, so DMs based on these data modeling languages don't seem to
   have enough ability to meet the requirements towards future network
   management.  Using our proposed evaluation framework, the
   deficiencies of available languages have been clearly shown above,
   the main point of which is summarized as follows.

   a.  All of them only use a single modeling approach not integration
       demanded by data modeling.

   b.  Their interoperability is insufficient, though some efforts have
       been made.  Traditional DMs are designed especially for certain
       protocols, always having close relation with specific operations
       of the protocols, and take their individual naming rules, way of
       expression, and so on, all of which lead to the poverty of
       universality in meeting the interoperable requirements of next
       generation network management solutions.

   c.  Their human readability is quite weak, while their machine
       readability is also fairly poor, which is far from the automatic
       aim of next generation network management.

   d.  Traditional DMs put emphasis on performance management, but take
       little consideration into configuration management.  Future DMs
       should strengthen this point in order to satisfy a higher demand
       of configuration management, which has been clearly shown as one
       of the most important objectives of next generation network
       management.

   e.  As for conformance required by data modeling, backward
       compatibility and versioning are two features that are related
       but with a different focus.  Additionally, few of the languages
       lay emphases on definition of event notification messages with
       exception of SMIv2 and SMIng, which are in full procession of
       this capability.  Furthermore, all these languages pay no
       attention to definition of error messages.




Xu & Xiao               Expires October 30, 2010               [Page 13]

Internet-Draft    Evaluation on Data Modeling Languages       April 2010


   f.  Their extensibility is quite deficient, which can not satisfy
       application needs of network management solutions.

   g.  In DMs specified by traditional modeling languages, mechanisms
       related to access control and lock is so simple that it cannot
       satisfy the demands of network security and adapt to complex
       network operations as well.  Additionally, the level of network
       security requirements is being higher and higher with the
       popularity of next generation networks.










































Xu & Xiao               Expires October 30, 2010               [Page 14]

Internet-Draft    Evaluation on Data Modeling Languages       April 2010


4.  Application of Proposed Framework to NETCONF-based Data Modeling

   Using our proposed evaluation framework, we compare the possible
   NETCONF data modeling languages that are XML Schema, RELAX NG, OWL
   and YANG, the result of which is presented in Table 3 and Table 4.

    +----------------------------+------------+----------+-----+------+
    |                            | XML Schema | RELAX NG | OWL | YANG |
    +----------------------------+------------+----------+-----+------+
    |   Data-Oriented Approach   |            |          |     |      |
    |                            |            |          |     |      |
    |  Command-Oriented Approach |            |          |     |      |
    |                            |            |          |     |      |
    |    Object-Based Approach   |            |          |     |   #  |
    |                            |            |          |     |      |
    |  Object-Oriented Approach  |            |          |     |      |
    |                            |            |          |     |      |
    | Document-Oriented Approach |      #     |     #    |  #  |   #  |
    +----------------------------+------------+----------+-----+------+

         Table 3: Modeling approach adopted by compared languages






























Xu & Xiao               Expires October 30, 2010               [Page 15]

Internet-Draft    Evaluation on Data Modeling Languages       April 2010


   +-------------------------------------+--------+-------+-----+------+
   | Language                            |   XML  | RELAX | OWL | YANG |
   |                                     | Schema |   NG  |     |      |
   +-------------------------------------+--------+-------+-----+------+
   | Interoperability                    |        |       |     |      |
   |                                     |        |       |     |      |
   |   Protocol Independence             |   ++   |   ++  |  ++ |   -  |
   |                                     |        |       |     |      |
   |   Naming Independence               |   ++   |   ++  |  ++ |   -  |
   |                                     |        |       |     |      |
   | Conformance                         |        |       |     |      |
   |                                     |        |       |     |      |
   |   Backward Compatibility            |    +   |   +   |  +  |   +  |
   |                                     |        |       |     |      |
   |   Versioning                        |   ++   |   ++  |  ++ |  ++  |
   |                                     |        |       |     |      |
   |   Definition of Event Notification  |    -   |   -   |  -  |  ++  |
   | Messages                            |        |       |     |      |
   |                                     |        |       |     |      |
   |   Definition of Error Messages      |    -   |   -   |  -  |  ++  |
   |                                     |        |       |     |      |
   | Extensibility                       |        |       |     |      |
   |                                     |        |       |     |      |
   |   Extensibility of Data Structures  |   ++   |   ++  |  ++ |  ++  |
   |                                     |        |       |     |      |
   |   Extensibility of Data Types       |   ++   |   ++  |  ++ |  ++  |
   |                                     |        |       |     |      |
   |   Extensibility of Elements and     |   ++   |   ++  |  ++ |  ++  |
   | Attributes                          |        |       |     |      |
   |                                     |        |       |     |      |
   | Readability                         |        |       |     |      |
   |                                     |        |       |     |      |
   |   Human Readability                 |    +   |   +   |  *  |  ++  |
   |                                     |        |       |     |      |
   |   Machine Readability               |    *   |   *   |  ++ |   +  |
   |                                     |        |       |     |      |
   | Data Representations                |        |       |     |      |
   |                                     |        |       |     |      |
   |   Support of Hierarchical Data      |   ++   |   ++  |  ++ |  ++  |
   |                                     |        |       |     |      |
   |   Specification of Configuration    |   ++   |   ++  |  ++ |  ++  |
   | Data,State Data and Statistics Data |        |       |     |      |
   |                                     |        |       |     |      |
   | Security Considerations             |        |       |     |      |
   |                                     |        |       |     |      |
   |   Granularity of Access Control     |   ++   |   ++  |  ++ |  ++  |
   |                                     |        |       |     |      |




Xu & Xiao               Expires October 30, 2010               [Page 16]

Internet-Draft    Evaluation on Data Modeling Languages       April 2010


   |   Lock Mechanism                    |    -   |   -   |  -  |  ++  |
   +-------------------------------------+--------+-------+-----+------+

                        Table 4: Comparsion result

   First of all, as is demonstrated in Table 3 and Table 4, it can be
   summarized that, most properties of XML Schema surpass those of
   previous data modeling languages, especially in aspects such as
   interoperability, data representation and extensibility, which have
   been quite well-known by its numerous users.  However, its machine
   readability is not so satisfying, for the reason that, what it is
   accomplished in is not semantic expressiveness but content
   definition.  Furthermore, compared to its wide application, XML
   Schema is both too complicated and excessively general as a data
   modeling language for special use only in the scope of network
   management.  On the other hand, definition of a NETCONF-based
   management DM is much more than an XML instance document description,
   or in other words, XML Schema is still not expressive enough with a
   view to NETCONF-based data modeling.

   All these reasons above lead to the fact that, there are still no DMs
   defined by XML Schema yet.  IETF Operations & Management (OPS) Area
   discusses issues related to SMI-to-XML Schema conversion and XSD for
   accessing SMIv2 DMs, since SNMP-based network management has been
   supplemented with a lot of proprietary MIB modules defined by
   different device vendors, and discarding MIB objects and SMIv2 syntax
   when designing a new DM does reduce this benefit from experience of
   so many years.  But more work has to be done on standardizing a
   NETCONF-based data modeling language for network management.

   Additionally, as is indicated in Table 3 and Table 4, the information
   modeling capability of RELAX NG is roughly equal with that of XML
   Schema for the sake of network management.  And RELAX NG may be a
   little more advantageous than XML Schema in some aspects such as
   human readability and extensibility.  At the same time, the mapping
   of YANG to Document Schema Definition Languages (DSDL, including
   RELAX NG) is also considered these days.

   Besides, as is shown in Table 3 and Table 4, the information modeling
   capability of OWL nearly equals with that of XML Schema and RELAX NG
   in the interest of network management.  However, OWL has a remarkable
   advantage in machine readability, although the level of its human
   readability is relatively low.

   Furthermore, it can also be seen from Table 3 and Table 4 that, as a
   NETCONF-specific data modeling language, YANG takes semantics such as
   notification message definitions, error message definitions and lock
   mechanism into consideration.  All these features make YANG much



Xu & Xiao               Expires October 30, 2010               [Page 17]

Internet-Draft    Evaluation on Data Modeling Languages       April 2010


   easier to describe DMs in a way that maps to NETCONF in a very
   straight-forward manner, and due to its focus on the immediate
   requirements for NETCONF-based network management, YANG has been
   chosen as the best approach up to now.

   As for data modeling languages in network management domain, YANG is
   designed at the semantic level, while XML-related languages are at
   the syntactic level.  That is to say, XSD can be generated from the
   DMs defined in YANG.  Thus in this case, existing XML-based tools can
   be utilized.

   To sum up, YANG seems to be much more appropriate than XML Schema,
   RELAX NG and OWL for NETCONF-based data modeling, due to its focus on
   immediate requirements for the NETCONF protocol, and in order to meet
   requirements that potentially have broader applicability, XML Schema,
   RELAX NG and OWL need to be improved by providing more supports for
   the purpose of NETCONF, while YANG needs to be improved by providing
   more supports in the interest of protocol independence.

































Xu & Xiao               Expires October 30, 2010               [Page 18]

Internet-Draft    Evaluation on Data Modeling Languages       April 2010


5.  Conclusions

   An evaluation framework for management data modeling languages has
   been established and validated by applying it to summarize the
   characteristics of existing languages through comparison.  This
   framework is universal and can be reused to study data modeling in
   next generation network management domain.  Future work includes
   further study on application of this framework to NETCONF-based data
   modeling, aiming to promote the standardization progress of data
   modeling languages for NETCONF-based network management.









































Xu & Xiao               Expires October 30, 2010               [Page 19]

Internet-Draft    Evaluation on Data Modeling Languages       April 2010


6.  Security Considerations

   None.
















































Xu & Xiao               Expires October 30, 2010               [Page 20]

Internet-Draft    Evaluation on Data Modeling Languages       April 2010


7.  IANA Considerations

   None.
















































Xu & Xiao               Expires October 30, 2010               [Page 21]

Internet-Draft    Evaluation on Data Modeling Languages       April 2010


8.  References

8.1.  Normative References

   [RFC1155]  Rose, M. and K. McCloghrie, "Structure and identification
              of management information for TCP/IP-based internets",
              STD 16, RFC 1155, May 1990.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2578]  McCloghrie, K., Ed., Perkins, D., Ed., and J.
              Schoenwaelder, Ed., "Structure of Management Information
              Version 2 (SMIv2)", STD 58, RFC 2578, April 1999.

   [RFC2579]  McCloghrie, K., Ed., Perkins, D., Ed., and J.
              Schoenwaelder, Ed., "Textual Conventions for SMIv2",
              STD 58, RFC 2579, April 1999.

   [RFC2580]  McCloghrie, K., Perkins, D., and J. Schoenwaelder,
              "Conformance Statements for SMIv2", STD 58, RFC 2580,
              April 1999.

   [RFC3216]  Elliott, C., Harrington, D., Jason, J., Schoenwaelder, J.,
              Strauss, F., and W. Weiss, "SMIng Objectives", RFC 3216,
              December 2001.

   [RFC3444]  Pras, A. and J. Schoenwaelder, "On the Difference between
              Information Models and Data Models", RFC 3444,
              January 2003.

   [RFC3535]  Schoenwaelder, J., "Overview of the 2002 IAB Network
              Management Workshop", RFC 3535, May 2003.

   [RFC3780]  Strauss, F. and J. Schoenwaelder, "SMIng - Next Generation
              Structure of Management Information", RFC 3780, May 2004.

   [RFC3781]  Strauss, F. and J. Schoenwaelder, "Next Generation
              Structure of Management Information (SMIng) Mappings to
              the Simple Network Management Protocol (SNMP)", RFC 3781,
              May 2004.

   [RFC4741]  Enns, R., "NETCONF Configuration Protocol", RFC 4741,
              December 2006.







Xu & Xiao               Expires October 30, 2010               [Page 22]

Internet-Draft    Evaluation on Data Modeling Languages       April 2010


8.2.  Informative References

   [RFC3410]  Case, J., Mundy, R., Partain, D., and B. Stewart,
              "Introduction and Applicability Statements for Internet-
              Standard Management Framework", RFC 3410, December 2002.














































Xu & Xiao               Expires October 30, 2010               [Page 23]

Internet-Draft    Evaluation on Data Modeling Languages       April 2010


Authors' Addresses

   Hui Xu
   Institute of Computer Network and Communication
   Huazhong Normal University
   WuHan, HuBei  430079
   P.R. China

   Phone: +86 027 6136 8682
   Email: xuhui_1004@hotmail.com


   Debao Xiao
   Institute of Computer Network and Communication
   Huazhong Normal University
   WuHan, HuBei  430079
   P.R. China

   Phone: +86 027 6786 6108
   Email: dbxiao@mail.ccnu.edu.cn































Xu & Xiao               Expires October 30, 2010               [Page 24]