1
SNMP-FRAMEWORK-MIB DEFINITIONS ::= BEGIN
4
MODULE-IDENTITY, OBJECT-TYPE,
6
snmpModules FROM SNMPv2-SMI
7
TEXTUAL-CONVENTION FROM SNMPv2-TC
8
MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF;
10
snmpFrameworkMIB MODULE-IDENTITY
11
LAST-UPDATED "200210140000Z"
12
ORGANIZATION "SNMPv3 Working Group"
13
CONTACT-INFO "WG-EMail: snmpv3@lists.tislabs.com
14
Subscribe: snmpv3-request@lists.tislabs.com
17
Network Associates Laboratories
18
postal: 15204 Omega Drive, Suite 300
19
Rockville, MD 20850-4601
21
EMail: mundy@tislabs.com
22
phone: +1 301-947-7107
25
Co-editor: David Harrington
27
postal: 35 Industrial Way
29
Rochester, New Hampshire 03866-5005
31
EMail: dbh@enterasys.com
32
phone: +1 603-337-2614
34
Co-editor: Randy Presuhn
36
postal: 2141 North First Street
37
San Jose, California 95131
39
EMail: randy_presuhn@bmc.com
40
phone: +1 408-546-1006
42
Co-editor: Bert Wijnen
48
EMail: bwijnen@lucent.com
49
phone: +31 348-680-485
51
DESCRIPTION "The SNMP Management Architecture MIB
53
Copyright (C) The Internet Society (2002). This
54
version of this MIB module is part of RFC 3411;
55
see the RFC itself for full legal notices.
58
REVISION "200210140000Z" -- 14 October 2002
59
DESCRIPTION "Changes in this revision:
60
- Updated various administrative information.
61
- Corrected some typos.
62
- Corrected typo in description of SnmpEngineID
63
that led to range overlap for 127.
64
- Changed '255a' to '255t' in definition of
65
SnmpAdminString to align with current SMI.
66
- Reworded 'reserved' for value zero in
67
DESCRIPTION of SnmpSecurityModel.
68
- The algorithm for allocating security models
69
should give 256 per enterprise block, rather
71
- The example engine ID of 'abcd' is not
72
legal. Replaced with '800002b804616263'H based
73
on example enterprise 696, string 'abc'.
74
- Added clarification that engineID should
75
persist across re-initializations.
76
This revision published as RFC 3411.
78
REVISION "199901190000Z" -- 19 January 1999
79
DESCRIPTION "Updated editors' addresses, fixed typos.
80
Published as RFC 2571.
82
REVISION "199711200000Z" -- 20 November 1997
83
DESCRIPTION "The initial version, published in RFC 2271.
85
::= { snmpModules 10 }
87
-- Textual Conventions used in the SNMP Management Architecture ***
89
SnmpEngineID ::= TEXTUAL-CONVENTION
91
DESCRIPTION "An SNMP engine's administratively-unique identifier.
92
Objects of this type are for identification, not for
93
addressing, even though it is possible that an
94
address may have been used in the generation of
97
The value for this object may not be all zeros or
98
all 'ff'H or the empty (zero length) string.
100
The initial value for this object may be configured
101
via an operator console entry or via an algorithmic
102
function. In the latter case, the following
103
example algorithm is recommended.
105
In cases where there are multiple engines on the
106
same system, the use of this algorithm is NOT
107
appropriate, as it would result in all of those
108
engines ending up with the same ID value.
110
1) The very first bit is used to indicate how the
111
rest of the data is composed.
113
0 - as defined by enterprise using former methods
114
that existed before SNMPv3. See item 2 below.
116
1 - as defined by this architecture, see item 3
119
Note that this allows existing uses of the
120
engineID (also known as AgentID [RFC1910]) to
121
co-exist with any new uses.
123
2) The snmpEngineID has a length of 12 octets.
125
The first four octets are set to the binary
126
equivalent of the agent's SNMP management
127
private enterprise number as assigned by the
128
Internet Assigned Numbers Authority (IANA).
129
For example, if Acme Networks has been assigned
130
{ enterprises 696 }, the first four octets would
131
be assigned '000002b8'H.
133
The remaining eight octets are determined via
134
one or more enterprise-specific methods. Such
135
methods must be designed so as to maximize the
136
possibility that the value of this object will
137
be unique in the agent's administrative domain.
138
For example, it may be the IP address of the SNMP
139
entity, or the MAC address of one of the
140
interfaces, with each address suitably padded
141
with random octets. If multiple methods are
142
defined, then it is recommended that the first
143
octet indicate the method being used and the
144
remaining octets be a function of the method.
146
3) The length of the octet string varies.
148
The first four octets are set to the binary
149
equivalent of the agent's SNMP management
150
private enterprise number as assigned by the
151
Internet Assigned Numbers Authority (IANA).
152
For example, if Acme Networks has been assigned
153
{ enterprises 696 }, the first four octets would
154
be assigned '000002b8'H.
156
The very first bit is set to 1. For example, the
157
above value for Acme Networks now changes to be
160
The fifth octet indicates how the rest (6th and
161
following octets) are formatted. The values for
164
0 - reserved, unused.
166
1 - IPv4 address (4 octets)
167
lowest non-special IP address
169
2 - IPv6 address (16 octets)
170
lowest non-special IP address
172
3 - MAC address (6 octets)
173
lowest IEEE MAC address, canonical
176
4 - Text, administratively assigned
177
Maximum remaining length 27
179
5 - Octets, administratively assigned
180
Maximum remaining length 27
182
6-127 - reserved, unused
184
128-255 - as defined by the enterprise
185
Maximum remaining length 27
187
SYNTAX OCTET STRING (SIZE(5..32))
189
SnmpSecurityModel ::= TEXTUAL-CONVENTION
191
DESCRIPTION "An identifier that uniquely identifies a
192
Security Model of the Security Subsystem within
193
this SNMP Management Architecture.
195
The values for securityModel are allocated as
198
- The zero value does not identify any particular
201
- Values between 1 and 255, inclusive, are reserved
202
for standards-track Security Models and are
203
managed by the Internet Assigned Numbers Authority
205
- Values greater than 255 are allocated to
206
enterprise-specific Security Models. An
207
enterprise-specific securityModel value is defined
210
enterpriseID * 256 + security model within
213
For example, the fourth Security Model defined by
214
the enterprise whose enterpriseID is 1 would be
217
This scheme for allocation of securityModel
218
values allows for a maximum of 255 standards-
219
based Security Models, and for a maximum of
220
256 Security Models per enterprise.
222
It is believed that the assignment of new
223
securityModel values will be rare in practice
224
because the larger the number of simultaneously
225
utilized Security Models, the larger the
226
chance that interoperability will suffer.
227
Consequently, it is believed that such a range
228
will be sufficient. In the unlikely event that
229
the standards committee finds this number to be
230
insufficient over time, an enterprise number
231
can be allocated to obtain an additional 256
234
Note that the most significant bit must be zero;
235
hence, there are 23 bits allocated for various
236
organizations to design and define non-standard
238
securityModels. This limits the ability to
239
define new proprietary implementations of Security
240
Models to the first 8,388,608 enterprises.
242
It is worthwhile to note that, in its encoded
243
form, the securityModel value will normally
244
require only a single byte since, in practice,
245
the leftmost bits will be zero for most messages
246
and sign extension is suppressed by the encoding
249
As of this writing, there are several values
250
of securityModel defined for use with SNMP or
251
reserved for use with supporting MIB objects.
255
1 reserved for SNMPv1
256
2 reserved for SNMPv2c
257
3 User-Based Security Model (USM)
259
SYNTAX INTEGER(0 .. 2147483647)
261
SnmpMessageProcessingModel ::= TEXTUAL-CONVENTION
263
DESCRIPTION "An identifier that uniquely identifies a Message
264
Processing Model of the Message Processing
265
Subsystem within this SNMP Management Architecture.
267
The values for messageProcessingModel are
268
allocated as follows:
270
- Values between 0 and 255, inclusive, are
271
reserved for standards-track Message Processing
272
Models and are managed by the Internet Assigned
273
Numbers Authority (IANA).
275
- Values greater than 255 are allocated to
276
enterprise-specific Message Processing Models.
277
An enterprise messageProcessingModel value is
281
messageProcessingModel within enterprise
283
For example, the fourth Message Processing Model
284
defined by the enterprise whose enterpriseID
288
This scheme for allocating messageProcessingModel
289
values allows for a maximum of 255 standards-
290
based Message Processing Models, and for a
291
maximum of 256 Message Processing Models per
294
It is believed that the assignment of new
295
messageProcessingModel values will be rare
296
in practice because the larger the number of
297
simultaneously utilized Message Processing Models,
298
the larger the chance that interoperability
299
will suffer. It is believed that such a range
300
will be sufficient. In the unlikely event that
301
the standards committee finds this number to be
302
insufficient over time, an enterprise number
303
can be allocated to obtain an additional 256
306
Note that the most significant bit must be zero;
307
hence, there are 23 bits allocated for various
308
organizations to design and define non-standard
309
messageProcessingModels. This limits the ability
310
to define new proprietary implementations of
311
Message Processing Models to the first 8,388,608
314
It is worthwhile to note that, in its encoded
315
form, the messageProcessingModel value will
316
normally require only a single byte since, in
317
practice, the leftmost bits will be zero for
318
most messages and sign extension is suppressed
319
by the encoding rules.
321
As of this writing, there are several values of
322
messageProcessingModel defined for use with SNMP.
325
0 reserved for SNMPv1
326
1 reserved for SNMPv2c
327
2 reserved for SNMPv2u and SNMPv2*
328
3 reserved for SNMPv3
330
SYNTAX INTEGER(0 .. 2147483647)
332
SnmpSecurityLevel ::= TEXTUAL-CONVENTION
334
DESCRIPTION "A Level of Security at which SNMP messages can be
335
sent or with which operations are being processed;
336
in particular, one of:
338
noAuthNoPriv - without authentication and
340
authNoPriv - with authentication but
342
authPriv - with authentication and
345
These three values are ordered such that
346
noAuthNoPriv is less than authNoPriv and
347
authNoPriv is less than authPriv.
349
SYNTAX INTEGER { noAuthNoPriv(1),
354
SnmpAdminString ::= TEXTUAL-CONVENTION
357
DESCRIPTION "An octet string containing administrative
358
information, preferably in human-readable form.
360
To facilitate internationalization, this
361
information is represented using the ISO/IEC
362
IS 10646-1 character set, encoded as an octet
363
string using the UTF-8 transformation format
364
described in [RFC2279].
366
Since additional code points are added by
367
amendments to the 10646 standard from time
368
to time, implementations must be prepared to
369
encounter any code point from 0x00000000 to
370
0x7fffffff. Byte sequences that do not
371
correspond to the valid UTF-8 encoding of a
372
code point or are outside this range are
375
The use of control codes should be avoided.
377
When it is necessary to represent a newline,
378
the control code sequence CR LF should be used.
380
The use of leading or trailing white space should
383
For code points not directly supported by user
384
interface hardware or software, an alternative
385
means of entry and display, such as hexadecimal,
388
For information encoded in 7-bit US-ASCII,
389
the UTF-8 encoding is identical to the
392
UTF-8 may require multiple bytes to represent a
393
single character / code point; thus the length
394
of this object in octets may be different from
395
the number of characters encoded. Similarly,
396
size constraints refer to the number of encoded
397
octets, not the number of characters represented
400
Note that when this TC is used for an object that
401
is used or envisioned to be used as an index, then
402
a SIZE restriction MUST be specified so that the
403
number of sub-identifiers for any object instance
404
does not exceed the limit of 128, as defined by
407
Note that the size of an SnmpAdminString object is
408
measured in octets, not characters.
410
SYNTAX OCTET STRING (SIZE (0..255))
414
OBJECT IDENTIFIER ::= { snmpFrameworkMIB 1 }
415
snmpFrameworkMIBObjects
416
OBJECT IDENTIFIER ::= { snmpFrameworkMIB 2 }
417
snmpFrameworkMIBConformance
418
OBJECT IDENTIFIER ::= { snmpFrameworkMIB 3 }
421
snmpEngine OBJECT IDENTIFIER ::= { snmpFrameworkMIBObjects 1 }
423
snmpEngineID OBJECT-TYPE
427
DESCRIPTION "An SNMP engine's administratively-unique identifier.
429
This information SHOULD be stored in non-volatile
430
storage so that it remains constant across
431
re-initializations of the SNMP engine.
435
snmpEngineBoots OBJECT-TYPE
436
SYNTAX INTEGER (1..2147483647)
439
DESCRIPTION "The number of times that the SNMP engine has
440
(re-)initialized itself since snmpEngineID
445
snmpEngineTime OBJECT-TYPE
446
SYNTAX INTEGER (0..2147483647)
450
DESCRIPTION "The number of seconds since the value of
451
the snmpEngineBoots object last changed.
452
When incrementing this object's value would
453
cause it to exceed its maximum,
454
snmpEngineBoots is incremented as if a
455
re-initialization had occurred, and this
456
object's value consequently reverts to zero.
460
snmpEngineMaxMessageSize OBJECT-TYPE
461
SYNTAX INTEGER (484..2147483647)
464
DESCRIPTION "The maximum length in octets of an SNMP message
465
which this SNMP engine can send or receive and
466
process, determined as the minimum of the maximum
467
message size values supported among all of the
468
transports available to and supported by the engine.
473
snmpAuthProtocols OBJECT-IDENTITY
475
DESCRIPTION "Registration point for standards-track
476
authentication protocols used in SNMP Management
479
::= { snmpFrameworkAdmin 1 }
481
snmpPrivProtocols OBJECT-IDENTITY
483
DESCRIPTION "Registration point for standards-track privacy
484
protocols used in SNMP Management Frameworks.
486
::= { snmpFrameworkAdmin 2 }
489
snmpFrameworkMIBCompliances
490
OBJECT IDENTIFIER ::= {snmpFrameworkMIBConformance 1}
491
snmpFrameworkMIBGroups
492
OBJECT IDENTIFIER ::= {snmpFrameworkMIBConformance 2}
495
snmpFrameworkMIBCompliance MODULE-COMPLIANCE
497
DESCRIPTION "The compliance statement for SNMP engines which
498
implement the SNMP Management Framework MIB.
500
MODULE -- this module
501
MANDATORY-GROUPS { snmpEngineGroup }
502
::= { snmpFrameworkMIBCompliances 1 }
505
snmpEngineGroup OBJECT-GROUP
510
snmpEngineMaxMessageSize
513
DESCRIPTION "A collection of objects for identifying and
514
determining the configuration and current timeliness
516
values of an SNMP engine.
518
::= { snmpFrameworkMIBGroups 1 }
added
removed
mibs/SNMP-FRAMEWORK-MIB.txt
