Network Working Group DB. Xiao Internet-Draft H. Xu Intended status: Experimental CCNU INC Expires: December 23, 2007 June 21, 2007 Evaluation on Modeling Languages for Generic Network Management Data Models draft-xiao-evaluate-dml-00 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 December 23, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Xiao & Xu Expires December 23, 2007 [Page 1] Internet-Draft Evaluation on Data Modeling Languages June 2007 Abstract In some scenarios, the multiplicity of network management models implies the use of multiple management data modeling languages, which are used to model the resources to be managed. Each language differs in the level of various capabilities and expressiveness, most of which are not easily measured. However, existing data modeling languages have drawbacks of different levels, which hinder them in adapting to the requirements of next generation network management. The aim of our project is then to establish a framework of evaluation to compare different management data modeling languages based on a set of criteria, the most important part of which are demonstrated in this memo, being modeling approaches, expressiveness, readability, interoperability, extensibility and others, and present some perspectives on developing future data modeling languages for next generation network management, possibly integrating existing ones. Thus, this memo summarizes the characteristics of existing data modeling languages through comparison based on given criteria for evaluation. Xiao & Xu Expires December 23, 2007 [Page 2] Internet-Draft Evaluation on Data Modeling Languages June 2007 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Existing data modeling languages . . . . . . . . . . . . . . . 5 2.1. GDMO . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.2. SMI . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.3. MIF . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.4. MOF/CIM . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.5. SMIng . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3. Proposed Criteria for Evaluation . . . . . . . . . . . . . . . 10 3.1. Modeling Approaches . . . . . . . . . . . . . . . . . . . 10 3.2. Expressiveness . . . . . . . . . . . . . . . . . . . . . . 11 3.2.1. Information Integrity . . . . . . . . . . . . . . . . 11 3.2.2. Data Type Diversity . . . . . . . . . . . . . . . . . 11 3.3. Readability . . . . . . . . . . . . . . . . . . . . . . . 12 3.3.1. Human Readability . . . . . . . . . . . . . . . . . . 12 3.3.2. Machine Readability . . . . . . . . . . . . . . . . . 12 3.4. Interoperability . . . . . . . . . . . . . . . . . . . . . 13 3.4.1. Backward Compatibility . . . . . . . . . . . . . . . . 13 3.4.2. Protocol Independence . . . . . . . . . . . . . . . . 14 3.4.3. Naming Independence . . . . . . . . . . . . . . . . . 14 3.4.4. Semantic Interoperability . . . . . . . . . . . . . . 15 3.5. Extensibility . . . . . . . . . . . . . . . . . . . . . . 15 3.5.1. Data Structure Extensibility . . . . . . . . . . . . . 15 3.5.2. Data Type Extensibility . . . . . . . . . . . . . . . 16 3.5.3. Element and Attribute Extensibility . . . . . . . . . 17 3.6. Others . . . . . . . . . . . . . . . . . . . . . . . . . . 17 3.6.1. Considerations for Configuration . . . . . . . . . . . 17 3.6.2. Access Control Granularity of Data Model . . . . . . . 18 4. Comparison . . . . . . . . . . . . . . . . . . . . . . . . . . 20 5. Future Perspectives . . . . . . . . . . . . . . . . . . . . . 23 6. Security Considerations . . . . . . . . . . . . . . . . . . . 27 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 8.1. Normative References . . . . . . . . . . . . . . . . . . . 29 8.2. Informative References . . . . . . . . . . . . . . . . . . 30 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31 Intellectual Property and Copyright Statements . . . . . . . . . . 32 Xiao & Xu Expires December 23, 2007 [Page 3] Internet-Draft Evaluation on Data Modeling Languages June 2007 1. Introduction With rapid development of the Internet, the complexity of computer networks has greatly increased, when more and more network resources need to be effectively managed. So the definition of IM (Information Model) and DM (Data Model) must be seriously considered for network management. IMs always model MOs (Managed Objects) at a conceptual level and thus are protocol-neutral. DMs, on the contrary, are defined at a concrete level, thus implementing in different ways and being protocol-specific. That is to say, multiple DMs can be derived from a single IM. Under this background, data modeling languages, which are languages used to define data models, are intensively studied nowadays. As for every network management model, the data modeling language needs to describe the resources to be managed, in order to ensure the communication between managers and agents. Currently, there are several existing data modeling languages for the definition of MOs, examples of such languages are GDMO (Guidelines for the Definition of Managed Objects) for CMIP, SMI (Structure of Management Information) with its different versions for SNMP, MIF (Management Information Format) for DMI, MOF/CIM (Management Object Format/Common Information Model) for WBEM, and SMIng (Structure of Management Information, next generation) for both SNMP and COPS-PR. However, existing data modeling languages have drawbacks of different levels, which hinder them in adapting to next generation network management needs. The aim of our project is then to establish a framework to compare different management data modeling languages based on a set of criteria, and present some perspectives on developing future data modeling languages for next generation network management. This memo summarizes the characteristics of existing data modeling languages through comparison based on given criteria for evaluation, which may possibly be a large part of our final framework. 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]. Xiao & Xu Expires December 23, 2007 [Page 4] Internet-Draft Evaluation on Data Modeling Languages June 2007 2. Existing data modeling languages One possible way to develop future data modeling language for next generation network management is integration of existing ones, and a first way to reach integration is to analyze the features of these languages. To present this analysis, for one thing, the languages being compared will be presented in chronological order with a brief introduction. 2.1. GDMO Specified in ISO/IEC 10165/ITU-T X.722, GDMO is a structured description language that provides a way to define classes of objects for demonstration of their attributes, behaviors and ancestry, adopting ASN.1 (Abstract Syntax Notation One) as its format. GDMO uses the object-oriented paradigm, always describing the managed resources either concrete or abstract in the Internet, mainly for the definition of constructs and behaviors of MOs for TMN-based Systems and CMIP services. Moreover, it adds some other features to allow a better reuse of the defined management data, which also adds a lot of complexity to the language. During the past years, GDMO has been widely used in the area of TMN management, when at the same time, some drawbacks still exist. For example, its power of expression is not strong enough, especially when being used to describe the characters of behaviors. Instead of formalized definitions, it uses the natural languages, such as the BEHAVIOUR template, which is open to any definition, hence not so accurate and always causing ambiguity. 2.2. SMI Since its introduction in late 1980s, SNMP has been widely used in the industry field of network management. MIB (Management Information Base) is the data model specific to SNMP, and accordingly SMI, which is derived from ASN.1, is the data modeling language for MIB, defining the organization structure of MIB and giving a set of rules to describe and identify variables in MIB. Originally developed from the similar concept in OSI network management, SMI defines organization, composing and identifier used in the framework of SNMP. In 1990, the Network WG (Working Group) established by IETF put forward RFC1155, which detailedly defines SMIv1 used in SNMPv1. Few years later, the IETF Network WG improved SMI so as to propose SMIv2, which was defined in RFC2578. Compared with SMIv1, SMIv2 is more expressive, since it introduces new data types and new macros, adds the compliance requirements of MIB, and leaves some space to the vendor for extension. SMIv2 is now used by Xiao & Xu Expires December 23, 2007 [Page 5] Internet-Draft Evaluation on Data Modeling Languages June 2007 both SNMPv2 and SNMPv3 to define MOs. According to the definition of both SMIv1 and SMIv2, every MO in SNMP has three attributes:(1)Name. Every MO has only one object identifier as its name;(2)Syntax. The abstract data structure of each MO is defined by ASN.1;(3)Encoding. The instance of MO is also encoded in ASN.1, while the sending and receiving protocol messages including the value of MO are defined in BER (Basic Encoding Rules). The objects defined by SMI are presented as scalar variables or tables, making it rather simply to construct, and the data types are much more than GDMO, for SMI has three kinds of types, including simple types, structured types and application types. Moreover, the SMI language is clear and easy to read. Unfortunately, SMI also has some drawbacks, which hinder the application of SNMP in future network management domain. The root lies in the fact that SMI uses a data-oriented approach to model all management aspects. On one hand, SMI is insufficient to represent hierarchical network configuration data, which is one of the main reasons for SNMP being used mostly in monitoring for fault and performance, but hardly used for configuration management. On the other hand, SMI is such a conceptually simple data modeling language that it is usually quite difficult to be used for modeling complex management operations. 2.3. MIF Created by the DMTF (Desktop Management Task Force) to automate system management, particularly beneficial in a network computing environment, DMI is hardware, operating system and management protocol-independent, easy for vendors to adopt, mappable to existing management protocols such as SNMP, and used on network and non- network computers. DMI establishes a standard framework for managing networked desktop systems and servers, enables remote manageability, and imposes a more tightly defined model for filtering events and describing interfaces for remote ability. As a component of DMI, MIF was first proposed in the "Desktop Management Interface Specification Version 1.0" in 1993, and until now, there are mainly four versions for its specification. MIF is a format used to describe a hardware or software component. MIF files are used by DMI to report system configuration information. Although MIF is a system-independent format, it is used primarily by Windows systems. As a text file, MIF contains specific information about the hardware and software, consisting of one or more groups with attributes for the description of each component and tables as well, which are somewhat similar to SMI, or even simpler, since table keys are always internal to that table, and thus, associations can not be Xiao & Xu Expires December 23, 2007 [Page 6] Internet-Draft Evaluation on Data Modeling Languages June 2007 defined in this way. By default, each MIF file contains the standard component ID group, which contains the product name, version, serial number and the accurate time of the last installation. The ID number is assigned based on when the component was installed in relation to other components. Manufacturers can also create their own MIFs specific to a component. MIF has done best in being protocol independence among existing data modeling languages. The Desktop Management Interface and the Internet-standard Network Management Framework, commonly known as "SNMP Management Framework", are standard management frameworks widely deployed to manage computer systems and network devices respectively. The two frameworks are similar in concept and function. However, while the two frameworks may co-exist on the same system, the two are not inherently interoperable. Despite this, applications that span the heterogeneous nature of system and network management must access management information using both frameworks. Therefore, the objective of the DMI-to-SNMP is to bridge the interoperability gap between SNMP and DMI-based solutions. 2.4. MOF/CIM Firstly proposed by DMTF in 1997, CIM is the core part of the WBEM (Web Based Enterprise Management), which is developed by DMTF to solve the heterogeneous management environment problem. CIM provides a data modeling environment in the form of object-oriented design diagrams and a language-neutral description of the model known as the MOF. As a part of the overall WBEM specification, the MOF language is again defined by the DMTF, but it is object-oriented and much more powerful than MIF. The DMTF has a variety of tools to work with MOF representations of CIM models. Based on IDL (Interface Definition Language), MOF contains a set of intrinsic data types. Moreover, with the goals of good human readability and effective parsing ability, the MOF syntax provides a way to describe object-oriented class and instance definitions in textual form. The main components of a MOF specification are textual descriptions of classes, associations, properties, references, methods, instance declarations, and their associated qualifiers. The format of MOF is very simple and easy to edit, and thus it can be readable by both machine and human. Additionally, MOF can also be translated to XML (eXtensible Markup Language) to exchange the information. Some other characteristics need to be seriously considered, presented as follows. a. MOF only defines information of type and description, hence it is quite difficult to extend. Xiao & Xu Expires December 23, 2007 [Page 7] Internet-Draft Evaluation on Data Modeling Languages June 2007 b. CIM specification describes the mappings from MOF to other network management data modeling languages. However, the syntax and semantic conformance in the mapping process is difficult to achieve. 2.5. SMIng Proposed by IRTF, the SMIng project started in 1999, aiming to address some drawbacks of SMIv2, in order to create a new kind of management data modeling language to integrate SMI and SPPI (Structure of Policy Provisioning Information), avoiding the use of ASN.1. Its ideal characteristics are protocol-neutral, more expressive than SMI and including much more information about the MOs. Specific objectives for SMIng are presented in 2001, dividing into three types: accepted ones, nice-to-have ones and rejected ones. SMIng has been split into two parts, which are a core data definition language (this specification is defined in RFC3780) and protocol mappings to allow the application of core definitions through multiple network management protocols (its mapping to SNMP is defined in RFC3781). SMIng applies an object-based approach to model MOs, combining SMI and SPPI. Compared to SMI, SMIng has more advantages in expressiveness, such as better data type definition capability, improved table definition, consideration of some operations, definition of attribute groups and event groups, and so on. Additionally, it is also possible to define extensions, which specify new structures by providing the syntax with which they must comply. However, due to disagreement of both the SMIng syntax and the relationship between SMIng and SMI, SMIng didn't finally become a standard network management data modeling language. Although SMIng aimed in being an integrated data modeling language that could be adapted for different network management protocols and thus closer to an information modeling language, the complexity of design increased when moving towards being a protocol-neutral language, much more than designers used to think of. The commonality of SMIng is only limited to two protocols, which are SNMP and COPS-PR (Common Open Policy Service for Policy Provisioning). Additionally, since the constraint difference of various protocols is quite great, the mapping method adopted by SMIng fails to provide a good treatment with this problem. Other things we have learned from the SMIng project are as follows. a. A tradeoff should be made among data model readers, data model writers and tool developers, and usually the preference needs to be given to readers. Xiao & Xu Expires December 23, 2007 [Page 8] Internet-Draft Evaluation on Data Modeling Languages June 2007 b. It is much more important to consider the semantics of data modeling languages than to consider their syntax, in order to promote automation. c. The language should be as much abstract, independent, extensible and consistent, as possible. Xiao & Xu Expires December 23, 2007 [Page 9] Internet-Draft Evaluation on Data Modeling Languages June 2007 3. Proposed Criteria for Evaluation A framework of evaluation will be established in the future to compare different management data modeling languages based on a set of criteria, a most important part of which are modeling approaches, expressiveness, readability, interoperability, extensibility and others. In the following, we will demonstrate them in the terms of "Description" (a brief introduction of the criteria), "Motivation" (requirement of network management to call for the criteria) and "Application" (one or more existing languages typical in the criteria). 3.1. Modeling Approaches Description: Four main modeling approaches must be considered, including Data- Oriented Approach, Command-Oriented Approach, Object-Oriented/ Object-Based Approach and Document-Oriented Approach. The data- oriented approach models all management aspects through data objects, and at least two operations (get and set) must 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. The document-oriented approach represents both the status information and the configuration information of a device as a structured document. Motivation: The choice of modeling approaches has impact on the features required by data modeling languages. It is desired that, a data modeling language supports a data-oriented view for monitoring, a command-oriented view for operations, and a document-oriented view for configuration. In fact, the object-oriented/object-based approach is just an attempt to combine different approaches for the purpose of integration. We argue that, however, it may be better to avoid mixing different approaches for the same functionality, and different approaches may be chosen aiming at different management requirements. Application: On one side, SMI applies a data-oriented approach to model network management data. On the other side, SMIng uses an object-based approach for network management data model, in order to improve SMI. Xiao & Xu Expires December 23, 2007 [Page 10] Internet-Draft Evaluation on Data Modeling Languages June 2007 3.2. Expressiveness 3.2.1. Information Integrity Description: Information integrity means that the information defined by data modeling languages about elements is comprehensive. Language with information integrity describes the elements in detail with every facet of them. Motivation: When a managed object is described in the field of network management, it is desired that the information about the object should be as much as possible so that every facets of the object is known to network managers. It may be better that a data modeling language be of stronger information integrity when be used for describing data model. Application: Every modeling language has its own method to define the information about elements and tries its best to describe more. On one hand, GDMO defines a series of templates to describe MOs such as package, attributes and operations, paying more attention about semantics. On the other hand, SMI defines information with less attention to semantics but more information about other features such as various data types, many status, and different access modes by the definition of several independent macros. 3.2.2. Data Type Diversity Description: Data type diversity means that data types should be diverse enough so that the modeling language can support various data presentation. Thus then data with suitable type can be clearly described and understood for users. Motivation: More structured data types and various RPC interactions (methods) are needed to make data models much simpler to design and implement in network management. It is said to be better that data types defined by a modeling language should be as many as possible in network management. Xiao & Xu Expires December 23, 2007 [Page 11] Internet-Draft Evaluation on Data Modeling Languages June 2007 Application: SMI defines three kinds of data types (simple types, structured types and application types) to present various data in complex networks with many different types of devices, which is better than other existing data modeling languages. 3.3. Readability 3.3.1. Human Readability Description: Human readability is the feature by which processors and managers can directly read and understand data representation including input and output (requirements, responses, error messages, etc). It is an essential feature for network management data modeling languages. Motivation: Only if processors easily read and understand meanings of the data model, can they efficiently write and use it. This also does favor to the interoperation between data models and processors. It is better that a data modeling language supports high level of human readability for processors to read, understand and write modules. Application: As for existing data modeling language including SMI, SMIng, GDMO, MOF and MIF, human readability is not very well. For example, SMI, GDMO, and MOF stores instances in the form of BER encoded ASN.1 sequences while MIF uses BNF, which are generally not suitable for human readability. Among them, though SMIng improves the feature of human readability using ABNF grammar, the problem of human readability also exists. Therefore, future data modeling languages strongly require good human readability. 3.3.2. Machine Readability Description: Machine readability refers to the feature that the description of data model can be easily read and understood by computer, thus related applications can be quickly developed and efficiently implemented. Its speed also has a close relation with the parse- ability of the machine. Xiao & Xu Expires December 23, 2007 [Page 12] Internet-Draft Evaluation on Data Modeling Languages June 2007 Motivation: The syntax that modeling language defines should be so readable to machine that parsing of the modeling language can be quick and easy, and thus then more time can be saved in the reading process of data model by machine. Application: Machine readability is a vital feature for data modeling languages, by which processing and implementation will be quicker and more efficient. However, existing data modeling languages including SMI, SMIng, GDMO, MOF and MIF are not good at this point. Most of them are represented by ASN.1 or BNF, which is very complex to parse and process. Therefore, it is desired that future data modeling language should have a better machine readability than existing ones, by which computer can understand and parse easily. Of course, it is better to use many good off- the-shelf tools. 3.4. Interoperability 3.4.1. Backward Compatibility Description: Backward compatibility means that new versions of a data modeling language can be used to define network management data model as the older modeling language used to do. Motivation: Backward compatibility is quite important, for the reason that it eliminates the need to start over when a new data modeling language is used. If a data modeling language is not backward compatible, it will cost much more for implementers to map the data model using older modeling language to that using the new one. Application: SMI is backward compatible. SMIv2 can be used to define any MIB that defined by SMIv1. Xiao & Xu Expires December 23, 2007 [Page 13] Internet-Draft Evaluation on Data Modeling Languages June 2007 3.4.2. Protocol Independence Description: A data modeling language needs to define data with support of any protocol instead of belonging to some specific protocol. In other words, data model defined by the modeling language can be implemented on any platform that installs different protocols. Motivation: A good data modeling language needs to stop the proliferation of different data modeling languages within the IETF and to harmonize the various models. As a result, data models defined in a protocol neutral data modeling language can be mapped on different underlying protocols. Application: As stated above, MIF has done best in being protocol independence among existing data modeling languages. Additionally, SMIng is more protocol neutral than other IETF approaches, because MIB and PIB modules defined in SMIng can be mapped on different underlying protocols, which are a mapping on SNMP and another mapping on COPS-PR. 3.4.3. Naming Independence Description: Naming independence is in fact the mechanism that specifies how name collisions are handled, and thus uniquely identifies attributes, groups of attributes, and events. Motivation: Since a data modeling language needs to be protocol independence, and protocols typically use different approaches to name instances, it must support multiple instance naming systems. Application: There must be a hierarchical, centrally-controlled namespace for standard named items, and a distributed namespace must be supported to allow vendor-specific naming and to assure unique module names across vendors and organizations. For example, data types defined in a namespace need to unambiguously identify definitions of various kinds. Implementation of data modeling Xiao & Xu Expires December 23, 2007 [Page 14] Internet-Draft Evaluation on Data Modeling Languages June 2007 languages should not have problems with different objects from multiple modules but with the same name. Being naming independence, a data modeling language needs to think about the relationships between models. 3.4.4. Semantic Interoperability Description: 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. Hence, it is then quite difficult to implement semantic interoperability, and nowadays, this problem becomes an open issue and temporally can be reduced to a problem of integrating different data modeling languages. Motivation: As for network management data modeling languages, they cannot be easily integrated due to a difficult translation of the semantics they contain. Integrated network management data modeling languages can be understood as a term of lightweight ontology because they just define the information of the management domain, but do not include the axioms or constraints present in heavyweight ontology, which makes them difficult to reason. Application: In fact, network management data modeling languages can be compared in term of their semantic expressiveness. Criteria consisting of concepts, taxonomies, relations, functions, instances and axioms have been adopted and applied to network management languages as grounds for comparison. It can be concluded that MOF/CIM has the best semantic expressiveness, while SMIng and GDMO are near MOF/CIM expressiveness. 3.5. Extensibility 3.5.1. Data Structure Extensibility Description: Data structure extensibility means that the data modeling languages have the ability to add new data structures without affecting existing data structure, and thus express the relations among data effectively and do operations on data easily. Xiao & Xu Expires December 23, 2007 [Page 15] Internet-Draft Evaluation on Data Modeling Languages June 2007 Motivation: Data structure is a way of storing data in computer including storage organization and logic structure, and only with good data structure can data be used effectively. Thus, there is a great need for data modeling languages to have the ability to extend data structure easily with the great increase of isomerization and complexity of Internet. For example, current modeling languages only have some simple data structures such as simple aggregations and lists, and future languages may extend to support more complex data structures like complex table or tree representations, singly-linked or doubly-linked lists and lists within list. Application: Up to now, none of existing data modeling languages has the ability of data structure extensibility. They all have the limitation of extension, for the reason that they are all fixed to only one data structure and thus can't extend any more. 3.5.2. Data Type Extensibility Description: Data type extensibility means that data types defined by modeling languages can be extended easily, so that it can support various kinds of data both simply and clearly. Motivation: With the development of network management, more and more new data types must be added to satisfy different data presentations. Hence, data type extensibility of the modeling language becomes essential. Although there are nowadays not many fixed rules for extensibility when designing data types, the modeling language still need to try its best to indicate it for further implementation. Application: Strictly speaking, none of the languages have data type extensibility. But some languages have extensibility from a partial point of view. For example, SMI has some extension above basic data types named Textual-Convention, which defines 13 kinds of data types, and SMIng has similar function. Xiao & Xu Expires December 23, 2007 [Page 16] Internet-Draft Evaluation on Data Modeling Languages June 2007 3.5.3. Element and Attribute Extensibility Description: Element and attribute extensibility means that types of element nodes and attributes defined by modeling languages 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 must be done easily. Motivation: More and more objects of various kinds need to be managed in future network management, which means the requirement for adding object types. Hence, future management data modeling languages should have the ability to extend the types of elements with different attributes, in order that everyone can manage the objects simply and effectively. For example, there are many macros defined by SMIv2 such as OBJECT-TYPE, OBJCET-GROUP, MODULE- COMPLIANCE and each of them represents a type of element. With the development of Internet, it is necessary to add new types of element and more attributes about each element based on some aspects like access and status. Application: Up to now, none of existing data modeling languages has the ability to extend new elements and attributes. 3.6. Others 3.6.1. Considerations for Configuration Description: The data model specified for a device must identify what is state data and what is configuration data without the need for separating container elements. An optional way to do this is by tagging each element definition in the information and data model with a "category" indicating whether the element is state data or configuration data. In addition, granular lock mechanism and access control on configuration data should also be considered. Motivation: It is necessary to make a clear distinction between configuration data and data that describes operational state and statistics. As for some devices, it is quite hard to determine which parameters Xiao & Xu Expires December 23, 2007 [Page 17] Internet-Draft Evaluation on Data Modeling Languages June 2007 are administratively configured and which are obtained via mechanisms such as routing protocols. For configuration management, an implementation must 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. Application: Existing data modeling languages and data models are not considered adequately. SMIv2 is the IETF standard for network management data modeling, but it is hardly specified for configuration management due to its limitations. 3.6.2. Access Control Granularity of Data Model Description: Access control granularity of data model refers to the certain degree of detail and precision of accessing data from data model. There are mainly two levels of granularity, which are a coarse one and a fine one. Using coarse access control granularity, a bulk of data can be retrieved and edited from data model, such as getting the whole data from the MIB. On the contrary, a fine granularity refers to a detailed operation to a small part of data, such as elements or attributes. Motivation: Both coarse granularity and fine granularity have their advantages and disadvantages. The implementation of coarse granularity is simple, while the reusability is very poor. Hence, the tradeoff between coarse granularity and fine granularity becomes quite essential. When something is modeled from a single perspective, granularity is often not very important. Granularity becomes an important issue for data modeling, when merging and mapping information across multiple systems or data stores. The reason lies in the fact that, granularity may not match in the process of mapping. Application: In SMI, the access control is defined at three levels: read-only, write-only and read-write. For instance, data with attribute "read-only" can just be read from the MIB but can't be edit any more. In future research, when defining elements in existing data Xiao & Xu Expires December 23, 2007 [Page 18] Internet-Draft Evaluation on Data Modeling Languages June 2007 models, attributes like "minOccurs" (the minimum occurs for elements) and "maxOccurs" (the maximum occurs for elements) must be used to specify the degree of detail and precision number of elements. Xiao & Xu Expires December 23, 2007 [Page 19] Internet-Draft Evaluation on Data Modeling Languages June 2007 4. Comparison Table 1 shows which modeling approach each existing data modeling language adopts. Note that, in Table 1, we especially distinguish object-based approach 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 approaches adopted by each language Table 2 shows a summary of all compared languages stated in Section 2, in term of the criteria for evaluation listed in Section 3 except for modeling approaches, the comparison in which has been presented in Table 1. Our measurement is classified as the following four levels. a. A minus sign (-) means that the language does not have such a character b. An asterisk sign (*) denotes that the language has little of the character c. A plus sign (+) is used when the language has much of this character d. Two plus sign (++) is placed when the language completely possesses the character As is shown in Table 2, some facts in terms of criteria can gained as follows. a. Almost all the existing data modeling languages have little or much of the characters in expressiveness and readability, which indicates that these two features are quite important and have been taken into consideration fairly earlier than others. Xiao & Xu Expires December 23, 2007 [Page 20] Internet-Draft Evaluation on Data Modeling Languages June 2007 b. Some facets of the interoperability are involved in particular languages. For example, all of the languages attach the importance to semantic interoperability by adopting different methods to semantic expressiveness, and only SMI, MIF, MOF/CIM with their different versions take backward compatibility into consideration. But characters such as protocol independence and naming independence are hardly owned by any language with exception of SMIng and MIF but just focusing on the former one. c. None of the languages pay much attention to extensibility and considerations for configuration and few of them lay emphasis on access control granularity of data model. With development of the Internet, proposed characters of data modeling languages might not meet the requirement of such a complex network and its corresponding data model. As a result, new criteria as the unimplemented criteria above should be seriously considered nowadays for the implementation of future data models and network management protocols. From another viewpoint of languages themselves, it can also be concluded from Table 2 that, SMIng is the language with best implementation of most criteria especially in both syntax and semantics. Additionally, SMI has dominance in syntactic expressiveness such as data type diversity and extensibility, while MOF/CIM is with the best semantic expressiveness. Xiao & Xu Expires December 23, 2007 [Page 21] Internet-Draft Evaluation on Data Modeling Languages June 2007 +------------------------------+------+-----+-----+---------+-------+ | Language | GDMO | SMI | MIF | MOF/CIM | SMIng | +------------------------------+------+-----+-----+---------+-------+ | Expressiveness | | | | | | | | | | | | | | Information Integrity | * | * | * | + | + | | | | | | | | | Data Type Diversity | - | * | - | - | * | | | | | | | | | Readability | | | | | | | | | | | | | | Human Readability | * | * | * | + | + | | | | | | | | | Machine Readability | * | * | * | * | * | | | | | | | | | Interoperability | | | | | | | | | | | | | | Backward Compatibility | - | + | * | * | - | | | | | | | | | Protocol Independence | - | - | + | - | * | | | | | | | | | Naming Independence | - | - | - | - | - | | | | | | | | | Semantics Interoperability | + | * | * | + | + | | | | | | | | | Extensibility | | | | | | | | | | | | | | Data Structure | - | - | - | - | - | | Extensibility | | | | | | | | | | | | | | Data Type Extensibility | - | * | - | * | * | | | | | | | | | Element and Attribute | - | - | - | - | - | | Extensibility | | | | | | | | | | | | | | Others | | | | | | | | | | | | | | Considerations for | - | - | - | - | - | | Configuration | | | | | | | | | | | | | | Access Control Granularity | - | * | - | - | * | | of Data Model | | | | | | +------------------------------+------+-----+-----+---------+-------+ Table 2: Summary of the compared characteristics Xiao & Xu Expires December 23, 2007 [Page 22] Internet-Draft Evaluation on Data Modeling Languages June 2007 5. Future Perspectives 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, with the development of next generation networks, networks become more and more complex and heterogeneous as well, so data models based on existing data modeling languages don't seem to have enough ability to meet the requirement towards next generation network management. The deficiencies of existing data modeling languages are clearly shown in Section 4, the main point of which is summarized as follows. a. Their data types are insufficient. As is known to all, the data types of traditional data models are too simple, since they aim at simple networks. Mostly, these data models are lack of complex data types such as object type, structure type, multi dimension table type and so on, which are greatly required in next generation network management. b. Their machine readability is fairly poor, which is going against the automatic requirement of next generation network management. c. Their interoperability has not been realized, though some efforts have been made. Traditional data models are designed especially for certain protocols, always have a close relationship with specific operations of the protocols, and take their individual modeling approaches, naming rules and the way of expression, all of which lead to the poverty of universality. d. Their extensibility is quite deficient, especially in the two parts named "structure extensibility" and "element and attributes extensibility". e. Traditional data models put emphasis on performance management, but take little consideration on configuration management. Future data models should strengthen this part in order to satisfy a higher demand of configuration management. f. In traditional data models, the mechanism of access control is so simple that it cannot satisfy the demands of network security and adapt to complex network operations. As a matter of fact, the level of network security requirements is being higher and higher with the expansion of next generation networks. Due to the drawbacks of previous data modeling languagesGBP[not]IETF has taken XML-based data model into consideration, especially in IETF NETCONF WG, which proposes a network configuration management Xiao & Xu Expires December 23, 2007 [Page 23] Internet-Draft Evaluation on Data Modeling Languages June 2007 protocol that uses a data encoding based on the XML and the data model of NETCONF is described using XML Schema Definition (XSD) or other XML Schema languages. The readability, interoperability, extensibility and other properties of a data model described by XSD surpass previous data models in many cases. For instance, it presents more data types, including complex ones, such as a hierarchical one, than SMI whose capability is limited to simple tables of scalar data types. But the semantic expressiveness of XSD isn't stronger enough and is even weaker than MOF/CIM. There are some draft specifications for a XML-based data model framework and related work in NETCONF. However, there are no data models yet, since it is quite complex to consider and design a new data modeling language and its corresponding data model. Note that, SMIv2 is known as a data modeling language for SNMP-based network management and MIB is the form for organizing management data modules. And it has been supplemented by a lot of proprietary MIB modules defined by different device vendors. Discarding MIB objects and SMI clauses when designing a new data model does not reduce this benefit, since intrinsically the objects are SMI items specified according to the Internet-Standard Management Framework and referenced in a standard management module. Currently, the members and experts in OPS (Operations & Management) Area of IETF are considering SMI-to-XML conversion and XSD for accessing SMIv2 data models. The relevant smidump and mibdump in LIBSMI are the most well-known tools and implementations. But both of them don't realize the semantic correlation among MIB modules and the conversion of some special macro nodes. At present, there are still some details worth discussing in OPS Area and NETCONF WG. For instance, in one of the Li Y's drafts, it mentions extended capability to access MIB in NETCONF, while in his another draft, it discusses how to inherit and develop data types and textual conventions in SMI. However, there are still a lot to do. Though currently data modeling is under hot research, it is now still an inchoate period for the research on next generation data modeling languages. Under this background, it is necessary to put forward a framework of evaluation on data modeling languages. We argue that a well-designed framework of evaluation plays an important role in the research on network management data modeling languages. The criteria of evaluation on data modeling languages put forward in Section 3 include some essential aspects about the languages and their corresponding data models, which will construct the rudiment of the framework for evaluation on management data modeling languages. By using the framework for evaluation, on one hand, existing data modeling languages can be evaluated objectively and the experience in the evaluation process may be used in future which has been stated in Section 4; on the other hand, some important characters of data Xiao & Xu Expires December 23, 2007 [Page 24] Internet-Draft Evaluation on Data Modeling Languages June 2007 modeling languages can be chosen in the blueprint of next generation data modeling languages. Thus in this way, it makes the research more pertinent and helps to accelerate the building progress of data models for next generation network management, which are of great guidance significance toward the study and design of next generation data modeling languages. To sum up, we argue that next generation data modeling language should achieve the following goals. The new data modeling language should have the ability to integrate all the advantages of existing ones, and complement their disadvantages and inconsideration of corresponding data models. Especially, it must be combined with the realistic requirement of next generation network management, so that the new data model not only satisfies the management requirement nowadays, but also adapts to future trend. For the sake of prospecting next generation data modeling language, we conduct an integrated consideration according to the proposed criteria in Section 3 as follows. a. As for modeling approaches, new 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, future language should avoid implementing the same function with simple combination of these approaches. b. When expressiveness is mentioned, new data modeling language should strengthen two aspects of expressiveness, which are information integrity and data type diversity. c. In the aspect of readability, new data modeling language should strongly strengthen the machine readability on the basis of guaranteeing good human readability. Good machine readability of data modeling languages also requires a better semantic expressiveness, for example, the behavior defined by modeling languages should be well understood, so that the automation requirements towards next generation network management may be promising. d. As for interoperability, new data modeling language should not only achieve backward compatibility, but also strengthen protocol independence, naming independence and semantic interoperability. e. As to extensibility, it is required that new data modeling language should implement three aspects of extensibility including data structure, data types, element and attribute. Xiao & Xu Expires December 23, 2007 [Page 25] Internet-Draft Evaluation on Data Modeling Languages June 2007 f. Taking configuration into consideration, in order to achieve the aim of bulking configuration, configuration data and state data should be separated by a means supported by new data modeling language. g. As regards to access control granularity of data model, existing data modeling languages are, generally speaking, very coarse in the aspect of accessing control, while new data modeling language requires fine granularity of access control, so as to meet the demands of security and complex operations towards next generation network management. Certainly, these criteria above are a general consideration on future data modeling languages, which seem to be an ideal state. It is possible that, next generation data modeling language may not obtain processing qualities of all the positive characters. Thus in this case, we can select more important properties for tradeoff and consider the requirements of next generation network management. Then the puzzling problem comes how to select a best set of criteria from the numerous criteria and set their weight individually to form the whole framework for evaluation. Xiao & Xu Expires December 23, 2007 [Page 26] Internet-Draft Evaluation on Data Modeling Languages June 2007 6. Security Considerations None. Xiao & Xu Expires December 23, 2007 [Page 27] Internet-Draft Evaluation on Data Modeling Languages June 2007 7. IANA Considerations None. Xiao & Xu Expires December 23, 2007 [Page 28] Internet-Draft Evaluation on Data Modeling Languages June 2007 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. Xiao & Xu Expires December 23, 2007 [Page 29] Internet-Draft Evaluation on Data Modeling Languages June 2007 8.2. Informative References [I-D.li-ngo-access-mib] Li, Y. and D. Harrington, "Accessing MIBs using NETCONF", draft-li-ngo-access-mib-01 (work in progress), June 2007. [I-D.romascanu-netconf-datatypes] Romascanu, D., "Datatypes for Netconf Data Models", draft-romascanu-netconf-datatypes-02 (work in progress), May 2007. [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet- Standard Management Framework", RFC 3410, December 2002. Xiao & Xu Expires December 23, 2007 [Page 30] Internet-Draft Evaluation on Data Modeling Languages June 2007 Authors' Addresses 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 Hui Xu Institute of Computer Network and Communication Huazhong Normal University WuHan, HuBei 430079 P.R.China Phone: +86 027 6786 6108 Email: xuhui_1004@mails.ccnu.edu.cn Xiao & Xu Expires December 23, 2007 [Page 31] Internet-Draft Evaluation on Data Modeling Languages June 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). 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. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Xiao & Xu Expires December 23, 2007 [Page 32]