From: http://www.ietf.org/internet-drafts/draft-ietf-opsawg-smi-datatypes-in-xsd-00.txt
Title: Expressing SNMP SMI Datatypes in XML Schema Definition Language
Reference: IETF Network Working Group, Internet Draft 'draft-ietf-opsawg-smi-datatypes-in-xsd-00.txt'
Date: February 11, 2008
I-D Tracker: http://ietfreport.isoc.org/idref/draft-ietf-opsawg-smi-datatypes-in-xsd/
IETF Operations and Management Area Working Group Working Group
http://www.ietf.org/html.charters/opsawg-charter.html
==============================================================================
Network Working Group B. Natale, Ed.
Internet-Draft MITRE
Intended status: Standards Track Y. Li, Ed.
Expires: August 14, 2008 Huawei Technologies
February 11, 2008
Expressing SNMP SMI Datatypes in XML Schema Definition Language
draft-ietf-opsawg-smi-datatypes-in-xsd-00.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
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 August 14, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Abstract
This memo defines the IETF standard expression of Simple Network
Management Protocol (SNMP) Structure of Management Information (SMI)
datatypes in eXtensible Markup Language (XML) Schema Definition (XSD)
language. The primary objective of this memo is to enable production
of XML documents that are as faithful to the SMI as possible, using
XSD as the validation mechanism.
Natale & Li Expires August 14, 2008 [Page 1]
Internet-Draft Expressing SNMP SMI Datatypes in XSD February 2008
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. XSD for SMI Datatypes . . . . . . . . . . . . . . . . . . . . 5
5. Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . 7
5.1. Numeric Datatypes . . . . . . . . . . . . . . . . . . . . 7
5.2. OctetString . . . . . . . . . . . . . . . . . . . . . . . 8
5.3. Opaque . . . . . . . . . . . . . . . . . . . . . . . . . . 8
5.4. IpAddress . . . . . . . . . . . . . . . . . . . . . . . . 9
5.5. ObjectIdentifier . . . . . . . . . . . . . . . . . . . . . 9
6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
9. Normative References . . . . . . . . . . . . . . . . . . . . . 11
Appendix A. Open Issues . . . . . . . . . . . . . . . . . . . . . 11
Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 12
Natale & Li Expires August 14, 2008 [Page 2]
Internet-Draft Expressing SNMP SMI Datatypes in XSD February 2008
1. Introduction
Numerous uses exist -- both within and outside the traditional IETF
network management industry -- for the expression of management
information described in and accessible via SNMP Management
Information Bases (MIBs) as XML documents [ref.XML]. For example,
XML-based management applications which want to incorporate SNMP MIBs
as data models and/or to access SNMP MIB instrumentation via gateways
to SNMP agents will benefit from an IETF standard mapping of MIB
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
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.
Various independent schemes have been devised for expressing the SMI
datatypes and textual conventions 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 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. SNMP SMI Datatypes [RFC2578] in XSD
2. SNMP MIB Structure [RFC2578] in XSD
3. SNMP Textual Conventions [RFC2579] in XSD
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 the SMIv2-compliant Management
Information Base ("The MIB").
Natale & Li Expires August 14, 2008 [Page 3]
Internet-Draft Expressing SNMP SMI Datatypes in XSD February 2008
This work will define 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.
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.
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].
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.
3. Requirements
R1. All SMI 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
to represent all valid values for that SMI datatype, and only
those values.
R4. The XSD datatype specified for a given SMI datatype MUST
represent any special encoding rules associated with that SMI
datatype.
R5. The XSD datatype specified for a given SMI datatype MUST include
any restrictions on values associated with the SMI datatype.
R6. The XSD datatype specified for a given SMI datatype MUST be the
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 from the perspective of
readability by humans.
[DISCUSS} Should any requirements be added, deleted, re-worded?
Natale & Li Expires August 14, 2008 [Page 4]
Internet-Draft Expressing SNMP SMI Datatypes in XSD February 2008
4. XSD for SMI Datatypes
This document concerns the SMI datatypes that are carried "on-the-
wire" -- i.e., have tag values defined in the SMI carried in varbinds
in SNMP PDUs -- between SNMP management applications and SNMP agents:
o INTEGER
o Integer32
o Unsigned32
o Counter32
o Gauge32
o TimeTicks
o Counter64
o OctetString
o Opague
o IpAddress
o ObjectIdentifier
The following should be considered a "notional" XSD file for now,
pending agreement on the actual datatype specifications. An
appropriate (official) targetNamespace must be designated (and
approved) and agreement must be reached on whether any additional XSD
content must be included (e.g., whether non-default values for
elementFormDefault or attributeFormDefault or schemaLocation, etc.,
need to be specified).
Mapping of SMIv2 datatypes from RFC 2578.
Natale & Li Expires August 14, 2008 [Page 5]
Internet-Draft Expressing SNMP SMI Datatypes in XSD February 2008
[TODO]Decisions needed on namespace issues [RFC3688]. One reviewer
suggested (until we have an RFC):
Natale & Li Expires August 14, 2008 [Page 6]
Internet-Draft Expressing SNMP SMI Datatypes in XSD February 2008
o "urn:ietf:params:xml:ns:opsawg:smi:v1.0" and
o "urn:ietf:params:xml:schema:draft-ietf-opsawg-smi-datatypes-in-
xsd-00.txt"
[DISCUSS] The "BITS" pseudo-type is treated as a Textual Convention
for the purpose of this document and, therefore, will be defined in
the associated "SNMP Textual Conventions in XSD" document.
[DISCUSS] Should we include value and pattern restriction language
from the SMI specifications in the XSD as either "documentation" or
"appInfo" "annotations" -- or keep the XSD as simple as possible and
merely refer the reader to the relevant sections of those
specifications?
5. Rationale
The XSD datatypes, including any specified restrictions, were chosen
based on fit with the requirements specified earlier in this
document, and with attention to simplicity while maintaining fidelity
to the SMI. Also, the "canonical representations" (i.e., refinements
of the "lexical representations") documented in the W3C XSD
specifications are assumed.
[DISCUSS] The use of "canonical representations" in the XSD specs
might merit review by others. This author's (Natale) understanding
might not be complete or correct.
5.1. Numeric Datatypes
All of the numeric XSD datatypes specified in the previous section --
INTEGER, Integer32, Unsigned32, Counter32, Counter, Gauge32, Gauge,
TimeTicks, and 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
characteristics relative to the corresponding SMI datatypes (which
is why no "restriction" statements 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).
Natale & Li Expires August 14, 2008 [Page 7]
Internet-Draft Expressing SNMP SMI Datatypes in XSD February 2008
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
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
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.
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. 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
"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.
Natale & Li Expires August 14, 2008 [Page 8]
Internet-Draft Expressing SNMP SMI Datatypes in XSD February 2008
o There are no restriction issues associated with using "hexBinary"
for "Opague".
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
applications, not humans.
[DISCUSS] Does the "Double-wrapping" aspect of "Opague" in the SMI
need to be accommodated in the XSD syntax?
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"
and "255" separated by a period (".") character. This pattern also
precludes leading zeros.
[DISCUSS] Is the leading-zeros restriction appropriate? It is
specified here for the following reasons: Enhances human readability,
conforms to the most common way of representing IpAddress values, and
conforms to other selections in this document to avoid leading-zeros
on numerical output values.
[DISCUSS] Irrespective of the previous discussion topic, can the
pattern for IpAddress be simplified further (while still satisfying
the core requirements for allowable value sequences)?
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.
Note that, while not mentioned in Sec. 7.1.3 of RFC 2578, due to
encoding rules the first two sub-ids of an "OBJECT IDENTIFIER" have
limited value ranges ([0-2] and [0-39], respectively), and the
minimum length of an "OBJECT IDENTIFIER" is two sub-ids (with a zero-
valued "OBJECT IDENTIFIER" represented as "0.0"). No explicit
Natale & Li Expires August 14, 2008 [Page 9]
Internet-Draft Expressing SNMP SMI Datatypes in XSD February 2008
"minLength" restriction (which would be "3" to allow for the minimum
of two sub-ids) is required, since the pattern itself enforces this
restriction.
[DISCUSS] The pattern specified for ObjectIdentifier attempts to
faithfully capture the restrictions mentioned above. Does it do so
correctly and is there a more efficient way of doing so?
6. Security Considerations
Security considerations for any given MIB are likely to be relevant
to any XSD/XML mapping of that MIB.
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 MIBs based on this specification
and its planned siblings, special care will need to be taken to
ensure that any SNMPv3 security mechanisms are supported in an
appropriate manner yet to be determined.
7. IANA Considerations
[DISCUSS] We will likely need namespace and location resources from
IANA...?.
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.
[TODO] Add an "Informational References" section documenting prior
developmental publications and implementations.
Individuals who participated in earlier discussions of this topic at
IETF meetings and on IETF mailing lists include: Sharon Chisholm,
David Harrington, Ray Atarashi, Yoshifumi Atarashi, Bert Wijnen, Andy
Bierman, Randy Presuhn, Chris Lonvick, Eliot Lear, Avri Doria,
Juergen Schoenwaelder, Rob Ennes, Faye Ly and Andre Westerinen.
[TODO] Expand list of participants as appropriate.
Natale & Li Expires August 14, 2008 [Page 10]
Internet-Draft Expressing SNMP SMI Datatypes in XSD February 2008
9. 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.
[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.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81,
RFC 3688, January 2004.
[ref.XML] World Wide Web Consortium, "Extensible Markup
Language (XML) 1.0", W3C XML, February 1998,
.
[ref.XMLSchema] World Wide Web Consortium, "XML Schema Part 1:
Structures Second Edition", W3C XML Schema,
October 2004, .
[ref.XSDDatatype] World Wide Web Consortium, "XML Schema Part 2:
Datatypes Second Edition", W3C XML Schema,
October 2004, .
Appendix A. Open Issues
o Resolve all [TODO] items.
o Resolve all [DISCUSS] items.
Natale & Li Expires August 14, 2008 [Page 11]
Internet-Draft Expressing SNMP SMI Datatypes in XSD February 2008
Appendix B. Change Log
-00 Initial version
Authors' Addresses
Bob Natale (editor)
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
Natale & Li Expires August 14, 2008 [Page 12]
Internet-Draft Expressing SNMP SMI Datatypes in XSD February 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.
Acknowledgement
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Natale & Li Expires August 14, 2008 [Page 13]