From ashishkh@wipinfo.soft.net Sun Aug 2 04:22:33 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id EAA10547 for ; Sun, 2 Aug 1998 04:22:33 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id EAA03480 for ; Sun, 2 Aug 1998 04:21:18 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma002890; Sun, 2 Aug 98 04:19:12 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id EAA18395 for ; Sun, 2 Aug 1998 04:17:57 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma017993; Sun, 2 Aug 98 04:17: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 EAA07592; Sun, 2 Aug 1998 04:17: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 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 10:58:57 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id KAA23902 for ; Mon, 3 Aug 1998 10:58:56 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id KAA06934 for ; Mon, 3 Aug 1998 10:57:36 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma006433; Mon, 3 Aug 98 10:55:42 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id KAA00219 for ; Mon, 3 Aug 1998 10:55:06 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma028032; Mon, 3 Aug 98 10:53:14 -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 KAA14108; Mon, 3 Aug 1998 10:53:38 -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 12:22:49 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id MAA24536 for ; Mon, 3 Aug 1998 12:22:45 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id MAA13463 for ; Mon, 3 Aug 1998 12:21:24 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma013225; Mon, 3 Aug 98 12:20:19 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id MAA10943 for ; Mon, 3 Aug 1998 12:19:43 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma006904; Mon, 3 Aug 98 12:15: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 MAA06374; Mon, 3 Aug 1998 12:16: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 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 12:26:02 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id MAA24566 for ; Mon, 3 Aug 1998 12:26:01 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id MAA14390 for ; Mon, 3 Aug 1998 12:24:42 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma013991; Mon, 3 Aug 98 12:23:15 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id MAA13978 for ; Mon, 3 Aug 1998 12:22:39 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma006905; Mon, 3 Aug 98 12:15: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 MAA06375; Mon, 3 Aug 1998 12:16:01 -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 12:42:47 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id MAA24695 for ; Mon, 3 Aug 1998 12:42:46 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id MAA16589 for ; Mon, 3 Aug 1998 12:41:25 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma016481; Mon, 3 Aug 98 12:40:49 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id MAA28944 for ; Mon, 3 Aug 1998 12:40:09 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma027539; Mon, 3 Aug 98 12:38: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 MAA11898; Mon, 3 Aug 1998 12:38: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 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 daniele@zk3.dec.com Mon Aug 3 13:47:08 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id NAA25183 for ; Mon, 3 Aug 1998 13:47:06 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id NAA23498 for ; Mon, 3 Aug 1998 13:45:41 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma023252; Mon, 3 Aug 98 13:44:33 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id NAA27224 for ; Mon, 3 Aug 1998 13:43:50 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma020691; Mon, 3 Aug 98 13:36: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 NAA26973; Mon, 3 Aug 1998 13:37:00 -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 bnatale@acecomm.com Mon Aug 3 13:52:04 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id NAA25224 for ; Mon, 3 Aug 1998 13:52:03 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id NAA24622 for ; Mon, 3 Aug 1998 13:50:42 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma024338; Mon, 3 Aug 98 13:49:21 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id NAA02012 for ; Mon, 3 Aug 1998 13:48:43 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma020913; Mon, 3 Aug 98 13:36: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 NAA27022; Mon, 3 Aug 1998 13:37: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 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 mithatch@cisco.com Mon Aug 3 13:52:18 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id NAA25228 for ; Mon, 3 Aug 1998 13:52:15 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id NAA24683 for ; Mon, 3 Aug 1998 13:50:53 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma024396; Mon, 3 Aug 98 13:49:42 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id NAA02231 for ; Mon, 3 Aug 1998 13:48:55 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma020733; Mon, 3 Aug 98 13:36: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 NAA26988; Mon, 3 Aug 1998 13:37: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 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 14:04:14 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id OAA25335 for ; Mon, 3 Aug 1998 14:04:13 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id OAA27223 for ; Mon, 3 Aug 1998 14:02:51 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma026868; Mon, 3 Aug 98 14:01:10 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id OAA13355 for ; Mon, 3 Aug 1998 14:00:26 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma000404; Mon, 3 Aug 98 13:47: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 NAA29827; Mon, 3 Aug 1998 13:47:14 -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 14:23:00 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id OAA25478 for ; Mon, 3 Aug 1998 14:22:58 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id OAA01529 for ; Mon, 3 Aug 1998 14:21:39 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma001112; Mon, 3 Aug 98 14:19:53 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id OAA00553 for ; Mon, 3 Aug 1998 14:19:10 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma008805; Mon, 3 Aug 98 13:55: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 NAA02320; Mon, 3 Aug 1998 13:55:49 -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 bnatale@acecomm.com Mon Aug 3 14:23:20 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id OAA25489 for ; Mon, 3 Aug 1998 14:23:19 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id OAA01646 for ; Mon, 3 Aug 1998 14:22:00 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma001266; Mon, 3 Aug 98 14:20:21 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id OAA01084 for ; Mon, 3 Aug 1998 14:19:37 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma008712; Mon, 3 Aug 98 13:55: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 NAA02298; Mon, 3 Aug 1998 13:55:46 -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 14:25:48 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id OAA25506 for ; Mon, 3 Aug 1998 14:25:45 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id OAA02319 for ; Mon, 3 Aug 1998 14:24:21 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma001903; Mon, 3 Aug 98 14:22:49 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id OAA03256 for ; Mon, 3 Aug 1998 14:22:09 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma011924; Mon, 3 Aug 98 13:58: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 NAA03067; Mon, 3 Aug 1998 13:59:02 -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 battle@snmp.com Mon Aug 3 14:43:02 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id OAA25640 for ; Mon, 3 Aug 1998 14:43:01 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id OAA06214 for ; Mon, 3 Aug 1998 14:41:34 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma006082; Mon, 3 Aug 98 14:40:54 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id OAA20502 for ; Mon, 3 Aug 1998 14:40:11 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma017419; Mon, 3 Aug 98 14:37: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 OAA13326; Mon, 3 Aug 1998 14:37: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 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 14:59:28 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id OAA25763 for ; Mon, 3 Aug 1998 14:59:27 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id OAA09165 for ; Mon, 3 Aug 1998 14:58:02 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma008820; Mon, 3 Aug 98 14:56:39 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id OAA05462 for ; Mon, 3 Aug 1998 14:55:51 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma001292; Mon, 3 Aug 98 14:51: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 OAA17117; Mon, 3 Aug 1998 14:52: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 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 15:34:00 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id PAA26026 for ; Mon, 3 Aug 1998 15:33:59 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id PAA13004 for ; Mon, 3 Aug 1998 15:32:39 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma012740; Mon, 3 Aug 98 15:31:29 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id PAA07180 for ; Mon, 3 Aug 1998 15:30:44 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma004522; Mon, 3 Aug 98 15:28: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 PAA27160; Mon, 3 Aug 1998 15:28: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 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 15:59:44 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id PAA26220 for ; Mon, 3 Aug 1998 15:59:43 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id PAA16426 for ; Mon, 3 Aug 1998 15:58:21 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma016213; Mon, 3 Aug 98 15:57:16 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id PAA00142 for ; Mon, 3 Aug 1998 15:56:30 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma024632; Mon, 3 Aug 98 15:50: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 PAA03485; Mon, 3 Aug 1998 15:50: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 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 15:59:52 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id PAA26226 for ; Mon, 3 Aug 1998 15:59:50 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id PAA16486 for ; Mon, 3 Aug 1998 15:58:31 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma016250; Mon, 3 Aug 98 15:57:24 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id PAA00241 for ; Mon, 3 Aug 1998 15:56:44 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma025698; Mon, 3 Aug 98 15:52: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 PAA03742; Mon, 3 Aug 1998 15:52:00 -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 16:22:51 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id QAA26412 for ; Mon, 3 Aug 1998 16:22:50 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id QAA20428 for ; Mon, 3 Aug 1998 16:21:31 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma019920; Mon, 3 Aug 98 16:19:43 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id QAA20170 for ; Mon, 3 Aug 1998 16:19:06 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma019014; Mon, 3 Aug 98 16:17: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 QAA10236; Mon, 3 Aug 1998 16:17:39 -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 16:53:02 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id QAA26647 for ; Mon, 3 Aug 1998 16:53:02 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id QAA23424 for ; Mon, 3 Aug 1998 16:51:41 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma023059; Mon, 3 Aug 98 16:50:31 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id QAA19118 for ; Mon, 3 Aug 1998 16:49:50 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma014923; Mon, 3 Aug 98 16:45: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 QAA17785; Mon, 3 Aug 1998 16:45: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 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 16:57:54 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id QAA26685 for ; Mon, 3 Aug 1998 16:57:52 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id QAA24508 for ; Mon, 3 Aug 1998 16:56:32 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma024111; Mon, 3 Aug 98 16:55:05 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id QAA23282 for ; Mon, 3 Aug 1998 16:54:29 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma019343; Mon, 3 Aug 98 16:50: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 QAA19139; Mon, 3 Aug 1998 16:50:14 -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 17:03:44 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id RAA26742 for ; Mon, 3 Aug 1998 17:03:43 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id RAA25878 for ; Mon, 3 Aug 1998 17:02:23 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma025553; Mon, 3 Aug 98 17:01:03 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id RAA28962 for ; Mon, 3 Aug 1998 17:00:25 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma026617; Mon, 3 Aug 98 16:57: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 QAA21523; Mon, 3 Aug 1998 16:58:13 -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 17:29:50 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id RAA26938 for ; Mon, 3 Aug 1998 17:29:49 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id RAA29432 for ; Mon, 3 Aug 1998 17:28:30 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma028879; Mon, 3 Aug 98 17:26:27 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id RAA20581 for ; Mon, 3 Aug 1998 17:25:50 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma019544; Mon, 3 Aug 98 17:24: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 RAA29084; Mon, 3 Aug 1998 17:25:27 -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 bnatale@acecomm.com Mon Aug 3 17:39:28 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id RAA27013 for ; Mon, 3 Aug 1998 17:39:28 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id RAA02192 for ; Mon, 3 Aug 1998 17:38:10 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma001170; Mon, 3 Aug 98 17:35:16 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id RAA29106 for ; Mon, 3 Aug 1998 17:34:39 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma027252; Mon, 3 Aug 98 17:32: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 RAA00919; Mon, 3 Aug 1998 17:33:24 -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 sgudur@hotmail.com Mon Aug 3 17:39:57 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id RAA27020 for ; Mon, 3 Aug 1998 17:39:56 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id RAA02288 for ; Mon, 3 Aug 1998 17:38:30 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma001439; Mon, 3 Aug 98 17:35:55 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id RAA29672 for ; Mon, 3 Aug 1998 17:35:19 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma026870; Mon, 3 Aug 98 17:32: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 RAA00846; Mon, 3 Aug 1998 17:33:00 -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 rpresuhn@dorothy.bmc.com Mon Aug 3 18:15:54 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id SAA27308 for ; Mon, 3 Aug 1998 18:15:53 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id SAA05766 for ; Mon, 3 Aug 1998 18:14:36 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma005167; Mon, 3 Aug 98 18:12:36 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id SAA20711 for ; Mon, 3 Aug 1998 18:11:58 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma019508; Mon, 3 Aug 98 18:10: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 SAA09575; Mon, 3 Aug 1998 18:11:08 -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 19:15:46 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id TAA27757 for ; Mon, 3 Aug 1998 19:15:46 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id TAA09063 for ; Mon, 3 Aug 1998 19:14:29 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma008496; Mon, 3 Aug 98 19:12:48 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id TAA12441 for ; Mon, 3 Aug 1998 19:12:11 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma011709; Mon, 3 Aug 98 19:11: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 TAA22323; Mon, 3 Aug 1998 19:12:00 -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 19:52:29 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id TAA28029 for ; Mon, 3 Aug 1998 19:52:29 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id TAA11675 for ; Mon, 3 Aug 1998 19:51:11 -0500 (CDT) Received: from dresden.bmc.com(198.64.253.250) by almond.bmc.com via smap (V2.0) id xma010966; Mon, 3 Aug 98 19:48:42 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id TAA22777 for ; Mon, 3 Aug 1998 19:47:59 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma021810; Mon, 3 Aug 98 19:47: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 TAA28941; Mon, 3 Aug 1998 19:47:47 -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 20:06:10 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id UAA28138 for ; Mon, 3 Aug 1998 20:06:08 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id UAA13423 for ; Mon, 3 Aug 1998 20:04:49 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma012929; Mon, 3 Aug 98 20:03:18 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id UAA28783 for ; Mon, 3 Aug 1998 20:02:41 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma028240; Mon, 3 Aug 98 20:02: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 UAA02138; Mon, 3 Aug 1998 20:02:34 -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 Mon Aug 3 23:24:27 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id XAA29698 for ; Mon, 3 Aug 1998 23:24:26 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id XAA21495 for ; Mon, 3 Aug 1998 23:23:06 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma020634; Mon, 3 Aug 98 23:20:31 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id XAA01395 for ; Mon, 3 Aug 1998 23:19:52 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma000712; Mon, 3 Aug 98 23:18: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 XAA04625; Mon, 3 Aug 1998 23:19:32 -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 00:27:52 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id AAA00176 for ; Tue, 4 Aug 1998 00:27:52 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id AAA24565 for ; Tue, 4 Aug 1998 00:26:33 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma023797; Tue, 4 Aug 98 00:24:24 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id AAA16349 for ; Tue, 4 Aug 1998 00:23:48 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma015769; Tue, 4 Aug 98 00:22: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 AAA15204; Tue, 4 Aug 1998 00:23:31 -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 00:33:08 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id AAA00225 for ; Tue, 4 Aug 1998 00:33:07 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id AAA26065 for ; Tue, 4 Aug 1998 00:31:49 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma025304; Tue, 4 Aug 98 00:29:27 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id AAA18654 for ; Tue, 4 Aug 1998 00:28:48 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma017936; Tue, 4 Aug 98 00:28: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 AAA16082; Tue, 4 Aug 1998 00:28:43 -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 03:11:17 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id DAA01428 for ; Tue, 4 Aug 1998 03:11:17 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id DAA02460 for ; Tue, 4 Aug 1998 03:09:58 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma002043; Tue, 4 Aug 98 03:08:47 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id DAA24291 for ; Tue, 4 Aug 1998 03:07:53 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma023840; Tue, 4 Aug 98 03:07: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 DAA11528; Tue, 4 Aug 1998 03:07: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 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 03:22:57 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id DAA01518 for ; Tue, 4 Aug 1998 03:22:57 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id DAA04311 for ; Tue, 4 Aug 1998 03:21:38 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma003484; Tue, 4 Aug 98 03:18:58 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id DAA28248 for ; Tue, 4 Aug 1998 03:18:16 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma027264; Tue, 4 Aug 98 03:17: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 DAA13272; Tue, 4 Aug 1998 03:18:07 -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 09:08:33 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id JAA04110 for ; Tue, 4 Aug 1998 09:08:32 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id JAA18609 for ; Tue, 4 Aug 1998 09:07:13 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma018354; Tue, 4 Aug 98 09:06:14 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id JAA06597 for ; Tue, 4 Aug 1998 09:05:38 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma005168; Tue, 4 Aug 98 09:04: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 JAA17243; Tue, 4 Aug 1998 09:04:36 -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 10:46:12 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id KAA04843 for ; Tue, 4 Aug 1998 10:46:11 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id KAA27648 for ; Tue, 4 Aug 1998 10:44:52 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma027372; Tue, 4 Aug 98 10:43:52 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id KAA02278 for ; Tue, 4 Aug 1998 10:43:16 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma001205; Tue, 4 Aug 98 10:42: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 KAA17138; Tue, 4 Aug 1998 10:42: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 12:07:20 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id MAA05456 for ; Tue, 4 Aug 1998 12:07:20 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id MAA03435 for ; Tue, 4 Aug 1998 12:05:59 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma003050; Tue, 4 Aug 98 12:04:50 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id MAA15990 for ; Tue, 4 Aug 1998 12:04:14 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma014728; Tue, 4 Aug 98 12:03: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 MAA10494; Tue, 4 Aug 1998 12:03:36 -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 13:14:26 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id NAA05977 for ; Tue, 4 Aug 1998 13:14:26 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id NAA08290 for ; Tue, 4 Aug 1998 13:13:06 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma007827; Tue, 4 Aug 98 13:11:31 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id NAA18416 for ; Tue, 4 Aug 1998 13:10:50 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma016225; Tue, 4 Aug 98 13:08: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 NAA28990; Tue, 4 Aug 1998 13:09:15 -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 14:47:45 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id OAA06714 for ; Tue, 4 Aug 1998 14:47:45 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id OAA15017 for ; Tue, 4 Aug 1998 14:46:22 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma014452; Tue, 4 Aug 98 14:44:06 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id OAA06496 for ; Tue, 4 Aug 1998 14:43:27 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma003840; Tue, 4 Aug 98 14:41:06 -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 OAA21941; Tue, 4 Aug 1998 14:41:35 -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 17:42:24 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id RAA08069 for ; Tue, 4 Aug 1998 17:42:23 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id RAA26142 for ; Tue, 4 Aug 1998 17:41:04 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma024876; Tue, 4 Aug 98 17:37:25 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id RAA07897 for ; Tue, 4 Aug 1998 17:36:42 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma004975; Tue, 4 Aug 98 17:34: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 RAA05791; Tue, 4 Aug 1998 17:34:57 -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 martin@exmandato.se Tue Aug 4 17:42:33 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id RAA08073 for ; Tue, 4 Aug 1998 17:42:33 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id RAA26212 for ; Tue, 4 Aug 1998 17:41:14 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma024917; Tue, 4 Aug 98 17:37:30 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id RAA08053 for ; Tue, 4 Aug 1998 17:36:48 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma004976; Tue, 4 Aug 98 17:34: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 RAA05792; Tue, 4 Aug 1998 17:34: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 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 rpresuhn@dorothy.bmc.com Wed Aug 5 00:32:07 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id AAA11199 for ; Wed, 5 Aug 1998 00:32:07 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id AAA10596 for ; Wed, 5 Aug 1998 00:30:45 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma009985; Wed, 5 Aug 98 00:28:54 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id AAA06407 for ; Wed, 5 Aug 1998 00:28:13 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma005407; Wed, 5 Aug 98 00:27: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 AAA21489; Wed, 5 Aug 1998 00:27:57 -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 08:52:16 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id IAA14916 for ; Wed, 5 Aug 1998 08:52:15 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id IAA29166 for ; Wed, 5 Aug 1998 08:50:53 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma027932; Wed, 5 Aug 98 08:47:46 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id IAA03863 for ; Wed, 5 Aug 1998 08:47:10 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma029758; Wed, 5 Aug 98 08:44: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 IAA20742; Wed, 5 Aug 1998 08:44: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 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 08:53:35 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id IAA14936 for ; Wed, 5 Aug 1998 08:53:35 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id IAA29493 for ; Wed, 5 Aug 1998 08:52:14 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma027884; Wed, 5 Aug 98 08:47:39 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id IAA03646 for ; Wed, 5 Aug 1998 08:46:57 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma029769; Wed, 5 Aug 98 08:44: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 IAA20744; Wed, 5 Aug 1998 08:44:53 -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 10:01:48 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id KAA15451 for ; Wed, 5 Aug 1998 10:01:48 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id KAA06391 for ; Wed, 5 Aug 1998 10:00:27 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma005527; Wed, 5 Aug 98 09:58:42 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id JAA17121 for ; Wed, 5 Aug 1998 09:58:02 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma014710; Wed, 5 Aug 98 09:56:07 -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 JAA13077; Wed, 5 Aug 1998 09:56:36 -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 daniele@zk3.dec.com Wed Aug 5 10:03:19 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id KAA15465 for ; Wed, 5 Aug 1998 10:03:19 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id KAA06953 for ; Wed, 5 Aug 1998 10:01:57 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma006129; Wed, 5 Aug 98 09:59:54 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id JAA18718 for ; Wed, 5 Aug 1998 09:59:15 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma014777; Wed, 5 Aug 98 09:56: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 JAA13093; Wed, 5 Aug 1998 09:56:38 -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 bnatale@acecomm.com Wed Aug 5 11:08:22 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id LAA16422 for ; Wed, 5 Aug 1998 11:08:22 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id LAA14661 for ; Wed, 5 Aug 1998 11:07:00 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma014330; Wed, 5 Aug 98 11:05:54 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id LAA27240 for ; Wed, 5 Aug 1998 11:05:18 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma026599; Wed, 5 Aug 98 11:04: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 LAA02846; Wed, 5 Aug 1998 11:05:15 -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 12:17:10 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id MAA17843 for ; Wed, 5 Aug 1998 12:17:10 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id MAA20945 for ; Wed, 5 Aug 1998 12:15:48 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma020566; Wed, 5 Aug 98 12:14:38 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id MAA02939 for ; Wed, 5 Aug 1998 12:14:03 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma001843; Wed, 5 Aug 98 12:13: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 MAA22027; Wed, 5 Aug 1998 12:13:44 -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 ------------- From bnatale@acecomm.com Wed Aug 5 16:43:10 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id QAA23301 for ; Wed, 5 Aug 1998 16:43:09 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id QAA07936 for ; Wed, 5 Aug 1998 16:41:46 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma007539; Wed, 5 Aug 98 16:40:13 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id QAA21590 for ; Wed, 5 Aug 1998 16:39:37 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma019638; Wed, 5 Aug 98 16:37: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 QAA28568 for ; Wed, 5 Aug 1998 16:38:14 -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 OAA05545 for ; Wed, 5 Aug 1998 14:11:56 -0700 (PDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id QAA05420 for ; Wed, 5 Aug 1998 16:11:54 -0500 (CDT) Received: from relay4.smtp.psi.net(38.9.52.2) by almond.bmc.com via smap (V2.0) id xma005408; Wed, 5 Aug 98 16:11:36 -0500 Received: from [192.152.208.5] (helo=acecomm.com) by relay4.smtp.psi.net with smtp (Exim 1.90 #1) for agentx@peer.com id 0z4Aq0-0001QK-00; Wed, 5 Aug 1998 17:11:21 -0400 Received: from bnatale by acecomm.com (5.65/3.2.083191-ACE*COMM) id AA06934; Wed, 5 Aug 1998 17:13:32 -0400 Message-Id: <9808052113.AA06934@acecomm.com> X-Sender: natale@nips.acec.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1 Date: Wed, 05 Aug 1998 17:13:16 -0400 To: agentx@peer.com From: Bob Natale Subject: AgentX Bake-Off Test Report Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Hi Everyone, Appended following my .sig is the summary report from the recent AgentX bake-off event. The report is based upon a series of post-event reports and exchanges among the group of participants (identified in the report) and the editors of the AgentX spec (Dale Franciso) and MIB (Smitha Gudur). I personally did the filtering/merging/editing of what ended up in the report as it appears below...so I am solely responsible for any errors of fact or omissions that it may contain. I am sure the other bake-off participants will point them out! I encourage everyone to feel free to comment on the contents and implications of the report in any respect you deem important. For those not planning to attend the AgentX meeting at the Chicago IETF on the 26th of this month, PLEASE take this opportunity to raise any issues or make any suggestions you think would be helpful. 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 ------------- AgentX Interoperability Testing Summary Report 1. Logistics: The AgentX Interoperability Testing was held at BMC facilities in Sunnyvale CA on Thursday, July 23, 1998, from (approximately) 9:30am to 6:30pm, PDT. Some follow-up testing was conducted by a subset of the participants the following day. The following organizations/individuals attended, testing the indicated implementations: COMPANY PEOPLE MA MIB SA OS ------- ------ -- --- -- -- ACE*COMM Bob Natale(1) Yes .02 No NT BMC Lauren Heintz Yes .00 Yes UNIX Vern Hyde Mike Thatcher Compaq/DEC Mike Daniele(2) Yes No Yes UNIX Mark Ellison IBM Bert Wijnen(2) * * * * ISI/Epilogue Shawn Routhier Yes .00 Yes UNIX SNMP Research Jeff Case Yes No Yes UNIX David Battle (in absentia) Legend: MA = Master Agent. MIB = AgentX MIB, with version noted. SA = Sub-Agent(s): - AgentX MIB - MIB-II - SMUX MIB - SNMPv3 MIBs (RFC 2271/2/4/5) - Various vanilla test MIBs - At least two "white-box" test MIBs OS = Operating system. UNIX variants used in the testing included: - Solar is 2.x - Digital UNIX - FreeBSD 2.2 - SunOS 4.1.4 Most or all of the UNIX implementations were coded to run on a variety of UNIX platforms. The NT implementation was coded to run on all current Win32 platforms. (1) = AgentX WG chair. (2) = AgentX (RFC 2257) co-author. * = Bert present in Area Director role. 2. Results: Some rough edges at the boundaries of each implementation were identified during the course of the day. Each of these was resolved on-site with modest effort. Beyond that, all capabilities provided by each implementation interoperated correctly with all other implementations with similar capabilities. Some AgentX features supporting complex operating scenarios were tested only with simpler scenarios and some AgentX features were not included in any of the tested implementations. These are noted below. 3. AgentX features not tested or incompletely tested: a. Index allocation and deallocation operations. b. Agent capabilities operations. c. UNIX Domain Sockets (multi-vendor configs): This feature was tested successfully, however, by two independent implementations prior to the AgentX bake-off. d. Multi-session over a single connection (multi- vendor configs). e. Complex region registrations (overlapping regions with row-level registrations among multi-vendor and multi-context configs) and protocol tests (i.e., do SNMP messages affect the proper subagents and authoritative regions). (Emphasis on "complex" here... many "routine" registration operations were tested successfully.) f. agentx-Notify-PDUs: This was tested at the AgentX level (subagent sent them to the master agent, which correctly parsed them), but no actual SNMP traps were issued by the master agent(s) involved. These features will have to be (more fully) tested for interoperability between at least two independent implementations prior to advancement of RFC 2257. 4. AgentX protocol features which proved mildly problematic: a. Byte-ordering conventions: The e-mail archives for July 16, 1997 contain a series of exchanges between David Battle, Mike Daniele, and Bob Natale which might yield the few additional words needed to ensure that implementors understand the role of the NETWORK_BYTE_ORDER bit. b. TCP streams vs UDP datagrams: SNMP programmers accustomed to UDP message delivery need to be aware of the generic differences for TCP message delivery. c. NON_DEFAULT_CONTEXT processing: The meaning of the OPTIONAL label in the descriptions of AgentX PDU types which support the "context" field must be called out more distinctly. (See 5d, below.) Clearly, the SNMPv3 WG has put additional meat on the bones of the term "context" (esp. in RFC 2271) and that should probably guide the evolution of AgentX in this particular respect. However, incorporation of SNMPv3 considerations will most likely not be attempted until AgentX v2 is undertaken (which is on our charter milestones for March of 1999). d. Several implementations had troubles with Counter64: To some extent this was due to varying levels and modes of support for 64-bit integers in the different operating systems under test and to some extent it was related to misunderstanding the byte-ordering implications of the NETWORK_BYTE_ORDER bit. In general, these problem areas were mostly a combination of coding practices and failure to read the protocol spec carefully enough. In most cases, it was agreed that more direct clarifying text in the spec is all that may be required to help other implementors avoid the problems. In all cases, the text in RFC 2257 is correct, but perhaps not sufficiently clear. 5. AgentX protocol features and specifications needing clarification: a. See #4 a/b/c/d above. b. PDU types not needing a response: Currently the elements of procedure specified in RFC 2257 do not require the master agent to issue an agentx-Response-PDU to the subagent in response to either the agentx-Close-PDU or agentx-Notify-PDU. This makes subagent TCP processing more complex than may be necessary or desirable. This is particularly true wrt the agentx-Notify-PDU; but the best course of action might be to require the master agent to issue an agentx-Response-PDU in reply to every PDU received from the subagent. c. UNIX-Domain socket conventions: This was a topic of discussion at the bake-off, but no needed changes or clarifications were identified. It is reported here simply for completeness of the record so that implementors in non-tested environments might be on the look-out for anything novel or problematic. d. Optional vs NULL/missing vs zero-length PDU fields: RFC 2257 includes at least three uses for "optional" components: - Context field - Upper bound subid on a registration operation - Padding after an octet string In the first two cases the data is either present in the pdu, or it is not, as indicated by something else in the pdu (i.e., NON_DEFAULT_CONTEXT bit set and a non-zero range_subid, respectively). These dependencies need to be highlighted in the affected PDU descriptions. For the octet string padding, we must change the phrase "Optional Padding" to "Padding (if needed)" or something similar. The point is that the padding bytes must be there in all cases where the string length is not zero or a multiple of four. e. Search ranges for PDUs: Some confusion existed as to the form of an acceptable search range for nexts/bulks, etc. For example, implementations received differing results from different vendors when a given master agent search range (for nexts) had a starting OID that preceded a subagent's implemented (and registered) range (and the include flag was off), and whose ending OID was NULL. So, the question arises: May a master agent perform a next query on a subagent using a search range that partially or wholly coincides with a non-registered region (regardless of whether this make sense)? RFC 2257 precludes this scenario (see Sec. 7.2.1.2, steps (1)b) and (5)). However, for this to work properly the master agent probably must have saved the INSTANCE_REGISTRATION flag. The handling of this flag bit (on registrations) is currently left to the discretion of the master agent "to optimize subsequent processing"...we should probably change the wording to point out that having access to this flag bit's value is necessary for correct operation of certain AgentX functions. In general, testing in this area showed that tighter wording may be necessary. f. The description of range_subid in the agentx-Register-PDU needs clarification: It is not clear whether its value should reflect the way the OID is encoded (i.e., added to any prefix that may also be specified) or always refer to its "natural" position in the OID (i.e., w/o regard to any prefix value). The example shows that to register 1.3.6.1.2.1.2.2.1.1-22.7 you specify a range_subid of 5, and an upper_bound of 22. This means the 5th subid after the prefix (1.3.6.1.2) is the range_subid. The text is not clear about this. Further, the intended mechanism requires one to know how the OID will be encoded. The bake-off participants expressed some agreement that both the text should be made clearer AND the value for range_subid should be based on the natural OID, not it's encoded form. So in the example given, the range_subid should be 10, not 5. g. Re-use of SessionID values: There was some confusion on this point due to differences in the related text in RFC 2257 versus the AgentX MIB I-D. In addition, the text in RFC 2257 may not be comprehensive enough. The current consensus among the bake-off participants is that SessionID values, within a given invocation of a master agent: - MUST always be unique among the open ones. - MUST not take 0 (zero) as an assigned value. - SHOULD start at 1. - SHOULD increase monotonically. - SHOULD not be reused, except in the case of of a wrap back to the initial value. RFC 2257 should be revised to include this stipulations. In any case, the AgentX MIB must conform to the clarified text in RFC 2257. 6. Features missing from the AgentX protocol that must be added: a. Generic error code(s)--e.g., otherError. b. Generic registrationFailed code. 7. AgentX MIB: Needs another review cycle and edits, primarily for consistency and completeness. No significant additions contemplated. This work is active and on-going on the list at this time. 8. RFC 2257: a. We are examining the e-mail archives for any changes that may have been agreed to and may have fallen through the cracks during the long IESG action cycle between submission of the final I-D and publication of the RFC. b. The core design team will monitor the overall results from the bake-off and follow-up on-list discussions and decide what edits are necessary and advisable. c. The full list will be given a chance to propose mods, review all proposed mods (and to know of those proposed but rejected). 9. On-going tests: The bake-off participants plan to continue testing, in pairs or larger ad hoc groups of implementations, to ensure that all AgentX protocol features interoperate correctly in accordance with RFC 2257. 10. AgentX WG meeting at Chicago (42nd) IETF...among other things: a. Formal implementation and interoperability reports will be presented. b. Current status of the MIB document and issues will be presented. c. A decision will be made wrt asking the IESG to advance RFC 2257 to Draft Standard status or recycling it at Proposed Standard status. If possible, on-list consensus for this decision will be sought prior to the IETF meeting. d. Interactions with efforts of the SNMPv3 WG and the DISMAN WG will be reviewed. --- The End --- From bnatale@acecomm.com Wed Aug 5 17:51:45 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id RAA24713 for ; Wed, 5 Aug 1998 17:51:45 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id RAA12981 for ; Wed, 5 Aug 1998 17:50:21 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma012318; Wed, 5 Aug 98 17:48:23 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id RAA13790 for ; Wed, 5 Aug 1998 17:47:48 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma012696; Wed, 5 Aug 98 17:46: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 RAA11240 for ; Wed, 5 Aug 1998 17:47: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 PAA07183 for ; Wed, 5 Aug 1998 15:33:50 -0700 (PDT) Received: (from uucp@localhost) by cashew.bmc.com (8.8.8/8.8.8) id RAA13347 for ; Wed, 5 Aug 1998 17:33:47 -0500 (CDT) Received: from relay4.smtp.psi.net(38.9.52.2) by cashew.bmc.com via smap (V2.0) id xma013338; Wed, 5 Aug 98 17:33:32 -0500 Received: from [192.152.208.5] (helo=acecomm.com) by relay4.smtp.psi.net with smtp (Exim 1.90 #1) id 0z4C1S-00062F-00; Wed, 5 Aug 1998 18:27:29 -0400 Received: from bnatale by acecomm.com (5.65/3.2.083191-ACE*COMM) id AA08084; Wed, 5 Aug 1998 18:29:01 -0400 Message-Id: <9808052229.AA08084@acecomm.com> X-Sender: natale@nips.acec.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1 Date: Wed, 05 Aug 1998 18:28:44 -0400 To: "Ashish Hanwadikar" From: Bob Natale Subject: RE: open issues in agentX MIB Cc: agentx@peer.com In-Reply-To: <008401bdbdeb$ea7e6c80$163409c0@opel.wipinfo.soft.net> References: <9807312258.AA17629@acecomm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" >At 8/2/98 01:32 PM, Ashish Hanwadikar wrote: Hi Ashish, <...> >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. Not really...since the range of choices is extremely limited. Try the one you prefer; if tha fails, try the other; if that fails, report the problem and exit or wait for retry instructions. >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. And the subagent would use SNMP to query the master agent for this table...? And, of course, the master agent might be listening at UDP/161 or it might listening somewhere else...what source would the subagent consult to retrieve that information? :-) >I guess such a table was there in the DPI from which AgentX >derives its inspiration. I'm not sure. In any case (the dilemma I mentioned above notwithstanding), this level of "AgentX environmental control" was not envisioned as one of the goals of this MIB. If it were, there's a lot we could add that would be equally beneficial to subagents...like, at what priority should I register my objects?; what index allocations should I ask for?; what contexts can I use?; etc. For now, such matters are left to implementation decisions...e.g., an agentx_startup.cfg file might tell the master the order in which to invoke known subagents and their relative priority levels. We have not seen anything close to a show-stopper in this respect. >Thanks Please let me know if I've misunderstood your point or failed to respond to it satisfactorily. 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 Wed Aug 5 19:36:44 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id TAA26864 for ; Wed, 5 Aug 1998 19:36:43 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id TAA17763 for ; Wed, 5 Aug 1998 19:35:21 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma017267; Wed, 5 Aug 98 19:34:05 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id TAA25651 for ; Wed, 5 Aug 1998 19:33:21 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma024524; Wed, 5 Aug 98 19:32: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 TAA01514 for ; Wed, 5 Aug 1998 19:33:03 -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 RAA08704 for ; Wed, 5 Aug 1998 17:18:09 -0700 (PDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id TAA16348 for ; Wed, 5 Aug 1998 19:18:08 -0500 (CDT) Received: from f213.hotmail.com(207.82.251.104) by almond.bmc.com via smap (V2.0) id xma016340; Wed, 5 Aug 98 19:17:53 -0500 Received: (qmail 14791 invoked by uid 0); 6 Aug 1998 00:17:46 -0000 Message-ID: <19980806001746.14790.qmail@hotmail.com> Received: from 152.67.249.57 by www.hotmail.com with HTTP; Wed, 05 Aug 1998 17:17:46 PDT X-Originating-IP: [152.67.249.57] From: "Smitha Gudur" To: daniele@zk3.dec.com Cc: agentx@peer.com Subject: Re: some comments on MIB Content-Type: text/plain Date: Wed, 05 Aug 1998 17:17:46 PDT Hi, Mike, >From daniele@zk3.dec.com Wed Aug 5 08:04:11 1998 >Received: (from uucp@localhost) > by almond.bmc.com (8.8.8/8.8.8) id KAA07422 > for ; Wed, 5 Aug 1998 10:03:35 -0500 (CDT) >Received: from firewall.bmc.com(192.245.162.250) > by almond.bmc.com via smap (V2.0) > id xma005772; Wed, 5 Aug 98 09:59:11 -0500 >Received: (from uucp@localhost) > by dresden.bmc.com (8.8.5/8.8.6) id JAA17795 > for ; Wed, 5 Aug 1998 09:58:30 -0500 (CDT) >Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) > id xma015842; Wed, 5 Aug 98 09:56: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 JAA12994; > Wed, 5 Aug 1998 09:56:23 -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. Agreed. Will be removed. > >2) I thought there was agreement last year to remove >agentxConnNumber and agentxConnSessions? Yes, there was an agreement to remove it and it will done this time for sure. > >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 :-) This will be useful and needs to be added once an agreement is reached on what needs to go into. > > >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.) ok. Will wait until it is changed in 2257 and then reflect the change into the MIB. thanks smitha > >Thanks, >Mike > ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com From manne@siemensdc.com Thu Aug 6 02:10:59 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id CAA05038 for ; Thu, 6 Aug 1998 02:10:58 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id CAA01036 for ; Thu, 6 Aug 1998 02:09:36 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma000404; Thu, 6 Aug 98 02:07:28 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id CAA05035 for ; Thu, 6 Aug 1998 02:06:53 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma004073; Thu, 6 Aug 98 02:05: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 CAA03899 for ; Thu, 6 Aug 1998 02:06:05 -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 XAA09980 for ; Wed, 5 Aug 1998 23:42:12 -0700 (PDT) Received: (from uucp@localhost) by cashew.bmc.com (8.8.8/8.8.8) id BAA00382 for ; Thu, 6 Aug 1998 01:42:10 -0500 (CDT) Received: from ornet.co.il(194.90.140.5) by cashew.bmc.com via smap (V2.0) id xma000368; Thu, 6 Aug 98 01:41:43 -0500 Received: from christin.ornet.co.il (christin.ornet.co.il [194.90.140.79]) by ornet.ornet.co.il (8.7.6/8.7.3) with ESMTP id JAA24563 for ; Thu, 6 Aug 1998 09:41:39 +0300 (IDT) Received: by christin.ornet.co.il with Internet Mail Service (5.5.1960.3) id ; Thu, 6 Aug 1998 09:41:38 +0300 Message-ID: <004246117607D21188470060089C61BB105EEC@christin.ornet.co.il> From: Aharon Manne To: agentx@peer.com Cc: Amit Meyuhas Subject: Dynamic row creation Date: Thu, 6 Aug 1998 09:41:37 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain Hello, We are considering using AgentX in the implementation of an agent for our stackable bridge products. We wish to present the stack as a single transparent bridge, with ifIndex indexing the ports of the various modules. In this situation, I would like to understand how to create an entry in the dot1dStaticTable of rfc1493, or in the dot1qStaticTable of the proposed new version of the bridge MIB. The former is indexed by {dot1dStaticAddress, dot1dStaticReceivePort}. According to a discussion I found in the list archives (from April 98), it is not possible under AgentX to create rows in tables with multiple indices [tuples, of the form (1,1), (1,2)]. The conclusion there as I understood it was that one can solve the problem by using one of the indices, as long as it is unique in the table. In our case, we could use dot1dStaticAddress as such an index. In our case, the desired result is that all the elements of the stack hold identical copies of the dot1dStaticTable (the fact that the hardware will interpret them differently depending on whether a given ifIndex is local or not is an implementation issue). As I understand AgentX, row creation is a function of the subagent, not the master. When an NMS requests the creation of a new row, the master agent must choose one of the subagents as being responsible for the given range of index values (rfc2257, sec. 7.2.1.4(3)) This implies that we should assign one of the subagents as being responsible for the entire range of dot1dStaticAddress values. This in turn seems to imply that the table would be propagated to the other subagents "behind the back" of AgentX, as it were. This seems to me to defeat the purpose of AgentX, but I can't think of a better implementation. I would appreciate it greatly if someone on the list could show me a better way of doing what I want to do. Aharon Manne Siemens Data Communications Karmiel, Israel From ashishkh@wipinfo.soft.net Thu Aug 6 06:30:06 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id GAA10321 for ; Thu, 6 Aug 1998 06:30:06 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id GAA09396 for ; Thu, 6 Aug 1998 06:28:43 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma008810; Thu, 6 Aug 98 06:26:39 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id GAA01932 for ; Thu, 6 Aug 1998 06:26:03 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma001126; Thu, 6 Aug 98 06:25: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 GAA16522 for ; Thu, 6 Aug 1998 06:25:34 -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 EAA10442 for ; Thu, 6 Aug 1998 04:05:21 -0700 (PDT) Received: (from uucp@localhost) by cashew.bmc.com (8.8.8/8.8.8) id GAA07119 for ; Thu, 6 Aug 1998 06:05:16 -0500 (CDT) Received: from agni.wipinfo.soft.net(164.164.6.20) by cashew.bmc.com via smap (V2.0) id xma007109; Thu, 6 Aug 98 06:04:42 -0500 Received: from divya.wipinfo.soft.net by wipinfo.soft.net (SMI-8.6/SMI-SVR4) id QAA18603; Thu, 6 Aug 1998 16:29:41 -0500 Received: from opel ([192.9.52.22]) by divya.wipinfo.soft.net (8.8.5/8.8.5) with SMTP id QAA02268; Thu, 6 Aug 1998 16:36:30 +0530 From: "Ashish Hanwadikar" To: "Smitha Gudur" Cc: "Agentx" Subject: RE: open issues in agentX MIB Date: Thu, 6 Aug 1998 16:34:54 +0530 Message-ID: <006e01bdc12a$0b1143f0$163409c0@opel.wipinfo.soft.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_006F_01BDC158.24C97FF0" 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 In-Reply-To: <19980803172850.25088.qmail@hotmail.com> This is a multi-part message in MIME format. ------=_NextPart_000_006F_01BDC158.24C97FF0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi smitha, You said "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.". However, I could not find any API through which I can find out whether there is any one listening on a particular port in particular transport domain? (I know I can always try to connect to the port and that should tell me whether the master agent is listening or not.) However, just for curiosity, is there any API (either in UNIX or NT) which will give the information that netstat displays through command line? Thanks. with regards, Ashish K Hanwadikar Senior Software Engineer, Wipro Infotech, Technology Solutions, Bangalore INDIA -----Original Message----- From: Smitha Gudur [mailto:sgudur@hotmail.com] Sent: Monday, August 03, 1998 10:59 PM To: ashishkh@wipinfo.soft.net Cc: agentx@peer.com Subject: RE: open issues in agentX MIB >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 ------=_NextPart_000_006F_01BDC158.24C97FF0 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_006F_01BDC158.24C97FF0-- From schoenw@ibr.cs.tu-bs.de Thu Aug 6 07:59:03 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id HAA12143 for ; Thu, 6 Aug 1998 07:59:03 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id HAA13722 for ; Thu, 6 Aug 1998 07:57:39 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma012990; Thu, 6 Aug 98 07:55:40 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id HAA04781 for ; Thu, 6 Aug 1998 07:55:05 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma003678; Thu, 6 Aug 98 07:54: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 HAA03535 for ; Thu, 6 Aug 1998 07:54:43 -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 FAA10634 for ; Thu, 6 Aug 1998 05:41:39 -0700 (PDT) Received: (from uucp@localhost) by cashew.bmc.com (8.8.8/8.8.8) id HAA10144 for ; Thu, 6 Aug 1998 07:41:37 -0500 (CDT) Received: from mumm.ibr.cs.tu-bs.de(134.169.34.190) by cashew.bmc.com via smap (V2.0) id xma010130; Thu, 6 Aug 98 07:41:32 -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 OAA28759; Thu, 6 Aug 1998 14:40:34 +0200 (MET DST) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id OAA23754; Thu, 6 Aug 1998 14:40:22 +0200 Date: Thu, 6 Aug 1998 14:40:22 +0200 Message-Id: <199808061240.OAA23754@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: ashishkh@wipinfo.soft.net CC: sgudur@hotmail.com, agentx@peer.com In-reply-to: <006e01bdc12a$0b1143f0$163409c0@opel.wipinfo.soft.net> (ashishkh@wipinfo.soft.net) Subject: Re: open issues in agentX MIB References: <006e01bdc12a$0b1143f0$163409c0@opel.wipinfo.soft.net> Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII >>>>> Ashish Hanwadikar writes: Ashish> Hi smitha, You said "There are other ways of finding out, Ashish> which port the Master agent is listening. In unix environment, Ashish> netstat and other commands would do the work.". However, I Ashish> could not find any API through which I can find out whether Ashish> there is any one listening on a particular port in particular Ashish> transport domain? (I know I can always try to connect to the Ashish> port and that should tell me whether the master agent is Ashish> listening or not.) However, just for curiosity, is there any Ashish> API (either in UNIX or NT) which will give the information Ashish> that netstat displays through command line? Read the source of netstat or, even better, lsof. On many UNIX operating systems, you have to do ugly kernel dives. Some UNIX systems give you access the information via a process file system. I am not sure about NT. 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 Thu Aug 6 09:47:55 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id JAA14325 for ; Thu, 6 Aug 1998 09:47:55 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id JAA23644 for ; Thu, 6 Aug 1998 09:46:30 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma022799; Thu, 6 Aug 98 09:43:59 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id JAA07378 for ; Thu, 6 Aug 1998 09:43:15 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma004534; Thu, 6 Aug 98 09:40: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 JAA04095 for ; Thu, 6 Aug 1998 09:41:18 -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 HAA10803 for ; Thu, 6 Aug 1998 07:19:25 -0700 (PDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id JAA19455 for ; Thu, 6 Aug 1998 09:19:24 -0500 (CDT) Received: from mumm.ibr.cs.tu-bs.de(134.169.34.190) by almond.bmc.com via smap (V2.0) id xma019400; Thu, 6 Aug 98 09:18:38 -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 QAA02883; Thu, 6 Aug 1998 16:11:32 +0200 (MET DST) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id QAA25187; Thu, 6 Aug 1998 16:11:24 +0200 Date: Thu, 6 Aug 1998 16:11:24 +0200 Message-Id: <199808061411.QAA25187@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: bnatale@acecomm.com CC: daniele@zk3.dec.com, agentx@peer.com In-reply-to: <9808051655.AA02660@acecomm.com> (message from Bob Natale on Wed, 05 Aug 1998 12:55:24 -0400) Subject: Re: Table Indices in AgentX MIB References: <9808051655.AA02660@acecomm.com> Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII >>>>> Bob Natale writes: [snip] Bob> Well, is anyone persuaded? :-) No. And I will tell you why. I will quote some of your statements and comment on them below. (Please excuse me if you think I am quoting out of context.) Bob> If one does not know what configurations might make sense in the Bob> future, one perhaps should *avoid* leveraging the "natural Bob> containment hierarchy" of the moment. If I understand the AgentX RFC correctly, than there is no way to have an AgentX session without a connection and there is no way to have a registration without a session. This means that the structure is inherent in AgentX and what the "natural containment hierarchy" is not going to change unless we make major changes to AgentX. So it is not a containment hierarchy of the moment - it is the containment hierarchy inherent in AgentX. Bob> Such "leveraging" serves the needs of only a small number of Bob> obvious queries--esp., what sessions belong to this connection; Bob> what registrations belong to this session; and what registrations Bob> belong to this connection. Other potential queries on the Bob> session and registration tables may be constrained by need for Bob> multiple index values when a single (unique) row identifier Bob> exists and/or by the NOT-ACCESSIBLE MAX-ACCESS nature of these Bob> indices. I do not understand your point. You can still dump the whole table if you prefer to do that. You can still monitor individual objects if you prefer to do that. Please explain why the structured index constrains other queries. Also explain why the NOT-ACCESSIBLE MAX-ACCESS clause constrains queries. Bob> Anyway, here's how I break out the general case: Bob> 1. If a table has a unique-valued columnar object suitable for Bob> use as an index, using other/additional objects as indices into Bob> this table requires special justification. The scope of uniqueness has to be determined - and has actually been a subject of discussion recently. And there is a justification: Using a structured indexing scheme gives us groupings that some people find valuable (see below for an example). Bob> 2. A justification based on "natural containment hierarchy" is Bob> not prima facie sufficient, unless it can be shown that: Bob> a. Queries which depend on such "containment" will dominate Bob> management operations; and/or I am arguing that not using a structured indexing scheme can cause scalability problems with the AgentX MIB in the future (see below for an example). Good MIB design should avoid these problems if possible at virtually no costs. Bob> b. the cost of not having such "containment" when performing Bob> the queries in 2a would have a significantly negative impact on Bob> the managed element. The implementation costs of a flat and a structured indexing scheme depends on the internal data structures you use, as we both seem to agree. Bob> Applied specifically to AgentX, 2a is not known to apply and 2b Bob> is known not to apply (since all tables will be "small" in any Bob> reasonable meaning of that vague term). Since we don't know whether 2a applies, we should make a design that works if 2a applies, especially if that is doable without raising the implementation costs. And see below for an example on how "small" the tables might be in two years from now. Bob> 3. The original SNMP philosophy of not encasing "meta-" and Bob> "pseudo-" data within an agent is still valid as a starting point Bob> in MIB design...the identified "containment hierarchy" is an Bob> example of such meta or pseudo data... I disagree. The indexing scheme does not express "meta-" or "pseudo-" data. All it does is that it makes a relationship which is inherent in AgentX explicit in the indexing structure so that it can be used by management applications to build optimized queries. The data which is expressed in the structured index would otherwise appear in some additional columnar objects and the manager (human or a program) would have to always dump complete tables in order to extract the information he is interested in. In other words, the structured indexing scheme makes a relationship explicit which otherwise only exists implicitely without adding new objects. I do not call this "meta-" or "pseudo-" data. Here is the promised example how small AgentX tables might be in the future. Lets assume that AgentX is getting widely deployed on server machines. Lets further assume that the work in the application management WG is successful. The preferred way to implement things like the application mgmt MIB is to have subagents embedded into applications that export statistics via AgentX. Lets assume you have a server and there are 20-50 instrumented applications running on your server. Every application will register several regions because it exports mgmt information in several shared tables. Lets assume the average number of registrations per application is 10 (which is not an unrealistic high number if you look at draft-ietf-applmib-mib-08.txt). This means that you end up with 200-500 entries in the agentxRegistrationTable. Finding the 10 registrations for a given application requires to retrieve those 200-500 entries in addition to the whole agentxSessionTable and the whole agentxConnectionTable (because you need the subagent connection endpoint in order to identify the application with the embedded subagent). With the structured index, you would need the retrieve about 30-60 entries (assuming there is only one session per connection). Sure, you will argue that we do not know whether this scenario will become reality in the next 2 years and that we should keep things simple. I argue that MIB designers should take care about scalability issues, especially if they do not know what the future will be and if there is little cost in making the MIB design scalable. Anyway, we don't have to agree. I have raised my view, you have raised your view. Now its up to the WG do make up its mind and to come to a conclusion. 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 bnatale@acecomm.com Thu Aug 6 09:48:00 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id JAA14334 for ; Thu, 6 Aug 1998 09:47:59 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id JAA23674 for ; Thu, 6 Aug 1998 09:46:34 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma022789; Thu, 6 Aug 98 09:43:58 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id JAA07519 for ; Thu, 6 Aug 1998 09:43:21 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma004621; Thu, 6 Aug 98 09:40: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 JAA04145 for ; Thu, 6 Aug 1998 09:41: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 HAA10795 for ; Thu, 6 Aug 1998 07:15:16 -0700 (PDT) Received: (from uucp@localhost) by cashew.bmc.com (8.8.8/8.8.8) id JAA15158 for ; Thu, 6 Aug 1998 09:15:14 -0500 (CDT) Received: from relay4.smtp.psi.net(38.9.52.2) by cashew.bmc.com via smap (V2.0) id xma015128; Thu, 6 Aug 98 09:15:01 -0500 Received: from [192.152.208.5] (helo=acecomm.com) by relay4.smtp.psi.net with smtp (Exim 1.90 #1) id 0z4Qoe-0005gJ-00; Thu, 6 Aug 1998 10:14:52 -0400 Received: from bnatale by acecomm.com (5.65/3.2.083191-ACE*COMM) id AA14059; Thu, 6 Aug 1998 10:17:38 -0400 Message-Id: <9808061417.AA14059@acecomm.com> X-Sender: natale@nips.acec.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1 Date: Thu, 06 Aug 1998 10:17:23 -0400 To: ashishkh@wipinfo.soft.net From: Bob Natale Subject: Re: open issues in agentX MIB Cc: agentx@peer.com In-Reply-To: <199808061240.OAA23754@henkell.ibr.cs.tu-bs.de> References: <006e01bdc12a$0b1143f0$163409c0@opel.wipinfo.soft.net> <006e01bdc12a$0b1143f0$163409c0@opel.wipinfo.soft.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" >At 8/6/98 02:40 PM, Juergen Schoenwaelder wrote: Hi Ashish (mostly), >Ashish> Hi smitha, You said "There are other ways of finding out, >Ashish> which port the Master agent is listening. In unix environment, >Ashish> netstat and other commands would do the work.". However, I >Ashish> could not find any API through which I can find out whether >Ashish> there is any one listening on a particular port in particular >Ashish> transport domain? (I know I can always try to connect to the >Ashish> port and that should tell me whether the master agent is >Ashish> listening or not.) However, just for curiosity, is there any >Ashish> API (either in UNIX or NT) which will give the information >Ashish> that netstat displays through command line? > >Read the source of netstat or, even better, lsof. On many UNIX >operating systems, you have to do ugly kernel dives. Some UNIX >systems give you access the information via a process file system. >I am not sure about NT. I guess one might also use the "services" database too, if hints are needed. However, for subagent connections to the AgentX master agent, the situation is just not very difficult. Only two connection "points" are defined (in Sec. 8 of RFC 2257) thus far: TCP, on port 705 UNIX Domain Socket, at "/var/agentx/master" Your app just tries the one in needs or prefers to use. If it fails and the app can support the other, try the other. If that fails, report the problem in whatever fashion makes sense to the app (e.g., UI, log file, trap) and take whatever action makes sense for the app (e.g., wait for retry indication, terminate, etc.). 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 Thu Aug 6 09:53:30 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id JAA14449 for ; Thu, 6 Aug 1998 09:53:30 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id JAA25550 for ; Thu, 6 Aug 1998 09:52:06 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma024300; Thu, 6 Aug 98 09:48:11 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id JAA12482 for ; Thu, 6 Aug 1998 09:47:28 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma009652; Thu, 6 Aug 98 09:45: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 JAA05082 for ; Thu, 6 Aug 1998 09:45: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 HAA10843 for ; Thu, 6 Aug 1998 07:39:05 -0700 (PDT) Received: (from uucp@localhost) by cashew.bmc.com (8.8.8/8.8.8) id JAA16561 for ; Thu, 6 Aug 1998 09:39:04 -0500 (CDT) Received: from relay4.smtp.psi.net(38.9.52.2) by cashew.bmc.com via smap (V2.0) id xma016542; Thu, 6 Aug 98 09:38:40 -0500 Received: from [192.152.208.5] (helo=acecomm.com) by relay4.smtp.psi.net with smtp (Exim 1.90 #1) id 0z4RBf-0000pG-00; Thu, 6 Aug 1998 10:38:39 -0400 Received: from bnatale by acecomm.com (5.65/3.2.083191-ACE*COMM) id AA14441; Thu, 6 Aug 1998 10:41:26 -0400 Message-Id: <9808061441.AA14441@acecomm.com> X-Sender: natale@nips.acec.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1 Date: Thu, 06 Aug 1998 10:41:10 -0400 To: Juergen Schoenwaelder From: Bob Natale Subject: Re: Table Indices in AgentX MIB Cc: agentx@peer.com In-Reply-To: <199808061411.QAA25187@henkell.ibr.cs.tu-bs.de> References: <9808051655.AA02660@acecomm.com> <9808051655.AA02660@acecomm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" >At 8/6/98 04:11 PM, Juergen Schoenwaelder wrote: Hi Juergen, <...> >Anyway, we don't have to agree. I have raised my view, you >have raised your view. You are right about that...I think it boils down simply to differing view of the value of assumptions about the uses of a [this] MIB...in the general case [i.e., there are specific MIBs--mostly of the enterprise variety--where I would hold the opposite view], my view favors a MIB design that does not embody [m]any usage assumptions. >Now its up to the WG do make up its mind and to come to a >conclusion. Yes, but for the record, since you proposed the changes some time ago that led to the current MIB text in this respect, it will take substantial support for my proposal to revert to the original design to make that happen. Does not look likely at this point...so, we can probably move on. 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 Thu Aug 6 10:21:27 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id KAA15000 for ; Thu, 6 Aug 1998 10:21:26 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id KAA28466 for ; Thu, 6 Aug 1998 10:20:00 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma028279; Thu, 6 Aug 98 10:19:10 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id KAA13729 for ; Thu, 6 Aug 1998 10:18:34 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma012224; Thu, 6 Aug 98 10:17:12 -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 KAA14986 for ; Thu, 6 Aug 1998 10:17:44 -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 IAA10899 for ; Thu, 6 Aug 1998 08:05:59 -0700 (PDT) Received: (from uucp@localhost) by cashew.bmc.com (8.8.8/8.8.8) id KAA18404 for ; Thu, 6 Aug 1998 10:05:57 -0500 (CDT) Received: from relay4.smtp.psi.net(38.9.52.2) by cashew.bmc.com via smap (V2.0) id xma018391; Thu, 6 Aug 98 10:05:45 -0500 Received: from [192.152.208.5] (helo=acecomm.com) by relay4.smtp.psi.net with smtp (Exim 1.90 #1) id 0z4Rbp-0002uT-00; Thu, 6 Aug 1998 11:05:42 -0400 Received: from bnatale by acecomm.com (5.65/3.2.083191-ACE*COMM) id AA15010; Thu, 6 Aug 1998 11:08:28 -0400 Message-Id: <9808061508.AA15010@acecomm.com> X-Sender: natale@nips.acec.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1 Date: Thu, 06 Aug 1998 11:08:13 -0400 To: Martin Jacobsson From: Bob Natale Subject: Re: open issues in agentX MIB Cc: agentx@peer.com In-Reply-To: References: <199807312343.QAA24395@dorothy.bmc.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" >At 8/5/98 12:15 AM, Martin Jacobsson wrote: Hi Martin, >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. I like your wording...possibly with a change of "solving" to "identifying" (which is, of course, just an early step on the path to solving a problem). I will build on this them in my response to your just slightly earlier posting on the same thread...should follow in a couple of minutes. 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 Thu Aug 6 11:22:10 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id LAA16228 for ; Thu, 6 Aug 1998 11:22:10 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id LAA04517 for ; Thu, 6 Aug 1998 11:20:45 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma004226; Thu, 6 Aug 98 11:19:36 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id LAA13379 for ; Thu, 6 Aug 1998 11:18:59 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma011501; Thu, 6 Aug 98 11:17: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 LAA03383 for ; Thu, 6 Aug 1998 11:17:47 -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 IAA10978 for ; Thu, 6 Aug 1998 08:35:29 -0700 (PDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id KAA00285 for ; Thu, 6 Aug 1998 10:35:27 -0500 (CDT) Received: from relay4.smtp.psi.net(38.9.52.2) by almond.bmc.com via smap (V2.0) id xma000280; Thu, 6 Aug 98 10:35:12 -0500 Received: from [192.152.208.5] (helo=acecomm.com) by relay4.smtp.psi.net with smtp (Exim 1.90 #1) id 0z4S4I-000591-00; Thu, 6 Aug 1998 11:35:06 -0400 Received: from bnatale by acecomm.com (5.65/3.2.083191-ACE*COMM) id AA15664; Thu, 6 Aug 1998 11:37:52 -0400 Message-Id: <9808061537.AA15664@acecomm.com> X-Sender: natale@nips.acec.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1 Date: Thu, 06 Aug 1998 11:37:37 -0400 To: Martin Jacobsson From: Bob Natale Subject: Re: open issues in agentX MIB Cc: agentx@peer.com In-Reply-To: References: <9807312258.AA17629@acecomm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" >At 8/5/98 12:13 AM, Martin Jacobsson wrote: Hi Martin, <...re a possible "agentxResponseTable"...> >... >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. My suggestion applied only to responses issued by the master agent to the subagent...so it only involves the values defined in RFC 2257, not those in RFC 1905 (which are only used by subagents to report "SNMP" processing errors back to the master and can ("would", presumably) therefore get reported at some "higher layer" entity eventually anyway). >Most of these values are normal and don't indicate a problem, >so this would be useless when debugging. I don't know what you mean by the premise there ("normal")... please elaborate. >I propose to add agentxSessionInPackets to the agentxSessionTable >because this will show that there are activity on the session. I do not favor (as you may know from my other posts on recent threads!) adding meta/pseudo data elements to this MIB, when the baseline raw data elements already exist and serve the purpose (at least as well, or better [in my opinion]). >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. Right...I don't think any of the 10 AgentX-specific error codes relate to "parsing" operations. I think this is also true wrt "protocol" errors, but I'm not 100% sure I know how you define that term. >But the number of timeouts is perhaps useful so you can find >out if the timeout values are to small. Maybe...except I believe the spec calls for closing the session (by either end) if and when timeouts so indicate. And I don't favor holding this error info [in this MIB] beyond the life of the session. >But global counters of parse and protocol errors could be useful. That is pretty much always a true statement. The question then becomes "how useful relative to whatever costs may be involved?". For the purposes of this MIB, we have started with the view that "Useful" must be very high and "costs" must be very low. Obviously, in the absence of solid metrics, there's a fair amount of subjectivity involved in assessing any proposal. That, thankfully, is where the wisdom of group consensus show its strength. >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. No, in this case the manager will almost surely know due to the impact on his queries. >(actually it can detect this beacuse the agentxConnIndex becomes very >big, but this is, in my opinion, not a clear indication.) That is true...and (if I recall correctly) we have not yet mandated this this index value begin at 1 and increase monotonically...so, the values may be large at once and sparse to boot. >> >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. I think this issue has been answered sufficiently on the thread that Ashish initiated...do you still feel differently? 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 Thu Aug 6 13:31:10 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id NAA18783 for ; Thu, 6 Aug 1998 13:31:10 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id NAA15219 for ; Thu, 6 Aug 1998 13:29:45 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma014648; Thu, 6 Aug 98 13:27:40 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id NAA05911 for ; Thu, 6 Aug 1998 13:27:05 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma004106; Thu, 6 Aug 98 13:25: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 NAA10400; Thu, 6 Aug 1998 13:25:27 -0500 (CDT) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id LAA12072 for agentx@peer.com; Thu, 6 Aug 1998 11:02:09 -0700 (PDT) Date: Thu, 6 Aug 1998 11:02:09 -0700 (PDT) From: Randy Presuhn Message-Id: <199808061802.LAA12072@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: 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 ... Here's something that's bugged me for quite some time about the agentx protocol definition that this discussion critically depended on: the requirement that session identifiers in protocol be unique not only in the context of a particular connection, but also across all connections across all transports (RFC 2257 page 18). The guidance in clause 6 of RFC 2119 regarding the use of "MUST" makes leads me to believe that this particular aspect of AgentX is over-specified. No rationale is provided explaining why, for purposes of interoperation, there need be a requirement that the scope of uniqueness for session identifiers extend beyond the connection level. As long as the identifiers are unique within a connection, the interoperation requirement is satisfied, unless we start constraining protocol behaviour to support a particular MIB indexing strategy. ----------------------------------------------------------------------- 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 Thu Aug 6 13:37:21 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id NAA18901 for ; Thu, 6 Aug 1998 13:37:21 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id NAA16846 for ; Thu, 6 Aug 1998 13:35:57 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma016141; Thu, 6 Aug 98 13:33:43 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id NAA12505 for ; Thu, 6 Aug 1998 13:33:07 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma010419; Thu, 6 Aug 98 13: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 NAA12096; Thu, 6 Aug 1998 13:31:40 -0500 (CDT) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id LAA12434 for agentx@peer.com; Thu, 6 Aug 1998 11:26:54 -0700 (PDT) Date: Thu, 6 Aug 1998 11:26:54 -0700 (PDT) From: Randy Presuhn Message-Id: <199808061826.LAA12434@dorothy.bmc.com> To: agentx@peer.com Subject: Re: agentxConnTransportAddress Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi - > To: agentx@peer.com > Subject: agentxConnTransportAddress > Date: Wed, 05 Aug 98 09:39:30 -0400 > From: Mike Daniele ... > 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. ... This is probably worth mentioning explicitly in the DESCRIPTION. ----------------------------------------------------------------------- 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 fenner@parc.xerox.com Thu Aug 6 13:51:57 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id NAA19201 for ; Thu, 6 Aug 1998 13:51:57 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id NAA18922 for ; Thu, 6 Aug 1998 13:50:32 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma018644; Thu, 6 Aug 98 13:49:51 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id NAA00228 for ; Thu, 6 Aug 1998 13:49:15 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma028389; Thu, 6 Aug 98 13:47: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 NAA16882; Thu, 6 Aug 1998 13:48:11 -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 LAA12583; Thu, 6 Aug 1998 11:43:22 -0700 (PDT) Received: (from uucp@localhost) by cashew.bmc.com (8.8.8/8.8.8) id NAA04394; Thu, 6 Aug 1998 13:43:20 -0500 (CDT) Received: from omega.xerox.com(13.1.64.95) by cashew.bmc.com via smap (V2.0) id xma004380; Thu, 6 Aug 98 13:43:03 -0500 Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <40656(1)>; Thu, 6 Aug 1998 11:42:57 PDT Received: from localhost by crevenia.parc.xerox.com with SMTP id <177515>; Thu, 6 Aug 1998 11:42:54 -0700 To: Randy Presuhn cc: agentx@dorothy.bmc.com, ops-area@ietf.org Subject: Re: Agentx list dilemma In-reply-to: Your message of "Tue, 04 Aug 98 07:53:42 PDT." <199808041453.HAA14013@dorothy.bmc.com> Date: Thu, 6 Aug 1998 11:42:39 PDT Sender: Bill Fenner From: Bill Fenner Message-Id: <98Aug6.114254pdt.177515@crevenia.parc.xerox.com> In message <199808041453.HAA14013@dorothy.bmc.com> you write: >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 don't know about the others, but PARC just checks the SMTP from "header". If the agentx list were modified to change the SMTP from, as other lists do, to the list owner, then these postings would get through. Here's an example post to the IDMR mailing list that made it into PARC: >(Message idmr:1608) >Return-Path: cs.ucl.ac.uk!owner-idmr >Message-ID: <19980805183438.16320.qmail@hotmail.com> >X-Originating-IP: [207.53.175.75] >From: jaihari loganathan >To: idmr@cs.ucl.ac.uk >Subject: mrouted.. >Date: Wed, 5 Aug 1998 11:34:38 PDT >Sender: owner-idmr@cs.ucl.ac.uk Note that from the Return-Path header, the SMTP FROM must have been "owner-idmr@cs.ucl.ac.uk". Bill From rpresuhn@dorothy.bmc.com Thu Aug 6 14:30:23 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id OAA19601 for ; Thu, 6 Aug 1998 14:30:22 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id OAA23346 for ; Thu, 6 Aug 1998 14:28:58 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma022671; Thu, 6 Aug 98 14:26:44 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id OAA07264 for ; Thu, 6 Aug 1998 14:26:06 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma005943; Thu, 6 Aug 98 14:25: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 OAA28134; Thu, 6 Aug 1998 14:25:21 -0500 (CDT) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id MAA12771 for agentx@peer.com; Thu, 6 Aug 1998 12:13:41 -0700 (PDT) Date: Thu, 6 Aug 1998 12:13:41 -0700 (PDT) From: Randy Presuhn Message-Id: <199808061913.MAA12771@dorothy.bmc.com> To: agentx@peer.com Subject: Re: Dynamic row creation Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi - > From: Aharon Manne > To: agentx@peer.com > Cc: Amit Meyuhas > Subject: Dynamic row creation > Date: Thu, 6 Aug 1998 09:41:37 +0300 ... > According to a discussion I found in the list archives (from April > 98), it is not possible under AgentX to create rows in tables with > multiple indices [tuples, of the form (1,1), (1,2)]. The conclusion > there as I understood it was that one can solve the problem by using one > of the indices, as long as it is unique in the table. In our case, we > could use dot1dStaticAddress as such an index. Be careful to distinguish row creation from index allocation. One does NOT need to do index allocation in order to support row creation. Index allocation is used when subagents don't have any other way to decide which portions of a table they should claim responsibility for. It may make sense for the subagents to claim responsibility for their respective ...*.dot1dStaticAddress.* regions, avoiding index allocation altogether. (It'd take a close look at the MIB to verify this.) ... > When an NMS requests the creation of a new row, the master agent must > choose one of the subagents as being responsible for the given range of > index values (rfc2257, sec. 7.2.1.4(3)) This implies that we should > assign one of the subagents as being responsible for the entire range of > dot1dStaticAddress values. This in turn seems to imply that the table > would be propagated to the other subagents "behind the back" of AgentX, > as it were. This seems to me to defeat the purpose of AgentX, but I > can't think of a better implementation. ... Appointing a "resource manager" to field the row creation requests makes sense IF your environment does not provide a reasonable way to pre-allocate responsibility amongst subagents. (Note that it is prefectly reasonable for subagents to claim responsibility for table regions that don't exist, allowing those subagents to get the row creation request.) Note also that it may make sense for such a resource manager to act in the AgentX master agent role with respect to the resource subagents, though this sort of "cascading" is beyond the scope of what the working group set as its goals. ----------------------------------------------------------------------- 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 sivakumar@cthulhu.engr.sgi.com Thu Aug 6 15:27:27 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id PAA20037 for ; Thu, 6 Aug 1998 15:27:26 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id PAA00555 for ; Thu, 6 Aug 1998 15:26:00 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma029378; Thu, 6 Aug 98 15:22:29 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id PAA01372 for ; Thu, 6 Aug 1998 15:21:52 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma025059; Thu, 6 Aug 98 15:16: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 PAA15232; Thu, 6 Aug 1998 15:16:48 -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 NAA13267 for ; Thu, 6 Aug 1998 13:07:41 -0700 (PDT) Received: (from uucp@localhost) by cashew.bmc.com (8.8.8/8.8.8) id PAA10286 for ; Thu, 6 Aug 1998 15:07:39 -0500 (CDT) Received: from sgi.com(192.48.153.1) by cashew.bmc.com via smap (V2.0) id xma010232; Thu, 6 Aug 98 15:07:28 -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 NAA10146 for <@sgi.engr.sgi.com:agentx@peer.com>; Thu, 6 Aug 1998 13:07:26 -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 NAA02038 for <@cthulhu.engr.sgi.com:agentx@peer.com>; Thu, 6 Aug 1998 13:07:25 -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 NAA21573 for ; Thu, 6 Aug 1998 13:06:44 -0700 (PDT) Sender: sivakumar@cthulhu.engr.sgi.com Message-ID: <35CA0CD3.50D93C14@engr.sgi.com> Date: Thu, 06 Aug 1998 13:06:43 -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 Thu Aug 6 15:27:41 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id PAA20044 for ; Thu, 6 Aug 1998 15:27:40 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id PAA00636 for ; Thu, 6 Aug 1998 15:26:14 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma029473; Thu, 6 Aug 98 15:22:42 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id PAA01688 for ; Thu, 6 Aug 1998 15:22:06 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma025228; Thu, 6 Aug 98 15:16: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 PAA15263; Thu, 6 Aug 1998 15:16:53 -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 NAA13260 for ; Thu, 6 Aug 1998 13:06:53 -0700 (PDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id PAA26301 for ; Thu, 6 Aug 1998 15:06:52 -0500 (CDT) Received: from relay1.smtp.psi.net(38.8.14.2) by almond.bmc.com via smap (V2.0) id xma026297; Thu, 6 Aug 98 15:06:50 -0500 Received: from [192.152.208.5] (helo=acecomm.com) by relay1.smtp.psi.net with smtp (Exim 1.90 #1) id 0z4WJ8-0001bA-00; Thu, 6 Aug 1998 16:06:43 -0400 Received: from ppp1 by acecomm.com (5.65/3.2.083191-ACE*COMM) id AA20539; Thu, 6 Aug 1998 16:09:26 -0400 Message-Id: <9808062009.AA20539@acecomm.com> X-Sender: natale@nips.acec.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1 Date: Thu, 06 Aug 1998 16:08:49 -0400 To: Randy Presuhn From: Bob Natale Subject: Re: Table Indices in AgentX MIB Cc: agentx@peer.com In-Reply-To: <199808061802.LAA12072@dorothy.bmc.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" >At 8/6/98 11:02 AM, Randy Presuhn wrote: Hi Randy, <...> >As long as the identifiers are unique within a connection, the >interoperation requirement is satisfied, I think you are right about that and I would support such a change (our implementation would continue to make them globally unique however). >unless we start constraining protocol behaviour to support a >particular MIB indexing strategy. It certainly does not make sense to do so in this case. Furthermore, if SessionID values can appear multiple times in the agentxSessionTable, distinguished by agentxConnIndex values, then I can (happily) drop my argument against the multi-indexing of that and the agentxRegistrationTable! :-) 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 sgudur@hotmail.com Thu Aug 6 17:06:24 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id RAA20785 for ; Thu, 6 Aug 1998 17:06:23 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id RAA08152 for ; Thu, 6 Aug 1998 17:04:58 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma007756; Thu, 6 Aug 98 17:04:02 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id RAA07690 for ; Thu, 6 Aug 1998 17:03:26 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma005066; Thu, 6 Aug 98 17:01:25 -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 RAA17096; Thu, 6 Aug 1998 17:01:49 -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 OAA13987 for ; Thu, 6 Aug 1998 14:45:18 -0700 (PDT) Received: (from uucp@localhost) by cashew.bmc.com (8.8.8/8.8.8) id QAA16432 for ; Thu, 6 Aug 1998 16:45:16 -0500 (CDT) Received: from f23.hotmail.com(207.82.250.34) by cashew.bmc.com via smap (V2.0) id xma016374; Thu, 6 Aug 98 16:44:48 -0500 Received: (qmail 17573 invoked by uid 0); 6 Aug 1998 21:44:33 -0000 Message-ID: <19980806214433.17572.qmail@hotmail.com> Received: from 152.67.249.57 by www.hotmail.com with HTTP; Thu, 06 Aug 1998 14:44:33 PDT X-Originating-IP: [152.67.249.57] From: "Smitha Gudur" To: sivakumar@cthulhu.engr.sgi.com Cc: agentx@peer.com Subject: Re: MIB Views and AgentX Content-Type: text/plain Date: Thu, 06 Aug 1998 14:44:33 PDT Hi, sivakumar, >From sivakumar@cthulhu.engr.sgi.com Thu Aug 6 13:23:31 1998 >Received: (from uucp@localhost) > by almond.bmc.com (8.8.8/8.8.8) id PAA29287 > for ; Thu, 6 Aug 1998 15:22:17 -0500 (CDT) >Received: from firewall.bmc.com(192.245.162.250) > by almond.bmc.com via smap (V2.0) > id xma028674; Thu, 6 Aug 98 15:20:34 -0500 >Received: (from uucp@localhost) > by dresden.bmc.com (8.8.5/8.8.6) id PAA28992 > for ; Thu, 6 Aug 1998 15:19:58 -0500 (CDT) >Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) > id xma026114; Thu, 6 Aug 98 15:17: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 PAA15213; > Thu, 6 Aug 1998 15:16:43 -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 NAA13267 > for ; Thu, 6 Aug 1998 13:07:41 -0700 (PDT) >Received: (from uucp@localhost) > by cashew.bmc.com (8.8.8/8.8.8) id PAA10286 > for ; Thu, 6 Aug 1998 15:07:39 -0500 (CDT) >Received: from sgi.com(192.48.153.1) > by cashew.bmc.com via smap (V2.0) > id xma010232; Thu, 6 Aug 98 15:07:28 -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 NAA10146 > for <@sgi.engr.sgi.com:agentx@peer.com>; Thu, 6 Aug 1998 13:07:26 -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 NAA02038 > for <@cthulhu.engr.sgi.com:agentx@peer.com>; > Thu, 6 Aug 1998 13:07:25 -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 NAA21573 for ; Thu, 6 Aug 1998 13:06:44 -0700 (PDT) >Sender: sivakumar@cthulhu.engr.sgi.com >Message-ID: <35CA0CD3.50D93C14@engr.sgi.com> >Date: Thu, 06 Aug 1998 13:06:43 -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. Yes. The subagents are ignorant. > >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? > The subagent need not know whether the object A exists in the MIB view or not. It is the responsibility of Master agent to check for this and send the requests to the appropriate subagent(s). I assume you mean write access to object A, so if the setting is not allowed, such a request will not even go to the subagent as access list is checked first by SNMP agent/master agent, and the user or manager will receive an error response. hope this helps. smitha >Any help is appreciated. > >Thanks, >Siva > >-- >Sivakumar Narayanan Silicon Graphics Inc. >Tel# 650 933 5249 (W) Email: sivakumar@engr.sgi.com > > > > ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com From sgudur@hotmail.com Thu Aug 6 17:09:08 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id RAA20814 for ; Thu, 6 Aug 1998 17:09:08 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id RAA09102 for ; Thu, 6 Aug 1998 17:07:44 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma007846; Thu, 6 Aug 98 17:04:15 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id RAA07919 for ; Thu, 6 Aug 1998 17:03:39 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma005069; Thu, 6 Aug 98 17:01:25 -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 RAA17100; Thu, 6 Aug 1998 17:01:49 -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 OAA14144 for ; Thu, 6 Aug 1998 14:49:03 -0700 (PDT) Received: (from uucp@localhost) by cashew.bmc.com (8.8.8/8.8.8) id QAA16672 for ; Thu, 6 Aug 1998 16:49:01 -0500 (CDT) Received: from f239.hotmail.com(207.82.251.130) by cashew.bmc.com via smap (V2.0) id xma016660; Thu, 6 Aug 98 16:48:41 -0500 Received: (qmail 3922 invoked by uid 0); 6 Aug 1998 21:48:32 -0000 Message-ID: <19980806214832.3921.qmail@hotmail.com> Received: from 152.67.249.57 by www.hotmail.com with HTTP; Thu, 06 Aug 1998 14:48:31 PDT X-Originating-IP: [152.67.249.57] From: "Smitha Gudur" To: rpresuhn@dorothy.bmc.com Cc: agentx@peer.com Subject: Re: agentxConnTransportAddress Content-Type: text/plain Date: Thu, 06 Aug 1998 14:48:31 PDT hi, Mike & Randy, >From rpresuhn@dorothy.bmc.com Thu Aug 6 12:24:32 1998 >Received: (from uucp@localhost) > by almond.bmc.com (8.8.8/8.8.8) id NAA16993 > for ; Thu, 6 Aug 1998 13:36:17 -0500 (CDT) >Received: from firewall.bmc.com(192.245.162.250) > by almond.bmc.com via smap (V2.0) > id xma016338; Thu, 6 Aug 98 13:34:08 -0500 >Received: (from uucp@localhost) > by dresden.bmc.com (8.8.5/8.8.6) id NAA13047 > for ; Thu, 6 Aug 1998 13:33:31 -0500 (CDT) >Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) > id xma010861; Thu, 6 Aug 98 13:31:46 -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 NAA12063; > Thu, 6 Aug 1998 13:31:35 -0500 (CDT) >Received: (from rpresuhn@localhost) > by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id LAA12434 > for agentx@peer.com; Thu, 6 Aug 1998 11:26:54 -0700 (PDT) >Date: Thu, 6 Aug 1998 11:26:54 -0700 (PDT) >From: Randy Presuhn >Message-Id: <199808061826.LAA12434@dorothy.bmc.com> >To: agentx@peer.com >Subject: Re: agentxConnTransportAddress >Mime-Version: 1.0 >Content-Type: text/plain; charset=us-ascii >Content-Transfer-Encoding: 7bit > >Hi - > >> To: agentx@peer.com >> Subject: agentxConnTransportAddress >> Date: Wed, 05 Aug 98 09:39:30 -0400 >> From: Mike Daniele >... >> 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. >... > >This is probably worth mentioning explicitly in the DESCRIPTION. I will add this to the description. thanks smitha > > ----------------------------------------------------------------------- > 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 sar@epilogue.com Fri Aug 7 12:15:48 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id MAA29479 for ; Fri, 7 Aug 1998 12:15:46 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id MAA25206 for ; Fri, 7 Aug 1998 12:14:20 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma024141; Fri, 7 Aug 98 12:11:24 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id MAA16654 for ; Fri, 7 Aug 1998 12:10:48 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma013277; Fri, 7 Aug 98 12:08: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 MAA28367; Fri, 7 Aug 1998 12:08:36 -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 JAA22250 for ; Fri, 7 Aug 1998 09:01:05 -0700 (PDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id LAA18089 for ; Fri, 7 Aug 1998 11:01:04 -0500 (CDT) Received: from khitomer.epilogue.com(128.224.1.172) by almond.bmc.com via smap (V2.0) id xma018041; Fri, 7 Aug 98 11:00:53 -0500 From: "Shawn A. Routhier" Sender: sar@khitomer.epilogue.com To: rpresuhn@dorothy.bmc.com CC: agentx@peer.com In-reply-to: <199808050503.WAA19883@dorothy.bmc.com> (message from Randy Presuhn on Tue, 4 Aug 1998 22:03:04 -0700 (PDT)) Subject: Re: open issues in agentX MIB Date: Fri, 7 Aug 98 12:00:46 -0400 Message-ID: <9808071200.aa00935@khitomer.epilogue.com> Date: Tue, 4 Aug 1998 22:03:04 -0700 (PDT) From: Randy Presuhn 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. ;-) I would like to add my support for keeping the mib as minimal as possible. Some people have pointed out that this information may be useful when new sub agents are added to an existing master agent. I have some doubts about this, but may be convinced about it. I have also heard plans to use agentx within a single product as part of modularizing the product. In this case all the debugging should be done by the vendor and the extra mib objects would be wasted. sar From sar@epilogue.com Fri Aug 7 12:15:54 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id MAA29485 for ; Fri, 7 Aug 1998 12:15:53 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id MAA25234 for ; Fri, 7 Aug 1998 12:14:26 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma024220; Fri, 7 Aug 98 12:11:36 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id MAA16894 for ; Fri, 7 Aug 1998 12:10:58 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma013294; Fri, 7 Aug 98 12:08: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 MAA28371; Fri, 7 Aug 1998 12:08:36 -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 JAA25196 for ; Fri, 7 Aug 1998 09:33:47 -0700 (PDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id LAA20448 for ; Fri, 7 Aug 1998 11:33:46 -0500 (CDT) Received: from khitomer.epilogue.com(128.224.1.172) by almond.bmc.com via smap (V2.0) id xma020445; Fri, 7 Aug 98 11:33:24 -0500 From: "Shawn A. Routhier" Sender: sar@khitomer.epilogue.com To: daniele@zk3.dec.com CC: agentx@peer.com In-reply-to: <9808051441.AA22180@bernie.zk3.dec.com> (message from Mike Daniele on Wed, 05 Aug 98 10:41:45 -0400) Subject: Re: some comments on MIB Date: Fri, 7 Aug 98 12:33:23 -0400 Message-ID: <9808071233.aa01225@khitomer.epilogue.com> 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? I would certainly like to see them removed. 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 :-) And what the values mean. As the mib is currently written the last entry doesn't decribe the registration information. The mib states that the values go from a.b.c.d.f to a.b.c.e.f+1 which would include a.b.c.d.f+1 which is not included in the registered region. We also need to decide if a subsection of a registration range can be unregistered and if so if they registration table needs any fixes. As an example if a sub agent registers a.b.c.[d-e].f and then unregisters a.b.c.d.f what should happen? Should the deregistration be allowed and the table updated? or should the deregistration be rejected if it doesn't match a registration request exactly? 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 sar From bnatale@acecomm.com Fri Aug 7 12:16:15 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id MAA29491 for ; Fri, 7 Aug 1998 12:16:15 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id MAA25372 for ; Fri, 7 Aug 1998 12:14:47 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma024278; Fri, 7 Aug 98 12:11:43 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id MAA16991 for ; Fri, 7 Aug 1998 12:11:03 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma013283; Fri, 7 Aug 98 12:08:04 -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 MAA28368; Fri, 7 Aug 1998 12:08:36 -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 KAA28001 for ; Fri, 7 Aug 1998 10:00:51 -0700 (PDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id MAA21864 for ; Fri, 7 Aug 1998 12:00:49 -0500 (CDT) Received: from relay1.smtp.psi.net(38.8.14.2) by almond.bmc.com via smap (V2.0) id xma021840; Fri, 7 Aug 98 12:00:32 -0500 Received: from [192.152.208.5] (helo=acecomm.com) by relay1.smtp.psi.net with smtp (Exim 1.90 #1) id 0z4psT-0006v6-00; Fri, 7 Aug 1998 13:00:29 -0400 Received: from bnatale by acecomm.com (5.65/3.2.083191-ACE*COMM) id AA01132; Fri, 7 Aug 1998 13:03:15 -0400 Message-Id: <9808071703.AA01132@acecomm.com> X-Sender: natale@nips.acec.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1 Date: Fri, 07 Aug 1998 13:02:57 -0400 To: agentx@peer.com From: Bob Natale Subject: AgentX WG Meeting Agenda, 42nd IETF (Chicago) Cc: agenda@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Hi everyone, In putting together the planned agenda for the AgentX WG meeting which appears below, I borrowed heavily from the very impressive format used by Randy for the DISMAN WG meeting. Thanks, Randy! You are invited to participate in all aspects of the meeting, but especially desired are technical presentations in the following areas: - Implementation reports - Interoperability reports - SNMPv3 and AgentX (issues and solutions) - DISMAN and AgentX (issues and solutions) If you can let me know ahead of time that you plan to give a presentation and approx. how much time you will need for it, that would be very helpful (but is not a prerequisite to giving a presentation at the meeting...we'll fit the ad hoc ones in after the pre-announced ones). Also, there's still plenty of time to modify the agenda...so feel free to make any recommendations in that respect too. But I had to get this into the offical agenda today due to some constraints on my schedule in the coming week. Planned Agenda AgentX WG at 42nd IETF (Chicago) Wednesday, August 26, at 1530-1730. 1. Adminstrative matters: 1.1 Selection of minute-taker See http://www.ietf.org/instructions/minutes.html 1.2 Circulation of signup sheet 1.3 Review of Agenda 1.4 Allocation of time 2. Status of current work: 2.1 Current Charter Goals & Milestone dates See http://www.ietf.org/html.charters/agentx-charter.html 2.2 Interoperability reports 2.3 Implementation reports 2.4 AgentX Protocol See ftp://ftp.isi.edu/in-notes/rfc2257.txt 2.5 AgentX MIB See http://www.ietf.org/internet-drafts/draft-ietf-agentx-mib-02.txt 2.6 AgentX API 3. Review of interactions with other Working Groups: 3.1 SNMPv3 issues (forwarded from SNMPv3 WG meeting on Monday) 3.2 DISMAN issues (forwarded to DISMAN WG meeting on Thursday) 4. Charter updates: See 2.1, above 4.1 Completed items 4.2 Changes to target dates 4.3 Possibile modifications to charter: 4.3.1 API 4.3.2 SNMPv3 4.3.3 DISMAN 5. Technical presentations: See http://www.ietf.org/instructions/slides.html 5.1 Open topics for presentations 5.2 Open topics for discussion 6. Wrap-up: 6.1 Summary 6.2 Action items 6.3 reminders to minute-takers and presenters 6.4 retrieval of sign-up sheet - - - - - - - - - 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 Aug 7 13:11:48 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id NAA29979 for ; Fri, 7 Aug 1998 13:11:47 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id NAA00362 for ; Fri, 7 Aug 1998 13:10:22 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma000028; Fri, 7 Aug 98 13:09:13 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id NAA11547 for ; Fri, 7 Aug 1998 13:08:36 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma009806; Fri, 7 Aug 98 13:07: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 NAA15981; Fri, 7 Aug 1998 13:07:35 -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 KAA03669 for ; Fri, 7 Aug 1998 10:56:20 -0700 (PDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id MAA28721 for ; Fri, 7 Aug 1998 12:56:19 -0500 (CDT) Received: from relay1.smtp.psi.net(38.8.14.2) by almond.bmc.com via smap (V2.0) id xma028719; Fri, 7 Aug 98 12:56:03 -0500 Received: from [192.152.208.5] (helo=acecomm.com) by relay1.smtp.psi.net with smtp (Exim 1.90 #1) id 0z4qkD-00068N-00; Fri, 7 Aug 1998 13:56:02 -0400 Received: from bnatale by acecomm.com (5.65/3.2.083191-ACE*COMM) id AA02044; Fri, 7 Aug 1998 13:58:49 -0400 Message-Id: <9808071758.AA02044@acecomm.com> X-Sender: natale@nips.acec.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1 Date: Fri, 07 Aug 1998 13:58:31 -0400 To: "Shawn A. Routhier" From: Bob Natale Subject: AgentX Registration/Deregistration Cc: agentx@peer.com In-Reply-To: <9808071233.aa01225@khitomer.epilogue.com> References: <9808051441.AA22180@bernie.zk3.dec.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" >At 8/7/98 12:33 PM, Shawn A. Routhier wrote: >Subject: Re: some comments on MIB Hi Shawn, <...> > 3) agentxRegStart and agentxRegEnd <...> >And what the values mean. As the mib is currently written >the last entry doesn't decribe the registration information. >The mib states that the values go from a.b.c.d.f to a.b.c.e.f+1 >which would include a.b.c.d.f+1 which is not included in the >registered region. Right...I *think* that was the original idea...to identify the "outside boundary" of the region...it seems to me like a good way of saying "you want <...>.f, you get <...>.f.<...> up to, but not including <...>.g (modulo of course any valid overlapping, non-duplicate, other registrations within the <...>.f.<...> range, subject to priority rankings)". Which, if I've got tha right, makes the little "+1" quite an efficient artifact. >We also need to decide if a subsection of a registration range >can be unregistered and if so if they registration table needs >any fixes. As an example if a sub agent registers a.b.c.[d-e].f >and then unregisters a.b.c.d.f what should happen? Should the >deregistration be allowed and the table updated? or should the >deregistration be rejected if it doesn't match a registration >request exactly? It MUST be rejected, per the u.region test in RFC 2257 Sec. 7.1.6, Processing the agentx-Unregister-PDU: "4) If u.region, u.priority, and the indicated context do not match an existing registration made during this session, the agentx- Response-PDU is returned with res.error set to 'unknownRegistration'." 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 sar@epilogue.com Fri Aug 7 16:26:49 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id QAA01622 for ; Fri, 7 Aug 1998 16:26:48 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id QAA11708 for ; Fri, 7 Aug 1998 16:25:21 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma011191; Fri, 7 Aug 98 16:24:03 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id QAA18930 for ; Fri, 7 Aug 1998 16:23:27 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma017884; Fri, 7 Aug 98 16:22: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 QAA16730; Fri, 7 Aug 1998 16:23: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 OAA03418 for ; Fri, 7 Aug 1998 14:01:09 -0700 (PDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id QAA09603 for ; Fri, 7 Aug 1998 16:01:07 -0500 (CDT) Received: from khitomer.epilogue.com(128.224.1.172) by almond.bmc.com via smap (V2.0) id xma009568; Fri, 7 Aug 98 16:00:54 -0500 From: "Shawn A. Routhier" Sender: sar@khitomer.epilogue.com To: bnatale@acecomm.com CC: agentx@peer.com In-reply-to: <9808071758.AA02044@acecomm.com> (message from Bob Natale on Fri, 07 Aug 1998 13:58:31 -0400) Subject: Re: AgentX Registration/Deregistration Date: Fri, 7 Aug 98 16:59:48 -0400 Message-ID: <9808071659.aa05715@khitomer.epilogue.com> X-Sender: natale@nips.acec.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1 Date: Fri, 07 Aug 1998 13:58:31 -0400 From: Bob Natale Cc: agentx@peer.com References: <9808051441.AA22180@bernie.zk3.dec.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" >At 8/7/98 12:33 PM, Shawn A. Routhier wrote: >Subject: Re: some comments on MIB Hi Shawn, <...> > 3) agentxRegStart and agentxRegEnd <...> >And what the values mean. As the mib is currently written >the last entry doesn't decribe the registration information. >The mib states that the values go from a.b.c.d.f to a.b.c.e.f+1 >which would include a.b.c.d.f+1 which is not included in the >registered region. Right...I *think* that was the original idea...to identify the "outside boundary" of the region...it seems to me like a good way of saying "you want <...>.f, you get <...>.f.<...> up to, but not including <...>.g (modulo of course any valid overlapping, non-duplicate, other registrations within the <...>.f.<...> range, subject to priority rankings)". Which, if I've got tha right, makes the little "+1" quite an efficient artifact. I think, but am not sure, that you missed my point. The words in the current draft "...implements objects starting at this value" (agentxRegStart) and "...implements objects up to but not including this value" (agentxRegEnd) cover all of the objects from the first to the last even if the registration request had holes in it due to specifying objectids after the range. For a concrete example, assume a sub agent registers ifentry.{1--22}.1, the above words would also imply that the range covers ifentry.1.2, ifentry.1.3 etc. I don't think that's what we want. I don't believe we need to change the objects in the mib, only the wording of the description to make it clear which elements are included in a range. I also think the concept of having a scheme that won't work correctly for certain values of subids (2^^32-1) is suspect and would prefer to see some other option. >We also need to decide if a subsection of a registration range >can be unregistered and if so if they registration table needs >any fixes. As an example if a sub agent registers a.b.c.[d-e].f >and then unregisters a.b.c.d.f what should happen? Should the >deregistration be allowed and the table updated? or should the >deregistration be rejected if it doesn't match a registration >request exactly? It MUST be rejected, per the u.region test in RFC 2257 Sec. 7.1.6, Processing the agentx-Unregister-PDU: "4) If u.region, u.priority, and the indicated context do not match an existing registration made during this session, the agentx- Response-PDU is returned with res.error set to 'unknownRegistration'." I think there are different ways of reading that. When registering, a request that has a range included may be viewed as either a single blob or a range of regions to register. You are taking the former view. I do not believe the current wording prohibits the latter view. In the latter case if u.region was one of the regions registered then it would be valid to unregister it. Note that u.region would be matched against r.region and that the range information is NOT carried in the *.region fields. sar From bnatale@acecomm.com Fri Aug 7 17:23:11 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id RAA02064 for ; Fri, 7 Aug 1998 17:23:11 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id RAA16081 for ; Fri, 7 Aug 1998 17:21:44 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma015506; Fri, 7 Aug 98 17:20:15 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id RAA06019 for ; Fri, 7 Aug 1998 17:19:40 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma004962; Fri, 7 Aug 98 17:18:46 -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 RAA02781; Fri, 7 Aug 1998 17:19: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 PAA10952 for ; Fri, 7 Aug 1998 15:06:37 -0700 (PDT) Received: (from uucp@localhost) by cashew.bmc.com (8.8.8/8.8.8) id RAA17108 for ; Fri, 7 Aug 1998 17:06:35 -0500 (CDT) Received: from relay4.smtp.psi.net(38.9.52.2) by cashew.bmc.com via smap (V2.0) id xma017101; Fri, 7 Aug 98 17:06:25 -0500 Received: from [192.152.208.5] (helo=acecomm.com) by relay4.smtp.psi.net with smtp (Exim 1.90 #1) id 0z4ueS-00004W-00; Fri, 7 Aug 1998 18:06:20 -0400 Received: from bnatale by acecomm.com (5.65/3.2.083191-ACE*COMM) id AA06108; Fri, 7 Aug 1998 18:09:03 -0400 Message-Id: <9808072209.AA06108@acecomm.com> X-Sender: natale@nips.acec.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1 Date: Fri, 07 Aug 1998 18:08:45 -0400 To: "Shawn A. Routhier" From: Bob Natale Subject: Re: AgentX Registration/Deregistration Cc: agentx@peer.com In-Reply-To: <9808071659.aa05715@khitomer.epilogue.com> References: <9808071758.AA02044@acecomm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" >At 8/7/98 04:59 PM, Shawn A. Routhier wrote: Hi Shawn, <...> >I think, but am not sure, that you missed my point. Perhaps...if so, I apologize. (Trying to get a bunch of things done before heading out for a week's worth of vacation! :-) >The words in the current draft "...implements objects >starting at this value" (agentxRegStart) and "...implements >objects up to but not including this value" (agentxRegEnd) >cover all of the objects from the first to the last even if >the registration request had holes in it due to specifying >objectids after the range. For a concrete example, assume >a sub agent registers ifentry.{1--22}.1, the above words >would also imply that the range covers ifentry.1.2, >ifentry.1.3 etc. Hmmm. I failed to make that interpretation of those words...and still do. I believe the various descriptions we give of such range registrations include a phrase like "for example, to register an entire row in some table".... >I don't think that's what we want. Right...but I think I've just seen the possible source of the different readings you and I are making. I read (into it, perhaps) that the INSTANCE_REGISTRATION bit was set on the associated agentx-Register-PDU operation and, therefore, I use the .22 subid as the one to increment and my agentxRegEnd value becomes ifEntry.23[.1]. That is, I treat the instance part as a logical suffix not as part of the ending object name itself. >I don't believe we need to change the objects in the mib, >only the wording of the description to make it clear which >elements are included in a range. Ok...if I'm right about the source of our different readings, then I think we need to change both the MIB description text, as you say, and perhaps add some clarifying text to RFC 2257, Section 6.2.3, "The agentx-Register-PDU", as (I think) might have been recommended by someone else earlier (this concerns "The master agent may save this information to optimize subsequent operational dispatching."). If you have any candidate text for either place, please post it. >I also think the concept of having a scheme that won't work >correctly for certain values of subids (2^^32-1) is suspect >and would prefer to see some other option. In general, I agree with you (I think I noted this in an earlier posting [but might have opted to leave it out for some wrong reasons!]). However, it's not really "certain values"; it's only one value it's not unheard of to allow for "special processing" on a single boundary value. Granted, again, it's not the most beautiful way in the world to do it. > It MUST be rejected, per the u.region test in RFC 2257 Sec. 7.1.6, > Processing the agentx-Unregister-PDU: > > "4) If u.region, u.priority, and the indicated context do not match > an existing registration made during this session, the agentx- > Response-PDU is returned with res.error set to > 'unknownRegistration'." > >I think there are different ways of reading that. When registering, >a request that has a range included may be viewed as either a single >blob or a range of regions to register. You are taking the former >view. I do not believe the current wording prohibits the latter view. >In the latter case if u.region was one of the regions registered then >it would be valid to unregister it. Note that u.region would be >matched against r.region and that the range information is NOT carried >in the *.region fields. Literally true...but the range info is carried in the PDU with the *.region info in both cases and is a virtual extension of those fields. I wouldn't mind adding more clarifying text [and I hope you will propose what you think will work best], but I would not like to have the meaning changed to allow for such "subset" deregistrations. 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 Aug 7 17:35:30 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id RAA02159 for ; Fri, 7 Aug 1998 17:35:29 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id RAA18307 for ; Fri, 7 Aug 1998 17:34:03 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma017732; Fri, 7 Aug 98 17:32:01 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id RAA15554 for ; Fri, 7 Aug 1998 17:31:19 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma013850; Fri, 7 Aug 98 17:29:43 -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 RAA05560; Fri, 7 Aug 1998 17:30:16 -0500 (CDT) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id PAA13736 for agentx@peer.com; Fri, 7 Aug 1998 15:25:35 -0700 (PDT) Date: Fri, 7 Aug 1998 15:25:35 -0700 (PDT) From: Randy Presuhn Message-Id: <199808072225.PAA13736@dorothy.bmc.com> To: agentx@peer.com Subject: Re: some comments on MIB Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi - > From: "Shawn A. Routhier" > To: daniele@zk3.dec.com > CC: agentx@peer.com > Subject: Re: some comments on MIB > Date: Fri, 7 Aug 98 12:33:23 -0400 ... > We also need to decide if a subsection of a registration range > can be unregistered and if so if they registration table needs > any fixes. As an example if a sub agent registers a.b.c.[d-e].f > and then unregisters a.b.c.d.f what should happen? Should the > deregistration be allowed and the table updated? or should the > deregistration be rejected if it doesn't match a registration > request exactly? I think there was agreement at one time that deregistration requests had to match registration requests exactly. It keeps things simple. ----------------------------------------------------------------------- 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 Fri Aug 7 17:52:54 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id RAA02304 for ; Fri, 7 Aug 1998 17:52:54 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id RAA20298 for ; Fri, 7 Aug 1998 17:51:26 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma019489; Fri, 7 Aug 98 17:48:41 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id RAA25433 for ; Fri, 7 Aug 1998 17:48:04 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma023975; Fri, 7 Aug 98 17:46: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 RAA09857; Fri, 7 Aug 1998 17:47:10 -0500 (CDT) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id PAA15789 for agentx@peer.com; Fri, 7 Aug 1998 15:42:33 -0700 (PDT) Date: Fri, 7 Aug 1998 15:42:33 -0700 (PDT) From: Randy Presuhn Message-Id: <199808072242.PAA15789@dorothy.bmc.com> To: agentx@peer.com Subject: Re: AgentX Registration/Deregistration Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi - > From sar@epilogue.com Fri Aug 7 14:22:57 PDT 1998 > From: "Shawn A. Routhier" > To: bnatale@acecomm.com > CC: agentx@peer.com > Subject: Re: AgentX Registration/Deregistration > Date: Fri, 7 Aug 98 16:59:48 -0400 ... > Date: Fri, 07 Aug 1998 13:58:31 -0400 > From: Bob Natale > Cc: agentx@peer.com ... > I think, but am not sure, that you missed my point. The words in > the current draft > "...implements objects starting at this value" (agentxRegStart) and > "...implements objects up to but not including this value" (agentxRegEnd) > cover all of the objects from the first to the last even if the > registration request had holes in it due to specifying objectids > after the range. For a concrete example, assume a sub agent > registers ifentry.{1--22}.1, the above words would also imply > that the range covers ifentry.1.2, ifentry.1.3 etc. I don't > think that's what we want. I don't believe we need to change > the objects in the mib, only the wording of the description to > make it clear which elements are included in a range. > > I also think the concept of having a scheme that won't work correctly > for certain values of subids (2^^32-1) is suspect and would prefer > to see some other option. I agree that it would be nice to have a representation that more accurately reflected what was going on. Mapping the ad-hoc encoding from AgentX protocol back into object identifiers doesn't seem like the right thing to do. I'd be happier with an encoding that matched the semantics of what the protocol carries. Three straw-person proposals: 1) represent it as dotted decimal strings with [low-high] for ranged elements, e.g.: 1.3.5.7.9.[11-13].15 2) pack the stuff into some ad hoc binary octet string 3) Break it into multiple objects, corresponding to the protocol elments > >We also need to decide if a subsection of a registration range > >can be unregistered and if so if they registration table needs > >any fixes. As an example if a sub agent registers a.b.c.[d-e].f > >and then unregisters a.b.c.d.f what should happen? Should the > >deregistration be allowed and the table updated? or should the > >deregistration be rejected if it doesn't match a registration > >request exactly? > > It MUST be rejected, per the u.region test in RFC 2257 Sec. 7.1.6, > Processing the agentx-Unregister-PDU: > > "4) If u.region, u.priority, and the indicated context do not match > an existing registration made during this session, the agentx- > Response-PDU is returned with res.error set to > 'unknownRegistration'." > > I think there are different ways of reading that. When registering, > a request that has a range included may be viewed as either a single > blob or a range of regions to register. You are taking the former > view. I do not believe the current wording prohibits the latter view. > In the latter case if u.region was one of the regions registered then > it would be valid to unregister it. Note that u.region would be > matched against r.region and that the range information is NOT carried > in the *.region fields. ... We need to tighten up the wording in 2257. Perhaps it would be useful to separate the concept of the specification of a region from the region itself. I think this is a good example of how the "tutorial" material on "splitting" regions is somewhat problematic, in that it currently tends to obscure this distinction. ----------------------------------------------------------------------- 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 jplee@knight.ce.kyungpook.ac.kr Sun Aug 9 07:16:37 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id HAA12821 for ; Sun, 9 Aug 1998 07:16:37 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id HAA06930 for ; Sun, 9 Aug 1998 07:15:07 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma006624; Sun, 9 Aug 98 07:14:20 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id HAA07681 for ; Sun, 9 Aug 1998 07:13:24 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma006941; Sun, 9 Aug 98 07:12: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 HAA28801; Sun, 9 Aug 1998 07:13: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 DAA18224 for ; Sun, 9 Aug 1998 03:57:58 -0700 (PDT) Received: (from uucp@localhost) by cashew.bmc.com (8.8.8/8.8.8) id FAA01878 for ; Sun, 9 Aug 1998 05:57:57 -0500 (CDT) Received: from knight.ce.kyungpook.ac.kr(155.230.28.208) by cashew.bmc.com via smap (V2.0) id xma001874; Sun, 9 Aug 98 05:57:47 -0500 Received: from knight.ce.kyungpook.ac.kr by knight.ce.kyungpook.ac.kr (SMI-8.6/SMI-SVR4) id TAA17087; Sun, 9 Aug 1998 19:55:26 +0900 Message-ID: <35CD7FB6.772CB8FF@knight.ce.kyungpook.ac.kr> Date: Sun, 09 Aug 1998 19:53:43 +0900 From: Jongphil Organization: Kyungpook National University. X-Mailer: Mozilla 4.05 [en] (WinNT; I) MIME-Version: 1.0 To: agentx@peer.com Subject: Help me References: <199808072242.PAA15789@dorothy.bmc.com> Content-Type: multipart/mixed; boundary="------------3CB3744B9661DECAE0B7BD49" This is a multi-part message in MIME format. --------------3CB3744B9661DECAE0B7BD49 Content-Type: text/plain; charset=iso-2022-kr Content-Transfer-Encoding: 7bit Hello. My name is jongphil,lee. I am from south of korea. I major in Computer Engineering in Master course. I am interested in Network management, specially i want to make my own Agent. But i am beginner about Network managemnet. And, I don't know How i make it. If you have a sample code about Agent or programmer's guide about Agent, Please send me it... Thank you for reading my letter. Good luck. from jongphil --------------3CB3744B9661DECAE0B7BD49 Content-Type: text/x-vcard; charset=iso-2022-kr; name="vcard.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Jongphil Lee Content-Disposition: attachment; filename="vcard.vcf" begin: vcard fn: Jongphil Lee n: Lee;Jongphil org: Internet Lab. Kyungpook National University adr: 1370 Sankyuk-dong Puk-gu Taegu ;;;;;702-701;R.O.Korea email;internet: jplee@knight.ce.kyungpook.ac.kr title: Master Course tel;work: +82-53-950-5551 tel;home: +82-53-558-3242 note: I love Smile.
Because Smile make me happy.
Always Smile
homepage : http://knight.ce.kyungpook.ac.kr/~jplee
Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id LAA25959 for ; Mon, 10 Aug 1998 11:34:36 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id LAA28275 for ; Mon, 10 Aug 1998 11:33:04 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma027019; Mon, 10 Aug 98 11:29:19 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id LAA28735 for ; Mon, 10 Aug 1998 11:28:06 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma027165; Mon, 10 Aug 98 11:27: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 LAA10073; Mon, 10 Aug 1998 11:27:38 -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 IAA05503 for ; Mon, 10 Aug 1998 08:10:31 -0700 (PDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id KAA20122 for ; Mon, 10 Aug 1998 10:10:19 -0500 (CDT) Received: from mail13.digital.com(192.208.46.30) by almond.bmc.com via smap (V2.0) id xma020110; Mon, 10 Aug 98 10:10:14 -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 LAA02442; Mon, 10 Aug 1998 11:10:03 -0400 (EDT) Received: from bernie.zk3.dec.com by quarry.zk3.dec.com; (5.65v4.0/1.1.8.2/16Jan95-0946AM) id AA21309; Mon, 10 Aug 1998 11:10:02 -0400 Received: from localhost by bernie.zk3.dec.com; (5.65/1.1.8.2/22Aug96-1117AM) id AA23583; Mon, 10 Aug 1998 11:10:05 -0400 Message-Id: <9808101510.AA23583@bernie.zk3.dec.com> To: Bob Natale Cc: agentx@peer.com Subject: Re: AgentX Bake-Off Test Report In-Reply-To: Your message of "Wed, 05 Aug 98 17:13:16 EDT." <9808052113.AA06934@acecomm.com> Date: Mon, 10 Aug 98 11:10:05 -0400 From: Mike Daniele X-Mts: smtp Hi Bob, Good job, thanks. The embedded tabs cause this in my mail: COMPANY PEOPLE MA MIB SA OS ------- ------ -- --- -- -- ACE*COMM Bob Natale(1) Yes .02 No NT ... Compaq/DEC Mike Daniele(2) Yes No Yes UNIX As a result, at first i read this as we didn't have a subagent. > RFC 2257 precludes this scenario (see Sec. 7.2.1.2, > steps (1)b) and (5)). However, for this to work > properly the master agent probably must have saved > the INSTANCE_REGISTRATION flag. The handling of > this flag bit (on registrations) is currently left > to the discretion of the master agent "to optimize > subsequent processing"...we should probably change > the wording to point out that having access to this > flag bit's value is necessary for correct operation > of certain AgentX functions. In general, testing > in this area showed that tighter wording may be > necessary. I don't think INSTANCE_REGISTRATION matters in this issue, and it certainly isn't required for this to work. Regards, Mike From daniele@zk3.dec.com Mon Aug 10 11:34:53 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id LAA25965 for ; Mon, 10 Aug 1998 11:34:53 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id LAA28374 for ; Mon, 10 Aug 1998 11:33:21 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma027062; Mon, 10 Aug 98 11:29:25 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id LAA29484 for ; Mon, 10 Aug 1998 11:28:47 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma027197; Mon, 10 Aug 98 11:27: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 LAA10099; Mon, 10 Aug 1998 11:27:41 -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 IAA06705 for ; Mon, 10 Aug 1998 08:48:19 -0700 (PDT) Received: (from uucp@localhost) by cashew.bmc.com (8.8.8/8.8.8) id KAA14630 for ; Mon, 10 Aug 1998 10:48:17 -0500 (CDT) Received: from mail13.digital.com(192.208.46.30) by cashew.bmc.com via smap (V2.0) id xma014570; Mon, 10 Aug 98 10:48:05 -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 LAA18871; Mon, 10 Aug 1998 11:48:03 -0400 (EDT) Received: from bernie.zk3.dec.com by quarry.zk3.dec.com; (5.65v4.0/1.1.8.2/16Jan95-0946AM) id AA28657; Mon, 10 Aug 1998 11:48:02 -0400 Received: from localhost by bernie.zk3.dec.com; (5.65/1.1.8.2/22Aug96-1117AM) id AA23747; Mon, 10 Aug 1998 11:48:16 -0400 Message-Id: <9808101548.AA23747@bernie.zk3.dec.com> To: Randy Presuhn Cc: agentx@peer.com Subject: Re: Table Indices in AgentX MIB In-Reply-To: Your message of "Thu, 06 Aug 98 11:02:09 PDT." <199808061802.LAA12072@dorothy.bmc.com> Date: Mon, 10 Aug 98 11:48:16 -0400 From: Mike Daniele X-Mts: smtp Hi Randy, >Here's something that's bugged me for quite some time about the agentx >protocol definition that this discussion critically depended on: the >requirement that session identifiers in protocol be unique not only in >the context of a particular connection, but also across all connections >across all transports (RFC 2257 page 18). >The guidance in clause 6 of RFC 2119 regarding the use of "MUST" >makes leads me to believe that this particular aspect of AgentX is >over-specified. No rationale is provided explaining why, for purposes of >interoperation, there need be a requirement that the scope of uniqueness >for session identifiers extend beyond the connection level. The reason we did this is because it was specifically requested by members of the workgroup. I agree with you that "for purposes of interoperation" one needs only uniqueness per connection. But the request was for agent-wide uniqueness to make it possible for implementations to use session ids only in their "upper layers", and let lower layers be concerned with connections, etc. Since it didn't seem to add any real complexity, and we had a specific requests to do so, and we didn't have any requests not to, we did. I happen to think it makes good protocol sense, but your mileage may obviously vary :-). >As long as the identifiers are unique within a connection, the >interoperation requirement is satisfied, unless we start constraining >protocol behaviour to support a particular MIB indexing strategy. No, the protocol was specified that way for reasons mentioned above, not to provide a MIB index. But since we have these semantics for SessionID, it seems a waste not to use it for a MIB index. It alls works nicely together. Would you like to see text added about why this "across all connections" uniqueness was chosen? Regards, Mike From daniele@zk3.dec.com Mon Aug 10 12:06:22 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id MAA26216 for ; Mon, 10 Aug 1998 12:06:21 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id MAA00816 for ; Mon, 10 Aug 1998 12:04:48 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma000220; Mon, 10 Aug 98 12:02:55 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id MAA00456 for ; Mon, 10 Aug 1998 12:02:18 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma028798; Mon, 10 Aug 98 12:01: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 MAA07830; Mon, 10 Aug 1998 12:01:33 -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 JAA10058 for ; Mon, 10 Aug 1998 09:51:57 -0700 (PDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id LAA29272 for ; Mon, 10 Aug 1998 11:51:56 -0500 (CDT) Received: from mail11.digital.com(192.208.46.10) by almond.bmc.com via smap (V2.0) id xma029270; Mon, 10 Aug 98 11:51:51 -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 MAA21679; Mon, 10 Aug 1998 12:51:43 -0400 (EDT) Received: from bernie.zk3.dec.com by quarry.zk3.dec.com; (5.65v4.0/1.1.8.2/16Jan95-0946AM) id AA13637; Mon, 10 Aug 1998 12:51:42 -0400 Received: from localhost by bernie.zk3.dec.com; (5.65/1.1.8.2/22Aug96-1117AM) id AA23824; Mon, 10 Aug 1998 12:51:57 -0400 Message-Id: <9808101651.AA23824@bernie.zk3.dec.com> To: Aharon Manne Cc: agentx@peer.com Subject: Re: Dynamic row creation In-Reply-To: Your message of "Thu, 06 Aug 98 09:41:37 +0300." <004246117607D21188470060089C61BB105EEC@christin.ornet.co.il> Date: Mon, 10 Aug 98 12:51:56 -0400 From: Mike Daniele X-Mts: smtp Hi, > According to a discussion I found in the list archives (from April >98), it is not possible under AgentX to create rows in tables with >multiple indices [tuples, of the form (1,1), (1,2)]. Well, no. As Randy pointed out, that discussion was specific to allocating random indexes. >In this situation, I would like to understand how to create an >entry in the dot1dStaticTable of rfc1493, or in the dot1qStaticTable of >the proposed new version of the bridge MIB. The former is indexed by >{dot1dStaticAddress, dot1dStaticReceivePort}. OK. > In our case, the desired result is that all the elements of the stack >hold identical copies of the dot1dStaticTable (the fact that the >hardware will interpret them differently depending on whether a given >ifIndex is local or not is an implementation issue). ... >This in turn seems to imply that the table >would be propagated to the other subagents "behind the back" of AgentX, >as it were. This seems to me to defeat the purpose of AgentX, but I >can't think of a better implementation. So one module actually contains the conceptual row objects, but all modules "know" about it? Yes, that propogation seems like it would happen "out of band". I don't think anything out there, AgentX or not, has a master agent that "advertises" what instances are implemented by what subagents. (I could be wrong, just haven't heard of it.) The main purpose of AgentX is to provide a mechanism for independantly developed subagents and master agents to interoperate. It sounds like you'll own the whole agent? >As I understand >AgentX, row creation is a function of the subagent, not the master. Yes. >When an NMS requests the creation of a new row, the master agent must >choose one of the subagents as being responsible for the given range of >index values (rfc2257, sec. 7.2.1.4(3)) This implies that we should >assign one of the subagents as being responsible for the entire range of >dot1dStaticAddress values. In order for an AgentX master agent to deliver the Set request, something must have registered a region that contains those variable names. One subagent could register dot1dStaticTable. Or each subagent could register a subset of that, etc. I'm still not clear on exactly what is a subagent in your scenario, how rows of the table really will be implemented, etc. Regards, Mike From daniele@zk3.dec.com Mon Aug 10 14:38:00 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id OAA27420 for ; Mon, 10 Aug 1998 14:38:00 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id OAA14790 for ; Mon, 10 Aug 1998 14:36:27 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma014294; Mon, 10 Aug 98 14:34:51 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id OAA02592 for ; Mon, 10 Aug 1998 14:34:15 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma001043; Mon, 10 Aug 98 14:33:04 -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 OAA20478; Mon, 10 Aug 1998 14:33:38 -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 MAA21001 for ; Mon, 10 Aug 1998 12:16:04 -0700 (PDT) Received: (from uucp@localhost) by cashew.bmc.com (8.8.8/8.8.8) id OAA27626 for ; Mon, 10 Aug 1998 14:16:02 -0500 (CDT) Received: from mail11.digital.com(192.208.46.10) by cashew.bmc.com via smap (V2.0) id xma027611; Mon, 10 Aug 98 14:15:34 -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 PAA22352; Mon, 10 Aug 1998 15:15:33 -0400 (EDT) Received: from bernie.zk3.dec.com by quarry.zk3.dec.com; (5.65v4.0/1.1.8.2/16Jan95-0946AM) id AA03357; Mon, 10 Aug 1998 15:15:32 -0400 Received: from localhost by bernie.zk3.dec.com; (5.65/1.1.8.2/22Aug96-1117AM) id AA23991; Mon, 10 Aug 1998 15:15:46 -0400 Message-Id: <9808101915.AA23991@bernie.zk3.dec.com> To: snmpv3@tis.com Cc: agentx@peer.com Subject: proposal for iana address mib Date: Mon, 10 Aug 98 15:15:46 -0400 From: Mike Daniele X-Mts: smtp Hi, Some of the issues with respect to TDomain and TAddress that have come up are o need new one for snmp over udp over ipv6 in RFC 1906 o need several new ones for AgentX MIB o progress within snmpv3 wg on updating 1906, 1903, etc has been glacial Out of ensuing discussions/complaints, the suggestion was made that we have a single MIB module that defines addressing information. It could be maintained by IANA, updated more easily than say 1906, and be more widely useable than the SNMP-specific definitions in 1906. Attached please find such a module. This specific work hasn't been requested by any WG chair, but I'm hoping it will be considered as a mechanism to get us moving, and provide a more generally useable solution. I missed the 7-Aug deadline for submission of i-ds, got a reply that my mail would be tossed, so I'm posting it on the lists. Sorry about that... Regards, Mike ======== Internet-Draft IANA Address MIB August 1998 Expires February, 1999 IANA Address MIB Mike Daniele Compaq Computer Corporation Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." To view the entire list of current Internet-Drafts, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). 1. Abstract This document contains an initial version of a MIB module for commonly used network addressing information. It defines a registry for identifiers that identify protocols and a set of textual conventions for representing addresses. This document also establishes IANA as the maintainer of this registry. 2. The SNMP Management Framework The SNMP Management Framework presently consists of five major components: o An overall architecture, described in RFC 2271 [1]. o Mechanisms for describing and naming objects and events for the purpose of management. The first version of this Structure of Management Information (SMI) is called SMIv1 and described in RFC 1155 [2], RFC 1212 [3] and RFC 1215 [4]. The second version, called SMIv2, is described in RFC 1902 [5], RFC 1903 [6] and RFC 1904 [7]. o Message protocols for transferring management information. The first version of the SNMP message protocol is called SNMPv1 and described in RFC 1157 [8]. A second version of the SNMP message protocol, which is not an Internet standards track protocol, is called SNMPv2c and described in RFC 1901 [9] and RFC 1906 [10]. The third version of the message protocol is called SNMPv3 and described in RFC 1906 [10], RFC 2272 [11] and RFC 2274 [12]. o Protocol operations for accessing management information. The first set of protocol operations and associated PDU formats is described in RFC 1157 [8]. A second set of protocol operations and associated PDU formats is described in RFC 1905 [13]. o A set of fundamental applications described in RFC 2273 [14] and the view-based access control mechanism described in RFC 2275 [15]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. Objects in the MIB are defined using the mechanisms defined in the SMI. This memo specifies a MIB module that is compliant to the SMIv2. A MIB conforming to the SMIv1 can be produced through the appropriate translations. The resulting translated MIB must be semantically equivalent, except where objects or events are omitted because no translation is possible (use of Counter64). Some machine readable information in SMIv2 will be converted into textual descriptions in SMIv1 during the translation process. However, this loss of machine readable information is not considered to change the semantics of the MIB. 3. Overview This MIB module contains definitions for commonly used network addressing information. In particular, it defines a registry of OBJECT-IDENTIFIERs for protocols, and a set of textual conventions for representing endpoints. The former are intended to be widely used as values for OBJECT-TYPES whose syntax is TDomain, the latter as values for OBJECT-TYPES whose syntax is TAddress. The purpose of this memo is to provide a single, well-known repository for address-related information. Further, this module establishes IANA as the maintainer of these definitions (see section 5). Without such a repository, each MIB module requiring addressing constructs is forced to either define its own, or attempt to locate and include similar definitions from other modules. The advantages of a repository are a) there is a single set of definitions b) all MIB developers know what to include, and where to look c) multiple definitions of the same information is avoided d) the definitions are independant and widely useable, not tied to a particular protocol, MIB module, or enterprise e) this module can be updated independently, and hence much more rapidly, than if the information is defined in broader RFCs on the standards-track (for example, [RFC1906]) 4. Transport Domains and Addresses The TDomain and TAddress textual conventions are defined in [RFC1903], and are intended to be used in MIB modules to represent transport domains and addresses. Actual values for OBJECT-TYPES with these syntaxes are currently defined in [RFC1906] and various other (enterprise-specific) modules. The transport domains defined in [RFC1906] all contain "snmp" as the prefix in their name, are all assigned under `snmpDomains' (from [RFC1902]). There has been some confusion as to whether these defintions are appropriate for designating transport endpoints for non-SNMP traffic. These definitions are also now incomplete, new transport addresses are currently required for at least IPv6 [?] and AgentX [RFC2257]. This module defines a new set of generic transport domains and addresses. All assignments are made under a new branch; (???), to be administered by IANA. 5. Impact on Transport Mappings This module does NOT define the transport mappings for any particular protocol. Rather, it defines a set of common identifiers and textual conventions that are intended to be used within various transport mappings documents. (Inclusion within transport mappings is just one possible use of these generic definitions.) 6. IANA Considerations It is intended that IANA will maintain this MIB module. Following the policies outlined in [IANA-CONSIDERATIONS], additions to this module MUST be reviewed by a Designated Expert. 7. Definitions IANA-ADDRESS-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-IDENTITY FROM SNMPv2-SMI TEXTUAL-CONVENTION FROM SNMPv2-TC; ianaAddressMIB MODULE-IDENTITY LAST-UPDATED "9808050000Z" ORGANIZATION "IANA" CONTACT-INFO "TBD" DESCRIPTION "The MIB module for commonly-used network addressing definitions." ::= { ??? } -- -- The registration node for protocol domains -- ianaAddrDomains OBJECT IDENTIFIER ::= { ??? } -- -- Protocol domains -- -- UDP over IPv4 ianaAddrUDPIPv4Domain OBJECT-IDENTITY STATUS current DESCRIPTION "The UDP over IPv4 transport domain. The corresponding transport address is of type IanaAddrIPv4TAddress." ::= { ianaAddrDomains 1 } -- UDP over IPv6 ianaAddrUDPIPv6Domain OBJECT-IDENTITY STATUS current DESCRIPTION "The UDP over IPv6 transport domain. The corresponding transport address is of type IanaAddrIPv6TAddress." ::= { ianaAddrDomains 2 } -- TCP over IPv4 ianaAddrTCPIPv4Domain OBJECT-IDENTITY STATUS current DESCRIPTION "The TCP over IPv4 transport domain. The corresponding transport address is of type IanaAddrIPv4TAddress." ::= { ianaAddrDomains 3 } -- TCP over IPv6 ianaAddrTCPIPv6Domain OBJECT-IDENTITY STATUS current DESCRIPTION "The TCP over IPv6 transport domain. The corresponding transport address is of type IanaAddrIPv6TAddress." ::= { ianaAddrDomains 4 } -- UNIX-domain sockets ianaAddrUNIXDomain OBJECT-IDENTITY STATUS current DESCRIPTION "The unix-domain sockets transport domain. The corresponding transport address is of type IanaAddrUNIXTAddress." ::= { ianaAddrDomains 5 } -- OSI ianaAddrCLNSDomain OBJECT-IDENTITY STATUS current DESCRIPTION "The CLNS transport domain. The corresponding transport address is of type IanaAddrOSITAddress." ::= { ianaAddrDomains 6 } ianaAddrCONSDomain OBJECT-IDENTITY STATUS current DESCRIPTION "The CONS transport domain. The corresponding transport address is of type IanaAddrOSITAddress." ::= { ianaAddrDomains 7 } -- DDP ianaAddrDDPDomain OBJECT-IDENTITY STATUS current DESCRIPTION "The DDP transport domain. The corresponding transport address is of type IanaAddrNBPTAddress." ::= { ianaAddrDomains 8 } -- IPX ianaAddrIPXDomain OBJECT-IDENTITY STATUS current DESCRIPTION "The IPX transport domain. The corresponding transport address is of type IanaAddrIPXTAddress." ::= { ianaAddrDomains 9 } -- -- Textual conventions for transport endpoints. -- -- These are named xxxTAddress to denote transport addresses, -- and differentiate them from network addresses that may be included -- in subsequent versions. -- -- TCP/UDP over IPv4 Transport Address IanaAddrIPv4TAddress ::= TEXTUAL-CONVENTION DISPLAY-HINT "1d.1d.1d.1d/2d" STATUS current DESCRIPTION "Represents a TCP-over-IPv4 or a UDP-over-IPv4 transport address: octets contents encoding 1-4 IP address network-byte order 5-6 TCP or UDP port network-byte order " SYNTAX OCTET STRING (SIZE (6)) -- TCP/UDP over IPv6 Transport Address IanaAddrIPv6TAddress ::= TEXTUAL-CONVENTION DISPLAY-HINT "2x:2x:2x:2x:2x:2x:2x:2x/2d" STATUS current DESCRIPTION "Represents a TCP-over-IPv6 or a UDP-over-IPv6 transport address: octets contents encoding 1-16 IPv6 address network-byte order 17-18 TCP or UDP port network-byte order " SYNTAX OCTET STRING (SIZE (18)) -- UNIX-domain socket Transport Address IanaAddrUNIXTAddress ::= TEXTUAL-CONVENTION DISPLAY-HINT "1a" STATUS current DESCRIPTION "Represents a UNIX-domain socket endpoint: octets contents encoding all UNIX domain endpoint string " SYNTAX OCTET STRING -- OSI Transport Address IanaAddrOSITAddress ::= TEXTUAL-CONVENTION DISPLAY-HINT "*1x:/1x:" STATUS current DESCRIPTION "Represents an OSI transport-address: octets contents encoding 1 length of NSAP 'n' as an unsigned-integer (either 0 or from 3 to 20) 2..(n+1) NSAP concrete binary representation (n+2)..m TSEL string of (up to 64) octets " SYNTAX OCTET STRING (SIZE (1 | 4..85)) -- NBP Transport Address IanaAddrNBPTAddress ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Represents an NBP name: octets contents encoding 1 length of object 'n' as an unsigned integer 2..(n+1) object string of (up to 32) octets n+2 length of type 'p' as an unsigned integer (n+3)..(n+2+p) type string of (up to 32) octets n+3+p length of zone 'q' as an unsigned integer (n+4+p)..(n+3+p+q) zone string of (up to 32) octets For comparison purposes, strings are case-insensitive. All strings may contain any octet other than 255 (hex ff)." SYNTAX OCTET STRING (SIZE (3..99)) -- IPX Transport Address IanaAddrIPXTTAddress ::= TEXTUAL-CONVENTION DISPLAY-HINT "4x.1x:1x:1x:1x:1x:1x.2d" STATUS current DESCRIPTION "Represents an IPX address: octets contents encoding 1-4 network-number network-byte order 5-10 physical-address network-byte order 11-12 socket-number network-byte order " SYNTAX OCTET STRING (SIZE (12)) END 8. Open Issues 1) Can the TDomain and TAddress textual conventions defined in RFC 1903 be used to represent "generic" transport information, used by applications other than just SNMP? Proposal: While their definitions use detailed examples that are SNMP-specific, they may be used more widely. (An update to RFC1903 should modify their descriptions accordingly.) 2) Can the IANA-ADDRESS-MIB also be used for non-transport addresses? For example, can a TAddress be used to represent just a network-layer address? Proposal: Yes, it can be used for arbitrary address domains. We should clarify the wordings of the TDomain and TAddress definition in the successor of RFC 1903 to make that clear. This needs to be discussed with the work currently going on to bring RFC 1903 to full standard status. 3) Do we need an OID where IANA controlled MIB modules such as this module can be registered? (Another such module might be the IANA-LANGUAGE-MIB from the DISMAN WG.) Proposal: Yes. One possible node is iana OBJECT IDENTIFIER ::= { internet 7 } Whatever assignment is made, it should be reflected in the revision of RFC 1902 which is currently being worked on. 4) Should there be separate OID branches for network (and below) addresses, network+transport addresses, and applications? Or is some other hierarchy more useful? 5) If this memo prospers, what happens to the values defined in RFC1906? 9. Acknowledgements Many of the definitions in this module are taken directly from [RFC1906]. Thanks to Juergen Schoenwaelder and Mark Ellison for ideas and review to date. 10. References [RFC1902] [RFC1903] [RFC1906] [RFC2257] [IPv6] [IANA-CONSIDERATIONS] 11. Security Considerations This MIB module defines assigned values for commonly used addressing domains, and a set of textual conventions. It does not define any MIB objects that actually contain management information. As such, there are no security considerations for this module. 12. Author's Address Mike Daniele Compaq Computer Corporation 110 Spit Brook Rd Nashua, NH 03062 Phone: +1-603-884-1423 EMail: daniele@zk3.dec.com 13. Full Copyright Statement Copyright (C) The Internet Society (1998). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Expires February, 1999 From BzyBees@lycos.com Mon Aug 10 14:56:14 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id OAA27571 for ; Mon, 10 Aug 1998 14:56:13 -0500 (CDT) From: BzyBees@lycos.com Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id OAA18951 for ; Mon, 10 Aug 1998 14:54:41 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma018039; Mon, 10 Aug 98 14:51:55 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id OAA21011 for ; Mon, 10 Aug 1998 14:51:16 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma020078; Mon, 10 Aug 98 14:50: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 OAA26278; Mon, 10 Aug 1998 14:51:02 -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 MAA21947; Mon, 10 Aug 1998 12:44:40 -0700 (PDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id OAA16477; Mon, 10 Aug 1998 14:44:34 -0500 (CDT) Received: from aaagk.aaapc.co.jp(210.175.71.5) by almond.bmc.com via smap (V2.0) id xma016461; Mon, 10 Aug 98 14:44:03 -0500 Received: from sdn-ts-012nccharP02.dialsprint.net by aaagk.aaapc.co.jp; (5.65v3.2/1.1.8.2/24Apr96-0210PM) id AA01833; Tue, 11 Aug 1998 05:10:49 +0900 Message-Id: <9808102010.AA01833@aaagk.aaapc.co.jp> Date: Mon, 10 Aug 98 14:06:33 EST To: 1you124@anywhere.com.bmc.com Subject: WORLDS' GREATEST ........ World's Greatest Business Opportunity! ......... You be the judge. No Competition No Selling Not MLM $1 - $5,000 per week from home, within the next 30 days! Complete Training & Support Live Conference Calls Daily! Leads! Leads! Leads! and Much More! If your a serious minded individual that is tired of hype and NEEDS to make several thousand dollars with in the next 30 - 60 days, then we need to talk. I am making several thousand dollars per week and YOU CAN TOO! Either myself or one of my associates will contact you about our turnkey, proprietary system that is so easy and simple to duplicate. IT WORKS LIKE A CHARM! P.S. You owe it to yourself and your family to take a serious look CLICK LINK BELOW AND ENTER YOUR INFO TO MAKE CONTACT ================================== Click Here ======>>>more info <<<======= Click Here Put the word "SUCCEED" in the subject field plus the information below and click send. ------------------------------------------------------ Please include the following: Without this information you will not be contacted ------------------------------------------------------ Name <<<<====Important (remember to include) Home or Work Phone number <<<<====Important (remember to include) The best time to contact you <<<<====Important (remember to include) ============================================================= To remove from mailing list click link below: Click Here ====>>> more info <<<==== Click Here Put the words "Remove now" in the Subject Field and Click Send. From daniele@zk3.dec.com Mon Aug 10 15:58:52 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id PAA28078 for ; Mon, 10 Aug 1998 15:58:52 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id PAA26538 for ; Mon, 10 Aug 1998 15:57:17 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma025665; Mon, 10 Aug 98 15:54:44 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id PAA24742 for ; Mon, 10 Aug 1998 15:53:48 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma023596; Mon, 10 Aug 98 15:53: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 PAA17436; Mon, 10 Aug 1998 15:53:35 -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 NAA24106 for ; Mon, 10 Aug 1998 13:40:32 -0700 (PDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id PAA23600 for ; Mon, 10 Aug 1998 15:40:31 -0500 (CDT) Received: from mail11.digital.com(192.208.46.10) by almond.bmc.com via smap (V2.0) id xma023582; Mon, 10 Aug 98 15:40:01 -0500 Received: from flume.zk3.dec.com (flume.zk3.dec.com [16.140.112.3]) by mail11.digital.com (8.8.8/8.8.8/WV1.0g) with SMTP id QAA19771; Mon, 10 Aug 1998 16:39:59 -0400 (EDT) Received: from bernie.zk3.dec.com by flume.zk3.dec.com (5.65v4.0/1.1.8.2/16Jan95-0946AM) id AA12150; Mon, 10 Aug 1998 16:39:58 -0400 Received: from localhost by bernie.zk3.dec.com; (5.65/1.1.8.2/22Aug96-1117AM) id AA20720; Mon, 10 Aug 1998 16:40:13 -0400 Message-Id: <9808102040.AA20720@bernie.zk3.dec.com> To: Randy Presuhn Cc: agentx@peer.com Subject: Re: some comments on MIB In-Reply-To: Your message of "Fri, 07 Aug 98 15:25:35 PDT." <199808072225.PAA13736@dorothy.bmc.com> Date: Mon, 10 Aug 98 16:40:13 -0400 From: Mike Daniele X-Mts: smtp Hello all, Randy said >I agree that it would be nice to have a representation that more >accurately reflected what was going on. Mapping the ad-hoc encoding >from AgentX protocol back into object identifiers doesn't seem like >the right thing to do. I'd be happier with an encoding that matched >the semantics of what the protocol carries. Three straw-person proposals: > 1) represent it as dotted decimal strings with [low-high] for > ranged elements, e.g.: 1.3.5.7.9.[11-13].15 > 2) pack the stuff into some ad hoc binary octet string > 3) Break it into multiple objects, corresponding to the > protocol elments I think #3 makes sense. Remove agentxRegEnd. Add 2 ints, agentxRegRangeSubid and agentxRegUpperBound. Take their description from the Register-PDU in 2257. Everything is crystal clear. (Nore that if we're about to change/clarify what to use for range_subid in 2257.) >> We also need to decide if a subsection of a registration range >> can be unregistered and if so if they registration table needs >> any fixes. As an example if a sub agent registers a.b.c.[d-e].f >> and then unregisters a.b.c.d.f what should happen? Should the >> deregistration be allowed and the table updated? or should the >> deregistration be rejected if it doesn't match a registration >> request exactly? >I think there was agreement at one time that deregistration requests >had to match registration requests exactly. It keeps things simple. I think there is still agreement, and it still keeps things simple :-) >We need to tighten up the wording in 2257. Perhaps it would be useful >to separate the concept of the specification of a region from the region >itself. I think this is a good example of how the "tutorial" material on >"splitting" regions is somewhat problematic, in that it currently tends >to obscure this distinction. Agreed. I'm hoping to remove all "splitting" references. And the word "range" is overloaded as currently used. Mike From Lauren_Heintz@crow.bmc.com Mon Aug 10 16:00:19 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id QAA28098 for ; Mon, 10 Aug 1998 16:00:18 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id PAA27231 for ; Mon, 10 Aug 1998 15:58:45 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma026833; Mon, 10 Aug 98 15:57:52 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id PAA28854 for ; Mon, 10 Aug 1998 15:57:13 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma027499; Mon, 10 Aug 98 15:56: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 PAA18155; Mon, 10 Aug 1998 15:56:55 -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 NAA24494 for ; Mon, 10 Aug 1998 13:53:42 -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 PAA17468; Mon, 10 Aug 1998 15:53:39 -0500 (CDT) Message-ID: <35CF5D37.C828BE97@bmc.com> Date: Mon, 10 Aug 1998 13:51:03 -0700 From: Lauren Heintz X-Mailer: Mozilla 4.04 [en] (WinNT; U) MIME-Version: 1.0 To: daniele@zk3.dec.com CC: snmpv3@tis.com, agentx@peer.com Subject: Re: proposal for iana address mib References: <9808101915.AA23991@bernie.zk3.dec.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit How about including corresponding mask objects for each of the TAddress definitions so that appropriate wildcarding can be specified if needed? TCP or UDP masks, for example, would allow an application to wildcard the IP portion (to subnet levels) AND/OR the port (one or any) of a TAddress value. Lauren daniele@zk3.dec.com wrote: > > Hi, > > Some of the issues with respect to TDomain and TAddress > that have come up are > > o need new one for snmp over udp over ipv6 in RFC 1906 > o need several new ones for AgentX MIB > o progress within snmpv3 wg on updating 1906, 1903, etc > has been glacial > > Out of ensuing discussions/complaints, the suggestion was made > that we have a single MIB module that defines addressing information. > It could be maintained by IANA, updated more easily than say 1906, > and be more widely useable than the SNMP-specific definitions in 1906. > > Attached please find such a module. This specific work hasn't been > requested by any WG chair, but I'm hoping it will be considered > as a mechanism to get us moving, and provide a more generally useable > solution. > ... > ... -------------------------------------------------------------------------- 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 rpresuhn@dorothy.bmc.com Tue Aug 11 00:29:40 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id AAA02188 for ; Tue, 11 Aug 1998 00:29:40 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id AAA01169 for ; Tue, 11 Aug 1998 00:28:06 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma000637; Tue, 11 Aug 98 00:26:57 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id AAA17340 for ; Tue, 11 Aug 1998 00:26:17 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma016723; Tue, 11 Aug 98 00:25: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 AAA04038; Tue, 11 Aug 1998 00:26:04 -0500 (CDT) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id WAA14450 for agentx@peer.com; Mon, 10 Aug 1998 22:03:28 -0700 (PDT) Date: Mon, 10 Aug 1998 22:03:28 -0700 (PDT) From: Randy Presuhn Message-Id: <199808110503.WAA14450@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 - > To: Randy Presuhn > Cc: agentx@peer.com > Subject: Re: Table Indices in AgentX MIB > Date: Mon, 10 Aug 98 11:48:16 -0400 > From: Mike Daniele ... > Would you like to see text added about why this "across all connections" > uniqueness was chosen? ... If folks are really building systems that DEPEND on this behaviour, then by all means the rationale should be documented. My point was that the rationale is based on consideratons that go beyond the pale of RFC 2119's guidelines for the use of "must". You have to admit, as protocol properties go, this one is pretty bizarre, in that a master agent could violate it flagrantly with no effect on interoperability, unless someone built a subagent that used this id for table indexing. (And the question of whether that was really a PROTOCOL interoperability issue would still be debatable.) ----------------------------------------------------------------------- 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 Wed Aug 12 13:19:22 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id NAA19903 for ; Wed, 12 Aug 1998 13:19:21 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id NAA16594 for ; Wed, 12 Aug 1998 13:17:46 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma016462; Wed, 12 Aug 98 13:17:00 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id NAA25721 for ; Wed, 12 Aug 1998 13:16:24 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma024968; Wed, 12 Aug 98 13:15: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 NAA14260; Wed, 12 Aug 1998 13:15:45 -0500 (CDT) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id JAA01826 for agentx@peer.com; Wed, 12 Aug 1998 09:45:00 -0700 (PDT) Date: Wed, 12 Aug 1998 09:45:00 -0700 (PDT) From: Randy Presuhn Message-Id: <199808121645.JAA01826@dorothy.bmc.com> To: agentx@peer.com Subject: Updated MIB draft? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi - I know there was a flurry of activity updating the AgentX MIB document. I haven't seen the I-D announcement yet. Did it meet the deadline? ----------------------------------------------------------------------- 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 dsteele@vcoutlet.com Fri Aug 14 11:16:15 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id LAA10298 for ; Fri, 14 Aug 1998 11:16:14 -0500 (CDT) From: dsteele@vcoutlet.com Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id LAA14332 for ; Fri, 14 Aug 1998 11:14:34 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma013813; Fri, 14 Aug 98 11:12:56 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id LAA23641 for ; Fri, 14 Aug 1998 11:12:18 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma021673; Fri, 14 Aug 98 11:10: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 LAA05132; Fri, 14 Aug 1998 11:11:00 -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 IAA15196; Fri, 14 Aug 1998 08:02:04 -0700 (PDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id KAA03254; Fri, 14 Aug 1998 10:02:02 -0500 (CDT) Date: Fri, 14 Aug 1998 10:02:02 -0500 (CDT) Message-Id: <199808141502.KAA03254@almond.bmc.com> Received: from icihs1.icih.net(208.218.252.100) by almond.bmc.com via smap (V2.0) id xma003087; Fri, 14 Aug 98 10:01:10 -0500 To: dsteele@vcoutlet.com Subject: Videoconferencing Hi, I would first like to thank you for taking the time to read this message regarding HTTP://www.vcoutlet.com . If you are in the videoconferencing market or are planning to be this may be one of the most important messages you will read for a while. At VCoutlet we are offering all of the major brands of videoconferencing products at the lowest price possible. How do we do it? Not a single pushy salesman, very little overhead, the best products and great customer support. When you order from HTTP://www.vcoutlet.com your order is shipped directly to you. Does this sound appealing? well visit our web site and see how much more we have to offer. Once again thank you for your time, we know it is important to you because it is important to us too! ___________________________________________________________ This Message was Composed using Extractor Pro '98 Bulk E- Mail Software. If you wish to be removed from this advertiser's future mailings, please reply with the subject "Remove" and this software will automatically block you from their future mailings. From mdavidson65@iname.com Sun Aug 16 22:42:43 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id WAA19414 for ; Sun, 16 Aug 1998 22:42:43 -0500 (CDT) From: mdavidson65@iname.com Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id WAA22770 for ; Sun, 16 Aug 1998 22:40:58 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma022092; Sun, 16 Aug 98 22:38:21 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id WAA20818 for ; Sun, 16 Aug 1998 22:37:33 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma020520; Sun, 16 Aug 98 22:37: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 WAA00951; Sun, 16 Aug 1998 22:37:35 -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 TAA00469 for ; Sun, 16 Aug 1998 19:20:40 -0700 (PDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id VAA11940 for ; Sun, 16 Aug 1998 21:20:38 -0500 (CDT) Received: from unknown(205.218.23.1) by almond.bmc.com via smap (V2.0) id xma011764; Sun, 16 Aug 98 21:19:45 -0500 Received: from [207.240.250.199] by mail.t-three.com (SMTPD32-4.0) id A0B49FB0240; Sun, 16 Aug 1998 20:08:52 -0600 Received: from login_0246.yybecker22.ca(yybecker22.ca.206.2142.231.88]) by yybecker22.ca (8.8.5/8.7.3) with SMTP id XAA00274 for 2121422@yybecker22.ca; Sun, 16 August 1998 19:27:50 -0700 (EDT) To: SearchEngineRegistration@yybecker22.ca.bmc.com Subject: Search Engines Reply-To: mdavidson65@iname.com X-PMFLAGS: 10322341.10 X-UIDL: 10293287_192832.222 Comments: Authenticated Sender is Message-Id: 93904039291232@hsd_hypothesis.com Date: Sun, 16 Aug 98 20:11:46 MST7MDT I came across your web site on the Internet and since I work for a company that submits web sites to over 350 search engines and directories for only 11.5 cents apiece, I wanted to bring our service to your attention. If you feel you can recoup the initial $39.95 investment (that is the total cost) on one sale from millions of potential customers, call us today to and get your web site in front of that potential buyer! Remember, you can't make that sale if people can't find you! All work is verified. Sincerely, Mike Davidson (800) 484-2621 X5568 From wllarso@somnet.sandia.gov Mon Aug 17 12:14:07 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id MAA25678 for ; Mon, 17 Aug 1998 12:14:03 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id MAA16280 for ; Mon, 17 Aug 1998 12:12:13 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma013568; Mon, 17 Aug 98 11:50:34 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id LAA14096 for ; Mon, 17 Aug 1998 11:48:39 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma012689; Mon, 17 Aug 98 11:47: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 LAA17087; Mon, 17 Aug 1998 11:48: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 JAA23995 for ; Mon, 17 Aug 1998 09:13:30 -0700 (PDT) Received: (from uucp@localhost) by cashew.bmc.com (8.8.8/8.8.8) id LAA28712 for ; Mon, 17 Aug 1998 11:13:28 -0500 (CDT) Received: from somnet.sandia.gov(132.175.109.2) by cashew.bmc.com via smap (V2.0) id xma028664; Mon, 17 Aug 98 11:12:56 -0500 Received: (from wllarso@localhost) by somnet.sandia.gov (8.9.1a/8.9.1a) id KAA01938 for agentx@peer.com; Mon, 17 Aug 1998 10:12:46 -0600 (MDT) From: "William L. Larson (Bill)" Message-Id: <199808171612.KAA01938@somnet.sandia.gov> Subject: AgentX mailing list archive To: agentx@peer.com Date: Mon, 17 Aug 1998 10:12:46 -0600 (MDT) X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I'm curious about using AgentX and have looked at the mailing list archives available from ftp.peer.com. I am suspecting that there may be a problem with permissions for the "current" file. The permissions on the "/pub/agentx/archives/current" file are set at 666 which allows ANYONE to write to this file, including anyone logged into the server as "anonymous" (unless there are other access controls set up on this server, which is possible since it is running WU-FTPD). I really don't want to mess things up by trying to write to this file, but you may want to check this out and possibly tighten up these permissions. Anyway, thanks for supporting this archive. Bill Larson (wllarso@sandia.gov) From rpresuhn@dorothy.bmc.com Mon Aug 17 20:18:07 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id UAA29256 for ; Mon, 17 Aug 1998 20:18:06 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id UAA10569 for ; Mon, 17 Aug 1998 20:16:20 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma009626; Mon, 17 Aug 98 19:45:18 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id TAA22586 for ; Mon, 17 Aug 1998 19:43:40 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma017206; Mon, 17 Aug 98 19:36: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 TAA22628; Mon, 17 Aug 1998 19:37:12 -0500 (CDT) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id RAA09168 for agentx@peer.com; Mon, 17 Aug 1998 17:13:08 -0700 (PDT) Date: Mon, 17 Aug 1998 17:13:08 -0700 (PDT) From: Randy Presuhn Message-Id: <199808180013.RAA09168@dorothy.bmc.com> To: agentx@peer.com Subject: Re: AgentX mailing list archive Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi - > From: "William L. Larson (Bill)" > Subject: AgentX mailing list archive > To: agentx@peer.com > Date: Mon, 17 Aug 1998 10:12:46 -0600 (MDT) ... > The permissions on the "/pub/agentx/archives/current" file are set at > 666 which allows ANYONE to write to this file, including anyone logged > into the server as "anonymous" (unless there are other access controls > set up on this server, which is possible since it is running WU-FTPD). There are indeed other access controls in place. The "666" permissions are an artifact of how mail is handled by that system coupled with how the FTP site is maintained and the fact that those responsible for the list (maintained on yet another system!) don't have administrative privileges on the system hosting the FTP site. On the other hand, it works. :-) ----------------------------------------------------------------------- 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 case@snmp.com Thu Aug 20 13:20:28 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id NAA29129 for ; Thu, 20 Aug 1998 13:20:27 -0500 (CDT) From: case@snmp.com Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id NAA08721 for ; Thu, 20 Aug 1998 13:18:36 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma008627; Thu, 20 Aug 98 13:18:02 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id NAA06334 for ; Thu, 20 Aug 1998 13:17:24 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xmaa05817; Thu, 20 Aug 98 13:16: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 NAA27396; Thu, 20 Aug 1998 13:17:33 -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 JAA22486 for ; Thu, 20 Aug 1998 09:48:12 -0700 (PDT) Received: (from uucp@localhost) by cashew.bmc.com (8.8.8/8.8.8) id LAA19108 for ; Thu, 20 Aug 1998 11:48:10 -0500 (CDT) Received: from seymour4.snmp.com(192.147.142.4) by cashew.bmc.com via smap (V2.0) id xma019076; Thu, 20 Aug 98 11:48:02 -0500 Received: by seymour4.snmp.com (cf v2.11c-SNMP) id MAA23467; Thu, 20 Aug 1998 12:48:00 -0400 (EDT) Date: Thu, 20 Aug 1998 12:48:00 -0400 (EDT) Message-Id: <199808201648.MAA23467@seymour4.snmp.com> To: manne@siemensdc.com Subject: Re: Dynamic row creation Cc: agentx@peer.com one of the early agent-x design decisions that has been followed fastidiously is that dispatching to subagents is done only via groups of non-overlapping regions that have been registered by subagents; i.e., that subagents register to "pull" or "solicit" requests implicit in this design decision is the reality that the master agent cannot dispatch a region that has not yet been registered ... and therefore a manager cannot create something that a subagent hasn't already "invited" by indicating a willingness to handle it via a registration request furthermore, a design decision was made to not include in the design any standard mechanism for allowing one subagent to get information from other parts of the agent (objects handled by the master agent or other subagents) so only "behind the back" mechanisms -- to use your words -- must be used to implement what you want these are two of the problems that crop up if one uses agentx as the master agent <--> subagent communications mechanisms and are the result of design decisions made in the interest of simplicity these design decisions severely limit the usefulness of the design -- in fact, the recent testing event demonstrated that one cannot use agentx to implement even mib-2's interfaces group with different parts of the ifTable handled by different subagents and still be able to get ifNumber correct -- unless one uses your so-called "behind the back" mechanisms the agentx document talks about some of these problems with implementing standard mibs, but yours is a real-life product that suffers from these limitations in my opinion, this is severely broken, and i argued against it at the time, but i was ineffective in convincing the group that it was broken -- it is too bad that you were not around and vocal in those days a better way? there are other master agent <--> subagent products in the market today that do not suffer from these severe problems that agentx has you might want to check with a resource within your own company, Helmut.Wrubel@vs.siemens.de to explore alternatives regards, jdc ----- >Hello, > > We are considering using AgentX in the implementation of an agent for >our stackable bridge products. We wish to present the stack as a single >transparent bridge, with ifIndex indexing the ports of the various >modules. In this situation, I would like to understand how to create an >entry in the dot1dStaticTable of rfc1493, or in the dot1qStaticTable of >the proposed new version of the bridge MIB. The former is indexed by >{dot1dStaticAddress, dot1dStaticReceivePort}. > > According to a discussion I found in the list archives (from April >98), it is not possible under AgentX to create rows in tables with >multiple indices [tuples, of the form (1,1), (1,2)]. The conclusion >there as I understood it was that one can solve the problem by using one >of the indices, as long as it is unique in the table. In our case, we >could use dot1dStaticAddress as such an index. > > In our case, the desired result is that all the elements of the stack >hold identical copies of the dot1dStaticTable (the fact that the >hardware will interpret them differently depending on whether a given >ifIndex is local or not is an implementation issue). As I understand >AgentX, row creation is a function of the subagent, not the master. >When an NMS requests the creation of a new row, the master agent must >choose one of the subagents as being responsible for the given range of >index values (rfc2257, sec. 7.2.1.4(3)) This implies that we should >assign one of the subagents as being responsible for the entire range of >dot1dStaticAddress values. This in turn seems to imply that the table >would be propagated to the other subagents "behind the back" of AgentX, >as it were. This seems to me to defeat the purpose of AgentX, but I >can't think of a better implementation. > > I would appreciate it greatly if someone on the list could show me a >better way of doing what I want to do. > >Aharon Manne >Siemens Data Communications >Karmiel, Israel From daniele@zk3.dec.com Fri Aug 21 13:33:22 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id NAA10963 for ; Fri, 21 Aug 1998 13:33:22 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id NAA10196 for ; Fri, 21 Aug 1998 13:31:27 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma010110; Fri, 21 Aug 98 13:31:16 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id NAA09129 for ; Fri, 21 Aug 1998 13:30:37 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma006187; Fri, 21 Aug 98 13:28: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 NAA29424; Fri, 21 Aug 1998 13:28:33 -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 KAA07191 for ; Fri, 21 Aug 1998 10:15:59 -0700 (PDT) Received: (from uucp@localhost) by cashew.bmc.com (8.8.8/8.8.8) id MAA01346 for ; Fri, 21 Aug 1998 12:15:57 -0500 (CDT) Received: from mail13.digital.com(192.208.46.30) by cashew.bmc.com via smap (V2.0) id xma001330; Fri, 21 Aug 98 12:15:45 -0500 Received: from flume.zk3.dec.com (yflume.zk3.dec.com [16.140.16.14]) by mail13.digital.com (8.8.8/8.8.8/WV1.0g) with SMTP id NAA28651; Fri, 21 Aug 1998 13:14:18 -0400 (EDT) Received: from bernie.zk3.dec.com by flume.zk3.dec.com (5.65v4.0/1.1.8.2/16Jan95-0946AM) id AA18557; Fri, 21 Aug 1998 13:14:17 -0400 Received: from localhost by bernie.zk3.dec.com; (5.65/1.1.8.2/22Aug96-1117AM) id AA30453; Fri, 21 Aug 1998 13:14:31 -0400 Message-Id: <9808211714.AA30453@bernie.zk3.dec.com> To: case@snmp.com Cc: manne@siemensdc.com, agentx@peer.com Subject: Re: Dynamic row creation In-Reply-To: Your message of "Thu, 20 Aug 98 12:48:00 EDT." <199808201648.MAA23467@seymour4.snmp.com> Date: Fri, 21 Aug 98 13:14:31 -0400 From: Mike Daniele X-Mts: smtp >one of the early agent-x design decisions that has been followed fastidiously >is that dispatching to subagents is done only via groups of non-overlapping >regions that have been registered by subagents; i.e., that subagents register >to "pull" or "solicit" requests >implicit in this design decision is the reality that the master agent cannot >dispatch a region that has not yet been registered ... and therefore a manager >cannot create something that a subagent hasn't already "invited" by indicating >a willingness to handle it via a registration request Correct. These same statements are also true, I believe, of every other extensible agent technology. That is, the master would dispatch to whatever registered ifTable. The difference is that AgentX only dispatches to a single registrant, while other technologies may dispatch to several. See below for more discussion. >furthermore, a design decision was made to not include in the design any >standard mechanism for allowing one subagent to get information from other >parts of the agent (objects handled by the master agent or other subagents) >so only "behind the back" mechanisms -- to use your words -- must be used >to implement what you want That's also technically correct. However, I point out that the the specific requirements Aharon presented apparently go well beyond this, and would not be helped greatly if AgentX did have this capability. (That is, this "advertising of instances" between components [not necessarily subagents in our usual understanding of that term] is probably beyond the scope of what an extensible agent should do.) >these are two of the problems that crop up if one uses agentx as the >master agent <--> subagent communications mechanisms and are the result >of design decisions made in the interest of simplicity >these design decisions severely limit the usefulness of the design -- in >fact, the recent testing event demonstrated that one cannot use agentx >to implement even mib-2's interfaces group with different parts of the >ifTable handled by different subagents and still be able to get ifNumber >correct -- unless one uses your so-called "behind the back" mechanisms That is utter nonsense. On many (most) platforms on which multivendor subagents will exist, interface data is available from the native system (e.g., "the kernel"). This is certainly the case for all UNIX variants and (I believe) all MS Windows variants. At the bakeoff your subagents were running on a SunOS system. See above. So instead of simply querying the managed resource to determine ifNumber, you pronounce AgentX broken. Also, during the bakeoff you made no mention of this problem. I know this because it was our master agent your subagent was successfully interoperating with. What *I* remember about it is that a getnext sweep of the ifTable worked correctly, with our master querying your two subagents that had each registered fully qualifed instances in separate rows of ifTable. I call this success, not broken specs. >the agentx document talks about some of these problems with implementing >standard mibs, but yours is a real-life product that suffers from these >limitations I don't believe so, based on further conversations. But I could be wrong. >in my opinion, this is severely broken, and i argued against it at the time, >but i was ineffective in convincing the group that it was broken -- it is >too bad that you were not around and vocal in those days The group opted for simple. One of the WG members also floated a proposal (remember "unionized registrations"?) for more complex types of registrations, in direct response to your concerns. There were no replies. You never made a proposal of any type, simply labeled things broken. This strategy of choosing "simple" in v1 seems to have served the community well in the past (for example, SNMPv1). >a better way? there are other master agent <--> subagent products in the >market today that do not suffer from these severe problems that agentx has >you might want to check with a resource within your own >company, Helmut.Wrubel@vs.siemens.de to explore alternatives Your protocol suffers from a serious design flaw. Multiple subagents may register for identical OIDs. They can each implement the same instance. The master agent queries them all, then, in an implemention-specific manner, decides which value to use. The WG decided this was not appropriate for an internet-standard extensible agent protocol. Please note I said *protocol*. This is not an attempt to bash your excellent product offerings. In summary, I believe Aharon's view is that it is acceptable for one subagent to register "the table", and cause other subagents to create and manage individual rows. I also believe this specific case may be one of a particular vendor implementing all components, hence not particularly germane to agentx. But again, my understanding may be wrong since it is based on a few quick mail messages. Mike From Lauren_Heintz@crow.bmc.com Fri Aug 21 13:36:08 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id NAA10983 for ; Fri, 21 Aug 1998 13:36:08 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id NAA11282 for ; Fri, 21 Aug 1998 13:34:14 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma010053; Fri, 21 Aug 98 13:31:08 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id NAA08912 for ; Fri, 21 Aug 1998 13:30:28 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma006128; Fri, 21 Aug 98 13:28:06 -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 NAA29416; Fri, 21 Aug 1998 13:28:32 -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 LAA07287 for ; Fri, 21 Aug 1998 11:20:11 -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 NAA27706; Fri, 21 Aug 1998 13:20:08 -0500 (CDT) Message-ID: <35DDB9A8.D2D58C54@bmc.com> Date: Fri, 21 Aug 1998 11:17:12 -0700 From: Lauren Heintz X-Mailer: Mozilla 4.04 [en] (WinNT; U) MIME-Version: 1.0 To: agentx@peer.com Subject: AgentX MIB draft issues Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit This is to notify this list that several posts will soon follow. Each post will contain one issue, and I believe there are 17 issues. These 17 issues represent the known issues that affect the April 14, 1998 version of the AgentX MIB draft, and will be presented for discussion at next week's IETF AgentX MIB document presentation. 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 Lauren_Heintz@crow.bmc.com Fri Aug 21 13:36:31 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id NAA10989 for ; Fri, 21 Aug 1998 13:36:30 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id NAA11455 for ; Fri, 21 Aug 1998 13:34:36 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma010149; Fri, 21 Aug 98 13:31:21 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id NAA09248 for ; Fri, 21 Aug 1998 13:30:42 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma006450; Fri, 21 Aug 98 13:28: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 NAA29412; Fri, 21 Aug 1998 13:28:31 -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 LAA07299 for ; Fri, 21 Aug 1998 11:23:02 -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 NAA28287; Fri, 21 Aug 1998 13:22:58 -0500 (CDT) Message-ID: <35DDBA4E.7E957DCD@bmc.com> Date: Fri, 21 Aug 1998 11:19:58 -0700 From: Lauren Heintz X-Mailer: Mozilla 4.04 [en] (WinNT; U) MIME-Version: 1.0 To: agentx@peer.com Subject: AgentX MIB issue 2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Issue 2: The exact nature and description of agentxSessionIndex needs to be clarified. Is it the same as h.SessionID in the AgentX header? When may sessionID values be re-used on a given connection? What is a connection defined as when connectionless transports are used? Should it be type constrained to not include 0? If session IDs are globally unique across any connection, then should the agentxSessionTable be indexed only by agentxSessionIndex (drop the agentxConnIndex index)? Status: consensus forming that agentxSessionIndex should be same as h.SessionID and should uniquely identify a session on a given connection. This issue needs to be in-sync with RFC 2257 text concerning h.SessionID. Proposed description: "agentxSesssionIndex is the same as h.sessionID defined in the agentx header. It is a non-zero index value that uniquely identifies the subagent session within a given connection. Session index values may be discontiguous and may be reused as long as the constraint of uniqueness within a single connection is preserved." -------------------------------------------------------------------------- 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 Lauren_Heintz@crow.bmc.com Fri Aug 21 13:36:45 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id NAA10997 for ; Fri, 21 Aug 1998 13:36:44 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id NAA11563 for ; Fri, 21 Aug 1998 13:34:50 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma010148; Fri, 21 Aug 98 13:31:21 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id NAA09240 for ; Fri, 21 Aug 1998 13:30:42 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma006399; Fri, 21 Aug 98 13:28:18 -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 NAA29435; Fri, 21 Aug 1998 13:28:34 -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 LAA07309 for ; Fri, 21 Aug 1998 11:24:12 -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 NAA28490; Fri, 21 Aug 1998 13:24:06 -0500 (CDT) Message-ID: <35DDBA93.36FBD385@bmc.com> Date: Fri, 21 Aug 1998 11:21:07 -0700 From: Lauren Heintz X-Mailer: Mozilla 4.04 [en] (WinNT; U) MIME-Version: 1.0 To: agentx@peer.com Subject: AgentX MIB issue 3 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Issue 3: Is agentxRegisterDuplicate really useful? If we're going to keep it, wouldn't it be better to make this counter part of the appropriate table entry? Status: consensus forming not to add error counters (whether as scalar or tabular objects). See issue eight for more details. Consensus not yet reached to remove this object, to keep it as it is, or to add it to an existing table entry. -------------------------------------------------------------------------- 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 Lauren_Heintz@crow.bmc.com Fri Aug 21 13:41:47 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id NAA11047 for ; Fri, 21 Aug 1998 13:41:47 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id NAA13767 for ; Fri, 21 Aug 1998 13:39:53 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma012010; Fri, 21 Aug 98 13:35:51 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id NAA15257 for ; Fri, 21 Aug 1998 13:35:12 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma010695; Fri, 21 Aug 98 13:31: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 NAA00469; Fri, 21 Aug 1998 13:32:15 -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 LAA07342 for ; Fri, 21 Aug 1998 11:27:55 -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 NAA29204; Fri, 21 Aug 1998 13:27:51 -0500 (CDT) Message-ID: <35DDBB72.BDC0842B@bmc.com> Date: Fri, 21 Aug 1998 11:24:50 -0700 From: Lauren Heintz X-Mailer: Mozilla 4.04 [en] (WinNT; U) MIME-Version: 1.0 To: agentx@peer.com Subject: AgentX MIB issue 7 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Issue 7: Should an agentxErrorTable be added? Would this remove the need for the agentxRegisterDuplicate object. This table would have an entry per session (and the SessionID or agentxSessionIndex would be the index object) and contain a column of counter32 or gauge32 values for each possible res.error value. Status: consensus forming not to add error counters (whether as scalar or tabular objects). See issue eight for more details. -------------------------------------------------------------------------- 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 Lauren_Heintz@crow.bmc.com Fri Aug 21 13:43:17 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id NAA11065 for ; Fri, 21 Aug 1998 13:43:16 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id NAA14378 for ; Fri, 21 Aug 1998 13:41:22 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma012577; Fri, 21 Aug 98 13:37:07 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id NAA16990 for ; Fri, 21 Aug 1998 13:36:28 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma012423; Fri, 21 Aug 98 13:33: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 NAA00818; Fri, 21 Aug 1998 13:33:33 -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 LAA07399 for ; Fri, 21 Aug 1998 11:29:38 -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 NAA29722; Fri, 21 Aug 1998 13:29:34 -0500 (CDT) Message-ID: <35DDBBD9.C3BC11BF@bmc.com> Date: Fri, 21 Aug 1998 11:26:33 -0700 From: Lauren Heintz X-Mailer: Mozilla 4.04 [en] (WinNT; U) MIME-Version: 1.0 To: agentx@peer.com Subject: AgentX MIB issue 9 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Issue 9: Should the DEFVAL for agentxRegPriority be changed to 128 (from 255) to allow subagents to get "in front of" or "behind" the default priority? Status: consensus forming to have DEFVAL become 128 if RFC 2257 is also appropriately updated. -------------------------------------------------------------------------- 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 Lauren_Heintz@crow.bmc.com Fri Aug 21 13:48:07 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id NAA11104 for ; Fri, 21 Aug 1998 13:48:07 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id NAA16222 for ; Fri, 21 Aug 1998 13:46:11 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma011419; Fri, 21 Aug 98 13:34:30 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id NAA13355 for ; Fri, 21 Aug 1998 13:33:50 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma009863; Fri, 21 Aug 98 13:31: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 NAA00249; Fri, 21 Aug 1998 13:31:26 -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 LAA07320 for ; Fri, 21 Aug 1998 11:27:06 -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 NAA29026; Fri, 21 Aug 1998 13:27:03 -0500 (CDT) Message-ID: <35DDBB43.86EADF8C@bmc.com> Date: Fri, 21 Aug 1998 11:24:03 -0700 From: Lauren Heintz X-Mailer: Mozilla 4.04 [en] (WinNT; U) MIME-Version: 1.0 To: agentx@peer.com Subject: AgentX MIB issue 6 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Issue 6: The RegistrationTable lacks an agentxRegSession object. Status: consensus forming to maintain multiple indices in the tables and not to instead add new columns in each table for determining cross-table associations. -------------------------------------------------------------------------- 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 Lauren_Heintz@crow.bmc.com Fri Aug 21 13:53:24 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id NAA11148 for ; Fri, 21 Aug 1998 13:53:24 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id NAA18578 for ; Fri, 21 Aug 1998 13:51:28 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma013693; Fri, 21 Aug 98 13:39:41 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id NAA20244 for ; Fri, 21 Aug 1998 13:38:58 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma014661; Fri, 21 Aug 98 13:34:46 -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 NAA01325; Fri, 21 Aug 1998 13:35:19 -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 LAA07448 for ; Fri, 21 Aug 1998 11:31:12 -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 NAA00178; Fri, 21 Aug 1998 13:31:08 -0500 (CDT) Message-ID: <35DDBC3C.B0F5C60@bmc.com> Date: Fri, 21 Aug 1998 11:28:12 -0700 From: Lauren Heintz X-Mailer: Mozilla 4.04 [en] (WinNT; U) MIME-Version: 1.0 To: agentx@peer.com Subject: AgentX MIB issue 10 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Issue 10: Must an agentxSessionEntry be removed from the session table after a session has been closed for any reason? If so, the last sentence in the agentxSessionAdminStatus description should be removed. Status: new issue, needs discussion -------------------------------------------------------------------------- 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 Lauren_Heintz@crow.bmc.com Fri Aug 21 13:58:26 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id NAA11191 for ; Fri, 21 Aug 1998 13:58:26 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id NAA20801 for ; Fri, 21 Aug 1998 13:56:31 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma015761; Fri, 21 Aug 98 13:45:03 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id NAA27076 for ; Fri, 21 Aug 1998 13:44:24 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma006790; Fri, 21 Aug 98 13:28:41 -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 NAA29411; Fri, 21 Aug 1998 13:28:31 -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 LAA07294 for ; Fri, 21 Aug 1998 11:22:04 -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 NAA28169; Fri, 21 Aug 1998 13:22:01 -0500 (CDT) Message-ID: <35DDBA16.973CF826@bmc.com> Date: Fri, 21 Aug 1998 11:19:02 -0700 From: Lauren Heintz X-Mailer: Mozilla 4.04 [en] (WinNT; U) MIME-Version: 1.0 To: agentx@peer.com Subject: AgentX MIB issue 1. Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Issue 1: Should AgentxTCPAddress and AgentxTCPDomain TCs be defined outside of the AgentX MIB? Where? Also, similar TCs need to be defined for Unix Domain Sockets, and for IPv6. Status: consensus forming that these TCs should be administered by IANA. See Mike Daniele's proposed draft on this subject (draft-daniele-iana-addr-mib-00.txt). -------------------------------------------------------------------------- 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 Lauren_Heintz@crow.bmc.com Fri Aug 21 14:09:04 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id OAA11293 for ; Fri, 21 Aug 1998 14:09:04 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id OAA25441 for ; Fri, 21 Aug 1998 14:07:09 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma019685; Fri, 21 Aug 98 13:53:54 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id NAA08834 for ; Fri, 21 Aug 1998 13:53:15 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma020581; Fri, 21 Aug 98 13:39: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 NAA02352; Fri, 21 Aug 1998 13:39:37 -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 LAA07484 for ; Fri, 21 Aug 1998 11:34:41 -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 NAA01100; Fri, 21 Aug 1998 13:34:37 -0500 (CDT) Message-ID: <35DDBD09.681A8DBA@bmc.com> Date: Fri, 21 Aug 1998 11:31:37 -0700 From: Lauren Heintz X-Mailer: Mozilla 4.04 [en] (WinNT; U) MIME-Version: 1.0 To: agentx@peer.com Subject: AgentX MIB issue 12 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Issue 12: Remove the comment regarding sysObjectID from the description of the agentxSessionObjectID object. Status: consensus reached to update description. Proposed description: "This value is taken from the 0.id field of the agentx-Open-PDU." -------------------------------------------------------------------------- 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 Lauren_Heintz@crow.bmc.com Fri Aug 21 14:09:27 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id OAA11298 for ; Fri, 21 Aug 1998 14:09:26 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id OAA25603 for ; Fri, 21 Aug 1998 14:07:31 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma019745; Fri, 21 Aug 98 13:54:02 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id NAA08952 for ; Fri, 21 Aug 1998 13:53:21 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma020682; Fri, 21 Aug 98 13:39: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 NAA02296; Fri, 21 Aug 1998 13:39:29 -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 LAA07488 for ; Fri, 21 Aug 1998 11:35:15 -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 NAA01285; Fri, 21 Aug 1998 13:35:11 -0500 (CDT) Message-ID: <35DDBD2A.864514D3@bmc.com> Date: Fri, 21 Aug 1998 11:32:10 -0700 From: Lauren Heintz X-Mailer: Mozilla 4.04 [en] (WinNT; U) MIME-Version: 1.0 To: agentx@peer.com Subject: AgentX MIB issue 13 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Issue 13: Remove agentxConnSessions and agentxConnNumber objects. Status: consensus reached to remove these objects. -------------------------------------------------------------------------- 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 Lauren_Heintz@crow.bmc.com Fri Aug 21 14:11:15 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id OAA11315 for ; Fri, 21 Aug 1998 14:11:15 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id OAA26350 for ; Fri, 21 Aug 1998 14:09:21 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma020793; Fri, 21 Aug 98 13:56:30 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id NAA12306 for ; Fri, 21 Aug 1998 13:55:51 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma023909; Fri, 21 Aug 98 13:41: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 NAA02986; Fri, 21 Aug 1998 13:42:19 -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 LAA07515 for ; Fri, 21 Aug 1998 11:38:22 -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 NAA01965; Fri, 21 Aug 1998 13:38:19 -0500 (CDT) Message-ID: <35DDBDE7.E2625B38@bmc.com> Date: Fri, 21 Aug 1998 11:35:19 -0700 From: Lauren Heintz X-Mailer: Mozilla 4.04 [en] (WinNT; U) MIME-Version: 1.0 To: agentx@peer.com Subject: AgentX MIB issue 17 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Issue 17: Remove the following comment from under the agentxSessionObjectID definition: -- -- Issue: should we describe this more in terms of -- AGENT-CAPABILITIES or sysORTable? -- Status: consensus reached to remove this comment from the document. -------------------------------------------------------------------------- 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 Lauren_Heintz@crow.bmc.com Fri Aug 21 14:25:57 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id OAA11435 for ; Fri, 21 Aug 1998 14:25:57 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id OAA01275 for ; Fri, 21 Aug 1998 14:24:02 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma016194; Fri, 21 Aug 98 13:46:07 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id NAA28393 for ; Fri, 21 Aug 1998 13:45:28 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma007808; Fri, 21 Aug 98 13:29: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 NAA29820; Fri, 21 Aug 1998 13:29:59 -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 LAA07317 for ; Fri, 21 Aug 1998 11:26:12 -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 NAA28897; Fri, 21 Aug 1998 13:26:07 -0500 (CDT) Message-ID: <35DDBB0B.DE516930@bmc.com> Date: Fri, 21 Aug 1998 11:23:07 -0700 From: Lauren Heintz X-Mailer: Mozilla 4.04 [en] (WinNT; U) MIME-Version: 1.0 To: agentx@peer.com Subject: AgentX MIB issue 5 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Issue 5: What table indices should be used? Some favor single indices for efficiency reasons, while others prefer multiple indices to reflect the various inter-table relationships among connections, sessions, and registrations. Status: consensus forming that multiple indices should be retained in the tables to reflect the natural containment hierarchy of AgentX. -------------------------------------------------------------------------- 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 Lauren_Heintz@crow.bmc.com Fri Aug 21 14:26:49 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id OAA11448 for ; Fri, 21 Aug 1998 14:26:48 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id OAA01593 for ; Fri, 21 Aug 1998 14:24:54 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma016653; Fri, 21 Aug 98 13:47:08 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id NAA29673 for ; Fri, 21 Aug 1998 13:46:28 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma006775; Fri, 21 Aug 98 13:28: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 NAA29553; Fri, 21 Aug 1998 13:28:58 -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 LAA07312 for ; Fri, 21 Aug 1998 11:25:22 -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 NAA28716; Fri, 21 Aug 1998 13:25:19 -0500 (CDT) Message-ID: <35DDBADB.5745F638@bmc.com> Date: Fri, 21 Aug 1998 11:22:19 -0700 From: Lauren Heintz X-Mailer: Mozilla 4.04 [en] (WinNT; U) MIME-Version: 1.0 To: agentx@peer.com Subject: AgentX MIB issue 4 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Issue 4: Regarding agentxRegStart and agentxRegEnd, should they be removed and new objects added to more directly reflect the protocol elements? Should their descriptions be updated to clearly reflect how the values of these objects are derived from the protocol elements? Should an example table be added to the document? Status: consensus forming that the MIB should instead reflect the protocol elements, which would involve replacing agentxRegEnd with two objects, agentxRegRangeSubid and agentxRegUpperBound. Also, detailed examples and/or explanatory text would be more appropriately placed in RFC 2257. -------------------------------------------------------------------------- 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 Lauren_Heintz@crow.bmc.com Fri Aug 21 14:32:34 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id OAA11495 for ; Fri, 21 Aug 1998 14:32:33 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id OAA03492 for ; Fri, 21 Aug 1998 14:30:38 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma019429; Fri, 21 Aug 98 13:53:20 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id NAA08015 for ; Fri, 21 Aug 1998 13:52:41 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma020634; Fri, 21 Aug 98 13:39:18 -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 NAA00476; Fri, 21 Aug 1998 13:32:16 -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 LAA07378 for ; Fri, 21 Aug 1998 11:28:38 -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 NAA29447; Fri, 21 Aug 1998 13:28:35 -0500 (CDT) Message-ID: <35DDBB9F.CA6CBDE5@bmc.com> Date: Fri, 21 Aug 1998 11:25:35 -0700 From: Lauren Heintz X-Mailer: Mozilla 4.04 [en] (WinNT; U) MIME-Version: 1.0 To: agentx@peer.com Subject: AgentX MIB issue 8 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Issue 8: The MIB needs to support RFC2257, Section 2, goal 4, which states: "Provide statistics about the protocol operation such as the number of packets to and from each subagent", or have this goal removed from RFC 2257 or modified. Status: consensus forming not to add error counters (whether as scalar or tabular objects). This would involve deleting the above stated goal from RFC 2257. It is felt that these counters primarily aid debugging during protocol development and, due to experience gained from other subagent protocols that also do not contain such error counters, are not required to support interoperable protocol operations. -------------------------------------------------------------------------- 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 Lauren_Heintz@crow.bmc.com Fri Aug 21 14:33:25 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id OAA11510 for ; Fri, 21 Aug 1998 14:33:24 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id OAA03783 for ; Fri, 21 Aug 1998 14:31:30 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma019890; Fri, 21 Aug 98 13:54:20 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id NAA09331 for ; Fri, 21 Aug 1998 13:53:40 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma021044; Fri, 21 Aug 98 13:39: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 NAA02532; Fri, 21 Aug 1998 13:40:06 -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 LAA07496 for ; Fri, 21 Aug 1998 11:36:24 -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 NAA01571; Fri, 21 Aug 1998 13:36:20 -0500 (CDT) Message-ID: <35DDBD6F.89FBE9C5@bmc.com> Date: Fri, 21 Aug 1998 11:33:19 -0700 From: Lauren Heintz X-Mailer: Mozilla 4.04 [en] (WinNT; U) MIME-Version: 1.0 To: agentx@peer.com Subject: AgentX MIB issue 14 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Issue 14: agentxConnTransportAddress description needs to be updated to reflect that this object is likely to be null for Unix domain sockets, since the subagent need not bind a filename to its local socket. Status: consensus reached to update description. Proposed description: "This is the transport address of the remote (subagent) end of this connection to the master agent. This value may be a zero-length string for certain types of transport address end-points. For example, subagents need not bind a filename to its local socket when using Unix Domain Sockets, and so this value will be a zero-length string." -------------------------------------------------------------------------- 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 Lauren_Heintz@crow.bmc.com Fri Aug 21 14:34:13 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id OAA11520 for ; Fri, 21 Aug 1998 14:34:13 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id OAA04062 for ; Fri, 21 Aug 1998 14:32:19 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma020274; Fri, 21 Aug 98 13:55:16 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id NAA10558 for ; Fri, 21 Aug 1998 13:54:34 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma021860; Fri, 21 Aug 98 13:40: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 NAA02650; Fri, 21 Aug 1998 13:40:36 -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 LAA07499 for ; Fri, 21 Aug 1998 11:37:03 -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 NAA01714; Fri, 21 Aug 1998 13:37:00 -0500 (CDT) Message-ID: <35DDBD98.847B1813@bmc.com> Date: Fri, 21 Aug 1998 11:34:00 -0700 From: Lauren Heintz X-Mailer: Mozilla 4.04 [en] (WinNT; U) MIME-Version: 1.0 To: agentx@peer.com Subject: AgentX MIB issue 15 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Issue 15: The Registration group lacks the "number" and "lastChange" objects for its table. Corresponding objects are included in the other two groups (connections and sessions). Status: consensus reached to make each group consistent, and to include a "agentxRegistrationTablelastChanged" object, but not a "number" object. -------------------------------------------------------------------------- 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 Lauren_Heintz@crow.bmc.com Fri Aug 21 14:35:07 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id OAA11528 for ; Fri, 21 Aug 1998 14:35:07 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id OAA04403 for ; Fri, 21 Aug 1998 14:33:13 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma020733; Fri, 21 Aug 98 13:56:22 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id NAA12083 for ; Fri, 21 Aug 1998 13:55:42 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma023051; Fri, 21 Aug 98 13:41: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 NAA02826; Fri, 21 Aug 1998 13:41:30 -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 LAA07505 for ; Fri, 21 Aug 1998 11:37:46 -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 NAA01792; Fri, 21 Aug 1998 13:37:42 -0500 (CDT) Message-ID: <35DDBDC2.91BAECAC@bmc.com> Date: Fri, 21 Aug 1998 11:34:42 -0700 From: Lauren Heintz X-Mailer: Mozilla 4.04 [en] (WinNT; U) MIME-Version: 1.0 To: agentx@peer.com Subject: AgentX MIB issue 16 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Issue 16: The "number" objects are superfluous? Status: consensus reached to remove all "number" objects. -------------------------------------------------------------------------- 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 case@snmp.com Fri Aug 21 14:36:34 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id OAA11541 for ; Fri, 21 Aug 1998 14:36:34 -0500 (CDT) From: case@snmp.com Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id OAA04905 for ; Fri, 21 Aug 1998 14:34:39 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma021484; Fri, 21 Aug 98 13:58:05 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id NAA14365 for ; Fri, 21 Aug 1998 13:57:26 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma024565; Fri, 21 Aug 98 13:42: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 NAA03103; Fri, 21 Aug 1998 13:42:49 -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 LAA07526 for ; Fri, 21 Aug 1998 11:39:20 -0700 (PDT) Received: (from uucp@localhost) by cashew.bmc.com (8.8.8/8.8.8) id NAA06474 for ; Fri, 21 Aug 1998 13:39:17 -0500 (CDT) Received: from seymour4.snmp.com(192.147.142.4) by cashew.bmc.com via smap (V2.0) id xma006455; Fri, 21 Aug 98 13:38:55 -0500 Received: by seymour4.snmp.com (cf v2.11c-SNMP) id OAA11281; Fri, 21 Aug 1998 14:38:51 -0400 (EDT) Date: Fri, 21 Aug 1998 14:38:51 -0400 (EDT) Message-Id: <199808211838.OAA11281@seymour4.snmp.com> To: daniele@zk3.dec.com Subject: Re: Dynamic row creation Cc: agentx@peer.com, manne@siemensdc.com hi mike i am happy to see that we agree on several things i don't understand why you want to debate this ... i argued for some features that i thought were necessary, based on my knowledge of what real customers have demanded of our products, and as i said, i was ineffective in getting them into agentx this guy appears to need/want them ... they aren't there ... he asked to understand, and i tried to share some useful information with him and point him to a source internal to his company for some more i have no interest in debating these issues with you, but i must address the part that you say is "utter nonsense" the implementation we tested at the testing event was sunos ... the agent i tested during the snmpv3 testing event returned an ifTable with 3 or 4 entries ... le0 (ethernet), le1 (ethernet), lo0 (loopback) and [optionally] a ppp interface that came and went depending on the state of the ppp subsystem that agent was able to "do the right thing" with ifNumber.0 the agent that i tested for agentx was unable to "do the right thing" with ifNumber.0 you say you can look in the kernel structure to see the number of interfaces perhaps you should show me how this is done on sunos ... to reflect whether zero, one, or many of the serial interfaces are being used for ppp i think that even if you can, it is uncontroversial that there are many situations, like the gentleman's from siemens, where there is no central authority that can be consulted -- reminder, his is an embedded environment you say i made no mention of this problem when in reality, i did and you got huffy then too ... i also mentioned it in email that you saw when the draft testing report was circulated you remember correctly showing the ifTable doing the right thing with agentx ... and that is partial success .... i said that ifNumber was the problem -- that we had difficulty using agentx to implement standard mib modules like mib 2 in a distributed way without undue cooperation between supposedly independent subagents or some other "behind the back" mechanism that is outside the agentx spec i don't see why this is a subject of debate ... i am only repeating here what is stated on pages 8 and 9 of the spec ... this gentleman is merely another example of an application is not satisfied by the agentx lowest common denominator design indeed, the agentx spec says: 4) Subagents implement rows in "complex tables". Complex tables here are defined as tables permitting row creation, or whose MIB also defines an object that counts entries in the table. Examples include the MIB-2 ifTable (due to ifNumber), and the RMON historyControlTable. The subagent that implements such a counter object (like ifNumber) must go beyond AgentX to correctly implement it. This is an implementation issue (and most new MIB designs no longer include such objects). so, the spec agrees that it is unable to meet the real-world need of the gentleman to whom i was responding -- it agrees that it is sometimes impossible to implement standard mibs, like mib2, with independently developed subagents doing individual rows unless one does implementation-specific things outside of agentx this is what i said to him he said he thought that was in conflict with the requirements of what agentx set out to do, at least his requirements, and his conclusion is correct so, since you seem to take offense at the word broken, please let me modify what i said ... what agentx does is "ok" -- it just is not enough to meet his needs and it does do (and not do) what it says it does (and what it says it does not do) how come i am the bad guy for correctly citing what the spec says? i am only the messenger come on mike, you say that i never made a "proposal of any type" and that just is not fair in that i made several contributions, few of which were accepted (unless made through david battle) i lost my enthusiasm for contributing when an effort that i fostered and partially funded was discarded without consideration [do you remember the internet draft (by d. battle and u. haebel) that spoke to instance reservation (later renamed allocation) that never was discussed after being rejected by maria greene as "too complex" although it directly addressed the concerns subsequently articulated by juergen on this list?] it is hard to remain enthusiastic about continuing to contribute when every idea presented is rejected, sometimes without a fair hearing i am not the only one who lost enthusiasm -- i got a private note yesterday after my posting that stated that they appreciated my note and said, in part: You weren't the only one who thought it was broken. I sent numerous private emails with examples of why it was broken. I was told it wasn't an issue that agentx needed to address. At that point, it was no longer worth fighting for, I knew that xxx_company_suppressed_xxx could never use a product like this. So, I threw my hands in the air and walked away. finally, i find it frustrating that i invested the time to give a carefully considered response to the gentleman from siemens and that you choose to bash me for it, then say that you did only did a quick read of the messages regards, jdc -------- From daniele@zk3.dec.com Fri Aug 21 13:24:34 1998 Return-Path: Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by seymour16.snmp.com with ESMTP (cf v2.9s-SNMP) id NAA09493; Fri, 21 Aug 1998 13:24:33 -0400 (EDT) Received: from flume.zk3.dec.com (yflume.zk3.dec.com [16.140.16.14]) by mail13.digital.com (8.8.8/8.8.8/WV1.0g) with SMTP id NAA28651; Fri, 21 Aug 1998 13:14:18 -0400 (EDT) Received: from bernie.zk3.dec.com by flume.zk3.dec.com (5.65v4.0/1.1.8.2/16Jan95-0946AM) id AA18557; Fri, 21 Aug 1998 13:14:17 -0400 Received: from localhost by bernie.zk3.dec.com; (5.65/1.1.8.2/22Aug96-1117AM) id AA30453; Fri, 21 Aug 1998 13:14:31 -0400 Message-Id: <9808211714.AA30453@bernie.zk3.dec.com> To: case@snmp.com Cc: manne@siemensdc.com, agentx@peer.com Subject: Re: Dynamic row creation In-Reply-To: Your message of "Thu, 20 Aug 98 12:48:00 EDT." <199808201648.MAA23467@seymour4.snmp.com> Date: Fri, 21 Aug 98 13:14:31 -0400 From: Mike Daniele X-Mts: smtp Status: R >one of the early agent-x design decisions that has been followed fastidiously >is that dispatching to subagents is done only via groups of non-overlapping >regions that have been registered by subagents; i.e., that subagents register >to "pull" or "solicit" requests >implicit in this design decision is the reality that the master agent cannot >dispatch a region that has not yet been registered ... and therefore a manager >cannot create something that a subagent hasn't already "invited" by indicating >a willingness to handle it via a registration request Correct. These same statements are also true, I believe, of every other extensible agent technology. That is, the master would dispatch to whatever registered ifTable. The difference is that AgentX only dispatches to a single registrant, while other technologies may dispatch to several. See below for more discussion. >furthermore, a design decision was made to not include in the design any >standard mechanism for allowing one subagent to get information from other >parts of the agent (objects handled by the master agent or other subagents) >so only "behind the back" mechanisms -- to use your words -- must be used >to implement what you want That's also technically correct. However, I point out that the the specific requirements Aharon presented apparently go well beyond this, and would not be helped greatly if AgentX did have this capability. (That is, this "advertising of instances" between components [not necessarily subagents in our usual understanding of that term] is probably beyond the scope of what an extensible agent should do.) >these are two of the problems that crop up if one uses agentx as the >master agent <--> subagent communications mechanisms and are the result >of design decisions made in the interest of simplicity >these design decisions severely limit the usefulness of the design -- in >fact, the recent testing event demonstrated that one cannot use agentx >to implement even mib-2's interfaces group with different parts of the >ifTable handled by different subagents and still be able to get ifNumber >correct -- unless one uses your so-called "behind the back" mechanisms That is utter nonsense. On many (most) platforms on which multivendor subagents will exist, interface data is available from the native system (e.g., "the kernel"). This is certainly the case for all UNIX variants and (I believe) all MS Windows variants. At the bakeoff your subagents were running on a SunOS system. See above. So instead of simply querying the managed resource to determine ifNumber, you pronounce AgentX broken. Also, during the bakeoff you made no mention of this problem. I know this because it was our master agent your subagent was successfully interoperating with. What *I* remember about it is that a getnext sweep of the ifTable worked correctly, with our master querying your two subagents that had each registered fully qualifed instances in separate rows of ifTable. I call this success, not broken specs. >the agentx document talks about some of these problems with implementing >standard mibs, but yours is a real-life product that suffers from these >limitations I don't believe so, based on further conversations. But I could be wrong. >in my opinion, this is severely broken, and i argued against it at the time, >but i was ineffective in convincing the group that it was broken -- it is >too bad that you were not around and vocal in those days The group opted for simple. One of the WG members also floated a proposal (remember "unionized registrations"?) for more complex types of registrations, in direct response to your concerns. There were no replies. You never made a proposal of any type, simply labeled things broken. This strategy of choosing "simple" in v1 seems to have served the community well in the past (for example, SNMPv1). >a better way? there are other master agent <--> subagent products in the >market today that do not suffer from these severe problems that agentx has >you might want to check with a resource within your own >company, Helmut.Wrubel@vs.siemens.de to explore alternatives Your protocol suffers from a serious design flaw. Multiple subagents may register for identical OIDs. They can each implement the same instance. The master agent queries them all, then, in an implemention-specific manner, decides which value to use. The WG decided this was not appropriate for an internet-standard extensible agent protocol. Please note I said *protocol*. This is not an attempt to bash your excellent product offerings. In summary, I believe Aharon's view is that it is acceptable for one subagent to register "the table", and cause other subagents to create and manage individual rows. I also believe this specific case may be one of a particular vendor implementing all components, hence not particularly germane to agentx. But again, my understanding may be wrong since it is based on a few quick mail messages. Mike From Lauren_Heintz@crow.bmc.com Fri Aug 21 14:44:13 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id OAA11613 for ; Fri, 21 Aug 1998 14:44:12 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id OAA07616 for ; Fri, 21 Aug 1998 14:42:18 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma025370; Fri, 21 Aug 98 14:06:58 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id OAA26157 for ; Fri, 21 Aug 1998 14:06:20 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma002127; Fri, 21 Aug 98 13:48:07 -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 NAA02291; Fri, 21 Aug 1998 13:39: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 LAA07478 for ; Fri, 21 Aug 1998 11:33:50 -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 NAA00845; Fri, 21 Aug 1998 13:33:47 -0500 (CDT) Message-ID: <35DDBCDA.D4E5AA16@bmc.com> Date: Fri, 21 Aug 1998 11:30:50 -0700 From: Lauren Heintz X-Mailer: Mozilla 4.04 [en] (WinNT; U) MIME-Version: 1.0 To: agentx@peer.com Subject: AgentX MIB issue 11 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Issue 11: Should the Utf8String TC be removed, and should agentxSessionDescr be of type snmpAdminString instead? Status: old issue, still lacks discussion -------------------------------------------------------------------------- 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 bnatale@acecomm.com Fri Aug 21 15:44:38 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id PAA12128 for ; Fri, 21 Aug 1998 15:44:37 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id PAA14179 for ; Fri, 21 Aug 1998 15:42:42 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma013427; Fri, 21 Aug 98 15:40:13 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id PAA26104 for ; Fri, 21 Aug 1998 15:39:34 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma024081; Fri, 21 Aug 98 15:38: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 PAA01159; Fri, 21 Aug 1998 15:38:36 -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 NAA07947 for ; Fri, 21 Aug 1998 13:23:25 -0700 (PDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id PAA12119 for ; Fri, 21 Aug 1998 15:23:24 -0500 (CDT) Received: from relay1.smtp.psi.net(38.8.14.2) by almond.bmc.com via smap (V2.0) id xma012107; Fri, 21 Aug 98 15:23:16 -0500 Received: from [192.152.208.5] (helo=acecomm.com) by relay1.smtp.psi.net with smtp (Exim 1.90 #1) id 0z9xhc-0004L5-00; Fri, 21 Aug 1998 16:22:34 -0400 Received: from bnatale by acecomm.com (5.65/3.2.083191-ACE*COMM) id AA02036; Fri, 21 Aug 1998 16:24:56 -0400 Message-Id: <9808212024.AA02036@acecomm.com> X-Sender: natale@nips.acec.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1 Date: Fri, 21 Aug 1998 16:24:54 -0400 To: case@snmp.com From: Bob Natale Subject: Re: Dynamic row creation Cc: daniele@zk3.dec.com, agentx@peer.com, manne@siemensdc.com In-Reply-To: <199808211838.OAA11281@seymour4.snmp.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" >At 8/21/98 02:38 PM, case@snmp.com wrote: Hi Jeff, everyone: <...> >i am not the only one who lost enthusiasm -- I am sorry and surprised to hear that. I really did not detect that attitude at the AgentX testing event. (Then again I must admit that I am definitely not the most perceptive person around! :-) >i got a private note yesterday after my posting that >stated that they appreciated my note and said, in part: Given the current "Wag the Dog" political climate here in the US, responding to such public "sound byte"-postings of private e-mail is probably foolhardy...nonetheless, I'll chance it: >>You weren't the only one who thought it was broken. I sent >>numerous private emails with examples of why it was broken. I would suggest that examples of such import would be more effective if posted to the public forum. I encourage this person--whoever he or she may be--and anyone else with similar input, to go ahead now and post it to the list. Let the group try to resolve it or schedule it for future work if warranted. (While I don't encourage anonymous posts, I guess it would be better to get even them where "fatal flaw" examples are at stake than to not get them at all.) >>I was told it wasn't an issue that agentx needed to address. I guess the validity of that response would have to be weighted by the limited audience. >>At that point, it was no longer worth fighting for, I knew >>that xxx_company_suppressed_xxx could never use a product >>like this. So, I threw my hands in the air and walked away. Well, ok...but a more effective approach might have been to give the full WG a chance to deal with the concerns. Furthermore, we should all note that AgentX is a protocol, *not* a product. Specific products are built with the protocol. Products that want to meet requirements that go beyond the standard capabilities provided by AgentX are free to do so. In doing so, they increasingly take on the characteristics of the various existing products built on vendor-specific proprietary protocols...with all the attendant advantages *and* disadvantages. A requirement set that can be completely met by the standard capabilities--especially configurations consisting of multiple MIBs each serviced by a (logically) distinct sub-agent--will tend to benefit greatly from AgentX solutions versus the existing vendor-specific proprietary solutions. More complex requirements will tend to *dilute* the benefit payoff. And, except for any given permanent set of requirements which are already being satisfactorily met by a pre-existing investment in a vednor-specfic proprietary solution, it is hard to imagine any requirement set for which the benefit payoff from an AgentX standard platform would fall into the negative range. 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 Aug 21 16:36:55 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id QAA12555 for ; Fri, 21 Aug 1998 16:36:54 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id QAA18863 for ; Fri, 21 Aug 1998 16:35:00 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma018492; Fri, 21 Aug 98 16:34:08 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id QAA21187 for ; Fri, 21 Aug 1998 16:33:28 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma018863; Fri, 21 Aug 98 16:31: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 QAA15556; Fri, 21 Aug 1998 16:32:17 -0500 (CDT) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id OAA08289 for agentx@peer.com; Fri, 21 Aug 1998 14:27:29 -0700 (PDT) Date: Fri, 21 Aug 1998 14:27:29 -0700 (PDT) From: Randy Presuhn Message-Id: <199808212127.OAA08289@dorothy.bmc.com> To: agentx@peer.com Subject: Re: AgentX MIB issue 6 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi - > Date: Fri, 21 Aug 1998 11:24:03 -0700 > From: Lauren Heintz > To: agentx@peer.com > Subject: AgentX MIB issue 6 > > Issue 6: The RegistrationTable lacks an agentxRegSession object. > > Status: consensus forming to maintain multiple indices > in the tables and not to instead add new columns > in each table for determining cross-table associations. ... It sounds like this would require both the connection and the session identifiers to be included in the indexes for the registration table if some of the other proposed mods are accepted. ----------------------------------------------------------------------- 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 Fri Aug 21 16:39:08 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id QAA12580 for ; Fri, 21 Aug 1998 16:39:07 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id QAA19464 for ; Fri, 21 Aug 1998 16:37:12 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma017791; Fri, 21 Aug 98 16:32:36 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id QAA19121 for ; Fri, 21 Aug 1998 16:31:54 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma017547; Fri, 21 Aug 98 16:30: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 QAA15287; Fri, 21 Aug 1998 16:31: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 OAA08275 for ; Fri, 21 Aug 1998 14:23:02 -0700 (PDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id QAA16811 for ; Fri, 21 Aug 1998 16:23:01 -0500 (CDT) Received: from mail11.digital.com(192.208.46.10) by almond.bmc.com via smap (V2.0) id xma016808; Fri, 21 Aug 98 16:22:58 -0500 Received: from flume.zk3.dec.com (yflume.zk3.dec.com [16.140.16.14]) by mail11.digital.com (8.8.8/8.8.8/WV1.0g) with SMTP id RAA29032; Fri, 21 Aug 1998 17:22:56 -0400 (EDT) Received: from bernie.zk3.dec.com by flume.zk3.dec.com (5.65v4.0/1.1.8.2/16Jan95-0946AM) id AA11093; Fri, 21 Aug 1998 17:22:55 -0400 Received: from localhost by bernie.zk3.dec.com; (5.65/1.1.8.2/22Aug96-1117AM) id AA30614; Fri, 21 Aug 1998 17:23:14 -0400 Message-Id: <9808212123.AA30614@bernie.zk3.dec.com> To: case@snmp.com Cc: agentx@peer.com Subject: Re: Dynamic row creation In-Reply-To: Your message of "Fri, 21 Aug 98 14:38:51 EDT." <199808211838.OAA11281@seymour4.snmp.com> Date: Fri, 21 Aug 98 17:23:13 -0400 From: Mike Daniele X-Mts: smtp Jeff, >finally, i find it frustrating that i invested the time to give a carefully >considered response to the gentleman from siemens and that you choose >to bash me for it, then say that you did only did a quick read of the messages No, I said my understanding of Siemens' requirements were based on a few quick messages (with Aharon). I've read your postings quite carefully :-) My overall points were: 1) I don't believe (again, based on the limited exchange so far) that putting subagent-to-subagent queries in AgentX would help them. I apologize to Aharon for being placed in the middle of this, and possibly taken out of context or misrepresented. 2) ifNumber has nothing to do with Aharon's questions. Yet you took it as (another) occassion to, for want of a better term, "market" against AgentX. 3) You could easily have made your subagent do ifNumber correctly at the bakeoff if you wanted to. I don't believe you wanted to. >come on mike, you say that i never made a "proposal of any type" and that >just is not fair in that i made several contributions, few of which were >accepted (unless made through david battle) Sorry for the ambiguous wording, but I thought the context scoped it sufficiently. I believe it is correct that you folks never made a proposal about how to handle "shared aggregates" (ifNumber). In fact, I still honestly don't know how you expect it to work. After the bakeoff testing was over, we had a short discussion about it (during which, apparently, I grew huffy :-). But it wasn't real clear to me. Maybe I was both huffy and tired. Also, I'm honestly suprised to hear you say none of your contributions were accepted. I thought just about all of them were. Well, enough. See you soon, Mike From rpresuhn@dorothy.bmc.com Fri Aug 21 16:54:23 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id QAA12711 for ; Fri, 21 Aug 1998 16:54:23 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id QAA22012 for ; Fri, 21 Aug 1998 16:52:27 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma021214; Fri, 21 Aug 98 16:50:36 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id QAA09803 for ; Fri, 21 Aug 1998 16:49:56 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma007707; Fri, 21 Aug 98 16:48:32 -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 QAA19960; Fri, 21 Aug 1998 16:49:00 -0500 (CDT) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id OAA08353 for agentx@peer.com; Fri, 21 Aug 1998 14:38:58 -0700 (PDT) Date: Fri, 21 Aug 1998 14:38:58 -0700 (PDT) From: Randy Presuhn Message-Id: <199808212138.OAA08353@dorothy.bmc.com> To: agentx@peer.com Subject: Re: AgentX MIB issue 10 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi - > Date: Fri, 21 Aug 1998 11:28:12 -0700 > From: Lauren Heintz > To: agentx@peer.com > Subject: AgentX MIB issue 10 > > Issue 10: Must an agentxSessionEntry be removed from the session > table after a session has been closed for any reason? If so, the > last sentence in the agentxSessionAdminStatus description should > be removed. ... I assume you're trying to account for the (transient) condition where the session has ended but the master agent hasn't finished cleaning things up. I think this might be what Marshall had in mind with the definition of smuxPstatus in RFC 1227, which provides a bit more guidance to the manager attempting to interpret one of these rows. ----------------------------------------------------------------------- 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 Fri Aug 21 16:57:14 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id QAA12737 for ; Fri, 21 Aug 1998 16:57:13 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id QAA22909 for ; Fri, 21 Aug 1998 16:55:19 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma021592; Fri, 21 Aug 98 16:51:33 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id QAA11004 for ; Fri, 21 Aug 1998 16:50:54 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma007758; Fri, 21 Aug 98 16: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 QAA19970; Fri, 21 Aug 1998 16:49:04 -0500 (CDT) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id OAA08370 for agentx@peer.com; Fri, 21 Aug 1998 14:43:06 -0700 (PDT) Date: Fri, 21 Aug 1998 14:43:06 -0700 (PDT) From: Randy Presuhn Message-Id: <199808212143.OAA08370@dorothy.bmc.com> To: agentx@peer.com Subject: Re: AgentX MIB issue 11 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi - > Date: Fri, 21 Aug 1998 11:30:50 -0700 > From: Lauren Heintz > To: agentx@peer.com > Subject: AgentX MIB issue 11 > > Issue 11: Should the Utf8String TC be removed, and should > agentxSessionDescr be of type snmpAdminString instead? ... I think we should do this. We should also do this for agentxRegContext, after getting agreement that the update to RFC 2257 should align the context definition with RFC 2271. ----------------------------------------------------------------------- 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 Fri Aug 21 17:36:21 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id RAA13066 for ; Fri, 21 Aug 1998 17:36:20 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id RAA26826 for ; Fri, 21 Aug 1998 17:34:25 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma025249; Fri, 21 Aug 98 17:30:05 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id RAA19229 for ; Fri, 21 Aug 1998 17:29:25 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma017668; Fri, 21 Aug 98 17:28: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 RAA29156; Fri, 21 Aug 1998 17:28: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 PAA08650 for ; Fri, 21 Aug 1998 15:20:54 -0700 (PDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id RAA24339 for ; Fri, 21 Aug 1998 17:20:53 -0500 (CDT) Received: from relay1.smtp.psi.net(38.8.14.2) by almond.bmc.com via smap (V2.0) id xma024331; Fri, 21 Aug 98 17:20:41 -0500 Received: from [192.152.208.5] (helo=acecomm.com) by relay1.smtp.psi.net with smtp (Exim 1.90 #1) id 0z9zXd-0000eT-00; Fri, 21 Aug 1998 18:20:21 -0400 Received: from bnatale by acecomm.com (5.65/3.2.083191-ACE*COMM) id AA03173; Fri, 21 Aug 1998 18:22:50 -0400 Message-Id: <9808212222.AA03173@acecomm.com> X-Sender: natale@nips.acec.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1 Date: Fri, 21 Aug 1998 18:22:47 -0400 To: Randy Presuhn From: Bob Natale Subject: Re: AgentX MIB issue 10 Cc: agentx@peer.com In-Reply-To: <199808212138.OAA08353@dorothy.bmc.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" >At 8/21/98 02:38 PM, Randy Presuhn wrote: Hi Randy, >> Issue 10: Must an agentxSessionEntry be removed from the session >> table after a session has been closed for any reason? If so, the >> last sentence in the agentxSessionAdminStatus description should >> be removed. >... > >I assume you're trying to account for the (transient) condition where >the session has ended but the master agent hasn't finished cleaning >things up. I think this might be what Marshall had in mind with the >definition of smuxPstatus in RFC 1227, which provides a bit more >guidance to the manager attempting to interpret one of these rows. Yes...*very* transient condition...I think it would suffice simply to say in the DESCRIPTION of agentxSessionAdminStatus that when its value is down(2)--which is the only value allowed other than up(1(-- it means that the session is in the process of being closed and the row will imminently disappear. The "last sentence" of that DESCRIPTION currently says something like "when read, this value is always up(1)"...I think that was just a mistake from the beginning. 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 Aug 21 17:37:37 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id RAA13084 for ; Fri, 21 Aug 1998 17:37:37 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id RAA27227 for ; Fri, 21 Aug 1998 17:35:41 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma025903; Fri, 21 Aug 98 17:31:36 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id RAA21242 for ; Fri, 21 Aug 1998 17:30:55 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma017654; Fri, 21 Aug 98 17:28: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 RAA29142; Fri, 21 Aug 1998 17:28: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 PAA08707 for ; Fri, 21 Aug 1998 15:24:26 -0700 (PDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id RAA24502 for ; Fri, 21 Aug 1998 17:24:25 -0500 (CDT) Received: from relay1.smtp.psi.net(38.8.14.2) by almond.bmc.com via smap (V2.0) id xma024490; Fri, 21 Aug 98 17:24:18 -0500 Received: from [192.152.208.5] (helo=acecomm.com) by relay1.smtp.psi.net with smtp (Exim 1.90 #1) id 0z9zbE-0001B9-00; Fri, 21 Aug 1998 18:24:07 -0400 Received: from bnatale by acecomm.com (5.65/3.2.083191-ACE*COMM) id AA03193; Fri, 21 Aug 1998 18:26:37 -0400 Message-Id: <9808212226.AA03193@acecomm.com> X-Sender: natale@nips.acec.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1 Date: Fri, 21 Aug 1998 18:26:34 -0400 To: Randy Presuhn From: Bob Natale Subject: Re: AgentX MIB issue 6 Cc: agentx@peer.com In-Reply-To: <199808212127.OAA08289@dorothy.bmc.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" >At 8/21/98 02:27 PM, Randy Presuhn wrote: Hi Randy, >> Issue 6: The RegistrationTable lacks an agentxRegSession object. >> >> Status: consensus forming to maintain multiple indices >> in the tables and not to instead add new columns >> in each table for determining cross-table associations. >... > >It sounds like this would require both the connection and the >session identifiers to be included in the indexes for the >registration table if some of the other proposed mods are >accepted. Yes, that is true. And the primary mod to RFC 2257 involved is simply that the h.SessionID values must be unique only within the context (normal sense of the word) of a connection, not "globablly" unique as the text now says. I personally find that change quite acceptable (removing my objection to the multiple indices in the MIB table), but I think Mike hinted at something about digging up a rationale for the "globally" unique requirement...? 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 Aug 21 18:03:15 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id SAA13303 for ; Fri, 21 Aug 1998 18:03:14 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id SAA00207 for ; Fri, 21 Aug 1998 18:01:20 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma029147; Fri, 21 Aug 98 17:58:13 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id RAA14725 for ; Fri, 21 Aug 1998 17:57:34 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma012612; Fri, 21 Aug 98 17:55: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 RAA06045; Fri, 21 Aug 1998 17:56:33 -0500 (CDT) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id PAA08816 for agentx@peer.com; Fri, 21 Aug 1998 15:44:47 -0700 (PDT) Date: Fri, 21 Aug 1998 15:44:47 -0700 (PDT) From: Randy Presuhn Message-Id: <199808212244.PAA08816@dorothy.bmc.com> To: agentx@peer.com Subject: Re: AgentX MIB issue 6 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi - > Date: Fri, 21 Aug 1998 18:26:34 -0400 > To: Randy Presuhn > From: Bob Natale > Subject: Re: AgentX MIB issue 6 > Cc: agentx@peer.com ... > I personally find that change quite acceptable (removing my > objection to the multiple indices in the MIB table), but I > think Mike hinted at something about digging up a rationale > for the "globally" unique requirement...? ... He already did, though he may have more to say on this. The arguments presented so far are based on internal implementation convenience. I think the guidelines for developing protocol requirements in RFC 2119, especially clauses 5 and 6, suggest that this would be an over-specification. ----------------------------------------------------------------------- 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 Aug 21 20:03:22 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id UAA14293 for ; Fri, 21 Aug 1998 20:03:22 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id UAA06412 for ; Fri, 21 Aug 1998 20:01:28 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma005980; Fri, 21 Aug 98 20:00:02 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id TAA28010 for ; Fri, 21 Aug 1998 19:59:21 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma027057; Fri, 21 Aug 98 19:58: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 TAA26869; Fri, 21 Aug 1998 19:58: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 RAA09723 for ; Fri, 21 Aug 1998 17:41:43 -0700 (PDT) Received: (from uucp@localhost) by cashew.bmc.com (8.8.8/8.8.8) id TAA24415 for ; Fri, 21 Aug 1998 19:41:42 -0500 (CDT) Received: from f179.hotmail.com(207.82.251.65) by cashew.bmc.com via smap (V2.0) id xma024403; Fri, 21 Aug 98 19:41:31 -0500 Received: (qmail 29357 invoked by uid 0); 22 Aug 1998 00:41:30 -0000 Message-ID: <19980822004130.29356.qmail@hotmail.com> Received: from 152.67.249.57 by www.hotmail.com with HTTP; Fri, 21 Aug 1998 17:41:30 PDT X-Originating-IP: [152.67.249.57] From: "Smitha Gudur" To: rpresuhn@dorothy.bmc.com Cc: agentx@peer.com Subject: Re: AgentX MIB issue 11 Content-Type: text/plain Date: Fri, 21 Aug 1998 17:41:30 PDT >From rpresuhn@dorothy.bmc.com Fri Aug 21 14:53:41 1998 >Received: (from uucp@localhost) > by almond.bmc.com (8.8.8/8.8.8) id QAA22455 > for ; Fri, 21 Aug 1998 16:53:37 -0500 (CDT) >Received: from firewall.bmc.com(192.245.162.250) > by almond.bmc.com via smap (V2.0) > id xma022104; Fri, 21 Aug 98 16:52:40 -0500 >Received: (from uucp@localhost) > by dresden.bmc.com (8.8.5/8.8.6) id QAA12539 > for ; Fri, 21 Aug 1998 16:52:00 -0500 (CDT) >Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) > id xma009337; Fri, 21 Aug 98 16:49: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 QAA19941; > Fri, 21 Aug 1998 16:48:57 -0500 (CDT) >Received: (from rpresuhn@localhost) > by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id OAA08370 > for agentx@peer.com; Fri, 21 Aug 1998 14:43:06 -0700 (PDT) >Date: Fri, 21 Aug 1998 14:43:06 -0700 (PDT) >From: Randy Presuhn >Message-Id: <199808212143.OAA08370@dorothy.bmc.com> >To: agentx@peer.com >Subject: Re: AgentX MIB issue 11 >Mime-Version: 1.0 >Content-Type: text/plain; charset=us-ascii >Content-Transfer-Encoding: 7bit > >Hi - > >> Date: Fri, 21 Aug 1998 11:30:50 -0700 >> From: Lauren Heintz >> To: agentx@peer.com >> Subject: AgentX MIB issue 11 >> >> Issue 11: Should the Utf8String TC be removed, and should >> agentxSessionDescr be of type snmpAdminString instead? >... > >I think we should do this. The only reason the Utf8String TC had been defined in agentx mib as snmpv3 drafts were still in progress. Now there is need to do update this. > >We should also do this for agentxRegContext, after getting agreement >that the update to RFC 2257 should align the context definition with >RFC 2271. Yes. I agree. smitha > > ----------------------------------------------------------------------- > 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 KTRTuKPZ4@chi1p9.jp.bmc.com Sat Aug 22 06:55:38 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id GAA01340 for ; Sat, 22 Aug 1998 06:55:37 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id GAA21590 for ; Sat, 22 Aug 1998 06:53:42 -0500 (CDT) From: KTRTuKPZ4@chi1p9.jp.bmc.com Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma021228; Sat, 22 Aug 98 06:52:48 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id GAA17185 for ; Sat, 22 Aug 1998 06:52:05 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma016854; Sat, 22 Aug 98 06:51:53 -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 GAA22237; Sat, 22 Aug 1998 06:52:29 -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 EAA11350 for ; Sat, 22 Aug 1998 04:19:39 -0700 (PDT) Received: (from uucp@localhost) by cashew.bmc.com (8.8.8/8.8.8) id GAA08666 for ; Sat, 22 Aug 1998 06:19:38 -0500 (CDT) Received: from vivek.doe.ernet.in(202.41.100.95) by cashew.bmc.com via smap (V2.0) id xma008658; Sat, 22 Aug 98 06:19:20 -0500 Received: from vikram.doe.ernet.in by vivek.doe.ernet.in (SMI-8.6/SMI-4.1-MHS-7.0) id QAA13216; Sat, 22 Aug 1998 16:43:28 -0500 Received: from by vikram.doe.ernet.in (4.1/SMI-4.1-MHS-7.0) id AB01888; Sat, 22 Aug 98 16:56:00+050 Date: 22 Aug 98 7:16:07 AM Reply-To: byer897@dri2t197.com.eu.bmc.com Message-Id: To: tyroaw531@grw45ht279.net.eu.bmc.com Subject: Daniel 12 Revealed Dear friend: This is an invitation to visit our Homepage that is linked to the FREE Internet publication, THE WISE SHALL UNDERSTAND. Chapter one is entitled "Daniel 12 Revealed." Daniel 12 was NOT to be understood "until the end of the days." It is now unfolded after more than 2,500 years by using a special "key" found in Genesis 2:4; Daniel 12 carries important warnings concerning last-day deception. Our Internet provider is frequently off-line, so please print this letter to preserve the following address where you can access this on-line publication: HTTP://MAINFRAM.CTAZ.COM/PUBLIC/DANIEL12/HOMEPAGE.HTM We know that there are many thinking people who are not happywith popular religion and are seeking greater truth. Please ask God for guidance as you study this material. It is of no cost to you, but we feel He would have us publish this last-day message in printed form for those unable to read it on the Internet. If you agree that it has a special message for this time, we would appreciate any contribution in U.S. funds to help with its publication. Make your check payable to ONE-WAY MINISTRIES. And mail to: Charles and Tish Clever One-Way Ministries P.O. Box 432 Talihina, OK 74571, U.S.A. Your friends in God's service, Charles and Tish Clever E-mail address: REVEALED4U@USA.NET Phone (918) 567-3545 CC: chasclever@mainfram.ctaz.com From 25096848@mail.com Sun Aug 23 22:30:51 1998 Return-Path: <25096848@mail.com> Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id WAA19793 for ; Sun, 23 Aug 1998 22:30:10 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id WAA21980 for ; Sun, 23 Aug 1998 22:28:12 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma021514; Sun, 23 Aug 98 22:26:09 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id WAA00315 for ; Sun, 23 Aug 1998 22:25:29 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma029642; Sun, 23 Aug 98 22:24: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 WAA17595; Sun, 23 Aug 1998 22:24:58 -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 SAA14117; Sun, 23 Aug 1998 18:53:35 -0700 (PDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id UAA17619; Sun, 23 Aug 1998 20:53:34 -0500 (CDT) Received: from zeus.nic.dtag.de(194.25.1.124) by almond.bmc.com via smap (V2.0) id xma017605; Sun, 23 Aug 98 20:53:07 -0500 Received: from mail.com (Dal-VD1-113.anet-dfw.com [207.227.175.13]) by zeus.NIC.DTAG.DE (8.8.5/8.8.0) with SMTP id DAA03347; Mon, 24 Aug 1998 03:41:23 +0200 (MET DST) Message-Id: <199808240141.DAA03347@zeus.NIC.DTAG.DE> Date: Mon, 26 May 97 07:10:52 EST From: "Jack" <25096848@mail.com> To: Friend@public.com Subject: August We can send your Bulk Email promoting your Web site,your favorite program or help you sell your product thru our servers and you won't have to worry about your ISP cutting you off. CALL 972-227-7286 CALL 972-227-7286 ///////////////////////////////////////////////////////////////////////////////////////////////////////// The Mailing List that you are being mailed from was filtered against the Global Remove List at: http://remove-list.com Go to http://remove-list.com add your name to the remove list From mdevlin@eltrax.com Tue Aug 25 02:26:09 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id CAA03385 for ; Tue, 25 Aug 1998 02:26:08 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id CAA13893 for ; Tue, 25 Aug 1998 02:24:06 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma010008; Tue, 25 Aug 98 02:13:07 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id CAA25085 for ; Tue, 25 Aug 1998 02:12:28 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma020503; Tue, 25 Aug 98 02:07:18 -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 CAA06425; Tue, 25 Aug 1998 02:07: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 WAA17010 for ; Mon, 24 Aug 1998 22:49:37 -0700 (PDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id AAA19904 for ; Tue, 25 Aug 1998 00:49:34 -0500 (CDT) Received: from mail.htconn.com(38.245.21.2) by almond.bmc.com via smap (V2.0) id xma017500; Tue, 25 Aug 98 00:39:49 -0500 Received: from AS5200-1-A43.hmc.psghs.edu by mail.htconn.com (SMI-8.6/SMI-SVR4) id BAA01819; Tue, 25 Aug 1998 01:33:04 -0400 From: mdevlin@eltrax.com (T. Max Devlin) To: agentx@peer.com Subject: Re: AgentX MIB issue 5 Date: Tue, 25 Aug 1998 05:27:11 GMT Organization: Eltrax Systems/Hi-TECH Connections Message-ID: <361c1645.35962897@mail.htconn.com> References: <35DDBB0B.DE516930@bmc.com> In-Reply-To: <35DDBB0B.DE516930@bmc.com> X-Mailer: Forte Agent 1.5/32.451 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lauren Heintz said: >Issue 5: What table indices should be used? Some favor single >indices for efficiency reasons, while others prefer multiple >indices to reflect the various inter-table relationships among >connections, sessions, and registrations. > > Status: consensus forming that multiple indices should be > retained in the tables to reflect the natural containment > hierarchy of AgentX. The natural hierarchy, while apparently restrictive in context, may be necessary for providing consistent value to the end-user of AgentX-based products. The market demands that some qausi-official, though not truly technically limiting, conception of connections to sessions to transaction identification occur during the protocol exchanges. The last thing we want is an unmanageable network application, especially the one necessary to manage other network applications. My suggestion that the index identifier "0" be utilized to abrogate the double indexing may seem fantastic, as I am not a programmer, and may not understand all the ramifications. But it would make AgentX an accessible tool, as Internet standards protocols are designed to be, without restricting the capabilities (after all, it is merely the MIB model, not the protocol, which is being restricted, in some context) of commercial implementations of the standard. -- T. Max Devlin Eltrax Systems, Inc. mdevlin@eltrax.com -[Opinions expressed are my own; everyone else, including my employer, has to pay for them, subject to applicable licensing agreement]- From mdevlin@eltrax.com Tue Aug 25 02:26:18 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id CAA03390 for ; Tue, 25 Aug 1998 02:26:18 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id CAA13943 for ; Tue, 25 Aug 1998 02:24:15 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma010055; Tue, 25 Aug 98 02:13:15 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id CAA25179 for ; Tue, 25 Aug 1998 02:12:34 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma020658; Tue, 25 Aug 98 02:07: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 CAA06448; Tue, 25 Aug 1998 02:07:51 -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 WAA17018 for ; Mon, 24 Aug 1998 22:50:00 -0700 (PDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id AAA20004 for ; Tue, 25 Aug 1998 00:49:58 -0500 (CDT) Received: from mail.htconn.com(38.245.21.2) by almond.bmc.com via smap (V2.0) id xma017623; Tue, 25 Aug 98 00:40:13 -0500 Received: from AS5200-1-A43.hmc.psghs.edu by mail.htconn.com (SMI-8.6/SMI-SVR4) id BAA01823; Tue, 25 Aug 1998 01:33:30 -0400 From: mdevlin@eltrax.com (T. Max Devlin) To: agentx@peer.com Subject: Re: AgentX MIB issue 7 Date: Tue, 25 Aug 1998 05:27:38 GMT Organization: Eltrax Systems/Hi-TECH Connections Message-ID: <361e165e.35987517@mail.htconn.com> References: <35DDBB72.BDC0842B@bmc.com> In-Reply-To: <35DDBB72.BDC0842B@bmc.com> X-Mailer: Forte Agent 1.5/32.451 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lauren Heintz said: >Issue 7: Should an agentxErrorTable be added? Would this >remove the need for the agentxRegisterDuplicate object. >This table would have an entry per session (and the SessionID >or agentxSessionIndex would be the index object) and contain a >column of counter32 or gauge32 values for each possible res.error >value. > > Status: consensus forming not to add error counters > (whether as scalar or tabular objects). See issue > eight for more details. I believe the success of AgentX depends on it providing value as an interoperable, multi-vendor standard data transfer protocol, regardless of any limitations it might have. I believe instrumentation must be provided in order to support an acceptably flexible mechanism for monitoring implementation-independant master/sub-agent interactions. To exclude error counters from the basic development effort will preclude vendor inter-operability as a market function. As the still-existant proprietary master/sub-agent implementations are all proprietary and all, in various ways, provide functionality that AgentX can't provide, due to it's requirement as an Internet standard for implementation-independance, it seems that to exclude the opportunity for low-level instrumentation would preclude almost all benefits to the market suppliers to include AgentX in their offerings, as there would be nothing critical for the market to demand. It might seem bass-ackwards, but if AgentX doesn't include error counters, it's not worth wasting time on. IMHO. -- T. Max Devlin Eltrax Systems, Inc. mdevlin@eltrax.com -[Opinions expressed are my own; everyone else, including my employer, has to pay for them, subject to applicable licensing agreement]- From mdevlin@eltrax.com Tue Aug 25 02:26:18 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id CAA03392 for ; Tue, 25 Aug 1998 02:26:18 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id CAA13947 for ; Tue, 25 Aug 1998 02:24:15 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma010054; Tue, 25 Aug 98 02:13:15 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id CAA25192 for ; Tue, 25 Aug 1998 02:12:35 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma020666; Tue, 25 Aug 98 02:07: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 CAA06440; Tue, 25 Aug 1998 02:07: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 WAA17007 for ; Mon, 24 Aug 1998 22:49:37 -0700 (PDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id AAA19898 for ; Tue, 25 Aug 1998 00:49:33 -0500 (CDT) Received: from mail.htconn.com(38.245.21.2) by almond.bmc.com via smap (V2.0) id xma017435; Tue, 25 Aug 98 00:39:35 -0500 Received: from AS5200-1-A43.hmc.psghs.edu by mail.htconn.com (SMI-8.6/SMI-SVR4) id BAA01817; Tue, 25 Aug 1998 01:32:49 -0400 From: mdevlin@eltrax.com (T. Max Devlin) To: agentx@peer.com Subject: Re: AgentX MIB issue 4 Date: Tue, 25 Aug 1998 05:26:57 GMT Organization: Eltrax Systems/Hi-TECH Connections Message-ID: <361b163b.35952895@mail.htconn.com> References: <35DDBADB.5745F638@bmc.com> In-Reply-To: <35DDBADB.5745F638@bmc.com> X-Mailer: Forte Agent 1.5/32.451 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lauren Heintz said: >Issue 4: Regarding agentxRegStart and agentxRegEnd, should they >be removed and new objects added to more directly reflect the >protocol elements? Should their descriptions be updated to clearly >reflect how the values of these objects are derived from the protocol >elements? Should an example table be added to the document? > > Status: consensus forming that the MIB should instead > reflect the protocol elements, which would involve > replacing agentxRegEnd with two objects, > agentxRegRangeSubid and agentxRegUpperBound. > Also, detailed examples and/or explanatory text > would be more appropriately placed in RFC 2257. Given the ongoing difficulty in dealing with registration specifications (as modeled by the SMI and translated into the AgentX and underlying SNMP protocol), I suggest that the table be reconsidered, with the protocol exchange activity being secondary in priority to the granularity of modeling table registrations. If it takes a thousand protocol exchanges to "register" an adequate region of certain tables, then it should be considered a function of the complexity of SMI models, not inadequacy in the protocol's efficiency. -- T. Max Devlin Eltrax Systems, Inc. mdevlin@eltrax.com -[Opinions expressed are my own; everyone else, including my employer, has to pay for them, subject to applicable licensing agreement]- From mdevlin@eltrax.com Tue Aug 25 02:26:23 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id CAA03398 for ; Tue, 25 Aug 1998 02:26:22 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id CAA13971 for ; Tue, 25 Aug 1998 02:24:20 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma010064; Tue, 25 Aug 98 02:13:16 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id CAA25194 for ; Tue, 25 Aug 1998 02:12:35 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma020662; Tue, 25 Aug 98 02:07: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 CAA06439; Tue, 25 Aug 1998 02:07: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 WAA17021 for ; Mon, 24 Aug 1998 22:50:06 -0700 (PDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id AAA20034 for ; Tue, 25 Aug 1998 00:50:05 -0500 (CDT) Received: from mail.htconn.com(38.245.21.2) by almond.bmc.com via smap (V2.0) id xma017674; Tue, 25 Aug 98 00:40:24 -0500 Received: from AS5200-1-A43.hmc.psghs.edu by mail.htconn.com (SMI-8.6/SMI-SVR4) id BAA01825; Tue, 25 Aug 1998 01:33:39 -0400 From: mdevlin@eltrax.com (T. Max Devlin) To: agentx@peer.com Subject: Re: AgentX MIB issue 9 Date: Tue, 25 Aug 1998 05:27:47 GMT Organization: Eltrax Systems/Hi-TECH Connections Message-ID: <361f1664.35993464@mail.htconn.com> References: <35DDBBD9.C3BC11BF@bmc.com> In-Reply-To: <35DDBBD9.C3BC11BF@bmc.com> X-Mailer: Forte Agent 1.5/32.451 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lauren Heintz said: >Issue 9: Should the DEFVAL for agentxRegPriority be changed to 128 >(from 255) to allow subagents to get "in front of" or "behind" the >default priority? > > Status: consensus forming to have DEFVAL become 128 if > RFC 2257 is also appropriately updated. Yes, the late realization that default "lowball" priorities are problematic was quite shocking, but valid. This seems a slam-dunk. -- T. Max Devlin Eltrax Systems, Inc. mdevlin@eltrax.com -[Opinions expressed are my own; everyone else, including my employer, has to pay for them, subject to applicable licensing agreement]- From mdevlin@eltrax.com Tue Aug 25 02:26:23 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id CAA03401 for ; Tue, 25 Aug 1998 02:26:23 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id CAA13973 for ; Tue, 25 Aug 1998 02:24:21 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma010060; Tue, 25 Aug 98 02:13:16 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id CAA25177 for ; Tue, 25 Aug 1998 02:12:34 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma020660; Tue, 25 Aug 98 02:07: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 CAA06441; Tue, 25 Aug 1998 02:07: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 WAA17002 for ; Mon, 24 Aug 1998 22:49:27 -0700 (PDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id AAA19863 for ; Tue, 25 Aug 1998 00:49:25 -0500 (CDT) Received: from mail.htconn.com(38.245.21.2) by almond.bmc.com via smap (V2.0) id xma017310; Tue, 25 Aug 98 00:39:07 -0500 Received: from AS5200-1-A43.hmc.psghs.edu by mail.htconn.com (SMI-8.6/SMI-SVR4) id BAA01813; Tue, 25 Aug 1998 01:32:20 -0400 From: mdevlin@eltrax.com (T. Max Devlin) To: agentx@peer.com Subject: Re: AgentX MIB issue 2 Date: Tue, 25 Aug 1998 05:26:28 GMT Organization: Eltrax Systems/Hi-TECH Connections Message-ID: <361915f3.35880924@mail.htconn.com> References: <35DDBA4E.7E957DCD@bmc.com> In-Reply-To: <35DDBA4E.7E957DCD@bmc.com> X-Mailer: Forte Agent 1.5/32.451 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lauren Heintz said: >Issue 2: The exact nature and description of agentxSessionIndex >needs to be clarified. Is it the same as h.SessionID in the >AgentX header? When may sessionID values be re-used on a given >connection? What is a connection defined as when connectionless >transports are used? Should it be type constrained to not include 0? >If session IDs are globally unique across any connection, then should >the agentxSessionTable be indexed only by agentxSessionIndex (drop >the agentxConnIndex index)? > > Status: consensus forming that agentxSessionIndex should > be same as h.SessionID and should uniquely identify a > session on a given connection. This issue needs to be > in-sync with RFC 2257 text concerning h.SessionID. > > Proposed description: "agentxSesssionIndex is the same as > h.sessionID defined in the agentx header. It is a non-zero > index value that uniquely identifies the subagent session > within a given connection. Session index values may be > discontiguous and may be reused as long as the constraint > of uniqueness within a single connection is preserved." Wonderful. The dichotomy with the nightmarish ifIndex should be obvious. The "connection" when using connectionless transports (UDP on layer 4, Transport layer, of the OSI reference model) is the transaction; a query/response exchange. The connectionless nature of in-band management protocols such as SNMP is necessary, despite the difficulties it causes when "mapping" connections. I prefer, as a general, but technically problematic and ultimately meaningless, preference, that .0 not be used for table attribute instance OID components. It helps a LOT when explaining how the "it's a table but a tree" MIB constructs work. I have dozens of training courses which get a little more complicated whenever 0 is used as an index value. :-) I'm not sure if this suggestion about indexing references the statements posted about the value of requiring the three AgentX "connection" index values to model the typical implementation. Perhaps a construct could be created whereby a "0" value identifies "we're not following the standard model, and agentxSessionTable is indexed only by agentxSessionIndex (without the agentxConnIndex index reference being meaningful)?" I know it might seem extreme but it would definitely be valuable if the mechanics of AgentX ever /do/ have to be understandable to end-users. I don't *think* it would compromise the technical validity or performance to use this kind of "defined metavalue", and it would allow compatibility between systems which are based on the standard connection/session/transaction model and those that don't. -- T. Max Devlin Eltrax Systems, Inc. mdevlin@eltrax.com -[Opinions expressed are my own; everyone else, including my employer, has to pay for them, subject to applicable licensing agreement]- From mdevlin@eltrax.com Tue Aug 25 02:26:47 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id CAA03408 for ; Tue, 25 Aug 1998 02:26:46 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id CAA14071 for ; Tue, 25 Aug 1998 02:24:44 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma010096; Tue, 25 Aug 98 02:13:22 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id CAA25321 for ; Tue, 25 Aug 1998 02:12:43 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xmaa20654; Tue, 25 Aug 98 02:07: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 CAA06450; Tue, 25 Aug 1998 02:07:51 -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 WAA17009 for ; Mon, 24 Aug 1998 22:49:37 -0700 (PDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id AAA19895 for ; Tue, 25 Aug 1998 00:49:33 -0500 (CDT) Received: from mail.htconn.com(38.245.21.2) by almond.bmc.com via smap (V2.0) id xma017375; Tue, 25 Aug 98 00:39:24 -0500 Received: from AS5200-1-A43.hmc.psghs.edu by mail.htconn.com (SMI-8.6/SMI-SVR4) id BAA01815; Tue, 25 Aug 1998 01:32:33 -0400 From: mdevlin@eltrax.com (T. Max Devlin) To: agentx@peer.com Subject: Re: AgentX MIB issue 3 Date: Tue, 25 Aug 1998 05:26:40 GMT Organization: Eltrax Systems/Hi-TECH Connections Message-ID: <361a15f7.35884929@mail.htconn.com> References: <35DDBA93.36FBD385@bmc.com> In-Reply-To: <35DDBA93.36FBD385@bmc.com> X-Mailer: Forte Agent 1.5/32.451 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lauren Heintz said: >Issue 3: Is agentxRegisterDuplicate really useful? If we're going >to keep it, wouldn't it be better to make this counter part of the >appropriate table entry? > > Status: consensus forming not to add error counters > (whether as scalar or tabular objects). See issue eight > for more details. Consensus not yet reached to remove this > object, to keep it as it is, or to add it to an existing table > entry. Limited, even rudimentary counters for "interoperability problem detection" would be a last defense against having to examine source code to determine connectivity problems. Being able to identify large values for duplicate registrations will be valuable, if anyone here has a real commitment to interoperability. Other rudimentary instrumentation should also be defined, but implementations, rather than the standard, should define them. This only serves to underscore the need for the most simple possible instrumentation. By requiring this, the "must" in defining the functionality of instrumenting AgentX processing is technically justified. Implementations of the table entry, and whether there is any technical *capability* for efficient processing of duplicate registrations, depend on the indexing questions separately addressed. -- T. Max Devlin Eltrax Systems, Inc. mdevlin@eltrax.com -[Opinions expressed are my own; everyone else, including my employer, has to pay for them, subject to applicable licensing agreement]- From mdevlin@eltrax.com Tue Aug 25 02:34:06 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id CAA03469 for ; Tue, 25 Aug 1998 02:34:06 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id CAA16051 for ; Tue, 25 Aug 1998 02:32:03 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma011914; Tue, 25 Aug 98 02:17:57 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id CAA29719 for ; Tue, 25 Aug 1998 02:17:00 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma020665; Tue, 25 Aug 98 02:07: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 CAA06442; Tue, 25 Aug 1998 02:07: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 WAA17015 for ; Mon, 24 Aug 1998 22:49:55 -0700 (PDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id AAA19986 for ; Tue, 25 Aug 1998 00:49:53 -0500 (CDT) Received: from mail.htconn.com(38.245.21.2) by almond.bmc.com via smap (V2.0) id xma017546; Tue, 25 Aug 98 00:39:58 -0500 Received: from AS5200-1-A43.hmc.psghs.edu by mail.htconn.com (SMI-8.6/SMI-SVR4) id BAA01821; Tue, 25 Aug 1998 01:33:15 -0400 From: mdevlin@eltrax.com (T. Max Devlin) To: agentx@peer.com Subject: Re: AgentX MIB issue 6 Date: Tue, 25 Aug 1998 05:27:23 GMT Organization: Eltrax Systems/Hi-TECH Connections Message-ID: <361d1658.35981437@mail.htconn.com> References: <9808212226.AA03193@acecomm.com> In-Reply-To: <9808212226.AA03193@acecomm.com> X-Mailer: Forte Agent 1.5/32.451 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bob Natale said: >>At 8/21/98 02:27 PM, Randy Presuhn wrote: > >Hi Randy, > >>> Issue 6: The RegistrationTable lacks an agentxRegSession object. >>> >>> Status: consensus forming to maintain multiple indices >>> in the tables and not to instead add new columns >>> in each table for determining cross-table associations. >>... >> >>It sounds like this would require both the connection and the >>session identifiers to be included in the indexes for the >>registration table if some of the other proposed mods are >>accepted. > >Yes, that is true. And the primary mod to RFC 2257 involved is >simply that the h.SessionID values must be unique only within >the context (normal sense of the word) of a connection, not >"globablly" unique as the text now says. > >I personally find that change quite acceptable (removing my >objection to the multiple indices in the MIB table), but I >think Mike hinted at something about digging up a rationale >for the "globally" unique requirement...? For a "gestalt" opinion, if you don't mind, using h.SessionID as a local-context identifier might be extremely beneficial from the protocol side, it proves problematic from the modeling side. I realize we have only so many cycles to do a job, but instrumentation MUST be built in from the ground up if it is ever going to be reliable. The value of the use of multiple indexes for the table would be compromised by allowing h.SessionID, by reference the session identifier in the natural hierarchy, to be non-unique in a "global" sense. I will shut up now until somebody (Mike?) presents specific benefits to global uniqueness for session identifiers. Thanks for your time. Hope it helps. -- T. Max Devlin Eltrax Systems, Inc. mdevlin@eltrax.com -[Opinions expressed are my own; everyone else, including my employer, has to pay for them, subject to applicable licensing agreement]- From mdevlin@eltrax.com Tue Aug 25 02:40:33 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id CAA03527 for ; Tue, 25 Aug 1998 02:40:33 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id CAA17757 for ; Tue, 25 Aug 1998 02:38:31 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma010005; Tue, 25 Aug 98 02:13:07 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id CAA25067 for ; Tue, 25 Aug 1998 02:12:26 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma020505; Tue, 25 Aug 98 02:07:18 -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 CAA06449; Tue, 25 Aug 1998 02:07:51 -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 WAA17001 for ; Mon, 24 Aug 1998 22:49:27 -0700 (PDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id AAA19859 for ; Tue, 25 Aug 1998 00:49:25 -0500 (CDT) Received: from mail.htconn.com(38.245.21.2) by almond.bmc.com via smap (V2.0) id xma017251; Tue, 25 Aug 98 00:38:55 -0500 Received: from AS5200-1-A43.hmc.psghs.edu by mail.htconn.com (SMI-8.6/SMI-SVR4) id BAA01811; Tue, 25 Aug 1998 01:32:12 -0400 From: mdevlin@eltrax.com (T. Max Devlin) To: agentx@peer.com Subject: Re: AgentX MIB issue 1. Date: Tue, 25 Aug 1998 05:26:19 GMT Organization: Eltrax Systems/Hi-TECH Connections Message-ID: <361815e8.35869611@mail.htconn.com> References: <35DDBA16.973CF826@bmc.com> In-Reply-To: <35DDBA16.973CF826@bmc.com> X-Mailer: Forte Agent 1.5/32.451 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lauren Heintz said: >Issue 1: Should AgentxTCPAddress and AgentxTCPDomain TCs be >defined outside of the AgentX MIB? Where? Also, similar >TCs need to be defined for Unix Domain Sockets, and for IPv6. > > Status: consensus forming that these TCs should > be administered by IANA. See Mike Daniele's proposed > draft on this subject (draft-daniele-iana-addr-mib-00.txt). If formal "administration" by IANA is required to recognize these ports as conventional under whatever indistinct descendant of the Berkeley Conventions still hold Unix and the Internet together, then OK. Seems to be wasted technical time, though, one way or the other. Who decides what port to use?, if that is the actual question, is a minor political point. Let's re-use 42, just to screw with them. :-) -- T. Max Devlin Eltrax Systems, Inc. mdevlin@eltrax.com -[Opinions expressed are my own; everyone else, including my employer, has to pay for them, subject to applicable licensing agreement]- From schoenw@ibr.cs.tu-bs.de Tue Aug 25 05:52:00 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id FAA05077 for ; Tue, 25 Aug 1998 05:51:59 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id FAA04976 for ; Tue, 25 Aug 1998 05:49:59 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma004003; Tue, 25 Aug 98 05:47:13 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id FAA21900 for ; Tue, 25 Aug 1998 05:46:31 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma018942; Tue, 25 Aug 98 05:44: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 FAA13054; Tue, 25 Aug 1998 05:44: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 DAA17457 for ; Tue, 25 Aug 1998 03:25:32 -0700 (PDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id FAA01011 for ; Tue, 25 Aug 1998 05:25:31 -0500 (CDT) Received: from mumm.ibr.cs.tu-bs.de(134.169.34.190) by almond.bmc.com via smap (V2.0) id xma000994; Tue, 25 Aug 98 05:25:21 -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 MAA24123; Tue, 25 Aug 1998 12:25:07 +0200 (MET DST) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id MAA25566; Tue, 25 Aug 1998 12:24:44 +0200 Date: Tue, 25 Aug 1998 12:24:44 +0200 Message-Id: <199808251024.MAA25566@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: mdevlin@eltrax.com CC: agentx@peer.com In-reply-to: <361815e8.35869611@mail.htconn.com> (mdevlin@eltrax.com) Subject: Re: AgentX MIB issue 1. References: <35DDBA16.973CF826@bmc.com> <361815e8.35869611@mail.htconn.com> Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII >>>>> T Max Devlin writes: T> Lauren Heintz said: >> Issue 1: Should AgentxTCPAddress and AgentxTCPDomain TCs be defined >> outside of the AgentX MIB? Where? Also, similar TCs need to be >> defined for Unix Domain Sockets, and for IPv6. >> >> Status: consensus forming that these TCs should be administered by >> IANA. See Mike Daniele's proposed draft on this subject >> (draft-daniele-iana-addr-mib-00.txt). T> If formal "administration" by IANA is required to recognize these T> ports as conventional under whatever indistinct descendant of the T> Berkeley Conventions still hold Unix and the Internet together, T> then OK. Seems to be wasted technical time, though, one way or the T> other. Who decides what port to use?, if that is the actual T> question, is a minor political point. Let's re-use 42, just to T> screw with them. :-) Did you read Mike's draft? Do you really understand the issue? I have serious problems to understand your comment. It seems you are talking about something completely unrelated to Mike's draft. Juergen From schoenw@ibr.cs.tu-bs.de Tue Aug 25 05:56:09 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id FAA05113 for ; Tue, 25 Aug 1998 05:56:08 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id FAA06280 for ; Tue, 25 Aug 1998 05:54:08 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma003998; Tue, 25 Aug 98 05:47:12 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id FAA21895 for ; Tue, 25 Aug 1998 05:46:31 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma018944; Tue, 25 Aug 98 05:44: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 FAA13059; Tue, 25 Aug 1998 05:44:51 -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 DAA17465 for ; Tue, 25 Aug 1998 03:27:53 -0700 (PDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id FAA01167 for ; Tue, 25 Aug 1998 05:27:42 -0500 (CDT) Received: from mumm.ibr.cs.tu-bs.de(134.169.34.190) by almond.bmc.com via smap (V2.0) id xma001149; Tue, 25 Aug 98 05:27:15 -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 MAA24195; Tue, 25 Aug 1998 12:27:10 +0200 (MET DST) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id MAA25601; Tue, 25 Aug 1998 12:27:10 +0200 Date: Tue, 25 Aug 1998 12:27:10 +0200 Message-Id: <199808251027.MAA25601@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: mdevlin@eltrax.com CC: agentx@peer.com In-reply-to: <361915f3.35880924@mail.htconn.com> (mdevlin@eltrax.com) Subject: Re: AgentX MIB issue 2 References: <35DDBA4E.7E957DCD@bmc.com> <361915f3.35880924@mail.htconn.com> Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII >>>>> T Max Devlin writes: T> Perhaps a construct could be created whereby a "0" value identifies T> "we're not following the standard model, and agentxSessionTable is T> indexed only by agentxSessionIndex (without the agentxConnIndex T> index reference being meaningful)?" I know it might seem extreme T> but it would definitely be valuable if the mechanics of AgentX ever T> /do/ have to be understandable to end-users. I don't *think* it T> would compromise the technical validity or performance to use this T> kind of "defined metavalue", and it would allow compatibility T> between systems which are based on the standard T> connection/session/transaction model and those that don't. I will never accept such a hack. And I do not see a single technical reason why this would be necessary. (I must admit that I do not understand your comments related to this issue in some of your other mails.) Juergen From sar@epilogue.com Wed Aug 26 13:32:26 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id NAA20738 for ; Wed, 26 Aug 1998 13:32:25 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id NAA04029 for ; Wed, 26 Aug 1998 13:30:22 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xmayp1952; Wed, 26 Aug 98 13:28:05 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id KAA07692 for ; Wed, 26 Aug 1998 10:08:52 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma006905; Wed, 26 Aug 98 10:08: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 KAA01639; Wed, 26 Aug 1998 10:08:44 -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 GAA24674 for ; Wed, 26 Aug 1998 06:47:15 -0700 (PDT) Received: (from uucp@localhost) by cashew.bmc.com (8.8.8/8.8.8) id IAA12166 for ; Wed, 26 Aug 1998 08:47:13 -0500 (CDT) Received: from khitomer.epilogue.com(128.224.1.172) by cashew.bmc.com via smap (V2.0) id xma012148; Wed, 26 Aug 98 08:47:04 -0500 From: "Shawn A. Routhier" Sender: sar@khitomer.epilogue.com To: agentx@peer.com Subject: Connection table Date: Wed, 26 Aug 98 09:47:03 -0400 Message-ID: <9808260947.aa03772@khitomer.epilogue.com> In looking through some older mail about the agentx mib I came across some discussion about simply getting rid of the connection table and possibly moving some of its informtion into the session table. There didn't seem to be much of a consensuss in either direction (but I may have lost some of the messages). Do people think this could be a good or bad idea? sar From sgudur@hotmail.com Wed Aug 26 20:57:50 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id UAA24416 for ; Wed, 26 Aug 1998 20:57:50 -0500 (CDT) Received: (from uucp@localhost) by almond.bmc.com (8.8.8/8.8.8) id UAA12142 for ; Wed, 26 Aug 1998 20:55:44 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma011446; Wed, 26 Aug 98 20:53:43 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id UAA25453 for ; Wed, 26 Aug 1998 20:53:02 -0500 (CDT) Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) id xma024403; Wed, 26 Aug 98 20:52:31 -0500 Received: from dorothy.bmc.com (dorothy.bmc.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id UAA18328; Wed, 26 Aug 1998 20:53: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 SAA14751 for ; Wed, 26 Aug 1998 18:27:26 -0700 (PDT) Received: (from uucp@localhost) by cashew.bmc.com (8.8.8/8.8.8) id UAA24168 for ; Wed, 26 Aug 1998 20:27:24 -0500 (CDT) Received: from f223.hotmail.com(207.82.251.114) by cashew.bmc.com via smap (V2.0) id xma024159; Wed, 26 Aug 98 20:26:58 -0500 Received: (qmail 13009 invoked by uid 0); 27 Aug 1998 01:26:56 -0000 Message-ID: <19980827012656.13008.qmail@hotmail.com> Received: from 152.67.249.57 by www.hotmail.com with HTTP; Wed, 26 Aug 1998 18:26:56 PDT X-Originating-IP: [152.67.249.57] From: "Smitha Gudur" To: mdevlin@eltrax.com Cc: agentx@peer.com Subject: Re: AgentX MIB issue 1. Content-Type: text/plain Date: Wed, 26 Aug 1998 18:26:56 PDT Hi, Max, >From mdevlin@eltrax.com Tue Aug 25 00:44:08 1998 >Received: (from uucp@localhost) > by almond.bmc.com (8.8.8/8.8.8) id CAA19212 > for ; Tue, 25 Aug 1998 02:44:05 -0500 (CDT) >Received: from firewall.bmc.com(192.245.162.250) > by almond.bmc.com via smap (V2.0) > id xma012375; Tue, 25 Aug 98 02:19:04 -0500 >Received: (from uucp@localhost) > by dresden.bmc.com (8.8.5/8.8.6) id CAA01508 > for ; Tue, 25 Aug 1998 02:18:15 -0500 (CDT) >Received: from tangelo.bmc.com(172.17.7.166) by dresden.bmc.com via smap (3.2) > id xma023265; Tue, 25 Aug 98 02:10: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 CAA06353; > Tue, 25 Aug 1998 02:07:33 -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 WAA17001 > for ; Mon, 24 Aug 1998 22:49:27 -0700 (PDT) >Received: (from uucp@localhost) > by almond.bmc.com (8.8.8/8.8.8) id AAA19859 > for ; Tue, 25 Aug 1998 00:49:25 -0500 (CDT) >Received: from mail.htconn.com(38.245.21.2) > by almond.bmc.com via smap (V2.0) > id xma017251; Tue, 25 Aug 98 00:38:55 -0500 >Received: from AS5200-1-A43.hmc.psghs.edu by mail.htconn.com (SMI-8.6/SMI-SVR4) > id BAA01811; Tue, 25 Aug 1998 01:32:12 -0400 >From: mdevlin@eltrax.com (T. Max Devlin) >To: agentx@peer.com >Subject: Re: AgentX MIB issue 1. >Date: Tue, 25 Aug 1998 05:26:19 GMT >Organization: Eltrax Systems/Hi-TECH Connections >Message-ID: <361815e8.35869611@mail.htconn.com> >References: <35DDBA16.973CF826@bmc.com> >In-Reply-To: <35DDBA16.973CF826@bmc.com> >X-Mailer: Forte Agent 1.5/32.451 >MIME-Version: 1.0 >Content-Type: text/plain; charset=us-ascii >Content-Transfer-Encoding: 7bit > >Lauren Heintz said: >>Issue 1: Should AgentxTCPAddress and AgentxTCPDomain TCs be >>defined outside of the AgentX MIB? Where? Also, similar >>TCs need to be defined for Unix Domain Sockets, and for IPv6. >> >> Status: consensus forming that these TCs should >> be administered by IANA. See Mike Daniele's proposed >> draft on this subject (draft-daniele-iana-addr-mib-00.txt). > >If formal "administration" by IANA is required to recognize these ports as >conventional under whatever indistinct descendant of the Berkeley Conventions >still hold Unix and the Internet together, then OK. Seems to be wasted >technical time, though, one way or the other. Who decides what port to use?, >if that is the actual question, is a minor political point. Let's re-use 42, >just to screw with them. :-) This is related with avoiding duplicate definitions for TC's. Having all these defined in one mib enables it to acheive this goal. smitha > >-- >T. Max Devlin >Eltrax Systems, Inc. >mdevlin@eltrax.com >-[Opinions expressed are my own; everyone else, including > my employer, has to pay for them, subject to > applicable licensing agreement]- > ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com From rpresuhn@dorothy.bmc.com Fri Aug 28 10:27:09 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id KAA12760 for ; Fri, 28 Aug 1998 10:27:08 -0500 (CDT) Received: from tangelo.bmc.com (root@tangelo.bmc.com [172.17.7.166]) by almond.bmc.com (8.9.1/8.9.1) with ESMTP id KAA29737; Fri, 28 Aug 1998 10:24:28 -0500 (CDT) Received: from dorothy.bmc.com (dorothy.bmc.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id KAA26162; Fri, 28 Aug 1998 10:24:02 -0500 (CDT) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id GAA16075; Fri, 28 Aug 1998 06:58:36 -0700 (PDT) Date: Fri, 28 Aug 1998 06:58:36 -0700 (PDT) From: Randy Presuhn Message-Id: <199808281358.GAA16075@dorothy.bmc.com> To: agentx@peer.com Subject: agentx / disman considerations Cc: disman@nexen.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi - (I've posted this to both the disman and agentx lists; let's limit the followup discussion to just the agentx list.) At the IETF meeting in Chicago, there was continued discussion of just what the so-called "disman requirements" of agentx protocol might be. After some discussion, we were able to reduce it down to three questions. Bob Natale requested that I post the questions; I've included my own strawman answers. The question of when (if ever) to address these is open to discussion, since it's pretty clear that these capabilities are only needed by certain specialized kinds of subagents. For purposes for supporting MIBs like the Script MIB, Schedule MIB, Expressions MIB, and so on: 1) Is inter-subagent communication via AgentX protocol required? Strawman: No. Since these are architecturally command generator applications, they already need to be able to issue SNMP operations. For an implementation to provide local optimizations of how such operations are actually performed is by definition a local implementation decision, not something we need to standardize. 2) Is access to the "isAccessAllowed" abstract service interface needed? Strawman: Yes. 2a) Is it desirable / necessary that this be accomplished via Agentx protocol? Strawman: not necessary, probably desirable. Needs discussion. 3) Is identification of the operation invoker and level of security required? Strawman: Yes. Other solutions (carrying this information out-of-band) appear to be overly complicated due to synchronization and corrdination issues. ----------------------------------------------------------------------- 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 31 15:07:04 1998 Return-Path: Received: from almond.bmc.com (mail-gw1.bmc.com [198.64.253.22]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id PAA18460 for ; Mon, 31 Aug 1998 15:07:04 -0500 (CDT) Received: from tangelo.bmc.com (root@tangelo.bmc.com [172.17.7.166]) by almond.bmc.com (8.9.1/8.9.1) with ESMTP id PAA15890; Mon, 31 Aug 1998 15:03:55 -0500 (CDT) 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 PAA13199; Mon, 31 Aug 1998 15:03:52 -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 KAA20302 for ; Mon, 31 Aug 1998 10:06:46 -0700 (PDT) Received: from tangelo.bmc.com (root@tangelo.bmc.com [172.17.7.166]) by almond.bmc.com (8.9.1/8.9.1) with ESMTP id MAA07021; Mon, 31 Aug 1998 12:06:43 -0500 (CDT) Received: from bmc.com ([192.146.153.145] (may be forged)) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id MAA04357; Mon, 31 Aug 1998 12:06:37 -0500 (CDT) Message-ID: <35EAD752.5DC63E8D@bmc.com> Date: Mon, 31 Aug 1998 10:03:14 -0700 From: Lauren Heintz X-Mailer: Mozilla 4.04 [en] (WinNT; U) MIME-Version: 1.0 To: sar@epilogue.com CC: agentx@peer.com Subject: Re: Connection table References: <9808260947.aa03772@khitomer.epilogue.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Seems we have several choices concerning the AgentX connection table: 1. Convert the connection table to be subagent protocol independant. The TDomain value will thus indicate which protocol is in effect for a given entry. One entry might be SMUX, another might be AgentX, etc.. RATIONALE: if I were to implement such a connection table for each different subagent protocol, they would appear very similar in design. Why not simply make it generic enough to be used for any subagent protocol? 2. Remove the connection table, since it seems not to really specify agentX protocol needs. RATIONALE: connection management, if not standardized for ALL subagent protocols, is probably better left to be an implementation-specific feature. 3. Leave it as is. RATIONALE: Ship the darn thing! 4. Other? Personally, my preferences would be 3,1,2, in that order. Lauren sar@epilogue.com wrote: > > In looking through some older mail about the agentx mib > I came across some discussion about simply getting rid > of the connection table and possibly moving some of its > informtion into the session table. There didn't seem > to be much of a consensuss in either direction (but I > may have lost some of the messages). > > Do people think this could be a good or bad idea? > > sar -- -------------------------------------------------------------------------- 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 --------------------------------------------------------------------------