--- 1/draft-ietf-opsawg-smi-datatypes-in-xsd-04.txt 2009-03-27 18:12:06.000000000 +0100 +++ 2/draft-ietf-opsawg-smi-datatypes-in-xsd-05.txt 2009-03-27 18:12:06.000000000 +0100 @@ -1,140 +1,147 @@ Network Working Group B. Natale Internet-Draft MITRE -Intended status: Standards Track October 29, 2008 -Expires: May 2, 2009 +Intended status: Standards Track March 27, 2009 +Expires: September 27, 2009 Expressing SNMP SMI Datatypes in XML Schema Definition Language - draft-ietf-opsawg-smi-datatypes-in-xsd-04.txt + draft-ietf-opsawg-smi-datatypes-in-xsd-05.txt 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. + 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 May 2, 2009. + This Internet-Draft will expire on September 27, 2009. + +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. Abstract - This memo (when approved as a standards-track RFC) defines the IETF - standard expression of Structure of Management Information (SMI) base - datatypes in Extensible Markup Language (XML) Schema Definition (XSD) - language. The primary objective of this memo is to enable the - production of XML documents that are as faithful to the SMI as - possible, using XSD as the validation mechanism. + This memo defines the IETF standard expression of Structure of + Management Information (SMI) base datatypes in Extensible Markup + Language (XML) Schema Definition (XSD) language. The primary + objective of this memo is to enable the production of XML documents + that are as faithful to the SMI as possible, using XSD as the + validation mechanism. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. XSD for SMI Base Datatypes . . . . . . . . . . . . . . . . . . 7 5. Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . 10 5.1. Numeric Datatypes . . . . . . . . . . . . . . . . . . . . 10 5.2. OctetString . . . . . . . . . . . . . . . . . . . . . . . 10 5.3. Opaque . . . . . . . . . . . . . . . . . . . . . . . . . . 11 5.4. IpAddress . . . . . . . . . . . . . . . . . . . . . . . . 12 5.5. ObjectIdentifier . . . . . . . . . . . . . . . . . . . . . 12 - 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 - 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 - 7.1. SMI Base Datatypes Namespace Registration . . . . . . . . 15 - 7.2. SMI Base Datatypes Schema Registration . . . . . . . . . . 15 - 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 - 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 - 9.1. Normative References . . . . . . . . . . . . . . . . . . . 17 - 9.2. Informational References . . . . . . . . . . . . . . . . . 17 - Appendix A. Open Issues . . . . . . . . . . . . . . . . . . . . . 18 - Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 19 - Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 20 - Intellectual Property and Copyright Statements . . . . . . . . . . 21 + 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 + 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 + 7.1. SMI Base Datatypes Namespace Registration . . . . . . . . 14 + 7.2. SMI Base Datatypes Schema Registration . . . . . . . . . . 14 + 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 + 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 + 9.1. Normative References . . . . . . . . . . . . . . . . . . . 16 + 9.2. Informational References . . . . . . . . . . . . . . . . . 16 + Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 17 1. Introduction Numerous uses exist -- both within and outside the traditional IETF network management community -- for the expression of management information described in and accessible via SMI Management - Information Base (MIB) modules as XML documents [ref.XML]. For - example, XML-based management applications which want to incorporate - MIB modules as data models and/or to access MIB module - instrumentation via gateways to SNMP agents will benefit from an IETF - standard mapping of SMI datatypes and structures to XML documents via - XSD. + Information Base (MIB) modules as XML documents [XML]. For example, + XML-based management applications which want to incorporate MIB + modules as data models and/or to access MIB module instrumentation + via gateways to SNMP agents will benefit from an IETF standard + mapping of SMI datatypes to XML documents via XSD. MIB data models are described using SMIv2 [RFC2578] and, for legacy MIBs, SMIv1 [RFC1155]. MIB data is conveyed in variable bindings ("varbinds") within protocol data units (PDUs) within SNMP messages using the base/primitive datatypes defined in the SMI. The SMI allows for creation of derivative datatypes, termed "textual conventions" ("TCs"), each of which has a unique name, a syntax which is or refines a primitive SMI datatype, and relatively precise application-level semantics. TCs are used principally to facilitate correct application-level handling of MIB data and for the convenience of humans reading MIB modules and appropriately rendered MIB data output. Values in varbinds corresponding to MIB objects with TC syntaxes are always encoded as the primitive SMI datatype underlying the TC syntax. Thus, the XSD mappings defined in this memo will support MIB objects with TC syntax as well as those with base SMI syntax. Various independent schemes have been devised for expressing the SMI - datatypes and TCs in XSD [ref.XMLSchema]. These schemes have - exhibited a degree of commonality (especially concerning the numeric - SMI datatypes), but also sufficient differences (especially - concerning the non-numeric SMI datatypes) to preclude general - interoperability. + datatypes in XSD [XMLSchema]. These schemes have exhibited a degree + of commonality (especially concerning the numeric SMI datatypes), but + also sufficient differences (especially concerning the non-numeric + SMI datatypes) to preclude uniformity and general interoperability. The primary purpose of this memo is to define a standard expression - of SMI base datatypes in XSD to ensure uniformity and general - interoperability in this respect. Internet operators, management - tool developers, and users will benefit from the wider selection of - management tools and the greater degree of unified management -- with - attendant improvements in timeliness and accuracy of management - information -- which such a standard will facilitate. - - This memo is the first in a set of three related and (logically) - ordered specifications: - - 1. SMI Base Datatypes [RFC2578] in XSD + of SMI base datatypes in XSD to ensure fidelity, consistency, and + general interoperability in this respect. Internet operators, + management tool developers, and users will benefit from the wider + selection of management tools and the greater degree of unified + management -- with attendant improvements in timeliness and accuracy + of management information -- which such a standard facilitates. - 2. SMI MIB Structure [RFC2578] in XSD + On its own, this memo specifies the IETF standard way to render SMI + data values carried in SNMP messages as XML in a faithful, + consistent, and interoperable way. - 3. SNMP Textual Conventions [RFC2579] in XSD + Certain XML-based applications will find this specification + sufficient for their purposes. Other XML applications may need to + make more complete reuse of existing MIB modules, requiring standard + XSDs for TCs [RFC2579] and MIB structure [RFC2578]. Documents + supporting those requirements are planned, but have not been produced + at the time of this writing. - As a set, these documents define the XSD equivalent of SMIv2 to - encourage XML-based protocols to carry, and XML-based applications to - use, the information modeled in SMIv2-compliant MIB modules. + The objective of this memo, and of any future related specifications + that might be produced, is to define the XSD equivalent + [XSDDatatypes] of SMIv2 (STD58) to encourage XML-based protocols to + carry, and XML-based applications to use, the information modeled in + SMIv2-compliant MIB modules. - This work defines XSD equivalents of the datatypes and data - structures [RFC2578] and the textual conventions [RFC2579] defined in - the SMIv2 standard (STD58) to encourage efficient reuse of existing - (including future) MIB modules and instrumentation by XML-based - management protocols and applications. + Having such a standard mapping of SMIv2 to XML via XSD validation + will enable and promote efficient reuse of existing (including + future) MIB modules and instrumentation by XML-based management + protocols and applications. The goal of fidelity to the SMIv2 standard (STD58), as specified in the "Requirements" section below, is crucial to this effort to leverage the established "rough consensus" for the precise data modeling used in MIB modules, and to leverage existing "running code" for implemented SMIv2 data models. This effort does not include redesign of SMIv2 datatypes or data structures or textual conventions to overcome known limitations -- that work can be pursued in other efforts. @@ -172,64 +179,74 @@ most direct XSD datatype, with the most parsimonious restrictions, which matches the foregoing requirements. R7. The XML output produced as a result of meeting the foregoing requirements SHOULD be the most direct (i.e., avoiding superfluous "decoration") from the perspective of readability by humans. 4. XSD for SMI Base Datatypes - This document concerns only the SMI base datatypes -- i.e., the - eleven "ObjectSyntax" datatypes defined in RFC2578. These datatypes - -- via tag values defined in the SMI to identify them in varbinds -- - constrain values carried "on-the-wire" in SNMP PDUs between SNMP - management applications and SNMP agents: + This document provides XSD datatype mappings for the SMIv2 base + datatypes only -- i.e., the eleven "ObjectSyntax" datatypes defined + in RFC 2578. These datatypes -- via tag values defined in the SMIv2 + to identify them in varbinds -- constrain values carried "on-the- + wire" in SNMP PDUs between SNMP management applications and SNMP + agents: o INTEGER, Integer32 o Unsigned32, Gauge32 o Counter32 o TimeTicks o Counter64 - o OctetString + o OCTET STRING - o Opague + o Opaque o IpAddress - o ObjectIdentifier + o OBJECT IDENTIFIER - The "BITS" pseudo-type (also referred to as a "construct" in RFC2578) - is treated as a Textual Convention for the purpose of this document - and, therefore, will be defined in the "SNMP Textual Conventions in - XSD" document. + The "BITS" pseudo-type (also referred to as a "construct" in RFC + 2578) is treated as a Textual Convention, not a base datatype, for + the purpose of this document. BEGIN - Mapping of SMIv2 base datatypes from RFC 2578. + Mapping of SMIv2 base datatypes from RFC 2578 + + Contact: Bob Natale + Organization: MITRE + Address: 7515 Colshire Drive + McLean VA 22102 + USA + Telephone: +1 703-983-2505 + E-Mail: rnatale@mitre.org + Last Updated: 200903090000Z + @@ -262,21 +278,21 @@ @@ -329,30 +345,30 @@ 5.2. OctetString This XSD datatype corresponds to the SMI "OCTET STRING" datatype. Several independent schemes for mapping SMI datatypes to XSD have used the XSD "string" type to represent "OCTET STRING", but this mapping does not conform to the requirements specified in this document. Most notably, "string" cannot faithfully represent all valid values (0 thru 255) that each octet in an "OCTET STRING" can - have -- or at least cannot do so in a way that provides for ready + have -- or at least cannot do so in a way that provides for easy human readability of the resulting XML output. Consequently, the XSD datatype "hexBinary" is specified as the standard mapping of the SMI "OCTET STRING" datatype. In hexBinary, each octet is encoded as two hexadecimal digits; the canonical representation limits the set of allowed hexadecimal digits to 0-9 and uppercase A-F. - The hexBinary representation of OCTET STRING complies with the + The hexBinary representation of "OCTET STRING" complies with the relevant requirements: o It covers all valid values for the corresponding SMI datatype. o It complies with the standard encoding rules associated with the corresponding SMI datatype. o With the "maxLength" restriction to 65535 octets, the XSD datatype specification matches the restrictions associated with the corresponding SMI datatype. @@ -365,115 +381,101 @@ XSD datatype is not optimal with respect to readability by humans; however, that is a consequence of the SMI datatype itself. Where human readability is more of a concern, it is likely that the actual MIB objects in question will be represented by textual conventions which limit the set of values that will be included in the OctetStrings and will, thus, bypass the hexBinary typing. 5.3. Opaque The "hexBinary" XSD datatype is specified as the representation of - the SMI "Opague" datatype generally for the same reasons as + the SMI "Opaque" datatype generally for the same reasons as "hexBinary" is specified for the "OctetString" datatype: o It covers all valid values for the corresponding SMI datatype. o It complies with the standard encoding rules associated with the corresponding SMI datatype. o There are no restriction issues associated with using "hexBinary" - for "Opague". + for "Opaque". o It is the most direct XSD datatype which exhibits the foregoing characteristics relative to the corresponding SMI datatype (which must allow for any valid binary octet value). o The XML output produced from the canonical representation of this XSD datatype is not optimal with respect to readability by humans; however, that is a consequence of the SMI datatype itself. - Unmediated "Opague" data is intended for consumption by + Unmediated "Opaque" data is intended for consumption by applications, not humans. 5.4. IpAddress The XSD "string" datatype is the natural choice to represent an IpAddress as XML output. The "pattern" restriction applied in this - case results in a "dotted-decimal string of four values between "0" + case results in a dotted-decimal string of four values between "0" and "255" separated by a period (".") character. This pattern also precludes leading zeros. 5.5. ObjectIdentifier This XSD datatype corresponds to the SMI "OBJECT IDENTIFIER" datatype. The XSD "string" datatype is also the natural choice to represent an ObjectIdentifier as XML output, for the same reasons as for the IpAddress choice. The "pattern" restriction applied in this case results in a dotted-decimal string of up to 128 elements (referred to as "sub-ids"), each holding an "Unsigned32" integer value. Note that, while not mentioned in Sec. 7.1.3 of RFC 2578, due to the use of Abstract Syntax Notation One (ASN.1) Basic Encoding Rules (BER) the first two components of an "OBJECT IDENTIFIER" have limited value ranges and are encoded into a single sub-id value [Steedman]. The ASN.1/BER standards specify that the numerical value of the first - sub-identifier is derived from the values of the first two object - identifier components in the object identifier value being encoded, - using the formula: (X*40) + Y, where X is the value of the first - object identifier component and Y is the value of the second object - identifier component. This packing of the first two object - identifier components recognizes that only three values are allocated - from the root node, and at most 39 subsequent values from nodes - reached by X = 0 and X = 1. The minimum length of an "OBJECT - IDENTIFIER" is two sub-ids (with a zero-valued "OBJECT IDENTIFIER" - represented as "0.0"). No explicit "minLength" restriction (which - would be "3" to allow for the minimum of two sub-ids and a single - separating dot) is required, since the pattern itself enforces this - restriction. + sub-identifier is derived from the values of the first two "OBJECT + IDENTIFIER" components in the value being encoded, using the formula: + (X*40) + Y, where X is the value of the first component and Y is the + value of the second component. This packing of the first two + components recognizes that only three values are allocated from the + root node, and at most 39 subsequent values from nodes reached by X = + 0 and X = 1. The minimum length of an "OBJECT IDENTIFIER" is two + sub-ids (with a zero-valued "OBJECT IDENTIFIER" represented as + "0.0"). No explicit "minLength" restriction (which would be "3" to + allow for the minimum of two sub-ids and a single separating dot) is + required, since the pattern itself enforces this restriction. 6. Security Considerations Security considerations for any given SMI MIB module are likely to be relevant to any XSD/XML mapping of that MIB module; however, the mapping defined in this document does not itself introduce any new security considerations. If and when proxies or gateways are developed to convey SNMP management information from SNMP agents to XML-based management applications via XSD/XML mapping of MIB modules based on this specification and its planned siblings, special care will need to be taken to ensure that all applicable SNMP security mechanisms are supported in an appropriate manner yet to be determined. 7. IANA Considerations - In accordance with RFC 3688, we will register namespaces and schemas - for all three documents in this set with the IANA XML Registry. - These entries -- corresponding to this base datatypes document and - the future textual conventions and MIB structure documents -- will be - as follows: + In accordance with RFC 3688 [RFC3688], we request the following + namespace and schema registrations associated with this document in + the IANA XML Registry: o urn:ietf:params:xml:ns:opsawg:smi:base:[version_id] o urn:ietf:params:xml:schema:opsawg:smi:base:[version_id] - o urn:ietf:params:xml:ns:opsawg:smi:tc:[version_id] - - o urn:ietf:params:xml:schema:opsawg:smi:tc:[version_id] - - o urn:ietf:params:xml:ns:opsawg:smi:structure:[version_id] - - o urn:ietf:params:xml:schema:opsawg:smi:structure:[version_id] - - The following sub-sections refer to the present document only. - 7.1. SMI Base Datatypes Namespace Registration This document registers a URI for the SMI Base Datatypes XML namespace in the IETF XML registry. Following the format in RFC 3688, IANA has made the following registration: URI: urn:ietf:params:xml:ns:opsawg:smi:base:1.0 Registration Contact: The IESG. @@ -494,169 +496,76 @@ 8. Acknowledgements Dave Harrington provided strategic and technical leadership to the team which developed this particular specification. Yan Li did much of the research into existing approaches that was used as a baseline for the recommendations in this particular specification. This document owes much to draft-romascanu-netconf-datatypes-xx and to many other sources (including libsmi and group discussions on the NETCONF mailing lists) developed by those who have researched and - published candidate mappings of SMI datatypes and textual conventions - to XSD. + published candidate mappings of SMI datatypes to XSD. Individuals who participated in various discussions of this topic at IETF meetings and on IETF mailing lists include: Ray Atarashi, Yoshifumi Atarashi, Andy Bierman, Sharon Chisholm, Avri Doria, Mark - Ellison, Rob Ennes, David Harrington, Alfred HInes, Eliot Lear, Chris - Lonvick, Faye Ly, Randy Presuhn, Juergen Schoenwaelder, Andre - Westerinen, and Bert Wijnen. - - (Others who have been inadvertently omitted from this list should - notify the editor.) + Ellison, Rob Ennes, Mehmet Ersue, David Harrington, Alfred Hines, + Eliot Lear, Chris Lonvick, Faye Ly, Randy Presuhn, Juergen + Schoenwaelder, Andre Westerinen, and Bert Wijnen. 9. References 9.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., Perkins, D., and J. Schoenwaelder, - "Textual Conventions for SMIv2", STD 58, RFC 2579, - April 1999. - -9.2. Informational References - [RFC3584] Frye, R., Levi, D., Routhier, S., and B. Wijnen, "Coexistence between Version 1, Version 2, and Version 3 of the Internet-standard Network Management Framework", BCP 74, RFC 3584, August 2003. +9.2. Informational References + + [RFC2579] McCloghrie, K., Perkins, D., and J. Schoenwaelder, + "Textual Conventions for SMIv2", STD 58, RFC 2579, + April 1999. + [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004. [Steedman] Steedman, D., "ASN.1: The Tutorial and Reference". - [ref.XML] World Wide Web Consortium, "Extensible Markup Language + [XML] World Wide Web Consortium, "Extensible Markup Language (XML) 1.0", W3C XML, February 1998, . - [ref.XMLSchema] + [XMLSchema] World Wide Web Consortium, "XML Schema Part 1: Structures Second Edition", W3C XML Schema, October 2004, . - [ref.XSDDatatype] + [XSDDatatypes] World Wide Web Consortium, "XML Schema Part 2: Datatypes Second Edition", W3C XML Schema, October 2004, . -Appendix A. Open Issues - - o Confirm IANA XML registration values and process. - -Appendix B. Change Log - - o -01 version: - - * Incorporated mailing list comments on -00 version from Juergen - Schoenwaelder - - * Incorporated mailing list comments on -00 version from David - Harrington - - o -02 version: - - * Fixed ObjectIdentifier pattern per correction from Juergen - Schoenwaelder, and text in sec. 5.5 adjusted accordingly. - - * Moved non-normative references to Informational section per - David Harrington - - * Tightened wording in to "XSD for SMI Datatypes" section per - Mark Ellison - - * Added a note about Gauge32 and Counter32 application semantics - to the "Rationale" section per Mark Ellison - - * Security section wording tightened per David Harrington - - * The IANA Considerations section completed--will need - adjustment. - - * Acknowledgments entries expanded and alphabetized - - o -03 version: - - * Corrected "ten" to "eleven" in opening sentence of "XSD for SMI - Datatypes" section. - - * Removed conditional wording that previously prefaced the XSD - itself. - - o -04 version: - - * Relatively minor text fix-ups in various places, mainly in - response to comments on the -03 version from Mark Ellison, - Alfred HInes, Juergen Schoenwaelder, and David Harrington. - Author's Address Bob Natale MITRE 7515 Colshire Dr MS H405 McLean, VA 22102 USA Phone: +1 703-983-2505 Email: rnatale@mitre.org - -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.