Network Working Group H. Xu
Internet-Draft DB. Xiao
Intended status: Experimental CCNU INC
Expires: May 4, 2009 October 31, 2008
An Evaluation Framework for Data Modeling Languages in Network
Management Domain
draft-xiao-evaluate-dml-03
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
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 May 4, 2009.
Xu & Xiao Expires May 4, 2009 [Page 1]
Internet-Draft Evaluation on Data Modeling Languages October 2008
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, readability, conformance, data representation,
extensibility and security considerations.
Xu & Xiao Expires May 4, 2009 [Page 2]
Internet-Draft Evaluation on Data Modeling Languages October 2008
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Proposed Evaluation Framework . . . . . . . . . . . . . . . . 5
2.1. Modeling Approaches . . . . . . . . . . . . . . . . . . . 5
2.2. Interoperability . . . . . . . . . . . . . . . . . . . . . 5
2.2.1. Protocol Independence . . . . . . . . . . . . . . . . 5
2.2.2. Naming Independence . . . . . . . . . . . . . . . . . 6
2.3. Readability . . . . . . . . . . . . . . . . . . . . . . . 6
2.3.1. Human Readability . . . . . . . . . . . . . . . . . . 6
2.3.2. Machine Readability . . . . . . . . . . . . . . . . . 6
2.4. Data Representation . . . . . . . . . . . . . . . . . . . 7
2.4.1. Diversity of Data Types . . . . . . . . . . . . . . . 7
2.4.2. Specification of Configuration Data, State Data
and Statistics Data . . . . . . . . . . . . . . . . . 7
2.5. Conformance . . . . . . . . . . . . . . . . . . . . . . . 8
2.5.1. Backward Compatibility . . . . . . . . . . . . . . . . 8
2.5.2. Versioning . . . . . . . . . . . . . . . . . . . . . . 8
2.5.3. Definition of Event Notification Messages . . . . . . 8
2.5.4. Definition of Error Messages . . . . . . . . . . . . . 8
2.6. Extensibility . . . . . . . . . . . . . . . . . . . . . . 9
2.6.1. Extensibility of Data Structures . . . . . . . . . . . 9
2.6.2. Extensibility of Data Types . . . . . . . . . . . . . 9
2.6.3. Extensibility of Elements and Attributes . . . . . . . 9
2.7. Security Considerations . . . . . . . . . . . . . . . . . 9
2.7.1. Granularity of Access Control . . . . . . . . . . . . 10
2.7.2. Lock Mechanism . . . . . . . . . . . . . . . . . . . . 10
3. Validation . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4. Application of Proposed Framework to NETCONF-based Data
Modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
5. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 20
6. Security Considerations . . . . . . . . . . . . . . . . . . . 21
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
8.1. Normative References . . . . . . . . . . . . . . . . . . . 23
8.2. Informative References . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25
Intellectual Property and Copyright Statements . . . . . . . . . . 26
Xu & Xiao Expires May 4, 2009 [Page 3]
Internet-Draft Evaluation on Data Modeling Languages October 2008
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 May 4, 2009 [Page 4]
Internet-Draft Evaluation on Data Modeling Languages October 2008
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. And our proposed
evaluation framework is based on a set of criteria, which are
modeling approaches, interoperability, readability, conformance, data
representation, extensibility 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.
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
Xu & Xiao Expires May 4, 2009 [Page 5]
Internet-Draft Evaluation on Data Modeling Languages October 2008
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. 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.3.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.3.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
Xu & Xiao Expires May 4, 2009 [Page 6]
Internet-Draft Evaluation on Data Modeling Languages October 2008
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.
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.4. Data Representation
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.4.1. Diversity of Data Types
Diversity of data types implies that data types should be diverse
enough so that the modeling language can support various data.
Hence, data with a suitable type can be clearly described and
understood for users.
More structured data types are needed to make DMs much simpler to
design and implement in the field of network management. It is said
to be better that data types defined by a management modeling
language should be as various as possible and emphasis should be
placed on creating application-level ones especially for the
configuration.
2.4.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
Xu & Xiao Expires May 4, 2009 [Page 7]
Internet-Draft Evaluation on Data Modeling Languages October 2008
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.5. Conformance
When defining MOs, it is also quite necessary to describe machine-
readable conformance for the DM.
2.5.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.5.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
the new language if it is also backwards compatible.
2.5.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.5.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.
Xu & Xiao Expires May 4, 2009 [Page 8]
Internet-Draft Evaluation on Data Modeling Languages October 2008
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.6. 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.6.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.6.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.
2.6.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.7. Security Considerations
Security cannot be ignored by modeling languages to ensure
confidentiality and integrity of management data.
Xu & Xiao Expires May 4, 2009 [Page 9]
Internet-Draft Evaluation on Data Modeling Languages October 2008
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 May 4, 2009 [Page 10]
Internet-Draft Evaluation on Data Modeling Languages October 2008
3. Validation
The languages being measured are Guidelines for the Definition of
Managed Objects (GDMO) for CMIP, Structure of Management Information
(SMI) with its different versions 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 | SMI | 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 May 4, 2009 [Page 11]
Internet-Draft Evaluation on Data Modeling Languages October 2008
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 SMI and MOF/CIM are near
SMIng capabilities.
Xu & Xiao Expires May 4, 2009 [Page 12]
Internet-Draft Evaluation on Data Modeling Languages October 2008
+------------------------------+------+-----+-----+---------+-------+
| Language | GDMO | SMI | MIF | MOF/CIM | SMIng |
+------------------------------+------+-----+-----+---------+-------+
| Interoperability | | | | | |
| | | | | | |
| Protocol Independence | - | - | + | - | * |
| | | | | | |
| Naming Independence | - | - | - | - | - |
| | | | | | |
| Readability | | | | | |
| | | | | | |
| Human Readability | * | * | * | * | + |
| | | | | | |
| Machine Readability | + | * | * | + | + |
| | | | | | |
| Data Representation | | | | | |
| | | | | | |
| Diversity of Data Types | - | * | - | - | - |
| | | | | | |
| Specification of | - | - | - | - | - |
| Configuration Data,State | | | | | |
| Data and Statistics Data | | | | | |
| | | | | | |
| 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 | | | | | |
| | | | | | |
| Security Considerations | | | | | |
| | | | | | |
Xu & Xiao Expires May 4, 2009 [Page 13]
Internet-Draft Evaluation on Data Modeling Languages October 2008
| 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, SMI 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 SMI 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 May 4, 2009 [Page 14]
Internet-Draft Evaluation on Data Modeling Languages October 2008
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 May 4, 2009 [Page 15]
Internet-Draft Evaluation on Data Modeling Languages October 2008
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 and YANG with
SMIng, existing top-one data modeling language, the result of which
is presented in Table 3 and Table 4.
+----------------------------+-------+------------+------+
| | SMIng | XML Schema | 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 May 4, 2009 [Page 16]
Internet-Draft Evaluation on Data Modeling Languages October 2008
+------------------------------------------+-------+---------+------+
| Language | SMIng | XML | YANG |
| | | Schema | |
+------------------------------------------+-------+---------+------+
| Interoperability | | | |
| | | | |
| Protocol Independence | * | ++ | * |
| | | | |
| Naming Independence | - | + | * |
| | | | |
| Readability | | | |
| | | | |
| Human Readability | + | + | ++ |
| | | | |
| Machine Readability | + | * | + |
| | | | |
| Data Representation | | | |
| | | | |
| Diversity of Data Types | - | ++ | ++ |
| | | | |
| Specification of Configuration | - | + | ++ |
| Data,State Data and Statistics Data | | | |
| | | | |
| 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 | | | |
| | | | |
| Security Considerations | | | |
| | | | |
| Granularity of Access Control | + | + | ++ |
| | | | |
Xu & Xiao Expires May 4, 2009 [Page 17]
Internet-Draft Evaluation on Data Modeling Languages October 2008
| 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. Currently, IETF Operations & Management
(OPS) Area is focusing the solutions on 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 SMI
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.
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
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.
Additionally, 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, description by
YANG is at a semantic level, and XSD can be generated from the DMs
defined in YANG. Thus in this case, existing tools can be utilized.
To sum up, YANG seems to be much more appropriate than XML Schema for
NETCONF-based data modeling, due to its focus on immediate
Xu & Xiao Expires May 4, 2009 [Page 18]
Internet-Draft Evaluation on Data Modeling Languages October 2008
requirements for the NETCONF protocol, and in order to meet
requirements that potentially have broader applicability, XML Schema
needs to be improved by providing more supports for the sake of
NETCONF, while YANG needs to be improved by providing more supports
in the interest of protocol independence.
Xu & Xiao Expires May 4, 2009 [Page 19]
Internet-Draft Evaluation on Data Modeling Languages October 2008
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 May 4, 2009 [Page 20]
Internet-Draft Evaluation on Data Modeling Languages October 2008
6. Security Considerations
None.
Xu & Xiao Expires May 4, 2009 [Page 21]
Internet-Draft Evaluation on Data Modeling Languages October 2008
7. IANA Considerations
None.
Xu & Xiao Expires May 4, 2009 [Page 22]
Internet-Draft Evaluation on Data Modeling Languages October 2008
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 May 4, 2009 [Page 23]
Internet-Draft Evaluation on Data Modeling Languages October 2008
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 May 4, 2009 [Page 24]
Internet-Draft Evaluation on Data Modeling Languages October 2008
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 May 4, 2009 [Page 25]
Internet-Draft Evaluation on Data Modeling Languages October 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Xu & Xiao Expires May 4, 2009 [Page 26]