From owner-disman@dorothy.bmc.com Tue Apr 2 18:01:27 2002 Received: from babbler.bmc.com (firebird.bmc.com [198.207.223.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07096 for ; Tue, 2 Apr 2002 18:01:26 -0500 (EST) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g32N4DG14104; Tue, 2 Apr 2002 17:04:13 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id OAA19447 for disman-list; Tue, 2 Apr 2002 14:57:01 -0800 (PST) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id OAA19437; Tue, 2 Apr 2002 14:56:56 -0800 (PST) Received: from mx-us-hou-1-int.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id g32Msss10584; Tue, 2 Apr 2002 16:54:54 -0600 (CST) Received: from tnt.isi.edu (unknown [128.9.128.128]) by mx-us-hou-1-int.bmc.com (Postfix) with SMTP id B9F8320EFAB; Tue, 2 Apr 2002 16:58:27 -0600 (CST) Received: from jet.isi.edu (jet.isi.edu [128.9.160.87]) by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id g32MwMp16340; Tue, 2 Apr 2002 14:58:22 -0800 (PST) From: RFC Editor Received: (from rfc-ed@localhost) by jet.isi.edu (8.8.7/8.8.6) id WAA10573; Tue, 2 Apr 2002 22:58:22 GMT Date: Tue, 2 Apr 2002 22:58:22 GMT Message-Id: <200204022258.WAA10573@jet.isi.edu> To: rfc-editor@rfc-editor.org, rpresuhn@dorothy.bmc.com Subject: Re: RFC 2925 erratum Cc: disman@dorothy.bmc.com X-Sun-Charset: ISO-8859-1 Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list Randy, We have added this to our errata page... Thank you. RFC Editor > From rfc-ed@ISI.EDU Tue Mar 26 15:18:57 2002 > Date: Tue, 26 Mar 2002 15:16:54 -0800 (PST) > From: Randy Presuhn > To: rfc-editor@rfc-editor.org > Subject: RFC 2925 erratum > Cc: disman@dorothy.bmc.com > Mime-Version: 1.0 > Content-Transfer-Encoding: 8bit > X-AntiVirus: scanned by AMaViS 0.2.1 > > Hi - > > As disman working group chair, I'd like to report a typo in > RFC 2925, "Definitions of Managed Objects for Remote Ping, > Traceroute, and Lookup Operations", September 2000. > > On page 32, there is a typo in the DESCRIPTION of pingTestCompleted. > > "Generated at the completion of a ping test when the > corresponding pingCtlTrapGeneration object is set to > testCompletion(4)." > > Should be: > > "Generated at the completion of a ping test when the > corresponding pingCtlTrapGeneration object is set to > testCompletion(2)." > > This correction has been discussed and agreed on the working > group's mailing list. > > ------------------------------------------------------ > Randy Presuhn BMC Software, Inc. 1-3141 > randy_presuhn@bmc.com 2141 North First Street > Tel: +1 408 546-1006 San José, California 95131 USA > ------------------------------------------------------ > My opinions and BMC's are independent variables. > ------------------------------------------------------ > From owner-disman@dorothy.bmc.com Tue Apr 2 19:11:03 2002 Received: from babbler.bmc.com (camaro.bmc.com [198.207.223.231]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09033 for ; Tue, 2 Apr 2002 19:11:03 -0500 (EST) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g330Dx522352; Tue, 2 Apr 2002 18:13:59 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id QAA20450 for disman-list; Tue, 2 Apr 2002 16:08:12 -0800 (PST) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id QAA20442; Tue, 2 Apr 2002 16:08:07 -0800 (PST) Received: from mx-us-hou-1-int.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id g33065Z12512; Tue, 2 Apr 2002 18:06:05 -0600 (CST) Received: from auemail1.firewall.lucent.com (unknown [192.11.223.161]) by mx-us-hou-1-int.bmc.com (Postfix) with SMTP id 320E620EFB2; Tue, 2 Apr 2002 18:09:38 -0600 (CST) Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by auemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g3309Vp23534; Tue, 2 Apr 2002 19:09:31 -0500 (EST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2653.19) id ; Wed, 3 Apr 2002 02:09:30 +0200 Message-ID: From: "Wijnen, Bert (Bert)" To: RFC Editor , rfc-editor@rfc-editor.org, rpresuhn@dorothy.bmc.com Cc: disman@dorothy.bmc.com Subject: RE: RFC 2925 erratum Date: Wed, 3 Apr 2002 02:09:29 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list Thank you! Bert > -----Original Message----- > From: RFC Editor [mailto:rfc-ed@ISI.EDU] > Sent: Wednesday, April 03, 2002 12:58 AM > To: rfc-editor@rfc-editor.org; rpresuhn@dorothy.bmc.com > Cc: disman@dorothy.bmc.com > Subject: Re: RFC 2925 erratum > > > Randy, > > We have added this to our errata page... > > Thank you. > > RFC Editor > > > > From rfc-ed@ISI.EDU Tue Mar 26 15:18:57 2002 > > Date: Tue, 26 Mar 2002 15:16:54 -0800 (PST) > > From: Randy Presuhn > > To: rfc-editor@rfc-editor.org > > Subject: RFC 2925 erratum > > Cc: disman@dorothy.bmc.com > > Mime-Version: 1.0 > > Content-Transfer-Encoding: 8bit > > X-AntiVirus: scanned by AMaViS 0.2.1 > > > > Hi - > > > > As disman working group chair, I'd like to report a typo in > > RFC 2925, "Definitions of Managed Objects for Remote Ping, > > Traceroute, and Lookup Operations", September 2000. > > > > On page 32, there is a typo in the DESCRIPTION of pingTestCompleted. > > > > "Generated at the completion of a ping test when the > > corresponding pingCtlTrapGeneration object is set to > > testCompletion(4)." > > > > Should be: > > > > "Generated at the completion of a ping test when the > > corresponding pingCtlTrapGeneration object is set to > > testCompletion(2)." > > > > This correction has been discussed and agreed on the working > > group's mailing list. > > > > ------------------------------------------------------ > > Randy Presuhn BMC Software, Inc. 1-3141 > > randy_presuhn@bmc.com 2141 North First Street > > Tel: +1 408 546-1006 San Jose, California 95131 USA > > ------------------------------------------------------ > > My opinions and BMC's are independent variables. > > ------------------------------------------------------ > > > From owner-disman@dorothy.bmc.com Tue Apr 2 20:39:40 2002 Received: from babbler.bmc.com (camaro.bmc.com [198.207.223.231]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11120 for ; Tue, 2 Apr 2002 20:39:39 -0500 (EST) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g331fAW00250; Tue, 2 Apr 2002 19:41:10 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id RAA21876 for disman-list; Tue, 2 Apr 2002 17:35:18 -0800 (PST) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id RAA21870 for disman@dorothy.bmc.com; Tue, 2 Apr 2002 17:35:14 -0800 (PST) Date: Tue, 2 Apr 2002 17:35:14 -0800 (PST) From: Randy Presuhn Message-Id: <200204030135.RAA21870@dorothy.bmc.com> To: disman@dorothy.bmc.com Subject: Re: Alarm MIB WG last call 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 - Private email has made it clear that some folks didn't read the attached message. Make no mistake: disman WG last call on the alarm MIB began March 28 when the draft appeared. The WG last call will end 5 p.m. Pacific Daylight Time on April 11, 2002. ------------------------------------------------------ Randy Presuhn BMC Software, Inc. 1-3141 randy_presuhn@bmc.com 2141 North First Street Tel: +1 408 546-1006 San José, California 95131 USA ------------------------------------------------------ My opinions and BMC's are independent variables. ------------------------------------------------------ > From owner-disman@dorothy.bmc.com Mon Mar 18 13:08:39 PST 2002 > Date: Mon, 18 Mar 2002 13:08:17 -0800 (PST) > From: Randy Presuhn > Message-Id: <200203182108.NAA19616@dorothy.bmc.com> > To: disman@dorothy.bmc.com > Subject: Alarm MIB WG last call > List-Id: IETF disman Working Group mailing list > > Hi - > > We finished a first WG last call on the alarm MIB, and, > *surprise* found that some revisions were needed. I've talked > to some of the folks active in the discussion, and as disman > WG chair have decided that, when the revision appears, another > two-week WG last call on the document would be appropriate. > This last call will begin when the revised I-D becomes available. > > As with the previous last call, I would appreciate a (personal) > note from those who have read the document but not felt the > need to comment on the WG mailing list, so that I might better > assess how much review it has actually received. > > ------------------------------------------------------ > Randy Presuhn BMC Software, Inc. 1-3141 > randy_presuhn@bmc.com 2141 North First Street > Tel: +1 408 546-1006 San José, California 95131 USA > ------------------------------------------------------ > My opinions and BMC's are independent variables. > ------------------------------------------------------ > From owner-disman@dorothy.bmc.com Tue Apr 2 20:59:23 2002 Received: from babbler.bmc.com (camaro.bmc.com [198.207.223.231]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11302 for ; Tue, 2 Apr 2002 20:59:23 -0500 (EST) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g3322M402055; Tue, 2 Apr 2002 20:02:22 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id RAA21941 for disman-list; Tue, 2 Apr 2002 17:56:31 -0800 (PST) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id RAA21935; Tue, 2 Apr 2002 17:56:27 -0800 (PST) Received: from mx-us-hou-2-int.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id g331sQ226927; Tue, 2 Apr 2002 19:54:26 -0600 (CST) Received: from riverstonenet.com (mail.riverstonenet.com [63.113.148.10]) by mx-us-hou-2-int.bmc.com (Postfix) with SMTP id EEAE51FF028; Tue, 2 Apr 2002 19:57:59 -0600 (CST) Received: from dperkins-nb2.dsperkins.com by riverstonenet.com (8.9.3+Sun/SMI-SVR4-Yago) id RAA24428; Tue, 2 Apr 2002 17:57:47 -0800 (PST) Message-Id: <5.0.2.1.2.20020402174913.02f98ec0@mail4.bayarea.net> X-Sender: dperkins@mail4.bayarea.net X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Tue, 02 Apr 2002 17:57:00 -0800 To: Randy Presuhn , disman@dorothy.bmc.com From: "David T. Perkins" Subject: Re: Alarm MIB WG last call In-Reply-To: <200204030135.RAA21870@dorothy.bmc.com> Mime-Version: 1.0 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 RAA21936 Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list Content-Transfer-Encoding: 8bit HI, The I-D still depends of RFC 3014. Steve Mouton and I plus RamK and implementor at cisco and implementor at Riverstone are looking into RFC 3014 and have found problems. Steve Mouton and I are working on a replacement MIB module to 3014. This replacement MIB module could result in the I-D being broken in its usage of RFC 3014. Note the reference in the I-D to RFC 3014 is not simply as an example. Hint: see the definition of object alarmListName. So, until the I-D is purged of references to RFC 3014, I find it inappropriate for it to be forwarded by the WG to the IESG for consideration as publication as an RFC. Regards, /david t. perkins At 05:35 PM 4/2/2002 -0800, Randy Presuhn wrote: >Hi - > >Private email has made it clear that some folks didn't read the >attached message. Make no mistake: disman WG last call on the >alarm MIB began March 28 when the draft appeared. The WG last >call will end 5 p.m. Pacific Daylight Time on April 11, 2002. > > ------------------------------------------------------ > Randy Presuhn BMC Software, Inc. 1-3141 > randy_presuhn@bmc.com 2141 North First Street > Tel: +1 408 546-1006 San José, California 95131 USA > ------------------------------------------------------ > My opinions and BMC's are independent variables. > ------------------------------------------------------ > >> From owner-disman@dorothy.bmc.com Mon Mar 18 13:08:39 PST 2002 >> Date: Mon, 18 Mar 2002 13:08:17 -0800 (PST) >> From: Randy Presuhn >> Message-Id: <200203182108.NAA19616@dorothy.bmc.com> >> To: disman@dorothy.bmc.com >> Subject: Alarm MIB WG last call >> List-Id: IETF disman Working Group mailing list >> >> Hi - >> >> We finished a first WG last call on the alarm MIB, and, >> *surprise* found that some revisions were needed. I've talked >> to some of the folks active in the discussion, and as disman >> WG chair have decided that, when the revision appears, another >> two-week WG last call on the document would be appropriate. >> This last call will begin when the revised I-D becomes available. >> >> As with the previous last call, I would appreciate a (personal) >> note from those who have read the document but not felt the >> need to comment on the WG mailing list, so that I might better >> assess how much review it has actually received. >> >> ------------------------------------------------------ >> Randy Presuhn BMC Software, Inc. 1-3141 >> randy_presuhn@bmc.com 2141 North First Street >> Tel: +1 408 546-1006 San José, California 95131 USA >> ------------------------------------------------------ >> My opinions and BMC's are independent variables. >> ------------------------------------------------------ >> From owner-disman@dorothy.bmc.com Wed Apr 3 10:14:37 2002 Received: from babbler.bmc.com (firebird.bmc.com [198.207.223.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05512 for ; Wed, 3 Apr 2002 10:14:37 -0500 (EST) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g33FHXF05830; Wed, 3 Apr 2002 09:17:33 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id HAA04655 for disman-list; Wed, 3 Apr 2002 07:11:08 -0800 (PST) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id HAA04649; Wed, 3 Apr 2002 07:11:03 -0800 (PST) Received: from mx-us-hou-2-int.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id g33F92Q01701; Wed, 3 Apr 2002 09:09:02 -0600 (CST) Received: from iere.net.avaya.com (iere.net.avaya.com [198.152.12.101]) by mx-us-hou-2-int.bmc.com (Postfix) with SMTP id 7E0D21FF025; Wed, 3 Apr 2002 09:12:35 -0600 (CST) Received: from iere.net.avaya.com (localhost [127.0.0.1]) by iere.net.avaya.com (8.11.2/8.9.3) with ESMTP id g33FAka06493; Wed, 3 Apr 2002 10:10:46 -0500 (EST) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by iere.net.avaya.com (8.11.2/8.9.3) with ESMTP id g33FAjM06468; Wed, 3 Apr 2002 10:10:45 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Alarm MIB WG last call Date: Wed, 3 Apr 2002 18:10:30 +0300 Message-ID: Thread-Topic: Alarm MIB WG last call Thread-Index: AcHasy4+ioW9wy/iSUGiuJP3gXDkcQAbLymQ From: "Romascanu, Dan (Dan)" To: "David T. Perkins" , "Randy Presuhn" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by dorothy.bmc.com id HAA04650 Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list Content-Transfer-Encoding: 8bit I find this argument in-sufficient. It includes a reference to a non-chartered work (AFAIK) and a conditional ('could result in the I-D being broken'). RFC 3014 is a standards track document at PS. Answering in same conditional mode, IF a replacement work will be chartered, and IF this will indeed replace RFC 3014, the next versions of the Alarm MIB COULD refer this replacement. Until then my opinion is that the references in the I-D are valid. Regards, Dan > -----Original Message----- > From: David T. Perkins [mailto:dperkins@dsperkins.com] > Sent: Wednesday, April 03, 2002 4:57 AM > To: Randy Presuhn; disman@dorothy.bmc.com > Subject: Re: Alarm MIB WG last call > > > HI, > > The I-D still depends of RFC 3014. Steve Mouton and I plus RamK and > implementor at cisco and implementor at Riverstone are looking into > RFC 3014 and have found problems. Steve Mouton and I are working on > a replacement MIB module to 3014. This replacement MIB module could > result in the I-D being broken in its usage of RFC 3014. Note the > reference in the I-D to RFC 3014 is not simply as an example. > Hint: see the definition of object alarmListName. > > So, until the I-D is purged of references to RFC 3014, I find it > inappropriate for it to be forwarded by the WG to the IESG for > consideration as publication as an RFC. > > Regards, > /david t. perkins > > At 05:35 PM 4/2/2002 -0800, Randy Presuhn wrote: > >Hi - > > > >Private email has made it clear that some folks didn't read the > >attached message. Make no mistake: disman WG last call on the > >alarm MIB began March 28 when the draft appeared. The WG last > >call will end 5 p.m. Pacific Daylight Time on April 11, 2002. > > > > ------------------------------------------------------ > > Randy Presuhn BMC Software, Inc. 1-3141 > > randy_presuhn@bmc.com 2141 North First Street > > Tel: +1 408 546-1006 San José, California 95131 USA > > ------------------------------------------------------ > > My opinions and BMC's are independent variables. > > ------------------------------------------------------ > > > >> From owner-disman@dorothy.bmc.com Mon Mar 18 13:08:39 PST 2002 > >> Date: Mon, 18 Mar 2002 13:08:17 -0800 (PST) > >> From: Randy Presuhn > >> Message-Id: <200203182108.NAA19616@dorothy.bmc.com> > >> To: disman@dorothy.bmc.com > >> Subject: Alarm MIB WG last call > >> List-Id: IETF disman Working Group mailing list > > >> > >> Hi - > >> > >> We finished a first WG last call on the alarm MIB, and, > >> *surprise* found that some revisions were needed. I've talked > >> to some of the folks active in the discussion, and as disman > >> WG chair have decided that, when the revision appears, another > >> two-week WG last call on the document would be appropriate. > >> This last call will begin when the revised I-D becomes available. > >> > >> As with the previous last call, I would appreciate a (personal) > >> note from those who have read the document but not felt the > >> need to comment on the WG mailing list, so that I might better > >> assess how much review it has actually received. > >> > >> ------------------------------------------------------ > >> Randy Presuhn BMC Software, Inc. 1-3141 > >> randy_presuhn@bmc.com 2141 North First Street > >> Tel: +1 408 546-1006 San José, California 95131 USA > >> ------------------------------------------------------ > >> My opinions and BMC's are independent variables. > >> ------------------------------------------------------ > >> > > From owner-disman@dorothy.bmc.com Wed Apr 3 12:44:30 2002 Received: from babbler.bmc.com (camaro.bmc.com [198.207.223.231]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10396 for ; Wed, 3 Apr 2002 12:44:30 -0500 (EST) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g33HlTj09167; Wed, 3 Apr 2002 11:47:29 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id JAA05450 for disman-list; Wed, 3 Apr 2002 09:41:53 -0800 (PST) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id JAA05444 for disman@dorothy.bmc.com; Wed, 3 Apr 2002 09:41:49 -0800 (PST) Date: Wed, 3 Apr 2002 09:41:49 -0800 (PST) From: Randy Presuhn Message-Id: <200204031741.JAA05444@dorothy.bmc.com> To: disman@dorothy.bmc.com Subject: RE: Alarm MIB WG last call 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 - > Subject: RE: Alarm MIB WG last call > Date: Wed, 3 Apr 2002 18:10:30 +0300 > Message-ID: > From: "Romascanu, Dan (Dan)" > To: "David T. Perkins" , > "Randy Presuhn" , > > I find this argument in-sufficient. It includes a reference to a > non-chartered work (AFAIK) and a conditional ('could result in the > I-D being broken'). RFC 3014 is a standards track document at PS. > Answering in same conditional mode, IF a replacement work will be > chartered, and IF this will indeed replace RFC 3014, the next versions > of the Alarm MIB COULD refer this replacement. Until then my opinion > is that the references in the I-D are valid. > As a technical contributor, I shared Dave Perkin's concern about making the linkage between the alarm MIB and RFC 3014 tighter than would be architecturally necessary. One of the important changes between the -05- and -06- drafts is the replacement of alarmActiveLogIndex with alarmActiveLogPointer. I think this change has eliminated any technical dependency on the indexing structure of the log MIB. The only other normative reference to 3014 is in the DESCRIPTION of alarmListName, and I really don't see how this ("The name of the list of alarms. This SHOULD be the same as nlmLogName if the Notification Log MIB [RFC3014] is supported.") could be a problem. ------------------------------------------------------ Randy Presuhn BMC Software, Inc. 1-3141 randy_presuhn@bmc.com 2141 North First Street Tel: +1 408 546-1006 San José, California 95131 USA ------------------------------------------------------ My opinions and BMC's are independent variables. ------------------------------------------------------ From owner-disman@dorothy.bmc.com Thu Apr 11 11:57:07 2002 Received: from babbler.bmc.com (firebird.bmc.com [198.207.223.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04197 for ; Thu, 11 Apr 2002 11:57:06 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g3BFxx908924; Thu, 11 Apr 2002 10:59:59 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id IAA28652 for disman-list; Thu, 11 Apr 2002 08:50:54 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id IAA28646; Thu, 11 Apr 2002 08:50:49 -0700 (PDT) Received: from mx-us-hou-2-int.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id g3BFmhW14332; Thu, 11 Apr 2002 10:48:43 -0500 (CDT) Received: from swan.prod.itd.earthlink.net (swan.mail.pas.earthlink.net [207.217.120.123]) by mx-us-hou-2-int.bmc.com (Postfix) with SMTP id CA8481FF03B; Thu, 11 Apr 2002 10:52:17 -0500 (CDT) Received: from 1cust201.tnt5.minneapolis.mn.da.uu.net ([67.251.191.201] helo=merkita.com) by swan.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16vgrd-0007Kn-00; Thu, 11 Apr 2002 08:51:58 -0700 Message-ID: <3CB5B08C.8DFB09D8@merkita.com> Date: Thu, 11 Apr 2002 10:49:32 -0500 From: Tammy Ferris Reply-To: tferris@merkita.com X-Mailer: Mozilla 4.75 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Randy Presuhn Cc: disman@dorothy.bmc.com Subject: Re: Alarm MIB WG last call References: <200204031741.JAA05444@dorothy.bmc.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list Content-Transfer-Encoding: 8bit Sharon, Dan, Randy, and all, I realize that last call is probably over in relation to the Alarm mib; therefore you may choose to ignore my comments below. I have only just now had some time to look at this. On the assumption that you would like to hear the comments anyway, I have included them. I commend the editors for the progress that has been made. I know how difficult it can sometimes be to get something standardized. I have tried to put my comments into a priority order with my greatest concerns first. 1) I question the wisdom of doing the last call on this MIB without having other alarm management functions adequately addressed such as alarm correlation and alarm suppression and also going for last call. While it looks to me that the MIB is well designed for the functionality it is intended to provide, I am not sure that it provides all the necessary functions. It also concerns me that agent behaviors in declaring/clearing/etc errors is not discussed. Further, I had hoped that this MIB would cover transient as well as persistent "errors" (using your terminology). Assuming all of this was discussed and these constraints are satisfactory to everybody else, the remaining comments are in the context of the given constraints and have quick remedies. 2) I have a problem with the definition of Fault as a "lasting" error or warning "condition". What is meant by lasting is not clear nor what is meant by condition. In addition, the ITU has used the term Fault for "errors" that are entering into the persistency function and are therefor, by definition, not persistent (if that is what was meant by lasting). Since the term fault is only used in the definition section, I would propose that the term Fault be removed and the definition of Alarm be modified to "Persistent indication of an Error". (Note: I actually would prefer an Alarm to be defined as an indication of trouble or something along those lines... my proposed correction is assuming that there is no negotiation on whether or not an alarm can be based on a transient condition) The definition for Alarm Raise would become: " The initial detection of the error indicated by an alarm or any number of alarm states later entered, except clear. A Notification SHOULD be sent on alarm raise." The definition for Alarm Clear would become: "The detection that the error indicated by an alarm no longer exists. A Notification SHOULD be sent on alarm clear." 3) In the overview, it would be nice to add a description regarding the extensibility of the AlarmActiveEntry. I think this is an important feature. 4) Section 4.1.4, it is not clear to me how it can be know what type of resource the alarm is for. It would be nice to have a description of this. Regards, Tammy Tammy Lehtinen Ferris tferris@merkita.com (763)577-5946 Merkita Incorporated www.merkita.com Randy Presuhn wrote: > Hi - > > > Subject: RE: Alarm MIB WG last call > > Date: Wed, 3 Apr 2002 18:10:30 +0300 > > Message-ID: > > From: "Romascanu, Dan (Dan)" > > To: "David T. Perkins" , > > "Randy Presuhn" , > > > > I find this argument in-sufficient. It includes a reference to a > > non-chartered work (AFAIK) and a conditional ('could result in the > > I-D being broken'). RFC 3014 is a standards track document at PS. > > Answering in same conditional mode, IF a replacement work will be > > chartered, and IF this will indeed replace RFC 3014, the next versions > > of the Alarm MIB COULD refer this replacement. Until then my opinion > > is that the references in the I-D are valid. > > > > As a technical contributor, I shared Dave Perkin's concern > about making the linkage between the alarm MIB and RFC 3014 > tighter than would be architecturally necessary. One of the > important changes between the -05- and -06- drafts is the > replacement of alarmActiveLogIndex with alarmActiveLogPointer. > > I think this change has eliminated any technical dependency > on the indexing structure of the log MIB. The only > other normative reference to 3014 is in the DESCRIPTION of > alarmListName, and I really don't see how this ("The name of > the list of alarms. This SHOULD be the same as nlmLogName > if the Notification Log MIB [RFC3014] is supported.") could > be a problem. > > ------------------------------------------------------ > Randy Presuhn BMC Software, Inc. 1-3141 > randy_presuhn@bmc.com 2141 North First Street > Tel: +1 408 546-1006 San José, California 95131 USA > ------------------------------------------------------ > My opinions and BMC's are independent variables. > ------------------------------------------------------ From owner-disman@dorothy.bmc.com Thu Apr 11 16:21:02 2002 Received: from babbler.bmc.com (firebird.bmc.com [198.207.223.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12714 for ; Thu, 11 Apr 2002 16:21:02 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g3BKO6v24686; Thu, 11 Apr 2002 15:24:06 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id NAA29164 for disman-list; Thu, 11 Apr 2002 13:17:46 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id NAA29151 for ; Thu, 11 Apr 2002 13:17:40 -0700 (PDT) Received: from mx-us-hou-1-int.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id g3BKFX810515 for ; Thu, 11 Apr 2002 15:15:33 -0500 (CDT) Received: from monsoon.mail.pipex.net (unknown [158.43.128.69]) by mx-us-hou-1-int.bmc.com (Postfix) with SMTP id 89D4120EFCF for ; Thu, 11 Apr 2002 15:19:12 -0500 (CDT) Received: (qmail 17180 invoked from network); 11 Apr 2002 20:19:11 -0000 Received: from userca14.uk.uudial.com (HELO tom3) (62.188.150.82) by smtp-1.dial.pipex.com with SMTP; 11 Apr 2002 20:19:11 -0000 Message-ID: <003301c1e195$de988a00$0301a8c0@tom3> Reply-To: "Tom Petch" From: "Tom Petch" To: "Randy Presuhn" , Subject: Re: Disman WG last call: Alarm MIB Date: Thu, 11 Apr 2002 21:14:25 +0100 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 4.72.2106.4 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list Content-Transfer-Encoding: 7bit "5.2 IANA Considerations Values of IANAItuProbableCause less than 255 can only be given out if they correspond to ITU numbers and are agreed to by the disman working group. Values of IANAItuProbableCause greater than 255 can be given out when agreed to by the disman working group. Values of IANAItuEventType can be given out when agreed to by the disman working group." Does this imply the disman working group will exist for ever, perhaps never completing its work :-)? Tom Petch, Network Consultant nwnetworks@dial.pipex.com +(44) 192 575 3018 ------------------------------------------------- From owner-disman@dorothy.bmc.com Thu Apr 11 17:09:35 2002 Received: from babbler.bmc.com (firebird.bmc.com [198.207.223.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12724 for ; Thu, 11 Apr 2002 16:21:04 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g3BKO9r24704; Thu, 11 Apr 2002 15:24:10 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id NAA29163 for disman-list; Thu, 11 Apr 2002 13:17:46 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id NAA29148 for ; Thu, 11 Apr 2002 13:17:39 -0700 (PDT) Received: from mx-us-hou-1-int.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id g3BKFWd10510 for ; Thu, 11 Apr 2002 15:15:32 -0500 (CDT) Received: from monsoon.mail.pipex.net (unknown [158.43.128.69]) by mx-us-hou-1-int.bmc.com (Postfix) with SMTP id 21CBB20EFA1 for ; Thu, 11 Apr 2002 15:19:11 -0500 (CDT) Received: (qmail 17171 invoked from network); 11 Apr 2002 20:19:09 -0000 Received: from userca14.uk.uudial.com (HELO tom3) (62.188.150.82) by smtp-1.dial.pipex.com with SMTP; 11 Apr 2002 20:19:09 -0000 Message-ID: <003201c1e195$dd739200$0301a8c0@tom3> Reply-To: "Tom Petch" From: "Tom Petch" To: "Randy Presuhn" , Subject: Re: Disman WG last call: Alarm MIB Date: Thu, 11 Apr 2002 20:53:15 +0100 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 4.72.2106.4 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list Content-Transfer-Encoding: 7bit "4.1.3 Alarm State Transition Notification Alarms are modelled by defining all possible states in the alarmModelTable, as well as defining alarmModelNotificationId, alarmModelVarbindIndex, and alarmModelVarbindValue for each of the possible alarm states. Optionally, ituAlarmPerceivedSeverity models the states in terms of ITU perceived severity. Alarm state transitions can use existing notifications or can use the generic notifications and alarmActiveState and alarmClearState. If the implementation chooses not to alert the management station, then a value of 0.0 can be used for alarmModelNotificationId. Alternatively, a notification can be defined in alarmModeNotifiationId and no hosts specified in the SNMP-TARGET-MIB [RFC2573]. What's a 'alarmModeNotifiationId'? Tom Petch, Network Consultant nwnetworks@dial.pipex.com From owner-disman@dorothy.bmc.com Thu Apr 11 17:27:57 2002 Received: from babbler.bmc.com (camaro.bmc.com [198.207.223.231]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15528 for ; Thu, 11 Apr 2002 17:27:57 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g3BLUTY13591; Thu, 11 Apr 2002 16:30:29 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id OAA29633 for disman-list; Thu, 11 Apr 2002 14:24:39 -0700 (PDT) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id OAA29627 for disman@dorothy.bmc.com; Thu, 11 Apr 2002 14:24:35 -0700 (PDT) Date: Thu, 11 Apr 2002 14:24:35 -0700 (PDT) From: Randy Presuhn Message-Id: <200204112124.OAA29627@dorothy.bmc.com> To: disman@dorothy.bmc.com Subject: Re: Alarm MIB WG last call 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 - > Date: Tue, 2 Apr 2002 17:35:14 -0800 (PST) > From: Randy Presuhn > Message-Id: <200204030135.RAA21870@dorothy.bmc.com> > To: disman@dorothy.bmc.com > Subject: Re: Alarm MIB WG last call ... > attached message. Make no mistake: disman WG last call on the > alarm MIB began March 28 when the draft appeared. The WG last > call will end 5 p.m. Pacific Daylight Time on April 11, 2002. ... I'm glad to see we've gotten some substantive comments. We will need to discuss those comments (and any others that might appear) on the mailing list, and revise the draft accordingly. Before issue another WG last call. Please, let's make this the last iteration! ------------------------------------------------------ Randy Presuhn BMC Software, Inc. 1-3141 randy_presuhn@bmc.com 2141 North First Street Tel: +1 408 546-1006 San José, California 95131 USA ------------------------------------------------------ My opinions and BMC's are independent variables. ------------------------------------------------------ From owner-disman@dorothy.bmc.com Thu Apr 11 18:17:54 2002 Received: from babbler.bmc.com (firebird.bmc.com [198.207.223.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16993 for ; Thu, 11 Apr 2002 18:17:49 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g3BMKMn20435; Thu, 11 Apr 2002 17:20:22 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id PAA29853 for disman-list; Thu, 11 Apr 2002 15:14:47 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id PAA29848 for ; Thu, 11 Apr 2002 15:14:43 -0700 (PDT) From: revab@revab.best.vwh.net Received: from mx-us-hou-2-int.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id g3BMCa114108 for ; Thu, 11 Apr 2002 17:12:36 -0500 (CDT) Received: from sj1-3-4-7.securesites.net (sj1-3-4-7.securesites.net [192.220.127.200]) by mx-us-hou-2-int.bmc.com (Postfix) with SMTP id 997741FF041 for ; Thu, 11 Apr 2002 17:16:08 -0500 (CDT) Received: (qmail 92460 invoked by uid 16517); 11 Apr 2002 22:15:58 -0000 Message-ID: <20020411221558.92459.qmail@revab.best.vwh.net> Subject: Re: Alarm MIB WG last call To: disman@dorothy.bmc.com Date: Thu, 11 Apr 2002 22:15:58 +0000 (GMT) In-Reply-To: <200204030135.RAA21870@dorothy.bmc.com> from "Randy Presuhn" at Apr 02, 2002 05:35:14 PM X-Mailer: ELM [version 2.5 PL6] MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list Content-Transfer-Encoding: 8bit Is alarmActiveSpecificPointer really intended to be "read-write" or should it be "read-only"? Reva Bailey > > Hi - > > Private email has made it clear that some folks didn't read the > attached message. Make no mistake: disman WG last call on the > alarm MIB began March 28 when the draft appeared. The WG last > call will end 5 p.m. Pacific Daylight Time on April 11, 2002. > > ------------------------------------------------------ > Randy Presuhn BMC Software, Inc. 1-3141 > randy_presuhn@bmc.com 2141 North First Street > Tel: +1 408 546-1006 San José, California 95131 USA > ------------------------------------------------------ > My opinions and BMC's are independent variables. > ------------------------------------------------------ > > > From owner-disman@dorothy.bmc.com Mon Mar 18 13:08:39 PST 2002 > > Date: Mon, 18 Mar 2002 13:08:17 -0800 (PST) > > From: Randy Presuhn > > Message-Id: <200203182108.NAA19616@dorothy.bmc.com> > > To: disman@dorothy.bmc.com > > Subject: Alarm MIB WG last call > > List-Id: IETF disman Working Group mailing list > > > > Hi - > > > > We finished a first WG last call on the alarm MIB, and, > > *surprise* found that some revisions were needed. I've talked > > to some of the folks active in the discussion, and as disman > > WG chair have decided that, when the revision appears, another > > two-week WG last call on the document would be appropriate. > > This last call will begin when the revised I-D becomes available. > > > > As with the previous last call, I would appreciate a (personal) > > note from those who have read the document but not felt the > > need to comment on the WG mailing list, so that I might better > > assess how much review it has actually received. > > > > ------------------------------------------------------ > > Randy Presuhn BMC Software, Inc. 1-3141 > > randy_presuhn@bmc.com 2141 North First Street > > Tel: +1 408 546-1006 San José, California 95131 USA > > ------------------------------------------------------ > > My opinions and BMC's are independent variables. > > ------------------------------------------------------ > > > From owner-disman@dorothy.bmc.com Fri Apr 12 18:46:14 2002 Received: from babbler.bmc.com (camaro.bmc.com [198.207.223.231]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05908 for ; Fri, 12 Apr 2002 18:46:14 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g3CMmR822253; Fri, 12 Apr 2002 17:48:28 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id PAA14811 for disman-list; Fri, 12 Apr 2002 15:41:31 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id OAA13394 for ; Fri, 12 Apr 2002 14:01:11 -0700 (PDT) Received: from mx-us-hou-2-int.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id g3CKx4N08196 for ; Fri, 12 Apr 2002 15:59:04 -0500 (CDT) Received: from snipe.prod.itd.earthlink.net (snipe.mail.pas.earthlink.net [207.217.120.62]) by mx-us-hou-2-int.bmc.com (Postfix) with SMTP id 240F21FF03F for ; Fri, 12 Apr 2002 16:02:44 -0500 (CDT) Received: from 1cust215.tnt5.minneapolis.mn.da.uu.net ([67.251.191.215] helo=merkita.com) by snipe.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16w8Be-00047n-00 for disman@dorothy.bmc.com; Fri, 12 Apr 2002 14:02:27 -0700 Message-ID: <3CB74ACF.F4E47A62@merkita.com> Date: Fri, 12 Apr 2002 15:59:59 -0500 From: Tammy Ferris Reply-To: tferris@merkita.com X-Mailer: Mozilla 4.75 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 Cc: disman@dorothy.bmc.com Subject: Re: Alarm MIB WG last call References: <20020411221558.92459.qmail@revab.best.vwh.net> Content-Type: multipart/alternative; boundary="------------96E80D625234320A12202891" Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list --------------96E80D625234320A12202891 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit All, Found another item. For clarity, I think the following definition: alarmActiveDateAndTime OBJECT-TYPE SYNTAX DateAndTime MAX-ACCESS not-accessible STATUS current DESCRIPTION "The local date and time when the alarm occurred. Implementations MUST include the offset from UTC, if available. Implementation in environments in which the UTC offset is not available is NOT RECOMMENDED." ::= { alarmActiveEntry 2 } Should be modified to: alarmActiveDateAndTime OBJECT-TYPE SYNTAX DateAndTime MAX-ACCESS not-accessible STATUS current DESCRIPTION "The local date and time when the error occurred. Implementations MUST include the offset from UTC, if available. Implementation in environments in which the UTC offset is not available is NOT RECOMMENDED." ::= { alarmActiveEntry 2 } Of course, I would not object to two time stamps. One for the time the error occurred and another for the time an alarm was reported. Cheers, Tammy Tammy Lehtinen Ferris tferris@merkita.com +1 (763)577-5946 Merkita Incorporated www.merkita.com > > > > Hi - > > > > Private email has made it clear that some folks didn't read the > > attached message. Make no mistake: disman WG last call on the > > alarm MIB began March 28 when the draft appeared. The WG last > > call will end 5 p.m. Pacific Daylight Time on April 11, 2002. > > > > ------------------------------------------------------ > > Randy Presuhn BMC Software, Inc. 1-3141 > > randy_presuhn@bmc.com 2141 North First Street > > Tel: +1 408 546-1006 San José, California 95131 USA > > ------------------------------------------------------ > > My opinions and BMC's are independent variables. > > ------------------------------------------------------ > > > > > From owner-disman@dorothy.bmc.com Mon Mar 18 13:08:39 PST 2002 > > > Date: Mon, 18 Mar 2002 13:08:17 -0800 (PST) > > > From: Randy Presuhn > > > Message-Id: <200203182108.NAA19616@dorothy.bmc.com> > > > To: disman@dorothy.bmc.com > > > Subject: Alarm MIB WG last call > > > List-Id: IETF disman Working Group mailing list > > > > > > Hi - > > > > > > We finished a first WG last call on the alarm MIB, and, > > > *surprise* found that some revisions were needed. I've talked > > > to some of the folks active in the discussion, and as disman > > > WG chair have decided that, when the revision appears, another > > > two-week WG last call on the document would be appropriate. > > > This last call will begin when the revised I-D becomes available. > > > > > > As with the previous last call, I would appreciate a (personal) > > > note from those who have read the document but not felt the > > > need to comment on the WG mailing list, so that I might better > > > assess how much review it has actually received. > > > > > > ------------------------------------------------------ > > > Randy Presuhn BMC Software, Inc. 1-3141 > > > randy_presuhn@bmc.com 2141 North First Street > > > Tel: +1 408 546-1006 San José, California 95131 USA > > > ------------------------------------------------------ > > > My opinions and BMC's are independent variables. > > > ------------------------------------------------------ > > > > > --------------96E80D625234320A12202891 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit All,
Found another item.  For clarity, I think the following definition:
   alarmActiveDateAndTime OBJECT-TYPE
      SYNTAX      DateAndTime
      MAX-ACCESS  not-accessible
      STATUS      current
      DESCRIPTION
          "The local date and time when the alarm occurred.

          Implementations MUST include the offset from UTC,
          if available.  Implementation in environments in which
          the UTC offset is not available is NOT RECOMMENDED."
      ::= { alarmActiveEntry 2 }

Should be modified to:
   alarmActiveDateAndTime OBJECT-TYPE
      SYNTAX      DateAndTime
      MAX-ACCESS  not-accessible
      STATUS      current
      DESCRIPTION
          "The local date and time when the error occurred.

          Implementations MUST include the offset from UTC,
          if available.  Implementation in environments in which
          the UTC offset is not available is NOT RECOMMENDED."
      ::= { alarmActiveEntry 2 }
 

Of course, I would not object to two time stamps.  One for the time the error occurred and another for the time an alarm was reported.
Cheers,
Tammy

Tammy Lehtinen Ferris
tferris@merkita.com
+1 (763)577-5946
Merkita Incorporated
www.merkita.com
 

>
> Hi -
>
> Private email has made it clear that some folks didn't read the
> attached message.  Make no mistake:  disman WG last call on the
> alarm MIB began March 28 when the draft appeared.  The WG last
> call will end 5 p.m. Pacific Daylight Time on April 11, 2002.
>
>  ------------------------------------------------------
>  Randy Presuhn          BMC Software, Inc.  1-3141
>  randy_presuhn@bmc.com  2141 North First Street
>  Tel: +1 408 546-1006   San José, California 95131  USA
>  ------------------------------------------------------
>  My opinions and BMC's are independent variables.
>  ------------------------------------------------------
>
> > From owner-disman@dorothy.bmc.com Mon Mar 18 13:08:39 PST 2002
> > Date: Mon, 18 Mar 2002 13:08:17 -0800 (PST)
> > From: Randy Presuhn <rpresuhn>
> > Message-Id: <200203182108.NAA19616@dorothy.bmc.com>
> > To: disman@dorothy.bmc.com
> > Subject: Alarm MIB WG last call
> > List-Id: IETF disman Working Group mailing list <disman.dorothy.bmc.com>
> >
> > Hi -
> >
> > We finished a first WG last call on the alarm MIB, and,
> > *surprise* found that some revisions were needed.  I've talked
> > to some of the folks active in the discussion, and as disman
> > WG chair have decided that, when the revision appears, another
> > two-week WG last call on the document would be appropriate.
> > This last call will begin when the revised I-D becomes available.
> >
> > As with the previous last call, I would appreciate a (personal)
> > note from those who have read the document but not felt the
> > need to comment on the WG mailing list, so that I might better
> > assess how much review it has actually received.
> >
> >  ------------------------------------------------------
> >  Randy Presuhn          BMC Software, Inc.  1-3141
> >  randy_presuhn@bmc.com  2141 North First Street
> >  Tel: +1 408 546-1006   San José, California 95131  USA
> >  ------------------------------------------------------
> >  My opinions and BMC's are independent variables.
> >  ------------------------------------------------------
> >
>
--------------96E80D625234320A12202891-- From owner-disman@dorothy.bmc.com Sat Apr 13 14:03:11 2002 Received: from babbler.bmc.com (firebird.bmc.com [198.207.223.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27823 for ; Sat, 13 Apr 2002 14:03:11 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g3DI5bo28026; Sat, 13 Apr 2002 13:05:38 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id KAA16913 for disman-list; Sat, 13 Apr 2002 10:59:15 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id KAA16908 for ; Sat, 13 Apr 2002 10:59:12 -0700 (PDT) From: stefan.wallin@dataductus.se Received: from mx-us-hou-1-int.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id g3DHv4c25588 for ; Sat, 13 Apr 2002 12:57:04 -0500 (CDT) Received: from mogwai.dataductus.se (unknown [213.199.99.186]) by mx-us-hou-1-int.bmc.com (Postfix) with SMTP id 03C2320EF91 for ; Sat, 13 Apr 2002 13:00:44 -0500 (CDT) Received: (from nobody@localhost) by mogwai.dataductus.se (8.11.6/8.11.6) id g3DHveN29296 for disman@dorothy.bmc.com; Sat, 13 Apr 2002 19:57:40 +0200 X-Authentication-Warning: mogwai.dataductus.se: nobody set sender to stefan.wallin@dataductus.se using -f Received: from 213.66.198.119 ( [213.66.198.119]) as user ddskswa@imap.dataductus.se by webmail2.dataductus.se with HTTP; Sat, 13 Apr 2002 19:57:40 +0200 Message-ID: <1018720660.3cb8719416ab0@webmail2.dataductus.se> Date: Sat, 13 Apr 2002 19:57:40 +0200 To: disman@dorothy.bmc.com Subject: read-write -> read-create in alarm-mib MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.0 X-Originating-IP: 213.66.198.119 Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list Content-Transfer-Encoding: 8bit Hi! According to SMIv2 ch 7.3 If any columnar object in a conceptual row has "read-create" as its maximal level of access, then no other columnar object of the same conceptual row may have a maximal access of "read-write". The alarmModelTable violates this. best regards Stefan From owner-disman@dorothy.bmc.com Sun Apr 14 05:29:16 2002 Received: from babbler.bmc.com (firebird.bmc.com [198.207.223.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA16051 for ; Sun, 14 Apr 2002 05:29:16 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g3E9VR409802; Sun, 14 Apr 2002 04:31:31 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id CAA18398 for disman-list; Sun, 14 Apr 2002 02:24:54 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id CAA18392; Sun, 14 Apr 2002 02:24:50 -0700 (PDT) Received: from mx-us-hou-2-int.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id g3E9MgJ24772; Sun, 14 Apr 2002 04:22:42 -0500 (CDT) Received: from auemail1.firewall.lucent.com (auemail1.lucent.com [192.11.223.161]) by mx-us-hou-2-int.bmc.com (Postfix) with SMTP id 9F2E51FF029; Sun, 14 Apr 2002 04:26:22 -0500 (CDT) Received: from nj7460exch002h.wins.lucent.com (h135-17-42-35.lucent.com [135.17.42.35]) by auemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g3E9Pud27495; Sun, 14 Apr 2002 05:25:56 -0400 (EDT) Received: by nj7460exch002h.ho.lucent.com with Internet Mail Service (5.5.2653.19) id <265QBAAQ>; Sun, 14 Apr 2002 05:25:55 -0400 Message-ID: <2E12619580C0D1118C6400805F9F4C950EA417DF@nj7460exch001u.ho.lucent.com> From: "Lam, Hing-Kam (Kam)" To: Randy Presuhn , andreaw@cisco.com, disman@dorothy.bmc.com Cc: jschott@cisco.com Subject: RE: FW: Probable Cause Date: Sun, 14 Apr 2002 05:25:54 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list Hi, Some more duplication cases in ITU-IANA-ALARM-TC: fire (120) & fireDetected (266) flood (121) & floodDetected (267) configurationOrCustomisationError (160) & configurationOrCustomizationError(260) underlayingResourceUnavailable (166) & underlyingResourceUnavailable(287) and possibly toxicGas (133) & toxicLeakDetected (286) ^^^ ^^^^ Kam > -----Original Message----- > From: Randy Presuhn [mailto:rpresuhn@dorothy.bmc.com] > Sent: Wednesday, March 27, 2002 3:16 PM > To: andreaw@cisco.com; disman@dorothy.bmc.com > Cc: jschott@cisco.com > Subject: Re: FW: Probable Cause > > > Hi - > > Looking at the ProbableCause list Andrea posted, it looks like > there are several distinct kinds of differences of concern to > our group: > > 1) different labels or numbers. Annoying, but > probably harmless. > > 2) CIM codes more specific than ITU codes. Example: > externalIFDeviceProblem -> either Input Device Error > or Output Device Error > > 3) ITU codes more specific than CIM codes. Example: > HVAC Problem -> coolingSystemFailure or > ventilationSystemFailure or airCompressorFailure > or airConditioningFailure or airDryerFailure or > heatingVentCoolingSystemProblem > > 4) "fuzzy" mappings, as in the ITU modulationFailure > and demodulationFailure both mapping to a choice > in CIM between Dataset/Modem Error and Equipment > Malfunction. > > 5) CIM codes with no ITU counterpart, e.g. Software > Virus Detected. > > By the way, what's the difference between our iODeviceError > and our inputOutputDeviceError codes? > > ------------------------------------------------------ > Randy Presuhn BMC Software, Inc. 1-3141 > randy_presuhn@bmc.com 2141 North First Street > Tel: +1 408 546-1006 San Jose, California 95131 USA > ------------------------------------------------------ > My opinions and BMC's are independent variables. > ------------------------------------------------------ > From owner-disman@dorothy.bmc.com Sun Apr 14 06:07:30 2002 Received: from babbler.bmc.com (firebird.bmc.com [198.207.223.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16283 for ; Sun, 14 Apr 2002 06:07:30 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g3EAA2g15313; Sun, 14 Apr 2002 05:10:02 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id DAA18456 for disman-list; Sun, 14 Apr 2002 03:04:36 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id DAA18450; Sun, 14 Apr 2002 03:04:32 -0700 (PDT) Received: from mx-us-hou-1-int.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id g3EA2NE07298; Sun, 14 Apr 2002 05:02:23 -0500 (CDT) Received: from ierw.net.avaya.com (unknown [198.152.13.101]) by mx-us-hou-1-int.bmc.com (Postfix) with SMTP id A9CD320EF89; Sun, 14 Apr 2002 05:06:04 -0500 (CDT) Received: from ierw.net.avaya.com (localhost [127.0.0.1]) by ierw.net.avaya.com (8.9.3+Sun/8.9.3) with ESMTP id GAA22089; Sun, 14 Apr 2002 06:04:22 -0400 (EDT) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by ierw.net.avaya.com (8.9.3+Sun/8.9.3) with ESMTP id GAA22070; Sun, 14 Apr 2002 06:04:21 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: FW: Probable Cause Date: Sun, 14 Apr 2002 13:04:04 +0300 Message-ID: Thread-Topic: FW: Probable Cause Thread-Index: AcHjlplvKe+SxTlvQKu5I3o3OchM4gABJH1Q From: "Romascanu, Dan (Dan)" To: "Lam, Hing-Kam (Kam)" , "Randy Presuhn" , , Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by dorothy.bmc.com id DAA18451 Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list Content-Transfer-Encoding: 8bit The question is where we go from here. Possible path: - keep all mappings from the original ITU list (values <256) - eliminate obvious duplication cases - wherever mapping of the ITU to CIM values is not perfect, add new values (>256) to fill in possible alarm cases not covered by ITU Does this seem reasonable? Keep in mind that the draft is clear that 'The following shall be used as the initial values, but the latest values for these textual conventions should be obtained from IANA'. Regards, Dan > -----Original Message----- > From: Lam, Hing-Kam (Kam) [mailto:hklam@lucent.com] > Sent: Sunday, April 14, 2002 12:26 PM > To: Randy Presuhn; andreaw@cisco.com; disman@dorothy.bmc.com > Cc: jschott@cisco.com > Subject: RE: FW: Probable Cause > > > Hi, > > Some more duplication cases in ITU-IANA-ALARM-TC: > > fire (120) & fireDetected (266) > > flood (121) & floodDetected (267) > > configurationOrCustomisationError (160) & > configurationOrCustomizationError(260) > > underlayingResourceUnavailable (166) & > underlyingResourceUnavailable(287) > > and possibly > toxicGas (133) & toxicLeakDetected (286) > ^^^ ^^^^ > > Kam > > > -----Original Message----- > > From: Randy Presuhn [mailto:rpresuhn@dorothy.bmc.com] > > Sent: Wednesday, March 27, 2002 3:16 PM > > To: andreaw@cisco.com; disman@dorothy.bmc.com > > Cc: jschott@cisco.com > > Subject: Re: FW: Probable Cause > > > > > > Hi - > > > > Looking at the ProbableCause list Andrea posted, it looks like > > there are several distinct kinds of differences of concern to > > our group: > > > > 1) different labels or numbers. Annoying, but > > probably harmless. > > > > 2) CIM codes more specific than ITU codes. Example: > > externalIFDeviceProblem -> either Input Device Error > > or Output Device Error > > > > 3) ITU codes more specific than CIM codes. Example: > > HVAC Problem -> coolingSystemFailure or > > ventilationSystemFailure or airCompressorFailure > > or airConditioningFailure or airDryerFailure or > > heatingVentCoolingSystemProblem > > > > 4) "fuzzy" mappings, as in the ITU modulationFailure > > and demodulationFailure both mapping to a choice > > in CIM between Dataset/Modem Error and Equipment > > Malfunction. > > > > 5) CIM codes with no ITU counterpart, e.g. Software > > Virus Detected. > > > > By the way, what's the difference between our iODeviceError > > and our inputOutputDeviceError codes? > > > > ------------------------------------------------------ > > Randy Presuhn BMC Software, Inc. 1-3141 > > randy_presuhn@bmc.com 2141 North First Street > > Tel: +1 408 546-1006 San Jose, California 95131 USA > > ------------------------------------------------------ > > My opinions and BMC's are independent variables. > > ------------------------------------------------------ > > > From owner-disman@dorothy.bmc.com Sun Apr 14 06:35:00 2002 Received: from babbler.bmc.com (camaro.bmc.com [198.207.223.231]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16549 for ; Sun, 14 Apr 2002 06:34:59 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g3EAbQN17771; Sun, 14 Apr 2002 05:37:26 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id DAA18526 for disman-list; Sun, 14 Apr 2002 03:31:48 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id DAA18520; Sun, 14 Apr 2002 03:31:44 -0700 (PDT) Received: from mx-us-hou-1-int.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id g3EATZ116245; Sun, 14 Apr 2002 05:29:35 -0500 (CDT) Received: from ihemail2.firewall.lucent.com (unknown [192.11.222.163]) by mx-us-hou-1-int.bmc.com (Postfix) with SMTP id BF16820EF99; Sun, 14 Apr 2002 05:33:16 -0500 (CDT) Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail2.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g3EAXAc19297; Sun, 14 Apr 2002 06:33:10 -0400 (EDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2653.19) id <2GN7XKHJ>; Sun, 14 Apr 2002 12:33:09 +0200 Message-ID: From: "Wijnen, Bert (Bert)" To: "Lam, Hing-Kam (Kam)" , Randy Presuhn , andreaw@cisco.com, disman@dorothy.bmc.com, jschott@cisco.com Cc: Randy Bush , Dave Sidor Subject: RE: FW: Probable Cause Date: Sun, 14 Apr 2002 12:33:01 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list Is this just me that sort of wrries when I see > Some more duplication cases in ITU-IANA-ALARM-TC: > To me it is either a set of ITU controled TCs, or a set of IANA controled TCs. How is this going to work out if both organisations need to stay in sync on this? Has anybody checked with ITU that they are happy to be restricted to 255 code points? Can we get that in a statement from them (possibly from SG 4?)? Do we have arranged for ITU to check and sign-off on the values we currently have in this document? Maybe I am just worrying too much... I am pretty busy with other stuff, so I have not followed all the emails/postings all that closely. Bert From owner-disman@dorothy.bmc.com Sun Apr 14 11:50:45 2002 Received: from babbler.bmc.com (camaro.bmc.com [198.207.223.231]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19660 for ; Sun, 14 Apr 2002 11:50:45 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g3EFrE813121; Sun, 14 Apr 2002 10:53:17 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id IAA18992 for disman-list; Sun, 14 Apr 2002 08:47:27 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id IAA18987 for ; Sun, 14 Apr 2002 08:47:23 -0700 (PDT) Received: from mx-us-hou-1-int.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id g3EFjFx28813 for ; Sun, 14 Apr 2002 10:45:15 -0500 (CDT) Received: from ierw.net.avaya.com (unknown [198.152.13.101]) by mx-us-hou-1-int.bmc.com (Postfix) with SMTP id E102520EF9A for ; Sun, 14 Apr 2002 10:46:47 -0500 (CDT) Received: from ierw.net.avaya.com (localhost [127.0.0.1]) by ierw.net.avaya.com (8.9.3+Sun/8.9.3) with ESMTP id LAA12473 for ; Sun, 14 Apr 2002 11:45:06 -0400 (EDT) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by ierw.net.avaya.com (8.9.3+Sun/8.9.3) with ESMTP id LAA12469 for ; Sun, 14 Apr 2002 11:45:05 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: read-write -> read-create in alarm-mib Date: Sun, 14 Apr 2002 18:44:47 +0300 Message-ID: Thread-Topic: read-write -> read-create in alarm-mib Thread-Index: AcHjFTpbYSV1x3V2T+ybK3i/YEy6tAAthDTw From: "Romascanu, Dan (Dan)" To: , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by dorothy.bmc.com id IAA18988 Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list Content-Transfer-Encoding: 8bit Correct. Needs to be fixed in the next rev. Thanks, Dan > -----Original Message----- > From: stefan.wallin@dataductus.se [mailto:stefan.wallin@dataductus.se] > Sent: Saturday, April 13, 2002 8:58 PM > To: disman@dorothy.bmc.com > Subject: read-write -> read-create in alarm-mib > > > Hi! > According to SMIv2 ch 7.3 > > If any columnar object in a conceptual row has "read-create" as its > maximal level of access, then no other columnar object of the same > conceptual row may have a maximal access of "read-write". > > The alarmModelTable violates this. > best regards Stefan > > > > > From owner-disman@dorothy.bmc.com Mon Apr 15 04:16:18 2002 Received: from babbler.bmc.com (camaro.bmc.com [198.207.223.231]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09743 for ; Mon, 15 Apr 2002 04:16:17 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g3F8HuX08694; Mon, 15 Apr 2002 03:17:57 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id BAA20308 for disman-list; Mon, 15 Apr 2002 01:11:22 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id BAA20303 for ; Mon, 15 Apr 2002 01:11:18 -0700 (PDT) Received: from mx-us-hou-2-int.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id g3F89Au11484 for ; Mon, 15 Apr 2002 03:09:10 -0500 (CDT) Received: from ierw.net.avaya.com (ierw.net.avaya.com [198.152.13.101]) by mx-us-hou-2-int.bmc.com (Postfix) with SMTP id B7E711FF00A for ; Mon, 15 Apr 2002 03:12:50 -0500 (CDT) Received: from ierw.net.avaya.com (localhost [127.0.0.1]) by ierw.net.avaya.com (8.9.3+Sun/8.9.3) with ESMTP id EAA22715 for ; Mon, 15 Apr 2002 04:10:58 -0400 (EDT) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by ierw.net.avaya.com (8.9.3+Sun/8.9.3) with ESMTP id EAA22706 for ; Mon, 15 Apr 2002 04:10:57 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Alarm MIB WG last call Date: Mon, 15 Apr 2002 11:10:40 +0300 Message-ID: Thread-Topic: Alarm MIB WG last call Thread-Index: AcHhplm7BSsZj/TmRN+wMpvWG1DXfACrVCKw From: "Romascanu, Dan (Dan)" To: , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by dorothy.bmc.com id BAA20304 Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list Content-Transfer-Encoding: 8bit A good question. I think that we defined this object as "read-write" having in mind the extensibility to different model-specific Alarm MIBs. However, thinking it twice, I think that an agent needs not attach a specific given alarm to more than one model. Even if more than one model-specific Alarm MIBs are supported by an agent, a given alarm should be mapped only into one of them. I think that changing the object to "read-only" would be a better choice. I would like to hear Sharon's opinion, and other opinions as well. Regards, Dan > > Is alarmActiveSpecificPointer really intended to be > "read-write" or should it be "read-only"? > > Reva Bailey > > > From owner-disman@dorothy.bmc.com Mon Apr 15 06:33:43 2002 Received: from babbler.bmc.com (camaro.bmc.com [198.207.223.231]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12400 for ; Mon, 15 Apr 2002 06:33:43 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g3FAZsS26141; Mon, 15 Apr 2002 05:35:54 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id DAA20783 for disman-list; Mon, 15 Apr 2002 03:28:12 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id DAA20778 for ; Mon, 15 Apr 2002 03:28:07 -0700 (PDT) Received: from mx-us-hou-2-int.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id g3FAPwM07164 for ; Mon, 15 Apr 2002 05:25:59 -0500 (CDT) Received: from watcher.dataductus.se (mail.dataductus.se [213.199.99.201]) by mx-us-hou-2-int.bmc.com (Postfix) with SMTP id 658CA1FF00B for ; Mon, 15 Apr 2002 05:29:38 -0500 (CDT) Received: (qmail 27873 invoked from network); 15 Apr 2002 10:29:06 -0000 Received: from nsmail.dataductus.se (192.168.100.43) by 0 with SMTP; 15 Apr 2002 10:29:06 -0000 Received: from dataductus.com ([192.168.100.240]) by nsmail.dataductus.se (Netscape Messaging Server 4.15) with SMTP id GULUH300.42R for ; Mon, 15 Apr 2002 12:29:27 +0200 From: "Stefan Wallin" To: "Disman" Subject: SV: Alarm MIB WG last call Date: Mon, 15 Apr 2002 12:28:56 +0200 MIME-Version: 1.0 Message-ID: X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Content-Type: multipart/signed; boundary="----=_NextPart_000_004D_01C1E479.1C8A83A0"; protocol="application/x-pkcs7-signature"; micalg=SHA1 Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list This is a multi-part message in MIME format. ------=_NextPart_000_004D_01C1E479.1C8A83A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I agree with Reva that the only reasonable MAX-ACCESS for = alarmActiveSpecificPointer is read-only=20 The alarmActiveTable should have entries that tells a mgr about = outstanding alarms. An entry with associated entries (alarmActiveSpecificPointer) is created = and NEVER changed. This is also the view in X733 whereas an Alarm Record is never changed = after creation. Regards, Stefan -----Ursprungligt meddelande----- Fr=E5n: owner-disman@dorothy.bmc.com [mailto:owner-disman@dorothy.bmc.com]F=F6r Romascanu, Dan (Dan) Skickat: den 15 april 2002 10:11 Till: revab@revab.best.vwh.net; disman@dorothy.bmc.com =C4mne: RE: Alarm MIB WG last call A good question. I think that we defined this object as "read-write" = having in mind the extensibility to different model-specific Alarm MIBs. = However, thinking it twice, I think that an agent needs not attach a = specific given alarm to more than one model. Even if more than one = model-specific Alarm MIBs are supported by an agent, a given alarm = should be mapped only into one of them. I think that changing the object = to "read-only" would be a better choice.=20 I would like to hear Sharon's opinion, and other opinions as well. Regards, Dan >=20 > Is alarmActiveSpecificPointer really intended to be > "read-write" or should it be "read-only"? >=20 > Reva Bailey >=20 > >=20 ------=_NextPart_000_004D_01C1E479.1C8A83A0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJATCCApAw ggH5oAMCAQICAwYNiDANBgkqhkiG9w0BAQIFADCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdl c3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsT FENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAw MC44LjMwMB4XDTAxMTEwODExMTcwMloXDTAyMTEwODExMTcwMlowTTEfMB0GA1UEAxMWVGhhd3Rl IEZyZWVtYWlsIE1lbWJlcjEqMCgGCSqGSIb3DQEJARYbc3RlZmFuLndhbGxpbkBkYXRhZHVjdHVz LnNlMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCs05PXVkcFgmj+s6KhgDkygKKwOv4n3+w9 16zv3AqqW7ssTETrL9l5sY/5i5KEJOpLYsXMD/hhpcSQj8wEec52JkC7DbuqtoQwwMExzD5ijNFV gG/efTaRZBmkMofmyypmLPaeRlwSs9DbLa1HKnK9jLPjT8+0zutDb+z66zjEgwIDAQABozgwNjAm BgNVHREEHzAdgRtzdGVmYW4ud2FsbGluQGRhdGFkdWN0dXMuc2UwDAYDVR0TAQH/BAIwADANBgkq hkiG9w0BAQIFAAOBgQC6vCfLXni0OMwFVRxNQzTdIKcnbUC7mpAlvEn3rgaX9prsg1A8fu8qJW79 xeQ5Jk9kYi8Lfo9AvVgIG1H3b2wngzwV85tfJmTTpgrfPdQnUpvZ5r51Pf8sznH0/QwscOzNlnZd RTZIXoYLtuGEDm52KznRxx/GRgFKgqXP+pCvjDCCAy0wggKWoAMCAQICAQAwDQYJKoZIhvcNAQEE BQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg VG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24g U2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTEr MCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw05NjAxMDEwMDAw MDBaFw0yMDEyMzEyMzU5NTlaMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBl MRIwEAYDVQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQL Ex9DZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29u YWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0ZS5j b20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANRp19SwlGRbcelH2AxRtupykbCEXn0tDY97 Et+FJXUodDpCLGMnn5V7S+9+GYcdhuqj3bnOlmQawhRuRKx85o/oTQ9xH0A4pgCjh3j2+ZSGXq3q wF5269kUo11uenwMpUtVfwYZKX+emibVars4JAhqmMex2qOYkf152+VaxBy5AgMBAAGjEzARMA8G A1UdEwEB/wQFMAMBAf8wDQYJKoZIhvcNAQEEBQADgYEAx+ySfk749ZalZ2IqpPBNEWDQb41gWGGs JrtSNVwIzzD7qEqWih9iQiOMFw/0umScF6xHKd+dmF7SbGBxXKKs3Hnj524ARx+1DSjoAp3kmv0T 9KbZfLH43F8jJgmRgHPQFBveQ6mDJfLmnC8Vyv6mq4oHdYsM3VGEa+T40c53ooEwggM4MIICoaAD AgECAhBmRXK3zHT1z2N2RYTQLpEBMA0GCSqGSIb3DQEBBAUAMIHRMQswCQYDVQQGEwJaQTEVMBMG A1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBD b25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYD VQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFs LWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcNMDAwODMwMDAwMDAwWhcNMDQwODI3MjM1OTU5WjCBkjEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8w DQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9Q ZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKB gQDeMzKmY8cJJUU+0m54J2eBxdqIGYKXDuNEKYpjNSptcDz63K737nRvMLwzkH/5NHGgo22Y8cNP omXbDfpL8dbdYaX5hc1VmjUanZJ1qCeu2HL5ugL217CR3hzpq+AYA6h8Q0JQUYeDPPA5tJtUihOH /7ObnUlmAC0JieyUa+mhaQIDAQABo04wTDApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0 ZUxhYmVsMS0yOTcwEgYDVR0TAQH/BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQEE BQADgYEAMbFLR135AXHl9VNsXXnWPZjAJhNigSKnEvgilegbSbcnewQ5uvzm8iTrkfq97A0qOPdQ Vahs9w2tTBu8A/S166JHn2yiDFiNMUIJEWywGmnRKxKyQF1q+XnQ6i4l3Yrk/NsNH50C81rbyjz2 ROomaYd/SJ7OpZ/nhNjJYmKtBcYxggKOMIICigIBATCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNV BAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAb BgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBS U0EgMjAwMC44LjMwAgMGDYgwCQYFKw4DAhoFAKCCAUkwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMDIwNDE1MTAyODU2WjAjBgkqhkiG9w0BCQQxFgQUToT+B58STtL3 J3WuXhzGz+hyaKAwPAYJKoZIhvcNAQkPMS8wLTAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAHBgUr DgMCGjAKBggqhkiG9w0CBTCBqwYJKwYBBAGCNxAEMYGdMIGaMIGSMQswCQYDVQQGEwJaQTEVMBMG A1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xDzANBgNVBAoTBlRoYXd0ZTEd MBsGA1UECxMUQ2VydGlmaWNhdGUgU2VydmljZXMxKDAmBgNVBAMTH1BlcnNvbmFsIEZyZWVtYWls IFJTQSAyMDAwLjguMzACAwYNiDANBgkqhkiG9w0BAQEFAASBgGL9oQHzayyPUUPKPPsUeKBUWXFN QbtEKarMRmZZsmM5MP0R+qx6gq4v3oXnqBQSws93XJZGA4xhsoFuS941E6M771szdMhrp+e7N2SL zNlfhIB41TrgmaoAFdWtsTnGjJXY6ldTTEOa/DrJHHaL+CdgP3tCs72h70ihZd90kcljAAAAAAAA ------=_NextPart_000_004D_01C1E479.1C8A83A0-- From owner-disman@dorothy.bmc.com Mon Apr 15 07:39:07 2002 Received: from babbler.bmc.com (firebird.bmc.com [198.207.223.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13350 for ; Mon, 15 Apr 2002 07:39:07 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g3FBfe903546; Mon, 15 Apr 2002 06:41:40 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id EAA20883 for disman-list; Mon, 15 Apr 2002 04:35:34 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id EAA20878 for ; Mon, 15 Apr 2002 04:35:30 -0700 (PDT) Received: from mx-us-hou-2-int.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id g3FBXMd04614 for ; Mon, 15 Apr 2002 06:33:22 -0500 (CDT) Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by mx-us-hou-2-int.bmc.com (Postfix) with SMTP id 63F861FF00A for ; Mon, 15 Apr 2002 06:37:03 -0500 (CDT) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g3FBaka07445; Mon, 15 Apr 2002 07:36:46 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <2WJA3BV6>; Mon, 15 Apr 2002 07:36:48 -0400 Message-ID: <3549C09B853DD5119B540002A52CDD3402C0AD70@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: disman@dorothy.bmc.com Cc: Randy Bush , "Wijnen, Bert (Bert)" Subject: RE: FW: Probable Cause Date: Mon, 15 Apr 2002 07:36:53 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list hi It's actually called IANA-ITU-ALARM-TC, but that probably does not help your concerns much. Study group 4 has seen the textual convention and seem happy with it. I'm not sure if they noticed the 255 limit, but we can verify. It would seem a liaison statement on how we get ITU sign-off on these values would be useful. Sharon -----Original Message----- From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] Sent: Sunday, April 14, 2002 6:33 AM To: Lam, Hing-Kam (Kam); Randy Presuhn; andreaw@cisco.com; disman@dorothy.bmc.com; jschott@cisco.com Cc: Randy Bush; Sidor, Dave [NC1:6L30:EXCH] Subject: RE: FW: Probable Cause Is this just me that sort of wrries when I see > Some more duplication cases in ITU-IANA-ALARM-TC: > To me it is either a set of ITU controled TCs, or a set of IANA controled TCs. How is this going to work out if both organisations need to stay in sync on this? Has anybody checked with ITU that they are happy to be restricted to 255 code points? Can we get that in a statement from them (possibly from SG 4?)? Do we have arranged for ITU to check and sign-off on the values we currently have in this document? Maybe I am just worrying too much... I am pretty busy with other stuff, so I have not followed all the emails/postings all that closely. Bert From owner-disman@dorothy.bmc.com Mon Apr 15 10:19:10 2002 Received: from babbler.bmc.com (camaro.bmc.com [198.207.223.231]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18475 for ; Mon, 15 Apr 2002 10:19:09 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g3FELTK26355; Mon, 15 Apr 2002 09:21:29 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id HAA21262 for disman-list; Mon, 15 Apr 2002 07:15:21 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id HAA21257 for ; Mon, 15 Apr 2002 07:15:17 -0700 (PDT) Received: from mx-us-hou-2-int.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id g3FED7222343 for ; Mon, 15 Apr 2002 09:13:07 -0500 (CDT) Received: from pintail.mail.pas.earthlink.net (pintail.mail.pas.earthlink.net [207.217.120.122]) by mx-us-hou-2-int.bmc.com (Postfix) with SMTP id 374BB1FF019 for ; Mon, 15 Apr 2002 09:16:49 -0500 (CDT) Received: from 1cust97.tnt4.minneapolis.mn.da.uu.net ([67.251.180.97] helo=merkita.com) by pintail.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 16x7HU-0007Oj-00 for disman@dorothy.bmc.com; Mon, 15 Apr 2002 07:16:33 -0700 Message-ID: <3CBAE02F.CA9910DF@merkita.com> Date: Mon, 15 Apr 2002 09:14:07 -0500 From: Tammy Ferris Reply-To: tferris@merkita.com X-Mailer: Mozilla 4.75 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 Cc: disman@dorothy.bmc.com Subject: Re: Alarm MIB WG last call References: <20020411221558.92459.qmail@revab.best.vwh.net> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list Content-Transfer-Encoding: 8bit All, I ran across a perceived anomaly related to the first item in one of my previous mail that I thought would be relevant to point out. It was explained to me that the table for active alarms is indexed based on time the error occurred, which allows the manager the ability to not have to retrieve the whole table all the time but can just query on the "most recent" alarms. This appears to work fine in the nominal case, however the addition of alarm suppression feature creates an anomaly using that approach. If an error occurs while alarm reporting is suppressed and still exists when alarm reporting is no longer suppressed, the alarm will be reported at the time the suppression is released but the time stamp will indicate the time the error occurred not the time the error is reported (as it should be). Thus, when supporting both the alarm mib and the arc mib, there is the possibility that "new" alarms could show up in the active alarm table with time stamps older (having earlier time stamps) than any other alarm in the active alarm table. One solution to this, though expensive, would be to have 2 timestamps in the active alarm table: one for the time the error occured and the other for the time the alarm notification was sent. Regards, Tammy Tammy Lehtinen Ferris tferris@merkita.com +1 (763)577-5946 Merkita Incorporated www.merkita.com > > > > > Hi - > > > > Private email has made it clear that some folks didn't read the > > attached message. Make no mistake: disman WG last call on the > > alarm MIB began March 28 when the draft appeared. The WG last > > call will end 5 p.m. Pacific Daylight Time on April 11, 2002. > > > > ------------------------------------------------------ > > Randy Presuhn BMC Software, Inc. 1-3141 > > randy_presuhn@bmc.com 2141 North First Street > > Tel: +1 408 546-1006 San José, California 95131 USA > > ------------------------------------------------------ > > My opinions and BMC's are independent variables. > > ------------------------------------------------------ > > > > > From owner-disman@dorothy.bmc.com Mon Mar 18 13:08:39 PST 2002 > > > Date: Mon, 18 Mar 2002 13:08:17 -0800 (PST) > > > From: Randy Presuhn > > > Message-Id: <200203182108.NAA19616@dorothy.bmc.com> > > > To: disman@dorothy.bmc.com > > > Subject: Alarm MIB WG last call > > > List-Id: IETF disman Working Group mailing list > > > > > > Hi - > > > > > > We finished a first WG last call on the alarm MIB, and, > > > *surprise* found that some revisions were needed. I've talked > > > to some of the folks active in the discussion, and as disman > > > WG chair have decided that, when the revision appears, another > > > two-week WG last call on the document would be appropriate. > > > This last call will begin when the revised I-D becomes available. > > > > > > As with the previous last call, I would appreciate a (personal) > > > note from those who have read the document but not felt the > > > need to comment on the WG mailing list, so that I might better > > > assess how much review it has actually received. > > > > > > ------------------------------------------------------ > > > Randy Presuhn BMC Software, Inc. 1-3141 > > > randy_presuhn@bmc.com 2141 North First Street > > > Tel: +1 408 546-1006 San José, California 95131 USA > > > ------------------------------------------------------ > > > My opinions and BMC's are independent variables. > > > ------------------------------------------------------ > > > > > From owner-disman@dorothy.bmc.com Mon Apr 15 12:58:51 2002 Received: from babbler.bmc.com (camaro.bmc.com [198.207.223.231]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27729 for ; Mon, 15 Apr 2002 12:58:51 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g3FH1NM01238; Mon, 15 Apr 2002 12:01:24 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id JAA22487 for disman-list; Mon, 15 Apr 2002 09:55:25 -0700 (PDT) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id JAA22481; Mon, 15 Apr 2002 09:55:20 -0700 (PDT) Date: Mon, 15 Apr 2002 09:55:20 -0700 (PDT) From: Randy Presuhn Message-Id: <200204151655.JAA22481@dorothy.bmc.com> To: andreaw@cisco.com, bwijnen@lucent.com, disman@dorothy.bmc.com, hklam@lucent.com, jschott@cisco.com Subject: RE: FW: Probable Cause Cc: djsidor@nortelnetworks.com, randy@psg.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 - > Message-ID: > From: "Wijnen, Bert (Bert)" > To: "Lam, Hing-Kam (Kam)" , > Randy Presuhn , andreaw@cisco.com, > disman@dorothy.bmc.com, jschott@cisco.com > Cc: Randy Bush , Dave Sidor > Subject: RE: FW: Probable Cause > Date: Sun, 14 Apr 2002 12:33:01 +0200 > > Is this just me that sort of wrries when I see > > > Some more duplication cases in ITU-IANA-ALARM-TC: > > > > To me it is either a set of ITU controled TCs, or a set > of IANA controled TCs. How is this going to work out > if both organisations need to stay in sync on this? ... The problem is a both worse and not so bad. Some of the enumerations are peculiar to the DMTF, and even the ones that are supposed to be the same from the two specifications have slightly different names. However, what we're really trying to do here is to provide a way of mapping probable cause codes from different specifications into a single representation. That is, we're mapping from the ITU and DMTF (and possibly other) sets into our own. So, from this perspective, I think the synchronization issue is less serious. ------------------------------------------------------ Randy Presuhn BMC Software, Inc. 1-3141 randy_presuhn@bmc.com 2141 North First Street Tel: +1 408 546-1006 San José, California 95131 USA ------------------------------------------------------ My opinions and BMC's are independent variables. ------------------------------------------------------ From owner-disman@dorothy.bmc.com Mon Apr 15 13:01:49 2002 Received: from babbler.bmc.com (camaro.bmc.com [198.207.223.231]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27817 for ; Mon, 15 Apr 2002 13:01:49 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g3FH4Mc02225; Mon, 15 Apr 2002 12:04:22 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id JAA22662 for disman-list; Mon, 15 Apr 2002 09:58:57 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id IAA18999 for ; Sun, 14 Apr 2002 08:48:26 -0700 (PDT) Received: from mx-us-hou-1-int.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id g3EFkIl29178 for ; Sun, 14 Apr 2002 10:46:18 -0500 (CDT) Received: from ierw.net.avaya.com (unknown [198.152.13.101]) by mx-us-hou-1-int.bmc.com (Postfix) with SMTP id 43E8620EFE2 for ; Sun, 14 Apr 2002 10:50:04 -0500 (CDT) Received: from ierw.net.avaya.com (localhost [127.0.0.1]) by ierw.net.avaya.com (8.9.3+Sun/8.9.3) with ESMTP id LAA12926 for ; Sun, 14 Apr 2002 11:48:22 -0400 (EDT) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by ierw.net.avaya.com (8.9.3+Sun/8.9.3) with ESMTP id LAA12921 for ; Sun, 14 Apr 2002 11:48:21 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1E3CB.C3609D1D" Subject: RE: Alarm MIB WG last call Date: Sun, 14 Apr 2002 18:48:03 +0300 Message-ID: Thread-Topic: Alarm MIB WG last call Thread-Index: AcHic5tr4f/YlQwTTyGtbJ3BH033NABWA/Ww From: "Romascanu, Dan (Dan)" To: Cc: Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list This is a multi-part message in MIME format. ------_=_NextPart_001_01C1E3CB.C3609D1D Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Tammy, =20 I agree with the proposed change in the DESCRIPTION clause, which is = consistent with the definition of an alarm. =20 Wrt. the SYNTAX, this was debated in SLC (if I remember well), and the = decision was to go with DateAndTime. =20 Thanks, =20 Dan =20 -----Original Message----- From: Tammy Ferris [mailto:tferris@merkita.com] Sent: Saturday, April 13, 2002 12:00 AM Cc: disman@dorothy.bmc.com Subject: Re: Alarm MIB WG last call All,=20 Found another item. For clarity, I think the following definition:=20 alarmActiveDateAndTime OBJECT-TYPE=20 SYNTAX DateAndTime=20 MAX-ACCESS not-accessible=20 STATUS current=20 DESCRIPTION=20 "The local date and time when the alarm occurred.=20 Implementations MUST include the offset from UTC,=20 if available. Implementation in environments in which=20 the UTC offset is not available is NOT RECOMMENDED."=20 ::=3D { alarmActiveEntry 2 }=20 Should be modified to:=20 alarmActiveDateAndTime OBJECT-TYPE=20 SYNTAX DateAndTime=20 MAX-ACCESS not-accessible=20 STATUS current=20 DESCRIPTION=20 "The local date and time when the error occurred.=20 Implementations MUST include the offset from UTC,=20 if available. Implementation in environments in which=20 the UTC offset is not available is NOT RECOMMENDED."=20 ::=3D { alarmActiveEntry 2 }=20 =20 Of course, I would not object to two time stamps. One for the time the = error occurred and another for the time an alarm was reported.=20 Cheers,=20 Tammy=20 Tammy Lehtinen Ferris=20 tferris@merkita.com=20 +1 (763)577-5946=20 Merkita Incorporated=20 www.merkita.com=20 =20 >=20 > Hi -=20 >=20 > Private email has made it clear that some folks didn't read the=20 > attached message. Make no mistake: disman WG last call on the=20 > alarm MIB began March 28 when the draft appeared. The WG last=20 > call will end 5 p.m. Pacific Daylight Time on April 11, 2002.=20 >=20 > ------------------------------------------------------=20 > Randy Presuhn BMC Software, Inc. 1-3141=20 > randy_presuhn@bmc.com 2141 North First Street=20 > Tel: +1 408 546-1006 San Jos=E9, California 95131 USA=20 > ------------------------------------------------------=20 > My opinions and BMC's are independent variables.=20 > ------------------------------------------------------=20 >=20 > > From owner-disman@dorothy.bmc.com Mon Mar 18 13:08:39 PST 2002=20 > > Date: Mon, 18 Mar 2002 13:08:17 -0800 (PST)=20 > > From: Randy Presuhn =20 > > Message-Id: <200203182108.NAA19616@dorothy.bmc.com>=20 > > To: disman@dorothy.bmc.com=20 > > Subject: Alarm MIB WG last call=20 > > List-Id: IETF disman Working Group mailing list = =20 > >=20 > > Hi -=20 > >=20 > > We finished a first WG last call on the alarm MIB, and,=20 > > *surprise* found that some revisions were needed. I've talked=20 > > to some of the folks active in the discussion, and as disman=20 > > WG chair have decided that, when the revision appears, another=20 > > two-week WG last call on the document would be appropriate.=20 > > This last call will begin when the revised I-D becomes available.=20 > >=20 > > As with the previous last call, I would appreciate a (personal)=20 > > note from those who have read the document but not felt the=20 > > need to comment on the WG mailing list, so that I might better=20 > > assess how much review it has actually received.=20 > >=20 > > ------------------------------------------------------=20 > > Randy Presuhn BMC Software, Inc. 1-3141=20 > > randy_presuhn@bmc.com 2141 North First Street=20 > > Tel: +1 408 546-1006 San Jos=E9, California 95131 USA=20 > > ------------------------------------------------------=20 > > My opinions and BMC's are independent variables.=20 > > ------------------------------------------------------=20 > >=20 > ------_=_NextPart_001_01C1E3CB.C3609D1D Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Tammy,
 
I=20 agree with the proposed change in the DESCRIPTION clause, which is = consistent=20 with the definition of an alarm.
 
Wrt.=20 the SYNTAX, this was debated in SLC (if I remember well), and the = decision was=20 to go with DateAndTime.
 
Thanks,
 
Dan
 
-----Original Message-----
From: Tammy Ferris=20 [mailto:tferris@merkita.com]
Sent: Saturday, April 13, 2002 = 12:00=20 AM
Cc: disman@dorothy.bmc.com
Subject: Re: Alarm = MIB WG=20 last call

All,
Found another item.  For = clarity,=20 I think the following definition:
   = alarmActiveDateAndTime=20 OBJECT-TYPE
     =20 SYNTAX      DateAndTime=20
      MAX-ACCESS  not-accessible=20
      = STATUS     =20 current
      DESCRIPTION=20
          "The local = date and=20 time when the alarm occurred.=20

          = Implementations MUST=20 include the offset from UTC,=20
          if = available. =20 Implementation in environments in which=20
          the UTC = offset is=20 not available is NOT RECOMMENDED."
      = ::=3D {=20 alarmActiveEntry 2 }=20

Should be modified to:
   = alarmActiveDateAndTime=20 OBJECT-TYPE
     =20 SYNTAX      DateAndTime=20
      MAX-ACCESS  not-accessible=20
      = STATUS     =20 current
      DESCRIPTION=20
          "The local = date and=20 time when the error occurred.=20

          = Implementations MUST=20 include the offset from UTC,=20
          if = available. =20 Implementation in environments in which=20
          the UTC = offset is=20 not available is NOT RECOMMENDED."
      = ::=3D {=20 alarmActiveEntry 2 }
 =20

Of course, I would not object to two time stamps.  One for the = time=20 the error occurred and another for the time an alarm was reported. =
Cheers,=20
Tammy=20

Tammy Lehtinen Ferris
tferris@merkita.com
+1 (763)577-5946=20
Merkita Incorporated
www.merkita.com
 =20

>
> Hi -
>
> Private = email=20 has made it clear that some folks didn't read the
> attached=20 message.  Make no mistake:  disman WG last call on the =
>=20 alarm MIB began March 28 when the draft appeared.  The WG last =
>=20 call will end 5 p.m. Pacific Daylight Time on April 11, 2002. =
>=20
>  = ------------------------------------------------------=20
>  Randy=20 Presuhn          BMC = Software,=20 Inc.  1-3141
>  randy_presuhn@bmc.com  2141 = North=20 First Street
>  Tel: +1 408 546-1006   San = Jos=E9,=20 California 95131  USA
> =20 ------------------------------------------------------ =
>  My=20 opinions and BMC's are independent variables.
> =20 ------------------------------------------------------
> =
>=20 > From owner-disman@dorothy.bmc.com Mon Mar 18 13:08:39 PST 2002 =
>=20 > Date: Mon, 18 Mar 2002 13:08:17 -0800 (PST)
> > From: = Randy=20 Presuhn <rpresuhn>
> > Message-Id:=20 <200203182108.NAA19616@dorothy.bmc.com>
> > To:=20 disman@dorothy.bmc.com
> > Subject: Alarm MIB WG last call =
> > List-Id: IETF disman Working Group mailing list=20 <disman.dorothy.bmc.com>
> >
> > Hi - =
>=20 >
> > We finished a first WG last call on the alarm = MIB, and,=20
> > *surprise* found that some revisions were = needed.  I've=20 talked
> > to some of the folks active in the discussion, = and as=20 disman
> > WG chair have decided that, when the revision = appears,=20 another
> > two-week WG last call on the document would be = appropriate.
> > This last call will begin when the = revised I-D=20 becomes available.
> >
> > As with the previous = last=20 call, I would appreciate a (personal)
> > note from those = who have=20 read the document but not felt the
> > need to comment on = the WG=20 mailing list, so that I might better
> > assess how much = review it=20 has actually received.
> >
> > =20 ------------------------------------------------------
> = > =20 Randy Presuhn          = BMC=20 Software, Inc.  1-3141
> >  = randy_presuhn@bmc.com =20 2141 North First Street
> >  Tel: +1 408 = 546-1006  =20 San Jos=E9, California 95131  USA
> > =20 ------------------------------------------------------
> = > =20 My opinions and BMC's are independent variables.
> >  = ------------------------------------------------------
> > =
>
------_=_NextPart_001_01C1E3CB.C3609D1D-- From owner-disman@dorothy.bmc.com Mon Apr 15 13:10:36 2002 Received: from babbler.bmc.com (camaro.bmc.com [198.207.223.231]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28253 for ; Mon, 15 Apr 2002 13:10:35 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g3FHD9405459; Mon, 15 Apr 2002 12:13:09 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id KAA23002 for disman-list; Mon, 15 Apr 2002 10:07:40 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id KAA22996; Mon, 15 Apr 2002 10:07:36 -0700 (PDT) Received: from mx-us-hou-2-int.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id g3FH5Rb00925; Mon, 15 Apr 2002 12:05:27 -0500 (CDT) Received: from auemail1.firewall.lucent.com (auemail1.lucent.com [192.11.223.161]) by mx-us-hou-2-int.bmc.com (Postfix) with SMTP id 16E1E1FF01D; Mon, 15 Apr 2002 12:09:09 -0500 (CDT) Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by auemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g3FH8qn02964; Mon, 15 Apr 2002 13:08:52 -0400 (EDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2653.19) id <2GN7YJ1H>; Mon, 15 Apr 2002 19:08:51 +0200 Message-ID: From: "Wijnen, Bert (Bert)" To: Randy Presuhn , andreaw@cisco.com, disman@dorothy.bmc.com, hklam@lucent.com, jschott@cisco.com Cc: djsidor@nortelnetworks.com, randy@psg.com Subject: RE: FW: Probable Cause Date: Mon, 15 Apr 2002 19:08:48 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list But we are limiting the range within which these other organisations can extend (if they ever need to) right? I think it would behoove us to try and get some official agreement from those other orgs that this is OK. WIth official, I think I would be happy to see it in the form of an email from the specifi cSG or WG (or whatever they call them) chair who is responsible for such codes. Bert > -----Original Message----- > From: Randy Presuhn [mailto:rpresuhn@dorothy.bmc.com] > Sent: Monday, April 15, 2002 6:55 PM > To: andreaw@cisco.com; bwijnen@lucent.com; disman@dorothy.bmc.com; > hklam@lucent.com; jschott@cisco.com > Cc: djsidor@nortelnetworks.com; randy@psg.com > Subject: RE: FW: Probable Cause > > > Hi - > > > Message-ID: > cent.com> > > From: "Wijnen, Bert (Bert)" > > To: "Lam, Hing-Kam (Kam)" , > > Randy Presuhn , andreaw@cisco.com, > > disman@dorothy.bmc.com, jschott@cisco.com > > Cc: Randy Bush , Dave Sidor > > > Subject: RE: FW: Probable Cause > > Date: Sun, 14 Apr 2002 12:33:01 +0200 > > > > Is this just me that sort of wrries when I see > > > > > Some more duplication cases in ITU-IANA-ALARM-TC: > > > > > > > To me it is either a set of ITU controled TCs, or a set > > of IANA controled TCs. How is this going to work out > > if both organisations need to stay in sync on this? > ... > > The problem is a both worse and not so bad. > > Some of the enumerations are peculiar to the DMTF, and > even the ones that are supposed to be the same from the two > specifications have slightly different names. > > However, what we're really trying to do here is to provide > a way of mapping probable cause codes from different > specifications into a single representation. > > That is, we're mapping from the ITU and DMTF (and possibly > other) sets into our own. So, from this perspective, I think > the synchronization issue is less serious. > > ------------------------------------------------------ > Randy Presuhn BMC Software, Inc. 1-3141 > randy_presuhn@bmc.com 2141 North First Street > Tel: +1 408 546-1006 San Jose, California 95131 USA > ------------------------------------------------------ > My opinions and BMC's are independent variables. > ------------------------------------------------------ > From owner-disman@dorothy.bmc.com Mon Apr 15 13:36:00 2002 Received: from babbler.bmc.com (firebird.bmc.com [198.207.223.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29163 for ; Mon, 15 Apr 2002 13:36:00 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g3FHcY609902; Mon, 15 Apr 2002 12:38:34 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id KAA23355 for disman-list; Mon, 15 Apr 2002 10:33:04 -0700 (PDT) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id KAA23349; Mon, 15 Apr 2002 10:33:00 -0700 (PDT) Date: Mon, 15 Apr 2002 10:33:00 -0700 (PDT) From: Randy Presuhn Message-Id: <200204151733.KAA23349@dorothy.bmc.com> To: andreaw@cisco.com, bwijnen@lucent.com, disman@dorothy.bmc.com, hklam@lucent.com, jschott@cisco.com Subject: RE: FW: Probable Cause Cc: djsidor@nortelnetworks.com, randy@psg.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 - > Message-ID: > From: "Wijnen, Bert (Bert)" > To: Randy Presuhn , andreaw@cisco.com, > disman@dorothy.bmc.com, hklam@lucent.com, jschott@cisco.com > Cc: djsidor@nortelnetworks.com, randy@psg.com > Subject: RE: FW: Probable Cause > Date: Mon, 15 Apr 2002 19:08:48 +0200 > > But we are limiting the range within which these other > organisations can extend (if they ever need to) right? > I think it would behoove us to try and get some official > agreement from those other orgs that this is OK. WIth > official, I think I would be happy to see it in the form > of an email from the specifi cSG or WG (or whatever they > call them) chair who is responsible for such codes. ... The language in question in the IANA considerations section does not constrain ITU in any way. It only sets aside a space in which ITU values and our "mapped" values will be the same. (As a technical contributor, I don't see a lot of value to keeping the numbers the same, except perhaps in devices too resource-constrained to implement this MIB anyway.) | Values of IANAItuProbableCause less than 255 can only be given out | if they correspond to ITU numbers and are agreed to by the disman | working group. Values of IANAItuProbableCause greater than 255 can | be given out when agreed to by the disman working group. | | Values of IANAItuEventType can be given out when agreed to by the | disman working group. (I do agree with the earlier comment that the second paragraph implies a kind of WG immortality that is probably not appropriate.) ------------------------------------------------------ Randy Presuhn BMC Software, Inc. 1-3141 randy_presuhn@bmc.com 2141 North First Street Tel: +1 408 546-1006 San José, California 95131 USA ------------------------------------------------------ My opinions and BMC's are independent variables. ------------------------------------------------------ From owner-disman@dorothy.bmc.com Mon Apr 15 13:57:43 2002 Received: from babbler.bmc.com (camaro.bmc.com [198.207.223.231]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00194 for ; Mon, 15 Apr 2002 13:57:43 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g3FI0HO14908; Mon, 15 Apr 2002 13:00:17 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id KAA23473 for disman-list; Mon, 15 Apr 2002 10:54:50 -0700 (PDT) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id KAA23467 for disman@dorothy.bmc.com; Mon, 15 Apr 2002 10:54:47 -0700 (PDT) Date: Mon, 15 Apr 2002 10:54:47 -0700 (PDT) From: Randy Presuhn Message-Id: <200204151754.KAA23467@dorothy.bmc.com> To: disman@dorothy.bmc.com Subject: html on disman list 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 - Please note that if your mailer spews HTML or sends multipart / alternative MIME to the disman list, your postings will be delayed until they can be manually approved. This is a defense against the forged viral mailings that have hit other IETF working group lists. Note that some cheesy mail readers will try to reply "in kind" to HTML messages. With one such defective tool, the sequence Format->Plain Text in the reply window will serve to override the annoying behaviour. ------------------------------------------------------ Randy Presuhn BMC Software, Inc. 1-3141 randy_presuhn@bmc.com 2141 North First Street Tel: +1 408 546-1006 San José, California 95131 USA ------------------------------------------------------ My opinions and BMC's are independent variables. ------------------------------------------------------ From owner-disman@dorothy.bmc.com Mon Apr 15 18:31:38 2002 Received: from babbler.bmc.com (firebird.bmc.com [198.207.223.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08355 for ; Mon, 15 Apr 2002 18:31:38 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g3FMY8c18486; Mon, 15 Apr 2002 17:34:12 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id PAA24340 for disman-list; Mon, 15 Apr 2002 15:27:42 -0700 (PDT) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id PAA24332; Mon, 15 Apr 2002 15:27:38 -0700 (PDT) Date: Mon, 15 Apr 2002 15:27:38 -0700 (PDT) From: Randy Presuhn Message-Id: <200204152227.PAA24332@dorothy.bmc.com> To: andreaw@cisco.com, disman@dorothy.bmc.com Subject: RE: FW: Probable Cause Cc: jschott@cisco.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 - > Subject: RE: FW: Probable Cause > Date: Sun, 14 Apr 2002 13:04:04 +0300 > Message-ID: > From: "Romascanu, Dan (Dan)" > To: "Lam, Hing-Kam (Kam)" , > "Randy Presuhn" , , > > Cc: ... > The question is where we go from here. Possible path: > > - keep all mappings from the original ITU list (values <256) > - eliminate obvious duplication cases > - wherever mapping of the ITU to CIM values is not perfect, add new values (>256) to fill in possible alarm cases not covered by ITU > > Does this seem reasonable? ... As a technical contributor, I think this might be a start, but it's not enough. See my posting *much* earlier in this thread to see why. In short: we also have 1:n, n:1, and n:n mappings between the DMTF and the ITU stuff to consider. At the very least I think we need to say something about performing the mappings in such a way as to not lose precision from whatever was received. ------------------------------------------------------ Randy Presuhn BMC Software, Inc. 1-3141 randy_presuhn@bmc.com 2141 North First Street Tel: +1 408 546-1006 San José, California 95131 USA ------------------------------------------------------ My opinions and BMC's are independent variables. ------------------------------------------------------ From owner-disman@dorothy.bmc.com Mon Apr 15 18:41:58 2002 Received: from babbler.bmc.com (camaro.bmc.com [198.207.223.231]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08742 for ; Mon, 15 Apr 2002 18:41:58 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g3FMiY020050; Mon, 15 Apr 2002 17:44:34 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id PAA24389 for disman-list; Mon, 15 Apr 2002 15:38:43 -0700 (PDT) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id PAA24383 for disman@dorothy.bmc.com; Mon, 15 Apr 2002 15:38:40 -0700 (PDT) Date: Mon, 15 Apr 2002 15:38:40 -0700 (PDT) From: Randy Presuhn Message-Id: <200204152238.PAA24383@dorothy.bmc.com> To: disman@dorothy.bmc.com Subject: RE: FW: Probable Cause 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: <3549C09B853DD5119B540002A52CDD3402C0AD70@zcard0ka.ca.nortel.com> > From: "Sharon Chisholm" > To: disman@dorothy.bmc.com > Cc: Randy Bush , "Wijnen, Bert (Bert)" > Subject: RE: FW: Probable Cause > Date: Mon, 15 Apr 2002 07:36:53 -0400 ... > It's actually called IANA-ITU-ALARM-TC, but that > probably does not help your concerns much. > > Study group 4 has seen the textual convention and > seem happy with it. I'm not sure if they noticed > the 255 limit, but we can verify. > > It would seem a liaison statement on how we get > ITU sign-off on these values would be useful. ... Please, let's NOT get into this mode of operation. The ITU does not "own" this MIB. It's a product of this working group, and part of our job is to consider related work, such as that of the ITU, to ensure that we can adequately represent the things we need to represent. Both the SG4 and the DMTF have been most helpful in providing us with information so that we might accomplish our task. If we believe that we have a requirement to be able to preserve "probable cause" semantics from DMTF and ITU management information, the minimum requirement for us is only to ensure that we define a mapping from their code sets to ours that does not lose information. They do not need to approve our mappings. ------------------------------------------------------ Randy Presuhn BMC Software, Inc. 1-3141 randy_presuhn@bmc.com 2141 North First Street Tel: +1 408 546-1006 San José, California 95131 USA ------------------------------------------------------ My opinions and BMC's are independent variables. ------------------------------------------------------ From owner-disman@dorothy.bmc.com Tue Apr 16 06:59:07 2002 Received: from babbler.bmc.com (camaro.bmc.com [198.207.223.231]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28935 for ; Tue, 16 Apr 2002 06:59:07 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g3GB1JD12679; Tue, 16 Apr 2002 06:01:22 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id DAA25981 for disman-list; Tue, 16 Apr 2002 03:54:28 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id DAA25975; Tue, 16 Apr 2002 03:54:24 -0700 (PDT) Received: from mx-us-hou-1-int.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id g3GAqFt27007; Tue, 16 Apr 2002 05:52:15 -0500 (CDT) Received: from ierw.net.avaya.com (unknown [198.152.13.101]) by mx-us-hou-1-int.bmc.com (Postfix) with SMTP id DCAE820EFA7; Tue, 16 Apr 2002 05:55:56 -0500 (CDT) Received: from ierw.net.avaya.com (localhost [127.0.0.1]) by ierw.net.avaya.com (8.9.3+Sun/8.9.3) with ESMTP id GAA20908; Tue, 16 Apr 2002 06:54:15 -0400 (EDT) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by ierw.net.avaya.com (8.9.3+Sun/8.9.3) with ESMTP id GAA20879; Tue, 16 Apr 2002 06:54:13 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: FW: Probable Cause Date: Tue, 16 Apr 2002 13:53:56 +0300 Message-ID: Thread-Topic: FW: Probable Cause Thread-Index: AcHkznXVN2k4w6/mQ8qgLC3TmNDbdQAZqkKg From: "Romascanu, Dan (Dan)" To: "Randy Presuhn" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by dorothy.bmc.com id DAA25976 Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list Content-Transfer-Encoding: 8bit > > From: "Sharon Chisholm" > ... > > It's actually called IANA-ITU-ALARM-TC, but that > > probably does not help your concerns much. > > > > Study group 4 has seen the textual convention and > > seem happy with it. I'm not sure if they noticed > > the 255 limit, but we can verify. > > > > It would seem a liaison statement on how we get > > ITU sign-off on these values would be useful. > ... > > Please, let's NOT get into this mode of operation. > > The ITU does not "own" this MIB. It's a product of > this working group, and part of our job is to consider > related work, such as that of the ITU, to ensure that we > can adequately represent the things we need to represent. > Both the SG4 and the DMTF have been most helpful in providing > us with information so that we might accomplish our task. > > If we believe that we have a requirement to be able to > preserve "probable cause" semantics from DMTF and ITU > management information, the minimum requirement for us is > only to ensure that we define a mapping from their code sets > to ours that does not lose information. They do not need to > approve our mappings. > > ------------------------------------------------------ > Randy Presuhn > I agree. Dan From owner-disman@dorothy.bmc.com Tue Apr 16 07:09:28 2002 Received: from babbler.bmc.com (camaro.bmc.com [198.207.223.231]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29088 for ; Tue, 16 Apr 2002 07:09:27 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g3GBBwg14872; Tue, 16 Apr 2002 06:11:58 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id EAA26015 for disman-list; Tue, 16 Apr 2002 04:06:32 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id EAA26009; Tue, 16 Apr 2002 04:06:28 -0700 (PDT) Received: from mx-us-hou-2-int.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id g3GB4J301887; Tue, 16 Apr 2002 06:04:19 -0500 (CDT) Received: from ierw.net.avaya.com (ierw.net.avaya.com [198.152.13.101]) by mx-us-hou-2-int.bmc.com (Postfix) with SMTP id 103DE1FF048; Tue, 16 Apr 2002 06:08:01 -0500 (CDT) Received: from ierw.net.avaya.com (localhost [127.0.0.1]) by ierw.net.avaya.com (8.9.3+Sun/8.9.3) with ESMTP id HAA25632; Tue, 16 Apr 2002 07:06:09 -0400 (EDT) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by ierw.net.avaya.com (8.9.3+Sun/8.9.3) with ESMTP id HAA25628; Tue, 16 Apr 2002 07:06:07 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: FW: Probable Cause Date: Tue, 16 Apr 2002 14:05:49 +0300 Message-ID: Thread-Topic: FW: Probable Cause Thread-Index: AcHkzQpOTU1gfR0YQ6SCqVfPd3mK6wAaDpfA From: "Romascanu, Dan (Dan)" To: "Randy Presuhn" , , Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by dorothy.bmc.com id EAA26010 Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list Content-Transfer-Encoding: 8bit > > From: "Romascanu, Dan (Dan)" > ... > > The question is where we go from here. Possible path: > > > > - keep all mappings from the original ITU list (values <256) > > - eliminate obvious duplication cases > > - wherever mapping of the ITU to CIM values is not perfect, > add new values (>256) to fill in possible alarm cases not > covered by ITU > > > > Does this seem reasonable? > ... > > As a technical contributor, I think this might be a start, > but it's not enough. See my posting *much* earlier in this > thread to see why. In short: we also have 1:n, n:1, and n:n > mappings between the DMTF and the ITU stuff to consider. > At the very least I think we need to say something about > performing the mappings in such a way as to not lose precision > from whatever was received. > > Randy Presuhn BMC Software, Inc. 1-3141 > randy_presuhn@bmc.com 2141 North First Street > I am not sure that I follow you completely. Our concept is that the ITU list is the basic staff and reference model for the list of possible causes. We should add staff from other sources only when we think something is missing in the ITU list. This was the reason - as I understood it - to look into the DMTF stuff. If somebody invents a better and greater list later, he could go to IANA and have the his new values added to the TC, as well as explanatory commented text to document the mapping of other values from his list in the previously available values. IMO the text assigning the responsibility of administrating the list to the disman wg for eternity should be changed. Regards, Dan From owner-disman@dorothy.bmc.com Tue Apr 16 07:39:04 2002 Received: from babbler.bmc.com (camaro.bmc.com [198.207.223.231]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29566 for ; Tue, 16 Apr 2002 07:39:04 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g3GBfdM18583; Tue, 16 Apr 2002 06:41:39 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id EAA26072 for disman-list; Tue, 16 Apr 2002 04:36:11 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id EAA26067 for ; Tue, 16 Apr 2002 04:36:07 -0700 (PDT) Received: from mx-us-hou-1-int.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id g3GBXwi14889 for ; Tue, 16 Apr 2002 06:33:58 -0500 (CDT) Received: from hose.mail.pipex.net (unknown [158.43.128.58]) by mx-us-hou-1-int.bmc.com (Postfix) with SMTP id B24F420EFB1 for ; Tue, 16 Apr 2002 06:37:39 -0500 (CDT) Received: (qmail 28378 invoked from network); 16 Apr 2002 08:55:19 -0000 Received: from useraf66.uk.uudial.com (HELO tom3) (62.188.132.53) by smtp-4.dial.pipex.com with SMTP; 16 Apr 2002 08:55:19 -0000 Message-ID: <002b01c1e524$24119540$0301a8c0@tom3> Reply-To: "Tom Petch" From: "Tom Petch" To: "disman" Subject: Alarm MIB et al; monotonic increasing Date: Tue, 16 Apr 2002 09:41:04 +0100 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 4.72.2106.4 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list Content-Transfer-Encoding: 7bit I am concerned about the use of monotonic increasing in the Alarm MIB and others. My university text book - E.G. Philips A Course of Analysis (1960) - defines monotonic increasing as s1 LTE s2 LTE s3 LTE s4 ... eg 1 1 3 5 7 7 9 10 .. which won't do for an INDEX such as alarmActiveVariableIndex or alarmActiveIndex. Any thoughts? Tom Petch, Network Consultant nwnetworks@dial.pipex.com From owner-disman@dorothy.bmc.com Tue Apr 16 07:39:31 2002 Received: from babbler.bmc.com (camaro.bmc.com [198.207.223.231]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29581 for ; Tue, 16 Apr 2002 07:39:31 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g3GBg6f18662; Tue, 16 Apr 2002 06:42:06 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id EAA26082 for disman-list; Tue, 16 Apr 2002 04:36:41 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id EAA26077 for ; Tue, 16 Apr 2002 04:36:37 -0700 (PDT) Received: from mx-us-hou-2-int.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id g3GBYSP15120 for ; Tue, 16 Apr 2002 06:34:28 -0500 (CDT) Received: from ierw.net.avaya.com (ierw.net.avaya.com [198.152.13.101]) by mx-us-hou-2-int.bmc.com (Postfix) with SMTP id 2FA0D1FF029 for ; Tue, 16 Apr 2002 06:38:10 -0500 (CDT) Received: from ierw.net.avaya.com (localhost [127.0.0.1]) by ierw.net.avaya.com (8.9.3+Sun/8.9.3) with ESMTP id HAA08872 for ; Tue, 16 Apr 2002 07:36:18 -0400 (EDT) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by ierw.net.avaya.com (8.9.3+Sun/8.9.3) with ESMTP id HAA08863 for ; Tue, 16 Apr 2002 07:36:17 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Alarm MIB WG last call Date: Tue, 16 Apr 2002 14:35:59 +0300 Message-ID: Thread-Topic: Alarm MIB WG last call Thread-Index: AcHkiDj4VJ3/Y+xbQDCPrZjLBn7T3QAsVi4g From: "Romascanu, Dan (Dan)" To: Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by dorothy.bmc.com id EAA26078 Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list Content-Transfer-Encoding: 8bit You are correct in the analysis of the behavior. However, I think that this is how it should work. Assuming that an alarm suppression mechanism is supported you seem to make assumptions about how it should work - timestamps of when the error occurred are somehow kept internally. This is an implementation assumption. What if in another implementation, polling an error conditions starts only after the suppression is released. Actually Alarm suppression is not part of the scope of the Alarm MIB. Model Specific Alarm MIBs may add such mechanisms, and document the behavior. Regards, Dan > -----Original Message----- > From: Tammy Ferris [mailto:tferris@merkita.com] > Sent: Monday, April 15, 2002 5:14 PM > Cc: disman@dorothy.bmc.com > Subject: Re: Alarm MIB WG last call > > > All, > I ran across a perceived anomaly related to the first item in > one of my previous > mail that I thought would be relevant to point out. > > It was explained to me that the table for active alarms is > indexed based on time > the error occurred, which allows the manager the ability to > not have to retrieve > the whole table all the time but can just query on the "most > recent" alarms. > > This appears to work fine in the nominal case, however the > addition of alarm > suppression feature creates an anomaly using that approach. > > If an error occurs while alarm reporting is suppressed and > still exists when > alarm reporting is no longer suppressed, the alarm will be > reported at the time > the suppression is released but the time stamp will indicate > the time the error > occurred not the time the error is reported (as it should > be). Thus, when > supporting both the alarm mib and the arc mib, there is the > possibility that > "new" alarms could show up in the active alarm table with > time stamps older > (having earlier time stamps) than any other alarm in the > active alarm table. > > One solution to this, though expensive, would be to have 2 > timestamps in the > active alarm table: one for the time the error occured and > the other for the > time the alarm notification was sent. > > Regards, > Tammy > > Tammy Lehtinen Ferris > tferris@merkita.com > +1 (763)577-5946 > Merkita Incorporated > www.merkita.com > > > > > > > > > > Hi - > > > > > > Private email has made it clear that some folks didn't read the > > > attached message. Make no mistake: disman WG last call on the > > > alarm MIB began March 28 when the draft appeared. The WG last > > > call will end 5 p.m. Pacific Daylight Time on April 11, 2002. > > > > > > ------------------------------------------------------ > > > Randy Presuhn BMC Software, Inc. 1-3141 > > > randy_presuhn@bmc.com 2141 North First Street > > > Tel: +1 408 546-1006 San José, California 95131 USA > > > ------------------------------------------------------ > > > My opinions and BMC's are independent variables. > > > ------------------------------------------------------ > > > > > > > From owner-disman@dorothy.bmc.com Mon Mar 18 13:08:39 PST 2002 > > > > Date: Mon, 18 Mar 2002 13:08:17 -0800 (PST) > > > > From: Randy Presuhn > > > > Message-Id: <200203182108.NAA19616@dorothy.bmc.com> > > > > To: disman@dorothy.bmc.com > > > > Subject: Alarm MIB WG last call > > > > List-Id: IETF disman Working Group mailing list > > > > > > > > > Hi - > > > > > > > > We finished a first WG last call on the alarm MIB, and, > > > > *surprise* found that some revisions were needed. I've talked > > > > to some of the folks active in the discussion, and as disman > > > > WG chair have decided that, when the revision appears, another > > > > two-week WG last call on the document would be appropriate. > > > > This last call will begin when the revised I-D becomes > available. > > > > > > > > As with the previous last call, I would appreciate a (personal) > > > > note from those who have read the document but not felt the > > > > need to comment on the WG mailing list, so that I might better > > > > assess how much review it has actually received. > > > > > > > > ------------------------------------------------------ > > > > Randy Presuhn BMC Software, Inc. 1-3141 > > > > randy_presuhn@bmc.com 2141 North First Street > > > > Tel: +1 408 546-1006 San José, California 95131 USA > > > > ------------------------------------------------------ > > > > My opinions and BMC's are independent variables. > > > > ------------------------------------------------------ > > > > > > > > > From owner-disman@dorothy.bmc.com Tue Apr 16 07:59:10 2002 Received: from babbler.bmc.com (firebird.bmc.com [198.207.223.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00047 for ; Tue, 16 Apr 2002 07:59:09 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g3GC1iU20788; Tue, 16 Apr 2002 07:01:44 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id EAA26193 for disman-list; Tue, 16 Apr 2002 04:56:04 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id EAA26186 for ; Tue, 16 Apr 2002 04:55:58 -0700 (PDT) Received: from mx-us-hou-1-int.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id g3GBrl423105 for ; Tue, 16 Apr 2002 06:53:47 -0500 (CDT) Received: from ierw.net.avaya.com (unknown [198.152.13.101]) by mx-us-hou-1-int.bmc.com (Postfix) with SMTP id 3E7CF20EFB4 for ; Tue, 16 Apr 2002 06:57:29 -0500 (CDT) Received: from ierw.net.avaya.com (localhost [127.0.0.1]) by ierw.net.avaya.com (8.9.3+Sun/8.9.3) with ESMTP id HAA17779 for ; Tue, 16 Apr 2002 07:55:47 -0400 (EDT) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by ierw.net.avaya.com (8.9.3+Sun/8.9.3) with ESMTP id HAA17732 for ; Tue, 16 Apr 2002 07:55:46 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Alarm MIB et al; monotonic increasing Date: Tue, 16 Apr 2002 14:55:28 +0300 Message-ID: Thread-Topic: Alarm MIB et al; monotonic increasing Thread-Index: AcHlOwSann3URORCRQuaAnWs8E3P0gAAmTtA From: "Romascanu, Dan (Dan)" To: "Tom Petch" , "disman" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by dorothy.bmc.com id EAA26187 Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list Content-Transfer-Encoding: 8bit With all due respect to your text book - this is the widely spread way we are defining the 'arbitrary' indices in many IETF MIBs. Actually what do you suggest? would 'strictly monotonic increasing' be OK? Thanks, Dan > -----Original Message----- > From: Tom Petch [mailto:nwnetworks@dial.pipex.com] > Sent: Tuesday, April 16, 2002 11:41 AM > To: disman > Subject: Alarm MIB et al; monotonic increasing > > > I am concerned about the use of monotonic increasing in the > Alarm MIB and others. > > My university text book - E.G. Philips A Course of Analysis > (1960) - defines monotonic increasing as > s1 LTE s2 LTE s3 LTE s4 ... > eg 1 1 3 5 7 7 9 10 .. > which won't do for an INDEX such as > alarmActiveVariableIndex or alarmActiveIndex. > > Any thoughts? > > Tom Petch, Network Consultant > nwnetworks@dial.pipex.com > > > > From owner-disman@dorothy.bmc.com Tue Apr 16 10:19:02 2002 Received: from babbler.bmc.com (firebird.bmc.com [198.207.223.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05805 for ; Tue, 16 Apr 2002 10:19:01 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g3GELa616739; Tue, 16 Apr 2002 09:21:36 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id HAA26575 for disman-list; Tue, 16 Apr 2002 07:15:42 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id HAA26570 for ; Tue, 16 Apr 2002 07:15:37 -0700 (PDT) Received: from mx-us-hou-1-int.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id g3GEDSU03198 for ; Tue, 16 Apr 2002 09:13:28 -0500 (CDT) Received: from falcon.prod.itd.earthlink.net (unknown [207.217.120.74]) by mx-us-hou-1-int.bmc.com (Postfix) with SMTP id 6342D20EFB9 for ; Tue, 16 Apr 2002 09:17:10 -0500 (CDT) Received: from 1cust149.tnt2.minneapolis.mn.da.uu.net ([67.251.129.149] helo=merkita.com) by falcon.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16xTlW-0001wP-00; Tue, 16 Apr 2002 07:17:03 -0700 Message-ID: <3CBC31CB.A960147B@merkita.com> Date: Tue, 16 Apr 2002 09:14:36 -0500 From: Tammy Ferris Reply-To: tferris@merkita.com X-Mailer: Mozilla 4.75 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Romascanu, Dan (Dan)" Cc: disman@dorothy.bmc.com Subject: Re: Alarm MIB WG last call References: Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list Content-Transfer-Encoding: 8bit Dan, While the ARC MIB is a separate MIB, it was my understanding that it should work together with this Alarm MIB in a compatible fashion and that they both (and possibly other MIBs as well --- such as a Conditions MIB (or should I say Error MIB)) fell under the topic of Alarm Management. I certainly don't see the Alarm MIB as sufficient to meet my Alarm Management requirements. However, with the addition of other MIBs, it should hopefully be close enough (It will always lack some of the ad hoc capabilities I have in using other protocols.). Some implementations may do polling but that would violate the T1 and ITU requirements and not be acceptable for telecommunications applications. So, while some may do polling, there are definitely some that will not. Further, polling makes for poor analysis because the receiver of the alarm information, without a valid time stamp, cannot correlate the occurrence of the error with any other activities that were occurring at the time the error occurred. Philosophically, I think it would be better to have no time stamp than an incorrect one with no indication that it is incorrect. But again, an elimination of the time stamp would not meet my requirements. Regards, Tammy Tammy Lehtinen Ferris tferris@merkita.com +1 (763)557-1681 Merkita Incorporated www.merkita.com "Romascanu, Dan (Dan)" wrote: > You are correct in the analysis of the behavior. However, I think that this is how it should work. > > Assuming that an alarm suppression mechanism is supported you seem to make assumptions about how it should work - timestamps of when the error occurred are somehow kept internally. This is an implementation assumption. What if in another implementation, polling an error conditions starts only after the suppression is released. > > Actually Alarm suppression is not part of the scope of the Alarm MIB. Model Specific Alarm MIBs may add such mechanisms, and document the behavior. > > Regards, > > Dan > > > -----Original Message----- > > From: Tammy Ferris [mailto:tferris@merkita.com] > > Sent: Monday, April 15, 2002 5:14 PM > > Cc: disman@dorothy.bmc.com > > Subject: Re: Alarm MIB WG last call > > > > > > All, > > I ran across a perceived anomaly related to the first item in > > one of my previous > > mail that I thought would be relevant to point out. > > > > It was explained to me that the table for active alarms is > > indexed based on time > > the error occurred, which allows the manager the ability to > > not have to retrieve > > the whole table all the time but can just query on the "most > > recent" alarms. > > > > This appears to work fine in the nominal case, however the > > addition of alarm > > suppression feature creates an anomaly using that approach. > > > > If an error occurs while alarm reporting is suppressed and > > still exists when > > alarm reporting is no longer suppressed, the alarm will be > > reported at the time > > the suppression is released but the time stamp will indicate > > the time the error > > occurred not the time the error is reported (as it should > > be). Thus, when > > supporting both the alarm mib and the arc mib, there is the > > possibility that > > "new" alarms could show up in the active alarm table with > > time stamps older > > (having earlier time stamps) than any other alarm in the > > active alarm table. > > > > One solution to this, though expensive, would be to have 2 > > timestamps in the > > active alarm table: one for the time the error occured and > > the other for the > > time the alarm notification was sent. > > > > Regards, > > Tammy > > > > Tammy Lehtinen Ferris > > tferris@merkita.com > > +1 (763)577-5946 > > Merkita Incorporated > > www.merkita.com > > > > > > > > > > > > > > > Hi - > > > > > > > > Private email has made it clear that some folks didn't read the > > > > attached message. Make no mistake: disman WG last call on the > > > > alarm MIB began March 28 when the draft appeared. The WG last > > > > call will end 5 p.m. Pacific Daylight Time on April 11, 2002. > > > > > > > > ------------------------------------------------------ > > > > Randy Presuhn BMC Software, Inc. 1-3141 > > > > randy_presuhn@bmc.com 2141 North First Street > > > > Tel: +1 408 546-1006 San José, California 95131 USA > > > > ------------------------------------------------------ > > > > My opinions and BMC's are independent variables. > > > > ------------------------------------------------------ > > > > > > > > > From owner-disman@dorothy.bmc.com Mon Mar 18 13:08:39 PST 2002 > > > > > Date: Mon, 18 Mar 2002 13:08:17 -0800 (PST) > > > > > From: Randy Presuhn > > > > > Message-Id: <200203182108.NAA19616@dorothy.bmc.com> > > > > > To: disman@dorothy.bmc.com > > > > > Subject: Alarm MIB WG last call > > > > > List-Id: IETF disman Working Group mailing list > > > > > > > > > > > > Hi - > > > > > > > > > > We finished a first WG last call on the alarm MIB, and, > > > > > *surprise* found that some revisions were needed. I've talked > > > > > to some of the folks active in the discussion, and as disman > > > > > WG chair have decided that, when the revision appears, another > > > > > two-week WG last call on the document would be appropriate. > > > > > This last call will begin when the revised I-D becomes > > available. > > > > > > > > > > As with the previous last call, I would appreciate a (personal) > > > > > note from those who have read the document but not felt the > > > > > need to comment on the WG mailing list, so that I might better > > > > > assess how much review it has actually received. > > > > > > > > > > ------------------------------------------------------ > > > > > Randy Presuhn BMC Software, Inc. 1-3141 > > > > > randy_presuhn@bmc.com 2141 North First Street > > > > > Tel: +1 408 546-1006 San José, California 95131 USA > > > > > ------------------------------------------------------ > > > > > My opinions and BMC's are independent variables. > > > > > ------------------------------------------------------ > > > > > > > > > > > > > From owner-disman@dorothy.bmc.com Tue Apr 16 11:23:40 2002 Received: from babbler.bmc.com (firebird.bmc.com [198.207.223.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07901 for ; Tue, 16 Apr 2002 11:23:39 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g3GFQAt04767; Tue, 16 Apr 2002 10:26:14 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id IAA26754 for disman-list; Tue, 16 Apr 2002 08:20:04 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id IAA26749 for ; Tue, 16 Apr 2002 08:19:59 -0700 (PDT) Received: from mx-us-hou-2-int.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id g3GFHoe10225 for ; Tue, 16 Apr 2002 10:17:50 -0500 (CDT) Received: from hose.mail.pipex.net (hose.mail.pipex.net [158.43.128.58]) by mx-us-hou-2-int.bmc.com (Postfix) with SMTP id D652B1FF03D for ; Tue, 16 Apr 2002 10:21:31 -0500 (CDT) Received: (qmail 15391 invoked from network); 16 Apr 2002 12:27:02 -0000 Received: from userbh39.uk.uudial.com (HELO tom3) (62.188.143.4) by smtp-4.dial.pipex.com with SMTP; 16 Apr 2002 12:27:02 -0000 Message-ID: <00bb01c1e541$b76b9300$0301a8c0@tom3> Reply-To: "Tom Petch" From: "Tom Petch" To: "disman" Subject: Alarm MIB et al; identifying a Trap Date: Tue, 16 Apr 2002 13:23:45 +0100 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 4.72.2106.4 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list Content-Transfer-Encoding: 7bit Two thoughts on identifying a SNMPv1 Trap in the Alarm MIB and others. 1) The community name is an OCTET STRING of up to 255 octets;this gets stored in an SnmpAdmin String eg alarmActiveContextName which is limited to 32 octets; does the community name get truncated? 2) What is the OID for an SNMPv1 trap such as linkUp eg as in alarmActiveNotificationID? Does the Alarm MIB agent used the SNMPv2/3 definitions eg .1.3.6.1.6.3.1.1.5.4 ? Tom Petch, Network Consultant nwnetworks@dial.pipex.com From owner-disman@dorothy.bmc.com Tue Apr 16 12:54:17 2002 Received: from babbler.bmc.com (camaro.bmc.com [198.207.223.231]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18794 for ; Tue, 16 Apr 2002 12:54:16 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g3GGukM23298; Tue, 16 Apr 2002 11:56:47 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id JAA27332 for disman-list; Tue, 16 Apr 2002 09:50:38 -0700 (PDT) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id JAA27326 for disman@dorothy.bmc.com; Tue, 16 Apr 2002 09:50:35 -0700 (PDT) Date: Tue, 16 Apr 2002 09:50:35 -0700 (PDT) From: Randy Presuhn Message-Id: <200204161650.JAA27326@dorothy.bmc.com> To: disman@dorothy.bmc.com Subject: IM 2003 CFP 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 - Most CFPs sent to this list are spam, with no clear connection to the WG's activities. This one is different and is highly recommended. > -----From Juergen ---------------------------------------------------- > The official Web site for IM 2003 is . You can > reach the call for papers by following one link. But I guess using the > top-level URL is safer since this is going to be correct for a while. ------------------------------------------------------ Randy Presuhn BMC Software, Inc. 1-3141 randy_presuhn@bmc.com 2141 North First Street Tel: +1 408 546-1006 San José, California 95131 USA ------------------------------------------------------ My opinions and BMC's are independent variables. ------------------------------------------------------ From owner-disman@dorothy.bmc.com Tue Apr 16 16:05:39 2002 Received: from babbler.bmc.com (firebird.bmc.com [198.207.223.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12270 for ; Tue, 16 Apr 2002 16:05:39 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g3GK88r00930; Tue, 16 Apr 2002 15:08:08 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id NAA03936 for disman-list; Tue, 16 Apr 2002 13:02:23 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id NAA03931 for ; Tue, 16 Apr 2002 13:02:19 -0700 (PDT) Received: from mx-us-hou-1-int.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id g3GK0AV19711 for ; Tue, 16 Apr 2002 15:00:10 -0500 (CDT) Received: from riverstonenet.com (unknown [63.113.148.10]) by mx-us-hou-1-int.bmc.com (Postfix) with SMTP id 6C3F720EFBB for ; Tue, 16 Apr 2002 15:03:52 -0500 (CDT) Received: from dperkins-nb2.dsperkins.com by riverstonenet.com (8.9.3+Sun/SMI-SVR4-Yago) id NAA15648; Tue, 16 Apr 2002 13:03:47 -0700 (PDT) Message-Id: <5.0.2.1.2.20020416130037.02caaec0@mail4.bayarea.net> X-Sender: dperkins@mail4.bayarea.net X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Tue, 16 Apr 2002 13:03:29 -0700 To: "Tom Petch" , "disman" From: "David T. Perkins" Subject: Re: Alarm MIB et al; identifying a Trap In-Reply-To: <00bb01c1e541$b76b9300$0301a8c0@tom3> 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, An SNMPv1 community string value and a CONTEXT name are not necessarily identical. That is, you cannot say the mapping is "always" one-to-one. For both the context name and the OID for the notification, you would follow the instructions found in RFC 2576 At 01:23 PM 4/16/2002 +0100, Tom Petch wrote: >Two thoughts on identifying a SNMPv1 Trap in the Alarm MIB >and others. >1) The community name is an OCTET STRING of up to 255 >octets;this gets stored in an SnmpAdmin String eg >alarmActiveContextName which is limited to 32 octets; does >the community name get truncated? >2) What is the OID for an SNMPv1 trap such as linkUp eg as >in alarmActiveNotificationID? Does the Alarm MIB agent used >the SNMPv2/3 definitions eg .1.3.6.1.6.3.1.1.5.4 ? > >Tom Petch, Network Consultant >nwnetworks@dial.pipex.com Regards, /david t. perkins From owner-disman@dorothy.bmc.com Tue Apr 16 19:42:51 2002 Received: from babbler.bmc.com (firebird.bmc.com [198.207.223.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05917 for ; Tue, 16 Apr 2002 19:42:51 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g3GNjPE10079; Tue, 16 Apr 2002 18:45:25 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id QAA04379 for disman-list; Tue, 16 Apr 2002 16:39:35 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id QAA04374 for ; Tue, 16 Apr 2002 16:39:30 -0700 (PDT) Received: from mx-us-hou-1-int.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id g3GNbLx06911 for ; Tue, 16 Apr 2002 18:37:21 -0500 (CDT) Received: from hose.mail.pipex.net (unknown [158.43.128.58]) by mx-us-hou-1-int.bmc.com (Postfix) with SMTP id D5E1420EFAB for ; Tue, 16 Apr 2002 18:41:02 -0500 (CDT) Received: (qmail 14011 invoked from network); 16 Apr 2002 17:10:34 -0000 Received: from userbf86.uk.uudial.com (HELO tom3) (62.188.142.107) by smtp-4.dial.pipex.com with SMTP; 16 Apr 2002 17:10:34 -0000 Message-ID: <022201c1e569$52c8c260$0301a8c0@tom3> Reply-To: "Tom Petch" From: "Tom Petch" To: "Romascanu, Dan (Dan)" , "disman" Subject: Re: Alarm MIB et al; monotonic increasing Date: Tue, 16 Apr 2002 13:56:21 +0100 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 4.72.2106.4 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list Content-Transfer-Encoding: 7bit Yes, I was taught 'strictly increasing' or 'strictly monotonic increasing' or 'increasing in the strict sense' and have used that in the engineering I have done since. I have looked at more modern mathematics books and see no change in the language. Tom Petch, Network Consultant nwnetworks@dial.pipex.com -----Original Message----- From: Romascanu, Dan (Dan) To: Tom Petch ; disman Date: 16 April 2002 12:57 Subject: RE: Alarm MIB et al; monotonic increasing With all due respect to your text book - this is the widely spread way we are defining the 'arbitrary' indices in many IETF MIBs. Actually what do you suggest? would 'strictly monotonic increasing' be OK? Thanks, Dan > -----Original Message----- > From: Tom Petch [mailto:nwnetworks@dial.pipex.com] > Sent: Tuesday, April 16, 2002 11:41 AM > To: disman > Subject: Alarm MIB et al; monotonic increasing > > > I am concerned about the use of monotonic increasing in the > Alarm MIB and others. > > My university text book - E.G. Philips A Course of Analysis > (1960) - defines monotonic increasing as > s1 LTE s2 LTE s3 LTE s4 ... > eg 1 1 3 5 7 7 9 10 .. > which won't do for an INDEX such as > alarmActiveVariableIndex or alarmActiveIndex. > > Any thoughts? > > Tom Petch, Network Consultant > nwnetworks@dial.pipex.com > > > > From owner-disman@dorothy.bmc.com Tue Apr 16 21:01:56 2002 Received: from babbler.bmc.com (firebird.bmc.com [198.207.223.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA14583 for ; Tue, 16 Apr 2002 21:01:55 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g3H14UG21331; Tue, 16 Apr 2002 20:04:31 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id RAA04674 for disman-list; Tue, 16 Apr 2002 17:58:37 -0700 (PDT) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id RAA04668 for disman@dorothy.bmc.com; Tue, 16 Apr 2002 17:58:33 -0700 (PDT) Date: Tue, 16 Apr 2002 17:58:33 -0700 (PDT) From: Randy Presuhn Message-Id: <200204170058.RAA04668@dorothy.bmc.com> To: disman@dorothy.bmc.com Subject: alarmActiveState notification 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 - In draft-ietf-disman-alarm-mib-06.txt, the definition of the alarmActiveState notification includes references to two accessible-for-notify objects, alarmModelIndexVarbind and alarmModelStateVarbind. It seems to me that it would be quite a bit simpler to remove these two from the OBJECTS list, and replace them with alarmActiveModelPointer. Similarly, in the definition of the alarmClearState notification, alarmModelIndexVarbind could also replaced with alarmActiveModelPointer. This would allow us to get rid of two object definitions, and all the varbinds in the OBJECTS clause would come from the same row in the same table, simplifying implementation. While we're on the topic of these two notifications, I think that alarmActiveResourceId is not particularly useful without alarmActiveContextName, alarmActiveEngineAddressType, alarmActiveEngineAddress, and alarmActiveEngineID. ------------------------------------------------------ Randy Presuhn BMC Software, Inc. 1-3141 randy_presuhn@bmc.com 2141 North First Street Tel: +1 408 546-1006 San José, California 95131 USA ------------------------------------------------------ My opinions and BMC's are independent variables. ------------------------------------------------------ From owner-disman@dorothy.bmc.com Wed Apr 17 04:00:35 2002 Received: from babbler.bmc.com (camaro.bmc.com [198.207.223.231]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12198 for ; Wed, 17 Apr 2002 04:00:35 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g3H839C01450; Wed, 17 Apr 2002 03:03:09 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id AAA05425 for disman-list; Wed, 17 Apr 2002 00:57:07 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id AAA05419; Wed, 17 Apr 2002 00:57:03 -0700 (PDT) Received: from mx-us-hou-2-int.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id g3H7ssL27862; Wed, 17 Apr 2002 02:54:54 -0500 (CDT) Received: from hoemail2.firewall.lucent.com (hoemail2.lucent.com [192.11.226.163]) by mx-us-hou-2-int.bmc.com (Postfix) with SMTP id 857C71FF008; Wed, 17 Apr 2002 02:58:36 -0500 (CDT) Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by hoemail2.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g3H7wJV02772; Wed, 17 Apr 2002 03:58:20 -0400 (EDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2653.19) id <2GN7ZR4G>; Wed, 17 Apr 2002 09:58:18 +0200 Message-ID: From: "Wijnen, Bert (Bert)" To: "Romascanu, Dan (Dan)" , Randy Presuhn , disman@dorothy.bmc.com Subject: RE: FW: Probable Cause Date: Wed, 17 Apr 2002 09:58:17 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list I think I did not understand that we were talking about a mapping. If it is a mapping then I think there is no problem. Bert > -----Original Message----- > From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] > Sent: Tuesday, April 16, 2002 12:54 PM > To: Randy Presuhn; disman@dorothy.bmc.com > Subject: RE: FW: Probable Cause > > > > > From: "Sharon Chisholm" > > ... > > > It's actually called IANA-ITU-ALARM-TC, but that > > > probably does not help your concerns much. > > > > > > Study group 4 has seen the textual convention and > > > seem happy with it. I'm not sure if they noticed > > > the 255 limit, but we can verify. > > > > > > It would seem a liaison statement on how we get > > > ITU sign-off on these values would be useful. > > ... > > > > Please, let's NOT get into this mode of operation. > > > > The ITU does not "own" this MIB. It's a product of > > this working group, and part of our job is to consider > > related work, such as that of the ITU, to ensure that we > > can adequately represent the things we need to represent. > > Both the SG4 and the DMTF have been most helpful in providing > > us with information so that we might accomplish our task. > > > > If we believe that we have a requirement to be able to > > preserve "probable cause" semantics from DMTF and ITU > > management information, the minimum requirement for us is > > only to ensure that we define a mapping from their code sets > > to ours that does not lose information. They do not need to > > approve our mappings. > > > > ------------------------------------------------------ > > Randy Presuhn > > > > I agree. > > Dan > > From owner-disman@dorothy.bmc.com Wed Apr 17 04:13:54 2002 Received: from babbler.bmc.com (camaro.bmc.com [198.207.223.231]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12392 for ; Wed, 17 Apr 2002 04:13:53 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g3H8GU503135; Wed, 17 Apr 2002 03:16:30 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id BAA05459 for disman-list; Wed, 17 Apr 2002 01:10:56 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id BAA05454 for ; Wed, 17 Apr 2002 01:10:51 -0700 (PDT) Received: from mx-us-hou-2-int.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id g3H88gu04740 for ; Wed, 17 Apr 2002 03:08:42 -0500 (CDT) Received: from iere.net.avaya.com (iere.net.avaya.com [198.152.12.101]) by mx-us-hou-2-int.bmc.com (Postfix) with SMTP id 069101FF008 for ; Wed, 17 Apr 2002 03:12:25 -0500 (CDT) Received: from iere.net.avaya.com (localhost [127.0.0.1]) by iere.net.avaya.com (8.11.2/8.9.3) with ESMTP id g3H8AWg02475 for ; Wed, 17 Apr 2002 04:10:32 -0400 (EDT) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by iere.net.avaya.com (8.11.2/8.9.3) with ESMTP id g3H8AWR02470 for ; Wed, 17 Apr 2002 04:10:32 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Alarm MIB et al; monotonic increasing Date: Wed, 17 Apr 2002 11:10:15 +0300 Message-ID: Thread-Topic: Alarm MIB et al; monotonic increasing Thread-Index: AcHln+mxR0UwJrDpQx6gHk31yLmZLQAR22Hw From: "Romascanu, Dan (Dan)" To: "Tom Petch" , "disman" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by dorothy.bmc.com id BAA05455 Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list Content-Transfer-Encoding: 8bit Sounds OK. We'll do the change in the next round. Thanks, Dan > -----Original Message----- > From: Tom Petch [mailto:nwnetworks@dial.pipex.com] > Sent: Tuesday, April 16, 2002 3:56 PM > To: Romascanu, Dan (Dan); disman > Subject: Re: Alarm MIB et al; monotonic increasing > > > Yes, I was taught 'strictly increasing' or 'strictly > monotonic increasing' or 'increasing in the strict sense' > and have used that in the engineering I have done since. I > have looked at more modern mathematics books and see no > change in the language. > > Tom Petch, Network Consultant > nwnetworks@dial.pipex.com > > -----Original Message----- > From: Romascanu, Dan (Dan) > To: Tom Petch ; disman > > Date: 16 April 2002 12:57 > Subject: RE: Alarm MIB et al; monotonic increasing > > > With all due respect to your text book - this is the widely > spread way we are defining the 'arbitrary' indices in many > IETF MIBs. > > Actually what do you suggest? would 'strictly monotonic > increasing' be OK? > > Thanks, > > Dan > > > > -----Original Message----- > > From: Tom Petch [mailto:nwnetworks@dial.pipex.com] > > Sent: Tuesday, April 16, 2002 11:41 AM > > To: disman > > Subject: Alarm MIB et al; monotonic increasing > > > > > > I am concerned about the use of monotonic increasing in > the > > Alarm MIB and others. > > > > My university text book - E.G. Philips A Course of > Analysis > > (1960) - defines monotonic increasing as > > s1 LTE s2 LTE s3 LTE s4 ... > > eg 1 1 3 5 7 7 9 10 .. > > which won't do for an INDEX such as > > alarmActiveVariableIndex or alarmActiveIndex. > > > > Any thoughts? > > > > Tom Petch, Network Consultant > > nwnetworks@dial.pipex.com > > > > > > > > > > > From owner-disman@dorothy.bmc.com Wed Apr 17 04:54:38 2002 Received: from babbler.bmc.com (firebird.bmc.com [198.207.223.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12711 for ; Wed, 17 Apr 2002 04:54:38 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g3H8vEZ07827; Wed, 17 Apr 2002 03:57:14 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id BAA05551 for disman-list; Wed, 17 Apr 2002 01:51:38 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id BAA05546 for ; Wed, 17 Apr 2002 01:51:34 -0700 (PDT) Received: from mx-us-hou-2-int.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id g3H8nPQ21177 for ; Wed, 17 Apr 2002 03:49:25 -0500 (CDT) Received: from iere.net.avaya.com (iere.net.avaya.com [198.152.12.101]) by mx-us-hou-2-int.bmc.com (Postfix) with SMTP id 72E541FF00A for ; Wed, 17 Apr 2002 03:53:07 -0500 (CDT) Received: from iere.net.avaya.com (localhost [127.0.0.1]) by iere.net.avaya.com (8.11.2/8.9.3) with ESMTP id g3H8pFg19287 for ; Wed, 17 Apr 2002 04:51:15 -0400 (EDT) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by iere.net.avaya.com (8.11.2/8.9.3) with ESMTP id g3H8pER19272 for ; Wed, 17 Apr 2002 04:51:14 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Alarm MIB WG last call Date: Wed, 17 Apr 2002 11:50:57 +0300 Message-ID: Thread-Topic: Alarm MIB WG last call Thread-Index: AcHlUSDojR3fraY0TzO/nnQZ+RGsmQAmoGBA From: "Romascanu, Dan (Dan)" To: Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by dorothy.bmc.com id BAA05547 Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list Content-Transfer-Encoding: 8bit Tammy, I think that we are back on an already beaten track. I would suggest that we do not get back to these discussions, if we want this work to progress and eventually make it to a standard. 'Your' Alarm MIB requirements exceed the agreed scope of this work. The Alarm MIB does not assume the ARC MIB as mandatory. The T1 and ITU requirements are not mandatory as well, and the telecom applications are just one of the Alarm MIB applications. There are many other, and this is why the Alarm MIB architecture is modular, and allows to accommodate different type of requirements. The core Alarm MIB needs to be kept simple. Regards, Dan > -----Original Message----- > From: Tammy Ferris [mailto:tferris@merkita.com] > Sent: Tuesday, April 16, 2002 5:15 PM > To: Romascanu, Dan (Dan) > Cc: disman@dorothy.bmc.com > Subject: Re: Alarm MIB WG last call > > > Dan, > While the ARC MIB is a separate MIB, it was my understanding > that it should work together with this Alarm MIB in a > compatible fashion and that they both (and possibly other > MIBs as well --- such as a Conditions MIB (or should I say > Error MIB)) fell under the topic of Alarm Management. > > I certainly don't see the Alarm MIB as sufficient to meet my > Alarm Management requirements. However, with the addition of > other MIBs, it should hopefully be close enough (It will > always lack some of the ad hoc capabilities I have in using > other protocols.). > > Some implementations may do polling but that would violate > the T1 and ITU requirements and not be acceptable for > telecommunications applications. So, while some may do > polling, there are definitely some that will not. Further, > polling makes for poor analysis because the receiver of the > alarm information, without a valid time > stamp, cannot correlate the occurrence of the error with any > other activities that were occurring at the time the error occurred. > > Philosophically, I think it would be better to have no time > stamp than an incorrect one with no indication that it is > incorrect. But again, an elimination of the time stamp would > not meet my requirements. > Regards, > Tammy > > Tammy Lehtinen Ferris > tferris@merkita.com > +1 (763)557-1681 > Merkita Incorporated > www.merkita.com > > "Romascanu, Dan (Dan)" wrote: > > > You are correct in the analysis of the behavior. However, I > think that this is how it should work. > > > > Assuming that an alarm suppression mechanism is supported > you seem to make assumptions about how it should work - > timestamps of when the error occurred are somehow kept > internally. This is an implementation assumption. What if in > another implementation, polling an error conditions starts > only after the suppression is released. > > > > Actually Alarm suppression is not part of the scope of the > Alarm MIB. Model Specific Alarm MIBs may add such mechanisms, > and document the behavior. > > > > Regards, > > > > Dan > > > > > -----Original Message----- > > > From: Tammy Ferris [mailto:tferris@merkita.com] > > > Sent: Monday, April 15, 2002 5:14 PM > > > Cc: disman@dorothy.bmc.com > > > Subject: Re: Alarm MIB WG last call > > > > > > > > > All, > > > I ran across a perceived anomaly related to the first item in > > > one of my previous > > > mail that I thought would be relevant to point out. > > > > > > It was explained to me that the table for active alarms is > > > indexed based on time > > > the error occurred, which allows the manager the ability to > > > not have to retrieve > > > the whole table all the time but can just query on the "most > > > recent" alarms. > > > > > > This appears to work fine in the nominal case, however the > > > addition of alarm > > > suppression feature creates an anomaly using that approach. > > > > > > If an error occurs while alarm reporting is suppressed and > > > still exists when > > > alarm reporting is no longer suppressed, the alarm will be > > > reported at the time > > > the suppression is released but the time stamp will indicate > > > the time the error > > > occurred not the time the error is reported (as it should > > > be). Thus, when > > > supporting both the alarm mib and the arc mib, there is the > > > possibility that > > > "new" alarms could show up in the active alarm table with > > > time stamps older > > > (having earlier time stamps) than any other alarm in the > > > active alarm table. > > > > > > One solution to this, though expensive, would be to have 2 > > > timestamps in the > > > active alarm table: one for the time the error occured and > > > the other for the > > > time the alarm notification was sent. > > > > > > Regards, > > > Tammy > > > > > > Tammy Lehtinen Ferris > > > tferris@merkita.com > > > +1 (763)577-5946 > > > Merkita Incorporated > > > www.merkita.com > > > > > > > > > > > > > > > > > > > > Hi - > > > > > > > > > > Private email has made it clear that some folks > didn't read the > > > > > attached message. Make no mistake: disman WG last > call on the > > > > > alarm MIB began March 28 when the draft appeared. The WG last > > > > > call will end 5 p.m. Pacific Daylight Time on April 11, 2002. > > > > > > > > > > ------------------------------------------------------ > > > > > Randy Presuhn BMC Software, Inc. 1-3141 > > > > > randy_presuhn@bmc.com 2141 North First Street > > > > > Tel: +1 408 546-1006 San José, California 95131 USA > > > > > ------------------------------------------------------ > > > > > My opinions and BMC's are independent variables. > > > > > ------------------------------------------------------ > > > > > > > > > > > From owner-disman@dorothy.bmc.com Mon Mar 18 > 13:08:39 PST 2002 > > > > > > Date: Mon, 18 Mar 2002 13:08:17 -0800 (PST) > > > > > > From: Randy Presuhn > > > > > > Message-Id: <200203182108.NAA19616@dorothy.bmc.com> > > > > > > To: disman@dorothy.bmc.com > > > > > > Subject: Alarm MIB WG last call > > > > > > List-Id: IETF disman Working Group mailing list > > > > > > > > > > > > > > > Hi - > > > > > > > > > > > > We finished a first WG last call on the alarm MIB, and, > > > > > > *surprise* found that some revisions were needed. > I've talked > > > > > > to some of the folks active in the discussion, and as disman > > > > > > WG chair have decided that, when the revision > appears, another > > > > > > two-week WG last call on the document would be appropriate. > > > > > > This last call will begin when the revised I-D becomes > > > available. > > > > > > > > > > > > As with the previous last call, I would appreciate > a (personal) > > > > > > note from those who have read the document but not felt the > > > > > > need to comment on the WG mailing list, so that I > might better > > > > > > assess how much review it has actually received. > > > > > > > > > > > > ------------------------------------------------------ > > > > > > Randy Presuhn BMC Software, Inc. 1-3141 > > > > > > randy_presuhn@bmc.com 2141 North First Street > > > > > > Tel: +1 408 546-1006 San José, California 95131 USA > > > > > > ------------------------------------------------------ > > > > > > My opinions and BMC's are independent variables. > > > > > > ------------------------------------------------------ > > > > > > > > > > > > > > > > > > > From owner-disman@dorothy.bmc.com Wed Apr 17 08:01:02 2002 Received: from babbler.bmc.com (firebird.bmc.com [198.207.223.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15150 for ; Wed, 17 Apr 2002 08:01:01 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g3HC3EV03318; Wed, 17 Apr 2002 07:03:14 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id EAA05860 for disman-list; Wed, 17 Apr 2002 04:56:33 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id EAA05855 for ; Wed, 17 Apr 2002 04:56:29 -0700 (PDT) Received: from mx-us-hou-2-int.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id g3HBsK807446 for ; Wed, 17 Apr 2002 06:54:20 -0500 (CDT) Received: from snowstorm.mail.pipex.net (snowstorm.mail.pipex.net [158.43.192.97]) by mx-us-hou-2-int.bmc.com (Postfix) with SMTP id 76A291FF008 for ; Wed, 17 Apr 2002 06:58:02 -0500 (CDT) Received: (qmail 7896 invoked from network); 17 Apr 2002 10:02:16 -0000 Received: from usercb53.uk.uudial.com (HELO tom3) (62.188.150.220) by smtp-6.dial.pipex.com with SMTP; 17 Apr 2002 10:02:16 -0000 Message-ID: <00d801c1e5f6$a8c0aec0$0301a8c0@tom3> Reply-To: "Tom Petch" From: "Tom Petch" To: "disman" , "David T. Perkins" Subject: Re: Alarm MIB et al; identifying a Trap Date: Wed, 17 Apr 2002 10:40:42 +0100 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 4.72.2106.4 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list Content-Transfer-Encoding: 7bit David Thanks for that; I had forgotten the contents of RFC2576. I would suggest that if and when the opportunity arises, a reference to RFC2576 is inserted in the Alarm MIB for the creation of OIDs for SNMP v1 traps. But with the community string, the Alarm MIB talks of placing the community string directly into eg alarmActiveContextName, not of translating it via the RFC2576 SNMP-COMMUNITY-MIB, so I think truncation is possible and again, should be mentioned if and when opportunity arises. Tom Petch, Network Consultant nwnetworks@dial.pipex.com -----Original Message----- From: David T. Perkins To: Tom Petch ; disman Date: 16 April 2002 21:02 Subject: Re: Alarm MIB et al; identifying a Trap >HI, > >An SNMPv1 community string value and a CONTEXT name are not >necessarily identical. That is, you cannot say the mapping >is "always" one-to-one. > >For both the context name and the OID for the notification, >you would follow the instructions found in RFC 2576 > >At 01:23 PM 4/16/2002 +0100, Tom Petch wrote: >>Two thoughts on identifying a SNMPv1 Trap in the Alarm MIB >>and others. >>1) The community name is an OCTET STRING of up to 255 >>octets;this gets stored in an SnmpAdmin String eg >>alarmActiveContextName which is limited to 32 octets; does >>the community name get truncated? >>2) What is the OID for an SNMPv1 trap such as linkUp eg as >>in alarmActiveNotificationID? Does the Alarm MIB agent used >>the SNMPv2/3 definitions eg .1.3.6.1.6.3.1.1.5.4 ? >> >>Tom Petch, Network Consultant >>nwnetworks@dial.pipex.com > >Regards, >/david t. perkins > From owner-disman@dorothy.bmc.com Wed Apr 17 08:11:16 2002 Received: from babbler.bmc.com (camaro.bmc.com [198.207.223.231]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15257 for ; Wed, 17 Apr 2002 08:11:15 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g3HCDoY05141; Wed, 17 Apr 2002 07:13:50 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id FAA05911 for disman-list; Wed, 17 Apr 2002 05:08:17 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id FAA05905; Wed, 17 Apr 2002 05:08:13 -0700 (PDT) Received: from mx-us-hou-1-int.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id g3HC64A12664; Wed, 17 Apr 2002 07:06:04 -0500 (CDT) Received: from zcars04e.ca.nortel.com (unknown [47.129.242.56]) by mx-us-hou-1-int.bmc.com (Postfix) with SMTP id 6A43320EFCC; Wed, 17 Apr 2002 07:09:46 -0500 (CDT) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g3HC9cK04680; Wed, 17 Apr 2002 08:09:38 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 17 Apr 2002 08:09:40 -0400 Message-ID: <3549C09B853DD5119B540002A52CDD3402CC6B15@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: disman@dorothy.bmc.com Cc: Randy Presuhn Subject: RE: alarmActiveState notification Date: Wed, 17 Apr 2002 08:09:41 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list hi In draft-ietf-disman-alarm-mib-06.txt, the definition of the alarmActiveState notification includes references to two accessible-for-notify objects, alarmModelIndexVarbind and alarmModelStateVarbind. It seems to me that it would be quite a bit simpler to remove these two from the OBJECTS list, and replace them with alarmActiveModelPointer. But, the manager is more interested in the model index and the model state. Yes, these can be extracted out of the instance information in alarmActiveModelPointer, but this is added complexity that, based on the number of questions I receive about notifications that do this sort of this, causes a lot of confusion. This would allow us to get rid of two object definitions, and all the varbinds in the OBJECTS clause would come from the same row in the same table, simplifying implementation. ... for the device. Of course, being able to varbind table indices would solve this for both of us. While we're on the topic of these two notifications, I think that alarmActiveResourceId is not particularly useful without alarmActiveContextName, alarmActiveEngineAddressType, alarmActiveEngineAddress, and alarmActiveEngineID. Maybe. I'll add it to the issues list. Sharon From owner-disman@dorothy.bmc.com Wed Apr 17 08:15:02 2002 Received: from babbler.bmc.com (camaro.bmc.com [198.207.223.231]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15335 for ; Wed, 17 Apr 2002 08:15:01 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g3HCHbb05659; Wed, 17 Apr 2002 07:17:37 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id FAA05929 for disman-list; Wed, 17 Apr 2002 05:12:11 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id FAA05924 for ; Wed, 17 Apr 2002 05:12:07 -0700 (PDT) Received: from mx-us-hou-1-int.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id g3HC9v414401 for ; Wed, 17 Apr 2002 07:09:57 -0500 (CDT) Received: from zcars04f.ca.nortel.com (unknown [47.129.242.57]) by mx-us-hou-1-int.bmc.com (Postfix) with SMTP id 24AE020EFCD for ; Wed, 17 Apr 2002 07:13:40 -0500 (CDT) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g3HCDXh21278 for ; Wed, 17 Apr 2002 08:13:33 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 17 Apr 2002 08:13:34 -0400 Message-ID: <3549C09B853DD5119B540002A52CDD3402CC6B1B@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: disman@dorothy.bmc.com Subject: Alarm MIB - Issues 25 - 35 Date: Wed, 17 Apr 2002 08:13:33 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list Alarm #25 Relation to RFC3014 (Closed) There was concern that the Alarm MIB references RFC3014 which could cause problems if the notification log MIB was modified to address some issues. In -06, the replacement of alarmActiveLogIndex with alarmActiveLogPointer eliminates the technical dependency. There are other references, but these were viewed as being appropriate. Alarm #26 Extensibility of alarmActiveEntry "In the overview, it would be nice to add a description regarding the extensibility of the AlarmActiveEntry. I think this is an important feature." Alarm #27 Resource Type "Section 4.1.4, it is not clear to me how it can be know what type of resource the alarm is for. It would be nice to have a description of this." Alarm #28 Typo alarmModeNotifiationId -> alarmModelNotificationId (Closed) Alarm #29 MAX-ACCESS in alarmModelTable should be read-create (Closed) Alarm #30 MAX-ACCESS of alarmActiveSpecificPointer to be read-only (Closed) Alarm #31 Duplicate Probable causes fire (120) & fireDetected (266) flood (121) & floodDetected (267) configurationOrCustomisationError (160) & configurationOrCustomizationError(260) underlayingResourceUnavailable (166) & underlyingResourceUnavailable(287) and possibly toxicGas (133) & toxicLeakDetected (286) Alarm #32 Description of alarmActiveDateAndTime (Closed) Change "when the alarm occurred" to "when the error occurred" Alarm #33 Disman Immortality Text in the IANA considerations section suggests we'll still be around for IETF 34523421, held in the Mars colonies. Alarm #34 Monotonically Increasing -> Strictly Monastically Increasing (Closed) Alarm #35 AlarmState Notification varbinds "While we're on the topic of these two notifications, I think that alarmActiveResourceId is not particularly useful without alarmActiveContextName, alarmActiveEngineAddressType, alarmActiveEngineAddress, and alarmActiveEngineID." Sharon Chisholm Preside Management Nortel Networks Ottawa, Ontario From owner-disman@dorothy.bmc.com Wed Apr 17 08:30:29 2002 Received: from babbler.bmc.com (camaro.bmc.com [198.207.223.231]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15669 for ; Wed, 17 Apr 2002 08:30:24 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g3HCWxG07745; Wed, 17 Apr 2002 07:33:00 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id FAA05970 for disman-list; Wed, 17 Apr 2002 05:27:26 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id FAA05965 for ; Wed, 17 Apr 2002 05:27:22 -0700 (PDT) Received: from mx-us-hou-2-int.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id g3HCPC121904 for ; Wed, 17 Apr 2002 07:25:13 -0500 (CDT) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.48]) by mx-us-hou-2-int.bmc.com (Postfix) with SMTP id E5AC81FF008 for ; Wed, 17 Apr 2002 07:28:54 -0500 (CDT) Received: from mbb5.ericsson.se (mbb5.ericsson.se [136.225.151.210]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g3HCSYs7010037 for ; Wed, 17 Apr 2002 14:28:35 +0200 (MEST) Received: from lm6068 (lm6068.lmera.ericsson.se [150.132.106.68]) by mbb1.ericsson.se (PMDF V5.2-29 #39352) with ESMTP id <0GUP00A7PPBM23@mbb1.ericsson.se> for disman@dorothy.bmc.com; Wed, 17 Apr 2002 14:28:34 +0200 (MET DST) Date: Wed, 17 Apr 2002 14:28:33 +0200 From: David Partain Subject: Re: alarmActiveState notification In-reply-to: <3549C09B853DD5119B540002A52CDD3402CC6B15@zcard0ka.ca.nortel.com> To: disman@dorothy.bmc.com Reply-To: David.Partain@ericsson.com Message-id: <200204171428.33577.David.Partain@ericsson.com> MIME-version: 1.0 X-Mailer: KMail [version 1.4] Content-type: text/plain; charset=iso-8859-1 References: <3549C09B853DD5119B540002A52CDD3402CC6B15@zcard0ka.ca.nortel.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by dorothy.bmc.com id FAA05966 Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list Content-Transfer-Encoding: 8bit Hi all, I _entirely_ support Randy's suggestion. On Wednesday 17 April 2002 14.09, Sharon Chisholm wrote: > hi > > > In draft-ietf-disman-alarm-mib-06.txt, the definition of the > alarmActiveState notification includes references to two > accessible-for-notify objects, alarmModelIndexVarbind and > alarmModelStateVarbind. It seems to me that it would be > quite a bit simpler to remove these two from the OBJECTS > list, and replace them with alarmActiveModelPointer. > > > But, the manager is more interested in the model index > and the model state. Yes, these can be extracted out > of the instance information in alarmActiveModelPointer, And that is the way they are _supposed_ to do it. That's why the SMI rules are what they are. In my opinion, adding in these accessible-for-notify copies of modelstate and modelIndex is an ugly hack to try to get around the rules. > but this is added complexity that, based on the number > of questions I receive about notifications that do > this sort of this, causes a lot of confusion. This is perhaps the third round (maybe more) on this mailing list about this rule in the SMI. I think we need to just accept that the SMI says what it does, not try to hack our way around it, and expect people to write tools that do the right thing. > > > This would allow us to get rid of two object definitions, > and all the varbinds in the OBJECTS clause would come from > the same row in the same table, simplifying implementation. > > > ... for the device. I'm sorry, but I just don't understand why parsing a varbind to get the index information is so hard... And, by the way, if the alarmModelTable is indexed by something other than an empty alarmListName, they'll have to parse something to get that out, or am I missing something? > Of course, being able to varbind table > indices would solve this for both of us. But you cannot. Since we obviously disagree on the validity of the rule (I continue to believe it's a Good Thing that promotes better tools), I suppose that I'll just jump up and down and holler that RFC 2578 forbids what you want to do, so don't do it. :-) Even if the copy-and-make-it-accessible-for-notify hack doesn't violate the letter of the law, it sure violates the spirit. Cheers, David From owner-disman@dorothy.bmc.com Wed Apr 17 08:54:38 2002 Received: from babbler.bmc.com (firebird.bmc.com [198.207.223.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16112 for ; Wed, 17 Apr 2002 08:54:37 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g3HCvDw12916; Wed, 17 Apr 2002 07:57:13 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id FAA06018 for disman-list; Wed, 17 Apr 2002 05:51:45 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id FAA06013 for ; Wed, 17 Apr 2002 05:51:41 -0700 (PDT) Received: from mx-us-hou-1-int.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id g3HCnVc02930 for ; Wed, 17 Apr 2002 07:49:32 -0500 (CDT) Received: from zcars04f.ca.nortel.com (unknown [47.129.242.57]) by mx-us-hou-1-int.bmc.com (Postfix) with SMTP id 6357A20EFD2 for ; Wed, 17 Apr 2002 07:53:14 -0500 (CDT) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g3HCr7h26061; Wed, 17 Apr 2002 08:53:07 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 17 Apr 2002 08:53:08 -0400 Message-ID: <3549C09B853DD5119B540002A52CDD3402CC6BE1@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: disman@dorothy.bmc.com Cc: David.Partain@ericsson.com Subject: RE: alarmActiveState notification Date: Wed, 17 Apr 2002 08:53:08 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list hi I _entirely_ support Randy's suggestion. I knew I could count on you ;-). I think we'll have to agree to disagree on the validity of that particular SMI rule and take it up in SMIng. And, by the way, if the alarmModelTable is indexed by something other than an empty alarmListName, they'll have to parse something to get that out, or am I missing something? Good point. I'll mark this as issue #36. I'm still not convinced the modelPointer is the best solution though. Sharon From owner-disman@dorothy.bmc.com Wed Apr 17 09:09:21 2002 Received: from babbler.bmc.com (camaro.bmc.com [198.207.223.231]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16475 for ; Wed, 17 Apr 2002 09:09:20 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g3HDBrc15295; Wed, 17 Apr 2002 08:11:54 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id GAA06055 for disman-list; Wed, 17 Apr 2002 06:06:13 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id GAA06050 for ; Wed, 17 Apr 2002 06:06:09 -0700 (PDT) Received: from mx-us-hou-1-int.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id g3HD3xB09884 for ; Wed, 17 Apr 2002 08:03:59 -0500 (CDT) Received: from albatross.wise.edt.ericsson.se (unknown [193.180.251.49]) by mx-us-hou-1-int.bmc.com (Postfix) with SMTP id D1AD820EF97 for ; Wed, 17 Apr 2002 08:07:41 -0500 (CDT) Received: from mbb5.ericsson.se (mbb5.ericsson.se [136.225.151.210]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g3HD7W3G006305 for ; Wed, 17 Apr 2002 15:07:32 +0200 (MEST) Received: from lm6068 (lm6068.lmera.ericsson.se [150.132.106.68]) by mbb1.ericsson.se (PMDF V5.2-29 #39352) with ESMTP id <0GUP00JENR4JE0@mbb1.ericsson.se> for disman@dorothy.bmc.com; Wed, 17 Apr 2002 15:07:32 +0200 (MET DST) Date: Wed, 17 Apr 2002 15:07:31 +0200 From: David Partain Subject: Re: alarmActiveState notification In-reply-to: <3549C09B853DD5119B540002A52CDD3402CC6BE1@zcard0ka.ca.nortel.com> To: disman@dorothy.bmc.com Reply-To: David.Partain@ericsson.com Message-id: <200204171507.31607.David.Partain@ericsson.com> MIME-version: 1.0 X-Mailer: KMail [version 1.4] Content-type: text/plain; charset=iso-8859-1 References: <3549C09B853DD5119B540002A52CDD3402CC6BE1@zcard0ka.ca.nortel.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by dorothy.bmc.com id GAA06051 Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list Content-Transfer-Encoding: 8bit Hi Sharon! On Wednesday 17 April 2002 14.53, Sharon Chisholm wrote: > > I _entirely_ support Randy's suggestion. > > > I knew I could count on you ;-). Always happy to fulfill my role :-) > I think we'll > have to agree to disagree on the validity of that > particular SMI rule and take it up in SMIng. I agree completely. If the SMI is changed, I'll be quiet. I promise :-) > > And, by the way, if the alarmModelTable is indexed by something > other than an empty alarmListName, they'll have to parse > something to get that out, or am I missing something? > > Good point. I'll mark this as issue #36. I'm still not convinced > the modelPointer is the best solution though. Does your answer mean that you'll remove the get-around-the-rules hack? Cheers, dlp From owner-disman@dorothy.bmc.com Wed Apr 17 10:36:11 2002 Received: from babbler.bmc.com (camaro.bmc.com [198.207.223.231]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20685 for ; Wed, 17 Apr 2002 10:36:11 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g3HEcYJ00495; Wed, 17 Apr 2002 09:38:35 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id HAA06254 for disman-list; Wed, 17 Apr 2002 07:32:28 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id HAA06249 for ; Wed, 17 Apr 2002 07:32:25 -0700 (PDT) Received: from mx-us-hou-2-int.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id g3HEUCA28362 for ; Wed, 17 Apr 2002 09:30:12 -0500 (CDT) Received: from agitator.ibr.cs.tu-bs.de (agitator.ibr.cs.tu-bs.de [134.169.34.18]) by mx-us-hou-2-int.bmc.com (Postfix) with SMTP id 120C21FF02E for ; Wed, 17 Apr 2002 09:33:54 -0500 (CDT) Received: from haerke.ibr.cs.tu-bs.de (IDENT:root@haerke.ibr.cs.tu-bs.de [134.169.34.84]) by agitator.ibr.cs.tu-bs.de (8.12.1/8.12.1/Debian -2) with ESMTP id g3HEXP06008812; Wed, 17 Apr 2002 16:33:25 +0200 Received: (from schoenw@localhost) by haerke.ibr.cs.tu-bs.de (8.11.6/8.11.6) id g3HEXPY18202; Wed, 17 Apr 2002 16:33:25 +0200 Date: Wed, 17 Apr 2002 16:33:25 +0200 Message-Id: <200204171433.g3HEXPY18202@haerke.ibr.cs.tu-bs.de> X-Authentication-Warning: haerke.ibr.cs.tu-bs.de: schoenw set sender to schoenw@ibr.cs.tu-bs.de using -f From: Juergen Schoenwaelder To: schishol@nortelnetworks.com Cc: disman@dorothy.bmc.com, David.Partain@ericsson.com In-reply-to: <3549C09B853DD5119B540002A52CDD3402CC6BE1@zcard0ka.ca.nortel.com> (schishol@nortelnetworks.com) Subject: Re: alarmActiveState notification References: <3549C09B853DD5119B540002A52CDD3402CC6BE1@zcard0ka.ca.nortel.com> Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list >>>>> Sharon Chisholm writes: Sharon> I knew I could count on you ;-). I think we'll have to agree Sharon> to disagree on the validity of that particular SMI rule and Sharon> take it up in SMIng. But that won't change the SMIv2 rule and since you are writing an SMIv2 MIB, ... BTW, I agree with Randy and David (which probably does not surprise you much. ;-) /js -- Juergen Schoenwaelder From owner-disman@dorothy.bmc.com Wed Apr 17 10:48:03 2002 Received: from babbler.bmc.com (camaro.bmc.com [198.207.223.231]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21230 for ; Wed, 17 Apr 2002 10:48:03 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g3HEoea02939; Wed, 17 Apr 2002 09:50:40 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id HAA06281 for disman-list; Wed, 17 Apr 2002 07:45:07 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id HAA06276 for ; Wed, 17 Apr 2002 07:45:04 -0700 (PDT) Received: from mx-us-hou-2-int.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id g3HEgsr06150 for ; Wed, 17 Apr 2002 09:42:54 -0500 (CDT) Received: from agitator.ibr.cs.tu-bs.de (agitator.ibr.cs.tu-bs.de [134.169.34.18]) by mx-us-hou-2-int.bmc.com (Postfix) with SMTP id 4BD9D1FF013 for ; Wed, 17 Apr 2002 09:46:36 -0500 (CDT) Received: from haerke.ibr.cs.tu-bs.de (IDENT:root@haerke.ibr.cs.tu-bs.de [134.169.34.84]) by agitator.ibr.cs.tu-bs.de (8.12.1/8.12.1/Debian -2) with ESMTP id g3HEkJ06009293; Wed, 17 Apr 2002 16:46:19 +0200 Received: (from schoenw@localhost) by haerke.ibr.cs.tu-bs.de (8.11.6/8.11.6) id g3HEkJf18383; Wed, 17 Apr 2002 16:46:19 +0200 Date: Wed, 17 Apr 2002 16:46:19 +0200 Message-Id: <200204171446.g3HEkJf18383@haerke.ibr.cs.tu-bs.de> X-Authentication-Warning: haerke.ibr.cs.tu-bs.de: schoenw set sender to schoenw@ibr.cs.tu-bs.de using -f From: Juergen Schoenwaelder To: nwnetworks@dial.pipex.com Cc: disman@dorothy.bmc.com In-reply-to: <00bb01c1e541$b76b9300$0301a8c0@tom3> (nwnetworks@dial.pipex.com) Subject: Re: Alarm MIB et al; identifying a Trap References: <00bb01c1e541$b76b9300$0301a8c0@tom3> Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list >>>>> Tom Petch writes: Tom> 2) What is the OID for an SNMPv1 trap such as linkUp eg as in Tom> alarmActiveNotificationID? Does the Alarm MIB agent used the Tom> SNMPv2/3 definitions eg .1.3.6.1.6.3.1.1.5.4 ? Yes. The Alarm MIB uses SMIv2 (a full standard since 1999) which identifies notifications via OIDs. There are appropriate mappings defined in RFC 2576 if you have to use SNMPv1 with SMIv2 MIB modules. /js -- Juergen Schoenwaelder From owner-disman@dorothy.bmc.com Wed Apr 17 11:18:01 2002 Received: from babbler.bmc.com (camaro.bmc.com [198.207.223.231]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22655 for ; Wed, 17 Apr 2002 11:18:01 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g3HFKcS08476; Wed, 17 Apr 2002 10:20:38 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id IAA06383 for disman-list; Wed, 17 Apr 2002 08:15:08 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id IAA06378 for ; Wed, 17 Apr 2002 08:15:04 -0700 (PDT) Received: from mx-us-hou-2-int.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id g3HFCrK23427 for ; Wed, 17 Apr 2002 10:12:53 -0500 (CDT) Received: from albatross.prod.itd.earthlink.net (albatross.mail.pas.earthlink.net [207.217.120.120]) by mx-us-hou-2-int.bmc.com (Postfix) with SMTP id 555A11FF02F for ; Wed, 17 Apr 2002 10:16:35 -0500 (CDT) Received: from 1cust73.tnt1.minneapolis.mn.da.uu.net ([67.250.208.73] helo=merkita.com) by albatross.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16xrAO-0003GH-00; Wed, 17 Apr 2002 08:16:17 -0700 Message-ID: <3CBD912A.8E02A32F@merkita.com> Date: Wed, 17 Apr 2002 10:13:47 -0500 From: Tammy Ferris Reply-To: tferris@merkita.com X-Mailer: Mozilla 4.75 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Romascanu, Dan (Dan)" Cc: disman@dorothy.bmc.com Subject: Re: Alarm MIB WG last call References: Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list Content-Transfer-Encoding: 8bit Dan, Your response here really surprises me! If this Alarm MIB work disregards ITU requirements than why are there so many e-mails discussing support for ITU alarm codes? Just forget about that then and make up your own. I never have pushed to make the ARC MIB mandatory. But, I believe if an application requires both the ARC MIB and the Alarm MIB then the addition of the ARC MIB should not break the Alarm MIB. The way the Alarm MIB is designed currently, addition of the ARC MIB breaks it. I proposed a fix of having 2 timestamps in the active alarm table rather than one : One time stamp (the time the alarm was reported) be the one to use for indexing and a second time stamp (the time the error occured). Maybe there is another way to fix this by using different attributes for indexing? I don't know. I haven't studied that. I think that there is fine line between simplicity and stupidity. While I agree that unecessary bells and whistles should be avoided to allow for a broader application base, this should not be acheived at the expense of MIB integrity. Tammy Tammy Lehtinen Ferris tferris@merkita.com +1 (763)577-5946 Merkita Incorporated www.merkita.com "Romascanu, Dan (Dan)" wrote: > Tammy, > > I think that we are back on an already beaten track. I would suggest that we do not get back to these discussions, if we want this work to progress and eventually make it to a standard. 'Your' Alarm MIB requirements exceed the agreed scope of this work. The Alarm MIB does not assume the ARC MIB as mandatory. The T1 and ITU requirements are not mandatory as well, and the telecom applications are just one of the Alarm MIB applications. There are many other, and this is why the Alarm MIB architecture is modular, and allows to accommodate different type of requirements. The core Alarm MIB needs to be kept simple. > > Regards, > > Dan > > > -----Original Message----- > > From: Tammy Ferris [mailto:tferris@merkita.com] > > Sent: Tuesday, April 16, 2002 5:15 PM > > To: Romascanu, Dan (Dan) > > Cc: disman@dorothy.bmc.com > > Subject: Re: Alarm MIB WG last call > > > > > > Dan, > > While the ARC MIB is a separate MIB, it was my understanding > > that it should work together with this Alarm MIB in a > > compatible fashion and that they both (and possibly other > > MIBs as well --- such as a Conditions MIB (or should I say > > Error MIB)) fell under the topic of Alarm Management. > > > > I certainly don't see the Alarm MIB as sufficient to meet my > > Alarm Management requirements. However, with the addition of > > other MIBs, it should hopefully be close enough (It will > > always lack some of the ad hoc capabilities I have in using > > other protocols.). > > > > Some implementations may do polling but that would violate > > the T1 and ITU requirements and not be acceptable for > > telecommunications applications. So, while some may do > > polling, there are definitely some that will not. Further, > > polling makes for poor analysis because the receiver of the > > alarm information, without a valid time > > stamp, cannot correlate the occurrence of the error with any > > other activities that were occurring at the time the error occurred. > > > > Philosophically, I think it would be better to have no time > > stamp than an incorrect one with no indication that it is > > incorrect. But again, an elimination of the time stamp would > > not meet my requirements. > > Regards, > > Tammy > > > > Tammy Lehtinen Ferris > > tferris@merkita.com > > +1 (763)557-1681 > > Merkita Incorporated > > www.merkita.com > > > > "Romascanu, Dan (Dan)" wrote: > > > > > You are correct in the analysis of the behavior. However, I > > think that this is how it should work. > > > > > > Assuming that an alarm suppression mechanism is supported > > you seem to make assumptions about how it should work - > > timestamps of when the error occurred are somehow kept > > internally. This is an implementation assumption. What if in > > another implementation, polling an error conditions starts > > only after the suppression is released. > > > > > > Actually Alarm suppression is not part of the scope of the > > Alarm MIB. Model Specific Alarm MIBs may add such mechanisms, > > and document the behavior. > > > > > > Regards, > > > > > > Dan > > > > > > > -----Original Message----- > > > > From: Tammy Ferris [mailto:tferris@merkita.com] > > > > Sent: Monday, April 15, 2002 5:14 PM > > > > Cc: disman@dorothy.bmc.com > > > > Subject: Re: Alarm MIB WG last call > > > > > > > > > > > > All, > > > > I ran across a perceived anomaly related to the first item in > > > > one of my previous > > > > mail that I thought would be relevant to point out. > > > > > > > > It was explained to me that the table for active alarms is > > > > indexed based on time > > > > the error occurred, which allows the manager the ability to > > > > not have to retrieve > > > > the whole table all the time but can just query on the "most > > > > recent" alarms. > > > > > > > > This appears to work fine in the nominal case, however the > > > > addition of alarm > > > > suppression feature creates an anomaly using that approach. > > > > > > > > If an error occurs while alarm reporting is suppressed and > > > > still exists when > > > > alarm reporting is no longer suppressed, the alarm will be > > > > reported at the time > > > > the suppression is released but the time stamp will indicate > > > > the time the error > > > > occurred not the time the error is reported (as it should > > > > be). Thus, when > > > > supporting both the alarm mib and the arc mib, there is the > > > > possibility that > > > > "new" alarms could show up in the active alarm table with > > > > time stamps older > > > > (having earlier time stamps) than any other alarm in the > > > > active alarm table. > > > > > > > > One solution to this, though expensive, would be to have 2 > > > > timestamps in the > > > > active alarm table: one for the time the error occured and > > > > the other for the > > > > time the alarm notification was sent. > > > > > > > > Regards, > > > > Tammy > > > > > > > > Tammy Lehtinen Ferris > > > > tferris@merkita.com > > > > +1 (763)577-5946 > > > > Merkita Incorporated > > > > www.merkita.com > > > > > > > > > > > > > > > > > > > > > > > > > Hi - > > > > > > > > > > > > Private email has made it clear that some folks > > didn't read the > > > > > > attached message. Make no mistake: disman WG last > > call on the > > > > > > alarm MIB began March 28 when the draft appeared. The WG last > > > > > > call will end 5 p.m. Pacific Daylight Time on April 11, 2002. > > > > > > > > > > > > ------------------------------------------------------ > > > > > > Randy Presuhn BMC Software, Inc. 1-3141 > > > > > > randy_presuhn@bmc.com 2141 North First Street > > > > > > Tel: +1 408 546-1006 San José, California 95131 USA > > > > > > ------------------------------------------------------ > > > > > > My opinions and BMC's are independent variables. > > > > > > ------------------------------------------------------ > > > > > > > > > > > > > From owner-disman@dorothy.bmc.com Mon Mar 18 > > 13:08:39 PST 2002 > > > > > > > Date: Mon, 18 Mar 2002 13:08:17 -0800 (PST) > > > > > > > From: Randy Presuhn > > > > > > > Message-Id: <200203182108.NAA19616@dorothy.bmc.com> > > > > > > > To: disman@dorothy.bmc.com > > > > > > > Subject: Alarm MIB WG last call > > > > > > > List-Id: IETF disman Working Group mailing list > > > > > > > > > > > > > > > > > > Hi - > > > > > > > > > > > > > > We finished a first WG last call on the alarm MIB, and, > > > > > > > *surprise* found that some revisions were needed. > > I've talked > > > > > > > to some of the folks active in the discussion, and as disman > > > > > > > WG chair have decided that, when the revision > > appears, another > > > > > > > two-week WG last call on the document would be appropriate. > > > > > > > This last call will begin when the revised I-D becomes > > > > available. > > > > > > > > > > > > > > As with the previous last call, I would appreciate > > a (personal) > > > > > > > note from those who have read the document but not felt the > > > > > > > need to comment on the WG mailing list, so that I > > might better > > > > > > > assess how much review it has actually received. > > > > > > > > > > > > > > ------------------------------------------------------ > > > > > > > Randy Presuhn BMC Software, Inc. 1-3141 > > > > > > > randy_presuhn@bmc.com 2141 North First Street > > > > > > > Tel: +1 408 546-1006 San José, California 95131 USA > > > > > > > ------------------------------------------------------ > > > > > > > My opinions and BMC's are independent variables. > > > > > > > ------------------------------------------------------ > > > > > > > > > > > > > > > > > > > > > > > > > From owner-disman@dorothy.bmc.com Wed Apr 17 17:00:06 2002 Received: from babbler.bmc.com (firebird.bmc.com [198.207.223.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07622 for ; Wed, 17 Apr 2002 17:00:01 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g3HL2Yp06439; Wed, 17 Apr 2002 16:02:37 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id NAA09374 for disman-list; Wed, 17 Apr 2002 13:56:11 -0700 (PDT) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id NAA09368; Wed, 17 Apr 2002 13:56:07 -0700 (PDT) Date: Wed, 17 Apr 2002 13:56:07 -0700 (PDT) From: Randy Presuhn Message-Id: <200204172056.NAA09368@dorothy.bmc.com> To: andreaw@cisco.com, disman@dorothy.bmc.com Subject: RE: FW: Probable Cause Cc: jschott@cisco.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 - > content-class: urn:content-classes:message > Subject: RE: FW: Probable Cause > Date: Tue, 16 Apr 2002 14:05:49 +0300 > Message-ID: > From: "Romascanu, Dan (Dan)" > To: "Randy Presuhn" , , > > Cc: ... > I am not sure that I follow you completely. Our concept is that the ITU list is the basic staff and reference model for the list of possible causes. We should add staff from other sources only when we think something is missing in the ITU list. This was the reason - as I understood it - to look into the DMTF stuff. If we're just passing through stuff from other sources, we don't even need to maintain the list. But if we really do care what the enumeration *means*, we've got a problem. What worries me here is the question of what kind of guidance we can provide to those using these values. If our list includes everything from both the DMTF and ITU sources, there are several possible values that might be used to report, for example, a heating problem. > > If somebody invents a better and greater list later, he could go to IANA and have the his new values added to the TC, as well as explanatory commented text to document the mapping of other values from his list in the previously available values. That's fine. My question is how someone implementing the code to generate an alarm would choose a particular value for ProbableCause from the overlapping possibilities. I think it amounts to recommending to implementors that they choose the narrowest semantic which does not exclude the real "probable cause". > IMO the text assigning the responsibility of administrating the list to the disman wg for eternity should be changed. ... Agreed. ------------------------------------------------------ Randy Presuhn BMC Software, Inc. 1-3141 randy_presuhn@bmc.com 2141 North First Street Tel: +1 408 546-1006 San José, California 95131 USA ------------------------------------------------------ My opinions and BMC's are independent variables. ------------------------------------------------------ From owner-disman@dorothy.bmc.com Wed Apr 17 20:19:27 2002 Received: from babbler.bmc.com (camaro.bmc.com [198.207.223.231]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11688 for ; Wed, 17 Apr 2002 20:19:26 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g3I0Lqa13444; Wed, 17 Apr 2002 19:21:55 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id RAA13998 for disman-list; Wed, 17 Apr 2002 17:15:40 -0700 (PDT) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id RAA13992 for disman@dorothy.bmc.com; Wed, 17 Apr 2002 17:15:36 -0700 (PDT) Date: Wed, 17 Apr 2002 17:15:36 -0700 (PDT) From: Randy Presuhn Message-Id: <200204180015.RAA13992@dorothy.bmc.com> To: disman@dorothy.bmc.com Subject: Re: event mib operating on ranges 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 - > Date: Mon, 14 Jan 2002 16:30:03 -0800 (PST) > From: Randy Presuhn > Message-Id: <200201150030.QAA26877@dorothy.bmc.com> > To: disman@dorothy.bmc.com > Subject: event mib operating on ranges ... > In Salt Lake City, Ram reported that a difficulty that > has arisen with the Event MIB is that it doesn't provide a > convenient way to apply thresholding for a range of ports. > He took the action item to provide an example to the WG > mailing list. ... Has anyone been able to reconstruct the problem case that concerned Ram? ------------------------------------------------------ Randy Presuhn BMC Software, Inc. 1-3141 randy_presuhn@bmc.com 2141 North First Street Tel: +1 408 546-1006 San José, California 95131 USA ------------------------------------------------------ My opinions and BMC's are independent variables. ------------------------------------------------------ From owner-disman@dorothy.bmc.com Wed Apr 17 20:20:16 2002 Received: from babbler.bmc.com (firebird.bmc.com [198.207.223.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11701 for ; Wed, 17 Apr 2002 20:20:16 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g3I0MrQ13534; Wed, 17 Apr 2002 19:22:53 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id RAA14018 for disman-list; Wed, 17 Apr 2002 17:17:26 -0700 (PDT) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id RAA14012 for disman@dorothy.bmc.com; Wed, 17 Apr 2002 17:17:22 -0700 (PDT) Date: Wed, 17 Apr 2002 17:17:22 -0700 (PDT) From: Randy Presuhn Message-Id: <200204180017.RAA14012@dorothy.bmc.com> To: disman@dorothy.bmc.com Subject: Re: StorageType in Event & Expression MIBS 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 - > Date: Mon, 14 Jan 2002 16:41:51 -0800 (PST) > From: Randy Presuhn > Message-Id: <200201150041.QAA26989@dorothy.bmc.com> > To: disman@dorothy.bmc.com > Subject: StorageType in Event & Expression MIBS ... > In Salt Lake City it was noted that the Event and Expression > MIBs lack StorageType objects. Based on implementation reports > and the sense of the room in Salt Lake City, Ram volunteered > to make a proposal to add appropriate objects to these MIBs. ... If no proposal surfaces, should I declare this dead due to lack of interest? ------------------------------------------------------ Randy Presuhn BMC Software, Inc. 1-3141 randy_presuhn@bmc.com 2141 North First Street Tel: +1 408 546-1006 San José, California 95131 USA ------------------------------------------------------ My opinions and BMC's are independent variables. ------------------------------------------------------ From owner-disman@dorothy.bmc.com Thu Apr 18 03:05:45 2002 Received: from babbler.bmc.com (firebird.bmc.com [198.207.223.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27520 for ; Thu, 18 Apr 2002 03:05:44 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g3I78FW25232; Thu, 18 Apr 2002 02:08:15 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id AAA15429 for disman-list; Thu, 18 Apr 2002 00:02:10 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id AAA15422 for ; Thu, 18 Apr 2002 00:02:03 -0700 (PDT) Received: from mx-us-hou-1-int.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id g3I6xrQ18849 for ; Thu, 18 Apr 2002 01:59:53 -0500 (CDT) Received: from pimout5-int.prodigy.net (unknown [207.115.63.98]) by mx-us-hou-1-int.bmc.com (Postfix) with SMTP id 42CA120EFD4 for ; Thu, 18 Apr 2002 02:03:36 -0500 (CDT) Received: from dperkins-nb2.dsperkins.com (adsl-64-171-12-48.dsl.sntc01.pacbell.net [64.171.12.48]) by pimout5-int.prodigy.net (8.11.0/8.11.0) with ESMTP id g3I73UL43012 for ; Thu, 18 Apr 2002 03:03:30 -0400 Message-Id: <5.0.2.1.2.20020417225249.02a46640@mail4.bayarea.net> X-Sender: dperkins@mail4.bayarea.net X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Wed, 17 Apr 2002 23:13:56 -0700 To: disman@dorothy.bmc.com From: "David T. Perkins" Subject: More than one notification for a state change 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, What if there are more than one notification type that causes a change to the same state? The alarm model table doesn't seem to support this. How is this done? Regards, /david t. perkins From owner-disman@dorothy.bmc.com Thu Apr 18 03:05:44 2002 Received: from babbler.bmc.com (firebird.bmc.com [198.207.223.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27505 for ; Thu, 18 Apr 2002 03:05:44 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g3I78CD25220; Thu, 18 Apr 2002 02:08:16 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id AAA15428 for disman-list; Thu, 18 Apr 2002 00:02:10 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id AAA15412 for ; Thu, 18 Apr 2002 00:02:01 -0700 (PDT) Received: from mx-us-hou-1-int.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id g3I6xpm18842 for ; Thu, 18 Apr 2002 01:59:51 -0500 (CDT) Received: from pimout5-int.prodigy.net (unknown [207.115.63.98]) by mx-us-hou-1-int.bmc.com (Postfix) with SMTP id 076D920EFCC for ; Thu, 18 Apr 2002 02:03:33 -0500 (CDT) Received: from dperkins-nb2.dsperkins.com (adsl-64-171-12-48.dsl.sntc01.pacbell.net [64.171.12.48]) by pimout5-int.prodigy.net (8.11.0/8.11.0) with ESMTP id g3I73SL184240 for ; Thu, 18 Apr 2002 03:03:28 -0400 Message-Id: <5.0.2.1.2.20020417223723.02a3e760@mail4.bayarea.net> X-Sender: dperkins@mail4.bayarea.net X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Wed, 17 Apr 2002 22:47:32 -0700 To: disman@dorothy.bmc.com From: "David T. Perkins" Subject: Description for object alarmModelVarbindIndex 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, In the 06 draft of the alarm MIB, the text in the DESCRIPTION clause for object alarmModelVarbindIndex needs to be corrected. It confuses the SNMP operations with the SMI. It currently reads... "The index into the varbind listing of the notification indicated by alarmModelNotificationId which helps signal that the given alarm has changed state. If there is no applicable varbind, the value of this object MUST be zero. For SNMPv1 traps, a 1 indicates the first varbind. For NOTIFICATION-TYPE, a 1 indicates the first real varbind after the required varbinds of sysUptime and SNMPTrapOID." And should be changed to... "The index into the varbind listing of the notification indicated by alarmModelNotificationId which helps signal that the given alarm has changed state. If there is no applicable varbind, the value of this object MUST be zero. For v1Traps, a 1 indicates the first varbind. For v2Traps and Informs, a 1 indicates the first varbind after the required varbinds of sysUptime and SNMPTrapOID." Regards, /david t. perkins From owner-disman@dorothy.bmc.com Thu Apr 18 03:55:29 2002 Received: from babbler.bmc.com (firebird.bmc.com [198.207.223.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27509 for ; Thu, 18 Apr 2002 03:05:44 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g3I78GA25234; Thu, 18 Apr 2002 02:08:16 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id AAA15454 for disman-list; Thu, 18 Apr 2002 00:02:23 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id AAA15431 for ; Thu, 18 Apr 2002 00:02:11 -0700 (PDT) Received: from mx-us-hou-2-int.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id g3I701B18926 for ; Thu, 18 Apr 2002 02:00:01 -0500 (CDT) Received: from pimout5-int.prodigy.net (pimout5-ext.prodigy.net [207.115.63.98]) by mx-us-hou-2-int.bmc.com (Postfix) with SMTP id B14091FF020 for ; Thu, 18 Apr 2002 02:03:44 -0500 (CDT) Received: from dperkins-nb2.dsperkins.com (adsl-64-171-12-48.dsl.sntc01.pacbell.net [64.171.12.48]) by pimout5-int.prodigy.net (8.11.0/8.11.0) with ESMTP id g3I73SL181070 for ; Thu, 18 Apr 2002 03:03:29 -0400 Message-Id: <5.0.2.1.2.20020417224838.02a41770@mail4.bayarea.net> X-Sender: dperkins@mail4.bayarea.net X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Wed, 17 Apr 2002 23:21:31 -0700 To: disman@dorothy.bmc.com From: "David T. Perkins" Subject: Use of Alarm MIB without ITU 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 HI, It really doesn't seem like the Alarm MIB is useful without the ITU MIB. Can an example be provided of another specific model so we can determine if all specific models have the common info which should be contained in the generic tables. Regards, /david t. perkins From owner-disman@dorothy.bmc.com Thu Apr 18 03:55:30 2002 Received: from babbler.bmc.com (firebird.bmc.com [198.207.223.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27506 for ; Thu, 18 Apr 2002 03:05:44 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g3I78HX25245; Thu, 18 Apr 2002 02:08:18 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id AAA15456 for disman-list; Thu, 18 Apr 2002 00:02:27 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id AAA15444 for ; Thu, 18 Apr 2002 00:02:14 -0700 (PDT) Received: from mx-us-hou-2-int.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id g3I705Q19010 for ; Thu, 18 Apr 2002 02:00:05 -0500 (CDT) Received: from pimout5-int.prodigy.net (pimout5-ext.prodigy.net [207.115.63.98]) by mx-us-hou-2-int.bmc.com (Postfix) with SMTP id CF9881FF02B for ; Thu, 18 Apr 2002 02:03:47 -0500 (CDT) Received: from dperkins-nb2.dsperkins.com (adsl-64-171-12-48.dsl.sntc01.pacbell.net [64.171.12.48]) by pimout5-int.prodigy.net (8.11.0/8.11.0) with ESMTP id g3I73VL66342 for ; Thu, 18 Apr 2002 03:03:31 -0400 Message-Id: <5.0.2.1.2.20020417233003.02a49e50@mail4.bayarea.net> X-Sender: dperkins@mail4.bayarea.net X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Wed, 17 Apr 2002 23:33:56 -0700 To: disman@dorothy.bmc.com From: "David T. Perkins" Subject: Totals are counters 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, The object alarmActiveStatsTotalActive should be a counter and not a Gauge32. Note that the following objects are correctly specified as counters: ituAlarmActiveStatsIndeterminateTotal ituAlarmActiveStatsCriticalTotal ituAlarmActiveStatsMajorTotal ituAlarmActiveStatsMinorTotal ituAlarmActiveStatsWarningTotal Regards, /david t. perkins From owner-disman@dorothy.bmc.com Thu Apr 18 03:55:30 2002 Received: from babbler.bmc.com (firebird.bmc.com [198.207.223.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27504 for ; Thu, 18 Apr 2002 03:05:44 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g3I78He25236; Thu, 18 Apr 2002 02:08:17 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id AAA15455 for disman-list; Thu, 18 Apr 2002 00:02:25 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id AAA15434 for ; Thu, 18 Apr 2002 00:02:12 -0700 (PDT) Received: from mx-us-hou-2-int.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id g3I702o18980 for ; Thu, 18 Apr 2002 02:00:02 -0500 (CDT) Received: from pimout5-int.prodigy.net (pimout5-ext.prodigy.net [207.115.63.98]) by mx-us-hou-2-int.bmc.com (Postfix) with SMTP id 71DB11FF021 for ; Thu, 18 Apr 2002 02:03:45 -0500 (CDT) Received: from dperkins-nb2.dsperkins.com (adsl-64-171-12-48.dsl.sntc01.pacbell.net [64.171.12.48]) by pimout5-int.prodigy.net (8.11.0/8.11.0) with ESMTP id g3I73TL181072 for ; Thu, 18 Apr 2002 03:03:29 -0400 Message-Id: <5.0.2.1.2.20020417224929.02a43760@mail4.bayarea.net> X-Sender: dperkins@mail4.bayarea.net X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Wed, 17 Apr 2002 23:18:38 -0700 To: disman@dorothy.bmc.com From: "David T. Perkins" Subject: Which named list does all alarm use 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, How is it determined into which named active list an alarm is put? How and why named lists are used is not shown. Also, it seems kind of redundant that the model table is indexed by a list name, since it would seem like there would be the same entries in each named list. Could an example be shown that demonstrated how named model and active lists were used together. Regards, /david t. perkins From owner-disman@dorothy.bmc.com Thu Apr 18 03:55:30 2002 Received: from babbler.bmc.com (firebird.bmc.com [198.207.223.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27508 for ; Thu, 18 Apr 2002 03:05:44 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g3I78BC25218; Thu, 18 Apr 2002 02:08:14 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id AAA15427 for disman-list; Thu, 18 Apr 2002 00:02:09 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id AAA15411 for ; Thu, 18 Apr 2002 00:02:01 -0700 (PDT) Received: from mx-us-hou-1-int.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id g3I6xpS18841 for ; Thu, 18 Apr 2002 01:59:51 -0500 (CDT) Received: from pimout5-int.prodigy.net (unknown [207.115.63.98]) by mx-us-hou-1-int.bmc.com (Postfix) with SMTP id 0718F20EF9C for ; Thu, 18 Apr 2002 02:03:33 -0500 (CDT) Received: from dperkins-nb2.dsperkins.com (adsl-64-171-12-48.dsl.sntc01.pacbell.net [64.171.12.48]) by pimout5-int.prodigy.net (8.11.0/8.11.0) with ESMTP id g3I73RL184238 for ; Thu, 18 Apr 2002 03:03:27 -0400 Message-Id: <5.0.2.1.2.20020417171251.02ff2580@mail4.bayarea.net> X-Sender: dperkins@mail4.bayarea.net X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Wed, 17 Apr 2002 23:28:40 -0700 To: disman@dorothy.bmc.com From: "David T. Perkins" Subject: Pairing instances 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, In the alarm MIB (the 06 draft), how does one specify in the alarm model table (or elsewhere) how to determine the value for object alarmActiveResourceId? Without being able to specify this programically, it doesn't look like having configurable alarms is doable. One needs to have values of alarmActiveResourceId so that clears can be paired with existing active alarms. For example, if one "configured" linkDown notifications to raise alarms and linkUp notifications to clear them, then if a linkDown occurred on interface 1, and then a link down occurred on interface 9, and then a linkUp occurred on interface 9, you would need values of alarmActiveResourceId to know which of the two active alarms to clear. But, there is no way to configure this. Regards, /david t. perkins From owner-disman@dorothy.bmc.com Thu Apr 18 03:55:31 2002 Received: from babbler.bmc.com (firebird.bmc.com [198.207.223.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27507 for ; Thu, 18 Apr 2002 03:05:44 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g3I78IA25250; Thu, 18 Apr 2002 02:08:18 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id AAA15457 for disman-list; Thu, 18 Apr 2002 00:02:31 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id AAA15445 for ; Thu, 18 Apr 2002 00:02:15 -0700 (PDT) Received: from mx-us-hou-2-int.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id g3I705m19012 for ; Thu, 18 Apr 2002 02:00:05 -0500 (CDT) Received: from pimout5-int.prodigy.net (pimout5-ext.prodigy.net [207.115.63.98]) by mx-us-hou-2-int.bmc.com (Postfix) with SMTP id 0B4D81FF016 for ; Thu, 18 Apr 2002 02:03:48 -0500 (CDT) Received: from dperkins-nb2.dsperkins.com (adsl-64-171-12-48.dsl.sntc01.pacbell.net [64.171.12.48]) by pimout5-int.prodigy.net (8.11.0/8.11.0) with ESMTP id g3I73WL104450 for ; Thu, 18 Apr 2002 03:03:32 -0400 Message-Id: <5.0.2.1.2.20020417233601.02a48c30@mail4.bayarea.net> X-Sender: dperkins@mail4.bayarea.net X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Thu, 18 Apr 2002 00:02:39 -0700 To: disman@dorothy.bmc.com From: "David T. Perkins" Subject: Problems with Variables table 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, The "variables" table is given an inappropriate descriptors and incorrectly described. It is really a "varBind" table, since is includes both the name of variables (an OID value that identifies an instance) and the associated value. SNMP terminology is to call such a list a "varBind" list. Also the descriptor for object alarmActiveVariables should be changed to alarmActiveVarBinds. A replacement might look like the following... alarmActiveVarBindTable OBJECT-TYPE SYNTAX SEQUENCE OF AlarmActiveVarBindEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of variable binding that are associated with entries in the active alarm table. The number of entries is equal to the sum of the values for all instances of object alarmActiveVarBinds." ::= { alarmActive 3 } alarmActiveVarBindEntry OBJECT-TYPE SYNTAX AlarmActiveVarBindEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the table of variable bindings for active alarms. Entries appear in this table when there are variable bindings in the varbind list of a notification that caused an entry in the active alarm table." INDEX { alarmListName, alarmActiveIndex, alarmActiveVarBindIndex } ::= { alarmActiveVarBindTable 1 } Also note that it is not clear whether the VarBind table includes the two entries for sysUpTime and snmpTrapOID. (Of course the value for these two are redundant. So I would say not to include them. However, it is not clear if they are or are not included). Finally, it appears to me that it would be useful to associate variables with the cleared table. If so, this table could be used as is with a global cleanup and change of descriptors alarmActiveIndex and alarmClearIndex. Regards, /david t. perkins From owner-disman@dorothy.bmc.com Thu Apr 18 09:12:42 2002 Received: from babbler.bmc.com (camaro.bmc.com [198.207.223.231]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04572 for ; Thu, 18 Apr 2002 09:12:42 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g3IDEs510764; Thu, 18 Apr 2002 08:14:54 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id GAA16167 for disman-list; Thu, 18 Apr 2002 06:08:13 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id GAA16162 for ; Thu, 18 Apr 2002 06:08:09 -0700 (PDT) Received: from mx-us-hou-1-int.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id g3ID5vr29879 for ; Thu, 18 Apr 2002 08:05:57 -0500 (CDT) Received: from ierw.net.avaya.com (unknown [198.152.13.101]) by mx-us-hou-1-int.bmc.com (Postfix) with SMTP id 8819C20EFC4 for ; Thu, 18 Apr 2002 08:09:42 -0500 (CDT) Received: from ierw.net.avaya.com (localhost [127.0.0.1]) by ierw.net.avaya.com (8.9.3+Sun/8.9.3) with ESMTP id JAA25439 for ; Thu, 18 Apr 2002 09:08:00 -0400 (EDT) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by ierw.net.avaya.com (8.9.3+Sun/8.9.3) with ESMTP id JAA25433 for ; Thu, 18 Apr 2002 09:07:59 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Pairing instances Date: Thu, 18 Apr 2002 16:07:41 +0300 Message-ID: Thread-Topic: Pairing instances Thread-Index: AcHmpyuxT6R8zbJ+T9mvUBB6i/q/DAAMcGyw From: "Romascanu, Dan (Dan)" To: "David T. Perkins" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by dorothy.bmc.com id GAA16163 Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list Content-Transfer-Encoding: 8bit David, See 4.1.4 for the definition of alarmActiveResourceId, and example 6.1 for the configuration of alarms based on linkUp/linkDown. The correspondence is built upon matching the indices with the values of index point to by linkUp to the indices pointed to by alarmActiveResourceId. This looks to me pretty obvious. Do you think that there is need for more explanation, or maybe do you think that an alarm may be triggered on interface 1 and cleared on interface 9? (I do not think this is a practical case) Regards, Dan > -----Original Message----- > From: David T. Perkins [mailto:dperkins@dsperkins.com] > Sent: Thursday, April 18, 2002 9:29 AM > To: disman@dorothy.bmc.com > Subject: Pairing instances > > > HI, > > In the alarm MIB (the 06 draft), how does one specify in the > alarm model table (or elsewhere) how to determine the value > for object alarmActiveResourceId? Without being able to > specify this programically, it doesn't look like having > configurable alarms is doable. > > One needs to have values of alarmActiveResourceId so that > clears can be paired with existing active alarms. For example, > if one "configured" linkDown notifications to raise alarms > and linkUp notifications to clear them, then if a linkDown > occurred on interface 1, and then a link down occurred on > interface 9, and then a linkUp occurred on interface 9, > you would need values of alarmActiveResourceId to know > which of the two active alarms to clear. But, there is no > way to configure this. > > Regards, > /david t. perkins > > From owner-disman@dorothy.bmc.com Thu Apr 18 12:53:49 2002 Received: from babbler.bmc.com (camaro.bmc.com [198.207.223.231]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14434 for ; Thu, 18 Apr 2002 12:53:48 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g3IGtwv26943; Thu, 18 Apr 2002 11:55:59 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id JAA16842 for disman-list; Thu, 18 Apr 2002 09:49:48 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id JAA16837 for ; Thu, 18 Apr 2002 09:49:44 -0700 (PDT) Received: from mx-us-hou-1-int.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id g3IGlWx05997 for ; Thu, 18 Apr 2002 11:47:32 -0500 (CDT) Received: from iere.net.avaya.com (unknown [198.152.12.101]) by mx-us-hou-1-int.bmc.com (Postfix) with SMTP id 95C5220EFBD for ; Thu, 18 Apr 2002 11:51:16 -0500 (CDT) Received: from iere.net.avaya.com (localhost [127.0.0.1]) by iere.net.avaya.com (8.11.2/8.9.3) with ESMTP id g3IGnYc24318 for ; Thu, 18 Apr 2002 12:49:34 -0400 (EDT) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by iere.net.avaya.com (8.11.2/8.9.3) with ESMTP id g3IGnXI24300 for ; Thu, 18 Apr 2002 12:49:33 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Problems with Variables table Date: Thu, 18 Apr 2002 19:49:16 +0300 Message-ID: Thread-Topic: Problems with Variables table Thread-Index: AcHmpyw4oheFu1LURD2AVaIO25hxGQAUIJiQ From: "Romascanu, Dan (Dan)" To: "David T. Perkins" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by dorothy.bmc.com id JAA16838 Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list Content-Transfer-Encoding: 8bit > > The "variables" table is given an inappropriate descriptors and > incorrectly described. > It is really a "varBind" table, since is includes both > the name of variables (an OID value that identifies an instance) > and the associated value. SNMP terminology is to call such > a list a "varBind" list. Also the descriptor for object > alarmActiveVariables should be changed to alarmActiveVarBinds. > > > A replacement might look like the following... > > alarmActiveVarBindTable OBJECT-TYPE > SYNTAX SEQUENCE OF AlarmActiveVarBindEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "A table of variable binding that are associated with > entries in the active alarm table. The number of entries is > equal to the sum of the values for all instances of > object alarmActiveVarBinds." > ::= { alarmActive 3 } > > alarmActiveVarBindEntry OBJECT-TYPE > SYNTAX AlarmActiveVarBindEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "An entry in the table of variable bindings for active > alarms. > > Entries appear in this table when there are variable bindings > in the varbind list of a notification that caused an > entry in the active alarm table." > INDEX { alarmListName, alarmActiveIndex, > alarmActiveVarBindIndex } > ::= { alarmActiveVarBindTable 1 } > I would not be oposed to such a change, if I was conviced that this makes the intention more clear. Though 'logically' this is a varBind table, the SMI limitations prevent it to be a real varbind, as only one of the objects between ...Entry 4 to ...Entry 12 in the row has a meaningful signification. I would rather go with an improved DESCRIPTION clasue, adding something like ' This table provides a logical table of varBinds expressed within the limitations of SMIv2'. > Also note that it is not clear whether the VarBind table includes the > two entries for sysUpTime and snmpTrapOID. (Of course the value for > these two are redundant. So I would say not to include them. However, > it is not clear if they are or are not included). > They are not. > Finally, it appears to me that it would be useful to associate > variables with the cleared table. If so, this table could be used > as is with a global cleanup and change of descriptors alarmActiveIndex > and alarmClearIndex. > I am not sure that I understand this. Can you describe more specifically the required change. > Regards, > /david t. perkins > > From owner-disman@dorothy.bmc.com Thu Apr 18 13:01:59 2002 Received: from babbler.bmc.com (firebird.bmc.com [198.207.223.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14719 for ; Thu, 18 Apr 2002 13:01:58 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g3IH4Yc28343; Thu, 18 Apr 2002 12:04:34 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id JAA17054 for disman-list; Thu, 18 Apr 2002 09:59:06 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id JAA17049 for ; Thu, 18 Apr 2002 09:59:02 -0700 (PDT) Received: from mx-us-hou-2-int.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id g3IGuo511111 for ; Thu, 18 Apr 2002 11:56:50 -0500 (CDT) Received: from ierw.net.avaya.com (ierw.net.avaya.com [198.152.13.101]) by mx-us-hou-2-int.bmc.com (Postfix) with SMTP id C5FB21FF022 for ; Thu, 18 Apr 2002 12:00:35 -0500 (CDT) Received: from ierw.net.avaya.com (localhost [127.0.0.1]) by ierw.net.avaya.com (8.9.3+Sun/8.9.3) with ESMTP id MAA04885 for ; Thu, 18 Apr 2002 12:58:43 -0400 (EDT) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by ierw.net.avaya.com (8.9.3+Sun/8.9.3) with ESMTP id MAA04866 for ; Thu, 18 Apr 2002 12:58:42 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Use of Alarm MIB without ITU MIB Date: Thu, 18 Apr 2002 19:58:25 +0300 Message-ID: Thread-Topic: Use of Alarm MIB without ITU MIB Thread-Index: AcHmpyv76u02jKKZSMSobqrnP/IkGwAUhjVw From: "Romascanu, Dan (Dan)" To: "David T. Perkins" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by dorothy.bmc.com id JAA17050 Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list Content-Transfer-Encoding: 8bit There are two other applications of the Alarm MIB that I am aware about, and require model specific Alarm MIBs to be attached: 1. network security and access control. There is practically no superposition or common functionality with the ITU Alarm MIB 2. facilities management - some commonality, still a lot of specifics that need to be dealt with separately Regards, Dan > -----Original Message----- > From: David T. Perkins [mailto:dperkins@dsperkins.com] > Sent: Thursday, April 18, 2002 9:22 AM > To: disman@dorothy.bmc.com > Subject: Use of Alarm MIB without ITU MIB > > > HI, > > It really doesn't seem like the Alarm MIB is useful without the > ITU MIB. Can an example be provided of another specific model > so we can determine if all specific models have the common info > which should be contained in the generic tables. > > Regards, > /david t. perkins > > From owner-disman@dorothy.bmc.com Thu Apr 18 13:23:17 2002 Received: from babbler.bmc.com (firebird.bmc.com [198.207.223.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15642 for ; Thu, 18 Apr 2002 13:23:16 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g3IHQKP04649; Thu, 18 Apr 2002 12:26:20 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id KAA17456 for disman-list; Thu, 18 Apr 2002 10:20:52 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id KAA17451 for ; Thu, 18 Apr 2002 10:20:48 -0700 (PDT) Received: from mx-us-hou-2-int.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id g3IHIaN23852 for ; Thu, 18 Apr 2002 12:18:36 -0500 (CDT) Received: from ierw.net.avaya.com (ierw.net.avaya.com [198.152.13.101]) by mx-us-hou-2-int.bmc.com (Postfix) with SMTP id 29A901FF011 for ; Thu, 18 Apr 2002 12:22:21 -0500 (CDT) Received: from ierw.net.avaya.com (localhost [127.0.0.1]) by ierw.net.avaya.com (8.9.3+Sun/8.9.3) with ESMTP id NAA24522 for ; Thu, 18 Apr 2002 13:20:29 -0400 (EDT) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by ierw.net.avaya.com (8.9.3+Sun/8.9.3) with ESMTP id NAA24498 for ; Thu, 18 Apr 2002 13:20:28 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Alarm MIB WG last call Date: Thu, 18 Apr 2002 20:20:10 +0300 Message-ID: Thread-Topic: Alarm MIB WG last call Thread-Index: AcHmIpI6q39eibROQz6l9/xFVsf2XQA2J0ZA From: "Romascanu, Dan (Dan)" To: Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by dorothy.bmc.com id KAA17452 Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list Content-Transfer-Encoding: 8bit Tammy, See below. > > Your response here really surprises me! If this Alarm MIB > work disregards ITU requirements than why are there so many > e-mails discussing support for ITU alarm codes? Just forget > about that then and make up your own. > The ITU Alarm MIB defines information specific to the Alarm model defined in ITU M.3100, X.733, X.736. This is actually a quote from the draft. It augments the basic Alarm MIB. The problem with the current discussion about probableCause is that we tried to exceed the initial goal and come with a more generic probableCause macro. Still the ITU alarms have priority in this context. > I never have pushed to make the ARC MIB mandatory. But, I > believe if an application requires both the ARC MIB and the > Alarm MIB then the addition of the ARC MIB should not break > the Alarm MIB. The way the Alarm MIB is designed currently, > addition of the ARC MIB breaks it. > I agree that the ARC MIB should not break the Alarm MIB. I fail to see how it does break it. On the other hand we should not impose implementation assumptions on the Alarm MIB because of requirements to fit in the ARC MIB. > I proposed a fix of having 2 timestamps in the active alarm > table rather than one : One time stamp (the time the alarm > was reported) be the one to use for indexing and a second > time stamp (the time the error occured). This is exactly the type of requirement that looks artificial for some implementations. It implies the capability of having both accurate values registered by an Alarm MIB agent. I understand the requirement, but this looks to me beyond the goal of the Alarm MIB. Regards, Dan From owner-disman@dorothy.bmc.com Thu Apr 18 15:19:58 2002 Received: from babbler.bmc.com (camaro.bmc.com [198.207.223.231]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19961 for ; Thu, 18 Apr 2002 15:19:58 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g3IJMTA26723; Thu, 18 Apr 2002 14:22:33 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id MAA17890 for disman-list; Thu, 18 Apr 2002 12:16:36 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id MAA17884; Thu, 18 Apr 2002 12:16:32 -0700 (PDT) Received: from mx-us-hou-1-int.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id g3IJEJQ23841; Thu, 18 Apr 2002 14:14:19 -0500 (CDT) Received: from sj-msg-core-3.cisco.com (unknown [171.70.157.152]) by mx-us-hou-1-int.bmc.com (Postfix) with SMTP id D08A520EFC4; Thu, 18 Apr 2002 14:18:04 -0500 (CDT) Received: from mira-sjcm-2.cisco.com (IDENT:mirapoint@mira-sjcm-2.cisco.com [171.69.24.14]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g3IJHfNo002884; Thu, 18 Apr 2002 12:17:41 -0700 (PDT) Received: from cisco.com (dhcp-128-107-165-172.cisco.com [128.107.165.172]) by mira-sjcm-2.cisco.com (Mirapoint) with ESMTP id ACR68249; Thu, 18 Apr 2002 12:17:57 -0700 (PDT) Message-ID: <3CBF1BE5.1FC550D7@cisco.com> Date: Thu, 18 Apr 2002 12:17:57 -0700 From: Ramanathan Kavasseri X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Randy Presuhn Cc: disman@dorothy.bmc.com Subject: Re: event mib operating on ranges References: <200204180015.RAA13992@dorothy.bmc.com> Content-Type: text/plain; charset=iso-8859-1 X-MIME-Autoconverted: from 8bit to quoted-printable by sj-msg-core-3.cisco.com id g3IJHfNo002884 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by dorothy.bmc.com id MAA17885 Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list Content-Transfer-Encoding: 8bit Randy Presuhn wrote: > > Hi - > > > Date: Mon, 14 Jan 2002 16:30:03 -0800 (PST) > > From: Randy Presuhn > > Message-Id: <200201150030.QAA26877@dorothy.bmc.com> > > To: disman@dorothy.bmc.com > > Subject: event mib operating on ranges > ... > > In Salt Lake City, Ram reported that a difficulty that > > has arisen with the Event MIB is that it doesn't provide a > > convenient way to apply thresholding for a range of ports. > > He took the action item to provide an example to the WG > > mailing list. > ... > > Has anyone been able to reconstruct the problem case that > concerned Ram? Yep - I took the action item and fell flat on my face. :-( The problem I'd mentioned was: 1. The Event MIB does great at wildcarding one ports, or ALL ports. It's hard to apply a template to a subset of all the existing ports on a device. We had to come up with a separate table in a proprietary MIB for this. This MIB had a table of templates, and another template-to-port mapping table. Each template could specify what object to watch for/threshold. Ram > > ------------------------------------------------------ > Randy Presuhn BMC Software, Inc. 1-3141 > randy_presuhn@bmc.com 2141 North First Street > Tel: +1 408 546-1006 San José, California 95131 USA > ------------------------------------------------------ > My opinions and BMC's are independent variables. > ------------------------------------------------------ From owner-disman@dorothy.bmc.com Thu Apr 18 16:43:05 2002 Received: from babbler.bmc.com (camaro.bmc.com [198.207.223.231]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22312 for ; Thu, 18 Apr 2002 16:43:04 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g3IKjgw14761; Thu, 18 Apr 2002 15:45:42 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id NAA18254 for disman-list; Thu, 18 Apr 2002 13:39:54 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id NAA18249 for ; Thu, 18 Apr 2002 13:39:50 -0700 (PDT) Received: from mx-us-hou-1-int.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id g3IKbcN07860 for ; Thu, 18 Apr 2002 15:37:38 -0500 (CDT) Received: from riverstonenet.com (unknown [63.113.148.10]) by mx-us-hou-1-int.bmc.com (Postfix) with SMTP id 2B6A920EFD5 for ; Thu, 18 Apr 2002 15:41:22 -0500 (CDT) Received: from dperkins-nb2.dsperkins.com by riverstonenet.com (8.9.3+Sun/SMI-SVR4-Yago) id NAA04171; Thu, 18 Apr 2002 13:41:00 -0700 (PDT) Message-Id: <5.0.2.1.2.20020418133219.03222ec0@mail4.bayarea.net> X-Sender: dperkins@mail4.bayarea.net X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Thu, 18 Apr 2002 13:36:53 -0700 To: "Romascanu, Dan (Dan)" , From: "David T. Perkins" Subject: RE: Pairing instances In-Reply-To: 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, Yes, its obvious to human readers (and, of course, I gave an example that should be well understood). But, if arbitrary notifications that are well defined for human readers are configured, how is the code that determines the value of alarmActiveResourceId suppose to figure this out? It seems like a little bit of magic for code. Also, in re-reading X.733/ISO-10164-3, it appears that there can be the cases: 1) multiple active alarms on the same instance 2) multiple correlated active alarms in which one clear notification causes all to clear. How is this specified in the model table? At 04:07 PM 4/18/2002 +0300, Romascanu, Dan (Dan) wrote: >David, > >See 4.1.4 for the definition of alarmActiveResourceId, and example 6.1 for the configuration of alarms based on linkUp/linkDown. The correspondence is built upon matching the indices with the values of index point to by linkUp to the indices pointed to by alarmActiveResourceId. This looks to me pretty obvious. Do you think that there is need for more explanation, or maybe do you think that an alarm may be triggered on interface 1 and cleared on interface 9? (I do not think this is a practical case) > >Regards, > >Dan > > >> -----Original Message----- >> From: David T. Perkins [mailto:dperkins@dsperkins.com] >> Sent: Thursday, April 18, 2002 9:29 AM >> To: disman@dorothy.bmc.com >> Subject: Pairing instances >> >> >> HI, >> >> In the alarm MIB (the 06 draft), how does one specify in the >> alarm model table (or elsewhere) how to determine the value >> for object alarmActiveResourceId? Without being able to >> specify this programically, it doesn't look like having >> configurable alarms is doable. >> >> One needs to have values of alarmActiveResourceId so that >> clears can be paired with existing active alarms. For example, >> if one "configured" linkDown notifications to raise alarms >> and linkUp notifications to clear them, then if a linkDown >> occurred on interface 1, and then a link down occurred on >> interface 9, and then a linkUp occurred on interface 9, >> you would need values of alarmActiveResourceId to know >> which of the two active alarms to clear. But, there is no >> way to configure this. >> >> Regards, >> /david t. perkins >> >> Regards, /david t. perkins From owner-disman@dorothy.bmc.com Thu Apr 18 17:54:49 2002 Received: from babbler.bmc.com (firebird.bmc.com [198.207.223.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24022 for ; Thu, 18 Apr 2002 17:54:49 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g3ILvN428410; Thu, 18 Apr 2002 16:57:23 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id OAA22066 for disman-list; Thu, 18 Apr 2002 14:51:23 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id OAA22061 for ; Thu, 18 Apr 2002 14:51:20 -0700 (PDT) Received: from mx-us-hou-1-int.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id g3ILn7M15728 for ; Thu, 18 Apr 2002 16:49:07 -0500 (CDT) Received: from riverstonenet.com (unknown [63.113.148.10]) by mx-us-hou-1-int.bmc.com (Postfix) with SMTP id 67F1C20EF91 for ; Thu, 18 Apr 2002 16:52:52 -0500 (CDT) Received: from dperkins-nb2.dsperkins.com by riverstonenet.com (8.9.3+Sun/SMI-SVR4-Yago) id OAA10406; Thu, 18 Apr 2002 14:52:51 -0700 (PDT) Message-Id: <5.0.2.1.2.20020418143832.0321e1a0@mail4.bayarea.net> X-Sender: dperkins@mail4.bayarea.net X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Thu, 18 Apr 2002 14:52:31 -0700 To: From: "David T. Perkins" Subject: Trend indicator 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, In section 8.1.26 of X.733 on trend indication, it basically says that the trend indication is only used when there is already an active alarm on the object instance. The next to last sentence of the section is "The Trend indication parameter shall not be present is there are no outstanding alarms." Given this, it seems like the values for the ItuTrendIndication TC should have one of following additions... indeterminate - for when you can't determine the trend noneActive - for when you can determine there are currently no outstanding alarms for the instance Also, the above TC and others from the external documents do not have the explanatory text found in those documents. This causes pain to the MIB reader, since they have to search down those documents and translate between SNMP terminology and CMIP terminology. Those readers without the CMIP background may misinterpret the text in the external documents. Regards, /david t. perkins From owner-disman@dorothy.bmc.com Thu Apr 18 19:41:51 2002 Received: from babbler.bmc.com (camaro.bmc.com [198.207.223.231]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25641 for ; Thu, 18 Apr 2002 19:41:51 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g3INiQJ13861; Thu, 18 Apr 2002 18:44:26 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id QAA22491 for disman-list; Thu, 18 Apr 2002 16:38:36 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id QAA22486 for ; Thu, 18 Apr 2002 16:38:29 -0700 (PDT) Received: from mx-us-hou-2-int.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id g3INaHg05438 for ; Thu, 18 Apr 2002 18:36:17 -0500 (CDT) Received: from hawk.mail.pas.earthlink.net (hawk.mail.pas.earthlink.net [207.217.120.22]) by mx-us-hou-2-int.bmc.com (Postfix) with SMTP id 673411FF010 for ; Thu, 18 Apr 2002 18:39:58 -0500 (CDT) Received: from 1cust213.tnt4.minneapolis.mn.da.uu.net ([67.251.180.213] helo=merkita.com) by hawk.mail.pas.earthlink.net with esmtp (Exim 3.33 #2) id 16yLUr-0007S5-00; Thu, 18 Apr 2002 16:39:26 -0700 Message-ID: <3CBF5883.E149F7E8@merkita.com> Date: Thu, 18 Apr 2002 18:36:36 -0500 From: Tammy Ferris Reply-To: tferris@merkita.com X-Mailer: Mozilla 4.75 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Romascanu, Dan (Dan)" , disman@dorothy.bmc.com Subject: Re: Alarm MIB WG last call References: 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 Dan, re your following comments: **** I agree that the ARC MIB should not break the Alarm MIB. I fail to see how it does break it. On the other hand we should not impose implementation assumptions on the Alarm MIB because of requirements to fit in the ARC MIB. > I proposed a fix of having 2 timestamps in the active alarm > table rather than one : One time stamp (the time the alarm > was reported) be the one to use for indexing and a second > time stamp (the time the error occurred). This is exactly the type of requirement that looks artificial for some implementations. It implies the capability of having both accurate values registered by an Alarm MIB agent. I understand the requirement, but this looks to me beyond the goal of the Alarm MIB. ***** I am not imposing a requirement for 2 timestamps. And I don't understand your point "On the other hand we should not impose implementation assumptions on the Alarm MIB because of requirements to fit in the ARC MIB." I see the fundamental problem as follows: The alarm model supported by the Alarm MIB appears to assume a requirement to be able to query for alarms that have been added to the active alarm table subsequent to the last manager query so that the manager does not have to read the whole table to get updated. The Alarm MIB seems to propose to meet this requirement by indexing on the timestamp for the time the error occurred. In analyzing this in combination with ARC, it can be seen that the currently proposed solution does not meet the original requirement as intended. This is because the declaration of the alarm does not always coincide with the occurance of the error. This proposed solution does not work for certain ARCed errors. Even without ARC, I think it is a bit risky to assume that agent implementations don't support other ways of suppressing alarm declarations that could have the same effect. For example, an error with a long integration period. To complicate things further (even if you may consider this outside scope I think it helps illustrate the point), what about systems that support alarm escalation and de-escalation. Using this MIB, such a system may indicate a clear for a minor condition followed but a raise for the same condition but only now with the severity code of major yet the same error timestamp. In this scenario, will a typical management system using this MIB, miss this updated information? I understand that the time the error occurred does help to uniquely identify a specific occurrence of an alarm and I also understand that there might be cases where it is nice to have the table sorted in time of occurrence order, but I am worried that the management application may miss critical alarm information by assuming that it can rely upon looking only at those alarms information with time of occurrence happening after xxx time. I proposed two timestamps as a possible MIB solution to discuss to meet a perceived alarm management requirement not as a requirement unto itself. If you have a better solution to fixing this problem, I am open to that. Maybe requiring that strictly monotonically increasing identifiers have to be unique within a table and dropping the time of error occurrence from the index? I don't understand how my proposal is counter to the goal of the Alarm MIB. .Maybe it would be worth restating the goal of the Alarm MIB. What do you think is the goal of the Alarm MIB? How is what I was proposing counter to that? Regards, Tammy Tammy Lehtinen Ferris tferris@merkita.com +1 (763)557-1681 Merkita Incorporated www.merkita.com "Romascanu, Dan (Dan)" wrote: > Tammy, > See below. > > > > > Your response here really surprises me! If this Alarm MIB > > work disregards ITU requirements than why are there so many > > e-mails discussing support for ITU alarm codes? Just forget > > about that then and make up your own. > > > The ITU Alarm MIB defines information specific to the Alarm model defined in ITU M.3100, X.733, X.736. > > This is actually a quote from the draft. It augments the basic Alarm MIB. The problem with the current discussion about probableCause is that we tried to exceed the initial goal and come with a more generic probableCause macro. Still the ITU alarms have priority in this context. > > > I never have pushed to make the ARC MIB mandatory. But, I > > believe if an application requires both the ARC MIB and the > > Alarm MIB then the addition of the ARC MIB should not break > > the Alarm MIB. The way the Alarm MIB is designed currently, > > addition of the ARC MIB breaks it. > > > I agree that the ARC MIB should not break the Alarm MIB. I fail to see how it does break it. On the other hand we should not impose implementation assumptions on the Alarm MIB because of requirements to fit in the ARC MIB. > > > I proposed a fix of having 2 timestamps in the active alarm > > table rather than one : One time stamp (the time the alarm > > was reported) be the one to use for indexing and a second > > time stamp (the time the error occured). > > This is exactly the type of requirement that looks artificial for some implementations. It implies the capability of having both accurate values registered by an Alarm MIB agent. I understand the requirement, but this looks to me beyond the goal of the Alarm MIB. > > Regards, > > Dan > From owner-disman@dorothy.bmc.com Fri Apr 19 21:11:42 2002 Received: from babbler.bmc.com (firebird.bmc.com [198.207.223.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28843 for ; Fri, 19 Apr 2002 21:11:41 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g3K1E5O16742; Fri, 19 Apr 2002 20:14:05 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id SAA05660 for disman-list; Fri, 19 Apr 2002 18:06:36 -0700 (PDT) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id SAA05654 for disman@dorothy.bmc.com; Fri, 19 Apr 2002 18:06:33 -0700 (PDT) Date: Fri, 19 Apr 2002 18:06:33 -0700 (PDT) From: Randy Presuhn Message-Id: <200204200106.SAA05654@dorothy.bmc.com> To: disman@dorothy.bmc.com Subject: Re: Alarm MIB WG last call 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: <3CBF5883.E149F7E8@merkita.com> > Date: Thu, 18 Apr 2002 18:36:36 -0500 > From: Tammy Ferris > To: "Romascanu, Dan (Dan)" , disman@dorothy.bmc.com > Subject: Re: Alarm MIB WG last call > References: ... > > I proposed a fix of having 2 timestamps in the active alarm > > table rather than one : One time stamp (the time the alarm > > was reported) be the one to use for indexing and a second > > time stamp (the time the error occurred). ... (much discussion / elaboration deleted) I'm thinking about this problem from an implementation perspective, specifically with an AgentX bias. Now I know that we don't want to *require* the use of agentx, but the pervasiveness of subagent technologies requires us to at least give some thought to its implications. If we would like to have both timestamps in the active alarm table, where would the values come from? If we rely on "in-band" information in AgentX, we are left with few reasonable choices: 1) the subagent could supply a sysUpTime.0 varbind reflecting the time the condition occurred, and the Active Alarm MIB implementation could use its local time to populate the "reported" field. 2) the subagent could supply a sysUpTime.0 varbind reflecting the time the condition was reported, and add another variable binding to reflect when the condition occurred. Though I personally prefer (1) (and would like to see appropriate language in the condition mib), both of these alternatives have a really interesting property: the information recording when the condition was detected ends up in the alarmActiveVariableTable, though perhaps not in the most convenient form imaginable. Am I missing something here? ------------------------------------------------------ Randy Presuhn BMC Software, Inc. 1-3141 randy_presuhn@bmc.com 2141 North First Street Tel: +1 408 546-1006 San José, California 95131 USA ------------------------------------------------------ My opinions and BMC's are independent variables. ------------------------------------------------------ From owner-disman@dorothy.bmc.com Fri Apr 19 21:20:41 2002 Received: from babbler.bmc.com (camaro.bmc.com [198.207.223.231]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29532 for ; Fri, 19 Apr 2002 21:20:41 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g3K1NIr17523; Fri, 19 Apr 2002 20:23:18 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id SAA05766 for disman-list; Fri, 19 Apr 2002 18:17:46 -0700 (PDT) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id SAA05757 for disman@dorothy.bmc.com; Fri, 19 Apr 2002 18:17:43 -0700 (PDT) Date: Fri, 19 Apr 2002 18:17:43 -0700 (PDT) From: Randy Presuhn Message-Id: <200204200117.SAA05757@dorothy.bmc.com> To: disman@dorothy.bmc.com Subject: Re: Alarm MIB - Issues 25 - 35 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: <3549C09B853DD5119B540002A52CDD3402CC6B1B@zcard0ka.ca.nortel.com> > From: "Sharon Chisholm" > To: disman@dorothy.bmc.com > Subject: Alarm MIB - Issues 25 - 35 > Date: Wed, 17 Apr 2002 08:13:33 -0400 ... > Alarm #34 Monotonically Increasing -> Strictly Monastically Increasing ... Are we to be fruitful and multiply? :-) ------------------------------------------------------ Randy Presuhn BMC Software, Inc. 1-3141 randy_presuhn@bmc.com 2141 North First Street Tel: +1 408 546-1006 San José, California 95131 USA ------------------------------------------------------ My opinions and BMC's are independent variables. ------------------------------------------------------ From owner-disman@dorothy.bmc.com Sun Apr 21 01:38:07 2002 Received: from babbler.bmc.com (camaro.bmc.com [198.207.223.231]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA13128 for ; Sun, 21 Apr 2002 01:38:06 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g3L5eUZ08775; Sun, 21 Apr 2002 00:40:34 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id WAA08644 for disman-list; Sat, 20 Apr 2002 22:34:00 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id WAA08632; Sat, 20 Apr 2002 22:33:52 -0700 (PDT) Received: from mx-us-hou-1-int.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id g3L5Vdo06329; Sun, 21 Apr 2002 00:31:39 -0500 (CDT) Received: from ierw.net.avaya.com (unknown [198.152.13.101]) by mx-us-hou-1-int.bmc.com (Postfix) with SMTP id 1025020EFDC; Sun, 21 Apr 2002 00:34:33 -0500 (CDT) Received: from ierw.net.avaya.com (localhost [127.0.0.1]) by ierw.net.avaya.com (8.9.3+Sun/8.9.3) with ESMTP id BAA06427; Sun, 21 Apr 2002 01:32:51 -0400 (EDT) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by ierw.net.avaya.com (8.9.3+Sun/8.9.3) with ESMTP id BAA06419; Sun, 21 Apr 2002 01:32:50 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Alarm MIB WG last call Date: Sun, 21 Apr 2002 08:32:29 +0300 Message-ID: Thread-Topic: Alarm MIB WG last call Thread-Index: AcHoCCOid4vU+9WuSg2NqE0WSDbjdwAcd/Dw From: "Romascanu, Dan (Dan)" To: "Randy Presuhn" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by dorothy.bmc.com id WAA08634 Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list Content-Transfer-Encoding: 8bit I also think that 1) is the better way. In the case that you describe it is the subagent that might have a better (or the only) clue about when the condition occurred. On the other hand, reporting time capability seems to be a characteristic of the main agent, similarly as in the case of a monolithic agent that polls some HW registers. Regards, Dan > -----Original Message----- > From: Randy Presuhn [mailto:rpresuhn@dorothy.bmc.com] > Sent: Saturday, April 20, 2002 4:07 AM > To: disman@dorothy.bmc.com > Subject: Re: Alarm MIB WG last call > > > Hi - > > > Message-ID: <3CBF5883.E149F7E8@merkita.com> > > Date: Thu, 18 Apr 2002 18:36:36 -0500 > > From: Tammy Ferris > > To: "Romascanu, Dan (Dan)" , > disman@dorothy.bmc.com > > Subject: Re: Alarm MIB WG last call > > References: > avaya.com> > ... > > > I proposed a fix of having 2 timestamps in the active alarm > > > table rather than one : One time stamp (the time the alarm > > > was reported) be the one to use for indexing and a second > > > time stamp (the time the error occurred). > ... > (much discussion / elaboration deleted) > > I'm thinking about this problem from an implementation > perspective, specifically with an AgentX bias. Now I > know that we don't want to *require* the use of agentx, > but the pervasiveness of subagent technologies requires > us to at least give some thought to its implications. > > If we would like to have both timestamps in the active > alarm table, where would the values come from? If we rely > on "in-band" information in AgentX, we are left with few > reasonable choices: > > 1) the subagent could supply a sysUpTime.0 varbind > reflecting the time the condition occurred, and > the Active Alarm MIB implementation could use its > local time to populate the "reported" field. > > 2) the subagent could supply a sysUpTime.0 varbind > reflecting the time the condition was reported, and > add another variable binding to reflect when the > condition occurred. > > Though I personally prefer (1) (and would like to see > appropriate language in the condition mib), both of these > alternatives have a really interesting property: the > information recording when the condition was detected ends > up in the alarmActiveVariableTable, though perhaps not in > the most convenient form imaginable. > > Am I missing something here? > > ------------------------------------------------------ > Randy Presuhn BMC Software, Inc. 1-3141 > randy_presuhn@bmc.com 2141 North First Street > Tel: +1 408 546-1006 San José, California 95131 USA > ------------------------------------------------------ > My opinions and BMC's are independent variables. > ------------------------------------------------------ > From owner-disman@dorothy.bmc.com Sun Apr 21 02:25:57 2002 Received: from babbler.bmc.com (camaro.bmc.com [198.207.223.231]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA13129 for ; Sun, 21 Apr 2002 01:38:06 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g3L5eUL08774; Sun, 21 Apr 2002 00:40:34 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id WAA08643 for disman-list; Sat, 20 Apr 2002 22:33:58 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id WAA08633 for ; Sat, 20 Apr 2002 22:33:52 -0700 (PDT) Received: from mx-us-hou-1-int.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id g3L5Vd506331 for ; Sun, 21 Apr 2002 00:31:39 -0500 (CDT) Received: from ierw.net.avaya.com (unknown [198.152.13.101]) by mx-us-hou-1-int.bmc.com (Postfix) with SMTP id D91DA20EFDA for ; Sun, 21 Apr 2002 00:34:31 -0500 (CDT) Received: from ierw.net.avaya.com (localhost [127.0.0.1]) by ierw.net.avaya.com (8.9.3+Sun/8.9.3) with ESMTP id BAA06411 for ; Sun, 21 Apr 2002 01:32:49 -0400 (EDT) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by ierw.net.avaya.com (8.9.3+Sun/8.9.3) with ESMTP id BAA06399 for ; Sun, 21 Apr 2002 01:32:48 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Alarm MIB WG last call Date: Sun, 21 Apr 2002 08:32:29 +0300 Message-ID: Thread-Topic: Alarm MIB WG last call Thread-Index: AcHnMg50sveggtEPSpWs1HtoJrvzYwBRs4+Q From: "Romascanu, Dan (Dan)" To: , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by dorothy.bmc.com id WAA08635 Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list Content-Transfer-Encoding: 8bit > Maybe it would be worth restating the goal of > the Alarm MIB. What do you think is the goal of the Alarm > MIB? Oh, no, please. Even an IETF work item must be completed at some point. WG Last Call is not the phase where goals are discussed. This work is at draft -06, and is lasting for two years or so. Goals were discussed for another bunch of time even before this. Let us complete the Last Call, fix what needs to be fixed, and deliver. Believe or not, there might be people there expecting for this work to be completed and waiting to use it. Regards, Dan > From owner-disman@dorothy.bmc.com Sun Apr 21 02:25:57 2002 Received: from babbler.bmc.com (camaro.bmc.com [198.207.223.231]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA13130 for ; Sun, 21 Apr 2002 01:38:06 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g3L5eUq08773; Sun, 21 Apr 2002 00:40:30 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id WAA08629 for disman-list; Sat, 20 Apr 2002 22:33:11 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id WAA08624 for ; Sat, 20 Apr 2002 22:33:07 -0700 (PDT) Received: from mx-us-hou-2-int.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id g3L5UsN06143 for ; Sun, 21 Apr 2002 00:30:54 -0500 (CDT) Received: from ierw.net.avaya.com (ierw.net.avaya.com [198.152.13.101]) by mx-us-hou-2-int.bmc.com (Postfix) with SMTP id 80F051FF019 for ; Sun, 21 Apr 2002 00:34:40 -0500 (CDT) Received: from ierw.net.avaya.com (localhost [127.0.0.1]) by ierw.net.avaya.com (8.9.3+Sun/8.9.3) with ESMTP id BAA06394 for ; Sun, 21 Apr 2002 01:32:48 -0400 (EDT) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by ierw.net.avaya.com (8.9.3+Sun/8.9.3) with ESMTP id BAA06383 for ; Sun, 21 Apr 2002 01:32:47 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Alarm MIB WG last call Date: Sun, 21 Apr 2002 08:32:29 +0300 Message-ID: Thread-Topic: Alarm MIB WG last call Thread-Index: AcHnMg50sveggtEPSpWs1HtoJrvzYwBRS0MQ From: "Romascanu, Dan (Dan)" To: , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by dorothy.bmc.com id WAA08625 Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list Content-Transfer-Encoding: 8bit OK, I think that I got now your issue. Getting back to your proposal: > > > I proposed a fix of having 2 timestamps in the active alarm > > > table rather than one : One time stamp (the time the alarm > > > was reported) be the one to use for indexing and a second > > > time stamp (the time the error occured). Two things need to be clarified here: - instead of saying 'the alarm was reported' we need to say 'the alarm was reported or retrieved', in order to accommodate agent implementations that are based on a polling model rather than asynchronous reports from an other subsystem - need to define the behavior of an agent an agent that cannot retrieve accurately the time the error occurred. I am not sure how to do this. We might need to add another variable that describes whether this capability exists in the system, or invent another TC like DateAndTimeOrZero. Regards, Dan > -----Original Message----- > From: Tammy Ferris [mailto:tferris@merkita.com] > Sent: Friday, April 19, 2002 2:37 AM > To: Romascanu, Dan (Dan); disman@dorothy.bmc.com > Subject: Re: Alarm MIB WG last call > > > Dan, > re your following comments: > **** > I agree that the ARC MIB should not break the Alarm MIB. I > fail to see how it does break it. On the other hand we should > not impose implementation assumptions on the Alarm MIB > because of requirements to fit in the ARC MIB. > > > I proposed a fix of having 2 timestamps in the active alarm > > table rather than one : One time stamp (the time the alarm > > was reported) be the one to use for indexing and a second > > time stamp (the time the error occurred). > > This is exactly the type of requirement that looks artificial > for some implementations. It implies the capability of having > both accurate values registered by an Alarm MIB agent. I > understand the requirement, but this looks to me beyond the > goal of the Alarm MIB. > > ***** > I am not imposing a requirement for 2 timestamps. And I > don't understand your point "On the other hand we should not > impose implementation assumptions on the Alarm MIB because of > requirements to fit in the ARC MIB." > > I see the fundamental problem as follows: > The alarm model supported by the Alarm MIB appears to assume > a requirement to be able to query for alarms that have been > added to the active alarm table subsequent to the last > manager query so that the manager does not have to read the > whole table to get updated. > > The Alarm MIB seems to propose to meet this requirement by > indexing on the timestamp for the time the error occurred. > > In analyzing this in combination with ARC, it can be seen > that the currently proposed solution does not meet the > original requirement as intended. This is because the > declaration of the alarm does not always coincide with the > occurance of the error. > > This proposed solution does not work for certain ARCed > errors. Even without ARC, I think it is a bit risky to > assume that agent implementations don't support other ways of > suppressing alarm declarations that could have the same > effect. For example, an error with a long integration > period. > > To complicate things further (even if you may consider this > outside scope I think it helps illustrate the point), what > about systems that support alarm escalation and > de-escalation. Using this MIB, such a system may indicate a > clear for a minor condition followed but a raise for > the same condition but only now with the severity code of > major yet the same error timestamp. In this scenario, will a > typical management system using this MIB, miss this updated > information? > > I understand that the time the error occurred does help to > uniquely identify a specific occurrence of an alarm and I > also understand that there might be cases where it is nice to > have the table sorted in time of occurrence order, but I am > worried that the management application may > miss critical alarm information by assuming that it can rely > upon looking only at those alarms information with time of > occurrence happening after xxx time. > > I proposed two timestamps as a possible MIB solution to > discuss to meet a perceived alarm management requirement not > as a requirement unto itself. If you have a better solution > to fixing this problem, I am open to that. Maybe requiring > that strictly monotonically increasing > identifiers have to be unique within a table and dropping the > time of error occurrence from the index? > > I don't understand how my proposal is counter to the goal of > the Alarm MIB. .Maybe it would be worth restating the goal of > the Alarm MIB. What do you think is the goal of the Alarm > MIB? How is what I was proposing counter to that? > > Regards, > Tammy > > Tammy Lehtinen Ferris > tferris@merkita.com > +1 (763)557-1681 > Merkita Incorporated > www.merkita.com > > > > > > "Romascanu, Dan (Dan)" wrote: > > > Tammy, > > See below. > > > > > > > > Your response here really surprises me! If this Alarm MIB > > > work disregards ITU requirements than why are there so many > > > e-mails discussing support for ITU alarm codes? Just forget > > > about that then and make up your own. > > > > > The ITU Alarm MIB defines information specific to the Alarm > model defined in ITU M.3100, X.733, X.736. > > > > This is actually a quote from the draft. It augments the > basic Alarm MIB. The problem with the current discussion > about probableCause is that we tried to exceed the initial > goal and come with a more generic probableCause macro. Still > the ITU alarms have priority in this context. > > > > > I never have pushed to make the ARC MIB mandatory. But, I > > > believe if an application requires both the ARC MIB and the > > > Alarm MIB then the addition of the ARC MIB should not break > > > the Alarm MIB. The way the Alarm MIB is designed currently, > > > addition of the ARC MIB breaks it. > > > > > I agree that the ARC MIB should not break the Alarm MIB. I > fail to see how it does break it. On the other hand we should > not impose implementation assumptions on the Alarm MIB > because of requirements to fit in the ARC MIB. > > > > > I proposed a fix of having 2 timestamps in the active alarm > > > table rather than one : One time stamp (the time the alarm > > > was reported) be the one to use for indexing and a second > > > time stamp (the time the error occured). > > > > This is exactly the type of requirement that looks > artificial for some implementations. It implies the > capability of having both accurate values registered by an > Alarm MIB agent. I understand the requirement, but this looks > to me beyond the goal of the Alarm MIB. > > > > Regards, > > > > Dan > > > > From owner-disman@dorothy.bmc.com Mon Apr 22 07:46:01 2002 Received: from babbler.bmc.com (firebird.bmc.com [198.207.223.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22162 for ; Mon, 22 Apr 2002 07:46:01 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g3MBmGH27781; Mon, 22 Apr 2002 06:48:19 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id EAA11574 for disman-list; Mon, 22 Apr 2002 04:41:02 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id EAA11567 for ; Mon, 22 Apr 2002 04:40:59 -0700 (PDT) Received: from mx-us-hou-2-int.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id g3MBcjB14531 for ; Mon, 22 Apr 2002 06:38:45 -0500 (CDT) Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by mx-us-hou-2-int.bmc.com (Postfix) with SMTP id 6E5A31FF045 for ; Mon, 22 Apr 2002 06:42:32 -0500 (CDT) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g3MBgEP17303 for ; Mon, 22 Apr 2002 07:42:14 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 22 Apr 2002 07:42:18 -0400 Message-ID: <3549C09B853DD5119B540002A52CDD3402D9CB05@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: disman@dorothy.bmc.com Subject: RE: Alarm MIB - Issues 25 - 35 Date: Mon, 22 Apr 2002 07:42:23 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list hi Yes. Spell checkers are great for accidentally spicing up an email. Alarm #34 Monotonically Increasing -> Strictly Monotonically Increasing thanks, Sharon -----Original Message----- From: Randy Presuhn [mailto:rpresuhn@dorothy.bmc.com] Sent: Friday, April 19, 2002 9:18 PM To: disman@dorothy.bmc.com Subject: Re: Alarm MIB - Issues 25 - 35 Hi - > Message-ID: <3549C09B853DD5119B540002A52CDD3402CC6B1B@zcard0ka.ca.nortel.com> > From: "Sharon Chisholm" > To: disman@dorothy.bmc.com > Subject: Alarm MIB - Issues 25 - 35 > Date: Wed, 17 Apr 2002 08:13:33 -0400 ... > Alarm #34 Monotonically Increasing -> Strictly Monastically Increasing ... Are we to be fruitful and multiply? :-) ------------------------------------------------------ Randy Presuhn BMC Software, Inc. 1-3141 randy_presuhn@bmc.com 2141 North First Street Tel: +1 408 546-1006 San José, California 95131 USA ------------------------------------------------------ My opinions and BMC's are independent variables. ------------------------------------------------------ From owner-disman@dorothy.bmc.com Mon Apr 22 13:39:03 2002 Received: from babbler.bmc.com (firebird.bmc.com [198.207.223.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04334 for ; Mon, 22 Apr 2002 13:39:03 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g3MHfvS27554; Mon, 22 Apr 2002 12:41:57 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id KAA13402 for disman-list; Mon, 22 Apr 2002 10:36:00 -0700 (PDT) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id KAA13393; Mon, 22 Apr 2002 10:35:51 -0700 (PDT) Date: Mon, 22 Apr 2002 10:35:51 -0700 (PDT) From: Randy Presuhn Message-Id: <200204221735.KAA13393@dorothy.bmc.com> To: bwijnen@lucent.com, djsidor@nortelnetworks.com Subject: Re: FW: Probable Cause Cc: disman@dorothy.bmc.com, dlmatthews@att.com, grim@tri.sbc.com, randy@psg.com, statements@ietf.org 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 Dave - > Message-ID: <3CC435D3.EF73C43C@americasm01.nt.com> > Date: Mon, 22 Apr 2002 12:09:55 -0400 > From: "Dave Sidor" > To: "Wijnen, Bert (Bert)" > Cc: Randy Presuhn , disman@dorothy.bmc.com, > Randy Bush , "*Matthews, Dave" , > "*Grim, Tom" , > "*IETF, communication statements" > Subject: Re: FW: Probable Cause > References: ... > In Bert's email below he raised an issue that SG 4 addressed at its > meeting that concluded on Friday. The SG 4 input is presented below > Bert's email and also attached as a Word document. I have also copied > this email to the IETF email address for communication statements from > other organizations. ... On behalf of the IETF disman working group, I'd like to thank you for the helpful input from SG 4. We'll take these comments into account as we produce our next revision to the draft. Of course, comments from the individual SG 4 participants are always welcome on our mailing list. Again, thank you (and SG 4) for taking the time to review our work. ------------------------------------------------------ Randy Presuhn BMC Software, Inc. 1-3141 randy_presuhn@bmc.com 2141 North First Street Tel: +1 408 546-1006 San José, California 95131 USA ------------------------------------------------------ My opinions and BMC's are independent variables. ------------------------------------------------------ From owner-disman@dorothy.bmc.com Mon Apr 22 13:39:10 2002 Received: from babbler.bmc.com (firebird.bmc.com [198.207.223.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04349 for ; Mon, 22 Apr 2002 13:39:09 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g3MHg0Z27563; Mon, 22 Apr 2002 12:42:00 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id KAA13420 for disman-list; Mon, 22 Apr 2002 10:36:27 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id JAA13157; Mon, 22 Apr 2002 09:02:48 -0700 (PDT) Received: from mx-us-hou-1-int.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id g3MG0Y229175; Mon, 22 Apr 2002 11:00:34 -0500 (CDT) Received: from zrtps0kn.us.nortel.com (unknown [47.140.192.55]) by mx-us-hou-1-int.bmc.com (Postfix) with SMTP id 614D020EFB6; Mon, 22 Apr 2002 11:04:20 -0500 (CDT) Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps0kn.us.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g3MG48429285; Mon, 22 Apr 2002 12:04:08 -0400 (EDT) Received: from zrtpd0j9.us.nortel.com ([47.140.203.27]) by zrtpd0jn.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JG5JTHC9; Mon, 22 Apr 2002 12:04:10 -0400 Received: from americasm01.nt.com (djsidor-2.us.nortel.com [47.142.213.225]) by zrtpd0j9.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id HCGKH2BB; Mon, 22 Apr 2002 12:04:10 -0400 Message-ID: <3CC435D3.EF73C43C@americasm01.nt.com> Date: Mon, 22 Apr 2002 12:09:55 -0400 X-Sybari-Trust: e9e4fece 0400a004 04016100 From: "Dave Sidor" Organization: Nortel Networks X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Wijnen, Bert (Bert)" Cc: Randy Presuhn , disman@dorothy.bmc.com, Randy Bush , "*Matthews, Dave" , "*Grim, Tom" , "*IETF, communication statements" Subject: Re: FW: Probable Cause References: Content-Type: multipart/mixed; boundary="------------D161BA2097B5F480451BB9CD" Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list This is a multi-part message in MIME format. --------------D161BA2097B5F480451BB9CD Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bert, Randy, Randy, In Bert's email below he raised an issue that SG 4 addressed at its meeting that concluded on Friday. The SG 4 input is presented below Bert's email and also attached as a Word document. I have also copied this email to the IETF email address for communication statements from other organizations. Dave Sidor Chairman, ITU-T SG 4 ----------------- "Wijnen, Bert (Bert)" wrote: > > Is this just me that sort of wrries when I see > > > Some more duplication cases in ITU-IANA-ALARM-TC: > > > > To me it is either a set of ITU controled TCs, or a set > of IANA controled TCs. How is this going to work out > if both organisations need to stay in sync on this? > > Has anybody checked with ITU that they are happy to be > restricted to 255 code points? Can we get that in a > statement from them (possibly from SG 4?)? > > Do we have arranged for ITU to check and sign-off on the > values we currently have in this document? > > Maybe I am just worrying too much... I am pretty busy with > other stuff, so I have not followed all the emails/postings > all that closely. > > Bert ------------------------------- ITU - Telecommunication Standardization Sector Temporary Document 86 (Rev.1) (PLEN) STUDY GROUP 4 Geneva, 8 - 19 April 2002 QUESTIONS: 19/4 SOURCE: ITU-T Study Group 4 TITLE: Additional input regarding the use of M.3100 probable causes for the ITU Alarm MIB _____________ COMMUNICATION STATEMENT TO: IETF disman WG APPROVAL: Agreed to at STUDY GROUP 4 MEETING FOR: ACTIOND EADLINE: January 1, 2003 CONTACT : Dave Matthews Acting Rapporteur, Question 19/4 AT&T USA Tel : +1 732 420 1613 Email: dlmatthews@att.com At the ITU-T Study Group 4 meeting in April 2002, we have examined version 6 of the IETF Alarm MIB focusing of course on those aspects related to the ITU-T SG 4 Recommendations and offer the following comments: - We have examined version 6 of the Alarm MIB (draft-ietf-disman-alarm-mib-06) and noted your incorporation of the M.3100 probable causes semantics. We thank you for that action in response to our July 2001 communication statement. - If you recall, in our July 2001 communication statement, we suggested the need for some extensibility mechanism and also we have been made aware that probable cause semantics other than that from the ITU-T are being reviewed, presumably for possible inclusion. We have discussed the possible impact of the latter and have come to the following conclusions: 1) While we value the identical number assignments for the M.3100 probable causes, regardless of the number assignments, we believe the ITU-T semantics are the most important aspect to retain. 2) Though M.3100 is currently using less than 256 probable causes, there is a likelihood that additional values will be needed. (The M.3100 syntax of ASN.1 INTEGER is, of course, able to support larger values.) 3) We have noted in section 5.2 that you have specified an IANAItuProbableCause textual convention apparently dedicated to the ITU-T probable causes and support that separation from any other probable cause asssignments. To ensure that separation, we recommend that the first paragraph of section 5.2 be replaced with the following text: "Values of IANAItuProbableCause can only be given out if they correspond to ITU probable causes semantics present in ITU-T Recommendations and are agreed to by the disman working group." We believe this text reflects the fact that this textual convention is limited to representing the ITU semantics while at the same time identifying the IETF as the owner of the alarm MIB. Other textual conventions would be presumably required to define the semantics and number assignments of other probable causes. 4) To assist the reader of the current specification, we recommend the replacement of the DESCRIPTION text with the following text: " ITU probable cause values for alarms are currently assigned as per M.3100-1995 (1-254), X.733-1992 (256-287), and X.736-1992 (288-303)." 5) We also note that code 158 (reinitialized) is missing. We would be grateful if you would keep us informed of your progress on this topic. --------------D161BA2097B5F480451BB9CD Content-Type: application/msword; name="T01-SG04-020408-TD-PLEN-0086!R1!MSW-E.doc" Content-Disposition: inline; filename="T01-SG04-020408-TD-PLEN-0086!R1!MSW-E.doc" Content-Transfer-Encoding: base64 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAAUgAAAAAA AAAAEAAAVAAAAAEAAAD+////AAAAAFEAAAD///////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// ///////////////////////////////////spcEATSAJBAAA8BK/AAAAAAAAEAAAAAAABAAA 4xAAAA4AYmpiauI94j0AAAAAAAAAAAAAAAAAAAAAAAAJBBYAOB4AAIBXAACAVwAAwQsAAAAA AAAhAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAD//w8AAAAAAAAAAAD//w8AAAAAAAAAAAD//w8A AAAAAAAAAAAAAAAAAAAAAGwAAAAAAN4TAAAAAAAA3hMAAN4TAAAAAAAA3hMAAAAAAADeEwAA AAAAAN4TAAAAAAAA3hMAABQAAAAAAAAAAAAAAPITAAAAAAAAkhcAAAAAAACSFwAAAAAAAJIX AAA4AAAAyhcAAAwAAADWFwAAHAAAAPITAAAAAAAA51wAAGYBAAD+FwAAAAAAAP4XAABeAAAA XBgAAAAAAABcGAAAAAAAAFwYAAAAAAAAXBgAAAAAAABcGAAAAAAAAFwYAAAAAAAAoVMAAAIA AACjUwAAAAAAAKNTAAAAAAAAo1MAAEEAAADkUwAAVAQAADhYAABUBAAAjFwAAAAAAABNXgAA IAIAAG1gAACEAQAAjFwAABUAAAAAAAAAAAAAAAAAAAAAAAAA3hMAAAAAAABcGAAAAAAAAAAA AAAAAAAAAAAAAAAAAABcGAAAAAAAAFwYAAAAAAAAXBgAAAAAAABcGAAAAAAAAIxcAAAAAAAA QhoAAAAAAADeEwAAAAAAAN4TAAAAAAAAXBgAAAAAAAAAAAAAAAAAAFwYAAAAAAAAoVwAABYA AABCGgAAAAAAAEIaAAAAAAAAQhoAAAAAAABcGAAA6AAAAN4TAAAAAAAAXBgAAAAAAADeEwAA AAAAAFwYAAAAAAAAoVMAAAAAAAAAAAAAAAAAAEIaAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAXBgAAAAAAAChUwAAAAAAAEIaAADeBQAA QhoAAAAAAAAgIAAAhgIAABFRAADQAQAA3hMAAAAAAADeEwAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAASVMAABwAAABcGAAA AAAAAPIXAAAMAAAAQLbwTxbqwQHyEwAAoAMAAJIXAAAAAAAARBkAAKwAAADhUgAANAAAAAAA AAAAAAAAZVMAADwAAAC3XAAAMAAAAOdcAAAAAAAAFVMAADQAAADxYQAAAAAAAPAZAABSAAAA 8WEAAAAAAABlUwAAAAAAAEIaAAAAAAAA8hMAAAAAAADyEwAAAAAAAN4TAAAAAAAA3hMAAAAA AADeEwAAAAAAAN4TAAAAAAAAAgDZAAAASVRVIC0gVGVsZWNvbW11bmljYXRpb24gU3RhbmRh cmRpemF0aW9uIFNlY3RvcglUZW1wb3JhcnkgRG9jdW1lbnQgODYgKFJldi4xKSAoUExFTikN U1RVRFkgR1JPVVAgNA0NR2VuZXZhLCA4IJYgMTkgQXByaWwgMjAwMg0NUVVFU1RJT05TOgkx OS80DVNPVVJDRToJSVRVLVQgU3R1ZHkgR3JvdXAgNA1USVRMRToJQWRkaXRpb25hbCBpbnB1 dCByZWdhcmRpbmcgdGhlIHVzZSBvZiAgTS4zMTAwIHByb2JhYmxlIGNhdXNlcyBmb3IgdGhl IElUVSBBbGFybSBNSUINX19fX19fX19fX19fXw1DT01NVU5JQ0FUSU9OIFNUQVRFTUVOVA1U TzoJSUVURiBkaXNtYW4gV0cNQVBQUk9WQUw6CUFncmVlZCB0byBhdCBTVFVEWSBHcm91cCA0 IG1lZXRpbmcgDUZPUjoJQUNUSU9ODURFQURMSU5FOglKYW51YXJ5IDEsICAyMDAzDQ1DT05U QUNUoDoJRGF2ZSBNYXR0aGV3cw1BY3RpbmcgUmFwcG9ydGV1ciwgUXVlc3Rpb24gMTkvNCAJ VGVsoDoJKzEgNzMyIDQyMCAxNjEzDUFUJlQJRmF4Og1VU0EJRW1haWw6IGRsbWF0dGhld3NA YXR0LmNvbQ0HBw0NDUF0IHRoZSBJVFUtVCBTdHVkeSBHcm91cCA0IG1lZXRpbmcgaW4gQXBy aWwgMjAwMiwgd2UgaGF2ZSBleGFtaW5lZCB2ZXJzaW9uIDYgb2YgdGhlIElFVEYgQWxhcm0g TUlCIGZvY3VzaW5nIG9mIGNvdXJzZSBvbiB0aG9zZSBhc3BlY3RzIHJlbGF0ZWQgdG8gdGhl IElUVS1UIFNHIDQgUmVjb21tZW5kYXRpb25zIGFuZCBvZmZlciB0aGUgZm9sbG93aW5nIGNv bW1lbnRzOg0tIFdlIGhhdmUgZXhhbWluZWQgdmVyc2lvbiA2IG9mIHRoZSBBbGFybSBNSUIg KGRyYWZ0LWlldGYtZGlzbWFuLWFsYXJtLW1pYi0wNikgYW5kIG5vdGVkIHlvdXIgaW5jb3Jw b3JhdGlvbiBvZiB0aGUgTS4zMTAwIHByb2JhYmxlIGNhdXNlcyBzZW1hbnRpY3MuIFdlIHRo YW5rIHlvdSBmb3IgdGhhdCBhY3Rpb24gaW4gcmVzcG9uc2UgdG8gb3VyIEp1bHkgMjAwMSBj b21tdW5pY2F0aW9uIHN0YXRlbWVudC4NLSBJZiB5b3UgcmVjYWxsLCBpbiBvdXIgSnVseSAy MDAxIGNvbW11bmljYXRpb24gc3RhdGVtZW50LCB3ZSBzdWdnZXN0ZWQgdGhlIG5lZWQgZm9y IHNvbWUgZXh0ZW5zaWJpbGl0eSBtZWNoYW5pc20gYW5kIGFsc28gd2UgaGF2ZSBiZWVuIG1h ZGUgYXdhcmUgdGhhdCBwcm9iYWJsZSBjYXVzZSBzZW1hbnRpY3Mgb3RoZXIgdGhhbiB0aGF0 IGZyb20gdGhlIElUVS1UIGFyZSBiZWluZyByZXZpZXdlZCwgcHJlc3VtYWJseSBmb3IgcG9z c2libGUgaW5jbHVzaW9uLiBXZSBoYXZlIGRpc2N1c3NlZCB0aGUgcG9zc2libGUgaW1wYWN0 IG9mIHRoZSBsYXR0ZXIgYW5kIGhhdmUgY29tZSB0byB0aGUgZm9sbG93aW5nIGNvbmNsdXNp b25zOg0xKSBXaGlsZSB3ZSB2YWx1ZSB0aGUgaWRlbnRpY2FsIG51bWJlciBhc3NpZ25tZW50 cyBmb3IgdGhlIE0uMzEwMCBwcm9iYWJsZSBjYXVzZXMsIHJlZ2FyZGxlc3Mgb2YgdGhlIG51 bWJlciBhc3NpZ25tZW50cywgd2UgYmVsaWV2ZSB0aGUgSVRVLVQgc2VtYW50aWNzIGFyZSB0 aGUgbW9zdCBpbXBvcnRhbnQgYXNwZWN0IHRvIHJldGFpbi4NMikgVGhvdWdoIE0uMzEwMCBp cyBjdXJyZW50bHkgdXNpbmcgbGVzcyB0aGFuIDI1NiBwcm9iYWJsZSBjYXVzZXMsIHRoZXJl IGlzIGEgbGlrZWxpaG9vZCB0aGF0IGFkZGl0aW9uYWwgdmFsdWVzIHdpbGwgYmUgbmVlZGVk LiAgKFRoZSBNLjMxMDAgc3ludGF4IG9mIEFTTi4xIElOVEVHRVIgaXMsIG9mIGNvdXJzZSwg YWJsZSB0byBzdXBwb3J0IGxhcmdlciB2YWx1ZXMuKQ0zKSBXZSBoYXZlIG5vdGVkIGluIHNl Y3Rpb24gNS4yIHRoYXQgeW91IGhhdmUgc3BlY2lmaWVkIGFuIElBTkFJdHVQcm9iYWJsZUNh dXNlIHRleHR1YWwgY29udmVudGlvbiBhcHBhcmVudGx5IGRlZGljYXRlZCB0byB0aGUgSVRV LVQgcHJvYmFibGUgY2F1c2VzIGFuZCBzdXBwb3J0IHRoYXQgc2VwYXJhdGlvbiBmcm9tIGFu eSBvdGhlciBwcm9iYWJsZSBjYXVzZSBhc3NzaWdubWVudHMuIFRvIGVuc3VyZSB0aGF0IHNl cGFyYXRpb24sIHdlIHJlY29tbWVuZCB0aGF0IHRoZSBmaXJzdCBwYXJhZ3JhcGggb2Ygc2Vj dGlvbiA1LjIgYmUgcmVwbGFjZWQgd2l0aCB0aGUgZm9sbG93aW5nIHRleHQ6DZNWYWx1ZXMg b2YgSUFOQUl0dVByb2JhYmxlQ2F1c2UgY2FuIG9ubHkgYmUgZ2l2ZW4gb3V0IGlmIHRoZXkg Y29ycmVzcG9uZCB0byBJVFUgcHJvYmFibGUgY2F1c2VzIHNlbWFudGljcyBwcmVzZW50IGlu IElUVS1UIFJlY29tbWVuZGF0aW9ucyBhbmQgYXJlIGFncmVlZCB0byBieSB0aGUgZGlzbWFu IHdvcmtpbmcgZ3JvdXAulA1XZSBiZWxpZXZlIHRoaXMgdGV4dCByZWZsZWN0cyB0aGUgZmFj dCB0aGF0IHRoaXMgdGV4dHVhbCBjb252ZW50aW9uIGlzIGxpbWl0ZWQgdG8gcmVwcmVzZW50 aW5nIHRoZSBJVFUgc2VtYW50aWNzIHdoaWxlIGF0IHRoZSBzYW1lIHRpbWUgaWRlbnRpZnlp bmcgdGhlIElFVEYgYXMgdGhlIG93bmVyIG9mIHRoZSBhbGFybSBNSUIuIE90aGVyIHRleHR1 YWwgY29udmVudGlvbnMgd291bGQgYmUgcHJlc3VtYWJseSByZXF1aXJlZCB0byBkZWZpbmUg dGhlIHNlbWFudGljcyBhbmQgbnVtYmVyIGFzc2lnbm1lbnRzIG9mIG90aGVyIHByb2JhYmxl IGNhdXNlcy4gDTQpIFRvIGFzc2lzdCB0aGUgcmVhZGVyIG9mIHRoZSBjdXJyZW50IHNwZWNp ZmljYXRpb24sIHdlIHJlY29tbWVuZCB0aGUgcmVwbGFjZW1lbnQgb2YgdGhlIERFU0NSSVBU SU9OIHRleHQgd2l0aCB0aGUgZm9sbG93aW5nIHRleHQ6IJMgSVRVIHByb2JhYmxlIGNhdXNl IHZhbHVlcyBmb3IgYWxhcm1zIGFyZSBjdXJyZW50bHkgYXNzaWduZWQgYXMgcGVyIE0uMzEw MC0xOTk1ICgxLTI1NCksIFguNzMzLTE5OTIgKDI1Ni0yODcpLCBhbmQgWC43MzYtMTk5MiAo Mjg4LTMwMykulCANNSkgV2UgYWxzbyBub3RlIHRoYXQgY29kZSAxNTggKHJlaW5pdGlhbGl6 ZWQpIGlzIG1pc3NpbmcuDVdlIHdvdWxkIGJlIGdyYXRlZnVsIGlmIHlvdSB3b3VsZCBrZWVw IHVzIGluZm9ybWVkIG9mIHlvdXIgcHJvZ3Jlc3Mgb24gdGhpcyB0b3BpYy4NX19fX19fX19f X19fX19fX18NLSATIFBBR0UgFDIVIC0NDRMgRklMRU5BTUUgXHAgXCogTUVSR0VGT1JNQVQg FEQ6XFByb2ZpbGVzXERKU2lkb3JcRGVza3RvcFxUMDEtU0cwNC0wMjA0MDgtVEQtUExFTi0w MDg2IVIxIU1TVy1FLmRvYxUJEyBzYXZlZGF0ZSBcQCBkZC5NTS55eSAUMTkuMDQuMDIVDQ0T IEZJTEVOQU1FIFxwIFwqIE1FUkdFRk9STUFUIBREOlxQcm9maWxlc1xESlNpZG9yXERlc2t0 b3BcVDAxLVNHMDQtMDIwNDA4LVRELVBMRU4tMDA4NiFSMSFNU1ctRS5kb2MVCRMgc2F2ZWRh dGUgXEAgZGQuTU0ueXkgFDE5LjA0LjAyFQ0NDQ0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAEAAAuBAAALwQAADAEAAA5BAAAOgQAAEIEAABTBAAAVAQAAGAE AABhBAAAEwUAACoFAAA9BQAAPgUAAFUFAABrBQAA7QUAAO4FAAARBgAAww8AAMQPAADKDwAA yw8AAMwPAADNDwAAzw8AANEPAADSDwAA7g8AAO8PAAA0EAAANRAAADYQAAA3EAAATRAAAE4Q AABWEAAAVxAAAFkQAABaEAAAdhAAAHcQAAC8EAAAvRAAAL4QAAC/EAAA1RAAANYQAADeEAAA 3xAAAOMQAAD9APn9+f35/QD5AP0A9QDzAPHsAOXi5drl4gDVANXP1QDVANXP1QDVANXP1QDV ANXP1QAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAtt SAAEbkgABHUIAQkDagAAAABVCAEPMEoTAG1IAARuSAAEdQgBBDBKEwAADQNqAAAAADBKEwBV CAEIbUgMBHNIDAQAA0gqAgM7CIEGNQiBNgiBAAc1CIFDSiAAAzUIgQAzAAQAAFQEAABiBAAA YwQAAH0EAAB+BAAAjgQAAKoEAAAFBQAAEwUAACsFAAA+BQAAbAUAAHgFAACTBQAAlAUAAKwF AAD4AAAAAAAAAAAAAAAA8QAAAAAAAAAAAAAAAN8AAAAAAAAAAAAAAADYAAAAAAAAAAAAAAAA 0wAAAAAAAAAAAAAAAL8AAAAAAAAAAAAAAAC/AAAAAAAAAAAAAAAAvwAAAAAAAAAAAAAAAK4A AAAAAAAAAAAAAACuAAAAAAAAAAAAAAAAvwAAAAAAAAAAAAAAAJwAAAAAAAAAAAAAAAC/AAAA AAAAAAAAAAAAvwAAAAAAAAAAAAAAAJwAAAAAAAAAAAAAAACOAAAAAAAAAAAAAAAAAAAAAAAA AAAOEQANxg0BBxoDGwZgGLMbAAAAFiQBSWYBAAAAEgAADcYFAAEXBgAPhBcGEYTp+RYkAUlm AQAAAF6EFwZghOn5EQAAAyQBD4QDABGE/f8WJAFJZgEAAABehAMAYIT9/2EkARQAAA3GCQIa A6cEARcGAA+EFwYRhOn5FiQBSWYBAAAAXoQXBmCE6fkFEQANxgQBBxoABxEADcYEAQcaABOk yAAAEREADcYEAQcaAA6E0xkmZAYBAAFQxggAAAD/BgEBAF2E0xkHEQANxgQBBxoAE6TjAAAG EQANxgcBBxoBpyXCABAABAAAwQ8AAOIQAAD+/gAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgEBAqwFAADkBQAA7gUAAAwG AAANBgAADgYAAA8GAAAQBgAAEQYAAOQGAADMBwAAMwkAAPQJAADICgAAGgwAANUMAAASDgAA Ig8AAOkAAAAAAAAAAAAAAADXAAAAAAAAAAAAAAAA1wAAAAAAAAAAAAAAAMcAAAAAAAAAAAAA AACVAAAAAAAAAAAAAAAAkwAAAAAAAAAAAAAAAJMAAAAAAAAAAAAAAACTAAAAAAAAAAAAAAAA kwAAAAAAAAAAAAAAAJMAAAAAAAAAAAAAAACTAAAAAAAAAAAAAAAAkwAAAAAAAAAAAAAAAJMA AAAAAAAAAAAAAACTAAAAAAAAAAAAAAAAkwAAAAAAAAAAAAAAAJMAAAAAAAAAAAAAAACTAAAA AAAAAAAAAAAAAAABAAAAMQAAFiQBFyQBSWYBAAAAAFQBAAKWbAAI1hoAAZT/EyYABn8mAAAA AAAAAAAAAAAAAAAAABT2AQAAGtYEAAAA/xvWBAAAAP8c1gQAAAD/HdYEAAAA/zTWBgABCgNs AGH2AwAAEAAADcYJAhoDpwQBYBhAD4QbBhYkAUlmAQAAAF6EGwYSAAANxgkCGgOnBAFgGEAP hBsGE6QAABYkAUlmAQAAAF6EGwYAFQAADcYQBBoDpwQ0BsEHAmAYsxtAQA+EGwYTpAAAFiQB SWYBAAAAXoQbBgARIg8AAFwPAACvDwAAwQ8AANAPAADRDwAAWBAAAFkQAADgEAAA4RAAAOIQ AADjEAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA9gAAAAAAAAAA AAAAAP0AAAAAAAAAAAAAAADwAAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAO4AAAAAAAAAAAAA AAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAARAAAAUQAA3GBQABjCQCAAEPAAAEAAADJAFhJAEAAQAAAAs2AAowARQwKgdQDwAIUA8A JlAJAB+whS4gsMJBIbB0BCKwdAQjkIQFJJCEBSWwAAAXsDECGLAxAgAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAABQAYAAKAAEAaQAPAAMAAwAAAAMAAABSAABA8f8CAFIADAAGAE4AbwByAG0A YQBsAAAAFwAAAA3GDgAEGgOnBDQGwQfAwMDAE6R4AAAcAENKGABPSgAAUUoAAF9IAQRtSAkI c0gJCHRICQRMAAEAAQACAEwADAAJAEgAZQBhAGQAaQBuAGcAIAAxAAAAHwABAAUkAQYkAQ+E GgMRhOb8E6TgAUAmAF6EGgNghOb8AAcANQiBQ0ocAAAyAAIAEQACADIADAAJAEgAZQBhAGQA aQBuAGcAIAAyAAAACQACABOkQAFAJgEABABDShgAMgADABEAAgAyAAwACQBIAGUAYQBkAGkA bgBnACAAMwAAAAkAAwATpMgAQCYCAAQAQ0oYAEAABAAxAAIAQAAMAAkASABlAGEAZABpAG4A ZwAgADQAAAAcAAQADcYEARoDAA+E4QMRhB/8QCYDXoThA2CEH/wAACoABQBBAAIAKgAMAAkA SABlAGEAZABpAG4AZwAgADUAAAAFAAUAQCYEAAAAKgAGAEEAAgAqAAwACQBIAGUAYQBkAGkA bgBnACAANgAAAAUABgBAJgUAAAAqAAcAQQACACoADAAJAEgAZQBhAGQAaQBuAGcAIAA3AAAA BQAHAEAmBgAAACoACABBAAIAKgAMAAkASABlAGEAZABpAG4AZwAgADgAAAAFAAgAQCYHAAAA KgAJAEEAAgAqAAwACQBIAGUAYQBkAGkAbgBnACAAOQAAAAUACQBAJggAAAA8AEFA8v+hADwA DAAWAEQAZQBmAGEAdQBsAHQAIABQAGEAcgBhAGcAcgBhAHAAaAAgAEYAbwBuAHQAAAAAAAAA AAAAAAAAPAAfQAEA8gA8AAwABgBIAGUAYQBkAGUAcgAAABkADwADJAENxgoEGgOnBDQGwQcA E6QAAGEkAQAEAENKFgBAACBAAQACAUAADAAGAEYAbwBvAHQAZQByAAAAGQAQAA3GEAQaA6cE NAbBBwJCF6clAAITpAAAAAcAOwiBQ0oSAAAwAP5PAQASATAADAAEAEgAZQBhAGQAAAAWABEA DcYNBBoDpwQ0BsEHAQcawBOkAAAAAEYA/g8BACIBRgAMAAcASQBuAGYAbwBkAG8AYwAAACYA EgANxg0EGgOnBDQGwQcBigXAD4SKBRGEdvoTpAAAXoSKBWCEdvoAACYAKUCiADEBJgAMAAsA UABhAGcAZQAgAE4AdQBtAGIAZQByAAAAAABWAP4PAQDiBVYADAAKAEEAUwBOAC4AMQAgAGkA dABhAGwAAAAdABQAAyQDDcYOAAQaA6cENAbBBwAAAAATpAAAYSQDABIANgiBQ0oUAG1ICQRz SAkEdQgAQAD+DwEAcgFAAAwACABBAG4AbgBlAHgAXwBOAG8AAAAWABUAAyQBBSQBBiQBE6Tg ARSkUABhJAEHADsIgUNKHAAANgD+DwEA0gM2AAwACQBBAG4AbgBlAHgAXwBSAGUAZgAAABIA FgADJAEFJAEGJAEUpBgBYSQBAABGAP4PAQBiAUYADAALAEEAbgBuAGUAeABfAFQAaQB0AGwA ZQAAABYAFwADJAEFJAEGJAETpPAAFKQYAWEkAQcANQiBQ0ocAAAqAP4PUQGiASoADAALAEEA cABwAGUAbgBkAGkAeABfAE4AbwAAAAIAGAAAACwA/g9hAdIDLAAMAAwAQQBwAHAAZQBuAGQA aQB4AF8AUgBlAGYAAAACABkAAAAwAP4PcQGSATAADAAOAEEAcABwAGUAbgBkAGkAeABfAFQA aQB0AGwAZQAAAAIAGgAAADwA/g8BANIDPAAMAAsAQQByAHQAXwBIAGUAYQBkAGkAbgBnAAAA DAAbAAMkAROk4AFhJAEHADUIgUNKHAAAMgD+DwEAAgAyAAwABgBBAHIAdABfAE4AbwAAAAwA HAADJAETpOABYSQBBwA7CIFDShwAADgA/g8BANIDOAAMAAkAQQByAHQAXwBUAGkAdABsAGUA AAAMAB0AAyQBE6TwAGEkAQcANQiBQ0ocAABgAP4PAQDiAWAABAAFAEEAUwBOAC4AMQAAADEA HgANxigEGgOnBDQGwQcKNwJuBKUG3AgTC0oNgQ+4Ee8TJhbAwMDAwMDAwMDAE6QAAAASADUI gUNKFABtSAAEbkgABHUIATIA/g8BAAIAMgAMAAQAYwBhAGwAbAAAABQAHwAFJAEGJAEPhBoD E6SgAF6EGgMDADYIgQAmAP4PwQECACYADAAHAEMAaABhAHAAXwBOAG8AAAACACAAAwA1CIEA KAD+D9EB0gMoAAwACgBDAGgAYQBwAF8AVABpAHQAbABlAAAAAgAhAAAAOAD+DwEAIgI4AAwA CABlAG4AdQBtAGwAZQB2ADEAAAAWACIAD4QaAxGE5vwTpFAAXoQaA2CE5vwAADQA/g8hAjIC NAAMAAgAZQBuAHUAbQBsAGUAdgAyAAAAEgAjAA+EpwQRhHP+XoSnBGCEc/4AACwA/g8xAkIC LAAMAAgAZQBuAHUAbQBsAGUAdgAzAAAACgAkAA+ENAZehDQGAAA2AP4PAQBSAjYADAAIAEUA cQB1AGEAdABpAG8AbgAAABMAJQANxg4DpwQ0BsEHAgwTGCbBwgAAADYAHAABAGICNgAMAA0A TgBvAHIAbQBhAGwAIABJAG4AZABlAG4AdAAAAAoAJgAPhBoDXoQaAwAAWgD+DwEAcgJaAAwA DwBFAHEAdQBhAHQAaQBvAG4AXwBMAGUAZwBlAG4AZAAAACkAJwANxhAEGgOnBDQGwQcC+wWl BsLAD4SlBhGEW/kTpFAAXoSlBmCEW/kAAAAwAP4PAQCyAjAADAAGAEYAaQBnAHUAcgBlAAAA EgAoAAMkAQUkAQYkARSkeABhJAEAAE4A/g8BAJICTgAMAA0ARgBpAGcAdQByAGUAXwBMAGUA ZwBlAG4AZAAAAB0AKQAFJAEGJAENxgoEGgOnBDQGwQcAE6QUABSkFAAABABDShIATgD+DwEA EgVOAAwACwBUAGEAYgBsAGUAXwBUAGkAdABsAGUAAAAhACoAAyQBBSQBBiQBDcYIAAKEC/IP wMATpOABFKR4AGEkAQADADUIgQA4AP4PoQLSAzgADAAMAEYAaQBnAHUAcgBlAF8AVABpAHQA bABlAAAADQArAAYkABOk8AAUpOABAAAARAD+D4EC0gNEAAwAFABGAGkAZwB1AHIAZQBfAHcA aQB0AGgAbwB1AHQAXwB0AGkAdABsAGUAAAAJACwABiQAFKTwAAAAADwAJkCiANECPAAMABIA RgBvAG8AdABuAG8AdABlACAAUgBlAGYAZQByAGUAbgBjAGUAAAAIAENKEgBFSAYASgAdAAEA 4gJKAAwADQBGAG8AbwB0AG4AbwB0AGUAIABUAGUAeAB0AAAAHQAuAAUkAQ3GBQABAAHAD4QA ARGEAP9ehAABYIQA/wAAAD4A/g8xAAIAPgAMAAkAaABlAGEAZABpAG4AZwBfAGIAAAAZAC8A D4QAABGEAAATpKAAQCYJXoQAAGCEAAAAAABEAP4PMQACAEQADAAJAGgAZQBhAGQAaQBuAGcA XwBpAAAAGQAwAA+EAAARhAAAE6SgAEAmCV6EAABghAAAAAYANQiBNgiBIgAKAAEAAgAiAA0A BwBJAG4AZABlAHgAIAAxAAAAAgAxAAAAKgALAAEAAgAqAA0ABwBJAG4AZABlAHgAIAAyAAAA CgAyAA+EHAFehBwBAAAqAAwAAQACACoADQAHAEkAbgBkAGUAeAAgADMAAAAKADMAD4Q3Al6E NwIAADwADQABAAIAPAANAAcASQBuAGQAZQB4ACAANAAAABsANAANxg4ABBoDpwQ0BsEHAAAA AA+EUwNehFMDAAAAKgAOAAEAAgAqAA0ABwBJAG4AZABlAHgAIAA1AAAACgA1AA+EbARehGwE AAAqAA8AAQACACoADQAHAEkAbgBkAGUAeAAgADYAAAAKADYAD4SHBV6EhwUAACoAEAABAAIA KgANAAcASQBuAGQAZQB4ACAANwAAAAoANwAPhKIGXoSiBgAALgAhAAEAEgMuAAwADQBJAG4A ZABlAHgAIABIAGUAYQBkAGkAbgBnAAAAAgA4AAAAPgD+DwEAkgM+AAwACABLAGUAeQB3AG8A cgBkAHMAAAAbADkADcYGAqcENAYAD4QaAxGE5vxehBoDYITm/AAAACYAKECiAKEDJgAMAAsA TABpAG4AZQAgAE4AdQBtAGIAZQByAAAAAABAAC8AAQCyA0AADAAEAEwAaQBzAHQAAAAlADsA DcYQBBoDpwQ0BsEHAqUGTwjAwA+ETwgRhLH3XoRPCGCEsfcAAAAuAP4PEQESAS4ADAAHAG0A ZQBlAHQAaQBuAGcAAAAOADwADcYFAAHLHAAUpDACAAA8AP4PAQACADwADAASAE4AbwByAG0A YQBsACAAYQBmAHQAZQByACAAdABpAHQAbABlAAAABgA9ABOkQAEAADYA/g8BAOIDNgAMAAQA TgBvAHQAZQAAABcAPgANxg4ABBoDpwQ0BsEHQEBAQBOkUAAABABDShYASAD+DwEA8gNIAAwA BABQAGEAcgB0AAAAKQA/AA3GEAQaA6cENAbBBwL8BKUGwMAPhKUGEYRb+ROkyABehKUGYIRb +QADADsIgQAiAP4PUQECACIADAAHAFAAYQByAHQAXwBOAG8AAAACAEAAAAAkAP4PYQHSAyQA DAAIAFAAYQByAHQAXwBSAGUAZgAAAAIAQQAAACgA/g9xARIEKAAMAAoAUABhAHIAdABfAFQA aQB0AGwAZQAAAAIAQgAAAEYA/g8BADIERgAMAAUAUQBsAGkAcwB0AAAAJQBDAA3GEAQaA6cE NAbBBwIzB9wIwMAPhNwIEYQk916E3AhghCT3AAMANQiBADgA/g8BAFIEOAAMAAYAUgBlAGMA XwBOAG8AAAASAEQAAyQBBSQBBiQBE6TgAWEkAQcAOwiBQ0ocAAAwAP4PQQRiBDAADAAJAFIA ZQBjAF8AVABpAHQAbABlAAAABgBFABOk8AAGADUIgTsIgToA/g9RBAIAOgAMAAcAUgBlAGMA XwBSAGUAZgAAABMARgANxgoEGgOnBDQGwQcAE6R4AAAGADUIgTsIgSoA/g9hBNIDKgAMAAgA UgBlAGMAXwBEAGEAdABlAAAACABHAAMkAmEkAgAANAD+DwEAggQ0AAwACABSAGUAZgBfAFQA ZQB4AHQAAAASAEgAD4QaAxGE5vxehBoDYITm/AAANAD+DwEAggQ0AAwACQBSAGUAZgBfAFQA aQB0AGwAZQAAAAwASQADJAETpOABYSQBAwA7CIEALAD+D3EE0gMsAAwACABSAGUAcwBfAEQA YQB0AGUAAAACAEoABwA7CIFDShgAACAA/g9BBAIAIAAMAAYAUgBlAHMAXwBOAG8AAAACAEsA AAAqAP4PYQSiBCoADAAHAFIAZQBzAF8AUgBlAGYAAAACAEwABwA7CIFDShgAACYA/g9RBMIE JgAMAAkAUgBlAHMAXwBUAGkAdABsAGUAAAACAE0AAAAoAP4PUQECACgADAAKAFMAZQBjAHQA aQBvAG4AXwBOAG8AAAACAE4AAAAyAP4PAQDSAzIADAANAFMAZQBjAHQAaQBvAG4AXwBUAGkA dABsAGUAAAACAE8ABABDShwAMgD+DwEAAgAyAAwABgBTAG8AdQByAGMAZQAAAAwAUAADJAET pEgDYSQBBwA1CIFDShwAAGoA/g8BABIFagAMAAoAVABhAGIAbABlAF8AVABlAHgAdAAAAD8A UQANxjIDGgOnBDQGDhwBNwJTA24EigWlBsEH3Aj4CRMLLwxKDWYOgQ8AAAAAAAAAAAAAAAAA ABOkKAAUpCgAAAQAQ0oWAD4A/g8RBSIFPgAMAAoAVABhAGIAbABlAF8ASABlAGEAZAAAABMA UgADJAEGJAETpFAAFKRQAGEkAQADADUIgQAwAP4PEQUyBTAADAAMAFQAYQBiAGwAZQBfAEwA ZQBnAGUAbgBkAAAABgBTABOkeAAAADYA/g8BAFIFNgAMAAUAdABvAGMAIAAwAAAAFQBUAAMk Ag3GCgQaA6cENAbBBwBhJAIAAwA1CIEARgATAAEAUgVGAA0ABQBUAE8AQwAgADEAAAAqAFUA DcYRA6cENAbBBwPEA1UiUiXAyMIPhMQDEYQ8/BOk8ABehMQDYIQ8/AAAIgAUAFEFYgUiAA0A BQBUAE8AQwAgADIAAAAGAFYAE6R4AAAAIgAVAGEFcgUiAA0ABQBUAE8AQwAgADMAAAAGAFcA E6RQAAAAHgAWAHEFggUeAA0ABQBUAE8AQwAgADQAAAACAFgAAAAeABcAcQWSBR4ADQAFAFQA TwBDACAANQAAAAIAWQAAAB4AGABxBaIFHgANAAUAVABPAEMAIAA2AAAAAgBaAAAAHgAZAHEF sgUeAA0ABQBUAE8AQwAgADcAAAACAFsAAAAeABoAcQXCBR4ADQAFAFQATwBDACAAOAAAAAIA XAAAAB4AGwBxBdIFHgANAAUAVABPAEMAIAA5AAAAAgBdAAAAYAD+D+EB4gVgAAwACwBBAFMA TgAuADEAIABDAG8AbgB0AC4AAAAnAF4ADcYiCjcCbgSlBtwIEwtKDYEPuBHvEyYWBBoDpwQ0 BsEHAAAAAAAPAENKEgBtSAkEc0gJBHUIAAAuAFVAogDxBS4ADAAJAEgAeQBwAGUAcgBsAGkA bgBrAAAADAA+KgFCKgJwaAAA/wAAAAAA4wwAAAUAAB4AAAAA/////wAAAABUAAAAYgAAAGMA AAB9AAAAfgAAAI4AAACqAAAABQEAABMBAAArAQAAPgEAAGwBAAB4AQAAkwEAAJQBAACsAQAA 5AEAAO4BAAAMAgAADQIAAA4CAAAPAgAAEAIAABECAADkAgAAzAMAADMFAAD0BQAAyAYAABoI AADVCAAAEgoAACILAABcCwAArwsAAMELAADQCwAA0QsAAFgMAABZDAAA4AwAAOQMAACYAAAA ETAAAAAAAAAAgAAAAICYAAAAEQAAAAAAAAAAgAAAAICYAAAAEQAAAAAAAAAAgAAAAICYAAAA ETAAAAAAAAAAgAAAAICYAAAAEQAAAAAAAAAAgAAAAICpAAAAADAAAAAAAAAAgAAAAICpAAAA ADAAAAAAAAAAgAAAAICpAAAAADAAAAAAAAAAgAAAAICpAAAAADAAAAAAAAAAgAAAAICpAAAA ADAAAAAAAAAAgAAAAICpAAAAADAAAAAAAAAAgAAAAICpAAAAADAAAAAAAAAAgAAAAICpAAAA ADAAAAAAAAAAgAAAAICpAAAAADAAAAAAAAAAgAAAAICpAAAAADAAAAAAAAAAgAAAAICpAAAA ETAAAAAAAAAAgAAAAICpAAAAADAAAAAAAAAAgAAAAICpAAAAADAAAAAAAAAAgAAAAICpAAAA ADAAAAAAAAAAgAAAAICpAAAAADAAAAAAAAAAgAAAAICZAAAAADAAAAAAAAAAgAAAAICYAAAA ADAAAAAAAAAAgAAAAICYAAAAAAAAAAAAAAAAgAAAAICYAAAAAAAAAAAAAAAAgAAAAICYAAAA ADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAA ADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAA ADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAA ADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICYAAAAADAAAAAAAAAAgAAAAICaQAAA DzAAAAAAAAAAgAAAAICaQAAAAAAAAAAAAAAAgAAAAICYQAAAEDAAAAAAAAAAgAAAAICaQAAA AAAAAAAAAAAAgAAAAICYQAAAEDAAAAAAAAAAgAAAAIAKAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAAAQAAAAmAAAAJgAAAAgAQAAIwEAAAAE AADjEAAACgAAAAAEAACsBQAAIg8AAOMQAAALAAAADQAAAA4AAAAABAAA4hAAAAwAAAACAAAA CQAAAAsAAAAQAAAALQAAAHMAAAB1AAAAjAAAAJUAAACYAAAAtQAAAPsAAAD9AAAAFAEAAB0B AAAjAQAAEyEU/5WAEx0U/5WAExYU/5WAEx0U/5WAExYU/5WAAAAAAH4AAAB+AAAANAEAADoB AAB4AQAA7AEAAO0BAAARAgAAAwcAABcHAAArBwAANAcAADQHAAA1BwAAlwcAAKMHAAAlCAAA OQgAAL4IAADECAAAIQsAACILAABBCwAATgsAAMALAADBCwAAwwsAAM0LAADRCwAANQwAADYM AABXDAAAWQwAAL0MAAC+DAAA3wwAAOEMAADkDAAABwAEAAcAHAAHAAMABAADAAcAHAAHABwA BAAcAAcAHAAHABwABwAcAAcABAAHABwABwACAAcABwAHAAcABwAHAAcABwAHAAcABwACAAAA AAB+AAAAfgAAANQAAADeAAAAeAEAAOwBAADuAQAAEQIAAEAGAABMBgAANAcAADQHAAAhCwAA IgsAAMALAADBCwAAwwsAAM0LAADRCwAANQwAADYMAABXDAAAWQwAAL0MAAC+DAAA3wwAAOEM AADkDAAABwAEAAcAMwAHAAMABAADAAcAMwAHAAQABwAEAAcAAgAHAAcABwAHAAcABwAHAAcA BwAHAAcAAgAAAAAAVAAAAH4AAACOAAAAyAYAAKQHAACvCwAAwAsAAMELAADDCwAAzQsAAM8L AADhDAAA5AwAAAUABwAFAAcABAAHAAUABwAFAAcABQAHAAIA//8UAAAABwBtAGMAZwByAGEA dABoACUATQA6AFwAUwBHAF8ARABPAEMAXABTAEcANABcAEEAUABSAEkATAAwADIAXABUAEQA cwBcAFAATABFAE4AXAA4ADYALgBkAG8AYwANAEQAYQB2AGUAIABNAGEAdAB0AGgAZQB3AHMA PABDADoAXABXAEkATgBEAE8AVwBTAFwARABlAHMAawB0AG8AcABcAFQAMAAxAC0AUwBHADAA NAAtADAAMgAwADQAMAA4AC0AVABEAC0AUABMAEUATgAtADAAMAA4ADYAcgAxACEAIQBNAFMA VwAtAEUALgBkAG8AYwAHAG0AYwBnAHIAYQB0AGgAJwBNADoAXABTAEcAXwBEAE8AQwBcAFMA RwA0AFwAQQBQAFIASQBMADAAMgBcAFQARABzAFwAUABMAEUATgBcADgANgByADEALgBkAG8A YwAHAG0AYwBnAHIAYQB0AGgAJwBNADoAXABTAEcAXwBEAE8AQwBcAFMARwA0AFwAQQBQAFIA SQBMADAAMgBcAFQARABzAFwAUABMAEUATgBcADgANgByADEALgBkAG8AYwAKAEQAYQB2AGUA IABTAGkAZABvAHIAcgBEADoAXABQAHIAbwBmAGkAbABlAHMAXABEAEoAUwBpAGQAbwByAFwA QQBwAHAAbABpAGMAYQB0AGkAbwBuACAARABhAHQAYQBcAE0AaQBjAHIAbwBzAG8AZgB0AFwA VwBvAHIAZABcAEEAdQB0AG8AUgBlAGMAbwB2AGUAcgB5ACAAcwBhAHYAZQAgAG8AZgAgAFQA MAAxAC0AUwBHADAANAAtADAAMgAwADQAMAA4AC0AVABEAC0AUABMAEUATgAtADAAMAA4ADYA IQBSADEAIQBNAFMAVwAtAEUALgBhAHMAZAAKAEQAYQB2AGUAIABTAGkAZABvAHIARQBEADoA XABQAHIAbwBmAGkAbABlAHMAXABEAEoAUwBpAGQAbwByAFwARABlAHMAawB0AG8AcABcAFQA MAAxAC0AUwBHADAANAAtADAAMgAwADQAMAA4AC0AVABEAC0AUABMAEUATgAtADAAMAA4ADYA IQBSADEAIQBNAFMAVwAtAEUALgBkAG8AYwAKAEQAYQB2AGUAIABTAGkAZABvAHIARQBEADoA XABQAHIAbwBmAGkAbABlAHMAXABEAEoAUwBpAGQAbwByAFwARABlAHMAawB0AG8AcABcAFQA MAAxAC0AUwBHADAANAAtADAAMgAwADQAMAA4AC0AVABEAC0AUABMAEUATgAtADAAMAA4ADYA IQBSADEAIQBNAFMAVwAtAEUALgBkAG8AYwAKAEQAYQB2AGUAIABTAGkAZABvAHIARQBEADoA XABQAHIAbwBmAGkAbABlAHMAXABEAEoAUwBpAGQAbwByAFwARABlAHMAawB0AG8AcABcAFQA MAAxAC0AUwBHADAANAAtADAAMgAwADQAMAA4AC0AVABEAC0AUABMAEUATgAtADAAMAA4ADYA IQBSADEAIQBNAFMAVwAtAEUALgBkAG8AYwAKAEQAYQB2AGUAIABTAGkAZABvAHIARQBEADoA XABQAHIAbwBmAGkAbABlAHMAXABEAEoAUwBpAGQAbwByAFwARABlAHMAawB0AG8AcABcAFQA MAAxAC0AUwBHADAANAAtADAAMgAwADQAMAA4AC0AVABEAC0AUABMAEUATgAtADAAMAA4ADYA IQBSADEAIQBNAFMAVwAtAEUALgBkAG8AYwAKAEQAYQB2AGUAIABTAGkAZABvAHIARQBEADoA XABQAHIAbwBmAGkAbABlAHMAXABEAEoAUwBpAGQAbwByAFwARABlAHMAawB0AG8AcABcAFQA MAAxAC0AUwBHADAANAAtADAAMgAwADQAMAA4AC0AVABEAC0AUABMAEUATgAtADAAMAA4ADYA IQBSADEAIQBNAFMAVwAtAEUALgBkAG8AYwAXANVIaws4NaYb/w//D/8P/w//D/8P/w//D/8P EADCR/YNPGJKZf8P/w//D/8P/w//D/8P/w//DxAATWWhDmyHwCL/D/8P/w//D/8P/w//D/8P /w8QAAc9VhEOCgji/w//D/8P/w//D/8P/w//D/8PAQAoH9EZ3IPCZv8P/w//D/8P/w//D/8P /w//DxAAADRVG/a9LNv/D/8P/w//D/8P/w//D/8P/w8QAAhSVySg/yJR/w//D/8P/w//D/8P /w//D/8PEADPZNwyBjpIIf8P/w//D/8P/w//D/8P/w//DxAAKm7pNcLTSkD/D/8P/w//D/8P /w//D/8P/w8QAFIACDZgGsYT/w//D/8P/w//D/8P/w//D/8PEAAfWwQ3VH0AqP8P/w//D/8P /w//D/8P/w//DxAADkzKPFKtxOz/D/8P/w//D/8P/w//D/8P/w8QAO85aEOMcWIw/w//D/8P /w//D/8P/w//D/8PEACAKCZEdh+O0v8P/w//D/8P/w//D/8P/w//DxAA8SebRLZRjh3/D/8P /w//D/8P/w//D/8P/w8BAEJTG0XykUCp/w//D/8P/w//D/8P/w//D/8PEAC1GN1W4L+Whv8P /w//D/8P/w//D/8P/w//DxAAtkCIXw8ACQT/DwAAAAAAAAAAAAAAAAAAAAABAPoGdGgPAAkE /w8AAAAAAAAAAAAAAAAAAAAAAQAzEHlpZOZO/P8P/w//D/8P/w//D/8P/w//DxAAunatbFZ8 KBz/D/8P/w//D/8P/w//D/8P/w8QAPNP/XhUW/LV/w//D/8P/w//D/8P/w//D/8PEABwVEx/ aqOYsf8P/w//D/8P/w//D/8P/w//DxAAISUAABcAAAAAAAAAAAAAAAAAAAAAAAAAExgAAA+E 0AIRhJj+FcYFAAHQAgZehNACYISY/k9KBABQSgAAUUoEAF5KAABvKAABAG7wAQAAABeAAAAA AAAAAAAAAAAAAAAAAAAACxgAAA+EoAURhJj+FcYFAAGgBQZehKAFYISY/k9KBQBRSgUAbygA AQBvAAEAAAAXgAAAAAAAAAAAAAAAAAAAAAAAAAsYAAAPhHAIEYSY/hXGBQABcAgGXoRwCGCE mP5PSgQAUUoEAG8oAAEAp/ABAAAAF4AAAAAAAAAAAAAAAAAAAAAAAAALGAAAD4RACxGEmP4V xgUAAUALBl6EQAtghJj+T0oBAFFKAQBvKAABALfwAQAAABeAAAAAAAAAAAAAAAAAAAAAAAAA CxgAAA+EEA4RhJj+FcYFAAEQDgZehBAOYISY/k9KBQBRSgUAbygAAQBvAAEAAAAXgAAAAAAA AAAAAAAAAAAAAAAAAAsYAAAPhOAQEYSY/hXGBQAB4BAGXoTgEGCEmP5PSgQAUUoEAG8oAAEA p/ABAAAAF4AAAAAAAAAAAAAAAAAAAAAAAAALGAAAD4SwExGEmP4VxgUAAbATBl6EsBNghJj+ T0oBAFFKAQBvKAABALfwAQAAABeAAAAAAAAAAAAAAAAAAAAAAAAACxgAAA+EgBYRhJj+FcYF AAGAFgZehIAWYISY/k9KBQBRSgUAbygAAQBvAAEAAAAXgAAAAAAAAAAAAAAAAAAAAAAAAAsY AAAPhFAZEYSY/hXGBQABUBkGXoRQGWCEmP5PSgQAUUoEAG8oAAEAp/AhJQAAFwAAAAAAAAAA AAAAAAAAAAAAAAATGAAAD4TQAhGEmP4VxgUAAdACBl6E0AJghJj+T0oEAFBKAABRSgQAXkoA AG8oAAEAbvABAAAAF4AAAAAAAAAAAAAAAAAAAAAAAAALGAAAD4SgBRGEmP4VxgUAAaAFBl6E oAVghJj+T0oFAFFKBQBvKAABAG8AAQAAABeAAAAAAAAAAAAAAAAAAAAAAAAACxgAAA+EcAgR hJj+FcYFAAFwCAZehHAIYISY/k9KBABRSgQAbygAAQCn8AEAAAAXgAAAAAAAAAAAAAAAAAAA AAAAAAsYAAAPhEALEYSY/hXGBQABQAsGXoRAC2CEmP5PSgEAUUoBAG8oAAEAt/ABAAAAF4AA AAAAAAAAAAAAAAAAAAAAAAALGAAAD4QQDhGEmP4VxgUAARAOBl6EEA5ghJj+T0oFAFFKBQBv KAABAG8AAQAAABeAAAAAAAAAAAAAAAAAAAAAAAAACxgAAA+E4BARhJj+FcYFAAHgEAZehOAQ YISY/k9KBABRSgQAbygAAQCn8AEAAAAXgAAAAAAAAAAAAAAAAAAAAAAAAAsYAAAPhLATEYSY /hXGBQABsBMGXoSwE2CEmP5PSgEAUUoBAG8oAAEAt/ABAAAAF4AAAAAAAAAAAAAAAAAAAAAA AAALGAAAD4SAFhGEmP4VxgUAAYAWBl6EgBZghJj+T0oFAFFKBQBvKAABAG8AAQAAABeAAAAA AAAAAAAAAAAAAAAAAAAACxgAAA+EUBkRhJj+FcYFAAFQGQZehFAZYISY/k9KBABRSgQAbygA AQCn8CElAAAXAAAAAAAAAAAAAAAAAAAAAAAAABMYAAAPhNACEYSY/hXGBQAB0AIGXoTQAmCE mP5PSgQAUEoAAFFKBABeSgAAbygAAQBu8AEAAAAXgAAAAAAAAAAAAAAAAAAAAAAAAAsYAAAP hKAFEYSY/hXGBQABoAUGXoSgBWCEmP5PSgUAUUoFAG8oAAEAbwABAAAAF4AAAAAAAAAAAAAA AAAAAAAAAAALGAAAD4RwCBGEmP4VxgUAAXAIBl6EcAhghJj+T0oEAFFKBABvKAABAKfwAQAA ABeAAAAAAAAAAAAAAAAAAAAAAAAACxgAAA+EQAsRhJj+FcYFAAFACwZehEALYISY/k9KAQBR SgEAbygAAQC38AEAAAAXgAAAAAAAAAAAAAAAAAAAAAAAAAsYAAAPhBAOEYSY/hXGBQABEA4G XoQQDmCEmP5PSgUAUUoFAG8oAAEAbwABAAAAF4AAAAAAAAAAAAAAAAAAAAAAAAALGAAAD4Tg EBGEmP4VxgUAAeAQBl6E4BBghJj+T0oEAFFKBABvKAABAKfwAQAAABeAAAAAAAAAAAAAAAAA AAAAAAAACxgAAA+EsBMRhJj+FcYFAAGwEwZehLATYISY/k9KAQBRSgEAbygAAQC38AEAAAAX gAAAAAAAAAAAAAAAAAAAAAAAAAsYAAAPhIAWEYSY/hXGBQABgBYGXoSAFmCEmP5PSgUAUUoF AG8oAAEAbwABAAAAF4AAAAAAAAAAAAAAAAAAAAAAAAALGAAAD4RQGRGEmP4VxgUAAVAZBl6E UBlghJj+T0oEAFFKBABvKAABAKfwDQAAABcAAAAAAAAAAAAAAAAAAAAAAAAACxgAAA+EaAER hJj+FcYFAAFoAQZehGgBYISY/k9KBABRSgQAbygAAQBu8CElAAAXAAAAAAAAAAAAAAAAAAAA AAAAABkYAAAPhNACEYSY/hXGBQAB0AIGXoTQAmCEmP41CAA2CAFPSgQAUEoAAFFKBABeSgAA bygAAQBu8AEAAAAXgAAAAAAAAAAAAAAAAAAAAAAAAAsYAAAPhKAFEYSY/hXGBQABoAUGXoSg BWCEmP5PSgUAUUoFAG8oAAEAbwABAAAAF4AAAAAAAAAAAAAAAAAAAAAAAAALGAAAD4RwCBGE mP4VxgUAAXAIBl6EcAhghJj+T0oEAFFKBABvKAABAKfwAQAAABeAAAAAAAAAAAAAAAAAAAAA AAAACxgAAA+EQAsRhJj+FcYFAAFACwZehEALYISY/k9KAQBRSgEAbygAAQC38AEAAAAXgAAA AAAAAAAAAAAAAAAAAAAAAAsYAAAPhBAOEYSY/hXGBQABEA4GXoQQDmCEmP5PSgUAUUoFAG8o AAEAbwABAAAAF4AAAAAAAAAAAAAAAAAAAAAAAAALGAAAD4TgEBGEmP4VxgUAAeAQBl6E4BBg hJj+T0oEAFFKBABvKAABAKfwAQAAABeAAAAAAAAAAAAAAAAAAAAAAAAACxgAAA+EsBMRhJj+ FcYFAAGwEwZehLATYISY/k9KAQBRSgEAbygAAQC38AEAAAAXgAAAAAAAAAAAAAAAAAAAAAAA AAsYAAAPhIAWEYSY/hXGBQABgBYGXoSAFmCEmP5PSgUAUUoFAG8oAAEAbwABAAAAF4AAAAAA AAAAAAAAAAAAAAAAAAALGAAAD4RQGRGEmP4VxgUAAVAZBl6EUBlghJj+T0oEAFFKBABvKAAB AKfwISUAABcAAAAAAAAAAAAAAAAAAAAAAAAAExgAAA+E0AIRhJj+FcYFAAHQAgZehNACYISY /k9KBABQSgAAUUoEAF5KAABvKAABAG7wAQAAABeAAAAAAAAAAAAAAAAAAAAAAAAACxgAAA+E oAURhJj+FcYFAAGgBQZehKAFYISY/k9KBQBRSgUAbygAAQBvAAEAAAAXgAAAAAAAAAAAAAAA AAAAAAAAAAsYAAAPhHAIEYSY/hXGBQABcAgGXoRwCGCEmP5PSgQAUUoEAG8oAAEAp/ABAAAA F4AAAAAAAAAAAAAAAAAAAAAAAAALGAAAD4RACxGEmP4VxgUAAUALBl6EQAtghJj+T0oBAFFK AQBvKAABALfwAQAAABeAAAAAAAAAAAAAAAAAAAAAAAAACxgAAA+EEA4RhJj+FcYFAAEQDgZe hBAOYISY/k9KBQBRSgUAbygAAQBvAAEAAAAXgAAAAAAAAAAAAAAAAAAAAAAAAAsYAAAPhOAQ EYSY/hXGBQAB4BAGXoTgEGCEmP5PSgQAUUoEAG8oAAEAp/ABAAAAF4AAAAAAAAAAAAAAAAAA AAAAAAALGAAAD4SwExGEmP4VxgUAAbATBl6EsBNghJj+T0oBAFFKAQBvKAABALfwAQAAABeA AAAAAAAAAAAAAAAAAAAAAAAACxgAAA+EgBYRhJj+FcYFAAGAFgZehIAWYISY/k9KBQBRSgUA bygAAQBvAAEAAAAXgAAAAAAAAAAAAAAAAAAAAAAAAAsYAAAPhFAZEYSY/hXGBQABUBkGXoRQ GWCEmP5PSgQAUUoEAG8oAAEAp/AhJQAAFwAAAAAAAAAAAAAAAAAAAAAAAAATGAAAD4TQAhGE mP4VxgUAAdACBl6E0AJghJj+T0oEAFBKAABRSgQAXkoAAG8oAAEAbvABAAAAF4AAAAAAAAAA AAAAAAAAAAAAAAALGAAAD4SgBRGEmP4VxgUAAaAFBl6EoAVghJj+T0oFAFFKBQBvKAABAG8A AQAAABeAAAAAAAAAAAAAAAAAAAAAAAAACxgAAA+EcAgRhJj+FcYFAAFwCAZehHAIYISY/k9K BABRSgQAbygAAQCn8AEAAAAXgAAAAAAAAAAAAAAAAAAAAAAAAAsYAAAPhEALEYSY/hXGBQAB QAsGXoRAC2CEmP5PSgEAUUoBAG8oAAEAt/ABAAAAF4AAAAAAAAAAAAAAAAAAAAAAAAALGAAA D4QQDhGEmP4VxgUAARAOBl6EEA5ghJj+T0oFAFFKBQBvKAABAG8AAQAAABeAAAAAAAAAAAAA AAAAAAAAAAAACxgAAA+E4BARhJj+FcYFAAHgEAZehOAQYISY/k9KBABRSgQAbygAAQCn8AEA AAAXgAAAAAAAAAAAAAAAAAAAAAAAAAsYAAAPhLATEYSY/hXGBQABsBMGXoSwE2CEmP5PSgEA UUoBAG8oAAEAt/ABAAAAF4AAAAAAAAAAAAAAAAAAAAAAAAALGAAAD4SAFhGEmP4VxgUAAYAW Bl6EgBZghJj+T0oFAFFKBQBvKAABAG8AAQAAABeAAAAAAAAAAAAAAAAAAAAAAAAACxgAAA+E UBkRhJj+FcYFAAFQGQZehFAZYISY/k9KBABRSgQAbygAAQCn8CElAAAXAAAAAAAAAAAAAAAA AAAAAAAAABMYAAAPhNACEYSY/hXGBQAB0AIGXoTQAmCEmP5PSgQAUEoAAFFKBABeSgAAbygA AQBu8AEAAAAXgAAAAAAAAAAAAAAAAAAAAAAAAAsYAAAPhKAFEYSY/hXGBQABoAUGXoSgBWCE mP5PSgUAUUoFAG8oAAEAbwABAAAAF4AAAAAAAAAAAAAAAAAAAAAAAAALGAAAD4RwCBGEmP4V xgUAAXAIBl6EcAhghJj+T0oEAFFKBABvKAABAKfwAQAAABeAAAAAAAAAAAAAAAAAAAAAAAAA CxgAAA+EQAsRhJj+FcYFAAFACwZehEALYISY/k9KAQBRSgEAbygAAQC38AEAAAAXgAAAAAAA AAAAAAAAAAAAAAAAAAsYAAAPhBAOEYSY/hXGBQABEA4GXoQQDmCEmP5PSgUAUUoFAG8oAAEA bwABAAAAF4AAAAAAAAAAAAAAAAAAAAAAAAALGAAAD4TgEBGEmP4VxgUAAeAQBl6E4BBghJj+ T0oEAFFKBABvKAABAKfwAQAAABeAAAAAAAAAAAAAAAAAAAAAAAAACxgAAA+EsBMRhJj+FcYF AAGwEwZehLATYISY/k9KAQBRSgEAbygAAQC38AEAAAAXgAAAAAAAAAAAAAAAAAAAAAAAAAsY AAAPhIAWEYSY/hXGBQABgBYGXoSAFmCEmP5PSgUAUUoFAG8oAAEAbwABAAAAF4AAAAAAAAAA AAAAAAAAAAAAAAALGAAAD4RQGRGEmP4VxgUAAVAZBl6EUBlghJj+T0oEAFFKBABvKAABAKfw ISUAABcAAAAAAAAAAAAAAAAAAAAAAAAAGRgAAA+E0AIRhJj+FcYFAAHQAgZehNACYISY/jUI ADYIAU9KBABQSgAAUUoEAF5KAABvKAABAG7wAQAAABeAAAAAAAAAAAAAAAAAAAAAAAAACxgA AA+EoAURhJj+FcYFAAGgBQZehKAFYISY/k9KBQBRSgUAbygAAQBvAAEAAAAXgAAAAAAAAAAA AAAAAAAAAAAAAAsYAAAPhHAIEYSY/hXGBQABcAgGXoRwCGCEmP5PSgQAUUoEAG8oAAEAp/AB AAAAF4AAAAAAAAAAAAAAAAAAAAAAAAALGAAAD4RACxGEmP4VxgUAAUALBl6EQAtghJj+T0oB AFFKAQBvKAABALfwAQAAABeAAAAAAAAAAAAAAAAAAAAAAAAACxgAAA+EEA4RhJj+FcYFAAEQ DgZehBAOYISY/k9KBQBRSgUAbygAAQBvAAEAAAAXgAAAAAAAAAAAAAAAAAAAAAAAAAsYAAAP hOAQEYSY/hXGBQAB4BAGXoTgEGCEmP5PSgQAUUoEAG8oAAEAp/ABAAAAF4AAAAAAAAAAAAAA AAAAAAAAAAALGAAAD4SwExGEmP4VxgUAAbATBl6EsBNghJj+T0oBAFFKAQBvKAABALfwAQAA ABeAAAAAAAAAAAAAAAAAAAAAAAAACxgAAA+EgBYRhJj+FcYFAAGAFgZehIAWYISY/k9KBQBR SgUAbygAAQBvAAEAAAAXgAAAAAAAAAAAAAAAAAAAAAAAAAsYAAAPhFAZEYSY/hXGBQABUBkG XoRQGWCEmP5PSgQAUUoEAG8oAAEAp/AhJQAAFwAAAAAAAAAAAAAAAAAAAAAAAAATGAAAD4TQ AhGEmP4VxgUAAdACBl6E0AJghJj+T0oEAFBKAABRSgQAXkoAAG8oAAEAbvABAAAAF4AAAAAA AAAAAAAAAAAAAAAAAAALGAAAD4SgBRGEmP4VxgUAAaAFBl6EoAVghJj+T0oFAFFKBQBvKAAB AG8AAQAAABeAAAAAAAAAAAAAAAAAAAAAAAAACxgAAA+EcAgRhJj+FcYFAAFwCAZehHAIYISY /k9KBABRSgQAbygAAQCn8AEAAAAXgAAAAAAAAAAAAAAAAAAAAAAAAAsYAAAPhEALEYSY/hXG BQABQAsGXoRAC2CEmP5PSgEAUUoBAG8oAAEAt/ABAAAAF4AAAAAAAAAAAAAAAAAAAAAAAAAL GAAAD4QQDhGEmP4VxgUAARAOBl6EEA5ghJj+T0oFAFFKBQBvKAABAG8AAQAAABeAAAAAAAAA AAAAAAAAAAAAAAAACxgAAA+E4BARhJj+FcYFAAHgEAZehOAQYISY/k9KBABRSgQAbygAAQCn 8AEAAAAXgAAAAAAAAAAAAAAAAAAAAAAAAAsYAAAPhLATEYSY/hXGBQABsBMGXoSwE2CEmP5P SgEAUUoBAG8oAAEAt/ABAAAAF4AAAAAAAAAAAAAAAAAAAAAAAAALGAAAD4SAFhGEmP4VxgUA AYAWBl6EgBZghJj+T0oFAFFKBQBvKAABAG8AAQAAABeAAAAAAAAAAAAAAAAAAAAAAAAACxgA AA+EUBkRhJj+FcYFAAFQGQZehFAZYISY/k9KBABRSgQAbygAAQCn8CElAAAXAAAAAAAAAAAA AAAAAAAAAAAAABMYAAAPhNACEYSY/hXGBQAB0AIGXoTQAmCEmP5PSgQAUEoAAFFKBABeSgAA bygAAQBu8AEAAAAXgAAAAAAAAAAAAAAAAAAAAAAAAAsYAAAPhKAFEYSY/hXGBQABoAUGXoSg BWCEmP5PSgUAUUoFAG8oAAEAbwABAAAAF4AAAAAAAAAAAAAAAAAAAAAAAAALGAAAD4RwCBGE mP4VxgUAAXAIBl6EcAhghJj+T0oEAFFKBABvKAABAKfwAQAAABeAAAAAAAAAAAAAAAAAAAAA AAAACxgAAA+EQAsRhJj+FcYFAAFACwZehEALYISY/k9KAQBRSgEAbygAAQC38AEAAAAXgAAA AAAAAAAAAAAAAAAAAAAAAAsYAAAPhBAOEYSY/hXGBQABEA4GXoQQDmCEmP5PSgUAUUoFAG8o AAEAbwABAAAAF4AAAAAAAAAAAAAAAAAAAAAAAAALGAAAD4TgEBGEmP4VxgUAAeAQBl6E4BBg hJj+T0oEAFFKBABvKAABAKfwAQAAABeAAAAAAAAAAAAAAAAAAAAAAAAACxgAAA+EsBMRhJj+ FcYFAAGwEwZehLATYISY/k9KAQBRSgEAbygAAQC38AEAAAAXgAAAAAAAAAAAAAAAAAAAAAAA AAsYAAAPhIAWEYSY/hXGBQABgBYGXoSAFmCEmP5PSgUAUUoFAG8oAAEAbwABAAAAF4AAAAAA AAAAAAAAAAAAAAAAAAALGAAAD4RQGRGEmP4VxgUAAVAZBl6EUBlghJj+T0oEAFFKBABvKAAB AKfwISUAABcAAAAAAAAAAAAAAAAAAAAAAAAAExgAAA+E0AIRhJj+FcYFAAHQAgZehNACYISY /k9KBABQSgAAUUoEAF5KAABvKAABAG7wAQAAABeAAAAAAAAAAAAAAAAAAAAAAAAACxgAAA+E oAURhJj+FcYFAAGgBQZehKAFYISY/k9KBQBRSgUAbygAAQBvAAEAAAAXgAAAAAAAAAAAAAAA AAAAAAAAAAsYAAAPhHAIEYSY/hXGBQABcAgGXoRwCGCEmP5PSgQAUUoEAG8oAAEAp/ABAAAA F4AAAAAAAAAAAAAAAAAAAAAAAAALGAAAD4RACxGEmP4VxgUAAUALBl6EQAtghJj+T0oBAFFK AQBvKAABALfwAQAAABeAAAAAAAAAAAAAAAAAAAAAAAAACxgAAA+EEA4RhJj+FcYFAAEQDgZe hBAOYISY/k9KBQBRSgUAbygAAQBvAAEAAAAXgAAAAAAAAAAAAAAAAAAAAAAAAAsYAAAPhOAQ EYSY/hXGBQAB4BAGXoTgEGCEmP5PSgQAUUoEAG8oAAEAp/ABAAAAF4AAAAAAAAAAAAAAAAAA AAAAAAALGAAAD4SwExGEmP4VxgUAAbATBl6EsBNghJj+T0oBAFFKAQBvKAABALfwAQAAABeA AAAAAAAAAAAAAAAAAAAAAAAACxgAAA+EgBYRhJj+FcYFAAGAFgZehIAWYISY/k9KBQBRSgUA bygAAQBvAAEAAAAXgAAAAAAAAAAAAAAAAAAAAAAAAAsYAAAPhFAZEYSY/hXGBQABUBkGXoRQ GWCEmP5PSgQAUUoEAG8oAAEAp/AhJQAAFwAAAAAAAAAAAAAAAAAAAAAAAAATGAAAD4TQAhGE mP4VxgUAAdACBl6E0AJghJj+T0oEAFBKAABRSgQAXkoAAG8oAAEAbvABAAAAF4AAAAAAAAAA AAAAAAAAAAAAAAALGAAAD4SgBRGEmP4VxgUAAaAFBl6EoAVghJj+T0oFAFFKBQBvKAABAG8A AQAAABeAAAAAAAAAAAAAAAAAAAAAAAAACxgAAA+EcAgRhJj+FcYFAAFwCAZehHAIYISY/k9K BABRSgQAbygAAQCn8AEAAAAXgAAAAAAAAAAAAAAAAAAAAAAAAAsYAAAPhEALEYSY/hXGBQAB QAsGXoRAC2CEmP5PSgEAUUoBAG8oAAEAt/ABAAAAF4AAAAAAAAAAAAAAAAAAAAAAAAALGAAA D4QQDhGEmP4VxgUAARAOBl6EEA5ghJj+T0oFAFFKBQBvKAABAG8AAQAAABeAAAAAAAAAAAAA AAAAAAAAAAAACxgAAA+E4BARhJj+FcYFAAHgEAZehOAQYISY/k9KBABRSgQAbygAAQCn8AEA AAAXgAAAAAAAAAAAAAAAAAAAAAAAAAsYAAAPhLATEYSY/hXGBQABsBMGXoSwE2CEmP5PSgEA UUoBAG8oAAEAt/ABAAAAF4AAAAAAAAAAAAAAAAAAAAAAAAALGAAAD4SAFhGEmP4VxgUAAYAW Bl6EgBZghJj+T0oFAFFKBQBvKAABAG8AAQAAABeAAAAAAAAAAAAAAAAAAAAAAAAACxgAAA+E UBkRhJj+FcYFAAFQGQZehFAZYISY/k9KBABRSgQAbygAAQCn8CElAAAXAAAAAAAAAAAAAAAA AAAAAAAAABMYAAAPhNACEYSY/hXGBQAB0AIGXoTQAmCEmP5PSgQAUEoAAFFKBABeSgAAbygA AQBu8AEAAAAXgAAAAAAAAAAAAAAAAAAAAAAAAAsYAAAPhKAFEYSY/hXGBQABoAUGXoSgBWCE mP5PSgUAUUoFAG8oAAEAbwABAAAAF4AAAAAAAAAAAAAAAAAAAAAAAAALGAAAD4RwCBGEmP4V xgUAAXAIBl6EcAhghJj+T0oEAFFKBABvKAABAKfwAQAAABeAAAAAAAAAAAAAAAAAAAAAAAAA CxgAAA+EQAsRhJj+FcYFAAFACwZehEALYISY/k9KAQBRSgEAbygAAQC38AEAAAAXgAAAAAAA AAAAAAAAAAAAAAAAAAsYAAAPhBAOEYSY/hXGBQABEA4GXoQQDmCEmP5PSgUAUUoFAG8oAAEA bwABAAAAF4AAAAAAAAAAAAAAAAAAAAAAAAALGAAAD4TgEBGEmP4VxgUAAeAQBl6E4BBghJj+ T0oEAFFKBABvKAABAKfwAQAAABeAAAAAAAAAAAAAAAAAAAAAAAAACxgAAA+EsBMRhJj+FcYF AAGwEwZehLATYISY/k9KAQBRSgEAbygAAQC38AEAAAAXgAAAAAAAAAAAAAAAAAAAAAAAAAsY AAAPhIAWEYSY/hXGBQABgBYGXoSAFmCEmP5PSgUAUUoFAG8oAAEAbwABAAAAF4AAAAAAAAAA AAAAAAAAAAAAAAALGAAAD4RQGRGEmP4VxgUAAVAZBl6EUBlghJj+T0oEAFFKBABvKAABAKfw AAAAABcAAAAAAAAAAAAAAAAAAAAAAAAACxgAAA+EaAERhJj+FcYFAAFoAQZehGgBYISY/k9K BABRSgQAbygAAQBu8CElAAAXAAAAAAAAAAAAAAAAAAAAAAAAABMYAAAPhNACEYSY/hXGBQAB 0AIGXoTQAmCEmP5PSgQAUEoAAFFKBABeSgAAbygAAQBu8AEAAAAXgAAAAAAAAAAAAAAAAAAA AAAAAAsYAAAPhKAFEYSY/hXGBQABoAUGXoSgBWCEmP5PSgUAUUoFAG8oAAEAbwABAAAAF4AA AAAAAAAAAAAAAAAAAAAAAAALGAAAD4RwCBGEmP4VxgUAAXAIBl6EcAhghJj+T0oEAFFKBABv KAABAKfwAQAAABeAAAAAAAAAAAAAAAAAAAAAAAAACxgAAA+EQAsRhJj+FcYFAAFACwZehEAL YISY/k9KAQBRSgEAbygAAQC38AEAAAAXgAAAAAAAAAAAAAAAAAAAAAAAAAsYAAAPhBAOEYSY /hXGBQABEA4GXoQQDmCEmP5PSgUAUUoFAG8oAAEAbwABAAAAF4AAAAAAAAAAAAAAAAAAAAAA AAALGAAAD4TgEBGEmP4VxgUAAeAQBl6E4BBghJj+T0oEAFFKBABvKAABAKfwAQAAABeAAAAA AAAAAAAAAAAAAAAAAAAACxgAAA+EsBMRhJj+FcYFAAGwEwZehLATYISY/k9KAQBRSgEAbygA AQC38AEAAAAXgAAAAAAAAAAAAAAAAAAAAAAAAAsYAAAPhIAWEYSY/hXGBQABgBYGXoSAFmCE mP5PSgUAUUoFAG8oAAEAbwABAAAAF4AAAAAAAAAAAAAAAAAAAAAAAAALGAAAD4RQGRGEmP4V xgUAAVAZBl6EUBlghJj+T0oEAFFKBABvKAABAKfwISUAABcAAAAAAAAAAAAAAAAAAAAAAAAA GRgAAA+E0AIRhJj+FcYFAAHQAgZehNACYISY/jUIADYIAU9KBABQSgAAUUoEAF5KAABvKAAB AG7wAQAAABeAAAAAAAAAAAAAAAAAAAAAAAAACxgAAA+EoAURhJj+FcYFAAGgBQZehKAFYISY /k9KBQBRSgUAbygAAQBvAAEAAAAXgAAAAAAAAAAAAAAAAAAAAAAAAAsYAAAPhHAIEYSY/hXG BQABcAgGXoRwCGCEmP5PSgQAUUoEAG8oAAEAp/ABAAAAF4AAAAAAAAAAAAAAAAAAAAAAAAAL GAAAD4RACxGEmP4VxgUAAUALBl6EQAtghJj+T0oBAFFKAQBvKAABALfwAQAAABeAAAAAAAAA AAAAAAAAAAAAAAAACxgAAA+EEA4RhJj+FcYFAAEQDgZehBAOYISY/k9KBQBRSgUAbygAAQBv AAEAAAAXgAAAAAAAAAAAAAAAAAAAAAAAAAsYAAAPhOAQEYSY/hXGBQAB4BAGXoTgEGCEmP5P SgQAUUoEAG8oAAEAp/ABAAAAF4AAAAAAAAAAAAAAAAAAAAAAAAALGAAAD4SwExGEmP4VxgUA AbATBl6EsBNghJj+T0oBAFFKAQBvKAABALfwAQAAABeAAAAAAAAAAAAAAAAAAAAAAAAACxgA AA+EgBYRhJj+FcYFAAGAFgZehIAWYISY/k9KBQBRSgUAbygAAQBvAAEAAAAXgAAAAAAAAAAA AAAAAAAAAAAAAAsYAAAPhFAZEYSY/hXGBQABUBkGXoRQGWCEmP5PSgQAUUoEAG8oAAEAp/AB AAAAAAABAAAAAAAAAAAAAAAAAAAAAAAAGAAAD4RoARGEmP4VxgUAAWgBBl6EaAFghJj+AgAA AC4AAQAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAABgAAA+EaAERhJj+FcYFAAFoAQZehGgBYISY /gIAAAAuACElAAAXAAAAAAAAAAAAAAAAAAAAAAAAABMYAAAPhNACEYSY/hXGBQAB0AIGXoTQ AmCEmP5PSgQAUEoAAFFKBABeSgAAbygAAQBu8AEAAAAXgAAAAAAAAAAAAAAAAAAAAAAAAAsY AAAPhKAFEYSY/hXGBQABoAUGXoSgBWCEmP5PSgUAUUoFAG8oAAEAbwABAAAAF4AAAAAAAAAA AAAAAAAAAAAAAAALGAAAD4RwCBGEmP4VxgUAAXAIBl6EcAhghJj+T0oEAFFKBABvKAABAKfw AQAAABeAAAAAAAAAAAAAAAAAAAAAAAAACxgAAA+EQAsRhJj+FcYFAAFACwZehEALYISY/k9K AQBRSgEAbygAAQC38AEAAAAXgAAAAAAAAAAAAAAAAAAAAAAAAAsYAAAPhBAOEYSY/hXGBQAB EA4GXoQQDmCEmP5PSgUAUUoFAG8oAAEAbwABAAAAF4AAAAAAAAAAAAAAAAAAAAAAAAALGAAA D4TgEBGEmP4VxgUAAeAQBl6E4BBghJj+T0oEAFFKBABvKAABAKfwAQAAABeAAAAAAAAAAAAA AAAAAAAAAAAACxgAAA+EsBMRhJj+FcYFAAGwEwZehLATYISY/k9KAQBRSgEAbygAAQC38AEA AAAXgAAAAAAAAAAAAAAAAAAAAAAAAAsYAAAPhIAWEYSY/hXGBQABgBYGXoSAFmCEmP5PSgUA UUoFAG8oAAEAbwABAAAAF4AAAAAAAAAAAAAAAAAAAAAAAAALGAAAD4RQGRGEmP4VxgUAAVAZ Bl6EUBlghJj+T0oEAFFKBABvKAABAKfwISUAABcAAAAAAAAAAAAAAAAAAAAAAAAAExgAAA+E 0AIRhJj+FcYFAAHQAgZehNACYISY/k9KBABQSgAAUUoEAF5KAABvKAABAG7wAQAAABeAAAAA AAAAAAAAAAAAAAAAAAAACxgAAA+EoAURhJj+FcYFAAGgBQZehKAFYISY/k9KBQBRSgUAbygA AQBvAAEAAAAXgAAAAAAAAAAAAAAAAAAAAAAAAAsYAAAPhHAIEYSY/hXGBQABcAgGXoRwCGCE mP5PSgQAUUoEAG8oAAEAp/ABAAAAF4AAAAAAAAAAAAAAAAAAAAAAAAALGAAAD4RACxGEmP4V xgUAAUALBl6EQAtghJj+T0oBAFFKAQBvKAABALfwAQAAABeAAAAAAAAAAAAAAAAAAAAAAAAA CxgAAA+EEA4RhJj+FcYFAAEQDgZehBAOYISY/k9KBQBRSgUAbygAAQBvAAEAAAAXgAAAAAAA AAAAAAAAAAAAAAAAAAsYAAAPhOAQEYSY/hXGBQAB4BAGXoTgEGCEmP5PSgQAUUoEAG8oAAEA p/ABAAAAF4AAAAAAAAAAAAAAAAAAAAAAAAALGAAAD4SwExGEmP4VxgUAAbATBl6EsBNghJj+ T0oBAFFKAQBvKAABALfwAQAAABeAAAAAAAAAAAAAAAAAAAAAAAAACxgAAA+EgBYRhJj+FcYF AAGAFgZehIAWYISY/k9KBQBRSgUAbygAAQBvAAEAAAAXgAAAAAAAAAAAAAAAAAAAAAAAAAsY AAAPhFAZEYSY/hXGBQABUBkGXoRQGWCEmP5PSgQAUUoEAG8oAAEAp/AhJQAAFwAAAAAAAAAA AAAAAAAAAAAAAAATGAAAD4TQAhGEmP4VxgUAAdACBl6E0AJghJj+T0oEAFBKAABRSgQAXkoA AG8oAAEAbvABAAAAF4AAAAAAAAAAAAAAAAAAAAAAAAALGAAAD4SgBRGEmP4VxgUAAaAFBl6E oAVghJj+T0oFAFFKBQBvKAABAG8AAQAAABeAAAAAAAAAAAAAAAAAAAAAAAAACxgAAA+EcAgR hJj+FcYFAAFwCAZehHAIYISY/k9KBABRSgQAbygAAQCn8AEAAAAXgAAAAAAAAAAAAAAAAAAA AAAAAAsYAAAPhEALEYSY/hXGBQABQAsGXoRAC2CEmP5PSgEAUUoBAG8oAAEAt/ABAAAAF4AA AAAAAAAAAAAAAAAAAAAAAAALGAAAD4QQDhGEmP4VxgUAARAOBl6EEA5ghJj+T0oFAFFKBQBv KAABAG8AAQAAABeAAAAAAAAAAAAAAAAAAAAAAAAACxgAAA+E4BARhJj+FcYFAAHgEAZehOAQ YISY/k9KBABRSgQAbygAAQCn8AEAAAAXgAAAAAAAAAAAAAAAAAAAAAAAAAsYAAAPhLATEYSY /hXGBQABsBMGXoSwE2CEmP5PSgEAUUoBAG8oAAEAt/ABAAAAF4AAAAAAAAAAAAAAAAAAAAAA AAALGAAAD4SAFhGEmP4VxgUAAYAWBl6EgBZghJj+T0oFAFFKBQBvKAABAG8AAQAAABeAAAAA AAAAAAAAAAAAAAAAAAAACxgAAA+EUBkRhJj+FcYFAAFQGQZehFAZYISY/k9KBABRSgQAbygA AQCn8CElAAAXAAAAAAAAAAAAAAAAAAAAAAAAABkYAAAPhNACEYSY/hXGBQAB0AIGXoTQAmCE mP41CAA2CAFPSgQAUEoAAFFKBABeSgAAbygAAQBu8AEAAAAXgAAAAAAAAAAAAAAAAAAAAAAA AAsYAAAPhKAFEYSY/hXGBQABoAUGXoSgBWCEmP5PSgUAUUoFAG8oAAEAbwABAAAAF4AAAAAA AAAAAAAAAAAAAAAAAAALGAAAD4RwCBGEmP4VxgUAAXAIBl6EcAhghJj+T0oEAFFKBABvKAAB AKfwAQAAABeAAAAAAAAAAAAAAAAAAAAAAAAACxgAAA+EQAsRhJj+FcYFAAFACwZehEALYISY /k9KAQBRSgEAbygAAQC38AEAAAAXgAAAAAAAAAAAAAAAAAAAAAAAAAsYAAAPhBAOEYSY/hXG BQABEA4GXoQQDmCEmP5PSgUAUUoFAG8oAAEAbwABAAAAF4AAAAAAAAAAAAAAAAAAAAAAAAAL GAAAD4TgEBGEmP4VxgUAAeAQBl6E4BBghJj+T0oEAFFKBABvKAABAKfwAQAAABeAAAAAAAAA AAAAAAAAAAAAAAAACxgAAA+EsBMRhJj+FcYFAAGwEwZehLATYISY/k9KAQBRSgEAbygAAQC3 8AEAAAAXgAAAAAAAAAAAAAAAAAAAAAAAAAsYAAAPhIAWEYSY/hXGBQABgBYGXoSAFmCEmP5P SgUAUUoFAG8oAAEAbwABAAAAF4AAAAAAAAAAAAAAAAAAAAAAAAALGAAAD4RQGRGEmP4VxgUA AVAZBl6EUBlghJj+T0oEAFFKBABvKAABAKfwFwAAAPEnm0QAAAAAAAAAAAAAAAAHPVYRAAAA AAAAAAAAAAAATWWhDgAAAAAAAAAAAAAAADMQeWkAAAAAAAAAAAAAAADCR/YNAAAAAAAAAAAA AAAA80/9eAAAAAAAAAAAAAAAACgf0RkAAAAAAAAAAAAAAABwVEx/AAAAAAAAAAAAAAAAtRjd VgAAAAAAAAAAAAAAAIAoJkQAAAAAAAAAAAAAAAAqbuk1AAAAAAAAAAAAAAAAz2TcMgAAAAAA AAAAAAAAAB9bBDcAAAAAAAAAAAAAAADvOWhDAAAAAAAAAAAAAAAADkzKPAAAAAAAAAAAAAAA ALp2rWwAAAAAAAAAAAAAAABCUxtFAAAAAAAAAAAAAAAAUgAINgAAAAAAAAAAAAAAAAhSVyQA AAAAAAAAAAAAAAAANFUbAAAAAAAAAAAAAAAA1UhrCwAAAAAAAAAAAAAAAPoGdGgAAAAAAAAA AAAAAAC2QIhfAAAAAAAAAAAAAAAA//////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// /////////xcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAA//8XAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAMAAAABAAkIAQIIAAEACQQBAggAAQAMBAACCQAAAAAAfQAAAH4AAAANAgAADgIAAMELAADh DAAA5AwAAAAAAAABAAAACAAAAAIBAACWAQAAAAAAAAEAAAD/QFxcUFJUUFAwNVBccG5jMXAw MHoATmUwMToAd2luc3Bvb2wASFAgTGFzZXJKZXQgODEwMCBTZXJpZXMgUENMIDYAXFxQUlRQ UDA1UFxwbmMxcDAwegAAAAAAAAAAAAAAAAABBBgAnAC4AwM/AQIBAAEAAAAAAGQAAQAHAFgC AgACAFgCAAAAAExldHRlcgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAlAQuAEhQIExhc2Vy SmV0IDgxMDAgU2VyaWVzIFBDTCA2AMAAAAAAAAAABAAyAIYBhgN4nHVVu27DMAzc9RnZC0iU SEr5j051tnYoUHTK/6OO7VqkrEPghScej8/clWtYPlLIEkMMafuVcO/mcpqJVrvkzU4tn/YY lscJsHaeZAFingNcGVBVQh49eIoyOHXBhR1ETYC0VucKqBUE6AlkDyQUgwDVJX3WvfTaTIzt /W43ZSHLlGsamFQOwDbrdlseNr6gHLlXJTXLR5IGPsOWoRNdnP71aW9MDbf33+f38+fr0/Jm VVfXvbbnkKqhHqAeNauZX7FVd2kXBR3kPK87sV0dB8CeKwBKRcHRXDFqn6I8FE27GbhBLvKo aNmlU6U4RIkovF13j4DkS+kub15A7QLUuwAuTm0OZANkGpJpYzLHSJdiATftVOEiUC0QmhBW PZT3WV6N+/vVENeB3R+/vpRaWnficTgengI82XsSBXc0WNHNNqs8AGN5T/U61yBx0FAODcd9 pHK5j1u7qK+p+G5lKhjqCZGPk2kahwT9mwhabvFr5DG/ScMRM0fVKODrTXx9f29tXo4AAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAFxcUFJUUFAwNVBccG5jMXAwMHoAAAAAAAAAAAAAAAAA AQQYAJwAuAMDPwECAQABAAAAAABkAAEABwBYAgIAAgBYAgAAAABMZXR0ZXIAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAJQELgBIUCBMYXNlckpldCA4MTAwIFNlcmllcyBQQ0wgNgDAAAAA AAAAAAQAMgCGAYYDeJx1VbtuwzAM3PUZ2QtIlEhK+Y9OdbZ2KFB0yv+jju1apKxD4IUnHo/P 3JVrWD5SyBJDDGn7lXDv5nKaiVa75M1OLZ/2GJbHCbB2nmQBYp4DXBlQVUIePXiKMjh1wYUd RE2AtFbnCqgVBOgJZA8kFIMA1SV91r302kyM7f1uN2Uhy5RrGphUDsA263ZbHja+oBy5VyU1 y0eSBj7DlqETXZz+9WlvTA2399/n9/Pn69PyZlVX172255CqoR6gHjWrmV+xVXdpFwUd5Dyv O7FdHQfAnisASkXB0Vwxap+iPBRNuxm4QS7yqGjZpVOlOESJKLxdd4+A5EvpLm9eQO0C1LsA Lk5tDmQDZBqSaWMyx0iXYgE37VThIlAtEJoQVj2U91lejfv71RDXgd0fv76UWlp34nE4Hp4C PNl7EgV3NFjRzTarPABjeU/1OtcgcdBQDg3HfaRyuY9bu6ivqfhuZSoY6gmRj5NpGocE/ZsI Wm7xa+Qxv0nDETNH1Sjg6018fX9vbV6OAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACEAAA AAAAAADjDAAAUAAACABAAAD//wEAAAAHAFUAbgBrAG4AbwB3AG4A//8BAAgAAAAAAAAAAAAA AP//AQAAAAAA//8AAAIA//8AAAAA//8AAAIA//8AAAAABgAAAEcWkAEAAAICBgMFBAUCAwSH egAgAAAAgAgAAAAAAAAA/wEAAAAAAABUAGkAbQBlAHMAIABOAGUAdwAgAFIAbwBtAGEAbgAA ADUWkAECAAUFAQIBBwYCBQcAAAAAAAAAEAAAAAAAAAAAAAAAgAAAAABTAHkAbQBiAG8AbAAA ADMmkAEAAAILBgQCAgICAgSHegAgAAAAgAgAAAAAAAAA/wEAAAAAAABBAHIAaQBhAGwAAAAz FpABAAACAgYDBQQFAgMEh3oAIAAAAIAIAAAAAAAAAP8BAAAAAAAAVABpAG0AZQBzAAAAOwaQ AQIABQAAAAAAAAAAAAAAAAAAAAAQAAAAAAAAAAAAAACAAAAAAFcAaQBuAGcAZABpAG4AZwBz AAAAPzWQAQAAAgcDCQICBQIEBId6ACAAAACACAAAAAAAAAD/AQAAAAAAAEMAbwB1AHIAaQBl AHIAIABOAGUAdwAAACIABAADAAkYVvwxAgAAaAEAAAAAQJtkpviyZCa3smQmCAAeAAAAswEA ALEJAAABAAQAAAAEAIMAFAAAAAAAAAAAAAAAAQABAAAAAQAAAAAAAAAkA1b8EIQAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAClBsAHeAB4AIABEjAAABAAGQBk AAAAGQAAAOYLAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAAAAAAAAAAAAEygxFW/BCE3wMAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAD//xIAAAAAAGUAQwA6AFwARABvAGMAdQBtAGUAbgB0AHMAIABh AG4AZAAgAFMAZQB0AHQAaQBuAGcAcwBcAGcAcgBpAG0AXABNAHkAIABEAG8AYwB1AG0AZQBu AHQAcwBcAHQAbwBwAGkAYwAgAGYAbwBsAGQAZQByAHMAXABJAFQAVQAgAFMARwAgADQAIAAw ADEAMAA3AFwAdABlAG0AcABsAGEAdABlAFwAbABzACAAVABlAG0AcABsAGEAdABlACAAbQBp AG4AZQAuAGQAbwB0ABMASQBUAFUAIABHAGwAbwBiAGEAbAAgAFQAZQBtAHAAbABhAHQAZQAA AAAAIABBAHUAZwB1AHMAdAAgADEAOQA5ADYALAAgAE4AVAAgAHYAZQByAHMAaQBvAG4AIAAo ADMAMgAgAGIAaQB0ACkACwBUAGgAbwBtAGEAcwAgAEcAcgBpAG0ACgBEAGEAdgBlACAAUwBp AGQAbwByAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/v8AAAUAAgAAAAAA AAAAAAAAAAAAAAAAAQAAAOCFn/L5T2gQq5EIACsns9kwAAAAwAEAABIAAAABAAAAmAAAAAIA AACgAAAAAwAAALwAAAAEAAAAyAAAAAUAAADcAAAABgAAAOgAAAAHAAAAFAEAAAgAAAA0AQAA CQAAAEgBAAASAAAAVAEAAAoAAABwAQAACwAAAHwBAAAMAAAAiAEAAA0AAACUAQAADgAAAKAB AAAPAAAAqAEAABAAAACwAQAAEwAAALgBAAACAAAA5AQAAB4AAAAUAAAASVRVIEdsb2JhbCBU ZW1wbGF0ZQAeAAAAAQAAAABUVSAeAAAADAAAAFRob21hcyBHcmltAB4AAAABAAAAAGhvbR4A AAAhAAAAQXVndXN0IDE5OTYsIE5UIHZlcnNpb24gKDMyIGJpdCkAcm9zHgAAABUAAABscyBU ZW1wbGF0ZSBtaW5lLmRvdABvbiAeAAAACwAAAERhdmUgU2lkb3IAIB4AAAACAAAAOAB2ZR4A AAATAAAATWljcm9zb2Z0IFdvcmQgOS4wAHRAAAAAADTiMAQAAABAAAAAAHrwrA3qwQFAAAAA AGgMpMPnwQFAAAAAACh4MhbqwQEDAAAAAQAAAAMAAACzAQAAAwAAALEJAAADAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP7/AAAFAAIAAAAAAAAAAAAAAAAA AAAAAAEAAAAC1c3VnC4bEJOXCAArLPmuMAAAAAwBAAANAAAAAQAAAHAAAAAPAAAAeAAAAAQA AACEAAAABQAAAIwAAAAGAAAAlAAAABEAAACcAAAAFwAAAKQAAAALAAAArAAAABAAAAC0AAAA EwAAALwAAAAWAAAAxAAAAA0AAADMAAAADAAAAOwAAAACAAAA5AQAAB4AAAAEAAAASVRVAAMA AAAAQgAAAwAAABQAAAADAAAABAAAAAMAAADmCwAAAwAAAO0OCQALAAAAAAAAAAsAAAAAAAAA CwAAAAAAAAALAAAAAAAAAB4QAAABAAAAFAAAAElUVSBHbG9iYWwgVGVtcGxhdGUADBAAAAIA AAAeAAAABgAAAFRpdGxlAAMAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAAAgAAAAMAAAAEAAAABQAAAAYAAAAHAAAA CAAAAAkAAAAKAAAACwAAAAwAAAANAAAADgAAAA8AAAD+////EQAAABIAAAATAAAAFAAAABUA AAAWAAAAFwAAABgAAAAZAAAAGgAAABsAAAAcAAAAHQAAAB4AAAAfAAAAIAAAACEAAAAiAAAA IwAAACQAAAAlAAAAJgAAACcAAAAoAAAAKQAAACoAAAArAAAALAAAAC0AAAAuAAAALwAAADAA AAAxAAAAMgAAADMAAAA0AAAANQAAADYAAAA3AAAAOAAAADkAAAA6AAAAOwAAADwAAAA9AAAA PgAAAD8AAABAAAAA/v///0IAAABDAAAARAAAAEUAAABGAAAARwAAAEgAAAD+////SgAAAEsA AABMAAAATQAAAE4AAABPAAAAUAAAAP7////9////UwAAAP7////+/////v////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// /////////////////////////////////////////////////////////////////////1IA bwBvAHQAIABFAG4AdAByAHkAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAWAAUB//////////8DAAAABgkCAAAAAADAAAAAAAAARgAAAAAAAAAAAAAAAKCZ B1AW6sEBVQAAAIAAAAAAAAAAMQBUAGEAYgBsAGUAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA4AAgD///////////////8AAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAA8WEAAAAAAABXAG8AcgBkAEQAbwBjAHUA bQBlAG4AdAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGgACAQUA AAD//////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA4HgAA AAAAAAUAUwB1AG0AbQBhAHIAeQBJAG4AZgBvAHIAbQBhAHQAaQBvAG4AAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAoAAIBAgAAAAQAAAD/////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAQQAAAAAQAAAAAAAABQBEAG8AYwB1AG0AZQBuAHQAUwB1AG0AbQBhAHIA eQBJAG4AZgBvAHIAbQBhAHQAaQBvAG4AAAAAAAAAAAAAADgAAgH///////////////8AAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABJAAAAABAAAAAAAAABAEMAbwBtAHAA TwBiAGoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA EgACAQEAAAAGAAAA/////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AABqAAAAAAAAAE8AYgBqAGUAYwB0AFAAbwBvAGwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAWAAEA////////////////AAAAAAAAAAAAAAAAAAAAAAAA AACgmQdQFurBAaCZB1AW6sEBAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD///////////// //8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAA /v////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// /////////////////////////////wEA/v8DCgAA/////wYJAgAAAAAAwAAAAAAAAEYYAAAA TWljcm9zb2Z0IFdvcmQgRG9jdW1lbnQACgAAAE1TV29yZERvYwAQAAAAV29yZC5Eb2N1bWVu dC44APQ5snEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA --------------D161BA2097B5F480451BB9CD-- From owner-disman@dorothy.bmc.com Mon Apr 22 16:12:22 2002 Received: from babbler.bmc.com (firebird.bmc.com [198.207.223.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11243 for ; Mon, 22 Apr 2002 16:12:21 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g3MKEri25472; Mon, 22 Apr 2002 15:14:57 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id NAA14558 for disman-list; Mon, 22 Apr 2002 13:08:49 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id NAA14552; Mon, 22 Apr 2002 13:08:45 -0700 (PDT) Received: from mx-us-hou-2-int.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id g3MK6Wn09899; Mon, 22 Apr 2002 15:06:32 -0500 (CDT) Received: from ihemail1.firewall.lucent.com (ihemail1.lucent.com [192.11.222.161]) by mx-us-hou-2-int.bmc.com (Postfix) with SMTP id 86AA01FF029; Mon, 22 Apr 2002 15:10:19 -0500 (CDT) Received: from nj7460exch002h.wins.lucent.com (h135-17-42-35.lucent.com [135.17.42.35]) by ihemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g3MKA0B23163; Mon, 22 Apr 2002 16:10:00 -0400 (EDT) Received: by nj7460exch002h.ho.lucent.com with Internet Mail Service (5.5.2653.19) id <20N5XCST>; Mon, 22 Apr 2002 16:09:59 -0400 Message-ID: <2E12619580C0D1118C6400805F9F4C950D7CEFE5@nj7460exch001u.ho.lucent.com> From: "Lam, Hing-Kam (Kam)" To: "'Randy Presuhn'" , disman@dorothy.bmc.com Subject: RE: Progressing the Condition/ARC MIB Date: Mon, 22 Apr 2002 16:09:53 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list Randy, Update to the ARC is now available. It follows the proposal to narrow the scope of the document to ARC only. It is done by extracting the ARC mib portion from draft-ietf-disman-conditionmib-02.txt. Before I upload it, I have a question that need you guidance. What should the title and file name of this document be? In order not to be confused with the condition mib portion in draft-ietf-disman-conditionmib-02.txt, should the updated ARC document be "ARC MIB" and with file name draft-ietf-disman-arcmib-00.txt ? Regards, Kam > -----Original Message----- > From: Randy Presuhn [mailto:rpresuhn@dorothy.bmc.com] > Sent: Monday, March 18, 2002 3:50 PM > To: disman@dorothy.bmc.com > Subject: RE: Progressing the Condition/ARC MIB > > > Hi - > > > Message-ID: > <2E12619580C0D1118C6400805F9F4C950D7CEE3E@nj7460exch001u.ho.lu > cent.com> > > From: "Lam, Hing-Kam (Kam)" > > To: "'Randy Presuhn'" , > > atommib@research.telcordia.com, disman@dorothy.bmc.com > > Subject: RE: Progressing the Condition/ARC MIB > > Date: Thu, 7 Feb 2002 09:21:18 -0500 > ... > > Since the Optical Interface MIB is on AToMMIB WG Last Call > review now, I > > hope the ARC mib part can move forward quick too. If the > "relationship" > > issue cannot be resolved soon, may be an alternative is to split the > > condition/arc mib I-D into two documents, one for ARC and > one for Condition. > > In the way, the Condition mib can progress in its own path. > > > > Any comments or suggestion? > ... > > I've seen no objections to the proposal to narrow the scope > of this document to ARC. My only question is when the next > update to ARC (draft-ietf-disman-conditionmib-02.txt) will > be available. > > Once it's completed, I'd be willing to entertain discussion > of whether the condition part is still of interest. > > ------------------------------------------------------ > Randy Presuhn BMC Software, Inc. 1-3141 > randy_presuhn@bmc.com 2141 North First Street > Tel: +1 408 546-1006 San Jose, California 95131 USA > ------------------------------------------------------ > My opinions and BMC's are independent variables. > ------------------------------------------------------ > From owner-disman@dorothy.bmc.com Mon Apr 22 16:29:56 2002 Received: from babbler.bmc.com (firebird.bmc.com [198.207.223.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11900 for ; Mon, 22 Apr 2002 16:29:56 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g3MKWZU01067; Mon, 22 Apr 2002 15:32:36 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id NAA14732 for disman-list; Mon, 22 Apr 2002 13:27:00 -0700 (PDT) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id NAA14726 for disman@dorothy.bmc.com; Mon, 22 Apr 2002 13:26:56 -0700 (PDT) Date: Mon, 22 Apr 2002 13:26:56 -0700 (PDT) From: Randy Presuhn Message-Id: <200204222026.NAA14726@dorothy.bmc.com> To: disman@dorothy.bmc.com Subject: RE: Progressing the Condition/ARC 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: <2E12619580C0D1118C6400805F9F4C950D7CEFE5@nj7460exch001u.ho.lucent.com> > From: "Lam, Hing-Kam (Kam)" > To: "'Randy Presuhn'" , disman@dorothy.bmc.com > Subject: RE: Progressing the Condition/ARC MIB > Date: Mon, 22 Apr 2002 16:09:53 -0400 > List-Id: IETF disman Working Group mailing list ... > Update to the ARC is now available. It follows the proposal to narrow the > scope of the document to ARC only. It is done by extracting the ARC mib > portion from draft-ietf-disman-conditionmib-02.txt. > > Before I upload it, I have a question that need you guidance. What should > the title and file name of this document be? > In order not to be confused with the condition mib portion in > draft-ietf-disman-conditionmib-02.txt, should the updated ARC document be > "ARC MIB" and with file name draft-ietf-disman-arcmib-00.txt ? ... The file name should be draft-ietf-disman-conditionmib-02.txt (my files show draft-ietf-disman-conditionmib-01.txt as the latest thing published) and the title should be "Alarm Report Control MIB". When you send it to internet-drafts@ietf.org, please note the title change and provide an updated abstract for the announcement. I do NOT want to start another document series. ------------------------------------------------------ Randy Presuhn BMC Software, Inc. 1-3141 randy_presuhn@bmc.com 2141 North First Street Tel: +1 408 546-1006 San José, California 95131 USA ------------------------------------------------------ My opinions and BMC's are independent variables. ------------------------------------------------------ From owner-disman@dorothy.bmc.com Mon Apr 22 16:48:27 2002 Received: from babbler.bmc.com (camaro.bmc.com [198.207.223.231]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12474 for ; Mon, 22 Apr 2002 16:48:27 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g3MKp7l04025; Mon, 22 Apr 2002 15:51:07 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id NAA14798 for disman-list; Mon, 22 Apr 2002 13:45:35 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id NAA14793 for ; Mon, 22 Apr 2002 13:45:31 -0700 (PDT) Received: from mx-us-hou-1-int.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id g3MKhHO29587 for ; Mon, 22 Apr 2002 15:43:17 -0500 (CDT) Received: from harrier.prod.itd.earthlink.net (unknown [207.217.120.12]) by mx-us-hou-1-int.bmc.com (Postfix) with SMTP id B919B20F016 for ; Mon, 22 Apr 2002 15:46:50 -0500 (CDT) Received: from 1cust232.tnt4.minneapolis.mn.da.uu.net ([67.251.180.232] helo=merkita.com) by harrier.prod.itd.earthlink.net with esmtp (Exim 3.33 #2) id 16zkhi-0002LU-00; Mon, 22 Apr 2002 13:46:30 -0700 Message-ID: <3CC47607.CEDE3EAD@merkita.com> Date: Mon, 22 Apr 2002 15:43:51 -0500 From: Tammy Ferris Reply-To: tferris@merkita.com X-Mailer: Mozilla 4.75 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Romascanu, Dan (Dan)" Cc: disman@dorothy.bmc.com Subject: Re: Alarm MIB WG last call References: 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 Dan, See my comments below. Tammy "Romascanu, Dan (Dan)" wrote: > OK, I think that I got now your issue. Getting back to your proposal: > > > > > I proposed a fix of having 2 timestamps in the active alarm > > > > table rather than one : One time stamp (the time the alarm > > > > was reported) be the one to use for indexing and a second > > > > time stamp (the time the error occured). > > Two things need to be clarified here: > > - instead of saying 'the alarm was reported' we need to say 'the alarm was reported or retrieved', in order to accommodate agent implementations that are based on a polling model rather than asynchronous reports from an other subsystem > - need to define the behavior of an agent an agent that cannot retrieve accurately the time the error occurred. I am not sure how to do this. We might need to add another variable that describes whether this capability exists in the system, or invent another TC like DateAndTimeOrZero. *** Does this reply indicate that you prefer two timestamps over some other solution to fix this problem? Instead of saying 'the alarm was reported' or 'the alarm was reported or retrieved', how about 'the error information was populated in the alarm table'? I say this because I think maybe the notion of time retrieved would be confusing in a multi-manager environment. For systems that cannot either produce and/or store error occurance timestamps, how about setting the time the error occurred equal to the time the alarm information was added to the alarm table? Tammy > > > Regards, > > Dan > > > -----Original Message----- > > From: Tammy Ferris [mailto:tferris@merkita.com] > > Sent: Friday, April 19, 2002 2:37 AM > > To: Romascanu, Dan (Dan); disman@dorothy.bmc.com > > Subject: Re: Alarm MIB WG last call > > > > > > Dan, > > re your following comments: > > **** > > I agree that the ARC MIB should not break the Alarm MIB. I > > fail to see how it does break it. On the other hand we should > > not impose implementation assumptions on the Alarm MIB > > because of requirements to fit in the ARC MIB. > > > > > I proposed a fix of having 2 timestamps in the active alarm > > > table rather than one : One time stamp (the time the alarm > > > was reported) be the one to use for indexing and a second > > > time stamp (the time the error occurred). > > > > This is exactly the type of requirement that looks artificial > > for some implementations. It implies the capability of having > > both accurate values registered by an Alarm MIB agent. I > > understand the requirement, but this looks to me beyond the > > goal of the Alarm MIB. > > > > ***** > > I am not imposing a requirement for 2 timestamps. And I > > don't understand your point "On the other hand we should not > > impose implementation assumptions on the Alarm MIB because of > > requirements to fit in the ARC MIB." > > > > I see the fundamental problem as follows: > > The alarm model supported by the Alarm MIB appears to assume > > a requirement to be able to query for alarms that have been > > added to the active alarm table subsequent to the last > > manager query so that the manager does not have to read the > > whole table to get updated. > > > > The Alarm MIB seems to propose to meet this requirement by > > indexing on the timestamp for the time the error occurred. > > > > In analyzing this in combination with ARC, it can be seen > > that the currently proposed solution does not meet the > > original requirement as intended. This is because the > > declaration of the alarm does not always coincide with the > > occurance of the error. > > > > This proposed solution does not work for certain ARCed > > errors. Even without ARC, I think it is a bit risky to > > assume that agent implementations don't support other ways of > > suppressing alarm declarations that could have the same > > effect. For example, an error with a long integration > > period. > > > > To complicate things further (even if you may consider this > > outside scope I think it helps illustrate the point), what > > about systems that support alarm escalation and > > de-escalation. Using this MIB, such a system may indicate a > > clear for a minor condition followed but a raise for > > the same condition but only now with the severity code of > > major yet the same error timestamp. In this scenario, will a > > typical management system using this MIB, miss this updated > > information? > > > > I understand that the time the error occurred does help to > > uniquely identify a specific occurrence of an alarm and I > > also understand that there might be cases where it is nice to > > have the table sorted in time of occurrence order, but I am > > worried that the management application may > > miss critical alarm information by assuming that it can rely > > upon looking only at those alarms information with time of > > occurrence happening after xxx time. > > > > I proposed two timestamps as a possible MIB solution to > > discuss to meet a perceived alarm management requirement not > > as a requirement unto itself. If you have a better solution > > to fixing this problem, I am open to that. Maybe requiring > > that strictly monotonically increasing > > identifiers have to be unique within a table and dropping the > > time of error occurrence from the index? > > > > I don't understand how my proposal is counter to the goal of > > the Alarm MIB. .Maybe it would be worth restating the goal of > > the Alarm MIB. What do you think is the goal of the Alarm > > MIB? How is what I was proposing counter to that? > > > > Regards, > > Tammy > > > > Tammy Lehtinen Ferris > > tferris@merkita.com > > +1 (763)557-1681 > > Merkita Incorporated > > www.merkita.com > > > > > > > > > > > > "Romascanu, Dan (Dan)" wrote: > > > > > Tammy, > > > See below. > > > > > > > > > > > Your response here really surprises me! If this Alarm MIB > > > > work disregards ITU requirements than why are there so many > > > > e-mails discussing support for ITU alarm codes? Just forget > > > > about that then and make up your own. > > > > > > > The ITU Alarm MIB defines information specific to the Alarm > > model defined in ITU M.3100, X.733, X.736. > > > > > > This is actually a quote from the draft. It augments the > > basic Alarm MIB. The problem with the current discussion > > about probableCause is that we tried to exceed the initial > > goal and come with a more generic probableCause macro. Still > > the ITU alarms have priority in this context. > > > > > > > I never have pushed to make the ARC MIB mandatory. But, I > > > > believe if an application requires both the ARC MIB and the > > > > Alarm MIB then the addition of the ARC MIB should not break > > > > the Alarm MIB. The way the Alarm MIB is designed currently, > > > > addition of the ARC MIB breaks it. > > > > > > > I agree that the ARC MIB should not break the Alarm MIB. I > > fail to see how it does break it. On the other hand we should > > not impose implementation assumptions on the Alarm MIB > > because of requirements to fit in the ARC MIB. > > > > > > > I proposed a fix of having 2 timestamps in the active alarm > > > > table rather than one : One time stamp (the time the alarm > > > > was reported) be the one to use for indexing and a second > > > > time stamp (the time the error occured). > > > > > > This is exactly the type of requirement that looks > > artificial for some implementations. It implies the > > capability of having both accurate values registered by an > > Alarm MIB agent. I understand the requirement, but this looks > > to me beyond the goal of the Alarm MIB. > > > > > > Regards, > > > > > > Dan > > > > > > > From owner-disman@dorothy.bmc.com Mon Apr 22 17:01:52 2002 Received: from babbler.bmc.com (firebird.bmc.com [198.207.223.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13012 for ; Mon, 22 Apr 2002 17:01:51 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g3ML4W409177; Mon, 22 Apr 2002 16:04:32 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id NAA14910 for disman-list; Mon, 22 Apr 2002 13:59:00 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id NAA14903; Mon, 22 Apr 2002 13:58:56 -0700 (PDT) Received: from mx-us-hou-2-int.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id g3MKuhu08373; Mon, 22 Apr 2002 15:56:43 -0500 (CDT) Received: from harrier.prod.itd.earthlink.net (harrier.mail.pas.earthlink.net [207.217.120.12]) by mx-us-hou-2-int.bmc.com (Postfix) with SMTP id DE2521FF055; Mon, 22 Apr 2002 16:00:15 -0500 (CDT) Received: from 1cust232.tnt4.minneapolis.mn.da.uu.net ([67.251.180.232] helo=merkita.com) by harrier.prod.itd.earthlink.net with esmtp (Exim 3.33 #2) id 16zkud-0005OU-00; Mon, 22 Apr 2002 13:59:56 -0700 Message-ID: <3CC47928.DF299A96@merkita.com> Date: Mon, 22 Apr 2002 15:57:12 -0500 From: Tammy Ferris Reply-To: tferris@merkita.com X-Mailer: Mozilla 4.75 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Randy Presuhn Cc: disman@dorothy.bmc.com Subject: Re: Alarm MIB WG last call References: <200204200106.SAA05654@dorothy.bmc.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list Content-Transfer-Encoding: 8bit Randy, If I understand your proposal correctly, it seems to me also that 1) meets the identified need better and provides a cleaner separation of the alarm and condition (or is it now called error?) MIBs. Tammy Randy Presuhn wrote: > Hi - > > > Message-ID: <3CBF5883.E149F7E8@merkita.com> > > Date: Thu, 18 Apr 2002 18:36:36 -0500 > > From: Tammy Ferris > > To: "Romascanu, Dan (Dan)" , disman@dorothy.bmc.com > > Subject: Re: Alarm MIB WG last call > > References: > ... > > > I proposed a fix of having 2 timestamps in the active alarm > > > table rather than one : One time stamp (the time the alarm > > > was reported) be the one to use for indexing and a second > > > time stamp (the time the error occurred). > ... > (much discussion / elaboration deleted) > > I'm thinking about this problem from an implementation > perspective, specifically with an AgentX bias. Now I > know that we don't want to *require* the use of agentx, > but the pervasiveness of subagent technologies requires > us to at least give some thought to its implications. > > If we would like to have both timestamps in the active > alarm table, where would the values come from? If we rely > on "in-band" information in AgentX, we are left with few > reasonable choices: > > 1) the subagent could supply a sysUpTime.0 varbind > reflecting the time the condition occurred, and > the Active Alarm MIB implementation could use its > local time to populate the "reported" field. > > 2) the subagent could supply a sysUpTime.0 varbind > reflecting the time the condition was reported, and > add another variable binding to reflect when the > condition occurred. > > Though I personally prefer (1) (and would like to see > appropriate language in the condition mib), both of these > alternatives have a really interesting property: the > information recording when the condition was detected ends > up in the alarmActiveVariableTable, though perhaps not in > the most convenient form imaginable. > > Am I missing something here? > > ------------------------------------------------------ > Randy Presuhn BMC Software, Inc. 1-3141 > randy_presuhn@bmc.com 2141 North First Street > Tel: +1 408 546-1006 San José, California 95131 USA > ------------------------------------------------------ > My opinions and BMC's are independent variables. > ------------------------------------------------------ From owner-disman@dorothy.bmc.com Mon Apr 22 17:20:45 2002 Received: from babbler.bmc.com (firebird.bmc.com [198.207.223.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13647 for ; Mon, 22 Apr 2002 17:20:45 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g3MLNPr12975; Mon, 22 Apr 2002 16:23:25 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id OAA15028 for disman-list; Mon, 22 Apr 2002 14:17:30 -0700 (PDT) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id OAA15022 for disman@dorothy.bmc.com; Mon, 22 Apr 2002 14:17:26 -0700 (PDT) Date: Mon, 22 Apr 2002 14:17:26 -0700 (PDT) From: Randy Presuhn Message-Id: <200204222117.OAA15022@dorothy.bmc.com> To: disman@dorothy.bmc.com Subject: Re: Alarm MIB WG last call 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: <3CC47607.CEDE3EAD@merkita.com> > Date: Mon, 22 Apr 2002 15:43:51 -0500 > From: Tammy Ferris > To: "Romascanu, Dan (Dan)" > Cc: disman@dorothy.bmc.com > Subject: Re: Alarm MIB WG last call > References: ... > Does this reply indicate that you prefer two timestamps > over some other solution to fix this problem? I can't speak for Dan, but my point was that the information recording when the condition was detected would already be present in the variable bindings, so that there's no need for a second object. ... > For systems that cannot either produce and/or store error occurance > timestamps, how about setting the time the error occurred equal to > the time the alarm information was added to the alarm table? ... Why would we need to support such a beast? A notification by definition includes a timestamp. Take a look at the agentx protocol spec. Infrastructure lacking this information is arguably broken. ------------------------------------------------------ Randy Presuhn BMC Software, Inc. 1-3141 randy_presuhn@bmc.com 2141 North First Street Tel: +1 408 546-1006 San José, California 95131 USA ------------------------------------------------------ My opinions and BMC's are independent variables. ------------------------------------------------------ From owner-disman@dorothy.bmc.com Mon Apr 22 18:40:35 2002 Received: from babbler.bmc.com (camaro.bmc.com [198.207.223.231]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16956 for ; Mon, 22 Apr 2002 18:40:35 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g3MMh9B27128; Mon, 22 Apr 2002 17:43:09 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id PAA16070 for disman-list; Mon, 22 Apr 2002 15:37:11 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id PAA16064; Mon, 22 Apr 2002 15:37:07 -0700 (PDT) Received: from mx-us-hou-2-int.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id g3MMYrT28841; Mon, 22 Apr 2002 17:34:53 -0500 (CDT) Received: from flamingo.mail.pas.earthlink.net (flamingo.mail.pas.earthlink.net [207.217.120.232]) by mx-us-hou-2-int.bmc.com (Postfix) with SMTP id 82A0E1FF049; Mon, 22 Apr 2002 17:38:36 -0500 (CDT) Received: from 1cust241.tnt3.minneapolis.mn.da.uu.net ([67.251.161.241] helo=merkita.com) by flamingo.mail.pas.earthlink.net with esmtp (Exim 3.33 #2) id 16zmRv-0005gG-00; Mon, 22 Apr 2002 15:38:20 -0700 Message-ID: <3CC49040.C954E9FF@merkita.com> Date: Mon, 22 Apr 2002 17:35:44 -0500 From: Tammy Ferris Reply-To: tferris@merkita.com X-Mailer: Mozilla 4.75 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Randy Presuhn Cc: disman@dorothy.bmc.com Subject: Re: Alarm MIB WG last call References: <200204222117.OAA15022@dorothy.bmc.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list Content-Transfer-Encoding: 8bit Randy, See my comments below. Tammy Randy Presuhn wrote: > Hi - > > > Message-ID: <3CC47607.CEDE3EAD@merkita.com> > > Date: Mon, 22 Apr 2002 15:43:51 -0500 > > From: Tammy Ferris > > To: "Romascanu, Dan (Dan)" > > Cc: disman@dorothy.bmc.com > > Subject: Re: Alarm MIB WG last call > > References: > ... > > Does this reply indicate that you prefer two timestamps > > over some other solution to fix this problem? > > I can't speak for Dan, but my point was that the information > recording when the condition was detected would already be present > in the variable bindings, so that there's no need for a second object. I apologize that I don't understand your point. Are you saying that the timestamp used for the index should be the 'time that the error information was added to the alarm table' and that the 'time the error occured' would be in the variable bindings? Or are you saying that there doesn't need to be a timestamp for the time the error information was added into the active alarm table? > > > ... > > For systems that cannot either produce and/or store error occurance > > timestamps, how about setting the time the error occurred equal to > > the time the alarm information was added to the alarm table? > ... > > Why would we need to support such a beast? A notification by > definition includes a timestamp. Take a look at the agentx > protocol spec. Infrastructure lacking this information is > arguably broken. Clarify for me - what I think you are saying here is that all 'subagents' and 'agents' have the capability (memory and clock) to support the recording and reporting the time of the occurance of every error. Is that correct? If so, then I agree that Dan should not worry about what to do if such capability does not exist. > > > ------------------------------------------------------ > Randy Presuhn BMC Software, Inc. 1-3141 > randy_presuhn@bmc.com 2141 North First Street > Tel: +1 408 546-1006 San José, California 95131 USA > ------------------------------------------------------ > My opinions and BMC's are independent variables. > ------------------------------------------------------ From owner-disman@dorothy.bmc.com Mon Apr 22 18:50:17 2002 Received: from babbler.bmc.com (firebird.bmc.com [198.207.223.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17202 for ; Mon, 22 Apr 2002 18:50:16 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g3MMqtD28348; Mon, 22 Apr 2002 17:52:55 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id PAA16120 for disman-list; Mon, 22 Apr 2002 15:47:24 -0700 (PDT) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id PAA16114 for disman@dorothy.bmc.com; Mon, 22 Apr 2002 15:47:20 -0700 (PDT) Date: Mon, 22 Apr 2002 15:47:20 -0700 (PDT) From: Randy Presuhn Message-Id: <200204222247.PAA16114@dorothy.bmc.com> To: disman@dorothy.bmc.com Subject: Re: Alarm MIB WG last call 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 - > Message-ID: <3CC49040.C954E9FF@merkita.com> > Date: Mon, 22 Apr 2002 17:35:44 -0500 > From: Tammy Ferris > To: Randy Presuhn > Cc: disman@dorothy.bmc.com > Subject: Re: Alarm MIB WG last call > References: <200204222117.OAA15022@dorothy.bmc.com> ... > > I can't speak for Dan, but my point was that the information > > recording when the condition was detected would already be present > > in the variable bindings, so that there's no need for a second object. > > I apologize that I don't understand your point. Are you saying that the timestamp used > for the index should be the 'time that the error information was added to the alarm table' > and that the 'time the error occured' would be in the variable bindings? Or are you This makes the most sense to me. > saying that there doesn't need to be a timestamp for the time the error information was > added into the active alarm table? No. I think both pieces of information are interesting. I'm just saying that we don't need to objects, because the timestamp indicating when the error occured will be in the variable bindings anyway. ... > > > For systems that cannot either produce and/or store error occurance > > > timestamps, how about setting the time the error occurred equal to > > > the time the alarm information was added to the alarm table? > > ... > > > > Why would we need to support such a beast? A notification by > > definition includes a timestamp. Take a look at the agentx > > protocol spec. Infrastructure lacking this information is > > arguably broken. > > Clarify for me - what I think you are saying here is that all 'subagents' and 'agents' > have the capability (memory and clock) to support the recording and reporting the time of > the occurance of every error. Is that correct? If so, then I agree that Dan should not > worry about what to do if such capability does not exist. ... Just think about it from an AgentX perspective: the protocol is specifically designed so that subagents will know their sysUpTime, and the text on notifications specifically provides for the communication of the time stamp. If the subagent omits the sysUpTime variable binding, the elements of procedure specifically provide for the master agent to provide the appropriate one for the context, which would be a perfectly reasonable fallback for an active alarm MIB to use when the "real" time of the failure isn't known. ------------------------------------------------------ Randy Presuhn BMC Software, Inc. 1-3141 randy_presuhn@bmc.com 2141 North First Street Tel: +1 408 546-1006 San José, California 95131 USA ------------------------------------------------------ My opinions and BMC's are independent variables. ------------------------------------------------------ From owner-disman@dorothy.bmc.com Mon Apr 22 19:28:05 2002 Received: from babbler.bmc.com (firebird.bmc.com [198.207.223.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17863 for ; Mon, 22 Apr 2002 19:28:04 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g3MNUhW03153; Mon, 22 Apr 2002 18:30:43 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id QAA17246 for disman-list; Mon, 22 Apr 2002 16:25:11 -0700 (PDT) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id QAA17240 for disman@dorothy.bmc.com; Mon, 22 Apr 2002 16:25:08 -0700 (PDT) Date: Mon, 22 Apr 2002 16:25:08 -0700 (PDT) From: Randy Presuhn Message-Id: <200204222325.QAA17240@dorothy.bmc.com> To: disman@dorothy.bmc.com Subject: Re: FW: Probable Cause 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: <3CC435D3.EF73C43C@americasm01.nt.com> > Date: Mon, 22 Apr 2002 12:09:55 -0400 > From: "Dave Sidor" > To: "Wijnen, Bert (Bert)" > Cc: Randy Presuhn , disman@dorothy.bmc.com, > Randy Bush , "*Matthews, Dave" , > "*Grim, Tom" , > "*IETF, communication statements" > Subject: Re: FW: Probable Cause > References: ... > TITLE: Additional input regarding the use of M.3100 probable causes for > the ITU Alarm MIB ... > 3) We have noted in section 5.2 that you have specified an > IANAItuProbableCause textual convention apparently dedicated to the > ITU-T probable causes and support that separation from any other > probable cause asssignments. To ensure that separation, we recommend > that the first paragraph of section 5.2 be replaced with the following > text: > > "Values of IANAItuProbableCause can only be given out if they correspond > to ITU probable causes semantics present in ITU-T Recommendations and > are agreed to by the disman working group." > > We believe this text reflects the fact that this textual convention is > limited to representing the ITU semantics while at the same time > identifying the IETF as the owner of the alarm MIB. Other textual > conventions would be presumably required to define the semantics and > number assignments of other probable causes. ... I'd like to get a sense of the working group on what the scope of "probableCause" should be: a) ITU's M.3100's probable causes b) ITU's X.733's probable causes c) ITU's future probable causes d) DMTF's CIM's probable causes e) DMTF's future probable causes f) IETF's future probable causes Based on the history of this work, (a), (b), and (c) make sense in the architecture which separates "generic" alarm management from "specific" models, such as ITU's. As the document is currently constituted, we're closer to having all of (a) through (f). If this is the direction we're headed, then it may make sense to re-label some items to reflect the broader scope, while retaining the references that make it clear that supporting the full range of ITU probable cause semantics is an objective. ------------------------------------------------------ Randy Presuhn BMC Software, Inc. 1-3141 randy_presuhn@bmc.com 2141 North First Street Tel: +1 408 546-1006 San José, California 95131 USA ------------------------------------------------------ My opinions and BMC's are independent variables. ------------------------------------------------------ From owner-disman@dorothy.bmc.com Mon Apr 22 19:33:11 2002 Received: from babbler.bmc.com (firebird.bmc.com [198.207.223.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17991 for ; Mon, 22 Apr 2002 19:33:11 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g3MNZoU03631; Mon, 22 Apr 2002 18:35:50 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id QAA17307 for disman-list; Mon, 22 Apr 2002 16:30:20 -0700 (PDT) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id QAA17301 for disman@dorothy.bmc.com; Mon, 22 Apr 2002 16:30:16 -0700 (PDT) Date: Mon, 22 Apr 2002 16:30:16 -0700 (PDT) From: Randy Presuhn Message-Id: <200204222330.QAA17301@dorothy.bmc.com> To: disman@dorothy.bmc.com Subject: Re: event mib operating on ranges 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 - > Message-ID: <3CBF1BE5.1FC550D7@cisco.com> > Date: Thu, 18 Apr 2002 12:17:57 -0700 > From: Ramanathan Kavasseri > To: Randy Presuhn > Cc: disman@dorothy.bmc.com > Subject: Re: event mib operating on ranges > References: <200204180015.RAA13992@dorothy.bmc.com> ... > The problem I'd mentioned was: > 1. The Event MIB does great at wildcarding one ports, > or ALL ports. It's hard to apply a template to a subset > of all the existing ports on a device. We had to come up with > a separate table in a proprietary MIB for this. This MIB > had a table of templates, and another template-to-port mapping > table. > > Each template could specify what object to watch for/threshold. ... Based on this experience, would you recommend changes to the Event MIB specification, currently at Proposed? ------------------------------------------------------ Randy Presuhn BMC Software, Inc. 1-3141 randy_presuhn@bmc.com 2141 North First Street Tel: +1 408 546-1006 San José, California 95131 USA ------------------------------------------------------ My opinions and BMC's are independent variables. ------------------------------------------------------ From owner-disman@dorothy.bmc.com Mon Apr 22 20:11:16 2002 Received: from babbler.bmc.com (camaro.bmc.com [198.207.223.231]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18895 for ; Mon, 22 Apr 2002 20:11:15 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g3N0Dsk07191; Mon, 22 Apr 2002 19:13:54 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id RAA17518 for disman-list; Mon, 22 Apr 2002 17:08:07 -0700 (PDT) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id RAA17512 for disman@dorothy.bmc.com; Mon, 22 Apr 2002 17:08:03 -0700 (PDT) Date: Mon, 22 Apr 2002 17:08:03 -0700 (PDT) From: Randy Presuhn Message-Id: <200204230008.RAA17512@dorothy.bmc.com> To: disman@dorothy.bmc.com Subject: RE: Pairing instances 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 - > content-class: urn:content-classes:message > Subject: RE: Pairing instances > Date: Thu, 18 Apr 2002 16:07:41 +0300 > Message-ID: > From: "Romascanu, Dan (Dan)" > To: "David T. Perkins" , ... > Do you think that there is need for > more explanation, or maybe do you think that an alarm may be > triggered on interface 1 and cleared on interface 9? (I do > not think this is a practical case) ... Consider the case where the ifStackTable is used to associate DS0s with their underlying T1. For something on interface 1 to potentially clear the alarms on interfaces 2 through 25 does not seem far-fetched. However, do we see this as being within the scope of this MIB? ------------------------------------------------------ Randy Presuhn BMC Software, Inc. 1-3141 randy_presuhn@bmc.com 2141 North First Street Tel: +1 408 546-1006 San José, California 95131 USA ------------------------------------------------------ My opinions and BMC's are independent variables. ------------------------------------------------------ From owner-disman@dorothy.bmc.com Mon Apr 22 20:31:24 2002 Received: from babbler.bmc.com (firebird.bmc.com [198.207.223.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19157 for ; Mon, 22 Apr 2002 20:31:24 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g3N0Y2409206; Mon, 22 Apr 2002 19:34:03 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id RAA17611 for disman-list; Mon, 22 Apr 2002 17:28:27 -0700 (PDT) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id RAA17603 for disman@dorothy.bmc.com; Mon, 22 Apr 2002 17:28:23 -0700 (PDT) Date: Mon, 22 Apr 2002 17:28:23 -0700 (PDT) From: Randy Presuhn Message-Id: <200204230028.RAA17603@dorothy.bmc.com> To: disman@dorothy.bmc.com Subject: RE: Problems with Variables table 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 - > Subject: RE: Problems with Variables table > Date: Thu, 18 Apr 2002 19:49:16 +0300 > Message-ID: > From: "Romascanu, Dan (Dan)" > To: "David T. Perkins" , ... > > Also note that it is not clear whether the VarBind table includes the > > two entries for sysUpTime and snmpTrapOID. (Of course the value for > > these two are redundant. So I would say not to include them. However, > > it is not clear if they are or are not included). > > > They are not. ... As a technical contributor, I think we do indeed need sysUpTime, for the reasons mentioned on the thread regarding the distinction between the time when the problem was detected and the time when the active alarm came into being, unless we break that information into a separate object. ------------------------------------------------------ Randy Presuhn BMC Software, Inc. 1-3141 randy_presuhn@bmc.com 2141 North First Street Tel: +1 408 546-1006 San José, California 95131 USA ------------------------------------------------------ My opinions and BMC's are independent variables. ------------------------------------------------------ From owner-disman@dorothy.bmc.com Mon Apr 22 20:38:47 2002 Received: from babbler.bmc.com (camaro.bmc.com [198.207.223.231]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19236 for ; Mon, 22 Apr 2002 20:38:47 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g3N0fN509913; Mon, 22 Apr 2002 19:41:23 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id RAA17644 for disman-list; Mon, 22 Apr 2002 17:35:53 -0700 (PDT) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id RAA17637 for disman@dorothy.bmc.com; Mon, 22 Apr 2002 17:35:48 -0700 (PDT) Date: Mon, 22 Apr 2002 17:35:48 -0700 (PDT) From: Randy Presuhn Message-Id: <200204230035.RAA17637@dorothy.bmc.com> To: disman@dorothy.bmc.com Subject: Re: Description for object alarmModelVarbindIndex 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: <5.0.2.1.2.20020417223723.02a3e760@mail4.bayarea.net> > Date: Wed, 17 Apr 2002 22:47:32 -0700 > To: disman@dorothy.bmc.com > From: "David T. Perkins" > Subject: Description for object alarmModelVarbindIndex ... > In the 06 draft of the alarm MIB, the text in the DESCRIPTION > clause for object alarmModelVarbindIndex needs to be corrected. > It confuses the SNMP operations with the SMI. It currently reads... > > "The index into the varbind listing of the notification > indicated by alarmModelNotificationId which helps > signal that the given alarm has changed state. > If there is no applicable varbind, the value of this > object MUST be zero. > > For SNMPv1 traps, a 1 indicates the first varbind. For > NOTIFICATION-TYPE, a 1 indicates the first real varbind > after the required varbinds of sysUptime and SNMPTrapOID." > > And should be changed to... > "The index into the varbind listing of the notification > indicated by alarmModelNotificationId which helps > signal that the given alarm has changed state. > If there is no applicable varbind, the value of this > object MUST be zero. > > For v1Traps, a 1 indicates the first varbind. For > v2Traps and Informs, a 1 indicates the first varbind > after the required varbinds of sysUptime and SNMPTrapOID." ... As a technical contributor, I agree with the rationale, but would prefer a slightly different solution. Specifically, I'd like to see notifications, regardless of the protocols (remember, these things may have "arrived" over SMUX, AgentX, or any number of proprietary mechanisms) treated *as though* they were v2, in accordance with the philosophy/rules in RFC 2576. I think this would ultimately simplify things for both the manager and for the agent infrastructure, since the same transformations are necessary for RFC 2573 notification forwarding / filtering and for access control to work anyway. ------------------------------------------------------ Randy Presuhn BMC Software, Inc. 1-3141 randy_presuhn@bmc.com 2141 North First Street Tel: +1 408 546-1006 San José, California 95131 USA ------------------------------------------------------ My opinions and BMC's are independent variables. ------------------------------------------------------ From owner-disman@dorothy.bmc.com Mon Apr 22 20:41:15 2002 Received: from babbler.bmc.com (camaro.bmc.com [198.207.223.231]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19260 for ; Mon, 22 Apr 2002 20:41:15 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g3N0hq310176; Mon, 22 Apr 2002 19:43:52 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id RAA17661 for disman-list; Mon, 22 Apr 2002 17:38:17 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id RAA17655; Mon, 22 Apr 2002 17:38:13 -0700 (PDT) Received: from mx-us-hou-2-int.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id g3N0ZxY18484; Mon, 22 Apr 2002 19:35:59 -0500 (CDT) Received: from riverstonenet.com (mail.riverstonenet.com [63.113.148.10]) by mx-us-hou-2-int.bmc.com (Postfix) with SMTP id 2F6031FF049; Mon, 22 Apr 2002 19:39:45 -0500 (CDT) Received: from dperkins-nb2.dsperkins.com by riverstonenet.com (8.9.3+Sun/SMI-SVR4-Yago) id RAA20493; Mon, 22 Apr 2002 17:39:33 -0700 (PDT) Message-Id: <5.0.2.1.2.20020422172156.03b39bd0@mail4.bayarea.net> X-Sender: dperkins@mail4.bayarea.net X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Mon, 22 Apr 2002 17:39:12 -0700 To: Randy Presuhn , disman@dorothy.bmc.com From: "David T. Perkins" Subject: RE: Pairing instances In-Reply-To: <200204230008.RAA17512@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 HI, The example below is interesting, but I'm talking about something really basic. Lets assume we are using unique notifications for "state transitions". Then the model table (alarmModelTable) maps notifications to "next state" severity levels of alarms. Assume the value for alarmListName is the zero length string. Say, we have alarm "A", that is identified with value 23 as specified for index object alarmModelIndex, and has the following assignments for values for perceived severity and notifications: clear - notification n1 is sent minor - notification n2 is sent critical - critical n3 is sent The three objects alarmModelNotificationId, alarmModelVarbindIndex, and alarmModelVarbindValue perform the mapping. However, how the code would determine the value of "alarmActiveResourceId" from the notifications is not described. If this mapping is "hard coded", so new entries could not be created in table alarmModelTable, then the problem is solved. But if so, then I'm note sure why we need the model table. At 05:08 PM 4/22/2002 -0700, Randy Presuhn wrote: >Hi - > >> content-class: urn:content-classes:message >> Subject: RE: Pairing instances >> Date: Thu, 18 Apr 2002 16:07:41 +0300 >> Message-ID: >> From: "Romascanu, Dan (Dan)" >> To: "David T. Perkins" , >... >> Do you think that there is need for >> more explanation, or maybe do you think that an alarm may be >> triggered on interface 1 and cleared on interface 9? (I do >> not think this is a practical case) >... > >Consider the case where the ifStackTable is used to associate >DS0s with their underlying T1. For something on interface >1 to potentially clear the alarms on interfaces 2 through 25 >does not seem far-fetched. However, do we see this as being >within the scope of this MIB? > > Randy Presuhn BMC Software, Inc. 1-3141 Regards, /david t. perkins From owner-disman@dorothy.bmc.com Mon Apr 22 20:58:51 2002 Received: from babbler.bmc.com (firebird.bmc.com [198.207.223.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19559 for ; Mon, 22 Apr 2002 20:58:50 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g3N11QC11983; Mon, 22 Apr 2002 20:01:27 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id RAA17718 for disman-list; Mon, 22 Apr 2002 17:55:53 -0700 (PDT) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id RAA17712 for disman@dorothy.bmc.com; Mon, 22 Apr 2002 17:55:49 -0700 (PDT) Date: Mon, 22 Apr 2002 17:55:49 -0700 (PDT) From: Randy Presuhn Message-Id: <200204230055.RAA17712@dorothy.bmc.com> To: disman@dorothy.bmc.com Subject: RE: Pairing instances 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: <5.0.2.1.2.20020422172156.03b39bd0@mail4.bayarea.net> > Date: Mon, 22 Apr 2002 17:39:12 -0700 > To: Randy Presuhn , disman@dorothy.bmc.com > From: "David T. Perkins" > Subject: RE: Pairing instances > In-Reply-To: <200204230008.RAA17512@dorothy.bmc.com> ... > The example below is interesting, but I'm talking about something > really basic. Much simpler than your example. ;-) The question about how the ... > code would determine the value of "alarmActiveResourceId" from > the notifications is not described. ... Agreed. This is a problem. Summing up, we have similar concerns about the alarmModelTable. A partial list, paraphrasing (or possibly reading too much into) your posts: 1) how does it the implementation figure out where to get the value for alarmActiveResourceId? (The information has to be in the notification somewhere, but how does the alarmModelTable tell the implementation where to look?) 2) what is the appropriate amount of power for describing the "finite state machine" for an alarm? 3) can a single notification "crank" more than one alarm's state machine? (This is tied to (1)) ------------------------------------------------------ Randy Presuhn BMC Software, Inc. 1-3141 randy_presuhn@bmc.com 2141 North First Street Tel: +1 408 546-1006 San José, California 95131 USA ------------------------------------------------------ My opinions and BMC's are independent variables. ------------------------------------------------------ From owner-disman@dorothy.bmc.com Tue Apr 23 07:05:14 2002 Received: from babbler.bmc.com (firebird.bmc.com [198.207.223.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11493 for ; Tue, 23 Apr 2002 07:05:14 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g3NB7m818079; Tue, 23 Apr 2002 06:07:48 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id EAA19269 for disman-list; Tue, 23 Apr 2002 04:01:55 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id EAA19264 for ; Tue, 23 Apr 2002 04:01:51 -0700 (PDT) Received: from mx-us-hou-2-int.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id g3NAxZc06887 for ; Tue, 23 Apr 2002 05:59:35 -0500 (CDT) Received: from iere.net.avaya.com (iere.net.avaya.com [198.152.12.101]) by mx-us-hou-2-int.bmc.com (Postfix) with SMTP id E39C41FF142 for ; Tue, 23 Apr 2002 06:03:20 -0500 (CDT) Received: from iere.net.avaya.com (localhost [127.0.0.1]) by iere.net.avaya.com (8.11.2/8.9.3) with ESMTP id g3NB1QQ11231 for ; Tue, 23 Apr 2002 07:01:26 -0400 (EDT) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by iere.net.avaya.com (8.11.2/8.9.3) with ESMTP id g3NB1PQ11221 for ; Tue, 23 Apr 2002 07:01:25 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: Alarm MIB WG last call Content-Type: text/plain; charset="iso-8859-1" Date: Tue, 23 Apr 2002 14:00:59 +0300 Message-ID: Thread-Topic: Alarm MIB WG last call Thread-Index: AcHqPoc3xQ7v0+0rQAGiN0RDsb29iwAEgz5A From: "Romascanu, Dan (Dan)" To: Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by dorothy.bmc.com id EAA19265 Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list Content-Transfer-Encoding: 8bit > Dan, > See my comments below. > Tammy > > "Romascanu, Dan (Dan)" wrote: > > > OK, I think that I got now your issue. Getting back to your > proposal: > > > > > > > I proposed a fix of having 2 timestamps in the active alarm > > > > > table rather than one : One time stamp (the time the alarm > > > > > was reported) be the one to use for indexing and a second > > > > > time stamp (the time the error occured). > > > > Two things need to be clarified here: > > > > - instead of saying 'the alarm was reported' we need to say > 'the alarm was reported or retrieved', in order to > accommodate agent implementations that are based on a polling > model rather than asynchronous reports from an other subsystem > > - need to define the behavior of an agent an agent that > cannot retrieve accurately the time the error occurred. I am > not sure how to do this. We might need to add another > variable that describes whether this capability exists in the > system, or invent another TC like DateAndTimeOrZero. > > *** > Does this reply indicate that you prefer two timestamps over > some other solution to fix this problem? > > Instead of saying 'the alarm was reported' or 'the alarm was > reported or retrieved', how about 'the error information was > populated in the alarm table'? I say this because I think > maybe the notion of time retrieved would be confusing in a > multi-manager environment. > > For systems that cannot either produce and/or store error > occurance timestamps, how about setting the time the error > occurred equal to the time the alarm information was added to > the alarm table? > Tammy > > > I am not convinced that there is a problem, or at least that this problem exists for all implementation models. However I would be ready to accomodate the solution that you are proposing, in order to avoid blocking thw advancement of this work. I would like to hear more opinions. Randy seems to indicate that he does not think that the second object is necessary, though I am not dure that I completely digested his reference to agentx, which also hints to (another) specific way of implementing the distribution. Regards, Dan > From owner-disman@dorothy.bmc.com Tue Apr 23 10:11:56 2002 Received: from babbler.bmc.com (firebird.bmc.com [198.207.223.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18604 for ; Tue, 23 Apr 2002 10:11:56 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g3NEECv15969; Tue, 23 Apr 2002 09:14:16 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id HAA19672 for disman-list; Tue, 23 Apr 2002 07:06:17 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id HAA19666; Tue, 23 Apr 2002 07:06:13 -0700 (PDT) Received: from mx-us-hou-1-int.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id g3NE3w210285; Tue, 23 Apr 2002 09:03:58 -0500 (CDT) Received: from harrier.prod.itd.earthlink.net (unknown [207.217.120.12]) by mx-us-hou-1-int.bmc.com (Postfix) with SMTP id 1092120EFED; Tue, 23 Apr 2002 09:07:44 -0500 (CDT) Received: from 1cust136.tnt2.minneapolis.mn.da.uu.net ([67.251.129.136] helo=merkita.com) by harrier.prod.itd.earthlink.net with esmtp (Exim 3.33 #2) id 1700xF-0006No-00; Tue, 23 Apr 2002 07:07:38 -0700 Message-ID: <3CC56A0D.1F917A66@merkita.com> Date: Tue, 23 Apr 2002 09:05:01 -0500 From: Tammy Ferris Reply-To: tferris@merkita.com X-Mailer: Mozilla 4.75 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Randy Presuhn Cc: disman@dorothy.bmc.com Subject: Re: Alarm MIB WG last call References: <200204222247.PAA16114@dorothy.bmc.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list Content-Transfer-Encoding: 8bit Randy, Thanks for the clarification. Sounds fine to me. Just one question. See below. Tammy Randy Presuhn wrote: > Hi - > > > Message-ID: <3CC49040.C954E9FF@merkita.com> > > Date: Mon, 22 Apr 2002 17:35:44 -0500 > > From: Tammy Ferris > > To: Randy Presuhn > > Cc: disman@dorothy.bmc.com > > Subject: Re: Alarm MIB WG last call > > References: <200204222117.OAA15022@dorothy.bmc.com> > ... > > > I can't speak for Dan, but my point was that the information > > > recording when the condition was detected would already be present > > > in the variable bindings, so that there's no need for a second object. > > > > I apologize that I don't understand your point. Are you saying that the timestamp used > > for the index should be the 'time that the error information was added to the alarm table' > > and that the 'time the error occured' would be in the variable bindings? Or are you > > This makes the most sense to me. > > > saying that there doesn't need to be a timestamp for the time the error information was > > added into the active alarm table? > > No. I think both pieces of information are interesting. I'm > just saying that we don't need to objects, because the timestamp > indicating when the error occured will be in the variable bindings > anyway. > > ... > > > > For systems that cannot either produce and/or store error occurance > > > > timestamps, how about setting the time the error occurred equal to > > > > the time the alarm information was added to the alarm table? > > > ... > > > > > > Why would we need to support such a beast? A notification by > > > definition includes a timestamp. Take a look at the agentx > > > protocol spec. Infrastructure lacking this information is > > > arguably broken. > > > > Clarify for me - what I think you are saying here is that all 'subagents' and 'agents' > > have the capability (memory and clock) to support the recording and reporting the time of > > the occurance of every error. Is that correct? If so, then I agree that Dan should not > > worry about what to do if such capability does not exist. > ... > > Just think about it from an AgentX perspective: the protocol is > specifically designed so that subagents will know their sysUpTime, > and the text on notifications specifically provides for the > communication of the time stamp. If the subagent omits the > sysUpTime variable binding, the elements of procedure specifically > provide for the master agent to provide the appropriate one for > the context, which would be a perfectly reasonable fallback > for an active alarm MIB to use when the "real" time of the > failure isn't known. **** What would be the appropriate one in this case? **** > > > ------------------------------------------------------ > Randy Presuhn BMC Software, Inc. 1-3141 > randy_presuhn@bmc.com 2141 North First Street > Tel: +1 408 546-1006 San José, California 95131 USA > ------------------------------------------------------ > My opinions and BMC's are independent variables. > ------------------------------------------------------ From owner-disman@dorothy.bmc.com Tue Apr 23 10:45:09 2002 Received: from babbler.bmc.com (camaro.bmc.com [198.207.223.231]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20149 for ; Tue, 23 Apr 2002 10:45:09 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g3NElnQ22122; Tue, 23 Apr 2002 09:47:49 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id HAA20234 for disman-list; Tue, 23 Apr 2002 07:42:09 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id HAA20229 for ; Tue, 23 Apr 2002 07:42:05 -0700 (PDT) Received: from mx-us-hou-1-int.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id g3NEdln02037 for ; Tue, 23 Apr 2002 09:39:47 -0500 (CDT) Received: from watcher.dataductus.se (unknown [213.199.99.201]) by mx-us-hou-1-int.bmc.com (Postfix) with SMTP id 6EC9620EFE0 for ; Tue, 23 Apr 2002 09:43:32 -0500 (CDT) Received: (qmail 7928 invoked from network); 23 Apr 2002 14:43:31 -0000 Received: from nsmail.dataductus.se (192.168.100.43) by 0 with SMTP; 23 Apr 2002 14:43:31 -0000 Received: from dataductus.com ([192.168.100.240]) by nsmail.dataductus.se (Netscape Messaging Server 4.15) with SMTP id GV0ZKJ00.K2O for ; Tue, 23 Apr 2002 16:43:31 +0200 From: "Stefan Wallin" To: Subject: Pairing instances in RMON example Date: Tue, 23 Apr 2002 16:43:29 +0200 MIME-Version: 1.0 Message-ID: X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0019_01C1EAE5.FF3665D0" Importance: Normal In-Reply-To: <5.0.2.1.2.20020422172156.03b39bd0@mail4.bayarea.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list This is a multi-part message in MIME format. ------=_NextPart_000_0019_01C1EAE5.FF3665D0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi! I have problems with the RMON example and some of the issues I think is connected to what Perkins describe. 1) In general the example is a little bit strange since it does not use fallingAlarm and risingAlarm as alarm on/off notifications. 2) However the more general question is: Lets say I define two alarms in the RMON alarmTable: alarmVariable X, risingThreshold 10, fallingthreshold 8 alarmVariable Y, risingThreshold 20, fallingthreshold 16 In this case it is extremely important that fallingAlarm Threshold on Y does not clear any active alarm on X. How do we describe that? Miss something in the alarmModelTable to point to resource var-bind in case the generic notifications are not used. (Resembles Perkins ifIndex example). What is the conclusion on the previous issue here? 3) Minor error in 6.1 Alarms Based on linkUp/linkDown Notification alarmActiveModelPointer alarmModelEntry.3 <<<<<<<<<<<<<< missing index -----Ursprungligt meddelande----- Fran: owner-disman@dorothy.bmc.com [mailto:owner-disman@dorothy.bmc.com]For David T. Perkins Skickat: den 23 april 2002 02:39 Till: Randy Presuhn; disman@dorothy.bmc.com Amne: RE: Pairing instances HI, The example below is interesting, but I'm talking about something really basic. Lets assume we are using unique notifications for "state transitions". Then the model table (alarmModelTable) maps notifications to "next state" severity levels of alarms. Assume the value for alarmListName is the zero length string. Say, we have alarm "A", that is identified with value 23 as specified for index object alarmModelIndex, and has the following assignments for values for perceived severity and notifications: clear - notification n1 is sent minor - notification n2 is sent critical - critical n3 is sent The three objects alarmModelNotificationId, alarmModelVarbindIndex, and alarmModelVarbindValue perform the mapping. However, how the code would determine the value of "alarmActiveResourceId" from the notifications is not described. If this mapping is "hard coded", so new entries could not be created in table alarmModelTable, then the problem is solved. But if so, then I'm note sure why we need the model table. At 05:08 PM 4/22/2002 -0700, Randy Presuhn wrote: >Hi - > >> content-class: urn:content-classes:message >> Subject: RE: Pairing instances >> Date: Thu, 18 Apr 2002 16:07:41 +0300 >> Message-ID: >> From: "Romascanu, Dan (Dan)" >> To: "David T. Perkins" , >... >> Do you think that there is need for >> more explanation, or maybe do you think that an alarm may be >> triggered on interface 1 and cleared on interface 9? (I do >> not think this is a practical case) >... > >Consider the case where the ifStackTable is used to associate >DS0s with their underlying T1. For something on interface >1 to potentially clear the alarms on interfaces 2 through 25 >does not seem far-fetched. However, do we see this as being >within the scope of this MIB? > > Randy Presuhn BMC Software, Inc. 1-3141 Regards, /david t. perkins ------=_NextPart_000_0019_01C1EAE5.FF3665D0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJATCCApAw ggH5oAMCAQICAwYNiDANBgkqhkiG9w0BAQIFADCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdl c3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsT FENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAw MC44LjMwMB4XDTAxMTEwODExMTcwMloXDTAyMTEwODExMTcwMlowTTEfMB0GA1UEAxMWVGhhd3Rl IEZyZWVtYWlsIE1lbWJlcjEqMCgGCSqGSIb3DQEJARYbc3RlZmFuLndhbGxpbkBkYXRhZHVjdHVz LnNlMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCs05PXVkcFgmj+s6KhgDkygKKwOv4n3+w9 16zv3AqqW7ssTETrL9l5sY/5i5KEJOpLYsXMD/hhpcSQj8wEec52JkC7DbuqtoQwwMExzD5ijNFV gG/efTaRZBmkMofmyypmLPaeRlwSs9DbLa1HKnK9jLPjT8+0zutDb+z66zjEgwIDAQABozgwNjAm BgNVHREEHzAdgRtzdGVmYW4ud2FsbGluQGRhdGFkdWN0dXMuc2UwDAYDVR0TAQH/BAIwADANBgkq hkiG9w0BAQIFAAOBgQC6vCfLXni0OMwFVRxNQzTdIKcnbUC7mpAlvEn3rgaX9prsg1A8fu8qJW79 xeQ5Jk9kYi8Lfo9AvVgIG1H3b2wngzwV85tfJmTTpgrfPdQnUpvZ5r51Pf8sznH0/QwscOzNlnZd RTZIXoYLtuGEDm52KznRxx/GRgFKgqXP+pCvjDCCAy0wggKWoAMCAQICAQAwDQYJKoZIhvcNAQEE BQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg VG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24g U2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTEr MCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw05NjAxMDEwMDAw MDBaFw0yMDEyMzEyMzU5NTlaMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBl MRIwEAYDVQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQL Ex9DZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29u YWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0ZS5j b20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANRp19SwlGRbcelH2AxRtupykbCEXn0tDY97 Et+FJXUodDpCLGMnn5V7S+9+GYcdhuqj3bnOlmQawhRuRKx85o/oTQ9xH0A4pgCjh3j2+ZSGXq3q wF5269kUo11uenwMpUtVfwYZKX+emibVars4JAhqmMex2qOYkf152+VaxBy5AgMBAAGjEzARMA8G A1UdEwEB/wQFMAMBAf8wDQYJKoZIhvcNAQEEBQADgYEAx+ySfk749ZalZ2IqpPBNEWDQb41gWGGs JrtSNVwIzzD7qEqWih9iQiOMFw/0umScF6xHKd+dmF7SbGBxXKKs3Hnj524ARx+1DSjoAp3kmv0T 9KbZfLH43F8jJgmRgHPQFBveQ6mDJfLmnC8Vyv6mq4oHdYsM3VGEa+T40c53ooEwggM4MIICoaAD AgECAhBmRXK3zHT1z2N2RYTQLpEBMA0GCSqGSIb3DQEBBAUAMIHRMQswCQYDVQQGEwJaQTEVMBMG A1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBD b25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYD VQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFs LWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcNMDAwODMwMDAwMDAwWhcNMDQwODI3MjM1OTU5WjCBkjEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8w DQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9Q ZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKB gQDeMzKmY8cJJUU+0m54J2eBxdqIGYKXDuNEKYpjNSptcDz63K737nRvMLwzkH/5NHGgo22Y8cNP omXbDfpL8dbdYaX5hc1VmjUanZJ1qCeu2HL5ugL217CR3hzpq+AYA6h8Q0JQUYeDPPA5tJtUihOH /7ObnUlmAC0JieyUa+mhaQIDAQABo04wTDApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0 ZUxhYmVsMS0yOTcwEgYDVR0TAQH/BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQEE BQADgYEAMbFLR135AXHl9VNsXXnWPZjAJhNigSKnEvgilegbSbcnewQ5uvzm8iTrkfq97A0qOPdQ Vahs9w2tTBu8A/S166JHn2yiDFiNMUIJEWywGmnRKxKyQF1q+XnQ6i4l3Yrk/NsNH50C81rbyjz2 ROomaYd/SJ7OpZ/nhNjJYmKtBcYxggKOMIICigIBATCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNV BAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAb BgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBS U0EgMjAwMC44LjMwAgMGDYgwCQYFKw4DAhoFAKCCAUkwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMDIwNDIzMTQ0MzI5WjAjBgkqhkiG9w0BCQQxFgQUHmt4ROlkJLia wcgshD7Bm0y/GlcwPAYJKoZIhvcNAQkPMS8wLTAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAHBgUr DgMCGjAKBggqhkiG9w0CBTCBqwYJKwYBBAGCNxAEMYGdMIGaMIGSMQswCQYDVQQGEwJaQTEVMBMG A1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xDzANBgNVBAoTBlRoYXd0ZTEd MBsGA1UECxMUQ2VydGlmaWNhdGUgU2VydmljZXMxKDAmBgNVBAMTH1BlcnNvbmFsIEZyZWVtYWls IFJTQSAyMDAwLjguMzACAwYNiDANBgkqhkiG9w0BAQEFAASBgFqJoLeTwyCq12jeUJRtJUwHFfdz /Iy53m+py1TouscsIyZ/9bFurBh4IOoi+3BoxD/VmFr4+T/1NHSaOwOBTqA9vWQVfvgxX6nXTa5L GILGY7Ruz+CdPSyXuWBx0djqhguDM4IjOTvPfYzfHkijwuvzhmRvHX+KZzHr6D1Olv9BAAAAAAAA ------=_NextPart_000_0019_01C1EAE5.FF3665D0-- From owner-disman@dorothy.bmc.com Tue Apr 23 11:23:22 2002 Received: from babbler.bmc.com (camaro.bmc.com [198.207.223.231]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22680 for ; Tue, 23 Apr 2002 11:23:22 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g3NFPxA00639; Tue, 23 Apr 2002 10:25:59 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id IAA20424 for disman-list; Tue, 23 Apr 2002 08:20:06 -0700 (PDT) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id IAA20418 for disman@dorothy.bmc.com; Tue, 23 Apr 2002 08:20:03 -0700 (PDT) Date: Tue, 23 Apr 2002 08:20:03 -0700 (PDT) From: Randy Presuhn Message-Id: <200204231520.IAA20418@dorothy.bmc.com> To: disman@dorothy.bmc.com Subject: Re: Alarm MIB WG last call 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 - > Message-ID: <3CC56A0D.1F917A66@merkita.com> > Date: Tue, 23 Apr 2002 09:05:01 -0500 > From: Tammy Ferris > To: Randy Presuhn > Cc: disman@dorothy.bmc.com > Subject: Re: Alarm MIB WG last call > References: <200204222247.PAA16114@dorothy.bmc.com> ... > > Just think about it from an AgentX perspective: the protocol is > > specifically designed so that subagents will know their sysUpTime, > > and the text on notifications specifically provides for the > > communication of the time stamp. If the subagent omits the > > sysUpTime variable binding, the elements of procedure specifically > > provide for the master agent to provide the appropriate one for > > the context, which would be a perfectly reasonable fallback > > for an active alarm MIB to use when the "real" time of the > > failure isn't known. > > **** > What would be the appropriate one in this case? > **** ... If there is nothing in the payload from the subagent, the AgentX specification requires the use of sysUpTime.0 from the named context. I don't see why we'd want to do anything else. ------------------------------------------------------ Randy Presuhn BMC Software, Inc. 1-3141 randy_presuhn@bmc.com 2141 North First Street Tel: +1 408 546-1006 San José, California 95131 USA ------------------------------------------------------ My opinions and BMC's are independent variables. ------------------------------------------------------ From owner-disman@dorothy.bmc.com Tue Apr 23 11:49:20 2002 Received: from babbler.bmc.com (firebird.bmc.com [198.207.223.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24294 for ; Tue, 23 Apr 2002 11:49:19 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g3NFq0Z08212; Tue, 23 Apr 2002 10:52:00 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id IAA20537 for disman-list; Tue, 23 Apr 2002 08:46:23 -0700 (PDT) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id IAA20529 for disman@dorothy.bmc.com; Tue, 23 Apr 2002 08:46:19 -0700 (PDT) Date: Tue, 23 Apr 2002 08:46:19 -0700 (PDT) From: Randy Presuhn Message-Id: <200204231546.IAA20529@dorothy.bmc.com> To: disman@dorothy.bmc.com Subject: RE: Alarm MIB WG last call 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 - > Subject: RE: Alarm MIB WG last call > Date: Tue, 23 Apr 2002 14:00:59 +0300 > Message-ID: > From: "Romascanu, Dan (Dan)" > To: > Cc: ... > I would like to hear more opinions. Randy seems to indicate > that he does not think that the second object is necessary, > though I am not dure that I completely digested his reference > to agentx, which also hints to (another) specific way of > implementing the distribution. ... The subagent protocols I am familiar with provide the ability for the subagent to include event time information. However, this information would be lost if the sysUpTime varbind is not retained in the varbind table. Here are the alternatives I see: 1) the distinction is not interesting. we can omit the variable binding from the varbind table, and do not need an object to represent the event time. 2) the distinction is interesting, but is not so important as to merit a special object. we can cover this case simply by including the sysUpTime variable binding in the varbind table. 3) the distinction is so interesting that it merits an object of its own. I lean towards (2), but am willing to listen to reason, particularly since (2) does have problems in the face of sysUpTime discontinuities. ------------------------------------------------------ Randy Presuhn BMC Software, Inc. 1-3141 randy_presuhn@bmc.com 2141 North First Street Tel: +1 408 546-1006 San José, California 95131 USA ------------------------------------------------------ My opinions and BMC's are independent variables. ------------------------------------------------------ From owner-disman@dorothy.bmc.com Tue Apr 23 11:56:20 2002 Received: from babbler.bmc.com (camaro.bmc.com [198.207.223.231]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24594 for ; Tue, 23 Apr 2002 11:56:20 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g3NFx2m09554; Tue, 23 Apr 2002 10:59:02 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id IAA20638 for disman-list; Tue, 23 Apr 2002 08:53:30 -0700 (PDT) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id IAA20632 for disman@dorothy.bmc.com; Tue, 23 Apr 2002 08:53:26 -0700 (PDT) Date: Tue, 23 Apr 2002 08:53:26 -0700 (PDT) From: Randy Presuhn Message-Id: <200204231553.IAA20632@dorothy.bmc.com> To: disman@dorothy.bmc.com Subject: Re: Pairing instances in RMON example 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: "Stefan Wallin" > To: > Subject: Pairing instances in RMON example > Date: Tue, 23 Apr 2002 16:43:29 +0200 > Message-ID: > In-Reply-To: <5.0.2.1.2.20020422172156.03b39bd0@mail4.bayarea.net> ... > 2) However the more general question is: > Lets say I define two alarms in the RMON alarmTable: > alarmVariable X, risingThreshold 10, fallingthreshold 8 > alarmVariable Y, risingThreshold 20, fallingthreshold 16 > > In this case it is extremely important that fallingAlarm Threshold on Y > does not clear any active alarm on X. > How do we describe that? Miss something in the alarmModelTable to point to > resource var-bind in case the generic notifications are not used. > (Resembles Perkins ifIndex example). What is the conclusion on the > previous issue here? ... I agree that there's a problem. For this to work as intended, the resource needs to be identified. At the moment, this looks like magic. Perhaps some of the tricks from the expression MIB or the snmpconf work might be appropriate. ------------------------------------------------------ Randy Presuhn BMC Software, Inc. 1-3141 randy_presuhn@bmc.com 2141 North First Street Tel: +1 408 546-1006 San José, California 95131 USA ------------------------------------------------------ My opinions and BMC's are independent variables. ------------------------------------------------------ From owner-disman@dorothy.bmc.com Tue Apr 23 12:38:01 2002 Received: from babbler.bmc.com (camaro.bmc.com [198.207.223.231]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26795 for ; Tue, 23 Apr 2002 12:38:01 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g3NGeec19109; Tue, 23 Apr 2002 11:40:41 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id JAA20937 for disman-list; Tue, 23 Apr 2002 09:34:36 -0700 (PDT) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id JAA20931 for disman@dorothy.bmc.com; Tue, 23 Apr 2002 09:34:32 -0700 (PDT) Date: Tue, 23 Apr 2002 09:34:32 -0700 (PDT) From: Randy Presuhn Message-Id: <200204231634.JAA20931@dorothy.bmc.com> To: disman@dorothy.bmc.com Subject: Re: Which named list does all alarm use 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: <5.0.2.1.2.20020417224929.02a43760@mail4.bayarea.net> > Date: Wed, 17 Apr 2002 23:18:38 -0700 > To: disman@dorothy.bmc.com > From: "David T. Perkins" > Subject: Which named list does all alarm use > List-Id: IETF disman Working Group mailing list ... > How is it determined into which named active list an alarm is put? My understanding is that an active alarm entry would be created in each list which had at least one model entry matching the notification. > How and why named lists are used is not shown. I assumed they were to support multiple communities of interest, perhaps with different access rights. > Also, it seems kind of redundant that the model table is indexed > by a list name, since it would seem like there would be the same > entries in each named list. There is an access control issue here. If we don't want the active alarm table to leak information about notifications, we need to ensure that stuff gets put into that table only if that table's "owner" would have been permitted to get the notification. (This is the same set of issues that went into the security considerations for the log mib.) Since the model table "sees" the notifications, only stuff which has already been approved for access should be processed in accordance with the models specified in it. This strongly suggests that the models should be kept separate. > Could an example be shown that demonstrated how named model and > active lists were used together. ... I like this suggestion, but would hope that it would flow naturally from any of the other examples. ------------------------------------------------------ Randy Presuhn BMC Software, Inc. 1-3141 randy_presuhn@bmc.com 2141 North First Street Tel: +1 408 546-1006 San José, California 95131 USA ------------------------------------------------------ My opinions and BMC's are independent variables. ------------------------------------------------------ From owner-disman@dorothy.bmc.com Tue Apr 23 13:22:27 2002 Received: from babbler.bmc.com (firebird.bmc.com [198.207.223.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28301 for ; Tue, 23 Apr 2002 13:22:26 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g3NHP4W27505; Tue, 23 Apr 2002 12:25:04 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id KAA21174 for disman-list; Tue, 23 Apr 2002 10:19:21 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id KAA21169 for ; Tue, 23 Apr 2002 10:19:12 -0700 (PDT) Received: from mx-us-hou-1-int.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id g3NHGwc03487 for ; Tue, 23 Apr 2002 12:16:59 -0500 (CDT) Received: from riverstonenet.com (unknown [63.113.148.10]) by mx-us-hou-1-int.bmc.com (Postfix) with SMTP id C69D420EFA9 for ; Tue, 23 Apr 2002 12:20:45 -0500 (CDT) Received: from dperkins-nb2.dsperkins.com by riverstonenet.com (8.9.3+Sun/SMI-SVR4-Yago) id KAA29120; Tue, 23 Apr 2002 10:20:44 -0700 (PDT) Message-Id: <5.0.2.1.2.20020423101447.03372170@mail4.bayarea.net> X-Sender: dperkins@mail4.bayarea.net X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Tue, 23 Apr 2002 10:19:07 -0700 To: From: "David T. Perkins" Subject: Use of alarmListName 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, The alarm draft has the tables indexed by object alarmListName. However, I cannot figure out how notifications are classified so that they use appropriate entries in tables based on the value of alarmListName. That is, what is the classifier from notifications to values of alarmListName? And how is this configured? PS Randy - feel free to restate this as a clearer and simpler question. Regards, /david t. perkins From owner-disman@dorothy.bmc.com Tue Apr 23 13:35:01 2002 Received: from babbler.bmc.com (firebird.bmc.com [198.207.223.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28663 for ; Tue, 23 Apr 2002 13:35:00 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g3NHbfe29522; Tue, 23 Apr 2002 12:37:41 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id KAA21270 for disman-list; Tue, 23 Apr 2002 10:32:09 -0700 (PDT) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id KAA21264 for disman@dorothy.bmc.com; Tue, 23 Apr 2002 10:32:06 -0700 (PDT) Date: Tue, 23 Apr 2002 10:32:06 -0700 (PDT) From: Randy Presuhn Message-Id: <200204231732.KAA21264@dorothy.bmc.com> To: disman@dorothy.bmc.com Subject: Re: Use of alarmListName 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: <5.0.2.1.2.20020423101447.03372170@mail4.bayarea.net> > Date: Tue, 23 Apr 2002 10:19:07 -0700 > To: > From: "David T. Perkins" > Subject: Use of alarmListName > List-Id: IETF disman Working Group mailing list > > HI, > > The alarm draft has the tables indexed by object alarmListName. > > However, I cannot figure out how notifications are classified > so that they use appropriate entries in tables based on the > value of alarmListName. That is, what is the classifier from > notifications to values of alarmListName? And how is this > configured? > > PS Randy - feel free to restate this as a clearer and simpler > question. ... I think alarmListName has nothing to do with alarm classification. Here's a not-very-useful example of how I think it's supposed to work. If I configure the same models under three different alarmListNames, and if access control policy permits, then I would expect that for any active alarm entry existing under one of the alarmListNames, there should be corresponding entries under both of the other alarmListNames. In short, it's to support sandboxing the users of the alarm facility. One *could* in a really twisted way use it for alarm classification (different models under different alarmListNames corresponding to alarm classification), but I don't think that that's the motivation for it. (Of course, I could have completely misunderstood the whole thing. :-) ------------------------------------------------------ Randy Presuhn BMC Software, Inc. 1-3141 randy_presuhn@bmc.com 2141 North First Street Tel: +1 408 546-1006 San José, California 95131 USA ------------------------------------------------------ My opinions and BMC's are independent variables. ------------------------------------------------------ From owner-disman@dorothy.bmc.com Tue Apr 23 14:18:48 2002 Received: from babbler.bmc.com (firebird.bmc.com [198.207.223.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00218 for ; Tue, 23 Apr 2002 14:18:48 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g3NILR906913; Tue, 23 Apr 2002 13:21:28 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id LAA21380 for disman-list; Tue, 23 Apr 2002 11:15:45 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id LAA21375 for ; Tue, 23 Apr 2002 11:15:42 -0700 (PDT) Received: from mx-us-hou-1-int.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id g3NIDSN05256 for ; Tue, 23 Apr 2002 13:13:28 -0500 (CDT) Received: from riverstonenet.com (unknown [63.113.148.10]) by mx-us-hou-1-int.bmc.com (Postfix) with SMTP id 5459920EFEE for ; Tue, 23 Apr 2002 13:17:15 -0500 (CDT) Received: from dperkins-nb2.dsperkins.com by riverstonenet.com (8.9.3+Sun/SMI-SVR4-Yago) id LAA04703; Tue, 23 Apr 2002 11:17:14 -0700 (PDT) Message-Id: <5.0.2.1.2.20020423110420.03454240@mail4.bayarea.net> X-Sender: dperkins@mail4.bayarea.net X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Tue, 23 Apr 2002 11:16:53 -0700 To: disman@dorothy.bmc.com From: "David T. Perkins" Subject: Re: Use of alarmListName In-Reply-To: <200204231732.KAA21264@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 HI, I was first trying to get clarification on the "simpler" of the three ways that alarms are defined. If this could be clarified, then the other two ways might be obvious. The first was via "existing" notifications. The second was via the two new notifications (alarmActiveState and alarmClearState). The third is via internal mechanisms (that is, alarmModelNotificationId has the value { 0 0 }). Did I get this correct? One of the fundamental goals of the I-D appears to me to use the existing notifications generated by a system, and to create a system that mapped these existing notifications to alarm raises (with configured severity) or to alarm clears. How this is done doesn't seem complete to me. At 10:32 AM 4/23/2002 -0700, Randy Presuhn wrote: >Hi - > >> Message-Id: <5.0.2.1.2.20020423101447.03372170@mail4.bayarea.net> >> Date: Tue, 23 Apr 2002 10:19:07 -0700 >> To: >> From: "David T. Perkins" >> Subject: Use of alarmListName >> List-Id: IETF disman Working Group mailing list >> >> HI, >> >> The alarm draft has the tables indexed by object alarmListName. >> >> However, I cannot figure out how notifications are classified >> so that they use appropriate entries in tables based on the >> value of alarmListName. That is, what is the classifier from >> notifications to values of alarmListName? And how is this >> configured? >> >> PS Randy - feel free to restate this as a clearer and simpler >> question. >... > >I think alarmListName has nothing to do with alarm classification. > >Here's a not-very-useful example of how I think it's supposed >to work. If I configure the same models under three different >alarmListNames, and if access control policy permits, then I >would expect that for any active alarm entry existing under >one of the alarmListNames, there should be corresponding >entries under both of the other alarmListNames. > >In short, it's to support sandboxing the users of the >alarm facility. One *could* in a really twisted way use it >for alarm classification (different models under different >alarmListNames corresponding to alarm classification), but >I don't think that that's the motivation for it. > >(Of course, I could have completely misunderstood the >whole thing. :-) Regards, /david t. perkins From owner-disman@dorothy.bmc.com Tue Apr 23 15:56:26 2002 Received: from babbler.bmc.com (camaro.bmc.com [198.207.223.231]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04631 for ; Tue, 23 Apr 2002 15:56:26 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g3NJwuB26458; Tue, 23 Apr 2002 14:58:57 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id MAA25355 for disman-list; Tue, 23 Apr 2002 12:52:59 -0700 (PDT) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id MAA25349 for disman@dorothy.bmc.com; Tue, 23 Apr 2002 12:52:56 -0700 (PDT) Date: Tue, 23 Apr 2002 12:52:56 -0700 (PDT) From: Randy Presuhn Message-Id: <200204231952.MAA25349@dorothy.bmc.com> To: disman@dorothy.bmc.com Subject: Re: Use of alarmListName 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: <5.0.2.1.2.20020423110420.03454240@mail4.bayarea.net> > Date: Tue, 23 Apr 2002 11:16:53 -0700 > To: disman@dorothy.bmc.com > From: "David T. Perkins" > Subject: Re: Use of alarmListName > In-Reply-To: <200204231732.KAA21264@dorothy.bmc.com> > List-Id: IETF disman Working Group mailing list > > HI, > > I was first trying to get clarification on the "simpler" of the three > ways that alarms are defined. If this could be clarified, then > the other two ways might be obvious. > > The first was via "existing" notifications. The second was via > the two new notifications (alarmActiveState and alarmClearState). > The third is via internal mechanisms (that is, alarmModelNotificationId > has the value { 0 0 }). > > Did I get this correct? That's what the draft seems to say. I think the second is a special case of the first, and the third just looks like magic. > One of the fundamental goals of the I-D appears to me to use the > existing notifications generated by a system, and to create a > system that mapped these existing notifications to alarm raises > (with configured severity) or to alarm clears. > How this is done doesn't seem complete to me. ... Yup, I'm inclined to agree. ------------------------------------------------------ Randy Presuhn BMC Software, Inc. 1-3141 randy_presuhn@bmc.com 2141 North First Street Tel: +1 408 546-1006 San José, California 95131 USA ------------------------------------------------------ My opinions and BMC's are independent variables. ------------------------------------------------------ From owner-disman@dorothy.bmc.com Tue Apr 23 17:29:31 2002 Received: from babbler.bmc.com (firebird.bmc.com [198.207.223.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07232 for ; Tue, 23 Apr 2002 17:29:31 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g3NLW9024206; Tue, 23 Apr 2002 16:32:09 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id OAA25615 for disman-list; Tue, 23 Apr 2002 14:26:25 -0700 (PDT) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id OAA25608 for disman@dorothy.bmc.com; Tue, 23 Apr 2002 14:26:21 -0700 (PDT) Date: Tue, 23 Apr 2002 14:26:21 -0700 (PDT) From: Randy Presuhn Message-Id: <200204232126.OAA25608@dorothy.bmc.com> To: disman@dorothy.bmc.com Subject: making AlarmModel more explicit 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 - As a technical contributor, for the sake of discussion I'd like to suggest thinking about slightly different approach to the problem of making the alarm models more explicit. First, a slightly different information flow would eliminate any "specialness" from the processing of the alarmActive/Clear notifications, and allow the alarm processing module to be built from the same components (including access control) as one would need to support logging. (internal) notification stream | alarmActiveState / alarmClearState |<-----------------------------------------------+ | | +------------------V-------------+ | | | | | | +---------------V----------+ | | | | RFC 2573 | | | | | SNMP-TARGET-MIB | | | | +---+------+-------------+-+ | +----------------------------+ | | | | | | | +------------------+ | | | V | +-------->--> Alarm Modelling | | | | +-------+ | | | | (descriptions) | | | | | Log | | | | +--------+---------+ | | | | MIB | | | | | | | | +-------+ | | | +--------V------------+ | | | | | | | Generic: Model- | | | | | | | | Active : Specific | | | | +----------V---------------+ | | | Alarms : Extensions | | | | | RFC 2573 | | | +---------------------+ | | | | SNMP-NOTIFICATION-MIB | | | | | | | +----------+---------------+ | | +------------------+ | | | +----------------------------+ +-------------|------------------+ | V "wire" notifications Secondly, I'd suggest a slightly different way of handling the "alarm modeling". Although this may seem more elaborate than the current i-d, I think it has the advantage of requiring no magic at all. The current alarmModelTable I would replace with three tables: AlarmKind, AlarmKindStates, and AlarmKindPatterns. Each entry in AlarmKind identifies a particular alarm type that is of interest. The set of entries in AlarmKindStates corresponding to a particular entry in AlarmKind defines all of the states in that particular alarm's FSM. AlarmKindPatterns defines the patterns of interest in the notification stream. A particular notification may cause any number of patterns to "fire". The indexing structure associates patterns with the defined states for the various defined alarm types. Each pattern definition includes rules for extracting instance identification information from the notification. When a pattern associated with a particular alarm kind in a particular state for a particular resource fires, either an existing active alarm will be transitioned to a new state, or if appropriate, a new active alarm will be created. AlarmKind ---+---> AlarmKindState ----+---> AlarmKindPattern +---> AlarmKindState +---> AlarmKindPattern +---> ... +---> ... A particular active alarm could be matched back to its AlarmKind and AlarmKindState. Given an AlarmKind and AlarmKindState, one could consult the AlarmKindPatterns to figure out the possibilities for the next transition. A sketch: AlarmKind[Owner, AlarmKind] - RowStatus, StorageType - description of alarm for humans - +/- enabled (this kind of alarm) - +/- notify on raise - +/- notify on clear - an entry in this table describes a particular kind of alarm that is being modeled. AlarmKindStates[Owner, AlarmKind, StateNumber] - description of particular node in alarm's state machine - RowStatus, StorageType - +/- notify on entering this state - +/- notify on leaving this state (Having both the AlarmKind and AlarmKindStates notification enablers is overkill. I think just having the enables on AlarmKind is sufficient, but folks interested in escalation might argue otherwise.) AlarmKindPatterns[Owner, AlarmKind, StateNumber, PatternNumber] - entries in this table describe the patterns in the notification stream that can trigger state transitions for the various kinds of alarms that are of interest. When a notification matches the pattern described in an entry in this table, the resource identification information is extracted (see below), and if an Active Alarm of this AlarmKind for the identified resource exists and its sate matches StateNumber, then the active alarm will be transitioned to "nextState". If StateNumber is 0 (reserved for "clear"), a match will cause creation of a new active alarm of this kind for the extracted resource id. - Notification OID matching rule - varbind matching - if any varbind is in subtree of given oid (0.0 means don't care) - resource id extraction use context from notification, and define a small number of objects to control choice of: - spliced object id: extract index part of varbind name (subtree of given OID), tack onto another oid base. - object id if varbind is in subtree of given oid (this is special case of previous one) - object id of resource specified in model - value of a matching varbind (of type oid) - etc. - nextState, 0 for clear - RowStatus, StorageType What are important differences from current id? 1) explicit rules for resource id extraction, part of notification pattern matching 2) permits multiple notification types to trigger a given transition in state machine 3) varbind processing is *not* positional This model permits powerful extensions with relatively little effort. For example, aging, escalation, and supplemental varbinds would all be done with simple extensions of these tables. Just a (lengthy) thought. ------------------------------------------------------ Randy Presuhn BMC Software, Inc. 1-3141 randy_presuhn@bmc.com 2141 North First Street Tel: +1 408 546-1006 San José, California 95131 USA ------------------------------------------------------ My opinions and BMC's are independent variables. ------------------------------------------------------ From owner-disman@dorothy.bmc.com Tue Apr 23 18:07:42 2002 Received: from babbler.bmc.com (camaro.bmc.com [198.207.223.231]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07977 for ; Tue, 23 Apr 2002 18:07:42 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g3NMAMQ00097; Tue, 23 Apr 2002 17:10:22 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id PAA25769 for disman-list; Tue, 23 Apr 2002 15:03:44 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id PAA25763 for ; Tue, 23 Apr 2002 15:03:40 -0700 (PDT) Received: from mx-us-hou-1-int.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id g3NM1Qc08453 for ; Tue, 23 Apr 2002 17:01:26 -0500 (CDT) Received: from riverstonenet.com (unknown [63.113.148.10]) by mx-us-hou-1-int.bmc.com (Postfix) with SMTP id DC31120EFB4 for ; Tue, 23 Apr 2002 17:05:13 -0500 (CDT) Received: from dperkins-nb2.dsperkins.com by riverstonenet.com (8.9.3+Sun/SMI-SVR4-Yago) id PAA24370; Tue, 23 Apr 2002 15:05:13 -0700 (PDT) Message-Id: <5.0.2.1.2.20020423144132.02cc6190@mail4.bayarea.net> X-Sender: dperkins@mail4.bayarea.net X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Tue, 23 Apr 2002 15:04:52 -0700 To: disman@dorothy.bmc.com From: "David T. Perkins" Subject: Re: making AlarmModel more explicit In-Reply-To: <200204232126.OAA25608@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 HI, Randy - thanks for the assistance. More comments on it after I've read through it thoroughly. Just a few now... 1) this, like the previous one seems to want to use the existing notification mechanisms. However, there are problems, because some notification definitions require that the code that internally generates calls to the API to the SNMP engine to distribute the notification MUST rate-limit the calls to the API. If so, you may not see all alarms (you don't see the raise), and more importantly you don't see the clear. 2) the picture below (I believe) incorrect in describing the flow from the engine API. The notification table from the notification MIB module is first consulted, not the targets table from the target MIB module. Not sure that the notification log MIB module fits where you have placed it. So, not sure that all of the plumbing results in water with pressure where you want it instead of water on the floor. (internal) notification stream | alarmActiveState / alarmClearState internal API to |<-----------------------------------------------+ SNMP engine -\| | +------------------V-------------+ | | | | | | +---------------V----------+ | | | | RFC 2573 | | | | | SNMP-TARGET-MIB | | | | +---+------+-------------+-+ | +----------------------------+ | | | | | | | +------------------+ | | | V | +-------->--> Alarm Modelling | | | | +-------+ | | | | (descriptions) | | | | | Log | | | | +--------+---------+ | | | | MIB | | | | | | | | +-------+ | | | +--------V------------+ | | | | | | | Generic: Model- | | | | | | | | Active : Specific | | | | +----------V---------------+ | | | Alarms : Extensions | | | | | RFC 2573 | | | +---------------------+ | | | | SNMP-NOTIFICATION-MIB | | | | | | | +----------+---------------+ | | +------------------+ | | | +----------------------------+ +-------------|------------------+ | V "wire" notifications 3) It sort of seemed to me that if this system was to use the existing notification stream, that the system would convert existing notifications to new notifications that were "alarm reports". And if one was to follow the ITU module, then the 10s of IETF notifications and 100s of vendor notifications would be converted to one the four ITU alarm reports (ignoring the security ones for now). (For example, a potential linkDown would be converted into a "communicationsAlarm notification" and it sent out, and not the linkDown notification. If so, how is this done? Otherwise, on alarms a manager would receive the original notification and the alarm notification (if these were not filtered by the notification filters specified in RFC 2573.) Regards, /david t. perkins From owner-disman@dorothy.bmc.com Tue Apr 23 18:23:55 2002 Received: from babbler.bmc.com (firebird.bmc.com [198.207.223.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08236 for ; Tue, 23 Apr 2002 18:23:55 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g3NMQXP02273; Tue, 23 Apr 2002 17:26:34 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id PAA25841 for disman-list; Tue, 23 Apr 2002 15:20:00 -0700 (PDT) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id PAA25835 for disman@dorothy.bmc.com; Tue, 23 Apr 2002 15:19:56 -0700 (PDT) Date: Tue, 23 Apr 2002 15:19:56 -0700 (PDT) From: Randy Presuhn Message-Id: <200204232219.PAA25835@dorothy.bmc.com> To: disman@dorothy.bmc.com Subject: Re: making AlarmModel more explicit 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: <5.0.2.1.2.20020423144132.02cc6190@mail4.bayarea.net> > Date: Tue, 23 Apr 2002 15:04:52 -0700 > To: disman@dorothy.bmc.com > From: "David T. Perkins" > Subject: Re: making AlarmModel more explicit > In-Reply-To: <200204232126.OAA25608@dorothy.bmc.com> ... > 1) this, like the previous one seems to want to use the existing > notification mechanisms. However, there are problems, because > some notification definitions require that the code that > internally generates calls to the API to the SNMP engine to > distribute the notification MUST rate-limit the calls to the > API. If so, you may not see all alarms (you don't see the > raise), and more importantly you don't see the clear. ... To some extent, the condition MIB would have provided a little help here. However, I agree that the way rate-limiting has been formulated at the notification-type definition level is a problem for us, and I don't see any good way around it without pushing active alarm objects closer to the instrumentation implementation, which would bring with it a whole different set of really ugly problems. I suspect this is just a problem we'll have to live with. I wonder about just how significant a problem it would be in operation. Occasionally the question of a general solution to the rate- limiting problem resurfaces. I think it'd be interesting to speculate on how things would behave if we had done it at the same point in the processing flow as the RFC 2573 notification mib. ------------------------------------------------------ Randy Presuhn BMC Software, Inc. 1-3141 randy_presuhn@bmc.com 2141 North First Street Tel: +1 408 546-1006 San José, California 95131 USA ------------------------------------------------------ My opinions and BMC's are independent variables. ------------------------------------------------------ From owner-disman@dorothy.bmc.com Tue Apr 23 18:26:30 2002 Received: from babbler.bmc.com (firebird.bmc.com [198.207.223.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08288 for ; Tue, 23 Apr 2002 18:26:29 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g3NMTCZ02563; Tue, 23 Apr 2002 17:29:12 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id PAA25856 for disman-list; Tue, 23 Apr 2002 15:22:40 -0700 (PDT) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id PAA25850 for disman@dorothy.bmc.com; Tue, 23 Apr 2002 15:22:37 -0700 (PDT) Date: Tue, 23 Apr 2002 15:22:37 -0700 (PDT) From: Randy Presuhn Message-Id: <200204232222.PAA25850@dorothy.bmc.com> To: disman@dorothy.bmc.com Subject: Re: making AlarmModel more explicit 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: <5.0.2.1.2.20020423144132.02cc6190@mail4.bayarea.net> > Date: Tue, 23 Apr 2002 15:04:52 -0700 > To: disman@dorothy.bmc.com > From: "David T. Perkins" > Subject: Re: making AlarmModel more explicit > In-Reply-To: <200204232126.OAA25608@dorothy.bmc.com> ... > 2) the picture below (I believe) incorrect in describing the flow > from the engine API. The notification table from the > notification MIB module is first consulted, not the targets > table from the target MIB module. Not sure that the notification > log MIB module fits where you have placed it. So, not sure > that all of the plumbing results in water with pressure where > you want it instead of water on the floor. ... My error. Swap the Notification and Target MIB labels in the ASCII art and it should suddenly make *much* more sense. ------------------------------------------------------ Randy Presuhn BMC Software, Inc. 1-3141 randy_presuhn@bmc.com 2141 North First Street Tel: +1 408 546-1006 San José, California 95131 USA ------------------------------------------------------ My opinions and BMC's are independent variables. ------------------------------------------------------ From owner-disman@dorothy.bmc.com Tue Apr 23 18:31:17 2002 Received: from babbler.bmc.com (camaro.bmc.com [198.207.223.231]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08387 for ; Tue, 23 Apr 2002 18:31:17 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g3NMXwY03159; Tue, 23 Apr 2002 17:33:58 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id PAA25888 for disman-list; Tue, 23 Apr 2002 15:27:16 -0700 (PDT) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id PAA25882 for disman@dorothy.bmc.com; Tue, 23 Apr 2002 15:27:12 -0700 (PDT) Date: Tue, 23 Apr 2002 15:27:12 -0700 (PDT) From: Randy Presuhn Message-Id: <200204232227.PAA25882@dorothy.bmc.com> To: disman@dorothy.bmc.com Subject: Re: making AlarmModel more explicit 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: <5.0.2.1.2.20020423144132.02cc6190@mail4.bayarea.net> > Date: Tue, 23 Apr 2002 15:04:52 -0700 > To: disman@dorothy.bmc.com > From: "David T. Perkins" > Subject: Re: making AlarmModel more explicit > In-Reply-To: <200204232126.OAA25608@dorothy.bmc.com> ... > 3) It sort of seemed to me that if this system was to use the > existing notification stream, that the system would convert > existing notifications to new notifications that were > "alarm reports". And if one was to follow the ITU module, > then the 10s of IETF notifications and 100s of vendor > notifications would be converted to one the four ITU > alarm reports (ignoring the security ones for now). > (For example, a potential linkDown would be converted > into a "communicationsAlarm notification" and it sent > out, and not the linkDown notification. If so, how is > this done? Otherwise, on alarms a manager would receive > the original notification and the alarm notification > (if these were not filtered by the notification > filters specified in RFC 2573.) ... This is a question of goals. I believe the goal is to provide objects corresponding to the current set of "active alarms" in a system, rather than mapping notifications into a stream that would look more like X.733. My recollection from one of our many meetings in Minneapolis was that we hoped that such "generic alarm notification types" suitable for massive re-use would end up in the ARC document. ------------------------------------------------------ Randy Presuhn BMC Software, Inc. 1-3141 randy_presuhn@bmc.com 2141 North First Street Tel: +1 408 546-1006 San José, California 95131 USA ------------------------------------------------------ My opinions and BMC's are independent variables. ------------------------------------------------------ From owner-disman@dorothy.bmc.com Wed Apr 24 07:32:51 2002 Received: from babbler.bmc.com (camaro.bmc.com [198.207.223.231]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29824 for ; Wed, 24 Apr 2002 07:32:50 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g3OBZQV26834; Wed, 24 Apr 2002 06:35:26 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id EAA27797 for disman-list; Wed, 24 Apr 2002 04:29:25 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id EAA27792 for ; Wed, 24 Apr 2002 04:29:21 -0700 (PDT) Received: from mx-us-hou-1-int.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id g3OBR7K20865 for ; Wed, 24 Apr 2002 06:27:07 -0500 (CDT) Received: from iere.net.avaya.com (unknown [198.152.12.101]) by mx-us-hou-1-int.bmc.com (Postfix) with SMTP id 3D40920EFD7 for ; Wed, 24 Apr 2002 06:30:55 -0500 (CDT) Received: from iere.net.avaya.com (localhost [127.0.0.1]) by iere.net.avaya.com (8.11.2/8.9.3) with ESMTP id g3OBTBT19101 for ; Wed, 24 Apr 2002 07:29:11 -0400 (EDT) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by iere.net.avaya.com (8.11.2/8.9.3) with ESMTP id g3OBTAb19074 for ; Wed, 24 Apr 2002 07:29:10 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Use of alarmListName Date: Wed, 24 Apr 2002 14:28:44 +0300 Message-ID: Thread-Topic: Use of alarmListName Thread-Index: AcHq8xcE2jbE/N9fSDiRQXD7JJYN6QACcPhg From: "Romascanu, Dan (Dan)" To: "David T. Perkins" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by dorothy.bmc.com id EAA27793 Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list Content-Transfer-Encoding: 8bit David, I am not sure what you are asking here. The object that is being used for the mapping is alarmModelNotificationId. What is not complete? You started with a different question, concerning alarm classification which Randy addressed correctly. Regards, Dan > -----Original Message----- > From: David T. Perkins [mailto:dperkins@dsperkins.com] > Sent: Tuesday, April 23, 2002 9:17 PM > To: disman@dorothy.bmc.com > Subject: Re: Use of alarmListName > > > HI, > > I was first trying to get clarification on the "simpler" of the three > ways that alarms are defined. If this could be clarified, then > the other two ways might be obvious. > > The first was via "existing" notifications. The second was via > the two new notifications (alarmActiveState and alarmClearState). > The third is via internal mechanisms (that is, > alarmModelNotificationId > has the value { 0 0 }). > > Did I get this correct? > > One of the fundamental goals of the I-D appears to me to use the > existing notifications generated by a system, and to create a > system that mapped these existing notifications to alarm raises > (with configured severity) or to alarm clears. > How this is done doesn't seem complete to me. > > > At 10:32 AM 4/23/2002 -0700, Randy Presuhn wrote: > >Hi - > > > >> Message-Id: <5.0.2.1.2.20020423101447.03372170@mail4.bayarea.net> > >> Date: Tue, 23 Apr 2002 10:19:07 -0700 > >> To: > >> From: "David T. Perkins" > >> Subject: Use of alarmListName > >> List-Id: IETF disman Working Group mailing list > > >> > >> HI, > >> > >> The alarm draft has the tables indexed by object alarmListName. > >> > >> However, I cannot figure out how notifications are classified > >> so that they use appropriate entries in tables based on the > >> value of alarmListName. That is, what is the classifier from > >> notifications to values of alarmListName? And how is this > >> configured? > >> > >> PS Randy - feel free to restate this as a clearer and simpler > >> question. > >... > > > >I think alarmListName has nothing to do with alarm classification. > > > >Here's a not-very-useful example of how I think it's supposed > >to work. If I configure the same models under three different > >alarmListNames, and if access control policy permits, then I > >would expect that for any active alarm entry existing under > >one of the alarmListNames, there should be corresponding > >entries under both of the other alarmListNames. > > > >In short, it's to support sandboxing the users of the > >alarm facility. One *could* in a really twisted way use it > >for alarm classification (different models under different > >alarmListNames corresponding to alarm classification), but > >I don't think that that's the motivation for it. > > > >(Of course, I could have completely misunderstood the > >whole thing. :-) > > Regards, > /david t. perkins > > From owner-disman@dorothy.bmc.com Wed Apr 24 07:33:03 2002 Received: from babbler.bmc.com (camaro.bmc.com [198.207.223.231]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29837 for ; Wed, 24 Apr 2002 07:33:03 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g3OBZhn26862; Wed, 24 Apr 2002 06:35:43 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id EAA27807 for disman-list; Wed, 24 Apr 2002 04:30:13 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id EAA27801; Wed, 24 Apr 2002 04:30:09 -0700 (PDT) Received: from mx-us-hou-1-int.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id g3OBRsa21166; Wed, 24 Apr 2002 06:27:55 -0500 (CDT) Received: from iere.net.avaya.com (unknown [198.152.12.101]) by mx-us-hou-1-int.bmc.com (Postfix) with SMTP id A9C9D20EF8C; Wed, 24 Apr 2002 06:31:42 -0500 (CDT) Received: from iere.net.avaya.com (localhost [127.0.0.1]) by iere.net.avaya.com (8.11.2/8.9.3) with ESMTP id g3OBTwT19416; Wed, 24 Apr 2002 07:29:58 -0400 (EDT) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by iere.net.avaya.com (8.11.2/8.9.3) with ESMTP id g3OBTvb19409; Wed, 24 Apr 2002 07:29:57 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Pairing instances in RMON example Date: Wed, 24 Apr 2002 14:29:31 +0300 Message-ID: Thread-Topic: Pairing instances in RMON example Thread-Index: AcHq3yUL8+KCIGyaQt2/QpVz1e1RNgALMFLQ From: "Romascanu, Dan (Dan)" To: "Randy Presuhn" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by dorothy.bmc.com id EAA27802 Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list Content-Transfer-Encoding: 8bit > -----Original Message----- > From: Randy Presuhn [mailto:rpresuhn@dorothy.bmc.com] > Sent: Tuesday, April 23, 2002 6:53 PM > To: disman@dorothy.bmc.com > Subject: Re: Pairing instances in RMON example > > > Hi - > > > From: "Stefan Wallin" > > To: > > Subject: Pairing instances in RMON example > > Date: Tue, 23 Apr 2002 16:43:29 +0200 > > Message-ID: > > > In-Reply-To: <5.0.2.1.2.20020422172156.03b39bd0@mail4.bayarea.net> > ... > > 2) However the more general question is: > > Lets say I define two alarms in the RMON alarmTable: > > alarmVariable X, risingThreshold 10, fallingthreshold 8 > > alarmVariable Y, risingThreshold 20, fallingthreshold 16 > > > > In this case it is extremely important that fallingAlarm > Threshold on Y > > does not clear any active alarm on X. > > How do we describe that? Miss something in the > alarmModelTable to point to > > resource var-bind in case the generic notifications are not used. > > (Resembles Perkins ifIndex example). What is the conclusion on the > > previous issue here? > ... > > I agree that there's a problem. For this to work as intended, > the resource needs to be identified. At the moment, this looks > like magic. Perhaps some of the tricks from the expression > MIB or the snmpconf work might be appropriate. > > ------------------------------------------------------ This is a good one. The way it can be solved without too much magic being involved is to add an object to the alarmModelTable that would help distinguish between the two different alarms in the RMON alarmTable, for example by pointing to the specific index. The question is whether we cam make it generic enough, but not too complex to look like magic, or maybe the RMON case is important enough to have something specifically targeting RMON. Regards, Dan From owner-disman@dorothy.bmc.com Wed Apr 24 07:56:06 2002 Received: from babbler.bmc.com (camaro.bmc.com [198.207.223.231]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00379 for ; Wed, 24 Apr 2002 07:56:06 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g3OBwjx29319; Wed, 24 Apr 2002 06:58:46 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id EAA27881 for disman-list; Wed, 24 Apr 2002 04:53:03 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id EAA27874 for ; Wed, 24 Apr 2002 04:52:59 -0700 (PDT) From: stefan.wallin@dataductus.se Received: from mx-us-hou-2-int.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id g3OBojm00903 for ; Wed, 24 Apr 2002 06:50:45 -0500 (CDT) Received: from mogwai.dataductus.se (mogwai2.dataductus.se [213.199.99.186]) by mx-us-hou-2-int.bmc.com (Postfix) with SMTP id 3F36E1FF011 for ; Wed, 24 Apr 2002 06:54:28 -0500 (CDT) Received: (from nobody@localhost) by mogwai.dataductus.se (8.11.6/8.11.6) id g3OBomG03432 for disman@dorothy.bmc.com; Wed, 24 Apr 2002 13:50:48 +0200 X-Authentication-Warning: mogwai.dataductus.se: nobody set sender to stefan.wallin@dataductus.se using -f Received: from 213.66.198.246 ( [213.66.198.246]) as user ddskswa@imap.dataductus.se by webmail2.dataductus.se with HTTP; Wed, 24 Apr 2002 13:50:47 +0200 Message-ID: <1019649047.3cc69c17e3bf0@webmail2.dataductus.se> Date: Wed, 24 Apr 2002 13:50:47 +0200 To: disman@dorothy.bmc.com Subject: RE: Pairing instances in RMON example References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.0 X-Originating-IP: 213.66.198.246 Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list Content-Transfer-Encoding: 8bit Hi, maybe I'm simplifying things but the addition of a row to alarmModelTable specifying which var-bind of the alarmModelNotificationId carries the resourceid. The general rule in the mgmt app: same alarm id AND same resource id -> correlate alarm and alarm clear. Assumption: alarm id is modelled/used fine-grained so that different event types and probable cause have different alarm id's. In X733 alarm conceptual model an alarm raise and alarm clear is correlated if they have same: -eventtype -probablecause -object The resource identifier to use in this case would be a reference to the alarmTable row, (note, not the value of the alarmVariable since we can have several measurements on the same alarmVariable). This is carried by var-bind 1 in risingAlarm, oops, an index variable. Does not matter could as well use var-bind 2 since it would embed the index. regards Stefan Citerar "Romascanu, Dan (Dan)" : > > > > -----Original Message----- > > From: Randy Presuhn [mailto:rpresuhn@dorothy.bmc.com] > > Sent: Tuesday, April 23, 2002 6:53 PM > > To: disman@dorothy.bmc.com > > Subject: Re: Pairing instances in RMON example > > > > > > Hi - > > > > > From: "Stefan Wallin" > > > To: > > > Subject: Pairing instances in RMON example > > > Date: Tue, 23 Apr 2002 16:43:29 +0200 > > > Message-ID: > > > > > In-Reply-To: <5.0.2.1.2.20020422172156.03b39bd0@mail4.bayarea.net> > > ... > > > 2) However the more general question is: > > > Lets say I define two alarms in the RMON alarmTable: > > > alarmVariable X, risingThreshold 10, fallingthreshold 8 > > > alarmVariable Y, risingThreshold 20, fallingthreshold 16 > > > > > > In this case it is extremely important that fallingAlarm > > Threshold on Y > > > does not clear any active alarm on X. > > > How do we describe that? Miss something in the > > alarmModelTable to point to > > > resource var-bind in case the generic notifications are not used. > > > (Resembles Perkins ifIndex example). What is the conclusion on the > > > previous issue here? > > ... > > > > I agree that there's a problem. For this to work as intended, > > the resource needs to be identified. At the moment, this looks > > like magic. Perhaps some of the tricks from the expression > > MIB or the snmpconf work might be appropriate. > > > > ------------------------------------------------------ > > This is a good one. The way it can be solved without too much magic being > involved is to add an object to the alarmModelTable that would help > distinguish between the two different alarms in the RMON alarmTable, for > example by pointing to the specific index. The question is whether we cam > make it generic enough, but not too complex to look like magic, or maybe the > RMON case is important enough to have something specifically targeting > RMON. > > Regards, > > Dan > From owner-disman@dorothy.bmc.com Wed Apr 24 10:01:38 2002 Received: from babbler.bmc.com (firebird.bmc.com [198.207.223.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07297 for ; Wed, 24 Apr 2002 10:01:37 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g3OE3oZ20236; Wed, 24 Apr 2002 09:03:53 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id GAA28147 for disman-list; Wed, 24 Apr 2002 06:57:11 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id GAA28142 for ; Wed, 24 Apr 2002 06:57:07 -0700 (PDT) Received: from mx-us-hou-1-int.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id g3ODsrC04485 for ; Wed, 24 Apr 2002 08:54:53 -0500 (CDT) Received: from zcars04e.ca.nortel.com (unknown [47.129.242.56]) by mx-us-hou-1-int.bmc.com (Postfix) with SMTP id 3649520EF8C for ; Wed, 24 Apr 2002 08:58:41 -0500 (CDT) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g3ODwXT11592 for ; Wed, 24 Apr 2002 09:58:33 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 24 Apr 2002 09:58:35 -0400 Message-ID: <3549C09B853DD5119B540002A52CDD3402E96EE0@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: disman@dorothy.bmc.com Subject: RE: Totals are counters Date: Wed, 24 Apr 2002 09:58:33 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list hi The Definitions: -- this wraps Counter32 ::= [APPLICATION 1] IMPLICIT INTEGER (0..4294967295) -- this doesn't wrap Gauge32 ::= [APPLICATION 2] IMPLICIT INTEGER (0..4294967295) Our Statistics: ituAlarmActiveStatsIndeterminateCurrent Gauge32, ituAlarmActiveStatsCriticalCurrent Gauge32, ituAlarmActiveStatsMajorCurrent Gauge32, ituAlarmActiveStatsMinorCurrent Gauge32, ituAlarmActiveStatsWarningCurrent Gauge32, ituAlarmActiveStatsIndeterminateTotal Counter32, ituAlarmActiveStatsCriticalTotal Counter32, ituAlarmActiveStatsMajorTotal Counter32, ituAlarmActiveStatsMinorTotal Counter32, ituAlarmActiveStatsWarningTotal Counter32 Do I really want my current counts to wrap? Is it better falsely show my current major alarm count to be 4294967295 or 3? Sharon -----Original Message----- From: David T. Perkins [mailto:dperkins@dsperkins.com] Sent: Thursday, April 18, 2002 2:34 AM To: disman@dorothy.bmc.com Subject: Totals are counters Hi, The object alarmActiveStatsTotalActive should be a counter and not a Gauge32. Note that the following objects are correctly specified as counters: ituAlarmActiveStatsIndeterminateTotal ituAlarmActiveStatsCriticalTotal ituAlarmActiveStatsMajorTotal ituAlarmActiveStatsMinorTotal ituAlarmActiveStatsWarningTotal Regards, /david t. perkins From owner-disman@dorothy.bmc.com Wed Apr 24 10:42:46 2002 Received: from babbler.bmc.com (firebird.bmc.com [198.207.223.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15127 for ; Wed, 24 Apr 2002 10:42:45 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g3OEjJm29505; Wed, 24 Apr 2002 09:45:19 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id HAA28246 for disman-list; Wed, 24 Apr 2002 07:39:18 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id HAA28241 for ; Wed, 24 Apr 2002 07:39:14 -0700 (PDT) Received: from mx-us-hou-2-int.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id g3OEaxt00104 for ; Wed, 24 Apr 2002 09:36:59 -0500 (CDT) Received: from agitator.ibr.cs.tu-bs.de (agitator.ibr.cs.tu-bs.de [134.169.34.18]) by mx-us-hou-2-int.bmc.com (Postfix) with SMTP id 7D2BD1FF06D for ; Wed, 24 Apr 2002 09:40:45 -0500 (CDT) Received: from haerke.ibr.cs.tu-bs.de (IDENT:root@haerke.ibr.cs.tu-bs.de [134.169.34.84]) by agitator.ibr.cs.tu-bs.de (8.12.1/8.12.1/Debian -2) with ESMTP id g3OEeMN4011811; Wed, 24 Apr 2002 16:40:22 +0200 Received: (from schoenw@localhost) by haerke.ibr.cs.tu-bs.de (8.11.6/8.11.6) id g3OEeMp18697; Wed, 24 Apr 2002 16:40:22 +0200 Date: Wed, 24 Apr 2002 16:40:22 +0200 Message-Id: <200204241440.g3OEeMp18697@haerke.ibr.cs.tu-bs.de> X-Authentication-Warning: haerke.ibr.cs.tu-bs.de: schoenw set sender to schoenw@ibr.cs.tu-bs.de using -f From: Juergen Schoenwaelder To: schishol@nortelnetworks.com Cc: disman@dorothy.bmc.com In-reply-to: <3549C09B853DD5119B540002A52CDD3402E96EE0@zcard0ka.ca.nortel.com> (schishol@nortelnetworks.com) Subject: Re: Totals are counters References: <3549C09B853DD5119B540002A52CDD3402E96EE0@zcard0ka.ca.nortel.com> Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list >>>>> Sharon Chisholm writes: Sharon> The Definitions: Sharon> -- this wraps Counter32 ::= [APPLICATION 1] IMPLICIT Sharon> INTEGER (0..4294967295) Sharon> -- this doesn't wrap Gauge32 ::= [APPLICATION 2] Sharon> IMPLICIT INTEGER (0..4294967295) Sharon> Our Statistics: [...] Sharon> Do I really want my current counts to wrap? Is it better Sharon> falsely show my current major alarm count to be 4294967295 or Sharon> 3? I think it is important to discuss what these numbers really model. Let me pick an example: ituAlarmActiveStatsIndeterminateCurrent OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "A count of the current number of active alarms with a ituAlarmPerceivedSeverity of indeterminate." ::= { ituAlarmActiveStatsEntry 1 } ituAlarmActiveStatsIndeterminateTotal OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "A count of the total number of active alarms with a ituAlarmPerceivedSeverity of indeterminate since system restart." ::= { ituAlarmActiveStatsEntry 6 } I am not 100% sure I understand the descriptions correctly. Perhaps you mean: ituAlarmActiveStatsIndeterminateCurrent OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "A current number of active alarms with a ituAlarmPerceivedSeverity of indeterminate." ::= { ituAlarmActiveStatsEntry 1 } ituAlarmActiveStatsIndeterminateTotal OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "A count of active alarms with a ituAlarmPerceivedSeverity of indeterminate since system restart." ::= { ituAlarmActiveStatsEntry 6 } These descritions would be clearer to me and with them, I would agree that Gauge32 and Counter32 are used properly. /js -- Juergen Schoenwaelder From owner-disman@dorothy.bmc.com Wed Apr 24 12:43:47 2002 Received: from babbler.bmc.com (firebird.bmc.com [198.207.223.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27255 for ; Wed, 24 Apr 2002 12:43:46 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g3OGkE129945; Wed, 24 Apr 2002 11:46:17 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id JAA28477 for disman-list; Wed, 24 Apr 2002 09:40:14 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id JAA28472 for ; Wed, 24 Apr 2002 09:40:10 -0700 (PDT) Received: from mx-us-hou-1-int.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id g3OGbup12907 for ; Wed, 24 Apr 2002 11:37:56 -0500 (CDT) Received: from riverstonenet.com (unknown [63.113.148.10]) by mx-us-hou-1-int.bmc.com (Postfix) with SMTP id 431D320EF90 for ; Wed, 24 Apr 2002 11:41:44 -0500 (CDT) Received: from dperkins-nb2.dsperkins.com by riverstonenet.com (8.9.3+Sun/SMI-SVR4-Yago) id JAA10694; Wed, 24 Apr 2002 09:41:29 -0700 (PDT) Message-Id: <5.0.2.1.2.20020424082022.02cfa380@mail4.bayarea.net> X-Sender: dperkins@mail4.bayarea.net X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Wed, 24 Apr 2002 08:23:54 -0700 To: Juergen Schoenwaelder , schishol@nortelnetworks.com From: "David T. Perkins" Subject: Re: Totals are counters Cc: disman@dorothy.bmc.com In-Reply-To: <200204241440.g3OEeMp18697@haerke.ibr.cs.tu-bs.de> References: <3549C09B853DD5119B540002A52CDD3402E96EE0@zcard0ka.ca.nortel.com> <3549C09B853DD5119B540002A52CDD3402E96EE0@zcard0ka.ca.nortel.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 HI, Yes, it all depends on the semantics. Also note that if you read the MIB module further, there are other objects with similar descriptions that are counters. At 04:40 PM 4/24/2002 +0200, Juergen Schoenwaelder wrote: >>>>>> Sharon Chisholm writes: > >Sharon> The Definitions: > >Sharon> -- this wraps Counter32 ::= [APPLICATION 1] IMPLICIT >Sharon> INTEGER (0..4294967295) > >Sharon> -- this doesn't wrap Gauge32 ::= [APPLICATION 2] >Sharon> IMPLICIT INTEGER (0..4294967295) > >Sharon> Our Statistics: > >[...] > >Sharon> Do I really want my current counts to wrap? Is it better >Sharon> falsely show my current major alarm count to be 4294967295 or >Sharon> 3? > >I think it is important to discuss what these numbers really >model. Let me pick an example: > > ituAlarmActiveStatsIndeterminateCurrent OBJECT-TYPE > SYNTAX Gauge32 > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "A count of the current number of active alarms with a > ituAlarmPerceivedSeverity of indeterminate." > ::= { ituAlarmActiveStatsEntry 1 } > > ituAlarmActiveStatsIndeterminateTotal OBJECT-TYPE > SYNTAX Counter32 > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "A count of the total number of active alarms with a > ituAlarmPerceivedSeverity of indeterminate since system > restart." > ::= { ituAlarmActiveStatsEntry 6 } > >I am not 100% sure I understand the descriptions correctly. Perhaps >you mean: > > ituAlarmActiveStatsIndeterminateCurrent OBJECT-TYPE > SYNTAX Gauge32 > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "A current number of active alarms with a > ituAlarmPerceivedSeverity of indeterminate." > ::= { ituAlarmActiveStatsEntry 1 } > > ituAlarmActiveStatsIndeterminateTotal OBJECT-TYPE > SYNTAX Counter32 > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "A count of active alarms with a ituAlarmPerceivedSeverity > of indeterminate since system restart." > ::= { ituAlarmActiveStatsEntry 6 } > >These descritions would be clearer to me and with them, I would agree >that Gauge32 and Counter32 are used properly. > >/js > >-- >Juergen Schoenwaelder Regards, /david t. perkins From owner-disman@dorothy.bmc.com Wed Apr 24 15:02:56 2002 Received: from babbler.bmc.com (camaro.bmc.com [198.207.223.231]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03354 for ; Wed, 24 Apr 2002 15:02:56 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g3OJ5aQ11038; Wed, 24 Apr 2002 14:05:36 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id LAA29268 for disman-list; Wed, 24 Apr 2002 11:59:18 -0700 (PDT) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id LAA29262 for disman@dorothy.bmc.com; Wed, 24 Apr 2002 11:59:14 -0700 (PDT) Date: Wed, 24 Apr 2002 11:59:14 -0700 (PDT) From: Randy Presuhn Message-Id: <200204241859.LAA29262@dorothy.bmc.com> To: disman@dorothy.bmc.com Subject: RE: Use of alarmListName 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 - > Subject: RE: Use of alarmListName > Date: Wed, 24 Apr 2002 14:28:44 +0300 > Message-ID: > From: "Romascanu, Dan (Dan)" > To: "David T. Perkins" , ... > I am not sure what you are asking here. The object that is being > used for the mapping is alarmModelNotificationId. What is not complete? ... I think the concern is this: - notification arrives - the implementation searches the alarmModelTable to find any entries where alarmModelNotificationId matches the notification that arrived - from each of these entries, we extract the tuple and alarmModelState - we now search the alarmActiveTable, looking for any active alarms matching so we can apply the new alarmModelState to them. There's just one problem. We should only apply this to ones with the "right" alarmActiveResourceId. This is the part of the mapping process that's not complete. ------------------------------------------------------ Randy Presuhn BMC Software, Inc. 1-3141 randy_presuhn@bmc.com 2141 North First Street Tel: +1 408 546-1006 San José, California 95131 USA ------------------------------------------------------ My opinions and BMC's are independent variables. ------------------------------------------------------ From owner-disman@dorothy.bmc.com Wed Apr 24 15:07:02 2002 Received: from babbler.bmc.com (firebird.bmc.com [198.207.223.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03495 for ; Wed, 24 Apr 2002 15:07:02 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g3OJ9cW11694; Wed, 24 Apr 2002 14:09:38 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id MAA29310 for disman-list; Wed, 24 Apr 2002 12:04:07 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id MAA29305 for ; Wed, 24 Apr 2002 12:04:03 -0700 (PDT) Received: from mx-us-hou-2-int.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id g3OJ1kG01297 for ; Wed, 24 Apr 2002 14:01:46 -0500 (CDT) Received: from msgbas1.cos.agilent.com (msgbas1x.cos.agilent.com [192.25.240.36]) by mx-us-hou-2-int.bmc.com (Postfix) with SMTP id B7EAC1FF083 for ; Wed, 24 Apr 2002 14:05:34 -0500 (CDT) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas1.cos.agilent.com (Postfix) with ESMTP id 5B1E2B9ED for ; Wed, 24 Apr 2002 13:05:24 -0600 (MDT) Received: from axcsbh1.cos.agilent.com (axcsbh1.cos.agilent.com [130.29.152.143]) by msgrel1.cos.agilent.com (Postfix) with ESMTP id 4344E599 for ; Wed, 24 Apr 2002 13:05:24 -0600 (MDT) Received: by axcsbh1.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Wed, 24 Apr 2002 13:05:24 -0600 Message-ID: <1BEBA5E8600DD4119A50009027AF54A00870E80D@axcs04.cos.agilent.com> From: "TRISTAN,GEORGE (A-FtCollins,ex1)" To: "'disman@dorothy.bmc.com'" Subject: unsubscribe Date: Wed, 24 Apr 2002 13:05:22 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list unsubscribe disman george_tristan@agilent.com From owner-disman@dorothy.bmc.com Wed Apr 24 15:14:53 2002 Received: from babbler.bmc.com (camaro.bmc.com [198.207.223.231]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03776 for ; Wed, 24 Apr 2002 15:14:52 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g3OJHXr15075; Wed, 24 Apr 2002 14:17:33 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id MAA29339 for disman-list; Wed, 24 Apr 2002 12:11:56 -0700 (PDT) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id MAA29333 for disman@dorothy.bmc.com; Wed, 24 Apr 2002 12:11:52 -0700 (PDT) Date: Wed, 24 Apr 2002 12:11:52 -0700 (PDT) From: Randy Presuhn Message-Id: <200204241911.MAA29333@dorothy.bmc.com> To: disman@dorothy.bmc.com Subject: RE: Totals are counters 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: <3549C09B853DD5119B540002A52CDD3402E96EE0@zcard0ka.ca.nortel.com> > From: "Sharon Chisholm" > To: disman@dorothy.bmc.com > Subject: RE: Totals are counters > Date: Wed, 24 Apr 2002 09:58:33 -0400 ... > The Definitions: > > -- this wraps > Counter32 ::= > [APPLICATION 1] > IMPLICIT INTEGER (0..4294967295) > > -- this doesn't wrap > Gauge32 ::= > [APPLICATION 2] > IMPLICIT INTEGER (0..4294967295) It's misleading to quote just this without also including RFC 2578 sections 7.1.6 and 7.1.7 which give the full story. > Our Statistics: > > ituAlarmActiveStatsIndeterminateCurrent Gauge32, > ituAlarmActiveStatsCriticalCurrent Gauge32, > ituAlarmActiveStatsMajorCurrent Gauge32, > ituAlarmActiveStatsMinorCurrent Gauge32, > ituAlarmActiveStatsWarningCurrent Gauge32, > ituAlarmActiveStatsIndeterminateTotal Counter32, > ituAlarmActiveStatsCriticalTotal Counter32, > ituAlarmActiveStatsMajorTotal Counter32, > ituAlarmActiveStatsMinorTotal Counter32, > ituAlarmActiveStatsWarningTotal Counter32 This is as it should be. > Do I really want my current counts to wrap? Is it better > falsely show my current major alarm count to be 4294967295 > or 3? ... The "current" ones, since they can go up or down, should be Gauges. The "total" ones, since they must be able to eventually wrap to support long-term tracking, should be Counters. There's no "falsely" about it. Management software that's reporting counter values is supposed to know about RFC 2578 section 7.1.6. To avoid confusing application developers that haven't read the SMI, perhaps "Total" could be changed to "Cumulative" or simply "s". ------------------------------------------------------ Randy Presuhn BMC Software, Inc. 1-3141 randy_presuhn@bmc.com 2141 North First Street Tel: +1 408 546-1006 San José, California 95131 USA ------------------------------------------------------ My opinions and BMC's are independent variables. ------------------------------------------------------ From owner-disman@dorothy.bmc.com Wed Apr 24 15:17:38 2002 Received: from babbler.bmc.com (firebird.bmc.com [198.207.223.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03977 for ; Wed, 24 Apr 2002 15:17:38 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g3OJKJw16240; Wed, 24 Apr 2002 14:20:19 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id MAA29382 for disman-list; Wed, 24 Apr 2002 12:14:48 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id MAA29377 for ; Wed, 24 Apr 2002 12:14:44 -0700 (PDT) From: george_tristan@agilent.com Received: from mx-us-hou-2-int.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id g3OJCTL07659 for ; Wed, 24 Apr 2002 14:12:29 -0500 (CDT) Received: from msgbas1.cos.agilent.com (msgbas1x.cos.agilent.com [192.25.240.36]) by mx-us-hou-2-int.bmc.com (Postfix) with SMTP id B3C331FF079 for ; Wed, 24 Apr 2002 14:16:17 -0500 (CDT) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas1.cos.agilent.com (Postfix) with ESMTP id 6EE35BACA for ; Wed, 24 Apr 2002 13:16:07 -0600 (MDT) Received: from axcsbh6.cos.agilent.com (axcsbh6.cos.agilent.com [130.29.152.171]) by msgrel1.cos.agilent.com (Postfix) with SMTP id 4EECC28F for ; Wed, 24 Apr 2002 13:16:07 -0600 (MDT) Received: from 130.29.152.171 by axcsbh6.cos.agilent.com (InterScan E-Mail VirusWall NT); Wed, 24 Apr 2002 13:16:07 -0600 Received: by axcsbh6.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Wed, 24 Apr 2002 13:16:07 -0600 Message-ID: <1BEBA5E8600DD4119A50009027AF54A00870E80E@axcs04.cos.agilent.com> To: disman@dorothy.bmc.com Subject: unsubscribe Date: Wed, 24 Apr 2002 13:16:06 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list unsubscribe disman george_tristan@agilent.com end From owner-disman@dorothy.bmc.com Wed Apr 24 15:23:05 2002 Received: from babbler.bmc.com (firebird.bmc.com [198.207.223.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04250 for ; Wed, 24 Apr 2002 15:23:04 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g3OJPjd18204; Wed, 24 Apr 2002 14:25:45 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id MAA29448 for disman-list; Wed, 24 Apr 2002 12:20:13 -0700 (PDT) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id MAA29442; Wed, 24 Apr 2002 12:20:09 -0700 (PDT) Date: Wed, 24 Apr 2002 12:20:09 -0700 (PDT) From: Randy Presuhn Message-Id: <200204241920.MAA29442@dorothy.bmc.com> To: disman@dorothy.bmc.com, george_tristan@agilent.com Subject: Re: unsubscribe 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: george_tristan@agilent.com > Message-ID: <1BEBA5E8600DD4119A50009027AF54A00870E80E@axcs04.cos.agilent.com> > To: disman@dorothy.bmc.com > Subject: unsubscribe > Date: Wed, 24 Apr 2002 13:16:06 -0600 > List-Id: IETF disman Working Group mailing list > > unsubscribe disman george_tristan@agilent.com > end A gentle reminder: adminstrative requests for ietf mailing lists generally go to -request@wherever. In this case, the correct address is: disman-request@dorothy.bmc.com As a public service, I've already removed george_tristan@agilent.com. ------------------------------------------------------ Randy Presuhn BMC Software, Inc. 1-3141 randy_presuhn@bmc.com 2141 North First Street Tel: +1 408 546-1006 San José, California 95131 USA ------------------------------------------------------ My opinions and BMC's are independent variables. ------------------------------------------------------ From owner-disman@dorothy.bmc.com Wed Apr 24 16:00:19 2002 Received: from babbler.bmc.com (camaro.bmc.com [198.207.223.231]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05682 for ; Wed, 24 Apr 2002 16:00:19 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g3OK30O26401; Wed, 24 Apr 2002 15:03:00 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id MAA29656 for disman-list; Wed, 24 Apr 2002 12:57:17 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id MAA29651 for ; Wed, 24 Apr 2002 12:57:14 -0700 (PDT) Received: from mx-us-hou-1-int.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id g3OJsxE01868 for ; Wed, 24 Apr 2002 14:54:59 -0500 (CDT) Received: from zcars04f.ca.nortel.com (unknown [47.129.242.57]) by mx-us-hou-1-int.bmc.com (Postfix) with SMTP id 80CFF20EFAA for ; Wed, 24 Apr 2002 14:57:53 -0500 (CDT) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g3OJvkN23407 for ; Wed, 24 Apr 2002 15:57:47 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 24 Apr 2002 15:57:47 -0400 Message-ID: <3549C09B853DD5119B540002A52CDD3402E97624@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: disman@dorothy.bmc.com Subject: RE: More than one notification for a state change Date: Wed, 24 Apr 2002 15:57:41 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list hi You would model them with different values for alarmModelState. The downside of this is that you may be artificially implying that these equivalent states have different severity, but I think this is balanced by the upside of keeping the model simple. It's the raise/clear relationship that is most important in practice. Sharon -----Original Message----- From: David T. Perkins [mailto:dperkins@dsperkins.com] Sent: Thursday, April 18, 2002 2:14 AM To: disman@dorothy.bmc.com Subject: More than one notification for a state change HI, What if there are more than one notification type that causes a change to the same state? The alarm model table doesn't seem to support this. How is this done? Regards, /david t. perkins From owner-disman@dorothy.bmc.com Wed Apr 24 16:17:03 2002 Received: from babbler.bmc.com (camaro.bmc.com [198.207.223.231]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05903 for ; Wed, 24 Apr 2002 16:17:03 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g3OKJh929875; Wed, 24 Apr 2002 15:19:43 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id NAA29695 for disman-list; Wed, 24 Apr 2002 13:13:56 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id NAA29688 for ; Wed, 24 Apr 2002 13:13:52 -0700 (PDT) Received: from mx-us-hou-1-int.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id g3OKBbj09957 for ; Wed, 24 Apr 2002 15:11:37 -0500 (CDT) Received: from zcars04f.ca.nortel.com (unknown [47.129.242.57]) by mx-us-hou-1-int.bmc.com (Postfix) with SMTP id C582C20F057 for ; Wed, 24 Apr 2002 15:14:08 -0500 (CDT) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g3OKE1N24609 for ; Wed, 24 Apr 2002 16:14:02 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 24 Apr 2002 16:14:02 -0400 Message-ID: <3549C09B853DD5119B540002A52CDD3402E97675@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: disman@dorothy.bmc.com Subject: RE: Pairing instances Date: Wed, 24 Apr 2002 16:14:00 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list hi Currently it is assumed that the implementer has some knowledge of the notification being used in the model. Of course if they are using the provided notifications, the resource ID is in a well defined spot within the notification, but can take any value. I don't know how practical it would be to even try and provide a standardized mechanism to identify where in a notification the resource information will be stored. My feeling is not very. Perhaps the best solution would be to add some clarifying text to the document. Sharon -----Original Message----- From: Randy Presuhn [mailto:rpresuhn@dorothy.bmc.com] Sent: Monday, April 22, 2002 8:56 PM To: disman@dorothy.bmc.com Subject: RE: Pairing instances Hi - > Message-Id: <5.0.2.1.2.20020422172156.03b39bd0@mail4.bayarea.net> > Date: Mon, 22 Apr 2002 17:39:12 -0700 > To: Randy Presuhn , disman@dorothy.bmc.com > From: "David T. Perkins" > Subject: RE: Pairing instances > In-Reply-To: <200204230008.RAA17512@dorothy.bmc.com> ... > The example below is interesting, but I'm talking about something > really basic. Much simpler than your example. ;-) The question about how the ... > code would determine the value of "alarmActiveResourceId" from > the notifications is not described. ... Agreed. This is a problem. Summing up, we have similar concerns about the alarmModelTable. A partial list, paraphrasing (or possibly reading too much into) your posts: 1) how does it the implementation figure out where to get the value for alarmActiveResourceId? (The information has to be in the notification somewhere, but how does the alarmModelTable tell the implementation where to look?) 2) what is the appropriate amount of power for describing the "finite state machine" for an alarm? 3) can a single notification "crank" more than one alarm's state machine? (This is tied to (1)) ------------------------------------------------------ Randy Presuhn BMC Software, Inc. 1-3141 randy_presuhn@bmc.com 2141 North First Street Tel: +1 408 546-1006 San José, California 95131 USA ------------------------------------------------------ My opinions and BMC's are independent variables. ------------------------------------------------------ From owner-disman@dorothy.bmc.com Wed Apr 24 16:22:54 2002 Received: from babbler.bmc.com (firebird.bmc.com [198.207.223.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06022 for ; Wed, 24 Apr 2002 16:22:54 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g3OKPZX01103; Wed, 24 Apr 2002 15:25:35 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id NAA29711 for disman-list; Wed, 24 Apr 2002 13:20:04 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id NAA29705; Wed, 24 Apr 2002 13:20:00 -0700 (PDT) Received: from mx-us-hou-2-int.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id g3OKHiM12652; Wed, 24 Apr 2002 15:17:44 -0500 (CDT) Received: from riverstonenet.com (mail.riverstonenet.com [63.113.148.10]) by mx-us-hou-2-int.bmc.com (Postfix) with SMTP id EA2A21FF09B; Wed, 24 Apr 2002 15:21:31 -0500 (CDT) Received: from dperkins-nb2.dsperkins.com by riverstonenet.com (8.9.3+Sun/SMI-SVR4-Yago) id NAA28221; Wed, 24 Apr 2002 13:10:06 -0700 (PDT) Message-Id: <5.0.2.1.2.20020424130513.02da9bc0@mail4.bayarea.net> X-Sender: dperkins@mail4.bayarea.net X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Wed, 24 Apr 2002 13:09:42 -0700 To: Randy Presuhn , disman@dorothy.bmc.com From: "David T. Perkins" Subject: RE: Use of alarmListName In-Reply-To: <200204241859.LAA29262@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 HI, Randy summarized the process below, when notifications are used to raise and clear alarms. But, my interpretation of the I-D is that two other mechanisms can also be used to raise and clear alarms. If this interpretation is correct, then for them, would also like to see the logic similar to what Randy has written below. At 11:59 AM 4/24/2002 -0700, Randy Presuhn wrote: >Hi - > >> Subject: RE: Use of alarmListName >> Date: Wed, 24 Apr 2002 14:28:44 +0300 >> Message-ID: >> From: "Romascanu, Dan (Dan)" >> To: "David T. Perkins" , >... >> I am not sure what you are asking here. The object that is being >> used for the mapping is alarmModelNotificationId. What is not complete? >... > >I think the concern is this: > > - notification arrives > - the implementation searches the alarmModelTable > to find any entries where alarmModelNotificationId matches > the notification that arrived > - from each of these entries, we extract the tuple > and alarmModelState > - we now search the alarmActiveTable, looking for any > active alarms matching so > we can apply the new alarmModelState to them. There's just > one problem. We should only apply this to ones with the > "right" alarmActiveResourceId. This is the part of the > mapping process that's not complete. Regards, /david t. perkins From owner-disman@dorothy.bmc.com Wed Apr 24 16:32:27 2002 Received: from babbler.bmc.com (camaro.bmc.com [198.207.223.231]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06290 for ; Wed, 24 Apr 2002 16:32:26 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g3OKZ7n04526; Wed, 24 Apr 2002 15:35:07 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id NAA29913 for disman-list; Wed, 24 Apr 2002 13:29:35 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id NAA29908 for ; Wed, 24 Apr 2002 13:29:32 -0700 (PDT) Received: from mx-us-hou-2-int.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id g3OKRHl18594 for ; Wed, 24 Apr 2002 15:27:17 -0500 (CDT) Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by mx-us-hou-2-int.bmc.com (Postfix) with SMTP id 83CF41FF048 for ; Wed, 24 Apr 2002 15:31:05 -0500 (CDT) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g3OKUlv29527 for ; Wed, 24 Apr 2002 16:30:48 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 24 Apr 2002 16:30:50 -0400 Message-ID: <3549C09B853DD5119B540002A52CDD3402E976C3@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: disman@dorothy.bmc.com Subject: RE: Pairing instances Date: Wed, 24 Apr 2002 16:30:44 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list hi My recollection is that hierarchical clearing was defined out of scope. It could always be supported as an add-on at a later date with a mechanism something like a hierarchicalClearTable that associated a clearNotification with a list of alarmModels. Sharon -----Original Message----- From: David T. Perkins [mailto:dperkins@dsperkins.com] Sent: Thursday, April 18, 2002 4:37 PM To: Romascanu, Dan (Dan); disman@dorothy.bmc.com Subject: RE: Pairing instances HI, Yes, its obvious to human readers (and, of course, I gave an example that should be well understood). But, if arbitrary notifications that are well defined for human readers are configured, how is the code that determines the value of alarmActiveResourceId suppose to figure this out? It seems like a little bit of magic for code. Also, in re-reading X.733/ISO-10164-3, it appears that there can be the cases: 1) multiple active alarms on the same instance 2) multiple correlated active alarms in which one clear notification causes all to clear. How is this specified in the model table? At 04:07 PM 4/18/2002 +0300, Romascanu, Dan (Dan) wrote: >David, > >See 4.1.4 for the definition of alarmActiveResourceId, and example 6.1 for the configuration of alarms based on linkUp/linkDown. The correspondence is built upon matching the indices with the values of index point to by linkUp to the indices pointed to by alarmActiveResourceId. This looks to me pretty obvious. Do you think that there is need for more explanation, or maybe do you think that an alarm may be triggered on interface 1 and cleared on interface 9? (I do not think this is a practical case) > >Regards, > >Dan > > >> -----Original Message----- >> From: David T. Perkins [mailto:dperkins@dsperkins.com] >> Sent: Thursday, April 18, 2002 9:29 AM >> To: disman@dorothy.bmc.com >> Subject: Pairing instances >> >> >> HI, >> >> In the alarm MIB (the 06 draft), how does one specify in the >> alarm model table (or elsewhere) how to determine the value >> for object alarmActiveResourceId? Without being able to >> specify this programically, it doesn't look like having >> configurable alarms is doable. >> >> One needs to have values of alarmActiveResourceId so that >> clears can be paired with existing active alarms. For example, >> if one "configured" linkDown notifications to raise alarms >> and linkUp notifications to clear them, then if a linkDown >> occurred on interface 1, and then a link down occurred on >> interface 9, and then a linkUp occurred on interface 9, >> you would need values of alarmActiveResourceId to know >> which of the two active alarms to clear. But, there is no >> way to configure this. >> >> Regards, >> /david t. perkins >> >> Regards, /david t. perkins From owner-disman@dorothy.bmc.com Wed Apr 24 17:13:03 2002 Received: from babbler.bmc.com (camaro.bmc.com [198.207.223.231]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09026 for ; Wed, 24 Apr 2002 17:13:02 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g3OLFfM17152; Wed, 24 Apr 2002 16:15:42 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id OAA00163 for disman-list; Wed, 24 Apr 2002 14:10:03 -0700 (PDT) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id OAA00155 for disman@dorothy.bmc.com; Wed, 24 Apr 2002 14:09:59 -0700 (PDT) Date: Wed, 24 Apr 2002 14:09:59 -0700 (PDT) From: Randy Presuhn Message-Id: <200204242109.OAA00155@dorothy.bmc.com> To: disman@dorothy.bmc.com Subject: RE: More than one notification for a state change 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: <3549C09B853DD5119B540002A52CDD3402E97624@zcard0ka.ca.nortel.com> > From: "Sharon Chisholm" > To: disman@dorothy.bmc.com > Subject: RE: More than one notification for a state change > Date: Wed, 24 Apr 2002 15:57:41 -0400 ... > hi > You would model them with different values for alarmModelState. > The downside of this is that you may be artificially implying > that these equivalent states have different severity, but I > think this is balanced by the upside of keeping the model > simple. It's the raise/clear relationship that is most > important in practice. ... Thanks for the explanation. The thing that I keep tripping over is that alarmModelState is the *next* state rather than the *current* state in the FSM. (Folks who implement FSMs are accustomed to representing FSMs as arrays, where one dimension of the array is "current state", and the other dimension of the array is "event", and the array content holds any actions to be taken as well as identification of the "next state". Treating "next state" as an array dimension rather than as content takes some getting used to, and may be contributing to the confusion.) ------------------------------------------------------ Randy Presuhn BMC Software, Inc. 1-3141 randy_presuhn@bmc.com 2141 North First Street Tel: +1 408 546-1006 San José, California 95131 USA ------------------------------------------------------ My opinions and BMC's are independent variables. ------------------------------------------------------ From owner-disman@dorothy.bmc.com Wed Apr 24 17:44:54 2002 Received: from babbler.bmc.com (camaro.bmc.com [198.207.223.231]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10065 for ; Wed, 24 Apr 2002 17:44:54 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g3OLlV424258; Wed, 24 Apr 2002 16:47:35 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id OAA00417 for disman-list; Wed, 24 Apr 2002 14:41:49 -0700 (PDT) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id OAA00410 for disman@dorothy.bmc.com; Wed, 24 Apr 2002 14:41:45 -0700 (PDT) Date: Wed, 24 Apr 2002 14:41:45 -0700 (PDT) From: Randy Presuhn Message-Id: <200204242141.OAA00410@dorothy.bmc.com> To: disman@dorothy.bmc.com Subject: RE: Pairing instances 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 - > Message-ID: <3549C09B853DD5119B540002A52CDD3402E97675@zcard0ka.ca.nortel.com> > From: "Sharon Chisholm" > To: disman@dorothy.bmc.com > Subject: RE: Pairing instances > Date: Wed, 24 Apr 2002 16:14:00 -0400 ... > Currently it is assumed that the implementer has some > knowledge of the notification being used in the model. ... As WG chair I'd like a consensus check on this point, since it clearly has significant impact on both the document and implementations. The Question: Shall we require implementations of this MIB to have built-in knowledge of know how to extract resource IDs from all the notification types they might encounter? (rather than representing how the resource ID is to be extracted in the MIB) ------------------------------------------------------ Randy Presuhn BMC Software, Inc. 1-3141 randy_presuhn@bmc.com 2141 North First Street Tel: +1 408 546-1006 San José, California 95131 USA ------------------------------------------------------ My opinions and BMC's are independent variables. ------------------------------------------------------ From owner-disman@dorothy.bmc.com Wed Apr 24 19:03:44 2002 Received: from babbler.bmc.com (camaro.bmc.com [198.207.223.231]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11183 for ; Wed, 24 Apr 2002 19:03:44 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g3ON6IH04970; Wed, 24 Apr 2002 18:06:19 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id QAA03941 for disman-list; Wed, 24 Apr 2002 16:00:38 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id QAA03935; Wed, 24 Apr 2002 16:00:34 -0700 (PDT) Received: from mx-us-hou-2-int.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id g3OMwKC05213; Wed, 24 Apr 2002 17:58:20 -0500 (CDT) Received: from iere.net.avaya.com (iere.net.avaya.com [198.152.12.101]) by mx-us-hou-2-int.bmc.com (Postfix) with SMTP id 749C71FF0A4; Wed, 24 Apr 2002 18:02:08 -0500 (CDT) Received: from iere.net.avaya.com (localhost [127.0.0.1]) by iere.net.avaya.com (8.11.2/8.9.3) with ESMTP id g3ON0EQ19160; Wed, 24 Apr 2002 19:00:14 -0400 (EDT) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by iere.net.avaya.com (8.11.2/8.9.3) with ESMTP id g3ON0D119143; Wed, 24 Apr 2002 19:00:13 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: making AlarmModel more explicit Date: Thu, 25 Apr 2002 01:59:47 +0300 Message-ID: Thread-Topic: making AlarmModel more explicit Thread-Index: AcHrFauo8Tkdr01LRFWekfow/aJTmAAzgTRw From: "Romascanu, Dan (Dan)" To: "Randy Presuhn" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by dorothy.bmc.com id QAA03936 Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list Content-Transfer-Encoding: 8bit > -----Original Message----- > From: Randy Presuhn [mailto:rpresuhn@dorothy.bmc.com] > Sent: Wednesday, April 24, 2002 1:23 AM > To: disman@dorothy.bmc.com > Subject: Re: making AlarmModel more explicit > > > Hi - > > > Message-Id: <5.0.2.1.2.20020423144132.02cc6190@mail4.bayarea.net> > > Date: Tue, 23 Apr 2002 15:04:52 -0700 > > To: disman@dorothy.bmc.com > > From: "David T. Perkins" > > Subject: Re: making AlarmModel more explicit > > In-Reply-To: <200204232126.OAA25608@dorothy.bmc.com> > ... > > 2) the picture below (I believe) incorrect in describing the flow > > from the engine API. The notification table from the > > notification MIB module is first consulted, not the targets > > table from the target MIB module. Not sure that the notification > > log MIB module fits where you have placed it. So, not sure > > that all of the plumbing results in water with pressure where > > you want it instead of water on the floor. > ... > > My error. Swap the Notification and Target MIB labels in > the ASCII art and it should suddenly make *much* more sense. > > ------------------------------------------------------ > Randy Presuhn BMC Software, Inc. 1-3141 > randy_presuhn@bmc.com 2141 North First Street > Tel: +1 408 546-1006 San José, California 95131 USA > ------------------------------------------------------ > My opinions and BMC's are independent variables. > ------------------------------------------------------ Thanks Randy, for making this clear. This swap needs to be done in the ASCII art in Section 3.3 of the draft. Regards, Dan > From owner-disman@dorothy.bmc.com Wed Apr 24 20:09:30 2002 Received: from babbler.bmc.com (firebird.bmc.com [198.207.223.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12045 for ; Wed, 24 Apr 2002 20:09:30 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g3P0CJ511484; Wed, 24 Apr 2002 19:12:19 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id RAA04138 for disman-list; Wed, 24 Apr 2002 17:06:17 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id RAA04132; Wed, 24 Apr 2002 17:06:13 -0700 (PDT) Received: from mx-us-hou-2-int.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id g3P03xX02847; Wed, 24 Apr 2002 19:03:59 -0500 (CDT) Received: from iere.net.avaya.com (iere.net.avaya.com [198.152.12.101]) by mx-us-hou-2-int.bmc.com (Postfix) with SMTP id 91C5F1FF036; Wed, 24 Apr 2002 19:07:47 -0500 (CDT) Received: from iere.net.avaya.com (localhost [127.0.0.1]) by iere.net.avaya.com (8.11.2/8.9.3) with ESMTP id g3P05rQ15090; Wed, 24 Apr 2002 20:05:53 -0400 (EDT) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by iere.net.avaya.com (8.11.2/8.9.3) with ESMTP id g3P05q115078; Wed, 24 Apr 2002 20:05:52 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Use of alarmListName Date: Thu, 25 Apr 2002 03:05:26 +0300 Message-ID: Thread-Topic: Use of alarmListName Thread-Index: AcHrwmc44tZDHlnOROm42osEmnToNgAKiN6w From: "Romascanu, Dan (Dan)" To: "Randy Presuhn" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by dorothy.bmc.com id RAA04133 Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list Content-Transfer-Encoding: 8bit The alarmAccessResourceId is known by the agent, because it is keeping an internal accounting of who the sends that need to be include in the alarmActiveTable. The agent will perform the matching of the respective resource (id information contained in the notification) to the relevant row(s) in the table. There is no need to duplicate this information in another MIB object. I assumed this is clear (probably part of the magic;-). If I am wrong appropriate text can be added. Regards, Dan > -----Original Message----- > From: Randy Presuhn [mailto:rpresuhn@dorothy.bmc.com] > Sent: Wednesday, April 24, 2002 9:59 PM > To: disman@dorothy.bmc.com > Subject: RE: Use of alarmListName > > > Hi - > > > Subject: RE: Use of alarmListName > > Date: Wed, 24 Apr 2002 14:28:44 +0300 > > Message-ID: > avaya.com> > > From: "Romascanu, Dan (Dan)" > > To: "David T. Perkins" , > > ... > > I am not sure what you are asking here. The object that is being > > used for the mapping is alarmModelNotificationId. What is > not complete? > ... > > I think the concern is this: > > - notification arrives > - the implementation searches the alarmModelTable > to find any entries where alarmModelNotificationId matches > the notification that arrived > - from each of these entries, we extract the tuple > and alarmModelState > - we now search the alarmActiveTable, looking for any > active alarms matching so > we can apply the new alarmModelState to them. There's just > one problem. We should only apply this to ones with the > "right" alarmActiveResourceId. This is the part of the > mapping process that's not complete. > > ------------------------------------------------------ > Randy Presuhn BMC Software, Inc. 1-3141 > randy_presuhn@bmc.com 2141 North First Street > Tel: +1 408 546-1006 San José, California 95131 USA > ------------------------------------------------------ > My opinions and BMC's are independent variables. > ------------------------------------------------------ > From owner-disman@dorothy.bmc.com Wed Apr 24 20:25:11 2002 Received: from babbler.bmc.com (firebird.bmc.com [198.207.223.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12142 for ; Wed, 24 Apr 2002 20:25:11 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g3P0Rqo12978; Wed, 24 Apr 2002 19:27:52 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id RAA04182 for disman-list; Wed, 24 Apr 2002 17:22:18 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id RAA04177 for ; Wed, 24 Apr 2002 17:22:15 -0700 (PDT) Received: from mx-us-hou-2-int.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id g3P0K0U09113 for ; Wed, 24 Apr 2002 19:20:00 -0500 (CDT) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by mx-us-hou-2-int.bmc.com (Postfix) with SMTP id BE9B41FF073 for ; Wed, 24 Apr 2002 19:23:48 -0500 (CDT) Received: from mira-sjcm-2.cisco.com (IDENT:mirapoint@mira-sjcm-2.cisco.com [171.69.24.14]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g3P0NWpY006697; Wed, 24 Apr 2002 17:23:32 -0700 (PDT) Received: from cisco.com (dhcp-128-107-165-172.cisco.com [128.107.165.172]) by mira-sjcm-2.cisco.com (Mirapoint) with ESMTP id ACS92652; Wed, 24 Apr 2002 17:23:32 -0700 (PDT) Message-ID: <3CC74C84.4C6D2200@cisco.com> Date: Wed, 24 Apr 2002 17:23:32 -0700 From: Ramanathan Kavasseri X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Sharon Chisholm Cc: disman@dorothy.bmc.com Subject: Re: Pairing instances References: <3549C09B853DD5119B540002A52CDD3402E97675@zcard0ka.ca.nortel.com> Content-Type: text/plain; charset=iso-8859-1 X-MIME-Autoconverted: from 8bit to quoted-printable by sj-msg-core-3.cisco.com id g3P0NWpY006697 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by dorothy.bmc.com id RAA04178 Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list Content-Transfer-Encoding: 8bit Sharon Chisholm wrote: > > hi > > Currently it is assumed that the implementer has some > knowledge of the notification being used in the model. > Of course if they are using the provided notifications, > the resource ID is in a well defined spot within the > notification, but can take any value. > > I don't know how practical it would be to even try > and provide a standardized mechanism to identify > where in a notification the resource information will > be stored. My feeling is not very. > > Perhaps the best solution would be to add some clarifying > text to the document. > Clarifying text in the doc will certainly be good (it will help towards a consistent implementation). I don't think a standardized mechanism is needed. Just my 2 cents, Ram > Sharon > > -----Original Message----- > From: Randy Presuhn [mailto:rpresuhn@dorothy.bmc.com] > Sent: Monday, April 22, 2002 8:56 PM > To: disman@dorothy.bmc.com > Subject: RE: Pairing instances > > Hi - > > > Message-Id: <5.0.2.1.2.20020422172156.03b39bd0@mail4.bayarea.net> > > Date: Mon, 22 Apr 2002 17:39:12 -0700 > > To: Randy Presuhn , disman@dorothy.bmc.com > > From: "David T. Perkins" > > Subject: RE: Pairing instances > > In-Reply-To: <200204230008.RAA17512@dorothy.bmc.com> > ... > > The example below is interesting, but I'm talking about something > > really basic. > > Much simpler than your example. ;-) > > The question about how the > > ... > > code would determine the value of "alarmActiveResourceId" from > > the notifications is not described. > ... > > Agreed. This is a problem. > > Summing up, we have similar concerns about the alarmModelTable. > A partial list, paraphrasing (or possibly reading too much > into) your posts: > > 1) how does it the implementation figure out where to get > the value for alarmActiveResourceId? (The information > has to be in the notification somewhere, but how does > the alarmModelTable tell the implementation where to > look?) > > 2) what is the appropriate amount of power for describing > the "finite state machine" for an alarm? > > 3) can a single notification "crank" more than one alarm's > state machine? (This is tied to (1)) > > ------------------------------------------------------ > Randy Presuhn BMC Software, Inc. 1-3141 > randy_presuhn@bmc.com 2141 North First Street > Tel: +1 408 546-1006 San José, California 95131 USA > ------------------------------------------------------ > My opinions and BMC's are independent variables. > ------------------------------------------------------ From owner-disman@dorothy.bmc.com Wed Apr 24 20:53:12 2002 Received: from babbler.bmc.com (firebird.bmc.com [198.207.223.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12534 for ; Wed, 24 Apr 2002 20:53:12 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g3P0tqI16322; Wed, 24 Apr 2002 19:55:52 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id RAA04370 for disman-list; Wed, 24 Apr 2002 17:50:19 -0700 (PDT) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id RAA04364 for disman@dorothy.bmc.com; Wed, 24 Apr 2002 17:50:16 -0700 (PDT) Date: Wed, 24 Apr 2002 17:50:16 -0700 (PDT) From: Randy Presuhn Message-Id: <200204250050.RAA04364@dorothy.bmc.com> To: disman@dorothy.bmc.com Subject: RE: Use of alarmListName 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 - > Subject: RE: Use of alarmListName > Date: Thu, 25 Apr 2002 03:05:26 +0300 > Message-ID: > From: "Romascanu, Dan (Dan)" > To: "Randy Presuhn" , > > The alarmAccessResourceId is known by the agent, because it > is keeping an internal accounting of who the sends that need to > be include in the alarmActiveTable. The agent will perform the > matching of the respective resource (id information contained > in the notification) to the relevant row(s) in the table. There > is no need to duplicate this information in another MIB object. ... WG chair wondering aloud: if the WG consensus is to go with requiring implementations to know a priori how to extract resource IDs from notifications (I'm awaiting response to consensus call on *that*), and since what one needs to do to extract a resource ID from a notification depends on the notification type, do we need to specify the set of NOTIFICATION-TYPEs that MUST be understood by a conformant implementation, and do we need to specify how the resource ID extraction works for these? ------------------------------------------------------ Randy Presuhn BMC Software, Inc. 1-3141 randy_presuhn@bmc.com 2141 North First Street Tel: +1 408 546-1006 San José, California 95131 USA ------------------------------------------------------ My opinions and BMC's are independent variables. ------------------------------------------------------ From owner-disman@dorothy.bmc.com Wed Apr 24 20:56:27 2002 Received: from babbler.bmc.com (firebird.bmc.com [198.207.223.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12046 for ; Wed, 24 Apr 2002 20:09:30 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g3P0CcZ11512; Wed, 24 Apr 2002 19:12:38 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id RAA04149 for disman-list; Wed, 24 Apr 2002 17:07:07 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id RAA04142; Wed, 24 Apr 2002 17:07:03 -0700 (PDT) Received: from mx-us-hou-2-int.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id g3P04nq03120; Wed, 24 Apr 2002 19:04:49 -0500 (CDT) Received: from iere.net.avaya.com (iere.net.avaya.com [198.152.12.101]) by mx-us-hou-2-int.bmc.com (Postfix) with SMTP id 3F59D1FF036; Wed, 24 Apr 2002 19:08:37 -0500 (CDT) Received: from iere.net.avaya.com (localhost [127.0.0.1]) by iere.net.avaya.com (8.11.2/8.9.3) with ESMTP id g3P06hQ15492; Wed, 24 Apr 2002 20:06:43 -0400 (EDT) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by iere.net.avaya.com (8.11.2/8.9.3) with ESMTP id g3P06g115478; Wed, 24 Apr 2002 20:06:42 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Use of alarmListName Date: Thu, 25 Apr 2002 03:06:16 +0300 Message-ID: Thread-Topic: Use of alarmListName Thread-Index: AcHrzY1gVcERgZEUQDydKlhl09UtLQAH6TIg From: "Romascanu, Dan (Dan)" To: "David T. Perkins" , "Randy Presuhn" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by dorothy.bmc.com id RAA04144 Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list Content-Transfer-Encoding: 8bit What are the two other mechanisms? Dan > -----Original Message----- > From: David T. Perkins [mailto:dperkins@dsperkins.com] > Sent: Wednesday, April 24, 2002 11:10 PM > To: Randy Presuhn; disman@dorothy.bmc.com > Subject: RE: Use of alarmListName > > > HI, > > Randy summarized the process below, when notifications are used to > raise and clear alarms. But, my interpretation of the I-D is that > two other mechanisms can also be used to raise and clear alarms. > If this interpretation is correct, then for them, would also like > to see the logic similar to what Randy has written below. > > At 11:59 AM 4/24/2002 -0700, Randy Presuhn wrote: > >Hi - > > > >> Subject: RE: Use of alarmListName > >> Date: Wed, 24 Apr 2002 14:28:44 +0300 > >> Message-ID: > avaya.com> > >> From: "Romascanu, Dan (Dan)" > >> To: "David T. Perkins" , > > >... > >> I am not sure what you are asking here. The object that is being > >> used for the mapping is alarmModelNotificationId. What is > not complete? > >... > > > >I think the concern is this: > > > > - notification arrives > > - the implementation searches the alarmModelTable > > to find any entries where alarmModelNotificationId matches > > the notification that arrived > > - from each of these entries, we extract the tuple > > and alarmModelState > > - we now search the alarmActiveTable, looking for any > > active alarms matching so > > we can apply the new alarmModelState to them. There's just > > one problem. We should only apply this to ones with the > > "right" alarmActiveResourceId. This is the part of the > > mapping process that's not complete. > > Regards, > /david t. perkins > > From owner-disman@dorothy.bmc.com Wed Apr 24 20:57:21 2002 Received: from babbler.bmc.com (firebird.bmc.com [198.207.223.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12630 for ; Wed, 24 Apr 2002 20:57:21 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g3P102e16752; Wed, 24 Apr 2002 20:00:02 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id RAA04399 for disman-list; Wed, 24 Apr 2002 17:54:30 -0700 (PDT) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id RAA04393 for disman@dorothy.bmc.com; Wed, 24 Apr 2002 17:54:26 -0700 (PDT) Date: Wed, 24 Apr 2002 17:54:26 -0700 (PDT) From: Randy Presuhn Message-Id: <200204250054.RAA04393@dorothy.bmc.com> To: disman@dorothy.bmc.com Subject: RE: Use of alarmListName 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 - > Subject: RE: Use of alarmListName > Date: Thu, 25 Apr 2002 03:06:16 +0300 > Message-ID: > From: "Romascanu, Dan (Dan)" > To: "David T. Perkins" , > "Randy Presuhn" , > > What are the two other mechanisms? Dan ... I believe he is referring to the three mechanisms specified in 4.1.3's second paragraph. |4.1.3 Alarm State Transition Notification | | Alarms are modelled by defining all possible states in the | alarmModelTable, as well as defining alarmModelNotificationId, | alarmModelVarbindIndex, and alarmModelVarbindValue for each of the | possible alarm states. Optionally, ituAlarmPerceivedSeverity models | the states in terms of ITU perceived severity. | | Alarm state transitions can use existing notifications or can use | the generic notifications and alarmActiveState and alarmClearState. | If the implementation chooses not to alert the management station, | then a value of 0.0 can be used for alarmModelNotificationId. | Alternatively, a notification can be defined in | alarmModeNotifiationId and no hosts specified in the SNMP-TARGET-MIB | [RFC2573]. As a technical contributor, I think the second looks like a special case of the first, and the third appears to me to be total magic. ------------------------------------------------------ Randy Presuhn BMC Software, Inc. 1-3141 randy_presuhn@bmc.com 2141 North First Street Tel: +1 408 546-1006 San José, California 95131 USA ------------------------------------------------------ My opinions and BMC's are independent variables. ------------------------------------------------------ From owner-disman@dorothy.bmc.com Wed Apr 24 21:00:13 2002 Received: from babbler.bmc.com (firebird.bmc.com [198.207.223.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12697 for ; Wed, 24 Apr 2002 21:00:13 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g3P12sn17003; Wed, 24 Apr 2002 20:02:54 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id RAA04446 for disman-list; Wed, 24 Apr 2002 17:57:21 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id RAA04432; Wed, 24 Apr 2002 17:57:16 -0700 (PDT) Received: from mx-us-hou-1-int.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id g3P0swW22835; Wed, 24 Apr 2002 19:54:59 -0500 (CDT) Received: from sj-msg-core-4.cisco.com (unknown [171.71.163.10]) by mx-us-hou-1-int.bmc.com (Postfix) with SMTP id 1D23B20F03C; Wed, 24 Apr 2002 19:58:47 -0500 (CDT) Received: from mira-sjcm-2.cisco.com (IDENT:mirapoint@mira-sjcm-2.cisco.com [171.69.24.14]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g3P0wfTG022624; Wed, 24 Apr 2002 17:58:41 -0700 (PDT) Received: from cisco.com (dhcp-128-107-165-172.cisco.com [128.107.165.172]) by mira-sjcm-2.cisco.com (Mirapoint) with ESMTP id ACS93409; Wed, 24 Apr 2002 17:58:40 -0700 (PDT) Message-ID: <3CC754C0.85C1C809@cisco.com> Date: Wed, 24 Apr 2002 17:58:40 -0700 From: Ramanathan Kavasseri X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Randy Presuhn Cc: disman@dorothy.bmc.com Subject: Re: Use of alarmListName References: <200204250050.RAA04364@dorothy.bmc.com> Content-Type: text/plain; charset=iso-8859-1 X-MIME-Autoconverted: from 8bit to quoted-printable by sj-msg-core-4.cisco.com id g3P0wfTG022624 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by dorothy.bmc.com id RAA04433 Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list Content-Transfer-Encoding: 8bit Randy Presuhn wrote: > > Hi - > > > Subject: RE: Use of alarmListName > > Date: Thu, 25 Apr 2002 03:05:26 +0300 > > Message-ID: > > From: "Romascanu, Dan (Dan)" > > To: "Randy Presuhn" , > > > > The alarmAccessResourceId is known by the agent, because it > > is keeping an internal accounting of who the sends that need to > > be include in the alarmActiveTable. The agent will perform the > > matching of the respective resource (id information contained > > in the notification) to the relevant row(s) in the table. There > > is no need to duplicate this information in another MIB object. > ... > > WG chair wondering aloud: if the WG consensus is to go > with requiring implementations to know a priori how to > extract resource IDs from notifications (I'm awaiting > response to consensus call on *that*), and since what > one needs to do to extract a resource ID from a notification > depends on the notification type, do we need to specify > the set of NOTIFICATION-TYPEs that MUST be understood by Yes. > a conformant implementation, and do we need to specify > how the resource ID extraction works for these? Yes. Ram > > ------------------------------------------------------ > Randy Presuhn BMC Software, Inc. 1-3141 > randy_presuhn@bmc.com 2141 North First Street > Tel: +1 408 546-1006 San José, California 95131 USA > ------------------------------------------------------ > My opinions and BMC's are independent variables. > ------------------------------------------------------ From owner-disman@dorothy.bmc.com Wed Apr 24 21:03:05 2002 Received: from babbler.bmc.com (firebird.bmc.com [198.207.223.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12739 for ; Wed, 24 Apr 2002 21:03:04 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g3P15kH17369; Wed, 24 Apr 2002 20:05:46 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id SAA04488 for disman-list; Wed, 24 Apr 2002 18:00:14 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id SAA04482; Wed, 24 Apr 2002 18:00:10 -0700 (PDT) Received: from mx-us-hou-2-int.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id g3P0vtP24286; Wed, 24 Apr 2002 19:57:55 -0500 (CDT) Received: from riverstonenet.com (mail.riverstonenet.com [63.113.148.10]) by mx-us-hou-2-int.bmc.com (Postfix) with SMTP id 26A031FF024; Wed, 24 Apr 2002 20:01:42 -0500 (CDT) Received: from dperkins-nb2.dsperkins.com by riverstonenet.com (8.9.3+Sun/SMI-SVR4-Yago) id SAA23229; Wed, 24 Apr 2002 18:01:28 -0700 (PDT) Message-Id: <5.0.2.1.2.20020424175350.024480a0@mail4.bayarea.net> X-Sender: dperkins@mail4.bayarea.net X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Wed, 24 Apr 2002 18:01:06 -0700 To: "Romascanu, Dan (Dan)" , "Randy Presuhn" , From: "David T. Perkins" Subject: RE: Use of alarmListName In-Reply-To: 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, for your question... At 03:06 AM 4/25/2002 +0300, Romascanu, Dan (Dan) wrote: >What are the two other mechanisms? Dan In section 3.2.2, Flexible Alarm Modeling, look at the 3rd paragraph that starts with Alarm states can be modelled using traditional notifications, generic alarm notifications, or without notifications. Note that it doesn't seem like the picture in section 3.3 matches the content of the above paragraph. Regards, /david t. perkins >> -----Original Message----- >> From: David T. Perkins [mailto:dperkins@dsperkins.com] >> Sent: Wednesday, April 24, 2002 11:10 PM >> To: Randy Presuhn; disman@dorothy.bmc.com >> Subject: RE: Use of alarmListName >> >> >> HI, >> >> Randy summarized the process below, when notifications are used to >> raise and clear alarms. But, my interpretation of the I-D is that >> two other mechanisms can also be used to raise and clear alarms. >> If this interpretation is correct, then for them, would also like >> to see the logic similar to what Randy has written below. >> >> At 11:59 AM 4/24/2002 -0700, Randy Presuhn wrote: >> >Hi - >> > >> >> Subject: RE: Use of alarmListName >> >> Date: Wed, 24 Apr 2002 14:28:44 +0300 >> >> Message-ID: >> > avaya.com> >> >> From: "Romascanu, Dan (Dan)" >> >> To: "David T. Perkins" , >> >> >... >> >> I am not sure what you are asking here. The object that is being >> >> used for the mapping is alarmModelNotificationId. What is >> not complete? >> >... >> > >> >I think the concern is this: >> > >> > - notification arrives >> > - the implementation searches the alarmModelTable >> > to find any entries where alarmModelNotificationId matches >> > the notification that arrived >> > - from each of these entries, we extract the tuple >> > and alarmModelState >> > - we now search the alarmActiveTable, looking for any >> > active alarms matching so >> > we can apply the new alarmModelState to them. There's just >> > one problem. We should only apply this to ones with the >> > "right" alarmActiveResourceId. This is the part of the >> > mapping process that's not complete. >> >> Regards, >> /david t. perkins >> >> From owner-disman@dorothy.bmc.com Wed Apr 24 21:03:56 2002 Received: from babbler.bmc.com (camaro.bmc.com [198.207.223.231]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12758 for ; Wed, 24 Apr 2002 21:03:56 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g3P16bO17477; Wed, 24 Apr 2002 20:06:37 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id SAA04502 for disman-list; Wed, 24 Apr 2002 18:01:06 -0700 (PDT) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id SAA04496 for disman@dorothy.bmc.com; Wed, 24 Apr 2002 18:01:02 -0700 (PDT) Date: Wed, 24 Apr 2002 18:01:02 -0700 (PDT) From: Randy Presuhn Message-Id: <200204250101.SAA04496@dorothy.bmc.com> To: disman@dorothy.bmc.com Subject: Re: Use of alarmListName 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 - > Message-ID: <3CC754C0.85C1C809@cisco.com> > Date: Wed, 24 Apr 2002 17:58:40 -0700 > From: Ramanathan Kavasseri > To: Randy Presuhn > Cc: disman@dorothy.bmc.com > Subject: Re: Use of alarmListName > References: <200204250050.RAA04364@dorothy.bmc.com> ... > > depends on the notification type, do we need to specify > > the set of NOTIFICATION-TYPEs that MUST be understood by > > Yes. Any thoughts on what that should be in that set? > > a conformant implementation, and do we need to specify > > how the resource ID extraction works for these? > > Yes. ... And the rules are... ? ------------------------------------------------------ Randy Presuhn BMC Software, Inc. 1-3141 randy_presuhn@bmc.com 2141 North First Street Tel: +1 408 546-1006 San José, California 95131 USA ------------------------------------------------------ My opinions and BMC's are independent variables. ------------------------------------------------------ From owner-disman@dorothy.bmc.com Wed Apr 24 21:30:08 2002 Received: from babbler.bmc.com (camaro.bmc.com [198.207.223.231]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13010 for ; Wed, 24 Apr 2002 21:30:08 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g3P1WiU19897; Wed, 24 Apr 2002 20:32:44 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id SAA04582 for disman-list; Wed, 24 Apr 2002 18:26:57 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id SAA04576; Wed, 24 Apr 2002 18:26:52 -0700 (PDT) Received: from mx-us-hou-2-int.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id g3P1Obm04775; Wed, 24 Apr 2002 20:24:38 -0500 (CDT) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by mx-us-hou-2-int.bmc.com (Postfix) with SMTP id 16E591FF04C; Wed, 24 Apr 2002 20:28:26 -0500 (CDT) Received: from mira-sjcm-2.cisco.com (IDENT:mirapoint@mira-sjcm-2.cisco.com [171.69.24.14]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g3P1SATG003708; Wed, 24 Apr 2002 18:28:10 -0700 (PDT) Received: from cisco.com (dhcp-128-107-165-172.cisco.com [128.107.165.172]) by mira-sjcm-2.cisco.com (Mirapoint) with ESMTP id ACS94001; Wed, 24 Apr 2002 18:28:09 -0700 (PDT) Message-ID: <3CC75BA9.1994DF1@cisco.com> Date: Wed, 24 Apr 2002 18:28:09 -0700 From: Ramanathan Kavasseri X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Randy Presuhn Cc: disman@dorothy.bmc.com Subject: Re: Use of alarmListName References: <200204250101.SAA04496@dorothy.bmc.com> Content-Type: text/plain; charset=iso-8859-1 X-MIME-Autoconverted: from 8bit to quoted-printable by sj-msg-core-4.cisco.com id g3P1SATG003708 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by dorothy.bmc.com id SAA04577 Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list Content-Transfer-Encoding: 8bit Randy Presuhn wrote: > > Hi - > > > Message-ID: <3CC754C0.85C1C809@cisco.com> > > Date: Wed, 24 Apr 2002 17:58:40 -0700 > > From: Ramanathan Kavasseri > > To: Randy Presuhn > > Cc: disman@dorothy.bmc.com > > Subject: Re: Use of alarmListName > > References: <200204250050.RAA04364@dorothy.bmc.com> > ... > > > depends on the notification type, do we need to specify > > > the set of NOTIFICATION-TYPEs that MUST be understood by > > > > Yes. > > Any thoughts on what that should be in that set? > > > > a conformant implementation, and do we need to specify > > > how the resource ID extraction works for these? > > > > Yes. > ... > > And the rules are... ? Was hoping someone would provide this - as I'm scratching my head about how to go about it. :-( Ram > > ------------------------------------------------------ > Randy Presuhn BMC Software, Inc. 1-3141 > randy_presuhn@bmc.com 2141 North First Street > Tel: +1 408 546-1006 San José, California 95131 USA > ------------------------------------------------------ > My opinions and BMC's are independent variables. > ------------------------------------------------------ From owner-disman@dorothy.bmc.com Thu Apr 25 00:21:01 2002 Received: from babbler.bmc.com (camaro.bmc.com [198.207.223.231]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17652 for ; Thu, 25 Apr 2002 00:21:01 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g3P4NaA05496; Wed, 24 Apr 2002 23:23:37 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id VAA04929 for disman-list; Wed, 24 Apr 2002 21:17:28 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id VAA04923; Wed, 24 Apr 2002 21:17:24 -0700 (PDT) Received: from mx-us-hou-1-int.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id g3P4FAC10792; Wed, 24 Apr 2002 23:15:10 -0500 (CDT) Received: from ierw.net.avaya.com (unknown [198.152.13.101]) by mx-us-hou-1-int.bmc.com (Postfix) with SMTP id A1C3D20F02E; Wed, 24 Apr 2002 23:18:58 -0500 (CDT) Received: from ierw.net.avaya.com (localhost [127.0.0.1]) by ierw.net.avaya.com (8.9.3+Sun/8.9.3) with ESMTP id AAA18428; Thu, 25 Apr 2002 00:17:16 -0400 (EDT) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by ierw.net.avaya.com (8.9.3+Sun/8.9.3) with ESMTP id AAA18419; Thu, 25 Apr 2002 00:17:15 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Use of alarmListName Date: Thu, 25 Apr 2002 07:16:47 +0300 Message-ID: Thread-Topic: Use of alarmListName Thread-Index: AcHr8+ELGXKjCvBDQA25Kyd18rw1YwAGqoOA From: "Romascanu, Dan (Dan)" To: "Randy Presuhn" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by dorothy.bmc.com id VAA04924 Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list Content-Transfer-Encoding: 8bit Maybe I start to understand. It looks to me that in all this discussion there is a confusion between the notifications that are received by an agent and need to be interpreted as an alarm condition and the notifications that are being sent by the agent when a change in the alarm state occurs. 4.1.3 describes the notifications that may be sent by the agent that supports the Alarm MIB. Regards, Dan > -----Original Message----- > From: Randy Presuhn [mailto:rpresuhn@dorothy.bmc.com] > Sent: Thursday, April 25, 2002 3:54 AM > To: disman@dorothy.bmc.com > Subject: RE: Use of alarmListName > > > Hi - > > > Subject: RE: Use of alarmListName > > Date: Thu, 25 Apr 2002 03:06:16 +0300 > > Message-ID: > avaya.com> > > From: "Romascanu, Dan (Dan)" > > To: "David T. Perkins" , > > "Randy Presuhn" , > > > > > What are the two other mechanisms? Dan > ... > > I believe he is referring to the three mechanisms specified in > 4.1.3's second paragraph. > > |4.1.3 Alarm State Transition Notification > | > | Alarms are modelled by defining all possible states in the > | alarmModelTable, as well as defining alarmModelNotificationId, > | alarmModelVarbindIndex, and alarmModelVarbindValue for each of the > | possible alarm states. Optionally, > ituAlarmPerceivedSeverity models > | the states in terms of ITU perceived severity. > | > | Alarm state transitions can use existing notifications or can use > | the generic notifications and alarmActiveState and > alarmClearState. > | If the implementation chooses not to alert the management station, > | then a value of 0.0 can be used for alarmModelNotificationId. > | Alternatively, a notification can be defined in > | alarmModeNotifiationId and no hosts specified in the > SNMP-TARGET-MIB > | [RFC2573]. > > As a technical contributor, I think the second looks like a > special case of the first, and the third appears to me to be > total magic. > > ------------------------------------------------------ > Randy Presuhn BMC Software, Inc. 1-3141 > randy_presuhn@bmc.com 2141 North First Street > Tel: +1 408 546-1006 San José, California 95131 USA > ------------------------------------------------------ > My opinions and BMC's are independent variables. > ------------------------------------------------------ > From owner-disman@dorothy.bmc.com Thu Apr 25 00:25:47 2002 Received: from babbler.bmc.com (camaro.bmc.com [198.207.223.231]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17711 for ; Thu, 25 Apr 2002 00:25:47 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g3P4SQY05883; Wed, 24 Apr 2002 23:28:27 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id VAA04948 for disman-list; Wed, 24 Apr 2002 21:22:54 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id VAA04942; Wed, 24 Apr 2002 21:22:50 -0700 (PDT) Received: from mx-us-hou-1-int.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id g3P4Kab12221; Wed, 24 Apr 2002 23:20:36 -0500 (CDT) Received: from ierw.net.avaya.com (unknown [198.152.13.101]) by mx-us-hou-1-int.bmc.com (Postfix) with SMTP id 5C96820EFEF; Wed, 24 Apr 2002 23:24:24 -0500 (CDT) Received: from ierw.net.avaya.com (localhost [127.0.0.1]) by ierw.net.avaya.com (8.9.3+Sun/8.9.3) with ESMTP id AAA20309; Thu, 25 Apr 2002 00:22:42 -0400 (EDT) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by ierw.net.avaya.com (8.9.3+Sun/8.9.3) with ESMTP id AAA20295; Thu, 25 Apr 2002 00:22:40 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Use of alarmListName Date: Thu, 25 Apr 2002 07:22:13 +0300 Message-ID: Thread-Topic: Use of alarmListName Thread-Index: AcHr801TEeJQ6h5iQze/uonregTVVQAHP37g From: "Romascanu, Dan (Dan)" To: "Randy Presuhn" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by dorothy.bmc.com id VAA04943 Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list Content-Transfer-Encoding: 8bit > > > Subject: RE: Use of alarmListName > > Date: Thu, 25 Apr 2002 03:05:26 +0300 > > Message-ID: > avaya.com> > > From: "Romascanu, Dan (Dan)" > > To: "Randy Presuhn" , > > > > > The alarmAccessResourceId is known by the agent, because it > > is keeping an internal accounting of who the sends that need to > > be include in the alarmActiveTable. The agent will perform the > > matching of the respective resource (id information contained > > in the notification) to the relevant row(s) in the table. There > > is no need to duplicate this information in another MIB object. > ... > > WG chair wondering aloud: if the WG consensus is to go > with requiring implementations to know a priori how to > extract resource IDs from notifications (I'm awaiting > response to consensus call on *that*), and since what > one needs to do to extract a resource ID from a notification > depends on the notification type, do we need to specify > the set of NOTIFICATION-TYPEs that MUST be understood by > a conformant implementation, and do we need to specify > how the resource ID extraction works for these? Why should it? The agent either knows how to populate the alarmActiveResourceId object, or it does not. The MIB structure does just that - passes alarms and identifies resources described by the OID. The 'magic' of populating the tables are not within the scope of the generic alarm model. > > ------------------------------------------------------ > Randy Presuhn BMC Software, Inc. 1-3141 > randy_presuhn@bmc.com 2141 North First Street > Tel: +1 408 546-1006 San José, California 95131 USA > ------------------------------------------------------ > My opinions and BMC's are independent variables. > ------------------------------------------------------ > Regards, Dan From owner-disman@dorothy.bmc.com Thu Apr 25 00:31:13 2002 Received: from babbler.bmc.com (camaro.bmc.com [198.207.223.231]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17793 for ; Thu, 25 Apr 2002 00:31:12 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g3P4XqQ06405; Wed, 24 Apr 2002 23:33:52 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id VAA04971 for disman-list; Wed, 24 Apr 2002 21:28:20 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id VAA04965; Wed, 24 Apr 2002 21:28:16 -0700 (PDT) Received: from mx-us-hou-1-int.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id g3P4Q0C14644; Wed, 24 Apr 2002 23:26:00 -0500 (CDT) Received: from ierw.net.avaya.com (unknown [198.152.13.101]) by mx-us-hou-1-int.bmc.com (Postfix) with SMTP id D4DAD20F009; Wed, 24 Apr 2002 23:29:46 -0500 (CDT) Received: from ierw.net.avaya.com (localhost [127.0.0.1]) by ierw.net.avaya.com (8.9.3+Sun/8.9.3) with ESMTP id AAA21391; Thu, 25 Apr 2002 00:28:04 -0400 (EDT) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by ierw.net.avaya.com (8.9.3+Sun/8.9.3) with ESMTP id AAA21385; Thu, 25 Apr 2002 00:28:02 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Use of alarmListName Date: Thu, 25 Apr 2002 07:27:35 +0300 Message-ID: Thread-Topic: Use of alarmListName Thread-Index: AcHr9HSaKJW0KJquRdOs259hQuvaaAAHNbCA From: "Romascanu, Dan (Dan)" To: "David T. Perkins" , "Randy Presuhn" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by dorothy.bmc.com id VAA04966 Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list Content-Transfer-Encoding: 8bit Dave, I think that you are confusing here between the notifications that are being sent by the Alarm MIB agent, and the conditions that lead to the activeAlarmTable being populated. 3.2.2 refers to the first, while 3.3 refer to the later. Probably the text in 3.2.2 may benefit from some further clarification to avoid confusion. Regards, Dan > -----Original Message----- > From: David T. Perkins [mailto:dperkins@dsperkins.com] > Sent: Thursday, April 25, 2002 4:01 AM > To: Romascanu, Dan (Dan); Randy Presuhn; disman@dorothy.bmc.com > Subject: RE: Use of alarmListName > > > HI, > > for your question... > > At 03:06 AM 4/25/2002 +0300, Romascanu, Dan (Dan) wrote: > >What are the two other mechanisms? Dan > > In section 3.2.2, Flexible Alarm Modeling, look at the 3rd paragraph > that starts with > Alarm states can be modelled using traditional notifications, > generic alarm notifications, or without notifications. > > Note that it doesn't seem like the picture in section 3.3 matches the > content of the above paragraph. > > Regards, > /david t. perkins > > > >> -----Original Message----- > >> From: David T. Perkins [mailto:dperkins@dsperkins.com] > >> Sent: Wednesday, April 24, 2002 11:10 PM > >> To: Randy Presuhn; disman@dorothy.bmc.com > >> Subject: RE: Use of alarmListName > >> > >> > >> HI, > >> > >> Randy summarized the process below, when notifications are used to > >> raise and clear alarms. But, my interpretation of the I-D is that > >> two other mechanisms can also be used to raise and clear alarms. > >> If this interpretation is correct, then for them, would also like > >> to see the logic similar to what Randy has written below. > >> > >> At 11:59 AM 4/24/2002 -0700, Randy Presuhn wrote: > >> >Hi - > >> > > >> >> Subject: RE: Use of alarmListName > >> >> Date: Wed, 24 Apr 2002 14:28:44 +0300 > >> >> Message-ID: > >> >> avaya.com> > >> >> From: "Romascanu, Dan (Dan)" > >> >> To: "David T. Perkins" , > >> > >> >... > >> >> I am not sure what you are asking here. The object that is being > >> >> used for the mapping is alarmModelNotificationId. What is > >> not complete? > >> >... > >> > > >> >I think the concern is this: > >> > > >> > - notification arrives > >> > - the implementation searches the alarmModelTable > >> > to find any entries where alarmModelNotificationId matches > >> > the notification that arrived > >> > - from each of these entries, we extract the tuple > >> > and alarmModelState > >> > - we now search the alarmActiveTable, looking for any > >> > active alarms matching so > >> > we can apply the new alarmModelState to them. There's just > >> > one problem. We should only apply this to ones with the > >> > "right" alarmActiveResourceId. This is the part of the > >> > mapping process that's not complete. > >> > >> Regards, > >> /david t. perkins > >> > >> > > From owner-disman@dorothy.bmc.com Thu Apr 25 00:37:54 2002 Received: from babbler.bmc.com (camaro.bmc.com [198.207.223.231]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17898 for ; Thu, 25 Apr 2002 00:37:54 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g3P4eYG07030; Wed, 24 Apr 2002 23:40:34 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id VAA04987 for disman-list; Wed, 24 Apr 2002 21:35:02 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id VAA04981; Wed, 24 Apr 2002 21:34:58 -0700 (PDT) Received: from mx-us-hou-1-int.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id g3P4WhR18007; Wed, 24 Apr 2002 23:32:43 -0500 (CDT) Received: from ierw.net.avaya.com (unknown [198.152.13.101]) by mx-us-hou-1-int.bmc.com (Postfix) with SMTP id 7856F20EFEF; Wed, 24 Apr 2002 23:36:30 -0500 (CDT) Received: from ierw.net.avaya.com (localhost [127.0.0.1]) by ierw.net.avaya.com (8.9.3+Sun/8.9.3) with ESMTP id AAA22980; Thu, 25 Apr 2002 00:34:48 -0400 (EDT) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by ierw.net.avaya.com (8.9.3+Sun/8.9.3) with ESMTP id AAA22969; Thu, 25 Apr 2002 00:34:47 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Use of alarmListName Date: Thu, 25 Apr 2002 07:34:19 +0300 Message-ID: Thread-Topic: Use of alarmListName Thread-Index: AcHr+HpUk+w0hBdYRniM6llf4qi5kwAGZPQw From: "Romascanu, Dan (Dan)" To: "Ramanathan Kavasseri" , "Randy Presuhn" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by dorothy.bmc.com id VAA04982 Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list Content-Transfer-Encoding: 8bit > -----Original Message----- > From: Ramanathan Kavasseri [mailto:ramk@cisco.com] > Sent: Thursday, April 25, 2002 4:28 AM > To: Randy Presuhn > Cc: disman@dorothy.bmc.com > Subject: Re: Use of alarmListName > > > > > Randy Presuhn wrote: > > > > Hi - > > > > > Message-ID: <3CC754C0.85C1C809@cisco.com> > > > Date: Wed, 24 Apr 2002 17:58:40 -0700 > > > From: Ramanathan Kavasseri > > > To: Randy Presuhn > > > Cc: disman@dorothy.bmc.com > > > Subject: Re: Use of alarmListName > > > References: <200204250050.RAA04364@dorothy.bmc.com> > > ... > > > > depends on the notification type, do we need to specify > > > > the set of NOTIFICATION-TYPEs that MUST be understood by > > > > > > Yes. > > > > Any thoughts on what that should be in that set? > > > > > > a conformant implementation, and do we need to specify > > > > how the resource ID extraction works for these? > > > > > > Yes. > > ... > > > > And the rules are... ? > > Was hoping someone would provide this - as I'm scratching > my head about how to go about it. > :-( > would be glad to spare you the scratching ;-) it would not be a problem to specify such a mapping. Avoiding to do this is by design. A generic agent needs not understand the semantics of the alarms. Some agent implementations do not use notifications to populate the alarmActiveTable. If you want to 'hard code' such a mapping you may do it in the model specific Alarm MIB. > Ram > > > > > ------------------------------------------------------ > > Randy Presuhn BMC Software, Inc. 1-3141 > > randy_presuhn@bmc.com 2141 North First Street > > Tel: +1 408 546-1006 San José, California 95131 USA > > ------------------------------------------------------ > > My opinions and BMC's are independent variables. > > ------------------------------------------------------ > From owner-disman@dorothy.bmc.com Thu Apr 25 08:21:31 2002 Received: from babbler.bmc.com (camaro.bmc.com [198.207.223.231]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02763 for ; Thu, 25 Apr 2002 08:21:31 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g3PCO9T28408; Thu, 25 Apr 2002 07:24:09 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id FAA05808 for disman-list; Thu, 25 Apr 2002 05:18:05 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id FAA05803 for ; Thu, 25 Apr 2002 05:18:01 -0700 (PDT) Received: from mx-us-hou-2-int.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id g3PCFja06408 for ; Thu, 25 Apr 2002 07:15:46 -0500 (CDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mx-us-hou-2-int.bmc.com (Postfix) with SMTP id 38DBC1FF04C for ; Thu, 25 Apr 2002 07:19:34 -0500 (CDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02661; Thu, 25 Apr 2002 08:19:16 -0400 (EDT) Message-Id: <200204251219.IAA02661@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: disman@dorothy.bmc.com From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-disman-conditionmib-02.txt Date: Thu, 25 Apr 2002 08:19:15 -0400 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 : Alarm Report Control MIB Author(s) : K. Lam, A. Huynh, D. Perkins Filename : draft-ietf-disman-conditionmib-02.txt Pages : Date : 24-Apr-02 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for controlling the reporting of alarm conditions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-disman-conditionmib-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-conditionmib-02.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-conditionmib-02.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: <20020424105035.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-disman-conditionmib-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-disman-conditionmib-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020424105035.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-disman@dorothy.bmc.com Thu Apr 25 13:49:31 2002 Received: from babbler.bmc.com (camaro.bmc.com [198.207.223.231]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29220 for ; Thu, 25 Apr 2002 13:49:31 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g3PHpmO07062; Thu, 25 Apr 2002 12:51:52 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id KAA06993 for disman-list; Thu, 25 Apr 2002 10:45:25 -0700 (PDT) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id KAA06987 for disman@dorothy.bmc.com; Thu, 25 Apr 2002 10:45:21 -0700 (PDT) Date: Thu, 25 Apr 2002 10:45:21 -0700 (PDT) From: Randy Presuhn Message-Id: <200204251745.KAA06987@dorothy.bmc.com> To: disman@dorothy.bmc.com Subject: RE: Use of alarmListName 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 - > Subject: RE: Use of alarmListName > Date: Thu, 25 Apr 2002 07:22:13 +0300 > Message-ID: > From: "Romascanu, Dan (Dan)" > To: "Randy Presuhn" , ... > > > Subject: RE: Use of alarmListName > > > Date: Thu, 25 Apr 2002 03:05:26 +0300 > > > Message-ID: > > > avaya.com> > > > From: "Romascanu, Dan (Dan)" > > > To: "Randy Presuhn" , > > ... > > WG chair wondering aloud: if the WG consensus is to go > > with requiring implementations to know a priori how to > > extract resource IDs from notifications (I'm awaiting > > response to consensus call on *that*), and since what > > one needs to do to extract a resource ID from a notification > > depends on the notification type, do we need to specify > > the set of NOTIFICATION-TYPEs that MUST be understood by > > a conformant implementation, and do we need to specify > > how the resource ID extraction works for these? > > Why should it? The agent either knows how to populate > the alarmActiveResourceId object, or it does not. The MIB > structure does just that - passes alarms and identifies > resources described by the OID. The 'magic' of populating > the tables are not within the scope of the generic alarm model. ... This provides no assurance that different implementations would exhibit similar behaviour. I think interoperability would suffer. When a management application creates entries in the AlarmModelTable, does it receive any indication at all regarding whether the MIB implementation will know what to do with them, or that what one implementation will use as a resource identification algorithm will produce the same results as any other implementations? ------------------------------------------------------ Randy Presuhn BMC Software, Inc. 1-3141 randy_presuhn@bmc.com 2141 North First Street Tel: +1 408 546-1006 San José, California 95131 USA ------------------------------------------------------ My opinions and BMC's are independent variables. ------------------------------------------------------ From owner-disman@dorothy.bmc.com Thu Apr 25 13:55:29 2002 Received: from babbler.bmc.com (camaro.bmc.com [198.207.223.231]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29447 for ; Thu, 25 Apr 2002 13:55:28 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g3PHwAE08026; Thu, 25 Apr 2002 12:58:10 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id KAA07030 for disman-list; Thu, 25 Apr 2002 10:52:38 -0700 (PDT) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id KAA07024 for disman@dorothy.bmc.com; Thu, 25 Apr 2002 10:52:34 -0700 (PDT) Date: Thu, 25 Apr 2002 10:52:34 -0700 (PDT) From: Randy Presuhn Message-Id: <200204251752.KAA07024@dorothy.bmc.com> To: disman@dorothy.bmc.com Subject: RE: Use of alarmListName 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 - > Subject: RE: Use of alarmListName > Date: Thu, 25 Apr 2002 07:34:19 +0300 > Message-ID: > From: "Romascanu, Dan (Dan)" > To: "Ramanathan Kavasseri" , > "Randy Presuhn" > Cc: ... > > > And the rules are... ? > > > > Was hoping someone would provide this - as I'm scratching > > my head about how to go about it. > > :-( > > > would be glad to spare you the scratching ;-) > > it would not be a problem to specify such a mapping. Avoiding > to do this is by design. A generic agent needs not understand > the semantics of the alarms. Some agent implementations do > not use notifications to populate the alarmActiveTable. If > you want to 'hard code' such a mapping you may do it in the > model specific Alarm MIB. ... Ok, now I'm really lost. The only way that I can imagine a generic implementation doing resource id extraction is to provide some MIB objects that control how the extraction is to be performed for the notification types of interest. Forgive my lack of imagination, but without such objects, I don't see how a generic, magic-free implementation of the current MIB is possible. ------------------------------------------------------ Randy Presuhn BMC Software, Inc. 1-3141 randy_presuhn@bmc.com 2141 North First Street Tel: +1 408 546-1006 San José, California 95131 USA ------------------------------------------------------ My opinions and BMC's are independent variables. ------------------------------------------------------ From owner-disman@dorothy.bmc.com Thu Apr 25 19:40:41 2002 Received: from babbler.bmc.com (camaro.bmc.com [198.207.223.231]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09087 for ; Thu, 25 Apr 2002 19:40:40 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g3PNaft05627; Thu, 25 Apr 2002 18:36:41 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id QAA08879 for disman-list; Thu, 25 Apr 2002 16:30:35 -0700 (PDT) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id QAA08873 for disman@dorothy.bmc.com; Thu, 25 Apr 2002 16:30:31 -0700 (PDT) Date: Thu, 25 Apr 2002 16:30:31 -0700 (PDT) From: Randy Presuhn Message-Id: <200204252330.QAA08873@dorothy.bmc.com> To: disman@dorothy.bmc.com Subject: Alarm MIB security issues 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 - As a technical contributor, I think some security issues in draft-ietf-disman-alarm-mib-06.txt need to be addressed. 1) To prevent the alarm MIB from becoming a backdoor for circumventing access control on information carried in notifications. Something similar to the language in RFC 3014 section 2.1.2 is needed. Proposed text: Security for alarms is awkward since access control for the objects in the underlying notifications 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 Alarm MIB has the notion of a named alarm list. By using alarm list names and view-based access control [RFC2575] a network administrator can provide different access for different users. When an application creates an alarm model (indexed in part by the alarm list name) the security credentials of the creator remain associated with that alarm model and constrain what information is allowed to be placed in the active alarm table, the active alarm variable table, the cleared alarm table, and the ITU alarm table. When processing locally-generated Notifications, the managed system MUST use the security credentials associated with that each alarm model respectively, 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 processing remotely-generated Notifications using the alarm models. In those cases the security of the information in the alarm tables SHOULD be left to the normal, overall access control for those tables. -=-=-=-=-=- To fit this in with the overall processing flow established by the work on RFC 3014, I think some additional changes to the diagram in section 3.3 of draft-ietf-disman-alarm-mib-06.txt are necessary. Thes will: 2) To permit implementations to take full advantage of the RFC 2573 filtering infrastructure 3) To keep the semantics of alarmListName in this mib and nlmLogName in RFC 3014 consistent. The modified diagram would look something like: | |<----------------------------------------------+ | | +------------------V-------------+ | | +---------------V-----------+ | | | | RFC 2573 | | | | | SNMP-NOTIFICATION-MIB | | | | +--------+--------------+-+-+ | | | | | | | | | | | +------------------+ | | | | | | | | | | | +----------V--------------+ | | | | | | +--------V---------+ | | | +---------V------------+ | | | | Alarm Modelling | | | | | RFC 3014 | | | | | (descriptions) | | | | | NOTIFICATION-LOG-MIB | | | | +--------+---------+ | | | +----------------------+ | | | | | | | | | | +--------V------------+ | | | +------------------------V-+ | | | Generic: Model- | | | | | RFC 2573 | | | | Active : Specific | | | | | SNMP-TARGET-MIB | | | | Alarms : Extensions | | | | +----------+---------------+ | | +--------+------------+ | | | | | | | | | +------------|-------------------+ +----------|--------------+ | | | | | +------------------+ V Informs & Traps Note that there are really only two changes to the existing diagram: (1) swapping the SNMP-TARGET-MIB and SNMP-NOTIFICATION-MIB labels, which has already been agreed on this list, and (2) feeding the output of the SNMP-NOTIFICATION-MIB to alarm processing (just like the log MIB), rather than having the alarm processing "tap" the inputs into the SNMP-NOTIFICATION-MIB. ------------------------------------------------------ Randy Presuhn BMC Software, Inc. 1-3141 randy_presuhn@bmc.com 2141 North First Street Tel: +1 408 546-1006 San José, California 95131 USA ------------------------------------------------------ My opinions and BMC's are independent variables. ------------------------------------------------------ From owner-disman@dorothy.bmc.com Fri Apr 26 07:36:02 2002 Received: from babbler.bmc.com (camaro.bmc.com [198.207.223.231]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29855 for ; Fri, 26 Apr 2002 07:36:02 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g3QBce314192; Fri, 26 Apr 2002 06:38:40 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id EAA10511 for disman-list; Fri, 26 Apr 2002 04:32:45 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id EAA10505; Fri, 26 Apr 2002 04:32:41 -0700 (PDT) Received: from mx-us-hou-1-int.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id g3QBUPk20555; Fri, 26 Apr 2002 06:30:25 -0500 (CDT) Received: from ierw.net.avaya.com (unknown [198.152.13.101]) by mx-us-hou-1-int.bmc.com (Postfix) with SMTP id DDC1520EFAA; Fri, 26 Apr 2002 06:34:14 -0500 (CDT) Received: from ierw.net.avaya.com (localhost [127.0.0.1]) by ierw.net.avaya.com (8.9.3+Sun/8.9.3) with ESMTP id HAA20050; Fri, 26 Apr 2002 07:32:32 -0400 (EDT) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by ierw.net.avaya.com (8.9.3+Sun/8.9.3) with ESMTP id HAA20029; Fri, 26 Apr 2002 07:32:31 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Use of alarmListName Date: Fri, 26 Apr 2002 14:32:03 +0300 Message-ID: Thread-Topic: Use of alarmListName Thread-Index: AcHsgWAoU2WvnHyMT+CQxH7zbNjVmAAUZzqQ From: "Romascanu, Dan (Dan)" To: "Randy Presuhn" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by dorothy.bmc.com id EAA10506 Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list Content-Transfer-Encoding: 8bit > > > Subject: RE: Use of alarmListName > > Date: Thu, 25 Apr 2002 07:22:13 +0300 > > Message-ID: > avaya.com> > > From: "Romascanu, Dan (Dan)" > > To: "Randy Presuhn" , > > ... > > > > Subject: RE: Use of alarmListName > > > > Date: Thu, 25 Apr 2002 03:05:26 +0300 > > > > Message-ID: > > > > > avaya.com> > > > > From: "Romascanu, Dan (Dan)" > > > > To: "Randy Presuhn" , > > > > ... > > > WG chair wondering aloud: if the WG consensus is to go > > > with requiring implementations to know a priori how to > > > extract resource IDs from notifications (I'm awaiting > > > response to consensus call on *that*), and since what > > > one needs to do to extract a resource ID from a notification > > > depends on the notification type, do we need to specify > > > the set of NOTIFICATION-TYPEs that MUST be understood by > > > a conformant implementation, and do we need to specify > > > how the resource ID extraction works for these? > > > > Why should it? The agent either knows how to populate > > the alarmActiveResourceId object, or it does not. The MIB > > structure does just that - passes alarms and identifies > > resources described by the OID. The 'magic' of populating > > the tables are not within the scope of the generic alarm model. > ... > > This provides no assurance that different implementations would > exhibit similar behaviour. I think interoperability would suffer. > When a management application creates entries in the AlarmModelTable, > does it receive any indication at all regarding whether the MIB > implementation will know what to do with them, or that what one > implementation will use as a resource identification algorithm > will produce the same results as any other implementations? If the implementation does not know what to do with an entry in the AlarmModelTable it should reject the row creation. This needs to be documented, if it was not clear. It can happen even if an algorithmic mechanism to extract resource ID from notifications is being defined. Regards, Dan > > ------------------------------------------------------ > Randy Presuhn BMC Software, Inc. 1-3141 > randy_presuhn@bmc.com 2141 North First Street > Tel: +1 408 546-1006 San José, California 95131 USA > ------------------------------------------------------ > My opinions and BMC's are independent variables. > ------------------------------------------------------ > From owner-disman@dorothy.bmc.com Fri Apr 26 08:02:05 2002 Received: from babbler.bmc.com (camaro.bmc.com [198.207.223.231]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00376 for ; Fri, 26 Apr 2002 08:02:05 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g3QC4k022119; Fri, 26 Apr 2002 07:04:46 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id EAA10595 for disman-list; Fri, 26 Apr 2002 04:59:05 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id EAA10590 for ; Fri, 26 Apr 2002 04:59:02 -0700 (PDT) Received: from mx-us-hou-1-int.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id g3QBuk201186 for ; Fri, 26 Apr 2002 06:56:46 -0500 (CDT) Received: from zcars04e.ca.nortel.com (unknown [47.129.242.56]) by mx-us-hou-1-int.bmc.com (Postfix) with SMTP id 89D1120EFEA for ; Fri, 26 Apr 2002 07:00:35 -0500 (CDT) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g3QC0Sq19729 for ; Fri, 26 Apr 2002 08:00:28 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 26 Apr 2002 08:00:29 -0400 Message-ID: <3549C09B853DD5119B540002A52CDD3402EFE178@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: disman@dorothy.bmc.com Subject: Alarm #40 - Potential Solution Date: Fri, 26 Apr 2002 08:00:29 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list hi I know I have not sent out the updated issues list yet, but the following is issue is being tracked as #40 Alarm #40 Identify where to find resource identifier (in notification) when defining alarm model I had previously said that I did not think it would be practical to completely solve this problem. Now I think a mechanism like the following is simple, but goes a long way: alarmModelResourceIdentifiers OBJECT-TYPE SYNTAX BITS ACCESS read-only DESCRIPTION "This object identifies which varbinds within the notification identified by alarmModelNotificationId are used to uniquely identify this resource. For SNMPv1 traps, a 1 indicates the first varbind. For NOTIFICATION-TYPE, a 1 indicates the first real varbind after the required varbinds of sysUptime and SNMPTrapOID." ::= { alarmModelEntry X } I suspect, for completeness, it would also need some discussion about identifying the host portion of the resource. Sharon Chisholm Preside Management Nortel Networks Ottawa, Ontario From owner-disman@dorothy.bmc.com Fri Apr 26 13:52:43 2002 Received: from babbler.bmc.com (camaro.bmc.com [198.207.223.231]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17133 for ; Fri, 26 Apr 2002 13:52:42 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g3QHqpd07597; Fri, 26 Apr 2002 12:52:52 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id KAA11630 for disman-list; Fri, 26 Apr 2002 10:46:01 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id KAA11623 for ; Fri, 26 Apr 2002 10:45:57 -0700 (PDT) Received: from mx-us-hou-2-int.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id g3QHhfg29481 for ; Fri, 26 Apr 2002 12:43:42 -0500 (CDT) Received: from riverstonenet.com (mail.riverstonenet.com [63.113.148.10]) by mx-us-hou-2-int.bmc.com (Postfix) with SMTP id 2507C1FF00E for ; Fri, 26 Apr 2002 12:47:31 -0500 (CDT) Received: from dperkins-nb2.dsperkins.com by riverstonenet.com (8.9.3+Sun/SMI-SVR4-Yago) id KAA21219; Fri, 26 Apr 2002 10:47:15 -0700 (PDT) Message-Id: <5.0.2.1.2.20020426100819.02835030@mail4.bayarea.net> X-Sender: dperkins@mail4.bayarea.net X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Fri, 26 Apr 2002 10:46:53 -0700 To: "Sharon Chisholm" , disman@dorothy.bmc.com From: "David T. Perkins" Subject: Re: Alarm #40 - Potential Solution In-Reply-To: <3549C09B853DD5119B540002A52CDD3402EFE178@zcard0ka.ca.norte l.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 HI, While I defer judgement on whether this approach works, I do believe that the DESCRIPTION text needs an some updates. 1) It repeats a common terminology confusion.... notifications, defined using the NOTIFICATION-TYPE construct, are sent using the TRAP PDU type in SNMPv1, or the v2TRAP and INFORM PDU types in SNMPv2c and SNMPv3. (That is, saying NOTIFICATION-TYPE in the text below is just incorrect terminology usage. And I believe that Sharon understands the technology, but I wish she would get her fingers trained to type out the appropriate terminology.) 2) The object uses the BITS pseudo type to select 0, 1, or more items in the varBind list. The bits in the BITS type are numbered starting at zero. Because of this, the DESCRIPTION text may confuse the reader, since it talks about numbering from one. Also, I'm pretty interested in the choice of BITS instead of using unsigned to choose a single item in the varBind list. The DESCRIPTION text didn't really address this. In general, is the algorithm for determining resourceID something like the following: Check to see if the variable is a column in one of the tables that the implementation has support for, such as a column in the ifTable. If so, then really don't need to have any knowledge about the notification. All that is needed is to transform the variable to a canonical variable that would be used for the resourceID. For example, variable ifAdminStatus.23 (in a notification), would be converted to ifIndex.23 for the value of resourceID. Please let us know in detail how you envision the algorithm to function. At 08:00 AM 4/26/2002 -0400, Sharon Chisholm wrote: >hi > >I know I have not sent out the updated issues list yet, but >the following is issue is being tracked as #40 > >Alarm #40 Identify where to find resource identifier (in notification) > when defining alarm model > >I had previously said that I did not think it would be practical to >completely solve this problem. Now I think a mechanism like the >following is simple, but goes a long way: > > alarmModelResourceIdentifiers OBJECT-TYPE > SYNTAX BITS > ACCESS read-only > DESCRIPTION > "This object identifies which varbinds within > the notification identified by alarmModelNotificationId > are used to uniquely identify this resource. > > For SNMPv1 traps, a 1 indicates the first varbind. For > NOTIFICATION-TYPE, a 1 indicates the first real varbind > after the required varbinds of sysUptime and SNMPTrapOID." > ::= { alarmModelEntry X } > >I suspect, for completeness, it would also need some discussion about >identifying the host portion of the resource. > >Sharon Chisholm >Preside Management >Nortel Networks >Ottawa, Ontario Regards, /david t. perkins From owner-disman@dorothy.bmc.com Fri Apr 26 14:28:30 2002 Received: from babbler.bmc.com (camaro.bmc.com [198.207.223.231]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22052 for ; Fri, 26 Apr 2002 14:28:30 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g3QIVCL14621; Fri, 26 Apr 2002 13:31:12 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id LAA11752 for disman-list; Fri, 26 Apr 2002 11:25:37 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id LAA11747 for ; Fri, 26 Apr 2002 11:25:33 -0700 (PDT) Received: from mx-us-hou-1-int.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id g3QINGD17952 for ; Fri, 26 Apr 2002 13:23:16 -0500 (CDT) Received: from zcars04f.ca.nortel.com (unknown [47.129.242.57]) by mx-us-hou-1-int.bmc.com (Postfix) with SMTP id C9A3420EFC9 for ; Fri, 26 Apr 2002 13:27:05 -0500 (CDT) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g3QIQxb07265 for ; Fri, 26 Apr 2002 14:26:59 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 26 Apr 2002 14:26:59 -0400 Message-ID: <3549C09B853DD5119B540002A52CDD3402F9726B@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: disman@dorothy.bmc.com Subject: RE: Alarm #40 - Potential Solution Date: Fri, 26 Apr 2002 14:26:57 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list hi While I defer judgement on whether this approach works, I do believe that the DESCRIPTION text needs an some updates. 1) It repeats a common terminology confusion.... notifications, defined using the NOTIFICATION-TYPE construct, are sent using the TRAP PDU type in SNMPv1, or the v2TRAP and INFORM PDU types in SNMPv2c and SNMPv3. (That is, saying NOTIFICATION-TYPE in the text below is just incorrect terminology usage. And I believe that Sharon understands the technology, but I wish she would get her fingers trained to type out the appropriate terminology.) 2) The object uses the BITS pseudo type to select 0, 1, or more items in the varBind list. The bits in the BITS type are numbered starting at zero. Because of this, the DESCRIPTION text may confuse the reader, since it talks about numbering from one. Also, I'm pretty interested in the choice of BITS instead of using unsigned to choose a single item in the varBind list. The DESCRIPTION text didn't really address this. Yes, I caught the second one after I sent the email. I thought I cut and paste the text for the first point from the corrected text, but apparently I did not - oops. I'd be sure to fix both if we decide to go this route. I'm just trying to see if people like the general approach. In general, is the algorithm for determining resourceID something like the following: Check to see if the variable is a column in one of the tables that the implementation has support for, such as a column in the ifTable. If so, then really don't need to have any knowledge about the notification. All that is needed is to transform the variable to a canonical variable that would be used for the resourceID. For example, variable ifAdminStatus.23 (in a notification), would be converted to ifIndex.23 for the value of resourceID. Please let us know in detail how you envision the algorithm to function. Actually, I'm suggesting something quite different from what you are describing. What I'm suggesting is replacing the assumption that users know what varbinds in a notification identify the resource, with a bitmap that tells them. Notifications without resource identifiers are today treated as alarms against the device, and under this scheme I would see this as having a value of 0, or nothing set, for alarmModelResourceIdentifiers. The user knows which varbinds identify the resource under alarm and can then correlate between raise/clear instances without having to understand the content of the fields. Some examples: 1. linkDown would set bit 0, to point at ifIndex Once you have matched against the correct alarm model, you just check alarmActiveVariable*.1 to see if it matches notification.varbind.1 linkDown NOTIFICATION-TYPE OBJECTS { ifIndex, ifAdminStatus, ifOperStatus } STATUS current DESCRIPTION "A linkDown trap signifies that the SNMPv2 entity, acting in an agent role, has detected that the ifOperStatus object for one of its communication links is about to enter the down state from some other state (but not from the notPresent state). This other state is indicated by the included value of ifOperStatus." ::= { snmpTraps 3 } 2. mplsTunnelUp would set bit 0 and 1 (and 2 and 3 if these next two parameters are part of identifying the resource - I'd have to read the MIB) Once you have matched against the correct alarm model, you just check alarmActiveVariable*.1 to see if it matches notification.varbind.1 and check alarmActiveVariable*.2 to see if it matches notification.varbind.2 mplsTunnelUp NOTIFICATION-TYPE OBJECTS { mplsTunnelIndex, mplsTunnelInstance, mplsTunnelIngressLSRId, mplsTunnelEgressLSRId, mplsTunnelAdminStatus, mplsTunnelOperStatus } STATUS current DESCRIPTION "This notification is generated when a mplsTunnelOperStatus object for one of the configured tunnels is about to leave the down state and transition into some other state (but not into the notPresent state). This other state is indicated by the included value of mplsTunnelOperStatus." ::= { mplsTeNotifyPrefix 1 } Sharon At 08:00 AM 4/26/2002 -0400, Sharon Chisholm wrote: >hi > >I know I have not sent out the updated issues list yet, but >the following is issue is being tracked as #40 > >Alarm #40 Identify where to find resource identifier (in notification) > when defining alarm model > >I had previously said that I did not think it would be practical to >completely solve this problem. Now I think a mechanism like the >following is simple, but goes a long way: > > alarmModelResourceIdentifiers OBJECT-TYPE > SYNTAX BITS > ACCESS read-only > DESCRIPTION > "This object identifies which varbinds within > the notification identified by alarmModelNotificationId > are used to uniquely identify this resource. > > For SNMPv1 traps, a 1 indicates the first varbind. For > NOTIFICATION-TYPE, a 1 indicates the first real varbind > after the required varbinds of sysUptime and SNMPTrapOID." > ::= { alarmModelEntry X } > >I suspect, for completeness, it would also need some discussion about >identifying the host portion of the resource. > >Sharon Chisholm >Preside Management >Nortel Networks >Ottawa, Ontario Regards, /david t. perkins From owner-disman@dorothy.bmc.com Fri Apr 26 15:08:42 2002 Received: from babbler.bmc.com (camaro.bmc.com [198.207.223.231]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27065 for ; Fri, 26 Apr 2002 15:08:41 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g3QJB6521108; Fri, 26 Apr 2002 14:11:11 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id MAA11893 for disman-list; Fri, 26 Apr 2002 12:05:21 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id MAA11888 for ; Fri, 26 Apr 2002 12:05:17 -0700 (PDT) Received: from mx-us-hou-2-int.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id g3QJ31708579 for ; Fri, 26 Apr 2002 14:03:01 -0500 (CDT) Received: from riverstonenet.com (mail.riverstonenet.com [63.113.148.10]) by mx-us-hou-2-int.bmc.com (Postfix) with SMTP id 56B7F1FF00E for ; Fri, 26 Apr 2002 14:06:50 -0500 (CDT) Received: from dperkins-nb2.dsperkins.com by riverstonenet.com (8.9.3+Sun/SMI-SVR4-Yago) id MAA28119; Fri, 26 Apr 2002 12:06:32 -0700 (PDT) Message-Id: <5.0.2.1.2.20020426115737.0291c5d0@mail4.bayarea.net> X-Sender: dperkins@mail4.bayarea.net X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Fri, 26 Apr 2002 12:06:10 -0700 To: "Sharon Chisholm" From: "David T. Perkins" Subject: RE: Alarm #40 - Potential Solution Cc: disman@dorothy.bmc.com In-Reply-To: <3549C09B853DD5119B540002A52CDD3402F9726B@zcard0ka.ca.norte l.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 HI, Your examples "only work" because those notification types include the "canonical" resource identifier. Consider a new notification type, say, called linkStatusChange, that has only variables ifAdminStatus and ifOperStatus. And lets assume that for interface resources, the canonical resource identifier is an instance of ifIndex. You would have to translate from instances of ifAdminStatus (or ifOperStatus) to instances of ifIndex. I don't know how you would use two variables to do the translation. At 02:26 PM 4/26/2002 -0400, you wrote: > >In general, is the algorithm for determining resourceID something >like the following: > Check to see if the variable is a column in one of the > tables that the implementation has support for, such as > a column in the ifTable. If so, then really don't need to > have any knowledge about the notification. All that is > needed is to transform the variable to a canonical variable > that would be used for the resourceID. For example, > variable ifAdminStatus.23 (in a notification), would be > converted to ifIndex.23 for the value of resourceID. > >Please let us know in detail how you envision the algorithm >to function. > > >Actually, I'm suggesting something quite different from >what you are describing. > >What I'm suggesting is replacing the assumption that users >know what varbinds in a notification identify the resource, >with a bitmap that tells them. Notifications without resource >identifiers are today treated as alarms against the device, >and under this scheme I would see this as having a value of >0, or nothing set, for alarmModelResourceIdentifiers. > >The user knows which varbinds identify the resource under >alarm and can then correlate between raise/clear instances >without having to understand the content of the fields. > >Some examples: > >1. linkDown would set bit 0, to point at ifIndex > > Once you have matched against the correct alarm model, > you just check alarmActiveVariable*.1 to see if it > matches notification.varbind.1 > > linkDown NOTIFICATION-TYPE > OBJECTS { ifIndex, ifAdminStatus, ifOperStatus } > STATUS current > DESCRIPTION > "A linkDown trap signifies that the SNMPv2 entity, > acting in an agent role, has detected that the > ifOperStatus object for one of its communication links > is about to enter the down state from some other state > (but not from the notPresent state). This other state > is indicated by the included value of ifOperStatus." > ::= { snmpTraps 3 } > >2. mplsTunnelUp would set bit 0 and 1 (and 2 and 3 > if these next two parameters are part of identifying > the resource - I'd have to read the MIB) > > Once you have matched against the correct alarm model, > you just check alarmActiveVariable*.1 to see if it > matches notification.varbind.1 and check alarmActiveVariable*.2 > to see if it matches notification.varbind.2 > > mplsTunnelUp NOTIFICATION-TYPE > OBJECTS { > mplsTunnelIndex, > mplsTunnelInstance, > mplsTunnelIngressLSRId, > mplsTunnelEgressLSRId, > mplsTunnelAdminStatus, > mplsTunnelOperStatus > } > STATUS current > DESCRIPTION > "This notification is generated when a > mplsTunnelOperStatus object for one of the > configured tunnels is about to leave the down state > and transition into some other state (but not into > the notPresent state). This other state is > indicated by the included value of > mplsTunnelOperStatus." > ::= { mplsTeNotifyPrefix 1 } > >Sharon What is the canonical resource identifier in the above example? Also, the above looks like "bad" notification design because it appears to include redundant index objects, which is bad. Regards, /david t. perkins From owner-disman@dorothy.bmc.com Fri Apr 26 15:30:26 2002 Received: from babbler.bmc.com (camaro.bmc.com [198.207.223.231]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29831 for ; Fri, 26 Apr 2002 15:30:19 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g3QJWuu24330; Fri, 26 Apr 2002 14:32:56 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id MAA11961 for disman-list; Fri, 26 Apr 2002 12:27:18 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id MAA11956 for ; Fri, 26 Apr 2002 12:27:14 -0700 (PDT) Received: from mx-us-hou-2-int.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id g3QJOxp19826 for ; Fri, 26 Apr 2002 14:24:59 -0500 (CDT) Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by mx-us-hou-2-int.bmc.com (Postfix) with SMTP id 9B0121FF00E for ; Fri, 26 Apr 2002 14:28:48 -0500 (CDT) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g3QJSLq07775 for ; Fri, 26 Apr 2002 15:28:21 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 26 Apr 2002 15:28:22 -0400 Message-ID: <3549C09B853DD5119B540002A52CDD3402F97383@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: disman@dorothy.bmc.com Subject: RE: Alarm #40 - Potential Solution Date: Fri, 26 Apr 2002 15:28:21 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list hi Arg. Well, I think you've just demonstrated how annoying that SMI rule is. ;-) Ok, well it could be done with two bitmaps 1) Variable OIDs to match on ifOperStatus.3 = Don't Care 2) Values of variables to match on ifIndex.3 = 3 But now the simple solution is a bit less simple. Sharon -----Original Message----- From: David T. Perkins [mailto:dperkins@dsperkins.com] Sent: Friday, April 26, 2002 3:06 PM To: Chisholm, Sharon [CAR:NM50:EXCH] Cc: disman@dorothy.bmc.com Subject: RE: Alarm #40 - Potential Solution HI, Your examples "only work" because those notification types include the "canonical" resource identifier. Consider a new notification type, say, called linkStatusChange, that has only variables ifAdminStatus and ifOperStatus. And lets assume that for interface resources, the canonical resource identifier is an instance of ifIndex. You would have to translate from instances of ifAdminStatus (or ifOperStatus) to instances of ifIndex. I don't know how you would use two variables to do the translation. At 02:26 PM 4/26/2002 -0400, you wrote: > >In general, is the algorithm for determining resourceID something >like the following: > Check to see if the variable is a column in one of the > tables that the implementation has support for, such as > a column in the ifTable. If so, then really don't need to > have any knowledge about the notification. All that is > needed is to transform the variable to a canonical variable > that would be used for the resourceID. For example, > variable ifAdminStatus.23 (in a notification), would be > converted to ifIndex.23 for the value of resourceID. > >Please let us know in detail how you envision the algorithm >to function. > > >Actually, I'm suggesting something quite different from >what you are describing. > >What I'm suggesting is replacing the assumption that users >know what varbinds in a notification identify the resource, >with a bitmap that tells them. Notifications without resource >identifiers are today treated as alarms against the device, >and under this scheme I would see this as having a value of >0, or nothing set, for alarmModelResourceIdentifiers. > >The user knows which varbinds identify the resource under >alarm and can then correlate between raise/clear instances >without having to understand the content of the fields. > >Some examples: > >1. linkDown would set bit 0, to point at ifIndex > > Once you have matched against the correct alarm model, > you just check alarmActiveVariable*.1 to see if it > matches notification.varbind.1 > > linkDown NOTIFICATION-TYPE > OBJECTS { ifIndex, ifAdminStatus, ifOperStatus } > STATUS current > DESCRIPTION > "A linkDown trap signifies that the SNMPv2 entity, > acting in an agent role, has detected that the > ifOperStatus object for one of its communication links > is about to enter the down state from some other state > (but not from the notPresent state). This other state > is indicated by the included value of ifOperStatus." > ::= { snmpTraps 3 } > >2. mplsTunnelUp would set bit 0 and 1 (and 2 and 3 > if these next two parameters are part of identifying > the resource - I'd have to read the MIB) > > Once you have matched against the correct alarm model, > you just check alarmActiveVariable*.1 to see if it > matches notification.varbind.1 and check alarmActiveVariable*.2 > to see if it matches notification.varbind.2 > > mplsTunnelUp NOTIFICATION-TYPE > OBJECTS { > mplsTunnelIndex, > mplsTunnelInstance, > mplsTunnelIngressLSRId, > mplsTunnelEgressLSRId, > mplsTunnelAdminStatus, > mplsTunnelOperStatus > } > STATUS current > DESCRIPTION > "This notification is generated when a > mplsTunnelOperStatus object for one of the > configured tunnels is about to leave the down state > and transition into some other state (but not into > the notPresent state). This other state is > indicated by the included value of > mplsTunnelOperStatus." > ::= { mplsTeNotifyPrefix 1 } > >Sharon What is the canonical resource identifier in the above example? Also, the above looks like "bad" notification design because it appears to include redundant index objects, which is bad. Regards, /david t. perkins From owner-disman@dorothy.bmc.com Fri Apr 26 19:54:21 2002 Received: from babbler.bmc.com (firebird.bmc.com [198.207.223.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00213 for ; Fri, 26 Apr 2002 19:54:20 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g3QNv0s02933; Fri, 26 Apr 2002 18:57:00 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id QAA13993 for disman-list; Fri, 26 Apr 2002 16:50:38 -0700 (PDT) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id QAA13987 for disman@dorothy.bmc.com; Fri, 26 Apr 2002 16:50:34 -0700 (PDT) Date: Fri, 26 Apr 2002 16:50:34 -0700 (PDT) From: Randy Presuhn Message-Id: <200204262350.QAA13987@dorothy.bmc.com> To: disman@dorothy.bmc.com Subject: RE: Alarm #40 - Potential Solution 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: <3549C09B853DD5119B540002A52CDD3402F97383@zcard0ka.ca.nortel.com> > From: "Sharon Chisholm" > To: disman@dorothy.bmc.com > Subject: RE: Alarm #40 - Potential Solution > Date: Fri, 26 Apr 2002 15:28:21 -0400 ... > But now the simple solution is a bit less simple. ... As a technical contributor... I think the "positional" approach to identifying the varbind for resource ID extraction is making things more complicated than they need to be. There are three broad cases: 1) The varbinds don't reveal the resource ID; the identity of the resource is simply implied by the notification type. Example: authenticationFailure. 2) The name portion of one of the variable bindings identifies the resource, though perhaps not directly. Here, for a given notification type, one needs to: a) figure out which variable binding is the interesting one b) extract the portion of the name that has the index we want c) tack that onto an object identifier "base" to form an appropriate rowpointer 3) The value portion of one of the varible bindings identifies the resource, though perhaps not directly. Do any such things exist? In the interest of keeping things relatively simply, I'm proposing two objects for the AlarmModelTable specifically for resource identification. These cover (1) and (2) in a fully general way, without requiring any magic or specific knowledge of different notification types in the alarm MIB implementation. Graphically: +--------------------------------+--------------+ | name | | | | (Prefix) | (Indexes) | +--------------------------------+--------------+ / use alarmModelVarbindSubtree1 / \ to match, split prefix / index \ | / 0.0 matches any prefix, yields / V \ empty indexes \ +--------------------------------+--------------+ | use alarmModelResourceSubtree | Indexes | | to supply new base. (0.0 just | | | passes through "prefix" | | +--------------------------------+--------------+ The operation of these two objects can be summarized in a simple table: ...ResourceSubtree # alarmModelVarbindSubtree # 0.0 | not 0.0 -------------------#-------------------+----------------------- not 0.0 # resulting name is | resulting name is the # ResourceSubtree | concatenation of the # | ResourceSubtree and the # | index from the varbind # | name (the part following # | the matching initial part) -------------------#-------------------+----------------------- 0.0 # pass name through | pass through matching # untouched | portion of name -------------------#-------------------+----------------------- alarmModelVarbindSubtree OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-create STATUS current DESCRIPTION "The name portion of each VarBind in the notification, in order, is compared to the value of this object. If the name is equal to or a subtree of the value of this object, for purposes of computing the value of AlarmActiveResourceID the 'prefix' will be the matching portion, and the 'indexes' will be any remainder. The examination of varbinds ends with the first match. " DEFVAL { {0 0} } ::= { whatever } alarmModelResourceSubtree OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-create STATUS current DESCRIPTION "The value of AlarmActiveResourceID is computed by appending any indexes extracted in accordance with the description of alarmModelVarbindSubtree onto the value of this object. If this object's value is 0.0, then the 'prefix' extracted is used instead. " DEFVAL { {0 0} } ::= { whatever } Three concrete examples: 1) if I receive an authenticationFailure, I'd like the resource to be 1.3.6.1.6.3.15.1.1, so I configure: alarmModelVarbindSubtree = 0.0 alarmModelResourceSubtree = 1.3.6.1.6.3.15.1.1 2) if I receive a linkDown that contains SDLC physicalFailures statistics, I'd like to have my alarm refer to the right ifEntry: alarmModelVarbindSubtree = 1.3.6.1.2.1.41.1.1.3.1.1 alarmModelResourceSubtree = 1.3.6.1.2.1.2.2.1.1 3) if the first varbind is always going to point to the right thing, then I just: alarmModelVarbindSubtree = 0.0 alarmModelResourceSubtree = 0.0 ------------------------------------------------------ Randy Presuhn BMC Software, Inc. 1-3141 randy_presuhn@bmc.com 2141 North First Street Tel: +1 408 546-1006 San José, California 95131 USA ------------------------------------------------------ My opinions and BMC's are independent variables. ------------------------------------------------------ From owner-disman@dorothy.bmc.com Sat Apr 27 04:08:02 2002 Received: from babbler.bmc.com (camaro.bmc.com [198.207.223.231]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02794 for ; Sat, 27 Apr 2002 04:08:01 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g3R8AbF12680; Sat, 27 Apr 2002 03:10:41 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id BAA15286 for disman-list; Sat, 27 Apr 2002 01:03:25 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id BAA15281 for ; Sat, 27 Apr 2002 01:03:21 -0700 (PDT) Received: from mx-us-hou-2-int.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id g3R815l08491 for ; Sat, 27 Apr 2002 03:01:06 -0500 (CDT) Received: from agitator.ibr.cs.tu-bs.de (agitator.ibr.cs.tu-bs.de [134.169.34.18]) by mx-us-hou-2-int.bmc.com (Postfix) with SMTP id C1D1F1FF0C7 for ; Sat, 27 Apr 2002 03:04:54 -0500 (CDT) Received: from haerke.ibr.cs.tu-bs.de (IDENT:root@haerke.ibr.cs.tu-bs.de [134.169.34.84]) by agitator.ibr.cs.tu-bs.de (8.12.1/8.12.1/Debian -2) with ESMTP id g3R83pN4024996; Sat, 27 Apr 2002 10:03:51 +0200 Received: (from schoenw@localhost) by haerke.ibr.cs.tu-bs.de (8.11.6/8.11.6) id g3R83ov12423; Sat, 27 Apr 2002 10:03:50 +0200 Date: Sat, 27 Apr 2002 10:03:50 +0200 Message-Id: <200204270803.g3R83ov12423@haerke.ibr.cs.tu-bs.de> X-Authentication-Warning: haerke.ibr.cs.tu-bs.de: schoenw set sender to schoenw@ibr.cs.tu-bs.de using -f From: Juergen Schoenwaelder To: dperkins@dsperkins.com Cc: schishol@nortelnetworks.com, disman@dorothy.bmc.com In-reply-to: <5.0.2.1.2.20020426115737.0291c5d0@mail4.bayarea.net> (dperkins@dsperkins.com) Subject: Re: Alarm #40 - Potential Solution References: <5.0.2.1.2.20020426115737.0291c5d0@mail4.bayarea.net> Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list >>>>> David T Perkins writes: David> Your examples "only work" because those notification types David> include the "canonical" resource identifier. Consider a new David> notification type, say, called linkStatusChange, that has only David> variables ifAdminStatus and ifOperStatus. And lets assume that David> for interface resources, the canonical resource identifier is David> an instance of ifIndex. You would have to translate from David> instances of ifAdminStatus (or ifOperStatus) to instances of David> ifIndex. David> I don't know how you would use two variables to do the David> translation. I agree with Dave's concerns in general. Notifications which would work for automatic alarm identification need to be designed for this purpose. And this constitutes a major change in the way we were defining notifications so far. Without special purpose notifications (and hopefully some guiding rules how to design them), there will always be magic involved and thus the alarm MIB must be "notification aware" in order to produce sensible alarms. Perhaps this is not even that bad as it might sound at first glance. I think we need to make a clear decision to either require that notifications have a certain structure to make automatic alarm determination feasible or to accept that sensible alarms can only be determined by alarm MIBs that understand specific notification formats. /js -- Juergen Schoenwaelder From owner-disman@dorothy.bmc.com Mon Apr 29 01:04:03 2002 Received: from babbler.bmc.com (camaro.bmc.com [198.207.223.231]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA14659 for ; Mon, 29 Apr 2002 01:04:03 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g3T55xJ20719; Mon, 29 Apr 2002 00:06:09 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id VAA18992 for disman-list; Sun, 28 Apr 2002 21:56:33 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id VAA18986; Sun, 28 Apr 2002 21:56:29 -0700 (PDT) Received: from mx-us-hou-1-int.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id g3T4sCC15635; Sun, 28 Apr 2002 23:54:12 -0500 (CDT) Received: from riverstonenet.com (unknown [63.113.148.10]) by mx-us-hou-1-int.bmc.com (Postfix) with SMTP id CAAEC20EF88; Sun, 28 Apr 2002 23:58:02 -0500 (CDT) Received: from dperkins-nb2.dsperkins.com by riverstonenet.com (8.9.3+Sun/SMI-SVR4-Yago) id VAA18820; Sun, 28 Apr 2002 21:58:00 -0700 (PDT) Message-Id: <5.1.0.14.2.20020428213841.02828ec0@mail4.bayarea.net> X-Sender: dperkins@mail4.bayarea.net X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sun, 28 Apr 2002 21:57:36 -0700 To: Randy Presuhn , disman@dorothy.bmc.com From: "David T. Perkins" Subject: Re: Alarm MIB security issues In-Reply-To: <200204252330.QAA08873@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 HI, I'm having problems following the below. However, it appears that it is reusing a "BROKEN" design pattern found in RFC 3014. I HOPE THAT THIS BROKEN DESIGN PATTERN IS NOT USED IN OTHER MIB MODULES. This is marked below.. At 04:30 PM 4/25/2002 -0700, Randy Presuhn wrote: >Hi - > >As a technical contributor, I think some security issues in >draft-ietf-disman-alarm-mib-06.txt need to be addressed. > > 1) To prevent the alarm MIB from becoming a backdoor for > circumventing access control on information carried > in notifications. Something similar to the language > in RFC 3014 section 2.1.2 is needed. Proposed text: > > Security for alarms is awkward since access control for the objects > in the underlying notifications 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 Alarm MIB has the notion of a named alarm list. By using > alarm list names and view-based access control [RFC2575] a network > administrator can provide different access for different users. VVVVVVVV > When an application creates an alarm model (indexed in part by the > alarm list name) the security credentials of the creator remain > associated with that alarm model and constrain what information is > allowed to be placed in the active alarm table, the active alarm > variable table, the cleared alarm table, and the ITU alarm table. > When processing locally-generated Notifications, the managed > system MUST use the security credentials associated with > that each alarm model respectively, and MUST apply the > same access control rules as described for a Notification > Originator in [RFC2573]. ^^^^^^^^ This is just totally broken. Why? Because the information is "hidden". A manager cannot look at the created rows and figure out the what is the behavior without knowing the hidden values. Also, if one wanted to "save the configuration" and then "restore it", it would be impossible. Also, say that you used SNMPv3 with USM and auth/priv to create the row. This one mean that only notifications that were allowed to be sent with auth/priv could result in additions to the active table. This is just not correct. > The managed system SHOULD NOT apply access control when > processing remotely-generated Notifications using the alarm > models. In those cases the security of the information > in the alarm tables SHOULD be left to the normal, overall > access control for those tables. > > -=-=-=-=-=- > >To fit this in with the overall processing flow established by >the work on RFC 3014, I think some additional changes to the >diagram in section 3.3 of draft-ietf-disman-alarm-mib-06.txt >are necessary. Thes will: > > 2) To permit implementations to take full advantage of > the RFC 2573 filtering infrastructure > > 3) To keep the semantics of alarmListName in this mib and > nlmLogName in RFC 3014 consistent. I don't believe that we should repeat the same mistakes found in other MIB modules. There is work in progress on fixing RFC 3014. >The modified diagram would look something like: > > | > |<----------------------------------------------+ > | | > +------------------V-------------+ | > | +---------------V-----------+ | | > | | RFC 2573 | | | > | | SNMP-NOTIFICATION-MIB | | | > | +--------+--------------+-+-+ | | > | | | | | | > | | | +------------------+ | > | | | | | | > | | | | +----------V--------------+ | > | | | | | +--------V---------+ | | > | +---------V------------+ | | | | Alarm Modelling | | | > | | RFC 3014 | | | | | (descriptions) | | | > | | NOTIFICATION-LOG-MIB | | | | +--------+---------+ | | > | +----------------------+ | | | | | | > | | | | +--------V------------+ | | > | +------------------------V-+ | | | Generic: Model- | | | > | | RFC 2573 | | | | Active : Specific | | | > | | SNMP-TARGET-MIB | | | | Alarms : Extensions | | | > | +----------+---------------+ | | +--------+------------+ | | > | | | | | | | > +------------|-------------------+ +----------|--------------+ | > | | | > | +------------------+ > V > Informs & Traps > >Note that there are really only two changes to the >existing diagram: (1) swapping the SNMP-TARGET-MIB and >SNMP-NOTIFICATION-MIB labels, which has already been >agreed on this list, and (2) feeding the output of the >SNMP-NOTIFICATION-MIB to alarm processing (just like the >log MIB), rather than having the alarm processing "tap" >the inputs into the SNMP-NOTIFICATION-MIB. > > ------------------------------------------------------ > Randy Presuhn BMC Software, Inc. 1-3141 Regards, /david t. perkins From owner-disman@dorothy.bmc.com Mon Apr 29 16:24:44 2002 Received: from babbler.bmc.com (firebird.bmc.com [198.207.223.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18400 for ; Mon, 29 Apr 2002 16:24:44 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g3TKRIi16257; Mon, 29 Apr 2002 15:27:22 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id NAA21737 for disman-list; Mon, 29 Apr 2002 13:20:38 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id NAA21732 for ; Mon, 29 Apr 2002 13:20:35 -0700 (PDT) Received: from mx-us-hou-2-int.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id g3TKIHl08788 for ; Mon, 29 Apr 2002 15:18:18 -0500 (CDT) Received: from hawk.mail.pas.earthlink.net (hawk.mail.pas.earthlink.net [207.217.120.22]) by mx-us-hou-2-int.bmc.com (Postfix) with SMTP id BD6C91FF12F for ; Mon, 29 Apr 2002 15:22:08 -0500 (CDT) Received: from 1cust22.tnt2.minneapolis.mn.da.uu.net ([67.251.129.22] helo=merkita.com) by hawk.mail.pas.earthlink.net with esmtp (Exim 3.33 #2) id 172Heg-0007iA-00; Mon, 29 Apr 2002 13:21:51 -0700 Message-ID: <3CCDAABC.8EF6D1B@merkita.com> Date: Mon, 29 Apr 2002 15:19:08 -0500 From: Tammy Ferris Reply-To: tferris@merkita.com X-Mailer: Mozilla 4.75 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Romascanu, Dan (Dan)" Cc: "David T. Perkins" , disman@dorothy.bmc.com Subject: Re: Use of Alarm MIB without ITU MIB References: 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 Dan, Can you clarify where these applications are documented? Currently, the Alarm MIB does not support the ITU model for security alarms so I am assuming that you are referring to something else? The ITU security alarms don't support clear notifications.... they are transient alarms. Also, I don't know why you called out separately, facilities alarms.... ITU model, of course, supports facility alarms. Could you please clarify? Thanks, Tammy "Romascanu, Dan (Dan)" wrote: > There are two other applications of the Alarm MIB that I am aware about, and require model specific Alarm MIBs to be attached: > > 1. network security and access control. There is practically no superposition or common functionality with the ITU Alarm MIB > 2. facilities management - some commonality, still a lot of specifics that need to be dealt with separately > > Regards, > > Dan > > > -----Original Message----- > > From: David T. Perkins [mailto:dperkins@dsperkins.com] > > Sent: Thursday, April 18, 2002 9:22 AM > > To: disman@dorothy.bmc.com > > Subject: Use of Alarm MIB without ITU MIB > > > > > > HI, > > > > It really doesn't seem like the Alarm MIB is useful without the > > ITU MIB. Can an example be provided of another specific model > > so we can determine if all specific models have the common info > > which should be contained in the generic tables. > > > > Regards, > > /david t. perkins > > > > From owner-disman@dorothy.bmc.com Mon Apr 29 19:13:23 2002 Received: from babbler.bmc.com (camaro.bmc.com [198.207.223.231]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22628 for ; Mon, 29 Apr 2002 19:13:23 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g3TNG1j08546; Mon, 29 Apr 2002 18:16:01 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id QAA25600 for disman-list; Mon, 29 Apr 2002 16:09:51 -0700 (PDT) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id QAA25592 for disman@dorothy.bmc.com; Mon, 29 Apr 2002 16:09:47 -0700 (PDT) Date: Mon, 29 Apr 2002 16:09:47 -0700 (PDT) From: Randy Presuhn Message-Id: <200204292309.QAA25592@dorothy.bmc.com> To: disman@dorothy.bmc.com Subject: Re: Alarm MIB security 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 - > Message-Id: <5.1.0.14.2.20020428213841.02828ec0@mail4.bayarea.net> > Date: Sun, 28 Apr 2002 21:57:36 -0700 > To: Randy Presuhn , disman@dorothy.bmc.com > From: "David T. Perkins" > Subject: Re: Alarm MIB security issues > In-Reply-To: <200204252330.QAA08873@dorothy.bmc.com> ... > I'm having problems following the below. However, it appears that it > is reusing a "BROKEN" design pattern found in RFC 3014. I HOPE THAT > THIS BROKEN DESIGN PATTERN IS NOT USED IN OTHER MIB MODULES. > This is marked below.. > > At 04:30 PM 4/25/2002 -0700, Randy Presuhn wrote: ... > VVVVVVVV > > When an application creates an alarm model (indexed in part by the > > alarm list name) the security credentials of the creator remain > > associated with that alarm model and constrain what information is > > allowed to be placed in the active alarm table, the active alarm > > variable table, the cleared alarm table, and the ITU alarm table. > > When processing locally-generated Notifications, the managed > > system MUST use the security credentials associated with > > that each alarm model respectively, and MUST apply the > > same access control rules as described for a Notification > > Originator in [RFC2573]. > > ^^^^^^^^ > This is just totally broken. Why? Because the information is "hidden". > A manager cannot look at the created rows and figure out the what > is the behavior without knowing the hidden values. Also, if one wanted > to "save the configuration" and then "restore it", it would be impossible. Writing as WG chair... Like it or not, there are already several standards-track RFCs with similar properties, e.g.: RFC 2982, Expression MIB RFC 2981, Event MIB RFC 3014, Log MIB, RFC 3165, Script MIB RFC 3231, Schedule MIB Several years ago, we had lengthy discussions in disman WG meetings regarding the pros and cons of "explicit delegation" rather than the path that we've taken. Though I personally believed (and still believe) explicit delegation to be both more powerful and ultimately easier to understand, the working group did not, and the consistent direction in the current RFCs and I-Ds reflects that rough consensus. Though I might personally very much like to see things working on a foundation of explicit delegation rather than the current implicit model, I don't see anything approaching a concensus to make such a potentially disruptive change, and nothing from implementation experience to date to suggest that what we currently have is unworkable. As a technical contributor, I'd like to remind you that several objects in RFC 2574 have the same "bug"/"feature" regarding the ability to use SNMP to extract a system's configuration. > Also, say that you used SNMPv3 with USM and auth/priv to create the > row. This one mean that only notifications that were allowed to be > sent with auth/priv could result in additions to the active table. > This is just not correct. ... As a technical contributor, I believe this is perfectly reasonable. No sane security administrator would circumscribe the auth/priv views more narrowly than noauth/nopriv. More importantly, notifications which are only allowed on the wire in auth/priv form should not go into "public" active alarm tables. ------------------------------------------------------ Randy Presuhn BMC Software, Inc. 1-3141 randy_presuhn@bmc.com 2141 North First Street Tel: +1 408 546-1006 San José, California 95131 USA ------------------------------------------------------ My opinions and BMC's are independent variables. ------------------------------------------------------ From owner-disman@dorothy.bmc.com Mon Apr 29 20:06:38 2002 Received: from babbler.bmc.com (firebird.bmc.com [198.207.223.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23931 for ; Mon, 29 Apr 2002 20:06:38 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g3U09IZ14792; Mon, 29 Apr 2002 19:09:18 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id RAA09488 for disman-list; Mon, 29 Apr 2002 17:01:17 -0700 (PDT) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id QAA06003; Mon, 29 Apr 2002 16:58:07 -0700 (PDT) Date: Mon, 29 Apr 2002 16:58:07 -0700 (PDT) From: Randy Presuhn Message-Id: <200204292358.QAA06003@dorothy.bmc.com> To: agentx@dorothy.bmc.com, disman@dorothy.bmc.com Subject: disman/agentx FTP site planned outage 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 - On Wednesday May 1st, 2002 sometime in the window from 19:00 to 20:00 Pacific Daylight Time, the host for the AgentX and DisMan working group's FTP sites will be re-booted. There should be no disruption to the mailing list. ------------------------------------------------------ Randy Presuhn BMC Software, Inc. 1-3141 randy_presuhn@bmc.com 2141 North First Street Tel: +1 408 546-1006 San José, California 95131 USA ------------------------------------------------------ My opinions and BMC's are independent variables. ------------------------------------------------------ From owner-disman@dorothy.bmc.com Mon Apr 29 21:26:11 2002 Received: from babbler.bmc.com (camaro.bmc.com [198.207.223.231]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25035 for ; Mon, 29 Apr 2002 21:26:10 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g3U1SrZ22771; Mon, 29 Apr 2002 20:28:53 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id SAA14431 for disman-list; Mon, 29 Apr 2002 18:22:55 -0700 (PDT) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id SAA14425; Mon, 29 Apr 2002 18:22:50 -0700 (PDT) Date: Mon, 29 Apr 2002 18:22:50 -0700 (PDT) From: Randy Presuhn Message-Id: <200204300122.SAA14425@dorothy.bmc.com> To: disman@dorothy.bmc.com Subject: Communication from ITU-T Study Group 4 Cc: djsidor@nortelnetworks.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 - Forwarded from our area director, Bert Wijnen... > From: McGrath, Margaret [mailto:margaret.mcgrath@itu.int] > Sent: Friday, April 26, 2002 4:09 PM > To: 'bwijnen@lucent.com' > Cc: Choe, Young-Han; 'djsidor@nortelnetworks.com' > Subject: Communication statement from ITU-T Study Group 4 > > > > Please find attached a Communication Statement from the April 2002 = > meeting of ITU-T Study Group 4 addressed to IETF disman WG. > > Regards. > > Mair=E9ad McGrath ... Rather than sending the Microsoft Word-encoded document to our entire mailing list (the text of this document was sent out to this mailing list some time ago) I'm just sending the URL of a copy of the document in our WG archives: ftp://amethyst.bmc.com/pub/disman/itu/2002-04-29_sg4_liaison.doc Again, I'd like to publicly thank SG4 for their comments. ------------------------------------------------------ Randy Presuhn BMC Software, Inc. 1-3141 randy_presuhn@bmc.com 2141 North First Street Tel: +1 408 546-1006 San José, California 95131 USA ------------------------------------------------------ My opinions and BMC's are independent variables. ------------------------------------------------------ From owner-disman@dorothy.bmc.com Mon Apr 29 22:03:37 2002 Received: from babbler.bmc.com (camaro.bmc.com [198.207.223.231]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA26384 for ; Mon, 29 Apr 2002 22:03:37 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g3U26KN29724; Mon, 29 Apr 2002 21:06:21 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id TAA14504 for disman-list; Mon, 29 Apr 2002 19:00:45 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id TAA14499 for ; Mon, 29 Apr 2002 19:00:41 -0700 (PDT) Received: from mx-us-hou-1-int.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id g3U1wOe15061 for ; Mon, 29 Apr 2002 20:58:24 -0500 (CDT) Received: from riverstonenet.com (unknown [63.113.148.10]) by mx-us-hou-1-int.bmc.com (Postfix) with SMTP id 98D5B20EFCC for ; Mon, 29 Apr 2002 21:02:15 -0500 (CDT) Received: from dperkins-nb2.dsperkins.com by riverstonenet.com (8.9.3+Sun/SMI-SVR4-Yago) id TAA09109; Mon, 29 Apr 2002 19:02:14 -0700 (PDT) Message-Id: <5.1.0.14.2.20020429185746.0378a070@mail4.bayarea.net> X-Sender: dperkins@mail4.bayarea.net X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 29 Apr 2002 19:01:22 -0700 To: disman@dorothy.bmc.com From: "David T. Perkins" Subject: Re: 2574 OBJECTS (was Alarm MIB security issues) In-Reply-To: <200204292309.QAA25592@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 HI, At 04:09 PM 4/29/2002 -0700, Randy Presuhn wrote: >As a technical contributor, I'd like to remind you that several >objects in RFC 2574 have the same "bug"/"feature" regarding the >ability to use SNMP to extract a system's configuration. Other than the keys, what objects have the attribute that you can not retrieve values set via SNMP so that you can restore the configuration via SNMP? Or were you talking about another attribute? Regards, /david t. perkins From owner-disman@dorothy.bmc.com Mon Apr 29 22:16:41 2002 Received: from babbler.bmc.com (firebird.bmc.com [198.207.223.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA26569 for ; Mon, 29 Apr 2002 22:16:41 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g3U2JPC03104; Mon, 29 Apr 2002 21:19:25 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id TAA14529 for disman-list; Mon, 29 Apr 2002 19:13:49 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id TAA14524 for ; Mon, 29 Apr 2002 19:13:45 -0700 (PDT) Received: from mx-us-hou-1-int.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id g3U2BSQ19386 for ; Mon, 29 Apr 2002 21:11:28 -0500 (CDT) Received: from riverstonenet.com (unknown [63.113.148.10]) by mx-us-hou-1-int.bmc.com (Postfix) with SMTP id A6DA320EFC6 for ; Mon, 29 Apr 2002 21:15:19 -0500 (CDT) Received: from dperkins-nb2.dsperkins.com by riverstonenet.com (8.9.3+Sun/SMI-SVR4-Yago) id TAA10281; Mon, 29 Apr 2002 19:15:18 -0700 (PDT) Message-Id: <5.1.0.14.2.20020429190217.03782370@mail4.bayarea.net> X-Sender: dperkins@mail4.bayarea.net X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 29 Apr 2002 19:12:23 -0700 To: disman@dorothy.bmc.com From: "David T. Perkins" Subject: Re: Alarm MIB security issues In-Reply-To: <200204292309.QAA25592@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 HI, Maybe an often repeated phrase is appropriate here... Those that do not study history repeat the same mistakes. Now whether or not what was done in the MIBs that you specified were or were not appropriate is something for someone else to review. However, in my review of the LOG MIB (RFC 3014), the capture and use of "hidden" credentials creates more problems than it solves. Lets fix the LOG MIB, and use that experience to do a better job of future MIBs (like the ALARM MIB) instead of reusing patterns that have problems. The configuration save/restore and auditing is one problem, but the model that one has to use the same security name, security model, and security level in creating the "control table entries" that you want for the "data table entries" is just silly. At 04:09 PM 4/29/2002 -0700, Randy Presuhn wrote: >Hi - > >> Message-Id: <5.1.0.14.2.20020428213841.02828ec0@mail4.bayarea.net> >> Date: Sun, 28 Apr 2002 21:57:36 -0700 >> To: Randy Presuhn , disman@dorothy.bmc.com >> From: "David T. Perkins" >> Subject: Re: Alarm MIB security issues >> In-Reply-To: <200204252330.QAA08873@dorothy.bmc.com> >... >> I'm having problems following the below. However, it appears that it >> is reusing a "BROKEN" design pattern found in RFC 3014. I HOPE THAT >> THIS BROKEN DESIGN PATTERN IS NOT USED IN OTHER MIB MODULES. >> This is marked below.. >> >> At 04:30 PM 4/25/2002 -0700, Randy Presuhn wrote: >... >> VVVVVVVV >> > When an application creates an alarm model (indexed in part by the >> > alarm list name) the security credentials of the creator remain >> > associated with that alarm model and constrain what information is >> > allowed to be placed in the active alarm table, the active alarm >> > variable table, the cleared alarm table, and the ITU alarm table. >> > When processing locally-generated Notifications, the managed >> > system MUST use the security credentials associated with >> > that each alarm model respectively, and MUST apply the >> > same access control rules as described for a Notification >> > Originator in [RFC2573]. >> >> ^^^^^^^^ >> This is just totally broken. Why? Because the information is "hidden". >> A manager cannot look at the created rows and figure out the what >> is the behavior without knowing the hidden values. Also, if one wanted >> to "save the configuration" and then "restore it", it would be impossible. > >Writing as WG chair... > >Like it or not, there are already several standards-track RFCs >with similar properties, e.g.: > RFC 2982, Expression MIB > RFC 2981, Event MIB > RFC 3014, Log MIB, > RFC 3165, Script MIB > RFC 3231, Schedule MIB > >Several years ago, we had lengthy discussions in disman WG >meetings regarding the pros and cons of "explicit delegation" >rather than the path that we've taken. Though I personally >believed (and still believe) explicit delegation to be both >more powerful and ultimately easier to understand, the working >group did not, and the consistent direction in the current >RFCs and I-Ds reflects that rough consensus. > >Though I might personally very much like to see things working >on a foundation of explicit delegation rather than the current >implicit model, I don't see anything approaching a concensus >to make such a potentially disruptive change, and nothing >from implementation experience to date to suggest that what >we currently have is unworkable. > >As a technical contributor, I'd like to remind you that several >objects in RFC 2574 have the same "bug"/"feature" regarding the >ability to use SNMP to extract a system's configuration. > >> Also, say that you used SNMPv3 with USM and auth/priv to create the >> row. This one mean that only notifications that were allowed to be >> sent with auth/priv could result in additions to the active table. >> This is just not correct. >... > >As a technical contributor, I believe this is perfectly reasonable. >No sane security administrator would circumscribe the auth/priv >views more narrowly than noauth/nopriv. > >More importantly, notifications which are only allowed on the >wire in auth/priv form should not go into "public" active alarm >tables. > > ------------------------------------------------------ > Randy Presuhn BMC Software, Inc. 1-3141 Regards, /david t. perkins From owner-disman@dorothy.bmc.com Tue Apr 30 13:22:23 2002 Received: from babbler.bmc.com (firebird.bmc.com [198.207.223.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29626 for ; Tue, 30 Apr 2002 13:22:22 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g3UHOiR19501; Tue, 30 Apr 2002 12:24:47 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id KAA16166 for disman-list; Tue, 30 Apr 2002 10:18:05 -0700 (PDT) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id KAA16160 for disman@dorothy.bmc.com; Tue, 30 Apr 2002 10:18:01 -0700 (PDT) Date: Tue, 30 Apr 2002 10:18:01 -0700 (PDT) From: Randy Presuhn Message-Id: <200204301718.KAA16160@dorothy.bmc.com> To: disman@dorothy.bmc.com Subject: Re: 2574 OBJECTS (was Alarm MIB security 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 - > Message-Id: <5.1.0.14.2.20020429185746.0378a070@mail4.bayarea.net> > Date: Mon, 29 Apr 2002 19:01:22 -0700 > To: disman@dorothy.bmc.com > From: "David T. Perkins" > Subject: Re: 2574 OBJECTS (was Alarm MIB security issues) > In-Reply-To: <200204292309.QAA25592@dorothy.bmc.com> ... > >As a technical contributor, I'd like to remind you that several > >objects in RFC 2574 have the same "bug"/"feature" regarding the > >ability to use SNMP to extract a system's configuration. > > Other than the keys, what objects have the attribute that you can > not retrieve values set via SNMP so that you can restore the > configuration via SNMP? ... I was referring to the keys, obviously. They're a critical part of a system's configuration. If you don't know what they are, you can't do much at all. By design. That's why I'm skeptical about any sort of "requirement" to make all the bits needed to support explicit (or even implicit) delegation recoverable via the MIB. A sane security administrator would probably chose to use group or user names to index these MIBs, making the administrative issues of managing access trivial: only the members of an authorized group would be able to access the tables, and in VACM, all members of a group have identical access rights by definition. ------------------------------------------------------ Randy Presuhn BMC Software, Inc. 1-3141 randy_presuhn@bmc.com 2141 North First Street Tel: +1 408 546-1006 San José, California 95131 USA ------------------------------------------------------ My opinions and BMC's are independent variables. ------------------------------------------------------ From owner-disman@dorothy.bmc.com Tue Apr 30 14:26:45 2002 Received: from babbler.bmc.com (firebird.bmc.com [198.207.223.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02767 for ; Tue, 30 Apr 2002 14:26:45 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g3UITQh05619; Tue, 30 Apr 2002 13:29:26 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id LAA16370 for disman-list; Tue, 30 Apr 2002 11:22:55 -0700 (PDT) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id LAA16364 for disman@dorothy.bmc.com; Tue, 30 Apr 2002 11:22:52 -0700 (PDT) Date: Tue, 30 Apr 2002 11:22:52 -0700 (PDT) From: Randy Presuhn Message-Id: <200204301822.LAA16364@dorothy.bmc.com> To: disman@dorothy.bmc.com Subject: Re: Alarm MIB security 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 - > Message-Id: <5.1.0.14.2.20020429190217.03782370@mail4.bayarea.net> > Date: Mon, 29 Apr 2002 19:12:23 -0700 > To: disman@dorothy.bmc.com > From: "David T. Perkins" > Subject: Re: Alarm MIB security issues > In-Reply-To: <200204292309.QAA25592@dorothy.bmc.com> ... > However, in my review of the LOG MIB (RFC 3014), > the capture and use of "hidden" credentials creates > more problems than it solves. And the problems are? 1) ability of a third party to save and restore a configuration (is there any agreement that this is a requirement?) 2) ? > Lets fix the LOG MIB, and use that experience to > do a better job of future MIBs (like the ALARM MIB) > instead of reusing patterns that have problems. The WG chair has been requesting feedback on the log MIB for well over a year. This is the first time that anyone has claimed that the credential mechanism posed any sort of a problem, so far as I know. There are *no* counter- proposals on the table. Your complaints might be taken more seriously if accompanied with a credible solution. > The configuration save/restore and auditing is one problem, > but the model that one has to use the same security name, > security model, and security level in creating the > "control table entries" that you want for the > "data table entries" is just silly. ... Thank you for the precise characterization of your viewpoint. Do you think you could make a constructive proposal? What should we do to prevent active alarms and logs from giving inappropriate access to information, if not the common approach taken by this WG in its other products? ------------------------------------------------------ Randy Presuhn BMC Software, Inc. 1-3141 randy_presuhn@bmc.com 2141 North First Street Tel: +1 408 546-1006 San José, California 95131 USA ------------------------------------------------------ My opinions and BMC's are independent variables. ------------------------------------------------------ From owner-disman@dorothy.bmc.com Tue Apr 30 14:45:02 2002 Received: from babbler.bmc.com (camaro.bmc.com [198.207.223.231]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03864 for ; Tue, 30 Apr 2002 14:45:02 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g3UIlkX08630; Tue, 30 Apr 2002 13:47:46 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id LAA16491 for disman-list; Tue, 30 Apr 2002 11:42:09 -0700 (PDT) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id LAA16485; Tue, 30 Apr 2002 11:42:06 -0700 (PDT) Date: Tue, 30 Apr 2002 11:42:06 -0700 (PDT) From: Randy Presuhn Message-Id: <200204301842.LAA16485@dorothy.bmc.com> To: disman@dorothy.bmc.com Subject: Re: Communication from ITU-T Study Group 4 Cc: djsidor@nortelnetworks.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 - > Date: Mon, 29 Apr 2002 18:22:50 -0700 (PDT) > From: Randy Presuhn > Message-Id: <200204300122.SAA14425@dorothy.bmc.com> > To: disman@dorothy.bmc.com > Subject: Communication from ITU-T Study Group 4 > Cc: djsidor@nortelnetworks.com ... > ftp://amethyst.bmc.com/pub/disman/itu/2002-04-29_sg4_liaison.doc ... Dave Sidor alerted me that this is actually a draft of the text document distributed earlier, so I have deleted this draft to avoid confusion. ------------------------------------------------------ Randy Presuhn BMC Software, Inc. 1-3141 randy_presuhn@bmc.com 2141 North First Street Tel: +1 408 546-1006 San José, California 95131 USA ------------------------------------------------------ My opinions and BMC's are independent variables. ------------------------------------------------------ From owner-disman@dorothy.bmc.com Tue Apr 30 15:41:13 2002 Received: from babbler.bmc.com (camaro.bmc.com [198.207.223.231]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06156 for ; Tue, 30 Apr 2002 15:41:13 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g3UJhm919071; Tue, 30 Apr 2002 14:43:48 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id MAA16646 for disman-list; Tue, 30 Apr 2002 12:37:47 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id MAA16641 for ; Tue, 30 Apr 2002 12:37:43 -0700 (PDT) Received: from mx-us-hou-2-int.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id g3UJZQK06630 for ; Tue, 30 Apr 2002 14:35:26 -0500 (CDT) Received: from riverstonenet.com (mail.riverstonenet.com [63.113.148.10]) by mx-us-hou-2-int.bmc.com (Postfix) with SMTP id 207591FF26E for ; Tue, 30 Apr 2002 14:39:17 -0500 (CDT) Received: from dperkins-nb2.dsperkins.com by riverstonenet.com (8.9.3+Sun/SMI-SVR4-Yago) id MAA11886; Tue, 30 Apr 2002 12:39:05 -0700 (PDT) Message-Id: <5.1.0.14.2.20020430114656.02e55060@mail4.bayarea.net> X-Sender: dperkins@mail4.bayarea.net X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 30 Apr 2002 12:38:39 -0700 To: disman@dorothy.bmc.com From: "David T. Perkins" Subject: Re: Alarm MIB security issues In-Reply-To: <200204301822.LAA16364@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 HI, Randy - I think you have forgotten about the work that Steve Moulton and I have done. Steve has been unavailable to review the last update, and, thus, I have not sent it to the list. However, I have sent it to RamK, but have not yet gotten any feed back from him. First, lets review the security issues, which are: 1) one wants only notifications in the named logs that were sent to a specific management target. Those notifications must "pass" the ACL check as described in RFC 2573 for notification distribution. 2) one wants a named log to be viewed only by the managers that have the appropriate credentials as specified by the VACM configuration for the named log. Moving on, to answer your question about the problems of the RFC 3014 due to the hidden credentials, these include: 1) cannot do a config save/restore 2) cannot do security audit (since you cannot see the "hidden credentials", you cannot determine if the control entries match your security policy) 3) currently, the credentials used for the activation of a control table entry are used for the credentials used for determining whether or not to add a notification to the log. However, these are separate operations. The current approach forces them to be the same. Note, there are other problems with RFC 3014, including: 1) confusion about engineIDs in the definition 2) no clean separation between usage in a "managed system" and a "mid-level manager" 3) efficiency of usage (that is, determining if new notifications have been added to a log, and then retrieving them) 4) confusion as to where in the notification distribution system as described in RFC 2573 where the "flow of notifications" is "tapped" (note, the tap point appears different for the null named log than for the named logs) and I've probably forgotten a few.... As to implementation, I'm presently working with the developers at cisco (who support only a "null named log") and the developers at RiverStone (who support for both the "null named log" and "named logs") to create some tests that are easy to configure and run to determine if the behaviors of each implementation are identical. Also, I'm trying to determine if the behaviors are useful by talking with application developers. Note, that if there are other implementations of RFC 3014 or suggestions for tests, please contact me. Also, if anyone is writing a management application to use RFC 3014, please contact me. (Of course, Randy would like implementation reports on the mailing list if this is possible.) So Randy - there is much work that has taken place. It's not on the list, because its not at that point yet. At 11:22 AM 4/30/2002 -0700, Randy Presuhn wrote: >Hi - > >> Message-Id: <5.1.0.14.2.20020429190217.03782370@mail4.bayarea.net> >> Date: Mon, 29 Apr 2002 19:12:23 -0700 >> To: disman@dorothy.bmc.com >> From: "David T. Perkins" >> Subject: Re: Alarm MIB security issues >> In-Reply-To: <200204292309.QAA25592@dorothy.bmc.com> >... >> However, in my review of the LOG MIB (RFC 3014), >> the capture and use of "hidden" credentials creates >> more problems than it solves. > >And the problems are? > 1) ability of a third party to save and restore > a configuration (is there any agreement that > this is a requirement?) > 2) ? > >> Lets fix the LOG MIB, and use that experience to >> do a better job of future MIBs (like the ALARM MIB) >> instead of reusing patterns that have problems. > >The WG chair has been requesting feedback on the log MIB >for well over a year. This is the first time that anyone >has claimed that the credential mechanism posed any sort >of a problem, so far as I know. There are *no* counter- >proposals on the table. Your complaints might be taken >more seriously if accompanied with a credible solution. > >> The configuration save/restore and auditing is one problem, >> but the model that one has to use the same security name, >> security model, and security level in creating the >> "control table entries" that you want for the >> "data table entries" is just silly. >... Maybe I deserved the following sarcasm for calling the current mechanism "just silly". If personal attacks on me are what it takes to solve the problem, then fine. However, I believe the below is more words of frustration than a personal attack. >Thank you for the precise characterization of your viewpoint. >Do you think you could make a constructive proposal? >What should we do to prevent active alarms and logs from >giving inappropriate access to information, if not the >common approach taken by this WG in its other products? > > Randy Presuhn BMC Software, Inc. 1-3141 Regards, /david t. perkins From owner-disman@dorothy.bmc.com Tue Apr 30 17:46:52 2002 Received: from babbler.bmc.com (camaro.bmc.com [198.207.223.231]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10035 for ; Tue, 30 Apr 2002 17:46:52 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g3ULnYM18946; Tue, 30 Apr 2002 16:49:34 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id OAA17151 for disman-list; Tue, 30 Apr 2002 14:43:36 -0700 (PDT) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id OAA17145 for disman@dorothy.bmc.com; Tue, 30 Apr 2002 14:43:32 -0700 (PDT) Date: Tue, 30 Apr 2002 14:43:32 -0700 (PDT) From: Randy Presuhn Message-Id: <200204302143.OAA17145@dorothy.bmc.com> To: disman@dorothy.bmc.com Subject: Re: Alarm MIB security 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 - > Message-Id: <5.1.0.14.2.20020430114656.02e55060@mail4.bayarea.net> > Date: Tue, 30 Apr 2002 12:38:39 -0700 > To: disman@dorothy.bmc.com > From: "David T. Perkins" > Subject: Re: Alarm MIB security issues > In-Reply-To: <200204301822.LAA16364@dorothy.bmc.com> > List-Id: IETF disman Working Group mailing list > > HI, > > Randy - I think you have forgotten about the work that Steve Moulton > and I have done. Steve has been unavailable to review the last > update, and, thus, I have not sent it to the list. However, I have > sent it to RamK, but have not yet gotten any feed back from him. ... WG chair says: If you can't disclose this work on an open IETF mailing list, then it's irrelevant for our purposes. As I've told you before, I am not going to even look at such proposals until they can be discussed publicly. If you have something that can be discussed in an open forum, fine, but until then, I'm tired of the histrionics. ------------------------------------------------------ Randy Presuhn BMC Software, Inc. 1-3141 randy_presuhn@bmc.com 2141 North First Street Tel: +1 408 546-1006 San José, California 95131 USA ------------------------------------------------------ My opinions and BMC's are independent variables. ------------------------------------------------------