5.  Identification of Management Targets in Notification Originators

   This section describes the mechanisms used by a notification
   originator application when using the MIB module described in this
   document to determine the set of management targets to be used when
   generating a notification.

   A notification originator uses each entry in the snmpNotifyTable to
   find the management targets to be used for generating notifications.
   Each active entry in this table identifies zero or more entries in
   the snmpTargetAddrTable.  Any entry in the snmpTargetAddrTable whose
   snmpTargetAddrTagList object contains a tag value which is equal to a
   value of snmpNotifyTag is selected by the snmpNotifyEntry which
   contains that instance of snmpNotifyTag.  Note that a particular
   snmpTargetAddrEntry may be selected by multiple entries in the
   snmpNotifyTable, resulting in multiple notifications being generated
   using that snmpTargetAddrEntry.

   Each snmpTargetAddrEntry contains a pointer to the
   snmpTargetParamsTable (snmpTargetAddrParams).  This pointer selects a
   set of SNMP parameters to be used for generating notifications.  If
   the selected entry in the snmpTargetParamsTable does not exist, the
   management target is not used to generate notifications.

   The decision as to whether a notification should contain an
   Unconfirmed-Class or a Confirmed-Class PDU is determined by the value
   of the snmpNotifyType object.  If the value of this object is
   trap(1), the notification should contain an Unconfirmed-Class PDU.

   If the value of this object is inform(2), then the notification
   should contain a Confirmed-Class PDU, and the timeout time and number
   of retries for the notification are the value of
   snmpTargetAddrTimeout and snmpTargetAddrRetryCount.  Note that the
   exception to these rules is when the snmpTargetParamsMPModel object
   indicates an SNMP version which supports a different PDU version.  In
   this case, the notification may be sent using a different PDU type
   ([COEX] defines the PDU type in the case where the outgoing SNMP
   version is SNMPv1).

6.  Notification Filtering

   This section describes the mechanisms used by a notification
   originator application when using the MIB module described in this
   document to filter generation of notifications.

   A notification originator uses the snmpNotifyFilterTable to filter
   notifications.  A notification filter profile may be associated with
   a particular entry in the snmpTargetParamsTable.  The associated
   filter profile is identified by an entry in the
   snmpNotifyFilterProfileTable whose index is equal to the index of the
   entry in the snmpTargetParamsTable.  If no such entry exists in the
   snmpNotifyFilterProfileTable, no filtering is performed for that
   management target.

   If such an entry does exist, the value of snmpNotifyFilterProfileName
   of the entry is compared with the corresponding portion of the index
   of all active entries in the snmpNotifyFilterTable.  All such entries
   for which this comparison results in an exact match are used for
   filtering a notification generated using the associated
   snmpTargetParamsEntry.  If no such entries exist, no filtering is
   performed, and a notification may be sent to the management target.

   Otherwise, if matching entries do exist, a notification may be sent
   if the NOTIFICATION-TYPE OBJECT IDENTIFIER of the notification (this
   is the value of the element of the variable bindings whose name is
   snmpTrapOID.0, i.e., the second variable binding) is specifically
   included, and none of the object instances to be included in the
   variable-bindings of the notification are specifically excluded by
   the matching entries.

   Each set of snmpNotifyFilterTable entries is divided into two
   collections of filter subtrees:  the included filter subtrees, and
   the excluded filter subtrees.  The snmpNotifyFilterType object
   defines the collection to which each matching entry belongs.

   To determine whether a particular notification name or object
   instance is excluded by the set of matching entries, compare the
   notification name's or object instance's OBJECT IDENTIFIER with each
   of the matching entries.  For a notification name, if none match,
   then the notification name is considered excluded, and the
   notification should not be sent to this management target.  For an
   object instance, if none match, the object instance is considered
   included, and the notification may be sent to this management target.
   If one or more match, then the notification name or object instance
   is included or excluded, according to the value of
   snmpNotifyFilterType in the entry whose value of
   snmpNotifyFilterSubtree has the most sub-identifiers.  If multiple
   entries match and have the same number of sub-identifiers, then the
   lexicographically greatest instance of snmpNotifyFilterType among
   those which match determines the inclusion or exclusion.

   A notification name or object instance's OBJECT IDENTIFIER X matches
   an entry in the snmpNotifyFilterTable when the number of sub-
   identifiers in X is at least as many as in the value of
   snmpNotifyFilterSubtree for the entry, and each sub-identifier in the
   value of snmpNotifyFilterSubtree matches its corresponding sub-
   identifier in X.  Two sub-identifiers match either if the
   corresponding bit of snmpNotifyFilterMask is zero (the 'wild card'
   value), or if the two sub-identifiers are equal.

7.  Management Target Translation in Proxy Forwarder Applications

   This section describes the mechanisms used by a proxy forwarder
   application when using the MIB module described in this document to
   translate incoming management target information into outgoing
   management target information for the purpose of forwarding messages.
   There are actually two mechanisms a proxy forwarder may use, one for
   forwarding request messages, and one for forwarding notification
   messages.

7.1.  Management Target Translation for Request Forwarding

   When forwarding request messages, the proxy forwarder will select a
   single entry in the snmpProxyTable.  To select this entry, it will
   perform the following comparisons:

     -  The snmpProxyType must be read(1) if the request is a Read-
        Class PDU.  The snmpProxyType must be write(2) if the request is
        a Write-Class PDU.

     -  The contextEngineID must equal the snmpProxyContextEngineID
        object.

     -  If the snmpProxyContextName object is supported, it must equal
        the contextName.

     -  The snmpProxyTargetParamsIn object identifies an entry in the
        snmpTargetParamsTable.  The messageProcessingModel,
        securityLevel, security model, and securityName must match the
        values of snmpTargetParamsMPModel,
        snmpTargetParamsSecurityModel, snmpTargetParamsSecurityName, and
        snmpTargetParamsSecurityLevel of the identified entry in the
        snmpTargetParamsTable.

   There may be multiple entries in the snmpProxyTable for which these
   comparisons succeed.  The entry whose snmpProxyName has the
   lexicographically smallest value and for which the comparisons
   succeed will be selected by the proxy forwarder.

   The outgoing management target information is identified by the value
   of the snmpProxySingleTargetOut object of the selected entry.  This
   object identifies an entry in the snmpTargetAddrTable.  The
   identified entry in the snmpTargetAddrTable also contains a reference
   to the snmpTargetParamsTable (snmpTargetAddrParams).  If either the
   identified entry in the snmpTargetAddrTable does not exist, or the
   identified entry in the snmpTargetParamsTable does not exist, then
   this snmpProxyEntry does not identify valid forwarding information,
   and the proxy forwarder should attempt to identify another row.

   If there is no entry in the snmpProxyTable for which all of the
   conditions above may be met, then there is no appropriate forwarding
   information, and the proxy forwarder should take appropriate actions.

   Otherwise, The snmpTargetAddrTDomain, snmpTargetAddrTAddress,
   snmpTargetAddrTimeout, and snmpTargetRetryCount of the identified
   snmpTargetAddrEntry, and the snmpTargetParamsMPModel,
   snmpTargetParamsSecurityModel, snmpTargetParamsSecurityName, and
   snmpTargetParamsSecurityLevel of the identified snmpTargetParamsEntry
   are used as the destination management target.

7.2.  Management Target Translation for Notification Forwarding

   When forwarding notification messages, the proxy forwarder will
   select multiple entries in the snmpProxyTable.  To select these
   entries, it will perform the following comparisons:

     -  The snmpProxyType must be trap(3) if the notification is an
        Unconfirmed-Class PDU.  The snmpProxyType must be inform(4) if
        the request is a Confirmed-Class PDU.

     -  The contextEngineID must equal the snmpProxyContextEngineID
        object.

     -  If the snmpProxyContextName object is supported, it must equal
        the contextName.

     -  The snmpProxyTargetParamsIn object identifies an entry in the
        snmpTargetParamsTable.  The messageProcessingModel,
        securityLevel, security model, and securityName must match the
        values of snmpTargetParamsMPModel,
        snmpTargetParamsSecurityModel, snmpTargetParamsSecurityName, and
        snmpTargetParamsSecurityLevel of the identified entry in the
        snmpTargetParamsTable.

   All entries for which these conditions are met are selected.  The
   snmpProxyMultipleTargetOut object of each such entry is used to
   select a set of entries in the snmpTargetAddrTable.  Any
   snmpTargetAddrEntry whose snmpTargetAddrTagList object contains a tag
   value equal to the value of snmpProxyMultipleTargetOut, and whose
   snmpTargetAddrParams object references an existing entry in the
   snmpTargetParamsTable, is selected as a destination for the forwarded
   notification.

8.  Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   intellectual property or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; neither does it represent that it
   has made any effort to identify any such rights.  Information on the
   IETF's procedures with respect to rights in standards-track and
   standards-related documentation can be found in BCP-11.  Copies of
   claims of rights made available for publication and any assurances of
   licenses to be made available, or the result of an attempt made to
   obtain a general license or permission for the use of such
   proprietary rights by implementors or users of this specification can
   be obtained from the IETF Secretariat.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights which may cover technology that may be required to practice
   this standard.  Please address the information to the IETF Executive
   Director.

9.  Acknowledgments

   This document is the result of the efforts of the SNMPv3 Working
   Group.  Some special thanks are in order to the following SNMPv3 WG
   members:

     Harald Tveit Alvestrand (Maxware)
     Dave Battle (SNMP Research, Inc.)
     Alan Beard (Disney Worldwide Services)
     Paul Berrevoets (SWI Systemware/Halcyon Inc.)
     Martin Bjorklund (Ericsson)
     Uri Blumenthal (IBM T.J. Watson Research Center)
     Jeff Case (SNMP Research, Inc.)
     John Curran (BBN)
     Mike Daniele (Compaq Computer Corporation)
     T. Max Devlin (Eltrax Systems)
     John Flick (Hewlett Packard)
     Rob Frye (MCI)
     Wes Hardaker (U.C.Davis, Information Technology - D.C.A.S.)
     David Harrington (Cabletron Systems Inc.)
     Lauren Heintz (BMC Software, Inc.)
     N.C. Hien (IBM T.J. Watson Research Center)
     Michael Kirkham (InterWorking Labs, Inc.)
     Dave Levi (SNMP Research, Inc.)
     Louis A Mamakos (UUNET Technologies Inc.)
     Joe Marzot (Nortel Networks)
     Paul Meyer (Secure Computing Corporation)
     Keith McCloghrie (Cisco Systems)
     Bob Moore (IBM)
     Russ Mundy (TIS Labs at Network Associates)
     Bob Natale (ACE*COMM Corporation)
     Mike O'Dell (UUNET Technologies Inc.)
     Dave Perkins (DeskTalk)
     Peter Polkinghorne (Brunel University)
     Randy Presuhn (BMC Software, Inc.)
     David Reeder (TIS Labs at Network Associates)
     David Reid (SNMP Research, Inc.)
     Aleksey Romanov (Quality Quorum)
     Shawn Routhier (Epilogue)
     Juergen Schoenwaelder (TU Braunschweig)
     Bob Stewart (Cisco Systems)
     Mike Thatcher (Independent Consultant)
     Bert Wijnen (IBM T.J. Watson Research Center)

   The document is based on recommendations of the IETF Security and
   Administrative Framework Evolution for SNMP Advisory Team. Members of
   that Advisory Team were:

     David Harrington (Cabletron Systems Inc.)
     Jeff Johnson (Cisco Systems)
     David Levi (SNMP Research Inc.)
     John Linn (Openvision)
     Russ Mundy (Trusted Information Systems) chair
     Shawn Routhier (Epilogue)
     Glenn Waters (Nortel)
     Bert Wijnen (IBM T. J. Watson Research Center)

   As recommended by the Advisory Team and the SNMPv3 Working Group
   Charter, the design incorporates as much as practical from previous
   RFCs and drafts. As a result, special thanks are due to the authors
   of previous designs known as SNMPv2u and SNMPv2*:

     Jeff Case (SNMP Research, Inc.)
     David Harrington (Cabletron Systems Inc.)
     David Levi (SNMP Research, Inc.)
     Keith McCloghrie (Cisco Systems)
     Brian O'Keefe (Hewlett Packard)
     Marshall T. Rose (Dover Beach Consulting)
     Jon Saperia (BGS Systems Inc.)
     Steve Waldbusser (International Network Services)
     Glenn W. Waters (Bell-Northern Research Ltd.)

10.  Security Considerations

   The SNMP applications described in this document typically have
   direct access to MIB instrumentation.  Thus, it is very important
   that these applications be strict in their application of access
   control as described in this document.

   In addition, there may be some types of notification generator
   applications which, rather than accessing MIB instrumentation using
   access control, will obtain MIB information through other means (such
   as from a command line).  The implementors and users of such
   applications must be responsible for not divulging MIB information
   that normally would be inaccessible due to access control.

   Finally, the MIBs described in this document contain potentially
   sensitive information.  A security administrator may wish to limit
   access to these MIBs.

11.  References

   [COEX]      The SNMPv3 Working Group, Frye, R.,Levi, D., Wijnen, B.,
               "Coexistence between Version 1, Version 2, and Version 3
               of the Internet-standard Network Management Framework",
               Work in Progress.

   [RFC1157]   Case, J., Fedor, M., Schoffstall, M. and J. Davin,
               "Simple Network Management Protocol", STD 15, RFC 1157,
               May 1990.

   [RFC1213]   McCloghrie, K. and M. Rose, Editors, "Management
               Information Base for Network Management of TCP/IP-based
               internets: MIB-II", STD 17, RFC 1213, March 1991.

   [RFC2578]   McCloghrie, K., Perkins, D. and J. Schoenwaelder,
               "Structure of Management Information Version 2 (SMIv2)",
               STD 58, RFC 2578, April 1999.

   [RFC2579]   McCloghrie, K., Perkins, D. and J.  Schoenwaelder,
               "Textual Conventions for SMIv2", STD 58, RFC 2579, April
               1999.

   [RFC1905]   SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M.
               and S.  Waldbusser, "Protocol Operations for Version 2 of
               the Simple Network Management Protocol (SNMPv2)",
               RFC1905, January 1996.

   [RFC1907]   SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M.
               and S.  Waldbusser, "Management Information Base for
               Version 2 of the Simple Network Management Protocol
               (SNMPv2)", RFC1905, January 1996.

   [RFC1908]   SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M.
               and S.  Waldbusser, "Coexistence between Version 1 and
               Version 2 of the Internet-standard Network Management
               Framework", RFC1905, January 1996.

   [RFC2119]   Bradner, S., "Key words for use in RFCs to Indicate
               Requirement Levels", BCP 14, RFC2119, March 1997.

   [RFC2571] Harrington, D., Presuhn, R. and B. Wijnen, "An Architecture
               for Describing SNMP Management Frameworks", RFC 2571,
               April 1999.

   [RFC2572]   Case, J., Harrington, D., Presuhn, R. and B. Wijnen,
               "Message Processing and Dispatching for the Simple
               Network Management Protocol (SNMP)", RFC 2572, April
               1999.

   [RFC2575]  Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based
               Access Control Model for the Simple Network Management
               Protocol (SNMP)", RFC 2575, April 1999.

   [RFC2573] Levi, D. B., Meyer, P. and B. Stewart, "SNMP Applications",
               RFC 2573, April 1999.

12.  Editors' Addresses

   David B. Levi
   SNMP Research, Inc.
   3001 Kimberlin Heights Road
   Knoxville, TN 37920-9716
   U.S.A.

   Phone: +1 423 573 1434
   EMail: levi@snmp.com


   Paul Meyer
   Secure Computing Corporation
   2675 Long Lake Road
   Roseville, MN 55113
   U.S.A.

   Phone: +1 651 628 1592
   EMail: paul_meyer@securecomputing.com


   Bob Stewart
   Cisco Systems, Inc.
   170 West Tasman Drive
   San Jose, CA 95134-1706
   U.S.A.

   Phone: +1 603 654 2686
   EMail: bstewart@cisco.com

APPENDIX A - Trap Configuration Example

   This section describes an example configuration for a Notification
   Generator application which implements the snmpNotifyBasicCompliance
   level.  The example configuration specifies that the Notification
   Generator should send notifications to 3 separate managers, using
   authentication and no privacy for the first 2 managers, and using
   both authentication and privacy for the third manager.

   The configuration consists of three rows in the snmpTargetAddrTable,
   and two rows in the snmpTargetTable.

          snmpTargetAddrName         SnmpAdminString,
          snmpTargetAddrTDomain      TDomain,
          snmpTargetAddrTAddress     TAddress,
          snmpTargetAddrTimeout      TimeInterval,
          snmpTargetAddrRetryCount   Integer32,
          snmpTargetAddrTagList      SnmpAdminString,
          snmpTargetAddrParams       SnmpAdminString,
          snmpTargetAddrStorageType  StorageType,
          snmpTargetAddrRowStatus    RowStatus

        * snmpTargetAddrName        = "addr1"
          snmpTargetAddrTDomain     = snmpUDPDomain
          snmpTargetAddrTAddress    = 128.1.2.3/162
          snmpTargetAddrTagList     = "group1"
          snmpTargetAddrParams      = "AuthNoPriv-joe"
          snmpTargetAddrStorageType = readOnly(5)
          snmpTargetAddrRowStatus   = active(1)

        * snmpTargetAddrName        = "addr2"
          snmpTargetAddrTDomain     = snmpUDPDomain
          snmpTargetAddrTAddress    = 128.2.4.6/162
          snmpTargetAddrTagList     = "group1"
          snmpTargetAddrParams      = "AuthNoPriv-joe"
          snmpTargetAddrStorageType = readOnly(5)
          snmpTargetAddrRowStatus   = active(1)

        * snmpTargetAddrName        = "addr3"
          snmpTargetAddrTDomain     = snmpUDPDomain
          snmpTargetAddrTAddress    = 128.1.2.3/162
          snmpTargetAddrTagList     = "group2"
          snmpTargetAddrParams      = "AuthPriv-bob"
          snmpTargetAddrStorageType = readOnly(5)
          snmpTargetAddrRowStatus   = active(1)

        * snmpTargetParamsName                   = "AuthNoPriv-joe"
          snmpTargetParamsMPModel                = 3m

          snmpTargetParamsSecurityModel          = 3 (USM)
          snmpTargetParamsSecurityName           = "joe"
          snmpTargetParamsSecurityLevel          = authNoPriv(2)
          snmpTargetParamsStorageType            = readOnly(5)
          snmpTargetParamsRowStatus              = active(1)

        * snmpTargetParamsName                   = "AuthPriv-bob"
          snmpTargetParamsMPModel                = 3
          snmpTargetParamsSecurityModel          = 3 (USM)
          snmpTargetParamsSecurityName           = "bob"
          snmpTargetParamsSecurityLevel          = authPriv(3)
          snmpTargetParamsStorageType            = readOnly(5)
          snmpTargetParamsRowStatus              = active(1)

        * snmpNotifyName         = "group1"
          snmpNotifyTag          = "group1"
          snmpNotifyType         = trap(1)
          snmpNotifyStorageType  = readOnly(5)
          snmpNotifyRowStatus    = active(1)

        * snmpNotifyName         = "group2"
          snmpNotifyTag          = "group2"
          snmpNotifyType         = trap(1)
          snmpNotifyStorageType  = readOnly(5)
          snmpNotifyRowStatus    = active(1)

   These entries define two groups of management targets.  The first
   group contains two management targets:

                                first target      second target
                                ------------      -------------
       messageProcessingModel   SNMPv3            SNMPv3
                securityModel   3 (USM)           3 (USM)
                 securityName   "joe"             "joe"
                securityLevel   authNoPriv(2)     authNoPriv(2)
              transportDomain   snmpUDPDomain     snmpUDPDomain
             transportAddress   128.1.2.3/162     128.2.4.6/162

   And the second group contains a single management target:

       messageProcessingModel   SNMPv3
                securityLevel   authPriv(3)
                securityModel   3 (USM)
                 securityName   "bob"
              transportDomain   snmpUDPDomain
             transportAddress   128.1.5.9/162

Appendix B.  Full Copyright Statement

   Copyright (C) The Internet Society (1999).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC Editor function is currently provided by
   the Internet Society.