From owner-disman@dorothy.bmc.com Fri Dec 1 15:36:24 2000 Received: from tattler.bmc.com (fw-us-hou-1.bmc.com [198.207.223.250]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA16095 for ; Fri, 1 Dec 2000 15:36:24 -0500 (EST) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id eB1KQh622447; Fri, 1 Dec 2000 14:26:43 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id MAA20779 for disman-list; Fri, 1 Dec 2000 12:25:40 -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 MAA20774 for ; Fri, 1 Dec 2000 12:25:36 -0800 (PST) Received: from fw-us-hou1.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with SMTP id eB1KOlp21922 for ; Fri, 1 Dec 2000 14:24:47 -0600 (CST) Received: (from revab@localhost) by shell9.ba.best.com (8.9.3/8.9.2/best.sh) id MAA27921 for disman@dorothy.bmc.com; Fri, 1 Dec 2000 12:25:35 -0800 (PST) From: Reva Bailey Message-Id: <200012012025.MAA27921@shell9.ba.best.com> Subject: Re: Proposed disman charter addition: alarm tracking To: disman@dorothy.bmc.com Date: Fri, 1 Dec 2000 12:25:35 -0800 (PST) X-Mailer: ELM [version 2.4ME+ PL38 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 X-MIME-Autoconverted: from 8bit to quoted-printable by shell9.ba.best.com id MAA27921 X-MIME-Autoconverted: from quoted-printable to 8bit by dorothy.bmc.com id MAA20775 Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list X-MIME-Autoconverted: from 8bit to quoted-printable by tattler.bmc.com id eB1KQh622447 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id PAA16095 I am also interested in an Alarm Management MIB. My work requires mapping to the ITU alarm model, flawed or not. I don't mind creating a better alarm model as long as the mapping to the ITU alarm model is straight forward. Reva Bailey TiMetra, Inc. revab@timetra.com > > Hi - > > Several people have read Sharon's draft and made substantive > comments to this list. As working group chair, I'd like to > determine whether we have a consensus to request of our ADs > that this deliverable be added to our charter. (The work > falls squarely within the existing scope of the charter, > in my opinion, so the only real question in my mind is > whether we have sufficient commitment in the group to > deliver a standards-track document.) > > We should have one-or-two line description of the deliverables > and dates. Here's a strawman, pulled out of the air: > > April, 2001: WG last call on Alarm Management MIB > > May, 2001: Alarm Management MIB delivered to IESG for > consideration as proposed standard. > > Sharon would be my choice as the document's editor. > > Are these dates reasonable? For example, should the scope > be expanded to include interworking with some non-SNMP > technologies? > > ------------------------------------------------------- > Randy Presuhn randy_presuhn@bmc.com > Voice: +1 408 546-1006 BMC Software, Inc. 1-3141 > Fax: +1 408 965-0359 2141 North First Street > http://www.bmc.com/ San José, California 95131 USA > ------------------------------------------------------- > My opinions and BMC's are independent variables. > ------------------------------------------------------- > > > ----- End of forwarded message from Randy Presuhn ----- From owner-disman@dorothy.bmc.com Mon Dec 4 10:17:31 2000 Received: from tattler.bmc.com (fw-us-hou-1.bmc.com [198.207.223.250]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA19197 for ; Mon, 4 Dec 2000 10:17:27 -0500 (EST) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id eB4FA1913574; Mon, 4 Dec 2000 09:10:01 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id HAA00218 for disman-list; Mon, 4 Dec 2000 07:08:38 -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 HAA00213 for ; Mon, 4 Dec 2000 07:08:33 -0800 (PST) Received: from fw-us-hou1.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with SMTP id eB4F7gV12915 for ; Mon, 4 Dec 2000 09:07:42 -0600 (CST) Received: from hansa.ibr.cs.tu-bs.de (IDENT:root@hansa [134.169.34.137]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) with ESMTP id QAA22272; Mon, 4 Dec 2000 16:09:23 +0100 (MET) Received: (from strauss@localhost) by hansa.ibr.cs.tu-bs.de (8.9.3/8.9.3) id QAA19058; Mon, 4 Dec 2000 16:09:23 +0100 X-Authentication-Warning: hansa.ibr.cs.tu-bs.de: strauss set sender to strauss@ibr.cs.tu-bs.de using -f From: Frank Strauss To: disman@dorothy.bmc.com Subject: Re: Comments on RFC 2591 References: Date: 04 Dec 2000 16:09:23 +0100 In-Reply-To: Frank Strauss's message of "30 Nov 2000 16:12:59 +0100" Message-ID: Lines: 37 User-Agent: Gnus/5.0803 (Gnus v5.8.3) Emacs/20.7 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 Another question/comment on RFC 2591: 5. Section 3.4. describes a model of two kinds of time transitions, those that cause ambiguous times and those that cause non-existent times. On time transitions that cause non-existent times, the text says: When an action is configured in the Schedule MIB to occur at a nonexistent time, the action SHOULD be invoked immediately upon a time transition. If multiple actions are invoked in this way, they SHALL be invoked in the order in which they normally would be invoked had the time transition not occured. For example, if an action (a) is scheduled at 2:05 am and another action (b) at 2:10 am, then both actions SHOULD be invoked at 3:00 am in the order (a),(b) if the time jumps forward from 2:00 am to 3:00 am. This example talks about two distinct actions (thus described by two separate schedules). But how about a single action of a single schedule that would be invoked multiple times during a single `period of non-existent time ;-)'? Assume you have a schedEntry like this: schedType = periodic schedWeekDay = sunday schedDay = d29 schedMonth = oct schedHour = 2 schedMinute = m0 + m1 + ... + m58 + m59 Would the action of this schedule have been invoked 60 times at 3 o'clock right after the end of the daylight savings period? Or would it have been invoked just once? I think there could be reasons for both models, but I see more value in having it invoked just once. However, I believe the text should be clearer at this point. From owner-disman@dorothy.bmc.com Tue Dec 5 11:38:26 2000 Received: from tattler.bmc.com (fw-us-hou-1.bmc.com [198.207.223.250]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA03705 for ; Tue, 5 Dec 2000 11:38:26 -0500 (EST) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id eB5GWJH05002; Tue, 5 Dec 2000 10:32:19 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id IAA04518 for disman-list; Tue, 5 Dec 2000 08:30:38 -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 IAA04513 for ; Tue, 5 Dec 2000 08:30:34 -0800 (PST) Received: from fw-us-hou1.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with SMTP id eB5GTgT04166 for ; Tue, 5 Dec 2000 10:29:43 -0600 (CST) Received: from zcard015.ca.nortel.com by zcars04e.ca.nortel.com; Tue, 5 Dec 2000 11:28:34 -0500 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2652.35) id ; Tue, 5 Dec 2000 11:28:35 -0500 Message-ID: <6DDA62170439D31185750000F80826AC049C7263@zmerd004.ca.nortel.com> From: "Sharon Chisholm" To: disman@dorothy.bmc.com Subject: Model-neutral & Model-specific Alarm Deliverables Date: Tue, 5 Dec 2000 11:28:27 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C05ED8.656C09E0" X-Orig: Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C05ED8.656C09E0 Content-Type: text/plain; charset="iso-8859-1" hi Dan and I have been discussing the best way to move forward based on some of the comments on the mailing list. We would like to break the Alarm MIB deliverable into two pieces: 1. A model-neutral MIB containing the active alarm list, raise/clear mapping, aging and any other model-neutral requirements 2. An ITU Alarm Model MIB. This both proves the model-neutral MIB's ability to work with an alarm model but fulfils a requirement of the install base already using this model. This division doesn't rule out a more generic alarm model being defined in the future and being used with the model-neutral MIB. Thoughts? Sharon Chisholm Preside Management Nortel Networks Ottawa, Ontario ------_=_NextPart_001_01C05ED8.656C09E0 Content-Type: text/html; charset="iso-8859-1" Model-neutral & Model-specific Alarm Deliverables

hi

Dan and I have been discussing the best way to move forward
based on some of the comments on the mailing list.  We would
like to break the Alarm MIB deliverable into two pieces:
        1. A model-neutral MIB containing the active alarm list,
           raise/clear mapping, aging and any other model-neutral
           requirements
        2. An ITU Alarm Model MIB.  This both proves the model-neutral
           MIB's ability to work with an alarm model but fulfils a
           requirement of the install base already using this model.

This division doesn't rule out a more generic alarm model being defined
in the future and being used with the model-neutral MIB.

Thoughts?

Sharon Chisholm
Preside Management
Nortel Networks
Ottawa, Ontario

------_=_NextPart_001_01C05ED8.656C09E0-- From owner-disman@dorothy.bmc.com Tue Dec 5 11:51:04 2000 Received: from tattler.bmc.com (fw-us-hou-1.bmc.com [198.207.223.250]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA07657 for ; Tue, 5 Dec 2000 11:51:04 -0500 (EST) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id eB5GinI08376; Tue, 5 Dec 2000 10:44:49 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id IAA04567 for disman-list; Tue, 5 Dec 2000 08:45:18 -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 IAA04562 for ; Tue, 5 Dec 2000 08:45:14 -0800 (PST) Received: from fw-us-hou1.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with SMTP id eB5GiM308223 for ; Tue, 5 Dec 2000 10:44:22 -0600 (CST) Received: from henkell.ibr.cs.tu-bs.de (schoenw@henkell [134.169.34.191]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) with ESMTP id RAA06036; Tue, 5 Dec 2000 17:46:01 +0100 (MET) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id RAA16660; Tue, 5 Dec 2000 17:46:01 +0100 Date: Tue, 5 Dec 2000 17:46:01 +0100 Message-Id: <200012051646.RAA16660@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: schishol@nortelnetworks.com CC: disman@dorothy.bmc.com In-reply-to: <6DDA62170439D31185750000F80826AC049C7263@zmerd004.ca.nortel.com> (schishol@nortelnetworks.com) Subject: Re: Model-neutral & Model-specific Alarm Deliverables References: <6DDA62170439D31185750000F80826AC049C7263@zmerd004.ca.nortel.com> Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list >>>>> Sharon Chisholm writes: Sharon> Dan and I have been discussing the best way to move forward Sharon> based on some of the comments on the mailing list. We would Sharon> like to break the Alarm MIB deliverable into two pieces: 1. A Sharon> model-neutral MIB containing the active alarm list, Sharon> raise/clear mapping, aging and any other model-neutral Sharon> requirements 2. An ITU Alarm Model MIB. This both proves the Sharon> model-neutral MIB's ability to work with an alarm model but Sharon> fulfils a requirement of the install base already using this Sharon> model. I prefer a simple single alarm model and mib. Lets keep it small and simple so that it actually gets implemented and deployed. /js -- Juergen Schoenwaelder Technical University Braunschweig Dept. Operating Systems & Computer Networks Phone: +49 531 391 3289 Bueltenweg 74/75, 38106 Braunschweig, Germany Fax: +49 531 391 5936 From owner-disman@dorothy.bmc.com Tue Dec 5 12:04:02 2000 Received: from tattler.bmc.com (fw-us-hou-1.bmc.com [198.207.223.250]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA11550 for ; Tue, 5 Dec 2000 12:04:01 -0500 (EST) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id eB5GuE512106; Tue, 5 Dec 2000 10:56:14 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id IAA04588 for disman-list; Tue, 5 Dec 2000 08:55:15 -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 IAA04583 for ; Tue, 5 Dec 2000 08:55:07 -0800 (PST) Received: from fw-us-hou2.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with SMTP id eB5Grc310911 for ; Tue, 5 Dec 2000 10:53:39 -0600 (CST) Received: by itc-eml2.lannet.com with Internet Mail Service (5.5.2650.21) id ; Tue, 5 Dec 2000 18:53:50 +0200 Message-ID: <15F58915DF84D311AC7D0090279AA614234213@itc-eml2.lannet.com> From: Dan Romascanu To: "'Juergen Schoenwaelder'" , schishol@nortelnetworks.com Cc: disman@dorothy.bmc.com Subject: RE: Model-neutral & Model-specific Alarm Deliverables Date: Tue, 5 Dec 2000 18:53:40 +0200 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 Juergen, It's even simpler. The Alarm MIB is model neutral and will keep a pointer to the alarm model. We think that developing a generic alarm model is too big a task to be dealt with in one hop. We would like to use this scalable mechanism, and gather some experience with building a specific model that deals with the ITU alarms mapping. Regards, Dan > -----Original Message----- > From: Juergen Schoenwaelder [SMTP:schoenw@ibr.cs.tu-bs.de] > Sent: Tue December 05 2000 18:46 > To: schishol@nortelnetworks.com > Cc: disman@dorothy.bmc.com > Subject: Re: Model-neutral & Model-specific Alarm Deliverables > > > > >>>>> Sharon Chisholm writes: > > Sharon> Dan and I have been discussing the best way to move forward > Sharon> based on some of the comments on the mailing list. We would > Sharon> like to break the Alarm MIB deliverable into two pieces: 1. A > Sharon> model-neutral MIB containing the active alarm list, > Sharon> raise/clear mapping, aging and any other model-neutral > Sharon> requirements 2. An ITU Alarm Model MIB. This both proves the > Sharon> model-neutral MIB's ability to work with an alarm model but > Sharon> fulfils a requirement of the install base already using this > Sharon> model. > > I prefer a simple single alarm model and mib. Lets keep it small and > simple so that it actually gets implemented and deployed. > > /js > > -- > Juergen Schoenwaelder Technical University Braunschweig > Dept. Operating Systems & Computer Networks > Phone: +49 531 391 3289 Bueltenweg 74/75, 38106 Braunschweig, Germany > Fax: +49 531 391 5936 > From owner-disman@dorothy.bmc.com Tue Dec 5 16:03:13 2000 Received: from tattler.bmc.com (fw-us-hou-1.bmc.com [198.207.223.250]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA17264 for ; Tue, 5 Dec 2000 16:03:04 -0500 (EST) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id eB5Kv5B29919; Tue, 5 Dec 2000 14:57:05 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id MAA05019 for disman-list; Tue, 5 Dec 2000 12:57:09 -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 MAA05014 for ; Tue, 5 Dec 2000 12:57:05 -0800 (PST) Received: from fw-us-hou1.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with SMTP id eB5KuE929707 for ; Tue, 5 Dec 2000 14:56:14 -0600 (CST) Received: from henkell.ibr.cs.tu-bs.de (schoenw@henkell [134.169.34.191]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) with ESMTP id VAA16999; Tue, 5 Dec 2000 21:57:38 +0100 (MET) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id VAA16999; Tue, 5 Dec 2000 21:57:38 +0100 Date: Tue, 5 Dec 2000 21:57:38 +0100 Message-Id: <200012052057.VAA16999@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: dromasca@avaya.com CC: schishol@nortelnetworks.com, disman@dorothy.bmc.com In-reply-to: <15F58915DF84D311AC7D0090279AA614234213@itc-eml2.lannet.com> (message from Dan Romascanu on Tue, 5 Dec 2000 18:53:40 +0200) Subject: Re: Model-neutral & Model-specific Alarm Deliverables References: <15F58915DF84D311AC7D0090279AA614234213@itc-eml2.lannet.com> Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list >>>>> Dan Romascanu writes: Dan> It's even simpler. The Alarm MIB is model neutral and will keep a Dan> pointer to the alarm model. Hm. I guess I need to see the details before I can understand what this model neutral part is and what the alarm model part is. Dan> We think that developing a generic alarm model is too big a task Dan> to be dealt with in one hop. We would like to use this scalable Dan> mechanism, and gather some experience with building a specific Dan> model that deals with the ITU alarms mapping. I was not arguing for a generic alarm model. I was arguing for one which is just good enough to do what many folks have done before in private MIBs (and they are usually based on the ITU alarm model). /js -- Juergen Schoenwaelder Technical University Braunschweig Dept. Operating Systems & Computer Networks Phone: +49 531 391 3289 Bueltenweg 74/75, 38106 Braunschweig, Germany Fax: +49 531 391 5936 From owner-disman@dorothy.bmc.com Tue Dec 5 22:45:41 2000 Received: from tattler.bmc.com (fw-us-hou-2.bmc.com [198.207.223.251]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA28075 for ; Tue, 5 Dec 2000 22:45:40 -0500 (EST) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id eB63bk215019; Tue, 5 Dec 2000 21:37:46 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id TAA05676 for disman-list; Tue, 5 Dec 2000 19:37:37 -0800 (PST) Received: from creeper.bmc.com (creeper.bmc.com [172.17.1.166]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id TAA05671 for ; Tue, 5 Dec 2000 19:37:33 -0800 (PST) Received: from ec02-hou.bmc.com (localhost [127.0.0.1]) by creeper.bmc.com (8.10.2/8.10.2) with ESMTP id eB63c2N25395; Tue, 5 Dec 2000 21:38:02 -0600 (CST) Received: by EC02-HOU.bmc.com with Internet Mail Service (5.5.2650.21) id ; Tue, 5 Dec 2000 21:38:15 -0600 Message-ID: From: "Ayers, Mike" To: "'Sharon Chisholm'" , disman@dorothy.bmc.com Subject: RE: draft-chisholm-disman-active-alarm-01.txt Date: Tue, 5 Dec 2000 21:40:33 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list > From: Sharon Chisholm [mailto:schishol@nortelnetworks.com] > > Comments in-line. > > >-----Original Message----- > >From: Ayers, Mike [mailto:Mike_Ayers@bmc.com] > > > >> From: Sharon Chisholm [mailto:schishol@nortelnetworks.com] > >> > >> These seem to apply to only a small subset of alarms. Wouldn't it > >> then be better to go with the option you also suggested of just > >> having them as varbinds in the trap, and therefore present in the > >> alarmActiveVariablesTable? > > > > Actually, I think they apply to about half the alarms, > since my copy > >of X.736 states that they are mandatory for all security > alarms. Does > yours > >read the same (mine is not a final copy, unfortunately)? > > That is how mine reads, but I would think that security > alarms would not be > that big of a percentage of the alarms a system has. Do you > really see it > being as much as half? I was thinking closer to 5%. It all depends on how you do the counting. You can count the two major alarm groups, application and security, and get 50%. You can count the number of alarm types and get ~50%. You can count the number of individual alarms actually posted on deployed systems and get a number (hopefully) vastly smaller than 5%. Finally (I think this is the important one), you can count the number of deployed ITU alarm systems which use the security objects (my terminology may be slipping, I don't have the ITU specs handy) and get a percentage I cannot even guess at. > > I don't object to these objects being in the > >alarmActiveVariablesTable, but I do think that there should > be objects > >defined specifically for them somewhere in the Active Alarm > MIB so that > they > >can be identified as such. > Maybe, I think this depends on the percentage of traps that > would actually > use these parameters. I don't see why. Perhaps you misunderstand my suggestion. I am looking for something like: alarmStandardObjects OBJECT IDENTIFIER ::= { alarm 3 } alarmStandardObjectsSecurityAlarmDetector OBJECT-TYPE SYNTAX OCTET STRING MAX-ACCESS not-accessible STATUS current DESCRIPTION "The detector of the current security alarm." alarmStandardObjectsServiceUser OBJECT-TYPE SYNTAX OCTET STRING MAX-ACCESS not-accessible STATUS current DESCRIPTION "The user of the currently alarmed service." alarmStandardObjectsServiceProvider OBJECT-TYPE SYNTAX OCTET STRING MAX-ACCESS not-accessible STATUS current DESCRIPTION "The provider of the service currently experiencing security alarm." This would allow objects to be mapped into the Alarm MIB from ITU tables and vice versa. Without them, there can be no transformation with the ITU tables. Note that they are not accessible, since it is only their OIDs that we would make use of. > >> PS. I send explicitly as plain text, it just arrive as > html. Network > >> Gremlins. > >> > > > > Some network admin is doing us a "favor", isn't that sweet? > > > I'm trying something new. Let me know if it's better or worse. Very nice, thank you! Nothin' but text! /|/|ike From owner-disman@dorothy.bmc.com Thu Dec 7 12:11:58 2000 Received: from tattler.bmc.com (fw-us-hou-2.bmc.com [198.207.223.251]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA23952 for ; Thu, 7 Dec 2000 12:11:57 -0500 (EST) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id eB7H2FJ27113; Thu, 7 Dec 2000 11:02:15 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id JAA10855 for disman-list; Thu, 7 Dec 2000 09:00:31 -0800 (PST) Received: from creeper.bmc.com (creeper.bmc.com [172.17.1.166]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id JAA10850 for ; Thu, 7 Dec 2000 09:00:27 -0800 (PST) Received: from ec03-hou.bmc.com (localhost [127.0.0.1]) by creeper.bmc.com (8.10.2/8.10.2) with ESMTP id eB7H0uh03832; Thu, 7 Dec 2000 11:00:56 -0600 (CST) Received: by ec03-hou.bmc.com with Internet Mail Service (5.5.2650.21) id ; Thu, 7 Dec 2000 11:00:53 -0600 Message-ID: From: "Ayers, Mike" To: "'David T. Perkins'" , disman@dorothy.bmc.com Subject: RE: Proposed disman charter addition: alarm tracking Date: Thu, 7 Dec 2000 11:03:29 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list > From: David T. Perkins [mailto:dperkins@dsperkins.com] > On the other hand, I believe the > ITU-T documents on which the Sharon's MIB is a based are > "fatally flawed", Really? How many telco workers have we lost so far? > and these flaws are carried forward in Sharon's document. > Additionally, the approach that is used to implement a union, > which is a reuse of a design pattern used in other disman MIB > modules, has very bad performance characteristics for bulk > retrieval. The problem of storing typed data of arbitrary type is not new, and so far, no elegant solution has emerged. There are two general solutions to the problem. Either one can create a union by using the OPAQUE primitive, or one can create a list of all possible types and a type discriminator for that list, as has been done in the Alarm and Notification Log MIBs. I have not seen the former employed, which is probably good, since it merely dumps the type problem on the manager. The latter solution is not quite as inefficient as it first appears, at least with respect to network bandwidth. Consider the following algorithm. First, using getbulk, walk alarmActiveVariableID. Copy the IDs into the name fields of two varbindlist structures, result and valueRetrieval. In the valueRetrieval structure, change 2 to 3 in the last field before the index so that alarmActiveVariableID.index becomes alarmActiveVariableType.index. Perform a get with this structure, but don't dispose of it. When the response comes back, copy the value for each varbind plus 3 into the last field before the index (e.g. if the alarmActiveVariableValueType is counter32(1), then change 3 to 4 (1+3) in the last field before the index to make alarmActiveVariableValueType.index into alarmActiveVariableCounter32Val.index). Perform another get. Copy the values into the corresponding value fields of the result structure. Delete the valueRetrieval structure. The result structure now contains the complete varbind list of the alarm. This method would be only 50% slower than an implementation that used OPAQUE. While it requires three requests to complete, it retrieves only required variables, and the multiple requests should be negligible overhead once the number of variables involved gets significant. There is another alternative that I have seen, but I do not consider it to be a good idea, therefore I hesitate to mention it. The SNMPconf Policy Management MIB contains a pmTrackingElementToPolicyTable whose objects don't appear unless they have a nonzero value. I consider such "magic MIBs" to be bad SNMP. Finally, Randy Presuhn showed me a way to retrieve N stored arbitrary varbinds in 2N varbind fetches, but it would require significant modifications to the existing MIB. In brief, tables would exist for each supported variable type, and there would be a table for retrieving the name (ID) of the each varbind, indexed by {alarmListName, alarmActiveIndex, alarmActiveVariableIndex, alarmActiveVariableValueType}. This way, when retrieving the ID of the varbind, you get the type number as bonus! Now, just look in the table for storing the given data type, also indexed by {alarmListName, alarmActiveIndex, alarmActiveVariableIndex}, and there is your varbind's value. This method has the added bonus of requiring storage for only those variables actually stored. If it is believed that large alarm tables will be maintained, then I would recommend this method. > Before the MIB module > should be written, the model needs to be described, which > has not been done in the contribution. This is really needed > due to differing uses of the "alarm" (and associated) terminology > and differing alarm models by vendors. Absolutely. A thread should be started for this. Sharon? /|/|ike From owner-disman@dorothy.bmc.com Thu Dec 7 17:39:11 2000 Received: from tattler.bmc.com (fw-us-hou-1.bmc.com [198.207.223.250]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA19991 for ; Thu, 7 Dec 2000 17:39:11 -0500 (EST) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id eB7MYJQ25238; Thu, 7 Dec 2000 16:34:19 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id OAA12021 for disman-list; Thu, 7 Dec 2000 14:34:26 -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 OAA12016 for ; Thu, 7 Dec 2000 14:34:22 -0800 (PST) Received: from fw-us-hou1.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with SMTP id eB7MXJr24911 for ; Thu, 7 Dec 2000 16:33:20 -0600 (CST) Received: from dperkins-nb2.dsperkins.com ([24.15.219.251]) by femail5.sdc1.sfba.home.com (InterMail vM.4.01.03.00 201-229-121) with ESMTP id <20001207223502.PKHY21363.femail5.sdc1.sfba.home.com@dperkins-nb2.dsperkins.com>; Thu, 7 Dec 2000 14:35:02 -0800 Message-Id: <5.0.2.1.2.20001207095109.0286ec60@mail.scruznet.com> X-Sender: dperkins@mail.scruznet.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Thu, 07 Dec 2000 10:05:00 -0800 To: "Ayers, Mike" , disman@dorothy.bmc.com From: "David T. Perkins" Subject: RE: Proposed disman charter addition: alarm tracking 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, Mike, thanks for looking into the performance issues. Given that I believe that an Alarm MIB module will be used more than all others, performance is important. Many years ago, some of the network operators that were attending working group meetings asked for information to be included in the RFCs that showed how the objects and notifications defined in MIB modules were to be used to solve problems. The WG said that this was too much work, and today, few RFCs contain implementation hints. How to use MIB objects and notifications was to be covered by book authors. So far, little has been published. Should this burden be pushed back to RFC authors? Well, not completely, but there needs to be a more than just the object and notification definitions except for really simple MIB modules. Since performance is important with this MIB module, some ammount of implementation strategy needs to be covered in the RFC (and alot more on the WG mailing list). Regards, /david t. perkins From owner-disman@dorothy.bmc.com Thu Dec 7 20:40:02 2000 Received: from tattler.bmc.com (fw-us-hou-2.bmc.com [198.207.223.251]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA26896 for ; Thu, 7 Dec 2000 20:40:02 -0500 (EST) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id eB81RQ802220; Thu, 7 Dec 2000 19:27:26 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id RAA12637 for disman-list; Thu, 7 Dec 2000 17:27:34 -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 RAA12632 for ; Thu, 7 Dec 2000 17:27:29 -0800 (PST) Received: from fw-us-hou1.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with SMTP id eB81QYY02035 for ; Thu, 7 Dec 2000 19:26:34 -0600 (CST) Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by boreas.isi.edu (8.9.3/8.9.3) with ESMTP id RAA15815; Thu, 7 Dec 2000 17:28:14 -0800 (PST) Message-Id: <200012080128.RAA15815@boreas.isi.edu> To: IETF-Announce: ; Subject: RFC 3014 on Notification Log MIB Cc: rfc-ed@ISI.EDU, disman@dorothy.bmc.com Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Thu, 07 Dec 2000 17:28:14 -0800 From: RFC Editor Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list --NextPart A new Request for Comments is now available in online RFC libraries. RFC 3014 Title: Notification Log MIB Author(s): R. Kavasseri, Editor Status: Standards Track Date: November 2000 Mailbox: ramk@cisco.com Pages: 26 Characters: 48287 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-disman-notif-log-mib-17.txt URL: ftp://ftp.isi.edu/in-notes/rfc3014.txt This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for logging Simple Network Management Protocol (SNMP) Notifications. This document is a product of the Distributed Management Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <001207171533.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3014 --OtherAccess Content-Type: Message/External-body; name="rfc3014.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <001207171533.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- From owner-disman@dorothy.bmc.com Thu Dec 7 21:05:24 2000 Received: from tattler.bmc.com (fw-us-hou-1.bmc.com [198.207.223.250]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA02750 for ; Thu, 7 Dec 2000 21:05:23 -0500 (EST) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id eB81rxo06023; Thu, 7 Dec 2000 19:53:59 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id RAA12721 for disman-list; Thu, 7 Dec 2000 17:54:29 -0800 (PST) Received: from creeper.bmc.com (creeper.bmc.com [172.17.1.166]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id RAA12716 for ; Thu, 7 Dec 2000 17:54:24 -0800 (PST) Received: from ec03-hou.bmc.com (localhost [127.0.0.1]) by creeper.bmc.com (8.10.2/8.10.2) with ESMTP id eB81t6T26795 for ; Thu, 7 Dec 2000 19:55:06 -0600 (CST) Received: by ec03-hou.bmc.com with Internet Mail Service (5.5.2650.21) id ; Thu, 7 Dec 2000 19:55:02 -0600 Message-ID: From: "Golovinsky, Eugene" To: "'disman@dorothy.bmc.com'" Subject: RE: Proposed disman charter addition: alarm tracking Date: Thu, 7 Dec 2000 19:55:38 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" X-MIME-Autoconverted: from quoted-printable to 8bit by dorothy.bmc.com id RAA12717 Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list X-MIME-Autoconverted: from 8bit to quoted-printable by tattler.bmc.com id eB81rxo06023 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id VAA02750 Hi. I support the proposal to add Active Alarm work to the charter. I absolutely convinced that this work is crucial. My only concern is that the delivery dates are a bit too aggressive. Thanks. Eugene Golovinsky BMC Software, Inc. SNMP Technology Group eugene_golovinsky@bmc.com Voice: (713)-9181816 Mobile: (713)-8598281 >-----Original Message----- >From: Randy Presuhn [mailto:rpresuhn@dorothy.bmc.com] >Sent: Wednesday, November 29, 2000 12:05 PM >To: disman@dorothy.bmc.com >Subject: Proposed disman charter addition: alarm tracking > > > >Hi - > >Several people have read Sharon's draft and made substantive >comments to this list. As working group chair, I'd like to >determine whether we have a consensus to request of our ADs >that this deliverable be added to our charter. (The work >falls squarely within the existing scope of the charter, >in my opinion, so the only real question in my mind is >whether we have sufficient commitment in the group to >deliver a standards-track document.) > >We should have one-or-two line description of the deliverables >and dates. Here's a strawman, pulled out of the air: > > April, 2001: WG last call on Alarm Management MIB > > May, 2001: Alarm Management MIB delivered to IESG for > consideration as proposed standard. > >Sharon would be my choice as the document's editor. > >Are these dates reasonable? For example, should the scope >be expanded to include interworking with some non-SNMP >technologies? > > ------------------------------------------------------- > Randy Presuhn randy_presuhn@bmc.com > Voice: +1 408 546-1006 BMC Software, Inc. 1-3141 > Fax: +1 408 965-0359 2141 North First Street > http://www.bmc.com/ San José, California 95131 USA > ------------------------------------------------------- > My opinions and BMC's are independent variables. > ------------------------------------------------------- > From owner-disman@dorothy.bmc.com Fri Dec 8 18:30:43 2000 Received: from tattler.bmc.com (fw-us-hou-2.bmc.com [198.207.223.251]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA02583 for ; Fri, 8 Dec 2000 18:30:42 -0500 (EST) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id eB8NMID04541; Fri, 8 Dec 2000 17:22:18 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id PAA20916 for disman-list; Fri, 8 Dec 2000 15:20:05 -0800 (PST) Received: from creeper.bmc.com (creeper.bmc.com [172.17.1.166]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id PAA20911 for ; Fri, 8 Dec 2000 15:20:01 -0800 (PST) Received: from ec02-hou.bmc.com (localhost [127.0.0.1]) by creeper.bmc.com (8.10.2/8.10.2) with ESMTP id eB8NKTC19953; Fri, 8 Dec 2000 17:20:29 -0600 (CST) Received: by EC02-HOU.bmc.com with Internet Mail Service (5.5.2650.21) id ; Fri, 8 Dec 2000 17:20:42 -0600 Message-ID: From: "Ayers, Mike" To: "'David T. Perkins'" , disman@dorothy.bmc.com Subject: RE: Proposed disman charter addition: alarm tracking Date: Fri, 8 Dec 2000 17:23:04 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list > From: David T. Perkins [mailto:dperkins@dsperkins.com] > How to use MIB objects and notifications was to be covered by > book authors. So far, little has been published. Should this > burden be pushed back to RFC authors? Well, not completely, but > there needs to be a more than just the object and notification > definitions except for really simple MIB modules. Since performance > is important with this MIB module, some ammount of implementation > strategy needs to be covered in the RFC (and alot more on the > WG mailing list). To put it another way, the WG remains responsible for the vision behind the RFC. Since noone else has jumped in yet, I'd like to take the first whack at clarifying what alarms are and how they ought to be used. Grab the ammo, folks, it's open season! 1.) Alarms are a device's statement of its own current problems. 2.) Alarms are not traps. Traps are not alarms. The two may be used in a complementary fashion, but this is not required. 3.) The Alarm MIB should be maintained by the device posting the alarms or by a device which directly or indirectly polls such devices for information. The Alarm MIB must not be maintained by gathering information from notifications, since that is the function of the Notification Log MIB. 4.) The alarm model is best used for situations where many uncoordinated monitors and/or managers are used upon a pool of devices, since the managed device does not need to be configured for each node which wants the information, only for the users or user groups that will have access. I think that's enough to start. You may notice (I did) that the raise/clear mechanism doesn't fit very neatly into my vision. In truth, I'm not sure what the raise/clear is for. Could someone be so kind as to enlighten? /|/|ike From owner-disman@dorothy.bmc.com Sun Dec 10 12:16:20 2000 Received: from tattler.bmc.com (fw-us-hou-2.bmc.com [198.207.223.251]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA04549 for ; Sun, 10 Dec 2000 12:16:19 -0500 (EST) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id eBAHBeo21312; Sun, 10 Dec 2000 11:11:41 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id JAA02357 for disman-list; Sun, 10 Dec 2000 09:09: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 JAA02352 for ; Sun, 10 Dec 2000 09:09:11 -0800 (PST) Received: from fw-us-hou1.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with SMTP id eBAH8DY21017 for ; Sun, 10 Dec 2000 11:08:16 -0600 (CST) Received: from public.szptt.net.cn([202.96.136.222]) by public.szptt.net.cn(JetMail 2.5.3.0) with SMTP id jm83a33eecb; Sun, 10 Dec 2000 17:03:48 -0000 Received: from loki.ietf.org([132.151.1.177]) by public.szptt.net.cn(JetMail 2.5.3.0) with SMTP id jm43a304dbd; Fri, 8 Dec 2000 02:54:21 -0000 Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id UAA03138 for ietf-123-outbound.01@ietf.org; Thu, 7 Dec 2000 20:35:00 -0500 (EST) Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id UAA03098 for ; Thu, 7 Dec 2000 20:28:19 -0500 (EST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA24073 for ; Thu, 7 Dec 2000 20:28:18 -0500 (EST) Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by boreas.isi.edu (8.9.3/8.9.3) with ESMTP id RAA15815; Thu, 7 Dec 2000 17:28:14 -0800 (PST) Message-Id: <200012080128.RAA15815@boreas.isi.edu> To: IETF-Announce: ; Subject: RFC 3014 on Notification Log MIB Cc: rfc-ed@ISI.EDU, disman@dorothy.bmc.com Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Thu, 07 Dec 2000 17:28:14 -0800 From: RFC Editor Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list --NextPart A new Request for Comments is now available in online RFC libraries. RFC 3014 Title: Notification Log MIB Author(s): R. Kavasseri, Editor Status: Standards Track Date: November 2000 Mailbox: ramk@cisco.com Pages: 26 Characters: 48287 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-disman-notif-log-mib-17.txt URL: ftp://ftp.isi.edu/in-notes/rfc3014.txt This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for logging Simple Network Management Protocol (SNMP) Notifications. This document is a product of the Distributed Management Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <001207171533.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3014 --OtherAccess Content-Type: Message/External-body; name="rfc3014.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <001207171533.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- From owner-disman@dorothy.bmc.com Sun Dec 10 19:58:20 2000 Received: from tattler.bmc.com (fw-us-hou-1.bmc.com [198.207.223.250]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA22902 for ; Sun, 10 Dec 2000 19:58:19 -0500 (EST) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id eBB0p7u27760; Sun, 10 Dec 2000 18:51:07 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id QAA02928 for disman-list; Sun, 10 Dec 2000 16:50:47 -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 QAA02923 for ; Sun, 10 Dec 2000 16:50:43 -0800 (PST) Received: from fw-us-hou1.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with SMTP id eBB0nmo27623 for ; Sun, 10 Dec 2000 18:49:48 -0600 (CST) Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com; Sun, 10 Dec 2000 19:51:25 -0500 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2652.35) id ; Sun, 10 Dec 2000 19:51:27 -0500 Message-ID: <6DDA62170439D31185750000F80826AC04A72B4A@zmerd004.ca.nortel.com> From: "Sharon Chisholm" To: "Ayers, Mike" , disman@dorothy.bmc.com Subject: RE: draft-chisholm-disman-active-alarm-01.txt Date: Sun, 10 Dec 2000 19:51:22 -0500 X-Mailer: Internet Mail Service (5.5.2652.35) X-Orig: Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list hi My original concern was cluttering a joint generic and ITU specific MIB with the more rarely used ITU fields. If we are splitting things into the two MIBs, then that leaves more room to be more ITUish and add the extra security parameters. Sharon -----Original Message----- From: Ayers, Mike [mailto:Mike_Ayers@bmc.com] Sent: Tuesday, December 05, 2000 10:41 PM To: Chisholm, Sharon [CAR:5K32:EXCH]; disman@dorothy.bmc.com Subject: RE: draft-chisholm-disman-active-alarm-01.txt > From: Sharon Chisholm [mailto:schishol@nortelnetworks.com] > > Comments in-line. > > >-----Original Message----- > >From: Ayers, Mike [mailto:Mike_Ayers@bmc.com] > > > >> From: Sharon Chisholm [mailto:schishol@nortelnetworks.com] > >> > >> These seem to apply to only a small subset of alarms. Wouldn't it > >> then be better to go with the option you also suggested of just > >> having them as varbinds in the trap, and therefore present in the > >> alarmActiveVariablesTable? > > > > Actually, I think they apply to about half the alarms, > since my copy > >of X.736 states that they are mandatory for all security > alarms. Does > yours > >read the same (mine is not a final copy, unfortunately)? > > That is how mine reads, but I would think that security > alarms would not be > that big of a percentage of the alarms a system has. Do you > really see it > being as much as half? I was thinking closer to 5%. It all depends on how you do the counting. You can count the two major alarm groups, application and security, and get 50%. You can count the number of alarm types and get ~50%. You can count the number of individual alarms actually posted on deployed systems and get a number (hopefully) vastly smaller than 5%. Finally (I think this is the important one), you can count the number of deployed ITU alarm systems which use the security objects (my terminology may be slipping, I don't have the ITU specs handy) and get a percentage I cannot even guess at. > > I don't object to these objects being in the > >alarmActiveVariablesTable, but I do think that there should > be objects > >defined specifically for them somewhere in the Active Alarm > MIB so that > they > >can be identified as such. > Maybe, I think this depends on the percentage of traps that > would actually > use these parameters. I don't see why. Perhaps you misunderstand my suggestion. I am looking for something like: alarmStandardObjects OBJECT IDENTIFIER ::= { alarm 3 } alarmStandardObjectsSecurityAlarmDetector OBJECT-TYPE SYNTAX OCTET STRING MAX-ACCESS not-accessible STATUS current DESCRIPTION "The detector of the current security alarm." alarmStandardObjectsServiceUser OBJECT-TYPE SYNTAX OCTET STRING MAX-ACCESS not-accessible STATUS current DESCRIPTION "The user of the currently alarmed service." alarmStandardObjectsServiceProvider OBJECT-TYPE SYNTAX OCTET STRING MAX-ACCESS not-accessible STATUS current DESCRIPTION "The provider of the service currently experiencing security alarm." This would allow objects to be mapped into the Alarm MIB from ITU tables and vice versa. Without them, there can be no transformation with the ITU tables. Note that they are not accessible, since it is only their OIDs that we would make use of. > >> PS. I send explicitly as plain text, it just arrive as > html. Network > >> Gremlins. > >> > > > > Some network admin is doing us a "favor", isn't that sweet? > > > I'm trying something new. Let me know if it's better or worse. Very nice, thank you! Nothin' but text! /|/|ike From owner-disman@dorothy.bmc.com Sun Dec 10 20:15:22 2000 Received: from tattler.bmc.com (fw-us-hou-2.bmc.com [198.207.223.251]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA24794 for ; Sun, 10 Dec 2000 20:15:21 -0500 (EST) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id eBB196O29360; Sun, 10 Dec 2000 19:09:06 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id RAA02967 for disman-list; Sun, 10 Dec 2000 17:09: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 RAA02962 for ; Sun, 10 Dec 2000 17:09:16 -0800 (PST) Received: from fw-us-hou1.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with SMTP id eBB18LV29303 for ; Sun, 10 Dec 2000 19:08:21 -0600 (CST) Received: from zcard015.ca.nortel.com by zcars04e.ca.nortel.com; Sun, 10 Dec 2000 20:09:49 -0500 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2652.35) id ; Sun, 10 Dec 2000 20:09:50 -0500 Message-ID: <6DDA62170439D31185750000F80826AC04A72B56@zmerd004.ca.nortel.com> From: "Sharon Chisholm" To: "Ayers, Mike" , "'David T. Perkins'" , disman@dorothy.bmc.com Subject: RE: Proposed disman charter addition: alarm tracking Date: Sun, 10 Dec 2000 20:09:44 -0500 X-Mailer: Internet Mail Service (5.5.2652.35) X-Orig: Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list hi Randy's algorithm sounds like it passes my "consistent and predictable" test, but I still say there is a lot of value in being consistent with the Notification Log MIB. As your algorithm indicated, the Notification Log MIB structure can be used quite efficiently and you don't have to go anywhere near the non-existent objects. The consistency between the two MIBs doesn't just make my management software simpler, but it also makes things easier for the agent people as well. Sharon -----Original Message----- From: Ayers, Mike [mailto:Mike_Ayers@bmc.com] Sent: Thursday, December 07, 2000 12:03 PM To: 'David T. Perkins'; disman@dorothy.bmc.com Subject: RE: Proposed disman charter addition: alarm tracking > From: David T. Perkins [mailto:dperkins@dsperkins.com] > On the other hand, I believe the > ITU-T documents on which the Sharon's MIB is a based are > "fatally flawed", Really? How many telco workers have we lost so far? > and these flaws are carried forward in Sharon's document. > Additionally, the approach that is used to implement a union, > which is a reuse of a design pattern used in other disman MIB > modules, has very bad performance characteristics for bulk > retrieval. The problem of storing typed data of arbitrary type is not new, and so far, no elegant solution has emerged. There are two general solutions to the problem. Either one can create a union by using the OPAQUE primitive, or one can create a list of all possible types and a type discriminator for that list, as has been done in the Alarm and Notification Log MIBs. I have not seen the former employed, which is probably good, since it merely dumps the type problem on the manager. The latter solution is not quite as inefficient as it first appears, at least with respect to network bandwidth. Consider the following algorithm. First, using getbulk, walk alarmActiveVariableID. Copy the IDs into the name fields of two varbindlist structures, result and valueRetrieval. In the valueRetrieval structure, change 2 to 3 in the last field before the index so that alarmActiveVariableID.index becomes alarmActiveVariableType.index. Perform a get with this structure, but don't dispose of it. When the response comes back, copy the value for each varbind plus 3 into the last field before the index (e.g. if the alarmActiveVariableValueType is counter32(1), then change 3 to 4 (1+3) in the last field before the index to make alarmActiveVariableValueType.index into alarmActiveVariableCounter32Val.index). Perform another get. Copy the values into the corresponding value fields of the result structure. Delete the valueRetrieval structure. The result structure now contains the complete varbind list of the alarm. This method would be only 50% slower than an implementation that used OPAQUE. While it requires three requests to complete, it retrieves only required variables, and the multiple requests should be negligible overhead once the number of variables involved gets significant. There is another alternative that I have seen, but I do not consider it to be a good idea, therefore I hesitate to mention it. The SNMPconf Policy Management MIB contains a pmTrackingElementToPolicyTable whose objects don't appear unless they have a nonzero value. I consider such "magic MIBs" to be bad SNMP. Finally, Randy Presuhn showed me a way to retrieve N stored arbitrary varbinds in 2N varbind fetches, but it would require significant modifications to the existing MIB. In brief, tables would exist for each supported variable type, and there would be a table for retrieving the name (ID) of the each varbind, indexed by {alarmListName, alarmActiveIndex, alarmActiveVariableIndex, alarmActiveVariableValueType}. This way, when retrieving the ID of the varbind, you get the type number as bonus! Now, just look in the table for storing the given data type, also indexed by {alarmListName, alarmActiveIndex, alarmActiveVariableIndex}, and there is your varbind's value. This method has the added bonus of requiring storage for only those variables actually stored. If it is believed that large alarm tables will be maintained, then I would recommend this method. > Before the MIB module > should be written, the model needs to be described, which > has not been done in the contribution. This is really needed > due to differing uses of the "alarm" (and associated) terminology > and differing alarm models by vendors. Absolutely. A thread should be started for this. Sharon? /|/|ike From owner-disman@dorothy.bmc.com Mon Dec 11 01:52:28 2000 Received: from tattler.bmc.com (fw-us-hou-2.bmc.com [198.207.223.251]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA02191 for ; Mon, 11 Dec 2000 01:52:28 -0500 (EST) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id eBB6lps01834; Mon, 11 Dec 2000 00:47:51 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id WAA03435 for disman-list; Sun, 10 Dec 2000 22:47: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 WAA03430 for ; Sun, 10 Dec 2000 22:47:11 -0800 (PST) Received: from fw-us-hou1.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with SMTP id eBB6kG301677 for ; Mon, 11 Dec 2000 00:46:16 -0600 (CST) Received: by itc-eml2.lannet.com with Internet Mail Service (5.5.2650.21) id ; Mon, 11 Dec 2000 08:47:43 +0200 Message-ID: <15F58915DF84D311AC7D0090279AA6141D70FC@itc-eml2.lannet.com> From: Dan Romascanu To: "Ayers, Mike" , "'David T. Perkins'" , disman@dorothy.bmc.com Subject: RE: Proposed disman charter addition: alarm tracking Date: Mon, 11 Dec 2000 08:47:42 +0200 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 Mike, > 3.) The Alarm MIB should be maintained by the device posting the > alarms or by a device which directly or indirectly polls such devices for > information. The Alarm MIB must not be maintained by gathering > information > from notifications, since that is the function of the Notification Log > MIB. > [Dan] I am not sure that I can agree with you on this - at least not at this stage. I think we need to invest some more thinking in how mechanism of gathering alarms are to be reflected in this MIB (or maybe not). During this process we need to clarify relationship with Notification Log MIB. > I think that's enough to start. You may notice (I did) that the > raise/clear mechanism doesn't fit very neatly into my vision. In truth, > I'm > not sure what the raise/clear is for. Could someone be so kind as to > enlighten? > [Dan] The issue is of keeping states of alarms within the device. The concepts of raise and clear are a very simple formalization of these states, which in my opinion works in most of the cases. We need to consider if this needs to be reflected in the MIB and where - especially if we separate the model independent and model dependent alarm MIB modules. Note also some text in Sharon's draft about alarms management and aging within the device. Regards, Dan > /|/|ike From owner-disman@dorothy.bmc.com Mon Dec 11 18:07:20 2000 Received: from tattler.bmc.com (fw-us-hou-2.bmc.com [198.207.223.251]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA27081 for ; Mon, 11 Dec 2000 18:07:19 -0500 (EST) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id eBBMsYE24811; Mon, 11 Dec 2000 16:54:35 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id OAA04865 for disman-list; Mon, 11 Dec 2000 14:53:49 -0800 (PST) Received: from creeper.bmc.com (creeper.bmc.com [172.17.1.166]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id OAA04860 for ; Mon, 11 Dec 2000 14:53:45 -0800 (PST) Received: from ec03-hou.bmc.com (localhost [127.0.0.1]) by creeper.bmc.com (8.10.2/8.10.2) with ESMTP id eBBMsE424033; Mon, 11 Dec 2000 16:54:14 -0600 (CST) Received: by ec03-hou.bmc.com with Internet Mail Service (5.5.2650.21) id ; Mon, 11 Dec 2000 16:54:06 -0600 Message-ID: From: "Golovinsky, Eugene" To: "'Dan Romascanu'" , "Ayers, Mike" , "'David T. Perkins'" , disman@dorothy.bmc.com Subject: RE: Proposed disman charter addition: alarm tracking Date: Mon, 11 Dec 2000 16:54:47 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list Dan, Mike. Let me see if I understood this correctly. The idea of active alarm table is to keep track of the sate of the device. I agree with that approach and with you Dan where you define "alarm" state. However, device could be not only in "Alarm", but also in "Warning" and "OK" conditions. Sure, we could have more state definitions or we could introduce the notion of severity to get more granularity within single state. As far as relation to the Notification Log, I think the State or State change in particular may (or may not, it should be a property of the particular state entry) result in the record in the Notification table. That creates some loose relationship, which I think is sufficient. One more thing, I do not think that we should be limiting ourselves by speaking only about "devices". Let's rather use "system", where system could be hardware, software or combination of the two entities. Any system has states. Thanks, --Eugene Eugene Golovinsky BMC Software, Inc. SNMP Technology Group eugene_golovinsky@bmc.com Voice: (713)-9181816 Mobile: (713)-8598281 >-----Original Message----- >From: Dan Romascanu [mailto:dromasca@avaya.com] >Sent: Monday, December 11, 2000 12:48 AM >To: Ayers, Mike; 'David T. Perkins'; disman@dorothy.bmc.com >Subject: RE: Proposed disman charter addition: alarm tracking > > > >Mike, > >> 3.) The Alarm MIB should be maintained by the device >posting the >> alarms or by a device which directly or indirectly polls >such devices for >> information. The Alarm MIB must not be maintained by gathering >> information >> from notifications, since that is the function of the >Notification Log >> MIB. >> > [Dan] I am not sure that I can agree with you on this >- at least >not at this stage. I think we need to invest some more thinking in how >mechanism of gathering alarms are to be reflected in this MIB (or maybe >not). During this process we need to clarify relationship with >Notification >Log MIB. > > >> I think that's enough to start. You may notice (I did) that the >> raise/clear mechanism doesn't fit very neatly into my >vision. In truth, >> I'm >> not sure what the raise/clear is for. Could someone be so kind as to >> enlighten? >> > [Dan] The issue is of keeping states of alarms within >the device. >The concepts of raise and clear are a very simple >formalization of these >states, which in my opinion works in most of the cases. We >need to consider >if this needs to be reflected in the MIB and where - especially if we >separate the model independent and model dependent alarm MIB modules. > > Note also some text in Sharon's draft about alarms >management and >aging within the device. > > Regards, > > Dan > >> /|/|ike > From owner-disman@dorothy.bmc.com Tue Dec 19 14:55:38 2000 Received: from tattler.bmc.com (fw-us-hou-1.bmc.com [198.207.223.250]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA23189 for ; Tue, 19 Dec 2000 14:55:37 -0500 (EST) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id eBJJfBr07121; Tue, 19 Dec 2000 13:41:12 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id LAA28463 for disman-list; Tue, 19 Dec 2000 11:38:46 -0800 (PST) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id LAA28457 for disman@dorothy.bmc.com; Tue, 19 Dec 2000 11:38:43 -0800 (PST) Date: Tue, 19 Dec 2000 11:38:43 -0800 (PST) From: Randy Presuhn Message-Id: <200012191938.LAA28457@dorothy.bmc.com> To: disman@dorothy.bmc.com Subject: Re: Comments on RFC 2591 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 X-MIME-Autoconverted: from 8bit to quoted-printable by tattler.bmc.com id eBJJfBr07121 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id OAA23189 Hi - I haven't seen any replies to Frank's follow-up question. Any thoughts? Personally, I think his "just once" interpretation is reasonable. ------------------------------------------------------- Randy Presuhn randy_presuhn@bmc.com Voice: +1 408 546-1006 BMC Software, Inc. 1-3141 Fax: +1 408 965-0359 2141 North First Street http://www.bmc.com/ San José, California 95131 USA ------------------------------------------------------- My opinions and BMC's are independent variables. ------------------------------------------------------- > From: Frank Strauss > To: disman@dorothy.bmc.com > Subject: Re: Comments on RFC 2591 > References: > Date: 04 Dec 2000 16:09:23 +0100 > In-Reply-To: Frank Strauss's message of "30 Nov 2000 16:12:59 +0100" > Message-ID: > List-Id: IETF disman Working Group mailing list > > > Another question/comment on RFC 2591: > > 5. Section 3.4. describes a model of two kinds of time transitions, > those that cause ambiguous times and those that cause non-existent > times. On time transitions that cause non-existent times, the text > says: > > When an action is configured in the Schedule MIB to occur at a > nonexistent time, the action SHOULD be invoked immediately upon a > time transition. If multiple actions are invoked in this way, they > SHALL be invoked in the order in which they normally would be invoked > had the time transition not occured. For example, if an action (a) is > scheduled at 2:05 am and another action (b) at 2:10 am, then both > actions SHOULD be invoked at 3:00 am in the order (a),(b) if the time > jumps forward from 2:00 am to 3:00 am. > > This example talks about two distinct actions (thus described by > two separate schedules). But how about a single action of a single > schedule that would be invoked multiple times during a single > `period of non-existent time ;-)'? Assume you have a schedEntry > like this: > > schedType = periodic > schedWeekDay = sunday > schedDay = d29 > schedMonth = oct > schedHour = 2 > schedMinute = m0 + m1 + ... + m58 + m59 > > Would the action of this schedule have been invoked 60 times at > 3 o'clock right after the end of the daylight savings period? Or > would it have been invoked just once? > > I think there could be reasons for both models, but I see more > value in having it invoked just once. > > However, I believe the text should be clearer at this point. > From owner-disman@dorothy.bmc.com Tue Dec 19 15:21:28 2000 Received: from tattler.bmc.com (fw-us-hou-2.bmc.com [198.207.223.251]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA23675 for ; Tue, 19 Dec 2000 15:21:28 -0500 (EST) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id eBJKHUw17369; Tue, 19 Dec 2000 14:17:31 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id MAA28677 for disman-list; Tue, 19 Dec 2000 12:18:03 -0800 (PST) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id MAA28669; Tue, 19 Dec 2000 12:17:58 -0800 (PST) Date: Tue, 19 Dec 2000 12:17:58 -0800 (PST) From: Randy Presuhn Message-Id: <200012192017.MAA28669@dorothy.bmc.com> To: disman@dorothy.bmc.com Subject: Fwd: CFP: ACM MobiCom 2001 Cc: dawn@eecs.wsu.edu 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 X-MIME-Autoconverted: from 8bit to quoted-printable by tattler.bmc.com id eBJKHUw17369 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id PAA23675 Hi - I'm forwarding a non-subscriber posting to the disman working group mailing list. Subscription instructions are at http://www.ietf.org/html.charters/disman-charter.html ------------------------------------------------------- Randy Presuhn randy_presuhn@bmc.com Voice: +1 408 546-1006 BMC Software, Inc. 1-3141 Fax: +1 408 965-0359 2141 North First Street http://www.bmc.com/ San José, California 95131 USA ------------------------------------------------------- My opinions and BMC's are independent variables. ------------------------------------------------------- > Received: from 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 LAA28497 > for ; Tue, 19 Dec 2000 11:55:08 -0800 (PST) > Received: from fw-us-hou1.bmc.com (localhost [127.0.0.1]) > by tattler.bmc.com (8.10.2/8.10.2) with SMTP id eBJJs3k10287 > for ; Tue, 19 Dec 2000 13:54:04 -0600 (CST) > Received: from carmel.eecs.wsu.edu (IDENT:root@carmel.eecs.wsu.edu [199.237.72.81]) by thalia.eecs.wsu.edu with ESMTP (8.9.3/) > id LAA23588 for ; Tue, 19 Dec 2000 11:53:02 -0800 (PST) > From: "DAWN Research Lab - Dr. Sivalingam" > Received: (from dawn@localhost) by carmel.eecs.wsu.edu (8.9.3/) > id LAA11271 for disman@dorothy.peer.com; Tue, 19 Dec 2000 11:53:02 -0800 > Message-Id: <200012191953.LAA11271@carmel.eecs.wsu.edu> > Subject: CFP: ACM MobiCom 2001 > To: disman@dorothy.bmc.com > Date: Tue, 19 Dec 2000 11:53:02 -0800 (PST) > X-Mailer: ELM [version 2.5 PL3] > MIME-Version: 1.0 > Content-Type: text/plain; charset=us-ascii > Content-Transfer-Encoding: 7bit > > > Enclosed below please find a Preliminary Announcement and Call for > Papers for the 7th Annual International Conference on Mobile Computing > and Networking (MobiCom) to be held in Rome, Italy from July 16-21, > 2001. > > As you might already know, MobiCom has an established reputation as > the pre-eminent conference in this area owing to the exceptionally > high quality of papers, excellent tutorials and workshops, and > stimulating panels conducted by mobile computing illuminati of various > stripes. > > For complete information about the upcoming conference, please visit: > http://www.research.ibm.com/mobicom2001/ > > A printer friendly version of this CFP is available at: > > http://www.eecs.wsu.edu/~krishna/Mobicom2001-onepagecfp.pdf (PDF) > http://www.eecs.wsu.edu/~krishna/Mobicom2001-onepagecfp.ps (PS) > > We apologize if you received multiple copies of this Call for Papers. > Please feel free to distribute it to those who might be interested. > > Very truly yours, > > ACM SIGMOBILE MobiCom 2001 Organizing Committee > > *********************************************************************** > Preliminary Announcement and Call for Papers > > *** ACM MobiCom 2001 *** > > The Seventh Annual International Conference on > Mobile Computing and Networking > > July 16-21, Rome, Italy > > Sponsored by ACM SIGMOBILE > > http://www.research.ibm.com/mobicom2001/ > http://www.acm.org/sigmobile/ > > Submission Deadline: January 12, 2001 > *********************************************************************** > > PAPERS: > > Technical papers (maximum 15 pages) describing original, previously > unpublished, completed research, not currently under review by another > conference or journal, are solicited on the following topics: > > * Applications and computing services supporting mobile users > * Architectures, protocols, and algorithms to cope with mobility, > limited bandwidth, or intermittent connectivity > * Database and data management issues in mobile computing > * Performance of mobile/wireless networks and systems > * Security and privacy of mobile/wireless systems > * Interaction between different layers of mobile/wireless systems > * Integration and interworking of wired and wireless networks > * Adaptive applications and systems for mobile environments > * Distributed-system aspects of mobile systems > * Operating system support for mobility > * Location-dependent applications > * Wireless multimedia systems > * Power management > * Mobile agents > * Pervasive computing > * Wireless sensor networks > * Wireless/mobile service management and delivery > > All papers will be refereed by the program committee. Accepted papers > will be published in the conference proceedings. Papers of particular > merit will be proposed for publication in the ACM/Baltzer Wireless > Networks (WINET) and Mobile Networks and Applications (MONET) journals. > > Note: Student Registrations will be provided at a discounted rate. > > CHALLENGES SESSION, PANELS, RESEARCH DEMOS, TUTORIALS: > > Short papers (maximum of 8 pages) that challenge the mobile computing > community with new technologies or visionary applications are > solicited. Such papers should provide stimulating ideas or visions > that may open up exciting avenues of mobile computing research. > > Proposals are solicited for panels that examine innovative, > controversial, or otherwise provocative issues of interest. > > Proposals for tutorials are solicited. Tutorial topics that encompass > the systems aspects of mobile computing and/or practical experiences > in building/deploying such systems are of particular interest. > > Informal proposals for research demos are solicited. Proposals should > include: the focus area in mobility, the technologies involved, > specific equipment used, demo layout, space required, etc. > > Please refer to the conference website for submission and other > details. (The paper submission website is READY for submissions now.) > > IMPORTANT DATES: > > * Technical Paper Submissions due: January 12, 2001 > - Please refer to the website for submission instructions > > * Notification of acceptance: May 1, 2001 > * Camera-ready version due: May 15, 2001 > > * Challenges Session Papers, Panel Proposals, Tutorial Proposals > Submissions due: January 12, 2001 > - Please refer to the website for submission instructions > > > FOR MORE INFORMATION: > > Send email to mobicom2001@winlab.rutgers.edu with any questions or > comments about the conference or for more information. > > ORGANIZING COMMITTEE: > > * General Chair: * Tutorials Co-Chairs: > > Christopher Rose Ravi Jain > Rutgers University, WINLAB Telcordia Technologies > > * General Vice Chair: Chiara Petrioli > Politecnico di Milano > Sergio Palazzo > Universita` di Catania * Panels Chair: > > * Program Co-Chairs: Ramesh Rao > Univ. of California, San Diego > Mahmoud Naghshineh > IBM T.J. Watson Research Center * Local Arrangement Chair: > > Michele Zorzi Marco Listanti > Universita` di Ferrara Universita` di Roma "La Sapienza" > > * Finance Chair: Chiara Petrioli > Politecnico di Milano > David B. Johnson > Rice University > > * Registration Chair: * Exhibits/Sponsorships Chair: > > Irene Katzela Marco Ajmone Marsan > Lucent Technologies Politecnico di Torino > > * Publicity Co-Chairs: * Research Demos Chair: > > Stefano Basagni Nigel Davies > Univ. of Texas at Dallas Lancaster University > > Krishna Sivalingam * Steering Committee Chair: > Washington State University > Imrich Chlamtac > Univ. of Texas at Dallas > > *********************************************************************** > > > > From owner-disman@dorothy.bmc.com Wed Dec 27 19:18:16 2000 Received: from tattler.bmc.com (fw-us-hou-2.bmc.com [198.207.223.251]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA26648 for ; Wed, 27 Dec 2000 19:18:16 -0500 (EST) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id eBS0Djd22451; Wed, 27 Dec 2000 18:13:45 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id QAA04050 for disman-list; Wed, 27 Dec 2000 16:12:20 -0800 (PST) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id QAA04044 for disman@dorothy.bmc.com; Wed, 27 Dec 2000 16:12:17 -0800 (PST) Date: Wed, 27 Dec 2000 16:12:17 -0800 (PST) From: Randy Presuhn Message-Id: <200012280012.QAA04044@dorothy.bmc.com> To: disman@dorothy.bmc.com Subject: X.733 et alia fatally flawed? 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 X-MIME-Autoconverted: from 8bit to quoted-printable by tattler.bmc.com id eBS0Djd22451 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id TAA26648 Hi - > Message-Id: <4.1.20001129153932.00be6a10@mail.scruznet.com> > Date: Wed, 29 Nov 2000 16:20:37 -0800 > To: Randy Presuhn , disman@dorothy.bmc.com > From: "David T. Perkins" > Subject: Re: Proposed disman charter addition: alarm tracking > In-Reply-To: <200011292004.MAA09159@dorothy.bmc.com> > List-Id: IETF disman Working Group mailing list ... > On one hand, the need for a MIB covering this subject area is great > and is a topic that is reoccuring on several of the SNMP mailing > lists and the SNMP news group. I'm glad we'll have your support! > On the other hand, I believe the > ITU-T documents on which the Sharon's MIB is a based are "fatally flawed", > and these flaws are carried forward in Sharon's document. ... In yet another message, I am going to formally request that work on alarm tracking be added to our charter. The statement of work will only require the WG to "consider existing standards and practices, such as ITU-T X.733" Despite several requests on this list, I have yet to see any any statement of what these allegedly fatal flaws might be. As WG chair, I am requesting that anyone believing there to be such problems post the technical arguments to this list by January 7, 2001. ------------------------------------------------------- Randy Presuhn randy_presuhn@bmc.com Voice: +1 408 546-1006 BMC Software, Inc. 1-3141 Fax: +1 408 965-0359 2141 North First Street http://www.bmc.com/ San José, California 95131 USA ------------------------------------------------------- My opinions and BMC's are independent variables. ------------------------------------------------------- From owner-disman@dorothy.bmc.com Wed Dec 27 19:26:01 2000 Received: from tattler.bmc.com (fw-us-hou-1.bmc.com [198.207.223.250]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA26704 for ; Wed, 27 Dec 2000 19:26:00 -0500 (EST) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id eBS0JLc23632; Wed, 27 Dec 2000 18:19:21 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id QAA04111 for disman-list; Wed, 27 Dec 2000 16:20:11 -0800 (PST) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id QAA04105 for disman@dorothy.bmc.com; Wed, 27 Dec 2000 16:20:08 -0800 (PST) Date: Wed, 27 Dec 2000 16:20:08 -0800 (PST) From: Randy Presuhn Message-Id: <200012280020.QAA04105@dorothy.bmc.com> To: disman@dorothy.bmc.com Subject: Re-open Log MIB for performance? 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 X-MIME-Autoconverted: from 8bit to quoted-printable by tattler.bmc.com id eBS0JLc23632 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id TAA26704 Hi - > Message-Id: <4.1.20001129153932.00be6a10@mail.scruznet.com> > Date: Wed, 29 Nov 2000 16:20:37 -0800 > To: Randy Presuhn , disman@dorothy.bmc.com > From: "David T. Perkins" > Subject: Re: Proposed disman charter addition: alarm tracking > In-Reply-To: <200011292004.MAA09159@dorothy.bmc.com> > List-Id: IETF disman Working Group mailing list ... > Additionally, the approach that is used to implement a union, > which is a reuse of a design pattern used in other disman MIB > modules, has very bad performance characteristics for bulk > retrieval. I believe that after an IETF standards track alarm > MIB module is defined (and the definition allows highly efficient > implementation on an agent system AND low cost useage by management > applications), then this will be the most useful and widely > implemented set of objects! ... Others in this thread have offered a couple of different ways to improve performance, at the cost of compatibility with the existing log MIB in RFC 3014, currently at proposed. As some of you may remember, I have repeatedly stated that I would rule arguments based solely on "progression" of specifications out of order. If we are finding that the structure of the log MIB in RFC 3014 is causing serious efficiency problems, then we should fix it and cycle it at "proposed", rather than blindly progressing it and inflicting its shortcomings on other specifications. So, as chair I ask the WG: do we need to re-open the log MIB to do alarming right? ------------------------------------------------------- Randy Presuhn randy_presuhn@bmc.com Voice: +1 408 546-1006 BMC Software, Inc. 1-3141 Fax: +1 408 965-0359 2141 North First Street http://www.bmc.com/ San José, California 95131 USA ------------------------------------------------------- My opinions and BMC's are independent variables. ------------------------------------------------------- From owner-disman@dorothy.bmc.com Wed Dec 27 19:47:13 2000 Received: from tattler.bmc.com (fw-us-hou-1.bmc.com [198.207.223.250]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA26869 for ; Wed, 27 Dec 2000 19:47:12 -0500 (EST) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id eBS0iBC28129; Wed, 27 Dec 2000 18:44:11 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id QAA04198 for disman-list; Wed, 27 Dec 2000 16:45:00 -0800 (PST) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id QAA04192; Wed, 27 Dec 2000 16:44:57 -0800 (PST) Date: Wed, 27 Dec 2000 16:44:57 -0800 (PST) From: Randy Presuhn Message-Id: <200012280044.QAA04192@dorothy.bmc.com> To: bwijnen@lucent.com Subject: Request for addition to disman WG charter Cc: disman@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 X-MIME-Autoconverted: from 8bit to quoted-printable by tattler.bmc.com id eBS0iBC28129 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id TAA26869 Hi Bert - As disman WG chair, I'd like to formally request the addition of the work on an "Alarm Management MIB" to our charter. I would like Sharon Chisholm and Dan Romascano to serve as the document editors. There appears to be strong consensus in the WG that we should take on this work, and that it would have significant value for the industry. The work on the Alarm MIB will take into consideration existing standards and practices, such as ITU-T X.733. Whether any mappings to these other standards appear in the Alarm MIB or in separate documents will be decided by the WG. The proposed timetable, based on feedback from the WG: January 2001: First WG draft of Alarm Management MIB. February 2001: WG agreement on direction regarding mappings to / from other alarm frameworks. February 2001: Submit updated draft of Alarm MIB for IETF meeting. March 2001: Meet at the 50th IETF in Minneapolis, Minnesota July 2001: Submit updated draft of Alarm MIB for IETF meeting. August 2001: Meet at 51st IETF in London, England August 2001: WG last call on Alarm Management MIB September 2001: Alarm Management MIB delivered to IESG for consideration as proposed standard. Your feedback and comments would be appreciated; let me know when it's OK to forward this to the secretariat. ------------------------------------------------------- Randy Presuhn randy_presuhn@bmc.com Voice: +1 408 546-1006 BMC Software, Inc. 1-3141 Fax: +1 408 965-0359 2141 North First Street http://www.bmc.com/ San José, California 95131 USA ------------------------------------------------------- My opinions and BMC's are independent variables. ------------------------------------------------------- From owner-disman@dorothy.bmc.com Thu Dec 28 03:22:59 2000 Received: from tattler.bmc.com (fw-us-hou-2.bmc.com [198.207.223.251]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA14399 for ; Thu, 28 Dec 2000 03:22:59 -0500 (EST) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id eBS8Hsf11005; Thu, 28 Dec 2000 02:17:54 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id AAA04840 for disman-list; Thu, 28 Dec 2000 00:17:51 -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 AAA04834; Thu, 28 Dec 2000 00:17:46 -0800 (PST) Received: from fw-us-hou1.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with SMTP id eBS8Gg410786; Thu, 28 Dec 2000 02:16:42 -0600 (CST) Received: from itc-eml2.lannet.com (itc-eml2.lannet.com [149.49.38.52]) by warp.lannet.com (8.8.8+Sun/8.8.8) with ESMTP id KAA04973; Thu, 28 Dec 2000 10:27:12 +0200 (IST) Received: by itc-eml2.lannet.com with Internet Mail Service (5.5.2650.21) id ; Thu, 28 Dec 2000 10:18:13 +0200 Message-ID: <15F58915DF84D311AC7D0090279AA614234327@itc-eml2.lannet.com> From: Dan Romascanu To: "'Randy Presuhn'" , bwijnen@lucent.com Cc: disman@dorothy.bmc.com Subject: RE: Request for addition to disman WG charter Date: Thu, 28 Dec 2000 10:18:11 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" X-MIME-Autoconverted: from quoted-printable to 8bit by dorothy.bmc.com id AAA04835 Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list X-MIME-Autoconverted: from 8bit to quoted-printable by tattler.bmc.com id eBS8Hsf11005 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id DAA14399 Randy, As part of the current discussion, we are considering the option of issuing two separate MIB modules - one including the model neutral MIB functions, and the second mappings of the ITU-I X.733 model alarms. If we decide for two documents, I would suggest that the wording in the charter allows to include the second document in the same timeframe as the first one. Regards, Dan > -----Original Message----- > From: Randy Presuhn [SMTP:rpresuhn@dorothy.bmc.com] > Sent: Thu December 28 2000 2:45 > To: bwijnen@lucent.com > Cc: disman@dorothy.bmc.com > Subject: Request for addition to disman WG charter > > > Hi Bert - > > As disman WG chair, I'd like to formally request the addition > of the work on an "Alarm Management MIB" to our charter. I > would like Sharon Chisholm and Dan Romascano to serve as the > document editors. > > There appears to be strong consensus in the WG that we should > take on this work, and that it would have significant value > for the industry. > > The work on the Alarm MIB will take into consideration existing > standards and practices, such as ITU-T X.733. Whether any > mappings to these other standards appear in the Alarm MIB or > in separate documents will be decided by the WG. > > The proposed timetable, based on feedback from the WG: > > January 2001: First WG draft of Alarm Management MIB. > > February 2001: WG agreement on direction regarding mappings > to / from other alarm frameworks. > > February 2001: Submit updated draft of Alarm MIB for IETF meeting. > > March 2001: Meet at the 50th IETF in Minneapolis, Minnesota > > July 2001: Submit updated draft of Alarm MIB for IETF meeting. > > August 2001: Meet at 51st IETF in London, England > > August 2001: WG last call on Alarm Management MIB > > September 2001: Alarm Management MIB delivered to IESG for > consideration as proposed standard. > > Your feedback and comments would be appreciated; let me know > when it's OK to forward this to the secretariat. > > ------------------------------------------------------- > Randy Presuhn randy_presuhn@bmc.com > Voice: +1 408 546-1006 BMC Software, Inc. 1-3141 > Fax: +1 408 965-0359 2141 North First Street > http://www.bmc.com/ San José, California 95131 USA > ------------------------------------------------------- > My opinions and BMC's are independent variables. > ------------------------------------------------------- From owner-disman@dorothy.bmc.com Thu Dec 28 15:25:53 2000 Received: from tattler.bmc.com (fw-us-hou-2.bmc.com [198.207.223.251]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA19022 for ; Thu, 28 Dec 2000 15:25:52 -0500 (EST) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id eBSKNo810235; Thu, 28 Dec 2000 14:23:50 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id MAA05877 for disman-list; Thu, 28 Dec 2000 12:21:02 -0800 (PST) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id MAA05869; Thu, 28 Dec 2000 12:20:58 -0800 (PST) Date: Thu, 28 Dec 2000 12:20:58 -0800 (PST) From: Randy Presuhn Message-Id: <200012282020.MAA05869@dorothy.bmc.com> To: bwijnen@lucent.com Subject: RE: Request for addition to disman WG charter Cc: disman@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 X-MIME-Autoconverted: from 8bit to quoted-printable by tattler.bmc.com id eBSKNo810235 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id PAA19022 Hi - > Message-ID: <15F58915DF84D311AC7D0090279AA614234327@itc-eml2.lannet.com> > From: Dan Romascanu > To: "'Randy Presuhn'" , bwijnen@lucent.com > Cc: disman@dorothy.bmc.com > Subject: RE: Request for addition to disman WG charter > Date: Thu, 28 Dec 2000 10:18:11 +0200 ... > As part of the current discussion, we are considering the option of issuing > two separate MIB modules - one including the model neutral MIB functions, > and the second mappings of the ITU-I X.733 model alarms. If we decide for > two documents, I would suggest that the wording in the charter allows to > include the second document in the same timeframe as the first one. ... I thought I had that covered when I wrote: > > The work on the Alarm MIB will take into consideration existing > > standards and practices, such as ITU-T X.733. Whether any > > mappings to these other standards appear in the Alarm MIB or > > in separate documents will be decided by the WG. ... Does anyone have any ideas how we could make this clearer without committing to two separate documents at this time? ------------------------------------------------------- Randy Presuhn randy_presuhn@bmc.com Voice: +1 408 546-1006 BMC Software, Inc. 1-3141 Fax: +1 408 965-0359 2141 North First Street http://www.bmc.com/ San José, California 95131 USA ------------------------------------------------------- My opinions and BMC's are independent variables. ------------------------------------------------------- From owner-disman@dorothy.bmc.com Thu Dec 28 16:55:24 2000 Received: from tattler.bmc.com (fw-us-hou-2.bmc.com [198.207.223.251]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA19920 for ; Thu, 28 Dec 2000 16:55:24 -0500 (EST) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id eBSLlSo29655; Thu, 28 Dec 2000 15:47:28 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id NAA06512 for disman-list; Thu, 28 Dec 2000 13:47:58 -0800 (PST) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id NAA06506 for disman@dorothy.bmc.com; Thu, 28 Dec 2000 13:47:55 -0800 (PST) Date: Thu, 28 Dec 2000 13:47:55 -0800 (PST) From: Randy Presuhn Message-Id: <200012282147.NAA06506@dorothy.bmc.com> To: disman@dorothy.bmc.com Subject: Fwd: Re: Request for addition to disman WG charter 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 X-MIME-Autoconverted: from 8bit to quoted-printable by tattler.bmc.com id eBSLlSo29655 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id QAA19920 Hi - I'm forwarding a post by Jon. I've added this alternate address to this disman "posters" list. ------------------------------------------------------- Randy Presuhn randy_presuhn@bmc.com Voice: +1 408 546-1006 BMC Software, Inc. 1-3141 Fax: +1 408 965-0359 2141 North First Street http://www.bmc.com/ San José, California 95131 USA ------------------------------------------------------- My opinions and BMC's are independent variables. ------------------------------------------------------- > Received: from 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 NAA06411; > Thu, 28 Dec 2000 13:09:51 -0800 (PST) > Received: from fw-us-hou1.bmc.com (localhost [127.0.0.1]) > by tattler.bmc.com (8.10.2/8.10.2) with SMTP id eBSL8g920014; > Thu, 28 Dec 2000 15:08:47 -0600 (CST) > Received: from europa-h0001027441c5.ne.mediaone.net (sun.ne.mediaone.net [192.168.20.40]) > by h0001027441c5.ne.mediaone.net (8.9.3/8.8.7) with ESMTP id QAA19692; > Thu, 28 Dec 2000 16:10:44 -0500 > Received: from europa (localhost [127.0.0.1]) > by europa-h0001027441c5.ne.mediaone.net (8.9.3+Sun/8.9.3) with ESMTP id PAA20017; > Thu, 28 Dec 2000 15:05:20 -0500 (EST) > Message-Id: <200012282005.PAA20017@europa-h0001027441c5.ne.mediaone.net> > To: Dan Romascanu > cc: "'Randy Presuhn'" , bwijnen@lucent.com, > disman@dorothy.bmc.com > Subject: Re: Request for addition to disman WG charter > From: Jon Saperia > In-reply-to: Your message of Thu, 28 Dec 2000 10:18:11 +0200. > <15F58915DF84D311AC7D0090279AA614234327@itc-eml2.lannet.com> > Date: Thu, 28 Dec 2000 15:05:20 -0500 > Sender: jon@h0001027441c5.ne.mediaone.net > > > > > Randy, > > > > As part of the current discussion, we are considering the option of issuing > > two separate MIB modules - one including the model neutral MIB functions, > > and the second mappings of the ITU-I X.733 model alarms. If we decide for > > two documents, I would suggest that the wording in the charter allows to > > include the second document in the same timeframe as the first one. > > > > Regards, > > > > Dan > > > > Folks, I too believe in the value of a common alarm MIB Module and the > Disman WG is as good a place as any to do it. I am not sure I know what > others had in mind in the paragraphs above. The problem that I would > like addresses is a MIB module that can be used to configure and control > alarm generation from devices that send notification. It can aggregate, > control absolute number of notifications generated per unit time, and a > number of other features. Is that what is meant by the work item? > > Thanks > /jon > > > Jon Saperia saperia@jdscons.com > Phone: 617-744-1079 > Fax: 617-249-0874 > http://www.jdscons.com/ > From owner-disman@dorothy.bmc.com Thu Dec 28 17:17:04 2000 Received: from tattler.bmc.com (fw-us-hou-2.bmc.com [198.207.223.251]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA20143 for ; Thu, 28 Dec 2000 17:17:04 -0500 (EST) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id eBSMAIV05125; Thu, 28 Dec 2000 16:10:18 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id OAA06786 for disman-list; Thu, 28 Dec 2000 14:10:58 -0800 (PST) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id OAA06780 for disman@dorothy.bmc.com; Thu, 28 Dec 2000 14:10:54 -0800 (PST) Date: Thu, 28 Dec 2000 14:10:54 -0800 (PST) From: Randy Presuhn Message-Id: <200012282210.OAA06780@dorothy.bmc.com> To: disman@dorothy.bmc.com Subject: Re: Request for addition to disman WG charter 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 X-MIME-Autoconverted: from 8bit to quoted-printable by tattler.bmc.com id eBSMAIV05125 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id RAA20143 Hi - ... > Message-Id: <200012282005.PAA20017@europa-h0001027441c5.ne.mediaone.net> > To: Dan Romascanu > cc: "'Randy Presuhn'" , bwijnen@lucent.com, > disman@dorothy.bmc.com > Subject: Re: Request for addition to disman WG charter > From: Jon Saperia > In-reply-to: Your message of Thu, 28 Dec 2000 10:18:11 +0200. > <15F58915DF84D311AC7D0090279AA614234327@itc-eml2.lannet.com> > Date: Thu, 28 Dec 2000 15:05:20 -0500 > Sender: jon@h0001027441c5.ne.mediaone.net ... > Folks, I too believe in the value of a common alarm MIB Module and the > Disman WG is as good a place as any to do it. I am not sure I know what > others had in mind in the paragraphs above. The problem that I would > like addresses is a MIB module that can be used to configure and control > alarm generation from devices that send notification. It can aggregate, > control absolute number of notifications generated per unit time, and a > number of other features. Is that what is meant by the work item? ... We're looking at a different problem. The submission that spurred this effort, draft-chisholm-disman-active-alarm-01.txt, "describes management objects used for maintaining a list of alarms currently active on a network element." The problem you're describing sounds more like it belongs in an extension/companion to RFC 2573's SNMP-NOTIFICATION-MIB. I agree that someone should look at it, but it's not on our plate (yet). ------------------------------------------------------- Randy Presuhn randy_presuhn@bmc.com Voice: +1 408 546-1006 BMC Software, Inc. 1-3141 Fax: +1 408 965-0359 2141 North First Street http://www.bmc.com/ San José, California 95131 USA ------------------------------------------------------- My opinions and BMC's are independent variables. ------------------------------------------------------- From owner-disman@dorothy.bmc.com Fri Dec 29 11:35:40 2000 Received: from tattler.bmc.com (fw-us-hou-1.bmc.com [198.207.223.250]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA10472 for ; Fri, 29 Dec 2000 11:35:39 -0500 (EST) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id eBTGQTu02936; Fri, 29 Dec 2000 10:26:30 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id IAA09204 for disman-list; Fri, 29 Dec 2000 08:25: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 IAA09198; Fri, 29 Dec 2000 08:25:51 -0800 (PST) Received: from fw-us-hou1.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with SMTP id eBTGOkx02383; Fri, 29 Dec 2000 10:24:46 -0600 (CST) Received: from itc-eml2.lannet.com (itc-eml2.lannet.com [149.49.38.52]) by warp.lannet.com (8.8.8+Sun/8.8.8) with ESMTP id SAA10806; Fri, 29 Dec 2000 18:35:14 +0200 (IST) Received: by itc-eml2.lannet.com with Internet Mail Service (5.5.2650.21) id ; Fri, 29 Dec 2000 18:26:16 +0200 Message-ID: <15F58915DF84D311AC7D0090279AA61423433D@itc-eml2.lannet.com> From: Dan Romascanu To: "'Randy Presuhn'" , bwijnen@lucent.com Cc: disman@dorothy.bmc.com Subject: RE: Request for addition to disman WG charter Date: Fri, 29 Dec 2000 18:26:15 +0200 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 > Does anyone have any ideas how we could make this clearer without > committing to two separate documents at this time? > [Dan] Wherever you mention 'draft' in the schedules write 'draft(s)' instead. Or is this too 'creative' for a WG Charter? > From owner-disman@dorothy.bmc.com Fri Dec 29 13:36:59 2000 Received: from tattler.bmc.com ([198.207.223.251]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA11414 for ; Fri, 29 Dec 2000 13:36:58 -0500 (EST) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id eBTIWbu00358; Fri, 29 Dec 2000 12:32:37 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id KAA09641 for disman-list; Fri, 29 Dec 2000 10:33:06 -0800 (PST) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id KAA09635; Fri, 29 Dec 2000 10:33:03 -0800 (PST) Date: Fri, 29 Dec 2000 10:33:03 -0800 (PST) From: Randy Presuhn Message-Id: <200012291833.KAA09635@dorothy.bmc.com> To: bwijnen@lucent.com Subject: RE: Request for addition to disman WG charter Cc: disman@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 X-MIME-Autoconverted: from 8bit to quoted-printable by tattler.bmc.com id eBTIWbu00358 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id NAA11414 Hi - > Message-ID: <15F58915DF84D311AC7D0090279AA61423433D@itc-eml2.lannet.com> > From: Dan Romascanu > To: "'Randy Presuhn'" , bwijnen@lucent.com > Cc: disman@dorothy.bmc.com > Subject: RE: Request for addition to disman WG charter > Date: Fri, 29 Dec 2000 18:26:15 +0200 > > > > Does anyone have any ideas how we could make this clearer without > > committing to two separate documents at this time? > > > [Dan] Wherever you mention 'draft' in the schedules write > 'draft(s)' instead. Or is this too 'creative' for a WG Charter? ... I have no problem with it. Bert? ------------------------------------------------------- Randy Presuhn randy_presuhn@bmc.com Voice: +1 408 546-1006 BMC Software, Inc. 1-3141 Fax: +1 408 965-0359 2141 North First Street http://www.bmc.com/ San José, California 95131 USA ------------------------------------------------------- My opinions and BMC's are independent variables. ------------------------------------------------------- From owner-disman@dorothy.bmc.com Fri Dec 29 15:14:19 2000 Received: from tattler.bmc.com ([198.207.223.251]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA12581 for ; Fri, 29 Dec 2000 15:14:18 -0500 (EST) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id eBTK8uQ21647; Fri, 29 Dec 2000 14:09:05 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id MAA10392 for disman-list; Fri, 29 Dec 2000 12:09: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 MAA10386; Fri, 29 Dec 2000 12:09:19 -0800 (PST) Received: from fw-us-hou1.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with SMTP id eBTK8D221471; Fri, 29 Dec 2000 14:08:13 -0600 (CST) Received: from ihemail1.firewall.lucent.com (localhost [127.0.0.1]) by ihemail1.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id PAA05012; Fri, 29 Dec 2000 15:10:05 -0500 (EST) Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail1.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id PAA05003; Fri, 29 Dec 2000 15:10:05 -0500 (EST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2650.21) id ; Fri, 29 Dec 2000 21:10:04 +0100 Message-ID: <2413FED0DFE6D111B3F90008C7FA61FB0A98431D@nl0006exch002u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Randy Presuhn Cc: disman@dorothy.bmc.com, Randy Bush Subject: RE: Request for addition to disman WG charter Date: Fri, 29 Dec 2000 21:10:02 +0100 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 Inline > ---------- > From: Randy Presuhn[SMTP:rpresuhn@dorothy.bmc.com] > Sent: Friday, December 29, 2000 7:33 PM > To: bwijnen@lucent.com > Cc: disman@dorothy.bmc.com > Subject: RE: Request for addition to disman WG charter > > Hi - > > > Message-ID: <15F58915DF84D311AC7D0090279AA61423433D@itc-eml2.lannet.com> > > From: Dan Romascanu > > To: "'Randy Presuhn'" , bwijnen@lucent.com > > Cc: disman@dorothy.bmc.com > > Subject: RE: Request for addition to disman WG charter > > Date: Fri, 29 Dec 2000 18:26:15 +0200 > > > > > > > Does anyone have any ideas how we could make this clearer without > > > committing to two separate documents at this time? > > > > > [Dan] Wherever you mention 'draft' in the schedules write > > 'draft(s)' instead. Or is this too 'creative' for a WG Charter? > ... > > I have no problem with it. Bert? > I don't think that we (IESG members, ADs) really get hung up over the outcome to be in 1 or 2 documents. And so wording to allow for that is OK (but not required ... can be handled while we go as well). Bert From owner-disman@dorothy.bmc.com Fri Dec 29 15:46:19 2000 Received: from tattler.bmc.com ([198.207.223.250]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA12877 for ; Fri, 29 Dec 2000 15:46:18 -0500 (EST) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id eBTKgtV28410; Fri, 29 Dec 2000 14:42:55 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id MAA10651 for disman-list; Fri, 29 Dec 2000 12:43:21 -0800 (PST) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id MAA10645; Fri, 29 Dec 2000 12:43:17 -0800 (PST) Date: Fri, 29 Dec 2000 12:43:17 -0800 (PST) From: Randy Presuhn Message-Id: <200012292043.MAA10645@dorothy.bmc.com> To: bwijnen@lucent.com Subject: RE: Request for addition to disman WG charter Cc: disman@dorothy.bmc.com, randy@psg.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 X-MIME-Autoconverted: from 8bit to quoted-printable by tattler.bmc.com id eBTKgtV28410 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id PAA12877 Hi - > Message-ID: <2413FED0DFE6D111B3F90008C7FA61FB0A98431D@nl0006exch002u.nl.lucent.com> > From: "Wijnen, Bert (Bert)" > To: Randy Presuhn > Cc: disman@dorothy.bmc.com, Randy Bush > Subject: RE: Request for addition to disman WG charter > Date: Fri, 29 Dec 2000 21:10:02 +0100 > List-Id: IETF disman Working Group mailing list ... > I don't think that we (IESG members, ADs) really get hung up over > the outcome to be in 1 or 2 documents. And so wording to allow > for that is OK (but not required ... can be handled while we go as well). ... Ok. So, may we make the addition? ------------------------------------------------------- Randy Presuhn randy_presuhn@bmc.com Voice: +1 408 546-1006 BMC Software, Inc. 1-3141 Fax: +1 408 965-0359 2141 North First Street http://www.bmc.com/ San José, California 95131 USA ------------------------------------------------------- My opinions and BMC's are independent variables. ------------------------------------------------------- From owner-disman@dorothy.bmc.com Sat Dec 30 05:46:42 2000 Received: from tattler.bmc.com ([198.207.223.251]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA01437 for ; Sat, 30 Dec 2000 05:46:41 -0500 (EST) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id eBUAgD319931; Sat, 30 Dec 2000 04:42:13 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id CAA13140 for disman-list; Sat, 30 Dec 2000 02:42:07 -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 CAA13134; Sat, 30 Dec 2000 02:42:02 -0800 (PST) Received: from fw-us-hou1.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with SMTP id eBUAevn19875; Sat, 30 Dec 2000 04:40:57 -0600 (CST) Received: from hoemail2.firewall.lucent.com (localhost [127.0.0.1]) by hoemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id FAA27421; Sat, 30 Dec 2000 05:42:57 -0500 (EST) Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by hoemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id FAA27411; Sat, 30 Dec 2000 05:42:57 -0500 (EST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2650.21) id ; Sat, 30 Dec 2000 11:42:56 +0100 Message-ID: <2413FED0DFE6D111B3F90008C7FA61FB0A984391@nl0006exch002u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Randy Presuhn Cc: disman@dorothy.bmc.com, Randy Bush Subject: RE: Request for addition to disman WG charter Date: Sat, 30 Dec 2000 11:42:55 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" X-MIME-Autoconverted: from quoted-printable to 8bit by dorothy.bmc.com id CAA13135 Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list X-MIME-Autoconverted: from 8bit to quoted-printable by tattler.bmc.com id eBUAgD319931 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id FAA01437 Randy, in principle I am OK with adding this work item to the WG charter. I also see there are two new I-Ds for script and schedule mib. And... there was discussion on the issue of a possible need to recycle notif log mib as a result of performance issues. I undestand that this was just a possibility.... but it needs discussion and/or work. So... I would like to see a complete writeup of the charter that includes all these work items, and that also lists milestones for decisions on all these items. Once I have that, I need to check with IESG/IAB for approval of adding the new work item (I expect no problems, but I want to make sure we follow the process properly. So... while you and I work out the admon/process details, the other volunteers can start working on their tasks as well. OK? Bert > ---------- > From: Randy Presuhn[SMTP:rpresuhn@dorothy.bmc.com] > Sent: Thursday, December 28, 2000 1:44 AM > To: bwijnen@lucent.com > Cc: disman@dorothy.bmc.com > Subject: Request for addition to disman WG charter > > Hi Bert - > > As disman WG chair, I'd like to formally request the addition > of the work on an "Alarm Management MIB" to our charter. I > would like Sharon Chisholm and Dan Romascano to serve as the > document editors. > > There appears to be strong consensus in the WG that we should > take on this work, and that it would have significant value > for the industry. > > The work on the Alarm MIB will take into consideration existing > standards and practices, such as ITU-T X.733. Whether any > mappings to these other standards appear in the Alarm MIB or > in separate documents will be decided by the WG. > > The proposed timetable, based on feedback from the WG: > > January 2001: First WG draft of Alarm Management MIB. > > February 2001: WG agreement on direction regarding mappings > to / from other alarm frameworks. > > February 2001: Submit updated draft of Alarm MIB for IETF meeting. > > March 2001: Meet at the 50th IETF in Minneapolis, Minnesota > > July 2001: Submit updated draft of Alarm MIB for IETF meeting. > > August 2001: Meet at 51st IETF in London, England > > August 2001: WG last call on Alarm Management MIB > > September 2001: Alarm Management MIB delivered to IESG for > consideration as proposed standard. > > Your feedback and comments would be appreciated; let me know > when it's OK to forward this to the secretariat. > > ------------------------------------------------------- > Randy Presuhn randy_presuhn@bmc.com > Voice: +1 408 546-1006 BMC Software, Inc. 1-3141 > Fax: +1 408 965-0359 2141 North First Street > http://www.bmc.com/ San José, California 95131 USA > ------------------------------------------------------- > My opinions and BMC's are independent variables. > ------------------------------------------------------- > From owner-disman@dorothy.bmc.com Sat Dec 30 10:23:11 2000 Received: from tattler.bmc.com (fw-us-hou-1.bmc.com [198.207.223.250]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA02141 for ; Sat, 30 Dec 2000 10:23:11 -0500 (EST) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id eBUFIQ804567; Sat, 30 Dec 2000 09:18:26 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id HAA13505 for disman-list; Sat, 30 Dec 2000 07:19:04 -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 HAA13499; Sat, 30 Dec 2000 07:18:58 -0800 (PST) Received: from fw-us-hou1.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with SMTP id eBUFHrt04508; Sat, 30 Dec 2000 09:17:53 -0600 (CST) Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com; Sat, 30 Dec 2000 10:19:36 -0500 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2652.35) id ; Sat, 30 Dec 2000 10:19:39 -0500 Message-ID: <6DDA62170439D31185750000F80826AC04C5DF18@zmerd004.ca.nortel.com> From: "Sharon Chisholm" To: "Wijnen, Bert (Bert)" , Randy Presuhn Cc: disman@dorothy.bmc.com, Randy Bush Subject: RE: Request for addition to disman WG charter Date: Sat, 30 Dec 2000 10:19:28 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C07273.E70E8D70" X-Orig: Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C07273.E70E8D70 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable hi Sounds good. Sharon -----Original Message----- From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] Sent: Saturday, December 30, 2000 5:43 AM To: Randy Presuhn Cc: disman@dorothy.bmc.com; Randy Bush Subject: RE: Request for addition to disman WG charter Randy, in principle I am OK with adding this work item to the WG charter. I also see there are two new I-Ds for script and schedule mib. And... there was discussion on the issue of a possible need to recycle notif log mib as a result of performance issues. I undestand that this was just a possibility.... but it needs discussion and/or = work. So... I would like to see a complete writeup of the charter that includes all these work items, and that also lists milestones for decisions on all these items. Once I have that, I need to check with IESG/IAB for approval of adding the new work item (I expect no problems, but I want to make sure we follow the process properly. So... while you and I work out the admon/process details, the other volunteers can start working on their tasks as well. OK? Bert > ---------- > From: Randy Presuhn[SMTP:rpresuhn@dorothy.bmc.com] > Sent: Thursday, December 28, 2000 1:44 AM > To: bwijnen@lucent.com > Cc: disman@dorothy.bmc.com > Subject: Request for addition to disman WG charter >=20 > Hi Bert - >=20 > As disman WG chair, I'd like to formally request the addition > of the work on an "Alarm Management MIB" to our charter. I > would like Sharon Chisholm and Dan Romascano to serve as the > document editors. >=20 > There appears to be strong consensus in the WG that we should > take on this work, and that it would have significant value > for the industry. >=20 > The work on the Alarm MIB will take into consideration existing > standards and practices, such as ITU-T X.733. Whether any > mappings to these other standards appear in the Alarm MIB or > in separate documents will be decided by the WG. >=20 > The proposed timetable, based on feedback from the WG: >=20 > January 2001: First WG draft of Alarm Management MIB. >=20 > February 2001: WG agreement on direction regarding mappings > to / from other alarm frameworks. >=20 > February 2001: Submit updated draft of Alarm MIB for IETF meeting. >=20 > March 2001: Meet at the 50th IETF in Minneapolis, Minnesota >=20 > July 2001: Submit updated draft of Alarm MIB for IETF meeting. >=20 > August 2001: Meet at 51st IETF in London, England >=20 > August 2001: WG last call on Alarm Management MIB >=20 > September 2001: Alarm Management MIB delivered to IESG for > consideration as proposed standard. >=20 > Your feedback and comments would be appreciated; let me know > when it's OK to forward this to the secretariat. >=20 > ------------------------------------------------------- > Randy Presuhn randy_presuhn@bmc.com > Voice: +1 408 546-1006 BMC Software, Inc. 1-3141 > Fax: +1 408 965-0359 2141 North First Street > http://www.bmc.com/ San Jos=E9, California 95131 USA > ------------------------------------------------------- > My opinions and BMC's are independent variables. > ------------------------------------------------------- >=20 ------_=_NextPart_001_01C07273.E70E8D70 Content-Type: text/html; charset="iso-8859-1" X-MIME-Autoconverted: from 8bit to quoted-printable by tattler.bmc.com id eBUFIQ804567 Content-Transfer-Encoding: quoted-printable RE: Request for addition to disman WG charter

hi

Sounds good.

Sharon

-----Original Message-----
From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]
Sent: Saturday, December 30, 2000 5:43 AM
To: Randy Presuhn
Cc: disman@dorothy.bmc.com; Randy Bush
Subject: RE: Request for addition to disman WG charter=



Randy, in principle I am OK with adding this work item = to the WG
charter. I also see there are two new I-Ds for script = and schedule mib.
And... there was discussion on the issue of a possible= need to
recycle notif log mib as a result of performance issue= s. I undestand
that this was just a possibility.... but it needs disc= ussion and/or work.

So... I would like to see a complete writeup of the cha= rter that
includes all these work items, and that also lists mil= estones for
decisions on all these items.

Once I have that, I need to check with IESG/IAB for app= roval of
adding the new work item (I expect no problems, but I = want
to make sure we follow the process properly.

So... while you and I work out the admon/process detail= s, the
other volunteers can start working on their tasks as w= ell.

OK?
Bert

> ----------
> From:         = Randy Presuhn[SMTP:rpresuhn@dorothy.bmc.com]
> Sent:         = Thursday, December 28, 2000 1:44 AM
> To:   bwijnen@lucent.com
> Cc:   disman@dorothy.bmc.com
> Subject:      Request for add= ition to disman WG charter
>
> Hi Bert -
>
> As disman WG chair, I'd like to formally request = the addition
> of the work on an "Alarm Management MIB"= ; to our charter.  I
> would like Sharon Chisholm and Dan Romascano to s= erve as the
> document editors.
>
> There appears to be strong consensus in the WG th= at we should
> take on this work, and that it would have signifi= cant value
> for the industry.
>
> The work on the Alarm MIB will take into consider= ation existing
> standards and practices, such as ITU-T X.733.&nbs= p; Whether any
> mappings to these other standards appear in the A= larm MIB or
> in separate documents will be decided by the WG.<= /FONT>
>
> The proposed timetable, based on feedback from th= e WG:
>
>    January 2001: First WG draft of= Alarm Management MIB.
>
>    February 2001: WG agreement on = direction regarding mappings
>        &n= bsp;          to / from othe= r alarm frameworks.
>
>    February 2001: Submit updated d= raft of Alarm MIB for IETF meeting.
>
>    March 2001: Meet at the 50th IE= TF in Minneapolis, Minnesota
>
>    July 2001: Submit updated draft= of Alarm MIB for IETF meeting.
>
>    August 2001: Meet at 51st IETF = in London, England
>
>    August 2001: WG last call on Al= arm Management MIB
>
>    September 2001: Alarm Managemen= t MIB delivered to IESG for
>        &n= bsp;      consideration as proposed standard.
>
> Your feedback and comments would be appreciated; = let me know
> when it's OK to forward this to the secretariat.<= /FONT>
>
>  -------------------------------------------= ------------
>  Randy Presuhn     =       randy_presuhn@bmc.com
>  Voice: +1 408 546-1006  BMC Software, = Inc.  1-3141
>  Fax:   +1 408 965-0359  2141= North First Street
>  http://www.bmc.com/     San Jos=E9, Califo= rnia 95131  USA
>  -------------------------------------------= ------------
>  My opinions and BMC's are independent varia= bles.
>  -------------------------------------------= ------------
>

------_=_NextPart_001_01C07273.E70E8D70--