Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11228; 9 Dec 93 16:16 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11222; 9 Dec 93 16:16 EST Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa21391; 9 Dec 93 16:16 EST Received: from mail.bellcore.com (mail.bellcore.com [128.96.90.10]) by thumper.bellcore.com (8.6.4/8.6.4) with SMTP id QAA03804 for ; Thu, 9 Dec 1993 16:14:04 -0500 Received: from ginsu10 (ginsu10.bellcore.com) by mail.bellcore.com (5.65c/2.1) id AA29907; Thu, 9 Dec 1993 16:09:08 -0500 Received: from localhost by ginsu10 (4.1/4.7) id AA02214; Thu, 9 Dec 93 16:08:14 EST X-Station-Sent-From: ginsu10.bellcore.com Message-Id: <9312092108.AA02214@ginsu10> To: snanaumib@thumper.bellcore.com Subject: SNA NAU MIB Reply-To: dck2@mail.bellcore.com Date: Thu, 09 Dec 93 16:08:11 -0500 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Deirdre Kostick Folks -- Attached is the latest draft of the SNA NAU MIB. It is based on the first SNA NAU MIB Internet-Draft issued in 7/93 and includes comments made at the 11/93 Houston meeting, comments from the mailing list, and 11/93 conference calls. PLEASE REVIEW THE MIB CAREFULLY AND PROVIDE COMMENTS REGARDING MIB CONTENT TO THE MAILING LIST. COMMENTS OF AN EDITORIAL NATURE ONLY CAN BE SENT DIRECTLY TO ZBIGNIEW at: zbig@eicon.qc.ca THIS WILL BE THE FINAL CALL FOR COMMENTS ON THIS MIB. We are planning on forwarding the I-D to the Area Director on 12/22 to request that the draft be considered as a Proposed Standard. Please send your comments ASAP so that they can be considered for incorporation in the draft. Thanks, Deirdre Zbigniew ========================================================= draft SNANAU MIB December 22, 1993 Definitions of Managed Objects for SNA NAUs December 22, 1993 Zbigniew Kielczewski (editor) Eicon Technology Corporation zbig@eicon.qc.ca Deirdre Kostick ( editor) Bell Communications Research dck2@mail.bellcore.com Kitty Shih (editor) Novell kmshih@novell.com Status of this Memo This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is Expires June 1994 [Page 1] draft SNANAU MIB December 22, 1993 inappropriate to use Internet Drafts as reference material or to cite them other than as a "work in progress". Please check the I-D abstract listing contained in each Internet Draft directory to learn the current status of this or any other Internet Draft. Expires June 1994 [Page 2] draft SNANAU MIB December 22, 1993 _1. _I_n_t_r_o_d_u_c_t_i_o_n This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for managing the configuration, monitoring and control of Physical Units (PUs) and Logical Units (LUs) in an SNA environment. PUs and LUs are two types of Network Addressable Units (NAUs) in the logical structure of an SNA network. NAUs are the origination or destination points for SNA data streams. This draft identifies managed objects for PU Type 2.0 and Type 2.1 and LUs Type 0, 1, 2, 3. The generic objects defined here can also be used to manage LU 6.2 and any LU-LU session. This memo does not specify a standard for the Internet community. Expires June 1994 [Page 3] draft SNANAU MIB December 22, 1993 _2. _T_h_e _S_N_M_P_v_2 _N_e_t_w_o_r_k _M_a_n_a_g_e_m_e_n_t _F_r_a_m_e_w_o_r_k The SNMPv2 Network Management Framework consists of four major components. They are: o RFC 1442 which defines the SMI, the mechanisms used for describing and naming objects for the purpose of management. o RFC 1213 defines MIB-II, the core set of managed objects for the Internet suite of protocols. o RFC 1445 which defines the administrative and other architectural aspects of the framework. o RFC 1448 which defines the protocol used for network access to managed objects. The Framework permits new objects to be defined for the purpose of experimentation and evaluation. _2._1. _O_b_j_e_c_t _D_e_f_i_n_i_t_i_o_n_s Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. Objects in the MIB are defined using the subset of Abstract Syntax Notation One (ASN.1) defined in the SMI. In particular, each object object type is named by an OBJECT IDENTIFIER, an administratively assigned name. The object type together with an object instance serves to uniquely identify a specific instantiation of the object. For human convenience, we often use a textual string, termed the descriptor, to refer to the object type. Expires June 1994 [Page 4] draft SNANAU MIB December 22, 1993 _3. _O_v_e_r_v_i_e_w This draft identifies the proposed set of objects for managing the configuration, monitoring and control of Physical Units (PUs) and Logical Units (LUs) in an SNA environment. PUs and LUs are two types of Network Addressable Units (NAUs) in the logical structure of an SNA network; NAUs are the origination or destination points for SNA data streams. In this draft, the name "Node" is used to describe SNA Node Type 2.0 and Type 2.1 and the name "LU" is used to describe Logical Unit of Type 0, 1, 2, 3 and 6.2. Note however that only objects common to all LU types are covered here and LU 6.2 specific obejcts are not included in this MIB module. Highlights of the mib include: + Creation/deletion of Nodes and LUs via the RowStatus objects in the snaNodeAdminTable and in the snaLuAdminTable + Creation/deletion of table entries associating Node instances with link instances via the RowStatus object in the snaNodeLinkAdminTable - it DOES NOT support creation of links - the SNA DLC MIB provides management capabilities for links + Activation/Deactivation of Nodes via the AdminState object in the snaNodeAdminTable + Deactivation of sessions via the AdminState object in the snaSessnTable - it DOES NOT support activation or deactivation of LUs - it DOES NOT support activation of sessions + Monitoring and modification of parameters related to Nodes, LUs, and Node/link associations + Monitoring of session operational parameters + PU2.0 operational statistics + Session operational statistics Expires June 1994 [Page 5] draft SNANAU MIB December 22, 1993 + RTM statistics + Traps for: Node state change Node activation failure LU state change LU session bind failure Expires June 1994 [Page 6] draft SNANAU MIB December 22, 1993 _3._1. _A_p_p_l_y_i_n_g _M_I_B _I_I _t_o _m_a_n_a_g_i_n_g _S_N_A _N_A_U_s This section will identify how MIB II objects, specifically the MIB II system group will be used in SNMP-based management of SNA NAUs. The following object is from the MIB II system group: sysUpTime: clock in the SNMP agent/proxy-agent; expressed in TimeTicks (1/100s of a seconds). The time stamp value for events in the SNA NAU MIB will be initialized with the value of sysUpTime measured when the event takes place. _3._2. _S_N_A_N_A_U _M_I_B _S_t_r_u_c_t_u_r_e The proposed SNANAU MIB module contains several groups of objects: snaNode - objects related to PU configuration, monitoring and control. snaLu - objects related to LU definition, monitoring and control. snaMgtTools - objects related to specific management tools well known in SNA environement. These groups are described below in more detail. The objects related to PUs and LUs are organized into two types of tables: Admin table and Oper table. Admin table contains configuration parameters which will be used by the SNA system for next service initialization. This usually happens when the system is reactivated but for some obejcts it may be possible to apply the Admin parameters immediately. The objects in the Admin table can be modified by Managament Station. New entries in the Admin table can be created and existing entries can be deleted which permits Management Station to dynamically define the resources (PUs, LUs) for SNA system. Oper table is an extension (augment) of Admin table. It contains obejcts which corespond to the values of parameters currently used by the SNA system. Special object, called AdminState, which contains to desired state of PU or Session is used to control the operational state of PU and Session. LU operational state can not be controled by objects in this MIB. Expires June 1994 [Page 7] draft SNANAU MIB December 22, 1993 _3._2._1. _s_n_a_N_o_d_e _g_r_o_u_p The snaNode group consists of the following tables: 1) snaNodeAdminTable This table contains objects which describe the configuration parameters of an SNA node. Link specific configuration objects are contained in a separate MIB module corresponding to link type. Entries in this table can be created, modified and deleted by either an Agent or a management station. The snaNodeAdminRowStatus object describes the status of an entry and is used to change the status of that entry. The snaNodeAdminState object describes the desired operational state of a Node and is used to change the operational state of a Node. How the Agent or management station obtain the initial value of each object at creation time is an implementation specific issue not addressed here. For each entry in this table, there is a corresponding entry in the snaNodeOperTable. While the objects in this table describe the desired or configured operational values of the SNA node, the actual runtime values are contained in snaNodeOperTable. 2) snaNodeOperTable Each row contains runtime and operational state variables for a Node. It is an extension of snaNodeAdminTable and as such uses the same index. The rows in this table are created by an Agent as soon as the entry in the Admin Table become 'active'. The entries in this table cannot be modified by the Management Station. 3) snaPu20StatsTable Each row contains statistics variables (counters) for a PU 2.0. The entries in this table are indexed by snaNodeAdminIndex. The rows in this table are created by Agent as soon as the corresponding entry in the snaNodeAdminTable becomes 'active'. 4) snaNodeLinkAdminTable This table contains all references to link specific tables. If the Node is configured for multiple links, then it will appear many times in this table. The entries in this table can be generated initially, after startup of SNA service, by the Agent which uses information from Node configuration file. Subsequent modifications of parameters, creation of new Nodes link entries and deletion of entries is possible. The modifications of this table can be saved in the Node configuration file for the next startup of SNA service, but mechanism for this function is not defined here. Each entry contains the configuration information that associates a Node instance to one Expires June 1994 [Page 8] draft SNANAU MIB December 22, 1993 link instance. The entries are indexed by snaNodeAdminIndex and snaNodeLinkAdminIndex. 5) snaNodeLinkOperTable This table contains all references to link specific tables for operational parameters. If the Node is configured for multiple links, then it will appear many times in this table. This table augments the snaNodeLinkAdminTable. 6) snaNodeTraps Two traps are defiend for Nodes. First indicates that operational state of a PU has changed. Second indicates the failure of ACTPU received from host. _3._2._2. _s_n_a_L_u _g_r_o_u_p The snaLu group consists of the following tables: 1) snaLuAdminTable Table of LUs configuration information. The rows in this table can be created and deleted by Management Station. Only objects which are common to all types of LUs are included in this table. Objects specific to a particular LU type may be included in an extension to this table. The entries are indexed by Node and LU indexes. 2) snaLuOperTable Table containing dynamic runtime information and control variables relating to LUs. Only objects which are common to all types of LUs are included in this table. Objects specific to a particular LU type may be included in an extension to this table. This table augments the snaLuAdminTable. 3) snaLuSessnTable This is a table containing objects which describe the operational state of LU sessions. Only objects which are common to all types of LU sessions are included in this table. Objects specific to a particular session type may be included in an extension to this table. When session enters the state 'pending-bind (2)', the corresponding entry in the session table is created by the Agent. When the session state becomes 'unbound (1)' then the session will be removed from the session table by the Agent. Entries are indexed by Node, Link, LU and session indexes. 4) snaLuSessnStatsTable Table containing dynamic statistics information relating to LU-LU sessions. The entries in this table augment the entries in the snaLuSessnTable and cannot be created by Management Station. 5) snaLuTraps Two traps are defiend for LUs. First indicates that the Expires June 1994 [Page 9] draft SNANAU MIB December 22, 1993 operational state of the LU has changed. Second indicates the failure of BIND. _3._2._3. _s_n_a_M_g_t_T_o_o_l_s _g_r_o_u_p This is an optional group. The snaMgtTools group consists of the following table: 1) snaLuRtmTable Each row contains NetView RTM variables of an LU. The table is indexed by Node and LU indexes. Entries correspond to LU 2 entries in the snaLuAdminTable. Management Station can activate or deactivate collection of RTM statistics for a given LU. More groups may be defined in the future to provide the compatibility with existing popular proprietary tools. _3._2._4. _C_o_n_f_o_r_m_a_n_c_e _s_t_a_t_e_m_e_n_t Compliance of the SNMPv2 management entity to the snanau MIB is defined in terms of following conformance units called groups. Unconditionally mandatory groups : snaNodeGroup, snaLuGroup, snaSessionGroup. Conditionally mandatory groups : snaPu20Group - mandatory only for those entities which implement PU type 2.0. The snaMgtToolsRtmGroup - mandatory only for those entities which implement LU type 2 and RTM. Refinement of requirements for objects access: Agent which does not implement row creation for snaNodeAdminTable snaNodeLinkAdminTable and snaLuAdminTable must at least accept objects modification (read-write access instead of read-create). _3._3. _S_N_A_N_A_U _M_I_B _s_p_e_c_i_a_l _f_e_a_t_u_r_e This chapter describes the mechanism used for row creation in the Admin tables and also presents critical state transitions for PUs, LUs and Sessions. Expires June 1994 [Page 10] draft SNANAU MIB December 22, 1993 _3._3._1. _R_o_w _C_r_e_a_t_i_o_n _m_e_c_h_a_n_i_s_m Row creation mechanism for Admin tables is based on the use of the RowStatus object. It follows the rules for the use in SNMPv1 context proposed in the Internet Draft "Row creation with SNMPv1" . Restriction of some operations for specific tables are described in each table. In particular, before accepting 'destroy' value for an entry, Agent has to verify operational state of the corresponding entry in the Oper table. _3._3._2. _S_t_a_t_e _D_i_a_g_r_a_m_s Following states diagram models the Node state transitions. When the row is created by Management Station, Agent creates the Oper table entry for that Node with the OperState equal to 'inactive'. Agent can not accept any operations for that Node until the RowStatus is set to 'active'. Oper -> inactive active waiting stopping AdminState: active active active waiting no inactive inactive stopping inactive stopping or inactive Following states diagram models the Session state transitions. When the session goes to 'unbound' state, the corresponding entry will be removed from the session table by the Agent. Oper -> unbound pending-bind bound AdminState: bound no no no unbound unbound unbound unbound Expires June 1994 [Page 11] draft SNANAU MIB December 22, 1993 _4. _O_b_j_e_c_t _D_e_f_i_n_i_t_i_o_n_s SNA-NAU-MIB DEFINITIONS ::= BEGIN -- This is the 12/06/93 draft text of the SNANAU MIB. -- It is based on the first I-D. -- It incorporates recommendations made during the AIW meeting -- in Raleigh in September 93 and the SNA MIB Working Group -- meeting in Houston on 11/3/93. -- Many modifications have been incorporated after a series of -- conference calls made in November 93. -- This second Internet Draft contains objects necessary -- for management of SNA devices: PU 2.0, 2.1 and LU 0, 1, 2, 3 -- as well as generic objects which can be used to manage -- LU 6.2. -- Naming conventions in this document: -- Following names are used according to SNA conventions. -- The name 'PU' is used to describe Node Type 2.0, 1.0 or 2.1 -- The name 'LU' is used to describe Logical Units of Type 0,1,2,3 -- or 6.2. IMPORTS DisplayString, RowStatus, InstancePointer FROM SNMPv2-TC experimental, Counter32, Gauge32, Integer32, TimeTicks, OBJECT-TYPE, MODULE-IDENTITY, NOTIFICATION-TYPE FROM SNMPv2-SMI MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF; snanauMIB MODULE-IDENTITY LAST-UPDATED "9312081800Z" ORGANIZATION "IETF SNA NAU MIB Working Group" CONTACT-INFO " Zbigniew Kielczewski Eicon Technology Inc. 2196 32nd Avenue Expires June 1994 [Page 12] draft SNANAU MIB December 22, 1993 Lachine, Que H8T 3H7 Canada Tel: 1 514 631 2592 E-mail: zbig@eicon.qc.ca Deirdre Kostick Bell Communications Research Red Bank, NJ 07701 Tel: 1 908 758 2642 E-mail: dck2@mail.bellcore.com Kitty Shih (editor) Novell 890 Ross Drive Sunnyvale, CA 94089 Tel: 1 408 747 4305 E-mail: kmshih@novell.com" DESCRIPTION "This is the MIB module for objects used to manage SNA devices." ::= { experimental 50 } -- The SNANAU MIB module contains objects part and conformance part. -- Obejcts are organized in the following groups: -- (1)snaNode group, -- (2)snaLU group, -- (3)snaMgtTools group. snanauObjects OBJECT IDENTIFIER ::= { snanauMIB 1 } snaNode OBJECT IDENTIFIER ::= { snanauObjects 1 } snaLu OBJECT IDENTIFIER ::= { snanauObjects 2 } snaMgtTools OBJECT IDENTIFIER ::= { snanauObjects 3} -- *************************************************************** -- snaNode group -- -- It contains Managed Objects related to any type of PU and -- some specific objects for PU Type 2.0. -- *************************************************************** -- *************************************************************** -- The following table contains generic Node configuration Expires June 1994 [Page 13] draft SNANAU MIB December 22, 1993 -- parameters. -- *************************************************************** snaNodeAdminTable OBJECT-TYPE SYNTAX SEQUENCE OF SnaNodeAdminEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains objects which describe the configuration parameters of an SNA node. Link specific configuration objects are contained in a separate MIB module corresponding to the link type. The table snaNodeAdminLinkTable contains objects which provide relation between nodes instances and links instances. Entries (i.e. rows) in this table can be created by either an agent or a management station. Agent can create entries initially based on the nodes configuration file. Management station can create entries through setting the appropriate value in the snaNodeAdminRowStatus. The snaNodeAdminRowStatus object describes the status of an entry and is used to change the status of an entry. The entry is deleted by agent based on the value of the snaNodeAdminRowStatus. The snaNodeAdminState object describes the desired operational state of a Node and is used to change the operational state of a Node. How the Agent or management station obtains the initial value of each object at creation time is an implementation specific issue not addressed here. For each entry in this table, there is a corresponding entry in the snaNodeOperTable. While the objects in this table describe the desired or configured operational values of the SNA node, the actual runtime values are contained in snaNodeOperTable." Expires June 1994 [Page 14] draft SNANAU MIB December 22, 1993 ::= { snaNode 1 } snaNodeAdminEntry OBJECT-TYPE SYNTAX SnaNodeAdminEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry contains the configuration parameters for one SNA node instance. The objects in the entry have read-create access. An entry can be created, modified or deleted. The object snaNodeAdminRowStatus is used (i.e., set) to create or delete a row entry." INDEX { snaNodeAdminIndex } ::= { snaNodeAdminTable 1 } SnaNodeAdminEntry ::= SEQUENCE { snaNodeAdminIndex Integer32, snaNodeAdminName DisplayString, snaNodeAdminType INTEGER, snaNodeAdminXidFormat INTEGER, snaNodeAdminBlockNum DisplayString, snaNodeAdminIdNum DisplayString, snaNodeAdminEnablingMethod INTEGER, snaNodeAdminLuTermDefault INTEGER, snaNodeAdminMaxLu Integer32, snaNodeAdminHostDescription DisplayString, snaNodeAdminStopMethod INTEGER, snaNodeAdminState INTEGER, snaNodeAdminRowStatus RowStatus } Expires June 1994 [Page 15] draft SNANAU MIB December 22, 1993 snaNodeAdminIndex OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS not-accessible STATUS current DESCRIPTION "Index used to uniquely identify each node instance. If an Agent creates the entry, then it will assign this number otherwise a Management Station generates a random number when it reserves the entry for creation." ::= { snaNodeAdminEntry 1 } snaNodeAdminName OBJECT-TYPE SYNTAX DisplayString (SIZE(0..17)) MAX-ACCESS read-create STATUS current DESCRIPTION "The name of the node which will be used during node activation. In Type 2.1 networks, this is a fully-qualified name, meaning the node name is preceded by the NetId (if present) and a period as the delimiter. A write operation to this object will not change the operational value reflected in snaNodeOperName until the node has be re-activated (e.g., after next startup of the SNA services)." ::= { snaNodeAdminEntry 2 } snaNodeAdminType OBJECT-TYPE SYNTAX INTEGER { other(1), pu10(2), pu20(3), t21len(4), endNode(5), networkNode(6) } MAX-ACCESS read-create STATUS current DESCRIPTION "The object identifies the type of SNA node. Expires June 1994 [Page 16] draft SNANAU MIB December 22, 1993 A write operation to this object will not change the operational value reflected in snaNodeOperType until the node has be re-activated (e.g., after next startup of the SNA services)." ::= { snaNodeAdminEntry 3 } snaNodeAdminXidFormat OBJECT-TYPE SYNTAX INTEGER { format0(1), format1(2), format3(3) } MAX-ACCESS read-create STATUS current DESCRIPTION "This object identifies the type of XID format used for this node. Note that there is no format type 2. A write operation to this object will not change the operational value reflected in snaNodeOperAdminXidFormat until the node has be re-activated (e.g., after next startup of the SNA services)." ::= { snaNodeAdminEntry 4 } snaNodeAdminBlockNum OBJECT-TYPE SYNTAX DisplayString (SIZE(3)) MAX-ACCESS read-create STATUS current DESCRIPTION "Identifies the block number for this node instance. It is the first 3 hexadecimal digits of the node id. A write operation to this object will not change the operational value reflected in snaNodeOperBlockNum until the node has be re-activated (e.g., after next startup of the SNA services)." ::= { snaNodeAdminEntry 5 } snaNodeAdminIdNum OBJECT-TYPE SYNTAX DisplayString (SIZE(5)) MAX-ACCESS read-create Expires June 1994 [Page 17] draft SNANAU MIB December 22, 1993 STATUS current DESCRIPTION "Identifies the ID number for this node instance. This is the last 5 hexadecimal digits of the node id. A write operation to this object will not change the operational value reflected in snaNodeOperIdNum until the node has be re-activated (e.g., after next startup of the SNA services)." ::= { snaNodeAdminEntry 6 } snaNodeAdminEnablingMethod OBJECT-TYPE SYNTAX INTEGER { other (1), startup (2), demand (3), onlyMS (4) } MAX-ACCESS read-create STATUS current DESCRIPTION "Indicates how the node should be activated for the first time. The values have the following meaning: startup (2) - at SNA services' initialization time (this is the default), demand (3) - only when LU is requested by application, onlyMS (4) - by a management station only. A write operation to this object may immediately change the operational value reflected in snaNodeOperEnablingMethod depending on the agent implementation. If the agent implementation accepts immediate change then the behavior of the Node changes immediately and not only after next system startup of the SNA services. This immediate change may only apply when changing the current value 'demand (3)' is changed to 'onlyMS (4)' and vice versa. If the agent implementation accepts immediate change, then the behavior of the Node changes immediately instead of at the next startup of the SNA services. " ::= { snaNodeAdminEntry 7 } snaNodeAdminLuTermDefault OBJECT-TYPE Expires June 1994 [Page 18] draft SNANAU MIB December 22, 1993 SYNTA INTEGER { other (1), unbind (2), termself (3), rshutd (4), poweroff(5) } MAX-ACCESS read-create STATUS current DESCRIPTION "Indicates how LUs for this Node should be deactivated. The values define which method has to be used. For LU6.2s, 'unbind(2)' is the only valid value. unbind(2) - terminate the LU-LU session by sending an SNA UNBIND request. termself(3) - terminate the LU-LU session by sending an SNA TERM-SELF (Terminate Self) request on the SSCP-LU session. The SSCP will inform the remote session LU partner to send an UNBIND request to terminate the session. rshutd(4) - terminate the LU-LU session by sending an SNA RSHUTD (Request ShutDown) request to the remote session LU partner. The remote LU will then send an UNBIND request to terminate the session. poweroff(5) - terminate the LU-LU session by sending either an SNA LUSTAT (LU Status) request on the LU-LU session or an SNA NOTIFY request on the SSCP-LU session indicating that the LU has been powered off. Sending both is also acceptable. The result should be that the remote session LU partner will send an UNBIND to terminate the session. This object applies to all LUs in this Node. It describes the default behaviour of how LU sessions will be terminated for this Node. However, it is possible to override this default by setting the appropriate value in the snaLuAdminTerm object in the snaLuAdminTable for a specific LU. A write operation to this object may immediately change the operational value reflected Expires June 1994 [Page 19] draft SNANAU MIB December 22, 1993 in snaNodeOperLuTermDefault depending on the agent implementation." ::= { snaNodeAdminEntry 8 } snaNodeAdminMaxLu OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-create STATUS current DESCRIPTION "Indicates the maximum number of LUs that may be activated for this Node. For PU2.1, this object refers to the number of dependent LUs. A write operation to this object will not change the operational value reflected in snaNodeOperMaxLu until the Node has be re-activated (e.g., after next startup of the SNA services). ::= { snaNodeAdminEntry 9 } snaNodeAdminHostDescription OBJECT-TYPE SYNTAX DisplayString (SIZE(0..128)) MAX-ACCESS read-create STATUS current DESCRIPTION "Identifies the remote host associated with this Node (e.g., PU). Since SSCP Id's may not be unique across hosts, the host description is required to uniquely identify the SSCP. This object is only applicable to PU2.0 type nodes. If the remote host is unknown, then the value is the null string. A write operation to this object may immediately change the operational value reflected in snaNodeOperHostDescription depending on the agent implementation." ::= { snaNodeAdminEntry 10 } snaNodeAdminStopMethod OBJECT-TYPE SYNTAX INTEGER { other (1), normal (2), immed (3), Expires June 1994 [Page 20] draft SNANAU MIB December 22, 1993 force (4) } MAX-ACCESS read-create STATUS current DESCRIPTION "This object indicates the desired method to be used by the agent to stop a Node (i.e., change the Node's operational state to inactive(1) ). The values have the following meaning: normal(2) - deactivate only when there is no more activity on this Node (i.e., all data flows have been been completed and all sessions have been terminated). immed(3) - deactivate immediately regardless of current activities on this Node. Wait for deactivation responses (from remote Node) before changing the Node state to inactive. force(4) - deactivate immediately regardless of current activities on this Node. Do not wait for deactivation responses (from remote Node) before changing the Node state to inactive. A write operation to this object may immediately change the operational value reflected in snaNodeOperStopMethod depending on the agent implementation." ::= { snaNodeAdminEntry 11 } snaNodeAdminState OBJECT-TYPE SYNTAX INTEGER { inactive (1), active (2) } MAX-ACCESS read-create STATUS current DESCRIPTION "Indicates the desired operational state of the SNA Node. This object is used by the management station to activate or deactivate the Node. If the current value in snaNodeOperState is 'active (2)', setting this object to Expires June 1994 [Page 21] draft SNANAU MIB December 22, 1993 'inactive (1)' will initiate the Node shutdown process using the method indicated by snaNodeOperStopMethod. If the current value in snaNodeOperState is 'inactive (1)', setting this object to 'active (2)' will initiate the Node's activation. A management station can always set this object to 'active (2)' irrespective of the value in the snaOperEnablingMethod." ::= { snaNodeAdminEntry 12 } snaNodeAdminRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "This object is used by a Management Station to create or delete the row entry in the snaNodeAdminTable following the Row Status textual convention. Upon successful creation of the row, the agent automatically creates a corresponding entry in the snaNodeOperTable with snaNodeOperState equal to 'inactive (1)'. Row deletion can be NMS or agent initiated: (a) The NMS can set the value to 'destroy (6)' only when the value of snaNodeOperState of this Node instance is 'inactive (1)'. The agent will then delete the rows correponding to this Node instance from snaNodeAdminTable and from snaNodeOperTable. (b) The agent detects that a row is in the 'notReady (3)' state for greater than a default period of 5 minutes. (c) All rows with the snaNodeAdminRowStatus object's value of 'notReady (3)' will be removed upon the next startup of the SNA services." ::= { snaNodeAdminEntry 13 } Expires June 1994 [Page 22] draft SNANAU MIB December 22, 1993 -- *************************************************************** -- The following object is updated when there is a change to -- the value of any object in the snaNodeAdminTable. -- *************************************************************** snaNodeAdminTableLastChange OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS current DESCRIPTION "The time stamp of the last change made to any object in this table, including row deletions/additions. This object can be used to reduce frequent retrievals of the snaNodeAdminTable by a management station. It is expected that a management station will periodically poll this object and compare its current value with the previous one. A difference indicates that some Node configuration information has been changed. Only then will the management station retrieve the entire table." ::= { snaNode 2 } -- *************************************************************** -- The following table contains Node operational parameters. -- *************************************************************** snaNodeOperTable OBJECT-TYPE SYNTAX SEQUENCE OF SnaNodeOperEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains the dynamic parameters which have read-only access. These objects reflect the actual status of the Node. The entries in this table cannot be created or modified by a Management Station. This table augments the snaNodeAdminTable." ::= { snaNode 3 } snaNodeOperEntry OBJECT-TYPE SYNTAX SnaNodeOperEntry MAX-ACCESS not-accessible Expires June 1994 [Page 23] draft SNANAU MIB December 22, 1993 STATUS current DESCRIPTION "The entry contains parameters which describe the state of one Node. The entries are created by the Agent. They have read-only access." AUGMENTS { snaNodeAdminEntry } ::= { snaNodeOperTable 1 } SnaNodeOperEntry ::= SEQUENCE { snaNodeOperName DisplayString, snaNodeOperType INTEGER, snaNodeOperXidFormat INTEGER, snaNodeOperBlockNum DisplayString, snaNodeOperIdNum DisplayString, snaNodeOperEnablingMethod INTEGER, snaNodeOperLuTermDefault INTEGER, snaNodeOperMaxLu Integer32, snaNodeOperHostDescription DisplayString, snaNodeOperStopMethod INTEGER, snaNodeOperState INTEGER, snaNodeOperHostSscpId OCTET STRING, snaNodeOperStartTime TimeTicks, snaNodeOperLastStateChange TimeTicks, snaNodeOperActFailures Integer32, snaNodeOperActFailureReason INTEGER } snaNodeOperName OBJECT-TYPE SYNTAX DisplayString (SIZE(0..17)) Expires June 1994 [Page 24] draft SNANAU MIB December 22, 1993 MAX-ACCESS read-only STATUS current DESCRIPTION "The name of the Node. In Type 2.1 networks, this is a fully-qualified name, meaning the Node name is preceded by the NetId (if present) and a period as the delimiter." ::= { snaNodeOperEntry 1 } snaNodeOperType OBJECT-TYPE SYNTAX INTEGER { other(1), pu10(2), pu20(3), t21LEN(4), endNode(5), networkNode(6) } MAX-ACCESS read-only STATUS current DESCRIPTION "The current type of the Node." ::= { snaNodeOperEntry 2 } snaNodeOperXidFormat OBJECT-TYPE SYNTAX INTEGER { format0 (1), format1 (2), format3 (3) } MAX-ACCESS read-only STATUS current DESCRIPTION "This object identifies the type of XID format currently used for this Node. Note that there is no format type 2." ::= { snaNodeOperEntry 3 } snaNodeOperBlockNum OBJECT-TYPE SYNTAX DisplayString (SIZE(3)) MAX-ACCESS read-only STATUS current DESCRIPTION "Identifies the block number for this Node instance. It is the first 3 hexadecimal digits Expires June 1994 [Page 25] draft SNANAU MIB December 22, 1993 of the Node id." ::= { snaNodeOperEntry 4 } snaNodeOperIdNum OBJECT-TYPE SYNTAX DisplayString (SIZE(5)) MAX-ACCESS read-only STATUS current DESCRIPTION "Identifies the ID number for this Node instance. This is the last 5 hexadecimal digits of the Node id." ::= { snaNodeOperEntry 5 } snaNodeOperEnablingMethod OBJECT-TYPE SYNTAX INTEGER { other (1), startup (2), demand (3), onlyMS (4) } MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates how the Node is activated for the first time. The values have the following meanings: other (1) - not at boot time, LU activation or by NMS; startup (2) - at SNA services' initialization time (this is the default), demand (3) - only when LU is requested by application, onlyMS (4) - by a network management station only." ::= { snaNodeOperEntry 6 } snaNodeOperLuTermDefault OBJECT-TYPE SYNTAX INTEGER { other (1), unbind (2), termself (3), rshutd (4), poweroff (5) } MAX-ACCESS read-only Expires June 1994 [Page 26] draft SNANAU MIB December 22, 1993 STATUS current DESCRIPTION "Indicates the current default method for deactivation of LUs on this Node. This method will be used all LUs when the Node has to deactivated" ::= { snaNodeOperEntry 7 } snaNodeOperMaxLu OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates the current, maximum number of LUs that are activated for this Node. For PU2.1, this object refers to the number of dependent LUs." ::= { snaNodeOperEntry 8 } snaNodeOperHostDescription OBJECT-TYPE SYNTAX DisplayString (SIZE(0..128)) MAX-ACCESS read-only STATUS current DESCRIPTION "Identifies the remote host currently associated with this Node (e.g., PU). Since SSCP Id's may not be unique across hosts, the host description is required to uniquely identify the SSCP." ::= { snaNodeOperEntry 9 } snaNodeOperStopMethod OBJECT-TYPE SYNTAX INTEGER { other (1), normal (2), immed (3), force (4) } MAX-ACCESS read-only STATUS current DESCRIPTION "This object indicates the current Node shutdown method to be used by the agent to stop the Node. When the agent changes the Node's state to 'inactive (1)', the agent must use the shutdown method indicated Expires June 1994 [Page 27] draft SNANAU MIB December 22, 1993 by this object. The values have the following meaning: normal(2) - deactivate only when there is no more activity on this Node (i.e., all data flows have been completed and all sessions have been terminated). immed(3) - deactivate immediately regardless of current activities on this Node. Wait for deactivation responses (from remote Node) before changing the Node state to inactive. force(4) - deactivate immediately regardless of current activities on this Node. Do not wait for deactivation responses (from remote Node) before changing the Node state to inactive. Note that a write operation to snaNodeAdminOperStopMethod may immediately change the value of snaNodeOperStopMethod depending on the agent implementation." ::= { snaNodeOperEntry 10 } snaNodeOperState OBJECT-TYPE SYNTAX INTEGER { inactive (1), active (2), waiting (3), stopping (4) } MAX-ACCESS read-only STATUS current DESCRIPTION "The current state of the Node. The values have the following meanings: inactive (1), a row representing the Node has been created in the AdminTable and, the Node is ready for activation -or- an active Node has been stopped -or- a waiting Node has returned to the inactive state waiting (3), a request to have the Node activated has been issued, and the Node is pending activation active (2), the Node is ready and operating Expires June 1994 [Page 28] draft SNANAU MIB December 22, 1993 stopping (4), the request to stop the Node has been issued while the StopMethod normal or immediate is used." ::= { snaNodeOperEntry 11 } snaNodeOperHostSscpId OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..6)) MAX-ACCESS read-only STATUS current DESCRIPTION "The current SSCP Id associated with the Node. This object is applicable only to PU2.0 type nodes." ::= { snaNodeOperEntry 12 } snaNodeOperStartTime OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS current DESCRIPTION "The time stamp of the Node activation." ::= { snaNodeOperEntry 13 } snaNodeOperLastStateChange OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS current DESCRIPTION "The time stamp of the last state change of the Node." ::= { snaNodeOperEntry 14 } snaNodeOperActFailures OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of failed Node activation attempts since system start-up." ::= { snaNodeOperEntry 15 } snaNodeOperActFailureReason OBJECT-TYPE SYNTAX INTEGER { other (1), linkFailure (2), Expires June 1994 [Page 29] draft SNANAU MIB December 22, 1993 noResources (3), badConfiguration (4), internalError (5) } MAX-ACCESS read-only STATUS current DESCRIPTION "The object identifies the reason for the activation failure. It will be sent in the trap snaNodeActFailTrap." ::= { snaNodeOperEntry 16 } -- *************************************************************** -- The following object is updated when there is a change to -- the value of snaNodeOperState in any row or a row is -- added/deleted from the snaNodeOperTable through snaNodeAdminTable. -- *************************************************************** snaNodeOperTableLastChange OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS current DESCRIPTION "The time stamp of the last change made to any snaNodeOperState object instance in this table or last time a row was deleted/added from the table. The expected use of this object is for a Management Station to retrieve this object, then compare it to a previous value. If there is a difference, this indicates that some change has occurred in some PU status, the Management Station will retrieve the entire table ." ::= { snaNode 4 } -- *************************************************************** -- The following table contains PU 2.0 statistics dynamic parameters. -- This is an optional table. -- *************************************************************** snaPu20StatsTable OBJECT-TYPE Expires June 1994 [Page 30] draft SNANAU MIB December 22, 1993 SYNTAX SEQUENCE OF SnaPu20StatsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains the dynamic parameters which have read-only access. The entries in this table correspond to PU 2.0 entries in the snaNodeOperTable and cannot be created by a Management Station." ::= { snaNode 5 } snaPu20StatsEntry OBJECT-TYPE SYNTAX SnaPu20StatsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The entry contains parameters which describe the statistics for one PU 2.0. They have read-only access. Each Node of PU Type 2.0 from the snaNodeAdminTable has one entry in this table and the index used here has the same value as snaNodeAdminIndex of that PU. The entry is created by the Agent." INDEX { snaNodeAdminIndex } ::= { snaPu20StatsTable 1 } SnaPu20StatsEntry ::= SEQUENCE { snaPu20StatsBytesSent Counter32, snaPu20StatsBytesReceived Counter32, snaPu20StatsRuSent Counter32, snaPu20StatsRuReceived Counter32, snaPu20StatsNegativeRespSent Counter32, snaPu20StatsNegativeRespReceived Counter32, snaPu20StatsActLu Gauge32, snaPu20StatsInActLu Gauge32, snaPu20StatsBindLu Gauge32 } Expires June 1994 [Page 31] draft SNANAU MIB December 22, 1993 snaPu20StatsBytesSent OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of bytes sent by this Node." ::= { snaPu20StatsEntry 1 } snaPu20StatsBytesReceived OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of bytes received by this Node." ::= { snaPu20StatsEntry 2 } snaPu20StatsRuSent OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of RUs sent by this Node." ::= { snaPu20StatsEntry 3 } snaPu20StatsRuReceived OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of RUs received by this Node." ::= { snaPu20StatsEntry 4 } snaPu20StatsNegativeRespSent OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of negative responses sent by this Node." ::= { snaPu20StatsEntry 5 } snaPu20StatsNegativeRespReceived OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current Expires June 1994 [Page 32] draft SNANAU MIB December 22, 1993 DESCRIPTION "The number of negative responses received by this Node." ::= { snaPu20StatsEntry 6 } snaPu20StatsActLu OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of LUs on this PU which have received and responded to ACTLU from the host." ::= { snaPu20StatsEntry 7 } snaPu20StatsInActLu OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of LUs on this PU which have not received an ACTLU from the host. This is possible if the number of configured LUs exceeds that on the host." ::= { snaPu20StatsEntry 8 } snaPu20StatsBindLu OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of LUs on this PU which have received and acknowledged a BIND request from the host." ::= { snaPu20StatsEntry 9 } -- *************************************************************** -- The following table contains the association between Nodes and -- link identifiers. -- It is used for the configuration purposes. -- *************************************************************** snaNodeLinkAdminTable OBJECT-TYPE SYNTAX SEQUENCE OF SnaNodeLinkAdminEntry MAX-ACCESS not-accessible Expires June 1994 [Page 33] draft SNANAU MIB December 22, 1993 STATUS current DESCRIPTION "This table contains all references to link specific tables. If the Node is configured for multiple links, then it will appear many times in this table. The entries in this table can be generated initially, after startup of SNA service, by the Agent which uses information from Node configuration file. Subsequent modifications of parameters, creation of new Nodes link entries and deletion of entries is possible. The modifications of this table can be saved in the Node configuration file for the next startup of SNA service, but mechanism for this function is not defined here." ::= { snaNode 6 } snaNodeLinkAdminEntry OBJECT-TYPE SYNTAX SnaNodeLinkAdminEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Entry contains the configuration information that associates a Node instance to one link instance. The objects in the entry have read-create access. Entry can be created, modified or deleted. The object snaNodeLinkAdminRowStatus is used (set) to create or delete an entry. The object snaNodeLinkAdminSpecific can be set later, after the entry has been created." INDEX { snaNodeAdminIndex, snaNodeLinkAdminIndex } ::= { snaNodeLinkAdminTable 1 } SnaNodeLinkAdminEntry ::= SEQUENCE { snaNodeLinkAdminIndex Integer32, snaNodeLinkAdminSpecific InstancePointer, snaNodeLinkAdminMaxPiu Integer32, snaNodeLinkAdminRowStatus RowStatus Expires June 1994 [Page 34] draft SNANAU MIB December 22, 1993 } snaNodeLinkAdminIndex OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS not-accessible STATUS current DESCRIPTION "Used to index the instances of objects. If an Agent creates the entry, then it will assign this number otherwise a Management Station generates a random number when it reserves the entry for creation." ::= { snaNodeLinkAdminEntry 1 } snaNodeLinkAdminSpecific OBJECT-TYPE SYNTAX InstancePointer MAX-ACCESS read-create STATUS current DESCRIPTION "The row in a table specific for the link. It is the object identifier representing the instance of the first columnar object in one of the link tables. E.g., sdlc link information are provided in the DLC MIB and this object will correspond to the sdlcLSAdminAddress instance." ::= { snaNodeLinkAdminEntry 2 } snaNodeLinkAdminMaxPiu OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-create STATUS current DESCRIPTION "Maximum number of octets that can be exchanged by this PU in one Path Information Unit (PIU)." ::= { snaNodeLinkAdminEntry 3 } snaNodeLinkAdminRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "This object is used by a Management Station to create or delete the row entry in the Expires June 1994 [Page 35] draft SNANAU MIB December 22, 1993 snaNodeLinkAdminTable. To activate a row, the NMS sets the value to 'active (1)' or 'notReady (3)' Upon successful creation of the row, the agent automatically creates a corresponding entry in the snaNodeLinkOperTable. Row deletion can be NMS or agent initiated: (a) The NMS can set the value to 'destroy (6)' only when the value of snaNodeLinkOperState of this Link instance is 'inactive (1)'. The agent will then delete the row corresponding to this Link instance from snaNodeLinkOperTable and from snaNodeLinkAdminTable. (b) The agent detects that a row is in the 'notReady (3)' state for greater than a default period of 5 minutes. (c) The agent will not include a row with RowStatus= 'notReady (3)', after SNA system re-initialization (e.g., reboot)." ::= { snaNodeLinkAdminEntry 4 } -- *************************************************************** -- The following object is updated when there is a change to -- the value of any object in the snaNodeLinkAdminTable. -- *************************************************************** snaNodeLinkAdminTableLastChange OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS current DESCRIPTION "The time stamp of the last change made to any object in this table; this includes row deletions/additions. The expected use of this object is for a Management Station to retrieve the object, then compare it to a previous value. If there is a difference, then this indicates that some Node link configuration information has changed. The Management Station will then retrieve the entire table." ::= { snaNode 7 } Expires June 1994 [Page 36] draft SNANAU MIB December 22, 1993 -- *************************************************************** -- The following table contains the association between -- Nodes and link identifiers. -- It provides the current status. -- *************************************************************** snaNodeLinkOperTable OBJECT-TYPE SYNTAX SEQUENCE OF SnaNodeLinkOperEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains all references to link specific tables for operational parameters. If the Node is configured for multiple links, then it will appear many times in this table. This table augments the snaNodeLinkAdminTable." ::= { snaNode 8 } snaNodeLinkOperEntry OBJECT-TYPE SYNTAX SnaNodeLinkOperEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Entry contains all current parameters of one Node link. The objects in the entry have read-only access." AUGMENTS { snaNodeLinkAdminEntry } ::= { snaNodeLinkOperTable 1 } SnaNodeLinkOperEntry ::= SEQUENCE { snaNodeLinkOperSpecific InstancePointer, snaNodeLinkOperMaxPiu Integer32 } snaNodeLinkOperSpecific OBJECT-TYPE SYNTAX InstancePointer MAX-ACCESS read-only STATUS current DESCRIPTION "The row in a table specific for the link. It is the object identifier representing the instance of the first columnar object in one of the link tables. Expires June 1994 [Page 37] draft SNANAU MIB December 22, 1993 E.g., sdlc link information is provided in the DLC MIB and this object will correspond to the sdlcLSOperAddress instance." ::= { snaNodeLinkOperEntry 1 } snaNodeLinkOperMaxPiu OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "Maximum number of octets that can be exchanged by this PU in one Path Information Unit (PIU)." ::= { snaNodeLinkOperEntry 2 } -- *************************************************************** -- The following object is updated when a row is added/deleted -- from the snaNodeLinkOperTable. -- *************************************************************** snaNodeLinkOperTableLastChange OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS current DESCRIPTION "The time stamp of the last time a row was deleted/added from the table. The expected use of this object is for a Management Station to retrieve this object, then compare it to a previous value. If there is a difference, this indicates that some change has occurred in some Node link status. The Management Station will retrieve the entire table ." ::= { snaNode 9 } -- *************************************************************** -- Traps -- *************************************************************** snaNodeTraps OBJECT IDENTIFIER ::= { snaNode 10 } Expires June 1994 [Page 38] draft SNANAU MIB December 22, 1993 snaNodeStateChangeTrap NOTIFICATION-TYPE OBJECTS { snaNodeOperName, snaNodeOperState } STATUS current DESCRIPTION "The operational state of a PU has changed. The following variables are returned: snaNodeOperName - current name of the Node, with the instance identifying the PU snaNodeOperState - current state after the change." ::= { snaNodeTraps 1 } snaNodeActFailTrap NOTIFICATION-TYPE OBJECTS { snaNodeOperName, snaNodeOperState, snaNodeOperActFailureReason } STATUS current DESCRIPTION "The trap sent to indicate an activation failure. Value snaNodeOperState indicates the current state after change. Value snaNodeOperActFailureReason indicates the failure reason." ::= { snaNodeTraps 2 } -- *************************************************************** -- snaLu group -- -- It contains Managed Objects releted to LUs in general and some -- specific for LUs of type 0, 1, 2, 3. -- *************************************************************** -- *************************************************************** -- The following table contains LU configuration parameters. -- *************************************************************** snaLuAdminTable OBJECT-TYPE SYNTAX SEQUENCE OF SnaLuAdminEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION Expires June 1994 [Page 39] draft SNANAU MIB December 22, 1993 "Table of LUs configuration information. The rows in this table can be created and deleted by a Management Station. Only objects which are common to all types of LUs are included in this table. Objects specific to a particular LU type may be included in an extended table." ::= { snaLu 1 } snaLuAdminEntry OBJECT-TYPE SYNTAX SnaLuAdminEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Contains configuration variables for an LU." INDEX { snaNodeAdminIndex, snaLuAdminLuIndex } ::= { snaLuAdminTable 1 } SnaLuAdminEntry ::= SEQUENCE { snaLuAdminLuIndex Integer32, snaLuAdminName DisplayString, snaLuAdminSnaName DisplayString, snaLuAdminType INTEGER, snaLuAdminDepType INTEGER, snaLuAdminLocalAddress OCTET STRING, snaLuAdminDisplayModel INTEGER, snaLuAdminTerm INTEGER, snaLuAdminRowStatus RowStatus } snaLuAdminLuIndex OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS not-accessible STATUS current DESCRIPTION "Unique index of an LU instance within a PU." Expires June 1994 [Page 40] draft SNANAU MIB December 22, 1993 ::= { snaLuAdminEntry 1 } snaLuAdminName OBJECT-TYPE SYNTAX DisplayString (SIZE(0..48)) MAX-ACCESS read-create STATUS current DESCRIPTION "User configurable name for this LU. May be a zero length string if not assigned. A write operation to this object will not change the operational value reflected in snaLuOperName until the Node has been re-activated (e.g., after the next startup of the SNA services)." ::= { snaLuAdminEntry 2 } snaLuAdminSnaName OBJECT-TYPE SYNTAX DisplayString (SIZE(1..17)) MAX-ACCESS read-create STATUS current DESCRIPTION "The SNA LU name used in exchange of SNA data. A write operation to this object will not change the operational value reflected in snaLuOperSnaName until the Node has been re-activated (e.g., after the next startup of the SNA services)." ::= { snaLuAdminEntry 3 } snaLuAdminType OBJECT-TYPE SYNTAX INTEGER { other(1), lu0(2), lu1(3), lu2(4), lu3(5), lu62(6) } MAX-ACCESS read-create STATUS current DESCRIPTION "Identifies the LU type. Expires June 1994 [Page 41] draft SNANAU MIB December 22, 1993 A write operation to this object will not change the operational value reflected in snaLuOperAdminType until the Node has been re-activated (e.g., after the next startup of the SNA services)." ::= { snaLuAdminEntry 4 } snaLuAdminDepType OBJECT-TYPE SYNTAX INTEGER { dependent(1), independent(2) } MAX-ACCESS read-create STATUS current DESCRIPTION "Identifies whether the LU is dependent or independent. A write operation to this object will not change the operational value reflected in snaLuOperDepType until the Node has been re-activated (e.g., after the next startup of the SNA services)." ::= { snaLuAdminEntry 5 } snaLuAdminLocalAddress OBJECT-TYPE SYNTAX OCTET STRING (SIZE(1)) MAX-ACCESS read-create STATUS current DESCRIPTION The local address for this LU is a byte ranging from 0 to 254. For dependent LUs, this value is between 1 and 254 and for independent LUs this value is always 0. A write operation to this object will not change the operational value reflected in snaLuOperLocalAddress until the Node has been re-activated (e.g., after the next startup of the SNA services)." ::= { snaLuAdminEntry 6 } snaLuAdminDisplayModel OBJECT-TYPE SYNTAX INTEGER { invalid(1), model2A(2), Expires June 1994 [Page 42] draft SNANAU MIB December 22, 1993 model2B(3), model3A(4), model3B(5), model4A(6), model4B(7), model5A(8), model5B(9), dynamic(10) } MAX-ACCESS read-create STATUS current DESCRIPTION "The model type and screen size of the terminal connected to the host. This is only valid for LU Type 2. The values have the following meaning: model2A(2) - Model 2 (24 rows x 80 cols) with base attributes model2B(3) - Model 2 (24 rows x 80 cols) with extended attributes model3A(4) - Model 3 (32 rows x 80 cols) with base attributes model3B(5) - Model 3 (32 rows x 80 cols) with extended attributes model4A(6) - Model 4 (43 rows x 80 cols) with base attributes model4B(7) - Model 4 (43 rows x 80 cols) with extended attributes model5A(8) - Model 5 (27 rows x 132 cols) with base attributes model5B(9) - Model 5 (27 rows x 132 cols) with extended attributes dynamic(10) - Screen size determine with BIND and Read Partition Query. This is only valid for LU Type 2. In case this LU is not Type 2, then this object should contain the invalid(1) value." ::= { snaLuAdminEntry 7 } snaLuAdminTerm OBJECT-TYPE SYNTAX INTEGER { other (1), unbind (2), Expires June 1994 [Page 43] draft SNANAU MIB December 22, 1993 termself (3), rshutd (4), poweroff (5) } MAX-ACCESS read-create STATUS current DESCRIPTION "Indicates the desired method for deactivation of this LUs. This value overrides the default method (snaNodeOperLuTermDefault) for this Node. For LU 6.2, only the value 'unbind (2)' applies. A write operation to this object may immediately change the operational value reflected in snaLuOperTerm depending on the agent implementation." ::= { snaLuAdminEntry 8 } snaLuAdminRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "This object is used by a Management Station to create or delete the row entry in the snaLuAdminTable. To activate a row, the NMS sets the value to 'active (1)' or 'notReady (3)' Upon successful creation of the row, the agent automatically creates a corresponding entry in the snaLuOperTable with snaLuOperState equal to 'inactive (1)'. Row deletion can be NMS or agent initiated: (a) The NMS can set the value to 'destroy (6)' only when the value of snaLuOperState of this LU instance is 'inactive (1)'. The agent will then delete the row correponding to this LU instance from snaLuAdminTable and from snaLuOperTable. (b) The agent detects that a row is in the 'notReady (3)' state for greater than a default period of 5 minutes. (c) The agent will not create a row with RowStatus equal to 'notReady (3)', after SNA system re-initialization (e.g., reboot)." Expires June 1994 [Page 44] draft SNANAU MIB December 22, 1993 ::= { snaLuAdminEntry 9 } -- *************************************************************** -- The following table contains LU state dynamic parameters. -- *************************************************************** snaLuOperTable OBJECT-TYPE SYNTAX SEQUENCE OF SnaLuOperEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Table containing dynamic runtime information and control variables relating to LUs. Only objects which are common to all types of LUs are included in this table. Objects specific to a particular LU type may be included in an extended table. This table augments the snaLuAdminTable." ::= { snaLu 2 } snaLuOperEntry OBJECT-TYPE SYNTAX SnaLuOperEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Contains objects reflecting current information for an LU. Each entry is created by the agent. All entries have read-only access." AUGMENTS { snaLuAdminEntry } ::= { snaLuOperTable 1 } SnaLuOperEntry ::= SEQUENCE { snaLuOperName DisplayString, snaLuOperSnaName DisplayString, snaLuOperType INTEGER, snaLuOperDepType INTEGER, snaLuOperLocalAddress OCTET STRING, snaLuOperDisplayModel Expires June 1994 [Page 45] draft SNANAU MIB December 22, 1993 INTEGER, snaLuOperTerm INTEGER, snaLuOperState INTEGER, snaLuOperSessnCount Gauge } snaLuOperName OBJECT-TYPE SYNTAX DisplayString (SIZE(0..48)) MAX-ACCESS read-only STATUS current DESCRIPTION "User configurable name for this LU. May be a zero length string if not assigned." ::= { snaLuOperEntry 1 } snaLuOperSnaName OBJECT-TYPE SYNTAX DisplayString (SIZE(0..8)) MAX-ACCESS read-only STATUS current DESCRIPTION "Identifies the current SNA LU name. May be a zero length string." ::= { snaLuOperEntry 2 } snaLuOperType OBJECT-TYPE SYNTAX INTEGER { other(1), lu0(2), lu1(3), lu2(4), lu3(5), lu62(6) } MAX-ACCESS read-only STATUS current DESCRIPTION "Identifies the current LU type." ::= { snaLuOperEntry 3 } snaLuOperDepType OBJECT-TYPE SYNTAX INTEGER { dependent(1), Expires June 1994 [Page 46] draft SNANAU MIB December 22, 1993 independent(2) } MAX-ACCESS read-only STATUS current DESCRIPTION "Identifies whether the LU is currently dependent or independent. A write operation to this object will not change the operational value reflected in snaLuOperDepType until the Node has been re-activated (e.g., after the next startup of the SNA services)." ::= { snaLuOperEntry 4 } snaLuOperLocalAddress OBJECT-TYPE SYNTAX OCTET STRING (SIZE(1)) MAX-ACCESS read-only STATUS current DESCRIPTION The local address for this LU is a byte ranging from 0 to 254. For dependent LUs, this value is between 1 and 254 and for independent LUs this value is always 0. A write operation to this object will not change the operational value reflected in snaLuOperLocalAddress until the Node has been re-activated (e.g., after the next startup of the SNA services)." ::= { snaLuOperEntry 5 } snaLuOperDisplayModel OBJECT-TYPE SYNTAX INTEGER { invalid(1), model2A(2), model2B(3), model3A(4), model3B(5), model4A(6), model4B(7), model5A(8), model5B(9), dynamic(10) } Expires June 1994 [Page 47] draft SNANAU MIB December 22, 1993 MAX-ACCESS read-only STATUS current DESCRIPTION "The screen model type of the terminal connected to the host. This is only valid for LU Type 2. In case this LU is not Type 2, then this object should contain the invalid(1) value." ::= { snaLuOperEntry 6 } snaLuOperTerm OBJECT-TYPE SYNTAX INTEGER { other (1), unbind (2), termself (3), rshutd (4), poweroff (5) } MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates the current method for deactivation of this LUs. This value overrides the default method (snaNodeOperLuTermDefault) for this Node." ::= { snaNodeOperEntry 7 } snaLuOperState OBJECT-TYPE SYNTAX INTEGER { inactive (1), active (2), } MAX-ACCESS read-only STATUS current DESCRIPTION "The current operational state of this LU. It has different meaning for dependent and independent LUs. Dependent LU: inactive (1) - LU didn't receive ACTLU or it received DACTLU or received ACTLU and sent negative response, active (2) - LU received ACTLUand acknowledged positively. Independent LU: Expires June 1994 [Page 48] draft SNANAU MIB December 22, 1993 active (2) - the LU is defined and is able to send and receive bind." inactive (1) - the LU has a session count equal to 0." ::= { snaLuOperEntry 8 } snaLuOperSessnCount OBJECT-TYPE SYNTAX Gauge MAX-ACCESS read-only STATUS current DESCRIPTION "The number of currently active LU-LU sessions of this LU. For the independent LU, if this object has value 0, it indicates that LU is inactive." ::= { snaLuOperEntry 9 } -- *************************************************************** -- The following table contains LU session status parameters. -- *************************************************************** snaLuSessnTable OBJECT-TYPE SYNTAX SEQUENCE OF SnaLuSessnEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This is a table containing objects which describe the operational state of LU sessions. Only objects which are common to all types of LU sessions are included in this table. Objects specific to a particular session type may be included in an extended table. When session enters the state 'pending-bind (2)', the corresponding entry in the session table is created by the Agent. When the session state becomes 'unbound (1)' then the session will be removed from the session table by the Agent." ::= { snaLu 3 } snaLuSessnEntry OBJECT-TYPE SYNTAX SnaLuSessnEntry MAX-ACCESS not-accessible Expires June 1994 [Page 49] draft SNANAU MIB December 22, 1993 STATUS current DESCRIPTION "Contains dynamic parameters of an LU-LU session. The indexes determine on which Node, link and LU this session has been establish." INDEX { snaNodeAdminIndex, snaNodeLinkAdminIndex, snaLuAdminLuIndex, snaLuSessnIndex } ::= { snaLuSessnTable 1 } SnaLuSessnEntry ::= SEQUENCE { snaLuSessnIndex Integer32, snaLuSessnLocalApplName DisplayString, snaLuSessnPartnerName DisplayString, snaLuSessnMaxSndRuSize INTEGER snaLuSessnMaxRcvRuSize INTEGER snaLuSessnSndPacingSize INTEGER snaLuSessnRcvPacingSize INTEGER snaLuSessnActiveTime TimeTicks, snaLuSessnAdminState INTEGER, snaLuSessnOperState INTEGER, snaLuSessnBindFailureReason OCTET STRING } snaLuSessnIndex OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "Unique index of the session. It is recommended that the Agent do not reuse the index of a deactivated session for a significant period of time." ::= { snaLuSessnEntry 1 } Expires June 1994 [Page 50] draft SNANAU MIB December 22, 1993 snaLuSessnLocalApplName OBJECT-TYPE SYNTAX DisplayString (SIZE(0..48)) MAX-ACCESS read-only STATUS current DESCRIPTION "The name of the local application using this LU. May be a zero length string if the local application is not known." ::= { snaLuSessnEntry 2 } snaLuSessnPartnerName OBJECT-TYPE SYNTAX DisplayString (SIZE(0..17)) MAX-ACCESS read-only STATUS current DESCRIPTION "For dependent LUs which are indicated by the snaLuOperDepType object containing the value 'dependent (1)', this object contains the Primary LU (PLU) name. For independent LUs, this object contains the fully-qualified partner name of this 6.2 session. A fully qualified name is an SNA NAU entity name preceded by the NetId and a period as the delimiter." ::= { snaLuSessnEntry 3 } snaLuSessnMaxSndRuSize SYNTAX INTEGER MAX-ACCESS read-only STATUS current DESCRIPTION "The maximum RU size used on this session for sending RUs." ::= { snaLuSessnEntry 4 } snaLuSessnMaxRcvRuSize SYNTAX INTEGER MAX-ACCESS read-only STATUS current DESCRIPTION "the maximum RU size used on this session for receiving RUs." ::= { snaLuSessnEntry 5 } snaLuSessnSndPacingSize Expires June 1994 [Page 51] draft SNANAU MIB December 22, 1993 SYNTAX INTEGER MAX-ACCESS read-only STATUS current DESCRIPTION "the size of the send pacing window on this session." ::= { snaLuSessnEntry 6 } snaLuSessnRcvPacingSize SYNTAX INTEGER MAX-ACCESS read-only STATUS current DESCRIPTION "the size of the receive pacing window on this session." ::= { snaLuSessnEntry 7 } snaLuSessnActiveTime OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS current DESCRIPTION "The time stamp when an LU becomes active." ::= { snaLuSessnEntry 8 } snaLuSessnAdminState OBJECT-TYPE SYNTAX INTEGER { unbound (1), bound (3) } MAX-ACCESS read-write STATUS current DESCRIPTION "Indicates the desired operational state of the session. This object is used to change the operational state of the session. Management station can only change the operational state of the session to 'unbound (1)'. Session deactivation: If a session is in the operational state 'bound (3)' then setting the value of this object to 'unbound (1)' will initiate the session shutdown. If a session is in the operational state Expires June 1994 [Page 52] draft SNANAU MIB December 22, 1993 'pending-bind (2)' then setting the value of this object to 'unbound (1)' will initiate the session shutdown. Note: for dependent LU, it is the same as deactivating the LU." ::= { snaSessnAdminEntry 9 } snaLuSessnOperState OBJECT-TYPE SYNTAX INTEGER { unbound (1), pending-bind (2), bound (3) } MAX-ACCESS read-only STATUS current DESCRIPTION "The current operational state of the session. 'unbound (1)' - session has been unbound; in this state it will be removed from the session table by the Agent. 'pending-bind (2)' - this state has different meaning for dependent and independent LUs; for dependent LU - waiting for bind from the host, for independent LU - waiting for bind response. When session enters this state, the corresponding entry in the session table is created by the Agent. 'bound (3)' - session has been successfully bound." ::= { snaLuSessnEntry 10 } snaLuSessnBindFailureReason OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..8)) MAX-ACCESS read-only STATUS current DESCRIPTION "The object identifies the sense code when there is a bind failure. It is taken from the negative bind response or unbind request. This is displayed as 8 hexadecimal digits." ::= { snaLuSessnEntry 11 } Expires June 1994 [Page 53] draft SNANAU MIB December 22, 1993 -- *************************************************************** -- The following table contains LU sessions statistics dynamic -- parameters. -- *************************************************************** snaLuSessnStatsTable OBJECT-TYPE SYNTAX SEQUENCE OF SnaLuSessnStatsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Table containing dynamic statistics information relating to LU sessions. The entries in this table augment the entries in the snaLuSessnTable and cannot be created by a Management Station." ::= { snaLu 4 } snaLuSessnStatsEntry OBJECT-TYPE SYNTAX SnaLuSessnStatsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Contains statistics information of an LU session. Each entry is created by the agent. Objects in this table have read-only access. Each session from snaLuSessnTable has one entry in this table." AUGMENTS { snaLuSessnEntry } ::= { snaLuSessnStatsTable 1 } SnaLuSessnStatsEntry ::= SEQUENCE { snaLuSessnStatsBytesSent Counter32, snaLuSessnStatsBytesReceived Counter32, snaLuSessnStatsRuSent Counter32, snaLuSessnStatsRuReceived Counter32, snaLuSessnStatsNegativeRespSent Counter32, snaLuSessnStatsNegativeRespReceived Counter32 } Expires June 1994 [Page 54] draft SNANAU MIB December 22, 1993 snaLuSessnStatsBytesSent OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of bytes sent by the local LU." ::= { snaLuSessnStatsEntry 1 } snaLuSessnStatsBytesReceived OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of bytes received by the local LU." ::= { snaLuSessnStatsEntry 2 } snaLuSessnStatsRuSent OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of RUs sent by the local LU." ::= { snaLuSessnStatsEntry 3 } snaLuSessnStatsRuReceived OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of RUs received by the local LU." ::= { snaLuSessnStatsEntry 4 } snaLuSessnStatsNegativeRespSent OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of negative responses sent by the local LU." ::= { snaLuSessnStatsEntry 5 } snaLuSessnStatsNegativeRespReceived OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current Expires June 1994 [Page 55] draft SNANAU MIB December 22, 1993 DESCRIPTION "The number of negative responses received by the local LU." ::= { snaLuSessnStatsEntry 6 } -- *************************************************************** -- Traps -- *************************************************************** snaLuTraps OBJECT IDENTIFIER ::= { snaLu 5 } snaLuStateChangeTrap NOTIFICATION-TYPE OBJECTS { snaLuOperName, snaLuOperSnaName, snaLuOperState } STATUS current DESCRIPTION "The operational state of the LU has changed. Value snaLuOperName indicates the name of the LU. Value snaLuOperSnaName indicates the SNA anem fo LU. Value snaLuOperState indicates the current state after change." ::= { snaLuTraps 1 } snaLuSessnBindFailTrap NOTIFICATION-TYPE OBJECTS { snaLuSessnLocalApplName, snaLuSessnPartnerName, snaLuSessnOperState, snaLuSessnBindFailureReason } STATUS current DESCRIPTION "The trap sent to indicate the failure of BIND. Value snaLuSessnLocalApplName indicates local application name. Value snaLuSessnPartnerName indicates the partner name. Value snaLuSessnOperState indicates the current state after change. Value snaLuSessnBindFailureReason indicates the failure reason. agent should not generate more than 1 trap of this type per minute to protect the bandwidth of the network." ::= { snaLuTraps 2 } Expires June 1994 [Page 56] draft SNANAU MIB December 22, 1993 -- *************************************************************** -- snaMgtTools group -- -- Currently this group contains only one table. -- *************************************************************** -- *************************************************************** -- The following table contains RTM statistics for LU 2. -- *************************************************************** snaLuRtmTable OBJECT-TYPE SYNTAX SEQUENCE OF SnaLuRtmEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Table containing RTM information relating to an LU (Type 2). Each entry corresponds to LU 2 entry in snaLuAdminTable." ::= { snaMgtTools 1 } snaLuRtmEntry OBJECT-TYPE SYNTAX SnaLuRtmEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Contains RTM information of an LU (Type 2). Each entry is created by the agent." INDEX { snaLuRtmPuIndex, snaLuRtmLuIndex } ::= { snaLuRtmTable 1 } SnaLuRtmEntry ::= SEQUENCE { snaLuRtmPuIndex Integer32, snaLuRtmLuIndex Integer32, snaLuRtmState INTEGER, snaLuRtmDef INTEGER, snaLuRtmBoundary1 Integer32, snaLuRtmBoundary2 Integer32, snaLuRtmBoundary3 Expires June 1994 [Page 57] draft SNANAU MIB December 22, 1993 Integer32, snaLuRtmBoundary4 Integer32, snaLuRtmCounter1 Counter32, snaLuRtmCounter2 Counter32, snaLuRtmCounter3 Counter32, snaLuRtmCounter4 Counter32, snaLuRtmOverFlow Counter32, snaLuRtmObjective Integer32, snaLuRtmActual Integer32, snaLuRtmNumTrans Integer32, snaLuRtmLastRspTime Integer32, snaLuRtmAvgRspTime Integer32 } snaLuRtmPuIndex OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS not-accessible STATUS current DESCRIPTION "Identifies the PU 2.0 with which this LU is associated." ::= { snaLuRtmEntry 1 } snaLuRtmLuIndex OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS not-accessible STATUS current DESCRIPTION "Uniquely identifies an LU in a PU 2.0." ::= { snaLuRtmEntry 2 } snaLuRtmState OBJECT-TYPE SYNTAX INTEGER { off(1), Expires June 1994 [Page 58] draft SNANAU MIB December 22, 1993 on(2) } MAX-ACCESS read-only STATUS current DESCRIPTION "The current RTM state of an LU." ::= { snaLuRtmEntry 3 } snaLuRtmDef OBJECT-TYPE SYNTAX INTEGER { firstChar(1), kb(2), cdeb(3) } MAX-ACCESS read-only STATUS current DESCRIPTION "The mode of measurement of this RTM request. The values have following meaning: firstChar(1) - time to first character on screen kb(2) - time to keyboard usable by operator cdeb(3) - time to Change Direction/End Bracket." ::= { snaLuRtmEntry 4} snaLuRtmBoundary1 OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "The value of the first boundary in 10th of a second." ::= { snaLuRtmEntry 5 } snaLuRtmBoundary2 OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "The value of the second boundary in 10th of a second." ::= { snaLuRtmEntry 6 } snaLuRtmBoundary3 OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only Expires June 1994 [Page 59] draft SNANAU MIB December 22, 1993 STATUS current DESCRIPTION "The value of the third boundary in 10th of a second." ::= { snaLuRtmEntry 7 } snaLuRtmBoundary4 OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "The value of the fourth boundary in 10th of a second." ::= { snaLuRtmEntry 8 } snaLuRtmCounter1 OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of transactions which fall in the range specified by the first boundary." ::= { snaLuRtmEntry 9 } snaLuRtmCounter2 OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of transactions which fall in the range specified by the second boundary." ::= { snaLuRtmEntry 10 } snaLuRtmCounter3 OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of transactions which fall in the range specified by the third boundary." ::= { snaLuRtmEntry 11 } snaLuRtmCounter4 OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only Expires June 1994 [Page 60] draft SNANAU MIB December 22, 1993 STATUS current DESCRIPTION "The number of transactions which fall in the range specified by the fourth boundary." ::= { snaLuRtmEntry 12 } snaLuRtmOverFlow OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of transactions which exceed the highest range specified by the boundaries." ::= { snaLuRtmEntry 13 } snaLuRtmObjective OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "The desired percentage of transactions which should be under a designated boundary range." ::= { snaLuRtmEntry 14 } snaLuRtmActual OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "The actual percentage of transactions which are under a designated boundary range." ::= { snaLuRtmEntry 15 } snaLuRtmNumTrans OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of transactions executed during this period." ::= { snaLuRtmEntry 16 } snaLuRtmLastRspTime OBJECT-TYPE Expires June 1994 [Page 61] draft SNANAU MIB December 22, 1993 SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "The response time for the last transaction in 10th of a second." ::= { snaLuRtmEntry 17 } snaLuRtmAvgRspTime OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "The average response time for all transactions in 10th of a second." ::= { snaLuRtmEntry 18 } -- *************************************************************** -- Conformance information -- *************************************************************** snanauConformance OBJECT IDENTIFIER ::= { snanauMIB 2 } snanauCompliances OBJECT IDENTIFIER ::= {snanauConformance 1 } snanauGroups OBJECT IDENTIFIER ::= {snanauConformance 2 } -- Compliance statements snanauCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for the SNMPv2 entities which implement the snanau MIB." MODULE -- this module -- Unconditionally mandatory groups MANDATORY-GROUPS { snaNodeGroup, snaLuGroup, snaSessionGroup } -- Conditionally mandatory groups GROUP snaPu20Group DESCRIPTION "The snaPu20Group is mandatory only for those Expires June 1994 [Page 62] draft SNANAU MIB December 22, 1993 entities which implement PU type 2.0" GROUP snaMgtToolsRtmGroup DESCRIPTION "The snaMgtToolsGroup is mandatory only for those entities which implement LU type 2 and RTM." -- Refinement of requirements for objects access. -- agent which does not implement row creation for -- snaNodeAdminTable, snaNodeLinkAdminTable and -- snaLuAdminTable must at least accept -- objects modification (read-write access instead of -- read-create). OBJECT snaNodeAdminName MIN-ACCESS read-write DESCRIPTION "Agent is required to implement read-write access to this object." OBJECT snaNodeAdminType MIN-ACCESS read-write DESCRIPTION "Agent is required to implement read-write access to this object." OBJECT snaNodeAdminXidFormat MIN-ACCESS read-write DESCRIPTION "Agent is required to implement read-write access to this object." OBJECT snaNodeAdminBlockNum MIN-ACCESS read-write DESCRIPTION "Agent is required to implement read-write access to this object." OBJECT snaNodeAdminIdNum MIN-ACCESS read-write DESCRIPTION "Agent is required to implement read-write access to this object." Expires June 1994 [Page 63] draft SNANAU MIB December 22, 1993 OBJECT snaNodeAdminEnablingMethod MIN-ACCESS read-write DESCRIPTION "Agent is required to implement read-write access to this object." OBJECT snaNodeAdminLuTermDefault MIN-ACCESS read-write DESCRIPTION "Agent is required to implement read-write access to this object." OBJECT snaNodeAdminMaxLu MIN-ACCESS read-write DESCRIPTION "Agent is required to implement read-write access to this object." OBJECT snaNodeAdminHostDescription MIN-ACCESS read-write DESCRIPTION "Agent is required to implement read-write access to this object." OBJECT snaNodeAdminStopMethod MIN-ACCESS read-write DESCRIPTION "Agent is required to implement read-write access to this object." OBJECT snaNodeAdminState MIN-ACCESS read-write DESCRIPTION "Agent is required to implement read-write access to this object." OBJECT snaNodeLinkAdminSpecific MIN-ACCESS read-write DESCRIPTION "Agent is required to implement read-write access to this object." OBJECT snaNodeLinkAdminMaxPiu MIN-ACCESS read-write DESCRIPTION Expires June 1994 [Page 64] draft SNANAU MIB December 22, 1993 "Agent is required to implement read-write access to this object." OBJECT snaLuAdminName MIN-ACCESS read-write DESCRIPTION "Agent is required to implement read-write access to this object." OBJECT snaLuAdminSnaName MIN-ACCESS read-write DESCRIPTION "Agent is required to implement read-write access to this object." OBJECT snaLuAdminType MIN-ACCESS read-write DESCRIPTION "Agent is required to implement read-write access to this object." OBJECT snaLuAdminDepType MIN-ACCESS read-write DESCRIPTION "Agent is required to implement read-write access to this object." OBJECT snaLuAdminLocalAddress MIN-ACCESS read-write DESCRIPTION "Agent is required to implement read-write access to this object." OBJECT snaLuAdminDisplayModel MIN-ACCESS read-write DESCRIPTION "Agent is required to implement read-write access to this object." OBJECT snaLuAdminTerm MIN-ACCESS read-write DESCRIPTION "Agent is required to implement read-write access to this object." Expires June 1994 [Page 65] draft SNANAU MIB December 22, 1993 ::= {snanauCompliances 1 } -- Units of conformance snaNodeGroup OBJECT-GROUP OBJECTS {snaNodeAdminIndex, snaNodeAdminName, snaNodeAdminType, snaNodeAdminXidFormat, snaNodeAdminBlockNum, snaNodeAdminIdNum, snaNodeAdminEnablingMethod, snaNodeAdminLuTermDefault, snaNodeAdminMaxLu, snaNodeAdminHostDescription, snaNodeAdminStopMethod, snaNodeAdminState, snaNodeAdminRowStatus, snaNodeAdminTableLastChange, snaNodeOperName, snaNodeOperType, snaNodeOperXidFormat, snaNodeOperBlockNum, snaNodeOperIdNum, snaNodeOperEnablingMethod, snaNodeOperLuTermDefault, snaNodeOperMaxLu, snaNodeOperHostDescription, snaNodeOperStopMethod, snaNodeOperState, snaNodeOperHostSscpId, snaNodeOperStartTime, snaNodeOperLastStateChange, snaNodeOperActFailures, snaNodeOperActFailureReason, snaNodeOperTableLastChange, snaNodeLinkAdminIndex, snaNodeLinkAdminSpecific, snaNodeLinkAdminMaxPiu, snaNodeLinkAdminRowStatus, snaNodeLinkAdminTableLastChange, snaNodeLinkOperSpecific, snaNodeLinkOperMaxPiu, snaNodeLinkOperTableLastChange } STATUS current Expires June 1994 [Page 66] draft SNANAU MIB December 22, 1993 DESCRIPTION "A collection of objects providing the instrumentation of SNA nodes." ::= { snanauGroups 1 } snaLuGroup OBJECT-GROUP OBJECTS { snaLuAdminLuIndex , snaLuAdminName, snaLuAdminSnaName, snaLuAdminType, snaLuAdminDepType, snaLuAdminLocalAddress, snaLuAdminDisplayModel, snaLuAdminTerm, snaLuAdminRowStatus, snaLuOperName, snaLuOperSnaName, snaLuOperType, snaLuOperDepType, snaLuOperLocalAddress, snaLuOperDisplayModel, snaLuOperTerm, snaLuOperState, snaLuOperSessnCount } STATUS current DESCRIPTION "A collection of objects providing the instrumentation of SNA LUs." ::= { snanauGroups 2 } snaSessionGroup OBJECT-GROUP OBJECTS { snaLuSessnIndex, snaLuSessnLocalApplName, snaLuSessnPartnerName, snaLuSessnMaxSndRuSize, snaLuSessnMaxRcvRuSize, snaLuSessnSndPacingSize, snaLuSessnRcvPacingSize, snaLuSessnActiveTime, snaLuSessnAdminState, snaLuSessnOperState, snaLuSessnBindFailureReason, snaLuSessnStatsBytesSent, snaLuSessnStatsBytesReceived, snaLuSessnStatsRuSent, Expires June 1994 [Page 67] draft SNANAU MIB December 22, 1993 snaLuSessnStatsRuReceived, snaLuSessnStatsNegativeRuSent, snaLuSessnStatsNegativeRuReceived } STATUS current DESCRIPTION "A collection of objects providing the instrumentation of SNA sessions." ::= { snanauGroups 3 } snaPu20Group OBJECT-GROUP OBJECTS { snaPu20StatsBytesSent, snaPu20StatsBytesReceived, snaPu20StatsRuSent, snaPu20StatsRuReceived, snaPu20StatsNegativeRespSent, snaPu20StatsNegativeRespReceived, snaPu20StatsActLu, snaPu20StatsInActLu, snaPu20StatsBindLu } STATUS current DESCRIPTION "A collection of objects providing the instrumentation of PU 2.0.} ::= { snanauGroups 4 } snaMgtToolsRtmGroup OBJECT-GROUP OBJECTS { snaLuRtmPuIndex, snaLuRtmLuIndex, snaLuRtmRequest, snaLuRtmState, snaLuRtmDef, snaLuRtmBoundary1, snaLuRtmBoundary2, snaLuRtmBoundary3, snaLuRtmBoundary4, snaLuRtmCounter1, snaLuRtmCounter2, snaLuRtmCounter3, snaLuRtmCounter4, snaLuRtmOverFlow, snaLuRtmObjective, snaLuRtmActual, snaLuRtmNumTrans, snaLuRtmLastRspTime, snaLuRtmAvgRspTime } Expires June 1994 [Page 68] draft SNANAU MIB December 22, 1993 STATUS current DESCRIPTION "A collection of objects providing the instrumentation of RTM for SNA LU 2.0." ::= { snanauGroups 5 } -- end of conformance statement END Expires June 1994 [Page 69] draft SNANAU MIB December 22, 1993 _5. _A_c_k_n_o_w_l_e_d_g_m_e_n_t_s Following people largely contributed to the work on this MIB document: Michael Allen, Robin Chang, Bill Kwan, Special thanks goes to Dave Perkins for his assistance in reviewing this MIB proposal. _6. _R_e_f_e_r_e_n_c_e_s [1] V. Cerf, IAB Recommendations for the Development of Internet Network Management Standards. Internet Working Group Request for Comments 1052. Network Information Center, SRI International, Menlo Park, California, (April, 1988). [2] M.T. Rose and K. McCloghrie, Structure and Identification of Management Information for TCP/IP-based internets, Internet Working Group Request for Comments 1155. Network Information Center, SRI International, Menlo Park, California, (May, 1990). [3] K. McCloghrie and M.T. Rose, Management Information Base for Network Management of TCP/IP-based internets, Internet Working Group Request for Comments 1156, Network Information Center, SRI International, Menlo Park, California, (May, 1990). [4] J.D. Case, M.S. Fedor, M.L. Schoffstall, and J.R. Davin, Simple Network Management Protocol, Internet Working Group Request for Comments 1157. Network Information Center, SRI International, Menlo Park, California, (May, 1990). [5] K. McCloghrie and M.T. Rose (editors), Management Information Base for Network Management of TCP/IP-based internets: MIB-II, Internet Working Group Request for Comments 1213. Network Information Center, SRI International, Menlo Park, California, (March, 1991). [6] Information processing systems - Open Systems Interconnection - Specification of Abstract Syntax Notation One (ASN.1), International Organization for Standardization, International Standard 8824, December 1987. [7] Information processing systems - Open Systems Interconnection - Specification of Basic Encoding Rules for Abstract Notation One (ASN.1), International Organization for Standardization, International Standard 8825, December 1987. [8] Rose, M., and K. McCloghrie, Editors, "Concise MIB Definitions", RFC 1212, Performance Systems International, Hughes LAN Systems, Expires June 1994 [Page 70] draft SNANAU MIB December 22, 1993 March 1991. Expires June 1994 [Page 71] draft SNANAU MIB December 22, 1993 _7. _S_e_c_u_r_i_t_y _C_o_n_s_i_d_e_r_a_t_i_o_n_s Security issues are not discussed in this memo. _8. _A_u_t_h_o_r_s' _A_d_d_r_e_s_s_e_s Zbigniew Kielczewski (editor) Eicon Technology Corporation 2196 32nd Avenue Montreal, Quebec, Canada H8T 3H7 Tel: 1 514 631 2592 E-mail: zbig@eicon.qc.ca Deirdre Kostick Bell Communications Research Red Bank, NJ 07701 Tel: 1 908 758 2642 E-mail: dck2@mail.bellcore.com Kitty Shih (editor) Novell 890 Ross Drive Sunnyvale, CA 94089 Tel: 1 408 747 4305 E-mail: kmshih@novell.com Expires June 1994 [Page 72] draft SNANAU MIB December 22, 1993 _9. _T_a_b_l_e _o_f _C_o_n_t_e_n_t_s 1 Introduction .................................................... 3 2 The SNMPv2 Network Management Framework ......................... 4 2.1 Object Definitions ............................................ 4 3 Overview ........................................................ 5 3.1 Applying MIB II to managing SNA NAUs .......................... 7 3.2 SNANAU MIB Structure .......................................... 7 3.2.1 snaNode group ............................................... 8 3.2.2 snaLu group ................................................. 9 3.2.3 snaMgtTools group ........................................... 10 3.2.4 Conformance statement ....................................... 10 3.3 SNANAU MIB special feature .................................... 10 3.3.1 Row Creation mechanism ...................................... 11 3.3.2 State Diagrams .............................................. 11 4 Object Definitions .............................................. 12 5 Acknowledgments ................................................. 70 6 References ...................................................... 70 7 Security Considerations ......................................... 72 8 Authors' Addresses .............................................. 72 9 Table of Contents ............................................... 73 Expires June 1994 [Page 73]   Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa24081; 13 Dec 93 10:58 EST Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa15552; 13 Dec 93 10:57 EST Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa24067; 13 Dec 93 10:57 EST Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa24011; 13 Dec 93 10:55 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: snanaumib@thumper.bellcore.com Sender:ietf-announce-request@IETF.CNRI.Reston.VA.US From: Internet-Drafts@CNRI.Reston.VA.US Reply-to: Internet-Drafts@CNRI.Reston.VA.US Subject: I-D ACTION:draft-ietf-snanau-snamib-01.txt Date: Mon, 13 Dec 93 10:55:57 -0500 X-Orig-Sender: cclark@CNRI.Reston.VA.US Message-ID: <9312131055.aa24011@IETF.CNRI.Reston.VA.US> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SNA NAU Services MIB Working Group of the IETF. Title : Definitions of Managed Objects for SNA NAUs Author(s) : Z. Kielczewski, D. Kostick, K. Shih Filename : draft-ietf-snanau-snamib-01.txt Pages : 74 Date : 12/10/1993 This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for managing the configuration, monitoring and control of Physical Units (PUs) and Logical Units (LUs) in an SNA environment. PUs and LUs are two types of Network Addressable Units (NAUs) in the logical structure of an SNA network. NAUs are the origination or destination points for SNA data streams. This draft identifies managed objects for PU Type 2.0 and Type 2.1 and LUs Type 0, 1, 2, 3. The generic objects defined here can also be used to manage LU 6.2 and any LU-LU session. This memo does not specify a standard for the Internet community. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and password "guest". After logging in, Type "cd internet-drafts". "get draft-ietf-snanau-snamib-01.txt". Internet-Drafts directories are located at: o East Coast (US) Address: ds.internic.net (198.49.45.10) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o Europe Address: nic.nordu.net (192.36.148.17) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-snanau-snamib-01.txt". For questions, please mail to Internet-Drafts@cnri.reston.va.us. Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19931210161853.I-D@CNRI.Reston.VA.US> FILE /internet-drafts/draft-ietf-snanau-snamib-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-snanau-snamib-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19931210161853.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart--   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa26874; 13 Dec 93 14:06 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa26870; 13 Dec 93 14:06 EST Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa21092; 13 Dec 93 14:06 EST Received: from sunlink.eicon.qc.ca (sunlink.eicon.qc.ca [192.77.49.137]) by thumper.bellcore.com (8.6.4/8.6.4) with SMTP id OAA23605 for ; Mon, 13 Dec 1993 14:04:58 -0500 Received: from mkt.eicon.qc.ca. ([192.219.20.3]) by sunlink.eicon.qc.ca (4.0/SMI-4.0) id AA06553; Mon, 13 Dec 93 14:18:47 EST Received: by mkt.eicon.qc.ca. with Microsoft Mail id <2D0CE6F1@mkt.eicon.qc.ca.>; Mon, 13 Dec 93 14:04:33 PST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Zbigniew Kielczewski To: snanaumib Subject: MIB Draft - outstanding issues, Dec 13. Date: Mon, 13 Dec 93 14:06:00 PST Message-Id: <2D0CE6F1@mkt.eicon.qc.ca.> Encoding: 59 TEXT X-Mailer: Microsoft Mail V3.0 Hi, You have in your hands the second draft of the SNA NAU MIB. Please review it and send your comments to the mailing list. Current structure of the MIB is based on the first draft and discussions during AIW and IETF meetings. Many changes were also made as a result of conference calls attended by Deirdre Kostick, Kitty Shish, Bill Kwan, Robin Cheng, Mike Allen, Dave Perkins and I. Following is the list of issues and questions which are still pending. We will have to resolve all issues before December 22 when we plan to make the recommendation of SNA NAU MIB for Proposed Standard. 1/ RTM - current table has read-only elements. As such it is a candiate for an Oper Table. Do we want to create an Admin Table with read-create access? 2/ snaNodeOperTable, snaNodeLinkOperTable, snaLuOperTable are augments of corresponding Admin tables. What are the initial, default values for Oper objects when the new entry is created? 3/ snaNodeAdminType has a possible value for Node type 1.0 but there is no LU 4 and 7 values for snaLuAdminType. Should we remove the PU 1.0? 4/ We have snaNodeOperActFailures but we do not have object for # of Node Activation Successes. Do we want to have one? 5/ The counters in the snaPu20StatsTable represent traffic for all kinds of sessions (LU-LU, SSCP-PU, SSCP-LU) or just LU-LU sessions? 6/ We snaPu20StatsRuSent and snaPu20StatsRuReceived but we do not have # of PIU sent/received. Do we need them? 7/ In the snaSessnTable we keep only LU-LU session information. In the snaLuOperTable we do not have object(s) for # of RUs sent/received for SSCP-LU session. Do we need them? I am waiting for your feedback. This list will be updated by your comments and I will post the updated list on Wednesday night. Regards, Zbigniew ------------------ Zbigniew Kielczewski Eicon Technology 1 514 631 2592 zbig@eicon.qc.ca   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa18779; 15 Dec 93 23:11 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa18775; 15 Dec 93 23:11 EST Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa24362; 15 Dec 93 23:11 EST Received: from uu5.psi.com (uu5.psi.com [38.145.226.3]) by thumper.bellcore.com (8.6.4/8.6.4) with SMTP id XAA18277 for ; Wed, 15 Dec 1993 23:08:57 -0500 Received: by uu5.psi.com (5.65b/4.0.071791-PSI/PSINet) via UUCP; id AA02113 for ; Wed, 15 Dec 93 22:45:12 -0500 Received: from rabbit1 by hutch.rabbit.com (5.65/3.2.012693-Rabbit Software Corporation) via SMTP; id AA26049 for thumper.bellcore.com!snanaumib; Wed, 15 Dec 93 22:25:43 -0500 Subject: Re: MIB Draft - outstanding issues, Dec 13. To: Zbigniew Kielczewski Date: Wed, 15 Dec 1993 21:22:09 -0500 (EST) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Bill Kwan Cc: snanaumib@thumper.bellcore.com In-Reply-To: <2D0CE6F1@mkt.eicon.qc.ca.> from "Zbigniew Kielczewski" at Dec 13, 93 02:06:00 pm X-Mailer: ELM [version 2.4 PL21] Content-Type: text Content-Length: 3643 Message-Id: <9312152122.aa10070@rabbit1.rabbit.com> Hi, The following are my thoughts on your questions. Comments are appreciated. Regards, Bill > > > Hi, > > You have in your hands the second draft of the SNA NAU MIB. > Please review it and send your comments to the mailing list. > > Current structure of the MIB is based on the first draft and discussions > during AIW and IETF meetings. Many changes were also made > as a result of conference calls attended by Deirdre Kostick, Kitty Shish, > Bill Kwan, Robin Cheng, Mike Allen, Dave Perkins and I. > > Following is the list of issues and questions which are still pending. > We will have to resolve all issues before December 22 when > we plan to make the recommendation of SNA NAU MIB for > Proposed Standard. > > 1/ RTM - current table has read-only elements. As such it is a candiate for > an Oper Table. > Do we want to create an Admin Table with read-create access? > I believe the concern we have is that if we allow changes to be made to the objects (e.g., boundaries) locally by the SNMP Management stations, it could confuse NetView. In theory, each RTM NMVT is self-contained in that it contains the boundaries and definitions, so any change will always be reflected. But we are not sure in practice whether NetView expects the values to be changed (so it may get confused). Unless we can get find out more information on this issue, I vote we leave it as is (i.e., READ-ONLY) for now. > 2/ snaNodeOperTable, snaNodeLinkOperTable, snaLuOperTable > are augments of corresponding Admin tables. What are the initial, default > values for Oper objects when the new entry is created? > What do other MIBs that have Admin and Oper tables do? I would think we should be able to model it after them. > 3/ snaNodeAdminType has a possible value for Node type 1.0 but there > is no LU 4 and 7 values for snaLuAdminType. > Should we remove the PU 1.0? > To be consistant, I vote we get rid of Node Type 1.0. Besides there shouldn't be many type 1 nodes we need to worry about anymore (I hope), and the 5250 controllers are moving toward PU2.1 nodes (if not already). > 4/ We have snaNodeOperActFailures but we do not have object > for # of Node Activation Successes. > Do we want to have one? > Failures are more important for troubleshooting. Not sure how useful successes are, but they might be important. I don't have a strong opinion on this one. Either way is fine with me. > 5/ The counters in the snaPu20StatsTable represent traffic for all kinds > of sessions (LU-LU, SSCP-PU, SSCP-LU) or just LU-LU sessions? > I think they should represent all traffic on the PU regardless of session. > 6/ We snaPu20StatsRuSent and snaPu20StatsRuReceived but > we do not have # of PIU sent/received. > Do we need them? > Good point. At the PU level, it is probably more useful to have PIU counters than RU. Unless someone feels it is important to have both, I vote to replace the RU counters with PIU. > 7/ In the snaSessnTable we keep only LU-LU session information. > In the snaLuOperTable we do not have object(s) for # of RUs sent/received > for SSCP-LU session. > Do we need them? > In general, most data flow on the LU-LU session and not much occurs on the SSCP-LU (except for logon screens). So, I am not sure how important it is to have RU counts for the SSCP-LU session. Unless someone feels it it important, I vote we not have those counters. > I am waiting for your feedback. > This list will be updated by your comments and > I will post the updated list on Wednesday night. > > Regards, > Zbigniew > ------------------ > Zbigniew Kielczewski > Eicon Technology > 1 514 631 2592 > zbig@eicon.qc.ca   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08226; 16 Dec 93 13:50 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08222; 16 Dec 93 13:50 EST Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa14073; 16 Dec 93 13:50 EST Received: from vnet.IBM.COM (vnet.ibm.com [192.239.48.4]) by thumper.bellcore.com (8.6.4/8.6.4) with SMTP id NAA06462 for ; Thu, 16 Dec 1993 13:48:44 -0500 Message-Id: <199312161848.NAA06462@thumper.bellcore.com> Received: from RALVM6 by vnet.IBM.COM (IBM VM SMTP V2R2) with BSMTP id 6296; Thu, 16 Dec 93 13:48:21 EST Date: Thu, 16 Dec 93 13:41:16 EST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "Michael O. Allen (919-254-4442)" X-Addr: Open Architecture Development IBM Networking Systems Research Triangle Park, NC 27709 Internet: moallen@vnet.ibm.com To: snanaumib@thumper.bellcore.com Subject: Comments on December 8 version of SNANAU MIB Good work everybody! I apologize that I have been out of the office so much over the past several weeks. I would have preferred to get these comments in earlier in the process. Unfortunately, I will be on vacation starting in 5 minutes, so I won't be able to follow up until Jan 3. Best wishes to all of you for the holidays! Regards, Mike ....................................................................... Here are my comments: 1. In response to the previous discussion about the value pu10 for snaNodeAdminType and snaNodeOperType, please do not delete this type. We may indeed wish to use this table to reflect a configuration that includes 5250-type devices. Also, as Bill Kwan pointed out, we do not have the corresponding LU types 4 and 7 defined. Please add values for LU4 and LU7 in snaLuAdminType and snaLuOperType. (Bill, thanks for noticing!) 2. I would second the vote to keep the RTM information read-only. 3. snaNodeLinkAdminIndex seems unnatural as one of the indices of snaLuSessnEntry. Since the snaNodeLinkAdmin and Oper tables reflect *SNA* links, for PU 2.0, won't it be the case that there is always a one-to-one correspondence between the entries in the Link table and the entries in the the node table? (A type 2.0 node can only have one SNA link, the one to the subarea boundary function.) So it would seem that the two indices are redundant for PU 2.0. For type 2.1 nodes, either LEN or APPN, such an index would have more meaning -- it would not be redundant anyway -- but I can't see a strong requirement for it. For APPN, I anticipate an extension to this table that contains the complete RSCS (the list of nodes and TGs that make up the path of the session across the network), so having the first link as part of the session table index is not very useful. Is there some mistake in my reasoning on this? If not, I would vote for removing the link index from the indexing of the session table. If the table is just indexed by node, LU, and session, someone could still build an application program that mapped sessions to LUs, LUs to PUs, PUs to links. 4. The DESCRIPTION for snaLuSessnPartnerName says that the partner LU is the PLU if the local LU is dependent, but we don't know which LU has which role for independent LUs. I know that we will extend this table for APPC, but wouldn't it be simpler at this point to just add an object indicating explicitly the role that the local LU plays in the session? How about something like this: snaLuSessnLocalLuRole OBJECT-TYPE SYNTAX INTEGER { secondary (1), primary (2) } MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates the role of the local LU played in the session setup. If the local LU was secondary, then the partner LU sent the bind. If the local LU was primary, then it sent the bind to the partner LU." ::= { snaLUSessnEntry x } Then the text under snaLuSessnPartnerName could be simplified. We will have to add this object as part of the APPC extensions, anyway. 5. I believe that there is need to add one more state to snaLuSessnOperState. Many of the problems that must be debugged in LU implementations are associated with the pending-inactive (or unbind-pending) state that a session enters when an unbind is sent and before the rsp(unbind) is received. Yes, I understand that for dependent LUs that should be a very transient state, but this state is very important for independent LUs. It would seem a trivial change to add that state to the list right now, rather than waiting for the APPC extensions to list it. Do you agree? 6. For snaLuSessnActiveTime, the DESCRIPTION reads "The time stamp when an LU becomes active." Shouldn't this be "The time stamp when the session became active."? 7. I would suggest that the object snaLuSessnBindFailure be renamed to something like snaLuSessnSenseData. The description indicates that it may contain either the sense data associated with -rsp(bind), which is consistent with the name, or it may contain the sense data taken from unbind, which is not consistent with the name. If the name is changed, I think the following additional objects would be potentially very useful for debugging session problems: snaLuSessnTerminationRu OBJECT-TYPE SYNTAX INTEGER { bind-failure (1), unbind (2) } MAX-ACCESS read-only STATUS current DESCRIPTION "The SNA RU that terminated the session. If the session is not in the unbound state, this object has a value of 0." ::= { snaLuSessnEntry xx } snaLuSessnUnbindType OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..1)) MAX-ACCESS read-only STATUS current DESCRIPTION "If the session is in the unbound state, and it was terminated by an Unbind, then this object contains the unbind type value (byte 1 of the unbind RU); otherwise the string is null." ::= { snaLuSessnEntry yy }   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06023; 17 Dec 93 13:10 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa06019; 17 Dec 93 13:10 EST Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa12170; 17 Dec 93 13:10 EST Received: from newsun (newsun.Novell.COM [130.57.10.190]) by thumper.bellcore.com (8.6.4/8.6.4) with SMTP id NAA11479 for ; Fri, 17 Dec 1993 13:09:19 -0500 Received: from va.SJF.Novell.COM by newsun (4.1/SMI-4.1) id AA21768; Fri, 17 Dec 93 10:08:51 PST Received: by va.SJF.Novell.COM (4.1/SMI-4.1) id AA08374; Fri, 17 Dec 93 10:08:01 PST Date: Fri, 17 Dec 93 10:08:01 PST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Kitty Shih Message-Id: <9312171808.AA08374@va.SJF.Novell.COM> To: zbig@eicon.qc.ca Subject: SNA NAU MIB comments - belated Cc: snanaumib@thumper.bellcore.com Folks: Some comments on Zbigniew and other's email: 1. RTM: I don't see any value about leaving the RTM as READ-only. In my mind it serves very little purpose because the SNMP manager does not when NetView will issue the RTM request. So is the SNMP manager going to poll this table continuously just in case NetView issues the request? It should be pointed out that this table is" mandatory for those entitiies which implement LU type 2 and RTM." What does this mean? Is it mandatory for people who implement LU type 2 but not RTM? This needs clarification. I vote to remove this table entirely. The other suggestion is to make it READ-WRITE, but make it clear that this SNMP-initiateded RTM should be treated separately from the NetView RTM - i.e. the users should be prepared at all time to use only one mechanism (NetView or SNMP) to do RTM. If a NetView RTM is in progress, the SNMP-initiated one can be rejected, and vice versa. We can add a new variable in the PU tables to indicate if this SNA stack support SNMP-based RTM. 2. Michael Allen's suggestion of removing snaNodeLinkAdminIndex from the snaLuSessnEntry. Yes, it is redundant for PU 2.0's sessions, but required for PU 2.1's sessions. I did a quick check of the snaLuAdminTable, it is indexed by the PU (Node) Admin Index and LU Index. So I don't think there is any other way to relate a session or an LU to its link. But this is past midnight Friday morning, so I may be missing something? Comments from others? 3. Adding snaLuSessnTerminationRu and snaLuSessnUnbindType: I thought that the entries for sessions are deleted from the table when they are terminated. So, won't these objects be very transient? 4. Adding snaLuSessnLocalLuRole: I think we can rewrite the description for snaLuSessnPartnerName. At this point let's try to leave out too many independent LU's information from this table, since we know adding another object will not be enough. How about if we change the name of the variable to snaLuSessnRemoteName? Kitty   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06033; 17 Dec 93 13:10 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa06029; 17 Dec 93 13:10 EST Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa12175; 17 Dec 93 13:10 EST Received: from newsun (newsun.Novell.COM [130.57.10.190]) by thumper.bellcore.com (8.6.4/8.6.4) with SMTP id NAA11647 for ; Fri, 17 Dec 1993 13:10:32 -0500 Received: from va.SJF.Novell.COM by newsun (4.1/SMI-4.1) id AA21782; Fri, 17 Dec 93 10:10:07 PST Received: by va.SJF.Novell.COM (4.1/SMI-4.1) id AA08407; Fri, 17 Dec 93 10:09:18 PST Date: Fri, 17 Dec 93 10:09:18 PST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Kitty Shih Message-Id: <9312171809.AA08407@va.SJF.Novell.COM> To: zbig@eicon.qc.ca Subject: more SNA NAU MIB comments Cc: snanaumib@thumper.bellcore.com Folks: Additional editiorial comments on the SNA NAU MIB. I apologize for not responding sooner or offer more help to Zbigniew, who should really be applauded for all he has done. I have really been swamped lately. Kitty ****************************************************************************** 1. Original: p.4 3. Overview section: "This draft identifies the proposed set of objects for managing the configuration, monitoring and control of Physical Units (PUs) and Logical Units (LUs) in an SNA environment. PUs and LUs are two types of Network Addressable Units (NAUs) in the logical structure of an SNA network; NAUs are the origination or destination points for SNA data streams. ....." Suggestion: Remove this section since it duplicates the Introduction. 2. Original: p.4: 3. OverView Section: "In this draft, the name "Node" is used to describe SNA Node Type 2.0 and Type 2.1 and the name "LU" is used to describe Logical Unit of Type 0, 1, 2, 3 and 6.2. Note however that only objects common to all LU types are covered here and LU 6.2 specific obejcts are not included in this MIB module." Suggestion: "In this draft, the name "Node" is used to describe SNA Node Type 2.0 and Type 2.1 and the name "LU" is used to describe Logical Unit of Type 0, 1, 2, 3 and 6.2. Note however that only objects common to all PU and LU types are covered here and LU 6.2 specific objects are not included in this MIB module." 3. Original: 3. Overview section. "Highlights of the mib include: + Creation/deletion of Nodes and LUs via the RowStatus objects in the snaNodeAdminTable and in the snaLuAdminTable + Creation/deletion of table entries associating Node instances with link instances via the RowStatus object in the snaNodeLinkAdminTable - it DOES NOT support creation of links - the SNA DLC MIB provides management capabilities for links + Activation/Deactivation of Nodes via the AdminState object in the snaNodeAdminTable + Deactivation of sessions via the AdminState object in the snaSessnTable - it DOES NOT support activation or deactivation of LUs - it DOES NOT support activation of sessions + Monitoring and modification of parameters related to Nodes, LUs, and Node/link associations + Monitoring of session operational parameters + PU2.0 operational statistics + Session operational statistics" + RTM statistics + Traps for: Node state change Node activation failure LU state change LU session bind failure Suggestion: Move the "DOES NOT support" clauses to a separate headings. 4. Suggestion: Can we run through the MIB through a spell-checker? 5. Original: p.6 3.2. "SNA NAU MIB Structure" "Admin table contains configuration parameters which will be used by the SNA system for next service initialization. This usually happens when the system is reactivated but for some obejcts it may be possible to apply the Admin parameters immediately. The objects in the Admin table can be modified by Managament Station. New entries in the Admin table can be created and existing entries can be deleted which permits Management Station to dynamically define the resources (PUs, LUs) for SNA system. Oper table is an extension (augment) of Admin table. It contains obejcts which corespond to the values of parameters currently used by the SNA system. Special object, called AdminState, which contains to desired state of PU or Session is used to control the operational state of PU and Session. LU operational state can not be controled by objects in this MIB." Suggestion: "Admin table contains parameters which are used by the Management Station to affect the operation of the SNA service. Some parameters are used to initialize and configure the SNA service at the next startup, while others can take effect immediately. A Management Station can dynamically define SNA resources (PUs, LUs) by creating new entries in the Admin table. It uses a special object, AdminState, to control the desired state of a defined PU or LU Session resource. Note that this MIB does not allow the manipulation of an LU's operational state." 6. p.10, 3.3.2 State Diagrams: The diagram may need grid or border. As is I cannot read nor understand the diagram. 7. Add preposition before noun: don't start off sentence with "Agent" or "Management Station". Should be "An Agent" and "A Management Station". 8. snaNodeAdminTable: The sentence: "Agent can create entries initially based on the nodes configuration file." directly conflicts with the following paragraph: "How the Agent or management station obtains the initial value of each object at creation time is an implementation specific issue not addressed here." How about the following: "Entries (i.e. rows) in this table can eb created by either an Agent or a Mangement Station. The Management Station can do this through setting the appropriate value in the snaNodeAdminRowStatus. .... How the Agent or Management Station obtains the initial value of each object at creation time is an implemention specific issue. For example, such information may be obtained from a configuration file." 9. In general, make sure all descriptions start either with a verb or noun. For example: "Identifies...." or "This object identifies.." Currently we use a mixture of both. 10. snaNodeOperTableLastChange, snaNodeLinkAdmin/OperTableLastChange, .... Description should reflect that in snaNodeAdminTableLastChange. 11. snaLuAdminTerm and snaLuOperTerm should reflect the description of each enumerated value that Bill Kwan submitted earlier on. 12. Consistency of naming: are we calling the manager: Management Station or NMS? 13. snaLuOperName: Description should reflect that in snaLuAdminName. It CANNOT be a zero-length string. 14. Do we need a TableLastChange for LU and Session tables? Did we discuss this in the teleconference? Or is this getting really late and I am not thinking clearly? Kitty   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03364; 21 Dec 93 10:23 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa03360; 21 Dec 93 10:23 EST Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa05018; 21 Dec 93 10:23 EST Received: from zoom.eicon.qc.ca (zoom.eicon.qc.ca [192.77.49.137]) by thumper.bellcore.com (8.6.4/8.6.4) with SMTP id KAA22648 for ; Tue, 21 Dec 1993 10:21:21 -0500 Received: from mkt.eicon.qc.ca. (admin.eicon.qc.ca) by zoom.eicon.qc.ca with SMTP id AA22524 (5.67a/IDA-1.5 for ); Tue, 21 Dec 1993 10:20:36 -0500 Received: by mkt.eicon.qc.ca. with Microsoft Mail id <2D173DFD@mkt.eicon.qc.ca.>; Tue, 21 Dec 93 10:18:37 PST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Zbigniew Kielczewski To: snanaumib Subject: RE: MIB Draft - outstanding issues, Dec 13. Date: Tue, 21 Dec 93 10:19:00 PST Message-Id: <2D173DFD@mkt.eicon.qc.ca.> Encoding: 255 TEXT X-Mailer: Microsoft Mail V3.0 Hi, Thanks for your comments on the issues listed in the last mail. Based on your opinions, I propose following solutions to original 7 points: >1/ RTM - current table has read-only elements. As such it is a candiate for >an Oper Table. >Do we want to create an Admin Table with read-create access? We will keep current table as is with small modifcations suggested by Robin. (The details of modifications are listed below.) >2/ snaNodeOperTable, snaNodeLinkOperTable, snaLuOperTable >are augments of corresponding Admin tables. What are the initial, default >values for Oper objects when the new entry is created? If Dave will not object I propose that we do not provide any values for objects when new entry is created. (this applies also to objects in Admin tables.) The get request will fail with 'no-such-name' or 'no-such-instance' error. Only when a PU, Link or LU is activated we will expect to get current values from those tables. >3/ snaNodeAdminType has a possible value for Node type 1.0 but there >is no LU 4 and 7 values for snaLuAdminType. >Should we remove the PU 1.0? I will keep PU 1.0 and put LU 4 nd 7 in the snaLuAdminType and snaLuOperType. >4/ We have snaNodeOperActFailures but we do not have object >for # of Node Activation Successes. >Do we want to have one? I will not create this new object. >5/ The counters in the snaPu20StatsTable represent traffic for all kinds >of sessions (LU-LU, SSCP-PU, SSCP-LU) or just LU-LU sessions? I will specify in the descriptions that counters represent all kinds of sessions. >6/ We snaPu20StatsRuSent and snaPu20StatsRuReceived but >we do not have # of PIU sent/received. >Do we need them? I will replace the Ru by Piu as more appropraite for the PU traffic. >7/ In the snaSessnTable we keep only LU-LU session information. >In the snaLuOperTable we do not have object(s) for # of RUs sent/received >for SSCP-LU session. >Do we need them? I will not create those new objects. Mike listed some additional issues in his mail (Dec.16). Following are my comments on that based on the responses from Kitty and Robin. >1. In response to the previous discussion about the value pu10 for > snaNodeAdminType and snaNodeOperType, please do not delete this > type. We may indeed wish to use this table to reflect a > configuration that includes 5250-type devices. Also, as Bill Kwan > pointed out, we do not have the corresponding LU types 4 and 7 > defined. Please add values for LU4 and LU7 in snaLuAdminType and > snaLuOperType. (Bill, thanks for noticing!) OK >2. I would second the vote to keep the RTM information read-only. OK >3. snaNodeLinkAdminIndex seems unnatural as one of the indices of > snaLuSessnEntry. Since the snaNodeLinkAdmin and Oper tables > reflect *SNA* links, for PU 2.0, won't it be the case that there is > always a one-to-one correspondence between the entries in the Link > table and the entries in the the node table? (A type 2.0 node can > only have one SNA link, the one to the subarea boundary function.) > So it would seem that the two indices are redundant for PU 2.0. For > type 2.1 nodes, either LEN or APPN, such an index would have more > meaning -- it would not be redundant anyway -- but I can't see a > strong requirement for it. For APPN, I anticipate an extension to > this table that contains the complete RSCS (the list of nodes and > TGs that make up the path of the session across the network), so > having the first link as part of the session table index is not > very useful. > Is there some mistake in my reasoning on this? If not, I would > vote for removing the link index from the indexing of the session > table. If the table is just indexed by node, LU, and session, > someone could still build an application program that mapped > sessions to LUs, LUs to PUs, PUs to links. There is no way to relate the Session to a Link for independent LU, so we will keep the Link index. >4. The DESCRIPTION for snaLuSessnPartnerName says that the partner LU > is the PLU if the local LU is dependent, but we don't know which LU > has which role for independent LUs. I know that we will extend > this table for APPC, but wouldn't it be simpler at this point to > just add an object indicating explicitly the role that the local LU > plays in the session? How about something like this: > snaLuSessnLocalLuRole OBJECT-TYPE > SYNTAX INTEGER { > secondary (1), > primary (2) > } > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "Indicates the role of the local LU played in the session > setup. If the local LU was secondary, then the partner > LU sent the bind. If the local LU was primary, then it > sent the bind to the partner LU." > ::= { snaLUSessnEntry x } > > Then the text under snaLuSessnPartnerName could be simplified. We > will have to add this object as part of the APPC extensions, > anyway. I would not include more information which is specific to independent LUs. I will change the object name to snaLuSessnRemoteLuName and modify description accordingly. >5. I believe that there is need to add one more state to > snaLuSessnOperState. Many of the problems that must be debugged in > LU implementations are associated with the pending-inactive (or > unbind-pending) state that a session enters when an unbind is sent > and before the rsp(unbind) is received. Yes, I understand that for > dependent LUs that should be a very transient state, but this state > is very important for independent LUs. It would seem a trivial > change to add that state to the list right now, rather than waiting > for the APPC extensions to list it. Do you agree? OK, I agree that it will be usefull. I will add that plus description and also state diagram will change. >6. For snaLuSessnActiveTime, the DESCRIPTION reads "The time stamp > when an LU becomes active." Shouldn't this be "The time stamp when > the session became active."? OK. >7. I would suggest that the object snaLuSessnBindFailure be renamed to > something like snaLuSessnSenseData. The description indicates that > it may contain either the sense data associated with -rsp(bind), > which is consistent with the name, or it may contain the sense data > taken from unbind, which is not consistent with the name. > > If the name is changed, I think the following additional objects > would be potentially very useful for debugging session problems: > > > snaLuSessnTerminationRu OBJECT-TYPE > SYNTAX INTEGER { > bind-failure (1), > unbind (2) > } > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The SNA RU that terminated the session. If the > session is not in the unbound state, this object > has a value of 0." > ::= { snaLuSessnEntry xx } > > snaLuSessnUnbindType OBJECT-TYPE > SYNTAX OCTET STRING (SIZE(0..1)) > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "If the session is in the unbound state, and it was > terminated by an Unbind, then this object contains > the unbind type value (byte 1 of the unbind RU); > otherwise the string is null." > ::= { snaLuSessnEntry yy } OK, I agree with the proposition but this values will not be kept by the Agent for long time since the entry should be removed from the table when session goes to the state 'unbound'. I also received the mail form Kitty (Dec 17) with mostly ediotorial comments which will be implemented. One question only requires an answare: >14. Do we need a TableLastChange for LU and Session tables? Did we > discuss this in the teleconference? Or is this getting really > late and I am not thinking clearly? We considered that the changes to those table will be too frequent so that LastChange object would indicate a change in most cases forcing the Management Station to get the Table anyway. Following are Robin's comments (I think he forgot to CC it to the mailing list): >Hi, SNANAU MIBers: >I agree with Mike Allen's comments you received earlier today (12/16). >In addition, I have some additional comments: > >1) RTM - I agree with Bill Kwan's comment that >this table should be kept read-only as it is now. >Allowing an SNMP manager to change RTM setup may cause some confusion >with NetView. For the time being, I don't think it is worthwhile >to go through the trouble defining an OperTable for RTM. > >2) RTP - >snaLuRtmObjective/snaLuRtmActual have DESCRIPTION which states > "The desired/actual percentage of transactions > which should be under a designated boundary range." > >--> Well, there may be five ranges, which range it is? >I think an object is needed to indicate where the designated >boundary range is for the desired percentage. >Also, I think snaLuRtmActual can be deleted since it's value can be >calculated using other objects in the same table. My proposal: > >snaLuRtmObjPercent OBJECT-TYPE > SYNTAX Integer32 > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The desired percentage of transactions > which should be under a designated boundary > range indicated by snaLuRtmObjRange." > ::= { snaLuRtmEntry 14 } > >snaLuRtmObjRange OBJECT-TYPE > SYNTAX INTEGER { > other(1) -- not specified > range1(2) -- less than boundary 1 > range2(3) -- between boundary 1 and 2 > range3(4) -- between boundary 2 and 3 > range4(5) -- between boundary 3 and 4 > range5(6) -- greater than boundary 4 > } > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The designated boundary range which > snaLuRtmObject refers to." > ::= { snaLuRtmEntry 15 } OK with this modification. I will include it. I will make the modifications to the MIB and unless you make some more comments before Wednesday, Dec 22nd 5:00PM EST this text will be sent as final I-D. Regards, Zbigniew ------------------ Zbigniew Kielczewski Eicon Technology 1 514 631 2592 zbig@eicon.qc.ca   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04922; 21 Dec 93 13:12 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04918; 21 Dec 93 13:12 EST Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa08521; 21 Dec 93 13:12 EST Received: from vnet.IBM.COM (vnet.ibm.com [192.239.48.4]) by thumper.bellcore.com (8.6.4/8.6.4) with SMTP id NAA04134 for ; Tue, 21 Dec 1993 13:11:08 -0500 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: CHENG@ralvm6.vnet.ibm.com Message-Id: <199312211811.NAA04134@thumper.bellcore.com> Received: from RALVM6 by vnet.IBM.COM (IBM VM SMTP V2R2) with BSMTP id 7596; Tue, 21 Dec 93 13:10:44 EST Date: Tue, 21 Dec 93 13:09:19 EST To: ZBIG@eicon.qc.ca cc: snanaumib@thumper.bellcore.com Subject: snanau mib Some syntax errors I have found in the SNANAU MIB by sending the MIB module in the body of a mail message to: mosy@dbc.mtview.ca.us Hope this will save the editor some time! Robin Cheng - - - - - - 1) snaNodeAdminLuTermDefault OBJECT-TYPE ... SYNTA INTEGER { ===> SYNTAX INTEGER { 2) snaNodeAdminMaxLu OBJECT TYPE ... SNA services). ===> SNA services)." -- End quote was missing. 3) snaLuAdminLocalAddress DESCRIPTION The local address for this LU is ==> "The local address for this LU is -- Begin quote was missing. 4) snaLuOperLocalAddress OBJECT-TYPE DESCRIPTION The local address for this LU is a byte ranging ==> "The local address for this LU is a byte ranging -- Begin quote was missing. 5) snaLuOperState OBJECT-TYPE ... Independent LU: active (2) - the LU is defined and is able to send and receive bind." -- <== extra end quote inactive (1) - the LU has a session count equal to 0." ::= { snaLuOperEntry 8 } -- Extra end quote should be deleted.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05036; 21 Dec 93 13:29 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05032; 21 Dec 93 13:29 EST Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa08775; 21 Dec 93 13:29 EST Received: from newsun.Novell.COM (newsun.Novell.COM [130.57.10.190]) by thumper.bellcore.com (8.6.4/8.6.4) with SMTP id NAA04937 for ; Tue, 21 Dec 1993 13:28:01 -0500 Received: from va.SJF.Novell.COM by newsun.Novell.COM (4.1/SMI-4.1) id AA05856; Tue, 21 Dec 93 10:24:53 PST Received: by va.SJF.Novell.COM (4.1/SMI-4.1) id AA22301; Tue, 21 Dec 93 10:27:08 PST Date: Tue, 21 Dec 93 10:27:08 PST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Kitty Shih Message-Id: <9312211827.AA22301@va.SJF.Novell.COM> To: snanaumib@thumper.bellcore.com Subject: RTM Subject: RTM Folks: I don't mind if we don't add Oper table to RTM. But I still think we should simply delete this table. I fail to see its use at this point. Kitty :wq   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06256; 21 Dec 93 14:34 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa06252; 21 Dec 93 14:34 EST Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa09939; 21 Dec 93 14:34 EST Received: from vnet.IBM.COM (vnet.ibm.com [192.239.48.4]) by thumper.bellcore.com (8.6.4/8.6.4) with SMTP id OAA09107 for ; Tue, 21 Dec 1993 14:32:17 -0500 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: CHENG@ralvm6.vnet.ibm.com Message-Id: <199312211932.OAA09107@thumper.bellcore.com> Received: from RALVM6 by vnet.IBM.COM (IBM VM SMTP V2R2) with BSMTP id 8233; Tue, 21 Dec 93 14:31:54 EST Date: Tue, 21 Dec 93 14:25:50 EST To: snanaumib@thumper.bellcore.com Subject: RTM Subject: Note from you attached below Kitty wrote: >Folks: >I don't mind if we don't add Oper table to RTM. But I still think we should >simply delete this table. I fail to see its use at this point. >Kitty I don't mind that RTM table be deleted in SNANAU MIB. I think this is the only reasonable way for us to get the next I-D ready by Dec. 22, 1993. Robin Cheng   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04193; 22 Dec 93 11:02 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04188; 22 Dec 93 11:02 EST Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa09717; 22 Dec 93 11:02 EST Received: from vnet.IBM.COM (vnet.ibm.com [192.239.48.4]) by thumper.bellcore.com (8.6.4/8.6.4) with SMTP id LAA02339 for ; Wed, 22 Dec 1993 11:01:45 -0500 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: CHENG@ralvm6.vnet.ibm.com Message-Id: <199312221601.LAA02339@thumper.bellcore.com> Received: from RALVM6 by vnet.IBM.COM (IBM VM SMTP V2R2) with BSMTP id 2819; Wed, 22 Dec 93 11:01:22 EST Date: Wed, 22 Dec 93 10:59:56 EST To: snanaumib@thumper.bellcore.com Subject: syntax errors A few more syntax errors I have found running mosy for SNMPv2. 6) snaLuOperState OBJECT-TYPE SYNTAX INTEGER { inactive (1), active (2), -- <= extra comma to be deleted. } 7) SnaLuSessnEntry ::= SEQUENCE { snaLuSessnIndex Integer32, snaLuSessnLocalApplName DisplayString, snaLuSessnPartnerName DisplayString, snaLuSessnMaxSndRuSize -- DEL INTEGER ==> INTEGER, snaLuSessnMaxRcvRuSize -- DEL INTEGER ==> INTEGER, snaLuSessnSndPacingSize -- DEL INTEGER ==> INTEGER, snaLuSessnRcvPacingSize -- DEL INTEGER ==> INTEGER, 8) snaLuSessnMaxSndRuSize ==> snaLuSessnMaxSndRuSize OBJECT-TYPE SYNTAX INTEGER ==> SYNTAX Integer32 snaLuSessnMaxRcvRuSize ==> snaLuSessnMaxRcvRuSize OBJECT-TYPE SYNTAX INTEGER ==> SYNTAX Integer32 snaLuSessnSndPacingSize ==> snaLuSessnSndPacingSize OBJECT-TYPE SYNTAX INTEGER ==> SYNTAX Integer32 snaLuSessnRcvPacingSize ==> snaLuSessnRcvPacingSize OBJECT-TYPE SYNTAX INTEGER ==> SYNTAX Integer32 9) snaPu20Group OBJECT-GROUP DESCRIPTION "A collection of objects providing the -- DEL instrumentation of PU 2.0.} ==> instrumentation of PU 2.0." ::= { snanauGroups 4 } 10) snaLuOperSessnCount OBJECT-TYPE SYNTAX Gauge ==> SYNTAX Gauge32 snaSessionGroup OBJECT-GROUP OBJECTS { ... -- DEL snaLuSessnStatsNegativeRuSent, -- DEL snaLuSessnStatsNegativeRuReceived } ==> snaLuSessnStatsNegativeRespSent, ==> snaLuSessnStatsNegativeRespReceived } Robin Cheng   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07328; 23 Dec 93 12:53 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07324; 23 Dec 93 12:53 EST Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa10485; 23 Dec 93 12:53 EST Received: from zoom.eicon.qc.ca (zoom.eicon.qc.ca [192.77.49.137]) by thumper.bellcore.com (8.6.4/8.6.4) with SMTP id MAA24475 for ; Thu, 23 Dec 1993 12:52:11 -0500 Received: from mkt.eicon.qc.ca. (uk.eicon.qc.ca) by zoom.eicon.qc.ca with SMTP id AA03754 (5.67a/IDA-1.5 for ); Thu, 23 Dec 1993 12:52:13 -0500 Received: by mkt.eicon.qc.ca. with Microsoft Mail id <2D1A047C@mkt.eicon.qc.ca.>; Thu, 23 Dec 93 12:50:04 PST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Zbigniew Kielczewski To: snanaumib Subject: Final Draft Date: Thu, 23 Dec 93 12:51:00 PST Message-Id: <2D1A047C@mkt.eicon.qc.ca.> Encoding: 54 TEXT X-Mailer: Microsoft Mail V3.0 Hi, The message has been send on December 09 by Deirdre Kostick (co-chair of the snanau MIB Working Group) asking for final comments on the I-D (draft-ietf-snanau-snamib-01.txt). I have received a number of editorial comments and I modified the text accordingly. We also received technical comments on following issues: 1/ RTM table will have read-only access. 2/ The tables snaNodeOperTable, snaNodeLinkOperTable, snaLuOperTable will not be provided with initial default values. 3/ We added LU type 4 and 7 to match PU type 1.0. 4/ The counters in the snaPu20StatsTable represent traffic for all kinds of sessions (LU-LU, SSCP-PU, SSCP-LU). 5/ snaPu20StatsRuSent and snaPu20StatsRuReceived have been replaced by counters for # of PIU sent/received, as more appropriate. 6/ One more state has been added to snaLuSessnOperState : 'pending-unbind'. 7/ snaLuSessnBindFailure has been renamed to snaLuSessnSenseData and two new objects added : snaLuSessnTerminationRu and snaLuSessnUnbindType. 8/ snaLuRtmObjective and snaLuRtmActual have been replaced by snaLuRtmObjPercent and snaLuRtmObjRange. The next version of the SNA NAU MIB will be posted to ietf drafts on Thursday, December 23 under the name 'draft-ietf-snanau-snamib-02.txt'. In the same time I will inform Marshall Rose, Network Management Area Director, that our group completed the work specified by the charter and I will request that this draft be considered as a Proposed Internet Standard. This completes first phase of our work - now the fun will start, it is the implementation time! Thanks to all of you for the work on this MIB - it was a great experience. I hope that we will have the opportunity to work together in the future - the world of SNA is wide open for SNMP management! I would especially like to thank Deirdre, co-chair of this WG, it was her work that made us meet all the deadlines. Big thanks also to Kitty, MIB editor, her effort largely contributed to the quality of this work. And finally, I have to express my gratitude to Dave who was our SNMP consultant (and if necessary nrof debugger :-) ). Thanks again, have great vacation and Happy New Year. Regards, Zbigniew   Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05628; 28 Dec 93 11:59 EST Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa09170; 28 Dec 93 11:59 EST Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05606; 28 Dec 93 11:59 EST Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa05478; 28 Dec 93 11:57 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: snanaumib@thumper.bellcore.com Sender:ietf-announce-request@IETF.CNRI.Reston.VA.US From: Internet-Drafts@CNRI.Reston.VA.US Reply-to: Internet-Drafts@CNRI.Reston.VA.US Subject: I-D ACTION:draft-ietf-snanau-snamib-02.txt Date: Tue, 28 Dec 93 11:57:31 -0500 X-Orig-Sender: cclark@CNRI.Reston.VA.US Message-ID: <9312281157.aa05478@IETF.CNRI.Reston.VA.US> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SNA NAU Services MIB Working Group of the IETF. Title : Definitions of Managed Objects for SNA NAUs Author(s) : Z. Kielczewski, D. Kostick, K. Shih Filename : draft-ietf-snanau-snamib-02.txt Pages : 77 Date : 12/23/1993 This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for managing the configuration, monitoring and control of Physical Units (PUs) and Logical Units (LUs) in an SNA environment. PUs and LUs are two types of Network Addressable Units (NAUs) in the logical structure of an SNA network. NAUs are the origination or destination points for SNA data streams. This draft identifies managed objects for PU Type 1.0, 2.0 and Type 2.1 and LU Type 0, 1, 2, 3, 4, 7. The generic objects defined here can also be used to manage LU 6.2 and any LU-LU session. This memo does not specify a standard for the Internet community. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and password "guest". After logging in, Type "cd internet-drafts". "get draft-ietf-snanau-snamib-02.txt". Internet-Drafts directories are located at: o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: venera.isi.edu (128.9.0.32) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o Europe Address: nic.nordu.net (192.36.148.17) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-snanau-snamib-02.txt". For questions, please mail to Internet-Drafts@cnri.reston.va.us. Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19931223135659.I-D@CNRI.Reston.VA.US> FILE /internet-drafts/draft-ietf-snanau-snamib-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-snanau-snamib-02.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19931223135659.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart--   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12328; 30 Dec 93 19:26 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12324; 30 Dec 93 19:26 EST Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa18382; 30 Dec 93 19:26 EST Received: from dbc.mtview.ca.us (ppp.dbc.mtview.ca.us [192.103.140.254]) by thumper.bellcore.com (8.6.4/8.6.4) with ESMTP id TAA18630 for ; Thu, 30 Dec 1993 19:25:58 -0500 Received: from localhost by dbc.mtview.ca.us (5.65/3.1.090690) id AA23618; Thu, 30 Dec 93 16:24:25 -0800 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: IETF Area Director for Network Management Cc: IETF Area Director for Network Management To: snanaumib@thumper.bellcore.com Subject: NM-D review draft-ietf-snanau-02.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Id: <23614.757297464.1@dbc.mtview.ca.us> Date: Thu, 30 Dec 1993 16:24:24 -0800 Message-Id: <23617.757297464@dbc.mtview.ca.us> X-Orig-Sender: mrose@dbc.mtview.ca.us Hi. (Belated) congratulations on reaching concensus on the above I-D! I anticipate the NM-D review to be completed by 1/31. Thanks! /mtr