home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / rfc / rfc1448 < prev    next >
Text File  |  1993-05-02  |  74KB  |  2,126 lines
  1.  
  2.  
  3.  
  4.           Network Working Group                                  J. Case
  5.           Request for Comments: 1448                 SNMP Research, Inc.
  6.                                                            K. McCloghrie
  7.                                                       Hughes LAN Systems
  8.                                                                  M. Rose
  9.                                             Dover Beach Consulting, Inc.
  10.                                                            S. Waldbusser
  11.                                               Carnegie Mellon University
  12.                                                               April 1993
  13.  
  14.  
  15.                                Protocol Operations
  16.                                for version 2 of the
  17.                    Simple Network Management Protocol (SNMPv2)
  18.  
  19.  
  20.           Status of this Memo
  21.  
  22.           This RFC specifes an IAB standards track protocol for the
  23.           Internet community, and requests discussion and suggestions
  24.           for improvements.  Please refer to the current edition of the
  25.           "IAB Official Protocol Standards" for the standardization
  26.           state and status of this protocol.  Distribution of this memo
  27.           is unlimited.
  28.  
  29.  
  30.           Table of Contents
  31.  
  32.           1 Introduction ..........................................    2
  33.           1.1 A Note on Terminology ...............................    2
  34.           2 Overview ..............................................    3
  35.           2.1 Roles of Protocol Entities ..........................    3
  36.           2.2 Management Information ..............................    3
  37.           2.3 Access to Management Information ....................    4
  38.           2.4 Retransmission of Requests ..........................    4
  39.           2.5 Message Sizes .......................................    5
  40.           2.6 Transport Mappings ..................................    6
  41.           3 Definitions ...........................................    7
  42.           4 Protocol Specification ................................   12
  43.           4.1 Common Constructs ...................................   12
  44.           4.2 PDU Processing ......................................   12
  45.           4.2.1 The GetRequest-PDU ................................   13
  46.           4.2.2 The GetNextRequest-PDU ............................   15
  47.           4.2.2.1 Example of Table Traversal ......................   16
  48.           4.2.3 The GetBulkRequest-PDU ............................   18
  49.           4.2.3.1 Another Example of Table Traversal ..............   21
  50.           4.2.4 The Response-PDU ..................................   22
  51.           4.2.5 The SetRequest-PDU ................................   23
  52.           4.2.6 The SNMPv2-Trap-PDU ...............................   26
  53.           4.2.7 The InformRequest-PDU .............................   27
  54.  
  55.  
  56.  
  57.  
  58.  
  59.           Case, McCloghrie, Rose & Waldbusser                   [Page i]
  60.  
  61.  
  62.  
  63.  
  64.  
  65.           RFC 1448        Protocol Operations for SNMPv2      April 1993
  66.  
  67.  
  68.           5 Acknowledgements ......................................   29
  69.           6 References ............................................   33
  70.           7 Security Considerations ...............................   35
  71.           8 Authors' Addresses ....................................   35
  72.  
  73.  
  74.  
  75.  
  76.  
  77.  
  78.  
  79.  
  80.  
  81.  
  82.  
  83.  
  84.  
  85.  
  86.  
  87.  
  88.  
  89.  
  90.  
  91.  
  92.  
  93.  
  94.  
  95.  
  96.  
  97.  
  98.  
  99.  
  100.  
  101.  
  102.  
  103.  
  104.  
  105.  
  106.  
  107.  
  108.  
  109.  
  110.  
  111.  
  112.  
  113.  
  114.  
  115.  
  116.  
  117.  
  118.           Case, McCloghrie, Rose & Waldbusser                   [Page 1]
  119.  
  120.  
  121.  
  122.  
  123.  
  124.           RFC 1448        Protocol Operations for SNMPv2      April 1993
  125.  
  126.  
  127.           1.  Introduction
  128.  
  129.           A network management system contains: several (potentially
  130.           many) nodes, each with a processing entity, termed an agent,
  131.           which has access to management instrumentation; at least one
  132.           management station; and, a management protocol, used to convey
  133.           management information between the agents and management
  134.           stations.  Operations of the protocol are carried out under an
  135.           administrative framework which defines both authentication and
  136.           authorization policies.
  137.  
  138.           Network management stations execute management applications
  139.           which monitor and control network elements.  Network elements
  140.           are devices such as hosts, routers, terminal servers, etc.,
  141.           which are monitored and controlled through access to their
  142.           management information.
  143.  
  144.           Management information is viewed as a collection of managed
  145.           objects, residing in a virtual information store, termed the
  146.           Management Information Base (MIB).  Collections of related
  147.           objects are defined in MIB modules.  These modules are written
  148.           using a subset of OSI's Abstract Syntax Notation One (ASN.1)
  149.           [1], termed the Structure of Management Information (SMI) [2].
  150.  
  151.           The management protocol, version 2 of the Simple Network
  152.           Management Protocol, provides for the exchange of messages
  153.           which convey management information between the agents and the
  154.           management stations.  The form of these messages is a message
  155.           "wrapper" which encapsulates a Protocol Data Unit (PDU).  The
  156.           form and meaning of the "wrapper" is determined by an
  157.           administrative framework which defines both authentication and
  158.           authorization policies.
  159.  
  160.           It is the purpose of this document, Protocol Operations for
  161.           SNMPv2, to define the operations of the protocol with respect
  162.           to the sending and receiving of the PDUs.
  163.  
  164.  
  165.           1.1.  A Note on Terminology
  166.  
  167.           For the purpose of exposition, the original Internet-standard
  168.           Network Management Framework, as described in RFCs 1155, 1157,
  169.           and 1212, is termed the SNMP version 1 framework (SNMPv1).
  170.           The current framework is termed the SNMP version 2 framework
  171.           (SNMPv2).
  172.  
  173.  
  174.  
  175.  
  176.  
  177.           Case, McCloghrie, Rose & Waldbusser                   [Page 2]
  178.  
  179.  
  180.  
  181.  
  182.  
  183.           RFC 1448        Protocol Operations for SNMPv2      April 1993
  184.  
  185.  
  186.           2.  Overview
  187.  
  188.           2.1.  Roles of Protocol Entities
  189.  
  190.           A SNMPv2 entity may operate in a manager role or an agent
  191.           role.
  192.  
  193.           A SNMPv2 entity acts in an agent role when it performs SNMPv2
  194.           management operations in response to received SNMPv2 protocol
  195.           messages (other than an inform notification) or when it sends
  196.           trap notifications.
  197.  
  198.           A SNMPv2 entity acts in a manager role when it initiates
  199.           SNMPv2 management operations by the generation of SNMPv2
  200.           protocol messages or when it performs SNMPv2 management
  201.           operations in response to received trap or inform
  202.           notifications.
  203.  
  204.           A SNMPv2 entity may support either or both roles, as dictated
  205.           by its implementation and configuration.  Further, a SNMPv2
  206.           entity can also act in the role of a proxy agent, in which it
  207.           appears to be acting in an agent role, but satisfies
  208.           management requests by acting in a manager role with a remote
  209.           entity.  The use of proxy agents and the transparency
  210.           principle that defines their behavior is described in [3].
  211.  
  212.  
  213.           2.2.  Management Information
  214.  
  215.           The term, variable, refers to an instance of a non-aggregate
  216.           object type defined according to the conventions set forth in
  217.           the SMI [2] or the textual conventions based on the SMI [4].
  218.           The term, variable binding, normally refers to the pairing of
  219.           the name of a variable and its associated value.  However, if
  220.           certain kinds of exceptional conditions occur during
  221.           processing of a retrieval request, a variable binding will
  222.           pair a name and an indication of that exception.
  223.  
  224.           A variable-binding list is a simple list of variable bindings.
  225.  
  226.           The name of a variable is an OBJECT IDENTIFIER which is the
  227.           concatenation of the OBJECT IDENTIFIER of the corresponding
  228.           object-type together with an OBJECT IDENTIFIER fragment
  229.           identifying the instance.  The OBJECT IDENTIFIER of the
  230.           corresponding object-type is called the OBJECT IDENTIFIER
  231.  
  232.  
  233.  
  234.  
  235.  
  236.           Case, McCloghrie, Rose & Waldbusser                   [Page 3]
  237.  
  238.  
  239.  
  240.  
  241.  
  242.           RFC 1448        Protocol Operations for SNMPv2      April 1993
  243.  
  244.  
  245.           prefix of the variable.
  246.  
  247.  
  248.           2.3.  Access to Management Information
  249.  
  250.           Three types of access to management information are provided
  251.           by the protocol.  One type is a request-response interaction,
  252.           in which a SNMPv2 entity, acting in a manager role, sends a
  253.           request to a SNMPv2 entity, acting in an agent role, and the
  254.           latter SNMPv2 entity then responds to the request.  This type
  255.           is used to retrieve or modify management information
  256.           associated with the managed device.
  257.  
  258.           A second type is also a request-response interaction, in which
  259.           a SNMPv2 entity, acting in a manager role, sends a request to
  260.           a SNMPv2 entity, also acting in a manager role, and the latter
  261.           SNMPv2 entity then responds to the request.  This type is used
  262.           to notify a SNMPv2 entity, acting in a manager role, of
  263.           management information associated with another SNMPv2 entity,
  264.           also acting in a manager role.
  265.  
  266.           The third type of access is an unconfirmed interaction, in
  267.           which a SNMPv2 entity, acting in an agent role, sends a
  268.           unsolicited message, termed a trap, to a SNMPv2 entity, acting
  269.           in a manager role, and no response is returned.  This type is
  270.           used to notify a SNMPv2 entity, acting in a manager role, of
  271.           an exceptional situation, which has resulted in changes to
  272.           management information associated with the managed device.
  273.  
  274.  
  275.           2.4.  Retransmission of Requests
  276.  
  277.           For all types of request in this protocol, the receiver is
  278.           required under normal circumstances, to generate and transmit
  279.           a response to the originator of the request.  Whether or not a
  280.           request should be retransmitted if no corresponding response
  281.           is received in an appropriate time interval, is at the
  282.           discretion of the application originating the request.  This
  283.           will normally depend on the urgency of the request.  However,
  284.           such an application needs to act responsibly in respect to the
  285.           frequency and duration of re-transmissions.
  286.  
  287.  
  288.  
  289.  
  290.  
  291.  
  292.  
  293.  
  294.  
  295.           Case, McCloghrie, Rose & Waldbusser                   [Page 4]
  296.  
  297.  
  298.  
  299.  
  300.  
  301.           RFC 1448        Protocol Operations for SNMPv2      April 1993
  302.  
  303.  
  304.           2.5.  Message Sizes
  305.  
  306.           The maximum size of a SNMPv2 message is limited the minimum
  307.           of:
  308.  
  309.           (1)  the maximum message size which the destination SNMPv2
  310.                entity can accept; and,
  311.  
  312.           (2)  the maximum message size which the source SNMPv2 entity
  313.                can generate.
  314.  
  315.           The former is indicated by partyMaxMessageSize[5] of the
  316.           destination party.  The latter is imposed by implementation-
  317.           specific local constraints.
  318.  
  319.           Each transport mapping for the SNMPv2 indicates the minimum
  320.           message size which a SNMPv2 implementation must be able to
  321.           produce or consume.  Although implementations are encouraged
  322.           to support larger values whenever possible, a conformant
  323.           implementation must never generate messages larger than
  324.           allowed by the receiving SNMPv2 entity.
  325.  
  326.           One of the aims of the GetBulkRequest-PDU, specified in this
  327.           protocol, is to minimize the number of protocol exchanges
  328.           required to retrieve a large amount of management information.
  329.           As such, this PDU type allows a SNMPv2 entity acting in a
  330.           manager role to request that the response be as large as
  331.           possible given the constraints on message sizes.  These
  332.           constraints include the limits on the size of messages which
  333.           the SNMPv2 entity acting in an agent role can generate, and
  334.           the SNMPv2 entity acting in a manager role can receive.
  335.  
  336.           However, it is possible that such maximum sized messages may
  337.           be larger than the Path MTU of the path across the network
  338.           traversed by the messages.  In this situation, such messages
  339.           are subject to fragmentation.  Fragmentation is generally
  340.           considered to be harmful [6], since among other problems, it
  341.           leads to a decrease in the reliability of the transfer of the
  342.           messages.  Thus, a SNMPv2 entity which sends a
  343.           GetBulkRequest-PDU must take care to set its parameters
  344.           accordingly, so as to reduce the risk of fragmentation.  In
  345.           particular, under conditions of network stress, only small
  346.           values should be used for max-repetitions.
  347.  
  348.  
  349.  
  350.  
  351.  
  352.  
  353.  
  354.           Case, McCloghrie, Rose & Waldbusser                   [Page 5]
  355.  
  356.  
  357.  
  358.  
  359.  
  360.           RFC 1448        Protocol Operations for SNMPv2      April 1993
  361.  
  362.  
  363.           2.6.  Transport Mappings
  364.  
  365.           It is important to note that the exchange of SNMPv2 messages
  366.           requires only an unreliable datagram service, with every
  367.           message being entirely and independently contained in a single
  368.           transport datagram.  Specific transport mappings and encoding
  369.           rules are specified elsewhere [7].  However, the preferred
  370.           mapping is the use of the User Datagram Protocol [8].
  371.  
  372.  
  373.  
  374.  
  375.  
  376.  
  377.  
  378.  
  379.  
  380.  
  381.  
  382.  
  383.  
  384.  
  385.  
  386.  
  387.  
  388.  
  389.  
  390.  
  391.  
  392.  
  393.  
  394.  
  395.  
  396.  
  397.  
  398.  
  399.  
  400.  
  401.  
  402.  
  403.  
  404.  
  405.  
  406.  
  407.  
  408.  
  409.  
  410.  
  411.  
  412.  
  413.           Case, McCloghrie, Rose & Waldbusser                   [Page 6]
  414.  
  415.  
  416.  
  417.  
  418.  
  419.           RFC 1448        Protocol Operations for SNMPv2      April 1993
  420.  
  421.  
  422.           3.  Definitions
  423.  
  424.                SNMPv2-PDU DEFINITIONS ::= BEGIN
  425.  
  426.                IMPORTS
  427.                    ObjectName, ObjectSyntax, Integer32
  428.                        FROM SNMPv2-SMI;
  429.  
  430.  
  431.                -- protocol data units
  432.  
  433.                PDUs ::=
  434.                    CHOICE {
  435.                        get-request
  436.                            GetRequest-PDU,
  437.  
  438.                        get-next-request
  439.                            GetNextRequest-PDU,
  440.  
  441.                        get-bulk-request
  442.                            GetBulkRequest-PDU,
  443.  
  444.                        response
  445.                            Response-PDU,
  446.  
  447.                        set-request
  448.                            SetRequest-PDU,
  449.  
  450.                        inform-request
  451.                            InformRequest-PDU,
  452.  
  453.                        snmpV2-trap
  454.                            SNMPv2-Trap-PDU
  455.                    }
  456.  
  457.  
  458.  
  459.  
  460.  
  461.  
  462.  
  463.  
  464.  
  465.  
  466.  
  467.  
  468.  
  469.  
  470.  
  471.  
  472.           Case, McCloghrie, Rose & Waldbusser                   [Page 7]
  473.  
  474.  
  475.  
  476.  
  477.  
  478.           RFC 1448        Protocol Operations for SNMPv2      April 1993
  479.  
  480.  
  481.                -- PDUs
  482.  
  483.                GetRequest-PDU ::=
  484.                    [0]
  485.                        IMPLICIT PDU
  486.  
  487.                GetNextRequest-PDU ::=
  488.                    [1]
  489.                        IMPLICIT PDU
  490.  
  491.                Response-PDU ::=
  492.                    [2]
  493.                        IMPLICIT PDU
  494.  
  495.                SetRequest-PDU ::=
  496.                    [3]
  497.                        IMPLICIT PDU
  498.  
  499.                -- [4] is obsolete
  500.  
  501.                GetBulkRequest-PDU ::=
  502.                    [5]
  503.                        IMPLICIT BulkPDU
  504.  
  505.                InformRequest-PDU ::=
  506.                    [6]
  507.                        IMPLICIT PDU
  508.  
  509.                SNMPv2-Trap-PDU ::=
  510.                    [7]
  511.                        IMPLICIT PDU
  512.  
  513.  
  514.  
  515.  
  516.  
  517.  
  518.  
  519.  
  520.  
  521.  
  522.  
  523.  
  524.  
  525.  
  526.  
  527.  
  528.  
  529.  
  530.  
  531.           Case, McCloghrie, Rose & Waldbusser                   [Page 8]
  532.  
  533.  
  534.  
  535.  
  536.  
  537.           RFC 1448        Protocol Operations for SNMPv2      April 1993
  538.  
  539.  
  540.                max-bindings
  541.                    INTEGER ::= 2147483647
  542.  
  543.                PDU ::=
  544.                    SEQUENCE {
  545.                        request-id
  546.                            Integer32,
  547.  
  548.                        error-status            -- sometimes ignored
  549.                            INTEGER {
  550.                                noError(0),
  551.                                tooBig(1),
  552.                                noSuchName(2),   -- for proxy compatibility
  553.                                badValue(3),     -- for proxy compatibility
  554.                                readOnly(4),     -- for proxy compatibility
  555.                                genErr(5),
  556.                                noAccess(6),
  557.                                wrongType(7),
  558.                                wrongLength(8),
  559.                                wrongEncoding(9),
  560.                                wrongValue(10),
  561.                                noCreation(11),
  562.                                inconsistentValue(12),
  563.                                resourceUnavailable(13),
  564.                                commitFailed(14),
  565.                                undoFailed(15),
  566.                                authorizationError(16),
  567.                                notWritable(17),
  568.                                inconsistentName(18)
  569.                            },
  570.  
  571.                        error-index            -- sometimes ignored
  572.                            INTEGER (0..max-bindings),
  573.  
  574.                        variable-bindings   -- values are sometimes ignored
  575.                            VarBindList
  576.                    }
  577.  
  578.  
  579.  
  580.  
  581.  
  582.  
  583.  
  584.  
  585.  
  586.  
  587.  
  588.  
  589.  
  590.           Case, McCloghrie, Rose & Waldbusser                   [Page 9]
  591.  
  592.  
  593.  
  594.  
  595.  
  596.           RFC 1448        Protocol Operations for SNMPv2      April 1993
  597.  
  598.  
  599.                BulkPDU ::=                     -- MUST be identical in
  600.                    SEQUENCE {                  -- structure to PDU
  601.                        request-id
  602.                            Integer32,
  603.  
  604.                        non-repeaters
  605.                            INTEGER (0..max-bindings),
  606.  
  607.                        max-repetitions
  608.                            INTEGER (0..max-bindings),
  609.  
  610.                        variable-bindings       -- values are ignored
  611.                            VarBindList
  612.                    }
  613.  
  614.  
  615.  
  616.  
  617.  
  618.  
  619.  
  620.  
  621.  
  622.  
  623.  
  624.  
  625.  
  626.  
  627.  
  628.  
  629.  
  630.  
  631.  
  632.  
  633.  
  634.  
  635.  
  636.  
  637.  
  638.  
  639.  
  640.  
  641.  
  642.  
  643.  
  644.  
  645.  
  646.  
  647.  
  648.  
  649.           Case, McCloghrie, Rose & Waldbusser                  [Page 10]
  650.  
  651.  
  652.  
  653.  
  654.  
  655.           RFC 1448        Protocol Operations for SNMPv2      April 1993
  656.  
  657.  
  658.                -- variable binding
  659.  
  660.                VarBind ::=
  661.                    SEQUENCE {
  662.                        name
  663.                            ObjectName,
  664.  
  665.                        CHOICE {
  666.                            value
  667.                                ObjectSyntax,
  668.  
  669.                            unSpecified         -- in retrieval requests
  670.                                    NULL,
  671.  
  672.                                                -- exceptions in responses
  673.                            noSuchObject[0]
  674.                                    IMPLICIT NULL,
  675.  
  676.                            noSuchInstance[1]
  677.                                    IMPLICIT NULL,
  678.  
  679.                            endOfMibView[2]
  680.                                    IMPLICIT NULL
  681.                        }
  682.                    }
  683.  
  684.  
  685.                -- variable-binding list
  686.  
  687.                VarBindList ::=
  688.                    SEQUENCE (SIZE (0..max-bindings)) OF
  689.                        VarBind
  690.  
  691.  
  692.                END
  693.  
  694.  
  695.  
  696.  
  697.  
  698.  
  699.  
  700.  
  701.  
  702.  
  703.  
  704.  
  705.  
  706.  
  707.  
  708.           Case, McCloghrie, Rose & Waldbusser                  [Page 11]
  709.  
  710.  
  711.  
  712.  
  713.  
  714.           RFC 1448        Protocol Operations for SNMPv2      April 1993
  715.  
  716.  
  717.           4.  Protocol Specification
  718.  
  719.  
  720.           4.1.  Common Constructs
  721.  
  722.           The value of the request-id field in a Response-PDU takes the
  723.           value of the request-id field in the request PDU to which it
  724.           is a response.  By use of the request-id value, a SNMPv2
  725.           application can distinguish the (potentially multiple)
  726.           outstanding requests, and thereby correlate incoming responses
  727.           with outstanding requests.  In cases where an unreliable
  728.           datagram service is used, the request-id also provides a
  729.           simple means of identifying messages duplicated by the
  730.           network.  Use of the same request-id on a retransmission of a
  731.           request allows the response to either the original
  732.           transmission or the retransmission to satisfy the request.
  733.           However, in order to calculate the round trip time for
  734.           transmission and processing of a request-response transaction,
  735.           the SNMPv2 application needs to use a different request-id
  736.           value on a retransmitted request.  The latter strategy is
  737.           recommended for use in the majority of situations.
  738.  
  739.           A non-zero value of the error-status field in a Response-PDU
  740.           is used to indicate that an exception occurred to prevent the
  741.           processing of the request.  In these cases, a non-zero value
  742.           of the Response-PDU's error-index field provides additional
  743.           information by identifying which variable binding in the list
  744.           caused the exception.  A variable binding is identified by its
  745.           index value.  The first variable binding in a variable-binding
  746.           list is index one, the second is index two, etc.
  747.  
  748.           SNMPv2 limits OBJECT IDENTIFIER values to a maximum of 128
  749.           sub-identifiers, where each sub-identifier has a maximum value
  750.           of 2**32-1.
  751.  
  752.  
  753.           4.2.  PDU Processing
  754.  
  755.           It is mandatory that all SNMPv2 entities acting in an agent
  756.           role be able to generate the following PDU types: Response-PDU
  757.           and SNMPv2-Trap-PDU; further, all such implementations must be
  758.           able to receive the following PDU types: GetRequest-PDU,
  759.           GetNextRequest-PDU, GetBulkRequest-PDU, and SetRequest-PDU.
  760.  
  761.  
  762.  
  763.  
  764.  
  765.  
  766.  
  767.           Case, McCloghrie, Rose & Waldbusser                  [Page 12]
  768.  
  769.  
  770.  
  771.  
  772.  
  773.           RFC 1448        Protocol Operations for SNMPv2      April 1993
  774.  
  775.  
  776.           It is mandatory that all SNMPv2 entities acting in a manager
  777.           role be able to generate the following PDU types: GetRequest-
  778.           PDU, GetNextRequest-PDU, GetBulkRequest-PDU, SetRequest-PDU,
  779.           InformRequest-PDU, and Response-PDU; further, all such
  780.           implementations must be able to receive the following PDU
  781.           types: Response-PDU, SNMPv2-Trap-PDU, InformRequest-PDU;
  782.  
  783.           In the elements of procedure below, any field of a PDU which
  784.           is not referenced by the relevant procedure is ignored by the
  785.           receiving SNMPv2 entity.  However, all components of a PDU,
  786.           including those whose values are ignored by the receiving
  787.           SNMPv2 entity, must have valid ASN.1 syntax and encoding.  For
  788.           example, some PDUs (e.g., the GetRequest-PDU) are concerned
  789.           only with the name of a variable and not its value.  In this
  790.           case, the value portion of the variable binding is ignored by
  791.           the receiving SNMPv2 entity.  The unSpecified value is defined
  792.           for use as the value portion of such bindings.
  793.  
  794.           For all generated PDUs, the message "wrapper" to encapsulate
  795.           the PDU is generated and transmitted as specified in [3].  The
  796.           size of a message is limited only by constraints on the
  797.           maximum message size, either a local limitation or the limit
  798.           associated with the message's destination party, i.e., it is
  799.           not limited by the number of variable bindings.
  800.  
  801.           On receiving a management communication, the procedures
  802.           defined in Section 3.2 of [3] are followed.  If these
  803.           procedures indicate that the PDU contained within the message
  804.           "wrapper" is to be processed, then the SNMPv2 context
  805.           associated with the PDU defines the object resources which are
  806.           visible to the operation.
  807.  
  808.  
  809.           4.2.1.  The GetRequest-PDU
  810.  
  811.           A GetRequest-PDU is generated and transmitted at the request
  812.           of a SNMPv2 application.
  813.  
  814.           Upon receipt of a GetRequest-PDU, the receiving SNMPv2 entity
  815.           processes each variable binding in the variable-binding list
  816.           to produce a Response-PDU.  All fields of the Response-PDU
  817.           have the same values as the corresponding fields of the
  818.           received request except as indicated below.  Each variable
  819.           binding is processed as follows:
  820.  
  821.  
  822.  
  823.  
  824.  
  825.  
  826.           Case, McCloghrie, Rose & Waldbusser                  [Page 13]
  827.  
  828.  
  829.  
  830.  
  831.  
  832.           RFC 1448        Protocol Operations for SNMPv2      April 1993
  833.  
  834.  
  835.           (1)  If the variable binding's name does not have an OBJECT
  836.                IDENTIFIER prefix which exactly matches the OBJECT
  837.                IDENTIFIER prefix of any variable accessible by this
  838.                request, then its value field is set to `noSuchObject'.
  839.  
  840.           (2)  Otherwise, if the variable binding's name does not
  841.                exactly match the name of a variable accessible by this
  842.                request, then its value field is set to `noSuchInstance'.
  843.  
  844.           (3)  Otherwise, the variable binding's value field is set to
  845.                the value of the named variable.
  846.  
  847.           If the processing of any variable binding fails for a reason
  848.           other than listed above, then the Response-PDU is re-formatted
  849.           with the same values in its request-id and variable-bindings
  850.           fields as the received GetRequest-PDU, with the value of its
  851.           error-status field set to `genErr', and the value of its
  852.           error-index field is set to the index of the failed variable
  853.           binding.
  854.  
  855.           Otherwise, the value of the Response-PDU's error-status field
  856.           is set to `noError', and the value of its error-index field is
  857.           zero.
  858.  
  859.           The generated Response-PDU is then encapsulated into a
  860.           message.  If the size of the resultant message is less than or
  861.           equal to both a local constraint and the maximum message size
  862.           of the request's source party, it is transmitted to the
  863.           originator of the GetRequest-PDU.
  864.  
  865.           Otherwise, an alternate Response-PDU is generated.  This
  866.           alternate Response-PDU is formatted with the same value in its
  867.           request-id field as the received GetRequest-PDU, with the
  868.           value of its error-status field set to `tooBig', the value of
  869.           its error-index field set to zero, and an empty variable-
  870.           bindings field.  This alternate Response-PDU is then
  871.           encapsulated into a message.  If the size of the resultant
  872.           message is less than or equal to both a local constraint and
  873.           the maximum message size of the request's source party, it is
  874.           transmitted to the originator of the GetRequest-PDU.
  875.           Otherwise, the resultant message is discarded.
  876.  
  877.  
  878.  
  879.  
  880.  
  881.  
  882.  
  883.  
  884.  
  885.           Case, McCloghrie, Rose & Waldbusser                  [Page 14]
  886.  
  887.  
  888.  
  889.  
  890.  
  891.           RFC 1448        Protocol Operations for SNMPv2      April 1993
  892.  
  893.  
  894.           4.2.2.  The GetNextRequest-PDU
  895.  
  896.           A GetNextRequest-PDU is generated and transmitted at the
  897.           request of a SNMPv2 application.
  898.  
  899.           Upon receipt of a GetNextRequest-PDU, the receiving SNMPv2
  900.           entity processes each variable binding in the variable-binding
  901.           list to produce a Response-PDU.  All fields of the Response-
  902.           PDU have the same values as the corresponding fields of the
  903.           received request except as indicated below.  Each variable
  904.           binding is processed as follows:
  905.  
  906.           (1)  The variable is located which is in the lexicographically
  907.                ordered list of the names of all variables which are
  908.                accessible by this request and whose name is the first
  909.                lexicographic successor of the variable binding's name in
  910.                the incoming GetNextRequest-PDU.  The corresponding
  911.                variable binding's name and value fields in the
  912.                Response-PDU are set to the name and value of the located
  913.                variable.
  914.  
  915.           (2)  If the requested variable binding's name does not
  916.                lexicographically precede the name of any variable
  917.                accessible by this request, i.e., there is no
  918.                lexicographic successor, then the corresponding variable
  919.                binding produced in the Response-PDU has its value field
  920.                set to 'endOfMibView', and its name field set to the
  921.                variable binding's name in the request.
  922.  
  923.           If the processing of any variable binding fails for a reason
  924.           other than listed above, then the Response-PDU is re-formatted
  925.           with the same values in its request-id and variable-bindings
  926.           fields as the received GetNextRequest-PDU, with the value of
  927.           its error-status field set to `genErr', and the value of its
  928.           error-index field is set to the index of the failed variable
  929.           binding.
  930.  
  931.           Otherwise, the value of the Response-PDU's error-status field
  932.           is set to `noError', and the value of its error-index field is
  933.           zero.
  934.  
  935.           The generated Response-PDU is then encapsulated into a
  936.           message.  If the size of the resultant message is less than or
  937.           equal to both a local constraint and the maximum message size
  938.           of the request's source party, it is transmitted to the
  939.  
  940.  
  941.  
  942.  
  943.  
  944.           Case, McCloghrie, Rose & Waldbusser                  [Page 15]
  945.  
  946.  
  947.  
  948.  
  949.  
  950.           RFC 1448        Protocol Operations for SNMPv2      April 1993
  951.  
  952.  
  953.           originator of the GetNextRequest-PDU.
  954.  
  955.           Otherwise, an alternate Response-PDU is generated.  This
  956.           alternate Response-PDU is formatted with the same values in
  957.           its request-id field as the received GetNextRequest-PDU, with
  958.           the value of its error-status field set to `tooBig', the value
  959.           of its error-index field set to zero, and an empty variable-
  960.           bindings field.  This alternate Response-PDU is then
  961.           encapsulated into a message.  If the size of the resultant
  962.           message is less than or equal to both a local constraint and
  963.           the maximum message size of the request's source party, it is
  964.           transmitted to the originator of the GetNextRequest-PDU.
  965.           Otherwise, the resultant message is discarded.
  966.  
  967.  
  968.           4.2.2.1.  Example of Table Traversal
  969.  
  970.           An important use of the GetNextRequest-PDU is the traversal of
  971.           conceptual tables of information within a MIB.  The semantics
  972.           of this type of request, together with the method of
  973.           identifying individual instances of objects in the MIB,
  974.           provides access to related objects in the MIB as if they
  975.           enjoyed a tabular organization.
  976.  
  977.           In the protocol exchange sketched below, a SNMPv2 application
  978.           retrieves the media-dependent physical address and the
  979.           address-mapping type for each entry in the IP net-to-media
  980.           Address Translation Table [9] of a particular network element.
  981.           It also retrieves the value of sysUpTime [9], at which the
  982.           mappings existed.  Suppose that the agent's IP net-to-media
  983.           table has three entries:
  984.  
  985.             Interface-Number  Network-Address  Physical-Address  Type
  986.  
  987.                    1            10.0.0.51     00:00:10:01:23:45  static
  988.                    1             9.2.3.4      00:00:10:54:32:10  dynamic
  989.                    2            10.0.0.15     00:00:10:98:76:54  dynamic
  990.  
  991.           The SNMPv2 entity acting in a manager role begins by sending a
  992.           GetNextRequest-PDU containing the indicated OBJECT IDENTIFIER
  993.           values as the requested variable names:
  994.  
  995.               GetNextRequest ( sysUpTime,
  996.                                ipNetToMediaPhysAddress,
  997.                                ipNetToMediaType )
  998.  
  999.  
  1000.  
  1001.  
  1002.  
  1003.           Case, McCloghrie, Rose & Waldbusser                  [Page 16]
  1004.  
  1005.  
  1006.  
  1007.  
  1008.  
  1009.           RFC 1448        Protocol Operations for SNMPv2      April 1993
  1010.  
  1011.  
  1012.           The SNMPv2 entity acting in an agent role responds with a
  1013.           Response-PDU:
  1014.  
  1015.               Response (( sysUpTime.0 =  "123456" ),
  1016.                         ( ipNetToMediaPhysAddress.1.9.2.3.4 =
  1017.                                                    "000010543210" ),
  1018.                         ( ipNetToMediaType.1.9.2.3.4 =  "dynamic" ))
  1019.  
  1020.           The SNMPv2 entity acting in a manager role continues with:
  1021.  
  1022.               GetNextRequest ( sysUpTime,
  1023.                                ipNetToMediaPhysAddress.1.9.2.3.4,
  1024.                                ipNetToMediaType.1.9.2.3.4 )
  1025.  
  1026.           The SNMPv2 entity acting in an agent role responds with:
  1027.  
  1028.               Response (( sysUpTime.0 =  "123461" ),
  1029.                         ( ipNetToMediaPhysAddress.1.10.0.0.51 =
  1030.                                                     "000010012345" ),
  1031.                         ( ipNetToMediaType.1.10.0.0.51 =  "static" ))
  1032.  
  1033.           The SNMPv2 entity acting in a manager role continues with:
  1034.  
  1035.               GetNextRequest ( sysUpTime,
  1036.                                ipNetToMediaPhysAddress.1.10.0.0.51,
  1037.                                ipNetToMediaType.1.10.0.0.51 )
  1038.  
  1039.           The SNMPv2 entity acting in an agent role responds with:
  1040.  
  1041.               Response (( sysUpTime.0 =  "123466" ),
  1042.                         ( ipNetToMediaPhysAddress.2.10.0.0.15 =
  1043.                                                      "000010987654" ),
  1044.                         ( ipNetToMediaType.2.10.0.0.15 =  "dynamic" ))
  1045.  
  1046.           The SNMPv2 entity acting in a manager role continues with:
  1047.  
  1048.               GetNextRequest ( sysUpTime,
  1049.                                ipNetToMediaPhysAddress.2.10.0.0.15,
  1050.                                ipNetToMediaType.2.10.0.0.15 )
  1051.  
  1052.           As there are no further entries in the table, the SNMPv2
  1053.           entity acting in an agent role responds with the variables
  1054.           that are next in the lexicographical ordering of the
  1055.           accessible object names, for example:
  1056.  
  1057.  
  1058.  
  1059.  
  1060.  
  1061.  
  1062.           Case, McCloghrie, Rose & Waldbusser                  [Page 17]
  1063.  
  1064.  
  1065.  
  1066.  
  1067.  
  1068.           RFC 1448        Protocol Operations for SNMPv2      April 1993
  1069.  
  1070.  
  1071.               Response (( sysUpTime.0 =  "123471" ),
  1072.                         ( ipNetToMediaNetAddress.1.9.2.3.4 =
  1073.                                                          "9.2.3.4" ),
  1074.                         ( ipRoutingDiscards.0 =  "2" ))
  1075.  
  1076.           This response signals the end of the table to the SNMPv2
  1077.           entity acting in a manager role.
  1078.  
  1079.  
  1080.           4.2.3.  The GetBulkRequest-PDU
  1081.  
  1082.           A GetBulkRequest-PDU is generated and transmitted at the
  1083.           request of a SNMPv2 application.  The purpose of the
  1084.           GetBulkRequest-PDU is to request the transfer of a potentially
  1085.           large amount of data, including, but not limited to, the
  1086.           efficient and rapid retrieval of large tables.
  1087.  
  1088.           Upon receipt of a GetBulkRequest-PDU, the receiving SNMPv2
  1089.           entity processes each variable binding in the variable-binding
  1090.           list to produce a Response-PDU with its request-id field
  1091.           having the same value as in the request.  Processing begins by
  1092.           examining the values in the non-repeaters and max-repetitions
  1093.           fields.  If the value in the non-repeaters field is less than
  1094.           zero, then the value of the field is set to zero.  Similarly,
  1095.           if the value in the max-repetitions field is less than zero,
  1096.           then the value of the field is set to zero.
  1097.  
  1098.           For the GetBulkRequest-PDU type, the successful processing of
  1099.           each variable binding in the request generates zero or more
  1100.           variable bindings in the Response-PDU.  That is, the one-to-
  1101.           one mapping between the variable bindings of the GetRequest-
  1102.           PDU, GetNextRequest-PDU, and SetRequest-PDU types and the
  1103.           resultant Response-PDUs does not apply for the mapping between
  1104.           the variable bindings of a GetBulkRequest-PDU and the
  1105.           resultant Response-PDU.
  1106.  
  1107.           The values of the non-repeaters and max-repetitions fields in
  1108.           the request specify the processing requested.  One variable
  1109.           binding in the Response-PDU is requested for the first N
  1110.           variable bindings in the request and M variable bindings are
  1111.           requested for each of the R remaining variable bindings in the
  1112.           request.  Consequently, the total number of requested variable
  1113.           bindings communicated by the request is given by N + (M * R),
  1114.           where N is the minimum of: a) the value of the non-repeaters
  1115.           field in the request, and b) the number of variable bindings
  1116.  
  1117.  
  1118.  
  1119.  
  1120.  
  1121.           Case, McCloghrie, Rose & Waldbusser                  [Page 18]
  1122.  
  1123.  
  1124.  
  1125.  
  1126.  
  1127.           RFC 1448        Protocol Operations for SNMPv2      April 1993
  1128.  
  1129.  
  1130.           in the request; M is the value of the max-repetitions field in
  1131.           the request; and R is the maximum of: a) number of variable
  1132.           bindings in the request - N, and b)  zero.
  1133.  
  1134.           The receiving SNMPv2 entity produces a Response-PDU with up to
  1135.           the total number of requested variable bindings communicated
  1136.           by the request.  The request-id shall have the same value as
  1137.           the received GetBulkRequest-PDU.
  1138.  
  1139.           If N is greater than zero, the first through the (N)-th
  1140.           variable bindings of the Response-PDU are each produced as
  1141.           follows:
  1142.  
  1143.           (1)  The variable is located which is in the lexicographically
  1144.                ordered list of the names of all variables which are
  1145.                accessible by this request and whose name is the first
  1146.                lexicographic successor of the variable binding's name in
  1147.                the incoming GetBulkRequest-PDU.  The corresponding
  1148.                variable binding's name and value fields in the
  1149.                Response-PDU are set to the name and value of the located
  1150.                variable.
  1151.  
  1152.           (2)  If the requested variable binding's name does not
  1153.                lexicographically precede the name of any variable
  1154.                accessible by this request, i.e., there is no
  1155.                lexicographic successor, then the corresponding variable
  1156.                binding produced in the Response-PDU has its value field
  1157.                set to `endOfMibView', and its name field set to the
  1158.                variable binding's name in the request.
  1159.  
  1160.           If M and R are non-zero, the (N + 1)-th and subsequent
  1161.           variable bindings of the Response-PDU are each produced in a
  1162.           similar manner.  For each iteration i, such that i is greater
  1163.           than zero and less than or equal to M, and for each repeated
  1164.           variable, r, such that r is greater than zero and less than or
  1165.           equal to R, the (N + ( (i-1) * R ) + r)-th variable binding of
  1166.           the Response-PDU is produced as follows:
  1167.  
  1168.           (1)  The variable which is in the lexicographically ordered
  1169.                list of the names of all variables which are accessible
  1170.                by this request and whose name is the (i)-th
  1171.                lexicographic successor of the (N + r)-th variable
  1172.                binding's name in the incoming GetBulkRequest-PDU is
  1173.                located and the variable binding's name and value fields
  1174.                are set to the name and value of the located variable.
  1175.  
  1176.  
  1177.  
  1178.  
  1179.  
  1180.           Case, McCloghrie, Rose & Waldbusser                  [Page 19]
  1181.  
  1182.  
  1183.  
  1184.  
  1185.  
  1186.           RFC 1448        Protocol Operations for SNMPv2      April 1993
  1187.  
  1188.  
  1189.           (2)  If there is no (i)-th lexicographic successor, then the
  1190.                corresponding variable binding produced in the Response-
  1191.                PDU has its value field set to `endOfMibView', and its
  1192.                name field set to either the last lexicographic
  1193.                successor, or if there are no lexicographic successors,
  1194.                to the (N + r)-th variable binding's name in the request.
  1195.  
  1196.           While the maximum number of variable bindings in the
  1197.           Response-PDU is bounded by N + (M * R), the response may be
  1198.           generated with a lesser number of variable bindings (possibly
  1199.           zero) for either of two reasons.
  1200.  
  1201.           (1)  If the size of the message encapsulating the Response-PDU
  1202.                containing the requested number of variable bindings
  1203.                would be greater than either a local constraint or the
  1204.                maximum message size of the request's source party, then
  1205.                the response is generated with a lesser number of
  1206.                variable bindings.  This lesser number is the ordered set
  1207.                of variable bindings with some of the variable bindings
  1208.                at the end of the set removed, such that the size of the
  1209.                message encapsulating the Response-PDU is approximately
  1210.                equal to but no greater than the minimum of the local
  1211.                constraint and the maximum message size of the request's
  1212.                source party.  Note that the number of variable bindings
  1213.                removed has no relationship to the values of N, M, or R.
  1214.  
  1215.           (2)  The response may also be generated with a lesser number
  1216.                of variable bindings if for some value of iteration i,
  1217.                such that i is greater than zero and less than or equal
  1218.                to M, that all of the generated variable bindings have
  1219.                the value field set to the `endOfMibView'.  In this case,
  1220.                the variable bindings may be truncated after the (N + (i
  1221.                * R))-th variable binding.
  1222.  
  1223.           If the processing of any variable binding fails for a reason
  1224.           other than listed above, then the Response-PDU is re-formatted
  1225.           with the same values in its request-id and variable-bindings
  1226.           fields as the received GetBulkRequest-PDU, with the value of
  1227.           its error-status field set to `genErr', and the value of its
  1228.           error-index field is set to the index of the failed variable
  1229.           binding.
  1230.  
  1231.           Otherwise, the value of the Response-PDU's error-status field
  1232.           is set to `noError', and the value of its error-index field to
  1233.           zero.
  1234.  
  1235.  
  1236.  
  1237.  
  1238.  
  1239.           Case, McCloghrie, Rose & Waldbusser                  [Page 20]
  1240.  
  1241.  
  1242.  
  1243.  
  1244.  
  1245.           RFC 1448        Protocol Operations for SNMPv2      April 1993
  1246.  
  1247.  
  1248.           The generated Response-PDU (possibly with an empty variable-
  1249.           bindings field) is then encapsulated into a message.  If the
  1250.           size of the resultant message is less than or equal to both a
  1251.           local constraint and the maximum message size of the request's
  1252.           source party, it is transmitted to the originator of the
  1253.           GetBulkRequest-PDU.  Otherwise, the resultant message is
  1254.           discarded.
  1255.  
  1256.  
  1257.           4.2.3.1.  Another Example of Table Traversal
  1258.  
  1259.           This example demonstrates how the GetBulkRequest-PDU can be
  1260.           used as an alternative to the GetNextRequest-PDU.  The same
  1261.           traversal of the IP net-to-media table as shown in Section
  1262.           4.2.2.1 is achieved with fewer exchanges.
  1263.  
  1264.           The SNMPv2 entity acting in a manager role begins by sending a
  1265.           GetBulkRequest-PDU with the modest max-repetitions value of 2,
  1266.           and containing the indicated OBJECT IDENTIFIER values as the
  1267.           requested variable names:
  1268.  
  1269.               GetBulkRequest [ non-repeaters = 1, max-repetitions = 2 ]
  1270.                               ( sysUpTime,
  1271.                                 ipNetToMediaPhysAddress,
  1272.                                 ipNetToMediaType )
  1273.  
  1274.           The SNMPv2 entity acting in an agent role responds with a
  1275.           Response-PDU:
  1276.  
  1277.               Response (( sysUpTime.0 =  "123456" ),
  1278.                         ( ipNetToMediaPhysAddress.1.9.2.3.4 =
  1279.                                                    "000010543210" ),
  1280.                         ( ipNetToMediaType.1.9.2.3.4 =  "dynamic" ),
  1281.                         ( ipNetToMediaPhysAddress.1.10.0.0.51 =
  1282.                                                     "000010012345" ),
  1283.                         ( ipNetToMediaType.1.10.0.0.51 =  "static" ))
  1284.  
  1285.           The SNMPv2 entity acting in a manager role continues with:
  1286.  
  1287.               GetBulkRequest [ non-repeaters = 1, max-repetitions = 2 ]
  1288.                               ( sysUpTime,
  1289.                                 ipNetToMediaPhysAddress.1.10.0.0.51,
  1290.                                 ipNetToMediaType.1.10.0.0.51 )
  1291.  
  1292.  
  1293.  
  1294.  
  1295.  
  1296.  
  1297.  
  1298.           Case, McCloghrie, Rose & Waldbusser                  [Page 21]
  1299.  
  1300.  
  1301.  
  1302.  
  1303.  
  1304.           RFC 1448        Protocol Operations for SNMPv2      April 1993
  1305.  
  1306.  
  1307.           The SNMPv2 entity acting in an agent role responds with:
  1308.  
  1309.               Response (( sysUpTime.0 =  "123466" ),
  1310.                         ( ipNetToMediaPhysAddress.2.10.0.0.15 =
  1311.                                                    "000010987654" ),
  1312.                         ( ipNetToMediaType.2.10.0.0.15 =
  1313.                                                         "dynamic" ),
  1314.                         ( ipNetToMediaNetAddress.1.9.2.3.4 =
  1315.                                                         "9.2.3.4" ),
  1316.                         ( ipRoutingDiscards.0 =  "2" ))
  1317.  
  1318.           This response signals the end of the table to the SNMPv2
  1319.           entity acting in a manager role.
  1320.  
  1321.  
  1322.           4.2.4.  The Response-PDU
  1323.  
  1324.           The Response-PDU is generated by a SNMPv2 entity only upon
  1325.           receipt of a GetRequest-PDU, GetNextRequest-PDU,
  1326.           GetBulkRequest-PDU, SetRequest-PDU, or InformRequest-PDU, as
  1327.           described elsewhere in this document.
  1328.  
  1329.           If the error-status field of the Response-PDU is non-zero, the
  1330.           value fields of the variable bindings in the variable binding
  1331.           list are ignored.
  1332.  
  1333.           If both the error-status field and the error-index field of
  1334.           the Response-PDU are non-zero, then the value of the error-
  1335.           index field is the index of the variable binding (in the
  1336.           variable-binding list of the corresponding request) for which
  1337.           the request failed.  The first variable binding in a request's
  1338.           variable-binding list is index one, the second is index two,
  1339.           etc.
  1340.  
  1341.           A compliant SNMPv2 entity acting in a manager role must be
  1342.           able to properly receive and handle a Response-PDU with an
  1343.           error-status field equal to `noSuchName', `badValue', or
  1344.           `readOnly'.  (See Section 3.1.2 of [10].)
  1345.  
  1346.           Upon receipt of a Response-PDU, the receiving SNMPv2 entity
  1347.           presents its contents to the SNMPv2 application which
  1348.           generated the request with the same request-id value.
  1349.  
  1350.  
  1351.  
  1352.  
  1353.  
  1354.  
  1355.  
  1356.  
  1357.           Case, McCloghrie, Rose & Waldbusser                  [Page 22]
  1358.  
  1359.  
  1360.  
  1361.  
  1362.  
  1363.           RFC 1448        Protocol Operations for SNMPv2      April 1993
  1364.  
  1365.  
  1366.           4.2.5.  The SetRequest-PDU
  1367.  
  1368.           A SetRequest-PDU is generated and transmitted at the request
  1369.           of a SNMPv2 application.
  1370.  
  1371.           Upon receipt of a SetRequest-PDU, the receiving SNMPv2 entity
  1372.           determines the size of a message encapsulating a Response-PDU
  1373.           with the same values in its request-id, error-status, error-
  1374.           index and variable-bindings fields as the received
  1375.           SetRequest-PDU.  If the determined message size is greater
  1376.           than either a local constraint or the maximum message size of
  1377.           the request's source party, then an alternate Response-PDU is
  1378.           generated, transmitted to the originator of the SetRequest-
  1379.           PDU, and processing of the SetRequest-PDU terminates
  1380.           immediately thereafter.  This alternate Response-PDU is
  1381.           formatted with the same values in its request-id field as the
  1382.           received SetRequest-PDU, with the value of its error-status
  1383.           field set to `tooBig', the value of its error-index field set
  1384.           to zero, and an empty variable-bindings field.  This alternate
  1385.           Response-PDU is then encapsulated into a message.  If the size
  1386.           of the resultant message is less than or equal to both a local
  1387.           constraint and the maximum message size of the request's
  1388.           source party, it is transmitted to the originator of the
  1389.           SetRequest-PDU.  Otherwise, the resultant message is
  1390.           discarded.  Regardless, processing of the SetRequest-PDU
  1391.           terminates.
  1392.  
  1393.           Otherwise, the receiving SNMPv2 entity processes each variable
  1394.           binding in the variable-binding list to produce a Response-
  1395.           PDU.  All fields of the Response-PDU have the same values as
  1396.           the corresponding fields of the received request except as
  1397.           indicated below.
  1398.  
  1399.           The variable bindings are conceptually processed as a two
  1400.           phase operation.  In the first phase, each variable binding is
  1401.           validated; if all validations are successful, then each
  1402.           variable is altered in the second phase.  Of course,
  1403.           implementors are at liberty to implement either the first, or
  1404.           second, or both, of the these conceptual phases as multiple
  1405.           implementation phases.  Indeed, such multiple implementation
  1406.           phases may be necessary in some cases to ensure consistency.
  1407.  
  1408.           The following validations are performed in the first phase on
  1409.           each variable binding until they are all successful, or until
  1410.           one fails:
  1411.  
  1412.  
  1413.  
  1414.  
  1415.  
  1416.           Case, McCloghrie, Rose & Waldbusser                  [Page 23]
  1417.  
  1418.  
  1419.  
  1420.  
  1421.  
  1422.           RFC 1448        Protocol Operations for SNMPv2      April 1993
  1423.  
  1424.  
  1425.           (1)  If the variable binding's name specifies a variable which
  1426.                is not accessible by this request, then the value of the
  1427.                Response-PDU's error-status field is set to `noAccess',
  1428.                and the value of its error-index field is set to the
  1429.                index of the failed variable binding.
  1430.  
  1431.           (2)  Otherwise, if the variable binding's name specifies a
  1432.                variable which does not exist and could not ever be
  1433.                created, then the value of the Response-PDU's error-
  1434.                status field is set to `noCreation', and the value of its
  1435.                error-index field is set to the index of the failed
  1436.                variable binding.
  1437.  
  1438.           (3)  Otherwise, if the variable binding's name specifies a
  1439.                variable which exists but can not be modified no matter
  1440.                what new value is specified, then the value of the
  1441.                Response-PDU's error-status field is set to
  1442.                `notWritable', and the value of its error-index field is
  1443.                set to the index of the failed variable binding.
  1444.  
  1445.           (4)  Otherwise, if the variable binding's value field
  1446.                specifies, according to the ASN.1 language, a type which
  1447.                is inconsistent with that required for the variable, then
  1448.                the value of the Response-PDU's error-status field is set
  1449.                to `wrongType', and the value of its error-index field is
  1450.                set to the index of the failed variable binding.
  1451.  
  1452.           (5)  Otherwise, if the variable binding's value field
  1453.                specifies, according to the ASN.1 language, a length
  1454.                which is inconsistent with that required for the
  1455.                variable, then the value of the Response-PDU's error-
  1456.                status field is set to `wrongLength', and the value of
  1457.                its error-index field is set to the index of the failed
  1458.                variable binding.
  1459.  
  1460.           (6)  Otherwise, if the variable binding's value field contains
  1461.                an ASN.1 encoding which is inconsistent with that field's
  1462.                ASN.1 tag, then: the value of the Response-PDU's error-
  1463.                status field is set to `wrongEncoding', and the value of
  1464.                its error-index field is set to the index of the failed
  1465.                variable binding.
  1466.  
  1467.           (7)  Otherwise, if the variable binding's value field
  1468.                specifies a value which could under no circumstances be
  1469.                assigned to the variable, then: the value of the
  1470.  
  1471.  
  1472.  
  1473.  
  1474.  
  1475.           Case, McCloghrie, Rose & Waldbusser                  [Page 24]
  1476.  
  1477.  
  1478.  
  1479.  
  1480.  
  1481.           RFC 1448        Protocol Operations for SNMPv2      April 1993
  1482.  
  1483.  
  1484.                Response-PDU's error-status field is set to `wrongValue',
  1485.                and the value of its error-index field is set to the
  1486.                index of the failed variable binding.
  1487.  
  1488.           (8)  Otherwise, if the variable binding's name specifies a
  1489.                variable which does not exist but can not be created not
  1490.                under the present circumstances (even though it could be
  1491.                created under other circumstances), then the value of the
  1492.                Response-PDU's error-status field is set to
  1493.                `inconsistentName', and the value of its error-index
  1494.                field is set to the index of the failed variable binding.
  1495.  
  1496.           (9)  Otherwise, if the variable binding's value field
  1497.                specifies a value that could under other circumstances be
  1498.                assigned to the variable, but is presently inconsistent,
  1499.                then the value of the Response-PDU's error-status field
  1500.                is set to `inconsistentValue', and the value of its
  1501.                error-index field is set to the index of the failed
  1502.                variable binding.
  1503.  
  1504.           (10) Otherwise, if the assignment of the value specified by
  1505.                the variable binding's value field to the specified
  1506.                variable requires the allocation of a resource which is
  1507.                presently unavailable, then: the value of the Response-
  1508.                PDU's error-status field is set to `resourceUnavailable',
  1509.                and the value of its error-index field is set to the
  1510.                index of the failed variable binding.
  1511.  
  1512.           (11) If the processing of the variable binding fails for a
  1513.                reason other than listed above, then the value of the
  1514.                Response-PDU's error-status field is set to `genErr', and
  1515.                the value of its error-index field is set to the index of
  1516.                the failed variable binding.
  1517.  
  1518.           (12) Otherwise, the validation of the variable binding
  1519.                succeeds.
  1520.  
  1521.           At the end of the first phase, if the validation of all
  1522.           variable bindings succeeded, then:
  1523.  
  1524.           The value of the Response-PDU's error-status field is set to
  1525.           `noError' and the value of its error-index field is zero.
  1526.  
  1527.           For each variable binding in the request, the named variable
  1528.           is created if necessary, and the specified value is assigned
  1529.  
  1530.  
  1531.  
  1532.  
  1533.  
  1534.           Case, McCloghrie, Rose & Waldbusser                  [Page 25]
  1535.  
  1536.  
  1537.  
  1538.  
  1539.  
  1540.           RFC 1448        Protocol Operations for SNMPv2      April 1993
  1541.  
  1542.  
  1543.           to it.  Each of these variable assignments occurs as if
  1544.           simultaneously with respect to all other assignments specified
  1545.           in the same request.  However, if the same variable is named
  1546.           more than once in a single request, with different associated
  1547.           values, then the actual assignment made to that variable is
  1548.           implementation-specific.
  1549.  
  1550.           If any of these assignments fail (even after all the previous
  1551.           validations), then all other assignments are undone, and the
  1552.           Response-PDU is modified to have the value of its error-status
  1553.           field set to `commitFailed', and the value of its error-index
  1554.           field set to the index of the failed variable binding.
  1555.  
  1556.           If and only if it is not possible to undo all the assignments,
  1557.           then the Response-PDU is modified to have the value of its
  1558.           error-status field set to `undoFailed', and the value of its
  1559.           error-index field is set to zero.  Note that implementations
  1560.           are strongly encouraged to take all possible measures to avoid
  1561.           use of either `commitFailed' or `undoFailed' - these two
  1562.           error-status codes are not to be taken as license to take the
  1563.           easy way out in an implementation.
  1564.  
  1565.           Finally, the generated Response-PDU is encapsulated into a
  1566.           message, and transmitted to the originator of the SetRequest-
  1567.           PDU.
  1568.  
  1569.  
  1570.           4.2.6.  The SNMPv2-Trap-PDU
  1571.  
  1572.           A SNMPv2-Trap-PDU is generated and transmitted by a SNMPv2
  1573.           entity acting in an agent role when an exceptional situation
  1574.           occurs.
  1575.  
  1576.           The destination(s) to which a SNMPv2-Trap-PDU is sent is
  1577.           determined by consulting the aclTable [5] to find all entries
  1578.           satisfying the following conditions:
  1579.  
  1580.           (1)  The value of aclSubject refers to the SNMPv2 entity.
  1581.  
  1582.           (2)  The value of aclPrivileges allows for the SNMPv2-Trap-
  1583.                PDU.
  1584.  
  1585.           (3)  aclResources refers to a SNMPv2 context denoting local
  1586.                object resources, and the notification's administratively
  1587.                assigned name is present in the corresponding MIB view.
  1588.  
  1589.  
  1590.  
  1591.  
  1592.  
  1593.           Case, McCloghrie, Rose & Waldbusser                  [Page 26]
  1594.  
  1595.  
  1596.  
  1597.  
  1598.  
  1599.           RFC 1448        Protocol Operations for SNMPv2      April 1993
  1600.  
  1601.  
  1602.                (That is, the set of entries in the viewTable [5] for
  1603.                which the instance of viewIndex has the same value as the
  1604.                aclResources's contextViewIndex, define a MIB view which
  1605.                contains the notification's administratively assigned
  1606.                name.)
  1607.  
  1608.           (4)  If the OBJECTS clause is present in the invocation of the
  1609.                corresponding NOTIFICATION-TYPE macro, then the
  1610.                correspondent variables are all present in the MIB view
  1611.                corresponding to aclResource.
  1612.  
  1613.           Then, for each entry satisfying these conditions, a SNMPv2-
  1614.           Trap-PDU is sent from aclSubject with context aclResources to
  1615.           aclTarget.  The instance of snmpTrapNumbers [11] corresponding
  1616.           to aclTarget is incremented, and is used as the request-id
  1617.           field of the SNMPv2-Trap-PDU.  Then, the variable-bindings
  1618.           field are constructed as:
  1619.  
  1620.           (1)  The first variable is sysUpTime.0 [9].
  1621.  
  1622.           (2)  The second variable is snmpTrapOID.0 [11], which contains
  1623.                the administratively assigned name of the notification.
  1624.  
  1625.           (3)  If the OBJECTS clause is present in the invocation of the
  1626.                corresponding NOTIFICATION-TYPE macro, then each
  1627.                corresponding variable is copied, in order, to the
  1628.                variable-bindings field.
  1629.  
  1630.           (4)  At the option of the SNMPv2 entity acting in an agent
  1631.                role, additional variables may follow in the variable-
  1632.                bindings field.
  1633.  
  1634.  
  1635.           4.2.7.  The InformRequest-PDU
  1636.  
  1637.           An InformRequest-PDU is generated and transmitted at the
  1638.           request an application in a SNMPv2 entity acting in a manager
  1639.           role, that wishes to notify another application (in a SNMPv2
  1640.           entity also acting in a manager role) of information in the
  1641.           MIB View of a party local to the sending application.
  1642.  
  1643.           The destination(s) to which an InformRequest-PDU is sent is
  1644.           determined by inspecting the snmpEventNotifyTable [12], or as
  1645.           specified by the requesting application.  The first two
  1646.           variable bindings in the variable binding list of an
  1647.  
  1648.  
  1649.  
  1650.  
  1651.  
  1652.           Case, McCloghrie, Rose & Waldbusser                  [Page 27]
  1653.  
  1654.  
  1655.  
  1656.  
  1657.  
  1658.           RFC 1448        Protocol Operations for SNMPv2      April 1993
  1659.  
  1660.  
  1661.           InformRequest-PDU are sysUpTime.0 [9] and snmpEventID.i [12]
  1662.           respectively.  If the OBJECTS clause is present in the
  1663.           invocation of the corresponding NOTIFICATION-TYPE macro, then
  1664.           each corresponding variable, as instantiated by this
  1665.           notification, is copied, in order, to the variable-bindings
  1666.           field.
  1667.  
  1668.           Upon receipt of an InformRequest-PDU, the receiving SNMPv2
  1669.           entity determines the size of a message encapsulating a
  1670.           Response-PDU with the same values in its request-id, error-
  1671.           status, error-index and variable-bindings fields as the
  1672.           received InformRequest-PDU.  If the determined message size is
  1673.           greater than either a local constraint or the maximum message
  1674.           size of the request's source party, then an alternate
  1675.           Response-PDU is generated, transmitted to the originator of
  1676.           the InformRequest-PDU, and processing of the InformRequest-PDU
  1677.           terminates immediately thereafter.  This alternate Response-
  1678.           PDU is formatted with the same values in its request-id field
  1679.           as the received InformRequest-PDU, with the value of its
  1680.           error-status field set to `tooBig', the value of its error-
  1681.           index field set to zero, and an empty variable-bindings field.
  1682.           This alternate Response-PDU is then encapsulated into a
  1683.           message.  If the size of the resultant message is less than or
  1684.           equal to both a local constraint and the maximum message size
  1685.           of the request's source party, it is transmitted to the
  1686.           originator of the InformRequest-PDU.  Otherwise, the resultant
  1687.           message is discarded.  Regardless, processing of the
  1688.           InformRequest-PDU terminates.
  1689.  
  1690.           Otherwise, the receiving SNMPv2 entity:
  1691.  
  1692.           (1)  presents its contents to the appropriate SNMPv2
  1693.                application;
  1694.  
  1695.           (2)  generates a Response-PDU with the same values in its
  1696.                request-id and variable-bindings fields as the received
  1697.                InformRequest-PDU, with the value of its error-status
  1698.                field is set to `noError' and the value of its error-
  1699.                index field is zero; and
  1700.  
  1701.           (3)  transmits the generated Response-PDU to the originator of
  1702.                the InformRequest-PDU.
  1703.  
  1704.  
  1705.  
  1706.  
  1707.  
  1708.  
  1709.  
  1710.  
  1711.           Case, McCloghrie, Rose & Waldbusser                  [Page 28]
  1712.  
  1713.  
  1714.  
  1715.  
  1716.  
  1717.           RFC 1448        Protocol Operations for SNMPv2      April 1993
  1718.  
  1719.  
  1720.           5.  Acknowledgements
  1721.  
  1722.           This document is based, in part, on RFC 1157.  The mechanism
  1723.           for bulk retrieval is influenced by many experiments,
  1724.           including RFC1187 and also Greg Satz's work on SNMP over TCP.
  1725.  
  1726.           Finally, the comments of the SNMP version 2 working group are
  1727.           gratefully acknowledged:
  1728.  
  1729.                Beth Adams, Network Management Forum
  1730.                Steve Alexander, INTERACTIVE Systems Corporation
  1731.                David Arneson, Cabletron Systems
  1732.                Toshiya Asaba
  1733.                Fred Baker, ACC
  1734.                Jim Barnes, Xylogics, Inc.
  1735.                Brian Bataille
  1736.                Andy Bierman, SynOptics Communications, Inc.
  1737.                Uri Blumenthal, IBM Corporation
  1738.                Fred Bohle, Interlink
  1739.                Jack Brown
  1740.                Theodore Brunner, Bellcore
  1741.                Stephen F. Bush, GE Information Services
  1742.                Jeffrey D. Case, University of Tennessee, Knoxville
  1743.                John Chang, IBM Corporation
  1744.                Szusin Chen, Sun Microsystems
  1745.                Robert Ching
  1746.                Chris Chiotasso, Ungermann-Bass
  1747.                Bobby A. Clay, NASA/Boeing
  1748.                John Cooke, Chipcom
  1749.                Tracy Cox, Bellcore
  1750.                Juan Cruz, Datability, Inc.
  1751.                David Cullerot, Cabletron Systems
  1752.                Cathy Cunningham, Microcom
  1753.                James R. (Chuck) Davin, Bellcore
  1754.                Michael Davis, Clearpoint
  1755.                Mike Davison, FiberCom
  1756.                Cynthia DellaTorre, MITRE
  1757.                Taso N. Devetzis, Bellcore
  1758.                Manual Diaz, DAVID Systems, Inc.
  1759.                Jon Dreyer, Sun Microsystems
  1760.                David Engel, Optical Data Systems
  1761.                Mike Erlinger, Lexcel
  1762.                Roger Fajman, NIH
  1763.                Daniel Fauvarque, Sun Microsystems
  1764.                Karen Frisa, CMU
  1765.  
  1766.  
  1767.  
  1768.  
  1769.  
  1770.           Case, McCloghrie, Rose & Waldbusser                  [Page 29]
  1771.  
  1772.  
  1773.  
  1774.  
  1775.  
  1776.           RFC 1448        Protocol Operations for SNMPv2      April 1993
  1777.  
  1778.  
  1779.                Shari Galitzer, MITRE
  1780.                Shawn Gallagher, Digital Equipment Corporation
  1781.                Richard Graveman, Bellcore
  1782.                Maria Greene, Xyplex, Inc.
  1783.                Michel Guittet, Apple
  1784.                Robert Gutierrez, NASA
  1785.                Bill Hagerty, Cabletron Systems
  1786.                Gary W. Haney, Martin Marietta Energy Systems
  1787.                Patrick Hanil, Nokia Telecommunications
  1788.                Matt Hecht, SNMP Research, Inc.
  1789.                Edward A. Heiner, Jr., Synernetics Inc.
  1790.                Susan E. Hicks, Martin Marietta Energy Systems
  1791.                Geral Holzhauer, Apple
  1792.                John Hopprich, DAVID Systems, Inc.
  1793.                Jeff Hughes, Hewlett-Packard
  1794.                Robin Iddon, Axon Networks, Inc.
  1795.                David Itusak
  1796.                Kevin M. Jackson, Concord Communications, Inc.
  1797.                Ole J. Jacobsen, Interop Company
  1798.                Ronald Jacoby, Silicon Graphics, Inc.
  1799.                Satish Joshi, SynOptics Communications, Inc.
  1800.                Frank Kastenholz, FTP Software
  1801.                Mark Kepke, Hewlett-Packard
  1802.                Ken Key, SNMP Research, Inc.
  1803.                Zbiginew Kielczewski, Eicon
  1804.                Jongyeoi Kim
  1805.                Andrew Knutsen, The Santa Cruz Operation
  1806.                Michael L. Kornegay, VisiSoft
  1807.                Deirdre C. Kostik, Bellcore
  1808.                Cheryl Krupczak, Georgia Tech
  1809.                Mark S. Lewis, Telebit
  1810.                David Lin
  1811.                David Lindemulder, AT&T/NCR
  1812.                Ben Lisowski, Sprint
  1813.                David Liu, Bell-Northern Research
  1814.                John Lunny, The Wollongong Group
  1815.                Robert C. Lushbaugh Martin, Marietta Energy Systems
  1816.                Michael Luufer, BBN
  1817.                Carl Madison, Star-Tek, Inc.
  1818.                Keith McCloghrie, Hughes LAN Systems
  1819.                Evan McGinnis, 3Com Corporation
  1820.                Bill McKenzie, IBM Corporation
  1821.                Donna McMaster, SynOptics Communications, Inc.
  1822.                John Medicke, IBM Corporation
  1823.                Doug Miller, Telebit
  1824.  
  1825.  
  1826.  
  1827.  
  1828.  
  1829.           Case, McCloghrie, Rose & Waldbusser                  [Page 30]
  1830.  
  1831.  
  1832.  
  1833.  
  1834.  
  1835.           RFC 1448        Protocol Operations for SNMPv2      April 1993
  1836.  
  1837.  
  1838.                Dave Minnich, FiberCom
  1839.                Mohammad Mirhakkak, MITRE
  1840.                Rohit Mital, Protools
  1841.                George Mouradian, AT&T Bell Labs
  1842.                Patrick Mullaney, Cabletron Systems
  1843.                Dan Myers, 3Com Corporation
  1844.                Rina Nathaniel, Rad Network Devices Ltd.
  1845.                Hien V. Nguyen, Sprint
  1846.                Mo Nikain
  1847.                Tom Nisbet
  1848.                William B. Norton, MERIT
  1849.                Steve Onishi, Wellfleet Communications, Inc.
  1850.                David T. Perkins, SynOptics Communications, Inc.
  1851.                Carl Powell, BBN
  1852.                Ilan Raab, SynOptics Communications, Inc.
  1853.                Richard Ramons, AT&T
  1854.                Venkat D. Rangan, Metric Network Systems, Inc.
  1855.                Louise Reingold, Sprint
  1856.                Sam Roberts, Farallon Computing, Inc.
  1857.                Kary Robertson, Concord Communications, Inc.
  1858.                Dan Romascanu, Lannet Data Communications Ltd.
  1859.                Marshall T. Rose, Dover Beach Consulting, Inc.
  1860.                Shawn A. Routhier, Epilogue Technology Corporation
  1861.                Chris Rozman
  1862.                Asaf Rubissa, Fibronics
  1863.                Jon Saperia, Digital Equipment Corporation
  1864.                Michael Sapich
  1865.                Mike Scanlon, Interlan
  1866.                Sam Schaen, MITRE
  1867.                John Seligson, Ultra Network Technologies
  1868.                Paul A. Serice, Corporation for Open Systems
  1869.                Chris Shaw, Banyan Systems
  1870.                Timon Sloane
  1871.                Robert Snyder, Cisco Systems
  1872.                Joo Young Song
  1873.                Roy Spitier, Sprint
  1874.                Einar Stefferud, Network Management Associates
  1875.                John Stephens, Cayman Systems, Inc.
  1876.                Robert L. Stewart, Xyplex, Inc. (chair)
  1877.                Kaj Tesink, Bellcore
  1878.                Dean Throop, Data General
  1879.                Ahmet Tuncay, France Telecom-CNET
  1880.                Maurice Turcotte, Racal Datacom
  1881.                Warren Vik, INTERACTIVE Systems Corporation
  1882.                Yannis Viniotis
  1883.  
  1884.  
  1885.  
  1886.  
  1887.  
  1888.           Case, McCloghrie, Rose & Waldbusser                  [Page 31]
  1889.  
  1890.  
  1891.  
  1892.  
  1893.  
  1894.           RFC 1448        Protocol Operations for SNMPv2      April 1993
  1895.  
  1896.  
  1897.                Steven L. Waldbusser, Carnegie Mellon Universitty
  1898.                Timothy M. Walden, ACC
  1899.                Alice Wang, Sun Microsystems
  1900.                James Watt, Newbridge
  1901.                Luanne Waul, Timeplex
  1902.                Donald E. Westlake III, Digital Equipment Corporation
  1903.                Gerry White
  1904.                Bert Wijnen, IBM Corporation
  1905.                Peter Wilson, 3Com Corporation
  1906.                Steven Wong, Digital Equipment Corporation
  1907.                Randy Worzella, IBM Corporation
  1908.                Daniel Woycke, MITRE
  1909.                Honda Wu
  1910.                Jeff Yarnell, Protools
  1911.                Chris Young, Cabletron
  1912.                Kiho Yum, 3Com Corporation
  1913.  
  1914.  
  1915.  
  1916.  
  1917.  
  1918.  
  1919.  
  1920.  
  1921.  
  1922.  
  1923.  
  1924.  
  1925.  
  1926.  
  1927.  
  1928.  
  1929.  
  1930.  
  1931.  
  1932.  
  1933.  
  1934.  
  1935.  
  1936.  
  1937.  
  1938.  
  1939.  
  1940.  
  1941.  
  1942.  
  1943.  
  1944.  
  1945.  
  1946.  
  1947.           Case, McCloghrie, Rose & Waldbusser                  [Page 32]
  1948.  
  1949.  
  1950.  
  1951.  
  1952.  
  1953.           RFC 1448        Protocol Operations for SNMPv2      April 1993
  1954.  
  1955.  
  1956.           6.  References
  1957.  
  1958.           [1]  Information processing systems - Open Systems
  1959.                Interconnection - Specification of Abstract Syntax
  1960.                Notation One (ASN.1), International Organization for
  1961.                Standardization.  International Standard 8824, (December,
  1962.                1987).
  1963.  
  1964.           [2]  Case, J., McCloghrie, K., Rose, M., and Waldbusser, S.,
  1965.                "Structure of Management Information for version 2 of the
  1966.                Simple Network Management Protocol (SNMPv2)", RFC 1442,
  1967.                SNMP Research, Inc., Hughes LAN Systems, Dover Beach
  1968.                Consulting, Inc., Carnegie Mellon University, April 1993.
  1969.  
  1970.           [3]  Galvin, J., and McCloghrie, K., "Administrative Model for
  1971.                version 2 of the Simple Network Management Protocol
  1972.                (SNMPv2)", RFC 1445, Trusted Information Systems, Hughes
  1973.                LAN Systems, April 1993.
  1974.  
  1975.           [4]  Case, J., McCloghrie, K., Rose, M., and Waldbusser, S.,
  1976.                "Textual Conventions for version 2 of the the Simple
  1977.                Network Management Protocol (SNMPv2)", RFC 1443, SNMP
  1978.                Research, Inc., Hughes LAN Systems, Dover Beach
  1979.                Consulting, Inc., Carnegie Mellon University, April 1993.
  1980.  
  1981.           [5]  McCloghrie, K., and Galvin, J., "Party MIB for version 2
  1982.                of the Simple Network Management Protocol (SNMPv2)", RFC
  1983.                1447, Hughes LAN Systems, Trusted Information Systems,
  1984.                April 1993.
  1985.  
  1986.           [6]  C. Kent, J. Mogul, Fragmentation Considered Harmful,
  1987.                Proceedings, ACM SIGCOMM '87, Stowe, VT, (August 1987).
  1988.  
  1989.           [7]  Case, J., McCloghrie, K., Rose, M., and Waldbusser, S.,
  1990.                "Transport Mappings for version 2 of the Simple Network
  1991.                Management Protocol (SNMPv2)", RFC 1449, SNMP Research,
  1992.                Inc., Hughes LAN Systems, Dover Beach Consulting, Inc.,
  1993.                Carnegie Mellon University, April 1993.
  1994.  
  1995.           [8]  Postel, J., "User Datagram Protocol", STD 6, RFC 768,
  1996.                USC/Information Sciences Institute, August 1980.
  1997.  
  1998.           [9]  McCloghrie, K., and Rose, M., "Management Information
  1999.                Base for Network Management of TCP/IP-based internets:
  2000.                MIB-II", STD 17, RFC 1213, March 1991.
  2001.  
  2002.  
  2003.  
  2004.  
  2005.  
  2006.           Case, McCloghrie, Rose & Waldbusser                  [Page 33]
  2007.  
  2008.  
  2009.  
  2010.  
  2011.  
  2012.           RFC 1448        Protocol Operations for SNMPv2      April 1993
  2013.  
  2014.  
  2015.           [10] Case, J., McCloghrie, K., Rose, M., and Waldbusser, S.,
  2016.                "Coexistence between version 1 and version 2 of the
  2017.                Internet-standard Network Management Framework", RFC
  2018.                1452, SNMP Research, Inc., Hughes LAN Systems, Dover
  2019.                Beach Consulting, Inc., Carnegie Mellon University, April
  2020.                1993.
  2021.  
  2022.           [11] Case, J., McCloghrie, K., Rose, M., and Waldbusser, S.,
  2023.                "Management Information Base for version 2 of the Simple
  2024.                Network Management Protocol (SNMPv2)", RFC 1450, SNMP
  2025.                Research, Inc., Hughes LAN Systems, Dover Beach
  2026.                Consulting, Inc., Carnegie Mellon University, April 1993.
  2027.  
  2028.           [12] Case, J., McCloghrie, K., Rose, M., and Waldbusser, S.,
  2029.                "Manager-to-Manager Management Information Base", RFC
  2030.                1451, SNMP Research, Inc., Hughes LAN Systems, Dover
  2031.                Beach Consulting, Inc., Carnegie Mellon University, April
  2032.                1993.
  2033.  
  2034.  
  2035.  
  2036.  
  2037.  
  2038.  
  2039.  
  2040.  
  2041.  
  2042.  
  2043.  
  2044.  
  2045.  
  2046.  
  2047.  
  2048.  
  2049.  
  2050.  
  2051.  
  2052.  
  2053.  
  2054.  
  2055.  
  2056.  
  2057.  
  2058.  
  2059.  
  2060.  
  2061.  
  2062.  
  2063.  
  2064.  
  2065.           Case, McCloghrie, Rose & Waldbusser                  [Page 34]
  2066.  
  2067.  
  2068.  
  2069.  
  2070.  
  2071.           RFC 1448        Protocol Operations for SNMPv2      April 1993
  2072.  
  2073.  
  2074.           7.  Security Considerations
  2075.  
  2076.           Security issues are not discussed in this memo.
  2077.  
  2078.  
  2079.           8.  Authors' Addresses
  2080.  
  2081.                Jeffrey D. Case
  2082.                SNMP Research, Inc.
  2083.                3001 Kimberlin Heights Rd.
  2084.                Knoxville, TN  37920-9716
  2085.                US
  2086.  
  2087.                Phone: +1 615 573 1434
  2088.                Email: case@snmp.com
  2089.  
  2090.  
  2091.                Keith McCloghrie
  2092.                Hughes LAN Systems
  2093.                1225 Charleston Road
  2094.                Mountain View, CA  94043
  2095.                US
  2096.  
  2097.                Phone: +1 415 966 7934
  2098.                Email: kzm@hls.com
  2099.  
  2100.  
  2101.                Marshall T. Rose
  2102.                Dover Beach Consulting, Inc.
  2103.                420 Whisman Court
  2104.                Mountain View, CA  94043-2186
  2105.                US
  2106.  
  2107.                Phone: +1 415 968 1052
  2108.                Email: mrose@dbc.mtview.ca.us
  2109.  
  2110.                Steven Waldbusser
  2111.                Carnegie Mellon University
  2112.                4910 Forbes Ave
  2113.                Pittsburgh, PA  15213
  2114.                US
  2115.  
  2116.                Phone: +1 412 268 6628
  2117.                Email: waldbusser@cmu.edu
  2118.  
  2119.  
  2120.  
  2121.  
  2122.  
  2123.  
  2124.           Case, McCloghrie, Rose & Waldbusser                  [Page 35]
  2125.  
  2126.