There are three types of OIDs that may be present in the
pmCapabilitiesType object:
1) The OID of a MODULE-COMPLIANCE macro that represents the
highest level of compliance realized by the agent for that
MIB Module. For example, an agent that implements the OSPF
MIB Module at the highest level of compliance would have the
value of '1.3.6.1.2.1.14.15.2' in the pmCapabilitiesType
object. For software that realizes standard MIB
Modules that do not have compliance statements, the base OID
of the MIB Module should be used instead. If the OSPF MIB
Module had not been created with a compliance statement, then
the correct value of the pmCapabilitiesType would be
'1.3.6.1.2.1.14'. In the cases where multiple compliance
statements in a MIB Module are supported by the agent, and
where one compliance statement does not by definition include
the other, each of the compliance OIDs would have entries in
this table.
MIB Documents can contain more than one MIB Module. In the
case of OSPF, there is a second MIB Module
that describes notifications for the OSPF Version 2 Protocol.
If the agent also realizes these functions, an entry will
also exist for those capabilities in this table.
2) Vendors should install OIDs in this table that represent
vendor-specific capabilities. These capabilities can be
expressed just as those described above for MIB Modules on
the standards track. In addition, vendors may install any
OID they desire from their registered branch. The OIDs may be
at any level of granularity, from the root of their entire
branch to an instance of a single OID. There is no
restriction on the number of registrations they may make,
though care should be taken to avoid unnecessary entries.
3) OIDs that represent one capability or a collection of
capabilities that could be any collection of MIB Objects or
hardware or software functions may be created in working
groups and registered in a MIB Module. Other entities (e.g.,
vendors) may also make registrations. Software will register
these standard capability OIDs, as well as vendor specific
OIDs.
If the OID for a known capability is not present in the
table, then it should be assumed that the capability is not
implemented.
As this object is used in the index for the
pmCapabilitiesTable, users of this table should be careful
not to create entries that would result in instance names
with more than 128 sub-identifiers.
Parsed from file POLICY-BASED-MANAGEMENT-MIB.mib
Module: POLICY-BASED-MANAGEMENT-MIB
Vendor: IETF RFCs
Module: POLICY-BASED-MANAGEMENT-MIB (rfc4011-Policy-Based-Management.mib)
Type: TABULAR
Access: read-only
Syntax: OBJECT IDENTIFIER
Automatically extracted from www.mibdepot.com
pmCapabilitiesType OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-only STATUS current DESCRIPTION "There are three types of OIDs that may be present in the pmCapabilitiesType object: 1) The OID of a MODULE-COMPLIANCE macro that represents the highest level of compliance realized by the agent for that MIB Module. For example, an agent that implements the OSPF MIB Module at the highest level of compliance would have the value of '1.3.6.1.2.1.14.15.2' in the pmCapabilitiesType object. For software that realizes standard MIB Modules that do not have compliance statements, the base OID of the MIB Module should be used instead. If the OSPF MIB Module had not been created with a compliance statement, then the correct value of the pmCapabilitiesType would be '1.3.6.1.2.1.14'. In the cases where multiple compliance statements in a MIB Module are supported by the agent, and where one compliance statement does not by definition include the other, each of the compliance OIDs would have entries in this table. MIB Documents can contain more than one MIB Module. In the case of OSPF, there is a second MIB Module that describes notifications for the OSPF Version 2 Protocol. If the agent also realizes these functions, an entry will also exist for those capabilities in this table. 2) Vendors should install OIDs in this table that represent vendor-specific capabilities. These capabilities can be expressed just as those described above for MIB Modules on the standards track. In addition, vendors may install any OID they desire from their registered branch. The OIDs may be at any level of granularity, from the root of their entire branch to an instance of a single OID. There is no restriction on the number of registrations they may make, though care should be taken to avoid unnecessary entries. 3) OIDs that represent one capability or a collection of capabilities that could be any collection of MIB Objects or hardware or software functions may be created in working groups and registered in a MIB Module. Other entities (e.g., vendors) may also make registrations. Software will register these standard capability OIDs, as well as vendor specific OIDs. If the OID for a known capability is not present in the table, then it should be assumed that the capability is not implemented. As this object is used in the index for the pmCapabilitiesTable, users of this table should be careful not to create entries that would result in instance names with more than 128 sub-identifiers." ::= { pmCapabilitiesEntry 1 }