From owner-agentx@dorothy.bmc.com Thu Apr 5 03:56:06 2001 Received: from creeper.bmc.com ([198.207.223.246]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA24936 for ; Thu, 5 Apr 2001 03:56:05 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by creeper.bmc.com (8.10.2/8.10.2) with ESMTP id f357sHC13930; Thu, 5 Apr 2001 02:54:17 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id WAA16329 for agentx-list; Wed, 4 Apr 2001 22:13:50 -0700 (PDT) Received: from babbler.bmc.com (babbler.bmc.com [172.17.0.116]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id WAA16324 for ; Wed, 4 Apr 2001 22:13:46 -0700 (PDT) From: Bob.Natale@AppliedSNMP.com Received: from fw-us-hou-9.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with SMTP id f355HZI28224 for ; Thu, 5 Apr 2001 00:17:35 -0500 (CDT) Received: from c001-h008.c001.snv.cp.net ([209.228.32.122]) by fw-us-hou-9.bmc.com; Thu, 05 Apr 2001 00:14:49 +0000 (CST) Received: (cpmta 692 invoked from network); 4 Apr 2001 22:08:01 -0700 Received: from unknown (HELO bnatale.AppliedSNMP.com) (38.203.142.102) by smtp.appliedsnmp.com (209.228.32.122) with SMTP; 4 Apr 2001 22:08:01 -0700 X-Sent: 5 Apr 2001 05:08:01 GMT Message-Id: <5.0.1.4.2.20010405010933.02549650@plymouth.acec.com> X-Sender: bnatale@plymouth.acec.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.1 Date: Thu, 05 Apr 2001 01:10:25 -0400 To: agentx@dorothy.bmc.com Subject: Advancing AgentX from Proposed to Draft Standard status Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-agentx@dorothy.bmc.com Precedence: bulk List-Id: IETF Agentx Working Group mailing list Hi everyone, Well, since we are safely in the period between the required six months at Proposed Standard status for the AgentX protocol spec (RFC2741) and MIB (RFC2742) and the 24-month initial duration limit for staying at a given maturity level other than Internet Standard, it is time for us to move formally toward progressing these specs to Draft Standard status. To move to the DS level we need "at least two independent and interoperable implementations from different code bases" with "sufficient successful operational experience" with them. I am aware of at least two commercial and two "non-commercial" implementations at this time (and have heard of others...I am not directly associated with any of the implementations). The Working Group chair is responsible for documenting those facts, in sufficient detail, for consideration by the IESG. Therefore, I am asking all implementors to prepare implementation reports (format to follow) and for anyone who has used any AgentX implementations (master agents and/or sub-agents) to prepare an interoperability report (format to follow). I will provide separate report formats for the protocol spec and the MIB. If at all possible, we would like to have such reports posted to the AgentX list but, if that is not workable for whatever reasons in any given case, please send the information to me privately and I will do my best to ensure confidentiality. We are allowed to make "minor revisions" to the specs in going from the PS level to the DS level. What is "minor" is a judgment call (made by the IESG, ultimately) but is usually obvious at the WG consensus level. Anyone may suggest necessary and/or desirable revisions to the specs. I will do my best to go back over the e-mail record and Dave Keeney's web site info to ensure that we capture any suggested mods that have been discussed since publication of the RFCs last year. Contributions from the list to that effort are warmly invited! Lastly, I will propose a charter/milestone update for the A-Ds to consider that will be focused on completing the work outlined above prior to the 51st IETF meeting (London, Aug 5-10, 2001). Finally (higher-order than "lastly"! :-), I sincerely request that all active WG members -- especially the authors, editors, and implementors -- take proactive measures to make sure that I keep this process moving per the above outline (or some later revised version of it). Assistance will be welcomed, nagging may be required (and will be appreciated if and when needed!). Feel free to post any questions or suggestions. Cordially, BobN AgentX WG Chair From owner-agentx@dorothy.bmc.com Thu Apr 5 15:05:24 2001 Received: from creeper.bmc.com ([198.207.223.246]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA11322 for ; Thu, 5 Apr 2001 15:05:23 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by creeper.bmc.com (8.10.2/8.10.2) with ESMTP id f35J31S05231; Thu, 5 Apr 2001 14:03:01 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id MAA29380 for agentx-list; Thu, 5 Apr 2001 12:01:13 -0700 (PDT) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id MAA29367 for agentx@dorothy.bmc.com; Thu, 5 Apr 2001 12:01:02 -0700 (PDT) Date: Thu, 5 Apr 2001 12:01:02 -0700 (PDT) From: Randy Presuhn Message-Id: <200104051901.MAA29367@dorothy.bmc.com> To: agentx@dorothy.bmc.com Subject: Fwd: Timeout during a commit-set operation Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-agentx@dorothy.bmc.com Precedence: bulk List-Id: IETF Agentx Working Group mailing list X-MIME-Autoconverted: from 8bit to quoted-printable by creeper.bmc.com id f35J31S05231 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id PAA11322 Hi - I'm forwarding a posting to the agentx mailing list. I've added this subscriber's alternate address to the agentx "posters" list. ------------------------------------------------------- Randy Presuhn randy_presuhn@bmc.com Voice: +1 408 546-1006 BMC Software, Inc. 1-3141 Fax: +1 408 965-0359 2141 North First Street http://www.bmc.com/ San José, California 95131 USA ------------------------------------------------------- My opinions and BMC's are independent variables. ------------------------------------------------------- |Received: from babbler.bmc.com (babbler.bmc.com [172.17.0.116]) | by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id FAA17096 | for ; Thu, 5 Apr 2001 05:36:08 -0700 (PDT) |Received: from fw-us-hou-9.bmc.com (localhost [127.0.0.1]) | by babbler.bmc.com (8.10.2/8.10.2) with SMTP id f35Cdvj07621 | for ; Thu, 5 Apr 2001 07:39:57 -0500 (CDT) |Received: from netmail2.alcatel.com ([128.251.168.51]) by fw-us-hou-9.bmc.com; Thu, 05 Apr 2001 07:37:06 +0000 (CST) |Received: from postal.adn.alcatel.com (workstation.alcatel.com [198.205.33.79] (may be forged)) | by netmail2.alcatel.com (8.9.1/8.9.1) with ESMTP id HAA15354 | for ; Thu, 5 Apr 2001 07:35:50 -0500 (CDT) |Received: from usa.alcatel.com ([198.205.41.133]) by postal.adn.alcatel.com | (Netscape Messaging Server 3.6) with ESMTP id AAA3F16; | Thu, 5 Apr 2001 08:48:31 -0400 |Sender: kandrews@netmail2.alcatel.com |Message-ID: <3ACC65E0.E3509F0A@usa.alcatel.com> |Date: Thu, 05 Apr 2001 08:32:32 -0400 |From: Ken Andrews |Organization: Alcatel |X-Mailer: Mozilla 4.61 [en] (X11; U; SunOS 5.7 sun4u) |X-Accept-Language: en |MIME-Version: 1.0 |To: AgentX |Subject: Timeout during a commit-set operation |Content-Type: text/plain; charset=us-ascii |Content-Transfer-Encoding: 7bit | |Hello, | |We are implementing a core router using agentX to connect a SNMPv3 |Master Agent with 20 or so sub-agents. | |One of the situations that I'm seeing is occasionally one of the |sub-agents fails to respond to a commit-set. After its timeout |period the Master Agent sends the SNMP manager a get response with |an error code 15 (Undo Failed) and sends the sub-agent a cleanup. | |RFC 2741 sec 7.2.5.1 states that the action of a master agent on |a timeout is implementation specific but I think that in the case |of a commit failure it needs to be more clear. | |As far as I can tell the best thing to do is to send the cleanup |and hope that the sub-agent can deal with it. | |regards, |Ken | |-- |Ken Andrews ken.andrews@adn.alcatel.com |New Office # 703-679-6476 |New Fax # 703-679-6450 |We all ride the same road | From owner-agentx@dorothy.bmc.com Thu Apr 5 15:25:00 2001 Received: from creeper.bmc.com ([198.207.223.246]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA12026 for ; Thu, 5 Apr 2001 15:25:00 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by creeper.bmc.com (8.10.2/8.10.2) with ESMTP id f35JEYU06115; Thu, 5 Apr 2001 14:14:34 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id MAA04228 for agentx-list; Thu, 5 Apr 2001 12:13:15 -0700 (PDT) Received: from creeper.bmc.com (creeper.bmc.com [172.17.1.166]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id MAA03928 for ; Thu, 5 Apr 2001 12:13:03 -0700 (PDT) Received: from ec03-hou.bmc.com (localhost [127.0.0.1]) by creeper.bmc.com (8.10.2/8.10.2) with ESMTP id f35JDqi06067 for ; Thu, 5 Apr 2001 14:13:52 -0500 (CDT) Received: by ec03-hou.bmc.com with Internet Mail Service (5.5.2653.19) id <2KPRWC6J>; Thu, 5 Apr 2001 14:11:31 -0500 Message-ID: From: "Ayers, Mike" To: agentx@dorothy.bmc.com Subject: RE: Timeout during a commit-set operation Date: Thu, 5 Apr 2001 14:13:57 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-agentx@dorothy.bmc.com Precedence: bulk List-Id: IETF Agentx Working Group mailing list > |Sender: kandrews@netmail2.alcatel.com > | > |One of the situations that I'm seeing is occasionally one of the > |sub-agents fails to respond to a commit-set. After its timeout > |period the Master Agent sends the SNMP manager a get response with > |an error code 15 (Undo Failed) and sends the sub-agent a cleanup. I don't think that this is correct. According to 7.2.5.1, the return code should be genErr due to the timeout. Next, 7.2.5.5 states that the master should sent an agentx-UndoSet-PDU to any subagent which has been sent an agentx-CommitSet-PDU, which would include the timed out subagent. > |RFC 2741 sec 7.2.5.1 states that the action of a master agent on > |a timeout is implementation specific but I think that in the case > |of a commit failure it needs to be more clear. That implementation specific behavior, I believe, generally refers to whether or not the master agent will terminate the AgentX session due to a timeout. While it is required to terminate a session after three consecutive timeouts, the master may choose to do so after only one timeout. > |As far as I can tell the best thing to do is to send the cleanup > |and hope that the sub-agent can deal with it. Agreed - provided you mean "send the undo". /|/|ike From owner-agentx@dorothy.bmc.com Thu Apr 5 23:01:18 2001 Received: from creeper.bmc.com ([198.207.223.246]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA20226 for ; Thu, 5 Apr 2001 23:01:17 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by creeper.bmc.com (8.10.2/8.10.2) with ESMTP id f362xN204685; Thu, 5 Apr 2001 21:59:23 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id TAA23847 for agentx-list; Thu, 5 Apr 2001 19:58:01 -0700 (PDT) Received: from babbler.bmc.com (babbler.bmc.com [172.17.0.116]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id TAA23840 for ; Thu, 5 Apr 2001 19:57:56 -0700 (PDT) Received: from fw-us-hou-9.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with SMTP id f3631k829698 for ; Thu, 5 Apr 2001 22:01:46 -0500 (CDT) Received: from wiprom2mx1.wipro.com ([203.197.164.41]) by fw-us-hou-9.bmc.com; Thu, 05 Apr 2001 21:59:01 +0000 (CST) Received: from m2vwall2.wipro.com (m2vwall2.wipro.com [164.164.27.52]) by wiprom2mx1.wipro.com (8.9.3+Sun/8.9.3) with SMTP id IAA04202 for ; Fri, 6 Apr 2001 08:37:02 GMT Received: from wipro.com ([192.168.176.70]) by sarovar.mail.wipro.com (Netscape Messaging Server 4.15) with ESMTP id GBCOJW00.7VG for ; Fri, 6 Apr 2001 08:34:44 +0530 Message-ID: <3ACD3275.745E6015@wipro.com> Date: Fri, 06 Apr 2001 08:35:25 +0530 From: Anju Nand Nathani Organization: Wipro Technologies X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: agentx@dorothy.bmc.com Subject: Implementing Undo cleanup pdu's Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-agentx@dorothy.bmc.com Precedence: bulk List-Id: IETF Agentx Working Group mailing list Content-Transfer-Encoding: 7bit hi, We are writing a subagent application using AgentX protocol on Linux. We are not sure how to handle the " undo " and "cleanup" pdu's - exactly how to retain the values after the commit set operation . Could these two opeartions return zero . Thanks Anju Nathani From owner-agentx@dorothy.bmc.com Wed Apr 18 15:00:40 2001 Received: from creeper.bmc.com ([198.207.223.246]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA16039 for ; Wed, 18 Apr 2001 15:00:40 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by creeper.bmc.com (8.10.2/8.10.2) with ESMTP id f3IIwlZ20388; Wed, 18 Apr 2001 13:58:48 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id LAA06335 for agentx-list; Wed, 18 Apr 2001 11:53:42 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id LAA05923 for ; Wed, 18 Apr 2001 11:53:20 -0700 (PDT) From: bob.natale@AppliedSNMP.com Received: from fw-us-hou-9.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with SMTP id f3IIpGH02811 for ; Wed, 18 Apr 2001 13:51:16 -0500 (CDT) Received: from c001-h009.c001.snv.cp.net ([209.228.32.123]) by fw-us-hou-9.bmc.com; Wed, 18 Apr 2001 13:54:25 +0000 (CST) Received: (cpmta 21471 invoked from network); 18 Apr 2001 11:54:24 -0700 Date: 18 Apr 2001 11:54:23 -0700 Message-ID: <20010418185423.21470.cpmta@c001.snv.cp.net> X-Sent: 18 Apr 2001 18:54:23 GMT Received: from [192.11.221.121] by mail.appliedsnmp.com with HTTP; 18 Apr 2001 11:54:23 PDT Content-Type: text/plain Content-Disposition: inline Mime-Version: 1.0 To: AgentX@dorothy.bmc.com X-Mailer: Web Mail 3.7.1.9 Subject: AgentX Charter/Milestone Update Sender: owner-agentx@dorothy.bmc.com Precedence: bulk List-Id: IETF Agentx Working Group mailing list Hi, The items/dates below are what I recommend we submit to the IESG and IETF Secretariat for our current work-plan. Please post any suggested revisions or comments by the end of the day this coming Friday (4/20). I will then submit this update (as may be revised via the list) and will post the implementation report format to the list on Monday (4/23). Apr 01 - Implementation reports formally solicited (Apr 23) Apr 01 - Interoperability reports formally solicited (Apr 30) May 01 - Implmentation and interoperability reports summarized (by WG Chair) and assessed via WG e-mail discussion (May 31) Jun 01 - All open issues resolved (Jun 30) Jul 01 - Modifications (if any) to documents (RFC2741 and RFC2742) completed (Jul 15) Jul 01 - Decision to advance or recycle made by WG and handed off to IESG for action (Jul 31) Aug 01 - Shutdown WG or re-charter Cordially, BobN WG Chair From owner-agentx@dorothy.bmc.com Wed Apr 18 16:20:55 2001 Received: from creeper.bmc.com ([198.207.223.246]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA17214 for ; Wed, 18 Apr 2001 16:20:55 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by creeper.bmc.com (8.10.2/8.10.2) with ESMTP id f3IKJF426867; Wed, 18 Apr 2001 15:19:15 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id NAA20251 for agentx-list; Wed, 18 Apr 2001 13:17:48 -0700 (PDT) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id NAA20245 for AgentX@dorothy.bmc.com; Wed, 18 Apr 2001 13:17:44 -0700 (PDT) Date: Wed, 18 Apr 2001 13:17:44 -0700 (PDT) From: Randy Presuhn Message-Id: <200104182017.NAA20245@dorothy.bmc.com> To: AgentX@dorothy.bmc.com Subject: Re: AgentX Charter/Milestone Update Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-agentx@dorothy.bmc.com Precedence: bulk List-Id: IETF Agentx Working Group mailing list X-MIME-Autoconverted: from 8bit to quoted-printable by creeper.bmc.com id f3IKJF426867 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id QAA17214 Hi - > From: bob.natale@AppliedSNMP.com > Date: 18 Apr 2001 11:54:23 -0700 > Message-ID: <20010418185423.21470.cpmta@c001.snv.cp.net> > To: AgentX@dorothy.bmc.com > Subject: AgentX Charter/Milestone Update ... > The items/dates below are what I recommend we submit to the IESG and IETF Secretariat for our current work-plan. Please post any suggested revisions or comments by the end of the day this coming Friday (4/20). I will then submit this update (as may be revised via the list) and will post the implementation report format to the list on Monday (4/23). > > Apr 01 - Implementation reports formally solicited (Apr 23) > Apr 01 - Interoperability reports formally solicited (Apr 30) > May 01 - Implmentation and interoperability reports summarized > (by WG Chair) and assessed via WG e-mail discussion (May 31) > Jun 01 - All open issues resolved (Jun 30) > Jul 01 - Modifications (if any) to documents (RFC2741 and RFC2742) completed (Jul 15) > Jul 01 - Decision to advance or recycle made by WG and handed off to IESG for action (Jul 31) > Aug 01 - Shutdown WG or re-charter ... Any thoughts on how SMING and EOS might impact this? ------------------------------------------------------- Randy Presuhn randy_presuhn@bmc.com Voice: +1 408 546-1006 BMC Software, Inc. 1-3141 Fax: +1 408 965-0359 2141 North First Street http://www.bmc.com/ San José, California 95131 USA ------------------------------------------------------- My opinions and BMC's are independent variables. ------------------------------------------------------- From owner-agentx@dorothy.bmc.com Wed Apr 18 18:23:20 2001 Received: from creeper.bmc.com ([198.207.223.246]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA18989 for ; Wed, 18 Apr 2001 18:23:20 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by creeper.bmc.com (8.10.2/8.10.2) with ESMTP id f3IMLmj07096; Wed, 18 Apr 2001 17:21:48 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id PAA21642 for agentx-list; Wed, 18 Apr 2001 15:20:17 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id PAA21637 for ; Wed, 18 Apr 2001 15:20:12 -0700 (PDT) Received: from fw-us-hou-9.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with SMTP id f3IMI9o25476 for ; Wed, 18 Apr 2001 17:18:09 -0500 (CDT) Received: from dns2.hardaker.davis.ca.us ([168.150.190.2]) by fw-us-hou-9.bmc.com; Wed, 18 Apr 2001 17:21:17 +0000 (CST) Received: (from hardaker@localhost) by wanderer.hardakers.net (8.9.3/8.9.3) id PAA20721; Wed, 18 Apr 2001 15:20:56 -0700 X-Authentication-Warning: wanderer.hardakers.net: hardaker set sender to wes@hardakers.net using -f To: bob.natale@AppliedSNMP.com Cc: AgentX@dorothy.bmc.com Subject: Re: AgentX Charter/Milestone Update References: <20010418185423.21470.cpmta@c001.snv.cp.net> From: Wes Hardaker X-URL: http://dcas.ucdavis.edu/~hardaker Organization: Network Associates - NAI Labs X-Face: #qW^}a%m*T^{A:Cp}$R\"38+d}41-Z}uU8,r%F#c#s:~Nzp0G9](s?,K49KJ]s"*7gvRgA SrAvQc4@/}L7Qc=w{)]ACO\R{LF@S{pXfojjjGg6c;q6{~C}CxC^^&~(F]`1W)%9j/iS/ IM",B1M.?{w8ckLTYD'`|kTr\i\cgY)P4 Date: 18 Apr 2001 15:20:55 -0700 In-Reply-To: <20010418185423.21470.cpmta@c001.snv.cp.net> (bob.natale@AppliedSNMP.com's message of "18 Apr 2001 11:54:23 -0700") Message-ID: Lines: 22 User-Agent: Gnus/5.090001 (Oort Gnus v0.01) XEmacs/21.2 (Terspichore) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-agentx@dorothy.bmc.com Precedence: bulk List-Id: IETF Agentx Working Group mailing list >>>>> On 18 Apr 2001 11:54:23 -0700, bob.natale@AppliedSNMP.com said: bob> Jun 01 - All open issues resolved (Jun 30) There might be a few issues that need to be thought about and discarded or acted upon. Specifically, it is not possible to implement certain MIBs inside a strict AgentX subagent implementation. Examples are the DISMAN-EVENT-MIB (needs access to authentication information and bi-directional requests) and the SNMPCONF-PM-MIB (has (will have) a "capabilities" table which is similar in nature to the sysORTable (but different, of course) and no way of registering entries to it easily via agentx, unless they change their indexing to avoid illegal information duplications [which I've requested to them that they do]). Makes me think that we should either support another set of protocol operations, or leave room for extensibility in some way that can be defined by future specification documents that want to mention how to implement "something" otherwise impossible under the AgentX protocol. -- "Ninjas aren't dangerous. They're more afraid of you than you are of them." From owner-agentx@dorothy.bmc.com Wed Apr 18 18:34:25 2001 Received: from creeper.bmc.com ([198.207.223.246]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA19117 for ; Wed, 18 Apr 2001 18:34:25 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by creeper.bmc.com (8.10.2/8.10.2) with ESMTP id f3IMXLW08083; Wed, 18 Apr 2001 17:33:21 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id PAA22157 for agentx-list; Wed, 18 Apr 2001 15:32:02 -0700 (PDT) Received: from babbler.bmc.com (babbler.bmc.com [172.17.0.116]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id PAA22144 for ; Wed, 18 Apr 2001 15:31:55 -0700 (PDT) Received: from ec03-hou.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id f3IMZra16022 for ; Wed, 18 Apr 2001 17:35:53 -0500 (CDT) Received: by ec03-hou.bmc.com with Internet Mail Service (5.5.2653.19) id <2KPRZYT0>; Wed, 18 Apr 2001 17:30:09 -0500 Message-ID: From: "Ayers, Mike" To: AgentX@dorothy.bmc.com Subject: RE: AgentX Charter/Milestone Update Date: Wed, 18 Apr 2001 17:32:45 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-agentx@dorothy.bmc.com Precedence: bulk List-Id: IETF Agentx Working Group mailing list > From: Wes Hardaker [mailto:wes@hardakers.net] > > >>>>> On 18 Apr 2001 11:54:23 -0700, bob.natale@AppliedSNMP.com said: > > bob> Jun 01 - All open issues resolved (Jun 30) > > There might be a few issues that need to be thought about and > discarded or acted upon. Specifically, it is not possible to > implement certain MIBs inside a strict AgentX subagent implementation. > Examples are the DISMAN-EVENT-MIB (needs access to authentication > information and bi-directional requests) and the SNMPCONF-PM-MIB (has > (will have) a "capabilities" table which is similar in nature to the > sysORTable (but different, of course) and no way of registering > entries to it easily via agentx, unless they change their indexing to > avoid illegal information duplications [which I've requested to them > that they do]). There is also USM, which needs the set of security credentials in order to support the Own Key Change objects. However, I feel that supporting such operations is outside the scope of AgentX. I think that such operations belong in a separate protocol, and that we should consider whether or not to define such a protocol during the shutdown/recharter phase. /|/|ike From owner-agentx@dorothy.bmc.com Thu Apr 19 00:19:49 2001 Received: from creeper.bmc.com ([198.207.223.246]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA23560 for ; Thu, 19 Apr 2001 00:19:49 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by creeper.bmc.com (8.10.2/8.10.2) with ESMTP id f3J4Hhc24658; Wed, 18 Apr 2001 23:17:43 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id VAA00339 for agentx-list; Wed, 18 Apr 2001 21:15:40 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id VAA00334 for ; Wed, 18 Apr 2001 21:15:36 -0700 (PDT) Received: from fw-us-hou-9.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with SMTP id f3J4DXQ28345 for ; Wed, 18 Apr 2001 23:13:33 -0500 (CDT) Received: from ihemail2.lucent.com ([192.11.222.163]) by fw-us-hou-9.bmc.com; Wed, 18 Apr 2001 23:16:42 +0000 (CST) Received: from ihemail2.firewall.lucent.com (localhost [127.0.0.1]) by ihemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id AAA22244 for ; Thu, 19 Apr 2001 00:16:42 -0400 (EDT) Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id AAA22234 for ; Thu, 19 Apr 2001 00:16:41 -0400 (EDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2650.21) id ; Thu, 19 Apr 2001 06:16:40 +0200 Message-ID: <2413FED0DFE6D111B3F90008C7FA61FB0C05779F@nl0006exch002u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: AgentX@dorothy.bmc.com, "Ayers, Mike" Subject: RE: AgentX Charter/Milestone Update Date: Thu, 19 Apr 2001 06:16:40 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-agentx@dorothy.bmc.com Precedence: bulk List-Id: IETF Agentx Working Group mailing list Inline > ---------- > From: Ayers, Mike[SMTP:Mike_Ayers@bmc.com] > Sent: Thursday, April 19, 2001 12:32 AM > To: AgentX@dorothy.bmc.com > Subject: RE: AgentX Charter/Milestone Update > > .. snip .. > There is also USM, which needs the set of security credentials in > order to support the Own Key Change objects. > I would think that these USM things belong in the MASTER agent and so would not have any impact on agentx protocol Bert From owner-agentx@dorothy.bmc.com Thu Apr 19 02:40:25 2001 Received: from creeper.bmc.com ([198.207.223.246]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA07863 for ; Thu, 19 Apr 2001 02:40:24 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by creeper.bmc.com (8.10.2/8.10.2) with ESMTP id f3J6cpS01631; Thu, 19 Apr 2001 01:38:51 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id XAA00751 for agentx-list; Wed, 18 Apr 2001 23:34:52 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id XAA00746 for ; Wed, 18 Apr 2001 23:34:48 -0700 (PDT) Received: from fw-us-hou-9.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with SMTP id f3J6Wi119317 for ; Thu, 19 Apr 2001 01:32:44 -0500 (CDT) Received: from c001-h007.c001.snv.cp.net ([209.228.32.121]) by fw-us-hou-9.bmc.com; Thu, 19 Apr 2001 01:35:53 +0000 (CST) Received: (cpmta 7973 invoked from network); 18 Apr 2001 23:34:55 -0700 Received: from unknown (HELO bnatale.AppliedSNMP.com) (38.203.142.102) by smtp.appliedsnmp.com (209.228.32.121) with SMTP; 18 Apr 2001 23:34:55 -0700 X-Sent: 19 Apr 2001 06:34:55 GMT Message-Id: <5.0.1.4.2.20010419023749.02301828@mail.AppliedSNMP.com> X-Sender: Bob.Natale@mail.AppliedSNMP.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.1 Date: Thu, 19 Apr 2001 02:39:23 -0400 To: "Wijnen, Bert (Bert)" From: Bob Natale Subject: RE: AgentX Charter/Milestone Update Cc: AgentX@dorothy.bmc.com, "Ayers, Mike" In-Reply-To: <2413FED0DFE6D111B3F90008C7FA61FB0C05779F@nl0006exch002u.nl .lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-agentx@dorothy.bmc.com Precedence: bulk List-Id: IETF Agentx Working Group mailing list At 4/19/2001:12:16 AM, Wijnen, Bert (Bert) wrote: Hi Bert and Mike, >> There is also USM, which needs the set of security credentials in >> order to support the Own Key Change objects. >> >I would think that these USM things belong in the MASTER agent >and so would not have any impact on agentx protocol Yes, that was the intent of the overall AgentX design in this particular case (authentication). BobN From owner-agentx@dorothy.bmc.com Thu Apr 19 02:43:41 2001 Received: from creeper.bmc.com ([198.207.223.246]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA07884 for ; Thu, 19 Apr 2001 02:43:41 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by creeper.bmc.com (8.10.2/8.10.2) with ESMTP id f3J6geS01903; Thu, 19 Apr 2001 01:42:40 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id XAA00767 for agentx-list; Wed, 18 Apr 2001 23:41:26 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id XAA00762 for ; Wed, 18 Apr 2001 23:41:22 -0700 (PDT) Received: from fw-us-hou-9.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with SMTP id f3J6dIj21517 for ; Thu, 19 Apr 2001 01:39:18 -0500 (CDT) Received: from c001-h000.c001.snv.cp.net ([209.228.32.114]) by fw-us-hou-9.bmc.com; Thu, 19 Apr 2001 01:42:27 +0000 (CST) Received: (cpmta 7929 invoked from network); 18 Apr 2001 23:41:02 -0700 Received: from unknown (HELO bnatale.AppliedSNMP.com) (38.203.142.102) by smtp.appliedsnmp.com (209.228.32.114) with SMTP; 18 Apr 2001 23:41:02 -0700 X-Sent: 19 Apr 2001 06:41:02 GMT Message-Id: <5.0.1.4.2.20010419024017.02301828@mail.AppliedSNMP.com> X-Sender: Bob.Natale@mail.AppliedSNMP.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.1 Date: Thu, 19 Apr 2001 02:45:30 -0400 To: "Ayers, Mike" From: Bob Natale Subject: RE: AgentX Charter/Milestone Update Cc: AgentX@dorothy.bmc.com In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-agentx@dorothy.bmc.com Precedence: bulk List-Id: IETF Agentx Working Group mailing list At 4/18/2001:06:32 PM, Ayers, Mike wrote: Hi Mike, ><...> > There is also USM, which needs the set of security credentials in >order to support the Own Key Change objects. > > However, I feel that supporting such operations is outside the scope >of AgentX. I think that such operations belong in a separate protocol, and >that we should consider whether or not to define such a protocol during the >shutdown/recharter phase. See the follow-up from Bert and me re USM in particular. However, your broader point is correct -- it is likely that some relevant new work might be identified in the course of the current business at hand (moving to Draft Status or recycling at Proposed) and any such *new* work that the WG wanted to tackle would be a part of the shutdown/recharter decision process. Thanks, BobN From owner-agentx@dorothy.bmc.com Thu Apr 19 02:49:06 2001 Received: from creeper.bmc.com ([198.207.223.246]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA07898 for ; Thu, 19 Apr 2001 02:49:05 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by creeper.bmc.com (8.10.2/8.10.2) with ESMTP id f3J6llD02195; Thu, 19 Apr 2001 01:47:47 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id XAA00792 for agentx-list; Wed, 18 Apr 2001 23:46:36 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id XAA00785 for ; Wed, 18 Apr 2001 23:46:32 -0700 (PDT) Received: from fw-us-hou-9.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with SMTP id f3J6iSZ23298 for ; Thu, 19 Apr 2001 01:44:28 -0500 (CDT) Received: from c001-h007.c001.snv.cp.net ([209.228.32.121]) by fw-us-hou-9.bmc.com; Thu, 19 Apr 2001 01:47:36 +0000 (CST) Received: (cpmta 12178 invoked from network); 18 Apr 2001 23:47:13 -0700 Received: from unknown (HELO bnatale.AppliedSNMP.com) (38.203.142.102) by smtp.appliedsnmp.com (209.228.32.121) with SMTP; 18 Apr 2001 23:47:13 -0700 X-Sent: 19 Apr 2001 06:47:13 GMT Message-Id: <5.0.1.4.2.20010419024555.02301828@mail.AppliedSNMP.com> X-Sender: Bob.Natale@mail.AppliedSNMP.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.1 Date: Thu, 19 Apr 2001 02:51:41 -0400 To: Randy Presuhn From: Bob Natale Subject: Re: AgentX Charter/Milestone Update Cc: AgentX@dorothy.bmc.com In-Reply-To: <200104182017.NAA20245@dorothy.bmc.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-agentx@dorothy.bmc.com Precedence: bulk List-Id: IETF Agentx Working Group mailing list At 4/18/2001:04:17 PM, Randy Presuhn wrote: Hi Randy, ><...proposed charter/milestone updates...> > >Any thoughts on how SMING and EOS might impact this? I think Lauren might have some specific comments on that question and I am hopeful that she will post them to this list. However, what I am *hoping* we can do re the action items on the table for AgentX during this phase is to limit the scope to what the specs targeted as part of the original charter. The argument being that we have had a number of deployed implementations of the Proposed Standard specs for a reasonable amount of time and we should use that experience to decide whether those specs (possibly with slight modifications), relative to their targeted requirements, should now be advanced to Draft Standard level. I.e., taking a limited view, deliberately. Objections? Thanks, BobN From owner-agentx@dorothy.bmc.com Thu Apr 19 02:59:56 2001 Received: from creeper.bmc.com ([198.207.223.246]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA07998 for ; Thu, 19 Apr 2001 02:59:55 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by creeper.bmc.com (8.10.2/8.10.2) with ESMTP id f3J6woB02789; Thu, 19 Apr 2001 01:58:50 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id XAA00831 for agentx-list; Wed, 18 Apr 2001 23:57:32 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id XAA00826 for ; Wed, 18 Apr 2001 23:57:28 -0700 (PDT) Received: from fw-us-hou-9.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with SMTP id f3J6tOc27172 for ; Thu, 19 Apr 2001 01:55:24 -0500 (CDT) Received: from c001-h000.c001.snv.cp.net ([209.228.32.114]) by fw-us-hou-9.bmc.com; Thu, 19 Apr 2001 01:58:34 +0000 (CST) Received: (cpmta 14808 invoked from network); 18 Apr 2001 23:58:00 -0700 Received: from unknown (HELO bnatale.AppliedSNMP.com) (38.203.142.102) by smtp.appliedsnmp.com (209.228.32.114) with SMTP; 18 Apr 2001 23:58:00 -0700 X-Sent: 19 Apr 2001 06:58:00 GMT Message-Id: <5.0.1.4.2.20010419025216.02301828@mail.AppliedSNMP.com> X-Sender: Bob.Natale@mail.AppliedSNMP.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.1 Date: Thu, 19 Apr 2001 03:02:28 -0400 To: Wes Hardaker From: Bob Natale Subject: Re: AgentX Charter/Milestone Update Cc: AgentX@dorothy.bmc.com In-Reply-To: References: <20010418185423.21470.cpmta@c001.snv.cp.net> <20010418185423.21470.cpmta@c001.snv.cp.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-agentx@dorothy.bmc.com Precedence: bulk List-Id: IETF Agentx Working Group mailing list At 4/18/2001:06:20 PM, Wes Hardaker wrote: Hi Wes, >bob> Jun 01 - All open issues resolved (Jun 30) > >There might be a few issues that need to be thought about and >discarded or acted upon. Agreed..."resolved" was not meant to imply any particular outcome -- hopefully all of them will be thought about, some may result in modifications to the specs (if any of those mods are significant/substantial, we might have to recycle as a result), some may be discarded (WG consensus is that they are not relevant to or acceptable for AgentX), and some might be tabled for consideration as part of a re-chartering of the WG, etc. >Specifically, it is not possible to implement certain MIBs inside >a strict AgentX subagent implementation. The stated goals for the protocol acknowledged this. The existing RFCs and their corresponding implementations should be assessed for advancement, at this time, on the basis of their pre-existing requirements and objectives. >Examples are the DISMAN-EVENT-MIB (needs access to authentication >information and bi-directional requests) and the SNMPCONF-PM-MIB (has >(will have) a "capabilities" table which is similar in nature to the >sysORTable (but different, of course) and no way of registering >entries to it easily via agentx, unless they change their indexing to >avoid illegal information duplications [which I've requested to them >that they do]). Understood. The authentication issues *should* be resolvable within the existing AgentX context, I believe. For some of the others, it may be best (in certain cases) if MIB designers think in terms of AgentX at the outset and, for some, it may be that only a new set of goals for a re-chartered AgentX WG will suffice. >Makes me think that we should either support another set of protocol >operations, or leave room for extensibility in some way that can be >defined by future specification documents that want to mention how to >implement "something" otherwise impossible under the AgentX protocol. Ok...sounds like proposed new work for the re-chartering discussion. Thanks, BobN From owner-agentx@dorothy.bmc.com Thu Apr 19 06:38:18 2001 Received: from creeper.bmc.com ([198.207.223.246]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA09818 for ; Thu, 19 Apr 2001 06:38:17 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by creeper.bmc.com (8.10.2/8.10.2) with ESMTP id f3JAZqP17467; Thu, 19 Apr 2001 05:35:52 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id DAA01232 for agentx-list; Thu, 19 Apr 2001 03:34:14 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id DAA01227 for ; Thu, 19 Apr 2001 03:34:10 -0700 (PDT) Received: from fw-us-hou-9.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with SMTP id f3JAW6t21118 for ; Thu, 19 Apr 2001 05:32:06 -0500 (CDT) Received: from mailhub2.liv.ac.uk ([138.253.100.95]) by fw-us-hou-9.bmc.com; Thu, 19 Apr 2001 05:35:13 +0000 (CST) Received: from ribble.server.csc.liv.ac.uk ([138.253.124.242]) by mailhub2.liv.ac.uk with esmtp (Exim 3.22 #1) id 14qBlA-0004b7-00 for AgentX@dorothy.bmc.com; Thu, 19 Apr 2001 11:34:00 +0100 Received: from daves.staff.csc.liv.ac.uk (IDENT:root@daves.staff.csc.liv.ac.uk [138.253.124.36]) by ribble.server.csc.liv.ac.uk (8.9.3 (PHNE_22672)/LUCS-DTS-3.0M10) with ESMTP id LAA19551 for ; Thu, 19 Apr 2001 11:33:57 +0100 (BST) Received: from daves.staff.csc.liv.ac.uk (daves@localhost [127.0.0.1]) by daves.staff.csc.liv.ac.uk (8.8.7/LUCS-DTS-3.0D9) with ESMTP id LAA02486 for ; Thu, 19 Apr 2001 11:30:19 +0100 Message-Id: <200104191030.LAA02486@daves.staff.csc.liv.ac.uk> X-Mailer: exmh version 2.0.2 To: AgentX@dorothy.bmc.com Subject: Re: AgentX Charter/Milestone Update In-Reply-To: Your message of "18 Apr 2001 11:54:23 PDT." <20010418185423.21470.cpmta@c001.snv.cp.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 19 Apr 2001 11:30:19 +0100 From: Dave Shield Sender: owner-agentx@dorothy.bmc.com Precedence: bulk List-Id: IETF Agentx Working Group mailing list > Apr 01 - Implementation reports formally solicited (Apr 23) > Apr 01 - Interoperability reports formally solicited (Apr 30) I presume these will include details of the appropriate formats as promised in the advance notice earlier this month ? Dave From owner-agentx@dorothy.bmc.com Thu Apr 19 09:05:58 2001 Received: from creeper.bmc.com ([198.207.223.246]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA10603 for ; Thu, 19 Apr 2001 09:05:58 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by creeper.bmc.com (8.10.2/8.10.2) with ESMTP id f3JD3Xv27099; Thu, 19 Apr 2001 08:03:33 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id GAA01478 for agentx-list; Thu, 19 Apr 2001 06:01:32 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id GAA01470 for ; Thu, 19 Apr 2001 06:01:27 -0700 (PDT) Received: from fw-us-hou-9.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with SMTP id f3JCxNE24945 for ; Thu, 19 Apr 2001 07:59:23 -0500 (CDT) Received: from mumm.ibr.cs.tu-bs.de ([134.169.34.190]) by fw-us-hou-9.bmc.com; Thu, 19 Apr 2001 08:02:26 +0000 (CST) Received: from hansa.ibr.cs.tu-bs.de (IDENT:root@hansa [134.169.34.137]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.0) with ESMTP id PAA18397; Thu, 19 Apr 2001 15:00:43 +0200 (MET DST) Received: (from strauss@localhost) by hansa.ibr.cs.tu-bs.de (8.9.3/8.9.3) id PAA12588; Thu, 19 Apr 2001 15:00:43 +0200 X-Authentication-Warning: hansa.ibr.cs.tu-bs.de: strauss set sender to strauss@ibr.cs.tu-bs.de using -f From: Frank Strauss To: AgentX@dorothy.bmc.com Subject: Re: AgentX Charter/Milestone Update References: <2413FED0DFE6D111B3F90008C7FA61FB0C05779F@nl0006exch002u.nl.lucent.com> Date: 19 Apr 2001 15:00:43 +0200 In-Reply-To: <2413FED0DFE6D111B3F90008C7FA61FB0C05779F@nl0006exch002u.nl.lucent.com> Message-ID: Lines: 24 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-agentx@dorothy.bmc.com Precedence: bulk List-Id: IETF Agentx Working Group mailing list Hi! >> There is also USM, which needs the set of security credentials in >> order to support the Own Key Change objects. >> Bert> I would think that these USM things belong in the MASTER agent Bert> and so would not have any impact on agentx protocol In my opinion, the same is true for other MIB tables that model general functions or characteristics of an agent or its infrastructure, e.g., in the DISMAN-EVENT-MIB or the SNMPCONF-PM-MIB mentioned by Wes. However, if we look at some tables more detailed on a per-row basis, it might be reasonable to let a sub-agent register single rows with the master, e.g. in case of the capabilities table. It is not the purpose of AgentX to be used for each and every MIB. It is the purpose of AgentX to allow to put the management instrumentation next to the instrumented entities in order to achieve a cleanly separated design where appropriate. In cases where there is no instrumented entity, there is no need to move the implementation away from the master agent. -frank From owner-agentx@dorothy.bmc.com Thu Apr 19 13:41:39 2001 Received: from creeper.bmc.com ([198.207.223.246]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA15107 for ; Thu, 19 Apr 2001 13:41:39 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by creeper.bmc.com (8.10.2/8.10.2) with ESMTP id f3JHe6n23509; Thu, 19 Apr 2001 12:40:06 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id KAA06787 for agentx-list; Thu, 19 Apr 2001 10:35:21 -0700 (PDT) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id KAA06781 for AgentX@dorothy.bmc.com; Thu, 19 Apr 2001 10:35:17 -0700 (PDT) Date: Thu, 19 Apr 2001 10:35:17 -0700 (PDT) From: Randy Presuhn Message-Id: <200104191735.KAA06781@dorothy.bmc.com> To: AgentX@dorothy.bmc.com Subject: Re: AgentX Charter/Milestone Update Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-agentx@dorothy.bmc.com Precedence: bulk List-Id: IETF Agentx Working Group mailing list X-MIME-Autoconverted: from 8bit to quoted-printable by creeper.bmc.com id f3JHe6n23509 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id NAA15107 Hi - > From: Frank Strauss > To: AgentX@dorothy.bmc.com > Subject: Re: AgentX Charter/Milestone Update > References: <2413FED0DFE6D111B3F90008C7FA61FB0C05779F@nl0006exch002u.nl.lucent.com> > Date: 19 Apr 2001 15:00:43 +0200 > In-Reply-To: <2413FED0DFE6D111B3F90008C7FA61FB0C05779F@nl0006exch002u.nl.lucent.com> > Message-ID: ... > Bert> I would think that these USM things belong in the MASTER agent > Bert> and so would not have any impact on agentx protocol > > In my opinion, the same is true for other MIB tables that model > general functions or characteristics of an agent or its infrastructure, > e.g., in the DISMAN-EVENT-MIB or the SNMPCONF-PM-MIB mentioned by Wes. I think it would be very nice to be able to put the disman event, schedule, script, and expression mibs into subagents. The only thing that currently makes that difficult is the need to remember credentials and to consult the (abstract) isAccessAllowed service. Building all these MIBs into the master agent implementation would be a configuration management (in the software sense) nightmare. > However, if we look at some tables more detailed on a per-row basis, > it might be reasonable to let a sub-agent register single rows with > the master, e.g. in case of the capabilities table. One can already perform such registrations with AgentX. > It is not the purpose of AgentX to be used for each and every MIB. > It is the purpose of AgentX to allow to put the management > instrumentation next to the instrumented entities in order to achieve > a cleanly separated design where appropriate. Agreed. > In cases where there is > no instrumented entity, there is no need to move the implementation > away from the master agent. ... In cases where there is no instrumented entity, a MIB would be pointless. ------------------------------------------------------- Randy Presuhn randy_presuhn@bmc.com Voice: +1 408 546-1006 BMC Software, Inc. 1-3141 Fax: +1 408 965-0359 2141 North First Street http://www.bmc.com/ San José, California 95131 USA ------------------------------------------------------- My opinions and BMC's are independent variables. ------------------------------------------------------- From owner-agentx@dorothy.bmc.com Thu Apr 19 14:30:34 2001 Received: from creeper.bmc.com ([198.207.223.246]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA15886 for ; Thu, 19 Apr 2001 14:30:33 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by creeper.bmc.com (8.10.2/8.10.2) with ESMTP id f3JIDSf26279; Thu, 19 Apr 2001 13:13:29 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id LAA07849 for agentx-list; Thu, 19 Apr 2001 11:12:04 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id LAA07840 for ; Thu, 19 Apr 2001 11:11:48 -0700 (PDT) Received: from fw-us-hou-9.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with SMTP id f3JI9ip26009 for ; Thu, 19 Apr 2001 13:09:44 -0500 (CDT) Received: from sj-msg-core-2.cisco.com ([171.69.43.88]) by fw-us-hou-9.bmc.com; Thu, 19 Apr 2001 13:12:53 +0000 (CST) Received: from fedex.cisco.com (fedex.cisco.com [171.69.18.27]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id KAA25744; Thu, 19 Apr 2001 10:50:38 -0700 (PDT) Received: from cisco.com (lheintz-dsl3.cisco.com [10.21.194.36]) by fedex.cisco.com (Mirapoint) with ESMTP id AEK10060 (AUTH lheintz); Thu, 19 Apr 2001 10:50:06 -0700 (PDT) Message-ID: <3ADF2590.D63BD868@cisco.com> Date: Thu, 19 Apr 2001 10:51:12 -0700 From: Lauren Heintz X-Mailer: Mozilla 4.73 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: "AgentX@dorothy.bmc.com" CC: Glenn Waters , "Dale Francisco (dfrancis@cisco.com)" Subject: EOS and AgentX charter impact? Content-Type: multipart/mixed; boundary="------------95890FB17D956A2328D0EFE5" Sender: owner-agentx@dorothy.bmc.com Precedence: bulk List-Id: IETF Agentx Working Group mailing list This is a multi-part message in MIME format. --------------95890FB17D956A2328D0EFE5 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, As Bob hinted yesterday, here is a EOS WG draft document that mentions some possible AgentX charter/protocol impacts. The ideas proposed in this draft are very young and very likely to change, so it's hard to tell at this time if the final doc will impact AgentX (and how so). The Appendix has some hastily drawn short blurbs about AgentX. In any case, please feel free to join the EOS discussions regarding this (and other) new and exciting -- and potentially controversial -- EOS work! Thanks, Lauren --------------95890FB17D956A2328D0EFE5 Content-Type: text/plain; charset=us-ascii; name="draft-ietf-eos-snmp-rowops-00.txt" Content-Disposition: inline; filename="draft-ietf-eos-snmp-rowops-00.txt" Content-Transfer-Encoding: 7bit INTERNET-DRAFT L. Heintz Cisco Systems, Inc. 19 April 2001 SNMP Row Operations Extensions Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Copyright Notice Copyright (C) The Internet Society (2001). All Rights Reserved. Abstract This document describes a set of extensions (protocol operations and textual conventions) to the existing SNMP framework architecture as defined in RFC2571. These extensions provide mechanisms for efficient creation, modification, deletion and retrieval of table rows. Table of Contents 1. The SNMP Network Management Framework ....................... 3 2. Overview .................................................... 4 2.1. Terms ..................................................... 4 2.2. Motivations for the Extensions ............................ 4 2.3. Design Goals .............................................. 5 EOS Working Group Expires October 2001 [Page 1] Internet Draft SNMP Row Operations Extensions 19 April 2001 3. The Extensions .............................................. 6 3.1. RowState .................................................. 6 3.2. Row Operations ............................................ 8 3.2.1. The rowIdentifier ....................................... 9 3.2.2. The operands ............................................ 12 3.2.3. Distinguishing rowIdentifiers from operands ............. 13 3.2.4. RowState and RowStatus Considerations ................... 13 3.2.5. Granularity of Success/Fail ............................. 14 3.2.6. Response PDUs ........................................... 14 4. Elements of Procedure ....................................... 14 4.1. CreateRow Request Processing .............................. 14 4.2. DeleteRow Request Processing .............................. 14 4.3. EditRow Request Processing ................................ 15 4.4. GetRow Request Processing ................................. 15 4.5. GetNextRow Request Processing ............................. 15 4.6. Response-PDU Processing ................................... 15 5. Coexistence and Transition .................................. 15 6. Protocol Operations Definitions ............................. 17 7. Managed Object Definitions .................................. 18 8. IANA Considerations ......................................... 19 9. Intellectual Property ....................................... 19 10. Acknowledgements ........................................... 19 11. Security Considerations .................................... 20 12. References ................................................. 20 13. Editor's Addresses ......................................... 23 A. Impact to SNMP and other Protocols .......................... 24 A.1. SNMPv3 .................................................... 24 A.2. AgentX .................................................... 24 B. Alternative Approaches ...................................... 24 C. Examples of Row Operations .................................. 25 C.1. CreateRow with RowStatus .................................. 25 C.2. CreateRow with RowState ................................... 26 C.3. DeleteRow ................................................. 27 C.4. GetRow and GetNextRow ..................................... 28 D. Known issues ................................................ 29 E. Full Copyright Statement .................................... 31 EOS Working Group Expires October 2001 [Page 2] Internet Draft SNMP Row Operations Extensions 19 April 2001 1. The SNMP Network Management Framework The SNMP Management Framework presently consists of five major components: - An overall architecture, described in RFC 2571 [RFC2571]. - Mechanisms for describing and naming objects and events for the purpose of management. The first version of this Structure of Management Information (SMI) is called SMIv1 and described in RFC 1155 [RFC1155], RFC 1212 [RFC1212] and RFC 1215 [RFC1215]. The second version, called SMIv2, is described in RFC 2578 [RFC2578], RFC 2579 [RFC2579] and RFC 2580 [RFC2580]. - Message protocols for transferring management information. The first version of the SNMP message protocol is called SNMPv1 and described in RFC 1157 [RFC1157]. A second version of the SNMP message protocol, which is not an Internet standards track protocol, is called SNMPv2c and described in RFC 1901 [RFC1901] and RFC 1906 [RFC1906]. The third version of the message protocol is called SNMPv3 and described in RFC 1906 [RFC1906], RFC 2572 [RFC2572] and RFC 2574 [RFC2574]. - Protocol operations for accessing management information. The first set of protocol operations and associated PDU formats is described in RFC 1157 [RFC1157]. A second set of protocol operations and associated PDU formats is described in RFC 1905 [RFC1905]. - A set of fundamental applications described in RFC 2573 [RFC2573] and the view-based access control mechanism described in RFC 2575 [RFC2575]. A more detailed introduction to the current SNMP Management Framework can be found in RFC 2570 [RFC2570]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. Objects in the MIB are defined using the mechanisms defined in the SMI. This memo specifies a MIB module that is compliant to the SMIv2. A MIB conforming to the SMIv1 can be produced through the appropriate translations. The resulting translated MIB must be semantically equivalent, except where objects or events are omitted because no translation is possible (use of Counter64). Some machine readable information in SMIv2 will be converted into textual descriptions in SMIv1 during the translation process. However, this loss of machine readable information is not considered to change the semantics of the EOS Working Group Expires October 2001 [Page 3] Internet Draft SNMP Row Operations Extensions 19 April 2001 MIB. 2. Overview This document describes a set of SNMP extensions to current protocol operations [RFC1905] to provide for efficient row operations (i.e. creating, modifying, deleting and retrieving table rows). In addition, a new textual convention, RowState, is defined to replace RowStatus in future MIBs. RowState maintains the ability to report the state of a row, but does not attempt to provide a mechanism to create or delete a row. APPENDIX A discusses some of the known impacts that these extensions may cause to current frameworks or protocols (e.g. AgentX). It is recognized that any one of several other approaches exist that could have been used to meet the design goals of this document. As such, a few of these approaches are briefly discussed in APPENDIX B. 2.1. Terms The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Terminology such as "leftmost" or "left" indicates a PDU component that is transmitted on the wire prior to other components. Thus, terms such as "rightmost" imply components that have similar, but opposite semantics. Protocol operation refers to a high-level request, such as a SetRequest or GetRequest (or one of the five new requests defined within this document). Row operation refers to one logical operation that affects one specific table row. A protocol operation may contain one or more row operations. The term rowOp refers to the component parts of a protocol operation that comprise a single row operation. 2.2. Motivations for the Extensions Experience has shown that current SNMP protocol operations and management structures are not ideally suited to effect configuration changes within managed devices and when retrieving information. The extensions described in this document are specifically designed to minimize, or provide opportunities to minimize the following problems which inhibit th effectiveness of SNMP: EOS Working Group Expires October 2001 [Page 4] Internet Draft SNMP Row Operations Extensions 19 April 2001 - Requests that contains multiple varbinds that affect one row of a table may contain significant redundancy of information. This is because each varbind contains an object name (i.e. Object Identifier or OID), and these OIDs may differ only in the single subid that designates a specific column. In cases where strings are used as instance identifiers, for example, UDP maximum-message-size constraints may force multiple SetRequests to be used to construct a new, or modify an existing row in a table. Requests containing redundant data are also more costly to encrypt and decrypt. - SetRequests may contain multiple varbinds that actually refer to the same MIB object. For example, varbind one may be attempting to set the object, foo, to the value 1, while varbind two may be attempting to set the same object, foo, to the value 2. In such cases, the SNMP protocol indicates that implementations may make independant decisions as to which varbind will effectively be used as the final result. - SetRequests do not impose any ordering requirements on the varbinds within a single request, even if they affect different objects in the same row of a table. This can cause added complexity in SetRequest processing. - The RowStatus textual convention [RFC1903] provides a mechanism for row management. RowStatus most often requires the implementation of a rather complicated state machine, many of whose transitions are optional and whose target states are at times non-deterministic. RowStatus also confuses the notion of row status with the notion of row fate, which also tends to complicate both the MIB design and the implementation. 2.3. Design Goals Several goals were identified when considering the kinds of extensions that were needed: - allow separate row operations (hereafter referred to as rowOps) to be performed in a single protocol operation. - minimize redundant information in a protocol operation. The extensions should at least make use of OID suppression techniques to meet this goal. Note that OID suppression (largely an issue of how data is stored within a PDU) is not equivalent to OID compression (data compression algorithms). Issues of OID compression are considered out of scope for this document. EOS Working Group Expires October 2001 [Page 5] Internet Draft SNMP Row Operations Extensions 19 April 2001 - eliminate the need for special MIB objects (e.g. RowStatus) that control the creation and deletion of rows. - minimize the impact on existing network management and subagent protocols such as SNMPv3, AgentX, and related applications. - interoperate with legacy MIBs as well as future MIBs. - operate in existing SNMP networks and not disrupt legacy SNMP- capable devices. 3. The Extensions Five new conceptual protocol operations are described in this document: CreateRowRequest-PDU (aka CreateRow), DeleteRowRequest-PDU (aka DeleteRow), EditRowRequest-PDU (aka EditRow), GetRowRequest-PDU (aka GetRow), and GetNextRowRequest-PDU (aka GetNextRow). Each of these request types are based on the same PDU structure as originally defined in [RFC1905]. For purposes of discussion, the three requests, CreateRow, DeleteRow and EditRow are more generically referred to as SetRow class requests, while GetRow and GetNextRow are referred to as RetrieveRow class requests. In addition, a RowState textual convention is defined and is intended to replace RowStatus in all future MIB designs. It is not the intention to deprecate RowStatus. Although RowState is not a protocol operation, it does serve to reestablish a distinction between SNMP data types and SNMP operations -- a line which is blurred in the current RowStatus definition. 3.1. RowState As mentioned earlier, this document defines a proposed textual convention, RowState, whose purpose is to replace RowStatus in future MIBs. This convention provides several important improvements over RowStatus: - RowState relaxes some of the row timeout rules that RowStatus suffers from. Such rules inhibit the usefulness of RowStatus as a means of temporarily placing system resources (i.e. table rows) out of service. For example, if an SNMP manager changes a given instance of snmpNotifyRowStatus from Active to NotInService as a means of temporarily disabling one or more notifications, an unintended side-effect of this action on some EOS Working Group Expires October 2001 [Page 6] Internet Draft SNMP Row Operations Extensions 19 April 2001 implementations may be that the row is automatically deleted after some short amount of time has elapsed (typically, a few minutes). - More importantly, RowState separates the notion of reporting row status and the notion of managing row fate (i.e. creation & deletion). Specifically, the purpose of RowState is to enable reporting of row state, while matters of creating and deleting rows are better served by protocol operations. RowState provides three states: NotReady, NotInService and Active, which are very similar to the corresponding RowStatus definitions. Unlike RowStatus, RowState does not provide CreatAndWait, CreateAndGo or Destroy. Any entity providing a RowState column in a table must instantiate an instance of RowState when one or more other column objects in the same row have been created or instantiated (by whatever means). Using the new protocol operations defined in this document, it is unnecessary to directly set or reference a RowState instance in order to create and activate a new row. The initial state of RowState is determined at the moment of initial row creation according to the semantics specified by the MIB designer (as provided within the Description clause of the RowState object, and much in the same way that RowStatus descriptions customize the semantics of those objects). At the time of row creation, the row creator may explicitly set the RowState object to a desired initial value, but the processing entity refers to this as a kind of "hint" since the final decision as to the initial value can only be determined after the complete row contents within the creation operation have been evaluated. One of the other differences between RowState and RowStatus is that RowState objects can never be automatically deleted from the entity as a result of timeouts when their states are either NotInService or Active. This provides the ability to use RowState objects to indefinitely take a row out of service without the fear of it being automatically deleted. When and whether rows containing RowState objects are added to, or removed from, non-volatile storage are not addressed by RowState. Such behavior must be specified by other means (e.g. StorageType), which is out of scope for this document. In addition, unlike RowStatus, it is permissible to explicitly set RowState objects to the NotReady state as a crude means of allowing traditional SetRequests to delete the row. In this case, deletion occurs as a side effect of a row timeout. As will be shown, the preferred method of deleting any row is via use of the new DeleteRow request, which does not contain any direct reference to any specific EOS Working Group Expires October 2001 [Page 7] Internet Draft SNMP Row Operations Extensions 19 April 2001 row object (such as RowState). The CreateRow request introduces the ability to set either RowStatus or RowState objects without the need to explicitly include a varbind in the request. A CreateRow request by convention contains an implicit operand (i.e. varbind) to set a corresponding RowState object (if any) to the Active value. This implicit varbind can be overridden by the inclusion of an actual RowState varbind. For example, the following two CreateRow requests are logically identical, as both will attempt to create a newly active fooEntry, whose index is 1, and whose fooInt object equals 2: CreateRow (fooEntry.1, fooInt=2); CreateRow (fooEntry.1, fooInt=2, fooRowState=Active); These two requests are NOT logically identical: CreateRow (fooEntry.1, fooInt=2); CreateRow (fooEntry.1, fooInt=2, fooRowState=NotInService); Implementations are not required, however, to support such implicit operands within CreateRow requests for RowStatus objects. This is intended to maximize the set of possible transition solutions for vendors of SNMP technology. The RowState textual convention provides full details of its use and operation and is provided in section 6. 3.2. Row Operations The new protocol operations are designed to "fit" in the existing PDU structure as originally defined in [RFC1905]. One of the alternative approaches discussed in the Appendix is the possibility of defining a new PDU structure that allows a more efficient OID suppression strategy than the one described herein. However, the initial approach offered in intended to "look and feel" as close to the current framework as possible. As will be shown, the current PDU structure is quite sufficient to obtain significant (but not optimal) OID suppression benefits. Formal definitions of the new protocol operations are provided in section 5. [RFC1905] provides the PDU definition which these new operations are based on. Although the old PDU structure is maintained for now, this document specifies an evolutionary approach in the way that the new protocol operations are encoded or contained within the PDU. As such, the new EOS Working Group Expires October 2001 [Page 8] Internet Draft SNMP Row Operations Extensions 19 April 2001 requests capitalize on OID suppression techniques to minimize information redundancy and therefore minimize PDU size. Note that the traditional SNMP protocol operations as defined in [RFC1905] are not being changed, either in their semantics, the way data is encoded within them, or the way they are processed. The following general discussion centers on how the varbinds of the new protocol operations are formed or constructed. Other components of the PDU (e.g. error-index) are treated similarly to the current framework. The elements of procedure, section 4, formally describes how the new requests are processed. APPENDIX C provides some high- level examples of the use of these operations. The varbinds in a PDU form one or more independant row operations (rowOps). This allows a single CreateRow request, for example, to create one or more new rows in a single protocol operation. Each rowOp corresponds to one attempt to create a row, in this case, or corresponds to one attempt to delete a row in the case of DeleteRow, and so forth. Note that the three layers in the diagram below do not describe different sections of the PDU, rather, they each represent the same information and structure (at different levels of abstraction). Although the above diagram shows a CreateRow request logically containing three rowOps (i.e. create three rows) with two consecutive varbinds per rowOp, in reality, these requests may contain one, two, or more than two rowOps, each of which may may be comprised of a differing number of varbinds (i.e. zero, one, or more than one). In addition, the above example (and the ones that follow) could have substituted a RetrieveRow class request instead of CreateRow, The varbinds allocatted to a single rowOp serve to function as either a rowIdentifier or as operands. 3.2.1. The rowIdentifier The first varbind in each rowOp provides basic request parameters, and is hereafter referred to as the rowIdentifier parameter of a rowOp. The remaining varbinds in a given rowOp provide the individual operands (i.e. the affected row objects), which are hereafter referred to as operands. In the diagram above, the 1st, 3rd and 5th varbinds are therefore rowIdentifiers while the 2nd, 4th and EOS Working Group Expires October 2001 [Page 9] Internet Draft SNMP Row Operations Extensions 19 April 2001 6th varbinds are operands. The following diagram shows a GetRow request containing a single rowOp that itself is composed of the required rowIdentifier and two operands. In this case, the GetRow request is seeking to retrieve two specific column objects from a specific row. To understand how each rowIdentifier varbind is constructed and what information is contained therein, it is useful to consider how OIDs for table objects are formed. An OID for a given object instance in a table can be broken up into three logical components: OID = If a traditional SetRequest contains two varbinds referring to two different columns in the same row, it is evident that both OIDs differ only in the integer value of the columnPart (a single subid). The other two parts, tableEntryPart and instancePart, therefore, are identical for each varbind present in a request affecting only a single table. A more meaningful representation for rowIdentifier is now possible: rowIdentifier = The vb.type MUST specify a type of OID. This is because the instancePart of an OID is actually comprised of one or more table index values, depending on which table is affected and how many MIB objects comprise the INDEX clause of that table. For example, for a table whose INDEX is comprised of a single integer, instancePart will be a single subid; and for a table whose INDEX is comprised of two or more objects of any kind, the instancePart will be an OID (index1 + index2 + ... + indexN) with each index component representing one or more subids. Because the instancePart always resolves to one or more subids, and because a valid OID must be composed of at least two subids, we prefix the instancePart with the OID value of 0.1. The reason EOS Working Group Expires October 2001 [Page 10] Internet Draft SNMP Row Operations Extensions 19 April 2001 instancePart cannot simply be prefixed with a single subid is that OIDs of the form 0.X, where X > 39, are not legal. Thus, if instancePart resolved to a single subid of 40 (or greater), the value of 0.40 would be illegal. Thus the need to prefix instancePart with two subids that guarantee a valid OID will be formed regardless of how instancePart is resolved. Note that due to ASN.1/BER encoding rules, the first two subids comprise only a single byte within the PDU. The rowIdentifier of each rowOp in a SetRow or RetrieveRow request specifies the exact row affected by the rowOp (but not which column objects are affected in that row). Consider the case of two or more rowOps in, say, a SetRow request that only affects different rows in the same table. In such cases, the varbind names of all the rowIdentifier varbinds will contain identical values. In order to therefore further minimize information redundancy, the OID of 1.0 (hereafter referred to as the inheritance OID, and occupying only a single byte within the resulting PDU) is permitted to be substituted as the varbind name of any rowIdentifier to indicate that the most recent (leftmost) rowIdentifier whose name is dissimilar (not 1.0) contains the OID value intended to be used. In this example, a simplified notation is used to help illustrate how a rowOp (the two middle ones in this case) uses the inheritance OID to minimize PDU size. This example shows four rowOps, each comprised of one rowIdentifier and one operand (op): [] [<1.0>] [<1.0>] [] The following is logically identical to the preceding example (though it forms a larger PDU): [] [] [] [] Of course, this implies that rowOps that affect the same table SHOULD be consecutively placed in the PDU varbind list, and also that the first rowIdentifier in the PDU MUST NOT contain the inheritance OID. Each rowOp is fully independant of any other despite any inheritance it may use. Each rowOp MUST contain a single rowIdentifier varbind, which MUST be the first varbind in each rowOp. The tableEntryPart of a rowIdentifier MUST NOT contain partial OIDs. This means that the tableEntryPart MUST always exactly correspond to a legal table entry definition (if the desired results are to be achieved). The motivation behind this is that all rowOps are performed at the row EOS Working Group Expires October 2001 [Page 11] Internet Draft SNMP Row Operations Extensions 19 April 2001 level. The instancePart within a GetNextRow is not required to be fully formed except that if the value is non-NULL, it MUST at least contain the 0.1 prefix. Also note that GetNextRow requests do not "jump" to the next table. In other words, in the event a GetNextRow rowOp refers to the last row in a given table, the appropriate exception is returned for that rowOp even if other tables follow that contain retrievable rows. In this sense, GetNextRow is limited to operate within the subtree of the targeted table(s). 3.2.2. The operands The remaining varbinds for a given rowOp are referred to as its operands, and are formed as standard SetRequest varbinds except that the name of each varbind is an OID whose length is exactly three subids long. The first two subids MUST be 0.1 and the third subid is taken from the affected column descriptor value whose object instance is affected. The reason three subids are specified (0.1.columnSubid) instead of two (0.columnSubid) is that columnSubid must accept all values in the range from 0 to 4294967295. However, the ASN.1/BER encoding rules do not allow OID values of 0.X where X > 39. Note that typical OIDs formed this way (where columnSubid is small) will be comprised of only two bytes despite the fact that three subids are specified. Each operand contained in the same rowOp will have a varbind name such that varbind N MUST be lexicographically smaller than the name of varbind N+1. In other words, there is a left to right ordering relationship imposed on the rowOp operands to further provide implementation optimization opportunities and to further guarantee that multiple and possibly conflicting operands for the same column object cannot be provided (further minimizes information redundancy and processing ambiguity). For example, the operand with the name of, 0.1.0, MUST be to the left of the operand with the name of, 0.1.1, if they are operands of the same rowOp. Any rowOp may contain zero or more operands, except that the EditRow request MUST contain at least one operand. In case of RetrieveRow requests, if zero operands are provided in a rowOp, this implicitly calls for the retrieval of all instantiated objects in the affected row. Otherwise, only the specified objects are retrieved. In cases of CreateRow, at least one column definition in each of the affected tables must have a MAX-ACCESS of read-create and the the EOS Working Group Expires October 2001 [Page 12] Internet Draft SNMP Row Operations Extensions 19 April 2001 affected rows MUST NOT already exist (in whole or part). If zero operands are provided in a rowOp, then the row must be able to be created in whole or part using only default values. In cases of EditRow, each rowOp contains an operand for each row object whose value is being changed and whose MAX-ACCESS is either read-create or read-write. The affected rows MUST already exist (in whole or part), though the specific operands MAY refer to objects that do not yet exist. In cases of DeleteRow, each rowOp MAY contain operands whose MAX- ACCESS are either read-write or read-create. While it is not essential that operands be included in a DeleteRow request, they may in special cases be useful, for example, when a proxy application translates a DeleteRow request to a conventional SetRequest that requires a RowStatus reference. 3.2.3. Distinguishing rowIdentifiers from operands As described earlier, the varbinds in a rowOp function either as a rowIdentifier (one per rowOp) or as an operand (zero or more per rowOp). By definition, the first varbind in any SetRow or RetrieveRow request MUST be a rowIdentifier. The varbind names of all rowIdentifiers are guaranteed to be OIDs with a minimum of four subids (because current SMIv2 rules and current IANA object registrations preclude the possibility that table entry definitions can have shorter OIDs). One exception to this, is that varbind names for rowIdentifiers may contain the inheritance OID value of, 1.0 (see earlier discussion for how and why this is used). The varbind names of all operands, on the other hand, are OID values with exactly three subids whose first two subids form an OID of 0.1.X. In summary, if a varbind name contains an OID of the form 0.1.X (exactly three subids) then the varbind in question functions as an operand. Otherwise, the varbind functions as a rowIdentifier. 3.2.4. RowState and RowStatus Considerations It is worthwhile to note that SetRow class requests allow new MIBs to be created without requiring use of the RowStatus or RowState textual conventions to allow for either incremental or "big-bang" style (i.e. CreateAndWait or CreateAndGo, resp.) row creation or deletion. RowState is useful only to report the current state of a row -- notwithstanding the slight anomaly that it also allows SetRequests EOS Working Group Expires October 2001 [Page 13] Internet Draft SNMP Row Operations Extensions 19 April 2001 and EditRow requests to explicitly change the state of such objects to NotReady, and thereby cause a row deletion timer to be instantiated. Similarly, traditional SetRequests and SetRow requests can both be used to manage MIBs that incoporate RowStatus columns. For new MIB tables that do not require row state reporting objects, but which do require creation and/or deletion semantics, it is sufficient to omit RowState and RowStatus entirely and instead use a MAX-ACCESS of read-create for all writable objects. Such tables can elegantly support row creation through use of the CreateRow or traditional SetRequest operations, and also support row deletion through use of the DeleteRow operation. 3.2.5. Granularity of Success/Fail In the event a SetRow class request contains two or more rowOps that affect the same row, the elements of procedure (below) indicate that all rowOps in the SetRow request are to be rejected (i.e. all rowOps fail and the entity remains in the state it was in prior to receiving the SetRow request). RetrieveRow class requests can succeed or fail individually or even with each varbind. 3.2.6. Response PDUs This document does not define any new response PDU. Instead, the traditional Response-PDU [RFC1905] is used as the standard response to each of the SetRow and RetrieveRow requests, except that the varbinds are constructed using the same OID suppression techniques as described above. 4. Elements of Procedure 4.1. CreateRow Request Processing TBD 4.2. DeleteRow Request Processing TBD EOS Working Group Expires October 2001 [Page 14] Internet Draft SNMP Row Operations Extensions 19 April 2001 4.3. EditRow Request Processing TBD 4.4. GetRow Request Processing TBD 4.5. GetNextRow Request Processing TBD 4.6. Response-PDU Processing TBD 5. Coexistence and Transition An essential requirement for these operations is that they must operate seamlessly in existing networks and not disrupt legacy SNMP devices. This is satisfied by the fact that the new protocol operations have new and unique ASN.1 tags, which allow older implementations to efficiently and silently drop these new PDU requests. Some entities may only support these extensions for certain tables. For example, different AgentX subagents may or may not support these operations. This requires that the requests fail whenever a table is targeted that cannot support the new operation. The elements of procedure indictate the proper exceptions in these cases. It is also possible that some table implementations may support only some subset of the new operations, for example, the RetrieveRow requests, but not the SetRow requests. It is herein RECOMMENDED that SNMP entities that support at least one operation within a class (i.e. SetRow or RequestRow) for a given table SHOULD support all requests within the same class for that table. Also, it is further RECOMMENDED that if the SetRow class of operations are supported for a given table, then the entity SHOULD also support all the RetrieveRow operations for that table. For any operation not supported by a targeted table (which nevertheless supports other operations), the elements of procedure indicate the proper exceptions that apply. EOS Working Group Expires October 2001 [Page 15] Internet Draft SNMP Row Operations Extensions 19 April 2001 In an ideal world, the extensions herein would be easily translatable to traditional operations. However, this is not the case. Consider, for example, that it is impossible to form an equivalent SetRequest from a DeleteRow request that contains only a rowIdentifier but no operands. In fact, any SetRow or RetrieveRow request containing no operands cannot be translated into an equivalent Set/Get request because at least one operand is needed to convert the rowIdentifier information into a valid object (OID) reference. DeleteRow may optionally include a RowStatus object, which allows such a translation, but then the question arises as to the need for DeleteRow definitions in the first place. Or consider a proxy application that accepts CreateRow or EditRow requests and translates them into an equivalent SetRequest. For example, CreateRow(fooEntry.row1, fooInt=1) is translated into Set(fooEntry.fooInt.row1=1). Note that an EditRow request containing the same varbind info would be translated into the exact same Set request. This implies that proxy applications cannot faithfully translate these two extensions into a SetRequest with the same semantics as the original request. A CreateRow request, after translation, might incorrectly cause an existing row to be modified, whereas an EditRow request might cause a new row to be instantiated. A partial workaround is to explicitly include a RowStatus reference in all CreateRow requests, and to ensure that rows do not exist before issuing EditRow requests, though in multi-manager environments, this latter procedure suffers. The same issues are evident when a master agent needs to translate the extensions into traditional subagent PDU forms. Semantics may be lost in the translation, and only some amount of workaround is possible unless the underlying subagent protocol is itself extended to accomodate the new extensions. While it is possible to develop proxy applications that incorporate simple PDU translation schemes to generally allow EOS-capable devices (as described herein) to interoperate with non-EOS-capable devices, the workarounds that would be needed might in some (but not all) environments mitigate some or all of the benefits in using the new extensions in the first place. In short, with the approach outlined in this document, it is believed that non-EOS-capable devices need to be converted into EOS-capable devices by means other than simple PDU translation schemes. In order to enable a transition strategy that uses simple PDU translation mechanisms, at least some of the earlier stated goals of this document would have to be abandoned (e.g. the goal to replace MIB objects such as RowStatus which confuse the notions of row state with EOS Working Group Expires October 2001 [Page 16] Internet Draft SNMP Row Operations Extensions 19 April 2001 row fate, and perhaps other goals as well). 6. Protocol Operations Definitions SNMP-ROWOP-PDUS-MIB DEFINITIONS ::= BEGIN IMPORTS PDU SNMPv2-PDU; ROWOP-PDUs ::= CHOICE { create-row-request CreateRowRequest-PDU, delete-row-request DeleteRowRequest-PDU, edit-row-request EditRowRequest-PDU, get-row-request GetRowRequest-PDU, get-next-row-request GetNextRowRequest-PDU } CreateRowRequest-PDU ::= [9] IMPLICIT PDU DeleteRowRequest-PDU ::= [10] IMPLICIT PDU EditRowRequest-PDU ::= [11] IMPLICIT PDU GetRowRequest-PDU ::= [12] IMPLICIT PDU GetNextRowRequest-PDU ::= [13] IMPLICIT PDU EOS Working Group Expires October 2001 [Page 17] Internet Draft SNMP Row Operations Extensions 19 April 2001 END 7. Managed Object Definitions SNMP-ROWOP-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, OBJECT-IDENTITY, snmpModules FROM SNMPv2-SMI TEXTUAL-CONVENTION FROM SNMPv2-TC MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF; snmpRowopMIB MODULE-IDENTITY LAST-UPDATED "200104191653Z" ORGANIZATION "EOS Working Group" CONTACT-INFO "WG-EMail: eos@ops.ietf.org Subscribe: eos-request@ops.ietf.org Co-Chair: Dale Francisco Cisco Systems, Inc. postal: 80 West Tasman Drive San Jose, CA 95134 USA EMail: dfrancis@cisco.com phone: +1 408-527-9787 Co-Chair: Glenn Waters Nortel Networks postal: USA EMail: gww@nortelnetworks.com phone: Co-editor: Lauren Heintz Cisco Systems, Inc. postal: 130 Baytech Drive San Jose, CA 95134 USA EMail: lheintz@cisco.com phone: +1 408-853-6568 " DESCRIPTION "The SNMP Row Operations MIB" REVISION "200103280000Z" DESCRIPTION "The initial version, published in draft-ietf-eos-snmp-rowops-00.txt. " EOS Working Group Expires October 2001 [Page 18] Internet Draft SNMP Row Operations Extensions 19 April 2001 ::= { snmpModules TBD } -- Textual Conventions RowState ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "TBD" SYNTAX INTEGER {TBD} END 8. IANA Considerations This document requires IANASnmpExtendedProtocol values to be reserved for allowing command responders to advertise their ability to support the extensions outlined in this document. IANASnmpExtendedProtocol values are administered by IANA. IANASnmpExtendedProtocol is defined in SNMP-X-PROTOCOL-TC. 9. Intellectual Property The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. 10. Acknowledgements This document is the result of the efforts of the Evolution Of SNMP (EOS) Working Group. Some special thanks are in order to the following EOS WG members: EOS Working Group Expires October 2001 [Page 19] Internet Draft SNMP Row Operations Extensions 19 April 2001 TBD 11. Security Considerations TBD 12. References [RFC1155] Rose, M. and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP- based internets", STD 16, RFC 1155, May 1990. [RFC1157] Case, J., M. Fedor, M. Schoffstall and J. Davin, "The Simple Network Management Protocol", STD 15, RFC 1157, May 1990. [RFC1212] Rose, M. and K. McCloghrie, "Concise MIB Definitions", STD 16, RFC 1212, March 1991. [RFC1901] The SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Introduction to Community-based SNMPv2", RFC 1901, January 1996. [RFC2571] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing SNMP Management Frameworks", RFC 2571, April 1999. [RFC2578] McCloghrie, K., Perkins, D. and J. Schoenwaelder, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC2579] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [RFC-PROTO] Presuhn, R., Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Protocol Operations for the Simple Network Management Protocol", , April 2001. [RFC-TMM] Presuhn, R., Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Transport Mappings for the Simple Network Management Protocol", , April 2001. [RFC-MIB] Presuhn, R., Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Management Information Base for the Simple Network Management Protocol", , April 2001. [RFC-COEX] Frye, R., Levi, D., Routhier, S., and B. Wijnen, "Coexistence between Version 1, Version 2, and Version 3 of the Internet-standard Network Management Framework", , April 2001. [RFC1909] McCloghrie, K., Editor, "An Administrative Infrastructure for SNMPv2", RFC 1909, February 1996. [RFC1910] Waters, G., Editor, "User-based Security Model for SNMPv2", RFC 1910, February 1996. [RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 2279, January, 1998. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [BCP-11] Hovey, R. and S. Bradner, "The Organizations Involved in the IETF Standards Process", BCP 11, RFC 2028, October 1996. [RFC2863] McCloghrie, K. and F. Kastenholz. "The Interfaces Group MIB." RFC 2863, June 2000. [SNMP-MPD] Case, J., Harrington, D., Presuhn, R. and B. Wijnen, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)", , April 2001. [SNMP-USM] Blumenthal, U. and B. Wijnen, "The User-Based Security Model for Version 3 of the Simple Network Management Protocol (SNMPv3)", , April 2001. [SNMP-ACM] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based Access Control Model for the Simple Network Management Protocol (SNMP)", , February 1999. , April 2001. [RFC-APPL] Levi, D., Meyer, P. and B. Stewart, "SNMP EOS Working Group Expires October 2001 [Page 21] Internet Draft SNMP Row Operations Extensions 19 April 2001 Applications", , April 2001. [RFC2570] Case, J., Mundy, R., Partain, D. and B. Stewart, "Introduction to Version 3 of the Internet-standard Network Management Framework", , January 1999. [RFC-COEX] Frye, R., Levi, D., Routhier, S., and B. Wijnen, "Coexistence between Version 1, Version 2, and Version 3 of the Internet-standard Network Management Framework", , April 2001. EOS Working Group Expires October 2001 [Page 22] Internet Draft SNMP Row Operations Extensions 19 April 2001 13. Editor's Addresses Lauren Heintz Cisco Systems, Inc. 130 Baytech Drive San Jose, Ca 95134 Phone: +1 408-853-6568 EMail: lheintz@cisco.com EOS Working Group Expires October 2001 [Page 23] Internet Draft SNMP Row Operations Extensions 19 April 2001 APPENDIXES A. Impact to SNMP and other Protocols A.1. SNMPv3 An issue remains whether a new message processing model MUST be specified as part of the SNMPv3 (or later) standard. Otherwise, it is not seen that these extensions pose any impact to other SNMPv3 architectural components (i.e. USM, VACM) because the new protocol operations and their contents contain sufficient information (along with the information provided in whatever version-specific message wrapper they are contined within) to satisfy the abstract service interfaces for those components. However, these extensions are not compatible with the SNMPv3 proxy application (or any legacy SNMP application incorporating a message processing module that receives and processes or forwards SNMP messages). A.2. AgentX These extensions imply that AgentX will have to evolve in order to support the new protocol operations. For example, AgentX does not provide a delete PDU (to support DeleteRow), and neither does its TestSet PDU provide for a standard way to indicate whether the operation being performed maps to a CreateRow or EditRow request. Furthermore, master agents will need to know how to recognize and process the new protocol operations (i.e. distinguish rowIdentifiers from operands, logically expand the targeted object OIDs and map them to subtree registrations). B. Alternative Approaches This section will be deleted before going standards track. This document outlines one approach to achieving the design goals stated earlier. Several other approaches also exist. Here are some hints: - Use the same approach described herein except define a new "RowPDU" to further optimize OID suppression (i.e. get rid of the 0.1.X column subid notation). This may require a new kind of varbind list where each varbind is no longer an OID/value EOS Working Group Expires October 2001 [Page 24] Internet Draft SNMP Row Operations Extensions 19 April 2001 pair, but instead it is an Integer/Value pair. Similarly, this new PDU could contain one or more rowIdentifier items (one per rowOp). - Instead of having five new request types, use only one instead and perhaps have an operator within the request to indicate the nature of the operation. Also, the operator might be included within each rowOp contained within the request so that one protocol operation might contain mixed row operations (i.e. a createRow and deleteRow might co-exist in the same protocol request). - Maintain the same PDU structure, but re-define what a varbind is (i.e. one varbind might actually be able to contain a sequence of objects, all of which pertain to one row operation). You'd still have to define where/how you designate which row(s) and column(s) are affected. - Nix the RowState idea, keep RowStatus, and simply provide traditional protocol operations, perhaps with a way of minimizing overhead. In this case, we would tradeoff feature set richness with the potential of being able to provide easier transition solutions for legacy systems (i.e. the requests might be more easily translatable into conventional requests). - Some combination of the above, or other? C. Examples of Row Operations Each of the following examples assumes that the error-index and error-status fields of the manager initiated request are set to 0 and the request-id contains an appropriate value. C.1. CreateRow with RowStatus This protocol exchange illustrates the use of the CreateRow request to create two new rows in the snmpNotifyTable [RFC2573]. This table uses RowStatus, so we choose to explicitly set its value for each row, as desired (some impls may allow us to instead omit setting RowStatus and rely on implicit support for it). Note that the second rowOp inherits its table OID information from the previous rowOp (because 1.0 instructs this). CreateRow ( EOS Working Group Expires October 2001 [Page 25] Internet Draft SNMP Row Operations Extensions 19 April 2001 -- rowOp 1 -- rowIdentifier (table and instance) vb1.name = 1.3.6.1.6.3.13.1.1.1 -- snmpNotifyEntry vb1.value(OID) = 0.1.114.111.119.49 -- "row1" vb2.name = 0.1.2 -- snmpNotifyTag vb2.value(SnmpTagValue) = "tag1" vb3.name = 0.1.3 -- snmpNotifyType vb3.value(INT) = 1 -- trap -- skip snmpNotifyStorageType. Use DEFVAL vb4.name = 0.1.5 -- snmpNotifyRowStatus vb4.value(RowStatus) = createAndGo -- rowOp 2 -- rowIdentifier (table and instance) vb5.name = 1.0 -- inherit snmpNotifyEntry vb5.value(OID) = 0.1.114.111.119.50 -- "row2" vb6.name = 0.1.5 -- snmpNotifyRowStatus vb6.value(RowStatus) = createAndWait ) C.2. CreateRow with RowState This protocol exchange illustrates the use of the CreateRow request to create two new rows in the snmpNotifyTable [RFC2573] except that we pretend here that RowState was used in the design of that table instead of RowStatus. CreateRow ( -- rowOp 1 -- rowIdentifier (table and instance) vb1.name = 1.3.6.1.6.3.13.1.1.1 -- snmpNotifyEntry vb1.value(OID) = 0.1.114.111.119.49 -- "row1" vb2.name = 0.1.2 -- snmpNotifyTag vb2.value(SnmpTagValue) = "tag1" vb3.name = 0.1.3 -- snmpNotifyType vb3.value(INT) = 1 -- trap EOS Working Group Expires October 2001 [Page 26] Internet Draft SNMP Row Operations Extensions 19 April 2001 -- skip snmpNotifyStorageType. Use DEFVAL -- By omitting a RowState varbind, it is the -- same as setting RowState=Active. -- rowOp 2 -- rowIdentifier (table and instance) vb4.name = 1.0 -- inherit snmpNotifyEntry vb4.value(OID) = 0.1.114.111.119.50 -- "row2" -- Explicitly set RowState to an initial -- value because we don't want to go -- active just yet. Even though we hint -- for an initial value of NotInService, -- it's possible that the result might -- show NotReady (if the row as defined -- by CreateRow were not ready to go Active). vb5.name = 0.1.5 -- snmpNotifyRowState vb5.value(RowState) = NotInService ) C.3. DeleteRow This example illustrates how a DeleteRow request containing two row operations is formed to delete the two rows created in either of the two previous examples. Note that the rowIdentifier in the second rowOp does not inherit the table OID from the first rowOp. Although this is legal, it also increases the request PDU size unnecessarily. DeleteRow ( -- rowOp 1 -- rowIdentifier (table and instance) vb1.name = 1.3.6.1.6.3.13.1.1.1 -- snmpNotifyEntry vb1.value(OID) = 0.1.114.111.119.49 -- "row1" -- rowOp 2 -- rowIdentifier (table and instance) vb2.name = 1.3.6.1.6.3.13.1.1.1 -- snmpNotifyEntry vb2.value(OID) = 0.1.114.111.119.50 -- "row2" ) EOS Working Group Expires October 2001 [Page 27] Internet Draft SNMP Row Operations Extensions 19 April 2001 C.4. GetRow and GetNextRow This example illustrates how a GetRow request with three row operations is used to retrieve row information. Note that rowOp1 retrieves only the snmpNotifyTag from row1, rowOp2 retrieves only the RowStatus value from row2, and rowOp3 retrieves all values from row2. rowOp2 additionally attempts to retrieve an object that does not exist in the table row. The Response PDU is also shown afterward. GetNextRow performs very similarly to GetRow except that the Response PDU will contain the object names and values from the next row in the table (if any), or will contain exceptions as placeholders where the requested objects do not exist. GetRow ( -- rowOp 1 -- rowIdentifier (table and instance) vb1.name = 1.3.6.1.6.3.13.1.1.1 -- snmpNotifyEntry vb1.value(OID) = 0.1.114.111.119.49 -- "row1" vb2.name = 0.1.2 -- snmpNotifyTag vb2.value = NULL -- rowOp 2 -- rowIdentifier (table and instance) vb3.name = 1.0 -- inherit snmpNotifyEntry vb3.value(OID) = 0.1.114.111.119.50 -- "row2" vb4.name = 0.1.5 -- snmpNotifyRowStatus vb4.value = NULL vb5.name = 0.1.999 -- doesn't exist, but try anyway vb5.value = NULL -- rowOp 3 -- rowIdentifier (table and instance) vb6.name = 1.0 -- inherit snmpNotifyEntry vb6.value(OID) = 0.1.114.111.119.50 -- "row2" -- omitting all operands indicates "get all" row objects. ) EOS Working Group Expires October 2001 [Page 28] Internet Draft SNMP Row Operations Extensions 19 April 2001 ResponsePdu ( -- rowOp 1 -- rowIdentifier (table and instance) vb1.name = 1.3.6.1.6.3.13.1.1.1 -- snmpNotifyEntry vb1.value(OID) = 0.1.114.111.119.49 -- "row1" vb2.name = 0.1.2 -- snmpNotifyTag vb2.value(snmpTagValue) = "tag1" -- rowOp 2 -- rowIdentifier (table and instance) vb3.name = 1.0 -- inherit snmpNotifyEntry vb3.value(OID) = 0.1.114.111.119.50 -- "row2" vb4.name = 0.1.5 -- snmpNotifyRowStatus vb4.value(RowStatus) = NotInService vb5.name = 0.1.999 -- doesn't exist vb5.value(int) = NoSuchObject -- rowOp 3 -- rowIdentifier (table and instance) vb6.name = 1.0 -- inherit snmpNotifyEntry vb6.value(OID) = 0.1.114.111.119.50 -- "row2" vb7.name = 0.1.2 -- snmpNotifyTag vb7.value(SnmpTagValue) = "" vb8.name = 0.1.3 -- snmpNotifyType vb8.value(INT) = 1 -- trap vb9.name = 0.1.4 -- snmpNotifyStorageType vb9.value(StorageType) = nonVolatile vb10.name = 0.1.5 -- snmpNotifyRowStatus vb10.value(RowStatus) = NotInService ) D. Known issues This section will be deleted before becoming an RFC. These are known issues that need to be resolved before going EOS Working Group Expires October 2001 [Page 29] Internet Draft SNMP Row Operations Extensions 19 April 2001 standards track: - Which SNMP message versions can these rowop PDUs be wrapped in? SNMPv3 only? - It is possible to further optimize the above PDU. For example, the instancePart of the rowIdentifiers can omit the 0.1 prefix if the instancePart contains two or subids whose first two subids are not 0.1. Furthermore, where instancePart resolves to a single subid, we can use vb.type=Unsigned32 instead, and vb.value will contain the instancePart. The cost is added complexity (special case handling). - Another possible optimization is to allow rowIdentifier varbind names to begin with the prefix 0.0 as a substitute for 1.3.6.1. This would save a few bytes per rowOp. - Change the inheritance OID from 1.0 to 0.0? - GetNextRow: Should we disallow use of wildcarding (where no operand means get all operands)? Also, requiring a complete table entry OID (instead of a partial OID) is too strict? The argument for maintaining this strictness is that this document is trying to define efficient, predictable protocol operations. Also, the OID provided cannot appear to be an operand of the previous rowOp (if any). Traditional SetRequests provide plenty of opportunity for expressiveness, if one desires such flexibility and inefficiency. This strictness, for example, may allow master agents to minimize the number of subagent protocol operations needed to fulfill a GetNextRowRequest. - Should it be a requirement that all the new proto-ops are "translatable" into traditional SNMP requests? If so, DeleteRow is not translatable, so should it be deleted? Alternatively, we can allow DeleteRow to contain one optional operand so that a RowState (or RowStatus) operand can be included. In this way, DeleteRow requests can also be translated by, for example, proxies and master agents. Also, a CreateRow request cannot be translated into a SetRequest because there is no way to convey the "create-only-if-not- exists" semantic unless a RowStatus-like object is explicitly included in the request. If this is a requirement, we may need to instead adopt the kind of approach where we nix the RowState idea and simply provide traditional protocol operations that instead make use of OID suppression or compression techniques. Cognizant SNMP entities would need to be able to distinguish such requests from traditional request formats while non- cognizant entities would predictably reject the request in some EOS Working Group Expires October 2001 [Page 30] Internet Draft SNMP Row Operations Extensions 19 April 2001 way. Cognizant entities such as proxies and master agents could then translate the requests as is appropriate (though again, many of the original motivations and goals stated earlier may not be achieved with such a solution). - Are the names for RowState and its values appropriate? Perhaps the values should be something like: Undefined, Unlocked and Locked, and the TC name should be RowLock! - Do we need a GetBulkRow request that makes use of similar OID suppression techniques as defined herein? It might be argued this would be the most effective use of OID suppression. - Should the coexistence and transition section be moved to a different document? - Should we remove the comments about the timeout issues with RowStatus from the meat of the document? E. Full Copyright Statement Copyright (C) The Internet Society (2001). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. EOS Working Group Expires October 2001 [Page 31] Internet Draft SNMP Row Operations Extensions 19 April 2001 Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. EOS Working Group Expires October 2001 [Page 32] --------------95890FB17D956A2328D0EFE5-- From owner-agentx@dorothy.bmc.com Thu Apr 19 15:30:19 2001 Received: from creeper.bmc.com ([198.207.223.246]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA17188 for ; Thu, 19 Apr 2001 15:30:18 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by creeper.bmc.com (8.10.2/8.10.2) with ESMTP id f3JJP7Z02384; Thu, 19 Apr 2001 14:25:07 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id MAA12808 for agentx-list; Thu, 19 Apr 2001 12:20:11 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id MAA12797; Thu, 19 Apr 2001 12:20:01 -0700 (PDT) Received: from fw-us-hou-9.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with SMTP id f3JJHvX28945; Thu, 19 Apr 2001 14:17:57 -0500 (CDT) Received: from mumm.ibr.cs.tu-bs.de ([134.169.34.190]) by fw-us-hou-9.bmc.com; Thu, 19 Apr 2001 14:21:07 +0000 (CST) Received: from hansa.ibr.cs.tu-bs.de (IDENT:root@hansa [134.169.34.137]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.0) with ESMTP id VAA11013; Thu, 19 Apr 2001 21:21:04 +0200 (MET DST) Received: (from strauss@localhost) by hansa.ibr.cs.tu-bs.de (8.9.3/8.9.3) id VAA01645; Thu, 19 Apr 2001 21:21:04 +0200 X-Authentication-Warning: hansa.ibr.cs.tu-bs.de: strauss set sender to strauss@ibr.cs.tu-bs.de using -f From: Frank Strauss To: Randy Presuhn Cc: AgentX@dorothy.bmc.com Subject: Re: AgentX Charter/Milestone Update References: <200104191735.KAA06781@dorothy.bmc.com> Date: 19 Apr 2001 21:21:04 +0200 In-Reply-To: <200104191735.KAA06781@dorothy.bmc.com> Message-ID: Lines: 86 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-agentx@dorothy.bmc.com Precedence: bulk List-Id: IETF Agentx Working Group mailing list Hi! Bert> I would think that these USM things belong in the MASTER agent Bert> and so would not have any impact on agentx protocol >> In my opinion, the same is true for other MIB tables that model >> general functions or characteristics of an agent or its infrastructure, >> e.g., in the DISMAN-EVENT-MIB or the SNMPCONF-PM-MIB mentioned by Wes. Randy> I think it would be very nice to be able to put the disman event, Randy> schedule, script, and expression mibs into subagents. Why? -- In general, I feel more comfortable if all aspects of a service are covered by one process, just for clarity and resource consumption. In some other areas, criteria like robustness of the whole system if one subsystem is buggy, or performance if threading is not available, are mentioned. I'm not convinced that these are real arguments for sub-agents. Randy> The only thing that currently makes that difficult is the need Randy> to remember credentials and to consult the (abstract) Randy> isAccessAllowed service. I agree that these two aspects should be carefully considered for being conveyed by the AgentX protocol, although they would probably drop a general concept of AgentX: The subagent could not remain "SNMP ignorant", I assume. Randy> Building all these MIBs into the master agent implementation Randy> would be a configuration management (in the software sense) Randy> nightmare. Why? -- In general, I prefer to see all aspects of an agent configuration covered by one scheme. >> However, if we look at some tables more detailed on a per-row basis, >> it might be reasonable to let a sub-agent register single rows with >> the master, e.g. in case of the capabilities table. Randy> One can already perform such registrations with AgentX. Yes, that's what I mean. :-) If each sub-agent (no matter whether internal or via AgentX) registers its "capabilities rows", there is no need for a sub-agent that serves the whole capabilities table and a new protocol extension that allows other sub-agents to register their capabilities with this capabilities sub-agent. >> It is not the purpose of AgentX to be used for each and every MIB. >> It is the purpose of AgentX to allow to put the management >> instrumentation next to the instrumented entities in order to achieve >> a cleanly separated design where appropriate. Randy> Agreed. >> In cases where there is no instrumented entity, there is no need to >> move the implementation away from the master agent. Randy> In cases where there is no instrumented entity, a MIB would Randy> be pointless. Sorry, I've probably used the wrong words. By "cases where there is no instrumented entity" I mean those MIB objects that are not related to a piece of source code that already exists. Examples: If you want to implement the WWW-MIB or the MTA-MIB, then you usually do this for a specific service application. This application has data structures from which you can more or less easily derive your MIB object implementation. Here, AgentX would be my favorite choice. On the other hand, if you implement something like the DISMAN-SCRIPT-MIB or the any of the SNMP-???-MIBs there is no code that already exists going to be instrumented. Everything has to be done from scratch. Here, I see no need to create a new program and run a separate process for questionable reasons. For example, on the NET-SNMP platform the capability of dynamically loadable modules is my favorite choice. -frank From owner-agentx@dorothy.bmc.com Thu Apr 19 16:04:00 2001 Received: from creeper.bmc.com ([198.207.223.246]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA17757 for ; Thu, 19 Apr 2001 16:03:54 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by creeper.bmc.com (8.10.2/8.10.2) with ESMTP id f3JJxKa05339; Thu, 19 Apr 2001 14:59:20 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id MAA15581 for agentx-list; Thu, 19 Apr 2001 12:57:01 -0700 (PDT) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id MAA15572 for agentx@dorothy.bmc.com; Thu, 19 Apr 2001 12:56:53 -0700 (PDT) Date: Thu, 19 Apr 2001 12:56:53 -0700 (PDT) From: Randy Presuhn Message-Id: <200104191956.MAA15572@dorothy.bmc.com> To: agentx@dorothy.bmc.com Subject: Re: AgentX Charter/Milestone Update Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-agentx@dorothy.bmc.com Precedence: bulk List-Id: IETF Agentx Working Group mailing list X-MIME-Autoconverted: from 8bit to quoted-printable by creeper.bmc.com id f3JJxKa05339 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id QAA17757 Hi - > From: Frank Strauss > To: Randy Presuhn > Cc: AgentX@dorothy.bmc.com > Subject: Re: AgentX Charter/Milestone Update > References: <200104191735.KAA06781@dorothy.bmc.com> > Date: 19 Apr 2001 21:21:04 +0200 > In-Reply-To: <200104191735.KAA06781@dorothy.bmc.com> > Message-ID: > Lines: 86 ... > Randy> I think it would be very nice to be able to put the disman event, > Randy> schedule, script, and expression mibs into subagents. > > Why? -- In general, I feel more comfortable if all aspects of a > service are covered by one process, just for clarity and resource > consumption. I find it very hard to think of the event mib and the schedule mib as being a single service. I can imagine that vendors would want to be able to sell script and expression MIB implementations as distinct products. Implementing them within a single process is plausible, but not necessarily desirable. > In some other areas, criteria like robustness of the whole system if > one subsystem is buggy, or performance if threading is not available, > are mentioned. I'm not convinced that these are real arguments for > sub-agents. They are very real arguments for subagents, especially in multi-processor and embedded systems. Consider the job of assiging execution priorities in an embedded system. Putting the schedule and script mibs into the same process as the master agent would probably not be a good idea. > Randy> The only thing that currently makes that difficult is the need > Randy> to remember credentials and to consult the (abstract) > Randy> isAccessAllowed service. > > I agree that these two aspects should be carefully considered for > being conveyed by the AgentX protocol, although they would probably > drop a general concept of AgentX: The subagent could not remain "SNMP > ignorant", I assume. I wouldn't want to put them into the AgentX protocol. I think a separate protocol that can operate in parallel with AgentX would be easier to define, would also permit a more modular implementation, and would avoid overly complicating the state machine for set request processing. However, if we go down this path, I think the agentx working group would be the right place to do it. > Randy> Building all these MIBs into the master agent implementation > Randy> would be a configuration management (in the software sense) > Randy> nightmare. > > Why? -- In general, I prefer to see all aspects of an agent > configuration covered by one scheme. I mean "configuration management" in the software engineering sense: being able to track and control versions of the various components needed to build a system. Forcing implementation within the master agent locks customers into a single-vendor solution, and potentially results in the pain and anguish of "forklift" upgrades of the software. ... > If each sub-agent (no matter whether internal or via AgentX) registers > its "capabilities rows", there is no need for a sub-agent that serves > the whole capabilities table and a new protocol extension that allows > other sub-agents to register their capabilities with this capabilities > sub-agent. We're in violent agreement here. ... > >> In cases where there is no instrumented entity, there is no need to > >> move the implementation away from the master agent. > > Randy> In cases where there is no instrumented entity, a MIB would > Randy> be pointless. > > Sorry, I've probably used the wrong words. By "cases where there is no > instrumented entity" I mean those MIB objects that are not related to > a piece of source code that already exists. > > Examples: If you want to implement the WWW-MIB or the MTA-MIB, then > you usually do this for a specific service application. This > application has data structures from which you can more or less easily > derive your MIB object implementation. Here, AgentX would be my > favorite choice. On the other hand, if you implement something like > the DISMAN-SCRIPT-MIB or the any of the SNMP-???-MIBs there is no code > that already exists going to be instrumented. Not true. For years have been commercially available products with capabilities remarkably similar to the disman script MIB. It would be really nice to be able to manage these things using standard MIBs. > Everything has to be > done from scratch. Here, I see no need to create a new program and run > a separate process for questionable reasons. The fact that a particular resource that will need to be managed is newly developed is no reason to assume that the instrumentation should be built into the master agent. Consider newly developed commercial or custom hardware and software that is to be installed on platforms that already have their own agents. > For example, on the > NET-SNMP platform the capability of dynamically loadable modules is my > favorite choice. ... You must have more clout with the owners of the systems running those agents than I do with the IS department that runs our servers. :-) ------------------------------------------------------- Randy Presuhn randy_presuhn@bmc.com Voice: +1 408 546-1006 BMC Software, Inc. 1-3141 Fax: +1 408 965-0359 2141 North First Street http://www.bmc.com/ San José, California 95131 USA ------------------------------------------------------- My opinions and BMC's are independent variables. ------------------------------------------------------- From owner-agentx@dorothy.bmc.com Thu Apr 19 16:17:38 2001 Received: from creeper.bmc.com ([198.207.223.246]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA17928 for ; Thu, 19 Apr 2001 16:17:38 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by creeper.bmc.com (8.10.2/8.10.2) with ESMTP id f3JKDJp06643; Thu, 19 Apr 2001 15:13:19 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id NAA15813 for agentx-list; Thu, 19 Apr 2001 13:11:08 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id NAA15807; Thu, 19 Apr 2001 13:11:03 -0700 (PDT) Received: from fw-us-sjc-1.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with SMTP id f3JK8xs18503; Thu, 19 Apr 2001 15:09:00 -0500 (CDT) Received: from fwd03.sul.t-online.com by mailout06.sul.t-online.com with smtp id 14qKev-00059M-0A; Thu, 19 Apr 2001 22:04:09 +0200 Received: from fock.de (320061250925-0001@[217.81.143.99]) by fwd03.sul.t-online.com with esmtp id 14qKeq-1LBZJ2C; Thu, 19 Apr 2001 22:04:04 +0200 Message-ID: <3ADF45DE.B7A853EF@fock.de> Date: Thu, 19 Apr 2001 22:09:02 +0200 From: Frank.Fock@t-online.de (Frank Fock) Organization: AGENT++ X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Frank Strauss CC: Randy Presuhn , AgentX@dorothy.bmc.com Subject: Re: AgentX Charter/Milestone Update References: <200104191735.KAA06781@dorothy.bmc.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Sender: 320061250925-0001@t-dialin.net Sender: owner-agentx@dorothy.bmc.com Precedence: bulk List-Id: IETF Agentx Working Group mailing list Content-Transfer-Encoding: 7bit Hi Frank, Frank Strauss wrote: > Bert> I would think that these USM things belong in the MASTER agent > Bert> and so would not have any impact on agentx protocol > Agreed. > > Randy> I think it would be very nice to be able to put the disman event, > Randy> schedule, script, and expression mibs into subagents. > > Why? -- In general, I feel more comfortable if all aspects of a > service are covered by one process, just for clarity and resource > consumption. > > In some other areas, criteria like robustness of the whole system if > one subsystem is buggy, or performance if threading is not available, > are mentioned. I'm not convinced that these are real arguments for > sub-agents. > Agreed too. > > Randy> The only thing that currently makes that difficult is the need > Randy> to remember credentials and to consult the (abstract) > Randy> isAccessAllowed service. > > I agree that these two aspects should be carefully considered for > being conveyed by the AgentX protocol, although they would probably > drop a general concept of AgentX: The subagent could not remain "SNMP > ignorant", I assume. In addition the inter process communication between the master and the subagent will be quite complex too. Especially on the subagent side, because it must be capable to accept responses to its own "isAccessAllowed" requests while it is processing an AgentX request from the master agent. IMHO the overall cost of such a protocol operation is higher than its benefit. > Randy> Building all these MIBs into the master agent implementation > Randy> would be a configuration management (in the software sense) > Randy> nightmare. > > Why? -- In general, I prefer to see all aspects of an agent > configuration covered by one scheme. > I would prefer implementing those MIBs into the master agent too. Regards, Frank From owner-agentx@dorothy.bmc.com Fri Apr 20 08:23:04 2001 Received: from creeper.bmc.com ([198.207.223.246]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA10830 for ; Fri, 20 Apr 2001 08:23:03 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by creeper.bmc.com (8.10.2/8.10.2) with ESMTP id f3KCI2H29540; Fri, 20 Apr 2001 07:18:02 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id FAA06001 for agentx-list; Fri, 20 Apr 2001 05:15:01 -0700 (PDT) Received: from fw-us-hou-9.bmc.com (fw-us-hou1.bmc.com [172.17.0.250]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id FAA05996 for ; Fri, 20 Apr 2001 05:14:57 -0700 (PDT) Received: from c001.snv.cp.net (c001-h001.c001.snv.cp.net [209.228.32.115]) by fw-us-hou-9.bmc.com (8.9.1/8.9.1) with SMTP id HAA14243 for ; Fri, 20 Apr 2001 07:16:01 -0500 (CDT) Received: (cpmta 3721 invoked from network); 19 Apr 2001 22:08:49 -0700 Received: from unknown (HELO bnatale.AppliedSNMP.com) (38.203.142.102) by smtp.appliedsnmp.com (209.228.32.115) with SMTP; 19 Apr 2001 22:08:49 -0700 X-Sent: 20 Apr 2001 05:08:49 GMT Message-Id: <5.0.1.4.2.20010420011258.02ae6cc0@mail.AppliedSNMP.com> X-Sender: Bob.Natale@mail.AppliedSNMP.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.1 Date: Fri, 20 Apr 2001 01:13:26 -0400 To: Dave Shield From: Bob Natale Subject: Re: AgentX Charter/Milestone Update Cc: AgentX@dorothy.bmc.com In-Reply-To: <200104191030.LAA02486@daves.staff.csc.liv.ac.uk> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-agentx@dorothy.bmc.com Precedence: bulk List-Id: IETF Agentx Working Group mailing list At 4/19/2001:06:30 AM, Dave Shield wrote: Hi Dave, >> Apr 01 - Implementation reports formally solicited (Apr 23) >> Apr 01 - Interoperability reports formally solicited (Apr 30) > >I presume these will include details of the appropriate formats >as promised in the advance notice earlier this month ? Precisely. Cheers, BobN From owner-agentx@dorothy.bmc.com Fri Apr 20 11:43:05 2001 Received: from creeper.bmc.com ([198.207.223.246]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA13328 for ; Fri, 20 Apr 2001 11:43:04 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by creeper.bmc.com (8.10.2/8.10.2) with ESMTP id f3KFYhJ17772; Fri, 20 Apr 2001 10:34:43 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id IAA06301 for agentx-list; Fri, 20 Apr 2001 08:32:24 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id IAA06295; Fri, 20 Apr 2001 08:32:18 -0700 (PDT) Received: from fw-us-hou-9.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with SMTP id f3KFUD528091; Fri, 20 Apr 2001 10:30:14 -0500 (CDT) Received: from mumm.ibr.cs.tu-bs.de ([134.169.34.190]) by fw-us-hou-9.bmc.com; Fri, 20 Apr 2001 10:32:07 +0000 (CST) Received: from hansa.ibr.cs.tu-bs.de (IDENT:root@hansa [134.169.34.137]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.0) with ESMTP id RAA16549; Fri, 20 Apr 2001 17:31:20 +0200 (MET DST) Received: (from strauss@localhost) by hansa.ibr.cs.tu-bs.de (8.9.3/8.9.3) id RAA05220; Fri, 20 Apr 2001 17:31:20 +0200 X-Authentication-Warning: hansa.ibr.cs.tu-bs.de: strauss set sender to strauss@ibr.cs.tu-bs.de using -f From: Frank Strauss To: Randy Presuhn Cc: agentx@dorothy.bmc.com Subject: Re: AgentX Charter/Milestone Update References: <200104191956.MAA15572@dorothy.bmc.com> Date: 20 Apr 2001 17:31:20 +0200 In-Reply-To: <200104191956.MAA15572@dorothy.bmc.com> Message-ID: Lines: 112 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-agentx@dorothy.bmc.com Precedence: bulk List-Id: IETF Agentx Working Group mailing list Hi! >> In some other areas, criteria like robustness of the whole system if >> one subsystem is buggy, or performance if threading is not available, >> are mentioned. I'm not convinced that these are real arguments for >> sub-agents. Randy> They are very real arguments for subagents, especially in Randy> multi-processor and embedded systems. Well, I just don't believe that multiple processes are a solution to all these situations. Randy> Consider the job of assiging execution priorities in an Randy> embedded system. Putting the schedule and script mibs into the Randy> same process as the master agent would probably not be a good Randy> idea. For the Schedule MIB there is no problem with a single agent process. For the Script MIB there is only a problem with the executing scripts, not with the Script MIB implementation itself. BTW, this is how our Script MIB and Schedule MIB implementations work, and I never felt a need to change this. But I can slightly imagine that the needs in embedded systems may vary from those on hosts with a traditional operating system. Unfortunately, I have no experience with embedded systems. Randy> The only thing that currently makes that difficult is the need Randy> to remember credentials and to consult the (abstract) Randy> isAccessAllowed service. >> >> I agree that these two aspects should be carefully considered for >> being conveyed by the AgentX protocol, although they would probably >> drop a general concept of AgentX: The subagent could not remain "SNMP >> ignorant", I assume. Randy> I wouldn't want to put them into the AgentX protocol. I think Randy> a separate protocol that can operate in parallel with AgentX Randy> would be easier to define, would also permit a more modular Randy> implementation, and would avoid overly complicating the state Randy> machine for set request processing. I have not yet a biased feeling whether and how these new features should be addressed. Randy> However, if we go down this path, I think the agentx working group Randy> would be the right place to do it. Agreed. >> Examples: If you want to implement the WWW-MIB or the MTA-MIB, then >> you usually do this for a specific service application. This >> application has data structures from which you can more or less easily >> derive your MIB object implementation. Here, AgentX would be my >> favorite choice. On the other hand, if you implement something like >> the DISMAN-SCRIPT-MIB or the any of the SNMP-???-MIBs there is no code >> that already exists going to be instrumented. Randy> Not true. For years have been commercially available products with Randy> capabilities remarkably similar to the disman script MIB. What commercially available products do you think of? Randy> It would be really nice to be able to manage these things using Randy> standard MIBs. [Since I'm not aware of the answer to my question 4 lines above, I assume we are talking about a process execution environment like the usual OS process management subsystem.] Yes, but the DISMAN-SCRIPT-MIB is probably not the right choice. The Script MIB is not designed to manage scripts in existing runtime environments. It is designed for the special purpose of delegating management functionality to mid-level managers. Such scripts have a very special focus and thus the runtime environment and the Script MIB have some special characteristics. A MIB which is to some degree comparable and which is used for monitoring (and to a very limited degree controlling) processes on a host is the HOST-RESOURCES-MIB, which is `of the other kind' and which (at least in theory) makes sense to be implemented using AgentX. Unfortunately, the `program' that would have to be instrumented in this case is the OS kernel, which could pose a problem. ;-) Randy> The fact that a particular resource that will need to be Randy> managed is newly developed is no reason to assume that Randy> the instrumentation should be built into the master agent. Randy> Consider newly developed commercial or custom hardware and Randy> software that is to be installed on platforms that already Randy> have their own agents. Here, you are talking about "hardware" or "software" that is going to be managed. This "hardware" or "software" *does exist* and is going to be instrumented for management. I agree that AgentX is reasonable in this situation. This situation is different from the Script MIB (at least in my opion) or the Schedule MIB or some other MIBs. >> For example, on the NET-SNMP platform the capability of dynamically >> loadable modules is my favorite choice. Randy> You must have more clout with the owners of the systems running those Randy> agents than I do with the IS department that runs our servers. :-) To some degree I'm both in one person. Hope I'm not to schizophrenic. ;-) -frank From owner-agentx@dorothy.bmc.com Fri Apr 20 11:56:42 2001 Received: from creeper.bmc.com ([198.207.223.246]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA13544 for ; Fri, 20 Apr 2001 11:56:41 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by creeper.bmc.com (8.10.2/8.10.2) with ESMTP id f3KFir218796; Fri, 20 Apr 2001 10:44:54 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id IAA06348 for agentx-list; Fri, 20 Apr 2001 08:43:41 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id IAA06339 for ; Fri, 20 Apr 2001 08:43:36 -0700 (PDT) Received: from fw-us-hou-9.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with SMTP id f3KFfV902274 for ; Fri, 20 Apr 2001 10:41:31 -0500 (CDT) Received: from dns1.hardaker.davis.ca.us ([168.150.190.1]) by fw-us-hou-9.bmc.com; Fri, 20 Apr 2001 10:43:18 +0000 (CST) Received: (from hardaker@localhost) by wanderer.hardakers.net (8.9.3/8.9.3) id IAA01668; Fri, 20 Apr 2001 08:43:00 -0700 X-Authentication-Warning: wanderer.hardakers.net: hardaker set sender to wes@hardakers.net using -f To: Frank Strauss Cc: AgentX@dorothy.bmc.com Subject: Re: AgentX Charter/Milestone Update References: <2413FED0DFE6D111B3F90008C7FA61FB0C05779F@nl0006exch002u.nl.lucent.com> From: Wes Hardaker X-URL: http://dcas.ucdavis.edu/~hardaker Organization: Network Associates - NAI Labs X-Face: #qW^}a%m*T^{A:Cp}$R\"38+d}41-Z}uU8,r%F#c#s:~Nzp0G9](s?,K49KJ]s"*7gvRgA SrAvQc4@/}L7Qc=w{)]ACO\R{LF@S{pXfojjjGg6c;q6{~C}CxC^^&~(F]`1W)%9j/iS/ IM",B1M.?{w8ckLTYD'`|kTr\i\cgY)P4 In-Reply-To: (Frank Strauss's message of "19 Apr 2001 15:00:43 +0200") Message-ID: User-Agent: Gnus/5.090001 (Oort Gnus v0.01) XEmacs/21.2 (Terspichore) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: 20 Apr 2001 08:43:00 -0700 Lines: 46 Sender: owner-agentx@dorothy.bmc.com Precedence: bulk List-Id: IETF Agentx Working Group mailing list >>>>> On 19 Apr 2001 15:00:43 +0200, Frank Strauss said: Frank> In my opinion, the same is true for other MIB tables that model Frank> general functions or characteristics of an agent or its Frank> infrastructure, e.g., in the DISMAN-EVENT-MIB or the Frank> SNMPCONF-PM-MIB mentioned by Wes. Well, I agree to a large extent. My examples were certainly the extremes. However, I've already spoken with people (Jeff Case being one example) that would not want to put the SNMPCONF-PM-MIB in the master agent, so the desire is there. In a discussion that revolved around the capabilities table, agentx was explicitly discussed and it was decided that support for agentx simply wouldn't be possible without crippling the functionality that was being proposed. Frank> However, if we look at some tables more detailed on a per-row Frank> basis, it might be reasonable to let a sub-agent register Frank> single rows with the master, e.g. in case of the capabilities Frank> table. Which works as long as there isn't conflicts with multiple subagents registering the same row with possibly different values. Granted, this is somewhat of an impossible problem to solve without the external tables explicitly saying how to handle this case. Frank> It is not the purpose of AgentX to be used for each and every Frank> MIB. True. Frank> It is the purpose of AgentX to allow to put the management Frank> instrumentation next to the instrumented entities in order to Frank> achieve a cleanly separated design where appropriate. In cases Frank> where there is no instrumented entity, there is no need to move Frank> the implementation away from the master agent. You could easily imagine an external application being responsible for monitoring or for policy manipulation. I'd even venture to say that I doubt any management station implements their polling engine inside the master snmp demon running on the manager server. -- Wes Hardaker NAI Labs Network Associates From owner-agentx@dorothy.bmc.com Fri Apr 20 11:59:34 2001 Received: from creeper.bmc.com ([198.207.223.246]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA13603 for ; Fri, 20 Apr 2001 11:59:34 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by creeper.bmc.com (8.10.2/8.10.2) with ESMTP id f3KFptZ19459; Fri, 20 Apr 2001 10:51:55 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id IAA06374 for agentx-list; Fri, 20 Apr 2001 08:50:34 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id IAA06368; Fri, 20 Apr 2001 08:50:29 -0700 (PDT) Received: from fw-us-hou-9.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with SMTP id f3KFmP404639; Fri, 20 Apr 2001 10:48:25 -0500 (CDT) Received: from dns2.hardaker.davis.ca.us ([168.150.190.2]) by fw-us-hou-9.bmc.com; Fri, 20 Apr 2001 10:51:34 +0000 (CST) Received: (from hardaker@localhost) by wanderer.hardakers.net (8.9.3/8.9.3) id IAA01669; Fri, 20 Apr 2001 08:43:00 -0700 X-Authentication-Warning: wanderer.hardakers.net: hardaker set sender to wes@hardakers.net using -f To: Frank Strauss Cc: Randy Presuhn , AgentX@dorothy.bmc.com Subject: Re: AgentX Charter/Milestone Update References: <200104191735.KAA06781@dorothy.bmc.com> From: Wes Hardaker X-URL: http://dcas.ucdavis.edu/~hardaker Organization: Network Associates - NAI Labs X-Face: #qW^}a%m*T^{A:Cp}$R\"38+d}41-Z}uU8,r%F#c#s:~Nzp0G9](s?,K49KJ]s"*7gvRgA SrAvQc4@/}L7Qc=w{)]ACO\R{LF@S{pXfojjjGg6c;q6{~C}CxC^^&~(F]`1W)%9j/iS/ IM",B1M.?{w8ckLTYD'`|kTr\i\cgY)P4 In-Reply-To: (Frank Strauss's message of "19 Apr 2001 21:21:04 +0200") Message-ID: User-Agent: Gnus/5.090001 (Oort Gnus v0.01) XEmacs/21.2 (Terspichore) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: 20 Apr 2001 08:43:00 -0700 Lines: 19 Sender: owner-agentx@dorothy.bmc.com Precedence: bulk List-Id: IETF Agentx Working Group mailing list >>>>> On 19 Apr 2001 21:21:04 +0200, Frank Strauss said: Frank> In some other areas, criteria like robustness of the whole Frank> system if one subsystem is buggy, or performance if threading Frank> is not available, are mentioned. I'm not convinced that these Frank> are real arguments for sub-agents. Using that argument, why wouldn't you just implement everything inside a single process? I mean, why put the MTA-MIB inside the sendmail demon? Wouldn't it be just as easy to put the sendmail demon inside the snmp demon? It'd greatly simplify the process table: % ps ax 1 ... snmpd -- Wes Hardaker NAI Labs Network Associates From owner-agentx@dorothy.bmc.com Fri Apr 20 12:01:18 2001 Received: from creeper.bmc.com ([198.207.223.246]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA13686 for ; Fri, 20 Apr 2001 12:01:17 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by creeper.bmc.com (8.10.2/8.10.2) with ESMTP id f3KFrZF19703; Fri, 20 Apr 2001 10:53:35 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id IAA06387 for agentx-list; Fri, 20 Apr 2001 08:52:09 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id IAA06381; Fri, 20 Apr 2001 08:52:04 -0700 (PDT) Received: from fw-us-hou-9.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with SMTP id f3KFo0k05145; Fri, 20 Apr 2001 10:50:00 -0500 (CDT) Received: from mumm.ibr.cs.tu-bs.de ([134.169.34.190]) by fw-us-hou-9.bmc.com; Fri, 20 Apr 2001 10:53:11 +0000 (CST) Received: from hansa.ibr.cs.tu-bs.de (IDENT:root@hansa [134.169.34.137]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.0) with ESMTP id RAA17931; Fri, 20 Apr 2001 17:53:08 +0200 (MET DST) Received: (from strauss@localhost) by hansa.ibr.cs.tu-bs.de (8.9.3/8.9.3) id RAA06495; Fri, 20 Apr 2001 17:53:08 +0200 X-Authentication-Warning: hansa.ibr.cs.tu-bs.de: strauss set sender to strauss@ibr.cs.tu-bs.de using -f From: Frank Strauss To: Wes Hardaker Cc: Randy Presuhn , AgentX@dorothy.bmc.com Subject: Re: AgentX Charter/Milestone Update References: <200104191735.KAA06781@dorothy.bmc.com> Date: 20 Apr 2001 17:53:08 +0200 In-Reply-To: Message-ID: Lines: 20 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-agentx@dorothy.bmc.com Precedence: bulk List-Id: IETF Agentx Working Group mailing list Hi! Frank> In some other areas, criteria like robustness of the whole Frank> system if one subsystem is buggy, or performance if threading Frank> is not available, are mentioned. I'm not convinced that these Frank> are real arguments for sub-agents. Wes> Using that argument, why wouldn't you just implement everything inside Wes> a single process? I mean, why put the MTA-MIB inside the sendmail Wes> demon? Wouldn't it be just as easy to put the sendmail demon inside Wes> the snmp demon? It'd greatly simplify the process table: Wes> % ps ax Wes> 1 ... snmpd ;-) Why a process at all? Let's put it into the kernel! -frank From owner-agentx@dorothy.bmc.com Fri Apr 20 12:32:02 2001 Received: from creeper.bmc.com ([198.207.223.246]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA14196 for ; Fri, 20 Apr 2001 12:32:01 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by creeper.bmc.com (8.10.2/8.10.2) with ESMTP id f3KGMSO22392; Fri, 20 Apr 2001 11:22:28 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id JAA06451 for agentx-list; Fri, 20 Apr 2001 09:21:03 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id JAA06443; Fri, 20 Apr 2001 09:20:58 -0700 (PDT) Received: from fw-us-hou-9.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with SMTP id f3KGIrB15199; Fri, 20 Apr 2001 11:18:54 -0500 (CDT) Received: from dns2.hardaker.davis.ca.us ([168.150.190.2]) by fw-us-hou-9.bmc.com; Fri, 20 Apr 2001 11:22:04 +0000 (CST) Received: (from hardaker@localhost) by wanderer.hardakers.net (8.9.3/8.9.3) id JAA01270; Fri, 20 Apr 2001 09:22:03 -0700 X-Authentication-Warning: wanderer.hardakers.net: hardaker set sender to wes@hardakers.net using -f To: Frank Strauss Cc: Randy Presuhn , AgentX@dorothy.bmc.com Subject: Re: AgentX Charter/Milestone Update References: <200104191735.KAA06781@dorothy.bmc.com> From: Wes Hardaker X-URL: http://dcas.ucdavis.edu/~hardaker Organization: Network Associates - NAI Labs X-Face: #qW^}a%m*T^{A:Cp}$R\"38+d}41-Z}uU8,r%F#c#s:~Nzp0G9](s?,K49KJ]s"*7gvRgA SrAvQc4@/}L7Qc=w{)]ACO\R{LF@S{pXfojjjGg6c;q6{~C}CxC^^&~(F]`1W)%9j/iS/ IM",B1M.?{w8ckLTYD'`|kTr\i\cgY)P4 Date: 20 Apr 2001 09:22:03 -0700 In-Reply-To: (Frank Strauss's message of "20 Apr 2001 17:53:08 +0200") Message-ID: Lines: 15 User-Agent: Gnus/5.090001 (Oort Gnus v0.01) XEmacs/21.2 (Terspichore) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-agentx@dorothy.bmc.com Precedence: bulk List-Id: IETF Agentx Working Group mailing list >>>>> On 20 Apr 2001 17:53:08 +0200, Frank Strauss said: Wes> % ps ax Wes> 1 ... snmpd Frank> ;-) Frank> Why a process at all? Let's put it into the kernel! Good idea! Oh wait. That's DOS. -- "Ninjas aren't dangerous. They're more afraid of you than you are of them." From owner-agentx@dorothy.bmc.com Fri Apr 20 13:27:25 2001 Received: from creeper.bmc.com ([198.207.223.246]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA14996 for ; Fri, 20 Apr 2001 13:27:25 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by creeper.bmc.com (8.10.2/8.10.2) with ESMTP id f3KHIT127013; Fri, 20 Apr 2001 12:18:29 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id KAA09041 for agentx-list; Fri, 20 Apr 2001 10:16:41 -0700 (PDT) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id KAA09008 for agentx@dorothy.bmc.com; Fri, 20 Apr 2001 10:16:31 -0700 (PDT) Date: Fri, 20 Apr 2001 10:16:31 -0700 (PDT) From: Randy Presuhn Message-Id: <200104201716.KAA09008@dorothy.bmc.com> To: agentx@dorothy.bmc.com Subject: Re: AgentX Charter/Milestone Update Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-agentx@dorothy.bmc.com Precedence: bulk List-Id: IETF Agentx Working Group mailing list X-MIME-Autoconverted: from 8bit to quoted-printable by creeper.bmc.com id f3KHIT127013 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id NAA14996 Hi - > From: Frank Strauss > To: Randy Presuhn > Cc: agentx@dorothy.bmc.com > Subject: Re: AgentX Charter/Milestone Update > References: <200104191956.MAA15572@dorothy.bmc.com> > Date: 20 Apr 2001 17:31:20 +0200 > In-Reply-To: <200104191956.MAA15572@dorothy.bmc.com> > Message-ID: ... > Randy> Consider the job of assiging execution priorities in an > Randy> embedded system. Putting the schedule and script mibs into the > Randy> same process as the master agent would probably not be a good > Randy> idea. > > For the Schedule MIB there is no problem with a single agent process. Only if the implementors want their SNMP engine and the scheduler to have the same priority, address space, etc. For some implementation environments this is not a problem. For other implementation environments it could be a big problem. All I'm saying is that we should permit modular implementations. > For the Script MIB there is only a problem with the executing scripts, > not with the Script MIB implementation itself. This depends strongly on the implementation architecture. In this particular case, I'm more concerned about the real-world situation where the SNMP master agent and the script execution environments could come from different vendors. > BTW, this is how our Script MIB and Schedule MIB implementations work, > and I never felt a need to change this. I'm not saying you should change. I'm just saying that this particular approach is not the only one possible, and that in some environments there are reasons to want to support others. > But I can slightly imagine that the needs in embedded systems may vary > from those on hosts with a traditional operating system. Unfortunately, > I have no experience with embedded systems. Embedded systems have become much more Unix-y over the years, but in hard real-time environments, knowing which task will be doing what is still very important to ensure that deadlines will be met under all load conditions. When processing is divided among multiple processors running on hot-swappable, field-upgradable cards, there is often little choice but to go to some kind of subagent/master agent architecture. ... > Randy> Not true. For years have been commercially available products with > Randy> capabilities remarkably similar to the disman script MIB. > > What commercially available products do you think of? BMC PATROL comes to mind. It'd really be nice to permit folks to manage it using the disman script MIB in addition to our enterprise MIB. > Randy> It would be really nice to be able to manage these things using > Randy> standard MIBs. > > [Since I'm not aware of the answer to my question 4 lines above, I > assume we are talking about a process execution environment like the > usual OS process management subsystem.] No. Part of what PATROL does is done by intelligent agents executing scripts. The PATROL agent can be managed as an SNMP subagent. > Yes, but the DISMAN-SCRIPT-MIB is probably not the right choice. The > Script MIB is not designed to manage scripts in existing runtime > environments. It is designed for the special purpose of delegating > management functionality to mid-level managers. Such scripts have a > very special focus and thus the runtime environment and the Script MIB > have some special characteristics. This is exactly what PATROL does. > A MIB which is to some degree comparable and which is used for > monitoring (and to a very limited degree controlling) processes on a > host is the HOST-RESOURCES-MIB, which is `of the other kind' and which > (at least in theory) makes sense to be implemented using > AgentX. Unfortunately, the `program' that would have to be > instrumented in this case is the OS kernel, which could pose a > problem. ;-) We're talking about very different things. > Randy> The fact that a particular resource that will need to be > Randy> managed is newly developed is no reason to assume that > Randy> the instrumentation should be built into the master agent. > Randy> Consider newly developed commercial or custom hardware and > Randy> software that is to be installed on platforms that already > Randy> have their own agents. > > Here, you are talking about "hardware" or "software" that is going to > be managed. This "hardware" or "software" *does exist* and is going to > be instrumented for management. I agree that AgentX is reasonable in > this situation. This situation is different from the Script MIB (at > least in my opion) or the Schedule MIB or some other MIBs. I'm missing something here. How is it that the implementation of a script or schedule MIB that is being managed doesn't "exist"? After all, a scripting engine is just another piece of software. In causing other programs to be run based on its input stream, it's really no different from lpr or emacs. > >> For example, on the NET-SNMP platform the capability of dynamically > >> loadable modules is my favorite choice. > > Randy> You must have more clout with the owners of the systems running those > Randy> agents than I do with the IS department that runs our servers. :-) > > To some degree I'm both in one person. Hope I'm not to schizophrenic. ;-) ... That's perhaps a good part of the difference in our perspectives. I work with software deployed into multi-vendor environments where different organizations may have control over which software is used to perform the various functions in a system. Specifically, I'm considering the case where schedulers and script execution engines are deployed into environments with SNMP infrastructure that is on a separate maintenance / upgrade cycle, and perhaps even provided by a completely different vendor. The current situation results in multiple SNMP master agents installed on a box, resulting in confusion, administrative annoyances, and even such evils as proxy. :-) * 0.5 ------------------------------------------------------- Randy Presuhn randy_presuhn@bmc.com Voice: +1 408 546-1006 BMC Software, Inc. 1-3141 Fax: +1 408 965-0359 2141 North First Street http://www.bmc.com/ San José, California 95131 USA ------------------------------------------------------- My opinions and BMC's are independent variables. ------------------------------------------------------- From owner-agentx@dorothy.bmc.com Fri Apr 20 14:51:43 2001 Received: from creeper.bmc.com ([198.207.223.246]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA16324 for ; Fri, 20 Apr 2001 14:51:42 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by creeper.bmc.com (8.10.2/8.10.2) with ESMTP id f3KIhUj03980; Fri, 20 Apr 2001 13:43:30 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id LAA14959 for agentx-list; Fri, 20 Apr 2001 11:40:53 -0700 (PDT) Received: from babbler.bmc.com (babbler.bmc.com [172.17.0.116]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id LAA14954 for ; Fri, 20 Apr 2001 11:40:49 -0700 (PDT) Received: from ec03-hou.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id f3KIimT16583 for ; Fri, 20 Apr 2001 13:44:48 -0500 (CDT) Received: by ec03-hou.bmc.com with Internet Mail Service (5.5.2653.19) id <2KPR5QL8>; Fri, 20 Apr 2001 13:39:00 -0500 Message-ID: From: "Ayers, Mike" To: AgentX@dorothy.bmc.com Subject: RE: AgentX Charter/Milestone Update Date: Fri, 20 Apr 2001 13:41:38 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-agentx@dorothy.bmc.com Precedence: bulk List-Id: IETF Agentx Working Group mailing list A compilation... There is also USM, which needs the set of security credentials in order to support the Own Key Change objects. I would think that these USM things belong in the MASTER agent and so would not have any impact on agentx protocol That was supposed to be my point. There have been (at least one) MIB(s) all along which could not be supported by AgentX, so why change direction now for *proposed* MIBs? If there is real need for such changes, ther is plenty of room in the timetable to do it either as AgentXv2 or as a new "AgentI" (agent integration?) protocol. As an aside, I have yet to see a MIB, existing or proposed, that could not have circumvented such needs. Even the EoS RowOps proposal, upon light consideration, seems to be implementable by having the master agent reconstruct the RowOps PDUs into traditional PDUs to pass to the subagents. In my opinion, the same is true for other MIB tables that model general functions or characteristics of an agent or its infrastructure, e.g., in the DISMAN-EVENT-MIB or the SNMPCONF-PM-MIB mentioned by Wes. [SNIP] I don't think it is a good idea to discuss agent architecture from the external view, since the reasons for architectures tend to include a lot of internal considerations. One question is: "Is it possible to redesign and implement these functionalities using only AgentX as it stands?" I believe that the answer is "yes, except for authentication". Another question is: "Is it desireable to support capabilities beyond what is currently provided by AgentX?" I suspect that the answer will be "yes", but that does not change the first answer. Also please note that AgentX has no security built in, which makes the connection of subagents which need authentication intrinsically(sp?) dicey. I suspect that authentication will drive a second phase of this WG. Which works as long as there isn't conflicts with multiple subagents registering the same row with possibly different values. Granted, this is somewhat of an impossible problem to solve without the external tables explicitly saying how to handle this case. Unless I'm misreading you, the protocol for handling that case is already explicitly stated. /|/|ike From owner-agentx@dorothy.bmc.com Fri Apr 20 14:51:52 2001 Received: from creeper.bmc.com ([198.207.223.246]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA16336 for ; Fri, 20 Apr 2001 14:51:52 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by creeper.bmc.com (8.10.2/8.10.2) with ESMTP id f3KIhUl03985; Fri, 20 Apr 2001 13:43:30 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id LAA14969 for agentx-list; Fri, 20 Apr 2001 11:41:09 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id LAA14961; Fri, 20 Apr 2001 11:41:00 -0700 (PDT) Received: from fw-us-hou-9.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with SMTP id f3KIctg29909; Fri, 20 Apr 2001 13:38:55 -0500 (CDT) Received: from netmail2.alcatel.com ([128.251.168.51]) by fw-us-hou-9.bmc.com; Fri, 20 Apr 2001 13:42:05 +0000 (CST) Received: from postal.adn.alcatel.com (workstation.alcatel.com [198.205.33.79] (may be forged)) by netmail2.alcatel.com (8.9.1/8.9.1) with ESMTP id NAA27376; Fri, 20 Apr 2001 13:42:04 -0500 (CDT) Received: from usa.alcatel.com ([198.205.41.133]) by postal.adn.alcatel.com (Netscape Messaging Server 3.6) with ESMTP id AAA3B0D; Fri, 20 Apr 2001 14:55:20 -0400 Message-ID: <3AE0823E.ACB34672@usa.alcatel.com> Date: Fri, 20 Apr 2001 14:38:54 -0400 From: Ken Andrews Organization: Alcatel X-Mailer: Mozilla 4.61 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Frank Strauss CC: Randy Presuhn , agentx@dorothy.bmc.com Subject: Re: AgentX Charter/Milestone Update References: <200104191956.MAA15572@dorothy.bmc.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-agentx@dorothy.bmc.com Precedence: bulk List-Id: IETF Agentx Working Group mailing list Content-Transfer-Encoding: 7bit Hello, I thought that I'd drop in my $.02 since I am caught in a reald world situation that is very applicable. We have implemented agentX to make our development more modular. rught now I think that we have about 20 or so sub-agents being developed in the U.S., Belgium, and India. Aside from makeing the development modular agentX made the overall system more fault tolerent since the restart of a single sub-agent does not stop the rest of the system from being managed. One of these sub-agents provides operations very similar to DISMAN-SCRIPT-MIB. The problem is how do you allow an admin to control everyones tasks and allow only users to control thier own tasks? It looks like our plan will be to use vacmFilters. This means that I (The Master Agent developer) will need to create "special" vacmViewFilter entries every time a usmUser is created. ugh! It would be a lot cleaner if I could pass security information in the AgentX request that would allow the sub-agent to do its additional security processing. For example I would like to be able to pass information about the authentication method (USM vs Community string or other) and some data such as the community string (and maybe source address) or the security name used in the SNMP request. Regards, Ken Frank Strauss wrote: > > Hi! > > >> In some other areas, criteria like robustness of the whole system if > >> one subsystem is buggy, or performance if threading is not available, > >> are mentioned. I'm not convinced that these are real arguments for > >> sub-agents. > > Randy> They are very real arguments for subagents, especially in > Randy> multi-processor and embedded systems. > > Well, I just don't believe that multiple processes are a solution > to all these situations. > > Randy> Consider the job of assiging execution priorities in an > Randy> embedded system. Putting the schedule and script mibs into the > Randy> same process as the master agent would probably not be a good > Randy> idea. > > For the Schedule MIB there is no problem with a single agent process. > For the Script MIB there is only a problem with the executing scripts, > not with the Script MIB implementation itself. > > BTW, this is how our Script MIB and Schedule MIB implementations work, > and I never felt a need to change this. > > But I can slightly imagine that the needs in embedded systems may vary > from those on hosts with a traditional operating system. Unfortunately, > I have no experience with embedded systems. > > Randy> The only thing that currently makes that difficult is the need > Randy> to remember credentials and to consult the (abstract) > Randy> isAccessAllowed service. > >> > >> I agree that these two aspects should be carefully considered for > >> being conveyed by the AgentX protocol, although they would probably > >> drop a general concept of AgentX: The subagent could not remain "SNMP > >> ignorant", I assume. > > Randy> I wouldn't want to put them into the AgentX protocol. I think > Randy> a separate protocol that can operate in parallel with AgentX > Randy> would be easier to define, would also permit a more modular > Randy> implementation, and would avoid overly complicating the state > Randy> machine for set request processing. > > I have not yet a biased feeling whether and how these new features > should be addressed. > > Randy> However, if we go down this path, I think the agentx working group > Randy> would be the right place to do it. > > Agreed. > > >> Examples: If you want to implement the WWW-MIB or the MTA-MIB, then > >> you usually do this for a specific service application. This > >> application has data structures from which you can more or less easily > >> derive your MIB object implementation. Here, AgentX would be my > >> favorite choice. On the other hand, if you implement something like > >> the DISMAN-SCRIPT-MIB or the any of the SNMP-???-MIBs there is no code > >> that already exists going to be instrumented. > > Randy> Not true. For years have been commercially available products with > Randy> capabilities remarkably similar to the disman script MIB. > > What commercially available products do you think of? > > Randy> It would be really nice to be able to manage these things using > Randy> standard MIBs. > > [Since I'm not aware of the answer to my question 4 lines above, I > assume we are talking about a process execution environment like the > usual OS process management subsystem.] > Yes, but the DISMAN-SCRIPT-MIB is probably not the right choice. The > Script MIB is not designed to manage scripts in existing runtime > environments. It is designed for the special purpose of delegating > management functionality to mid-level managers. Such scripts have a > very special focus and thus the runtime environment and the Script MIB > have some special characteristics. > > A MIB which is to some degree comparable and which is used for > monitoring (and to a very limited degree controlling) processes on a > host is the HOST-RESOURCES-MIB, which is `of the other kind' and which > (at least in theory) makes sense to be implemented using > AgentX. Unfortunately, the `program' that would have to be > instrumented in this case is the OS kernel, which could pose a > problem. ;-) > > Randy> The fact that a particular resource that will need to be > Randy> managed is newly developed is no reason to assume that > Randy> the instrumentation should be built into the master agent. > Randy> Consider newly developed commercial or custom hardware and > Randy> software that is to be installed on platforms that already > Randy> have their own agents. > > Here, you are talking about "hardware" or "software" that is going to > be managed. This "hardware" or "software" *does exist* and is going to > be instrumented for management. I agree that AgentX is reasonable in > this situation. This situation is different from the Script MIB (at > least in my opion) or the Schedule MIB or some other MIBs. > > >> For example, on the NET-SNMP platform the capability of dynamically > >> loadable modules is my favorite choice. > > Randy> You must have more clout with the owners of the systems running those > Randy> agents than I do with the IS department that runs our servers. :-) > > To some degree I'm both in one person. Hope I'm not to schizophrenic. ;-) > > -frank -- Ken Andrews ken.andrews@usa.alcatel.com Office # 703-679-6476 Fax # 703-679-6450 We all ride the same road From owner-agentx@dorothy.bmc.com Fri Apr 20 15:07:06 2001 Received: from creeper.bmc.com ([198.207.223.246]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA16526 for ; Fri, 20 Apr 2001 15:07:05 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by creeper.bmc.com (8.10.2/8.10.2) with ESMTP id f3KIxUq05243; Fri, 20 Apr 2001 13:59:30 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id LAA15565 for agentx-list; Fri, 20 Apr 2001 11:58:11 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id LAA15560 for ; Fri, 20 Apr 2001 11:58:06 -0700 (PDT) Received: from fw-us-hou-9.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with SMTP id f3KIu2O05087 for ; Fri, 20 Apr 2001 13:56:02 -0500 (CDT) Received: from c001-h008.c001.snv.cp.net ([209.228.32.122]) by fw-us-hou-9.bmc.com; Fri, 20 Apr 2001 13:59:11 +0000 (CST) Received: (cpmta 22569 invoked from network); 20 Apr 2001 11:59:00 -0700 Received: from unknown (HELO bnatale.AppliedSNMP.com) (38.203.142.102) by smtp.appliedsnmp.com (209.228.32.122) with SMTP; 20 Apr 2001 11:59:00 -0700 X-Sent: 20 Apr 2001 18:59:00 GMT Message-Id: <5.0.1.4.2.20010420145801.01f51028@mail.AppliedSNMP.com> X-Sender: Bob.Natale@mail.AppliedSNMP.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.1 Date: Fri, 20 Apr 2001 15:03:39 -0400 To: AgentX@dorothy.bmc.com From: Bob Natale Subject: Re: AgentX Charter/Milestone Update In-Reply-To: References: <200104191735.KAA06781@dorothy.bmc.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-agentx@dorothy.bmc.com Precedence: bulk List-Id: IETF Agentx Working Group mailing list At 4/20/2001:12:22 PM, Wes Hardaker wrote: >>>>>> On 20 Apr 2001 17:53:08 +0200, Frank Strauss said: >Wes> % ps ax >Wes> 1 ... snmpd > >Frank> ;-) >Frank> Why a process at all? Let's put it into the kernel! > >Good idea! >Oh wait. That's DOS. Excellent piece of word-smithing, both of you. Nice way to conclude the point: - the case for sub-agents has been well-established by the marketplace - a standard sub-agent technology (AgentX) can adequately address many/most real-world cases - there are some perfectly valid real-world cases were the cost/benefit ratio does not favor a de jure standard approach - various requirement-sets, design choices, and/or implementation strategies can result in different allocations of real-world cases among those two solution sets. Cordially, BobN >-- >"Ninjas aren't dangerous. They're more afraid of you than you are of them." From owner-agentx@dorothy.bmc.com Fri Apr 20 15:13:43 2001 Received: from creeper.bmc.com ([198.207.223.246]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA16637 for ; Fri, 20 Apr 2001 15:13:42 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by creeper.bmc.com (8.10.2/8.10.2) with ESMTP id f3KJ5vD05807; Fri, 20 Apr 2001 14:05:57 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id MAA15823 for agentx-list; Fri, 20 Apr 2001 12:04:35 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id MAA15814 for ; Fri, 20 Apr 2001 12:04:28 -0700 (PDT) Received: from fw-us-hou-9.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with SMTP id f3KJ2Nk07220 for ; Fri, 20 Apr 2001 14:02:24 -0500 (CDT) Received: from c001-h000.c001.snv.cp.net ([209.228.32.114]) by fw-us-hou-9.bmc.com; Fri, 20 Apr 2001 14:05:32 +0000 (CST) Received: (cpmta 24768 invoked from network); 20 Apr 2001 12:05:27 -0700 Received: from unknown (HELO bnatale.AppliedSNMP.com) (38.203.142.102) by smtp.appliedsnmp.com (209.228.32.114) with SMTP; 20 Apr 2001 12:05:27 -0700 X-Sent: 20 Apr 2001 19:05:27 GMT Message-Id: <5.0.1.4.2.20010420150428.01f5ec50@mail.AppliedSNMP.com> X-Sender: Bob.Natale@mail.AppliedSNMP.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.1 Date: Fri, 20 Apr 2001 15:10:06 -0400 To: agentx@dorothy.bmc.com From: Bob Natale Subject: Re: AgentX Charter/Milestone Update In-Reply-To: <200104201716.KAA09008@dorothy.bmc.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-agentx@dorothy.bmc.com Precedence: bulk List-Id: IETF Agentx Working Group mailing list At 4/20/2001:01:16 PM, Randy Presuhn wrote: ><...deleted most of an argument I agree with 100%...> > >The current situation results in multiple SNMP master agents >installed on a box, resulting in confusion, administrative >annoyances, and even such evils as proxy. :-) * 0.5 Right. And has also, IMHO, done a lot to retard the expansion of SNMP into devices/applications for which it is otherwise an excellent choice. Continuing implementation, interoperability, deployment, and development of AgentX products (commercial or otherwise) and promoting the specs to Draft Standard status still promises to help rectify that situation. Fortunately, in the time it has taken for us to come this far with AgentX, not a lot seems to have changed in the marketplace -- at least not in any dominant way -- so the basic problem/opportunity is still there. BobN From owner-agentx@dorothy.bmc.com Fri Apr 20 16:41:02 2001 Received: from creeper.bmc.com ([198.207.223.246]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA17726 for ; Fri, 20 Apr 2001 16:41:01 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by creeper.bmc.com (8.10.2/8.10.2) with ESMTP id f3KKWoB12746; Fri, 20 Apr 2001 15:32:50 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id NAA19185 for agentx-list; Fri, 20 Apr 2001 13:29:16 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id NAA19179 for ; Fri, 20 Apr 2001 13:29:10 -0700 (PDT) Received: from fw-us-hou-9.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with SMTP id f3KKR6V04975 for ; Fri, 20 Apr 2001 15:27:06 -0500 (CDT) Received: from c001-h008.c001.snv.cp.net ([209.228.32.122]) by fw-us-hou-9.bmc.com; Fri, 20 Apr 2001 15:30:16 +0000 (CST) Received: (cpmta 21695 invoked from network); 20 Apr 2001 13:28:54 -0700 Received: from unknown (HELO bnatale.AppliedSNMP.com) (38.203.142.102) by smtp.appliedsnmp.com (209.228.32.122) with SMTP; 20 Apr 2001 13:28:54 -0700 X-Sent: 20 Apr 2001 20:28:54 GMT Message-Id: <5.0.1.4.2.20010420162544.01f16268@mail.AppliedSNMP.com> X-Sender: Bob.Natale@mail.AppliedSNMP.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.1 Date: Fri, 20 Apr 2001 16:33:33 -0400 To: AgentX@dorothy.bmc.com From: Bob Natale Subject: RE: AgentX Charter/Milestone Update In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-agentx@dorothy.bmc.com Precedence: bulk List-Id: IETF Agentx Working Group mailing list At 4/20/2001:02:41 PM, Ayers, Mike wrote: ><...> > As an aside, I have yet to see a MIB, existing or proposed, that >could not have circumvented such needs. Quite right, Mike. In part, the fact that many new MIB efforts since the initial standardization of AgentX have not taken it into consideration during the design phase reflects a failure on my part to generate adequate PR for the protocol, both within the IETF and in the industry at-large. Lots of reasons for that -- some good, some lame. I plan to make a concerted effort to rectify that error once we move past (or get very near to completing) the new milestones for this round. > Even the EoS RowOps proposal, upon light consideration, seems to be >implementable by having the master agent reconstruct the RowOps PDUs >into traditional PDUs to pass to the subagents. Good idea for further discussion. We'll have to see how such a flexible approach might fly in practice. ><...> BobN From owner-agentx@dorothy.bmc.com Fri Apr 20 16:41:18 2001 Received: from creeper.bmc.com ([198.207.223.246]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA17742 for ; Fri, 20 Apr 2001 16:41:17 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by creeper.bmc.com (8.10.2/8.10.2) with ESMTP id f3KKXWK12867; Fri, 20 Apr 2001 15:33:32 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id NAA19333 for agentx-list; Fri, 20 Apr 2001 13:31:19 -0700 (PDT) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id NAA19320; Fri, 20 Apr 2001 13:31:11 -0700 (PDT) Date: Fri, 20 Apr 2001 13:31:11 -0700 (PDT) From: Randy Presuhn Message-Id: <200104202031.NAA19320@dorothy.bmc.com> To: agentx@dorothy.bmc.com, disman@dorothy.bmc.com Subject: BRIEF outage of agentx & disman lists Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-agentx@dorothy.bmc.com Precedence: bulk List-Id: IETF Agentx Working Group mailing list X-MIME-Autoconverted: from 8bit to quoted-printable by creeper.bmc.com id f3KKXWK12867 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id QAA17742 Hi - Our operations folk have informed me that amethyst.bmc.com (the host for the archives of the disman and agentx lists) needs to be re-booted. This will happen at 14:00 Pacific Daylight Time today, April 20, 2001. It should be back online by 14:30. ------------------------------------------------------- Randy Presuhn randy_presuhn@bmc.com Voice: +1 408 546-1006 BMC Software, Inc. 1-3141 Fax: +1 408 965-0359 2141 North First Street http://www.bmc.com/ San José, California 95131 USA ------------------------------------------------------- My opinions and BMC's are independent variables. ------------------------------------------------------- From owner-agentx@dorothy.bmc.com Fri Apr 20 17:35:21 2001 Received: from creeper.bmc.com ([198.207.223.246]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA18371 for ; Fri, 20 Apr 2001 17:35:21 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by creeper.bmc.com (8.10.2/8.10.2) with ESMTP id f3KLRWr17149; Fri, 20 Apr 2001 16:27:33 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id OAA22884 for agentx-list; Fri, 20 Apr 2001 14:26:09 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id OAA22872 for ; Fri, 20 Apr 2001 14:25:44 -0700 (PDT) Received: from fw-us-hou-9.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with SMTP id f3KLNeg23339 for ; Fri, 20 Apr 2001 16:23:40 -0500 (CDT) Received: from sj-msg-core-2.cisco.com ([171.69.43.88]) by fw-us-hou-9.bmc.com; Fri, 20 Apr 2001 16:26:50 +0000 (CST) Received: from fedex.cisco.com (fedex.cisco.com [171.69.18.27]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id OAA12455; Fri, 20 Apr 2001 14:27:16 -0700 (PDT) Received: from cisco.com (lheintz-dsl3.cisco.com [10.21.194.36]) by fedex.cisco.com (Mirapoint) with ESMTP id AEM22468 (AUTH lheintz); Fri, 20 Apr 2001 14:26:26 -0700 (PDT) Message-ID: <3AE0A9BD.F6040E15@cisco.com> Date: Fri, 20 Apr 2001 14:27:25 -0700 From: Lauren Heintz X-Mailer: Mozilla 4.73 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Bob Natale CC: AgentX@dorothy.bmc.com Subject: Re: AgentX Charter/Milestone Update References: <5.0.1.4.2.20010420162544.01f16268@mail.AppliedSNMP.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-agentx@dorothy.bmc.com Precedence: bulk List-Id: IETF Agentx Working Group mailing list Content-Transfer-Encoding: 7bit Hi, > > Even the EoS RowOps proposal, upon light consideration, seems to be > >implementable by having the master agent reconstruct the RowOps PDUs > >into traditional PDUs to pass to the subagents. > > Good idea for further discussion. We'll have to see how such a flexible > approach might fly in practice. The rowop PDUs as defined in the current draft can indeed by translated into convention Sets/gets, but only with some loss of semantics in some cases, and only if the cmd generator takes care to address certain issues when deciding what to put into the PDUs. In other words, not all EOS row operations (as defined) are translatable. That draft discusses this issue a bit. It is not yet an EOS requirement that any new rowops MUST NOT impact the current AgentX protocol (rather, only minimize such impact, whatever that means). Thanks, Lauren From owner-agentx@dorothy.bmc.com Sat Apr 21 07:08:41 2001 Received: from creeper.bmc.com ([198.207.223.246]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA09254 for ; Sat, 21 Apr 2001 07:08:41 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by creeper.bmc.com (8.10.2/8.10.2) with ESMTP id f3LAxda19703; Sat, 21 Apr 2001 05:59:40 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id DAA24429 for agentx-list; Sat, 21 Apr 2001 03:54:17 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id DAA24423; Sat, 21 Apr 2001 03:54:12 -0700 (PDT) Received: from fw-us-hou-9.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with SMTP id f3LAtIS04190; Sat, 21 Apr 2001 05:55:18 -0500 (CDT) Received: from mumm.ibr.cs.tu-bs.de ([134.169.34.190]) by fw-us-hou-9.bmc.com; Sat, 21 Apr 2001 05:55:18 +0000 (CST) Received: from hansa.ibr.cs.tu-bs.de (IDENT:root@hansa [134.169.34.137]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.0) with ESMTP id MAA14277; Sat, 21 Apr 2001 12:55:16 +0200 (MET DST) Received: (from strauss@localhost) by hansa.ibr.cs.tu-bs.de (8.9.3/8.9.3) id MAA00533; Sat, 21 Apr 2001 12:55:15 +0200 X-Authentication-Warning: hansa.ibr.cs.tu-bs.de: strauss set sender to strauss@ibr.cs.tu-bs.de using -f From: Frank Strauss To: Randy Presuhn Cc: agentx@dorothy.bmc.com Subject: Re: AgentX Charter/Milestone Update References: <200104201716.KAA09008@dorothy.bmc.com> Date: 21 Apr 2001 12:55:15 +0200 In-Reply-To: <200104201716.KAA09008@dorothy.bmc.com> Message-ID: Lines: 100 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-agentx@dorothy.bmc.com Precedence: bulk List-Id: IETF Agentx Working Group mailing list Hi! Randy> [...] All I'm saying is that we should permit modular Randy> implementations. [...] Randy> I'm just saying that this Randy> particular approach is not the only one possible, and that Randy> in some environments there are reasons to want to support Randy> others. I absolutely agree. >> But I can slightly imagine that the needs in embedded systems may vary >> from those on hosts with a traditional operating system. Unfortunately, >> I have no experience with embedded systems. Randy> Embedded systems have become much more Unix-y over the years, Randy> but in hard real-time environments, knowing which task will Randy> be doing what is still very important to ensure that deadlines Randy> will be met under all load conditions. When processing is Randy> divided among multiple processors running on hot-swappable, Randy> field-upgradable cards, there is often little choice but to Randy> go to some kind of subagent/master agent architecture. Ok. I understand. Thank you, Randy. Randy> Not true. For years have been commercially available products with Randy> capabilities remarkably similar to the disman script MIB. >> >> What commercially available products do you think of? Randy> BMC PATROL comes to mind. It'd really be nice to permit Randy> folks to manage it using the disman script MIB in addition Randy> to our enterprise MIB. Randy> It would be really nice to be able to manage these things using Randy> standard MIBs. >> >> [Since I'm not aware of the answer to my question 4 lines above, I >> assume we are talking about a process execution environment like the >> usual OS process management subsystem.] Randy> No. Part of what PATROL does is done by intelligent agents executing Randy> scripts. The PATROL agent can be managed as an SNMP subagent. Ok. I understand this argumentation. However, in the architecture of our DISMAN-SCRIPT-MIB implementation this would probably just lead to an additional PATROL runtime engine talking SMX to the agent. [For the rest of this topic it's now obvious that I made the wrong assumption and we were talking about different things.] Randy> The fact that a particular resource that will need to be Randy> managed is newly developed is no reason to assume that Randy> the instrumentation should be built into the master agent. Randy> Consider newly developed commercial or custom hardware and Randy> software that is to be installed on platforms that already Randy> have their own agents. >> >> Here, you are talking about "hardware" or "software" that is going to >> be managed. This "hardware" or "software" *does exist* and is going to >> be instrumented for management. I agree that AgentX is reasonable in >> this situation. This situation is different from the Script MIB (at >> least in my opion) or the Schedule MIB or some other MIBs. Randy> I'm missing something here. How is it that the implementation Randy> of a script or schedule MIB that is being managed doesn't Randy> "exist"? After all, a scripting engine is just another piece Randy> of software. In causing other programs to be run based on Randy> its input stream, it's really no different from lpr or emacs. I understand your argument. I was too much prejudiced by the architecture of our implementation. Now, I can also imagine an architecture, where a runtime system as a spearate process registers Script MIB objects via AgentX (although some nasty questions come to my mind, but let's not delve into the details any further at this point. ;-)). But how about some other MIB examples: DISMAN-SCHEDULE-MIB, SNMP-NOTIFICATION-MIB, DISMAN-EXPRESSION-MIB, DISMAN-EVENT-MIB. Can you think of any piece of real hardware or software being managed via these MIBs or would you say these MIBs themselves give a functionality that people want to use? Let me pick the DISMAN-SCHEDULE-MIB example: Sure, in the end there is a scheduler, and managers can use the management interface to make use of this managable scheduler. But the initial need for the user is to have a MIB that allows to schedule management actions. It is not to manage the scheduler. Hence (despite from other reasons you have conviced me of, like software configuration management) I see no reason to set up a separate process. This is different from printer or web services. I thank you, Wes and Ken for enlighten me, that there are other reasons for using a sub-agent architecture than those that came to my mind in the first place. -frank From owner-agentx@dorothy.bmc.com Wed Apr 25 02:41:49 2001 Received: from creeper.bmc.com ([198.207.223.246]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA08461 for ; Wed, 25 Apr 2001 02:41:49 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by creeper.bmc.com (8.10.2/8.10.2) with ESMTP id f3P6ZUJ07931; Wed, 25 Apr 2001 01:35:30 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id XAA16769 for agentx-list; Tue, 24 Apr 2001 23:30:55 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id XAA16764 for ; Tue, 24 Apr 2001 23:30:50 -0700 (PDT) From: Bob.Natale@AppliedSNMP.com Received: from fw-us-hou-9.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with SMTP id f3P6VsZ10417 for ; Wed, 25 Apr 2001 01:31:54 -0500 (CDT) Received: from c001-h008.c001.snv.cp.net ([209.228.32.122]) by fw-us-hou-9.bmc.com; Wed, 25 Apr 2001 01:31:56 +0000 (CST) Received: (cpmta 29096 invoked from network); 24 Apr 2001 23:31:54 -0700 Received: from unknown (HELO bnatale.AppliedSNMP.com) (38.203.142.102) by smtp.appliedsnmp.com (209.228.32.122) with SMTP; 24 Apr 2001 23:31:54 -0700 X-Sent: 25 Apr 2001 06:31:54 GMT Message-Id: <5.0.1.4.2.20010425013655.026b5e60@plymouth.acec.com> X-Sender: bnatale@plymouth.acec.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.1 Date: Wed, 25 Apr 2001 02:34:54 -0400 To: agentx@dorothy.bmc.com Subject: AgentX implementation reports requested Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-agentx@dorothy.bmc.com Precedence: bulk List-Id: IETF Agentx Working Group mailing list AgentX Implementation Report Solicitation date: April 25, 2001 Desired due date: May 11, 2001 Required due date: May 18, 2001 Draft summary report posted to list by WG Chair: May 21, 2001 Final summary report submitted to IESG by WG Chair: May 31, 2001 Please complete a separate report for each distinct implementation. Please return all reports to the WG Chair, Bob.Natale@AppliedSNMP.com. We would appreciate having the reports copied to the AgentX list as well (agentx@dorothy.bmc.com). If you do not copy the list (or otherwise submit a report to the list), the report will be used only for the purpose of producing the overall summary report. Please use any of the "Comments:" areas to note areas of the specifications that were particularly difficult to implement due to complexity, ambiguity, inconsistency, incompleteness, etc. It is very important for us to identify any implementation hurdles here. You may also use these areas for any other notes that you consider helpful or otherwise worthy of WG attention. Use as much space as necessary. In the end, we need to show that IESG that we have at least two independent and interoperable implementations of all AgentX features for advancement to Draft Standard status. I will solicit interoperability reports with an analogous format next week (interoperability reports may come from end-users of the implementations as well as from implementors themselves). Report date: __________________________________________________ Submitted by: __________________________________________________ Organization: __________________________________________________ E-mail address: __________________________________________________ Implementation name: __________________________________________________ Implementation type: ___ Master and/or ___ Sub-Agent and/or ___ Toolkit Runtime platform(s): __________________________________________________ Reported version id: __________________________________________________ If Master Agent, did you implement: SNMPv1 support in master agent: ___ Yes ___ No Comments: SNMPv2c support in master agent: ___ Yes ___ No Comments: SNMPv3 support in master agent: ___ Yes ___ No Comments: If Sub-Agent, what MIB(s) did you implement: Comments: (Please identify each specific MIB.) If Toolkit, please identify: Development languages supported: Comments: Development platforms supported: Comments: Runtime platforms supported: Comments: For all implementations: Did you implement the following PDU types: agentx-Open-PDU: ___ Yes ___ No, but plan to within ___ months Comments: agentx-Close-PDU: ___ Yes ___ No, but plan to within ___ months Comments: agentx-Register-PDU: ___ Yes ___ No, but plan to within ___ months Comments: agentx-Unregister-PDU: ___ Yes ___ No, but plan to within ___ months Comments: agentx-Get-PDU: ___ Yes ___ No, but plan to within ___ months Comments: agentx-GetNext-PDU: ___ Yes ___ No, but plan to within ___ months Comments: agentx-GetBulk-PDU: ___ Yes ___ No, but plan to within ___ months Comments: agentx-TestSet-PDU: ___ Yes ___ No, but plan to within ___ months Comments: agentx-Commit-PDU: ___ Yes ___ No, but plan to within ___ months Comments: agentx-Set-PDU: ___ Yes ___ No, but plan to within ___ months Comments: agentx-UndoSet-PDU: ___ Yes ___ No, but plan to within ___ months Comments: agentx-CleanupSet-PDU: ___ Yes ___ No, but plan to within ___ months Comments: agentx-Notify-PDU: ___ Yes ___ No, but plan to within ___ months Comments: agentx-Ping-PDU: ___ Yes ___ No, but plan to within ___ months Comments: agentx-IndexAllocate-PDU: ___ Yes ___ No, but plan to within ___ months Comments: agentx-IndexDeallocate-PDU: ___ Yes ___ No, but plan to within ___ months Comments: agentx-AddAgentCaps-PDU: ___ Yes ___ No, but plan to within ___ months Comments: agentx-RemoveAgentCaps-PDU: ___ Yes ___ No, but plan to within ___ months Comments: agentx-Response-PDU: ___ Yes ___ No, but plan to within ___ months Comments: Does this implementation have interoperability experience with at least one other independent implementation with respect to: Registration operations: ___ Yes ___ No, but plan to within ___ months Comments: Registration priorities: ___ Yes ___ No, but plan to within ___ months Comments: Index allocation operations: ___ Yes ___ No, but plan to within ___ months Comments: Index deallocation operations: ___ Yes ___ No, but plan to within ___ months Comments: Multiple sub-agent connections: ___ Yes ___ No, but plan to within ___ months Comments: Connecting sub-agent(s) to multiple master agents: ___ Yes ___ No, but plan to within ___ months Comments: Detecting loss of connection of sub-agent(s): ___ Yes ___ No, but plan to within ___ months Comments: Detecting loss of connection with master agent(s): ___ Yes ___ No, but plan to within ___ months Comments: What transport mappings did you implement: TCP/IP on port 705: ___ Yes ___ No, but plan to within ___ months Comments: UNIX Domain Sockets on "/var/agentx/master": ___ Yes ___ No, but plan to within ___ months Comments: UNIX Domain Sockets on other endpoints: ___ Yes ___ No, but plan to within ___ months Comments: Other(s): ___ Yes ___ No, but plan to within ___ months Comments: (Please indicate at least type(s) and connection specifics.) Did you implement the AgentX MIB (RFC2742): ___ Yes ___ No, but plan to within ___ months Comments: Did you satisfy the agentxMIBCompliance MODULE-COMPLIANCE requirements:: ___ Yes ___ No, but plan to within ___ months Comments: Did you implement the MIB as an integral part of the master agent: ___ Yes ___ No Comments: Did you implement the MIB in an AgentX sub-agent: ___ Yes ___ No Comments: Please record any other comments or notes you deem useful for the record: Comments: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Bob Natale AgentX WG Chair From owner-agentx@dorothy.bmc.com Thu Apr 26 15:18:04 2001 Received: from creeper.bmc.com ([198.207.223.246]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA16695 for ; Thu, 26 Apr 2001 15:18:04 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by creeper.bmc.com (8.10.2/8.10.2) with ESMTP id f3QJBx713405; Thu, 26 Apr 2001 14:11:59 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id MAA26326 for agentx-list; Thu, 26 Apr 2001 12:02:48 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id MAA26321 for ; Thu, 26 Apr 2001 12:02:42 -0700 (PDT) Received: from fw-us-hou-9.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with SMTP id f3QJ3jd10001 for ; Thu, 26 Apr 2001 14:03:45 -0500 (CDT) Received: from lespaul.process.com ([192.42.95.27]) by fw-us-hou-9.bmc.com; Thu, 26 Apr 2001 14:03:50 +0000 (CST) Received: by lespaul.process.com with Internet Mail Service (5.5.2653.19) id ; Thu, 26 Apr 2001 15:03:49 -0400 Message-ID: <63D30D6E10CFD11190A90000F805FE860381E994@lespaul.process.com> From: Richard Whalen To: "'Bob.Natale@AppliedSNMP.com'" Cc: "'agentx@dorothy.bmc.com'" Subject: RE: AgentX implementation reports requested Date: Thu, 26 Apr 2001 15:03:48 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-agentx@dorothy.bmc.com Precedence: bulk List-Id: IETF Agentx Working Group mailing list AgentX Implementation Report Report date: __April 25, 2001________________________________________________ Submitted by: _Richard Whalen__________________________________ Organization: __Process Software, LLC___________________________ E-mail address: __WhalenR@process.com_______________________ Implementation name: __MultiNet, released August 2000; TCPware, released April 2001 Implementation type: _X_ Master and/or _X_ Sub-Agent and/or _X_ Toolkit The initial goal was to implement a master agent. The creation of test programs for the master agent led to the creation of the toolkit and sub-agents. Runtime platform(s): __OpenVMS VAX V5.5-2 to V7.3, OpenVMS AXP V6.1 to V7.3 Reported version id: __MultiNet V4.3A; TCPware V5.5-3_____________________ If Master Agent, did you implement: SNMPv1 support in master agent: _X_ Yes ___ No Comments: Agent X support was added on to an existing SNMPv1 master agent that has SMUX and a proprietary subagent interface. The same code base is used in two different products, hence I consider this to be a single implementation. To provide a level of security, the master agent must be supplied with a list of IP addresses that subagents can connect from. SNMPv2c support in master agent: ___ Yes ___ No Comments: SNMPv3 support in master agent: ___ Yes ___ No Comments: If Sub-Agent, what MIB(s) did you implement: Comments: (Please identify each specific MIB.) Partial implementation of RFC 2788 at enterprises.105.2.21 Partial implementation of RFC 2789 at enterprises.105.3.25 If Toolkit, please identify: Internal tool kit used for instrumenting services to present MIB information. Interface descriptions have not been included in product documentation as there are rough edges and it currently requires significant knowledge of Agent X in order to build response PDUs. Development languages supported: All supported on VMS Comments: Code is written in C. VMS has a well defined calling standard that allows routines written in any language to be used by any other. Development platforms supported: OpenVMS VAX and OpenVMS AXP Comments: Runtime platforms supported: OpenVMS VAX and OpenVMS AXP Comments: For all implementations: Did you implement the following PDU types: agentx-Open-PDU: _X_ Yes ___ No, but plan to within ___ months Comments: agentx-Close-PDU: _X_ Yes ___ No, but plan to within ___ months Comments: agentx-Register-PDU: _X_ Yes ___ No, but plan to within ___ months Comments: agentx-Unregister-PDU: _X_ Yes ___ No, but plan to within ___ months Comments: agentx-Get-PDU: _X_ Yes ___ No, but plan to within ___ months Comments: agentx-GetNext-PDU: _X_ Yes ___ No, but plan to within ___ months Comments: agentx-GetBulk-PDU: _X_ Yes ___ No, but plan to within ___ months Comments: agentx-TestSet-PDU: _X_ Yes ___ No, but plan to within ___ months Comments: agentx-Commit-PDU: _X_ Yes ___ No, but plan to within ___ months Comments: agentx-Set-PDU: ___ Yes _X_ No, but plan to within ___ months Comments: I don't see this described in RFC 2741 agentx-UndoSet-PDU: _X_ Yes ___ No, but plan to within ___ months Comments: agentx-CleanupSet-PDU: _X_ Yes ___ No, but plan to within ___ months Comments: agentx-Notify-PDU: _X_ Yes ___ No, but plan to within ___ months Comments: There were difficulties here due to misunderstanding the required OIDs specified in RFC 2741. There were difficulties due to translating the SNMPv2 trap information into a SNMPv1 trap due to misunderstanding RFC2089, section 3.3 agentx-Ping-PDU: _X_ Yes ___ No, but plan to within ___ months Comments: Master agent does not send pings, tool kit subagents may send pings. agentx-IndexAllocate-PDU: ___ Yes _X_ No, but plan to within ___ months Comments: Subagents that it was initially intended to be used with do not use IndexAllocate, so this was put off until needed. Some research into what is needed to be done to implement this has been done. agentx-IndexDeallocate-PDU: ___ Yes _X_ No, but plan to within ___ months Comments: See IndexAllocate Comment. agentx-AddAgentCaps-PDU: ___ Yes _X_ No, but plan to within ___ months Comments: No immediate subagent need, put off until needed and better understood. agentx-RemoveAgentCaps-PDU: ___ Yes _X_ No, but plan to within ___ months Comments: See AddAgentCaps. agentx-Response-PDU: _X_ Yes ___ No, but plan to within ___ months Comments: Master agent handles Response-PDU. Master agent had some problems with receiving pings while waiting for responses; these have been resolved. Toolkit does not provide a mechanism for building response PDUs. Does this implementation have interoperability experience with at least one other independent implementation with respect to: Registration operations: _X_ Yes ___ No, but plan to within ___ months Comments: Master agent only. Registration priorities: ___ Yes _X_ No, but plan to within ___ months Comments: Index allocation operations: ___ Yes _X_ No, but plan to within ___ months Comments: Index deallocation operations: ___ Yes _X_ No, but plan to within ___ months Comments: Multiple sub-agent connections: _X_ Yes ___ No, but plan to within ___ months Comments: Connecting sub-agent(s) to multiple master agents: ___ Yes _X_ No, but plan to within ___ months Comments: Detecting loss of connection of sub-agent(s): ___ Yes _X_ No, but plan to within ___ months Comments: Loss of connection is detected when PDUs are not respond to, but master agent does not actively send pings. Detecting loss of connection with master agent(s): ___ Yes _X_ No, but plan to within ___ months Comments: The privately developed subagents developed connect to localhost, and are designed to be used in the context of the TCP/IP product implementations that they come with. It would be difficult to test them with independent implementations of the master agent. They do detect loss of connection with the master agent in our environment. What transport mappings did you implement: TCP/IP on port 705: _X_ Yes ___ No, but plan to within ___ months Comments: UNIX Domain Sockets on "/var/agentx/master": ___ Yes _X_ No, but plan to within ___ months Comments: UNIX Domain Sockets on other endpoints: ___ Yes _X_ No, but plan to within ___ months Comments: Other(s): ___ Yes ___ No, but plan to within ___ months Comments: (Please indicate at least type(s) and connection specifics.) Did you implement the AgentX MIB (RFC2742): _X_ Yes ___ No, but plan to within ___ months Comments: Did you satisfy the agentxMIBCompliance MODULE-COMPLIANCE requirements:: ___ Yes _X_ No, but plan to within ___ months Comments: Only recently came to understand what is needed for MODULE-COMPLIANCE since reading "The Simple Times" Vol 8, Num 1. Did you implement the MIB as an integral part of the master agent: _X_ Yes ___ No Comments: Did you implement the MIB in an AgentX sub-agent: ___ Yes _X_ No Comments: The idea of implementing RFC2742 as a sub-agent never occurred to me because of its need for information that is maintained by the master agent. After thinking about it a bit, I see how it could be done as a component (thread) of the master agent with the SNMP operations being done through AgentX. That type of implementation would not have been possible with our existing SNMP master agent. Please record any other comments or notes you deem useful for the record: Comments: The master agent is being used with the subagent tool kit provided in Compaq TCP/IP Services for OpenVMS V5.1 to allow Compaq Insight Manager MIB agents to run. It has also been tested with Comtek Services NMServer for OpenVMS. The subagents that we provide use our own tool kit. From owner-agentx@dorothy.bmc.com Thu Apr 26 18:32:00 2001 Received: from creeper.bmc.com ([198.207.223.246]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA23976 for ; Thu, 26 Apr 2001 18:31:59 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by creeper.bmc.com (8.10.2/8.10.2) with ESMTP id f3QMQTR29512; Thu, 26 Apr 2001 17:26:29 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id PAA01690 for agentx-list; Thu, 26 Apr 2001 15:23:19 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id PAA01685 for ; Thu, 26 Apr 2001 15:23:14 -0700 (PDT) Received: from fw-us-hou-9.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with SMTP id f3QMOGD18255 for ; Thu, 26 Apr 2001 17:24:16 -0500 (CDT) Received: from mailout03.sul.t-online.com ([194.25.134.81]) by fw-us-hou-9.bmc.com; Thu, 26 Apr 2001 17:24:21 +0000 (CST) Received: from fwd04.sul.t-online.com by mailout03.sul.t-online.com with smtp id 14suBN-00081v-04; Fri, 27 Apr 2001 00:24:17 +0200 Received: from fock.de (320061250925-0001@[217.81.136.130]) by fwd04.sul.t-online.com with esmtp id 14suBW-04C8GWC; Fri, 27 Apr 2001 00:24:26 +0200 Message-ID: <3AE8A188.8098B4C3@fock.de> Date: Fri, 27 Apr 2001 00:30:32 +0200 From: Frank.Fock@t-online.de (Frank Fock) Organization: AGENT++ X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Bob.Natale@AppliedSNMP.com CC: agentx@dorothy.bmc.com Subject: Re: AgentX implementation reports requested References: <5.0.1.4.2.20010425013655.026b5e60@plymouth.acec.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Sender: 320061250925-0001@t-dialin.net Sender: owner-agentx@dorothy.bmc.com Precedence: bulk List-Id: IETF Agentx Working Group mailing list Content-Transfer-Encoding: 7bit Report date: 2001-04-26________________________________________ Submitted by: Frank Fock_________________________________________ Organization: AGENT++ (http://www.agentpp.com)_____________________ E-mail address: fock@agentpp.com___________________________________ Implementation name: AgentX++__________________________________________ Implementation type: _X_ Master and/or _X_ Sub-Agent and/or _X_ Toolkit Runtime platform(s): Unix (i.e., Solaris, Linux), WinNT/2000____________________ Reported version id: 1_________________________________________________ If Master Agent, did you implement: SNMPv1 support in master agent: _X_ Yes ___ No Comments: SNMPv2c support in master agent: _X_ Yes ___ No Comments: SNMPv3 support in master agent: _X_ Yes ___ No Comments: AgentX context support in master agent is only available with SNMPv3 support enabled. If Sub-Agent, what MIB(s) did you implement: Comments: Master and subagent implemented as examples. One subagent example implements the interfaces substree with row registration and index allocation for Linux. If Toolkit, please identify: Development languages supported: C++ Comments: ANSI C++ with pthreads or Visual C++ 6 Development platforms supported: Unix, WinNT/2000 Comments: Runtime platforms supported: Unix, WinNT/2000 Comments: For all implementations: Did you implement the following PDU types: agentx-Open-PDU: _X_ Yes ___ No, but plan to within ___ months Comments: agentx-Close-PDU: _X_ Yes ___ No, but plan to within ___ months Comments: agentx-Register-PDU: _X_ Yes ___ No, but plan to within ___ months Comments: agentx-Unregister-PDU: _X_ Yes ___ No, but plan to within ___ months Comments: agentx-Get-PDU: _X_ Yes ___ No, but plan to within ___ months Comments: agentx-GetNext-PDU: _X_ Yes ___ No, but plan to within ___ months Comments: agentx-GetBulk-PDU: _X_ Yes ___ No, but plan to within ___ months Comments: agentx-TestSet-PDU: _X_ Yes ___ No, but plan to within ___ months Comments: agentx-Commit-PDU: _X_ Yes ___ No, but plan to within ___ months Comments: agentx-Set-PDU: _X_ Yes ___ No, but plan to within ___ months Comments: I thin TestSet is meant here? agentx-UndoSet-PDU: _X_ Yes ___ No, but plan to within ___ months Comments: agentx-CleanupSet-PDU: _X_ Yes ___ No, but plan to within ___ months Comments: agentx-Notify-PDU: _X_ Yes ___ No, but plan to within ___ months Comments: agentx-Ping-PDU: _X_ Yes ___ No, but plan to within ___ months Comments: Toolkit does not use it itself, but API user may use it. agentx-IndexAllocate-PDU: _X_ Yes ___ No, but plan to within ___ months Comments: It should be made clear within the AgentX RFC, that a subagent implementation should always try to register also the table (entry) object with the same priority as it registers its rows. This approach ensures that a noSuchInstance error is returned when accessing a non-existent row. Otherwise the master agent might return noSuchObject if no subagent have registered the table object. agentx-IndexDeallocate-PDU: _X_ Yes ___ No, but plan to within ___ months Comments: agentx-AddAgentCaps-PDU: _X_ Yes ___ No, but plan to within ___ months Comments: agentx-RemoveAgentCaps-PDU: _X_ Yes ___ No, but plan to within ___ months Comments: agentx-Response-PDU: _X_ Yes ___ No, but plan to within ___ months Comments: Does this implementation have interoperability experience with at least one other independent implementation with respect to: Registration operations: _X_ Yes ___ No, but plan to within ___ months Comments: NET-SNMP Registration priorities: _X_ Yes ___ No, but plan to within ___ months Comments: NET-SNMP Index allocation operations: _X_ Yes ___ No, but plan to within ___ months Comments: Index allocation seems to work with NET-SNMP master, however the NET-SNMP 4.2 master agent does not propagate requests with correct range (i.e., lower bound in AgentX PDU is lower than originally requested OID for GETNEXT operations). Index deallocation operations: _X_ Yes ___ No, but plan to within ___ months Comments: Multiple sub-agent connections: _X_ Yes ___ No, but plan to within ___ months Comments: NET-SNMP Connecting sub-agent(s) to multiple master agents: ___ Yes _X_ No, but plan to within ___ months Comments: AgentX++ subagents only support one connection, however multiple sessions may be run over that connection. Detecting loss of connection of sub-agent(s): _X_ Yes ___ No, but plan to within ___ months Comments: Detecting loss of connection with master agent(s): _X_ Yes ___ No, but plan to within ___ months Comments: What transport mappings did you implement: TCP/IP on port 705: _X_ Yes ___ No, but plan to within ___ months Comments: API user have to implement security mechanisms. UNIX Domain Sockets on "/var/agentx/master": _X_ Yes ___ No, but plan to within ___ months Comments: Of course, for Unix OS only. UNIX Domain Sockets on other endpoints: _X_ Yes ___ No, but plan to within ___ months Comments: May be configured by API user. Other(s): ___ Yes ___ No, but plan to within ___ months Comments: (Please indicate at least type(s) and connection specifics.) Did you implement the AgentX MIB (RFC2742): _X_ Yes ___ No, but plan to within ___ months Comments: Did you satisfy the agentxMIBCompliance MODULE-COMPLIANCE requirements:: _X_ Yes ___ No, but plan to within ___ months Comments: Did you implement the MIB as an integral part of the master agent: _X_ Yes ___ No Comments: Did you implement the MIB in an AgentX sub-agent: ___ Yes _X_ No Comments: This seems not to be straightforward, because subagent will have to get all information from master -> why not implementing it there? Regards, Frank Fock