Delivery-Date: Fri, 03 Nov 1995 10:34:12 -0500 Received: (from daemon@localhost) by fv.com (8.6.10/8.6.10) id KAA14750 for X-agentx-local; Fri, 3 Nov 1995 10:31:24 -0500 Received: from LOTAN.DRAGON.COM (lotan.dragon.com [155.229.20.3]) by fv.com (8.6.10/8.6.10) with SMTP id KAA14740 for ; Fri, 3 Nov 1995 10:31:21 -0500 From: cheryl@empiretech.com Received: by dragon.com (MX V4.1 VAX) with UUCP; Fri, 03 Nov 1995 10:32:10 EDT Received: (from cheryl@localhost) by emptech.empiretech.com (8.6.12/8.6.12) id JAA04738 for agentx@fv.com; Fri, 3 Nov 1995 09:43:21 -0500 Message-ID: <199511031443.JAA04738@emptech.empiretech.com> Subject: Dallas meeting To: agentx@fv.com Date: Fri, 3 Nov 1995 09:43:20 -0500 (EST) X-Mailer: ELM [version 2.4 PL22] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 610 When is the meeting at the Dallas IETF? +--------------------------------------------------------------------+ + Check us out! http://www.empiretech.com/empiretech + +--------------------------------------------------------------------+ + Cheryl Krupczak NEW ADDRESS Empire Technologies, Inc. + + cheryl@empiretech.com AND 541 Tenth Street NW + + PH : (770)384-0184 PHONE NUMBERS! Suite 169 + + FAX: (770)384-0183 (eff. Oct. 29) Atlanta, GA 30318 + +--------------------------------------------------------------------+   Delivery-Date: Fri, 03 Nov 1995 12:40:04 -0500 Received: (from daemon@localhost) by fv.com (8.6.10/8.6.10) id MAA01229 for X-agentx-local; Fri, 3 Nov 1995 12:27:00 -0500 Received: from tsunami.fv.com ([204.250.93.202]) by fv.com (8.6.10/8.6.10) with ESMTP id MAA01225 for ; Fri, 3 Nov 1995 12:26:59 -0500 Received: from localhost (localhost [127.0.0.1]) by tsunami.fv.com (8.6.10/8.6.10) with ESMTP id JAA01981; Fri, 3 Nov 1995 09:25:29 -0800 To: cheryl@empiretech.com reply-to: agentx@fv.com cc: agentx@fv.com Subject: Re: Dallas meeting In-reply-to: Your message of "Fri, 03 Nov 1995 09:43:20 EST." <199511031443.JAA04738@emptech.empiretech.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----- =_aaaaaaaaaa0" Content-ID: <1979.815419528.0@dbc.mtview.ca.us> Date: Fri, 03 Nov 1995 09:25:28 -0800 Message-ID: <1980.815419528@dbc.mtview.ca.us> From: Marshall Rose ------- =_aaaaaaaaaa0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1979.815419528.1@dbc.mtview.ca.us> the secretariat is currently scheduling the meeting. when i am told how many slots we can get and when, i'll post it to this list. i'm sure that the secretariat will also be posting a general agenda soon. two administrative items: 1. i'm going to wait a couple of days before posting an agenda. there are two reasons for this: first, i'm trying to give people some time to subscribe; and, second, once i know how many slots we have, i'll have an idea on how much time to allocate for presentations and discussions... 2. as a courtesy to people who still haven't seen the wg-action message, i ask that early subscribers to this list please wait until the middle of next week before posting messages... /mtr ------- =_aaaaaaaaaa0 Content-Type: message/rfc822 Content-Description: original message Newsgroups: internet.ietf.agentx Received: from yukinojo.fv.com (yukinojo.fv.com [204.250.90.3]) by tsunami.fv.com (8.6.10/8.6.10) with ESMTP id JAA01553 for ; Fri, 3 Nov 1995 09:05:41 -0800 Resent-From: agentx-owner@fv.com Received: from fv.com (fv.com [199.100.120.3]) by yukinojo.fv.com (8.7.1/8.7.1) with ESMTP id HAA09157 for ; Fri, 3 Nov 1995 07:42:52 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by fv.com (8.6.10/8.6.10) with ESMTP id KAA15116 for ; Fri, 3 Nov 1995 10:34:12 -0500 Comment: Posted to the agentx Mailing List To unsubscribe, send mail to agentx-request@fv.com with "unsubscribe" in the Subject Resent-Date: Fri, 03 Nov 1995 10:34:12 -0500 Resent-Message-ID: <15113.815412852.1@fv.com> Received: (from daemon@localhost) by fv.com (8.6.10/8.6.10) id KAA14750 for X-agentx-local; Fri, 3 Nov 1995 10:31:24 -0500 Received: from LOTAN.DRAGON.COM (lotan.dragon.com [155.229.20.3]) by fv.com (8.6.10/8.6.10) with SMTP id KAA14740 for ; Fri, 3 Nov 1995 10:31:21 -0500 From: cheryl@empiretech.com Received: by dragon.com (MX V4.1 VAX) with UUCP; Fri, 03 Nov 1995 10:32:10 EDT Received: (from cheryl@localhost) by emptech.empiretech.com (8.6.12/8.6.12) id JAA04738 for agentx@fv.com; Fri, 3 Nov 1995 09:43:21 -0500 Message-ID: <199511031443.JAA04738@emptech.empiretech.com> Subject: Dallas meeting To: agentx@fv.com Date: Fri, 3 Nov 1995 09:43:20 -0500 (EST) X-Mailer: ELM [version 2.4 PL22] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit When is the meeting at the Dallas IETF? +--------------------------------------------------------------------+ + Check us out! http://www.empiretech.com/empiretech + +--------------------------------------------------------------------+ + Cheryl Krupczak NEW ADDRESS Empire Technologies, Inc. + + cheryl@empiretech.com AND 541 Tenth Street NW + + PH : (770)384-0184 PHONE NUMBERS! Suite 169 + + FAX: (770)384-0183 (eff. Oct. 29) Atlanta, GA 30318 + +--------------------------------------------------------------------+ ---------------- The above message was posted to the agentx Mailing List. You received it because you are subscribed to the list. If you wish to stop receiving such messages, please send mail to: agentx-request@fv.com with Subject: unsubscribe Please do not send such messages to the whole mailing list. Thank you for your cooperation. -- the list maintainers ------- =_aaaaaaaaaa0--   Delivery-Date: Thu, 09 Nov 1995 01:05:30 -0500 Received: (from daemon@localhost) by fv.com (8.7.1/8.7.1) id BAA13902 for X-agentx-local; Thu, 9 Nov 1995 01:04:52 -0500 (EST) Received: from tsunami.dbc.mtview.ca.us (tsunami.dbc.mtview.ca.us [204.250.93.202]) by fv.com (8.7.1/8.7.1) with ESMTP id BAA13899 for ; Thu, 9 Nov 1995 01:04:51 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by tsunami.dbc.mtview.ca.us (8.6.10/8.6.10) with ESMTP id WAA17349 for ; Wed, 8 Nov 1995 22:03:30 -0800 To: agentx@fv.com Subject: preparations for next month Reply-To: agentx@fv.com MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <17347.815897007.1@dbc.mtview.ca.us> Date: Wed, 08 Nov 1995 22:03:27 -0800 Message-ID: <17348.815897007@dbc.mtview.ca.us> From: Marshall Rose welcome to the agentx@fv.com working group. we have two slots (one wednesday, one friday) allocated to us; however, for the kickoff meeting, i feel a third slot may be necessary. more details on that as they develop...once i know the number of slots, i can circulate the agenda. for right now, i would like readers of this list to do some homework in preparation for the meeting. at the meeting, i am going to ask three questions of the group, and solicit answers in the form of prepared presentations and subsequent discussion. the questions are: - what are the issues which are driving agent extensibility? - what technologies exist which address these issues? - what are the real-world experiences with these technologies? note that i have phrased these questions to very carefully avoid any specific outcome. for example, everyone might agree on the answers given to the first question, but then someone might argue that packet-based multiplexing (proxy), instead of method-based multiplexing (agentx), is an acceptable answer to the second question. for the third question, i am interested in hearing answers that talk about both succeses and failures. for example, someone might discuss the problems which occur when two sub-agents need to talk with each other, and how they feel that this can be solved by MIB, but not protocol, design. please take some time to think these questions through before preparing your presentations. however, feel free to ask questions now in terms of clarifications, etc. /mtr ps: if you can not attend the meeting, and want to make a presentation, you can e-mail postscript by november 30 and i will present your materials, in a neutral fashion to the group.   Delivery-Date: Wed, 15 Nov 1995 17:11:13 -0500 Received: (from daemon@localhost) by fv.com (8.7.1/8.7.1) id RAA15951 for X-agentx-local; Wed, 15 Nov 1995 17:11:12 -0500 (EST) Received: from tsunami.dbc.mtview.ca.us (tsunami.dbc.mtview.ca.us [204.250.93.202]) by fv.com (8.7.1/8.7.1) with ESMTP id RAA15947 for ; Wed, 15 Nov 1995 17:11:10 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by tsunami.dbc.mtview.ca.us (8.6.10/8.6.10) with ESMTP id OAA17998; Wed, 15 Nov 1995 14:09:42 -0800 To: Ilan Raab reply-to: agentx@fv.com cc: snmpv2@tis.com Subject: Re: agentx In-reply-to: Your message of "Wed, 15 Nov 1995 09:34:30 PST." <9511151734.AA12984@scooby.engwest> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----- =_aaaaaaaaaa0" Content-ID: <17986.816473340.0@dbc.mtview.ca.us> Date: Wed, 15 Nov 1995 14:09:34 -0800 Message-ID: <17994.816473374@dbc.mtview.ca.us> From: Marshall Rose ------- =_aaaaaaaaaa0 Content-Type: text/plain; charset="us-ascii" Content-ID: <17986.816473340.1@dbc.mtview.ca.us> > What is this new group? Can you please give me a brief synopsis? I enclose two messages. The first is the wg activation notice, which contains the charter. The second is the kick-off message which was sent. Further discussion should occur on the agentx@fv.com mailing list. ------- =_aaaaaaaaaa0 Content-Type: multipart/digest; boundary="----- =_aaaaaaaaaa1" Content-ID: <17986.816473340.2@dbc.mtview.ca.us> ------- =_aaaaaaaaaa1 Content-Type: message/rfc822 Newsgroups: internet.ietf Received: from yukinojo.fv.com (yukinojo.fv.com [204.250.90.3]) by tsunami.fv.com (8.6.10/8.6.10) with ESMTP id HAA00925 for ; Fri, 3 Nov 1995 07:56:00 -0800 Received: from IETF.nri.reston.VA.US (ietf.cnri.reston.va.us [132.151.1.35]) by yukinojo.fv.com (8.7.1/8.7.1) with SMTP id HAA09291 for ; Fri, 3 Nov 1995 07:56:24 -0800 (PST) Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11922; 3 Nov 95 9:19 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa10192; 3 Nov 95 7:57 EST Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa07873; 3 Nov 95 7:57 EST Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa10186; 3 Nov 95 7:57 EST To: IETF-Announce:; Subject: WG Action:SNMP Agent Extensibility (agentx) Date: Fri, 03 Nov 95 07:57:03 -0500 Sender: ietf-announce-request@IETF.CNRI.Reston.VA.US From: Steve Coya Message-ID: <9511030757.aa10186@IETF.CNRI.Reston.VA.US> A new working group has been formed in the Network Management Area of the IETF. For more information, please contact the working group chair or the Area Director. SNMP Agent Extensibility (agentx) --------------------------------- Chair(s): Marshall T. Rose Network Management Area Director(s): Deirdre Kostick Mailing lists: General Discussion:agentx@fv.com To Subscribe: agentx-request@fv.com In Body: Subject: subscribe Archive: ftp://fv.com/pub/mrose/agentx Description of Working Group: The goal of this working group is to define standards-track technology for SNMP Agent extensibility. The resulting technology specification will allow independently developed sub-agents to communicate with a master-agent running on an Internet device. The technology specification will consist of: o (mandatory) a platform-independent protocol which supports intra-agent communication within a device or local area network; o (optional) a MIB module, which, when implemented by a master-agent, allows an SNMP-based management application to monitor and control the intra-agent communication service; and, o (optional) a programmatic interface to the services offered by that protocol. The working group is explicitly directed to develop a solution which is adequate to achieve transparency with respect to whether a SNMP request is processed by a master-agent and/or one or more sub-agents; simultaneously, the working group is further directed to use good engineering judgement is developing an approach with the smallest reasonable "footprint" to achieve intra-agent communication. As a consequence, if the working group may choose to avoid complete transparency, if, at its discretion, this proves too costly. In this case, the working group should document its decision for this engineering trade-off. Although the working group will solicit existing specifications and experience in this area, it will produce a vendor-neutral technology specification. Goals and Milestones: Dec 95 First meeting at Dallas IETF. Dec 95 Post first Internet-Draft(s) for SNMP Agent Extensibility. Jan 96 Post revised Internet-Draft(s) on SNMP Agent Extensibility. Mar 96 Meet at LA IETF. Apr 96 Post final Internet-Drafts. May 96 Submit final set of Internet-Drafts on SNMP Agent Extensibility to IESG for consideration as a Proposed Standard. ------- =_aaaaaaaaaa1 Content-Type: message/rfc822 To: agentx@fv.com Subject: preparations for next month Reply-To: agentx@fv.com MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <17347.815897007.1@dbc.mtview.ca.us> Date: Wed, 08 Nov 1995 22:03:27 -0800 Message-ID: <17348.815897007@dbc.mtview.ca.us> From: Marshall Rose welcome to the agentx@fv.com working group. we have two slots (one wednesday, one friday) allocated to us; however, for the kickoff meeting, i feel a third slot may be necessary. more details on that as they develop...once i know the number of slots, i can circulate the agenda. for right now, i would like readers of this list to do some homework in preparation for the meeting. at the meeting, i am going to ask three questions of the group, and solicit answers in the form of prepared presentations and subsequent discussion. the questions are: - what are the issues which are driving agent extensibility? - what technologies exist which address these issues? - what are the real-world experiences with these technologies? note that i have phrased these questions to very carefully avoid any specific outcome. for example, everyone might agree on the answers given to the first question, but then someone might argue that packet-based multiplexing (proxy), instead of method-based multiplexing (agentx), is an acceptable answer to the second question. for the third question, i am interested in hearing answers that talk about both succeses and failures. for example, someone might discuss the problems which occur when two sub-agents need to talk with each other, and how they feel that this can be solved by MIB, but not protocol, design. please take some time to think these questions through before preparing your presentations. however, feel free to ask questions now in terms of clarifications, etc. /mtr ps: if you can not attend the meeting, and want to make a presentation, you can e-mail postscript by november 30 and i will present your materials, in a neutral fashion to the group. ------- =_aaaaaaaaaa1-- ------- =_aaaaaaaaaa0--   Delivery-Date: Wed, 15 Nov 1995 19:37:48 -0500 Received: (from daemon@localhost) by fv.com (8.7.1/8.7.1) id TAA06655 for X-agentx-local; Wed, 15 Nov 1995 19:37:47 -0500 (EST) Received: from emory.mathcs.emory.edu (emory.mathcs.emory.edu [128.140.2.1]) by fv.com (8.7.1/8.7.1) with SMTP id TAA06649 for ; Wed, 15 Nov 1995 19:37:46 -0500 (EST) Received: from bir.UUCP by emory.mathcs.emory.edu (5.65/Emory_mathcs.4.0.16) via UUCP id AA22466 ; Wed, 15 Nov 95 19:37:42 -0500 Received: by bir.mlksys.atl.ga.us (uA-1.6v2); Wed, 15 Nov 95 19:22:49 EST From: mlk@mlksys.atl.ga.us (Michael L. Kornegay) To: agentx@fv.com Subject: Re: agentx Date: Wed, 15 Nov 95 19:22:49 EST Cc: snmpv2@tis.com Reply-To: mlk@mlksys.atl.ga.us Message-Id: <0D15DDF1.cvrk8t@bir.mlksys.atl.ga.us> X-Mailer: uAccess - Macintosh Release: 1.6v2 In Regards to your letter <17994.816473374@dbc.mtview.ca.us>: > The working group is explicitly directed to develop a solution which is > adequate to achieve transparency with respect to whether a SNMP request > is processed by a master-agent and/or one or more sub-agents; > simultaneously, the working group is further directed to use good I hope this means that row instances in conceptual tables will be able to be instrumented by different and multiple sub-agents? ___________________ Michael L. Kornegay Internet: mlk@mlksys.atl.ga.us UUCP: mlk@bir.uucp or bir!mlk   Delivery-Date: Wed, 15 Nov 1995 20:06:32 -0500 Received: (from daemon@localhost) by fv.com (8.7.1/8.7.1) id UAA09755 for X-agentx-local; Wed, 15 Nov 1995 20:06:31 -0500 (EST) Received: from s.wipinfo.soft.net (s.wipinfo.soft.net [164.164.6.6]) by fv.com (8.7.1/8.7.1) with SMTP id UAA09730 for ; Wed, 15 Nov 1995 20:06:25 -0500 (EST) Received: by s.wipinfo.soft.net (4.1/SMI-4.1) id AA24763; Thu, 16 Nov 95 06:39:59 IST From: agentx@fv.com Received: from rishabh.wipinfo.soft.net by rolex.rnd.blr (4.1/SMI-4.1) id AA08942; Thu, 16 Nov 95 06:39:42+050 Received: from fv.com by rishabh.wipinfo.soft.net; Thu, 16 Nov 95 06:36 IST Received: from fv.com by tagore.wipinfo.soft.net; Thu, 16 Nov 1995 06:38 IST Received: from fv.com by rishabh.wipinfo.soft.net; Thu, 16 Nov 95 06:36 IST Received: from wipinfo.soft.net (infotech) by rolex.rnd.blr (4.1/SMI-4.1) id AA08939; Thu, 16 Nov 95 06:39:33+050 Received: by wipinfo.soft.net (4.1/SMI-4.1) id AA00717; Thu, 16 Nov 95 06:39:02 IST Received: from neptune.tis.com by neptune.TIS.COM id aa23586; 15 Nov 95 17:17 EST Received: from relay.tis.com by neptune.TIS.COM id aa23582; 15 Nov 95 17:09 EST Received: from tsunami.dbc.mtview.ca.us(204.250.93.202) by relay.tis.com via smap (g3.0.1) id xma016645; Wed, 15 Nov 95 16:48:10 -0500 Received: from localhost (localhost [127.0.0.1]) by tsunami.dbc.mtview.ca.us (8.6.10/8.6.10) with ESMTP id OAA17998; Wed, 15 Nov 1995 14:09:42 -0800 Message-Id: <9511160636.AA25879@rishabh.wipinfo.soft.net> >From: fv.com!agentx To: rishabh!fv.com!agentx Report-Version: 2 Date: Thu, 16 Nov 95 01:08:12 GMT Original-Date: Wed, 15 Nov 1995 14:09:34 -0800 Original-Subject: Re: agentx Not-Delivered-To: tagore!rama due to 11 Transfer Failure ORIGINAL MESSAGE ATTACHED (rmail: Error # 22 ':84:Surrogate command failed', rc = 0) ======= Surrogate command ======= Content-Type: text ==== stdout & stderr unavailable === End-of-Header: Content-Type: text Content-Length: 7637 >From agentx Wed Nov 15 14:09:34 0800 1995 remote from fv.com From: agentx@fv.com Received: from fv.com by rishabh.wipinfo.soft.net; Thu, 16 Nov 95 06:36 IST Received: from wipinfo.soft.net (infotech) by rolex.rnd.blr (4.1/SMI-4.1) id AA08939; Thu, 16 Nov 95 06:39:33+050 Received: by wipinfo.soft.net (4.1/SMI-4.1) id AA00717; Thu, 16 Nov 95 06:39:02 IST Received: from neptune.tis.com by neptune.TIS.COM id aa23586; 15 Nov 95 17:17 EST Received: from relay.tis.com by neptune.TIS.COM id aa23582; 15 Nov 95 17:09 EST Received: from tsunami.dbc.mtview.ca.us(204.250.93.202) by relay.tis.com via smap (g3.0.1) id xma016645; Wed, 15 Nov 95 16:48:10 -0500 Received: from localhost (localhost [127.0.0.1]) by tsunami.dbc.mtview.ca.us (8.6.10/8.6.10) with ESMTP id OAA17998; Wed, 15 Nov 1995 14:09:42 -0800 To: baynetworks.com!iraab (Ilan Raab) Reply-To: agentx@fv.com Cc: TIS.COM!snmpv2 Subject: Re: agentx In-Reply-To: Your message of "Wed, 15 Nov 1995 09:34:30 PST." <9511151734.AA12984@scooby.engwest> Mime-Version: 1.0 Content-Id: <17986.816473340.0@dbc.mtview.ca.us> Date: Wed, 15 Nov 1995 14:09:34 -0800 Message-Id: <17994.816473374@dbc.mtview.ca.us> >From: dbc.mtview.ca.us!mrose (Marshall Rose) Content-Type: multipart/mixed; boundary="----- =_aaaaaaaaaa0" Content-Length: 6325 ------- =_aaaaaaaaaa0 Content-Type: text/plain; charset="us-ascii" Content-ID: <17986.816473340.1@dbc.mtview.ca.us> > What is this new group? Can you please give me a brief synopsis? I enclose two messages. The first is the wg activation notice, which contains the charter. The second is the kick-off message which was sent. Further discussion should occur on the agentx@fv.com mailing list. ------- =_aaaaaaaaaa0 Content-Type: multipart/digest; boundary="----- =_aaaaaaaaaa1" Content-ID: <17986.816473340.2@dbc.mtview.ca.us> ------- =_aaaaaaaaaa1 Content-Type: message/rfc822 Newsgroups: internet.ietf Received: from yukinojo.fv.com (yukinojo.fv.com [204.250.90.3]) by tsunami.fv.com (8.6.10/8.6.10) with ESMTP id HAA00925 for ; Fri, 3 Nov 1995 07:56:00 -0800 Received: from IETF.nri.reston.VA.US (ietf.cnri.reston.va.us [132.151.1.35]) by yukinojo.fv.com (8.7.1/8.7.1) with SMTP id HAA09291 for ; Fri, 3 Nov 1995 07:56:24 -0800 (PST) Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11922; 3 Nov 95 9:19 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa10192; 3 Nov 95 7:57 EST Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa07873; 3 Nov 95 7:57 EST Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa10186; 3 Nov 95 7:57 EST To: IETF-Announce:; Subject: WG Action:SNMP Agent Extensibility (agentx) Date: Fri, 03 Nov 95 07:57:03 -0500 Sender: ietf-announce-request@IETF.CNRI.Reston.VA.US From: Steve Coya Message-ID: <9511030757.aa10186@IETF.CNRI.Reston.VA.US> A new working group has been formed in the Network Management Area of the IETF. For more information, please contact the working group chair or the Area Director. SNMP Agent Extensibility (agentx) --------------------------------- Chair(s): Marshall T. Rose Network Management Area Director(s): Deirdre Kostick Mailing lists: General Discussion:agentx@fv.com To Subscribe: agentx-request@fv.com In Body: Subject: subscribe Archive: ftp://fv.com/pub/mrose/agentx Description of Working Group: The goal of this working group is to define standards-track technology for SNMP Agent extensibility. The resulting technology specification will allow independently developed sub-agents to communicate with a master-agent running on an Internet device. The technology specification will consist of: o (mandatory) a platform-independent protocol which supports intra-agent communication within a device or local area network; o (optional) a MIB module, which, when implemented by a master-agent, allows an SNMP-based management application to monitor and control the intra-agent communication service; and, o (optional) a programmatic interface to the services offered by that protocol. The working group is explicitly directed to develop a solution which is adequate to achieve transparency with respect to whether a SNMP request is processed by a master-agent and/or one or more sub-agents; simultaneously, the working group is further directed to use good engineering judgement is developing an approach with the smallest reasonable "footprint" to achieve intra-agent communication. As a consequence, if the working group may choose to avoid complete transparency, if, at its discretion, this proves too costly. In this case, the working group should document its decision for this engineering trade-off. Although the working group will solicit existing specifications and experience in this area, it will produce a vendor-neutral technology specification. Goals and Milestones: Dec 95 First meeting at Dallas IETF. Dec 95 Post first Internet-Draft(s) for SNMP Agent Extensibility. Jan 96 Post revised Internet-Draft(s) on SNMP Agent Extensibility. Mar 96 Meet at LA IETF. Apr 96 Post final Internet-Drafts. May 96 Submit final set of Internet-Drafts on SNMP Agent Extensibility to IESG for consideration as a Proposed Standard. ------- =_aaaaaaaaaa1 Content-Type: message/rfc822 To: agentx@fv.com Subject: preparations for next month Reply-To: agentx@fv.com MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <17347.815897007.1@dbc.mtview.ca.us> Date: Wed, 08 Nov 1995 22:03:27 -0800 Message-ID: <17348.815897007@dbc.mtview.ca.us> From: Marshall Rose welcome to the agentx@fv.com working group. we have two slots (one wednesday, one friday) allocated to us; however, for the kickoff meeting, i feel a third slot may be necessary. more details on that as they develop...once i know the number of slots, i can circulate the agenda. for right now, i would like readers of this list to do some homework in preparation for the meeting. at the meeting, i am going to ask three questions of the group, and solicit answers in the form of prepared presentations and subsequent discussion. the questions are: - what are the issues which are driving agent extensibility? - what technologies exist which address these issues? - what are the real-world experiences with these technologies? note that i have phrased these questions to very carefully avoid any specific outcome. for example, everyone might agree on the answers given to the first question, but then someone might argue that packet-based multiplexing (proxy), instead of method-based multiplexing (agentx), is an acceptable answer to the second question. for the third question, i am interested in hearing answers that talk about both succeses and failures. for example, someone might discuss the problems which occur when two sub-agents need to talk with each other, and how they feel that this can be solved by MIB, but not protocol, design. please take some time to think these questions through before preparing your presentations. however, feel free to ask questions now in terms of clarifications, etc. /mtr ps: if you can not attend the meeting, and want to make a presentation, you can e-mail postscript by november 30 and i will present your materials, in a neutral fashion to the group. ------- =_aaaaaaaaaa1-- ------- =_aaaaaaaaaa0--   Delivery-Date: Thu, 16 Nov 1995 12:08:02 -0500 Received: (from daemon@localhost) by fv.com (8.7.1/8.7.1) id MAA05992 for X-agentx-local; Thu, 16 Nov 1995 12:08:02 -0500 (EST) Received: from lobster.wellfleet.com (lobster.wellfleet.com [192.32.253.3]) by fv.com (8.7.1/8.7.1) with SMTP id MAA05972 for ; Thu, 16 Nov 1995 12:08:00 -0500 (EST) Received: from pobox.BayNetworks.com (pobox.wellfleet.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA12533; Thu, 16 Nov 95 12:06:54 EST Received: from torino.engeast by pobox.BayNetworks.com (4.1/SMI-4.1) id AA08577; Thu, 16 Nov 95 12:07:57 EST Date: Thu, 16 Nov 95 12:07:57 EST From: jmadsen@BayNetworks.com (Jonathon Madsen) Message-Id: <9511161707.AA08577@pobox.BayNetworks.com> To: agentx@fv.com Subject: Dallas ietf I was wondering if someone could give me information concerning the dates and times of this working groups meetings at the Dallas ietf. thanks, jon   Delivery-Date: Thu, 16 Nov 1995 15:17:28 -0500 Received: (from daemon@localhost) by fv.com (8.7.1/8.7.1) id PAA10912 for X-agentx-local; Thu, 16 Nov 1995 15:17:27 -0500 (EST) Received: from osi.com (k9.osi.com [199.99.184.2]) by fv.com (8.7.1/8.7.1) with SMTP id PAA10896 for ; Thu, 16 Nov 1995 15:17:22 -0500 (EST) Received: from osi (osi.osi.com) by osi.com (4.1/SMI-4.1) id AA16283; Thu, 16 Nov 95 12:17:18 PST Received: from noteserv.osi.COM.osi.COM by osi (5.x/SMI-SVR4) id AA14617; Thu, 16 Nov 1995 12:17:11 -0800 Received: by noteserv.osi.COM (4.1/SMI-4.1) id AA22915; Thu, 16 Nov 95 12:00:55 PST Message-Id: <9511162000.AA22915@noteserv.osi.COM> Received: from OSI with "Lotus Notes Mail Gateway for SMTP" id 886D861367FA4ACB88256276006D60EE; Thu, 16 Nov 95 20:00:54 To: agentx Cc: snmpv2 From: John W Riley/OSI Date: 16 Nov 95 11:44:15 EDT Subject: Re: agentx Mime-Version: 1.0 Content-Type: Text/Plain In Regards to your letter <17994.816473374@dbc.mtview.ca.us>: > The working group is explicitly directed to develop a solution which is > adequate to achieve transparency with respect to whether a SNMP request > is processed by a master-agent and/or one or more sub-agents; > simultaneously, the working group is further directed to use good I hope this means that row instances in conceptual tables will be able to be instrumented by different and multiple sub-agents? ___________________ Michael L. Kornegay Internet: mlk@mlksys.atl.ga.us UUCP: mlk@bir.uucp or bir!mlk   Delivery-Date: Thu, 16 Nov 1995 15:17:29 -0500 Received: (from daemon@localhost) by fv.com (8.7.1/8.7.1) id PAA10914 for X-agentx-local; Thu, 16 Nov 1995 15:17:27 -0500 (EST) Received: from osi.com (k9.osi.com [199.99.184.2]) by fv.com (8.7.1/8.7.1) with SMTP id PAA10898 for ; Thu, 16 Nov 1995 15:17:22 -0500 (EST) Received: from osi (osi.osi.com) by osi.com (4.1/SMI-4.1) id AA16277; Thu, 16 Nov 95 12:17:12 PST Received: from noteserv.osi.COM.osi.COM by osi (5.x/SMI-SVR4) id AA14585; Thu, 16 Nov 1995 12:17:05 -0800 Received: by noteserv.osi.COM (4.1/SMI-4.1) id AA22903; Thu, 16 Nov 95 12:00:52 PST Message-Id: <9511162000.AA22903@noteserv.osi.COM> Received: from OSI with "Lotus Notes Mail Gateway for SMTP" id B80395B4AD833FB488256276006D60EF; Thu, 16 Nov 95 20:00:52 To: agentx Cc: snmpv2 From: John W Riley/OSI Date: 16 Nov 95 11:44:17 EDT Subject: Re: agentx Mime-Version: 1.0 Content-Type: Text/Plain In Regards to your letter <17994.816473374@dbc.mtview.ca.us>: > The working group is explicitly directed to develop a solution which is > adequate to achieve transparency with respect to whether a SNMP request > is processed by a master-agent and/or one or more sub-agents; > simultaneously, the working group is further directed to use good I hope this means that row instances in conceptual tables will be able to be instrumented by different and multiple sub-agents? ___________________ Michael L. Kornegay Internet: mlk@mlksys.atl.ga.us UUCP: mlk@bir.uucp or bir!mlk   Delivery-Date: Thu, 16 Nov 1995 16:17:35 -0500 Received: (from daemon@localhost) by fv.com (8.7.1/8.7.1) id QAA22728 for X-agentx-local; Thu, 16 Nov 1995 16:17:34 -0500 (EST) Received: from osi.com (k9.osi.com [199.99.184.2]) by fv.com (8.7.1/8.7.1) with SMTP id QAA22719 for ; Thu, 16 Nov 1995 16:17:31 -0500 (EST) Received: from osi (osi.osi.com) by osi.com (4.1/SMI-4.1) id AA17473; Thu, 16 Nov 95 13:17:27 PST Received: from noteserv.osi.COM.osi.COM by osi (5.x/SMI-SVR4) id AA18350; Thu, 16 Nov 1995 13:17:20 -0800 Received: by noteserv.osi.COM (4.1/SMI-4.1) id AA03060; Thu, 16 Nov 95 12:44:06 PST Message-Id: <9511162044.AA03060@noteserv.osi.COM> Received: from OSI with "Lotus Notes Mail Gateway for SMTP" id 785CAD259463E46888256276006D61C6; Thu, 16 Nov 95 20:44:06 To: agentx Cc: snmpv2 From: John W Riley/OSI Date: 16 Nov 95 11:44:17 EDT Subject: Re: agentx Mime-Version: 1.0 Content-Type: Text/Plain In Regards to your letter <17994.816473374@dbc.mtview.ca.us>: > The working group is explicitly directed to develop a solution which is > adequate to achieve transparency with respect to whether a SNMP request > is processed by a master-agent and/or one or more sub-agents; > simultaneously, the working group is further directed to use good I hope this means that row instances in conceptual tables will be able to be instrumented by different and multiple sub-agents? ___________________ Michael L. Kornegay Internet: mlk@mlksys.atl.ga.us UUCP: mlk@bir.uucp or bir!mlk   Delivery-Date: Thu, 16 Nov 1995 18:05:45 -0500 Received: (from daemon@localhost) by fv.com (8.7.1/8.7.1) id SAA13979 for X-agentx-local; Thu, 16 Nov 1995 18:05:45 -0500 (EST) Received: from home.merit.edu (home.merit.edu [198.108.60.42]) by fv.com (8.7.1/8.7.1) with ESMTP id SAA13970 for ; Thu, 16 Nov 1995 18:05:43 -0500 (EST) Received: (from wbn@localhost) by home.merit.edu (8.7.1/merit-2.0) id SAA26192; Thu, 16 Nov 1995 18:05:41 -0500 (EST) Date: Thu, 16 Nov 1995 18:05:40 -0500 (EST) From: "William B. Norton" To: agentx@fv.com Subject: Re: agentx In-Reply-To: <17994.816473374@dbc.mtview.ca.us> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Marshall - I'm glad this WG is starting up and I absolutely agree this needs to be standardized for the good of the Internet in general as well as several of my own projects (MBone Mgmt, Routing Arbiter Mgmt). However, your past statements ("No IETF standardization work in this area while I'm NMAD") suggest you do not share these views. In fact, you forced us to another hotel to even discuss agent extenisbility amongst ourselves! So Mr. Clinton, have you changed your mind? (Sorry, being Republican I couldn't resist ;-)) Bill ------------------------------------------------------------------------- William B. Norton Merit Network Inc. e-mail: wbn@merit.edu phone: (313) 936-2656 WWW: http://home.merit.edu/~wbn On Wed, 15 Nov 1995, Marshall Rose wrote: > > ------- =_aaaaaaaaaa0 > Content-Type: text/plain; charset="us-ascii" > Content-ID: <17986.816473340.1@dbc.mtview.ca.us> > > > What is this new group? Can you please give me a brief synopsis? > > I enclose two messages. The first is the wg activation notice, which > contains the charter. The second is the kick-off message which was > sent. Further discussion should occur on the > > agentx@fv.com > > mailing list. > > > ------- =_aaaaaaaaaa0 > Content-Type: multipart/digest; boundary="----- =_aaaaaaaaaa1" > Content-ID: <17986.816473340.2@dbc.mtview.ca.us> > > ------- =_aaaaaaaaaa1 > Content-Type: message/rfc822 > > Newsgroups: internet.ietf > Received: from yukinojo.fv.com (yukinojo.fv.com [204.250.90.3]) by tsunami.fv.com (8.6.10/8.6.10) with ESMTP id HAA00925 for ; Fri, 3 Nov 1995 07:56:00 -0800 > Received: from IETF.nri.reston.VA.US (ietf.cnri.reston.va.us [132.151.1.35]) by yukinojo.fv.com (8.7.1/8.7.1) with SMTP id HAA09291 for ; Fri, 3 Nov 1995 07:56:24 -0800 (PST) > Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11922; > 3 Nov 95 9:19 EST > Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa10192; > 3 Nov 95 7:57 EST > Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa07873; > 3 Nov 95 7:57 EST > Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa10186; > 3 Nov 95 7:57 EST > To: IETF-Announce:; > Subject: WG Action:SNMP Agent Extensibility (agentx) > Date: Fri, 03 Nov 95 07:57:03 -0500 > Sender: ietf-announce-request@IETF.CNRI.Reston.VA.US > From: Steve Coya > Message-ID: <9511030757.aa10186@IETF.CNRI.Reston.VA.US> > > A new working group has been formed in the Network Management Area of > the IETF. For more information, please contact the working group > chair or the Area Director. > > SNMP Agent Extensibility (agentx) > --------------------------------- > > Chair(s): > Marshall T. Rose > > Network Management Area Director(s): > Deirdre Kostick > > Mailing lists: > General Discussion:agentx@fv.com > To Subscribe: agentx-request@fv.com > In Body: Subject: subscribe > Archive: ftp://fv.com/pub/mrose/agentx > > Description of Working Group: > > The goal of this working group is to define standards-track technology > for SNMP Agent extensibility. The resulting technology specification > will allow independently developed sub-agents to communicate with a > master-agent running on an Internet device. > > The technology specification will consist of: > > o (mandatory) a platform-independent protocol which supports > intra-agent communication within a device or local area network; > > o (optional) a MIB module, which, when implemented by a master-agent, > allows an SNMP-based management application to monitor and control > the intra-agent communication service; and, > > o (optional) a programmatic interface to the services offered by > that protocol. > > The working group is explicitly directed to develop a solution which is > adequate to achieve transparency with respect to whether a SNMP request > is processed by a master-agent and/or one or more sub-agents; > simultaneously, the working group is further directed to use good > engineering judgement is developing an approach with the smallest > reasonable "footprint" to achieve intra-agent communication. As a > consequence, if the working group may choose to avoid complete > transparency, if, at its discretion, this proves too costly. In this > case, the working group should document its decision for this > engineering trade-off. > > Although the working group will solicit existing specifications and > experience in this area, it will produce a vendor-neutral technology > specification. > > Goals and Milestones: > > Dec 95 First meeting at Dallas IETF. > > Dec 95 Post first Internet-Draft(s) for SNMP Agent Extensibility. > > Jan 96 Post revised Internet-Draft(s) on SNMP Agent Extensibility. > > Mar 96 Meet at LA IETF. > > Apr 96 Post final Internet-Drafts. > > May 96 Submit final set of Internet-Drafts on SNMP Agent Extensibility to > IESG for consideration as a Proposed Standard. > > > > > ------- =_aaaaaaaaaa1 > Content-Type: message/rfc822 > > To: agentx@fv.com > Subject: preparations for next month > Reply-To: agentx@fv.com > MIME-Version: 1.0 > Content-Type: text/plain; charset="us-ascii" > Content-ID: <17347.815897007.1@dbc.mtview.ca.us> > Date: Wed, 08 Nov 1995 22:03:27 -0800 > Message-ID: <17348.815897007@dbc.mtview.ca.us> > From: Marshall Rose > > welcome to the agentx@fv.com working group. > > we have two slots (one wednesday, one friday) allocated to us; however, for > the kickoff meeting, i feel a third slot may be necessary. more details > on that as they develop...once i know the number of slots, i can circulate the > agenda. > > for right now, i would like readers of this list to do some homework in > preparation for the meeting. at the meeting, i am going to ask three > questions of the group, and solicit answers in the form of prepared > presentations and subsequent discussion. the questions are: > > - what are the issues which are driving agent extensibility? > - what technologies exist which address these issues? > - what are the real-world experiences with these technologies? > > note that i have phrased these questions to very carefully avoid any > specific outcome. for example, everyone might agree on the answers > given to the first question, but then someone might argue that > packet-based multiplexing (proxy), instead of method-based > multiplexing (agentx), is an acceptable answer to the second question. > > for the third question, i am interested in hearing answers that talk > about both succeses and failures. for example, someone might discuss > the problems which occur when two sub-agents need to talk with each > other, and how they feel that this can be solved by MIB, but not > protocol, design. > > please take some time to think these questions through before preparing > your presentations. however, feel free to ask questions now in terms of > clarifications, etc. > > /mtr > > ps: if you can not attend the meeting, and want to make a presentation, > you can e-mail postscript by november 30 and i will present your > materials, in a neutral fashion to the group. > > ------- =_aaaaaaaaaa1-- > > ------- =_aaaaaaaaaa0-- >   Delivery-Date: Thu, 16 Nov 1995 18:31:34 -0500 Received: (from daemon@localhost) by fv.com (8.7.1/8.7.1) id SAA19976 for X-agentx-local; Thu, 16 Nov 1995 18:31:33 -0500 (EST) Received: from tsunami.dbc.mtview.ca.us (tsunami.dbc.mtview.ca.us [204.250.93.202]) by fv.com (8.7.1/8.7.1) with ESMTP id SAA19967 for ; Thu, 16 Nov 1995 18:31:32 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by tsunami.dbc.mtview.ca.us (8.6.10/8.6.10) with ESMTP id PAA03570; Thu, 16 Nov 1995 15:29:57 -0800 To: "William B. Norton" reply-to: agentx@fv.com cc: agentx@fv.com Subject: Re: agentx In-reply-to: Your message of "Thu, 16 Nov 1995 18:05:40 EST." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <3566.816564596.1@dbc.mtview.ca.us> Date: Thu, 16 Nov 1995 15:29:56 -0800 Message-ID: <3568.816564596@dbc.mtview.ca.us> From: Marshall Rose > I'm glad this WG is starting up and I absolutely agree this needs to be > standardized for the good of the Internet in general as well as several > of my own projects (MBone Mgmt, Routing Arbiter Mgmt). good. > However, your past statements ("No IETF standardization work in this area > while I'm NMAD") suggest you do not share these views. In fact, you forced > us to another hotel to even discuss agent extenisbility amongst ourselves! perhaps there is now "room at the inn" (this is an inside joke to people who remember bob natale's comment.) more seriously, perhaps i feel that the industry has matured enough to where a standard in this area is appropriate. however, you will note that the charter is very carefully written so as to allow multiple completion points for the working group...i asked for this on purpose. it may be that there are three successive things that we need agreement on in the long-term, but we find that it is practical to agree on only one or two of them in the short-term. in other words, we can probably agree on the intra-agent protocol, but harder things may not be doable at the present time. i don't know, we'll have to see what people bring to the table. > So Mr. Clinton, have you changed your mind? > (Sorry, being Republican I couldn't resist ;-)) i'm registered as a republican, though a libertarian at heart... however, a more clinton-esque response would be "well, i'm no longer AD now, am I?" /mtr   Delivery-Date: Thu, 16 Nov 1995 20:14:50 -0500 Received: (from daemon@localhost) by fv.com (8.7.1/8.7.1) id UAA11138 for X-agentx-local; Thu, 16 Nov 1995 20:14:49 -0500 (EST) Received: from osi.com (k9.osi.com [199.99.184.2]) by fv.com (8.7.1/8.7.1) with SMTP id UAA11114 for ; Thu, 16 Nov 1995 20:14:43 -0500 (EST) Received: from osi (osi.osi.com) by osi.com (4.1/SMI-4.1) id AA21694; Thu, 16 Nov 95 17:14:37 PST Received: from noteserv.osi.COM.osi.COM by osi (5.x/SMI-SVR4) id AA02620; Thu, 16 Nov 1995 17:14:31 -0800 Received: by noteserv.osi.COM (4.1/SMI-4.1) id AA03072; Thu, 16 Nov 95 12:44:09 PST Message-Id: <9511162044.AA03072@noteserv.osi.COM> Received: from OSI with "Lotus Notes Mail Gateway for SMTP" id DCE7A33DBCC9AA3788256276006D61C5; Thu, 16 Nov 95 20:44:09 To: agentx Cc: snmpv2 From: John W Riley/OSI Date: 16 Nov 95 11:44:15 EDT Subject: Re: agentx Mime-Version: 1.0 Content-Type: Text/Plain In Regards to your letter <17994.816473374@dbc.mtview.ca.us>: > The working group is explicitly directed to develop a solution which is > adequate to achieve transparency with respect to whether a SNMP request > is processed by a master-agent and/or one or more sub-agents; > simultaneously, the working group is further directed to use good I hope this means that row instances in conceptual tables will be able to be instrumented by different and multiple sub-agents? ___________________ Michael L. Kornegay Internet: mlk@mlksys.atl.ga.us UUCP: mlk@bir.uucp or bir!mlk   Delivery-Date: Fri, 17 Nov 1995 08:46:57 -0500 Received: (from daemon@localhost) by fv.com (8.7.1/8.7.1) id IAA27118 for X-agentx-local; Fri, 17 Nov 1995 08:46:57 -0500 (EST) Received: from tsunami.dbc.mtview.ca.us (tsunami.dbc.mtview.ca.us [204.250.93.202]) by fv.com (8.7.1/8.7.1) with ESMTP id IAA27113 for ; Fri, 17 Nov 1995 08:46:55 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by tsunami.dbc.mtview.ca.us (8.6.10/8.6.10) with ESMTP id FAA12629; Fri, 17 Nov 1995 05:45:24 -0800 To: jmadsen@baynetworks.com (Jonathon Madsen) reply-to: agentx@fv.com cc: agentx@fv.com Subject: Re: Dallas ietf In-reply-to: Your message of "Thu, 16 Nov 1995 12:07:57 EST." <9511161707.AA08577@pobox.BayNetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <12623.816615919.1@dbc.mtview.ca.us> Date: Fri, 17 Nov 1995 05:45:19 -0800 Message-ID: <12625.816615919@dbc.mtview.ca.us> From: Marshall Rose > I was wondering if someone could give me information concerning the dates and > times of this working groups meetings at the Dallas ietf. according to ftp://ds.internic.net/ietf/0mtg-agenda.txt... Wednesday 1300-1500 Friday 0900-1130 the wednesday session conflicts with AToM MIB, the friday session conflicts with IF MIB. /mtr   Delivery-Date: Fri, 17 Nov 1995 13:15:01 -0500 Received: (from daemon@localhost) by fv.com (8.7.1/8.7.1) id NAA14230 for X-agentx-local; Fri, 17 Nov 1995 13:14:58 -0500 (EST) Received: from netcom10.netcom.com (netcom10.netcom.com [192.100.81.120]) by fv.com (8.7.1/8.7.1) with SMTP id NAA14220 for ; Fri, 17 Nov 1995 13:14:56 -0500 (EST) Received: by netcom10.netcom.com (8.6.12/Netcom) id KAA26619; Fri, 17 Nov 1995 10:13:29 -0800 From: sudhir@netcom.com (Sudhir Pendse) Message-Id: <199511171813.KAA26619@netcom10.netcom.com> Subject: Comments To: agentx@fv.com Date: Fri, 17 Nov 1995 10:13:29 -0800 (PST) X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Whatever the reasons for its start, I am certainly glad to see this group started. If we are able to live with a RESONABLE relaxation of the two golden rules 1) "Set as if simultaneous" 2) "sysUpTime.0" not capturing the intermediate reinitialization of counters the goals of this working group would be certainly accomplished. What I am concerned about is "What happens to this working group if the Chair of this working group were to follow his own advise and abstain from participating in IETF activities for one year ?" - sudhir   Delivery-Date: Fri, 17 Nov 1995 13:27:44 -0500 Received: (from daemon@localhost) by fv.com (8.7.1/8.7.1) id NAA16670 for X-agentx-local; Fri, 17 Nov 1995 13:27:43 -0500 (EST) Received: from tsunami.dbc.mtview.ca.us (tsunami.dbc.mtview.ca.us [204.250.93.202]) by fv.com (8.7.1/8.7.1) with ESMTP id NAA16666 for ; Fri, 17 Nov 1995 13:27:42 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by tsunami.dbc.mtview.ca.us (8.6.10/8.6.10) with ESMTP id KAA15586; Fri, 17 Nov 1995 10:26:05 -0800 To: sudhir@netcom.com (Sudhir Pendse) reply-to: agentx@fv.com cc: agentx@fv.com Subject: Re: Comments In-reply-to: Your message of "Fri, 17 Nov 1995 10:13:29 PST." <199511171813.KAA26619@netcom10.netcom.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <15581.816632764.1@dbc.mtview.ca.us> Date: Fri, 17 Nov 1995 10:26:04 -0800 Message-ID: <15583.816632764@dbc.mtview.ca.us> From: Marshall Rose > Whatever the reasons for its start, I am certainly > glad to see this group started. ditto. > If we are able to live with a RESONABLE relaxation > of the two golden rules > > 1) "Set as if simultaneous" > 2) "sysUpTime.0" not capturing the intermediate > reinitialization of counters > > the goals of this working group would be certainly > accomplished. may i ask that you make a presentation at the wg meeting to discuss the issues you see with respect to like-natured properties? an outline of your talk might be: - here's a list of the 10 things that we expect agents to do - here's the one's i think we can relax - here's why they need to be relaxed - here's why we can relax them - here's the cost-benefit etc. if you can not attend, then please consider taking me up on the offer i made earlier to people on this mailing list: > > ps: if you can not attend the meeting, and want to make a presentation, > > you can e-mail postscript by november 30 and i will present your > > materials, in a neutral fashion to the group. > What I am concerned about is > > "What happens to this working group if the Chair of > this working group were to follow his own advise and > abstain from participating in IETF activities for > one year ?" in that event, the AD will appoint another chair... /mtr   Delivery-Date: Fri, 17 Nov 1995 14:07:03 -0500 Received: (from daemon@localhost) by fv.com (8.7.1/8.7.1) id OAA24907 for X-agentx-local; Fri, 17 Nov 1995 14:07:02 -0500 (EST) Received: from epilogue.com (quern.epilogue.com [128.224.1.136]) by fv.com (8.7.1/8.7.1) with SMTP id OAA24900 for ; Fri, 17 Nov 1995 14:07:00 -0500 (EST) Received: from dab.gate.epilogue.com with DMSP Date: Fri, 17 Nov 95 12:06:18 -0700 From: David Bridgham To: agentx@fv.com In-reply-to: <199511171813.KAA26619@netcom10.netcom.com> (sudhir@netcom.com) Subject: Re: Comments Sender: dab@epilogue.com Repository: quern.epilogue.com Originating-client: gate.epilogue.com Message-ID: <9511171406.aa07702@quern.epilogue.com> If we are able to live with a RESONABLE relaxation of the two golden rules 1) "Set as if simultaneous" 2) "sysUpTime.0" not capturing the intermediate reinitialization of counters the goals of this working group would be certainly accomplished. Since a sub-agent protocol can be designed which maintains both, why modify SNMP? Since proxies meet the goals of the working group and don't require any changes to SNMP, why modify SNMP? Dave   Delivery-Date: Fri, 17 Nov 1995 15:16:03 -0500 Received: (from daemon@localhost) by fv.com (8.7.1/8.7.1) id PAA07641 for X-agentx-local; Fri, 17 Nov 1995 15:16:02 -0500 (EST) Received: from pokey.maxm.com (POKEY.MAXM.COM [192.147.28.65]) by fv.com (8.7.1/8.7.1) with SMTP id PAA07613 for ; Fri, 17 Nov 1995 15:15:56 -0500 (EST) Received: from kirk.maxm.com by pokey.maxm.com (AIX 3.2/UCB 5.64/4.03) id AA25173; Fri, 17 Nov 1995 14:54:15 -0600 Received: by kirk.maxm.com (AIX 3.2/UCB 5.64/4.03) id AA83314; Fri, 17 Nov 1995 15:11:27 -0500 Date: Fri, 17 Nov 1995 15:11:27 -0500 From: jwest@maxm.com (Jim West) Message-Id: <9511172011.AA83314@kirk.maxm.com> To: agentx@fv.com Subject: Re: Comments > If we are able to live with a RESONABLE relaxation > of the two golden rules > > 1) "Set as if simultaneous" > 2) "sysUpTime.0" not capturing the intermediate > reinitialization of counters > > the goals of this working group would be certainly > accomplished. I guess you are assuming that the solution needs to involve method-based multiplexing. If we were to us a packet-based multiplexing (i.e. a proxy), we wouldn't need these relaxations. Assuming that the proxy looks something like the Internet Draft dck and mtr posted last January (OK big assumption, but it does provide a starting point for a proxy approach). You have to implement the system and snmp group in each of the subagents (called targets in the ID). I implemented something close to the system proposed in the above ID. A nice feature was that I was able to add what were originally complete SNMP agents as targets just by starting these agents up on different ports. (Thus giving a way to continue to us in 'legacy' SNMP agents with a new agentx technology) Jim West MAXM Systems Corp   Delivery-Date: Sat, 18 Nov 1995 12:12:59 -0500 Received: (from daemon@localhost) by fv.com (8.7.1/8.7.1) id MAA13921 for X-agentx-local; Sat, 18 Nov 1995 12:12:58 -0500 (EST) Received: from netcom7.netcom.com (netcom7.netcom.com [192.100.81.115]) by fv.com (8.7.1/8.7.1) with SMTP id MAA13917 for ; Sat, 18 Nov 1995 12:12:57 -0500 (EST) Received: by netcom7.netcom.com (8.6.12/Netcom) id JAA06268; Sat, 18 Nov 1995 09:11:25 -0800 From: sudhir@netcom.com (Sudhir Pendse) Message-Id: <199511181711.JAA06268@netcom7.netcom.com> Subject: Re: Comments To: dab@epilogue.com (David Bridgham) Date: Sat, 18 Nov 1995 09:11:25 -0800 (PST) Cc: agentx@fv.com In-Reply-To: <9511171406.aa07702@quern.epilogue.com> from "David Bridgham" at Nov 17, 95 12:06:18 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit >> >> >> If we are able to live with a RESONABLE relaxation >> of the two golden rules >> >> 1) "Set as if simultaneous" >> 2) "sysUpTime.0" not capturing the intermediate >> reinitialization of counters >> >> the goals of this working group would be certainly accomplished. > > Since a sub-agent protocol can be designed which maintains both, why > modify SNMP? > > Since proxies meet the goals of the working group and don't require > any changes to SNMP, why modify SNMP? > > Dave One of the implicit assumptions is that existing management applications do NOT need to change to talk with extensible agents. The need for relaxing the requirements comes from this assumption. Maybe it is time to explicitly change this assumption. - sudhir   Delivery-Date: Sat, 18 Nov 1995 21:04:36 -0500 Received: (from daemon@localhost) by fv.com (8.7.1/8.7.1) id VAA17631 for X-agentx-local; Sat, 18 Nov 1995 21:04:34 -0500 (EST) Received: from epilogue.com (quern.epilogue.com [128.224.1.136]) by fv.com (8.7.1/8.7.1) with SMTP id VAA17618 for ; Sat, 18 Nov 1995 21:04:31 -0500 (EST) Received: from dab.gate.epilogue.com with DMSP Date: Sat, 18 Nov 95 19:01:46 -0700 From: David Bridgham To: agentx@fv.com In-reply-to: "sudhir@netcom.com"'s message of Sat, 18 Nov 1995 09:11:25 -0800 (PST) Subject: Re: requirement: management apps don't change Sender: dab@epilogue.com Repository: quern.epilogue.com Originating-client: gate.epilogue.com Message-ID: <9511182103.aa21219@quern.epilogue.com> One of the implicit assumptions is that existing management applications do NOT need to change to talk with extensible agents. At a "requirements" level, how do people feel about this? If it was implicit, perhaps now's the time for explicitness. My opinion is it's not a good requirement but if accepted it should only be after a hard look at the reasons why. First, there's a bit of clarity needed. I can read "managment application" two ways; it could be any program that sends SNMP *-request packets, or it could be a management application which runs on a management station platform. So if this sort of thing becomes one of the requirements of the agentx working group, which is meant should be clearly stated. Some considerations: 1) We're making an addition to an existing protocol (which may or may not undergo significant change both near and not so near term). It's a client/server protocol and the change may effect one end or the other or both. If we elect to restrict changes to one end only, we should have reasons why. 2) Do we limit possible solutions by this? Possibly better solutions? [You all know I think so but there may be others too.] 3) We should start with a system's architect view. We're designing the entire system of network management, not just the agent end. We should add up the effects on all the parts to decide which way to jump. How much complexity if we do it this way vs the other? We can't do that if we've pre-judged the answer. 4) Changes have been proposed to the SNMP protocol to support sub-agents. They are bad changes but if good changes are suggested during this process, this requirement would prohibit them. 5) An SNMP philosophy decision was made a long time ago that complexity should be moved to the manager when possible to keep the agents as simple as possible. I don't see that the reasons for that decision have changed. 6) Finally, we're engineers not just scientists. As nice as it would be to always choose the superior technology, we need to keep issues like installed base in mind. Of what's already fielded, what are we going to have to change and what can run in some backwards compatibility mode? This would seem to argue for the requirement I said I didn't like; it seems to be about the only argument for it. I think if we actually look at the backwards compatibility cost of other solutions, they're not so bad. But we won't know if those solutions are disallowed from the start and we never look. 7) So far, management station capabilties are in their infancy. We've got to learn what information managers really use and what information they want that's not yet available. We've got to learn what to do in general about verbs and errors. We've got to learn how to more easily get semantic information about MIBs into managers. I predict that we're going to be learning and adding for quite a while still. Let's allow the early, primitive managers to fade away if that's what's needed to solve the problem in the best way we can. If we impose this limit on every network management effort, SNMP isn't going anywhere. Dave   Delivery-Date: Sat, 18 Nov 1995 21:04:38 -0500 Received: (from daemon@localhost) by fv.com (8.7.1/8.7.1) id VAA17643 for X-agentx-local; Sat, 18 Nov 1995 21:04:36 -0500 (EST) Received: from epilogue.com (quern.epilogue.com [128.224.1.136]) by fv.com (8.7.1/8.7.1) with SMTP id VAA17632 for ; Sat, 18 Nov 1995 21:04:33 -0500 (EST) Received: from dab.gate.epilogue.com with DMSP Date: Sat, 18 Nov 95 18:10:34 -0700 From: David Bridgham To: sudhir@netcom.com Cc: agentx@fv.com In-reply-to: "sudhir@netcom.com"'s message of Sat, 18 Nov 1995 09:04:58 -0800 (PST) Subject: Re: Changes to SNMP Sender: dab@epilogue.com Repository: quern.epilogue.com Originating-client: gate.epilogue.com Message-ID: <9511182103.aa21217@quern.epilogue.com> From: Sudhir Pendse Date: Sat, 18 Nov 1995 09:04:58 -0800 (PST) One of the implicit assumptions is to have the existing management applications, make NO changes to talk with these extensible agents. Of the three possibilites mentioned so far: 1) relax SNMP requirements for inadequate sub-agent protocol 2) design adequate sub-agent protocol that doesn't require changing SNMP (this isn't _that_ hard, it's just a bad idea) 3) use proxies or other per-packet multiplexing and go home early only number 2 requires not change to existing management applications. Numbers 1 and 3 probably require app changes though if a management station architect was really awake, they might not. The need for relaxing the requirements comes from this assumption. Maybe it is time to explicitly change this assumption. Now I don't accept your requirement, but if such a requirement turns out to be the concensus of the group then changing SNMP should be near the top of the "thou shalt not do" list. This should lead you to prefer #2 above and be pretty dubious about #1 and #3. Dave   Delivery-Date: Sun, 19 Nov 1995 01:03:08 -0500 Received: (from daemon@localhost) by fv.com (8.7.1/8.7.1) id BAA28616 for X-agentx-local; Sun, 19 Nov 1995 01:03:07 -0500 (EST) Received: from tsunami.dbc.mtview.ca.us (tsunami.dbc.mtview.ca.us [204.250.93.202]) by fv.com (8.7.1/8.7.1) with ESMTP id BAA28604 for ; Sun, 19 Nov 1995 01:03:04 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by tsunami.dbc.mtview.ca.us (8.6.10/8.6.10) with ESMTP id WAA05675; Sat, 18 Nov 1995 22:01:34 -0800 To: David Bridgham reply-to: agentx@fv.com cc: agentx@fv.com Subject: Re: requirement: management apps don't change In-reply-to: Your message of "Sat, 18 Nov 1995 19:01:46 MST." <9511182103.aa21219@quern.epilogue.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----- =_aaaaaaaaaa0" Content-ID: <5668.816760889.0@dbc.mtview.ca.us> Date: Sat, 18 Nov 1995 22:01:30 -0800 Message-ID: <5670.816760890@dbc.mtview.ca.us> From: Marshall Rose ------- =_aaaaaaaaaa0 Content-Type: text/plain; charset="us-ascii" Content-ID: <5668.816760889.1@dbc.mtview.ca.us> david - this is precisely the kind of analysis and discussion that we need to consider. regardless about how differences in one's architectural and engineering perspectives, i hope we can all agree that issues of this sort are kind that must be addressed. i trust you will be able to attend the meeting and make a presentation! /mtr ------- =_aaaaaaaaaa0 Content-Type: message/rfc822 Content-Description: original message Newsgroups: internet.ietf.agentx Received: from fv.com (fv.com [199.100.120.3]) by tsunami.dbc.mtview.ca.us (8.6.10/8.6.10) with ESMTP id SAA03620 for ; Sat, 18 Nov 1995 18:06:51 -0800 Resent-From: agentx-owner@fv.com Received: from localhost (localhost [127.0.0.1]) by fv.com (8.7.1/8.7.1) with ESMTP id VAA17647 for ; Sat, 18 Nov 1995 21:04:36 -0500 (EST) Comment: Posted to the agentx Mailing List To unsubscribe, send mail to agentx-request@fv.com with "unsubscribe" in the Subject Resent-Date: Sat, 18 Nov 1995 21:04:36 -0500 Resent-Message-ID: <17639.816746676.1@fv.com> Message-ID: <9511182103.aa21219@quern.epilogue.com> X-Suppressed-Originating-client: gate.epilogue.com X-Suppressed-Repository: quern.epilogue.com X-Suppressed-Sender: dab@epilogue.com Subject: Re: requirement: management apps don't change X-Suppressed-In-reply-to: "sudhir@netcom.com"'s message of Sat, 18 Nov 1995 09:11:25 -0800 (PST) To: agentx@fv.com From: David Bridgham Date: Sat, 18 Nov 95 19:01:46 -0700 Received: from dab.gate.epilogue.com with DMSP Received: from epilogue.com (quern.epilogue.com [128.224.1.136]) by fv.com (8.7.1/8.7.1) with SMTP id VAA17618 for ; Sat, 18 Nov 1995 21:04:31 -0500 (EST) Received: (from daemon@localhost) by fv.com (8.7.1/8.7.1) id VAA17631 for X-agentx-local; Sat, 18 Nov 1995 21:04:34 -0500 (EST) One of the implicit assumptions is that existing management applications do NOT need to change to talk with extensible agents. At a "requirements" level, how do people feel about this? If it was implicit, perhaps now's the time for explicitness. My opinion is it's not a good requirement but if accepted it should only be after a hard look at the reasons why. First, there's a bit of clarity needed. I can read "managment application" two ways; it could be any program that sends SNMP *-request packets, or it could be a management application which runs on a management station platform. So if this sort of thing becomes one of the requirements of the agentx working group, which is meant should be clearly stated. Some considerations: 1) We're making an addition to an existing protocol (which may or may not undergo significant change both near and not so near term). It's a client/server protocol and the change may effect one end or the other or both. If we elect to restrict changes to one end only, we should have reasons why. 2) Do we limit possible solutions by this? Possibly better solutions? [You all know I think so but there may be others too.] 3) We should start with a system's architect view. We're designing the entire system of network management, not just the agent end. We should add up the effects on all the parts to decide which way to jump. How much complexity if we do it this way vs the other? We can't do that if we've pre-judged the answer. 4) Changes have been proposed to the SNMP protocol to support sub-agents. They are bad changes but if good changes are suggested during this process, this requirement would prohibit them. 5) An SNMP philosophy decision was made a long time ago that complexity should be moved to the manager when possible to keep the agents as simple as possible. I don't see that the reasons for that decision have changed. 6) Finally, we're engineers not just scientists. As nice as it would be to always choose the superior technology, we need to keep issues like installed base in mind. Of what's already fielded, what are we going to have to change and what can run in some backwards compatibility mode? This would seem to argue for the requirement I said I didn't like; it seems to be about the only argument for it. I think if we actually look at the backwards compatibility cost of other solutions, they're not so bad. But we won't know if those solutions are disallowed from the start and we never look. 7) So far, management station capabilties are in their infancy. We've got to learn what information managers really use and what information they want that's not yet available. We've got to learn what to do in general about verbs and errors. We've got to learn how to more easily get semantic information about MIBs into managers. I predict that we're going to be learning and adding for quite a while still. Let's allow the early, primitive managers to fade away if that's what's needed to solve the problem in the best way we can. If we impose this limit on every network management effort, SNMP isn't going anywhere. Dave ---------------- This e-mail message was sent to all subscribers to the agentx mailing list. To unsubscribe from this mailing list, please send mail to: agentx-request@fv.com with Subject: unsubscribe your.address@your.domain (NOTE: Please do not reply to the this message to unsubscribe. You must send your request to agentx-request@fv.com Thank you.) ------- =_aaaaaaaaaa0--   Delivery-Date: Sun, 19 Nov 1995 03:34:07 -0500 Received: (from daemon@localhost) by fv.com (8.7.1/8.7.1) id DAA25127 for X-agentx-local; Sun, 19 Nov 1995 03:34:06 -0500 (EST) Received: from epilogue.com (quern.epilogue.com [128.224.1.136]) by fv.com (8.7.1/8.7.1) with SMTP id DAA25121 for ; Sun, 19 Nov 1995 03:34:04 -0500 (EST) Received: from dab.gate.epilogue.com with DMSP Date: Sun, 19 Nov 95 0:43:13 -0700 From: David Bridgham To: agentx@fv.com reply-to: agentx@fv.com In-reply-to: <9511182103.aa21219@quern.epilogue.com> (mrose@dbc.mtview.ca.us) Subject: Re: requirement: management apps don't change Sender: dab@epilogue.com Repository: quern.epilogue.com Originating-client: gate.epilogue.com Message-ID: <9511190332.aa22714@quern.epilogue.com> i trust you will be able to attend the meeting and make a presentation! I'd intended on showing up (modulo schedule conflicts), what sort of presentation did you have in mind? Everyone's already heard me talk about how we don't need a new protocol to achieve agent multiplexing. Dave   Delivery-Date: Sun, 19 Nov 1995 09:36:27 -0500 Received: (from daemon@localhost) by fv.com (8.7.1/8.7.1) id JAA03488 for X-agentx-local; Sun, 19 Nov 1995 09:36:26 -0500 (EST) Received: from tsunami.dbc.mtview.ca.us (tsunami.dbc.mtview.ca.us [204.250.93.202]) by fv.com (8.7.1/8.7.1) with ESMTP id JAA03485 for ; Sun, 19 Nov 1995 09:36:24 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by tsunami.dbc.mtview.ca.us (8.6.10/8.6.10) with ESMTP id GAA09936 for ; Sun, 19 Nov 1995 06:34:59 -0800 To: agentx@fv.com Reply-To: agentx@fv.com Subject: Re: requirement: management apps don't change In-reply-to: Your message of "Sun, 19 Nov 1995 00:43:13 MST." <9511190332.aa22714@quern.epilogue.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----- =_aaaaaaaaaa0" Content-ID: <9928.816791669.0@dbc.mtview.ca.us> Date: Sun, 19 Nov 1995 06:34:55 -0800 Message-ID: <9933.816791695@dbc.mtview.ca.us> From: Marshall Rose ------- =_aaaaaaaaaa0 Content-Type: text/plain; charset="us-ascii" Content-ID: <9928.816791669.1@dbc.mtview.ca.us> > i trust you will be able to attend the meeting and make a presentation! > > I'd intended on showing up (modulo schedule conflicts), what sort of > presentation did you have in mind? Everyone's already heard me talk > about how we don't need a new protocol to achieve agent multiplexing. my call for presentations is included below. obviously, not everyone in the room is going to agree with you, but i feel it is important that all the issues are put on the table so we can figure out the best way to proceed. /mtr ------- =_aaaaaaaaaa0 Content-Type: message/rfc822 Content-Description: earlier message To: agentx@fv.com Subject: preparations for next month Reply-To: agentx@fv.com MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <17347.815897007.1@dbc.mtview.ca.us> Date: Wed, 08 Nov 1995 22:03:27 -0800 Message-ID: <17348.815897007@dbc.mtview.ca.us> From: Marshall Rose welcome to the agentx@fv.com working group. we have two slots (one wednesday, one friday) allocated to us; however, for the kickoff meeting, i feel a third slot may be necessary. more details on that as they develop...once i know the number of slots, i can circulate the agenda. for right now, i would like readers of this list to do some homework in preparation for the meeting. at the meeting, i am going to ask three questions of the group, and solicit answers in the form of prepared presentations and subsequent discussion. the questions are: - what are the issues which are driving agent extensibility? - what technologies exist which address these issues? - what are the real-world experiences with these technologies? note that i have phrased these questions to very carefully avoid any specific outcome. for example, everyone might agree on the answers given to the first question, but then someone might argue that packet-based multiplexing (proxy), instead of method-based multiplexing (agentx), is an acceptable answer to the second question. for the third question, i am interested in hearing answers that talk about both succeses and failures. for example, someone might discuss the problems which occur when two sub-agents need to talk with each other, and how they feel that this can be solved by MIB, but not protocol, design. please take some time to think these questions through before preparing your presentations. however, feel free to ask questions now in terms of clarifications, etc. /mtr ps: if you can not attend the meeting, and want to make a presentation, you can e-mail postscript by november 30 and i will present your materials, in a neutral fashion to the group. ------- =_aaaaaaaaaa0--   Delivery-Date: Sun, 19 Nov 1995 11:55:05 -0500 Received: (from daemon@localhost) by fv.com (8.7.1/8.7.1) id LAA23028 for X-agentx-local; Sun, 19 Nov 1995 11:55:03 -0500 (EST) Received: from pokey.maxm.com (POKEY.MAXM.COM [192.147.28.65]) by fv.com (8.7.1/8.7.1) with SMTP id LAA23022 for ; Sun, 19 Nov 1995 11:55:02 -0500 (EST) Received: from kirk.maxm.com by pokey.maxm.com (AIX 3.2/UCB 5.64/4.03) id AA15086; Sun, 19 Nov 1995 11:32:06 -0600 Received: by kirk.maxm.com (AIX 3.2/UCB 5.64/4.03) id AA48340; Sun, 19 Nov 1995 11:49:18 -0500 Date: Sun, 19 Nov 1995 11:49:18 -0500 From: jwest@maxm.com (Jim West) Message-Id: <9511191649.AA48340@kirk.maxm.com> To: agentx@fv.com, sudhir@netcom.com Subject: Re: Comments >From: sudhir@netcom.com (Sudhir Pendse) >One of the implicit assumptions is that existing management >applications do NOT need to change to talk with extensible >agents. > >Maybe it is time to explicitly change this assumption. > I thought one of the implicit assumptions is that we try to isolate complexity in SNMP management entities. Also, considering: - there are many more agents entities deployed than management entities deployed - People tend to upgrade their management stations more often than their agent systems I believe it is time to change this assumption (it was never one of my assumptions). Jim West MAXM Systems Corp.   Delivery-Date: Sun, 19 Nov 1995 22:08:13 -0500 Received: (from daemon@localhost) by fv.com (8.7.1/8.7.1) id WAA06921 for X-agentx-local; Sun, 19 Nov 1995 22:08:12 -0500 (EST) Received: from netcom17.netcom.com (netcom17.netcom.com [192.100.81.130]) by fv.com (8.7.1/8.7.1) with SMTP id WAA06899 for ; Sun, 19 Nov 1995 22:08:08 -0500 (EST) Received: by netcom17.netcom.com (8.6.12/Netcom) id TAA06832; Sun, 19 Nov 1995 19:06:28 -0800 From: sudhir@netcom.com (Sudhir Pendse) Message-Id: <199511200306.TAA06832@netcom17.netcom.com> Subject: Re: Changes to SNMP To: dab@epilogue.com (David Bridgham) Date: Sun, 19 Nov 1995 19:06:28 -0800 (PST) Cc: agentx@fv.com In-Reply-To: <9511182103.aa21217@quern.epilogue.com> from "David Bridgham" at Nov 18, 95 06:10:34 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Before my general comments on resonably relaxing the "set as if simultaneous", and "sysUpTime not reflecting all counter transitions", be too widely known as an attempt to change SNMP, let me elaborate. :) 1) "Set as if simultaneous". One can always design a multiphase commit process, and proivde a mechanism to "undo", or depend on the local OS to provide locking, but after the best effort is made, there will always be some cases for which the "Set as if simultaneous" rule will break. Let it. 2) "sysUpTime not reflecting all counter transitions" All the solutions to this problem that I have seen deal with making changes to the MIB (from creating a new table that tracks these trasitions, all the way to associating a sysUpTime equivalent with each counter..) These solutions require that the Manager Application tracking these counters be aware of these MIBs, and make changes to their existing implementations to look at these new tables/mib variables when making rate/delta computations. IMHO, its not a MAJOR violation if sysUpTime were NOT to reflect all counter transitions. From a Manager Application viewpoint, it might get this big sudden spike for one polling interval, which will disappear from the subsequent ones. This will ONLY happen if the subagents go and come back within the Manager Poll interval.(typically 10-30 sec). I think the real underlying issue is to make available to an inquisitive Manager, if required, the actual implementation behind this apparently monolithic MIB. A simple practical solution would be to have a subagent table that tabulates current and past (which could get aged out) subagents registered with the main agent and a time stamp of their registration, and if applicable, deregistration. The "subagent id to the mib variables supported by that subagent" mapping could be in another table, if required. (one could use the v2 view table scheme to specify the information compactly) Older Manager Applications and some not so inquisitive newer Manager Applications will not make use of these tables, and hence would be susceptible to the rate/delta spikes (as they are today for all the existing subagents) Let them. I hope this clarifies what I had ment earlier. - sudhir   Delivery-Date: Sun, 19 Nov 1995 23:24:03 -0500 Received: (from daemon@localhost) by fv.com (8.7.1/8.7.1) id XAA21506 for X-agentx-local; Sun, 19 Nov 1995 23:24:02 -0500 (EST) Received: from europe.std.com (europe.std.com [192.74.137.10]) by fv.com (8.7.1/8.7.1) with SMTP id XAA21501 for ; Sun, 19 Nov 1995 23:24:00 -0500 (EST) Received: from world.std.com by europe.std.com (8.6.12/Spike-8-1.0) id XAA17862; Sun, 19 Nov 1995 23:23:52 -0500 Received: by world.std.com (5.65c/Spike-2.0) id AA22641; Sun, 19 Nov 1995 23:23:51 -0500 From: ralex@world.std.com (Aleksey Y Romanov) Message-Id: <199511200423.AA22641@world.std.com> Subject: summary, part 0 To: agentx@fv.com Date: Sun, 19 Nov 1995 23:23:51 -0500 (EST) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Hi, It seems reasonable to me to start with summary of my past experience in the area of extensible SNMP agents. I had been using four different APIs to develop MIB-modules, I had developed such API for number of products. I was involved into discussions around SNMP extension systems which I had no practical experience with. So, it seems to me that there is something of public interest in it. All of my experience is related to per-variable extensible SNMP agents. Let me shortly stop at per-variable vs per-packet multiplexing here. There are number of reasons to choose per-variable vs per-packet extensibility and there are number of reasons against it. IMHO, it all boils down to administrative overhead, security and discovery issues on the NMS side, because sub-agent is actually more complicated piece of code than full-blown agent and there is no additional waste in speed/space associated with per-packet multiplexing if DLLs are used to perform basic SNMP operations for all full-blown agents running in the same entity. This question is still wide open, however, it seems to me that what I am going to discuss will find its use ever if per-packet multiplexing will be chosen as a base for the standard. There are several separate aspects in this area I would like to address in following posts: 1. Basic primitives. Whatever mechanism is used to pass data, whatever design trade-offs are made in any area it seems like basic set of primitive operations required to successfully adapt third party MIB-module (sub-agent) is basically the same. 2. Program units vs logical units. One program unit can contain several logical units: e.g. standard MIB table and its enterprise augmentation are two logical units which are naturally to be located in the same program unit. Lots of stuff I saw so far assumes that there is one logical unit per program unit. Which creates lots of unconveniences in a long run. 3. Overlapped MIB-modules: e.g. when different rows in the same table are represented by different logical units. Aleksey   Delivery-Date: Sun, 19 Nov 1995 23:32:15 -0500 Received: (from daemon@localhost) by fv.com (8.7.1/8.7.1) id XAA23134 for X-agentx-local; Sun, 19 Nov 1995 23:32:12 -0500 (EST) Received: from europe.std.com (europe.std.com [192.74.137.10]) by fv.com (8.7.1/8.7.1) with SMTP id XAA23124 for ; Sun, 19 Nov 1995 23:32:10 -0500 (EST) Received: from world.std.com by europe.std.com (8.6.12/Spike-8-1.0) id XAA18787; Sun, 19 Nov 1995 23:32:02 -0500 Received: by world.std.com (5.65c/Spike-2.0) id AA27126; Sun, 19 Nov 1995 23:32:01 -0500 From: ralex@world.std.com (Aleksey Y Romanov) Message-Id: <199511200432.AA27126@world.std.com> Subject: summary, part1 To: agentx@fv.com Date: Sun, 19 Nov 1995 23:32:01 -0500 (EST) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Hi, Whatever mechanism is used to pass data, whatever design trade-offs are made in any area it seems like basic set of primitive operations required to successfully adapt third party MIB-module (sub-agent) is basically the same. In one environment it is reasonable sometimes to combine two or more primitives in one complex one, but the overall set is constant. As it was properly noted by BobN, all these primitives have to be optional to be implemented by particular sub-agent, however, all of them are required to be part of the master-sub-agent framework. So, it seems reasonable to spell them out. I am sorry, I am planning very skim description and rationale of each primitive. I hope it will be enough for the people already involved into agent design and implementations and I will be more than glad to answer questions, however, I would like to have this thing slim enough. This set of primitives I am describing is associated with no changes in both protocol and NMSs. A. General A.1 Initialization It is quite reasonable for master-agent to have a possibility to reset sub-agent into known state. E.g. if sub-agent initialization takes some time and can cause unwanted delays if implemented as part of PDU processing. Again, all primitives has to be optional, but this possibility has to be part of the framework. In particular if sub-agent is implemented as separate process it does not need this primitive to be used. A.2. Time ticking There are number of time related activities to be performed by sub-agent. Most important of them is cleanup of 'notReady', 'notInService' rows. Second use is to provide monitoring capabilities in single-threaded environments. Third, cacheing agents would like keep their cache up to date. So, we have to have entry to be alled once upon a litle while in order to allow sub-agent to perform these kinds of work. Again, all primitives has to be optional, but this possibility has to be part of the framework. In particular if sub-agent is implemented as separate process it does not need this primitive to be used. B. Get/GetNext/Bulk B.1. Beginning of the new PDU If sub-agent is using some sort of cacheing scheme one would not like to have cache updated in a middle of the PDU processing and thus have inconsistent data. Allowing for cache invalidation synchronously with PDU processing is a major necessity of this primitive. Again, all primitives has to be optional, but this possibility has to be part of the framework. In particular this primitive expected to have very light job associated with it, so it is primary candidate to be piggy-backed on top of search/retrieval primitive. B.2. Variable search/retrieval This is the most agreeable upon primitive :). There is only one issue to be discussed. In order to provide for effective GetNext/GetBulk implementations, access checking has to be performed within this primitive. Hence we have a requirement to admin model development: access rules database has to be small enough to be distributable to sub-agents at low price (in other words to be of small size) from master to sub-agent. Again, all primitives has to be optional, but this possibility has to be part of the framework. E.g. I can imagine sub-agent which has only time ticking primitive implemented. B.3. End of PDU processing We can expect that some sub-agents will temporarily allocate some local resources in order to process requests, so we have to give them a possibility to release these resources ASAP. At least we as standard body are in no position to punish implementors who chose this approach in their wares. C. Set C.1. Beginning of the new PDU It is not hard thing to imagine that sub-agent designer would appreciate being notified about new PDU being processed. Again, all primitives has to be optional, but this possibility has to be part of the framework. In particular this primitive expected to have very light job associated with it, so it is primary candidate to be piggy-backed on top of search/verification primitive. C.2. Variable search/verification This is the second most agreeable upon primitive. C.3. Resource locking If we are talking about sub-agents developed by independent parties we have to go some additional lengths insuring that whatever resource is locked it will be properly unlocked (e.g. setting splnet/splx in two different program modules). The most common way to insure this feature is to unlock resources in reverse order it is unlocked. So, master-agent has to have a good idea about order resources were locked in order to unlock them properly, easiest way to achieve it is by having resource locking as separate primitive. This primitive can be piggy-backed on search/verification primitive. However, if master agent calls search/verification primitive several times per PDU being processed, then it is desirable (from implementation point of view) to not piggy-back it. There are positi side effect of having this primitive separate: cross variable checking can be implemented within this primitive instead of search/verification which makes it a little bit easier. Again, all primitives has to be optional, but this possibility has to be part of the framework. C.4. Resource unlocking This is the third most agreeable primitive. Important thing is that it has to be called in reverse order vs resource locking primitive. Again, all primitives has to be optional, but this possibility has to be part of the framework. C.5. Commit This is the fourth most agreeable primitive. Again, all primitives has to be optional, but this possibility has to be part of the framework. C.6. Commit undo This is the fifth most agreeable primitive. Important thing is that it has to be called in reverse order vs commit primitive. It seems reasonable to have resource unlocking called after commit undoing in order to allow unwinding of the most complicated web of cross dependent resource locks, however, this idea is far from being generally accepted. Again, all primitives has to be optional, but this possibility has to be part of the framework. C.7. Release If all sub-agents performed commit successfully, the only thing left is to unlock resources and inform sub-agents about this remarkable achievement. Important thing is that it has to be called in reverse order vs resource locking primitive. Again, all primitives has to be optional, but this possibility has to be part of the framework. C.8. End of PDU processing We can expect that some sub-agents will temporarily allocate some local resources within search/verification primitive, these resources cannot not be freed as part of resource unlocking, because if one sub-agent had error-encountered in search/verification primitive, resource locking/unlocking stage will never be reached. So we have to give them a possibility to release these resources ASAP. At least we as standard body are in no position to punish implementors who chose this approach to there wares. Aleksey P.S. ftp://ftp.std.com/vendors/snmp/snmp95/snmp95.tar.Z can be used as an example implementation.   Delivery-Date: Mon, 20 Nov 1995 01:53:05 -0500 Received: (from daemon@localhost) by fv.com (8.7.1/8.7.1) id BAA18238 for X-agentx-local; Mon, 20 Nov 1995 01:53:04 -0500 (EST) Received: from matisse.fibronics.co.il (matisse.fibronics.co.il [192.114.66.22]) by fv.com (8.7.1/8.7.1) with SMTP id BAA18211 for ; Mon, 20 Nov 1995 01:52:55 -0500 (EST) Received: by matisse.fibronics.co.il id AA02320 (5.65c/IDA-1.4.4 for agentx@fv.com); Mon, 20 Nov 1995 08:57:21 +0200 Date: Mon, 20 Nov 1995 08:57:21 +0200 From: Yosef Kahana Message-Id: <199511200657.AA02320@matisse.fibronics.co.il> To: agentx@fv.com Subject: What kind of architecture is address by agentx ? I'm trying to understand to what kind of network architecture the agentx addresses to. Are we talking about sub-agent within a master-agent physicaly connected or connected over the net ? Are we taking about multiple agent corperating together ? Maybe it's Proxy-agent managment ? I'll start useing Primery agent(P) as name for the "master-agent" and Secondery agent (S) for "sub-agent". Does P know what are S capabilities ? If no, how does it learn S capabilities ? If P and S are physicaly connected, are we going to set connection protocol between P and S ? Yosef.   Delivery-Date: Mon, 20 Nov 1995 05:00:17 -0500 Received: (from daemon@localhost) by fv.com (8.7.1/8.7.1) id FAA15788 for X-agentx-local; Mon, 20 Nov 1995 05:00:16 -0500 (EST) Received: from VNET.IBM.COM (vnet.ibm.com [199.171.26.4]) by fv.com (8.7.1/8.7.1) with SMTP id FAA15784 for ; Mon, 20 Nov 1995 05:00:13 -0500 (EST) Message-Id: <199511201000.FAA15784@fv.com> Received: from UITVM1 by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 7165; Mon, 20 Nov 95 05:00:06 EST Date: Mon, 20 Nov 95 11:00:47 CET From: "Bert Wijnen" To: agentx@fv.com Subject: Changes to SNMP Ref: Your note of Sun, 19 Nov 1995 19:06:28 -0800 (PST) Subject: saMIB - subAgent MIB sudhir writes: > A simple practical solution would be to have a subagent > table that tabulates current and past (which could get > aged out) subagents registered with the main agent > and a time stamp of their registration, and if applicable, > deregistration. The "subagent id to the mib variables > supported by that subagent" mapping could be in another > table, if required. (one could use the v2 view table > scheme to specify the information compactly) Just in case newcomers have not seen it before, I have played with and actually implemented in products we (IBM) ship, a subAgent MIb that basically tries to do what sudhir proposes/suggests. I am attaching it here, so you can check it out and so we can discuss it in our WG meetings if that seems usefull. Bert Wijnen (IBM Research) ---------------- following is a copy of saMIB ------------------- -- the SUBAGENT MIB -- The MIB objects are implemented by the local SNMP agent -- This MIB is based on some experience with both DPI and SMUX -- subagents. As you can see, some of the ideas come from the -- original SMUX MIB (RFC1227) by Marshall Rose. -- We try to define a subagent MIB that represents subagents -- using different protocols. SUBAGENT-MIB DEFINITIONS ::= BEGIN IMPORTS enterprises, TimeTicks, Counter FROM RFC1155-SMI OBJECT-TYPE FROM RFC-1212 DisplayString FROM RFC1213-MIB; ibm OBJECT IDENTIFIER ::= { enterprises 2 } ibmResearch OBJECT IDENTIFIER ::= { ibm 4 } saMIB OBJECT IDENTIFIER ::= { ibmResearch 12 } -- -- Following can be used once we fit into SNMPv2 -- -- MODULE-IDENTITY, OBJECT-TYPE, snmpModules -- FROM SNMPv2-SMI -- -- saMIB MODULE-IDENTITY -- LAST-UPDATED "9403200000Z" -- ORGANIZATION "IBM Research - T.J. Watson Research Center" -- CONTACT-INFO -- " Bert Wijnen -- -- Postal: IBM International Operations -- Watsonweg 2 -- 1423 ND Uithoorn -- The Netherlands -- -- Tel: +31 2975 53316 -- Fax: +31 2975 62468 -- -- E-mail: wijnen@vnet.ibm.com -- (IBM internal: wijnen at nlvm1)" -- DESCRIPTION -- "The MIB module describing SNMP subagents." -- ::= { snmpModules x } saDefaultTimeout OBJECT-TYPE SYNTAX INTEGER -- (1..saMaxTimeout) -- UNITS "seconds" ACCESS read-write STATUS mandatory DESCRIPTION "The default timeout (in seconds) that this agent waits for a response from a SubAgent. This value is used if a timeout value is not specified for the subtree nor for the subagent that exports the subtree." -- DEFVAL { 5 } ::= { saMIB 1 } saMaxTimeout OBJECT-TYPE SYNTAX INTEGER (1..3600) -- 3600 is 60 minutes, -- so quite big already -- UNITS "seconds" ACCESS read-write STATUS mandatory DESCRIPTION "The maximum timeout (in seconds) that this agent allows for timeout values for SubAgents. When you try to set any other timeout value it must be between 1 and this maximum value." -- DEFVAL { 60 } ::= { saMIB 2 } saAllowDuplicateIDs OBJECT-TYPE SYNTAX INTEGER { yes(1), no(2) } ACCESS read-write STATUS mandatory DESCRIPTION "Controls if multiple instances of a sub-agent (as identified by the sub-agent Identifier) are allowed. Setting this object to the value no(2) will prevent (new) duplicate sub-agentIDs. However, if any duplicates exist at that point in time, the agent will not remove them. That is considered a manager responsibility." -- DEFVAL { yes } ::= { saMIB 3 } saNumber OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of entries in the saTable" ::= { saMIB 4 } saAllPacketsIn OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "A count of packets received from all subagents." ::= { saMIB 5 } saAllPacketsOut OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "A count of packets send to all subagents." ::= { saMIB 6 } saTable OBJECT-TYPE SYNTAX SEQUENCE OF SaEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "The SubAgent table, listing all subagents." ::= { saMIB 7 } saEntry OBJECT-TYPE SYNTAX SaEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "An entry in the SubAgent table." INDEX { saIndex } ::= { saTable 1 } SaEntry ::= SEQUENCE { saIndex INTEGER, saIdentifier OBJECT IDENTIFIER, saDescription DisplayString, saStatus INTEGER, saStatusChangeTime TimeTicks, saProtocol INTEGER, saProtocolVersion INTEGER, saProtocolRelease INTEGER, saTransport INTEGER, saTransportAddress OCTET STRING, saTimeout INTEGER, saMaxVarBinds INTEGER, saPacketsIn Counter, saPacketsOut Counter } saIndex OBJECT-TYPE SYNTAX INTEGER (1..4294967295) ACCESS read-only STATUS mandatory DESCRIPTION "An index which uniquely identifies a SubAgent. The number is in the range from 1 up to and including the value of saNumber." ::= { saEntry 1 } saIdentifier OBJECT-TYPE SYNTAX OBJECT IDENTIFIER ACCESS read-only STATUS mandatory DESCRIPTION "The authoritative identification for a SubAgent." ::= { saEntry 2 } saDescription OBJECT-TYPE SYNTAX DisplayString (SIZE (0..255)) ACCESS read-only STATUS mandatory DESCRIPTION "A descriptive name for a SubAgent." ::= { saEntry 3 } saStatus OBJECT-TYPE SYNTAX INTEGER { valid(1), invalid(2), connecting(3), disconnecting(4), closedByManager(5), closedByAgent(6), closedBySubAgent(7), closedBySubAgentTimeout(8), closedBySubAgentError(9) } ACCESS read-write STATUS mandatory DESCRIPTION "The status of the SubAgent. The only value that can be set is invalid(2). This can only be done if the status is not already in a ClosedSomething status. Setting this object to the value invalid(2) has the effect of invalidating the entry upon which the agent will close the connection and turn it to status closedByManager(7). It is an implementation specific matter if an entry that is not valid(1) is removed from the table. However, if such an entry is kept and the subagent re-connects, then the same entry must be re-used." ::= { saEntry 4 } saStatusChangeTime OBJECT-TYPE SYNTAX TimeTicks ACCESS read-only STATUS mandatory DESCRIPTION "The timestamp of the last status change of the SubAgent. Timestamp is taken from the sysUpTime." ::= { saEntry 5 } saProtocol OBJECT-TYPE SYNTAX INTEGER { dpi(1), -- SNMP DPI, RFC 1228 & 1592 moh(2), -- SNMP MIB Object Handler smux(3) -- SNMP MUX, RFC 1227 } ACCESS read-only STATUS mandatory DESCRIPTION "The SubAgent protocol being used." ::= { saEntry 6 } saProtocolVersion OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION "The version of the SubAgent Protocol used." ::= { saEntry 7 } saProtocolRelease OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION "The release of the SubAgent Protocol used." ::= { saEntry 8 } saTransport OBJECT-TYPE SYNTAX INTEGER { udp(1), -- User Datagram tcp(2), -- Transmission Control nmq(3), -- Named Queue sna(4) -- IBM SNA } ACCESS read-only STATUS mandatory DESCRIPTION "The transport protocol used by the SubAgent." ::= { saEntry 9 } saTransportAddress OBJECT-TYPE SYNTAX OCTET STRING ACCESS read-only STATUS mandatory DESCRIPTION "The address of the subagent (transport specific address information)." -- IPaddress, Portnumber for UDP and TCP -- DisplayString for Named Queue -- DisplayString for SNA (LU-name) ::= { saEntry 10 } saTimeout OBJECT-TYPE SYNTAX INTEGER -- (1..saMaxTimeout) -- UNITS "seconds" ACCESS read-write STATUS mandatory DESCRIPTION "The default timeout (seconds) for a SubAgent response. This value will be used if there is no timeout value specified for a particular subtree." -- DEFVAL { 0 } ::= { saEntry 11 } saMaxVarBinds OBJECT-TYPE SYNTAX INTEGER (0..4294967295) ACCESS read-only STATUS mandatory DESCRIPTION "Max varBinds this subagent accepts per request." ::= { saEntry 12 } saPacketsIn OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "A count of packets received from this subagent." ::= { saEntry 13 } saPacketsOut OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "A count of packets send to this subagent." ::= { saEntry 14 } saTreeTable OBJECT-TYPE SYNTAX SEQUENCE OF SaTreeEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "The SubAgent tree table." ::= { saMIB 8 } saTreeEntry OBJECT-TYPE SYNTAX SaTreeEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "An entry in the SubAgent tree table." INDEX { saTsubtree, saTpriority } ::= { saTreeTable 1 } SaTreeEntry ::= SEQUENCE { saTsubtree OBJECT IDENTIFIER, saTpriority INTEGER, saTindex INTEGER, saTstatus INTEGER, saTtimeout INTEGER } saTsubtree OBJECT-TYPE SYNTAX OBJECT IDENTIFIER ACCESS read-only STATUS mandatory DESCRIPTION "The MIB subtree being exported by the SubAgent." ::= { saTreeEntry 1 } saTpriority OBJECT-TYPE SYNTAX INTEGER (0..'7fffffff'h) ACCESS read-only STATUS mandatory DESCRIPTION "The SubAgents Priority when exporting the MIB subtree. The lower the value the better the priority." ::= { saTreeEntry 2 } saTindex OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION "The SubAgent's identity (index into the saTable)." ::= { saTreeEntry 3 } saTstatus OBJECT-TYPE SYNTAX INTEGER { valid(1), -- registered, active entry invalid(2), -- invalid, unregistered waiting(3) -- registered, waiting cause -- higher priority entry is -- valid/active now } ACCESS read-write STATUS mandatory DESCRIPTION "The status of subtree exported by the SubAgent. The only value that can be set is invalid(2). Setting this object to the value invalid(2) has the effect of invalidating the entry. It is an implementation specific matter if an entry that is not valid(1) or waiting(3) is removed from the table." ::= { saTreeEntry 4 } saTtimeout OBJECT-TYPE SYNTAX INTEGER -- (1..saMaxTimeout) -- UNITS "seconds" ACCESS read-write STATUS mandatory DESCRIPTION "The timeout (in seconds) for objects in this subtree. A value of zero (0) means that the overall timeout value (as specified in the saTableEntry for the SubAgent) will be used." -- DEFVAL { 0 } ::= { saTreeEntry 5 } END   Delivery-Date: Mon, 20 Nov 1995 13:11:26 -0500 Received: (from daemon@localhost) by fv.com (8.7.1/8.7.1) id NAA17490 for X-agentx-local; Mon, 20 Nov 1995 13:11:23 -0500 (EST) Received: from ingate.adc.com (ingate.adc.com [155.226.10.200]) by fv.com (8.7.1/8.7.1) with SMTP id NAA17480 for ; Mon, 20 Nov 1995 13:11:21 -0500 (EST) Received: by ingate.adc.com (5.65/DEC-Ultrix/4.3) id AA19726; Mon, 20 Nov 1995 12:11:09 -0600 Message-Id: <9511201811.AA19726@ingate.adc.com> Received: by shelob (1.37.109.16/16.2) id AA270641071; Mon, 20 Nov 1995 12:11:11 -0600 From: Heng Lou Subject: subscribe To: agentx@fv.com Date: Mon, 20 Nov 95 12:11:10 CST Mailer: Elm [revision: 70.85] Subject: subscribe   Delivery-Date: Mon, 20 Nov 1995 13:25:44 -0500 Received: (from daemon@localhost) by fv.com (8.7.1/8.7.1) id NAA19812 for X-agentx-local; Mon, 20 Nov 1995 13:25:43 -0500 (EST) Received: from epilogue.com (quern.epilogue.com [128.224.1.136]) by fv.com (8.7.1/8.7.1) with SMTP id NAA19809 for ; Mon, 20 Nov 1995 13:25:41 -0500 (EST) Received: from dab.gate.epilogue.com with DMSP Date: Mon, 20 Nov 95 11:23:08 -0700 From: David Bridgham To: agentx@fv.com In-reply-to: "sudhir@netcom.com"'s message of Sun, 19 Nov 1995 19:06:28 -0800 (PST) Subject: Re: Changes to SNMP Sender: dab@epilogue.com Repository: quern.epilogue.com Originating-client: gate.epilogue.com Message-ID: <9511201323.aa09671@quern.epilogue.com> Before my general comments on resonably relaxing the "set as if simultaneous", and "sysUpTime not reflecting all counter transitions", be too widely known as an attempt to change SNMP, let me elaborate. :) They still sound like changes to SNMP to me. All the solutions to this problem that I have seen deal with making changes to the MIB (from creating a new table that tracks these trasitions, all the way to associating a sysUpTime equivalent with each counter..) Not all the solutions. You can also reset sysUptime appropriately. These solutions require that the Manager Application tracking these counters be aware of these MIBs, and make changes to their existing implementations to look at these new tables/mib variables when making rate/delta computations. I thought your goal was not to change any manager application. Older Manager Applications and some not so inquisitive newer Manager Applications will not make use of these tables, and hence would be susceptible to the rate/delta spikes (as they are today for all the existing subagents) Not all sub-agents schemes today necessarily have this bug. Dave   Delivery-Date: Mon, 20 Nov 1995 14:00:16 -0500 Received: (from daemon@localhost) by fv.com (8.7.1/8.7.1) id OAA26657 for X-agentx-local; Mon, 20 Nov 1995 14:00:14 -0500 (EST) Received: from hp.com (hp.com [15.255.152.4]) by fv.com (8.7.1/8.7.1) with ESMTP id OAA26633 for ; Mon, 20 Nov 1995 14:00:12 -0500 (EST) Received: from nsmdserv.cnd.hp.com by hp.com with SMTP (1.37.109.16/15.5+ECS 3.3) id AA210794005; Mon, 20 Nov 1995 11:00:05 -0800 Received: from localhost by nsmdserv.cnd.hp.com with SMTP (1.38.193.5/15.5+ECS 3.3) id AA04594; Mon, 20 Nov 1995 12:00:03 -0700 Message-Id: <9511201900.AA04594@nsmdserv.cnd.hp.com> To: agentx@fv.com Subject: What about Requirements? In-Reply-To: Your message of Wed, 08 Nov 1995 22:03:27 -0800. <17348.815897007@dbc.mtview.ca.us> Date: Mon, 20 Nov 1995 12:00:03 -0700 From: "Brian O'Keefe" It is evident from postings to this mailing list that a clear set of detailed requirements, let alone an agreed upon understanding of those requirements, does not exist. This is a significant concern given the diverse and contrasting opinions on this technology. Further, the lack of clearly defined requirements became a very hot topic in another recent NM Area WG. I wish to not repeat the debacle of that WG. Without detailed requirements IDENTIFIED, DOCUMENTED, PRIORITIZED and AGREED UPON, there is no way to know: a) when we are done, nor b) if what we have produced satisfies anyone's needs. The WG Chair's first of three questions relates to requirements (ref: "preparations for next month", 8 Nov 95). However, there is no stated OBJECTIVE to yield a well documented set of requirements which are then prioritized and used to guide and bound the design of a standards-track solution. I am very concerned about an ad-hoc approach to the issue of requirements w/in the process. Therefore, I request that the WG Chair include a formal requirements specification phase to the process. I would expect the deliverable of this phase to be an internet-draft (or even an informational RFC) from which the WG can specify a solution and measure progress. I suspect that this effort will require AT LEAST one full WG session in Dallas to do it right. I believe this is time well spent. Regards, bok PS - a related topic is the lack of an overall documented and agreed upon process (both engineering and logistical) by which the WG is to conduct its business. Will this be a topic to be addressed and completed during the initial WG meeting in Dallas?   Delivery-Date: Mon, 20 Nov 1995 15:27:07 -0500 Received: (from daemon@localhost) by fv.com (8.7.1/8.7.1) id PAA11597 for X-agentx-local; Mon, 20 Nov 1995 15:27:04 -0500 (EST) Received: from acme.sb.west.net (acme.sb.west.net [205.254.224.2]) by fv.com (8.7.1/8.7.1) with SMTP id PAA11587 for ; Mon, 20 Nov 1995 15:27:01 -0500 (EST) Received: (from abierman@localhost) by acme.sb.west.net (8.6.12/8.6.12) id MAA03825; Mon, 20 Nov 1995 12:20:17 -0800 From: Andy Bierman Message-Id: <199511202020.MAA03825@acme.sb.west.net> Subject: Re: What about Requirements? To: bok@nsmdserv.cnd.hp.com (Brian O'Keefe) Date: Mon, 20 Nov 1995 12:20:17 -0800 (PST) Cc: agentx@fv.com In-Reply-To: <9511201900.AA04594@nsmdserv.cnd.hp.com> from "Brian O'Keefe" at Nov 20, 95 12:00:03 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text > > >It is evident from postings to this mailing list that a clear set of >detailed requirements, let alone an agreed upon understanding of those >requirements, does not exist. This is a significant concern given the >diverse and contrasting opinions on this technology. Further, the lack >of clearly defined requirements became a very hot topic in another >recent NM Area WG. I wish to not repeat the debacle of that WG. > >Without detailed requirements IDENTIFIED, DOCUMENTED, PRIORITIZED and >AGREED UPON, there is no way to know: > a) when we are done, nor > b) if what we have produced > satisfies anyone's needs. > Thank you Brian. I'm not sure how this WG can reconcile the wide spectrum of ideas on the fundamental question: Where is the boundary between manager and managed device? total visibility some visibility sub-agents are and control no control invisible +----------------+-------------------+ SNMPv2 proxy saMIB SNMPv1 One end of the spectrum wants to move the boundary into the agent, so an NMS has to manage an arbitrary mix of sub-agents, keeping PDUs for each one separated, and keeping independent sysUpTime values for each subagent. (These people think proxy is the way to go and perhaps this WG is not necessary.) The other end of the spectrum doesn't want to change the boundary at all. An NMS sends an arbitrary PDU to an agent, and it is an implementation detail as to how the PDU is handled. (These people think this WG was created to standardize communication between an agent and a sub-agent or between multiple sub-agents, NOT between an NMS and an agent.) The people in the middle think some amount of work is needed in both areas. I think the WG must decide where this manager <--> managed-device boundary is before proceeding to write MIBs. > >Therefore, I request that the WG Chair include a formal requirements >specification phase to the process. I would expect the deliverable >of this phase to be an internet-draft (or even an informational RFC) >from which the WG can specify a solution and measure progress. I second the motion! > >Regards, >bok Andy   Delivery-Date: Tue, 21 Nov 1995 02:15:49 -0500 Received: (from daemon@localhost) by fv.com (8.7.1/8.7.1) id CAA13325 for X-agentx-local; Tue, 21 Nov 1995 02:15:49 -0500 (EST) Received: from tsunami.dbc.mtview.ca.us (tsunami.dbc.mtview.ca.us [204.250.93.202]) by fv.com (8.7.1/8.7.1) with ESMTP id CAA13319 for ; Tue, 21 Nov 1995 02:15:47 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by tsunami.dbc.mtview.ca.us (8.6.10/8.6.10) with ESMTP id XAA06606; Mon, 20 Nov 1995 23:07:33 -0800 To: "Brian O'Keefe" reply-to: agentx@fv.com cc: agentx@fv.com Subject: Re: What about Requirements? In-reply-to: Your message of "Mon, 20 Nov 1995 12:00:03 MST." <9511201900.AA04594@nsmdserv.cnd.hp.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <6599.816937649.1@dbc.mtview.ca.us> Date: Mon, 20 Nov 1995 23:07:30 -0800 Message-ID: <6601.816937650@dbc.mtview.ca.us> From: Marshall Rose the development of formal requirements is not a part of the agentx charter, and i am unaware of any IETF-activity which can trace its success to the development of formal requirements prior to doing the work that it was chartered to undertake. if you feel that the development of formal requirements would serve the agentx working group by bringing it to a speedy and successful conclusion, then i urge you to make a presentation along those lines at the agentx meeting in dallas. /mtr   Delivery-Date: Tue, 21 Nov 1995 08:29:57 -0500 Received: (from daemon@localhost) by fv.com (8.7.1/8.7.1) id IAA27655 for X-agentx-local; Tue, 21 Nov 1995 08:29:56 -0500 (EST) Received: from europe.std.com (europe.std.com [192.74.137.10]) by fv.com (8.7.1/8.7.1) with SMTP id IAA27647 for ; Tue, 21 Nov 1995 08:29:54 -0500 (EST) Received: from world.std.com by europe.std.com (8.6.12/Spike-8-1.0) id IAA29619; Tue, 21 Nov 1995 08:29:47 -0500 Received: by world.std.com (5.65c/Spike-2.0) id AA21920; Tue, 21 Nov 1995 08:29:45 -0500 From: ralex@world.std.com (Aleksey Y Romanov) Message-Id: <199511211329.AA21920@world.std.com> Subject: Re: What about Requirements? To: abierman@west.net (Andy Bierman) Date: Tue, 21 Nov 1995 08:29:44 -0500 (EST) Cc: agentx@fv.com In-Reply-To: <199511202020.MAA03825@acme.sb.west.net> from "Andy Bierman" at Nov 20, 95 12:20:17 pm X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit > I'm not sure how this WG can reconcile the wide spectrum of ideas > on the fundamental question: Where is the boundary between > manager and managed device? > > total visibility some visibility sub-agents are > and control no control invisible > +----------------+-------------------+ > SNMPv2 proxy saMIB SNMPv1 > > One end of the spectrum wants to move the boundary into the agent, > so an NMS has to manage an arbitrary mix of sub-agents, keeping > PDUs for each one separated, and keeping independent sysUpTime values > for each subagent. (These people think proxy is the way to go > and perhaps this WG is not necessary.) First, I would like to note that SNMPv2 proxy is not absolutely open: each sub-agent looks like context of the primary agent, with one funny quirk - if proxied agent is not there, there will be no response instead of 'noSuch'/'notWritable'. Second, this actually not so bad idea, once three issues will find its solution. 1. Administrative over-kill. Each proxied-agent is full-blown SNMP agent with administrative parameters which are set and maintained independently on per sub-agent basis. Proxy agent has to keep potentially huge (just think about 100 sub-agents with 10 contexts in each with 10 users per context) proxy database allowing mapping external admin paramters to sub-agent parameters. And all this stuff (with sub-agents which can dynamically come and go) has to be maintained by controlling NMS. So, we have to advise a way to define operations of claster of of SNMP agents sharing common admin database before this idea will become viable 2. Proxy performance over-kill. Just think about it, in order to just forward packet proxy-agent has to to parse wrapper and decrypt PDU then, it has to encrypt PDU and rebuild wrapper. And it has to maintain database of outstanding requests in order to properly forward responses. IMHO, forwarding has to be done much cheaper. 3. Autodiscovery. snmpORTable is very weak mechanism to present functionality provided by sub-agent especially if sub-agents can come and go. So, let me outline what will be a reasonable proxy-like solution, do not beat me hard if you do not like it it is just a proposal. Claster-agents: 1. All sub-agents share same admin infrastructure. E.g. there is only one view database used across all sub-agents. Context access permissions are expressed on per context group basis (see snmpv2*), which shared across all sub-agents. Each sub-agent represents context but access rules are based upon bigger units (context groups). 2. There is master agent it has two MIBs: sub-agent MIB describing who is there and who is doing what, and admin/security MIB. Master agent is repsonsible to periodically check presense of sub-agents by sending authenticated PDUs to sub-agents. 3. No forwarding for claster agents, period. Each sub-agent advertises its transport address in sub-agent MIB. If forwarding is required then proxy should be used. > Andy Aleksey   Delivery-Date: Tue, 21 Nov 1995 08:56:21 -0500 Received: (from daemon@localhost) by fv.com (8.7.1/8.7.1) id IAA01295 for X-agentx-local; Tue, 21 Nov 1995 08:56:21 -0500 (EST) Received: from utrhcs.cs.utwente.nl (utrhcs.cs.utwente.nl [130.89.10.247]) by fv.com (8.7.1/8.7.1) with SMTP id IAA01287 for ; Tue, 21 Nov 1995 08:56:19 -0500 (EST) Received: from myrtilos.cs.utwente.nl by utrhcs.cs.utwente.nl (SMI-8.6/csrelayMX-SVR4_1.1tmp/RB) id OAA22783; Tue, 21 Nov 1995 14:56:02 +0100 Received: from dijkstra.cs.utwente.nl by myrtilos.cs.utwente.nl (SMI-8.6/csrelay-Sol1.4/RB) id OAA25182; Tue, 21 Nov 1995 14:56:02 +0100 Received: from localhost by dijkstra.cs.utwente.nl (SMI-8.6/SMI-SVR4) id OAA06252; Tue, 21 Nov 1995 14:56:02 +0100 Message-Id: <199511211356.OAA06252@dijkstra.cs.utwente.nl> To: agentx@fv.com Subject: archived From: f.p.h.vanHengstum@cs.utwente.nl Organisation: "Frederic P. H. van Hengstum" "Dept. of Computer Science" "P.O. Box 217, 7500 AE Enschede, The Netherlands" "phone +31 53 4893742, fax +31 53 4333815" "www http://www.cs.utwente.nl/~hengstum/" "" Date: Tue, 21 Nov 1995 14:56:01 +0100 Sender: hengstum@cs.utwente.nl ---------------------------------CUT-HERE------------------------------------ Hi, The postings on this mailing list will be archived on the SimpleWeb server! (http://wwwsnmp.cs.utwente.nl) Regards, Eric van Hengstum ---------------------------------CUT-HERE------------------------------------ If a train station is where a train stops, then what's a workstation ? Anonymous.   Delivery-Date: Tue, 21 Nov 1995 10:14:11 -0500 Received: (from daemon@localhost) by fv.com (8.7.1/8.7.1) id KAA11766 for X-agentx-local; Tue, 21 Nov 1995 10:14:10 -0500 (EST) Received: from ks3.haninge.trab.se (ks3.haninge.trab.se [131.115.49.96]) by fv.com (8.7.1/8.7.1) with SMTP id KAA11752 for ; Tue, 21 Nov 1995 10:14:07 -0500 (EST) Received: from yankees.haninge.trab.se by ks3.haninge.trab.se with SMTP id AA17451 (5.65c8+/IDA-1.4.4 for ); Tue, 21 Nov 1995 16:07:17 +0100 Received: from redsox.haninge.trab.se by yankees.haninge.trab.se (4.1/SMI-4.1) id AA04572; Tue, 21 Nov 95 16:07:13 +0100 Date: Tue, 21 Nov 95 16:07:13 +0100 From: Kim.Laraqui@haninge.trab.se (Kim Laraqui Sfp-han) Message-Id: <9511211507.AA04572@yankees.haninge.trab.se> To: agentx@fv.com Subject: entity MIB Will the entity MIB (draft-ietf-entmib-entmib-00.txt) find a place in this group? /kim   Delivery-Date: Tue, 21 Nov 1995 10:35:40 -0500 Received: (from daemon@localhost) by fv.com (8.7.1/8.7.1) id KAA14875 for X-agentx-local; Tue, 21 Nov 1995 10:35:39 -0500 (EST) Received: from relay.hp.com (relay.hp.com [15.255.152.2]) by fv.com (8.7.1/8.7.1) with ESMTP id KAA14858 for ; Tue, 21 Nov 1995 10:35:35 -0500 (EST) Received: from nsmdserv.cnd.hp.com by relay.hp.com with SMTP (1.37.109.16/15.5+ECS 3.3) id AA289948125; Tue, 21 Nov 1995 07:35:26 -0800 Received: from localhost by nsmdserv.cnd.hp.com with SMTP (1.38.193.5/15.5+ECS 3.3) id AA01735; Tue, 21 Nov 1995 08:34:03 -0700 Message-Id: <9511211534.AA01735@nsmdserv.cnd.hp.com> To: agentx@fv.com Cc: "Brian O'Keefe" Subject: Re: What about Requirements? In-Reply-To: Your message of Mon, 20 Nov 1995 23:07:30 -0800. <6601.816937650@dbc.mtview.ca.us> Date: Tue, 21 Nov 1995 08:34:03 -0700 From: "Brian O'Keefe" > the development of formal requirements is not a part of the agentx > charter, and i am unaware of any IETF-activity which can trace its > success to the development of formal requirements prior to doing the > work that it was chartered to undertake. > > /mtr maybe not, but I can sure point to at least one BIG failure because there were no formal requirements guiding the work. bok   Delivery-Date: Tue, 21 Nov 1995 11:20:46 -0500 Received: (from daemon@localhost) by fv.com (8.7.1/8.7.1) id LAA22022 for X-agentx-local; Tue, 21 Nov 1995 11:20:45 -0500 (EST) Received: from card.com (card.com [199.100.120.2]) by fv.com (8.7.1/8.7.1) with ESMTP id LAA22015 for ; Tue, 21 Nov 1995 11:20:43 -0500 (EST) Received: from ra.ibr.cs.tu-bs.de (ra.ibr.cs.tu-bs.de [134.169.246.34]) by card.com (8.7.1/8.7.1) with SMTP id LAA27424 for ; Tue, 21 Nov 1995 11:20:07 -0500 (EST) Received: from data [134.169.34.7] by ra.ibr.cs.tu-bs.de (8.6.10/tubsibr) with ESMTP id RAA09043; Tue, 21 Nov 1995 17:09:17 +0100 Received: from schoenw@localhost by data.ibr.cs.tu-bs.de (8.6.10/tubsibr) id RAA11963; Tue, 21 Nov 1995 17:09:09 +0100 Date: Tue, 21 Nov 1995 17:09:09 +0100 Message-Id: <199511211609.RAA11963@data.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: dab@epilogue.com CC: agentx@fv.com In-reply-to: <9511201323.aa09671@quern.epilogue.com> (message from David Bridgham on Mon, 20 Nov 95 11:23:08 -0700) Subject: Re: Changes to SNMP Reply-to: schoenw@ibr.cs.tu-bs.de Hi! sudhir@netcom.com (Sudhir Pendse) wrote: Sudhir> All the solutions to this problem that I have seen deal with Sudhir> making changes to the MIB (from creating a new table that Sudhir> tracks these trasitions, all the way to associating a Sudhir> sysUpTime equivalent with each counter..) David Bridgham said: David> Not all the solutions. You can also reset sysUptime David> appropriately. So you propose to reset sysUpTime whenever a sub-agent appears, disappears or re-initializes itself, right? Does this simple solution cover all important situations? What are the drawbacks (other than some additional SNMP traffic because the manager has to re-initialize statistics for all variables although many of them are still valid.) Juergen   Delivery-Date: Tue, 21 Nov 1995 12:23:01 -0500 Received: (from daemon@localhost) by fv.com (8.7.1/8.7.1) id MAA01114 for X-agentx-local; Tue, 21 Nov 1995 12:22:59 -0500 (EST) Received: from vader.premisys.com (vader.premisys.com [199.182.239.1]) by fv.com (8.7.1/8.7.1) with SMTP id MAA01104 for ; Tue, 21 Nov 1995 12:22:54 -0500 (EST) Received: from jostein.premisys.com (jostein.premisys.com [199.190.211.254]) by vader.premisys.com (8.6.9/8.6.9) with SMTP id JAA07103 for ; Tue, 21 Nov 1995 09:23:03 -0800 Received: by jostein.premisys.com with Microsoft Mail id <01BAB7F2.DCC3D460@jostein.premisys.com>; Tue, 21 Nov 1995 09:22:21 -0800 Message-ID: <01BAB7F2.DCC3D460@jostein.premisys.com> From: Jostein Eklund To: "'agentx@fv.com'" Subject: unsubscribe Jostein.Eklund@premisys.com Date: Tue, 21 Nov 1995 09:22:16 -0800 Return-Receipt-To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Get me off the mailing-list now!!!!!   Delivery-Date: Tue, 21 Nov 1995 13:20:24 -0500 Received: (from daemon@localhost) by fv.com (8.7.1/8.7.1) id NAA10622 for X-agentx-local; Tue, 21 Nov 1995 13:20:21 -0500 (EST) Received: from tsunami.dbc.mtview.ca.us ([204.250.93.202]) by fv.com (8.7.1/8.7.1) with ESMTP id NAA10613 for ; Tue, 21 Nov 1995 13:20:18 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by tsunami.dbc.mtview.ca.us (8.6.10/8.6.10) with ESMTP id KAA13370; Tue, 21 Nov 1995 10:09:57 -0800 To: "Brian O'Keefe" cc: agentx@fv.com reply-to: agentx@fv.com Subject: Re: What about Requirements? In-reply-to: Your message of "Tue, 21 Nov 1995 08:34:03 MST." <9511211534.AA01735@nsmdserv.cnd.hp.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <13366.816977396.1@dbc.mtview.ca.us> Date: Tue, 21 Nov 1995 10:09:57 -0800 Message-ID: <13368.816977397@dbc.mtview.ca.us> From: Marshall Rose > > the development of formal requirements is not a part of the agentx > > charter, and i am unaware of any IETF-activity which can trace its > > success to the development of formal requirements prior to doing the > > work that it was chartered to undertake. > > > > /mtr > > maybe not, but I can sure point to at least one BIG failure because > there were no formal requirements guiding the work. > > bok brian - i am unaware of any BIG failure because of no formal requirements. if your reference is to snmpv2, then formal requirements wouldn't have prevented the disaster. (parenthentically i will note that the snmp security work started out with a list of requirements, that's where the "threats" section in the admin documents came from...) but...to re-iterate from my previous message: if you feel that developing formal requirements would help to bring the wg to a timely and succesful conclusion, then i urge you to make a presentation to that effect in the wednesday meeting of the working group! /mtr   Delivery-Date: Tue, 21 Nov 1995 13:25:24 -0500 Received: (from daemon@localhost) by fv.com (8.7.1/8.7.1) id NAA11762 for X-agentx-local; Tue, 21 Nov 1995 13:25:23 -0500 (EST) Received: from vader.premisys.com (vader.premisys.com [199.182.239.1]) by fv.com (8.7.1/8.7.1) with SMTP id NAA11219 for ; Tue, 21 Nov 1995 13:23:14 -0500 (EST) Received: from jostein.premisys.com (jostein.premisys.com [199.190.211.254]) by vader.premisys.com (8.6.9/8.6.9) with SMTP id KAA08615 for ; Tue, 21 Nov 1995 10:21:34 -0800 Received: by jostein.premisys.com with Microsoft Mail id <01BAB7FB.0BB697A0@jostein.premisys.com>; Tue, 21 Nov 1995 10:20:56 -0800 Message-ID: <01BAB7FB.0BB697A0@jostein.premisys.com> From: Jostein Eklund To: "'agentx@fv.com'" Subject: unsubscribe Jostein.Eklund@premisys.com Date: Tue, 21 Nov 1995 10:20:52 -0800 Return-Receipt-To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit   Delivery-Date: Tue, 21 Nov 1995 13:43:42 -0500 Received: (from daemon@localhost) by fv.com (8.7.1/8.7.1) id NAA15324 for X-agentx-local; Tue, 21 Nov 1995 13:43:41 -0500 (EST) Received: from vader.premisys.com (vader.premisys.com [199.182.239.1]) by fv.com (8.7.1/8.7.1) with SMTP id NAA15009 for ; Tue, 21 Nov 1995 13:41:47 -0500 (EST) Received: from jostein.premisys.com (jostein.premisys.com [199.190.211.254]) by vader.premisys.com (8.6.9/8.6.9) with SMTP id KAA09135 for ; Tue, 21 Nov 1995 10:40:00 -0800 Received: by jostein.premisys.com with Microsoft Mail id <01BAB7FD.76982000@jostein.premisys.com>; Tue, 21 Nov 1995 10:38:15 -0800 Message-ID: <01BAB7FD.76982000@jostein.premisys.com> From: Jostein Eklund To: "'agentx@fv.com'" Subject: unsubscribe Jostein.Eklund@premisys.com Date: Tue, 21 Nov 1995 10:38:11 -0800 Return-Receipt-To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit   Delivery-Date: Tue, 21 Nov 1995 14:14:56 -0500 Received: (from daemon@localhost) by fv.com (8.7.1/8.7.1) id OAA21346 for X-agentx-local; Tue, 21 Nov 1995 14:14:54 -0500 (EST) Received: from epilogue.com (quern.epilogue.com [128.224.1.136]) by fv.com (8.7.1/8.7.1) with SMTP id OAA21339 for ; Tue, 21 Nov 1995 14:14:52 -0500 (EST) Received: from dab.gate.epilogue.com with DMSP Date: Tue, 21 Nov 95 11:29:21 -0700 From: David Bridgham To: agentx@fv.com In-reply-to: "schoenw@ibr.cs.tu-bs.de"'s message of Tue, 21 Nov 1995 17:09:09 +0100 Subject: Re: Changes to SNMP Sender: dab@epilogue.com Repository: quern.epilogue.com Originating-client: gate.epilogue.com Message-ID: <9511211413.aa23924@quern.epilogue.com> So you propose to reset sysUpTime whenever a sub-agent appears, disappears or re-initializes itself, right? Well, I propose that sub-agents are a bad idea, but if you're going to do them then that's basically it. Actually, I believe only one of "when a sub-agent appears" or "when a sub-agent disappears" is necessary and if you want to optimize it further it's only necessary when a given instance of a variable disappears and then reappears. And all three of the above could be allowed by different master agents (implementation differences) with no loss of correctness. Does this simple solution cover all important situations? What are the drawbacks (other than some additional SNMP traffic because the manager has to re-initialize statistics for all variables although many of them are still valid.) As far as I know, the extra traffic is people's main objection. At the very least I want to have that objection in the open so everyone knows it's a performance issue not one of being unable to do it correctly with respect to the current SNMP protocol. Dave   Delivery-Date: Tue, 21 Nov 1995 15:20:28 -0500 Received: (from daemon@localhost) by fv.com (8.7.1/8.7.1) id PAA04012 for X-agentx-local; Tue, 21 Nov 1995 15:20:27 -0500 (EST) Received: from epilogue.com (quern.epilogue.com [128.224.1.136]) by fv.com (8.7.1/8.7.1) with SMTP id PAA03981 for ; Tue, 21 Nov 1995 15:20:23 -0500 (EST) Received: from dab.gate.epilogue.com with DMSP Date: Tue, 21 Nov 95 13:10:25 -0700 From: David Bridgham To: agentx@fv.com In-reply-to: "ralex@world.std.com"'s message of Tue, 21 Nov 1995 08:29:44 -0500 (EST) Subject: Re: What about Requirements? Sender: dab@epilogue.com Repository: quern.epilogue.com Originating-client: gate.epilogue.com Message-ID: <9511211519.aa24556@quern.epilogue.com> I'll see if I can get this finished before my computer crashes this time. So, let me outline what will be a reasonable proxy-like solution, do not beat me hard if you do not like it it is just a proposal. It's certainly not my intent to beat on anyone. In fact, I'm rather intrigued by some of the ideas here. I do want to point some things out though. Claster-agents: I'd like a new term but did you mean, perhaps, "cluster"? I don't know if this is what Aleksey was talking about, but there are two types of proxies. Not different in the protocol, but different in usage. One proxy, the kind that most people seem to think of when they hear the term, is to a proxy target that's usually another device, perhaps the proxy protocol isn't even SNMP. The manager probably wants to display this as a separate entity. The other proxy is when proxies are used for agent extensibility. Here the proxy targert is usually in the same box as the proxy agent and the manager may wish to mush all the data together and display it as a single entity. 1. Administrative over-kill. Each proxied-agent is full-blown SNMP agent with administrative parameters which are set and maintained independently on per sub-agent basis. Proxy agent has to keep potentially huge (just think about 100 sub-agents with 10 contexts in each with 10 users per context) proxy database allowing mapping external admin paramters to sub-agent parameters. And all this stuff (with sub-agents which can dynamically come and go) has to be maintained by controlling NMS. I suspect, in most uses, the proxy targets have a very simple comfiguration, just enough to let the proxy agent have access. The proxy agent has as much access configuration as a master agent or a monolithic agent would in the same place. The proxy agent than has a mapping from its various accesses to each proxy target. This is commonly just a single bit, access or no access, but may be more complex if, and only if, necessary for a particular proxy target. So, we have to advise a way to define operations of claster of of SNMP agents sharing common admin database before this idea will become viable If Aleksey's idea of bypassing proxy forwarding is used, then something like this is required. We'd then need a standard way to pass around access control information (and secure it?) so proxy targets written by different people with different SNMP packages could all play together. 2. Proxy performance over-kill. Just think about it, in order to just forward packet proxy-agent has to to parse wrapper and decrypt PDU then, it has to encrypt PDU and rebuild wrapper. And it has to maintain database of outstanding requests in order to properly forward responses. The varbind list doesn't have to be decoded. The PDU wouldn't except you need access to the req-id and some security schemes want to know the PDU type. The database of outstanding requests is definately needed. The pain there is figuring out when to garbage collect entries. IMHO, forwarding has to be done much cheaper. I want numbers and a good explanation of why those numbers were too slow before I sign up for this. As compared with sub-agents' optimal case --- only a single sub-agent is involved --- proxy forwarding ought to be equivalent. Aleksey's scheme for bypassing the forwarding step is clearly faster, at the cost of pushing the access controls out to all the proxy targets and the savings of not having to maintain an outstanding request table in the proxy agent. 3. Autodiscovery. snmpORTable is very weak mechanism to present functionality provided by sub-agent especially if sub-agents can come and go. Agree. If the working group chooses proxy as the appropriate solution space for agent multiplexing, this will be its real work. I assume there'll be a proxy table of some sort and a MIB to go with it. We'll want to work out a garbage collection strategy for this table, for instance Aleksey's idea about the proxy agent polling the proxy target periodically, maybe augmented with knowledge about failures and garbage collection in the outstanding requests table. We also need registration. Probably just through the MIB for the proxy table. Dave   Delivery-Date: Tue, 21 Nov 1995 15:34:28 -0500 Received: (from daemon@localhost) by fv.com (8.7.1/8.7.1) id PAA06652 for X-agentx-local; Tue, 21 Nov 1995 15:34:28 -0500 (EST) Received: from vader.premisys.com (vader.premisys.com [199.182.239.1]) by fv.com (8.7.1/8.7.1) with SMTP id PAA06447 for ; Tue, 21 Nov 1995 15:33:43 -0500 (EST) Received: from jostein.premisys.com (jostein.premisys.com [199.190.211.254]) by vader.premisys.com (8.6.9/8.6.9) with SMTP id MAA11323 for ; Tue, 21 Nov 1995 12:33:35 -0800 Received: by jostein.premisys.com with Microsoft Mail id <01BAB80D.7BB2A1E0@jostein.premisys.com>; Tue, 21 Nov 1995 12:32:55 -0800 Message-ID: <01BAB80D.7BB2A1E0@jostein.premisys.com> From: Jostein Eklund To: "'agentx@fv.com'" Subject: How to unsubscribe Date: Tue, 21 Nov 1995 12:32:50 -0800 Return-Receipt-To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi As some of you already know, I have been trying to unsubscribe from this = group since yesterday. I have now come to the point where I have sent = what I believe is the correct unsubscribe message to = agentx-request@fv.com. The problem is that the server responds with that I am not a subscriber, = yet I still get messages!!!   Delivery-Date: Tue, 21 Nov 1995 16:45:07 -0500 Received: (from daemon@localhost) by fv.com (8.7.1/8.7.1) id QAA19042 for X-agentx-local; Tue, 21 Nov 1995 16:45:05 -0500 (EST) Received: from mail2.digital.com (mail2.digital.com [204.123.2.56]) by fv.com (8.7.1/8.7.1) with SMTP id QAA19034 for ; Tue, 21 Nov 1995 16:45:04 -0500 (EST) From: romanov@nacto.lkg.dec.com Received: from nacto1.nacto.lkg.dec.com by mail2.digital.com; (5.65 EXP 4/12/95 for V3.2/1.0/WV) id AA16253; Tue, 21 Nov 1995 13:36:21 -0800 Received: from kalvi.nacto.lkg.dec.com by nacto1.nacto.lkg.dec.com with SMTP id AA09709; Tue, 21 Nov 1995 16:36:14 -0500 Received: by kalvi.nacto.lkg.dec.com (5.65/4.7) id AA22412; Tue, 21 Nov 1995 16:36:13 -0500 Message-Id: <9511212136.AA22412@kalvi.nacto.lkg.dec.com> Subject: Re: What about Requirements? To: dab@epilogue.com (David Bridgham) Date: Tue, 21 Nov 1995 16:36:13 -0500 (EST) Cc: agentx@fv.com In-Reply-To: <9511211519.aa24556@quern.epilogue.com> from "David Bridgham" at Nov 21, 95 01:10:25 pm X-Mailer: ELM [version 2.4 PL20] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit > Claster-agents: > > I'd like a new term but did you mean, perhaps, "cluster"? Forgive me my ignorance :(:(:(. > I don't > know if this is what Aleksey was talking about, but there are two > types of proxies. Not different in the protocol, but different in > usage. One proxy, the kind that most people seem to think of when > they hear the term, is to a proxy target that's usually another > device, perhaps the proxy protocol isn't even SNMP. The manager > probably wants to display this as a separate entity. > > The other proxy is when proxies are used for agent extensibility. > Here the proxy targert is usually in the same box as the proxy agent > and the manager may wish to mush all the data together and display it > as a single entity. Here I was talking about how proxies can be used (rather what have to be done in order to make proxy-like solution usable) for agent extnsibility and only about it (it is posted on agentx list, BTW). I would like to draw everybody's attention that I am not proposing to replace proxies, I am talking about using proxy-like solution for agent extensibility. > 1. Administrative over-kill. Each proxied-agent is full-blown SNMP agent > with administrative parameters which are set and maintained > independently on per sub-agent basis. Proxy agent has to keep > potentially huge (just think about 100 sub-agents with 10 > contexts in each with 10 users per context) proxy database > allowing mapping external admin paramters to sub-agent parameters. > And all this stuff (with sub-agents which can dynamically come > and go) has to be maintained by controlling NMS. > > I suspect, in most uses, the proxy targets have a very simple > comfiguration, just enough to let the proxy agent have access. The > proxy agent has as much access configuration as a master agent or a > monolithic agent would in the same place. The proxy agent than has a > mapping from its various accesses to each proxy target. This is > commonly just a single bit, access or no access, but may be more > complex if, and only if, necessary for a particular proxy target. It is clear necessity if we are going to use them for agent extensibility. And it seems like additional complexity of proxy configuraitons is unavoidable part of proxy standartisation a la SNMPv2-Classic, which is our current level of intentions here. > So, we have to advise a way to define operations of claster of > of SNMP agents sharing common admin database before this idea > will become viable > > If Aleksey's idea of bypassing proxy forwarding is used, then > something like this is required. We'd then need a standard way to > pass around access control information (and secure it?) so proxy > targets written by different people with different SNMP packages could > all play together. Standartization means, there should be standard way. As I see it the only way to change admin database in sub-agents should be replacement of the whole database in a single (secure) SET operation from master-agent. In order to do so: database has to be small, binary format has to be advise, any error in this SET have to force sub-agent shutdown and restart. It is not the only way to do so, but this is how I see today. > 2. Proxy performance over-kill. Just think about it, in order to > just forward packet proxy-agent has to to parse wrapper and > decrypt PDU then, it has to encrypt PDU and rebuild wrapper. And ^^^^^^^ ^^^^^^^ > it has to maintain database of outstanding requests in order to > properly forward responses. > > The varbind list doesn't have to be decoded. The PDU wouldn't except > you need access to the req-id and some security schemes want to know > the PDU type 1. I am talking about decryption 2. All schemes (including unsecure ones) have to know PDU type and req-id in order to properly forward responses. > The database of outstanding requests is definately needed. The pain > there is figuring out when to garbage collect entries. > > IMHO, forwarding has to be done much cheaper. > > I want numbers and a good explanation of why those numbers were too > slow before I sign up for this. As compared with sub-agents' optimal > case --- only a single sub-agent is involved --- proxy forwarding > ought to be equivalent. Aleksey's scheme for bypassing the forwarding > step is clearly faster, at the cost of pushing the access controls out > to all the proxy targets and the savings of not having to maintain an > outstanding request table in the proxy agent. Also not: 1. Maintaining separate admin database for each sub-agent 2. Maintaining huge proxy database on master agent 3. Having 2 extra MD5-zation per transaction 4. having 2 extra de-MD5-zation per transaction 5. Having 2 extra decryptions per trasaction 6. Having 2 extra encryptions per transactions 7. Having 2 extra send operations per transaction 8. Having 2 extra receive operations per transaction > 3. Autodiscovery. snmpORTable is very weak mechanism to present > functionality provided by sub-agent especially if sub-agents > can come and go. > > Agree. If the working group chooses proxy as the appropriate solution > space for agent multiplexing, this will be its real work. I assume > there'll be a proxy table of some sort and a MIB to go with it. We'll > want to work out a garbage collection strategy for this table, for > instance Aleksey's idea about the proxy agent polling the proxy target > periodically, maybe augmented with knowledge about failures and > garbage collection in the outstanding requests table. > > We also need registration. Probably just through the MIB for the > proxy table. Naturally. > Dave Aleksey   Delivery-Date: Tue, 21 Nov 1995 17:53:09 -0500 Received: (from daemon@localhost) by fv.com (8.7.1/8.7.1) id RAA02645 for X-agentx-local; Tue, 21 Nov 1995 17:53:07 -0500 (EST) Received: from epilogue.com (quern.epilogue.com [128.224.1.136]) by fv.com (8.7.1/8.7.1) with SMTP id RAA02631 for ; Tue, 21 Nov 1995 17:53:03 -0500 (EST) Received: from dab.gate.epilogue.com with DMSP Date: Tue, 21 Nov 95 15:48:27 -0700 From: David Bridgham To: agentx@fv.com In-reply-to: "romanov@nacto.lkg.dec.com"'s message of Tue, 21 Nov 1995 16:36:13 -0500 (EST) Subject: Re: What about Requirements? Sender: dab@epilogue.com Repository: quern.epilogue.com Originating-client: gate.epilogue.com Message-ID: <9511211749.aa25650@quern.epilogue.com> > I'd like a new term but did you mean, perhaps, "cluster"? Forgive me my ignorance :(:(:(. No forgiveness needed. I cringe when I read my own postings, they're so full of typos and grammar errors and this is the language I grew up with. I would like to draw everybody's attention that I am not proposing to replace proxies, I am talking about using proxy-like solution for agent extensibility. Understood. Standartization means, there should be standard way. As I see it the only way to change admin database in sub-agents should be replacement of the whole database in a single (secure) SET operation from master-agent. In order to do so: database has to be small, binary format has to be advise, any error in this SET have to force sub-agent shutdown and restart. It is not the only way to do so, but this is how I see today. This might be the requirement that kills this approach. 1. I am talking about decryption I didn't read your message closely enough. You're right, of course. 2. All schemes (including unsecure ones) have to know PDU type and req-id in order to properly forward responses. Why the PDU type? It doesn't matter though, we're not going to change that part of SNMP. Also not: 1. Maintaining separate admin database for each sub-agent 2. Maintaining huge proxy database on master agent 3. Having 2 extra MD5-zation per transaction 4. having 2 extra de-MD5-zation per transaction 5. Having 2 extra decryptions per trasaction 6. Having 2 extra encryptions per transactions 7. Having 2 extra send operations per transaction 8. Having 2 extra receive operations per transaction Another point here is that with proxy forwarding the extra MD5 and encryption/decryption steps are not necessarily required. If a host has its own IPC mechanism that is sufficiently secure for its purposes, then there's no need to throw in SNMP security. Even if the IPC is UDP to localhost, if the SNMP code is sufficiently sure that the packets aren't leaving the host, that might be enough in many cases. Again, the flexiblity is there, if needed, to turn on more security and spend the effort on the extra configuration. Dave   Delivery-Date: Tue, 21 Nov 1995 20:02:39 -0500 Received: (from daemon@localhost) by fv.com (8.7.1/8.7.1) id UAA27162 for X-agentx-local; Tue, 21 Nov 1995 20:02:38 -0500 (EST) Received: from mail2.digital.com (mail2.digital.com [204.123.2.56]) by fv.com (8.7.1/8.7.1) with SMTP id UAA27152 for ; Tue, 21 Nov 1995 20:02:36 -0500 (EST) From: romanov@nacto.lkg.dec.com Received: from nacto1.nacto.lkg.dec.com by mail2.digital.com; (5.65 EXP 4/12/95 for V3.2/1.0/WV) id AA05046; Tue, 21 Nov 1995 16:58:50 -0800 Received: from kalvi.nacto.lkg.dec.com by nacto1.nacto.lkg.dec.com with SMTP id AA12916; Tue, 21 Nov 1995 19:58:47 -0500 Received: by kalvi.nacto.lkg.dec.com (5.65/4.7) id AA22651; Tue, 21 Nov 1995 19:58:44 -0500 Message-Id: <9511220058.AA22651@kalvi.nacto.lkg.dec.com> Subject: Re: What about Requirements? To: dab@epilogue.com (David Bridgham) Date: Tue, 21 Nov 1995 19:58:43 -0500 (EST) Cc: agentx@fv.com In-Reply-To: <9511211749.aa25650@quern.epilogue.com> from "David Bridgham" at Nov 21, 95 03:48:27 pm X-Mailer: ELM [version 2.4 PL20] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit > Standartization means, there should be standard way. As I see it > the only way to change admin database in sub-agents should be > replacement of the whole database in a single (secure) SET > operation from master-agent. In order to do so: database has to be > small, binary format has to be advise, any error in this SET > have to force sub-agent shutdown and restart. It is not the only > way to do so, but this is how I see today. > > This might be the requirement that kills this approach. It is not requirement it is on of possible means of achivement admin database distributuon across all sub-agents involved. > > 1. I am talking about decryption > > I didn't read your message closely enough. You're right, of course. > > 2. All schemes (including unsecure ones) have to know PDU type and > req-id in order to properly forward responses. > > Why the PDU type? It doesn't matter though, we're not going to change > that part of SNMP. ???? Proxy has to decode PDU in order to figure out what is in the packet from NMS: response to inform request or request and what in the packet from sub-agent: inform request, trap or response. > Also not: > > 1. Maintaining separate admin database for each sub-agent > 2. Maintaining huge proxy database on master agent > 3. Having 2 extra MD5-zation per transaction > 4. having 2 extra de-MD5-zation per transaction > 5. Having 2 extra decryptions per trasaction > 6. Having 2 extra encryptions per transactions > 7. Having 2 extra send operations per transaction > 8. Having 2 extra receive operations per transaction > > Another point here is that with proxy forwarding the extra MD5 and > encryption/decryption steps are not necessarily required. If a host > has its own IPC mechanism that is sufficiently secure for its > purposes, then there's no need to throw in SNMP security. Even if the > IPC is UDP to localhost, if the SNMP code is sufficiently sure that > the packets aren't leaving the host, that might be enough in many > cases. Again, the flexiblity is there, if needed, to turn on more > security and spend the effort on the extra configuration. ?????? As far as I understand situation, it is common desire for extensibility mechanism to reach outside the box master-agent is running. We can gain a lot of simplicity by relaxing this requirement, however, as far as I know it is still there. > Dave Aleksey   Delivery-Date: Tue, 21 Nov 1995 20:17:28 -0500 Received: (from daemon@localhost) by fv.com (8.7.1/8.7.1) id UAA00182 for X-agentx-local; Tue, 21 Nov 1995 20:17:27 -0500 (EST) Received: from epilogue.com (quern.epilogue.com [128.224.1.136]) by fv.com (8.7.1/8.7.1) with SMTP id UAA00177 for ; Tue, 21 Nov 1995 20:17:25 -0500 (EST) Received: from dab.gate.epilogue.com with DMSP Date: Tue, 21 Nov 95 18:15:54 -0700 From: David Bridgham To: agentx@fv.com In-reply-to: "romanov@nacto.lkg.dec.com"'s message of Tue, 21 Nov 1995 19:58:43 -0500 (EST) Subject: Re: What about Requirements? Sender: dab@epilogue.com Repository: quern.epilogue.com Originating-client: gate.epilogue.com Message-ID: <9511212016.aa26620@quern.epilogue.com> ?????? As far as I understand situation, it is common desire for extensibility mechanism to reach outside the box master-agent is running. I hadn't heard this. In those cases, yes, you'd need stronger security and all the configuration that goes with it. I'm still assuming that the 95% case is multiple agents on a unix box and that can still benefit from a simplified, host only security approach. Dave   Delivery-Date: Mon, 27 Nov 1995 14:24:44 -0500 Received: (from daemon@localhost) by fv.com (8.7.1/8.7.1) id OAA24151 for X-agentx-local; Mon, 27 Nov 1995 14:24:44 -0500 (EST) Received: from tsunami.dbc.mtview.ca.us (tsunami.dbc.mtview.ca.us [204.250.93.202]) by fv.com (8.7.1/8.7.1) with ESMTP id OAA24143 for ; Mon, 27 Nov 1995 14:24:42 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by tsunami.dbc.mtview.ca.us (8.6.10/8.6.10) with ESMTP id LAA21069 for ; Mon, 27 Nov 1995 11:23:11 -0800 To: agentx@fv.com Subject: draft agenda Reply-To: agentx@fv.com MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----- =_aaaaaaaaaa0" Content-ID: <21065.817500190.0@dbc.mtview.ca.us> Date: Mon, 27 Nov 1995 11:23:10 -0800 Message-ID: <21066.817500190@dbc.mtview.ca.us> From: Marshall Rose ------- =_aaaaaaaaaa0 Content-Type: text/plain; charset="us-ascii" Content-ID: <21065.817500190.1@dbc.mtview.ca.us> your comments are solicited... /mtr ------- =_aaaaaaaaaa0 Content-Type: text/plain; charset="us-ascii" Content-ID: <21065.817500190.2@dbc.mtview.ca.us> Content-Description: draft agenda Draft Agenda of the SNMP Agent Extensibility (agentx) Working Group of the 34th IETF Session 1: Wednesday, December 6, 1995, 1300-1500 - Introduction and Review of the Charter The chair will present the working group's charter and provide a history of IETF discussion and publication in this area - Presentations by Interested Parties (singing afterwards, optional) All particpants are invited to make prepared, or impromptu, presentations to the working group, answering these three questions: - what are the issues which are driving agent extensibility? - what technologies exist which address these issues? - what are the real-world experiences with these technologies? By convention, participants with prepared presentations will present first. (Participants who have prepared presentations, but are unable to attend, may e-mail their presentation, in postscript format, to the chair by november 30; the chair will make their presentation in a neutral fashion.) - Group Discussion of Presentations Questions of a clarifying nature may be asked during each individual presentation; however, all other questions should be held until all presentations are heard. At that time, questions and discussions on all presentations and topics will be held. Session 2: Friday, December 8, 1995, 0900-1130 - Group Discussion of Presentations (continued) (if time requires) - Review of Problems and Approaches In real-time, the group will attempt to derive a taxonomy of the problems, approaches, and experiences presented and discussed. - Group Discussion on How to Proceed in a timely fashion. ------- =_aaaaaaaaaa0--   Delivery-Date: Wed, 29 Nov 1995 09:05:38 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.1/8.7.1) id IAA10296 for X-agentx-local; Wed, 29 Nov 1995 08:39:11 -0800 (PST) Received: from yukinojo.fv.com (yukinojo.fv.com [204.250.90.3]) by zloty.fv.com (8.7.1/8.7.1) with ESMTP id IAA10290 for ; Wed, 29 Nov 1995 08:39:10 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by yukinojo.fv.com (8.7.1/8.7.1) with ESMTP id IAA00583 for ; Wed, 29 Nov 1995 08:38:44 -0800 (PST) From: Marshall Rose To: agentx@fv.com Subject: test message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <581.817663124.1@dbc.fv.com> Date: Wed, 29 Nov 1995 08:38:44 -0800 Message-ID: <582.817663124@dbc.fv.com> Sender: mrose@dbc.fv.com please ignore this message. we moved the mail/ftp server yesterday and although everything else is working just fine, i wanted an independent confirmation that there aren't any problems. thanks! /mtr   Delivery-Date: Thu, 30 Nov 1995 08:10:25 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.1/8.7.1) id HAA00657 for X-agentx-local; Thu, 30 Nov 1995 07:25:58 -0800 (PST) Received: from mail1.digital.com (mail1.digital.com [204.123.2.50]) by zloty.fv.com (8.7.1/8.7.1) with SMTP id HAA00644 for ; Thu, 30 Nov 1995 07:25:55 -0800 (PST) From: romanov@nacto.lkg.dec.com Received: from nacto1.nacto.lkg.dec.com by mail1.digital.com; (5.65 EXP 4/12/95 for V3.2/1.0/WV) id AA09292; Thu, 30 Nov 1995 07:19:35 -0800 Received: from kalvi.nacto.lkg.dec.com by nacto1.nacto.lkg.dec.com with SMTP id AA05916; Thu, 30 Nov 1995 10:19:30 -0500 Received: by kalvi.nacto.lkg.dec.com (5.65/4.7) id AA01614; Thu, 30 Nov 1995 10:19:30 -0500 Message-Id: <9511301519.AA01614@kalvi.nacto.lkg.dec.com> Subject: Re: questions about sysUpTime To: reijo01@ingres.com (Joseph Reilly) Date: Thu, 30 Nov 1995 10:19:29 -0500 (EST) Cc: snmpv2@tis.com, agentx@fv.com In-Reply-To: <9511282204.AA27592@usilsu72.ingres.com> from "Joseph Reilly" at Nov 28, 95 05:04:17 pm X-Mailer: ELM [version 2.4 PL20] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit > > Hello, > I have several questions concerning sysUpTime, master agents and sub- > agents. I know there are several protocols for master-subagent architeture. > I am hoping the answers to my questions hold true for all protocols. > Is a master agent responsible for maintaining the system table > within MIB-II and thus sysUpTime? Generally it is supposed to be so. > If I'm writing a subagent that will support the Network Services > Monitoring MIB and thus the object applUptime, how is my sub-agent supposed > to obtain the value of sysUpTime? Is the master-subagent protocol supposed > to supply a call to obtain this value? Or does my subagent have to act like > a manager and issue a get request to the very box it is running on? It seems to me that this should not be a source of a major worry: 1. If we are talking about per-variable extensibility then sysUpTime it will be read it from master agent anyway. 2. If we are talking about per-packet extensibility then sysUpTime will be read from sub-agent. BTW SNMPv2(all flavors) does not require for sub-agent's sysUpTime to be the same as master-agent's sysUpTime. And in any case providing for sysUpTime synchronization does not seem difficult ever if it is required. There is a much funnier thing to solve: how to establish ifIndex numbering across all sub-agents :) once one would consider following: 1. None of the master/sub -agents has information about all interfaces of the system. 2. It is a normal behavior for interfaces to be created and to disappear on the fly. 3. Having different ifIndex layout per-subagent based on per-packet multiplexing will definitely screw-up NMS. Have fun :). > Joe Reilly Aleksey