From mailman-bounces@ietf.org Sun Aug 1 07:08:07 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12144 for ; Sun, 1 Aug 2004 07:08:07 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BrCXW-0001sb-2E for disman-archive@lists.ietf.org; Sun, 01 Aug 2004 05:21:58 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: ietf.org mailing list memberships reminder From: mailman-owner@ietf.org To: disman-archive@ietf.org X-No-Archive: yes Message-ID: Date: Sun, 01 Aug 2004 05:05:37 -0400 Precedence: bulk X-BeenThere: mailman@lists.ietf.org X-Mailman-Version: 2.1.5 List-Id: Mailman site list X-List-Administrivia: yes Sender: mailman-bounces@ietf.org Errors-To: mailman-bounces@ietf.org Content-Transfer-Encoding: 7bit This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, mailman-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. ********************************************************************** NOTE WELL: Any submission to the IETF intended by the Contributor for publication as all or part of an IETF Internet-Draft or RFC and any statement made within the context of an IETF activity is considered an "IETF Contribution". Such statements include oral statements in IETF sessions, as well as written and electronic communications made at any time or place, which are addressed to: o the IETF plenary session, o any IETF working group or portion thereof, o the IESG, or any member thereof on behalf of the IESG, o the IAB or any member thereof on behalf of the IAB, o any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, o the RFC Editor or the Internet-Drafts function All IETF Contributions are subject to the rules of RFC 3667 and RFC 3668. Statements made outside of an IETF session, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not IETF Contributions in the context of this notice. Please consult RFC 3667 for details. ******************************************************************************* If you have questions, problems, comments, etc, send them to mailman-owner@ietf.org. Thanks! Passwords for disman-archive@lists.ietf.org: List Password // URL ---- -------- disman@ietf.org hixour https://www1.ietf.org/mailman/options/disman/disman-archive%40lists.ietf.org From disman-bounces@ietf.org Mon Aug 9 17:37:03 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21269 for ; Mon, 9 Aug 2004 17:37:03 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuHe3-0007j0-DU; Mon, 09 Aug 2004 17:25:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuFls-0002j5-8L; Mon, 09 Aug 2004 15:25:24 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01566; Mon, 9 Aug 2004 15:25:22 -0400 (EDT) Message-Id: <200408091925.PAA01566@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Mon, 09 Aug 2004 15:25:22 -0400 X-Mailman-Approved-At: Mon, 09 Aug 2004 17:25:26 -0400 Cc: disman@ietf.org Subject: [Disman] I-D ACTION:draft-ietf-disman-remops-mib-v2-04.txt X-BeenThere: disman@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Distributed Management List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: disman-bounces@ietf.org Errors-To: disman-bounces@ietf.org --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 : Definitions of Managed Objects for Remote Ping, Traceroute, and Lookup Operations Author(s) : J. Quittek, K. White Filename : draft-ietf-disman-remops-mib-v2-04.txt Pages : 89 Date : 2004-8-9 This memo defines Management Information Bases (MIBs) for performing remote ping, traceroute and lookup operations at a remote host. When managing a network it is useful to be able to initiate and retrieve the results of ping or traceroute operations when performed at a remote host. A Lookup capability is defined in order to enable resolving of either an IP address to an DNS name or an DNS name to an IP address at a remote host. Currently, there are several enterprise-specific MIBs for performing remote ping or traceroute operations. The purpose of this memo is to define a standards-based solution to enable interoperability. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-disman-remops-mib-v2-04.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-remops-mib-v2-04.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-remops-mib-v2-04.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: <2004-8-9154707.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-disman-remops-mib-v2-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-disman-remops-mib-v2-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-8-9154707.I-D@ietf.org> --OtherAccess-- --NextPart-- From disman-bounces@ietf.org Tue Aug 10 14:43:34 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20137 for ; Tue, 10 Aug 2004 14:43:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BubUL-0003uv-77; Tue, 10 Aug 2004 14:36:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuSIy-0007gU-OD for disman@megatron.ietf.org; Tue, 10 Aug 2004 04:48:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03777 for ; Tue, 10 Aug 2004 04:48:22 -0400 (EDT) Received: from syd-iport-1.cisco.com ([64.104.193.196]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BuSNT-0007lO-31 for disman@ietf.org; Tue, 10 Aug 2004 04:53:04 -0400 Received: from india-core-1.cisco.com (64.104.129.221) by syd-iport-1.cisco.com with ESMTP; 10 Aug 2004 18:57:42 +1000 X-BrightmailFiltered: true Received: from ind-mira-01.cisco.com (IDENT:mirapoint@ind-mira-01.cisco.com [64.104.129.12]) by india-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i7A8lRVh016016; Tue, 10 Aug 2004 01:47:28 -0700 (PDT) Received: from kkoushikw2k02 (dhcp-64-104-147-150.cisco.com [64.104.147.150]) by ind-mira-01.cisco.com (MOS 3.4.6-GR) with SMTP id ADY62429; Tue, 10 Aug 2004 14:15:04 +0530 (IST) Message-ID: <07b301c47eb6$b3b90010$96936840@apac.cisco.com> From: "A S Kiran Koushik" To: Date: Tue, 10 Aug 2004 14:17:43 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4922.1500 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4939.300 X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 10 Aug 2004 14:36:44 -0400 Cc: Narayana Pai , Ram Kavasseri Subject: [Disman] Editor for NOTIFICATION-LOG-MIB X-BeenThere: disman@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Distributed Management List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: disman-bounces@ietf.org Errors-To: disman-bounces@ietf.org Content-Transfer-Encoding: 7bit Hi All, After discussion with Ram Kavasseri regarding NOTIFICATION-LOG-MIB I found out that you are looking for an editor for the above MIB. I would like to propose myself for this esteemed position. I have not been active on this list, but I have co-implemented the NOTIFICATION-LOG-MIB for Cisco IOS and have tested it. I have even made it High-Availability aware. I you accept this, I will work with Ram who is the present editor and take the ownership of the editorial activity. Regards, Kiran. From disman-bounces@ietf.org Wed Aug 11 03:35:10 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09685 for ; Wed, 11 Aug 2004 03:35:10 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bunc4-0001s9-34; Wed, 11 Aug 2004 03:33:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BunbF-0001kZ-6G for disman@megatron.ietf.org; Wed, 11 Aug 2004 03:32:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09547 for ; Wed, 11 Aug 2004 03:32:39 -0400 (EDT) Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bunfu-0000NC-Al for disman@ietf.org; Wed, 11 Aug 2004 03:37:33 -0400 Received: from [10.1.1.171] (marseille.netlab.nec.de [195.37.70.15]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 150791BAC95 for ; Wed, 11 Aug 2004 09:31:53 +0200 (CEST) Date: Wed, 11 Aug 2004 09:31:57 +0200 From: Juergen Quittek To: disman@ietf.org Message-ID: <2147483647.1092216717@[10.1.1.171]> In-Reply-To: <200408091925.PAA01566@ietf.org> References: <200408091925.PAA01566@ietf.org> X-Mailer: Mulberry/3.0.3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 Content-Transfer-Encoding: 7bit Subject: [Disman] Re: I-D ACTION:draft-ietf-disman-remops-mib-v2-04.txt X-BeenThere: disman@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Distributed Management List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: disman-bounces@ietf.org Errors-To: disman-bounces@ietf.org Content-Transfer-Encoding: 7bit Dear all, Please find the list of changes between version -03 and version -04 listed at the end of this message. We already discussed the changes on this list and - so far - there are no further open issues left. Thanks, Juergen -- Juergen Quittek quittek@netlab.nec.de Tel: +49 6221 90511-15 NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 Kurfuersten-Anlage 36, 69115 Heidelberg, Germany http://www.netlab.nec.de --On 09.08.2004 15:25 h -0400 Internet-Drafts@ietf.org wrote: > 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 : Definitions of Managed Objects for Remote Ping, Traceroute, and Lookup Operations > Author(s) : J. Quittek, K. White > Filename : draft-ietf-disman-remops-mib-v2-04.txt > Pages : 89 > Date : 2004-8-9 ======================================= changes from version -03 to version -04 ======================================= ======================================================================== 29. Bad numbering of objects in DISMAN-TRACEROUTE-MIB ======================================================================== Problem Description: ------------------------------------------------------------------------ OID { traceRouteGroups 6 } is assigned twice, to traceRouteCtlRowStatusGroup and to traceRouteHistoryGroup ======================================================================== Suggested solution: ------------------------------------------------------------------------ replcace for traceRouteHistoryGroup OLD ::= { traceRouteGroups 6 } with NEW ::= { traceRouteGroups 7 } ======================================================================== Status: solution committed ======================================================================== ======================================================================== 30. traceRouteMinimumCompliancy does not cover traceRouteCtlRowStatusGroup ======================================================================== Problem Description: ------------------------------------------------------------------------ The traceRouteMinimumCompliancy statement does not cover the new traceRouteCtlRowStatusGroup. ======================================================================== Suggested solution: ------------------------------------------------------------------------ add to traceRouteMinimumCompliancy: GROUP traceRouteCtlRowStatusGroup DESCRIPTION "A compliant implementation does not have to implement the traceRouteCtlRowStatusGroup." ======================================================================== Status: solution committed ======================================================================== ======================================================================== 31. Coverage of excessive lookup in security considerations ======================================================================== Problem Description: ------------------------------------------------------------------------ The Security considerations do not describe the threat of excessively using the lookup service. raised by Dan Romascanu ======================================================================== Suggested solution: ------------------------------------------------------------------------ In Section 5. Security Considerations replace OLD In general, both the ping and traceroute functions when used excessively are considered a form of system attack. In the case of ping sending a system requests too often can negatively effect its performance or attempting to connect to what is supposed to be an unused port can be very unpredictable. Excessive use of the traceroute capability can like ping negatively affect system performance. In insecure environments it is RECOMMENDED that the MIBs defined within this memo not be supported. with NEW In general, all three, the ping, traceroute and lookup functions, when used excessively are considered a form of system attack. In the case of ping sending a system requests too often can negatively effect its performance or attempting to connect to what is supposed to be an unused port can be very unpredictable. Excessive use of the traceroute capability can like ping negatively affect system performance. The same applies to excessive use of the lookup service, particularly, if the lookup cannot be resolved locally. In insecure environments it is RECOMMENDED that the MIBs defined within this memo not be supported. ======================================================================== Status: solution committed ======================================================================== From disman-bounces@ietf.org Wed Aug 11 06:29:37 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18717 for ; Wed, 11 Aug 2004 06:29:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuqJS-0005Zi-1d; Wed, 11 Aug 2004 06:26:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuqJD-0005Rp-TK for disman@megatron.ietf.org; Wed, 11 Aug 2004 06:26:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18532 for ; Wed, 11 Aug 2004 06:26:13 -0400 (EDT) Received: from weird-brew.cisco.com ([144.254.15.118] helo=strange-brew.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BuqNx-00037x-1j for disman@ietf.org; Wed, 11 Aug 2004 06:31:09 -0400 Received: from [192.168.0.3] (ams-clip-vpn-dhcp4293.cisco.com [10.61.80.196]) by strange-brew.cisco.com (8.11.7+Sun/8.8.8) with ESMTP id i7BAPfg11450; Wed, 11 Aug 2004 12:25:42 +0200 (CEST) Message-ID: <4119F425.1010105@cisco.com> Date: Wed, 11 Aug 2004 12:25:41 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040514 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Randy Presuhn Subject: Re: [Disman] Event MIB Implementation Survey References: <00b601c41b44$1c123d60$7f1afea9@oemcomputer> <007801c4531b$346875a0$7f1afea9@oemcomputer> In-Reply-To: <007801c4531b$346875a0$7f1afea9@oemcomputer> Content-Type: multipart/alternative; boundary="------------000906060507000901000909" X-Spam-Score: 0.5 (/) X-Scan-Signature: 93df555cbdbcdae9621e5b95d44b301e Cc: me , "Disman \(E-mail\)" X-BeenThere: disman@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Distributed Management List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: disman-bounces@ietf.org Errors-To: disman-bounces@ietf.org This is a multi-part message in MIME format. --------------000906060507000901000909 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi Randy, Sorry for the late reply. Note that some URLs below might require a www.cisco.com login. Implementation Survey for RFC 2981, Event MIB _Module:_ DISMAN-EVENT-MIB _Implementation Source:_ Cisco IOS Release 12.0(12)S was based on the draft-ietf-disman-event-mib-10.txt Release 12.2(4)T is compliant to RFC2981 http://www.cisco.com/en/US/customer/products/sw/iosswrel/ps1834/products_feature_guide09186a00800801fd.html http://www.cisco.com/en/US/products/sw/iosswrel/ps1839/products_feature_guide09186a00800c391a.html _Management Application / Agent:_ Agent <>_GROUPs:_ dismanEventResourceGroup (y/n): y dismanEventTriggerGroup (y/n): y dismanEventObjectsGroup (y/n): y dismanEventEventGroup (y/n): y dismanEventNotificationObjectGroup (y/n): y dismanEventNotificationGroup (y/n): y _OBJECTs:_ mteTriggerTargetTag (ro/rw): ro mteEventSetTargetTag (ro/rw): ro mteTriggerValueIDWildcard (ro/rw): rw mteTriggerContextNameWildcard (ro/rw): ro mteObjectsIDWildcard (ro/rw): rw mteEventSetContextNameWildcard (ro/rw): ro _Deployment / Operational Experience:_ We have a couple of working examples posted on www.cisco.com - The example monitors the locIfInputQueueDrops MIB object for increases http://www.cisco.com/en/US/customer/products/hw/routers/ps133/products_white_paper09186a00801a5a68.shtml - A combined exampled of the EVENT and EXPRESSION MIBs http://www.cisco.com/en/US/tech/tk648/tk362/technologies_configuration_example09186a008023267a.shtml Some other working examples will be posted soon: - Customized notification. A trigger will monitor the status of the ifOperStatus snmp-variable of all the interfaces. When this value changes for one of the interfaces, then a snmp-trap will be sent that will contain some customized fields: ifIndex, ifDescr, ifType, sysLocation, sysName. This example uses the existence + notification functionalities of the EVENT-MIB - Writing the new configuration automatically to a tftp server. A trigger will monitor the status of the ccmHistoryRunningLastChanged snmp-variable. When the value changes (which means that the config was possibly changed), a copy of the current config will be sent to a server via tftp. This example uses the existence + SNMPSet functionalities of the EVENT-MIB - Backup interface A trigger will monitor the status of the ifInOctets snmp-variable of a specific the interface. When the delta reaches a threshold, a secondary line will be brought up using ifOperStatus. When the delta goes below a threshold then the secondary line will be shut down. This example uses the threshold + SNMPSet functionalities of the EVENT-MIB _Comments:_ This MIB has been implemented for a couple of years already, but not widely used. The first issue is that not many customers knew about it. I presented a "Fault Management" update at 2 big events recently (total: 300 customers). After presenting the EVENT MIB, I asked a few questions. To be perfectly accurate, the questions were for both EVENT & EXPRESSION MIB, as those 2 MIBs go along together. The EXPRESSION MIB will triger another email later on; anyway the conclusions are useful for the EVENT MIB. 1. Who knew about this MIBs before Networkers? Just one of two hands up 2. Who consider those 2 MIBs useful in their environments? A majority of hands up 3. Who will be playing with those 2 MIBs back home? I would say 1/3 of the audience. The second issue is that this MIB is not easy to set up. For example, the indexing must be clearly explained with one example. So more examples should be posted to help the easier deployement. Customizing the events in the network elements in time consuming. We don't want to loose the configuration in case of network element reload. The EVENT MIB persistence was introduced http://www.cisco.com/en/US/partner/products/sw/iosswrel/ps1839/products_feature_guide09186a0080087bdc.html Regards, Benoit. --------------000906060507000901000909 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Randy,

Sorry for the late reply.
Note that some URLs below might require a www.cisco.com login.

Implementation Survey for RFC 2981, Event MIB

Module: DISMAN-EVENT-MIB

Implementation Source: 
Cisco IOS
	Release 12.0(12)S was based on the draft-ietf-disman-event-mib-10.txt
	Release 12.2(4)T is compliant to RFC2981
	http://www.cisco.com/en/US/customer/products/sw/iosswrel/ps1834/products_feature_guide09186a00800801fd.html
	http://www.cisco.com/en/US/products/sw/iosswrel/ps1839/products_feature_guide09186a00800c391a.html

Management Application / Agent: Agent
<>GROUPs:
dismanEventResourceGroup (y/n): y
dismanEventTriggerGroup (y/n): y
dismanEventObjectsGroup (y/n): y
dismanEventEventGroup (y/n): y
dismanEventNotificationObjectGroup (y/n): y
dismanEventNotificationGroup (y/n): y

OBJECTs:
mteTriggerTargetTag (ro/rw): ro
mteEventSetTargetTag (ro/rw): ro
mteTriggerValueIDWildcard (ro/rw): rw
mteTriggerContextNameWildcard (ro/rw): ro
mteObjectsIDWildcard (ro/rw): rw
mteEventSetContextNameWildcard (ro/rw): ro

Deployment / Operational Experience:
We have a couple of working examples posted on www.cisco.com
- The example monitors the locIfInputQueueDrops MIB object for increases
http://www.cisco.com/en/US/customer/products/hw/routers/ps133/products_white_paper09186a00801a5a68.shtml

- A combined exampled of the EVENT and EXPRESSION MIBs
http://www.cisco.com/en/US/tech/tk648/tk362/technologies_configuration_example09186a008023267a.shtml

Some other working examples will be posted soon:
- Customized notification.
A trigger will monitor the status of the ifOperStatus snmp-variable of all the interfaces. When this value changes for one of the interfaces, then a snmp-trap will be sent that will contain some customized fields: ifIndex, ifDescr, ifType, sysLocation, sysName.
This example uses the existence + notification functionalities of the EVENT-MIB

- Writing the new configuration automatically to a tftp server.
A trigger will monitor the status of the ccmHistoryRunningLastChanged snmp-variable. When the value
changes (which means that the config was possibly changed), a copy of the current config will be sent to a server via tftp.
This example uses the existence + SNMPSet functionalities of the EVENT-MIB

- Backup interface
A trigger will monitor the status of the ifInOctets snmp-variable of a specific the interface. When the delta reaches a threshold, a secondary line will be brought up using ifOperStatus. When the delta goes below a threshold then the secondary line will be shut down.
This example uses the threshold + SNMPSet functionalities of the EVENT-MIB 
Comments:
This MIB has been implemented for a couple of years already, but not widely used.
The first issue is that not many customers knew about it.
I presented a "Fault Management" update at 2 big events recently (total: 300 customers). After presenting the EVENT MIB, I asked a few questions. To be perfectly accurate, the questions were for both EVENT & EXPRESSION MIB, as those 2 MIBs go along together. The EXPRESSION MIB will triger another email later on; anyway the conclusions are useful for the EVENT MIB.
	1. Who knew about this MIBs before Networkers?
           Just one of two hands up
        2. Who consider those 2 MIBs useful in their environments?
           A majority of hands up
        3. Who will be playing with those 2 MIBs back home?
           I would say 1/3 of the audience.
The second issue is that this MIB is not easy to set up. For example, the indexing must be clearly explained with one example. So more examples should be posted to help the easier deployement.

Customizing the events in the network elements in time consuming. We don't want to loose the configuration in case of network element reload. The EVENT MIB persistence was introduced
http://www.cisco.com/en/US/partner/products/sw/iosswrel/ps1839/products_feature_guide09186a0080087bdc.html

Regards, Benoit.
--------------000906060507000901000909-- From disman-bounces@ietf.org Wed Aug 11 06:36:11 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19056 for ; Wed, 11 Aug 2004 06:36:11 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuqRE-0006ah-Gn; Wed, 11 Aug 2004 06:34:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuqQc-0006RX-AP for disman@megatron.ietf.org; Wed, 11 Aug 2004 06:33:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18928 for ; Wed, 11 Aug 2004 06:33:51 -0400 (EDT) Received: from weird-brew.cisco.com ([144.254.15.118] helo=strange-brew.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BuqVL-0003Ek-M9 for disman@ietf.org; Wed, 11 Aug 2004 06:38:48 -0400 Received: from [192.168.0.3] (ams-clip-vpn-dhcp4293.cisco.com [10.61.80.196]) by strange-brew.cisco.com (8.11.7+Sun/8.8.8) with ESMTP id i7BAXMg16133 for ; Wed, 11 Aug 2004 12:33:22 +0200 (CEST) Message-ID: <4119F5F2.1010902@cisco.com> Date: Wed, 11 Aug 2004 12:33:22 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040514 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Disman (E-mail)" Content-Type: multipart/alternative; boundary="------------050003060504030408090508" X-Spam-Score: 0.5 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 Subject: [Disman] Event MIB - some more examples? X-BeenThere: disman@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Distributed Management List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: disman-bounces@ietf.org Errors-To: disman-bounces@ietf.org This is a multi-part message in MIME format. --------------050003060504030408090508 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Dear all, As you probably saw from my previous email, we have implemented the EVENT-MIB. In order to advertise this MIB, I'm thinking to post some extra useful examples. This MIB is very flexible, but finding the right examples is not that easy... I mean examples with a good business case. Currently, our working examples are: - Customized notification. A trigger will monitor the status of the ifOperStatus snmp-variable of all the interfaces. When this value changes for one of the interfaces, then a snmp-trap will be sent that will contain some customized fields: ifIndex, ifDescr, ifType, sysLocation, sysName. This example uses the existence + notification functionalities of the EVENT-MIB - Writing the new configuration automatically to a tftp server. A trigger will monitor the status of the ccmHistoryRunningLastChanged snmp-variable. When the value changes (which means that the config was possibly changed), a copy of the current config will be sent to a server via tftp. This example uses the existence + SNMPSet functionalities of the EVENT-MIB - Backup interface A trigger will monitor the status of the ifInOctets snmp-variable of a specific the interface. When the delta reaches a threshold, a secondary line will be brought up using ifOperStatus. When the delta goes below a threshold then the secondary line will be shut down. This example uses the threshold + SNMPSet functionalities of the EVENT-MIB I'm wondering if you have in mind other good examples. I would be happy to test them and to post the serie of SNMPSet commands. Please let me know. Regards, Benoit. _ _ --------------050003060504030408090508 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Dear all,

As you probably saw from my previous email, we have implemented the EVENT-MIB.
In order to advertise this MIB, I'm thinking to post some extra useful examples.
This MIB is very flexible, but finding the right examples is not that easy... I mean examples with a good business case.

Currently, our working examples are:

- Customized notification.
A trigger will monitor the status of the ifOperStatus snmp-variable of all the interfaces. When this value changes for one of the interfaces, then a snmp-trap will be sent that will contain some customized fields: ifIndex, ifDescr, ifType, sysLocation, sysName.
This example uses the existence + notification functionalities of the EVENT-MIB

- Writing the new configuration automatically to a tftp server.
A trigger will monitor the status of the ccmHistoryRunningLastChanged snmp-variable. When the value
changes (which means that the config was possibly changed), a copy of the current config will be sent to a server via tftp.
This example uses the existence + SNMPSet functionalities of the EVENT-MIB

- Backup interface
A trigger will monitor the status of the ifInOctets snmp-variable of a specific the interface. When the delta reaches a threshold, a secondary line will be brought up using ifOperStatus. When the delta goes below a threshold then the secondary line will be shut down.
This example uses the threshold + SNMPSet functionalities of the EVENT-MIB

I'm wondering if you have in mind other good examples.
I would be happy to test them and to post the serie of SNMPSet commands.

Please let me know.

Regards, Benoit.
--------------050003060504030408090508-- From disman-bounces@ietf.org Wed Aug 11 12:34:33 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17271 for ; Wed, 11 Aug 2004 12:34:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuvsK-00067V-JQ; Wed, 11 Aug 2004 12:22:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Buvlt-0004Tu-5b for disman@megatron.ietf.org; Wed, 11 Aug 2004 12:16:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16312 for ; Wed, 11 Aug 2004 12:16:10 -0400 (EDT) Received: from weird-brew.cisco.com ([144.254.15.118] helo=strange-brew.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Buvqb-0002LA-3Y for disman@ietf.org; Wed, 11 Aug 2004 12:21:10 -0400 Received: from [192.168.0.3] (ams-clip-vpn-dhcp4293.cisco.com [10.61.80.196]) by strange-brew.cisco.com (8.11.7+Sun/8.8.8) with ESMTP id i7BGFVg08298; Wed, 11 Aug 2004 18:15:31 +0200 (CEST) Message-ID: <411A4623.7030309@cisco.com> Date: Wed, 11 Aug 2004 18:15:31 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040514 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Benoit Claise Subject: Re: [Disman] Event MIB Implementation Survey References: <00b601c41b44$1c123d60$7f1afea9@oemcomputer> <007801c4531b$346875a0$7f1afea9@oemcomputer> <4119F425.1010105@cisco.com> In-Reply-To: <4119F425.1010105@cisco.com> Content-Type: multipart/alternative; boundary="------------020507020504050202020708" X-Spam-Score: 0.5 (/) X-Scan-Signature: 76c7db407a166e4c39f35d8215d8dd32 Cc: Randy Presuhn , "Disman \(E-mail\)" X-BeenThere: disman@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Distributed Management List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: disman-bounces@ietf.org Errors-To: disman-bounces@ietf.org This is a multi-part message in MIME format. --------------020507020504050202020708 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Benoit Claise wrote: > Hi Randy, > > Sorry for the late reply. > Note that some URLs below might require a www.cisco.com login. > >Implementation Survey for RFC 2981, Event MIB > >_Module:_ DISMAN-EVENT-MIB > >_Implementation Source:_ >Cisco IOS > Release 12.0(12)S was based on the draft-ietf-disman-event-mib-10.txt > Release 12.2(4)T is compliant to RFC2981 > http://www.cisco.com/en/US/customer/products/sw/iosswrel/ps1834/products_feature_guide09186a00800801fd.html > http://www.cisco.com/en/US/products/sw/iosswrel/ps1839/products_feature_guide09186a00800c391a.html > > >_Management Application / Agent:_ Agent > > > <>_GROUPs:_ > dismanEventResourceGroup (y/n): y > dismanEventTriggerGroup (y/n): y > dismanEventObjectsGroup (y/n): y > dismanEventEventGroup (y/n): y > dismanEventNotificationObjectGroup (y/n): y > dismanEventNotificationGroup (y/n): y > > _OBJECTs:_ > mteTriggerTargetTag (ro/rw): ro > mteEventSetTargetTag (ro/rw): ro > mteTriggerValueIDWildcard (ro/rw): rw > mteTriggerContextNameWildcard (ro/rw): ro > mteObjectsIDWildcard (ro/rw): rw > mteEventSetContextNameWildcard (ro/rw): ro Actually, when I wrote ro, I wanted to say that remote monitoring and context wildcarding are not implemented. So potentially, the right answer should: no Regards, Benoit > > _Deployment / Operational Experience:_ > We have a couple of working examples posted on www.cisco.com > - The example monitors the locIfInputQueueDrops MIB object for increases > http://www.cisco.com/en/US/customer/products/hw/routers/ps133/products_white_paper09186a00801a5a68.shtml > > - A combined exampled of the EVENT and EXPRESSION MIBs > http://www.cisco.com/en/US/tech/tk648/tk362/technologies_configuration_example09186a008023267a.shtml > > Some other working examples will be posted soon: > - Customized notification. > A trigger will monitor the status of the ifOperStatus snmp-variable of > all the interfaces. When this value changes for one of the interfaces, > then a snmp-trap will be sent that will contain some customized > fields: ifIndex, ifDescr, ifType, sysLocation, sysName. > This example uses the existence + notification functionalities of the > EVENT-MIB > > - Writing the new configuration automatically to a tftp server. > A trigger will monitor the status of the ccmHistoryRunningLastChanged > snmp-variable. When the value > changes (which means that the config was possibly changed), a copy of > the current config will be sent to a server via tftp. > This example uses the existence + SNMPSet functionalities of the EVENT-MIB > > - Backup interface > A trigger will monitor the status of the ifInOctets snmp-variable of a > specific the interface. When the delta reaches a threshold, a > secondary line will be brought up using ifOperStatus. When the delta > goes below a threshold then the secondary line will be shut down. > This example uses the threshold + SNMPSet functionalities of the > EVENT-MIB > >_Comments:_ >This MIB has been implemented for a couple of years already, but not widely used. >The first issue is that not many customers knew about it. >I presented a "Fault Management" update at 2 big events recently (total: 300 customers). After presenting the EVENT MIB, I asked a few questions. To be perfectly accurate, the questions were for both EVENT & EXPRESSION MIB, as those 2 MIBs go along together. The EXPRESSION MIB will triger another email later on; anyway the conclusions are useful for the EVENT MIB. > 1. Who knew about this MIBs before Networkers? > Just one of two hands up > 2. Who consider those 2 MIBs useful in their environments? > A majority of hands up > 3. Who will be playing with those 2 MIBs back home? > I would say 1/3 of the audience. >The second issue is that this MIB is not easy to set up. For example, the indexing must be clearly explained with one example. So more examples should be posted to help the easier deployement. > >Customizing the events in the network elements in time consuming. We don't want to loose the configuration in case of network element reload. The EVENT MIB persistence was introduced >http://www.cisco.com/en/US/partner/products/sw/iosswrel/ps1839/products_feature_guide09186a0080087bdc.html > >Regards, Benoit. > > > --------------020507020504050202020708 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Benoit Claise wrote:
Hi Randy,

Sorry for the late reply.
Note that some URLs below might require a www.cisco.com login.

Implementation Survey for RFC 2981, Event MIB

Module: DISMAN-EVENT-MIB

Implementation Source: 
Cisco IOS
	Release 12.0(12)S was based on the draft-ietf-disman-event-mib-10.txt
	Release 12.2(4)T is compliant to RFC2981
	http://www.cisco.com/en/US/customer/products/sw/iosswrel/ps1834/products_feature_guide09186a00800801fd.html
	http://www.cisco.com/en/US/products/sw/iosswrel/ps1839/products_feature_guide09186a00800c391a.html
  
Management Application / Agent: Agent
<>GROUPs:
dismanEventResourceGroup (y/n): y
dismanEventTriggerGroup (y/n): y
dismanEventObjectsGroup (y/n): y
dismanEventEventGroup (y/n): y
dismanEventNotificationObjectGroup (y/n): y
dismanEventNotificationGroup (y/n): y

OBJECTs:
mteTriggerTargetTag (ro/rw): ro
mteEventSetTargetTag (ro/rw): ro
mteTriggerValueIDWildcard (ro/rw): rw
mteTriggerContextNameWildcard (ro/rw): ro
mteObjectsIDWildcard (ro/rw): rw
mteEventSetContextNameWildcard (ro/rw): ro
Actually, when I wrote ro, I wanted to say that remote monitoring and context wildcarding are not implemented.
So potentially, the right answer should: no

Regards, Benoit

Deployment / Operational Experience:
We have a couple of working examples posted on www.cisco.com
- The example monitors the locIfInputQueueDrops MIB object for increases
http://www.cisco.com/en/US/customer/products/hw/routers/ps133/products_white_paper09186a00801a5a68.shtml

- A combined exampled of the EVENT and EXPRESSION MIBs
http://www.cisco.com/en/US/tech/tk648/tk362/technologies_configuration_example09186a008023267a.shtml

Some other working examples will be posted soon:
- Customized notification.
A trigger will monitor the status of the ifOperStatus snmp-variable of all the interfaces. When this value changes for one of the interfaces, then a snmp-trap will be sent that will contain some customized fields: ifIndex, ifDescr, ifType, sysLocation, sysName.
This example uses the existence + notification functionalities of the EVENT-MIB

- Writing the new configuration automatically to a tftp server.
A trigger will monitor the status of the ccmHistoryRunningLastChanged snmp-variable. When the value
changes (which means that the config was possibly changed), a copy of the current config will be sent to a server via tftp.
This example uses the existence + SNMPSet functionalities of the EVENT-MIB

- Backup interface
A trigger will monitor the status of the ifInOctets snmp-variable of a specific the interface. When the delta reaches a threshold, a secondary line will be brought up using ifOperStatus. When the delta goes below a threshold then the secondary line will be shut down.
This example uses the threshold + SNMPSet functionalities of the EVENT-MIB 
Comments:
This MIB has been implemented for a couple of years already, but not widely used.
The first issue is that not many customers knew about it.
I presented a "Fault Management" update at 2 big events recently (total: 300 customers). After presenting the EVENT MIB, I asked a few questions. To be perfectly accurate, the questions were for both EVENT & EXPRESSION MIB, as those 2 MIBs go along together. The EXPRESSION MIB will triger another email later on; anyway the conclusions are useful for the EVENT MIB.
	1. Who knew about this MIBs before Networkers?
           Just one of two hands up
        2. Who consider those 2 MIBs useful in their environments?
           A majority of hands up
        3. Who will be playing with those 2 MIBs back home?
           I would say 1/3 of the audience.
The second issue is that this MIB is not easy to set up. For example, the indexing must be clearly explained with one example. So more examples should be posted to help the easier deployement.

Customizing the events in the network elements in time consuming. We don't want to loose the configuration in case of network element reload. The EVENT MIB persistence was introduced
http://www.cisco.com/en/US/partner/products/sw/iosswrel/ps1839/products_feature_guide09186a0080087bdc.html

Regards, Benoit.

--------------020507020504050202020708-- From disman-bounces@ietf.org Wed Aug 11 15:25:21 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01477 for ; Wed, 11 Aug 2004 15:25:21 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuyQr-0003om-UZ; Wed, 11 Aug 2004 15:06:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuyKV-0004XY-LR for disman@megatron.ietf.org; Wed, 11 Aug 2004 15:00:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27743 for ; Wed, 11 Aug 2004 15:00:05 -0400 (EDT) Received: from mallard.mail.pas.earthlink.net ([207.217.120.48]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BuyPJ-0005VD-Gr for disman@ietf.org; Wed, 11 Aug 2004 15:05:05 -0400 Received: from h-66-167-205-28.snvacaid.dynamic.covad.net ([66.167.205.28] helo=oemcomputer) by mallard.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1BuyKN-0003EW-00 for disman@ietf.org; Wed, 11 Aug 2004 11:59:59 -0700 Message-ID: <001101c47fd5$cda94280$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" References: <00b601c41b44$1c123d60$7f1afea9@oemcomputer> <007801c4531b$346875a0$7f1afea9@oemcomputer><4119F425.1010105@cisco.com> <411A4623.7030309@cisco.com> Subject: Re: [Disman] Event MIB Implementation Survey Date: Wed, 11 Aug 2004 12:02:52 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.0 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 X-BeenThere: disman@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Distributed Management List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: disman-bounces@ietf.org Errors-To: disman-bounces@ietf.org Hi - Thanks for the implementation report and the clarification. Randy > From: "Benoit Claise" > To: "Benoit Claise" > Cc: "Randy Presuhn" ; "Disman (E-mail)" > Sent: Wednesday, August 11, 2004 9:15 AM > Subject: Re: [Disman] Event MIB Implementation Survey > > Benoit Claise wrote: > > > Hi Randy, > > > > Sorry for the late reply. > > Note that some URLs below might require a www.cisco.com login. > > > >Implementation Survey for RFC 2981, Event MIB > > > >_Module:_ DISMAN-EVENT-MIB > > > >_Implementation Source:_ > >Cisco IOS > > Release 12.0(12)S was based on the draft-ietf-disman-event-mib-10.txt > > Release 12.2(4)T is compliant to RFC2981 > > http://www.cisco.com/en/US/customer/products/sw/iosswrel/ps1834/products_feature_guide09186a00800801fd.html > > http://www.cisco.com/en/US/products/sw/iosswrel/ps1839/products_feature_guide09186a00800c391a.html > > > > > >_Management Application / Agent:_ Agent > > > > > > <>_GROUPs:_ > > dismanEventResourceGroup (y/n): y > > dismanEventTriggerGroup (y/n): y > > dismanEventObjectsGroup (y/n): y > > dismanEventEventGroup (y/n): y > > dismanEventNotificationObjectGroup (y/n): y > > dismanEventNotificationGroup (y/n): y > > > > _OBJECTs:_ > > mteTriggerTargetTag (ro/rw): ro > > mteEventSetTargetTag (ro/rw): ro > > mteTriggerValueIDWildcard (ro/rw): rw > > mteTriggerContextNameWildcard (ro/rw): ro > > mteObjectsIDWildcard (ro/rw): rw > > mteEventSetContextNameWildcard (ro/rw): ro > > Actually, when I wrote ro, I wanted to say that remote monitoring and > context wildcarding are not implemented. > So potentially, the right answer should: no > > Regards, Benoit > > > > > _Deployment / Operational Experience:_ > > We have a couple of working examples posted on www.cisco.com > > - The example monitors the locIfInputQueueDrops MIB object for increases > > http://www.cisco.com/en/US/customer/products/hw/routers/ps133/products_white_paper09186a00801a5a68.shtml > > > > - A combined exampled of the EVENT and EXPRESSION MIBs > > http://www.cisco.com/en/US/tech/tk648/tk362/technologies_configuration_example09186a008023267a.shtml > > > > Some other working examples will be posted soon: > > - Customized notification. > > A trigger will monitor the status of the ifOperStatus snmp-variable of > > all the interfaces. When this value changes for one of the interfaces, > > then a snmp-trap will be sent that will contain some customized > > fields: ifIndex, ifDescr, ifType, sysLocation, sysName. > > This example uses the existence + notification functionalities of the > > EVENT-MIB > > > > - Writing the new configuration automatically to a tftp server. > > A trigger will monitor the status of the ccmHistoryRunningLastChanged > > snmp-variable. When the value > > changes (which means that the config was possibly changed), a copy of > > the current config will be sent to a server via tftp. > > This example uses the existence + SNMPSet functionalities of the EVENT-MIB > > > > - Backup interface > > A trigger will monitor the status of the ifInOctets snmp-variable of a > > specific the interface. When the delta reaches a threshold, a > > secondary line will be brought up using ifOperStatus. When the delta > > goes below a threshold then the secondary line will be shut down. > > This example uses the threshold + SNMPSet functionalities of the > > EVENT-MIB > > > >_Comments:_ > >This MIB has been implemented for a couple of years already, but not widely used. > >The first issue is that not many customers knew about it. > >I presented a "Fault Management" update at 2 big events recently (total: 300 customers). After presenting the EVENT MIB, I asked a few questions. To be perfectly accurate, the questions were for both EVENT & EXPRESSION MIB, as those 2 MIBs go along together. The EXPRESSION MIB will triger another email later on; anyway the conclusions are useful for the EVENT MIB. > > 1. Who knew about this MIBs before Networkers? > > Just one of two hands up > > 2. Who consider those 2 MIBs useful in their environments? > > A majority of hands up > > 3. Who will be playing with those 2 MIBs back home? > > I would say 1/3 of the audience. > >The second issue is that this MIB is not easy to set up. For example, the indexing must be clearly explained with one example. So more examples should be posted to help the easier deployement. > > > >Customizing the events in the network elements in time consuming. We don't want to loose the configuration in case of network element reload. The EVENT MIB persistence was introduced > >http://www.cisco.com/en/US/partner/products/sw/iosswrel/ps1839/products_feature_guide09186a0080087bdc.html > > > >Regards, Benoit. > > > > > > > > From disman-bounces@ietf.org Fri Aug 27 09:41:40 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29016 for ; Fri, 27 Aug 2004 09:41:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0gtc-0000b6-RJ; Fri, 27 Aug 2004 09:36:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0gjD-0007Qp-GV for disman@megatron.ietf.org; Fri, 27 Aug 2004 09:25:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28214 for ; Fri, 27 Aug 2004 09:25:13 -0400 (EDT) Received: from w194.mcl-va.us.cnc.net ([205.158.158.194] helo=thinkmailsrvr.bos.thinkengine.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C0gkM-0001CR-QS for disman@ietf.org; Fri, 27 Aug 2004 09:26:27 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C48C39.2FD357B0" Date: Fri, 27 Aug 2004 09:24:31 -0400 Message-ID: Thread-Topic: Status of DISMAN-EVENT-MIB? Thread-Index: AcSMOS/YXzv3dW7jSl+Cqcmslr5t4Q== From: "Chapman, Ken" To: X-Spam-Score: 0.1 (/) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 Cc: Paul.Gagne@ietf.org Subject: [Disman] Status of DISMAN-EVENT-MIB? X-BeenThere: disman@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Distributed Management List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: disman-bounces@ietf.org Errors-To: disman-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C48C39.2FD357B0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, What is the status of DISMAN-EVENT-MIB?=20 I have a copy of draft-ietf-disman-event-mib-v2-01, which fixed some things. =20 Is there a more recent ID? Will these changes ever make it into an RFC? Are there any plans to progress this MIB to Draft Standard? =20 Ken Chapman ThinkEngine Networks, Inc. 100 Nickerson Road Marlborough, MA 01752 Phone: +1 508 597 0460 =20 ------_=_NextPart_001_01C48C39.2FD357B0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

What is the status of DISMAN-EVENT-MIB? =

I have a copy of draft-ietf-disman-event-mib-v2-01, = which fixed some things. 

Is there a more recent ID?

Will these changes ever make it into an = RFC?

Are there any plans to progress this MIB to Draft = Standard?

 

Ken Chapman

ThinkEngine Networks, Inc.

100 Nickerson Road

Marlborough, MA 01752

Phone: +1 508 597 0460

 

=00 ------_=_NextPart_001_01C48C39.2FD357B0-- From disman-bounces@ietf.org Fri Aug 27 09:52:00 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29687 for ; Fri, 27 Aug 2004 09:52:00 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0h74-0003q0-AV; Fri, 27 Aug 2004 09:49:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C0h5N-0003RU-Kr for disman@megatron.ietf.org; Fri, 27 Aug 2004 09:48:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29541 for ; Fri, 27 Aug 2004 09:48:07 -0400 (EDT) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C0h6U-0001bx-5a for disman@ietf.org; Fri, 27 Aug 2004 09:49:21 -0400 X-BrightmailFiltered: true Received: from mira-sjc5-d.cisco.com (IDENT:mirapoint@mira-sjc5-d.cisco.com [171.71.163.28]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id i7RDk7mk023726; Fri, 27 Aug 2004 06:46:07 -0700 (PDT) Received: from cisco.com (sjc-vpn5-585.cisco.com [10.21.90.73]) by mira-sjc5-d.cisco.com (MOS 3.4.6-GR) with ESMTP id AEB83672; Fri, 27 Aug 2004 06:46:05 -0700 (PDT) Message-ID: <412F3B22.9020003@cisco.com> Date: Fri, 27 Aug 2004 06:46:10 -0700 From: Ramanathan Kavasseri User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Chapman, Ken" Subject: Re: [Disman] Status of DISMAN-EVENT-MIB? References: Content-Type: multipart/alternative; boundary="------------000709070801070503060702" X-Spam-Score: 0.7 (/) X-Scan-Signature: 3d7f2f6612d734db849efa86ea692407 Cc: disman@ietf.org, Paul.Gagne@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ramk@cisco.com List-Id: Distributed Management List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: disman-bounces@ietf.org Errors-To: disman-bounces@ietf.org --------------000709070801070503060702 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Chapman, Ken wrote: > Hi, > > What is the status of DISMAN-EVENT-MIB? > > I have a copy of draft-ietf-disman-event-mib-v2-01, which fixed some > things. > > Is there a more recent ID? > > Will these changes ever make it into an RFC? > > Are there any plans to progress this MIB to Draft Standard? > Ken, will post the latest rev today. Ram > > > Ken Chapman > > ThinkEngine Networks, Inc. > > 100 Nickerson Road > > Marlborough, MA 01752 > > Phone: +1 508 597 0460 > > > --------------000709070801070503060702 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit

Chapman, Ken wrote:

Hi,

What is the status of DISMAN-EVENT-MIB?

I have a copy of draft-ietf-disman-event-mib-v2-01, which fixed some things. 

Is there a more recent ID?

Will these changes ever make it into an RFC?

Are there any plans to progress this MIB to Draft Standard?

Ken,

will post the latest rev today.

Ram

 

Ken Chapman

ThinkEngine Networks, Inc.

100 Nickerson Road

Marlborough, MA 01752

Phone: +1 508 597 0460

 


--------------000709070801070503060702--