home *** CD-ROM | disk | FTP | other *** search
/ Chip 2001 May / W2KPRK.iso / apps / InternetScanner / data1.cab / Program_Files / Mibs / SNMP-FRAMEWORK-MIB.txt < prev    next >
Encoding:
Text File  |  1999-11-22  |  14.8 KB  |  463 lines

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