From: http://www.ietf.org/internet-drafts/draft-xiao-conversion-dm-00.txt Title: Conversion of MIB to XSD for NETCONF Reference: IETF Network Working Group, Internet Draft 'draft-xiao-conversion-dm-00' Date: March 26, 2008 I-D Tracker: http://ietfreport.isoc.org/idref/draft-xiao-conversion-dm/ See also: IETF Network Configuration (NETCONF) Working Group http://www.ietf.org/html.charters/netconf-charter.html IETF Netconf Status Pages http://tools.ietf.org/wg/netconf IETF NETCONF Working Group Information Pages (Simon Leinen) http://www.ops.ietf.org/netconf/ IETF NETCONF WG Mailing List http://ops.ietf.org/lists/netconf/ NETCONF Configuration Protocol http://www.ietf.org/rfc/rfc4741.txt IETF Operations and Management Area http://tools.ietf.org/area/ops ============================================================================== Network Working Group DB. Xiao Internet-Draft YN. Chang Intended status: Experimental CCNU INC Expires: September 27, 2008 March 26, 2008 Conversion of MIB to XSD for NETCONF draft-xiao-conversion-dm-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 September 27, 2008. Xiao & Chang Expires September 27, 2008 [Page 1] Internet-Draft Conversion of MIB to XSD for NETCONF March 2008 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 . . . . . . . . . . . 13 7. A XML schema for translated XSD . . . . . . . . . . . . . . . 15 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 10.1. Normative References . . . . . . . . . . . . . . . . . . . 18 10.2. Informative References . . . . . . . . . . . . . . . . . . 18 Appendix A. SMI-Data types.xsd . . . . . . . . . . . . . . . . . 19 Appendix B. A SMI.xsd for NETCONF . . . . . . . . . . . . . . . . 25 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29 Intellectual Property and Copyright Statements . . . . . . . . . . 30 Xiao & Chang Expires September 27, 2008 [Page 2] Internet-Draft Conversion of MIB to XSD for NETCONF March 2008 1. Introduction [NETCONF] can be conceptually partitioned into four layers: Layer Example +-------------+ +-----------------------------+ | Content | | Configuration data | +-------------+ +-----------------------------+ | | +-------------+ +-----------------------------+ | Operations | | , | +-------------+ +-----------------------------+ | | +-------------+ +-----------------------------+ | RPC | | , | +-------------+ +-----------------------------+ | | +-------------+ +-----------------------------+ | Transport | | BEEP, SSH, SSL, console | | Protocol | | | +-------------+ +-----------------------------+ 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, Xiao & Chang Expires September 27, 2008 [Page 3] Internet-Draft Conversion of MIB to XSD for NETCONF March 2008 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 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. Xiao & Chang Expires September 27, 2008 [Page 4] Internet-Draft Conversion of MIB to XSD for NETCONF March 2008 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. 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. Xiao & Chang Expires September 27, 2008 [Page 5] Internet-Draft Conversion of MIB to XSD for NETCONF March 2008 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. Xiao & Chang Expires September 27, 2008 [Page 6] Internet-Draft Conversion of MIB to XSD for NETCONF March 2008 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 "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. Xiao & Chang Expires September 27, 2008 [Page 7] Internet-Draft Conversion of MIB to XSD for NETCONF March 2008 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". Xiao & Chang Expires September 27, 2008 [Page 8] Internet-Draft Conversion of MIB to XSD for NETCONF March 2008 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: Xiao & Chang Expires September 27, 2008 [Page 9] Internet-Draft Conversion of MIB to XSD for NETCONF March 2008 255a 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. Xiao & Chang Expires September 27, 2008 [Page 10] Internet-Draft Conversion of MIB to XSD for NETCONF March 2008 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. The XSD for the top two levels is represented as follows: Xiao & Chang Expires September 27, 2008 [Page 11] Internet-Draft Conversion of MIB to XSD for NETCONF March 2008 ...... ...... ...... ...... Xiao & Chang Expires September 27, 2008 [Page 12] Internet-Draft Conversion of MIB to XSD for NETCONF March 2008 6. Mapping and application of Marco clauses There are three kinds of elements in the third level depicted as follows: 1. 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. 2. The entry of a table containing columnar elements which can appear multiple times. It is defined from the OBJECT-TYPE macro. 3. The notification node is used while the agent is off working defined by NOTIFICATION-TYPE macro. Both scalar and columnar objects are defined by the OBJECT-TYPE macro as the leaf nodes, thus their mappings are the same. The translations of OBJECT-TYPE, OBJECT IDENTIFIER, and NOTIFICATION- TYPE are more or less alike. The items included in their definition in SMI are translated into following items in XSD by the rule that the NETCONF manager only need to know the nodes' name not all information about them such as "description" while communicate with NETCOFN agent. We translate all the other information as in XSD whose children is and . The detailed mapping is shown as below. +--------------+-----------------+----------------------------------+ | SMI | XSD item | TYPE | | primitive | | | | item | | | +--------------+-----------------+----------------------------------+ | MAX-ACCESS | | OBJECT-TYPE | | | | | | STATUS | | OBJECT-TYPE, OBJECT IDENTIFIER | | | | | | DESCRIPTION | | OBJECT-TYPE, OBJECT IDENTIFIER, | | | | NOTIFICATION-TYPE | | | | | | INDEX | | OBJECT-TYPE | | | | | | OBJECTS | | NOTIFICATION-TYPE | | | | | Xiao & Chang Expires September 27, 2008 [Page 13] Internet-Draft Conversion of MIB to XSD for NETCONF March 2008 | OID | | OBJECT-TYPE, OBJECT IDENTIFIER, | | | | NOTIFICATION-TYPE | +--------------+-----------------+----------------------------------+ The following is an example: sysName OBJECT-TYPE SYNTAX DisplayString (SIZE (0..255)) ACCESS read-write STATUS mandatory DESCRIPTION "An administratively-assigned name for this managed node. By convention, this is the node's fully-qualified domain name." ::= { system 5 } Each OBJECT-TYPE macro is mapped to an element declaration. Note that the UNITS, REFERENCE and DefValPart items are all omitted in translated XSD, and the SYNTAX, MAX-ACCESS and STATUS are all translated as the child of the while the DESCRIPTION are under which is the child of with . The XSD represents as follows: read-write 1.3.6.1.2.1.1.5 mandatory An administratively-assigned name for this managed node.By convention, this is the node's fully-qualified domain name. The example above shows the translation of leaf nodes. If there is b middle node, we should only modify the type as "ComplexType", and we define leaf node under "ComplexType". Xiao & Chang Expires September 27, 2008 [Page 14] Internet-Draft Conversion of MIB to XSD for NETCONF March 2008 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. Xiao & Chang Expires September 27, 2008 [Page 15] Internet-Draft Conversion of MIB to XSD for NETCONF March 2008 8. Security Considerations None. Xiao & Chang Expires September 27, 2008 [Page 16] Internet-Draft Conversion of MIB to XSD for NETCONF March 2008 9. IANA Considerations None. Xiao & Chang Expires September 27, 2008 [Page 17] Internet-Draft Conversion of MIB to XSD for NETCONF March 2008 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. Xiao & Chang Expires September 27, 2008 [Page 18] Internet-Draft Conversion of MIB to XSD for NETCONF March 2008 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 OCTET STRING from RFC 2578 IpAddress from RFC 2578 Xiao & Chang Expires September 27, 2008 [Page 19] Internet-Draft Conversion of MIB to XSD for NETCONF March 2008 Counter32 from RFC 2578 Gauge32 from RFC 2578 Unsigned32 from RFC 2578 TimeTicks from RFC 2578 Counter64 from RFC 2578 Unsigned64 TC (missing) from RFC 2856. PhysAddress TC from RFC 2579 Xiao & Chang Expires September 27, 2008 [Page 20] Internet-Draft Conversion of MIB to XSD for NETCONF March 2008 MacAddress TC from RFC 2579 TruthValue TC from RFC 2579 DateAndTime TC from RFC 2579 TAddress TC from RFC 2579 Xiao & Chang Expires September 27, 2008 [Page 21] Internet-Draft Conversion of MIB to XSD for NETCONF March 2008 DisplayString TC from RFC 2579 TestAndIncr TC from RFC 2579 RowStatus TC from RFC 2579 Xiao & Chang Expires September 27, 2008 [Page 22] Internet-Draft Conversion of MIB to XSD for NETCONF March 2008 StorageType TC from RFC 2579 TimeStamp TC from RFC 2579 TimeInterval TC from RFC 2579 OBJECT IDENTIFIER from RFC 2578, libsmi v0.4.5 output. //GBP?GBP? Xiao & Chang Expires September 27, 2008 [Page 23] Internet-Draft Conversion of MIB to XSD for NETCONF March 2008 AutonomousType TC from RFC 2579, page 5. 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. TDomain TC from RFC 2579, page 20. Xiao & Chang Expires September 27, 2008 [Page 24] Internet-Draft Conversion of MIB to XSD for NETCONF March 2008 Appendix B. A SMI.xsd for NETCONF Xiao & Chang Expires September 27, 2008 [Page 25] Internet-Draft Conversion of MIB to XSD for NETCONF March 2008 Xiao & Chang Expires September 27, 2008 [Page 26] Internet-Draft Conversion of MIB to XSD for NETCONF March 2008 Xiao & Chang Expires September 27, 2008 [Page 27] Internet-Draft Conversion of MIB to XSD for NETCONF March 2008 Xiao & Chang Expires September 27, 2008 [Page 28] Internet-Draft Conversion of MIB to XSD for NETCONF March 2008 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 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 Xiao & Chang Expires September 27, 2008 [Page 29] Internet-Draft Conversion of MIB to XSD for NETCONF March 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. Xiao & Chang Expires September 27, 2008 [Page 30]