--- 1/draft-ietf-opsawg-smi-datatypes-in-xsd-03.txt 2008-10-29 08:12:17.000000000 +0100 +++ 2/draft-ietf-opsawg-smi-datatypes-in-xsd-04.txt 2008-10-29 08:12:17.000000000 +0100 @@ -1,19 +1,18 @@ -Network Working Group B. Natale, Ed. +Network Working Group B. Natale Internet-Draft MITRE -Intended status: Standards Track Y. Li, Ed. -Expires: January 29, 2009 Huawei Technologies - July 28, 2008 +Intended status: Standards Track October 29, 2008 +Expires: May 2, 2009 Expressing SNMP SMI Datatypes in XML Schema Definition Language - draft-ietf-opsawg-smi-datatypes-in-xsd-03.txt + draft-ietf-opsawg-smi-datatypes-in-xsd-04.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. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that @@ -24,21 +23,21 @@ 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 January 29, 2009. + This Internet-Draft will expire on May 2, 2009. 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. @@ -57,44 +56,51 @@ 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 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 + Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 20 Intellectual Property and Copyright Statements . . . . . . . . . . 21 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. MIB data models are described using SMIv2 [RFC2578] and, for legacy - MIBs, SMIv1 [RFC1155]. MIB data is conveyed via SNMP using the base - 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 based on a core 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. + 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. The primary purpose of this memo is to define a standard expression of SMI base datatypes in XSD to ensure uniformity and general @@ -135,21 +141,21 @@ 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 RFC 2119 [RFC2119]. 3. Requirements The following set of requirements is intended to produce XML documents which can be validated via the XSD defined in this - specification to faithfully represnt values carried "on-the-wire" in + specification to faithfully represent values carried "on-the-wire" in SNMP PDUs as defined by the SMI: R1. All SMI base datatypes MUST have a corresponding XSD datatype. R2. SMIv2 is the normative SMI for this document -- SMIv1 modules, if encountered, MUST be converted (at least logically) in accordance with Section 2.1, inclusive, of the "Coexistence" RFC [RFC3584]. R3. The XSD datatype specified for a given SMI datatype MUST be able @@ -251,29 +257,34 @@ + "((0|(1[0-9]{0,2})| + (2(([0-4][0-9]?)|(5[0-5]?)|([6-9]?)))| + ([3-9][0-9]?))\.){3} + (0|(1[0-9]{0,2})| + (2(([0-4][0-9]?)|(5[0-5]?)|([6-9]?)))| + ([3-9][0-9]?))" END 5. Rationale The XSD datatypes, including any specified restrictions, were chosen @@ -290,38 +301,38 @@ Counter64 -- comply with the relevant requirements o They cover all valid values for the corresponding SMI datatypes. o They comply with the standard encoding rules associated with the corresponding SMI datatypes. o They inherently match the range restrictions associated with the corresponding SMI datatypes. - o They are the most direct XSD datatype which exhibit the foregoing + o They are the most direct XSD datatypes which exhibit the foregoing characteristics relative to the corresponding SMI datatypes (which is why no "restriction" statements -- other than the "base" XSD type -- are required in the XSD). o The XML output produced from the canonical representation of these XSD datatypes is also the most direct from the perspective of readability by humans (i.e., no leading "+" sign and no leading zeros). Special note to application developers: Compliance with this schema in an otherwise correct translation from raw ("on-the-wire" representation) SNMP MIB data produces values that are faithful to - the original. However, the Gauge32 and Counter32 datatypes have - special application semantics that must be considered when using - their raw values for anything other than display, printing, storage, - or transmission of the literal value. This is particularly important - for Counter32 values. RFC 2578 provides the necessary details. + the original. However, the Gauge32, Counter32, Counter64, and + TimeTicks datatypes have special application semantics that must be + considered when using their raw values for anything other than + display, printing, storage, or transmission of the literal value. + RFC 2578 provides the necessary details. 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 @@ -392,28 +403,28 @@ 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"), holding "Unsigned32" integer values. + 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 - subidentifier is derived from the values of the first two object + 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 @@ -489,24 +500,26 @@ 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. 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, 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 editors.) + 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.) 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 @@ -580,44 +593,41 @@ * 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. - * Temoved conditional wording that previously prefaced the XSD + * Removed conditional wording that previously prefaced the XSD itself. -Authors' Addresses + o -04 version: - Bob Natale (editor) + * 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 - Yan Li (editor) - Huawei Technologies - No.3 Xinxi Road, Shangdi Information Industry Base - Beijing, HaiDian District 100085 - P.R.China - - Phone: +86 10 8288 2008 - Email: liyan_77@huawei.com - 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