1SNMP-FRAMEWORK-MIB DEFINITIONS ::= BEGIN 2 3IMPORTS 4 MODULE-IDENTITY, OBJECT-TYPE, 5 OBJECT-IDENTITY, 6 snmpModules FROM SNMPv2-SMI 7 TEXTUAL-CONVENTION FROM SNMPv2-TC 8 MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF; 9 10snmpFrameworkMIB 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 15 16 Co-Chair: Russ Mundy 17 Network Associates Laboratories 18 postal: 15204 Omega Drive, Suite 300 19 Rockville, MD 20850-4601 20 USA 21 EMail: mundy@tislabs.com 22 phone: +1 301-947-7107 23 24 Co-Chair & 25 Co-editor: David Harrington 26 Enterasys Networks 27 postal: 35 Industrial Way 28 P. O. Box 5005 29 Rochester, New Hampshire 03866-5005 30 USA 31 EMail: dbh@enterasys.com 32 phone: +1 603-337-2614 33 34 Co-editor: Randy Presuhn 35 BMC Software, Inc. 36 postal: 2141 North First Street 37 San Jose, California 95131 38 USA 39 EMail: randy_presuhn@bmc.com 40 phone: +1 408-546-1006 41 42 Co-editor: Bert Wijnen 43 Lucent Technologies 44 postal: Schagen 33 45 3461 GL Linschoten 46 Netherlands 47 48 EMail: bwijnen@lucent.com 49 phone: +31 348-680-485 50 " 51 DESCRIPTION "The SNMP Management Architecture MIB 52 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. 56 " 57 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 70 than 255. 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. 77 " 78 REVISION "199901190000Z" -- 19 January 1999 79 DESCRIPTION "Updated editors' addresses, fixed typos. 80 Published as RFC 2571. 81 " 82 REVISION "199711200000Z" -- 20 November 1997 83 DESCRIPTION "The initial version, published in RFC 2271. 84 " 85 ::= { snmpModules 10 } 86 87 -- Textual Conventions used in the SNMP Management Architecture *** 88 89SnmpEngineID ::= TEXTUAL-CONVENTION 90 STATUS current 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 95 a specific value. 96 97 The value for this object may not be all zeros or 98 all 'ff'H or the empty (zero length) string. 99 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. 104 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. 109 110 1) The very first bit is used to indicate how the 111 rest of the data is composed. 112 113 0 - as defined by enterprise using former methods 114 that existed before SNMPv3. See item 2 below. 115 116 1 - as defined by this architecture, see item 3 117 below. 118 119 Note that this allows existing uses of the 120 engineID (also known as AgentID [RFC1910]) to 121 co-exist with any new uses. 122 123 2) The snmpEngineID has a length of 12 octets. 124 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. 132 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. 145 146 3) The length of the octet string varies. 147 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. 155 156 The very first bit is set to 1. For example, the 157 above value for Acme Networks now changes to be 158 '800002b8'H. 159 160 The fifth octet indicates how the rest (6th and 161 following octets) are formatted. The values for 162 the fifth octet are: 163 164 0 - reserved, unused. 165 166 1 - IPv4 address (4 octets) 167 lowest non-special IP address 168 169 2 - IPv6 address (16 octets) 170 lowest non-special IP address 171 172 3 - MAC address (6 octets) 173 lowest IEEE MAC address, canonical 174 order 175 176 4 - Text, administratively assigned 177 Maximum remaining length 27 178 179 5 - Octets, administratively assigned 180 Maximum remaining length 27 181 182 6-127 - reserved, unused 183 184 128-255 - as defined by the enterprise 185 Maximum remaining length 27 186 " 187 SYNTAX OCTET STRING (SIZE(5..32)) 188 189SnmpSecurityModel ::= TEXTUAL-CONVENTION 190 STATUS current 191 DESCRIPTION "An identifier that uniquely identifies a 192 Security Model of the Security Subsystem within 193 this SNMP Management Architecture. 194 195 The values for securityModel are allocated as 196 follows: 197 198 - The zero value does not identify any particular 199 security model. 200 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 204 (IANA). 205 - Values greater than 255 are allocated to 206 enterprise-specific Security Models. An 207 enterprise-specific securityModel value is defined 208 to be: 209 210 enterpriseID * 256 + security model within 211 enterprise 212 213 For example, the fourth Security Model defined by 214 the enterprise whose enterpriseID is 1 would be 215 259. 216 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. 221 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 232 possible values. 233 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 237 238 securityModels. This limits the ability to 239 define new proprietary implementations of Security 240 Models to the first 8,388,608 enterprises. 241 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 247 rules. 248 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. 252 They are as follows: 253 254 0 reserved for 'any' 255 1 reserved for SNMPv1 256 2 reserved for SNMPv2c 257 3 User-Based Security Model (USM) 258 " 259 SYNTAX INTEGER(0 .. 2147483647) 260 261SnmpMessageProcessingModel ::= TEXTUAL-CONVENTION 262 STATUS current 263 DESCRIPTION "An identifier that uniquely identifies a Message 264 Processing Model of the Message Processing 265 Subsystem within this SNMP Management Architecture. 266 267 The values for messageProcessingModel are 268 allocated as follows: 269 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). 274 275 - Values greater than 255 are allocated to 276 enterprise-specific Message Processing Models. 277 An enterprise messageProcessingModel value is 278 defined to be: 279 280 enterpriseID * 256 + 281 messageProcessingModel within enterprise 282 283 For example, the fourth Message Processing Model 284 defined by the enterprise whose enterpriseID 285 286 is 1 would be 259. 287 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 292 enterprise. 293 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 304 possible values. 305 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 312 enterprises. 313 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. 320 321 As of this writing, there are several values of 322 messageProcessingModel defined for use with SNMP. 323 They are as follows: 324 325 0 reserved for SNMPv1 326 1 reserved for SNMPv2c 327 2 reserved for SNMPv2u and SNMPv2* 328 3 reserved for SNMPv3 329 " 330 SYNTAX INTEGER(0 .. 2147483647) 331 332SnmpSecurityLevel ::= TEXTUAL-CONVENTION 333 STATUS current 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: 337 338 noAuthNoPriv - without authentication and 339 without privacy, 340 authNoPriv - with authentication but 341 without privacy, 342 authPriv - with authentication and 343 with privacy. 344 345 These three values are ordered such that 346 noAuthNoPriv is less than authNoPriv and 347 authNoPriv is less than authPriv. 348 " 349 SYNTAX INTEGER { noAuthNoPriv(1), 350 authNoPriv(2), 351 authPriv(3) 352 } 353 354SnmpAdminString ::= TEXTUAL-CONVENTION 355 DISPLAY-HINT "255t" 356 STATUS current 357 DESCRIPTION "An octet string containing administrative 358 information, preferably in human-readable form. 359 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]. 365 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 373 prohibited. 374 375 The use of control codes should be avoided. 376 377 When it is necessary to represent a newline, 378 the control code sequence CR LF should be used. 379 380 The use of leading or trailing white space should 381 be avoided. 382 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, 386 may be provided. 387 388 For information encoded in 7-bit US-ASCII, 389 the UTF-8 encoding is identical to the 390 US-ASCII encoding. 391 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 398 by an encoding. 399 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 405 [RFC3416]. 406 407 Note that the size of an SnmpAdminString object is 408 measured in octets, not characters. 409 " 410 SYNTAX OCTET STRING (SIZE (0..255)) 411 412-- Administrative assignments *************************************** 413 414snmpFrameworkAdmin 415 OBJECT IDENTIFIER ::= { snmpFrameworkMIB 1 } 416snmpFrameworkMIBObjects 417 OBJECT IDENTIFIER ::= { snmpFrameworkMIB 2 } 418snmpFrameworkMIBConformance 419 OBJECT IDENTIFIER ::= { snmpFrameworkMIB 3 } 420 421-- the snmpEngine Group ******************************************** 422 423snmpEngine OBJECT IDENTIFIER ::= { snmpFrameworkMIBObjects 1 } 424 425snmpEngineID OBJECT-TYPE 426 SYNTAX SnmpEngineID 427 MAX-ACCESS read-only 428 STATUS current 429 DESCRIPTION "An SNMP engine's administratively-unique identifier. 430 431 This information SHOULD be stored in non-volatile 432 storage so that it remains constant across 433 re-initializations of the SNMP engine. 434 " 435 ::= { snmpEngine 1 } 436 437snmpEngineBoots OBJECT-TYPE 438 SYNTAX INTEGER (1..2147483647) 439 MAX-ACCESS read-only 440 STATUS current 441 DESCRIPTION "The number of times that the SNMP engine has 442 (re-)initialized itself since snmpEngineID 443 was last configured. 444 " 445 ::= { snmpEngine 2 } 446 447snmpEngineTime OBJECT-TYPE 448 SYNTAX INTEGER (0..2147483647) 449 UNITS "seconds" 450 MAX-ACCESS read-only 451 STATUS current 452 DESCRIPTION "The number of seconds since the value of 453 the snmpEngineBoots object last changed. 454 When incrementing this object's value would 455 cause it to exceed its maximum, 456 snmpEngineBoots is incremented as if a 457 re-initialization had occurred, and this 458 object's value consequently reverts to zero. 459 " 460 ::= { snmpEngine 3 } 461 462snmpEngineMaxMessageSize OBJECT-TYPE 463 SYNTAX INTEGER (484..2147483647) 464 MAX-ACCESS read-only 465 STATUS current 466 DESCRIPTION "The maximum length in octets of an SNMP message 467 which this SNMP engine can send or receive and 468 process, determined as the minimum of the maximum 469 message size values supported among all of the 470 transports available to and supported by the engine. 471 " 472 ::= { snmpEngine 4 } 473 474-- Registration Points for Authentication and Privacy Protocols ** 475 476snmpAuthProtocols OBJECT-IDENTITY 477 STATUS current 478 DESCRIPTION "Registration point for standards-track 479 authentication protocols used in SNMP Management 480 Frameworks. 481 " 482 ::= { snmpFrameworkAdmin 1 } 483 484snmpPrivProtocols OBJECT-IDENTITY 485 STATUS current 486 DESCRIPTION "Registration point for standards-track privacy 487 protocols used in SNMP Management Frameworks. 488 " 489 ::= { snmpFrameworkAdmin 2 } 490 491-- Conformance information ****************************************** 492 493snmpFrameworkMIBCompliances 494 OBJECT IDENTIFIER ::= {snmpFrameworkMIBConformance 1} 495snmpFrameworkMIBGroups 496 OBJECT IDENTIFIER ::= {snmpFrameworkMIBConformance 2} 497 498-- compliance statements 499 500snmpFrameworkMIBCompliance MODULE-COMPLIANCE 501 STATUS current 502 DESCRIPTION "The compliance statement for SNMP engines which 503 implement the SNMP Management Framework MIB. 504 " 505 MODULE -- this module 506 MANDATORY-GROUPS { snmpEngineGroup } 507 ::= { snmpFrameworkMIBCompliances 1 } 508 509-- units of conformance 510 511snmpEngineGroup OBJECT-GROUP 512 OBJECTS { 513 snmpEngineID, 514 snmpEngineBoots, 515 snmpEngineTime, 516 snmpEngineMaxMessageSize 517 } 518 STATUS current 519 DESCRIPTION "A collection of objects for identifying and 520 determining the configuration and current timeliness 521 522 values of an SNMP engine. 523 " 524 ::= { snmpFrameworkMIBGroups 1 } 525 526END 527