From owner-disman@dorothy.bmc.com Fri Feb 1 15:15: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 PAA10956 for ; Fri, 1 Feb 2002 15:15:46 -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 g11KHvY23956; Fri, 1 Feb 2002 14:17:57 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id MAA11716 for disman-list; Fri, 1 Feb 2002 12:11:14 -0800 (PST) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id MAA11710 for disman@dorothy.bmc.com; Fri, 1 Feb 2002 12:11:10 -0800 (PST) Date: Fri, 1 Feb 2002 12:11:10 -0800 (PST) From: Randy Presuhn Message-Id: <200202012011.MAA11710@dorothy.bmc.com> To: disman@dorothy.bmc.com Subject: Disman I-D cutoff dates 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 - Note well the cutoff dates below. If you want to make a draft-ietf-disman-*-00.txt submission, you must let me (disman WG chair) know before February 7. I will be away from email from then until February 26 or so. (Lunar New Year is approaching; time to visit the inlaws.) ------------------------------------------------------ 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. ------------------------------------------------------ > Message-Id: <200202011646.LAA02775@ietf.org> > To: IETF-Announce: ; > From: Internet-Drafts Administrator > Subject: Internet-Draft Cutoff Dates for Minneapolis, MN > Date: Fri, 01 Feb 2002 11:46:42 -0500 > > > NOTE: There are two (2) Internet-Draft Cutoff dates > > February 22nd: Cutoff for Initial Submissions (new documents) > > All initial submissions(-00) must be submitted by Friday, > February 22nd, 17:00 US-EST. Initial submissions received after this time > will NOT be made available in the Internet-Drafts directory, and will have > to be resubmitted. > > As before, all initial submissions (-00.txt) with a filename beginning > with a draft-ietf MUST be approved by the appropriate WG Chair prior to > processing and announcing. WG Chair approval must be received by > Monday, February 25th. > > Please do NOT wait until the last minute to submit. > > Be advised: NO placeholders. Updates to initial submissions received > the week of February 22nd will NOT be accepted. > > March 1st: FINAL Internet-Draft Cutoff > > All revised Internet-Draft submissions must be submitted by Friday, > March 1st, 2002 at 17:00 US-EST. Internet-Drafts received after this time > will NOT be announced NOR made available in the Internet-Drafts > Directories. > > We will begin accepting Internet-Draft submissions the week of the > meeting, though announcements will NOT be sent until the IETF meeting > is over. > > Thank you for your understanding and cooperation. Please do not hesitate > to contact us if you have any questions or concenrs. > > FYI: These and other significant dates can be found at > http://www.ietf.org/meetings/cutoff_dates_53.html > > From owner-disman@dorothy.bmc.com Mon Feb 4 07:43:28 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 HAA20488 for ; Mon, 4 Feb 2002 07:43:27 -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 g14CjiA17289; Mon, 4 Feb 2002 06:45:44 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id EAA10673 for disman-list; Mon, 4 Feb 2002 04:38:20 -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 EAA10668 for ; Mon, 4 Feb 2002 04:38:15 -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 g14Cagl25144 for ; Mon, 4 Feb 2002 06:36:42 -0600 (CST) Received: from zcars0m9.ca.nortel.com (unknown [47.129.242.157]) by mx-us-hou-1-int.bmc.com (Postfix) with SMTP id 6977C20F045 for ; Mon, 4 Feb 2002 06:39:34 -0600 (CST) Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57]) by zcars0m9.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g14CdKH22818; Mon, 4 Feb 2002 07:39:21 -0500 (EST) 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 g14CdI320810; Mon, 4 Feb 2002 07:39:19 -0500 (EST) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 4 Feb 2002 07:39:21 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD3401A812CD@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: disman@dorothy.bmc.com Cc: Juergen Schoenwaelder Subject: RE: resend Re: alarmModelEntry notInService (Alarm Issue #15) Date: Mon, 4 Feb 2002 07:39:24 -0500 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 Would that be resourceUnavailable? Sharon -----Original Message----- From: Juergen Schoenwaelder [mailto:schoenw@ibr.cs.tu-bs.de] Sent: Wednesday, January 30, 2002 8:56 AM To: Chisholm, Sharon [CAR:NM50:EXCH] Cc: disman@dorothy.bmc.com Subject: Re: resend Re: alarmModelEntry notInService (Alarm Issue #15) >>>>> Sharon Chisholm writes: Sharon> This row can not be modified or deleted while it is being Sharon> referenced by a value of alarmActiveModelPointer." It might be service for implementors and improve interoperability to say precisely which of the RFC 1905 error codes applies in this case. /js From owner-disman@dorothy.bmc.com Mon Feb 4 08:12: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 IAA21146 for ; Mon, 4 Feb 2002 08:12:44 -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 g14DFB523857; Mon, 4 Feb 2002 07:15:11 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id FAA10759 for disman-list; Mon, 4 Feb 2002 05:10:23 -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 FAA10754 for ; Mon, 4 Feb 2002 05:10:18 -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 g14D8lg03232 for ; Mon, 4 Feb 2002 07:08:47 -0600 (CST) Received: from zcars0m9.ca.nortel.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by mx-us-hou-2-int.bmc.com (Postfix) with SMTP id 4AC0E1FF046 for ; Mon, 4 Feb 2002 07:11:44 -0600 (CST) Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57]) by zcars0m9.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g14DBRH24250 for ; Mon, 4 Feb 2002 08:11:27 -0500 (EST) 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 g14DBP321588 for ; Mon, 4 Feb 2002 08:11:26 -0500 (EST) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 4 Feb 2002 08:11:28 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD3401A81314@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: disman@dorothy.bmc.com Subject: Updated Alarm MIB Issues 9-20 Date: Mon, 4 Feb 2002 08:11:31 -0500 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 Newly Closed ------------- Alarm#14 alarmRaise notification inconsistent with terminology Changed the alarmRaise notification to be alarmSet to be consistent with the terminology as defined. > Alarm#13 DMTF input into probable cause > We have some input from DMTF as to potential additional probable > cause values. When these are available, the initial set of > probable causes can be updated. If we receive this input, we can include it. Otherwise, these additional causes can be added using IANA. Alarm#15 RowStatus and Not in service Added the following text to the RowStatus Description ... Alarms whose alarmModelRowStatus is not active will not appear in either the alarmActiveTable or the alarmClearTable. Setting this object to notInService cannot be used as an alarm suppression mechanism. Entries that are notInService will disappear as described in RFC2579 This row can not be modified or deleted while it is being referenced by a value of alarmActiveModelPointer. In these cases, an error of resourceUnavailable will be returned to the manager. Alarm#16 Access rights to table varbinds David> * Change indices to not-accessible or accessible-for-notify as David> appropriate. This necessitates small changes in object David> groups, as well. Alarm#17 MODULE-IDENTITY Added MODULE-IDENTITY macros to both textual conventions Alarm#19 alarmModelVarbindIndex Dave> * Need clarification on how alarmModelVarbindIndex works This is the issue of SNMPv1 traps versus SNMPv2 traps. I've added some clarifying text. Open Issues ---------- > Alarm#9 Example showing relation to Condition and Arc MIB > Currently missing from -04 > > Alarm#11 Resource Identification > The resource identification method in -04 uses a type and > integer value pair to identify a resource. There has > been some support for using an OID instead. There are > pros and cons to each approach. I'd also add the discussion of a per instance displayString here as well. A display string in the active alarm table serves simple managers well, although it's a nightmare for anyone trying to do anything other than display the object. It might make sense to include both it and an object that can be used by more complicated managers to do more interesting things with. I'm still not a fan of the OID approach, but it seems to have a lot of support. We may be able to produce something with a lot of MUSTs in that might address my concerns Alarm#18 David> * How can alarmActiveTable and alarmClearTable share an index David> from alarmActiveTable given that when an alarm is cleared it David> is moved to alarmClearTable and the corresponding entry in David> alarmActiveTable is removed? Well, I guess the alarmActiveIndex does not exist when it is being used in the clear table. I've seen this sort of thing done before, but strictly speaking, should alarmActiveIndex be instantiated to reuse it? If this is the case, then I would suggest creating a duplicate object that shares the same value. Alarm#20 OID Aesthetics Dave> * Small change: move alarmNotifications from { alarmMIB 2 } to Dave> { alarmMIB 0 } do you don't have to have { alarmNotifications 0 1 } Dave> but can instead just have { alarmNotifications 1 }. Dave> I realize this is cosmetic. Sharon From owner-disman@dorothy.bmc.com Mon Feb 4 11:18: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 LAA27387 for ; Mon, 4 Feb 2002 11:18:17 -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 g14GKgA26804; Mon, 4 Feb 2002 10:20:42 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id IAA11200 for disman-list; Mon, 4 Feb 2002 08:15:23 -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 IAA11195 for ; Mon, 4 Feb 2002 08:15:20 -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 g14GDjf00293 for ; Mon, 4 Feb 2002 10:13:45 -0600 (CST) 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 8862F1FF180 for ; Mon, 4 Feb 2002 10:16:40 -0600 (CST) 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 g14GFccl018877; Mon, 4 Feb 2002 17:15:41 +0100 Received: (from schoenw@localhost) by haerke.ibr.cs.tu-bs.de (8.11.6/8.11.6) id g14GFch08360; Mon, 4 Feb 2002 17:15:38 +0100 Date: Mon, 4 Feb 2002 17:15:38 +0100 Message-Id: <200202041615.g14GFch08360@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: <3549C09B853DD5119B540002A52CDD3401A812CD@zcard0ka.ca.nortel.com> (schishol@nortelnetworks.com) Subject: Re: resend Re: alarmModelEntry notInService (Alarm Issue #15) References: <3549C09B853DD5119B540002A52CDD3401A812CD@zcard0ka.ca.nortel.com> Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list >>>>> Sharon Chisholm writes: Sharon> Would that be resourceUnavailable? I would probably have chosen `inconsistentValue' - not sure we really face a resource allocation problem here. But one can certainly argue this way. I don't care much what the final right answer is as long as the document says which one to send/expect in this case. /js -- Juergen Schoenwaelder University of Osnabrueck Dept. of Mathematics and Computer Science Phone: +49 541 969 2483 Albrechtstr. 28, 49069 Osnabrueck, Germany Fax: +49 541 969 2770 From owner-disman@dorothy.bmc.com Tue Feb 5 15:04: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 PAA17040 for ; Tue, 5 Feb 2002 15:04:53 -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 g15K77h15405; Tue, 5 Feb 2002 14:07:07 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id MAA28142 for disman-list; Tue, 5 Feb 2002 12:00:59 -0800 (PST) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id MAA28136 for disman@dorothy.bmc.com; Tue, 5 Feb 2002 12:00:56 -0800 (PST) Date: Tue, 5 Feb 2002 12:00:56 -0800 (PST) From: Randy Presuhn Message-Id: <200202052000.MAA28136@dorothy.bmc.com> To: disman@dorothy.bmc.com Subject: Will disman need to meet in MSP? 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 - We were supposed to be finished by now, but the alarm stuff is still under discussion on the mailing list. I intend to start WG last call on the active alarms document when the next i-d is announced. Will it be necessary to reserve a meeting slot in Minneapolis? I need to know BY THURSDAY of this week. I'm about to disappear until the last week of February, and the deadline for meeting slot requests is February 22. My working assumption is that we will *not* have a session in Minneapolis. ------------------------------------------------------ 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 Feb 5 16:26: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 QAA19974 for ; Tue, 5 Feb 2002 16:26:41 -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 g15LT5R03154; Tue, 5 Feb 2002 15:29:05 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id NAA28422 for disman-list; Tue, 5 Feb 2002 13:23:57 -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 NAA28415 for ; Tue, 5 Feb 2002 13:23:52 -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 g15LMJ518354 for ; Tue, 5 Feb 2002 15:22:20 -0600 (CST) Received: from auemail2.firewall.lucent.com (unknown [192.11.223.163]) by mx-us-hou-1-int.bmc.com (Postfix) with SMTP id B5FEC20EF87 for ; Tue, 5 Feb 2002 15:25:09 -0600 (CST) Received: from nj7460exch001h.wins.lucent.com (h135-17-42-36.lucent.com [135.17.42.36]) by auemail2.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g15LP3203261 for ; Tue, 5 Feb 2002 16:25:03 -0500 (EST) Received: by nj7460exch001h.ho.lucent.com with Internet Mail Service (5.5.2650.21) id ; Tue, 5 Feb 2002 16:25:02 -0500 Message-ID: <2E12619580C0D1118C6400805F9F4C950D7CEE29@nj7460exch001u.ho.lucent.com> From: "Lam, Hing-Kam (Kam)" To: "'disman@dorothy.bmc.com'" Cc: "'Sharon Chisholm'" , "'Dan Romascanu'" , "'David Perkins'" , "Huynh, An-Ni (An-Ni)" Subject: RE: Progressing the Condition/ARC MIB Date: Tue, 5 Feb 2002 16:25:00 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list Dear All, Up to now, I didn't hear any opinion to the proposal I have made. May I interpret this as no objection. If so, then the remain issue is the relationship of the Condition MIB to the Alarm MIB. Any input? Regards, Kam > -----Original Message----- > From: Lam, Hing-Kam (Kam) [mailto:hklam@lucent.com] > Sent: Thursday, January 10, 2002 4:47 PM > To: 'disman@dorothy.bmc.com' > Subject: Progressing the Condition/ARC MIB > > > In the Salt Lake City meeting, the Condition/ARC MIB > http://www.ietf.org/internet-drafts/draft-ietf-disman-conditio > nmib-01.txt > was discussed and some open issues were noted (see the meeting details > posted by Randy on December 18). > > To progress the Condition/ARC MIB, I have extrated those open > issues to here > to solicite your input. The issues are mainly related to the > terminology, > definition, and relationship with the Alarm MIB (Sections 3, > 4 and 5 of the > document). > Attached is the modified Sections 3, 4, & 5 for your comments. > > > 4. Condition MIB and ARC MIB > > - changes from version 00 to version 01 > > - open issues > > - terminology - condition to be taken on the mailing list - Kam to > > initiate the thread > > One of the comments on the document is that it should point > to the alarm MIB > for the definitions. Agree. Once the definitions (Error, > Fault, Alarm, Alarm > Raised, Alarm Cleared, Event, and Notification) are removed, > the only term > left is Condition. So I think the current Section 3.1 > "Terminology" can be > deleted and embed the definition of Condition in the first > couple paragraphs > at the beginning of Section 3 as follow. > > The Condition MIB module defines MIB objects and > notifications that > provide mechanism to monitor abnormal conditions currently active > and the history of abnormal conditions being set and cleared on a > managed system. > > The list of abnormal conditions that can be monitored by > using this > MIB are based on the Probable Causes defined in ITU-T > Recommendations > M.3100, X.733, and X.736. A textual convention, > IANAItuProbableCause, > has been defined in the Alarm MIB to assign values to the ITU-T > Probable Causes. The IANAItuProbableCause textual > convention is being > used by the Condition MIB to represent the abnormal conditions. > > > - Alarm Raised and Clear - should point to the Alarm MIB > > Agree. See the attached file, Section 3. > > > - Alarm type definition - delete section 3.2 > > Agree. See the attached file, Section 3. > > > - Section 4.1 readability - text needs fixing, diagram > should be taken > > out > > Agree. See the attached file, Section 4.1. The diagram and > associated text > have been deleted. > > > - change 'clarification' in Section 5 that says that when a > resource is > > in ARC mode active alarm information SHALL be available for > retrieval by > > the managing system - change active alarm with condition information > > Agree. See the attached file, Section 5, third paragraph, > last sentence. > > > - section 5.1 - ARC impact on alarm notifications - needs > to be further > > worked on the list. > > The text has been modified to describe the general impact on alarm > notifications according to M.3100 Amendment 3, and not to describe its > impact on specific notifications, such as those in the Alarm MIB and > Condition MIB. See attached file, Section 5.1. > > > - relationship with Alarm MIB - Sharon to propose text on > the mailing > > list > > To be provided. Any input or suggestion on this item. > > Regards, > Kam > <> > > > > > From owner-disman@dorothy.bmc.com Wed Feb 6 09:14: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 JAA20462 for ; Wed, 6 Feb 2002 09:14:43 -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 g16EH2K22177; Wed, 6 Feb 2002 08:17:02 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id GAA12221 for disman-list; Wed, 6 Feb 2002 06:10:54 -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 GAA12216 for ; Wed, 6 Feb 2002 06:10:50 -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 g16E9K211973 for ; Wed, 6 Feb 2002 08:09:20 -0600 (CST) Received: from zcars0m9.ca.nortel.com (unknown [47.129.242.157]) by mx-us-hou-1-int.bmc.com (Postfix) with SMTP id 9B7F420EFBE for ; Wed, 6 Feb 2002 08:12:14 -0600 (CST) Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57]) by zcars0m9.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g16EC7H06369 for ; Wed, 6 Feb 2002 09:12:08 -0500 (EST) 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 g16EC6318839 for ; Wed, 6 Feb 2002 09:12:06 -0500 (EST) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <1J339540>; Wed, 6 Feb 2002 09:12:07 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD3401AEAAA5@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: disman@dorothy.bmc.com Subject: draft-ietf-disman-alarm-mib-05.txt Just Submitted Date: Wed, 6 Feb 2002 09:12:07 -0500 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 We've just sent -05 of the alarm MIB into internet drafts. It should be appearing shortly. Newly Closed Issues ------------------- Alarm #11 Resource Identification In the interest of working group consensus and the fact that we claim to be providing a generic alarm model, we have gone with the OID for the resource identifier. We've hopefully provided enough guidance that it gets used consistently. We also included an alarmActiveDescription to the alarmActiveTable to serve people looking for something displayable without any processing. Alarm #18 Active & Cleared Shared Indices We created an alarmClearIndex that has the same value as the alarmActiveIndex had, but continues to exist after the alarm is no longer active. Alarm #20 OID Aesthetics We made this change to prevent to "0 1" thing appearing in the SMI. Sharon Chisholm Preside Management Nortel Networks Ottawa, Ontario From owner-disman@dorothy.bmc.com Wed Feb 6 09:41: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 JAA21283 for ; Wed, 6 Feb 2002 09:41:42 -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 g16Ei9W26190; Wed, 6 Feb 2002 08:44:09 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id GAA12311 for disman-list; Wed, 6 Feb 2002 06:39:16 -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 GAA12306 for ; Wed, 6 Feb 2002 06:39:12 -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 g16EbgE20731 for ; Wed, 6 Feb 2002 08:37:42 -0600 (CST) Received: from zcars0m9.ca.nortel.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by mx-us-hou-2-int.bmc.com (Postfix) with SMTP id 96BA31FF05B for ; Wed, 6 Feb 2002 08:40:39 -0600 (CST) Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57]) by zcars0m9.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g16EeIH10219; Wed, 6 Feb 2002 09:40:18 -0500 (EST) 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 g16EeG320837; Wed, 6 Feb 2002 09:40:17 -0500 (EST) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <1J3396VT>; Wed, 6 Feb 2002 09:40:17 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD3401AEAB6F@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: "'disman@dorothy.bmc.com'" , "Lam, Hing-Kam (Kam)" Cc: "'Dan Romascanu'" , "'David Perkins'" , "Huynh, An-Ni (An-Ni)" Subject: RE: Progressing the Condition/ARC MIB Date: Wed, 6 Feb 2002 09:40:17 -0500 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 had a few discussions with people in Salt Late City about one possible way to move forward with all this. There appeared to be some interest in this approach. I proposed that the Condition/ARC draft only stores suppressed conditions. It seems to me that this simplifies the overall architecture and eliminates a lot of the confusion. You could even start calling suppressed conditions suppressed alarms without causing too much confusion. The condition/ARC draft would then consist of - Alarm Suppression via ARC - Suppressed Alarms This could either be done tightly coupled with the alarm MIB, using its ResourceId and alarmModelTable, or more independently if it better supports what's defined in ITU's ARC. Would this work for those people interested in conditions and ARC? What about those not interested in conditions and ARC, but interested in reducing the confusion level around this and the Alarm MIB? Sharon -----Original Message----- From: Lam, Hing-Kam (Kam) [mailto:hklam@lucent.com] Sent: Tuesday, February 05, 2002 4:25 PM To: 'disman@dorothy.bmc.com' Cc: Chisholm, Sharon [CAR:NM50:EXCH]; 'Dan Romascanu'; 'David Perkins'; Huynh, An-Ni (An-Ni) Subject: RE: Progressing the Condition/ARC MIB Dear All, Up to now, I didn't hear any opinion to the proposal I have made. May I interpret this as no objection. If so, then the remain issue is the relationship of the Condition MIB to the Alarm MIB. Any input? Regards, Kam > -----Original Message----- > From: Lam, Hing-Kam (Kam) [mailto:hklam@lucent.com] > Sent: Thursday, January 10, 2002 4:47 PM > To: 'disman@dorothy.bmc.com' > Subject: Progressing the Condition/ARC MIB > > > In the Salt Lake City meeting, the Condition/ARC MIB > http://www.ietf.org/internet-drafts/draft-ietf-disman-conditio > nmib-01.txt > was discussed and some open issues were noted (see the meeting details > posted by Randy on December 18). > > To progress the Condition/ARC MIB, I have extrated those open > issues to here > to solicite your input. The issues are mainly related to the > terminology, > definition, and relationship with the Alarm MIB (Sections 3, > 4 and 5 of the > document). > Attached is the modified Sections 3, 4, & 5 for your comments. > > > 4. Condition MIB and ARC MIB > > - changes from version 00 to version 01 > > - open issues > > - terminology - condition to be taken on the mailing list - Kam to > > initiate the thread > > One of the comments on the document is that it should point > to the alarm MIB > for the definitions. Agree. Once the definitions (Error, > Fault, Alarm, Alarm > Raised, Alarm Cleared, Event, and Notification) are removed, > the only term > left is Condition. So I think the current Section 3.1 > "Terminology" can be > deleted and embed the definition of Condition in the first > couple paragraphs > at the beginning of Section 3 as follow. > > The Condition MIB module defines MIB objects and > notifications that > provide mechanism to monitor abnormal conditions currently active > and the history of abnormal conditions being set and cleared on a > managed system. > > The list of abnormal conditions that can be monitored by > using this > MIB are based on the Probable Causes defined in ITU-T > Recommendations > M.3100, X.733, and X.736. A textual convention, > IANAItuProbableCause, > has been defined in the Alarm MIB to assign values to the ITU-T > Probable Causes. The IANAItuProbableCause textual > convention is being > used by the Condition MIB to represent the abnormal conditions. > > > - Alarm Raised and Clear - should point to the Alarm MIB > > Agree. See the attached file, Section 3. > > > - Alarm type definition - delete section 3.2 > > Agree. See the attached file, Section 3. > > > - Section 4.1 readability - text needs fixing, diagram > should be taken > > out > > Agree. See the attached file, Section 4.1. The diagram and > associated text > have been deleted. > > > - change 'clarification' in Section 5 that says that when a > resource is > > in ARC mode active alarm information SHALL be available for > retrieval by > > the managing system - change active alarm with condition information > > Agree. See the attached file, Section 5, third paragraph, > last sentence. > > > - section 5.1 - ARC impact on alarm notifications - needs > to be further > > worked on the list. > > The text has been modified to describe the general impact on alarm > notifications according to M.3100 Amendment 3, and not to describe its > impact on specific notifications, such as those in the Alarm MIB and > Condition MIB. See attached file, Section 5.1. > > > - relationship with Alarm MIB - Sharon to propose text on > the mailing > > list > > To be provided. Any input or suggestion on this item. > > Regards, > Kam > <> > > > > > From owner-disman@dorothy.bmc.com Wed Feb 6 15:45: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 PAA01421 for ; Wed, 6 Feb 2002 15:45:05 -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 g16Kkue29593; Wed, 6 Feb 2002 14:46:56 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id MAA13689 for disman-list; Wed, 6 Feb 2002 12:41: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 MAA13684 for ; Wed, 6 Feb 2002 12:41:07 -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 g16Kdbu01201 for ; Wed, 6 Feb 2002 14:39:37 -0600 (CST) Received: from hoemail1.firewall.lucent.com (hoemail1.lucent.com [192.11.226.161]) by mx-us-hou-2-int.bmc.com (Postfix) with SMTP id A4B8A1FF008 for ; Wed, 6 Feb 2002 14:42:30 -0600 (CST) Received: from nj7460exch001h.wins.lucent.com (h135-17-42-36.lucent.com [135.17.42.36]) by hoemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g16KgD118683 for ; Wed, 6 Feb 2002 15:42:13 -0500 (EST) Received: by nj7460exch001h.ho.lucent.com with Internet Mail Service (5.5.2650.21) id ; Wed, 6 Feb 2002 15:42:13 -0500 Message-ID: <2E12619580C0D1118C6400805F9F4C950D7CEE39@nj7460exch001u.ho.lucent.com> From: "Lam, Hing-Kam (Kam)" To: "'Sharon Chisholm'" , "'disman@dorothy.bmc.com'" , "Lam, Hing-Kam (Kam)" , "'AToM Working Group'" Cc: "'Dan Romascanu'" , "'David Perkins'" , "Huynh, An-Ni (An-Ni)" Subject: RE: Progressing the Condition/ARC MIB Date: Wed, 6 Feb 2002 15:42:09 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list I support Sharon's proposal. This will work for the Optical Interface MIB in AToMMIB WG. Originanlly, the ARC mib was started with the Optical Interface MIB in the AToMMIB WG. It was transferred to the Disman WG because of the generic nature of the ARC function (as defined in ITU-T). So, the draft would consist of one single module. It supports the Alarm Suppression function via the existing objects defined in the ARC module (i.e., the current section 7) plus Suppressed Alarms information via an alarmSuppressedTable. The alarmSuppressedTable would contain information similar to those in the existing condActiveTable. I prefer "suppressed alarms" then "suppressed conditions" as this will be consistent with the terms used in ITU-T. Randy: Couple questions. Need your guidance. (1) If no objection to this approach, can we simply call the document "ARC MIB" (or Alarm Reporting Control MIB), instead of "CONDITION & ARC MIB"? (2) How about the file name of the I-D? draft-ietf-disman-conditionmib-02.txt or draft-ietf-disman-arcmib-02.txt or draft-ietf-disman-arcmib-00.txt ? Regards, Kam > -----Original Message----- > From: Sharon Chisholm [mailto:schishol@nortelnetworks.com] > Sent: Wednesday, February 06, 2002 9:40 AM > To: 'disman@dorothy.bmc.com'; Lam, Hing-Kam (Kam) > Cc: 'Dan Romascanu'; 'David Perkins'; Huynh, An-Ni (An-Ni) > Subject: RE: Progressing the Condition/ARC MIB > > > hi > > I had a few discussions with people in Salt Late City > about one possible way to move forward with all this. > There appeared to be some interest in this approach. > > I proposed that the Condition/ARC draft only stores > suppressed conditions. It seems to me that this simplifies > the overall architecture and eliminates a lot of the > confusion. You could even start calling suppressed > conditions suppressed alarms without causing too much > confusion. > > The condition/ARC draft would then consist of > - Alarm Suppression via ARC > - Suppressed Alarms > > This could either be done tightly coupled with > the alarm MIB, using its ResourceId and alarmModelTable, > or more independently if it better supports what's > defined in ITU's ARC. > > Would this work for those people interested in conditions > and ARC? What about those not interested in conditions > and ARC, but interested in reducing the confusion level > around this and the Alarm MIB? > > Sharon > > -----Original Message----- > From: Lam, Hing-Kam (Kam) [mailto:hklam@lucent.com] > Sent: Tuesday, February 05, 2002 4:25 PM > To: 'disman@dorothy.bmc.com' > Cc: Chisholm, Sharon [CAR:NM50:EXCH]; 'Dan Romascanu'; 'David > Perkins'; > Huynh, An-Ni (An-Ni) > Subject: RE: Progressing the Condition/ARC MIB > > > Dear All, > > Up to now, I didn't hear any opinion to the proposal I have > made. May I > interpret this as no objection. If so, then the remain issue is the > relationship of the Condition MIB to the Alarm MIB. Any input? > > Regards, > Kam > > > -----Original Message----- > > From: Lam, Hing-Kam (Kam) [mailto:hklam@lucent.com] > > Sent: Thursday, January 10, 2002 4:47 PM > > To: 'disman@dorothy.bmc.com' > > Subject: Progressing the Condition/ARC MIB > > > > > > In the Salt Lake City meeting, the Condition/ARC MIB > > http://www.ietf.org/internet-drafts/draft-ietf-disman-conditio > > nmib-01.txt > > was discussed and some open issues were noted (see the > meeting details > > posted by Randy on December 18). > > > > To progress the Condition/ARC MIB, I have extrated those open > > issues to here > > to solicite your input. The issues are mainly related to the > > terminology, > > definition, and relationship with the Alarm MIB (Sections 3, > > 4 and 5 of the > > document). > > Attached is the modified Sections 3, 4, & 5 for your comments. > > > > > 4. Condition MIB and ARC MIB > > > - changes from version 00 to version 01 > > > - open issues > > > - terminology - condition to be taken on the mailing list - Kam to > > > initiate the thread > > > > One of the comments on the document is that it should point > > to the alarm MIB > > for the definitions. Agree. Once the definitions (Error, > > Fault, Alarm, Alarm > > Raised, Alarm Cleared, Event, and Notification) are removed, > > the only term > > left is Condition. So I think the current Section 3.1 > > "Terminology" can be > > deleted and embed the definition of Condition in the first > > couple paragraphs > > at the beginning of Section 3 as follow. > > > > The Condition MIB module defines MIB objects and > > notifications that > > provide mechanism to monitor abnormal conditions currently active > > and the history of abnormal conditions being set and cleared on a > > managed system. > > > > The list of abnormal conditions that can be monitored by > > using this > > MIB are based on the Probable Causes defined in ITU-T > > Recommendations > > M.3100, X.733, and X.736. A textual convention, > > IANAItuProbableCause, > > has been defined in the Alarm MIB to assign values to the ITU-T > > Probable Causes. The IANAItuProbableCause textual > > convention is being > > used by the Condition MIB to represent the abnormal conditions. > > > > > - Alarm Raised and Clear - should point to the Alarm MIB > > > > Agree. See the attached file, Section 3. > > > > > - Alarm type definition - delete section 3.2 > > > > Agree. See the attached file, Section 3. > > > > > - Section 4.1 readability - text needs fixing, diagram > > should be taken > > > out > > > > Agree. See the attached file, Section 4.1. The diagram and > > associated text > > have been deleted. > > > > > - change 'clarification' in Section 5 that says that when a > > resource is > > > in ARC mode active alarm information SHALL be available for > > retrieval by > > > the managing system - change active alarm with condition > information > > > > Agree. See the attached file, Section 5, third paragraph, > > last sentence. > > > > > - section 5.1 - ARC impact on alarm notifications - needs > > to be further > > > worked on the list. > > > > The text has been modified to describe the general impact on alarm > > notifications according to M.3100 Amendment 3, and not to > describe its > > impact on specific notifications, such as those in the Alarm MIB and > > Condition MIB. See attached file, Section 5.1. > > > > > - relationship with Alarm MIB - Sharon to propose text on > > the mailing > > > list > > > > To be provided. Any input or suggestion on this item. > > > > Regards, > > Kam > > <> > > > > > > > > > > > From owner-disman@dorothy.bmc.com Wed Feb 6 21:11: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 VAA07370 for ; Wed, 6 Feb 2002 21:11:02 -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 g172DUm22072; Wed, 6 Feb 2002 20:13:30 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id SAA14848 for disman-list; Wed, 6 Feb 2002 18:08:22 -0800 (PST) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id SAA14842; Wed, 6 Feb 2002 18:08:19 -0800 (PST) Date: Wed, 6 Feb 2002 18:08:19 -0800 (PST) From: Randy Presuhn Message-Id: <200202070208.SAA14842@dorothy.bmc.com> To: atommib@research.telcordia.com, 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: <2E12619580C0D1118C6400805F9F4C950D7CEE39@nj7460exch001u.ho.lucent.com> > From: "Lam, Hing-Kam (Kam)" > To: "'Sharon Chisholm'" , > "'disman@dorothy.bmc.com'" , > "Lam, Hing-Kam (Kam)" , > "'AToM Working Group'" > Cc: "'Dan Romascanu'" , > "'David Perkins'" , > "Huynh, An-Ni (An-Ni)" > Subject: RE: Progressing the Condition/ARC MIB > Date: Wed, 6 Feb 2002 15:42:09 -0500 ... > Randy: Couple questions. Need your guidance. > (1) If no objection to this approach, can we simply call the document "ARC > MIB" (or Alarm Reporting Control MIB), instead of "CONDITION & ARC MIB"? If there are no objections, the title change is fine with me. However, I'd be surprised if there were no objections because much of the functionality is in the condition MIB part of the document. (For example, all that good stuff from X.733 and M.3100) > (2) How about the file name of the I-D? > draft-ietf-disman-conditionmib-02.txt or draft-ietf-disman-arcmib-02.txt or > draft-ietf-disman-arcmib-00.txt ? ... draft-ietf-disman-conditionmib-02.txt is the only name that will work. I won't be around around to approve a -00- draft before the deadline, and a new series of names must start with sequence number 00. ------------------------------------------------------ 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 Feb 6 21:22: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 VAA07599 for ; Wed, 6 Feb 2002 21:22: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 g172OW423115; Wed, 6 Feb 2002 20:24:32 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id SAA14904 for disman-list; Wed, 6 Feb 2002 18:19:49 -0800 (PST) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id SAA14898 for disman@dorothy.bmc.com; Wed, 6 Feb 2002 18:19:43 -0800 (PST) Date: Wed, 6 Feb 2002 18:19:43 -0800 (PST) From: Randy Presuhn Message-Id: <200202070219.SAA14898@dorothy.bmc.com> To: disman@dorothy.bmc.com Subject: Disman WG last call: Alarm 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 - Soon draft-ietf-disman-alarm-mib-05.txt should appear in the internet draft repositories. As disman WG chair, I'd like to start the working group last call on this document. The last call period will end with February 28, 2002. - Please send your comments to disman@dorothy.bmc.com. - If you read the document and have no comments, please notify the mailing list. - If you are committed to reviewing the document but need more time, please inform 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 Thu Feb 7 09:24: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 JAA27730 for ; Thu, 7 Feb 2002 09:24:36 -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 g17EPL309613; Thu, 7 Feb 2002 08:25:21 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id GAA27495 for disman-list; Thu, 7 Feb 2002 06:20:05 -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 GAA27489; Thu, 7 Feb 2002 06:20:01 -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 g17EIU704989; Thu, 7 Feb 2002 08:18:30 -0600 (CST) Received: from hoemail1.firewall.lucent.com (unknown [192.11.226.161]) by mx-us-hou-1-int.bmc.com (Postfix) with SMTP id 49FD120F01F; Thu, 7 Feb 2002 08:21:28 -0600 (CST) Received: from nj7460exch001h.wins.lucent.com (h135-17-42-36.lucent.com [135.17.42.36]) by hoemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g17ELMl09767; Thu, 7 Feb 2002 09:21:22 -0500 (EST) Received: by nj7460exch001h.ho.lucent.com with Internet Mail Service (5.5.2650.21) id ; Thu, 7 Feb 2002 09:21:22 -0500 Message-ID: <2E12619580C0D1118C6400805F9F4C950D7CEE3E@nj7460exch001u.ho.lucent.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 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list Hi, The M.3100 & X.733 Probable Causes are already defined as IANAItuProbableCause in the Alarm MIB and imported by the condition/arc mib. As said in the previous email, the ARC mib part will also include the Suppressed Alarms information via an alarmSuppressedTable. The alarmSuppressedTable would contain information similar to those in the existing condActiveTable. Therefore it will need the Textual Conventions similar to the existing ones in the Condition mib part. (However, instead of calling them ConditionIndex, ConditionLocation, ... etc., they will be AlarmIndex, AlarmLocation, etc.) Therefore the remaining portions of the Condition mib part are mainly the condActiveTable, condRetiredTable, condTransientTable, condActiveEvent notification, and condRetiredEvent notification. This is exactly the open issue we try to solve - i.e., "the relationship of the condition mib with the alarm mib". I thought Sharon's proposal is to drop the Condition mib part and let the ARC mib part move forward. I have no problem with this proposal. (That is why I asked about the document title and file name.) If we want to keep the Condition mib part, then we still need to resolve the "relationship" issue. 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? Regards, Kam > -----Original Message----- > From: Randy Presuhn [mailto:rpresuhn@dorothy.bmc.com] > Sent: Wednesday, February 06, 2002 9:08 PM > To: atommib@research.telcordia.com; disman@dorothy.bmc.com > Subject: RE: Progressing the Condition/ARC MIB > > > Hi - > > > Message-ID: > <2E12619580C0D1118C6400805F9F4C950D7CEE39@nj7460exch001u.ho.lu > cent.com> > > From: "Lam, Hing-Kam (Kam)" > > To: "'Sharon Chisholm'" , > > "'disman@dorothy.bmc.com'" , > > "Lam, Hing-Kam (Kam)" , > > "'AToM Working Group'" > > Cc: "'Dan Romascanu'" , > > "'David Perkins'" , > > "Huynh, An-Ni (An-Ni)" > > Subject: RE: Progressing the Condition/ARC MIB > > Date: Wed, 6 Feb 2002 15:42:09 -0500 > ... > > Randy: Couple questions. Need your guidance. > > (1) If no objection to this approach, can we simply call > the document "ARC > > MIB" (or Alarm Reporting Control MIB), instead of > "CONDITION & ARC MIB"? > > If there are no objections, the title change is fine with me. > However, I'd be surprised if there were no objections because > much of the functionality is in the condition MIB part of > the document. (For example, all that good stuff from X.733 > and M.3100) > > > (2) How about the file name of the I-D? > > draft-ietf-disman-conditionmib-02.txt or > draft-ietf-disman-arcmib-02.txt or > > draft-ietf-disman-arcmib-00.txt ? > ... > > draft-ietf-disman-conditionmib-02.txt is the only name that will > work. I won't be around around to approve a -00- draft before > the deadline, and a new series of names must start with sequence > number 00. > > ------------------------------------------------------ > 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 Thu Feb 7 13:24:26 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 NAA04780 for ; Thu, 7 Feb 2002 13:24: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 g17IQq727717; Thu, 7 Feb 2002 12:26:52 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id KAA28142 for disman-list; Thu, 7 Feb 2002 10:21:43 -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 KAA28137 for ; Thu, 7 Feb 2002 10:21:39 -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 g17IK8h06883 for ; Thu, 7 Feb 2002 12:20:08 -0600 (CST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mx-us-hou-2-int.bmc.com (Postfix) with SMTP id 1D3A51FF0AC for ; Thu, 7 Feb 2002 12:22:56 -0600 (CST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04528; Thu, 7 Feb 2002 13:22:38 -0500 (EST) Message-Id: <200202071822.NAA04528@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-alarm-mib-05.txt Date: Thu, 07 Feb 2002 13:22:38 -0500 Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Distributed Management Working Group of the IETF. Title : Alarm MIB Author(s) : S. Chisholm, D. Romascanu Filename : draft-ietf-disman-alarm-mib-05.txt Pages : 58 Date : 06-Feb-02 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes management objects used for defining and storing alarms. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-disman-alarm-mib-05.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-alarm-mib-05.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-alarm-mib-05.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: <20020206132134.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-disman-alarm-mib-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-disman-alarm-mib-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020206132134.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-disman@dorothy.bmc.com Thu Feb 7 17:38:46 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 RAA11732 for ; Thu, 7 Feb 2002 17:38:45 -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 g17Mf3h06555; Thu, 7 Feb 2002 16:41:03 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id OAA29311 for disman-list; Thu, 7 Feb 2002 14:35:13 -0800 (PST) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id OAA29305 for disman@dorothy.bmc.com; Thu, 7 Feb 2002 14:35:10 -0800 (PST) Date: Thu, 7 Feb 2002 14:35:10 -0800 (PST) From: Randy Presuhn Message-Id: <200202072235.OAA29305@dorothy.bmc.com> To: disman@dorothy.bmc.com Subject: Re: Will disman need to meet in MSP? 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, 5 Feb 2002 12:00:56 -0800 (PST) > From: Randy Presuhn > Message-Id: <200202052000.MAA28136@dorothy.bmc.com> > To: disman@dorothy.bmc.com > Subject: Will disman need to meet in MSP? ... I have seen no requests for meeting time for the disman WG in Minneapolis, so I will *not* request a slot there. If something comes up that would necessitate a face-to-face meeting in Minneapolis, please make your case with Bert Wijnen, our AD, since I will be away from email until after the deadline for slot requests. Though I plan to be in Minneapolis (what native Minnesotan could resist?), my strong preference is to finish our work items on 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 Feb 11 10:17: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 KAA05126 for ; Mon, 11 Feb 2002 10:17:51 -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 g1BF6xN01130; Mon, 11 Feb 2002 09:07:00 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id GAA13753 for disman-list; Mon, 11 Feb 2002 06:59:55 -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 GAA13748 for ; Mon, 11 Feb 2002 06:59:52 -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 g1BEwIh16529 for ; Mon, 11 Feb 2002 08:58:18 -0600 (CST) Received: from zcars0m9.ca.nortel.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by mx-us-hou-2-int.bmc.com (Postfix) with SMTP id C4AE91FF053 for ; Mon, 11 Feb 2002 09:01:19 -0600 (CST) Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57]) by zcars0m9.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g1BF12i00633 for ; Mon, 11 Feb 2002 10:01:03 -0500 (EST) 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 g1BF11V00339 for ; Mon, 11 Feb 2002 10:01:01 -0500 (EST) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <1J3PBR0P>; Mon, 11 Feb 2002 10:01:03 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD3401C0147C@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: disman@dorothy.bmc.com Subject: Alarm MIB Issue #21 Date: Mon, 11 Feb 2002 10:01:06 -0500 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 just noticed something silly I did on the last update. Alarm #21 AlarmRaise/Set/Active I changed the name of the alarmRaise notification because that name did not reflect the actual use of the notification. For some reason, I changed it to alarmSet, a term not used anywhere else in the document. This should be alarmActive to be consistent with the rest of the terminology. Sharon Chisholm Preside Management Nortel Networks Ottawa, Ontario From owner-disman@dorothy.bmc.com Mon Feb 11 11:48: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 LAA09432 for ; Mon, 11 Feb 2002 11:48:06 -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 g1BGiMK24638; Mon, 11 Feb 2002 10:44:22 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id IAA13924 for disman-list; Mon, 11 Feb 2002 08:38:39 -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 IAA13919 for ; Mon, 11 Feb 2002 08:38:31 -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 g1BGavI21482 for ; Mon, 11 Feb 2002 10:36:57 -0600 (CST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by mx-us-hou-2-int.bmc.com (Postfix) with SMTP id 425F91FF0E5 for ; Mon, 11 Feb 2002 10:39:58 -0600 (CST) 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 g1BGdf43026269 for ; Mon, 11 Feb 2002 17:39:41 +0100 (MET) Received: from there (lm6068.lmera.ericsson.se [150.132.106.68]) by mbb1.ericsson.se (PMDF V5.2-29 #39352) with SMTP id <0GRD00F0TNM32H@mbb1.ericsson.se> for disman@dorothy.bmc.com; Mon, 11 Feb 2002 17:39:41 +0100 (MET) Date: Mon, 11 Feb 2002 17:39:39 +0100 From: David Partain Subject: Re: draft-ietf-disman-alarm-mib-05.txt Just Submitted In-reply-to: <3549C09B853DD5119B540002A52CDD3401AEAAA5@zcard0ka.ca.nortel.com> To: Sharon Chisholm Cc: DISMAN Mailing List Reply-To: David.Partain@ericsson.com Message-id: <0GRD00F0XNM52H@mbb1.ericsson.se> MIME-version: 1.0 X-Mailer: KMail [version 1.3.2] Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8bit References: <3549C09B853DD5119B540002A52CDD3401AEAAA5@zcard0ka.ca.nortel.com> Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list Content-Transfer-Encoding: 8bit Hi Sharon, In glancing through the new alarm MIB, there are a few things that need to be changed: I see you did what I recommended and changed some indices to accessible-for-notify. Unfortunately, as David Perkins correctly pointed out, this is illegal. :-) They must be not-accessible. This applies to alarmModelIndex, alarmModelState. That also means that you have to change alarmSet to include a different object from the alarmModelTable and remove alarmModelIndex and alarmModelState. I put in the description object for the diff below. Your "ResourceId" TC violates the SMI because RowPointer is a TC itself. You need either to change this to OBJECT IDENTIFIER or simply give alarmActiveResourceId and alarmClearResourceId the SYNTAX RowPointer and explain in the DESCRIPTION where it should point. If you just use RowPointer, it would mean you can remove the TC completely. The name of alarmActiveStatsLastRaise in one of the object groups needs to be changed. Note that this diff doesn't reflect your mail about calling the notification alarmActive. Hope this helps. Cheers, dlp --- ALARM-MIB.orig Mon Feb 11 17:27:50 2002 +++ ALARM-MIB Mon Feb 11 17:32:17 2002 @@ -6,8 +6,7 @@ TimeTicks, Counter32, Counter64, IpAddress, Opaque, mib-2 FROM SNMPv2-SMI DateAndTime, - RowStatus, RowPointer, - TEXTUAL-CONVENTION FROM SNMPv2-TC + RowStatus, RowPointer FROM SNMPv2-TC SnmpAdminString, SnmpEngineID FROM SNMP-FRAMEWORK-MIB InetAddressType, InetAddress FROM INET-ADDRESS-MIB MODULE-COMPLIANCE, OBJECT-GROUP, @@ -52,22 +51,6 @@ alarmClear OBJECT IDENTIFIER ::= { alarmObjects 3 } --- Textual Conventions - -ResourceId ::= TEXTUAL-CONVENTION - STATUS current - DESCRIPTION - "A unique identifier for this resource. - - The type of the resource can be determined by looking - at the OID that describes the resource. - - Resources must be identified in a consistent manner. - For example, if this resource is an interface, this - object MUST point to an ifIndex." - SYNTAX RowPointer - - -- Alarm Model alarmModelLastChanged OBJECT-TYPE @@ -118,7 +101,7 @@ alarmModelIndex OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) - MAX-ACCESS accessible-for-notify + MAX-ACCESS not-accessible STATUS current DESCRIPTION "An integer that acts as an alarm Id @@ -128,7 +111,7 @@ alarmModelState OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) - MAX-ACCESS accessible-for-notify + MAX-ACCESS not-accessible STATUS current DESCRIPTION "A value of 1 MUST indicate a clear alarm state. @@ -261,7 +244,7 @@ alarmActiveContextName SnmpAdminString, alarmActiveVariables Unsigned32, alarmActiveNotificationID OBJECT IDENTIFIER, - alarmActiveResourceId ResourceId, + alarmActiveResourceId RowPointer, alarmActiveDescription SnmpAdminString, alarmActiveLogIndex Unsigned32, alarmActiveModelPointer RowPointer, @@ -374,7 +357,7 @@ ::= { alarmActiveEntry 9 } alarmActiveResourceId OBJECT-TYPE - SYNTAX ResourceId + SYNTAX RowPointer MAX-ACCESS read-only STATUS current DESCRIPTION @@ -706,7 +689,7 @@ alarmClearEngineAddress InetAddress, alarmClearContextName SnmpAdminString, alarmClearNotificationID OBJECT IDENTIFIER, - alarmClearResourceId ResourceId, + alarmClearResourceId RowPointer, alarmClearLogIndex Unsigned32, alarmClearModelPointer RowPointer } @@ -794,7 +777,7 @@ ::= { alarmClearEntry 7 } alarmClearResourceId OBJECT-TYPE - SYNTAX ResourceId + SYNTAX RowPointer MAX-ACCESS read-only STATUS current DESCRIPTION @@ -829,25 +812,26 @@ alarmSet NOTIFICATION-TYPE - OBJECTS { alarmModelIndex, - alarmModelState, + OBJECTS { alarmModelDescription, alarmActiveResourceId } STATUS current DESCRIPTION - "An instance of the alarm indicated by alarmModelIndex - has been set against the entity indicated by - alarmActiveResourceType and alarmACtiveResourceId." + "An instance of the alarm indicated by alarmModelIndex/ + alarmModelState (found by gleaning the index from + alarmModelDescription) has been set against the + entity indicated by alarmActiveResourceId." ::= { alarmNotifications 1 } alarmCleared NOTIFICATION-TYPE - OBJECTS { alarmModelIndex, + OBJECTS { alarmModelDescription, alarmActiveResourceId } STATUS current DESCRIPTION - "An instance of the alarm indicated by alarmModelIndex - has been cleared against the entity indicated by - alarmActiveResourceType and alarmACtiveResourceId." - ::= { alarmNotifications 0 2 } + "An instance of the alarm indicated by alarmModelIndex/ + alarmModelState (found by gleaning the index from + alarmModelDescription) has been cleared against + the entity indicated by alarmActiveResourceId." + ::= { alarmNotifications 2 } -- Conformance @@ -872,8 +856,6 @@ alarmModelGroup OBJECT-GROUP OBJECTS { alarmModelLastChanged, - alarmModelIndex, - alarmModelState, alarmModelNotificationId, alarmModelVarbindIndex, alarmModelVarbindValue, @@ -923,7 +905,7 @@ OBJECTS { alarmActiveStatsTotalActive, alarmActiveStatsCurrentActive, - alarmActiveStatsLastRaise, + alarmActiveStatsLastSet, alarmActiveStatsLastClear } STATUS current From owner-disman@dorothy.bmc.com Thu Feb 28 07:50: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 HAA20173 for ; Thu, 28 Feb 2002 07:50:16 -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 g1SCqhH14035; Thu, 28 Feb 2002 06:52:43 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id EAA25148 for disman-list; Thu, 28 Feb 2002 04:45:24 -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 EAA25143 for ; Thu, 28 Feb 2002 04:45:19 -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 g1SChag07521 for ; Thu, 28 Feb 2002 06:43:36 -0600 (CST) Received: from zcars0m9.ca.nortel.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by mx-us-hou-2-int.bmc.com (Postfix) with SMTP id C576F1FF007 for ; Thu, 28 Feb 2002 06:46:47 -0600 (CST) Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56]) by zcars0m9.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g1SCkUD02720 for ; Thu, 28 Feb 2002 07:46:31 -0500 (EST) 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 g1SCkSS17161 for ; Thu, 28 Feb 2002 07:46:29 -0500 (EST) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 28 Feb 2002 07:46:31 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD3401FF1A77@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: disman@dorothy.bmc.com Subject: Alarm MIB - Issues From Last Call Date: Thu, 28 Feb 2002 07:46:34 -0500 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 believe we complete last call today. Here are the issues raised to date and the proposed resolution. I can make these changes and issue a -06 version, but as we are not meeting in Minneapolis, I'm not sure if it makes sense to try and make the draft cut-off date. Alarm #21 AlarmSet notification should be alarmActive --------- Make this change Alarm #22 Incorrect access privileges on indices. --------- Change the access privileges. Use different object as varbind in alarmActive notification Alarm #22 Type of ResourceId should be OBJECT IDENTIFIER --------- Make this change Sharon Chisholm Preside Management Nortel Networks Ottawa, Ontario