527 lines
22 KiB
Plaintext
527 lines
22 KiB
Plaintext
|
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
|