smilint output for ./SNMP-FRAMEWORK-MIB

Messages:

SNMP-FRAMEWORK-MIB

   1: -- extracted from rfc3411.txt
   2: -- at Mon Dec 23 06:11:31 2002

  91: 
  92: SnmpEngineID ::= TEXTUAL-CONVENTION

  93:     STATUS       current
  94:     DESCRIPTION "An SNMP engine's administratively-unique identifier.
  95:                  Objects of this type are for identification, not for
  96:                  addressing, even though it is possible that an
  97:                  address may have been used in the generation of
  98:                  a specific value.
  99:                  The value for this object may not be all zeros or
 100:                  all 'ff'H or the empty (zero length) string.
 101: 
 102:                  The initial value for this object may be configured
 103:                  via an operator console entry or via an algorithmic
 104:                  function.  In the latter case, the following
 105:                  example algorithm is recommended.
 106: 
 107:                  In cases where there are multiple engines on the
 108:                  same system, the use of this algorithm is NOT
 109:                  appropriate, as it would result in all of those
 110:                  engines ending up with the same ID value.
 111: 
 112:                  1) The very first bit is used to indicate how the
 113:                     rest of the data is composed.
 114: 
 115:                     0 - as defined by enterprise using former methods
 116:                         that existed before SNMPv3. See item 2 below.
 117: 
 118:                     1 - as defined by this architecture, see item 3
 119:                         below.
 120: 
 121:                     Note that this allows existing uses of the
 122:                     engineID (also known as AgentID [RFC1910]) to
 123:                     co-exist with any new uses.
 124: 
 125:                  2) The snmpEngineID has a length of 12 octets.
 126: 
 127:                     The first four octets are set to the binary
 128:                     equivalent of the agent's SNMP management
 129:                     private enterprise number as assigned by the
 130:                     Internet Assigned Numbers Authority (IANA).
 131:                     For example, if Acme Networks has been assigned
 132:                     { enterprises 696 }, the first four octets would
 133:                     be assigned '000002b8'H.
 134: 
 135:                     The remaining eight octets are determined via
 136:                     one or more enterprise-specific methods. Such
 137:                     methods must be designed so as to maximize the
 138:                     possibility that the value of this object will
 139:                     be unique in the agent's administrative domain.
 140:                     For example, it may be the IP address of the SNMP
 141:                     entity, or the MAC address of one of the
 142:                     interfaces, with each address suitably padded
 143:                     with random octets.  If multiple methods are
 144:                     defined, then it is recommended that the first
 145:                     octet indicate the method being used and the
 146:                     remaining octets be a function of the method.
 147: 
 148:                  3) The length of the octet string varies.
 149: 
 150:                     The first four octets are set to the binary
 151:                     equivalent of the agent's SNMP management
 152:                     private enterprise number as assigned by the
 153:                     Internet Assigned Numbers Authority (IANA).
 154:                     For example, if Acme Networks has been assigned
 155:                     { enterprises 696 }, the first four octets would
 156:                     be assigned '000002b8'H.
 157: 
 158:                     The very first bit is set to 1. For example, the
 159:                     above value for Acme Networks now changes to be
 160:                     '800002b8'H.
 161: 
 162:                     The fifth octet indicates how the rest (6th and
 163:                     following octets) are formatted. The values for
 164:                     the fifth octet are:
 165: 
 166:                       0     - reserved, unused.
 167: 
 168:                       1     - IPv4 address (4 octets)
 169:                               lowest non-special IP address
 170: 
 171:                       2     - IPv6 address (16 octets)
 172:                               lowest non-special IP address
 173: 
 174:                       3     - MAC address (6 octets)
 175:                               lowest IEEE MAC address, canonical
 176:                               order
 177: 
 178:                       4     - Text, administratively assigned
 179:                               Maximum remaining length 27
 180: 
 181:                       5     - Octets, administratively assigned
 182:                               Maximum remaining length 27
 183: 
 184:                       6-127 - reserved, unused
 185: 
 186:                     128-255 - as defined by the enterprise
 187:                               Maximum remaining length 27
 188:                 "
 189:     SYNTAX       OCTET STRING (SIZE(5..32))
 190: 
 191: SnmpSecurityModel ::= TEXTUAL-CONVENTION

 192:     STATUS       current
 193:     DESCRIPTION "An identifier that uniquely identifies a
 194:                  Security Model of the Security Subsystem within
 195:                  this SNMP Management Architecture.
 196: 
 197:                  The values for securityModel are allocated as
 198:                  follows:
 199: 
 200:                  - The zero value does not identify any particular
 201:                    security model.
 202: 
 203:                  - Values between 1 and 255, inclusive, are reserved
 204:                    for standards-track Security Models and are
 205:                    managed by the Internet Assigned Numbers Authority
 206:                    (IANA).
 207:                  - Values greater than 255 are allocated to
 208:                    enterprise-specific Security Models.  An
 209:                    enterprise-specific securityModel value is defined
 210:                    to be:
 211: 
 212:                    enterpriseID * 256 + security model within
 213:                    enterprise
 214: 
 215:                    For example, the fourth Security Model defined by
 216:                    the enterprise whose enterpriseID is 1 would be
 217:                    259.
 218: 
 219:                  This scheme for allocation of securityModel
 220:                  values allows for a maximum of 255 standards-
 221:                  based Security Models, and for a maximum of
 222:                  256 Security Models per enterprise.
 223: 
 224:                  It is believed that the assignment of new
 225:                  securityModel values will be rare in practice
 226:                  because the larger the number of simultaneously
 227:                  utilized Security Models, the larger the
 228:                  chance that interoperability will suffer.
 229:                  Consequently, it is believed that such a range
 230:                  will be sufficient.  In the unlikely event that
 231:                  the standards committee finds this number to be
 232:                  insufficient over time, an enterprise number
 233:                  can be allocated to obtain an additional 256
 234:                  possible values.
 235: 
 236:                  Note that the most significant bit must be zero;
 237:                  hence, there are 23 bits allocated for various
 238:                  organizations to design and define non-standard
 239:                  securityModels.  This limits the ability to
 240:                  define new proprietary implementations of Security
 241:                  Models to the first 8,388,608 enterprises.
 242: 
 243:                  It is worthwhile to note that, in its encoded
 244:                  form, the securityModel value will normally
 245:                  require only a single byte since, in practice,
 246:                  the leftmost bits will be zero for most messages
 247:                  and sign extension is suppressed by the encoding
 248:                  rules.
 249: 
 250:                  As of this writing, there are several values
 251:                  of securityModel defined for use with SNMP or
 252:                  reserved for use with supporting MIB objects.
 253:                  They are as follows:
 254: 
 255:                      0  reserved for 'any'
 256:                      1  reserved for SNMPv1
 257:                      2  reserved for SNMPv2c
 258:                      3  User-Based Security Model (USM)
 259:                 "
 260:     SYNTAX       INTEGER(0 .. 2147483647)

 261: 
 262: 
 263: SnmpMessageProcessingModel ::= TEXTUAL-CONVENTION

 264:     STATUS       current
 265:     DESCRIPTION "An identifier that uniquely identifies a Message
 266:                  Processing Model of the Message Processing
 267:                  Subsystem within this SNMP Management Architecture.
 268: 
 269:                  The values for messageProcessingModel are
 270:                  allocated as follows:
 271: 
 272:                  - Values between 0 and 255, inclusive, are
 273:                    reserved for standards-track Message Processing
 274:                    Models and are managed by the Internet Assigned
 275:                    Numbers Authority (IANA).
 276: 
 277:                  - Values greater than 255 are allocated to
 278:                    enterprise-specific Message Processing Models.
 279:                    An enterprise messageProcessingModel value is
 280:                    defined to be:
 281: 
 282:                    enterpriseID * 256 +
 283:                         messageProcessingModel within enterprise
 284: 
 285:                    For example, the fourth Message Processing Model
 286:                    defined by the enterprise whose enterpriseID
 287:                    is 1 would be 259.
 288: 
 289:                  This scheme for allocating messageProcessingModel
 290:                  values allows for a maximum of 255 standards-
 291:                  based Message Processing Models, and for a
 292:                  maximum of 256 Message Processing Models per
 293:                  enterprise.
 294: 
 295:                  It is believed that the assignment of new
 296:                  messageProcessingModel values will be rare
 297:                  in practice because the larger the number of
 298:                  simultaneously utilized Message Processing Models,
 299:                  the larger the chance that interoperability
 300:                  will suffer. It is believed that such a range
 301:                  will be sufficient.  In the unlikely event that
 302:                  the standards committee finds this number to be
 303:                  insufficient over time, an enterprise number
 304:                  can be allocated to obtain an additional 256
 305:                  possible values.
 306: 
 307:                  Note that the most significant bit must be zero;
 308:                  hence, there are 23 bits allocated for various
 309:                  organizations to design and define non-standard
 310:                  messageProcessingModels.  This limits the ability
 311:                  to define new proprietary implementations of
 312:                  Message Processing Models to the first 8,388,608
 313:                  enterprises.
 314: 
 315:                  It is worthwhile to note that, in its encoded
 316:                  form, the messageProcessingModel value will
 317:                  normally require only a single byte since, in
 318:                  practice, the leftmost bits will be zero for
 319:                  most messages and sign extension is suppressed
 320:                  by the encoding rules.
 321: 
 322:                  As of this writing, there are several values of
 323:                  messageProcessingModel defined for use with SNMP.
 324:                  They are as follows:
 325: 
 326:                      0  reserved for SNMPv1
 327:                      1  reserved for SNMPv2c
 328:                      2  reserved for SNMPv2u and SNMPv2*
 329:                      3  reserved for SNMPv3
 330:                 "
 331:     SYNTAX       INTEGER(0 .. 2147483647)

 332: 
 333: SnmpSecurityLevel ::= TEXTUAL-CONVENTION

 334:     STATUS       current
 335:     DESCRIPTION "A Level of Security at which SNMP messages can be
 336:                  sent or with which operations are being processed;
 337:                  in particular, one of:
 338: 
 339:                    noAuthNoPriv - without authentication and
 340:                                   without privacy,
 341:                    authNoPriv   - with authentication but
 342:                                   without privacy,
 343:                    authPriv     - with authentication and
 344:                                   with privacy.
 345: 
 346:                  These three values are ordered such that
 347:                  noAuthNoPriv is less than authNoPriv and
 348:                  authNoPriv is less than authPriv.
 349:                 "
 350:     SYNTAX       INTEGER { noAuthNoPriv(1),
 351:                            authNoPriv(2),
 352:                            authPriv(3)
 353:                          }
 354: 
 355: SnmpAdminString ::= TEXTUAL-CONVENTION

 356:     DISPLAY-HINT "255t"
 357:     STATUS       current
 358:     DESCRIPTION "An octet string containing administrative
 359:                  information, preferably in human-readable form.
 360: 
 361:                  To facilitate internationalization, this
 362:                  information is represented using the ISO/IEC
 363:                  IS 10646-1 character set, encoded as an octet
 364:                  string using the UTF-8 transformation format
 365:                  described in [RFC2279].
 366: 
 367:                  Since additional code points are added by
 368:                  amendments to the 10646 standard from time
 369:                  to time, implementations must be prepared to
 370:                  encounter any code point from 0x00000000 to
 371:                  0x7fffffff.  Byte sequences that do not
 372:                  correspond to the valid UTF-8 encoding of a
 373:                  code point or are outside this range are
 374:                  prohibited.
 375: 
 376:                  The use of control codes should be avoided.
 377: 
 378:                  When it is necessary to represent a newline,
 379:                  the control code sequence CR LF should be used.
 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: 
 413: -- Administrative assignments ***************************************
 414: 
...
 424: snmpEngine OBJECT IDENTIFIER ::= { snmpFrameworkMIBObjects 1 }
 425: snmpEngineID     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: 
 437: snmpEngineBoots  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: 
 447: snmpEngineTime   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: 
 462: snmpEngineMaxMessageSize 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 **