RFC 3418
Management Information Base (MIB) for the Simple Network Management Protocol (SNMP)
RFC 3418: Management Information Base (MIB) for the Simple Network Management Protocol (SNMP) 💖
okay bestie, this is the RFC that defines the SNMPv2-MIB, the standard set of managed objects that describe what an SNMP entity is and what it can do 🫶
Editor of this version: R. Presuhn, BMC Software, Inc. Authors of previous version: J. Case (SNMP Research, Inc.), K. McCloghrie (Cisco Systems, Inc.), M. Rose (Dover Beach Consulting, Inc.), S. Waldbusser (International Network Services) Category: Standards Track 🔥 STD: 62 Date: December 2002 Obsoletes: RFC 1907
Network Working Group, so this is an official IETF doc. It obsoletes RFC 1907, which is the one before it. It doesn't update anything else 🌸
Status of this Memo
so this doc specifies an Internet standards track protocol for the Internet community, and it's literally asking for discussion and suggestions for improvements 🦋 if you want the current standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1). and distribution of this memo is unlimited, so share it with everyone 💅
Copyright Notice
Copyright (C) The Internet Society (2002). All Rights Reserved. 🔒
Abstract
this doc defines managed objects that describe the behavior of a Simple Network Management Protocol (SNMP) entity ✨ it obsoletes RFC 1907, Management Information Base for Version 2 of the Simple Network Management Protocol (SNMPv2), so that's the glow-up era 🌈
Table of Contents
1. The Internet-Standard Management Framework .................. 2
2. Definitions ................................................. 2
3. Notice on Intellectual Property ............................. 20
4. Acknowledgments ............................................. 21
5. Security Considerations ..................................... 22
6. References .................................................. 23
6.1. Normative References ...................................... 23
6.2. Informative References .................................... 24
7. Changes from RFC 1907 ....................................... 24
8. Editor's Address ............................................ 25
9. Full Copyright Statement .................................... 261. The Internet-Standard Management Framework ✨
okay so if you want the big picture of the documents that make up the current Internet-Standard Management Framework, check section 7 of RFC 3410 [RFC3410]. it's giving overview energy 🧚
managed objects are accessed through a virtual information store called the Management Information Base, or MIB 💜 MIB objects are generally accessed through the Simple Network Management Protocol (SNMP).
the objects in the MIB are defined using the mechanisms in the Structure of Management Information (SMI). this memo specifies a MIB module that is compliant to the SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580] 🎀
the whole point of this doc is to define managed objects that describe the behavior of an SNMP entity, as defined in the SNMP architecture STD 62, [RFC3411] 🍓
the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [RFC2119]. so those capitalized words are the ones that really matter, bestie 👑
2. Definitions 🧚
here's the actual MIB module, copied exactly as written, because the details are everything 💅
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 }Okay so the sysORTable is the part of the MIB where each entry describes a capability the agent supports, bestie 💖 Here's the entry definition and its columns:
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 }Next up is the SNMP group 💜 It's a bundle of basic counters and controls for an SNMP entity, so think of it as the entity's little scoreboard 🧚
-- 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 }The counters are giving "tell me everything that went wrong" 😭 and snmpEnableAuthenTraps is the switch for the authenticationFailure trap, so it's the one to watch.
Now the notifications part 🦋 This is where the entity gets set up to send SNMPv2-Trap-PDUs, plus the well-known traps like coldStart and warmStart.
-- 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 1213Last bit for this part is the set group 🎀 It's the lock that lets several command generators coordinate their use of the set operation, which is so cooperative of them 🫶
-- 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 snmpCommunityGroup
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 snmpCommunityGroup
DESCRIPTION
"This group is mandatory for SNMP entities which
support community-based authentication."Okay bestie, we're picking up mid-MIB, right where the warm start compliance group is wrapping up 🎀✨
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 obsoleteSo the compliance bit says the warm start group is mandatory for an entity that does command responder stuff AND can reinitialise itself with its config left alone 💅 And then we get the units of conformance, where four OIDs are just marked obsolete, so they're like the ex-girlfriends of this MIB 💀 🫶
Next up, the real groups. These are the bundles that actually hold the objects and notifications 🦋
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 }
snmpCommunityGroup 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 }Quick vibe check on those 🌸 The snmpGroup is the basic instrumentation crew, the community one is for entities doing community-based auth, the set group helps cooperating command generators coordinate their set operations, and systemGroup is the stuff every managed system shares 👑 Then there are the notification groups, with warmStart getting its own group, and the notification originator objects. Lowkey iconic organisation 🧚
Now the RFC 1213 leftovers. Basically the MIB is saying "these older definitions got made obsolete by this subset of the snmp group," so they're still here but retired 🥀 Each one is an obsolete Counter32 🍓
-- 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 }Ngl, that's a whole graveyard of counters 💀 Each one is a read-only Counter32 marked obsolete, and the descriptions are all about PDUs counted by error-status value, like tooBig, noSuchName, badValue and genErr 🙈 The snmpInReadOnlys one is extra spicy because it says that generating a PDU with readOnly in the error-status field is a protocol error, so the counter exists to catch implementations doing that 🔥 Also { snmp 7 } and { snmp 23 } are just unused, so they're literally reserved vibes 🌈
Last bit: the obsolete group that bundles all of those RFC 1213 leftovers together, and then the end of the module 🎀
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 }
ENDAnd that's the MIB module wrapped up, periodt 💅✨ The obsolete group gathers every one of those RFC 1213 objects into one retired bundle, and then END closes it out 👑 Bestie, we're so close to the finish line 🦋💜
3. Notice on Intellectual Property 💅
Okay so, the IETF is not picking a side here 🫢 It takes no position on whether any intellectual property or other rights that someone might claim over this technology are valid, or how far they reach, or whether any license under them is even available. It also doesn't say it has tried to find out what rights exist. If you want the details on how the IETF handles rights for standards-track and standards-related documents, check BCP-11. Copies of any claims of rights that were filed for publication, plus any promises to license, or the results of attempts to get a general license or permission for implementors or users of this spec, can be requested from the IETF Secretariat. 📄
The IETF also invites anyone to flag any copyrights, patents, patent applications, or other proprietary rights that might cover technology needed to implement this standard. Send that info to the IETF Executive Director 🦋
4. Acknowledgments 🎀
This document is the product of the SNMPv3 Working Group 🌸 Huge thanks to these Working Group members:
- Randy Bush
- Jeffrey D. Case
- Mike Daniele
- Rob Frye
- Lauren Heintz
- Keith McCloghrie
- Russ Mundy
- David T. Perkins
- Randy Presuhn
- Aleksey Romanov
- Juergen Schoenwaelder
- Bert Wijnen
This version of the document was edited by Randy Presuhn, and it was first based on the work of a design team made up of:
- Jeffrey D. Case
- Keith McCloghrie
- David T. Perkins
- Randy Presuhn
- Juergen Schoenwaelder
The previous versions of this document were edited by Keith McCloghrie, and they were the result of major work by four main contributors:
- Jeffrey D. Case
- Keith McCloghrie
- Marshall T. Rose
- Steven Waldbusser
The SNMPv2 Working Group also contributed to the previous versions, and they deserve a shoutout too ✨ Special thanks go to:
- Alexander I. Alten
- Dave Arneson
- Uri Blumenthal
- Doug Book
- Kim Curran
- Jim Galvin
- Maria Greene
- Iain Hanson
- Dave Harrington
- Nguyen Hien
- Jeff Johnson
- Michael Kornegay
- Deirdre Kostick
- David Levi
- Daniel Mahoney
- Bob Natale
- Brian O'Keefe
- Andrew Pearson
- Dave Perkins
- Randy Presuhn
- Aleksey Romanov
- Shawn Routhier
- Jon Saperia
- Juergen Schoenwaelder
- Bob Stewart
- Kaj Tesink
- Glenn Waters
- Bert Wijnen
5. Security Considerations 🔐
Okay, this part is seriously important 😭 There are a bunch of management objects in this MIB that have a MAX-ACCESS clause of read-write. Those objects may be considered sensitive or vulnerable in some network environments. Supporting SET operations in a non-secure environment without proper protection can really mess with network operations 💀
SNMPv1 by itself is not a secure environment 🙈 Even if the network itself is secure (for example by using IPSec), there is still no control over who on that secure network is allowed to GET/SET (read/change) the objects in this MIB. Not it 😤
It is recommended that implementors consider the security features provided by the SNMPv3 framework. Specifically, the use of the User-based Security Model STD 62, RFC 3414 [RFC3414] and the View-based Access Control Model STD 62, RFC 3415 [RFC3415] is recommended 🫶
After that, it's on the customer/user to make sure the SNMP entity giving access to an instance of this MIB is set up properly, so the objects are only accessible to principals (users) who have legitimate rights to GET or SET (change) them 👑
6. References 📚
6.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
Rose, M. and S. Waldbusser, "Structure of Management
Information Version 2 (SMIv2)", STD 58, RFC 2578, April
1999.
[RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
Rose, M. and S. Waldbusser, "Textual Conventions for
SMIv2", STD 58, RFC 2579, April 1999.
[RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
Rose, M. and S. Waldbusser, "Conformance Statements for
SMIv2", STD 58, RFC 2580, April 1999.
[RFC3411] Harrington, D., Presuhn, R. and B. Wijnen, "An
Architecture for describing Simple Network Management
Protocol (SNMP) Management Frameworks", STD 62, RFC 3411,
December 2002.
[RFC3414] Blumenthal, U. and B. Wijnen, "The User-Based Security
Model (USM) for Version 3 of the Simple Network
Management Protocol (SNMPv3)", STD 62, RFC 3414, December
2002.
[RFC3415] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based
Access Control Model (VACM) for the Simple Network
Management Protocol (SNMP)", STD 62, RFC 3415, December
2002.6.1. Informative References
[RFC1157] Case, J., Fedor, M., Schoffstall, M. and J. Davin,
"Simple Network Management Protocol", STD 15, RFC 1157,
May 1990.
[RFC1213] McCloghrie, K. and M. Rose, "Management Information Base
for Network Management of TCP/IP-based internets: MIB-
II", STD 16, RFC 1213, March 1991.
[RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group
MIB", RFC 2863, June 2000.
[RFC3410] Case, J., Mundy, R., Partain, D. and B. Stewart,
"Introduction and Applicability Statements for Internet-
Standard Management Framework", RFC 3410, December 2002.7. Changes from RFC 1907 🦋
Here's what changed from RFC 1907, the tea ☕
- Corrected typo in copyright statement;
- Updated copyright date;
- Updated with new editor's name and contact information;
- Cosmetic fixes to layout and typography;
- Changed title;
- Replace introduction with current MIB boilerplate;
- Updated references;
- Fixed typo in sysORUpTime;
- Re-worded description of snmpSilentDrops;
- Updated reference to RFC 1573 to 2863;
- Added IPR boilerplate as required by RFC 2026;
- Weakened authenticationFailure description from MUST to MAY, clarified that it pertains to all SNMP entities;
- Clarified descriptions of snmpInBadCommunityNames and snmpInBadCommunityUses;
- Updated module-identity and contact information;
- Updated the acknowledgments section;
- Replaced references to "manager role", "agent role" and "SNMPv2 entity" with appropriate terms from RFC 2571;
- Updated document headers and footers;
- Added security considerations, based on current recommendations for MIB modules;
- Added NOTIFICATION-GROUP and OBJECT-GROUP constructs for NOTIFICATION-TYPEs and OBJECT-TYPEs that were left unreferenced in RFC 1907;
- Fixed typos in sysServices DESCRIPTION;
- Changed description of snmpProxyDrops to use terms from architecture;
- Changed value used in example for sysObjectID;
- Added an abstract;
- Deprecated the snmpBasicCompliance MODULE-COMPLIANCE, and added the snmpBasicComplianceRev2 MODULE-COMPLIANCE to take its place;
- Updated working group mailing list address;
- Added co-chair's address.
8. Editor's Address 📬
Randy Presuhn
BMC Software, Inc.
2141 North First Street
San Jose, CA 95131
USA
Phone: +1 408 546 1006
EMail: randy_presuhn@bmc.com9. Full Copyright Statement 💜
Copyright (C) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement ✨
Funding for the RFC Editor function is currently provided by the Internet Society. 🌈
📦 where this page comes from
- ietf: rfc3418 2002-12
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms