Network Working Group XQ. Wu Internet-Draft YN. Chang Intended status: Experimental DB. Xiao Expires: March 15, 2010 CCNU INC September 11, 2009 Conversion of MIB to XSD for NETCONF draft-xiao-conversion-dm-02 Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and 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 March 15, 2010. Copyright Notice Copyright (c) 2009 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 Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Wu, et al. Expires March 15, 2010 [Page 1] Internet-Draft Conversion of MIB to XSD for NETCONF September 2009 Abstract NETCONF needs a data model for its process of standardization. This documentation defines a standard expression of SMI MIBs in XSD for NETCONF to ensure uniformity, general interoperability and reusability of existing MIBs. In addition, we define a XML schema to give a restriction and validation to translated XSD files. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.1. Requirements for NETCONF . . . . . . . . . . . . . . . . . 7 3.2. Requirements for MIB . . . . . . . . . . . . . . . . . . . 7 4. Mapping of data types . . . . . . . . . . . . . . . . . . . . 8 4.1. SMI base datatypes . . . . . . . . . . . . . . . . . . . . 8 4.2. Other datatypes . . . . . . . . . . . . . . . . . . . . . 9 5. Mapping of MIB structure . . . . . . . . . . . . . . . . . . . 11 6. Mapping and application of Marco clauses . . . . . . . . . . . 12 6.1. the mapping of MODULE-IDENTITY macro . . . . . . . . . . . 12 6.2. the mapping of OBJECT-IDENTIFIER macro . . . . . . . . . . 14 6.3. the mapping of OBJECT-TYPE macro . . . . . . . . . . . . . 14 6.3.1. the mapping of scalar nodes and columnar nodes . . . . 14 6.3.2. the mapping of entry nodes . . . . . . . . . . . . . . 16 6.4. the mapping of NOTIFICATION macro . . . . . . . . . . . . 18 7. A XML schema for translated XSD . . . . . . . . . . . . . . . 21 8. Security Considerations . . . . . . . . . . . . . . . . . . . 22 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 10.1. Normative References . . . . . . . . . . . . . . . . . . . 24 10.2. Informative References . . . . . . . . . . . . . . . . . . 24 Appendix A. SMI-Data types.xsd . . . . . . . . . . . . . . . . . 25 Appendix B. A SMI.xsd for NETCONF . . . . . . . . . . . . . . . . 38 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 43 Wu, et al. Expires March 15, 2010 [Page 2] Internet-Draft Conversion of MIB to XSD for NETCONF September 2009 1. Introduction [NETCONF] can be conceptually partitioned into four layers: +------------+-----------------------------+ | Layer | Example | +------------+-----------------------------+ | Content | Configuration data | | | | | Operations | , | | | | | RPC | , | | | | | Transport | BEEP, SSH, TLS | +------------+-----------------------------+ The last three layers of NETCONF have been already standardized in RFC4741, RFC4742, RFC4743 and RFC4744. However, there isn't a standard data modeling language or a standard data model for NETCONF content layer. If we can't make the content layer of NETCONF standardized, every vendor can define its own data model, which will cause trouble and confusion in understanding the syntax and semantics of data model in communication. Thus the NETCONF won't be applied widely as SNMP in future and the NETCONF defined in RFC4741 will have no sense. The work to standardize the content layer of NETCONF is of two ways: 1. Create a new data modeling language and then a new data model for NETCONF. YANG is a new data modeling language which defines a new SMI for NETCONF containing datatypes, node statement, and syntax specification and so on. The NCX is somewhat like YANG. It not only defines the new SMI for NETCOFN but also has supplemented some ability to NETCONF protocol. All these new languages are under discussion, which means that these will be a longer term effort to create a solid SMI and then remodel some of the key data to be carried. 2. Conversion from MIB to XSD. This is being done by XSDMI group. The XSDMI effort is designed to produce a XSD specification by translating from MIB. NETCONF configuration is an improvement of CLI, not SNMP which has been widely used for performance,monitoring and fault management. However, some MIB-based monitoring data have become part of the operational framework of many networks. And many of the data names and meanings have been widely accepted by vendors for years. For a long run, to establish a new data modeling language and new Wu, et al. Expires March 15, 2010 [Page 3] Internet-Draft Conversion of MIB to XSD for NETCONF September 2009 data model is much better than simple conversion of MIB to XSD. However, its standardization will need a very long time and plenty of effort. On the other hand, IETF has spent over 20 years to make SMI MIB standardization and many vendors also have made great effort to supplement these MIBs which have been widely used in current network management systems. Most of these MIB data are focused on monitoring information, such as statistics and state. Although the NETCONF protocol are aiming at establishing a new data model for configuration management, it still need to benefit from reusing existing MIB objects for monitoring the configured technology or checking the state following configuration. It will be a waste to abandon these MIB modules without adequate reasons. So in current times, to convert SMI MIB module to XSD is more feasible than creating a new data model and reusing MIB for NETCONF content layer can be a transitional way before new language and new data model emerge. NETCONF uses XML-based data encoding for the configuration data as well as the protocol messages. Under such background, we should provide a standard translation to make using the MIB's managed objects with XSD easier. The whys and wherefores that XSD is considered a better way to be the data modeling language for NETCONF are as follows: 1. Data models which expressed by XSD can be accessed by NETCONF and any XML-based protocols such as IDMEF, XCAP, IDMEF, and ATOM, which improves the interoperability. 2. XSD can generate any diverse data types, multi-dimensional arrays and can be used in real world devices which employ hash-tables which don't exist in SMI. 3. Many people are familiar with XML and XSD. There are many standard technologies about XML and will useful for protocol development. The XSDMI BOF proposed the creation of a WG to develop : a. the XSD equivalents of datatypes and textual conventions from SMIv2. b. algorithms to translate MIB module specifications into XSD equivalents. c. Netconf operations to access MIB data. d. a draft documenting security requirements for protocols accessing the MIB. Wu, et al. Expires March 15, 2010 [Page 4] Internet-Draft Conversion of MIB to XSD for NETCONF September 2009 Based on the XSDMI's and previous smidump's work, this documentation defines a standard expression of SMI MIBs in XSD for NETCONF to ensure uniformity and general interoperability and reusability of existing MIBs. In addition, we define a XML schema to give a restriction and validation to translated XSD files. Wu, et al. Expires March 15, 2010 [Page 5] Internet-Draft Conversion of MIB to XSD for NETCONF September 2009 2. Conventions 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]. Sections requiring further editing are identified by [TODO] markers in the text. Points requiring further WG research and discussion are identified by [DISCUSS] markers in the text. Wu, et al. Expires March 15, 2010 [Page 6] Internet-Draft Conversion of MIB to XSD for NETCONF September 2009 3. Requirements This section describes some basic restrictions on translated XSD from MIBs. 3.1. Requirements for NETCONF NETCONF has an obvious advantage of its separation of configuration and state data. Configuration data is the set of writable data that is required to transform a system from its initial default state into its current state. State data is the additional data on a system that is not configuration data such as read-only status information and collected statistics. First advantage lies in its separation of configuration data and state data, which can avoid the problems that comparisons of configuration data sets would be dominated by irrelevant entries such as different statistics and incoming data could contain nonsensical requests such as attempts write read-only data. Our target is to establish a data model translated from MIB to XSD for NETCONF, so we should follow the requirements of NETCONF and need a separation of configuration and state data. Although MIBs are mostly used for monitor and don't have explicit separation of them in any form of label, we can only use label to distinguish them. We consider data whose value are "not- accessible", "read-only" as state data's and whose value are "write-only", "read-write", "read-create" as configuration. [TODO]More requirements need to be standardized for NETCONF content, even a configuration network management. 3.2. Requirements for MIB Two goals of this work are instrumentation reuse and semantics reuse. The IETF has spent twenty years developing standard managed objects, and vendors have supplemented that with proprietary managed objects, all written using a standard way expressing the syntax and semantics. So it is better to preserve that work and make it available for XML- based messaging, which means that we should follow the syntax and semantics rule of SMI. Wu, et al. Expires March 15, 2010 [Page 7] Internet-Draft Conversion of MIB to XSD for NETCONF September 2009 4. Mapping of data types 4.1. SMI base datatypes This section defines the IETF standard expression of SMI base datatypes in XSD.[I-D.li-mib-convert] has given an expression for SMI base datatypes, and there are few shortcomings of it: 1. It isn't covering all datatypes of SMI base types, which can't be incompatible with all different kind of vendors' device. 2. Some of the datatypes' names are different with SMI base datatypes, which can't form a semantic merge of different devices. In this section, the datatypes defined in RFC2578 and RFC2579 should be all translated in derived data types in XSD that the number and names of data types are the same to SMI. The data types are on the base of restriction on build-in data types in XSD. It not only preserves the unambiguous of data types but also reduces the changes that vendors make to be suitable for translated data types. Then the translated data types are written as a fixed file in order that if these data types are used in some module, the source module can directly import the only one file enough. There are totally 24 kind of datatypes included in RFC2578 and RFC2579 except that some datatypes have been obsoleted such as "Opaque" and "InstancePointer". We can divide these datatypes into five groups by the way they derived from base types in XSD: 1. Some types can be equally placed by the build-in datatypes in XSD. What the difference between translated SMI datatypes and XSD datatypes is only the name of them. For example, Integer, Unsigned32, Counter32, Counter64, Gauge32, TimeTicks, OCTET STRING are of this type. 2. Some use pattern restriction on the base types to express translated datatypes which may not be unique such as IPAddress, MacAddress, PhyAddress, DateAndTime, Objectidentifier. 3. Some use enumeration way to express datatypes. Such as "StorageType", "RowStatus", "TruthValue". 4. Some use range restriction to express them such as "TAddress", "DisplayString", "TestAndIncr", "TimeInterval". 5. Some derives from defined datatypes such as "TimeStamp", "AutonomousType", "VariablePointer", "RowPointer", "Tdomain". Wu, et al. Expires March 15, 2010 [Page 8] Internet-Draft Conversion of MIB to XSD for NETCONF September 2009 The full definition of datatypes' schema is shown in Appendix A. [Discuss] Is there any need to express datatypes of OID and those derived from OID? NETCONF-based network management needn't OID to locate the managed objects. Instead, they use "Subtree" or "XPATH" to find them. [Discuss] How we make the expression of all datatypes standard and unique for datatypes that use pattern restriction, for example, the regular expression of IPAddress isn't unique, then how we deal with such thing? [TODO] We should tell the protocol-independent datatypes from those protocol-special datatypes. NETCONF content is specified to protocol-independent thus its datatypes should also follow the rule. 4.2. Other datatypes Other data types are mostly defined by vendors for their special use and are all in form of Textual Conventions. An example is described as follows: OwnerString ::= TEXTUAL-CONVENTION DISPLAY-HINT "255a" STATUS deprecated DESCRIPTION "This data type is used to model an administratively assigned name of the owner of a resource." SYNTAX OCTET STRING (SIZE(0..255)) The SYNTAX clause defines abstract data structure corresponding to the textual convention. We only use to restrict the base type. The translated XSD is representing as follows: 255a Wu, et al. Expires March 15, 2010 [Page 9] Internet-Draft Conversion of MIB to XSD for NETCONF September 2009 This data type is used to model an administratively assigned name of the owner of a resource. [Discuss] How we define a standard for the expression of restriction in TCs for auto conversion? For example, sometimes we can use "minInclusive" and "maxInclusive" to express the range of values, use "minlength" and "maxlength" to express the range of length, and use "pattern" to define regular expression. Wu, et al. Expires March 15, 2010 [Page 10] Internet-Draft Conversion of MIB to XSD for NETCONF September 2009 5. Mapping of MIB structure This section gives a flattened structure of translated XSD files from SMI MIBs. Previous MIB tree has so many layers that many of them are of little use and some of the middle node are of no use only for the organization of its children. Until now, there are many tools used to converting MIBs, and one of the popular tools is smidump. Instead of the high hierarchy of MIB tree, it uses a flattened structure which only has four levels: the root of the document level, the agent information description level, the third level representing either the containers of scalar nodes or the entry of table nodes, and the fourth level of all leaf nodes including scalars nodes or columnar nodes. It omits many middle nodes and the conformance statement. However, it also has following limits when used in NETCONF content layer: 1. It can't satisfy the requirements of NETCONF protocol that the configuration and state data sho1uld be separated. 2. The second layer is not needed in NETCONF protocol. In our draft, we also optimize the complex structure of MIB to a flattened and simple structure especially for NETCONF and its separation of configuration and state data. The new structure still reserves the relationship between leaf nodes and their parents as following four layers: 1. The root of the document level. 2. Three branches of the root named "configuration", "state" and "notification". 3. The third level representing either the containers of scalar nodes or the entry of table nodes or the notification nodes. 4. The fourth level of all leaf nodes including scalars nodes or columnar nodes. Wu, et al. Expires March 15, 2010 [Page 11] Internet-Draft Conversion of MIB to XSD for NETCONF September 2009 6. Mapping and application of Marco clauses In the flattened structure of four levels,it includes nodes which are defined by MODULE-IDENTITY macro, OBJECT- IDENTIFIER macro, OBJECT- TYPE macro and NOTIFICATION-TYPE macro. We translate all the macro types as follows: 6.1. the mapping of MODULE-IDENTITY macro Some mibs have MODULE-IDENTITY macro,which is used to describe the entire block of information for top-level description of the mib.We translate MODULE-IDENTITY macro as information of root element.Note that the LAST-UPDATED, ORGANIZATION![cents]CONTACT- INFO![cents]REVISION and the corresponding label elements DESCRIPTION are all omitted in the translated XSD,and the DESCRIPTION which is the introduction of the mib is translated as ,which is the child of . The following is an example,which is from IF-MIB: ifMIB MODULE-IDENTITY LAST-UPDATED "200006140000Z" ORGANIZATION "IETF Interfaces MIB Working Group" CONTACT-INFO " Keith McCloghrie Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134-1706 US 408-526-5260 kzm@cisco.com" DESCRIPTION "The MIB module to describe generic objects for network interface sub-layers. This MIB is an Wu, et al. Expires March 15, 2010 [Page 12] Internet-Draft Conversion of MIB to XSD for NETCONF September 2009 updated version of MIB-II's ifTable, and incorporates the extensions defined in RFC 1229." REVISION "200006140000Z" DESCRIPTION "Clarifications agreed upon by the Interfaces MIB WG, and published as RFC 2863." REVISION "199602282155Z" DESCRIPTION "Revisions made by the Interfaces MIB WG, and published in RFC 2233." REVISION "199311082155Z" DESCRIPTION "Initial revision, published as part of RFC 1573." ::= { mib-2 31 } The XSD represents as follows: The MIB module to describe generic objects for network interface sub-layers. This MIB is an updated version of MIB-II's ifTable, and incorporates the extensions defined in RFC 1229. Wu, et al. Expires March 15, 2010 [Page 13] Internet-Draft Conversion of MIB to XSD for NETCONF September 2009 6.2. the mapping of OBJECT-IDENTIFIER macro The container element containing scalar elements which appear at most once.This kind of element is derived from an OBJECT IDENTIFIER or OBJECT IDENTIFIER assignment, of which the latter is the supplement of the former.The information of OBJECT-IDENTIFIER macro contained is relatively simple.We translate OID as ,which is placed under ,as a child of . The following is an example,which is from mib of RFC1213: system OBJECT IDENTIFIER ::= { mib-2 1 } The XSD represents as follows: .1.3.6.1.2.1.1 6.3. the mapping of OBJECT-TYPE macro In the bottom of the flatted structure,there is scalar nodes and the columnar nodesGBP[not]which are defined in macro OBJECT-TYPE.And entry nodes are also defined in macro OBJECT-TYPE. 6.3.1. the mapping of scalar nodes and columnar nodes For this type of nodes, UnitPart,ReferPart,IndexPart,DefValPart are all omitted in translated XSD.We translate MAX-ACCESS,STATUS as and ,which are placed under ,and is mapping as . The following is an example,which is from mib of RFC1213: sysObjectID OBJECT-TYPE Wu, et al. Expires March 15, 2010 [Page 14] Internet-Draft Conversion of MIB to XSD for NETCONF September 2009 SYNTAX OBJECT IDENTIFIER ACCESS read-only STATUS mandatory DESCRIPTION "The vendor's authoritative identification of the network management subsystem contained in the entity. This value is allocated within the SMI enterprises subtree (1.3.6.1.4.1) and provides an easy and unambiguous means for determining `what kind of box' is being managed. For example, if vendor `Flintstones, Inc.' was assigned the subtree 1.3.6.1.4.1.4242, it could assign the identifier 1.3.6.1.4.1.4242.1.1 to its `Fred Router'." ::= { system 2 } The XSD represents as follows: read-only mandatory The vendor's authoritative identification of the Wu, et al. Expires March 15, 2010 [Page 15] Internet-Draft Conversion of MIB to XSD for NETCONF September 2009 network management subsystem contained in the entity. This value is allocated within the SMI enterprises subtree (1.3.6.1.4.1) and provides an easy and unambiguous means for determining `what kind of box' is being managed. For example, if vendor `Flintstones, Inc.' was assigned the subtree 1.3.6.1.4.1.4242, it could assign the identifier 1.3.6.1.4.1.4242.1.1 to its `Fred Router'. 6.3.2. the mapping of entry nodes The translations of entry nodes are more or less alike.But There are two differences:1)entry nodes can appear many times.So,we add two attributes and to the translated XSD.2)we need to use index clause to read entry node,we add element to mark it.But if it is an enternal index,add instead. The following is an example,which is from mib of RFC1213: ifEntry OBJECT-TYPE SYNTAX IfEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "An interface entry containing objects at the subnetwork layer and below for a particular Wu, et al. Expires March 15, 2010 [Page 16] Internet-Draft Conversion of MIB to XSD for NETCONF September 2009 interface." INDEX { ifIndex } ::= { ifTable 1 } The XSD represents as follows: not-accessible mandatory ifIndex An interface entry containing objects at the subnetwork layer and below for a particular interface. The following is an example from mib of IF-MIB,which is an entry node contain an enternal index: ifXEntry OBJECT-TYPE SYNTAX IfXEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION Wu, et al. Expires March 15, 2010 [Page 17] Internet-Draft Conversion of MIB to XSD for NETCONF September 2009 "An entry containing additional management information applicable to a particular interface." AUGMENTS { ifEntry } ::= { ifXTable 1 } The XSD represents as follows: not-accessible current ifIndex An entry containing additional management information applicable to a particular interface. 6.4. the mapping of NOTIFICATION macro The notification node is used while the agent is off working defined by NOTIFICATION-TYPE macro.ReferPart is omitted in translated xsd, STATUS,OBJECTS are translated as and ,which are placed under ,as a child of .And DESCRIPTION is translated as ,which is placed under . The following is an example,which is from IF-MIB: linkDown NOTIFICATION-TYPE Wu, et al. Expires March 15, 2010 [Page 18] Internet-Draft Conversion of MIB to XSD for NETCONF September 2009 OBJECTS { ifIndex, ifAdminStatus, ifOperStatus } STATUS current DESCRIPTION "A linkDown trap signifies that the SNMP entity, acting in an agent role, has detected that the ifOperStatus object for one of its communication links is about to enter the down state from some other state (but not from the notPresent state). This other state is indicated by the included value of ifOperStatus." ::= { snmpTraps 3 } The XSD represents as follows: current ifIndex, ifAdminStatus, ifOperStatus A linkDown trap signifies that the SNMP entity, acting in an agent role, has detected that the ifOperStatus object for one of its communication links is about to enter the down state from some other state (but not Wu, et al. Expires March 15, 2010 [Page 19] Internet-Draft Conversion of MIB to XSD for NETCONF September 2009 from the notPresent state). This other state is indicated by the included value of ifOperStatus. Wu, et al. Expires March 15, 2010 [Page 20] Internet-Draft Conversion of MIB to XSD for NETCONF September 2009 7. A XML schema for translated XSD Until now, there are many ways of translating MIB to XSD with different structure or content type, so there should be a schema to restrict them and make them follow a rule, when the rule changes, the translated XSD should also change. The XML schema for translated XSD is as Appendix B. From Appendix B, we can see that Many elements are defined as global elements so that they can be referred many times, for example, , , , and so on. It reduces the waste of repeat definition and makes them more readable and easily understood. Wu, et al. Expires March 15, 2010 [Page 21] Internet-Draft Conversion of MIB to XSD for NETCONF September 2009 8. Security Considerations None. Wu, et al. Expires March 15, 2010 [Page 22] Internet-Draft Conversion of MIB to XSD for NETCONF September 2009 9. IANA Considerations None. Wu, et al. Expires March 15, 2010 [Page 23] Internet-Draft Conversion of MIB to XSD for NETCONF September 2009 10. References 10.1. Normative References [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. [RFC4741] Enns, R., "NETCONF Configuration Protocol", RFC 4741, December 2006. 10.2. Informative References [I-D.bjorklund-netconf-yang] Bjorklund, M., "YANG - A data modeling language for NETCONF", draft-bjorklund-netconf-yang-02 (work in progress), February 2008. [I-D.li-mib-convert] Li, Y., "Using Smidump to Convert MIB to XSD", draft-li-mib-convert-00 (work in progress), June 2007. [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. [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet-Standard Management Framework", RFC 3410, December 2002. Wu, et al. Expires March 15, 2010 [Page 24] Internet-Draft Conversion of MIB to XSD for NETCONF September 2009 Appendix A. SMI-Data types.xsd Converted from SMI core datatypes INTEGER from RFC 2578, page 8 and sec. 7.1.1. An enumerated integer is simply the 'enum' data type Wu, et al. Expires March 15, 2010 [Page 25] Internet-Draft Conversion of MIB to XSD for NETCONF September 2009 OCTET STRING from RFC 2578 IpAddress from RFC 2578 Wu, et al. Expires March 15, 2010 [Page 26] Internet-Draft Conversion of MIB to XSD for NETCONF September 2009 Counter32 from RFC 2578 Gauge32 from RFC 2578 Unsigned32 from RFC 2578 Wu, et al. Expires March 15, 2010 [Page 27] Internet-Draft Conversion of MIB to XSD for NETCONF September 2009 TimeTicks from RFC 2578 Counter64 from RFC 2578 Wu, et al. Expires March 15, 2010 [Page 28] Internet-Draft Conversion of MIB to XSD for NETCONF September 2009 Unsigned64 TC (missing) from RFC 2856. PhysAddress TC from RFC 2579. MacAddress TC from RFC 2579. Wu, et al. Expires March 15, 2010 [Page 29] Internet-Draft Conversion of MIB to XSD for NETCONF September 2009 TruthValue TC from RFC 2579. DateAndTime TC from RFC 2579. Wu, et al. Expires March 15, 2010 [Page 30] Internet-Draft Conversion of MIB to XSD for NETCONF September 2009 TAddress TC from RFC 2579 DisplayString TC from RFC 2579. Wu, et al. Expires March 15, 2010 [Page 31] Internet-Draft Conversion of MIB to XSD for NETCONF September 2009 TestAndIncr TC from RFC 2579. RowStatus TC from RFC 2579. Wu, et al. Expires March 15, 2010 [Page 32] Internet-Draft Conversion of MIB to XSD for NETCONF September 2009 StorageType TC from RFC 2579. Wu, et al. Expires March 15, 2010 [Page 33] Internet-Draft Conversion of MIB to XSD for NETCONF September 2009 TimeStamp TC from RFC 2579. TimeInterval TC from RFC 2579. Wu, et al. Expires March 15, 2010 [Page 34] Internet-Draft Conversion of MIB to XSD for NETCONF September 2009 OBJECT IDENTIFIER from RFC 2578, libsmi v0.4.5 output. AutonomousType TC from RFC 2579, page 5. Wu, et al. Expires March 15, 2010 [Page 35] Internet-Draft Conversion of MIB to XSD for NETCONF September 2009 VariablePointer TC from RFC 2579. VariablePointer TC from RFC 2579, page 6. smidump v0.4.5,A pointer to a specific object instance. For example, sysContact.0 or ifInOctets.3. Wu, et al. Expires March 15, 2010 [Page 36] Internet-Draft Conversion of MIB to XSD for NETCONF September 2009 TDomain TC from RFC 2579, page 20. Wu, et al. Expires March 15, 2010 [Page 37] Internet-Draft Conversion of MIB to XSD for NETCONF September 2009 Appendix B. A SMI.xsd for NETCONF Wu, et al. Expires March 15, 2010 [Page 38] Internet-Draft Conversion of MIB to XSD for NETCONF September 2009 ... ... Wu, et al. Expires March 15, 2010 [Page 39] Internet-Draft Conversion of MIB to XSD for NETCONF September 2009 ... Wu, et al. Expires March 15, 2010 [Page 40] Internet-Draft Conversion of MIB to XSD for NETCONF September 2009 ... ... Wu, et al. Expires March 15, 2010 [Page 41] Internet-Draft Conversion of MIB to XSD for NETCONF September 2009 Wu, et al. Expires March 15, 2010 [Page 42] Internet-Draft Conversion of MIB to XSD for NETCONF September 2009 Authors' Addresses Xiaoqiong Wu Institute of Computer Network and Communication Huazhong Normal University WuHan, HuBei 430079 P.R. China Phone: +86 027 6136 8682 Email: marissblue@yahoo.com.cn Yanan Chang Institute of Computer Network and Communication Huazhong Normal University WuHan, HuBei 430079 P.R. China Phone: +86 027 6786 6108 Email: cyn_23@yahoo.com.cn Debao Xiao Institute of Computer Network and Communication Huazhong Normal University WuHan, HuBei 430079 P.R. China Phone: +86 027 6136 8682 Email: dbxiao@mail.ccnu.edu.cn Wu, et al. Expires March 15, 2010 [Page 43]