draft-ietf-opsawg-smi-datatypes-in-xsd-03.txt   draft-ietf-opsawg-smi-datatypes-in-xsd-04.txt 
Network Working Group B. Natale, Ed. Network Working Group B. Natale
Internet-Draft MITRE Internet-Draft MITRE
Intended status: Standards Track Y. Li, Ed. Intended status: Standards Track October 29, 2008
Expires: January 29, 2009 Huawei Technologies Expires: May 2, 2009
July 28, 2008
Expressing SNMP SMI Datatypes in XML Schema Definition Language 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 Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 35 skipping to change at page 1, line 34
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. 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 Abstract
This memo (when approved as a standards-track RFC) defines the IETF This memo (when approved as a standards-track RFC) defines the IETF
standard expression of Structure of Management Information (SMI) base standard expression of Structure of Management Information (SMI) base
datatypes in Extensible Markup Language (XML) Schema Definition (XSD) datatypes in Extensible Markup Language (XML) Schema Definition (XSD)
language. The primary objective of this memo is to enable the language. The primary objective of this memo is to enable the
production of XML documents that are as faithful to the SMI as production of XML documents that are as faithful to the SMI as
possible, using XSD as the validation mechanism. possible, using XSD as the validation mechanism.
skipping to change at page 2, line 36 skipping to change at page 2, line 36
6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
7.1. SMI Base Datatypes Namespace Registration . . . . . . . . 15 7.1. SMI Base Datatypes Namespace Registration . . . . . . . . 15
7.2. SMI Base Datatypes Schema Registration . . . . . . . . . . 15 7.2. SMI Base Datatypes Schema Registration . . . . . . . . . . 15
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
9.1. Normative References . . . . . . . . . . . . . . . . . . . 17 9.1. Normative References . . . . . . . . . . . . . . . . . . . 17
9.2. Informational References . . . . . . . . . . . . . . . . . 17 9.2. Informational References . . . . . . . . . . . . . . . . . 17
Appendix A. Open Issues . . . . . . . . . . . . . . . . . . . . . 18 Appendix A. Open Issues . . . . . . . . . . . . . . . . . . . . . 18
Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 19 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 20
Intellectual Property and Copyright Statements . . . . . . . . . . 21 Intellectual Property and Copyright Statements . . . . . . . . . . 21
1. Introduction 1. Introduction
Numerous uses exist -- both within and outside the traditional IETF Numerous uses exist -- both within and outside the traditional IETF
network management community -- for the expression of management network management community -- for the expression of management
information described in and accessible via SMI Management information described in and accessible via SMI Management
Information Base (MIB) modules as XML documents [ref.XML]. For Information Base (MIB) modules as XML documents [ref.XML]. For
example, XML-based management applications which want to incorporate example, XML-based management applications which want to incorporate
MIB modules as data models and/or to access MIB module MIB modules as data models and/or to access MIB module
instrumentation via gateways to SNMP agents will benefit from an IETF instrumentation via gateways to SNMP agents will benefit from an IETF
standard mapping of SMI datatypes and structures to XML documents via standard mapping of SMI datatypes and structures to XML documents via
XSD. XSD.
MIB data models are described using SMIv2 [RFC2578] and, for legacy MIB data models are described using SMIv2 [RFC2578] and, for legacy
MIBs, SMIv1 [RFC1155]. MIB data is conveyed via SNMP using the base MIBs, SMIv1 [RFC1155]. MIB data is conveyed in variable bindings
datatypes defined in the SMI. The SMI allows for creation of ("varbinds") within protocol data units (PDUs) within SNMP messages
derivative datatypes, termed "textual conventions" ("TCs"), each of using the base/primitive datatypes defined in the SMI.
which has a unique name, a syntax based on a core SMI datatype, and
relatively precise application-level semantics. TCs are used The SMI allows for creation of derivative datatypes, termed "textual
principally to facilitate correct application-level handling of MIB conventions" ("TCs"), each of which has a unique name, a syntax which
data and for the convenience of humans reading MIB modules and is or refines a primitive SMI datatype, and relatively precise
appropriately rendered MIB data output. 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 Various independent schemes have been devised for expressing the SMI
datatypes and TCs in XSD [ref.XMLSchema]. These schemes have datatypes and TCs in XSD [ref.XMLSchema]. These schemes have
exhibited a degree of commonality (especially concerning the numeric exhibited a degree of commonality (especially concerning the numeric
SMI datatypes), but also sufficient differences (especially SMI datatypes), but also sufficient differences (especially
concerning the non-numeric SMI datatypes) to preclude general concerning the non-numeric SMI datatypes) to preclude general
interoperability. interoperability.
The primary purpose of this memo is to define a standard expression The primary purpose of this memo is to define a standard expression
of SMI base datatypes in XSD to ensure uniformity and general of SMI base datatypes in XSD to ensure uniformity and general
skipping to change at page 6, line 9 skipping to change at page 6, line 9
2. Conventions 2. Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
3. Requirements 3. Requirements
The following set of requirements is intended to produce XML The following set of requirements is intended to produce XML
documents which can be validated via the XSD defined in this 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: SNMP PDUs as defined by the SMI:
R1. All SMI base datatypes MUST have a corresponding XSD datatype. R1. All SMI base datatypes MUST have a corresponding XSD datatype.
R2. SMIv2 is the normative SMI for this document -- SMIv1 modules, R2. SMIv2 is the normative SMI for this document -- SMIv1 modules,
if encountered, MUST be converted (at least logically) in if encountered, MUST be converted (at least logically) in
accordance with Section 2.1, inclusive, of the "Coexistence" RFC accordance with Section 2.1, inclusive, of the "Coexistence" RFC
[RFC3584]. [RFC3584].
R3. The XSD datatype specified for a given SMI datatype MUST be able R3. The XSD datatype specified for a given SMI datatype MUST be able
skipping to change at page 8, line 45 skipping to change at page 8, line 45
</xs:restriction> </xs:restriction>
</xs:simpleType> </xs:simpleType>
<xs:simpleType name="Opaque"> <xs:simpleType name="Opaque">
<xs:restriction base="xs:hexBinary"/> <xs:restriction base="xs:hexBinary"/>
</xs:simpleType> </xs:simpleType>
<xs:simpleType name="IpAddress"> <xs:simpleType name="IpAddress">
<xs:restriction base="xs:string"> <xs:restriction base="xs:string">
<xs:pattern value= <xs:pattern value=
"((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})|
(0|1[0-9]{0,2}|2([0-4][0-9]?|5[0-5]?|[6-9])?|[3-9][0-9]?)"/> (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]?))"
</xs:restriction> </xs:restriction>
</xs:simpleType> </xs:simpleType>
<xs:simpleType name="ObjectIdentifier"> <xs:simpleType name="ObjectIdentifier">
<xs:restriction base="xs:string"> <xs:restriction base="xs:string">
<xs:pattern value= <xs:pattern value=
"([0-1](\.[1-3]?[0-9]))|(2.(0|([1-9]\d*))) "(([0-1](\.[1-3]?[0-9]))|
(2\.(0|([1-9]\d*))))
(\.(0|([1-9]\d*))){0,126}"/> (\.(0|([1-9]\d*))){0,126}"/>
</xs:restriction> </xs:restriction>
</xs:simpleType> </xs:simpleType>
</xs:schema> </xs:schema>
END END
5. Rationale 5. Rationale
The XSD datatypes, including any specified restrictions, were chosen The XSD datatypes, including any specified restrictions, were chosen
skipping to change at page 10, line 28 skipping to change at page 10, line 28
Counter64 -- comply with the relevant requirements Counter64 -- comply with the relevant requirements
o They cover all valid values for the corresponding SMI datatypes. o They cover all valid values for the corresponding SMI datatypes.
o They comply with the standard encoding rules associated with the o They comply with the standard encoding rules associated with the
corresponding SMI datatypes. corresponding SMI datatypes.
o They inherently match the range restrictions associated with the o They inherently match the range restrictions associated with the
corresponding SMI datatypes. 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 characteristics relative to the corresponding SMI datatypes (which
is why no "restriction" statements -- other than the "base" XSD is why no "restriction" statements -- other than the "base" XSD
type -- are required in the XSD). type -- are required in the XSD).
o The XML output produced from the canonical representation of these o The XML output produced from the canonical representation of these
XSD datatypes is also the most direct from the perspective of XSD datatypes is also the most direct from the perspective of
readability by humans (i.e., no leading "+" sign and no leading readability by humans (i.e., no leading "+" sign and no leading
zeros). zeros).
Special note to application developers: Compliance with this schema Special note to application developers: Compliance with this schema
in an otherwise correct translation from raw ("on-the-wire" in an otherwise correct translation from raw ("on-the-wire"
representation) SNMP MIB data produces values that are faithful to representation) SNMP MIB data produces values that are faithful to
the original. However, the Gauge32 and Counter32 datatypes have the original. However, the Gauge32, Counter32, Counter64, and
special application semantics that must be considered when using TimeTicks datatypes have special application semantics that must be
their raw values for anything other than display, printing, storage, considered when using their raw values for anything other than
or transmission of the literal value. This is particularly important display, printing, storage, or transmission of the literal value.
for Counter32 values. RFC 2578 provides the necessary details. RFC 2578 provides the necessary details.
5.2. OctetString 5.2. OctetString
This XSD datatype corresponds to the SMI "OCTET STRING" datatype. This XSD datatype corresponds to the SMI "OCTET STRING" datatype.
Several independent schemes for mapping SMI datatypes to XSD have Several independent schemes for mapping SMI datatypes to XSD have
used the XSD "string" type to represent "OCTET STRING", but this used the XSD "string" type to represent "OCTET STRING", but this
mapping does not conform to the requirements specified in this mapping does not conform to the requirements specified in this
document. Most notably, "string" cannot faithfully represent all document. Most notably, "string" cannot faithfully represent all
valid values (0 thru 255) that each octet in an "OCTET STRING" can valid values (0 thru 255) that each octet in an "OCTET STRING" can
skipping to change at page 12, line 35 skipping to change at page 12, line 35
5.5. ObjectIdentifier 5.5. ObjectIdentifier
This XSD datatype corresponds to the SMI "OBJECT IDENTIFIER" This XSD datatype corresponds to the SMI "OBJECT IDENTIFIER"
datatype. datatype.
The XSD "string" datatype is also the natural choice to represent an The XSD "string" datatype is also the natural choice to represent an
ObjectIdentifier as XML output, for the same reasons as for the ObjectIdentifier as XML output, for the same reasons as for the
IpAddress choice. The "pattern" restriction applied in this case IpAddress choice. The "pattern" restriction applied in this case
results in a dotted-decimal string of up to 128 elements (referred to 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 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 use of Abstract Syntax Notation One (ASN.1) Basic Encoding Rules
(BER) the first two components of an "OBJECT IDENTIFIER" have limited (BER) the first two components of an "OBJECT IDENTIFIER" have limited
value ranges and are encoded into a single sub-id value [Steedman]. 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 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, identifier components in the object identifier value being encoded,
using the formula: (X*40) + Y, where X is the value of the first 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 object identifier component and Y is the value of the second object
identifier component. This packing of the first two object identifier component. This packing of the first two object
identifier components recognizes that only three values are allocated identifier components recognizes that only three values are allocated
from the root node, and at most 39 subsequent values from nodes 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 reached by X = 0 and X = 1. The minimum length of an "OBJECT
IDENTIFIER" is two sub-ids (with a zero-valued "OBJECT IDENTIFIER" IDENTIFIER" is two sub-ids (with a zero-valued "OBJECT IDENTIFIER"
represented as "0.0"). No explicit "minLength" restriction (which represented as "0.0"). No explicit "minLength" restriction (which
would be "3" to allow for the minimum of two sub-ids and a single would be "3" to allow for the minimum of two sub-ids and a single
skipping to change at page 16, line 21 skipping to change at page 16, line 21
This document owes much to draft-romascanu-netconf-datatypes-xx and This document owes much to draft-romascanu-netconf-datatypes-xx and
to many other sources (including libsmi and group discussions on the to many other sources (including libsmi and group discussions on the
NETCONF mailing lists) developed by those who have researched and NETCONF mailing lists) developed by those who have researched and
published candidate mappings of SMI datatypes and textual conventions published candidate mappings of SMI datatypes and textual conventions
to XSD. to XSD.
Individuals who participated in various discussions of this topic at Individuals who participated in various discussions of this topic at
IETF meetings and on IETF mailing lists include: Ray Atarashi, IETF meetings and on IETF mailing lists include: Ray Atarashi,
Yoshifumi Atarashi, Andy Bierman, Sharon Chisholm, Avri Doria, Mark Yoshifumi Atarashi, Andy Bierman, Sharon Chisholm, Avri Doria, Mark
Ellison, Rob Ennes, David Harrington, Eliot Lear, Chris Lonvick, Faye Ellison, Rob Ennes, David Harrington, Alfred HInes, Eliot Lear, Chris
Ly, Randy Presuhn, Juergen Schoenwaelder, Andre Westerinen, and Bert Lonvick, Faye Ly, Randy Presuhn, Juergen Schoenwaelder, Andre
Wijnen. (Others who have been inadvertently omitted from this list Westerinen, and Bert Wijnen.
should notify the editors.)
(Others who have been inadvertently omitted from this list should
notify the editor.)
9. References 9. References
9.1. Normative References 9.1. Normative References
[RFC1155] Rose, M. and K. McCloghrie, "Structure and identification [RFC1155] Rose, M. and K. McCloghrie, "Structure and identification
of management information for TCP/IP-based internets", of management information for TCP/IP-based internets",
STD 16, RFC 1155, May 1990. STD 16, RFC 1155, May 1990.
[RFC2119] Bradner, s., "Key words for use in RFCs to Indicate [RFC2119] Bradner, s., "Key words for use in RFCs to Indicate
skipping to change at page 19, line 41 skipping to change at page 19, line 41
* The IANA Considerations section completed--will need * The IANA Considerations section completed--will need
adjustment. adjustment.
* Acknowledgments entries expanded and alphabetized * Acknowledgments entries expanded and alphabetized
o -03 version: o -03 version:
* Corrected "ten" to "eleven" in opening sentence of "XSD for SMI * Corrected "ten" to "eleven" in opening sentence of "XSD for SMI
Datatypes" section. Datatypes" section.
* Temoved conditional wording that previously prefaced the XSD * Removed conditional wording that previously prefaced the XSD
itself. 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 MITRE
7515 Colshire Dr 7515 Colshire Dr
MS H405 MS H405
McLean, VA 22102 McLean, VA 22102
USA USA
Phone: +1 703-983-2505 Phone: +1 703-983-2505
Email: rnatale@mitre.org 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 Full Copyright Statement
Copyright (C) The IETF Trust (2008). Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
 End of changes. 18 change blocks. 
43 lines changed or deleted 53 lines changed or added

This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/