From owner-disman@dorothy.bmc.com Sun Jan 2 00:37:07 2000 Received: from tangelo.bmc.com (fw-us-hou-2.bmc.com [198.207.223.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA02753 for ; Sun, 2 Jan 2000 00:37:07 -0500 (EST) Received: from dorothy.bmc.com (dorothy.bmc.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id XAA18060; Sat, 1 Jan 2000 23:36:47 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id VAA20186 for disman-list; Sat, 1 Jan 2000 21:32:23 -0800 (PST) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id VAA20118; Sat, 1 Jan 2000 21:28:48 -0800 (PST) Date: Sat, 1 Jan 2000 21:28:48 -0800 (PST) From: Randy Presuhn Message-Id: <200001020528.VAA20118@dorothy.bmc.com> To: agentx@dorothy.peer.com, disman@dorothy.peer.com Subject: agentx/disman y2k test - please ignore Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list Content-Transfer-Encoding: 7bit Hi - This is merely a test of the mailing lists. Please ignore. ------------------------------------------------------------------------ Randy Presuhn randy_presuhn@bmc.com http://www.bmc.com/ Voice: +1 408 546-1006 BMC Software, Inc. 1-3141 2141 N. First Street Fax: +1 408 965-0359 San Jose, California 95131 USA ------------------------------------------------------------------------ Any relationship between my opinions and BMC's should be coincidental. ------------------------------------------------------------------------ From owner-disman@dorothy.bmc.com Mon Jan 3 11:15:42 2000 Received: from tangelo.bmc.com (fw-us-hou-2.bmc.com [198.207.223.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03500 for ; Mon, 3 Jan 2000 11:15:41 -0500 (EST) Received: from dorothy.peer.com (dorothy.bmc.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id KAA02722; Mon, 3 Jan 2000 10:15:22 -0600 (CST) Received: (from root@localhost) by dorothy.peer.com (8.8.6 (PHNE_12836)/8.8.6) id IAA23129 for disman-list; Mon, 3 Jan 2000 08:10:26 -0800 (PST) Received: from tangelo.bmc.com (root@tangelo.bmc.com [172.17.7.166]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id IAA23124 for ; Mon, 3 Jan 2000 08:10:21 -0800 (PST) Received: from fw-us-hou1.bmc.com (fw-us-hou1.bmc.com [172.17.0.250]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with SMTP id KAA01758 for ; Mon, 3 Jan 2000 10:10:42 -0600 (CST) Received: from henkell.ibr.cs.tu-bs.de (schoenw@henkell [134.169.34.191]) by mumm (8.9.3/8.9.3) with ESMTP id RAA26014; Mon, 3 Jan 2000 17:10:39 +0100 (MET) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id RAA17842; Mon, 3 Jan 2000 17:10:39 +0100 Date: Mon, 3 Jan 2000 17:10:39 +0100 Message-Id: <200001031610.RAA17842@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: luchuk@snmp.com CC: disman@dorothy.peer.com, luchuk@snmp.com In-reply-to: <199912291953.OAA02578@seymour47.SNMP.COM> (message from Alan Luchuk on Wed, 29 Dec 1999 14:53:01 -0500 (EST)) Subject: Re: Sched/Script MIB issues References: <199912291953.OAA02578@seymour47.SNMP.COM> Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list >>>>> Alan Luchuk writes: Alan> Issue Schedule-01: >> o Sets on arbitrary objects triggered by the scheduler Alan> Further explanation, please. Does this mean that the scheduler Alan> will be able to set: Alan> A. MIB objects of type other than Integer32; and/or B. Alan> Several MIB objects with a single trigger; Alan> at the trigger time? Yes, I think this is the issue on the table. The question here is whether we can borrow infrastructure from the event MIB or whether we redo some of the work. (This is why I was arguing that we (as a WG) should have done a better job to align things.) Alan> Issue Script-02: >> o Restartable scripts Alan> What does this mean? (A cut-and-paste from archived discussion Alan> of this topic would be fine.) Scripts that are automatically launched when an agent starts up (or some other event happens). Alan> Issue Script-03: >> o Error message during script retrieval or compilation >> (smScriptError) Alan> We have solved this problem by adding such an object to a Alan> proprietary MIB that extends the DISMAN-SCRIPT-MIB. But this Alan> kind of object is something that many implementations probably Alan> have use for, so extending the DISMAN-SCRIPT-MIB makes sense. So you argue in favour of adding such an object. Do you have a concrete proposal for the definition of such an object? Alan> Issue Script-04: >> o Scripts that can run forever without having to reset >> smRunLifeTime Alan> Eamonn solved this very simply and elegantly in his Alan> implementation. I forget the exact details, but conceptually it Alan> works like this: If smRunLifeTime is set to its maximum allowed Alan> value (2147483647), the smRunLifeTime is never decremented. We Alan> have added Eamonn's solution to our implementation of the Alan> DISMAN-SCRIPT-MIB. So you and Eamonn are happy with this solution. I have no problem with it. So the strawman position is to add text to the description of smLaunchLifeTime and smRunLifeTime to give 2147483647 a special meaning. Alan> Issue Script-05: >> o Index smLangTable and smExtsnTable by name rather than Integer32 Alan> No opinion on this one. I can align with whatever the DISMAN WG Alan> decides. Alan> Issue Script-06: >> o Dependencies between scripts and script versioning (Eamonn) There is a bit more about this in Eamonn's Simple Times article. Alan> Issue Script-07: >> o Storage type of script code versus storage type of script meta >> information Alan> What does this mean? (A cut-and-paste from archived discussion Alan> of this topic would be fine.) There has been ongoing confusion about the precise meaning of the smScriptStorageType object. It affects the meta information of a script (everything which is in a smScriptTable row) and the storage of the script itself. Alan> Also, as time allows, I'll re-read RFC 2592 and make additional Alan> notes and comments about issues I recall. I've slept since I Alan> last read RFC 2592, so I can't remember the issues without Alan> looking at the RFC :-) That would be great. I also just received another question regarding RFC 2591: Issue Schedule-02: Can the SNMP manager modify CalendarGroup Objects and schedInterval object when the schedRowStatus is in 'active' state? /js -- Juergen Schoenwaelder Technical University Braunschweig Dept. Operating Systems & Computer Networks Phone: +49 531 391 3289 Bueltenweg 74/75, 38106 Braunschweig, Germany Fax: +49 531 391 5936 From owner-disman@dorothy.bmc.com Mon Jan 3 12:13:21 2000 Received: from tangelo.bmc.com (fw-us-hou-2.bmc.com [198.207.223.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04435 for ; Mon, 3 Jan 2000 12:13:21 -0500 (EST) Received: from dorothy.bmc.com (dorothy.bmc.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id LAA14088; Mon, 3 Jan 2000 11:13:17 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id JAA23540 for disman-list; Mon, 3 Jan 2000 09:11:23 -0800 (PST) Received: (from rpresuhn@localhost) by dorothy.peer.com (8.8.6 (PHNE_12836)/8.8.6) id JAA23534; Mon, 3 Jan 2000 09:11:20 -0800 (PST) Date: Mon, 3 Jan 2000 09:11:20 -0800 (PST) From: Randy Presuhn Message-Id: <200001031711.JAA23534@dorothy.peer.com> To: mibs@ops.ietf.org Subject: Re: IPv4 address in IETF MIBS Cc: disman@dorothy.peer.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list Content-Transfer-Encoding: 7bit Hi - ... > Here is a list of current Internet-Drafts that mention IpAddress in some way. ... > DISMAN-EXPRESSION-MIB (draft-ietf-disman-express-mib-10.txt) ... IpAddress is mentioned here because it is a datatype in the SMI. This should not cause a problem for IPv6, since IPv6 addresses would be OCTET STRINGs. ------------------------------------------------------------------------ Randy Presuhn randy_presuhn@bmc.com http://www.bmc.com/ Voice: +1 408 546-1006 BMC Software, Inc. 1-3141 2141 N. First Street Fax: +1 408 965-0359 San Jose, California 95131 USA ------------------------------------------------------------------------ Any relationship between my opinions and BMC's should be coincidental. ------------------------------------------------------------------------ From owner-disman@dorothy.bmc.com Tue Jan 4 12:58:34 2000 Received: from tangelo.bmc.com (fw-us-hou-2.bmc.com [198.207.223.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03242 for ; Tue, 4 Jan 2000 12:58:33 -0500 (EST) Received: from dorothy.peer.com (dorothy.bmc.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id LAA10597; Tue, 4 Jan 2000 11:57:56 -0600 (CST) Received: (from root@localhost) by dorothy.peer.com (8.8.6 (PHNE_12836)/8.8.6) id JAA28115 for disman-list; Tue, 4 Jan 2000 09:48:58 -0800 (PST) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id JAA28109; Tue, 4 Jan 2000 09:48:54 -0800 (PST) Date: Tue, 4 Jan 2000 09:48:54 -0800 (PST) From: Randy Presuhn Message-Id: <200001041748.JAA28109@dorothy.bmc.com> To: disman@dorothy.peer.com Subject: Fwd: question regarding rfc2591, implementation Cc: hongal@yagosys.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list Content-Transfer-Encoding: 7bit Hi - I'm forwarding a non-subscriber post to the disman working group mailing list. Subscription and mailing list archive information is available at http://www.ietf.org/html.charters/disman-charter.html ------------------------------------------------------------------------ Randy Presuhn randy_presuhn@bmc.com http://www.bmc.com/ Voice: +1 408 546-1006 BMC Software, Inc. 1-3141 2141 N. First Street Fax: +1 408 965-0359 San Jose, California 95131 USA ------------------------------------------------------------------------ Any relationship between my opinions and BMC's should be coincidental. ------------------------------------------------------------------------ > Received: from tangelo.bmc.com (root@tangelo.bmc.com [172.17.7.166]) > by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id JAA27921 > for ; Tue, 4 Jan 2000 09:28:18 -0800 (PST) > Received: from fw-us-hou1.bmc.com (fw-us-hou1.bmc.com [172.17.0.250]) > by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with SMTP id LAA02638 > for ; Tue, 4 Jan 2000 11:28:39 -0600 (CST) > Received: from yagosys.com by yagosys.com (8.8.8+Sun/SMI-SVR4-Yago) > id JAA12186; Tue, 4 Jan 2000 09:28:32 -0800 (PST) > Message-ID: <3872122D.DE7BD3ED@yagosys.com> > Date: Tue, 04 Jan 2000 09:30:53 -0600 > From: T F Hongal > X-Mailer: Mozilla 4.61 [en] (WinNT; I) > X-Accept-Language: en > MIME-Version: 1.0 > To: disman@dorothy.peer.com > Subject: question regarding rfc2591, implementation > Content-Type: multipart/mixed; > boundary="------------A129B258DCA4222F681523DB" > > This is a multi-part message in MIME format. > --------------A129B258DCA4222F681523DB > Content-Type: text/plain; charset=us-ascii > Content-Transfer-Encoding: 7bit > > hi all, > I am currently implementing rfc2591, on router. > I have a question regarding the user modification of calendar values or > interval while the schedule is in active state. > ------------------------------------------------------------------------------------------------- > > 1. Can the SNMP Management Station modify CalendarGroup Objects and > schedInterval object when the schedRowStatus is in 'active' state > ?. If the answer > is 'yes' does the agent implementation should temporarily put > schedOperStatus > to DISABLE to achieve the Calendar value change ?. Is there a better > way > to handle this?. > -------------------------------------------------------------------------------------------------- > > Thanks for your earliest response. > hongal > > --------------A129B258DCA4222F681523DB > Content-Type: text/x-vcard; charset=us-ascii; > name="hongal.vcf" > Content-Transfer-Encoding: 7bit > Content-Description: Card for T F Hongal > Content-Disposition: attachment; > filename="hongal.vcf" > > begin:vcard > n:Hongal;Thippanna > tel;cell:408-221-3212 > tel;fax:408-878-6560 > tel;home:408-248-5855 > tel;work:408-878-6562 > x-mozilla-html:TRUE > org:Cabletron Systems, Inc.;NMS Engg > adr:;;3615 Green Lee Drive Apt. No. 21;San Jose;ca;95117;US > version:2.1 > email;internet:hongal@yagosys.com > title:Member of Technical Staff > x-mozilla-cpt:;25856 > fn:Thippanna Hongal > end:vcard > > --------------A129B258DCA4222F681523DB-- > > From owner-disman@dorothy.bmc.com Wed Jan 5 10:05:17 2000 Received: from tangelo.bmc.com (fw-us-hou-2.bmc.com [198.207.223.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06840 for ; Wed, 5 Jan 2000 10:05:09 -0500 (EST) Received: from dorothy.bmc.com (dorothy.bmc.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id JAA14577; Wed, 5 Jan 2000 09:04:26 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id HAA14161 for disman-list; Wed, 5 Jan 2000 07:01:37 -0800 (PST) Received: from tangelo.bmc.com (root@tangelo.bmc.com [172.17.7.166]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id HAA14156 for ; Wed, 5 Jan 2000 07:01:33 -0800 (PST) Received: from fw-us-hou1.bmc.com (fw-us-hou1.bmc.com [172.17.0.250]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with SMTP id JAA13587 for ; Wed, 5 Jan 2000 09:01:54 -0600 (CST) Received: from seymour47.SNMP.COM (seymour47.snmp.com [192.147.142.47]) by seymour39.SNMP.COM (8.9.3/snmpserver.mc-990526) with ESMTP id KAA21314; Wed, 5 Jan 2000 10:00:33 -0500 (EST) From: Alan Luchuk Received: (from luchuk@localhost) by seymour47.SNMP.COM (8.9.3/snmpclient.mc-990423) id KAA05738; Wed, 5 Jan 2000 10:00:31 -0500 (EST) Date: Wed, 5 Jan 2000 10:00:31 -0500 (EST) Message-Id: <200001051500.KAA05738@seymour47.SNMP.COM> To: rpresuhn@dorothy.peer.com Subject: Re: Fwd: question regarding rfc2591, implementation Cc: disman@dorothy.peer.com, hongal@yagosys.com, luchuk@snmp.com Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list >> hi all, >> I am currently implementing rfc2591, on router. >> I have a question regarding the user modification of calendar values or >> interval while the schedule is in active state. >> ------------------------------------------------------------------------ >> >> 1. Can the SNMP Management Station modify CalendarGroup Objects and >> schedInterval object when the schedRowStatus is in 'active' state >> ?. If the answer >> is 'yes' does the agent implementation should temporarily put >> schedOperStatus >> to DISABLE to achieve the Calendar value change ?. Is there a better >> way >> to handle this?. >> ----------------------------------------------------------------------- Hello, Setting a read-create MIB object in a table row while the table row's RowStatus field is 'active' is a legal. So the answer to question (1) above must be "yes". The harder question is what is supposed to happen if you attempt to change the schedInterval while schedAdminStatus is 'enabled'. I have not checked RFC 2591 carefully to determine whether the RFC specifies how this _should_ work. But SNMP Research's DISMAN-SCHEDULE-MIB implementation lets you change the schedInterval while schedAdminStatus and schedOperStatus both are 'enabled'. I surfed through the code and also verified this behavior with an operational test. Our DISMAN-SCHEDULE-MIB implementation does _not_ briefly set schedAdminStatus or schedOperStatus to 'disabled' to make the change to schedInterval. Regards, --Alan ----------------------------------------------------------------------------- Alan Luchuk SNMP Research, Inc. Voice: +1 865 573 1434 Software Engineer 3001 Kimberlin Heights Road FAX: +1 865 573 9197 luchuk@snmp.com Knoxville, TN 37920-9716 U.S.A. http://www.snmp.com/ ----------------------------------------------------------------------------- Please note that our telephone area code recently changed from 423 to 865. Area 423 should countinue to work until it is phased out in April, 2000. From owner-disman@dorothy.bmc.com Wed Jan 5 10:48:41 2000 Received: from tangelo.bmc.com (fw-us-hou-2.bmc.com [198.207.223.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08417 for ; Wed, 5 Jan 2000 10:48:39 -0500 (EST) Received: from dorothy.bmc.com (dorothy.bmc.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id JAA29710; Wed, 5 Jan 2000 09:48:31 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id HAA14247 for disman-list; Wed, 5 Jan 2000 07:47:32 -0800 (PST) Received: from tangelo.bmc.com (root@tangelo.bmc.com [172.17.7.166]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id HAA14242 for ; Wed, 5 Jan 2000 07:47:28 -0800 (PST) Received: from fw-us-hou1.bmc.com (fw-us-hou1.bmc.com [172.17.0.250]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with SMTP id JAA29465 for ; Wed, 5 Jan 2000 09:47:49 -0600 (CST) Received: from seymour47.SNMP.COM (seymour47.snmp.com [192.147.142.47]) by seymour39.SNMP.COM (8.9.3/snmpserver.mc-990526) with ESMTP id KAA22985; Wed, 5 Jan 2000 10:47:02 -0500 (EST) From: Alan Luchuk Received: (from luchuk@localhost) by seymour47.SNMP.COM (8.9.3/snmpclient.mc-990423) id KAA05791; Wed, 5 Jan 2000 10:47:01 -0500 (EST) Date: Wed, 5 Jan 2000 10:47:01 -0500 (EST) Message-Id: <200001051547.KAA05791@seymour47.SNMP.COM> To: schoenw@ibr.cs.tu-bs.de Subject: Re: Sched/Script MIB issues Cc: disman@dorothy.peer.com, luchuk@snmp.com Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list Hello all, Thanks for the clarifications. (Text deleted to shorten this E-mail.) >Alan> Issue Script-02: >>> o Restartable scripts > >Scripts that are automatically launched when an agent starts up (or >some other event happens). I believe Eamonn has a simple and elegant solution for launching scripts when the DISMAN-SCRIPT-MIB agent starts. If the smLaunchName begins with an asterisk, the corresponding launch 'button' is pressed automatically when the agent starts. I have added this to SNMP Research's DISMAN-SCRIPT-MIB implementation. >Alan> Issue Script-03: >>> o Error message during script retrieval or compilation >>> (smScriptError) > >So you argue in favour of adding such an object. Do you have a >concrete proposal for the definition of such an object? I suggest adding a single octet string MIB object to the smScriptTable that can return compile-time error messages. This would provide a single-line error message that would describe the first compile-time error that occurred. Other solutions are possible, like a _table_ of octet strings that would describe all compile-time errors that occurred. SNMP Research's DISMAN-SCRIPT-MIB implementation would work just fine with a single-line error message, but I can see the value of an error message table. Based upon the preferences of the DISMAN WG for one or the other of these solutions, I'll be glad to write up first-cut additions to the DISMAN-SCRIPT-MIB. >Alan> Issue Script-04: >>> o Scripts that can run forever without having to reset >>> smRunLifeTime > >Alan> Eamonn solved this very simply and elegantly in his >Alan> implementation. I forget the exact details, but conceptually it >Alan> works like this: If smRunLifeTime is set to its maximum allowed >Alan> value (2147483647), the smRunLifeTime is never decremented. We >Alan> have added Eamonn's solution to our implementation of the >Alan> DISMAN-SCRIPT-MIB. > >So you and Eamonn are happy with this solution. I have no problem with >it. So the strawman position is to add text to the description of >smLaunchLifeTime and smRunLifeTime to give 2147483647 a special >meaning. Works for me. >Alan> Issue Script-07: >>> o Storage type of script code versus storage type of script meta >>> information > >Alan> What does this mean? (A cut-and-paste from archived discussion >Alan> of this topic would be fine.) > >There has been ongoing confusion about the precise meaning of the >smScriptStorageType object. It affects the meta information of a >script (everything which is in a smScriptTable row) and the storage >of the script itself. Yes, I believe I discovered this during implementation. I solved the problem by shadowing the smScriptStorageType in each row of the smCodeTable. >Issue Schedule-02: > >Can the SNMP manager modify CalendarGroup Objects and schedInterval >object when the schedRowStatus is in 'active' state? SNMP Research's implementation lets you change the schedInterval while the schedRowStatus is 'active', and the row's schedAdmin- Status is 'enabled'. If the user resets the schedInterval, when the set occurs, the existing interval is cancelled and the new interval takes effect. Note that I did not re-check RFC 2591 to determine how this is _supposed_ to work. Regards, --Alan ----------------------------------------------------------------------------- Alan Luchuk SNMP Research, Inc. Voice: +1 865 573 1434 Software Engineer 3001 Kimberlin Heights Road FAX: +1 865 573 9197 luchuk@snmp.com Knoxville, TN 37920-9716 U.S.A. http://www.snmp.com/ ----------------------------------------------------------------------------- Please note that our telephone area code recently changed from 423 to 865. Area 423 should countinue to work until it is phased out in April, 2000. From owner-disman@dorothy.bmc.com Wed Jan 5 13:23:02 2000 Received: from tangelo.bmc.com (fw-us-hou-2.bmc.com [198.207.223.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12661 for ; Wed, 5 Jan 2000 13:23:00 -0500 (EST) Received: from dorothy.peer.com (dorothy.bmc.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id MAA18848; Wed, 5 Jan 2000 12:21:59 -0600 (CST) Received: (from root@localhost) by dorothy.peer.com (8.8.6 (PHNE_12836)/8.8.6) id KAA14655 for disman-list; Wed, 5 Jan 2000 10:15:40 -0800 (PST) Received: from tangelo.bmc.com (root@tangelo.bmc.com [172.17.7.166]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id KAA14650 for ; Wed, 5 Jan 2000 10:15:35 -0800 (PST) Received: from fw-us-hou1.bmc.com (fw-us-hou1.bmc.com [172.17.0.250]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with SMTP id MAA17381 for ; Wed, 5 Jan 2000 12:15:56 -0600 (CST) Received: from seymour47.SNMP.COM (seymour47.snmp.com [192.147.142.47]) by seymour39.SNMP.COM (8.9.3/snmpserver.mc-990526) with ESMTP id NAA01607; Wed, 5 Jan 2000 13:14:43 -0500 (EST) From: Alan Luchuk Received: (from luchuk@localhost) by seymour47.SNMP.COM (8.9.3/snmpclient.mc-990423) id NAA06065; Wed, 5 Jan 2000 13:14:42 -0500 (EST) Date: Wed, 5 Jan 2000 13:14:42 -0500 (EST) Message-Id: <200001051814.NAA06065@seymour47.SNMP.COM> To: disman@dorothy.peer.com Subject: Cc: luchuk@snmp.com Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list Hello all, I been very carefully reading and thinking about draft 9 of the DISMAN-EVENT-MIB. (OW! My head hurts!! :-) I realize it is "after midnight" to submit these questions and comments about the DISMAN-EVENT-MIB. If any of these bring up issues that really need attention and are not due simply to my ignorance, perhaps the issues could be considered in the next doc cycle. Specifying IMPLIED for the second octet string index for each of the tables is inconsistent with the DISMAN-SCHEDULE-MIB and DISMAN-SCRIPT-MIB. Consistency in the MIBs produced by a single IETF WG reflects better upon the IETF WG that produced the MIBs. That is, if the MIBs produced by an IETF WG are consistent among each other, the MIBs then look like the same people wrote them. I suggest dropping the IMPLIED from each of the tables in the DISMAN-EVENT-MIB. Based upon the text in the first paragraph of the DESCRIPTION clause for the mteTriggerTest object, the DISMAN-EVENT-MIB supports sampling of data types that are BER encoded as integer types. Not supporting the sampling of unsigned or counter64 types restricts the stand-alone (i.e., without the DISMAN-EXPRESSION-MIB) utility of the DISMAN-EVENT-MIB. I would suggest extending the DISMAN-EVENT-MIB to sample unsigned and counter64 types. Perhaps add a "MIN-ACCESS read-only" clause in the compliance statement for the mteResourceSampleMinimum and mteResourceSampleInstanceMaximum MIB objects. In real-world implementations, the mteResourceSampleMinimum will always have seconds values that are zero or positive. I suggest that changing its syntax to "Unsigned32" better reflects the real- world values it can take on. Also, what is the rationale for the upper bound of 600 on mteResourceSampleMinimum? Should the DISMAN-EVENT-MIB have the capability to wildcard the mteTriggerTargetTag? I can envision that DISMAN-EVENT-MIB users would want to monitor the same MIB objects on different IP hosts. I suggest that renaming the MIB objects: mteTriggerEnabled -----> mteTriggerAdminStatus mteEventEnabled -----> mteEventAdminStatus would clarify the function of these MIB objects. It might also change the syntax of these objects to be consistent with the AdminStatus MIB objects in the DISMAN-SCHEDULE-MIB and DISMAN- SCRIPT-MIB. (Consistency comments above...) Please pardon my ignorance, but I'm still pretty clueless about what the "Trigger Delta Table" is for and how it works. It appears that the mteTriggerDeltaDiscontinuityID object is supposed to specify a TimeTicks, TimeStamp, or DateAndType object on the monitored system. What happens if the clock on the monitored system does have a time discontinuity? Also, mteTriggerDelta- DiscontinuityID object can be wildcarded. Will someone please explain a situation where this wildcarding capability would be useful? Better still, I suggest documenting it in the MIB itself. The mteTriggerExistenceTest is defined as follows: mteTriggerExistenceTest OBJECT-TYPE SYNTAX BITS { present(0), absent(1), changed(2) } MAX-ACCESS read-write STATUS current DESCRIPTION "The type of existence test to perform. The trigger fires when the object at mteTriggerValueID is seen to go from present to absent, from absent to present, or to have it's value changed, depending on which tests are selected. Once the trigger has fired for either presence or absence it will not fire again for that state until the object has been to the other state." DEFVAL { { present, absent } } ::= { mteTriggerExistenceEntry 1 } The exact function of each bit is somewhat ambiguous. For example, assuming the description ordering matches the bit ordering, here are the bit functions: present(0) - the mteTriggerValueID object goes from present to absent absent(1) - the mteTriggerValueID object goes from absent to present changed(2) - the mteTriggerValueID object value changes But, based upon the final state of the mteTriggerValueID object, the bit functions might be: present(0) - the mteTriggerValueID object goes from absent to present absent(1) - the mteTriggerValueID object goes from present to absent changed(2) - the mteTriggerValueID object value changes Other orderings are possible. Changing the DESCRIPTION text to spell this out would clarify this issue for me (and probably for other implementors.) I believe the 'changed(2)' bit value should be deleted from the mteTriggerExistenceStartup MIB object. Including this bit value suggests (to me, at least) the DISMAN-EVENT-MIB knows the value of the monitored object before mteTriggerExistenceTest is configured. Am I missing something here? Changing the mteTriggerBooleanComparison syntax from an INTEGER to a BITS type, with the values less(0), equal(1), and greater(2), might simplify this object a little. Changing the mteTriggerThresholdStartup syntax from an INTEGER to a BITS type, with the values rising(0) and falling(1), might simplify this object a little. The mteEventSetObject and mteEventSetValue support setting only Integer32 objects. This means the DISMAN-EVENT-MIB has the same set-event limitations that the DISMAN-SCHEDULE-MIB has. I suggest that providing a facility for setting arbitrary MIB objects when an event fires would increase the utility of the DISMAN-EVENT-MIB. My first thought about how this might be resolved would be to expand the mteObjectsTable to contain values. MteEventSetEntrys could refer to the mteObjectsTable to get the list of objects to set. How are the error notifications (mteTriggerFailure, mteEventSetFailure) enabled and disabled? OK. Now a question about the notification handling of the DISMAN- EVENT-MIB. Can someone give me examples about why I would want to have trigger-specific, trigger-subclass-specific, and event-specific MIB object lists in event notifications? Why is it insufficient to have only the mteEventNotificationObjectsOwner and mteEventNotif- icationObjects and delete: mteTriggerObjectsOwner mteTriggerObjects mteTriggerExistenceObjectsOwner mteTriggerExistenceObjects mteTriggerBooleanObjectsOwner mteTriggerBooleanObjects mteTriggerThresholdObjectsOwner mteTriggerThresholdObjects Can someone give me examples where I would want to allow one user access to another user's entries in the mteObjectsTable and the mteEventTable? As always, I hope my comments and questions help produce the most useful specification, and don't just waste net bandwidth. Thanks to Ram for his continued work on the DISMAN-EVENT-MIB! Regards, --Alan ----------------------------------------------------------------------------- Alan Luchuk SNMP Research, Inc. Voice: +1 865 573 1434 Software Engineer 3001 Kimberlin Heights Road FAX: +1 865 573 9197 luchuk@snmp.com Knoxville, TN 37920-9716 U.S.A. http://www.snmp.com/ ----------------------------------------------------------------------------- Please note that our telephone area code recently changed from 423 to 865. Area 423 should countinue to work until it is phased out in April, 2000. From owner-disman@dorothy.bmc.com Wed Jan 5 13:50:34 2000 Received: from tangelo.bmc.com (fw-us-hou-2.bmc.com [198.207.223.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13190 for ; Wed, 5 Jan 2000 13:50:31 -0500 (EST) Received: from dorothy.bmc.com (dorothy.bmc.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id MAA26019; Wed, 5 Jan 2000 12:50:14 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id KAA14755 for disman-list; Wed, 5 Jan 2000 10:49:12 -0800 (PST) Received: (from rpresuhn@localhost) by dorothy.peer.com (8.8.6 (PHNE_12836)/8.8.6) id KAA14749 for disman@dorothy.bmc.com; Wed, 5 Jan 2000 10:49:07 -0800 (PST) Date: Wed, 5 Jan 2000 10:49:07 -0800 (PST) From: Randy Presuhn Message-Id: <200001051849.KAA14749@dorothy.peer.com> To: disman@dorothy.peer.com Subject: Re: Editorial comments about DISMAN-EVENT-MIB Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list Content-Transfer-Encoding: 7bit Hi - I'm forwarding these to the list so no one is surprised. My recommendations are in-line below. Thanks to Alan for the close reading of the document! > From: Alan Luchuk > Date: Wed, 5 Jan 2000 13:03:34 -0500 (EST) > Message-Id: <200001051803.NAA06048@seymour47.SNMP.COM> > To: ramk@cisco.com > Subject: Editorial comments about DISMAN-EVENT-MIB > Cc: luchuk@snmp.com, rpresuhn@dorothy.peer.com > > Hi Ram, > > As I've carefully read/thought about , > I have a number of editorial comments. These are included below. I have > not concentrated on your latest E-mails to the DISMAN WG, so if you have > already addressed these editorial issues, then please disregard my comments. > > Thanks for your continued work on this! > > Regards, > --Alan > > ----------------------------------------------------------------------------- > Alan Luchuk SNMP Research, Inc. Voice: +1 865 573 1434 > Software Engineer 3001 Kimberlin Heights Road FAX: +1 865 573 9197 > luchuk@snmp.com Knoxville, TN 37920-9716 U.S.A. http://www.snmp.com/ > ----------------------------------------------------------------------------- > > Please note that our telephone area code recently changed from 423 to 865. > Area 423 should countinue to work until it is phased out in April, 2000. > > > ------------ DISMAN-EVENT-MIB editorial comments included below --------- > > Column alignment: > ---------------- > > There are several places where things would look tidier if they > were column aligned. A few examples include: > > > mteResource OBJECT IDENTIFIER ::= { dismanEventMIBObjects 1 } > mteTrigger OBJECT IDENTIFIER ::= { dismanEventMIBObjects 2 } > mteObjects OBJECT IDENTIFIER ::= { dismanEventMIBObjects 3 } > mteEvent OBJECT IDENTIFIER ::= { dismanEventMIBObjects 4 } > This is up to the editor's discretion; it can be handled as part of the publication process. > > Table row definitions (Page 15), like: > > > MteTriggerEntry ::= SEQUENCE { > mteOwner SnmpAdminString, > mteTriggerName SnmpAdminString, > mteTriggerComment SnmpAdminString, > mteTriggerTest BITS, > mteTriggerSampleType INTEGER, > mteTriggerValueID OBJECT IDENTIFIER, > mteTriggerValueIDWildcard TruthValue, > mteTriggerTargetTag SnmpTagValue, > mteTriggerContextName SnmpAdminString, > mteTriggerContextNameWildcard TruthValue, > mteTriggerFrequency Unsigned32, > mteTriggerObjectsOwner SnmpAdminString, > mteTriggerObjects SnmpAdminString, > mteTriggerEnabled TruthValue, > mteTriggerEntryStatus RowStatus > } > ditto. > > And (Page 11): > > > localResourceLack some local resource such as memory lacking > or mteResourceSampleInstanceMaximum > exceeded > badDestination unrecognized domain name or otherwise > invalid destination address > destinationUnreachable can't get to destination address > noResponse no response to SNMP request > badType the data syntax of a retrieved object > as not as expected > sampleOverrun another sample attempt occurred before > the previous one completed" > > This is so ugly that it probably should be fixed, though this can be done as part of the publication process. > > > Use of capitalized MAY/SHOULD/MUST, etc. > ---------------------------------------- > > RFC 2119 defines the usage of a number of words like MAY/SHOULD/MUST, > etc. There are a number of places in draft 9 where these words are > capitalized, but I'm not sure they should be. > > I believe the difference is who or what these words apply to. If > the word (like 'may') describes the implementation, then it should > be capitalized. Otherwise, the word should be in lowercase. > > Example: On page 8, section 6, the last sentence of paragraph 3 > reads: > > "All of this takes place independently of any additional > instances that MAY fill the wildcard." > > In this case (and in others throughout the document) I believe the > word "MAY" should be in lowercase letters. > > Getting all of these into the correct case (uppercase/lowercase) > will require some thought. > We've discussed this one, and I believe there is agreement: the capitalized versions are to be used only in the stating of conformance requirements. > > > Page 5, the first complete paragraph reads: > ------------------------------------------- > > The trigger table lists what objects are to be monitored and how and > relates each trigger to an event. It has supplementary, companion > tables for additional objects that depend on the type of test done for > the trigger. > > > I suggest the following text is a little clearer: > > > The trigger table lists what MIB objects are monitored and how > these MIB objects are monitored. The trigger table also relates > triggers to events. It has supplementary, companion tables for > additional objects that depend on the type of test done for the > trigger. > Indeed, it's the mteTrigger*Tables, and not the mteTriggerTable, that associate triggers and events. Neither text communicates this, unless one considers "trigger table" to be an abstraction that is implemented in MIB-speak as mteTriggerTable and the various mteTrigger*Tables. > > > Page 5, the third complete paragraph reads: > ------------------------------------------- > > The event table defines what happens when an event is triggered, > sending a notification, setting a MIB object or both. It has > supplementary, companion tables for additional objects that depend > on the action taken. > > > I suggest the following punctuation change is a little clearer: > > > The event table defines what happens when an event is triggered: > sending a notification, setting a MIB object, or both. It has > supplementary, companion tables for additional objects that depend > on the action taken. > I leave the replacement of the "," with a ":" to the editor. > > Page 8, second paragraph, last sentence, reads: > ----------------------------------------------- > > A self-management only system MAY not implement remote monitoring. > > I suggest the following text is a little clearer: > > An implementation of the DISMAN-EVENT-MIB MAY support only > self-management. That is, an implementation MAY omit remote > monitoring. > Ok. > > Page 8, third paragraph, reads: > ------------------------------- > > Wildcards indicate that the application SHOULD use a GetNext-type > operation to find the zero or more instances implied by a truncated > object identifier, just like an ordinary SNMP-based management > application. Each instance of a wildcard is treated as if it were a > separate entry, that is the instances of a wildcarded object are > independent of one another. For example, a wild-carded object MAY > trigger an event and result in the setting of another wildcarded object. > The instance that satisfied the trigger function is used to perform the > set function. All of this takes place independently of any additional > instances that MAY fill the wildcard. > > I suggest the following text has a few grammatical corrections: > > Wildcards indicate that the application should use a GetNext-type We're on a slippery slope here. To the extent that the operation of an implementation of this MIB may result in traffic on the network, this "should" probably should be a "SHOULD". > operation to find the zero or more instances implied by a truncated > object identifier, just like an ordinary SNMP-based management > application. Each instance of a wildcard is treated as if it were a > separate entry, that is, the instances of a wildcarded object are > independent of one another. For example, a wildcarded object may > trigger an event, and may result in the setting of another wildcarded There's no need for the second may. I think the phenomenon is called "gapping" in transformational grammar. > object. The instance that satisfied the trigger function is used > to perform the set function. All of this takes place independently > of any additional instances that may fill the wildcard. > This looks ok. > > > Page 8, fourth paragraph: > ------------------------- > > Need a few spaces between "[rfcNotificationLogMIB]." and "MIB". ?? The only occurrance of rfcNotificationLogMIB is on page 6. The "rfc" should be replaced with RFC, though the whole thing should be replaced during the publication process. > > Page 8, sixth paragraph: > ------------------------ > > "implementation specific" should be "implementation-specific". > Editor's discretion. > > Page 14 > ------- > > Add a "UNITS" clause to mteTriggerFailures. > Makes sense. > > Page 16, second paragraph: > -------------------------- > > Currently reads: > > For 'existence', the specific test is as selected by > mteTriggerExistenceTest. When an object appears or vanishes > the trigger fires. The trigger will not fire again until the > object has changed states. > > I suggest the following text is a little clearer (and more accurate): > > For 'existence', the specific test is as selected by > mteTriggerExistenceTest. When an object appears, vanishes, or > changes value, then the trigger fires. The trigger will not > fire again until the object has changed states. > Adding "or changes value" would be a significant technical change. This would be inappropriate at this time. Unless there is a good internal consistency argument that the current text here is in error, as WG chair I'm inclined to rule "too late" on this one. > > Page 25 > ------- > > The DESCRIPTION clause for the mteTriggerExistenceEventOwner > references the mteObjectsTable. > I believe the current description is correct. It's consistent with all the other mte*EventOwner objects. > > Page 37 > ------- > > The DESCRIPTION clause for the mteEventNotificationTable reads: > > "A table of management event action notification information." > > I suggest the following text is a little clearer: > > "A table of information about all notifications that may be > sent in response to management events." > I'd suggest a bit more word-smithing: | "A table of information about notifications to be | sent as a consequence of management events." but I leave it up to the editor. ------------------------------------------------------------------------ Randy Presuhn randy_presuhn@bmc.com http://www.bmc.com/ Voice: +1 408 546-1006 BMC Software, Inc. 1-3141 2141 N. First Street Fax: +1 408 965-0359 San Jose, California 95131 USA ------------------------------------------------------------------------ Any relationship between my opinions and BMC's should be coincidental. ------------------------------------------------------------------------ From owner-disman@dorothy.bmc.com Wed Jan 5 14:59:18 2000 Received: from tangelo.bmc.com (fw-us-hou-2.bmc.com [198.207.223.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14803 for ; Wed, 5 Jan 2000 14:59:17 -0500 (EST) Received: from dorothy.peer.com (dorothy.bmc.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id NAA16361; Wed, 5 Jan 2000 13:58:38 -0600 (CST) Received: (from root@localhost) by dorothy.peer.com (8.8.6 (PHNE_12836)/8.8.6) id LAA15060 for disman-list; Wed, 5 Jan 2000 11:56:32 -0800 (PST) Received: from tangelo.bmc.com (root@tangelo.bmc.com [172.17.7.166]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id LAA15054; Wed, 5 Jan 2000 11:56:19 -0800 (PST) Received: from fw-us-hou1.bmc.com (fw-us-hou1.bmc.com [172.17.0.250]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with SMTP id NAA15565; Wed, 5 Jan 2000 13:56:40 -0600 (CST) Received: from seymour47.SNMP.COM (seymour47.snmp.com [192.147.142.47]) by seymour39.SNMP.COM (8.9.3/snmpserver.mc-990526) with ESMTP id OAA04624; Wed, 5 Jan 2000 14:56:36 -0500 (EST) From: Alan Luchuk Received: (from luchuk@localhost) by seymour47.SNMP.COM (8.9.3/snmpclient.mc-990423) id OAA06214; Wed, 5 Jan 2000 14:56:36 -0500 (EST) Date: Wed, 5 Jan 2000 14:56:36 -0500 (EST) Message-Id: <200001051956.OAA06214@seymour47.SNMP.COM> To: rpresuhn@dorothy.peer.com Subject: Re: Editorial comments about DISMAN-EVENT-MIB Cc: disman@dorothy.peer.com, luchuk@snmp.com, ramk@cisco.com Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list Hello, I have questions about Randy's replies to my editorial comments on . In this reply, I deleted most of Randy's comments to shorten the E-mail. What remains are only the few items I have questions about. >> Page 8, fourth paragraph: >> ------------------------- >> >> Need a few spaces between "[rfcNotificationLogMIB]." and "MIB". > >?? The only occurrance of rfcNotificationLogMIB is on page 6. >The "rfc" should be replaced with RFC, though the whole thing >should be replaced during the publication process. Are we both looking at ? I doubled checked, in my copy, this is in _section_ 6, titled "Operation", on _page_ 8. >> >> Page 16, second paragraph: >> -------------------------- >> >> Currently reads: >> >> For 'existence', the specific test is as selected by >> mteTriggerExistenceTest. When an object appears or vanishes >> the trigger fires. The trigger will not fire again until the >> object has changed states. >> >> I suggest the following text is a little clearer (and more accurate): >> >> For 'existence', the specific test is as selected by >> mteTriggerExistenceTest. When an object appears, vanishes, or >> changes value, then the trigger fires. The trigger will not >> fire again until the object has changed states. >> > >Adding "or changes value" would be a significant technical change. >This would be inappropriate at this time. Unless there is a good >internal consistency argument that the current text here is in >error, as WG chair I'm inclined to rule "too late" on this one. Why would adding "or changes value" be a significant technical change? The mteTriggerExistenceTest object is defined (on page 24) as follows: mteTriggerExistenceTest OBJECT-TYPE SYNTAX BITS { present(0), absent(1), changed(2) } MAX-ACCESS read-write STATUS current DESCRIPTION "The type of existence test to perform. The trigger fires when the object at mteTriggerValueID is seen to go from present to absent, from absent to present, or to have it's value changed, depending on which tests are selected. Once the trigger has fired for either presence or absence it will not fire again for that state until the object has been to the other state." DEFVAL { { present, absent } } ::= { mteTriggerExistenceEntry 1 } Adding "or changes value" (on page 16, second paragraph) simply states in verbiage what the the mteTriggerExistenceTest SYNTAX and DESCRIPTION clauses (on page 24) already says. Personally, I don't really care about whether or not "or changes value" is added on page 16, I just thought adding the my suggested text would more accurately reflect the definition of mteTriggerExistenceTest. I'm asking why this is considered a technical change so I better understand the IETF standards-writing "procedural" stuff. >> >> Page 25 >> ------- >> >> The DESCRIPTION clause for the mteTriggerExistenceEventOwner >> references the mteObjectsTable. >> > >I believe the current description is correct. >It's consistent with all the other mte*EventOwner objects. Huh? I double-checked. Closely compare the DESCRIPTION clauses of: mteTriggerExistenceEventOwner mteTriggerBooleanEventOwner mteTriggerThresholdRisingEventOwner mteTriggerThresholdFallingEventOwner The DESCRIPTION clause of mteTriggerExistenceEventOwner differs from the other three. I thought the EventOwner objects referred to the mteEventTable, not the mteObjectsTable (as written in the mteTriggerExistenceEventOwner DESCRIPTION clause.) Regards, --Alan ----------------------------------------------------------------------------- Alan Luchuk SNMP Research, Inc. Voice: +1 865 573 1434 Software Engineer 3001 Kimberlin Heights Road FAX: +1 865 573 9197 luchuk@snmp.com Knoxville, TN 37920-9716 U.S.A. http://www.snmp.com/ ----------------------------------------------------------------------------- Please note that our telephone area code recently changed from 423 to 865. Area 423 should countinue to work until it is phased out in April, 2000. From owner-disman@dorothy.bmc.com Wed Jan 5 17:11:01 2000 Received: from tangelo.bmc.com (fw-us-hou-2.bmc.com [198.207.223.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16872 for ; Wed, 5 Jan 2000 17:11:00 -0500 (EST) Received: from dorothy.peer.com (dorothy.bmc.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id QAA22876; Wed, 5 Jan 2000 16:09:55 -0600 (CST) Received: (from root@localhost) by dorothy.peer.com (8.8.6 (PHNE_12836)/8.8.6) id OAA15566 for disman-list; Wed, 5 Jan 2000 14:07:06 -0800 (PST) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id OAA15560 for disman@dorothy.bmc.com; Wed, 5 Jan 2000 14:07:01 -0800 (PST) Date: Wed, 5 Jan 2000 14:07:01 -0800 (PST) From: Randy Presuhn Message-Id: <200001052207.OAA15560@dorothy.bmc.com> To: disman@dorothy.peer.com Subject: Re: Editorial comments about DISMAN-EVENT-MIB Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list Content-Transfer-Encoding: 7bit Hi - > From: Alan Luchuk > Date: Wed, 5 Jan 2000 14:56:36 -0500 (EST) > Message-Id: <200001051956.OAA06214@seymour47.SNMP.COM> > To: rpresuhn@dorothy.peer.com > Subject: Re: Editorial comments about DISMAN-EVENT-MIB > Cc: disman@dorothy.peer.com, luchuk@snmp.com, ramk@cisco.com > List-Id: IETF disman Working Group mailing list ... > I have questions about Randy's replies to my editorial comments on > . In this reply, I deleted > most of Randy's comments to shorten the E-mail. What remains are > only the few items I have questions about. > > > > >> Page 8, fourth paragraph: > >> ------------------------- > >> > >> Need a few spaces between "[rfcNotificationLogMIB]." and "MIB". > > > >?? The only occurrance of rfcNotificationLogMIB is on page 6. > >The "rfc" should be replaced with RFC, though the whole thing > >should be replaced during the publication process. > > Are we both looking at ? Silly me. I was looking at the most recent i-d, which is just -08. Yet another reason why stuff should be posted as i-ds, rather than just being sent to the mailing list. My mistake. > I doubled checked, in my copy, this is in _section_ 6, titled > "Operation", on _page_ 8. ?? I think you mean there should be a couple of spaces before the word "Note". "MIB" and "[rfcNotificationLogMIB]." are on different lines. > > >> > >> Page 16, second paragraph: > >> -------------------------- > >> > >> Currently reads: > >> > >> For 'existence', the specific test is as selected by > >> mteTriggerExistenceTest. When an object appears or vanishes > >> the trigger fires. The trigger will not fire again until the > >> object has changed states. > >> > >> I suggest the following text is a little clearer (and more accurate): > >> > >> For 'existence', the specific test is as selected by > >> mteTriggerExistenceTest. When an object appears, vanishes, or > >> changes value, then the trigger fires. The trigger will not > >> fire again until the object has changed states. > >> > > > >Adding "or changes value" would be a significant technical change. > >This would be inappropriate at this time. Unless there is a good > >internal consistency argument that the current text here is in > >error, as WG chair I'm inclined to rule "too late" on this one. > > > Why would adding "or changes value" be a significant technical change? > The mteTriggerExistenceTest object is defined (on page 24) as follows: > > mteTriggerExistenceTest OBJECT-TYPE > SYNTAX BITS { present(0), absent(1), changed(2) } > MAX-ACCESS read-write > STATUS current > DESCRIPTION > "The type of existence test to perform. The trigger fires > when the object at mteTriggerValueID is seen to go from > present to absent, from absent to present, or to have it's > value changed, depending on which tests are selected. > > Once the trigger has fired for either presence or absence it > will not fire again for that state until the object has been > to the other state." > DEFVAL { { present, absent } } > ::= { mteTriggerExistenceEntry 1 } > > > Adding "or changes value" (on page 16, second paragraph) simply states > in verbiage what the the mteTriggerExistenceTest SYNTAX and DESCRIPTION > clauses (on page 24) already says. Ok. You've convinced me. Ram, fix it. :-) > Personally, I don't really care about whether or not "or changes value" > is added on page 16, I just thought adding the my suggested text would > more accurately reflect the definition of mteTriggerExistenceTest. I'm > asking why this is considered a technical change so I better understand > the IETF standards-writing "procedural" stuff. That's why I handed you the "Unless". You've given a solid argument based on the internal consistency of the specification. I agree it should be fixed, based on your argument. > > >> > >> Page 25 > >> ------- > >> > >> The DESCRIPTION clause for the mteTriggerExistenceEventOwner > >> references the mteObjectsTable. > >> > > > >I believe the current description is correct. > >It's consistent with all the other mte*EventOwner objects. > > Huh? I double-checked. Closely compare the DESCRIPTION clauses of: > > mteTriggerExistenceEventOwner > mteTriggerBooleanEventOwner > mteTriggerThresholdRisingEventOwner > mteTriggerThresholdFallingEventOwner > > The DESCRIPTION clause of mteTriggerExistenceEventOwner differs > from the other three. I thought the EventOwner objects referred > to the mteEventTable, not the mteObjectsTable (as written in the > mteTriggerExistenceEventOwner DESCRIPTION clause.) ... Right again. Ram, fix it. :-) ------------------------------------------------------------------------ Randy Presuhn randy_presuhn@bmc.com http://www.bmc.com/ Voice: +1 408 546-1006 BMC Software, Inc. 1-3141 2141 N. First Street Fax: +1 408 965-0359 San Jose, California 95131 USA ------------------------------------------------------------------------ Any relationship between my opinions and BMC's should be coincidental. ------------------------------------------------------------------------ From owner-disman@dorothy.bmc.com Wed Jan 5 18:39:21 2000 Received: from tangelo.bmc.com (fw-us-hou-2.bmc.com [198.207.223.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18147 for ; Wed, 5 Jan 2000 18:39:21 -0500 (EST) Received: from dorothy.bmc.com (dorothy.bmc.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id RAA14036; Wed, 5 Jan 2000 17:38:57 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id PAA15870 for disman-list; Wed, 5 Jan 2000 15:37:55 -0800 (PST) Received: (from rpresuhn@localhost) by dorothy.peer.com (8.8.6 (PHNE_12836)/8.8.6) id PAA15864 for disman@dorothy.peer.com; Wed, 5 Jan 2000 15:37:50 -0800 (PST) Date: Wed, 5 Jan 2000 15:37:50 -0800 (PST) From: Randy Presuhn Message-Id: <200001052337.PAA15864@dorothy.peer.com> To: disman@dorothy.peer.com Subject: Re: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list Content-Transfer-Encoding: 7bit Hi - > From: Alan Luchuk > Date: Wed, 5 Jan 2000 13:14:42 -0500 (EST) > Message-Id: <200001051814.NAA06065@seymour47.SNMP.COM> > To: disman@dorothy.peer.com > Subject: > Cc: luchuk@snmp.com > List-Id: IETF disman Working Group mailing list ... > I been very carefully reading and thinking about draft 9 of the > DISMAN-EVENT-MIB. (OW! My head hurts!! :-) That does seem to be a common reaction to these three documents. It's rather ironic, considering that they were motivated by the desire to avoid the perceived complexities of the script MIB. > I realize it is > "after midnight" to submit these questions and comments about the > DISMAN-EVENT-MIB. If any of these bring up issues that really > need attention and are not due simply to my ignorance, perhaps > the issues could be considered in the next doc cycle. The expectation is that this specification may need to cycle at proposed if we ever get it out the door. Keeping this in mind, I believe only things that are truly broken (and not just ugly) should be fixed at this time. > Specifying IMPLIED for the second octet string index for each of the > tables is inconsistent with the DISMAN-SCHEDULE-MIB and DISMAN-SCRIPT-MIB. > Consistency in the MIBs produced by a single IETF WG reflects better > upon the IETF WG that produced the MIBs. That is, if the MIBs produced > by an IETF WG are consistent among each other, the MIBs then look > like the same people wrote them. I suggest dropping the IMPLIED > from each of the tables in the DISMAN-EVENT-MIB. Personally, I think adding IMPLIED to the SMI was a mistake. In this particular case, it doesn't add much value, but it also doesn't break anything. I suppose one could construct scenarios making use of wildcarding and naming conventions to take advantage of the current structure, but I'm skeptical. These MIBs were in fact written by different people, with different views of how MIBs should be written. So though I agree with your argument, it's not the kind of problem that supports making a technical change at this point. > > Based upon the text in the first paragraph of the DESCRIPTION clause > for the mteTriggerTest object, the DISMAN-EVENT-MIB supports sampling > of data types that are BER encoded as integer types. Not supporting > the sampling of unsigned or counter64 types restricts the stand-alone > (i.e., without the DISMAN-EXPRESSION-MIB) utility of the DISMAN-EVENT-MIB. > I would suggest extending the DISMAN-EVENT-MIB to sample unsigned and > counter64 types. > Definitely for further study, definitely not for the current document. Given the discussions leading up to , it looks like we'd have a fight on our hands if we wanted to do anything in the area. We should discuss this and look at solutions, but not for incorporation at this time in the document we're trying to publish. > > Perhaps add a "MIN-ACCESS read-only" clause in the compliance statement > for the mteResourceSampleMinimum and mteResourceSampleInstanceMaximum > MIB objects. I don't see what problem or requirement this would address. Let's leave this question for the future based on implementation and deployment experience. > In real-world implementations, the mteResourceSampleMinimum will > always have seconds values that are zero or positive. I suggest > that changing its syntax to "Unsigned32" better reflects the real- > world values it can take on. Also, what is the rationale for the > upper bound of 600 on mteResourceSampleMinimum? Changing the datatype from Integer32 to Unsigned32 would have no effect on capability, but would change what shows up on the wire. It's not a change we need to make. The range itself is a different story. This issue arose at the Minneapolis meeting. In the minutes of 1999-03-19: | The Event MIB has one week remaining for WG last call. | One question was raised by the chair regarding the "strange | limits" of object mteResourceSampleMinimum (-1 | 1..600). | Bob Stewart agreed that since he was the one who created | it that he would investigate and document why those | particular limits. If no good reason is found then the | architectural constraints will be lifted. If no other | concerns are raised, it will complete WG last call. Bob subsequently identified the -1 as a cut-and-paste error. The upper bound of 600 was never justified. It looks like our agreement was to get rid of the upper bound, i.e., make it 2147483647. Comments? > > Should the DISMAN-EVENT-MIB have the capability to wildcard the > mteTriggerTargetTag? I can envision that DISMAN-EVENT-MIB users > would want to monitor the same MIB objects on different IP hosts. The mteTriggerTargetTag is already capable of specifying multiple ip hosts through the normal operation of the target MIB. The need for yet another layer of wildcarding hasn't been established (yet). Let's defer this. > > I suggest that renaming the MIB objects: > > mteTriggerEnabled -----> mteTriggerAdminStatus > mteEventEnabled -----> mteEventAdminStatus > > would clarify the function of these MIB objects. It might also > change the syntax of these objects to be consistent with the > AdminStatus MIB objects in the DISMAN-SCHEDULE-MIB and DISMAN- > SCRIPT-MIB. (Consistency comments above...) This, too, is something to put on the wich list for the next version. > Please pardon my ignorance, but I'm still pretty clueless about > what the "Trigger Delta Table" is for and how it works. It appears > that the mteTriggerDeltaDiscontinuityID object is supposed to > specify a TimeTicks, TimeStamp, or DateAndType object on the > monitored system. What happens if the clock on the monitored > system does have a time discontinuity? Let's say we have samples S[n-2], S[n-1], S[n], S[n+1], and S[n+2] This means the potential deltas computed would be: time n-1: Delta(S[n-1], S[n-2]) time n: Delta(S[n], S[n-1]) time n+1: Delta(S[n+1], S[n]) time n+2: Delta(S[n+2], S[n-1]) Now, if a discontinuity is detected at time n, then the only deltas which can be considered valid are: time n-1: Delta(S[n-1], S[n-2]) time n+1: Delta(S[n+1], S[n]) time n+2: Delta(S[n+2], S[n-1]) > Also, mteTriggerDelta- > DiscontinuityID object can be wildcarded. Will someone please > explain a situation where this wildcarding capability would be > useful? Better still, I suggest documenting it in the MIB itself. An example would be the RFC 2564 applOpenChannelOpenTime object, where each row in that table has its own indicator. This is useful where different rows might be implemented by different processes or subagents in a system. Note that that MIB uses the old RFC 1902 clause 7.1.10 approach of a TimeStamp for the indicator, rather than the current RFC 2578 clause 7.1.6 approach of a DateAndTime or TimeTicks. > > The mteTriggerExistenceTest is defined as follows: > > mteTriggerExistenceTest OBJECT-TYPE > SYNTAX BITS { present(0), absent(1), changed(2) } > MAX-ACCESS read-write > STATUS current > DESCRIPTION > "The type of existence test to perform. The trigger fires > when the object at mteTriggerValueID is seen to go from > present to absent, from absent to present, or to have it's > value changed, depending on which tests are selected. > > Once the trigger has fired for either presence or absence it > will not fire again for that state until the object has been > to the other state." > DEFVAL { { present, absent } } > ::= { mteTriggerExistenceEntry 1 } > > The exact function of each bit is somewhat ambiguous. For example, > assuming the description ordering matches the bit ordering, here > are the bit functions: > > present(0) - the mteTriggerValueID object goes from present to absent > absent(1) - the mteTriggerValueID object goes from absent to present > changed(2) - the mteTriggerValueID object value changes > > But, based upon the final state of the mteTriggerValueID object, the > bit functions might be: > > present(0) - the mteTriggerValueID object goes from absent to present > absent(1) - the mteTriggerValueID object goes from present to absent > changed(2) - the mteTriggerValueID object value changes > > Other orderings are possible. Changing the DESCRIPTION text to spell > this out would clarify this issue for me (and probably for other > implementors.) I believe the second interpretation is the one intended. Ram, make it clear. > > I believe the 'changed(2)' bit value should be deleted from the > mteTriggerExistenceStartup MIB object. Including this bit value > suggests (to me, at least) the DISMAN-EVENT-MIB knows the value > of the monitored object before mteTriggerExistenceTest is configured. > Am I missing something here? I think you're right that changed(2) doesn't make sense here. > Changing the mteTriggerBooleanComparison syntax from an INTEGER > to a BITS type, with the values less(0), equal(1), and greater(2), > might simplify this object a little. Such a change would also permit specification of two conditions not supported by the current design: always (all bits one) and never (all bits zero). In the interest of not letting the features creep, let's leave it along for now. > > Changing the mteTriggerThresholdStartup syntax from an INTEGER > to a BITS type, with the values rising(0) and falling(1), > might simplify this object a little. That change would permit specification of one more pattern not defined currently. I think it would mean "never", but in the interest of not letteing features creep, let's leave it alone. > > The mteEventSetObject and mteEventSetValue support setting only > Integer32 objects. This means the DISMAN-EVENT-MIB has the same > set-event limitations that the DISMAN-SCHEDULE-MIB has. I suggest > that providing a facility for setting arbitrary MIB objects when > an event fires would increase the utility of the DISMAN-EVENT-MIB. Agreed, but this is a future issue. > My first thought about how this might be resolved would be to expand > the mteObjectsTable to contain values. MteEventSetEntrys could refer > to the mteObjectsTable to get the list of objects to set. > > > How are the error notifications (mteTriggerFailure, mteEventSetFailure) > enabled and disabled? Presumably via RFC 2573, though an implementation might provide other means. If we were to try to build the controls into this MIB, then coping with multiple managers would be a problem or we'd end up replicating RFC 2573's functionality for target and notification handling. > > OK. Now a question about the notification handling of the DISMAN- > EVENT-MIB. Can someone give me examples about why I would want to > have trigger-specific, trigger-subclass-specific, and event-specific > MIB object lists in event notifications? Why is it insufficient to > have only the mteEventNotificationObjectsOwner and mteEventNotif- > icationObjects and delete: > > mteTriggerObjectsOwner > mteTriggerObjects > mteTriggerExistenceObjectsOwner > mteTriggerExistenceObjects > mteTriggerBooleanObjectsOwner > mteTriggerBooleanObjects > mteTriggerThresholdObjectsOwner > mteTriggerThresholdObjects It's nice to know what object triggered the notification as well as the values of potentially related objects. > > > Can someone give me examples where I would want to allow one > user access to another user's entries in the mteObjectsTable > and the mteEventTable? That's up to your security administrator. For example, the head network administrator probably should have sufficient rights to turn off any of the monitors his/her minions have created. > As always, I hope my comments and questions help produce the most > useful specification, and don't just waste net bandwidth. ... The comments are greatly appreciated. I just wish they had come two years ago. ------------------------------------------------------------------------ Randy Presuhn randy_presuhn@bmc.com http://www.bmc.com/ Voice: +1 408 546-1006 BMC Software, Inc. 1-3141 2141 N. First Street Fax: +1 408 965-0359 San Jose, California 95131 USA ------------------------------------------------------------------------ Any relationship between my opinions and BMC's should be coincidental. ------------------------------------------------------------------------ From owner-disman@dorothy.bmc.com Wed Jan 5 19:28:58 2000 Received: from tangelo.bmc.com (fw-us-hou-2.bmc.com [198.207.223.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18656 for ; Wed, 5 Jan 2000 19:28:51 -0500 (EST) Received: from dorothy.bmc.com (dorothy.bmc.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id SAA25221; Wed, 5 Jan 2000 18:28:33 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id QAA16262 for disman-list; Wed, 5 Jan 2000 16:27:43 -0800 (PST) Received: (from rpresuhn@localhost) by dorothy.peer.com (8.8.6 (PHNE_12836)/8.8.6) id QAA16256 for disman@dorothy.bmc.com; Wed, 5 Jan 2000 16:27:40 -0800 (PST) Date: Wed, 5 Jan 2000 16:27:40 -0800 (PST) From: Randy Presuhn Message-Id: <200001060027.QAA16256@dorothy.peer.com> To: disman@dorothy.peer.com Subject: RFC 2591 updates Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list Content-Transfer-Encoding: 7bit Hi - Since folks are discussing clarifications and possible extensions, I figured I should ask: - What are the chances we can spin a new I-D for RFC 2591 updates before Adelaide? - Would anyone attend a WG session in Adelaide? ------------------------------------------------------------------------ Randy Presuhn randy_presuhn@bmc.com http://www.bmc.com/ Voice: +1 408 546-1006 BMC Software, Inc. 1-3141 2141 N. First Street Fax: +1 408 965-0359 San Jose, California 95131 USA ------------------------------------------------------------------------ Any relationship between my opinions and BMC's should be coincidental. ------------------------------------------------------------------------ From owner-disman@dorothy.bmc.com Thu Jan 6 05:35:26 2000 Received: from tangelo.bmc.com (fw-us-hou-2.bmc.com [198.207.223.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06678 for ; Thu, 6 Jan 2000 05:35:25 -0500 (EST) Received: from dorothy.bmc.com (dorothy.bmc.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id EAA08790; Thu, 6 Jan 2000 04:35:02 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id CAA18539 for disman-list; Thu, 6 Jan 2000 02:33:31 -0800 (PST) Received: from tangelo.bmc.com (root@tangelo.bmc.com [172.17.7.166]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id CAA18534 for ; Thu, 6 Jan 2000 02:33:26 -0800 (PST) Received: from fw-us-hou1.bmc.com (fw-us-hou1.bmc.com [172.17.0.250]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with SMTP id EAA08621 for ; Thu, 6 Jan 2000 04:33:48 -0600 (CST) Received: from henkell.ibr.cs.tu-bs.de (schoenw@henkell [134.169.34.191]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) with ESMTP id LAA23144; Thu, 6 Jan 2000 11:33:46 +0100 (MET) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id LAA09050; Thu, 6 Jan 2000 11:33:45 +0100 Date: Thu, 6 Jan 2000 11:33:45 +0100 Message-Id: <200001061033.LAA09050@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: luchuk@snmp.com CC: disman@dorothy.peer.com, luchuk@snmp.com In-reply-to: <200001051814.NAA06065@seymour47.SNMP.COM> (message from Alan Luchuk on Wed, 5 Jan 2000 13:14:42 -0500 (EST)) Subject: Re: References: <200001051814.NAA06065@seymour47.SNMP.COM> Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list >>>>> Alan Luchuk writes: Alan> Specifying IMPLIED for the second octet string index for each of Alan> the tables is inconsistent with the DISMAN-SCHEDULE-MIB and Alan> DISMAN-SCRIPT-MIB. Consistency in the MIBs produced by a single Alan> IETF WG reflects better upon the IETF WG that produced the MIBs. Alan> That is, if the MIBs produced by an IETF WG are consistent among Alan> each other, the MIBs then look like the same people wrote them. Alan> I suggest dropping the IMPLIED from each of the tables in the Alan> DISMAN-EVENT-MIB. My personal opinion is that you SHOULD NOT use IMPLIED unless you have a very very good reason to do so. I do not see a good reason why IMPLIED in this MIB has a big advantage and so I agree. With regard to the consistency problem: Bob and I obviously had very different views on MIB design and this is reflected in the document produced by this WG. It basically shows that the WG failed to define what the WG's preferred MIB design looks like. Hence, the editor's did what they think is the right thing to do. But I generally agree that consistency will (a) make it easier to read and understand these document, (b) make it easier to for users to use them in interesting combinations and (c) will save development time and costs for potential implementors. So even if it is very very very late in the process, we should try to align things, especially in areas that are hard to change after publication. (Changes in the indexing structure requires to deprecate whole tables - very annoying.) Alan> I suggest that renaming the MIB objects: Alan> mteTriggerEnabled -----> mteTriggerAdminStatus Alan> mteEventEnabled -----> mteEventAdminStatus Alan> would clarify the function of these MIB objects. It might also Alan> change the syntax of these objects to be consistent with the Alan> AdminStatus MIB objects in the DISMAN-SCHEDULE-MIB and DISMAN- Alan> SCRIPT-MIB. (Consistency comments above...) I would have no problem with such a change. ;-) Alan> The mteEventSetObject and mteEventSetValue support setting only Alan> Integer32 objects. This means the DISMAN-EVENT-MIB has the same Alan> set-event limitations that the DISMAN-SCHEDULE-MIB has. I Alan> suggest that providing a facility for setting arbitrary MIB Alan> objects when an event fires would increase the utility of the Alan> DISMAN-EVENT-MIB. Its possible to address this "limitation" for all these MIBs by defining something like a DISMAN-SET-MIB. I would rather go this direction instead of adding a facility for setting arbitrary MIB objects to the DISMAN-SCHEDULE-MIB or the DISMAN-EVENT-MIB or both. Alan> OK. Now a question about the notification handling of the Alan> DISMAN- EVENT-MIB. Can someone give me examples about why I Alan> would want to have trigger-specific, trigger-subclass-specific, Alan> and event-specific MIB object lists in event notifications? Why Alan> is it insufficient to have only the Alan> mteEventNotificationObjectsOwner and mteEventNotif- Alan> icationObjects and delete: Alan> mteTriggerObjectsOwner mteTriggerObjects Alan> mteTriggerExistenceObjectsOwner mteTriggerExistenceObjects Alan> mteTriggerBooleanObjectsOwner mteTriggerBooleanObjects Alan> mteTriggerThresholdObjectsOwner mteTriggerThresholdObjects I proposed this simplification several months (years?) ago. The question here is whether the additional (*ObjectsOwner, *Objects) pairs reduce the complexity of the configured rows substantially and whether the price in terms of additional complexity (both on the managers and agents side) is justified. I would start with a simple solution and add additional complexity once we know it is needed. /js -- Juergen Schoenwaelder Technical University Braunschweig Dept. Operating Systems & Computer Networks Phone: +49 531 391 3289 Bueltenweg 74/75, 38106 Braunschweig, Germany Fax: +49 531 391 5936 From owner-disman@dorothy.bmc.com Thu Jan 6 05:42:04 2000 Received: from tangelo.bmc.com (fw-us-hou-2.bmc.com [198.207.223.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06703 for ; Thu, 6 Jan 2000 05:42:03 -0500 (EST) Received: from dorothy.bmc.com (dorothy.bmc.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id EAA09655; Thu, 6 Jan 2000 04:41:58 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id CAA18560 for disman-list; Thu, 6 Jan 2000 02:41:24 -0800 (PST) Received: from tangelo.bmc.com (root@tangelo.bmc.com [172.17.7.166]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id CAA18551 for ; Thu, 6 Jan 2000 02:41:20 -0800 (PST) Received: from fw-us-hou1.bmc.com (fw-us-hou1.bmc.com [172.17.0.250]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with SMTP id EAA09612 for ; Thu, 6 Jan 2000 04:41:41 -0600 (CST) Received: from henkell.ibr.cs.tu-bs.de (schoenw@henkell [134.169.34.191]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) with ESMTP id LAA23705; Thu, 6 Jan 2000 11:41:40 +0100 (MET) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id LAA09234; Thu, 6 Jan 2000 11:41:39 +0100 Date: Thu, 6 Jan 2000 11:41:39 +0100 Message-Id: <200001061041.LAA09234@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: rpresuhn@dorothy.peer.com CC: disman@dorothy.peer.com In-reply-to: <200001060027.QAA16256@dorothy.peer.com> (message from Randy Presuhn on Wed, 5 Jan 2000 16:27:40 -0800 (PST)) Subject: Re: RFC 2591 updates References: <200001060027.QAA16256@dorothy.peer.com> Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list >>>>> Randy Presuhn writes: Randy> Since folks are discussing clarifications and possible Randy> extensions, I figured I should ask: Randy> - What are the chances we can spin a new I-D for RFC 2591 Randy> updates before Adelaide? New IDs for the RFC 2591 and RFC 2592 revision are no problem. Randy> - Would anyone attend a WG session in Adelaide? I have some doubts that I will make my way to Adelaide. Better do not count on me. (And I don't see an urgent need to have a meeting for the RFC 2591 and RFC 2592 revision. The only reason I see to hold a face to face meeting is to do _real_work_ on the EVENT and EXPRESSION MIBs in order to align them with the rest of what we have. But I also understand if you prefer no changes since we are way too late anyway.) /js -- Juergen Schoenwaelder Technical University Braunschweig Dept. Operating Systems & Computer Networks Phone: +49 531 391 3289 Bueltenweg 74/75, 38106 Braunschweig, Germany Fax: +49 531 391 5936 From owner-disman@dorothy.bmc.com Thu Jan 6 05:50:35 2000 Received: from tangelo.bmc.com (fw-us-hou-2.bmc.com [198.207.223.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06746 for ; Thu, 6 Jan 2000 05:50:34 -0500 (EST) Received: from dorothy.bmc.com (dorothy.bmc.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id EAA10731; Thu, 6 Jan 2000 04:50:29 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id CAA18581 for disman-list; Thu, 6 Jan 2000 02:49:54 -0800 (PST) Received: from tangelo.bmc.com (root@tangelo.bmc.com [172.17.7.166]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id CAA18575; Thu, 6 Jan 2000 02:49:50 -0800 (PST) Received: from fw-us-hou1.bmc.com (fw-us-hou1.bmc.com [172.17.0.250]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with SMTP id EAA10693; Thu, 6 Jan 2000 04:50:12 -0600 (CST) Received: from henkell.ibr.cs.tu-bs.de (schoenw@henkell [134.169.34.191]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) with ESMTP id LAA24243; Thu, 6 Jan 2000 11:50:09 +0100 (MET) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id LAA09458; Thu, 6 Jan 2000 11:50:09 +0100 Date: Thu, 6 Jan 2000 11:50:09 +0100 Message-Id: <200001061050.LAA09458@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: luchuk@snmp.com CC: rpresuhn@dorothy.peer.com, disman@dorothy.peer.com, hongal@yagosys.com In-reply-to: <200001051500.KAA05738@seymour47.SNMP.COM> (message from Alan Luchuk on Wed, 5 Jan 2000 10:00:31 -0500 (EST)) Subject: Re: Fwd: question regarding rfc2591, implementation References: <200001051500.KAA05738@seymour47.SNMP.COM> Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list >>>>> Alan Luchuk writes: Alan> The harder question is what is supposed to happen if you attempt Alan> to change the schedInterval while schedAdminStatus is 'enabled'. Alan> I have not checked RFC 2591 carefully to determine whether the Alan> RFC specifies how this _should_ work. I think RFC 2591 is silent about this case. Alan> But SNMP Research's DISMAN-SCHEDULE-MIB implementation lets you Alan> change the schedInterval while schedAdminStatus and Alan> schedOperStatus both are 'enabled'. I surfed through the code Alan> and also verified this behavior with an operational test. Our Alan> DISMAN-SCHEDULE-MIB implementation does _not_ briefly set Alan> schedAdminStatus or schedOperStatus to 'disabled' to make the Alan> change to schedInterval. I think that this is a reasonable interpretation. I do not see a strong reason why one should inhibit changes to schedInterval and friends while the schedAdminStatus and schedOperStatus is enabled (other than that it may be a bit easier to implement). Unless I hear a good argument why changes to schedInterval and friends should be disallowed as long as a row is enabled, I tend to put text into the next revision that clarifies that changing schedInterval is allowed even if schedAdminStatus and schedOperStatus are enabled. /js -- Juergen Schoenwaelder Technical University Braunschweig Dept. Operating Systems & Computer Networks Phone: +49 531 391 3289 Bueltenweg 74/75, 38106 Braunschweig, Germany Fax: +49 531 391 5936 From owner-disman@dorothy.bmc.com Thu Jan 6 06:15:09 2000 Received: from tangelo.bmc.com (fw-us-hou-2.bmc.com [198.207.223.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06864 for ; Thu, 6 Jan 2000 06:15:09 -0500 (EST) Received: from dorothy.bmc.com (dorothy.bmc.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id FAA13622; Thu, 6 Jan 2000 05:15:00 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id DAA18654 for disman-list; Thu, 6 Jan 2000 03:14:11 -0800 (PST) Received: from tangelo.bmc.com (root@tangelo.bmc.com [172.17.7.166]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id DAA18649 for ; Thu, 6 Jan 2000 03:14:07 -0800 (PST) Received: from fw-us-hou1.bmc.com (fw-us-hou1.bmc.com [172.17.0.250]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with SMTP id FAA13544 for ; Thu, 6 Jan 2000 05:14:29 -0600 (CST) Received: from henkell.ibr.cs.tu-bs.de (schoenw@henkell [134.169.34.191]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) with ESMTP id MAA26064; Thu, 6 Jan 2000 12:14:26 +0100 (MET) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id MAA09958; Thu, 6 Jan 2000 12:14:26 +0100 Date: Thu, 6 Jan 2000 12:14:26 +0100 Message-Id: <200001061114.MAA09958@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: luchuk@snmp.com CC: disman@dorothy.peer.com, luchuk@snmp.com In-reply-to: <200001051547.KAA05791@seymour47.SNMP.COM> (message from Alan Luchuk on Wed, 5 Jan 2000 10:47:01 -0500 (EST)) Subject: Re: Sched/Script MIB issues References: <200001051547.KAA05791@seymour47.SNMP.COM> Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list >>>>> Alan Luchuk writes: Alan> Issue Script-02: >>>> o Restartable scripts >> Scripts that are automatically launched when an agent starts up >> (or some other event happens). Alan> I believe Eamonn has a simple and elegant solution for launching Alan> scripts when the DISMAN-SCRIPT-MIB agent starts. If the Alan> smLaunchName begins with an asterisk, the corresponding launch Alan> 'button' is pressed automatically when the agent starts. I have Alan> added this to SNMP Research's DISMAN-SCRIPT-MIB implementation. Not sure I really like this solution. I understand that it is easy to implement. A cleaner solution would IMHO be to have the autostart bit encoded somewhere else. One could for example define a BITS object which has a bit set if the launch butten should be pressed by a restart event. A BITS object also allows to add additional flags over time without playing even more games with the name. The other ultimate solution is to define a mechanism which allows to launch scripts (or better perform sets on INTEGER valued objects) when a notification is generated or received. But this gets hairy when it comes down to passing notification details to the script or whatever got invoked. So I currently tend to prefer an object which indicated autostart behaviour and to leave a more general mechanism for future work (which would be a nice small MIB module independent from the schedule MIB itself). Alan> Issue Script-03: >>>> o Error message during script retrieval or compilation >>>> (smScriptError) >> So you argue in favour of adding such an object. Do you have a >> concrete proposal for the definition of such an object? Alan> I suggest adding a single octet string MIB object to the Alan> smScriptTable that can return compile-time error messages. This Alan> would provide a single-line error message that would describe Alan> the first compile-time error that occurred. Alan> Other solutions are possible, like a _table_ of octet strings Alan> that would describe all compile-time errors that occurred. Alan> SNMP Research's DISMAN-SCRIPT-MIB implementation would work just Alan> fine with a single-line error message, but I can see the value Alan> of an error message table. Alan> Based upon the preferences of the DISMAN WG for one or the other Alan> of these solutions, I'll be glad to write up first-cut additions Alan> to the DISMAN-SCRIPT-MIB. I would prefer a single object to keep things small. I think it should be an SnmpAdminString or do we really care about binary data? >> Issue Schedule-02: >> >> Can the SNMP manager modify CalendarGroup Objects and schedInterval >> object when the schedRowStatus is in 'active' state? Alan> SNMP Research's implementation lets you change the schedInterval Alan> while the schedRowStatus is 'active', and the row's schedAdmin- Alan> Status is 'enabled'. If the user resets the schedInterval, when Alan> the set occurs, the existing interval is cancelled and the new Alan> interval takes effect. Note that I did not re-check RFC 2591 to Alan> determine how this is _supposed_ to work. I think this is a reasonable interpretation. Strawman: Add a note which clarifies that sets on schedInterval and friends are legal if the schedRowStatus is 'active' and the row's schedAdminStatus and schedOperStatus is 'enabled'. /js -- Juergen Schoenwaelder Technical University Braunschweig Dept. Operating Systems & Computer Networks Phone: +49 531 391 3289 Bueltenweg 74/75, 38106 Braunschweig, Germany Fax: +49 531 391 5936 From owner-disman@dorothy.bmc.com Thu Jan 6 09:59:42 2000 Received: from tangelo.bmc.com (fw-us-hou-2.bmc.com [198.207.223.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13688 for ; Thu, 6 Jan 2000 09:59:23 -0500 (EST) Received: from dorothy.bmc.com (dorothy.bmc.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id IAA21721; Thu, 6 Jan 2000 08:58:32 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id GAA19030 for disman-list; Thu, 6 Jan 2000 06:56:15 -0800 (PST) Received: from tangelo.bmc.com (root@tangelo.bmc.com [172.17.7.166]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id GAA19024; Thu, 6 Jan 2000 06:56:10 -0800 (PST) Received: from fw-us-hou1.bmc.com (fw-us-hou1.bmc.com [172.17.0.250]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with SMTP id IAA20884; Thu, 6 Jan 2000 08:56:31 -0600 (CST) Received: from seymour47.SNMP.COM (seymour47.snmp.com [192.147.142.47]) by seymour39.SNMP.COM (8.9.3/snmpserver.mc-990526) with ESMTP id JAA07399; Thu, 6 Jan 2000 09:56:23 -0500 (EST) From: Alan Luchuk Received: (from luchuk@localhost) by seymour47.SNMP.COM (8.9.3/snmpclient.mc-990423) id JAA00679; Thu, 6 Jan 2000 09:56:22 -0500 (EST) Date: Thu, 6 Jan 2000 09:56:22 -0500 (EST) Message-Id: <200001061456.JAA00679@seymour47.SNMP.COM> To: rpresuhn@dorothy.peer.com Subject: Re: Cc: disman@dorothy.peer.com, luchuk@snmp.com Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list Hello all, I've made my technical comments about draft 9 of the DISMAN-EVENT-MIB. I'm not going to argue for changing anything in draft 9, but I would like to explain my points a little, if/when there is another doc cycle. >> Perhaps add a "MIN-ACCESS read-only" clause in the compliance statement >> for the mteResourceSampleMinimum and mteResourceSampleInstanceMaximum >> MIB objects. > >I don't see what problem or requirement this would address. >Let's leave this question for the future based on implementation >and deployment experience. Adding a "MIN-ACCESS read-only" clause in the compliance statement would let the DISMAN-EVENT-MIB _implementation_ specify the mteResourceSampleMinimum and mteResourceSampleInstanceMaximum values, instead of allowing the _user_ to specify them. >> In real-world implementations, the mteResourceSampleMinimum will >> always have seconds values that are zero or positive. I suggest >> that changing its syntax to "Unsigned32" better reflects the real- >> world values it can take on. Also, what is the rationale for the >> upper bound of 600 on mteResourceSampleMinimum? > >Changing the datatype from Integer32 to Unsigned32 would have >no effect on capability, but would change what shows up on the >wire. It's not a change we need to make. I can align with 'no changes'. I tend to be compulsive about choosing the MIB object data type to best reflect the real-world data for a two reasons. First, it seems incon- sistent that human beings must use the user-hostile, very formal, ASN.1 grammer to accurately specify the SNMP data objects, then negate some of the benefits of the formal ASN.1 grammer by choosing data types that are not the best fit with the real-world data. Second, my MIB compiler automatically generates code that range-checks the incoming data. With accurate ASN.1 specifications of the data-types, I do not have to manually code additional range checks to eliminate data values supported by the ASN.1 definition, but not supported by the real-world. Example: What does a mteResourceSampleMinimum of -1 seconds mean? >Bob subsequently identified the -1 as a cut-and-paste >error. The upper bound of 600 was never justified. >It looks like our agreement was to get rid of the upper >bound, i.e., make it 2147483647. Comments? Personally I don't care either way. 600 just seems arbitrary. >> Should the DISMAN-EVENT-MIB have the capability to wildcard the >> mteTriggerTargetTag? I can envision that DISMAN-EVENT-MIB users >> would want to monitor the same MIB objects on different IP hosts. > >The mteTriggerTargetTag is already capable of specifying >multiple ip hosts through the normal operation of the >target MIB. The need for yet another layer of wildcarding >hasn't been established (yet). Let's defer this. Works for me. Call me clueless, but I was unaware the target MIB supported specifying multiple IP hosts. (Although I did give the target MIB a quick scan before I wrote this comment.) >It's nice to know what object triggered the notification >as well as the values of potentially related objects. I believe that most existing (uncustomized) SNMP management stations can only log the variable-content notifications. I believe that most existing (uncustomized) SNMP management stations cannot graphically render the variable-content notifications. Because I believe that most management stations cannot parse and present variable-content notifications to their users, I suspect this capability in the DISMAN- EVENT-MIB will be unused (while adding complexity to the MIB.) There- fore, in future doc cycles of the DISMAN-EVENT-MIB, I believe the issue of having all of the xxxObjectOwner/xxxObject MIB objects in the trigger class/subclass tables should be carefully considered. >> Can someone give me examples where I would want to allow one >> user access to another user's entries in the mteObjectsTable >> and the mteEventTable? > >That's up to your security administrator. For example, the >head network administrator probably should have sufficient >rights to turn off any of the monitors his/her minions >have created. I suspect the capability of DISMAN-EVENT-MIB for Alan to generate triggers that reference Randy's objects and events will largely be unused in practice. Eliminating this capability could simplify the DISMAN-EVENT-MIB. >The comments are greatly appreciated. I just wish they had come >two years ago. Me too. But I was asked to review this at the 11th hour and 59th minute. Two years ago, my coefficient of cluelessness was even higher :-) Regards, --Alan ----------------------------------------------------------------------------- Alan Luchuk SNMP Research, Inc. Voice: +1 865 573 1434 Software Engineer 3001 Kimberlin Heights Road FAX: +1 865 573 9197 luchuk@snmp.com Knoxville, TN 37920-9716 U.S.A. http://www.snmp.com/ ----------------------------------------------------------------------------- Please note that our telephone area code recently changed from 423 to 865. Area 423 should countinue to work until it is phased out in April, 2000. From owner-disman@dorothy.bmc.com Thu Jan 6 10:07:24 2000 Received: from tangelo.bmc.com (fw-us-hou-2.bmc.com [198.207.223.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14037 for ; Thu, 6 Jan 2000 10:07:22 -0500 (EST) Received: from dorothy.peer.com (dorothy.bmc.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id JAA24779; Thu, 6 Jan 2000 09:07:10 -0600 (CST) Received: (from root@localhost) by dorothy.peer.com (8.8.6 (PHNE_12836)/8.8.6) id HAA19050 for disman-list; Thu, 6 Jan 2000 07:04:58 -0800 (PST) Received: from tangelo.bmc.com (root@tangelo.bmc.com [172.17.7.166]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id HAA19045 for ; Thu, 6 Jan 2000 07:04:54 -0800 (PST) Received: from fw-us-hou1.bmc.com (fw-us-hou1.bmc.com [172.17.0.250]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with SMTP id JAA23947 for ; Thu, 6 Jan 2000 09:05:16 -0600 (CST) Received: from seymour47.SNMP.COM (seymour47.snmp.com [192.147.142.47]) by seymour39.SNMP.COM (8.9.3/snmpserver.mc-990526) with ESMTP id KAA07872; Thu, 6 Jan 2000 10:04:36 -0500 (EST) From: Alan Luchuk Received: (from luchuk@localhost) by seymour47.SNMP.COM (8.9.3/snmpclient.mc-990423) id KAA00730; Thu, 6 Jan 2000 10:04:36 -0500 (EST) Date: Thu, 6 Jan 2000 10:04:36 -0500 (EST) Message-Id: <200001061504.KAA00730@seymour47.SNMP.COM> To: schoenw@ibr.cs.tu-bs.de Subject: Re: Cc: disman@dorothy.peer.com, luchuk@snmp.com Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list Juergen>Its possible to address this "limitation" for all these MIBs by Juergen>defining something like a DISMAN-SET-MIB. I would rather go this Juergen>direction instead of adding a facility for setting arbitrary MIB Juergen>objects to the DISMAN-SCHEDULE-MIB or the DISMAN-EVENT-MIB or both. Works for me. Seems like a good idea. Perhaps setting an integer value in a table in the DISMAN-SET-MIB would kick off the SNMP sets of the list of arbitrary objects. Then the existing DISMAN-SCHEDULE-MIB and DISMAN-EVENT-MIB could use this without changes. Regards, --Alan ----------------------------------------------------------------------------- Alan Luchuk SNMP Research, Inc. Voice: +1 865 573 1434 Software Engineer 3001 Kimberlin Heights Road FAX: +1 865 573 9197 luchuk@snmp.com Knoxville, TN 37920-9716 U.S.A. http://www.snmp.com/ ----------------------------------------------------------------------------- Please note that our telephone area code recently changed from 423 to 865. Area 423 should countinue to work until it is phased out in April, 2000. From owner-disman@dorothy.bmc.com Thu Jan 6 10:14:12 2000 Received: from tangelo.bmc.com (fw-us-hou-2.bmc.com [198.207.223.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14169 for ; Thu, 6 Jan 2000 10:14:06 -0500 (EST) Received: from dorothy.bmc.com (dorothy.bmc.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id JAA27319; Thu, 6 Jan 2000 09:13:45 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id HAA19074 for disman-list; Thu, 6 Jan 2000 07:13:07 -0800 (PST) Received: from tangelo.bmc.com (root@tangelo.bmc.com [172.17.7.166]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id HAA19069 for ; Thu, 6 Jan 2000 07:13:04 -0800 (PST) Received: from fw-us-hou1.bmc.com (fw-us-hou1.bmc.com [172.17.0.250]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with SMTP id JAA27173 for ; Thu, 6 Jan 2000 09:13:25 -0600 (CST) Received: from henkell.ibr.cs.tu-bs.de (schoenw@henkell [134.169.34.191]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) with ESMTP id QAA12446; Thu, 6 Jan 2000 16:12:38 +0100 (MET) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id QAA16936; Thu, 6 Jan 2000 16:12:37 +0100 Date: Thu, 6 Jan 2000 16:12:37 +0100 Message-Id: <200001061512.QAA16936@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: luchuk@snmp.com CC: disman@dorothy.peer.com, luchuk@snmp.com In-reply-to: <200001061504.KAA00730@seymour47.SNMP.COM> (message from Alan Luchuk on Thu, 6 Jan 2000 10:04:36 -0500 (EST)) Subject: Re: References: <200001061504.KAA00730@seymour47.SNMP.COM> Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list >>>>> Alan Luchuk writes: Juergen> Its possible to address this "limitation" for all these MIBs Juergen> by defining something like a DISMAN-SET-MIB. I would rather Juergen> go this direction instead of adding a facility for setting Juergen> arbitrary MIB objects to the DISMAN-SCHEDULE-MIB or the Juergen> DISMAN-EVENT-MIB or both. Alan> Works for me. Seems like a good idea. Perhaps setting an Alan> integer value in a table in the DISMAN-SET-MIB would kick off Alan> the SNMP sets of the list of arbitrary objects. Then the Alan> existing DISMAN-SCHEDULE-MIB and DISMAN-EVENT-MIB could use this Alan> without changes. Exactly. Formally, we need to do whatever is needed to update the WG charter. But I think we can also work ahead without a formal approval of this work item as long as the WG chair feels comfortable with this idea... /js -- Juergen Schoenwaelder Technical University Braunschweig Dept. Operating Systems & Computer Networks Phone: +49 531 391 3289 Bueltenweg 74/75, 38106 Braunschweig, Germany Fax: +49 531 391 5936 From owner-disman@dorothy.bmc.com Thu Jan 6 10:20:33 2000 Received: from tangelo.bmc.com (fw-us-hou-2.bmc.com [198.207.223.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14306 for ; Thu, 6 Jan 2000 10:20:28 -0500 (EST) Received: from dorothy.bmc.com (dorothy.bmc.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id JAA29693; Thu, 6 Jan 2000 09:20:12 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id HAA19091 for disman-list; Thu, 6 Jan 2000 07:19:26 -0800 (PST) Received: from tangelo.bmc.com (root@tangelo.bmc.com [172.17.7.166]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id HAA19086 for ; Thu, 6 Jan 2000 07:19:22 -0800 (PST) Received: from fw-us-hou1.bmc.com (fw-us-hou1.bmc.com [172.17.0.250]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with SMTP id JAA29545 for ; Thu, 6 Jan 2000 09:19:43 -0600 (CST) Received: from seymour47.SNMP.COM (seymour47.snmp.com [192.147.142.47]) by seymour39.SNMP.COM (8.9.3/snmpserver.mc-990526) with ESMTP id KAA01293; Thu, 6 Jan 2000 10:19:03 -0500 (EST) From: Alan Luchuk Received: (from luchuk@localhost) by seymour47.SNMP.COM (8.9.3/snmpclient.mc-990423) id KAA00802; Thu, 6 Jan 2000 10:19:02 -0500 (EST) Date: Thu, 6 Jan 2000 10:19:02 -0500 (EST) Message-Id: <200001061519.KAA00802@seymour47.SNMP.COM> To: schoenw@ibr.cs.tu-bs.de Subject: Re: Sched/Script MIB issues Cc: disman@dorothy.peer.com, luchuk@snmp.com Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list Hello all, >Alan> Issue Script-02: >>>>> o Restartable scripts >>> Scripts that are automatically launched when an agent starts up >>> (or some other event happens). > >Alan> I believe Eamonn has a simple and elegant solution for launching >Alan> scripts when the DISMAN-SCRIPT-MIB agent starts. If the >Alan> smLaunchName begins with an asterisk, the corresponding launch >Alan> 'button' is pressed automatically when the agent starts. I have >Alan> added this to SNMP Research's DISMAN-SCRIPT-MIB implementation. > Juergen>Not sure I really like this solution. I understand that it is easy to Juergen>implement. A cleaner solution would IMHO be to have the autostart bit Juergen>encoded somewhere else. One could for example define a BITS object Juergen>which has a bit set if the launch butten should be pressed by a Juergen>restart event. A BITS object also allows to add additional flags over Juergen>time without playing even more games with the name. The other ultimate Juergen>solution is to define a mechanism which allows to launch scripts (or Juergen>better perform sets on INTEGER valued objects) when a notification is Juergen>generated or received. But this gets hairy when it comes down to Juergen>passing notification details to the script or whatever got invoked. Juergen> Juergen>So I currently tend to prefer an object which indicated autostart Juergen>behaviour and to leave a more general mechanism for future work (which Juergen>would be a nice small MIB module independent from the schedule MIB Juergen>itself). I can align with whatever the DISMAN WG group decides is the best way to handle the auto-start issue. I implemented Eamonn's auto-start solution because it was way simpler and more elegant than what I devised. > >Alan> Issue Script-03: >>>>> o Error message during script retrieval or compilation >>>>> (smScriptError) >>> So you argue in favour of adding such an object. Do you have a >>> concrete proposal for the definition of such an object? > >Alan> I suggest adding a single octet string MIB object to the >Alan> smScriptTable that can return compile-time error messages. This >Alan> would provide a single-line error message that would describe >Alan> the first compile-time error that occurred. > >Alan> Other solutions are possible, like a _table_ of octet strings >Alan> that would describe all compile-time errors that occurred. > >Alan> SNMP Research's DISMAN-SCRIPT-MIB implementation would work just >Alan> fine with a single-line error message, but I can see the value >Alan> of an error message table. > >Alan> Based upon the preferences of the DISMAN WG for one or the other >Alan> of these solutions, I'll be glad to write up first-cut additions >Alan> to the DISMAN-SCRIPT-MIB. > >I would prefer a single object to keep things small. I think it should >be an SnmpAdminString or do we really care about binary data? OK. Based on a lone voice crying in the wilderness, would it make sense to add the following to the smScriptTable: smScriptCompileMessage OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION "Contains any single message produced during script compilation." ::= { smScriptEntry 10 } (It will be left to the astute reader to determine whether or not this was shamelessly cut-and-pasted from the smScriptDescr.) Would it also make sense to put in another MIB object the smScriptEntry that indicates the severity (e.g., like 'informational', 'warning', 'error', and 'fatal') of the smScriptCompileMessage? Regards, --Alan ----------------------------------------------------------------------------- Alan Luchuk SNMP Research, Inc. Voice: +1 865 573 1434 Software Engineer 3001 Kimberlin Heights Road FAX: +1 865 573 9197 luchuk@snmp.com Knoxville, TN 37920-9716 U.S.A. http://www.snmp.com/ ----------------------------------------------------------------------------- Please note that our telephone area code recently changed from 423 to 865. Area 423 should countinue to work until it is phased out in April, 2000. From owner-disman@dorothy.bmc.com Thu Jan 6 10:38:11 2000 Received: from tangelo.bmc.com (fw-us-hou-2.bmc.com [198.207.223.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14585 for ; Thu, 6 Jan 2000 10:38:01 -0500 (EST) Received: from dorothy.bmc.com (dorothy.bmc.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id JAA05224; Thu, 6 Jan 2000 09:37:45 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id HAA19131 for disman-list; Thu, 6 Jan 2000 07:36:51 -0800 (PST) Received: from tangelo.bmc.com (root@tangelo.bmc.com [172.17.7.166]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id HAA19126 for ; Thu, 6 Jan 2000 07:36:48 -0800 (PST) Received: from fw-us-hou1.bmc.com (fw-us-hou1.bmc.com [172.17.0.250]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with SMTP id JAA05053 for ; Thu, 6 Jan 2000 09:37:09 -0600 (CST) Received: from henkell.ibr.cs.tu-bs.de (schoenw@henkell [134.169.34.191]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) with ESMTP id QAA13788; Thu, 6 Jan 2000 16:36:48 +0100 (MET) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id QAA17692; Thu, 6 Jan 2000 16:36:48 +0100 Date: Thu, 6 Jan 2000 16:36:48 +0100 Message-Id: <200001061536.QAA17692@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: luchuk@snmp.com CC: disman@dorothy.peer.com, luchuk@snmp.com In-reply-to: <200001061519.KAA00802@seymour47.SNMP.COM> (message from Alan Luchuk on Thu, 6 Jan 2000 10:19:02 -0500 (EST)) Subject: Re: Sched/Script MIB issues References: <200001061519.KAA00802@seymour47.SNMP.COM> Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list >>>>> Alan Luchuk writes: Alan> OK. Based on a lone voice crying in the wilderness, would it Alan> make sense to add the following to the smScriptTable: : smScriptCompileMessage OBJECT-TYPE : SYNTAX SnmpAdminString : MAX-ACCESS read-only : STATUS current : DESCRIPTION : "Contains any single message produced during script compilation." : ::= { smScriptEntry 10 } Alan> (It will be left to the astute reader to determine whether or Alan> not this was shamelessly cut-and-pasted from the smScriptDescr.) Why do you want to restrict this object to compilation errors? Would it not make more sense to have something like the following: smScriptErrorMessage OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION "This object contains a descriptive error message whenever the corresponding smScriptOperStatus variable indicates a non-transient error state. This object must be cleared whenever the value of smScriptOperStatus changes to one of the values `enabled', `disabled', `editing', `retrieving', or `compiling'." ::= { smScriptEntry 10 } This way, the object can also hold a descriptive error message in cases such as a failed download (e.g. protocolFailure). Alan> Would it also make sense to put in another MIB object the Alan> smScriptEntry that indicates the severity (e.g., like Alan> 'informational', 'warning', 'error', and 'fatal') of the Alan> smScriptCompileMessage? I originally did not think of 'informational' or 'warning' messages. But we can probably allow them in case you reach the `enabled' state. Not sure we really should go down the path to try to classify these messages. In other words: a distinction between 'informational'/'warning' and 'error'/'fatal' is already in place (smScriptOperStatus). Not sure we really need more since the precise distinction between these levels will really be implementation dependent, I think. /js -- Juergen Schoenwaelder Technical University Braunschweig Dept. Operating Systems & Computer Networks Phone: +49 531 391 3289 Bueltenweg 74/75, 38106 Braunschweig, Germany Fax: +49 531 391 5936 From owner-disman@dorothy.bmc.com Thu Jan 6 11:58:38 2000 Received: from tangelo.bmc.com (fw-us-hou-2.bmc.com [198.207.223.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16338 for ; Thu, 6 Jan 2000 11:58:24 -0500 (EST) Received: from dorothy.bmc.com (dorothy.bmc.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id KAA04243; Thu, 6 Jan 2000 10:58:01 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id IAA00763 for disman-list; Thu, 6 Jan 2000 08:48:58 -0800 (PST) Received: from tangelo.bmc.com (root@tangelo.bmc.com [172.17.7.166]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id IAA00745 for ; Thu, 6 Jan 2000 08:48:51 -0800 (PST) Received: from fw-us-hou1.bmc.com (fw-us-hou1.bmc.com [172.17.0.250]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with SMTP id KAA26957 for ; Thu, 6 Jan 2000 10:38:12 -0600 (CST) Received: from seymour47.SNMP.COM (seymour47.snmp.com [192.147.142.47]) by seymour39.SNMP.COM (8.9.3/snmpserver.mc-990526) with ESMTP id LAA19141; Thu, 6 Jan 2000 11:37:37 -0500 (EST) From: Alan Luchuk Received: (from luchuk@localhost) by seymour47.SNMP.COM (8.9.3/snmpclient.mc-990423) id LAA01206; Thu, 6 Jan 2000 11:37:36 -0500 (EST) Date: Thu, 6 Jan 2000 11:37:36 -0500 (EST) Message-Id: <200001061637.LAA01206@seymour47.SNMP.COM> To: schoenw@ibr.cs.tu-bs.de Subject: Re: Sched/Script MIB issues Cc: disman@dorothy.peer.com, luchuk@snmp.com Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list Hello, Juergen>Why do you want to restrict this object to compilation errors? Would Juergen>it not make more sense to have something like the following: Juergen> Juergen>smScriptErrorMessage OBJECT-TYPE Juergen> SYNTAX SnmpAdminString Juergen> MAX-ACCESS read-only Juergen> STATUS current Juergen> DESCRIPTION Juergen> "This object contains a descriptive error message whenever Juergen> the corresponding smScriptOperStatus variable indicates Juergen> a non-transient error state. Juergen> Juergen> This object must be cleared whenever the value of Juergen> smScriptOperStatus changes to one of the values `enabled', Juergen> `disabled', `editing', `retrieving', or `compiling'." Juergen> ::= { smScriptEntry 10 } Juergen> Juergen>This way, the object can also hold a descriptive error message in Juergen>cases such as a failed download (e.g. protocolFailure). I did not think of this generalized message. I agree that your idea (a more general-purpose descriptive message) is superior. Regards, --Alan ----------------------------------------------------------------------------- Alan Luchuk SNMP Research, Inc. Voice: +1 865 573 1434 Software Engineer 3001 Kimberlin Heights Road FAX: +1 865 573 9197 luchuk@snmp.com Knoxville, TN 37920-9716 U.S.A. http://www.snmp.com/ ----------------------------------------------------------------------------- Please note that our telephone area code recently changed from 423 to 865. Area 423 should countinue to work until it is phased out in April, 2000. From owner-disman@dorothy.bmc.com Thu Jan 6 14:21:35 2000 Received: from tangelo.bmc.com (fw-us-hou-2.bmc.com [198.207.223.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20327 for ; Thu, 6 Jan 2000 14:21:33 -0500 (EST) Received: from dorothy.peer.com (dorothy.bmc.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id NAA17387; Thu, 6 Jan 2000 13:21:02 -0600 (CST) Received: (from root@localhost) by dorothy.peer.com (8.8.6 (PHNE_12836)/8.8.6) id LAA02980 for disman-list; Thu, 6 Jan 2000 11:13:23 -0800 (PST) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id LAA02974 for disman@dorothy.bmc.com; Thu, 6 Jan 2000 11:13:19 -0800 (PST) Date: Thu, 6 Jan 2000 11:13:19 -0800 (PST) From: Randy Presuhn Message-Id: <200001061913.LAA02974@dorothy.bmc.com> To: disman@dorothy.peer.com Subject: Re: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list Content-Transfer-Encoding: 7bit Hi - > From: Alan Luchuk > Date: Thu, 6 Jan 2000 09:56:22 -0500 (EST) > Message-Id: <200001061456.JAA00679@seymour47.SNMP.COM> > To: rpresuhn@dorothy.peer.com > Subject: Re: > Cc: disman@dorothy.peer.com, luchuk@snmp.com > > Hello all, > > I've made my technical comments about draft 9 of the DISMAN-EVENT-MIB. > I'm not going to argue for changing anything in draft 9, but I would > like to explain my points a little, if/when there is another doc cycle. > > > >> Perhaps add a "MIN-ACCESS read-only" clause in the compliance statement >> MIB objects. > > > >I don't see what problem or requirement this would address. > >Let's leave this question for the future based on implementation > >and deployment experience. > > Adding a "MIN-ACCESS read-only" clause in the compliance statement > would let the DISMAN-EVENT-MIB _implementation_ specify the > mteResourceSampleMinimum and mteResourceSampleInstanceMaximum > values, instead of allowing the _user_ to specify them. I think the current object definitions already cover this, where it has words to the effect "A system may use the larger values of this minimum to lessen the impact of constant sampling." No matter what the user asks for, the implementation can impose any lower bound it wants. > >> In real-world implementations, the mteResourceSampleMinimum will > >> always have seconds values that are zero or positive. I suggest > >> that changing its syntax to "Unsigned32" better reflects the real- > >> world values it can take on. Also, what is the rationale for the > >> upper bound of 600 on mteResourceSampleMinimum? > > > >Changing the datatype from Integer32 to Unsigned32 would have > >no effect on capability, but would change what shows up on the > >wire. It's not a change we need to make. > > > I can align with 'no changes'. > > I tend to be compulsive about choosing the MIB object data type to best > reflect the real-world data for a two reasons. First, it seems incon- > sistent that human beings must use the user-hostile, very formal, ASN.1 > grammer to accurately specify the SNMP data objects, then negate some of > the benefits of the formal ASN.1 grammer by choosing data types that are > not the best fit with the real-world data. Second, my MIB compiler > automatically generates code that range-checks the incoming data. With > accurate ASN.1 specifications of the data-types, I do not have to manually > code additional range checks to eliminate data values supported by the > ASN.1 definition, but not supported by the real-world. Example: What > does a mteResourceSampleMinimum of -1 seconds mean? I could sell you a MIB compiler that generates the correct checks. :-) The SYNTAX clause clearly specifies that -1 would be a bad value. > >Bob subsequently identified the -1 as a cut-and-paste > >error. The upper bound of 600 was never justified. > >It looks like our agreement was to get rid of the upper > >bound, i.e., make it 2147483647. Comments? > > Personally I don't care either way. 600 just seems arbitrary. That was the sense of the room at the WG meeting. Since this appears to be an agreed change that wasn't applied, Let's make it 2147483647. > >> Should the DISMAN-EVENT-MIB have the capability to wildcard the > >> mteTriggerTargetTag? I can envision that DISMAN-EVENT-MIB users > >> would want to monitor the same MIB objects on different IP hosts. > > > >The mteTriggerTargetTag is already capable of specifying > >multiple ip hosts through the normal operation of the > >target MIB. The need for yet another layer of wildcarding > >hasn't been established (yet). Let's defer this. > > Works for me. Call me clueless, but I was unaware the target MIB > supported specifying multiple IP hosts. (Although I did give the > target MIB a quick scan before I wrote this comment.) One would do this by using a tag which appeared in multiple instances of snmpTargetAddrTagList in the snmpTargetAddrTable in RFC 2573. Conceptually, it's like have another (invisible) table which has the individual tags from each of the snmpTargetAddrTagLists as one its first index, and snmpTargetAddrName as its second index, serving as an associative memory representing the 1:N relationship. > > >It's nice to know what object triggered the notification > >as well as the values of potentially related objects. > > I believe that most existing (uncustomized) SNMP management stations > can only log the variable-content notifications. I believe that most > existing (uncustomized) SNMP management stations cannot graphically > render the variable-content notifications. Because I believe that > most management stations cannot parse and present variable-content > notifications to their users, I suspect this capability in the DISMAN- > EVENT-MIB will be unused (while adding complexity to the MIB.) There- > fore, in future doc cycles of the DISMAN-EVENT-MIB, I believe the issue > of having all of the xxxObjectOwner/xxxObject MIB objects in the > trigger class/subclass tables should be carefully considered. It'd be nice to hear from dbh and other manager folks on this. > > >> Can someone give me examples where I would want to allow one > >> user access to another user's entries in the mteObjectsTable > >> and the mteEventTable? > > > >That's up to your security administrator. For example, the > >head network administrator probably should have sufficient > >rights to turn off any of the monitors his/her minions > >have created. > > I suspect the capability of DISMAN-EVENT-MIB for Alan to generate > triggers that reference Randy's objects and events will largely > be unused in practice. Eliminating this capability could simplify > the DISMAN-EVENT-MIB. ... That could be. We won't know until we get some experience with the thing. I think part of the rationale was that, in order to conserve resources, an administration would define common events (and payloads) to which individual operators would "subscribe" through their trigger setups. It'll be interesting to see what, if anything, is done with this. ------------------------------------------------------------------------ Randy Presuhn randy_presuhn@bmc.com http://www.bmc.com/ Voice: +1 408 546-1006 BMC Software, Inc. 1-3141 2141 N. First Street Fax: +1 408 965-0359 San Jose, California 95131 USA ------------------------------------------------------------------------ Any relationship between my opinions and BMC's should be coincidental. ------------------------------------------------------------------------ From owner-disman@dorothy.bmc.com Thu Jan 6 19:30:53 2000 Received: from tangelo.bmc.com (fw-us-hou-2.bmc.com [198.207.223.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25760 for ; Thu, 6 Jan 2000 19:30:52 -0500 (EST) Received: from dorothy.bmc.com (dorothy.bmc.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id SAA08830; Thu, 6 Jan 2000 18:30:37 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id QAA13078 for disman-list; Thu, 6 Jan 2000 16:29:09 -0800 (PST) Received: from tangelo.bmc.com (root@tangelo.bmc.com [172.17.7.166]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id QAA13068 for ; Thu, 6 Jan 2000 16:29:02 -0800 (PST) Received: from fw-us-hou1.bmc.com (fw-us-hou1.bmc.com [172.17.0.250]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with SMTP id SAA08551 for ; Thu, 6 Jan 2000 18:29:20 -0600 (CST) Received: from ramk-pc.cisco.com (dhcp-171-69-66-201.cisco.com [171.69.66.201]) by sigma.cisco.com (8.8.8-Cisco List Logging/8.8.8) with SMTP id QAA10604; Thu, 6 Jan 2000 16:29:17 -0800 (PST) Message-Id: <4.1.20000106140118.009c04c0@sigma.cisco.com> Message-Id: <4.1.20000106140118.009c04c0@sigma.cisco.com> X-Sender: ramk@sigma.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Thu, 06 Jan 2000 14:01:37 -0800 To: Randy Presuhn , disman@dorothy.peer.com From: Ramanathan Kavasseri Subject: Re: Editorial comments about DISMAN-EVENT-MIB Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list At 02:07 PM 1/5/00 -0800, Randy Presuhn wrote: > >Hi - > >> From: Alan Luchuk >> Date: Wed, 5 Jan 2000 14:56:36 -0500 (EST) >> Message-Id: <200001051956.OAA06214@seymour47.SNMP.COM> >> To: rpresuhn@dorothy.peer.com >> Subject: Re: Editorial comments about DISMAN-EVENT-MIB >> Cc: disman@dorothy.peer.com, luchuk@snmp.com, ramk@cisco.com >> List-Id: IETF disman Working Group mailing list >... >> I have questions about Randy's replies to my editorial comments on >> . In this reply, I deleted >> most of Randy's comments to shorten the E-mail. What remains are >> only the few items I have questions about. >> >> >> >> >> Page 8, fourth paragraph: >> >> ------------------------- >> >> >> >> Need a few spaces between "[rfcNotificationLogMIB]." and "MIB". >> > >> >?? The only occurrance of rfcNotificationLogMIB is on page 6. >> >The "rfc" should be replaced with RFC, though the whole thing >> >should be replaced during the publication process. >> >> Are we both looking at ? > >Silly me. I was looking at the most recent i-d, which is just -08. >Yet another reason why stuff should be posted as i-ds, rather than >just being sent to the mailing list. My mistake. > >> I doubled checked, in my copy, this is in _section_ 6, titled >> "Operation", on _page_ 8. > >?? I think you mean there should be a couple of spaces before the >word "Note". "MIB" and "[rfcNotificationLogMIB]." are on different >lines. Ahhhh... *bing* - I finally figured what you were saying...Done. >> >> >> >> >> Page 16, second paragraph: >> >> -------------------------- >> >> >> >> Currently reads: >> >> >> >> For 'existence', the specific test is as selected by >> >> mteTriggerExistenceTest. When an object appears or vanishes >> >> the trigger fires. The trigger will not fire again until the >> >> object has changed states. >> >> >> >> I suggest the following text is a little clearer (and more accurate): >> >> >> >> For 'existence', the specific test is as selected by >> >> mteTriggerExistenceTest. When an object appears, vanishes, or >> >> changes value, then the trigger fires. The trigger will not >> >> fire again until the object has changed states. >> >> >> > >> >Adding "or changes value" would be a significant technical change. >> >This would be inappropriate at this time. Unless there is a good >> >internal consistency argument that the current text here is in >> >error, as WG chair I'm inclined to rule "too late" on this one. >> >> >> Why would adding "or changes value" be a significant technical change? >> The mteTriggerExistenceTest object is defined (on page 24) as follows: >> >> mteTriggerExistenceTest OBJECT-TYPE >> SYNTAX BITS { present(0), absent(1), changed(2) } >> MAX-ACCESS read-write >> STATUS current >> DESCRIPTION >> "The type of existence test to perform. The trigger fires >> when the object at mteTriggerValueID is seen to go from >> present to absent, from absent to present, or to have it's >> value changed, depending on which tests are selected. >> >> Once the trigger has fired for either presence or absence it >> will not fire again for that state until the object has been >> to the other state." >> DEFVAL { { present, absent } } >> ::= { mteTriggerExistenceEntry 1 } >> >> >> Adding "or changes value" (on page 16, second paragraph) simply states >> in verbiage what the the mteTriggerExistenceTest SYNTAX and DESCRIPTION >> clauses (on page 24) already says. > >Ok. You've convinced me. Ram, fix it. :-) By "fix it", did you mean add Alan's text (that would be the easiest thing to do, and would not change the operation of mteTriggerExistenceTest), or remove the "or to have its value changed," text, which is a significant operational deviation from the existing text? I'm assuming that it's the former... >> Personally, I don't really care about whether or not "or changes value" >> is added on page 16, I just thought adding the my suggested text would >> more accurately reflect the definition of mteTriggerExistenceTest. I'm >> asking why this is considered a technical change so I better understand >> the IETF standards-writing "procedural" stuff. > >That's why I handed you the "Unless". You've given a solid argument >based on the internal consistency of the specification. I agree it >should be fixed, based on your argument. > >> >> >> >> >> Page 25 >> >> ------- >> >> >> >> The DESCRIPTION clause for the mteTriggerExistenceEventOwner >> >> references the mteObjectsTable. >> >> >> > >> >I believe the current description is correct. >> >It's consistent with all the other mte*EventOwner objects. >> >> Huh? I double-checked. Closely compare the DESCRIPTION clauses of: >> >> mteTriggerExistenceEventOwner >> mteTriggerBooleanEventOwner >> mteTriggerThresholdRisingEventOwner >> mteTriggerThresholdFallingEventOwner >> >> The DESCRIPTION clause of mteTriggerExistenceEventOwner differs >> from the other three. I thought the EventOwner objects referred >> to the mteEventTable, not the mteObjectsTable (as written in the >> mteTriggerExistenceEventOwner DESCRIPTION clause.) >... > >Right again. Ram, fix it. :-) Done. :-) BTW, Alan, thanks for the detailed reviews... :-) Ram > ------------------------------------------------------------------------ > Randy Presuhn randy_presuhn@bmc.com http://www.bmc.com/ > Voice: +1 408 546-1006 BMC Software, Inc. 1-3141 2141 N. First Street > Fax: +1 408 965-0359 San Jose, California 95131 USA > ------------------------------------------------------------------------ > Any relationship between my opinions and BMC's should be coincidental. > ------------------------------------------------------------------------ > From owner-disman@dorothy.bmc.com Thu Jan 6 19:38:27 2000 Received: from tangelo.bmc.com (fw-us-hou-2.bmc.com [198.207.223.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25761 for ; Thu, 6 Jan 2000 19:30:52 -0500 (EST) Received: from dorothy.bmc.com (dorothy.bmc.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id SAA08835; Thu, 6 Jan 2000 18:30:37 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id QAA13097 for disman-list; Thu, 6 Jan 2000 16:29:31 -0800 (PST) Received: from tangelo.bmc.com (root@tangelo.bmc.com [172.17.7.166]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id QAA13090; Thu, 6 Jan 2000 16:29:25 -0800 (PST) Received: from fw-us-hou1.bmc.com (fw-us-hou1.bmc.com [172.17.0.250]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with SMTP id SAA08685; Thu, 6 Jan 2000 18:29:49 -0600 (CST) Received: from ramk-pc.cisco.com (dhcp-171-69-66-201.cisco.com [171.69.66.201]) by sigma.cisco.com (8.8.8-Cisco List Logging/8.8.8) with SMTP id QAA10598; Thu, 6 Jan 2000 16:29:16 -0800 (PST) Message-Id: <4.1.20000106133934.00a05ea0@sigma.cisco.com> Message-Id: <4.1.20000106133934.00a05ea0@sigma.cisco.com> X-Sender: ramk@sigma.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Thu, 06 Jan 2000 13:51:46 -0800 To: Alan Luchuk , rpresuhn@dorothy.peer.com From: Ramanathan Kavasseri Subject: Re: Editorial comments about DISMAN-EVENT-MIB Cc: disman@dorothy.peer.com, luchuk@snmp.com In-Reply-To: <200001051956.OAA06214@seymour47.SNMP.COM> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list At 02:56 PM 1/5/00 -0500, Alan Luchuk wrote: >Hello, > >I have questions about Randy's replies to my editorial comments on >. In this reply, I deleted >most of Randy's comments to shorten the E-mail. What remains are >only the few items I have questions about. > > > >>> Page 8, fourth paragraph: >>> ------------------------- >>> >>> Need a few spaces between "[rfcNotificationLogMIB]." and "MIB". >> >>?? The only occurrance of rfcNotificationLogMIB is on page 6. >>The "rfc" should be replaced with RFC, though the whole thing >>should be replaced during the publication process. > >Are we both looking at ? >I doubled checked, in my copy, this is in _section_ 6, titled >"Operation", on _page_ 8. > > >>> >>> Page 16, second paragraph: >>> -------------------------- >>> >>> Currently reads: >>> >>> For 'existence', the specific test is as selected by >>> mteTriggerExistenceTest. When an object appears or vanishes >>> the trigger fires. The trigger will not fire again until the >>> object has changed states. >>> >>> I suggest the following text is a little clearer (and more accurate): >>> >>> For 'existence', the specific test is as selected by >>> mteTriggerExistenceTest. When an object appears, vanishes, or >>> changes value, then the trigger fires. The trigger will not >>> fire again until the object has changed states. >>> >> >>Adding "or changes value" would be a significant technical change. >>This would be inappropriate at this time. Unless there is a good >>internal consistency argument that the current text here is in >>error, as WG chair I'm inclined to rule "too late" on this one. > > >Why would adding "or changes value" be a significant technical change? >The mteTriggerExistenceTest object is defined (on page 24) as follows: > > mteTriggerExistenceTest OBJECT-TYPE > SYNTAX BITS { present(0), absent(1), changed(2) } > MAX-ACCESS read-write > STATUS current > DESCRIPTION > "The type of existence test to perform. The trigger fires > when the object at mteTriggerValueID is seen to go from > present to absent, from absent to present, or to have it's > value changed, depending on which tests are selected. Hmm, the above "have it's value changed" text seems to be in error. I'd like to see it removed, but it presents a significant operational change...Comments from the chair? I don't think an "existence check" should have anything to do with testing values... > Once the trigger has fired for either presence or absence it > will not fire again for that state until the object has been > to the other state." > DEFVAL { { present, absent } } > ::= { mteTriggerExistenceEntry 1 } > > >Adding "or changes value" (on page 16, second paragraph) simply states >in verbiage what the the mteTriggerExistenceTest SYNTAX and DESCRIPTION >clauses (on page 24) already says. > >Personally, I don't really care about whether or not "or changes value" >is added on page 16, I just thought adding the my suggested text would >more accurately reflect the definition of mteTriggerExistenceTest. I'm >asking why this is considered a technical change so I better understand >the IETF standards-writing "procedural" stuff. I see where you're coming from...I don't think the DESXCRIPTION of the mteTriggerExistenceTest is correct - perhaps someone else can fill in the reason why the DESCRIPTION asks to test for value changes... >>> >>> Page 25 >>> ------- >>> >>> The DESCRIPTION clause for the mteTriggerExistenceEventOwner >>> references the mteObjectsTable. >>> >> >>I believe the current description is correct. >>It's consistent with all the other mte*EventOwner objects. > >Huh? I double-checked. Closely compare the DESCRIPTION clauses of: > > mteTriggerExistenceEventOwner > mteTriggerBooleanEventOwner > mteTriggerThresholdRisingEventOwner > mteTriggerThresholdFallingEventOwner > >The DESCRIPTION clause of mteTriggerExistenceEventOwner differs >from the other three. I thought the EventOwner objects referred >to the mteEventTable, not the mteObjectsTable (as written in the >mteTriggerExistenceEventOwner DESCRIPTION clause.) You're right...Fixed it...The text now reads: mteTriggerExistenceEventOwner OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (0..32)) MAX-ACCESS read-write STATUS current DESCRIPTION "To go with mteTriggerExistenceEvent, the mteOwner of an event entry from the mteEventTable." DEFVAL { ''H } ::= { mteTriggerExistenceEntry 5 } Thanks, Ram >Regards, >--Alan > > ----------------------------------------------------------------------------- > Alan Luchuk SNMP Research, Inc. Voice: +1 865 573 1434 > Software Engineer 3001 Kimberlin Heights Road FAX: +1 865 573 9197 > luchuk@snmp.com Knoxville, TN 37920-9716 U.S.A. http://www.snmp.com/ > ----------------------------------------------------------------------------- > > Please note that our telephone area code recently changed from 423 to 865. > Area 423 should countinue to work until it is phased out in April, 2000. > From owner-disman@dorothy.bmc.com Thu Jan 6 19:38:28 2000 Received: from tangelo.bmc.com (fw-us-hou-2.bmc.com [198.207.223.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25762 for ; Thu, 6 Jan 2000 19:30:52 -0500 (EST) Received: from dorothy.peer.com (dorothy.bmc.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id SAA08820; Thu, 6 Jan 2000 18:30:35 -0600 (CST) Received: (from root@localhost) by dorothy.peer.com (8.8.6 (PHNE_12836)/8.8.6) id QAA13079 for disman-list; Thu, 6 Jan 2000 16:29:14 -0800 (PST) Received: from tangelo.bmc.com (root@tangelo.bmc.com [172.17.7.166]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id QAA13072 for ; Thu, 6 Jan 2000 16:29:03 -0800 (PST) Received: from fw-us-hou1.bmc.com (fw-us-hou1.bmc.com [172.17.0.250]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with SMTP id SAA08575 for ; Thu, 6 Jan 2000 18:29:25 -0600 (CST) Received: from ramk-pc.cisco.com (dhcp-171-69-66-201.cisco.com [171.69.66.201]) by sigma.cisco.com (8.8.8-Cisco List Logging/8.8.8) with SMTP id QAA10618; Thu, 6 Jan 2000 16:29:20 -0800 (PST) Message-Id: <4.1.20000106142354.00988dc0@sigma.cisco.com> Message-Id: <4.1.20000106142354.00988dc0@sigma.cisco.com> X-Sender: ramk@sigma.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Thu, 06 Jan 2000 14:48:11 -0800 To: Randy Presuhn , disman@dorothy.peer.com From: Ramanathan Kavasseri Subject: Re: In-Reply-To: <200001061913.LAA02974@dorothy.bmc.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list At 11:13 AM 1/6/00 -0800, Randy Presuhn wrote: > >Hi - > >> From: Alan Luchuk >> Date: Thu, 6 Jan 2000 09:56:22 -0500 (EST) >> Message-Id: <200001061456.JAA00679@seymour47.SNMP.COM> >> To: rpresuhn@dorothy.peer.com >> Subject: Re: >> Cc: disman@dorothy.peer.com, luchuk@snmp.com >> >> Hello all, >> >> I've made my technical comments about draft 9 of the DISMAN-EVENT-MIB. >> I'm not going to argue for changing anything in draft 9, but I would >> like to explain my points a little, if/when there is another doc cycle. >> >> >> >> Perhaps add a "MIN-ACCESS read-only" clause in the compliance statement >>> MIB objects. >> > >> >I don't see what problem or requirement this would address. >> >Let's leave this question for the future based on implementation >> >and deployment experience. >> >> Adding a "MIN-ACCESS read-only" clause in the compliance statement >> would let the DISMAN-EVENT-MIB _implementation_ specify the >> mteResourceSampleMinimum and mteResourceSampleInstanceMaximum >> values, instead of allowing the _user_ to specify them. > >I think the current object definitions already cover >this, where it has words to the effect "A system may use >the larger values of this minimum to lessen the impact of >constant sampling." No matter what the user asks for, the >implementation can impose any lower bound it wants. I agree. Since the choice is left to the implementation to choose a "saner" value, we should leave this as is... Also you can still implement the object as read-only, and supply a CAPABILITY MIB indicating that it is a read-only implementation, right? >> >> In real-world implementations, the mteResourceSampleMinimum will >> >> always have seconds values that are zero or positive. I suggest >> >> that changing its syntax to "Unsigned32" better reflects the real- >> >> world values it can take on. Also, what is the rationale for the >> >> upper bound of 600 on mteResourceSampleMinimum? >> > >> >Changing the datatype from Integer32 to Unsigned32 would have >> >no effect on capability, but would change what shows up on the >> >wire. It's not a change we need to make. >> >> >> I can align with 'no changes'. >> >> I tend to be compulsive about choosing the MIB object data type to best >> reflect the real-world data for a two reasons. First, it seems incon- >> sistent that human beings must use the user-hostile, very formal, ASN.1 >> grammer to accurately specify the SNMP data objects, then negate some of >> the benefits of the formal ASN.1 grammer by choosing data types that are >> not the best fit with the real-world data. Second, my MIB compiler >> automatically generates code that range-checks the incoming data. With >> accurate ASN.1 specifications of the data-types, I do not have to manually >> code additional range checks to eliminate data values supported by the >> ASN.1 definition, but not supported by the real-world. Example: What >> does a mteResourceSampleMinimum of -1 seconds mean? > >I could sell you a MIB compiler that generates the correct checks. :-) >The SYNTAX clause clearly specifies that -1 would be a bad value. > >> >Bob subsequently identified the -1 as a cut-and-paste >> >error. The upper bound of 600 was never justified. >> >It looks like our agreement was to get rid of the upper >> >bound, i.e., make it 2147483647. Comments? >> >> Personally I don't care either way. 600 just seems arbitrary. > >That was the sense of the room at the WG meeting. >Since this appears to be an agreed change that >wasn't applied, Let's make it 2147483647. Done. [...snip...] >> >> Can someone give me examples where I would want to allow one >> >> user access to another user's entries in the mteObjectsTable >> >> and the mteEventTable? >> > >> >That's up to your security administrator. For example, the >> >head network administrator probably should have sufficient >> >rights to turn off any of the monitors his/her minions >> >have created. >> >> I suspect the capability of DISMAN-EVENT-MIB for Alan to generate >> triggers that reference Randy's objects and events will largely >> be unused in practice. Eliminating this capability could simplify >> the DISMAN-EVENT-MIB. >... That could very well be, but we should wait for implementation feedback on this before modifying behaviour...Sharing events and object entries across multiple owners may be necessary in resource constrained implementations, or to limit the number of events/object entries in order to simplify management. Ram >That could be. We won't know until we get some experience with >the thing. I think part of the rationale was that, in order to >conserve resources, an administration would define common events >(and payloads) to which individual operators would "subscribe" >through their trigger setups. It'll be interesting to see >what, if anything, is done with this. > > ------------------------------------------------------------------------ > Randy Presuhn randy_presuhn@bmc.com http://www.bmc.com/ > Voice: +1 408 546-1006 BMC Software, Inc. 1-3141 2141 N. First Street > Fax: +1 408 965-0359 San Jose, California 95131 USA > ------------------------------------------------------------------------ > Any relationship between my opinions and BMC's should be coincidental. > ------------------------------------------------------------------------ > From owner-disman@dorothy.bmc.com Thu Jan 6 19:42:23 2000 Received: from tangelo.bmc.com (fw-us-hou-2.bmc.com [198.207.223.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25950 for ; Thu, 6 Jan 2000 19:42:21 -0500 (EST) Received: from dorothy.bmc.com (dorothy.bmc.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id SAA10758; Thu, 6 Jan 2000 18:42:13 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id QAA13197 for disman-list; Thu, 6 Jan 2000 16:41:36 -0800 (PST) Received: (from rpresuhn@localhost) by dorothy.peer.com (8.8.6 (PHNE_12836)/8.8.6) id QAA13191 for disman@dorothy.peer.com; Thu, 6 Jan 2000 16:41:33 -0800 (PST) Date: Thu, 6 Jan 2000 16:41:33 -0800 (PST) From: Randy Presuhn Message-Id: <200001070041.QAA13191@dorothy.peer.com> To: disman@dorothy.peer.com Subject: Re: Editorial comments about DISMAN-EVENT-MIB Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list Content-Transfer-Encoding: 7bit Hi - > Message-Id: <4.1.20000106140118.009c04c0@sigma.cisco.com> > Date: Thu, 06 Jan 2000 14:01:37 -0800 > To: Randy Presuhn , disman@dorothy.peer.com > From: Ramanathan Kavasseri > Subject: Re: Editorial comments about DISMAN-EVENT-MIB ... > By "fix it", did you mean add Alan's text (that would be the easiest thing to > do, and would not change the operation of mteTriggerExistenceTest), or > remove the "or to have its value changed," text, which is a significant > operational deviation from the existing text? I'm assuming > that it's the former... ... Your assumption is correct. ------------------------------------------------------------------------ Randy Presuhn randy_presuhn@bmc.com http://www.bmc.com/ Voice: +1 408 546-1006 BMC Software, Inc. 1-3141 2141 N. First Street Fax: +1 408 965-0359 San Jose, California 95131 USA ------------------------------------------------------------------------ Any relationship between my opinions and BMC's should be coincidental. ------------------------------------------------------------------------ From owner-disman@dorothy.bmc.com Thu Jan 6 19:51:23 2000 Received: from tangelo.bmc.com (fw-us-hou-2.bmc.com [198.207.223.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26003 for ; Thu, 6 Jan 2000 19:51:22 -0500 (EST) Received: from dorothy.bmc.com (dorothy.bmc.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id SAA12269; Thu, 6 Jan 2000 18:51:16 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id QAA13438 for disman-list; Thu, 6 Jan 2000 16:50:36 -0800 (PST) Received: (from rpresuhn@localhost) by dorothy.peer.com (8.8.6 (PHNE_12836)/8.8.6) id QAA13432 for disman@dorothy.bmc.com; Thu, 6 Jan 2000 16:50:33 -0800 (PST) Date: Thu, 6 Jan 2000 16:50:33 -0800 (PST) From: Randy Presuhn Message-Id: <200001070050.QAA13432@dorothy.peer.com> To: disman@dorothy.peer.com Subject: Re: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list Content-Transfer-Encoding: 7bit Hi - > Message-Id: <4.1.20000106142354.00988dc0@sigma.cisco.com> > Date: Thu, 06 Jan 2000 14:48:11 -0800 > To: Randy Presuhn , disman@dorothy.peer.com > From: Ramanathan Kavasseri > Subject: Re: > In-Reply-To: <200001061913.LAA02974@dorothy.bmc.com> ... > >> Adding a "MIN-ACCESS read-only" clause in the compliance statement > >> would let the DISMAN-EVENT-MIB _implementation_ specify the > >> mteResourceSampleMinimum and mteResourceSampleInstanceMaximum > >> values, instead of allowing the _user_ to specify them. > > > >I think the current object definitions already cover > >this, where it has words to the effect "A system may use > >the larger values of this minimum to lessen the impact of > >constant sampling." No matter what the user asks for, the > >implementation can impose any lower bound it wants. > > I agree. Since the choice is left to the implementation to > choose a "saner" value, we should leave this as is... so far, so good. > Also you can still implement the object as read-only, and supply > a CAPABILITY MIB indicating that it is a read-only implementation, right? ... Thin ice. The AGENT-CAPABILITIES macro lets the implementor describe what has been implemented. However, that does NOT by itself make the implementation conformant. If the MIB definition says read-write, and does not qualify that statement in the statement of conformance requirements (MODULE-COMPLIANCE MIN-ACCESS), and the implementation is incapable of handling a SetRequest for an instance of that object, then that implementation does not conform to that MIB specification. It may still be a useful implementation, but it's not conformant, no matter what the AGENT-CAPABILITIES macro says. ------------------------------------------------------------------------ Randy Presuhn randy_presuhn@bmc.com http://www.bmc.com/ Voice: +1 408 546-1006 BMC Software, Inc. 1-3141 2141 N. First Street Fax: +1 408 965-0359 San Jose, California 95131 USA ------------------------------------------------------------------------ Any relationship between my opinions and BMC's should be coincidental. ------------------------------------------------------------------------ From owner-disman@dorothy.bmc.com Thu Jan 6 20:05:22 2000 Received: from tangelo.bmc.com (fw-us-hou-1.bmc.com [198.207.223.250]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26168 for ; Thu, 6 Jan 2000 20:05:21 -0500 (EST) Received: from dorothy.peer.com (dorothy.bmc.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id TAA14148; Thu, 6 Jan 2000 19:05:14 -0600 (CST) Received: (from root@localhost) by dorothy.peer.com (8.8.6 (PHNE_12836)/8.8.6) id RAA13645 for disman-list; Thu, 6 Jan 2000 17:04:33 -0800 (PST) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id RAA13617 for disman@dorothy.bmc.com; Thu, 6 Jan 2000 17:04:26 -0800 (PST) Date: Thu, 6 Jan 2000 17:04:26 -0800 (PST) From: Randy Presuhn Message-Id: <200001070104.RAA13617@dorothy.bmc.com> To: disman@dorothy.peer.com Subject: Re: Editorial comments about DISMAN-EVENT-MIB Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list Content-Transfer-Encoding: 7bit Hi - > Message-Id: <4.1.20000106133934.00a05ea0@sigma.cisco.com> > Date: Thu, 06 Jan 2000 13:51:46 -0800 > To: Alan Luchuk , rpresuhn@dorothy.peer.com > From: Ramanathan Kavasseri > Subject: Re: Editorial comments about DISMAN-EVENT-MIB > Cc: disman@dorothy.peer.com, luchuk@snmp.com > In-Reply-To: <200001051956.OAA06214@seymour47.SNMP.COM> ... > >The mteTriggerExistenceTest object is defined (on page 24) as follows: > > > > mteTriggerExistenceTest OBJECT-TYPE > > SYNTAX BITS { present(0), absent(1), changed(2) } > > MAX-ACCESS read-write > > STATUS current > > DESCRIPTION > > "The type of existence test to perform. The trigger fires > > when the object at mteTriggerValueID is seen to go from > > present to absent, from absent to present, or to have it's > > value changed, depending on which tests are selected. > > Hmm, the above "have it's value changed" text seems to be in error. > I'd like to see it removed, but it presents a significant operational > change...Comments from the chair? It looks like there was an inconsistancy. It appears that most of the text took the approach that state changes could be considered for existence tests. This may be a resaonable thing to do, since there are MIBs in which setting an attribute to "deleted" does not necessarily result in the disappearance of the row in question. > I don't think an "existence check" should have anything to do with > testing values... ... If this weren't SNMP, I'd be inclined to agree. :-) But hey, we do creation and deletion as side-effects of SetRequest, so caution is in order. Given that the weight of the text appears to support including tests for value changes, and given that some MIB objects don't immediately dissappear when "deleted", let's leave the "value changed" text in there. (By the way, the possessive pronoun is spelled "its", not "it's". It's the same pattern as for "hers", "yours", and "ours" but not "mine". :-) ------------------------------------------------------------------------ Randy Presuhn randy_presuhn@bmc.com http://www.bmc.com/ Voice: +1 408 546-1006 BMC Software, Inc. 1-3141 2141 N. First Street Fax: +1 408 965-0359 San Jose, California 95131 USA ------------------------------------------------------------------------ Any relationship between my opinions and BMC's should be coincidental. ------------------------------------------------------------------------ From owner-disman@dorothy.bmc.com Fri Jan 7 13:56:10 2000 Received: from tangelo.bmc.com (fw-us-hou-2.bmc.com [198.207.223.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25113 for ; Fri, 7 Jan 2000 13:56:10 -0500 (EST) Received: from dorothy.bmc.com (dorothy.bmc.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id MAA08368; Fri, 7 Jan 2000 12:55:49 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id KAA19519 for disman-list; Fri, 7 Jan 2000 10:51:24 -0800 (PST) Received: from tangelo.bmc.com (root@tangelo.bmc.com [172.17.7.166]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id KAA19509 for ; Fri, 7 Jan 2000 10:51:19 -0800 (PST) Received: from fw-us-hou1.bmc.com (fw-us-hou1.bmc.com [172.17.0.250]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with SMTP id MAA07421 for ; Fri, 7 Jan 2000 12:51:43 -0600 (CST) Received: from ramk-pc.cisco.com (dhcp-171-69-66-201.cisco.com [171.69.66.201]) by sigma.cisco.com (8.8.8-Cisco List Logging/8.8.8) with SMTP id KAA07132; Fri, 7 Jan 2000 10:51:40 -0800 (PST) Message-Id: <4.1.20000106182155.009d5650@sigma.cisco.com> X-Sender: ramk@sigma.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Thu, 06 Jan 2000 18:28:29 -0800 To: Randy Presuhn , disman@dorothy.peer.com From: Ramanathan Kavasseri Subject: Re: Editorial comments about DISMAN-EVENT-MIB In-Reply-To: <200001070104.RAA13617@dorothy.bmc.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list At 05:04 PM 1/6/00 -0800, Randy Presuhn wrote: > >Hi - > >> Message-Id: <4.1.20000106133934.00a05ea0@sigma.cisco.com> >> Date: Thu, 06 Jan 2000 13:51:46 -0800 >> To: Alan Luchuk , rpresuhn@dorothy.peer.com >> From: Ramanathan Kavasseri >> Subject: Re: Editorial comments about DISMAN-EVENT-MIB >> Cc: disman@dorothy.peer.com, luchuk@snmp.com >> In-Reply-To: <200001051956.OAA06214@seymour47.SNMP.COM> >... >> >The mteTriggerExistenceTest object is defined (on page 24) as follows: >> > >> > mteTriggerExistenceTest OBJECT-TYPE >> > SYNTAX BITS { present(0), absent(1), changed(2) } >> > MAX-ACCESS read-write >> > STATUS current >> > DESCRIPTION >> > "The type of existence test to perform. The trigger fires >> > when the object at mteTriggerValueID is seen to go from >> > present to absent, from absent to present, or to have it's >> > value changed, depending on which tests are selected. >> >> Hmm, the above "have it's value changed" text seems to be in error. >> I'd like to see it removed, but it presents a significant operational >> change...Comments from the chair? > >It looks like there was an inconsistancy. It appears that >most of the text took the approach that state changes could be >considered for existence tests. This may be a resaonable thing >to do, since there are MIBs in which setting an attribute to >"deleted" does not necessarily result in the disappearance >of the row in question. > >> I don't think an "existence check" should have anything to do with >> testing values... >... > >If this weren't SNMP, I'd be inclined to agree. :-) >But hey, we do creation and deletion as side-effects >of SetRequest, so caution is in order. I feel like there are other triggers that we can define to watch for the explicit value of an object instance, and "existence" should not be the place for it. But I see your point about attributes being "marked" as deleted, but not being removed. I can live with the existing text, and if it becomes an issue, I'll raise it during implementation feedback... >Given that the weight of the text appears to support >including tests for value changes, and given that some >MIB objects don't immediately dissappear when "deleted", >let's leave the "value changed" text in there. ok. >(By the way, the possessive pronoun is spelled "its", not >"it's". It's the same pattern as for "hers", "yours", and >"ours" but not "mine". :-) Yep...Typo'd. :-) Ram > ------------------------------------------------------------------------ > Randy Presuhn randy_presuhn@bmc.com http://www.bmc.com/ > Voice: +1 408 546-1006 BMC Software, Inc. 1-3141 2141 N. First Street > Fax: +1 408 965-0359 San Jose, California 95131 USA > ------------------------------------------------------------------------ > Any relationship between my opinions and BMC's should be coincidental. > ------------------------------------------------------------------------ > From owner-disman@dorothy.bmc.com Fri Jan 7 15:55:36 2000 Received: from tangelo.bmc.com (fw-us-hou-2.bmc.com [198.207.223.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27112 for ; Fri, 7 Jan 2000 15:55:35 -0500 (EST) Received: from dorothy.bmc.com (dorothy.bmc.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id OAA12756; Fri, 7 Jan 2000 14:54:58 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id MAA22160 for disman-list; Fri, 7 Jan 2000 12:51:02 -0800 (PST) Received: from tangelo.bmc.com (root@tangelo.bmc.com [172.17.7.166]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id MAA22152; Fri, 7 Jan 2000 12:50:57 -0800 (PST) Received: from fw-us-hou1.bmc.com (fw-us-hou1.bmc.com [172.17.0.250]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with SMTP id OAA11821; Fri, 7 Jan 2000 14:51:20 -0600 (CST) Received: from ramk-pc.cisco.com (dhcp-171-69-66-201.cisco.com [171.69.66.201]) by sigma.cisco.com (8.8.8-Cisco List Logging/8.8.8) with SMTP id MAA25402; Fri, 7 Jan 2000 12:51:14 -0800 (PST) Message-Id: <4.1.20000107124421.009de8e0@sigma.cisco.com> X-Sender: ramk@sigma.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Fri, 07 Jan 2000 12:51:10 -0800 To: Randy Presuhn , disman@dorothy.peer.com From: Ramanathan Kavasseri Subject: Re: List of edits applied to the Event MIB In-Reply-To: <199912220119.RAA04848@sigma.cisco.com> References: <199912211921.LAA18481@dorothy.bmc.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list I'm down to the last issue for the Event MIB (*gasp*), issue Event-09. I'd sent this mail out on the 21st of December, but haven't seen any comments on the DESCRIPTIONS for the two objects being added. So I'll wait one more day, and if I don't hear anything, I'll assume the objects are ok as is, and will wind up the edits (for this stage) on the event MIB... (I've snipped out the parts that were agreed upon from the original mail). At 05:06 PM 12/21/99 -0800, Ramanathan Kavasseri wrote: > >At 11:21 AM 12/21/99 -0800, Randy Presuhn wrote: >> >>> 9. For Disman issue Event-09: >>> >>> The following is an extract from the disman issue Event-09 discussion: >>> >>> > > Page 26: >>> > > >>> > > This is a general coment about the Trigger Threshold Table. Rising and >>> > > Falling and combination objects are specified. What is absent is the >>> > > rate of change which is often in values (not talking about delta >>> > > discontinuity here). For example an object such as >>> > > mteTriggerThresholdRisingDelat could be added (would require mod of >>> > > mteTriggerThresholdStartup) which rahter than an absolute value would be >>> > > measured at each interval so that if the change exceeded the value the >>> > > trigger threshold would be thought to have been exceeded. If this was >>> > > already discussed and dismissed, OK but I think from an operational >>> > > perspective this is of value. >>> >>> > Proposed resolution: add the suggested objects. >>> > >>> > Objections? Alternatives? >>> >>> You would also need mteTriggerRisingDeltaInterval and >mteTriggerFallingDeltaInterval, >>> since you need both the range and the time to calculate a >rate-of-climb/fall. >>> Comments? >> >>The additional *Interval objects would not be needed, since >>the MIB already has a notion of sampling frequencies. > >Heh...Now I'm red-faced... >:-) > >I added the two objects "mteTriggerThresholdDeltaRising" and >"mteTriggerDeltaFalling", and they're pasted below...The >DESCRIPTION needs a little work, so I'll let folks comment away. > >I was going to modify mteTriggerThresholdStartup, and then >realized that since we're talking about "deltaRising" and "deltaFalling", >we need two samples, and hence we shouldn't modify >mteTriggerThresholdStartup...Comments? > >mteTriggerThresholdDeltaRising OBJECT-TYPE > SYNTAX Integer32 > MAX-ACCESS read-write > STATUS current > DESCRIPTION > "A threshold value to check against if mteTriggerType is > 'threshold'. > > When the delta value (difference) between the current sampled > value (value(n)) and the previous sampled value (value(n-1)) > is greater than or equal to this threshold, > and the delta value calculated at the last sampling interval > (i.e. value(n-1) - value(n-2)) was less than this threshold, > one mteTriggerThresholdRisingEvent is triggered. That event is > also triggered if the first delta value calculated after this > entry becomes active, i.e. value(2) - value(1), where value(1) > is the first sample taken of that instance, is greater than or > equal to this threshold. > > After a rising event is generated, another such event is not > triggered until the delta value falls below this threshold and > reaches mteTriggerThresholdDeltaFalling." > DEFVAL { 0 } > ::= { mteTriggerThresholdEntry 4 } > >mteTriggerThresholdDeltaFalling OBJECT-TYPE > SYNTAX Integer32 > MAX-ACCESS read-write > STATUS current > DESCRIPTION > "A threshold value to check against if mteTriggerType is > 'threshold'. > > When the delta value (difference) between the current sampled > value (value(n)) and the previous sampled value (value(n-1)) > is less than or equal to this threshold, > and the delta value calculated at the last sampling interval > (i.e. value(n-1) - value(n-2)) was greater than this threshold, > one mteTriggerThresholdFallingEvent is triggered. That event is > also triggered if the first delta value calculated after this > entry becomes active, i.e. value(2) - value(1), where value(1) > is the first sample taken of that instance, is less than or > equal to this threshold. > > After a falling event is generated, another such event is not > triggered until the delta value rises above this threshold and > reaches mteTriggerThresholdDeltaRising." > DEFVAL { 0 } > ::= { mteTriggerThresholdEntry 5 } > From owner-disman@dorothy.bmc.com Sun Jan 9 12:33:06 2000 Received: from tangelo.bmc.com (fw-us-hou-2.bmc.com [198.207.223.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09364 for ; Sun, 9 Jan 2000 12:33:06 -0500 (EST) Received: from dorothy.bmc.com (dorothy.bmc.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id LAA27150; Sun, 9 Jan 2000 11:32:49 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id JAA09512 for disman-list; Sun, 9 Jan 2000 09:27:39 -0800 (PST) Received: from tangelo.bmc.com (root@tangelo.bmc.com [172.17.7.166]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id JAA09503; Sun, 9 Jan 2000 09:27:30 -0800 (PST) Received: from fw-us-hou1.bmc.com (fw-us-hou1.bmc.com [172.17.0.250]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with SMTP id LAA26757; Sun, 9 Jan 2000 11:27:54 -0600 (CST) Received: from mediaone.net (h0050e460d16d.ne.mediaone.net [24.128.60.221]) by chmls05.mediaone.net (8.8.7/8.8.7) with ESMTP id MAA20832; Sun, 9 Jan 2000 12:27:38 -0500 (EST) Message-ID: <3878C567.DCEA5A49@mediaone.net> Date: Sun, 09 Jan 2000 12:29:11 -0500 From: Jon Saperia X-Mailer: Mozilla 4.7 (Macintosh; U; PPC) X-Accept-Language: en MIME-Version: 1.0 To: Ramanathan Kavasseri CC: Randy Presuhn , disman@dorothy.peer.com Subject: Re: List of edits applied to the Event MIB References: <199912211921.LAA18481@dorothy.bmc.com> <4.1.20000107124421.009de8e0@sigma.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list Content-Transfer-Encoding: 7bit Ram, Yes, these are the types of objects with the semantics I was thinking about when I made the suggestion for the additions. After we get some additional implementation experience we may find that mods or additions are necessary. For now I am happy. /jon From owner-disman@dorothy.bmc.com Mon Jan 10 04:01:49 2000 Received: from tangelo.bmc.com (fw-us-hou-1.bmc.com [198.207.223.250]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28041 for ; Mon, 10 Jan 2000 04:01:48 -0500 (EST) Received: from dorothy.bmc.com (dorothy.bmc.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id DAA09401; Mon, 10 Jan 2000 03:01:20 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id AAA24024 for disman-list; Mon, 10 Jan 2000 00:59:43 -0800 (PST) Received: from tangelo.bmc.com (root@tangelo.bmc.com [172.17.7.166]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id AAA24018; Mon, 10 Jan 2000 00:59:39 -0800 (PST) Received: from fw-us-hou1.bmc.com (fw-us-hou1.bmc.com [172.17.0.250]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with SMTP id DAA09200; Mon, 10 Jan 2000 03:00:02 -0600 (CST) Received: from ramk-95.cisco.com (ramk-dsl4.cisco.com [10.19.11.157]) by sigma.cisco.com (8.8.8-Cisco List Logging/8.8.8) with SMTP id AAA23666; Mon, 10 Jan 2000 00:59:28 -0800 (PST) Message-Id: <4.1.20000110004744.0099d960@sigma.cisco.com> Message-Id: <4.1.20000110004744.0099d960@sigma.cisco.com> X-Sender: ramk@sigma.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Mon, 10 Jan 2000 00:49:31 -0800 To: Jon Saperia From: "Ramanathan R. Kavasseri" Subject: Re: List of edits applied to the Event MIB Cc: Randy Presuhn , disman@dorothy.peer.com In-Reply-To: <3878C567.DCEA5A49@mediaone.net> References: <199912211921.LAA18481@dorothy.bmc.com> <4.1.20000107124421.009de8e0@sigma.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list At 12:29 PM 1/9/00 -0500, Jon Saperia wrote: >Ram, > >Yes, these are the types of objects with the semantics I was thinking >about when I made the suggestion for the additions. After we get some >additional implementation experience we may find that mods or additions >are necessary. For now I am happy. > >/jon > Jon, thanks for the feedback. I'll have the latest EVENT-MIB draft posted today... Ram From owner-disman@dorothy.bmc.com Mon Jan 10 16:40:45 2000 Received: from tangelo.bmc.com (fw-us-hou-2.bmc.com [198.207.223.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13464 for ; Mon, 10 Jan 2000 16:40:45 -0500 (EST) Received: from dorothy.bmc.com (dorothy.bmc.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id PAA26306; Mon, 10 Jan 2000 15:40:02 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id NAA18655 for disman-list; Mon, 10 Jan 2000 13:33:48 -0800 (PST) Received: (from rpresuhn@localhost) by dorothy.peer.com (8.8.6 (PHNE_12836)/8.8.6) id NAA18649; Mon, 10 Jan 2000 13:33:44 -0800 (PST) Date: Mon, 10 Jan 2000 13:33:44 -0800 (PST) From: Randy Presuhn Message-Id: <200001102133.NAA18649@dorothy.peer.com> To: disman@dorothy.peer.com Subject: Fwd: RFC 2591, implementation question Cc: hongal@yagosys.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list Content-Transfer-Encoding: 7bit Hi - I'm forwarding a non-subscriber post to the disman list. For subscription information, please see http://www.ietf.org/html.charters/disman-charter.html ------------------------------------------------------------------------ Randy Presuhn randy_presuhn@bmc.com http://www.bmc.com/ Voice: +1 408 546-1006 BMC Software, Inc. 1-3141 2141 N. First Street Fax: +1 408 965-0359 San Jose, California 95131 USA ------------------------------------------------------------------------ Any relationship between my opinions and BMC's should be coincidental. ------------------------------------------------------------------------ > Received: from tangelo.bmc.com (root@tangelo.bmc.com [172.17.7.166]) > by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id MAA17792 > for ; Mon, 10 Jan 2000 12:58:38 -0800 (PST) > Received: from fw-us-hou1.bmc.com (fw-us-hou1.bmc.com [172.17.0.250]) > by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with SMTP id OAA12762 > for ; Mon, 10 Jan 2000 14:59:01 -0600 (CST) > Received: from yagosys.com by yagosys.com (8.8.8+Sun/SMI-SVR4-Yago) > id MAA20045; Mon, 10 Jan 2000 12:58:43 -0800 (PST) > Message-ID: <387A2C8F.E5870A47@yagosys.com> > Date: Mon, 10 Jan 2000 13:01:35 -0600 > From: T F Hongal > X-Mailer: Mozilla 4.61 [en] (WinNT; I) > X-Accept-Language: en > MIME-Version: 1.0 > To: "disman@dorothy.peer.com" > Subject: RFC 2591, implementation question > Content-Type: multipart/mixed; > boundary="------------001E578BF99F483D733F3691" > > This is a multi-part message in MIME format. > --------------001E578BF99F483D733F3691 > Content-Type: text/plain; charset=us-ascii > Content-Transfer-Encoding: 7bit > > hi all, > > Is there any upper limit on schedInterval ?. > > thanks > hongal > > --------------001E578BF99F483D733F3691 > Content-Type: text/x-vcard; charset=us-ascii; > name="hongal.vcf" > Content-Transfer-Encoding: 7bit > Content-Description: Card for T F Hongal > Content-Disposition: attachment; > filename="hongal.vcf" > > begin:vcard > n:Hongal;Thippanna > tel;cell:408-221-3212 > tel;fax:408-878-6560 > tel;home:408-248-5855 > tel;work:408-878-6562 > x-mozilla-html:TRUE > org:Cabletron Systems, Inc.;NMS Engg > adr:;;3615 Green Lee Drive Apt. No. 21;San Jose;ca;95117;US > version:2.1 > email;internet:hongal@yagosys.com > title:Member of Technical Staff > x-mozilla-cpt:;25856 > fn:Thippanna Hongal > end:vcard > > --------------001E578BF99F483D733F3691-- > > From owner-disman@dorothy.bmc.com Tue Jan 11 06:03:49 2000 Received: from tangelo.bmc.com (fw-us-hou-2.bmc.com [198.207.223.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03332 for ; Tue, 11 Jan 2000 06:03:49 -0500 (EST) Received: from dorothy.bmc.com (dorothy.bmc.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id FAA28010; Tue, 11 Jan 2000 05:03:25 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id DAA08767 for disman-list; Tue, 11 Jan 2000 03:01:46 -0800 (PST) Received: from tangelo.bmc.com (root@tangelo.bmc.com [172.17.7.166]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id DAA08762 for ; Tue, 11 Jan 2000 03:01:41 -0800 (PST) Received: from fw-us-hou1.bmc.com (fw-us-hou1.bmc.com [172.17.0.250]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with SMTP id FAA27828 for ; Tue, 11 Jan 2000 05:02:04 -0600 (CST) Received: from henkell.ibr.cs.tu-bs.de (schoenw@henkell [134.169.34.191]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) with ESMTP id MAA00495; Tue, 11 Jan 2000 12:02:01 +0100 (MET) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id MAA10149; Tue, 11 Jan 2000 12:02:00 +0100 Date: Tue, 11 Jan 2000 12:02:00 +0100 Message-Id: <200001111102.MAA10149@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: hongal@yagosys.com CC: disman@dorothy.peer.com In-reply-to: <200001102133.NAA18649@dorothy.peer.com> (message from Randy Presuhn on Mon, 10 Jan 2000 13:33:44 -0800 (PST)) Subject: Re: Fwd: RFC 2591, implementation question References: <200001102133.NAA18649@dorothy.peer.com> Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list >>>>> T F Hongal writes: >> Is there any upper limit on schedInterval ?. schedInterval is of type Unsigned32 and has a unit of seconds. Hence, the upper limit is 4294967295 seconds (~ 136 years). (Only few humans will see such a scheduling entry fire twice. ;-) /js -- Juergen Schoenwaelder Technical University Braunschweig Dept. Operating Systems & Computer Networks Phone: +49 531 391 3289 Bueltenweg 74/75, 38106 Braunschweig, Germany Fax: +49 531 391 5936 From owner-disman@dorothy.bmc.com Tue Jan 11 14:55:11 2000 Received: from tangelo.bmc.com (fw-us-hou-2.bmc.com [198.207.223.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19747 for ; Tue, 11 Jan 2000 14:55:10 -0500 (EST) Received: from dorothy.peer.com (dorothy.bmc.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id NAA15616; Tue, 11 Jan 2000 13:54:43 -0600 (CST) Received: (from root@localhost) by dorothy.peer.com (8.8.6 (PHNE_12836)/8.8.6) id LAA07791 for disman-list; Tue, 11 Jan 2000 11:52:06 -0800 (PST) Received: from tangelo.bmc.com (root@tangelo.bmc.com [172.17.7.166]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id LAA07720 for ; Tue, 11 Jan 2000 11:51:57 -0800 (PST) Received: from fw-us-hou1.bmc.com (fw-us-hou1.bmc.com [172.17.0.250]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with SMTP id NAA14930 for ; Tue, 11 Jan 2000 13:52:20 -0600 (CST) Received: from ramk-95.cisco.com (ramk-dsl4.cisco.com [10.19.11.157]) by sigma.cisco.com (8.8.8-Cisco List Logging/8.8.8) with SMTP id LAA13629; Tue, 11 Jan 2000 11:52:17 -0800 (PST) Message-Id: <4.1.20000111102500.00996d80@sigma.cisco.com> X-Sender: ramk@sigma.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Tue, 11 Jan 2000 11:54:52 -0800 To: Randy Presuhn , disman@dorothy.peer.com From: "Ramanathan R. Kavasseri" Subject: Re: In-Reply-To: <200001052337.PAA15864@dorothy.peer.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list Can't remember responding to this email - there were two issues that required edits to the event mib - just posting that the changes have been made... At 03:37 PM 1/5/00 -0800, Randy Presuhn wrote: > >Hi - > >> From: Alan Luchuk >> Date: Wed, 5 Jan 2000 13:14:42 -0500 (EST) >> Message-Id: <200001051814.NAA06065@seymour47.SNMP.COM> >> To: disman@dorothy.peer.com >> Subject: >> Cc: luchuk@snmp.com >> List-Id: IETF disman Working Group mailing list >... >> The mteTriggerExistenceTest is defined as follows: >> >> mteTriggerExistenceTest OBJECT-TYPE >> SYNTAX BITS { present(0), absent(1), changed(2) } >> MAX-ACCESS read-write >> STATUS current >> DESCRIPTION >> "The type of existence test to perform. The trigger fires >> when the object at mteTriggerValueID is seen to go from >> present to absent, from absent to present, or to have it's >> value changed, depending on which tests are selected. >> >> Once the trigger has fired for either presence or absence it >> will not fire again for that state until the object has been >> to the other state." >> DEFVAL { { present, absent } } >> ::= { mteTriggerExistenceEntry 1 } >> >> The exact function of each bit is somewhat ambiguous. For example, >> assuming the description ordering matches the bit ordering, here >> are the bit functions: >> >> present(0) - the mteTriggerValueID object goes from present to absent >> absent(1) - the mteTriggerValueID object goes from absent to present >> changed(2) - the mteTriggerValueID object value changes >> >> But, based upon the final state of the mteTriggerValueID object, the >> bit functions might be: >> >> present(0) - the mteTriggerValueID object goes from absent to present >> absent(1) - the mteTriggerValueID object goes from present to absent >> changed(2) - the mteTriggerValueID object value changes >> >> Other orderings are possible. Changing the DESCRIPTION text to spell >> this out would clarify this issue for me (and probably for other >> implementors.) > >I believe the second interpretation is the one intended. >Ram, make it clear. Done. >> >> I believe the 'changed(2)' bit value should be deleted from the >> mteTriggerExistenceStartup MIB object. Including this bit value >> suggests (to me, at least) the DISMAN-EVENT-MIB knows the value >> of the monitored object before mteTriggerExistenceTest is configured. >> Am I missing something here? > >I think you're right that changed(2) doesn't make sense here. > Agreed. I've removed "changed" from mteTriggerExistenceStartup. Thanks, Ram From owner-disman@dorothy.bmc.com Tue Jan 11 14:55:14 2000 Received: from tangelo.bmc.com (fw-us-hou-2.bmc.com [198.207.223.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19744 for ; Tue, 11 Jan 2000 14:55:10 -0500 (EST) Received: from dorothy.bmc.com (dorothy.bmc.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id NAA15637; Tue, 11 Jan 2000 13:54:46 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id LAA07450 for disman-list; Tue, 11 Jan 2000 11:51:06 -0800 (PST) Received: from tangelo.bmc.com (root@tangelo.bmc.com [172.17.7.166]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id LAA07204 for ; Tue, 11 Jan 2000 11:50:17 -0800 (PST) Received: from fw-us-hou1.bmc.com (fw-us-hou1.bmc.com [172.17.0.250]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with SMTP id NAA14307 for ; Tue, 11 Jan 2000 13:50:34 -0600 (CST) Received: (ramk@localhost) by itech-view2.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) id LAA18233; Tue, 11 Jan 2000 11:49:56 -0800 (PST) From: Ram Kavasseri Message-Id: <200001111949.LAA18233@itech-view2.cisco.com> Subject: draft-ietf-disman-event-mib-10.txt To: internet-drafts@ietf.org Date: Tue, 11 Jan 2000 11:49:56 -0800 (PST) Cc: disman@dorothy.peer.com X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list Content-Transfer-Encoding: 7bit Please post the attached document "draft-ietf-disman-event-mib-10.txt" as an internet draft. Than you, Ram Kavasseri Internet Draft Distributed Management Event MIB 6 January 2000 Event MIB 6 January 2000 draft-ietf-disman-event-mib-10.txt Bob Stewart Cisco Systems, Inc. Ramanathan R. Kavasseri Cisco Systems, Inc. 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 Distribution of this document is unlimited. Please send comments to the Distributed Management Working Group, . Copyright Notice Copyright (C) The Internet Society (2000). All Rights Reserved. Expires 6 July 2000 [Page 1] Internet Draft Distributed Management Event MIB 6 January 2000 1. Abstract This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects that can be used to manage and monitor MIB objects and take action through events. The Event MIB provides the ability to monitor MIB objects on the local system or on a remote system and take simple action when a trigger condition is met. 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 RFC 2119. 2. The SNMP Management Framework The SNMP Management Framework presently consists of five major components: o An overall architecture, described in RFC 2571 [RFC2571]. o Mechanisms for describing and naming objects and events for the purpose of management. The first version of this Structure of Management Information (SMI) is called SMIv1 and described in STD 16, RFC 1155 [RFC1155], STD 16, RFC 1212 [RFC1212] and RFC 1215 [RFC1215]. The second version, called SMIv2, is described in STD 58, RFC 2578 [RFC2578], RFC 2579 [RFC2579] and RFC 2580 [RFC2580]. o Message protocols for transferring management information. The first version of the SNMP message protocol is called SNMPv1 and described in STD 15, 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]. o Protocol operations for accessing management information. The first set of protocol operations and associated PDU formats is described in STD 15, RFC 1157 [RFC1157]. A second set of protocol operations and associated PDU formats is described in Expires 6 July 2000 [Page 2] Internet Draft Distributed Management Event MIB 6 January 2000 RFC 1905 [RFC1905]. o 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 MIB. It may not be possible to meaningfully monitor Counter64 objects using an SMIv1 version of the MIB. Expires 6 July 2000 [Page 3] Internet Draft Distributed Management Event MIB 6 January 2000 3. Overview With network sizes well beyond the ability of people to manage them directly, automated, distributed management is vital. An important aspect of such management is the ability of a system to monitor itself or for some other system to monitor it. The Event MIB provides the ability to monitor MIB objects on the local system or on a remote system and take simple action when a trigger condition is met. The MIB is intended to suit either a relatively powerful manager or mid- level manager, as well as a somewhat more limited self-managing system. 4. Relationship to Other MIBs The Event MIB is based on extensive experience with the RMON MIB [RFC1757] and provides a superset of the capabilities of the RMON alarm and event groups. Conceptually, the key extension is the ability to allow alarms to be generated for MIB objects that are on another network element. The Event MIB calls "triggers" what the RMON MIB called "alarms," but the concepts are the same. Event MIB triggers maintain the RMON handling of thresholds and add the concept of booleans. Event MIB events maintain the RMON concept of sending an SNMP notification in response to a trigger and add the concept of setting a MIB object. The Event MIB is the successor and update to SNMPv2's Manager-to-Manager MIB [RFC1451] which was declared Historic pending this work. The Event MIB depends on the services of the SNMPv3 Management Target and Notification MIBs [RFC2573]. The Event MIB is nicely complemented by the Distributed Management Expression MIB [RFCExpressionMIB], which is the expected source of boolean objects to monitor. Note that there is considerable overlap between the wildcard and delta sample capabilities of the Event and Expression MIBs. A carefully-planned implementation might well use common code to provide the overlapping functions. 5. MIB Sections The MIB has four sections: triggers, objects, events, and notifications. Triggers define the conditions that lead to events. Events may cause Expires 6 July 2000 [Page 4] Internet Draft Distributed Management Event MIB 6 January 2000 notifications. The trigger table lists what objects are to be monitored and how and relates each trigger to an event. It has supplementary, companion tables for additional objects that depend on the type of test done for the trigger. The objects table lists objects that can be added to notifications based on the trigger, the trigger test type, or the event that resulted in the notification. The event table defines what happens when an event is triggered: sending a notification, setting a MIB object or both. It has supplementary, companion tables for additional objects that depend on the action taken. The notification section defines a set of generic notifications to go with the events and for Event MIB error handling, and it defines a set of objects to put in those notifications. Expires 6 July 2000 [Page 5] Internet Draft Distributed Management Event MIB 6 January 2000 The following diagram describes the relationships between the tables in the Event MIB. +--------------------------------+ | mteTriggerEntry | subclassed by: | { mteOwner, |---+ | IMPLIED mteTriggerName } | +-- mteTriggerDeltaEntry | | | | | +-- mteTriggerExistenceEntry | | | | | +-- mteTriggerBooleanEntry | | | | | +-- mteTriggerThresholdEntry | | | | | | | | | mteTrigger*Event ----------------------------->+ | | | | mteTriggerObjects --------------->+ | | | | | +--------------------------------+ | | | | V | +<--------------------------------------------+ | | | V | +--------------------------------+ | | | | | mteObjectsEntry | | | { mteOwner, | | | mteObjectsName, | | | mteObjectsIndex } | | | | | +--------------------------------+ | | V +<---------------------------------------------------------+ | V +---------------------------------+ | | | mteEventEntry | | { mteOwner, | Expires 6 July 2000 [Page 6] Internet Draft Distributed Management Event MIB 6 January 2000 | IMPLIED mteEventName } | | | | mteEventAction - - - - - - > + (condition) | | | +---------------------------------+ | | + < - - - + < - - - - - - - - - - - - - - + | | | | | | | V | +---------------------------------+ | | | | | mteEventNotificationEntry | | | { mteOwner, | | | IMPLIED mteEventName } | | | | | +---------------------------------+ | | | V +---------------------------------+ | | | mteEventSetEntry | | { mteOwner, | | IMPLIED mteEventName } | | | +---------------------------------+ 6. Operation The Event MIB is instrumentation for a distributed management application that monitors MIB objects. In its simplest form this application monitors individual, local MIB objects, just as an RMON probe fulfills the functions implied by RMON's alarm and event operation. Additionally the application can monitor remote objects and wildcarded groups of objects. Remote monitoring uses the tag service of the Management Target MIB [RFC2573] to select and access remote systems as an ordinary SNMP-based management application. Local monitoring may be via a more intimate, local interface which may, for example, bypass SNMP encoding but Expires 6 July 2000 [Page 7] Internet Draft Distributed Management Event MIB 6 January 2000 otherwise is functionally identical to remote SNMP operation, including the application of access control. A self-management only system MAY not implement remote monitoring. Wildcards indicate that the application SHOULD use a GetNext-type operation to find the zero or more instances implied by a truncated object identifier, just like an ordinary SNMP-based management application. Each instance of a wildcard is treated as if it were a separate entry, that is the instances of a wildcarded object are independent of one another. For example, a wild-carded object may trigger an event, and result in the setting of another wildcarded object. The instance that satisfied the trigger function is used to perform the set function. All of this takes place independently of any additional instances that may fill the wildcard. Error handling is by notification. These error notifications SHOULD be enabled only for the diagnosis of problems indicated by error counters. If minimizing the probability of notification loss is a concern they SHOULD be transmitted as Inform PDUs as described in the [SNMP-TARGET- MIB] or directed to a log as described in the Notification Log MIB [rfcNotificationLogMIB]. Note that this does not mean the Notification Log MIB is REQUIRED, since in fact notifications usually are not lost, but that the Notification Log MIB can be helpful with this as well as other MIBs that include notifications. Although like most MIBs this one has no explicit controls for the persistence of the values set in configuring events, a robust, polite implementation would certainly not force its managing applications to reconfigure it whenever it resets. Again, as with most MIBs, it is implementation-specific how a system provides and manages such persistence. To speculate, one could imagine, for example, that persistence depended on the context in which the expression was configured, or perhaps system-specific characteristics of the expression's owner. Or perhaps everything in a MIB such as this one, which is clearly aimed at persistent configuration, is automatically part of a system's other persistent configuration. 7. Security Security of Event MIB entries depends on SNMPv3 access control for the entire MIB or for subsets based on entry owner names. Security of monitored objects for remote access depends on the Expires 6 July 2000 [Page 8] Internet Draft Distributed Management Event MIB 6 January 2000 Management Target MIB [RFC2573]. Security for local access can depend on the Management Target MIB or on recording appropriate security credentials of the creator of an entry and using those to access the local objects. These security credentials are the parameters necessary as inputs to isAccessAllowed from the Architecture for Describing SNMP Management Frameworks. When accessing local objects without using a local target tag, the system MUST (conceptually) use isAccessAllowed to ensure that it does not violate security. To facilitate the provisioning of access control by a security administrator for this MIB itself using the View-Based Access Control Model (VACM) defined in RFC 2275 [RFC2575] for tables in which multiple users may need to independently create or modify entries, the initial index is used as an "owner index". Such an initial index has a syntax of SnmpAdminString, and can thus be trivially mapped to a securityName or groupName as defined in VACM, in accordance with a security policy. All entries in related tables belonging to a particular user will have the same value for this initial index. For a given user's entries in a particular table, the object identifiers for the information in these entries will have the same sub-identifiers (except for the "column" sub- identifier) up to the end of the encoded owner index. To configure VACM to permit access to this portion of the table, one would create vacmViewTreeFamilyTable entries with the value of vacmViewTreeFamilySubtree including the owner index portion, and vacmViewTreeFamilyMask "wildcarding" the column sub-identifier. More elaborate configurations are possible. Expires 6 July 2000 [Page 9] Internet Draft Distributed Management Event MIB 6 January 2000 8. Definitions DISMAN-EVENT-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, Integer32, Unsigned32, NOTIFICATION-TYPE, Counter32, Gauge32, mib-2, zeroDotZero FROM SNMPv2-SMI TEXTUAL-CONVENTION, RowStatus, TruthValue FROM SNMPv2-TC MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP FROM SNMPv2-CONF sysUpTime FROM SNMPv2-MIB SnmpTagValue FROM SNMP-TARGET-MIB SnmpAdminString FROM SNMP-FRAMEWORK-MIB; dismanEventMIB MODULE-IDENTITY LAST-UPDATED "200001060000Z" -- 6 January 2000 ORGANIZATION "IETF Distributed Management Working Group" CONTACT-INFO "Ramanathan Kavasseri Cisco Systems, Inc. 170 West Tasman Drive, San Jose CA 95134-1706. Phone: +1 408 526 4527 Email: ramk@cisco.com" DESCRIPTION "The MIB module for defining event triggers and actions for network management purposes." -- Revision History REVISION "200001060000Z" -- 6 January 2000 DESCRIPTION "This is the initial version of this MIB. Published as RFC xxxxx" ::= { mib-2 xx } - final assignment by IANA at publication time dismanEventMIBObjects OBJECT IDENTIFIER ::= { dismanEventMIB 1 } -- Management Triggered Event (MTE) objects mteResource OBJECT IDENTIFIER ::= { dismanEventMIBObjects 1 } mteTrigger OBJECT IDENTIFIER ::= { dismanEventMIBObjects 2 } mteObjects OBJECT IDENTIFIER ::= { dismanEventMIBObjects 3 } mteEvent OBJECT IDENTIFIER ::= { dismanEventMIBObjects 4 } Expires 6 July 2000 [Page 10] Internet Draft Distributed Management Event MIB 6 January 2000 -- -- Textual Conventions -- FailureReason ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Reasons for failures in an attempt to perform a management request. The first group of errors, numbered less than 0, are related to problems in sending the request. The existence of a particular error code here does not imply that all implementations are capable of sensing that error and returning that code. The second group, numbered greater than 0, are copied directly from SNMP protocol operations and are intended to carry exactly the meanings defined for the protocol as returned in an SNMP response. localResourceLack some local resource such as memory lacking or mteResourceSampleInstanceMaximum exceeded badDestination unrecognized domain name or otherwise invalid destination address destinationUnreachable can't get to destination address noResponse no response to SNMP request badType the data syntax of a retrieved object as not as expected sampleOverrun another sample attempt occurred before the previous one completed" SYNTAX INTEGER { localResourceLack(-1), badDestination(-2), destinationUnreachable(-3), noResponse(-4), badType(-5), sampleOverrun(-6), noError(0), tooBig(1), noSuchName(2), badValue(3), Expires 6 July 2000 [Page 11] Internet Draft Distributed Management Event MIB 6 January 2000 readOnly(4), genErr(5), noAccess(6), wrongType(7), wrongLength(8), wrongEncoding(9), wrongValue(10), noCreation(11), inconsistentValue(12), resourceUnavailable(13), commitFailed(14), undoFailed(15), authorizationError(16), notWritable(17), inconsistentName(18) } -- -- Resource Control Section -- mteResourceSampleMinimum OBJECT-TYPE SYNTAX Integer32 (1..2147483647) UNITS "seconds" MAX-ACCESS read-write STATUS current DESCRIPTION "The minimum mteTriggerFrequency this system will accept. A system may use the larger values of this minimum to lessen the impact of constant sampling. For larger sampling intervals the system samples less often and suffers less overhead. This object provides a way to enforce such lower overhead for all triggers created after it is set. Unless explicitly resource limited, a system's value for this object SHOULD be 1, allowing as small as a 1 second interval for ongoing trigger sampling. Changing this value will not invalidate an existing setting of mteTriggerFrequency." ::= { mteResource 1 } mteResourceSampleInstanceMaximum OBJECT-TYPE SYNTAX Unsigned32 UNITS "instances" MAX-ACCESS read-write Expires 6 July 2000 [Page 12] Internet Draft Distributed Management Event MIB 6 January 2000 STATUS current DESCRIPTION "The maximum number of instance entries this system will support for sampling. These are the entries that maintain state, one for each instance of each sampled object as selected by mteTriggerValueID. Note that wildcarded objects result in multiple instances of this state. A value of 0 indicates no preset limit, that is, the limit is dynamic based on system operation and resources. Unless explicitly resource limited, a system's value for this object SHOULD be 0. Changing this value will not eliminate or inhibit existing sample state but could prevent allocation of additional state information." ::= { mteResource 2 } mteResourceSampleInstances OBJECT-TYPE SYNTAX Gauge32 UNITS "instances" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of currently active instance entries as defined for mteResourceSampleInstanceMaximum." ::= { mteResource 3 } mteResourceSampleInstancesHigh OBJECT-TYPE SYNTAX Gauge32 UNITS "instances" MAX-ACCESS read-only STATUS current DESCRIPTION "The highest value of mteResourceSampleInstances that has occurred since initialization of the management system." ::= { mteResource 4 } mteResourceSampleInstanceLacks OBJECT-TYPE SYNTAX Counter32 UNITS "instances" MAX-ACCESS read-only Expires 6 July 2000 [Page 13] Internet Draft Distributed Management Event MIB 6 January 2000 STATUS current DESCRIPTION "The number of times this system could not take a new sample because that allocation would have exceeded the limit set by mteResourceSampleInstanceMaximum." ::= { mteResource 5 } -- -- Trigger Section -- -- Counters mteTriggerFailures OBJECT-TYPE SYNTAX Counter32 UNITS "failures" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times an attempt to check for a trigger condition has failed. This counts individually for each attempt in a group of targets or each attempt for a wildcarded object." ::= { mteTrigger 1 } -- -- Trigger Table -- mteTriggerTable OBJECT-TYPE SYNTAX SEQUENCE OF MteTriggerEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of management event trigger information." ::= { mteTrigger 2 } mteTriggerEntry OBJECT-TYPE SYNTAX MteTriggerEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information about a single trigger. Applications create and Expires 6 July 2000 [Page 14] Internet Draft Distributed Management Event MIB 6 January 2000 delete entries using mteTriggerEntryStatus." INDEX { mteOwner, IMPLIED mteTriggerName } ::= { mteTriggerTable 1 } MteTriggerEntry ::= SEQUENCE { mteOwner SnmpAdminString, mteTriggerName SnmpAdminString, mteTriggerComment SnmpAdminString, mteTriggerTest BITS, mteTriggerSampleType INTEGER, mteTriggerValueID OBJECT IDENTIFIER, mteTriggerValueIDWildcard TruthValue, mteTriggerTargetTag SnmpTagValue, mteTriggerContextName SnmpAdminString, mteTriggerContextNameWildcard TruthValue, mteTriggerFrequency Unsigned32, mteTriggerObjectsOwner SnmpAdminString, mteTriggerObjects SnmpAdminString, mteTriggerEnabled TruthValue, mteTriggerEntryStatus RowStatus } mteOwner OBJECT-TYPE SYNTAX SnmpAdminString (SIZE(0..32)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The owner of this entry. The exact semantics of this string are subject to the security policy defined by the security administrator." ::= { mteTriggerEntry 1 } mteTriggerName OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (1..32)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "A locally-unique, administratively assigned name for the trigger within the scope of mteOwner." ::= { mteTriggerEntry 2 } mteTriggerComment OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-create STATUS current Expires 6 July 2000 [Page 15] Internet Draft Distributed Management Event MIB 6 January 2000 DESCRIPTION "A description of the trigger's function and use." DEFVAL { ''H } ::= { mteTriggerEntry 3 } mteTriggerTest OBJECT-TYPE SYNTAX BITS { existence(0), boolean(1), threshold(2) } MAX-ACCESS read-create STATUS current DESCRIPTION "The type of trigger test to perform. For 'boolean' and 'threshold' tests, the object at mteTriggerValueID MUST evaluate to an integer, that is, anything that ends up encoded for transmission (that is, in BER, not ASN.1) as an integer. For 'existence', the specific test is as selected by mteTriggerExistenceTest. When an object appears, vanishes or changes value, the trigger fires. If the object's appearance caused the trigger firing, the object MUST vanish before the trigger can be fired again for it, and vice versa. If the trigger fired due to a change in the object's value, it will be fired again on every successive value change for that object. For 'boolean', the specific test is as selected by mteTriggerBooleanTest. If the test result is true the trigger fires. The trigger will not fire again until the value has become false and come back to true. For 'threshold' the test works as described below for mteTriggerThresholdStartup, mteTriggerThresholdRising, and mteTriggerThresholdFalling. Note that combining 'boolean' and 'threshold' tests on the same object may be somewhat redundant." DEFVAL { boolean } ::= { mteTriggerEntry 4 } mteTriggerSampleType OBJECT-TYPE SYNTAX INTEGER { absoluteValue(1), deltaValue(2) } MAX-ACCESS read-create STATUS current DESCRIPTION "The type of sampling to perform. Expires 6 July 2000 [Page 16] Internet Draft Distributed Management Event MIB 6 January 2000 An 'absoluteValue' sample requires only a single sample to be meaningful, and is exactly the value of the object at mteTriggerValueID at the sample time. A 'deltaValue' requires two samples to be meaningful and is thus not available for testing until the second and subsequent samples after the object at mteTriggerValueID is first found to exist. It is the difference between the two samples. For unsigned values it is always positive, based on unsigned arithmetic. For signed values it can be positive or negative. For SNMP counters to be meaningful they MUST be sampled as a 'deltaValue'. For 'deltaValue' mteTriggerDeltaTable contains further parameters. If only 'existence' is set in mteTriggerTest this object has no meaning." DEFVAL { absoluteValue } ::= { mteTriggerEntry 5 } mteTriggerValueID OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-create STATUS current DESCRIPTION "The object identifier of the MIB object to sample to see if the trigger should fire. This may be wildcarded by truncating all or part of the instance portion, in which case the value is obtained as if with a GetNext function, checking multiple values if they exist. If such wildcarding is applied, mteTriggerValueIDWildcard must be 'true' and if not it must be 'false'. Bad object identifiers or a mismatch between truncating the identifier and the value of mteTriggerValueIDWildcard result in operation as one would expect when providing the wrong identifier to a Get or GetNext operation. The Get will fail or get the wrong object. The GetNext will indeed get whatever is next, proceeding until it runs past the initial part of the identifier and perhaps many unintended objects for confusing results. If the value syntax of those objects is not usable, Expires 6 July 2000 [Page 17] Internet Draft Distributed Management Event MIB 6 January 2000 that results in a 'badType' error that terminates the scan. Each instance that fills the wildcard is independent of any additional instances, that is, wildcarded objects operate as if there were a separate table entry for each instance that fills the wildcard without having to actually predict all possible instances ahead of time." DEFVAL { zeroDotZero } ::= { mteTriggerEntry 6 } mteTriggerValueIDWildcard OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "Control for whether mteTriggerValueID is to be treated as fully-specified or wildcarded, with 'true' indicating wildcard." DEFVAL { false } ::= { mteTriggerEntry 7 } mteTriggerTargetTag OBJECT-TYPE SYNTAX SnmpTagValue MAX-ACCESS read-create STATUS current DESCRIPTION "The tag for the target(s) from which to obtain the condition for a trigger check. A length of 0 indicates the local system. In this case, access to the objects indicated by mteTriggerValueID is under the security credentials of the requester that set mteTriggerEntryStatus to 'active'. Those credentials are the input parameters for isAccessAllowed from the Architecture for Describing SNMP Management Frameworks. Otherwise access rights are checked according to the security parameters resulting from the tag." DEFVAL { ''H } ::= { mteTriggerEntry 8 } mteTriggerContextName OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-create STATUS current DESCRIPTION Expires 6 July 2000 [Page 18] Internet Draft Distributed Management Event MIB 6 January 2000 "The management context from which to obtain mteTriggerValueID. This may be wildcarded by leaving characters off the end. For example use 'Repeater' to wildcard to 'Repeater1', 'Repeater2', 'Repeater-999.87b', and so on. To indicate such wildcarding is intended, mteTriggerContextNameWildcard must be 'true'. Each instance that fills the wildcard is independent of any additional instances, that is, wildcarded objects operate as if there were a separate table entry for each instance that fills the wildcard without having to actually predict all possible instances ahead of time. Operation of this feature assumes that the local system has a list of available contexts against which to apply the wildcard. If the objects are being read from the local system, this is clearly the system's own list of contexts. For a remote system a local version of such a list is not defined by any current standard and may not be available, so this function MAY not be supported." DEFVAL { ''H } ::= { mteTriggerEntry 9 } mteTriggerContextNameWildcard OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "Control for whether mteTriggerContextName is to be treated as fully-specified or wildcarded, with 'true' indicating wildcard." DEFVAL { false } ::= { mteTriggerEntry 10 } mteTriggerFrequency OBJECT-TYPE SYNTAX Unsigned32 UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "The number of seconds to wait between trigger samples. To encourage consistency in sampling, the interval is measured from the beginning of one check to the beginning of the next and the timer is restarted immediately when it expires, not when the check completes. Expires 6 July 2000 [Page 19] Internet Draft Distributed Management Event MIB 6 January 2000 If the next sample begins before the previous one completed the system may either attempt to make the check or treat this as an error condition with the error 'sampleOverrun'. A frequency of 0 indicates instantaneous recognition of the condition. This is not possible in many cases, but may be supported in cases where it makes sense and the system is able to do so. This feature allows the MIB to be used in implementations where such interrupt-driven behavior is possible and is not likely to be supported for all MIB objects even then since such sampling generally has to be tightly integrated into low-level code. Systems that can support this SHOULD document those cases where it can be used. In cases where it can not, setting this object to 0 should be disallowed." DEFVAL { 600 } ::= { mteTriggerEntry 11 } mteTriggerObjectsOwner OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (0..32)) MAX-ACCESS read-create STATUS current DESCRIPTION "To go with mteTriggerObjects, the mteOwner of a group of objects from mteObjectsTable." DEFVAL { ''H } ::= { mteTriggerEntry 12 } mteTriggerObjects OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (0..32)) MAX-ACCESS read-create STATUS current DESCRIPTION "The mteObjectsName of a group of objects from mteObjectsTable. These objects are to be added to any Notification resulting from the firing of this trigger. A list of objects may also be added based on the event or on the value of mteTriggerTest. A length of 0 indicates no additional objects." DEFVAL { ''H } ::= { mteTriggerEntry 13 } Expires 6 July 2000 [Page 20] Internet Draft Distributed Management Event MIB 6 January 2000 mteTriggerEnabled OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "A control to allow a trigger to be configured but not used. When the value is 'false' the trigger is not sampled." DEFVAL { false } ::= { mteTriggerEntry 14 } mteTriggerEntryStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The control that allows creation and deletion of entries. Once made active an entry may not be modified except to delete it." ::= { mteTriggerEntry 15 } -- -- Trigger Delta Table -- mteTriggerDeltaTable OBJECT-TYPE SYNTAX SEQUENCE OF MteTriggerDeltaEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of management event trigger information for delta sampling." ::= { mteTrigger 3 } mteTriggerDeltaEntry OBJECT-TYPE SYNTAX MteTriggerDeltaEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information about a single trigger's delta sampling. Entries automatically exist in this this table for each mteTriggerEntry that has mteTriggerSampleType set to 'deltaValue'." INDEX { mteOwner, IMPLIED mteTriggerName } ::= { mteTriggerDeltaTable 1 } Expires 6 July 2000 [Page 21] Internet Draft Distributed Management Event MIB 6 January 2000 MteTriggerDeltaEntry ::= SEQUENCE { mteTriggerDeltaDiscontinuityID OBJECT IDENTIFIER, mteTriggerDeltaDiscontinuityIDWildcard TruthValue, mteTriggerDeltaDiscontinuityIDType INTEGER } sysUpTimeInstance OBJECT IDENTIFIER ::= { sysUpTime 0 } mteTriggerDeltaDiscontinuityID OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-write STATUS current DESCRIPTION "The OBJECT IDENTIFIER (OID) of a TimeTicks, TimeStamp, or DateAndTime object that indicates a discontinuity in the value at mteTriggerValueID. The OID may be for a leaf object (e.g. sysUpTime.0) or may be wildcarded to match mteTriggerValueID. This object supports normal checking for a discontinuity in a counter. Note that if this object does not point to sysUpTime discontinuity checking MUST still check sysUpTime for an overall discontinuity. If the object identified is not accessible the sample attempt is in error, with the error code as from an SNMP request. Bad object identifiers or a mismatch between truncating the identifier and the value of mteDeltaDiscontinuityIDWildcard result in operation as one would expect when providing the wrong identifier to a Get operation. The Get will fail or get the wrong object. If the value syntax of those objects is not usable, that results in an error that terminates the sample with a 'badType' error code." DEFVAL { sysUpTimeInstance } ::= { mteTriggerDeltaEntry 1 } mteTriggerDeltaDiscontinuityIDWildcard OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "Control for whether mteTriggerDeltaDiscontinuityID is to be Expires 6 July 2000 [Page 22] Internet Draft Distributed Management Event MIB 6 January 2000 treated as fully-specified or wildcarded, with 'true' indicating wildcard. Note that the value of this object will be the same as that of the corresponding instance of mteTriggerValueIDWildcard when the corresponding mteTriggerSampleType is 'deltaValue'." DEFVAL { false } ::= { mteTriggerDeltaEntry 2 } mteTriggerDeltaDiscontinuityIDType OBJECT-TYPE SYNTAX INTEGER { timeTicks(1), timeStamp(2), dateAndTime(3) } MAX-ACCESS read-write STATUS current DESCRIPTION "The value 'timeTicks' indicates the mteTriggerDeltaDiscontinuityID of this row is of syntax TimeTicks. The value 'timeStamp' indicates syntax TimeStamp. The value 'dateAndTime' indicates syntax DateAndTime." DEFVAL { timeTicks } ::= { mteTriggerDeltaEntry 3 } -- -- Trigger Existence Table -- mteTriggerExistenceTable OBJECT-TYPE SYNTAX SEQUENCE OF MteTriggerExistenceEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of management event trigger information for existence triggers." ::= { mteTrigger 4 } mteTriggerExistenceEntry OBJECT-TYPE SYNTAX MteTriggerExistenceEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information about a single existence trigger. Entries automatically exist in this this table for each mteTriggerEntry that has 'existence' set in mteTriggerTest." INDEX { mteOwner, IMPLIED mteTriggerName } ::= { mteTriggerExistenceTable 1 } Expires 6 July 2000 [Page 23] Internet Draft Distributed Management Event MIB 6 January 2000 MteTriggerExistenceEntry ::= SEQUENCE { mteTriggerExistenceTest BITS, mteTriggerExistenceStartup BITS, mteTriggerExistenceObjectsOwner SnmpAdminString, mteTriggerExistenceObjects SnmpAdminString, mteTriggerExistenceEventOwner SnmpAdminString, mteTriggerExistenceEvent SnmpAdminString } mteTriggerExistenceTest OBJECT-TYPE SYNTAX BITS { present(0), absent(1), changed(2) } MAX-ACCESS read-write STATUS current DESCRIPTION "The type of existence test to perform. The trigger fires when the object at mteTriggerValueID is seen to go from present to absent, from absent to present, or to have it's value changed, depending on which tests are selected: present(0) - when this test is selected, the trigger fires when the mteTriggerValueID object goes from absent to present. absent(1) - when this test is selected, the trigger fires when the mteTriggerValueID object goes from present to absent. changed(2) - when this test is selected, the trigger fires the mteTriggerValueID object value changes. Once the trigger has fired for either presence or absence it will not fire again for that state until the object has been to the other state. " DEFVAL { { present, absent } } ::= { mteTriggerExistenceEntry 1 } mteTriggerExistenceStartup OBJECT-TYPE SYNTAX BITS { present(0), absent(1) } MAX-ACCESS read-write STATUS current DESCRIPTION "Control for whether an event may be triggered when this entry is first set to 'active' and the test specified by mteTriggerExistenceTest is true. Setting an option causes that trigger to fire when its test is true." DEFVAL { { present, absent } } ::= { mteTriggerExistenceEntry 2 } Expires 6 July 2000 [Page 24] Internet Draft Distributed Management Event MIB 6 January 2000 mteTriggerExistenceObjectsOwner OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (0..32)) MAX-ACCESS read-write STATUS current DESCRIPTION "To go with mteTriggerExistenceObjects, the mteOwner of a group of objects from mteObjectsTable." DEFVAL { ''H } ::= { mteTriggerExistenceEntry 3 } mteTriggerExistenceObjects OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (0..32)) MAX-ACCESS read-write STATUS current DESCRIPTION "The mteObjectsName of a group of objects from mteObjectsTable. These objects are to be added to any Notification resulting from the firing of this trigger for this test. A list of objects may also be added based on the overall trigger, the event or other settings in mteTriggerTest. A length of 0 indicates no additional objects." DEFVAL { ''H } ::= { mteTriggerExistenceEntry 4 } mteTriggerExistenceEventOwner OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (0..32)) MAX-ACCESS read-write STATUS current DESCRIPTION "To go with mteTriggerExistenceEvent, the mteOwner of an event entry from the mteEventTable." DEFVAL { ''H } ::= { mteTriggerExistenceEntry 5 } mteTriggerExistenceEvent OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (0..32)) MAX-ACCESS read-write STATUS current DESCRIPTION "The mteEventName of the event to invoke when mteTriggerType is 'existence' and this trigger fires. A length of 0 indicates no event." Expires 6 July 2000 [Page 25] Internet Draft Distributed Management Event MIB 6 January 2000 DEFVAL { ''H } ::= { mteTriggerExistenceEntry 6 } -- -- Trigger Boolean Table -- mteTriggerBooleanTable OBJECT-TYPE SYNTAX SEQUENCE OF MteTriggerBooleanEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of management event trigger information for boolean triggers." ::= { mteTrigger 5 } mteTriggerBooleanEntry OBJECT-TYPE SYNTAX MteTriggerBooleanEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information about a single boolean trigger. Entries automatically exist in this this table for each mteTriggerEntry that has 'boolean' set in mteTriggerTest." INDEX { mteOwner, IMPLIED mteTriggerName } ::= { mteTriggerBooleanTable 1 } MteTriggerBooleanEntry ::= SEQUENCE { mteTriggerBooleanComparison INTEGER, mteTriggerBooleanValue Integer32, mteTriggerBooleanStartup TruthValue, mteTriggerBooleanObjectsOwner SnmpAdminString, mteTriggerBooleanObjects SnmpAdminString, mteTriggerBooleanEventOwner SnmpAdminString, mteTriggerBooleanEvent SnmpAdminString } mteTriggerBooleanComparison OBJECT-TYPE SYNTAX INTEGER { unequal(1), equal(2), less(3), lessOrEqual(4), greater(5), greaterOrEqual(6) } MAX-ACCESS read-write STATUS current DESCRIPTION Expires 6 July 2000 [Page 26] Internet Draft Distributed Management Event MIB 6 January 2000 "The type of boolean comparison to perform. The value at mteTriggerValueID is compared to mteTriggerBooleanValue, so for example if mteTriggerBooleanComparison is 'less' the result would be true if the value at mteTriggerValueID is less than the value of mteTriggerBooleanValue." DEFVAL { unequal } ::= { mteTriggerBooleanEntry 1 } mteTriggerBooleanValue OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-write STATUS current DESCRIPTION "The value to use for the test specified by mteTriggerBooleanTest." DEFVAL { 0 } ::= { mteTriggerBooleanEntry 2 } mteTriggerBooleanStartup OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "Control for whether an event may be triggered when this entry is first set to 'active' or a new instance of the object at mteTriggerValueID is found and the test specified by mteTriggerBooleanComparison is true. In that case an event is triggered if mteTriggerBooleanStartup is 'true'." DEFVAL { true } ::= { mteTriggerBooleanEntry 3 } mteTriggerBooleanObjectsOwner OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (0..32)) MAX-ACCESS read-write STATUS current DESCRIPTION "To go with mteTriggerBooleanObjects, the mteOwner of a group of objects from mteObjectsTable." DEFVAL { ''H } ::= { mteTriggerBooleanEntry 4 } mteTriggerBooleanObjects OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (0..32)) Expires 6 July 2000 [Page 27] Internet Draft Distributed Management Event MIB 6 January 2000 MAX-ACCESS read-write STATUS current DESCRIPTION "The mteObjectsName of a group of objects from mteObjectsTable. These objects are to be added to any Notification resulting from the firing of this trigger for this test. A list of objects may also be added based on the overall trigger, the event or other settings in mteTriggerTest. A length of 0 indicates no additional objects." DEFVAL { ''H } ::= { mteTriggerBooleanEntry 5 } mteTriggerBooleanEventOwner OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (0..32)) MAX-ACCESS read-write STATUS current DESCRIPTION "To go with mteTriggerBooleanEvent, the mteOwner of an event entry from mteEventTable." DEFVAL { ''H } ::= { mteTriggerBooleanEntry 6 } mteTriggerBooleanEvent OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (0..32)) MAX-ACCESS read-write STATUS current DESCRIPTION "The mteEventName of the event to invoke when mteTriggerType is 'boolean' and this trigger fires. A length of 0 indicates no event." DEFVAL { ''H } ::= { mteTriggerBooleanEntry 7 } -- -- Trigger Threshold Table -- mteTriggerThresholdTable OBJECT-TYPE SYNTAX SEQUENCE OF MteTriggerThresholdEntry MAX-ACCESS not-accessible STATUS current Expires 6 July 2000 [Page 28] Internet Draft Distributed Management Event MIB 6 January 2000 DESCRIPTION "A table of management event trigger information for threshold triggers." ::= { mteTrigger 6 } mteTriggerThresholdEntry OBJECT-TYPE SYNTAX MteTriggerThresholdEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information about a single threshold trigger. Entries automatically exist in this table for each mteTriggerEntry that has 'threshold' set in mteTriggerTest." INDEX { mteOwner, IMPLIED mteTriggerName } ::= { mteTriggerThresholdTable 1 } MteTriggerThresholdEntry ::= SEQUENCE { mteTriggerThresholdStartup INTEGER, mteTriggerThresholdRising Integer32, mteTriggerThresholdFalling Integer32, mteTriggerThresholdDeltaRising Integer32, mteTriggerThresholdDeltaFalling Integer32, mteTriggerThresholdObjectsOwner SnmpAdminString, mteTriggerThresholdObjects SnmpAdminString, mteTriggerThresholdRisingEventOwner SnmpAdminString, mteTriggerThresholdRisingEvent SnmpAdminString, mteTriggerThresholdFallingEventOwner SnmpAdminString, mteTriggerThresholdFallingEvent SnmpAdminString mteTriggerThresholdDeltaRisingEventOwner SnmpAdminString, mteTriggerThresholdDeltaRisingEvent SnmpAdminString, mteTriggerThresholdDeltaFallingEventOwner SnmpAdminString, mteTriggerThresholdDeltaFallingEvent SnmpAdminString } mteTriggerThresholdStartup OBJECT-TYPE SYNTAX INTEGER { rising(1), falling(2), risingOrFalling(3) } MAX-ACCESS read-write STATUS current DESCRIPTION "The event that may be triggered when this entry is first set to 'active' and a new instance of the object at mteTriggerValueID is found. If the first sample after this instance becomes active is greater than or equal to mteTriggerThresholdRising and mteTriggerThresholdStartup is equal to 'rising' or 'risingOrFalling', then one Expires 6 July 2000 [Page 29] Internet Draft Distributed Management Event MIB 6 January 2000 mteTriggerThresholdRisingEvent is triggered for that instance. If the first sample after this entry becomes active is less than or equal to mteTriggerThresholdFalling and mteTriggerThresholdStartup is equal to 'falling' or 'risingOrFalling', then one mteTriggerThresholdRisingEvent is triggered for that instance." DEFVAL { risingOrFalling } ::= { mteTriggerThresholdEntry 1 } mteTriggerThresholdRising OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-write STATUS current DESCRIPTION "A threshold value to check against if mteTriggerType is 'threshold'. When the current sampled value is greater than or equal to this threshold, and the value at the last sampling interval was less than this threshold, one mteTriggerThresholdRisingEvent is triggered. That event is also triggered if the first sample after this entry becomes active is greater than or equal to this threshold and mteTriggerThresholdStartup is equal to 'rising' or 'risingOrFalling'. After a rising event is generated, another such event is not triggered until the sampled value falls below this threshold and reaches mteTriggerThresholdFalling." DEFVAL { 0 } ::= { mteTriggerThresholdEntry 2 } mteTriggerThresholdFalling OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-write STATUS current DESCRIPTION "A threshold value to check against if mteTriggerType is 'threshold'. When the current sampled value is less than or equal to this threshold, and the value at the last sampling interval was greater than this threshold, one mteTriggerThresholdFallingEvent is triggered. That event is also triggered if the first sample afer this entry bcomes Expires 6 July 2000 [Page 30] Internet Draft Distributed Management Event MIB 6 January 2000 active is less than or equal to this threshold and mteTriggerThresholdStartup is equal to 'falling' or 'risingOrFalling'. After a falling event is generated, another such event is not triggered until the sampled value rises above this threshold and reaches mteTriggerThresholdRising." DEFVAL { 0 } ::= { mteTriggerThresholdEntry 3 } mteTriggerThresholdDeltaRising OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-write STATUS current DESCRIPTION "A threshold value to check against if mteTriggerType is 'threshold'. When the delta value (difference) between the current sampled value (value(n)) and the previous sampled value (value(n-1)) is greater than or equal to this threshold, and the delta value calculated at the last sampling interval (i.e. value(n-1) - value(n-2)) was less than this threshold, one mteTriggerThresholdDeltaRisingEvent is triggered. That event is also triggered if the first delta value calculated after this entry becomes active, i.e. value(2) - value(1), where value(1) is the first sample taken of that instance, is greater than or equal to this threshold. After a rising event is generated, another such event is not triggered until the delta value falls below this threshold and reaches mteTriggerThresholdDeltaFalling." DEFVAL { 0 } ::= { mteTriggerThresholdEntry 4 } mteTriggerThresholdDeltaFalling OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-write STATUS current DESCRIPTION "A threshold value to check against if mteTriggerType is 'threshold'. When the delta value (difference) between the current sampled value (value(n)) and the previous sampled value (value(n-1)) Expires 6 July 2000 [Page 31] Internet Draft Distributed Management Event MIB 6 January 2000 is less than or equal to this threshold, and the delta value calculated at the last sampling interval (i.e. value(n-1) - value(n-2)) was greater than this threshold, one mteTriggerThresholdDeltaFallingEvent is triggered. That event is also triggered if the first delta value calculated after this entry becomes active, i.e. value(2) - value(1), where value(1) is the first sample taken of that instance, is less than or equal to this threshold. After a falling event is generated, another such event is not triggered until the delta value falls below this threshold and reaches mteTriggerThresholdDeltaRising." DEFVAL { 0 } ::= { mteTriggerThresholdEntry 5 } mteTriggerThresholdObjectsOwner OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (0..32)) MAX-ACCESS read-write STATUS current DESCRIPTION "To go with mteTriggerThresholdObjects, the mteOwner of a group of objects from mteObjectsTable." DEFVAL { ''H } ::= { mteTriggerThresholdEntry 6 } mteTriggerThresholdObjects OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (0..32)) MAX-ACCESS read-write STATUS current DESCRIPTION "The mteObjectsName of a group of objects from mteObjectsTable. These objects are to be added to any Notification resulting from the firing of this trigger for this test. A list of objects may also be added based on the overall trigger, the event or other settings in mteTriggerTest. A length of 0 indicates no additional objects." DEFVAL { ''H } ::= { mteTriggerThresholdEntry 7 } mteTriggerThresholdRisingEventOwner OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (0..32)) MAX-ACCESS read-write Expires 6 July 2000 [Page 32] Internet Draft Distributed Management Event MIB 6 January 2000 STATUS current DESCRIPTION "To go with mteTriggerThresholdRisingEvent, the mteOwner of an event entry from mteEventTable." DEFVAL { ''H } ::= { mteTriggerThresholdEntry 8 } mteTriggerThresholdRisingEvent OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (0..32)) MAX-ACCESS read-write STATUS current DESCRIPTION "The mteEventName of the event to invoke when mteTriggerType is 'threshold' and this trigger fires based on mteTriggerThresholdRising. A length of 0 indicates no event." DEFVAL { ''H } ::= { mteTriggerThresholdEntry 9 } mteTriggerThresholdFallingEventOwner OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (0..32)) MAX-ACCESS read-write STATUS current DESCRIPTION "To go with mteTriggerThresholdFallingEvent, the mteOwner of an event entry from mteEventTable." DEFVAL { ''H } ::= { mteTriggerThresholdEntry 10 } mteTriggerThresholdFallingEvent OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (0..32)) MAX-ACCESS read-write STATUS current DESCRIPTION "The mteEventName of the event to invoke when mteTriggerType is 'threshold' and this trigger fires based on mteTriggerThresholdFalling. A length of 0 indicates no event." DEFVAL { ''H } ::= { mteTriggerThresholdEntry 11 } mteTriggerThresholdDeltaRisingEventOwner OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (0..32)) MAX-ACCESS read-write STATUS current DESCRIPTION "To go with mteTriggerThresholdDeltaRisingEvent, the mteOwner of an Expires 6 July 2000 [Page 33] Internet Draft Distributed Management Event MIB 6 January 2000 event entry from mteEventTable." DEFVAL { ''H } ::= { mteTriggerThresholdEntry 12 } mteTriggerThresholdDeltaRisingEvent OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (0..32)) MAX-ACCESS read-write STATUS current DESCRIPTION "The mteEventName of the event to invoke when mteTriggerType is 'threshold' and this trigger fires based on mteTriggerThresholdDeltaRising. A length of 0 indicates no event." DEFVAL { ''H } ::= { mteTriggerThresholdEntry 13 } mteTriggerThresholdDeltaFallingEventOwner OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (0..32)) MAX-ACCESS read-write STATUS current DESCRIPTION "To go with mteTriggerThresholdDeltaFallingEvent, the mteOwner of an event entry from mteEventTable." DEFVAL { ''H } ::= { mteTriggerThresholdEntry 14 } mteTriggerThresholdDeltaFallingEvent OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (0..32)) MAX-ACCESS read-write STATUS current DESCRIPTION "The mteEventName of the event to invoke when mteTriggerType is 'threshold' and this trigger fires based on mteTriggerThresholdDeltaFalling. A length of 0 indicates no event." DEFVAL { ''H } ::= { mteTriggerThresholdEntry 15 } -- -- Objects Table -- mteObjectsTable OBJECT-TYPE SYNTAX SEQUENCE OF MteObjectsEntry MAX-ACCESS not-accessible STATUS current Expires 6 July 2000 [Page 34] Internet Draft Distributed Management Event MIB 6 January 2000 DESCRIPTION "A table of objects that can be added to notifications based on the trigger, trigger test, or event, as pointed to by entries in those tables." ::= { mteObjects 1 } mteObjectsEntry OBJECT-TYPE SYNTAX MteObjectsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A group of objects. Applications create and delete entries using mteObjectsEntryStatus. When adding objects to a notification they are added in the lexical order of their index in this table. Those associated with a trigger come first, then trigger test, then event." INDEX { mteOwner, mteObjectsName, mteObjectsIndex } ::= { mteObjectsTable 1 } MteObjectsEntry ::= SEQUENCE { mteObjectsName SnmpAdminString, mteObjectsIndex Unsigned32, mteObjectsID OBJECT IDENTIFIER, mteObjectsIDWildcard TruthValue, mteObjectsEntryStatus RowStatus } mteObjectsName OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (1..32)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "A locally-unique, administratively assigned name for a group of objects." ::= { mteObjectsEntry 1 } mteObjectsIndex OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "An arbitrary small integer for the purpose of identifying individual objects within a mteObjectsName group. Expires 6 July 2000 [Page 35] Internet Draft Distributed Management Event MIB 6 January 2000 Objects within a group are placed in the notification in the numerical order of this index. Groups are placed in the notification in the order of the selections for overall trigger, trigger test, and event. Within trigger test they are in the same order as the numerical values of the bits defined for mteTriggerTest. Bad object identifiers or a mismatch between truncating the identifier and the value of mteDeltaDiscontinuityIDWildcard result in operation as one would expect when providing the wrong identifier to a Get operation. The Get will fail or get the wrong object. If the object is not available it is omitted from the notification." ::= { mteObjectsEntry 2 } mteObjectsID OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-create STATUS current DESCRIPTION "The object identifier of a MIB object to add to a Notification that results from the firing of a trigger. This may be wildcarded by truncating all or part of the instance portion, in which case the instance portion of the OID for obtaining this object will be the same as that used in obtaining the mteTriggerValueID that fired. If such wildcarding is applied, mteObjectsIDWildcard must be 'true' and if not it must be 'false'. Each instance that fills the wildcard is independent of any additional instances, that is, wildcarded objects operate as if there were a separate table entry for each instance that fills the wildcard without having to actually predict all possible instances ahead of time." DEFVAL { zeroDotZero } ::= { mteObjectsEntry 3 } mteObjectsIDWildcard OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "Control for whether mteObjectsID is to be treated as Expires 6 July 2000 [Page 36] Internet Draft Distributed Management Event MIB 6 January 2000 fully-specified or wildcarded, with 'true' indicating wildcard." DEFVAL { false } ::= { mteObjectsEntry 4 } mteObjectsEntryStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The control that allows creation and deletion of entries. Once made active an entry MAY not be modified except to delete it." ::= { mteObjectsEntry 5 } -- -- Event Section -- -- Counters mteEventFailures OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times an attempt to invoke an event has failed. This counts individually for each attempt in a group of targets or each attempt for a wildcarded trigger object." ::= { mteEvent 1 } -- -- Event Table -- mteEventTable OBJECT-TYPE SYNTAX SEQUENCE OF MteEventEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of management event action information." ::= { mteEvent 2 } Expires 6 July 2000 [Page 37] Internet Draft Distributed Management Event MIB 6 January 2000 mteEventEntry OBJECT-TYPE SYNTAX MteEventEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information about a single event. Applications create and delete entries using mteEventEntryStatus." INDEX { mteOwner, IMPLIED mteEventName } ::= { mteEventTable 1 } MteEventEntry ::= SEQUENCE { mteEventName SnmpAdminString, mteEventComment SnmpAdminString, mteEventActions BITS, mteEventEnabled TruthValue, mteEventEntryStatus RowStatus } mteEventName OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (1..32)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "A locally-unique, administratively assigned name for the event." ::= { mteEventEntry 1 } mteEventComment OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-create STATUS current DESCRIPTION "A description of the event's function and use." DEFVAL { ''H } ::= { mteEventEntry 2 } mteEventActions OBJECT-TYPE SYNTAX BITS { notification(0), set(1) } MAX-ACCESS read-create STATUS current DESCRIPTION "The actions to perform when this event occurs. For 'notification', Traps and/or Informs are sent according to the configuration in the SNMP Notification MIB. Expires 6 July 2000 [Page 38] Internet Draft Distributed Management Event MIB 6 January 2000 For 'set', an SNMP Set operation is performed according to control values in this entry." DEFVAL { '0'H } -- No bits set. ::= { mteEventEntry 3 } mteEventEnabled OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "A control to allow an event to be configured but not used. When the value is 'false' the event does not execute even if triggered." DEFVAL { false } ::= { mteEventEntry 4 } mteEventEntryStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The control that allows creation and deletion of entries. Once made active an entry MAY not be modified except to delete it." ::= { mteEventEntry 5 } -- -- Event Notification Table -- mteEventNotificationTable OBJECT-TYPE SYNTAX SEQUENCE OF MteEventNotificationEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of information about notifications to be sent as a consequence of management events." ::= { mteEvent 3 } mteEventNotificationEntry OBJECT-TYPE SYNTAX MteEventNotificationEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION Expires 6 July 2000 [Page 39] Internet Draft Distributed Management Event MIB 6 January 2000 "Information about a single event's notification. Entries automatically exist in this this table for each mteEventEntry that has 'notification' set in mteEventActions." INDEX { mteOwner, IMPLIED mteEventName } ::= { mteEventNotificationTable 1 } MteEventNotificationEntry ::= SEQUENCE { mteEventNotification OBJECT IDENTIFIER, mteEventNotificationObjectsOwner SnmpAdminString, mteEventNotificationObjects SnmpAdminString } mteEventNotification OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-write STATUS current DESCRIPTION "The object identifier from the NOTIFICATION-TYPE for the notification to use if metEventActions has 'notification' set." DEFVAL { zeroDotZero } ::= { mteEventNotificationEntry 1 } mteEventNotificationObjectsOwner OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (0..32)) MAX-ACCESS read-write STATUS current DESCRIPTION "To go with mteEventNotificationObjects, the mteOwner of a group of objects from mteObjectsTable." DEFVAL { ''H } ::= { mteEventNotificationEntry 2 } mteEventNotificationObjects OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (0..32)) MAX-ACCESS read-write STATUS current DESCRIPTION "The mteObjectsName of a group of objects from mteObjectsTable if mteEventActions has 'notification' set. These objects are to be added to any Notification generated by this event. Objects may also be added based on the trigger that stimulated the event. Expires 6 July 2000 [Page 40] Internet Draft Distributed Management Event MIB 6 January 2000 A length of 0 indicates no additional objects." DEFVAL { ''H } ::= { mteEventNotificationEntry 3 } -- -- Event Set Table -- mteEventSetTable OBJECT-TYPE SYNTAX SEQUENCE OF MteEventSetEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of management event action information." ::= { mteEvent 4 } mteEventSetEntry OBJECT-TYPE SYNTAX MteEventSetEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information about a single event's set option. Entries automatically exist in this this table for each mteEventEntry that has 'set' set in mteEventActions." INDEX { mteOwner, IMPLIED mteEventName } ::= { mteEventSetTable 1 } MteEventSetEntry ::= SEQUENCE { mteEventSetObject OBJECT IDENTIFIER, mteEventSetObjectWildcard TruthValue, mteEventSetValue Integer32, mteEventSetTargetTag SnmpTagValue, mteEventSetContextName SnmpAdminString, mteEventSetContextNameWildcard TruthValue } mteEventSetObject OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-write STATUS current DESCRIPTION "The object identifier from the MIB object to set if mteEventActions has 'set' set. Expires 6 July 2000 [Page 41] Internet Draft Distributed Management Event MIB 6 January 2000 This object identifier may be wildcarded by leaving sub-identifiers off the end, in which case nteEventSetObjectWildCard must be 'true'. If mteEventSetObject is wildcarded the instance used to set the object to which it points is the same as the instance from the value of mteTriggerValueID that triggered the event. Each instance that fills the wildcard is independent of any additional instances, that is, wildcarded objects operate as if there were a separate table entry for each instance that fills the wildcard without having to actually predict all possible instances ahead of time. Bad object identifiers or a mismatch between truncating the identifier and the value of mteSetObjectWildcard result in operation as one would expect when providing the wrong identifier to a Set operation. The Set will fail or set the wrong object. If the value syntax of the destination object is not correct, the Set fails with the normal SNMP error code." DEFVAL { zeroDotZero } ::= { mteEventSetEntry 1 } mteEventSetObjectWildcard OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "Control over whether mteEventSetObject is to be treated as fully-specified or wildcarded, with 'true' indicating wildcard if mteEventActions has 'set' set." DEFVAL { false } ::= { mteEventSetEntry 2 } mteEventSetValue OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-write STATUS current DESCRIPTION "The value to which to set the object at mteEventSetObject if mteEventActions has 'set' set." DEFVAL { 0 } ::= { mteEventSetEntry 3 } Expires 6 July 2000 [Page 42] Internet Draft Distributed Management Event MIB 6 January 2000 mteEventSetTargetTag OBJECT-TYPE SYNTAX SnmpTagValue MAX-ACCESS read-write STATUS current DESCRIPTION "The tag for the target(s) at which to set the object at mteEventSetObject to mteEventSetValue if mteEventActions has 'set' set. Systems limited to self management MAY not accept a non-zero length for the value of this object. A length of 0 indicates the local system. In this case, access to the objects indicated by mteEventSetObject is under the security credentials of the requester that set mteTriggerEntryStatus to 'active'. Those credentials are the input parameters for isAccessAllowed from the Architecture for Describing SNMP Management Frameworks. Otherwise access rights are checked according to the security parameters resulting from the tag." DEFVAL { ''H } ::= { mteEventSetEntry 4 } mteEventSetContextName OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-write STATUS current DESCRIPTION "The management context in which to set mteEventObjectID. if mteEventActions has 'set' set. This may be wildcarded by leaving characters off the end. To indicate such wildcarding mteEventSetContextNameWildcard must be 'true'. If this context name is wildcarded the value used to complete the wildcarding of mteTriggerContextName will be appended." DEFVAL { ''H } ::= { mteEventSetEntry 5 } mteEventSetContextNameWildcard OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current Expires 6 July 2000 [Page 43] Internet Draft Distributed Management Event MIB 6 January 2000 DESCRIPTION "Control for whether mteEventSetContextName is to be treated as fully-specified or wildcarded, with 'true' indicating wildcard if mteEventActions has 'set' set." DEFVAL { false } ::= { mteEventSetEntry 6 } -- -- Notifications -- dismanEventMIBNotificationPrefix OBJECT IDENTIFIER ::= { dismanEventMIB 2 } dismanEventMIBNotifications OBJECT IDENTIFIER ::= { dismanEventMIBNotificationPrefix 0 } dismanEventMIBNotificationObjects OBJECT IDENTIFIER ::= { dismanEventMIBNotificationPrefix 1 } -- -- Notification Objects -- mteHotTrigger OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS accessible-for-notify STATUS current DESCRIPTION "The name of the trigger causing the notification." ::= { dismanEventMIBNotificationObjects 1 } mteHotTargetName OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS accessible-for-notify STATUS current DESCRIPTION "The SNMP Target MIB's snmpTargetAddrName related to the notification." ::= { dismanEventMIBNotificationObjects 2 } mteHotContextName OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS accessible-for-notify STATUS current DESCRIPTION "The context name related to the notification. This MUST be as Expires 6 July 2000 [Page 44] Internet Draft Distributed Management Event MIB 6 January 2000 fully-qualified as possible, including filling in wildcard information determined in processing." ::= { dismanEventMIBNotificationObjects 3 } mteHotOID OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS accessible-for-notify STATUS current DESCRIPTION "The object identifier of the destination object related to the notification. This MUST be as fully-qualified as possible, inluding filling in wildcard information determined in processing. For a trigger-related notification this is from mteTriggerValueID. For a set failure this is from mteEventSetObject." ::= { dismanEventMIBNotificationObjects 4 } mteHotValue OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS accessible-for-notify STATUS current DESCRIPTION "The value of the object at mteTriggerValueID when a trigger fired." ::= { dismanEventMIBNotificationObjects 5 } mteFailedReason OBJECT-TYPE SYNTAX FailureReason MAX-ACCESS accessible-for-notify STATUS current DESCRIPTION "The reason for the failure of an attempt to check for a trigger condition or set an object in response to an event." ::= { dismanEventMIBNotificationObjects 6 } -- -- Notifications -- mteTriggerFired NOTIFICATION-TYPE OBJECTS { mteHotTrigger, mteHotTargetName, Expires 6 July 2000 [Page 45] Internet Draft Distributed Management Event MIB 6 January 2000 mteHotContextName, mteHotOID, mteHotValue } STATUS current DESCRIPTION "Notification that the trigger indicated by the object instances has fired, for triggers with mteTriggerType 'boolean' or 'existence'." ::= { dismanEventMIBNotifications 1 } mteTriggerRising NOTIFICATION-TYPE OBJECTS { mteHotTrigger, mteHotTargetName, mteHotContextName, mteHotOID, mteHotValue } STATUS current DESCRIPTION "Notification that the rising threshold was met for triggers with mteTriggerType 'threshold'." ::= { dismanEventMIBNotifications 2 } mteTriggerFalling NOTIFICATION-TYPE OBJECTS { mteHotTrigger, mteHotTargetName, mteHotContextName, mteHotOID, mteHotValue } STATUS current DESCRIPTION "Notification that the falling threshold was met for triggers with mteTriggerType 'threshold'." ::= { dismanEventMIBNotifications 3 } mteTriggerFailure NOTIFICATION-TYPE OBJECTS { mteHotTrigger, mteHotTargetName, mteHotContextName, mteHotOID, mteFailedReason } STATUS current DESCRIPTION "Notification that an attempt to check a trigger has failed. The network manager must enable this notification only with Expires 6 July 2000 [Page 46] Internet Draft Distributed Management Event MIB 6 January 2000 a certain fear and trembling, as it can easily crowd out more important information. It should be used only to help diagnose a problem that has appeared in the error counters and can not be found otherwise." ::= { dismanEventMIBNotifications 4 } mteEventSetFailure NOTIFICATION-TYPE OBJECTS { mteHotTrigger, mteHotTargetName, mteHotContextName, mteHotOID, mteFailedReason } STATUS current DESCRIPTION "Notification that an attempt to do a set in response to an event has failed. The network manager must enable this notification only with a certain fear and trembling, as it can easily crowd out more important information. It should be used only to help diagnose a problem that has appeared in the error counters and can not be found otherwise." ::= { dismanEventMIBNotifications 5 } -- -- Conformance -- dismanEventMIBConformance OBJECT IDENTIFIER ::= { dismanEventMIB 3 } dismanEventMIBCompliances OBJECT IDENTIFIER ::= { dismanEventMIBConformance 1 } dismanEventMIBGroups OBJECT IDENTIFIER ::= { dismanEventMIBConformance 2 } -- Compliance dismanEventMIBCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for entities which implement the Event MIB." MODULE -- this module MANDATORY-GROUPS { dismanEventResourceGroup, dismanEventTriggerGroup, dismanEventObjectsGroup, Expires 6 July 2000 [Page 47] Internet Draft Distributed Management Event MIB 6 January 2000 dismanEventEventGroup, dismanEventNotificationObjectGroup, dismanEventNotificationGroup } OBJECT mteTriggerTargetTag MIN-ACCESS read-only DESCRIPTION "Write access is not required, thus limiting monitoring to the local system or pre-configured remote systems." OBJECT mteEventSetTargetTag MIN-ACCESS read-only DESCRIPTION "Write access is not required, thus limiting setting to the local system or pre-configured remote systems." OBJECT mteTriggerValueIDWildcard MIN-ACCESS read-only DESCRIPTION "Write access is not required, thus allowing the system not to implement wildcarding." OBJECT mteTriggerContextNameWildcard MIN-ACCESS read-only DESCRIPTION "Write access is not required, thus allowing the system not to implement wildcarding." OBJECT mteObjectsIDWildcard MIN-ACCESS read-only DESCRIPTION "Write access is not required, thus allowing the system not to implement wildcarding." OBJECT mteEventSetContextNameWildcard MIN-ACCESS read-only DESCRIPTION "Write access is not required, thus allowing the system not to implement wildcarding." ::= { dismanEventMIBCompliances 1 } Expires 6 July 2000 [Page 48] Internet Draft Distributed Management Event MIB 6 January 2000 -- Units of Conformance dismanEventResourceGroup OBJECT-GROUP OBJECTS { mteResourceSampleMinimum, mteResourceSampleInstanceMaximum, mteResourceSampleInstances, mteResourceSampleInstancesHigh, mteResourceSampleInstanceLacks } STATUS current DESCRIPTION "Event resource status and control objects." ::= { dismanEventMIBGroups 1 } dismanEventTriggerGroup OBJECT-GROUP OBJECTS { mteTriggerFailures, mteTriggerComment, mteTriggerTest, mteTriggerSampleType, mteTriggerValueID, mteTriggerValueIDWildcard, mteTriggerTargetTag, mteTriggerContextName, mteTriggerContextNameWildcard, mteTriggerFrequency, mteTriggerObjectsOwner, mteTriggerObjects, mteTriggerEnabled, mteTriggerEntryStatus, mteTriggerDeltaDiscontinuityID, mteTriggerDeltaDiscontinuityIDWildcard, mteTriggerDeltaDiscontinuityIDType, mteTriggerExistenceTest, mteTriggerExistenceStartup, mteTriggerExistenceObjectsOwner, mteTriggerExistenceObjects, mteTriggerExistenceEventOwner, mteTriggerExistenceEvent, Expires 6 July 2000 [Page 49] Internet Draft Distributed Management Event MIB 6 January 2000 mteTriggerBooleanComparison, mteTriggerBooleanValue, mteTriggerBooleanStartup, mteTriggerBooleanObjectsOwner, mteTriggerBooleanObjects, mteTriggerBooleanEventOwner, mteTriggerBooleanEvent, mteTriggerThresholdStartup, mteTriggerThresholdObjectsOwner, mteTriggerThresholdObjects, mteTriggerThresholdRising, mteTriggerThresholdFalling, mteTriggerThresholdDeltaRising, mteTriggerThresholdDeltaFalling, mteTriggerThresholdRisingEventOwner, mteTriggerThresholdRisingEvent, mteTriggerThresholdFallingEventOwner, mteTriggerThresholdFallingEvent mteTriggerThresholdDeltaRisingEventOwner, mteTriggerThresholdDeltaRisingEvent, mteTriggerThresholdDeltaFallingEventOwner, mteTriggerThresholdDeltaFallingEvent } STATUS current DESCRIPTION "Event triggers." ::= { dismanEventMIBGroups 2 } dismanEventObjectsGroup OBJECT-GROUP OBJECTS { mteObjectsID, mteObjectsIDWildcard, mteObjectsEntryStatus } STATUS current DESCRIPTION "Supplemental objects." ::= { dismanEventMIBGroups 3 } dismanEventEventGroup OBJECT-GROUP OBJECTS { mteEventFailures, mteEventComment, Expires 6 July 2000 [Page 50] Internet Draft Distributed Management Event MIB 6 January 2000 mteEventActions, mteEventEnabled, mteEventEntryStatus, mteEventNotification, mteEventNotificationObjectsOwner, mteEventNotificationObjects, mteEventSetObject, mteEventSetObjectWildcard, mteEventSetValue, mteEventSetTargetTag, mteEventSetContextName, mteEventSetContextNameWildcard } STATUS current DESCRIPTION "Events." ::= { dismanEventMIBGroups 4 } dismanEventNotificationObjectGroup OBJECT-GROUP OBJECTS { mteHotTrigger, mteHotTargetName, mteHotContextName, mteHotOID, mteHotValue, mteFailedReason } STATUS current DESCRIPTION "Notification objects." ::= { dismanEventMIBGroups 5 } dismanEventNotificationGroup NOTIFICATION-GROUP NOTIFICATIONS { mteTriggerFired, mteTriggerRising, mteTriggerFalling, mteTriggerFailure, mteEventSetFailure } STATUS current DESCRIPTION "Notifications." Expires 6 July 2000 [Page 51] Internet Draft Distributed Management Event MIB 6 January 2000 ::= { dismanEventMIBGroups 6 } END Expires 6 July 2000 [Page 52] Internet Draft Distributed Management Event MIB 6 January 2000 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. Expires 6 July 2000 [Page 53] Internet Draft Distributed Management Event MIB 6 January 2000 10. Acknowledgements This MIB contains considerable contributions from the RMON MIB, the Distributed Management Design Team (Andy Bierman, Maria Greene, Bob Stewart, and Steve Waldbusser), the Distributed Management Working Group, and colleagues at Cisco. Expires 6 July 2000 [Page 54] Internet Draft Distributed Management Event MIB 6 January 2000 11. References [RFC2571] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing SNMP Management Frameworks", RFC 2571, April 1999 [RFC1155] Rose, M., and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based Internets", STD 16, RFC 1155, May 1990 [RFC1212] Rose, M., and K. McCloghrie, "Concise MIB Definitions", STD 16, RFC 1212, March 1991 [RFC1215] M. Rose, "A Convention for Defining Traps for use with the SNMP", RFC 1215, March 1991 [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., and S. Waldbusser, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999 [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999 [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., and S. Waldbusser, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999 [RFC1157] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network Management Protocol", STD 15, RFC 1157, May 1990. [RFC1901] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Introduction to Community-based SNMPv2", RFC 1901, January 1996. [RFC1906] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Transport Mappings for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1906, January 1996. [RFC2572] Case, J., Harrington D., Presuhn R., and B. Wijnen, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)", RFC 2572, April 1999 [RFC2574] Blumenthal, U., and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Expires 6 July 2000 [Page 55] Internet Draft Distributed Management Event MIB 6 January 2000 Protocol (SNMPv3)", RFC 2574, April 1999 [RFC1905] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Protocol Operations for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1905, January 1996. [RFC2573] Levi, D., Meyer, P., and B. Stewart, "SNMPv3 Applications", RFC 2573, April 1999 [RFC2575] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", RFC 2575, April 1999 [RFC2570] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction to Version 3 of the Internet-standard Network Management Framework", RFC 2570, April 1999 [RFC1903] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Coexistence between Version 1 and version 2 of the Internet-standard Network Management Framework", RFC 1903, January 1996. [RFCEventMIB] Stewart, B., "Event MIB", RFC ????, ?Month? 1999. [RFC1757] Waldbusser, S., "Remote Network Monitoring Management Information Base", RFC 1757, February 1995. [RFC1451] Case, J., McCloghrie, K., Rose, M., Waldbusser, S., "Manager-to- Manager Management Information Base", RFC 1451, April 1993. [RFCExpressionMIB] Stewart, B., "Expression MIB", RFC ????, ?Month? 1999. [RFCNotificationLogMIB] Stewart, B., "Notification Log MIB", RFC ????, ?Month? 1999. Expires 6 July 2000 [Page 56] Internet Draft Distributed Management Event MIB 6 January 2000 12. Security Considerations Security issues are discussed in the Security section and in the DESCRIPTION clauses of relevant objects. 13. Author's Address Bob Stewart Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134-1706 U.S.A. 14. Editor's Address Ramanathan Kavasseri Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134-1706 U.S.A. Phone: +1 408 527 2446 Email: ramk@cisco.com Expires 6 July 2000 [Page 57] Internet Draft Distributed Management Event MIB 6 January 2000 15. Full Copyright Statement Copyright (C) The Internet Society (1999). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Expires 6 July 2000 [Page 58] Internet Draft Distributed Management Event MIB 6 January 2000 Table of Contents 1 Abstract ........................................................ 2 2 The SNMP Management Framework ................................... 2 3 Overview ........................................................ 4 4 Relationship to Other MIBs ...................................... 4 5 MIB Sections .................................................... 4 6 Operation ....................................................... 7 7 Security ........................................................ 8 8 Definitions ..................................................... 10 9 Intellectual Property ........................................... 53 10 Acknowledgements ............................................... 54 11 References ..................................................... 55 12 Security Considerations ........................................ 57 13 Author's Address ............................................... 57 14 Editor's Address ............................................... 57 15 Full Copyright Statement ....................................... 58 Expires 6 July 2000 [Page 59] From owner-disman@dorothy.bmc.com Wed Jan 12 06:44:54 2000 Received: from tangelo.bmc.com (fw-us-hou-2.bmc.com [198.207.223.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12239 for ; Wed, 12 Jan 2000 06:44:54 -0500 (EST) Received: from dorothy.peer.com (dorothy.bmc.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id FAA22855; Wed, 12 Jan 2000 05:44:33 -0600 (CST) Received: (from root@localhost) by dorothy.peer.com (8.8.6 (PHNE_12836)/8.8.6) id DAA21779 for disman-list; Wed, 12 Jan 2000 03:40:33 -0800 (PST) Received: from tangelo.bmc.com (root@tangelo.bmc.com [172.17.7.166]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id DAA21727 for ; Wed, 12 Jan 2000 03:40:24 -0800 (PST) Received: from fw-us-hou1.bmc.com (fw-us-hou1.bmc.com [172.17.0.250]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with SMTP id FAA22458 for ; Wed, 12 Jan 2000 05:40:42 -0600 (CST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12189; Wed, 12 Jan 2000 06:40:40 -0500 (EST) Message-Id: <200001121140.GAA12189@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: disman@dorothy.peer.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-disman-event-mib-09.txt Date: Wed, 12 Jan 2000 06:40:40 -0500 Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Distributed Management Working Group of the IETF. Title : Event MIB Author(s) : B. Stewart Filename : draft-ietf-disman-event-mib-09.txt Pages : 59 Date : 11-Jan-00 This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects that can be used to manage and monitor MIB objects and take action through events. The Event MIB provides the ability to monitor MIB objects on the local system or on a remote system and take simple action when a trigger condition is met. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-disman-event-mib-09.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-disman-event-mib-09.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-disman-event-mib-09.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000111145420.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-disman-event-mib-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-disman-event-mib-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000111145420.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-disman@dorothy.bmc.com Wed Jan 12 09:56:48 2000 Received: from tangelo.bmc.com (fw-us-hou-2.bmc.com [198.207.223.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17187 for ; Wed, 12 Jan 2000 09:56:43 -0500 (EST) Received: from dorothy.bmc.com (dorothy.bmc.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id IAA03560; Wed, 12 Jan 2000 08:56:04 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id GAA00775 for disman-list; Wed, 12 Jan 2000 06:54:10 -0800 (PST) Received: from tangelo.bmc.com (root@tangelo.bmc.com [172.17.7.166]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id GAA00769 for ; Wed, 12 Jan 2000 06:54:06 -0800 (PST) Received: from fw-us-hou1.bmc.com (fw-us-hou1.bmc.com [172.17.0.250]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with SMTP id IAA03128 for ; Wed, 12 Jan 2000 08:54:30 -0600 (CST) Received: from henkell.ibr.cs.tu-bs.de (schoenw@henkell [134.169.34.191]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) with ESMTP id PAA14736; Wed, 12 Jan 2000 15:54:25 +0100 (MET) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id PAA13980; Wed, 12 Jan 2000 15:54:25 +0100 Date: Wed, 12 Jan 2000 15:54:25 +0100 Message-Id: <200001121454.PAA13980@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: disman@dorothy.peer.com In-reply-to: <387C8E58.D662FB44@france.sun.com> (message from Eamonn McManus on Wed, 12 Jan 2000 15:23:20 +0100) Subject: Re: Sched/Script MIB issues References: <200001051547.KAA05791@seymour47.SNMP.COM> <200001061114.MAA09958@henkell.ibr.cs.tu-bs.de> <387C8E58.D662FB44@france.sun.com> Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list >>>>> Eamonn McManus writes: Eamonn> I quite agree with Juergen about this. In the project I Eamonn> implemented the Script MIB for, I wanted to be able to say Eamonn> that the implementation conformed to a (future) standard, and Eamonn> in particular I set myself the constraint that I would add no Eamonn> new SNMP objects. Without this constraint, I agree that Eamonn> overloading the name to hold the auto-start flag is hacky. >> The other ultimate solution is to define a mechanism which allows >> to launch scripts (or better perform sets on INTEGER valued >> objects) when a notification is generated or received. But this >> gets hairy when it comes down to passing notification details to >> the script or whatever got invoked. Eamonn> In principle this is indeed a nicer solution, but if made Eamonn> appropriately general it is in danger of being very Eamonn> complicated, and in particular perhaps too complicated for Eamonn> embedded systems. Thanks for your feedback. So here is a strawman proposal: We add a new object to the smLaunchTable which controls whether the associated script is restarted during reboot. We make this new object a BITS object so that it is possible to add additional start conditions in the future (if we ever need to do this) and we leave a more general solution for this problem for future work. Let me know if there are any concerns or objections. /js -- Juergen Schoenwaelder Technical University Braunschweig Dept. Operating Systems & Computer Networks Phone: +49 531 391 3289 Bueltenweg 74/75, 38106 Braunschweig, Germany Fax: +49 531 391 5936 From owner-disman@dorothy.bmc.com Wed Jan 12 10:44:19 2000 Received: from tangelo.bmc.com (fw-us-hou-2.bmc.com [198.207.223.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17959 for ; Wed, 12 Jan 2000 10:44:17 -0500 (EST) Received: from dorothy.peer.com (dorothy.bmc.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id JAA20446; Wed, 12 Jan 2000 09:44:11 -0600 (CST) Received: (from root@localhost) by dorothy.peer.com (8.8.6 (PHNE_12836)/8.8.6) id HAA02943 for disman-list; Wed, 12 Jan 2000 07:42:50 -0800 (PST) Received: from tangelo.bmc.com (root@tangelo.bmc.com [172.17.7.166]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id HAA02938 for ; Wed, 12 Jan 2000 07:42:45 -0800 (PST) Received: from fw-us-hou1.bmc.com (fw-us-hou1.bmc.com [172.17.0.250]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with SMTP id JAA20003 for ; Wed, 12 Jan 2000 09:43:09 -0600 (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.3) with ESMTP id QAA18673; Wed, 12 Jan 2000 16:43:06 +0100 (MET) Received: (from strauss@localhost) by hansa.ibr.cs.tu-bs.de (8.9.3/8.9.3) id QAA16666; Wed, 12 Jan 2000 16:43:06 +0100 From: Frank Strauss To: disman@dorothy.peer.com Cc: Juergen Schoenwaelder Subject: Re: Sched/Script MIB issues References: <200001121454.PAA13980.disman@henkell.ibr.cs.tu-bs.de> Date: 12 Jan 2000 16:43:06 +0100 In-Reply-To: schoenw@ibr.cs.tu-bs.de's message of "12 Jan 2000 16:00:36 +0100" Message-ID: Lines: 26 User-Agent: Gnus/5.070097 (Pterodactyl Gnus v0.97) Emacs/20.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list Hi! Juergen> Thanks for your feedback. So here is a strawman proposal: Juergen> We add a new object to the smLaunchTable which controls Juergen> whether the associated script is restarted during reboot. We Juergen> make this new object a BITS object so that it is possible to Juergen> add additional start conditions in the future (if we ever Juergen> need to do this) and we leave a more general solution for Juergen> this problem for future work. Juergen> Let me know if there are any concerns or objections. One potential objection just comes to my mind: There might arise situations where it is useful to start multiple running script instances of a single script and may be even from a single launch button. Thus, one could consider it useful to have an integer typed object that identifies the number to scripts to start instead of just a flag. On the other hand, at this moment I cannot find any reasonable example where it could be really useful to start multiple equivalent script instances. Frank From owner-disman@dorothy.bmc.com Wed Jan 12 10:53:31 2000 Received: from tangelo.bmc.com (fw-us-hou-1.bmc.com [198.207.223.250]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18069 for ; Wed, 12 Jan 2000 10:53:29 -0500 (EST) Received: from dorothy.bmc.com (dorothy.bmc.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id JAA23725; Wed, 12 Jan 2000 09:53:24 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id HAA03439 for disman-list; Wed, 12 Jan 2000 07:52:42 -0800 (PST) Received: from tangelo.bmc.com (root@tangelo.bmc.com [172.17.7.166]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id HAA03434 for ; Wed, 12 Jan 2000 07:52:38 -0800 (PST) Received: from fw-us-hou1.bmc.com (fw-us-hou1.bmc.com [172.17.0.250]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with SMTP id JAA23613 for ; Wed, 12 Jan 2000 09:53:02 -0600 (CST) Received: from henkell.ibr.cs.tu-bs.de (schoenw@henkell [134.169.34.191]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) with ESMTP id QAA19470; Wed, 12 Jan 2000 16:53:00 +0100 (MET) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id QAA16178; Wed, 12 Jan 2000 16:52:59 +0100 Date: Wed, 12 Jan 2000 16:52:59 +0100 Message-Id: <200001121552.QAA16178@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: strauss@ibr.cs.tu-bs.de CC: disman@dorothy.peer.com In-reply-to: (message from Frank Strauss on 12 Jan 2000 16:43:06 +0100) Subject: Re: Sched/Script MIB issues References: <200001121454.PAA13980.disman@henkell.ibr.cs.tu-bs.de> Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list >>>>> Frank Strauss writes: Frank> On the other hand, at this moment I cannot find any reasonable Frank> example where it could be really useful to start multiple Frank> equivalent script instances. ... with the same argument. And even if you need to start a small number of scripts with the same arguments, you can create multiple smLaunchTable entries. So the issue is whether there is a practical need to starts lots of equivalent script instances and whether the script MIB should have special support for it. I have doubts. /js -- Juergen Schoenwaelder Technical University Braunschweig Dept. Operating Systems & Computer Networks Phone: +49 531 391 3289 Bueltenweg 74/75, 38106 Braunschweig, Germany Fax: +49 531 391 5936 From owner-disman@dorothy.bmc.com Wed Jan 12 12:46:04 2000 Received: from tangelo.bmc.com (fw-us-hou-2.bmc.com [198.207.223.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20528 for ; Wed, 12 Jan 2000 12:45:59 -0500 (EST) Received: from dorothy.bmc.com (dorothy.bmc.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id LAA04574; Wed, 12 Jan 2000 11:45:35 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id JAA25958 for disman-list; Wed, 12 Jan 2000 09:43:07 -0800 (PST) Received: (from rpresuhn@localhost) by dorothy.peer.com (8.8.6 (PHNE_12836)/8.8.6) id JAA25952; Wed, 12 Jan 2000 09:43:03 -0800 (PST) Date: Wed, 12 Jan 2000 09:43:03 -0800 (PST) From: Randy Presuhn Message-Id: <200001121743.JAA25952@dorothy.peer.com> To: disman@dorothy.peer.com Subject: Fwd: Re: Sched/Script MIB issues Cc: eamonn.mcmanus@france.sun.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list Content-Transfer-Encoding: 8bit Hi - Relevant non-subscriber post to the disman list. ------------------------------------------------------------------------ Randy Presuhn randy_presuhn@bmc.com http://www.bmc.com/ Voice: +1 408 546-1006 BMC Software, Inc. 1-3141 2141 N. First Street Fax: +1 408 965-0359 San Jose, California 95131 USA ------------------------------------------------------------------------ Any relationship between my opinions and BMC's should be coincidental. ------------------------------------------------------------------------ > Received: from tangelo.bmc.com (root@tangelo.bmc.com [172.17.7.166]) > by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id GAA29235 > for ; Wed, 12 Jan 2000 06:23:31 -0800 (PST) > Received: from fw-us-hou1.bmc.com (fw-us-hou1.bmc.com [172.17.0.250]) > by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with SMTP id IAA21601 > for ; Wed, 12 Jan 2000 08:23:55 -0600 (CST) > Received: from France.Sun.COM ([129.157.188.1]) > by mercury.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id GAA08568; > Wed, 12 Jan 2000 06:23:48 -0800 (PST) > Received: from bebop.France.Sun.COM by France.Sun.COM (SMI-8.6/SMI-SVR4-sd.fkk205) > id PAA19962; Wed, 12 Jan 2000 15:23:46 +0100 > Received: from noname.France.Sun.COM by bebop.France.Sun.COM (8.8.8+Sun/SMI-SVR4) id PAA15569 > for ; Wed, 12 Jan 2000 15:23:43 +0100 (MET) > Received: from france.sun.com (localhost [127.0.0.1]) > by noname.France.Sun.COM (8.9.3+Sun/8.9.1) with ESMTP id PAA01001; > Wed, 12 Jan 2000 15:23:20 +0100 (MET) > Sender: Eamonn.McManus@france.sun.com > Message-ID: <387C8E58.D662FB44@france.sun.com> > Date: Wed, 12 Jan 2000 15:23:20 +0100 > From: Eamonn McManus > Organization: Sun Microsystems, France > X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.7 sun4u) > X-Accept-Language: ga, fr, en > MIME-Version: 1.0 > To: Juergen Schoenwaelder > CC: luchuk@snmp.com, disman@dorothy.peer.com > Subject: Re: Sched/Script MIB issues > References: <200001051547.KAA05791@seymour47.SNMP.COM> <200001061114.MAA09958@henkell.ibr.cs.tu-bs.de> > Content-Type: text/plain; charset=iso-8859-1 > Content-Transfer-Encoding: 8bit > X-MIME-Autoconverted: from quoted-printable to 8bit by dorothy.bmc.com id GAA29236 > > Juergen Schoenwaelder wrote: > > >>>>> Alan Luchuk writes: > > Alan> Issue Script-02: > > >>>> o Restartable scripts > > >> Scripts that are automatically launched when an agent starts up > > >> (or some other event happens). > > Alan> I believe Eamonn has a simple and elegant solution for launching > > Alan> scripts when the DISMAN-SCRIPT-MIB agent starts. If the > > Alan> smLaunchName begins with an asterisk, the corresponding launch > > Alan> 'button' is pressed automatically when the agent starts. I have > > Alan> added this to SNMP Research's DISMAN-SCRIPT-MIB implementation. > > > > Not sure I really like this solution. I understand that it is easy to > > implement. A cleaner solution would IMHO be to have the autostart bit > > encoded somewhere else. > > I quite agree with Juergen about this. In the project I implemented the Script > MIB for, I wanted to be able to say that the implementation conformed to a > (future) standard, and in particular I set myself the constraint that I would > add no new SNMP objects. Without this constraint, I agree that overloading the > name to hold the auto-start flag is hacky. > > > The other ultimate > > solution is to define a mechanism which allows to launch scripts (or > > better perform sets on INTEGER valued objects) when a notification is > > generated or received. But this gets hairy when it comes down to > > passing notification details to the script or whatever got invoked. > > In principle this is indeed a nicer solution, but if made appropriately general > it is in danger of being very complicated, and in particular perhaps too > complicated for embedded systems. > > Éamonn > From owner-disman@dorothy.bmc.com Wed Jan 12 15:00:00 2000 Received: from tangelo.bmc.com (fw-us-hou-2.bmc.com [198.207.223.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23474 for ; Wed, 12 Jan 2000 14:59:58 -0500 (EST) Received: from dorothy.bmc.com (dorothy.bmc.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id NAA12683; Wed, 12 Jan 2000 13:59:32 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id LAA01803 for disman-list; Wed, 12 Jan 2000 11:57:13 -0800 (PST) Received: (from rpresuhn@localhost) by dorothy.peer.com (8.8.6 (PHNE_12836)/8.8.6) id LAA01797 for disman@dorothy.bmc.com; Wed, 12 Jan 2000 11:57:09 -0800 (PST) Date: Wed, 12 Jan 2000 11:57:09 -0800 (PST) From: Randy Presuhn Message-Id: <200001121957.LAA01797@dorothy.peer.com> To: disman@dorothy.peer.com Subject: Fwd: Re: Sched/Script MIB issues Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list Content-Transfer-Encoding: 7bit Hi - Another forwarded post. ------------------------------------------------------------------------ Randy Presuhn randy_presuhn@bmc.com http://www.bmc.com/ Voice: +1 408 546-1006 BMC Software, Inc. 1-3141 2141 N. First Street Fax: +1 408 965-0359 San Jose, California 95131 USA ------------------------------------------------------------------------ Any relationship between my opinions and BMC's should be coincidental. ------------------------------------------------------------------------ > Received: from tangelo.bmc.com (root@tangelo.bmc.com [172.17.7.166]) > by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id KAA00939 > for ; Wed, 12 Jan 2000 10:26:43 -0800 (PST) > Received: from fw-us-hou1.bmc.com (fw-us-hou1.bmc.com [172.17.0.250]) > by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with SMTP id MAA16177 > for ; Wed, 12 Jan 2000 12:27:07 -0600 (CST) > Received: from zsc4c002.corpwest.baynetworks.com (actually h0295.s86b1.BayNetworks.COM) > by smtprch1.nortel.com; Wed, 12 Jan 2000 12:26:44 -0600 > Received: from zsc4c012.corpwest.baynetworks.com ([134.177.2.159]) > by zsc4c002.corpwest.baynetworks.com > with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) > id ZAR19R3Y; Wed, 12 Jan 2000 10:26:43 -0800 > Received: from dlevi-pc3.corpwest.baynetworks.com (DLEVI-PC3 [134.177.69.61]) > by zsc4c012.corpwest.baynetworks.com > with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) > id CGZPRVR3; Wed, 12 Jan 2000 10:26:42 -0800 > Message-Id: <3.0.32.20000112102214.009c16f4@ZSC4C012.corpwest.baynetworks.com> > X-Sender: dlevi@ZSC4C012.corpwest.baynetworks.com > X-Mailer: Windows Eudora Pro Version 3.0 (32) > Date: Wed, 12 Jan 2000 10:22:14 -0800 > To: disman@dorothy.peer.com > From: "David Levi" > Subject: Re: Sched/Script MIB issues > Mime-Version: 1.0 > Content-Type: text/plain; charset="us-ascii" > > >Return-Path: > >Date: Wed, 12 Jan 2000 15:54:25 +0100 > >From: Juergen Schoenwaelder > >To: disman@dorothy.peer.com > >Subject: Re: Sched/Script MIB issues > >References: <200001051547.KAA05791@seymour47.SNMP.COM> > <200001061114.MAA09958@henkell.ibr.cs.tu-bs.de> > <387C8E58.D662FB44@france.sun.com> > >Sender: owner-disman@dorothy.bmc.com > >List-Id: IETF disman Working Group mailing list > >X-SMTP-HELO: tangelo.bmc.com > >X-SMTP-MAIL-FROM: owner-disman@dorothy.bmc.com > >X-SMTP-RCPT-TO: dlevi@nortelnetworks.com > >X-SMTP-PEER-INFO: fw-us-hou-2.bmc.com [198.207.223.251] > > > > > > > >>>>>> Eamonn McManus writes: > > > >Eamonn> I quite agree with Juergen about this. In the project I > >Eamonn> implemented the Script MIB for, I wanted to be able to say > >Eamonn> that the implementation conformed to a (future) standard, and > >Eamonn> in particular I set myself the constraint that I would add no > >Eamonn> new SNMP objects. Without this constraint, I agree that > >Eamonn> overloading the name to hold the auto-start flag is hacky. > > > >>> The other ultimate solution is to define a mechanism which allows > >>> to launch scripts (or better perform sets on INTEGER valued > >>> objects) when a notification is generated or received. But this > >>> gets hairy when it comes down to passing notification details to > >>> the script or whatever got invoked. > > > >Eamonn> In principle this is indeed a nicer solution, but if made > >Eamonn> appropriately general it is in danger of being very > >Eamonn> complicated, and in particular perhaps too complicated for > >Eamonn> embedded systems. > > > >Thanks for your feedback. So here is a strawman proposal: > > > >We add a new object to the smLaunchTable which controls whether the > >associated script is restarted during reboot. We make this new object > >a BITS object so that it is possible to add additional start > >conditions in the future (if we ever need to do this) and we leave a > >more general solution for this problem for future work. > > > >Let me know if there are any concerns or objections. > > A more general solution would be to add this BITs object to the > schedTable in the schedule mib, so that you can perform a set > at startup. > > -Dave > ----------------------------------------------------------------------------- > David B. Levi Nortel Networks dlevi@nortelnetworks.com > Voice: +1 865 686 0432 Fax: +1 865 686 0433 Voice Mail: +1 408 495 3622 > ----------------------------------------------------------------------------- > From owner-disman@dorothy.bmc.com Thu Jan 13 10:12:46 2000 Received: from tangelo.bmc.com (fw-us-hou-2.bmc.com [198.207.223.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19655 for ; Thu, 13 Jan 2000 10:12:37 -0500 (EST) Received: from dorothy.bmc.com (dorothy.bmc.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id JAA05948; Thu, 13 Jan 2000 09:12:13 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id HAA29091 for disman-list; Thu, 13 Jan 2000 07:03:41 -0800 (PST) Received: from tangelo.bmc.com (root@tangelo.bmc.com [172.17.7.166]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id HAA29084 for ; Thu, 13 Jan 2000 07:03:20 -0800 (PST) Received: from fw-us-hou1.bmc.com (fw-us-hou1.bmc.com [172.17.0.250]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with SMTP id JAA03022 for ; Thu, 13 Jan 2000 09:03:44 -0600 (CST) Received: from henkell.ibr.cs.tu-bs.de (schoenw@henkell [134.169.34.191]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) with ESMTP id QAA18989; Thu, 13 Jan 2000 16:03:37 +0100 (MET) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id QAA14372; Thu, 13 Jan 2000 16:03:36 +0100 Date: Thu, 13 Jan 2000 16:03:36 +0100 Message-Id: <200001131503.QAA14372@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: dlevi@nortelnetworks.com CC: disman@dorothy.peer.com In-reply-to: <200001121957.LAA01797@dorothy.peer.com> (message from Randy Presuhn on Wed, 12 Jan 2000 11:57:09 -0800 (PST)) Subject: Re: Fwd: Re: Sched/Script MIB issues References: <200001121957.LAA01797@dorothy.peer.com> Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list >>>>> David Levi writes: Dave> A more general solution would be to add this BITs object to the Dave> schedTable in the schedule mib, so that you can perform a set at Dave> startup. What are the pros and cons? + You can set an arbitrary INTEGER objects when the agent (re)starts, which is definately more than just being able to fire up scripts. - Right now, the DISMAN-SCHEDULE-MIB does periodic and calendar schedules. Putting the auto start flag into this MIBs means that it now does periodic schedules, calendar schedules and "special event" schedules, which probably goes beyond what it was designed to do. - A pure script MIB implementation now needs to implement at least a degenerated version of the DISMAN-SCHEDULE-MIB in order to auto start scripts. This is much more work and code compared to just checking a bit and kicking the script when you read the configuration. - Configuration of auto start scripts now requires to keep pointers from the DISMAN-SCHEDULE-MIB to the scripts and you have to look at two tables in order to figure out if a script will be restarted. Given the fact that the auto start feature is very cheap to implement in the smLaunchTable and that I do not really mind if we also have another more generalized way of doing the same thing, I would prefer to put the auto start bit in the smLaunchTable and to keep the DISMAN-SCHEDULE-MIB for schedules only. The other option I see is to define a MIB which triggers sets based on notification OIDs. Such a MIB will be very similar to the scheduling MIB - only the event source mechanism would be different. The only problem with this approach is that it is hard to pass event details around through a MIB. Doing this will lead to complex tables whose value is questionable. So I would propose that passing the event details around is something that is outside the scope of the MIB and depends on what got set (a script may get access to the event details through scripting language features). I am willing to write such a MIB if there is interest. But independent of this, I think we should add the auto start bit to the smLaunchTable. /js -- Juergen Schoenwaelder Technical University Braunschweig Dept. Operating Systems & Computer Networks Phone: +49 531 391 3289 Bueltenweg 74/75, 38106 Braunschweig, Germany Fax: +49 531 391 5936 From owner-disman@dorothy.bmc.com Tue Jan 18 22:45:27 2000 Received: from tangelo.bmc.com (fw-us-hou-2.bmc.com [198.207.223.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA10987 for ; Tue, 18 Jan 2000 22:45:27 -0500 (EST) Received: from dorothy.bmc.com (dorothy.bmc.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id VAA21874; Tue, 18 Jan 2000 21:45:16 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id TAA24862 for disman-list; Tue, 18 Jan 2000 19:38:49 -0800 (PST) Received: (from rpresuhn@localhost) by dorothy.peer.com (8.8.6 (PHNE_12836)/8.8.6) id TAA24856; Tue, 18 Jan 2000 19:38:45 -0800 (PST) Date: Tue, 18 Jan 2000 19:38:45 -0800 (PST) From: Randy Presuhn Message-Id: <200001190338.TAA24856@dorothy.peer.com> To: WIJNEN@vnet.ibm.com Subject: Re: disman status Cc: disman@dorothy.peer.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list Content-Transfer-Encoding: 7bit Hi Bert - > From WIJNEN@vnet.ibm.com Tue Jan 18 19:18:20 PST 2000 > Message-Id: <200001190314.WAA34334@southrelay03.raleigh.ibm.com> > Date: Wed, 19 Jan 00 04:14:32 CET > From: "Bert Wijnen" > To: rpresuhn@bmc.com > Subject: disman status > > Randy, I did see lots of email w.r.t. to the 3 disman MIB docs > that originated from Bob Stewart. I am not sure what the current > status is. Have new revs been posted. Is there WG consensus on > those new revs? Is the ball still in your hands or is it back in > mine? > > Thanks, bert Here's where we're at, after a rather productive and extended last call period: Event MIB: reviewer says OK, current draft is what we'll use. Log MIB: awaiting edits in response to reviewer comments. New draft should be ready friday 2000-01-21. That's the one we'll use. Expression MIB: reviewer says OK with one small change to make reference to Event MIB non-normative to avoid circular dependency. Have asked editor to produce updated draft. That'll be the one we'll use. I believe we have WG consensus on all three documents. It's definitely a "rough" consensus with concerns about MIB complexity, but I believe there is general agreement that we're now at the point where more operational experience would make sense before we tinker any further with these three documents. With any luck, on Friday we should have the I-D names for the "blessed" material for your to carry forward. The level of agreement is such that if the reviewers are happy, I believe the three documents should go forward in my absence. As for the remote operations document, I think we're awaiting reviewer feedback. ------------------------------------------------------------------------ Randy Presuhn randy_presuhn@bmc.com http://www.bmc.com/ Voice: +1 408 546-1006 BMC Software, Inc. 1-3141 2141 N. First Street Fax: +1 408 965-0359 San Jose, California 95131 USA ------------------------------------------------------------------------ Any relationship between my opinions and BMC's should be coincidental. ------------------------------------------------------------------------ From owner-disman@dorothy.bmc.com Fri Jan 21 22:07:42 2000 Received: from tangelo.bmc.com (fw-us-hou-2.bmc.com [198.207.223.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA21549 for ; Fri, 21 Jan 2000 22:07:41 -0500 (EST) Received: from dorothy.peer.com (dorothy.bmc.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id VAA08495; Fri, 21 Jan 2000 21:07:27 -0600 (CST) Received: (from root@localhost) by dorothy.peer.com (8.8.6 (PHNE_12836)/8.8.6) id TAA26967 for disman-list; Fri, 21 Jan 2000 19:03:26 -0800 (PST) Received: from tangelo.bmc.com (root@tangelo.bmc.com [172.17.7.166]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id TAA26962 for ; Fri, 21 Jan 2000 19:03:10 -0800 (PST) Received: from fw-us-hou1.bmc.com (fw-us-hou1.bmc.com [172.17.0.250]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with SMTP id VAA08098 for ; Fri, 21 Jan 2000 21:03:34 -0600 (CST) Received: (ramk@localhost) by itech-view2.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) id TAA26314; Fri, 21 Jan 2000 19:02:21 -0800 (PST) From: Ram Kavasseri Message-Id: <200001220302.TAA26314@itech-view2.cisco.com> Subject: draft-ietf-disman-notif-log-mib-13.txt To: internet-drafts@ietf.org Date: Fri, 21 Jan 2000 19:02:21 -0800 (PST) Cc: rpresuhn@dorothy.peer.com, dharrington@mediaone.net, disman@dorothy.peer.com X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list Content-Transfer-Encoding: 7bit Please post the attached document "draft-ietf-disman-notif-log-mib-13.txt" as an internet draft. Thank you, Ram Kavasseri Internet Draft Notification Log MIB 21 January 2000 Notification Log MIB 21 January 2000 draft-ietf-disman-notif-log-mib-13.txt Bob Stewart Cisco Systems, Inc. Ramanathan R. Kavasseri Cisco Systems, Inc. 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. Distribution of this document is unlimited. Please send comments to the Distributed Management Working Group, . Copyright Notice Copyright (C) The Internet Society (1999). All Rights Reserved. Expires 21 July 2000 [Page 1] Internet Draft Notification Log MIB 21 January 2000 1. Abstract This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for logging SNMP Notifications. 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 RFC 2119. 2. The SNMP Management Framework The SNMP Management Framework presently consists of five major components: o An overall architecture, described in RFC 2571 [RFC2571]. o Mechanisms for describing and naming objects and events for the purpose of management. The first version of this Structure of Management Information (SMI) is called SMIv1 and described in STD 16, RFC 1155 [RFC1155], STD 16, RFC 1212 [RFC1212] and RFC 1215 [RFC1215]. The second version, called SMIv2, is described in STD 58, RFC 2578 [RFC2578], RFC 2579 [RFC2579] and RFC 2580 [RFC2580]. o Message protocols for transferring management information. The first version of the SNMP message protocol is called SNMPv1 and described in STD 15, 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]. o Protocol operations for accessing management information. The first set of protocol operations and associated PDU formats is described in STD 15, RFC 1157 [RFC1157]. A second set of protocol operations and associated PDU formats is described in RFC 1905 [RFC1905]. o A set of fundamental applications described in RFC 2573 [RFC2573] and the view-based access control mechanism described in RFC 2575 [RFC2575]. Expires 21 July 2000 [Page 2] Internet Draft Notification Log MIB 21 January 2000 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 MIB. 3. Overview Systems that support SNMP often need a mechanism for recording Notification information as a hedge against lost Notifications, whether those are Traps or Informs [RFC1905] that exceed retransmission limits. This MIB therefore provides common infrastructure for other MIBs in the form of a local logging function. It is intended primarily for senders of Notifications but could be used also by receivers. Given the Notification Log MIB, individual MIBs bear less responsibility to record the transient information associated with an event against the possibility that the Notification message is lost, and applications can poll the log to verify that they have not missed important Notifications. 3.1. Environment The overall environmental concerns for the MIB are: o SNMP Engines and Contexts o Security Expires 21 July 2000 [Page 3] Internet Draft Notification Log MIB 21 January 2000 3.1.1. SNMP Engines and Contexts There are two distinct information flows from multiple notification originators that one may log. The first is the notifications that are received (from one or more SNMP engines) for logging as SNMP informs and traps. The other comprises notifications delivered to an SNMP engine at the interface to the notification originator (using a notification mechanism other than SNMP informs or traps). The latter information flow (using a notification mechanism other than SNMP informs or traps) MUST be modeled as the SNMP engine (which maintains the log) sending a notification to itself. The remainder of this section discusses the handling of the former information flow - notifications (received in the form of SNMP informs or traps) from multiple SNMP engines. As described in the SNMP architecture [RFC2571], a given system may support multiple SNMP engines operating independently of one another, each with its own SNMP engine identification. Furthermore, within the purview of a given engine there may be multiple named management contexts supporting overlapping or disjoint sets of MIB objects and Notifications. Thus, understanding a particular Notification requires knowing the SNMP engine and management context from whence it came. To provide the necessary source information for a logged Notification, the MIB includes objects to record that Notification's source SNMP engine ID and management context name. 3.1.2. Security Security for Notifications is awkward since access control for the objects in the Notification can be checked only where the Notification is created. Thus such checking is possible only for locally-generated Notifications, and even then only when security credentials are available. For the purpose of this discussion, "security credentials" means the input values for the abstract service interface function isAccessAllowed [RFC2571] and using those credentials means conceptually using that function to see that those credentials allow access to the MIB objects in question, operating as for a Notification Originator in [RFC2573]. The Notification Log MIB has the notion of a "named log." By using hierarchically structured log names and view-based access control [RFC2575] a network administrator can provide different access for different users. When an application creates a named log the security Expires 21 July 2000 [Page 4] Internet Draft Notification Log MIB 21 January 2000 credentials of the creator stay associated with that log. Hierarchically structured names encode groupings of names within the name string, starting from the left so that they work well with instance-level, view-based access control [RFC2575], for example: ops ops-admin ops-oper ops-oper-senior ops-oper-junior Network security managers designing such a naming policy SHOULD use punctuation (as in the example) to avoid the problem of a lower level name inadvertently running together with the next higher level name. A managed system with fewer resources MAY disallow the creation of named logs, providing only the default, null-named log. Such a log has no implicit security credentials for Notification object access control and Notifications are put into it with no further checking. When putting locally-generated Notifications into a named log, the managed system MUST use the security credentials associated with that log and MUST apply the same access control rules as described for a Notification Originator in [RFC2573]. The managed system SHOULD NOT apply access control when adding remotely- generated Notifications into either a named log or the default, null- named log. In those cases the security of the information in the log SHOULD be left to the normal, overall access control for the log itself. The Notification Log MIB allows applications to set the maximum number of Notifications that can be logged, using nlmConfigGlobalEntryLimit. Similarly, an application can set the maximum age using nlmConfigGlobalAgeOut, after which older Notifications MAY be timed out. Please be aware that contention between multiple applications trying to set these objects to different values MAY affect the reliability and completeness of data seen by each application, i.e. it is possible that one application may change the value of either of these objects, resulting in some Notifications being deleted before the other applications have had a chance to see them. This could be used to orchestrate a denial-of-service attack. Methods for countering such an attack are for further study. 3.2. Structure The MIB has the following sections: Expires 21 July 2000 [Page 5] Internet Draft Notification Log MIB 21 January 2000 o Configuration -- control over how much the log can hold and what Notifications are to be logged. o Statistics -- indications of logging activity. o Log -- the Notifications themselves. 3.2.1. Configuration The configuration section contains objects to manage resource use by the MIB. This section also contains a table to specify what logs exist and how they operate. Deciding which Notifications are to be logged depends on filters defined in the the snmpNotifyFilterTable in the standard SNMP Notification MIB [RFC2573] identified by the initial index (snmpNotifyFilterName) from that table. 3.2.2. Statistics The statistics section contains counters for Notifications logged and discarded, supplying a means to understand the results of log capacity configuration and resource problems. 3.2.3. Log The log contains the Notifications and the objects that came in their variable binding list, indexed by an integer that reflects when the entry was made. An application that wants to collect all logged Notifications or to know if it may have missed any can keep track of the highest index it has retrieved and start from there on its next poll, checking sysUpTime for a discontinuity that would have reset the index and perhaps have lost entries. Variables are in a table indexed by Notification index and variable index within that Notification. The values are kept as a "discriminated union," with one value object per variable. Exactly which value object is instantiated depends on the SNMP data type of the variable, with a separate object of appropriate type for each distinct SNMP data type. An application can thus reconstruct the information from the Notification PDU from what is recorded in the log. Expires 21 July 2000 [Page 6] Internet Draft Notification Log MIB 21 January 2000 3.3. Example Following is an example configuration of a named log for logging only linkUp and linkDown Notifications. In nlmConfigLogTable: nlmConfigLogFilterName.5."links" = "link-status" nlmConfigLogEntryLimit.5."links" = 0 nlmConfigLogAdminStatus.5."links" = enabled nlmConfigLogOperStatus.5."links" = operational nlmConfigLogStorageType.5."links" = nonVolatile nlmConfigLogEntryStatus.5."links" = active Note that snmpTraps is: iso.org.dod.internet.snmpV2.snmpModules.snmpMIB.snmpMIBObjects.5 Or numerically: 1.3.6.1.6.3.1.1.5 And linkDown is snmpTraps.3 and linkUp is snmpTraps.4. So to allow the two Notifications in snmpNotifyFilterTable: snmpNotifyFilterMask.11."link-status".1.3.6.1.6.3.1.1.5.3 = ''H snmpNotifyFilterType.11."link-status".1.3.6.1.6.3.1.1.5.3 = include snmpNotifyFilterStorageType.11."link-status".1.3.6.1.6.3.1.1.5.3 = nonVolatile snmpNotifyFilterRowStatus.11."link-status".1.3.6.1.6.3.1.1.5.3 = active snmpNotifyFilterMask.11."link-status".1.3.6.1.6.3.1.1.5.4 = ''H snmpNotifyFilterType.11."link-status".1.3.6.1.6.3.1.1.5.4 = include snmpNotifyFilterStorageType.11."link-status".1.3.6.1.6.3.1.1.5.4 = nonVolatile snmpNotifyFilterRowStatus.11."link-status".1.3.6.1.6.3.1.1.5.4 = active Expires 21 July 2000 [Page 7] Internet Draft Notification Log MIB 21 January 2000 4. Definitions NOTIFICATION-LOG-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, Integer32, Unsigned32, TimeTicks, Counter32, Counter64, IpAddress, Opaque, mib-2 FROM SNMPv2-SMI TimeStamp, DateAndTime, StorageType, RowStatus FROM SNMPv2-TC SnmpAdminString, SnmpEngineID FROM SNMP-FRAMEWORK-MIB MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF; notificationLogMIB MODULE-IDENTITY LAST-UPDATED "9910220000Z" ORGANIZATION "IETF Distributed Management Working Group" CONTACT-INFO "Ramanathan Kavasseri Cisco Systems, Inc. 170 West Tasman Drive, San Jose CA 95134-1706. Phone: +1 408 527 2446 Email: ramk@cisco.com" DESCRIPTION "The MIB module for logging SNMP Notifications, that is, Traps and Informs." -- Revision History REVISION "9910220000Z" -- 22 October 1999 DESCRIPTION "This is the initial version of this MIB. Published as RFC xxxxx" ::= { mib-2 xx } -- final assignment by IANA at publication time notificationLogMIBObjects OBJECT IDENTIFIER ::= { notificationLogMIB 1 } nlmConfig OBJECT IDENTIFIER ::= { notificationLogMIBObjects 1 } nlmStats OBJECT IDENTIFIER ::= { notificationLogMIBObjects 2 } nlmLog OBJECT IDENTIFIER ::= { notificationLogMIBObjects 3 } -- -- Configuration Section -- nlmConfigGlobalEntryLimit OBJECT-TYPE Expires 21 July 2000 [Page 8] Internet Draft Notification Log MIB 21 January 2000 SYNTAX Unsigned32 MAX-ACCESS read-write STATUS current DESCRIPTION "The maximum number of notification entries that may be held in nlmLogTable for all nlmLogNames added together. A particular setting does not guarantee that much data can be held. If an application changes the limit while there are Notifications in the log, the oldest Notifications MUST be discarded to bring the log down to the new limit - thus the value of nlmConfigGlobalEntryLimit MUST take precedence over the values of nlmConfigGlobalAgeOut and nlmConfigLogEntryLimit, even if the Notification being discarded has been present for fewer minutes than the value of nlmConfigGlobalAgeOut, or if the named log has fewer entries than that specified in nlmConfigLogEntryLimit. A value of 0 means no limit. Please be aware that contention between multiple managers trying to set this object to different values MAY affect the reliability and completeness of data seen by each manager." DEFVAL { 0 } ::= { nlmConfig 1 } nlmConfigGlobalAgeOut OBJECT-TYPE SYNTAX Unsigned32 UNITS "minutes" MAX-ACCESS read-write STATUS current DESCRIPTION "The number of minutes a Notification SHOULD be kept in a log before it is automatically removed. If an application changes the value of nlmConfigGlobalAgeOut, Notifications older than the new time MAY be discarded to meet the new time. A value of 0 means no age out. Please be aware that contention between multiple managers trying to set this object to different values MAY affect the reliability and completeness of data seen by each manager." DEFVAL { 1440 } -- 24 hours Expires 21 July 2000 [Page 9] Internet Draft Notification Log MIB 21 January 2000 ::= { nlmConfig 2 } -- -- Basic Log Configuration Table -- nlmConfigLogTable OBJECT-TYPE SYNTAX SEQUENCE OF NlmConfigLogEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of logging control entries." ::= { nlmConfig 3 } nlmConfigLogEntry OBJECT-TYPE SYNTAX NlmConfigLogEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A logging control entry. Depending on the entry's storage type entries may be supplied by the system or created and deleted by applications using nlmConfigLogEntryStatus." INDEX { nlmLogName } ::= { nlmConfigLogTable 1 } NlmConfigLogEntry ::= SEQUENCE { nlmLogName SnmpAdminString, nlmConfigLogFilterName SnmpAdminString, nlmConfigLogEntryLimit Unsigned32, nlmConfigLogAdminStatus INTEGER, nlmConfigLogOperStatus INTEGER, nlmConfigLogStorageType StorageType, nlmConfigLogEntryStatus RowStatus } nlmLogName OBJECT-TYPE SYNTAX SnmpAdminString (SIZE(0..32)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The name of the log. An implementation may allow multiple named logs, up to some implementation-specific limit (which may be none). A Expires 21 July 2000 [Page 10] Internet Draft Notification Log MIB 21 January 2000 zero-length log name is reserved for creation and deletion by the managed system, and MUST be used as the default log name by systems that do not support named logs." ::= { nlmConfigLogEntry 1 } nlmConfigLogFilterName OBJECT-TYPE SYNTAX SnmpAdminString (SIZE(0..32)) MAX-ACCESS read-create STATUS current DESCRIPTION "A value of snmpNotifyFilterProfileName as used as an index into the snmpNotifyFilterTable in the SNMP Notification MIB, specifying the locally or remotely originated Notifications to be filtered out and not logged in this log. A zero-length value or a name that does not identify an existing entry in snmpNotifyFilterTable indicate no Notifications are to be logged in this log." DEFVAL { ''H } ::= { nlmConfigLogEntry 2 } nlmConfigLogEntryLimit OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-create STATUS current DESCRIPTION "The maximum number of notification entries that can be held in nlmLogTable for this named log. A particular setting does not guarantee that that much data can be held. If an application changes the limit while there are Notifications in the log, the oldest Notifications are discarded to bring the log down to the new limit. A value of 0 indicates no limit. Please be aware that contention between multiple managers trying to set this object to different values MAY affect the reliability and completeness of data seen by each manager." DEFVAL { 0 } ::= { nlmConfigLogEntry 3 } nlmConfigLogAdminStatus OBJECT-TYPE SYNTAX INTEGER { enabled(1), disabled(2) } MAX-ACCESS read-create Expires 21 July 2000 [Page 11] Internet Draft Notification Log MIB 21 January 2000 STATUS current DESCRIPTION "Control to enable or disable the log without otherwise disturbing the log's entry. Please be aware that contention between multiple managers trying to set this object to different values MAY affect the reliability and completeness of data seen by each manager." DEFVAL { enabled } ::= { nlmConfigLogEntry 4 } nlmConfigLogOperStatus OBJECT-TYPE SYNTAX INTEGER { disabled(1), operational(2), noFilter(3) } MAX-ACCESS read-only STATUS current DESCRIPTION "The operational status of this log: disabled administratively disabled operational administratively enabled and working noFilter administratively enabled but either nlmConfigLogFilterName is zero length or does not name an existing entry in snmpNotifyFilterTable" ::= { nlmConfigLogEntry 5 } nlmConfigLogStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create STATUS current DESCRIPTION "The storage type of this conceptual row." ::= { nlmConfigLogEntry 6 } nlmConfigLogEntryStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "Control for creating and deleting entries. Entries may be modified while active. For non-null-named logs, the managed system records the security Expires 21 July 2000 [Page 12] Internet Draft Notification Log MIB 21 January 2000 credentials from the request that sets nlmConfigLogStatus to 'active' and uses that identity to apply access control to the objects in the Notification to decide if that Notification may be logged." ::= { nlmConfigLogEntry 7 } -- -- Statistics Section -- nlmStatsGlobalNotificationsLogged OBJECT-TYPE SYNTAX Counter32 UNITS "notifications" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Notifications put into the nlmLogTable. This counts a Notification once for each log entry, so a Notification put into multiple logs is counted multiple times." ::= { nlmStats 1 } nlmStatsGlobalNotificationsBumped OBJECT-TYPE SYNTAX Counter32 UNITS "notifications" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of log entries discarded to make room for a new entry due to lack of resources or the value of nlmConfigGlobalEntryLimit or nlmConfigLogEntryLimit. This does not include entries discarded due to the value of nlmConfigGlobalAgeOut." ::= { nlmStats 2 } -- -- Log Statistics Table -- nlmStatsLogTable OBJECT-TYPE SYNTAX SEQUENCE OF NlmStatsLogEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of Notification log statistics entries." ::= { nlmStats 3 } Expires 21 July 2000 [Page 13] Internet Draft Notification Log MIB 21 January 2000 nlmStatsLogEntry OBJECT-TYPE SYNTAX NlmStatsLogEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A Notification log statistics entry." AUGMENTS { nlmConfigLogEntry } ::= { nlmStatsLogTable 1 } NlmStatsLogEntry ::= SEQUENCE { nlmStatsLogNotificationsLogged Counter32, nlmStatsLogNotificationsBumped Counter32 } nlmStatsLogNotificationsLogged OBJECT-TYPE SYNTAX Counter32 UNITS "notifications" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Notifications put in this named log." ::= { nlmStatsLogEntry 1 } nlmStatsLogNotificationsBumped OBJECT-TYPE SYNTAX Counter32 UNITS "notifications" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of log entries discarded from this named log to make room for a new entry due to lack of resources or the value of nlmConfigGlobalEntryLimit or nlmConfigLogEntryLimit. This does not include entries discarded due to the value of nlmConfigGlobalAgeOut." ::= { nlmStatsLogEntry 2 } -- -- Log Section -- -- -- Log Table -- Expires 21 July 2000 [Page 14] Internet Draft Notification Log MIB 21 January 2000 nlmLogTable OBJECT-TYPE SYNTAX SEQUENCE OF NlmLogEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of Notification log entries. It is an implementation-specific matter whether entries in this table are preserved across initializations of the management system. In general one would expect that they are not. Note that keeping entries across initializations of the management system leads to some confusion with counters and TimeStamps, since both of those are based on sysUpTime, which resets on management initialization. In this situation, counters apply only after the reset and nlmLogTime for entries made before the reset SHOULD be set to 0." ::= { nlmLog 1 } nlmLogEntry OBJECT-TYPE SYNTAX NlmLogEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A Notification log entry. Entries appear in this table when Notifications occur and pass filtering by nlmConfigLogFilterName and access control. They are removed to make way for new entries due to lack of resources or the values of nlmConfigGlobalEntryLimit, nlmConfigGlobalAgeOut, or nlmConfigLogEntryLimit. If adding an entry would exceed nlmConfigGlobalEntryLimit or system resources in general, the oldest entry in any log SHOULD be removed to make room for the new one. If adding an entry would exceed nlmConfigLogEntryLimit the oldest entry in that log SHOULD be removed to make room for the new one. Before the managed system puts a locally-generated Notification into a non-null-named log it assures that the creator of the log has access to the information in the Notification. If not it does not log that Notification in that log." INDEX { nlmLogName, nlmLogIndex } ::= { nlmLogTable 1 } Expires 21 July 2000 [Page 15] Internet Draft Notification Log MIB 21 January 2000 NlmLogEntry ::= SEQUENCE { nlmLogIndex Unsigned32, nlmLogTime TimeStamp, nlmLogDateAndTime DateAndTime, nlmLogEngineID SnmpEngineID, nlmLogEngineAddress IpAddress, nlmLogContextEngineID SnmpEngineID, nlmLogContextName SnmpAdminString, nlmLogNotificationID OBJECT IDENTIFIER } nlmLogIndex OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "A monotonically increasing integer for the sole purpose of indexing entries within the named log. When it reaches the maximum value, an extremely unlikely event, the agent wraps the value back to 1 and MUST flush existing entries." ::= { nlmLogEntry 1 } nlmLogTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime when the entry was placed in the log. If the entry occurred before the most recent management system initialization this object value MUST be set to zero." ::= { nlmLogEntry 2 } nlmLogDateAndTime OBJECT-TYPE SYNTAX DateAndTime MAX-ACCESS read-only STATUS current DESCRIPTION "The local date and time when the entry was logged, instantiated only by systems that have date and time capability." ::= { nlmLogEntry 3 } nlmLogEngineID OBJECT-TYPE SYNTAX SnmpEngineID MAX-ACCESS read-only STATUS current Expires 21 July 2000 [Page 16] Internet Draft Notification Log MIB 21 January 2000 DESCRIPTION "The identification of the SNMP engine at which the Notification originated. If the log can contain Notifications from only one engine or the Trap is in SNMPv1 format, this object is not instantiated." ::= { nlmLogEntry 4 } nlmLogEngineAddress OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS read-only STATUS current DESCRIPTION "The IP Address of the SNMP engine from which the Notification was received. This is used to identify the source of an SNMPv1 trap, since an nlmLogEngineId cannot be extracted from the SNMPv1 trap pdu. This object MUST always be instantiated, even if the log can contain Notifications from only one engine. Please be aware that the nlmLogEngineAddress may not uniquely identify the SNMP engine from which the Notification was received. For example, if an SNMP engine uses DHCP or NAT to obtain ip addresses, the address it uses may be shared with other network devices, and hence will not uniquely identify the SNMP engine." ::= { nlmLogEntry 5 } nlmLogContextEngineID OBJECT-TYPE SYNTAX SnmpEngineID MAX-ACCESS read-only STATUS current DESCRIPTION "The contextEngineID within an administrative domain (indicated by nlmEngineID) that uniquely identifies an SNMP entity that may realize an instance of a context with a particular contextName. If the log originates from an administrative domain with only one contextEngineID, or the Trap is from an SNMPv1 system, this object SHOULD NOT be instantiated." ::= { nlmLogEntry 6 } nlmLogContextName OBJECT-TYPE Expires 21 July 2000 [Page 17] Internet Draft Notification Log MIB 21 January 2000 SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION "The name of the SNMP MIB context from which the Notification came. For SNMPv1 Traps this is the community string from the Trap. If the Notification's source SNMP engine is known not to support multiple contexts, this object MAY not be instantiated." ::= { nlmLogEntry 7 } nlmLogNotificationID OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-only STATUS current DESCRIPTION "The NOTIFICATION-TYPE object identifer of the Notification that occurred." ::= { nlmLogEntry 8 } -- -- Log Variable Table -- nlmLogVariableTable OBJECT-TYPE SYNTAX SEQUENCE OF NlmLogVariableEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of variables to go with Notification log entries." ::= { nlmLog 2 } nlmLogVariableEntry OBJECT-TYPE SYNTAX NlmLogVariableEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A Notification log entry variable. Entries appear in this table when there are variables in the varbind list of a Notification in nlmLogTable." INDEX { nlmLogName, nlmLogIndex, nlmLogVariableIndex } ::= { nlmLogVariableTable 1 } NlmLogVariableEntry ::= SEQUENCE { Expires 21 July 2000 [Page 18] Internet Draft Notification Log MIB 21 January 2000 nlmLogVariableIndex Unsigned32, nlmLogVariableID OBJECT IDENTIFIER, nlmLogVariableValueType INTEGER, nlmLogVariableCounter32Val Counter32, nlmLogVariableUnsigned32Val Unsigned32, nlmLogVariableTimeTicksVal TimeTicks, nlmLogVariableInteger32Val Integer32, nlmLogVariableOctetStringVal OCTET STRING, nlmLogVariableIpAddressVal IpAddress, nlmLogVariableOidVal OBJECT IDENTIFIER, nlmLogVariableCounter64Val Counter64, nlmLogVariableOpaqueVal Opaque } nlmLogVariableIndex OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "A monotonically increasing integer, starting at 1 for a given nlmLogIndex, for indexing variables within the logged Notification." ::= { nlmLogVariableEntry 1 } nlmLogVariableID OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-only STATUS current DESCRIPTION "The variable's object identifier." ::= { nlmLogVariableEntry 2 } nlmLogVariableValueType OBJECT-TYPE SYNTAX INTEGER { counter32(1), unsigned32(2), timeTicks(3), integer32(4), ipAddress(5), octetString(6), objectId(7), counter64(8), opaque(9) } MAX-ACCESS read-only STATUS current DESCRIPTION "The type of the value. One and only one of the value objects that follow must be instantiated, based on this type." ::= { nlmLogVariableEntry 3 } nlmLogVariableCounter32Val OBJECT-TYPE SYNTAX Counter32 Expires 21 July 2000 [Page 19] Internet Draft Notification Log MIB 21 January 2000 MAX-ACCESS read-only STATUS current DESCRIPTION "The value when nlmLogVariableType is 'counter32'." ::= { nlmLogVariableEntry 4 } nlmLogVariableUnsigned32Val OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "The value when nlmLogVariableType is 'unsigned32'." ::= { nlmLogVariableEntry 5 } nlmLogVariableTimeTicksVal OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS current DESCRIPTION "The value when nlmLogVariableType is 'timeTicks'." ::= { nlmLogVariableEntry 6 } nlmLogVariableInteger32Val OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "The value when nlmLogVariableType is 'integer32'." ::= { nlmLogVariableEntry 7 } nlmLogVariableOctetStringVal OBJECT-TYPE SYNTAX OCTET STRING MAX-ACCESS read-only STATUS current DESCRIPTION "The value when nlmLogVariableType is 'octetString'." ::= { nlmLogVariableEntry 8 } nlmLogVariableIpAddressVal OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS read-only STATUS current DESCRIPTION "The value when nlmLogVariableType is 'ipAddress'." ::= { nlmLogVariableEntry 9 } Expires 21 July 2000 [Page 20] Internet Draft Notification Log MIB 21 January 2000 nlmLogVariableOidVal OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-only STATUS current DESCRIPTION "The value when nlmLogVariableType is 'objectId'." ::= { nlmLogVariableEntry 10 } nlmLogVariableCounter64Val OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The value when nlmLogVariableType is 'counter64'." ::= { nlmLogVariableEntry 11 } nlmLogVariableOpaqueVal OBJECT-TYPE SYNTAX Opaque MAX-ACCESS read-only STATUS current DESCRIPTION "The value when nlmLogVariableType is 'opaque'." ::= { nlmLogVariableEntry 12 } -- -- Conformance -- notificationLogMIBConformance OBJECT IDENTIFIER ::= { notificationLogMIB 3 } notificationLogMIBCompliances OBJECT IDENTIFIER ::= { notificationLogMIBConformance 1 } notificationLogMIBGroups OBJECT IDENTIFIER ::= { notificationLogMIBConformance 2 } -- Compliance notificationLogMIBCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for entities which implement the Notification Log MIB." MODULE -- this module MANDATORY-GROUPS { Expires 21 July 2000 [Page 21] Internet Draft Notification Log MIB 21 January 2000 notificationLogConfigGroup, notificationLogStatsGroup, notificationLogLogGroup } OBJECT nlmConfigGlobalEntryLimit SYNTAX Unsigned32 (0..4294967295) MIN-ACCESS read-only DESCRIPTION "Implementations may choose a limit and not allow it to be changed or may enforce an upper or lower bound on the limit." OBJECT nlmConfigLogEntryLimit SYNTAX Unsigned32 (0..4294967295) MIN-ACCESS read-only DESCRIPTION "Implementations may choose a limit and not allow it to be changed or may enforce an upper or lower bound on the limit." OBJECT nlmConfigLogEntryStatus MIN-ACCESS read-only DESCRIPTION "Implementations may disallow the creation of named logs." GROUP notificationLogDateGroup DESCRIPTION "This group is mandatory on systems that keep wall clock date and time and should not be implemented on systems that do not have a wall clock date." ::= { notificationLogMIBCompliances 1 } -- Units of Conformance notificationLogConfigGroup OBJECT-GROUP OBJECTS { nlmConfigGlobalEntryLimit, nlmConfigGlobalAgeOut, nlmConfigLogFilterName, nlmConfigLogEntryLimit, nlmConfigLogAdminStatus, nlmConfigLogOperStatus, nlmConfigLogStorageType, Expires 21 July 2000 [Page 22] Internet Draft Notification Log MIB 21 January 2000 nlmConfigLogEntryStatus } STATUS current DESCRIPTION "Notification log configuration management." ::= { notificationLogMIBGroups 1 } notificationLogStatsGroup OBJECT-GROUP OBJECTS { nlmStatsGlobalNotificationsLogged, nlmStatsGlobalNotificationsBumped, nlmStatsLogNotificationsLogged, nlmStatsLogNotificationsBumped } STATUS current DESCRIPTION "Notification log statistics." ::= { notificationLogMIBGroups 2 } notificationLogLogGroup OBJECT-GROUP OBJECTS { nlmLogTime, nlmLogEngineID, nlmLogEngineAddress, nlmLogContextEngineID, nlmLogContextName, nlmLogNotificationID, nlmLogVariableID, nlmLogVariableValueType, nlmLogVariableCounter32Val, nlmLogVariableUnsigned32Val, nlmLogVariableTimeTicksVal, nlmLogVariableInteger32Val, nlmLogVariableOctetStringVal, nlmLogVariableIpAddressVal, nlmLogVariableOidVal, nlmLogVariableCounter64Val, nlmLogVariableOpaqueVal } STATUS current DESCRIPTION "Notification log data." ::= { notificationLogMIBGroups 3 } Expires 21 July 2000 [Page 23] Internet Draft Notification Log MIB 21 January 2000 notificationLogDateGroup OBJECT-GROUP OBJECTS { nlmLogDateAndTime } STATUS current DESCRIPTION "Conditionally mandatory notification log data." ::= { notificationLogMIBGroups 4 } END Expires 21 July 2000 [Page 24] Internet Draft Notification Log MIB 21 January 2000 5. 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. Expires 21 July 2000 [Page 25] Internet Draft Notification Log MIB 21 January 2000 6. References [RFC2571] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing SNMP Management Frameworks", RFC 2571, April 1999 [RFC1155] Rose, M., and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based Internets", STD 16, RFC 1155, May 1990 [RFC1212] Rose, M., and K. McCloghrie, "Concise MIB Definitions", STD 16, RFC 1212, March 1991 [RFC1215] M. Rose, "A Convention for Defining Traps for use with the SNMP", RFC 1215, March 1991 [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., and S. Waldbusser, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999 [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999 [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., and S. Waldbusser, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999 [RFC1157] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network Management Protocol", STD 15, RFC 1157, May 1990. [RFC1901] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Introduction to Community-based SNMPv2", RFC 1901, January 1996. [RFC1906] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Transport Mappings for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1906, January 1996. [RFC2572] Case, J., Harrington D., Presuhn R., and B. Wijnen, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)", RFC 2572, April 1999 [RFC2574] Blumenthal, U., and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Expires 21 July 2000 [Page 26] Internet Draft Notification Log MIB 21 January 2000 Protocol (SNMPv3)", RFC 2574, April 1999 [RFC1905] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Protocol Operations for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1905, January 1996. [RFC2573] Levi, D., Meyer, P., and B. Stewart, "SNMPv3 Applications", RFC 2573, April 1999 [RFC2575] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", RFC 2575, April 1999 [RFC2570] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction to Version 3 of the Internet-standard Network Management Framework", RFC 2570, April 1999 [RFC1903] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Coexistence between Version 1 and version 2 of the Internet-standard Network Management Framework", RFC 1903, January 1996. Expires 21 July 2000 [Page 27] Internet Draft Notification Log MIB 21 January 2000 7. Security Considerations Security issues are discussed in Section 3.1.2. 8. Author's Address Bob Stewart Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134-1706 U.S.A. Ramanathan Kavasseri Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134-1706 U.S.A. Phone: +1 408 527 2446 Email: ramk@cisco.com Expires 21 July 2000 [Page 28] Internet Draft Notification Log MIB 21 January 2000 9. Full Copyright Statement Copyright (C) The Internet Society (1999). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Expires 21 July 2000 [Page 29] Internet Draft Notification Log MIB 21 January 2000 Table of Contents 1 Abstract ........................................................ 2 2 The SNMP Management Framework ................................... 2 3 Overview ........................................................ 3 3.1 Environment ................................................... 3 3.1.1 SNMP Engines and Contexts ................................... 4 3.1.2 Security .................................................... 4 3.2 Structure ..................................................... 5 3.2.1 Configuration ............................................... 6 3.2.2 Statistics .................................................. 6 3.2.3 Log ......................................................... 6 3.3 Example ....................................................... 7 4 Definitions ..................................................... 8 5 Intellectual Property ........................................... 25 6 References ...................................................... 26 7 Security Considerations ......................................... 28 8 Author's Address ................................................ 28 9 Full Copyright Statement ........................................ 29 Expires 21 July 2000 [Page 30] From owner-disman@dorothy.bmc.com Fri Jan 21 22:24:11 2000 Received: from tangelo.bmc.com (fw-us-hou-2.bmc.com [198.207.223.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA21615 for ; Fri, 21 Jan 2000 22:24:10 -0500 (EST) Received: from dorothy.bmc.com (dorothy.bmc.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id VAA10658; Fri, 21 Jan 2000 21:24:08 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id TAA27017 for disman-list; Fri, 21 Jan 2000 19:23:28 -0800 (PST) Received: from tangelo.bmc.com (root@tangelo.bmc.com [172.17.7.166]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id TAA27011; Fri, 21 Jan 2000 19:23:13 -0800 (PST) Received: from fw-us-hou1.bmc.com (fw-us-hou1.bmc.com [172.17.0.250]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with SMTP id VAA10581; Fri, 21 Jan 2000 21:23:37 -0600 (CST) Received: (ramk@localhost) by itech-view2.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) id TAA27985; Fri, 21 Jan 2000 19:23:05 -0800 (PST) From: Ram Kavasseri Message-Id: <200001220323.TAA27985@itech-view2.cisco.com> Subject: draft-ietf-disman-notif-log-mib-14.txt To: internet-drafts@ietf.org Date: Fri, 21 Jan 2000 19:23:05 -0800 (PST) Cc: rpresuhn@dorothy.peer.com, dharrington@mediaone.net, disman@dorothy.peer.com X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list Content-Transfer-Encoding: 7bit Please accept the attached document "draft-ietf-disman-notif-log-mib-14.txt" for publication as an internet draft. Thanks, Ram Internet Draft Notification Log MIB 21 January 2000 Notification Log MIB 21 January 2000 draft-ietf-disman-notif-log-mib-14.txt Bob Stewart Cisco Systems, Inc. Ramanathan R. Kavasseri Cisco Systems, Inc. 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. Distribution of this document is unlimited. Please send comments to the Distributed Management Working Group, . Copyright Notice Copyright (C) The Internet Society (1999). All Rights Reserved. Expires 21 July 2000 [Page 1] Internet Draft Notification Log MIB 21 January 2000 1. Abstract This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for logging SNMP Notifications. 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 RFC 2119. 2. The SNMP Management Framework The SNMP Management Framework presently consists of five major components: o An overall architecture, described in RFC 2571 [RFC2571]. o Mechanisms for describing and naming objects and events for the purpose of management. The first version of this Structure of Management Information (SMI) is called SMIv1 and described in STD 16, RFC 1155 [RFC1155], STD 16, RFC 1212 [RFC1212] and RFC 1215 [RFC1215]. The second version, called SMIv2, is described in STD 58, RFC 2578 [RFC2578], RFC 2579 [RFC2579] and RFC 2580 [RFC2580]. o Message protocols for transferring management information. The first version of the SNMP message protocol is called SNMPv1 and described in STD 15, 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]. o Protocol operations for accessing management information. The first set of protocol operations and associated PDU formats is described in STD 15, RFC 1157 [RFC1157]. A second set of protocol operations and associated PDU formats is described in RFC 1905 [RFC1905]. o A set of fundamental applications described in RFC 2573 [RFC2573] and the view-based access control mechanism described in RFC 2575 [RFC2575]. Expires 21 July 2000 [Page 2] Internet Draft Notification Log MIB 21 January 2000 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 MIB. 3. Overview Systems that support SNMP often need a mechanism for recording Notification information as a hedge against lost Notifications, whether those are Traps or Informs [RFC1905] that exceed retransmission limits. This MIB therefore provides common infrastructure for other MIBs in the form of a local logging function. It is intended primarily for senders of Notifications but could be used also by receivers. Given the Notification Log MIB, individual MIBs bear less responsibility to record the transient information associated with an event against the possibility that the Notification message is lost, and applications can poll the log to verify that they have not missed important Notifications. 3.1. Environment The overall environmental concerns for the MIB are: o SNMP Engines and Contexts o Security Expires 21 July 2000 [Page 3] Internet Draft Notification Log MIB 21 January 2000 3.1.1. SNMP Engines and Contexts There are two distinct information flows from multiple notification originators that one may log. The first is the notifications that are received (from one or more SNMP engines) for logging as SNMP informs and traps. The other comprises notifications delivered to an SNMP engine at the interface to the notification originator (using a notification mechanism other than SNMP informs or traps). The latter information flow (using a notification mechanism other than SNMP informs or traps) MUST be modeled as the SNMP engine (which maintains the log) sending a notification to itself. The remainder of this section discusses the handling of the former information flow - notifications (received in the form of SNMP informs or traps) from multiple SNMP engines. As described in the SNMP architecture [RFC2571], a given system may support multiple SNMP engines operating independently of one another, each with its own SNMP engine identification. Furthermore, within the purview of a given engine there may be multiple named management contexts supporting overlapping or disjoint sets of MIB objects and Notifications. Thus, understanding a particular Notification requires knowing the SNMP engine and management context from whence it came. To provide the necessary source information for a logged Notification, the MIB includes objects to record that Notification's source SNMP engine ID and management context name. 3.1.2. Security Security for Notifications is awkward since access control for the objects in the Notification can be checked only where the Notification is created. Thus such checking is possible only for locally-generated Notifications, and even then only when security credentials are available. For the purpose of this discussion, "security credentials" means the input values for the abstract service interface function isAccessAllowed [RFC2571] and using those credentials means conceptually using that function to see that those credentials allow access to the MIB objects in question, operating as for a Notification Originator in [RFC2573]. The Notification Log MIB has the notion of a "named log." By using hierarchically structured log names and view-based access control [RFC2575] a network administrator can provide different access for different users. When an application creates a named log the security Expires 21 July 2000 [Page 4] Internet Draft Notification Log MIB 21 January 2000 credentials of the creator stay associated with that log. Hierarchically structured names encode groupings of names within the name string, starting from the left so that they work well with instance-level, view-based access control [RFC2575], for example: ops ops-admin ops-oper ops-oper-senior ops-oper-junior Network security managers designing such a naming policy SHOULD use punctuation (as in the example) to avoid the problem of a lower level name inadvertently running together with the next higher level name. A managed system with fewer resources MAY disallow the creation of named logs, providing only the default, null-named log. Such a log has no implicit security credentials for Notification object access control and Notifications are put into it with no further checking. When putting locally-generated Notifications into a named log, the managed system MUST use the security credentials associated with that log and MUST apply the same access control rules as described for a Notification Originator in [RFC2573]. The managed system SHOULD NOT apply access control when adding remotely- generated Notifications into either a named log or the default, null- named log. In those cases the security of the information in the log SHOULD be left to the normal, overall access control for the log itself. The Notification Log MIB allows applications to set the maximum number of Notifications that can be logged, using nlmConfigGlobalEntryLimit. Similarly, an application can set the maximum age using nlmConfigGlobalAgeOut, after which older Notifications MAY be timed out. Please be aware that contention between multiple applications trying to set these objects to different values MAY affect the reliability and completeness of data seen by each application, i.e. it is possible that one application may change the value of either of these objects, resulting in some Notifications being deleted before the other applications have had a chance to see them. This could be used to orchestrate a denial-of-service attack. Methods for countering such an attack are for further study. 3.2. Structure The MIB has the following sections: Expires 21 July 2000 [Page 5] Internet Draft Notification Log MIB 21 January 2000 o Configuration -- control over how much the log can hold and what Notifications are to be logged. o Statistics -- indications of logging activity. o Log -- the Notifications themselves. 3.2.1. Configuration The configuration section contains objects to manage resource use by the MIB. This section also contains a table to specify what logs exist and how they operate. Deciding which Notifications are to be logged depends on filters defined in the the snmpNotifyFilterTable in the standard SNMP Notification MIB [RFC2573] identified by the initial index (snmpNotifyFilterName) from that table. 3.2.2. Statistics The statistics section contains counters for Notifications logged and discarded, supplying a means to understand the results of log capacity configuration and resource problems. 3.2.3. Log The log contains the Notifications and the objects that came in their variable binding list, indexed by an integer that reflects when the entry was made. An application that wants to collect all logged Notifications or to know if it may have missed any can keep track of the highest index it has retrieved and start from there on its next poll, checking sysUpTime for a discontinuity that would have reset the index and perhaps have lost entries. Variables are in a table indexed by Notification index and variable index within that Notification. The values are kept as a "discriminated union," with one value object per variable. Exactly which value object is instantiated depends on the SNMP data type of the variable, with a separate object of appropriate type for each distinct SNMP data type. An application can thus reconstruct the information from the Notification PDU from what is recorded in the log. Expires 21 July 2000 [Page 6] Internet Draft Notification Log MIB 21 January 2000 3.3. Example Following is an example configuration of a named log for logging only linkUp and linkDown Notifications. In nlmConfigLogTable: nlmConfigLogFilterName.5."links" = "link-status" nlmConfigLogEntryLimit.5."links" = 0 nlmConfigLogAdminStatus.5."links" = enabled nlmConfigLogOperStatus.5."links" = operational nlmConfigLogStorageType.5."links" = nonVolatile nlmConfigLogEntryStatus.5."links" = active Note that snmpTraps is: iso.org.dod.internet.snmpV2.snmpModules.snmpMIB.snmpMIBObjects.5 Or numerically: 1.3.6.1.6.3.1.1.5 And linkDown is snmpTraps.3 and linkUp is snmpTraps.4. So to allow the two Notifications in snmpNotifyFilterTable: snmpNotifyFilterMask.11."link-status".1.3.6.1.6.3.1.1.5.3 = ''H snmpNotifyFilterType.11."link-status".1.3.6.1.6.3.1.1.5.3 = include snmpNotifyFilterStorageType.11."link-status".1.3.6.1.6.3.1.1.5.3 = nonVolatile snmpNotifyFilterRowStatus.11."link-status".1.3.6.1.6.3.1.1.5.3 = active snmpNotifyFilterMask.11."link-status".1.3.6.1.6.3.1.1.5.4 = ''H snmpNotifyFilterType.11."link-status".1.3.6.1.6.3.1.1.5.4 = include snmpNotifyFilterStorageType.11."link-status".1.3.6.1.6.3.1.1.5.4 = nonVolatile snmpNotifyFilterRowStatus.11."link-status".1.3.6.1.6.3.1.1.5.4 = active Expires 21 July 2000 [Page 7] Internet Draft Notification Log MIB 21 January 2000 4. Definitions NOTIFICATION-LOG-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, Integer32, Unsigned32, TimeTicks, Counter32, Counter64, IpAddress, Opaque, mib-2 FROM SNMPv2-SMI TimeStamp, DateAndTime, StorageType, RowStatus FROM SNMPv2-TC SnmpAdminString, SnmpEngineID FROM SNMP-FRAMEWORK-MIB MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF; notificationLogMIB MODULE-IDENTITY LAST-UPDATED "9910220000Z" ORGANIZATION "IETF Distributed Management Working Group" CONTACT-INFO "Ramanathan Kavasseri Cisco Systems, Inc. 170 West Tasman Drive, San Jose CA 95134-1706. Phone: +1 408 527 2446 Email: ramk@cisco.com" DESCRIPTION "The MIB module for logging SNMP Notifications, that is, Traps and Informs." -- Revision History REVISION "9910220000Z" -- 22 October 1999 DESCRIPTION "This is the initial version of this MIB. Published as RFC xxxxx" ::= { mib-2 xx } -- final assignment by IANA at publication time notificationLogMIBObjects OBJECT IDENTIFIER ::= { notificationLogMIB 1 } nlmConfig OBJECT IDENTIFIER ::= { notificationLogMIBObjects 1 } nlmStats OBJECT IDENTIFIER ::= { notificationLogMIBObjects 2 } nlmLog OBJECT IDENTIFIER ::= { notificationLogMIBObjects 3 } -- -- Configuration Section -- nlmConfigGlobalEntryLimit OBJECT-TYPE Expires 21 July 2000 [Page 8] Internet Draft Notification Log MIB 21 January 2000 SYNTAX Unsigned32 MAX-ACCESS read-write STATUS current DESCRIPTION "The maximum number of notification entries that may be held in nlmLogTable for all nlmLogNames added together. A particular setting does not guarantee that much data can be held. If an application changes the limit while there are Notifications in the log, the oldest Notifications MUST be discarded to bring the log down to the new limit - thus the value of nlmConfigGlobalEntryLimit MUST take precedence over the values of nlmConfigGlobalAgeOut and nlmConfigLogEntryLimit, even if the Notification being discarded has been present for fewer minutes than the value of nlmConfigGlobalAgeOut, or if the named log has fewer entries than that specified in nlmConfigLogEntryLimit. A value of 0 means no limit. Please be aware that contention between multiple managers trying to set this object to different values MAY affect the reliability and completeness of data seen by each manager." DEFVAL { 0 } ::= { nlmConfig 1 } nlmConfigGlobalAgeOut OBJECT-TYPE SYNTAX Unsigned32 UNITS "minutes" MAX-ACCESS read-write STATUS current DESCRIPTION "The number of minutes a Notification SHOULD be kept in a log before it is automatically removed. If an application changes the value of nlmConfigGlobalAgeOut, Notifications older than the new time MAY be discarded to meet the new time. A value of 0 means no age out. Please be aware that contention between multiple managers trying to set this object to different values MAY affect the reliability and completeness of data seen by each manager." DEFVAL { 1440 } -- 24 hours Expires 21 July 2000 [Page 9] Internet Draft Notification Log MIB 21 January 2000 ::= { nlmConfig 2 } -- -- Basic Log Configuration Table -- nlmConfigLogTable OBJECT-TYPE SYNTAX SEQUENCE OF NlmConfigLogEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of logging control entries." ::= { nlmConfig 3 } nlmConfigLogEntry OBJECT-TYPE SYNTAX NlmConfigLogEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A logging control entry. Depending on the entry's storage type entries may be supplied by the system or created and deleted by applications using nlmConfigLogEntryStatus." INDEX { nlmLogName } ::= { nlmConfigLogTable 1 } NlmConfigLogEntry ::= SEQUENCE { nlmLogName SnmpAdminString, nlmConfigLogFilterName SnmpAdminString, nlmConfigLogEntryLimit Unsigned32, nlmConfigLogAdminStatus INTEGER, nlmConfigLogOperStatus INTEGER, nlmConfigLogStorageType StorageType, nlmConfigLogEntryStatus RowStatus } nlmLogName OBJECT-TYPE SYNTAX SnmpAdminString (SIZE(0..32)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The name of the log. An implementation may allow multiple named logs, up to some implementation-specific limit (which may be none). A Expires 21 July 2000 [Page 10] Internet Draft Notification Log MIB 21 January 2000 zero-length log name is reserved for creation and deletion by the managed system, and MUST be used as the default log name by systems that do not support named logs." ::= { nlmConfigLogEntry 1 } nlmConfigLogFilterName OBJECT-TYPE SYNTAX SnmpAdminString (SIZE(0..32)) MAX-ACCESS read-create STATUS current DESCRIPTION "A value of snmpNotifyFilterProfileName as used as an index into the snmpNotifyFilterTable in the SNMP Notification MIB, specifying the locally or remotely originated Notifications to be filtered out and not logged in this log. A zero-length value or a name that does not identify an existing entry in snmpNotifyFilterTable indicate no Notifications are to be logged in this log." DEFVAL { ''H } ::= { nlmConfigLogEntry 2 } nlmConfigLogEntryLimit OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-create STATUS current DESCRIPTION "The maximum number of notification entries that can be held in nlmLogTable for this named log. A particular setting does not guarantee that that much data can be held. If an application changes the limit while there are Notifications in the log, the oldest Notifications are discarded to bring the log down to the new limit. A value of 0 indicates no limit. Please be aware that contention between multiple managers trying to set this object to different values MAY affect the reliability and completeness of data seen by each manager." DEFVAL { 0 } ::= { nlmConfigLogEntry 3 } nlmConfigLogAdminStatus OBJECT-TYPE SYNTAX INTEGER { enabled(1), disabled(2) } MAX-ACCESS read-create Expires 21 July 2000 [Page 11] Internet Draft Notification Log MIB 21 January 2000 STATUS current DESCRIPTION "Control to enable or disable the log without otherwise disturbing the log's entry. Please be aware that contention between multiple managers trying to set this object to different values MAY affect the reliability and completeness of data seen by each manager." DEFVAL { enabled } ::= { nlmConfigLogEntry 4 } nlmConfigLogOperStatus OBJECT-TYPE SYNTAX INTEGER { disabled(1), operational(2), noFilter(3) } MAX-ACCESS read-only STATUS current DESCRIPTION "The operational status of this log: disabled administratively disabled operational administratively enabled and working noFilter administratively enabled but either nlmConfigLogFilterName is zero length or does not name an existing entry in snmpNotifyFilterTable" ::= { nlmConfigLogEntry 5 } nlmConfigLogStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create STATUS current DESCRIPTION "The storage type of this conceptual row." ::= { nlmConfigLogEntry 6 } nlmConfigLogEntryStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "Control for creating and deleting entries. Entries may be modified while active. For non-null-named logs, the managed system records the security Expires 21 July 2000 [Page 12] Internet Draft Notification Log MIB 21 January 2000 credentials from the request that sets nlmConfigLogStatus to 'active' and uses that identity to apply access control to the objects in the Notification to decide if that Notification may be logged." ::= { nlmConfigLogEntry 7 } -- -- Statistics Section -- nlmStatsGlobalNotificationsLogged OBJECT-TYPE SYNTAX Counter32 UNITS "notifications" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Notifications put into the nlmLogTable. This counts a Notification once for each log entry, so a Notification put into multiple logs is counted multiple times." ::= { nlmStats 1 } nlmStatsGlobalNotificationsBumped OBJECT-TYPE SYNTAX Counter32 UNITS "notifications" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of log entries discarded to make room for a new entry due to lack of resources or the value of nlmConfigGlobalEntryLimit or nlmConfigLogEntryLimit. This does not include entries discarded due to the value of nlmConfigGlobalAgeOut." ::= { nlmStats 2 } -- -- Log Statistics Table -- nlmStatsLogTable OBJECT-TYPE SYNTAX SEQUENCE OF NlmStatsLogEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of Notification log statistics entries." ::= { nlmStats 3 } Expires 21 July 2000 [Page 13] Internet Draft Notification Log MIB 21 January 2000 nlmStatsLogEntry OBJECT-TYPE SYNTAX NlmStatsLogEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A Notification log statistics entry." AUGMENTS { nlmConfigLogEntry } ::= { nlmStatsLogTable 1 } NlmStatsLogEntry ::= SEQUENCE { nlmStatsLogNotificationsLogged Counter32, nlmStatsLogNotificationsBumped Counter32 } nlmStatsLogNotificationsLogged OBJECT-TYPE SYNTAX Counter32 UNITS "notifications" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Notifications put in this named log." ::= { nlmStatsLogEntry 1 } nlmStatsLogNotificationsBumped OBJECT-TYPE SYNTAX Counter32 UNITS "notifications" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of log entries discarded from this named log to make room for a new entry due to lack of resources or the value of nlmConfigGlobalEntryLimit or nlmConfigLogEntryLimit. This does not include entries discarded due to the value of nlmConfigGlobalAgeOut." ::= { nlmStatsLogEntry 2 } -- -- Log Section -- -- -- Log Table -- Expires 21 July 2000 [Page 14] Internet Draft Notification Log MIB 21 January 2000 nlmLogTable OBJECT-TYPE SYNTAX SEQUENCE OF NlmLogEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of Notification log entries. It is an implementation-specific matter whether entries in this table are preserved across initializations of the management system. In general one would expect that they are not. Note that keeping entries across initializations of the management system leads to some confusion with counters and TimeStamps, since both of those are based on sysUpTime, which resets on management initialization. In this situation, counters apply only after the reset and nlmLogTime for entries made before the reset SHOULD be set to 0." ::= { nlmLog 1 } nlmLogEntry OBJECT-TYPE SYNTAX NlmLogEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A Notification log entry. Entries appear in this table when Notifications occur and pass filtering by nlmConfigLogFilterName and access control. They are removed to make way for new entries due to lack of resources or the values of nlmConfigGlobalEntryLimit, nlmConfigGlobalAgeOut, or nlmConfigLogEntryLimit. If adding an entry would exceed nlmConfigGlobalEntryLimit or system resources in general, the oldest entry in any log SHOULD be removed to make room for the new one. If adding an entry would exceed nlmConfigLogEntryLimit the oldest entry in that log SHOULD be removed to make room for the new one. Before the managed system puts a locally-generated Notification into a non-null-named log it assures that the creator of the log has access to the information in the Notification. If not it does not log that Notification in that log." INDEX { nlmLogName, nlmLogIndex } ::= { nlmLogTable 1 } Expires 21 July 2000 [Page 15] Internet Draft Notification Log MIB 21 January 2000 NlmLogEntry ::= SEQUENCE { nlmLogIndex Unsigned32, nlmLogTime TimeStamp, nlmLogDateAndTime DateAndTime, nlmLogEngineID SnmpEngineID, nlmLogEngineAddress IpAddress, nlmLogContextEngineID SnmpEngineID, nlmLogContextName SnmpAdminString, nlmLogNotificationID OBJECT IDENTIFIER } nlmLogIndex OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "A monotonically increasing integer for the sole purpose of indexing entries within the named log. When it reaches the maximum value, an extremely unlikely event, the agent wraps the value back to 1." ::= { nlmLogEntry 1 } nlmLogTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime when the entry was placed in the log. If the entry occurred before the most recent management system initialization this object value MUST be set to zero." ::= { nlmLogEntry 2 } nlmLogDateAndTime OBJECT-TYPE SYNTAX DateAndTime MAX-ACCESS read-only STATUS current DESCRIPTION "The local date and time when the entry was logged, instantiated only by systems that have date and time capability." ::= { nlmLogEntry 3 } nlmLogEngineID OBJECT-TYPE SYNTAX SnmpEngineID MAX-ACCESS read-only STATUS current Expires 21 July 2000 [Page 16] Internet Draft Notification Log MIB 21 January 2000 DESCRIPTION "The identification of the SNMP engine at which the Notification originated. If the log can contain Notifications from only one engine or the Trap is in SNMPv1 format, this object is not instantiated." ::= { nlmLogEntry 4 } nlmLogEngineAddress OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS read-only STATUS current DESCRIPTION "The IP Address of the SNMP engine from which the Notification was received. This is used to identify the source of an SNMPv1 trap, since an nlmLogEngineId cannot be extracted from the SNMPv1 trap pdu. This object MUST always be instantiated, even if the log can contain Notifications from only one engine. Please be aware that the nlmLogEngineAddress may not uniquely identify the SNMP engine from which the Notification was received. For example, if an SNMP engine uses DHCP or NAT to obtain ip addresses, the address it uses may be shared with other network devices, and hence will not uniquely identify the SNMP engine." ::= { nlmLogEntry 5 } nlmLogContextEngineID OBJECT-TYPE SYNTAX SnmpEngineID MAX-ACCESS read-only STATUS current DESCRIPTION "The contextEngineID within an administrative domain (indicated by nlmEngineID) that uniquely identifies an SNMP entity that may realize an instance of a context with a particular contextName. If the log originates from an administrative domain with only one contextEngineID, or the Trap is from an SNMPv1 system, this object SHOULD NOT be instantiated." ::= { nlmLogEntry 6 } nlmLogContextName OBJECT-TYPE Expires 21 July 2000 [Page 17] Internet Draft Notification Log MIB 21 January 2000 SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION "The name of the SNMP MIB context from which the Notification came. For SNMPv1 Traps this is the community string from the Trap. If the Notification's source SNMP engine is known not to support multiple contexts, this object MAY not be instantiated." ::= { nlmLogEntry 7 } nlmLogNotificationID OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-only STATUS current DESCRIPTION "The NOTIFICATION-TYPE object identifer of the Notification that occurred." ::= { nlmLogEntry 8 } -- -- Log Variable Table -- nlmLogVariableTable OBJECT-TYPE SYNTAX SEQUENCE OF NlmLogVariableEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of variables to go with Notification log entries." ::= { nlmLog 2 } nlmLogVariableEntry OBJECT-TYPE SYNTAX NlmLogVariableEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A Notification log entry variable. Entries appear in this table when there are variables in the varbind list of a Notification in nlmLogTable." INDEX { nlmLogName, nlmLogIndex, nlmLogVariableIndex } ::= { nlmLogVariableTable 1 } NlmLogVariableEntry ::= SEQUENCE { Expires 21 July 2000 [Page 18] Internet Draft Notification Log MIB 21 January 2000 nlmLogVariableIndex Unsigned32, nlmLogVariableID OBJECT IDENTIFIER, nlmLogVariableValueType INTEGER, nlmLogVariableCounter32Val Counter32, nlmLogVariableUnsigned32Val Unsigned32, nlmLogVariableTimeTicksVal TimeTicks, nlmLogVariableInteger32Val Integer32, nlmLogVariableOctetStringVal OCTET STRING, nlmLogVariableIpAddressVal IpAddress, nlmLogVariableOidVal OBJECT IDENTIFIER, nlmLogVariableCounter64Val Counter64, nlmLogVariableOpaqueVal Opaque } nlmLogVariableIndex OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "A monotonically increasing integer, starting at 1 for a given nlmLogIndex, for indexing variables within the logged Notification." ::= { nlmLogVariableEntry 1 } nlmLogVariableID OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-only STATUS current DESCRIPTION "The variable's object identifier." ::= { nlmLogVariableEntry 2 } nlmLogVariableValueType OBJECT-TYPE SYNTAX INTEGER { counter32(1), unsigned32(2), timeTicks(3), integer32(4), ipAddress(5), octetString(6), objectId(7), counter64(8), opaque(9) } MAX-ACCESS read-only STATUS current DESCRIPTION "The type of the value. One and only one of the value objects that follow must be instantiated, based on this type." ::= { nlmLogVariableEntry 3 } nlmLogVariableCounter32Val OBJECT-TYPE SYNTAX Counter32 Expires 21 July 2000 [Page 19] Internet Draft Notification Log MIB 21 January 2000 MAX-ACCESS read-only STATUS current DESCRIPTION "The value when nlmLogVariableType is 'counter32'." ::= { nlmLogVariableEntry 4 } nlmLogVariableUnsigned32Val OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "The value when nlmLogVariableType is 'unsigned32'." ::= { nlmLogVariableEntry 5 } nlmLogVariableTimeTicksVal OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS current DESCRIPTION "The value when nlmLogVariableType is 'timeTicks'." ::= { nlmLogVariableEntry 6 } nlmLogVariableInteger32Val OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "The value when nlmLogVariableType is 'integer32'." ::= { nlmLogVariableEntry 7 } nlmLogVariableOctetStringVal OBJECT-TYPE SYNTAX OCTET STRING MAX-ACCESS read-only STATUS current DESCRIPTION "The value when nlmLogVariableType is 'octetString'." ::= { nlmLogVariableEntry 8 } nlmLogVariableIpAddressVal OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS read-only STATUS current DESCRIPTION "The value when nlmLogVariableType is 'ipAddress'." ::= { nlmLogVariableEntry 9 } Expires 21 July 2000 [Page 20] Internet Draft Notification Log MIB 21 January 2000 nlmLogVariableOidVal OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-only STATUS current DESCRIPTION "The value when nlmLogVariableType is 'objectId'." ::= { nlmLogVariableEntry 10 } nlmLogVariableCounter64Val OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The value when nlmLogVariableType is 'counter64'." ::= { nlmLogVariableEntry 11 } nlmLogVariableOpaqueVal OBJECT-TYPE SYNTAX Opaque MAX-ACCESS read-only STATUS current DESCRIPTION "The value when nlmLogVariableType is 'opaque'." ::= { nlmLogVariableEntry 12 } -- -- Conformance -- notificationLogMIBConformance OBJECT IDENTIFIER ::= { notificationLogMIB 3 } notificationLogMIBCompliances OBJECT IDENTIFIER ::= { notificationLogMIBConformance 1 } notificationLogMIBGroups OBJECT IDENTIFIER ::= { notificationLogMIBConformance 2 } -- Compliance notificationLogMIBCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for entities which implement the Notification Log MIB." MODULE -- this module MANDATORY-GROUPS { Expires 21 July 2000 [Page 21] Internet Draft Notification Log MIB 21 January 2000 notificationLogConfigGroup, notificationLogStatsGroup, notificationLogLogGroup } OBJECT nlmConfigGlobalEntryLimit SYNTAX Unsigned32 (0..4294967295) MIN-ACCESS read-only DESCRIPTION "Implementations may choose a limit and not allow it to be changed or may enforce an upper or lower bound on the limit." OBJECT nlmConfigLogEntryLimit SYNTAX Unsigned32 (0..4294967295) MIN-ACCESS read-only DESCRIPTION "Implementations may choose a limit and not allow it to be changed or may enforce an upper or lower bound on the limit." OBJECT nlmConfigLogEntryStatus MIN-ACCESS read-only DESCRIPTION "Implementations may disallow the creation of named logs." GROUP notificationLogDateGroup DESCRIPTION "This group is mandatory on systems that keep wall clock date and time and should not be implemented on systems that do not have a wall clock date." ::= { notificationLogMIBCompliances 1 } -- Units of Conformance notificationLogConfigGroup OBJECT-GROUP OBJECTS { nlmConfigGlobalEntryLimit, nlmConfigGlobalAgeOut, nlmConfigLogFilterName, nlmConfigLogEntryLimit, nlmConfigLogAdminStatus, nlmConfigLogOperStatus, nlmConfigLogStorageType, Expires 21 July 2000 [Page 22] Internet Draft Notification Log MIB 21 January 2000 nlmConfigLogEntryStatus } STATUS current DESCRIPTION "Notification log configuration management." ::= { notificationLogMIBGroups 1 } notificationLogStatsGroup OBJECT-GROUP OBJECTS { nlmStatsGlobalNotificationsLogged, nlmStatsGlobalNotificationsBumped, nlmStatsLogNotificationsLogged, nlmStatsLogNotificationsBumped } STATUS current DESCRIPTION "Notification log statistics." ::= { notificationLogMIBGroups 2 } notificationLogLogGroup OBJECT-GROUP OBJECTS { nlmLogTime, nlmLogEngineID, nlmLogEngineAddress, nlmLogContextEngineID, nlmLogContextName, nlmLogNotificationID, nlmLogVariableID, nlmLogVariableValueType, nlmLogVariableCounter32Val, nlmLogVariableUnsigned32Val, nlmLogVariableTimeTicksVal, nlmLogVariableInteger32Val, nlmLogVariableOctetStringVal, nlmLogVariableIpAddressVal, nlmLogVariableOidVal, nlmLogVariableCounter64Val, nlmLogVariableOpaqueVal } STATUS current DESCRIPTION "Notification log data." ::= { notificationLogMIBGroups 3 } Expires 21 July 2000 [Page 23] Internet Draft Notification Log MIB 21 January 2000 notificationLogDateGroup OBJECT-GROUP OBJECTS { nlmLogDateAndTime } STATUS current DESCRIPTION "Conditionally mandatory notification log data." ::= { notificationLogMIBGroups 4 } END Expires 21 July 2000 [Page 24] Internet Draft Notification Log MIB 21 January 2000 5. 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. Expires 21 July 2000 [Page 25] Internet Draft Notification Log MIB 21 January 2000 6. References [RFC2571] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing SNMP Management Frameworks", RFC 2571, April 1999 [RFC1155] Rose, M., and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based Internets", STD 16, RFC 1155, May 1990 [RFC1212] Rose, M., and K. McCloghrie, "Concise MIB Definitions", STD 16, RFC 1212, March 1991 [RFC1215] M. Rose, "A Convention for Defining Traps for use with the SNMP", RFC 1215, March 1991 [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., and S. Waldbusser, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999 [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999 [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., and S. Waldbusser, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999 [RFC1157] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network Management Protocol", STD 15, RFC 1157, May 1990. [RFC1901] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Introduction to Community-based SNMPv2", RFC 1901, January 1996. [RFC1906] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Transport Mappings for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1906, January 1996. [RFC2572] Case, J., Harrington D., Presuhn R., and B. Wijnen, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)", RFC 2572, April 1999 [RFC2574] Blumenthal, U., and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Expires 21 July 2000 [Page 26] Internet Draft Notification Log MIB 21 January 2000 Protocol (SNMPv3)", RFC 2574, April 1999 [RFC1905] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Protocol Operations for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1905, January 1996. [RFC2573] Levi, D., Meyer, P., and B. Stewart, "SNMPv3 Applications", RFC 2573, April 1999 [RFC2575] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", RFC 2575, April 1999 [RFC2570] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction to Version 3 of the Internet-standard Network Management Framework", RFC 2570, April 1999 [RFC1903] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Coexistence between Version 1 and version 2 of the Internet-standard Network Management Framework", RFC 1903, January 1996. Expires 21 July 2000 [Page 27] Internet Draft Notification Log MIB 21 January 2000 7. Security Considerations Security issues are discussed in Section 3.1.2. 8. Author's Address Bob Stewart Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134-1706 U.S.A. Ramanathan Kavasseri Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134-1706 U.S.A. Phone: +1 408 527 2446 Email: ramk@cisco.com Expires 21 July 2000 [Page 28] Internet Draft Notification Log MIB 21 January 2000 9. Full Copyright Statement Copyright (C) The Internet Society (1999). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Expires 21 July 2000 [Page 29] Internet Draft Notification Log MIB 21 January 2000 Table of Contents 1 Abstract ........................................................ 2 2 The SNMP Management Framework ................................... 2 3 Overview ........................................................ 3 3.1 Environment ................................................... 3 3.1.1 SNMP Engines and Contexts ................................... 4 3.1.2 Security .................................................... 4 3.2 Structure ..................................................... 5 3.2.1 Configuration ............................................... 6 3.2.2 Statistics .................................................. 6 3.2.3 Log ......................................................... 6 3.3 Example ....................................................... 7 4 Definitions ..................................................... 8 5 Intellectual Property ........................................... 25 6 References ...................................................... 26 7 Security Considerations ......................................... 28 8 Author's Address ................................................ 28 9 Full Copyright Statement ........................................ 29 Expires 21 July 2000 [Page 30] From owner-disman@dorothy.bmc.com Fri Jan 21 23:29:02 2000 Received: from tangelo.bmc.com (fw-us-hou-2.bmc.com [198.207.223.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA22974 for ; Fri, 21 Jan 2000 23:29:02 -0500 (EST) Received: from dorothy.peer.com (dorothy.bmc.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id WAA17732; Fri, 21 Jan 2000 22:28:42 -0600 (CST) Received: (from root@localhost) by dorothy.peer.com (8.8.6 (PHNE_12836)/8.8.6) id UAA27139 for disman-list; Fri, 21 Jan 2000 20:27:33 -0800 (PST) Received: from tangelo.bmc.com (root@tangelo.bmc.com [172.17.7.166]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id UAA27134 for ; Fri, 21 Jan 2000 20:27:26 -0800 (PST) Received: from fw-us-hou1.bmc.com (fw-us-hou1.bmc.com [172.17.0.250]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with SMTP id WAA17656 for ; Fri, 21 Jan 2000 22:27:51 -0600 (CST) Received: from ramk-pc.cisco.com (dhcp-171-69-66-201.cisco.com [171.69.66.201]) by sigma.cisco.com (8.8.8-Cisco List Logging/8.8.8) with SMTP id UAA17476; Fri, 21 Jan 2000 20:27:42 -0800 (PST) Message-Id: <4.1.20000121192323.00a39400@sigma.cisco.com> X-Sender: ramk@sigma.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Fri, 21 Jan 2000 19:26:38 -0800 To: disman@dorothy.peer.com From: Ramanathan Kavasseri Subject: Reason for publishing draft-ietf-disman-notif-log-mib-14.txt Cc: dharrington@mediaone.net Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list Following a discussion about nlmLogIndex and the behavior when the index wrapped, the consensus was that the text "and MUST flush existing entries" should be dropped...draft-ietf-disman-notif-log-mib-13.txt did not nave this correction, and hence I needed to post a final one... Thanks, Ram Kavasseri From owner-disman@dorothy.peer.com Mon Jan 24 05:32:35 2000 Received: from tangelo.bmc.com (fw-us-hou-2.bmc.com [198.207.223.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00930 for ; Mon, 24 Jan 2000 05:32:34 -0500 (EST) Received: from dorothy.peer.com (dorothy.bmc.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id VAA09791; Sun, 23 Jan 2000 21:38:50 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id KAA07798 for disman-list; Sun, 23 Jan 2000 10:30:51 -0800 (PST) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id KAA07752; Sun, 23 Jan 2000 10:24:52 -0800 (PST) Date: Sun, 23 Jan 2000 10:24:52 -0800 (PST) From: Randy Presuhn Message-Id: <200001231824.KAA07752@dorothy.bmc.com> To: disman@dorothy.peer.com Subject: You may be dropped if... Cc: agentx@dorothy.peer.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-disman@dorothy.peer.com Precedence: bulk List-Id: IETF disman Working Group mailing list Content-Transfer-Encoding: 7bit Hi - Some sites have apparently decided to block traffic from the disman and agentx WG mailing lists. I find this surprising, since I think our spam record has been quite good. When list administrators get bounces like these, there is no choice but to drop the offending addresses from the mailing list. Note that the nature of these blocks can prevent list administrators from notifying such subscribers that they have been dropped. ------------------------------------------------------------------------ Randy Presuhn randy_presuhn@bmc.com http://www.bmc.com/ Voice: +1 408 546-1006 BMC Software, Inc. 1-3141 2141 N. First Street Fax: +1 408 965-0359 San Jose, California 95131 USA ------------------------------------------------------------------------ Any relationship between my opinions and BMC's should be coincidental. ------------------------------------------------------------------------ > From MAILER-DAEMON Fri Jan 21 19:23:39 PST 2000 > Date: Fri, 21 Jan 2000 21:24:02 -0600 (CST) > From: Mail Delivery Subsystem > Message-Id: <200001220324.VAA08672@tangelo.bmc.com> > To: > Subject: Returned mail: Service unavailable > Auto-Submitted: auto-generated (failure) > > This is a MIME-encapsulated message > > --VAA08672.948511442/tangelo.bmc.com > > The original message was received at Fri, 21 Jan 2000 21:08:10 -0600 (CST) > from dorothy.bmc.com [192.146.153.65] > > ----- The following addresses had permanent fatal errors ----- > > > ----- Transcript of session follows ----- > 451 ... reply: read error from ecarsddd.nortelnetworks.com. > ... while talking to fobos.ulpgc.es.: > >>> MAIL From: > <<< 550 198.207.223.251 is an open relay - see http://www.orbs.org > 554 ... Service unavailable > > --VAA08672.948511442/tangelo.bmc.com > Content-Type: message/delivery-status > > Reporting-MTA: dns; tangelo.bmc.com > Received-From-MTA: DNS; dorothy.bmc.com > Arrival-Date: Fri, 21 Jan 2000 21:08:10 -0600 (CST) > > Final-Recipient: RFC822; mario@cicei.ulpgc.es > Action: failed > Status: 5.0.0 > Remote-MTA: DNS; fobos.ulpgc.es > Diagnostic-Code: SMTP; 550 198.207.223.251 is an open relay - see http://www.orbs.org > Last-Attempt-Date: Fri, 21 Jan 2000 21:20:53 -0600 (CST) > > --VAA08672.948511442/tangelo.bmc.com > Content-Type: text/rfc822-headers > > Return-Path: > Received: from dorothy.peer.com (dorothy.bmc.com [192.146.153.65]) > by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id VAA08621; > Fri, 21 Jan 2000 21:08:10 -0600 (CST) > Received: (from root@localhost) > by dorothy.peer.com (8.8.6 (PHNE_12836)/8.8.6) id TAA26967 > for disman-list; Fri, 21 Jan 2000 19:03:26 -0800 (PST) > Received: from tangelo.bmc.com (root@tangelo.bmc.com [172.17.7.166]) > by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id TAA26962 > for ; Fri, 21 Jan 2000 19:03:10 -0800 (PST) > Received: from fw-us-hou1.bmc.com (fw-us-hou1.bmc.com [172.17.0.250]) > by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with SMTP id VAA08098 > for ; Fri, 21 Jan 2000 21:03:34 -0600 (CST) > Received: (ramk@localhost) by itech-view2.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) id TAA26314; Fri, 21 Jan 2000 19:02:21 -0800 (PST) > From: Ram Kavasseri > Message-Id: <200001220302.TAA26314@itech-view2.cisco.com> > Subject: draft-ietf-disman-notif-log-mib-13.txt > To: internet-drafts@ietf.org > Date: Fri, 21 Jan 2000 19:02:21 -0800 (PST) > Cc: rpresuhn@dorothy.peer.com, dharrington@mediaone.net, > disman@dorothy.peer.com > X-Mailer: ELM [version 2.5 PL1] > MIME-Version: 1.0 > Content-Type: text/plain; charset=us-ascii > Content-Transfer-Encoding: 7bit > Sender: owner-disman@dorothy.bmc.com > Precedence: bulk > List-Id: IETF disman Working Group mailing list > > --VAA08672.948511442/tangelo.bmc.com-- > > From owner-disman@dorothy.peer.com Tue Jan 25 08:42:43 2000 Received: from tangelo.bmc.com (fw-us-hou-2.bmc.com [198.207.223.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25479 for ; Tue, 25 Jan 2000 08:42:43 -0500 (EST) Received: from dorothy.peer.com (dorothy.bmc.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id HAA24087; Tue, 25 Jan 2000 07:41:53 -0600 (CST) Received: (from root@localhost) by dorothy.peer.com (8.8.6 (PHNE_12836)/8.8.6) id FAA11284 for disman-list; Tue, 25 Jan 2000 05:37:54 -0800 (PST) Received: from tangelo.bmc.com (root@tangelo.bmc.com [172.17.7.166]) by dorothy.peer.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id FAA11279 for ; Tue, 25 Jan 2000 05:37:49 -0800 (PST) Received: from fw-us-hou1.bmc.com (fw-us-hou1.bmc.com [172.17.0.250]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with SMTP id HAA23366 for ; Tue, 25 Jan 2000 07:38:15 -0600 (CST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21744; Tue, 25 Jan 2000 07:09:51 -0500 (EST) Message-Id: <200001251209.HAA21744@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: disman@dorothy.peer.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-disman-notif-log-mib-13.txt Date: Tue, 25 Jan 2000 07:09:46 -0500 Sender: owner-disman@dorothy.peer.com Precedence: bulk List-Id: IETF disman Working Group mailing list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Distributed Management Working Group of the IETF. Title : Notification Log MIB Author(s) : B. Stewart, R. Kavasseri Filename : draft-ietf-disman-notif-log-mib-13.txt Pages : 30 Date : 24-Jan-00 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for logging SNMP Notifications. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-disman-notif-log-mib-13.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-disman-notif-log-mib-13.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-disman-notif-log-mib-13.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000124125430.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-disman-notif-log-mib-13.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-disman-notif-log-mib-13.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000124125430.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-disman@dorothy.peer.com Thu Jan 27 07:06:52 2000 Received: from tangelo.bmc.com (fw-us-hou-2.bmc.com [198.207.223.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02807 for ; Thu, 27 Jan 2000 07:06:42 -0500 (EST) Received: from dorothy.peer.com (dorothy.bmc.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id GAA07332; Thu, 27 Jan 2000 06:05:03 -0600 (CST) Received: (from root@localhost) by dorothy.peer.com (8.8.6 (PHNE_12836)/8.8.6) id DAA29119 for disman-list; Thu, 27 Jan 2000 03:59:45 -0800 (PST) Received: from tangelo.bmc.com (root@tangelo.bmc.com [172.17.7.166]) by dorothy.peer.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id DAA29114 for ; Thu, 27 Jan 2000 03:59:38 -0800 (PST) Received: from fw-us-hou1.bmc.com (fw-us-hou1.bmc.com [172.17.0.250]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with SMTP id FAA06388 for ; Thu, 27 Jan 2000 05:59:52 -0600 (CST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02664; Thu, 27 Jan 2000 06:59:50 -0500 (EST) Message-Id: <200001271159.GAA02664@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: disman@dorothy.peer.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-disman-notif-log-mib-14.txt Date: Thu, 27 Jan 2000 06:59:50 -0500 Sender: owner-disman@dorothy.peer.com Precedence: bulk List-Id: IETF disman Working Group mailing list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Distributed Management Working Group of the IETF. Title : Notification Log MIB Author(s) : B. Stewart, R. Kavasseri Filename : draft-ietf-disman-notif-log-mib-14.txt Pages : 30 Date : 25-Jan-00 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for logging SNMP Notifications. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-disman-notif-log-mib-14.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-disman-notif-log-mib-14.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-disman-notif-log-mib-14.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000125074940.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-disman-notif-log-mib-14.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-disman-notif-log-mib-14.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000125074940.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-disman@dorothy.peer.com Thu Jan 27 13:37:01 2000 Received: from tangelo.bmc.com (fw-us-hou-2.bmc.com [198.207.223.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11630 for ; Thu, 27 Jan 2000 13:37:00 -0500 (EST) Received: from dorothy.bmc.com (dorothy.bmc.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id MAA05484; Thu, 27 Jan 2000 12:36:36 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id KAA03286 for disman-list; Thu, 27 Jan 2000 10:32:17 -0800 (PST) Received: from tangelo.bmc.com (root@tangelo.bmc.com [172.17.7.166]) by dorothy.peer.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id KAA03281 for ; Thu, 27 Jan 2000 10:32:10 -0800 (PST) Received: from ec01-hou.bmc.com (ec01-hou.bmc.com [172.17.0.150]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id MAA04185 for ; Thu, 27 Jan 2000 12:32:30 -0600 (CST) Received: by ec01-hou.bmc.com with Internet Mail Service (5.5.2650.21) id ; Thu, 27 Jan 2000 12:32:28 -0600 Message-ID: From: "Appelbaum, Muriel" To: "'disman@dorothy.bmc.com'" Subject: FW: Non-member submission from [Thippanna Hongal ] Date: Thu, 27 Jan 2000 12:32:42 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-disman@dorothy.peer.com Precedence: bulk List-Id: IETF disman Working Group mailing list -----Original Message----- From: owner-disman@dorothy.peer.com [mailto:owner-disman@dorothy.peer.com] Sent: Thursday, January 27, 2000 10:10 AM To: owner-disman@dorothy.peer.com Subject: BOUNCE disman@dorothy.bmc.com: Non-member submission from [Thippanna Hongal ] From owner-disman Thu Jan 27 10:09:57 2000 Received: from tangelo.bmc.com (root@tangelo.bmc.com [172.17.7.166]) by dorothy.peer.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id KAA01167 for ; Thu, 27 Jan 2000 10:09:55 -0800 (PST) Received: from fw-us-hou1.bmc.com (fw-us-hou1.bmc.com [172.17.0.250]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with SMTP id MAA27104 for ; Thu, 27 Jan 2000 12:10:04 -0600 (CST) Received: from yagosys.com by yagosys.com (8.8.8+Sun/SMI-SVR4-Yago) id KAA10211; Thu, 27 Jan 2000 10:08:53 -0800 (PST) Message-ID: <38906E6D.8C163665@yagosys.com> Date: Thu, 27 Jan 2000 10:12:30 -0600 From: Thippanna Hongal Organization: Cabletron Systems Inc X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en,Kannada MIME-Version: 1.0 To: disman@dorothy.peer.com Subject: implementation of rfc2591 Content-Type: multipart/mixed; boundary="------------4342DB19B82B0E3B224E2EF9" This is a multi-part message in MIME format. --------------4342DB19B82B0E3B224E2EF9 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit hi all I am still implementing rfc2591, Thanks for your quick reply for my earlier questions. I have some question regarding daylight sayings non existent time. If an calendar schedule is scheduled to shoot every minute, and if the time is changed from 2 PM to 3 PM, Do I need to schedule 60 times the schedule at 3 PM or it is triggered only once ?. thanks hongal --------------4342DB19B82B0E3B224E2EF9 Content-Type: text/x-vcard; charset=us-ascii; name="hongal.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Thippanna Hongal Content-Disposition: attachment; filename="hongal.vcf" begin:vcard n:Hongal;Thippanna tel;cell:408-221-3212 tel;fax:408-878-6560 tel;home:408-248-5855 tel;work:408-878-6562 x-mozilla-html:TRUE org:Cabletron Systems, Inc.;NMS Engg adr:;;3615 Green Lee Drive Apt. No. 21;San Jose;ca;95117;US version:2.1 email;internet:hongal@yagosys.com title:Member of Technical Staff x-mozilla-cpt:;25856 fn:Thippanna Hongal end:vcard --------------4342DB19B82B0E3B224E2EF9-- From owner-disman@dorothy.peer.com Thu Jan 27 15:37:48 2000 Received: from tangelo.bmc.com (fw-us-hou-2.bmc.com [198.207.223.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14285 for ; Thu, 27 Jan 2000 15:37:45 -0500 (EST) Received: from dorothy.bmc.com (dorothy.bmc.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id OAA14173; Thu, 27 Jan 2000 14:37:22 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id MAA07435 for disman-list; Thu, 27 Jan 2000 12:35:32 -0800 (PST) Received: from tangelo.bmc.com (root@tangelo.bmc.com [172.17.7.166]) by dorothy.peer.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id MAA07430 for ; Thu, 27 Jan 2000 12:35:27 -0800 (PST) Received: from fw-us-hou1.bmc.com (fw-us-hou1.bmc.com [172.17.0.250]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with SMTP id OAA13719 for ; Thu, 27 Jan 2000 14:35:54 -0600 (CST) Received: from seymour47.SNMP.COM (seymour47.snmp.com [192.147.142.47]) by seymour39.SNMP.COM (8.9.3/snmpserver.mc-990526) with ESMTP id PAA29045; Thu, 27 Jan 2000 15:34:45 -0500 (EST) From: Alan Luchuk Received: (from luchuk@localhost) by seymour47.SNMP.COM (8.9.3/snmpclient.mc-990423) id PAA18242; Thu, 27 Jan 2000 15:34:44 -0500 (EST) Date: Thu, 27 Jan 2000 15:34:44 -0500 (EST) Message-Id: <200001272034.PAA18242@seymour47.SNMP.COM> To: hongal@yagosys.com Subject: Re: Implementation of RFC 2591 Cc: disman@dorothy.peer.com, luchuk@snmp.com Sender: owner-disman@dorothy.peer.com Precedence: bulk List-Id: IETF disman Working Group mailing list >hi all > >I am still implementing rfc2591, Thanks for your quick reply for my >earlier questions. > >I have some question regarding daylight sayings non existent time. >If an calendar schedule is scheduled to shoot every minute, and if the >time is changed from 2 PM to 3 PM, >Do I need to schedule 60 times the schedule at 3 PM or it is triggered >only once ?. > >thanks >hongal Hello, In your text above, I assume you mean 2 AM and 3 AM. In RFC 2591, section 3.4, the last paragraph (on page 5) reads: When an action is configured in the Schedule MIB to occur at a nonexistent time, the action SHOULD be invoked immediately upon a time transition. If multiple actions are invoked in this way, they SHALL be invoked in the order in which they normally would be invoked had the time transition not occured. For example, if an action (a) is scheduled at 2:05 am and another action (b) at 2:10 am, then both actions SHOULD be invoked at 3:00 am in the order (a),(b) if the time jumps forward from 2:00 am to 3:00 am. As I read this, the 3 AM event occurs only once. But also, all of the events scheduled for the missing hour between 2 AM and 3 AM also must be triggered at 3 AM. Regards, --Alan ----------------------------------------------------------------------------- Alan Luchuk SNMP Research, Inc. Voice: +1 865 573 1434 Software Engineer 3001 Kimberlin Heights Road FAX: +1 865 573 9197 luchuk@snmp.com Knoxville, TN 37920-9716 U.S.A. http://www.snmp.com/ ----------------------------------------------------------------------------- Note: Our area code changed to 865 from 423 in November. If you have trouble reaching us via area code 865, please try the old area code (423) and let us know. Both area codes should work until April. From owner-disman@dorothy.peer.com Fri Jan 28 06:35:35 2000 Received: from tangelo.bmc.com (fw-us-hou-2.bmc.com [198.207.223.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05486 for ; Fri, 28 Jan 2000 06:35:35 -0500 (EST) Received: from dorothy.peer.com (dorothy.bmc.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id FAA21970; Fri, 28 Jan 2000 05:35:11 -0600 (CST) Received: (from root@localhost) by dorothy.peer.com (8.8.6 (PHNE_12836)/8.8.6) id DAA29572 for disman-list; Fri, 28 Jan 2000 03:32:34 -0800 (PST) Received: from tangelo.bmc.com (root@tangelo.bmc.com [172.17.7.166]) by dorothy.peer.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id DAA29567 for ; Fri, 28 Jan 2000 03:32:29 -0800 (PST) Received: from fw-us-hou1.bmc.com (fw-us-hou1.bmc.com [172.17.0.250]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with SMTP id FAA21687 for ; Fri, 28 Jan 2000 05:32:54 -0600 (CST) Received: from henkell.ibr.cs.tu-bs.de (schoenw@henkell [134.169.34.191]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) with ESMTP id MAA14648; Fri, 28 Jan 2000 12:32:59 +0100 (MET) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id MAA11644; Fri, 28 Jan 2000 12:32:49 +0100 Date: Fri, 28 Jan 2000 12:32:49 +0100 Message-Id: <200001281132.MAA11644@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: luchuk@snmp.com, hongal@yagosys.com CC: disman@dorothy.peer.com In-reply-to: <200001272034.PAA18242@seymour47.SNMP.COM> (message from Alan Luchuk on Thu, 27 Jan 2000 15:34:44 -0500 (EST)) Subject: Re: Implementation of RFC 2591 References: <200001272034.PAA18242@seymour47.SNMP.COM> Sender: owner-disman@dorothy.peer.com Precedence: bulk List-Id: IETF disman Working Group mailing list >>>>> Thippanna Hongal writes: >> I have some question regarding daylight sayings non existent time. >> If an calendar schedule is scheduled to shoot every minute, and if >> the time is changed from 2 PM to 3 PM, Do I need to schedule 60 >> times the schedule at 3 PM or it is triggered only once ?. Alan> In RFC 2591, section 3.4, the last paragraph (on page 5) reads: [...] Alan> As I read this, the 3 AM event occurs only once. But also, all Alan> of the events scheduled for the missing hour between 2 AM and 3 Alan> AM also must be triggered at 3 AM. I think this is obvious for events scheduled for nonexistent times that come from different entries in the schedTable. It is probably not so obvious for multiple events scheduled for nonexistent times that come from the same schedTable entry. Shall we add a sentence which makes that clearer? What about adding the following sentence directly below the last paragraph of section 3.4 in RFC 2591: This rule applies to all events scheduled for nonexistent time, regardless whether the scheduled events originate from one or multiple rows in the schedTable. Would that help? /js -- Juergen Schoenwaelder Technical University Braunschweig Dept. Operating Systems & Computer Networks Phone: +49 531 391 3289 Bueltenweg 74/75, 38106 Braunschweig, Germany Fax: +49 531 391 5936 From owner-disman@dorothy.peer.com Fri Jan 28 08:53:38 2000 Received: from tangelo.bmc.com (fw-us-hou-2.bmc.com [198.207.223.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10249 for ; Fri, 28 Jan 2000 08:53:35 -0500 (EST) Received: from dorothy.bmc.com (dorothy.bmc.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id HAA13498; Fri, 28 Jan 2000 07:53:10 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id FAA29808 for disman-list; Fri, 28 Jan 2000 05:48:28 -0800 (PST) Received: from tangelo.bmc.com (root@tangelo.bmc.com [172.17.7.166]) by dorothy.peer.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id FAA29803 for ; Fri, 28 Jan 2000 05:48:25 -0800 (PST) Received: from fw-us-hou1.bmc.com (fw-us-hou1.bmc.com [172.17.0.250]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with SMTP id HAA12593 for ; Fri, 28 Jan 2000 07:48:51 -0600 (CST) Received: from zrchb213.us.nortel.com (actually zrchb213) by smtprch1.nortel.com; Fri, 28 Jan 2000 07:48:41 -0600 Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2448.0) id ; Fri, 28 Jan 2000 07:48:34 -0600 Message-ID: <6DDA62170439D31185750000F80826AC015BA3FF@zmerd004.ca.nortel.com> From: "Sharon Chisholm" To: DISMAN Subject: Notification Log MIB and Informs Date: Fri, 28 Jan 2000 07:48:27 -0600 X-Mailer: Internet Mail Service (5.5.2448.0) Sender: owner-disman@dorothy.peer.com Precedence: bulk List-Id: IETF disman Working Group mailing list hi I just did a quick scan of the notification log MIB and I noticed that it does not explicitly say how to handle retransmission of informs. I am assuming that the notification only gets logged once, no matter how many times it gets sent out. Would it be worth explicitly stating this in a future version? Sharon Chisholm Preside Management Nortel Networks Ottawa, Ontario From owner-disman@dorothy.peer.com Fri Jan 28 14:22:12 2000 Received: from tangelo.bmc.com (fw-us-hou-2.bmc.com [198.207.223.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24472 for ; Fri, 28 Jan 2000 14:22:02 -0500 (EST) Received: from dorothy.peer.com (dorothy.bmc.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id NAA00838; Fri, 28 Jan 2000 13:21:04 -0600 (CST) Received: (from root@localhost) by dorothy.peer.com (8.8.6 (PHNE_12836)/8.8.6) id LAA04135 for disman-list; Fri, 28 Jan 2000 11:16:24 -0800 (PST) Received: from tangelo.bmc.com (root@tangelo.bmc.com [172.17.7.166]) by dorothy.peer.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id LAA04130 for ; Fri, 28 Jan 2000 11:16:19 -0800 (PST) Received: from ec01-hou.bmc.com (ec01-hou.bmc.com [172.17.0.150]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id NAA29550 for ; Fri, 28 Jan 2000 13:16:44 -0600 (CST) Received: by ec01-hou.bmc.com with Internet Mail Service (5.5.2650.21) id ; Fri, 28 Jan 2000 13:16:47 -0600 Message-ID: From: "Appelbaum, Muriel" To: "'disman@dorothy.bmc.com'" Subject: FW: Non-member submission from [Thippanna Hongal ] Date: Fri, 28 Jan 2000 13:16:58 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-disman@dorothy.peer.com Precedence: bulk List-Id: IETF disman Working Group mailing list -----Original Message----- From: owner-disman@dorothy.peer.com [mailto:owner-disman@dorothy.peer.com] Sent: Friday, January 28, 2000 10:31 AM To: owner-disman@dorothy.peer.com Subject: BOUNCE disman@dorothy.bmc.com: Non-member submission from [Thippanna Hongal ] From owner-disman Fri Jan 28 10:30:30 2000 Received: from tangelo.bmc.com (root@tangelo.bmc.com [172.17.7.166]) by dorothy.peer.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id KAA04047 for ; Fri, 28 Jan 2000 10:30:25 -0800 (PST) Received: from fw-us-hou1.bmc.com (fw-us-hou1.bmc.com [172.17.0.250]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with SMTP id MAA15314 for ; Fri, 28 Jan 2000 12:30:24 -0600 (CST) Received: from yagosys.com by yagosys.com (8.8.8+Sun/SMI-SVR4-Yago) id KAA08576; Fri, 28 Jan 2000 10:28:45 -0800 (PST) Message-ID: <3891C49D.5C80F4A4@yagosys.com> Date: Fri, 28 Jan 2000 10:32:29 -0600 From: Thippanna Hongal Organization: Cabletron Systems Inc X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en,Kannada MIME-Version: 1.0 To: Juergen Schoenwaelder CC: luchuk@snmp.com, disman@dorothy.peer.com Subject: Re: Implementation of RFC 2591 References: <200001272034.PAA18242@seymour47.SNMP.COM> <200001281132.MAA11644@henkell.ibr.cs.tu-bs.de> Content-Type: multipart/mixed; boundary="------------DD8001433660E8E69658FB48" This is a multi-part message in MIME format. --------------DD8001433660E8E69658FB48 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Juergen Schoenwaelder wrote: > >>>>> Thippanna Hongal writes: > > >> I have some question regarding daylight sayings non existent time. > >> If an calendar schedule is scheduled to shoot every minute, and if > >> the time is changed from 2 PM to 3 PM, Do I need to schedule 60 > >> times the schedule at 3 PM or it is triggered only once ?. > > Alan> In RFC 2591, section 3.4, the last paragraph (on page 5) reads: > > [...] > > Alan> As I read this, the 3 AM event occurs only once. But also, all > Alan> of the events scheduled for the missing hour between 2 AM and 3 > Alan> AM also must be triggered at 3 AM. > > I think this is obvious for events scheduled for nonexistent times > that come from different entries in the schedTable. It is probably not > so obvious for multiple events scheduled for nonexistent times that > come from the same schedTable entry. > > Shall we add a sentence which makes that clearer? What about adding > the following sentence directly below the last paragraph of section > 3.4 in RFC 2591: > > This rule applies to all events scheduled for nonexistent > time, regardless whether the scheduled events originate from > one or multiple rows in the schedTable. > > Would that help? > I do not see any confusion over the explanation in RFC regarding the non-existent time. My question is a specific case of one schedule and one table. I have a single row and which does calendar schedule for 60 times in hour. For 2hrs of non existant time I have to do SNMP SET for 60 * 2 times at the end of 3 PM. This might lead to net congestion. What I have done in my implementation is if that case exists then I have done SET operation to work once and a LOG message will be generated about this saying rest of the 119 SET operations are not done because of repeated large number of SET operations. This LOG message is generated for each schedules which have large number of SET operation to be done during the nonexistent time. At this time I would like to add another implementation feature. If a schedule fails to do its intended operation for certain number of time then schedOperStatus is set to DISABLED. While considering the number of times , I consider the interval between the schedules too. Let me know your thoughts about this. thanks hongal. > > /js > > -- > Juergen Schoenwaelder Technical University Braunschweig > Dept. Operating Systems & Computer Networks > Phone: +49 531 391 3289 Bueltenweg 74/75, 38106 Braunschweig, Germany > Fax: +49 531 391 5936 -- thanks hongal --------------DD8001433660E8E69658FB48 Content-Type: text/x-vcard; charset=us-ascii; name="hongal.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Thippanna Hongal Content-Disposition: attachment; filename="hongal.vcf" begin:vcard n:Hongal;Thippanna tel;cell:408-221-3212 tel;fax:408-878-6560 tel;home:408-248-5855 tel;work:408-878-6562 x-mozilla-html:TRUE org:Cabletron Systems, Inc.;NMS Engg adr:;;3615 Green Lee Drive Apt. No. 21;San Jose;ca;95117;US version:2.1 email;internet:hongal@yagosys.com title:Member of Technical Staff x-mozilla-cpt:;25856 fn:Thippanna Hongal end:vcard --------------DD8001433660E8E69658FB48-- From owner-disman@dorothy.peer.com Fri Jan 28 15:48:02 2000 Received: from tangelo.bmc.com (fw-us-hou-1.bmc.com [198.207.223.250]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26705 for ; Fri, 28 Jan 2000 15:48:02 -0500 (EST) Received: from dorothy.bmc.com (dorothy.bmc.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id OAA28646; Fri, 28 Jan 2000 14:47:37 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id MAA04532 for disman-list; Fri, 28 Jan 2000 12:44:59 -0800 (PST) Received: from tangelo.bmc.com (root@tangelo.bmc.com [172.17.7.166]) by dorothy.peer.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id MAA04527 for ; Fri, 28 Jan 2000 12:44:53 -0800 (PST) Received: from ec01-hou.bmc.com (ec01-hou.bmc.com [172.17.0.150]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id OAA28077 for ; Fri, 28 Jan 2000 14:45:18 -0600 (CST) Received: by ec01-hou.bmc.com with Internet Mail Service (5.5.2650.21) id ; Fri, 28 Jan 2000 14:45:21 -0600 Message-ID: From: "Appelbaum, Muriel" To: "'disman@dorothy.peer.com'" Subject: FW: Non-member submission from [Thippanna Hongal ] Date: Fri, 28 Jan 2000 14:45:28 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-disman@dorothy.peer.com Precedence: bulk List-Id: IETF disman Working Group mailing list -----Original Message----- From: owner-disman@dorothy.peer.com [mailto:owner-disman@dorothy.peer.com] Sent: Friday, January 28, 2000 10:31 AM To: owner-disman@dorothy.peer.com Subject: BOUNCE disman@dorothy.bmc.com: Non-member submission from [Thippanna Hongal ] From owner-disman Fri Jan 28 10:30:30 2000 Received: from tangelo.bmc.com (root@tangelo.bmc.com [172.17.7.166]) by dorothy.peer.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id KAA04047 for ; Fri, 28 Jan 2000 10:30:25 -0800 (PST) Received: from fw-us-hou1.bmc.com (fw-us-hou1.bmc.com [172.17.0.250]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with SMTP id MAA15314 for ; Fri, 28 Jan 2000 12:30:24 -0600 (CST) Received: from yagosys.com by yagosys.com (8.8.8+Sun/SMI-SVR4-Yago) id KAA08576; Fri, 28 Jan 2000 10:28:45 -0800 (PST) Message-ID: <3891C49D.5C80F4A4@yagosys.com> Date: Fri, 28 Jan 2000 10:32:29 -0600 From: Thippanna Hongal Organization: Cabletron Systems Inc X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en,Kannada MIME-Version: 1.0 To: Juergen Schoenwaelder CC: luchuk@snmp.com, disman@dorothy.peer.com Subject: Re: Implementation of RFC 2591 References: <200001272034.PAA18242@seymour47.SNMP.COM> <200001281132.MAA11644@henkell.ibr.cs.tu-bs.de> Content-Type: multipart/mixed; boundary="------------DD8001433660E8E69658FB48" This is a multi-part message in MIME format. --------------DD8001433660E8E69658FB48 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Juergen Schoenwaelder wrote: > >>>>> Thippanna Hongal writes: > > >> I have some question regarding daylight sayings non existent time. > >> If an calendar schedule is scheduled to shoot every minute, and if > >> the time is changed from 2 PM to 3 PM, Do I need to schedule 60 > >> times the schedule at 3 PM or it is triggered only once ?. > > Alan> In RFC 2591, section 3.4, the last paragraph (on page 5) reads: > > [...] > > Alan> As I read this, the 3 AM event occurs only once. But also, all > Alan> of the events scheduled for the missing hour between 2 AM and 3 > Alan> AM also must be triggered at 3 AM. > > I think this is obvious for events scheduled for nonexistent times > that come from different entries in the schedTable. It is probably not > so obvious for multiple events scheduled for nonexistent times that > come from the same schedTable entry. > > Shall we add a sentence which makes that clearer? What about adding > the following sentence directly below the last paragraph of section > 3.4 in RFC 2591: > > This rule applies to all events scheduled for nonexistent > time, regardless whether the scheduled events originate from > one or multiple rows in the schedTable. > > Would that help? > I do not see any confusion over the explanation in RFC regarding the non-existent time. My question is a specific case of one schedule and one table. I have a single row and which does calendar schedule for 60 times in hour. For 2hrs of non existant time I have to do SNMP SET for 60 * 2 times at the end of 3 PM. This might lead to net congestion. What I have done in my implementation is if that case exists then I have done SET operation to work once and a LOG message will be generated about this saying rest of the 119 SET operations are not done because of repeated large number of SET operations. This LOG message is generated for each schedules which have large number of SET operation to be done during the nonexistent time. At this time I would like to add another implementation feature. If a schedule fails to do its intended operation for certain number of time then schedOperStatus is set to DISABLED. While considering the number of times , I consider the interval between the schedules too. Let me know your thoughts about this. thanks hongal. > > /js > > -- > Juergen Schoenwaelder Technical University Braunschweig > Dept. Operating Systems & Computer Networks > Phone: +49 531 391 3289 Bueltenweg 74/75, 38106 Braunschweig, Germany > Fax: +49 531 391 5936 -- thanks hongal --------------DD8001433660E8E69658FB48 Content-Type: text/x-vcard; charset=us-ascii; name="hongal.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Thippanna Hongal Content-Disposition: attachment; filename="hongal.vcf" begin:vcard n:Hongal;Thippanna tel;cell:408-221-3212 tel;fax:408-878-6560 tel;home:408-248-5855 tel;work:408-878-6562 x-mozilla-html:TRUE org:Cabletron Systems, Inc.;NMS Engg adr:;;3615 Green Lee Drive Apt. No. 21;San Jose;ca;95117;US version:2.1 email;internet:hongal@yagosys.com title:Member of Technical Staff x-mozilla-cpt:;25856 fn:Thippanna Hongal end:vcard --------------DD8001433660E8E69658FB48-- From owner-disman@dorothy.peer.com Mon Jan 31 07:20:28 2000 Received: from tangelo.bmc.com (fw-us-hou-2.bmc.com [198.207.223.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01285 for ; Mon, 31 Jan 2000 07:20:27 -0500 (EST) Received: from dorothy.bmc.com (dorothy.bmc.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id GAA23787; Mon, 31 Jan 2000 06:20:07 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id EAA04044 for disman-list; Mon, 31 Jan 2000 04:13:27 -0800 (PST) Received: from tangelo.bmc.com (root@tangelo.bmc.com [172.17.7.166]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id EAA04039 for ; Mon, 31 Jan 2000 04:13:07 -0800 (PST) Received: from fw-us-hou1.bmc.com (fw-us-hou1.bmc.com [172.17.0.250]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with SMTP id GAA22968 for ; Mon, 31 Jan 2000 06:13:38 -0600 (CST) Received: from henkell.ibr.cs.tu-bs.de (schoenw@henkell [134.169.34.191]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) with ESMTP id NAA06827; Mon, 31 Jan 2000 13:13:45 +0100 (MET) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id NAA07079; Mon, 31 Jan 2000 13:13:31 +0100 Date: Mon, 31 Jan 2000 13:13:31 +0100 Message-Id: <200001311213.NAA07079@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: hongal@yagosys.com CC: disman@dorothy.peer.com In-reply-to: (Muriel_Appelbaum@bmc.com) Subject: Re: FW: Non-member submission from [Thippanna Hongal ] References: Sender: owner-disman@dorothy.peer.com Precedence: bulk List-Id: IETF disman Working Group mailing list >>>>> Thippanna Hongal Muriel writes: hongal> I do not see any confusion over the explanation in RFC hongal> regarding the non-existent time. hongal> My question is a specific case of one schedule and one table. hongal> I have a single row and which does calendar schedule for 60 hongal> times in hour. For 2hrs of non existant time I have to do hongal> SNMP SET for 60 * 2 times at the end of 3 PM. This might lead hongal> to net congestion. It only leads to "agent congestion" since the sets are performed on local MIB variables only. A calendar schedule can hav a maximum resolution of minutes. Hence, you can have 60 sets per minute in one hour of non existant time (which is the usual time difference for daylight savings time). Sure, multiple entries can cause lots of sets to happen when time jumps forward. But you are not required to do them all simultaneous. If your agent is single-threaded, then you will process them in a serialized order anyway. All what is required is that you process the events in the same order they were scheduled. hongal> What I have done in my implementation is if that case exists hongal> then I have done SET operation to work once and a LOG message hongal> will be generated about this saying rest of the 119 SET hongal> operations are not done because of repeated large number of hongal> SET operations. This LOG message is generated for each hongal> schedules which have large number of SET operation to be done hongal> during the nonexistent time. Whether this is good or bad depends on what your set operations trigger. In some cases, just doing a single set might be OK, in other cases, your optimization may create inconsistencies. I think we need to define a common way to deal with this situation. The intention of the text currently in RFC 2591 is that all events that fire during non existant time are processed. If we keep that position and your implementation does not behave this way, then it is not conforming to the RFC. So the real question here is whether the behaviour described in RFC 2591 should be changed or not. Any opinions? hongal> At this time I would like to add another implementation hongal> feature. hongal> If a schedule fails to do its intended operation for certain hongal> number of time then schedOperStatus is set to DISABLED. While hongal> considering the number of times , I consider the interval hongal> between the schedules too. This may be a useful addition. Any comments from the WG? Is there interest to add such a capability? Any suggestions for a concrete definition? /js -- Juergen Schoenwaelder Technical University Braunschweig Dept. Operating Systems & Computer Networks Phone: +49 531 391 3289 Bueltenweg 74/75, 38106 Braunschweig, Germany Fax: +49 531 391 5936 From owner-disman@dorothy.peer.com Mon Jan 31 16:13:26 2000 Received: from tangelo.bmc.com (fw-us-hou-1.bmc.com [198.207.223.250]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15894 for ; Mon, 31 Jan 2000 16:13:25 -0500 (EST) Received: from dorothy.peer.com (dorothy.bmc.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id PAA09198; Mon, 31 Jan 2000 15:12:47 -0600 (CST) Received: (from root@localhost) by dorothy.peer.com (8.8.6 (PHNE_12836)/8.8.6) id NAA07885 for disman-list; Mon, 31 Jan 2000 13:05:28 -0800 (PST) Received: from tangelo.bmc.com (root@tangelo.bmc.com [172.17.7.166]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id NAA07880 for ; Mon, 31 Jan 2000 13:05:24 -0800 (PST) Received: from ec01-hou.bmc.com (ec01-hou.bmc.com [172.17.0.150]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id PAA07232 for ; Mon, 31 Jan 2000 15:05:55 -0600 (CST) Received: by ec01-hou.bmc.com with Internet Mail Service (5.5.2650.21) id ; Mon, 31 Jan 2000 15:05:53 -0600 Message-ID: From: "Appelbaum, Muriel" To: "'disman@dorothy.bmc.com'" Subject: FW: Non-member submission from [Thippanna Hongal ] Date: Mon, 31 Jan 2000 15:06:14 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-disman@dorothy.peer.com Precedence: bulk List-Id: IETF disman Working Group mailing list Juergen Schoenwaelder wrote: > >>>>> Thippanna Hongal writes: > > >> I have some question regarding daylight sayings non existent time. > >> If an calendar schedule is scheduled to shoot every minute, and if > >> the time is changed from 2 PM to 3 PM, Do I need to schedule 60 > >> times the schedule at 3 PM or it is triggered only once ?. > > Alan> In RFC 2591, section 3.4, the last paragraph (on page 5) reads: > > [...] > > Alan> As I read this, the 3 AM event occurs only once. But also, all > Alan> of the events scheduled for the missing hour between 2 AM and 3 > Alan> AM also must be triggered at 3 AM. > > I think this is obvious for events scheduled for nonexistent times > that come from different entries in the schedTable. It is probably not > so obvious for multiple events scheduled for nonexistent times that > come from the same schedTable entry. > > Shall we add a sentence which makes that clearer? What about adding > the following sentence directly below the last paragraph of section > 3.4 in RFC 2591: > > This rule applies to all events scheduled for nonexistent > time, regardless whether the scheduled events originate from > one or multiple rows in the schedTable. > > Would that help? > I do not see any confusion over the explanation in RFC regarding the non-existent time. My question is a specific case of one schedule and one table. I have a single row and which does calendar schedule for 60 times in hour. For 2hrs of non existant time I have to do SNMP SET for 60 * 2 times at the end of 3 PM. This might lead to net congestion. What I have done in my implementation is if that case exists then I have done SET operation to work once and a LOG message will be generated about this saying rest of the 119 SET operations are not done because of repeated large number of SET operations. This LOG message is generated for each schedules which have large number of SET operation to be done during the nonexistent time. At this time I would like to add another implementation feature. If a schedule fails to do its intended operation for certain number of time then schedOperStatus is set to DISABLED. While considering the number of times , I consider the interval between the schedules too. Let me know your thoughts about this. thanks hongal. > > /js > > -- > Juergen Schoenwaelder Technical University Braunschweig > Dept. Operating Systems & Computer Networks > Phone: +49 531 391 3289 Bueltenweg 74/75, 38106 Braunschweig, Germany > Fax: +49 531 391 5936 -- thanks hongal --------------DD8001433660E8E69658FB48 Content-Type: text/x-vcard; charset=us-ascii; name="hongal.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Thippanna Hongal Content-Disposition: attachment; filename="hongal.vcf" begin:vcard n:Hongal;Thippanna tel;cell:408-221-3212 tel;fax:408-878-6560 tel;home:408-248-5855 tel;work:408-878-6562 x-mozilla-html:TRUE org:Cabletron Systems, Inc.;NMS Engg adr:;;3615 Green Lee Drive Apt. No. 21;San Jose;ca;95117;US version:2.1 email;internet:hongal@yagosys.com title:Member of Technical Staff x-mozilla-cpt:;25856 fn:Thippanna Hongal end:vcard --------------DD8001433660E8E69658FB48-- From owner-disman@dorothy.peer.com Mon Jan 31 19:43:53 2000 Received: from tangelo.bmc.com (fw-us-hou-2.bmc.com [198.207.223.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19069 for ; Mon, 31 Jan 2000 19:43:52 -0500 (EST) Received: from dorothy.bmc.com (dorothy.bmc.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id SAA07111; Mon, 31 Jan 2000 18:43:47 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id QAA01626 for disman-list; Mon, 31 Jan 2000 16:42:29 -0800 (PST) Received: from tangelo.bmc.com (root@tangelo.bmc.com [172.17.7.166]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id QAA01621 for ; Mon, 31 Jan 2000 16:42:23 -0800 (PST) Received: from fw-us-hou1.bmc.com (fw-us-hou1.bmc.com [172.17.0.250]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with SMTP id SAA06942 for ; Mon, 31 Jan 2000 18:42:53 -0600 (CST) Received: from yagosys.com by yagosys.com (8.8.8+Sun/SMI-SVR4-Yago) id QAA08388; Mon, 31 Jan 2000 16:41:58 -0800 (PST) Message-ID: <389610AD.7827B8AC@yagosys.com> Date: Mon, 31 Jan 2000 16:46:05 -0600 From: Thippanna Hongal Organization: Cabletron Systems Inc X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en,Kannada MIME-Version: 1.0 To: Juergen Schoenwaelder CC: disman@dorothy.peer.com Subject: Re: FW: Non-member submission from [Thippanna Hongal ] References: <200001311213.NAA07079@henkell.ibr.cs.tu-bs.de> Content-Type: multipart/mixed; boundary="------------EB4DCF96BF502AE32142FFE4" Sender: owner-disman@dorothy.peer.com Precedence: bulk List-Id: IETF disman Working Group mailing list This is a multi-part message in MIME format. --------------EB4DCF96BF502AE32142FFE4 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Juergen Schoenwaelder wrote: > >>>>> Thippanna Hongal Muriel writes: > > hongal> I do not see any confusion over the explanation in RFC > hongal> regarding the non-existent time. > > hongal> My question is a specific case of one schedule and one table. > > hongal> I have a single row and which does calendar schedule for 60 > hongal> times in hour. For 2hrs of non existant time I have to do > hongal> SNMP SET for 60 * 2 times at the end of 3 PM. This might lead > hongal> to net congestion. > > It only leads to "agent congestion" since the sets are performed on > local MIB variables only. A calendar schedule can hav a maximum > resolution of minutes. Hence, you can have 60 sets per minute in one > hour of non existant time (which is the usual time difference for > daylight savings time). Sure, multiple entries can cause lots of sets > to happen when time jumps forward. But you are not required to do them > all simultaneous. If your agent is single-threaded, then you will > process them in a serialized order anyway. All what is required is > that you process the events in the same order they were scheduled. > > hongal> What I have done in my implementation is if that case exists > hongal> then I have done SET operation to work once and a LOG message > hongal> will be generated about this saying rest of the 119 SET > hongal> operations are not done because of repeated large number of > hongal> SET operations. This LOG message is generated for each > hongal> schedules which have large number of SET operation to be done > hongal> during the nonexistent time. > > Whether this is good or bad depends on what your set operations > trigger. In some cases, just doing a single set might be OK, in > other cases, your optimization may create inconsistencies. > > I think we need to define a common way to deal with this situation. > The intention of the text currently in RFC 2591 is that all events > that fire during non existant time are processed. If we keep that > position and your implementation does not behave this way, then it is > not conforming to the RFC. > > So the real question here is whether the behaviour described in RFC > 2591 should be changed or not. Any opinions? > At this time I have no data about the side effects of 'agent congestion' on our router due to non existent time SET operation for the above specific case. In my opinion this feature can be made user configurable in future to avoid such possible congestion if those congestion are harmful to the main device operation. I have a luxury of making this feature turn-off and turn-on through CLI commands I hope user configurability through CLI does not make our implementation to not to confirm with the RFC. Let me know if it is. > > hongal> At this time I would like to add another implementation > hongal> feature. > > hongal> If a schedule fails to do its intended operation for certain > hongal> number of time then schedOperStatus is set to DISABLED. While > hongal> considering the number of times , I consider the interval > hongal> between the schedules too. > > This may be a useful addition. Any comments from the WG? Is there > interest to add such a capability? Any suggestions for a concrete > definition? > In this case the question of when to turn off the schedule , I mean how many failures are acceptable can be left to the user to decide based on his requirement. User configurable new object could help decide about it. hongal > > /js > I subscribed to the disman WG general mailing list. > > -- > Juergen Schoenwaelder Technical University Braunschweig > Dept. Operating Systems & Computer Networks > Phone: +49 531 391 3289 Bueltenweg 74/75, 38106 Braunschweig, Germany > Fax: +49 531 391 5936 -- thanks hongal --------------EB4DCF96BF502AE32142FFE4 Content-Type: text/x-vcard; charset=us-ascii; name="hongal.vcf" Content-Description: Card for Thippanna Hongal Content-Disposition: attachment; filename="hongal.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Hongal;Thippanna tel;cell:408-221-3212 tel;fax:408-878-6560 tel;home:408-248-5855 tel;work:408-878-6562 x-mozilla-html:TRUE org:Cabletron Systems, Inc.;NMS Engg adr:;;3615 Green Lee Drive Apt. No. 21;San Jose;ca;95117;US version:2.1 email;internet:hongal@yagosys.com title:Member of Technical Staff x-mozilla-cpt:;25856 fn:Thippanna Hongal end:vcard --------------EB4DCF96BF502AE32142FFE4--