RFC 2456
Definitions of Managed Objects for APPN TRAPS
RFC 2456: Definitions of Managed Objects for APPN TRAPS 🦋✨
okay bestie, this one is RFC 2456 💖 It's a Standards Track doc, so it's an official Internet protocol spec, not just a vibe. It was written by B. Clouston from Cisco Systems and B. Moore from IBM Corporation, and it's dated November 1998. It doesn't list any obsoletes or updates, so it isn't replacing or patching anything else 🌸
Status of this Memo 📜
okay so this doc is an Internet standards track protocol for the Internet community, and it's asking for discussion and suggestions for improvements 💅 To check the official standardization state and status of this protocol, look at the current edition of "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited, so share it with whoever 🫶
Copyright Notice ©️
Copyright (C) The Internet Society (1998). All Rights Reserved. 🔒
Abstract 🍓
this memo defines a piece of the Management Information Base (MIB) for network management protocols in the Internet community ✨ It's all about objects for getting notifications from network devices with APPN (Advanced Peer-to-Peer Network) and DLUR (Dependent LU Requester) capabilities 🧚 It basically lists the notifications for the APPN and DLUR architecture, and honestly it's iconic 👑
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 ............................... 211. Introduction 🎀
this doc is a product of the SNA NAU Services MIB Working Group 💜 It defines a MIB module for notifications from devices with Advanced Peer-to-Peer Networking (APPN) and Dependent LU Requester (DLUR) capabilities, so yes, that's the whole point of it 💅
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] 🌈 these are the official requirement words, so they're doing a lot of work here 🔥
2. The SNMP Network Management Framework 🧠
okay so the SNMP Management Framework right now has five major components 👑
- An overall architecture, described in RFC 2271 [1].
- 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].
- 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].
- 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].
- 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 through a virtual information store called the Management Information Base, or MIB 🗃️ Objects in the MIB are defined using the mechanisms defined in the SMI ✨
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 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 gets turned into textual descriptions in SMIv1 during translation. but that loss of machine readable info is not considered to change the semantics of the MIB, so we're good 🦋
3. Overview 🌸
this document identifies the set of objects for reporting the status of devices with APPN and DLUR capabilities through notifications 📣
see the SNANAU APPN MIB [18] and SNANAU DLUR MIB [19] for the objects that monitor the configuration and active characteristics of devices with APPN and DLUR capabilities 🧚 A lot of the objects in this MIB's notifications are imported from the APPN and DLUR MIBs. implementors of this MIB must also implement the APPN MIB 💖 and implementations that support the appnTrapMibDlurConfGroup and the appnTrapMibDlurNotifGroup must also implement the DLUR MIB 🫶
the SNANAU APPN MIB lets a management station collect the network topology of an APPN network (the network nodes (NNs) in the network and all of the transmission groups (TGs) between them) from an APPN device. it also lets the station collect the local topology (TGs to end stations, and locally defined ports and link stations) from an APPN device ✨ 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 🔥 but it does not have a mechanism to poll the local topology tables (appnLocalTgTable, appnPortTable, and appnLsTable) for status changes 💀
so this MIB gives an APPN device a way to send notifications that tell the management station about status changes to rows in these tables 📣 Status changes include operational state changes, and for TGs they 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 a transition to active or inactive state 🍓
Notifications are only sent for row creation if the state is active or operational 💅 This avoids sending a notification when the row is created with an inactive initial state and then another one when the resource gets activated, which is so extra 🙈
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. So there's no need for a second notification for the row deletion, except when the deletion happened without deactivation. In that case, the state of the object in the notification will show an inactive 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 stays operational 👑 So this notification is only sent if there's a change to an appnLocalTgCpCpSession object, but not a change to the appnLocalTgOperational object 💖 It's never sent for the creation or deletion of a row in the appnLocalTgTable 💀
each notification always contains an object that counts how many times the status of a row in the table has changed since the APPN node was last reinitialized 🔢 This lets a management station detect that it missed a notification if it doesn't 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 gives a way to retrieve 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 same way as above 💅 A notification is only sent for a session state transition to active or inactive. Like the others, it's only sent on row creation if the initial state is active, and on row deletion if the last state was active, in which case the notification says the state is now inactive 🦋
the SNANAU APPN MIB also gives a management station a way to collect traffic statistics on intermediate sessions, mainly for accounting purposes 💰 But when a session ends, all statistics from the last poll until the session termination time are lost, since the row for that session is deleted from the appnIsInTable 😭 So this MIB defines a notification that sends the session's final statistics to a management station 🎀 If that notification isn't delivered, the final session statistics are lost 💔 If that's a concern, you can increase the polling of the appnIsInTable in the APPN MIB, which makes it more likely to shrink the time between the last poll and the session termination, so less data gets lost 🧚
Highlights of the management functions supported by the APPN TRAP MIB module include the following 👑
- A notification for an APPN local TG operational state change.
- A notification for an APPN local TG CP-CP session state change.
- A notification for an APPN port operational state change.
- A notification for an APPN link station operational state change.
- A notification for a DLUR-DLUS session state change.
- A notification for reporting final APPN intermediate session statistics.
This MIB module does not support 🙅♀️
- Objects to query the configuration or status of APPN nodes on demand.
- Notifications for changes to local topology tables that aren't related to status.
3.1. APPN TRAP MIB Structure 🦋
okay bestie, so the APPN TRAP MIB module is basically two squads: a group of notifications (the little "hey, something changed!" pings 🔔) and a group of supporting objects that run the show 💅
the notification group has six members:
appnIsrAccountingDataTrap: an APPN device fires this when an intermediate session is terminating, so the final accounting stats for that session get reported 📊appnLocalTgOperStateChangeTrap: flags a change to theappnLocalTgOperationalobject in a row of the SNANAU APPN MIBappnLocalTgTable🔥appnLocalTgCpCpStateChangeTrap: flags a change to theappnLocalTgCpCpSessionobject in a row of the SNANAU APPN MIBappnLocalTgTable🫶appnPortOperStateChangeTrap: flags a change to theappnPortOperStateobject in a row of the SNANAU APPN MIBappnPortTable🌸appnLsOperStateChangeTrap: flags a change to theappnLsOperStateobject in a row of the SNANAU APPN MIBappnLsTable🦋dlurDlusStateChangeTrap: flags a change to thedlurDlusSessnStatusobject in a row of the SNANAU DLUR MIBdlurDlusTable💜
the supporting objects group includes appnTrapControl, which controls whether the APPN device generates each type of notification. heads up 👀: generation of appnIsrAccountingDataTrap is not controlled by this object. it's controlled by appnIsInGlobalCtrAdminStatus in the SNANAU APPN MIB instead.
here's the clever bit ✨: notification generation could be controlled purely through entries in the snmpNotificationMIB, RFC 2273 [9]. but the appnTrapControl object exists so that implementations don't have to implement RFC 2273 just to switch APPN notifications on or off 🙈. for a notification to be generated and sent as a TRAP or INFORM, its notification type must first be enabled by appnTrapControl. it also must not be disabled by an snmpNotificationMIB entry. where the notifications end up going is outside the scope of this MIB 📍.
last but not least, this group also has objects for the TG, port, link, and DLUR-DLUS session notifications. these count how many times each of the tables has had a row status change since the APPN node was last reinitialized 🔢.
4. Definitions ✨
APPN-TRAP-MIB DEFINITIONS ::= BEGIN
IMPORTS
Counter32, OBJECT-TYPE, MODULE-IDENTITY,
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."
::= { 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."
::= { 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
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
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 }Okay bestie, the notifications keep coming and they're giving main character energy ✨
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."
::= { 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),
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 }
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
"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,
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
"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 }
END5. Security Considerations 🔐
okay so this part is SERIOUS bestie 😭 but also lowkey important. Certain management info in this MIB might be considered sensitive in some network environments, so authentication of received SNMP requests and controlled access to management information SHOULD be employed in those environments 🔒. The authentication protocol is defined in [12], and the access control protocol is defined in [15]. Main character security energy 💅
None of the read-only objects in the APPN TRAP MIB reports a password, user data, or anything else that's particularly sensitive ✨. BUT some enterprises treat their network configuration itself, plus info about network usage and performance, as corporate assets 💼. Those enterprises might wanna restrict SNMP access to most of the objects in the MIB 🫶.
There's one read-write object in the APPN TRAP MIB, appnTrapControl 👀. It controls the generation of the notifications defined in the APPN TRAP MIB, so handle it with care, bestie 🧚.
6. Intellectual Property 📜
The IETF takes no position on 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 in this document, or on whether any license under those rights might or might not be available. It also doesn't say it has tried to identify any such rights 🤷♀️. Info on the IETF's procedures for 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 to get a general license or permission for implementers or users to use such proprietary rights, can be obtained from the IETF Secretariat 💌.
The IETF invites any interested party to bring to its attention any copyrights, patents, patent applications, or other proprietary rights that may cover technology required to practice this standard 🦋. Please send that info 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. Big thank-you energy to the whole crew 🌈✨.
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.
- [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.
9. Authors' Addresses 💖
Meet the brilliant humans behind it 🌸:
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.comRobert 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.com10. 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. 🫶🦋
📦 where this page comes from
- ietf: rfc2456 1998-11
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms