diff -Nur svn/observium/includes/definitions/os.inc.php observium.cimc/includes/definitions/os.inc.php --- svn/observium/includes/definitions/os.inc.php 2014-05-31 10:53:12.922024326 +0300 +++ observium.cimc/includes/definitions/os.inc.php 2014-05-31 23:57:48.230931416 +0300 @@ -557,6 +557,27 @@ $config['os'][$os]['icon'] = "cisco"; $config['os'][$os]['mibs'][] = "AIRESPACE-WIRELESS-MIB"; +// Cisco UCS CIMC + +$os = "cimc"; +$config['os'][$os]['text'] = "Cisco Integrated Management Controller"; +$config['os'][$os]['type'] = "server"; +$config['os'][$os]['over'][0]['graph'] = "device_temperature"; +$config['os'][$os]['over'][0]['text'] = "Temperature"; +$config['os'][$os]['over'][1]['graph'] = "device_power"; +$config['os'][$os]['over'][1]['text'] = "Power"; +$config['os'][$os]['icon'] = "cisco"; +$config['os'][$os]['sysObjectID'][] = ".1.3.6.1.4.1.9.1.1512"; +$config['os'][$os]['sysObjectID'][] = ".1.3.6.1.4.1.9.1.1513"; +$config['os'][$os]['sysObjectID'][] = ".1.3.6.1.4.1.9.1.1514"; +$config['os'][$os]['sysObjectID'][] = ".1.3.6.1.4.1.9.1.1515"; +$config['os'][$os]['sysObjectID'][] = ".1.3.6.1.4.1.9.1.1516"; +$config['os'][$os]['sysObjectID'][] = ".1.3.6.1.4.1.9.1.1682"; +$config['os'][$os]['sysObjectID'][] = ".1.3.6.1.4.1.9.1.1683"; +$config['os'][$os]['sysObjectID'][] = ".1.3.6.1.4.1.9.1.1684"; +$config['os'][$os]['sysObjectID'][] = ".1.3.6.1.4.1.9.1.1685"; +$config['os'][$os]['mibs'][] = "CISCO-UCS-CIMC-MIB"; + // Cisco IronPort $os = "asyncos"; diff -Nur svn/observium/includes/discovery/sensors/cisco-ucs-cimc-mib.inc.php observium.cimc/includes/discovery/sensors/cisco-ucs-cimc-mib.inc.php --- svn/observium/includes/discovery/sensors/cisco-ucs-cimc-mib.inc.php 1970-01-01 02:00:00.000000000 +0200 +++ observium.cimc/includes/discovery/sensors/cisco-ucs-cimc-mib.inc.php 2014-06-01 00:01:00.914935292 +0300 @@ -0,0 +1,71 @@ + $sensor) +{ + $value = snmp_get($device, $sensor['oid'], "-Oqv"); + + // Only add sensors which are present + if ($sensor['desc'] != "" && is_numeric($value)) + { + discover_sensor($valid['sensor'], $sensor['measurement'], $device, $sensor['oid'], $index, $sensor['type'], $sensor['desc'], 1, $value); + } +} + +// table: CPU Temperature info, walk through all installed CPUs +$oids = snmpwalk_cache_oid($device, "cucsProcessorEnvStatsTemperature", array(), "CISCO-UNIFIED-COMPUTING-PROCESSOR-MIB", mib_dirs('cisco')); + +if (is_array($oids)) +{ + foreach ($oids as $index => $entry) + { + $descr = "CPU ".$index." Temperature"; + $oid = ".1.3.6.1.4.1.9.9.719.1.41.2.1.10.".$index; + + // Only add sensors which are present + if (is_numeric($entry['cucsProcessorEnvStatsTemperature'])) + { + discover_sensor($valid['sensor'], 'temperature', $device, $oid, "cpu".$index, 'cimc', $descr, 1, $entry['cucsProcessorEnvStatsTemperature']); + } + } +} + +/* End of file cisco-ucs-cimc-mib.inc.php */ diff -Nur svn/observium/includes/polling/os/cimc.inc.php observium.cimc/includes/polling/os/cimc.inc.php --- svn/observium/includes/polling/os/cimc.inc.php 1970-01-01 02:00:00.000000000 +0200 +++ observium.cimc/includes/polling/os/cimc.inc.php 2014-05-31 23:59:58.287934033 +0300 @@ -0,0 +1,12 @@ +." + DESCRIPTION + "This MIB module defines textual conventions for + representing Internet addresses. An Internet + address can be an IPv4 address, an IPv6 address, + or a DNS domain name. This module also defines + textual conventions for Internet port numbers, + autonomous system numbers, and the length of an + Internet address prefix. + + Copyright (C) The Internet Society (2005). This version + of this MIB module is part of RFC 4001, see the RFC + itself for full legal notices." + REVISION "200502040000Z" + DESCRIPTION + "Third version, published as RFC 4001. This revision + introduces the InetZoneIndex, InetScopeType, and + InetVersion textual conventions." + REVISION "200205090000Z" + DESCRIPTION + "Second version, published as RFC 3291. This + revision contains several clarifications and + introduces several new textual conventions: + InetAddressPrefixLength, InetPortNumber, + InetAutonomousSystemNumber, InetAddressIPv4z, + and InetAddressIPv6z." + REVISION "200006080000Z" + + + DESCRIPTION + "Initial version, published as RFC 2851." + ::= { mib-2 76 } + +InetAddressType ::= TEXTUAL-CONVENTION + STATUS current + DESCRIPTION + "A value that represents a type of Internet address. + + unknown(0) 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(1) An IPv4 address as defined by the + InetAddressIPv4 textual convention. + + ipv6(2) An IPv6 address as defined by the + InetAddressIPv6 textual convention. + + ipv4z(3) A non-global IPv4 address including a zone + index as defined by the InetAddressIPv4z + textual convention. + + ipv6z(4) A non-global IPv6 address including a zone + index as defined by the InetAddressIPv6z + textual convention. + + dns(16) A DNS domain name as defined by the + InetAddressDNS textual convention. + + Each definition of a concrete InetAddressType value must be + accompanied by a definition of a textual convention for use + with that InetAddressType. + + To support future extensions, the InetAddressType textual + convention 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. An inconsistentValue error must be generated + if an attempt to change an InetAddressType object would, + for example, lead to an undefined InetAddress value. In + + + particular, InetAddressType/InetAddress pairs must be + changed together if the address type changes (e.g., from + ipv6(2) to ipv4(1))." + SYNTAX INTEGER { + unknown(0), + ipv4(1), + ipv6(2), + ipv4z(3), + ipv6z(4), + dns(16) + } + +InetAddress ::= TEXTUAL-CONVENTION + STATUS current + DESCRIPTION + "Denotes a generic Internet address. + + An InetAddress value is always interpreted within the context + of an InetAddressType value. Every usage of the InetAddress + textual convention 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 textual convention, 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 with an inconsistentValue error. + + When this textual convention is used as the syntax of an + index object, there may be issues with the limit of 128 + sub-identifiers specified in SMIv2, STD 58. In this case, + the object definition MUST include a 'SIZE' clause to + limit the number of potential instance sub-identifiers; + otherwise the applicable constraints MUST be stated in + the appropriate conceptual row DESCRIPTION clauses, or + in the surrounding documentation if there is no single + DESCRIPTION clause that is appropriate." + SYNTAX OCTET STRING (SIZE (0..255)) + +InetAddressIPv4 ::= TEXTUAL-CONVENTION + DISPLAY-HINT "1d.1d.1d.1d" + STATUS current + DESCRIPTION + "Represents an IPv4 network address: + + + Octets Contents Encoding + 1-4 IPv4 address network-byte order + + The corresponding InetAddressType value is ipv4(1). + + This textual convention 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." + SYNTAX OCTET STRING (SIZE (4)) + +InetAddressIPv6 ::= TEXTUAL-CONVENTION + DISPLAY-HINT "2x:2x:2x:2x:2x:2x:2x:2x" + STATUS current + DESCRIPTION + "Represents an IPv6 network address: + + Octets Contents Encoding + 1-16 IPv6 address network-byte order + + The corresponding InetAddressType value is ipv6(2). + + This textual convention 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." + SYNTAX OCTET STRING (SIZE (16)) + +InetAddressIPv4z ::= TEXTUAL-CONVENTION + DISPLAY-HINT "1d.1d.1d.1d%4d" + STATUS current + DESCRIPTION + "Represents a non-global IPv4 network address, together + with its zone index: + + Octets Contents Encoding + 1-4 IPv4 address network-byte order + 5-8 zone index network-byte order + + The corresponding InetAddressType value is ipv4z(3). + + The zone index (bytes 5-8) 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 textual convention 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." + SYNTAX OCTET STRING (SIZE (8)) + +InetAddressIPv6z ::= TEXTUAL-CONVENTION + DISPLAY-HINT "2x:2x:2x:2x:2x:2x:2x:2x%4d" + STATUS current + DESCRIPTION + "Represents a non-global IPv6 network address, together + with its zone index: + + Octets Contents Encoding + 1-16 IPv6 address network-byte order + 17-20 zone index network-byte order + + The corresponding InetAddressType value is ipv6z(4). + + The zone index (bytes 17-20) 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 textual convention 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." + SYNTAX OCTET STRING (SIZE (20)) + +InetAddressDNS ::= TEXTUAL-CONVENTION + DISPLAY-HINT "255a" + STATUS current + DESCRIPTION + "Represents a DNS domain name. The name SHOULD be fully + qualified whenever possible. + + The corresponding InetAddressType is dns(16). + + 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 textual convention 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." + SYNTAX OCTET STRING (SIZE (1..255)) + +InetAddressPrefixLength ::= TEXTUAL-CONVENTION + DISPLAY-HINT "d" + STATUS current + DESCRIPTION + "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 textual convention 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 textual convention, 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(1)' and 'ipv4z(3)' and 128 for the InetAddressType + 'ipv6(2)' and 'ipv6z(4)'. The maximum significant value + for the InetAddressType 'dns(16)' 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." + SYNTAX Unsigned32 (0..2040) + +InetPortNumber ::= TEXTUAL-CONVENTION + DISPLAY-HINT "d" + STATUS current + DESCRIPTION + "Represents a 16 bit port number of an Internet transport + + + layer protocol. Port numbers are assigned by IANA. A + current list of all assignments is available from + . + + The value zero is object-specific and must be defined as + part of the description of any object that uses this + syntax. Examples of the usage of zero might include + situations where a port number is unknown, or when the + value zero is used as a wildcard in a filter." + REFERENCE "STD 6 (RFC 768), STD 7 (RFC 793) and RFC 2960" + SYNTAX Unsigned32 (0..65535) + +InetAutonomousSystemNumber ::= TEXTUAL-CONVENTION + DISPLAY-HINT "d" + STATUS current + DESCRIPTION + "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 are currently limited to 16 bits + (0..65535). There is, however, work in progress to enlarge the + autonomous system number space to 32 bits. Therefore, this + textual convention uses an Unsigned32 value without a + range restriction in order to support a larger autonomous + system number space." + REFERENCE "RFC 1771, RFC 1930" + SYNTAX Unsigned32 + +InetScopeType ::= TEXTUAL-CONVENTION + STATUS current + DESCRIPTION + "Represents a scope type. This textual convention 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." + REFERENCE "RFC 3513" + SYNTAX INTEGER { + -- reserved(0), + + + interfaceLocal(1), + linkLocal(2), + subnetLocal(3), + adminLocal(4), + siteLocal(5), -- site-local unicast addresses + -- have been deprecated by RFC 3879 + -- unassigned(6), + -- unassigned(7), + organizationLocal(8), + -- unassigned(9), + -- unassigned(10), + -- unassigned(11), + -- unassigned(12), + -- unassigned(13), + global(14) + -- reserved(15) + } + +InetZoneIndex ::= TEXTUAL-CONVENTION + DISPLAY-HINT "d" + STATUS current + DESCRIPTION + "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." + REFERENCE "RFC4007" + SYNTAX Unsigned32 + +InetVersion ::= TEXTUAL-CONVENTION + STATUS current + DESCRIPTION + "A value representing a version of the IP protocol. + + unknown(0) An unknown or unspecified version of the IP + protocol. + + + ipv4(1) The IPv4 protocol as defined in RFC 791 (STD 5). + + ipv6(2) The IPv6 protocol as defined in RFC 2460. + + Note that this textual convention SHOULD NOT be used to + distinguish different address types associated with IP + protocols. The InetAddressType has been designed for this + purpose." + REFERENCE "RFC 791, RFC 2460" + SYNTAX INTEGER { + unknown(0), + ipv4(1), + ipv6(2) + } +END diff -Nur svn/observium/mibs/cisco/ITU-ALARM-TC-MIB.my observium.cimc/mibs/cisco/ITU-ALARM-TC-MIB.my --- svn/observium/mibs/cisco/ITU-ALARM-TC-MIB.my 1970-01-01 02:00:00.000000000 +0200 +++ observium.cimc/mibs/cisco/ITU-ALARM-TC-MIB.my 2013-08-21 14:11:56.000000000 +0300 @@ -0,0 +1,90 @@ +ITU-ALARM-TC-MIB DEFINITIONS ::= BEGIN + +IMPORTS + MODULE-IDENTITY, mib-2 + FROM SNMPv2-SMI -- [RFC2578] + TEXTUAL-CONVENTION + FROM SNMPv2-TC; -- [RFC2579] + + ituAlarmTc MODULE-IDENTITY + LAST-UPDATED "200409090000Z" -- September 09, 2004 + ORGANIZATION "IETF Distributed Management Working Group" + CONTACT-INFO + " WG EMail: disman@ietf.org + Subscribe: disman-request@ietf.org + http://www.ietf.org/html.charters/disman-charter.html + + Chair: Randy Presuhn + randy_presuhn@mindspring.com + + Editors: Sharon Chisholm + Nortel Networks + PO Box 3511 Station C + Ottawa, Ont. K1Y 4H7 + Canada + schishol@nortelnetworks.com + + Dan Romascanu + Avaya + Atidim Technology Park, Bldg. #3 + Tel Aviv, 61131 + Israel + Tel: +972-3-645-8414 + Email: dromasca@avaya.com" + DESCRIPTION + "This MIB module defines the ITU Alarm + textual convention for objects not expected to require + regular extension. + + Copyright (C) The Internet Society (2004). The + initial version of this MIB module was published + in RFC 3877. For full legal notices see the RFC + itself. Supplementary information may be available on: + http://www.ietf.org/copyrights/ianamib.html" + REVISION "200409090000Z" -- September 09, 2004 + DESCRIPTION + "Initial version, published as RFC 3877." + + + + ::= { mib-2 120 } + +ItuPerceivedSeverity ::= TEXTUAL-CONVENTION + STATUS current + DESCRIPTION + "ITU perceived severity values" + REFERENCE + "ITU Recommendation M.3100, 'Generic Network Information + Model', 1995 + ITU Recommendation X.733, 'Information Technology - Open + Systems Interconnection - System Management: Alarm + Reporting Function', 1992" + SYNTAX INTEGER + { + cleared (1), + indeterminate (2), + critical (3), + major (4), + minor (5), + warning (6) + } + +ItuTrendIndication ::= TEXTUAL-CONVENTION + STATUS current + DESCRIPTION + "ITU trend indication values for alarms." + REFERENCE + "ITU Recommendation M.3100, 'Generic Network Information + Model', 1995 + ITU Recommendation X.733, 'Information Technology - Open + Systems Interconnection - System Management: Alarm + Reporting Function', 1992" + SYNTAX INTEGER + { + moreSevere (1), + noChange (2), + lessSevere (3) + } + +END + diff -Nur svn/observium/mibs/cisco/SNMP-FRAMEWORK-MIB.my observium.cimc/mibs/cisco/SNMP-FRAMEWORK-MIB.my --- svn/observium/mibs/cisco/SNMP-FRAMEWORK-MIB.my 1970-01-01 02:00:00.000000000 +0200 +++ observium.cimc/mibs/cisco/SNMP-FRAMEWORK-MIB.my 2013-08-21 14:13:37.000000000 +0300 @@ -0,0 +1,538 @@ +SNMP-FRAMEWORK-MIB DEFINITIONS ::= BEGIN + +IMPORTS + MODULE-IDENTITY, OBJECT-TYPE, + OBJECT-IDENTITY, + snmpModules FROM SNMPv2-SMI + TEXTUAL-CONVENTION FROM SNMPv2-TC + MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF; + +snmpFrameworkMIB MODULE-IDENTITY + LAST-UPDATED "200210140000Z" + ORGANIZATION "SNMPv3 Working Group" + CONTACT-INFO "WG-EMail: snmpv3@lists.tislabs.com + Subscribe: snmpv3-request@lists.tislabs.com + + Co-Chair: Russ Mundy + Network Associates Laboratories + postal: 15204 Omega Drive, Suite 300 + Rockville, MD 20850-4601 + USA + EMail: mundy@tislabs.com + phone: +1 301-947-7107 + + Co-Chair & + Co-editor: David Harrington + Enterasys Networks + postal: 35 Industrial Way + P. O. Box 5005 + Rochester, New Hampshire 03866-5005 + USA + EMail: dbh@enterasys.com + phone: +1 603-337-2614 + + Co-editor: Randy Presuhn + BMC Software, Inc. + postal: 2141 North First Street + San Jose, California 95131 + USA + EMail: randy_presuhn@bmc.com + phone: +1 408-546-1006 + + Co-editor: Bert Wijnen + Lucent Technologies + postal: Schagen 33 + 3461 GL Linschoten + Netherlands + + + EMail: bwijnen@lucent.com + phone: +31 348-680-485 + " + DESCRIPTION "The SNMP Management Architecture MIB + + Copyright (C) The Internet Society (2002). This + version of this MIB module is part of RFC 3411; + see the RFC itself for full legal notices. + " + + REVISION "200210140000Z" -- 14 October 2002 + DESCRIPTION "Changes in this revision: + - Updated various administrative information. + - Corrected some typos. + - Corrected typo in description of SnmpEngineID + that led to range overlap for 127. + - Changed '255a' to '255t' in definition of + SnmpAdminString to align with current SMI. + - Reworded 'reserved' for value zero in + DESCRIPTION of SnmpSecurityModel. + - The algorithm for allocating security models + should give 256 per enterprise block, rather + than 255. + - The example engine ID of 'abcd' is not + legal. Replaced with '800002b804616263'H based + on example enterprise 696, string 'abc'. + - Added clarification that engineID should + persist across re-initializations. + This revision published as RFC 3411. + " + REVISION "199901190000Z" -- 19 January 1999 + DESCRIPTION "Updated editors' addresses, fixed typos. + Published as RFC 2571. + " + REVISION "199711200000Z" -- 20 November 1997 + DESCRIPTION "The initial version, published in RFC 2271. + " + ::= { snmpModules 10 } + + -- Textual Conventions used in the SNMP Management Architecture *** + +SnmpEngineID ::= TEXTUAL-CONVENTION + STATUS current + DESCRIPTION "An SNMP engine's administratively-unique identifier. + Objects of this type are for identification, not for + addressing, even though it is possible that an + address may have been used in the generation of + a specific value. + + + The value for this object may not be all zeros or + all 'ff'H or the empty (zero length) string. + + The initial value for this object may be configured + via an operator console entry or via an algorithmic + function. In the latter case, the following + example algorithm is recommended. + + In cases where there are multiple engines on the + same system, the use of this algorithm is NOT + appropriate, as it would result in all of those + engines ending up with the same ID value. + + 1) The very first bit is used to indicate how the + rest of the data is composed. + + 0 - as defined by enterprise using former methods + that existed before SNMPv3. See item 2 below. + + 1 - as defined by this architecture, see item 3 + below. + + Note that this allows existing uses of the + engineID (also known as AgentID [RFC1910]) to + co-exist with any new uses. + + 2) The snmpEngineID has a length of 12 octets. + + The first four octets are set to the binary + equivalent of the agent's SNMP management + private enterprise number as assigned by the + Internet Assigned Numbers Authority (IANA). + For example, if Acme Networks has been assigned + { enterprises 696 }, the first four octets would + be assigned '000002b8'H. + + The remaining eight octets are determined via + one or more enterprise-specific methods. Such + methods must be designed so as to maximize the + possibility that the value of this object will + be unique in the agent's administrative domain. + For example, it may be the IP address of the SNMP + entity, or the MAC address of one of the + interfaces, with each address suitably padded + with random octets. If multiple methods are + defined, then it is recommended that the first + octet indicate the method being used and the + remaining octets be a function of the method. + + + 3) The length of the octet string varies. + + The first four octets are set to the binary + equivalent of the agent's SNMP management + private enterprise number as assigned by the + Internet Assigned Numbers Authority (IANA). + For example, if Acme Networks has been assigned + { enterprises 696 }, the first four octets would + be assigned '000002b8'H. + + The very first bit is set to 1. For example, the + above value for Acme Networks now changes to be + '800002b8'H. + + The fifth octet indicates how the rest (6th and + following octets) are formatted. The values for + the fifth octet are: + + 0 - reserved, unused. + + 1 - IPv4 address (4 octets) + lowest non-special IP address + + 2 - IPv6 address (16 octets) + lowest non-special IP address + + 3 - MAC address (6 octets) + lowest IEEE MAC address, canonical + order + + 4 - Text, administratively assigned + Maximum remaining length 27 + + 5 - Octets, administratively assigned + Maximum remaining length 27 + + 6-127 - reserved, unused + + 128-255 - as defined by the enterprise + Maximum remaining length 27 + " + SYNTAX OCTET STRING (SIZE(5..32)) + + +SnmpSecurityModel ::= TEXTUAL-CONVENTION + STATUS current + DESCRIPTION "An identifier that uniquely identifies a + Security Model of the Security Subsystem within + this SNMP Management Architecture. + + The values for securityModel are allocated as + follows: + + - The zero value does not identify any particular + security model. + + - Values between 1 and 255, inclusive, are reserved + for standards-track Security Models and are + managed by the Internet Assigned Numbers Authority + (IANA). + - Values greater than 255 are allocated to + enterprise-specific Security Models. An + enterprise-specific securityModel value is defined + to be: + + enterpriseID * 256 + security model within + enterprise + + For example, the fourth Security Model defined by + the enterprise whose enterpriseID is 1 would be + 259. + + This scheme for allocation of securityModel + values allows for a maximum of 255 standards- + based Security Models, and for a maximum of + 256 Security Models per enterprise. + + It is believed that the assignment of new + securityModel values will be rare in practice + because the larger the number of simultaneously + utilized Security Models, the larger the + chance that interoperability will suffer. + Consequently, it is believed that such a range + will be sufficient. In the unlikely event that + the standards committee finds this number to be + insufficient over time, an enterprise number + can be allocated to obtain an additional 256 + possible values. + + Note that the most significant bit must be zero; + hence, there are 23 bits allocated for various + organizations to design and define non-standard + + + securityModels. This limits the ability to + define new proprietary implementations of Security + Models to the first 8,388,608 enterprises. + + It is worthwhile to note that, in its encoded + form, the securityModel value will normally + require only a single byte since, in practice, + the leftmost bits will be zero for most messages + and sign extension is suppressed by the encoding + rules. + + As of this writing, there are several values + of securityModel defined for use with SNMP or + reserved for use with supporting MIB objects. + They are as follows: + + 0 reserved for 'any' + 1 reserved for SNMPv1 + 2 reserved for SNMPv2c + 3 User-Based Security Model (USM) + " + SYNTAX INTEGER(0 .. 2147483647) + +SnmpMessageProcessingModel ::= TEXTUAL-CONVENTION + STATUS current + DESCRIPTION "An identifier that uniquely identifies a Message + Processing Model of the Message Processing + Subsystem within this SNMP Management Architecture. + + The values for messageProcessingModel are + allocated as follows: + + - Values between 0 and 255, inclusive, are + reserved for standards-track Message Processing + Models and are managed by the Internet Assigned + Numbers Authority (IANA). + + - Values greater than 255 are allocated to + enterprise-specific Message Processing Models. + An enterprise messageProcessingModel value is + defined to be: + + enterpriseID * 256 + + messageProcessingModel within enterprise + + For example, the fourth Message Processing Model + defined by the enterprise whose enterpriseID + + + is 1 would be 259. + + This scheme for allocating messageProcessingModel + values allows for a maximum of 255 standards- + based Message Processing Models, and for a + maximum of 256 Message Processing Models per + enterprise. + + It is believed that the assignment of new + messageProcessingModel values will be rare + in practice because the larger the number of + simultaneously utilized Message Processing Models, + the larger the chance that interoperability + will suffer. It is believed that such a range + will be sufficient. In the unlikely event that + the standards committee finds this number to be + insufficient over time, an enterprise number + can be allocated to obtain an additional 256 + possible values. + + Note that the most significant bit must be zero; + hence, there are 23 bits allocated for various + organizations to design and define non-standard + messageProcessingModels. This limits the ability + to define new proprietary implementations of + Message Processing Models to the first 8,388,608 + enterprises. + + It is worthwhile to note that, in its encoded + form, the messageProcessingModel value will + normally require only a single byte since, in + practice, the leftmost bits will be zero for + most messages and sign extension is suppressed + by the encoding rules. + + As of this writing, there are several values of + messageProcessingModel defined for use with SNMP. + They are as follows: + + 0 reserved for SNMPv1 + 1 reserved for SNMPv2c + 2 reserved for SNMPv2u and SNMPv2* + 3 reserved for SNMPv3 + " + SYNTAX INTEGER(0 .. 2147483647) + + +SnmpSecurityLevel ::= TEXTUAL-CONVENTION + STATUS current + DESCRIPTION "A Level of Security at which SNMP messages can be + sent or with which operations are being processed; + in particular, one of: + + noAuthNoPriv - without authentication and + without privacy, + authNoPriv - with authentication but + without privacy, + authPriv - with authentication and + with privacy. + + These three values are ordered such that + noAuthNoPriv is less than authNoPriv and + authNoPriv is less than authPriv. + " + SYNTAX INTEGER { noAuthNoPriv(1), + authNoPriv(2), + authPriv(3) + } + +SnmpAdminString ::= TEXTUAL-CONVENTION + DISPLAY-HINT "255t" + STATUS current + DESCRIPTION "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 [RFC2279]. + + 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 when this TC is used for an object that + is used or envisioned to be used as an index, then + a SIZE restriction MUST be specified so that the + number of sub-identifiers for any object instance + does not exceed the limit of 128, as defined by + [RFC3416]. + + Note that the size of an SnmpAdminString object is + measured in octets, not characters. + " + SYNTAX OCTET STRING (SIZE (0..255)) + +-- Administrative assignments *************************************** + +snmpFrameworkAdmin + OBJECT IDENTIFIER ::= { snmpFrameworkMIB 1 } +snmpFrameworkMIBObjects + OBJECT IDENTIFIER ::= { snmpFrameworkMIB 2 } +snmpFrameworkMIBConformance + OBJECT IDENTIFIER ::= { snmpFrameworkMIB 3 } + +-- the snmpEngine Group ******************************************** + +snmpEngine OBJECT IDENTIFIER ::= { snmpFrameworkMIBObjects 1 } + + +snmpEngineID OBJECT-TYPE + SYNTAX SnmpEngineID + MAX-ACCESS read-only + STATUS current + DESCRIPTION "An SNMP engine's administratively-unique identifier. + + This information SHOULD be stored in non-volatile + storage so that it remains constant across + re-initializations of the SNMP engine. + " + ::= { snmpEngine 1 } + +snmpEngineBoots OBJECT-TYPE + SYNTAX INTEGER (1..2147483647) + MAX-ACCESS read-only + STATUS current + DESCRIPTION "The number of times that the SNMP engine has + (re-)initialized itself since snmpEngineID + was last configured. + " + ::= { snmpEngine 2 } + +snmpEngineTime OBJECT-TYPE + SYNTAX INTEGER (0..2147483647) + UNITS "seconds" + MAX-ACCESS read-only + STATUS current + DESCRIPTION "The number of seconds since the value of + the snmpEngineBoots object last changed. + When incrementing this object's value would + cause it to exceed its maximum, + snmpEngineBoots is incremented as if a + re-initialization had occurred, and this + object's value consequently reverts to zero. + " + ::= { snmpEngine 3 } + +snmpEngineMaxMessageSize OBJECT-TYPE + SYNTAX INTEGER (484..2147483647) + MAX-ACCESS read-only + STATUS current + DESCRIPTION "The maximum length in octets of an SNMP message + which this SNMP engine can send or receive and + process, determined as the minimum of the maximum + message size values supported among all of the + transports available to and supported by the engine. + " + ::= { snmpEngine 4 } + + +-- Registration Points for Authentication and Privacy Protocols ** + +snmpAuthProtocols OBJECT-IDENTITY + STATUS current + DESCRIPTION "Registration point for standards-track + authentication protocols used in SNMP Management + Frameworks. + " + ::= { snmpFrameworkAdmin 1 } + +snmpPrivProtocols OBJECT-IDENTITY + STATUS current + DESCRIPTION "Registration point for standards-track privacy + protocols used in SNMP Management Frameworks. + " + ::= { snmpFrameworkAdmin 2 } + +-- Conformance information ****************************************** + +snmpFrameworkMIBCompliances + OBJECT IDENTIFIER ::= {snmpFrameworkMIBConformance 1} +snmpFrameworkMIBGroups + OBJECT IDENTIFIER ::= {snmpFrameworkMIBConformance 2} + +-- compliance statements + +snmpFrameworkMIBCompliance MODULE-COMPLIANCE + STATUS current + DESCRIPTION "The compliance statement for SNMP engines which + implement the SNMP Management Framework MIB. + " + MODULE -- this module + MANDATORY-GROUPS { snmpEngineGroup } + + ::= { snmpFrameworkMIBCompliances 1 } + +-- units of conformance + +snmpEngineGroup OBJECT-GROUP + OBJECTS { + snmpEngineID, + snmpEngineBoots, + snmpEngineTime, + snmpEngineMaxMessageSize + } + STATUS current + DESCRIPTION "A collection of objects for identifying and + determining the configuration and current timeliness + + + values of an SNMP engine. + " + ::= { snmpFrameworkMIBGroups 1 } + +END diff -Nur svn/observium/mibs/cisco/SNMPv2-CONF.my observium.cimc/mibs/cisco/SNMPv2-CONF.my --- svn/observium/mibs/cisco/SNMPv2-CONF.my 1970-01-01 02:00:00.000000000 +0200 +++ observium.cimc/mibs/cisco/SNMPv2-CONF.my 2013-08-21 14:12:29.000000000 +0300 @@ -0,0 +1,19 @@ +-- ***************************************************************** +-- SNMPv2-CONF.my: SNMPv2 Conformance MIB file +-- +-- May 1994, Jeffrey T. Johnson +-- +-- Copyright (c) 1994,1996 by cisco Systems, Inc. +-- All rights reserved. +-- +-- ***************************************************************** +-- +-- This mib was extracted from RFC 1904 +-- All macro definitions have been removed because they are +-- predefined in the mib compiler + +SNMPv2-CONF DEFINITIONS ::= BEGIN + +-- everything is predefined in the mib compiler + +END diff -Nur svn/observium/mibs/cisco/SNMPv2-MIB.my observium.cimc/mibs/cisco/SNMPv2-MIB.my --- svn/observium/mibs/cisco/SNMPv2-MIB.my 1970-01-01 02:00:00.000000000 +0200 +++ observium.cimc/mibs/cisco/SNMPv2-MIB.my 2013-08-21 14:12:27.000000000 +0300 @@ -0,0 +1,864 @@ +-- ***************************************************************** +-- SNMPv2-MIB.my: Management Information Base (MIB) for the +-- Simple Network Management Protocol (SNMP) +-- +-- March 2006, Wen Xu +-- +-- Copyright (c) 2006 by cisco Systems, Inc. +-- All rights reserved. +-- ***************************************************************** +-- +-- This mib was extracted from RFC 3418 + + +SNMPv2-MIB DEFINITIONS ::= BEGIN + + IMPORTS + MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE, + TimeTicks, Counter32, snmpModules, mib-2 + FROM SNMPv2-SMI + DisplayString, TestAndIncr, TimeStamp + FROM SNMPv2-TC + MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP + FROM SNMPv2-CONF; + + snmpMIB MODULE-IDENTITY + LAST-UPDATED "200210160000Z" + ORGANIZATION "IETF SNMPv3 Working Group" + CONTACT-INFO + "WG-EMail: snmpv3@lists.tislabs.com + Subscribe: snmpv3-request@lists.tislabs.com + + Co-Chair: Russ Mundy + Network Associates Laboratories + postal: 15204 Omega Drive, Suite 300 + Rockville, MD 20850-4601 + USA + EMail: mundy@tislabs.com + phone: +1 301 947-7107 + + Co-Chair: David Harrington + Enterasys Networks + postal: 35 Industrial Way + P. O. Box 5005 + Rochester, NH 03866-5005 + USA + EMail: dbh@enterasys.com + phone: +1 603 337-2614 + + Editor: Randy Presuhn + BMC Software, Inc. + postal: 2141 North First Street + San Jose, CA 95131 + USA + EMail: randy_presuhn@bmc.com + phone: +1 408 546-1006" + DESCRIPTION + "The MIB module for SNMP entities. + + Copyright (C) The Internet Society (2002). This + version of this MIB module is part of RFC 3418; + see the RFC itself for full legal notices. + " + REVISION "200210160000Z" + DESCRIPTION + "This revision of this MIB module was published as + RFC 3418." + REVISION "199511090000Z" + DESCRIPTION + "This revision of this MIB module was published as + RFC 1907." + REVISION "199304010000Z" + DESCRIPTION + "The initial revision of this MIB module was published + as RFC 1450." + ::= { snmpModules 1 } + + snmpMIBObjects OBJECT IDENTIFIER ::= { snmpMIB 1 } + + -- ::= { snmpMIBObjects 1 } this OID is obsolete + -- ::= { snmpMIBObjects 2 } this OID is obsolete + -- ::= { snmpMIBObjects 3 } this OID is obsolete + + -- the System group + -- + -- a collection of objects common to all managed systems. + + system OBJECT IDENTIFIER ::= { mib-2 1 } + + sysDescr OBJECT-TYPE + SYNTAX DisplayString (SIZE (0..255)) + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A textual description of the entity. This value should + include the full name and version identification of + the system's hardware type, software operating-system, + and networking software." + ::= { system 1 } + + sysObjectID OBJECT-TYPE + SYNTAX OBJECT IDENTIFIER + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The vendor's authoritative identification of the + network management subsystem contained in the entity. + This value is allocated within the SMI enterprises + subtree (1.3.6.1.4.1) and provides an easy and + unambiguous means for determining `what kind of box' is + being managed. For example, if vendor `Flintstones, + Inc.' was assigned the subtree 1.3.6.1.4.1.424242, + it could assign the identifier 1.3.6.1.4.1.424242.1.1 + to its `Fred Router'." + ::= { system 2 } + + sysUpTime OBJECT-TYPE + SYNTAX TimeTicks + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The time (in hundredths of a second) since the + network management portion of the system was last + re-initialized." + ::= { system 3 } + + sysContact OBJECT-TYPE + SYNTAX DisplayString (SIZE (0..255)) + MAX-ACCESS read-write + STATUS current + DESCRIPTION + "The textual identification of the contact person for + this managed node, together with information on how + to contact this person. If no contact information is + known, the value is the zero-length string." + ::= { system 4 } + + sysName OBJECT-TYPE + SYNTAX DisplayString (SIZE (0..255)) + MAX-ACCESS read-write + STATUS current + DESCRIPTION + "An administratively-assigned name for this managed + node. By convention, this is the node's fully-qualified + domain name. If the name is unknown, the value is + the zero-length string." + ::= { system 5 } + + sysLocation OBJECT-TYPE + SYNTAX DisplayString (SIZE (0..255)) + MAX-ACCESS read-write + STATUS current + DESCRIPTION + "The physical location of this node (e.g., 'telephone + closet, 3rd floor'). If the location is unknown, the + value is the zero-length string." + ::= { system 6 } + + sysServices OBJECT-TYPE + SYNTAX INTEGER (0..127) + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A value which indicates the set of services that this + entity may potentially offer. The value is a sum. + This sum initially takes the value zero. Then, for + each layer, L, in the range 1 through 7, that this node + performs transactions for, 2 raised to (L - 1) is added + to the sum. For example, a node which performs only + routing functions would have a value of 4 (2^(3-1)). + In contrast, a node which is a host offering application + services would have a value of 72 (2^(4-1) + 2^(7-1)). + Note that in the context of the Internet suite of + protocols, values should be calculated accordingly: + + layer functionality + 1 physical (e.g., repeaters) + 2 datalink/subnetwork (e.g., bridges) + 3 internet (e.g., supports the IP) + 4 end-to-end (e.g., supports the TCP) + 7 applications (e.g., supports the SMTP) + + For systems including OSI protocols, layers 5 and 6 + may also be counted." + ::= { system 7 } + + -- object resource information + -- + -- a collection of objects which describe the SNMP entity's + -- (statically and dynamically configurable) support of + -- various MIB modules. + + sysORLastChange OBJECT-TYPE + SYNTAX TimeStamp + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The value of sysUpTime at the time of the most recent + change in state or value of any instance of sysORID." + ::= { system 8 } + + sysORTable OBJECT-TYPE + SYNTAX SEQUENCE OF SysOREntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "The (conceptual) table listing the capabilities of + the local SNMP application acting as a command + responder with respect to various MIB modules. + SNMP entities having dynamically-configurable support + of MIB modules will have a dynamically-varying number + of conceptual rows." + ::= { system 9 } + + sysOREntry OBJECT-TYPE + SYNTAX SysOREntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "An entry (conceptual row) in the sysORTable." + INDEX { sysORIndex } + ::= { sysORTable 1 } + + SysOREntry ::= SEQUENCE { + sysORIndex INTEGER, + sysORID OBJECT IDENTIFIER, + sysORDescr DisplayString, + sysORUpTime TimeStamp + } + + sysORIndex OBJECT-TYPE + SYNTAX INTEGER (1..2147483647) + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "The auxiliary variable used for identifying instances + of the columnar objects in the sysORTable." + ::= { sysOREntry 1 } + + sysORID OBJECT-TYPE + SYNTAX OBJECT IDENTIFIER + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "An authoritative identification of a capabilities + statement with respect to various MIB modules supported + by the local SNMP application acting as a command + responder." + ::= { sysOREntry 2 } + + sysORDescr OBJECT-TYPE + SYNTAX DisplayString + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A textual description of the capabilities identified + by the corresponding instance of sysORID." + ::= { sysOREntry 3 } + + sysORUpTime OBJECT-TYPE + SYNTAX TimeStamp + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The value of sysUpTime at the time this conceptual + row was last instantiated." + ::= { sysOREntry 4 } + + -- the SNMP group + -- + -- a collection of objects providing basic instrumentation and + -- control of an SNMP entity. + + snmp OBJECT IDENTIFIER ::= { mib-2 11 } + + snmpInPkts OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The total number of messages delivered to the SNMP + entity from the transport service." + ::= { snmp 1 } + + snmpInBadVersions OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The total number of SNMP messages which were delivered + to the SNMP entity and were for an unsupported SNMP + version." + ::= { snmp 3 } + + snmpInBadCommunityNames OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The total number of community-based SNMP messages (for + example, SNMPv1) delivered to the SNMP entity which + used an SNMP community name not known to said entity. + Also, implementations which authenticate community-based + SNMP messages using check(s) in addition to matching + the community name (for example, by also checking + whether the message originated from a transport address + allowed to use a specified community name) MAY include + in this value the number of messages which failed the + additional check(s). It is strongly RECOMMENDED that + the documentation for any security model which is used + to authenticate community-based SNMP messages specify + the precise conditions that contribute to this value." + ::= { snmp 4 } + + snmpInBadCommunityUses OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The total number of community-based SNMP messages (for + example, SNMPv1) delivered to the SNMP entity which + represented an SNMP operation that was not allowed for + the SNMP community named in the message. The precise + conditions under which this counter is incremented + (if at all) depend on how the SNMP entity implements + its access control mechanism and how its applications + interact with that access control mechanism. It is + strongly RECOMMENDED that the documentation for any + access control mechanism which is used to control access + to and visibility of MIB instrumentation specify the + precise conditions that contribute to this value." + ::= { snmp 5 } + + snmpInASNParseErrs OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The total number of ASN.1 or BER errors encountered by + the SNMP entity when decoding received SNMP messages." + ::= { snmp 6 } + + snmpEnableAuthenTraps OBJECT-TYPE + SYNTAX INTEGER { enabled(1), disabled(2) } + MAX-ACCESS read-write + STATUS current + DESCRIPTION + "Indicates whether the SNMP entity is permitted to + generate authenticationFailure traps. The value of this + object overrides any configuration information; as such, + it provides a means whereby all authenticationFailure + traps may be disabled. + + Note that it is strongly recommended that this object + be stored in non-volatile memory so that it remains + constant across re-initializations of the network + management system." + ::= { snmp 30 } + + snmpSilentDrops OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The total number of Confirmed Class PDUs (such as + GetRequest-PDUs, GetNextRequest-PDUs, + GetBulkRequest-PDUs, SetRequest-PDUs, and + InformRequest-PDUs) delivered to the SNMP entity which + were silently dropped because the size of a reply + containing an alternate Response Class PDU (such as a + Response-PDU) with an empty variable-bindings field + was greater than either a local constraint or the + maximum message size associated with the originator of + the request." + ::= { snmp 31 } + + snmpProxyDrops OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The total number of Confirmed Class PDUs + (such as GetRequest-PDUs, GetNextRequest-PDUs, + GetBulkRequest-PDUs, SetRequest-PDUs, and + InformRequest-PDUs) delivered to the SNMP entity which + were silently dropped because the transmission of + the (possibly translated) message to a proxy target + failed in a manner (other than a time-out) such that + no Response Class PDU (such as a Response-PDU) could + be returned." + ::= { snmp 32 } + + -- information for notifications + -- + -- a collection of objects which allow the SNMP entity, when + -- supporting a notification originator application, + -- to be configured to generate SNMPv2-Trap-PDUs. + + snmpTrap OBJECT IDENTIFIER ::= { snmpMIBObjects 4 } + + snmpTrapOID OBJECT-TYPE + SYNTAX OBJECT IDENTIFIER + MAX-ACCESS accessible-for-notify + STATUS current + DESCRIPTION + "The authoritative identification of the notification + currently being sent. This variable occurs as + the second varbind in every SNMPv2-Trap-PDU and + InformRequest-PDU." + ::= { snmpTrap 1 } + + -- ::= { snmpTrap 2 } this OID is obsolete + + snmpTrapEnterprise OBJECT-TYPE + SYNTAX OBJECT IDENTIFIER + MAX-ACCESS accessible-for-notify + STATUS current + DESCRIPTION + "The authoritative identification of the enterprise + associated with the trap currently being sent. When an + SNMP proxy agent is mapping an RFC1157 Trap-PDU + into a SNMPv2-Trap-PDU, this variable occurs as the + last varbind." + ::= { snmpTrap 3 } + + -- ::= { snmpTrap 4 } this OID is obsolete + + -- well-known traps + + snmpTraps OBJECT IDENTIFIER ::= { snmpMIBObjects 5 } + + coldStart NOTIFICATION-TYPE + STATUS current + DESCRIPTION + "A coldStart trap signifies that the SNMP entity, + supporting a notification originator application, is + reinitializing itself and that its configuration may + have been altered." + ::= { snmpTraps 1 } + + warmStart NOTIFICATION-TYPE + STATUS current + DESCRIPTION + "A warmStart trap signifies that the SNMP entity, + supporting a notification originator application, + is reinitializing itself such that its configuration + is unaltered." + ::= { snmpTraps 2 } + + -- Note the linkDown NOTIFICATION-TYPE ::= { snmpTraps 3 } + -- and the linkUp NOTIFICATION-TYPE ::= { snmpTraps 4 } + -- are defined in RFC 2863 [RFC2863] + + authenticationFailure NOTIFICATION-TYPE + STATUS current + DESCRIPTION + "An authenticationFailure trap signifies that the SNMP + entity has received a protocol message that is not + properly authenticated. While all implementations + of SNMP entities MAY be capable of generating this + trap, the snmpEnableAuthenTraps object indicates + whether this trap will be generated." + ::= { snmpTraps 5 } + + -- Note the egpNeighborLoss notification is defined + -- as { snmpTraps 6 } in RFC 1213 + + -- the set group + -- + -- a collection of objects which allow several cooperating + -- command generator applications to coordinate their use of the + -- set operation. + + snmpSet OBJECT IDENTIFIER ::= { snmpMIBObjects 6 } + + snmpSetSerialNo OBJECT-TYPE + SYNTAX TestAndIncr + MAX-ACCESS read-write + STATUS current + DESCRIPTION + "An advisory lock used to allow several cooperating + command generator applications to coordinate their + use of the SNMP set operation. + + This object is used for coarse-grain coordination. + To achieve fine-grain coordination, one or more similar + objects might be defined within each MIB group, as + appropriate." + ::= { snmpSet 1 } + + -- conformance information + + snmpMIBConformance + OBJECT IDENTIFIER ::= { snmpMIB 2 } + + snmpMIBCompliances + OBJECT IDENTIFIER ::= { snmpMIBConformance 1 } + snmpMIBGroups OBJECT IDENTIFIER ::= { snmpMIBConformance 2 } + + -- compliance statements + -- ::= { snmpMIBCompliances 1 } this OID is obsolete + snmpBasicCompliance MODULE-COMPLIANCE + STATUS deprecated + DESCRIPTION + "The compliance statement for SNMPv2 entities which + implement the SNMPv2 MIB. + + This compliance statement is replaced by + snmpBasicComplianceRev2." + MODULE -- this module + MANDATORY-GROUPS { snmpGroup, snmpSetGroup, systemGroup, + snmpBasicNotificationsGroup } + + GROUP snmpCommunityGroup1 + DESCRIPTION + "This group is mandatory for SNMPv2 entities which + support community-based authentication." + + ::= { snmpMIBCompliances 2 } + + snmpBasicComplianceRev2 MODULE-COMPLIANCE + STATUS current + DESCRIPTION + "The compliance statement for SNMP entities which + implement this MIB module." + MODULE -- this module + MANDATORY-GROUPS { snmpGroup, snmpSetGroup, systemGroup, + snmpBasicNotificationsGroup } + + GROUP snmpCommunityGroup1 + DESCRIPTION + "This group is mandatory for SNMP entities which + support community-based authentication." + + GROUP snmpWarmStartNotificationGroup + DESCRIPTION + "This group is mandatory for an SNMP entity which + supports command responder applications, and is + able to reinitialize itself such that its + configuration is unaltered." + + ::= { snmpMIBCompliances 3 } + + -- units of conformance + + -- ::= { snmpMIBGroups 1 } this OID is obsolete + -- ::= { snmpMIBGroups 2 } this OID is obsolete + -- ::= { snmpMIBGroups 3 } this OID is obsolete + -- ::= { snmpMIBGroups 4 } this OID is obsolete + + snmpGroup OBJECT-GROUP + OBJECTS { snmpInPkts, + snmpInBadVersions, + snmpInASNParseErrs, + snmpSilentDrops, + snmpProxyDrops, + snmpEnableAuthenTraps } + STATUS current + DESCRIPTION + "A collection of objects providing basic instrumentation + and control of an SNMP entity." + ::= { snmpMIBGroups 8 } + + snmpCommunityGroup1 OBJECT-GROUP + OBJECTS { snmpInBadCommunityNames, + snmpInBadCommunityUses } + STATUS current + DESCRIPTION + "A collection of objects providing basic instrumentation + of a SNMP entity which supports community-based + authentication." + ::= { snmpMIBGroups 9 } + + snmpSetGroup OBJECT-GROUP + OBJECTS { snmpSetSerialNo } + STATUS current + DESCRIPTION + "A collection of objects which allow several cooperating + command generator applications to coordinate their + use of the set operation." + ::= { snmpMIBGroups 5 } + + systemGroup OBJECT-GROUP + OBJECTS { sysDescr, sysObjectID, sysUpTime, + sysContact, sysName, sysLocation, + sysServices, + sysORLastChange, sysORID, + sysORUpTime, sysORDescr } + STATUS current + DESCRIPTION + "The system group defines objects which are common to all + managed systems." + ::= { snmpMIBGroups 6 } + + snmpBasicNotificationsGroup NOTIFICATION-GROUP + NOTIFICATIONS { coldStart, authenticationFailure } + STATUS current + DESCRIPTION + "The basic notifications implemented by an SNMP entity + supporting command responder applications." + ::= { snmpMIBGroups 7 } + + snmpWarmStartNotificationGroup NOTIFICATION-GROUP + NOTIFICATIONS { warmStart } + STATUS current + DESCRIPTION + "An additional notification for an SNMP entity supporting + command responder applications, if it is able to reinitialize + itself such that its configuration is unaltered." + ::= { snmpMIBGroups 11 } + + snmpNotificationGroup OBJECT-GROUP + OBJECTS { snmpTrapOID, snmpTrapEnterprise } + STATUS current + DESCRIPTION + "These objects are required for entities + which support notification originator applications." + ::= { snmpMIBGroups 12 } + + -- definitions in RFC 1213 made obsolete by the inclusion of a + -- subset of the snmp group in this MIB + + snmpOutPkts OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS obsolete + DESCRIPTION + "The total number of SNMP Messages which were + passed from the SNMP protocol entity to the + transport service." + ::= { snmp 2 } + + -- { snmp 7 } is not used + + snmpInTooBigs OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS obsolete + DESCRIPTION + "The total number of SNMP PDUs which were + delivered to the SNMP protocol entity and for + which the value of the error-status field was + `tooBig'." + ::= { snmp 8 } + + snmpInNoSuchNames OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS obsolete + DESCRIPTION + "The total number of SNMP PDUs which were + delivered to the SNMP protocol entity and for + which the value of the error-status field was + `noSuchName'." + ::= { snmp 9 } + + snmpInBadValues OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS obsolete + DESCRIPTION + "The total number of SNMP PDUs which were + delivered to the SNMP protocol entity and for + which the value of the error-status field was + `badValue'." + ::= { snmp 10 } + + snmpInReadOnlys OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS obsolete + DESCRIPTION + "The total number valid SNMP PDUs which were delivered + to the SNMP protocol entity and for which the value + of the error-status field was `readOnly'. It should + be noted that it is a protocol error to generate an + SNMP PDU which contains the value `readOnly' in the + error-status field, as such this object is provided + as a means of detecting incorrect implementations of + the SNMP." + ::= { snmp 11 } + + snmpInGenErrs OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS obsolete + DESCRIPTION + "The total number of SNMP PDUs which were delivered + to the SNMP protocol entity and for which the value + of the error-status field was `genErr'." + ::= { snmp 12 } + + snmpInTotalReqVars OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS obsolete + DESCRIPTION + "The total number of MIB objects which have been + retrieved successfully by the SNMP protocol entity + as the result of receiving valid SNMP Get-Request + and Get-Next PDUs." + ::= { snmp 13 } + + snmpInTotalSetVars OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS obsolete + DESCRIPTION + "The total number of MIB objects which have been + altered successfully by the SNMP protocol entity as + the result of receiving valid SNMP Set-Request PDUs." + ::= { snmp 14 } + + snmpInGetRequests OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS obsolete + DESCRIPTION + "The total number of SNMP Get-Request PDUs which + have been accepted and processed by the SNMP + protocol entity." + ::= { snmp 15 } + + snmpInGetNexts OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS obsolete + DESCRIPTION + "The total number of SNMP Get-Next PDUs which have been + accepted and processed by the SNMP protocol entity." + ::= { snmp 16 } + + snmpInSetRequests OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS obsolete + DESCRIPTION + "The total number of SNMP Set-Request PDUs which + have been accepted and processed by the SNMP protocol + entity." + ::= { snmp 17 } + + snmpInGetResponses OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS obsolete + DESCRIPTION + "The total number of SNMP Get-Response PDUs which + have been accepted and processed by the SNMP protocol + entity." + ::= { snmp 18 } + + snmpInTraps OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS obsolete + DESCRIPTION + "The total number of SNMP Trap PDUs which have been + accepted and processed by the SNMP protocol entity." + ::= { snmp 19 } + + snmpOutTooBigs OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS obsolete + DESCRIPTION + "The total number of SNMP PDUs which were generated + by the SNMP protocol entity and for which the value + of the error-status field was `tooBig.'" + ::= { snmp 20 } + + snmpOutNoSuchNames OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS obsolete + DESCRIPTION + "The total number of SNMP PDUs which were generated + by the SNMP protocol entity and for which the value + of the error-status was `noSuchName'." + ::= { snmp 21 } + + snmpOutBadValues OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS obsolete + DESCRIPTION + "The total number of SNMP PDUs which were generated + by the SNMP protocol entity and for which the value + of the error-status field was `badValue'." + ::= { snmp 22 } + + -- { snmp 23 } is not used + + snmpOutGenErrs OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS obsolete + DESCRIPTION + "The total number of SNMP PDUs which were generated + by the SNMP protocol entity and for which the value + of the error-status field was `genErr'." + ::= { snmp 24 } + + snmpOutGetRequests OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS obsolete + DESCRIPTION + "The total number of SNMP Get-Request PDUs which + have been generated by the SNMP protocol entity." + ::= { snmp 25 } + + snmpOutGetNexts OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS obsolete + DESCRIPTION + "The total number of SNMP Get-Next PDUs which have + been generated by the SNMP protocol entity." + ::= { snmp 26 } + + snmpOutSetRequests OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS obsolete + DESCRIPTION + "The total number of SNMP Set-Request PDUs which + have been generated by the SNMP protocol entity." + ::= { snmp 27 } + + snmpOutGetResponses OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS obsolete + DESCRIPTION + "The total number of SNMP Get-Response PDUs which + have been generated by the SNMP protocol entity." + ::= { snmp 28 } + + snmpOutTraps OBJECT-TYPE + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS obsolete + DESCRIPTION + "The total number of SNMP Trap PDUs which have + been generated by the SNMP protocol entity." + ::= { snmp 29 } + + snmpObsoleteGroup OBJECT-GROUP + OBJECTS { snmpOutPkts, snmpInTooBigs, snmpInNoSuchNames, + snmpInBadValues, snmpInReadOnlys, snmpInGenErrs, + snmpInTotalReqVars, snmpInTotalSetVars, + snmpInGetRequests, snmpInGetNexts, snmpInSetRequests, + snmpInGetResponses, snmpInTraps, snmpOutTooBigs, + snmpOutNoSuchNames, snmpOutBadValues, + snmpOutGenErrs, snmpOutGetRequests, snmpOutGetNexts, + snmpOutSetRequests, snmpOutGetResponses, snmpOutTraps + } + STATUS obsolete + DESCRIPTION + "A collection of objects from RFC 1213 made obsolete + by this MIB module." + ::= { snmpMIBGroups 10 } + +END diff -Nur svn/observium/mibs/cisco/SNMPv2-SMI.my observium.cimc/mibs/cisco/SNMPv2-SMI.my --- svn/observium/mibs/cisco/SNMPv2-SMI.my 1970-01-01 02:00:00.000000000 +0200 +++ observium.cimc/mibs/cisco/SNMPv2-SMI.my 2013-08-21 14:12:44.000000000 +0300 @@ -0,0 +1,49 @@ +-- ***************************************************************** +-- SNMPv2-SMI.my: SNMPv2 Structure of Management Information +-- +-- May 1994, Jeffrey T. Johnson +-- +-- Copyright (c) 1994,1996 by cisco Systems, Inc. +-- All rights reserved. +-- +-- ***************************************************************** +-- +-- The following was extracted from RFC 1902 +-- All macro definitions have been removed because they are +-- predefined in the mib compiler + +SNMPv2-SMI DEFINITIONS ::= BEGIN + + +-- the path to the root + +org OBJECT IDENTIFIER ::= { iso 3 } +dod OBJECT IDENTIFIER ::= { org 6 } +internet OBJECT IDENTIFIER ::= { dod 1 } + +directory OBJECT IDENTIFIER ::= { internet 1 } + +mgmt OBJECT IDENTIFIER ::= { internet 2 } +mib-2 OBJECT IDENTIFIER ::= { mgmt 1 } +transmission OBJECT IDENTIFIER ::= { mib-2 10 } + +experimental OBJECT IDENTIFIER ::= { internet 3 } + +private OBJECT IDENTIFIER ::= { internet 4 } +enterprises OBJECT IDENTIFIER ::= { private 1 } + +security OBJECT IDENTIFIER ::= { internet 5 } + +snmpV2 OBJECT IDENTIFIER ::= { internet 6 } + +-- transport domains +snmpDomains OBJECT IDENTIFIER ::= { snmpV2 1 } + +-- transport proxies +snmpProxys OBJECT IDENTIFIER ::= { snmpV2 2 } + +-- module identities +snmpModules OBJECT IDENTIFIER ::= { snmpV2 3 } + +END + diff -Nur svn/observium/mibs/cisco/SNMPv2-TC.my observium.cimc/mibs/cisco/SNMPv2-TC.my --- svn/observium/mibs/cisco/SNMPv2-TC.my 1970-01-01 02:00:00.000000000 +0200 +++ observium.cimc/mibs/cisco/SNMPv2-TC.my 2013-08-21 14:13:09.000000000 +0300 @@ -0,0 +1,729 @@ +-- ***************************************************************** +-- SNMPv2-TC.my: SNMPv2 Textual Conventions +-- +-- May 1994, Jeffrey T. Johnson +-- +-- Copyright (c) 1994,1996 by cisco Systems, Inc. +-- All rights reserved. +-- +-- ***************************************************************** +-- +-- This file was extracted from RFC 1903 +-- All macro definitions have been removed because they are +-- predefined in the mib compiler + + +SNMPv2-TC DEFINITIONS ::= BEGIN + +IMPORTS + ObjectSyntax, TimeTicks + FROM SNMPv2-SMI; + + +-- definition of textual conventions + +DisplayString ::= TEXTUAL-CONVENTION + DISPLAY-HINT "255a" + STATUS current + DESCRIPTION + "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." + SYNTAX OCTET STRING (SIZE (0..255)) + + +PhysAddress ::= TEXTUAL-CONVENTION + DISPLAY-HINT "1x:" + STATUS current + DESCRIPTION + "Represents media- or physical-level addresses." + SYNTAX OCTET STRING + + +MacAddress ::= TEXTUAL-CONVENTION + DISPLAY-HINT "1x:" + STATUS current + DESCRIPTION + "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." + SYNTAX OCTET STRING (SIZE (6)) + + +TruthValue ::= TEXTUAL-CONVENTION + STATUS current + DESCRIPTION + "Represents a boolean value." + SYNTAX INTEGER { true(1), false(2) } + +TestAndIncr ::= TEXTUAL-CONVENTION + STATUS current + DESCRIPTION + "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." + SYNTAX INTEGER (0..2147483647) + + +AutonomousType ::= TEXTUAL-CONVENTION + STATUS current + DESCRIPTION + "Represents an independently extensible type identification + value. It may, for example, indicate a particular sub-tree + with further MIB definitions, or define a particular type of + protocol or hardware." + SYNTAX OBJECT IDENTIFIER + + +InstancePointer ::= TEXTUAL-CONVENTION + STATUS obsolete + DESCRIPTION + "A pointer to either a specific instance of a MIB object or + a conceptual row of a MIB table in the managed device. In + the latter case, by convention, it is the name of the + particular instance of the first accessible columnar object + in the conceptual row. + + The two uses of this textual convention are replaced by + VariablePointer and RowPointer, respectively." + SYNTAX OBJECT IDENTIFIER + + +VariablePointer ::= TEXTUAL-CONVENTION + STATUS current + DESCRIPTION + "A pointer to a specific object instance. For example, + sysContact.0 or ifInOctets.3." + SYNTAX OBJECT IDENTIFIER + + +RowPointer ::= TEXTUAL-CONVENTION + STATUS current + DESCRIPTION + "Represents a pointer to a conceptual row. The value is the + name of the instance of the first accessible columnar object + in the conceptual row. + + For example, ifIndex.3 would point to the 3rd row in the + ifTable (note that if ifIndex were not-accessible, then + ifDescr.3 would be used instead)." + SYNTAX OBJECT IDENTIFIER + + +RowStatus ::= TEXTUAL-CONVENTION + STATUS current + DESCRIPTION + "The RowStatus textual convention is used to manage the + creation and deletion of conceptual rows, and is used as the + value of the SYNTAX clause for the status column of a + conceptual row (as described in Section 7.7.1 of [2].) + + The status column has six defined values: + + - `active', which indicates that the conceptual row is + available for use by the managed device; + + - `notInService', which indicates that the conceptual + row exists in the agent, but is unavailable for use by + the managed device (see NOTE below); + + - `notReady', which indicates that the conceptual row + exists in the agent, but is missing information + necessary in order to be available for use by the + managed device; + + - `createAndGo', which is supplied by a management + station wishing to create a new instance of a + conceptual row and to have its status automatically set + to active, making it available for use by the managed + device; + + - `createAndWait', which is supplied by a management + station wishing to create a new instance of a + conceptual row (but not make it available for use by + the managed device); and, + + - `destroy', which is supplied by a management station + wishing to delete all of the instances associated with + an existing conceptual row. + + Whereas five of the six values (all except `notReady') may + be specified in a management protocol set operation, only + three values will be returned in response to a management + protocol retrieval operation: `notReady', `notInService' or + `active'. That is, when queried, an existing conceptual row + has only three states: it is either available for use by + the managed device (the status column has value `active'); + it is not available for use by the managed device, though + the agent has sufficient information to make it so (the + status column has value `notInService'); or, it is not + available for use by the managed device, and an attempt to + make it so would fail because the agent has insufficient + information (the state column has value `notReady'). + + NOTE WELL + + This textual convention may be used for a MIB table, + irrespective of whether the values of that table's + conceptual rows are able to be modified while it is + active, or whether its conceptual rows must be taken + out of service in order to be modified. That is, it is + the responsibility of the DESCRIPTION clause of the + status column to specify whether the status column must + not be `active' in order for the value of some other + column of the same conceptual row to be modified. If + such a specification is made, affected columns may be + changed by an SNMP set PDU if the RowStatus would not + be equal to `active' either immediately before or after + processing the PDU. In other words, if the PDU also + contained a varbind that would change the RowStatus + value, the column in question may be changed if the + RowStatus was not equal to `active' as the PDU was + received, or if the varbind sets the status to a value + other than 'active'. + + + Also note that whenever any elements of a row exist, the + RowStatus column must also exist. + + + To summarize the effect of having a conceptual row with a + status column having a SYNTAX clause value of RowStatus, + consider the following state diagram: + + + STATE + +--------------+-----------+-------------+------------- + | A | B | C | D + | |status col.|status column| + |status column | is | is |status column + ACTION |does not exist| notReady | notInService| is active +--------------+--------------+-----------+-------------+------------- +set status |noError ->D|inconsist- |inconsistent-|inconsistent- +column to | or | entValue| Value| Value +createAndGo |inconsistent- | | | + | Value| | | +--------------+--------------+-----------+-------------+------------- +set status |noError see 1|inconsist- |inconsistent-|inconsistent- +column to | or | entValue| Value| Value +createAndWait |wrongValue | | | +--------------+--------------+-----------+-------------+------------- +set status |inconsistent- |inconsist- |noError |noError +column to | Value| entValue| | +active | | | | + | | or | | + | | | | + | |see 2 ->D| ->D| ->D +--------------+--------------+-----------+-------------+------------- +set status |inconsistent- |inconsist- |noError |noError ->C +column to | Value| entValue| | +notInService | | | | + | | or | | or + | | | | + | |see 3 ->C| ->C|wrongValue +--------------+--------------+-----------+-------------+------------- +set status |noError |noError |noError |noError +column to | | | | +destroy | ->A| ->A| ->A| ->A +--------------+--------------+-----------+-------------+------------- +set any other |see 4 |noError |noError |see 5 +column to some| | | | +value | | see 1| ->C| ->D +--------------+--------------+-----------+-------------+------------- + + (1) goto B or C, depending on information available to the + agent. + + (2) if other variable bindings included in the same PDU, + provide values for all columns which are missing but + required, then return noError and goto D. + + (3) if other variable bindings included in the same PDU, + provide values for all columns which are missing but + required, then return noError and goto C. + + (4) at the discretion of the agent, the return value may be + either: + + inconsistentName: because the agent does not choose to + create such an instance when the corresponding + RowStatus instance does not exist, or + + inconsistentValue: if the supplied value is + inconsistent with the state of some other MIB object's + value, or + + noError: because the agent chooses to create the + instance. + + If noError is returned, then the instance of the status + column must also be created, and the new state is B or C, + depending on the information available to the agent. If + inconsistentName or inconsistentValue is returned, the row + remains in state A. + + (5) depending on the MIB definition for the column/table, + either noError or inconsistentValue may be returned. + + NOTE: Other processing of the set request may result in a + response other than noError being returned, e.g., + wrongValue, noCreation, etc. + + + Conceptual Row Creation + + There are four potential interactions when creating a + conceptual row: selecting an instance-identifier which is + not in use; creating the conceptual row; initializing any + objects for which the agent does not supply a default; and, + making the conceptual row available for use by the managed + device. + + Interaction 1: Selecting an Instance-Identifier + + The algorithm used to select an instance-identifier varies + for each conceptual row. In some cases, the instance- + identifier is semantically significant, e.g., the + destination address of a route, and a management station + selects the instance-identifier according to the semantics. + + In other cases, the instance-identifier is used solely to + distinguish conceptual rows, and a management station + without specific knowledge of the conceptual row might + examine the instances present in order to determine an + unused instance-identifier. (This approach may be used, but + it is often highly sub-optimal; however, it is also a + questionable practice for a naive management station to + attempt conceptual row creation.) + + Alternately, the MIB module which defines the conceptual row + might provide one or more objects which provide assistance + in determining an unused instance-identifier. For example, + if the conceptual row is indexed by an integer-value, then + an object having an integer-valued SYNTAX clause might be + defined for such a purpose, allowing a management station to + issue a management protocol retrieval operation. In order + to avoid unnecessary collisions between competing management + stations, `adjacent' retrievals of this object should be + different. + + Finally, the management station could select a pseudo-random + number to use as the index. In the event that this index + was already in use and an inconsistentValue was returned in + response to the management protocol set operation, the + management station should simply select a new pseudo-random + number and retry the operation. + + A MIB designer should choose between the two latter + algorithms based on the size of the table (and therefore the + efficiency of each algorithm). For tables in which a large + number of entries are expected, it is recommended that a MIB + object be defined that returns an acceptable index for + creation. For tables with small numbers of entries, it is + recommended that the latter pseudo-random index mechanism be + used. + + Interaction 2: Creating the Conceptual Row + + Once an unused instance-identifier has been selected, the + management station determines if it wishes to create and + activate the conceptual row in one transaction or in a + negotiated set of interactions. + + Interaction 2a: Creating and Activating the Conceptual Row + + The management station must first determine the column + requirements, i.e., it must determine those columns for + which it must or must not provide values. Depending on the + complexity of the table and the management station's + knowledge of the agent's capabilities, this determination + can be made locally by the management station. Alternately, + the management station issues a management protocol get + operation to examine all columns in the conceptual row that + it wishes to create. In response, for each column, there + are three possible outcomes: + + - a value is returned, indicating that some other + management station has already created this conceptual + row. We return to interaction 1. + + - the exception `noSuchInstance' is returned, + indicating that the agent implements the object-type + associated with this column, and that this column in at + least one conceptual row would be accessible in the MIB + view used by the retrieval were it to exist. For those + columns to which the agent provides read-create access, + the `noSuchInstance' exception tells the management + station that it should supply a value for this column + when the conceptual row is to be created. + + - the exception `noSuchObject' is returned, indicating + that the agent does not implement the object-type + associated with this column or that there is no + conceptual row for which this column would be + accessible in the MIB view used by the retrieval. As + such, the management station can not issue any + management protocol set operations to create an + instance of this column. + + Once the column requirements have been determined, a + management protocol set operation is accordingly issued. + This operation also sets the new instance of the status + column to `createAndGo'. + + When the agent processes the set operation, it verifies that + it has sufficient information to make the conceptual row + available for use by the managed device. The information + available to the agent is provided by two sources: the + management protocol set operation which creates the + conceptual row, and, implementation-specific defaults + supplied by the agent (note that an agent must provide + implementation-specific defaults for at least those objects + which it implements as read-only). If there is sufficient + information available, then the conceptual row is created, a + `noError' response is returned, the status column is set to + `active', and no further interactions are necessary (i.e., + interactions 3 and 4 are skipped). If there is insufficient + information, then the conceptual row is not created, and the + set operation fails with an error of `inconsistentValue'. + On this error, the management station can issue a management + protocol retrieval operation to determine if this was + because it failed to specify a value for a required column, + or, because the selected instance of the status column + already existed. In the latter case, we return to + interaction 1. In the former case, the management station + can re-issue the set operation with the additional + information, or begin interaction 2 again using + `createAndWait' in order to negotiate creation of the + conceptual row. + + NOTE WELL + + Regardless of the method used to determine the column + requirements, it is possible that the management + station might deem a column necessary when, in fact, + the agent will not allow that particular columnar + instance to be created or written. In this case, the + management protocol set operation will fail with an + error such as `noCreation' or `notWritable'. In this + case, the management station decides whether it needs + to be able to set a value for that particular columnar + instance. If not, the management station re-issues the + management protocol set operation, but without setting + a value for that particular columnar instance; + otherwise, the management station aborts the row + creation algorithm. + + Interaction 2b: Negotiating the Creation of the Conceptual + Row + + The management station issues a management protocol set + operation which sets the desired instance of the status + column to `createAndWait'. If the agent is unwilling to + process a request of this sort, the set operation fails with + an error of `wrongValue'. (As a consequence, such an agent + must be prepared to accept a single management protocol set + operation, i.e., interaction 2a above, containing all of the + columns indicated by its column requirements.) Otherwise, + the conceptual row is created, a `noError' response is + returned, and the status column is immediately set to either + `notInService' or `notReady', depending on whether it has + sufficient information to make the conceptual row available + for use by the managed device. If there is sufficient + information available, then the status column is set to + `notInService'; otherwise, if there is insufficient + information, then the status column is set to `notReady'. + Regardless, we proceed to interaction 3. + + Interaction 3: Initializing non-defaulted Objects + + The management station must now determine the column + requirements. It issues a management protocol get operation + to examine all columns in the created conceptual row. In + the response, for each column, there are three possible + outcomes: + + - a value is returned, indicating that the agent + implements the object-type associated with this column + and had sufficient information to provide a value. For + those columns to which the agent provides read-create + access (and for which the agent allows their values to + be changed after their creation), a value return tells + the management station that it may issue additional + management protocol set operations, if it desires, in + order to change the value associated with this column. + + - the exception `noSuchInstance' is returned, + indicating that the agent implements the object-type + associated with this column, and that this column in at + least one conceptual row would be accessible in the MIB + view used by the retrieval were it to exist. However, + the agent does not have sufficient information to + provide a value, and until a value is provided, the + conceptual row may not be made available for use by the + managed device. For those columns to which the agent + provides read-create access, the `noSuchInstance' + exception tells the management station that it must + issue additional management protocol set operations, in + order to provide a value associated with this column. + + - the exception `noSuchObject' is returned, indicating + that the agent does not implement the object-type + associated with this column or that there is no + conceptual row for which this column would be + accessible in the MIB view used by the retrieval. As + such, the management station can not issue any + management protocol set operations to create an + instance of this column. + + If the value associated with the status column is + `notReady', then the management station must first deal with + all `noSuchInstance' columns, if any. Having done so, the + value of the status column becomes `notInService', and we + proceed to interaction 4. + + Interaction 4: Making the Conceptual Row Available + + Once the management station is satisfied with the values + associated with the columns of the conceptual row, it issues + a management protocol set operation to set the status column + to `active'. If the agent has sufficient information to + make the conceptual row available for use by the managed + device, the management protocol set operation succeeds (a + `noError' response is returned). Otherwise, the management + protocol set operation fails with an error of + `inconsistentValue'. + + + NOTE WELL + + A conceptual row having a status column with value + `notInService' or `notReady' is unavailable to the + managed device. As such, it is possible for the + managed device to create its own instances during the + time between the management protocol set operation + which sets the status column to `createAndWait' and the + management protocol set operation which sets the status + column to `active'. In this case, when the management + protocol set operation is issued to set the status + column to `active', the values held in the agent + supersede those used by the managed device. + + If the management station is prevented from setting the + status column to `active' (e.g., due to management station + or network failure) the conceptual row will be left in the + `notInService' or `notReady' state, consuming resources + indefinitely. The agent must detect conceptual rows that + have been in either state for an abnormally long period of + time and remove them. It is the responsibility of the + DESCRIPTION clause of the status column to indicate what an + abnormally long period of time would be. This period of + time should be long enough to allow for human response time + (including `think time') between the creation of the + conceptual row and the setting of the status to `active'. + In the absense of such information in the DESCRIPTION + clause, it is suggested that this period be approximately 5 + minutes in length. This removal action applies not only to + newly-created rows, but also to previously active rows which + are set to, and left in, the notInService state for a + prolonged period exceeding that which is considered normal + for such a conceptual row. + + + Conceptual Row Suspension + + When a conceptual row is `active', the management station + may issue a management protocol set operation which sets the + instance of the status column to `notInService'. If the + agent is unwilling to do so, the set operation fails with an + error of `wrongValue'. Otherwise, the conceptual row is + taken out of service, and a `noError' response is returned. + It is the responsibility of the DESCRIPTION clause of the + status column to indicate under what circumstances the + status column should be taken out of service (e.g., in order + for the value of some other column of the same conceptual + row to be modified). + + + Conceptual Row Deletion + + For deletion of conceptual rows, a management protocol set + operation is issued which sets the instance of the status + column to `destroy'. This request may be made regardless of + the current value of the status column (e.g., it is possible + to delete conceptual rows which are either `notReady', + `notInService' or `active'.) If the operation succeeds, + then all instances associated with the conceptual row are + immediately removed." + + + SYNTAX INTEGER { + -- the following two values are states: + -- these values may be read or written + active(1), + notInService(2), + + -- the following value is a state: + -- this value may be read, but not written + notReady(3), + + -- the following three values are + -- actions: these values may be written, + -- but are never read + createAndGo(4), + createAndWait(5), + destroy(6) + } + + +TimeStamp ::= TEXTUAL-CONVENTION + STATUS current + DESCRIPTION + "The value of the sysUpTime object at which a specific + occurrence happened. The specific occurrence must be + defined in the description of any object defined using this + type." + SYNTAX TimeTicks + + +TimeInterval ::= TEXTUAL-CONVENTION + STATUS current + DESCRIPTION + "A period of time, measured in units of 0.01 seconds." + SYNTAX INTEGER (0..2147483647) + + +DateAndTime ::= TEXTUAL-CONVENTION + DISPLAY-HINT "2d-1d-1d,1d:1d:1d.1d,1a1d:1d" + STATUS current + DESCRIPTION + "A date-time specification. + + field octets contents range + ----- ------ -------- ----- + 1 1-2 year 0..65536 + 2 3 month 1..12 + 3 4 day 1..31 + 4 5 hour 0..23 + 5 6 minutes 0..59 + 6 7 seconds 0..60 + (use 60 for leap-second) + 7 8 deci-seconds 0..9 + 8 9 direction from UTC '+' / '-' + 9 10 hours from UTC 0..11 + 10 11 minutes from UTC 0..59 + + For example, Tuesday May 26, 1992 at 1:30:15 PM EDT would be + displayed as: + + 1992-5-26,13:30:15.0,-4:0 + + Note that if only local time is known, then timezone + information (fields 8-10) is not present." + SYNTAX OCTET STRING (SIZE (8 | 11)) + + +StorageType ::= TEXTUAL-CONVENTION + STATUS current + DESCRIPTION + "Describes the memory realization of a conceptual row. A + row which is volatile(2) is lost upon reboot. A row which + is either nonVolatile(3), permanent(4) or readOnly(5), is + backed up by stable storage. A row which is permanent(4) + can be changed but not deleted. A row which is readOnly(5) + cannot be changed nor deleted. + + If the value of an object with this syntax is either + permanent(4) or readOnly(5), it cannot be modified. + Conversely, if the value is either other(1), volatile(2) or + nonVolatile(3), it cannot be modified to be permanent(4) or + readOnly(5). + + Every usage of this textual convention is required to + specify the columnar objects which a permanent(4) row must + at a minimum allow to be writable." + SYNTAX INTEGER { + other(1), -- eh? + volatile(2), -- e.g., in RAM + nonVolatile(3), -- e.g., in NVRAM + permanent(4), -- e.g., partially in ROM + readOnly(5) -- e.g., completely in ROM + } + + +TDomain ::= TEXTUAL-CONVENTION + STATUS current + DESCRIPTION + "Denotes a kind of transport service. + + Some possible values, such as snmpUDPDomain, are defined in + 'Transport Mappings for Version 2 of the Simple Network + Management Protocol (SNMPv2)'." + SYNTAX OBJECT IDENTIFIER + + +TAddress ::= TEXTUAL-CONVENTION + STATUS current + DESCRIPTION + "Denotes a transport service address. + + For snmpUDPDomain, a TAddress is 6 octets long, the initial 4 + octets containing the IP-address in network-byte order and the + last 2 containing the UDP port in network-byte order. Consult + 'Transport Mappings for Version 2 of the Simple Network + Management Protocol (SNMPv2)' for further information on + snmpUDPDomain." + SYNTAX OCTET STRING (SIZE (1..255)) + + +END +