From rpresuhn@dorothy.bmc.com Tue Sep 1 13:20: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 NAA06970 for ; Tue, 1 Sep 1998 13:20:46 -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 NAA19428; Tue, 1 Sep 1998 13:17:37 -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 NAA05999; Tue, 1 Sep 1998 13:17:28 -0500 (CDT) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id KAA07962 for agentx; Tue, 1 Sep 1998 10:21:02 -0700 (PDT) Date: Tue, 1 Sep 1998 10:21:02 -0700 (PDT) From: Randy Presuhn Message-Id: <199809011721.KAA07962@dorothy.bmc.com> To: agentx@dorothy.bmc.com Subject: agentx list test - please ignore Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi - test - please ignore ----------------------------------------------------------------------- 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@dt-nis.bmc.com Tue Sep 1 13:21: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 NAA06976 for ; Tue, 1 Sep 1998 13:21:06 -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 NAA19417; Tue, 1 Sep 1998 13:17:34 -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 NAA05966; Tue, 1 Sep 1998 13:17:26 -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 LAA09547 for ; Tue, 1 Sep 1998 11:07:02 -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 NAA17767 for ; Tue, 1 Sep 1998 13:07:00 -0500 (CDT) Received: from dt-nis.bmc.com (dt-nis.bmc.com [10.10.1.90]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id NAA02411 for ; Tue, 1 Sep 1998 13:06:59 -0500 (CDT) Received: from cyclone.bmc.com (cyclone.bmc.com [192.146.153.86]) by dt-nis.bmc.com (8.8.8/8.8.8) with SMTP id LAA01836 for ; Tue, 1 Sep 1998 11:06:58 -0700 (PDT) Received: by cyclone.bmc.com (SMI-8.6/SMI-SVR4) id LAA08564; Tue, 1 Sep 1998 11:06:26 -0700 Date: Tue, 1 Sep 1998 11:06:26 -0700 From: rpresuhn@dt-nis.bmc.com (Randy Presuhn) Message-Id: <199809011806.LAA08564@cyclone.bmc.com> To: agentx@peer.com Subject: test#3 of agentx list hi - test, please ignore Randy From rpresuhn@dorothy.bmc.com Tue Sep 1 13:21:58 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 NAA06996 for ; Tue, 1 Sep 1998 13:21:58 -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 NAA19420; Tue, 1 Sep 1998 13:17:36 -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 NAA05969; Tue, 1 Sep 1998 13:17:26 -0500 (CDT) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id KAA08875 for agentx@peer.com; Tue, 1 Sep 1998 10:47:16 -0700 (PDT) Date: Tue, 1 Sep 1998 10:47:16 -0700 (PDT) From: Randy Presuhn Message-Id: <199809011747.KAA08875@dorothy.bmc.com> To: agentx@peer.com Subject: test#2 of agentx Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi - test#2 - please ignore ----------------------------------------------------------------------- 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 Tue Sep 1 16:39: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 QAA09751 for ; Tue, 1 Sep 1998 16:39:10 -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 QAA14521; Tue, 1 Sep 1998 16:35:23 -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 QAA12463; Tue, 1 Sep 1998 16:35:15 -0500 (CDT) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id OAA16614 for agentx@peer.com; Tue, 1 Sep 1998 14:06:00 -0700 (PDT) Date: Tue, 1 Sep 1998 14:06:00 -0700 (PDT) From: Randy Presuhn Message-Id: <199809012106.OAA16614@dorothy.bmc.com> To: agentx@peer.com Subject: agentx test #4 please ignore Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi - sorry about the noise! ----------------------------------------------------------------------- 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 Sep 3 15:07: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 PAA14944 for ; Thu, 3 Sep 1998 15:07:06 -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 PAA24995 for ; Thu, 3 Sep 1998 15:04:47 -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 PAA21451 for ; Thu, 3 Sep 1998 15:04:41 -0500 (CDT) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id LAA07704 for agentx@peer.com; Thu, 3 Sep 1998 11:38:21 -0700 (PDT) Date: Thu, 3 Sep 1998 11:38:21 -0700 (PDT) From: Randy Presuhn Message-Id: <199809031838.LAA07704@dorothy.bmc.com> To: agentx@peer.com Subject: AgentX list is back Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi - Apologies for the outage of the distribution list. Things should be back to normal again. Please let me know if you don't get this message. :-) ----------------------------------------------------------------------- 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 Sep 4 00:40: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 AAA01902 for ; Fri, 4 Sep 1998 00:40:49 -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 AAA06707; Fri, 4 Sep 1998 00:38:21 -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 AAA00566; Fri, 4 Sep 1998 00:38:16 -0500 (CDT) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id WAA19181 for agentx@peer.com; Thu, 3 Sep 1998 22:14:38 -0700 (PDT) Date: Thu, 3 Sep 1998 22:14:38 -0700 (PDT) From: Randy Presuhn Message-Id: <199809040514.WAA19181@dorothy.bmc.com> To: agentx@peer.com Subject: Re: AgentX MIB issue 4 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi - |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 |References: <35DDBADB.5745F638@bmc.com> | |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. ... I believe the question is whether the MIB table can adequately and economically reflect what has happened in the protocol, not whether the protocol can efficiently handle a specific registration scenario. ----------------------------------------------------------------------- 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 Sep 4 00:40: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 AAA01908 for ; Fri, 4 Sep 1998 00:40:54 -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 AAA06708; Fri, 4 Sep 1998 00:38:22 -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 AAA00571; Fri, 4 Sep 1998 00:38:18 -0500 (CDT) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id WAA19648 for agentx@peer.com; Thu, 3 Sep 1998 22:29:50 -0700 (PDT) Date: Thu, 3 Sep 1998 22:29:50 -0700 (PDT) From: Randy Presuhn Message-Id: <199809040529.WAA19648@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 - |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 |References: <9808212226.AA03193@acecomm.com> ... |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. I fail to see what the modeling problem would be. The idea that h.SessionID be unique across all connections is rather like saying that an X.25 LCN would have to be unique across all links, or that house numbers must be unique across all streets. |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 don't see how local (rather than global) uniqueness of h.SessionID makes the index tuple any less suitable, since it's the other element of the tuple that limits the scope of uniqueness anyway. ----------------------------------------------------------------------- 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 Sep 4 00:43: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 AAA02007 for ; Fri, 4 Sep 1998 00:43:45 -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 AAA07061; Fri, 4 Sep 1998 00:41:17 -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 AAA01371; Fri, 4 Sep 1998 00:41:14 -0500 (CDT) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id WAA19930 for agentx@peer.com; Thu, 3 Sep 1998 22:38:49 -0700 (PDT) Date: Thu, 3 Sep 1998 22:38:49 -0700 (PDT) From: Randy Presuhn Message-Id: <199809040538.WAA19930@dorothy.bmc.com> To: agentx@peer.com Subject: Re: AgentX MIB issue 7 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi - > 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 ... > 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. ... The agentx bakeoffs demonstrated pretty conclusively that one does not need a MIB with error counters to achieve multi-vendor interoperability. This has also been demonstrated with other subagent protocols. When we add things to this MIB, they should be demonstrably useful and in response to a real need. I'd like to hear an implementor of agents, subagents, or management applications give a requirement before we go adding more instrumentation. ----------------------------------------------------------------------- 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 Sep 4 01:09: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 BAA02763 for ; Fri, 4 Sep 1998 01:09:14 -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 BAA08248; Fri, 4 Sep 1998 01:06:44 -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 BAA05808; Fri, 4 Sep 1998 01:06:39 -0500 (CDT) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id XAA20621 for agentx@peer.com; Thu, 3 Sep 1998 23:01:10 -0700 (PDT) Date: Thu, 3 Sep 1998 23:01:10 -0700 (PDT) From: Randy Presuhn Message-Id: <199809040601.XAA20621@dorothy.bmc.com> To: agentx@peer.com Subject: Re: SubAgent API Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi - > Date: Thu, 27 Aug 1998 01:59:51 -0400 > To: "Ramakumara.K" > From: Bob Natale > Subject: Re: SubAgent API > Cc: agentx@peer.com ... > My personal feeling is that we *should* do the API--even though > personally I am somewhat inclined these days to avoid taking on > additional standards-body work. But that will remain an open > WG decsion item until we actually develop and deliver such an API. ... One important consideration (not necessarily a requirement) in the API design is whether to base it on a "service definition" or on the protocol specification. The distinction is important. The former is potentially useful for other protocols, and is closer to the level of abstraction a MIB implementor would be comfortable with. The latter ends up being inextricably tied to AgentX protocol (possibly even a specific version), and tends to be at a gory bits and bytes level. One COULD define an API that's little more than some structs and typedefs that map directly onto the RFC 2257 PDU layouts. Such an approach would provide little value. I think a higher level of abstraction is appropriate. The part that gets tricky in this is whether the dispatch of operations and execution of access methods is handled within this API. Unfortunately, it's in this area where the API could provide the most value that vendors' (and freely available) interfaces (MIB compiler output, support libraries, and so on) differ in wildly incompatible ways, even though the capability provided may be remarkably similar. ----------------------------------------------------------------------- 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 Sep 4 10:21: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 KAA18993 for ; Fri, 4 Sep 1998 10:21:54 -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 KAA16849; Fri, 4 Sep 1998 10:18:45 -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 KAA02406; Fri, 4 Sep 1998 10:18:37 -0500 (CDT) Received: from cashew.bmc.com (cashew.bmc.com [172.19.0.100]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id HAA05650 for ; Fri, 4 Sep 1998 07:53:19 -0700 (PDT) Received: from relay4.smtp.psi.net (relay4.smtp.psi.net [38.9.52.2]) by cashew.bmc.com (8.9.1/8.9.1) with ESMTP id JAA17375 for ; Fri, 4 Sep 1998 09:53:13 -0500 (CDT) Received: from [192.152.208.5] (helo=acecomm.com) by relay4.smtp.psi.net with smtp (Exim 1.90 #1) id 0zExEO-0003mh-00; Fri, 4 Sep 1998 10:52:57 -0400 Received: from bnatale by acecomm.com (5.65/3.2.083191-ACE*COMM) id AA19940; Fri, 4 Sep 1998 10:55:39 -0400 Message-Id: <9809041455.AA19940@acecomm.com> X-Sender: natale@nips.acec.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1 Date: Fri, 04 Sep 1998 10:55:49 -0400 To: Randy Presuhn From: Bob Natale Subject: Re: AgentX MIB issue 7 Cc: agentx@peer.com In-Reply-To: <199809040538.WAA19930@dorothy.bmc.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" >At 9/3/98 10:38 PM, Randy Presuhn wrote: Hi Randy, <...> >The agentx bakeoffs demonstrated pretty conclusively that one does not >need a MIB with error counters to achieve multi-vendor interoperability. True...then again I'd say that the bakeoffs demonstrated conclusively that one does need a MIB at all to achieve multi-vendor interoperability at the protocol level! (I will use that assertion to argue against your point below, however!) >This has also been demonstrated with other subagent protocols. It could probably be demonstrated with most protocols, whether they pertained to subagents or not. That is, implementations may achieve interoperability at the protocol level by acquiring and keeping whatever necessary state/housekeeping info using whatever implementation-specific methods/structures they want to. I don't think that proves much in terms of what *should* be in the AgentX MIB. In other words, I think the purposes originally outlined for the AgentX MIB served other potential "consumers" than (just) protocol implementors. I am not sure where the concept that it should only serve the purposes of AgentX interoperability arose (but I'm pretty sure you'll give me a hard-to-refute reference for it!). >When we add things to this MIB, they should be demonstrably >useful and in response to a real need. That is indisputable. However, the primary "real need" I see the AgentX MIB serving is to provide the local (i.e., master agent node) system administrator(s)--and the apps they use--to monitor, assess, and control their AgentX environment. Knowing what connections, sessions, registrations, and error states exist represent the *kinds* of information those sysAdmins will need for this purpose. >I'd like to hear an implementor of agents, subagents, or >management applications give a requirement before we go >adding more instrumentation. Speaking primarily from the perspective of "an implementor of management applications", please see above. Granted one could easily devise an enterprise tree MIB to achieve the goal I am talking about...however, that seems like a cop-out here, esp. in this era when we are collectively trying to make progress on standardized approaches to configuring the SNMP environment itself. So, my position is that we need the traffic/error info in the MIB because sysAdmins will need it. I don't have a closed mind about it, however...I just don't have your rationale for the "needed for implementation interoperability" test clear in my mind. As a related aside, I would not object to coalescing the connection [as suggested by Shawn] and "status" info into the agentxSessionTable, since that info can be (readily) modeled as fixed (wrt number of instances) and directly dependent upon the h.SessionID anyway. 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 battle@snmp.com Fri Sep 4 12:07: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 MAA22134 for ; Fri, 4 Sep 1998 12:07:16 -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 MAA06355; Fri, 4 Sep 1998 12:03:45 -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 MAA07033; Fri, 4 Sep 1998 12:03:41 -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 JAA09440 for ; Fri, 4 Sep 1998 09:53:22 -0700 (PDT) Received: from seymour16.snmp.com (seymour16.snmp.com [192.147.142.16]) by almond.bmc.com (8.9.1/8.9.1) with ESMTP id LAA04308 for ; Fri, 4 Sep 1998 11:53:20 -0500 (CDT) Received: by seymour16.snmp.com (cf v2.9s-SNMP) id MAA22614; Fri, 4 Sep 1998 12:52:49 -0400 (EDT) Date: Fri, 4 Sep 1998 12:52:49 -0400 (EDT) From: David Battle Message-Id: <199809041652.MAA22614@seymour16.snmp.com> To: rpresuhn@dorothy.bmc.com Subject: Re: AgentX MIB issue 7 Cc: agentx@peer.com > When we add things to this MIB, they should be demonstrably useful and Frankly it's not clear to me that we need a mib at all. EMANATE has been very successful to-date without a mib at all, and like you said it isn't needed for multi-vendor interoperability. Thanks, -David From Lauren_Heintz@crow.bmc.com Fri Sep 4 14:24: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 OAA26196 for ; Fri, 4 Sep 1998 14:24:20 -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 OAA23097; Fri, 4 Sep 1998 14:19:29 -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 OAA11997; Fri, 4 Sep 1998 14:19: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 LAA12651 for ; Fri, 4 Sep 1998 11:48:54 -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 NAA19437; Fri, 4 Sep 1998 13:48:53 -0500 (CDT) Received: from bmc.com (LUCILLE.bmc.com [192.146.153.145]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id NAA04602; Fri, 4 Sep 1998 13:48:51 -0500 (CDT) Message-ID: <35F03557.9EF9A6B1@bmc.com> Date: Fri, 04 Sep 1998 11:45:43 -0700 From: Lauren Heintz X-Mailer: Mozilla 4.04 [en] (WinNT; U) MIME-Version: 1.0 To: battle@snmp.com CC: rpresuhn@dorothy.bmc.com, agentx@peer.com Subject: Re: AgentX MIB issue 7 References: <199809041652.MAA22614@seymour16.snmp.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I believe everyone I've tested with had varying versions of the AgentX MIB -- and few (if not none) had significant error instrumentation. Still, we all managed to interoperate successfully and I don't remember anyone ever crying out, "Oh, if we only had some error counters in this darn MIB!" Translation: nix the error counters and keep the MIB simple. Tks, Lauren battle@snmp.com wrote: > > > When we add things to this MIB, they should be demonstrably useful and > > Frankly it's not clear to me that we need a mib at all. EMANATE has been > very successful to-date without a mib at all, and like you said it isn't > needed for multi-vendor interoperability. > > Thanks, > -David -- -------------------------------------------------------------------------- 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 Sep 4 15:44:32 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 PAA28554 for ; Fri, 4 Sep 1998 15:44:31 -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 PAA06518; Fri, 4 Sep 1998 15:41:21 -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 PAA07410; Fri, 4 Sep 1998 15:40:59 -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 NAA15531 for ; Fri, 4 Sep 1998 13:05:04 -0700 (PDT) Received: from relay4.smtp.psi.net (relay4.smtp.psi.net [38.9.52.2]) by almond.bmc.com (8.9.1/8.9.1) with ESMTP id PAA00224 for ; Fri, 4 Sep 1998 15:05:01 -0500 (CDT) Received: from [192.152.208.5] (helo=acecomm.com) by relay4.smtp.psi.net with smtp (Exim 1.90 #1) id 0zF268-0004dl-00; Fri, 4 Sep 1998 16:04:53 -0400 Received: from bnatale by acecomm.com (5.65/3.2.083191-ACE*COMM) id AA24273; Fri, 4 Sep 1998 16:07:10 -0400 Message-Id: <9809042007.AA24273@acecomm.com> X-Sender: natale@nips.acec.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1 Date: Fri, 04 Sep 1998 16:07:21 -0400 To: Lauren Heintz From: Bob Natale Subject: Re: AgentX MIB issue 7 Cc: agentx@peer.com In-Reply-To: <35F03557.9EF9A6B1@bmc.com> References: <199809041652.MAA22614@seymour16.snmp.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" >At 9/4/98 11:45 AM, Lauren Heintz wrote: Hi Lauren, >I believe everyone I've tested with had varying versions >of the AgentX MIB -- and few (if not none) had significant >error instrumentation. Still, we all managed to interoperate >successfully and I don't remember anyone ever crying out, >"Oh, if we only had some error counters in this darn MIB!" I can only try to restate what I said (evidently unclearly) in my response to Randy's message on this thread: I don't think it proves much (or counts for all that much) that multiple implementations of the protocol are able to inter- operate w/o a MIB. What is the basis for the assertion that the purpose of the MIB is implementation interoperability? I don't believe that is the primary purpose of the MIB--indeed, as your comments (and the similar ones from Randy and David) indicate, the MIB may serve no (essential) purpose wrt implementation interoperability at all. So what? The primary purpose of the AgentX MIB--as with most (all?) MIBs--is to enable the relevant user group(s)--primarily sysAdmins in this case--to manage their environment. At least, that's how I read the situation and, since that group (as usual/always) is vastly under-represnted in such a WG, I must (as WG chair) ensure that their interests are fairly represented (which does not mandate a certain outcome, however) and I am also expressing my technical opinion on the matter (which may well be proved wrong). >Translation: nix the error counters and keep the MIB simple. Re-translation: Let's take a closer look at who *should* benefit from an AgentX MIB and what *their* needs may 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 ashishkh@wipinfo.soft.net Mon Sep 7 01:22:05 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 BAA19315 for ; Mon, 7 Sep 1998 01:22:05 -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 BAA24047; Mon, 7 Sep 1998 01:15:47 -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 BAA05490; Mon, 7 Sep 1998 01:15:21 -0500 (CDT) Received: from almond.bmc.com (almond.bmc.com [172.17.0.100]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id WAA16114 for ; Sun, 6 Sep 1998 22:04:18 -0700 (PDT) Received: from wipinfo.soft.net (agni.wipinfo.soft.net [164.164.6.20]) by almond.bmc.com (8.9.1/8.9.1) with SMTP id AAA21394 for ; Mon, 7 Sep 1998 00:04:03 -0500 (CDT) Received: from tagore.wipinfo.soft.net by wipinfo.soft.net (SMI-8.6/SMI-SVR4) id KAA04560; Mon, 7 Sep 1998 10:28:36 -0500 From: "Ashish Hanwadikar" To: "Agentx" Subject: AgentX Session Date: Mon, 7 Sep 1998 10:34:06 +0530 Message-ID: <006401bdda1c$f0739cd0$163409c0@opel.wipinfo.soft.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0065_01BDDA4B.0A2BD8D0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal X-Mimeole: Produced By Microsoft MimeOLE V4.72.2106.4 This is a multi-part message in MIME format. ------=_NextPart_000_0065_01BDDA4B.0A2BD8D0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi, We are trying to implement AgentX Master Agent. During design discussions the question came as what exactly is importance of AgentX Sessions? What is the benefit of having multiple AgentX Sessions on the top of Transport connections? It is making things slight complicated for the implementation? Will the thing become simplified if we have only one session per transport connection? I could make out how multiple sessions will help either the master agent or the sub agent developer and in what situation it will make sense? Maybe I am asking a very preliminary question! Thanks in advance. Ashish K Hanwadikar Senior Software Engineer, Wipro Infotech, Technology Solutions, Bangalore INDIA ------=_NextPart_000_0065_01BDDA4B.0A2BD8D0 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_0065_01BDDA4B.0A2BD8D0-- From rpresuhn@dorothy.bmc.com Tue Sep 8 12: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 MAA21911 for ; Tue, 8 Sep 1998 12:53:30 -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 MAA23180; Tue, 8 Sep 1998 12:50:04 -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 MAA18767; Tue, 8 Sep 1998 12:49:43 -0500 (CDT) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id JAA16805 for agentx@peer.com; Tue, 8 Sep 1998 09:35:16 -0700 (PDT) Date: Tue, 8 Sep 1998 09:35:16 -0700 (PDT) From: Randy Presuhn Message-Id: <199809081635.JAA16805@dorothy.bmc.com> To: agentx@peer.com Subject: Re: AgentX Session Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi - > From: "Ashish Hanwadikar" > To: "Agentx" > Subject: AgentX Session > Date: Mon, 7 Sep 1998 10:34:06 +0530 ... > We are trying to implement AgentX Master Agent. During design discussions > the question came as what exactly is importance of AgentX Sessions? They are a mandatory element of the protocol as defined by RFC 2257. > What is > the benefit of having multiple AgentX Sessions on the top of Transport > connections? Simplifies "cascading" subagents (not an explicit design goal) on systems severely limiting the number of open sockets per process. For more history, see RFC 1592 clause 2.1, DPIv2. > It is making things slight complicated for the implementation? I don't think so. There are other good design reasons for an implementation to distinguish connection state from session state, particularly if you plan to support transports beyond just TCP. > Will the thing become simplified if we have only one session per transport > connection? It would mean that your implementation would not be able to interoperate with some subagents developed in conformance to the specification. > I could make out how multiple sessions will help either the > master agent or the sub agent developer and in what situation it will make > sense? ... The capability is primarily of value to a subagent developer. See above. Note that there has been some talk of dropping this capability. ----------------------------------------------------------------------- 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 Sep 9 17:50: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 RAA13274 for ; Wed, 9 Sep 1998 17:50:10 -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 RAA23796; Wed, 9 Sep 1998 17:46:40 -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 RAA27614; Wed, 9 Sep 1998 17:46:22 -0500 (CDT) Received: from cashew.bmc.com (cashew.bmc.com [172.19.0.100]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id OAA06089 for ; Wed, 9 Sep 1998 14:21:44 -0700 (PDT) Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by cashew.bmc.com (8.9.1/8.9.1) with ESMTP id QAA01284 for ; Wed, 9 Sep 1998 16:21:40 -0500 (CDT) Received: from quarry.zk3.dec.com (quarry.zk3.dec.com [16.140.16.3]) by mail11.digital.com (8.8.8/8.8.8/WV1.0g) with SMTP id RAA15689; Wed, 9 Sep 1998 17:20:40 -0400 (EDT) Received: from bernie.zk3.dec.com by quarry.zk3.dec.com; (5.65v4.0/1.1.8.2/16Jan95-0946AM) id AA11299; Wed, 9 Sep 1998 17:20:41 -0400 Received: from localhost by bernie.zk3.dec.com; (5.65/1.1.8.2/22Aug96-1117AM) id AA08058; Wed, 9 Sep 1998 17:21:04 -0400 Message-Id: <9809092121.AA08058@bernie.zk3.dec.com> To: Bob Natale Cc: agentx@peer.com Subject: Re: AgentX MIB issue 7 In-Reply-To: Your message of "Fri, 04 Sep 98 16:07:21 EDT." <9809042007.AA24273@acecomm.com> Date: Wed, 09 Sep 98 17:21:04 -0400 From: Mike Daniele X-Mts: smtp Hi Bob, >What is the basis for the assertion that the purpose of the >MIB is implementation interoperability? I don't believe that >is the primary purpose of the MIB--indeed, as your comments >(and the similar ones from Randy and David) indicate, the >MIB may serve no (essential) purpose wrt implementation >interoperability at all. So what? I think what happened was something like this: 1) T. Max Devlin posted something that said, *roughly*, you won't be able to have interoperability without a MIB with good error counters. 2) Lauren pointed out that this is not the case, using the bakeoff as an example. As such, I think you and Lauren agree :-) >The primary purpose of the AgentX MIB--as with most (all?) >MIBs--is to enable the relevant user group(s)--primarily >sysAdmins in this case--to manage their environment. I think there is wide agreement with that statement. >>Translation: nix the error counters and keep the MIB simple. >Re-translation: Let's take a closer look at who *should* >benefit from an AgentX MIB and what *their* needs may be. Makes sense. To me, the sysadmin needs 1) to be able to control which subagents start, and perhaps how they register (what priority) 2) to be able to view the state of the registry 3) to be able to alter the registry by one or more of a) stopping subagents b) closing sessions c) forcing unregistrations I don't believe 1) is possible via this MIB. It's a question of what applications are started with what specific configuration parameters. 2) is fulfilled by the session and registration tables 3) b) is fulfilled by agentxSessionAdminStatus a) seems like too big a hammer c) may be too fine granularity I think what we have currently is a reasonable balance. The only error counter that seems to help here is agentxRegisterDuplicate. It would be more helpful it if were part of session table. (It might be even more helpful as part of the registration table, not sure.) My 2 cents, Mike From Lauren_Heintz@crow.bmc.com Mon Sep 14 14:47:13 1998 Return-Path: Received: from tangelo.bmc.com ([172.17.7.166]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id OAA08270 for ; Mon, 14 Sep 1998 14:47:13 -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 KAA06847; Mon, 14 Sep 1998 10:13:21 -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 IAA04911 for ; Mon, 14 Sep 1998 08:09:35 -0700 (PDT) Received: from bmc.com (LUCILLE.bmc.com [192.146.153.145]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id KAA04860; Mon, 14 Sep 1998 10:09:21 -0500 (CDT) Message-ID: <35FD30D1.E53EAFEB@bmc.com> Date: Mon, 14 Sep 1998 08:05:53 -0700 From: Lauren Heintz X-Mailer: Mozilla 4.04 [en] (WinNT; U) MIME-Version: 1.0 To: agentx@peer.com Subject: Post-IETF AgentX MIB Issues update. Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit FYI: The following is a list of current issues and their current "strawman" resolutions as I believe I understand things to have been determined at the Chicago IETF. Related issues have been grouped (in parentheses) to simplify matters from here on out. The issue numbers correspond to the issues I discussed at the IETF AgentX WG session and which I had posted on the mail-list just before the IETF. Lauren ------------------------------------------------------------ NEED CONSENSUS: Issues 8 (3,7): AgentX error counters need to be defined (unless goal 4 in Section 2 of RFC2257 is instead removed). Not clear yet whether error counters should be wholly contained in a new table, or each of the current tables would contain a few new columns to represent important error counters that pertain to the associated connection, session, or registration. Issue 18: Should the agentxConnectionTable be removed and pertinent information instead be included in the agentxSessionTable? Rationale for removal: The table is overkill -- especially for implementations that open few sessions on a single connection. The address and domain info could be added to the session table. Although this info would be redundant for each session entry using the same connection, it is anticipated that most implementations would use only one session per connection. Issue 19: Should agentxSessionAdminStatus be of type RowStatus? Rationale for using RowStatus: The current possible values for agentxSessionAdminStatus are "up(1)" and "down(2)", which in essence determine if the associated entry (and the logical session which it defines) is active or should be removed. The purpose of RowStatus, on the other hand, is to "manage the creation and deletion of conceptual rows." (first sentence of RowStatus description in RFC 1903). ------------------------------------------------------------ CONSENSUS FORMED: Resolution for the following issues seem to have reached a consensus (as indicated). Issue 1: TDomain and TAddres TC definitions will be provided somewhere other than the AgentX MIB, so will be removed. Issue 2: agentxSessionIndex should be the same as h.SessionID. However, this may depend on how RFC2257 is finalized. Issue 4: agentxRegEnd will be replaced by agentxRegRangeSubid and agentxRegUpperBound so the entry will unambiguously reflect the protocol elements. Issues 5 (6): Table indicing will reflect inter-table relationships. If an error table is added, it will be indexed by agentxSessionIndex. If the connection table is deleted, agentxConnIndex will be deleted from all other tables as an index. Issue 9: DEFVALs for all read-only row objects will be removed. Issue 10: The last sentence in the agentxSessionEntry description will be removed. Issue 19 could render this issue obsolete! Issue 11: The UTF8String TC will be removed and its references will be replaced by snmpAdminString. Issue 12: Comment regarding sysObjectID will be removed from the description of the agentxSessionObjectID. Issue 13 (15, 16): Each table will be consistent and have an associated "time of last change" scalar but not a "number of entries" scalar. Issue 14: agentxConnTransportAddr description will be updated to reflect possibility of NULL values for some types of transports. Issue 18 could render this issue obsolete! Issue 17: The comment "... or sysOrTable?" under the agentxSessionObjectID definition will be removed. ------------------------------------------------------------------------ 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 12886144@18131.com.bmc.com Tue Sep 15 12:34:51 1998 Return-Path: <12886144@18131.com.bmc.com> Received: from tangelo.bmc.com ([172.17.7.166]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id MAA24769 for ; Tue, 15 Sep 1998 12:34:51 -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 MAA20391; Tue, 15 Sep 1998 12:32:16 -0500 (CDT) From: 12886144@18131.com.bmc.com 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 KAA27986; Tue, 15 Sep 1998 10:29:41 -0700 (PDT) Received: from fw-us-hou1.bmc.com (fw-us-hou1.bmc.com [172.17.0.250]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with SMTP id MAA19337; Tue, 15 Sep 1998 12:27:01 -0500 (CDT) Received: from caspian.hearst.com ([207.170.105.156]) by caspian.hearst.com (Netscape Mail Server v2.0) with SMTP id AAD27597; Tue, 15 Sep 1998 13:03:15 -0400 Received: from login_0246.whynot.net (mx.whynot.net[206.212.231.88]) by whynot.net (8.8.5/8.6.5) with SMTP id GAA06742 for ; Tue, 17 Jun 1997 23:53:05 -0600 (EST) Date: Tue, 17 Jun 97 23:53:05 EST To: sender422@mail.whynot.net Subject: Re: subject Message-ID: <93904039291232@hsd_hypothesis.com> Reply-To: sample@mail.whynot.net X-PMFLAGS: 10322341.10 X-UIDL: 10293287_192832.222 Comments: Authenticated sender is GET IT OUT THERE! WHERE PEOPLE CAN SEE IT!! Tired of endlessly posting your ad to ONLINE CLASSIFIED SITES that don't get the results you need? The fact is there are over 7000 such sites scattered about the web and frankly none of them generate enough traffic to be worth your while. The greatest way of marketing this century is undoubtedly direct e-mail. The ability to promote your product, service, website or MLM/Network Marketing opportunity to millions instantly is what advertisers have been dreaming of for over 100 years. And the greatest part, it's completely affordable. We will e-mail your one page promotion to a list of our general and/or targeted list. Call 1-972-227-7286 to get current prices. If you respond by 26th of September, receive a special discount. NOTICE: No pornogaphy, chain letters, get quick rich scheme, or any threating or questionable materials. Don't even Ask!! * * * SPECIAL OF THE DAY: 20 Million addresses on a CD-ROM, General and targeted. This CD consists 16 of the biggest companies. Also receive targeted lists of Bizmlm, Bizopp, Consumer, food, health, investing and etc. Other services charge upward of 5 cents per address for this type of targeted list. (appx. 1.6 million) This CD has over 20 million addresses, these are less than 30 days old. This CD was sorted/deduped, and randomized in each domain. These were run against the global remove list, and through our 140 mb (almost 7million) remove\flamer list. The EDU, ORG, Gov, Mil, and US was removed with some domains that ask not receive e-mail. Then CD was run against our custom filter with 492 keywords to remove more. Also we have 61mbs of undeliverables, just to make sure our list are clean as possible. Regular price is $299, but If its purchased before 9-26-98 Only $199 and PRIORITY shipping is included. Call 1-972-227-7286 for complete details. From mwhite@cmu.edu Mon Sep 28 13:45:24 1998 Return-Path: Received: from tangelo.bmc.com ([172.17.7.166]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id NAA27891 for ; Mon, 28 Sep 1998 13:45:24 -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 NAA09672; Mon, 28 Sep 1998 13:42:13 -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 LAA27347 for ; Mon, 28 Sep 1998 11:37:29 -0700 (PDT) Received: from fw-us-hou1.bmc.com (fw-us-hou1.bmc.com [172.17.0.250]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with SMTP id NAA08175 for ; Mon, 28 Sep 1998 13:37:25 -0500 (CDT) Received: from FOLD.REM.CMU.EDU (FOLD.REM.CMU.EDU [128.2.6.40]) by smtp1.andrew.cmu.edu (8.8.5/8.8.2) with ESMTP id OAA04443 for ; Mon, 28 Sep 1998 14:37:04 -0400 (EDT) Date: Mon, 28 Sep 1998 14:36:08 -0400 From: Matt White To: agentx@peer.com Subject: Error values in the AgentX Notify PDU Message-ID: <755268744.906993368@FOLD.REM.CMU.EDU> Originator-Info: login-id=; server=cyrus.andrew.cmu.edu X-Mailer: Mulberry (Win32) [1.4.0b3, s/n S-100002] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline At the Chicago IETF meeting I believe that it was decided that both the Open and Notify PDUs should always send a response PDU, as opposed to just sending a response when an error occurred. With regard to the Notify PDU, this means that we can get an error value of noError or notOpen in the response PDU. It occurs to me that we might want to also allow genErr to indicate that an error in processing occurred and that the notification was not delivered. This could be useful in the case of a master delivering notifications via some reliable transport where a response to the subagent could be delayed until the notification has been delivered and acknowledged. -Matt ---------- Matt White Network Systems Designer Canegie Mellon Computing Services From bnatale@acecomm.com Mon Sep 28 14:08:27 1998 Return-Path: Received: from tangelo.bmc.com ([172.17.7.166]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id OAA28086 for ; Mon, 28 Sep 1998 14:08:26 -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 OAA17106; Mon, 28 Sep 1998 14:05:42 -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 MAA28132 for ; Mon, 28 Sep 1998 12:05:25 -0700 (PDT) Received: from fw-us-hou1.bmc.com (fw-us-hou1.bmc.com [172.17.0.250]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with SMTP id OAA16972 for ; Mon, 28 Sep 1998 14:05:21 -0500 (CDT) Received: from [192.152.208.5] (helo=acecomm.com) by relay3.smtp.psi.net with smtp (Exim 1.90 #1) id 0zNibQ-0003Ya-00; Mon, 28 Sep 1998 15:04:57 -0400 Received: from bnatale by acecomm.com (5.65/3.2.083191-ACE*COMM) id AA02115; Mon, 28 Sep 1998 15:07:43 -0400 Message-Id: <9809281907.AA02115@acecomm.com> X-Sender: natale@nips.acec.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 Date: Mon, 28 Sep 1998 15:08:02 -0400 To: Matt White From: Bob Natale Subject: Re: Error values in the AgentX Notify PDU Cc: agentx@peer.com In-Reply-To: <755268744.906993368@FOLD.REM.CMU.EDU> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" >At 9/28/98 02:36 PM, Matt White wrote: Hi Matt, >At the Chicago IETF meeting I believe that it was decided that >both the Open and Notify PDUs should always send a response PDU, >as opposed to just sending a response when an error occurred. I think you mean the "Close and Notify PDUs" there...? And, yes, that was the consensus of the meeting attendees. However, this will yet be put before the full list for any desired discussion or refinement. (I apologize for the delay in that discussion process...we had hoped to peg it to the posting of the meeting minutes...unfortunately, our faithful editor--Dale Francisco-- was sent on assignment out of the country by his employer in the interim, resulting in this unfortunately delay. I *believe* that Dale will be back in action with us later this week.) >With regard to the Notify PDU, this means that we can get an >error value of noError or notOpen in the response PDU. It occurs >to me that we might want to also allow genErr to indicate that an >error in processing occurred and that the notification was not >delivered. Yes, "genErr" is another one we saw the need for at the bake-off and saw no dissent on at the IETF meeting. I *believe* that genErr will be allowed for all PDU types...although, as we often say in SNMP, it's use will be discouraged except for the truly unavoidable cases (or better words to that effect). >This could be useful in the case of a master delivering >notifications via some reliable transport where a response to >the subagent could be delayed until the notification has been >delivered and acknowledged. Hmmm. I *think* the master agent would probably deliver a "noError" response to the subagent when it (the master) determined that the sub's Notify PDU was "correct" iaw some local definition of that term and the master had the resources and connectivity to process and transmit the corresponding SNMP notification message--I do not think the downstream receipt of the notification by the target will be communicated back to the sub, one way or the other. 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 mwhite@cmu.edu Mon Sep 28 17:04:55 1998 Return-Path: Received: from tangelo.bmc.com ([172.17.7.166]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id RAA29518 for ; Mon, 28 Sep 1998 17:04: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 RAA10438; Mon, 28 Sep 1998 17:03:23 -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 PAA04647 for ; Mon, 28 Sep 1998 15:02:09 -0700 (PDT) Received: from fw-us-hou1.bmc.com (fw-us-hou1.bmc.com [172.17.0.250]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with SMTP id RAA10155 for ; Mon, 28 Sep 1998 17:02:05 -0500 (CDT) Received: from FOLD.REM.CMU.EDU (FOLD.REM.CMU.EDU [128.2.6.40]) by smtp1.andrew.cmu.edu (8.8.5/8.8.2) with ESMTP id SAA21607; Mon, 28 Sep 1998 18:01:48 -0400 (EDT) Date: Mon, 28 Sep 1998 18:00:27 -0400 From: Matt White To: agentx@peer.com cc: Bob Natale Subject: Re: Error values in the AgentX Notify PDU Message-ID: <767528444.907005627@FOLD.REM.CMU.EDU> In-Reply-To: <9809281907.AA02115@acecomm.com> Originator-Info: login-id=; server=cyrus.andrew.cmu.edu X-Mailer: Mulberry (Win32) [1.4.0b3, s/n S-100002] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline --On Monday, September 28, 1998, 3:08 PM -0400 Bob Natale wrote: > I think you mean the "Close and Notify PDUs" there...? And, yes, > that was the consensus of the meeting attendees. However, this > will yet be put before the full list for any desired discussion > or refinement. Yes, that is what I meant. > Hmmm. I *think* the master agent would probably deliver a > "noError" response to the subagent when it (the master) > determined that the sub's Notify PDU was "correct" iaw some > local definition of that term and the master had the resources > and connectivity to process and transmit the corresponding > SNMP notification message--I do not think the downstream > receipt of the notification by the target will be communicated > back to the sub, one way or the other. This behaviour is somewhat less useful than waiting until an ack has been received to send a Response PDU. Remember that the wording of the RFC2257 states that what the master does with the Notify is implementation specific and may include: SNMP Traps, SNMP Informs, syslog, paging, mailing a xmas card to your grandmother or dropping the packet on the floor. Some of these actions provide a way of determining whether the notification was received by recipient. This is useful information to the subagent -- there is actually an application here that requires it. What I am suggesting is that there be an error type of 'notDelivered' or some such thing that the master can reply to Notify PDUs with. We don't require its use since we don't say much about what to do with AgentX Notify PDUs. That way, if a master wants to inform the subagent that it was not able to deliver the notification, there is a simple way of doing so. This has the inherent restriction that the master must time out the notification that it sends before the AgentX Notify times out, but I would not think this too counter-intuitive. -Matt ---------- Matt White Network Systems Designer Canegie Mellon Computing Services From daniele@zk3.dec.com Tue Sep 29 12:55:56 1998 Return-Path: Received: from tangelo.bmc.com ([172.17.7.166]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id MAA09086 for ; Tue, 29 Sep 1998 12:55:56 -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 MAA05037; Tue, 29 Sep 1998 12:52:38 -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 KAA22183 for ; Tue, 29 Sep 1998 10:51:05 -0700 (PDT) Received: from fw-us-hou1.bmc.com (fw-us-hou1.bmc.com [172.17.0.250]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with SMTP id MAA04472 for ; Tue, 29 Sep 1998 12:50:58 -0500 (CDT) 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 NAA02033; Tue, 29 Sep 1998 13:48:37 -0400 (EDT) Received: from bernie.zk3.dec.com by flume.zk3.dec.com (5.65v4.0/1.1.8.2/16Jan95-0946AM) id AA25396; Tue, 29 Sep 1998 13:48:36 -0400 Received: from localhost by bernie.zk3.dec.com; (5.65/1.1.8.2/22Aug96-1117AM) id AA01064; Tue, 29 Sep 1998 13:49:07 -0400 Message-Id: <9809291749.AA01064@bernie.zk3.dec.com> To: Matt White Cc: agentx@peer.com Subject: Re: Error values in the AgentX Notify PDU In-Reply-To: Your message of "Mon, 28 Sep 98 18:00:27 EDT." <767528444.907005627@FOLD.REM.CMU.EDU> Date: Tue, 29 Sep 98 13:49:07 -0400 From: Mike Daniele X-Mts: smtp Matt, >Some of these actions provide a way of determining whether the notification >was received by recipient. This is useful information to the subagent -- >there is actually an application here that requires it. What I am >suggesting is that there be an error type of 'notDelivered' or some such >thing that the master can reply to Notify PDUs with. How would you foresee this working when a master is configured to send notifications to several targets, and some accept delivery and some don't? Thanks, Mike From mwhite@cmu.edu Tue Sep 29 13:47:17 1998 Return-Path: Received: from tangelo.bmc.com ([172.17.7.166]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id NAA09503 for ; Tue, 29 Sep 1998 13:47:17 -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 NAA21983; Tue, 29 Sep 1998 13:42:56 -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 LAA23591 for ; Tue, 29 Sep 1998 11:39:58 -0700 (PDT) Received: from fw-us-hou1.bmc.com (fw-us-hou1.bmc.com [172.17.0.250]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with SMTP id NAA20934 for ; Tue, 29 Sep 1998 13:39:50 -0500 (CDT) Received: from FOLD.REM.CMU.EDU (FOLD.REM.CMU.EDU [128.2.6.40]) by smtp1.andrew.cmu.edu (8.8.5/8.8.2) with ESMTP id OAA01704; Tue, 29 Sep 1998 14:38:47 -0400 (EDT) Date: Tue, 29 Sep 1998 14:37:44 -0400 From: Matt White To: agentx@peer.com cc: Mike Daniele Subject: Re: Error values in the AgentX Notify PDU Message-ID: <841765194.907079864@FOLD.REM.CMU.EDU> In-Reply-To: <9809291749.AA01064@bernie.zk3.dec.com> Originator-Info: login-id=; server=cyrus.andrew.cmu.edu X-Mailer: Mulberry (Win32) [1.4.0b3, s/n S-100002] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Hmmm...my apologies. I didn't really answer your question, did I? The answer is: it depends. The master agent designer could do one of several things: * reply noError if the notification was ACKed by any of its recipients * reply notDelivered if the notification was NAKed by any of its recipients * maintain groups of recipients that are 'important' and apply one of the above to that group. There's going to be some fuzziness about this since the subagent has no concept of where its notifications are going. -Matt ---------- Matt White Network Systems Designer Canegie Mellon Computing Services --On Tuesday, September 29, 1998, 1:49 PM -0400 Mike Daniele wrote: > Matt, > >> Some of these actions provide a way of determining whether the >> notification was received by recipient. This is useful information to >> the subagent -- there is actually an application here that requires it. >> What I am suggesting is that there be an error type of 'notDelivered' or >> some such thing that the master can reply to Notify PDUs with. > > How would you foresee this working when a master is configured > to send notifications to several targets, and some accept delivery > and some don't? > > Thanks, > Mike From mwhite@cmu.edu Tue Sep 29 13:49:11 1998 Return-Path: Received: from tangelo.bmc.com ([172.17.7.166]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id NAA09521 for ; Tue, 29 Sep 1998 13:49:10 -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 NAA21985; Tue, 29 Sep 1998 13:42:56 -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 LAA23630 for ; Tue, 29 Sep 1998 11:40:20 -0700 (PDT) Received: from fw-us-hou1.bmc.com (fw-us-hou1.bmc.com [172.17.0.250]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with SMTP id NAA21024 for ; Tue, 29 Sep 1998 13:40:17 -0500 (CDT) Received: from FOLD.REM.CMU.EDU (FOLD.REM.CMU.EDU [128.2.6.40]) by smtp1.andrew.cmu.edu (8.8.5/8.8.2) with ESMTP id OAA01017; Tue, 29 Sep 1998 14:31:09 -0400 (EDT) Date: Tue, 29 Sep 1998 14:30:09 -0400 From: Matt White To: Mike Daniele cc: agentx@peer.com Subject: Re: Error values in the AgentX Notify PDU Message-ID: <841310514.907079409@FOLD.REM.CMU.EDU> In-Reply-To: <9809291749.AA01064@bernie.zk3.dec.com> Originator-Info: login-id=; server=cyrus.andrew.cmu.edu X-Mailer: Mulberry (Win32) [1.4.0b3, s/n S-100002] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline The purpose of the notDelivered error is to inform the subagent that the subagent was not heard and should seek alternate forms of communication or attempt to deal with the situation on its own. In the case of one or more ACKs and one or more NAKs, master behaviour is implementation specific because there is no way for us to know the right thing to do now at the writing of this document. In reality, a master agent should allow this to be a user-configurable option, so that a given site can choose an appropriate behaviour for their application. -Matt --On Tuesday, September 29, 1998, 1:49 PM -0400 Mike Daniele wrote: > Matt, > >> Some of these actions provide a way of determining whether the >> notification was received by recipient. This is useful information to >> the subagent -- there is actually an application here that requires it. >> What I am suggesting is that there be an error type of 'notDelivered' or >> some such thing that the master can reply to Notify PDUs with. > > How would you foresee this working when a master is configured > to send notifications to several targets, and some accept delivery > and some don't? > > Thanks, > Mike From wwwpages@msn.com Wed Sep 30 10:15:09 1998 Return-Path: Received: from tangelo.bmc.com ([172.17.7.166]) by amethyst.bmc.com (8.8.8/8.8.8) with ESMTP id KAA28381 for ; Wed, 30 Sep 1998 10:15:09 -0500 (CDT) From: wwwpages@msn.com 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 KAA02228; Wed, 30 Sep 1998 10:06:42 -0500 (CDT) Received: from tangelo.bmc.com (tangelo.bmc.com [172.17.7.166]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id IAA11237; Wed, 30 Sep 1998 08:03:19 -0700 (PDT) Received: from fw-us-hou1.bmc.com (fw-us-hou1.bmc.com [172.17.0.250]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with SMTP id KAA01113; Wed, 30 Sep 1998 10:02:48 -0500 (CDT) Message-Id: <199809301502.KAA01113@tangelo.bmc.com> Date: Wed, 30 Sep 1998 06:19:35 Subject: $1,000 FREE ADVERTISING FOR STUDY PARTICIPATION Receive up to $1,000 OF FREE ADVERTISING as part of a study to evaluate the benefits of different types of online advertising. Analysts will work with study participants to develop campaigns that meet both the requirements of the study and the goals of the study participant. You may choose virtually any form of online advertising offered by any company to target your online audience. Web sites will then be monitored to assess the benefits of selected campaigns. This is a privately funded study and there are no charges, obligations, fees, or paperwork required. Please note that due to cost constraints space is limited. For more information or to register (three minutes), please visit http://wwwpages.org/study.asp . If you have questions about the study, please e-mail questions@wwwpages.org and we will get back to you as soon as possible. Thank You, WWWPages