telemetry-snmp 0.1.0

data/lib/telemetry/snmp/mibs/SNMP-FRAMEWORK-MIB.txt

@@ -0,0 +1,526 @@
+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