tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search

RFC 2741

 
 
 

Agent Extensibility (AgentX) Protocol Version 1

Part 3 of 4, p. 45 to 75
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 45 
7. Elements of Procedure

   This section describes the actions of protocol entities (master
   agents and subagents) implementing the AgentX protocol.  Note,
   however, that it is not intended to constrain the internal
   architecture of any conformant implementation.

   The actions of AgentX protocol entities can be broadly categorized
   under two headings, each of which is described separately:

   (1)  processing AgentX administrative messages (e.g., registration
        requests from a subagent to a master agent); and

   (2)  processing SNMP messages (the coordinated actions of a master
        agent and one or more subagents in processing, for example, a
        received SNMP GetRequest-PDU).

7.1. Processing AgentX Administrative Messages

   This subsection describes the actions of AgentX protocol entities in
   processing AgentX administrative messages.  Such messages include
   those involved in establishing and terminating an AgentX session
   between a subagent and a master agent, those by which a subagent
   requests allocation of instance index values, and those by which a
   subagent communicates to a master agent which MIB regions it
   supports.

   Processing is defined specifically for each PDU type in its own
   section.  For the master agent, many of these PDU types require the
   same initial processing steps.  This common processing is defined
   here, and referenced as needed in the PDU type-specific descriptions.

   Common Processing:

   The master agent initially processes a received AgentX PDU as
   follows:

      1) An agentx-Response-PDU is created, res.sysUpTime is set to the
         value of sysUpTime.0 for the default context, res.error is set
         to `noAgentXError', and res.index is set to 0.

      2) If the received PDU cannot be parsed, res.error is set to `
         parseError'.  Examples of a parse error are:

Top      Up      ToC       Page 46 
            - PDU length (h.payload) too short to contain current
               construct (Object Identifier header indicates more sub-
               identifiers, VarBind v.type indicates data follows, etc)

            - An unrecognized value is encountered for h.type, v.type,
               etc.

      3) Otherwise, if h.sessionID does not correspond to a currently
         established session with this subagent, res.error is set to
         `notOpen'.

      4) Otherwise, if the NON_DEFAULT_CONTEXT bit is set and the master
         agent does not support the indicated context, res.error is set
         to `unsupportedContext'.  If the master agent does support the
         indicated context, the value of res.sysUpTime is set to the
         value of sysUpTime.0 for that context.

      Note: Non-default contexts might be added on the fly by the master
            agent, or the master agent might require such non-default
            contexts to be pre-configured.  The choice is
            implementation-specific.

      5) If resources cannot be allocated or some other condition
         prevents processing, res.error is set to `processingError'.

      6) At this point, if res.error is not `noAgentXError', the
         received PDU is not processed further.  If the received PDU's
         header was successfully parsed, the AgentX-Response-PDU is sent
         in reply.  If the received PDU contained a VarBindList which
         was successfully parsed, the AgentX-Response-PDU contains the
         identical VarBindList.  If the received PDU's header was not
         successfully parsed or for some other reason the master agent
         cannot send a reply, processing is complete.

7.1.1.  Processing the agentx-Open-PDU

   When the master agent receives an agentx-Open-PDU, it processes it as
   follows:

   1) An agentx-Response-PDU is created, res.sysUpTime is set to the
      value of sysUpTime.0 for the default context, res.error is set to
      `noAgentXError', and res.index is set to 0.

   2) If the received PDU cannot be parsed, res.error is set to
      `parseError'.

   3) Otherwise, if the master agent is unable to open an AgentX session
      for any reason, res.error is set to `openFailed'.

Top      Up      ToC       Page 47 
   4) Otherwise:  The master agent assigns a sessionID to the new
      session and puts the value in the h.sessionID field of the
      agentx-Response-PDU.  This value must be unique among all existing
      open sessions.

      The master agent retains session-specific information from the PDU
      for this session:

      -  The NETWORK_BYTE_ORDER value in h.flags is retained.  All
         subsequent AgentX protocol operations initiated by the master
         agent for this session must use this byte ordering and set this
         bit accordingly.

      The subagent typically sets this bit to correspond to its native
      byte ordering, and typically does not vary byte ordering for an
      initiated session.  The master agent must be able to decode each
      PDU according to the h.flag NETWORK_BYTE_ORDER bit in the PDU, but
      does not need to toggle its retained value for the session if the
      subagent varies its byte ordering.

      -  The o.timeout value is used in calculating response timeout
         conditions for this session. This field is also referenced in
         the AgentX MIB (a work-in-progress) by the agentxSessionTimeout
         object.

      -  The o.id and o.descr fields are used for informational
         purposes.  These two fields are also referenced in the AgentX
         MIB (a work-in-progress) by the agentxSessionObjectID object,
         and by the agentxSessionDescr object.

   5) The agentx-Response-PDU is sent with the res.error field
      indicating the result of the session initiation.

   If processing was successful, an AgentX session is considered
   established between the master agent and the subagent.  An AgentX
   session is a distinct channel for the exchange of AgentX protocol
   messages between a master agent and one subagent, qualified by the
   session-specific attributes listed in 4) above.  AgentX session
   establishment is initiated by the subagent.  An AgentX session can be
   terminated by either the master agent or the subagent.

7.1.2. Processing the agentx-IndexAllocate-PDU

   When the master agent receives an agentx-IndexAllocate-PDU, it
   performs the common processing described in section 7.1, "Processing
   AgentX Administrative Messages".  If as a result res.error is
   `noAgentXError', processing continues as follows:

Top      Up      ToC       Page 48 
   1) Each VarBind in the VarBindList is processed until either all are
      successful, or one fails.  If any VarBind fails, the agentx-
      Response-PDU is sent in reply containing the original VarBindList,
      with res.index set to indicate the failed VarBind, and with
      res.error set as described subsequently.  All other VarBinds are
      ignored; no index values are allocated.

      VarBinds are processed as follows:

      -  v.name is the OID prefix of the MIB OBJECT-TYPE for which a
         value is to be allocated.

      - v.type is the syntax of the MIB OBJECT-TYPE for which a value is
         to be allocated.

      -  v.data indicates the specific index value requested.  If the
         NEW_INDEX or the ANY_INDEX bit is set, the actual value in
         v.data is ignored and an appropriate index value is generated.

      a) If there are no currently allocated index values for v.name in
         the indicated context, and v.type does not correspond to a
         valid index type value, the VarBind fails and res.error is set
         to `indexWrongType'.

      b) If there are currently allocated index values for v.name in the
         indicated context, but the syntax of those values does not
         match v.type, the VarBind fails and res.error is set to
         `indexWrongType'.

      c) Otherwise, if both the NEW_INDEX and ANY_INDEX bits are clear,
         allocation of a specific index value is being requested.  If
         the requested index is already allocated for v.name in the
         indicated context, the VarBind fails and res.error is set to
         `indexAlreadyAllocated'.

      d) Otherwise, if the NEW_INDEX bit is set, the master agent should
         generate the next available index value for v.name in the
         indicated context, with the constraint that this value must not
         have been allocated (even if subsequently released) to any
         subagent since the last re-initialization of the master agent.
         If no such value can be generated, the VarBind fails and
         res.error is set to `indexNoneAvailable'.

      e) Otherwise, if the ANY_INDEX bit is set, the master agent should
         generate an index value for v.name in the indicated context,
         with the constraint that this value is not currently allocated
         to any subagent.  If no such value can be generated, then the
         VarBind fails and res.error is set to `indexNoneAvailable'.

Top      Up      ToC       Page 49 
   2) If all VarBinds are processed successfully, the agentx-Response-
      PDU is sent in reply with res.error set to `noAgentXError'.  A
      VarBindList is included that is identical to the one sent in the
      agentx-IndexAllocate-PDU, except that VarBinds requesting a
      NEW_INDEX or ANY_INDEX value are generated with an appropriate
      value.

      See section 7.1.4.2, "Registering Stuff" for more information on
      how subagents should perform index allocations.

7.1.3. Processing the agentx-IndexDeallocate-PDU

   When the master agent receives an agentx-IndexDeallocate-PDU, it
   performs the common processing described in section 7.1, "Processing
   AgentX Administrative Messages".  If as a result res.error is
   `noAgentXError', processing continues as follows:

   1) Each VarBind in the VarBindList is processed until either all are
      successful, or one fails.  If any VarBind fails, the agentx-
      Response-PDU is sent in reply, containing the original
      VarBindList, with res.index set to indicate the failed VarBind,
      and with res.error set as described subsequently.  All other
      VarBinds are ignored; no index values are released.

      VarBinds are processed as follows:

      -  v.name is the name of the index for which a value is to be
         released

      -  v.type is the syntax of the index object

      -  v.data indicates the specific index value to be released.  The
         NEW_INDEX and ANY_INDEX bits are ignored.

      a) If the index value for the named index is not currently
         allocated to this session, the VarBind fails and res.error is
         set to `indexNotAllocated'.

   2) If all VarBinds are processed successfully, res.error is set to
      `noAgentXError' and the agentx-Response-PDU is sent.  A
      VarBindList is included which is identical to the one sent in the
      agentx-IndexDeallocate-PDU.

   All released index values are now available, and may be used in
   response to subsequent allocation requests for ANY_INDEX values and
   in response to subsequent allocation requests for the particular
   index value.

Top      Up      ToC       Page 50 
7.1.4. Processing the agentx-Register-PDU

   When the master agent receives an agentx-Register-PDU, it performs
   the common processing described in section 7.1, "Processing AgentX
   Administrative Messages".  If as a result res.error is
   `noAgentXError', processing continues as follows:

   If any of the union of subtrees defined by this MIB region is exactly
   the same as any subtree defined by a MIB region currently registered
   within the indicated context, those subtrees are termed "duplicate
   subtrees".

   If any of the union of subtrees defined by this MIB region overlaps,
   or is itself overlapped by, any subtree defined by a MIB region
   currently registered within the indicated context, those subtrees are
   termed "overlapping subtrees".

   1) If this registration would result in duplicate subtrees registered
      with the same value of r.priority, the request fails and an
      agentx-Response-PDU is returned with res.error set to
      `duplicateRegistration'.

   2) Otherwise, if the master agent does not wish to permit this
      registration for implementation-specific reasons, the request
      fails and an agentx-Response-PDU is returned with res.error set to
      `requestDenied'.

   3) Otherwise, the agentx-Response-PDU is returned with res.error set
      to `noAgentXError'.

      The master agent adds this MIB region to its registration data
      store for the indicated context, to be considered during the
      dispatching phase for subsequently received SNMP protocol
      messages.

7.1.4.1.  Handling Duplicate and Overlapping Subtrees

   As a result of this registration algorithm there are likely to be
   duplicate and/or overlapping subtrees within the registration data
   store of the master agent.  Whenever the master agent's dispatching
   algorithm (see section 7.2.1, "Dispatching AgentX PDUs") determines
   that there are multiple subtrees that could potentially contain the
   same MIB object instances, the master agent selects one to use,
   termed the 'authoritative region', as follows:

Top      Up      ToC       Page 51 
      1) Choose the one whose original agentx-Register-PDU r.subtree
         contained the most subids, i.e., the most specific r.subtree.
         Note: The presence or absence of a range subid has no bearing
         on how "specific" one object identifier is compared to another.

      2) If still ambiguous, there were duplicate subtrees.  Choose the
         one whose original agentx-Register-PDU specified the smaller
         value of r.priority.

7.1.4.2.  Registering Stuff

   This section describes more fully how AgentX subagents use the
   agentx-IndexAllocate-PDU and agentx-Register-PDU to achieve desired
   configurations.

7.1.4.2.1.     Registration Priority

   The r.priority field in the agentx-Register-PDU is intended to be
   manipulated by human administrators to achieve a desired subagent
   configuration.  Typically this would be needed where a legacy
   application registers a specific subtree, and a different
   (configurable) application may need to become authoritative for the
   identical subtree.

   The result of this configuration (the same subtree registered on
   different sessions with different priorities) is that the session
   using the better priority (see section 7.1.4.1, "Handling Duplicate
   and Overlapping Subtrees") will be authoritative.  The other session
   will simply never be dispatched to.

   This is useful in the case described above, but is NOT useful in
   other cases, particularly when subagents share tables indexed by
   arbitrary values (see below).  In general, subagents should register
   using the default priority (127).

7.1.4.2.2.     Index Allocation

   Index allocation is a service provided by an AgentX master agent.  It
   provides generic support for sharing MIB conceptual tables among
   subagents who are assumed to have no knowledge of each other.

   The master agent maintains a database of index objects (OIDs), and,
   for each index, the values that have been allocated for it.  It is
   unaware of what MIB variables (if any) the index objects represent.

Top      Up      ToC       Page 52 
   By convention, subagents use the MIB variable listed in the INDEX
   clause as the index object for which values must be allocated.  For
   tables indexed by multiple variables, values may be allocated for
   each index (although this is frequently unnecessary; see example 2
   below).  The subagent may request allocation of

          a) a specific index value
          b) an index value that is not currently allocated
          c) an index value that has never been allocated

   The last two alternatives reflect the uniqueness and constancy
   requirements present in many MIB specifications for arbitrary integer
   indexes (e.g., ifIndex in the IF-MIB (RFC 2233 [19]),
   snmpFddiSMTIndex in the FDDI MIB (RFC 1285 [20]), or
   sysApplInstallPkgIndex in the System Application MIB (RFC 2287
   [21])).  The need for subagents to share tables using such indexes is
   the main motivation for index allocation in AgentX.

   It is important to note that index allocation and MIB region
   registration are not coupled in the master agent. The current state
   of index allocations is not considered when processing registration
   requests, and the current registry is not considered when processing
   index allocation requests.  (This is mainly to accommodate non-AgentX
   subagents.)

   AgentX subagents should follow the model of "first request allocation
   of an index, then register the corresponding region".  Then a
   successful index allocation request gives a subagent a good hint (but
   no guarantee) of what it should be able to register.  The
   registration may fail (with `duplicateRegistration') because some
   other subagent session has already registered that row of the table.

   The recommended mechanism for subagents to register conceptual rows
   in a shared table is

   1) Successfully allocate an index value.

   2) Use that value to fully qualify the MIB region(s), and attempt to
      register using the default priority.

   3) If the registration fails with `duplicateRegistration' deallocate
      the previously allocated index value(s) for this row and go to
      step 1).

Top      Up      ToC       Page 53 
   Note that index allocation is necessary only when the index in
   question is an arbitrary value, and hence the subagent has no other
   reasonable way to determine which index values to use.  When index
   values have intrinsic meaning it is not expected that subagents will
   allocate their index values.

   For example, RFC 1514's table of running software processes
   (hrSWRunTable) is indexed by the system's native process identifier
   (pid).  A subagent implementing the row of hrSWRunTable corresponding
   to its own process would simply register the region defining that
   row's object instances without allocating index values.

7.1.4.2.3.     Examples

   Example 1:

      A subagent implements an interface, and wishes to register a
      single row of the RFC 2233 ifTable.  It requests an allocation for
      the index object "ifIndex", for a value that has never been
      allocated (since ifIndex values must be unique).  The master agent
      returns the value "7".

      The subagent now attempts to register row 7 of ifTable, by
      specifying a MIB region in the agentx-Register-PDU of
      1.3.6.1.2.1.2.2.1.[1-22].7.  If the registration succeeds, no
      further processing is required.  The master agent will dispatch to
      this subagent correctly.

      If the registration failed with `duplicateRegistration', the
      subagent should deallocate the failed index, request allocation of
      a new index i, and attempt to register ifTable.[1-22].i, until
      successful.

   Example 2:

      This same subagent wishes to register ipNetToMediaTable rows
      corresponding to its interface (ifIndex i).  Due to the structure
      of this table, no further index allocation need be done.  The
      subagent can register the MIB region ipNetToMediaTable.[1-4].i, It
      is claiming responsibility for all rows of the table whose value
      of ipNetToMediaIfIndex is i.

Top      Up      ToC       Page 54 
   Example 3:

      A network device consists of a set of processors, each of which
      accepts network connections for a unique set of IP addresses.
      Further, each processor contains a subagent that implements
      tcpConnTable.  In order to represent tcpConnTable for the entire
      managed device, the subagents need to share tcpConnTable.

      In this case, no index allocation need be done at all.  Each
      subagent can register a MIB region of tcpConnTable.[1-5].a.b.c.d,
      where a.b.c.d represents an unique IP address of the individual
      processor.

      Each subagent is claiming responsibility for the region of
      tcpConnTable where the value of tcpConnLocalAddress is a.b.c.d.

   Example 4:

      The Application Management MIB (RFC 2564 [22]) uses two objects to
      index several tables.  A partial description of them is:

      applSrvIndex     OBJECT-TYPE
             SYNTAX      Unsigned32 (1..'ffffffff'h)
             MAX-ACCESS  read-only
             STATUS      current
             DESCRIPTION
                "An applSrvIndex is the system-unique identifier
                of an instance of a service.  The value is unique
                not only across all instances of a given service,
                but also across all services in a system."

      applSrvName     OBJECT-TYPE
             SYNTAX     SnmpAdminString
             MAX-ACCESS read-only
             STATUS     current
             DESCRIPTION
                "The human-readable name of a service.  Where
                appropriate, as in the case where a service can
                be identified in terms of a single protocol, the
                strings should be established names such as those
                assigned by IANA and found in STD 2 [23], or
                defined by some other authority.  In some cases
                private conventions apply and the string should
                in these cases be consistent with these
                non-standard conventions. An applicability
                statement may specify the service name(s) to be
                used."

Top      Up      ToC       Page 55 
      Since applSrvIndex is an arbitrary value, it would be reasonable
      for subagents to allocate values for this index.  applSrvName
      however has intrinsic meaning and any values a subagent would use
      should be known a priori, hence it is not reasonable for subagents
      to allocate values of this index.

7.1.5. Processing the agentx-Unregister-PDU

   When the master agent receives an agentx-Unregister-PDU, it performs
   the common processing described in section 7.1, "Processing AgentX
   Administrative Messages".  If as a result res.error is `
   noAgentXError', processing continues as follows:

   1) If u.subtree, u.priority, u.range_subid (and if u.range_subid is
      not 0, u.upper_bound), and the indicated context do not match an
      existing registration made during this session, the agentx-
      Response-PDU is returned with res.error set to `
      unknownRegistration'.

   2) Otherwise, the agentx-Response-PDU is sent in reply with res.error
      set to `noAgentXError', and the previous registration is removed
      from the registration data store.

7.1.6. Processing the agentx-AddAgentCaps-PDU

   When the master agent receives an agentx-AddAgentCaps-PDU, it
   performs the common processing described in section 7.1, "Processing
   AgentX Administrative Messages".  If as a result res.error is `
   noAgentXError', processing continues as follows:

   1) The master agent adds this agent capabilities information to the
      sysORTable for the indicated context.  An agentx-Response-PDU is
      sent in reply with res.error set to `noAgentXError'.

7.1.7. Processing the agentx-RemoveAgentCaps-PDU

   When the master agent receives an agentx-RemoveAgentCaps-PDU, it
   performs the common processing described in section 7.1, "Processing
   AgentX Administrative Messages".  If as a result res.error is
   `noAgentXError', processing continues as follows:

   1) If the combination of a.id and the optional a.context does not
      represent a sysORTable entry that was added by this subagent
      during this session, the agentx-Response-PDU is returned with
      res.error set to `unknownAgentCaps'.

Top      Up      ToC       Page 56 
   2) Otherwise the master agent deletes the corresponding sysORTable
      entry and sends in reply the agentx-Response-PDU, with res.error
      set to `noAgentXError'.

7.1.8. Processing the agentx-Close-PDU

   When the master agent receives an agentx-Close-PDU, it performs the
   common processing described in section 7.1, "Processing AgentX
   Administrative Messages", with the exception that step 4) is not
   performed since the agentx-Close-PDU does may not contain a context
   field. If as a result res.error is `noAgentXError', processing
   continues as follows:

   1) The master agent closes the AgentX session as described below, and
      sends in reply the agentx-Response-PDU with res.error set to
      `noAgentXError':

      -  All MIB regions that have been registered during this session
         are unregistered, as described in section 7.1.5, "Processing
         the agentx-Unregister-PDU".

      -  All index values allocated during this session are freed, as
         described in section 7.1.3, "Processing the agentx-
         IndexDeallocate-PDU".

      -  All sysORID values that were registered during this session are
         removed, as described in section 7.1.7, "Processing the
         agentx-RemoveAgentCaps-PDU".

   The master agent does not maintain state for closed sessions.  If a
   subagent wishes to re-establish a session after it has been closed,
   it needs to re-register MIB regions, agent capabilities, etc.

7.1.9. Detecting Connection Loss

   If a master agent is able to detect (from the underlying transport)
   that a subagent cannot receive AgentX PDUs, it should close all
   affected AgentX sessions as described in section 7.1.8, "Processing
   the agentx-Close-PDU", step 1).

7.1.10. Processing the agentx-Notify-PDU

   A subagent sending SNMPv1 trap information must map this into
   (minimally) a value of snmpTrapOID.0, as described in 3.1.2 of RFC
   1908 [24].

Top      Up      ToC       Page 57 
   When the master agent receives an agentx-Notify-PDU, it performs the
   common processing described in section 7.1, "Processing AgentX
   Administrative Messages".  If as a result res.error is
   `noAgentXError',  processing continues as follows:

   1) If the first VarBind is sysUpTime.0;

      (a)  if the second VarBind is not snmpTrapOID.0, res.error is set
           to `processingError' and res.index to 2

      (b)  otherwise these two VarBinds are used as the first two
           VarBinds within the generated notification.

   2) If the first VarBind is not sysUpTime.0;

      (a)  if the first VarBind is not snmpTrapOID.0, res.error is set
           to `processingError' and res.index to 1

      (b)  otherwise this VarBind is used for snmpTrapOID.0 within the
           generated notification, and the master agent uses the current
           value of sysUpTime.0 for the indicated context as sysUpTime.0
           within the notification.

   3) An agentx-Response-PDU is sent containing the original
      VarBindList, and with res.error and res.index set as described
      above.  If res.error is `noAgentXError', notifications are sent
      according to the implementation-specific configuration of the
      master agent.  If SNMPv1 Trap PDUs are generated, the recommended
      mapping is as described in RFC 2089 [25].  If res.error indicates
      an error in processing, no notifications are generated.

      Note that the master agent's successful response indicates the
      agentx-Notify-PDU was received and validated.  It does not
      indicate that any particular notifications were actually generated
      or received by notification targets.

7.1.11. Processing the agentx-Ping-PDU

   When the master agent receives an agentx-Ping-PDU, it performs the
   common processing described in section 7.1, "Processing AgentX
   Administrative Messages".     If as a result res.error is `
   noAgentXError', processing continues as follows:

Top      Up      ToC       Page 58 
      1) An agentx-Response-PDU is sent in reply.

   If a subagent does not receive a response to its pings, or if it is
   able to detect (from the underlying transport) that the master agent
   is not able to receive AgentX messages, then it eventually must
   initiate a new AgentX session, re-register its MIB regions, etc.

7.2. Processing Received SNMP Protocol Messages

   When an SNMP GetRequest, GetNextRequest, GetBulkRequest, or
   SetRequest protocol message is received by the master agent, the
   master agent applies its access control policy.

   In particular, for SNMPv1 or SNMPv2c protocol messages, the master
   agent applies the Elements of Procedure defined in section 4.1 of STD
   15, RFC 1157 [8] that apply to receiving entities.  For SNMPv3, the
   master agent applies an Access Control Model, possibly the View-based
   Access Control Model (see RFC 2575 [15]), as described in section
   3.1.2 and section 4.3 of RFC 2571 [1].

   For SNMPv1 and SNMPv2c, the master agent uses the community string as
   an index into a local repository of configuration information that
   may include community profiles or more complex context information.
   For SNMPv3, the master agent uses the SNMP Context (see section 3.3.1
   of RFC 2571 [1]) for these purposes.

   If application of the access control policy results in a valid SNMP
   request PDU, then an SNMP Response-PDU is constructed from
   information gathered in the exchange of AgentX PDUs between the
   master agent and one or more subagents.  Upon receipt and initial
   validation of an SNMP request PDU, a master agent uses the procedures
   described below to dispatch AgentX PDUs to the proper subagents,
   marshal the subagent responses, and construct an SNMP response PDU.

7.2.1. Dispatching AgentX PDUs

   Upon receipt and initial validation of an SNMP request PDU, a master
   agent uses the procedures described below to dispatch AgentX PDUs to
   the proper subagents.

   General Rules of Procedure

   While processing a particular SNMP request, the master agent may send
   one or more AgentX PDUs on one or more subagent sessions.  The
   following rules of procedure apply in general to the AgentX master
   agent.  PDU-specific rules are listed in the applicable sections.

Top      Up      ToC       Page 59 
   1) Honoring the registry

      Because AgentX supports registration of duplicate and overlapping
      regions, it is possible for the master agent to obtain a value for
      a requested varbind from within multiple registered MIB regions.

      The master agent must ensure that the value (or exception)
      actually returned in the SNMP response PDU is taken from the
      authoritative region (as defined in section 7.1.4.1, "Handling
      Duplicate and Overlapping Subtrees").

   2) GetNext and GetBulk Processing

      The master agent may choose to send agentx-Get-PDUs while
      servicing an SNMP GetNextRequest-PDU.  The master agent may choose
      to send agentx-Get-PDUs or agentx-GetNext-PDUs while servicing an
      SNMP GetBulkRequest-PDU.  One possible reason for this would be if
      the current iteration has targeted instance-level registrations.

      The master agent may choose to "scope" the possible instances
      returned by a subagent by specifying an ending OID in the
      SearchRange.  If such scoping is used, typically the ending OID
      would be the first lexicographical successor to the target region
      that was registered on a session other than the target session.
      Regardless of this choice, rule (1) must be obeyed.

      The master agent may require multiple request-response iterations
      on the same subagent session, to determine the final value of all
      requested variables.

      All AgentX PDUs sent on the session while processing a given SNMP
      request must contain identical values of transactionID.  Each
      different SNMP request processed by the master agent must present
      a unique value of transactionID (within the limits of the 32-bit
      field) to the session.

   3) Number and order of variables sent per AgentX PDU

      For Get/GetNext/GetBulk operations, at any stage of the possibly
      iterative process, the master agent may need to dispatch several
      SearchRanges to a particular subagent session.  The master agent
      may send one, some, or all of the SearchRanges in a single AgentX
      PDU.

      The master agent must ensure that the correct contents and
      ordering of the VarBindList in the SNMP Response-PDU are
      maintained.

Top      Up      ToC       Page 60 
      The following rules govern the number of VarBinds in a given
      AgentX PDU:

         a) The subagent must support processing of AgentX PDUs with
            multiple VarBinds.

         b) When processing an SNMP Set request, the master agent must
            send all of the VarBinds applicable to a particular subagent
            session in a single agentx-TestSet-PDU.

         c) When processing an SNMP Get, GetNext, or GetBulk request,
            the master agent may send a single AgentX PDU on the session
            with all applicable VarBinds, or multiple PDUs with single
            VarBinds, or something in between those extremes. The
            determination of which method to use in a particular case is
            implementation-specific.

   4) Timeout Values

      The master agent chooses a timeout value for each MIB region being
      queried, which is

         a) the value specified during registration of the MIB region,
            if it was non-zero

         b) otherwise, the value specified during establishment of the
            session in which this region was subsequently registered, if
            that value was non-zero

         c) otherwise, or, if the specified value is not practical, the
            master agent's implementaton-specific default value

      When an AgentX PDU that references multiple MIB regions is
      dispatched, the timeout value used for the PDU is the maximum
      value of the timeouts so determined for each of the referenced MIB
      regions.

   5) Context

      If the master agent has determined that a specific non-default
      context is associated with the SNMP request PDU, that context is
      encoded into the AgentX PDU's context field and the
      NON_DEFAULT_CONTEXT bit is set in h.flags.

      Otherwise, no context Octet String is added to the PDU, and the
      NON_DEFAULT_CONTEXT bit is cleared.

Top      Up      ToC       Page 61 
7.2.1.1.  agentx-Get-PDU

   Each variable binding in the SNMP request PDU is processed as
   follows:

   (1)  Identify the target MIB region.

        Within a lexicographically ordered set of registered MIB
        regions, valid for the indicated context, locate the
        authoritative region (according to section 7.1.4.1, "Handling
        Duplicate and Overlapping Subtrees") that contains the binding's
        name.

   (2)  If no such region exists, the variable binding is not processed
        further, and its value is set to `noSuchObject'.

   (3)  Identify the subagent session in which this region was
        registered, termed the target session.

   (4)  If this is the first variable binding to be dispatched over the
        target session in a request-response exchange entailed in the
        processing of this management request:

         -  Create an agentx-Get-PDU for this session, with the header
            fields initialized as described above (see section 6.1,
            "AgentX PDU Header").

   (5)  Add a SearchRange to the end of the target session's PDU for
        this variable binding.

        - The variable binding's name is encoded into the starting OID.

        - The ending OID is encoded as null.

7.2.1.2.  agentx-GetNext-PDU

   Each variable binding in the SNMP request PDU is processed as
   follows:

   (1)  Identify the target MIB region.

        Within a lexicographically ordered set of registered MIB
        regions, valid for the indicated context, locate the
        authoritative region (according to section 7.1.4.1, "Handling
        Duplicate and Overlapping Subtrees") that

        a) contains the variable binding's name and is not a fully
           qualified instance, or

Top      Up      ToC       Page 62 
        b) is the first lexicographical successor to the variable
           binding's name.

   (2)  If no such region exists, the variable binding is not processed
        further, and its value is set to `endOfMibView'.

   (3)  Identify the subagent session in which this region was
        registered, termed the target session.

   (4)  If this is the first variable binding to be dispatched over the
        target session in a request-response exchange entailed in the
        processing of this management request:

        -  Create an agentx-GetNext-PDU for the session, with the header
           fields initialized as described above (see section 6.1,
           "AgentX PDU Header").

   (5)  Add a SearchRange to the end of the target session's agentx-
        GetNext-PDU for this variable binding.

        -  if (1a) applies, the variable binding's name is encoded into
           the starting OID, and the OID's "include" field is set to 0.

        -  if (1b) applies, the target region's r.subtree is encoded
           into the starting OID, and its "include" field is set to 1.
           (This is the recommended method.  An implementation may
           choose to use a Starting OID value that precedes r.subtree,
           in which case the include bit must be 0.  A starting OID
           value that succeeds r.subtree is not permitted.)

        -  the Ending OID for the SearchRange is encoded to be either
           NULL, or a value that lexicographically succeeds the Starting
           OID.  This is an implementation-specific choice depending on
           how the master agent wishes to "scope" the possible returned
           instances.

7.2.1.3.  agentx-GetBulk-PDU

   (Note: The outline of the following procedure is based closely on
   section 4.2.3, "The GetBulkRequest-PDU" of RFC 1905 [13].  Please
   refer to it for details on the format of the SNMP GetBulkRequest-PDU
   itself.)

Top      Up      ToC       Page 63 
   Each variable binding in the request PDU is processed as follows:

   (1)  Identify the authoritative target region and target session,
        exactly as described for the agentx-GetNext-PDU (see section
        7.2.1.2, "agentx-GetNext-PDU").

   (2)  If this is the first variable binding to be dispatched over the
        target session in a request-response exchange entailed in the
        processing of this management request:

        -  Create an agentx-GetBulk-PDU for the session, with the header
           fields initialized as described above (see section 6.1,
           "AgentX PDU Header").

   (3)  Add a SearchRange to the end of the target session's agentx-
        GetBulk-PDU for this variable binding, as described for the
        agentx-GetNext-PDU.  If the variable binding was a non-repeater
        in the original request PDU, it must be a non-repeater in the
        agentx-GetBulk-PDU.

   The value of g.max_repetitions in the agentx-GetBulk-PDU may be less
   than (but not greater than) the value in the original request PDU.

   The master agent may make such alterations due to simple sanity
   checking, optimizations for the current iteration based on the
   registry, the maximum possible size of a potential Response-PDU,
   known constraints of the AgentX transport, or any other
   implementation-specific constraint.

7.2.1.4.  agentx-TestSet-PDU

   AgentX employs test-commit-undo-cleanup phases to achieve "as if
   simultaneous" semantics of the SNMP SetRequest-PDU within the
   extensible agent.  The initial phase involves the agentx-TestSet-PDU.

   Each variable binding in the SNMP request PDU is processed in order,
   as follows:

   (1)  Identify the target MIB region and target session exactly as
        described in section 7.2.1.1, "agentx-Get-PDU", step 1).

        Within a lexicographically ordered set of OID ranges, valid for
        the indicated context, locate the authoritative range that
        contains the variable binding's name.

   (2)  If no such target region exists, this variable binding fails
        with an error of `notWritable'.  Processing is complete for this
        request.

Top      Up      ToC       Page 64 
   (3)  If this is the first variable binding to be dispatched over the
        target session in a request-response exchange entailed in the
        processing of this management request:

        -  create an agentx-TestSet-PDU for the session, with the header
           fields initialized as described above (see section 6.1,
           "AgentX PDU Header").

   (4)  Add a VarBind to the end of the target session's PDU for this
        variable binding, as described in section 5.4, "Value
        Representation".

   Note that all VarBinds applicable to a given session must be sent in
   a single agentx-TestSet-PDU.

7.2.1.5.  Dispatch

   A timeout value is calculated for each PDU to be sent, which is the
   maximum value of the timeouts determined for each of the PDU's
   SearchRanges (as described above in section 7.2.1, "Dispatching
   AgentX PDUs", item 4). Each pending PDU is mapped (via its
   h.sessionID value) to a particular transport domain/endpoint, as
   described in section 8 (Transport Mappings).

7.2.2. Subagent Processing

   A subagent initially processes a received AgentX PDU as follows:

   -  If the received PDU is an agentx-Response-PDU:

   1) If there are any errors parsing or interpreting the PDU, it is
      silently dropped.

   2) Otherwise the response is matched to the original request via
      h.packetID, and handled in an implementation-specific manner.  For
      example, if this response indicates an error attempting to
      register a MIB region, the subagent may wish to register a
      different region, or log an error and halt, etc.

   -  If the received PDU is any other type:

   1) an agentx-Response-PDU is created whose header fields are
      identical to the received request PDU except that h.type is set to
      Response, res.error to `noError', res.index to 0, and the
      VarBindList to null.

   2) If the received PDU cannot be parsed, res.error is set to
      `parseError'.

Top      Up      ToC       Page 65 
   3) Otherwise, if h.sessionID does not correspond to a currently
      established session, res.error is set to `notOpen'.

   4) At this point, if res.error is not `noError', the received PDU is
      not processed further.  If the received PDU's header was
      successfully parsed, the AgentX-Response-PDU is sent in reply.  If
      the received PDU's header was not successfully parsed or for some
      other reason the subagent cannot send a reply, processing is
      complete.

7.2.3. Subagent Processing of agentx-Get, GetNext, GetBulk-PDUs

   A conformant AgentX subagent must support the agentx-Get, -GetNext,
   and -GetBulk PDUs, and must support multiple variables being supplied
   in each PDU.

   When a subagent receives an agentx-Get-, GetNext-, or GetBulk-PDU, it
   performs the indicated management operations and returns an agentx-
   Response-PDU.

   Each SearchRange in the request PDU's SearchRangeList is processed as
   described below, and a VarBind is added in the corresponding location
   of the agentx-Response-PDU's  VarbindList.  If processing should fail
   for any reason not described below, res.error is set to `genErr',
   res.index to the index of the failed SearchRange, the VarBindList is
   reset to null, and this agentx-Response-PDU is returned to the master
   agent.

7.2.3.1.  Subagent Processing of the agentx-Get-PDU

   Upon the subagent's receipt of an agentx-Get-PDU, each SearchRange in
   the request is processed as follows:

   (1)  The starting OID is copied to v.name.

   (2)  If the starting OID exactly matches the name of a variable
        instantiated by this subagent within the indicated context and
        session, v.type and v.data are encoded to represent the
        variable's syntax and value, as described in section 5.4, "Value
        Representation".

   (3)  Otherwise, if the starting OID does not match the object
        identifier prefix of any variable instantiated within the
        indicated context and session, the VarBind is set to
        `noSuchObject', in the manner described in section 5.4, "Value
        Representation".

Top      Up      ToC       Page 66 
   (4)  Otherwise, the VarBind is set to `noSuchInstance' in the manner
        described in section 5.4, "Value Representation".

7.2.3.2.  Subagent Processing of the agentx-GetNext-PDU

   Upon the subagent's receipt of an agentx-GetNext-PDU, each
   SearchRange in the request is processed as follows:

   (1)  The subagent searches for a variable within the
        lexicographically ordered list of variable names for all
        variables it instantiates (without regard to registration of
        regions) within the indicated context and session, as follows:

        -  if the "include" field of the starting OID is 0, the
           variable's name is the closest lexicographical successor to
           the starting OID.

        -  if the "include" field of the starting OID is 1, the
           variable's name is either equal to, or the closest
           lexicographical successor to, the starting OID.

        -  If the ending OID is not null, the variable's name
           lexicographically precedes the ending OID.

        If a variable is successfully located, v.name is set to that
        variable's name.  v.type and v.data are encoded to represent the
        variable's syntax and value, as described in section 5.4, "Value
        Representation".

   (2)  If the subagent cannot locate an appropriate variable, v.name is
        set to the starting OID, and the VarBind is set to `
        endOfMibView', in the manner described in section 5.4, "Value
        Representation".

7.2.3.3.  Subagent Processing of the agentx-GetBulk-PDU

   A maximum of N + (M * R) VarBinds are returned, where

      N equals g.non_repeaters,
      M equals g.max_repetitions, and
      R is (number of SearchRanges in the GetBulk request) - N.

   The first N SearchRanges are processed exactly as for the agentx-
   GetNext-PDU.

   If M and R are both non-zero, the remaining R SearchRanges are
   processed iteratively to produce potentially many VarBinds.  For each
   iteration i, such that i is greater than zero and less than or equal

Top      Up      ToC       Page 67 
   to M, and for each repeated SearchRange s, such that s is greater
   than zero and less than or equal to R, the (N+((i-1)*R)+s)-th VarBind
   is added to the agentx-Response-PDU as follows:

      1) The subagent searches for a variable within the
         lexicographically ordered list of variable names for all
         variables it instantiates (without regard to registration of
         regions) within the indicated context and session, for which
         the following are all true:

         -  The variable's name is the (i)-th lexicographical successor
            to the (N+s)-th requested OID.

            (Note that if i is 0 and the "include" field is 1, the
            variable's name may be equivalent to, or the first
            lexicographical successor to, the (N+s)-th requested OID.)

         -  If the ending OID is not null, the variable's name
            lexicographically precedes the ending OID.

      If all of these conditions are met, v.name is set to the located
      variable's name.  v.type and v.data are encoded to represent the
      variable's syntax and value, as described in section 5.4, "Value
      Representation".

      2) If no such variable exists, the VarBind is set to `
         endOfMibView' as described in section 5.4, "Value
         Representation".  v.name is set to v.name of the (N+((i-
         2)*R)+s)-th VarBind unless i is currently 1, in which case it
         is set to the value of the starting OID in the (N+s)-th
         SearchRange.

   Note that further iterative processing should stop if

         -  For any iteration i, all s values of v.type are `
            endOfMibView'.

         -  An AgentX transport constraint or other implementation-
            specific constraint is reached.

7.2.4. Subagent Processing of agentx-TestSet, -CommitSet, -UndoSet,
                   -CleanupSet-PDUs

   A conformant AgentX subagent must support the agentx-TestSet,
   -CommitSet, -UndoSet, and -CleanupSet PDUs, and must support multiple
   variables being supplied in the agentx-TestSet-PDU.

Top      Up      ToC       Page 68 
   These four PDUs are used to collectively perform the indicated
   management operation.  An agentx-Response-PDU is sent in reply to
   each of the PDUs (except -CleanupSet), to inform the master agent of
   the state of the operation.

   The master agent must serialize Set transactions for each session.
   That is, a session need not handle multiple concurrent Set
   transactions.

   These Response-PDUs do not contain a VarBindList.

7.2.4.1.  Subagent Processing of the agentx-TestSet-PDU

   Upon the subagent's receipt of an agentx-TestSet-PDU, each VarBind in
   the PDU is validated until they are all successful, or until one
   fails, as described in section 4.2.5 of RFC 1905 [13]. The subagent
   validates variables with respect to the context and session indicated
   in the testSet-PDU.

   If each VarBind is successful, the subagent has a further
   responsibility to ensure the availability of all resources (memory,
   write access, etc.) required for successfully carrying out a
   subsequent agentx-CommitSet operation.  If this cannot be guaranteed,
   the subagent should set res.error to `resourceUnavailable'.  As a
   result of this validation step, an agentx-Response-PDU is sent in
   reply whose res.error field is set to one of the following SNMPv2 PDU
   error-status values (see section 3, "Definitions", in RFC 1905 [13]):

            noError                    (0),
            genErr                     (5),
            noAccess                   (6),
            wrongType                  (7),
            wrongLength                (8),
            wrongEncoding              (9),
            wrongValue                (10),
            noCreation                (11),
            inconsistentValue         (12),
            resourceUnavailable       (13),
            notWritable               (17),
            inconsistentName          (18)

   If this value is not `noError', the res.index field must be set to
   the index of the VarBind for which validation failed.

Top      Up      ToC       Page 69 
   Implementation of rigorous validation code may be one of the most
   demanding aspects of subagent development.  Implementors are strongly
   encouraged to do this right, so as to avoid if at all possible the
   extensible agent's having to return `commitFailed' or `undoFailed'
   during subsequent processing.

7.2.4.2.  Subagent Processing of the agentx-CommitSet-PDU

   The agentx-CommitSet-PDU indicates that the subagent should actually
   perform (as described in the post-validation sections of 4.2.5 of RFC
   1905 [13]) the management operation indicated by the previous
   TestSet-PDU.  After carrying out the management operation, the
   subagent sends in reply an agentx-Response-PDU whose res.error field
   is set to one of the following SNMPv2 PDU error-status values (see
   section 3, "Definitions", in RFC 1905 [13]):

            noError                    (0),
            commitFailed              (14)

   If this value is `commitFailed', the res.index field must be set to
   the index of the VarBind (as it occurred in the agentx-TestSet-PDU)
   for which the operation failed.  Otherwise res.index is set to 0.

7.2.4.3.  Subagent Processing of the agentx-UndoSet-PDU

   The agentx-UndoSet-PDU indicates that the subagent should undo the
   management operation requested in a preceding CommitSet-PDU.  The
   undo process is as described in section 4.2.5 of RFC 1905 [13].

   After carrying out the undo process, the subagent sends in reply an
   agentx-Response-PDU whose res.error field is set to one of the
   following SNMPv2 PDU error-status values (see section 3,
   "Definitions", in RFC 1905 [13]):

            noError                    (0),
            undoFailed                (15)

   If this value is `undoFailed', the res.index field must be set to the
   index of the VarBind (as it occurred in the agentx-TestSet-PDU) for
   which the operation failed.  Otherwise res.index is set to 0.

   This PDU also signals the end of processing of the management
   operation initiated by the previous TestSet-PDU.  The subagent should
   release resources, etc. as described in section 7.2.4.4, "Subagent
   Processing of the agentx-CleanupSet-PDU".

Top      Up      ToC       Page 70 
7.2.4.4.  Subagent Processing of the agentx-CleanupSet-PDU

   The agentx-CleanupSet-PDU signals the end of processing of the
   management operation requested in the previous TestSet-PDU.  This is
   an indication to the subagent that it may now release any resources
   it may have reserved in order to carry out the management request.
   No response is sent by the subagent.

7.2.5. Master Agent Processing of AgentX Responses

   The master agent now marshals all subagent AgentX response PDUs and
   builds an SNMP response PDU.  In the next several subsections, the
   initial processing of all subagent AgentX response PDUs is described,
   followed by descriptions of subsequent processing for each specific
   subagent Response.

7.2.5.1.  Common Processing of All AgentX Response PDUs

   1) If a response is not received on a session within the timeout
      interval for this dispatch, it is treated as if the subagent had
      returned `genErr' and processed as described below.

      A timeout may be due to a variety of reasons, and does not
      necessarily denote a failed or malfunctioning subagent.  As such,
      the master agent's response to a subagent timeout is
      implementation-specific, but with the following constraint:

      A session that times out on three consecutive AgentX requests is
      considered unable to respond, and the master agent must close the
      AgentX session as described in section 7.1.8, "Processing the
      agentx-Close-PDU", step (2).

   2) Otherwise, the h.packetID, h.sessionID, and h.transactionID fields
      of the AgentX response PDU are used to correlate subagent
      responses.  If the response does not pertain to this SNMP
      operation, it is ignored.

   3) Otherwise, the responses are processed jointly to form the SNMP
      response PDU.

7.2.5.2.  Processing of Responses to agentx-Get-PDUs

   After common processing of the subagent's response to an agentx-Get-
   PDU (see section 7.2.5.1, "Common Processing of All AgentX Response
   PDUs", above), processing continues with the following steps:

Top      Up      ToC       Page 71 
   1) For any received AgentX response PDU, if res.error is not
      `noError', the SNMP response PDU's error code is set to this
      value.  If res.error contains an AgentX specific value (e.g.
      `parseError'), the SNMP response PDU's error code is set to a
      value of genErr instead.  Also, the SNMP response PDU's error
      index is set to the index of the variable binding corresponding to
      the failed VarBind in the subagent's AgentX response PDU.

      All other AgentX response PDUs received due to processing this
      SNMP request are ignored.  Processing is complete; the SNMP
      Response PDU is ready to be sent (see section 7.2.6, "Sending the
      SNMP Response-PDU").

   2) Otherwise, the content of each VarBind in the AgentX response PDU
      is used to update the corresponding variable binding in the SNMP
      Response-PDU.

7.2.5.3.  Processing of Responses to agentx-GetNext-PDU and
                agentx-GetBulk-PDU

   After common processing of the subagent's response to an agentx-
   GetNext-PDU or agentx-GetBulk-PDU (see section 7.2.5.1, "Common
   Processing of All AgentX Response PDUs", above), processing continues
   with the following steps:

   1) For any received AgentX response PDU, if res.error is not
      `noError', the SNMP response PDU's error code is set to this
      value.  If res.error contains an AgentX specific value (e.g.
      `parseError'), the SNMP response PDU's error code is set to a
      value of genErr instead.  Also, the SNMP response PDU's error
      index is set to the index of the variable binding corresponding to
      the failed VarBind in the subagent's AgentX response PDU.

      All other AgentX response PDUs received due to processing this
      SNMP request are ignored.  Processing is complete; the SNMP
      response PDU is ready to be sent (see section 7.2.6, "Sending the
      SNMP Response-PDU").

   2) Otherwise, the content of each VarBind in the AgentX response PDU
      is used to update the corresponding VarBind in the SNMP response
      PDU.

   After all expected AgentX response PDUs have been processed, if any
   VarBinds still contain the value `endOfMibView' in their v.type
   fields, processing must continue:

Top      Up      ToC       Page 72 
   3) A new iteration of AgentX request dispatching is initiated (as
      described in section 7.2.1.2, "agentx-GetNext-PDU"), in which only
      those VarBinds whose v.type is `endOfMibView' are processed.

   4) For each such VarBind, an authoritative target MIB region is
      identified in which the master agent expects to find suitable MIB
      variables.  The target session is the one on which this new target
      region was registered.

      The starting OID in each SearchRange is set to the value of v.name
      for the corresponding VarBind, and its "include" field is set to
      0.

   5) The value of transactionID must be identical to the value used
      during the previous iteration.

   6) The AgentX PDUs are sent on the target session(s), and the
      responses are received and processed according to the steps
      described in section 7.2.5, "Master Agent Processing of AgentX
      Responses".

   7) This process continues iteratively until a complete SNMP
      Response-PDU has been built, or until there remain no
      authoritative MIB regions to query.

   Note that r.subtree for the new target region identified in step 4)
   may not lexicographically succeed r.subtree for the region that has
   returned `endOfMibView'.  For example, consider the following
   registry:

        session A   `mib-2' (1.3.6.1.2.1)
        session B   `ip'    (1.3.6.1.2.1.4)
        session C   `tcp'   (1.3.6.1.2.1.6)

   If while processing a GetNext-Request-PDU session B returns
   `endOfMibView' for a variable name within 1.3.6.1.2.1.4, the target
   MIB region identified in step 4) would be 1.3.6.1.2.1 (since it may
   contain variables whose names precede 1.3.6.1.2.1.6).

   Note also that if session A returned variables from within
   1.3.6.1.2.1.6, they must be discarded since session A is NOT
   authoritative for that region.

7.2.5.4.  Processing of Responses to agentx-TestSet-PDUs

   After common processing of the subagent's response to an agentx-
   TestSet-PDU (see section 7.2.5.1, "Common Processing of All AgentX
    Response PDUs", above), processing continues with the further

Top      Up      ToC       Page 73 
   exchange of AgentX PDUs.  The value of h.transactionID in the
   agentx-CommitSet, -UndoSet, and -CleanupSet-PDUs must be identical to
   the value sent in the testSet-PDU.

   The state transitions and PDU sequences are depicted in section 7.3,
   "State Transitions".

   The set of all sessions who have been sent an agentx-TestSet-PDU for
   this particular transaction are referred to below as "involved
   sessions".

   1) If any target session's response is not `noError', all other
      agentx-Response-PDUs received due to processing this SNMP request
      are ignored.

      An agentx-CleanupSet-PDU is sent to all involved sessions.
      Processing is complete; the SNMP response PDU is constructed as
      described below in 7.2.6, "Sending the SNMP Response-PDU".

   2) Otherwise an agentx-CommitSet-PDU is sent to all involved
      sessions.

7.2.5.5.  Processing of Responses to agentx-CommitSet-PDUs

   After common processing of the subagent's response to an agentx-
   CommitSet-PDU (see section 7.2.5.1, "Common Processing of All AgentX
   Response PDUs", above), processing continues with the following
   steps:

   1) If any response is not `noError', the SNMP response PDU's error
      code is set to this value.  If res.error contains an AgentX
      specific value (e.g. `parseError'), the SNMP response PDU's error
      code is set to a value of genErr instead.  Also, the SNMP response
      PDU's error index is set to the index of the VarBind corresponding
      to the failed VarBind in the agentx-TestSet-PDU.

      An agentx-UndoSet-PDU is sent to each target session that has been
      sent an agentx-CommitSet-PDU.  An agentx-CleanupSet-PDU is sent to
      the remainder of the involved sessions.

   2) Otherwise an agentx-CleanupSet-PDU is sent to all involved
      sessions.  Processing is complete; the SNMP response PDU is
      constructed as described below in section 7.2.6, "Sending the SNMP
      Response-PDU".

Top      Up      ToC       Page 74 
7.2.5.6.  Processing of Responses to agentx-UndoSet-PDUs

   After common processing of the subagent's response to an agentx-
   UndoSet-PDU (see section 7.2.5.1, "Common Processing of All AgentX
   Response PDUs", above), processing continues with the following
   steps:

   1) If any response is `undoFailed' the SNMP response PDU's error code
      is set to this value.  Also, the SNMP response PDU's error index
      is set to 0.

   2) Otherwise, if any response is not `noError' the SNMP response
      PDU's error code is set to this value.  Also, the SNMP response
      PDU's error index is set to the index of the VarBind corresponding
      to the failed VarBind in the agentx-TestSet-PDU. If res.error is
      an AgentX specific value (e.g. `parseError'), the SNMP response
      PDU's error code is set to a value of genErr instead.

   3) Otherwise the SNMP response PDU's error code and error index were
      set in section 7.2.5.5 step 1)

7.2.6. Sending the SNMP Response-PDU

   Once the processing described in section 7.2.5, "Master Agent
   Processing of AgentX Responses" is complete, there is an SNMP
   response PDU available.  The master agent now implements the Elements
   of Procedure for the applicable version of the SNMP protocol in order
   to encapsulate the PDU into a message, and transmit it to the
   originator of the SNMP management request.  Note that this may
   involve altering the PDU contents (for instance, to replace the
   original VarBinds if an error condition is to be returned).

   The response PDU may also be altered in order to support the SNMPv1
   PDU.  In such cases the required PDU mapping is that defined in RFC
   2089 [25].  (Note in particular that the rules for handling Counter64
   syntax may require re-sending AgentX GetBulk or GetNext PDUs until a
   VarBind of suitable syntax is returned.)

7.2.7. MIB Views

   AgentX subagents are not aware of MIB views, since view information
   is not contained in AgentX PDUs.

   As stated above, the descriptions of procedures in section 7,
   "Elements of Procedure", of this memo are not intended to constrain
   the internal architecture of any conformant implementation.  In
   particular, the master agent procedures described in section 7.2.1,

Top      Up      ToC       Page 75 
   "Dispatching AgentX PDUs" and in section 7.2.5, "Master Agent
   Processing of AgentX Responses" may be altered so as to optimize
   AgentX exchanges when implementing MIB views.

   Such optimizations are beyond the scope of this memo.  But note that
   section 7.2.3, "Subagent Processing of agentx-Get, GetNext, GetBulk-
   PDUs",  defines subagent behavior in such a way that alteration of
   SearchRanges may be used in such optimizations.



(page 75 continued on part 4)

Next RFC Part