From daemon Mon Nov 17 10:46:08 1997 Delivery-Date: Mon, 17 Nov 1997 10:54:10 -0500 Return-Path: daemon Received: (from daemon@localhost) by ietf.org (8.8.7/8.8.7a) id KAA15484 for ietf-123-outbound.10@ietf.org; Mon, 17 Nov 1997 10:45:57 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id KAA15465; Mon, 17 Nov 1997 10:45:46 -0500 (EST) Message-Id: <199711171545.KAA15465@ietf.org> 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-mib-01.txt Date: Mon, 17 Nov 1997 10:45:46 -0500 Sender: cclark@cnri.reston.va.us --NextPart A New 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 : Definitions of Managed Objects for Extensible SNMP Agents Author(s) : M. Greene, S. Gudur Filename : draft-ietf-agentx-mib-01.txt Pages : 18 Date : 14-Nov-97 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. 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-mib-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-agentx-mib-01.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net 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-mib-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: <19971114180355.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-agentx-mib-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-agentx-mib-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19971114180355.I-D@ietf.org> --OtherAccess-- --NextPart-- From adm Mon Dec 29 11:12:22 1997 Delivery-Date: Mon, 29 Dec 1997 11:22:08 -0500 Return-Path: adm Received: (from adm@localhost) by ns.ietf.org (8.8.7/8.8.7a) id LAA16247 for ietf-123-outbound.10@ietf.org; Mon, 29 Dec 1997 11:12:02 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id LAA16131; Mon, 29 Dec 1997 11:07:17 -0500 (EST) Message-Id: <199712291607.LAA16131@ns.ietf.org> To: IETF-Announce: ; Cc: RFC Editor Cc: Internet Architecture Board Cc: agentx@fv.com From: The IESG Subject: Protocol Action: Agent Extensibility (AgentX) Protocol Version 1 to Proposed Standard Date: Mon, 29 Dec 1997 11:07:17 -0500 Sender: scoya@cnri.reston.va.us The IESG has approved the Internet-Draft 'Agent Extensibility (AgentX) Protocol Version 1' as a Proposed Standard. This document is the product of the SNMP Agent Extensibility Working Group. The IESG contact persons are John Curran and Michael O'Dell. Technical Summary This memo defines a standardized 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. Working Group Summary The Working Group spent significant time discussing the scope of the protocol and trying to balance the desire for a straightforward subagent communication model against the desire for a transparent subagent model which would work for any given MIB structure. This resulted in an approach which minimizes subagent communication messages while supporting the many common MIB object configurations. During Last Call, the issue was raised that the protocol was not suitable as a replacement for existing proprietary master/subagent protocols, as it could not address the full range of object types found in some MIBs. In review, it was determined that this tradeoff were made with the rough consensus of the working group, and that the resulting protocol is still sufficiently valuable for portable subagents development that it warrants standardization. Also raised during Last Call was an issue regarding inability of a master agent to administratively decline a subagent's registration request. While not a requirement, per se, it was felt that this concern was reasonable and would be best resolved by the creation of an additional return code or set of codes as determined by implementation experience. Protocol Quality This work has been reviewed by the Area Director responsible for the work as well as others knowledgable regarding master/subagent technology. There are at least two draft implementations at this time. From sw0l+hostmib-errors@andrew.cmu.edu Tue Mar 24 10:05:26 1998 Delivery-Date: Tue, 24 Mar 1998 10:05:31 -0500 Return-Path: sw0l+hostmib-errors@andrew.cmu.edu Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id KAA29074 for ; Tue, 24 Mar 1998 10:05:05 -0500 (EST) Received: from andrew.cmu.edu (ANDREW.CMU.EDU [128.2.10.101]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id KAA07005 for ; Tue, 24 Mar 1998 10:07:36 -0500 (EST) Received: (from postman@localhost) by andrew.cmu.edu (8.8.5/8.8.2) id JAA07394; Tue, 24 Mar 1998 09:58:57 -0500 (EST) Received: via switchmail for hostmib+@andrew.cmu.edu; Tue, 24 Mar 1998 09:58:56 -0500 (EST) Received: from po5.andrew.cmu.edu via qmail ID ; Tue, 24 Mar 1998 09:55:41 -0500 (EST) Received: from shiva.jussieu.fr (shiva.jussieu.fr [134.157.0.129]) by po5.andrew.cmu.edu (8.8.5/8.8.2) with ESMTP id JAA12530 for ; Tue, 24 Mar 1998 09:55:34 -0500 (EST) Received: from unix.artemis.jussieu.fr (root@unix.artemis.jussieu.fr [134.157.55.10]) by shiva.jussieu.fr (8.8.8/jtpda-5.3) with ESMTP id PAA15293 ; Tue, 24 Mar 1998 15:53:55 +0100 (CET) Received: from pelsys.com (dione.artemis.jussieu.fr [134.157.55.57]) by unix.artemis.jussieu.fr (8.8.7/jtpda-5.2) with ESMTP id PAA03492 ; Tue, 24 Mar 1998 15:45:20 GMT Message-ID: <3517C8A0.42C40750@pelsys.com> Date: Tue, 24 Mar 1998 15:52:17 +0100 From: aecl X-Mailer: Mozilla 4.03 [fr] (Win95; I) MIME-Version: 1.0 To: agentx@fv.com, hostmib@andrew.cmu.edu, rdbms@us.oracle.com, rmonmib@cisco.com, applmib@emi-summit.com Subject: (pas d'objet) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit subscribe From adm Thu Apr 16 10:48:12 1998 Delivery-Date: Thu, 16 Apr 1998 11:01:27 -0400 Return-Path: adm Received: (from adm@localhost) by ns.ietf.org (8.8.5/8.8.7a) id KAA05012 for ietf-123-outbound.10@ietf.org; Thu, 16 Apr 1998 10:45:02 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id JAA03090; Thu, 16 Apr 1998 09:44:34 -0400 (EDT) Message-Id: <199804161344.JAA03090@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: agentx@peer.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-agentx-mib-02.txt Date: Thu, 16 Apr 1998 09:44:34 -0400 Sender: cclark@cnri.reston.va.us --NextPart A New 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 : Definitions of Managed Objects for Extensible SNMP Agents Author(s) : M. Greene, S. Gudur Filename : draft-ietf-agentx-mib-02.txt Pages : 18 Date : 15-Apr-98 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. 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-mib-02.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-agentx-mib-02.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ftp.ietf.org US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-agentx-mib-02.txt". NOTE: The mail server at ietf.org 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@ietf.org" Content-Type: text/plain Content-ID: <19980415173543.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-agentx-mib-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-agentx-mib-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980415173543.I-D@ietf.org> --OtherAccess-- --NextPart-- From ashishkh@wipinfo.soft.net Wed Jun 24 11:07:35 1998 Delivery-Date: Wed, 24 Jun 1998 11:07:35 -0400 Return-Path: ashishkh@wipinfo.soft.net Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id BAA15261 for ; Wed, 24 Jun 1998 01:09:23 -0400 (EDT) Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id BAA13431 for ; Wed, 24 Jun 1998 01:11:39 -0400 (EDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id AAA25634 for ; Wed, 24 Jun 1998 00:09:15 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma025081; Wed, 24 Jun 98 00:08:01 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id AAA05077 for ; Wed, 24 Jun 1998 00:07:28 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma004469; Wed, 24 Jun 98 00:07:03 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id AAA08628; Wed, 24 Jun 1998 00:07:06 -0500 (CDT) Received: from almond.bmc.com (almond.bmc.com [172.17.0.100]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id WAA29666 for ; Tue, 23 Jun 1998 22:05:15 -0700 (PDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id AAA24667 for ; Wed, 24 Jun 1998 00:05:07 -0500 (CDT) Received: from agni.wipinfo.soft.net(164.164.6.20) by almond.bmc.com via smap (V2.0) id xma024635; Wed, 24 Jun 98 00:04:58 -0500 Received: from scan.wipinfo.soft.net by wipinfo.soft.net (SMI-8.6/SMI-SVR4) id KAA01078; Wed, 24 Jun 1998 10:29:54 -0500 Received: from 192.9.100.151 by scan.wipinfo.soft.net (InterScan E-Mail VirusWall NT) Received: from opel ([192.9.52.22]) by divya.wipinfo.soft.net (8.8.5/8.8.5) with SMTP id KAA16929 for ; Wed, 24 Jun 1998 10:36:09 +0530 Message-Id: <3.0.5.32.19980624103433.00946cb0@tagore> X-Sender: ashishkh@tagore X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (32) Date: Wed, 24 Jun 1998 10:34:33 To: agentx@peer.com From: Ashish Hanwadikar Subject: UNIX Domain Sockets Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Hi all, I want to know whether Microsoft NT/win95 supports UNIX Domain sockets or not. I searched for it msdn, but could not find it out. The Simple Times Article in March 1998 issue by Matt White on "An OverView of AgentX Protocol" says in "Security Issues" Subsection that "Fortunately, there are implementations of Unix domain sockets for all major platforms, including Microsoft Windows". If that is the case where can I get the implementation of UNIX domain sockets on NT/95? Thanks in advance, With Regds., Ashish Hanwadikar Technology Solutions, Wipro Limited Bangalore-27 http://www.geocities.com/SiliconValley/Bay/5393/ Email: ashishkh@writeme.com Ph: +91-80-2241730 Ext. 3315 From rpresuhn@dorothy.bmc.com Wed Jun 24 11:07:44 1998 Delivery-Date: Wed, 24 Jun 1998 11:07:44 -0400 Return-Path: rpresuhn@dorothy.bmc.com Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id TAA07260 for ; Tue, 23 Jun 1998 19:55:44 -0400 (EDT) Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id TAA12667 for ; Tue, 23 Jun 1998 19:57:49 -0400 (EDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id SAA14426 for ; Tue, 23 Jun 1998 18:55:15 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma014111; Tue, 23 Jun 98 18:54:26 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id SAA28877 for ; Tue, 23 Jun 1998 18:53:47 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma027544; Tue, 23 Jun 98 18:52:35 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id SAA09812; Tue, 23 Jun 1998 18:52:50 -0500 (CDT) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id QAA27732 for agentx@peer.com; Tue, 23 Jun 1998 16:51:01 -0700 (PDT) Date: Tue, 23 Jun 1998 16:51:01 -0700 (PDT) From: Randy Presuhn Message-Id: <199806232351.QAA27732@dorothy.bmc.com> To: agentx@peer.com Subject: Re: Transport Mappings Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi - > Date: Tue, 23 Jun 1998 15:59:45 > To: agentx@peer.com > From: Ashish Hanwadikar > Subject: Transport Mappings ... > 1) The Transport Mappings TCP and UNIX Domain Socket are compulsory or > optional? > The AgentX RFC just mentions the two transport Domains. However, it does > not say whether the Master Agent or Sub Agents should always implement TCP > or UNIX Domain Sockets. > > My guess is that the Transport Mappings are purely optional. ... That'd be my reading of the current words. I'd prefer it if support for the TCP mapping were mandatory, but I can live with the current language. > If implementation of Transport Mapping are purely optional, then detection > of whether master agent is running or not is difficult to be detected by > the subagent library or subagent implementation. ... It's not THAT hard. One can use getservbyname() as well as the old "just try it" approach. One can even do this to support multiple subagent protocols over multiple transports. ... > e) One more alternative here is to include the master agent code as a > separate module alongwith subagent api or code. Thus, if no master agent is > available then subagent implementation can take over that responsibility. > This behavior can be tailored through some parameter in the config files or > whatever mechanism available. ... Deja vu. The access rights needed within a system for a master agent (for privacy/authentication keys and access control information) should not be within reach of a typical subagent. It's one thing to trigger the activation of a master agent if none is found; it's quite another to BECOME the master agent if no one else is doing the job. ----------------------------------------------------------------------- Randy Presuhn Email: rpresuhn@bmc.com http://www.bmc.com Voice: +1 408 616-3100 BMC Software, Inc. 965 Stewart Drive Fax: +1 408 616-3101 Sunnyvale, California 94086 USA ----------------------------------------------------------------------- In accordance with the BMC Communications Systems Use and Security Policy, I explicitly state that although my affiliation with BMC may be apparent, implied, or provided, my opinions are not necessarily those of BMC Software and that all external representations on behalf of BMC must first be cleared with a member of "the top management team." ----------------------------------------------------------------------- From mwhite@andrew.cmu.edu Wed Jun 24 14:18:45 1998 Delivery-Date: Wed, 24 Jun 1998 14:18:46 -0400 Return-Path: mwhite@andrew.cmu.edu Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id LAA21645 for ; Wed, 24 Jun 1998 11:44:43 -0400 (EDT) Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id LAA15386 for ; Wed, 24 Jun 1998 11:46:54 -0400 (EDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id KAA25522 for ; Wed, 24 Jun 1998 10:44:32 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma025168; Wed, 24 Jun 98 10:43:28 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id KAA09576 for ; Wed, 24 Jun 1998 10:42:54 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma008744; Wed, 24 Jun 98 10:42:15 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id KAA00286; Wed, 24 Jun 1998 10:41:54 -0500 (CDT) Received: from almond.bmc.com (almond.bmc.com [172.17.0.100]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id IAA02147 for ; Wed, 24 Jun 1998 08:37:12 -0700 (PDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id KAA24340 for ; Wed, 24 Jun 1998 10:37:09 -0500 (CDT) Received: from cmu1.acs.cmu.edu(128.2.35.186) by almond.bmc.com via smap (V2.0) id xma024323; Wed, 24 Jun 98 10:36:50 -0500 Received: from freehold.net.cmu.edu (FREEHOLD.NET.CMU.EDU [128.2.6.69]) by cmu1.acs.cmu.edu (8.8.5/8.8.5) with SMTP id LAA20936; Wed, 24 Jun 1998 11:33:04 -0400 (EDT) Date: Wed, 24 Jun 1998 11:33:03 -0400 (EDT) From: Matthew White X-Sender: mwhite@freehold.net.cmu.edu To: Ashish Hanwadikar cc: agentx@peer.com Subject: Re: UNIX Domain Sockets In-Reply-To: <3.0.5.32.19980624103433.00946cb0@tagore> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Ashish: The Cygnus GCC for windows supports unix domain sockets. You can get more information from http://www.cygnus.com/. -Matt On Wed, 24 Jun 1998, Ashish Hanwadikar wrote: > Hi all, > I want to know whether Microsoft NT/win95 supports UNIX Domain > sockets or not. I searched for it msdn, but could not find it out. The > Simple Times Article in March 1998 issue by Matt White on "An OverView of > AgentX Protocol" says in "Security Issues" Subsection that "Fortunately, > there are implementations of Unix domain sockets for all major platforms, > including Microsoft Windows". > If that is the case where can I get the implementation of UNIX domain > sockets on NT/95? > Thanks in advance, > > With Regds., > Ashish Hanwadikar > Technology Solutions, > Wipro Limited > Bangalore-27 > http://www.geocities.com/SiliconValley/Bay/5393/ > Email: ashishkh@writeme.com > Ph: +91-80-2241730 Ext. 3315 > > ---------- Matt White Network Systems Designer Carnegie Mellon Computing Services From daniele@zk3.dec.com Thu Jun 25 13:39:13 1998 Delivery-Date: Thu, 25 Jun 1998 13:39:13 -0400 Return-Path: daniele@zk3.dec.com Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id NAA10217 for ; Thu, 25 Jun 1998 13:39:12 -0400 (EDT) Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id NAA20853 for ; Thu, 25 Jun 1998 13:41:33 -0400 (EDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id MAA09830 for ; Thu, 25 Jun 1998 12:39:12 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma009682; Thu, 25 Jun 98 12:38:43 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id MAA24670 for ; Thu, 25 Jun 1998 12:38:11 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma024119; Thu, 25 Jun 98 12:37:31 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id MAA01688; Thu, 25 Jun 1998 12:36:39 -0500 (CDT) Received: from cashew.bmc.com (cashew.bmc.com [172.19.0.100]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id KAA16172 for ; Thu, 25 Jun 1998 10:25:23 -0700 (PDT) Received: (from uucp@localhost) by cashew.bmc.com (8.8.8/8.8.8) id MAA08198 for ; Thu, 25 Jun 1998 12:25:23 -0500 (CDT) Received: from mail11.digital.com(192.208.46.10) by cashew.bmc.com via smap (V2.0) id xma008191; Thu, 25 Jun 98 12:25:03 -0500 Received: from quarry.zk3.dec.com (fquarry.zk3.dec.com [16.140.160.9]) by mail11.digital.com (8.8.8/8.8.8/WV1.0f) with SMTP id NAA27472 for ; Thu, 25 Jun 1998 13:24:57 -0400 (EDT) Received: from bernie.zk3.dec.com by quarry.zk3.dec.com; (5.65v4.0/1.1.8.2/16Jan95-0946AM) id AA17978; Thu, 25 Jun 1998 13:24:56 -0400 Received: from localhost by bernie.zk3.dec.com; (5.65/1.1.8.2/22Aug96-1117AM) id AA04982; Thu, 25 Jun 1998 13:24:57 -0400 Message-Id: <9806251724.AA04982@bernie.zk3.dec.com> To: agentx@peer.com Subject: Testing: some early results and net availability Date: Thu, 25 Jun 98 13:24:57 -0400 From: Mike Daniele X-Mts: smtp Hi, We've done some testing of DEC's subagent library vis a vis Peer/BMC's master agent. In general, the news is good. We've been able to open a session, register multiple regions, and have some SNMP Get and GetNext requests handled correctly end to end. I wanted to note 2 things that might help avoid problems for others: 1) SearchRange ending OID Cannot be identical to the SearchRange starting OID. 7.2.2.2 states that for next/bulk, a subagent must return a variable such that > - If the ending OID is not null, the variable's name > lexicographically precedes the ending OID. If the SearchRange's ending oid == its starting oid, the subagent can't legally return anything. 2) Register PDU's optional range upper bound (r.upper_bound) This field is present only if r.range_subid is non-zero. If r.range_subid is 0, the PDU ends with r.region. It does NOT contain (a 0-valued) r.upper_bound in this case. Note to editors: We should discuss r.upper_bound in sections 6.2.3 and 6.2.4 in a separate paragraph, just like we do with all the other fields. We should also include an example that has no upper bound. We have master and subagents available for testing (via TCP over the internet) if other folks are interested in doing so before the bakeoff. Thanks Lauren @ BMC, the testing so far has been very valuable. Regards, Mike From bnatale@acecomm.com Tue Jun 30 12:01:54 1998 Delivery-Date: Tue, 30 Jun 1998 12:01:55 -0400 Return-Path: bnatale@acecomm.com Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id MAA18093 for ; Tue, 30 Jun 1998 12:01:54 -0400 (EDT) Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id MAA10817 for ; Tue, 30 Jun 1998 12:04:11 -0400 (EDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id LAA13829 for ; Tue, 30 Jun 1998 11:01:49 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma013522; Tue, 30 Jun 98 11:00:37 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id LAA17973 for ; Tue, 30 Jun 1998 11:00:02 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma016958; Tue, 30 Jun 98 10:59:03 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id KAA13465; Tue, 30 Jun 1998 10:59:06 -0500 (CDT) Received: from almond.bmc.com (almond.bmc.com [172.17.0.100]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id IAA18530 for ; Tue, 30 Jun 1998 08:43:43 -0700 (PDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id KAA11264 for ; Tue, 30 Jun 1998 10:43:41 -0500 (CDT) Received: from relay2.smtp.psi.net(38.8.188.2) by almond.bmc.com via smap (V2.0) id xma011245; Tue, 30 Jun 98 10:43:11 -0500 Received: from [192.152.208.5] (helo=acecomm.com) by relay2.smtp.psi.net with smtp (Exim 1.90 #1) for agentx@peer.com id 0yr2YW-0000bN-00; Tue, 30 Jun 1998 11:42:58 -0400 Received: from bnatale by acecomm.com (5.65/3.2.083191-ACE*COMM) id AA06228; Tue, 30 Jun 1998 11:45:00 -0400 Message-Id: <9806301545.AA06228@acecomm.com> X-Sender: natale@nips.acec.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Tue, 30 Jun 1998 11:44:41 -0400 To: agentx@peer.com From: Bob Natale Subject: Updated goals and milestones Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA18093 Hi, The AgentX page at www.ietf.org has been updated with the following: Goals and Milestones: Done Publication of AgentX protocol specification Done Submit working draft version of AgentX MIB I-D. Jun 98 Collect and evaluate implementation reports (through bake-off). Jul 98 Conduct AgentX interoperability testing (July 23-24, Sunnyvale). Aug 98 Meet at 42nd IETF-Chicago (refine or revise RFC 2257). Sep 98 Petition IESG to advance RFC 2257 to Draft or recycle at Proposed Oct 98 Submit final version of AgentX MIB I-D to IESG for consideration as Proposed. Nov 98 Submit initial draft version of AgentX API I-D Dec 98 Submit interim draft version of AgentX API I-D. Jan 99 Submit final version of AgentX API I-D to IESG for consideration as an Informational RFC. Feb 99 Evaluate necessary revisions to RFC 2257. Feb 99 Evaluate necessary revisions to AgentX MIB RFC. Mar 99 Meet at 44th IETF to Assess status of AgentX deployment Determine need for AgentX v2 (Protocol, MIB, or API) Plan future work items accordingly. Apr 99 Submit new charter proposal to IESG or retire WG. I have submitted a request for a single 2hr meeting slot in Chicago...I have not yet received notification of the scheduled time and place. The basic agenda will include: - the usual preliminaries - review implementation status reports - review bake-off results, findings - review list of open issues - review status of AgentX MIB - review need/desire for a standard AgentX API - review status of SNMPv3 and DISMAN wrt AgentX - recommend working plan wrt any of the above items - the usual summaries Comments on any of the above are welcomed...as are proposed mods (additions/deletions/changes) to the agenda outline. Cordially, BobN ------------ ISO 9001 Registered Quality Supplier ----------- Bob Natale         | ACE*COMM              | 301-721-3000 [v] Dir, Net Mgmt Prod | 704 Quince Orchard Rd | 301-721-3001 [f] bnatale@acecomm.com| Gaithersburg MD 20878 | www.acecomm.com ------------- Free downloads at www.winsnmp.com ------------- From ashishkh@wipinfo.soft.net Wed Jul 1 05:08:46 1998 Delivery-Date: Wed, 01 Jul 1998 05:08:47 -0400 Return-Path: ashishkh@wipinfo.soft.net Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id FAA06581 for ; Wed, 1 Jul 1998 05:08:43 -0400 (EDT) Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id FAA14628 for ; Wed, 1 Jul 1998 05:10:54 -0400 (EDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id EAA00633 for ; Wed, 1 Jul 1998 04:08:34 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma000192; Wed, 1 Jul 98 04:07:11 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id EAA03319 for ; Wed, 1 Jul 1998 04:06:36 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma002808; Wed, 1 Jul 98 04:06:00 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id EAA08592; Wed, 1 Jul 1998 04:06:13 -0500 (CDT) Received: from almond.bmc.com (almond.bmc.com [172.17.0.100]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id CAA17702 for ; Wed, 1 Jul 1998 02:02:39 -0700 (PDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id EAA29692 for ; Wed, 1 Jul 1998 04:02:27 -0500 (CDT) Received: from agni.wipinfo.soft.net(164.164.6.20) by almond.bmc.com via smap (V2.0) id xma029655; Wed, 1 Jul 98 04:02:10 -0500 Received: from scan.wipinfo.soft.net by wipinfo.soft.net (SMI-8.6/SMI-SVR4) id OAA00601; Wed, 1 Jul 1998 14:26:07 -0500 Received: from 192.9.100.151 by scan.wipinfo.soft.net (InterScan E-Mail VirusWall NT) Received: from opel ([192.9.52.22]) by divya.wipinfo.soft.net (8.8.5/8.8.5) with SMTP id OAA07687; Wed, 1 Jul 1998 14:32:22 +0530 Reply-To: From: "Ashish K Hanwadikar" To: "Bob Natale" Cc: "Agentx" Subject: RE: Updated goals and milestones Date: Wed, 1 Jul 1998 14:31:07 +0530 Keywords: Mailing Lists Message-ID: <000501bda4ce$c904dfc0$163409c0@opel.wipinfo.soft.net> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Reply-By: Mon, 6 Jul 1998 18:00:00 +0530 In-Reply-To: <9806301545.AA06228@acecomm.com> X-Message-Flag: Follow up Content-Type: text/plain; charset="iso-8859-1" X-MIME-Autoconverted: from 8bit to quoted-printable by tangelo.bmc.com id EAA08592 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id FAA06581 Hi, Is the AgentX API I-D going to be an information RFC or a standard RFC? Where can I get more information about the efforts on AgentX API (mailing lists, working groups etc.)? Also, one more thing, the AgentX-Close-PDU when sent by Sub Agent to Master Agent does not require master agent to respond until there is an error in closing the session. This is unnecessarily making the implementation complicated. Why can't master agent send response to all agentx-close-PDUs irrespective of the outcome? Otherwise, the sub agent has to keep on waiting for the response to agentx-close-PDU, when he don't even know whether there will be any response or not. The same is true for agentx-notify-PDU. The implementation becomes very complicated when we have to design a generic sub agent API. What should be the semantics of the call agent-close-session(sessionID), blocking or non-blocking? If it is non-blocking what happens when there is error in closing the session and response is received from the master agent? If it is made blocking and there is no resonse because the session was closed successfuly then how long should the call block? This waiting on the sub agent side is a general problem. What should be the timeout values from the sub agent side, i.e. for how long should the sub agent wait for responses from the master agent for various PDU's like registration etc. Thanks in advance. > -----Original Message----- > From: Bob Natale [mailto:bnatale@acecomm.com] > Sent: Tuesday, June 30, 1998 9:15 PM > To: agentx@peer.com > Subject: Updated goals and milestones > > > Hi, > > The AgentX page at www.ietf.org has been > updated with the > following: > > Goals and Milestones: > > Done Publication of AgentX protocol specification > Done Submit working draft version of AgentX MIB I-D. > Jun 98 Collect and evaluate implementation reports > (through bake-off). > Jul 98 Conduct AgentX interoperability testing > (July 23-24, Sunnyvale). > Aug 98 Meet at 42nd IETF-Chicago (refine or revise > RFC 2257). > Sep 98 Petition IESG to advance RFC 2257 to Draft > or recycle at Proposed > Oct 98 Submit final version of AgentX MIB I-D to > IESG for consideration as Proposed. > Nov 98 Submit initial draft version of AgentX API I-D > Dec 98 Submit interim draft version of AgentX API I-D. > Jan 99 Submit final version of AgentX API I-D to IESG > for consideration as an Informational RFC. > Feb 99 Evaluate necessary revisions to RFC 2257. > Feb 99 Evaluate necessary revisions to AgentX MIB RFC. > Mar 99 Meet at 44th IETF to > Assess status of AgentX deployment > Determine need for AgentX v2 (Protocol, MIB, or API) > Plan future work items accordingly. > Apr 99 Submit new charter proposal to IESG or retire WG. > > I have submitted a request for a single 2hr meeting slot in > Chicago...I have not yet received notification of the scheduled > time and place. The basic agenda will include: > > - the usual preliminaries > - review implementation status reports > - review bake-off results, findings > - review list of open issues > - review status of AgentX MIB > - review need/desire for a standard AgentX API > - review status of SNMPv3 and DISMAN wrt AgentX > - recommend working plan wrt any of the above items > - the usual summaries > > Comments on any of the above are welcomed...as are proposed > mods (additions/deletions/changes) to the agenda outline. > > Cordially, > > BobN > ------------ ISO 9001 Registered Quality Supplier ----------- > Bob Natale         | ACE*COMM              | 301-721-3000 [v] > Dir, Net Mgmt Prod | 704 Quince Orchard Rd | 301-721-3001 [f] > bnatale@acecomm.com| Gaithersburg MD 20878 | > www.acecomm.com > ------------- Free downloads at www.winsnmp.com > ------------- > > From bnatale@acecomm.com Mon Jul 6 11:28:18 1998 Delivery-Date: Mon, 06 Jul 1998 11:28:19 -0400 Return-Path: bnatale@acecomm.com Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id LAA24913 for ; Mon, 6 Jul 1998 11:28:18 -0400 (EDT) Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id LAA03235 for ; Mon, 6 Jul 1998 11:30:38 -0400 (EDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id KAA23089 for ; Mon, 6 Jul 1998 10:28:11 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma022849; Mon, 6 Jul 98 10:27:04 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id KAA13780 for ; Mon, 6 Jul 1998 10:26:30 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma013317; Mon, 6 Jul 98 10:26:08 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id KAA14187; Mon, 6 Jul 1998 10:25:55 -0500 (CDT) Received: from almond.bmc.com (almond.bmc.com [172.17.0.100]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id IAA29874 for ; Mon, 6 Jul 1998 08:18:41 -0700 (PDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id KAA22297 for ; Mon, 6 Jul 1998 10:18:38 -0500 (CDT) Received: from relay2.smtp.psi.net(38.8.188.2) by almond.bmc.com via smap (V2.0) id xma022295; Mon, 6 Jul 98 10:18:27 -0500 Received: from [192.152.208.5] (helo=acecomm.com) by relay2.smtp.psi.net with smtp (Exim 1.90 #1) for agentx@peer.com id 0ytD24-0001tf-00; Mon, 6 Jul 1998 11:18:21 -0400 Received: from bnatale by acecomm.com (5.65/3.2.083191-ACE*COMM) id AA00601; Mon, 6 Jul 1998 11:20:39 -0400 Message-Id: <9807061520.AA00601@acecomm.com> X-Sender: natale@nips.acec.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Mon, 06 Jul 1998 11:20:25 -0400 To: agentx@peer.com From: Bob Natale Subject: Fwd: 42nd IETF-CHICAGO, IL: AGENTX Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" >Date: Mon, 06 Jul 1998 10:54:59 -0400 >From: Marcia Beaulieu >This is to confirm one session for AGENTX as follows: > > Wednesday, August 26 at 1530-1730 > > Other groups scheduled at that time: ip1394, > Routing Area Meeting, avt We must submit a formal agenda by Aug 19. I have already posted (on Jun 30) the outline candidate agenda included below. Please post any suggested changes to the list (or to me directly if you prefer). Thanks. The basic agenda will include: - the usual preliminaries - review implementation status reports - review bake-off results, findings - review list of open issues - review status of AgentX MIB - review need/desire for a standard AgentX API - review status of SNMPv3 and DISMAN wrt AgentX - recommend working plan wrt any of the above items - the usual summaries Cordially, BobN ------------ ISO 9001 Registered Quality Supplier ----------- Bob Natale | ACE*COMM | 301-721-3000 [v] Dir, Net Mgmt Prod | 704 Quince Orchard Rd | 301-721-3001 [f] bnatale@acecomm.com| Gaithersburg MD 20878 | www.acecomm.com ------------- Free downloads at www.winsnmp.com ------------- From uglyware@berkscountypa.com Thu Jul 16 02:50:38 1998 Delivery-Date: Thu, 16 Jul 1998 02:50:39 -0400 Return-Path: uglyware@berkscountypa.com Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id CAA08466 for ; Thu, 16 Jul 1998 02:50:38 -0400 (EDT) From: uglyware@berkscountypa.com Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id CAA19048 for ; Thu, 16 Jul 1998 02:50:34 -0400 (EDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id BAA05076 for ; Thu, 16 Jul 1998 01:50:38 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma004777; Thu, 16 Jul 98 01:49:41 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id BAA25510 for ; Thu, 16 Jul 1998 01:49:05 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma025284; Thu, 16 Jul 98 01:48:34 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id BAA20526; Thu, 16 Jul 1998 01:48:45 -0500 (CDT) Received: from almond.bmc.com (almond.bmc.com [172.17.0.100]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id XAA07395 for ; Wed, 15 Jul 1998 23:41:12 -0700 (PDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id BAA04079 for ; Thu, 16 Jul 1998 01:41:11 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma004065; Thu, 16 Jul 98 01:40:45 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id BAA23228 for ; Thu, 16 Jul 1998 01:40:12 -0500 (CDT) Date: Thu, 16 Jul 1998 01:40:12 -0500 (CDT) Message-Id: <199807160640.BAA23228@dresden.bmc.com> Received: from unknown(205.148.246.213) by dresden.bmc.com via smap (3.2) id xma023215; Thu, 16 Jul 98 01:40:05 -0500 To: agentx@peer.com Subject: Public Service - S.M.A.R.T. Sensor As a public service, Higher Ground Diagnostics, Inc. is offering a free download of the Hard Drive Mechanics S.M.A.R.T. sensor. This program will check your PC for the presence of *Predictive* technology installed into most hard drives built after 1996. This technology is capable of determining when hard drive failures will occur. If your hard drive has the S.M.A.R.T. technology, then your PC already has the ability to detect hard drive crashes, weeks even months before they actually occur. To take advantage of the S.M.A.R.T. technology, you simply need to access it. As a free public service, the S.M.A.R.T. tester can be downloaded from http://www.uglyware.com/deluxe/ The S.M.A.R.T. tester has been checked for viruses and may be downloaded safely from that website. Zandy Carter International Marketing Manager From agentx-bugs@andrew.cmu.edu Fri Jul 17 13:46:49 1998 Delivery-Date: Fri, 17 Jul 1998 13:46:50 -0400 Return-Path: agentx-bugs@andrew.cmu.edu Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id NAA12346 for ; Fri, 17 Jul 1998 13:46:49 -0400 (EDT) From: agentx-bugs@andrew.cmu.edu Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id NAA27198 for ; Fri, 17 Jul 1998 13:46:39 -0400 (EDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id MAA08130 for ; Fri, 17 Jul 1998 12:46:43 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma007598; Fri, 17 Jul 98 12:45:05 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id MAA26914 for ; Fri, 17 Jul 1998 12:44:31 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma025612; Fri, 17 Jul 98 12:43:35 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id MAA22575; Fri, 17 Jul 1998 12:43:50 -0500 (CDT) Received: from cashew.bmc.com (cashew.bmc.com [172.19.0.100]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id JAA26493 for ; Fri, 17 Jul 1998 09:27:31 -0700 (PDT) Received: (from uucp@localhost) by cashew.bmc.com (8.8.8/8.8.8) id LAA05633 for ; Fri, 17 Jul 1998 11:27:25 -0500 (CDT) Received: from gauntlet.fv.com(207.67.199.118) by cashew.bmc.com via smap (V2.0) id xma005619; Fri, 17 Jul 98 11:27:02 -0500 Received: from shekel.fv.com (shekel.fv.com [207.67.199.130]) by gauntlet.fv.com (8.9.1/8.9.0) with ESMTP id JAA26845 for ; Fri, 17 Jul 1998 09:25:53 -0700 (PDT) Received: from gauntlet.fv.com (gauntlet-in.fv.com [10.0.0.2]) by shekel.fv.com (8.9.1/8.9.1) with ESMTP id JAA04153 for ; Fri, 17 Jul 1998 09:26:45 -0700 (PDT) Received: from mail1.andrew.cmu.edu (MAIL1.ANDREW.CMU.EDU [128.2.10.131]) by gauntlet.fv.com (8.9.1/8.9.0) with ESMTP id JAA26831 for ; Fri, 17 Jul 1998 09:25:42 -0700 (PDT) Received: from po4.andrew.cmu.edu (PO4.ANDREW.CMU.EDU [128.2.10.104]) by mail1.andrew.cmu.edu (8.8.5/8.8.2) with ESMTP id MAA11804 for ; Fri, 17 Jul 1998 12:26:41 -0400 (EDT) Received: (from daemon@localhost) by po4.andrew.cmu.edu (8.8.5/8.8.2) id MAA23553 for post+internet.computing.agentx@MAIL1.ANDREW.CMU.EDU; Fri, 17 Jul 1998 12:26:38 -0400 (EDT) Received: via switchmail for post+internet.computing.agentx@andrew.cmu.edu; Fri, 17 Jul 1998 12:26:36 -0400 (EDT) Received: from cmu1.acs.cmu.edu (CMU1.ACS.CMU.EDU [128.2.35.186]) by po4.andrew.cmu.edu (8.8.5/8.8.2) with ESMTP id MAA23530; Fri, 17 Jul 1998 12:26:26 -0400 (EDT) Received: from FRAUGHT.NET.CMU.EDU (FRAUGHT.NET.CMU.EDU [128.2.6.66]) by cmu1.acs.cmu.edu (8.8.5/8.8.5) with SMTP id MAA24850; Fri, 17 Jul 1998 12:26:22 -0400 (EDT) Date: Fri, 17 Jul 1998 12:28:33 -0400 To: post+internet.computing.agentx@andrew.cmu.edu Subject: CMU AgentX v0.1.1 available Message-ID: <3030348966.900678513@FRAUGHT.NET.CMU.EDU> X-Mailer: Mulberry (Win32) [1.3.3, s/n S-100002] X-Authenticated: mwhite by cyrus.andrew.cmu.edu X-Licensed-To: site license MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I have made a second alpha quality release of our AgentX subagent library and snmpd available for FTP. While there are still several protocol features that need to be implemented, we have verified that we interoperate with Digital's implementation of the AgentX protocol. The web site for the CMU AgentX project is located at; http://www.net.cmu.edu/projects/agentx/ Commnets or questions should be addressed to: agentx-bug@andrew.cmu.edu Thanks to all who have shown interest in our work. Matt White ---------- Matt White Maintainer, AgentX Implementation Carnegie Mellon Computing Services From ashishkh@wipinfo.soft.net Fri Jul 31 11:28:58 1998 Delivery-Date: Fri, 31 Jul 1998 11:28:58 -0400 Return-Path: ashishkh@wipinfo.soft.net Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id LAA21286 for ; Fri, 31 Jul 1998 11:28:56 -0400 (EDT) Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id LAA28480 for ; Fri, 31 Jul 1998 11:27:34 -0400 (EDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id KAA17698 for ; Fri, 31 Jul 1998 10:27:48 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma017391; Fri, 31 Jul 98 10:26:49 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id KAA18543 for ; Fri, 31 Jul 1998 10:26:10 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma017781; Fri, 31 Jul 98 10:25:34 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id KAA18474; Fri, 31 Jul 1998 10:25:49 -0500 (CDT) Received: from almond.bmc.com (almond.bmc.com [172.17.0.100]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id GAA11429 for ; Fri, 31 Jul 1998 06:59:40 -0700 (PDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id IAA11006 for ; Fri, 31 Jul 1998 08:59:38 -0500 (CDT) Received: from agni.wipinfo.soft.net(164.164.6.20) by almond.bmc.com via smap (V2.0) id xma010837; Fri, 31 Jul 98 08:59:03 -0500 Received: from tagore.wipinfo.soft.net by wipinfo.soft.net (SMI-8.6/SMI-SVR4) id TAA09690; Fri, 31 Jul 1998 19:23:51 -0500 From: "Ashish Hanwadikar" To: "Agentx" Cc: "RAMAKUMARA K" Subject: Sub Agent Processing of AgentX GetNext Response Date: Fri, 31 Jul 1998 19:29:15 +0530 Message-ID: <005301bdbc8b$67266f10$163409c0@opel.wipinfo.soft.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0054_01BDBCB9.80DEAB10" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 This is a multi-part message in MIME format. ------=_NextPart_000_0054_01BDBCB9.80DEAB10 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi all, While going through the AgentX RFC we noticed one ambiguity: "Section 7.2.2.2. Subagent Processing of the agentx-GetNext-PDU Upon the subagent's receipt of an agentx-GetNext-PDU, each SearchRange in the request is processed as follows: (1) The subagent searches for a variable within the lexicographically ordered list of variable names for all variables it instantiates (without regard to registration of regions) within the indicated context and session, for which the following are all true:" Suppose master agent sends AgentX GetNext request to a subagent (Sub Agent #1) with a SearchRange (falling under a target MIB Region #1). The sub agent responds with a oid and its value falling under a different MIB Region (lexicographically after MIB Region #1). Lets call these region as MIB Region #2. Now suppose another sub agent had registered an MIB Region #3. The lexicographical relationship is MIB Region #1 < #3 < #2 That means, if the SearchRange doesn't fall within MIB Region #1, then ideally target sub agent should return endOfMIBView. The Master Agent will find lexicographically next region, i.e. MIB Region #3 (by subagent #2) and resend the request to sub agent #2. If first sub agent returns the oid and value from MIB Region #2 (as he has to search through a list of lexicographically ordered list of instantiated variables without regard to registration of region), then the SNMP Response for SNMP GetNext will be wrong. Either this is a error or it is not clear what is meant by "without regard to registration of MIB region". Please clarify. Also, in the section "7.2.4.3. Processing of Responses to agentx-GetNext-PDU and agentx-GetBulk-PDU ", the Master Agent never checks whether for each oid in the VarBind the response returned by a sub agent is valid or not. I think the master agent should check whether, for the oid in the varbind, the response returned by the sub agent is falling within the target MIB Region (which he determined while preparing the AgentX GetNext PDU for that particular sub agent). Thanks. With regards, Ashish K Hanwadikar Senior Software Engineer, Wipro Infotech, Technology Solutions, Bangalore INDIA ------=_NextPart_000_0054_01BDBCB9.80DEAB10 Content-Type: text/x-vcard; name="Ashish K Hanwadikar.vcf" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="Ashish K Hanwadikar.vcf" BEGIN:VCARD VERSION:2.1 N:Hanwadikar;Ashish;K;; FN:Ashish K Hanwadikar ORG:Wipro Infotech, Technology Solutions;Technology Solutions TITLE:Senior Software Engineer TEL;WORK;VOICE:+91-80-2241730 Ext. 3315 TEL;HOME;VOICE:+91-80-2241730 Ext. 3315 ADR;WORK:;Mission Road LABEL;WORK:Mission Road ADR;HOME;ENCODING=3DQUOTED-PRINTABLE:;;Wipro Limited=3D0D=3D0A30 Mission = Road,=3D0D=3D0A1st Main,=3D0D=3D0AS.R. Nagar;Bangalo=3D re;Karnataka;560 027;INDIA LABEL;HOME;ENCODING=3DQUOTED-PRINTABLE:Wipro Limited=3D0D=3D0A30 Mission = Road,=3D0D=3D0A1st Main,=3D0D=3D0AS.R. Nagar=3D0D=3D0ABang=3D alore, Karnataka 560 027=3D0D=3D0AINDIA URL:http://www.geocities.com/SiliconValley/Bay/5393/ URL:http://www.geocities.com/SiliconValley/Bay/5393 EMAIL;PREF;INTERNET:ashishkh@wipinfo.soft.net REV:19980630T133122Z END:VCARD ------=_NextPart_000_0054_01BDBCB9.80DEAB10-- From daniele@zk3.dec.com Fri Jul 31 13:15:58 1998 Delivery-Date: Fri, 31 Jul 1998 13:16:00 -0400 Return-Path: daniele@zk3.dec.com Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id NAA25631 for ; Fri, 31 Jul 1998 13:15:56 -0400 (EDT) Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id NAA29347 for ; Fri, 31 Jul 1998 13:15:25 -0400 (EDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id MAA27276 for ; Fri, 31 Jul 1998 12:15:41 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma026670; Fri, 31 Jul 98 12:13:53 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id MAA07608 for ; Fri, 31 Jul 1998 12:13:14 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma006461; Fri, 31 Jul 98 12:12:24 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id MAA21709; Fri, 31 Jul 1998 12:12:37 -0500 (CDT) Received: from almond.bmc.com (almond.bmc.com [172.17.0.100]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id JAA12460 for ; Fri, 31 Jul 1998 09:58:58 -0700 (PDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id LAA25297 for ; Fri, 31 Jul 1998 11:58:56 -0500 (CDT) Received: from mail11.digital.com(192.208.46.10) by almond.bmc.com via smap (V2.0) id xma025290; Fri, 31 Jul 98 11:58:49 -0500 Received: from quarry.zk3.dec.com (fquarry.zk3.dec.com [16.140.160.9]) by mail11.digital.com (8.8.8/8.8.8/WV1.0f) with SMTP id MAA15672; Fri, 31 Jul 1998 12:57:52 -0400 (EDT) Received: from bernie.zk3.dec.com by quarry.zk3.dec.com; (5.65v4.0/1.1.8.2/16Jan95-0946AM) id AA06644; Fri, 31 Jul 1998 12:57:51 -0400 Received: from localhost by bernie.zk3.dec.com; (5.65/1.1.8.2/22Aug96-1117AM) id AA20179; Fri, 31 Jul 1998 12:58:03 -0400 Message-Id: <9807311658.AA20179@bernie.zk3.dec.com> To: "Ashish Hanwadikar" Cc: agentx@peer.com Subject: Re: Sub Agent Processing of AgentX GetNext Response In-Reply-To: Your message of "Fri, 31 Jul 98 19:29:15 +0530." <005301bdbc8b$67266f10$163409c0@opel.wipinfo.soft.net> Date: Fri, 31 Jul 98 12:58:03 -0400 From: Mike Daniele X-Mts: smtp Hi Ashish, > If first sub agent returns the oid and value from MIB Region #2 (as he has >to search through a list of lexicographically ordered list of instantiated >variables without regard to registration of region), then the SNMP Response >for SNMP GetNext will be wrong. > Either this is a error or it is not clear what is meant by "without regard >to registration of MIB region". Please clarify. > Also, in the section "7.2.4.3. Processing of Responses to >agentx-GetNext-PDU and agentx-GetBulk-PDU ", the Master Agent never checks >whether for each oid in the VarBind the response returned by a sub agent is >valid or not. I think the master agent should check whether, for the oid in >the varbind, the response returned by the sub agent is falling within the >target MIB Region (which he determined while preparing the AgentX GetNext >PDU for that particular sub agent). 7.2.1 states 1) Honoring the registry Because AgentX supports overlapping registrations, it is possible for the master agent to obtain a value for a requested varbind from within multiple registered MIB regions. The master agent must ensure that the value (or exception) actually returned in the SNMP response PDU is taken from the authoritative region (as defined in section 7.1.5.1). I think this "blanket rule" covers your concerns. Note that the master agent may use the ending oid of the searchrange to "scope" the instances the subagent may return, as described in 2) of section 7.2.1, and 7.2.2.2. Does this make it clear? Regards, Mike From sgudur@hotmail.com Fri Jul 31 13:40:32 1998 Delivery-Date: Fri, 31 Jul 1998 13:40:32 -0400 Return-Path: sgudur@hotmail.com Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id NAA26257 for ; Fri, 31 Jul 1998 13:40:31 -0400 (EDT) Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id NAA29464 for ; Fri, 31 Jul 1998 13:40:14 -0400 (EDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id MAA29816 for ; Fri, 31 Jul 1998 12:40:13 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma029406; Fri, 31 Jul 98 12:39:14 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id MAA01953 for ; Fri, 31 Jul 1998 12:38:34 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma001305; Fri, 31 Jul 98 12:38:01 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id MAA28932; Fri, 31 Jul 1998 12:38:19 -0500 (CDT) Received: from cashew.bmc.com (cashew.bmc.com [172.19.0.100]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id KAA12551 for ; Fri, 31 Jul 1998 10:33:03 -0700 (PDT) Received: (from uucp@localhost) by cashew.bmc.com (8.8.8/8.8.8) id MAA07662 for ; Fri, 31 Jul 1998 12:33:01 -0500 (CDT) Received: from f220.hotmail.com(207.82.251.111) by cashew.bmc.com via smap (V2.0) id xma007630; Fri, 31 Jul 98 12:32:35 -0500 Received: (qmail 29030 invoked by uid 0); 31 Jul 1998 17:32:29 -0000 Message-ID: <19980731173229.29029.qmail@hotmail.com> Received: from 152.67.249.57 by www.hotmail.com with HTTP; Fri, 31 Jul 1998 10:32:29 PDT X-Originating-IP: [152.67.249.57] From: "Smitha Gudur" To: agentx@peer.com Subject: open issues in agentX MIB Content-Type: text/plain Date: Fri, 31 Jul 1998 10:32:29 PDT Hi, Some of the open issues that needs to be addressed for agentx MIB include: 1. Relevance of agentxConnNumber, and agentxSessionNumber. This gives the number of entries in each respective table. Do we need these in the tables? 2. Add agentXLastChange to RegistrationTable to be consistent with the other tables. If there are any other open items that need to be addressed in the MIB, I urge everyone on the mailing list to send them as early as possible. These need to be resolved before the Chicago IETF meeting in August. Please send all email to agentx mailing list. thanks smitha ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com From fenner@parc.xerox.com Fri Jul 31 15:09:32 1998 Delivery-Date: Fri, 31 Jul 1998 15:09:33 -0400 Return-Path: fenner@parc.xerox.com Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id PAA28204 for ; Fri, 31 Jul 1998 15:09:32 -0400 (EDT) Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id PAA00009 for ; Fri, 31 Jul 1998 15:09:17 -0400 (EDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id OAA07003 for ; Fri, 31 Jul 1998 14:09:19 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma006340; Fri, 31 Jul 98 14:07:23 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id OAA29431 for ; Fri, 31 Jul 1998 14:06:46 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma028224; Fri, 31 Jul 98 14:05:54 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id OAA26344; Fri, 31 Jul 1998 14:06:11 -0500 (CDT) Received: from almond.bmc.com (almond.bmc.com [172.17.0.100]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id LAA13234 for ; Fri, 31 Jul 1998 11:51:47 -0700 (PDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id NAA04931 for ; Fri, 31 Jul 1998 13:51:46 -0500 (CDT) Received: from omega.xerox.com(13.1.64.95) by almond.bmc.com via smap (V2.0) id xma004880; Fri, 31 Jul 98 13:51:16 -0500 Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <40677(2)>; Fri, 31 Jul 1998 11:51:05 PDT Received: by crevenia.parc.xerox.com id <177515>; Fri, 31 Jul 1998 11:50:55 -0700 From: Bill Fenner To: agentx@peer.com Subject: Can an AgnetX sub-agent send an AgentX-GET PDU to the AgentX master? Cc: fenner@parc.xerox.com Message-Id: <98Jul31.115055pdt.177515@crevenia.parc.xerox.com> Date: Fri, 31 Jul 1998 11:50:52 PDT Hi, Let's say I have a routing daemon which wants to present a MIB which happens to include ifindex values. However, the local interface to ifindex value mapping happens in a different subagent; the routing daemon doesn't know what this mapping is. It has to walk the iftable and try to match that up with its view of the interfaces. Can this routing daemon send AgentX-GET PDU's up to the master agent and expect it to dispatch them to the right sub-agent and dispatch the reply back to me all via AgentX, or do I have to use SNMP for this part? I ask because it seems like a shame that an application that only wants to be an AgentX sub-agent also has to be able to be an SNMP client. Thanks, Bill From fenner@parc.xerox.com Fri Jul 31 15:20:09 1998 Delivery-Date: Fri, 31 Jul 1998 15:20:09 -0400 Return-Path: fenner@parc.xerox.com Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id PAA28399 for ; Fri, 31 Jul 1998 15:20:09 -0400 (EDT) Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id PAA00078 for ; Fri, 31 Jul 1998 15:19:52 -0400 (EDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id OAA08630 for ; Fri, 31 Jul 1998 14:20:06 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma008420; Fri, 31 Jul 98 14:19:31 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id OAA11186 for ; Fri, 31 Jul 1998 14:18:54 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma009923; Fri, 31 Jul 98 14:18:03 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id OAA00175; Fri, 31 Jul 1998 14:18:20 -0500 (CDT) Received: from cashew.bmc.com (cashew.bmc.com [172.19.0.100]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id MAA13406 for ; Fri, 31 Jul 1998 12:13:11 -0700 (PDT) Received: (from uucp@localhost) by cashew.bmc.com (8.8.8/8.8.8) id OAA14055 for ; Fri, 31 Jul 1998 14:13:09 -0500 (CDT) Received: from omega.xerox.com(13.1.64.95) by cashew.bmc.com via smap (V2.0) id xma013944; Fri, 31 Jul 98 14:12:46 -0500 Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <40652(2)>; Fri, 31 Jul 1998 12:11:20 PDT Received: by crevenia.parc.xerox.com id <177515>; Fri, 31 Jul 1998 12:11:13 -0700 From: Bill Fenner To: agentx@peer.com Subject: Misleading wording in section 8.1.2: AgentX over TCP operation Cc: fenner@parc.xerox.com Message-Id: <98Jul31.121113pdt.177515@crevenia.parc.xerox.com> Date: Fri, 31 Jul 1998 12:11:00 PDT Section 8.1.2 says: All AgentX PDUs are presented individually to the TCP, to be sent as the data portion of a TCP PDU. Applications can't control TCP PDU's; e.g. if you do 3 small TCP writes in a row, most TCP's will coalesce the 2nd and 3rd write into a single TCP PDU. And, of course, large writes will be fragmented into multiple TCP PDU's. I'd suggest removing this sentence in the next version of the document, since how you present data to TCP has very little to do with how TCP puts the data into PDU's. Bill From schoenw@ibr.cs.tu-bs.de Fri Jul 31 16:27:27 1998 Delivery-Date: Fri, 31 Jul 1998 16:27:28 -0400 Return-Path: schoenw@ibr.cs.tu-bs.de Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id QAA29583 for ; Fri, 31 Jul 1998 16:27:27 -0400 (EDT) Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id QAA00550 for ; Fri, 31 Jul 1998 16:27:08 -0400 (EDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id PAA14905 for ; Fri, 31 Jul 1998 15:27:07 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma014390; Fri, 31 Jul 98 15:25:54 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id PAA15230 for ; Fri, 31 Jul 1998 15:25:18 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma014183; Fri, 31 Jul 98 15:24:26 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id PAA19354; Fri, 31 Jul 1998 15:24:32 -0500 (CDT) Received: from cashew.bmc.com (cashew.bmc.com [172.19.0.100]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id NAA13775 for ; Fri, 31 Jul 1998 13:12:35 -0700 (PDT) Received: (from uucp@localhost) by cashew.bmc.com (8.8.8/8.8.8) id PAA17695 for ; Fri, 31 Jul 1998 15:12:33 -0500 (CDT) Received: from mumm.ibr.cs.tu-bs.de(134.169.34.190) by cashew.bmc.com via smap (V2.0) id xma017637; Fri, 31 Jul 98 15:11:53 -0500 Received: from henkell.ibr.cs.tu-bs.de (schoenw@henkell [134.169.34.191]) by mumm.ibr.cs.tu-bs.de (8.9.1/8.9.0) with ESMTP id WAA17833; Fri, 31 Jul 1998 22:11:51 +0200 (MET DST) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id WAA01760; Fri, 31 Jul 1998 22:11:50 +0200 Date: Fri, 31 Jul 1998 22:11:50 +0200 Message-Id: <199807312011.WAA01760@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: agentx@peer.com Subject: Extensions for AgentX Version 1 Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII AgentX verion 1 does not allow a subagent to do the following: 1) check whether access is allowed to variables that exist in other subagents 2) read variables that exist in other subagents (with appropriate access control applied) 3) write variables that exist in other subagents (with appropriate access control applied) Some of the DISMAN MIBs that are currently on their way to proposed standard require to do the operations listed above. This means that it is impossible to implement and ship these DISMAN MIBs as separate products that you can plug into your native AgentX master agent. It might be possible to extend AgentX to provide this capability. The hardest part of the problem is how you maintain the required input for the access control function. Shipping this information to the subagent is probably not a good idea (it would make it pretty easy to mount guessing attacks from a subagent). However, it might be possible to find a solution where the master maintains a cache for security related information and passes only a handle to a subagent, probably only on a special request from the subagent while processing a read or write SNMP request. Anyway, I would like to know if there is interest in extending AgentX in this direction so that DISMAN MIBs can be implemented based on AgentX. (Bob, please consider this a request to discuss this during the AgentX meeting in Chicago. ;-) Juergen Juergen Schoenwaelder schoenw@ibr.cs.tu-bs.de http://www.cs.tu-bs.de/~schoenw Technical University Braunschweig, Dept. Operating Systems & Computer Networks Bueltenweg 74/75, 38106 Braunschweig, Germany. (Tel. +49 531 / 391 3289) From mithatch@cisco.com Fri Jul 31 16:33:47 1998 Delivery-Date: Fri, 31 Jul 1998 16:33:47 -0400 Return-Path: mithatch@cisco.com Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id QAA29743 for ; Fri, 31 Jul 1998 16:33:46 -0400 (EDT) Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id QAA00586 for ; Fri, 31 Jul 1998 16:33:27 -0400 (EDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id PAA16677 for ; Fri, 31 Jul 1998 15:33:42 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma016117; Fri, 31 Jul 98 15:32:14 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id PAA22117 for ; Fri, 31 Jul 1998 15:31:36 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma020699; Fri, 31 Jul 98 15:30:28 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id PAA20945; Fri, 31 Jul 1998 15:30:28 -0500 (CDT) Received: from almond.bmc.com (almond.bmc.com [172.17.0.100]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id NAA13847 for ; Fri, 31 Jul 1998 13:27:05 -0700 (PDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id PAA14881 for ; Fri, 31 Jul 1998 15:27:02 -0500 (CDT) Received: from brownale.cisco.com(171.69.95.89) by almond.bmc.com via smap (V2.0) id xma014359; Fri, 31 Jul 98 15:25:50 -0500 Received: from mithatch-ultra.cisco.com (mithatch-ultra.cisco.com [171.69.50.33]) by brownale.cisco.com (8.8.4-Cisco.1/8.6.5) with ESMTP id NAA08617; Fri, 31 Jul 1998 13:24:36 -0700 (PDT) Received: from cisco.com (localhost [127.0.0.1]) by mithatch-ultra.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/CISCO.WS.1.2) with ESMTP id NAA12501; Fri, 31 Jul 1998 13:24:35 -0700 (PDT) Sender: mithatch@cisco.com Message-ID: <35C22803.C5940BEE@cisco.com> Date: Fri, 31 Jul 1998 13:24:35 -0700 From: Mike Thatcher X-Mailer: Mozilla 4.03C-CISCOENG [en] (X11; U; SunOS 5.5.1 sun4u) MIME-Version: 1.0 To: Smitha Gudur CC: agentx@peer.com Subject: Re: open issues in agentX MIB References: <19980731173229.29029.qmail@hotmail.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit If there is a relationship between sessionID as defined in RFC2257and agentxSessionIndex then the relationship needs to be clarified and the description of agentxSessionIndex made consistent with the definition in the RFC. (See sections 6.1, 6.2.16, 7.1.1(3)) MikeT From rpresuhn@dorothy.bmc.com Fri Jul 31 17:41:51 1998 Delivery-Date: Fri, 31 Jul 1998 17:41:51 -0400 Return-Path: rpresuhn@dorothy.bmc.com Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id RAA01143 for ; Fri, 31 Jul 1998 17:41:50 -0400 (EDT) Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id RAA01147 for ; Fri, 31 Jul 1998 17:41:21 -0400 (EDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id QAA22259 for ; Fri, 31 Jul 1998 16:41:25 -0500 (CDT) Received: from dresden.bmc.com(198.64.253.250) by almond.bmc.com via smap (V2.0) id xma021531; Fri, 31 Jul 98 16:39:45 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id QAA19859 for ; Fri, 31 Jul 1998 16:39:08 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma018792; Fri, 31 Jul 98 16:38:23 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id QAA09606; Fri, 31 Jul 1998 16:38:36 -0500 (CDT) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id OAA14938 for agentx@peer.com; Fri, 31 Jul 1998 14:24:42 -0700 (PDT) Date: Fri, 31 Jul 1998 14:24:42 -0700 (PDT) From: Randy Presuhn Message-Id: <199807312124.OAA14938@dorothy.bmc.com> To: agentx@peer.com Subject: Re: Extensions for AgentX Version 1 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi - > Date: Fri, 31 Jul 1998 22:11:50 +0200 > From: Juergen Schoenwaelder > To: agentx@peer.com > Subject: Extensions for AgentX Version 1 ... > Anyway, I would like to know if there is interest in extending AgentX > in this direction so that DISMAN MIBs can be implemented based on > AgentX. (Bob, please consider this a request to discuss this during > the AgentX meeting in Chicago. ;-) ... Discussion of whatever the AgentX WG has to say on this topic is already on the proposed disman agenda. ----------------------------------------------------------------------- Randy Presuhn Email: rpresuhn@bmc.com http://www.bmc.com Voice: +1 408 616-3100 BMC Software, Inc. 965 Stewart Drive Fax: +1 408 616-3101 Sunnyvale, California 94086 USA ----------------------------------------------------------------------- In accordance with the BMC Communications Systems Use and Security Policy, I explicitly state that although my affiliation with BMC may be apparent, implied, or provided, my opinions are not necessarily those of BMC Software and that all external representations on behalf of BMC must first be cleared with a member of "the top management team." ----------------------------------------------------------------------- From sgudur@hotmail.com Fri Jul 31 17:50:49 1998 Delivery-Date: Fri, 31 Jul 1998 17:50:49 -0400 Return-Path: sgudur@hotmail.com Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id RAA01283 for ; Fri, 31 Jul 1998 17:50:48 -0400 (EDT) Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id RAA01173 for ; Fri, 31 Jul 1998 17:50:33 -0400 (EDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id QAA24052 for ; Fri, 31 Jul 1998 16:50:50 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma023713; Fri, 31 Jul 98 16:50:05 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id QAA00709 for ; Fri, 31 Jul 1998 16:49:29 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma029506; Fri, 31 Jul 98 16:48:45 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id QAA12462; Fri, 31 Jul 1998 16:49:10 -0500 (CDT) Received: from almond.bmc.com (almond.bmc.com [172.17.0.100]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id OAA15711 for ; Fri, 31 Jul 1998 14:45:37 -0700 (PDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id QAA23291 for ; Fri, 31 Jul 1998 16:45:35 -0500 (CDT) Received: from f185.hotmail.com(207.82.251.74) by almond.bmc.com via smap (V2.0) id xma023283; Fri, 31 Jul 98 16:45:29 -0500 Received: (qmail 29356 invoked by uid 0); 31 Jul 1998 21:45:24 -0000 Message-ID: <19980731214524.29355.qmail@hotmail.com> Received: from 152.67.249.57 by www.hotmail.com with HTTP; Fri, 31 Jul 1998 14:45:24 PDT X-Originating-IP: [152.67.249.57] From: "Smitha Gudur" To: mithatch@cisco.com Cc: agentx@peer.com Subject: Re: open issues in agentX MIB Content-Type: text/plain Date: Fri, 31 Jul 1998 14:45:24 PDT Hi, Mike, There is relationship between sessionID defined in RFC2257 and the agentxSessionIndex. Current description for agentxSessionIndex includes: "Index values assigned for a given registration are constant for the lifetime of this table." is inappropriate and needs to be removed. The other part of the description is consistent with the RFC. "A unique index for the subagent session. Note that if a subagent's session with the master agent is closed for any reason its index should not be re-used, therefore, the values of agentxSessionIndex may not be contiguous and will generally not be the same for the same subagent across multiple sessions." thanks for the inputs. regards smitha >From mithatch@cisco.com Fri Jul 31 13:25:54 1998 >Received: from mithatch-ultra.cisco.com (mithatch-ultra.cisco.com [171.69.50.33]) by brownale.cisco.com (8.8.4-Cisco.1/8.6.5) with ESMTP id NAA08617; Fri, 31 Jul 1998 13:24:36 -0700 (PDT) >Received: from cisco.com (localhost [127.0.0.1]) by mithatch-ultra.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/CISCO.WS.1.2) with ESMTP id NAA12501; Fri, 31 Jul 1998 13:24:35 -0700 (PDT) >Sender: mithatch@cisco.com >Message-ID: <35C22803.C5940BEE@cisco.com> >Date: Fri, 31 Jul 1998 13:24:35 -0700 >From: Mike Thatcher >X-Mailer: Mozilla 4.03C-CISCOENG [en] (X11; U; SunOS 5.5.1 sun4u) >MIME-Version: 1.0 >To: Smitha Gudur >CC: agentx@peer.com >Subject: Re: open issues in agentX MIB >References: <19980731173229.29029.qmail@hotmail.com> >Content-Type: text/plain; charset=us-ascii >Content-Transfer-Encoding: 7bit > >If there is a relationship between sessionID as defined in RFC2257and >agentxSessionIndex then the relationship needs to be clarified and the >description of agentxSessionIndex made consistent with the definition in >the RFC. (See sections 6.1, 6.2.16, 7.1.1(3)) > >MikeT > > ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com From martin@exmandato.se Fri Jul 31 18:05:05 1998 Delivery-Date: Fri, 31 Jul 1998 18:05:05 -0400 Return-Path: martin@exmandato.se Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id SAA01487 for ; Fri, 31 Jul 1998 18:05:04 -0400 (EDT) Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id SAA01257 for ; Fri, 31 Jul 1998 18:04:44 -0400 (EDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id RAA26363 for ; Fri, 31 Jul 1998 17:05:01 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma026066; Fri, 31 Jul 98 17:04:15 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id RAA13150 for ; Fri, 31 Jul 1998 17:03:30 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma010923; Fri, 31 Jul 98 17:01:47 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id RAA15629; Fri, 31 Jul 1998 17:01:57 -0500 (CDT) Received: from almond.bmc.com (almond.bmc.com [172.17.0.100]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id OAA16380 for ; Fri, 31 Jul 1998 14:57:17 -0700 (PDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id QAA25126 for ; Fri, 31 Jul 1998 16:57:14 -0500 (CDT) Received: from oden.exmandato.se(192.71.33.1) by almond.bmc.com via smap (V2.0) id xma025120; Fri, 31 Jul 98 16:56:53 -0500 Received: from localhost (martin@localhost) by oden.exmandato.se (8.8.8/8.8.5) with SMTP id XAA00477; Fri, 31 Jul 1998 23:56:59 +0200 (MET DST) Date: Fri, 31 Jul 1998 23:56:59 +0200 (CEST) From: Martin Jacobsson Reply-To: Martin Jacobsson To: Smitha Gudur cc: agentx@peer.com Subject: Re: open issues in agentX MIB In-Reply-To: <19980731173229.29029.qmail@hotmail.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Fri, 31 Jul 1998, Smitha Gudur wrote: > If there are any other open items that need to be addressed in the MIB, > I urge everyone on the mailing list to send them as early as possible. Section 2, goal 4 says: - Provide statistics about the protocol operation such as the number of packets to and from each subagent This information is not available through the mib as defined. One option is to add agentxSessionInPackets and agentxSessionOutPackets to the session table. And another is to add agentxConnInPackets, agentxConnOutPackets, agentxConnProtocolErrors and agentxConnParseErrors to the connection table. All as Counter32's. Then a port table would be nice, so that it is possible to see what ports the master agent accepts connections from and if it listens on any nondefault ports. A typical unix master agent will listen on both tcp port 705 and unix-domain socket "/var/agentx/master". /Martin Jacobsson --- .signature: No such file or directory From sgudur@hotmail.com Fri Jul 31 18:46:31 1998 Delivery-Date: Fri, 31 Jul 1998 18:46:32 -0400 Return-Path: sgudur@hotmail.com Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id SAA02130 for ; Fri, 31 Jul 1998 18:46:31 -0400 (EDT) Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id SAA01472 for ; Fri, 31 Jul 1998 18:46:09 -0400 (EDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id RAA29685 for ; Fri, 31 Jul 1998 17:46:14 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma028834; Fri, 31 Jul 98 17:44:28 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id RAA10171 for ; Fri, 31 Jul 1998 17:43:50 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma008835; Fri, 31 Jul 98 17:42:59 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id RAA26717; Fri, 31 Jul 1998 17:43:21 -0500 (CDT) Received: from almond.bmc.com (almond.bmc.com [172.17.0.100]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id PAA25398 for ; Fri, 31 Jul 1998 15:30:07 -0700 (PDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id RAA27889 for ; Fri, 31 Jul 1998 17:30:06 -0500 (CDT) Received: from f139.hotmail.com(207.82.251.18) by almond.bmc.com via smap (V2.0) id xma027878; Fri, 31 Jul 98 17:29:43 -0500 Received: (qmail 1049 invoked by uid 0); 31 Jul 1998 22:29:42 -0000 Message-ID: <19980731222942.1048.qmail@hotmail.com> Received: from 152.67.249.57 by www.hotmail.com with HTTP; Fri, 31 Jul 1998 15:29:41 PDT X-Originating-IP: [152.67.249.57] From: "Smitha Gudur" To: mithatch@cisco.com Cc: agentx@peer.com Subject: Re: open issues in agentX MIB Content-Type: text/plain Date: Fri, 31 Jul 1998 15:29:41 PDT >From mithatch@cisco.com Fri Jul 31 15:03:58 1998 >Received: from mithatch-ultra.cisco.com (mithatch-ultra.cisco.com [171.69.50.33]) by pleco.cisco.com (8.8.4-Cisco.1/8.6.5) with ESMTP id PAA29758; Fri, 31 Jul 1998 15:02:54 -0700 (PDT) >Received: from cisco.com (localhost [127.0.0.1]) by mithatch-ultra.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/CISCO.WS.1.2) with ESMTP id PAA12637; Fri, 31 Jul 1998 15:02:54 -0700 (PDT) >Sender: mithatch@cisco.com >Message-ID: <35C23F0D.44E2CE36@cisco.com> >Date: Fri, 31 Jul 1998 15:02:53 -0700 >From: Mike Thatcher >X-Mailer: Mozilla 4.03C-CISCOENG [en] (X11; U; SunOS 5.5.1 sun4u) >MIME-Version: 1.0 >To: Smitha Gudur >Subject: Re: open issues in agentX MIB >References: <19980731214524.29355.qmail@hotmail.com> >Content-Type: text/plain; charset=us-ascii >Content-Transfer-Encoding: 7bit > >Smitha Gudur wrote: > >> Hi, Mike, >> >> There is relationship between sessionID defined in RFC2257 and >> the agentxSessionIndex. >> >> Current description for agentxSessionIndex includes: >> >> "Index values assigned for a given registration are constant for the >> lifetime of this table." >> >> is inappropriate and needs to be removed. >> >> The other part of the description is consistent with the RFC. >> >> "A unique index for the subagent session. Note that if a >> subagent's session with the master agent is closed for >> any reason its index should not be re-used, therefore, >> > >However the RFC does not restrict the reuse of sessionID. I agree, it does not restrict the usage but says that it should be globally unique over all its sessions if master agent supports multiple transports. The description has to be changed to make it unique across all the sessions that the master agent supports instead of saying it cannot be reused. smitha > >MikeT > > ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com From bnatale@acecomm.com Fri Jul 31 18:47:15 1998 Delivery-Date: Fri, 31 Jul 1998 18:47:16 -0400 Return-Path: bnatale@acecomm.com Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id SAA02139 for ; Fri, 31 Jul 1998 18:47:15 -0400 (EDT) Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id SAA01475 for ; Fri, 31 Jul 1998 18:46:53 -0400 (EDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id RAA00057 for ; Fri, 31 Jul 1998 17:47:07 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma029437; Fri, 31 Jul 98 17:45:45 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id RAA11639 for ; Fri, 31 Jul 1998 17:45:06 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma008922; Fri, 31 Jul 98 17:43:03 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id RAA26713; Fri, 31 Jul 1998 17:43:20 -0500 (CDT) Received: from almond.bmc.com (almond.bmc.com [172.17.0.100]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id PAA25406 for ; Fri, 31 Jul 1998 15:30:08 -0700 (PDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id RAA27891 for ; Fri, 31 Jul 1998 17:30:06 -0500 (CDT) Received: from relay2.smtp.psi.net(38.8.188.2) by almond.bmc.com via smap (V2.0) id xma027887; Fri, 31 Jul 98 17:29:56 -0500 Received: from [192.152.208.5] (helo=acecomm.com) by relay2.smtp.psi.net with smtp (Exim 1.90 #1) id 0z2NgO-0005N2-00; Fri, 31 Jul 1998 18:29:53 -0400 Received: from bnatale by acecomm.com (5.65/3.2.083191-ACE*COMM) id AA17422; Fri, 31 Jul 1998 18:32:10 -0400 Message-Id: <9807312232.AA17422@acecomm.com> X-Sender: natale@nips.acec.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1 Date: Fri, 31 Jul 1998 18:32:19 -0400 To: "Smitha Gudur" From: Bob Natale Subject: Re: open issues in agentX MIB Cc: mithatch@cisco.com, agentx@peer.com In-Reply-To: <19980731214524.29355.qmail@hotmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" >At 7/31/98 02:45 PM, Smitha Gudur wrote: Hi Smitha, >There is relationship between sessionID defined in RFC2257 and >the agentxSessionIndex. Logically, that's true. The value used for agentxSessionIndex to identify the session should be the same as that used for the SessionID as given by the master agent to the subagent. The problem Mike alludes to here derives from the "should not be re-used" semantics used for agentxSessionIndex in the MIB but which are missing from the RFC references to SessionID. I would argue that the RFC text should be tightened in this respect, to stipulate non-reuse; but it is clear that a reasonable argument can be made for not stipulating it and leaving it up to the implementation. In my view, however, management apps will be able to use the MIB better to monitor the overall AgentX system if the non-reuse semantics of agentxSessionIndex are carried over to SessionID. This value, via agentxSessionIndex, is critical to all three of the tables currently defined in the MIB [btw, we should all be reading from the -02.txt version of the MIB document, dated April 14, 1998, at this point]: agentxConnectionTable agentxSessionTable agentxRegistrationTable In thinking through the relationships, it seems that we need to add agentxConnIndex to the AgentxSessionEntry and agentxSessionIndex to the AgentxRegistrationEntry. In this way, each registration entry can point to the session in which it lives and each session can point to the connection in which it lives. [Note to Smitha and Lauren here in particular:] The rationale and the consequent OBJECT-TYPE macros should be obvious (I think), but if not let me know. >Current description for agentxSessionIndex includes: > >"Index values assigned for a given registration are constant >for the lifetime of this table." > >is inappropriate and needs to be removed. Right. >The other part of the description is consistent with the RFC. That's the debatable part. >thanks for the inputs. Likewise. Cordially, BobN ------------ ISO 9001 Registered Quality Supplier ----------- Bob Natale | ACE*COMM | 301-721-3000 [v] Dir, Net Mgmt Prod | 704 Quince Orchard Rd | 301-721-3001 [f] bnatale@acecomm.com| Gaithersburg MD 20878 | www.acecomm.com ------------- Free downloads at www.winsnmp.com ------------- From bnatale@acecomm.com Fri Jul 31 19:07:10 1998 Delivery-Date: Fri, 31 Jul 1998 19:07:10 -0400 Return-Path: bnatale@acecomm.com Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id TAA02325 for ; Fri, 31 Jul 1998 19:07:09 -0400 (EDT) Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id TAA01547 for ; Fri, 31 Jul 1998 19:06:52 -0400 (EDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id SAA02632 for ; Fri, 31 Jul 1998 18:06:55 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma002095; Fri, 31 Jul 98 18:05:39 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id SAA20798 for ; Fri, 31 Jul 1998 18:05:03 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma020093; Fri, 31 Jul 98 18:04:26 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id SAA01875; Fri, 31 Jul 1998 18:04:51 -0500 (CDT) Received: from cashew.bmc.com (cashew.bmc.com [172.19.0.100]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id PAA10570 for ; Fri, 31 Jul 1998 15:56:45 -0700 (PDT) Received: (from uucp@localhost) by cashew.bmc.com (8.8.8/8.8.8) id RAA26038 for ; Fri, 31 Jul 1998 17:56:43 -0500 (CDT) Received: from relay2.smtp.psi.net(38.8.188.2) by cashew.bmc.com via smap (V2.0) id xma026033; Fri, 31 Jul 98 17:56:17 -0500 Received: from [192.152.208.5] (helo=acecomm.com) by relay2.smtp.psi.net with smtp (Exim 1.90 #1) id 0z2O5t-0000Op-00; Fri, 31 Jul 1998 18:56:14 -0400 Received: from bnatale by acecomm.com (5.65/3.2.083191-ACE*COMM) id AA17629; Fri, 31 Jul 1998 18:58:27 -0400 Message-Id: <9807312258.AA17629@acecomm.com> X-Sender: natale@nips.acec.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1 Date: Fri, 31 Jul 1998 18:58:35 -0400 To: Martin Jacobsson From: Bob Natale Subject: Re: open issues in agentX MIB Cc: Smitha Gudur , agentx@peer.com In-Reply-To: References: <19980731173229.29029.qmail@hotmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" >At 7/31/98 11:56 PM, Martin Jacobsson wrote: Hi Martin, >Section 2, goal 4 says: > >- Provide statistics about the protocol operation such >as the number of packets to and from each subagent > >This information is not available through the mib as defined. >One option is to add agentxSessionInPackets and >agentxSessionOutPackets to the session table. And another is >to add agentxConnInPackets, agentxConnOutPackets, >agentxConnProtocolErrors and agentxConnParseErrors >to the connection table. All as Counter32's. First, let me note that there is considerable sentiment to keep this MIB relatively minimal. Second, you are right, if state such purposes (and the one you quote seems like a sound one to me). The approach that I would like to propose for this purpose is to add an agentxResponseTable. This would be indexed by agentxSessionID and consist of a set of objects (with syntax of GAUGE32, I suggest), one for each of the possible AgentX-Response-PDU res.error codes (including no_error). Such a table would handle overall (by simple summing), connection-specific (by mapping back to agentxConnectionTable via the agentxConnIndex in the corresponding agentxSessionTable row, and session-specific traffic and error counts for all active sessions. >Then a port table would be nice, so that it is possible to see >what ports the master agent accepts connections from I think this can be had now, via the agentxConnTransportDomain and agentxConnTransportAddress objects in the agentxConnectionTable. No...? >and if it listens on any nondefault ports. I'll pass on that one (I don't really see the need for it). >A typical unix master agent will listen on both tcp port >705 and unix-domain socket "/var/agentx/master". True...and the two objects mentioned above would, I think, tend to reveal that, given at least one active connection from each domain. Cordially, BobN ------------ ISO 9001 Registered Quality Supplier ----------- Bob Natale | ACE*COMM | 301-721-3000 [v] Dir, Net Mgmt Prod | 704 Quince Orchard Rd | 301-721-3001 [f] bnatale@acecomm.com| Gaithersburg MD 20878 | www.acecomm.com ------------- Free downloads at www.winsnmp.com ------------- From rpresuhn@dorothy.bmc.com Fri Jul 31 19:58:31 1998 Delivery-Date: Fri, 31 Jul 1998 19:58:32 -0400 Return-Path: rpresuhn@dorothy.bmc.com Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id TAA02678 for ; Fri, 31 Jul 1998 19:58:31 -0400 (EDT) Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id TAA01720 for ; Fri, 31 Jul 1998 19:58:14 -0400 (EDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id SAA05749 for ; Fri, 31 Jul 1998 18:58:31 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma005145; Fri, 31 Jul 98 18:57:08 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id SAA06572 for ; Fri, 31 Jul 1998 18:56:32 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma005796; Fri, 31 Jul 98 18:55:55 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id SAA11662; Fri, 31 Jul 1998 18:56:20 -0500 (CDT) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id QAA24395 for agentx@peer.com; Fri, 31 Jul 1998 16:43:08 -0700 (PDT) Date: Fri, 31 Jul 1998 16:43:08 -0700 (PDT) From: Randy Presuhn Message-Id: <199807312343.QAA24395@dorothy.bmc.com> To: agentx@peer.com Subject: Re: open issues in agentX MIB Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi - > Date: Fri, 31 Jul 1998 18:58:35 -0400 > To: Martin Jacobsson > From: Bob Natale > Subject: Re: open issues in agentX MIB > Cc: Smitha Gudur , agentx@peer.com > References: <19980731173229.29029.qmail@hotmail.com> > > >At 7/31/98 11:56 PM, Martin Jacobsson wrote: > > Hi Martin, > > >Section 2, goal 4 says: > > > >- Provide statistics about the protocol operation such > >as the number of packets to and from each subagent ... > First, let me note that there is considerable sentiment to > keep this MIB relatively minimal. ... A counter-proposal to consider: delete goal 4 in section 2. ----------------------------------------------------------------------- Randy Presuhn Email: rpresuhn@bmc.com http://www.bmc.com Voice: +1 408 616-3100 BMC Software, Inc. 965 Stewart Drive Fax: +1 408 616-3101 Sunnyvale, California 94086 USA ----------------------------------------------------------------------- In accordance with the BMC Communications Systems Use and Security Policy, I explicitly state that although my affiliation with BMC may be apparent, implied, or provided, my opinions are not necessarily those of BMC Software and that all external representations on behalf of BMC must first be cleared with a member of "the top management team." ----------------------------------------------------------------------- From ashishkh@wipinfo.soft.net Sun Aug 2 05:19:05 1998 Delivery-Date: Sun, 02 Aug 1998 05:19:06 -0400 Return-Path: ashishkh@wipinfo.soft.net Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id FAA01169 for ; Sun, 2 Aug 1998 05:19:03 -0400 (EDT) Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id FAA00502 for ; Sun, 2 Aug 1998 05:18:46 -0400 (EDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id EAA02813 for ; Sun, 2 Aug 1998 04:18:59 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma002353; Sun, 2 Aug 98 04:17:54 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id EAA17869 for ; Sun, 2 Aug 1998 04:17:11 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma017361; Sun, 2 Aug 98 04:16:44 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id EAA07409; Sun, 2 Aug 1998 04:17:10 -0500 (CDT) Received: from cashew.bmc.com (cashew.bmc.com [172.19.0.100]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id BAA04388 for ; Sun, 2 Aug 1998 01:02:27 -0700 (PDT) Received: (from uucp@localhost) by cashew.bmc.com (8.8.8/8.8.8) id DAA08809 for ; Sun, 2 Aug 1998 03:02:24 -0500 (CDT) Received: from agni.wipinfo.soft.net(164.164.6.20) by cashew.bmc.com via smap (V2.0) id xma008791; Sun, 2 Aug 98 03:02:08 -0500 Received: from scan.wipinfo.soft.net by wipinfo.soft.net (SMI-8.6/SMI-SVR4) id NAA18037; Sun, 2 Aug 1998 13:27:25 -0500 Received: from 192.9.100.151 by scan.wipinfo.soft.net (InterScan E-Mail VirusWall NT) Received: from opel ([192.9.52.22]) by divya.wipinfo.soft.net (8.8.5/8.8.5) with SMTP id NAA26354; Sun, 2 Aug 1998 13:34:01 +0530 From: "Ashish Hanwadikar" To: "Bob Natale" Cc: "Agentx" Subject: RE: open issues in agentX MIB Date: Sun, 2 Aug 1998 13:32:36 +0530 Message-ID: <008401bdbdeb$ea7e6c80$163409c0@opel.wipinfo.soft.net> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal In-Reply-To: <9807312258.AA17629@acecomm.com> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0085_01BDBE1A.0436A880" This is a multi-part message in MIME format. ------=_NextPart_000_0085_01BDBE1A.0436A880 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Ashish K Hanwadikar Senior Software Engineer, Wipro Infotech, Technology Solutions, Bangalore INDIA -----Original Message----- From: Bob Natale [mailto:bnatale@acecomm.com] Sent: Saturday, August 01, 1998 4:29 AM To: Martin Jacobsson Cc: Smitha Gudur; agentx@peer.com Subject: Re: open issues in agentX MIB >At 7/31/98 11:56 PM, Martin Jacobsson wrote: Hi Martin, >Section 2, goal 4 says: > >- Provide statistics about the protocol operation such >as the number of packets to and from each subagent > >This information is not available through the mib as defined. >One option is to add agentxSessionInPackets and >agentxSessionOutPackets to the session table. And another is >to add agentxConnInPackets, agentxConnOutPackets, >agentxConnProtocolErrors and agentxConnParseErrors >to the connection table. All as Counter32's. First, let me note that there is considerable sentiment to keep this MIB relatively minimal. Second, you are right, if state such purposes (and the one you quote seems like a sound one to me). The approach that I would like to propose for this purpose is to add an agentxResponseTable. This would be indexed by agentxSessionID and consist of a set of objects (with syntax of GAUGE32, I suggest), one for each of the possible AgentX-Response-PDU res.error codes (including no_error). Such a table would handle overall (by simple summing), connection-specific (by mapping back to agentxConnectionTable via the agentxConnIndex in the corresponding agentxSessionTable row, and session-specific traffic and error counts for all active sessions. >Then a port table would be nice, so that it is possible to see >what ports the master agent accepts connections from I think this can be had now, via the agentxConnTransportDomain and agentxConnTransportAddress objects in the agentxConnectionTable. No...? >and if it listens on any nondefault ports. I'll pass on that one (I don't really see the need for it). >A typical unix master agent will listen on both tcp port >705 and unix-domain socket "/var/agentx/master". True...and the two objects mentioned above would, I think, tend to reveal that, given at least one active connection from each domain. given at least one active connection .. That is the hitch. Suppose, the sub agent wants to know which transport should he use to communicate with the Master Agent? If no connections are active, then it is very difficult to known on which transport domains the Master Agent is listening. I think it will be generally be useful from the Sub Agent and Sub Agent API developers point of view to add an agentxListenTable to the AgentX MIB. I guess such a table was there in the DPI from which AgentX derives its inspiration. Thanks Cordially, BobN ------------ ISO 9001 Registered Quality Supplier ----------- Bob Natale | ACE*COMM | 301-721-3000 [v] Dir, Net Mgmt Prod | 704 Quince Orchard Rd | 301-721-3001 [f] bnatale@acecomm.com| Gaithersburg MD 20878 | www.acecomm.com ------------- Free downloads at www.winsnmp.com ------------- ------=_NextPart_000_0085_01BDBE1A.0436A880 Content-Type: text/x-vcard; name="Ashish K Hanwadikar.vcf" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="Ashish K Hanwadikar.vcf" BEGIN:VCARD VERSION:2.1 N:Hanwadikar;Ashish;K;; FN:Ashish K Hanwadikar ORG:Wipro Infotech, Technology Solutions;Technology Solutions TITLE:Senior Software Engineer TEL;WORK;VOICE:+91-80-2241730 Ext. 3315 TEL;HOME;VOICE:+91-80-2241730 Ext. 3315 ADR;WORK:;Mission Road LABEL;WORK:Mission Road ADR;HOME;ENCODING=3DQUOTED-PRINTABLE:;;Wipro Limited=3D0D=3D0A30 Mission = Road,=3D0D=3D0A1st Main,=3D0D=3D0AS.R. Nagar;Bangalo=3D re;Karnataka;560 027;INDIA LABEL;HOME;ENCODING=3DQUOTED-PRINTABLE:Wipro Limited=3D0D=3D0A30 Mission = Road,=3D0D=3D0A1st Main,=3D0D=3D0AS.R. Nagar=3D0D=3D0ABang=3D alore, Karnataka 560 027=3D0D=3D0AINDIA URL:http://www.geocities.com/SiliconValley/Bay/5393/ URL:http://www.geocities.com/SiliconValley/Bay/5393 EMAIL;PREF;INTERNET:ashishkh@wipinfo.soft.net REV:19980630T133122Z END:VCARD ------=_NextPart_000_0085_01BDBE1A.0436A880-- From daniele@zk3.dec.com Mon Aug 3 11:57:40 1998 Delivery-Date: Mon, 03 Aug 1998 11:57:41 -0400 Return-Path: daniele@zk3.dec.com Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id LAA21512 for ; Mon, 3 Aug 1998 11:57:36 -0400 (EDT) Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id LAA04306 for ; Mon, 3 Aug 1998 11:57:13 -0400 (EDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id KAA06763 for ; Mon, 3 Aug 1998 10:56:45 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma006383; Mon, 3 Aug 98 10:55:35 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id KAA29902 for ; Mon, 3 Aug 1998 10:54:57 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma026997; Mon, 3 Aug 98 10:52:23 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id KAA13127; Mon, 3 Aug 1998 10:50:21 -0500 (CDT) Received: from cashew.bmc.com (cashew.bmc.com [172.19.0.100]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id HAA08220 for ; Mon, 3 Aug 1998 07:22:57 -0700 (PDT) Received: (from uucp@localhost) by cashew.bmc.com (8.8.8/8.8.8) id JAA11615 for ; Mon, 3 Aug 1998 09:22:56 -0500 (CDT) Received: from mail11.digital.com(192.208.46.10) by cashew.bmc.com via smap (V2.0) id xma011588; Mon, 3 Aug 98 09:22:47 -0500 Received: from flume.zk3.dec.com (flambe.zk3.dec.com [16.140.96.19]) by mail11.digital.com (8.8.8/8.8.8/WV1.0g) with SMTP id KAA27570; Mon, 3 Aug 1998 10:22:38 -0400 (EDT) Received: from bernie.zk3.dec.com by flume.zk3.dec.com (5.65v4.0/1.1.8.2/16Jan95-0946AM) id AA04399; Mon, 3 Aug 1998 10:22:38 -0400 Received: from localhost by bernie.zk3.dec.com; (5.65/1.1.8.2/22Aug96-1117AM) id AA21193; Mon, 3 Aug 1998 10:22:51 -0400 Message-Id: <9808031422.AA21193@bernie.zk3.dec.com> To: Randy Presuhn Cc: agentx@peer.com Subject: Re: Extensions for AgentX Version 1 In-Reply-To: Your message of "Fri, 31 Jul 98 14:24:42 PDT." <199807312124.OAA14938@dorothy.bmc.com> Date: Mon, 03 Aug 98 10:22:50 -0400 From: Mike Daniele X-Mts: smtp Hi, >> Date: Fri, 31 Jul 1998 22:11:50 +0200 >> From: Juergen Schoenwaelder >> To: agentx@peer.com >> Subject: Extensions for AgentX Version 1 >... >> Anyway, I would like to know if there is interest in extending AgentX >> in this direction so that DISMAN MIBs can be implemented based on >> AgentX. (Bob, please consider this a request to discuss this during >> the AgentX meeting in Chicago. ;-) >Discussion of whatever the AgentX WG has to say on this topic is >already on the proposed disman agenda. This topic, which is really AgentX V2, is not (to my knowledge) on the AgentX WG's agenda. Personally, I'd like to see us finish version 1 before starting to work on version 2. Mike From sgudur@hotmail.com Mon Aug 3 13:21:11 1998 Delivery-Date: Mon, 03 Aug 1998 13:21:11 -0400 Return-Path: sgudur@hotmail.com Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id NAA22166 for ; Mon, 3 Aug 1998 13:21:10 -0400 (EDT) Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id NAA04679 for ; Mon, 3 Aug 1998 13:20:29 -0400 (EDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id MAA13252 for ; Mon, 3 Aug 1998 12:20:42 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma013056; Mon, 3 Aug 98 12:19:49 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id MAA10373 for ; Mon, 3 Aug 1998 12:19:11 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma005793; Mon, 3 Aug 98 12:14:48 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id MAA05754; Mon, 3 Aug 1998 12:13:20 -0500 (CDT) Received: from cashew.bmc.com (cashew.bmc.com [172.19.0.100]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id JAA09048 for ; Mon, 3 Aug 1998 09:59:07 -0700 (PDT) Received: (from uucp@localhost) by cashew.bmc.com (8.8.8/8.8.8) id LAA21108 for ; Mon, 3 Aug 1998 11:58:54 -0500 (CDT) Received: from f57.hotmail.com(207.82.251.69) by cashew.bmc.com via smap (V2.0) id xma021103; Mon, 3 Aug 98 11:58:29 -0500 Received: (qmail 14581 invoked by uid 0); 3 Aug 1998 16:58:27 -0000 Message-ID: <19980803165827.14580.qmail@hotmail.com> Received: from 152.67.249.57 by www.hotmail.com with HTTP; Mon, 03 Aug 1998 09:58:26 PDT X-Originating-IP: [152.67.249.57] From: "Smitha Gudur" To: bnatale@acecomm.com Cc: agentx@peer.com Subject: Re: open issues in agentX MIB Content-Type: text/plain Date: Mon, 03 Aug 1998 09:58:26 PDT >From bnatale@acecomm.com Fri Jul 31 15:29:56 1998 >Received: from [192.152.208.5] (helo=acecomm.com) > by relay2.smtp.psi.net with smtp (Exim 1.90 #1) > id 0z2NgO-0005N2-00; Fri, 31 Jul 1998 18:29:53 -0400 >Received: from bnatale by acecomm.com (5.65/3.2.083191-ACE*COMM) > id AA17422; Fri, 31 Jul 1998 18:32:10 -0400 >Message-Id: <9807312232.AA17422@acecomm.com> >X-Sender: natale@nips.acec.com >X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1 >Date: Fri, 31 Jul 1998 18:32:19 -0400 >To: "Smitha Gudur" >From: Bob Natale >Subject: Re: open issues in agentX MIB >Cc: mithatch@cisco.com, agentx@peer.com >In-Reply-To: <19980731214524.29355.qmail@hotmail.com> >Mime-Version: 1.0 >Content-Type: text/plain; charset="us-ascii" > >>At 7/31/98 02:45 PM, Smitha Gudur wrote: > >Hi Smitha, > >>There is relationship between sessionID defined in RFC2257 and >>the agentxSessionIndex. > >Logically, that's true. The value used for agentxSessionIndex >to identify the session should be the same as that used for >the SessionID as given by the master agent to the subagent. >The problem Mike alludes to here derives from the "should not >be re-used" semantics used for agentxSessionIndex in the MIB >but which are missing from the RFC references to SessionID. > >I would argue that the RFC text should be tightened in this >respect, to stipulate non-reuse; but it is clear that a >reasonable argument can be made for not stipulating it and >leaving it up to the implementation. > >In my view, however, management apps will be able to use >the MIB better to monitor the overall AgentX system if >the non-reuse semantics of agentxSessionIndex are carried >over to SessionID. This value, via agentxSessionIndex, >is critical to all three of the tables currently defined >in the MIB [btw, we should all be reading from the -02.txt >version of the MIB document, dated April 14, 1998, at this >point]: > > agentxConnectionTable > agentxSessionTable > agentxRegistrationTable > >In thinking through the relationships, it seems that we >need to add agentxConnIndex to the AgentxSessionEntry and >agentxSessionIndex to the AgentxRegistrationEntry. In this >way, each registration entry can point to the session in >which it lives and each session can point to the connection >in which it lives. > >[Note to Smitha and Lauren here in particular:] >The rationale and the consequent OBJECT-TYPE macros >should be obvious (I think), but if not let me know. Currently, the agentxConnIndex is one of the indices for agentxSessionEntry, and agentxSessionIndex is also one of the indices for agentxRegistrationEntry. Do we still need each of these object-type for the respective entries? smitha. > >>Current description for agentxSessionIndex includes: >> >>"Index values assigned for a given registration are constant >>for the lifetime of this table." >> >>is inappropriate and needs to be removed. > >Right. > >>The other part of the description is consistent with the RFC. > >That's the debatable part. > >>thanks for the inputs. > >Likewise. > >Cordially, > >BobN >------------ ISO 9001 Registered Quality Supplier ----------- >Bob Natale | ACE*COMM | 301-721-3000 [v] >Dir, Net Mgmt Prod | 704 Quince Orchard Rd | 301-721-3001 [f] >bnatale@acecomm.com| Gaithersburg MD 20878 | www.acecomm.com >------------- Free downloads at www.winsnmp.com ------------- > > ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com From sgudur@hotmail.com Mon Aug 3 13:21:16 1998 Delivery-Date: Mon, 03 Aug 1998 13:21:17 -0400 Return-Path: sgudur@hotmail.com Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id NAA22177 for ; Mon, 3 Aug 1998 13:21:16 -0400 (EDT) Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id NAA04677 for ; Mon, 3 Aug 1998 13:19:49 -0400 (EDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id MAA13137 for ; Mon, 3 Aug 1998 12:20:03 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma012897; Mon, 3 Aug 98 12:19:14 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id MAA09682 for ; Mon, 3 Aug 1998 12:18:34 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma005592; Mon, 3 Aug 98 12:14:33 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id MAA05752; Mon, 3 Aug 1998 12:13:20 -0500 (CDT) Received: from almond.bmc.com (almond.bmc.com [172.17.0.100]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id KAA09072 for ; Mon, 3 Aug 1998 10:04:35 -0700 (PDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id MAA11147 for ; Mon, 3 Aug 1998 12:04:27 -0500 (CDT) Received: from f133.hotmail.com(207.82.251.12) by almond.bmc.com via smap (V2.0) id xma011134; Mon, 3 Aug 98 12:04:13 -0500 Received: (qmail 10568 invoked by uid 0); 3 Aug 1998 17:04:08 -0000 Message-ID: <19980803170408.10567.qmail@hotmail.com> Received: from 152.67.249.57 by www.hotmail.com with HTTP; Mon, 03 Aug 1998 10:04:07 PDT X-Originating-IP: [152.67.249.57] From: "Smitha Gudur" To: martin@exmandato.se Cc: agentx@peer.com Subject: Re: open issues in agentX MIB Content-Type: text/plain Date: Mon, 03 Aug 1998 10:04:07 PDT >From martin@exmandato.se Fri Jul 31 15:04:49 1998 >Received: (from uucp@localhost) > by almond.bmc.com (8.8.8/8.8.8) id RAA26253 > for ; Fri, 31 Jul 1998 17:04:42 -0500 (CDT) >Received: from firewall.bmc.com(192.245.162.250) > by almond.bmc.com via smap (V2.0) > id xma025969; Fri, 31 Jul 98 17:04:03 -0500 >Received: (from uucp@localhost) > by dresden.bmc.com (8.8.5/8.8.6) id RAA12852 > for ; Fri, 31 Jul 1998 17:03:19 -0500 (CDT) >Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) > id xma011550; Fri, 31 Jul 98 17:02:13 -0500 >Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) > by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id RAA15748; > Fri, 31 Jul 1998 17:02:20 -0500 (CDT) >Received: from almond.bmc.com (almond.bmc.com [172.17.0.100]) > by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id OAA16380 > for ; Fri, 31 Jul 1998 14:57:17 -0700 (PDT) >Received: (from uucp@localhost) > by almond.bmc.com (8.8.8/8.8.8) id QAA25126 > for ; Fri, 31 Jul 1998 16:57:14 -0500 (CDT) >Received: from oden.exmandato.se(192.71.33.1) > by almond.bmc.com via smap (V2.0) > id xma025120; Fri, 31 Jul 98 16:56:53 -0500 >Received: from localhost (martin@localhost) > by oden.exmandato.se (8.8.8/8.8.5) with SMTP id XAA00477; > Fri, 31 Jul 1998 23:56:59 +0200 (MET DST) >Date: Fri, 31 Jul 1998 23:56:59 +0200 (CEST) >From: Martin Jacobsson >Reply-To: Martin Jacobsson >To: Smitha Gudur >cc: agentx@peer.com >Subject: Re: open issues in agentX MIB >In-Reply-To: <19980731173229.29029.qmail@hotmail.com> >Message-ID: >MIME-Version: 1.0 >Content-Type: TEXT/PLAIN; charset=US-ASCII > > >On Fri, 31 Jul 1998, Smitha Gudur wrote: > >> If there are any other open items that need to be addressed in the MIB, >> I urge everyone on the mailing list to send them as early as possible. > >Section 2, goal 4 says: > >- Provide statistics about the protocol operation such as the number of > packets to and from each subagent > >This information is not available through the mib as defined. >One option is to add agentxSessionInPackets and agentxSessionOutPackets to >the session table. And another is to add agentxConnInPackets, >agentxConnOutPackets, agentxConnProtocolErrors and agentxConnParseErrors >to the connection table. All as Counter32's. As Bob said, the objective is to keep the MIB minimal. The statistics were defined in detail in the early version of the MIB and were subsequently removed as it was felt there were not adding any usefulness except in debugging. > >Then a port table would be nice, so that it is possible to see what ports >the master agent accepts connections from and if it listens on any >nondefault ports. A typical unix master agent will listen on both tcp port >705 and unix-domain socket "/var/agentx/master". agentxConnTransportAddress is the transport address and the port. smitha > >/Martin Jacobsson > >--- >.signature: No such file or directory > > > > > ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com From sgudur@hotmail.com Mon Aug 3 13:40:55 1998 Delivery-Date: Mon, 03 Aug 1998 13:41:01 -0400 Return-Path: sgudur@hotmail.com Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id NAA22376 for ; Mon, 3 Aug 1998 13:40:50 -0400 (EDT) Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id NAA04812 for ; Mon, 3 Aug 1998 13:40:29 -0400 (EDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id MAA16321 for ; Mon, 3 Aug 1998 12:40:17 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma016193; Mon, 3 Aug 98 12:39:33 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id MAA27779 for ; Mon, 3 Aug 1998 12:38:54 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma026712; Mon, 3 Aug 98 12:37:42 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id MAA10977; Mon, 3 Aug 1998 12:34:37 -0500 (CDT) Received: from cashew.bmc.com (cashew.bmc.com [172.19.0.100]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id KAA09184 for ; Mon, 3 Aug 1998 10:29:19 -0700 (PDT) Received: (from uucp@localhost) by cashew.bmc.com (8.8.8/8.8.8) id MAA22690 for ; Mon, 3 Aug 1998 12:29:17 -0500 (CDT) Received: from f210.hotmail.com(207.82.251.101) by cashew.bmc.com via smap (V2.0) id xma022684; Mon, 3 Aug 98 12:28:56 -0500 Received: (qmail 25089 invoked by uid 0); 3 Aug 1998 17:28:50 -0000 Message-ID: <19980803172850.25088.qmail@hotmail.com> Received: from 152.67.249.57 by www.hotmail.com with HTTP; Mon, 03 Aug 1998 10:28:49 PDT X-Originating-IP: [152.67.249.57] From: "Smitha Gudur" To: ashishkh@wipinfo.soft.net Cc: agentx@peer.com Subject: RE: open issues in agentX MIB Content-Type: text/plain Date: Mon, 03 Aug 1998 10:28:49 PDT >From ashishkh@wipinfo.soft.net Sun Aug 2 02:19:22 1998 >Received: (from uucp@localhost) > by almond.bmc.com (8.8.8/8.8.8) id EAA02950 > for ; Sun, 2 Aug 1998 04:19:21 -0500 (CDT) >Received: from firewall.bmc.com(192.245.162.250) > by almond.bmc.com via smap (V2.0) > id xma002666; Sun, 2 Aug 98 04:18:40 -0500 >Received: (from uucp@localhost) > by dresden.bmc.com (8.8.5/8.8.6) id EAA18517 > for ; Sun, 2 Aug 1998 04:18:02 -0500 (CDT) >Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) > id xma018019; Sun, 2 Aug 98 04:17:22 -0500 >Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) > by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id EAA07541; > Sun, 2 Aug 1998 04:17:40 -0500 (CDT) >Received: from cashew.bmc.com (cashew.bmc.com [172.19.0.100]) > by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id BAA04388 > for ; Sun, 2 Aug 1998 01:02:27 -0700 (PDT) >Received: (from uucp@localhost) > by cashew.bmc.com (8.8.8/8.8.8) id DAA08809 > for ; Sun, 2 Aug 1998 03:02:24 -0500 (CDT) >Received: from agni.wipinfo.soft.net(164.164.6.20) > by cashew.bmc.com via smap (V2.0) > id xma008791; Sun, 2 Aug 98 03:02:08 -0500 >Received: from scan.wipinfo.soft.net by wipinfo.soft.net (SMI-8.6/SMI-SVR4) > id NAA18037; Sun, 2 Aug 1998 13:27:25 -0500 >Received: from 192.9.100.151 by scan.wipinfo.soft.net (InterScan E-Mail VirusWall NT) >Received: from opel ([192.9.52.22]) > by divya.wipinfo.soft.net (8.8.5/8.8.5) with SMTP id NAA26354; > Sun, 2 Aug 1998 13:34:01 +0530 >From: "Ashish Hanwadikar" >To: "Bob Natale" >Cc: "Agentx" >Subject: RE: open issues in agentX MIB >Date: Sun, 2 Aug 1998 13:32:36 +0530 >Message-ID: <008401bdbdeb$ea7e6c80$163409c0@opel.wipinfo.soft.net> >MIME-Version: 1.0 >X-Priority: 3 (Normal) >X-MSMail-Priority: Normal >X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 >Importance: Normal >In-Reply-To: <9807312258.AA17629@acecomm.com> >X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 >Content-Type: multipart/mixed; > boundary="----=_NextPart_000_0085_01BDBE1A.0436A880" > > > >Ashish K Hanwadikar >Senior Software Engineer, >Wipro Infotech, Technology Solutions, >Bangalore >INDIA > >-----Original Message----- >From: Bob Natale [mailto:bnatale@acecomm.com] >Sent: Saturday, August 01, 1998 4:29 AM >To: Martin Jacobsson >Cc: Smitha Gudur; agentx@peer.com >Subject: Re: open issues in agentX MIB > > >>At 7/31/98 11:56 PM, Martin Jacobsson wrote: > >Hi Martin, > >>Section 2, goal 4 says: >> >>- Provide statistics about the protocol operation such >>as the number of packets to and from each subagent >> >>This information is not available through the mib as defined. >>One option is to add agentxSessionInPackets and >>agentxSessionOutPackets to the session table. And another is >>to add agentxConnInPackets, agentxConnOutPackets, >>agentxConnProtocolErrors and agentxConnParseErrors >>to the connection table. All as Counter32's. > >First, let me note that there is considerable sentiment to >keep this MIB relatively minimal. > >Second, you are right, if state such purposes (and the >one you quote seems like a sound one to me). The approach >that I would like to propose for this purpose is to add >an agentxResponseTable. This would be indexed by >agentxSessionID and consist of a set of objects (with >syntax of GAUGE32, I suggest), one for each of the possible >AgentX-Response-PDU res.error codes (including no_error). > >Such a table would handle overall (by simple summing), >connection-specific (by mapping back to agentxConnectionTable >via the agentxConnIndex in the corresponding agentxSessionTable >row, and session-specific traffic and error counts for all >active sessions. > >>Then a port table would be nice, so that it is possible to see >>what ports the master agent accepts connections from > >I think this can be had now, via the agentxConnTransportDomain >and agentxConnTransportAddress objects in the agentxConnectionTable. >No...? > >>and if it listens on any nondefault ports. > >I'll pass on that one (I don't really see the need for it). > >>A typical unix master agent will listen on both tcp port >>705 and unix-domain socket "/var/agentx/master". > >True...and the two objects mentioned above would, I think, >tend to reveal that, given at least one active connection >from each domain. > > given at least one active connection .. That is the hitch. Suppose, >the sub agent wants to know which transport should he use to communicate >with the Master Agent? If no connections are active, then it is very >difficult to known on which transport domains the Master Agent is listening. >I think it will be generally be useful from the Sub Agent and Sub Agent API >developers point of view to add an agentxListenTable to the AgentX MIB. >I guess such a table was there in the DPI from which AgentX derives its >inspiration. There are other ways of finding out, which port the Master agent is listening. In unix environment, netstat and other commands would do the work. One suggestion, is such a table instead of being repeated in every MIB of agent/subagent protocol(s), it would be nice to have this table in SNMP which allows the user to know which agent protocols and ports these are listening to, at any time. smitha >Thanks >Cordially, > >BobN >------------ ISO 9001 Registered Quality Supplier ----------- >Bob Natale | ACE*COMM | 301-721-3000 [v] >Dir, Net Mgmt Prod | 704 Quince Orchard Rd | 301-721-3001 [f] >bnatale@acecomm.com| Gaithersburg MD 20878 | www.acecomm.com >------------- Free downloads at www.winsnmp.com ------------- > > ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com From bnatale@acecomm.com Mon Aug 3 14:44:30 1998 Delivery-Date: Mon, 03 Aug 1998 14:44:31 -0400 Return-Path: bnatale@acecomm.com Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id OAA23485 for ; Mon, 3 Aug 1998 14:44:30 -0400 (EDT) Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id OAA05267 for ; Mon, 3 Aug 1998 14:43:54 -0400 (EDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id NAA23106 for ; Mon, 3 Aug 1998 13:44:00 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma022854; Mon, 3 Aug 98 13:42:40 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id NAA25502 for ; Mon, 3 Aug 1998 13:41:52 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma019149; Mon, 3 Aug 98 13:35:05 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id NAA25644; Mon, 3 Aug 1998 13:31:52 -0500 (CDT) Received: from cashew.bmc.com (cashew.bmc.com [172.19.0.100]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id LAA09272 for ; Mon, 3 Aug 1998 11:19:02 -0700 (PDT) Received: (from uucp@localhost) by cashew.bmc.com (8.8.8/8.8.8) id NAA25206 for ; Mon, 3 Aug 1998 13:19:00 -0500 (CDT) Received: from relay1.smtp.psi.net(38.8.14.2) by cashew.bmc.com via smap (V2.0) id xma025170; Mon, 3 Aug 98 13:18:59 -0500 Received: from [192.152.208.5] (helo=acecomm.com) by relay1.smtp.psi.net with smtp (Exim 1.90 #1) id 0z3PB4-0005Mf-00; Mon, 3 Aug 1998 14:17:47 -0400 Received: from bnatale by acecomm.com (5.65/3.2.083191-ACE*COMM) id AA10947; Mon, 3 Aug 1998 14:20:02 -0400 Message-Id: <9808031820.AA10947@acecomm.com> X-Sender: natale@nips.acec.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1 Date: Mon, 03 Aug 1998 14:20:14 -0400 To: "Smitha Gudur" From: Bob Natale Subject: Table Indices in AgentX MIB Cc: agentx@peer.com In-Reply-To: <19980803165827.14580.qmail@hotmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" >At 8/3/98 09:58 AM, Smitha Gudur wrote: >Subject was: Re: open issues in agentX MIB Hi Smitha, <...> >> agentxConnectionTable >> agentxSessionTable >> agentxRegistrationTable >> >>In thinking through the relationships, it seems that we >>need to add agentxConnIndex to the AgentxSessionEntry and >>agentxSessionIndex to the AgentxRegistrationEntry. In this >>way, each registration entry can point to the session in >>which it lives and each session can point to the connection >>in which it lives. <...> >Currently, the agentxConnIndex is one of the indices for >agentxSessionEntry, and agentxSessionIndex is also one of >the indices for agentxRegistrationEntry. Implicit in my comments was the notion that each of the three tables needs only a single simple index, respectively: agentxConnectionTable agentxConnIndex agentxSessionTable agentxSessionIndex agentxRegistrationTable agentxRegIndex I can see no need for the multiple indices on agentxSessionTable (agentxConnIndex, agentxSessionIndex) or agentxRegistrationTable (agentxConnIndex, agentxSessionIndex, agentxRegIndex). It would lead to unnecessary ambiguity about the semantics of some of the protocol elements (SessionID, in particular); it would preclude certain useful queries (due to the not-accessible max access clauses of the index elements); and it just violates Occam's razor--using an (effectively) unique integer valued primary index for each table solves the problem w/o further adornment. The key relationship is on the agentxSessionIndex (SessionID). The registration info clearly depends on it and *if* we add the traffic/error info via the proposed agentxResponsesTable that would also tie to the agentxSessionIndex (indeed, it could be added directly to the agentxSessionTable as is... we would keep it separate only if we want to allow it to be a MODULE-COMPLIANCE option). >Do we still need each of these object-type for the >respective entries? Yes, but not as an "in addition to" (obviously) but (IMHO) rather "in lieu" of the multiple indexing. Cordially, BobN ------------ ISO 9001 Registered Quality Supplier ----------- Bob Natale | ACE*COMM | 301-721-3000 [v] Dir, Net Mgmt Prod | 704 Quince Orchard Rd | 301-721-3001 [f] bnatale@acecomm.com| Gaithersburg MD 20878 | www.acecomm.com ------------- Free downloads at www.winsnmp.com ------------- From daniele@zk3.dec.com Mon Aug 3 14:48:13 1998 Delivery-Date: Mon, 03 Aug 1998 14:48:13 -0400 Return-Path: daniele@zk3.dec.com Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id OAA23580 for ; Mon, 3 Aug 1998 14:48:12 -0400 (EDT) Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id OAA05291 for ; Mon, 3 Aug 1998 14:47:39 -0400 (EDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id NAA24018 for ; Mon, 3 Aug 1998 13:47:52 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma023721; Mon, 3 Aug 98 13:46:57 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id NAA29665 for ; Mon, 3 Aug 1998 13:46:19 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma019015; Mon, 3 Aug 98 13:35:02 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id NAA25636; Mon, 3 Aug 1998 13:31:50 -0500 (CDT) Received: from almond.bmc.com (almond.bmc.com [172.17.0.100]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id LAA09266 for ; Mon, 3 Aug 1998 11:17:05 -0700 (PDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id NAA19606 for ; Mon, 3 Aug 1998 13:17:04 -0500 (CDT) Received: from mail13.digital.com(192.208.46.30) by almond.bmc.com via smap (V2.0) id xma019565; Mon, 3 Aug 98 13:16:33 -0500 Received: from quarry.zk3.dec.com (fquarry.zk3.dec.com [16.140.160.9]) by mail13.digital.com (8.8.8/8.8.8/WV1.0g) with SMTP id OAA31792 for ; Mon, 3 Aug 1998 14:16:26 -0400 (EDT) Received: from bernie.zk3.dec.com by quarry.zk3.dec.com; (5.65v4.0/1.1.8.2/16Jan95-0946AM) id AA25138; Mon, 3 Aug 1998 14:16:26 -0400 Received: from localhost by bernie.zk3.dec.com; (5.65/1.1.8.2/22Aug96-1117AM) id AA21275; Mon, 3 Aug 1998 14:16:39 -0400 Message-Id: <9808031816.AA21275@bernie.zk3.dec.com> To: agentx@peer.com Subject: the use of registration priority Date: Mon, 03 Aug 98 14:16:39 -0400 From: Mike Daniele X-Mts: smtp Hi, Discussions after the recent bakeoff led to the question of what provisions there are in AgentX for a subagent to determine what index to use in registering instances. The provisions are a) index allocation provides a hint b) if a subagent gets a duplicateRegistration error it knows to try a different index It was pointed out that b) only happens if 2 subagents register the same region with the same value for priority. 6.2.3 says > r.priority > A value between 1 and 255, used to achieve a desired > configuration when different subagents register identical or > overlapping regions. Subagents with no particular knowledge of > priority should register with the default value of 255 (lowest > priority). It seems like a good idea to beef up this text, to make clear that using 255 is necessary for the master to detect duplicateRegistration (in general). something like this? A value between 1 and 255, used to achieve a desired configuration when different subagents register identical or overlapping regions. In the master agent's dispatching algorithm, smaller values of r.priority take precedence over larger values, as described in section 7.1.5.1. Subagents with no particular knowledge of priority should register with the default value of 255 (lowest priority). This convention permits the master agent to detect duplicate registrations and return that error to subagents, who may then take appropriate action (as describe in section 7.1.3). Using non-default values for priority is typically done by human administrators who wish to tailor a specific configuration. (7.1.3 could use a little expansion around this point too.) Mike From mithatch@cisco.com Mon Aug 3 14:48:57 1998 Delivery-Date: Mon, 03 Aug 1998 14:48:57 -0400 Return-Path: mithatch@cisco.com Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id OAA23602 for ; Mon, 3 Aug 1998 14:48:57 -0400 (EDT) Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id OAA05297 for ; Mon, 3 Aug 1998 14:48:32 -0400 (EDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id NAA24188 for ; Mon, 3 Aug 1998 13:48:46 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma023910; Mon, 3 Aug 98 13:47:33 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id NAA00246 for ; Mon, 3 Aug 1998 13:46:54 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma019161; Mon, 3 Aug 98 13:35:08 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id NAA25630; Mon, 3 Aug 1998 13:31:50 -0500 (CDT) Received: from cashew.bmc.com (cashew.bmc.com [172.19.0.100]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id LAA09276 for ; Mon, 3 Aug 1998 11:20:42 -0700 (PDT) Received: (from uucp@localhost) by cashew.bmc.com (8.8.8/8.8.8) id NAA25308 for ; Mon, 3 Aug 1998 13:20:40 -0500 (CDT) Received: from pleco.cisco.com(171.69.30.22) by cashew.bmc.com via smap (V2.0) id xma025296; Mon, 3 Aug 98 13:20:25 -0500 Received: from mithatch-ultra.cisco.com (mithatch-ultra.cisco.com [171.69.50.33]) by pleco.cisco.com (8.8.4-Cisco.1/8.6.5) with ESMTP id LAA17804; Mon, 3 Aug 1998 11:19:18 -0700 (PDT) Received: from cisco.com (localhost [127.0.0.1]) by mithatch-ultra.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/CISCO.WS.1.2) with ESMTP id LAA15507; Mon, 3 Aug 1998 11:19:18 -0700 (PDT) Sender: mithatch@cisco.com Message-ID: <35C5FF26.BE818E95@cisco.com> Date: Mon, 03 Aug 1998 11:19:18 -0700 From: Mike Thatcher X-Mailer: Mozilla 4.03C-CISCOENG [en] (X11; U; SunOS 5.5.1 sun4u) MIME-Version: 1.0 To: Bob Natale CC: Smitha Gudur , agentx@peer.com Subject: Re: open issues in agentX MIB References: <9807312232.AA17422@acecomm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bob Natale wrote: > >At 7/31/98 02:45 PM, Smitha Gudur wrote: > > Hi Smitha, > > >There is relationship between sessionID defined in RFC2257 and > >the agentxSessionIndex. > > Logically, that's true. The value used for agentxSessionIndex > to identify the session should be the same as that used for > the SessionID as given by the master agent to the subagent. Now this may have been discussed before, and if so could you review the reasoning. But if the value for for agentxSessionIndex is expected to be the value of the SessionID, why don't you call it agentxSessionID? Otherwise people like me may read the MIB and since there is no reference to sessionID, could implement this as a unique value assigned by the MIB implementation with no reference to sessionID at all. MikeT From dbh@cabletron.com Mon Aug 3 15:01:04 1998 Delivery-Date: Mon, 03 Aug 1998 15:01:04 -0400 Return-Path: dbh@cabletron.com Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id PAA23930 for ; Mon, 3 Aug 1998 15:01:03 -0400 (EDT) Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id PAA05350 for ; Mon, 3 Aug 1998 15:00:37 -0400 (EDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id OAA26751 for ; Mon, 3 Aug 1998 14:00:22 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma026366; Mon, 3 Aug 98 13:59:00 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id NAA11342 for ; Mon, 3 Aug 1998 13:58:21 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma029353; Mon, 3 Aug 98 13:46:00 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id NAA28977; Mon, 3 Aug 1998 13:43:58 -0500 (CDT) Received: from cashew.bmc.com (cashew.bmc.com [172.19.0.100]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id LAA09416 for ; Mon, 3 Aug 1998 11:35:39 -0700 (PDT) Received: (from uucp@localhost) by cashew.bmc.com (8.8.8/8.8.8) id NAA26113 for ; Mon, 3 Aug 1998 13:35:37 -0500 (CDT) Received: from ctron-dnm.cabletron.com(199.92.133.126) by cashew.bmc.com via smap (V2.0) id xma026099; Mon, 3 Aug 98 13:35:36 -0500 Received: (from uucp@localhost) by ctron-dnm.ctron.com (8.8.7/8.8.7) id OAA17661 for ; Mon, 3 Aug 1998 14:35:14 -0400 (EDT) Received: from roc-mail2.ctron.com(134.141.72.230) by ctron-dnm.ctron.com via smap (4.1) id xma017652; Mon, 3 Aug 98 14:34:20 -0400 Received: from dur-mail.ctron.com (dur-mail [134.141.69.20]) by roc-mail2.ctron.com (8.8.7/8.8.7) with ESMTP id OAA21787 for ; Mon, 3 Aug 1998 14:34:20 -0400 (EDT) Received: from cabletron.com (gimli.ctron.com [134.141.64.24]) by dur-mail.ctron.com (8.8.7/8.8.7) with ESMTP id OAA04513 for ; Mon, 3 Aug 1998 14:35:50 -0400 (EDT) Sender: dbh@cabletron.com Message-ID: <35C601C7.327C73E0@cabletron.com> Date: Mon, 03 Aug 1998 14:30:31 -0400 From: David Harrington Organization: Cabletron Systems, Inc X-Mailer: Mozilla 4.05 [en] (X11; I; SunOS 5.5.1 sun4u) MIME-Version: 1.0 To: agentx@peer.com Subject: Re: open issues in agentX MIB References: <19980803170408.10567.qmail@hotmail.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Smitha Gudur wrote: > > > > >Section 2, goal 4 says: > > > >- Provide statistics about the protocol operation such as the number of > > packets to and from each subagent > > > >This information is not available through the mib as defined. > >One option is to add agentxSessionInPackets and agentxSessionOutPackets > to > >the session table. And another is to add agentxConnInPackets, > >agentxConnOutPackets, agentxConnProtocolErrors and > agentxConnParseErrors > >to the connection table. All as Counter32's. > > As Bob said, the objective is to keep the MIB minimal. > The statistics were defined in detail in the early version of the MIB > and were subsequently removed as it was felt there were not adding any > usefulness except in debugging. > I have not followed agentX very closely, since it is agent-centric, and I am very manager-centric, but I am concerned that information that would be helpful to network operators and snmp applications may be eliminated in the quest for a minimal MIB. If I understand correctly the purposes of agentX, it is to make it 1) easier for devlopers to provide their domain-centric piece, and 2) to permit developers to write their code to a consistent interface for attachment to potentially multiple master-agent toolkits. I believe I have seen allusions to a future of dynamic linking and registration (or other dynamic associations between master and subagent pieces). If dynamic "attachment" is likely to be supported by implementations, then debugging could well become a problem that network operators and snmp applications must deal with. Under those conditions, having the statistics regarding the number of packets, and the number of errors could be very important for determining the cause of problems and/or inconsistencies in the network management information gathered. This information could be especially valuable if one sub-agent's registration can supercede another's registration, which I believe is part of the spec. My point is that "debugging" may be necessary at run-time, not just development time, so good information should be available at run-time. my $.02 dbh -- ----------------------------------------------------- #include David Harrington dbh@cabletron.com Spectrum Network Management Platform Core Group Cabletron Systems Inc. ----------------------------------------------------- From daniele@zk3.dec.com Mon Aug 3 15:14:49 1998 Delivery-Date: Mon, 03 Aug 1998 15:14:50 -0400 Return-Path: daniele@zk3.dec.com Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id PAA24241 for ; Mon, 3 Aug 1998 15:14:49 -0400 (EDT) Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id PAA05451 for ; Mon, 3 Aug 1998 15:14:28 -0400 (EDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id OAA29938 for ; Mon, 3 Aug 1998 14:14:45 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma029451; Mon, 3 Aug 98 14:12:39 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id OAA24103 for ; Mon, 3 Aug 1998 14:12:03 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma011336; Mon, 3 Aug 98 13:58:17 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id NAA02176; Mon, 3 Aug 1998 13:55:09 -0500 (CDT) Received: from almond.bmc.com (almond.bmc.com [172.17.0.100]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id LAA09461 for ; Mon, 3 Aug 1998 11:51:09 -0700 (PDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id NAA24740 for ; Mon, 3 Aug 1998 13:51:03 -0500 (CDT) Received: from mail11.digital.com(192.208.46.10) by almond.bmc.com via smap (V2.0) id xma024400; Mon, 3 Aug 98 13:49:56 -0500 Received: from quarry.zk3.dec.com (fquarry.zk3.dec.com [16.140.160.9]) by mail11.digital.com (8.8.8/8.8.8/WV1.0g) with SMTP id OAA14112; Mon, 3 Aug 1998 14:49:47 -0400 (EDT) Received: from bernie.zk3.dec.com by quarry.zk3.dec.com; (5.65v4.0/1.1.8.2/16Jan95-0946AM) id AA28014; Mon, 3 Aug 1998 14:49:46 -0400 Received: from localhost by bernie.zk3.dec.com; (5.65/1.1.8.2/22Aug96-1117AM) id AA21320; Mon, 3 Aug 1998 14:49:59 -0400 Message-Id: <9808031849.AA21320@bernie.zk3.dec.com> To: Bill Fenner Cc: agentx@peer.com Subject: Re: Misleading wording in section 8.1.2: AgentX over TCP operation In-Reply-To: Your message of "Fri, 31 Jul 98 12:11:00 PDT." <98Jul31.121113pdt.177515@crevenia.parc.xerox.com> Date: Mon, 03 Aug 98 14:49:59 -0400 From: Mike Daniele X-Mts: smtp >Section 8.1.2 says: > All AgentX PDUs are presented individually to the TCP, to be sent as > the data portion of a TCP PDU. >Applications can't control TCP PDU's; e.g. if you do 3 small TCP writes >in a row, most TCP's will coalesce the 2nd and 3rd write into a single >TCP PDU. And, of course, large writes will be fragmented into multiple >TCP PDU's. Yep. "as" should have been "within". >I'd suggest removing this sentence in the next version of the document, >since how you present data to TCP has very little to do with how TCP >puts the data into PDU's. What we need to say is that the sender's byte stream contain a sequence of complete AgentX PDUs. The sender cannot interleave PDUs fragments. Thanks for the comments, Mike From bnatale@acecomm.com Mon Aug 3 15:16:46 1998 Delivery-Date: Mon, 03 Aug 1998 15:16:46 -0400 Return-Path: bnatale@acecomm.com Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id PAA24333 for ; Mon, 3 Aug 1998 15:16:46 -0400 (EDT) Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id PAA05466 for ; Mon, 3 Aug 1998 15:16:18 -0400 (EDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id OAA00382 for ; Mon, 3 Aug 1998 14:16:31 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma029959; Mon, 3 Aug 98 14:14:54 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id OAA25930 for ; Mon, 3 Aug 1998 14:14:11 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma006912; Mon, 3 Aug 98 13:53:49 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id NAA00960; Mon, 3 Aug 1998 13:51:12 -0500 (CDT) Received: from cashew.bmc.com (cashew.bmc.com [172.19.0.100]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id LAA09438 for ; Mon, 3 Aug 1998 11:45:55 -0700 (PDT) Received: (from uucp@localhost) by cashew.bmc.com (8.8.8/8.8.8) id NAA26696 for ; Mon, 3 Aug 1998 13:45:53 -0500 (CDT) Received: from relay1.smtp.psi.net(38.8.14.2) by cashew.bmc.com via smap (V2.0) id xmaa26687; Mon, 3 Aug 98 13:45:31 -0500 Received: from [192.152.208.5] (helo=acecomm.com) by relay1.smtp.psi.net with smtp (Exim 1.90 #1) id 0z3PbY-0000tD-00; Mon, 3 Aug 1998 14:45:19 -0400 Received: from bnatale by acecomm.com (5.65/3.2.083191-ACE*COMM) id AA12135; Mon, 3 Aug 1998 14:47:06 -0400 Message-Id: <9808031847.AA12135@acecomm.com> X-Sender: natale@nips.acec.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1 Date: Mon, 03 Aug 1998 14:47:17 -0400 To: Mike Thatcher From: Bob Natale Subject: Re: open issues in agentX MIB Cc: agentx@peer.com In-Reply-To: <35C5FF26.BE818E95@cisco.com> References: <9807312232.AA17422@acecomm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" >At 8/3/98 11:19 AM, Mike Thatcher wrote: Hi Mike, >>>There is relationship between sessionID defined in RFC2257 and >>>the agentxSessionIndex. >> >> Logically, that's true. The value used for agentxSessionIndex >> to identify the session should be the same as that used for >> the SessionID as given by the master agent to the subagent. > >Now this may have been discussed before, and if so could you review >the reasoning. But if the value for for agentxSessionIndex is >expected to be the value of the SessionID, why don't you call it >agentxSessionID? Otherwise people like me may read the MIB and >since there is no reference to sessionID, could implement this as >a unique value assigned by the MIB implementation with no reference >to sessionID at all. Yes, you are exactly right...and that is, in part, why the current process of normalizing the MIB doc wrt the protocol doc is under way. At this stage, I'd say it's not a totally unidirectional process--i.e., we *could* identify some useful MIB construct that might need supporting text in the protocol document...but I can't see anything like that on the horizon. I suppose that Smitha and/or Maria was/were just trying to be internally self-consistent with naming conventions in an earlier rev of the MIB and the wording stuck...'til now. I agree with you that it would be wise to use identical terminology--driven by that used in RFC 2257--in every place possible in the MIB document (ditto in any eventual API document that the WG might elect to work on in the future). >MikeT [Btw, Mike, mail I send to your Cisco address keeps bouncing back to me...I assume you're getting this via the AgentX list ok...and your rahul.net address seems to work for me...?] Cordially, BobN ------------ ISO 9001 Registered Quality Supplier ----------- Bob Natale | ACE*COMM | 301-721-3000 [v] Dir, Net Mgmt Prod | 704 Quince Orchard Rd | 301-721-3001 [f] bnatale@acecomm.com| Gaithersburg MD 20878 | www.acecomm.com ------------- Free downloads at www.winsnmp.com ------------- From daniele@zk3.dec.com Mon Aug 3 15:17:55 1998 Delivery-Date: Mon, 03 Aug 1998 15:17:55 -0400 Return-Path: daniele@zk3.dec.com Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id PAA24376 for ; Mon, 3 Aug 1998 15:17:55 -0400 (EDT) Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id PAA05471 for ; Mon, 3 Aug 1998 15:17:33 -0400 (EDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id OAA00624 for ; Mon, 3 Aug 1998 14:17:43 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma000127; Mon, 3 Aug 98 14:15:46 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id OAA26644 for ; Mon, 3 Aug 1998 14:15:06 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma007090; Mon, 3 Aug 98 13:53:58 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id NAA00959; Mon, 3 Aug 1998 13:51:12 -0500 (CDT) Received: from cashew.bmc.com (cashew.bmc.com [172.19.0.100]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id LAA09437 for ; Mon, 3 Aug 1998 11:45:54 -0700 (PDT) Received: (from uucp@localhost) by cashew.bmc.com (8.8.8/8.8.8) id NAA26698 for ; Mon, 3 Aug 1998 13:45:53 -0500 (CDT) Received: from mail13.digital.com(192.208.46.30) by cashew.bmc.com via smap (V2.0) id xma026688; Mon, 3 Aug 98 13:45:37 -0500 Received: from flume.zk3.dec.com (flambe.zk3.dec.com [16.140.96.19]) by mail13.digital.com (8.8.8/8.8.8/WV1.0g) with SMTP id OAA09148; Mon, 3 Aug 1998 14:45:25 -0400 (EDT) Received: from bernie.zk3.dec.com by flume.zk3.dec.com (5.65v4.0/1.1.8.2/16Jan95-0946AM) id AA32090; Mon, 3 Aug 1998 14:45:24 -0400 Received: from localhost by bernie.zk3.dec.com; (5.65/1.1.8.2/22Aug96-1117AM) id AA21304; Mon, 3 Aug 1998 14:45:33 -0400 Message-Id: <9808031845.AA21304@bernie.zk3.dec.com> To: Bill Fenner Cc: agentx@peer.com Subject: Re: Can an AgnetX sub-agent send an AgentX-GET PDU to the AgentX master? In-Reply-To: Your message of "Fri, 31 Jul 98 11:50:52 PDT." <98Jul31.115055pdt.177515@crevenia.parc.xerox.com> Date: Mon, 03 Aug 98 14:45:33 -0400 From: Mike Daniele X-Mts: smtp Hi, > Let's say I have a routing daemon which wants to present a MIB which >happens to include ifindex values. However, the local interface to >ifindex value mapping happens in a different subagent; the routing >daemon doesn't know what this mapping is. It has to walk the iftable >and try to match that up with its view of the interfaces. Can this >routing daemon send AgentX-GET PDU's up to the master agent and expect >it to dispatch them to the right sub-agent and dispatch the reply back >to me all via AgentX, or do I have to use SNMP for this part? You have to use SNMP (or some other mechanism) for this part. > I ask because it seems like a shame that an application that only wants >to be an AgentX sub-agent also has to be able to be an SNMP client. I agree it seems like a shame, but it was agreed very early on that subagent to subagent communications (and security considerations) was way out of scope. Fyi, the issue is being raised again by the DISMAN WG. A final note, off the subject of AgentX: Many systems (bsd for example) provide interface indexing within the kernel interface structures, and point to interface info from the kernel route structures. So it's entirely possible that no local mapping need be done by any subagent, just use the kernel's if_index values. (Possible now because the interfaces MIB permits if_index values > ifNumber). Regards, Mike From battle@snmp.com Mon Aug 3 15:39:01 1998 Delivery-Date: Mon, 03 Aug 1998 15:39:01 -0400 Return-Path: battle@snmp.com Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id PAA25097 for ; Mon, 3 Aug 1998 15:39:01 -0400 (EDT) Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id PAA05585 for ; Mon, 3 Aug 1998 15:38:41 -0400 (EDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id OAA05630 for ; Mon, 3 Aug 1998 14:38:57 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma005451; Mon, 3 Aug 98 14:38:05 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id OAA17705 for ; Mon, 3 Aug 1998 14:37:22 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma015961; Mon, 3 Aug 98 14:35:28 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id OAA12676; Mon, 3 Aug 1998 14:35:06 -0500 (CDT) Received: from cashew.bmc.com (cashew.bmc.com [172.19.0.100]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id MAA09531 for ; Mon, 3 Aug 1998 12:20:43 -0700 (PDT) Received: (from uucp@localhost) by cashew.bmc.com (8.8.8/8.8.8) id OAA28403 for ; Mon, 3 Aug 1998 14:20:42 -0500 (CDT) Received: from seymour16.snmp.com(192.147.142.16) by cashew.bmc.com via smap (V2.0) id xma028369; Mon, 3 Aug 98 14:20:12 -0500 Received: by seymour16.snmp.com (cf v2.9s-SNMP) id PAA04246; Mon, 3 Aug 1998 15:20:07 -0400 (EDT) Date: Mon, 3 Aug 1998 15:20:07 -0400 (EDT) From: David Battle Message-Id: <199808031920.PAA04246@seymour16.snmp.com> To: agentx@peer.com Subject: default priority suggestion >It seems like we might want to not require the *lowest* priority as >the default. What if an operator was faced with the following >situation: >subagent A which registers some mib region at the default priority >and has no option for registering it at a different priority >subagent B which registers the same mib region at the default >priority but *does* provide a mechanism for registering at >a different priority >The operator would like for subagent A to "win" regardless of the order >in which the two subagents are started. How does he do this? Since >the default is the lowest, there is no way to "get in under" this >default priority. If the default were an intermediate value >then there would be room to "override" it with a higer priority or >"hide behind it" with a lower priority. (Originally a message to Mike Daniele directly, he requested I post it to the list). -David From daniele@zk3.dec.com Mon Aug 3 15:57:51 1998 Delivery-Date: Mon, 03 Aug 1998 15:57:51 -0400 Return-Path: daniele@zk3.dec.com Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id PAA25791 for ; Mon, 3 Aug 1998 15:57:50 -0400 (EDT) Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id PAA05708 for ; Mon, 3 Aug 1998 15:57:23 -0400 (EDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id OAA09036 for ; Mon, 3 Aug 1998 14:57:31 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma008766; Mon, 3 Aug 98 14:56:10 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id OAA05011 for ; Mon, 3 Aug 1998 14:55:30 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma000805; Mon, 3 Aug 98 14:51:31 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id OAA16562; Mon, 3 Aug 1998 14:50:04 -0500 (CDT) Received: from cashew.bmc.com (cashew.bmc.com [172.19.0.100]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id MAA09572 for ; Mon, 3 Aug 1998 12:43:11 -0700 (PDT) Received: (from uucp@localhost) by cashew.bmc.com (8.8.8/8.8.8) id OAA29632 for ; Mon, 3 Aug 1998 14:43:09 -0500 (CDT) Received: from mail13.digital.com(192.208.46.30) by cashew.bmc.com via smap (V2.0) id xma029619; Mon, 3 Aug 98 14:42:46 -0500 Received: from quarry.zk3.dec.com (fquarry.zk3.dec.com [16.140.160.9]) by mail13.digital.com (8.8.8/8.8.8/WV1.0g) with SMTP id PAA23654; Mon, 3 Aug 1998 15:42:28 -0400 (EDT) Received: from bernie.zk3.dec.com by quarry.zk3.dec.com; (5.65v4.0/1.1.8.2/16Jan95-0946AM) id AA21460; Mon, 3 Aug 1998 15:42:27 -0400 Received: from localhost by bernie.zk3.dec.com; (5.65/1.1.8.2/22Aug96-1117AM) id AA21344; Mon, 3 Aug 1998 15:42:40 -0400 Message-Id: <9808031942.AA21344@bernie.zk3.dec.com> To: Bob Natale Cc: agentx@peer.com, mithatch@cisco.com Subject: Re: open issues in agentX MIB In-Reply-To: Your message of "Mon, 03 Aug 98 14:47:17 EDT." <9808031847.AA12135@acecomm.com> Date: Mon, 03 Aug 98 15:42:40 -0400 From: Mike Daniele X-Mts: smtp Hi, >>Now this may have been discussed before, and if so could you review >>the reasoning. But if the value for for agentxSessionIndex is >>expected to be the value of the SessionID, why don't you call it >>agentxSessionID? Otherwise people like me may read the MIB and >>since there is no reference to sessionID, could implement this as >>a unique value assigned by the MIB implementation with no reference >>to sessionID at all. >I suppose that Smitha and/or Maria was/were just trying to >be internally self-consistent with naming conventions in an >earlier rev of the MIB and the wording stuck...'til now. >I agree with you that it would be wise to use identical >terminology--driven by that used in RFC 2257--in every >place possible in the MIB document (ditto in any eventual >API document that the WG might elect to work on in the >future). It's not just the name of the object, right? The real issue is, is agentxSessionIndex == h.SessionID? We need to say so in the MIB spec one way or the other. I asked a while ago > 5) Is the value of agentxSessionId the same as the sessionID field > within the protocol? And Randy replied >The value of agentxSessionIndex should map to the value of h.sessionID >used for a given session. The non-reuse requirements for the MIB index >are stricter than those for the protocol field. (Aside: why does the >protocol require that h.sessionID be given values unique across all of >a master agent's transports? The logical requirement for uniqueness >ends at the level of a transport connection.) Since we're moving toward refining h.SessionID to not be reused by the master within the realm of 32-bit rollover, it seems like the non-reuse requirements of the 2 are identical. Given that, it seems beneficial to me to use an index with semantic meaning. Make them the same value. I think the name agentxSessionIndex is fine. I think the description should state this value must equal h.SessionID for this session. Note, currently it's legal to use a SessionID of 0. If we're going to make agentxSessionIndex == h.SessionID, we may want to stipulate SessionIDs start at 1. Mike From sivakumar@cthulhu.engr.sgi.com Mon Aug 3 16:30:48 1998 Delivery-Date: Mon, 03 Aug 1998 16:30:49 -0400 Return-Path: sivakumar@cthulhu.engr.sgi.com Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id QAA27168 for ; Mon, 3 Aug 1998 16:30:48 -0400 (EDT) Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id QAA05919 for ; Mon, 3 Aug 1998 16:30:29 -0400 (EDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id PAA12601 for ; Mon, 3 Aug 1998 15:30:38 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma012453; Mon, 3 Aug 98 15:30:01 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id PAA05856 for ; Mon, 3 Aug 1998 15:29:22 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma003937; Mon, 3 Aug 98 15:27:29 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id PAA26510; Mon, 3 Aug 1998 15:25:39 -0500 (CDT) Received: from cashew.bmc.com (cashew.bmc.com [172.19.0.100]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id NAA09873 for ; Mon, 3 Aug 1998 13:17:19 -0700 (PDT) Received: (from uucp@localhost) by cashew.bmc.com (8.8.8/8.8.8) id PAA01440 for ; Mon, 3 Aug 1998 15:17:17 -0500 (CDT) Received: from sgi.com(192.48.153.1) by cashew.bmc.com via smap (V2.0) id xma001420; Mon, 3 Aug 98 15:16:53 -0500 Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id NAA11291 for <@sgi.engr.sgi.com:agentx@peer.com>; Mon, 3 Aug 1998 13:16:51 -0700 (PDT) mail_from (sivakumar@cthulhu.engr.sgi.com) Received: from nandadevi.engr.sgi.com (nandadevi.engr.sgi.com [150.166.76.34]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id NAA02406 for <@cthulhu.engr.sgi.com:agentx@peer.com>; Mon, 3 Aug 1998 13:16:50 -0700 (PDT) mail_from (sivakumar@cthulhu.engr.sgi.com) Received: from engr.sgi.com (localhost [127.0.0.1]) by nandadevi.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id NAA12442 for ; Mon, 3 Aug 1998 13:15:56 -0700 (PDT) Sender: sivakumar@cthulhu.engr.sgi.com Message-ID: <35C61A7C.7419BA5F@engr.sgi.com> Date: Mon, 03 Aug 1998 13:15:56 -0700 From: Sivakumar Narayanan Reply-To: sivakumar@cthulhu.engr.sgi.com Organization: Silicon Graphics Inc. X-Mailer: Mozilla 4.05 [en] (X11; I; IRIX 6.5 IP32) MIME-Version: 1.0 To: agentx@peer.com Subject: MIB views and agentx Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, I have been reading the agentx rfc. One thing is not clear to me. The agentx-based subagents will be ignorant of MIB views and access lists. Suppose we implement an enterprise-specific MIB in an independent subagent; and suppose that the MIB defines RMON-like alarm tables to monitor specific objects. If the user tries to create a new entry, how can the subagent know if the particular mib object A corresponding to "The variable to be monitored" exists in the particular MIB view ? There is a possibility that the current MIB view does not even allow read access to the object A. So, setting up an alarm for this variable is not allowed. But, how can the subagent know from the master whether A exists in the current MIB view or not? Any help is appreciated. Thanks, Siva -- Sivakumar Narayanan Silicon Graphics Inc. Tel# 650 933 5249 (W) Email: sivakumar@engr.sgi.com From bnatale@acecomm.com Mon Aug 3 16:56:29 1998 Delivery-Date: Mon, 03 Aug 1998 16:56:29 -0400 Return-Path: bnatale@acecomm.com Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id QAA28319 for ; Mon, 3 Aug 1998 16:56:28 -0400 (EDT) Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id QAA06060 for ; Mon, 3 Aug 1998 16:56:03 -0400 (EDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id PAA16035 for ; Mon, 3 Aug 1998 15:56:19 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma015731; Mon, 3 Aug 98 15:55:11 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id PAA27967 for ; Mon, 3 Aug 1998 15:54:29 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma022960; Mon, 3 Aug 98 15:49:08 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id PAA02711; Mon, 3 Aug 1998 15:47:22 -0500 (CDT) Received: from almond.bmc.com (almond.bmc.com [172.17.0.100]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id NAA10066 for ; Mon, 3 Aug 1998 13:34:16 -0700 (PDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id PAA13400 for ; Mon, 3 Aug 1998 15:34:13 -0500 (CDT) Received: from relay1.smtp.psi.net(38.8.14.2) by almond.bmc.com via smap (V2.0) id xma013201; Mon, 3 Aug 98 15:33:21 -0500 Received: from [192.152.208.5] (helo=acecomm.com) by relay1.smtp.psi.net with smtp (Exim 1.90 #1) id 0z3RI0-0001B0-00; Mon, 3 Aug 1998 16:33:04 -0400 Received: from bnatale by acecomm.com (5.65/3.2.083191-ACE*COMM) id AA15080; Mon, 3 Aug 1998 16:35:17 -0400 Message-Id: <9808032035.AA15080@acecomm.com> X-Sender: natale@nips.acec.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1 Date: Mon, 03 Aug 1998 16:35:28 -0400 To: Mike Daniele From: Bob Natale Subject: Re: open issues in agentX MIB Cc: agentx@peer.com In-Reply-To: <9808031942.AA21344@bernie.zk3.dec.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" >At 8/3/98 03:42 PM, Mike Daniele wrote: Hi Mike, <...> >It's not just the name of the object, right? >The real issue is, is agentxSessionIndex == h.SessionID? >We need to say so in the MIB spec one way or the other. Right. >I asked a while ago > >> 5) Is the value of agentxSessionId the same as the sessionID field >> within the protocol? > >And Randy replied > >>The value of agentxSessionIndex should map to the value of h.sessionID >>used for a given session. The non-reuse requirements for the MIB index >>are stricter than those for the protocol field. (Aside: why does the >>protocol require that h.sessionID be given values unique across all of >>a master agent's transports? The logical requirement for uniqueness >>ends at the level of a transport connection.) > >Since we're moving toward refining h.SessionID to not be reused by the >master within the realm of 32-bit rollover, it seems like the non-reuse >requirements of the 2 are identical. Right. Maintaining uniqueness of h.SessionID across all active sessions--irrespective of transport connections--is simpler than maintaining uniqueness within transport connections and yields more payoff to boot (e.g., simplifying registration relationships and possibly traffic/error reporting). >Given that, it seems beneficial to me to use an index with semantic >meaning. Make them the same value. Yes. >I think the name agentxSessionIndex is fine. Ok by me. >I think the description should state this value must equal h.SessionID >for this session. Yes. >Note, currently it's legal to use a SessionID of 0. If we're going >to make agentxSessionIndex == h.SessionID, we may want to stipulate >SessionIDs start at 1. I favor this stipulation too. Cordially, BobN ------------ ISO 9001 Registered Quality Supplier ----------- Bob Natale | ACE*COMM | 301-721-3000 [v] Dir, Net Mgmt Prod | 704 Quince Orchard Rd | 301-721-3001 [f] bnatale@acecomm.com| Gaithersburg MD 20878 | www.acecomm.com ------------- Free downloads at www.winsnmp.com ------------- From sgudur@hotmail.com Mon Aug 3 16:58:55 1998 Delivery-Date: Mon, 03 Aug 1998 16:58:55 -0400 Return-Path: sgudur@hotmail.com Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id QAA28437 for ; Mon, 3 Aug 1998 16:58:55 -0400 (EDT) Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id QAA06069 for ; Mon, 3 Aug 1998 16:57:28 -0400 (EDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id PAA16313 for ; Mon, 3 Aug 1998 15:57:38 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma016074; Mon, 3 Aug 98 15:56:27 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id PAA29274 for ; Mon, 3 Aug 1998 15:55:49 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma023873; Mon, 3 Aug 98 15:50:09 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id PAA02865; Mon, 3 Aug 1998 15:48:06 -0500 (CDT) Received: from almond.bmc.com (almond.bmc.com [172.17.0.100]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id NAA10114 for ; Mon, 3 Aug 1998 13:42:31 -0700 (PDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id PAA14057 for ; Mon, 3 Aug 1998 15:42:29 -0500 (CDT) Received: from f171.hotmail.com(207.82.251.57) by almond.bmc.com via smap (V2.0) id xma014004; Mon, 3 Aug 98 15:42:05 -0500 Received: (qmail 548 invoked by uid 0); 3 Aug 1998 20:41:53 -0000 Message-ID: <19980803204153.547.qmail@hotmail.com> Received: from 152.67.249.57 by www.hotmail.com with HTTP; Mon, 03 Aug 1998 13:41:53 PDT X-Originating-IP: [152.67.249.57] From: "Smitha Gudur" To: bnatale@acecomm.com Cc: agentx@peer.com Subject: Re: Table Indices in AgentX MIB Content-Type: text/plain Date: Mon, 03 Aug 1998 13:41:53 PDT Hi, Bob, >From bnatale@acecomm.com Mon Aug 3 11:17:55 1998 >Received: from [192.152.208.5] (helo=acecomm.com) > by relay1.smtp.psi.net with smtp (Exim 1.90 #1) > id 0z3PB4-0005Mf-00; Mon, 3 Aug 1998 14:17:47 -0400 >Received: from bnatale by acecomm.com (5.65/3.2.083191-ACE*COMM) > id AA10947; Mon, 3 Aug 1998 14:20:02 -0400 >Message-Id: <9808031820.AA10947@acecomm.com> >X-Sender: natale@nips.acec.com >X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1 >Date: Mon, 03 Aug 1998 14:20:14 -0400 >To: "Smitha Gudur" >From: Bob Natale >Subject: Table Indices in AgentX MIB >Cc: agentx@peer.com >In-Reply-To: <19980803165827.14580.qmail@hotmail.com> >Mime-Version: 1.0 >Content-Type: text/plain; charset="us-ascii" > >>At 8/3/98 09:58 AM, Smitha Gudur wrote: >>Subject was: Re: open issues in agentX MIB > >Hi Smitha, > ><...> >>> agentxConnectionTable >>> agentxSessionTable >>> agentxRegistrationTable >>> >>>In thinking through the relationships, it seems that we >>>need to add agentxConnIndex to the AgentxSessionEntry and >>>agentxSessionIndex to the AgentxRegistrationEntry. In this >>>way, each registration entry can point to the session in >>>which it lives and each session can point to the connection >>>in which it lives. ><...> >>Currently, the agentxConnIndex is one of the indices for >>agentxSessionEntry, and agentxSessionIndex is also one of >>the indices for agentxRegistrationEntry. > >Implicit in my comments was the notion that each of the >three tables needs only a single simple index, respectively: > > agentxConnectionTable agentxConnIndex > agentxSessionTable agentxSessionIndex > agentxRegistrationTable agentxRegIndex > >I can see no need for the multiple indices on agentxSessionTable The reason for adding multiple indices goes back to Jurgen posting as on Tue, March 17 1998 and the follow up discussion. Jurgen's posting: >The AgentX MIB has three tables: >1) agentxConnectionTable >2) agentxSessionTable >3) agentxRegistrationTable >There is a 1:n relationship between 1) and 2) and another 1:n >relationship between 2) and 3). Further, every session is bound to a >single connection and every registration is bound to a single >session. This means that the relationships between the tables can be >modeled by the indexing structure (a): > agentxConnectionTable > INDEX { agentxConnIndex } > agentxSessionTable > INDEX { agentxConnIndex, agentxSessionIndex } > agentxRegistrationTable > INDEX { agentxConnIndex, agentxSessionIndex, agentxRegIndex } >The draft of the AgentX MIB uses a >different approach (b). Every table has a single index and there is a >to the agentxConnectionTable. There is also a column >agentxRegSessionIndex in the agentxRegistrationTable which points >back to the agentxSessionTable. >I think approach (a) has nice properties: First, you can use the >natural order to easily get all registrations for a given session or >all sessions on a given connection. Second, you don't need to make >additional lookups if you want to know the connection associated with >a given registration. Third, you save two columns. Finally, it >simplifies the description of some object types (e.g. agentxRegStart >and agentxRegEnd) because the subagent is implicitely identified by >the instance identifier. Of course, the cost of approach (a) is that >each instance identifier gets two more components, which means at >least 2 additional bytes per instance identifier. And it was agreed at that time that approach (a) is a beter way to implement this. regards smitha >(agentxConnIndex, agentxSessionIndex) or agentxRegistrationTable >(agentxConnIndex, agentxSessionIndex, agentxRegIndex). > >It would lead to unnecessary ambiguity about the semantics >of some of the protocol elements (SessionID, in particular); >it would preclude certain useful queries (due to the >not-accessible max access clauses of the index elements); >and it just violates Occam's razor--using an (effectively) >unique integer valued primary index for each table solves >the problem w/o further adornment. > >The key relationship is on the agentxSessionIndex (SessionID). >The registration info clearly depends on it and *if* we add >the traffic/error info via the proposed agentxResponsesTable >that would also tie to the agentxSessionIndex (indeed, it >could be added directly to the agentxSessionTable as is... >we would keep it separate only if we want to allow it to >be a MODULE-COMPLIANCE option). > >>Do we still need each of these object-type for the >>respective entries? > >Yes, but not as an "in addition to" (obviously) but >(IMHO) rather "in lieu" of the multiple indexing. > >Cordially, > >BobN >------------ ISO 9001 Registered Quality Supplier ----------- >Bob Natale | ACE*COMM | 301-721-3000 [v] >Dir, Net Mgmt Prod | 704 Quince Orchard Rd | 301-721-3001 [f] >bnatale@acecomm.com| Gaithersburg MD 20878 | www.acecomm.com >------------- Free downloads at www.winsnmp.com ------------- > > ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com From bnatale@acecomm.com Mon Aug 3 17:20:21 1998 Delivery-Date: Mon, 03 Aug 1998 17:20:21 -0400 Return-Path: bnatale@acecomm.com Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id RAA29335 for ; Mon, 3 Aug 1998 17:20:20 -0400 (EDT) Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id RAA06199 for ; Mon, 3 Aug 1998 17:19:53 -0400 (EDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id QAA19740 for ; Mon, 3 Aug 1998 16:18:50 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma019587; Mon, 3 Aug 98 16:18:10 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id QAA18752 for ; Mon, 3 Aug 1998 16:17:30 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma017161; Mon, 3 Aug 98 16:15:38 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id QAA09403; Mon, 3 Aug 1998 16:14:10 -0500 (CDT) Received: from almond.bmc.com (almond.bmc.com [172.17.0.100]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id OAA10381 for ; Mon, 3 Aug 1998 14:06:39 -0700 (PDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id QAA18255 for ; Mon, 3 Aug 1998 16:06:20 -0500 (CDT) Received: from relay4.smtp.psi.net(38.9.52.2) by almond.bmc.com via smap (V2.0) id xma017924; Mon, 3 Aug 98 16:04:10 -0500 Received: from [192.152.208.5] (helo=acecomm.com) by relay4.smtp.psi.net with smtp (Exim 1.90 #1) id 0z3Rlq-0006LV-00; Mon, 3 Aug 1998 17:03:56 -0400 Received: from bnatale by acecomm.com (5.65/3.2.083191-ACE*COMM) id AA15696; Mon, 3 Aug 1998 17:05:58 -0400 Message-Id: <9808032105.AA15696@acecomm.com> X-Sender: natale@nips.acec.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1 Date: Mon, 03 Aug 1998 17:06:09 -0400 To: "Smitha Gudur" From: Bob Natale Subject: Re: Table Indices in AgentX MIB Cc: agentx@peer.com In-Reply-To: <19980803204153.547.qmail@hotmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" >At 8/3/98 01:41 PM, Smitha Gudur wrote: Hi Smitha, <...much of helpful summary deleted...> >>This means that the relationships between the tables can be >>modeled by the indexing structure (a): > >> agentxConnectionTable >> INDEX { agentxConnIndex } > >> agentxSessionTable >> INDEX { agentxConnIndex, agentxSessionIndex } > >> agentxRegistrationTable >> INDEX { agentxConnIndex, agentxSessionIndex, agentxRegIndex } > >And it was agreed at that time that approach (a) is a beter way >to implement this. Where each table has a simple *unique* natural index, there is (IMHO) only cost incurred (and no value derived) from requiring other index elements to access a row. Perhaps we were not considering the uniqueness requirement or implications at the time Juergen made his suggestion (a)...? >>The draft of the AgentX MIB >>uses a different approach (b). Every table has a single index >>and there is a to the agentxConnectionTable. ??????????????????????????????????????????? >>There is also a column agentxRegSessionIndex in the >>agentxRegistrationTable which points back to the >>agentxSessionTable. Even though I might be missing something important that I cannot understand in the ?-lined phrase, I think we were on the right (or at least a preferable) track with this approach (b). Cordially, BobN ------------ ISO 9001 Registered Quality Supplier ----------- Bob Natale | ACE*COMM | 301-721-3000 [v] Dir, Net Mgmt Prod | 704 Quince Orchard Rd | 301-721-3001 [f] bnatale@acecomm.com| Gaithersburg MD 20878 | www.acecomm.com ------------- Free downloads at www.winsnmp.com ------------- From sgudur@hotmail.com Mon Aug 3 17:51:44 1998 Delivery-Date: Mon, 03 Aug 1998 17:51:44 -0400 Return-Path: sgudur@hotmail.com Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id RAA00380 for ; Mon, 3 Aug 1998 17:51:43 -0400 (EDT) Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id RAA06345 for ; Mon, 3 Aug 1998 17:51:08 -0400 (EDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id QAA23339 for ; Mon, 3 Aug 1998 16:51:24 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma023036; Mon, 3 Aug 98 16:50:13 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id QAA18720 for ; Mon, 3 Aug 1998 16:49:30 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma014007; Mon, 3 Aug 98 16:44:30 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id QAA16953; Mon, 3 Aug 1998 16:42:48 -0500 (CDT) Received: from almond.bmc.com (almond.bmc.com [172.17.0.100]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id OAA10576 for ; Mon, 3 Aug 1998 14:34:00 -0700 (PDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id QAA21311 for ; Mon, 3 Aug 1998 16:33:58 -0500 (CDT) Received: from f115.hotmail.com(207.82.250.165) by almond.bmc.com via smap (V2.0) id xma021296; Mon, 3 Aug 98 16:33:54 -0500 Received: (qmail 1286 invoked by uid 0); 3 Aug 1998 21:33:49 -0000 Message-ID: <19980803213349.1283.qmail@hotmail.com> Received: from 152.67.249.57 by www.hotmail.com with HTTP; Mon, 03 Aug 1998 14:33:48 PDT X-Originating-IP: [152.67.249.57] From: "Smitha Gudur" To: bnatale@acecomm.com Cc: agentx@peer.com Subject: agentxSessionIndex description Content-Type: text/plain Date: Mon, 03 Aug 1998 14:33:48 PDT Hi, Bob & Mike, So the changes to agentxSessionIndex description will be as follows: "agentxSesssionIndex is the same as h.sessionID defined in the agentx header. It is a unique index for the subagent session. Note that if a subagent's session with the master agent is closed for any reason its index should not be re-used, therefore, the values of agentxSessionIndex may not be contiguous and will generally not be the same for the same subagent across multiple sessions." thanks smitha >From bnatale@acecomm.com Mon Aug 3 13:59:01 1998 >Received: (from uucp@localhost) > by almond.bmc.com (8.8.8/8.8.8) id PAA16591 > for ; Mon, 3 Aug 1998 15:58:49 -0500 (CDT) >Received: from firewall.bmc.com(192.245.162.250) > by almond.bmc.com via smap (V2.0) > id xma016364; Mon, 3 Aug 98 15:58:04 -0500 >Received: (from uucp@localhost) > by dresden.bmc.com (8.8.5/8.8.6) id PAA00875 > for ; Mon, 3 Aug 1998 15:57:21 -0500 (CDT) >Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) > id xma024895; Mon, 3 Aug 98 15:51:22 -0500 >Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) > by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id PAA03166; > Mon, 3 Aug 1998 15:49:29 -0500 (CDT) >Received: from almond.bmc.com (almond.bmc.com [172.17.0.100]) > by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id NAA10066 > for ; Mon, 3 Aug 1998 13:34:16 -0700 (PDT) >Received: (from uucp@localhost) > by almond.bmc.com (8.8.8/8.8.8) id PAA13400 > for ; Mon, 3 Aug 1998 15:34:13 -0500 (CDT) >Received: from relay1.smtp.psi.net(38.8.14.2) > by almond.bmc.com via smap (V2.0) > id xma013201; Mon, 3 Aug 98 15:33:21 -0500 >Received: from [192.152.208.5] (helo=acecomm.com) > by relay1.smtp.psi.net with smtp (Exim 1.90 #1) > id 0z3RI0-0001B0-00; Mon, 3 Aug 1998 16:33:04 -0400 >Received: from bnatale by acecomm.com (5.65/3.2.083191-ACE*COMM) > id AA15080; Mon, 3 Aug 1998 16:35:17 -0400 >Message-Id: <9808032035.AA15080@acecomm.com> >X-Sender: natale@nips.acec.com >X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1 >Date: Mon, 03 Aug 1998 16:35:28 -0400 >To: Mike Daniele >From: Bob Natale >Subject: Re: open issues in agentX MIB >Cc: agentx@peer.com >In-Reply-To: <9808031942.AA21344@bernie.zk3.dec.com> >References: >Mime-Version: 1.0 >Content-Type: text/plain; charset="us-ascii" > >>At 8/3/98 03:42 PM, Mike Daniele wrote: > >Hi Mike, > ><...> >>It's not just the name of the object, right? >>The real issue is, is agentxSessionIndex == h.SessionID? >>We need to say so in the MIB spec one way or the other. > >Right. > >>I asked a while ago >> >>> 5) Is the value of agentxSessionId the same as the sessionID field >>> within the protocol? >> >>And Randy replied >> >>>The value of agentxSessionIndex should map to the value of h.sessionID >>>used for a given session. The non-reuse requirements for the MIB index >>>are stricter than those for the protocol field. (Aside: why does the >>>protocol require that h.sessionID be given values unique across all of >>>a master agent's transports? The logical requirement for uniqueness >>>ends at the level of a transport connection.) >> >>Since we're moving toward refining h.SessionID to not be reused by the >>master within the realm of 32-bit rollover, it seems like the non-reuse >>requirements of the 2 are identical. > >Right. Maintaining uniqueness of h.SessionID across all active >sessions--irrespective of transport connections--is simpler than >maintaining uniqueness within transport connections and yields >more payoff to boot (e.g., simplifying registration relationships >and possibly traffic/error reporting). > >>Given that, it seems beneficial to me to use an index with semantic >>meaning. Make them the same value. > >Yes. > >>I think the name agentxSessionIndex is fine. > >Ok by me. > >>I think the description should state this value must equal h.SessionID >>for this session. > >Yes. > >>Note, currently it's legal to use a SessionID of 0. If we're going >>to make agentxSessionIndex == h.SessionID, we may want to stipulate >>SessionIDs start at 1. > >I favor this stipulation too. > >Cordially, > >BobN >------------ ISO 9001 Registered Quality Supplier ----------- >Bob Natale | ACE*COMM | 301-721-3000 [v] >Dir, Net Mgmt Prod | 704 Quince Orchard Rd | 301-721-3001 [f] >bnatale@acecomm.com| Gaithersburg MD 20878 | www.acecomm.com >------------- Free downloads at www.winsnmp.com ------------- > > ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com From rpresuhn@dorothy.bmc.com Mon Aug 3 17:55:08 1998 Delivery-Date: Mon, 03 Aug 1998 17:55:08 -0400 Return-Path: rpresuhn@dorothy.bmc.com Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id RAA00567 for ; Mon, 3 Aug 1998 17:55:08 -0400 (EDT) Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id RAA06369 for ; Mon, 3 Aug 1998 17:54:43 -0400 (EDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id QAA24042 for ; Mon, 3 Aug 1998 16:54:52 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma023760; Mon, 3 Aug 98 16:53:17 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id QAA21697 for ; Mon, 3 Aug 1998 16:52:38 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma017923; Mon, 3 Aug 98 16:48:27 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id QAA18164; Mon, 3 Aug 1998 16:46:46 -0500 (CDT) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id OAA10590 for agentx@peer.com; Mon, 3 Aug 1998 14:38:11 -0700 (PDT) Date: Mon, 3 Aug 1998 14:38:11 -0700 (PDT) From: Randy Presuhn Message-Id: <199808032138.OAA10590@dorothy.bmc.com> To: agentx@peer.com Subject: Re: Table Indices in AgentX MIB Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi - > Date: Mon, 03 Aug 1998 17:06:09 -0400 > To: "Smitha Gudur" > From: Bob Natale > Subject: Re: Table Indices in AgentX MIB > Cc: agentx@peer.com ... > Where each table has a simple *unique* natural index, there > is (IMHO) only cost incurred (and no value derived) from > requiring other index elements to access a row. ... There are other good reasons for using multiple indexes. For example, since multiple sessions can be multiplexed over a single connection, if the session table is singly indexed it will be necessary to walk the whole table to determine which sessions are multiplexed over a particular connection. If the table is indexed by both connection and session identifiers, the retrieval takes far fewer transactions. This depends on the kinds of usage scenarios the MIB is intended to support. Ones that I've found useful in the past with other subagent protocols: 1) determine the current membership of the set of subagents 2) "disconnect" a particular session or connection 3) "delete" (render ineffective) a specific registration 4) determine what mib regions a particular subagent has claimed responsibility for (actually more interesting than finding out what subagent has claimed responsibility for a particular mib region) ----------------------------------------------------------------------- Randy Presuhn Email: rpresuhn@bmc.com http://www.bmc.com Voice: +1 408 616-3100 BMC Software, Inc. 965 Stewart Drive Fax: +1 408 616-3101 Sunnyvale, California 94086 USA ----------------------------------------------------------------------- In accordance with the BMC Communications Systems Use and Security Policy, I explicitly state that although my affiliation with BMC may be apparent, implied, or provided, my opinions are not necessarily those of BMC Software and that all external representations on behalf of BMC must first be cleared with a member of "the top management team." ----------------------------------------------------------------------- From rpresuhn@dorothy.bmc.com Mon Aug 3 18:05:33 1998 Delivery-Date: Mon, 03 Aug 1998 18:05:33 -0400 Return-Path: rpresuhn@dorothy.bmc.com Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id SAA00804 for ; Mon, 3 Aug 1998 18:05:33 -0400 (EDT) Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id SAA06419 for ; Mon, 3 Aug 1998 18:05:08 -0400 (EDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id RAA26704 for ; Mon, 3 Aug 1998 17:05:22 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma026007; Mon, 3 Aug 98 17:02:43 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id RAA00857 for ; Mon, 3 Aug 1998 17:02:05 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma025962; Mon, 3 Aug 98 16:57:16 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id QAA20746; Mon, 3 Aug 1998 16:55:35 -0500 (CDT) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id OAA10759 for agentx@peer.com; Mon, 3 Aug 1998 14:50:13 -0700 (PDT) Date: Mon, 3 Aug 1998 14:50:13 -0700 (PDT) From: Randy Presuhn Message-Id: <199808032150.OAA10759@dorothy.bmc.com> To: agentx@peer.com Subject: Re: agentxSessionIndex description Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi - > From: "Smitha Gudur" > To: bnatale@acecomm.com > Cc: agentx@peer.com > Subject: agentxSessionIndex description > Date: Mon, 03 Aug 1998 14:33:48 PDT ... > So the changes to agentxSessionIndex description will be as follows: > > "agentxSesssionIndex is the same as h.sessionID defined in the agentx > header. It is a unique index for the subagent session. Note that if a > subagent's session with the master agent is closed for any reason its > index should not be re-used, therefore, the values of agentxSessionIndex but (for any long-lived system) the value will have to be re-used eventually > may not be contiguous and will generally not be the same for the same ??? I think you mean "may be discontiguous" rather than "may not be contiguous". > subagent across multiple sessions." ... ----------------------------------------------------------------------- Randy Presuhn Email: rpresuhn@bmc.com http://www.bmc.com Voice: +1 408 616-3100 BMC Software, Inc. 965 Stewart Drive Fax: +1 408 616-3101 Sunnyvale, California 94086 USA ----------------------------------------------------------------------- In accordance with the BMC Communications Systems Use and Security Policy, I explicitly state that although my affiliation with BMC may be apparent, implied, or provided, my opinions are not necessarily those of BMC Software and that all external representations on behalf of BMC must first be cleared with a member of "the top management team." ----------------------------------------------------------------------- From rpresuhn@dorothy.bmc.com Mon Aug 3 18:27:30 1998 Delivery-Date: Mon, 03 Aug 1998 18:27:30 -0400 Return-Path: rpresuhn@dorothy.bmc.com Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id SAA01118 for ; Mon, 3 Aug 1998 18:27:29 -0400 (EDT) Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id SAA06528 for ; Mon, 3 Aug 1998 18:26:37 -0400 (EDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id RAA29061 for ; Mon, 3 Aug 1998 17:26:50 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma028587; Mon, 3 Aug 98 17:25:41 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id RAA19732 for ; Mon, 3 Aug 1998 17:25:05 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma018695; Mon, 3 Aug 98 17:24:13 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id RAA28683; Mon, 3 Aug 1998 17:24:03 -0500 (CDT) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id PAA10908 for agentx@peer.com; Mon, 3 Aug 1998 15:19:11 -0700 (PDT) Date: Mon, 3 Aug 1998 15:19:11 -0700 (PDT) From: Randy Presuhn Message-Id: <199808032219.PAA10908@dorothy.bmc.com> To: agentx@peer.com Subject: Re: MIB views and agentx Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi - > Date: Mon, 03 Aug 1998 13:15:56 -0700 > From: Sivakumar Narayanan > To: agentx@peer.com > Subject: MIB views and agentx ... > One thing is not clear to me. The agentx-based subagents will be > ignorant of MIB views and access lists. This is correct and intentional. > Suppose we implement an enterprise-specific MIB in an independent > subagent; and suppose that the MIB defines RMON-like alarm tables to > monitor specific objects. If the user tries to create a new entry, how > can the subagent know if the particular mib object A corresponding to > "The variable to be monitored" exists in the particular MIB view ? The subagent should not need to know this. Since the access control policy may change over time, the access decision function will have to be consulted when access is actually attempted, since the decision may be different from what would have resulted with the entry was created. The real question, then, is how does the monitor program make its requests? The answer is simple: SNMP. The subagent with the RMON-like table you describe would take a command generator role. The access decision function is consulted by the management application in the command responder role, not this RMON-like command generator. Now, in both the Disman and the SNMPv3 work we've said over and over that a particular implementation might provide all sorts of specialized infrastructure to do this efficiently. Architecturally, however, its pretty simple, as long as this RMON-like process acts on its own behalf. If the it needs to act on behalf of the user making the original request, life gets much more interesting. See the disman archives for more on this. > There is a possibility that the current MIB view does not even allow > read access to the object A. So, setting up an alarm for this variable > is not allowed. But, how can the subagent know from the master whether > A exists in the current MIB view or not? ... But what if the access policy is later changed to permit access? I think it's not a good idea to base access control decisions on old information. ----------------------------------------------------------------------- Randy Presuhn Email: rpresuhn@bmc.com http://www.bmc.com Voice: +1 408 616-3100 BMC Software, Inc. 965 Stewart Drive Fax: +1 408 616-3101 Sunnyvale, California 94086 USA ----------------------------------------------------------------------- In accordance with the BMC Communications Systems Use and Security Policy, I explicitly state that although my affiliation with BMC may be apparent, implied, or provided, my opinions are not necessarily those of BMC Software and that all external representations on behalf of BMC must first be cleared with a member of "the top management team." ----------------------------------------------------------------------- From sgudur@hotmail.com Mon Aug 3 18:35:05 1998 Delivery-Date: Mon, 03 Aug 1998 18:35:05 -0400 Return-Path: sgudur@hotmail.com Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id SAA01187 for ; Mon, 3 Aug 1998 18:35:04 -0400 (EDT) Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id SAA06562 for ; Mon, 3 Aug 1998 18:34:42 -0400 (EDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id RAA01021 for ; Mon, 3 Aug 1998 17:34:57 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma000815; Mon, 3 Aug 98 17:34:29 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id RAA28149 for ; Mon, 3 Aug 1998 17:33:53 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma025610; Mon, 3 Aug 98 17:31:21 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id RAA00229; Mon, 3 Aug 1998 17:30:12 -0500 (CDT) Received: from cashew.bmc.com (cashew.bmc.com [172.19.0.100]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id PAA11047 for ; Mon, 3 Aug 1998 15:27:20 -0700 (PDT) Received: (from uucp@localhost) by cashew.bmc.com (8.8.8/8.8.8) id RAA07983 for ; Mon, 3 Aug 1998 17:27:18 -0500 (CDT) Received: from f211.hotmail.com(207.82.251.102) by cashew.bmc.com via smap (V2.0) id xma007942; Mon, 3 Aug 98 17:26:48 -0500 Received: (qmail 13187 invoked by uid 0); 3 Aug 1998 22:26:30 -0000 Message-ID: <19980803222630.13186.qmail@hotmail.com> Received: from 152.67.249.57 by www.hotmail.com with HTTP; Mon, 03 Aug 1998 15:26:29 PDT X-Originating-IP: [152.67.249.57] From: "Smitha Gudur" To: rpresuhn@dorothy.bmc.com Cc: agentx@peer.com Subject: Re: agentxSessionIndex description Content-Type: text/plain Date: Mon, 03 Aug 1998 15:26:29 PDT Hi, Randy, >From rpresuhn@dorothy.bmc.com Mon Aug 3 15:04:09 1998 >Received: (from uucp@localhost) > by almond.bmc.com (8.8.8/8.8.8) id RAA26329 > for ; Mon, 3 Aug 1998 17:03:46 -0500 (CDT) >Received: from firewall.bmc.com(192.245.162.250) > by almond.bmc.com via smap (V2.0) > id xma025876; Mon, 3 Aug 98 17:02:22 -0500 >Received: (from uucp@localhost) > by dresden.bmc.com (8.8.5/8.8.6) id RAA00449 > for ; Mon, 3 Aug 1998 17:01:46 -0500 (CDT) >Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) > id xma027793; Mon, 3 Aug 98 16:59:03 -0500 >Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) > by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id QAA21186; > Mon, 3 Aug 1998 16:56:52 -0500 (CDT) >Received: (from rpresuhn@localhost) > by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id OAA10759 > for agentx@peer.com; Mon, 3 Aug 1998 14:50:13 -0700 (PDT) >Date: Mon, 3 Aug 1998 14:50:13 -0700 (PDT) >From: Randy Presuhn >Message-Id: <199808032150.OAA10759@dorothy.bmc.com> >To: agentx@peer.com >Subject: Re: agentxSessionIndex description >Mime-Version: 1.0 >Content-Type: text/plain; charset=us-ascii >Content-Transfer-Encoding: 7bit > >Hi - > >> From: "Smitha Gudur" >> To: bnatale@acecomm.com >> Cc: agentx@peer.com >> Subject: agentxSessionIndex description >> Date: Mon, 03 Aug 1998 14:33:48 PDT >... >> So the changes to agentxSessionIndex description will be as follows: >> >> "agentxSesssionIndex is the same as h.sessionID defined in the agentx >> header. It is a unique index for the subagent session. Note that if a >> subagent's session with the master agent is closed for any reason its >> index should not be re-used, therefore, the values of agentxSessionIndex > >but (for any long-lived system) the value will have to be re-used >eventually As Mike suggested in the earlier email that there will be a refinement to h.sessionID not to be reused. I thought it would be appropriate to add this in the MIB also. > >> may not be contiguous and will generally not be the same for the same > >??? I think you mean "may be discontiguous" rather than "may not be >contiguous". Yes. To make it more clearer I will change it to "may be discontiguous". thanks smitha > >> subagent across multiple sessions." >... > > ----------------------------------------------------------------------- > Randy Presuhn Email: rpresuhn@bmc.com http://www.bmc.com > Voice: +1 408 616-3100 BMC Software, Inc. 965 Stewart Drive > Fax: +1 408 616-3101 Sunnyvale, California 94086 USA > ----------------------------------------------------------------------- > In accordance with the BMC Communications Systems Use and Security > Policy, I explicitly state that although my affiliation with BMC may be > apparent, implied, or provided, my opinions are not necessarily those > of BMC Software and that all external representations on behalf of > BMC must first be cleared with a member of "the top management team." > ----------------------------------------------------------------------- > ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com From bnatale@acecomm.com Mon Aug 3 18:38:00 1998 Delivery-Date: Mon, 03 Aug 1998 18:38:00 -0400 Return-Path: bnatale@acecomm.com Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id SAA01198 for ; Mon, 3 Aug 1998 18:37:59 -0400 (EDT) Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id SAA06579 for ; Mon, 3 Aug 1998 18:37:38 -0400 (EDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id RAA02109 for ; Mon, 3 Aug 1998 17:37:57 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma001054; Mon, 3 Aug 98 17:35:01 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id RAA28807 for ; Mon, 3 Aug 1998 17:34:25 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma026137; Mon, 3 Aug 98 17:31:56 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id RAA00317; Mon, 3 Aug 1998 17:30:44 -0500 (CDT) Received: from almond.bmc.com (almond.bmc.com [172.17.0.100]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id PAA11125 for ; Mon, 3 Aug 1998 15:29:08 -0700 (PDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id RAA29633 for ; Mon, 3 Aug 1998 17:29:05 -0500 (CDT) Received: from relay4.smtp.psi.net(38.9.52.2) by almond.bmc.com via smap (V2.0) id xma029199; Mon, 3 Aug 98 17:27:14 -0500 Received: from [192.152.208.5] (helo=acecomm.com) by relay4.smtp.psi.net with smtp (Exim 1.90 #1) id 0z3T4R-0004C0-00; Mon, 3 Aug 1998 18:27:12 -0400 Received: from bnatale by acecomm.com (5.65/3.2.083191-ACE*COMM) id AA16713; Mon, 3 Aug 1998 18:29:22 -0400 Message-Id: <9808032229.AA16713@acecomm.com> X-Sender: natale@nips.acec.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1 Date: Mon, 03 Aug 1998 18:29:33 -0400 To: Randy Presuhn From: Bob Natale Subject: Re: Table Indices in AgentX MIB Cc: agentx@peer.com In-Reply-To: <199808032138.OAA10590@dorothy.bmc.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" >At 8/3/98 02:38 PM, Randy Presuhn wrote: Hi Randy, >There are other good reasons for using multiple indexes. There certainly are. I don't think they apply here, however. >For example, since multiple sessions can be multiplexed over >a single connection, if the session table is singly indexed >it will be necessary to walk the whole table to determine >which sessions are multiplexed over a particular connection. >If the table is indexed by both connection and session >identifiers, the retrieval takes far fewer transactions. >From a practical perspective, the "whole table" in this case (agentxSessionTable) will never be onerously large, hence I do not think that "far fewer" transactions will be realized. Furthermore, the frequency of this query is likely to be extremely low. >This depends on the kinds of usage scenarios the MIB is >intended to support. Yes, that is very important. >Ones that I've found useful in the past with other subagent >protocols: > > 1) determine the current membership of the set of subagents One must walk the entire agentxSessionTable under either approach to get this info; hence, the multiple indices on that table provide no gain here. > 2) "disconnect" a particular session or connection To enable the master to close a session requires only the single session's unique id into the agentxSessionTable (with its agentxConnIndex given there); hence, the multiple indices on that table provide no gain here. To enable the master to close all sessions over a given connection would require a scan of the agentxSessionTable in the single index scheme to identify all those over the single connection...however, again, I would judge this to be non-onerous because (1) the table will be small and (2) the frequency of the operation will be seldom. > 3) "delete" (render ineffective) a specific registration To enable the master to "delete" a specific registration would require only the single unique agentxRegIndex value; hence, the multiple indices on that table provide no gain here. > 4) determine what mib regions a particular subagent has claimed > responsibility for (actually more interesting than finding > out what subagent has claimed responsibility for a particular > mib region) This would require a scan of the agentxRegistrationTable in the single index scheme. While this table may be a bit larger on average than the agentxSessionTable, I do not envision it hitting any formidable size in the real world and, again, I see the frequency of this (and all other!) operations against the AgentX MIB to be minimal. For those kinds of reasons, I think extreme simplicity of design is all that is called for here...we're not really facing any serious performance or size constraints. OTOH, I don't want to push my point too hard...I guess it's safe to say the issue is still open...let's see if any other opinions pop up over the next few days. Cordially, BobN ------------ ISO 9001 Registered Quality Supplier ----------- Bob Natale | ACE*COMM | 301-721-3000 [v] Dir, Net Mgmt Prod | 704 Quince Orchard Rd | 301-721-3001 [f] bnatale@acecomm.com| Gaithersburg MD 20878 | www.acecomm.com ------------- Free downloads at www.winsnmp.com ------------- From rpresuhn@dorothy.bmc.com Mon Aug 3 19:12:55 1998 Delivery-Date: Mon, 03 Aug 1998 19:12:55 -0400 Return-Path: rpresuhn@dorothy.bmc.com Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id TAA01416 for ; Mon, 3 Aug 1998 19:12:55 -0400 (EDT) Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id TAA06745 for ; Mon, 3 Aug 1998 19:12:34 -0400 (EDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id SAA05304 for ; Mon, 3 Aug 1998 18:12:54 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma004774; Mon, 3 Aug 98 18:11:32 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id SAA19801 for ; Mon, 3 Aug 1998 18:10:54 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma018882; Mon, 3 Aug 98 18:09:57 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id SAA09333; Mon, 3 Aug 1998 18:10:00 -0500 (CDT) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id PAA11381 for agentx@peer.com; Mon, 3 Aug 1998 15:56:57 -0700 (PDT) Date: Mon, 3 Aug 1998 15:56:57 -0700 (PDT) From: Randy Presuhn Message-Id: <199808032256.PAA11381@dorothy.bmc.com> To: agentx@peer.com Subject: Re: Table Indices in AgentX MIB Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi - > Date: Mon, 03 Aug 1998 18:29:33 -0400 > To: Randy Presuhn > From: Bob Natale > Subject: Re: Table Indices in AgentX MIB > Cc: agentx@peer.com ... > From a practical perspective, the "whole table" in this case > (agentxSessionTable) will never be onerously large, hence > I do not think that "far fewer" transactions will be realized. How many subagents do you envision in a typical configuration? I've seen systems with literally dozens. > Furthermore, the frequency of this query is likely to be > extremely low. ... Granted. ----------------------------------------------------------------------- Randy Presuhn Email: rpresuhn@bmc.com http://www.bmc.com Voice: +1 408 616-3100 BMC Software, Inc. 965 Stewart Drive Fax: +1 408 616-3101 Sunnyvale, California 94086 USA ----------------------------------------------------------------------- In accordance with the BMC Communications Systems Use and Security Policy, I explicitly state that although my affiliation with BMC may be apparent, implied, or provided, my opinions are not necessarily those of BMC Software and that all external representations on behalf of BMC must first be cleared with a member of "the top management team." ----------------------------------------------------------------------- From Lauren_Heintz@crow.bmc.com Mon Aug 3 20:14:09 1998 Delivery-Date: Mon, 03 Aug 1998 20:14:09 -0400 Return-Path: Lauren_Heintz@crow.bmc.com Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id UAA01719 for ; Mon, 3 Aug 1998 20:14:08 -0400 (EDT) Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id UAA06942 for ; Mon, 3 Aug 1998 20:13:47 -0400 (EDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id TAA08898 for ; Mon, 3 Aug 1998 19:14:02 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma008447; Mon, 3 Aug 98 19:12:43 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id TAA12323 for ; Mon, 3 Aug 1998 19:12:05 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma011521; Mon, 3 Aug 98 19:11:10 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id TAA22249; Mon, 3 Aug 1998 19:11:28 -0500 (CDT) Received: from tangelo.bmc.com (root@tangelo.bmc.com [172.17.7.166]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id QAA11927 for ; Mon, 3 Aug 1998 16:58:08 -0700 (PDT) Received: from bmc.com (lucille.peer.com [192.146.153.185]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id SAA19843; Mon, 3 Aug 1998 18:58:06 -0500 (CDT) Message-ID: <35C64E15.201F3D6F@bmc.com> Date: Mon, 03 Aug 1998 16:56:05 -0700 From: Lauren Heintz X-Mailer: Mozilla 4.04 [en] (WinNT; U) MIME-Version: 1.0 To: agentx@peer.com Subject: AgentX transport MIB definitions Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, -- Since RFC 2257 makes equal reference to both TCP and Unix domain socket transports, shouldn't the AgentX MIB also do so? For example, the MIB has an AgentXTCPAddress TC definition, but no similar TC definition for Unix domain sockets. Similarly, an agentXTCPDomain object is defined, but not a corresponding one for Unix domain sockets. -- The AgentXTCPAddress TC should clarify the byte contents and ordering for objects of this type. For example: "Represents a TCP address consisting of a four byte IP address value followed by a two byte port value in network-byte order." Lauren -------------------------------------------------------------------------- Lauren Heintz BMC Software, Inc. (Formerly PEER Networks) Voice: +1 408 616-3169 Silicon Valley Division Fax: +1 408 616-3339 965 Stewart Drive Email: Lauren_Heintz@bmc.com Sunnyvale, California 94086 USA -------------------------------------------------------------------------- From sgudur@hotmail.com Mon Aug 3 20:50:50 1998 Delivery-Date: Mon, 03 Aug 1998 20:50:51 -0400 Return-Path: sgudur@hotmail.com Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id UAA01938 for ; Mon, 3 Aug 1998 20:50:50 -0400 (EDT) Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id UAA07052 for ; Mon, 3 Aug 1998 20:50:30 -0400 (EDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id TAA11539 for ; Mon, 3 Aug 1998 19:50:49 -0500 (CDT) Received: from dresden.bmc.com(198.64.253.250) by almond.bmc.com via smap (V2.0) id xma010770; Mon, 3 Aug 98 19:48:18 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id TAA22157 for ; Mon, 3 Aug 1998 19:47:34 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma021578; Mon, 3 Aug 98 19:46:51 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id TAA28773; Mon, 3 Aug 1998 19:47:07 -0500 (CDT) Received: from cashew.bmc.com (cashew.bmc.com [172.19.0.100]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id RAA12084 for ; Mon, 3 Aug 1998 17:42:03 -0700 (PDT) Received: (from uucp@localhost) by cashew.bmc.com (8.8.8/8.8.8) id TAA14403 for ; Mon, 3 Aug 1998 19:42:01 -0500 (CDT) Received: from f85.hotmail.com(207.82.250.191) by cashew.bmc.com via smap (V2.0) id xma014388; Mon, 3 Aug 98 19:41:46 -0500 Received: (qmail 7898 invoked by uid 0); 4 Aug 1998 00:41:45 -0000 Message-ID: <19980804004145.7897.qmail@hotmail.com> Received: from 152.67.249.57 by www.hotmail.com with HTTP; Mon, 03 Aug 1998 17:41:45 PDT X-Originating-IP: [152.67.249.57] From: "Smitha Gudur" To: Lauren_Heintz@crow.bmc.com Cc: agentx@peer.com Subject: Re: AgentX transport MIB definitions Content-Type: text/plain Date: Mon, 03 Aug 1998 17:41:45 PDT Hi, Lauren, >From lauren_heintz@crow.bmc.com Mon Aug 3 17:15:06 1998 >Received: (from uucp@localhost) > by almond.bmc.com (8.8.8/8.8.8) id TAA09251 > for ; Mon, 3 Aug 1998 19:14:59 -0500 (CDT) >Received: from firewall.bmc.com(192.245.162.250) > by almond.bmc.com via smap (V2.0) > id xma008605; Mon, 3 Aug 98 19:13:01 -0500 >Received: (from uucp@localhost) > by dresden.bmc.com (8.8.5/8.8.6) id TAA12787 > for ; Mon, 3 Aug 1998 19:12:25 -0500 (CDT) >Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) > id xma011782; Mon, 3 Aug 98 19:11:33 -0500 >Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) > by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id TAA22310; > Mon, 3 Aug 1998 19:11:52 -0500 (CDT) >Received: from tangelo.bmc.com (root@tangelo.bmc.com [172.17.7.166]) > by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id QAA11927 > for ; Mon, 3 Aug 1998 16:58:08 -0700 (PDT) >Received: from bmc.com (lucille.peer.com [192.146.153.185]) > by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id SAA19843; > Mon, 3 Aug 1998 18:58:06 -0500 (CDT) >Message-ID: <35C64E15.201F3D6F@bmc.com> >Date: Mon, 03 Aug 1998 16:56:05 -0700 >From: Lauren Heintz >X-Mailer: Mozilla 4.04 [en] (WinNT; U) >MIME-Version: 1.0 >To: agentx@peer.com >Subject: AgentX transport MIB definitions >Content-Type: text/plain; charset=us-ascii >Content-Transfer-Encoding: 7bit > >Hi, > >-- Since RFC 2257 makes equal reference to both TCP and >Unix domain socket transports, shouldn't the AgentX MIB also do so? >For example, the MIB has an AgentXTCPAddress TC definition, >but no similar TC definition for Unix domain sockets. Similarly, >an agentXTCPDomain object is defined, but not a corresponding one >for Unix domain sockets. Actually AgentxTCPAddress is not being used in the MIB. so this needs to be taken out. As there was no point in duplicating these definitions in this MIB, currently TDomain and TAddress are being used in the MIB. thanks smitha > >-- The AgentXTCPAddress TC should clarify the byte >contents and ordering for objects of this type. For example: > > "Represents a TCP address consisting of a four byte > IP address value followed by a two byte port value > in network-byte order." > >Lauren > >-------------------------------------------------------------------------- >Lauren Heintz BMC Software, Inc. (Formerly PEER Networks) >Voice: +1 408 616-3169 Silicon Valley Division >Fax: +1 408 616-3339 965 Stewart Drive >Email: Lauren_Heintz@bmc.com Sunnyvale, California 94086 USA >-------------------------------------------------------------------------- > ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com From Lauren_Heintz@crow.bmc.com Mon Aug 3 21:04:23 1998 Delivery-Date: Mon, 03 Aug 1998 21:04:23 -0400 Return-Path: Lauren_Heintz@crow.bmc.com Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id VAA02015 for ; Mon, 3 Aug 1998 21:04:22 -0400 (EDT) Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id VAA07087 for ; Mon, 3 Aug 1998 21:04:02 -0400 (EDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id UAA13264 for ; Mon, 3 Aug 1998 20:04:22 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma012881; Mon, 3 Aug 98 20:03:12 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id UAA28541 for ; Mon, 3 Aug 1998 20:02:29 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma027847; Mon, 3 Aug 98 20:01:39 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id UAA01995; Mon, 3 Aug 1998 20:01:51 -0500 (CDT) Received: from tangelo.bmc.com (root@tangelo.bmc.com [172.17.7.166]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id RAA12145 for ; Mon, 3 Aug 1998 17:57:08 -0700 (PDT) Received: from bmc.com (lucille.peer.com [192.146.153.185]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id TAA01027; Mon, 3 Aug 1998 19:57:05 -0500 (CDT) Message-ID: <35C65BE9.91106C1E@bmc.com> Date: Mon, 03 Aug 1998 17:55:05 -0700 From: Lauren Heintz X-Mailer: Mozilla 4.04 [en] (WinNT; U) MIME-Version: 1.0 To: sgudur@hotmail.com CC: agentx@peer.com Subject: Re: AgentX transport MIB definitions References: <19980804004145.7897.qmail@hotmail.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Smitha, While AgentXTCPAddress and AgentXTCPDomain are indeed not used in the AgentX MIB, they still need to be defined somewhere so that implementations can access and correctly interpet the TDomain and TAddress values. If they are not to be defined in the AgentX MIB, where then will they be defined? I couldn't find them defined anywhere else, so it seems we'll have to. Yes? No? Tks, Lauren sgudur@hotmail.com wrote: > > Hi, Lauren, > > >From lauren_heintz@crow.bmc.com Mon Aug 3 17:15:06 1998 > >Received: (from uucp@localhost) > > by almond.bmc.com (8.8.8/8.8.8) id TAA09251 > > for ; Mon, 3 Aug 1998 19:14:59 -0500 (CDT) > >Received: from firewall.bmc.com(192.245.162.250) > > by almond.bmc.com via smap (V2.0) > > id xma008605; Mon, 3 Aug 98 19:13:01 -0500 > >Received: (from uucp@localhost) > > by dresden.bmc.com (8.8.5/8.8.6) id TAA12787 > > for ; Mon, 3 Aug 1998 19:12:25 -0500 (CDT) > >Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via > smap (3.2) > > id xma011782; Mon, 3 Aug 98 19:11:33 -0500 > >Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) > > by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id TAA22310; > > Mon, 3 Aug 1998 19:11:52 -0500 (CDT) > >Received: from tangelo.bmc.com (root@tangelo.bmc.com [172.17.7.166]) > > by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id QAA11927 > > for ; Mon, 3 Aug 1998 16:58:08 -0700 (PDT) > >Received: from bmc.com (lucille.peer.com [192.146.153.185]) > > by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id SAA19843; > > Mon, 3 Aug 1998 18:58:06 -0500 (CDT) > >Message-ID: <35C64E15.201F3D6F@bmc.com> > >Date: Mon, 03 Aug 1998 16:56:05 -0700 > >From: Lauren Heintz > >X-Mailer: Mozilla 4.04 [en] (WinNT; U) > >MIME-Version: 1.0 > >To: agentx@peer.com > >Subject: AgentX transport MIB definitions > >Content-Type: text/plain; charset=us-ascii > >Content-Transfer-Encoding: 7bit > > > >Hi, > > > >-- Since RFC 2257 makes equal reference to both TCP and > >Unix domain socket transports, shouldn't the AgentX MIB also do so? > >For example, the MIB has an AgentXTCPAddress TC definition, > >but no similar TC definition for Unix domain sockets. Similarly, > >an agentXTCPDomain object is defined, but not a corresponding one > >for Unix domain sockets. > > Actually AgentxTCPAddress is not being used in the MIB. so this > needs to be taken out. > > As there was no point in duplicating these definitions in this MIB, > currently TDomain and TAddress are being used in the MIB. > > thanks > smitha > > > > >-- The AgentXTCPAddress TC should clarify the byte > >contents and ordering for objects of this type. For example: > > > > "Represents a TCP address consisting of a four byte > > IP address value followed by a two byte port value > > in network-byte order." > > > >Lauren > > > >-------------------------------------------------------------------------- > >Lauren Heintz BMC Software, Inc. (Formerly PEER > Networks) > >Voice: +1 408 616-3169 Silicon Valley Division > >Fax: +1 408 616-3339 965 Stewart Drive > >Email: Lauren_Heintz@bmc.com Sunnyvale, California 94086 USA > >-------------------------------------------------------------------------- > > > > ______________________________________________________ > Get Your Private, Free Email at http://www.hotmail.com -- -------------------------------------------------------------------------- Lauren Heintz BMC Software, Inc. (Formerly PEER Networks) Voice: +1 408 616-3169 Silicon Valley Division Fax: +1 408 616-3339 965 Stewart Drive Email: Lauren_Heintz@bmc.com Sunnyvale, California 94086 USA -------------------------------------------------------------------------- From mwhite@cmu.edu Tue Aug 4 00:21:17 1998 Delivery-Date: Tue, 04 Aug 1998 00:21:17 -0400 Return-Path: mwhite@cmu.edu Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id AAA11348 for ; Tue, 4 Aug 1998 00:21:17 -0400 (EDT) Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id AAA07623 for ; Tue, 4 Aug 1998 00:20:56 -0400 (EDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id XAA20949 for ; Mon, 3 Aug 1998 23:21:15 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma020366; Mon, 3 Aug 98 23:19:43 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id XAA00886 for ; Mon, 3 Aug 1998 23:19:07 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma000249; Mon, 3 Aug 98 23:18:34 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id XAA04488; Mon, 3 Aug 1998 23:18:56 -0500 (CDT) Received: from almond.bmc.com (almond.bmc.com [172.17.0.100]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id UAA12614 for ; Mon, 3 Aug 1998 20:55:09 -0700 (PDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id WAA19414 for ; Mon, 3 Aug 1998 22:55:08 -0500 (CDT) Received: from cmu1.acs.cmu.edu(128.2.35.186) by almond.bmc.com via smap (V2.0) id xma019406; Mon, 3 Aug 98 22:54:42 -0500 Received: from CLEANSE.MOBILE.NET.CMU.EDU (CLEANSE.MOBILE.NET.CMU.EDU [128.2.108.200]) by cmu1.acs.cmu.edu (8.8.5/8.8.5) with SMTP id XAA06422 for ; Mon, 3 Aug 1998 23:54:40 -0400 (EDT) Date: Mon, 03 Aug 1998 23:53:47 -0400 From: "Matt White" To: agentx@peer.com Subject: Re: open issues in agentX MIB Message-ID: <245295330.902188427@CLEANSE.MOBILE.NET.CMU.EDU> X-Mailer: Mulberry (Win32) [1.3.3, s/n S-100002] X-Authenticated: mwhite by cyrus.andrew.cmu.edu X-Licensed-To: site license MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit --On Monday, August 03, 1998, 3:42 PM -0400 "Mike Daniele" wrote: > Since we're moving toward refining h.SessionID to not be reused by the > master within the realm of 32-bit rollover, it seems like the non-reuse > requirements of the 2 are identical. I haven't said much until now about this, but I am afraid that I'm missing something here. Why is this necessary? The only reason I ask is that this will break the current CMU implementation of AgentX and might take a little time to fix. I haven't been following the MIB discussions as closely as I might, so perhaps I'm missing some motivation. However, it seems to me that MIB implementation should follow the protocol, not vice-versa. > Note, currently it's legal to use a SessionID of 0. If we're going to > make agentxSessionIndex == h.SessionID, we may want to stipulate > SessionIDs start at 1. This seems somewhat reasonable in any case for debugging purposes. -Matt ---------- Matt White Network Systems Designer Canegie Mellon Computing Services From bnatale@acecomm.com Tue Aug 4 01:25:27 1998 Delivery-Date: Tue, 04 Aug 1998 01:25:28 -0400 Return-Path: bnatale@acecomm.com Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id BAA11831 for ; Tue, 4 Aug 1998 01:25:27 -0400 (EDT) Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id BAA07767 for ; Tue, 4 Aug 1998 01:25:06 -0400 (EDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id AAA24263 for ; Tue, 4 Aug 1998 00:25:25 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma023988; Tue, 4 Aug 98 00:24:46 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id AAA16763 for ; Tue, 4 Aug 1998 00:24:04 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma015341; Tue, 4 Aug 98 00:22:40 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id AAA15118; Tue, 4 Aug 1998 00:23:01 -0500 (CDT) Received: from cashew.bmc.com (cashew.bmc.com [172.19.0.100]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id WAA12784 for ; Mon, 3 Aug 1998 22:12:01 -0700 (PDT) Received: (from uucp@localhost) by cashew.bmc.com (8.8.8/8.8.8) id AAA23194 for ; Tue, 4 Aug 1998 00:11:59 -0500 (CDT) Received: from relay4.smtp.psi.net(38.9.52.2) by cashew.bmc.com via smap (V2.0) id xma023187; Tue, 4 Aug 98 00:11:49 -0500 Received: from [192.152.208.5] (helo=acecomm.com) by relay4.smtp.psi.net with smtp (Exim 1.90 #1) id 0z3ZO0-0003iF-00; Tue, 4 Aug 1998 01:11:48 -0400 Received: from ppp1 by acecomm.com (5.65/3.2.083191-ACE*COMM) id AA18755; Tue, 4 Aug 1998 01:14:05 -0400 Message-Id: <9808040514.AA18755@acecomm.com> X-Sender: natale@nips.acec.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1 Date: Tue, 04 Aug 1998 01:14:45 -0400 To: Randy Presuhn From: Bob Natale Subject: Re: Table Indices in AgentX MIB Cc: agentx@peer.com In-Reply-To: <199808032256.PAA11381@dorothy.bmc.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" >At 8/3/98 03:56 PM, Randy Presuhn wrote: Hi Randy, >> From a practical perspective, the "whole table" in this case >> (agentxSessionTable) will never be onerously large, hence >> I do not think that "far fewer" transactions will be realized. > >How many subagents do you envision in a typical configuration? >I've seen systems with literally dozens. Sounds ok to me...I just don't consider 4-5 dozen entries in this table to be onerous, esp. in light of... >> Furthermore, the frequency of this query is likely to be >> extremely low. >... > >Granted. Cordially, BobN ---- ISO 9001 Registered, H/W & S/W Products| NASDAQ: ACEC ----- Bob Natale | ACE*COMM | 301-721-3000 [v] Dir, Net Mgmt Prod | 704 Quince Orchard Rd | 301-721-3001 [f] bnatale@acecomm.com | Gaithersburg MD 20878 | www.acecomm.com ----- WinSNMP DLL, SDK, Apps & Agents for Win16/32 & UNIX ------ ------ WinSNMP specs and sample code at www.winsnmp.com -------- From bnatale@acecomm.com Tue Aug 4 01:31:24 1998 Delivery-Date: Tue, 04 Aug 1998 01:31:24 -0400 Return-Path: bnatale@acecomm.com Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id BAA11885 for ; Tue, 4 Aug 1998 01:31:23 -0400 (EDT) Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id BAA07774 for ; Tue, 4 Aug 1998 01:31:03 -0400 (EDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id AAA25900 for ; Tue, 4 Aug 1998 00:31:22 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma025147; Tue, 4 Aug 98 00:29:08 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id AAA18189 for ; Tue, 4 Aug 1998 00:28:30 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma017774; Tue, 4 Aug 98 00:27:52 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id AAA15944; Tue, 4 Aug 1998 00:28:08 -0500 (CDT) Received: from cashew.bmc.com (cashew.bmc.com [172.19.0.100]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id WAA12808 for ; Mon, 3 Aug 1998 22:25:14 -0700 (PDT) Received: (from uucp@localhost) by cashew.bmc.com (8.8.8/8.8.8) id AAA23602 for ; Tue, 4 Aug 1998 00:25:13 -0500 (CDT) Received: from relay4.smtp.psi.net(38.9.52.2) by cashew.bmc.com via smap (V2.0) id xma023594; Tue, 4 Aug 98 00:25:08 -0500 Received: from [192.152.208.5] (helo=acecomm.com) by relay4.smtp.psi.net with smtp (Exim 1.90 #1) id 0z3Zas-00046b-00; Tue, 4 Aug 1998 01:25:07 -0400 Received: from ppp1 by acecomm.com (5.65/3.2.083191-ACE*COMM) id AA18828; Tue, 4 Aug 1998 01:27:23 -0400 Message-Id: <9808040527.AA18828@acecomm.com> X-Sender: natale@nips.acec.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1 Date: Tue, 04 Aug 1998 01:28:04 -0400 To: "Matt White" From: Bob Natale Subject: Re: open issues in agentX MIB Cc: agentx@peer.com In-Reply-To: <245295330.902188427@CLEANSE.MOBILE.NET.CMU.EDU> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" >At 8/3/98 11:53 PM, Matt White wrote: Hi Matt, >> Since we're moving toward refining h.SessionID to not be reused by the >> master within the realm of 32-bit rollover, it seems like the non-reuse >> requirements of the 2 are identical. > >I haven't said much until now about this, but I am afraid that I'm missing >something here. Why is this necessary? Avoiding re-use of small integer indices has simply become a matter of "good practice" where other factors do not dictate otherwise. (Note that, as has already been said, we can only do our best to avoid re-use, not mandate it...given the (logically possible) case of the long-running master that wraps...so far, we have not mandated "monotonically increasing", but that is also a good idea in this case... and, in any case, the active SessionID values in a given invocation of the master agent must be globally unique.) >The only reason I ask is that this will break the current CMU >implementation of AgentX and might take a little time to fix. At the bake-off, one implementation out of five under test (to the best of my knowledge) had taken the approach of quickly re-using SessionID values. The developers were able to make the switch to the "avoid re-use" model in a matter of minutes. That's just a single data point, I know; I realize that there may be many valid reasons why anyone else's mileage may vary. In any case, we'll be spending a little time fixing up one thing or another in our AgentX implementations for a while yet. :-) >I haven't been following the MIB discussions as closely as I might, so >perhaps I'm missing some motivation. However, it seems to me that MIB >implementation should follow the protocol, not vice-versa. Yes, I don't think you'll see too much debate with that...the twist, however, is that we are also refining the protocol spec in this process, esp. in areas where possible multiple interpretations exist or where some things were left a bit looser than necessary or sufficient. >> Note, currently it's legal to use a SessionID of 0. If we're going to >> make agentxSessionIndex == h.SessionID, we may want to stipulate >> SessionIDs start at 1. > >This seems somewhat reasonable in any case for debugging purposes. Right...good. Cordially, BobN ---- ISO 9001 Registered, H/W & S/W Products| NASDAQ: ACEC ----- Bob Natale | ACE*COMM | 301-721-3000 [v] Dir, Net Mgmt Prod | 704 Quince Orchard Rd | 301-721-3001 [f] bnatale@acecomm.com | Gaithersburg MD 20878 | www.acecomm.com ----- WinSNMP DLL, SDK, Apps & Agents for Win16/32 & UNIX ------ ------ WinSNMP specs and sample code at www.winsnmp.com -------- From schoenw@ibr.cs.tu-bs.de Tue Aug 4 04:09:09 1998 Delivery-Date: Tue, 04 Aug 1998 04:09:09 -0400 Return-Path: schoenw@ibr.cs.tu-bs.de Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id EAA12493 for ; Tue, 4 Aug 1998 04:09:08 -0400 (EDT) Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id EAA07985 for ; Tue, 4 Aug 1998 04:08:48 -0400 (EDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id DAA02156 for ; Tue, 4 Aug 1998 03:09:07 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma001623; Tue, 4 Aug 98 03:07:43 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id DAA23692 for ; Tue, 4 Aug 1998 03:07:07 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma023171; Tue, 4 Aug 98 03:06:36 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id DAA11274; Tue, 4 Aug 1998 03:06:56 -0500 (CDT) Received: from almond.bmc.com (almond.bmc.com [172.17.0.100]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id AAA13053 for ; Tue, 4 Aug 1998 00:51:06 -0700 (PDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id CAA00749 for ; Tue, 4 Aug 1998 02:51:05 -0500 (CDT) Received: from mumm.ibr.cs.tu-bs.de(134.169.34.190) by almond.bmc.com via smap (V2.0) id xma000743; Tue, 4 Aug 98 02:51:04 -0500 Received: from henkell.ibr.cs.tu-bs.de (schoenw@henkell [134.169.34.191]) by mumm.ibr.cs.tu-bs.de (8.9.1/8.9.0) with ESMTP id JAA09142; Tue, 4 Aug 1998 09:50:31 +0200 (MET DST) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id JAA09834; Tue, 4 Aug 1998 09:50:29 +0200 Date: Tue, 4 Aug 1998 09:50:29 +0200 Message-Id: <199808040750.JAA09834@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: Lauren_Heintz@crow.bmc.com CC: sgudur@hotmail.com, agentx@peer.com In-reply-to: <35C65BE9.91106C1E@bmc.com> (message from Lauren Heintz on Mon, 03 Aug 1998 17:55:05 -0700) Subject: Re: AgentX transport MIB definitions References: <19980804004145.7897.qmail@hotmail.com> <35C65BE9.91106C1E@bmc.com> Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII >>>>> Lauren Heintz writes: Lauren> While AgentXTCPAddress and AgentXTCPDomain are indeed not used Lauren> in the AgentX MIB, they still need to be defined somewhere so Lauren> that implementations can access and correctly interpet the Lauren> TDomain and TAddress values. Right. This is IMHO the job of the SNMP working group. We need a set of TDomain and TAddress definition in several places. Putting them into AgentX, IPv6, or application mgmt MIBs is the wrong approach. Please go to the SNMP meeting or the open area meeting and raise your voice that we need to make progress faster on things like this. Lauren> If they are not to be defined in the AgentX MIB, where then Lauren> will they be defined? I couldn't find them defined anywhere Lauren> else, so it seems we'll have to. Yes? No? I proposed on the SNMPv3 WG mailing list to move TDomain and TAddress definitions over to IANA. This allows to make updates with a much faster procedure so that the TC definitions can be extended as needed. Perhaps our ADs can help to solve this problem if the SNMPv3 has not the ressources to do this in a timely manner. Juergen Juergen Schoenwaelder schoenw@ibr.cs.tu-bs.de http://www.cs.tu-bs.de/~schoenw Technical University Braunschweig, Dept. Operating Systems & Computer Networks Bueltenweg 74/75, 38106 Braunschweig, Germany. (Tel. +49 531 / 391 3289) From schoenw@ibr.cs.tu-bs.de Tue Aug 4 04:19:42 1998 Delivery-Date: Tue, 04 Aug 1998 04:19:42 -0400 Return-Path: schoenw@ibr.cs.tu-bs.de Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id EAA12514 for ; Tue, 4 Aug 1998 04:19:41 -0400 (EDT) Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id EAA07995 for ; Tue, 4 Aug 1998 04:19:23 -0400 (EDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id DAA03760 for ; Tue, 4 Aug 1998 03:19:41 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma003270; Tue, 4 Aug 98 03:18:30 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id DAA27648 for ; Tue, 4 Aug 1998 03:17:54 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma027096; Tue, 4 Aug 98 03:17:17 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id DAA13182; Tue, 4 Aug 1998 03:17:40 -0500 (CDT) Received: from almond.bmc.com (almond.bmc.com [172.17.0.100]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id BAA13101 for ; Tue, 4 Aug 1998 01:11:11 -0700 (PDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id DAA02767 for ; Tue, 4 Aug 1998 03:11:09 -0500 (CDT) Received: from mumm.ibr.cs.tu-bs.de(134.169.34.190) by almond.bmc.com via smap (V2.0) id xma002146; Tue, 4 Aug 98 03:09:26 -0500 Received: from henkell.ibr.cs.tu-bs.de (schoenw@henkell [134.169.34.191]) by mumm.ibr.cs.tu-bs.de (8.9.1/8.9.0) with ESMTP id KAA09429; Tue, 4 Aug 1998 10:08:14 +0200 (MET DST) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id KAA11389; Tue, 4 Aug 1998 10:08:12 +0200 Date: Tue, 4 Aug 1998 10:08:12 +0200 Message-Id: <199808040808.KAA11389@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: bnatale@acecomm.com CC: sgudur@hotmail.com, agentx@peer.com In-reply-to: <9808032105.AA15696@acecomm.com> (message from Bob Natale on Mon, 03 Aug 1998 17:06:09 -0400) Subject: Re: Table Indices in AgentX MIB References: <9808032105.AA15696@acecomm.com> Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII >>>>> Bob Natale writes: Bob> Where each table has a simple *unique* natural index, there is Bob> (IMHO) only cost incurred (and no value derived) from requiring Bob> other index elements to access a row. I am quoting the complete email send on Tue, 17 Mar 1998 18:27:05 +0100 on this subject in order to make it clear what the trade-offs are: : The AgentX MIB has three tables: : : 1) agentxConnectionTable : 2) agentxSessionTable : 3) agentxRegistrationTable : : There is a 1:n relationship between 1) and 2) and another 1:n : relationship between 2) and 3). Further, every session is bound to a : single connection and every registration is bound to a single : session. This means that the relationships between the tables can be : modeled by the indexing structure (a): : : agentxConnectionTable : INDEX { agentxConnIndex } : : agentxSessionTable : INDEX { agentxConnIndex, agentxSessionIndex } : : agentxRegistrationTable : INDEX { agentxConnIndex, agentxSessionIndex, agentxRegIndex } : : The draft of the AgentX MIB uses a : different approach (b). Every table has a single index and there is a : column agentxSessionConnIndex in the agentxSessionTable which points : to the agentxConnectionTable. There is also a column : agentxRegSessionIndex in the agentxRegistrationTable which points : back to the agentxSessionTable. : : I think approach (a) has nice properties: First, you can use the : natural order to easily get all registrations for a given session or : all sessions on a given connection. Second, you don't need to make : additional lookups if you want to know the connection associated with : a given registration. Third, you save two columns. Finally, it : simplifies the description of some object types (e.g. agentxRegStart : and agentxRegEnd) because the subagent is implicitely identified by : the instance identifier. Of course, the cost of approach (a) is that : each instance identifier gets two more components, which means at : least 2 additional bytes per instance identifier. : : Approach (b) does not lead to a natural sorting order, which means : that in most cases the complete tables have to be read in order to get : e.g. all registrations for a given session. Are there any reasons for : choosing approach (b)? There are additional benefits of using the indexing structure I proposed in March. For example, you can use VACM efficiently to define access control rules for particular connections or sessions over a particular connection. Anyway, you claim that the indexing approach b) is simpler. Please explain where you see the benefits. I argue that option b) - needs more objects (to establish the relationships); - makes manager interactions more expensive in some situations; - makes VACM configuration harder. So, where are the benefits of b)? Is it that your getnext function is slightly more complex? This really depends on the data structures you use. In some cases, option a) might even be simpler to implement. Is there something else which makes option b) more expensive than option a). Given the advantages cited above, do you think the trade-off justifies to use b)? I still believe that the hidden costs of choosing b) can in the long term cause us serious problems (and therefore costs) and we should be very carefull to not make the wrong decision here. Juergen Juergen Schoenwaelder schoenw@ibr.cs.tu-bs.de http://www.cs.tu-bs.de/~schoenw Technical University Braunschweig, Dept. Operating Systems & Computer Networks Bueltenweg 74/75, 38106 Braunschweig, Germany. (Tel. +49 531 / 391 3289) From mwhite@cmu.edu Tue Aug 4 10:05:34 1998 Delivery-Date: Tue, 04 Aug 1998 10:05:34 -0400 Return-Path: mwhite@cmu.edu Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id KAA17057 for ; Tue, 4 Aug 1998 10:05:33 -0400 (EDT) Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id KAA08933 for ; Tue, 4 Aug 1998 10:05:14 -0400 (EDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id JAA18247 for ; Tue, 4 Aug 1998 09:05:32 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma018055; Tue, 4 Aug 98 09:04:56 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id JAA05176 for ; Tue, 4 Aug 1998 09:04:18 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma003885; Tue, 4 Aug 98 09:02:58 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id JAA16445; Tue, 4 Aug 1998 09:01:30 -0500 (CDT) Received: from cashew.bmc.com (cashew.bmc.com [172.19.0.100]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id GAA13723 for ; Tue, 4 Aug 1998 06:32:45 -0700 (PDT) Received: (from uucp@localhost) by cashew.bmc.com (8.8.8/8.8.8) id IAA07610 for ; Tue, 4 Aug 1998 08:32:42 -0500 (CDT) Received: from cmu1.acs.cmu.edu(128.2.35.186) by cashew.bmc.com via smap (V2.0) id xma007601; Tue, 4 Aug 98 08:32:19 -0500 Received: from SUBNET6-LO.DYNAMIC.NET.CMU.EDU (SUBNET6-LO.DYNAMIC.NET.CMU.EDU [128.2.6.97]) by cmu1.acs.cmu.edu (8.8.5/8.8.5) with SMTP id JAA18391; Tue, 4 Aug 1998 09:32:16 -0400 (EDT) Date: Tue, 04 Aug 1998 09:31:19 -0400 From: "Matt White" To: agentx@peer.com cc: "Bob Natale" Subject: Re: open issues in agentX MIB Message-ID: <279947820.902223079@SUBNET6-LO.DYNAMIC.NET.CMU.EDU> X-Mailer: Mulberry (Win32) [1.3.3, s/n S-100002] X-Authenticated: mwhite by cyrus.andrew.cmu.edu X-Licensed-To: site license MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit --On Tuesday, August 04, 1998, 1:28 AM -0400 "Bob Natale" wrote: > Avoiding re-use of small integer indices has simply become a matter > of "good practice" where other factors do not dictate otherwise. > > (Note that, as has already been said, we can only do our best to > avoid re-use, not mandate it...given the (logically possible) case > of the long-running master that wraps...so far, we have not mandated > "monotonically increasing", but that is also a good idea in this case... > and, in any case, the active SessionID values in a given invocation > of the master agent must be globally unique.) I suppose. I'm not experienced enough with this to have any first hand experience with reusing integer indices causing problems. Which is of course why I chose to reuse them in the first place. > At the bake-off, one implementation out of five under test (to the > best of my knowledge) had taken the approach of quickly re-using > SessionID values. The developers were able to make the switch > to the "avoid re-use" model in a matter of minutes. That's just > a single data point, I know; I realize that there may be many > valid reasons why anyone else's mileage may vary. Well, it's not quite that trivial in my case, but I imagine that it's probably not more than a day of coding to replace my dynamic arrays with hash tables. Our memory footprint will probably increase, but if that is the worst thing that happens to me this year... > In any case, we'll be spending a little time fixing up one > thing or another in our AgentX implementations for a while > yet. :-) Yeah, I was mostly just being grumpy when I made my orginal post. -Matt From rpresuhn@dorothy.bmc.com Tue Aug 4 11:43:15 1998 Delivery-Date: Tue, 04 Aug 1998 11:43:16 -0400 Return-Path: rpresuhn@dorothy.bmc.com Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id LAA09832 for ; Tue, 4 Aug 1998 11:43:14 -0400 (EDT) Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id LAA10287 for ; Tue, 4 Aug 1998 11:42:55 -0400 (EDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id KAA27112 for ; Tue, 4 Aug 1998 10:43:13 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma026865; Tue, 4 Aug 98 10:41:54 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id KAA00135 for ; Tue, 4 Aug 1998 10:41:16 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma029425; Tue, 4 Aug 98 10:40:39 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id KAA16058; Tue, 4 Aug 1998 10:39:37 -0500 (CDT) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id HAA14013; Tue, 4 Aug 1998 07:53:42 -0700 (PDT) Date: Tue, 4 Aug 1998 07:53:42 -0700 (PDT) From: Randy Presuhn Message-Id: <199808041453.HAA14013@dorothy.bmc.com> To: agentx@dorothy.bmc.com Subject: Agentx list dilemma Cc: ops-area@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi - The AgentX mailing list administrator has a dilemma. Postings from list subscribers who are in the hotmail.com domain are being rejected by (at least) the world.std.com, parc.xerox.com, qualcomm.com, gmx.net, and pacbell.com domains. As you can imagine, this generates a fair amount of really annoying traffic for the list administrator. Should I 1) drop the subscribers whose domains are rejecting the agentx traffic 2) drop the hotmail.com subscribers whose submissions are getting rejected by networks I have no control over 3) do something else 4) do nothing (not too likely; I really don't have time to weed through this many bouncies) ----------------------------------------------------------------------- Randy Presuhn Email: rpresuhn@bmc.com http://www.bmc.com Voice: +1 408 616-3100 BMC Software, Inc. 965 Stewart Drive Fax: +1 408 616-3101 Sunnyvale, California 94086 USA ----------------------------------------------------------------------- In accordance with the BMC Communications Systems Use and Security Policy, I explicitly state that although my affiliation with BMC may be apparent, implied, or provided, my opinions are not necessarily those of BMC Software and that all external representations on behalf of BMC must first be cleared with a member of "the top management team." ----------------------------------------------------------------------- From bnatale@acecomm.com Tue Aug 4 13:04:48 1998 Delivery-Date: Tue, 04 Aug 1998 13:04:52 -0400 Return-Path: bnatale@acecomm.com Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id NAA12915 for ; Tue, 4 Aug 1998 13:04:48 -0400 (EDT) Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id NAA10702 for ; Tue, 4 Aug 1998 13:04:16 -0400 (EDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id MAA02969 for ; Tue, 4 Aug 1998 12:04:28 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma002820; Tue, 4 Aug 98 12:04:04 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id MAA15201 for ; Tue, 4 Aug 1998 12:03:28 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma014309; Tue, 4 Aug 98 12:02:45 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id MAA10036; Tue, 4 Aug 1998 12:02:28 -0500 (CDT) Received: from cashew.bmc.com (cashew.bmc.com [172.19.0.100]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id JAA14441; Tue, 4 Aug 1998 09:35:35 -0700 (PDT) Received: (from uucp@localhost) by cashew.bmc.com (8.8.8/8.8.8) id LAA19246; Tue, 4 Aug 1998 11:35:33 -0500 (CDT) Received: from relay4.smtp.psi.net(38.9.52.2) by cashew.bmc.com via smap (V2.0) id xma019205; Tue, 4 Aug 98 11:35:02 -0500 Received: from [192.152.208.5] (helo=acecomm.com) by relay4.smtp.psi.net with smtp (Exim 1.90 #1) id 0z3k2r-0001Gr-00; Tue, 4 Aug 1998 12:34:43 -0400 Received: from bnatale by acecomm.com (5.65/3.2.083191-ACE*COMM) id AA25552; Tue, 4 Aug 1998 12:36:26 -0400 Message-Id: <9808041636.AA25552@acecomm.com> X-Sender: natale@nips.acec.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1 Date: Tue, 04 Aug 1998 12:36:39 -0400 To: Randy Presuhn From: Bob Natale Subject: Re: Agentx list dilemma Cc: agentx@dorothy.bmc.com, ops-area@ietf.org In-Reply-To: <199808041453.HAA14013@dorothy.bmc.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" >At 8/4/98 07:53 AM, Randy Presuhn wrote: Hi Randy, >The AgentX mailing list administrator has a dilemma. Postings from >list subscribers who are in the hotmail.com domain are being rejected >by (at least) the world.std.com, parc.xerox.com, qualcomm.com, gmx.net, >and pacbell.com domains. I am personally familiar with this problem by virtue of performing the admin function for the WinSNMP list. It's not limited to hotmail.com...in general, some larger domains are rejecting mail from a growing number of (mostly "free") e-mail domains. I can only see this trend continuing to take hold at a rapid pace. >As you can imagine, this generates a fair amount of really annoying >traffic for the list administrator. Should I > 1) drop the subscribers whose domains are rejecting the agentx traffic > 2) drop the hotmail.com subscribers whose submissions are getting > rejected by networks I have no control over I opt for #2. I am very sorry about that because I understand that (1) some people need a free e-mail accoutn; (2) some people like (the illusion of) permanence it gives them (even thoough, ironically, it's the ephemerality of the accounts that make them so appealing to spammers!); (3) who knows where the blocking domains will draw the line on the practice (or fail to); (4) maybe the concept of the free/anonymous/universal mail domains/services will make sense in the long run. For now, however, I think the best policy is to require subscribers to have e-mail addresses that are not "routinely" blocked by domains which are known to otherwise employ "safe e-mail" practices. Granted, there would be some subjectivity in that, but any AgentX list admin (and you, in particular!) can be trusted with that judgment. > 3) do something else > 4) do nothing (not too likely; I really don't have time to weed > through this many bouncies) Right. In the end, you will have to do what is best for BMC in this matter. And that is as it should be. Cordially, BobN ------------ ISO 9001 Registered Quality Supplier ----------- Bob Natale | ACE*COMM | 301-721-3000 [v] Dir, Net Mgmt Prod | 704 Quince Orchard Rd | 301-721-3001 [f] bnatale@acecomm.com| Gaithersburg MD 20878 | www.acecomm.com ------------- Free downloads at www.winsnmp.com ------------- From Harald.Alvestrand@maxware.no Tue Aug 4 14:12:31 1998 Delivery-Date: Tue, 04 Aug 1998 14:12:37 -0400 Return-Path: Harald.Alvestrand@maxware.no Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id OAA14725 for ; Tue, 4 Aug 1998 14:12:31 -0400 (EDT) Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id OAA11096 for ; Tue, 4 Aug 1998 14:11:40 -0400 (EDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id NAA07991 for ; Tue, 4 Aug 1998 13:11:57 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma007613; Tue, 4 Aug 98 13:10:31 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id NAA17576 for ; Tue, 4 Aug 1998 13:09:55 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma015831; Tue, 4 Aug 98 13:08:20 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id NAA28734; Tue, 4 Aug 1998 13:08:22 -0500 (CDT) Received: from cashew.bmc.com (cashew.bmc.com [172.19.0.100]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id KAA15058; Tue, 4 Aug 1998 10:53:33 -0700 (PDT) Received: (from uucp@localhost) by cashew.bmc.com (8.8.8/8.8.8) id MAA23559; Tue, 4 Aug 1998 12:53:30 -0500 (CDT) Received: from dokka.maxware.no(195.139.236.69) by cashew.bmc.com via smap (V2.0) id xma023536; Tue, 4 Aug 98 12:53:20 -0500 Received: from alden (alvestrand.kvatro.no [193.216.167.143]) by dokka.maxware.no (8.8.5/8.8.5) with SMTP id TAA03319; Tue, 4 Aug 1998 19:48:50 +0200 Message-Id: <3.0.2.32.19980804182340.00afabb0@dokka.maxware.no> X-Sender: hta@dokka.maxware.no X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.2 (32) Date: Tue, 04 Aug 1998 18:23:40 +0200 To: Randy Presuhn , agentx@dorothy.bmc.com From: Harald Tveit Alvestrand Subject: Re: Agentx list dilemma Cc: ops-area@ietf.org In-Reply-To: <199808041453.HAA14013@dorothy.bmc.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" At 07:53 04.08.98 -0700, Randy Presuhn wrote: >Hi - > >The AgentX mailing list administrator has a dilemma. Postings from >list subscribers who are in the hotmail.com domain are being rejected >by (at least) the world.std.com, parc.xerox.com, qualcomm.com, gmx.net, >and pacbell.com domains. It might be a Good Thing to mail the postmasters at those domains and point out to them the little fact that most spam with hotmail in their headers (at least when I looked at it) had been nowhere near the REAL hotmail domain. I suspect some spammers have been thrown off hotmail and are taking a primitive kind of revenge...... >As you can imagine, this generates a fair amount of really annoying traffic >for the list administrator. Should I > 1) drop the subscribers whose domains are rejecting the agentx traffic > 2) drop the hotmail.com subscribers whose submissions are getting > rejected by networks I have no control over > 3) do something else > 4) do nothing (not too likely; I really don't have time to weed > through this many bouncies) there is no good solution. Offering to rewrite their FROM address as someone%hotmail.com@yourrelay is a patch, not a solution. Harald A -- Harald Tveit Alvestrand, Maxware, Norway Harald.Alvestrand@maxware.no From rpresuhn@dorothy.bmc.com Tue Aug 4 15:44:33 1998 Delivery-Date: Tue, 04 Aug 1998 15:44:33 -0400 Return-Path: rpresuhn@dorothy.bmc.com Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id PAA15926 for ; Tue, 4 Aug 1998 15:44:32 -0400 (EDT) Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id PAA11532 for ; Tue, 4 Aug 1998 15:44:12 -0400 (EDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id OAA14564 for ; Tue, 4 Aug 1998 14:44:30 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma014089; Tue, 4 Aug 98 14:42:59 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id OAA05329 for ; Tue, 4 Aug 1998 14:42:23 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma003676; Tue, 4 Aug 98 14:40:56 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id OAA21704; Tue, 4 Aug 1998 14:40:42 -0500 (CDT) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id MAA15917; Tue, 4 Aug 1998 12:25:53 -0700 (PDT) Date: Tue, 4 Aug 1998 12:25:53 -0700 (PDT) From: Randy Presuhn Message-Id: <199808041925.MAA15917@dorothy.bmc.com> To: agentx@dorothy.bmc.com Subject: Re: Agentx list dilemma Cc: ops-area@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi - Thanks everyone for the suggestions on what to do about mailing list subscribers whose domains bounce messages from hotmail.com subscribers to the agentx@peer.com distribution list. Having read everyone's advice, I'm going to do something completely different. :-) For now, all agentx mailing list bounce messages resulting from postings by hotmail.com subscribers will simply be discarded, with no action taken by the agentx list administrator. Subscribers from domains which are refusing the hotmail.com postings will have to use the working group FTP site at ftp://ftp.peer.com/pub/agentx/archives in order to see these postings. Those posting messages to the agentx list should come to expect these bounces, and should complain directly to the postmasters of the domains that are rejecting this legitimate mail. I reserve the right to change my mind and do something completely different in the future. ----------------------------------------------------------------------- Randy Presuhn Email: rpresuhn@bmc.com http://www.bmc.com Voice: +1 408 616-3100 BMC Software, Inc. 965 Stewart Drive Fax: +1 408 616-3101 Sunnyvale, California 94086 USA ----------------------------------------------------------------------- In accordance with the BMC Communications Systems Use and Security Policy, I explicitly state that although my affiliation with BMC may be apparent, implied, or provided, my opinions are not necessarily those of BMC Software and that all external representations on behalf of BMC must first be cleared with a member of "the top management team." ----------------------------------------------------------------------- From martin@exmandato.se Tue Aug 4 18:37:26 1998 Delivery-Date: Tue, 04 Aug 1998 18:37:26 -0400 Return-Path: martin@exmandato.se Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id SAA17845 for ; Tue, 4 Aug 1998 18:37:25 -0400 (EDT) Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id SAA12426 for ; Tue, 4 Aug 1998 18:37:04 -0400 (EDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id RAA24860 for ; Tue, 4 Aug 1998 17:37:23 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma024368; Tue, 4 Aug 98 17:36:11 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id RAA06399 for ; Tue, 4 Aug 1998 17:35:27 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma004590; Tue, 4 Aug 98 17:34:09 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id RAA05670; Tue, 4 Aug 1998 17:34:21 -0500 (CDT) Received: from almond.bmc.com (almond.bmc.com [172.17.0.100]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id PAA17122 for ; Tue, 4 Aug 1998 15:14:40 -0700 (PDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id RAA22830 for ; Tue, 4 Aug 1998 17:14:38 -0500 (CDT) Received: from oden.exmandato.se(192.71.33.1) by almond.bmc.com via smap (V2.0) id xma022802; Tue, 4 Aug 98 17:14:14 -0500 Received: from localhost (martin@localhost) by oden.exmandato.se (8.8.8/8.8.5) with SMTP id AAA25806; Wed, 5 Aug 1998 00:13:58 +0200 (MET DST) Date: Wed, 5 Aug 1998 00:13:58 +0200 (CEST) From: Martin Jacobsson To: Bob Natale cc: Smitha Gudur , agentx@peer.com Subject: Re: open issues in agentX MIB In-Reply-To: <9807312258.AA17629@acecomm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi Bob, On Fri, 31 Jul 1998, Bob Natale wrote: > Second, you are right, if state such purposes (and the > one you quote seems like a sound one to me). The approach > that I would like to propose for this purpose is to add > an agentxResponseTable. This would be indexed by > agentxSessionID and consist of a set of objects (with > syntax of GAUGE32, I suggest), one for each of the possible > AgentX-Response-PDU res.error codes (including no_error). > > Such a table would handle overall (by simple summing), > connection-specific (by mapping back to agentxConnectionTable > via the agentxConnIndex in the corresponding agentxSessionTable > row, and session-specific traffic and error counts for all > active sessions. This table will be big since there a lot of possible res.error values. First the 10 values in RFC2257 and then the 19 values in RFC1905. Most of these values are normal and don't indicate a problem, so this would be useless when debugging. I propose to add agentxSessionInPackets to the agentxSessionTable because this will show that there are activity on the session. Keeping track of the parse and protocol errors seems unnecessary because a master agent may choose to close the connection immediately without doing a recovery attempt when a parse/protocol error is found. But the number of timeouts is perhaps useful so you can find out if the timeout values are to small. But global counters of parse and protocol errors could be useful. Say my master agent closes the connection immediately if it recieves a bad packet. Then the subagent reconnect if the session is closed with a reason other than reasonShutdown or reasonByManager. A manager will not notice if this happens very often or not if there are no global counters of parse and protocol errors. (actually it can detect this beacuse the agentxConnIndex becomes very big, but this is, in my opinion, not a clear indication.) > >Then a port table would be nice, so that it is possible to see > >what ports the master agent accepts connections from > > I think this can be had now, via the agentxConnTransportDomain > and agentxConnTransportAddress objects in the agentxConnectionTable. > No...? No! It's the wrong end of the connection. agentxConnTransportAddress will contain the subagent's address, not the master agent's address. Then what happens if there are no subagents running or if there are no subagents using a opened port? Say all subagents use the unix domain socket and none use the tcp port. The tcp port would be missing. The table could be used to reveal configuration errors. For instance, you can see that the master agent listens to the tcp port when it shouldn't due to security reasons. /Martin Jacobsson --- .signature: No such file or directory From martin@exmandato.se Tue Aug 4 18:37:51 1998 Delivery-Date: Tue, 04 Aug 1998 18:37:51 -0400 Return-Path: martin@exmandato.se Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id SAA17858 for ; Tue, 4 Aug 1998 18:37:50 -0400 (EDT) Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id SAA12430 for ; Tue, 4 Aug 1998 18:37:30 -0400 (EDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id RAA25076 for ; Tue, 4 Aug 1998 17:37:49 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma024500; Tue, 4 Aug 98 17:36:26 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id RAA06922 for ; Tue, 4 Aug 1998 17:35:51 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma004755; Tue, 4 Aug 98 17:34:19 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id RAA05676; Tue, 4 Aug 1998 17:34:25 -0500 (CDT) Received: from cashew.bmc.com (cashew.bmc.com [172.19.0.100]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id PAA17142 for ; Tue, 4 Aug 1998 15:15:48 -0700 (PDT) Received: (from uucp@localhost) by cashew.bmc.com (8.8.8/8.8.8) id RAA08618 for ; Tue, 4 Aug 1998 17:15:47 -0500 (CDT) Received: from oden.exmandato.se(192.71.33.1) by cashew.bmc.com via smap (V2.0) id xma008589; Tue, 4 Aug 98 17:15:35 -0500 Received: from localhost (martin@localhost) by oden.exmandato.se (8.8.8/8.8.5) with SMTP id AAA25822; Wed, 5 Aug 1998 00:15:26 +0200 (MET DST) Date: Wed, 5 Aug 1998 00:15:26 +0200 (CEST) From: Martin Jacobsson To: Randy Presuhn cc: agentx@peer.com Subject: Re: open issues in agentX MIB In-Reply-To: <199807312343.QAA24395@dorothy.bmc.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Fri, 31 Jul 1998, Randy Presuhn wrote: > > >Section 2, goal 4 says: > > > > > >- Provide statistics about the protocol operation such > > >as the number of packets to and from each subagent > ... > > First, let me note that there is considerable sentiment to > > keep this MIB relatively minimal. > ... > > A counter-proposal to consider: delete goal 4 in section 2. Or change it to something like this: - Provide statistics about the protocol operation to help solving problems with subagents. /Martin Jacobsson --- .signature: No such file or directory From rpresuhn@dorothy.bmc.com Wed Aug 5 01:30:10 1998 Delivery-Date: Wed, 05 Aug 1998 01:30:10 -0400 Return-Path: rpresuhn@dorothy.bmc.com Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id BAA00198 for ; Wed, 5 Aug 1998 01:30:10 -0400 (EDT) Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id BAA13510 for ; Wed, 5 Aug 1998 01:29:49 -0400 (EDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id AAA10371 for ; Wed, 5 Aug 1998 00:30:08 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma009830; Wed, 5 Aug 98 00:28:36 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id AAA06044 for ; Wed, 5 Aug 1998 00:27:57 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma005254; Wed, 5 Aug 98 00:27:13 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id AAA21404; Wed, 5 Aug 1998 00:27:31 -0500 (CDT) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id WAA19883 for agentx@peer.com; Tue, 4 Aug 1998 22:03:04 -0700 (PDT) Date: Tue, 4 Aug 1998 22:03:04 -0700 (PDT) From: Randy Presuhn Message-Id: <199808050503.WAA19883@dorothy.bmc.com> To: agentx@peer.com Subject: Re: open issues in agentX MIB Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi - > Date: Wed, 5 Aug 1998 00:15:26 +0200 (CEST) > From: Martin Jacobsson > To: Randy Presuhn > cc: agentx@peer.com > Subject: Re: open issues in agentX MIB ... > Or change it to something like this: > > - Provide statistics about the protocol operation to help > solving problems with subagents. ... A question for implementors of AgentX's predecessor protocols (DPI, DPIv2, eSNMP, SMUX, c.): Did you find such MIB objects necessary or useful? A question for the bakeoff participants: Would such MIB objects have helped the bakeoff go smoother? My own experience (SMUX and several SMUX-like protocols) was that such objects were not necessary. Nice in some debugging situations perhaps, but not really the sort of thing one would use in a production configuration. If someone REALLY wanted to instrument the heck out of the agent/subagent dialogue, perhaps an Applmib applicability statement would be appropriate. ;-) ----------------------------------------------------------------------- Randy Presuhn Email: rpresuhn@bmc.com http://www.bmc.com Voice: +1 408 616-3100 BMC Software, Inc. 965 Stewart Drive Fax: +1 408 616-3101 Sunnyvale, California 94086 USA ----------------------------------------------------------------------- In accordance with the BMC Communications Systems Use and Security Policy, I explicitly state that although my affiliation with BMC may be apparent, implied, or provided, my opinions are not necessarily those of BMC Software and that all external representations on behalf of BMC must first be cleared with a member of "the top management team." ----------------------------------------------------------------------- From daniele@zk3.dec.com Wed Aug 5 09:49:14 1998 Delivery-Date: Wed, 05 Aug 1998 09:49:14 -0400 Return-Path: daniele@zk3.dec.com Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id JAA03811 for ; Wed, 5 Aug 1998 09:49:14 -0400 (EDT) Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id JAA14759 for ; Wed, 5 Aug 1998 09:49:14 -0400 (EDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id IAA28500 for ; Wed, 5 Aug 1998 08:49:09 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma027598; Wed, 5 Aug 98 08:46:47 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id IAA02473 for ; Wed, 5 Aug 1998 08:46:10 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma000203; Wed, 5 Aug 98 08:44:35 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id IAA20591; Wed, 5 Aug 1998 08:44:24 -0500 (CDT) Received: from cashew.bmc.com (cashew.bmc.com [172.19.0.100]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id GAA20982 for ; Wed, 5 Aug 1998 06:20:37 -0700 (PDT) Received: (from uucp@localhost) by cashew.bmc.com (8.8.8/8.8.8) id IAA07741 for ; Wed, 5 Aug 1998 08:20:35 -0500 (CDT) Received: from mail13.digital.com(192.208.46.30) by cashew.bmc.com via smap (V2.0) id xma007729; Wed, 5 Aug 98 08:20:24 -0500 Received: from quarry.zk3.dec.com (rock.zk3.dec.com [16.141.0.34]) by mail13.digital.com (8.8.8/8.8.8/WV1.0g) with SMTP id JAA07499; Wed, 5 Aug 1998 09:20:21 -0400 (EDT) Received: from bernie.zk3.dec.com by quarry.zk3.dec.com; (5.65v4.0/1.1.8.2/16Jan95-0946AM) id AA08039; Wed, 5 Aug 1998 09:20:21 -0400 Received: from localhost by bernie.zk3.dec.com; (5.65/1.1.8.2/22Aug96-1117AM) id AA22113; Wed, 5 Aug 1998 09:20:34 -0400 Message-Id: <9808051320.AA22113@bernie.zk3.dec.com> To: Randy Presuhn Cc: agentx@peer.com Subject: Re: open issues in agentX MIB In-Reply-To: Your message of "Tue, 04 Aug 98 22:03:04 PDT." <199808050503.WAA19883@dorothy.bmc.com> Date: Wed, 05 Aug 98 09:20:34 -0400 From: Mike Daniele X-Mts: smtp Hi, >A question for the bakeoff participants: >Would such MIB objects have helped the bakeoff go smoother? No. More detailed information (packet traces, printf-s :-) tend to be used in bakeoffs and debugging situations. One counter that seems like it would be useful in a production environment is a count of PDUs dispatched to each registered region (so would be in AgentXRegistrationEntry). This would give humans an easy way to verify how the master agent is dispatching, which could be very useful. Issue a few SNMP get/nexts for regions of interest, then go check what counters bumped. Mike From daniele@zk3.dec.com Wed Aug 5 09:51:03 1998 Delivery-Date: Wed, 05 Aug 1998 09:51:03 -0400 Return-Path: daniele@zk3.dec.com Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id JAA03879 for ; Wed, 5 Aug 1998 09:51:02 -0400 (EDT) Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id JAA14770 for ; Wed, 5 Aug 1998 09:51:03 -0400 (EDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id IAA29230 for ; Wed, 5 Aug 1998 08:51:03 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma028000; Wed, 5 Aug 98 08:47:55 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id IAA04095 for ; Wed, 5 Aug 1998 08:47:19 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma029819; Wed, 5 Aug 98 08:44:23 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id IAA20586; Wed, 5 Aug 1998 08:44:22 -0500 (CDT) Received: from almond.bmc.com (almond.bmc.com [172.17.0.100]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id GAA21015 for ; Wed, 5 Aug 1998 06:39:49 -0700 (PDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id IAA26234 for ; Wed, 5 Aug 1998 08:39:48 -0500 (CDT) Received: from mail11.digital.com(192.208.46.10) by almond.bmc.com via smap (V2.0) id xma026219; Wed, 5 Aug 98 08:39:22 -0500 Received: from quarry.zk3.dec.com (rock.zk3.dec.com [16.141.0.34]) by mail11.digital.com (8.8.8/8.8.8/WV1.0g) with SMTP id JAA05639 for ; Wed, 5 Aug 1998 09:39:21 -0400 (EDT) Received: from bernie.zk3.dec.com by quarry.zk3.dec.com; (5.65v4.0/1.1.8.2/16Jan95-0946AM) id AA14781; Wed, 5 Aug 1998 09:39:20 -0400 Received: from localhost by bernie.zk3.dec.com; (5.65/1.1.8.2/22Aug96-1117AM) id AA22125; Wed, 5 Aug 1998 09:39:30 -0400 Message-Id: <9808051339.AA22125@bernie.zk3.dec.com> To: agentx@peer.com Subject: agentxConnTransportAddress Date: Wed, 05 Aug 98 09:39:30 -0400 From: Mike Daniele X-Mts: smtp Hi, I want to point out that the value of this object is likely to be null for unix-domain sockets, since the subagent need not bind a filename to its local socket. Mike From daniele@zk3.dec.com Wed Aug 5 11:04:36 1998 Delivery-Date: Wed, 05 Aug 1998 11:04:37 -0400 Return-Path: daniele@zk3.dec.com Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id LAA07072 for ; Wed, 5 Aug 1998 11:04:36 -0400 (EDT) Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id LAA15312 for ; Wed, 5 Aug 1998 11:04:37 -0400 (EDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id KAA07739 for ; Wed, 5 Aug 1998 10:04:24 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma006224; Wed, 5 Aug 98 10:00:05 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id JAA18868 for ; Wed, 5 Aug 1998 09:59:22 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma014877; Wed, 5 Aug 98 09:56:15 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id JAA12879; Wed, 5 Aug 1998 09:56:04 -0500 (CDT) Received: from cashew.bmc.com (cashew.bmc.com [172.19.0.100]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id HAA21149 for ; Wed, 5 Aug 1998 07:49:36 -0700 (PDT) Received: (from uucp@localhost) by cashew.bmc.com (8.8.8/8.8.8) id JAA13371 for ; Wed, 5 Aug 1998 09:49:34 -0500 (CDT) Received: from mail11.digital.com(192.208.46.10) by cashew.bmc.com via smap (V2.0) id xma013358; Wed, 5 Aug 98 09:49:24 -0500 Received: from quarry.zk3.dec.com (rock.zk3.dec.com [16.141.0.34]) by mail11.digital.com (8.8.8/8.8.8/WV1.0g) with SMTP id KAA13746 for ; Wed, 5 Aug 1998 10:48:08 -0400 (EDT) Received: from bernie.zk3.dec.com by quarry.zk3.dec.com; (5.65v4.0/1.1.8.2/16Jan95-0946AM) id AA20806; Wed, 5 Aug 1998 10:48:08 -0400 Received: from localhost by bernie.zk3.dec.com; (5.65/1.1.8.2/22Aug96-1117AM) id AA22170; Wed, 5 Aug 1998 10:48:22 -0400 Message-Id: <9808051448.AA22170@bernie.zk3.dec.com> To: agentx@peer.com Subject: Re: Table Indices in AgentX MIB In-Reply-To: Your message of "Tue, 04 Aug 98 10:08:12 +0200." <199808040808.KAA11389@henkell.ibr.cs.tu-bs.de> Date: Wed, 05 Aug 98 10:48:21 -0400 From: Mike Daniele X-Mts: smtp >: There is a 1:n relationship between 1) and 2) and another 1:n >: relationship between 2) and 3). Further, every session is bound to a >: single connection and every registration is bound to a single >: session. This means that the relationships between the tables can be >: modeled by the indexing structure (a): I agree. It seems to me where there is such a natural containment hierarchy, the MIB's indexing should reflect it. It seems like better design to me. >So, where are the benefits of b)? Is it that your getnext function is >slightly more complex? This really depends on the data structures you >use. In some cases, option a) might even be simpler to implement. Agreed. >I still believe that the hidden costs of choosing b) can in the long >term cause us serious problems (and therefore costs) and we should be >very carefull to not make the wrong decision here. We don't know what configurations will happen in the future. So it seems to me that if we can provide the ability to directly lookup all As in B, or all Bs in C, at virtually no cost to agent implementors, we should do so. Mike From daniele@zk3.dec.com Wed Aug 5 11:04:42 1998 Delivery-Date: Wed, 05 Aug 1998 11:04:42 -0400 Return-Path: daniele@zk3.dec.com Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id LAA07077 for ; Wed, 5 Aug 1998 11:04:41 -0400 (EDT) Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id LAA15311 for ; Wed, 5 Aug 1998 11:04:27 -0400 (EDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id KAA07666 for ; Wed, 5 Aug 1998 10:04:14 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma006126; Wed, 5 Aug 98 09:59:54 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id JAA18704 for ; Wed, 5 Aug 1998 09:59:14 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma014815; Wed, 5 Aug 98 09:56:11 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id JAA12869; Wed, 5 Aug 1998 09:56:03 -0500 (CDT) Received: from cashew.bmc.com (cashew.bmc.com [172.19.0.100]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id HAA21136 for ; Wed, 5 Aug 1998 07:41:57 -0700 (PDT) Received: (from uucp@localhost) by cashew.bmc.com (8.8.8/8.8.8) id JAA12877 for ; Wed, 5 Aug 1998 09:41:55 -0500 (CDT) Received: from mail11.digital.com(192.208.46.10) by cashew.bmc.com via smap (V2.0) id xma012851; Wed, 5 Aug 98 09:41:37 -0500 Received: from quarry.zk3.dec.com (rock.zk3.dec.com [16.141.0.34]) by mail11.digital.com (8.8.8/8.8.8/WV1.0g) with SMTP id KAA17712 for ; Wed, 5 Aug 1998 10:41:36 -0400 (EDT) Received: from bernie.zk3.dec.com by quarry.zk3.dec.com; (5.65v4.0/1.1.8.2/16Jan95-0946AM) id AA15462; Wed, 5 Aug 1998 10:41:35 -0400 Received: from localhost by bernie.zk3.dec.com; (5.65/1.1.8.2/22Aug96-1117AM) id AA22180; Wed, 5 Aug 1998 10:41:46 -0400 Message-Id: <9808051441.AA22180@bernie.zk3.dec.com> To: agentx@peer.com Subject: some comments on MIB Date: Wed, 05 Aug 98 10:41:45 -0400 From: Mike Daniele X-Mts: smtp Hi, 1) Under agentxSessionObjectID is >-- >-- Issue: should we describe this more in terms of AGENT-CAPABILITIES >-- or sysORTable? >-- This should be removed, since this oid has no relation to agent capabilities. 2) I thought there was agreement last year to remove agentxConnNumber and agentxConnSessions? 3) agentxRegStart and agentxRegEnd There was a lot of discussion on these (see archives for Dec 97). I want to make sure we all agree on what goes into these objects. since agentxRegEnd is described as "up to but not including", I assume the following: received r.region agentxRegStart agentxRegEnd ----------------- -------------- ------------ a.b.c a.b.c a.b.c+1 a.b.c.[d-e] a.b.c.d a.b.c.e+1 a.b.c.[d-e].f a.b.c.d.f a.b.c.e.f+1 I think a table such as this in the MIB would be helpful (once we agree on what to use for values :-) 4) agentxRegPriority I think the DEFVAL will end up being 128, if we agree on that for 2257. (David Battle's mail about making the default such that one can always get "in front of" or "behind" it.) 5) agentxRegisterDuplicate Is this really useful? If we're going to keep it, wouldn't it be better to make this counter part of agentxRegistrationEntry? At least then you'd know which registered region was encountering duplicate registrations. Thanks, Mike From bnatale@acecomm.com Wed Aug 5 12:07:32 1998 Delivery-Date: Wed, 05 Aug 1998 12:07:33 -0400 Return-Path: bnatale@acecomm.com Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id MAA09633 for ; Wed, 5 Aug 1998 12:07:32 -0400 (EDT) Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id MAA15647 for ; Wed, 5 Aug 1998 12:07:33 -0400 (EDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id LAA14855 for ; Wed, 5 Aug 1998 11:07:32 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma014380; Wed, 5 Aug 98 11:06:15 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id LAA27709 for ; Wed, 5 Aug 1998 11:05:39 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma026555; Wed, 5 Aug 98 11:04:42 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id LAA02619; Wed, 5 Aug 1998 11:04:30 -0500 (CDT) Received: from almond.bmc.com (almond.bmc.com [172.17.0.100]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id IAA21223 for ; Wed, 5 Aug 1998 08:24:24 -0700 (PDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id KAA09452 for ; Wed, 5 Aug 1998 10:24:23 -0500 (CDT) Received: from relay3.smtp.psi.net(38.8.210.2) by almond.bmc.com via smap (V2.0) id xma009435; Wed, 5 Aug 98 10:23:56 -0500 Received: from [192.152.208.5] (helo=acecomm.com) by relay3.smtp.psi.net with smtp (Exim 1.90 #1) id 0z45Pg-0004a8-00; Wed, 5 Aug 1998 11:23:42 -0400 Received: from bnatale by acecomm.com (5.65/3.2.083191-ACE*COMM) id AA00986; Wed, 5 Aug 1998 11:26:13 -0400 Message-Id: <9808051526.AA00986@acecomm.com> X-Sender: natale@nips.acec.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1 Date: Wed, 05 Aug 1998 11:25:56 -0400 To: Mike Daniele From: Bob Natale Subject: Re: some comments on [AgentX] MIB Cc: agentx@peer.com In-Reply-To: <9808051441.AA22180@bernie.zk3.dec.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" >At 8/5/98 10:41 AM, Mike Daniele wrote: Hi Mike, >1) Under agentxSessionObjectID is > >>-- >>-- Issue: should we describe this more in terms of AGENT-CAPABILITIES >>-- or sysORTable? >>-- > >This should be removed, since this oid has no relation to >agent capabilities. Right...the comment should be removed. >2) I thought there was agreement last year to remove >agentxConnNumber and agentxConnSessions? If not, now's as good a time to agree to remove them... does anyone object. (Note that there no corresponding object for number of entries in the registration table anyway.) >3) agentxRegStart and agentxRegEnd > >There was a lot of discussion on these (see archives for Dec 97). >I want to make sure we all agree on what goes into these objects. > >since agentxRegEnd is described as "up to but not including", >I assume the following: > >received r.region agentxRegStart agentxRegEnd >----------------- -------------- ------------ >a.b.c a.b.c a.b.c+1 >a.b.c.[d-e] a.b.c.d a.b.c.e+1 >a.b.c.[d-e].f a.b.c.d.f a.b.c.e.f+1 > >I think a table such as this in the MIB would be helpful >(once we agree on what to use for values :-) That's the way we implemented it. And, yes, I guess the last subid in an agentxRegStart object could conceivably have the max UINT32 value, presenting an anomaly wrt the "+1" operation. Not worth worrying about, it seems. >4) agentxRegPriority > >I think the DEFVAL will end up being 128, if we agree on that >for 2257. (David Battle's mail about making the default such >that one can always get "in front of" or "behind" it.) Good idea (David)! >5) agentxRegisterDuplicate > >Is this really useful? If we're going to keep it, wouldn't >it be better to make this counter part of agentxRegistrationEntry? >At least then you'd know which registered region was encountering >duplicate registrations. I personally think a count of each error state is useful. I think isolating it to the subagent session involved is sufficient for this MIB. I realize that this is a topic of disagreement already in one or more other threads on this general matter. I will do a summary posting of my position/rationale later today and try to accept whatever the outcome of that is w/o dragging this one much further. (I've been doing some research and trying to formulate the rationale concisely and convincingly.) But you are certainly right in that, as it stands in the 980414 AgentX MIB, this object is somewhat peculiar at best. Cordially, BobN ------------ ISO 9001 Registered Quality Supplier ----------- Bob Natale | ACE*COMM | 301-721-3000 [v] Dir, Net Mgmt Prod | 704 Quince Orchard Rd | 301-721-3001 [f] bnatale@acecomm.com| Gaithersburg MD 20878 | www.acecomm.com ------------- Free downloads at www.winsnmp.com ------------- From bnatale@acecomm.com Wed Aug 5 13:17:00 1998 Delivery-Date: Wed, 05 Aug 1998 13:17:01 -0400 Return-Path: bnatale@acecomm.com Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id NAA12346 for ; Wed, 5 Aug 1998 13:17:00 -0400 (EDT) Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id NAA16115 for ; Wed, 5 Aug 1998 13:16:58 -0400 (EDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id MAA21325 for ; Wed, 5 Aug 1998 12:16:53 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma020715; Wed, 5 Aug 98 12:15:12 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id MAA03641 for ; Wed, 5 Aug 1998 12:14:35 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma002071; Wed, 5 Aug 98 12:13:20 -0500 Received: from dorothy.bmc.com (dorothy.peer.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id MAA21928; Wed, 5 Aug 1998 12:13:18 -0500 (CDT) Received: from cashew.bmc.com (cashew.bmc.com [172.19.0.100]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id JAA21571 for ; Wed, 5 Aug 1998 09:53:39 -0700 (PDT) Received: (from uucp@localhost) by cashew.bmc.com (8.8.8/8.8.8) id LAA22009 for ; Wed, 5 Aug 1998 11:53:32 -0500 (CDT) Received: from relay3.smtp.psi.net(38.8.210.2) by cashew.bmc.com via smap (V2.0) id xma021981; Wed, 5 Aug 98 11:52:59 -0500 Received: from [192.152.208.5] (helo=acecomm.com) by relay3.smtp.psi.net with smtp (Exim 1.90 #1) id 0z46o1-0007iz-00; Wed, 5 Aug 1998 12:52:53 -0400 Received: from bnatale by acecomm.com (5.65/3.2.083191-ACE*COMM) id AA02660; Wed, 5 Aug 1998 12:55:40 -0400 Message-Id: <9808051655.AA02660@acecomm.com> X-Sender: natale@nips.acec.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1 Date: Wed, 05 Aug 1998 12:55:24 -0400 To: Mike Daniele From: Bob Natale Subject: Re: Table Indices in AgentX MIB Cc: agentx@peer.com In-Reply-To: <9808051448.AA22170@bernie.zk3.dec.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" >At 8/5/98 10:48 AM, Mike Daniele wrote: Hi Mike, I will use your posting to try to present my thinking on this and, thereby, also answer the comments from Juergen and Martin. This gets a bit "didactic" in spots...forgive me...it's not a deliberate effort to be pompous or anything...just trying to explain some thinking. It's intended as much as a learning experience for me as anything else. If the exposition proves either fatally flawed or unpersuasive, I'll drop my pitch on the indexing of tables in the AgentX MIB. (As always, I use an awful lot of words to say what others could express in many fewer...I am sorry for that.) >>There is a 1:n relationship between 1) and 2) and another 1:n >>relationship between 2) and 3). Further, every session is bound >>to a single connection and every registration is bound to a >>single session. This means that the relationships between the >>tables can be modeled by the indexing structure (a): "Can be" and "should be" are two different things. As engineers, we often gravitate toward the "can be" irrespective of the "should be?" considerations. >I agree. It seems to me where there is such a natural containment >hierarchy, the MIB's indexing should reflect it. It seems like >better design to me. I do not agree with that conclusion. Such a "natural containment hierarchy" may be taken as one data point in such a design decision, but it alone is not sufficient to make such a decision. What constitutes a "better design" for a MIB is whatever serves to maximize the result of some complex value function dealing with the full range of operations that will be useful to existing, conceived, or even as yet unimagined, management applications while at the same time keeping the corresponding impact on the managed element as minimal as possible. No one is saying that one can usually/often/(maybe even)ever know that one has come up with the absolute best result ahead of time. >>So, where are the benefits of b)? Is it that your getnext >>function is slightly more complex? It would be slightly less complex...but, no, that is not the main benefit...the main benefit would come from not imposing a pre-defined set of constraints on all management applications. >>This really depends on the data structures you use. True in either case. >In some cases, option a) might even be simpler to implement. True (without signifying anything, one way or the other). >Agreed. Not much was said there to agree with (not a cut, Juergen)... we all know that a good implementation might be able to turn a bad design into a workable solution and a bad implementation might be able to muck up a good design. That will always be true (I fear), no matter what design decisions are made. What we (as a community) need is more specific guidance on MIB design decisions. Given the amount of time that we (the SNMP community) have been doing MIBs, we ought to be close to the level of demonstrated wisdom of, say, normalization rules for relational databases. I have looked at some of the latest sources available that might offer such guidance... I have found some, but it seems to be widely scattered and not totally consistent. >>I still believe that the hidden costs of choosing b) can in >>the long term cause us serious problems (and therefore costs) >>and we should be very carefull to not make the wrong decision >>here. Again, the exact same statement could be made if "b)" were replaced with "a)" and it would be exactly as true (or false). There is no basis for decision there. In general, however, it can be assured--given our stated objectives for this MIB from the beginning--that even the worst design decision we could possibly make would not lead to truly "serious problems". I am not arguing for consciously making the wrong decisions, obviously...just recalling that the purpose and scope of this MIB are intentionally quite limited. That fact plays a role in my rationale (below). >We don't know what configurations will happen in the future. *That*, Mike, is a *key* design guideline in this case, IMO. >So it seems to me that if we can provide the ability to directly >lookup all As in B, or all Bs in C, at virtually no cost to >agent implementors, we should do so. That seems like an incongruous deduction from your previous statement to me, Mike. If one does not know what configurations might make sense in the future, one perhaps should *avoid* leveraging the "natural containment hierarchy" of the moment. Such "leveraging" serves the needs of only a small number of obvious queries--esp., what sessions belong to this connection; what registrations belong to this session; and what registrations belong to this connection. Other potential queries on the session and registration tables may be constrained by need for multiple index values when a single (unique) row identifier exists and/or by the NOT-ACCESSIBLE MAX-ACCESS nature of these indices. Anyway, here's how I break out the general case: 1. If a table has a unique-valued columnar object suitable for use as an index, using other/additional objects as indices into this table requires special justification. 2. A justification based on "natural containment hierarchy" is not prima facie sufficient, unless it can be shown that: a. Queries which depend on such "containment" will dominate management operations; and/or b. the cost of not having such "containment" when performing the queries in 2a would have a significantly negative impact on the managed element. Applied specifically to AgentX, 2a is not known to apply and 2b is known not to apply (since all tables will be "small" in any reasonable meaning of that vague term). 3. The original SNMP philosophy of not encasing "meta-" and "pseudo-" data within an agent is still valid as a starting point in MIB design...the identified "containment hierarchy" is an example of such meta or pseudo data...(I agree that today there are a growing number of manageable elements that can support agents that go beyond the original SNMP agent role philosophy...there is no need for the AgentX MIB to do so, however). >From that, I draw the conclusion that the indexing design in the original version of the MIB (single, unique index per table) is preferable to that in the current version ("grouping" indexes added to the single unique index in the session and registration tables...and presumably to any other similar tables we might want to include future revs of the MIB). Leveraging the "natural containment hierarchy" as represented via the multi-indexing in the current version, IMVHO, adds some complexity and overhead to (virtually) all potential management operations against this MIB (including the many that might not care about the "containment hierarchy" but benefits only a small number of known queries that will not be made all that frequently and would not incur exorbitant costs to satisfy in the absence of the multiple indexes. Well, is anyone persuaded? :-) Cordially, BobN ------------ ISO 9001 Registered Quality Supplier ----------- Bob Natale | ACE*COMM | 301-721-3000 [v] Dir, Net Mgmt Prod | 704 Quince Orchard Rd | 301-721-3001 [f] bnatale@acecomm.com| Gaithersburg MD 20878 | www.acecomm.com ------------- Free downloads at www.winsnmp.com -------------