1SNMP-FRAMEWORK-MIB(7) MIB SNMP-FRAMEWORK-MIB(7)
2 SNMP-FRAMEWORK-MIB DEFINITIONS ::= BEGIN
6 IMPORTS
8 MODULE-IDENTITY, OBJECT-TYPE,
9 OBJECT-IDENTITY,
10 snmpModules FROM SNMPv2-SMI
11 TEXTUAL-CONVENTION FROM SNMPv2-TC
12 MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF;
13 snmpFrameworkMIB MODULE-IDENTITY
15 LAST-UPDATED "9901190000Z" -- 19 January 1999
16 ORGANIZATION "SNMPv3 Working Group"
17 CONTACT-INFO "WG-EMail: snmpv3@tis.com
18 Subscribe: majordomo@tis.com
19 In message body: subscribe snmpv3
20 Chair: Russ Mundy
22 TIS Labs at Network Associates
23 postal: 3060 Washington Rd
24 Glenwood MD 21738
25 USA
26 EMail: mundy@tis.com
27 phone: +1 301-854-6889
28 Co-editor Dave Harrington
30 Cabletron Systems, Inc.
31 postal: Post Office Box 5005
32 Mail Stop: Durham
33 35 Industrial Way
34 Rochester, NH 03867-5005
35 USA
36 EMail: dbh@ctron.com
37 phone: +1 603-337-7357
38 Co-editor Randy Presuhn
40 BMC Software, Inc.
41 postal: 965 Stewart Drive
42 Sunnyvale, CA 94086
43 USA
44 EMail: randy_presuhn@bmc.com
45 phone: +1 408-616-3100
46 Co-editor: Bert Wijnen
48 IBM T.J. Watson Research
49 postal: Schagen 33
50 3461 GL Linschoten
51 Netherlands
52 EMail: wijnen@vnet.ibm.com
53 phone: +31 348-432-794
54 "
55 DESCRIPTION "The SNMP Management Architecture MIB"
56 REVISION "9901190000Z" -- 19 January 1999
57 DESCRIPTION "Updated editors' addresses, fixed typos.
58 "
59 REVISION "9711200000Z" -- 20 November 1997
60 DESCRIPTION "The initial version, published in RFC 2271.
61 "
62 ::= { snmpModules 10 }
63 -- Textual Conventions used in the SNMP Management Architecture ***
65 SnmpEngineID ::= TEXTUAL-CONVENTION
67 STATUS current
68 DESCRIPTION "An SNMP engine's administratively-unique identifier.
69 Objects of this type are for identification, not for
70 addressing, even though it is possible that an
71 address may have been used in the generation of
72 a specific value.
73 The value for this object may not be all zeros or
75 all 'ff'H or the empty (zero length) string.
76 The initial value for this object may be configured
78 via an operator console entry or via an algorithmic
79 function. In the latter case, the following
80 example algorithm is recommended.
81 In cases where there are multiple engines on the
83 same system, the use of this algorithm is NOT
84 appropriate, as it would result in all of those
85 engines ending up with the same ID value.
86 1) The very first bit is used to indicate how the
88 rest of the data is composed.
89 0 - as defined by enterprise using former methods
91 that existed before SNMPv3. See item 2 below.
92 1 - as defined by this architecture, see item 3
94 below.
95 Note that this allows existing uses of the
97 engineID (also known as AgentID [RFC1910]) to
98 co-exist with any new uses.
99 2) The snmpEngineID has a length of 12 octets.
101 The first four octets are set to the binary
103 equivalent of the agent's SNMP management
104 private enterprise number as assigned by the
105 Internet Assigned Numbers Authority (IANA).
106 For example, if Acme Networks has been assigned
107 { enterprises 696 }, the first four octets would
108 be assigned '000002b8'H.
109 The remaining eight octets are determined via
111 one or more enterprise-specific methods. Such
112 methods must be designed so as to maximize the
113 possibility that the value of this object will
114 be unique in the agent's administrative domain.
115 For example, it may be the IP address of the SNMP
116 entity, or the MAC address of one of the
117 interfaces, with each address suitably padded
118 with random octets. If multiple methods are
119 defined, then it is recommended that the first
120 octet indicate the method being used and the
121 remaining octets be a function of the method.
122 3) The length of the octet strings varies.
124 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.
132 The very first bit is set to 1. For example, the
134 above value for Acme Networks now changes to be
135 '800002b8'H.
136 The fifth octet indicates how the rest (6th and
138 following octets) are formatted. The values for
139 the fifth octet are:
140 0 - reserved, unused.
142 1 - IPv4 address (4 octets)
144 lowest non-special IP address
145 2 - IPv6 address (16 octets)
147 lowest non-special IP address
148 3 - MAC address (6 octets)
150 lowest IEEE MAC address, canonical
151 order
152 4 - Text, administratively assigned
154 Maximum remaining length 27
155 5 - Octets, administratively assigned
157 Maximum remaining length 27
158 6-127 - reserved, unused
160 127-255 - as defined by the enterprise
162 Maximum remaining length 27
163 "
164 SYNTAX OCTET STRING (SIZE(5..32))
165 SnmpSecurityModel ::= TEXTUAL-CONVENTION
167 STATUS current
168 DESCRIPTION "An identifier that uniquely identifies a
169 securityModel of the Security Subsystem within the
170 SNMP Management Architecture.
171 The values for securityModel are allocated as
173 follows:
174 - The zero value is reserved.
176 - Values between 1 and 255, inclusive, are reserved
177 for standards-track Security Models and are
178 managed by the Internet Assigned Numbers Authority
179 (IANA).
180 - Values greater than 255 are allocated to
181 enterprise-specific Security Models. An
182 enterprise-specific securityModel value is defined
183 to be:
184 enterpriseID * 256 + security model within
186 enterprise
187 For example, the fourth Security Model defined by
189 the enterprise whose enterpriseID is 1 would be
190 260.
191 This scheme for allocation of securityModel
193 values allows for a maximum of 255 standards-
194 based Security Models, and for a maximum of
195 255 Security Models per enterprise.
196 It is believed that the assignment of new
198 securityModel values will be rare in practice
199 because the larger the number of simultaneously
200 utilized Security Models, the larger the
201 chance that interoperability will suffer.
202 Consequently, it is believed that such a range
203 will be sufficient. In the unlikely event that
204 the standards committee finds this number to be
205 insufficient over time, an enterprise number
206 can be allocated to obtain an additional 255
207 possible values.
208 Note that the most significant bit must be zero;
210 hence, there are 23 bits allocated for various
211 organizations to design and define non-standard
212 securityModels. This limits the ability to
213 define new proprietary implementations of Security
214 Models to the first 8,388,608 enterprises.
215 It is worthwhile to note that, in its encoded
217 form, the securityModel value will normally
218 require only a single byte since, in practice,
219 the leftmost bits will be zero for most messages
220 and sign extension is suppressed by the encoding
221 rules.
222 As of this writing, there are several values
224 of securityModel defined for use with SNMP or
225 reserved for use with supporting MIB objects.
226 They are as follows:
227 0 reserved for 'any'
229 1 reserved for SNMPv1
230 2 reserved for SNMPv2c
231 3 User-Based Security Model (USM)
232 "
233 SYNTAX INTEGER(0 .. 2147483647)
234 SnmpMessageProcessingModel ::= TEXTUAL-CONVENTION
236 STATUS current
237 DESCRIPTION "An identifier that uniquely identifies a Message
238 Processing Model of the Message Processing
239 Subsystem within a SNMP Management Architecture.
240 The values for messageProcessingModel are
242 allocated as follows:
243 - Values between 0 and 255, inclusive, are
245 reserved for standards-track Message Processing
246 Models and are managed by the Internet Assigned
247 Numbers Authority (IANA).
248 - Values greater than 255 are allocated to
250 enterprise-specific Message Processing Models.
251 An enterprise messageProcessingModel value is
252 defined to be:
253 enterpriseID * 256 +
255 messageProcessingModel within enterprise
256 For example, the fourth Message Processing Model
258 defined by the enterprise whose enterpriseID
259 is 1 would be 260.
260 This scheme for allocating messageProcessingModel
262 values allows for a maximum of 255 standards-
263 based Message Processing Models, and for a
264 maximum of 255 Message Processing Models per
265 enterprise.
266 It is believed that the assignment of new
268 messageProcessingModel values will be rare
269 in practice because the larger the number of
270 simultaneously utilized Message Processing Models,
271 the larger the chance that interoperability
272 will suffer. It is believed that such a range
273 will be sufficient. In the unlikely event that
274 the standards committee finds this number to be
275 insufficient over time, an enterprise number
276 can be allocated to obtain an additional 256
277 possible values.
278 Note that the most significant bit must be zero;
280 hence, there are 23 bits allocated for various
281 organizations to design and define non-standard
282 messageProcessingModels. This limits the ability
283 to define new proprietary implementations of
284 Message Processing Models to the first 8,388,608
285 enterprises.
286 It is worthwhile to note that, in its encoded
288 form, the messageProcessingModel value will
289 normally require only a single byte since, in
290 practice, the leftmost bits will be zero for
291 most messages and sign extension is suppressed
292 by the encoding rules.
293 As of this writing, there are several values of
295 messageProcessingModel defined for use with SNMP.
296 They are as follows:
297 0 reserved for SNMPv1
299 1 reserved for SNMPv2c
300 2 reserved for SNMPv2u and SNMPv2*
301 3 reserved for SNMPv3
302 "
303 SYNTAX INTEGER(0 .. 2147483647)
304 SnmpSecurityLevel ::= TEXTUAL-CONVENTION
306 STATUS current
307 DESCRIPTION "A Level of Security at which SNMP messages can be
308 sent or with which operations are being processed;
309 in particular, one of:
310 noAuthNoPriv - without authentication and
312 without privacy,
313 authNoPriv - with authentication but
314 without privacy,
315 authPriv - with authentication and
316 with privacy.
317 These three values are ordered such that
319 noAuthNoPriv is less than authNoPriv and
320 authNoPriv is less than authPriv.
321 "
322 SYNTAX INTEGER { noAuthNoPriv(1),
323 authNoPriv(2),
324 authPriv(3)
325 }
326 SnmpAdminString ::= TEXTUAL-CONVENTION
328 DISPLAY-HINT "255a"
329 STATUS current
330 DESCRIPTION "An octet string containing administrative
331 information, preferably in human-readable form.
332 To facilitate internationalization, this
334 information is represented using the ISO/IEC
335 IS 10646-1 character set, encoded as an octet
336 string using the UTF-8 transformation format
337 described in [RFC2279].
338 Since additional code points are added by
340 amendments to the 10646 standard from time
341 to time, implementations must be prepared to
342 encounter any code point from 0x00000000 to
343 0x7fffffff. Byte sequences that do not
344 correspond to the valid UTF-8 encoding of a
345 code point or are outside this range are
346 prohibited.
347 The use of control codes should be avoided.
349 When it is necessary to represent a newline,
351 the control code sequence CR LF should be used.
352 The use of leading or trailing white space should
354 be avoided.
355 For code points not directly supported by user
357 interface hardware or software, an alternative
358 means of entry and display, such as hexadecimal,
359 may be provided.
360 For information encoded in 7-bit US-ASCII,
362 the UTF-8 encoding is identical to the
363 US-ASCII encoding.
364 UTF-8 may require multiple bytes to represent a
366 single character / code point; thus the length
367 of this object in octets may be different from
368 the number of characters encoded. Similarly,
369 size constraints refer to the number of encoded
370 octets, not the number of characters represented
371 by an encoding.
372 Note that when this TC is used for an object that
374 is used or envisioned to be used as an index, then
375 a SIZE restriction MUST be specified so that the
376 number of sub-identifiers for any object instance
377 does not exceed the limit of 128, as defined by
378 [RFC1905].
379 Note that the size of an SnmpAdminString object is
381 measured in octets, not characters.
382 "
383 SYNTAX OCTET STRING (SIZE (0..255))
384 -- Administrative assignments ***************************************
387 snmpFrameworkAdmin
389 OBJECT IDENTIFIER ::= { snmpFrameworkMIB 1 }
390 snmpFrameworkMIBObjects
391 OBJECT IDENTIFIER ::= { snmpFrameworkMIB 2 }
392 snmpFrameworkMIBConformance
393 OBJECT IDENTIFIER ::= { snmpFrameworkMIB 3 }
394 -- the snmpEngine Group ********************************************
396 snmpEngine OBJECT IDENTIFIER ::= { snmpFrameworkMIBObjects 1 }
398 snmpEngineID OBJECT-TYPE
400 SYNTAX SnmpEngineID
401 MAX-ACCESS read-only
402 STATUS current
403 DESCRIPTION "An SNMP engine's administratively-unique identifier.
404 "
405 ::= { snmpEngine 1 }
406 snmpEngineBoots OBJECT-TYPE
408 SYNTAX INTEGER (1..2147483647)
409 MAX-ACCESS read-only
410 STATUS current
411 DESCRIPTION "The number of times that the SNMP engine has
412 (re-)initialized itself since snmpEngineID
413 was last configured.
414 "
415 ::= { snmpEngine 2 }
416 snmpEngineTime OBJECT-TYPE
418 SYNTAX INTEGER (0..2147483647)
419 UNITS "seconds"
420 MAX-ACCESS read-only
421 STATUS current
422 DESCRIPTION "The number of seconds since the value of
423 the snmpEngineBoots object last changed.
424 When incrementing this object's value would
425 cause it to exceed its maximum,
426 snmpEngineBoots is incremented as if a
427 re-initialization had occurred, and this
428 object's value consequently reverts to zero.
429 "
430 ::= { snmpEngine 3 }
431 snmpEngineMaxMessageSize OBJECT-TYPE
433 SYNTAX INTEGER (484..2147483647)
434 MAX-ACCESS read-only
435 STATUS current
436 DESCRIPTION "The maximum length in octets of an SNMP message
437 which this SNMP engine can send or receive and
438 process, determined as the minimum of the maximum
439 message size values supported among all of the
440 transports available to and supported by the engine.
441 "
442 ::= { snmpEngine 4 }
443 -- Registration Points for Authentication and Privacy Protocols **
446 snmpAuthProtocols OBJECT-IDENTITY
448 STATUS current
449 DESCRIPTION "Registration point for standards-track
450 authentication protocols used in SNMP Management
451 Frameworks.
452 "
453 ::= { snmpFrameworkAdmin 1 }
454 snmpPrivProtocols OBJECT-IDENTITY
456 STATUS current
457 DESCRIPTION "Registration point for standards-track privacy
458 protocols used in SNMP Management Frameworks.
459 "
460 ::= { snmpFrameworkAdmin 2 }
461 -- Conformance information ******************************************
463 snmpFrameworkMIBCompliances
465 OBJECT IDENTIFIER ::= {snmpFrameworkMIBConformance 1}
466 snmpFrameworkMIBGroups
467 OBJECT IDENTIFIER ::= {snmpFrameworkMIBConformance 2}
468 -- compliance statements
470 snmpFrameworkMIBCompliance MODULE-COMPLIANCE
472 STATUS current
473 DESCRIPTION "The compliance statement for SNMP engines which
474 implement the SNMP Management Framework MIB.
475 "
476 MODULE -- this module
477 MANDATORY-GROUPS { snmpEngineGroup }
478 ::= { snmpFrameworkMIBCompliances 1 }
480 -- units of conformance
482 snmpEngineGroup OBJECT-GROUP
484 OBJECTS {
485 snmpEngineID,
486 snmpEngineBoots,
487 snmpEngineTime,
488 snmpEngineMaxMessageSize
489 }
490 STATUS current
491 DESCRIPTION "A collection of objects for identifying and
492 determining the configuration and current timeliness
493 values of an SNMP engine.
494 "
495 ::= { snmpFrameworkMIBGroups 1 }
496 END
498Erlang/OTP SNMP SNMP-FRAMEWORK-MIB(7)