aboutsummaryrefslogtreecommitdiffstats
path: root/lib/snmp/mibs/SNMP-FRAMEWORK-MIB.mib
diff options
context:
space:
mode:
Diffstat (limited to 'lib/snmp/mibs/SNMP-FRAMEWORK-MIB.mib')
-rw-r--r--lib/snmp/mibs/SNMP-FRAMEWORK-MIB.mib493
1 files changed, 493 insertions, 0 deletions
diff --git a/lib/snmp/mibs/SNMP-FRAMEWORK-MIB.mib b/lib/snmp/mibs/SNMP-FRAMEWORK-MIB.mib
new file mode 100644
index 0000000000..a3fa40cf0e
--- /dev/null
+++ b/lib/snmp/mibs/SNMP-FRAMEWORK-MIB.mib
@@ -0,0 +1,493 @@
+ 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: [email protected]
+ Subscribe: [email protected]
+ In message body: subscribe snmpv3
+
+ Chair: Russ Mundy
+ TIS Labs at Network Associates
+ postal: 3060 Washington Rd
+ Glenwood MD 21738
+ USA
+ EMail: [email protected]
+ 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: [email protected]
+ phone: +1 603-337-7357
+
+ Co-editor Randy Presuhn
+ BMC Software, Inc.
+ postal: 965 Stewart Drive
+ Sunnyvale, CA 94086
+ USA
+ EMail: [email protected]
+ phone: +1 408-616-3100
+
+ Co-editor: Bert Wijnen
+ IBM T.J. Watson Research
+ postal: Schagen 33
+ 3461 GL Linschoten
+ Netherlands
+ EMail: [email protected]
+ 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:
+
+ 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 a 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 260.
+
+ This scheme for allocating messageProcessingModel
+ values allows for a maximum of 255 standards-
+ based Message Processing Models, and for a
+ maximum of 255 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 "255a"
+ 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
+ [RFC1905].
+
+ 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.
+ "
+ ::= { 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
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-25 08:36:35 +0000