Delivery-Date: Mon, 02 Dec 1996 10:47:22 -0800 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.5/8.7.3) id KAA10612 for X-agentx; Mon, 2 Dec 1996 10:47:22 -0800 (PST) Received: from gauntlet.fv.com (gauntlet.fv.com [207.67.199.118]) by fv.com (8.7.5/8.7.3) with ESMTP id KAA10609 for ; Mon, 2 Dec 1996 10:47:21 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.7.5/8.7.3) id NAA19202 for ; Mon, 2 Dec 1996 13:48:16 -0500 (EST) Received: from shekel.fv.com(207.67.199.130) by gauntlet.fv.com via smap (3.2) id xma019153; Mon, 2 Dec 96 10:47:45 -0800 Received: from gauntlet.fv.com (gauntlet-in.fv.com [10.0.0.2]) by shekel.fv.com (8.7.5/8.7.3) with ESMTP id KAA24524 for ; Mon, 2 Dec 1996 10:48:05 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.7.5/8.7.3) id NAA19134 for ; Mon, 2 Dec 1996 13:47:44 -0500 (EST) Received: from ietf.org(132.151.1.19) by gauntlet.fv.com via smap (3.2) id xma019093; Mon, 2 Dec 96 10:47:15 -0800 Received: from ietf.ietf.org by ietf.org id aa06437; 2 Dec 96 11:29 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: agentx@fv.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-agentx-ext-pro-01.txt Date: Mon, 02 Dec 1996 11:29:24 -0500 Sender: cclark@ietf.org Message-ID: <9612021129.aa06437@ietf.org> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SNMP Agent Extensibility Working Group of the IETF. Title : Agent Extensibility (AgentX) Protocol Version 1 Author(s) : M. Daniele, B. Wijnen, D. Francisco Filename : draft-ietf-agentx-ext-pro-01.txt Pages : 72 Date : 11/27/1996 This memo defines a framework for extensible SNMP agents. It defines processing entities called master agents and subagents, a protocol (AgentX) used to communicate between them, and the elements of procedure by which the extensible agent processes SNMP protocol messages. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-agentx-ext-pro-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-agentx-ext-pro-01.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-agentx-ext-pro-01.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: <19961127164135.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-agentx-ext-pro-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-agentx-ext-pro-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961127164135.I-D@ietf.org> --OtherAccess-- --NextPart--   Delivery-Date: Thu, 05 Dec 1996 08:35:12 -0800 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.5/8.7.3) id IAA17657 for X-agentx; Thu, 5 Dec 1996 08:35:11 -0800 (PST) Received: from gauntlet.fv.com (gauntlet.fv.com [207.67.199.118]) by fv.com (8.7.5/8.7.3) with ESMTP id IAA17654 for ; Thu, 5 Dec 1996 08:35:11 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.7.5/8.7.3) id LAA21780 for ; Thu, 5 Dec 1996 11:35:57 -0500 (EST) Received: from shekel.fv.com(207.67.199.130) by gauntlet.fv.com via smap (3.2) id xma021702; Thu, 5 Dec 96 08:35:28 -0800 Received: from gauntlet.fv.com (gauntlet-in.fv.com [10.0.0.2]) by shekel.fv.com (8.7.5/8.7.3) with ESMTP id IAA05560 for ; Thu, 5 Dec 1996 08:35:50 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.7.5/8.7.3) id LAA21688 for ; Thu, 5 Dec 1996 11:35:27 -0500 (EST) Received: from relay1.smtp.psi.net(38.8.14.2) by gauntlet.fv.com via smap (3.2) id xma021673; Thu, 5 Dec 96 08:35:10 -0800 Received: from nips.acec.com by relay1.smtp.psi.net (8.6.12/SMI-5.4-PSI) id LAA01195; Thu, 5 Dec 1996 11:34:18 -0500 Received: from bnatale by nips.acec.com (5.65/3.2.083191-American Computer and Electronics Corp. ) id AA06527; Thu, 5 Dec 1996 11:35:56 -0500 Date: Thu, 5 Dec 1996 11:33:58 EST From: Bob Natale Subject: Agenda for AgentX meeting in San Jose To: agentx@fv.com Message-Id: Priority: Normal Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Hi everyone, The AgentX WG will hold one meeting at the San Jose IETF: Wed (Dec 11), 9:00 - 11:30 Here is the planned agenda: 1. Housekeeping 2. Issues resolution review* 3. Implementation commitments & reporting 4. Interoperability testing plans & reporting 5. AgentX MIB** 6. Remaining process steps: - On-list call for consensus - Proposal to NMAD and IESG - WG future * - Meaningful participation in the issues resolution review will require that you have read the final AgentX protocol specification draft, as submitted to the IETF: A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/ draft-ietf-agentx-ext-pro-01.txt Also, I will post a list of the current perceived consensus positions for the "Questions and Issues" identified in Sec. 11 of the I-D over the weekend, if not earlier. ** - I believe the MIB document is very important and that Maria has done an *excellent* job under difficult circumstances (heavy workload, some career moves, and some significant changes to the protocol I-D since the first cut of the MIB document). However, it is an optional deliverable for the WG at this stage...so we will adjust the time allowed for this topic to ensure that we have time to cover the items in #6. Comments welcome. Cordially, BobN ------ ISO 9000 Registered, Hardware and Software Divsions ----- Bob Natale | ACE*COMM | 301-721-3000 [v] Dir, Net Mgmt Prod | 704 Quince Orchard Rd | 301-721-3001 [f] natale@acec.com | Gaithersburg MD 20878 | http://www.acec.com ----- WinSNMP DLL, SDK, Apps & Agents for Win16/32 & UNIX ------ ------- NetPlus (r) "FCAPS" Telemanagement Applications --------   Delivery-Date: Thu, 05 Dec 1996 11:08:36 -0800 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.5/8.7.3) id LAA01447 for X-agentx; Thu, 5 Dec 1996 11:08:35 -0800 (PST) Received: from gauntlet.fv.com (gauntlet.fv.com [207.67.199.118]) by fv.com (8.7.5/8.7.3) with ESMTP id LAA01444 for ; Thu, 5 Dec 1996 11:08:31 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.7.5/8.7.3) id OAA03020 for ; Thu, 5 Dec 1996 14:09:18 -0500 (EST) Received: from shekel.fv.com(207.67.199.130) by gauntlet.fv.com via smap (3.2) id xma003013; Thu, 5 Dec 96 11:08:50 -0800 Received: from gauntlet.fv.com (gauntlet-in.fv.com [10.0.0.2]) by shekel.fv.com (8.7.5/8.7.3) with ESMTP id LAA20489 for ; Thu, 5 Dec 1996 11:09:13 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.7.5/8.7.3) id OAA03004 for ; Thu, 5 Dec 1996 14:08:48 -0500 (EST) Received: from charity.harvard.net(206.137.222.16) by gauntlet.fv.com via smap (3.2) id xma002993; Thu, 5 Dec 96 11:08:24 -0800 Received: from xedia.com (madway.xedia.com [198.202.232.199]) by charity.harvard.net (8.8.3/8.7.3) with SMTP id OAA23398 for ; Thu, 5 Dec 1996 14:14:22 -0500 (EST) Received: from (espanola) by xedia.com (4.1/SMI-4.1) id AA06376; Thu, 5 Dec 96 14:02:51 EST Received: by (5.x/SMI-SVR4) id AA17227; Thu, 5 Dec 1996 14:07:09 -0500 Date: Thu, 5 Dec 1996 14:07:09 -0500 Message-Id: <9612051907.AA17227@> From: Maria Greene To: agentx@fv.com Subject: AgentX MIB update Hi, everyone. As Bob mentioned in his agenda, we will be discussing the AgentX MIB in San Jose if time allows. Here is an updated draft of that MIB (note: not yet posted as an official I-D). Looking forward to seeing everyone in San Jose, Maria - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Definitions of Managed Objects for Extensible SNMP Agents November 14, 1996 Maria Greene Ascom Nexion greene@nexen.com Dale Francisco (editor) Cisco Systems, Inc. dfrancis@cisco.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 draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as a "work in progress". To learn the current status of any Internet-Draft, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). Abstract 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 describes objects managing SNMP agents that use the Agent Extensibility (AgentX) Protocol. This memo specifies a MIB module in a manner that is both compliant to the SNMPv2 SMI, and semantically identical to the peer SNMPv1 definitions. This memo does not specify a standard for the Internet community. 1. The SNMP Network Management Framework The SNMP Network Management Framework presently consists of three major components. They are: o the SMI, described in RFC 1902 [1] - the mechanisms used for describing and naming objects for the purpose of management. o the MIB-II, STD 17, RFC 1213 [2] - the core set of managed objects for the Internet suite of protocols. o the protocol, RFC 1157 [3] and/or RFC 1905 [4], - the protocol for accessing managed objects. The Framework permits new objects to be defined for the purpose of experimentation and evaluation. 1.1. Object Definitions 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 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 also refer to the object type. 2. Introduction The SNMP Agent Extensibility Protocol (AgentX) is a protocol used to distribute the implementation of an SNMP agent amongst a single "master agent" and multiple "subagents". See [5] for details about the AgentX protocol. The AgentX MIB allows an SNMP manager to - List the set of subagents that currently have logical sessions open with the master agent. - Identify a subagent's type, vendor, transport address, AgentX protocol version, and other characteristics. - Identify the set of MIB objects each subagent implements, the context in which the objects are registered, and the priority of the registration. - Monitor AgentX protocol statistics, such as the number of packets transmitted to and received from a subagent. - Determine AgentX protocol operational parameters, such as the timeout interval for responses from a subagent and the priority at which a subagent registers a particular MIB region. - Modify AgentX protocol operational parameters and close subagent sessions with the master agent. 3. Definitions AGENTX-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, experimental, Counter32, BITS FROM SNMPv2-SMI MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF DisplayString, TimeStamp FROM SNMPv2-TC ; agentxMIB MODULE-IDENTITY LAST-UPDATED "9611151200Z" -- November 15, 1996 ORGANIZATION "IETF AgentX Working Group" CONTACT-INFO "Maria Greene greene@nexen.com Dale Francisco (Editor) dfrancis@cisco.com Bob Natale (WG Chair) natale@acec.com Send comments to the AgentX working group: agentx@fv.com." DESCRIPTION "The MIB module for the SNMP Agent Extensibility Protocol (AgentX). This MIB module will be implemented by the master agent." -- For testing purposes only. Need to get an experimental id -- ::= { experimental 2001 } ::= { experimental XX } agentxObjects OBJECT IDENTIFIER ::= { agentxMIB 1 } agentxGeneral OBJECT IDENTIFIER ::= { agentxObjects 1 } agentxDefaultTimeout OBJECT-TYPE SYNTAX INTEGER (0..255) UNITS "seconds" MAX-ACCESS read-write STATUS current DESCRIPTION "The default length of time, in seconds, that the master agent should allow to elapse after dispatching a message to a subagent before it regards the subagent as not responding. This is a system-wide value that may be overridden by the values associated with a particular subagent (agentxSATimeout) or with a particular registered MIB region (agentxRegTimeout)." DEFVAL { 5 } ::= { agentxGeneral 1 } agentxMasterAgentXVer OBJECT-TYPE SYNTAX INTEGER (1..255) MAX-ACCESS read-only STATUS current DESCRIPTION "The latest AgentX protocol version supported by this master agent. Initial version was 1. Note that the master agent must allow registration of earlier version subagents." DEFVAL { 1 } ::= { agentxGeneral 2 } agentxMasterSnmpVer OBJECT-TYPE -- For testing with a pre-v2c compiler -- SYNTAX BIT STRING { SYNTAX BITS { snmpv1(0), snmpv2c(1), snmpv2star(2), snmpv2u(3), other(4) } MAX-ACCESS read-only STATUS current DESCRIPTION "The SNMP protocol versions that this master agent supports." ::= { agentxGeneral 3 } agentxMasterTransports OBJECT-TYPE -- For testing with a pre-v2c compiler -- SYNTAX BIT STRING { SYNTAX BITS { unixDomainSockets(0), tcp(1), udp(2), sharedMem(3), other(4) } MAX-ACCESS read-only STATUS current DESCRIPTION "The transports that the master agent supports." DEFVAL { { unixDomainSockets } } ::= { agentxGeneral 4 } -- -- The AgentX Subagent Group -- agentxSubagent OBJECT IDENTIFIER ::= { agentxObjects 2 } agentxSATableLastChange OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime when the last row creation or deletion occurred in the agentxSubagentTable." ::= { agentxSubagent 1 } agentxSANumber OBJECT-TYPE SYNTAX INTEGER (0..65535) MAX-ACCESS read-only STATUS current DESCRIPTION "The current number of entries in the agentxSubagentTable. Note that this may be smaller than the largest value of agentxSAIndex since index values are not reused when entries come and go from the agentxSubagentTable." ::= { agentxSubagent 2 } -- -- The AgentX Subagent Table -- agentxSubagentTable OBJECT-TYPE SYNTAX SEQUENCE OF AgentxSubagentEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of AgentX subagents that have open sessions with the AgentX master agent." ::= { agentxSubagent 3 } agentxSubagentEntry OBJECT-TYPE SYNTAX AgentxSubagentEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information about a single subagent that has an open session with the AgentX master agent." INDEX { agentxSAIndex } ::= { agentxSubagentTable 1 } AgentxSubagentEntry ::= SEQUENCE { agentxSAIndex INTEGER, agentxSAObjectID OBJECT IDENTIFIER, agentxSADescr DisplayString, agentxSAAdminStatus INTEGER, agentxSAOpenTime TimeStamp, agentxSAAgentXVer INTEGER, agentxSATimeout INTEGER, agentxSAMsgsIn Counter32, agentxSAMsgsOut Counter32, agentxSATransportType INTEGER, agentxSATransportAddr OCTET STRING } agentxSAIndex OBJECT-TYPE SYNTAX INTEGER (1..65535) MAX-ACCESS not-accessible STATUS current DESCRIPTION "A small-integer index for the subagent's session, guaranteed to be unique between re-initializations of the master agent. Note that if a subagent's session with the master agent is closed for any reason its index will not be reused (between master agent re-initializations). Therefore, the values of agentxSAIndex need not be contiguous, nor will they be the same for the same subagent across multiple sessions." ::= { agentxSubagentEntry 1 } agentxSATimeout OBJECT-TYPE SYNTAX INTEGER (0..255) MAX-ACCESS read-write STATUS current DESCRIPTION "The length of time, in seconds, that a master agent should allow to elapse after dispatching a message to this subagent before it regards the subagent as not responding. This value is taken from the o.timeout field of the agentx-Open-PDU. This is a subagent-wide value that may be overridden by values associated with specific registered MIB regions (see agentxRegTimeout). The default value of '0' indicates that the master agent's default timeout value should be used (see agentxDefaultTimeout). Note that when a new value is written to this object, the new value will be used in all subsequent agentx-Open-PDUs the subagent sends. Thus, if a network operator wishes to change the master agent's idea of a particular subagent's timeout, she must set this value, then set agentxSAAdminStatus to 'down(2)', which will close the subagent, after which it will automatically attempt to re-open a session with the new timeout value." DEFVAL { 0 } ::= { agentxSubagentEntry 2 } agentxSAObjectID OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-only STATUS current DESCRIPTION "The type identification for the subagent. This is analogous to 'sysObjectID' as defined in MIB-2 [2], and is taken from the o.id field of the agentx-Open-PDU." ::= { agentxSubagentEntry 3 } agentxSADescr OBJECT-TYPE SYNTAX DisplayString MAX-ACCESS read-only STATUS current DESCRIPTION "A textual description of the subagent. This is analogous to 'sysDescr' as defined in MIB-2 [2], and is taken from the o.descr field of the agentx-Open-PDU." ::= { agentxSubagentEntry 4 } agentxSAAdminStatus OBJECT-TYPE SYNTAX INTEGER { up(1), down(2) } MAX-ACCESS read-write STATUS current DESCRIPTION "The administrative (desired) status of the subagent. Setting the value to 'down(2)' closes the subagent (with c.reason set to 'reasonByManager'). When read, the value returned is always 'up(1)'. When a subagent is closed it will automatically try to re-open its session with the master agent." DEFVAL { up } ::= { agentxSubagentEntry 5 } agentxSAOpenTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime when this session was opened. By convention, this is also the value of sysUpTime when this entry was added to the table." ::= { agentxSubagentEntry 6 } agentxSAAgentXVer OBJECT-TYPE SYNTAX INTEGER (1..256) MAX-ACCESS read-only STATUS current DESCRIPTION "The version of the AgentX protocol supported by the subagent. This will be less than or equal to the value of agentxMasterAgentXVer." DEFVAL { 1 } ::= { agentxSubagentEntry 7 } agentxSAMsgsIn OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of AgentX protocol messages (administrative and SNMP protocol related) received by this subagent from the master agent." ::= { agentxSubagentEntry 8 } agentxSAMsgsOut OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of AgentX protocol messages (administrative and SNMP protocol related) sent by this subagent to the master agent." ::= { agentxSubagentEntry 9 } agentxSATransportType OBJECT-TYPE SYNTAX INTEGER { unixDomainSockets(1), tcp(2), udp(3), sharedMem(4), other(5) } MAX-ACCESS read-only STATUS current DESCRIPTION "The transport used for AgentX protocol messages between this subagent and the master agent." ::= { agentxSubagentEntry 10 } agentxSATransportAddr OBJECT-TYPE SYNTAX OCTET STRING MAX-ACCESS read-only STATUS current DESCRIPTION "The 'address' of the session this subagent has open with the master agent. Interpretation of this value depends on the value of agentxSATransportType. Note that a subagent may have multiple valid addresses in use at the same time, in which case this object contains one of those addresses, selected in an implementation-specific manner." ::= { agentxSubagentEntry 11 } -- -- The AgentX Registration Table -- agentxRegistrationTable OBJECT-TYPE SYNTAX SEQUENCE OF AgentxRegistrationEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of registered OBJECT IDENTIFIER regions. This is the table used to dispatch AgentX PDUs to the appropriate subagent based on the requested OIDs in the SNMP messages. Note that a subagent registration may be broken up into multiple entries in this table, as described in the AgentX Protocol specification [5]." ::= { agentxObjects 3 } agentxRegistrationEntry OBJECT-TYPE SYNTAX AgentxRegistrationEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A single registered region. Regions are added by the master agent when subagents register and are removed from the table when the subagents unregister the region or their sessions are closed. Note that the combination of agentxRegContext, agentxRegStart and agentxRegDispatchOrder will be unique and could have been used for indexing purposes. It is recommended that the agent sort this table by those values." INDEX { agentxRegIndex } ::= { agentxRegistrationTable 1 } AgentxRegistrationEntry ::= SEQUENCE { agentxRegIndex INTEGER, agentxRegContext OCTET STRING, agentxRegStart OBJECT IDENTIFIER, agentxRegEnd OBJECT IDENTIFIER, agentxRegDispatchOrder INTEGER, agentxRegPriority INTEGER, agentxRegSAIndex INTEGER, agentxRegTimeout INTEGER } agentxRegIndex OBJECT-TYPE SYNTAX INTEGER (1..65535) MAX-ACCESS not-accessible STATUS current DESCRIPTION "An integer that uniquely identifies a registration entry." ::= { agentxRegistrationEntry 1 } agentxRegContext OBJECT-TYPE SYNTAX OCTET STRING (SIZE (0..256)) MAX-ACCESS read-only STATUS current DESCRIPTION "The context in which the subagent supports the objects in this region. A zero-length context indicates the default context." ::= { agentxRegistrationEntry 2 } agentxRegStart OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-only STATUS current DESCRIPTION "The starting OBJECT IDENTIFIER of this registration entry. The subagent identified by agentxRegSAIndex implements objects starting at this value (inclusive). Note that this value could identify an object type, an object instance, or a partial object instance identifier." ::= { agentxRegistrationEntry 3 } agentxRegEnd OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-only STATUS current DESCRIPTION "The ending OBJECT IDENTIFIER of this registration entry. The subagent identified by agentxRegSAIndex implements objects up to but not including this value. Note that this value could identify an object type, an object instance, or a partial object instance identifier." ::= { agentxRegistrationEntry 4 } agentxRegDispatchOrder OBJECT-TYPE SYNTAX INTEGER (0..256) MAX-ACCESS read-only STATUS current DESCRIPTION "An indication of this range's order or precedence for dispatching purposes. This value will normally be 0, indicating that there is no duplicate OID registration for this range. If the value is anything other than 0, then there is duplicate registration, and the entry with the lowest value of agentxRegDispatchOrder will be the first selected for dispatch." REFERENCE "Agent Extensibility (AgentX) Protocol Version 1 [5], section 7.1.4.1 Handling Duplicate OID Ranges." DEFVAL { 0 } ::= { agentxRegistrationEntry 5 } agentxRegPriority OBJECT-TYPE SYNTAX INTEGER (1..255) MAX-ACCESS read-write STATUS current DESCRIPTION "The subagent's priority when exporting this OID range. Lower values represent higher priority. Note that when a new value is written to this object, this new value will be used for all subsequent agentx-Register-PDUs the subagent sends for this region. Thus, if a network operator wishes to change the master agent's idea of a particular subagent's priority, she must set this value, then set the corresponding agentxSAAdminStatus (as indicated by agentxRegSAIndex) to 'down(2)', which will close the subagent, after which the subagent will automatically attempt to re-open a session with the new priority value." DEFVAL { 255 } ::= { agentxRegistrationEntry 6 } agentxRegSAIndex OBJECT-TYPE SYNTAX INTEGER (1..65535) MAX-ACCESS read-only STATUS current DESCRIPTION "The value of agentxSAIndex for the subagent that registered this OID range." ::= { agentxRegistrationEntry 7 } agentxRegTimeout OBJECT-TYPE SYNTAX INTEGER (0..255) MAX-ACCESS read-write STATUS current DESCRIPTION "The timeout value, in seconds, for subagent responses to requests associated with this OID range. The value '0' indicates that default value (indicated by agentxSATimeout or agentxDefaultTimeout) is to be used. This value is taken from the r.timeout field of the agentx-Register-PDU. Note that, if the agent supports writing of this object the new value will be used for subsequent agentx-Register-PDUs the subagent sends for this region. In other words, if the manager wishes to change the value operationally, she must set this value then set the corresponding agentxSAAdminStatus to 'down(2)' (as indicated by agentxRegSAIndex), which will close the subagent, after which is will automatically re-open the session and re-register its OID ranges with the new timeout value." DEFVAL { 0 } ::= { agentxRegistrationEntry 8 } -- -- The AgentX Statistics Group -- -- The statistics in this group are maintained by the Master Agent -- and therefore, "In" indicates messages from the subagents and -- "Out"refers to messages sent to the subagents. -- agentxStats OBJECT IDENTIFIER ::= { agentxObjects 4 } agentxInNonAdminMsgs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Non-administrative messages are AgentX protocol messages such as agentx-Get-PDU, agentx-TestSet-PDU, and agentx-CommitSet-PDU; messages that are sent during processing of received SNMP protocol messages. This counter is the total number of all such AgentX messages received by the master agent from the subagents." ::= { agentxStats 1 } agentxOutNonAdminMsgs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Non-administrative messages are AgentX protocol messages such as agentx-Get-PDU, agentx-TestSet-PDU, and agentx-CommitSet-PDU; messages that are sent during processing of received SNMP protocol messages. This counter is the total number of all such AgentX messages sent by the master agent to the subagents." ::= { agentxStats 2 } agentxInOpen OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of agentx-Open-PDU messages received by the master agent." ::= { agentxStats 3 } agentxOutAlreadyOpen OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of responses sent to agentx-Open-PDU messages where the res.error field was set to 'alreadyOpen'." ::= { agentxStats 4 } agentxOutOpenFailed OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of responses sent to agentx-Open-PDU messages where the res.error field was set to 'openFailed'." ::= { agentxStats 5 } agentxInCloseOther OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of agentx-Close-PDU messages received by the master agent where the c.reason field was 'reasonOther'." ::= { agentxStats 6 } agentxInCloseProtoErr OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of agentx-Close-PDU messages received by the master agent where the c.reason field was 'reasonProtocolError'." ::= { agentxStats 7 } agentxInCloseTimeouts OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of agentx-Close-PDU messages received by the master agent where the c.reason field was 'reasonTimeouts'." ::= { agentxStats 8 } agentxInCloseShutdown OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of agentx-Close-PDU messages received by the master agent where the c.reason field was 'reasonShutdown'." ::= { agentxStats 9 } agentxInCloseByManager OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of agentx-Close-PDU messages received by the master agent where the c.reason field was 'reasonByManager'." ::= { agentxStats 10 } agentxOutCloseNotOpen OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of agentx-Response-PDU messages sent by the master agent in response to agentx-Close-PDU messages where the res.error field was set to 'notOpen'." ::= { agentxStats 11 } agentxOutCloseOther OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of agentx-Close-PDU messages sent by the master agent where the c.reason field was 'reasonOther'." ::= { agentxStats 12 } agentxOutCloseProtoErr OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of agentx-Close-PDU messages sent by the master agent where the c.reason field was 'reasonProtocolError'." ::= { agentxStats 13 } agentxOutCloseTimeouts OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of agentx-Close-PDU messages sent by the master agent where the c.reason field was 'reasonTimeouts'." ::= { agentxStats 14 } agentxOutCloseShutdown OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of agentx-Close-PDU messages sent by the master agent where the c.reason field was 'reasonShutdown'." ::= { agentxStats 15 } agentxOutCloseByManager OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of agentx-Close-PDU messages sent by the master agent where the c.reason feld was 'reasonByManager'." ::= { agentxStats 16 } agentxInCloseNotOpen OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of agentx-Response-PDU messages received by the master agent in response to agentx-Close-PDU messages it sent where the res.error field was set to 'notOpen'." ::= { agentxStats 17 } agentxInRegister OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of agentx-Register-PDU messages received by the master agent." ::= { agentxStats 18 } agentxOutRegisterNotOpen OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of agentx-Response-PDU messages sent by the master agent in response to incoming agentx-Register-PDU messages where the res.error field was set to 'notOpen'." ::= { agentxStats 19 } agentxOutRegisterUnsupportedContext OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of agentx-Response-PDU messages sent by the master agent in response to incoming agentx-Register-PDU messages where the res.error field was set to 'unsupportedContext'." ::= { agentxStats 20 } agentxOutRegisterDuplicate OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of agentx-Response-PDU messages sent by the master agent in response to incoming agentx-Register-PDU messages where the res.error field was set to 'duplicateRegistration'." ::= { agentxStats 21 } agentxInUnregister OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of agentx-Unregister-PDU messages received by the master agent." ::= { agentxStats 22 } agentxOutUnregisterNotOpen OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of agentx-Response-PDU messages sent by the master agent in response to incoming agentx-Unregister-PDU messages where the res.error field was set to 'notOpen'." ::= { agentxStats 23 } agentxOutUnregisterUnknown OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of agentx-Response-PDU messages sent by the master agent in response to incoming agentx-Unregister-PDU messages where the res.error field was set to 'unknownRegistration'." ::= { agentxStats 24 } agentxInNotify OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of agentx-Notify-PDU messages received by the master agent." ::= { agentxStats 25 } agentxOutNotifyNotOpen OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of agentx-Response-PDU messages sent by the master agent in response to incoming agentx-Notify-PDU messages where the res.error field was set to 'notOpen'." ::= { agentxStats 26 } agentxInPing OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of agentx-Ping-PDU messages received by the master agent." ::= { agentxStats 27 } agentxOutPingNotOpen OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of agentx-Response-PDU messages sent by the master agent in response to incoming agentx-Ping-PDU messages where the res.error field was set to 'notOpen'." ::= { agentxStats 28 } agentxInIndexRes OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of agentx-IndexReserve-PDU messages received by the master agent." ::= { agentxStats 29 } agentxOutIndexResNotOpen OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of agentx-Response-PDU messages sent by the master agent in response to incoming agentx-IndexReserve-PDU messages where the res.error field was set to 'notOpen'." ::= { agentxStats 30 } agentxOutIndexResUnsupportedType OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of agentx-Response-PDU messages sent by the master agent in response to incoming agentx-IndexReserve-PDU messages where the res.error field was set to 'indexUnsupportedType'." ::= { agentxStats 31 } agentxOutIndexResWrongType OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of agentx-Response-PDU messages sent by the master agent in response to incoming agentx-IndexReserve-PDU messages where the res.error field was set to 'indexWrongType'." ::= { agentxStats 32 } agentxOutIndexResAlreadyRes OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of agentx-Response-PDU messages sent by the master agent in response to incoming agentx-IndexReserve-PDU messages where the res.error field was set to 'indexAlreadyReserved'." ::= { agentxStats 33 } agentxOutIndexResNoneAvail OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of agentx-Response-PDU messages sent by the master agent in response to incoming agentx-IndexReserve-PDU messages where the res.error field was set to 'indexNoneAvailable'." ::= { agentxStats 34 } agentxInIndexUnres OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of agentx-IndexUnreserve-PDU messages received by the master agent." ::= { agentxStats 35 } agentxOutIndexUnresNotOpen OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of agentx-Response-PDU messages sent by the master agent in response to incoming agentx-IndexUnreserve-PDU messages where the res.error field was set to 'notOpen'." ::= { agentxStats 36 } agentxOutIndexUnresNotReserved OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of agentx-Response-PDU messages sent by the master agent in response to incoming agentx-IndexUnreserve-PDU messages where the res.error field was set to 'indexNotCurrentlyReserved'." ::= { agentxStats 37 } agentxInAddAgentCaps OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of agentx-AddAgentCaps-PDU messages received by the master agent." ::= { agentxStats 38 } agentxOutAddAgentCapsNotOpen OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of agentx-Response-PDU messages sent by the master agent in response to incoming agentx-AddAgentCaps-PDU messages where the res.error field was set to 'notOpen'." ::= { agentxStats 39 } agentxOutAddAgentCapsUnsupportedContext OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of agentx-Response-PDU messages sent by the master agent in response to incoming agentx-AddAgentCaps-PDU messages where the res.error field was set to 'unsupportedContext'." ::= { agentxStats 40 } agentxInRemoveAgentCaps OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of agentx-RemoveAgentCaps-PDU messages received by the master agent." ::= { agentxStats 41 } agentxOutRemoveAgentCapsNotOpen OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of agentx-Response-PDU messages sent by the master agent in response to incoming agentx-RemoveAgentCaps-PDU messages where the res.error field was set to 'notOpen'." ::= { agentxStats 42 } agentxOutRemoveAgentCapsUnknown OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of agentx-Response-PDU messages sent by the master agent in response to incoming agentx-RemoveAgentCaps-PDU messages where the res.error field was set to 'unknownAgentCaps'." ::= { agentxStats 43 } -- -- Conformance Statements for the AgentX MIB -- agentxConformance OBJECT IDENTIFIER ::= { agentxMIB 2 } agentxMIBGroups OBJECT IDENTIFIER ::= { agentxConformance 1 } agentxMIBCompliances OBJECT IDENTIFIER ::= { agentxConformance 2 } agentxMIBCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for SNMP entities that implement the AgentX protocol. Note that a compliant agent can implement all objects in this MIB module as read-only." MODULE -- this module MANDATORY-GROUPS { agentxMIBGroup } OBJECT agentxDefaultTimeout MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT agentxSATimeout MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT agentxSAAdminStatus MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT agentxRegPriority MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT agentxRegTimeout MIN-ACCESS read-only DESCRIPTION "Write access is not required." ::= { agentxMIBCompliances 1 } agentxMIBGroup OBJECT-GROUP OBJECTS { agentxDefaultTimeout, agentxMasterAgentXVer, agentxMasterSnmpVer, agentxMasterTransports, agentxSATableLastChange, agentxSANumber, agentxSATimeout, agentxSAObjectID, agentxSADescr, agentxSAAdminStatus, agentxSAOpenTime, agentxSAAgentXVer, agentxSAMsgsIn, agentxSAMsgsOut, agentxSATransportType, agentxSATransportAddr, agentxRegContext, agentxRegStart, agentxRegEnd, agentxRegDispatchOrder, agentxRegPriority, agentxRegSAIndex, agentxRegTimeout, agentxInNonAdminMsgs, agentxOutNonAdminMsgs, agentxInOpen, agentxOutAlreadyOpen, agentxOutOpenFailed, agentxInCloseOther, agentxInCloseProtoErr, agentxInCloseTimeouts, agentxInCloseShutdown, agentxInCloseByManager, agentxOutCloseNotOpen, agentxOutCloseOther, agentxOutCloseProtoErr, agentxOutCloseTimeouts, agentxOutCloseShutdown, agentxOutCloseByManager, agentxInCloseNotOpen, agentxInRegister, agentxOutRegisterNotOpen, agentxOutRegisterUnsupportedContext, agentxOutRegisterDuplicate, agentxInUnregister, agentxOutUnregisterNotOpen, agentxOutUnregisterUnknown, agentxInNotify, agentxOutNotifyNotOpen, agentxInPing, agentxOutPingNotOpen, agentxInIndexRes, agentxOutIndexResNotOpen, agentxOutIndexResUnsupportedType, agentxOutIndexResWrongType, agentxOutIndexResAlreadyRes, agentxOutIndexResNoneAvail, agentxInIndexUnres, agentxOutIndexUnresNotOpen, agentxOutIndexUnresNotReserved, agentxInAddAgentCaps, agentxOutAddAgentCapsNotOpen, agentxOutAddAgentCapsUnsupportedContext, agentxInRemoveAgentCaps, agentxOutRemoveAgentCapsNotOpen, agentxOutRemoveAgentCapsUnknown } STATUS current DESCRIPTION "All accessible objects in the AgentX MIB." ::= { agentxMIBGroups 1 } END 4. Acknowledgments This document is a product of the IETF's AgentX Working Group. This MIB is an evolution of the Subagent MIB by Bert Wijnen (wijnen@vnet.ibm.com) which in turn was derived from the SMUX-MIB by Marshall Rose [6]. 5. References [1] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Structure of Management Information for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC1902, SNMP Research,Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., International Network Services, January 1996. [2] McCloghrie, K., and M. Rose, Editors, "Management Information Base for Network Management of TCP/IP-based internets: MIB-II", STD 17, RFC 1213, Hughes LAN Systems, Performance Systems International, March 1991. [3] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network Management Protocol", RFC 1157, SNMP Research, Performance Systems International, Performance Systems International, MIT Laboratory for Computer Science, May 1990. [4] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Protocol Operations for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC1905, SNMP Research,Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., International Network Services, January 1996. [5] Daniele, M., Wijnen, B., Francisco, D., "Agent Extensibility (AgentX) Protocol, Version 1", draft-ietf-agentx-ext-pro-01.txt, Digital Equipment Corporation, T.J. Watson Research Center, IBM Corp., Cisco Systems, November, 1996. [6] Rose, M., "SNMP MUX Protocol and MIB", RFC1227, Performance Systems International, Inc., May 1991. [7] Wijnen, B., Carpenter, G., Curran, K., Sehgal, A., and G. Waters, "Simple Network Management Protocol: Distributed Protocol Interface, Version 2.0", RFC 1592, T.J. Watson Research Center, IBM Corp., Bell Northern Research, Ltd., March 1994. 6. Security Considerations Security issues are not discussed in this memo. 7. Author's and Editor's Address Maria Greene Ascom Nexion 289 Great Road Acton, MA 01720 Phone: (508) 266-4570 EMail: greene@nexen.com Dale Francisco (editor) Cisco Systems 150 Castilian Dr. Goleta, CA 93117 Phone: (805) 961-3642 EMail: dfrancis@cisco.com Table of Contents 1 The SNMP Network Management Framework ...................... 2 1.1 Object Definitions ....................................... 2 2 Introduction ............................................... 3 3 Definitions ................................................ 4 4 Acknowledgments ............................................ 25 5 References ................................................. 26 6 Security Considerations .................................... 27 7 Author's and Editor's Address .............................. 27   Delivery-Date: Thu, 05 Dec 1996 17:51:49 -0800 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.5/8.7.3) id RAA07727 for X-agentx; Thu, 5 Dec 1996 17:51:49 -0800 (PST) Received: from gauntlet.fv.com (gauntlet.fv.com [207.67.199.118]) by fv.com (8.7.5/8.7.3) with ESMTP id RAA07724 for ; Thu, 5 Dec 1996 17:51:49 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.7.5/8.7.3) id UAA27696 for ; Thu, 5 Dec 1996 20:52:34 -0500 (EST) Received: from shekel.fv.com(207.67.199.130) by gauntlet.fv.com via smap (3.2) id xma027694; Thu, 5 Dec 96 17:52:05 -0800 Received: from gauntlet.fv.com (gauntlet-in.fv.com [10.0.0.2]) by shekel.fv.com (8.7.5/8.7.3) with ESMTP id RAA20516 for ; Thu, 5 Dec 1996 17:52:28 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.7.5/8.7.3) id UAA27691 for ; Thu, 5 Dec 1996 20:52:04 -0500 (EST) Received: from bort.mv.net(192.80.84.6) by gauntlet.fv.com via smap (3.2) id xma027670; Thu, 5 Dec 96 17:51:56 -0800 Received: from keeney (dek.bluefin.net [205.162.68.223]) by bort.mv.net (8.8.3/mem-951016) with SMTP id UAA14146 for ; Thu, 5 Dec 1996 20:50:55 -0500 (EST) Message-Id: <2.2.32.19961206015037.00951414@pop-cnh.mv.net> X-Sender: keeney-ke@pop-cnh.mv.net X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 05 Dec 1996 20:50:37 -0500 To: agentx@fv.com From: David Keeney Subject: Agentx Web page The latest Agentx MIB and Working document have been posted on the Agentx Web page "http://www.scguild.com/agentx" The agenda for the upcoming San Jose meeting is also posted. David Keeney ================================================================ David E Keeney, Contract Software Engineer, keeney@mv.mv.com Software Contractors' Guild http://www.scguild.com/ Box 257 Nottingham NH, 03290   Delivery-Date: Fri, 06 Dec 1996 17:56:49 -0800 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.5/8.7.3) id RAA01324 for X-agentx; Fri, 6 Dec 1996 17:56:49 -0800 (PST) Received: from gauntlet.fv.com (gauntlet.fv.com [207.67.199.118]) by fv.com (8.7.5/8.7.3) with ESMTP id RAA01321 for ; Fri, 6 Dec 1996 17:56:44 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.7.5/8.7.3) id UAA27058 for ; Fri, 6 Dec 1996 20:57:28 -0500 (EST) Received: from shekel.fv.com(207.67.199.130) by gauntlet.fv.com via smap (3.2) id xma027046; Fri, 6 Dec 96 17:56:58 -0800 Received: from gauntlet.fv.com (gauntlet-in.fv.com [10.0.0.2]) by shekel.fv.com (8.7.5/8.7.3) with ESMTP id RAA01198 for ; Fri, 6 Dec 1996 17:57:23 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.7.5/8.7.3) id UAA27043 for ; Fri, 6 Dec 1996 20:56:57 -0500 (EST) Received: from unknown(198.64.253.250) by gauntlet.fv.com via smap (3.2) id xma026995; Fri, 6 Dec 96 17:56:43 -0800 Received: by dresden.bmc.com (1.40.112.4/16.2) id AA014784111; Fri, 6 Dec 1996 20:01:51 -0600 Received: from crow.bmc.com(198.147.191.100) by dresden.bmc.com via smap (3.2) id xma001420; Fri, 6 Dec 96 20:01:44 -0600 Received: from dorothy.peer.com by crow.bmc.com (AIX 3.2/UCB 5.64/4.03) id AA14525; Fri, 6 Dec 1996 19:49:53 -0600 Received: by dorothy.peer.com (1.39.111.2/16.2) id AA272443657; Fri, 6 Dec 1996 17:54:17 -0800 Date: Fri, 6 Dec 1996 17:54:17 -0800 From: Muriel Appelbaum Message-Id: <199612070154.AA272443657@dorothy.peer.com> To: agentx@fv.com Subject: CommitSet failure Cc: tech@peer.com Mime-Version: 1.0 Content-Type: text/plain; charset=X-roman8 Content-Transfer-Encoding: 7bit The explanation of the master agent "Processing of Responses to agentx-CommitSet-PDUs" and "Processing of Responses to agentx-UndoSet-PDUs", sections 7.2.4.5 and 7.2.4.6, is not clear in the situation when the CommitSet fails but the UndoSet responses are all "noError." The text seems to suggest that the SNMP response would be "noError", reflecting the success of the UndoSet, rather than "commitFailed", reflecting the failure of the CommitSet processing. Muriel ----------------------------------------------------------------------- Muriel Appelbaum BMC Software, Inc. (Silicon Valley Division) Voice: +1 408 556-0720 (Formerly PEER Networks) http://www.bmc.com Fax: +1 408 556-0735 1190 Saratoga Avenue, Suite 130 Email: mappelba@bmc.com San Jose, California 95129-3433 USA -----------------------------------------------------------------------   Delivery-Date: Tue, 10 Dec 1996 12:45:46 -0800 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.5/8.7.3) id MAA08736 for X-agentx; Tue, 10 Dec 1996 12:45:45 -0800 (PST) Received: from gauntlet.fv.com (gauntlet.fv.com [207.67.199.118]) by fv.com (8.7.5/8.7.3) with ESMTP id MAA08733 for ; Tue, 10 Dec 1996 12:45:36 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.7.5/8.7.3) id PAA25711 for ; Tue, 10 Dec 1996 15:46:11 -0500 (EST) Received: from shekel.fv.com(207.67.199.130) by gauntlet.fv.com via smap (3.2) id xma025704; Tue, 10 Dec 96 12:45:47 -0800 Received: from gauntlet.fv.com (gauntlet-in.fv.com [10.0.0.2]) by shekel.fv.com (8.7.5/8.7.3) with ESMTP id MAA17479 for ; Tue, 10 Dec 1996 12:46:17 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.7.5/8.7.3) id PAA25698 for ; Tue, 10 Dec 1996 15:45:41 -0500 (EST) Received: from dresden.bmc.com(198.64.253.250) by gauntlet.fv.com via smap (3.2) id xma025694; Tue, 10 Dec 96 12:45:29 -0800 Received: by dresden.bmc.com (1.40.112.4/16.2) id AA152721103; Tue, 10 Dec 1996 14:51:43 -0600 Received: from crow.bmc.com(198.147.191.100) by dresden.bmc.com via smap (3.2) id xma015223; Tue, 10 Dec 96 14:51:34 -0600 Received: from dorothy.peer.com by crow.bmc.com (AIX 3.2/UCB 5.64/4.03) id AA21919; Tue, 10 Dec 1996 14:38:49 -0600 Received: by dorothy.peer.com (1.39.111.2/16.2) id AA104090592; Tue, 10 Dec 1996 12:43:12 -0800 From: Smitha Gudur Message-Id: <199612102043.AA104090592@dorothy.peer.com> Subject: TBD issues - port number To: agentx@fv.com Date: Tue, 10 Dec 1996 12:43:12 PST Cc: tech@peer.com X-Mailer: Elm [revision: 111.1] This is in reference to section 8.1.1 well known port is still TBD. This and any other "TBD" issues should be included in the issue list of section 11.1 of the draft. Smitha ----------------------------------------------------------------------- Smitha Gudur BMC Software, Inc. (Silicon Valley Division) Voice: +1 408 556-0720 (Formerly PEER Networks) http://www.bmc.com Fax: +1 408 556-0735 1190 Saratoga Avenue, Suite 130 Email: sgudur@bmc.com San Jose, California 95129-3433 USA -----------------------------------------------------------------------   Delivery-Date: Sun, 15 Dec 1996 23:21:08 -0800 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.5/8.7.3) id XAA00197 for X-agentx; Sun, 15 Dec 1996 23:21:07 -0800 (PST) Received: from gauntlet.fv.com (gauntlet.fv.com [207.67.199.118]) by fv.com (8.7.5/8.7.3) with ESMTP id XAA00184 for ; Sun, 15 Dec 1996 23:21:06 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.7.5/8.7.3) id CAA00533 for ; Mon, 16 Dec 1996 02:21:27 -0500 (EST) Received: from shekel.fv.com(207.67.199.130) by gauntlet.fv.com via smap (3.2) id xma000523; Sun, 15 Dec 96 23:20:58 -0800 Received: from gauntlet.fv.com (gauntlet-in.fv.com [10.0.0.2]) by shekel.fv.com (8.7.5/8.7.3) with ESMTP id XAA29075 for ; Sun, 15 Dec 1996 23:21:32 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.7.5/8.7.3) id CAA00499 for ; Mon, 16 Dec 1996 02:20:55 -0500 (EST) Received: from bubbuh.cisco.com(198.92.30.35) by gauntlet.fv.com via smap (3.2) id xma000488; Sun, 15 Dec 96 23:20:33 -0800 Received: from manatee.cisco.com (manatee.cisco.com [171.69.131.101]) by bubbuh.cisco.com (8.7.6/CISCO.GATE.1.1) with SMTP id XAA00547 for ; Sun, 15 Dec 1996 23:20:08 -0800 (PST) Message-ID: <32B4F5E1.71B2@cisco.com> Date: Sun, 15 Dec 1996 23:10:25 -0800 From: "Jeffrey T. Johnson" Organization: cisco Systems, Inc. X-Mailer: Mozilla 3.0 (Win95; I) MIME-Version: 1.0 To: agentx@fv.com Subject: Unionized Registration Requirement Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Although the current draft allows a subagent to register non-qualified = support for a table (i.e. without any instance information), in reality = such registrations will be useless. Consider two subagents that both = want to register for the tcpConnTable under the default context. Under = the current draft, only one of the registrations will be visible, either = because it has a higher priority or because it was the first to = register. Hence, in reality only partially or fully qualified instances = can be registered. The current draft provides several examples of a = subagent registering partially or fully qualified table instances. The = section on index allocation describes how a subagent might register = support for ifTable.[1-22].i, ipNetToMediaTable.[1-4].i, or = tcpConnTable.[1-5].a.b.c.d (as a side note, "Table" should actually be = "Entry" in the examples). Unfortunately, even the above examples can cause a lot of overhead for = both the master agent and subagent. Consider a subagent on a Network = Interface Card containing 128 interfaces. For each of the individual = interfaces a separate registration will be required. This is a lot of = agentx administrative traffic at subagent startup time, and doesn=92t eve= n = include the 128 individual index allocation messages. (I=92ll note that = if all 128 instances are contiguous, then a really smart subagent could = get away with 22 registrations of ifEntry.x.[y-z] where x is the OID of = the table objects, and y-z is the range of ifIndex values). But I admit = that although this is inconvenient, it is not a show stopper. One thing that the three examples above have in common is that the = qualified portion of the instance information is (relatively) static. = For the ifTable and ifNetToMediaTable, once assigned, the ifIndex values = don=92t change. Likewise, for the tcpConnTable, the tcpConnLocalAddress = is rarely changed on a subagent. Unfortunately, there are tables which = might be useful in a subagent environment for which no portion of the = instance information is static. Consider the MIB-II ipRouteTable, which = is indexed by ipRouteDest. This index value is not arbitrary and is not = specific to a subagent. With the current registration scheme, since two = routing subagents cannot both register for "ipRouteTable", they must = register ipRouteEntry.1-13.a.b.c.d for every ip route, and must = constantly register and deregister individual instances as the routing = tables change. On Internet connected devices, this can result in tens = of thousands of entries registered with the master agent, with multiple = changes every second, resulting in more administrative traffic than pdu = traffic between master agent and subagent. This would seem to indicate = that the decision to not support non-unionized registrations might not = be optimal. OK, one could argue that although the lack of non-unionized = registrations may lead to extremely large dispatch tables in the master = agent as well as an undesirable ratio of administrative to pdu traffic = between master and subagent, that the scheme will still work. And I = would concur that while what I have addressed so far are problematic, = they are not fatal. So here is the show stopper. Without unionized = registrations, there is no way to support row creation in arbitrarily = indexed tables. Consider the RMON-MIB. If an application wants to create a history = study, it does so by creating a row in the historyControlTable. This = table is indexed by historyControlIndex, an arbitrary index. Since the = index is arbitrary, a subagent cannot register for it beforehand. The = only way that the historyControlTable (or any other RMON control table) = can be supported is if unionized registration is allowed. /jeff   Delivery-Date: Sun, 15 Dec 1996 23:21:08 -0800 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.5/8.7.3) id XAA00203 for X-agentx; Sun, 15 Dec 1996 23:21:07 -0800 (PST) Received: from gauntlet.fv.com (gauntlet.fv.com [207.67.199.118]) by fv.com (8.7.5/8.7.3) with ESMTP id XAA00187 for ; Sun, 15 Dec 1996 23:21:06 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.7.5/8.7.3) id CAA00539 for ; Mon, 16 Dec 1996 02:21:28 -0500 (EST) Received: from shekel.fv.com(207.67.199.130) by gauntlet.fv.com via smap (3.2) id xma000520; Sun, 15 Dec 96 23:20:58 -0800 Received: from gauntlet.fv.com (gauntlet-in.fv.com [10.0.0.2]) by shekel.fv.com (8.7.5/8.7.3) with ESMTP id XAA29072 for ; Sun, 15 Dec 1996 23:21:32 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.7.5/8.7.3) id CAA00497 for ; Mon, 16 Dec 1996 02:20:55 -0500 (EST) Received: from bubbuh.cisco.com(198.92.30.35) by gauntlet.fv.com via smap (3.2) id xma000490; Sun, 15 Dec 96 23:20:37 -0800 Received: from manatee.cisco.com (manatee.cisco.com [171.69.131.101]) by bubbuh.cisco.com (8.7.6/CISCO.GATE.1.1) with SMTP id XAA00555 for ; Sun, 15 Dec 1996 23:20:12 -0800 (PST) Message-ID: <32B4F5EB.44EE@cisco.com> Date: Sun, 15 Dec 1996 23:10:35 -0800 From: "Jeffrey T. Johnson" Organization: cisco Systems, Inc. X-Mailer: Mozilla 3.0 (Win95; I) MIME-Version: 1.0 To: agentx@fv.com Subject: Directed Traps Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable The agentx-Notify-PDU allows a subagent to specify a context and a = variable binding list that is to be used for trap generation. = Unfortunately, for some forms of directed traps, this is not enough = information. For the purpose of this discussion, there are two kinds of = directed traps I=92d like to address. The first type of directed trap is found in the RMON MIB. The = eventTable is used to determine if an RMON event will generate an SNMP = trap, and if so, the associated instance of eventCommunity specifies the = communities which are to receive the trap. In other words, the trap = should only be directed to those hosts associated with the given = community. Unfortunately, the agentx-Notify-PDU does not provide a = mechanism for an RMON subagent to tell the master agent the communities = to which the trap is to be directed, and hence agentx is unable to = correctly support RMON traps. = The second type of directed trap is not found in any standard MIB that I = am aware of. However, I have seen this type of trap in several vendor = MIBs. This type of trap is sent to a single recipient when a service = that was requested has completed. Consider a generic "service" MIB. = Such a MIB would allow a management application to specify the = parameters for a service to be performed, and then activate the service. = The management application can monitor a status object to check when the = requested service has completed, or alternately can wait for a directed = trap that is sent from the agent to the management application when the = service has completed. Since this mechanism is not found in any = standard MIBs, there is not a requirement to support it, but it would be = nice to have this capability. Of course, I recognize that adding this = support would require adding a mechanism for the subagent to specify the = destination of the trap, and further would require adding a mechanism = for the subagent to determine from the master agent where the initial = service request came from. /jeff   Delivery-Date: Sun, 15 Dec 1996 23:21:09 -0800 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.5/8.7.3) id XAA00211 for X-agentx; Sun, 15 Dec 1996 23:21:08 -0800 (PST) Received: from gauntlet.fv.com (gauntlet.fv.com [207.67.199.118]) by fv.com (8.7.5/8.7.3) with ESMTP id XAA00201 for ; Sun, 15 Dec 1996 23:21:07 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.7.5/8.7.3) id CAA00551 for ; Mon, 16 Dec 1996 02:21:28 -0500 (EST) Received: from shekel.fv.com(207.67.199.130) by gauntlet.fv.com via smap (3.2) id xma000528; Sun, 15 Dec 96 23:20:59 -0800 Received: from gauntlet.fv.com (gauntlet-in.fv.com [10.0.0.2]) by shekel.fv.com (8.7.5/8.7.3) with ESMTP id XAA29084 for ; Sun, 15 Dec 1996 23:21:33 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.7.5/8.7.3) id CAA00512 for ; Mon, 16 Dec 1996 02:20:57 -0500 (EST) Received: from bubbuh.cisco.com(198.92.30.35) by gauntlet.fv.com via smap (3.2) id xma000492; Sun, 15 Dec 96 23:20:40 -0800 Received: from manatee.cisco.com (manatee.cisco.com [171.69.131.101]) by bubbuh.cisco.com (8.7.6/CISCO.GATE.1.1) with SMTP id XAA00563 for ; Sun, 15 Dec 1996 23:20:16 -0800 (PST) Message-ID: <32B4F5EE.50D3@cisco.com> Date: Sun, 15 Dec 1996 23:10:38 -0800 From: "Jeffrey T. Johnson" Organization: cisco Systems, Inc. X-Mailer: Mozilla 3.0 (Win95; I) MIME-Version: 1.0 To: agentx@fv.com Subject: Support for Persistency Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Although I don=92t know of any arbitrarily-indexed MIB tables which = require that the arbitrary indexing be persistent from reboot to reboot, = there are customers who require this, specifically in the ifTable. Many = of us have experienced the distinct displeasure of trying to explain to = a customer that it is perfectly legal for a given interface to have a = different ifIndex value following a reboot. Many applications don=92t = handle this, and customers are more likely to blame the agent than the = application. So it would be nice if there were some support for = persistency. I have though of two possible mechanisms. One mechanism is quite simple. When a master agent powers up, it = ignores (or postpones) responding to agentx-IndexAllocate-PDU which = specify NEW_INDEX or ANY_INDEX. This allows subagents which want a = specific index to power up and request the index before it has been = arbitrarily assigned to another subagent. The second mechanism is more complex. If a subagent requests a given = index, and it has already been arbitrarily assigned to another subagent, = but if that subagent has not sent or received any agentx PDUs which = utilize the given index, then the master agent can take back the index = and reassign a new one. This is much more complex. /jeff   Delivery-Date: Sun, 15 Dec 1996 23:21:10 -0800 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.5/8.7.3) id XAA00209 for X-agentx; Sun, 15 Dec 1996 23:21:08 -0800 (PST) Received: from gauntlet.fv.com (gauntlet.fv.com [207.67.199.118]) by fv.com (8.7.5/8.7.3) with ESMTP id XAA00195 for ; Sun, 15 Dec 1996 23:21:06 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.7.5/8.7.3) id CAA00547 for ; Mon, 16 Dec 1996 02:21:28 -0500 (EST) Received: from shekel.fv.com(207.67.199.130) by gauntlet.fv.com via smap (3.2) id xma000527; Sun, 15 Dec 96 23:20:59 -0800 Received: from gauntlet.fv.com (gauntlet-in.fv.com [10.0.0.2]) by shekel.fv.com (8.7.5/8.7.3) with ESMTP id XAA29082 for ; Sun, 15 Dec 1996 23:21:33 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.7.5/8.7.3) id CAA00510 for ; Mon, 16 Dec 1996 02:20:57 -0500 (EST) Received: from bubbuh.cisco.com(198.92.30.35) by gauntlet.fv.com via smap (3.2) id xma000491; Sun, 15 Dec 96 23:20:39 -0800 Received: from manatee.cisco.com (manatee.cisco.com [171.69.131.101]) by bubbuh.cisco.com (8.7.6/CISCO.GATE.1.1) with SMTP id XAA00559 for ; Sun, 15 Dec 1996 23:20:14 -0800 (PST) Message-ID: <32B4F5EC.287@cisco.com> Date: Sun, 15 Dec 1996 23:10:36 -0800 From: "Jeffrey T. Johnson" Organization: cisco Systems, Inc. X-Mailer: Mozilla 3.0 (Win95; I) MIME-Version: 1.0 To: agentx@fv.com Subject: Get-Bulk Elements of Procedure Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable This is more of a hand waving objection. I=92ll admit that I have not sa= t = down and verified that the get-bulk elements of procedure really work. = But a few things just jumped out at me. Let me share a little story. There was an SNMPv2 interoperability = testing event held at CMU about three years ago. One of the tests was a = get-bulk performance test. In this test a get-bulk request was sent to = the agent which specified an extremely large value for max-repetitions. = Not all agents handled this well. Some just =93went away.=94 These agen= ts = actually tried to perform all of the repetitions on all of the variable = bindings, and only when it was time to build the response did it = discover that the response packet was too big. Way too big. So the = agent had performed thousands of unnecessary dispatches into the method = routines. The moral of the story is that just because a get-bulk pdu = requests a certain number of repetitions doesn=92t mean that a agent need= s = to perform that many repetitions. This brings us to 7.2.1.3 of the agentx draft which starts by specifying = that a response PDU containing N + (M * R) variable bindings. For large = values of M this is stupid since the response will be too big. Further, = even though step 2 specifies that the g.max_repetitions field in the = agentx-GetBulk-PDU can be set to a value smaller than the max- repetitions field in the incoming SNMP PDU, there are no real guidelines = for supplying a value. There is another problem that I perceive with the GetBulk elements of = procedure. I believe that you can=92t do a given repetition until the = previous repetition has completed. Consider three subagents SA1, SA2, = and SA3 which respectively serve ifTable rows 1, 2, and 3. Suppose the = master agent receives a GetBulk PDU which specifies zero non-repeaters, four max-repetitions, and a single variable binding of ifTable. = According to step 1 we identify the target subagent and OID range. Well = this will only identify one subagent, SA1. A mechanism has not been = specified which would require the master agent to also get the = appropriate information from SA2 and SA3. I personally don=92t see that an agentx-GetBulk-PDU is necessary (or that= = one would even work). It seems to me that an agentx-GetNext-PDU should = be used for the non-repeaters. Then a loop is entered that iterates at = most max-repetitions times. This loop would seed a requested varbinds = list with the remaining varbinds from the GetNext PDU. Each iteration = of the loop would use the agentx-GetNext-Pdu to retrieve the values for = each of the requested varbinds. The returned OID would then be used as = the requested varbind on the next iteration. This scheme has the = advantage that it removes complexity from the subagents, and that it = handles the cutover from one subagent to another. /jeff   Delivery-Date: Sun, 15 Dec 1996 23:21:08 -0800 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.5/8.7.3) id XAA00204 for X-agentx; Sun, 15 Dec 1996 23:21:07 -0800 (PST) Received: from gauntlet.fv.com (gauntlet.fv.com [207.67.199.118]) by fv.com (8.7.5/8.7.3) with ESMTP id XAA00185 for ; Sun, 15 Dec 1996 23:21:06 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.7.5/8.7.3) id CAA00534 for ; Mon, 16 Dec 1996 02:21:27 -0500 (EST) Received: from shekel.fv.com(207.67.199.130) by gauntlet.fv.com via smap (3.2) id xma000519; Sun, 15 Dec 96 23:20:58 -0800 Received: from gauntlet.fv.com (gauntlet-in.fv.com [10.0.0.2]) by shekel.fv.com (8.7.5/8.7.3) with ESMTP id XAA29070 for ; Sun, 15 Dec 1996 23:21:32 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.7.5/8.7.3) id CAA00498 for ; Mon, 16 Dec 1996 02:20:55 -0500 (EST) Received: from bubbuh.cisco.com(198.92.30.35) by gauntlet.fv.com via smap (3.2) id xma000487; Sun, 15 Dec 96 23:20:31 -0800 Received: from manatee.cisco.com (manatee.cisco.com [171.69.131.101]) by bubbuh.cisco.com (8.7.6/CISCO.GATE.1.1) with SMTP id XAA00543 for ; Sun, 15 Dec 1996 23:20:06 -0800 (PST) Message-ID: <32B4F5DC.235F@cisco.com> Date: Sun, 15 Dec 1996 23:10:20 -0800 From: "Jeffrey T. Johnson" Organization: cisco Systems, Inc. X-Mailer: Mozilla 3.0 (Win95; I) MIME-Version: 1.0 To: agentx@fv.com Subject: draft-ietf-agentx-ext-pro-01.txt problems Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable For those of you who were not at the AgentX Working Group meeting in San = Jose, I want to start by reiterating the apology I made there. I have = been busy with other activities and have not been following this working = group. But recently I was asked by several individuals to look over the = latest draft as a sanity check. This is an incredible piece of work, = and I congratulate you on the thoroughness and completeness of the = document. One could argue that this is a bad feature, since as a result = I was able to find what I consider to be several show-stopper issues. = So as I did in San Jose, I want to apologize here for bringing these = issues up so late in the schedule, but I hope that by doing so, the = working group can produce a document that can be usefully deployed. When evaluating the document, I took off my normal hat as a developer of = embedded agent/subagent software, and instead examined the problems of a = developer trying to interface his product with other products in an open = system such as a workstation. In particular, I was interested in two = classes of products: 1) software applications running on the workstation 2) hardware products with on-board subagents being plugged into the = workstation AgentX is of course not limited to these environments, but I do feel = that this is where it is most applicable. In evaluating the document from this perspective, it is useful to see = how currently existing, applicable MIBs would be implemented in an = AgentX environment. In particular, I considered it mandatory that an = AgentX master agent with multiple subagents be able to completely = implement the following MIBs which should reasonably be expected to be = implemented in an AgentX environment. 1) The MIBs Formerly Known as MIB-II 1.1) SNMPv2 MIB 1.2) Interfaces MIB 1.3) IP MIB 1.4) UDP MIB 1.5) TCP MIB 2) Media-specific MIBs 3) Remote Monitoring MIB 4) Host Resources MIB 5) Application MIB Note that I wanted to add Entity MIB to the list, but I don=92t see how i= t = can be implemented in a distributed environment (particularly the object = entPhysicalContainedIn). Now that you know where I=92m coming from, here is my list of issues. I=92= m = going to address each in separate messages so that the individual = threads can be followed. 1) unionized registration requirement 2) handling scalar objects 3) directed traps 4) get-bulk elements of procedure 5) support for persistency I did have some other issues (including concerns about how the index = allocation scheme works), but feel that the above issues are of a higher = priority. /jeff   Delivery-Date: Sun, 15 Dec 1996 23:21:09 -0800 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.5/8.7.3) id XAA00215 for X-agentx; Sun, 15 Dec 1996 23:21:08 -0800 (PST) Received: from gauntlet.fv.com (gauntlet.fv.com [207.67.199.118]) by fv.com (8.7.5/8.7.3) with ESMTP id XAA00190 for ; Sun, 15 Dec 1996 23:21:06 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.7.5/8.7.3) id CAA00545 for ; Mon, 16 Dec 1996 02:21:28 -0500 (EST) Received: from shekel.fv.com(207.67.199.130) by gauntlet.fv.com via smap (3.2) id xma000526; Sun, 15 Dec 96 23:20:58 -0800 Received: from gauntlet.fv.com (gauntlet-in.fv.com [10.0.0.2]) by shekel.fv.com (8.7.5/8.7.3) with ESMTP id XAA29079 for ; Sun, 15 Dec 1996 23:21:33 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.7.5/8.7.3) id CAA00508 for ; Mon, 16 Dec 1996 02:20:57 -0500 (EST) Received: from bubbuh.cisco.com(198.92.30.35) by gauntlet.fv.com via smap (3.2) id xma000489; Sun, 15 Dec 96 23:20:35 -0800 Received: from manatee.cisco.com (manatee.cisco.com [171.69.131.101]) by bubbuh.cisco.com (8.7.6/CISCO.GATE.1.1) with SMTP id XAA00551 for ; Sun, 15 Dec 1996 23:20:11 -0800 (PST) Message-ID: <32B4F5EA.4482@cisco.com> Date: Sun, 15 Dec 1996 23:10:34 -0800 From: "Jeffrey T. Johnson" Organization: cisco Systems, Inc. X-Mailer: Mozilla 3.0 (Win95; I) MIME-Version: 1.0 To: agentx@fv.com Subject: Handling Scalar Objects Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Unlike table objects where a given instance of an object typically resides on a single subagent, scalar objects typically represent global data which may be shared among multiple (or all) subagents. The current agentx draft has no support for scalar objects. Consider the scalar ifNumber. The agentx draft uses the ifTable in many of its examples to demonstrate how agentx works, and yet inexplicably ignores ifNumber. In reality the value for the global ifNumber is the sum of the individual ifNumber values maintained by each subagent supporting the ifTable. But there is no mechanism in agentx to support this summation. /jeff   Delivery-Date: Mon, 16 Dec 1996 10:34:18 -0800 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.5/8.7.3) id KAA23091 for X-agentx; Mon, 16 Dec 1996 10:34:18 -0800 (PST) Received: from gauntlet.fv.com (gauntlet.fv.com [207.67.199.118]) by fv.com (8.7.5/8.7.3) with ESMTP id KAA23088 for ; Mon, 16 Dec 1996 10:34:17 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.7.5/8.7.3) id NAA21213 for ; Mon, 16 Dec 1996 13:34:36 -0500 (EST) Received: from shekel.fv.com(207.67.199.130) by gauntlet.fv.com via smap (3.2) id xma021199; Mon, 16 Dec 96 10:34:11 -0800 Received: from gauntlet.fv.com (gauntlet-in.fv.com [10.0.0.2]) by shekel.fv.com (8.7.5/8.7.3) with ESMTP id KAA26803 for ; Mon, 16 Dec 1996 10:34:44 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.7.5/8.7.3) id NAA21189 for ; Mon, 16 Dec 1996 13:34:06 -0500 (EST) Received: from stratacom.strata.com(204.179.0.2) by gauntlet.fv.com via smap (3.2) id xma021180; Mon, 16 Dec 96 10:33:50 -0800 Received: from Strata.COM (kiwi.strata.com) by stratacom.strata.com (4.1/SMI-4.1/Gatekeeper.Strata.Com-950201) id AA08063; Mon, 16 Dec 96 10:29:14 PST Received: from farley.strata.com by Strata.COM (4.1/SMI-4.1/StrataCom-GCA-Kiwi-961130-1) id AA14628; Mon, 16 Dec 96 10:29:13 PST Received: from santa.strata.com by farley.strata.com (SMI-8.6/SMI-SVR4) id KAA27150; Mon, 16 Dec 1996 10:28:33 -0800 Received: from marvell.strata.com by santa.strata.com (4.1/SMI-4.1/StrataCom-GCA-SunClient-LOCAL-931101) id AA01658; Mon, 16 Dec 96 10:29:12 PST Date: Mon, 16 Dec 96 10:29:12 PST From: dfrancis@stratacom.com (Dale Francisco) Message-Id: <9612161829.AA01658@santa.strata.com> To: agentx@fv.com Subject: San Jose IETF meeting Cc: natale@acec.com, daniele@zk3.dec.com, wijnen@vnet.ibm.com The AgentX WG meeting at IETF 37, San Jose, was an occasion for some very productive and focused discussion of issues regarding the latest version of the protocol draft. We had good questions and contributions from Uri Blumenthal, Jeff Case, Maria Greene, Jeff Johnson, Randy Presuhn, Don Ryan, and several others. It was clear that not only have many people given the draft a careful review, there are many implementing AgentX now. Not surprisingly, implementors are running into ambiguities or problems with the draft. Which is good; part of what early implementation is about is exposing the problems. I will be publishing a more-than-usually-complete set of minutes by the end of this week, so that those who were unable to attend will get a sense of the issues that were discussed. In the meantime, here's a list of milestones that we agreed on for the next couple of months: Jan 10 Deadline for submission of problems or questions regarding the current protocol draft. The idea is to make sure that the many good points raised during last Wednesday's discussion are submitted to the group in writtten form, so that we can track them and reach consensus on resolution. Jeff Johnson has started the ball rolling with his recent e-mails. Feb 14 Closure for discussion and consensus on the protocol. Feb 28 Revised protocol draft submitted to the IETF. Thanks, Dale Francisco Editor, AgentX WG dfrancis@cisco.com Cisco Systems 150 Castilian Drive Goleta CA 93117-3028 voice: (805) 961-3642 fax: (805) 961-3600   Delivery-Date: Mon, 16 Dec 1996 11:09:36 -0800 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.5/8.7.3) id LAA25965 for X-agentx; Mon, 16 Dec 1996 11:09:36 -0800 (PST) Received: from gauntlet.fv.com (gauntlet.fv.com [207.67.199.118]) by fv.com (8.7.5/8.7.3) with ESMTP id LAA25962 for ; Mon, 16 Dec 1996 11:09:36 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.7.5/8.7.3) id OAA23761 for ; Mon, 16 Dec 1996 14:09:55 -0500 (EST) Received: from shekel.fv.com(207.67.199.130) by gauntlet.fv.com via smap (3.2) id xma023728; Mon, 16 Dec 96 11:09:27 -0800 Received: from gauntlet.fv.com (gauntlet-in.fv.com [10.0.0.2]) by shekel.fv.com (8.7.5/8.7.3) with ESMTP id LAA29714 for ; Mon, 16 Dec 1996 11:10:04 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.7.5/8.7.3) id OAA23721 for ; Mon, 16 Dec 1996 14:09:26 -0500 (EST) Message-Id: <199612161909.OAA23721@gauntlet.fv.com> Received: from vnet.ibm.com(199.171.26.4) by gauntlet.fv.com via smap (3.2) id xma023696; Mon, 16 Dec 96 11:09:16 -0800 Received: from UITVM1 by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 8752; Mon, 16 Dec 96 14:08:41 EST Date: Mon, 16 Dec 96 18:09:12 CET From: "Bert Wijnen" To: agentx@fv.com Subject: comments by Jeff Johnson - RMON MIB Jeff, thanks for some very good feedback that we need to take into account and that we need to analyze and try to address. One MIB that you mention is the RMON MIB. Now... in the past people have also used the RMON MIB to explain to me that DPI was flawed. Such is fine... except that my statement was back then that I did not see that MIBs like the RMON-MIB should/would use somethng like the DPI. So I offered back then (to everyone who used the RMON MIB as an example) that I would try to address the issues if any RMON MIB implementer is ready to do an implementation that used the DPI. But none would do so. An I think that the reason is that they need to do so many detailed things and need to know so much about SNMP already, that they prefer to directly implement the thing as a monolithic agent. To me that means that a mib like RMON is not meant to be implemented using DPI (or any other extensible agent protocol). So for agentX, I kind of still think the same. Now.... - Is there any RMON-MIB implementer out there who is willing to use agentX to implement this mib??? This assumes we will change agentX such that you can indeed do that. If the answer is yes, are you willing to do an implementation soon, so we can really verify that it can work and that it can perform in an acceptable manner? - If you do not want to use agentX, even if we solve the problems that Jeff has identified (and any othe rproblems we may find), can you then explain why? I am trying to get a feel if we are trying to solve problems that only 1% or less of the public would need/use. Thanks, Bert   Delivery-Date: Mon, 16 Dec 1996 15:03:28 -0800 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.5/8.7.3) id PAA15916 for X-agentx; Mon, 16 Dec 1996 15:03:28 -0800 (PST) Received: from gauntlet.fv.com (gauntlet.fv.com [207.67.199.118]) by fv.com (8.7.5/8.7.3) with ESMTP id PAA15913 for ; Mon, 16 Dec 1996 15:03:27 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.7.5/8.7.3) id SAA09796 for ; Mon, 16 Dec 1996 18:03:46 -0500 (EST) Received: from shekel.fv.com(207.67.199.130) by gauntlet.fv.com via smap (3.2) id xma009781; Mon, 16 Dec 96 15:03:18 -0800 Received: from gauntlet.fv.com (gauntlet-in.fv.com [10.0.0.2]) by shekel.fv.com (8.7.5/8.7.3) with ESMTP id PAA17132 for ; Mon, 16 Dec 1996 15:03:55 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.7.5/8.7.3) id SAA09774 for ; Mon, 16 Dec 1996 18:03:16 -0500 (EST) Received: from mail12.digital.com(192.208.46.20) by gauntlet.fv.com via smap (3.2) id xma009767; Mon, 16 Dec 96 15:02:47 -0800 Received: from flume.zk3.dec.com by mail12.digital.com (8.7.5/UNX 1.5/1.0/WV) id RAA13334; Mon, 16 Dec 1996 17:55:34 -0500 (EST) Received: from bernie.zk3.dec.com by flume.zk3.dec.com; (5.65v3.2/1.1.8.2/16Jan95-0946AM) id AA09688; Mon, 16 Dec 1996 17:55:16 -0500 Received: from localhost by bernie.zk3.dec.com; (5.65/1.1.8.2/22Aug96-1117AM) id AA06346; Mon, 16 Dec 1996 17:59:15 -0500 Message-Id: <9612162259.AA06346@bernie.zk3.dec.com> To: jjohnson@Cisco.COM Cc: agentx@fv.com Subject: Unionized Registration Requirement Date: Mon, 16 Dec 96 17:59:14 -0500 From: Mike Daniele X-Mts: smtp >From: "Jeffrey T. Johnson" Hi Jeff, Thanks for taking the time to post your detailed comments. >Although the current draft allows a subagent to register non-qualified = >support for a table (i.e. without any instance information), in reality = >such registrations will be useless. Many a unix gated would be happy to register ipRouteTable out from under another subagent's mib-2 registration ... In the context of sharing tables, yes I agree it is not useful. >The current draft provides several examples of a = >subagent registering partially or fully qualified table instances. The = >section on index allocation describes how a subagent might register = >support for ifTable.[1-22].i, ipNetToMediaTable.[1-4].i, or = >tcpConnTable.[1-5].a.b.c.d (as a side note, "Table" should actually be = >"Entry" in the examples). Dale please note! :-) >Unfortunately, even the above examples can cause a lot of overhead for = >both the master agent and subagent. Consider a subagent on a Network = >Interface Card containing 128 interfaces. Jeff, which of the following 2 categories applies to this NIC? >To: agentx@fv.com >Subject: draft-ietf-agentx-ext-pro-01.txt problems >When evaluating the document, I took off my normal hat as a developer of = >embedded agent/subagent software, and instead examined the problems of a = >developer trying to interface his product with other products in an open = >system such as a workstation. In particular, I was interested in two = >classes of products: >1) software applications running on the workstation >2) hardware products with on-board subagents being plugged into the = > workstation >AgentX is of course not limited to these environments, but I do feel = >that this is where it is most applicable. Are you saying it's common to plug into a "workstation" a NIC that supports 128 interfaces? I think you forgot to take your hat off :-) I agree completely with the focus of your evaluation. I seem to arrive at different conclusions. >Unfortunately, there are tables which = >might be useful in a subagent environment for which no portion of the = >instance information is static. Consider the MIB-II ipRouteTable, which = >is indexed by ipRouteDest. This index value is not arbitrary and is not = >specific to a subagent. With the current registration scheme, since two = >routing subagents cannot both register for "ipRouteTable", they must = >register ipRouteEntry.1-13.a.b.c.d for every ip route, and must = >constantly register and deregister individual instances as the routing = >tables change. On Internet connected devices, this can result in tens = >of thousands of entries registered with the master agent, with multiple = >changes every second, resulting in more administrative traffic than pdu = >traffic between master agent and subagent. This would seem to indicate = >that the decision to not support non-unionized registrations might not = >be optimal. I am not aware of any real-world situations in which the ipRouteTable needs to be shared between multiple subagents. Are you? Certainly NICs don't know about ip routes, right? And if there are 2 subagents running on a system that each wish to register ipRouteTable, one of them is successful and one of them is not. This seems like the correct behavior to me. >So here is the show stopper. Without unionized = >registrations, there is no way to support row creation in arbitrarily = >indexed tables. This is true. The argument that was made on this list during previous discussions went something like this: One subagent registers the table, and as such receives all requests for row creation. It forks/starts other subagents that each manage (register) a (newly created) row in the table. Note also that this mechanism would permit the first (overseer) subagent to implement a scalar that counts the number of entries in the table. It seems that this scheme would work only within a solution delivered by a single, or cooperating, vendors. But that seemed to be the case whenever it was discussed. I'd be interested in your thoughts on this idea. >Consider the RMON-MIB. If an application wants to create a history = >study, it does so by creating a row in the historyControlTable. This = >table is indexed by historyControlIndex, an arbitrary index. Since the = >index is arbitrary, a subagent cannot register for it beforehand. The = >only way that the historyControlTable (or any other RMON control table) = >can be supported is if unionized registration is allowed. This might be a showstopper, but I don't understand it enough to know. Could you explain how subagents share the implementation of RMON mib? When this was being debated previously, I asked: >Would it be possible to supply a specific example how this feature >(permitting multiple subagents to register the same oid) is used/required >in order for subagents to implement a table that is split across subagents? >What I'm really trying to get at is this: Is it useful/required because >a) These companies implement tables that CANNOT reasonably be split > across subagents WITHOUT this feature. That is, the table's indexing > structure and/or the nature of the data make it impossible to > partition the table so that each subagent gets unique sections? > (If so, an example of this would be vey helpful.) >or >b) These companies implement subagents that each "take the easy way out" > and register the entire table, and expect the master agent to figure > things out. (Perhaps this is reality and it's naive to expect otherwise...) The response was >Sure. The clasic example is the Interfaces table. These days, interfaces >can come as loadable software drivers, plug-in hardware, or both. Are you >going to require every interface hardware/software vendor to reserve a chunk >of ifIndex space so that their subagents can pre-register which instance >they will support? I think there is general agreement that this case can be handled with index allocation and instance-level registration. If the vendors are going to ship NICs that register ifTable, can't they ship NICs that allocate an ifindex and then register a row (or rows) of ifTable? In general (and to the best of my recollection :-), no one came forth with a concrete example of a MIB table that really will/must be shared by generic multivendor subagents, and that cannot be reasonably partitioned according to the draft. In addition, several individuals were concerned about the added complexity, and the lack of "data integrity" (different subagents implementing the same variable at different times, etc). Given all this, it didn't survive. To some extent I've been playing devil's advocate in this mail, but I really would like to see an example that shows us unionized registration is absolutely necessary for successful deployment of AgentX subagents. For instance, - NIC vendors can't implement media-specific mib without unionized registrations, because ... - Software vendors can't implement mib because ... If you HAVE given such an example and I'm too thick to get it, please keep trying. Thanks, Mike   Delivery-Date: Tue, 17 Dec 1996 01:44:14 -0800 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.5/8.7.3) id BAA07079 for X-agentx; Tue, 17 Dec 1996 01:44:14 -0800 (PST) Received: from gauntlet.fv.com (gauntlet.fv.com [207.67.199.118]) by fv.com (8.7.5/8.7.3) with ESMTP id BAA07076 for ; Tue, 17 Dec 1996 01:44:13 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.7.5/8.7.3) id EAA27695 for ; Tue, 17 Dec 1996 04:44:32 -0500 (EST) Received: from shekel.fv.com(207.67.199.130) by gauntlet.fv.com via smap (3.2) id xma027693; Tue, 17 Dec 96 01:44:02 -0800 Received: from gauntlet.fv.com (gauntlet-in.fv.com [10.0.0.2]) by shekel.fv.com (8.7.5/8.7.3) with ESMTP id BAA18295 for ; Tue, 17 Dec 1996 01:44:40 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.7.5/8.7.3) id EAA27690 for ; Tue, 17 Dec 1996 04:44:01 -0500 (EST) Received: from malmo.trab.se(131.115.48.10) by gauntlet.fv.com via smap (3.2) id xma027688; Tue, 17 Dec 96 01:43:44 -0800 Received: (from root@localhost) by malmo.trab.se (8.7.5/TRAB-primary-1) id KAA21208 for agentx@fv.com; Tue, 17 Dec 1996 10:43:21 +0100 (MET) Message-Id: <199612170943.KAA21208@malmo.trab.se> X400-Received: by mta trab.se in /c=SE/admd=400net/prmd=Telia/; converted ( (1)(0)(10021)(7)(1)(0)(6)(6), (1)(0)(10021)(7)(1)(0)(6)(1)); Relayed; 17 Dec 1996 10:43:20 +0100 X400-Received: by /c=SE/admd=400net/prmd=Telia/; converted ( (1)(0)(10021)(7)(1)(0)(6)(6), (1)(0)(10021)(7)(1)(0)(6)(1)); Relayed; 17 Dec 1996 10:43:20 +0100 X400-Received: by /c=se/admd=400net/prmd=mailbus/; Relayed; 17 Dec 1996 10:44:48 +0100 X400-MTS-Identifier: [/c=se/admd=400net/prmd=mailbus/; 850815889] Content-Return: Allowed X400-Content-Type: P2-1988 ( 22 ) Conversion: Allowed Original-Encoded-Information-Types: (1)(0)(10021)(7)(1)(0)(6), (1)(0)(10021)(7)(1)(0)(1) Priority: normal Disclose-Recipients: Prohibited Alternate-Recipient: Allowed X400-Originator: Kim.H.Laraqui@telia.se X400-Recipients: non-disclosure; Sensitivity: Company-Confidential Date: 17 Dec 1996 10:44:48 +0100 From: Kim Laraqui To: agentx@fv.com Subject: Some questions on AgentX MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable When I read the doc on AgentX (November 1996) my first reaction is that it is so "anti-SNMP". My understanding of the spirit of SNMP/SMI is the use of a very limited set of PDUs to convey pretty simple structur= es that still are used to model complex control applications and mechanisms.= = The MIB is used as a repository of system and interface variables, = as opposed to traditional signaling protocols in which the control = data structures are immediately consumed by a FSM; these FSMs = always come with a bunch of system variables but those are still very = local to the signaling protocol in their structures (i.e. not SMI). It's = thus very difficult within the realm of one control/signaling protocol to refe= r to a variable in another. Thus, the way I see it, there is a big differen= ce between concentrating semantics on MIB variables and on PDUs. So my question is, why doesn't the AgentX protocol use SMI structures (say something like one table per AgentX PDU type, to be deployed on the master or subagent or both, depending on the PDUs' target) in combina= tion = with the simple set/get operations, to achieve the same results as that w= hich is currently being advocated to employ lots of new PDU types for? One cou= ld still retain the faster coding schemes currently proposed. = Could someone enlighten a humble SNMP user from the deep and cold = Swedish forests. Cheers /kim (Mr!) Kim Laraqui, Telia Research, Haninge, Sweden.   Delivery-Date: Tue, 17 Dec 1996 06:14:06 -0800 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.5/8.7.3) id GAA28020 for X-agentx; Tue, 17 Dec 1996 06:14:06 -0800 (PST) Received: from gauntlet.fv.com (gauntlet.fv.com [207.67.199.118]) by fv.com (8.7.5/8.7.3) with ESMTP id GAA28017 for ; Tue, 17 Dec 1996 06:14:05 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.7.5/8.7.3) id JAA01504 for ; Tue, 17 Dec 1996 09:14:23 -0500 (EST) Received: from shekel.fv.com(207.67.199.130) by gauntlet.fv.com via smap (3.2) id xma001502; Tue, 17 Dec 96 06:13:53 -0800 Received: from gauntlet.fv.com (gauntlet-in.fv.com [10.0.0.2]) by shekel.fv.com (8.7.5/8.7.3) with ESMTP id GAA26471 for ; Tue, 17 Dec 1996 06:14:30 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.7.5/8.7.3) id JAA01499 for ; Tue, 17 Dec 1996 09:13:53 -0500 (EST) Received: from mail.htconn.com(38.245.21.2) by gauntlet.fv.com via smap (3.2) id xma001497; Tue, 17 Dec 96 06:13:41 -0800 Received: from tmax.htconn.com by mail.htconn.com (SMI-8.6/SMI-SVR4) id JAA06936; Tue, 17 Dec 1996 09:12:32 -0500 Date: Tue, 17 Dec 1996 09:12:32 -0500 From: devlinm@mail.htconn.com (T. Max Devlin) Message-Id: <199612171412.JAA06936@mail.htconn.com> To: agentx@fv.com Subject: Re: comments by Jeff Johnson - RMON MIB X-Mailer: ProntoIP [version 2.0] MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit > > So for agentX, I kind of still think the same. Now.... > - Is there any RMON-MIB implementer out there who is willing > to use agentX to implement this mib??? This assumes we will > change agentX such that you can indeed do that. I am not an agent implementor, but also made a mental note when I saw Jeff's list of MIBs. I work (teaching, consulting, developing, evaluating, analyzing, etc.) with SNMP-based enterprise network management platforms and systems, so I am familiar with a wide variety of operational commercially available network management software. No credentials, but I've got experience. Since RMON was published and finalized, I have been discussing its strengths and weaknesses to both technical and sales/management people (the latter who often casually throw it on the table as a silver bullet, without in any way examining the intricacy and difficulty of using it for the solution unders discussion). I have seen broken RMON, and I have seen functional RMON. And it is my honest opinion that there is no justification whatsoever for supporting RMON with an extensible agent. Yes, you could build an agent which maintained a MIB for multiple probes. But why? And how is this any different from the multiple interface capability already built into RMON? I discount "big picture" agents such as a theoretical implementation which will use a number of RMON sub-agents to correlate instrumentation from a number of different LANs to give an overall representation of a network, as this scenario seems more appropriately handled with multiple interfaces within RMON, or as a mid-level-manager type entity, rather than a master/slave agent system. Thanks for asking, Bert, and I hope my input is useful. I'm also interested, of course, in discussing why my opinion may be completely wrong. So all I can do, I guess, is repeat your question: IS there an RMON implementor who can envision a reason for an agentx-based RMON implementation? -- T. Max Devlin Hi-TECH Connections Voice:(610)372-1401x233 Fax:(610)372-1805 tmax@htconn.com -[Opinions expressed are my own; everyone else, including my employer, has to pay for them, subject to applicable licensing agreement]-   Delivery-Date: Tue, 17 Dec 1996 06:34:06 -0800 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.5/8.7.3) id GAA29635 for X-agentx; Tue, 17 Dec 1996 06:34:05 -0800 (PST) Received: from gauntlet.fv.com (gauntlet.fv.com [207.67.199.118]) by fv.com (8.7.5/8.7.3) with ESMTP id GAA29632 for ; Tue, 17 Dec 1996 06:34:05 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.7.5/8.7.3) id JAA01789 for ; Tue, 17 Dec 1996 09:34:23 -0500 (EST) Received: from shekel.fv.com(207.67.199.130) by gauntlet.fv.com via smap (3.2) id xma001787; Tue, 17 Dec 96 06:33:54 -0800 Received: from gauntlet.fv.com (gauntlet-in.fv.com [10.0.0.2]) by shekel.fv.com (8.7.5/8.7.3) with ESMTP id GAA27252 for ; Tue, 17 Dec 1996 06:34:31 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.7.5/8.7.3) id JAA01778 for ; Tue, 17 Dec 1996 09:33:54 -0500 (EST) Received: from mail.htconn.com(38.245.21.2) by gauntlet.fv.com via smap (3.2) id xma001773; Tue, 17 Dec 96 06:33:33 -0800 Received: from tmax.htconn.com by mail.htconn.com (SMI-8.6/SMI-SVR4) id JAA07064; Tue, 17 Dec 1996 09:32:38 -0500 Date: Tue, 17 Dec 1996 09:32:38 -0500 From: devlinm@mail.htconn.com (T. Max Devlin) Message-Id: <199612171432.JAA07064@mail.htconn.com> To: agentx@fv.com Subject: Re: Unionized Registration Requirement X-Mailer: ProntoIP [version 2.0] MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit > > >The current draft provides several examples of a = > >subagent registering partially or fully qualified table instances. The = > >section on index allocation describes how a subagent might register = > >support for ifTable.[1-22].i, ipNetToMediaTable.[1-4].i, or = > >tcpConnTable.[1-5].a.b.c.d (as a side note, "Table" should actually be = > >"Entry" in the examples). > > Dale please note! :-) > I'm not a developer, but I do teach SNMP concepts, so I'd like to give some input here. I would disagree with Jeff and Mike, I think. Conceptually, the sub-agent does not "support" an Entry; it registers the Entry to support the Table. It's just semantics, and I don't want to sound like I'm just picking at Jeff's words, but it makes more sense that if an agent is registering support *for* ifTable, it does so by identifying specific "Entry's" (rows), that is; support *of* ifEntry.[1-22] I agree that it is more precise to use the Entry objects in the examples in 7.1.3, but I feel that it is far more confusing. I suggest that the reference to "Table" remain, but the OIDs be changed (ifTable.1.[1-22].i, pNetToMediaTable.1.[1-4].i, or tcpConnTable.1.[1-5].a.b.c.d) for accuracy. -- T. Max Devlin Hi-TECH Connections Voice:(610)372-1401x233 Fax:(610)372-1805 tmax@htconn.com -[Opinions expressed are my own; everyone else, including my employer, has to pay for them, subject to applicable licensing agreement]-   Delivery-Date: Tue, 17 Dec 1996 07:50:03 -0800 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.5/8.7.3) id HAA06368 for X-agentx; Tue, 17 Dec 1996 07:50:02 -0800 (PST) Received: from gauntlet.fv.com (gauntlet.fv.com [207.67.199.118]) by fv.com (8.7.5/8.7.3) with ESMTP id HAA06356 for ; Tue, 17 Dec 1996 07:50:01 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.7.5/8.7.3) id KAA05630 for ; Tue, 17 Dec 1996 10:50:20 -0500 (EST) Received: from shekel.fv.com(207.67.199.130) by gauntlet.fv.com via smap (3.2) id xma005616; Tue, 17 Dec 96 07:49:50 -0800 Received: from gauntlet.fv.com (gauntlet-in.fv.com [10.0.0.2]) by shekel.fv.com (8.7.5/8.7.3) with ESMTP id HAA02506 for ; Tue, 17 Dec 1996 07:50:28 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.7.5/8.7.3) id KAA05611 for ; Tue, 17 Dec 1996 10:49:49 -0500 (EST) Received: from puli.cisco.com(171.69.1.174) by gauntlet.fv.com via smap (3.2) id xma005594; Tue, 17 Dec 96 07:49:39 -0800 Received: from [171.69.128.42] (gryphon.cisco.com [171.69.128.42]) by puli.cisco.com (8.6.12/8.6.5) with ESMTP id HAA01401 for ; Tue, 17 Dec 1996 07:49:02 -0800 X-Sender: bstewart@puli.cisco.com Message-Id: In-Reply-To: <199612171412.JAA06936@mail.htconn.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-pression: awestruck amazement Date: Tue, 17 Dec 1996 10:47:58 -0500 To: agentx@fv.com From: Bob Stewart Subject: Re: comments by Jeff Johnson - RMON MIB Circa 9:12 AM -0500 12/17/96, T. Max Devlin bitwhacked: >And it is my honest opinion that there is no justification whatsoever for >supporting >RMON with an extensible agent. Would anyone ever build a network device for an open system and supply RMON capability along with the necessary driver? What if you had two of those on your open system? Would that be a case of extensible RMON? I don't know. I'm just asking. Bob   Delivery-Date: Tue, 17 Dec 1996 08:15:42 -0800 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.5/8.7.3) id IAA08459 for X-agentx; Tue, 17 Dec 1996 08:15:42 -0800 (PST) Received: from gauntlet.fv.com (gauntlet.fv.com [207.67.199.118]) by fv.com (8.7.5/8.7.3) with ESMTP id IAA08452 for ; Tue, 17 Dec 1996 08:15:41 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.7.5/8.7.3) id LAA06920 for ; Tue, 17 Dec 1996 11:15:59 -0500 (EST) Received: from shekel.fv.com(207.67.199.130) by gauntlet.fv.com via smap (3.2) id xma006890; Tue, 17 Dec 96 08:15:31 -0800 Received: from gauntlet.fv.com (gauntlet-in.fv.com [10.0.0.2]) by shekel.fv.com (8.7.5/8.7.3) with ESMTP id IAA04170 for ; Tue, 17 Dec 1996 08:16:08 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.7.5/8.7.3) id LAA06880 for ; Tue, 17 Dec 1996 11:15:29 -0500 (EST) Received: from mail13.digital.com(192.208.46.30) by gauntlet.fv.com via smap (3.2) id xma006847; Tue, 17 Dec 96 08:15:17 -0800 Received: from hunch.zk3.dec.com by mail13.digital.com (8.7.5/UNX 1.5/1.0/WV) id KAA29039; Tue, 17 Dec 1996 10:20:25 -0500 (EST) Received: from bernie.zk3.dec.com by hunch.zk3.dec.com; (5.65v3.2/1.1.8.2/11Mar96-0342PM) id AA20740; Tue, 17 Dec 1996 10:20:18 -0500 Received: from localhost by bernie.zk3.dec.com; (5.65/1.1.8.2/22Aug96-1117AM) id AA06524; Tue, 17 Dec 1996 10:23:55 -0500 Message-Id: <9612171523.AA06524@bernie.zk3.dec.com> To: jjohnson@cisco.com Cc: agentx@fv.com Subject: Re: Handling Scalar Objects Date: Tue, 17 Dec 96 10:23:55 -0500 From: Mike Daniele X-Mts: smtp Jeff, >Unlike table objects where a given instance of an object typically >resides on a single subagent, scalar objects typically represent global >data which may be shared among multiple (or all) subagents. The current >agentx draft has no support for scalar objects. Consider the scalar >ifNumber. The agentx draft uses the ifTable in many of its examples to >demonstrate how agentx works, and yet inexplicably ignores ifNumber. In >reality the value for the global ifNumber is the sum of the individual >ifNumber values maintained by each subagent supporting the ifTable. But >there is no mechanism in agentx to support this summation. Unionized registration (at least as it's been discussed so far) does not handle this, since the master agent has no way to differentiate a) "things that multiple subagents implement but I should pick a single returned value" from b) "things that multiple subagents share and I should sum up all returned values". Unionized registration had been defined in terms of a). Do you have a suggestion? A different type of (aggregrate) registration? Thanks, Mike - ---------------- This e-mail message was sent to all subscribers to the agentx mailing list. To unsubscribe from this mailing list, please send mail to: agentx-request@fv.com with Subject: unsubscribe your.address@your.domain (NOTE: Please do not reply to this message to unsubscribe. You must send your request to agentx-request@fv.com Thank you.) ------- End of Forwarded Message   Delivery-Date: Tue, 17 Dec 1996 10:01:22 -0800 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.5/8.7.3) id KAA17700 for X-agentx; Tue, 17 Dec 1996 10:01:22 -0800 (PST) Received: from gauntlet.fv.com (gauntlet.fv.com [207.67.199.118]) by fv.com (8.7.5/8.7.3) with ESMTP id KAA17697 for ; Tue, 17 Dec 1996 10:01:22 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.7.5/8.7.3) id NAA14362 for ; Tue, 17 Dec 1996 13:01:40 -0500 (EST) Received: from shekel.fv.com(207.67.199.130) by gauntlet.fv.com via smap (3.2) id xma014325; Tue, 17 Dec 96 10:01:11 -0800 Received: from gauntlet.fv.com (gauntlet-in.fv.com [10.0.0.2]) by shekel.fv.com (8.7.5/8.7.3) with ESMTP id KAA11886 for ; Tue, 17 Dec 1996 10:01:48 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.7.5/8.7.3) id NAA14318 for ; Tue, 17 Dec 1996 13:01:10 -0500 (EST) Received: from stratacom.strata.com(204.179.0.2) by gauntlet.fv.com via smap (3.2) id xma014267; Tue, 17 Dec 96 10:00:41 -0800 Received: from Strata.COM (kiwi.strata.com) by stratacom.strata.com (4.1/SMI-4.1/Gatekeeper.Strata.Com-950201) id AA26281; Tue, 17 Dec 96 10:00:20 PST Received: from farley.strata.com by Strata.COM (4.1/SMI-4.1/StrataCom-GCA-Kiwi-961130-1) id AA28313; Tue, 17 Dec 96 10:00:19 PST Received: from santa.strata.com by farley.strata.com (SMI-8.6/SMI-SVR4) id JAA18039; Tue, 17 Dec 1996 09:59:39 -0800 Received: from marvell.strata.com by santa.strata.com (4.1/SMI-4.1/StrataCom-GCA-SunClient-LOCAL-931101) id AA21265; Tue, 17 Dec 96 10:00:18 PST Date: Tue, 17 Dec 96 10:00:18 PST From: dfrancis@stratacom.com (Dale Francisco) Message-Id: <9612171800.AA21265@santa.strata.com> To: daniele@zk3.dec.com Subject: Re: Handling Scalar Objects Cc: jjohnson@cisco.com, agentx@fv.com In order to handle 'ifNumber' and similar objects, clearly there has to be a tweak to the protocol, since only the subagents know which variables are of this 'aggregate' type, and only the master agent is capable of aggregating the individual values returned by multiple subagents. Seems like the minimal change to the current registration process would be to add an AGGREGATE flag to h.flags. A subagent could then register a fully-qualified instance of ifNumber, with the INSTANCE_REGISTER and AGGREGATE bits in h.flags set. I guess we'd also have to refine our idea of duplicate registration, so that identical objects registered with the same context and at the same priority are duplicates unless the AGGREGATE flag is set. Dale   Delivery-Date: Tue, 17 Dec 1996 13:19:50 -0800 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.5/8.7.3) id NAA06514 for X-agentx; Tue, 17 Dec 1996 13:19:50 -0800 (PST) Received: from gauntlet.fv.com (gauntlet.fv.com [207.67.199.118]) by fv.com (8.7.5/8.7.3) with ESMTP id NAA06511 for ; Tue, 17 Dec 1996 13:19:49 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.7.5/8.7.3) id QAA26738 for ; Tue, 17 Dec 1996 16:20:07 -0500 (EST) Received: from shekel.fv.com(207.67.199.130) by gauntlet.fv.com via smap (3.2) id xma026709; Tue, 17 Dec 96 13:19:41 -0800 Received: from gauntlet.fv.com (gauntlet-in.fv.com [10.0.0.2]) by shekel.fv.com (8.7.5/8.7.3) with ESMTP id NAA26076 for ; Tue, 17 Dec 1996 13:20:15 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.7.5/8.7.3) id QAA26695 for ; Tue, 17 Dec 1996 16:19:36 -0500 (EST) Received: from mail.htconn.com(38.245.21.2) by gauntlet.fv.com via smap (3.2) id xma026677; Tue, 17 Dec 96 13:19:28 -0800 Received: from tmax.htconn.com by mail.htconn.com (SMI-8.6/SMI-SVR4) id QAA08794; Tue, 17 Dec 1996 16:18:27 -0500 Date: Tue, 17 Dec 1996 16:18:27 -0500 From: devlinm@mail.htconn.com (T. Max Devlin) Message-Id: <199612172118.QAA08794@mail.htconn.com> To: bstewart@cisco.com, agentx@fv.com Subject: Re: comments by Jeff Johnson - RMON MIB X-Mailer: ProntoIP [version 2.0] MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit > Circa 9:12 AM -0500 12/17/96, T. Max Devlin bitwhacked: > >And it is my honest opinion that there is no > >justification whatsoever for > >supporting > >RMON with an extensible agent. > > Would anyone ever build a network device > for an open system and supply RMON > capability along with the necessary driver? > What if you had two of those > on your open system? Would that be a case of extensible RMON? > > I don't know. I'm just asking. > > Bob Hmmm, yea. This is where it gets sticky. Because I see the point, of course. Let's say that, what with the advances in ASICs over the last few years, someone build an RMON agent onto the NIC card itself. If they supported agentx, then the scenario makes sense. The real key, though, is not how many probes (or agents) there are, but how many networks (monitored entities). If both of these devices are connected to the same segment, than a feasible agentx implementation would have one of them priority register the entire RMON MIB. If they are on two separate segments, then they need to register rows in various RMON tables which use interface number (not ifIndex; this is RMON interface, that is, "probe number"). Actually, I think that could work, with each sub-agent registering each table, as appropriate, according to the interface number. But I haven't made an examination of the MIB to check for problems with this approach. My more complete sentiment would be that such a scenario is broken by design. RMON implements a probe to monitor a LAN, not the device the agent is running on. I don't see any reason to buy RMON probes that I don't need; building enhanced management functionality into hardware is a cost analysis I am not convinced has been solved. If it is a matter of wanting redundancy, the probes should be implemented on separate hosts. As you can tell, I haven't worked out all the issues, but my instincts tell me that having more than one RMON entity at any one transport address just doesn't make sense from a network management perspective. It would be expensive without giving any real benefit. So the answer to your question "would anyone ever build..." is not really appropriate, Bob. If they could convince some poor shmuck that it will solve all their network problems, then they can sell it. If they can sell it, then they will build it. Is it a viable way of running network management operations? IHMO, the answer is NO. -- T. Max Devlin Hi-TECH Connections Voice:(610)372-1401x233 Fax:(610)372-1805 tmax@htconn.com -[Opinions expressed are my own; everyone else, including my employer, has to pay for them, subject to applicable licensing agreement]-   Delivery-Date: Wed, 18 Dec 1996 09:39:22 -0800 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.5/8.7.3) id JAA20350 for X-agentx; Wed, 18 Dec 1996 09:39:21 -0800 (PST) Received: from gauntlet.fv.com (gauntlet.fv.com [207.67.199.118]) by fv.com (8.7.5/8.7.3) with ESMTP id JAA20345 for ; Wed, 18 Dec 1996 09:39:20 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.7.5/8.7.3) id MAA06275 for ; Wed, 18 Dec 1996 12:39:36 -0500 (EST) Received: from shekel.fv.com(207.67.199.130) by gauntlet.fv.com via smap (3.2) id xma006227; Wed, 18 Dec 96 09:39:08 -0800 Received: from gauntlet.fv.com (gauntlet-in.fv.com [10.0.0.2]) by shekel.fv.com (8.7.5/8.7.3) with ESMTP id JAA05934 for ; Wed, 18 Dec 1996 09:39:46 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.7.5/8.7.3) id MAA06218 for ; Wed, 18 Dec 1996 12:39:06 -0500 (EST) Received: from unknown(198.92.30.35) by gauntlet.fv.com via smap (3.2) id xma006204; Wed, 18 Dec 96 09:38:52 -0800 Received: from manatee.cisco.com (manatee.cisco.com [171.69.131.101]) by bubbuh.cisco.com (8.7.6/CISCO.GATE.1.1) with SMTP id JAA07878 for ; Wed, 18 Dec 1996 09:38:24 -0800 (PST) Message-ID: <32B82BF4.2D86@cisco.com> Date: Wed, 18 Dec 1996 09:37:56 -0800 From: "Jeffrey T. Johnson" Organization: cisco Systems, Inc. X-Mailer: Mozilla 3.0 (Win95; I) MIME-Version: 1.0 To: agentx@fv.com Subject: Re: Handling Scalar Objects References: <9612171800.AA21265@santa.strata.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit good, i don't have to be the solution guy ;-) Dale Francisco wrote: > Seems like the minimal change to the current registration > process would be to add an AGGREGATE flag to h.flags. > A subagent could then register a fully-qualified instance > of ifNumber, with the INSTANCE_REGISTER and AGGREGATE bits > in h.flags set. I guess we'd also have to refine our > idea of duplicate registration, so that identical > objects registered with the same context and at the same > priority are duplicates unless the AGGREGATE flag is set.   Delivery-Date: Wed, 18 Dec 1996 09:39:22 -0800 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.5/8.7.3) id JAA20353 for X-agentx; Wed, 18 Dec 1996 09:39:21 -0800 (PST) Received: from gauntlet.fv.com (gauntlet.fv.com [207.67.199.118]) by fv.com (8.7.5/8.7.3) with ESMTP id JAA20348 for ; Wed, 18 Dec 1996 09:39:21 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.7.5/8.7.3) id MAA06274 for ; Wed, 18 Dec 1996 12:39:37 -0500 (EST) Received: from shekel.fv.com(207.67.199.130) by gauntlet.fv.com via smap (3.2) id xma006228; Wed, 18 Dec 96 09:39:08 -0800 Received: from gauntlet.fv.com (gauntlet-in.fv.com [10.0.0.2]) by shekel.fv.com (8.7.5/8.7.3) with ESMTP id JAA05936 for ; Wed, 18 Dec 1996 09:39:47 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.7.5/8.7.3) id MAA06217 for ; Wed, 18 Dec 1996 12:39:07 -0500 (EST) Received: from unknown(198.92.30.35) by gauntlet.fv.com via smap (3.2) id xma006202; Wed, 18 Dec 96 09:38:48 -0800 Received: from manatee.cisco.com (manatee.cisco.com [171.69.131.101]) by bubbuh.cisco.com (8.7.6/CISCO.GATE.1.1) with SMTP id JAA07874 for ; Wed, 18 Dec 1996 09:38:20 -0800 (PST) Message-ID: <32B82B95.5E5@cisco.com> Date: Wed, 18 Dec 1996 09:36:21 -0800 From: "Jeffrey T. Johnson" Organization: cisco Systems, Inc. X-Mailer: Mozilla 3.0 (Win95; I) MIME-Version: 1.0 To: agentx@fv.com Subject: Re: Handling Scalar Objects References: <9612171523.AA06524@bernie.zk3.dec.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mike Daniele wrote: > Unionized registration (at least as it's been discussed so far) does not > handle this, since the master agent has no way to differentiate > a) "things that multiple subagents implement but I should pick a single > returned value" from b) "things that multiple subagents share and I should > sum up all returned values". i concur > Unionized registration had been defined in terms of a). correct > Do you have a suggestion? A different type of (aggregrate) registration? suggesting solutions is really stepping outside my area of expertise, but yes, I suppose you need an aggregate registration mechanism. /jeff   Delivery-Date: Wed, 18 Dec 1996 11:16:15 -0800 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.5/8.7.3) id LAA28821 for X-agentx; Wed, 18 Dec 1996 11:16:14 -0800 (PST) Received: from gauntlet.fv.com (gauntlet.fv.com [207.67.199.118]) by fv.com (8.7.5/8.7.3) with ESMTP id LAA28815 for ; Wed, 18 Dec 1996 11:16:13 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.7.5/8.7.3) id OAA12751 for ; Wed, 18 Dec 1996 14:16:28 -0500 (EST) Received: from shekel.fv.com(207.67.199.130) by gauntlet.fv.com via smap (3.2) id xma012717; Wed, 18 Dec 96 11:15:58 -0800 Received: from gauntlet.fv.com (gauntlet-in.fv.com [10.0.0.2]) by shekel.fv.com (8.7.5/8.7.3) with ESMTP id LAA14125 for ; Wed, 18 Dec 1996 11:16:36 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.7.5/8.7.3) id OAA12690 for ; Wed, 18 Dec 1996 14:15:56 -0500 (EST) Received: from unknown(198.92.30.35) by gauntlet.fv.com via smap (3.2) id xma012647; Wed, 18 Dec 96 11:15:37 -0800 Received: from manatee.cisco.com (manatee.cisco.com [171.69.131.101]) by bubbuh.cisco.com (8.7.6/CISCO.GATE.1.1) with SMTP id LAA08679 for ; Wed, 18 Dec 1996 11:15:18 -0800 (PST) Message-ID: <32B83F1A.2460@cisco.com> Date: Wed, 18 Dec 1996 10:59:38 -0800 From: "Jeffrey T. Johnson" Organization: cisco Systems, Inc. X-Mailer: Mozilla 3.0 (Win95; I) MIME-Version: 1.0 To: agentx@fv.com Subject: Re: comments by Jeff Johnson - RMON MIB References: <199612171412.JAA06936@mail.htconn.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bob Stewart wrote: > > Circa 9:12 AM -0500 12/17/96, T. Max Devlin bitwhacked: > >And it is my honest opinion that there is no justification whatsoever for > >supporting > >RMON with an extensible agent. > > Would anyone ever build a network device for an open system and supply RMON > capability along with the necessary driver? What if you had two of those > on your open system? Would that be a case of extensible RMON? > > I don't know. I'm just asking. That was the exact scenario I envisioned. Dunno if it is theoretical or practical. But keep one thing in mind. It used to be that the fabric of the network was composed of closed systems, and open systems were only at the periphery. But there are multiple companies that are trying to chage that, and put open systems in the fabric. I sincerely believe that these systems will have rmon capability, and further believe that there will be systems with multiple rmon-capable adapters. Since those are my companies competitors, perhaps I shouldn't be trying to help them. /jeff   Delivery-Date: Wed, 18 Dec 1996 11:16:15 -0800 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.5/8.7.3) id LAA28823 for X-agentx; Wed, 18 Dec 1996 11:16:14 -0800 (PST) Received: from gauntlet.fv.com (gauntlet.fv.com [207.67.199.118]) by fv.com (8.7.5/8.7.3) with ESMTP id LAA28817 for ; Wed, 18 Dec 1996 11:16:14 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.7.5/8.7.3) id OAA12753 for ; Wed, 18 Dec 1996 14:16:28 -0500 (EST) Received: from shekel.fv.com(207.67.199.130) by gauntlet.fv.com via smap (3.2) id xma012721; Wed, 18 Dec 96 11:15:59 -0800 Received: from gauntlet.fv.com (gauntlet-in.fv.com [10.0.0.2]) by shekel.fv.com (8.7.5/8.7.3) with ESMTP id LAA14129 for ; Wed, 18 Dec 1996 11:16:36 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.7.5/8.7.3) id OAA12696 for ; Wed, 18 Dec 1996 14:15:57 -0500 (EST) Received: from unknown(198.92.30.35) by gauntlet.fv.com via smap (3.2) id xma012648; Wed, 18 Dec 96 11:15:38 -0800 Received: from manatee.cisco.com (manatee.cisco.com [171.69.131.101]) by bubbuh.cisco.com (8.7.6/CISCO.GATE.1.1) with SMTP id LAA08672 for ; Wed, 18 Dec 1996 11:15:15 -0800 (PST) Message-ID: <32B83BE0.25F6@cisco.com> Date: Wed, 18 Dec 1996 10:45:52 -0800 From: "Jeffrey T. Johnson" Organization: cisco Systems, Inc. X-Mailer: Mozilla 3.0 (Win95; I) MIME-Version: 1.0 To: agentx@fv.com Subject: Re: Unionized Registration Requirement References: <9612162259.AA06346@bernie.zk3.dec.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mike Daniele wrote: > >Although the current draft allows a subagent to register non-qualified = > >support for a table (i.e. without any instance information), in reality = > >such registrations will be useless. > > Many a unix gated would be happy to register ipRouteTable out from > under another subagent's mib-2 registration ... > In the context of sharing tables, yes I agree it is not useful. Not only is it not useful, it's harmful (for lack of a better word), since you're hiding information that should otherwise be available. That's one of the things that first stuck me when I read the draft, especially the example in section 7.1.5 (processing the agentx-Register-PDU) where subagent S2 registered `ip' and subagent S1 subsequently registered `ipNetToMediaTable', thereby hiding S2's entires in the ipNetToMediaTable without either S2 or the NMS knowing about it, except perhaps via an agentx mib. > >Unfortunately, even the above examples can cause a lot of overhead for = > >both the master agent and subagent. Consider a subagent on a Network = > >Interface Card containing 128 interfaces. > > Jeff, which of the following 2 categories applies to this NIC? > > >To: agentx@fv.com > >Subject: draft-ietf-agentx-ext-pro-01.txt problems > > >When evaluating the document, I took off my normal hat as a developer of = > >embedded agent/subagent software, and instead examined the problems of a = > >developer trying to interface his product with other products in an open = > >system such as a workstation. In particular, I was interested in two = > >classes of products: > >1) software applications running on the workstation > >2) hardware products with on-board subagents being plugged into the = > > workstation > > >AgentX is of course not limited to these environments, but I do feel = > >that this is where it is most applicable. > > Are you saying it's common to plug into a "workstation" a NIC that > supports 128 interfaces? I think you forgot to take your hat off :-) Well, in my current role I don't work on adapters that plug into workstations (although other portions of my company does), so this truely wasn't from my current perspective, but was from a perspective I had at a previous company where we were building multi-port workstation adapters . OK, I admit that 128 interfaces is definitely not common, but who knows what Microsoft/Intel/Compaq have up their sleeves (I don't know because for some strange reason their marketing folkks won't tell me ;-) > I agree completely with the focus of your evaluation. > I seem to arrive at different conclusions. that is fine. > >Unfortunately, there are tables which = > >might be useful in a subagent environment for which no portion of the = > >instance information is static. Consider the MIB-II ipRouteTable, which = > >is indexed by ipRouteDest. This index value is not arbitrary and is not = > >specific to a subagent. With the current registration scheme, since two = > >routing subagents cannot both register for "ipRouteTable", they must = > >register ipRouteEntry.1-13.a.b.c.d for every ip route, and must = > >constantly register and deregister individual instances as the routing = > >tables change. On Internet connected devices, this can result in tens = > >of thousands of entries registered with the master agent, with multiple = > >changes every second, resulting in more administrative traffic than pdu = > >traffic between master agent and subagent. This would seem to indicate = > >that the decision to not support non-unionized registrations might not = > >be optimal. > > I am not aware of any real-world situations in which the ipRouteTable > needs to be shared between multiple subagents. Are you? > > Certainly NICs don't know about ip routes, right? the company i worked at previously offloaded TCP/IP onto the adapter. So the workstation itself would have a complete IP stack, as would each adapter plugged into the workstation. Since there was no way to integrate our instrumentation with the instrumentation on the workstation, we ended up having full snmp agents running on the adapters, and they were completely separately managable. This has its good points and bad points. The good point is that when a management station is talking directly to an adapter, it knows who it is talking, whereas when it is talking to a workstation running extensible agent technology, all it kows is that the data is coming from the workstation, and not necessarily from which adapter. The bad point is that when the management station wanted a composite collection of data from the workstation, it had to query multiple agents and compile the composite itself. Note that having separate agents also gave most autodiscovery programs a headache. If we had extensible agent technology at the time, I suspect that each adapter would register all of its mibs twice, once in the default context so that it's instrumentation would be part of the composite, and once in a unique context so that the adapter would be separately managable when desired. > And if there are 2 subagents running on a system that each > wish to register ipRouteTable, one of them is successful and > one of them is not. This seems like the correct behavior to me. And lose half your routing information? > >So here is the show stopper. Without unionized = > >registrations, there is no way to support row creation in arbitrarily = > >indexed tables. > > This is true. The argument that was made on this list > during previous discussions went something like this: > > One subagent registers the table, and as such receives all > requests for row creation. It forks/starts other subagents > that each manage (register) a (newly created) row in the table. > > Note also that this mechanism would permit the first (overseer) > subagent to implement a scalar that counts the number of entries > in the table. > > It seems that this scheme would work only within a solution > delivered by a single, or cooperating, vendors. But that seemed to > be the case whenever it was discussed. > > I'd be interested in your thoughts on this idea. I find this problematic for several reasons. The first is that this pushes a lot of complexity into subagents. Using this scheme, every subagent that supports such row creation would have to be capable of acting in the arbiter role since it may be the only subagent in the system that supports the table. So every subagent must be capable of handling the create request, and then spawing/starting an associated subagent to handle the row. The second problem is this spawing/starting action. If agentx doesn't define the mechanism, then you are back to proprietary solutions and agentx hasn't gained you anything. And note that the mechanism by which different subagents in a box talk to the master agent may differ. For example, a workstation master agent may use RPC to talk to an application, but use TCP to talk to an adapter. If I had a rmon daemon that ran on /dev/nit as well as rmon capability in an adapter, then the rmon daemon would have to know how to talk to the adapter and the adapter would have to know how to talk to the daemon. In reality, only the master agent should need to know how to talk to subagents. > >Consider the RMON-MIB. If an application wants to create a history = > >study, it does so by creating a row in the historyControlTable. This = > >table is indexed by historyControlIndex, an arbitrary index. Since the = > >index is arbitrary, a subagent cannot register for it beforehand. The = > >only way that the historyControlTable (or any other RMON control table) = > >can be supported is if unionized registration is allowed. > > This might be a showstopper, but I don't understand it enough to know. > Could you explain how subagents share the implementation of RMON > mib? My colleagues at Bay could probably provide better implementation experience, but this is my experience. With extensible agent technology that supports unionized registration, each rmon-capable "card" registers support for the entire rmon mib with the master agent. When a set request comes into the master agent, if it specifies an instance that has not been explicitly registered (such as during row creation) it sends a test message to every subagent. Each subagent examines the varbinds to see if it is capable of creating the row, specificially by examining the data source object to see if the subagent is the owner of the data source. If so, the subagent passes the test, and if not, the subagent fails the test. The master agent collects the test results, of which there are three possibilities. 1) no subagent passed the test, in which case the master agent returns the appropriate error, 2) one subagent passed the test, in which case the remainder of the set processing takes place between the master agent and this one subagent, or 3) multiple subagents passed the test, in which case you're hosed. If multiple subagents think they ca create a given row, I suppose you just pick one. > When this was being debated previously, I asked: > > >Would it be possible to supply a specific example how this feature > >(permitting multiple subagents to register the same oid) is used/required > >in order for subagents to implement a table that is split across subagents? > > >What I'm really trying to get at is this: Is it useful/required because > > >a) These companies implement tables that CANNOT reasonably be split > > across subagents WITHOUT this feature. That is, the table's indexing > > structure and/or the nature of the data make it impossible to > > partition the table so that each subagent gets unique sections? > > (If so, an example of this would be vey helpful.) > > >or > > >b) These companies implement subagents that each "take the easy way out" > > and register the entire table, and expect the master agent to figure > > things out. (Perhaps this is reality and it's naive to expect otherwise...) > > The response was > > >Sure. The clasic example is the Interfaces table. These days, interfaces > >can come as loadable software drivers, plug-in hardware, or both. Are you > >going to require every interface hardware/software vendor to reserve a chunk > >of ifIndex space so that their subagents can pre-register which instance > >they will support? > > I think there is general agreement that this case can be handled > with index allocation and instance-level registration. > > If the vendors are going to ship NICs that register ifTable, > can't they ship NICs that allocate an ifindex and then register > a row (or rows) of ifTable? > > In general (and to the best of my recollection :-), no one > came forth with a concrete example of a MIB table that really > will/must be shared by generic multivendor subagents, and > that cannot be reasonably partitioned according to the draft. > > In addition, several individuals were concerned about the added > complexity, and the lack of "data integrity" (different subagents > implementing the same variable at different times, etc). > > Given all this, it didn't survive. > > To some extent I've been playing devil's advocate in this mail, > but I really would like to see an example that shows us unionized > registration is absolutely necessary for successful deployment > of AgentX subagents. For instance, > > - NIC vendors can't implement media-specific mib > without unionized registrations, because ... > > - Software vendors can't implement mib because ... > > If you HAVE given such an example and I'm too thick to get it, > please keep trying. I really think the rmon mib (or any other mib with arbitrarily-indexed tables which support row creation) will be impossible to implement using the current agentx protocol. Now it's another thread as to whether or not rmon support is necessary. /jeff   Delivery-Date: Wed, 18 Dec 1996 11:16:16 -0800 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.5/8.7.3) id LAA28833 for X-agentx; Wed, 18 Dec 1996 11:16:15 -0800 (PST) Received: from gauntlet.fv.com (gauntlet.fv.com [207.67.199.118]) by fv.com (8.7.5/8.7.3) with ESMTP id LAA28825 for ; Wed, 18 Dec 1996 11:16:14 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.7.5/8.7.3) id OAA12762 for ; Wed, 18 Dec 1996 14:16:29 -0500 (EST) Received: from shekel.fv.com(207.67.199.130) by gauntlet.fv.com via smap (3.2) id xma012720; Wed, 18 Dec 96 11:15:59 -0800 Received: from gauntlet.fv.com (gauntlet-in.fv.com [10.0.0.2]) by shekel.fv.com (8.7.5/8.7.3) with ESMTP id LAA14135 for ; Wed, 18 Dec 1996 11:16:37 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.7.5/8.7.3) id OAA12704 for ; Wed, 18 Dec 1996 14:15:57 -0500 (EST) Received: from unknown(198.92.30.35) by gauntlet.fv.com via smap (3.2) id xma012660; Wed, 18 Dec 96 11:15:43 -0800 Received: from manatee.cisco.com (manatee.cisco.com [171.69.131.101]) by bubbuh.cisco.com (8.7.6/CISCO.GATE.1.1) with SMTP id LAA08683 for ; Wed, 18 Dec 1996 11:15:19 -0800 (PST) Message-ID: <32B842AE.10E1@cisco.com> Date: Wed, 18 Dec 1996 11:14:54 -0800 From: "Jeffrey T. Johnson" Organization: cisco Systems, Inc. X-Mailer: Mozilla 3.0 (Win95; I) MIME-Version: 1.0 To: agentx@fv.com Subject: Re: comments by Jeff Johnson - RMON MIB References: <199612172118.QAA08794@mail.htconn.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit T. Max Devlin wrote: > Actually, I think that could work, with each sub-agent registering each > table, as appropriate, according to the interface number. But I haven't > made an examination of the MIB to check for problems with this approach. the "problem" with the rmon mib is that the interface number isn't part of the table indexing. the rmon mib is indexed by an arbitrary integer, and it is another (non-index) field in the table, the data source, which specifies the interface to be monitored. so a subagent has to look at this data source to determine if it supports the individual entry in the row. > My more complete sentiment would be that such a scenario is broken by > design. RMON implements a probe to monitor a LAN, not the device the > agent is running on. I don't see any reason to buy RMON probes that I > don't need; building enhanced management functionality into hardware is a > cost analysis I am not convinced has been solved. If it is a matter of > wanting redundancy, the probes should be implemented on separate hosts. well, the market is demanding rmon in just about every network device. Heck, they're demanding rmon in routers, and routers, by design, don't even see all the packets on a shared media. go figure. but there is also one important feature of rmon that is overlooked, and that's the events and alarms. these actually *do* allow monitoring of the device and not the lan (provided that your implementation allows examination of mib objects outside the rmon mib). I can see a very real justification for just supporting these two groups on *any* managed device since it allows application-defined thresholding to be applied to just about any mib object. > As you can tell, I haven't worked out all the issues, but my instincts > tell me that having more than one RMON entity at any one transport address > just doesn't make sense from a network management perspective. It would > be expensive without giving any real benefit. well, i guess we just disagree on this point. that is fine. > So the answer to your question "would anyone ever build..." is not really > appropriate, Bob. If they could convince some poor shmuck that it will > solve all their network problems, then they can sell it. If they can sell > it, then they will build it. and IMO they will > Is it a viable way of running network management operations? IHMO, the > answer is NO. (IHMO? In a Health Maintenance Organization? ;-) I really don't see the difference between having some number of individual probes scattered on the network, and having some number of probes stuck in a single box which collectively monitor the same segments of the network. And it's this latter scenario I'm picturing. /jeff   Delivery-Date: Wed, 18 Dec 1996 11:49:30 -0800 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.5/8.7.3) id LAA01488 for X-agentx; Wed, 18 Dec 1996 11:49:29 -0800 (PST) Received: from gauntlet.fv.com (gauntlet.fv.com [207.67.199.118]) by fv.com (8.7.5/8.7.3) with ESMTP id LAA01478 for ; Wed, 18 Dec 1996 11:49:28 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.7.5/8.7.3) id OAA14853 for ; Wed, 18 Dec 1996 14:49:43 -0500 (EST) Received: from shekel.fv.com(207.67.199.130) by gauntlet.fv.com via smap (3.2) id xma014824; Wed, 18 Dec 96 11:49:15 -0800 Received: from gauntlet.fv.com (gauntlet-in.fv.com [10.0.0.2]) by shekel.fv.com (8.7.5/8.7.3) with ESMTP id LAA16658 for ; Wed, 18 Dec 1996 11:49:53 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.7.5/8.7.3) id OAA14805 for ; Wed, 18 Dec 1996 14:49:13 -0500 (EST) Received: from mail11.digital.com(192.208.46.10) by gauntlet.fv.com via smap (3.2) id xma014755; Wed, 18 Dec 96 11:48:53 -0800 Received: from flume.zk3.dec.com by mail11.digital.com (8.7.5/UNX 1.5/1.0/WV) id OAA21738; Wed, 18 Dec 1996 14:34:52 -0500 (EST) Received: from bernie.zk3.dec.com by flume.zk3.dec.com; (5.65v3.2/1.1.8.2/16Jan95-0946AM) id AA16900; Wed, 18 Dec 1996 14:34:47 -0500 Received: from localhost by bernie.zk3.dec.com; (5.65/1.1.8.2/22Aug96-1117AM) id AA07242; Wed, 18 Dec 1996 14:38:27 -0500 Message-Id: <9612181938.AA07242@bernie.zk3.dec.com> To: "Jeffrey T. Johnson" Cc: agentx@fv.com Subject: Re: Support for Persistency In-Reply-To: Your message of "Sun, 15 Dec 96 23:10:38 PST." <32B4F5EE.50D3@cisco.com> Date: Wed, 18 Dec 96 14:38:26 -0500 From: Mike Daniele X-Mts: smtp Jeff, >One mechanism is quite simple. When a master agent powers up, it >ignores (or postpones) responding to agentx-IndexAllocate-PDU which >specify NEW_INDEX or ANY_INDEX. This allows subagents which want a >specific index to power up and request the index before it has been = >arbitrarily assigned to another subagent. Although it's talking about how to use the protocol instead of defining it, it makes sense to me to add some text suggesting subagents save their allocated indexes and attempt to allocate them specifically when restarting, to avoid the proliferation of "renumbering". I'm less enthusiastic about prescribing master agent behavior. If the subs do the right thing, and no new subagents are present since the last boot, the master need do nothing special. Implementations might choose to queue up NEW or ANY_INDEX requests, or simply to respond to them starting with values > any that were allocated before the reboot. >The second mechanism is more complex. If a subagent requests a given >index, and it has already been arbitrarily assigned to another subagent, >but if that subagent has not sent or received any agentx PDUs which >utilize the given index, then the master agent can take back the index >and reassign a new one. This is much more complex. Ouch! I'd hate to have to code that, much less write it up :-) Mike   Delivery-Date: Wed, 18 Dec 1996 12:15:16 -0800 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.5/8.7.3) id MAA03971 for X-agentx; Wed, 18 Dec 1996 12:15:15 -0800 (PST) Received: from gauntlet.fv.com (gauntlet.fv.com [207.67.199.118]) by fv.com (8.7.5/8.7.3) with ESMTP id MAA03966 for ; Wed, 18 Dec 1996 12:15:15 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.7.5/8.7.3) id PAA16796 for ; Wed, 18 Dec 1996 15:15:30 -0500 (EST) Received: from shekel.fv.com(207.67.199.130) by gauntlet.fv.com via smap (3.2) id xma016783; Wed, 18 Dec 96 12:15:00 -0800 Received: from gauntlet.fv.com (gauntlet-in.fv.com [10.0.0.2]) by shekel.fv.com (8.7.5/8.7.3) with ESMTP id MAA18434 for ; Wed, 18 Dec 1996 12:15:38 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.7.5/8.7.3) id PAA16780 for ; Wed, 18 Dec 1996 15:14:59 -0500 (EST) Received: from ns1.baynetworks.com(134.177.3.20) by gauntlet.fv.com via smap (3.2) id xma016776; Wed, 18 Dec 96 12:14:42 -0800 Received: from lobster1.corpeast.Baynetworks.com (lobster1.corpeast.baynetworks.com [192.32.72.17]) by mailhost2.BayNetworks.COM (8.8.3/BNET-96/12/06-E) with SMTP id MAA01403 Posted-Date: Wed, 18 Dec 1996 12:12:18 -0800 (PST) Received: from chianti.engeast by lobster1.corpeast.Baynetworks.com (4.1/SMI-4.1) id AA19257; Wed, 18 Dec 96 15:13:45 EST Received: from chianti (localhost) by chianti.engeast (4.1/SMI-4.1) id AA03090; Wed, 18 Dec 96 15:11:09 EST Sender: lcabeca@BayNetworks.COM Message-Id: <32B84FDB.60E33853@BayNetworks.com> Date: Wed, 18 Dec 1996 15:11:07 -0500 From: Linda Cabeca X-Mailer: Mozilla 2.0 (X11; I; SunOS 4.1.3_U1 sun4m) Mime-Version: 1.0 To: "Jeffrey T. Johnson" Cc: agentx@fv.com Subject: Re: Unionized Registration Requirement References: <9612162259.AA06346@bernie.zk3.dec.com> <32B83BE0.25F6@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Jeffrey T. Johnson wrote: > > My colleagues at Bay could probably provide better implementation > experience, but this is my experience. With extensible agent technology > that supports unionized registration, each rmon-capable "card" registers > support for the entire rmon mib with the master agent. When a set > request comes into the master agent, if it specifies an instance that > has not been explicitly registered (such as during row creation) it > sends a test message to every subagent. Each subagent examines the > varbinds to see if it is capable of creating the row, specificially by > examining the data source object to see if the subagent is the owner of > the data source. If so, the subagent passes the test, and if not, the > subagent fails the test. The master agent collects the test results, of > which there are three possibilities. 1) no subagent passed the test, in > which case the master agent returns the appropriate error, 2) one > subagent passed the test, in which case the remainder of the set > processing takes place between the master agent and this one subagent, > or 3) multiple subagents passed the test, in which case you're hosed. > If multiple subagents think they ca create a given row, I suppose you > just pick one. Jeff pretty much hit the nail on the head with how we handle registration here at Bay. Each SA would register with no instance information. When a set came in, each SA would receive it. Only those SA's that care about the row would respond to the test phase. Now we do have the special case where we have SA's that support the same columns of the same rows on different slots of our routers. So, we can have multiple SA's respond positively to the test request. I'm sure that some of you are cringing now :-) We also have the concept of aggregation. When an SA registers with us, associated with each object is an aggregation rule. These rules can be MIN, MAX, SUM or ANY. This is how we resolve receiving multiple responses on a get request. I do have a question regarding registration. From what I read in the draft (and I may have read it wrong), it looks like only OID's are registered with the MA, there is no type or access information registered with the MA. Is this correct ? My issue is that I would rather not have to bother the SA with a request that he is immediately going to reject. Seems the MA could quickly bounce the request if he had type and access information. I would rather not waste the context switch to have the SA run and do the checking. I also have a concern about a lot of these registration problems being solved by doing an instance level registration. This seems dangerous to me because these registration tables are going to start to get huge. I believe that we need to be able to register not only at the instance level, but at the table level for row creations as well. My 2 cents, Linda > /jeff > > > ---------------- > This e-mail message was sent to all subscribers to the > agentx mailing list. > > To unsubscribe from this mailing list, please send mail to: > agentx-request@fv.com > with > Subject: unsubscribe your.address@your.domain > > (NOTE: Please do not reply to this message to unsubscribe. You must send > your request to agentx-request@fv.com Thank you.)   Delivery-Date: Wed, 18 Dec 1996 15:18:55 -0800 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.5/8.7.3) id PAA18409 for X-agentx; Wed, 18 Dec 1996 15:18:55 -0800 (PST) Received: from gauntlet.fv.com (gauntlet.fv.com [207.67.199.118]) by fv.com (8.7.5/8.7.3) with ESMTP id PAA18406 for ; Wed, 18 Dec 1996 15:18:54 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.7.5/8.7.3) id SAA26682 for ; Wed, 18 Dec 1996 18:19:12 -0500 (EST) Received: from shekel.fv.com(207.67.199.130) by gauntlet.fv.com via smap (3.2) id xma026666; Wed, 18 Dec 96 15:18:43 -0800 Received: from gauntlet.fv.com (gauntlet-in.fv.com [10.0.0.2]) by shekel.fv.com (8.7.5/8.7.3) with ESMTP id PAA00719 for ; Wed, 18 Dec 1996 15:19:22 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.7.5/8.7.3) id SAA26663 for ; Wed, 18 Dec 1996 18:18:42 -0500 (EST) Received: from bubbuh.cisco.com(198.92.30.35) by gauntlet.fv.com via smap (3.2) id xma026635; Wed, 18 Dec 96 15:18:16 -0800 Received: from manatee.cisco.com (manatee.cisco.com [171.69.131.101]) by bubbuh.cisco.com (8.7.6/CISCO.GATE.1.1) with SMTP id PAA10459 for ; Wed, 18 Dec 1996 15:17:56 -0800 (PST) Message-ID: <32B87AA4.6AD8@cisco.com> Date: Wed, 18 Dec 1996 15:13:40 -0800 From: "Jeffrey T. Johnson" Organization: cisco Systems, Inc. X-Mailer: Mozilla 3.0 (Win95; I) MIME-Version: 1.0 To: agentx@fv.com Subject: Re: Support for Persistency References: <32B4F5EE.50D3@cisco.com> <9612181938.AA07242@bernie.zk3.dec.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mike Daniele wrote: > If the subs do the right thing, and no new subagents are present > since the last boot, the master need do nothing special. correct. it's the case where new subagents are present that I was most concerned with, although I do concur that it would be nice to have text the recommends that subagents remember and reuse their index values across reboots. /jeff   Delivery-Date: Wed, 18 Dec 1996 22:56:45 -0800 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.5/8.7.3) id WAA23805 for X-agentx; Wed, 18 Dec 1996 22:56:45 -0800 (PST) Received: from gauntlet.fv.com (gauntlet.fv.com [207.67.199.118]) by fv.com (8.7.5/8.7.3) with ESMTP id WAA23802 for ; Wed, 18 Dec 1996 22:56:44 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.7.5/8.7.3) id BAA18814 for ; Thu, 19 Dec 1996 01:57:02 -0500 (EST) Received: from shekel.fv.com(207.67.199.130) by gauntlet.fv.com via smap (3.2) id xma018810; Wed, 18 Dec 96 22:56:33 -0800 Received: from gauntlet.fv.com (gauntlet-in.fv.com [10.0.0.2]) by shekel.fv.com (8.7.5/8.7.3) with ESMTP id WAA19124 for ; Wed, 18 Dec 1996 22:57:11 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.7.5/8.7.3) id BAA18805 for ; Thu, 19 Dec 1996 01:56:32 -0500 (EST) Received: from stratacom.strata.com(204.179.0.2) by gauntlet.fv.com via smap (3.2) id xma018801; Wed, 18 Dec 96 22:56:05 -0800 Received: from Strata.COM (kiwi.strata.com) by stratacom.strata.com (4.1/SMI-4.1/Gatekeeper.Strata.Com-950201) id AA11345; Wed, 18 Dec 96 22:55:48 PST Received: from farley.strata.com by Strata.COM (4.1/SMI-4.1/StrataCom-GCA-Kiwi-961130-1) id AA15336; Wed, 18 Dec 96 22:55:47 PST Received: from santa.strata.com by farley.strata.com (SMI-8.6/SMI-SVR4) id WAA12572; Wed, 18 Dec 1996 22:55:08 -0800 Received: from marvell.strata.com by santa.strata.com (4.1/SMI-4.1/StrataCom-GCA-SunClient-LOCAL-931101) id AA25022; Wed, 18 Dec 96 22:55:46 PST Date: Wed, 18 Dec 96 22:55:46 PST From: dfrancis@stratacom.com (Dale Francisco) Message-Id: <9612190655.AA25022@santa.strata.com> To: agentx@fv.com Subject: Re: San Jose IETF meeting Just a heads up: Getting the "more complete" minutes into usable written form is taking longer than I had hoped. I may not be able to finish until this weekend, but will post ASAP. Dale > I will be publishing a more-than-usually-complete set of > minutes by the end of this week, so that those who were > unable to attend will get a sense of the issues that > were discussed.   Delivery-Date: Thu, 19 Dec 1996 06:52:10 -0800 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.5/8.7.3) id GAA29105 for X-agentx; Thu, 19 Dec 1996 06:52:10 -0800 (PST) Received: from gauntlet.fv.com (gauntlet.fv.com [207.67.199.118]) by fv.com (8.7.5/8.7.3) with ESMTP id GAA29102 for ; Thu, 19 Dec 1996 06:52:09 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.7.5/8.7.3) id JAA24601 for ; Thu, 19 Dec 1996 09:52:26 -0500 (EST) Received: from shekel.fv.com(207.67.199.130) by gauntlet.fv.com via smap (3.2) id xma024596; Thu, 19 Dec 96 06:51:56 -0800 Received: from gauntlet.fv.com (gauntlet-in.fv.com [10.0.0.2]) by shekel.fv.com (8.7.5/8.7.3) with ESMTP id GAA29897 for ; Thu, 19 Dec 1996 06:52:36 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.7.5/8.7.3) id JAA24589 for ; Thu, 19 Dec 1996 09:51:55 -0500 (EST) Received: from igw3.watson.ibm.com(129.34.139.18) by gauntlet.fv.com via smap (3.2) id xma024585; Thu, 19 Dec 96 06:51:48 -0800 Received: from mailhub1.watson.ibm.com (mailhub1.watson.ibm.com [9.2.249.31]) by igw3.watson.ibm.com (8.7.6/8.7.1) with ESMTP id JAA15704; Thu, 19 Dec 1996 09:51:50 -0500 Received: from hawpub.watson.ibm.com (hawpub.watson.ibm.com [9.2.90.19]) by mailhub1.watson.ibm.com (8.8.2/11-26-96) with SMTP id JAA19308; Thu, 19 Dec 1996 09:51:18 -0500 Received: by hawpub.watson.ibm.com (AIX 3.2/UCB 5.64/6/25/96) id AA17877; Thu, 19 Dec 1996 09:51:18 -0500 From: Uri Blumenthal Message-Id: <9612191451.AA17877@hawpub.watson.ibm.com> Subject: Re: Support for Persistency To: jjohnson@cisco.com (Jeffrey T. Johnson) Date: Thu, 19 Dec 1996 09:51:17 -0500 (EST) Cc: agentx@fv.com In-Reply-To: <32B87AA4.6AD8@cisco.com> from "Jeffrey T. Johnson" at Dec 18, 96 03:13:40 pm Reply-To: uri@watson.ibm.com X-Mailer: ELM [version 2.4 PL25] Content-Type: text Jeffrey T. Johnson says: > Mike Daniele wrote: > > If the subs do the right thing, and no new subagents are present > > since the last boot, the master need do nothing special. > > correct. it's the case where new subagents are present that I was most > concerned with, although I do concur that it would be nice to have text > the recommends that subagents remember and reuse their index values > across reboots. I'm afraid I'm missing something. 1. The transport between the master and the sub' is to be reliable. 2. Therefore the sub' will definitely get a notice when the master goes away. 3. Therefore the sub' "knows" that its connection/registration is gone and it should reestablish most if not all of it at some later time. Most likely this will be done by the AgentX library itself, to relieve the application writer... So what's the big deal? -- Regards, Uri uri@watson.ibm.com -=-=-=-=-=-=-   Delivery-Date: Thu, 19 Dec 1996 09:26:19 -0800 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.5/8.7.3) id JAA11910 for X-agentx; Thu, 19 Dec 1996 09:26:18 -0800 (PST) Received: from gauntlet.fv.com (gauntlet.fv.com [207.67.199.118]) by fv.com (8.7.5/8.7.3) with ESMTP id JAA11907 for ; Thu, 19 Dec 1996 09:26:17 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.7.5/8.7.3) id MAA02765 for ; Thu, 19 Dec 1996 12:26:34 -0500 (EST) Received: from shekel.fv.com(207.67.199.130) by gauntlet.fv.com via smap (3.2) id xma002728; Thu, 19 Dec 96 09:26:05 -0800 Received: from gauntlet.fv.com (gauntlet-in.fv.com [10.0.0.2]) by shekel.fv.com (8.7.5/8.7.3) with ESMTP id JAA07546 for ; Thu, 19 Dec 1996 09:26:44 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.7.5/8.7.3) id MAA02722 for ; Thu, 19 Dec 1996 12:26:05 -0500 (EST) Received: from bubbuh.cisco.com(198.92.30.35) by gauntlet.fv.com via smap (3.2) id xma002696; Thu, 19 Dec 96 09:25:44 -0800 Received: from manatee.cisco.com (manatee.cisco.com [171.69.131.101]) by bubbuh.cisco.com (8.7.6/CISCO.GATE.1.1) with SMTP id JAA00881 for ; Thu, 19 Dec 1996 09:25:22 -0800 (PST) Message-ID: <32B97A6F.6CAC@cisco.com> Date: Thu, 19 Dec 1996 09:25:03 -0800 From: "Jeffrey T. Johnson" Organization: cisco Systems, Inc. X-Mailer: Mozilla 3.0 (Win95; I) MIME-Version: 1.0 To: agentx@fv.com Subject: Re: Support for Persistency References: <9612191451.AA17877@hawpub.watson.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Uri Blumenthal wrote: > > Jeffrey T. Johnson says: > > Mike Daniele wrote: > > > If the subs do the right thing, and no new subagents are present > > > since the last boot, the master need do nothing special. > > > > correct. it's the case where new subagents are present that I was most > > concerned with, although I do concur that it would be nice to have text > > the recommends that subagents remember and reuse their index values > > across reboots. > > I'm afraid I'm missing something. > > 1. The transport between the master and the sub' is to be reliable. > 2. Therefore the sub' will definitely get a notice when the master > goes away. > 3. Therefore the sub' "knows" that its connection/registration is > gone and it should reestablish most if not all of it at some > later time. Most likely this will be done by the AgentX > library itself, to relieve the application writer... > > So what's the big deal? Uri, if a box reboots, and your master agent and all subagent processes "die", you lose all your agentx state. reliable transports don't survive a reboot or a power down of the box. Since I guess I need to be even more specific, the exact scenario I envisioned was something like: workstation has several slots. at a given time the workstation is running an agentx MA daemon, and there is a card in one of the slots that is running an agentx SA daemon, call it S1. Further, the SA has allocated several ifIndex values, say 1 and 2. Ok, I want to add a new single-interface card to this configuration. I power down the workstation, add the new card (which contains its own embedded agentx SA daemon, call it SA2), and power the workstation back up. The MA and the two SAs start up, and begin talking to one another. SA1 will try to allocate ifIndex.1 and ifIndex.2 while SA2 will try to allocate ifIndex.NEW_INDEX. When the workstation powers up, there is no way to control whether SA1 or SA2 will try to allocate ifIndex values first. Without any control, if SA2's request is received first, the MA will allocate ifIndex.1 to SA2. In order to be end-user friendly, it is preferable to service SA1's request first since it is attempting to allocate specific ifIndex values (and hence maintain persistency). Hopefully this clarifies my objective. /jeff   Delivery-Date: Thu, 19 Dec 1996 09:57:18 -0800 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.5/8.7.3) id JAA14493 for X-agentx; Thu, 19 Dec 1996 09:57:18 -0800 (PST) Received: from gauntlet.fv.com (gauntlet.fv.com [207.67.199.118]) by fv.com (8.7.5/8.7.3) with ESMTP id JAA14488 for ; Thu, 19 Dec 1996 09:57:17 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.7.5/8.7.3) id MAA04927 for ; Thu, 19 Dec 1996 12:57:35 -0500 (EST) Received: from shekel.fv.com(207.67.199.130) by gauntlet.fv.com via smap (3.2) id xma004883; Thu, 19 Dec 96 09:57:05 -0800 Received: from gauntlet.fv.com (gauntlet-in.fv.com [10.0.0.2]) by shekel.fv.com (8.7.5/8.7.3) with ESMTP id JAA10736 for ; Thu, 19 Dec 1996 09:57:44 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.7.5/8.7.3) id MAA04874 for ; Thu, 19 Dec 1996 12:57:05 -0500 (EST) Received: from mail.htconn.com(38.245.21.2) by gauntlet.fv.com via smap (3.2) id xma004851; Thu, 19 Dec 96 09:56:48 -0800 Received: from tmax.htconn.com by mail.htconn.com (SMI-8.6/SMI-SVR4) id MAA14048; Thu, 19 Dec 1996 12:55:53 -0500 Date: Thu, 19 Dec 1996 12:55:53 -0500 From: devlinm@mail.htconn.com (T. Max Devlin) Message-Id: <199612191755.MAA14048@mail.htconn.com> To: agentx@fv.com Subject: Re: comments by Jeff Johnson - RMON MIB X-Mailer: ProntoIP [version 2.0] MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit > the "problem" with the rmon mib is that the interface number isn't part > of the table indexing. the rmon mib is indexed by an arbitrary integer, > and it is another (non-index) field in the table, the data source, > which specifies the interface to be monitored. so a subagent has to > look at this data source to determine if it supports the individual > entry in the row. Oh, yes, I remember now. But I'm still confused about your use of the terms "the rmon mib" and "the table". As far as I recall, there isn't an index for the entirety of what we refer to as the RMON MIB (1.3.6.1.2.1.16 is it?), or is that OID the arbitrary integer you were refering to (that is to say, there is no way to specify an instance of all of RMON, just an instance of a particular table within the RMON groups?). Or am I just completely befuddled and out of my league? ;-) > > > My more complete sentiment would be that such a scenario is broken by > > design. RMON implements a probe to monitor a LAN, not the device the > > agent is running on. I don't see any reason to buy RMON probes that I > > don't need; [...] > well, the market is demanding rmon in just about every network device. > Heck, they're demanding rmon in routers, and routers, by design, don't > even see all the packets on a shared media. go figure. I think there has to be a line where the engineers say that building the box the salesmen are pushing would be a stupid idea. Or have we entered "the Dilbert Zone"? For that matter, there is no device that by design sees all the packets on a shared media any more than the router does. The hub, by design, doesn't "see" any packets at all, it just repeats frames. That's really what RMON is all about; adding promiscuous mode monitoring to whatever device you want to be the "probe". A stand-alone box, a hub, a router, a server, whatever. Which simply underscores the fact that adding it to EVERYTHING just doesn't make any logical sense at all. > > but there is also one important feature of rmon that is overlooked, and > that's the events and alarms. these actually *do* allow monitoring of > the device and not the lan (provided that your implementation allows > examination of mib objects outside the rmon mib). I can see a very real > justification for just supporting these two groups on *any* managed > device since it allows application-defined thresholding to be applied to > just about any mib object. True, I didn't consider alarms and events. I can't see what difference it makes which agent or subagent generated the trap, though. As long as you know the transport address (and all the other information, like monitored object, threshold value, and sampled value, needs to be in the varbinds anyway, for a functional RMON alarm implementation) you just need to know that something happened. What difference does it make which sub-agent generated it? > >having more than one RMON entity at any one transport address > > just doesn't make sense from a network management perspective. It > > would be expensive without giving any real benefit. > > well, i guess we just disagree on this point. that is fine. I wish it were. You've already mentioned that you don't see the logic in putting RMON into every device (with the exception of the events and alarms), so I assume that you recognized the inconsistency, inefficiency, and unmanageability of multiple RMON implementations on a single LAN. It just doesn't make any sense. If you do have multiple RMON sub-agents, then one of them should "over-write" the registration of the others, as appropriate. It doesn't matter how many RMON sub-agents are on a LAN, only one should be active, so I don't see a conflict between RMON and agentx, except in the case where the implementation is broken (multiple active RMON SAs monitoring _different_ data links, but hosted at the _same_ transport address). The fact that agentx can't fix that doesn't seem to be an issue to me. IMHO, the confusion thus caused can only be belayed by a manager, not a master agent. [...] > > If they can sell > > it, then they will build it. > > and IMO they will > > > Is it a viable way of running network management operations? IHMO, the > > answer is NO. > > (IHMO? In a Health Maintenance Organization? ;-) > I really don't see the difference between having some number of > individual probes scattered on the network, and having some number of > probes stuck in a single box which collectively monitor the same > segments of the network. And it's this latter scenario I'm picturing. The point is, though, that the some number of probes do not "collectively" monitor the same segment. They independantly monitor the same segment, and are thus redundant, and blocking previous registrations is not a problem, except in the transient example of a set made to set up a certain table being executed on one subagent, with another subagent being instantiated afterwards. The second SA will act on subsequent gets, but will not have the desired information. On that basis, I'd say that proper operations requires that the first registration of equal priority be the only accepted one, which I believe is the methodology for agentx. So long as all RMON SAs register with the lowest priority for the RMON MIB, it will work fine. Newer RMON agents at the same TA will be ignored. In implementations where the TA can support probes on multiple segments (a router-based agentx RMON), the initial agent _must_ support _all_ RMON interfaces. I can't see any other way to resolve the conflict. One other note, Jeff. You've finally made me realize why I never liked the idea of putting alarms and events into RMON (in addition to the problems with agent-based thresholding and the deficiencies in the implementation [single conventional trap number for all events]). The "global" nature of this capability makes it problematic to lump it with the data link analysis purpose of RMON. Sorry for the length, but I'm excited at the opportunity for helping this effort. Happy Holidays!   Delivery-Date: Thu, 19 Dec 1996 10:01:26 -0800 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.5/8.7.3) id KAA14924 for X-agentx; Thu, 19 Dec 1996 10:01:25 -0800 (PST) Received: from gauntlet.fv.com (gauntlet.fv.com [207.67.199.118]) by fv.com (8.7.5/8.7.3) with ESMTP id KAA14921 for ; Thu, 19 Dec 1996 10:01:25 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.7.5/8.7.3) id NAA05400 for ; Thu, 19 Dec 1996 13:01:42 -0500 (EST) Received: from shekel.fv.com(207.67.199.130) by gauntlet.fv.com via smap (3.2) id xma005368; Thu, 19 Dec 96 10:01:13 -0800 Received: from gauntlet.fv.com (gauntlet-in.fv.com [10.0.0.2]) by shekel.fv.com (8.7.5/8.7.3) with ESMTP id KAA11185 for ; Thu, 19 Dec 1996 10:01:52 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.7.5/8.7.3) id NAA05344 for ; Thu, 19 Dec 1996 13:01:11 -0500 (EST) Received: from igw3.watson.ibm.com(129.34.139.18) by gauntlet.fv.com via smap (3.2) id xma005290; Thu, 19 Dec 96 10:00:51 -0800 Received: from mailhub1.watson.ibm.com (mailhub1.watson.ibm.com [9.2.249.31]) by igw3.watson.ibm.com (8.7.6/8.7.1) with ESMTP id NAA09770; Thu, 19 Dec 1996 13:01:02 -0500 Received: from hawpub.watson.ibm.com (hawpub.watson.ibm.com [9.2.90.19]) by mailhub1.watson.ibm.com (8.8.2/11-26-96) with SMTP id NAA32226; Thu, 19 Dec 1996 13:00:31 -0500 Received: by hawpub.watson.ibm.com (AIX 3.2/UCB 5.64/6/25/96) id AA25859; Thu, 19 Dec 1996 13:00:30 -0500 From: Uri Blumenthal Message-Id: <9612191800.AA25859@hawpub.watson.ibm.com> Subject: Re: Support for Persistency To: jjohnson@cisco.com (Jeffrey T. Johnson) Date: Thu, 19 Dec 1996 13:00:30 -0500 (EST) Cc: agentx@fv.com In-Reply-To: <32B97A6F.6CAC@cisco.com> from "Jeffrey T. Johnson" at Dec 19, 96 09:25:03 am Reply-To: uri@watson.ibm.com X-Mailer: ELM [version 2.4 PL25] Content-Type: text Jeffrey T. Johnson says: > Uri, if a box reboots, and your master agent and all subagent processes > "die", you lose all your agentx state. reliable transports don't > survive a reboot or a power down of the box. Excellent. Then they all will start "from scratch", with no "previous state" burden. > Ok, I want to add a new single-interface card to this configuration. I > power down the workstation, add the new card (which contains its own > embedded agentx SA daemon, call it SA2), and power the workstation back > up. The MA and the two SAs start up, and begin talking to one another. > SA1 will try to allocate ifIndex.1 and ifIndex.2 while SA2 will try to > allocate ifIndex.NEW_INDEX. When the workstation powers up, there is no > way to control whether SA1 or SA2 will try to allocate ifIndex values > first......... I understand your position. However: if the computer and the motherboard allow for the card (and for the sub') to figure out in which slot this card sits in - then the answer is obvious. Have those sub's asking for that slot. If neither one cares - well, I sympathyze but the interfaces will be numbered in a random way... A question to everybody: is the extra complexity (and I'm afraid there will be considerable complexity) to implement such reservation really worth it? My answer is no. User-friendly ton of bricks ready for shipment next decade is worse than a-bit-less-friendly but still very much usable code being shipped now. -- Regards, Uri uri@watson.ibm.com -=-=-=-=-=-=-   Delivery-Date: Thu, 19 Dec 1996 12:01:14 -0800 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.5/8.7.3) id MAA24647 for X-agentx; Thu, 19 Dec 1996 12:01:13 -0800 (PST) Received: from gauntlet.fv.com (gauntlet.fv.com [207.67.199.118]) by fv.com (8.7.5/8.7.3) with ESMTP id MAA24644 for ; Thu, 19 Dec 1996 12:01:13 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.7.5/8.7.3) id PAA13409 for ; Thu, 19 Dec 1996 15:01:29 -0500 (EST) Received: from shekel.fv.com(207.67.199.130) by gauntlet.fv.com via smap (3.2) id xma013393; Thu, 19 Dec 96 12:01:03 -0800 Received: from gauntlet.fv.com (gauntlet-in.fv.com [10.0.0.2]) by shekel.fv.com (8.7.5/8.7.3) with ESMTP id MAA18636 for ; Thu, 19 Dec 1996 12:01:42 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.7.5/8.7.3) id PAA13377 for ; Thu, 19 Dec 1996 15:00:57 -0500 (EST) Received: from utrhcs.cs.utwente.nl(130.89.10.247) by gauntlet.fv.com via smap (3.2) id xma013367; Thu, 19 Dec 96 12:00:50 -0800 Received: from myrtilos.cs.utwente.nl by utrhcs.cs.utwente.nl (SMI-8.6/csrelay-SVR4_1.3/RBCS) id VAA18218; Thu, 19 Dec 1996 21:00:14 +0100 Received: from atlas.cs.utwente.nl by myrtilos.cs.utwente.nl (SMI-8.6/csrelay-Sol1.4/RB) id VAA27386; Thu, 19 Dec 1996 21:00:12 +0100 Received: by atlas.cs.utwente.nl (SMI-8.6/SMI-SVR4) id VAA00787; Thu, 19 Dec 1996 21:00:11 +0100 Date: Thu, 19 Dec 1996 21:00:11 +0100 Message-Id: <199612192000.VAA00787@atlas.cs.utwente.nl> From: Juergen Schoenwaelder To: uri@watson.ibm.com CC: jjohnson@cisco.com, agentx@fv.com In-reply-to: <9612191800.AA25859@hawpub.watson.ibm.com> (message from Uri Blumenthal on Thu, 19 Dec 1996 13:00:30 -0500 (EST)) Subject: Re: Support for Persistency Jeffrey T. Johnson says: Jeff> Ok, I want to add a new single-interface card to this configuration. I Jeff> power down the workstation, add the new card (which contains its own Jeff> embedded agentx SA daemon, call it SA2), and power the workstation back Jeff> up. The MA and the two SAs start up, and begin talking to one another. Jeff> SA1 will try to allocate ifIndex.1 and ifIndex.2 while SA2 will try to Jeff> allocate ifIndex.NEW_INDEX. When the workstation powers up, there is no Jeff> way to control whether SA1 or SA2 will try to allocate ifIndex values Jeff> first......... Uri Blumenthal said: Uri> However: if the computer and the motherboard allow for the card (and Uri> for the sub') to figure out in which slot this card sits in - then Uri> the answer is obvious. Have those sub's asking for that slot. If Uri> neither one cares - well, I sympathyze but the interfaces will Uri> be numbered in a random way... I think that this example does not justify the complexity. (Even some monolithic agents will have problems if you change the hardware. :-) However, it is possible to create examples where the problem might have some major impacts. All you need are two equivalent subagents SA1 and SA2 which can be configured by the manager. Both register at the same priority and SA1 wins. The manager configures SA1 by issuing some set requests. The system reboots and the next time SA2 registers first. The configuration is gone, even if SA1 has assured to keep the configured values in non-volatile storage. (Think of a trap forwarding table - a manager configures the table but it does not receive any traps because the agent system has rebooted and another subagent registered first.) The question is whether AgentX has to deal with this problem. If the WG decides that this is not a requirement, than we should add some text to explicitly lists this (and probably other) limitations. Therefore, I suggest to add a section 4.3 "AgentX Limitations". This section should contain clear statements what this WG considers to be out of scope for (the first version of) AgentX. An example: : AgentX does not guarantee that registrations issued by multiple : subagents with the same priority will be transparent to the manager : if the master agent or the selected subagent reinitializes. I am happy with such a decision if it is well documented. (Note that the solution proposed by Jeff where a subagent keeps a previously allocated index across reboots and the master waits before responding to allocation requests is a reasonable workaround, but it does not remove the limitation of AgentX.) Juergen -- Juergen Schoenwaelder schoenw@cs.utwente.nl http://www.cs.utwente.nl/~schoenw Computer Science Department, University of Twente, (Fax: +31-53-489-3247) P.O. Box 217, NL-7500 AE Enschede, The Netherlands. (Tel. +31-53-489-3678)   Delivery-Date: Fri, 20 Dec 1996 02:34:11 -0800 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.5/8.7.3) id CAA04090 for X-agentx; Fri, 20 Dec 1996 02:34:10 -0800 (PST) Received: from gauntlet.fv.com (gauntlet.fv.com [207.67.199.118]) by fv.com (8.7.5/8.7.3) with ESMTP id CAA04087 for ; Fri, 20 Dec 1996 02:34:10 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.7.5/8.7.3) id FAA19375 for ; Fri, 20 Dec 1996 05:34:24 -0500 (EST) Received: from shekel.fv.com(207.67.199.130) by gauntlet.fv.com via smap (3.2) id xma019370; Fri, 20 Dec 96 02:33:55 -0800 Received: from gauntlet.fv.com (gauntlet-in.fv.com [10.0.0.2]) by shekel.fv.com (8.7.5/8.7.3) with ESMTP id CAA01338 for ; Fri, 20 Dec 1996 02:34:34 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.7.5/8.7.3) id FAA19367 for ; Fri, 20 Dec 1996 05:33:55 -0500 (EST) Received: from utrhcs.cs.utwente.nl(130.89.10.247) by gauntlet.fv.com via smap (3.2) id xma019365; Fri, 20 Dec 96 02:33:23 -0800 Received: from myrtilos.cs.utwente.nl by utrhcs.cs.utwente.nl (SMI-8.6/csrelay-SVR4_1.3/RBCS) id LAA22663; Fri, 20 Dec 1996 11:33:04 +0100 Received: from atlas.cs.utwente.nl by myrtilos.cs.utwente.nl (SMI-8.6/csrelay-Sol1.4/RB) id LAA11453; Fri, 20 Dec 1996 11:33:03 +0100 Received: by atlas.cs.utwente.nl (SMI-8.6/SMI-SVR4) id LAA07796; Fri, 20 Dec 1996 11:33:02 +0100 Date: Fri, 20 Dec 1996 11:33:02 +0100 Message-Id: <199612201033.LAA07796@atlas.cs.utwente.nl> From: Juergen Schoenwaelder To: agentx@fv.com Subject: tagging index allocations One of the topics discussed in the application MIB WG in San Jose was the question how relationships between MIB modules can be handled in an AgentX environment. The problem comes down to the following question: How can subagent B refer to an index value allocated and used by subagent A? Various solutions were discussed: 1. "avoid the problem" Every index should have a well defined meaning so that the correct value can be obtained from the local system. The typical example is the definition of hrSWRunIndex (RFC1514) which says that "the system's native, unique identification number" should be used. However, in many cases, there is no such native unique number and I have doubts that we can change all existing MIBs that currently use "small arbitrary numbers" for indexing purposes. 2. "hack around the problem" This solution requires that subagent B sends SNMP requests to the master agent to lookup the index value used by subagent A. There are two problems with this approach: First, it requires to have access to an SNMP protocol engine (which is something we want to avoid by using AgentX) and it requires SNMP configuration information in the subagent B so that it can access the required information. The second problem is that allocation changes (e.g. subagent A restarts and uses a new indexing scheme) are not easily detected by subagent B. (Well, subagent B can poll the master agent via SNMP requests but I hope nobody really suggests this as a solution.) 3. "index generator(s) in the master agent" The idea here is to add index generation functions to the master agent so that subagents retrieve index values from the master. The problem with this approach is that the master agent probably needs some MIB knowledge to generate good index values which violates one of the design goals. This solution does not attack the problem of allocation changes. None of these solutions is really satisfying. Thats why I add another proposal. It is less general, but it allows to solve the problem if subagents are implemented to "cooperate". 4. "tagging index allocations" The agentx-IndexAllocate-PDU is extended with a new field called a tag (an Octet String value). Subagent A can use this field to tag an index allocation request with arbitrary information that uniquely identifies the row for which the index will be used. A new agentx-IndexQuery-PDU is added which allows to retrieve the index value for a given tag. This PDU can be used by subagent B to query the master for an index that has been allocated with the given tag by subagent A. The problem with this approach is that it relies on the assumption that both subagents use the same tags. However, the list of used tags and allocated index values can be put in an agentxAllocationTable of the AgentX MIB so that subagents can be configured to use the "correct" tagging scheme. An alternative is to recommend tagging values in MIB modules that are likely to be implemented in an AgentX environment. This solution does not attack the problem of allocation changes. Any comments on this proposal? Is the described index tagging mechanism acceptable? Are there better solutions for this problem? I am happy to work out the details if people think it is worth to develop this idea further. (And sorry for the length of this email.) Juergen -- Juergen Schoenwaelder schoenw@cs.utwente.nl http://www.cs.utwente.nl/~schoenw Computer Science Department, University of Twente, (Fax: +31-53-489-3247) P.O. Box 217, NL-7500 AE Enschede, The Netherlands. (Tel. +31-53-489-3678)   Delivery-Date: Fri, 20 Dec 1996 08:38:07 -0800 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.5/8.7.3) id IAA02003 for X-agentx; Fri, 20 Dec 1996 08:38:03 -0800 (PST) Received: from gauntlet.fv.com (gauntlet.fv.com [207.67.199.118]) by fv.com (8.7.5/8.7.3) with ESMTP id IAA01997 for ; Fri, 20 Dec 1996 08:38:02 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.7.5/8.7.3) id LAA28319 for ; Fri, 20 Dec 1996 11:38:17 -0500 (EST) Received: from shekel.fv.com(207.67.199.130) by gauntlet.fv.com via smap (3.2) id xma028313; Fri, 20 Dec 96 08:37:49 -0800 Received: from gauntlet.fv.com (gauntlet-in.fv.com [10.0.0.2]) by shekel.fv.com (8.7.5/8.7.3) with ESMTP id IAA15441 for ; Fri, 20 Dec 1996 08:38:30 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.7.5/8.7.3) id LAA28308 for ; Fri, 20 Dec 1996 11:37:47 -0500 (EST) Received: from relay1.smtp.psi.net(38.8.14.2) by gauntlet.fv.com via smap (3.2) id xma028296; Fri, 20 Dec 96 08:37:35 -0800 Received: from nips.acec.com by relay1.smtp.psi.net (8.6.12/SMI-5.4-PSI) id LAA04997; Fri, 20 Dec 1996 11:37:17 -0500 Received: from bnatale by nips.acec.com (5.65/3.2.083191-American Computer and Electronics Corp. ) id AA23312; Fri, 20 Dec 1996 11:38:59 -0500 Date: Fri, 20 Dec 1996 11:36:53 EST From: Bob Natale Subject: Re: Support for Persistency To: Juergen Schoenwaelder Cc: uri@watson.ibm.com, jjohnson@cisco.com, agentx@fv.com Message-Id: Priority: Normal Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII > From: Juergen Schoenwaelder > Date: Thu, 19 Dec 1996 21:00:11 +0100 Hi Juergen, everyone, <...> > The question is whether AgentX has to deal with this problem. If the > WG decides that this is not a requirement, than we should add some > text to explicitly lists this (and probably other) limitations. > Therefore, I suggest to add a section 4.3 "AgentX Limitations". This > section should contain clear statements what this WG considers to be > out of scope for (the first version of) AgentX. I really don't see this as an "AgentX Limitation"...it's the way things work in SNMP...index values are not guaranteed to be constant across re-inits. AtomMIB people have been discussing some aspects of this in recent days and seem to be coming to the conclusion that, all in all, this is the best approach. RFC1213, ifIndex, already establishes the point. > An example: > > : AgentX does not guarantee that registrations issued by multiple > : subagents with the same priority will be transparent to the manager > : if the master agent or the selected subagent reinitializes. > I am happy with such a decision if it is well documented. There are an infinite number of such negatives to document. Where we don't change SNMP, we don't need to take any special action, IMHO. And an objective should be to avoid changing SNMP where possible. > (Note that the solution proposed by Jeff where a subagent > keeps a previously allocated index across reboots This can be done within the protocol as spec'd currently... then the sub tries an instance-level registration when it comes back up. > and the master waits before responding to allocation requests > is a reasonable workaround, How does the master know when it has waited long enough? > but it does not remove the limitation of AgentX.) It's not a limitation of AgentX to begin with. Cordially, BobN ------ ISO 9000 Registered, Hardware and Software Divsions ----- Bob Natale | ACE*COMM | 301-721-3000 [v] Dir, Net Mgmt Prod | 704 Quince Orchard Rd | 301-721-3001 [f] natale@acec.com | Gaithersburg MD 20878 | http://www.acec.com ----- WinSNMP DLL, SDK, Apps & Agents for Win16/32 & UNIX ------ ------- NetPlus (r) "FCAPS" Telemanagement Applications --------   Delivery-Date: Fri, 20 Dec 1996 11:33:15 -0800 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.5/8.7.3) id LAA17030 for X-agentx; Fri, 20 Dec 1996 11:33:15 -0800 (PST) Received: from gauntlet.fv.com (gauntlet.fv.com [207.67.199.118]) by fv.com (8.7.5/8.7.3) with ESMTP id LAA17025 for ; Fri, 20 Dec 1996 11:33:14 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.7.5/8.7.3) id OAA10694 for ; Fri, 20 Dec 1996 14:33:27 -0500 (EST) Received: from shekel.fv.com(207.67.199.130) by gauntlet.fv.com via smap (3.2) id xma010683; Fri, 20 Dec 96 11:32:58 -0800 Received: from gauntlet.fv.com (gauntlet-in.fv.com [10.0.0.2]) by shekel.fv.com (8.7.5/8.7.3) with ESMTP id LAA29359 for ; Fri, 20 Dec 1996 11:33:38 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.7.5/8.7.3) id OAA10675 for ; Fri, 20 Dec 1996 14:32:57 -0500 (EST) Received: from mail13.digital.com(192.208.46.30) by gauntlet.fv.com via smap (3.2) id xma010670; Fri, 20 Dec 96 11:32:35 -0800 Received: from flume.zk3.dec.com by mail13.digital.com (8.7.5/UNX 1.5/1.0/WV) id OAA00763; Fri, 20 Dec 1996 14:16:06 -0500 (EST) Received: from bernie.zk3.dec.com by flume.zk3.dec.com; (5.65v3.2/1.1.8.2/16Jan95-0946AM) id AA07560; Fri, 20 Dec 1996 14:15:53 -0500 Received: from localhost by bernie.zk3.dec.com; (5.65/1.1.8.2/22Aug96-1117AM) id AA08296; Fri, 20 Dec 1996 14:19:25 -0500 Message-Id: <9612201919.AA08296@bernie.zk3.dec.com> To: Juergen Schoenwaelder Cc: jjohnson@cisco.com, agentx@fv.com Subject: Re: Support for Persistency In-Reply-To: Your message of "Thu, 19 Dec 96 21:00:11 +0100." <199612192000.VAA00787@atlas.cs.utwente.nl> Date: Fri, 20 Dec 96 14:19:24 -0500 From: Mike Daniele X-Mts: smtp >However, it is possible to create examples where the problem might >have some major impacts. All you need are two equivalent subagents SA1 >and SA2 which can be configured by the manager. Both register at the >same priority and SA1 wins. The manager configures SA1 by issuing some >set requests. The system reboots and the next time SA2 registers >first. The configuration is gone, even if SA1 has assured to keep the >configured values in non-volatile storage. (Think of a trap forwarding >table - a manager configures the table but it does not receive any >traps because the agent system has rebooted and another subagent >registered first.) >The question is whether AgentX has to deal with this problem. I think it already does. a) It requires the master agent to fail the duplicate registration, so whichever subagent is second, it at least knows. If after the reboot SA1 finds its registration is rejected, it can take action (log something, send a trap, etc). b) It makes the actual registry available via the MIB, so a human can see SA1 has in fact registered. c) It provides a priority mechanism. The human who configured SA1 via some set requests should modify SA1's config/startup parameters so it registers next time with the best priority. Seems like plenty of support to me. It's not a goal (nor even possible) to make this foolproof in every possible configuration scenario. We have to rely on subagent developers and human managers using some common sense. Now my question: Let's imagine this same SA1 and SA2 scenario but that AgentX supports unionized registration. a) Both SA1 and SA2 will succeed in registering. b) The set requests to configure something in the MIB are dispatched to subagent...? c) The MIB shows ... ? d) A human who wishes to make sure his configuration doesn't get lost can ... ? Anyone care to explain how this gets resolved? Or how about this? The SetRequest ended up going (in an implementation-specific, transparent manner) to SA1. But on a subsequent Get*Request SA1 is busy and doesn't reply. SA2's response is used, but it returns different values. Your thoughts welcome... Thanks, Mike   Delivery-Date: Fri, 20 Dec 1996 12:03:46 -0800 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.5/8.7.3) id MAA19437 for X-agentx; Fri, 20 Dec 1996 12:03:45 -0800 (PST) Received: from gauntlet.fv.com (gauntlet.fv.com [207.67.199.118]) by fv.com (8.7.5/8.7.3) with ESMTP id MAA19433 for ; Fri, 20 Dec 1996 12:03:44 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.7.5/8.7.3) id PAA12614 for ; Fri, 20 Dec 1996 15:03:57 -0500 (EST) Received: from shekel.fv.com(207.67.199.130) by gauntlet.fv.com via smap (3.2) id xma012560; Fri, 20 Dec 96 12:03:25 -0800 Received: from gauntlet.fv.com (gauntlet-in.fv.com [10.0.0.2]) by shekel.fv.com (8.7.5/8.7.3) with ESMTP id MAA01959 for ; Fri, 20 Dec 1996 12:04:05 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.7.5/8.7.3) id PAA12541 for ; Fri, 20 Dec 1996 15:03:24 -0500 (EST) Received: from mail12.digital.com(192.208.46.20) by gauntlet.fv.com via smap (3.2) id xma012508; Fri, 20 Dec 96 12:02:54 -0800 Received: from hunch.zk3.dec.com by mail12.digital.com (8.7.5/UNX 1.5/1.0/WV) id OAA28870; Fri, 20 Dec 1996 14:54:02 -0500 (EST) Received: from bernie.zk3.dec.com by hunch.zk3.dec.com; (5.65v3.2/1.1.8.2/11Mar96-0342PM) id AA30575; Fri, 20 Dec 1996 14:53:54 -0500 Received: from localhost by bernie.zk3.dec.com; (5.65/1.1.8.2/22Aug96-1117AM) id AA08268; Fri, 20 Dec 1996 14:57:36 -0500 Message-Id: <9612201957.AA08268@bernie.zk3.dec.com> To: Juergen Schoenwaelder Cc: agentx@fv.com Subject: Re: tagging index allocations In-Reply-To: Your message of "Fri, 20 Dec 96 11:33:02 +0100." <199612201033.LAA07796@atlas.cs.utwente.nl> Date: Fri, 20 Dec 96 14:57:36 -0500 From: Mike Daniele X-Mts: smtp >One of the topics discussed in the application MIB WG in San Jose was >the question how relationships between MIB modules can be handled in >an AgentX environment. The problem comes down to the following >question: > How can subagent B refer to an index value allocated and used > by subagent A? I'm sorry I missed this meeting (and all the others...). Can you be more specific abouy what's required for applmib? I assume it's something along the lines of "How can an application process find out what row of sysApplRunElmtTable (in sysApplMIB) refers to itself?". I'm currently being gored by this very issue (we have several different subagents/MIBs that wish to refer to Host MIB instances). The conclusion I came to is that the extensible agent infrastructure is the wrong place to try and solve this. There needs to be some sort of SNMP-aware interface to the managed resource. (I realize this is problematic in many cases.) Or one can always resort to SNMP requests. Two problems I can think of with your suggestion of tagging index allocations are: - Just because a subagent successfully allocated an index does NOT mean that index is being used in any instantiated variable. (Registration and index allocation are disjoint.) - It assumes the required index value is for a table that is shared between subagents, and hence for which an index allocation was made. Seems likely that the referred-to table will often be implemented in its entirety by a single subagent. That was the whole idea of the sysApplMIB, right? Individual applications do not need to be instrumented, meaning a central "monitor" subagent implements the entire table. Regards, Mike   Delivery-Date: Sat, 21 Dec 1996 16:35:07 -0800 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.5/8.7.3) id QAA26102 for X-agentx; Sat, 21 Dec 1996 16:35:06 -0800 (PST) Received: from gauntlet.fv.com (gauntlet.fv.com [207.67.199.118]) by fv.com (8.7.5/8.7.3) with ESMTP id QAA26099 for ; Sat, 21 Dec 1996 16:35:06 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.7.5/8.7.3) id TAA24066 for ; Sat, 21 Dec 1996 19:35:17 -0500 (EST) Received: from shekel.fv.com(207.67.199.130) by gauntlet.fv.com via smap (3.2) id xma024059; Sat, 21 Dec 96 16:34:52 -0800 Received: from gauntlet.fv.com (gauntlet-in.fv.com [10.0.0.2]) by shekel.fv.com (8.7.5/8.7.3) with ESMTP id QAA05425 for ; Sat, 21 Dec 1996 16:35:34 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.7.5/8.7.3) id TAA24056 for ; Sat, 21 Dec 1996 19:34:47 -0500 (EST) Received: from igw3.watson.ibm.com(129.34.139.18) by gauntlet.fv.com via smap (3.2) id xma024054; Sat, 21 Dec 96 16:34:42 -0800 Received: from mailhub1.watson.ibm.com (mailhub1.watson.ibm.com [9.2.249.31]) by igw3.watson.ibm.com (8.7.6/8.7.1) with ESMTP id TAA08646; Sat, 21 Dec 1996 19:32:10 -0500 Received: from hawpub.watson.ibm.com (hawpub.watson.ibm.com [9.2.90.19]) by mailhub1.watson.ibm.com (8.8.2/11-26-96) with SMTP id TAA22032; Sat, 21 Dec 1996 19:31:38 -0500 Received: by hawpub.watson.ibm.com (AIX 3.2/UCB 5.64/6/25/96) id AA219912; Sat, 21 Dec 1996 19:31:37 -0500 From: Uri Blumenthal Message-Id: <9612220031.AA219912@hawpub.watson.ibm.com> Subject: Re: tagging index allocations To: daniele@zk3.dec.com (Mike Daniele) Date: Sat, 21 Dec 1996 19:31:36 -0500 (EST) Cc: schoenw@cs.utwente.nl, agentx@fv.com In-Reply-To: <9612201957.AA08268@bernie.zk3.dec.com> from "Mike Daniele" at Dec 20, 96 02:57:36 pm Reply-To: uri@watson.ibm.com X-Mailer: ELM [version 2.4 PL25] Content-Type: text Mike Daniele says: > > The problem comes down to the following question: > > > How can subagent B refer to an index value allocated and used > > by subagent A? I'm firmly convinced [and have yet to see a valid argument to the contrary] that the answer is: "It's not subagent B's business". > I assume it's something along the lines of "How can an application > process find out what row of sysApplRunElmtTable (in sysApplMIB) refers to > itself?". Something like that could be dealt with in a regustration response. > Individual applications do not need to be instrumented, > meaning a central "monitor" subagent implements the entire > table. I'm not sure I understand (or agree)... -- Regards, Uri uri@watson.ibm.com -=-=-=-=-=-=-   Delivery-Date: Tue, 24 Dec 1996 05:07:46 -0800 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.5/8.7.3) id FAA03329 for X-agentx; Tue, 24 Dec 1996 05:07:45 -0800 (PST) Received: from gauntlet.fv.com (gauntlet.fv.com [207.67.199.118]) by fv.com (8.7.5/8.7.3) with ESMTP id FAA03326 for ; Tue, 24 Dec 1996 05:07:44 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.7.5/8.7.3) id IAA04851 for ; Tue, 24 Dec 1996 08:07:50 -0500 (EST) Received: from shekel.fv.com(207.67.199.130) by gauntlet.fv.com via smap (3.2) id xma004840; Tue, 24 Dec 96 05:07:20 -0800 Received: from gauntlet.fv.com (gauntlet-in.fv.com [10.0.0.2]) by shekel.fv.com (8.7.5/8.7.3) with ESMTP id FAA23294 for ; Tue, 24 Dec 1996 05:08:03 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.7.5/8.7.3) id IAA04837 for ; Tue, 24 Dec 1996 08:07:19 -0500 (EST) Received: from utrhcs.cs.utwente.nl(130.89.10.247) by gauntlet.fv.com via smap (3.2) id xma004835; Tue, 24 Dec 96 05:06:57 -0800 Received: from myrtilos.cs.utwente.nl by utrhcs.cs.utwente.nl (SMI-8.6/csrelay-SVR4_1.3/RBCS) id OAA19641; Tue, 24 Dec 1996 14:06:42 +0100 Received: from atlas.cs.utwente.nl by myrtilos.cs.utwente.nl (SMI-8.6/csrelay-Sol1.4/RB) id OAA01607; Tue, 24 Dec 1996 14:06:40 +0100 Received: by atlas.cs.utwente.nl (SMI-8.6/SMI-SVR4) id OAA27258; Tue, 24 Dec 1996 14:06:40 +0100 Date: Tue, 24 Dec 1996 14:06:40 +0100 Message-Id: <199612241306.OAA27258@atlas.cs.utwente.nl> From: Juergen Schoenwaelder To: natale@acec.com CC: uri@watson.ibm.com, jjohnson@cisco.com, agentx@fv.com In-reply-to: (message from Bob Natale on Fri, 20 Dec 1996 11:36:53 EST) Subject: Re: Support for Persistency Bob Natale said: Bob> I really don't see this as an "AgentX Limitation"...it's the Bob> way things work in SNMP...index values are not guaranteed to Bob> be constant across re-inits. I am not talking about index values. I am for example talking about RFC 1903 StorageType values where a subagent claims that a newly created row is kept in non-volatile storage but the row disappears if the competing subagent wins the next "initialization contest". I think this kind of "random" behavior is not part of SNMP - I think it is caused by AgentX. Juergen> : AgentX does not guarantee that registrations issued by multiple Juergen> : subagents with the same priority will be transparent to the manager Juergen> : if the master agent or the selected subagent reinitializes. Juergen> I am happy with such a decision if it is well documented. Bob> There are an infinite number of such negatives to document. Bob> Where we don't change SNMP, we don't need to take any special Bob> action, IMHO. And an objective should be to avoid changing Bob> SNMP where possible. Lets look at the AgentX transparency requirement: > The internal operations of AgentX are invisible to an SNMP entity > operating in a manager role. From a manager's point of view, an > extensible agent behaves exactly as would a non-extensible > (monolithic) agent that has access to the same management > instrumentation. I think that we can have situations where it is difficult to guarantee this transparency with AgentX. Selecting between competing subagents is one of them. I think it is good engineering to document these issues instead of hiding them deep in the spec. Of course, I hope we don't have an infinite number of these AgentX specific things. ;-) My proposal to add a section "AgentX Limitations" is meant to be positive and constructive. It helps an AgentX user to see where potential problems are and it documents that the engineers who created AgentX were well aware of these issues. Juergen> (Note that the solution proposed by Jeff where a subagent Juergen> keeps a previously allocated index across reboots Juergen> and the master waits before responding to allocation requests Juergen> is a reasonable workaround, Bob> How does the master know when it has waited long enough? Thats why I call it a workaround - it is not a solution, although it might work in many cases in practice. Juergen> but it does not remove the limitation of AgentX.) Bob> It's not a limitation of AgentX to begin with. We have AgentX specific limitations every time the master has to choose between multiple conflicting options. I believe that the "first subagent wins" rule can cause "random behavior" as seen from the manager's point of view and we should document this. Juergen -- Juergen Schoenwaelder schoenw@cs.utwente.nl http://www.cs.utwente.nl/~schoenw Computer Science Department, University of Twente, (Fax: +31-53-489-3247) P.O. Box 217, NL-7500 AE Enschede, The Netherlands. (Tel. +31-53-489-3678)   Delivery-Date: Tue, 24 Dec 1996 05:30:45 -0800 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.5/8.7.3) id FAA05429 for X-agentx; Tue, 24 Dec 1996 05:30:44 -0800 (PST) Received: from gauntlet.fv.com (gauntlet.fv.com [207.67.199.118]) by fv.com (8.7.5/8.7.3) with ESMTP id FAA05423 for ; Tue, 24 Dec 1996 05:30:43 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.7.5/8.7.3) id IAA05717 for ; Tue, 24 Dec 1996 08:30:49 -0500 (EST) Received: from shekel.fv.com(207.67.199.130) by gauntlet.fv.com via smap (3.2) id xma005708; Tue, 24 Dec 96 05:30:19 -0800 Received: from gauntlet.fv.com (gauntlet-in.fv.com [10.0.0.2]) by shekel.fv.com (8.7.5/8.7.3) with ESMTP id FAA24246 for ; Tue, 24 Dec 1996 05:31:03 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.7.5/8.7.3) id IAA05699 for ; Tue, 24 Dec 1996 08:30:18 -0500 (EST) Received: from utrhcs.cs.utwente.nl(130.89.10.247) by gauntlet.fv.com via smap (3.2) id xma005694; Tue, 24 Dec 96 05:30:05 -0800 Received: from myrtilos.cs.utwente.nl by utrhcs.cs.utwente.nl (SMI-8.6/csrelay-SVR4_1.3/RBCS) id OAA19710; Tue, 24 Dec 1996 14:22:59 +0100 Received: from atlas.cs.utwente.nl by myrtilos.cs.utwente.nl (SMI-8.6/csrelay-Sol1.4/RB) id OAA01832; Tue, 24 Dec 1996 14:22:57 +0100 Received: by atlas.cs.utwente.nl (SMI-8.6/SMI-SVR4) id OAA27319; Tue, 24 Dec 1996 14:22:57 +0100 Date: Tue, 24 Dec 1996 14:22:57 +0100 Message-Id: <199612241322.OAA27319@atlas.cs.utwente.nl> From: Juergen Schoenwaelder To: daniele@zk3.dec.com CC: agentx@fv.com In-reply-to: <9612201957.AA08268@bernie.zk3.dec.com> (message from Mike Daniele on Fri, 20 Dec 96 14:57:36 -0500) Subject: Re: tagging index allocations Mike Daniele said: Mike> Two problems I can think of with your suggestion of tagging Mike> index allocations are: Mike> - Just because a subagent successfully allocated an index Mike> does NOT mean that index is being used in any instantiated Mike> variable. (Registration and index allocation are Mike> disjoint.) It depends on how the agentx-IndexQuery-PDU is defined. We can define it in such a way that only allocated and registered index values are used to resolve tags. Mike> - It assumes the required index value is for a table that Mike> is shared between subagents, and hence for which an index Mike> allocation was made. Mike> Seems likely that the referred-to table will often be Mike> implemented in its entirety by a single subagent. Mike> That was the whole idea of the sysApplMIB, right? Mike> Individual applications do not need to be instrumented, Mike> meaning a central "monitor" subagent implements the entire Mike> table. Let me see if I understand your point: Tables that are referred to are usually implemented in a single subagent and hence there is no need for the subagent to allocate index values. Is this correct? Your comment is probably true for many tables. Indeed, the tagging approach would require to allocate index values for these tables in order to make the tags known to the master. (I guess this turns into a good argument against tags.) Juergen -- Juergen Schoenwaelder schoenw@cs.utwente.nl http://www.cs.utwente.nl/~schoenw Computer Science Department, University of Twente, (Fax: +31-53-489-3247) P.O. Box 217, NL-7500 AE Enschede, The Netherlands. (Tel. +31-53-489-3678)   Delivery-Date: Tue, 24 Dec 1996 07:07:13 -0800 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.5/8.7.3) id HAA13538 for X-agentx; Tue, 24 Dec 1996 07:07:13 -0800 (PST) Received: from gauntlet.fv.com (gauntlet.fv.com [207.67.199.118]) by fv.com (8.7.5/8.7.3) with ESMTP id HAA13533 for ; Tue, 24 Dec 1996 07:07:12 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.7.5/8.7.3) id KAA09012 for ; Tue, 24 Dec 1996 10:07:18 -0500 (EST) Received: from shekel.fv.com(207.67.199.130) by gauntlet.fv.com via smap (3.2) id xma008993; Tue, 24 Dec 96 07:06:48 -0800 Received: from gauntlet.fv.com (gauntlet-in.fv.com [10.0.0.2]) by shekel.fv.com (8.7.5/8.7.3) with ESMTP id HAA27471 for ; Tue, 24 Dec 1996 07:07:32 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.7.5/8.7.3) id KAA08980 for ; Tue, 24 Dec 1996 10:06:47 -0500 (EST) Received: from mail11.digital.com(192.208.46.10) by gauntlet.fv.com via smap (3.2) id xma008970; Tue, 24 Dec 96 07:06:27 -0800 Received: from hunch.zk3.dec.com by mail11.digital.com (8.7.5/UNX 1.5/1.0/WV) id JAA20495; Tue, 24 Dec 1996 09:59:21 -0500 (EST) Received: from bernie.zk3.dec.com by hunch.zk3.dec.com; (5.65v3.2/1.1.8.2/11Mar96-0342PM) id AA16052; Tue, 24 Dec 1996 09:58:47 -0500 Received: from localhost by bernie.zk3.dec.com; (5.65/1.1.8.2/22Aug96-1117AM) id AA09436; Tue, 24 Dec 1996 10:02:27 -0500 Message-Id: <9612241502.AA09436@bernie.zk3.dec.com> To: Juergen Schoenwaelder Cc: agentx@fv.com Subject: Re: Support for Persistency In-Reply-To: Your message of "Tue, 24 Dec 96 14:06:40 +0100." <199612241306.OAA27258@atlas.cs.utwente.nl> Date: Tue, 24 Dec 96 10:02:27 -0500 From: Mike Daniele X-Mts: smtp Hi Juergen, >Bob Natale said: >Bob> I really don't see this as an "AgentX Limitation"...it's the >Bob> way things work in SNMP...index values are not guaranteed to >Bob> be constant across re-inits. >I am not talking about index values. I am for example talking about >RFC 1903 StorageType values where a subagent claims that a newly >created row is kept in non-volatile storage but the row disappears if >the competing subagent wins the next "initialization contest". I think >this kind of "random" behavior is not part of SNMP - I think it is >caused by AgentX. It's a problem, not part of SNMP, due to the nature of distributed agents. >My proposal to add a section "AgentX Limitations" is meant to be >positive and constructive. It helps an AgentX user to see where >potential problems are and it documents that the engineers who >created AgentX were well aware of these issues. I agree that there should be a section that discusses expected usage, and potential problems (like this). Probably an expansion of 7.1.3 (Using the Allocate-PDU). Mike   Delivery-Date: Tue, 24 Dec 1996 07:47:36 -0800 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.5/8.7.3) id HAA17046 for X-agentx; Tue, 24 Dec 1996 07:47:35 -0800 (PST) Received: from gauntlet.fv.com (gauntlet.fv.com [207.67.199.118]) by fv.com (8.7.5/8.7.3) with ESMTP id HAA17043 for ; Tue, 24 Dec 1996 07:47:35 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.7.5/8.7.3) id KAA11078 for ; Tue, 24 Dec 1996 10:47:41 -0500 (EST) Received: from shekel.fv.com(207.67.199.130) by gauntlet.fv.com via smap (3.2) id xma011070; Tue, 24 Dec 96 07:47:12 -0800 Received: from gauntlet.fv.com (gauntlet-in.fv.com [10.0.0.2]) by shekel.fv.com (8.7.5/8.7.3) with ESMTP id HAA29126 for ; Tue, 24 Dec 1996 07:47:56 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.7.5/8.7.3) id KAA11067 for ; Tue, 24 Dec 1996 10:47:11 -0500 (EST) Received: from hp827.clearsys.com(192.246.186.10) by gauntlet.fv.com via smap (3.2) id xma011010; Tue, 24 Dec 96 07:46:49 -0800 Received: from pc102.clearsys.com by hp827.clearsys.com with SMTP (1.37.109.4/16.2) id AA16746; Tue, 24 Dec 96 09:48:53 -0600 Message-Id: <32BFFAEB.3532@clearsys.com> Date: Tue, 24 Dec 1996 09:46:51 -0600 From: "John J. Catalano" Organization: ClearSystems, Inc. X-Mailer: Mozilla 2.01Gold (Win95; I) Mime-Version: 1.0 To: agentx@fv.com Subject: What happened to the SNMP mail list Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Folks. Does anyone out there in agentx land know what happened to the snmp mailing list that was hosted by snmp@psi.com? I have not gotten anything in a while from that mail list and as I do, many of you read/respond to both agentx and snmp. Regards, John J. Catalano   Delivery-Date: Tue, 24 Dec 1996 08:25:21 -0800 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.5/8.7.3) id IAA20779 for X-agentx; Tue, 24 Dec 1996 08:25:21 -0800 (PST) Received: from gauntlet.fv.com (gauntlet.fv.com [207.67.199.118]) by fv.com (8.7.5/8.7.3) with ESMTP id IAA20776 for ; Tue, 24 Dec 1996 08:25:20 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.7.5/8.7.3) id LAA13993 for ; Tue, 24 Dec 1996 11:25:26 -0500 (EST) Received: from shekel.fv.com(207.67.199.130) by gauntlet.fv.com via smap (3.2) id xma013962; Tue, 24 Dec 96 08:24:56 -0800 Received: from gauntlet.fv.com (gauntlet-in.fv.com [10.0.0.2]) by shekel.fv.com (8.7.5/8.7.3) with ESMTP id IAA01225 for ; Tue, 24 Dec 1996 08:25:39 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.7.5/8.7.3) id LAA13948 for ; Tue, 24 Dec 1996 11:24:55 -0500 (EST) Received: from igw3.watson.ibm.com(129.34.139.18) by gauntlet.fv.com via smap (3.2) id xma013939; Tue, 24 Dec 96 08:24:43 -0800 Received: from mailhub1.watson.ibm.com (mailhub1.watson.ibm.com [9.2.249.31]) by igw3.watson.ibm.com (8.7.6/8.7.1) with ESMTP id LAA09834; Tue, 24 Dec 1996 11:24:55 -0500 Received: from hawpub.watson.ibm.com (hawpub.watson.ibm.com [9.2.90.19]) by mailhub1.watson.ibm.com (8.8.2/11-26-96) with SMTP id LAA23720; Tue, 24 Dec 1996 11:24:21 -0500 Received: by hawpub.watson.ibm.com (AIX 3.2/UCB 5.64/6/25/96) id AA183963; Tue, 24 Dec 1996 11:24:21 -0500 From: Uri Blumenthal Message-Id: <9612241624.AA183963@hawpub.watson.ibm.com> Subject: Re: Support for Persistency To: schoenw@cs.utwente.nl (Juergen Schoenwaelder) Date: Tue, 24 Dec 1996 11:24:21 -0500 (EST) Cc: agentx@fv.com In-Reply-To: <199612241306.OAA27258@atlas.cs.utwente.nl> from "Juergen Schoenwaelder" at Dec 24, 96 02:06:40 pm Reply-To: uri@watson.ibm.com X-Mailer: ELM [version 2.4 PL25] Content-Type: text Juergen Schoenwaelder says: > Bob> I really don't see this as an "AgentX Limitation"...it's the > Bob> way things work in SNMP...index values are not guaranteed to > Bob> be constant across re-inits. > > I am not talking about index values. I am for example talking about > RFC 1903 StorageType values where a subagent claims that a newly > created row is kept in non-volatile storage but the row disappears if > the competing subagent wins the next "initialization contest". I think > this kind of "random" behavior is not part of SNMP - I think it is > caused by AgentX. Well, a "smart" sub' often can manage to crash the master agent, and practically always can screw up the NMS picture, if it wishes so (or if unwittingly designed this way). In this particular example, it would be unwise to pretend the index/row obtained by the sub' is non-volatile. If a sub' cannot determine from the unambiguous source what row/index it serves (hardware slot # would be a good source :-), then it's kinda silly to claim that you handle row 15 and this survives reboots and such... But if a sub' writer doesn't care - well, I don't think there *is* a way to handle such things gracefully. In short - if your code really wants to screw it - it can. The only solution in my view would be to document this and similar possibilities, explaining to the potential users these pitfalls, and how to adoiv them. -- Regards, Uri uri@watson.ibm.com -=-=-=-=-=-=-   Delivery-Date: Tue, 24 Dec 1996 09:00:24 -0800 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.5/8.7.3) id JAA23532 for X-agentx; Tue, 24 Dec 1996 09:00:23 -0800 (PST) Received: from gauntlet.fv.com (gauntlet.fv.com [207.67.199.118]) by fv.com (8.7.5/8.7.3) with ESMTP id JAA23529 for ; Tue, 24 Dec 1996 09:00:23 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.7.5/8.7.3) id MAA16063 for ; Tue, 24 Dec 1996 12:00:27 -0500 (EST) Received: from shekel.fv.com(207.67.199.130) by gauntlet.fv.com via smap (3.2) id xma016049; Tue, 24 Dec 96 08:59:58 -0800 Received: from gauntlet.fv.com (gauntlet-in.fv.com [10.0.0.2]) by shekel.fv.com (8.7.5/8.7.3) with ESMTP id JAA02774 for ; Tue, 24 Dec 1996 09:00:41 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.7.5/8.7.3) id LAA16034 for ; Tue, 24 Dec 1996 11:59:56 -0500 (EST) Received: from relay1.smtp.psi.net(38.8.14.2) by gauntlet.fv.com via smap (3.2) id xma016027; Tue, 24 Dec 96 08:59:33 -0800 Received: from nips.acec.com by relay1.smtp.psi.net (8.6.12/SMI-5.4-PSI) id LAA03764; Tue, 24 Dec 1996 11:59:21 -0500 Received: from bnatale by nips.acec.com (5.65/3.2.083191-American Computer and Electronics Corp. ) id AA27401; Tue, 24 Dec 1996 12:01:04 -0500 Message-Id: <3.0.32.19961224115859.00972100@nips.acec.com> X-Sender: natale@nips.acec.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Tue, 24 Dec 1996 11:59:00 -0500 To: Kim Laraqui From: Bob Natale Subject: Re: Some questions on AgentX Cc: agentx@fv.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" > At 10:44 AM 12/17/96 +0100, Kim Laraqui wrote: Hi Kim, For the record, I am the chair of the AgentX WG, and for those who care about such things...I am composing this response with one foot in the chair's domain and one foot in the technical arena. [Actually, now that I've finished it and am reviewing it, I'd like to say that I am writing this almost entirely as a private technical observer, with all of my well-known shortcomings in that respect clearly still intact!] >When I read the doc on AgentX (November 1996) my first reaction >is that it is so "anti-SNMP". I can understand how it can be read that way. This causes me some personal angst. While, perhaps, "anti-" is a bit strong...the drift certainly seems, to me, to be toward "extra-" or "supra-" SNMP. I think we are becoming trapped in the "problem space", having lost sight of the "solution space" we occupied initially. >My understanding of the spirit of SNMP/SMI is the use of a very >limited set of PDUs to convey pretty simple structures that still >are used to model complex control applications and mechanisms. Correct. >The MIB is used as a repository of system and interface variables, >as opposed to traditional signaling protocols in which the control >data structures are immediately consumed by a FSM; these FSMs >always come with a bunch of system variables but those are still >very local to the signaling protocol in their structures (i.e. >not SMI). It's thus very difficult within the realm of one >control/signaling protocol to refer to a variable in another. Ok. >Thus, the way I see it, there is a big difference >between concentrating semantics on MIB variables and on PDUs. Right. >So my question is, why doesn't the AgentX protocol use SMI >structures (say something like one table per AgentX PDU type, >to be deployed on the master or subagent or both, depending on >the PDUs' target) in combination with the simple set/get >operations, That was a cornerstone of my original proposal for AgentX. The consensus was, however, that "SNMP" was too complex for the sub-agents to deal with and/or we wanted to avoid the redundant BER operations that might be involved. >to achieve the same results as that which is currently being >advocated to employ lots of new PDU types for? Well, it is possibly true that we are now accepting so many (i.e., anything imaginable) permutations of registration and instantiation options that modeling them in a MIB might be close to impossible. >One could still retain the faster coding schemes currently >proposed. Possibly...although I know that we spend much effort to ensure that our BER coding operations are as efficient as possible and, in the grand scheme of things (on the platforms of interest to us and our customers), this is just noise relative to polling, filtering, aggregating, forwarding, and database storage processing times. >Could someone enlighten a humble SNMP user from the >deep and cold Swedish forests. My hope was that AgentX would provide a workable solution, quickly derived from the SMUX, DPI, and commercial precedents already in existence, for SNMP agent extensibility for relatively simple and reasonably self-contained systems. Desktop PCs, including their peripherals and major software components, are the prototypical example--numbering in the 100s of millions (in the foreseeable future, if not now). My company is working on two AgentX-like implementations for VSAT terminals and information Kiosks, both of which--despite having some state-of-the-art technology elements--appear to meet my criteria for relatively simple and self-contained systems. I suspect there are an unbounded number of possible systems that will meet these criteria in the future. And I think the general category of systems they represent will host an extremely large number of extensible agents overall. In the WG--esp. in f2f meetings--we have been mildly debating whether this represents 50%, 80%, 90% of the market (no one knows), and whether whatever percentage it might be is enough to not include support for the other 50/20/10/1% of sub-agents that will need more "advanced" feature support. Granted, in my scheme, there are some existing agent implementations and some MIBs that would have to be re-designed to fit AgentX. This seems to be counter to the current consensus of the group...which is closer to "AgentX must be designed to accommodate any and all existing agents and MIBs, even though they were not designed with standardized extensibility in mind". [And it is truly a tribute to the intelligence, creativity, effort, and open-mindedness of Mike, Bert, and Dale that the spec continues to evolve in this direction.] IMHO, a key requirement for the success of AgentX in the marketplace is optimizing for the simplicity of sub-agent implementation. We all seem to agree that objective will be aided by APIs and toolkits regardless of the actual nature of AgentX in the end. While true, that suggests several other considerations: 1. Well, then, there is little reason not to leverage SNMP itself (as your comments recommend). 2. It must still be possible/feasible/workable to write sub-agents at the protocol level, if one wants. 3. The timeliness and quality of APIs and toolkits will be negatively impacted by the number of features and the extent of "feature interaction" among them. >Cheers Thanks...I know it must sound from my response like I've been hanging out in some cold, dark, deep forest somewhere... but I do wish everyone a safe and happy holiday season and a very successful 1997! Cordially, BobN ------ ISO 9000 Registered, Hardware and Software Divsions ----- Bob Natale | ACE*COMM | 301-721-3000 [v] Dir, Net Mgmt Prod | 704 Quince Orchard Rd | 301-721-3001 [f] natale@acec.com | Gaithersburg MD 20878 | http://www.acec.com ----- WinSNMP DLL, SDK, Apps & Agents for Win16/32 & UNIX ------ ------- NetPlus (r) "FCAPS" Telemanagement Applications --------