Expressing SNMP SMI Textual Conventions in XML Schema Definition Language
Ellison Software Consulting38 Salem RoadAtkinsonNH03811USA+1 603-362-9270ietf@ellisonsoftware.comMITRE300 Sentinel Drive6th FloorAnnapolis JunctionMD20701USA+1 301-617-3008rnatale@mitre.org
Operations and Management
RFCRequest for CommentsI-DInternet-DraftSMIDatatypeTextual ConventionTCXMLeXtensible Markup LanguageXML SchemaXSDThis 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.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-TCTruthValue has the following SMIv2 Syntax clause:
RowStatus has the following SMIv2 Syntax clause:
StorageType has the following SMIv2 Syntax clause:
defined in INET-ADDRESS-MIBInetAddressType 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-TCdefined in SNMP-FRAMEWORK-MIBdefined in SYSAPPL-MIBExamples of textual conventions conveying a binary OCTET STRING include:
defined in SNMPv2-TCThere 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:
AutonomousTypeVariablePointerRowPointerTDomaindefined in ACCOUNTING-CONTROL-MIB:
DataCollectionSubtreedefined in ALARM-MIB:
alarmModelLastChangeddefined in APM-MIB:
DataSourceOrZerodefined in HOST-RESOURCES-MIB:
ProductIDdefined in RMON2-MIB:
DataSourcedefined in SMON-MIB:
SmonDataSourceThe 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-MIBAdsl2TransmissionModeType 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-MIBEntityAlarmStatus has the following SMIv2 Syntax clause:
defined in FC-MGMT-MIBFcClasses has the following SMIv2 Syntax clause:
FcUnitFunctions has the following SMIv2 Syntax clause:
defined in NAT-MIBNatProtocolMap has the following SMIv2 Syntax clause:
NatTranslationEntity has the following SMIv2 Syntax clause:
defined in SIP-TC-MIBSipTCTransportProtocol 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.
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 ASCIINUL, LF, CR, BEL, BS, HT, VT and FF have the special
meanings specified in RFC 854the other 25 codes have no standard interpretationthe sequence 'CR LF' means newlinethe sequence 'CR NUL' means carriage-returnan '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:
activenotInServicenotReadycreateAndGocreateAndWaitdestroyThe 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.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^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.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 typeudpIpv4 transportDomainUdpIpv4udpIpv6 transportDomainUdpIpv6udpIpv4z transportDomainUdpIpv4zudpIpv6z transportDomainUdpIpv6ztcpIpv4 transportDomainTcpIpv4tcpIpv6 transportDomainTcpIpv6tcpIpv4z transportDomainTcpIpv4ztcpIpv6z transportDomainTcpIpv6zsctpIpv4 transportDomainSctpIpv4sctpIpv6 transportDomainSctpIpv6sctpIpv4z transportDomainSctpIpv4zsctpIpv6z transportDomainSctpIpv6zlocal transportDomainLocaludpDns transportDomainUdpDnstcpDns transportDomainTcpDnssctpDns transportDomainSctpDnsThis 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 > 1the value of IntervalCount(1) becomes that
of CurrentCountthe 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 > 1the 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.0Registration 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.0Registration 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.Structure and identification of management information for TCP/IP-based internetsPerformance Systems International, Inc.P.O. Box 391776Mountain ViewCA94039US+1 415 961 3380mrose@PSI.COMHughes LAN Systems, The Wollongong Group1129 San Antonio RoadPalo AltoCA94303US+1 415 962 7160sytek!kzm@HPLABS.HP.COMKey words for use in RFCs to Indicate Requirement LevelsHarvard University1350 Mass. Ave.CambridgeMA 02138- +1 617 495 3864sob@harvard.edu
General
keyword
In many standards track documents several words are used to
signify the requirements in the specification. These words are
often capitalized. This document defines these words as they
should be interpreted in IETF documents. Authors who follow these
guidelines should incorporate this phrase near the beginning of
their document:
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.
Note that the force of these words is modified by the
requirement level of the document in which they are used.
Definitions of System-Level Managed Objects for Applications
Empire Technologies, Inc.541 Tenth StreetNW Suite 169AtlantaGA 30318770.384.0184cheryl@empiretech.comBGS Systems Inc.saperia@networks.bgs.com
Management
Management Information Basemanaged object
This memo defines a portion of the Management Information Base (MIB)
for use with network management protocols in the Internet community.
In particular, it describes a basic set of managed objects for fault,
configuration and performance management of applications from a
systems perspective. More specifically, the managed objects are
restricted to information that can be determined from the system
itself and which does not require special instrumentation within the
applications to make the information available.
This memo does not specify a standard for the Internet community.
Structure of Management Information Version 2
(SMIv2)Cisco Systems, Inc.170 West Tasman DriveSan JoseCA95134-1706USA+1 408 526 5260kzm@cisco.comSNMPinfo3763 Benton StreetSanta ClaraCA95051USA+1 408 221 8702dperkins@snmpinfo.comTU BraunschweigBueltenweg 74/7538106 BraunschweigGermany+49 531 3913283schoenw@ibr.cs.tu-bs.deTextual Conventions for SMIv2Cisco Systems, Inc.170 West Tasman DriveSan JoseCA95134-1706US+1 408 526 5260kzm@cisco.comSNMPinfo3763 Benton StreetSanta ClaraCA95051US+1 408 221 8702dperkins@snmpinfo.comTU BraunschweigBueltenweg 74/7538106 BraunschweigDE+49 531 3913283schoenw@ibr.cs.tu-bs.deTextual Conventions for Additional High Capacity Data Types
This memo specifies new textual conventions for additional high capacity
data types, intended for SNMP implementations which already support the
Counter64 data type. [STANDARDS TRACK]
The Interfaces Group MIB
This memo discusses the 'interfaces' group of MIB-II, especially the
experience gained from the definition of numerous media-specific MIB
modules for use in conjunction with the 'interfaces' group for managing
various sub-layers beneath the internetwork-layer. It specifies
clarifications to, and extensions of, the architectural issues within
the MIB-II model of the 'interfaces' group. [STANDARDS TRACK]
An Architecture for Describing Simple Network Management Protocol (SNMP)
Management Frameworks
This document describes an architecture for describing Simple Network
Management Protocol (SNMP) Management Frameworks. The architecture is
designed to be modular to allow the evolution of the SNMP protocol standards
over time. The major portions of the architecture are an SNMP engine
containing a Message Processing Subsystem, a Security Subsystem and an
Access Control Subsystem, and possibly multiple SNMP applications which
provide specific functional processing of management data. This document
obsoletes RFC 2571. [STANDARDS TRACK]
Textual Conventions for Transport Addresses
This document introduces a Management Information Base (MIB) module that
defines textual conventions to represent commonly used transport-layer
addressing information. The definitions are compatible with the concept of
TAddress/TDomain pairs introduced by the Structure of Management Information
version 2 (SMIv2) and support the Internet transport protocols over IPv4 and
IPv6. [STANDARDS TRACK]
Definitions of Extension Managed Objects for Asymmetric Digital Subscriber Lines
This memo defines a portion of the Management Information Base (MIB)
for use with network management protocols in the Internet community.
In particular, it describes additional managed objects used for managing
Asymmetric Digital Subscriber Line (ADSL) interfaces not covered by the
ADSL Line MIB (RFC 2662). [STANDARDS-TRACK]
Coexistence between Version 1, Version 2, and Version 3 of the
Internet-standard Network Management Framework
Textual Conventions for MIB Modules Using Performance History Based
on 15 Minute Intervals
This document defines a set of Textual Conventions for MIB modules
that make use of performance history data based on 15 minute intervals.
This memo replaces RFC 2493. Changes relative to RFC 2493 are summarized
in the MIB module's REVISION clause. [STANDARDS TRACK]
UTF-8, a transformation format of ISO 10646
ISO/IEC 10646-1 defines a large character set called the Universal
Character Set (UCS) which encompasses most of the world's writing systems.
The originally proposed encodings of the UCS, however, were not
compatible with many current applications and protocols, and this has
led to the development of UTF-8, the object of this memo. UTF-8 has
the characteristic of preserving the full US-ASCII range, providing
compatibility with file systems, parsers and other software that rely
on US-ASCII values but are transparent to other values. This memo
obsoletes and replaces RFC 2279.
High Capacity Textual Conventions for MIB Modules Using Performance
History Based on 15 Minute Intervals
This document presents a set of High Capacity Textual Conventions
for use in MIB modules which require performance history based
upon 15 minute intervals. The Textual Conventions defined in
this document extend the conventions presented in RFC 3593 to 64 bit
resolution using the conventions presented in RFC 2856. [STANDARDS TRACK]
Alarm Management Information Base (MIB)
This memo defines a portion of the Management Information Base (MIB)
for use with network management protocols in the Internet community.
In particular, it describes management objects used for modelling and
storing alarms. [STANDARDS TRACK]
Textual Conventions for Internet Network Addresses
This MIB module defines textual conventions to represent commonly
used Internet network layer addressing information. The intent is
that these textual conventions will be imported and used in MIB modules
that would otherwise define their own representations. [STANDARDS TRACK]
Definitions of Managed Objects for Network Address Translators (NAT)
This memo defines a portion of the Management Information Base (MIB)
for devices implementing Network Address Translator (NAT) function.
This MIB module may be used for configuration as well as monitoring of a
device capable of NAT function. [STANDARDS-TRACK]Fibre Channel Management MIBThis memo defines a portion of the Management Information Base (MIB)
for use with network management protocols in the Internet community.
In particular, it describes managed objects for information related
to the Fibre Channel. [STANDARDS-TRACK]Entity MIB (Version 3)
This memo defines a portion of the Management Information Base (MIB)
for use with network management protocols in the Internet community.
In particular, it describes managed objects used for managing multiple
logical and physical entities managed by a single SNMP agent. This
document specifies version 3 of the Entity MIB, which obsoletes
version 2 (RFC 2737). [STANDARDS TRACK]
Entity State MIB
This memo defines a portion of the Management Information Base (MIB)
for use with network management protocols in the Internet community.
In particular, it describes extensions to the Entity MIB to provide
information about the state of physical entities.</t><t> In
addition, this memo defines a set of Textual Conventions to represent
various states of an entity. The intent is that these Textual Conventions
will be imported and used in MIB modules that would otherwise define
their own representations. [STANDARDS TRACK]
Definitions of Managed Objects for Bridges with Traffic Classes,
Multicast Filtering, and Virtual LAN Extensions
This memo defines a portion of the Management Information Base (MIB)
for use with network management protocols in TCP/IP-based internets.
In particular, it defines two MIB modules for managing the capabilities
of MAC bridges defined by the IEEE 802.1D-1998 (TM) MAC Bridges and the
IEEE 802.1Q-2003 (TM) Virtual LAN (VLAN) standards for bridging between
Local Area Network (LAN) segments. One MIB module defines objects for
managing the 'Traffic Classes' and 'Enhanced Multicast Filtering' components
of IEEE 802.1D-1998 and P802.1t-2001 (TM). The other MIB module defines
objects for managing VLANs, as specified in IEEE 802.1Q-2003, P802.1u (TM),
and P802.1v (TM).</t><t> Provisions are made for support of transparent
bridging. Provisions are also made so that these objects apply to bridges
connected by subnetworks other than LAN segments.</t><t> This memo
supplements RFC 4188 and obsoletes RFC 2674. [STANDARDS TRACK]
Remote Network Monitoring Management Information Base Version 2
This document defines a portion of the Management Information Base (MIB)
for use with network management protocols in TCP/IP-based internets.
In particular, it defines objects for managing remote network monitoring
devices.</t><t> This document obsoletes RFC 2021, updates RFC 3273,
and contains a new version of the RMON2-MIB module. [STANDARDS TRACK]
Extensible Markup Language (XML) 1.0World Wide Web ConsortiumMIT Laboratory for Computer Science545 Technology SquareCambridgeMA02139US+ 1 617 253 2613+ 1 617 258 5999timbl@w3.orghttp://www.w3c.orgDefinitions of Managed Objects for Asymmetric Digital Subscriber Line 2 (ADSL2)This document defines a Management Information Base (MIB) module for use
with network management protocols in the Internet community. In particular,
it describes objects used for managing parameters of the "Asymmetric Digital
Subscriber Line" family of interface types: ADSL, ADSL2, ADSL2+, and their
variants. [STANDARDS-TRACK]Management Information Base for the Session Initiation Protocol (SIP)This memo defines a portion of the Management Information Base (MIB)
for use with network management protocols in the Internet community.
In particular, it describes a set of managed objects that are used to
manage Session Initiation Protocol (SIP) entities, which include User
Agents, and Proxy, Redirect and Registrar servers. [STANDARDS-TRACK]Expressing SNMP SMI Datatypes in XML Schema Definition LanguageThis memo defines the IETF standard expression of Structure of
Management Information (SMI) base datatypes in 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. [STANDARDS TRACK]XML Schema Part 1: Structures Second EditionWorld Wide Web ConsortiumMIT Laboratory for Computer Science545 Technology SquareCambridgeMA02139US+ 1 617 253 2613+ 1 617 258 5999timbl@w3.orghttp://www.w3c.orgXML Schema Part 2: Datatypes Second EditionWorld Wide Web ConsortiumMIT Laboratory for Computer Science545 Technology SquareCambridgeMA02139US+ 1 617 253 2613+ 1 617 258 5999timbl@w3.orghttp://www.w3c.orgThe IETF XML RegistryThis document describes an IANA maintained registry for IETF standards
which use Extensible Markup Language (XML) related items such as Namespaces,
Document Type Declarations (DTDs), Schemas, and Resource Description Framework
(RDF) Schemas.Information processing systems - Open Systems Interconnection -
Specification of Basic Encoding Rules for Abstract Syntax Notation
One (ASN.1)
International Organization for Standardization-00 Initial version