Network Working Group M. Ellison
Internet-Draft Ellison Software Consulting
Intended status: Standards Track B. Natale
Expires: April 9, 2012 MITRE
October 7, 2011
Expressing SNMP SMI Textual Conventions in XML Schema Definition
Language
draft-ellison-opsawg-smi-textual-conventions-xsd-00.txt
Abstract
This memo defines the IETF standard expression of Structure of
Management Information (SMI) textual conventions 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.
Status of this Memo
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). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on April 9, 2012.
Copyright Notice
Copyright (c) 2011 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
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Ellison & Natale Expires April 9, 2012 [Page 1]
Internet-Draft Expressing SNMP SMI TCs in XSD October 2011
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 8
5. Algorithmic Conversions . . . . . . . . . . . . . . . . . . . 9
5.1. Numeric Datatypes . . . . . . . . . . . . . . . . . . . . 10
5.1.1. Integer32 . . . . . . . . . . . . . . . . . . . . . . 10
5.1.2. INTEGER . . . . . . . . . . . . . . . . . . . . . . . 12
5.1.2.1. Named-Number Enumeration . . . . . . . . . . . . . 14
5.1.3. Unsigned32 . . . . . . . . . . . . . . . . . . . . . . 19
5.1.4. Gauge32 . . . . . . . . . . . . . . . . . . . . . . . 20
5.1.5. Counter32 . . . . . . . . . . . . . . . . . . . . . . 22
5.1.6. TimeTicks . . . . . . . . . . . . . . . . . . . . . . 23
5.1.7. Counter64 . . . . . . . . . . . . . . . . . . . . . . 23
5.2. OCTET STRING . . . . . . . . . . . . . . . . . . . . . . . 23
5.3. Opaque . . . . . . . . . . . . . . . . . . . . . . . . . . 26
5.4. IpAddress . . . . . . . . . . . . . . . . . . . . . . . . 26
5.5. OBJECT IDENTIFIER . . . . . . . . . . . . . . . . . . . . 27
5.6. The BITS Construct . . . . . . . . . . . . . . . . . . . . 28
6. XSD for SMI Textual Conventions . . . . . . . . . . . . . . . 42
7. Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . 57
7.1. Textual Conventions defined in SNMPv2-TC . . . . . . . . . 57
7.1.1. DisplayString . . . . . . . . . . . . . . . . . . . . 57
7.1.2. TruthValue . . . . . . . . . . . . . . . . . . . . . . 57
7.1.3. TestAndIncr . . . . . . . . . . . . . . . . . . . . . 57
7.1.4. RowPointer . . . . . . . . . . . . . . . . . . . . . . 58
7.1.5. RowStatus . . . . . . . . . . . . . . . . . . . . . . 58
7.1.6. TimeStamp . . . . . . . . . . . . . . . . . . . . . . 59
7.1.7. TimeInterval . . . . . . . . . . . . . . . . . . . . . 59
7.1.8. StorageType . . . . . . . . . . . . . . . . . . . . . 59
7.1.9. MacAddress . . . . . . . . . . . . . . . . . . . . . . 59
7.2. Textual Conventions defined in SNMP-FRAMEWORK-MIB . . . . 59
7.2.1. SnmpAdminString . . . . . . . . . . . . . . . . . . . 60
7.3. Textual Conventions defined in SYSAPPL-MIB . . . . . . . . 60
7.3.1. Utf8String . . . . . . . . . . . . . . . . . . . . . . 60
7.3.2. LongUtf8String . . . . . . . . . . . . . . . . . . . . 61
7.4. Textual Conventions defined in RMON2-MIB . . . . . . . . . 61
7.4.1. ZeroBasedCounter32 . . . . . . . . . . . . . . . . . . 61
7.5. Textual Conventions defined in HCNUM-MIB . . . . . . . . . 61
7.5.1. ZeroBasedCounter64 . . . . . . . . . . . . . . . . . . 61
7.5.2. CounterBasedGauge64 . . . . . . . . . . . . . . . . . 62
Ellison & Natale Expires April 9, 2012 [Page 2]
Internet-Draft Expressing SNMP SMI TCs in XSD October 2011
7.6. Textual Conventions defined in IF-MIB . . . . . . . . . . 62
7.6.1. InterfaceIndex . . . . . . . . . . . . . . . . . . . . 62
7.6.2. InterfaceIndexOrZero . . . . . . . . . . . . . . . . . 62
7.7. Textual Conventions defined in ENTITY-MIB . . . . . . . . 63
7.7.1. PhysicalIndex . . . . . . . . . . . . . . . . . . . . 63
7.7.2. PhysicalIndexOrZero . . . . . . . . . . . . . . . . . 63
7.8. Textual Conventions defined in INET-ADDRESS-MIB . . . . . 63
7.8.1. InetAddressType . . . . . . . . . . . . . . . . . . . 63
7.8.2. InetAddress . . . . . . . . . . . . . . . . . . . . . 64
7.8.3. InetAddressIPv4 . . . . . . . . . . . . . . . . . . . 64
7.8.4. InetZoneIndex . . . . . . . . . . . . . . . . . . . . 64
7.8.5. InetAddressIPv4z . . . . . . . . . . . . . . . . . . . 65
7.8.6. InetAddressIPv6 . . . . . . . . . . . . . . . . . . . 65
7.8.7. InetAddressIPv6z . . . . . . . . . . . . . . . . . . . 65
7.8.8. InetAddressDNS . . . . . . . . . . . . . . . . . . . . 65
7.8.9. InetAddressPrefixLength . . . . . . . . . . . . . . . 66
7.8.10. InetPortNumber . . . . . . . . . . . . . . . . . . . . 67
7.8.11. InetAutonomousSystemNumber . . . . . . . . . . . . . . 67
7.8.12. InetScopeType . . . . . . . . . . . . . . . . . . . . 67
7.8.13. InetVersion . . . . . . . . . . . . . . . . . . . . . 67
7.9. Textual Conventions defined in TRANSPORT-ADDRESS-MIB . . . 68
7.9.1. TransportDomain . . . . . . . . . . . . . . . . . . . 68
7.9.2. TransportAddressType . . . . . . . . . . . . . . . . . 68
7.9.3. TransportAddress . . . . . . . . . . . . . . . . . . . 69
7.10. Textual Conventions defined in PerfHist-TC-MIB . . . . . . 69
7.10.1. PerfCurrentCount . . . . . . . . . . . . . . . . . . . 69
7.10.2. PerfIntervalCount . . . . . . . . . . . . . . . . . . 70
7.10.3. PerfTotalCount . . . . . . . . . . . . . . . . . . . . 70
7.11. Textual Conventions defined in HC-PerfHist-TC-MIB . . . . 70
7.11.1. HCPerfValidIntervals . . . . . . . . . . . . . . . . . 70
7.11.2. HCPerfInvalidIntervals . . . . . . . . . . . . . . . . 70
7.11.3. HCPerfTimeElapsed . . . . . . . . . . . . . . . . . . 71
7.11.4. HCPerfIntervalThreshold . . . . . . . . . . . . . . . 71
7.11.5. HCPerfCurrentCount . . . . . . . . . . . . . . . . . . 71
7.11.6. HCPerfIntervalCount . . . . . . . . . . . . . . . . . 71
7.11.7. HCPerfTotalCount . . . . . . . . . . . . . . . . . . . 72
7.12. Textual Conventions defined in ITU-ALARM-TC-MIB . . . . . 72
7.12.1. ItuPerceivedSeverity . . . . . . . . . . . . . . . . . 72
7.12.2. ItuTrendIndication . . . . . . . . . . . . . . . . . . 73
7.13. Textual Conventions defined in ENTITY-STATE-TC-MIB . . . . 73
7.13.1. EntityAdminState . . . . . . . . . . . . . . . . . . . 73
7.13.2. EntityOperState . . . . . . . . . . . . . . . . . . . 73
7.13.3. EntityUsageState . . . . . . . . . . . . . . . . . . . 73
7.13.4. EntityAlarmStatus . . . . . . . . . . . . . . . . . . 73
7.13.5. EntityStandbyStatus . . . . . . . . . . . . . . . . . 74
7.14. Textual Conventions defined in Q-BRIDGE-MIB . . . . . . . 74
7.14.1. VlanId . . . . . . . . . . . . . . . . . . . . . . . . 74
7.14.2. VlanIdOrAny . . . . . . . . . . . . . . . . . . . . . 74
Ellison & Natale Expires April 9, 2012 [Page 3]
Internet-Draft Expressing SNMP SMI TCs in XSD October 2011
7.14.3. VlanIdOrNone . . . . . . . . . . . . . . . . . . . . . 75
8. Security Considerations . . . . . . . . . . . . . . . . . . . 76
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 77
9.1. SMI Textual Conventions Namespace Registration . . . . . . 77
9.2. SMI Textual Conventions Schema Registration . . . . . . . 77
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 78
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 79
11.1. Normative References . . . . . . . . . . . . . . . . . . . 79
11.2. Informative References . . . . . . . . . . . . . . . . . . 81
Appendix A. Open Issues . . . . . . . . . . . . . . . . . . . . . 82
Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 83
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 84
Ellison & Natale Expires April 9, 2012 [Page 4]
Internet-Draft Expressing SNMP SMI TCs in XSD October 2011
1. Introduction
The use of a standard mapping from SMI textual conventions to XML via
XSD validation enables and promotes the efficient reuse of existing
and future MIB modules and instrumentation by XML-based protocols and
management applications. This standard mapping enables and
facilitates improvements to the timeliness, accuracy and utility of
management information.
This memo defines the standard expression of SMI textual conventions
in XML documents that is both uniform and interoperable. This
standard mapping enables Internet operators, management application
developers, and users to benefit from a wider range of management
tools and to benefit from a greater degree of unified management.
Numerous use cases exist for expressing the management information
described by SMI Management Information Base (MIB) modules in XML
[XML]. Potential use cases reside both outside and within the
traditional IETF network management community. For example,
developers of some XML-based management applications may want to
incorporate the rich set of data models provided by MIB modules.
Developers of other XML-based management applications may want to
access MIB module instrumentation via gateways to SNMP agents. Such
applications benefit from the IETF standard mapping of SMI textual
conventions to XML datatypes via XSD [XMLSchema], [XSDDatatypes].
Ellison & Natale Expires April 9, 2012 [Page 5]
Internet-Draft Expressing SNMP SMI TCs in XSD October 2011
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].
Ellison & Natale Expires April 9, 2012 [Page 6]
Internet-Draft Expressing SNMP SMI TCs in XSD October 2011
3. Overview
Developers of certain XML-based management applications will find the
specification defined in RFC 5935 [RFC5935] sufficient for their
purposes. Developers of other XML-based management applications may
need to make more complete reuse of existing MIB modules, requiring
standard XSD documents for TCs [RFC2579] and MIB structure [RFC2578].
This memo builds upon the mappings of SMI base datatypes as published
in RFC 5935 by specifying mappings for SMI textual conventions.
Support of RFC 5935 is prerequisite to support of the mappings
defined in this memo.
The SMI allows for the creation of derivative datatypes, "textual
conventions" ("TCs") [RFC2579]. A TC has a unique name, has a syntax
that either refines or is a base SMI datatype and has relatively
precise application-level semantics. TCs facilitate correct
application-level handling of MIB data, improve readability of MIB
modules by humans and support appropriate renderings of MIB data.
Textual conventions can be mapped using an algorithmic approach.
This memo discusses both the application of a standard algorithmic
mapping for TCs and specifies XSD mappings for a set of widely used
TCs.
Note that the semantics of textual conventions are "applied" to
values by a management application, for example a command generator
or notification receiver. Such values in varbinds "on-the-wire" are
always encoded as the base SMI datatype underlying the textual
convention syntax.
Ellison & Natale Expires April 9, 2012 [Page 7]
Internet-Draft Expressing SNMP SMI TCs in XSD October 2011
4. 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 represent the applied semantics of
textual conventions as defined by the SMI:
R1. SMIv2 is the normative SMI for this document. Textual
conventions were first introduced in SMIv2. Any textual
conventions informally defined in an SMIv1 module MUST be
converted (at least logically) in accordance with Section 2.1,
inclusive, of the "Coexistence" RFC [RFC3584].
R2. The XSD base datatype of restriction facets specified for a
given SMI textual convention MUST be defined within section 4 of
the "Expressing SNMP SMI Datatypes in XSD" RFC [RFC5935], or be
defined within this memo.
R3. The XSD datatype specified for a given SMI textual convention
MUST be defined with the fewest necessary restriction facets on
its set of values, consistent with the following requirements.
R4. The XSD restriction facet(s) specified for a given SMI textual
convention MUST be able to represent all valid values and
semantics for that SMI textual convention.
R5. The XSD restriction facet(s) specified for a given SMI textual
convention MUST represent any special encoding rules associated
with that SMI textual convention.
R6. The XSD restriction facet(s) specified for a given SMI textual
convention MUST include any restrictions on values associated
with the SMI textual convention.
R7. The XML output produced as a result of meeting the foregoing
requirements SHOULD be the most coherent and succinct
representation (i.e., avoiding superfluous "decoration") from
the perspective of readability by humans.
Ellison & Natale Expires April 9, 2012 [Page 8]
Internet-Draft Expressing SNMP SMI TCs in XSD October 2011
5. Algorithmic Conversions
[TODO: discuss, add text describing xs:element .vs. xs:
simpleType...for this draft revision algorithmic conversions, MUST be
simpletype.]
[TODO: discuss, add text describing mapping of the units clause and
the display hints clause]
SMI textual conventions may be built upon any SMI base datatype.
[TODO: call out limits of refinements for certain SMI bas datatypes?
(e.g. OBJECT IDENTIFIER)]
The algorithmic mapping from an SMI textual convention to an XML
Schema Definition (XSD) MUST provide a faithful and consistent
representation of management information ((for which no cannonical
XSD mapping is published)).
For all algorithmic mappings, the following XSD facets are required:
* QName
The local portion of the Qname MUST be the same as the name of
the SMI textual convention. For example, the local portion of
the Qname for the DisplayString TC defined in SNMPv2-TC [RFC2579]
MUST be "DisplayString".
* Opening tag
The opening tag MUST be where
XsdName is the name of the SMI textual convention.
* XML datatype
The mapping of the base XML datatype varies according to the SMI
datatype. The algorithm for mapping to the proper XML datatype
is discussed in the following sections.
* Value constraints
The mapping of the value constraints vary according to the SMI
datatype and the semantics of the SMI textual convention. The
algorithm for mapping value constraints is discussed in the
following sections.
Ellison & Natale Expires April 9, 2012 [Page 9]
Internet-Draft Expressing SNMP SMI TCs in XSD October 2011
* Closing tag
The closing tag MUST be
Within the following sections, the namespace 'smi' is used to refer
to the XML schema defined in RFC 5935.
5.1. Numeric Datatypes
This section discusses standard algorithms for the mapping of base
XML datatypes and XML value constraints for textual conventions that
are based upon SMI numeric datatypes.
The SMI datatypes INTEGER, Integer32, Unsigned32 and Gauge32 may be
sub-typed to represent a more constrained value range by raising the
lower-bounds, by reducing the upper-bounds,and/or by reducing the
alternative value/range choices.
Thus, textual conventions based upon the SMI datatypes INTEGER,
Integer32, Unsigned32 and Gauge32 rely upon a mapping to a value
range or a mapping to the union of a set of value ranges. Each value
range consists of a minimum inclusive value and a maximum inclusive
value.
In the case of a value range consisting of a single value, for
example "0", the value range is sufficiently described by a mapping
to an enumeration with a value of "0". Such a mapping is considered
an equivalent mapping to a value range with a minimum inclusive value
of "0" and a maximum inclusive value of "0".
The SMI datatype INTEGER may be sub-typed to represent an enumeration
of one or more named-numbers.
Thus, textual conventions based upon the SMI datatype INTEGER with a
enumeration of named-numbers rely upon a mapping to an enumeration of
values where each value is the label of a named-number.
Additional detail and examples are presented in the following
sections. Note that the specification on sections for INTEGER,
Integer32, Unsigned32 and Gauge32 are similar in nature. These
specifications are maintained in four separate sections to provide an
easier reference by practitioners.
5.1.1. Integer32
For the algorithmic mapping of textual conventions based upon the SMI
Integer32 datatype, the following XSD facets are required:
Ellison & Natale Expires April 9, 2012 [Page 10]
Internet-Draft Expressing SNMP SMI TCs in XSD October 2011
* XML datatype
An XSD mapping of MUST be
used.
* Value constraints
An XSD mapping for each value range of:
Where MIN is the low value of the range and MAX is the high value
of the range.
A value range consisting of a single value MAY be mapped using an
enumeration:
Where SINGLETON is the single value comprising the range.
Multiple value ranges are represented by a union among the set of
value ranges.
* Examples:
- SYNTAX Integer32 (-640..630)
- SYNTAX Integer32 (-640..630 | 500..925)
Ellison & Natale Expires April 9, 2012 [Page 11]
Internet-Draft Expressing SNMP SMI TCs in XSD October 2011
- SYNTAX Integer32 (0|4096|8192|12288|16384)
- SYNTAX Integer32 (0 | 128..255 | 325 | 400)
5.1.2. INTEGER
For the algorithmic mapping of textual conventions based upon the SMI
INTEGER datatype when named-number enumerations are not present, the
following XSD facets are required:
Ellison & Natale Expires April 9, 2012 [Page 12]
Internet-Draft Expressing SNMP SMI TCs in XSD October 2011
* XML datatype
An xsd mapping of MUST be
used.
* Value constraints
An XSD mapping for each value range of:
Where MIN is the low value of the range and MAX is the high value
of the range.
A value range consisting of a single value MAY be mapped using an
enumeration:
Where SINGLETON is the single value comprising the range.
Multiple value ranges are represented by a union among the set of
value ranges.
* Examples:
- SYNTAX INTEGER (-640..630)
- SYNTAX INTEGER (-640..630 | 500..925)
Ellison & Natale Expires April 9, 2012 [Page 13]
Internet-Draft Expressing SNMP SMI TCs in XSD October 2011
- SYNTAX INTEGER (0|4096|8192|12288|16384)
- SYNTAX INTEGER (0 | 128..255 | 325 | 400)
5.1.2.1. Named-Number Enumeration
For the algorithmic mapping of textual conventions based upon the SMI
INTEGER datatype when named-number enumerations are present, the
following XSD facets are required:
Ellison & Natale Expires April 9, 2012 [Page 14]
Internet-Draft Expressing SNMP SMI TCs in XSD October 2011
* XML datatype
An xsd mapping of MUST be used.
The following XSD datatype specifies the NamedNumber simpleType:
* Value constraints
Exactly one named-number of an enumeration may be present as a
value:
Where VALUE is the label of a named-number within the
enumeration.
Examples of textual conventions based upon a named-number
enumeration include:
* defined in SNMPv2-TC[RFC2579]
+ TruthValue has the following SMIv2 Syntax clause:
Ellison & Natale Expires April 9, 2012 [Page 15]
Internet-Draft Expressing SNMP SMI TCs in XSD October 2011
SYNTAX INTEGER { true(1),
false(2)
}
and algorithmically maps to the following XSD simpleType:
+ RowStatus has the following SMIv2 Syntax clause:
SYNTAX INTEGER { active(1),
notInService(2),
notReady(3),
createAndGo(4),
createAndWait(5),
destroy(6) }
and algorithmically maps to the following XSD simpleType:
+ StorageType has the following SMIv2 Syntax clause:
Ellison & Natale Expires April 9, 2012 [Page 16]
Internet-Draft Expressing SNMP SMI TCs in XSD October 2011
SYNTAX INTEGER { other(1),
volatile(2),
nonVolatile(3),
permanent(4),
readOnly(5) }
* defined in INET-ADDRESS-MIB[RFC4001]
+ InetAddressType has the following SMIv2 Syntax clause:
SYNTAX INTEGER { unknown(0),
ipv4(1),
ipv6(2),
ipv4z(3),
ipv6z(4),
dns(16) }
and algorithmically maps to the following XSD simpleType:
+ InetScopeType has the following SMIv2 Syntax clause:
Ellison & Natale Expires April 9, 2012 [Page 17]
Internet-Draft Expressing SNMP SMI TCs in XSD October 2011
SYNTAX INTEGER { -- reserved(0),
interfaceLocal(1),
linkLocal(2),
subnetLocal(3),
adminLocal(4),
siteLocal(5), -- site-local unicast
-- addresses have been
-- deprecated by RFC 3879
-- unassigned(6),
-- unassigned(7),
organizationLocal(8),
-- unassigned(9),
-- unassigned(10),
-- unassigned(11),
-- unassigned(12),
-- unassigned(13),
global(14)
-- reserved(15) }
and algorithmically maps to the following XSD simpleType:
+ InetVersion has the following SMIv2 Syntax clause:
SYNTAX INTEGER { unknown(0),
ipv4(1),
ipv6(2) }
and algorithmically maps to the following XSD simpleType:
Ellison & Natale Expires April 9, 2012 [Page 18]
Internet-Draft Expressing SNMP SMI TCs in XSD October 2011
5.1.3. Unsigned32
For the algorithmic mapping of textual conventions based upon the SMI
Unsigned32 datatype, the following XSD facets are required:
* XML datatype
An xsd mapping of MUST be
used.
* Value constraints
An XSD mapping for each value range of:
Where MIN is the low value of the range and MAX is the high value
of the range.
A value range consisting of a single value MAY be mapped using an
enumeration:
Where SINGLETON is the single value comprising the range.
Multiple value ranges are represented by a union among the set of
value ranges.
* Examples:
- SYNTAX Unsigned32 (40..630)
- SYNTAX Unsigned32 (40..630 | 500..925)
Ellison & Natale Expires April 9, 2012 [Page 19]
Internet-Draft Expressing SNMP SMI TCs in XSD October 2011
- SYNTAX Unsigned32 (0|4096|8192|12288|16384)
- SYNTAX Unsigned32 (0 | 128..255 | 325 | 400)
5.1.4. Gauge32
For the algorithmic mapping of textual conventions based upon the SMI
Gauge32 datatype, the following XSD facets are required:
Ellison & Natale Expires April 9, 2012 [Page 20]
Internet-Draft Expressing SNMP SMI TCs in XSD October 2011
* XML datatype
An xsd mapping of MUST be
used.
* Value constraints
An XSD mapping for each value range of:
Where MIN is the low value of the range and MAX is the high value
of the range.
A value range consisting of a single value MAY be mapped using an
enumeration:
Where SINGLETON is the single value comprising the range.
Multiple value ranges are represented by a union among the set of
value ranges.
* Examples:
- SYNTAX Gauge32 (40..630)
- SYNTAX Gauge32 (40..630 | 500..925)
Ellison & Natale Expires April 9, 2012 [Page 21]
Internet-Draft Expressing SNMP SMI TCs in XSD October 2011
- SYNTAX Gauge32 (0|4096|8192|12288|16384)
- SYNTAX Gauge32 (0 | 128..255 | 325 | 400)
5.1.5. Counter32
For the algorithmic mapping of textual conventions based upon the SMI
Gauge32 datatype, the following XSD facets are required:
Ellison & Natale Expires April 9, 2012 [Page 22]
Internet-Draft Expressing SNMP SMI TCs in XSD October 2011
* XML datatype
An xsd mapping of MUST be
used.
* Value constraints
No value constraints are possible for textual conventions based
upon the SMI Counter32 datatype.
5.1.6. TimeTicks
For the algorithmic mapping of textual conventions based upon the SMI
Gauge32 datatype, the following XSD facets are required:
* XML datatype
An xsd mapping of MUST be
used.
* Value constraints
No value constraints are possible for textual conventions based
upon the SMI TimeTicks datatype.
5.1.7. Counter64
For the algorithmic mapping of textual conventions based upon the SMI
Counter32 datatype, the following XSD facets are required:
* XML datatype
An xsd mapping of MUST be
used.
* Value constraints
No value constraints are possible for textual conventions based
upon the SMI Counter64 datatype.
5.2. OCTET STRING
For the algorithmic mapping of textual conventions based upon the SMI
OCTET STRING datatype, the following XSD facets are required:
Ellison & Natale Expires April 9, 2012 [Page 23]
Internet-Draft Expressing SNMP SMI TCs in XSD October 2011
* XML datatype
An xsd mapping of MUST be
used.
* Value constraints
Size constraints are possible. pattern constraints are possible.
Character subsets are possible.
The SMI OCTET STRING base datatype may be used to represent
information as a displayable text string or may be used to represent
information as a binary octet string.
Examples of textual conventions conveying a displayable OCTET STRING
include:
o defined in SNMPv2-TC[RFC2579]
- DisplayString has the following SMIv2 Syntax clause:
OCTET STRING (SIZE (0..255))
and algorithmically maps to the following XSD simpleType:
o defined in SNMP-FRAMEWORK-MIB[RFC3411]
- SnmpAdminString has the following SMIv2 Syntax clause:
Ellison & Natale Expires April 9, 2012 [Page 24]
Internet-Draft Expressing SNMP SMI TCs in XSD October 2011
OCTET STRING (SIZE (0..255))
and algorithmically maps to the following XSD simpleType:
o defined in SYSAPPL-MIB[RFC2287]
- LongUtf8String has the following SMIv2 Syntax clause:
OCTET STRING (SIZE (0..1024))
and algorithmically maps to the following XSD simpleType:
- Utf8String has the following SMIv2 Syntax clause:
OCTET STRING (SIZE (0..255))
and algorithmically maps to the following XSD simpleType:
Examples of textual conventions conveying a binary OCTET STRING
include:
o defined in SNMPv2-TC[RFC2579]
Ellison & Natale Expires April 9, 2012 [Page 25]
Internet-Draft Expressing SNMP SMI TCs in XSD October 2011
- MacAddress has the following SMIv2 Syntax clause:
OCTET STRING (SIZE (6))
and algorithmically maps to the following XSD simpleType:
- DateAndTime has the following SMIv2 Syntax clause:
OCTET STRING (SIZE (8 | 11))
and algorithmically maps to the following XSD simpleType:
5.3. Opaque
There are no IETF Standards Track Textual Conventions defined using
an SMI base type of Opaque. The OCTET STRING SMI base type provides
sufficient and complete support for any TC that would otherwise be
based upon Opaque.
RFC 5935 includes an XML mapping for the Opaque base type for
completeness and historic purposes.
Thus, there is no need for a mapping for TCs based upon Opaque.
5.4. IpAddress
There are no IETF Standards Track Textual Conventions defined using
an SMI base type of IpAddress. The InetAddressType and InetAddress
TCs defined within RFC 4001, provide sufficient and complete mapping
for any IPv4, IPv6 or DNS internet address.
RFC 5935 includes an XML mapping for the IpAddress base type for
Ellison & Natale Expires April 9, 2012 [Page 26]
Internet-Draft Expressing SNMP SMI TCs in XSD October 2011
completeness and historic purposes.
Thus, there is no need for a mapping for TCs based upon IpAddress.
5.5. OBJECT IDENTIFIER
For the algorithmic mapping of textual conventions based upon the SMI
OBJECT IDENTIFIER base datatype, the following XSD facets are
required:
* XML datatype
An xsd mapping of
MUST be used.
* Value constraints
No value constraints are possible for textual conventions based
upon the SMI OBJECT IDENTIFIER datatype.
There are a number of IETF Standards Track Textual Conventions
defined using an SMI base type of OBJECT IDENTIFIER. These TCs
include the following:
o defined in SNMPv2-TC:
* AutonomousType
* VariablePointer
* RowPointer
* TDomain
o defined in ACCOUNTING-CONTROL-MIB:
* DataCollectionSubtree
o defined in ALARM-MIB:
* alarmModelLastChanged
o defined in APM-MIB:
* DataSourceOrZero
Ellison & Natale Expires April 9, 2012 [Page 27]
Internet-Draft Expressing SNMP SMI TCs in XSD October 2011
o defined in HOST-RESOURCES-MIB:
* ProductID
o defined in RMON2-MIB:
* DataSource
o defined in SMON-MIB:
* SmonDataSource
The algorithmic mappings of all TCs based upon the SMI OBJECT
IDENTIFIER base datatype follow the same form. For example,
RowPointer is mapped as:
5.6. The BITS Construct
For the algorithmic mapping of textual conventions based upon the SMI
BITS construct, the following XSD facets are required:
* XML datatype
An xsd mapping of MUST be
used.
The following XSD datatype specifies the NamedBit simpleType:
Ellison & Natale Expires April 9, 2012 [Page 28]
Internet-Draft Expressing SNMP SMI TCs in XSD October 2011
* Value constraints
Zero, one or more named-bits may be present as a list value.
First, we map the named-bits:
.
.
.
Where BITSENUM MUST be the TC name appended with "BitNames" and
VALUE MUST be the label of a named-number within the enumeration.
Second we create the XSD mapping the BITS TC as follows:
Where BITSTC is the TC name. Note there is no maxLength facet
specified because XML value sets are limited to the restricted
list of NamedBit value choices. In the event that an XML value
set contains additional value choices, then each additional value
choice must be a duplicate of a NamedBit a previous value choice.
The effect is equivalent of specifying a specific bit to be set
more than once. Thus, the maxLength facet is considered
unnecessary.
If, for some application specific reason, a maxLength facet is
considered desirable, then the following schema production SHOULD
be used:
Where LEN is the numeric maxLength value.
Ellison & Natale Expires April 9, 2012 [Page 29]
Internet-Draft Expressing SNMP SMI TCs in XSD October 2011
Examples of textual conventions based upon the BITS construct
include:
o defined in ADSL2-LINE-TC-MIB[RFC4706]
* Adsl2TransmissionModeType has the following SMIv2 Syntax
clause:
SYNTAX BITS {
ansit1413(0),
etsi(1),
g9921PotsNonOverlapped(2),
g9921PotsOverlapped(3),
g9921IsdnNonOverlapped(4),
g9921isdnOverlapped(5),
g9921tcmIsdnNonOverlapped(6),
g9921tcmIsdnOverlapped(7),
g9922potsNonOverlapped(8),
g9922potsOverlapped(9),
g9922tcmIsdnNonOverlapped(10),
g9922tcmIsdnOverlapped(11),
g9921tcmIsdnSymmetric(12),
reserved1(13),
reserved2(14),
reserved3(15),
reserved4(16),
reserved5(17),
g9923PotsNonOverlapped(18),
g9923PotsOverlapped(19),
g9923IsdnNonOverlapped(20),
g9923isdnOverlapped(21),
reserved6(22),
reserved7(23),
g9924potsNonOverlapped(24),
g9924potsOverlapped(25),
reserved8(26),
reserved9(27),
g9923AnnexIAllDigNonOverlapped(28),
g9923AnnexIAllDigOverlapped(29),
g9923AnnexJAllDigNonOverlapped(30),
g9923AnnexJAllDigOverlapped(31),
g9924AnnexIAllDigNonOverlapped(32),
g9924AnnexIAllDigOverlapped(33),
g9923AnnexLMode1NonOverlapped(34),
g9923AnnexLMode2NonOverlapped(35),
g9923AnnexLMode3Overlapped(36),
g9923AnnexLMode4Overlapped(37),
g9923AnnexMPotsNonOverlapped(38),
Ellison & Natale Expires April 9, 2012 [Page 30]
Internet-Draft Expressing SNMP SMI TCs in XSD October 2011
g9923AnnexMPotsOverlapped(39),
g9925PotsNonOverlapped(40),
g9925PotsOverlapped(41),
g9925IsdnNonOverlapped(42),
g9925isdnOverlapped(43),
reserved10(44),
reserved11(45),
g9925AnnexIAllDigNonOverlapped(46),
g9925AnnexIAllDigOverlapped(47),
g9925AnnexJAllDigNonOverlapped(48),
g9925AnnexJAllDigOverlapped(49),
g9925AnnexMPotsNonOverlapped(50),
g9925AnnexMPotsOverlapped(51),
reserved12(52),
reserved13(53),
reserved14(54),
reserved15(55)
}
and algorithmically maps to the following XSD simpleType:
* Adsl2LConfProfPmMode has the following SMIv2 Syntax clause:
SYNTAX BITS {
allowTransitionsToIdle(0),
allowTransitionsToLowPower(1)
}
and algorithmically maps to the following XSD simpleType:
* Adsl2LineStatus has the following SMIv2 Syntax clause:
Ellison & Natale Expires April 9, 2012 [Page 33]
Internet-Draft Expressing SNMP SMI TCs in XSD October 2011
SYNTAX BITS {
noDefect(0),
lossOfFrame(1),
lossOfSignal(2),
lossOfPower(3),
initFailure(4)
}
and algorithmically maps to the following XSD simpleType:
* Adsl2ChAtmStatus has the following SMIv2 Syntax clause:
SYNTAX BITS {
noDefect(0),
noCellDelineation(1),
lossOfCellDelineation(2)
}
and algorithmically maps to the following XSD simpleType:
Ellison & Natale Expires April 9, 2012 [Page 34]
Internet-Draft Expressing SNMP SMI TCs in XSD October 2011
* Adsl2ChPtmStatus has the following SMIv2 Syntax clause:
SYNTAX BITS {
noDefect(0),
outOfSync(1)
}
and algorithmically maps to the following XSD simpleType:
o defined in ENTITY-STATE-TC-MIB[RFC4268]
* EntityAlarmStatus has the following SMIv2 Syntax clause:
Ellison & Natale Expires April 9, 2012 [Page 35]
Internet-Draft Expressing SNMP SMI TCs in XSD October 2011
SYNTAX BITS {
unknown(0),
underRepair(1),
critical(2),
major(3),
minor(4),
-- The following are not defined in X.733
warning(5),
indeterminate(6)
}
and algorithmically maps to the following XSD simpleType:
o defined in FC-MGMT-MIB[RFC4044]
* FcClasses has the following SMIv2 Syntax clause:
Ellison & Natale Expires April 9, 2012 [Page 36]
Internet-Draft Expressing SNMP SMI TCs in XSD October 2011
SYNTAX BITS {
classF(0),
class1(1),
class2(2),
class3(3),
class4(4),
class5(5),
class6(6)
}
and algorithmically maps to the following XSD simpleType:
* FcUnitFunctions has the following SMIv2 Syntax clause:
Ellison & Natale Expires April 9, 2012 [Page 37]
Internet-Draft Expressing SNMP SMI TCs in XSD October 2011
SYNTAX BITS {
other(0), -- none of the following
hub(1),
switch(2),
bridge(3),
gateway(4),
host(5),
storageSubsys(6),
storageAccessDev(7),
nas(8),
wdmux(9),
storageDevice(10)
}
and algorithmically maps to the following XSD simpleType:
o defined in NAT-MIB[RFC4008]
* NatProtocolMap has the following SMIv2 Syntax clause:
Ellison & Natale Expires April 9, 2012 [Page 38]
Internet-Draft Expressing SNMP SMI TCs in XSD October 2011
SYNTAX BITS {
other(0),
icmp(1),
udp(2),
tcp(3)
}
and algorithmically maps to the following XSD simpleType:
* NatTranslationEntity has the following SMIv2 Syntax clause:
SYNTAX BITS {
inboundSrcEndPoint(0),
outboundDstEndPoint(1),
inboundDstEndPoint(2),
outboundSrcEndPoint(3)
}
and algorithmically maps to the following XSD simpleType:
Ellison & Natale Expires April 9, 2012 [Page 39]
Internet-Draft Expressing SNMP SMI TCs in XSD October 2011
o defined in SIP-TC-MIB[RFC4780]
* SipTCTransportProtocol has the following SMIv2 Syntax clause:
SYNTAX BITS {
other(0), -- none of the following
udp(1),
tcp(2),
sctp(3), -- RFC4168
tlsTcp(4),
tlsSctp(5) -- RFC 4168
}
and algorithmically maps to the following XSD simpleType:
* SipTCEntityRole has the following SMIv2 Syntax clause:
Ellison & Natale Expires April 9, 2012 [Page 40]
Internet-Draft Expressing SNMP SMI TCs in XSD October 2011
SYNTAX BITS {
other(0),
userAgent(1),
proxyServer(2),
redirectServer(3),
registrarServer(4)
}
and algorithmically maps to the following XSD simpleType:
* SipTCOptionTagHeaders has the following SMIv2 Syntax clause:
SYNTAX BITS {
require(0), -- Require header
proxyRequire(1), -- Proxy-Require header
supported(2), -- Supported header
unsupported(3) -- Unsupported header
}
and algorithmically maps to the following XSD simpleType:
Ellison & Natale Expires April 9, 2012 [Page 41]
Internet-Draft Expressing SNMP SMI TCs in XSD October 2011
6. XSD for SMI Textual Conventions
This document provides XSD datatype mappings for the SMIv2 Textual
Conventions based upon "BITS" pseudo-type and the eleven
"ObjectSyntax" datatypes defined in RFC 2578.
BEGIN
Mapping of SMIv2 Textual Conventions from RFC 2579
and other standards-track RFCs.
Contact: Mark Ellison
Organization: Ellison Software Consulting
Address: 38 Salem Road
Atkinson, NH 03811
USA
Telephone: +1 603-362-9270
E-Mail: ietf@EllisonSoftware.com
Contact: Bob Natale
Organization: MITRE
Address: 300 Sentinel Drive
6th Floor
Annapolis Junction, MD 20701
USA
Telephone: +1 301-617-3008
E-Mail: rnatale@mitre.org
Last Updated: 201107150000Z
Copyright (c) 2011 IETF Trust and the persons
Ellison & Natale Expires April 9, 2012 [Page 42]
Internet-Draft Expressing SNMP SMI TCs in XSD October 2011
identified as the document authors. All rights
reserved.
Redistribution and use in source and binary forms,
with or without modification, is permitted pursuant
to, and subject to the license terms contained in,
the Simplified BSD License set forth in Section
4.c of the IETF Trust's Legal Provisions Relating to
IETF Documents (http://trustee.ietf.org/license-info).
This version of this XML Schema Definition (XSD)
document is part of RFC XXXX; see the RFC itself for
full legal notices."
RFC Editor - please replace XXXX with the value allocated
for publication as an RFC.
Ellison & Natale Expires April 9, 2012 [Page 43]
Internet-Draft Expressing SNMP SMI TCs in XSD October 2011
Ellison & Natale Expires April 9, 2012 [Page 44]
Internet-Draft Expressing SNMP SMI TCs in XSD October 2011
Ellison & Natale Expires April 9, 2012 [Page 45]
Internet-Draft Expressing SNMP SMI TCs in XSD October 2011
Ellison & Natale Expires April 9, 2012 [Page 46]
Internet-Draft Expressing SNMP SMI TCs in XSD October 2011
Ellison & Natale Expires April 9, 2012 [Page 47]
Internet-Draft Expressing SNMP SMI TCs in XSD October 2011
Ellison & Natale Expires April 9, 2012 [Page 48]
Internet-Draft Expressing SNMP SMI TCs in XSD October 2011
Ellison & Natale Expires April 9, 2012 [Page 49]
Internet-Draft Expressing SNMP SMI TCs in XSD October 2011
Ellison & Natale Expires April 9, 2012 [Page 50]
Internet-Draft Expressing SNMP SMI TCs in XSD October 2011
Ellison & Natale Expires April 9, 2012 [Page 51]
Internet-Draft Expressing SNMP SMI TCs in XSD October 2011
Ellison & Natale Expires April 9, 2012 [Page 52]
Internet-Draft Expressing SNMP SMI TCs in XSD October 2011
Ellison & Natale Expires April 9, 2012 [Page 54]
Internet-Draft Expressing SNMP SMI TCs in XSD October 2011
Ellison & Natale Expires April 9, 2012 [Page 55]
Internet-Draft Expressing SNMP SMI TCs in XSD October 2011
END
Ellison & Natale Expires April 9, 2012 [Page 56]
Internet-Draft Expressing SNMP SMI TCs in XSD October 2011
7. Rationale
7.1. Textual Conventions defined in SNMPv2-TC
7.1.1. DisplayString
This XSD datatype corresponds to the SMI "DisplayString" Textual
Convention.
A DisplayString syntax represents textual information taken from the
NVT ASCII character set, as defined in pages 4, 10-11 of RFC 854.
To summarize RFC 854, the NVT ASCII repertoire specifies:
o the use of character codes 0-127 (decimal)
o the graphics characters (32-126) are interpreted as US ASCII
o NUL, LF, CR, BEL, BS, HT, VT and FF have the special meanings
specified in RFC 854
o the other 25 codes have no standard interpretation
o the sequence 'CR LF' means newline
o the sequence 'CR NUL' means carriage-return
o an 'LF' not preceded by a 'CR' means moving to the same column on
the next line.
o the sequence 'CR x' for any x other than LF or NUL is illegal.
(Note that this also means that a string may end with either 'CR
LF' or 'CR NUL', but not with CR.)
Any object defined using this syntax may not exceed 255 characters in
length.
7.1.2. TruthValue
This XSD datatype corresponds to the SMI "TruthValue" Textual
Convention.
A TruthValue syntax represents a boolean value.
7.1.3. TestAndIncr
This XSD datatype corresponds to the SMI "TestAndIncr" Textual
Convention.
Ellison & Natale Expires April 9, 2012 [Page 57]
Internet-Draft Expressing SNMP SMI TCs in XSD October 2011
A TestAndIncr syntax represents integer-valued information used for
atomic operations. When the management protocol is used to specify
that an object instance having this syntax is to be modified, the new
value supplied via the management protocol must precisely match the
value presently held by the instance. If not, the management
protocol set operation fails with an error of `inconsistentValue'.
Otherwise, if the current value is the maximum value of 2^31-1
(2147483647 decimal), then the value held by the instance is wrapped
to zero; otherwise, the value held by the instance is incremented by
one. (Note that regardless of whether the management protocol set
operation succeeds, the variable- binding in the request and response
PDUs are identical.)
The value of the ACCESS clause for objects having this syntax is
either `read-write' or `read-create'. When an instance of a columnar
object having this syntax is created, any value may be supplied via
the management protocol. When the network management portion of the
system is re- initialized, the value of every object instance having
this syntax must either be incremented from its value prior to the
re-initialization, or (if the value prior to the re- initialization
is unknown) be set to a pseudo-randomly generated value.
7.1.4. RowPointer
Represents a pointer to an element instance. The value is an
absolute XPath expression that points to the instance.
7.1.5. RowStatus
This XSD datatype corresponds to the SMI "RowStatus" Textual
Convention as defined in SNMPv2-TC [RFC 2579].
A RowStatus syntax represents a set of enumerated string values as
follow:
o active
o notInService
o notReady
o createAndGo
o createAndWait
o destroy
Ellison & Natale Expires April 9, 2012 [Page 58]
Internet-Draft Expressing SNMP SMI TCs in XSD October 2011
7.1.6. TimeStamp
The value of the sysUpTime object at which a specific occurrence
happened. The sysUpTime object is that the time (in hundredths of a
second) since the network management portion of the system was last
re-initialized. The specific occurrence must be defined in the
description of any object defined using this type.
If sysUpTime is reset to zero as a result of a re- initialization of
the network management (sub)system, then the values of all TimeStamp
objects are also reset. However, after approximately 497 days
without a re- initialization, the sysUpTime object will reach 2^^32-1
and then increment around to zero; in this case, existing values of
TimeStamp objects do not change. This can lead to ambiguities in the
value of TimeStamp objects.
7.1.7. TimeInterval
A period of time, measured in units of 0.01 seconds.
7.1.8. StorageType
Describes the memory realization of a conceptual row. A row which is
volatile is lost upon reboot. A row which is either nonVolatile,
permanent or readOnly, is backed up by stable storage. A row which
is permanent can be changed but not deleted. A row which is readOnly
cannot be changed nor deleted.
If the value of an object with this syntax is either permanent or
readOnly, it cannot be written. Conversely, if the value is either
other, volatile or nonVolatile, it cannot be modified to be permanent
or readOnly.
Every usage of this datatype is required to specify the columnar
objects which a permanent row must at a minimum allow to be writable.
7.1.9. MacAddress
Represents an 802 MAC address represented in the `canonical' order
defined by IEEE 802.1a, i.e., as if it were transmitted least
significant bit first, even though 802.5 (in contrast to other 802.x
protocols) requires MAC addresses to be transmitted most significant
bit first.
7.2. Textual Conventions defined in SNMP-FRAMEWORK-MIB
Ellison & Natale Expires April 9, 2012 [Page 59]
Internet-Draft Expressing SNMP SMI TCs in XSD October 2011
7.2.1. SnmpAdminString
An octet string containing administrative information, preferably in
human-readable form.
To facilitate internationalization, this information is represented
using the ISO/IEC IS 10646-1 character set, encoded as an octet
string using the UTF-8 transformation format described in RFC3629.
Since additional code points are added by amendments to the 10646
standard from time to time, implementations must be prepared to
encounter any code point from 0x00000000 to 0x7fffffff. Byte
sequences that do not correspond to the valid UTF-8 encoding of a
code point or are outside this range are prohibited.
The use of control codes should be avoided.
When it is necessary to represent a newline, the control code
sequence CR LF should be used.
The use of leading or trailing white space should be avoided.
For code points not directly supported by user interface hardware or
software, an alternative means of entry and display, such as
hexadecimal, may be provided.
For information encoded in 7-bit US-ASCII, the UTF-8 encoding is
identical to the US-ASCII encoding.
UTF-8 may require multiple bytes to represent a single character /
code point; thus the length of this object in octets may be different
from the number of characters encoded. Similarly, size constraints
refer to the number of encoded octets, not the number of characters
represented by an encoding.
Note that the size of an SnmpAdminString object is measured in
octets, not characters.
7.3. Textual Conventions defined in SYSAPPL-MIB
7.3.1. Utf8String
To facilitate internationalization, this datatype represents
information taken from the ISO/IEC IS 10646-1 character set, encoded
as an octet string using the UTF-8 character encoding scheme
described in RFC 2044. For strings in 7-bit US-ASCII, there is no
impact since the UTF-8 representation is identical to the US-ASCII
encoding.
Ellison & Natale Expires April 9, 2012 [Page 60]
Internet-Draft Expressing SNMP SMI TCs in XSD October 2011
7.3.2. LongUtf8String
To facilitate internationalization, this datatype represents
information taken from the ISO/IEC IS 10646-1 character set, encoded
as an octet string using the UTF-8 character encoding scheme
described in RFC 2044. For strings in 7-bit US-ASCII, there is no
impact since the UTF-8 representation is identical to the US-ASCII
encoding.
7.4. Textual Conventions defined in RMON2-MIB
7.4.1. ZeroBasedCounter32
This datatype describes an object which counts events with the
following semantics: objects of this type will be set to zero(0) on
creation and will thereafter count appropriate events, wrapping back
to zero(0) when the value 2^32 is reached.
Provided that an application discovers the new object within the
minimum time to wrap it can use the initial value as a delta since it
last polled the table of which this object is part. It is important
for a management station to be aware of this minimum time and the
actual time between polls, and to discard data if the actual time is
too long or there is no defined minimum time.
Typically this datatype is used in tables where the INDEX space is
constantly changing and/or the TimeFilter mechanism is in use.
7.5. Textual Conventions defined in HCNUM-MIB
7.5.1. ZeroBasedCounter64
This datatype describes an object which counts events with the
following semantics: objects of this type will be set to zero(0) on
creation and will thereafter count appropriate events, wrapping back
to zero(0) when the value 2^64 is reached.
Provided that an application discovers the new object within the
minimum time to wrap it can use the initial value as a delta since it
last polled the table of which this object is part. It is important
for a management station to be aware of this minimum time and the
actual time between polls, and to discard data if the actual time is
too long or there is no defined minimum time.
Typically this datatype is used in tables where the INDEX space is
constantly changing and/or the TimeFilter mechanism is in use.
Note that this datatype does not retain all the semantics of the
Ellison & Natale Expires April 9, 2012 [Page 61]
Internet-Draft Expressing SNMP SMI TCs in XSD October 2011
Counter64 base type. Specifically, a Counter64 has an arbitrary
initial value, but objects defined with this datatype are required to
start at the value zero. This behavior is not likely to have any
adverse effects on management applications which are expecting
Counter64 semantics.
7.5.2. CounterBasedGauge64
This datatype represents a non-negative integer, which may increase
or decrease, but shall never exceed a maximum value, nor fall below a
minimum value. The maximum value can not be greater than 2^64-1
(18446744073709551615 decimal), and the minimum value can not be
smaller than 0. The value of a CounterBasedGauge64 has its maximum
value whenever the information being modeled is greater than or equal
to its maximum value, and has its minimum value whenever the
information being modeled is smaller than or equal to its minimum
value. If the information being modeled subsequently decreases below
(increases above) the maximum (minimum) value, the
CounterBasedGauge64 also decreases (increases).
Note that this datatype is not strictly supported in SMIv2, because
the 'always increasing' and 'counter wrap' semantics associated with
the Counter64 base type are not preserved. It is possible that
management applications which rely solely upon the (Counter64) ASN.1
tag to determine object semantics will mistakenly operate upon
objects of this type as they would for Counter64 objects.
7.6. Textual Conventions defined in IF-MIB
7.6.1. InterfaceIndex
A unique value, greater than zero, for each interface or interface
sub-layer in the managed system. It is recommended that values are
assigned contiguously starting from 1. The value for each interface
sub-layer must remain constant at least from one re-initialization of
the entity's network management system to the next re-initialization.
7.6.2. InterfaceIndexOrZero
This datatype is an extension of the InterfaceIndex datatype. The
latter defines a greater than zero value used to identify an
interface or interface sub-layer in the managed system. This
extension permits the additional value of zero. the value zero is
object-specific and must therefore be defined as part of the
description of any object which uses this syntax. Examples of the
usage of zero might include situations where interface was unknown,
or when none or all interfaces need to be referenced.
Ellison & Natale Expires April 9, 2012 [Page 62]
Internet-Draft Expressing SNMP SMI TCs in XSD October 2011
7.7. Textual Conventions defined in ENTITY-MIB
7.7.1. PhysicalIndex
An arbitrary value that uniquely identifies the physical entity. The
value should be a small, positive integer. Index values for
different physical entities are not necessarily contiguous.
7.7.2. PhysicalIndexOrZero
This datatype is an extension of the PhysicalIndex datatype, which
defines a greater than zero value used to identify a physical entity.
This extension permits the additional value of zero. The semantics
of the value zero are object-specific and must, therefore, be defined
as part of the description of any object that uses this syntax.
Examples of the usage of this extension are situations where none or
all physical entities need to be referenced."
7.8. Textual Conventions defined in INET-ADDRESS-MIB
7.8.1. InetAddressType
A value that represents a type of Internet address.
unknown An unknown address type. This value MUST be used if the
value of the corresponding InetAddress object is a zero-length
string. It may also be used to indicate an IP address that is not in
one of the formats defined below.
ipv4 An IPv4 address as defined by the InetAddressIPv4 datatype.
ipv6 An IPv6 address as defined by the InetAddressIPv6 datatype.
ipv4z A non-global IPv4 address including a zone index as defined by
the InetAddressIPv4z datatype.
ipv6z A non-global IPv6 address including a zone index as defined by
the InetAddressIPv6z datatype.
dns A DNS domain name as defined by the InetAddressDNS datatype.
Each definition of a concrete InetAddressType value must be
accompanied by a definition of a datatype for use with that
InetAddressType.
To support future extensions, the InetAddressType datatype SHOULD NOT
be sub-typed in object type definitions. It MAY be sub-typed in
compliance statements in order to require only a subset of these
Ellison & Natale Expires April 9, 2012 [Page 63]
Internet-Draft Expressing SNMP SMI TCs in XSD October 2011
address types for a compliant implementation.
Implementations must ensure that InetAddressType objects and any
dependent objects (e.g., InetAddress objects) are consistent. In
particular, InetAddressType/InetAddress pairs must be changed
together if the address type changes (e.g., from ipv6 to ipv4).
7.8.2. InetAddress
Denotes a generic Internet address. An InetAddress value is always
interpreted within the context of an InetAddressType value. Every
usage of the InetAddress datatype is required to specify the
InetAddressType object that provides the context. It is suggested
that the InetAddressType object be logically registered before the
object(s) that use the InetAddress datatype, if they appear in the
same logical row.
The value of an InetAddress object must always be consistent with the
value of the associated InetAddressType object. Attempts to set an
InetAddress object to a value inconsistent with the associated
InetAddressType must fail.
7.8.3. InetAddressIPv4
Represents an IPv4 network address.
This datatype SHOULD NOT be used directly in object definitions, as
it restricts addresses to a specific format. However, if it is used,
it MAY be used either on its own or in conjunction with
InetAddressType, as a pair."
7.8.4. InetZoneIndex
A zone index identifies an instance of a zone of a specific scope.
The zone index MUST disambiguate identical address values. For link-
local addresses, the zone index will typically be the interface index
(ifIndex as defined in the IF-MIB) of the interface on which the
address is configured.
The zone index may contain the special value 0, which refers to the
default zone. The default zone may be used in cases where the valid
zone index is not known (e.g., when a management application has to
write a link-local IPv6 address without knowing the interface index
value). The default zone SHOULD NOT be used as an easy way out in
cases where the zone index for a non-global IPv6 address is known.
Ellison & Natale Expires April 9, 2012 [Page 64]
Internet-Draft Expressing SNMP SMI TCs in XSD October 2011
7.8.5. InetAddressIPv4z
Represents a non-global IPv4 network address, together with its zone
index.
The corresponding InetAddressType value is 'ipv4z'.
The zone index is used to disambiguate identical address values on
nodes that have interfaces attached to different zones of the same
scope. The zone index may contain the special value 0, which refers
to the default zone for each scope.
This datatype SHOULD NOT be used directly in object definitions, as
it restricts addresses to a specific format. However, if it is used,
it MAY be used either on its own or in conjunction with
InetAddressType, as a pair.
7.8.6. InetAddressIPv6
Represents an IPv6 network address.
The corresponding InetAddressType value is 'ipv6'.
This datatype SHOULD NOT be used directly in object definitions, as
it restricts addresses to a specific format. However, if it is used,
it MAY be used either on its own or in conjunction with
InetAddressType, as a pair.
7.8.7. InetAddressIPv6z
Represents a non-global IPv6 network address, together with its zone
index.
The corresponding InetAddressType value is 'ipv6z'. The zone index
is used to disambiguate identical address values on nodes that have
interfaces attached to different zones of the same scope. The zone
index may contain the special value 0, which refers to the default
zone for each scope.
This datatype SHOULD NOT be used directly in object definitions, as
it restricts addresses to a specific format. However, if it is used,
it MAY be used either on its own or in conjunction with
InetAddressType, as a pair.
7.8.8. InetAddressDNS
Represents a DNS domain name. The name SHOULD be fully qualified
whenever possible.
Ellison & Natale Expires April 9, 2012 [Page 65]
Internet-Draft Expressing SNMP SMI TCs in XSD October 2011
The corresponding InetAddressType is dns.
The DESCRIPTION clause of InetAddress objects that may have
InetAddressDNS values MUST fully describe how (and when) these names
are to be resolved to IP addresses.
The resolution of an InetAddressDNS value may require to query
multiple DNS records (e.g., A for IPv4 and AAAA for IPv6). The order
of the resolution process and which DNS record takes precedence
depends on the configuration of the resolver.
This datatype SHOULD NOT be used directly in object definitions, as
it restricts addresses to a specific format. However, if it is used,
it MAY be used either on its own or in conjunction with
InetAddressType, as a pair.
7.8.9. InetAddressPrefixLength
Denotes the length of a generic Internet network address prefix. A
value of n corresponds to an IP address mask that has n contiguous
1-bits from the most significant bit (MSB), with all other bits set
to 0.
An InetAddressPrefixLength value is always interpreted within the
context of an InetAddressType value. Every usage of the
InetAddressPrefixLength datatype is required to specify the
InetAddressType object that provides the context. It is suggested
that the InetAddressType object be logically registered before the
object(s) that use the InetAddressPrefixLength datatype, if they
appear in the same logical row.
InetAddressPrefixLength values larger than the maximum length of an
IP address for a specific InetAddressType are treated as the maximum
significant value applicable for the InetAddressType. The maximum
significant value is 32 for the InetAddressType 'ipv4' and 'ipv4z'
and 128 for the InetAddressType 'ipv6' and 'ipv6z'. The maximum
significant value for the InetAddressType 'dns' is 0.
The value zero is object-specific and must be defined as part of the
description of any object that uses this syntax. Examples of the
usage of zero might include situations where the Internet network
address prefix is unknown or does not apply.
The upper bound of the prefix length has been chosen to be consistent
with the maximum size of an InetAddress.
Ellison & Natale Expires April 9, 2012 [Page 66]
Internet-Draft Expressing SNMP SMI TCs in XSD October 2011
7.8.10. InetPortNumber
Represents a 16 bit port number of an Internet transport layer
protocol. Port numbers are assigned by IANA. A current list of all
assignments is available from .
The value zero is object-specific and must be defined as part of the
description of any object that uses this syntax. Examples of the
usage of zero might include situations where a port number is
unknown, or when the value zero is used as a wildcard in a filter.
7.8.11. InetAutonomousSystemNumber
Represents an autonomous system number that identifies an Autonomous
System (AS). An AS is a set of routers under a single technical
administration, using an interior gateway protocol and common metrics
to route packets within the AS, and using an exterior gateway
protocol to route packets to other ASes'. IANA maintains the AS
number space and has delegated large parts to the regional
registries.
Autonomous system numbers had been limited to 16 bits (0..65535).
But they have been enlarged to 32 bits in RFC 4893 now. Therefore,
this datatype uses an unsignedInt value without a range restriction.
7.8.12. InetScopeType
Represents a scope type. This datatype can be used in cases where a
MIB has to represent different scope types and there is no context
information, such as an InetAddress object, that implicitly defines
the scope type.
Note that not all possible values have been assigned yet, but they
may be assigned in future revisions of this specification.
Applications should therefore be able to deal with values not yet
assigned.
7.8.13. InetVersion
A value representing a version of the IP protocol.
unknown An unknown or unspecified version of the IP protocol.
ipv4 The IPv4 protocol as defined in RFC 791 (STD 5).
ipv6 The IPv6 protocol as defined in RFC 2460.
Note that this datatype SHOULD NOT be used to distinguish different
Ellison & Natale Expires April 9, 2012 [Page 67]
Internet-Draft Expressing SNMP SMI TCs in XSD October 2011
address types associated with IP protocols. The InetAddressType has
been designed for this purpose.
7.9. Textual Conventions defined in TRANSPORT-ADDRESS-MIB
7.9.1. TransportDomain
A value that represents a transport domain.
7.9.2. TransportAddressType
A value that represents a transport domain. The enumerated values
have the following meaning:
o unknown unknown transport address type
o udpIpv4 transportDomainUdpIpv4
o udpIpv6 transportDomainUdpIpv6
o udpIpv4z transportDomainUdpIpv4z
o udpIpv6z transportDomainUdpIpv6z
o tcpIpv4 transportDomainTcpIpv4
o tcpIpv6 transportDomainTcpIpv6
o tcpIpv4z transportDomainTcpIpv4z
o tcpIpv6z transportDomainTcpIpv6z
o sctpIpv4 transportDomainSctpIpv4
o sctpIpv6 transportDomainSctpIpv6
o sctpIpv4z transportDomainSctpIpv4z
o sctpIpv6z transportDomainSctpIpv6z
o local transportDomainLocal
o udpDns transportDomainUdpDns
o tcpDns transportDomainTcpDns
o sctpDns transportDomainSctpDns
Ellison & Natale Expires April 9, 2012 [Page 68]
Internet-Draft Expressing SNMP SMI TCs in XSD October 2011
This datatype can be used to represent transport domains in
situations where a syntax of TransportDomain is unwieldy (for
example, when used as an index).
The usage of this datatype implies that additional transport domains
can only be supported by updating this MIB module. This
extensibility restriction does not apply for the TransportDomain
datatype which allows data model authors to define additional
transport domains independently in other data model modules.
7.9.3. TransportAddress
Denotes a generic transport address.
A TransportAddress value is always interpreted within the context of
a TransportAddressType or TransportDomain value. Every usage of the
TransportAddress datatype MUST specify the TransportAddressType or
TransportDomain object which provides the context. Furthermore, data
model authors SHOULD define a separate TransportAddressType or
TransportDomain object for each TransportAddress object. It is
suggested that the TransportAddressType or TransportDomain is
logically registered before the object(s) which use the
TransportAddress datatype if they appear in the same logical row.
The value of a TransportAddress object must always be consistent with
the value of the associated TransportAddressType or TransportDomain
object. Attempts to set a TransportAddress object to a value which
is inconsistent with the associated TransportAddressType or
TransportDomain must fail with an error.
7.10. Textual Conventions defined in PerfHist-TC-MIB
7.10.1. PerfCurrentCount
A counter associated with a performance measurement in a current 15
minute measurement interval. The value of this counter starts from
zero and is increased when associated events occur, until the end of
the 15 minute interval. At that time the value of the counter is
stored in the first 15 minute history interval, and the CurrentCount
is restarted at zero. In the case where the agent has no valid data
available for the current interval the corresponding object instance
is not available and upon a retrieval request a corresponding error
message shall be returned to indicate that this instance does not
exist.
Ellison & Natale Expires April 9, 2012 [Page 69]
Internet-Draft Expressing SNMP SMI TCs in XSD October 2011
7.10.2. PerfIntervalCount
A counter associated with a performance measurement in a previous 15
minute measurement interval. In the case where the agent has no
valid data available for a particular interval the corresponding
object instance is not available and upon a retrieval request a
corresponding error message shall be returned to indicate that this
instance does not exist.
In a system supporting a history of n intervals with most and least
recent intervals respectively, the following applies at the end of a
15 minute interval:
o discard the value of IntervalCount(n)
o the value of IntervalCount(i) becomes that of IntervalCount(i-1)
for n >= i > 1
o the value of IntervalCount(1) becomes that of CurrentCount
o the TotalCount, if supported, is adjusted.
7.10.3. PerfTotalCount
A counter associated with a performance measurements aggregating the
previous valid 15 minute measurement intervals. (Intervals for which
no valid data was available are not counted)
7.11. Textual Conventions defined in HC-PerfHist-TC-MIB
7.11.1. HCPerfValidIntervals
The number of near end intervals for which data was collected. The
value of an object with an HCPerfValidIntervals syntax will be 96
unless the measurement was (re-)started within the last 1440 minutes,
in which case the value will be the number of complete 15 minute
intervals for which the agent has at least some data. In certain
cases (e.g., in the case where the agent is a proxy) it is possible
that some intervals are unavailable. In this case, this interval is
the maximum interval number for which data is available.
7.11.2. HCPerfInvalidIntervals
The number of near end intervals for which no data is available. The
value of an object with an HCPerfInvalidIntervals syntax will
typically be zero except in cases where the data for some intervals
are not available (e.g., in proxy situations).
Ellison & Natale Expires April 9, 2012 [Page 70]
Internet-Draft Expressing SNMP SMI TCs in XSD October 2011
7.11.3. HCPerfTimeElapsed
The number of seconds that have elapsed since the beginning of the
current measurement period. If, for some reason, such as an
adjustment in the system's time-of-day clock or the addition of a
leap second, the duration of the current interval exceeds the maximum
value, the agent will return the maximum value.
For 15 minute intervals, the range is limited to (0..899). For 24
hour intervals, the range is limited to (0..86399).
7.11.4. HCPerfIntervalThreshold
This convention defines a range of values that may be set in a fault
threshold alarm control. As the number of seconds in a 15-minute
interval numbers at most 900, objects of this type may have a range
of 0...900, where the value of 0 disables the alarm.
7.11.5. HCPerfCurrentCount
A gauge associated with a performance measurement in a current 15
minute measurement interval. The value of an object with an
HCPerfCurrentCount syntax starts from zero and is increased when
associated events occur, until the end of the 15 minute interval. At
that time the value of the gauge is stored in the first 15 minute
history interval, and the gauge is restarted at zero. In the case
where the agent has no valid data available for the current interval,
the corresponding object instance is not available and upon a
retrieval request a corresponding error message shall be returned to
indicate that this instance does not exist.
This count represents a non-negative integer, which may increase or
decrease, but shall never exceed 2^64-1 (18446744073709551615
decimal), nor fall below 0. The value of an object with
HCPerfCurrentCount syntax assumes its maximum value whenever the
underlying count exceeds 2^64-1. If the underlying count
subsequently decreases below 2^64-1 (due, e.g., to a retroactive
adjustment as a result of entering or exiting unavailable time), then
the object's value also decreases.
7.11.6. HCPerfIntervalCount
A gauge associated with a performance measurement in a previous 15
minute measurement interval. In the case where the agent has no
valid data available for a particular interval, the corresponding
object instance is not available and upon a retrieval request a
corresponding error message shall be returned to indicate that this
instance does not exist.
Ellison & Natale Expires April 9, 2012 [Page 71]
Internet-Draft Expressing SNMP SMI TCs in XSD October 2011
Let X be an object with HCPerfIntervalCount syntax. Let Y be an
object with HCPerfCurrentCount syntax. Let Z be an object with
HCPerfTotalCount syntax. Then, in a system supporting a history of n
intervals with X(1) and X(n) the most and least recent intervals
respectively, the following applies at the end of a 15 minute
interval:
o discard the value of X(n)
o the value of X(i) becomes that of X(i-1) for n >= i > 1
o the value of X(1) becomes that of Y.
o the value of Z, if supported, is adjusted.
This count represents a non-negative integer, which may increase or
decrease, but shall never exceed 2^64-1 (18446744073709551615
decimal), nor fall below 0. The value of an object with
HCPerfIntervalCount syntax assumes its maximum value whenever the
underlying count exceeds 2^64-1. If the underlying count
subsequently decreases below 2^64-1 (due, e.g., to a retroactive
adjustment as a result of entering or exiting unavailable time), then
the value of the object also decreases.
7.11.7. HCPerfTotalCount
A gauge representing the aggregate of previous valid 15 minute
measurement intervals. Intervals for which no valid data was
available are not counted.
This count represents a non-negative integer, which may increase or
decrease, but shall never exceed 2^64-1 (18446744073709551615
decimal), nor fall below 0. The value of an object with
HCPerfTotalCount syntax assumes its maximum value whenever the
underlying count exceeds 2^64-1. If the underlying count
subsequently decreases below 2^64-1 (due, e.g., to a retroactive
adjustment as a result of entering or exiting unavailable time), then
the object's value also decreases.
7.12. Textual Conventions defined in ITU-ALARM-TC-MIB
7.12.1. ItuPerceivedSeverity
ITU perceived severity values.
Ellison & Natale Expires April 9, 2012 [Page 72]
Internet-Draft Expressing SNMP SMI TCs in XSD October 2011
7.12.2. ItuTrendIndication
ITU trend indication values for alarms.
7.13. Textual Conventions defined in ENTITY-STATE-TC-MIB
7.13.1. EntityAdminState
Represents the various possible administrative states.
A value of 'locked' means the resource is administratively prohibited
from use. A value of 'shuttingDown' means that usage is
administratively limited to current instances of use. A value of
'unlocked' means the resource is not administratively prohibited from
use. A value of 'unknown' means that this resource is unable to
report administrative state.
7.13.2. EntityOperState
Represents the possible values of operational states.
A value of 'disabled' means the resource is totally inoperable. A
value of 'enabled' means the resource is partially or fully operable.
A value of 'testing' means the resource is currently being tested and
cannot therefore report whether it is operational or not. A value of
'unknown' means that this resource is unable to report operational
state.
7.13.3. EntityUsageState
Represents the possible values of usage states.
A value of 'idle' means the resource is servicing no users. A value
of 'active' means the resource is currently in use and it has
sufficient spare capacity to provide for additional users. A value
of 'busy' means the resource is currently in use, but it currently
has no spare capacity to provide for additional users. A value of
'unknown' means that this resource is unable to report usage state.
7.13.4. EntityAlarmStatus
Represents the possible values of alarm status. An Alarm , as
defined in RFC3877, is a persistent indication of an error or warning
condition.
When no bits of this attribute are set, then no active alarms are
known against this entity and it is not under repair.
Ellison & Natale Expires April 9, 2012 [Page 73]
Internet-Draft Expressing SNMP SMI TCs in XSD October 2011
When the 'value of underRepair' is set, the resource is currently
being repaired, which, depending on the implementation, may make the
other values in this bit string not meaningful.
When the value of 'critical' is set, one or more critical alarms are
active against the resource. When the value of 'major' is set, one
or more major alarms are active against the resource. When the value
of 'minor' is set, one or more minor alarms are active against the
resource. When the value of 'warning' is set, one or more warning
alarms are active against the resource. When the value of
'indeterminate' is set, one or more alarms of whose perceived
severity cannot be determined are active against this resource.
A value of 'unknown' means that this resource is unable to report
alarm state.
7.13.5. EntityStandbyStatus
Represents the possible values of standby status.
A value of 'hotStandby' means the resource is not providing service,
but it will be immediately able to take over the role of the resource
to be backed up, without the need for initialization activity, and
will contain the same information as the resource to be backed up. A
value of 'coldStandy' means that the resource is to back up another
resource, but will not be immediately able to take over the role of a
resource to be backed up, and will require some initialization
activity. A value of 'providingService' means the resource is
providing service. A value of 'unknown' means that this resource is
unable to report standby state.
7.14. Textual Conventions defined in Q-BRIDGE-MIB
7.14.1. VlanId
The VLAN-ID that uniquely identifies a VLAN. This is the 12-bit
VLAN-ID used in the VLAN Tag header.
7.14.2. VlanIdOrAny
The VLAN-ID that uniquely identifies a specific VLAN, or any VLAN.
The value of 4095 is used to indicate a wildcard, i.e., any VLAN.
This can be used in any situation where an object or table entry must
refer either to a specific VLAN or to any VLAN.
Note that a managed object that is defined using this datatype should
clarify the meaning of 'any VLAN' (i.e., the special value 4095).
Ellison & Natale Expires April 9, 2012 [Page 74]
Internet-Draft Expressing SNMP SMI TCs in XSD October 2011
7.14.3. VlanIdOrNone
The VLAN-ID that uniquely identifies a specific VLAN, or no VLAN.
The value of zero is used to indicate that no VLAN-ID is present or
used. This can be used in any situation where an object or a table
entry must refer either to a specific VLAN, or to no VLAN.
Note that a managed object that is defined using this datatype should
clarify the meaning of 'no VLAN' (i.e., the special value 0).
Ellison & Natale Expires April 9, 2012 [Page 75]
Internet-Draft Expressing SNMP SMI TCs in XSD October 2011
8. 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.
Ellison & Natale Expires April 9, 2012 [Page 76]
Internet-Draft Expressing SNMP SMI TCs in XSD October 2011
9. IANA Considerations
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:smi:tc:[version_id]
o urn:ietf:params:xml:schema:smi:tc:[version_id]
9.1. SMI Textual Conventions Namespace Registration
This document registers a URI for the SMI Textual Conventions XML
namespace in the IETF XML registry. Following the format in RFC
3688, IANA has made the following registration:
URI: urn:ietf:params:xml:smi:tc:1.0
Registration Contact: The IESG.
XML: N/A, the requested URI is an XML namespace.
9.2. SMI Textual Conventions Schema Registration
This document registers a URI for the SMI Textual Conventions XML
schema in the IETF XML registry. Following the format in RFC 3688,
IANA has made the following registration:
URI: urn:ietf:params:xml:schema:smi:tc:1.0
Registration Contact: The IESG.
XML: Section 4 of this document.
Ellison & Natale Expires April 9, 2012 [Page 77]
Internet-Draft Expressing SNMP SMI TCs in XSD October 2011
10. 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, Dan
Romascanu, Subrata Mazumdar, Sandeep Adwankar and 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 textual conventions to XSD.
Ellison & Natale Expires April 9, 2012 [Page 78]
Internet-Draft Expressing SNMP SMI TCs in XSD October 2011
11. References
11.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.
[RFC2287] Krupczak, C. and J. Saperia, "Definitions of System-Level
Managed Objects for Applications", RFC 2287,
February 1998.
[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.
[RFC2856] Bierman, A., McCloghrie, K., and R. Presuhn, "Textual
Conventions for Additional High Capacity Data Types",
RFC 2856, June 2000.
[RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group
MIB", RFC 2863, June 2000.
[RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An
Architecture for Describing Simple Network Management
Protocol (SNMP) Management Frameworks", STD 62, RFC 3411,
December 2002.
[RFC3419] Daniele, M. and J. Schoenwaelder, "Textual Conventions for
Transport Addresses", RFC 3419, December 2002.
[RFC3440] Ly, F. and G. Bathrick, "Definitions of Extension Managed
Objects for Asymmetric Digital Subscriber Lines",
RFC 3440, December 2002.
[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.
[RFC3593] Tesink, K., "Textual Conventions for MIB Modules Using
Ellison & Natale Expires April 9, 2012 [Page 79]
Internet-Draft Expressing SNMP SMI TCs in XSD October 2011
Performance History Based on 15 Minute Intervals",
RFC 3593, September 2003.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, November 2003.
[RFC3705] Ray, B. and R. Abbi, "High Capacity Textual Conventions
for MIB Modules Using Performance History Based on 15
Minute Intervals", RFC 3705, February 2004.
[RFC3877] Chisholm, S. and D. Romascanu, "Alarm Management
Information Base (MIB)", RFC 3877, September 2004.
[RFC4001] Daniele, M., Haberman, B., Routhier, S., and J.
Schoenwaelder, "Textual Conventions for Internet Network
Addresses", RFC 4001, February 2005.
[RFC4008] Rohit, R., Srisuresh, P., Raghunarayan, R., Pai, N., and
C. Wang, "Definitions of Managed Objects for Network
Address Translators (NAT)", RFC 4008, March 2005.
[RFC4044] McCloghrie, K., "Fibre Channel Management MIB", RFC 4044,
May 2005.
[RFC4133] Bierman, A. and K. McCloghrie, "Entity MIB (Version 3)",
RFC 4133, August 2005.
[RFC4268] Chisholm, S. and D. Perkins, "Entity State MIB", RFC 4268,
November 2005.
[RFC4363] Levi, D. and D. Harrington, "Definitions of Managed
Objects for Bridges with Traffic Classes, Multicast
Filtering, and Virtual LAN Extensions", RFC 4363,
January 2006.
[RFC4502] Waldbusser, S., "Remote Network Monitoring Management
Information Base Version 2", RFC 4502, May 2006.
[RFC4706] Morgenstern, M., Dodge, M., Baillie, S., and U. Bonollo,
"Definitions of Managed Objects for Asymmetric Digital
Subscriber Line 2 (ADSL2)", RFC 4706, November 2006.
[RFC4780] Lingle, K., Mule, J-F., Maeng, J., and D. Walker,
"Management Information Base for the Session Initiation
Protocol (SIP)", RFC 4780, April 2007.
[RFC5935] Ellison, M. and B. Natale, "Expressing SNMP SMI Datatypes
in XML Schema Definition Language", RFC 5935, August 2010.
Ellison & Natale Expires April 9, 2012 [Page 80]
Internet-Draft Expressing SNMP SMI TCs in XSD October 2011
[XML] World Wide Web Consortium, "Extensible Markup Language
(XML) 1.0", W3C XML, February 1998,
.
[XMLSchema]
World Wide Web Consortium, "XML Schema Part 1: Structures
Second Edition", W3C XML Schema, October 2004,
.
[XSDDatatypes]
World Wide Web Consortium, "XML Schema Part 2: Datatypes
Second Edition", W3C XML Schema, October 2004,
.
11.2. Informative References
[ASN.1] International Organization for Standardization,
"Information processing systems - Open Systems
Interconnection - Specification of Basic Encoding Rules
for Abstract Syntax Notation One (ASN.1)", International
Standard 8825, December 1987.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
January 2004.
Ellison & Natale Expires April 9, 2012 [Page 81]
Internet-Draft Expressing SNMP SMI TCs in XSD October 2011
Appendix A. Open Issues
Ellison & Natale Expires April 9, 2012 [Page 82]
Internet-Draft Expressing SNMP SMI TCs in XSD October 2011
Appendix B. Change Log
-00 Initial version
Ellison & Natale Expires April 9, 2012 [Page 83]
Internet-Draft Expressing SNMP SMI TCs in XSD October 2011
Authors' Addresses
Mark Ellison
Ellison Software Consulting
38 Salem Road
Atkinson, NH 03811
USA
Phone: +1 603-362-9270
Email: ietf@ellisonsoftware.com
Bob Natale
MITRE
300 Sentinel Drive
6th Floor
Annapolis Junction, MD 20701
USA
Phone: +1 301-617-3008
Email: rnatale@mitre.org
Ellison & Natale Expires April 9, 2012 [Page 84]