Expressing SNMP SMI Textual Conventions in XML Schema Definition Language

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 . 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 , .

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 .

Developers of certain XML-based management applications will find the specification defined in RFC 5935 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 and MIB structure . 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") . 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.

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: 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 . 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 , or be defined within this memo. 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. 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. The XSD restriction facet(s) specified for a given SMI textual convention MUST represent any special encoding rules associated with that SMI textual convention. The XSD restriction facet(s) specified for a given SMI textual convention MUST include any restrictions on values associated with the SMI textual convention. 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.

[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: 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 MUST be "DisplayString". The opening tag MUST be <xs:simpleType name="XsdName"> where XsdName is the name of the SMI textual convention. 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. 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. The closing tag MUST be </xs:simpleType> Within the following sections, the namespace 'smi' is used to refer to the XML schema defined in RFC 5935.

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.

For the algorithmic mapping of textual conventions based upon the SMI Integer32 datatype, the following XSD facets are required: An XSD mapping of <xs:restriction base="smi:Integer32"> MUST be used. 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.

]]>

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: An xsd mapping of <xs:restriction base="smi:INTEGER"> MUST be used. 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.

]]>

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: An xsd mapping of <xs:restriction base="tc:"> MUST be used. The following XSD datatype specifies the NamedNumber simpleType:

]]> 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 TruthValue has the following SMIv2 Syntax clause:

]]> RowStatus has the following SMIv2 Syntax clause:

]]> StorageType has the following SMIv2 Syntax clause:

]]> defined in INET-ADDRESS-MIB InetAddressType has the following SMIv2 Syntax clause:

]]> InetScopeType has the following SMIv2 Syntax clause:

]]> InetVersion has the following SMIv2 Syntax clause:

]]>

For the algorithmic mapping of textual conventions based upon the SMI Unsigned32 datatype, the following XSD facets are required: An xsd mapping of <xs:restriction base="smi:Unsigned32"> MUST be used. 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.

]]>

For the algorithmic mapping of textual conventions based upon the SMI Gauge32 datatype, the following XSD facets are required: An xsd mapping of <xs:restriction base="smi:Gauge32"> MUST be used. 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.

]]>

For the algorithmic mapping of textual conventions based upon the SMI Gauge32 datatype, the following XSD facets are required: An xsd mapping of <xs:restriction base="smi:Counter32"> MUST be used. No value constraints are possible for textual conventions based upon the SMI Counter32 datatype.

For the algorithmic mapping of textual conventions based upon the SMI Gauge32 datatype, the following XSD facets are required: An xsd mapping of <xs:restriction base="smi:TimeTicks"> MUST be used. No value constraints are possible for textual conventions based upon the SMI TimeTicks datatype.

For the algorithmic mapping of textual conventions based upon the SMI Counter32 datatype, the following XSD facets are required: An xsd mapping of <xs:restriction base="smi:Counter64"> MUST be used. No value constraints are possible for textual conventions based upon the SMI Counter64 datatype.

For the algorithmic mapping of textual conventions based upon the SMI OCTET STRING datatype, the following XSD facets are required: An xsd mapping of <xs:restriction base="smi:OctetString"> MUST be used. 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: defined in SNMPv2-TC

]]> defined in SNMP-FRAMEWORK-MIB

]]> defined in SYSAPPL-MIB

]]>

]]> Examples of textual conventions conveying a binary OCTET STRING include: defined in SNMPv2-TC

]]>

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.

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 completeness and historic purposes. Thus, there is no need for a mapping for TCs based upon IpAddress.

For the algorithmic mapping of textual conventions based upon the SMI OBJECT IDENTIFIER base datatype, the following XSD facets are required: An xsd mapping of <xs:restriction base="smi:ObjectIdentifier"> MUST be used. 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: defined in SNMPv2-TC: AutonomousType VariablePointer RowPointer TDomain defined in ACCOUNTING-CONTROL-MIB: DataCollectionSubtree defined in ALARM-MIB: alarmModelLastChanged defined in APM-MIB: DataSourceOrZero defined in HOST-RESOURCES-MIB: ProductID defined in RMON2-MIB: DataSource 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:

]]>

For the algorithmic mapping of textual conventions based upon the SMI BITS construct, the following XSD facets are required: An xsd mapping of <xs:restriction base="tc:NamedBit"> MUST be used. The following XSD datatype specifies the NamedBit simpleType:

]]> 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. Examples of textual conventions based upon the BITS construct include: defined in ADSL2-LINE-TC-MIB Adsl2TransmissionModeType has the following SMIv2 Syntax clause:

]]> Adsl2LConfProfPmMode has the following SMIv2 Syntax clause:

]]> Adsl2LineStatus has the following SMIv2 Syntax clause:

]]> Adsl2ChAtmStatus has the following SMIv2 Syntax clause:

]]> Adsl2ChPtmStatus has the following SMIv2 Syntax clause:

]]> defined in ENTITY-STATE-TC-MIB EntityAlarmStatus has the following SMIv2 Syntax clause:

]]> defined in FC-MGMT-MIB FcClasses has the following SMIv2 Syntax clause:

]]> FcUnitFunctions has the following SMIv2 Syntax clause:

]]> defined in NAT-MIB NatProtocolMap has the following SMIv2 Syntax clause:

]]> NatTranslationEntity has the following SMIv2 Syntax clause:

]]> defined in SIP-TC-MIB SipTCTransportProtocol has the following SMIv2 Syntax clause:

]]> SipTCEntityRole has the following SMIv2 Syntax clause:

]]> SipTCOptionTagHeaders has the following SMIv2 Syntax clause:

]]>

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.

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 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. END ]]>

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: the use of character codes 0-127 (decimal) the graphics characters (32-126) are interpreted as US ASCII NUL, LF, CR, BEL, BS, HT, VT and FF have the special meanings specified in RFC 854 the other 25 codes have no standard interpretation the sequence 'CR LF' means newline the sequence 'CR NUL' means carriage-return an 'LF' not preceded by a 'CR' means moving to the same column on the next line. 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.

This XSD datatype corresponds to the SMI "TruthValue" Textual Convention. A TruthValue syntax represents a boolean value.

This XSD datatype corresponds to the SMI "TestAndIncr" Textual Convention. 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.

Represents a pointer to an element instance. The value is an absolute XPath expression that points to the instance.

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: active notInService notReady createAndGo createAndWait destroy

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.

A period of time, measured in units of 0.01 seconds.

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.

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.

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.

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.

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 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.

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.

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.

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.

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.

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."

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 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).

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.

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."

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.

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.

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.

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.

Represents a DNS domain name. The name SHOULD be fully qualified whenever possible. 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.

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.

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 <http://www.iana.org/>. 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.

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.

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.

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 address types associated with IP protocols. The InetAddressType has been designed for this purpose.

A value that represents a transport domain.

A value that represents a transport domain. The enumerated values have the following meaning: unknown unknown transport address type udpIpv4 transportDomainUdpIpv4 udpIpv6 transportDomainUdpIpv6 udpIpv4z transportDomainUdpIpv4z udpIpv6z transportDomainUdpIpv6z tcpIpv4 transportDomainTcpIpv4 tcpIpv6 transportDomainTcpIpv6 tcpIpv4z transportDomainTcpIpv4z tcpIpv6z transportDomainTcpIpv6z sctpIpv4 transportDomainSctpIpv4 sctpIpv6 transportDomainSctpIpv6 sctpIpv4z transportDomainSctpIpv4z sctpIpv6z transportDomainSctpIpv6z local transportDomainLocal udpDns transportDomainUdpDns tcpDns transportDomainTcpDns sctpDns transportDomainSctpDns 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.

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.

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.

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: discard the value of IntervalCount(n) the value of IntervalCount(i) becomes that of IntervalCount(i-1) for n >= i > 1 the value of IntervalCount(1) becomes that of CurrentCount the TotalCount, if supported, is adjusted.

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)

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.

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).

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).

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.

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.

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. 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: discard the value of X(n) the value of X(i) becomes that of X(i-1) for n >= i > 1 the value of X(1) becomes that of Y. 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.

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.

ITU perceived severity values.

ITU trend indication values for alarms.

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.

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.

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.

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. 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.

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.

The VLAN-ID that uniquely identifies a VLAN. This is the 12-bit VLAN-ID used in the VLAN Tag header.

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).

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).

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.

In accordance with RFC 3688 , we request the following namespace and schema registrations associated with this document in the IANA XML Registry: urn:ietf:params:xml:ns:smi:tc:[version_id] urn:ietf:params:xml:schema:smi:tc:[version_id]

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.

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.

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.