doc: Add RFC documents

1 files changed, 1179 insertions, 0 deletions

diff --git a/doc/rfc/rfc2456.txt b/doc/rfc/rfc2456.txt
new file mode 100644
index 0000000..3126e32
--- /dev/null
+++ b/doc/rfc/rfc2456.txt
@@ -0,0 +1,1179 @@
+
+
+
+
+
+
+Network Working Group                                     B. Clouston
+Request for Comments: 2456                              Cisco Systems
+Category: Standards Track                                    B. Moore
+                                                      IBM Corporation
+                                                        November 1998
+
+
+                     Definitions of Managed Objects
+                             for APPN TRAPS
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (1998).  All Rights Reserved.
+
+Abstract
+
+   This memo defines a portion of the Management Information Base (MIB)
+   for use with network management protocols in the Internet community.
+   In particular, it defines objects for receiving notifications from
+   network devices with APPN (Advanced Peer-to-Peer Network) and DLUR
+   (Dependent LU Requester) capabilities.  This memo identifies
+   notifications for the APPN and DLUR architecture.
+
+Table of Contents
+
+   1.     Introduction  ...........................................  2
+   2.     The SNMP Network Management Framework  ..................  2
+   3.     Overview  ...............................................  3
+   3.1      APPN TRAP MIB structure  ..............................  5
+   4.     Definitions  ............................................  6
+   5.     Security Considerations  ................................ 17
+   6.     Intellectual Property  .................................. 17
+   7.     Acknowledgments  ........................................ 18
+   8.     References  ............................................. 18
+   9.     Authors' Addresses  ..................................... 20
+   10.    Full Copyright Statement  ............................... 21
+
+
+
+
+
+
+
+Clouston & Moore            Standards Track                     [Page 1]
+
+RFC 2456                     APPN TRAPS MIB                November 1998
+
+
+1.  Introduction
+
+   This document is a product of the SNA NAU Services MIB Working Group.
+   It defines a MIB module for notifications for devices with Advanced
+   Peer-to-Peer Networking (APPN) and Dependent LU Requester (DLUR)
+   capabilities.
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in RFC 2119 [13].
+
+2.  The SNMP Network Management Framework
+
+   The SNMP Management Framework presently consists of five major
+   components:
+
+   o    An overall architecture, described in RFC 2271 [1].
+
+   o    Mechanisms for describing and naming objects and events for the
+        purpose of management. The first version of this Structure of
+        Management Information (SMI) is called SMIv1 and described in
+        STD 16, RFC 1155 [2], STD 16, RFC 1212 [3] and RFC 1215 [4]. The
+        second version, called SMIv2, is described in RFC 1902 [5], RFC
+        1903 [6] and RFC 1904 [7].
+
+   o    Message protocols for transferring management information. The
+        first version of the SNMP message protocol is called SNMPv1 and
+        described in STD 15, RFC 1157 [8]. A second version of the SNMP
+        message protocol, which is not an Internet standards track
+        protocol, is called SNMPv2c and described in RFC 1901 [9] and
+        RFC 1906 [10]. The third version of the message protocol is
+        called SNMPv3 and described in RFC 1906 [10], RFC 2272 [11] and
+        RFC 2274 [12].
+
+   o    Protocol operations for accessing management information. The
+        first set of protocol operations and associated PDU formats is
+        described in STD 15, RFC 1157 [8]. A second set of protocol
+        operations and associated PDU formats is described in RFC 1905
+        [13].
+
+   o    A set of fundamental applications described in RFC 2273 [14] and
+        the view-based access control mechanism described in RFC 2275
+        [15].
+
+   Managed objects are accessed via a virtual information store, termed
+   the Management Information Base or MIB.  Objects in the MIB are
+   defined using the mechanisms defined in the SMI.
+
+
+
+
+Clouston & Moore            Standards Track                     [Page 2]
+
+RFC 2456                     APPN TRAPS MIB                November 1998
+
+
+   This memo specifies a MIB module that is compliant to the SMIv2. A
+   MIB conforming to the SMIv1 can be produced through the appropriate
+   translations. The resulting translated MIB must be semantically
+   equivalent, except where objects or events are omitted because no
+   translation is possible (use of Counter64). Some machine readable
+   information in SMIv2 will be converted into textual descriptions in
+   SMIv1 during the translation process. However, this loss of machine
+   readable information is not considered to change the semantics of the
+   MIB.
+
+3.  Overview
+
+   This document identifies the set of objects for reporting the status
+   of devices with APPN and DLUR capabilities via notifications.
+
+   See the SNANAU APPN MIB [18] and SNANAU DLUR MIB [19] for the objects
+   for monitoring the configuration and active characteristics of the
+   devices with APPN and DLUR capabilities. Many objects contained in
+   the notifications of this MIB are imported from the APPN and DLUR
+   MIBs.  Implementors of this MIB must also implement the APPN MIB.
+   Implementations that support the appnTrapMibDlurConfGroup and the
+   appnTrapMibDlurNotifGroup must also implement the DLUR MIB.
+
+   The SNANAU APPN MIB allows a management station to collect the
+   network topology of an APPN network (the network nodes (NNs) in the
+   network and all of transmission groups (TGs) between the network
+   nodes) from an APPN device.  It also allows the management station to
+   collect the local topology (TGs to end stations, and locally defined
+   ports and link stations) from an APPN device.  While the SNANAU APPN
+   MIB has an efficient way to poll the APPN device for updates to the
+   network topology, using flow reduction sequence numbers (FRSNs) as a
+   table index; it does not have a mechanism to poll the local topology
+   tables (appnLocalTgTable, appnPortTable, and appnLsTable) for status
+   changes.
+
+   This MIB provides a mechanism for an APPN device to send
+   notifications to inform the management station of status changes to
+   rows of these tables. Status changes include operational state
+   changes, and for TGs also include control-point to control-point
+   (CP-CP) session state changes.  A notification is defined for each
+   type of status change for each table.
+
+   The port and link operational state objects have intermediate states.
+   Notifications are only sent for transition to active or inactive
+   state.
+
+
+
+
+
+
+Clouston & Moore            Standards Track                     [Page 3]
+
+RFC 2456                     APPN TRAPS MIB                November 1998
+
+
+   Notifications are only sent for row creation if the state is active
+   or operational.  This is done to avoid sending a notification as the
+   row is created with an inactive initial state, followed by another
+   notification as the resource is activated.
+
+   Notifications are only sent for row deletion if the last state was
+   active or operational.  In most cases, a resource must be deactivated
+   before it can be deleted, and the deactivation will cause a
+   notification to be sent.  There is no need for a second notification
+   to be sent for the row deletion, except for the case where the
+   deletion occurred without deactivation.  In this case, the state of
+   the object in the notification will indicate an inactve state, since
+   a deleted resource can no longer be active.
+
+   The purpose of the appnLocalTgCpCpStateChangeTrap notification is to
+   identify the loss or recovery of CP-CP sessions on a TG while the TG
+   remains operational.  Thus this notification is only sent if there is
+   a change to an appnLocalTgCpCpSession object, but not a change to the
+   appnLocalTgOperational object.  This notification is never sent for
+   the creation or deletion of a row in the appnLocalTgTable.
+
+   Each notification always contains an object which is a count of the
+   number of times the status of a row in table has changed since the
+   APPN node was last reinitialized.  This enables a management station
+   to detect that it has missed a notification, if it does not get the
+   notifications in numerical sequence.  If the notifications are not in
+   sequence, the management station should retrieve the entire table to
+   get the correct status for all rows.
+
+   Similarly, the SNANAU DLUR MIB provides a mechanism for retrieving
+   the configuration and status of dependent LU server (DLUS) sessions
+   on a device with DLUR capabilities.  This MIB defines a notification
+   for a DLUR-DLUS session state change of a row in the dlurDlusTable,
+   in the manner described above.  A notification is only sent for a
+   session state transition to active or inactive.  As with the above
+   notifications, it is only sent on row creation if the initial state
+   is active; and on row deletion is the last state was active, in which
+   case the notification indicates that the state is now inactive.
+
+   The SNANAU APPN MIB also provides a mechanism for a management
+   station to collect traffic statistics on intermediate sessions,
+   primarily for accounting purposes.  However, when the session is
+   terminated, all statistics from the last poll until the session
+   termination time are lost, since the row for that session is deleted
+   from the appnIsInTable.  This MIB defines a notification so that the
+   session's final statistics can be sent to a management station.  If
+   the notification is not delivered, the final session statistics are
+   lost.  If this is a concern, polling of the appnIsInTable in the APPN
+
+
+
+Clouston & Moore            Standards Track                     [Page 4]
+
+RFC 2456                     APPN TRAPS MIB                November 1998
+
+
+   MIB should be increased to more likely reduce the time between the
+   last poll and the session termination, thereby reducing the amount of
+   data lost.
+
+   Highlights of the management functions supported by the APPN TRAP MIB
+   module include the following:
+
+   o    A notification for an APPN local TG operational state change.
+
+   o    A notification for an APPN local TG CP-CP session state change.
+
+   o    A notification for an APPN port operational state change.
+
+   o    A notification for an APPN link station operational state
+        change.
+
+   o    A notification for a DLUR-DLUS session state change.
+
+   o    A notification for reporting final APPN intermediate session
+        statistics.
+
+   This MIB module does not support:
+
+   o    Objects to query the configuration or status of APPN nodes on
+        demand.
+
+   o    Notifications for changes to local topology tables not related
+        to status.
+
+3.1.  APPN TRAP MIB Structure
+
+   The APPN TRAP MIB module contains a group of notifications, and a
+   group of supporting objects.
+
+   The group of notifications consists of the following notifications:
+
+   1) appnIsrAccountingDataTrap
+
+   This notification is generated by an APPN device when an intermediate
+   session is terminating, to report the final accounting statistics of
+   the session.
+
+   2) appnLocalTgOperStateChangeTrap
+
+   This notification identifies a change to the appnLocalTgOperational
+   object in a row of the SNANAU APPN MIB appnLocalTgTable.
+
+
+
+
+
+Clouston & Moore            Standards Track                     [Page 5]
+
+RFC 2456                     APPN TRAPS MIB                November 1998
+
+
+   3) appnLocalTgCpCpStateChangeTrap
+
+   This notification identifies a change to the appnLocalTgCpCpSession
+   object in a row of the SNANAU APPN MIB appnLocalTgTable.
+
+   4) appnPortOperStateChangeTrap
+
+   This notification identifies a change to the appnPortOperState object
+   in a row of the SNANAU APPN MIB appnPortTable.
+
+   5) appnLsOperStateChangeTrap
+
+   This notification identifies a change to the appnLsOperState object
+   in a row of the SNANAU APPN MIB appnLsTable.
+
+   6) dlurDlusStateChangeTrap
+
+   This notification identifies a change to the dlurDlusSessnStatus
+   object in a row of the SNANAU DLUR MIB dlurDlusTable.
+
+   The group of supporting objects contains the appnTrapControl object,
+   which controls whether the APPN device generates each type of
+   notification.  Note that generation of the appnIsrAccountingDataTrap
+   is not controlled by this object; instead it is controlled by the
+   appnIsInGlobalCtrAdminStatus object in the SNANAU APPN MIB.
+
+   Although APPN notification generation could be controlled solely by
+   entries in the snmpNotificationMIB, RFC 2273 [9], the appnTrapControl
+   object exists in this MIB so that implementations are not required to
+   implement RFC 2273 to control generation of APPN notifications.  For
+   a notification to be generated and sent as a TRAP or INFORM, the
+   notification type must first be enabled by the appnTrapControl
+   object.  It must also not be disabled by an snmpNotificationMIB
+   entry.  The destination of notifications is not within the scope of
+   this MIB.
+
+   Also contained in this group are objects for the TG, port, link, and
+   DLUR-DLUS session notifications to indicate the number of times each
+   of the tables has had a status change of a row since the APPN node
+   was last reinitialized.
+
+4.  Definitions
+
+APPN-TRAP-MIB DEFINITIONS ::= BEGIN
+
+IMPORTS
+
+        Counter32, OBJECT-TYPE, MODULE-IDENTITY,
+
+
+
+Clouston & Moore            Standards Track                     [Page 6]
+
+RFC 2456                     APPN TRAPS MIB                November 1998
+
+
+        NOTIFICATION-TYPE
+                FROM SNMPv2-SMI
+
+        MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP
+                FROM SNMPv2-CONF
+
+        appnMIB, appnIsInP2SFmdPius, appnIsInS2PFmdPius,
+        appnIsInP2SNonFmdPius, appnIsInS2PNonFmdPius,
+        appnIsInP2SFmdBytes, appnIsInS2PFmdBytes,
+        appnIsInP2SNonFmdBytes, appnIsInS2PNonFmdBytes,
+        appnIsInSessUpTime, appnObjects,
+        appnLocalTgOperational, appnLocalTgCpCpSession,
+        appnPortOperState, appnLsOperState,
+        appnCompliances, appnGroups
+                 FROM APPN-MIB
+
+        dlurDlusSessnStatus
+                 FROM APPN-DLUR-MIB;
+
+appnTrapMIB MODULE-IDENTITY
+        LAST-UPDATED  "9808310000Z" -- August 31, 1998
+        ORGANIZATION  "IETF SNA NAU MIB WG / AIW APPN MIBs SIG"
+        CONTACT-INFO
+
+                "
+                        Bob Clouston
+                        Cisco Systems
+                        7025 Kit Creek Road
+                        P.O. Box 14987
+                        Research Triangle Park, NC 27709, USA
+                        Tel:    1 919 472 2333
+                        E-mail: clouston@cisco.com
+
+                        Bob Moore
+                        IBM Corporation
+                        4205 S. Miami Boulevard
+                        BRQA/501
+                        P.O. Box 12195
+                        Research Triangle Park, NC 27709, USA
+                        Tel:    1 919 254 4436
+                        E-mail: remoore@us.ibm.com
+                "
+      DESCRIPTION
+                "This MIB module defines notifications to be generated by
+                network devices with APPN capabilities.  It presupposes
+                support for the APPN MIB.  It also presupposes
+                support for the DLUR MIB for implementations
+                that support the DLUR-related groups."
+
+
+
+Clouston & Moore            Standards Track                     [Page 7]
+
+RFC 2456                     APPN TRAPS MIB                November 1998
+
+
+::= { appnMIB 0 }
+
+-- *********************************************************************
+-- Notifications
+-- *********************************************************************
+
+appnIsrAccountingDataTrap NOTIFICATION-TYPE
+      OBJECTS  {
+                appnIsInP2SFmdPius,
+                appnIsInS2PFmdPius,
+                appnIsInP2SNonFmdPius,
+                appnIsInS2PNonFmdPius,
+                appnIsInP2SFmdBytes,
+                appnIsInS2PFmdBytes,
+                appnIsInP2SNonFmdBytes,
+                appnIsInS2PNonFmdBytes,
+                appnIsInSessUpTime
+               }
+      STATUS current
+      DESCRIPTION
+          "When it has been enabled, this notification is generated by an
+          APPN node whenever an ISR session passing through the node is
+          taken down, regardless of whether the session went down
+          normally or abnormally.  Its purpose is to allow a management
+          application (primarily an accounting application) that is
+          monitoring the ISR counts to receive the final values of these
+          counts, so that the application can properly account for the
+          amounts the counts were incremented since the last time the
+          application polled them.  The appnIsInSessUpTime object
+          provides the total amount of time that the session was active.
+
+          This notification is not a substitute for polling the ISR
+          counts.  In particular, the count values reported in this
+          notification cannot be assumed to be the complete totals for
+          the life of the session, since they may have wrapped while the
+          session was up.
+
+          The session to which the objects in this notification apply is
+          identified by the fully qualified CP name and PCID that make up
+          the table index.  An instance of this notification will contain
+          exactly one instance of each of its objects, and these objects
+          will all belong to the same conceptual row of the
+          appnIsInTable.
+
+          Generation of this notification is controlled by the same
+          object in the APPN MIB, appnIsInGlobeCtrAdminStatus, that
+          controls whether the count objects themselves are being
+          incremented."
+
+
+
+Clouston & Moore            Standards Track                     [Page 8]
+
+RFC 2456                     APPN TRAPS MIB                November 1998
+
+
+      ::= { appnTrapMIB 1 }
+
+appnLocalTgOperStateChangeTrap NOTIFICATION-TYPE
+      OBJECTS  {
+                appnLocalTgTableChanges,
+                appnLocalTgOperational
+               }
+      STATUS current
+      DESCRIPTION
+          "When it has been enabled, this notification makes it possible
+          for an APPN topology application to get asynchronous
+          notifications of local TG operational state changes,
+          and thus to reduce the frequency with which it polls
+          for these changes.
+
+          This notification is sent whenever there is a change to
+          the appnLocalTgOperational object in a row of the
+          appnLocalTgTable.  This notification is only sent for row
+          creation if the row is created with a value of 'true' for
+          appnLocalTgOperational.  This notification is only sent for
+          row deletion if the last value of appnLocalTgOperational was
+          'true'.  In this case, the value of appnLocalTgOperational
+          in the notification shall be 'false', since the deletion of
+          a row indicates that the TG is no longer operational.
+
+          The notification is more than a simple 'poll me now' indication.
+          It carries both a count of local TG topology changes, and the
+          current operational state itself.  The count of changes allows an
+          application to detect lost notifications, either when polling
+          or upon receiving a subsequent notification, at which point it
+          knows it must retrieve the entire appnLocalTgTable again.
+          This is the same count as used in the appnLocalCpCpStateChangeTrap.
+          A lost notification could indicate a local TG CP-CP session state
+          change or an operational state change.
+
+          Generation of this notification is controlled by the
+          appnTrapControl object."
+
+      ::= { appnTrapMIB 2 }
+
+appnLocalTgCpCpChangeTrap NOTIFICATION-TYPE
+      OBJECTS  {
+                appnLocalTgTableChanges,
+                appnLocalTgCpCpSession
+               }
+      STATUS current
+      DESCRIPTION
+          "When it has been enabled, this notification makes it possible
+
+
+
+Clouston & Moore            Standards Track                     [Page 9]
+
+RFC 2456                     APPN TRAPS MIB                November 1998
+
+
+          for an APPN topology application to get asynchronous
+          notifications of local TG control-point to control-point (CP-CP)
+          session state changes, and thus to reduce the
+          frequency with which it polls for these changes.
+
+          This notification is sent whenever there is a change to
+          the appnLocalTgCpCpSession object but NOT the
+          appnLocalTgOperational object in a row of the appnLocalTgTable.
+          This notification is never sent for appnLocalTgTable row
+          creation or deletion.
+
+          The notification is more than a simple 'poll me now' indication.
+          It carries both a count of local TG topology changes, and the
+          current CP-CP session state itself.  The count of changes allows
+          an application to detect lost notifications, either when polling
+          or upon receiving a subsequent notification, at which point it
+          knows it must retrieve the entire appnLocalTgTable again.  This
+          is the same count as used in the appnLocalTgOperStateChangeTrap.
+          A lost notification could indicate a local TG CP-CP session
+          state change or an operational state change.
+
+          Generation of this notification is controlled by the
+          appnTrapControl object."
+
+      ::= { appnTrapMIB 3 }
+
+appnPortOperStateChangeTrap NOTIFICATION-TYPE
+      OBJECTS  {
+                appnPortTableChanges,
+                appnPortOperState
+               }
+
+      STATUS current
+      DESCRIPTION
+          "When it has been enabled, this notification makes it possible
+          for an APPN topology application to get asynchronous
+          notifications of port operational state changes, and thus to
+          reduce the frequency with which it polls for these changes.
+          This notification is only sent when a appnPortOperState has
+          transitioned to a value of 'active' or 'inactive'.
+
+          This notification is sent whenever there is a appnPortOperState
+          object transition to 'inactive' or 'active' state in the
+          appnPortTable.  This notification is only sent for row creation
+          if the row is created with a value of 'active' for
+          appnPortOperState.  This notification is only sent for
+          row deletion if the last value of appnPortOperState was
+          'active'.  In this case, the value of appnPortOperState
+
+
+
+Clouston & Moore            Standards Track                    [Page 10]
+
+RFC 2456                     APPN TRAPS MIB                November 1998
+
+
+          in the notification shall be 'inactive', since the deletion of
+          a row indicates that the port is no longer active.
+
+          The notification is more than a simple 'poll me now' indication.
+          It carries both a count of port table changes, and the
+          operational state itself.  The count of changes allows an
+          application to detect lost notifications, either when polling
+          or upon receiving a subsequent notification, at which point
+          it knows it must retrieve the entire appnPortTable again.
+
+          Generation of this notification is controlled by the
+          appnTrapControl object."
+
+      ::= { appnTrapMIB 4 }
+
+appnLsOperStateChangeTrap NOTIFICATION-TYPE
+      OBJECTS  {
+                appnLsTableChanges,
+                appnLsOperState
+               }
+      STATUS current
+      DESCRIPTION
+          "When it has been enabled, this notification makes it possible
+          for an APPN topology application to get asynchronous
+          notifications of link station operational state changes, and
+          thus to reduce the frequency with which it polls for these
+          changes.  This notification is only sent when a appnLsOperState
+          has transitioned to a value of 'active' or 'inactive'.
+
+          This notification is sent whenever there is a appnLsOperState
+          object transition to 'inactive' or 'active' state in the
+          appnLsTable.  This notification is only sent for row creation
+          if the row is created with a value of 'active' for
+          appnLsOperState.  This notification is only sent for
+          row deletion if the last value of appnLsOperState was
+          'active'.  In this case, the value of appnLsOperState
+          in the notification shall be 'inactive', since the deletion of
+          a row indicates that the link station is no longer active.
+
+          The notification is more than a simple 'poll me now' indication.
+          It carries both a count of link station table changes, and the
+          operational state itself.  The count of changes allows an
+          application to detect lost notifications, either when polling
+          or upon receiving a subsequent notification, at which point it
+          knows it must retrieve the entire appnLsTable again.
+
+          Generation of this notification is controlled by the
+          appnTrapControl object."
+
+
+
+Clouston & Moore            Standards Track                    [Page 11]
+
+RFC 2456                     APPN TRAPS MIB                November 1998
+
+
+      ::= { appnTrapMIB 5 }
+
+dlurDlusStateChangeTrap NOTIFICATION-TYPE
+      OBJECTS  {
+                dlurDlusTableChanges,
+                dlurDlusSessnStatus
+               }
+      STATUS current
+      DESCRIPTION
+          "When it has been enabled, this notification makes it possible
+          for an APPN topology application to get asynchronous
+          notifications of DLUR-DLUS session changes, and thus to reduce
+          the frequency with which it polls for these changes.
+
+          This notification is sent whenever there is a dlurDlusSessnStatus
+          object transition to 'inactive' or 'active' state in the
+          dlurDlusTable.  This notification is only sent for row creation
+          if the row is created with a value of 'active' for
+          dlurDlusSessnStatus.  This notification is only sent for
+          row deletion if the last value of dlurDlusSessnStatus was
+          'active'.  In this case, the value of dlurDlusSessnStatus
+          in the notification shall be 'inactive', since the deletion of
+          a row indicates that the session is no longer active.
+
+          The notification is more than a simple 'poll me now' indication.
+          It carries both a count of DLUR-DLUS table changes, and the
+          session status itself.  The count of changes allows an
+          application to detect lost notifications, either when polling
+          or upon receiving a subsequent notification, at which point it
+          knows it must retrieve the entire dlurDlusTable again.
+
+          Generation of this notification is controlled by the
+          appnTrapControl object."
+
+      ::= { appnTrapMIB 6 }
+
+-- *********************************************************************
+-- Supporting Objects
+-- *********************************************************************
+
+appnTrapObjects              OBJECT IDENTIFIER ::= { appnObjects 7 }
+
+appnTrapControl OBJECT-TYPE
+
+      SYNTAX BITS {
+                   appnLocalTgOperStateChangeTrap(0),
+                   appnLocalTgCpCpChangeTrap(1),
+                   appnPortOperStateChangeTrap(2),
+
+
+
+Clouston & Moore            Standards Track                    [Page 12]
+
+RFC 2456                     APPN TRAPS MIB                November 1998
+
+
+                   appnLsOperStateChangeTrap(3),
+                   dlurDlusStateChangeTrap(4)
+                   -- add other notification types here
+                  }
+      MAX-ACCESS read-write
+      STATUS current
+      DESCRIPTION
+          "An object to turn APPN notification generation on and off.
+          Setting a notification type's bit to 1 enables generation of
+          notifications of that type, subject to further filtering
+          resulting from entries in the snmpNotificationMIB.  Setting
+          this bit to 0 disables generation of notifications of that
+          type.
+
+          Note that generation of the appnIsrAccountingDataTrap is
+          controlled by the appnIsInGlobeCtrAdminStatus object in
+          the APPN MIB:  if counts of intermediate session traffic
+          are being kept at all, then the notification is also enabled."
+
+      ::= { appnTrapObjects 1 }
+
+appnLocalTgTableChanges OBJECT-TYPE
+      SYNTAX Counter32
+      MAX-ACCESS read-only
+      STATUS current
+      DESCRIPTION
+          "A count of the number of times a row in the appnLocalTgTable
+          has changed status since the APPN node was last reinitialized.
+          This counter is incremented whenever a condition is detected
+          that would cause a appnLocalTgOperStateChangeTrap or
+          appnLocalTgCpCpChangeTrap notification to be sent, whether
+          or not those notifications are enabled."
+
+      ::= { appnTrapObjects 2 }
+
+appnPortTableChanges OBJECT-TYPE
+      SYNTAX Counter32
+      MAX-ACCESS read-only
+      STATUS current
+      DESCRIPTION
+          "A count of the number of times a row in the appnPortTable
+          has changed status since the APPN node was last reinitialized.
+          This counter is incremented whenever a condition is detected
+          that would cause a appnPortOperStateChangeTrap notification
+          to be sent, whether or not this notification is enabled."
+
+      ::= { appnTrapObjects 3 }
+
+
+
+
+Clouston & Moore            Standards Track                    [Page 13]
+
+RFC 2456                     APPN TRAPS MIB                November 1998
+
+
+appnLsTableChanges OBJECT-TYPE
+      SYNTAX Counter32
+      MAX-ACCESS read-only
+      STATUS current
+      DESCRIPTION
+          "A count of the number of times a row in the appnLsTable
+          has changed status since the APPN node was last reinitialized.
+          This counter is incremented whenever a condition is detected
+          that would cause a appnLsOperStateChangeTrap notification
+          to be sent, whether or not this notification is enabled."
+
+      ::= { appnTrapObjects 4 }
+
+dlurDlusTableChanges OBJECT-TYPE
+      SYNTAX Counter32
+      MAX-ACCESS read-only
+      STATUS current
+      DESCRIPTION
+          "A count of the number of times a row in the dlurDlusTable
+          has changed status since the APPN node was last reinitialized.
+          This counter is incremented whenever a condition is detected
+          that would cause a dlurDlusStateChangeTrap notification
+          to be sent, whether or not this notification is enabled."
+
+      ::= { appnTrapObjects 5 }
+
+-- *********************************************************************
+-- Conformance information
+-- *********************************************************************
+
+-- Tie into the conformance structure in the APPN MIB:
+-- appnConformance       OBJECT IDENTIFIER ::= {appnMIB 3 }
+--
+-- appnCompliances       OBJECT IDENTIFIER ::= {appnConformance 1 }
+-- appnGroups            OBJECT IDENTIFIER ::= {appnConformance 2 }
+
+-- Compliance statement
+appnTrapMibCompliance  MODULE-COMPLIANCE
+       STATUS  current
+       DESCRIPTION
+           "The compliance statement for the SNMP entities that
+           implement the APPN-TRAP-MIB."
+
+       MODULE  -- this module
+
+--     Conditionally mandatory groups
+           GROUP appnTrapMibIsrNotifGroup
+           DESCRIPTION
+
+
+
+Clouston & Moore            Standards Track                    [Page 14]
+
+RFC 2456                     APPN TRAPS MIB                November 1998
+
+
+               "This group is mandatory for APPN nodes supporting
+               reporting of final ISR counter values via notifications."
+
+           GROUP appnTrapMibTopoConfGroup
+           DESCRIPTION
+               "This group is mandatory for APPN nodes supporting
+               polling reduction for local topology."
+
+           GROUP appnTrapMibTopoNotifGroup
+           DESCRIPTION
+               "This group is mandatory for APPN nodes supporting
+               polling reduction for local topology."
+
+           GROUP appnTrapMibDlurConfGroup
+           DESCRIPTION
+               "This group is mandatory for APPN nodes supporting
+               polling reduction for the dlurDlusTable."
+
+           GROUP appnTrapMibDlurNotifGroup
+           DESCRIPTION
+               "This group is mandatory for APPN nodes supporting
+               polling reduction for the dlurDlusTable."
+
+           OBJECT appnTrapControl
+               MIN-ACCESS  read-only
+               DESCRIPTION
+                   "An agent is not required to support a set to
+                   this object."
+
+       ::= {appnCompliances 2 }
+
+-- Units of conformance
+appnTrapMibIsrNotifGroup    NOTIFICATION-GROUP
+        NOTIFICATIONS {
+                       appnIsrAccountingDataTrap
+                      }
+        STATUS  current
+        DESCRIPTION
+            "A notification for reporting the final values of the
+            APPN MIB's ISR counters."
+
+        ::= { appnGroups 21 }
+
+appnTrapMibTopoConfGroup  OBJECT-GROUP
+        OBJECTS  {
+                  appnTrapControl,
+                  appnLocalTgTableChanges,
+                  appnPortTableChanges,
+
+
+
+Clouston & Moore            Standards Track                    [Page 15]
+
+RFC 2456                     APPN TRAPS MIB                November 1998
+
+
+                  appnLsTableChanges
+                 }
+        STATUS  current
+        DESCRIPTION
+            "A collection of objects for reducing the polling
+            associated with the local topology tables in the
+            APPN MIB.  Nodes that implement this group SHALL
+            also implement the appnTrapMibTopoNotifGroup."
+
+        ::= { appnGroups 22 }
+
+appnTrapMibTopoNotifGroup    NOTIFICATION-GROUP
+        NOTIFICATIONS {
+                       appnLocalTgOperStateChangeTrap,
+                       appnLocalTgCpCpChangeTrap,
+                       appnPortOperStateChangeTrap,
+                       appnLsOperStateChangeTrap
+
+                      }
+        STATUS  current
+        DESCRIPTION
+            "A collection of notifications for reducing the polling
+            associated with the local topology tables in the
+            APPN MIB.  Nodes that implement this group SHALL
+            also implement the appnTrapMibTopoConfGroup."
+
+        ::= { appnGroups 23 }
+
+appnTrapMibDlurConfGroup  OBJECT-GROUP
+        OBJECTS  {
+                  appnTrapControl,
+                  dlurDlusTableChanges
+                 }
+        STATUS  current
+        DESCRIPTION
+            "A collection of objects for reducing the polling
+            associated with the dlurDlusTable in the DLUR
+            MIB.  Nodes that implement this group SHALL also
+            implement the appnTrapMibDlurNotifGroup."
+
+        ::= { appnGroups 24 }
+
+appnTrapMibDlurNotifGroup    NOTIFICATION-GROUP
+        NOTIFICATIONS {
+                       dlurDlusStateChangeTrap
+                      }
+        STATUS  current
+        DESCRIPTION
+
+
+
+Clouston & Moore            Standards Track                    [Page 16]
+
+RFC 2456                     APPN TRAPS MIB                November 1998
+
+
+            "A notification for reducing the polling associated
+            with the dlurDlusTable in the DLUR MIB.  Nodes that
+            implement this group SHALL also implement the
+            appnTrapMibDlurConfGroup."
+
+        ::= { appnGroups 25 }
+
+END
+
+5.  Security Considerations
+
+   Certain management information defined in this MIB may be considered
+   sensitive in some network environments.  Therefore, authentication of
+   received SNMP requests and controlled access to management
+   information SHOULD be employed in such environments.  An
+   authentication protocol is defined in [12].  A protocol for access
+   control is defined in [15].
+
+   None of the read-only objects in the APPN TRAP MIB reports a
+   password, user data, or anything else that is particularly sensitive.
+   Some enterprises view their network configuration itself, as well as
+   information about network usage and performance, as corporate assets;
+   such enterprises may wish to restrict SNMP access to most of the
+   objects in the MIB.
+
+   There is one read-write object in the APPN TRAP MIB, appnTrapControl.
+   This object controls the generation of the notifications defined in
+   the APPN TRAP MIB.
+
+6.  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 [16].  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 implementers or users of this specification can
+   be obtained from the IETF Secretariat.
+
+
+
+
+
+
+
+Clouston & Moore            Standards Track                    [Page 17]
+
+RFC 2456                     APPN TRAPS MIB                November 1998
+
+
+   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.
+
+7.  Acknowledgments
+
+   This MIB module is the product of the IETF SNA NAU MIB WG and the AIW
+   APPN/HPR MIBs SIG.
+
+8.  References
+
+   [1]  Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for
+        Describing SNMP Management Frameworks", RFC 2271, Cabletron
+        Systems, Inc., BMC Software, Inc., IBM T. J. Watson Research,
+        January 1998.
+
+   [2]  Rose, M., and K. McCloghrie, "Structure and Identification of
+        Management Information for TCP/IP-based Internets", STD 16, RFC
+        1155, May 1990.
+
+   [3]  Rose, M., and K. McCloghrie, "Concise MIB Definitions", STD 16,
+        RFC 1212, March 1991.
+
+   [4]  Rose, M., "A Convention for Defining Traps for use with the
+        SNMP", RFC 1215, March 1991.
+
+   [5]  Case, J., McCloghrie, K., Rose, M., and S. Waldbusser,
+        "Structure of Management Information for Version 2 of the Simple
+        Network Management Protocol (SNMPv2)", RFC 1902, January 1996.
+
+   [6]  Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Textual
+        Conventions for Version 2 of the Simple Network Management
+        Protocol (SNMPv2)", RFC 1903, January 1996.
+
+   [7]  Case, J., McCloghrie, K., Rose, M., and S. Waldbusser,
+        "Conformance Statements for Version 2 of the Simple Network
+        Management Protocol (SNMPv2)", RFC 1904, January 1996.
+
+   [8]  Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple
+        Network Management Protocol", STD 15, RFC 1157, May 1990.
+
+   [9]  Case, J., McCloghrie, K., Rose, M., and S. Waldbusser,
+        "Introduction to Community-based SNMPv2", RFC 1901, January
+        1996.
+
+
+
+
+
+Clouston & Moore            Standards Track                    [Page 18]
+
+RFC 2456                     APPN TRAPS MIB                November 1998
+
+
+   [10] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser,
+        "Transport Mappings for Version 2 of the Simple Network
+        Management Protocol (SNMPv2)", RFC 1906, January 1996.
+
+   [11] Case, J., Harrington D., Presuhn R., and B. Wijnen, "Message
+        Processing and Dispatching for the Simple Network Management
+        Protocol (SNMP)", RFC 2272, January 1998.
+
+   [12] Blumenthal, U., and B. Wijnen, "User-based Security Model (USM)
+        for version 3 of the Simple Network Management Protocol
+        (SNMPv3)", RFC 2274, January 1998.
+
+   [13] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Protocol
+        Operations for Version 2 of the Simple Network Management
+        Protocol (SNMPv2)", RFC 1905, January 1996.
+
+   [14] Levi, D., Meyer, P., and B. Stewart, "SNMPv3 Applications", RFC
+        2273, January 1998.
+
+   [15] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based Access
+         Control Model (VACM) for the Simple Network Management Protocol
+         (SNMP)", RFC 2275, January 1998
+
+   [16] Hovey, R., and S. Bradner, "The Organizations Involved in the
+        IETF Standards Process", BCP 11, RFC 2028, October 1996.
+
+   [17] Bradner, S., "Key words for use in RFCs to Indicate Requirement
+        Levels", BCP 14, RFC 2119, March 1997.
+
+   [18] Clouston, B., and B. Moore, "Definition of Managed Objects for
+        APPN", RFC 2455, November 1998.
+
+   [19] Clouston, B., and B. Moore, "Definitions of Managed Objects for
+        DLUR", RFC 2232, November 1997.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Clouston & Moore            Standards Track                    [Page 19]
+
+RFC 2456                     APPN TRAPS MIB                November 1998
+
+
+9.  Authors' Addresses
+
+   Bob Clouston
+   Cisco Systems
+   7025 Kit Creek Road
+   P.O. Box 14987
+   Research Triangle Park, NC 27709, USA
+
+   Phone: +1 919 472 2333
+   EMail: clouston@cisco.com
+
+
+   Robert Moore
+   Dept. BRQA/Bldg. 501/G114
+   IBM Corporation
+   P.O.Box 12195
+   3039 Cornwallis
+   Research Triangle Park, NC 27709, USA
+
+   Phone: +1 919 254 4436
+   EMail: remoore@us.ibm.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Clouston & Moore            Standards Track                    [Page 20]
+
+RFC 2456                     APPN TRAPS MIB                November 1998
+
+
+10.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (1998).  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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Clouston & Moore            Standards Track                    [Page 21]
+