SNMP-FRAMEWORK-MIB(7)
✨ NAME ✨
Okay bestie, this is SNMP-FRAMEWORK-MIB(7) — the Erlang/OTP MIB module for textual conventions used in the SNMP management architecture. It's giving formal ASN.1 but make it group chat 💅.
🌸 DESCRIPTION 🌸
Okay so the page opens with the actual MIB definition, and SNMP-FRAMEWORK-MIB DEFINITIONS ::= BEGIN is literally the main character. Here's the source exactly as it appears — copy it character-for-character, no autocorrect, no “fixing” the spacing, periodt:
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 "9901190000Z" -- 19 January 1999
ORGANIZATION "SNMPv3 Working Group"
CONTACT-INFO "WG-EMail: snmpv3@tis.com
Subscribe: majordomo@tis.com
In message body: subscribe snmpv3
Chair: Russ Mundy
TIS Labs at Network Associates
postal: 3060 Washington Rd
Glenwood MD 21738
USA
EMail: mundy@tis.com
phone: +1 301-854-6889
Co-editor Dave Harrington
Cabletron Systems, Inc.
postal: Post Office Box 5005
Mail Stop: Durham
35 Industrial Way
Rochester, NH 03867-5005
USA
EMail: dbh@ctron.com
phone: +1 603-337-7357
Co-editor Randy Presuhn
BMC Software, Inc.
postal: 965 Stewart Drive
Sunnyvale, CA 94086
USA
EMail: randy_presuhn@bmc.com
phone: +1 408-616-3100
Co-editor: Bert Wijnen
IBM T.J. Watson Research
postal: Schagen 33
3461 GL Linschoten
Netherlands
EMail: wijnen@vnet.ibm.com
phone: +31 348-432-794
"
DESCRIPTION "The SNMP Management Architecture MIB"
REVISION "9901190000Z" -- 19 January 1999
DESCRIPTION "Updated editors' addresses, fixed typos.
"
REVISION "9711200000Z" -- 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 strings 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
127-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
securityModel of the Security Subsystem within the
SNMP Management Architecture.
The values for securityModel are allocated as
follows:
- The zero value is reserved.
- 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
260.
This scheme for allocation of securityModel
values allows for a maximum of 255 standards-
based Security Models, and for a maximum of
255 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 255
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:
"🫶 snmpFrameworkMIB — the module identity
- It's a
MODULE-IDENTITYwithLAST-UPDATED "9901190000Z"— that's 19 January 1999, bestie. ORGANIZATION "SNMPv3 Working Group".- The
CONTACT-INFOblock has the full contact situation: WG-EMailsnmpv3@tis.com; Subscribemajordomo@tis.comwithIn message body: subscribe snmpv3; Chair Russ Mundy at TIS Labs at Network Associates, postal3060 Washington Rd,Glenwood MD 21738,USA, EMailmundy@tis.com, phone+1 301-854-6889; Co-editor Dave Harrington at Cabletron Systems, Inc., postalPost Office Box 5005,Mail Stop: Durham,35 Industrial Way,Rochester, NH 03867-5005,USA, EMaildbh@ctron.com, phone+1 603-337-7357; Co-editor Randy Presuhn at BMC Software, Inc., postal965 Stewart Drive,Sunnyvale, CA 94086,USA, EMailrandy_presuhn@bmc.com, phone+1 408-616-3100; Co-editor: Bert Wijnen at IBM T.J. Watson Research, postalSchagen 33,3461 GL Linschoten,Netherlands, EMailwijnen@vnet.ibm.com, phone+31 348-432-794. DESCRIPTION "The SNMP Management Architecture MIB".REVISION "9901190000Z"— 19 January 1999 —DESCRIPTION "Updated editors' addresses, fixed typos."REVISION "9711200000Z"— 20 November 1997 —DESCRIPTION "The initial version, published in RFC 2271."- And the identity itself is
::= { snmpModules 10 }.
🦋 SnmpEngineID — the ID that is not an address
- It's a
TEXTUAL-CONVENTIONwithSTATUS current. - The description says it's 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'Hor the empty (zero length) string. - The initial value 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.
- 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.
- The
snmpEngineIDhas 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.
- 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
- The length of the octet strings varies.
- The first four octets are set to the binary equivalent of the agent's SNMP management private enterprise number as assigned by 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.127-255— as defined by the enterprise. Maximum remaining length 27.
- The first four octets are set to the binary equivalent of the agent's SNMP management private enterprise number as assigned by IANA. For example, if Acme Networks has been assigned
- The syntax is
OCTET STRING (SIZE(5..32)).
🔥 SnmpSecurityModel — the security model ID
- It's a
TEXTUAL-CONVENTIONwithSTATUS current. - It's an identifier that uniquely identifies a
securityModelof the Security Subsystem within the SNMP Management Architecture. - The values for
securityModelare allocated as follows:- The zero value is reserved.
- Values between
1and255, inclusive, are reserved for standards-track Security Models and are managed by the Internet Assigned Numbers Authority (IANA). - Values greater than
255are allocated to enterprise-specific Security Models. An enterprise-specificsecurityModelvalue is defined to beenterpriseID * 256 + security model within enterprise. For example, the fourth Security Model defined by the enterprise whoseenterpriseIDis1would be260.
- This scheme allows for a maximum of
255standards-based Security Models, and for a maximum of255Security Models per enterprise. - It is believed that the assignment of new
securityModelvalues 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 additional255possible values. - Note that the most significant bit must be zero; hence, there are
23bits allocated for various organizations to design and define non-standardsecurityModels. This limits the ability to define new proprietary implementations of Security Models to the first8,388,608enterprises. - It is worthwhile to note that, in its encoded form, the
securityModelvalue 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
securityModeldefined for use with SNMP or reserved for use with supporting MIB objects. They are as follows: the actual list is next, bestie — hold that thought 🫶.
and the list finishes with these exact values:
0 reserved for 'any'
1 reserved for SNMPv1
2 reserved for SNMPv2c
3 User-Based Security Model (USM)and the SYNTAX is INTEGER(0 .. 2147483647) — periodt.
✨ SnmpMessageProcessingModel ✨
SnmpMessageProcessingModel ::= TEXTUAL-CONVENTION with STATUS current and SYNTAX INTEGER(0 .. 2147483647). This one is an identifier that uniquely identifies a Message Processing Model of the Message Processing Subsystem within a SNMP Management Architecture.
The allocation rules are giving very precise, bestie:
- Values between
0and255, inclusive, are reserved for standards-track Message Processing Models and are managed by the Internet Assigned Numbers Authority (IANA). - Values greater than
255are allocated to enterprise-specific Message Processing Models. An enterprisemessageProcessingModelvalue is defined to be:
enterpriseID * 256 +
messageProcessingModel within enterpriseFor example, the fourth Message Processing Model defined by the enterprise whose enterpriseID is 1 would be 260.
This scheme means a maximum of 255 standards-based Message Processing Models, and a maximum of 255 Message Processing Models per enterprise.
The MIB authors are lowkey convinced new assignments will be rare in practice, because the more Message Processing Models running at once, the bigger the chance interoperability gets messy. They believe this range is sufficient. But in the unlikely event that the standards committee finds the number insufficient over time, an enterprise number can be allocated to obtain an additional 256 possible values.
Important vibe check: the most significant bit must be zero. That means there are23bits allocated for various organizations to design and define non-standardmessageProcessingModels. This limits the ability to define new proprietary implementations of Message Processing Models to the first8,388,608enterprises.
Also worth noting: 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:
0 reserved for SNMPv1
1 reserved for SNMPv2c
2 reserved for SNMPv2u and SNMPv2*
3 reserved for SNMPv3🔐 SnmpSecurityLevel 🔐
SnmpSecurityLevel ::= TEXTUAL-CONVENTION with STATUS current. It describes a Level of Security at which SNMP messages can be sent or with which operations are being processed. Specifically, 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 so that noAuthNoPriv is less than authNoPriv, and authNoPriv is less than authPriv. The syntax is exactly:
SYNTAX INTEGER { noAuthNoPriv(1),
authNoPriv(2),
authPriv(3erl)
}Yes, it says authPriv(3erl) — copying that exactly, no cap. 🫶
🌸 SnmpAdminString 🌸
SnmpAdminString ::= TEXTUAL-CONVENTION with DISPLAY-HINT "255a", STATUS current, and SYNTAX OCTET STRING (SIZE (0..255)). It’s an octet string containing administrative information, preferably in human-readable form.
The internationalization details are important, so let’s lay them out:
- 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
10646standard from time to time, implementations must be prepared to encounter any code point from0x00000000to0x7fffffff. 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 LFshould 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.
Index warning: when this TC is used for an object that is used or envisioned to be used as an index, then aSIZErestriction MUST be specified so that the number of sub-identifiers for any object instance does not exceed the limit of128, as defined by[RFC1905].
And one last note: the size of an SnmpAdminString object is measured in octets, not characters. Iconic, honestly.
🧾 Administrative assignments 🧾
The MIB sets up these OID assignments:
-- Administrative assignments ***************************************
snmpFrameworkAdmin
OBJECT IDENTIFIER ::= { snmpFrameworkMIB 1 }
snmpFrameworkMIBObjects
OBJECT IDENTIFIER ::= { snmpFrameworkMIB 2 }
snmpFrameworkMIBConformance
OBJECT IDENTIFIER ::= { snmpFrameworkMIB 3 }🚀 the snmpEngine Group 🚀
First, the group itself:
snmpEngine OBJECT IDENTIFIER ::= { snmpFrameworkMIBObjects 1 }Then the objects, in order:
snmpEngineID—OBJECT-TYPE,SYNTAX SnmpEngineID,MAX-ACCESS read-only,STATUS current,::= { snmpEngine 1 }. It’s an SNMP engine's administratively-unique identifier. Short, sweet, iconic.snmpEngineBoots—OBJECT-TYPE,SYNTAX INTEGER (1..2147483647),MAX-ACCESS read-only,STATUS current,::= { snmpEngine 2 }. It counts the number of times that the SNMP engine has (re-)initialized itself sincesnmpEngineIDwas last configured.snmpEngineTime—OBJECT-TYPE,SYNTAX INTEGER (0..2147483647),UNITS "seconds",MAX-ACCESS read-only,STATUS current,::= { snmpEngine 3 }. It’s the number of seconds since the value of thesnmpEngineBootsobject last changed. When incrementing this object's value would cause it to exceed its maximum,snmpEngineBootsis incremented as if a re-initialization had occurred, and this object's value consequently reverts to zero. Time math, but make it fashion. ⏰snmpEngineMaxMessageSize—OBJECT-TYPE,SYNTAX INTEGER (484..2147483647),MAX-ACCESS read-only,STATUS current,::= { snmpEngine 4 }. It’s 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.
🔐 Registration Points for Authentication and Privacy Protocols 🔐
-- Registration Points for Authentication and Privacy Protocols **snmpAuthProtocols—OBJECT-IDENTITY,STATUS current,::= { snmpFrameworkAdmin 1 }. It’s the registration point for standards-track authentication protocols used in SNMP Management Frameworks.snmpPrivProtocols—OBJECT-IDENTITY,STATUS current,::= { snmpFrameworkAdmin 2 }. It’s the registration point for standards-track privacy protocols used in SNMP Management Frameworks.
📋 Conformance information 📋
-- Conformance information ******************************************
snmpFrameworkMIBCompliances
OBJECT IDENTIFIER ::= {snmpFrameworkMIBConformance 1}
snmpFrameworkMIBGroups
OBJECT IDENTIFIER ::= {snmpFrameworkMIBConformance 2}and then the page hits us with:
-- compliance statementsthat’s the cliffhanger — compliance statements are next 💅
💖 MODULE-COMPLIANCE — the compliance statement era
okay so this is where the MIB gets official about who's allowed to claim they speak this module. It's the receipts section, bestie 👑
The definition is literally this:
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 }Breaking it down like we're decoding a group chat 🫶:
snmpFrameworkMIBCompliance— that's the name of this compliance statement, main character energy, no notes.MODULE-COMPLIANCE— the actual type of this thing. It's a compliance statement, not an object, not a table, not a trap. 💅STATUS current— status iscurrent. It's valid, it's live, it's that girl.DESCRIPTION— says it plain: "The compliance statement for SNMP engines which implement the SNMP Management Framework MIB." That's the whole vibe. If your SNMP engine implements this MIB, this is the statement it's signing off on ✍️MODULE -- this module— heads up, the compliance is defined against-- this module, like, the module we're literally inside right now. Self-referential queen.MANDATORY-GROUPS { snmpEngineGroup }— non-negotiable. If you're compliant, you must implementsnmpEngineGroup. Not optional, not "if you feel like it", it's mandatory mandatory. Periodt.::= { snmpFrameworkMIBCompliances 1 }— the OID assignment, dropping this definition atsnmpFrameworkMIBCompliances 1so the registry knows where to find it. iykyk.
🌸 OBJECT-GROUP — units of conformance
And here's the "units of conformance" part, which is basically the list of objects you're promising to have if you want in 👯♀️
-- 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 }So what's happening here 🧚:
snmpEngineGroup— the group's name, and yeah, it's the same one that wasMANDATORY-GROUPSup above. Connected. 💫OBJECT-GROUP— the type. This is a bundle of objects, packaged up together.OBJECTS— the actual roster, exactly four members, all iconic:snmpEngineIDsnmpEngineBootssnmpEngineTimesnmpEngineMaxMessageSize
That's the whole squad. All four, every time. No substituting, no "I brought a plus one instead" 🎀
STATUS current— againcurrent. Nothing deprecated here, we stan a valid group.DESCRIPTION— describes it as "A collection of objects for identifying and determining the configuration and current timeliness values of an SNMP engine." So the group covers identification, configuration, and the current timeliness values. That's the official wording, not me guessing 💅::= { snmpFrameworkMIBGroups 1 }— OID registration, sitting atsnmpFrameworkMIBGroups 1.
⚠️ gentle reminder bestie: the OBJECTS list is exactly those four. If you're writing docs or tooling off this page, don't add, don't merge, don't rename — copy them character for character fr fr.
✨ END
ENDThat's it — END. The module definition is closed, the curtain has dropped, the MIB has left the building 👑🌙
Literally the whole module, done and dusted.
and that's a wrap on the whole page, bestie!! 🦋 This absolute banger of a manual page comes to us from Erlang/OTP, and it lives in the SNMP section of the manual — filed under SNMP-FRAMEWORK-MIB(7) if you ever need to find it again 💖 go forth and implement your mandatory groups, you compliant little legend 🫶✨
📦 where this page comes from
- debian bookworm: erlang-manpages 1:25.2.3+dfsg-1+deb12u1 · Apache-2.0
- debian bookworm: erlang-manpages 1:25.2.3+dfsg-1+deb12u4 · Apache-2.0
- ubuntu jammy: erlang-manpages 1:24.2.1+dfsg-1 · Apache-2.0
- ubuntu jammy: erlang-manpages 1:24.2.1+dfsg-1ubuntu0.8 · Apache-2.0
- ubuntu noble: erlang-manpages 1:25.3.2.8+dfsg-1ubuntu4 · Apache-2.0
- ubuntu noble: erlang-manpages 1:25.3.2.8+dfsg-1ubuntu4.8 · Apache-2.0
- 💖 girlified by deepseek-ai/DeepSeek-V4.1-Flash-1017 on : a language model's rewrite of the original, under its terms