snmp: T3606: Install MIBs into well known location

FRR also expects the MIBs in /usr/share/snmp/mibs

1 files changed, 0 insertions, 912 deletions

diff --git a/data/mibs/SNMP-USER-BASED-SM-MIB.txt b/data/mibs/SNMP-USER-BASED-SM-MIB.txt
deleted file mode 100644
index 3b714030c..000000000
--- a/data/mibs/SNMP-USER-BASED-SM-MIB.txt
+++ /dev/null
@@ -1,912 +0,0 @@
-SNMP-USER-BASED-SM-MIB DEFINITIONS ::= BEGIN
-
-IMPORTS
-    MODULE-IDENTITY, OBJECT-TYPE,
-    OBJECT-IDENTITY,
-    snmpModules, Counter32                FROM SNMPv2-SMI
-    TEXTUAL-CONVENTION, TestAndIncr,
-    RowStatus, RowPointer,
-    StorageType, AutonomousType           FROM SNMPv2-TC
-    MODULE-COMPLIANCE, OBJECT-GROUP       FROM SNMPv2-CONF
-    SnmpAdminString, SnmpEngineID,
-    snmpAuthProtocols, snmpPrivProtocols  FROM SNMP-FRAMEWORK-MIB;
-
-snmpUsmMIB MODULE-IDENTITY
-    LAST-UPDATED "200210160000Z"            -- 16 Oct 2002, midnight
-    ORGANIZATION "SNMPv3 Working Group"
-    CONTACT-INFO "WG-email:   snmpv3@lists.tislabs.com
-                  Subscribe:  majordomo@lists.tislabs.com
-                              In msg body:  subscribe snmpv3
-
-                  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:   David Harrington
-                              Enterasys Networks
-                  Postal:     35 Industrial Way
-                              P. O. Box 5004
-                              Rochester, New Hampshire 03866-5005
-                              USA
-                  EMail:      dbh@enterasys.com
-                  Phone:      +1 603-337-2614
-
-                  Co-editor   Uri Blumenthal
-                              Lucent Technologies
-                  postal:     67 Whippany Rd.
-                              Whippany, NJ 07981
-                              USA
-                  email:      uri@lucent.com
-                  phone:      +1-973-386-2163
-
-                  Co-editor:  Bert Wijnen
-                              Lucent Technologies
-                  postal:     Schagen 33
-                              3461 GL Linschoten
-                              Netherlands
-                  email:      bwijnen@lucent.com
-                  phone:      +31-348-480-685
-                 "
-    DESCRIPTION  "The management information definitions for the
-                  SNMP User-based Security Model.
-
-                  Copyright (C) The Internet Society (2002). This
-                  version of this MIB module is part of RFC 3414;
-                  see the RFC itself for full legal notices.
-                 "
---  Revision history
-
-    REVISION     "200210160000Z"          -- 16 Oct 2002, midnight
-    DESCRIPTION  "Changes in this revision:
-                  - Updated references and contact info.
-                  - Clarification to usmUserCloneFrom DESCRIPTION
-                    clause
-                  - Fixed 'command responder' into 'command generator'
-                    in last para of DESCRIPTION clause of
-                    usmUserTable.
-                  This revision published as RFC3414.
-                 "
-    REVISION     "199901200000Z"          -- 20 Jan 1999, midnight
-    DESCRIPTION  "Clarifications, published as RFC2574"
-
-    REVISION     "199711200000Z"          -- 20 Nov 1997, midnight
-    DESCRIPTION  "Initial version, published as RFC2274"
-    ::= { snmpModules 15 }
-
--- Administrative assignments ****************************************
-
-usmMIBObjects     OBJECT IDENTIFIER ::= { snmpUsmMIB 1 }
-usmMIBConformance OBJECT IDENTIFIER ::= { snmpUsmMIB 2 }
-
--- Identification of Authentication and Privacy Protocols ************
-
-usmNoAuthProtocol OBJECT-IDENTITY
-    STATUS        current
-    DESCRIPTION  "No Authentication Protocol."
-    ::= { snmpAuthProtocols 1 }
-
-usmHMACMD5AuthProtocol OBJECT-IDENTITY
-    STATUS        current
-    DESCRIPTION  "The HMAC-MD5-96 Digest Authentication Protocol."
-    REFERENCE    "- H. Krawczyk, M. Bellare, R. Canetti HMAC:
-                    Keyed-Hashing for Message Authentication,
-                    RFC2104, Feb 1997.
-                  - Rivest, R., Message Digest Algorithm MD5, RFC1321.
-                 "
-    ::= { snmpAuthProtocols 2 }
-
-usmHMACSHAAuthProtocol OBJECT-IDENTITY
-    STATUS        current
-    DESCRIPTION  "The HMAC-SHA-96 Digest Authentication Protocol."
-    REFERENCE    "- H. Krawczyk, M. Bellare, R. Canetti, HMAC:
-                    Keyed-Hashing for Message Authentication,
-                    RFC2104, Feb 1997.
-                  - Secure Hash Algorithm. NIST FIPS 180-1.
-                 "
-    ::= { snmpAuthProtocols 3 }
-
-usmNoPrivProtocol OBJECT-IDENTITY
-    STATUS        current
-    DESCRIPTION  "No Privacy Protocol."
-    ::= { snmpPrivProtocols 1 }
-
-usmDESPrivProtocol OBJECT-IDENTITY
-    STATUS        current
-    DESCRIPTION  "The CBC-DES Symmetric Encryption Protocol."
-    REFERENCE    "- Data Encryption Standard, National Institute of
-                    Standards and Technology.  Federal Information
-                    Processing Standard (FIPS) Publication 46-1.
-
-                    Supersedes FIPS Publication 46,
-                    (January, 1977; reaffirmed January, 1988).
-
-                  - Data Encryption Algorithm, American National
-                    Standards Institute.  ANSI X3.92-1981,
-                    (December, 1980).
-
-                  - DES Modes of Operation, National Institute of
-                    Standards and Technology.  Federal Information
-                    Processing Standard (FIPS) Publication 81,
-                    (December, 1980).
-
-                  - Data Encryption Algorithm - Modes of Operation,
-                    American National Standards Institute.
-                    ANSI X3.106-1983, (May 1983).
-                 "
-    ::= { snmpPrivProtocols 2 }
-
--- Textual Conventions ***********************************************
-
-KeyChange ::=     TEXTUAL-CONVENTION
-   STATUS         current
-   DESCRIPTION
-         "Every definition of an object with this syntax must identify
-          a protocol P, a secret key K, and a hash algorithm H
-          that produces output of L octets.
-
-          The object's value is a manager-generated, partially-random
-          value which, when modified, causes the value of the secret
-          key K, to be modified via a one-way function.
-
-          The value of an instance of this object is the concatenation
-          of two components: first a 'random' component and then a
-          'delta' component.
-
-          The lengths of the random and delta components
-          are given by the corresponding value of the protocol P;
-          if P requires K to be a fixed length, the length of both the
-          random and delta components is that fixed length; if P
-          allows the length of K to be variable up to a particular
-          maximum length, the length of the random component is that
-          maximum length and the length of the delta component is any
-          length less than or equal to that maximum length.
-          For example, usmHMACMD5AuthProtocol requires K to be a fixed
-          length of 16 octets and L - of 16 octets.
-          usmHMACSHAAuthProtocol requires K to be a fixed length of
-          20 octets and L - of 20 octets. Other protocols may define
-          other sizes, as deemed appropriate.
-
-          When a requester wants to change the old key K to a new
-          key keyNew on a remote entity, the 'random' component is
-          obtained from either a true random generator, or from a
-          pseudorandom generator, and the 'delta' component is
-          computed as follows:
-
-           - a temporary variable is initialized to the existing value
-             of K;
-           - if the length of the keyNew is greater than L octets,
-             then:
-              - the random component is appended to the value of the
-                temporary variable, and the result is input to the
-                the hash algorithm H to produce a digest value, and
-                the temporary variable is set to this digest value;
-              - the value of the temporary variable is XOR-ed with
-                the first (next) L-octets (16 octets in case of MD5)
-                of the keyNew to produce the first (next) L-octets
-                (16 octets in case of MD5) of the 'delta' component.
-              - the above two steps are repeated until the unused
-                portion of the keyNew component is L octets or less,
-           - the random component is appended to the value of the
-             temporary variable, and the result is input to the
-             hash algorithm H to produce a digest value;
-           - this digest value, truncated if necessary to be the same
-             length as the unused portion of the keyNew, is XOR-ed
-             with the unused portion of the keyNew to produce the
-             (final portion of the) 'delta' component.
-
-           For example, using MD5 as the hash algorithm H:
-
-              iterations = (lenOfDelta - 1)/16; /* integer division */
-              temp = keyOld;
-              for (i = 0; i < iterations; i++) {
-                  temp = MD5 (temp || random);
-                  delta[i*16 .. (i*16)+15] =
-                         temp XOR keyNew[i*16 .. (i*16)+15];
-              }
-              temp = MD5 (temp || random);
-              delta[i*16 .. lenOfDelta-1] =
-                     temp XOR keyNew[i*16 .. lenOfDelta-1];
-
-          The 'random' and 'delta' components are then concatenated as
-          described above, and the resulting octet string is sent to
-          the recipient as the new value of an instance of this object.
-
-          At the receiver side, when an instance of this object is set
-          to a new value, then a new value of K is computed as follows:
-
-           - a temporary variable is initialized to the existing value
-             of K;
-           - if the length of the delta component is greater than L
-             octets, then:
-              - the random component is appended to the value of the
-                temporary variable, and the result is input to the
-                hash algorithm H to produce a digest value, and the
-                temporary variable is set to this digest value;
-              - the value of the temporary variable is XOR-ed with
-                the first (next) L-octets (16 octets in case of MD5)
-                of the delta component to produce the first (next)
-                L-octets (16 octets in case of MD5) of the new value
-                of K.
-              - the above two steps are repeated until the unused
-                portion of the delta component is L octets or less,
-           - the random component is appended to the value of the
-             temporary variable, and the result is input to the
-             hash algorithm H to produce a digest value;
-           - this digest value, truncated if necessary to be the same
-             length as the unused portion of the delta component, is
-             XOR-ed with the unused portion of the delta component to
-             produce the (final portion of the) new value of K.
-
-           For example, using MD5 as the hash algorithm H:
-
-              iterations = (lenOfDelta - 1)/16; /* integer division */
-              temp = keyOld;
-              for (i = 0; i < iterations; i++) {
-                  temp = MD5 (temp || random);
-                  keyNew[i*16 .. (i*16)+15] =
-                         temp XOR delta[i*16 .. (i*16)+15];
-              }
-              temp = MD5 (temp || random);
-              keyNew[i*16 .. lenOfDelta-1] =
-                     temp XOR delta[i*16 .. lenOfDelta-1];
-
-          The value of an object with this syntax, whenever it is
-          retrieved by the management protocol, is always the zero
-          length string.
-
-          Note that the keyOld and keyNew are the localized keys.
-
-          Note that it is probably wise that when an SNMP entity sends
-          a SetRequest to change a key, that it keeps a copy of the old
-          key until it has confirmed that the key change actually
-          succeeded.
-         "
-    SYNTAX       OCTET STRING
-
--- Statistics for the User-based Security Model **********************
-
-usmStats         OBJECT IDENTIFIER ::= { usmMIBObjects 1 }
-
-usmStatsUnsupportedSecLevels OBJECT-TYPE
-    SYNTAX       Counter32
-    MAX-ACCESS   read-only
-    STATUS       current
-    DESCRIPTION "The total number of packets received by the SNMP
-                 engine which were dropped because they requested a
-                 securityLevel that was unknown to the SNMP engine
-                 or otherwise unavailable.
-                "
-    ::= { usmStats 1 }
-
-usmStatsNotInTimeWindows OBJECT-TYPE
-    SYNTAX       Counter32
-    MAX-ACCESS   read-only
-    STATUS       current
-    DESCRIPTION "The total number of packets received by the SNMP
-                 engine which were dropped because they appeared
-                 outside of the authoritative SNMP engine's window.
-                "
-    ::= { usmStats 2 }
-
-usmStatsUnknownUserNames OBJECT-TYPE
-    SYNTAX       Counter32
-    MAX-ACCESS   read-only
-    STATUS       current
-    DESCRIPTION "The total number of packets received by the SNMP
-                 engine which were dropped because they referenced a
-                 user that was not known to the SNMP engine.
-                "
-    ::= { usmStats 3 }
-
-usmStatsUnknownEngineIDs OBJECT-TYPE
-    SYNTAX       Counter32
-    MAX-ACCESS   read-only
-    STATUS       current
-    DESCRIPTION "The total number of packets received by the SNMP
-                 engine which were dropped because they referenced an
-                 snmpEngineID that was not known to the SNMP engine.
-                "
-    ::= { usmStats 4 }
-
-usmStatsWrongDigests OBJECT-TYPE
-    SYNTAX       Counter32
-    MAX-ACCESS   read-only
-    STATUS       current
-    DESCRIPTION "The total number of packets received by the SNMP
-                 engine which were dropped because they didn't
-                 contain the expected digest value.
-                "
-    ::= { usmStats 5 }
-
-usmStatsDecryptionErrors OBJECT-TYPE
-    SYNTAX       Counter32
-    MAX-ACCESS   read-only
-    STATUS       current
-    DESCRIPTION "The total number of packets received by the SNMP
-                 engine which were dropped because they could not be
-                 decrypted.
-                "
-    ::= { usmStats 6 }
-
--- The usmUser Group ************************************************
-
-usmUser          OBJECT IDENTIFIER ::= { usmMIBObjects 2 }
-
-usmUserSpinLock  OBJECT-TYPE
-    SYNTAX       TestAndIncr
-    MAX-ACCESS   read-write
-    STATUS       current
-    DESCRIPTION "An advisory lock used to allow several cooperating
-                 Command Generator Applications to coordinate their
-                 use of facilities to alter secrets in the
-                 usmUserTable.
-                "
-    ::= { usmUser 1 }
-
--- The table of valid users for the User-based Security Model ********
-
-usmUserTable     OBJECT-TYPE
-    SYNTAX       SEQUENCE OF UsmUserEntry
-    MAX-ACCESS   not-accessible
-    STATUS       current
-    DESCRIPTION "The table of users configured in the SNMP engine's
-                 Local Configuration Datastore (LCD).
-
-                 To create a new user (i.e., to instantiate a new
-                 conceptual row in this table), it is recommended to
-                 follow this procedure:
-
-                   1)  GET(usmUserSpinLock.0) and save in sValue.
-
-                   2)  SET(usmUserSpinLock.0=sValue,
-                           usmUserCloneFrom=templateUser,
-                           usmUserStatus=createAndWait)
-                       You should use a template user to clone from
-                       which has the proper auth/priv protocol defined.
-
-                 If the new user is to use privacy:
-
-                   3)  generate the keyChange value based on the secret
-                       privKey of the clone-from user and the secret key
-                       to be used for the new user. Let us call this
-                       pkcValue.
-                   4)  GET(usmUserSpinLock.0) and save in sValue.
-                   5)  SET(usmUserSpinLock.0=sValue,
-                           usmUserPrivKeyChange=pkcValue
-                           usmUserPublic=randomValue1)
-                   6)  GET(usmUserPulic) and check it has randomValue1.
-                       If not, repeat steps 4-6.
-
-                 If the new user will never use privacy:
-
-                   7)  SET(usmUserPrivProtocol=usmNoPrivProtocol)
-
-                 If the new user is to use authentication:
-
-                   8)  generate the keyChange value based on the secret
-                       authKey of the clone-from user and the secret key
-                       to be used for the new user. Let us call this
-                       akcValue.
-                   9)  GET(usmUserSpinLock.0) and save in sValue.
-                   10) SET(usmUserSpinLock.0=sValue,
-                           usmUserAuthKeyChange=akcValue
-                           usmUserPublic=randomValue2)
-                   11) GET(usmUserPulic) and check it has randomValue2.
-                       If not, repeat steps 9-11.
-
-                 If the new user will never use authentication:
-
-                   12) SET(usmUserAuthProtocol=usmNoAuthProtocol)
-
-                 Finally, activate the new user:
-
-                   13) SET(usmUserStatus=active)
-
-                 The new user should now be available and ready to be
-                 used for SNMPv3 communication. Note however that access
-                 to MIB data must be provided via configuration of the
-                 SNMP-VIEW-BASED-ACM-MIB.
-
-                 The use of usmUserSpinlock is to avoid conflicts with
-                 another SNMP command generator application which may
-                 also be acting on the usmUserTable.
-                "
-    ::= { usmUser 2 }
-
-usmUserEntry     OBJECT-TYPE
-    SYNTAX       UsmUserEntry
-    MAX-ACCESS   not-accessible
-    STATUS       current
-    DESCRIPTION "A user configured in the SNMP engine's Local
-                 Configuration Datastore (LCD) for the User-based
-                 Security Model.
-                "
-    INDEX       { usmUserEngineID,
-                  usmUserName
-                }
-    ::= { usmUserTable 1 }
-
-UsmUserEntry ::= SEQUENCE
-    {
-        usmUserEngineID         SnmpEngineID,
-        usmUserName             SnmpAdminString,
-        usmUserSecurityName     SnmpAdminString,
-        usmUserCloneFrom        RowPointer,
-        usmUserAuthProtocol     AutonomousType,
-        usmUserAuthKeyChange    KeyChange,
-        usmUserOwnAuthKeyChange KeyChange,
-        usmUserPrivProtocol     AutonomousType,
-        usmUserPrivKeyChange    KeyChange,
-        usmUserOwnPrivKeyChange KeyChange,
-        usmUserPublic           OCTET STRING,
-        usmUserStorageType      StorageType,
-        usmUserStatus           RowStatus
-    }
-
-usmUserEngineID  OBJECT-TYPE
-    SYNTAX       SnmpEngineID
-    MAX-ACCESS   not-accessible
-    STATUS       current
-    DESCRIPTION "An SNMP engine's administratively-unique identifier.
-
-                 In a simple agent, this value is always that agent's
-                 own snmpEngineID value.
-
-                 The value can also take the value of the snmpEngineID
-                 of a remote SNMP engine with which this user can
-                 communicate.
-                "
-    ::= { usmUserEntry 1 }
-
-usmUserName      OBJECT-TYPE
-    SYNTAX       SnmpAdminString (SIZE(1..32))
-    MAX-ACCESS   not-accessible
-    STATUS       current
-    DESCRIPTION "A human readable string representing the name of
-                 the user.
-
-                 This is the (User-based Security) Model dependent
-                 security ID.
-                "
-    ::= { usmUserEntry 2 }
-
-usmUserSecurityName OBJECT-TYPE
-    SYNTAX       SnmpAdminString
-    MAX-ACCESS   read-only
-    STATUS       current
-    DESCRIPTION "A human readable string representing the user in
-                 Security Model independent format.
-
-                 The default transformation of the User-based Security
-                 Model dependent security ID to the securityName and
-                 vice versa is the identity function so that the
-                 securityName is the same as the userName.
-                "
-    ::= { usmUserEntry 3 }
-
-usmUserCloneFrom OBJECT-TYPE
-    SYNTAX       RowPointer
-    MAX-ACCESS   read-create
-    STATUS       current
-    DESCRIPTION "A pointer to another conceptual row in this
-                 usmUserTable.  The user in this other conceptual
-                 row is called the clone-from user.
-
-                 When a new user is created (i.e., a new conceptual
-                 row is instantiated in this table), the privacy and
-                 authentication parameters of the new user must be
-                 cloned from its clone-from user. These parameters are:
-                   - authentication protocol (usmUserAuthProtocol)
-                   - privacy protocol (usmUserPrivProtocol)
-                 They will be copied regardless of what the current
-                 value is.
-
-                 Cloning also causes the initial values of the secret
-                 authentication key (authKey) and the secret encryption
-
-                 key (privKey) of the new user to be set to the same
-                 values as the corresponding secrets of the clone-from
-                 user to allow the KeyChange process to occur as
-                 required during user creation.
-
-                 The first time an instance of this object is set by
-                 a management operation (either at or after its
-                 instantiation), the cloning process is invoked.
-                 Subsequent writes are successful but invoke no
-                 action to be taken by the receiver.
-                 The cloning process fails with an 'inconsistentName'
-                 error if the conceptual row representing the
-                 clone-from user does not exist or is not in an active
-                 state when the cloning process is invoked.
-
-                 When this object is read, the ZeroDotZero OID
-                 is returned.
-                "
-    ::= { usmUserEntry 4 }
-
-usmUserAuthProtocol OBJECT-TYPE
-    SYNTAX       AutonomousType
-    MAX-ACCESS   read-create
-    STATUS       current
-    DESCRIPTION "An indication of whether messages sent on behalf of
-                 this user to/from the SNMP engine identified by
-                 usmUserEngineID, can be authenticated, and if so,
-                 the type of authentication protocol which is used.
-
-                 An instance of this object is created concurrently
-                 with the creation of any other object instance for
-                 the same user (i.e., as part of the processing of
-                 the set operation which creates the first object
-                 instance in the same conceptual row).
-
-                 If an initial set operation (i.e. at row creation time)
-                 tries to set a value for an unknown or unsupported
-                 protocol, then a 'wrongValue' error must be returned.
-
-                 The value will be overwritten/set when a set operation
-                 is performed on the corresponding instance of
-                 usmUserCloneFrom.
-
-                 Once instantiated, the value of such an instance of
-                 this object can only be changed via a set operation to
-                 the value of the usmNoAuthProtocol.
-
-                 If a set operation tries to change the value of an
-
-                 existing instance of this object to any value other
-                 than usmNoAuthProtocol, then an 'inconsistentValue'
-                 error must be returned.
-
-                 If a set operation tries to set the value to the
-                 usmNoAuthProtocol while the usmUserPrivProtocol value
-                 in the same row is not equal to usmNoPrivProtocol,
-                 then an 'inconsistentValue' error must be returned.
-                 That means that an SNMP command generator application
-                 must first ensure that the usmUserPrivProtocol is set
-                 to the usmNoPrivProtocol value before it can set
-                 the usmUserAuthProtocol value to usmNoAuthProtocol.
-                "
-    DEFVAL      { usmNoAuthProtocol }
-    ::= { usmUserEntry 5 }
-
-usmUserAuthKeyChange OBJECT-TYPE
-    SYNTAX       KeyChange   -- typically (SIZE (0 | 32)) for HMACMD5
-                             -- typically (SIZE (0 | 40)) for HMACSHA
-    MAX-ACCESS   read-create
-    STATUS       current
-    DESCRIPTION "An object, which when modified, causes the secret
-                 authentication key used for messages sent on behalf
-                 of this user to/from the SNMP engine identified by
-                 usmUserEngineID, to be modified via a one-way
-                 function.
-
-                 The associated protocol is the usmUserAuthProtocol.
-                 The associated secret key is the user's secret
-                 authentication key (authKey). The associated hash
-                 algorithm is the algorithm used by the user's
-                 usmUserAuthProtocol.
-
-                 When creating a new user, it is an 'inconsistentName'
-                 error for a set operation to refer to this object
-                 unless it is previously or concurrently initialized
-                 through a set operation on the corresponding instance
-                 of usmUserCloneFrom.
-
-                 When the value of the corresponding usmUserAuthProtocol
-                 is usmNoAuthProtocol, then a set is successful, but
-                 effectively is a no-op.
-
-                 When this object is read, the zero-length (empty)
-                 string is returned.
-
-                 The recommended way to do a key change is as follows:
-
-                   1) GET(usmUserSpinLock.0) and save in sValue.
-                   2) generate the keyChange value based on the old
-                      (existing) secret key and the new secret key,
-                      let us call this kcValue.
-
-                 If you do the key change on behalf of another user:
-
-                   3) SET(usmUserSpinLock.0=sValue,
-                          usmUserAuthKeyChange=kcValue
-                          usmUserPublic=randomValue)
-
-                 If you do the key change for yourself:
-
-                   4) SET(usmUserSpinLock.0=sValue,
-                          usmUserOwnAuthKeyChange=kcValue
-                          usmUserPublic=randomValue)
-
-                 If you get a response with error-status of noError,
-                 then the SET succeeded and the new key is active.
-                 If you do not get a response, then you can issue a
-                 GET(usmUserPublic) and check if the value is equal
-                 to the randomValue you did send in the SET. If so, then
-                 the key change succeeded and the new key is active
-                 (probably the response got lost). If not, then the SET
-                 request probably never reached the target and so you
-                 can start over with the procedure above.
-                "
-    DEFVAL      { ''H }    -- the empty string
-    ::= { usmUserEntry 6 }
-
-usmUserOwnAuthKeyChange OBJECT-TYPE
-    SYNTAX       KeyChange   -- typically (SIZE (0 | 32)) for HMACMD5
-                             -- typically (SIZE (0 | 40)) for HMACSHA
-    MAX-ACCESS   read-create
-    STATUS       current
-    DESCRIPTION "Behaves exactly as usmUserAuthKeyChange, with one
-                 notable difference: in order for the set operation
-                 to succeed, the usmUserName of the operation
-                 requester must match the usmUserName that
-                 indexes the row which is targeted by this
-                 operation.
-                 In addition, the USM security model must be
-                 used for this operation.
-
-                 The idea here is that access to this column can be
-                 public, since it will only allow a user to change
-                 his own secret authentication key (authKey).
-                 Note that this can only be done once the row is active.
-
-                 When a set is received and the usmUserName of the
-                 requester is not the same as the umsUserName that
-                 indexes the row which is targeted by this operation,
-                 then a 'noAccess' error must be returned.
-
-                 When a set is received and the security model in use
-                 is not USM, then a 'noAccess' error must be returned.
-                "
-    DEFVAL      { ''H }    -- the empty string
-    ::= { usmUserEntry 7 }
-
-usmUserPrivProtocol OBJECT-TYPE
-    SYNTAX       AutonomousType
-    MAX-ACCESS   read-create
-    STATUS       current
-    DESCRIPTION "An indication of whether messages sent on behalf of
-                 this user to/from the SNMP engine identified by
-                 usmUserEngineID, can be protected from disclosure,
-                 and if so, the type of privacy protocol which is used.
-
-                 An instance of this object is created concurrently
-                 with the creation of any other object instance for
-                 the same user (i.e., as part of the processing of
-                 the set operation which creates the first object
-                 instance in the same conceptual row).
-
-                 If an initial set operation (i.e. at row creation time)
-                 tries to set a value for an unknown or unsupported
-                 protocol, then a 'wrongValue' error must be returned.
-
-                 The value will be overwritten/set when a set operation
-                 is performed on the corresponding instance of
-                 usmUserCloneFrom.
-
-                 Once instantiated, the value of such an instance of
-                 this object can only be changed via a set operation to
-                 the value of the usmNoPrivProtocol.
-
-                 If a set operation tries to change the value of an
-                 existing instance of this object to any value other
-                 than usmNoPrivProtocol, then an 'inconsistentValue'
-                 error must be returned.
-
-                 Note that if any privacy protocol is used, then you
-                 must also use an authentication protocol. In other
-                 words, if usmUserPrivProtocol is set to anything else
-                 than usmNoPrivProtocol, then the corresponding instance
-                 of usmUserAuthProtocol cannot have a value of
-
-                 usmNoAuthProtocol. If it does, then an
-                 'inconsistentValue' error must be returned.
-                "
-    DEFVAL      { usmNoPrivProtocol }
-    ::= { usmUserEntry 8 }
-
-usmUserPrivKeyChange OBJECT-TYPE
-    SYNTAX       KeyChange  -- typically (SIZE (0 | 32)) for DES
-    MAX-ACCESS   read-create
-    STATUS       current
-    DESCRIPTION "An object, which when modified, causes the secret
-                 encryption key used for messages sent on behalf
-                 of this user to/from the SNMP engine identified by
-                 usmUserEngineID, to be modified via a one-way
-                 function.
-
-                 The associated protocol is the usmUserPrivProtocol.
-                 The associated secret key is the user's secret
-                 privacy key (privKey). The associated hash
-                 algorithm is the algorithm used by the user's
-                 usmUserAuthProtocol.
-
-                 When creating a new user, it is an 'inconsistentName'
-                 error for a set operation to refer to this object
-                 unless it is previously or concurrently initialized
-                 through a set operation on the corresponding instance
-                 of usmUserCloneFrom.
-
-                 When the value of the corresponding usmUserPrivProtocol
-                 is usmNoPrivProtocol, then a set is successful, but
-                 effectively is a no-op.
-
-                 When this object is read, the zero-length (empty)
-                 string is returned.
-                 See the description clause of usmUserAuthKeyChange for
-                 a recommended procedure to do a key change.
-                "
-    DEFVAL      { ''H }    -- the empty string
-    ::= { usmUserEntry 9 }
-
-usmUserOwnPrivKeyChange OBJECT-TYPE
-    SYNTAX       KeyChange  -- typically (SIZE (0 | 32)) for DES
-    MAX-ACCESS   read-create
-    STATUS       current
-    DESCRIPTION "Behaves exactly as usmUserPrivKeyChange, with one
-                 notable difference: in order for the Set operation
-                 to succeed, the usmUserName of the operation
-                 requester must match the usmUserName that indexes
-
-                 the row which is targeted by this operation.
-                 In addition, the USM security model must be
-                 used for this operation.
-
-                 The idea here is that access to this column can be
-                 public, since it will only allow a user to change
-                 his own secret privacy key (privKey).
-                 Note that this can only be done once the row is active.
-
-                 When a set is received and the usmUserName of the
-                 requester is not the same as the umsUserName that
-                 indexes the row which is targeted by this operation,
-                 then a 'noAccess' error must be returned.
-
-                 When a set is received and the security model in use
-                 is not USM, then a 'noAccess' error must be returned.
-                "
-    DEFVAL      { ''H }    -- the empty string
-    ::= { usmUserEntry 10 }
-
-usmUserPublic    OBJECT-TYPE
-    SYNTAX       OCTET STRING (SIZE(0..32))
-    MAX-ACCESS   read-create
-    STATUS       current
-    DESCRIPTION "A publicly-readable value which can be written as part
-                 of the procedure for changing a user's secret
-                 authentication and/or privacy key, and later read to
-                 determine whether the change of the secret was
-                 effected.
-                "
-    DEFVAL      { ''H }  -- the empty string
-    ::= { usmUserEntry 11 }
-
-usmUserStorageType OBJECT-TYPE
-    SYNTAX       StorageType
-    MAX-ACCESS   read-create
-    STATUS       current
-    DESCRIPTION "The storage type for this conceptual row.
-
-                 Conceptual rows having the value 'permanent' must
-                 allow write-access at a minimum to:
-
-                 - usmUserAuthKeyChange, usmUserOwnAuthKeyChange
-                   and usmUserPublic for a user who employs
-                   authentication, and
-                 - usmUserPrivKeyChange, usmUserOwnPrivKeyChange
-                   and usmUserPublic for a user who employs
-                   privacy.
-
-                 Note that any user who employs authentication or
-                 privacy must allow its secret(s) to be updated and
-                 thus cannot be 'readOnly'.
-
-                 If an initial set operation tries to set the value to
-                 'readOnly' for a user who employs authentication or
-                 privacy, then an 'inconsistentValue' error must be
-                 returned.  Note that if the value has been previously
-                 set (implicit or explicit) to any value, then the rules
-                 as defined in the StorageType Textual Convention apply.
-
-                 It is an implementation issue to decide if a SET for
-                 a readOnly or permanent row is accepted at all. In some
-                 contexts this may make sense, in others it may not. If
-                 a SET for a readOnly or permanent row is not accepted
-                 at all, then a 'wrongValue' error must be returned.
-                "
-    DEFVAL      { nonVolatile }
-    ::= { usmUserEntry 12 }
-
-usmUserStatus    OBJECT-TYPE
-    SYNTAX       RowStatus
-    MAX-ACCESS   read-create
-    STATUS       current
-    DESCRIPTION "The status of this conceptual row.
-
-                 Until instances of all corresponding columns are
-                 appropriately configured, the value of the
-                 corresponding instance of the usmUserStatus column
-                 is 'notReady'.
-
-                 In particular, a newly created row for a user who
-                 employs authentication, cannot be made active until the
-                 corresponding usmUserCloneFrom and usmUserAuthKeyChange
-                 have been set.
-
-                 Further, a newly created row for a user who also
-                 employs privacy, cannot be made active until the
-                 usmUserPrivKeyChange has been set.
-
-                 The RowStatus TC [RFC2579] requires that this
-                 DESCRIPTION clause states under which circumstances
-                 other objects in this row can be modified:
-
-                 The value of this object has no effect on whether
-                 other objects in this conceptual row can be modified,
-                 except for usmUserOwnAuthKeyChange and
-                 usmUserOwnPrivKeyChange. For these 2 objects, the
-
-                 value of usmUserStatus MUST be active.
-                "
-    ::= { usmUserEntry 13 }
-
--- Conformance Information *******************************************
-
-usmMIBCompliances OBJECT IDENTIFIER ::= { usmMIBConformance 1 }
-usmMIBGroups      OBJECT IDENTIFIER ::= { usmMIBConformance 2 }
-
--- Compliance statements
-
-usmMIBCompliance MODULE-COMPLIANCE
-    STATUS       current
-    DESCRIPTION "The compliance statement for SNMP engines which
-                 implement the SNMP-USER-BASED-SM-MIB.
-                "
-
-    MODULE       -- this module
-        MANDATORY-GROUPS { usmMIBBasicGroup }
-
-        OBJECT           usmUserAuthProtocol
-        MIN-ACCESS       read-only
-        DESCRIPTION     "Write access is not required."
-
-        OBJECT           usmUserPrivProtocol
-        MIN-ACCESS       read-only
-        DESCRIPTION     "Write access is not required."
-    ::= { usmMIBCompliances 1 }
-
--- Units of compliance
-usmMIBBasicGroup OBJECT-GROUP
-    OBJECTS     {
-                  usmStatsUnsupportedSecLevels,
-                  usmStatsNotInTimeWindows,
-                  usmStatsUnknownUserNames,
-                  usmStatsUnknownEngineIDs,
-                  usmStatsWrongDigests,
-                  usmStatsDecryptionErrors,
-                  usmUserSpinLock,
-                  usmUserSecurityName,
-                  usmUserCloneFrom,
-                  usmUserAuthProtocol,
-                  usmUserAuthKeyChange,
-                  usmUserOwnAuthKeyChange,
-                  usmUserPrivProtocol,
-                  usmUserPrivKeyChange,
-                  usmUserOwnPrivKeyChange,
-                  usmUserPublic,
-                  usmUserStorageType,
-                  usmUserStatus
-                }
-    STATUS       current
-    DESCRIPTION "A collection of objects providing for configuration
-                 of an SNMP engine which implements the SNMP
-                 User-based Security Model.
-                "
-    ::= { usmMIBGroups 1 }
-
-END