From owner-disman@dorothy.bmc.com Wed Jan 2 09:44:58 2002 Received: from babbler.bmc.com (firebird.bmc.com [198.207.223.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04793 for ; Wed, 2 Jan 2002 09:44:57 -0500 (EST) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g02Ekpa08006; Wed, 2 Jan 2002 08:46:51 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id GAA05942 for disman-list; Wed, 2 Jan 2002 06:39:19 -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 GAA05937 for ; Wed, 2 Jan 2002 06:39:13 -0800 (PST) Received: from mx-us-hou-1-int.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id g02Ec0s01261 for ; Wed, 2 Jan 2002 08:38:00 -0600 (CST) Received: from watcher.dataductus.se (unknown [213.199.99.201]) by mx-us-hou-1-int.bmc.com (Postfix) with SMTP id D92F221C3AC for ; Wed, 2 Jan 2002 14:28:27 -0600 (CST) Received: (qmail 19010 invoked from network); 2 Jan 2002 14:32:19 -0000 Received: from nsmail.dataductus.se (192.168.100.43) by 0 with SMTP; 2 Jan 2002 14:32:19 -0000 Received: from ddskvirus.dataductus.se ([192.168.100.101]) by nsmail.dataductus.se (Netscape Messaging Server 4.15) with SMTP id GPBFDH00.759 for ; Wed, 2 Jan 2002 15:39:17 +0100 Received: from mogwai.dataductus.se ([192.168.100.44]) by ddskvirus.dataductus.se (NAVGW 2.5.1.15) with SMTP id M2002010215391615306 ; Wed, 02 Jan 2002 15:39:16 +0100 Received: (from nobody@localhost) by mogwai.dataductus.se (8.9.3/8.9.3) id PAA17701; Wed, 2 Jan 2002 15:39:12 +0100 To: disman@dorothy.bmc.com Subject: disman alarm mib comments Message-ID: <1009982352.3c331b901e564@webmail.dataductus.se> Date: Wed, 02 Jan 2002 15:39:12 +0100 (CET) From: Stefan Wallin MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 8bit User-Agent: IMP/PHP IMAP webmail program 2.2.4 X-Originating-IP: 213.65.8.243 Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list Content-Transfer-Encoding: 8bit Hi! Here are some comments to the alarm mib: ************** * ALARM-MIB * ************** ============ Alarm States ============ Can an active alarm have different states then active and cleared? Conceptual model 1: ------------------- An alarm goes on with a severity, stays in that state/severity until it is cleared. Example: lifecycle 1: [linkDown, major]->[linkDown, clear] lifecycle 2: [linkDown, minor]->[linkDown, clear] Conceptual model 2: ------------------- An alarm goes on with a severity, the same active alarm can then change severity during its lifetime and finally it is cleared. Example: lifecycle 1: [linkDown, major]->[linkDown, minor]->[linkDown, clear] Comments: --------- Model 1 is easy to implement in managers where the alarm list handles alarms and cleared alarms, not changed alarms. It is also more easy handled where the alarm manager is integrated with a trouble ticket manager. Complex integration issues arises where alarms changes states and how trouble tickets then shall be handled. Model 2 is proposed by the 3GPP Alarm Model, (http:/www.3gpp.org). They have three generic notifications (CORBA and Q3, not SNMP...), alarmNew, alarmChanged, alarmCleared. It is not really clear which model the Disman Alarm Mib supports/recommends: the generic traps seems to imply model 1, since there is no changedAlarm notification. Recommendation 1: We should strongly recommend model 1. --------------------------------------------------------------- Note however that the alarmModelTable still can have several "states"/entries for the same problem. The different entries models an alarm becoming active with different severities. Recommendation 2: Change name of OBJECT-TYPE alarmModelState to alarmModelSeverity -------------------------------------------------------------------------------- -- Even if we stick to model 2 the alarmModelState OBJECT-TYPE models severity so the model is easier to understand if we use that name. ==================== Notification design ==================== Issue 1a: user friendly information var-bind in traps ------------------------------------------------------ Traps carrying alarm information should fulfill following requirements: a) identify object/resource b) indicate severity c) carry user friendly information so that it can be displayed in real-time d) correlate alarm and alarm clear traps (C) is important since traps are often displayed in real-time in alarm logs and the user must be able to understand the alarm without chasing OIDs using a MIB Browser. The use of generic alarm traps also increases the requirement for (C) since the trap name does not tell the user what problem it is. The alarmRaise and alarmClear traps almost fulfill these requirements but c) is missing. There are two existing OBJECT-TYPES that could be used for this purpose: - alarmModelDescription (SnmpAdminString) - ituAlarmAdditionalText (DisplayString) Solution 1: The straightforward solution would be to include alarmModelDescription in the traps. The risk is that the text is a little too "static" and not generated by the agent at the event generation time including important dynamic information from the user. Solution 2: ituAlarmAdditionalText is the classical X733 variable used for this purpose. But we probably do not want to have a dependency to the itu module. Furthermore it is 7-bit ASCII... Solution 3: define a new columnar object-type, included in the alarmActiveTable: alarmInformation OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION "...." ::= { alarmActiveEntry ... } Proposal for trap var-bind: solution 1. Issue 1b: user-friendly resource identification ----------------------------------------------- The reference to the resource emitting the alarm should of course be a valid reference to an object as done in the current alarm MIB. This enables the management application to chase the reference and do "whatever". But again, traps are displayed in real-time for end-users and it is critical for them to quickly identify the resource. Example: an ifIndex does not tell the typical alarm operator that much... The alarm should say: "Slot 1, port 17, link is down administratively." My recommendation is that the user-friendly var-bind above has this information embedded. This requirement must than be expressed in the DESCRIPTION clause of the OBJECT- TYPE. This also implies that the information is generated dynamically and therefore the alarmModelDescription in the alarmModelTable does not tell the whole story: Imagine the following example from the drarft: alarmModelIndex 3 alarmModelState 2 alarmModelNotificationId linkDown alarmModelVarbindIndex 2 alarmModelVarbindValue down (2) alarmModelDescription "linkDown administratively" In the trap we would like to carry the alarmModelDescription.3.2 = "Slot 1, port 17, linkDown administratively". Solution: allow dynamic information to be added in the string prefix, or suffix and include this as a requirement in the DESCRIPTION clause of alarmModelDescription. Issue 2: index variables in notifications ----------------------------------------- Notifications should not be carried by traps, see "7.7. Mapping of the INDEX clause", rfc2578. If we go for Solution 1 above, sending the alarmModelDescription in the traps, we would implicit send the index variables in the var bind: alarmModelDescription.. = "Toaster burning" The definition would be: alarmRaise NOTIFICATION-TYPE OBJECTS { alarmModelDescription, alarmActiveResourceType, alarmActiveResourceId } STATUS current ============================ Notification sequence number ============================ In order for the manager and agent to be synchronized regarding alarms a sequence number mechanism of alarms are useful. Every alarmRaise carries a sequence number which also is stored in the alarmActiveTable. Why is it useful: a) It is a useful index for the manager to map its alarms to the ones in alarmActiveTable. b) It can be used as an indicatin of missed alarms if there are wholes in the sequence. (Of course trap filtering makes this not too useful...) ============================== OBJECT-TYPE descriptions ============================ Below follows some, I hope ;) , improvements on the object descriptions: alarmModelIndex ---------------- "The alarm model index is the index for a possible alarm object. To model e.g. link failure, there will be two entries in the alarmModelTable which share the same alarmModelIndex; linkUp and linkDown, but with different alarmModelStates" alarmModelState ---------------- "A value of 1 MUST indicate a clear alarm state. The value is an indication of the severity of the alarm state. Higher values MUST imply more severe alarm states. An example using link failure: alarmModelindex alarmModelState ================================ 17 1 -- linkDown: clear alarm state 17 3 -- linkUp Alignment with the ItuPerceivedSeverity defined in ITU-ALARM-TC is recommended " alarmModelVarbindIndex ----------------------- "The index into the varbind listing of the notification indicated by alarmModelNotificationId which helps signal that the given alarm has changed state. If there is no applicable varbind, the value of this object MUST be zero. This must be used if the different states can not be separated by individual notification types. Imagine a toaster notification: toasterProblem(toasterProblemState) where the toasterProblemState var bind has the following values: 0 : OK 1 : toasterJam 2 : burning index ModelState ModelNotificationId ModelVarbindIndex ======================================================== 77 1 toasterProblem 1 77 3 toasterProblem 1 77 5 toasterProblem 1 This tells the manager that var bind 1 must be checked in order to indicate the severity " alarmModelVarBindValue ---------------------- "The value that the varbind indicated by alarmModelVarbindIndex takes to indicate that the alarm has entered this state. Using the previous toaster example: alarmModelVarbindIndex alarmModelVarbindValue ============================================== index ModelState ModelNotificationId ModelVarbindIndex ModelVarbindValue 77 1 toasterProblem 1 0 -- OK 77 3 toasterProblem 1 1 -- jam 77 5 toasterProblem 1 2 -- burning " ********************* * ITU-ALARM modules * ********************* Severity TC ------------------- What is the motivation for not using the same values as X733? See below. I assume one of the reasons is not having 0 as value in the enumerated since it is not recommended in SMIv1. Anyhow, I recommend that we reuse the values and possibly move indeterminate(0) to something else. X733 ITU-ALARM-TC ==================================== indeterminate(0), cleared (1), critical(1), indeterminate (2), major(2), critical (3), minor(3), major (4), warning(4), minor (5), cleared(5) warning (6) ituAlarmAdditionalText ------------------------- Change DisplayString to SNMPAdminString. IANAItuProbableCause ---------------------- I have serious problems with probable cause both in the old ITU standards and now when applied to SNMP. The problem is that the definition lacks extensibility. The values in X733 M3100 etc are for transmission systems and not useful for modern systems. But since it is not an OID structure it is impossible to extend for new standards and enterprise specific values. This has resulted in different vendors just added to the enum, which typically implies collisions when integrating several MIBs. Any thoughts? Stefan Wallin Data Ductus AB +46 70 5233262 stefan.wallin@dataductus.se From owner-disman@dorothy.bmc.com Thu Jan 3 09:33:08 2002 Received: from babbler.bmc.com (firebird.bmc.com [198.207.223.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02083 for ; Thu, 3 Jan 2002 09:33:08 -0500 (EST) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g03EZAY07947; Thu, 3 Jan 2002 08:35:10 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id GAA20693 for disman-list; Thu, 3 Jan 2002 06:30:30 -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 GAA20688 for ; Thu, 3 Jan 2002 06:30:24 -0800 (PST) Received: from mx-us-hou-1-int.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id g03ETDt28062 for ; Thu, 3 Jan 2002 08:29:13 -0600 (CST) Received: from zcars0m9.ca.nortel.com (unknown [47.129.242.157]) by mx-us-hou-1-int.bmc.com (Postfix) with SMTP id D7EE620F4D6 for ; Thu, 3 Jan 2002 14:20:54 -0600 (CST) Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57]) by zcars0m9.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g03EVaa05132; Thu, 3 Jan 2002 09:31:37 -0500 (EST) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g03EVZv29308; Thu, 3 Jan 2002 09:31:35 -0500 (EST) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 3 Jan 2002 09:29:58 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD34013F0135@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: disman@dorothy.bmc.com, Stefan Wallin Subject: RE: disman alarm mib comments Date: Thu, 3 Jan 2002 09:30:03 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list hi Thanks a lot for taking the time to provide this level of comments. My comments are inline: ============ Alarm States ============ Can an active alarm have different states then active and cleared? Yes, that is the intent. It is not really clear which model the Disman Alarm Mib supports/recommends: the generic traps seems to imply model 1, since there is no changedAlarm notification. Oops. We should then change the name of the generic notification to alarmActive to imply this. A lot of systems are able to handle alarms changing state. Systems that prefer a simple raise/clear model can always model their alarms in this manner. Even if we stick to model 2 the alarmModelState OBJECT-TYPE models severity so the model is easier to understand if we use that name. We specifically used a term other than severity for reasons I'm trying to remember. I think part of it was to avoid confusion with ituPerceivedSeverity. I think it might also be because of cases like RMON where the states don't really model well the severities, but as the value of state has an applied severity, I'm not sure how well that argument holds up. ==================== Notification design ==================== The alarmRaise and alarmClear traps almost fulfil these requirements but c) is missing. There are two existing OBJECT-TYPES that could be used for this purpose: - alarmModelDescription (SnmpAdminString) - ituAlarmAdditionalText (DisplayString) I'm actually not a fan of attaching everything to trap varbinds. As you mentioned, alarmModelDescription is static and the manager can read it in well before it receives the notification and display it. The ituAlarmAdditionalText would only be supported by systems using the ITU-ALARM-MIB, so it can't really be sent as part of these varbinds. Plus, in practice, I've never really seen any useful information in this field. Solution 3: define a new columnar object-type, included in the alarmActiveTable: alarmInformation OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION "...." ::= { alarmActiveEntry ... } Do you really think systems will code this level of granularity into their alarm Descriptions? Issue 1b: user-friendly resource identification ----------------------------------------------- The reference to the resource emitting the alarm should of course be a valid reference to an object as done in the current alarm MIB. This is currently being discussed. Can you elaborate on the bits you like about what's currently being done? But again, traps are displayed in real-time for end-users and it is critical for them to quickly identify the resource. Example: an ifIndex does not tell the typical alarm operator that much... The alarm should say: "Slot 1, port 17, link is down administratively." My recommendation is that the user-friendly var-bind above has this information embedded. I disagree that this should be done in the agent, especially if it ends up being done somewhere like a text string. The result of this approach can be seen with fields such as ifName and ifDescription. No agent gives either consistent information or consistent format. I've even seen systems where it isn't even consistent for its different ifTypes. My approach is that base information should be given in a consistent, hard to mess up format such as an integer, and the manager does the mapping to get physical components or other information it needs and then displays it in a nice consistent format to the user. In my experience, this is the only way this sort of thing works. Issue 2: index variables in notifications ----------------------------------------- Notifications should not be carried by traps, see "7.7. Mapping of the INDEX clause", rfc2578. If we go for Solution 1 above, sending the alarmModelDescription in the traps, we would implicit send the index variables in the var bind: alarmModelDescription.. = "Toaster burning" The definition would be: alarmRaise NOTIFICATION-TYPE OBJECTS { alarmModelDescription, alarmActiveResourceType, alarmActiveResourceId } STATUS current This goes back to how annoying it is that table indices are not accessible in SMIv2. Annoying, Annoying, Annoying. It looks like we should be fixing this in SMIng. ============================ Notification sequence number ============================ In order for the manager and agent to be synchronized regarding alarms a sequence number mechanism of alarms are useful. Every alarmRaise carries a sequence number which also is stored in the alarmActiveTable. Why is it useful: a) It is a useful index for the manager to map its alarms to the ones in alarmActiveTable. b) It can be used as an indicatin of missed alarms if there are wholes in the sequence. (Of course trap filtering makes this not too useful...) Well, the alarmActiveLogIndex can serve as this. ============================== OBJECT-TYPE descriptions ============================ Below follows some, I hope ;) , improvements on the object descriptions: Thanks for the suggestions. We'll give them a bit more a read and see if there is stuff we should incorporate. ********************* * ITU-ALARM modules * ********************* Severity TC ------------------- What is the motivation for not using the same values as X733? See below. I assume one of the reasons is not having 0 as value in the enumerated since it is not recommended in SMIv1. Anyhow, I recommend that we reuse the values and possibly move indeterminate(0) to something else. X733 ITU-ALARM-TC ==================================== indeterminate(0), cleared (1), critical(1), indeterminate (2), major(2), critical (3), minor(3), major (4), warning(4), minor (5), cleared(5) warning (6) Hmm. The no enumerated 0 was a factor. I also think this is an attempt to be able to use the same indices in the alarmModelTable as in the ituAlarmTable. There are rowPointers between the two, but I still think this is a good goal and if we don't use 0 we can never match the X733 anyways. ituAlarmAdditionalText ------------------------- Change DisplayString to SNMPAdminString. Thanks. I didn't realize I'd missed that one. IANAItuProbableCause ---------------------- I have serious problems with probable cause both in the old ITU standards and now when applied to SNMP. The problem is that the definition lacks extensibility. The values in X733 M3100 etc are for transmission systems and not useful for modern systems. But since it is not an OID structure it is impossible to extend for new standards and enterprise specific values. This has resulted in different vendors just added to the enum, which typically implies collisions when integrating several MIBs. Any thoughts? Well, I hate identifying things via OIDs. My preferred solution, and what we've done here, is to create an IANA owned enumerated list. It provides one stop shopping for values and extensibility. Thanks again for all the comments, Sharon From owner-disman@dorothy.bmc.com Tue Jan 8 12:24:27 2002 Received: from babbler.bmc.com (firebird.bmc.com [198.207.223.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00960 for ; Tue, 8 Jan 2002 12:24:25 -0500 (EST) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g08HQNH07024; Tue, 8 Jan 2002 11:26:23 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id JAA26694 for disman-list; Tue, 8 Jan 2002 09:19:19 -0800 (PST) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id JAA26688 for disman@dorothy.bmc.com; Tue, 8 Jan 2002 09:19:12 -0800 (PST) Date: Tue, 8 Jan 2002 09:19:12 -0800 (PST) From: Randy Presuhn Message-Id: <200201081719.JAA26688@dorothy.bmc.com> To: disman@dorothy.bmc.com Subject: Fwd: IDMS-PROMS'2002 Call for Papers Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list Content-Transfer-Encoding: 7bit Hi - I'm forwarding a non-subscriber posting to the disman WG mailing list. ------------------------------------------------------ Randy Presuhn BMC Software, Inc. 1-3141 randy_presuhn@bmc.com 2141 North First Street Tel: +1 408 546-1006 San José, California 95131 USA ------------------------------------------------------ My opinions and BMC's are independent variables. ------------------------------------------------------ > 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 EAA25813 > for ; Tue, 8 Jan 2002 04:20:06 -0800 (PST) > Received: from mx-us-hou-1-int.bmc.com (localhost [127.0.0.1]) > by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id g08CIpw11559 > for ; Tue, 8 Jan 2002 06:18:52 -0600 (CST) > Received: from eden.dei.uc.pt (unknown [193.137.203.232]) > by mx-us-hou-1-int.bmc.com (Postfix) with SMTP id A0E5B20EF92 > for ; Tue, 8 Jan 2002 12:09:47 -0600 (CST) > Received: from pan.eden.dei.uc.pt (pan.dei.uc.pt [10.2.0.27]) > by eden.dei.uc.pt (8.11.6/8.11.6) with ESMTP id g08CF7t189655; > Tue, 8 Jan 2002 12:15:08 GMT > Message-Id: <5.1.0.14.0.20020108121828.00a12aa0@eden.dei.uc.pt> > X-Sender: boavida@eden.dei.uc.pt > X-Mailer: QUALCOMM Windows Eudora Version 5.1 > Date: Tue, 08 Jan 2002 12:18:45 +0000 > To: desouza@dc.ufscar.br;, desprats@irit.fr;, deswarte@laas.fr;, > detecon@ghana.com;, devulder@info.unicaen.fr;, dferrari@pc.unicatt.it;, > dginsbur@cisco.com;, dgriffin@ee.ucl.ac.uk;, dh@comp.lancs.ac.uk;, > diakov@cs.utwente.nl;, diaz@droopy.laas.fr;, diaz@laas.fr;, > dibold@tzd.telekom.de;, dib@sei.cmu.edu;, dick.bulterman@cwi.nl;, > Didier.Begay@labri.u-bordeaux.fr;, Didier.Bert@imag.fr;, > dieter@cs.uni-bonn.de;, Dieter.Nazareth@bmw.de;, > dieter@prz.tu-berlin.de;, dieter@uran.informatik.uni-bonn.de;, > dietmar.wagner@danet.de;, dilcher@vxdesy.desy.de;, > dimitris@ced.tuc.gr;, dini@crim.ca;, dirk.steinberg@gmd.de;, > disman@dorothy.bmc.com;, dittmann@darmstadt.gmd.de;, > divivier@informatik.uni-kl.de;, divoux@cran.u-nancy.fr;, > djansen@cs.utwente.nl;, dj@informatik.uni-rostock.de;, > dku@zarniwoop.pc-labor.uni-bremen.de;, dlarra@dit.upm.es > From: Fernando Boavida > Subject: IDMS-PROMS'2002 Call for Papers > Mime-Version: 1.0 > Content-Type: multipart/alternative; > boundary="=====================_11781255==_.ALT" > > --=====================_11781255==_.ALT > Content-Type: text/plain; charset="iso-8859-1"; format=flowed > Content-Transfer-Encoding: quoted-printable > > > We apologize if you receive multiple copies. > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > IDMS/PROMS'2002 > Joint International Workshop on > Interactive Distributed Multimedia Systems / > Protocols for Multimedia Systems > http:// ip2002.dei.uc.pt/ > > November 26-29, 2002 > University of Coimbra, Coimbra, Portugal > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > Interactive Distributed Multimedia Systems (IDMS) and Protocols for > Multimedia Systems (PROMS) have been two successful series of international > events bringing together researchers, developers and practitioners from > academia and industry in all areas of multimedia systems. In 2002, for > the first time, these two workshops will be held jointly, in what is > expected to be the first of a new series of challenging and topical > international workshops. > > IDMS/PROMS'2002 is intended to contribute to scientific, strategic and > practical advances in the area of distributed multimedia applications, > protocols, and intelligent management tools, with emphasis on their > provision over broadband networks. Along with tutorials, invited papers > and technical demonstrations, IDMS/PROMS'2002 is seeking first quality > original work. > > Relevant topics to IDMS/PROMS'2002 include, but are not limited to: > > Mobile multimedia systems > Multimedia middleware > Multimedia communication protocols > Quality of service issues > Resource management > Next generation Internet > Active and programmable networking for multimedia applications > Multimedia-specific mobile agents > Multimedia distribution and transport > Multimedia traffic engineering > Multimedia encoding and compression > Ubiquitous computing > Development tools for distributed multimedia applications > Multimedia applications: video-on-demand, digital video libraries, > video games, virtual community, teleworking, teleteaching, > e-commerce, telemeeting, multimedia conferencing, virtual > reality simulations > Performance of protocols and applications: modelling, simulation > and optimisation in different networks > Multimedia content management > Service access - security, authentication, privacy, watermarking > Accounting and tariff policing for multimedia teleservices > Standards (e.g., MPEG) and related issues > > IDMS/PROMS'2002 will consist of a two and a half day technical program, > plus a full day of tutorials, and demonstrations during the workshop. > Contributions in the form of full papers and position papers are encouraged. > Full papers should describe innovative and significant work. Position > papers are meant to enable researchers to present exciting ongoing work > in early stages, opinions about current developments, and suggestions for > future directions. The purpose of position papers is to provide a seed > for debate and discussion. Both types of papers will be reviewed by the > program committee and included in the workshop proceedings, which will > be published by Springer-Verlag as part of the Lecture Notes in Computer > Science series. > > Information for authors > ----------------------- > > Authors are invited to submit full papers and position papers in PDF > or Postscript formats through the workshop website http://ip2002.dei.uc.pt/. > Submitted papers must describe original work not submitted elsewhere. Full > papers must not be longer than 12 single-spaced pages, and position > papers must not be longer than 6 single-spaced pages. Both types of > papers should contain an abstract of approximately 300 words, and include > title, authors and affiliations. Final versions of accepted papers must > be structured according to the instructions of Springer-Verlag > (http://www.springer.de/comp/lncs/authors.html) > > Best paper award > ---------------- > > A jury will select the best paper, based on the quality of the written > paper. The winner will be awarded a prize donated by one of the workshop > sponsors. > > General information > ------------------- > > For more information visit http://ip2002.dei.uc.pt/ or mail to > ip2002@dei.uc.pt > (Fax.: +351 239 701266). > See also the webpages of previous IDMS and PROMS events: > IDMS'2001 - http://www.idms2001.org/ > PROMS'2001 - http://www.ctit.utwente.nl/news/proms_2001/ > > Important dates > --------------- > > Paper submissions due: May 15th, 2002 > Notification of acceptance: June 30th, 2002 > Camera ready version due: September 10th, 2002 > > > Program Chair > ------------- > > Fernando Boavida, University of Coimbra, Portugal > > > Tutorial Chair > -------------- > Edmundo Monteiro, University of Coimbra, Portugal > > > Steering Committee > ------------------ > > Thomas Plagemann, University of Oslo, UniK, Norway > Patrick Senac, ENSICA, France > Hans Scholten, Twente University, The Netherlands > Marten van Sinderen, Twente University, The Netherlands > Joe Finney, Lancaster University, United Kingdom > Laurent Mathy, Lancaster University, United Kingdom > Zdzislaw Papir, AGH University of Technology, Poland > Arturo Azcorra, Carlos III University, Madrid, Spain > > Program Committee > ----------------- > > Alexandre Santos, University of Minho, Portugal > Andrew Campbell, Columbia University, USA > Arnaldo Martins, University of Aveiro, Portugal > Arturo Azcorra, Carlos III University, Madrid, Spain > Augusto Casaca, INESC, Portugal > Burkhard Stiller, ETH Zurich, Switzerland > David Hutchison, Lancaster University, United Kingdom > Edmundo Madeira, University of Campinas, Brazil > Edmundo Monteiro, University of Coimbra, Portugal > Fernando Boavida, University of Coimbra, Portugal > Fernando Pereira, Instituto Superior T=E9cnico, Portugal > Francisco Fontes, Portugal Telecom Inova=E7=E3o, SA, Portugal > Frank Eliassen, University of Oslo, Norway > Fred Stentiford, BTexaCT Research, United Kingdom > Giorgio Ventre, University Frederico II, Napoli, Italy > Greg O'Shea, Microsoft Research Cambridge, United Kingdom > Gregor v. Bochmann, University of Otawa, Canada > Guy Leduc, University of Liege, Belgium > Hans Scholten, Twente University, The Netherlands > Henk Eertink, Telematica Instituut, The Netherlands > Jan Bormans, IMEC, Belgium > Jason Nieh, Columbia University, USA > Jean-Luc Raffy, Institut National des Telecommunications, France > Joao Orvalho, ESEC/CISUC, Portugal > Joe Finney, Lancaster University, United Kingdom > Jordi Domingo-Pascual, Universitat Polit=E8cnica de Catalunya, Spain > Ketan Mayer-Patel, University of North Carolina, USA > Lars Wolf, University of Karlsruhe, Germany > Laurent Mathy, Lancaster University, United Kingdom > Marten van Sinderen, University of Twente, The Netherlands > Martin Mauve, University of Mannheim, Germany > Michel Diaz, LAAS-CNRS, France > Nick Race, Lancaster University, United Kingdom > Patrick Senac, ENSICA, France > Paul D. Amer, University of Delaware, USA > Philippe Owezarski, LAAS-CNRS, France > Radu Popescu-Zeletin, GMD-FOKUS, Germany > Ralf Steinmetz, TU Darmstadt, Germany > Roberto Canonico, University Frederico II, Napoli, Italy > Serge Fdida, LiP6, France > Sergio Palazzo, University of Catania, Italy > Thomas Plagemann, University of Oslo, Unik, Norway > Tim Chown, University of Southampton, United Kingdom > Timothy Roscoe, Sprint Labs, USA > Tobias Helbig, Philips Research Laboratories, Germany > Ulrich Hofmann, University of Salzburg, Austria > Vera Goebel, University of Oslo, Norway > Winfried Kalfa, TU Chemnitz, Germany > Wolfgang Effelsberg, University of Mannheim, Germany > Zdzislaw Papir, AGH University of Technology, Poland > > Local Organising Committee > -------------------------- > Jo=E3o Orvalho (Chair), ESEC/CISUC, Portugal > Jorge S=E1 Silva, University of Coimbra, Portugal > Mar=EDlia Oliveira, University of Coimbra, Portugal > Paulo Sim=F5es, University of Coimbra, Portugal > > > --------------------------------------------------------------------------- > Fernando Boavida (Associate Professor) > Dept. Engenharia Informatica Tel.: + 351 239 790012 > Universidade de Coimbra Fax.: + 351 239 701266 > POLO II . Pinhal de Marrocos e-mail: boavida@dei.uc.pt > P-3030 COIMBRA = > http://www.dei.uc.pt/~boavida > --------------------------------------------------------------------------- > > > --=====================_11781255==_.ALT > Content-Type: text/html; charset="iso-8859-1" > Content-Transfer-Encoding: quoted-printable > > >
> We apologize if you receive multiple copies.

> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

>             &nbs= > p;         > IDMS/PROMS'2002
>             &nbs= > p; > Joint International Workshop on
>          Interactive Distributed > Multimedia Systems /
>              > Protocols for Multimedia Systems
>             &nbs= > p;   > http:// > ip2002.dei.uc.pt/

>             &nbs= > p;     November 26-29, 2002
>            University of= > Coimbra, Coimbra, Portugal

> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

> Interactive Distributed Multimedia Systems (IDMS) and Protocols for
> Multimedia Systems (PROMS) have been two successful series of international= >
> events bringing together researchers, developers and practitioners from
> academia and industry in all areas of multimedia systems. In 2002, for
> the first time, these two workshops will be held jointly, in what is
> expected to be the first of a new series of challenging and topical
> international workshops.

> IDMS/PROMS'2002 is intended to contribute to scientific, strategic and
> practical advances in the area of distributed multimedia applications,
> protocols, and intelligent management tools, with emphasis on their
> provision over broadband networks. Along with tutorials, invited papers
> and technical demonstrations, IDMS/PROMS'2002 is seeking first quality
> original work.

> Relevant topics to IDMS/PROMS'2002 include, but are not limited to:
>  
>         Mobile= > multimedia systems
>         Multimedia= > middleware
>         Multimedia= > communication protocols
>         Quality of= > service issues
>         Resource= > management
>         Next= > generation Internet
>         Active and= > programmable networking for multimedia applications
>         Multimedia-sp= > ecific mobile agents
>         Multimedia= > distribution and transport
>         Multimedia= > traffic engineering
>         Multimedia= > encoding and compression
>         Ubiquitous= > computing
>         Development= > tools for distributed multimedia applications
>         Multimedia= > applications: video-on-demand, digital video libraries,
>           = > video games, virtual community, teleworking, teleteaching,
>           = > e-commerce, telemeeting, multimedia conferencing, virtual
>           = > reality simulations
>         Performance= > of protocols and applications: modelling, simulation
>           = > and optimisation in different networks
>         Multimedia= > content management
>         Service= > access - security, authentication, privacy, watermarking
>         Accounting= > and tariff policing for multimedia teleservices
>         Standards= > (e.g., MPEG) and related issues

> IDMS/PROMS'2002 will consist of a two and a half day technical program,
> plus a full day of tutorials, and demonstrations during the workshop.
> Contributions in the form of full papers and position papers are encouraged.= >
> Full papers should describe innovative and significant work. Position
> papers are meant to enable researchers to present exciting ongoing work
> in early stages, opinions about current developments, and suggestions for= >
> future directions. The purpose of position papers is to provide a seed
> for debate and discussion. Both types of papers will be reviewed by the
> program committee and included in the workshop proceedings, which will
> be published by Springer-Verlag as part of the Lecture Notes in Computer= >
> Science series.

> Information for authors
> -----------------------

> Authors are invited to submit full papers and position papers in PDF
> or Postscript formats through the workshop website href=3D"http://ip2002.dei.uc.pt/"= > eudora=3D"autourl">http://ip2002.dei.uc.pt/.
> Submitted papers must describe original work not submitted elsewhere. Full= >
> papers must not be longer than 12 single-spaced pages, and position
> papers must not be longer than 6 single-spaced pages. Both types of
> papers should contain an abstract of approximately 300 words, and include= >
> title, authors and affiliations. Final versions of accepted papers must
> be structured according to the instructions of Springer-Verlag
> ( eudora=3D"autourl">http://www.springer.de/comp/lncs/authors.html)
r> > Best paper award
> ----------------

> A jury will select the best paper, based on the quality of the written
> paper. The winner will be awarded a prize donated by one of the workshop= >
> sponsors.

> General information
> -------------------

> For more information visit eudora=3D"autourl">http://ip2002.dei.uc.pt/ or mail to
> ip2002@dei.uc.pt
> (Fax.: +351 239 701266).
> See also the webpages of previous IDMS and PROMS events:
> IDMS'2001 - eudora=3D"autourl">http://www.idms2001.org/
> PROMS'2001 - eudora=3D"autourl">http://www.ctit.utwente.nl/news/proms_2001/

> Important dates
> ---------------

> Paper submissions= > due:        &= > nbsp; May 15th,= > 2002        &= > nbsp; 
> Notification of acceptance:     June= > 30th, 2002 
> Camera ready version= > due:       September= > 10th,= > 2002        &= > nbsp;   

>
> Program Chair
> -------------

> Fernando Boavida, University of Coimbra, Portugal

>
> Tutorial Chair
> --------------
> Edmundo Monteiro, University of Coimbra, Portugal

>
> Steering Committee
> ------------------

> Thomas Plagemann, University of Oslo, UniK,= > Norway        = > ;      
> Patrick Senac, ENSICA, France
> Hans Scholten, Twente University, The Netherlands
> Marten van Sinderen, Twente University, The Netherlands
> Joe Finney, Lancaster University, United Kingdom
> Laurent Mathy, Lancaster University, United Kingdom
> Zdzislaw Papir, AGH University of Technology, Poland
> Arturo Azcorra, Carlos III University, Madrid, Spain

> Program Committee
> -----------------

> Alexandre Santos, University of Minho, Portugal
> Andrew Campbell, Columbia University, USA
> Arnaldo Martins, University of Aveiro, Portugal
> Arturo Azcorra, Carlos III University, Madrid, Spain
> Augusto Casaca, INESC, Portugal
> Burkhard Stiller, ETH Zurich, Switzerland
> David Hutchison, Lancaster University, United Kingdom
> Edmundo Madeira, University of Campinas, Brazil
> Edmundo Monteiro, University of Coimbra, Portugal
> Fernando Boavida, University of Coimbra, Portugal
> Fernando Pereira, Instituto Superior T=E9cnico, Portugal
> Francisco Fontes, Portugal Telecom Inova=E7=E3o, SA, Portugal
> Frank Eliassen, University of Oslo, Norway
> Fred Stentiford, BTexaCT Research, United Kingdom
> Giorgio Ventre, University Frederico II, Napoli, Italy
> Greg O'Shea, Microsoft Research Cambridge, United Kingdom
> Gregor v. Bochmann, University of Otawa, Canada
> Guy Leduc, University of Liege, Belgium
> Hans Scholten, Twente University, The Netherlands
> Henk Eertink, Telematica Instituut, The Netherlands
> Jan Bormans, IMEC, Belgium
> Jason Nieh, Columbia University, USA
> Jean-Luc Raffy, Institut National des Telecommunications, France 
> Joao Orvalho, ESEC/CISUC, Portugal
> Joe Finney, Lancaster University, United Kingdom
> Jordi Domingo-Pascual, Universitat Polit=E8cnica de Catalunya, Spain
> Ketan Mayer-Patel, University of North Carolina, USA
> Lars Wolf, University of Karlsruhe, Germany
> Laurent Mathy, Lancaster University, United Kingdom
> Marten van Sinderen, University of Twente, The Netherlands
> Martin Mauve, University of Mannheim, Germany
> Michel Diaz, LAAS-CNRS, France
> Nick Race, Lancaster University, United Kingdom
> Patrick Senac, ENSICA, France
> Paul D. Amer, University of Delaware, USA
> Philippe Owezarski, LAAS-CNRS, France
> Radu Popescu-Zeletin, GMD-FOKUS, Germany
> Ralf Steinmetz, TU Darmstadt, Germany
> Roberto Canonico, University Frederico II, Napoli, Italy
> Serge Fdida, LiP6, France
> Sergio Palazzo, University of Catania, Italy
> Thomas Plagemann, University of Oslo, Unik, Norway
> Tim Chown, University of Southampton, United Kingdom
> Timothy Roscoe, Sprint Labs, USA
> Tobias Helbig, Philips Research Laboratories, Germany
> Ulrich Hofmann, University of Salzburg, Austria
> Vera Goebel, University of Oslo, Norway
> Winfried Kalfa, TU Chemnitz, Germany
> Wolfgang Effelsberg, University of Mannheim, Germany  
> Zdzislaw Papir, AGH University of Technology, Poland

> Local Organising Committee
> --------------------------
> Jo=E3o Orvalho (Chair), ESEC/CISUC, Portugal
> Jorge S=E1 Silva, University of Coimbra, Portugal
> Mar=EDlia Oliveira, University of Coimbra, Portugal
> Paulo Sim=F5es, University of Coimbra, Portugal

>

> Courier">------------------------------------------------------------------= > ---------
> Fernando Boavida (Associate= > Professor)           = > ;           
> Dept. Engenharia= > Informatica          &nbs= > p;      Tel.: + 351 239 790012
> Universidade de= > Coimbra           &n= > bsp;          Fax.: + 351 239= > 701266
> POLO II . Pinhal de= > Marrocos           &= > nbsp;     e-mail: boavida@dei.uc.pt
> P-3030= > COIMBRA       &nbs= > p;          = > ;        &nbs= > p;         href=3D"http://www.dei.uc.pt/~boavida"= > eudora=3D"autourl">http://www.dei.uc.pt/~boavida
> ---------------------------------------------------------------------------<= > br>
> > > --=====================_11781255==_.ALT-- > > From owner-disman@dorothy.bmc.com Tue Jan 8 21:10:05 2002 Received: from babbler.bmc.com (camaro.bmc.com [198.207.223.231]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16225 for ; Tue, 8 Jan 2002 21:10:05 -0500 (EST) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g092C8o02250; Tue, 8 Jan 2002 20:12:08 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id SAA28276 for disman-list; Tue, 8 Jan 2002 18:07:25 -0800 (PST) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id SAA28258 for disman@dorothy.bmc.com; Tue, 8 Jan 2002 18:07:20 -0800 (PST) Date: Tue, 8 Jan 2002 18:07:20 -0800 (PST) From: Randy Presuhn Message-Id: <200201090207.SAA28258@dorothy.bmc.com> To: disman@dorothy.bmc.com Subject: Fwd: NOTIFICATION-LOG-MIB value objects instantiation question Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list Content-Transfer-Encoding: 7bit Hi - I'm forwarding a posting from Reva Bailey to the disman WG mailing list. I've added her posting address to the disman "posters" list. ------------------------------------------------------ Randy Presuhn BMC Software, Inc. 1-3141 randy_presuhn@bmc.com 2141 North First Street Tel: +1 408 546-1006 San José, California 95131 USA ------------------------------------------------------ My opinions and BMC's are independent variables. ------------------------------------------------------ > 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 PAA27742 > for ; Tue, 8 Jan 2002 15:44:37 -0800 (PST) > Received: from mx-us-hou-1-int.bmc.com (localhost [127.0.0.1]) > by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id g08NhNA15240 > for ; Tue, 8 Jan 2002 17:43:23 -0600 (CST) > Received: from mail.timetra.timetra.com (unknown [63.104.212.2]) > by mx-us-hou-1-int.bmc.com (Postfix) with SMTP id EC83520EFE0 > for ; Tue, 8 Jan 2002 23:34:27 -0600 (CST) > Received: from rbailey ([192.168.1.197]) by mail.timetra.timetra.com with Microsoft SMTPSVC(5.0.2195.3779); > Tue, 8 Jan 2002 15:34:41 -0800 > Reply-To: > From: "Reva Bailey" > To: > Subject: NOTIFICATION-LOG-MIB value objects instantiation question > Date: Tue, 8 Jan 2002 15:51:18 -0800 > Message-ID: > MIME-Version: 1.0 > Content-Type: text/plain; > charset="iso-8859-1" > Content-Transfer-Encoding: 7bit > X-Priority: 3 (Normal) > X-MSMail-Priority: Normal > X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) > X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 > Importance: Normal > X-OriginalArrivalTime: 08 Jan 2002 23:34:41.0879 (UTC) FILETIME=[0BD39E70:01C1989D] > > This is a basic SNMP object instantiation question, but I need help to > interpret correctly the description clause of nlmLogVariableValueType > because I am having problems getting my agent tool-kit to work the way > I think it should :-(. > > nlmLogVariableValueType OBJECT-TYPE > SYNTAX INTEGER { counter32(1), unsigned32(2), timeTicks(3), > integer32(4), ipAddress(5), octetString(6), > objectId(7), counter64(8), opaque(9) } > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The type of the value. One and only one of the value > objects that follow must be instantiated, based on this type." > ::= { nlmLogVariableEntry 3 } > > I interpret this to mean that if I have only one entry in the nlmLogTable > and I do a getnext walk on the nlmLogVariableTable, I expect to see > results like this: > > nlmLogVariableID."".8.1 = OID: sysUpTime.0 > nlmLogVariableID."".8.2 = OID: snmpTrapOID.0 > nlmLogVariableID."".8.3 = OID: ifIndex > nlmLogVariableID."".8.4 = OID: ifAdminStatus > nlmLogVariableID."".8.5 = OID: ifOperStatus > nlmLogVariableValueType."".8.1 = timeTicks(3) > nlmLogVariableValueType."".8.2 = objectId(7) > nlmLogVariableValueType."".8.3 = integer32(4) > nlmLogVariableValueType."".8.4 = integer32(4) > nlmLogVariableValueType."".8.5 = integer32(4) > nlmLogVariableTimeTicksVal."".8.1 = Timeticks: (305023) 0:50:50.23 > nlmLogVariableInteger32Val."".8.3 = 5 > nlmLogVariableInteger32Val."".8.4 = 1 > nlmLogVariableInteger32Val."".8.5 = 2 > nlmLogVariableOidVal."".8.2 = OID: linkDown > > But not like this: > > nlmLogVariableID."".8.1 = OID: sysUpTime.0 > nlmLogVariableID."".8.2 = OID: snmpTrapOID.0 > nlmLogVariableID."".8.3 = OID: ifIndex > nlmLogVariableID."".8.4 = OID: ifAdminStatus > nlmLogVariableID."".8.5 = OID: ifOperStatus > nlmLogVariableValueType."".8.1 = timeTicks(3) > nlmLogVariableValueType."".8.2 = objectId(7) > nlmLogVariableValueType."".8.3 = integer32(4) > nlmLogVariableValueType."".8.4 = integer32(4) > nlmLogVariableValueType."".8.5 = integer32(4) > nlmLogVariableCounter32Val."".8.1 = Counter32: 0 > nlmLogVariableCounter32Val."".8.2 = Counter32: 0 > nlmLogVariableCounter32Val."".8.3 = Counter32: 0 > nlmLogVariableCounter32Val."".8.4 = Counter32: 0 > nlmLogVariableCounter32Val."".8.5 = Counter32: 0 > nlmLogVariableUnsigned32Val."".8.1 = Gauge32: 0 > nlmLogVariableUnsigned32Val."".8.2 = Gauge32: 0 > nlmLogVariableUnsigned32Val."".8.3 = Gauge32: 0 > nlmLogVariableUnsigned32Val."".8.4 = Gauge32: 0 > nlmLogVariableUnsigned32Val."".8.5 = Gauge32: 0 > nlmLogVariableTimeTicksVal."".8.1 = Timeticks: (305023) 0:50:50.23 > nlmLogVariableTimeTicksVal."".8.2 = Timeticks: (0) 0:00:00.00 > nlmLogVariableTimeTicksVal."".8.3 = Timeticks: (0) 0:00:00.00 > nlmLogVariableTimeTicksVal."".8.4 = Timeticks: (0) 0:00:00.00 > nlmLogVariableTimeTicksVal."".8.5 = Timeticks: (0) 0:00:00.00 > nlmLogVariableInteger32Val."".8.1 = 0 > nlmLogVariableInteger32Val."".8.2 = 0 > nlmLogVariableInteger32Val."".8.3 = 5 > nlmLogVariableInteger32Val."".8.4 = 1 > nlmLogVariableInteger32Val."".8.5 = 2 > nlmLogVariableOctetStringVal."".8.1 = "" > nlmLogVariableOctetStringVal."".8.2 = "" > nlmLogVariableOctetStringVal."".8.3 = "" > nlmLogVariableOctetStringVal."".8.4 = "" > nlmLogVariableOctetStringVal."".8.5 = "" > nlmLogVariableIpAddressVal."".8.1 = IpAddress: 0.0.0.0 > nlmLogVariableIpAddressVal."".8.2 = IpAddress: 0.0.0.0 > nlmLogVariableIpAddressVal."".8.3 = IpAddress: 0.0.0.0 > nlmLogVariableIpAddressVal."".8.4 = IpAddress: 0.0.0.0 > nlmLogVariableIpAddressVal."".8.5 = IpAddress: 0.0.0.0 > nlmLogVariableOidVal."".8.1 = OID: ccitt > nlmLogVariableOidVal."".8.2 = OID: linkDown > nlmLogVariableOidVal."".8.3 = OID: ccitt > nlmLogVariableOidVal."".8.4 = OID: ccitt > nlmLogVariableOidVal."".8.5 = OID: ccitt > nlmLogVariableCounter64Val."".8.1 = Counter64: 0 > nlmLogVariableCounter64Val."".8.2 = Counter64: 0 > nlmLogVariableCounter64Val."".8.3 = Counter64: 0 > nlmLogVariableCounter64Val."".8.4 = Counter64: 0 > nlmLogVariableCounter64Val."".8.5 = Counter64: 0 > nlmLogVariableOpaqueVal."".8.1 = OPAQUE: > nlmLogVariableOpaqueVal."".8.2 = OPAQUE: > nlmLogVariableOpaqueVal."".8.3 = OPAQUE: > nlmLogVariableOpaqueVal."".8.4 = OPAQUE: > nlmLogVariableOpaqueVal."".8.5 = OPAQUE: > > Am I correct? Are both styles correct? > > Thanks, > > Reva Bailey > > TiMetra Inc. > revab@timetra.com > 650-237-5123 > > Experience is that marvelous thing that enables you to recognize a mistake > when you make it again. -Franklin P. Jones > > > From owner-disman@dorothy.bmc.com Wed Jan 9 11:55:28 2002 Received: from babbler.bmc.com (firebird.bmc.com [198.207.223.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07181 for ; Wed, 9 Jan 2002 11:55:23 -0500 (EST) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g09GvZg13835; Wed, 9 Jan 2002 10:57:35 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id IAA11176 for disman-list; Wed, 9 Jan 2002 08:52:31 -0800 (PST) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id IAA11171 for ; Wed, 9 Jan 2002 08:52:26 -0800 (PST) Received: from mx-us-hou-2-int.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id g09GpAt29128 for ; Wed, 9 Jan 2002 10:51:11 -0600 (CST) Received: from watcher.dataductus.se (mail.dataductus.se [213.199.99.201]) by mx-us-hou-2-int.bmc.com (Postfix) with SMTP id 0E0F61FF0D8 for ; Wed, 9 Jan 2002 16:43:15 -0600 (CST) Received: (qmail 23192 invoked from network); 9 Jan 2002 11:19:07 -0000 Received: from nsmail.dataductus.se (192.168.100.43) by 0 with SMTP; 9 Jan 2002 11:19:07 -0000 Received: from dataductus.com ([192.168.100.240]) by nsmail.dataductus.se (Netscape Messaging Server 4.15) with SMTP id GPO54M00.QFG for ; Wed, 9 Jan 2002 12:26:46 +0100 From: "Stefan Wallin" To: Subject: time stamp of alarms in ALARM MIB Date: Wed, 9 Jan 2002 12:26:17 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: <3549C09B853DD5119B540002A52CDD34013F0135@zcard0ka.ca.nortel.com> Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list Content-Transfer-Encoding: 8bit Hi! The time stamps of alarms are using the DateAndTime TC. It is of vital importance that the agents use the optional time zone information. We have stumbled across problems in this area since agents usually omit this part and the alarm manager have serious problems in synchronizing alarms etc. Can this requirement be inserted in the OBJECT-TYPES which uses DateAndTime. best regards Stefan Wallin -----Ursprungligt meddelande----- Från: owner-disman@dorothy.bmc.com [mailto:owner-disman@dorothy.bmc.com]För Sharon Chisholm Skickat: den 3 januari 2002 15:30 Till: disman@dorothy.bmc.com; Stefan Wallin Ämne: RE: disman alarm mib comments hi Thanks a lot for taking the time to provide this level of comments. My comments are inline: ============ Alarm States ============ Can an active alarm have different states then active and cleared? Yes, that is the intent. It is not really clear which model the Disman Alarm Mib supports/recommends: the generic traps seems to imply model 1, since there is no changedAlarm notification. Oops. We should then change the name of the generic notification to alarmActive to imply this. A lot of systems are able to handle alarms changing state. Systems that prefer a simple raise/clear model can always model their alarms in this manner. Even if we stick to model 2 the alarmModelState OBJECT-TYPE models severity so the model is easier to understand if we use that name. We specifically used a term other than severity for reasons I'm trying to remember. I think part of it was to avoid confusion with ituPerceivedSeverity. I think it might also be because of cases like RMON where the states don't really model well the severities, but as the value of state has an applied severity, I'm not sure how well that argument holds up. ==================== Notification design ==================== The alarmRaise and alarmClear traps almost fulfil these requirements but c) is missing. There are two existing OBJECT-TYPES that could be used for this purpose: - alarmModelDescription (SnmpAdminString) - ituAlarmAdditionalText (DisplayString) I'm actually not a fan of attaching everything to trap varbinds. As you mentioned, alarmModelDescription is static and the manager can read it in well before it receives the notification and display it. The ituAlarmAdditionalText would only be supported by systems using the ITU-ALARM-MIB, so it can't really be sent as part of these varbinds. Plus, in practice, I've never really seen any useful information in this field. Solution 3: define a new columnar object-type, included in the alarmActiveTable: alarmInformation OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION "...." ::= { alarmActiveEntry ... } Do you really think systems will code this level of granularity into their alarm Descriptions? Issue 1b: user-friendly resource identification ----------------------------------------------- The reference to the resource emitting the alarm should of course be a valid reference to an object as done in the current alarm MIB. This is currently being discussed. Can you elaborate on the bits you like about what's currently being done? But again, traps are displayed in real-time for end-users and it is critical for them to quickly identify the resource. Example: an ifIndex does not tell the typical alarm operator that much... The alarm should say: "Slot 1, port 17, link is down administratively." My recommendation is that the user-friendly var-bind above has this information embedded. I disagree that this should be done in the agent, especially if it ends up being done somewhere like a text string. The result of this approach can be seen with fields such as ifName and ifDescription. No agent gives either consistent information or consistent format. I've even seen systems where it isn't even consistent for its different ifTypes. My approach is that base information should be given in a consistent, hard to mess up format such as an integer, and the manager does the mapping to get physical components or other information it needs and then displays it in a nice consistent format to the user. In my experience, this is the only way this sort of thing works. Issue 2: index variables in notifications ----------------------------------------- Notifications should not be carried by traps, see "7.7. Mapping of the INDEX clause", rfc2578. If we go for Solution 1 above, sending the alarmModelDescription in the traps, we would implicit send the index variables in the var bind: alarmModelDescription.. = "Toaster burning" The definition would be: alarmRaise NOTIFICATION-TYPE OBJECTS { alarmModelDescription, alarmActiveResourceType, alarmActiveResourceId } STATUS current This goes back to how annoying it is that table indices are not accessible in SMIv2. Annoying, Annoying, Annoying. It looks like we should be fixing this in SMIng. ============================ Notification sequence number ============================ In order for the manager and agent to be synchronized regarding alarms a sequence number mechanism of alarms are useful. Every alarmRaise carries a sequence number which also is stored in the alarmActiveTable. Why is it useful: a) It is a useful index for the manager to map its alarms to the ones in alarmActiveTable. b) It can be used as an indicatin of missed alarms if there are wholes in the sequence. (Of course trap filtering makes this not too useful...) Well, the alarmActiveLogIndex can serve as this. ============================== OBJECT-TYPE descriptions ============================ Below follows some, I hope ;) , improvements on the object descriptions: Thanks for the suggestions. We'll give them a bit more a read and see if there is stuff we should incorporate. ********************* * ITU-ALARM modules * ********************* Severity TC ------------------- What is the motivation for not using the same values as X733? See below. I assume one of the reasons is not having 0 as value in the enumerated since it is not recommended in SMIv1. Anyhow, I recommend that we reuse the values and possibly move indeterminate(0) to something else. X733 ITU-ALARM-TC ==================================== indeterminate(0), cleared (1), critical(1), indeterminate (2), major(2), critical (3), minor(3), major (4), warning(4), minor (5), cleared(5) warning (6) Hmm. The no enumerated 0 was a factor. I also think this is an attempt to be able to use the same indices in the alarmModelTable as in the ituAlarmTable. There are rowPointers between the two, but I still think this is a good goal and if we don't use 0 we can never match the X733 anyways. ituAlarmAdditionalText ------------------------- Change DisplayString to SNMPAdminString. Thanks. I didn't realize I'd missed that one. IANAItuProbableCause ---------------------- I have serious problems with probable cause both in the old ITU standards and now when applied to SNMP. The problem is that the definition lacks extensibility. The values in X733 M3100 etc are for transmission systems and not useful for modern systems. But since it is not an OID structure it is impossible to extend for new standards and enterprise specific values. This has resulted in different vendors just added to the enum, which typically implies collisions when integrating several MIBs. Any thoughts? Well, I hate identifying things via OIDs. My preferred solution, and what we've done here, is to create an IANA owned enumerated list. It provides one stop shopping for values and extensibility. Thanks again for all the comments, Sharon From owner-disman@dorothy.bmc.com Wed Jan 9 12:31:36 2002 Received: from babbler.bmc.com (firebird.bmc.com [198.207.223.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07810 for ; Wed, 9 Jan 2002 12:31:36 -0500 (EST) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g09HXou21076; Wed, 9 Jan 2002 11:33:50 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id JAA11497 for disman-list; Wed, 9 Jan 2002 09:28:43 -0800 (PST) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id JAA11492 for ; Wed, 9 Jan 2002 09:28:37 -0800 (PST) Received: from mx-us-hou-1-int.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id g09HRNa12365 for ; Wed, 9 Jan 2002 11:27:23 -0600 (CST) Received: from iere.net.avaya.com (unknown [198.152.12.101]) by mx-us-hou-1-int.bmc.com (Postfix) with SMTP id B4BC320F10E for ; Wed, 9 Jan 2002 17:18:24 -0600 (CST) Received: from iere.net.avaya.com (localhost [127.0.0.1]) by iere.net.avaya.com (8.11.2/8.9.3) with ESMTP id g09HSel10320 for ; Wed, 9 Jan 2002 12:28:40 -0500 (EST) Received: from IS0004AVEXU1.global.avaya.com (h149-49-38-91.avaya.com [149.49.38.91]) by iere.net.avaya.com (8.11.2/8.9.3) with ESMTP id g09HSdT10293 for ; Wed, 9 Jan 2002 12:28:39 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: time stamp of alarms in ALARM MIB Date: Wed, 9 Jan 2002 19:29:07 +0200 Message-ID: Thread-Topic: time stamp of alarms in ALARM MIB Thread-Index: AcGZL9N0PwmhsMBURqGi4lX3YZsMnwAAYS0g From: "Romascanu, Dan (Dan)" To: "Stefan Wallin" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by dorothy.bmc.com id JAA11493 Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list Content-Transfer-Encoding: 8bit I do not think that we can do much more in this document than putting a SHOULD in the DESCRIPTION clause. The issue seems more general, it applies not only for this MIB, but for all applications that use agents distributed in different time zones. Maybe we should define a new TC ZoneDateAndTime, that is similar with DateAndTime, with the exception of the last two infamous rows in the TC DESCRIPTION. Regards, Dan > -----Original Message----- > From: Stefan Wallin [mailto:stefan.wallin@dataductus.se] > Sent: Wednesday, January 09, 2002 1:26 PM > To: disman@dorothy.bmc.com > Subject: time stamp of alarms in ALARM MIB > > > Hi! > The time stamps of alarms are using the DateAndTime TC. > It is of vital importance that the agents use the optional time zone > information. > We have stumbled across problems in this area since agents > usually omit this > part and the alarm manager have serious problems in > synchronizing alarms > etc. > > Can this requirement be inserted in the OBJECT-TYPES which > uses DateAndTime. > best regards Stefan Wallin > > -----Ursprungligt meddelande----- > Från: owner-disman@dorothy.bmc.com > [mailto:owner-disman@dorothy.bmc.com]För Sharon Chisholm > Skickat: den 3 januari 2002 15:30 > Till: disman@dorothy.bmc.com; Stefan Wallin > Ämne: RE: disman alarm mib comments > > > hi > > Thanks a lot for taking the time to provide this level of > comments. My comments are inline: > > > ============ > Alarm States > ============ > Can an active alarm have different states then active and cleared? > > > Yes, that is the intent. > > > It is not really clear which model the Disman Alarm Mib > supports/recommends: > the generic traps seems to imply model 1, since there is no > changedAlarm > notification. > > > Oops. We should then change the name of the generic notification to > alarmActive to imply this. > > A lot of systems are able to handle alarms changing state. Systems > that prefer a simple raise/clear model can always model their alarms > in this manner. > > > Even if we stick to model 2 the alarmModelState OBJECT-TYPE > models severity > so > the model > is easier to understand if we use that name. > > > We specifically used a term other than severity for reasons I'm trying > to remember. I think part of it was to avoid confusion with > ituPerceivedSeverity. > I think it might also be because of cases like RMON where the > states don't > really model well the severities, but as the value of state > has an applied > severity, I'm not sure how well that argument holds up. > > > ==================== > Notification design > ==================== > > > > The alarmRaise and alarmClear traps almost fulfil these > requirements but c) > is > missing. > There are two existing OBJECT-TYPES that could be used for > this purpose: > - alarmModelDescription (SnmpAdminString) > - ituAlarmAdditionalText (DisplayString) > > > I'm actually not a fan of attaching everything to trap > varbinds. As you > mentioned, alarmModelDescription is static and the manager can read it > in well before it receives the notification and display it. > > The ituAlarmAdditionalText would only be supported by systems > using the > ITU-ALARM-MIB, so it can't really be sent as part of these > varbinds. Plus, > in practice, I've never really seen any useful information in > this field. > > > Solution 3: define a new columnar object-type, included in the > alarmActiveTable: > > alarmInformation OBJECT-TYPE > SYNTAX SnmpAdminString > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "...." > ::= { alarmActiveEntry ... } > > > Do you really think systems will code this level of granularity into > their alarm Descriptions? > > > Issue 1b: user-friendly resource identification > ----------------------------------------------- > The reference to the resource emitting the alarm should of > course be a valid > > reference > to an object as done in the current alarm MIB. > > > This is currently being discussed. Can you elaborate on the > bits you like > about what's currently being done? > > > But again, traps are displayed in > real-time > for end-users and it is critical for them to quickly identify > the resource. > > Example: an ifIndex does not tell the typical alarm operator > that much... > The alarm should say: "Slot 1, port 17, link is down > administratively." > > My recommendation is that the user-friendly var-bind above has this > information > embedded. > > > I disagree that this should be done in the agent, especially > if it ends up > being > done somewhere like a text string. The result of this > approach can be seen > with > fields such as ifName and ifDescription. No agent gives > either consistent > information or consistent format. I've even seen systems > where it isn't even > consistent for its different ifTypes. My approach is that > base information > should be given in a consistent, hard to mess up format such > as an integer, > and the manager does the mapping to get physical components or other > information > it needs and then displays it in a nice consistent format to > the user. In my > experience, this is the only way this sort of thing works. > > > Issue 2: index variables in notifications > ----------------------------------------- > Notifications should not be carried by traps, see "7.7. > Mapping of the > INDEX > clause", rfc2578. > If we go for Solution 1 above, sending the > alarmModelDescription in the > traps, > we would implicit send > the index variables in the var bind: > alarmModelDescription.. = "Toaster > burning" > > The definition would be: > alarmRaise NOTIFICATION-TYPE > OBJECTS { alarmModelDescription, > alarmActiveResourceType, > alarmActiveResourceId } > STATUS current > > > This goes back to how annoying it is that table indices are > not accessible > in SMIv2. Annoying, Annoying, Annoying. It looks like we > should be fixing > this in SMIng. > > > ============================ > Notification sequence number > ============================ > In order for the manager and agent to be synchronized > regarding alarms a > sequence number > mechanism of alarms are useful. Every alarmRaise carries a > sequence number > which also is > stored in the alarmActiveTable. > Why is it useful: > > a) It is a useful index for the manager to map its alarms to > the ones in > alarmActiveTable. > b) It can be used as an indicatin of missed alarms if there > are wholes in > the > sequence. > (Of course trap filtering makes this not too useful...) > > > Well, the alarmActiveLogIndex can serve as this. > > > > ============================== > OBJECT-TYPE descriptions > ============================ > > Below follows some, I hope ;) , improvements on the object > descriptions: > > > > Thanks for the suggestions. We'll give them a bit more a read > and see if > there is stuff we should incorporate. > > > ********************* > * ITU-ALARM modules * > ********************* > > Severity TC > ------------------- > What is the motivation for not using the same values as X733? > See below. > I assume one of the reasons is not having 0 as value in the enumerated > since it is not recommended in SMIv1. > Anyhow, I recommend that we reuse the values and possibly move > indeterminate(0) > to > something else. > > X733 ITU-ALARM-TC > ==================================== > indeterminate(0), cleared (1), > critical(1), indeterminate (2), > major(2), critical (3), > minor(3), major (4), > warning(4), minor (5), > cleared(5) warning (6) > > > > Hmm. The no enumerated 0 was a factor. I also think this is > an attempt to be able to use the same indices in the > alarmModelTable as in the ituAlarmTable. There are rowPointers > between the two, but I still think this is a good goal and > if we don't use 0 we can never match the X733 anyways. > > > ituAlarmAdditionalText > ------------------------- > Change DisplayString to SNMPAdminString. > > > Thanks. I didn't realize I'd missed that one. > > > IANAItuProbableCause > ---------------------- > I have serious problems with probable cause both in the old > ITU standards > and > now when > applied to SNMP. > The problem is that the definition lacks extensibility. The > values in X733 > M3100 etc > are for transmission systems and not useful for modern > systems. But since it > is > not > an OID structure it is impossible to extend for new standards > and enterprise > > specific values. This has resulted in different vendors just > added to the > enum, > which typically implies collisions when integrating several MIBs. > > Any thoughts? > > > Well, I hate identifying things via OIDs. My preferred > solution, and what > we've done here, is to create an IANA owned enumerated list. > It provides > one stop shopping for values and extensibility. > > Thanks again for all the comments, > > Sharon > > From owner-disman@dorothy.bmc.com Wed Jan 9 13:11:30 2002 Received: from babbler.bmc.com (firebird.bmc.com [198.207.223.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08650 for ; Wed, 9 Jan 2002 13:11:29 -0500 (EST) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g09IDe928686; Wed, 9 Jan 2002 12:13:40 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id KAA11587 for disman-list; Wed, 9 Jan 2002 10:08:48 -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 KAA11582 for ; Wed, 9 Jan 2002 10:08:45 -0800 (PST) Received: from mx-us-hou-2-int.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id g09I7UO25765 for ; Wed, 9 Jan 2002 12:07:30 -0600 (CST) Received: from mumm.ibr.cs.tu-bs.de (mumm.ibr.cs.tu-bs.de [134.169.34.33]) by mx-us-hou-2-int.bmc.com (Postfix) with SMTP id 6222D1FF12C for ; Wed, 9 Jan 2002 17:59:34 -0600 (CST) Received: from haerke.ibr.cs.tu-bs.de (IDENT:root@haerke.ibr.cs.tu-bs.de [134.169.34.84]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.0) with ESMTP id TAA20086; Wed, 9 Jan 2002 19:09:37 +0100 (MET) Received: (from schoenw@localhost) by haerke.ibr.cs.tu-bs.de (8.11.6/8.11.6) id g09I9b422751; Wed, 9 Jan 2002 19:09:37 +0100 Date: Wed, 9 Jan 2002 19:09:37 +0100 Message-Id: <200201091809.g09I9b422751@haerke.ibr.cs.tu-bs.de> X-Authentication-Warning: haerke.ibr.cs.tu-bs.de: schoenw set sender to schoenw@ibr.cs.tu-bs.de using -f From: Juergen Schoenwaelder To: dromasca@avaya.com Cc: stefan.wallin@dataductus.se, disman@dorothy.bmc.com In-reply-to: (dromasca@avaya.com) Subject: Re: time stamp of alarms in ALARM MIB References: Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list >>>>> Romascanu, Dan (Dan) writes: Dan> I do not think that we can do much more in this document than Dan> putting a SHOULD in the DESCRIPTION clause. And I think that is appropriate and enough. Dan> The issue seems more general, it applies not only for this MIB, Dan> but for all applications that use agents distributed in different Dan> time zones. Maybe we should define a new TC ZoneDateAndTime, Dan> that is similar with DateAndTime, with the exception of the last Dan> two infamous rows in the TC DESCRIPTION. I do not think there is a problem with the DateAndTime TC. It says: Note that if only local time is known, then timezone information (fields 8-10) is not present." Perhaps the language could be stronger, but it basically says the right thing to me: Report the timezone except in cases where the timezone information is not available. Defining a ZoneDateAndTime which requires to report the timezone even if your box has no clue about the timezone is not a step forward and people will just report GMT or something like that which is worse. /js From owner-disman@dorothy.bmc.com Wed Jan 9 13:21:30 2002 Received: from babbler.bmc.com (firebird.bmc.com [198.207.223.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08892 for ; Wed, 9 Jan 2002 13:21:30 -0500 (EST) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g09INgC01201; Wed, 9 Jan 2002 12:23:42 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id KAA11620 for disman-list; Wed, 9 Jan 2002 10:19: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 KAA11615 for ; Wed, 9 Jan 2002 10:19:11 -0800 (PST) Received: from mx-us-hou-2-int.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id g09IHvj29338 for ; Wed, 9 Jan 2002 12:17:57 -0600 (CST) Received: from ierw.net.avaya.com (ierw.net.avaya.com [198.152.13.101]) by mx-us-hou-2-int.bmc.com (Postfix) with SMTP id A7D731FF0D8 for ; Wed, 9 Jan 2002 18:09:59 -0600 (CST) Received: from ierw.net.avaya.com (localhost [127.0.0.1]) by ierw.net.avaya.com (8.9.3+Sun/8.9.3) with ESMTP id NAA04750 for ; Wed, 9 Jan 2002 13:18:53 -0500 (EST) Received: from IS0004AVEXU1.global.avaya.com (h149-49-38-91.avaya.com [149.49.38.91]) by ierw.net.avaya.com (8.9.3+Sun/8.9.3) with ESMTP id NAA04724 for ; Wed, 9 Jan 2002 13:18:52 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: time stamp of alarms in ALARM MIB Date: Wed, 9 Jan 2002 20:19:27 +0200 Message-ID: Thread-Topic: time stamp of alarms in ALARM MIB Thread-Index: AcGZOMaI/14tjTt9T1OJf8ZtJsvgPQAANtww From: "Romascanu, Dan (Dan)" To: "Juergen Schoenwaelder" Cc: , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by dorothy.bmc.com id KAA11616 Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list Content-Transfer-Encoding: 8bit > I do not think there is a problem with the DateAndTime TC. It says: > > Note that if only local time is known, then timezone > information (fields 8-10) is not present." > > Perhaps the language could be stronger, but it basically says the > right thing to me: Report the timezone except in cases where the > timezone information is not available. > > Defining a ZoneDateAndTime which requires to report the timezone even > if your box has no clue about the timezone is not a step forward and > people will just report GMT or something like that which is worse. > I was not meaning the context of this MIB. However, for a MIB and applications that clearly would require objects distributed at different time zones I would use this new TC, and include text mandating time zone awareness in the agents implementing the TC. Regards, Dan > From owner-disman@dorothy.bmc.com Wed Jan 9 14:38:29 2002 Received: from babbler.bmc.com (firebird.bmc.com [198.207.223.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13521 for ; Wed, 9 Jan 2002 14:38:28 -0500 (EST) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g09JeeX15308; Wed, 9 Jan 2002 13:40:41 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id LAA12105 for disman-list; Wed, 9 Jan 2002 11:35:39 -0800 (PST) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id LAA12100 for ; Wed, 9 Jan 2002 11:35:35 -0800 (PST) Received: from mx-us-hou-1-int.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id g09JYKh21414 for ; Wed, 9 Jan 2002 13:34:20 -0600 (CST) Received: from alpha.armillaire.com (unknown [64.66.32.133]) by mx-us-hou-1-int.bmc.com (Postfix) with SMTP id 1FA5920F118 for ; Wed, 9 Jan 2002 19:25:11 -0600 (CST) Received: from BETHEXC01.armillaire.com (unknown [64.66.32.137]) by alpha.armillaire.com (Postfix) with ESMTP id 55ACE5C754 for ; Wed, 9 Jan 2002 14:35:22 -0500 (EST) Received: by bethexc01.armillaire.com with Internet Mail Service (5.5.2653.19) id ; Wed, 9 Jan 2002 14:33:34 -0500 Message-ID: <4D38F1A1C17DD411931F00508BAF728ED6808A@bethexc01.armillaire.com> From: "Nallappa, Bhashyam" To: disman@dorothy.bmc.com Subject: NOTIFICATION-LOG-MIB Date: Wed, 9 Jan 2002 14:33:33 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list I had a question regarding the Notification Log. How long realistically is one supposed to store these notifications? There could be thousands of notifications in a day and though I understand someone may like to look at a notification logs for a month old problem. What are some of the standard practices? Thanks Bhashyam From owner-disman@dorothy.bmc.com Wed Jan 9 16:01:20 2002 Received: from babbler.bmc.com (firebird.bmc.com [198.207.223.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15177 for ; Wed, 9 Jan 2002 16:01:20 -0500 (EST) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g09L3W800401; Wed, 9 Jan 2002 15:03:32 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id MAA12596 for disman-list; Wed, 9 Jan 2002 12:58:44 -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 MAA12591 for ; Wed, 9 Jan 2002 12:58:39 -0800 (PST) Received: from mx-us-hou-2-int.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id g09KvMu15917 for ; Wed, 9 Jan 2002 14:57:23 -0600 (CST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mx-us-hou-2-int.bmc.com (Postfix) with SMTP id 4DE431FF148 for ; Wed, 9 Jan 2002 20:49:28 -0600 (CST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15067; Wed, 9 Jan 2002 15:59:43 -0500 (EST) Message-Id: <200201092059.PAA15067@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: disman@dorothy.bmc.com From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-disman-alarm-mib-04.txt Date: Wed, 09 Jan 2002 15:59:42 -0500 Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Distributed Management Working Group of the IETF. Title : Alarm MIB Author(s) : S. Chisholm, D. Romascanu Filename : draft-ietf-disman-alarm-mib-04.txt Pages : 57 Date : 08-Jan-02 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes management objects used for defining and storing alarms. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-disman-alarm-mib-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-disman-alarm-mib-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-disman-alarm-mib-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020108150519.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-disman-alarm-mib-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-disman-alarm-mib-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020108150519.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-disman@dorothy.bmc.com Wed Jan 9 16:03:25 2002 Received: from babbler.bmc.com (camaro.bmc.com [198.207.223.231]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15325 for ; Wed, 9 Jan 2002 16:03:25 -0500 (EST) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g09L5Xs00858; Wed, 9 Jan 2002 15:05:38 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id NAA12618 for disman-list; Wed, 9 Jan 2002 13:01:12 -0800 (PST) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id NAA12613 for ; Wed, 9 Jan 2002 13:01:09 -0800 (PST) Received: from mx-us-hou-1-int.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id g09KxsP16648 for ; Wed, 9 Jan 2002 14:59:54 -0600 (CST) Received: from sj-msg-core-4.cisco.com (unknown [171.71.163.10]) by mx-us-hou-1-int.bmc.com (Postfix) with SMTP id 00CB820F164 for ; Wed, 9 Jan 2002 20:50:54 -0600 (CST) Received: from mira-sjcm-2.cisco.com (mira-sjcm-2.cisco.com [171.69.24.14]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id g09L2TJ11917; Wed, 9 Jan 2002 13:02:29 -0800 (PST) Received: from cisco.com (dhcp-128-107-165-172.cisco.com [128.107.165.172]) by mira-sjcm-2.cisco.com (Mirapoint) with ESMTP id ABH81928; Wed, 9 Jan 2002 13:02:12 -0800 (PST) Message-ID: <3C3CAEF8.343D233E@cisco.com> Date: Wed, 09 Jan 2002 12:58:32 -0800 From: Ramanathan Kavasseri X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Nallappa, Bhashyam" Cc: disman@dorothy.bmc.com Subject: Re: NOTIFICATION-LOG-MIB References: <4D38F1A1C17DD411931F00508BAF728ED6808A@bethexc01.armillaire.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list Content-Transfer-Encoding: 7bit Bhashyam, managed systems have limitations on how much memory they can dedicate to the notification log mib. The notif log mib, IMHO, isn't a permanent store for logged notifications. Notifs should be kept for a "reasonable period of time" so that NMSes can periodically poll for lost notifications. A reasonable time could be 10 minutes, an hour, 24 hours. Anything logged on the managed device much beyond that may be of questionable value, IMHO. If a user needs to "archive" logged notifications, this should be done by a dedicated application, preferably off the managed device. Just my 2 cents. Ram "Nallappa, Bhashyam" wrote: > > > I had a question regarding the Notification Log. How long realistically is > one supposed to store these notifications? There could be thousands of > notifications in a day and though I understand someone may like to look at a > notification logs for a month old problem. What are some of the standard > practices? > > Thanks > Bhashyam From owner-disman@dorothy.bmc.com Wed Jan 9 19:12:52 2002 Received: from babbler.bmc.com (firebird.bmc.com [198.207.223.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21543 for ; Wed, 9 Jan 2002 19:12:52 -0500 (EST) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g0A0EwC29420; Wed, 9 Jan 2002 18:14:58 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id QAA13538 for disman-list; Wed, 9 Jan 2002 16:10:12 -0800 (PST) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id QAA13532 for disman@dorothy.bmc.com; Wed, 9 Jan 2002 16:10:08 -0800 (PST) Date: Wed, 9 Jan 2002 16:10:08 -0800 (PST) From: Randy Presuhn Message-Id: <200201100010.QAA13532@dorothy.bmc.com> To: disman@dorothy.bmc.com Subject: alarm corelation at NOMS 2002 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list Content-Transfer-Encoding: 7bit Hi - I was looking at the technical program for http://www.comsoc.org/confs/noms/2002/Program1.html and see that they're doing a session on alarm corelation. Does anyone have more detail on this? ------------------------------------------------------ Randy Presuhn BMC Software, Inc. 1-3141 randy_presuhn@bmc.com 2141 North First Street Tel: +1 408 546-1006 San José, California 95131 USA ------------------------------------------------------ My opinions and BMC's are independent variables. ------------------------------------------------------ From owner-disman@dorothy.bmc.com Thu Jan 10 01:33:43 2002 Received: from babbler.bmc.com (camaro.bmc.com [198.207.223.231]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02341 for ; Thu, 10 Jan 2002 01:33:43 -0500 (EST) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g0A6Zos00134; Thu, 10 Jan 2002 00:35:50 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id WAA17902 for disman-list; Wed, 9 Jan 2002 22:30:59 -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 WAA17897 for ; Wed, 9 Jan 2002 22:30:53 -0800 (PST) Received: from mx-us-hou-2-int.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id g0A6Tcw23115 for ; Thu, 10 Jan 2002 00:29:38 -0600 (CST) Received: from watcher.dataductus.se (mail.dataductus.se [213.199.99.201]) by mx-us-hou-2-int.bmc.com (Postfix) with SMTP id 4E8CE1FF033 for ; Thu, 10 Jan 2002 06:21:42 -0600 (CST) Received: (qmail 13724 invoked from network); 10 Jan 2002 06:24:24 -0000 Received: from nsmail.dataductus.se (192.168.100.43) by 0 with SMTP; 10 Jan 2002 06:24:24 -0000 Received: from ddskvirus.dataductus.se ([192.168.100.101]) by nsmail.dataductus.se (Netscape Messaging Server 4.15) with SMTP id GPPM5P00.4JT for ; Thu, 10 Jan 2002 07:32:13 +0100 Received: from mogwai.dataductus.se ([192.168.100.44]) by ddskvirus.dataductus.se (NAVGW 2.5.1.15) with SMTP id M2002011007321321750 ; Thu, 10 Jan 2002 07:32:13 +0100 Received: (from nobody@localhost) by mogwai.dataductus.se (8.9.3/8.9.3) id HAA26236; Thu, 10 Jan 2002 07:32:06 +0100 To: "Romascanu, Dan (Dan)" Subject: RE: time stamp of alarms in ALARM MIB Message-ID: <1010644325.3c3d3565cdbfb@webmail.dataductus.se> Date: Thu, 10 Jan 2002 07:32:05 +0100 (CET) From: Stefan Wallin Cc: Stefan Wallin , disman@dorothy.bmc.com References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 8bit User-Agent: IMP/PHP IMAP webmail program 2.2.4 X-Originating-IP: 194.23.29.137 Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list Content-Transfer-Encoding: 8bit I agree, in the context of the alarm mib, all that is needed is a SHOULD clause in the description so that I can hit people implementing agents without tz info. /stefan Citerat från "Romascanu, Dan (Dan)" : > I do not think that we can do much more in this document than putting > a > SHOULD in the DESCRIPTION clause. > > The issue seems more general, it applies not only for this MIB, but > for > all applications that use agents distributed in different time zones. > Maybe we should define a new TC ZoneDateAndTime, that is similar with > DateAndTime, with the exception of the last two infamous rows in the > TC > DESCRIPTION. > > Regards, > > Dan > > > > -----Original Message----- > > From: Stefan Wallin [mailto:stefan.wallin@dataductus.se] > > Sent: Wednesday, January 09, 2002 1:26 PM > > To: disman@dorothy.bmc.com > > Subject: time stamp of alarms in ALARM MIB > > > > > > Hi! > > The time stamps of alarms are using the DateAndTime TC. > > It is of vital importance that the agents use the optional time zone > > information. > > We have stumbled across problems in this area since agents > > usually omit this > > part and the alarm manager have serious problems in > > synchronizing alarms > > etc. > > > > Can this requirement be inserted in the OBJECT-TYPES which > > uses DateAndTime. > > best regards Stefan Wallin > > > > -----Ursprungligt meddelande----- > > Från: owner-disman@dorothy.bmc.com > > [mailto:owner-disman@dorothy.bmc.com]För Sharon Chisholm > > Skickat: den 3 januari 2002 15:30 > > Till: disman@dorothy.bmc.com; Stefan Wallin > > Ämne: RE: disman alarm mib comments > > > > > > hi > > > > Thanks a lot for taking the time to provide this level of > > comments. My comments are inline: > > > > > > ============ > > Alarm States > > ============ > > Can an active alarm have different states then active and cleared? > > > > > > Yes, that is the intent. > > > > > > It is not really clear which model the Disman Alarm Mib > > supports/recommends: > > the generic traps seems to imply model 1, since there is no > > changedAlarm > > notification. > > > > > > Oops. We should then change the name of the generic notification to > > alarmActive to imply this. > > > > A lot of systems are able to handle alarms changing state. Systems > > that prefer a simple raise/clear model can always model their alarms > > in this manner. > > > > > > Even if we stick to model 2 the alarmModelState OBJECT-TYPE > > models severity > > so > > the model > > is easier to understand if we use that name. > > > > > > We specifically used a term other than severity for reasons I'm > trying > > to remember. I think part of it was to avoid confusion with > > ituPerceivedSeverity. > > I think it might also be because of cases like RMON where the > > states don't > > really model well the severities, but as the value of state > > has an applied > > severity, I'm not sure how well that argument holds up. > > > > > > ==================== > > Notification design > > ==================== > > > > > > > > The alarmRaise and alarmClear traps almost fulfil these > > requirements but c) > > is > > missing. > > There are two existing OBJECT-TYPES that could be used for > > this purpose: > > - alarmModelDescription (SnmpAdminString) > > - ituAlarmAdditionalText (DisplayString) > > > > > > I'm actually not a fan of attaching everything to trap > > varbinds. As you > > mentioned, alarmModelDescription is static and the manager can read > it > > in well before it receives the notification and display it. > > > > The ituAlarmAdditionalText would only be supported by systems > > using the > > ITU-ALARM-MIB, so it can't really be sent as part of these > > varbinds. Plus, > > in practice, I've never really seen any useful information in > > this field. > > > > > > Solution 3: define a new columnar object-type, included in the > > alarmActiveTable: > > > > alarmInformation OBJECT-TYPE > > SYNTAX SnmpAdminString > > MAX-ACCESS read-only > > STATUS current > > DESCRIPTION > > "...." > > ::= { alarmActiveEntry ... } > > > > > > Do you really think systems will code this level of granularity into > > their alarm Descriptions? > > > > > > Issue 1b: user-friendly resource identification > > ----------------------------------------------- > > The reference to the resource emitting the alarm should of > > course be a valid > > > > reference > > to an object as done in the current alarm MIB. > > > > > > This is currently being discussed. Can you elaborate on the > > bits you like > > about what's currently being done? > > > > > > But again, traps are displayed in > > real-time > > for end-users and it is critical for them to quickly identify > > the resource. > > > > Example: an ifIndex does not tell the typical alarm operator > > that much... > > The alarm should say: "Slot 1, port 17, link is down > > administratively." > > > > My recommendation is that the user-friendly var-bind above has this > > information > > embedded. > > > > > > I disagree that this should be done in the agent, especially > > if it ends up > > being > > done somewhere like a text string. The result of this > > approach can be seen > > with > > fields such as ifName and ifDescription. No agent gives > > either consistent > > information or consistent format. I've even seen systems > > where it isn't even > > consistent for its different ifTypes. My approach is that > > base information > > should be given in a consistent, hard to mess up format such > > as an integer, > > and the manager does the mapping to get physical components or other > > information > > it needs and then displays it in a nice consistent format to > > the user. In my > > experience, this is the only way this sort of thing works. > > > > > > Issue 2: index variables in notifications > > ----------------------------------------- > > Notifications should not be carried by traps, see "7.7. > > Mapping of the > > INDEX > > clause", rfc2578. > > If we go for Solution 1 above, sending the > > alarmModelDescription in the > > traps, > > we would implicit send > > the index variables in the var bind: > > alarmModelDescription.. = "Toaster > > burning" > > > > The definition would be: > > alarmRaise NOTIFICATION-TYPE > > OBJECTS { alarmModelDescription, > > alarmActiveResourceType, > > alarmActiveResourceId } > > STATUS current > > > > > > This goes back to how annoying it is that table indices are > > not accessible > > in SMIv2. Annoying, Annoying, Annoying. It looks like we > > should be fixing > > this in SMIng. > > > > > > ============================ > > Notification sequence number > > ============================ > > In order for the manager and agent to be synchronized > > regarding alarms a > > sequence number > > mechanism of alarms are useful. Every alarmRaise carries a > > sequence number > > which also is > > stored in the alarmActiveTable. > > Why is it useful: > > > > a) It is a useful index for the manager to map its alarms to > > the ones in > > alarmActiveTable. > > b) It can be used as an indicatin of missed alarms if there > > are wholes in > > the > > sequence. > > (Of course trap filtering makes this not too useful...) > > > > > > Well, the alarmActiveLogIndex can serve as this. > > > > > > > > ============================== > > OBJECT-TYPE descriptions > > ============================ > > > > Below follows some, I hope ;) , improvements on the object > > descriptions: > > > > > > > > Thanks for the suggestions. We'll give them a bit more a read > > and see if > > there is stuff we should incorporate. > > > > > > ********************* > > * ITU-ALARM modules * > > ********************* > > > > Severity TC > > ------------------- > > What is the motivation for not using the same values as X733? > > See below. > > I assume one of the reasons is not having 0 as value in the > enumerated > > since it is not recommended in SMIv1. > > Anyhow, I recommend that we reuse the values and possibly move > > indeterminate(0) > > to > > something else. > > > > X733 ITU-ALARM-TC > > ==================================== > > indeterminate(0), cleared (1), > > critical(1), indeterminate (2), > > major(2), critical (3), > > minor(3), major (4), > > warning(4), minor (5), > > cleared(5) warning (6) > > > > > > > > Hmm. The no enumerated 0 was a factor. I also think this is > > an attempt to be able to use the same indices in the > > alarmModelTable as in the ituAlarmTable. There are rowPointers > > between the two, but I still think this is a good goal and > > if we don't use 0 we can never match the X733 anyways. > > > > > > ituAlarmAdditionalText > > ------------------------- > > Change DisplayString to SNMPAdminString. > > > > > > Thanks. I didn't realize I'd missed that one. > > > > > > IANAItuProbableCause > > ---------------------- > > I have serious problems with probable cause both in the old > > ITU standards > > and > > now when > > applied to SNMP. > > The problem is that the definition lacks extensibility. The > > values in X733 > > M3100 etc > > are for transmission systems and not useful for modern > > systems. But since it > > is > > not > > an OID structure it is impossible to extend for new standards > > and enterprise > > > > specific values. This has resulted in different vendors just > > added to the > > enum, > > which typically implies collisions when integrating several MIBs. > > > > Any thoughts? > > > > > > Well, I hate identifying things via OIDs. My preferred > > solution, and what > > we've done here, is to create an IANA owned enumerated list. > > It provides > > one stop shopping for values and extensibility. > > > > Thanks again for all the comments, > > > > Sharon > > > > > Stefan Wallin Data Ductus AB +46 70 5233262 stefan.wallin@dataductus.se From owner-disman@dorothy.bmc.com Thu Jan 10 04:42:46 2002 Received: from babbler.bmc.com (firebird.bmc.com [198.207.223.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12199 for ; Thu, 10 Jan 2002 04:42:45 -0500 (EST) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g0A9io918261; Thu, 10 Jan 2002 03:44:54 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id BAA18229 for disman-list; Thu, 10 Jan 2002 01:40:13 -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 BAA18223; Thu, 10 Jan 2002 01:40:10 -0800 (PST) Received: from mx-us-hou-2-int.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id g0A9ctU29367; Thu, 10 Jan 2002 03:38:55 -0600 (CST) Received: from mumm.ibr.cs.tu-bs.de (mumm.ibr.cs.tu-bs.de [134.169.34.33]) by mx-us-hou-2-int.bmc.com (Postfix) with SMTP id 48EB61FF02F; Thu, 10 Jan 2002 09:30:56 -0600 (CST) Received: from haerke.ibr.cs.tu-bs.de (IDENT:root@haerke.ibr.cs.tu-bs.de [134.169.34.84]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.0) with ESMTP id KAA26392; Thu, 10 Jan 2002 10:41:16 +0100 (MET) Received: (from schoenw@localhost) by haerke.ibr.cs.tu-bs.de (8.11.6/8.11.6) id g0A9fGT00478; Thu, 10 Jan 2002 10:41:16 +0100 Date: Thu, 10 Jan 2002 10:41:16 +0100 Message-Id: <200201100941.g0A9fGT00478@haerke.ibr.cs.tu-bs.de> X-Authentication-Warning: haerke.ibr.cs.tu-bs.de: schoenw set sender to schoenw@ibr.cs.tu-bs.de using -f From: Juergen Schoenwaelder To: rpresuhn@dorothy.bmc.com Cc: disman@dorothy.bmc.com In-reply-to: <200201100010.QAA13532@dorothy.bmc.com> (message from Randy Presuhn on Wed, 9 Jan 2002 16:10:08 -0800 (PST)) Subject: Re: alarm corelation at NOMS 2002 References: <200201100010.QAA13532@dorothy.bmc.com> Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list >>>>> Randy Presuhn writes: Randy> I was looking at the technical program for Randy> http://www.comsoc.org/confs/noms/2002/Program1.html and see Randy> that they're doing a session on alarm corelation. Does anyone Randy> have more detail on this? Alarm correlation is an ongoing topic on IM and NOMS conferences for several years now. It is obviously an interesting problem where lots of algorithms exist and there is still room for new ones. If you seek more information about this particular session at NOMS 2002, you may want to contact the session chair Joe Hellerstein or even better just go there. :-) /js -- Juergen Schoenwaelder University of Osnabrueck Dept. of Mathematics and Computer Science Phone: +49 541 969 2483 Albrechtstr. 28, 49069 Osnabrueck, Germany Fax: +49 541 969 2770 From owner-disman@dorothy.bmc.com Thu Jan 10 16:49:53 2002 Received: from babbler.bmc.com (camaro.bmc.com [198.207.223.231]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24572 for ; Thu, 10 Jan 2002 16:49:53 -0500 (EST) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g0ALppx23097; Thu, 10 Jan 2002 15:51:51 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id NAA02404 for disman-list; Thu, 10 Jan 2002 13:45:52 -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 NAA02399 for ; Thu, 10 Jan 2002 13:45:47 -0800 (PST) Received: from mx-us-hou-2-int.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id g0ALiWB28922 for ; Thu, 10 Jan 2002 15:44:32 -0600 (CST) Received: from hoemail2.firewall.lucent.com (hoemail2.lucent.com [192.11.226.163]) by mx-us-hou-2-int.bmc.com (Postfix) with SMTP id 7C52B1FF078 for ; Thu, 10 Jan 2002 21:36:33 -0600 (CST) Received: from nj7460exch001h.wins.lucent.com (h135-17-42-36.lucent.com [135.17.42.36]) by hoemail2.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g0ALkuW09072 for ; Thu, 10 Jan 2002 16:46:56 -0500 (EST) Received: by nj7460exch001h.ho.lucent.com with Internet Mail Service (5.5.2650.21) id ; Thu, 10 Jan 2002 16:46:56 -0500 Message-ID: <2E12619580C0D1118C6400805F9F4C950D7CED57@nj7460exch001u.ho.lucent.com> From: "Lam, Hing-Kam (Kam)" To: "'disman@dorothy.bmc.com'" Subject: Progressing the Condition/ARC MIB Date: Thu, 10 Jan 2002 16:46:53 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C19A20.517CF820" 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_000_01C19A20.517CF820 Content-Type: text/plain; charset="iso-8859-1" In the Salt Lake City meeting, the Condition/ARC MIB http://www.ietf.org/internet-drafts/draft-ietf-disman-conditionmib-01.txt was discussed and some open issues were noted (see the meeting details posted by Randy on December 18). To progress the Condition/ARC MIB, I have extrated those open issues to here to solicite your input. The issues are mainly related to the terminology, definition, and relationship with the Alarm MIB (Sections 3, 4 and 5 of the document). Attached is the modified Sections 3, 4, & 5 for your comments. > 4. Condition MIB and ARC MIB > - changes from version 00 to version 01 > - open issues > - terminology - condition to be taken on the mailing list - Kam to > initiate the thread One of the comments on the document is that it should point to the alarm MIB for the definitions. Agree. Once the definitions (Error, Fault, Alarm, Alarm Raised, Alarm Cleared, Event, and Notification) are removed, the only term left is Condition. So I think the current Section 3.1 "Terminology" can be deleted and embed the definition of Condition in the first couple paragraphs at the beginning of Section 3 as follow. The Condition MIB module defines MIB objects and notifications that provide mechanism to monitor abnormal conditions currently active and the history of abnormal conditions being set and cleared on a managed system. The list of abnormal conditions that can be monitored by using this MIB are based on the Probable Causes defined in ITU-T Recommendations M.3100, X.733, and X.736. A textual convention, IANAItuProbableCause, has been defined in the Alarm MIB to assign values to the ITU-T Probable Causes. The IANAItuProbableCause textual convention is being used by the Condition MIB to represent the abnormal conditions. > - Alarm Raised and Clear - should point to the Alarm MIB Agree. See the attached file, Section 3. > - Alarm type definition - delete section 3.2 Agree. See the attached file, Section 3. > - Section 4.1 readability - text needs fixing, diagram should be taken > out Agree. See the attached file, Section 4.1. The diagram and associated text have been deleted. > - change 'clarification' in Section 5 that says that when a resource is > in ARC mode active alarm information SHALL be available for retrieval by > the managing system - change active alarm with condition information Agree. See the attached file, Section 5, third paragraph, last sentence. > - section 5.1 - ARC impact on alarm notifications - needs to be further > worked on the list. The text has been modified to describe the general impact on alarm notifications according to M.3100 Amendment 3, and not to describe its impact on specific notifications, such as those in the Alarm MIB and Condition MIB. See attached file, Section 5.1. > - relationship with Alarm MIB - Sharon to propose text on the mailing > list To be provided. Any input or suggestion on this item. Regards, Kam <> ------_=_NextPart_000_01C19A20.517CF820 Content-Type: text/plain; name="cond_mib_sec3-4-5.txt" Content-Disposition: attachment; filename="cond_mib_sec3-4-5.txt" Content-Transfer-Encoding: quoted-printable 3. Introduction The scope of this document is target for network administrators = responsible=20 for managing the operations of network resources. This document = contains=20 two MIB modules: Condition MIB module and ARC MIB module. The Condition MIB module defines MIB objects and notifications that=20 provide mechanism to monitor abnormal conditions currently active=20 and the history of abnormal conditions being set and cleared on a=20 managed system. The list of abnormal conditions that can be monitored by using this=20 MIB are based on the Probable Causes defined in ITU-T = Recommendations=20 M.3100, X.733, and X.736. A textual convention, = IANAItuProbableCause,=20 has been defined in the Alarm MIB to assign values to the ITU-T=20 Probable Causes. The IANAItuProbableCause textual convention is = being=20 used by the Condition MIB to represent the abnormal conditions.=20 =20 The ARC MIB provides a mechanism for a manager to suppress or defer=20 the reporting of abnormal conditions based on the resource and=20 condition type. In this document, the terms Alarm, Alarm Raise, and Alarm Clear=20 are used according to the definition defined in the Alarm MIB = document. =20 4. Condition MIB Overview 4.1 Relationship with the Alarm MIB [*** to be provided ***] 4.2 Structure of the Condition MIB The Condition MIB provides a mechanism for a manager to: (1) retrieve information of current conditions in a system,=20 and its condition history, (2) receive an unified notification of the occurrence of an = condition, (3) suppress the alarm notification based on the condition severity = level. =20 This MIB module defines three tables. All active standing = conditions can be retrieved from the condActiveTable. As standing conditions=20 are cleared, they are moved from the condActiveTable to = condRetiredTable. The third table condTransientTable stores the information of all = transient=20 conditions. Two notifications are defined for multiple notification types:=20 condActiveEvent, and condRetiredEvent. Both notifications specify = the condition information from its variables (e.g., condition location,=20 condition category, level of severity, and probable cause). =20 Notifications are generated based on the value of = condNotificationSelection.=20 A SNMP agent sends notifications based on the level of severity of = the =20 conditions. It is the responsibility of the manager to periodically synchronize with the agent using the condActiveTable and = condRetiredTable to determine if any condition notification have been missed. 5. ARC MIB Overview There is a need to provide a mechanism for controlling the reporting = of alarm conditions of resources in a network device. For examples,=20 (a) inhibiting the reporting of alarm conditions of a resource until = the resource is problem-free, (b) inhibiting the reporting of alarm=20 conditions of a resource for a specified time period, or=20 (c) inhibiting the reporting of alarm conditions of a resource=20 until explicitly allowed later on by the managing system.=20 The alarm reporting control (ARC) feature provides an automatic=20 in-service provisioning capability. It allows sufficient time for=20 service setup, customer testing, and other maintenance activities in = an "alarm-free" state. Once a resource is "problem-free",=20 alarm reporting is automatically (or manually) turned on=20 (i.e., allowed). By putting a network resource in ARC mode, (i.e., either NALM,=20 NALM-TI,NALM-QI, or NALM-QI-CD), the technicians and=20 managing systems will not be flooded with unnecessary work items=20 during operations activities such as service provisioning and=20 network setup/teardown. This will reduce maintenance costs and=20 improve the operation and maintenance of these systems. Putting a network resource in ARC mode shall not affect the=20 availability of retrieval of the active condition information. ITU-T Recommendation M.3100 Amendment 3 [M.3100 Amd3] provides the=20 business requirements, analysis, and design of the Alarm Reporting=20 Control Feature.=20 This MIB module defines the SNMP objects to support a subset of=20 the ARC functions described in M.3100 Amd3. In particular, it = defines a table that contains the ARC setting for the resources in a system. Management objects for defining and storing alarms, including active = and history alarms, standing and transient alarms, are described in=20 the Alarm MIB, ITU Alarm MIB, and Condition MIB. 5.1 ARC Impact on Alarm Notifications=20 - For condition raised prior to entering ARC mode, reporting=20 of alarm raised and alarm cleared will be sent as usual.=20 That it, ARC has no impacts. =09 - For condition raised after entering ARC mode and also cleared before exiting ARC mode, no reporting of alarm raised will be=20 sent and no reporting of alarm cleared will be sent. - For condition raised after entering ARC mode and cleared=20 after exiting ARC mode, the reporting of alarm raised will be=20 deferred until the moment of exiting ARC mode. The reporting of = alarm clear will be sent as usual (i.e., at the time of alarm=20 cleared). Further details of ARC impact on alarm notifications can be found = in M.3100 Amendment 3. ------_=_NextPart_000_01C19A20.517CF820-- From owner-disman@dorothy.bmc.com Thu Jan 10 20:01:07 2002 Received: from babbler.bmc.com (camaro.bmc.com [198.207.223.231]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26938 for ; Thu, 10 Jan 2002 20:01:07 -0500 (EST) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g0B13E117190; Thu, 10 Jan 2002 19:03:14 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id QAA03152 for disman-list; Thu, 10 Jan 2002 16:57:06 -0800 (PST) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id QAA03146 for disman@dorothy.bmc.com; Thu, 10 Jan 2002 16:57:02 -0800 (PST) Date: Thu, 10 Jan 2002 16:57:02 -0800 (PST) From: Randy Presuhn Message-Id: <200201110057.QAA03146@dorothy.bmc.com> To: disman@dorothy.bmc.com Subject: RE: time stamp of alarms in ALARM MIB Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list Content-Transfer-Encoding: 8bit Hi - Proposed wording for both of the objects with DateAndTime syntax: Implementations MUST include the offset from UTC, if available. Implementation in environments in which the UTC offset is not available is NOT RECOMMENDED. Just a bit stronger than the "SHOULD", leaving very little wiggle room. ------------------------------------------------------ Randy Presuhn BMC Software, Inc. 1-3141 randy_presuhn@bmc.com 2141 North First Street Tel: +1 408 546-1006 San José, California 95131 USA ------------------------------------------------------ My opinions and BMC's are independent variables. ------------------------------------------------------ From owner-disman@dorothy.bmc.com Thu Jan 10 20:42:04 2002 Received: from babbler.bmc.com (firebird.bmc.com [198.207.223.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27454 for ; Thu, 10 Jan 2002 20:42:04 -0500 (EST) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g0B1iCf20339; Thu, 10 Jan 2002 19:44:13 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id RAA03398 for disman-list; Thu, 10 Jan 2002 17:38:48 -0800 (PST) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id RAA03321; Thu, 10 Jan 2002 17:30:49 -0800 (PST) Date: Thu, 10 Jan 2002 17:30:49 -0800 (PST) From: Randy Presuhn Message-Id: <200201110130.RAA03321@dorothy.bmc.com> To: agentx@dorothy.bmc.com, disman@dorothy.bmc.com Subject: disman/agentx FTP server update Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list Content-Transfer-Encoding: 7bit Hi - We're in the process of migrating the FTP site for the disman and agentx mailing lists to a new box in San Jose. (The folks in Texas have been complaining for over a year about the ominous sounds emanating from the old box in Houston.) There might be temporary reachability problems as the new DNS configuration propagates. If you have trouble reaching "amethyst.bmc.com", please try "new-amethyst.bmc.com" If both fail, or if problems persist for more than a day, please let me know. Mail will be archived on both systems until the cutover is complete. ------------------------------------------------------ Randy Presuhn BMC Software, Inc. 1-3141 randy_presuhn@bmc.com 2141 North First Street Tel: +1 408 546-1006 San José, California 95131 USA ------------------------------------------------------ My opinions and BMC's are independent variables. ------------------------------------------------------ From owner-disman@dorothy.bmc.com Fri Jan 11 00:02:05 2002 Received: from babbler.bmc.com (firebird.bmc.com [198.207.223.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA01833 for ; Fri, 11 Jan 2002 00:02:05 -0500 (EST) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g0B54Cg04124; Thu, 10 Jan 2002 23:04:13 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id UAA04353 for disman-list; Thu, 10 Jan 2002 20:59:21 -0800 (PST) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id UAA04347 for disman@dorothy.bmc.com; Thu, 10 Jan 2002 20:59:17 -0800 (PST) Date: Thu, 10 Jan 2002 20:59:17 -0800 (PST) From: Randy Presuhn Message-Id: <200201110459.UAA04347@dorothy.bmc.com> To: disman@dorothy.bmc.com Subject: Re: NOTIFICATION-LOG-MIB Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list Content-Transfer-Encoding: 7bit Hi - > Message-ID: <3C3CAEF8.343D233E@cisco.com> > Date: Wed, 09 Jan 2002 12:58:32 -0800 > From: Ramanathan Kavasseri > To: "Nallappa, Bhashyam" > Cc: disman@dorothy.bmc.com > Subject: Re: NOTIFICATION-LOG-MIB > References: <4D38F1A1C17DD411931F00508BAF728ED6808A@bethexc01.armillaire.com> .. > managed systems have limitations on how much memory they > can dedicate to the notification log mib. The notif log mib, > IMHO, isn't a permanent store for logged notifications. Notifs > should be kept for a "reasonable period of time" so that > NMSes can periodically poll for lost notifications. A reasonable > time could be 10 minutes, an hour, 24 hours. Anything logged > on the managed device much beyond that may be of questionable > value, IMHO. ... RFC 3014 is a bit more specific than this. Don't forget that nlmConfigGlobalAgeOut and nlmConfigGlobalEntryLimit control the behaviour, and that the big unknown in any case will be the rate of notification arrival. ------------------------------------------------------ Randy Presuhn BMC Software, Inc. 1-3141 randy_presuhn@bmc.com 2141 North First Street Tel: +1 408 546-1006 San José, California 95131 USA ------------------------------------------------------ My opinions and BMC's are independent variables. ------------------------------------------------------ From owner-disman@dorothy.bmc.com Fri Jan 11 18:41:36 2002 Received: from babbler.bmc.com (camaro.bmc.com [198.207.223.231]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02967 for ; Fri, 11 Jan 2002 18:41:36 -0500 (EST) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g0BNhkG03693; Fri, 11 Jan 2002 17:43:46 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id PAA21983 for disman-list; Fri, 11 Jan 2002 15:37: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 PAA21978 for ; Fri, 11 Jan 2002 15:37:50 -0800 (PST) Received: from mx-us-hou-1-int.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id g0BNaYq22387 for ; Fri, 11 Jan 2002 17:36:35 -0600 (CST) Received: from gamma.isi.edu (unknown [128.9.144.145]) by mx-us-hou-1-int.bmc.com (Postfix) with SMTP id 4F0D520F01A for ; Fri, 11 Jan 2002 23:27:21 -0600 (CST) Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id g0BNd1H24099; Fri, 11 Jan 2002 15:39:01 -0800 (PST) Message-Id: <200201112339.g0BNd1H24099@gamma.isi.edu> To: IETF-Announce: ; Subject: RFC 3231 on Schedule MIB Cc: rfc-ed@ISI.EDU, disman@dorothy.bmc.com Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Fri, 11 Jan 2002 15:39:01 -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 3231 Title: Definitions of Managed Objects for Scheduling Management Operations Author(s): D. Levi, J. Schoenwaelder Status: Standards Track Date: January 2002 Mailbox: dlevi@nortelnetworks.com, schoenw@ibr.cs.tu-bs.de Pages: 29 Characters: 61308 Obsoletes: 2591 I-D Tag: draft-ietf-disman-schedule-mib-v2-04.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3231.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 a set of managed objects that are used to schedule management operations periodically or at specified dates and times. This document obsoletes RFC 2591. This document is a product of the Distrubuted 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: <020111153500.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3231 --OtherAccess Content-Type: Message/External-body; name="rfc3231.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <020111153500.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- From owner-disman@dorothy.bmc.com Fri Jan 11 21:02:02 2002 Received: from babbler.bmc.com (firebird.bmc.com [198.207.223.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA04444 for ; Fri, 11 Jan 2002 21:02:02 -0500 (EST) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g0C246214576; Fri, 11 Jan 2002 20:04:06 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id RAA22555 for disman-list; Fri, 11 Jan 2002 17:59:15 -0800 (PST) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id RAA22549 for disman@dorothy.bmc.com; Fri, 11 Jan 2002 17:59:11 -0800 (PST) Date: Fri, 11 Jan 2002 17:59:11 -0800 (PST) From: Randy Presuhn Message-Id: <200201120159.RAA22549@dorothy.bmc.com> To: disman@dorothy.bmc.com Subject: Re: RFC 3231 on Schedule MIB Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list Content-Transfer-Encoding: 7bit Hi - > Message-Id: <200201112339.g0BNd1H24099@gamma.isi.edu> > To: IETF-Announce: ; > Subject: RFC 3231 on Schedule MIB > Cc: rfc-ed@ISI.EDU, disman@dorothy.bmc.com > Date: Fri, 11 Jan 2002 15:39:01 -0800 > From: RFC Editor ... > A new Request for Comments is now available in online RFC libraries. > > > RFC 3231 > > Title: Definitions of Managed Objects for Scheduling > Management Operations > Author(s): D. Levi, J. Schoenwaelder > Status: Standards Track ... THANK YOU & Congratulations to the authors, the WG, and everyone else who helped bring this to a successful conclusion! ------------------------------------------------------ Randy Presuhn BMC Software, Inc. 1-3141 randy_presuhn@bmc.com 2141 North First Street Tel: +1 408 546-1006 San José, California 95131 USA ------------------------------------------------------ My opinions and BMC's are independent variables. ------------------------------------------------------ From owner-disman@dorothy.bmc.com Mon Jan 14 16:07:11 2002 Received: from babbler.bmc.com (camaro.bmc.com [198.207.223.231]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19194 for ; Mon, 14 Jan 2002 16:07:11 -0500 (EST) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g0EL9N713316; Mon, 14 Jan 2002 15:09:23 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id NAA21997 for disman-list; Mon, 14 Jan 2002 13:02: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 NAA21991; Mon, 14 Jan 2002 13:02:12 -0800 (PST) Received: from mx-us-hou-1-int.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id g0EL0tQ13621; Mon, 14 Jan 2002 15:00:55 -0600 (CST) Received: from ierw.net.avaya.com (unknown [198.152.13.101]) by mx-us-hou-1-int.bmc.com (Postfix) with SMTP id 6094B20F09D; Mon, 14 Jan 2002 20:51:06 -0600 (CST) Received: from ierw.net.avaya.com (localhost [127.0.0.1]) by ierw.net.avaya.com (8.9.3+Sun/8.9.3) with ESMTP id QAA02064; Mon, 14 Jan 2002 16:01:50 -0500 (EST) Received: from IS0004AVEXU1.global.avaya.com (h149-49-38-91.avaya.com [149.49.38.91]) by ierw.net.avaya.com (8.9.3+Sun/8.9.3) with ESMTP id QAA02020; Mon, 14 Jan 2002 16:01:49 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: time stamp of alarms in ALARM MIB Date: Mon, 14 Jan 2002 23:02:24 +0200 Message-ID: Thread-Topic: time stamp of alarms in ALARM MIB Thread-Index: AcGaO6lX6TWWrugcTWKOlSCLqm9uMQC+mCoA From: "Romascanu, Dan (Dan)" To: "Randy Presuhn" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by dorothy.bmc.com id NAA21992 Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list Content-Transfer-Encoding: 8bit The proposed change is fine with me. Regards, Dan > -----Original Message----- > From: Randy Presuhn [mailto:rpresuhn@dorothy.bmc.com] > Sent: Friday, January 11, 2002 2:57 AM > To: disman@dorothy.bmc.com > Subject: RE: time stamp of alarms in ALARM MIB > > > Hi - > > Proposed wording for both of the objects with DateAndTime > syntax: > > Implementations MUST include the offset from UTC, > if available. Implementation in environments in which > the UTC offset is not available is NOT RECOMMENDED. > > Just a bit stronger than the "SHOULD", leaving very > little wiggle room. > > ------------------------------------------------------ > Randy Presuhn BMC Software, Inc. 1-3141 > randy_presuhn@bmc.com 2141 North First Street > Tel: +1 408 546-1006 San José, California 95131 USA > ------------------------------------------------------ > My opinions and BMC's are independent variables. > ------------------------------------------------------ > From owner-disman@dorothy.bmc.com Mon Jan 14 16:59:18 2002 Received: from babbler.bmc.com (firebird.bmc.com [198.207.223.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21296 for ; Mon, 14 Jan 2002 16:59:18 -0500 (EST) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g0EM1WG27082; Mon, 14 Jan 2002 16:01:32 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id NAA22262 for disman-list; Mon, 14 Jan 2002 13:56:17 -0800 (PST) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id NAA22256; Mon, 14 Jan 2002 13:56:14 -0800 (PST) Date: Mon, 14 Jan 2002 13:56:14 -0800 (PST) From: Randy Presuhn Message-Id: <200201142156.NAA22256@dorothy.bmc.com> To: minutes@ietf.org Subject: disman WG minutes Cc: disman@dorothy.bmc.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list Content-Transfer-Encoding: 8bit Hi - Minutes and slides for the disman WG session in Salt Lake City are at ftp://new-amethyst.bmc.com/pub/disman/ietf52/ ------------------------------------------------------ Randy Presuhn BMC Software, Inc. 1-3141 randy_presuhn@bmc.com 2141 North First Street Tel: +1 408 546-1006 San José, California 95131 USA ------------------------------------------------------ My opinions and BMC's are independent variables. ------------------------------------------------------ From owner-disman@dorothy.bmc.com Mon Jan 14 19:33:32 2002 Received: from babbler.bmc.com (firebird.bmc.com [198.207.223.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27217 for ; Mon, 14 Jan 2002 19:33:31 -0500 (EST) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g0F0Zjr20305; Mon, 14 Jan 2002 18:35:45 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id QAA26883 for disman-list; Mon, 14 Jan 2002 16:30:06 -0800 (PST) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id QAA26877 for disman@dorothy.bmc.com; Mon, 14 Jan 2002 16:30:03 -0800 (PST) Date: Mon, 14 Jan 2002 16:30:03 -0800 (PST) From: Randy Presuhn Message-Id: <200201150030.QAA26877@dorothy.bmc.com> To: disman@dorothy.bmc.com Subject: event mib operating on ranges Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list Content-Transfer-Encoding: 7bit Hi - In Salt Lake City, Ram reported that a difficulty that has arisen with the Event MIB is that it doesn't provide a convenient way to apply thresholding for a range of ports. He took the action item to provide an example to the WG mailing list. ------------------------------------------------------ Randy Presuhn BMC Software, Inc. 1-3141 randy_presuhn@bmc.com 2141 North First Street Tel: +1 408 546-1006 San José, California 95131 USA ------------------------------------------------------ My opinions and BMC's are independent variables. ------------------------------------------------------ From owner-disman@dorothy.bmc.com Mon Jan 14 19:35:20 2002 Received: from babbler.bmc.com (camaro.bmc.com [198.207.223.231]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27303 for ; Mon, 14 Jan 2002 19:35:20 -0500 (EST) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g0F0bYf20472; Mon, 14 Jan 2002 18:37:34 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id QAA26906 for disman-list; Mon, 14 Jan 2002 16:32:32 -0800 (PST) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id QAA26898 for disman@dorothy.bmc.com; Mon, 14 Jan 2002 16:32:28 -0800 (PST) Date: Mon, 14 Jan 2002 16:32:28 -0800 (PST) From: Randy Presuhn Message-Id: <200201150032.QAA26898@dorothy.bmc.com> To: disman@dorothy.bmc.com Subject: Log MIB / VACM clarification Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list Content-Transfer-Encoding: 7bit Hi - In Salt Lake City, Ram took on the action item of providing clarifying text for the Log MIB to explain that nothing special is needed of VACM to read a log record. ------------------------------------------------------ Randy Presuhn BMC Software, Inc. 1-3141 randy_presuhn@bmc.com 2141 North First Street Tel: +1 408 546-1006 San José, California 95131 USA ------------------------------------------------------ My opinions and BMC's are independent variables. ------------------------------------------------------ From owner-disman@dorothy.bmc.com Mon Jan 14 19:38:00 2002 Received: from babbler.bmc.com (camaro.bmc.com [198.207.223.231]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27355 for ; Mon, 14 Jan 2002 19:38:00 -0500 (EST) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g0F0eEZ20765; Mon, 14 Jan 2002 18:40:14 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id QAA26923 for disman-list; Mon, 14 Jan 2002 16:35:13 -0800 (PST) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id QAA26917 for disman@dorothy.bmc.com; Mon, 14 Jan 2002 16:35:09 -0800 (PST) Date: Mon, 14 Jan 2002 16:35:09 -0800 (PST) From: Randy Presuhn Message-Id: <200201150035.QAA26917@dorothy.bmc.com> To: disman@dorothy.bmc.com Subject: Log MIB cost/benefit ratios Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list Content-Transfer-Encoding: 7bit Hi - In Salt Lake City, Sharon took on a couple of action items to "do the math" so that we can assess the cost/benefit tradeoff for a couple of proposed changes to the Log MIB. 1) the question of whether adding a column to the nlmLogTable to report how many variable bindings are stored in nlmLogVariableType in order to reduce the number of queries needed for retrieval 2) the question of adding a variable to indicate the current log index for each named log ------------------------------------------------------ Randy Presuhn BMC Software, Inc. 1-3141 randy_presuhn@bmc.com 2141 North First Street Tel: +1 408 546-1006 San José, California 95131 USA ------------------------------------------------------ My opinions and BMC's are independent variables. ------------------------------------------------------ From owner-disman@dorothy.bmc.com Mon Jan 14 19:40:32 2002 Received: from babbler.bmc.com (firebird.bmc.com [198.207.223.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27444 for ; Mon, 14 Jan 2002 19:40:32 -0500 (EST) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g0F0gk420973; Mon, 14 Jan 2002 18:42:46 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id QAA26940 for disman-list; Mon, 14 Jan 2002 16:37:45 -0800 (PST) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id QAA26934 for disman@dorothy.bmc.com; Mon, 14 Jan 2002 16:37:42 -0800 (PST) Date: Mon, 14 Jan 2002 16:37:42 -0800 (PST) From: Randy Presuhn Message-Id: <200201150037.QAA26934@dorothy.bmc.com> To: disman@dorothy.bmc.com Subject: log age-out granularity Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list Content-Transfer-Encoding: 7bit Hi - A question arose in Salt Lake City: - should we add an object similar to nlmLogConfigAgeout for each named log? The rationale is left as an exercise for the reader. ------------------------------------------------------ Randy Presuhn BMC Software, Inc. 1-3141 randy_presuhn@bmc.com 2141 North First Street Tel: +1 408 546-1006 San José, California 95131 USA ------------------------------------------------------ My opinions and BMC's are independent variables. ------------------------------------------------------ From owner-disman@dorothy.bmc.com Mon Jan 14 19:44:42 2002 Received: from babbler.bmc.com (firebird.bmc.com [198.207.223.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27515 for ; Mon, 14 Jan 2002 19:44:42 -0500 (EST) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g0F0kur21423; Mon, 14 Jan 2002 18:46:56 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id QAA26995 for disman-list; Mon, 14 Jan 2002 16:41:54 -0800 (PST) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id QAA26989 for disman@dorothy.bmc.com; Mon, 14 Jan 2002 16:41:51 -0800 (PST) Date: Mon, 14 Jan 2002 16:41:51 -0800 (PST) From: Randy Presuhn Message-Id: <200201150041.QAA26989@dorothy.bmc.com> To: disman@dorothy.bmc.com Subject: StorageType in Event & Expression MIBS Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list Content-Transfer-Encoding: 7bit Hi - In Salt Lake City it was noted that the Event and Expression MIBs lack StorageType objects. Based on implementation reports and the sense of the room in Salt Lake City, Ram volunteered to make a proposal to add appropriate objects to these MIBs. ------------------------------------------------------ Randy Presuhn BMC Software, Inc. 1-3141 randy_presuhn@bmc.com 2141 North First Street Tel: +1 408 546-1006 San José, California 95131 USA ------------------------------------------------------ My opinions and BMC's are independent variables. ------------------------------------------------------ From owner-disman@dorothy.bmc.com Mon Jan 14 19:52:47 2002 Received: from babbler.bmc.com (firebird.bmc.com [198.207.223.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27730 for ; Mon, 14 Jan 2002 19:52:47 -0500 (EST) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g0F0t1E22208; Mon, 14 Jan 2002 18:55:02 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id QAA27041 for disman-list; Mon, 14 Jan 2002 16:50:34 -0800 (PST) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id QAA27035; Mon, 14 Jan 2002 16:50:30 -0800 (PST) Date: Mon, 14 Jan 2002 16:50:30 -0800 (PST) From: Randy Presuhn Message-Id: <200201150050.QAA27035@dorothy.bmc.com> To: andreaw@cisco.com Subject: DMTF ProbableCause beyond X.733 Cc: disman@dorothy.bmc.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list Content-Transfer-Encoding: 7bit Hi Andrea - In Salt Lake City we chatted about the DMTF's use of X.733 "probable cause" codes, and how the DMTF's events work had found it necessary to extend this list. We in the IETF disman (distributed management) working group would like to know what the DMTF extensions are, so that our related work, which also includes the M.3100 codes, does not diverge unnecessarily from what the DMTF has done in this space. We appreciate your help. ------------------------------------------------------ Randy Presuhn BMC Software, Inc. 1-3141 randy_presuhn@bmc.com 2141 North First Street Tel: +1 408 546-1006 San José, California 95131 USA ------------------------------------------------------ My opinions and BMC's are independent variables. ------------------------------------------------------ From owner-disman@dorothy.bmc.com Mon Jan 14 19:56:46 2002 Received: from babbler.bmc.com (firebird.bmc.com [198.207.223.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27820 for ; Mon, 14 Jan 2002 19:56:46 -0500 (EST) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g0F0x0122644; Mon, 14 Jan 2002 18:59:00 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id QAA27078 for disman-list; Mon, 14 Jan 2002 16:54:36 -0800 (PST) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id QAA27072 for disman@dorothy.bmc.com; Mon, 14 Jan 2002 16:54:33 -0800 (PST) Date: Mon, 14 Jan 2002 16:54:33 -0800 (PST) From: Randy Presuhn Message-Id: <200201150054.QAA27072@dorothy.bmc.com> To: disman@dorothy.bmc.com Subject: alarm / condition relationship Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list Content-Transfer-Encoding: 8bit Hi - Sharon took the action item in Salt Lake City to produce text on the relationship between conditions and alarms. ------------------------------------------------------ Randy Presuhn BMC Software, Inc. 1-3141 randy_presuhn@bmc.com 2141 North First Street Tel: +1 408 546-1006 San José, California 95131 USA ------------------------------------------------------ My opinions and BMC's are independent variables. ------------------------------------------------------ From owner-disman@dorothy.bmc.com Mon Jan 14 19:57:49 2002 Received: from babbler.bmc.com (firebird.bmc.com [198.207.223.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27835 for ; Mon, 14 Jan 2002 19:57:48 -0500 (EST) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g0F103R22809; Mon, 14 Jan 2002 19:00:03 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id QAA27090 for disman-list; Mon, 14 Jan 2002 16:55:39 -0800 (PST) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id QAA27084 for disman@dorothy.bmc.com; Mon, 14 Jan 2002 16:55:36 -0800 (PST) Date: Mon, 14 Jan 2002 16:55:36 -0800 (PST) From: Randy Presuhn Message-Id: <200201150055.QAA27084@dorothy.bmc.com> To: disman@dorothy.bmc.com Subject: replication discussion? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list Content-Transfer-Encoding: 8bit Hi - Any followup discussion to the Clustering Architecture / replication discussion in Salt Lake City? ------------------------------------------------------ Randy Presuhn BMC Software, Inc. 1-3141 randy_presuhn@bmc.com 2141 North First Street Tel: +1 408 546-1006 San José, California 95131 USA ------------------------------------------------------ My opinions and BMC's are independent variables. ------------------------------------------------------ From owner-disman@dorothy.bmc.com Mon Jan 14 20:09:11 2002 Received: from babbler.bmc.com (camaro.bmc.com [198.207.223.231]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28104 for ; Mon, 14 Jan 2002 20:09:11 -0500 (EST) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g0F1BPk23936; Mon, 14 Jan 2002 19:11:25 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id RAA27167 for disman-list; Mon, 14 Jan 2002 17:06:59 -0800 (PST) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id RAA27161; Mon, 14 Jan 2002 17:06:55 -0800 (PST) Date: Mon, 14 Jan 2002 17:06:55 -0800 (PST) From: Randy Presuhn Message-Id: <200201150106.RAA27161@dorothy.bmc.com> To: disman@dorothy.bmc.com, revab@timetra.com Subject: Re: FW: NOTIFICATION-LOG-MIB value objects instantiation question Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list Content-Transfer-Encoding: 7bit Hi Reva - > From: "Reva Bailey" > To: > Subject: FW: NOTIFICATION-LOG-MIB value objects instantiation question > Date: Mon, 14 Jan 2002 16:27:32 -0800 > Message-ID: ... > Well, no-one has answered my question. Too basic, I guess. > Will you please give me your opinion? If the first case > below is what is intended, then I'll have to go try and ... As I read the RFC, your interpretation (the first example) of the description is correct. Since the language is "must", an implementation that follows the second interpretation would have to be considered non-conformant. As a one-time toolkit developer, I know that supporting tables like this is possible in at least one environment, although it's really really ugly. ------------------------------------------------------ Randy Presuhn BMC Software, Inc. 1-3141 randy_presuhn@bmc.com 2141 North First Street Tel: +1 408 546-1006 San José, California 95131 USA ------------------------------------------------------ My opinions and BMC's are independent variables. ------------------------------------------------------ ... > > From: Reva Bailey [mailto:revab@timetra.com] > > Sent: Tuesday, January 08, 2002 3:51 PM > > To: disman@dorothy.bmc.com > > Subject: NOTIFICATION-LOG-MIB value objects instantiation question > > > > > > This is a basic SNMP object instantiation question, but I need help to > > interpret correctly the description clause of nlmLogVariableValueType > > because I am having problems getting my agent tool-kit to work the way > > I think it should :-(. > > > > nlmLogVariableValueType OBJECT-TYPE > > SYNTAX INTEGER { counter32(1), unsigned32(2), timeTicks(3), > > integer32(4), ipAddress(5), octetString(6), > > objectId(7), counter64(8), opaque(9) } > > MAX-ACCESS read-only > > STATUS current > > DESCRIPTION > > "The type of the value. One and only one of the value > > objects that follow must be instantiated, based on this type." > > ::= { nlmLogVariableEntry 3 } > > > > I interpret this to mean that if I have only one entry in the nlmLogTable > > and I do a getnext walk on the nlmLogVariableTable, I expect to see > > results like this: > > > > nlmLogVariableID."".8.1 = OID: sysUpTime.0 > > nlmLogVariableID."".8.2 = OID: snmpTrapOID.0 > > nlmLogVariableID."".8.3 = OID: ifIndex > > nlmLogVariableID."".8.4 = OID: ifAdminStatus > > nlmLogVariableID."".8.5 = OID: ifOperStatus > > nlmLogVariableValueType."".8.1 = timeTicks(3) > > nlmLogVariableValueType."".8.2 = objectId(7) > > nlmLogVariableValueType."".8.3 = integer32(4) > > nlmLogVariableValueType."".8.4 = integer32(4) > > nlmLogVariableValueType."".8.5 = integer32(4) > > nlmLogVariableTimeTicksVal."".8.1 = Timeticks: (305023) 0:50:50.23 > > nlmLogVariableInteger32Val."".8.3 = 5 > > nlmLogVariableInteger32Val."".8.4 = 1 > > nlmLogVariableInteger32Val."".8.5 = 2 > > nlmLogVariableOidVal."".8.2 = OID: linkDown > > > > But not like this: > > > > nlmLogVariableID."".8.1 = OID: sysUpTime.0 > > nlmLogVariableID."".8.2 = OID: snmpTrapOID.0 > > nlmLogVariableID."".8.3 = OID: ifIndex > > nlmLogVariableID."".8.4 = OID: ifAdminStatus > > nlmLogVariableID."".8.5 = OID: ifOperStatus > > nlmLogVariableValueType."".8.1 = timeTicks(3) > > nlmLogVariableValueType."".8.2 = objectId(7) > > nlmLogVariableValueType."".8.3 = integer32(4) > > nlmLogVariableValueType."".8.4 = integer32(4) > > nlmLogVariableValueType."".8.5 = integer32(4) > > nlmLogVariableCounter32Val."".8.1 = Counter32: 0 > > nlmLogVariableCounter32Val."".8.2 = Counter32: 0 > > nlmLogVariableCounter32Val."".8.3 = Counter32: 0 > > nlmLogVariableCounter32Val."".8.4 = Counter32: 0 > > nlmLogVariableCounter32Val."".8.5 = Counter32: 0 > > nlmLogVariableUnsigned32Val."".8.1 = Gauge32: 0 > > nlmLogVariableUnsigned32Val."".8.2 = Gauge32: 0 > > nlmLogVariableUnsigned32Val."".8.3 = Gauge32: 0 > > nlmLogVariableUnsigned32Val."".8.4 = Gauge32: 0 > > nlmLogVariableUnsigned32Val."".8.5 = Gauge32: 0 > > nlmLogVariableTimeTicksVal."".8.1 = Timeticks: (305023) 0:50:50.23 > > nlmLogVariableTimeTicksVal."".8.2 = Timeticks: (0) 0:00:00.00 > > nlmLogVariableTimeTicksVal."".8.3 = Timeticks: (0) 0:00:00.00 > > nlmLogVariableTimeTicksVal."".8.4 = Timeticks: (0) 0:00:00.00 > > nlmLogVariableTimeTicksVal."".8.5 = Timeticks: (0) 0:00:00.00 > > nlmLogVariableInteger32Val."".8.1 = 0 > > nlmLogVariableInteger32Val."".8.2 = 0 > > nlmLogVariableInteger32Val."".8.3 = 5 > > nlmLogVariableInteger32Val."".8.4 = 1 > > nlmLogVariableInteger32Val."".8.5 = 2 > > nlmLogVariableOctetStringVal."".8.1 = "" > > nlmLogVariableOctetStringVal."".8.2 = "" > > nlmLogVariableOctetStringVal."".8.3 = "" > > nlmLogVariableOctetStringVal."".8.4 = "" > > nlmLogVariableOctetStringVal."".8.5 = "" > > nlmLogVariableIpAddressVal."".8.1 = IpAddress: 0.0.0.0 > > nlmLogVariableIpAddressVal."".8.2 = IpAddress: 0.0.0.0 > > nlmLogVariableIpAddressVal."".8.3 = IpAddress: 0.0.0.0 > > nlmLogVariableIpAddressVal."".8.4 = IpAddress: 0.0.0.0 > > nlmLogVariableIpAddressVal."".8.5 = IpAddress: 0.0.0.0 > > nlmLogVariableOidVal."".8.1 = OID: ccitt > > nlmLogVariableOidVal."".8.2 = OID: linkDown > > nlmLogVariableOidVal."".8.3 = OID: ccitt > > nlmLogVariableOidVal."".8.4 = OID: ccitt > > nlmLogVariableOidVal."".8.5 = OID: ccitt > > nlmLogVariableCounter64Val."".8.1 = Counter64: 0 > > nlmLogVariableCounter64Val."".8.2 = Counter64: 0 > > nlmLogVariableCounter64Val."".8.3 = Counter64: 0 > > nlmLogVariableCounter64Val."".8.4 = Counter64: 0 > > nlmLogVariableCounter64Val."".8.5 = Counter64: 0 > > nlmLogVariableOpaqueVal."".8.1 = OPAQUE: > > nlmLogVariableOpaqueVal."".8.2 = OPAQUE: > > nlmLogVariableOpaqueVal."".8.3 = OPAQUE: > > nlmLogVariableOpaqueVal."".8.4 = OPAQUE: > > nlmLogVariableOpaqueVal."".8.5 = OPAQUE: > > > > Am I correct? Are both styles correct? ... From owner-disman@dorothy.bmc.com Tue Jan 15 06:37:39 2002 Received: from babbler.bmc.com (camaro.bmc.com [198.207.223.231]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18666 for ; Tue, 15 Jan 2002 06:37:39 -0500 (EST) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g0FBbW722386; Tue, 15 Jan 2002 05:37:32 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id DAA09983 for disman-list; Tue, 15 Jan 2002 03:32:27 -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 DAA09978 for ; Tue, 15 Jan 2002 03:32:23 -0800 (PST) Received: from mx-us-hou-2-int.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id g0FBV6t21125 for ; Tue, 15 Jan 2002 05:31:06 -0600 (CST) Received: from watcher.dataductus.se (mail.dataductus.se [213.199.99.201]) by mx-us-hou-2-int.bmc.com (Postfix) with SMTP id A2F931FF042 for ; Tue, 15 Jan 2002 11:22:45 -0600 (CST) Received: (qmail 955 invoked from network); 15 Jan 2002 11:33:23 -0000 Received: from nsmail.dataductus.se (192.168.100.43) by 0 with SMTP; 15 Jan 2002 11:33:23 -0000 Received: from dataductus.com ([192.168.100.240]) by nsmail.dataductus.se (Netscape Messaging Server 4.15) with SMTP id GPZ9FS00.GVH for ; Tue, 15 Jan 2002 12:33:28 +0100 From: "Stefan Wallin" To: "Disman" Subject: alarmModelEntry notInService Date: Tue, 15 Jan 2002 12:33:26 +0100 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0000_01C19DC0.D433A2C0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list This is a multi-part message in MIME format. ------=_NextPart_000_0000_01C19DC0.D433A2C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi! Is there a definition of an alarmModelEntry being in state notInService? Possible interpretations: 1) In conflict with NOTIFICATION-MIB, so I assume wrong - notifications not sent - activeAlarmTable NOT updated 2) The entry does not represent a possible alarm: - notifications sent, (depending on NOTIFICATION-MIB) - activeAlarmTable NOT updated best regards Stefan Wallin ------=_NextPart_000_0000_01C19DC0.D433A2C0 Content-Type: text/x-vcard; name="Stefan Wallin.vcf" Content-Disposition: attachment; filename="Stefan Wallin.vcf" Content-Transfer-Encoding: quoted-printable BEGIN:VCARD VERSION:2.1 N:Wallin;Stefan FN:Stefan Wallin ORG:Data Ductus TEL;WORK;VOICE:+46 910 732305 TEL;HOME;VOICE:+46 910 31114 TEL;CELL;VOICE:+46 70 5233262 TEL;WORK;FAX:+46 910 55756 ADR;WORK:;;Torget 6;Skellefte=E5;;93131;Sweden LABEL;WORK;ENCODING=3DQUOTED-PRINTABLE:Torget 6=3D0D=3D0ASkellefte=3DE5 = 93131=3D0D=3D0ASweden ADR;HOME:;;Stupv=E4gen 3;Skelleftehamn;;93233;Sweden LABEL;HOME;ENCODING=3DQUOTED-PRINTABLE:Stupv=3DE4gen = 3=3D0D=3D0ASkelleftehamn 93233=3D0D=3D0ASweden URL: URL:http://www.dataductus.se EMAIL;PREF;INTERNET:stefan.wallin@dataductus.se REV:20020108T135650Z END:VCARD ------=_NextPart_000_0000_01C19DC0.D433A2C0-- From owner-disman@dorothy.bmc.com Tue Jan 15 08:27:07 2002 Received: from babbler.bmc.com (camaro.bmc.com [198.207.223.231]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21821 for ; Tue, 15 Jan 2002 08:27:06 -0500 (EST) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g0FDTKa04679; Tue, 15 Jan 2002 07:29:21 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id FAA10241 for disman-list; Tue, 15 Jan 2002 05:23:06 -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 FAA10235; Tue, 15 Jan 2002 05:23:01 -0800 (PST) Received: from mx-us-hou-2-int.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id g0FDLiw13861; Tue, 15 Jan 2002 07:21:44 -0600 (CST) Received: from e21.nc.us.ibm.com (e21.nc.us.ibm.com [32.97.136.227]) by mx-us-hou-2-int.bmc.com (Postfix) with SMTP id E00731FF07F; Tue, 15 Jan 2002 13:13:23 -0600 (CST) Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by e21.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id HAA38214; Tue, 15 Jan 2002 07:20:00 -0600 Received: from d04mc200.raleigh.ibm.com (d04mc200.raleigh.ibm.com [9.67.228.62]) by southrelay02.raleigh.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id g0FDOAE26288; Tue, 15 Jan 2002 08:24:11 -0500 Subject: Re: DMTF ProbableCause beyond X.733 To: Randy Presuhn Cc: andreaw@cisco.com, disman@dorothy.bmc.com, owner-disman@dorothy.bmc.com X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Robert Moore" Date: Tue, 15 Jan 2002 08:27:37 -0500 X-MIMETrack: Serialize by Router on D04MC200/04/M/IBM(Release 5.0.8 |June 18, 2001) at 01/15/2002 08:24:10 AM MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by dorothy.bmc.com id FAA10236 Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list Content-Transfer-Encoding: 8bit Hi Randy, I can answer this question as well as Andrea can. Understand, though, that I don't even participate in the Events WG, so all I can give you is what's in the current (i.e., Version 2.6 Preliminary) CIM Schema. I doubt that the WG is tweaking this further as we speak, but I don't know this for sure. I've also lost track of how these code points ended up in X.733, so I can't do the comparison for you. Here's the full set of values in the Events MOF, though: [Required, Description ( "An enumerated value that describes the probable cause of the " "situation which resulted in the AlertIndication."), Values {"Unknown", "Other", "Adapter Error", "Application Subsystem Failure", "Bandwidth Reduced", "Connection Establishment Error", "Communications Protocol Error", "Communications Subsystem Failure", "Configuration/Customization Error", "Congestion", "Corrupt Data", "CPU Cycles Limit Exceeded", "Dataset/Modem Error", "Degraded Signal", "DTE-DCE Interface Error", "Enclosure Door Open", "Equipment Malfunction", "Excessive Vibration", "File Format Error", "Fire Detected", "Flood Detected", "Framing Error", "HVAC Problem", "Humidity Unacceptable", "I/O Device Error", "Input Device Error", "LAN Error", "Non-Toxic Leak Detected", "Local Node Transmission Error", "Loss of Frame", "Loss of Signal", "Material Supply Exhausted", "Multiplexer Problem", "Out of Memory", "Output Device Error", "Performance Degraded", "Power Problem", "Pressure Unacceptable", "Processor Problem (Internal Machine Error)", "Pump Failure", "Queue Size Exceeded", "Receive Failure", "Receiver Failure", "Remote Node Transmission Error", "Resource at or Nearing Capacity", "Response Time Excessive", "Retransmission Rate Excessive", "Software Error", "Software Program Abnormally Terminated", "Software Program Error (Incorrect Results)", "Storage Capacity Problem", "Temperature Unacceptable", "Threshold Crossed", "Timing Problem", "Toxic Leak Detected", "Transmit Failure", "Transmitter Failure", "Underlying Resource Unavailable", "Version MisMatch", "Previous Alert Cleared", "Login Attempts Failed", "Software Virus Detected", "Hardware Security Breached", "Denial of Service Detected", "Security Credential MisMatch", "Invalid Access of Data Detected"}, MappingStrings {"Recommendation.ITU|X733.Probable cause"} ] uint16 ProbableCause; Regards, Bob Bob Moore Advanced Design and Technology Application Integration Middleware Division IBM Software Group +1-919-254-4436 remoore@us.ibm.com Randy Presuhn cc: disman@dorothy.bmc.com Sent by: Subject: DMTF ProbableCause beyond X.733 owner-disman@dorot hy.bmc.com 01/14/02 07:50 PM Hi Andrea - In Salt Lake City we chatted about the DMTF's use of X.733 "probable cause" codes, and how the DMTF's events work had found it necessary to extend this list. We in the IETF disman (distributed management) working group would like to know what the DMTF extensions are, so that our related work, which also includes the M.3100 codes, does not diverge unnecessarily from what the DMTF has done in this space. We appreciate your help. ------------------------------------------------------ Randy Presuhn BMC Software, Inc. 1-3141 randy_presuhn@bmc.com 2141 North First Street Tel: +1 408 546-1006 San José, California 95131 USA ------------------------------------------------------ My opinions and BMC's are independent variables. ------------------------------------------------------ From owner-disman@dorothy.bmc.com Tue Jan 15 10:49:57 2002 Received: from babbler.bmc.com (firebird.bmc.com [198.207.223.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29787 for ; Tue, 15 Jan 2002 10:49:56 -0500 (EST) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g0FFq7w03371; Tue, 15 Jan 2002 09:52:07 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id HAA10513 for disman-list; Tue, 15 Jan 2002 07:47:25 -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 HAA10508 for ; Tue, 15 Jan 2002 07:47:21 -0800 (PST) Received: from mx-us-hou-1-int.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id g0FFk4r29129 for ; Tue, 15 Jan 2002 09:46:04 -0600 (CST) Received: from alpha.armillaire.com (unknown [64.66.32.133]) by mx-us-hou-1-int.bmc.com (Postfix) with SMTP id 28C4820F0C4 for ; Tue, 15 Jan 2002 15:36:26 -0600 (CST) Received: from BETHEXC01.armillaire.com (unknown [64.66.32.137]) by alpha.armillaire.com (Postfix) with ESMTP id 5AEB65C754 for ; Tue, 15 Jan 2002 10:46:53 -0500 (EST) Received: by bethexc01.armillaire.com with Internet Mail Service (5.5.2653.19) id ; Tue, 15 Jan 2002 10:44:52 -0500 Message-ID: <4D38F1A1C17DD411931F00508BAF728ED68098@bethexc01.armillaire.com> From: "Nallappa, Bhashyam" To: disman@dorothy.bmc.com Subject: Active alarm Date: Tue, 15 Jan 2002 10:44:51 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list Hello, I have a question regarding the active alarms clearing philosphy. As I understand that we can paired alarms whereby the up alarm clears the down alarm for example as in the case of linkup alarm clearing the linkdown alarm I also read somewhere about the concept of aging. So if an alarm has not been cleared for an extended period (this could be an implenetation issue) then the alarm would be cleared from the list of active alarms. Can someone who have either implemented such an aging scheme or one who knows about this comment on this please Thanks Bhashyam Nallappa From owner-disman@dorothy.bmc.com Tue Jan 15 11:31:37 2002 Received: from babbler.bmc.com (camaro.bmc.com [198.207.223.231]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01512 for ; Tue, 15 Jan 2002 11:31:37 -0500 (EST) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g0FGXqx15901; Tue, 15 Jan 2002 10:33:52 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id IAA10595 for disman-list; Tue, 15 Jan 2002 08:29: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 IAA10589; Tue, 15 Jan 2002 08:29:18 -0800 (PST) Received: from mx-us-hou-1-int.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id g0FGS1a15816; Tue, 15 Jan 2002 10:28:01 -0600 (CST) Received: from sj-msg-core-1.cisco.com (unknown [171.71.163.11]) by mx-us-hou-1-int.bmc.com (Postfix) with SMTP id 1C0BB20F0BD; Tue, 15 Jan 2002 16:18:06 -0600 (CST) Received: from mira-sjcm-2.cisco.com (mira-sjcm-2.cisco.com [171.69.24.14]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g0FGUKF25095; Tue, 15 Jan 2002 08:30:21 -0800 (PST) Received: from ANDREAWW2K (andreaw-frame1.cisco.com [10.19.253.186]) by mira-sjcm-2.cisco.com (Mirapoint) with SMTP id ABJ21386; Tue, 15 Jan 2002 08:30:02 -0800 (PST) From: "Andrea Westerinen" To: "Robert Moore" , "Randy Presuhn" Cc: , Subject: RE: DMTF ProbableCause beyond X.733 Date: Tue, 15 Jan 2002 08:33:00 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-MIME-Autoconverted: from 8bit to quoted-printable by sj-msg-core-1.cisco.com id g0FGUKF25095 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by dorothy.bmc.com id IAA10590 Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list Content-Transfer-Encoding: 8bit Bob and Randy, I did the original mapping from the X.733 spec (since much of the AlertIndication is indeed based on X.733). Then, the DMTF Event WG added other values to the enum, that they felt were missing. I took the action from Randy (at the Policy SLA meeting) to indicate what we added - so that we could have a consistent list of values across the standards, and also will look at M.3100 probable cause (since it addresses more info than X.733). I actually responded to Randy (privately) that I would send this info next week. Andrea -----Original Message----- From: Robert Moore [mailto:remoore@us.ibm.com] Sent: Tuesday, January 15, 2002 5:28 AM To: Randy Presuhn Cc: andreaw@cisco.com; disman@dorothy.bmc.com; owner-disman@dorothy.bmc.com Subject: Re: DMTF ProbableCause beyond X.733 Hi Randy, I can answer this question as well as Andrea can. Understand, though, that I don't even participate in the Events WG, so all I can give you is what's in the current (i.e., Version 2.6 Preliminary) CIM Schema. I doubt that the WG is tweaking this further as we speak, but I don't know this for sure. I've also lost track of how these code points ended up in X.733, so I can't do the comparison for you. Here's the full set of values in the Events MOF, though: [Required, Description ( "An enumerated value that describes the probable cause of the " "situation which resulted in the AlertIndication."), Values {"Unknown", "Other", "Adapter Error", "Application Subsystem Failure", "Bandwidth Reduced", "Connection Establishment Error", "Communications Protocol Error", "Communications Subsystem Failure", "Configuration/Customization Error", "Congestion", "Corrupt Data", "CPU Cycles Limit Exceeded", "Dataset/Modem Error", "Degraded Signal", "DTE-DCE Interface Error", "Enclosure Door Open", "Equipment Malfunction", "Excessive Vibration", "File Format Error", "Fire Detected", "Flood Detected", "Framing Error", "HVAC Problem", "Humidity Unacceptable", "I/O Device Error", "Input Device Error", "LAN Error", "Non-Toxic Leak Detected", "Local Node Transmission Error", "Loss of Frame", "Loss of Signal", "Material Supply Exhausted", "Multiplexer Problem", "Out of Memory", "Output Device Error", "Performance Degraded", "Power Problem", "Pressure Unacceptable", "Processor Problem (Internal Machine Error)", "Pump Failure", "Queue Size Exceeded", "Receive Failure", "Receiver Failure", "Remote Node Transmission Error", "Resource at or Nearing Capacity", "Response Time Excessive", "Retransmission Rate Excessive", "Software Error", "Software Program Abnormally Terminated", "Software Program Error (Incorrect Results)", "Storage Capacity Problem", "Temperature Unacceptable", "Threshold Crossed", "Timing Problem", "Toxic Leak Detected", "Transmit Failure", "Transmitter Failure", "Underlying Resource Unavailable", "Version MisMatch", "Previous Alert Cleared", "Login Attempts Failed", "Software Virus Detected", "Hardware Security Breached", "Denial of Service Detected", "Security Credential MisMatch", "Invalid Access of Data Detected"}, MappingStrings {"Recommendation.ITU|X733.Probable cause"} ] uint16 ProbableCause; Regards, Bob Bob Moore Advanced Design and Technology Application Integration Middleware Division IBM Software Group +1-919-254-4436 remoore@us.ibm.com Randy Presuhn cc: disman@dorothy.bmc.com Sent by: Subject: DMTF ProbableCause beyond X.733 owner-disman@dorot hy.bmc.com 01/14/02 07:50 PM Hi Andrea - In Salt Lake City we chatted about the DMTF's use of X.733 "probable cause" codes, and how the DMTF's events work had found it necessary to extend this list. We in the IETF disman (distributed management) working group would like to know what the DMTF extensions are, so that our related work, which also includes the M.3100 codes, does not diverge unnecessarily from what the DMTF has done in this space. We appreciate your help. ------------------------------------------------------ Randy Presuhn BMC Software, Inc. 1-3141 randy_presuhn@bmc.com 2141 North First Street Tel: +1 408 546-1006 San José, California 95131 USA ------------------------------------------------------ My opinions and BMC's are independent variables. ------------------------------------------------------ From owner-disman@dorothy.bmc.com Tue Jan 15 19:01:07 2002 Received: from babbler.bmc.com (firebird.bmc.com [198.207.223.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16802 for ; Tue, 15 Jan 2002 19:01:07 -0500 (EST) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g0G03GN11067; Tue, 15 Jan 2002 18:03:16 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id PAA14476 for disman-list; Tue, 15 Jan 2002 15: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 PAA14470; Tue, 15 Jan 2002 15:57:05 -0800 (PST) Received: from mx-us-hou-1-int.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id g0FNtmu11188; Tue, 15 Jan 2002 17:55:48 -0600 (CST) Received: from zcars0m9.ca.nortel.com (unknown [47.129.242.157]) by mx-us-hou-1-int.bmc.com (Postfix) with SMTP id 9CA4220EFFB; Tue, 15 Jan 2002 23:46:03 -0600 (CST) Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56]) by zcars0m9.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g0FNwJn12627; Tue, 15 Jan 2002 18:58:20 -0500 (EST) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g0FNwHd02781; Tue, 15 Jan 2002 18:58:17 -0500 (EST) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 15 Jan 2002 18:58:17 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD34016A7F9F@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: disman@dorothy.bmc.com, Randy Presuhn Subject: RE: List of Notif Log MIB issues Date: Tue, 15 Jan 2002 18:58:17 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list hi Randy> Randy> > 3. Variable to indicate the current log index for each named log Randy> Randy> Sharon Chisholm took the action item to do the math to assess Randy> what the actual improvement will be. The numbers are... ? No numbers just yet, but a bit of a clarification on the problem and a possible solution. The problem is that for the most efficient algorithms you need to be able to query one variable that tells you how many notifications you should have received, compare this to the number of notifications you have received and then take action as appropriate. The closest object to this is nlmStatsLogNotificationsLogged, but this object is not guaranteed to give the right answer. The three cases I believe it fails are if the logIndex wraps, if logIndex does not always increase by one, or if the notifications in a viewed log includes notifications you are not receiving due to VACM or filtering reasons. It seems to me that if we created a table with VACM/Filter type indexing, such as snmpTargetParamsName, with an object like nlmTargetCurrentLogIndex in it then this would be the correct object all the time. Sharon From owner-disman@dorothy.bmc.com Tue Jan 15 19:05:28 2002 Received: from babbler.bmc.com (firebird.bmc.com [198.207.223.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16834 for ; Tue, 15 Jan 2002 19:05:27 -0500 (EST) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g0G07iH11687; Tue, 15 Jan 2002 18:07:44 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id QAA14502 for disman-list; Tue, 15 Jan 2002 16:03: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 QAA14496; Tue, 15 Jan 2002 16:03:16 -0800 (PST) Received: from mx-us-hou-2-int.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id g0G01xg12764; Tue, 15 Jan 2002 18:01:59 -0600 (CST) Received: from zcars0m9.ca.nortel.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by mx-us-hou-2-int.bmc.com (Postfix) with SMTP id 2D6151FF028; Tue, 15 Jan 2002 23:53:37 -0600 (CST) Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57]) by zcars0m9.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g0G04Pn17199; Tue, 15 Jan 2002 19:04:25 -0500 (EST) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g0G04OD19258; Tue, 15 Jan 2002 19:04:24 -0500 (EST) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 15 Jan 2002 19:04:23 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD34016A7FA0@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: disman@dorothy.bmc.com, Randy Presuhn Subject: RE: Notification Log Suggested Improvements Date: Tue, 15 Jan 2002 19:04:23 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list hi > > 3. The logIndex can increase by more than one and > > can technically increase different amount between > > notifications. It would therefore be nice for the > > management station to either predict this behaviour > > or to find out what it has increased after the fact. > > There could be a constantIncrement object, if applicable, > > or a lastIncrement. ... I'm missing something here. Why would it be "nice" to have such an object? A use case might make things clearer. The solution I proposed in my last email would make this unnecessary I believe. It supports the same heartbeat mechanism I described, although after talking to Ram it does not make as much sense as I originally thought. Sharon From owner-disman@dorothy.bmc.com Tue Jan 15 19:22:51 2002 Received: from babbler.bmc.com (camaro.bmc.com [198.207.223.231]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16991 for ; Tue, 15 Jan 2002 19:22:46 -0500 (EST) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g0G0P0g14809; Tue, 15 Jan 2002 18:25:00 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id QAA14529 for disman-list; Tue, 15 Jan 2002 16:20:35 -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 QAA14524 for ; Tue, 15 Jan 2002 16:20:32 -0800 (PST) Received: from mx-us-hou-1-int.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id g0G0JEv16875 for ; Tue, 15 Jan 2002 18:19:14 -0600 (CST) Received: from zcars0m9.ca.nortel.com (unknown [47.129.242.157]) by mx-us-hou-1-int.bmc.com (Postfix) with SMTP id B085A20EFCB for ; Wed, 16 Jan 2002 00:09:34 -0600 (CST) Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56]) by zcars0m9.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g0G0Lon17857; Tue, 15 Jan 2002 19:21:51 -0500 (EST) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g0G0Lmd03825; Tue, 15 Jan 2002 19:21:48 -0500 (EST) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 15 Jan 2002 19:21:48 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD34016A7FA7@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: Stefan Wallin , Disman Subject: RE: alarmModelEntry notInService Date: Tue, 15 Jan 2002 19:21:49 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list hi I'm not sure I fully understand the question. I think what you are referring to we have been discussing as either notification suppression as defined by RFC2573 or alarm suppression as defined by ARC. In either of these cases the suppression is an external factor on the alarms. In the case of ARC that uses its own notifications, then when something is suppressed then no notification is sent or logged and no active alarm entry is created. In the case of notification filter, the active alarm would get created, but the notification would not be sent out and would not be logged. Did that answer your question? Sharon -----Original Message----- From: Stefan Wallin [mailto:stefan.wallin@dataductus.se] Sent: Tuesday, January 15, 2002 6:33 AM To: Disman Subject: alarmModelEntry notInService Hi! Is there a definition of an alarmModelEntry being in state notInService? Possible interpretations: 1) In conflict with NOTIFICATION-MIB, so I assume wrong - notifications not sent - activeAlarmTable NOT updated 2) The entry does not represent a possible alarm: - notifications sent, (depending on NOTIFICATION-MIB) - activeAlarmTable NOT updated best regards Stefan Wallin From owner-disman@dorothy.bmc.com Tue Jan 15 19:30:40 2002 Received: from babbler.bmc.com (camaro.bmc.com [198.207.223.231]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17050 for ; Tue, 15 Jan 2002 19:30:40 -0500 (EST) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g0G0Wss15818; Tue, 15 Jan 2002 18:32:54 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id QAA14557 for disman-list; Tue, 15 Jan 2002 16:28: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 QAA14552 for ; Tue, 15 Jan 2002 16:28:23 -0800 (PST) Received: from mx-us-hou-2-int.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id g0G0R6m18676 for ; Tue, 15 Jan 2002 18:27:06 -0600 (CST) Received: from zcars0m9.ca.nortel.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by mx-us-hou-2-int.bmc.com (Postfix) with SMTP id BA7DD1FF028 for ; Wed, 16 Jan 2002 00:18:43 -0600 (CST) Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56]) by zcars0m9.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g0G0TQn18241; Tue, 15 Jan 2002 19:29:27 -0500 (EST) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g0G0TOd03956; Tue, 15 Jan 2002 19:29:24 -0500 (EST) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 15 Jan 2002 19:29:24 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD34016A7FAA@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: disman@dorothy.bmc.com, "Nallappa, Bhashyam" Subject: RE: Active alarm Date: Tue, 15 Jan 2002 19:29:24 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list hi Traditionally alarm aging is done in the manager, not on the managed system. It is often done to try and kludge an alarm management model in systems that don't send proper clear notifications to indicate a problem is no longer occurring. The alarm MIB allows you to model alarms using the alarmClear notification provided. This can be sent out to indicate that the problem the alarm is signalling is no longer occurring. It should therefore not be necessary to instrument alarm aging. Sharon -----Original Message----- From: Nallappa, Bhashyam [mailto:BNallappa@armillaire.com] Sent: Tuesday, January 15, 2002 10:45 AM To: disman@dorothy.bmc.com Subject: Active alarm Hello, I have a question regarding the active alarms clearing philosphy. As I understand that we can paired alarms whereby the up alarm clears the down alarm for example as in the case of linkup alarm clearing the linkdown alarm I also read somewhere about the concept of aging. So if an alarm has not been cleared for an extended period (this could be an implenetation issue) then the alarm would be cleared from the list of active alarms. Can someone who have either implemented such an aging scheme or one who knows about this comment on this please Thanks Bhashyam Nallappa From owner-disman@dorothy.bmc.com Tue Jan 15 19:32:12 2002 Received: from babbler.bmc.com (firebird.bmc.com [198.207.223.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17071 for ; Tue, 15 Jan 2002 19:32:11 -0500 (EST) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g0G0YQp16022; Tue, 15 Jan 2002 18:34:26 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id QAA14569 for disman-list; Tue, 15 Jan 2002 16:30:02 -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 QAA14564 for ; Tue, 15 Jan 2002 16:29:59 -0800 (PST) Received: from mx-us-hou-1-int.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id g0G0Sgj19084 for ; Tue, 15 Jan 2002 18:28:42 -0600 (CST) Received: from zcars0m9.ca.nortel.com (unknown [47.129.242.157]) by mx-us-hou-1-int.bmc.com (Postfix) with SMTP id 0F1F420F0C1 for ; Wed, 16 Jan 2002 00:19:02 -0600 (CST) Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56]) by zcars0m9.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g0G0VIn18299 for ; Tue, 15 Jan 2002 19:31:18 -0500 (EST) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g0G0VGd03978 for ; Tue, 15 Jan 2002 19:31:16 -0500 (EST) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 15 Jan 2002 19:31:16 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD34016A7FAB@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: disman@dorothy.bmc.com Subject: Alarm MIB Issues 1-13 Date: Tue, 15 Jan 2002 19:31:16 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list hi Ok, last email of the evening. Here is an updated issue list for the Alarm MIB. Closed Issues ------------- Alarm#1 TimeFilter as index to Active Alarm Table Alarm#2 Cleared Alarm Table Alarm#3 Resource Identifier for Application Alarm#5 EngineId versus ContextEngineId Alarm#6 Telcordia Alarm Models Alarm#7 Alarm Example Error Alarm#8 Matching Notifications Alarm#10 Detecting Alarm State Change Open Issues ----------- Alarm#4 Relation to Event MIB There does not seem to be any particular relation between these MIBs, compared with other MIBs, but the commonality in terms may cause confusion if not clarified. Alarm#9 Example showing relation to Condition and Arc MIB Currently missing from -04 Alarm#11 Resource Identification The resource identification method in -04 uses a type and integer value pair to identify a resource. There has been some support for using an OID instead. There are pros and cons to each approach. Alarm#12 Time Zone in DataAndTime There are concerns that the optional zone part of DateAndTime might not be implemented. As time zones are an important piece of information in a distributed manager. Test should be added the textual descriptions of the DateAndTime object to encourage the correct behaviour. Randy suggested some text on which there was some agreement. Alarm#13 DMTF input into probable cause We have some input from DMTF as to potential additional probable cause values. When these are available, the initial set of probable causes can be updated. Sharon Chisholm Preside Management Nortel Networks Ottawa, Ontario From owner-disman@dorothy.bmc.com Wed Jan 16 03:04:52 2002 Received: from babbler.bmc.com (firebird.bmc.com [198.207.223.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02413 for ; Wed, 16 Jan 2002 03:04:52 -0500 (EST) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g0G876Q27121; Wed, 16 Jan 2002 02:07:06 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id AAA15786 for disman-list; Wed, 16 Jan 2002 00:02: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 AAA15780 for ; Wed, 16 Jan 2002 00:01:58 -0800 (PST) Received: from mx-us-hou-2-int.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id g0G80e822747 for ; Wed, 16 Jan 2002 02:00:40 -0600 (CST) Received: from watcher.dataductus.se (mail.dataductus.se [213.199.99.201]) by mx-us-hou-2-int.bmc.com (Postfix) with SMTP id A756A1FF11E for ; Wed, 16 Jan 2002 07:52:15 -0600 (CST) Received: (qmail 12763 invoked from network); 16 Jan 2002 08:03:09 -0000 Received: from nsmail.dataductus.se (192.168.100.43) by 0 with SMTP; 16 Jan 2002 08:03:09 -0000 Received: from dataductus.com ([192.168.100.240]) by nsmail.dataductus.se (Netscape Messaging Server 4.15) with SMTP id GQ0UDI00.RWX; Wed, 16 Jan 2002 09:03:18 +0100 From: "Stefan Wallin" To: "Sharon Chisholm" , "Disman" Subject: SV: alarmModelEntry notInService Date: Wed, 16 Jan 2002 09:03:10 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <3549C09B853DD5119B540002A52CDD34016A7FA7@zcard0ka.ca.nortel.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list Content-Transfer-Encoding: 7bit Hi! Sharon>Did that answer your question? No it did not. My question is how a alarmModelEntry in state notInService shall be handled by the agent. My guess is that the correct behaviour is my alternative 2: activeAlarmTable is NOT updated when the corresponding event occurs. Of course it does not affect notification sending. See def of notInService in SMIv2-TC: - `notInService', which indicates that the conceptual row exists in the agent, but is unavailable for use by the managed device Assuming that interpretation, we have a transactional concern, it is confusing to make only some of the entries of the same alarmindex out of service. It should affect all entries with the same alarmModelIndex. Modified example from draft-4, where an alarm clear entry is outOfService: alarmModelIndex 3 alarmModelState 1 alarmModelNotificationId linkUp alarmModelVarbindIndex 0 alarmModelVarbindValue 0 alarmModelDescription "linkUp" alarmModelSpecificPointer ituAlarmEntry.3.1 alarmModelRowStatus notInService(2) <------NOTE--------- ituAlarmEventType communicationsAlarm (2) ituAlarmPerceivedSeverity cleared (1) ituAlarmGenericModel alarmModelEntry.3.1 alarmModelIndex 3 alarmModelState 2 alarmModelNotificationId linkDown alarmModelVarbindIndex 2 alarmModelVarbindValue down (2) alarmModelDescription "linkDown administratively" alarmModelSpecificPointer ituAlarmEntry.3.6 alarmModelRowStatus active (1) ituAlarmEventType communicationsAlarm (2) ituAlarmPerceivedSeverity warning (6) ituAlarmGenericModel alarmModelEntry.3.2 What would be the correct behaviour of the agent in my modified example above? best regards Stefan Sharon -----Original Message----- From: Stefan Wallin [mailto:stefan.wallin@dataductus.se] Sent: Tuesday, January 15, 2002 6:33 AM To: Disman Subject: alarmModelEntry notInService Hi! Is there a definition of an alarmModelEntry being in state notInService? Possible interpretations: 1) In conflict with NOTIFICATION-MIB, so I assume wrong - notifications not sent - activeAlarmTable NOT updated 2) The entry does not represent a possible alarm: - notifications sent, (depending on NOTIFICATION-MIB) - activeAlarmTable NOT updated best regards Stefan Wallin From owner-disman@dorothy.bmc.com Wed Jan 16 03:14:32 2002 Received: from babbler.bmc.com (camaro.bmc.com [198.207.223.231]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02496 for ; Wed, 16 Jan 2002 03:14:31 -0500 (EST) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g0G8Gi028035; Wed, 16 Jan 2002 02:16:44 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id AAA15832 for disman-list; Wed, 16 Jan 2002 00:12:19 -0800 (PST) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id AAA15826 for disman@dorothy.bmc.com; Wed, 16 Jan 2002 00:12:15 -0800 (PST) Date: Wed, 16 Jan 2002 00:12:15 -0800 (PST) From: Randy Presuhn Message-Id: <200201160812.AAA15826@dorothy.bmc.com> To: disman@dorothy.bmc.com Subject: Re: SV: alarmModelEntry notInService Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list Content-Transfer-Encoding: 7bit Hi - > From: "Stefan Wallin" > To: "Sharon Chisholm" , > "Disman" > Subject: SV: alarmModelEntry notInService > Date: Wed, 16 Jan 2002 09:03:10 +0100 > Message-ID: > In-Reply-To: <3549C09B853DD5119B540002A52CDD34016A7FA7@zcard0ka.ca.nortel.com> ... > My question is how a alarmModelEntry in state notInService shall be > handled by the agent. My guess is that the correct behaviour is my > alternative 2: > activeAlarmTable is NOT updated when the corresponding event occurs. > Of course it does not affect notification sending. That would be my expectation. > See def of notInService in SMIv2-TC: > - `notInService', which indicates that the conceptual > row exists in the agent, but is unavailable for use by > the managed device > > Assuming that interpretation, we have a transactional concern, it is > confusing to make only some of the entries of the same alarmindex out of > service. It should affect all entries with the same alarmModelIndex. ... Note well that the notInService value of the RowStatus textual convention is probably NOT appropriate as a "control" value here, since the row may disappear due to the provisions at the bottom of page 16 of RFC 2579. ------------------------------------------------------ Randy Presuhn BMC Software, Inc. 1-3141 randy_presuhn@bmc.com 2141 North First Street Tel: +1 408 546-1006 San José, California 95131 USA ------------------------------------------------------ My opinions and BMC's are independent variables. ------------------------------------------------------ From owner-disman@dorothy.bmc.com Wed Jan 16 08:50:21 2002 Received: from babbler.bmc.com (camaro.bmc.com [198.207.223.231]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07016 for ; Wed, 16 Jan 2002 08:50:21 -0500 (EST) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g0GDqZS04917; Wed, 16 Jan 2002 07:52:35 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id FAA27653 for disman-list; Wed, 16 Jan 2002 05:47:42 -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 FAA27648 for ; Wed, 16 Jan 2002 05:47:37 -0800 (PST) Received: from mx-us-hou-2-int.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id g0GDkFw14466 for ; Wed, 16 Jan 2002 07:46:15 -0600 (CST) Received: from watcher.dataductus.se (mail.dataductus.se [213.199.99.201]) by mx-us-hou-2-int.bmc.com (Postfix) with SMTP id C24FA1FF07C for ; Wed, 16 Jan 2002 13:37:48 -0600 (CST) Received: (qmail 18434 invoked from network); 16 Jan 2002 13:48:42 -0000 Received: from nsmail.dataductus.se (192.168.100.43) by 0 with SMTP; 16 Jan 2002 13:48:42 -0000 Received: from dataductus.com ([192.168.100.240]) by nsmail.dataductus.se (Netscape Messaging Server 4.15) with SMTP id GQ1ADC00.RY2 for ; Wed, 16 Jan 2002 14:48:48 +0100 From: "Stefan Wallin" To: "Disman" Date: Wed, 16 Jan 2002 14:48:43 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list Content-Transfer-Encoding: 7bit Hi! Regarding Open issue Alarm#11 Resource Identification ======================================================= It would be helpful if the object reference mechanism allowed me a bit more power than it currently does. It doesn't really allow me to reference an object in a enterprise-specific MIB or some other standard MIB. This could be done very indirectly by implementing the entity mib and letting that point further to the resource but this is rather roundabout. I think it would be very useful to use OIDs and would strongly recommend to having an OID pointing to the object. dynamic Mapping to X733 ============================ The current model assumes that mapping is done very static: it is based on translating every entry in alarmModelTable to the X733 parameters. This model assumes that the notification does not carry any X733 like information in var-binds. The only information that is mapped dynamically (checking var-bind in notification) is severity -> alarmModelState. Having done alarm management apps translating SNMP notifications to X733 format I have come across several occasions where the mapping is done dynamically for things like eventType, additionalText and even probableCause. In order to support this, (if we want to), the ituAlarmTable needs a mechanism saying e.g. that the additionalText value should be fetched from var-bind #4, instead of hard-wiring to a static text. From owner-disman@dorothy.bmc.com Wed Jan 16 13:22:51 2002 Received: from babbler.bmc.com (camaro.bmc.com [198.207.223.231]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16614 for ; Wed, 16 Jan 2002 13:22:51 -0500 (EST) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g0GIP6c11315; Wed, 16 Jan 2002 12:25:06 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id KAA28857 for disman-list; Wed, 16 Jan 2002 10:20:12 -0800 (PST) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id KAA28852 for ; Wed, 16 Jan 2002 10:20:08 -0800 (PST) Received: from mx-us-hou-1-int.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id g0GIIos25171 for ; Wed, 16 Jan 2002 12:18:51 -0600 (CST) Received: from watcher.dataductus.se (unknown [213.199.99.201]) by mx-us-hou-1-int.bmc.com (Postfix) with SMTP id 2D9E820F0EB for ; Wed, 16 Jan 2002 18:09:05 -0600 (CST) Received: (qmail 22704 invoked from network); 16 Jan 2002 18:21:27 -0000 Received: from nsmail.dataductus.se (192.168.100.43) by 0 with SMTP; 16 Jan 2002 18:21:27 -0000 Received: from ddskvirus.dataductus.se ([192.168.100.101]) by nsmail.dataductus.se (Netscape Messaging Server 4.15) with SMTP id GQ1N0200.CWU for ; Wed, 16 Jan 2002 19:21:38 +0100 Received: from mogwai.dataductus.se ([192.168.100.44]) by ddskvirus.dataductus.se (NAVGW 2.5.1.15) with SMTP id M2002011619213912762 for ; Wed, 16 Jan 2002 19:21:39 +0100 Received: (from nobody@localhost) by mogwai.dataductus.se (8.9.3/8.9.3) id TAA25293 for disman@dorothy.bmc.com; Wed, 16 Jan 2002 19:21:32 +0100 To: disman@dorothy.bmc.com Subject: more comments... Message-ID: <1011205292.3c45c4ac764be@webmail.dataductus.se> Date: Wed, 16 Jan 2002 19:21:32 +0100 (CET) From: Stefan Wallin MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 8bit User-Agent: IMP/PHP IMAP webmail program 2.2.4 X-Originating-IP: 213.65.8.243 Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list Content-Transfer-Encoding: 8bit Hi! More comments... alarmModelRowStatus ===================== Current description of alarmModelRowStatus: "Control for creating and deleting entries. Entries may be modified while active. This row can not be deleted while it is being referenced by a value of alarmActiveModelPointer" I assume we should expand the restrictions to: This row can not be deleted or _modified_ while it is being referenced by a value of alarmActiveModelPointer. Since the manager can not reestablish the alarm if the alarmModel has changed after the reference was setup between alarmActiveTable and alarmModelTable. Also, as stated previously add: If the status is notInService alarmActiveModel will not be updated with corresponding alarm. Comments of editorial art: 1) The ITU-ALARM-TC and ITU-IANA-ALARM-TC are missing MODULE-IDENTITY 2) The module name starts with ITU which normally should indicate the enterprise owning the module, I wonder what ITU says... 3) Groups in ITU-ALARM-MIB have strange names considering their contained objects. ituAlarmServiceUserGroup OBJECT-GROUP OBJECTS { ituAlarmAdditionalText, ituAlarmActiveTrendIndication } ituAlarmSecurityGroup OBJECT-GROUP OBJECTS { ituAlarmActiveDetector, ituAlarmActiveServiceProvider, ituAlarmActiveServiceUser } The ituAlarmServiceGroup has nothing to do with serviceUsers, they are in the next group... change ituAlarmServiceUserGroup to something like ituAlarmEnhancedGroup 4) Page 44: examples section: remove alarmActiveDetailsIndex, old obsoleted object I guess? alarmActiveModelPointer ituAlarmActiveEntry.1.3 should be: alarmActiveModelPointer alarmModelEntry.1.3 best regards Stefan Stefan Wallin Data Ductus AB +46 70 5233262 stefan.wallin@dataductus.se Stefan Wallin Data Ductus AB +46 70 5233262 stefan.wallin@dataductus.se From owner-disman@dorothy.bmc.com Wed Jan 16 20:10:30 2002 Received: from babbler.bmc.com (camaro.bmc.com [198.207.223.231]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA25073 for ; Wed, 16 Jan 2002 20:10:30 -0500 (EST) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g0H1CcD16612; Wed, 16 Jan 2002 19:12:38 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id RAA04483 for disman-list; Wed, 16 Jan 2002 17:06:18 -0800 (PST) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id RAA04477 for disman@dorothy.bmc.com; Wed, 16 Jan 2002 17:06:15 -0800 (PST) Date: Wed, 16 Jan 2002 17:06:15 -0800 (PST) From: Randy Presuhn Message-Id: <200201170106.RAA04477@dorothy.bmc.com> To: disman@dorothy.bmc.com Subject: *planned* last call for alarm mib Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list Content-Transfer-Encoding: 7bit Hi - At the disman session in Salt Lake City, our plan was to issue a WG last call on the alarm document as soon as it became available. Given the number of (useful) comments that have circulated on this list recently, as WG chair I feel it will be necessary for the editors to do at least one more revision before a WG last call would make sense. However, PLEASE keep those comments coming! Just once I'd like to see a *quick* last call. :-) ------------------------------------------------------ Randy Presuhn BMC Software, Inc. 1-3141 randy_presuhn@bmc.com 2141 North First Street Tel: +1 408 546-1006 San José, California 95131 USA ------------------------------------------------------ My opinions and BMC's are independent variables. ------------------------------------------------------ From owner-disman@dorothy.bmc.com Wed Jan 16 21:24:03 2002 Received: from babbler.bmc.com (camaro.bmc.com [198.207.223.231]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25776 for ; Wed, 16 Jan 2002 21:24:02 -0500 (EST) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g0H2QIb24066; Wed, 16 Jan 2002 20:26:18 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id SAA04817 for disman-list; Wed, 16 Jan 2002 18:21: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 SAA04812 for ; Wed, 16 Jan 2002 18:21:12 -0800 (PST) Received: from mx-us-hou-1-int.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id g0H2Jsh21369 for ; Wed, 16 Jan 2002 20:19:54 -0600 (CST) Received: from ierw.net.avaya.com (unknown [198.152.13.101]) by mx-us-hou-1-int.bmc.com (Postfix) with SMTP id 5837020EFCA for ; Thu, 17 Jan 2002 02:09:20 -0600 (CST) Received: from ierw.net.avaya.com (localhost [127.0.0.1]) by ierw.net.avaya.com (8.9.3+Sun/8.9.3) with ESMTP id VAA27757 for ; Wed, 16 Jan 2002 21:20:20 -0500 (EST) Received: from IS0004AVEXU1.global.avaya.com (h149-49-38-91.avaya.com [149.49.38.91]) by ierw.net.avaya.com (8.9.3+Sun/8.9.3) with ESMTP id VAA27748 for ; Wed, 16 Jan 2002 21:20:19 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Alarm MIB Issues 1-13 Date: Thu, 17 Jan 2002 04:20:54 +0200 Message-ID: Thread-Topic: Alarm MIB Issues 1-13 Thread-Index: AcGeJWNHTKAx/wRITwmyELc/kLCCjQA1iLJQ From: "Romascanu, Dan (Dan)" To: "Sharon Chisholm" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by dorothy.bmc.com id SAA04813 Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list Content-Transfer-Encoding: 8bit Let me try to shorten the list: Alarm #4 - I suggest the following text. x.y Relationship with the Event MIB During the work and discussions in the Working Group, the issue of the relationship between the MIB modules and the Event MIB [RFC...] was raised. There is no direct relation or dependency between the Alarm MIB and the Event MIB. Some common terms (like 'event') are being used in both MIB modules, and the user is directed to the sections that define terminology in the two documents for clarification. Alarm#12 I suggest to adopt the additional text proposed by Randy Alarm #13 This issue seems similar with Alarm#6. Mentioning a possible source of information without bringing a concrete proposal does not help. I suggest to close this item. If somebody will bring a specific proposal for additional probable cause values from DMTF or any other source, we will consider it. Assuming that we will fill in the example required at Alarm #9 in the next I-D, the only real open issue remains Alarm #11. IMO both approaches would work, and which one we pick is more an issue of culinary taste or religion ('do you like the flexibility of the OIDs? do you believe that it is that difficult to implement OIDs?). I would suggest to let our Chair rule, so that the process is not stalled for an issue that might be rather 'don't care' at the end of the day. Regards, Dan > -----Original Message----- > From: Sharon Chisholm [mailto:schishol@nortelnetworks.com] > Sent: Wednesday, January 16, 2002 2:31 AM > To: disman@dorothy.bmc.com > Subject: Alarm MIB Issues 1-13 > > > hi > > Ok, last email of the evening. Here is an updated issue > list for the Alarm MIB. > > Closed Issues > ------------- > Alarm#1 TimeFilter as index to Active Alarm Table > Alarm#2 Cleared Alarm Table > Alarm#3 Resource Identifier for Application > Alarm#5 EngineId versus ContextEngineId > Alarm#6 Telcordia Alarm Models > Alarm#7 Alarm Example Error > Alarm#8 Matching Notifications > Alarm#10 Detecting Alarm State Change > > Open Issues > ----------- > > Alarm#4 Relation to Event MIB > There does not seem to be any particular relation between > these MIBs, > compared with other MIBs, but the commonality in terms may cause > confusion if not clarified. > > Alarm#9 Example showing relation to Condition and Arc MIB > Currently missing from -04 > > Alarm#11 Resource Identification > The resource identification method in -04 uses a type and > integer value pair to identify a resource. There has > been some support for using an OID instead. There are > pros and cons to each approach. > > Alarm#12 Time Zone in DataAndTime > There are concerns that the optional zone part of DateAndTime > might not be implemented. As time zones are an important piece > of information in a distributed manager. Test should > be added the textual descriptions of the DateAndTime object > to encourage the correct behaviour. Randy suggested some > text on which there was some agreement. > > Alarm#13 DMTF input into probable cause > We have some input from DMTF as to potential additional probable > cause values. When these are available, the initial set of > probable causes can be updated. > > Sharon Chisholm > Preside Management > Nortel Networks > Ottawa, Ontario > From owner-disman@dorothy.bmc.com Thu Jan 17 11:42:59 2002 Received: from babbler.bmc.com (firebird.bmc.com [198.207.223.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23611 for ; Thu, 17 Jan 2002 11:42:58 -0500 (EST) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g0HGjDw08907; Thu, 17 Jan 2002 10:45:14 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id IAA17520 for disman-list; Thu, 17 Jan 2002 08:40:06 -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 IAA17515 for ; Thu, 17 Jan 2002 08:40:03 -0800 (PST) Received: from mx-us-hou-1-int.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id g0HGci319254 for ; Thu, 17 Jan 2002 10:38:44 -0600 (CST) Received: from duncan.cs.utk.edu (unknown [160.36.56.58]) by mx-us-hou-1-int.bmc.com (Postfix) with SMTP id 65FFD20EFCF for ; Thu, 17 Jan 2002 16:28:48 -0600 (CST) Received: from duncan.cs.utk.edu (localhost [127.0.0.1]) by duncan.cs.utk.edu (cf 8.9.3) with ESMTP id LAA00433 for ; Thu, 17 Jan 2002 11:41:17 -0500 (EST) Message-Id: <200201171641.LAA00433@duncan.cs.utk.edu> To: disman@dorothy.bmc.com Subject: resend Re: alarmModelEntry notInService MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <426.1011285675.1@duncan.cs.utk.edu> Date: Thu, 17 Jan 2002 11:41:16 -0500 From: "David L. Partain" Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list Greetings, I sent this yesterday from a different account, but I haven't seen it appear yet, so I'll retry from here... Forgive any duplication. Cheers, dlp ----------------------------------------------------- Hi, > > From: "Stefan Wallin" > > To: "Sharon Chisholm" , > > "Disman" > > Subject: SV: alarmModelEntry notInService > > Date: Wed, 16 Jan 2002 09:03:10 +0100 > > Message-ID: > > In-Reply-To: > > <3549C09B853DD5119B540002A52CDD34016A7FA7@zcard0ka.ca.nortel.com> > > ... > > > My question is how a alarmModelEntry in state notInService shall be > > handled by the agent. My guess is that the correct behaviour is my > > alternative 2: > > activeAlarmTable is NOT updated when the corresponding event occurs. > > Of course it does not affect notification sending. > > That would be my expectation. > > > See def of notInService in SMIv2-TC: > > - `notInService', which indicates that the conceptual > > row exists in the agent, but is unavailable for use by > > the managed device > > > > Assuming that interpretation, we have a transactional concern, it is > > confusing to make only some of the entries of the same alarmindex out of > > service. It should affect all entries with the same alarmModelIndex. > > ... > > Note well that the notInService value of the RowStatus textual > convention is probably NOT appropriate as a "control" value > here, since the row may disappear due to the provisions at > the bottom of page 16 of RFC 2579. That's true, but it also seems to be the best alternative. 2579 also says "It is the responsibility of the DESCRIPTION clause of the status column to indicate what an abnormally long period of time would be." As such, it would be possible to use notInService as this "control" value as long as the DESCRIPTION clause clearly states what garbage collection should do. Cheers, David Partain From owner-disman@dorothy.bmc.com Thu Jan 17 12:07:15 2002 Received: from babbler.bmc.com (camaro.bmc.com [198.207.223.231]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24584 for ; Thu, 17 Jan 2002 12:07:15 -0500 (EST) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g0HH9WH14798; Thu, 17 Jan 2002 11:09:32 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id JAA17558 for disman-list; Thu, 17 Jan 2002 09:05:01 -0800 (PST) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id JAA17553 for ; Thu, 17 Jan 2002 09:04:58 -0800 (PST) Received: from mx-us-hou-1-int.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id g0HH3aj29404 for ; Thu, 17 Jan 2002 11:03:36 -0600 (CST) Received: from mumm.ibr.cs.tu-bs.de (unknown [134.169.34.33]) by mx-us-hou-1-int.bmc.com (Postfix) with SMTP id 0378720F020 for ; Thu, 17 Jan 2002 16:53:44 -0600 (CST) Received: from haerke.ibr.cs.tu-bs.de (IDENT:root@haerke.ibr.cs.tu-bs.de [134.169.34.84]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.0) with ESMTP id SAA29320; Thu, 17 Jan 2002 18:06:13 +0100 (MET) Received: (from schoenw@localhost) by haerke.ibr.cs.tu-bs.de (8.11.6/8.11.6) id g0HH6Ck25888; Thu, 17 Jan 2002 18:06:12 +0100 Date: Thu, 17 Jan 2002 18:06:12 +0100 Message-Id: <200201171706.g0HH6Ck25888@haerke.ibr.cs.tu-bs.de> X-Authentication-Warning: haerke.ibr.cs.tu-bs.de: schoenw set sender to schoenw@ibr.cs.tu-bs.de using -f From: Juergen Schoenwaelder To: partain@cs.utk.edu Cc: disman@dorothy.bmc.com In-reply-to: <200201171641.LAA00433@duncan.cs.utk.edu> (partain@cs.utk.edu) Subject: Re: resend Re: alarmModelEntry notInService References: <200201171641.LAA00433@duncan.cs.utk.edu> Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list >>>>> David L Partain writes: >> Note well that the notInService value of the RowStatus textual >> convention is probably NOT appropriate as a "control" value here, >> since the row may disappear due to the provisions at the bottom of >> page 16 of RFC 2579. David> That's true, but it also seems to be the best alternative. David> 2579 also says "It is the responsibility of the DESCRIPTION David> clause of the status column to indicate what an abnormally long David> period of time would be." As such, it would be possible to use David> notInService as this "control" value as long as the DESCRIPTION David> clause clearly states what garbage collection should do. I generally recommend against mixing row creation/deletion machinery details with the actual enabled/disabled status control of a row. If there is a need to disable a row (or better the function represented by a row), then add proper status control objects. This is clear and clean and gives you extensibility in case you find out that the row may need to distinguish additional status values over time. And even implementation wise, I find it simpler to implement additional control objects than tweaking the RowStatus machinery to do additional stuff. Of course, you still have to say what the implications of notInService are - in case this is the original question and there is no requirement to be able to disable things. /js -- Juergen Schoenwaelder University of Osnabrueck Dept. of Mathematics and Computer Science Phone: +49 541 969 2483 Albrechtstr. 28, 49069 Osnabrueck, Germany Fax: +49 541 969 2770 From owner-disman@dorothy.bmc.com Thu Jan 17 12:19:59 2002 Received: from babbler.bmc.com (firebird.bmc.com [198.207.223.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27092 for ; Thu, 17 Jan 2002 12:19:59 -0500 (EST) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g0HHMGp17254; Thu, 17 Jan 2002 11:22:16 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id JAA17604 for disman-list; Thu, 17 Jan 2002 09:17:44 -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 JAA17599 for ; Thu, 17 Jan 2002 09:17:40 -0800 (PST) Received: from mx-us-hou-1-int.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id g0HHGMH03974 for ; Thu, 17 Jan 2002 11:16:22 -0600 (CST) Received: from duncan.cs.utk.edu (unknown [160.36.56.58]) by mx-us-hou-1-int.bmc.com (Postfix) with SMTP id EC86220EFC4 for ; Thu, 17 Jan 2002 17:06:25 -0600 (CST) Received: from duncan.cs.utk.edu (localhost [127.0.0.1]) by duncan.cs.utk.edu (cf 8.9.3) with ESMTP id MAA01870; Thu, 17 Jan 2002 12:05:56 -0500 (EST) Message-Id: <200201171705.MAA01870@duncan.cs.utk.edu> To: "Sharon Chisholm" , disman@dorothy.bmc.com, Stefan Wallin Subject: Re: disman alarm mib comments MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1866.1011287153.1@duncan.cs.utk.edu> Date: Thu, 17 Jan 2002 12:05:55 -0500 From: "David L. Partain" Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list Greetings, I don't believe I have seen an answer to some of the issues herein, so I'll give it my 2 eurocents. I've cut out lots of things that I think have been discussed elsewhere. I hope I haven't whacked too zealously. > > But again, traps are displayed in real-time > for end-users and it is critical for them to quickly identify the resource. > > Example: an ifIndex does not tell the typical alarm operator that much... > The alarm should say: "Slot 1, port 17, link is down administratively." > > My recommendation is that the user-friendly var-bind above has this > information > embedded. > > > I disagree that this should be done in the agent, And I agree with Stefan that it should. The point is that there are going to be many settings where a human operator is sitting in front of a screen watching incoming alarms. Not the job I want, but there are people that do this. What Stefan is suggesting, and I think it makes great sense, is that the agent indeed include some reasonable text string that can be shown to this human operator _immediately_ upon receipt of the alarm. Whether this is the best way to manage networks or not is of course debatable, but there is no question that there are definitely users of this technology who would benefit from this. > especially if it ends up being done somewhere like a text > string. The result of this approach can be seen with fields such > as ifName and ifDescription. No agent gives either consistent > information or consistent format. That certainly is true, but it doesn't really change the fact that this would be useful in many cases. I guarantee that if we build boxes that put silliness into such a text string, we'll hear about it very quickly from our customers. > I've even seen systems where > it isn't even consistent for its different ifTypes. My approach > is that base information should be given in a consistent, hard > to mess up format such as an integer, and the manager does the > mapping to get physical components or other information it needs > and then displays it in a nice consistent format to the user. In > my experience, this is the only way this sort of thing works. I obviously cannot argue with your experience. I can, though, make a case for the fact that our customers are definitely going to want to have something easily displayable when an alarm arrives at the manager. The text string would allow this to happen. > > Issue 2: index variables in notifications > ----------------------------------------- > Notifications should not be carried by traps, see "7.7. > Mapping of the INDEX clause", rfc2578. If we go for Solution > 1 above, sending the alarmModelDescription in the traps, > we would implicit send the index variables in the var bind: > alarmModelDescription.. = > "Toaster burning" > > The definition would be: > alarmRaise NOTIFICATION-TYPE > OBJECTS { alarmModelDescription, > alarmActiveResourceType, > alarmActiveResourceId } > STATUS current > > This goes back to how annoying it is that table indices are not accessible > in SMIv2. Annoying, Annoying, Annoying. It looks like we should be fixing > this in SMIng. I don't think it's broken. I think it's absolutely correct. If I do a get-next on interfaces and get back ifDescr.1 = "blah" why it is so hard to figure out that ifIndex is 1. I think the reason for this change (to promote better management applications since they don't display indices based on separate objects in a response) are very sound. I certainly hope that SMIng won't "fix" this. And whether one considers it broken or not, the rule exists in RFC 2578, so I think Stefan's correct. Cheers, David From owner-disman@dorothy.bmc.com Thu Jan 17 12:36:12 2002 Received: from babbler.bmc.com (firebird.bmc.com [198.207.223.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27678 for ; Thu, 17 Jan 2002 12:36:11 -0500 (EST) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g0HHcSB20234; Thu, 17 Jan 2002 11:38:28 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id JAA17655 for disman-list; Thu, 17 Jan 2002 09:34:01 -0800 (PST) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id JAA17650 for ; Thu, 17 Jan 2002 09:33:57 -0800 (PST) Received: from mx-us-hou-2-int.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id g0HHWc810501 for ; Thu, 17 Jan 2002 11:32:39 -0600 (CST) Received: from ierw.net.avaya.com (ierw.net.avaya.com [198.152.13.101]) by mx-us-hou-2-int.bmc.com (Postfix) with SMTP id 8F0CD1FF1B6 for ; Thu, 17 Jan 2002 17:24:08 -0600 (CST) Received: from ierw.net.avaya.com (localhost [127.0.0.1]) by ierw.net.avaya.com (8.9.3+Sun/8.9.3) with ESMTP id MAA00906 for ; Thu, 17 Jan 2002 12:33:42 -0500 (EST) Received: from IS0004AVEXU1.global.avaya.com (h149-49-38-91.avaya.com [149.49.38.91]) by ierw.net.avaya.com (8.9.3+Sun/8.9.3) with ESMTP id MAA00886 for ; Thu, 17 Jan 2002 12:33:41 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: disman alarm mib comments Date: Thu, 17 Jan 2002 19:34:16 +0200 Message-ID: Thread-Topic: disman alarm mib comments Thread-Index: AcGfe2QKoMfkUPjwS12pwjX0ta4TjAAALtRg From: "Romascanu, Dan (Dan)" To: "David L. Partain" , "Sharon Chisholm" , , "Stefan Wallin" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by dorothy.bmc.com id JAA17651 Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list Content-Transfer-Encoding: 8bit This is probably a discussion that started the day the first notification was sent on the wire. The argument is not about the fact that users would rather see messages in English (or Swedish, or Hebrew) rather than OIDs, that might actually include re-directing information. We should never argue with customers. The question is about how we implement this. Should we build clear text messages in the agent, or should we somehow code these messages, use some (quite simple) parsing SW in the application and refer a text file to present the readable information to the user. Am I mistaken, or do you suggest a third way to do it - not only have the agent send clear readable text, but even define the text as part of the standard? I just want to make sure that I do not mis-read you and Stefan. Thanks, Dan > -----Original Message----- > From: David L. Partain [mailto:partain@cs.utk.edu] > Sent: Thursday, January 17, 2002 7:06 PM > To: Sharon Chisholm; disman@dorothy.bmc.com; Stefan Wallin > Subject: Re: disman alarm mib comments > > > Greetings, > > I don't believe I have seen an answer to some of the issues > herein, so I'll give it my 2 eurocents. I've cut out lots of > things that I think have been discussed elsewhere. I hope I > haven't whacked too zealously. > > > > > But again, traps are displayed in real-time > > for end-users and it is critical for them to quickly > identify the resource. > > > > Example: an ifIndex does not tell the typical alarm > operator that much... > > The alarm should say: "Slot 1, port 17, link is down > administratively." > > > > My recommendation is that the user-friendly var-bind above has this > > information > > embedded. > > > > > > I disagree that this should be done in the agent, > > And I agree with Stefan that it should. The point is that > there are going to be many settings where a human operator is > sitting in front of a screen watching incoming alarms. Not the > job I want, but there are people that do this. What Stefan is > suggesting, and I think it makes great sense, is that the agent > indeed include some reasonable text string that can be shown to > this human operator _immediately_ upon receipt of the alarm. > Whether this is the best way to manage networks or not is > of course debatable, but there is no question that there are > definitely users of this technology who would benefit from this. > > > especially if it ends up being done somewhere like a text > > string. The result of this approach can be seen with fields such > > as ifName and ifDescription. No agent gives either consistent > > information or consistent format. > > That certainly is true, but it doesn't really change the fact > that this would be useful in many cases. I guarantee that if we > build boxes that put silliness into such a text string, we'll > hear about it very quickly from our customers. > > > I've even seen systems where > > it isn't even consistent for its different ifTypes. My approach > > is that base information should be given in a consistent, hard > > to mess up format such as an integer, and the manager does the > > mapping to get physical components or other information it needs > > and then displays it in a nice consistent format to the user. In > > my experience, this is the only way this sort of thing works. > > I obviously cannot argue with your experience. I can, though, > make a case for the fact that our customers are definitely going > to want to have something easily displayable when an alarm > arrives at the manager. The text string would allow this to > happen. > > > > > Issue 2: index variables in notifications > > ----------------------------------------- > > Notifications should not be carried by traps, see "7.7. > > Mapping of the INDEX clause", rfc2578. If we go for Solution > > 1 above, sending the alarmModelDescription in the traps, > > we would implicit send the index variables in the var bind: > > alarmModelDescription.. = > > "Toaster burning" > > > > The definition would be: > > alarmRaise NOTIFICATION-TYPE > > OBJECTS { alarmModelDescription, > > alarmActiveResourceType, > > alarmActiveResourceId } > > STATUS current > > > > > This goes back to how annoying it is that table indices are > not accessible > > in SMIv2. Annoying, Annoying, Annoying. It looks like we > should be fixing > > this in SMIng. > > I don't think it's broken. I think it's absolutely correct. If > I do a get-next on interfaces and get back ifDescr.1 = "blah" why > it is so hard to figure out that ifIndex is 1. I think the > reason for this change (to promote better management applications > since they don't display indices based on separate objects in a > response) are very sound. I certainly hope that SMIng won't > "fix" this. > > And whether one considers it broken or not, the rule exists in > RFC 2578, so I think Stefan's correct. > > Cheers, > > David > From owner-disman@dorothy.bmc.com Thu Jan 17 22:41:22 2002 Received: from babbler.bmc.com (camaro.bmc.com [198.207.223.231]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA20931 for ; Thu, 17 Jan 2002 22:41:22 -0500 (EST) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g0I3hWB05506; Thu, 17 Jan 2002 21:43:32 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id TAA10599 for disman-list; Thu, 17 Jan 2002 19:37:32 -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 TAA10594 for ; Thu, 17 Jan 2002 19:37:28 -0800 (PST) Received: from mx-us-hou-1-int.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id g0I3aAG25650 for ; Thu, 17 Jan 2002 21:36:10 -0600 (CST) Received: from iere.net.avaya.com (unknown [198.152.12.101]) by mx-us-hou-1-int.bmc.com (Postfix) with SMTP id A148B20F020 for ; Fri, 18 Jan 2002 03:26:09 -0600 (CST) Received: from iere.net.avaya.com (localhost [127.0.0.1]) by iere.net.avaya.com (8.11.2/8.9.3) with ESMTP id g0I3bOC21759 for ; Thu, 17 Jan 2002 22:37:24 -0500 (EST) Received: from IS0004AVEXU1.global.avaya.com (h149-49-38-91.avaya.com [149.49.38.91]) by iere.net.avaya.com (8.11.2/8.9.3) with ESMTP id g0I3bOT21755 for ; Thu, 17 Jan 2002 22:37:24 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Active alarm Date: Fri, 18 Jan 2002 05:37:51 +0200 Message-ID: Thread-Topic: Active alarm Thread-Index: AcGeJS/JPJWMjA7hRN2gpRQ/MrLPEQBYBwAA From: "Romascanu, Dan (Dan)" To: "Sharon Chisholm" , , "Nallappa, Bhashyam" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by dorothy.bmc.com id TAA10595 Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list Content-Transfer-Encoding: 8bit I would add to Sharon's comments that we did discuss in early stages whether to include an aging mechanism in the Alarm MIB, and decide not to do it, because that would mandate the existence of such a mechanism in the device that implements the agent. Regards, Dan > -----Original Message----- > From: Sharon Chisholm [mailto:schishol@nortelnetworks.com] > Sent: Wednesday, January 16, 2002 2:29 AM > To: disman@dorothy.bmc.com; Nallappa, Bhashyam > Subject: RE: Active alarm > > > hi > > Traditionally alarm aging is done in the manager, not on the > managed system. It is often done to try and kludge an alarm > management model in systems that don't send proper clear > notifications to indicate a problem is no longer occurring. > > The alarm MIB allows you to model alarms using the alarmClear > notification provided. This can be sent out to indicate that > the problem the alarm is signalling is no longer occurring. > It should therefore not be necessary to instrument alarm > aging. > > Sharon > > -----Original Message----- > From: Nallappa, Bhashyam [mailto:BNallappa@armillaire.com] > Sent: Tuesday, January 15, 2002 10:45 AM > To: disman@dorothy.bmc.com > Subject: Active alarm > > > > Hello, > I have a question regarding the active alarms clearing philosphy. > As I understand that we can paired alarms whereby the up > alarm clears the > down alarm > for example as in the case of linkup alarm clearing the linkdown alarm > I also read somewhere about the concept of aging. > So if an alarm has not been cleared for an extended period > (this could be an > implenetation issue) > then the alarm would be cleared from the list of active alarms. > Can someone who have either implemented such an aging scheme > or one who > knows about this > comment on this please > Thanks > Bhashyam Nallappa > From owner-disman@dorothy.bmc.com Fri Jan 18 11:13:02 2002 Received: from babbler.bmc.com (firebird.bmc.com [198.207.223.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16723 for ; Fri, 18 Jan 2002 11:13:02 -0500 (EST) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g0IGFGr10472; Fri, 18 Jan 2002 10:15:16 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id IAA23089 for disman-list; Fri, 18 Jan 2002 08:10: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 IAA23084 for ; Fri, 18 Jan 2002 08:10:10 -0800 (PST) Received: from mx-us-hou-2-int.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id g0IG8oC17192 for ; Fri, 18 Jan 2002 10:08:50 -0600 (CST) Received: from swan.prod.itd.earthlink.net (swan.mail.pas.earthlink.net [207.217.120.123]) by mx-us-hou-2-int.bmc.com (Postfix) with SMTP id 829F61FF06C for ; Fri, 18 Jan 2002 16:00:11 -0600 (CST) Received: from 1cust98.tnt4.minneapolis.mn.da.uu.net ([63.11.56.98] helo=merkita.com) by swan.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16RbbY-0004tG-00; Fri, 18 Jan 2002 08:11:01 -0800 Message-ID: <3C4848CC.16F179C6@merkita.com> Date: Fri, 18 Jan 2002 10:09:48 -0600 From: Tammy Ferris Reply-To: tferris@merkita.com X-Mailer: Mozilla 4.75 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Romascanu, Dan (Dan)" Cc: "David L. Partain" , Sharon Chisholm , disman@dorothy.bmc.com, Stefan Wallin Subject: Re: disman alarm mib comments References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list Content-Transfer-Encoding: 7bit Dan, In the applications that I am familiar with, this type of text information is not standardized. I don't think the text or the format of the text needs to be standardized as I would think the content would vary depending on the application. In the telecom standards, it is up to the agent to determine what to put in the text description. In some applications, operators are allowed to edit the text descriptions that are to be emitted by the agent. Tammy Tammy Ferris Merkita, Incorporated +1 (763)577-5945 tferris@merkita.com "Romascanu, Dan (Dan)" wrote: > This is probably a discussion that started the day the first > notification was sent on the wire. The argument is not about the fact > that users would rather see messages in English (or Swedish, or Hebrew) > rather than OIDs, that might actually include re-directing information. > We should never argue with customers. The question is about how we > implement this. Should we build clear text messages in the agent, or > should we somehow code these messages, use some (quite simple) parsing > SW in the application and refer a text file to present the readable > information to the user. > > Am I mistaken, or do you suggest a third way to do it - not only have > the agent send clear readable text, but even define the text as part of > the standard? > > I just want to make sure that I do not mis-read you and Stefan. > > Thanks, > > Dan > > > -----Original Message----- > > From: David L. Partain [mailto:partain@cs.utk.edu] > > Sent: Thursday, January 17, 2002 7:06 PM > > To: Sharon Chisholm; disman@dorothy.bmc.com; Stefan Wallin > > Subject: Re: disman alarm mib comments > > > > > > Greetings, > > > > I don't believe I have seen an answer to some of the issues > > herein, so I'll give it my 2 eurocents. I've cut out lots of > > things that I think have been discussed elsewhere. I hope I > > haven't whacked too zealously. > > > > > > > > But again, traps are displayed in real-time > > > for end-users and it is critical for them to quickly > > identify the resource. > > > > > > Example: an ifIndex does not tell the typical alarm > > operator that much... > > > The alarm should say: "Slot 1, port 17, link is down > > administratively." > > > > > > My recommendation is that the user-friendly var-bind above has this > > > information > > > embedded. > > > > > > > > > I disagree that this should be done in the agent, > > > > And I agree with Stefan that it should. The point is that > > there are going to be many settings where a human operator is > > sitting in front of a screen watching incoming alarms. Not the > > job I want, but there are people that do this. What Stefan is > > suggesting, and I think it makes great sense, is that the agent > > indeed include some reasonable text string that can be shown to > > this human operator _immediately_ upon receipt of the alarm. > > Whether this is the best way to manage networks or not is > > of course debatable, but there is no question that there are > > definitely users of this technology who would benefit from this. > > > > > especially if it ends up being done somewhere like a text > > > string. The result of this approach can be seen with fields such > > > as ifName and ifDescription. No agent gives either consistent > > > information or consistent format. > > > > That certainly is true, but it doesn't really change the fact > > that this would be useful in many cases. I guarantee that if we > > build boxes that put silliness into such a text string, we'll > > hear about it very quickly from our customers. > > > > > I've even seen systems where > > > it isn't even consistent for its different ifTypes. My approach > > > is that base information should be given in a consistent, hard > > > to mess up format such as an integer, and the manager does the > > > mapping to get physical components or other information it needs > > > and then displays it in a nice consistent format to the user. In > > > my experience, this is the only way this sort of thing works. > > > > I obviously cannot argue with your experience. I can, though, > > make a case for the fact that our customers are definitely going > > to want to have something easily displayable when an alarm > > arrives at the manager. The text string would allow this to > > happen. > > > > > > > > Issue 2: index variables in notifications > > > ----------------------------------------- > > > Notifications should not be carried by traps, see "7.7. > > > Mapping of the INDEX clause", rfc2578. If we go for Solution > > > 1 above, sending the alarmModelDescription in the traps, > > > we would implicit send the index variables in the var bind: > > > alarmModelDescription.. = > > > "Toaster burning" > > > > > > The definition would be: > > > alarmRaise NOTIFICATION-TYPE > > > OBJECTS { alarmModelDescription, > > > alarmActiveResourceType, > > > alarmActiveResourceId } > > > STATUS current > > > > > > > > This goes back to how annoying it is that table indices are > > not accessible > > > in SMIv2. Annoying, Annoying, Annoying. It looks like we > > should be fixing > > > this in SMIng. > > > > I don't think it's broken. I think it's absolutely correct. If > > I do a get-next on interfaces and get back ifDescr.1 = "blah" why > > it is so hard to figure out that ifIndex is 1. I think the > > reason for this change (to promote better management applications > > since they don't display indices based on separate objects in a > > response) are very sound. I certainly hope that SMIng won't > > "fix" this. > > > > And whether one considers it broken or not, the rule exists in > > RFC 2578, so I think Stefan's correct. > > > > Cheers, > > > > David > > From owner-disman@dorothy.bmc.com Fri Jan 18 11:18:39 2002 Received: from babbler.bmc.com (firebird.bmc.com [198.207.223.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16912 for ; Fri, 18 Jan 2002 11:18:39 -0500 (EST) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g0IGKuG11561; Fri, 18 Jan 2002 10:20:56 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id IAA23122 for disman-list; Fri, 18 Jan 2002 08:16:17 -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 IAA23117 for ; Fri, 18 Jan 2002 08:16:13 -0800 (PST) Received: from mx-us-hou-1-int.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id g0IGEr719231 for ; Fri, 18 Jan 2002 10:14:53 -0600 (CST) Received: from swan.prod.itd.earthlink.net (unknown [207.217.120.123]) by mx-us-hou-1-int.bmc.com (Postfix) with SMTP id 2434820F02E for ; Fri, 18 Jan 2002 16:04:55 -0600 (CST) Received: from 1cust98.tnt4.minneapolis.mn.da.uu.net ([63.11.56.98] helo=merkita.com) by swan.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16Rbhb-000587-00; Fri, 18 Jan 2002 08:17:16 -0800 Message-ID: <3C484A43.A3DCA537@merkita.com> Date: Fri, 18 Jan 2002 10:16:04 -0600 From: Tammy Ferris Reply-To: tferris@merkita.com X-Mailer: Mozilla 4.75 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "David L. Partain" Cc: Sharon Chisholm , disman@dorothy.bmc.com, Stefan Wallin Subject: Re: disman alarm mib comments References: <200201171705.MAA01870@duncan.cs.utk.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list Content-Transfer-Encoding: 7bit I support the idea of having a text string associated with the alarm. This alarm information field is optional in telecom but widely used. Tammy Tammy Ferris Merkita Incorporated +1 (763)577-5946 tferris@merkita.com "David L. Partain" wrote: > Greetings, > > I don't believe I have seen an answer to some of the issues > herein, so I'll give it my 2 eurocents. I've cut out lots of > things that I think have been discussed elsewhere. I hope I > haven't whacked too zealously. > > > > > But again, traps are displayed in real-time > > for end-users and it is critical for them to quickly identify the resource. > > > > Example: an ifIndex does not tell the typical alarm operator that much... > > The alarm should say: "Slot 1, port 17, link is down administratively." > > > > My recommendation is that the user-friendly var-bind above has this > > information > > embedded. > > > > > > I disagree that this should be done in the agent, > > And I agree with Stefan that it should. The point is that > there are going to be many settings where a human operator is > sitting in front of a screen watching incoming alarms. Not the > job I want, but there are people that do this. What Stefan is > suggesting, and I think it makes great sense, is that the agent > indeed include some reasonable text string that can be shown to > this human operator _immediately_ upon receipt of the alarm. > Whether this is the best way to manage networks or not is > of course debatable, but there is no question that there are > definitely users of this technology who would benefit from this. > > > especially if it ends up being done somewhere like a text > > string. The result of this approach can be seen with fields such > > as ifName and ifDescription. No agent gives either consistent > > information or consistent format. > > That certainly is true, but it doesn't really change the fact > that this would be useful in many cases. I guarantee that if we > build boxes that put silliness into such a text string, we'll > hear about it very quickly from our customers. > > > I've even seen systems where > > it isn't even consistent for its different ifTypes. My approach > > is that base information should be given in a consistent, hard > > to mess up format such as an integer, and the manager does the > > mapping to get physical components or other information it needs > > and then displays it in a nice consistent format to the user. In > > my experience, this is the only way this sort of thing works. > > I obviously cannot argue with your experience. I can, though, > make a case for the fact that our customers are definitely going > to want to have something easily displayable when an alarm > arrives at the manager. The text string would allow this to > happen. > > > > > Issue 2: index variables in notifications > > ----------------------------------------- > > Notifications should not be carried by traps, see "7.7. > > Mapping of the INDEX clause", rfc2578. If we go for Solution > > 1 above, sending the alarmModelDescription in the traps, > > we would implicit send the index variables in the var bind: > > alarmModelDescription.. = > > "Toaster burning" > > > > The definition would be: > > alarmRaise NOTIFICATION-TYPE > > OBJECTS { alarmModelDescription, > > alarmActiveResourceType, > > alarmActiveResourceId } > > STATUS current > > > > > This goes back to how annoying it is that table indices are not accessible > > in SMIv2. Annoying, Annoying, Annoying. It looks like we should be fixing > > this in SMIng. > > I don't think it's broken. I think it's absolutely correct. If > I do a get-next on interfaces and get back ifDescr.1 = "blah" why > it is so hard to figure out that ifIndex is 1. I think the > reason for this change (to promote better management applications > since they don't display indices based on separate objects in a > response) are very sound. I certainly hope that SMIng won't > "fix" this. > > And whether one considers it broken or not, the rule exists in > RFC 2578, so I think Stefan's correct. > > Cheers, > > David From owner-disman@dorothy.bmc.com Sat Jan 19 09:01:25 2002 Received: from babbler.bmc.com (camaro.bmc.com [198.207.223.231]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19197 for ; Sat, 19 Jan 2002 09:01:25 -0500 (EST) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g0JE3X329763; Sat, 19 Jan 2002 08:03:33 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id FAA29798 for disman-list; Sat, 19 Jan 2002 05:56:48 -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 FAA29793 for ; Sat, 19 Jan 2002 05:56:44 -0800 (PST) From: aldri@inf.ufpr.br Received: from mx-us-hou-1-int.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id g0JDtPI27145 for ; Sat, 19 Jan 2002 07:55:25 -0600 (CST) Received: from inf.ufpr.br (unknown [200.17.212.164]) by mx-us-hou-1-int.bmc.com (Postfix) with SMTP id EF90220EF99 for ; Sat, 19 Jan 2002 13:45:20 -0600 (CST) Received: (qmail 5381 invoked from network); 19 Jan 2002 13:58:08 -0000 Received: from haddock.inf.ufpr.br (qmailr@200.17.212.168) by caco.inf.ufpr.br with SMTP; 19 Jan 2002 13:58:08 -0000 Received: (qmail 12118 invoked by uid 9601); 19 Jan 2002 13:58:08 -0000 Message-ID: <20020119135808.12117.qmail@haddock.inf.ufpr.br> Subject: Re: replication discussion? In-Reply-To: <200201150055.QAA27084@dorothy.bmc.com> "from Randy Presuhn at Jan 14, 2002 04:55:36 pm" To: disman@dorothy.bmc.com Date: Sat, 19 Jan 2002 11:58:07 -0200 (BRST) Cc: aldri santos X-Mailer: ELM [version 2.4ME+ PL89 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list Content-Transfer-Encoding: 7bit Hi, > Any followup discussion to the Clustering Architecture / > replication discussion in Salt Lake City? A new slightly revised version of the Clustering/Replication MIB is available at: http://www.inf.ufpr.br/~aldri/draft/replicationmib/index.html Your regular monitoring system allows you to browse the MIB of all working/fault-free agents, but what about the crashed/unreachable agents? As the agent has crashed, you can't access its MIB variables, right? Not with the Clustering Architecture/ Replication MIB! By browsing the MIB of a crashed agent you may discover what was the traffic on its interfaces before it crashed, what type of traffic was there, and the system state including protocols, CPU, memory, etc. In order to get this benefit, we must pay a price: the extra traffic required to replicate selected managed objects. It is possible to determine replication intervals that will cause an extra traffic that fits within acceptable bounds. Furthermore, the distributed clustering architecture avoids bottlenecks in network monitoring. We are looking forward to your comments! Aldri From owner-disman@dorothy.bmc.com Sun Jan 20 12:57:00 2002 Received: from babbler.bmc.com (camaro.bmc.com [198.207.223.231]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14172 for ; Sun, 20 Jan 2002 12:57:00 -0500 (EST) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g0KHx5S20812; Sun, 20 Jan 2002 11:59:05 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id JAA13931 for disman-list; Sun, 20 Jan 2002 09:52:04 -0800 (PST) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id JAA13925; Sun, 20 Jan 2002 09:51:59 -0800 (PST) Date: Sun, 20 Jan 2002 09:51:59 -0800 (PST) From: Randy Presuhn Message-Id: <200201201751.JAA13925@dorothy.bmc.com> To: disman@dorothy.bmc.com Subject: Fwd: Alarm source & compatility with syslog Cc: izilbers@avaya.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list Content-Transfer-Encoding: 7bit Hi - I'm forwarding a non-subscriber posting to the disman WG mailing list from izilbers@avaya.com. Subscription instructions are at http://www.ietf.org/html.charters/disman-charter.html ------------------------------------------------------ Randy Presuhn BMC Software, Inc. 1-3141 randy_presuhn@bmc.com 2141 North First Street Tel: +1 408 546-1006 San José, California 95131 USA ------------------------------------------------------ My opinions and BMC's are independent variables. ------------------------------------------------------ > 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 JAA13354 > for ; Sun, 20 Jan 2002 09:12:24 -0800 (PST) > Received: from mx-us-hou-2-int.bmc.com (localhost [127.0.0.1]) > by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id g0KHB3T12678 > for ; Sun, 20 Jan 2002 11:11:03 -0600 (CST) > Received: from iere.net.avaya.com (iere.net.avaya.com [198.152.12.101]) > by mx-us-hou-2-int.bmc.com (Postfix) with SMTP id EFE421FF06B > for ; Sun, 20 Jan 2002 17:02:20 -0600 (CST) > Received: from iere.net.avaya.com (localhost [127.0.0.1]) > by iere.net.avaya.com (8.11.2/8.9.3) with ESMTP id g0KHCIx12772 > for ; Sun, 20 Jan 2002 12:12:18 -0500 (EST) > Received: from IS0004AVEXU1.global.avaya.com (h149-49-38-91.avaya.com [149.49.38.91]) > by iere.net.avaya.com (8.11.2/8.9.3) with ESMTP id g0KHCGp12768 > for ; Sun, 20 Jan 2002 12:12:17 -0500 (EST) > X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 > content-class: urn:content-classes:message > MIME-Version: 1.0 > Content-Type: multipart/alternative; > boundary="----_=_NextPart_001_01C1A1D5.AC9953A5" > Subject: Alarm source & compatility with syslog > Date: Sun, 20 Jan 2002 19:12:43 +0200 > Message-ID: > Thread-Topic: Alarm source & compatility with syslog > Thread-Index: AcGh1cUQnTJunFOISy6f3rT/6gnoZw== > From: "Zilbershtein, Itai (Itai)" > To: "Sharon Chisholm" , > > This is a multi-part message in MIME format. > > ------_=_NextPart_001_01C1A1D5.AC9953A5 > Content-Type: text/plain; > charset="us-ascii" > Content-Transfer-Encoding: quoted-printable > > 1. In the current Alarm MIB draft, the alarm source is known as > "resource" (i.e., alarmActiveResourceType, alarmActiveResourceId). This > term is not particularly clear to the readers of the MIB. Furthermore, > it is difficult (well, at least I was challenged :-) ) to understand > from Section 4.1.4 (that describes ResourceType and ResourceID) or from > the Description clause in the MIB itself that "resource"=3D=3D"alarm > source". In syslog, for instance (RFC3164) , the sub-system that > generated a message is known as "Facility"; It might be nice if the > description (or the term chosen for this datum) will reflect this > similarity.=20 > > 2. Syslog compatibility - while I'm aware that syslog is an > entirely different system, and that some differences between syslog and > SNMP based alarm tracking may be hard to reconcile, it may be handy to > provide a standard mapping between syslog's Severities and > alarmModelState (especially as it appears that the severity scale in > syslog is exactly the opposite of what is expected in alarmModelState - > lower value translates to a higher severity). Syslog is in wide use, and > people are bound to come to the point where the same underlying events > are to be represented both in syslog and the Alarm MIB. > > For reference, here are the syslog Severities: (RFC 3164, page 8):=20 > > " Numerical Severity > Code > 0 Emergency: system is unusable > 1 Alert: action must be taken immediately > 2 Critical: critical conditions > 3 Error: error conditions > 4 Warning: warning conditions > 5 Notice: normal but significant condition > 6 Informational: informational messages > 7 Debug: debug-level messages > > Table 2. syslog Message Severities" > > ItaiZ. > > ------------------------------------------------------------------------ > ------- > Itai Zilbershtein > System Architecture Group, LSG-I, EIS, Avaya Inc. > mailto:izilbers@Avaya.com Tel/Fax: +972(3)6457667=20 > Avaya Voice Mail box: (09723) 37667 > > > ------_=_NextPart_001_01C1A1D5.AC9953A5 > Content-Type: text/html; > charset="us-ascii" > Content-Transfer-Encoding: quoted-printable > > > > > charset=3Dus-ascii"> > 6.0.4720.25"> > Alarm source & compatility with syslog > > > > >

COLOR=3D"#000000" SIZE=3D2 = > FACE=3D"Arial">1.      LANG=3D"ar-sa"> SIZE=3D2 FACE=3D"Arial">In the current Alarm MIB draft, the alarm source = > is known as “ COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">resource” (i.e., = > alarmActiveResourceType, alarmActiveResourceId).  This = > term FACE=3D"Arial"> COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">is not LANG=3D"en-us"> FACE=3D"Arial">particularly clear to the readers of the = > MIB FACE=3D"Arial">. COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">Furthermore, it is = > difficult SIZE=3D2 FACE=3D"Arial">(well, at least I was = > challenged SIZE=3D2 FACE=3D"Arial">:-) COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">) LANG=3D"en-us"> to = > understand from S COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">ection = > 4.1.4 SIZE=3D2 FACE=3D"Arial">( COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">that describes ResourceType = > and ResourceID SIZE=3D2 FACE=3D"Arial">) or from the Description clause in the MIB = > itself that  COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial"> LANG=3D"en-us"> FACE=3D"Arial">“ COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">resource LANG=3D"en-us"> FACE=3D"Arial">” COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">=3D=3D LANG=3D"en-us"> FACE=3D"Arial">” COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">alarm = > source SIZE=3D2 FACE=3D"Arial">” COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">. LANG=3D"en-us"> In = > syslog, for instance COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial"> (RFC3164) LANG=3D"en-us"> , the = > sub-s FACE=3D"Arial">yst COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">em that generated a message is = > known as “Facility” COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">; LANG=3D"en-us"> FACE=3D"Arial">I COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">t LANG=3D"en-us"> FACE=3D"Arial">might COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial"> be nice if the description = > (or the term SIZE=3D2 FACE=3D"Arial"> chosen for this datum LANG=3D"en-us">) will = > reflect this SIZE=3D2 FACE=3D"Arial">similarity LANG=3D"en-us"> FACE=3D"Arial">.

> >

LANG=3D"ar-sa">

> >

LANG=3D"ar-sa"> SIZE=3D2 = > FACE=3D"Arial">2.      LANG=3D"en-us"> LANG=3D"ar-sa"> SIZE=3D2 FACE=3D"Arial">Syslog compatibility LANG=3D"en-us"> FACE=3D"Arial">– COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial"> LANG=3D"en-us"> while = > I’m aware that syslog is COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">an LANG=3D"en-us"> entirely = > different system, and that some differences between syslog and SNMP = > based alarm tracking COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">may be hard = > to FACE=3D"Arial"> reconcile COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">, it may be handy to provide a = > standard mapping between COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">syslog’s Severities = > and FACE=3D"Arial"> COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">alarmModelState (especially as = > it appears th SIZE=3D2 FACE=3D"Arial">at the severity scale in syslog is exactly the = > oppo FACE=3D"Arial">site of what is expected in alarmModelState – lower = > value translates to a higher severity). LANG=3D"en-us"> Syslog = > is in wide use, and people are bound to come to the point where the same = > underlying events are to be COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">represented LANG=3D"en-us"> both in = > syslog and the Alarm MIB.

> >

> >

LANG=3D"ar-sa"> SIZE=3D2 FACE=3D"Arial">For reference, here are the syslog = > Severities: SIZE=3D2 FACE=3D"Arial"> (RFC COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial"> LANG=3D"en-us"> 3164, = > page 8):

> >

LANG=3D"ar-sa">

> >

FACE=3D"Arial">“ COLOR=3D"#000000" SIZE=3D2 = > FACE=3D"Arial">        = > Numerical         = > Severity

> >

FACE=3D"Arial">          = > Code

> >

FACE=3D"Arial">         &nbs= > p; 0       Emergency: system is = > unusable

> >

FACE=3D"Arial">         &nbs= > p; 1       Alert: action must be taken = > immediately

> >

FACE=3D"Arial">         &nbs= > p; 2       Critical: critical = > conditions

> >

FACE=3D"Arial">         &nbs= > p; 3       Error: error = > conditions

> >

FACE=3D"Arial">         &nbs= > p; 4       Warning: warning = > conditions

> >

FACE=3D"Arial">         &nbs= > p; 5       Notice: normal but significant = > condition

> >

FACE=3D"Arial">         &nbs= > p; 6       Informational: informational = > messages

> >

FACE=3D"Arial">         &nbs= > p; 7       Debug: debug-level = > messages

> >

FACE=3D"Arial">         &nbs= > p; Table 2. syslog Message Severities LANG=3D"en-us"> FACE=3D"Arial">”

> >

FACE=3D"Arial">ItaiZ.

> >

> >

COLOR=3D"#000000" SIZE=3D2 = > FACE=3D"Arial">----------------------------------------------------------= > ---------------------

> >

FACE=3D"Arial">Itai Zilbershtein

> >

FACE=3D"Arial">System Architecture Group, LSG-I, EIS, Avaya = > Inc.

> >

FACE=3D"Arial"> HREF=3D"mailto:izilbers@Avaya.com">mailto:izilbers@Avaya.com  = > Tel/Fax: +972(3)6457667

> >

FACE=3D"Arial">Avaya Voice Mail box: (09723) 37667

> >

LANG=3D"ar-sa">

> > > > ------_=_NextPart_001_01C1A1D5.AC9953A5-- > From owner-disman@dorothy.bmc.com Sun Jan 20 15:07:37 2002 Received: from babbler.bmc.com (firebird.bmc.com [198.207.223.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15411 for ; Sun, 20 Jan 2002 15:07:37 -0500 (EST) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g0KK9uR28023; Sun, 20 Jan 2002 14:09:56 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id MAA14452 for disman-list; Sun, 20 Jan 2002 12:04:19 -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 MAA14446; Sun, 20 Jan 2002 12:04:15 -0800 (PST) Received: from mx-us-hou-1-int.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id g0KK2rl02721; Sun, 20 Jan 2002 14:02:54 -0600 (CST) Received: from rwcrmhc51.attbi.com (unknown [204.127.198.38]) by mx-us-hou-1-int.bmc.com (Postfix) with SMTP id 3FB1C20EFAC; Sun, 20 Jan 2002 19:52:34 -0600 (CST) Received: from dperkins-nb2.dsperkins.com ([12.234.130.131]) by rwcrmhc51.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020120200530.MRLA26243.rwcrmhc51.attbi.com@dperkins-nb2.dsperkins.com>; Sun, 20 Jan 2002 20:05:30 +0000 Message-Id: <5.0.2.1.2.20020120120159.028b62d0@mail4.bayarea.net> X-Sender: dperkins@mail4.bayarea.net X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Sun, 20 Jan 2002 12:05:10 -0800 To: Randy Presuhn , disman@dorothy.bmc.com From: "David T. Perkins" Subject: Re: Fwd: Alarm source & compatility with syslog Cc: izilbers@avaya.com In-Reply-To: <200201201751.JAA13925@dorothy.bmc.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list HI, Interesting.... It appears (but this is difficult to determine without re-reading the syslog docs) that we have yet another example of the confusion in terminology between "event reports" and "alarm reports". Regards, /david t. perkins At 09:51 AM 1/20/2002 -0800, Randy Presuhn wrote: >> Subject: Alarm source & compatility with syslog >> Date: Sun, 20 Jan 2002 19:12:43 +0200 >> From: "Zilbershtein, Itai (Itai)" >> To: "Sharon Chisholm" , >> >> 1. In the current Alarm MIB draft, the alarm source is known as >> "resource" (i.e., alarmActiveResourceType, alarmActiveResourceId). This >> term is not particularly clear to the readers of the MIB. Furthermore, >> it is difficult (well, at least I was challenged :-) ) to understand >> from Section 4.1.4 (that describes ResourceType and ResourceID) or from >> the Description clause in the MIB itself that "resource"=3D=3D"alarm >> source". In syslog, for instance (RFC3164) , the sub-system that >> generated a message is known as "Facility"; It might be nice if the >> description (or the term chosen for this datum) will reflect this >> similarity.=20 >> >> 2. Syslog compatibility - while I'm aware that syslog is an >> entirely different system, and that some differences between syslog and >> SNMP based alarm tracking may be hard to reconcile, it may be handy to >> provide a standard mapping between syslog's Severities and >> alarmModelState (especially as it appears that the severity scale in >> syslog is exactly the opposite of what is expected in alarmModelState - >> lower value translates to a higher severity). Syslog is in wide use, and >> people are bound to come to the point where the same underlying events >> are to be represented both in syslog and the Alarm MIB. >> >> For reference, here are the syslog Severities: (RFC 3164, page 8):=20 >> >> " Numerical Severity >> Code >> 0 Emergency: system is unusable >> 1 Alert: action must be taken immediately >> 2 Critical: critical conditions >> 3 Error: error conditions >> 4 Warning: warning conditions >> 5 Notice: normal but significant condition >> 6 Informational: informational messages >> 7 Debug: debug-level messages >> >> Table 2. syslog Message Severities" >> >> ItaiZ. >> >> ------------------------------------------------------------------------ >> ------- >> Itai Zilbershtein >> System Architecture Group, LSG-I, EIS, Avaya Inc. >> mailto:izilbers@Avaya.com Tel/Fax: +972(3)6457667=20 >> Avaya Voice Mail box: (09723) 37667 From owner-disman@dorothy.bmc.com Sun Jan 20 16:49:51 2002 Received: from babbler.bmc.com (firebird.bmc.com [198.207.223.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16598 for ; Sun, 20 Jan 2002 16:49:51 -0500 (EST) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g0KLqBT02902; Sun, 20 Jan 2002 15:52:11 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id NAA14615 for disman-list; Sun, 20 Jan 2002 13:46:45 -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 NAA14610 for ; Sun, 20 Jan 2002 13:46:42 -0800 (PST) Received: from mx-us-hou-1-int.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id g0KLjKw14474 for ; Sun, 20 Jan 2002 15:45:20 -0600 (CST) Received: from zcars0m9.ca.nortel.com (unknown [47.129.242.157]) by mx-us-hou-1-int.bmc.com (Postfix) with SMTP id 335C320F071 for ; Sun, 20 Jan 2002 21:35:10 -0600 (CST) Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56]) by zcars0m9.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g0KLm0P14050; Sun, 20 Jan 2002 16:48:00 -0500 (EST) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g0KLlwB27070; Sun, 20 Jan 2002 16:47:58 -0500 (EST) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Sun, 20 Jan 2002 16:47:59 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD3401766B22@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: disman@dorothy.bmc.com, "Romascanu, Dan (Dan)" Subject: Updated Alarm MIB Issues 1-15 Date: Sun, 20 Jan 2002 16:47:59 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list hi Version -05 is in progress and we can send it out when we close off on the remaining issues. Newly Closed ------------- Alarm #4 - Relation to Event MIB Add the following text to -05 x.y Relationship with the Event MIB During the work and discussions in the Working Group, the issue of the relationship between the MIB modules and the Event MIB [RFC...] was raised. There is no direct relation or dependency between the Alarm MIB and the Event MIB. Some common terms (like 'event') are being used in both MIB modules, and the user is directed to the sections that define terminology in the two documents for clarification. Alarm#12 Time Zone in DataAndTime Add the following to -05 Implementations MUST include the offset from UTC, if available. Implementation in environments in which the UTC offset is not available is NOT RECOMMENDED. Open Issues ---------- > Alarm#9 Example showing relation to Condition and Arc MIB > Currently missing from -04 > > Alarm#11 Resource Identification > The resource identification method in -04 uses a type and > integer value pair to identify a resource. There has > been some support for using an OID instead. There are > pros and cons to each approach. I'd also add the discussion of a per instance displayString here as well. A display string in the active alarm table serves simple managers well, although it's a nightmare for anyone trying to do anything other than display the object. It might make sense to include both it and an object that can be used by more complicated managers to do more interesting things with. I'm still not a fan of the OID approach, but it seems to have a lot of support. We may be able to produce something with a lot of MUSTs in that might address my concerns. > > Alarm#13 DMTF input into probable cause > We have some input from DMTF as to potential additional probable > cause values. When these are available, the initial set of > probable causes can be updated. If we receive this input, we can include it. Otherwise, these additional causes can be added using IANA. Alarm#14 alarmRaise notification inconsistent with terminology Change the alarmRaise notification to be alarmSet to be consistent with the terminology as defined. Alarm#15 RowStatus and Not in service There may be an issue here, I'm still catching up on the email. Sharon From owner-disman@dorothy.bmc.com Sun Jan 20 16:57:54 2002 Received: from babbler.bmc.com (firebird.bmc.com [198.207.223.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16641 for ; Sun, 20 Jan 2002 16:57:53 -0500 (EST) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g0KM0Ef03394; Sun, 20 Jan 2002 16:00:14 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id NAA14641 for disman-list; Sun, 20 Jan 2002 13:54:56 -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 NAA14632 for ; Sun, 20 Jan 2002 13:54:52 -0800 (PST) Received: from mx-us-hou-2-int.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id g0KLrUT15747 for ; Sun, 20 Jan 2002 15:53:30 -0600 (CST) Received: from zcars0m9.ca.nortel.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by mx-us-hou-2-int.bmc.com (Postfix) with SMTP id 8C8221FF033 for ; Sun, 20 Jan 2002 21:44:47 -0600 (CST) Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57]) by zcars0m9.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g0KLtjP14561; Sun, 20 Jan 2002 16:55:46 -0500 (EST) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g0KLthp25435; Sun, 20 Jan 2002 16:55:44 -0500 (EST) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Sun, 20 Jan 2002 16:55:44 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD3401766B24@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: disman@dorothy.bmc.com, Stefan Wallin Subject: RE: more comments... Date: Sun, 20 Jan 2002 16:55:42 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list hi alarmModelRowStatus ===================== Current description of alarmModelRowStatus: "Control for creating and deleting entries. Entries may be modified while active. This row can not be deleted while it is being referenced by a value of alarmActiveModelPointer" I assume we should expand the restrictions to: This row can not be deleted or _modified_ while it is being referenced by a value of alarmActiveModelPointer. Yes. Thanks, I'll make this change. Comments of editorial art: 1) The ITU-ALARM-TC and ITU-IANA-ALARM-TC are missing MODULE-IDENTITY I was hoping to get away without one as not all textual conventions have them. I've looked, but I don't think I ever found anything that said they were mandatory. 2) The module name starts with ITU which normally should indicate the enterprise owning the module, I wonder what ITU says... Good question. Study group 4 has certainly seen the MIB but the expectation is that disman owns the MIB. 3) Groups in ITU-ALARM-MIB have strange names considering their contained objects. The group names are actually from the group names as defined in one of the ITU documents. I think it was X.733. 4) Page 44: examples section: Thanks, Sharon From owner-disman@dorothy.bmc.com Mon Jan 21 02:54:39 2002 Received: from babbler.bmc.com (firebird.bmc.com [198.207.223.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02346 for ; Mon, 21 Jan 2002 02:54:39 -0500 (EST) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g0L7uvn05953; Mon, 21 Jan 2002 01:56:57 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id XAA15511 for disman-list; Sun, 20 Jan 2002 23:50:17 -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 XAA15506 for ; Sun, 20 Jan 2002 23:50:12 -0800 (PST) Received: from mx-us-hou-1-int.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id g0L7moA06391 for ; Mon, 21 Jan 2002 01:48:50 -0600 (CST) Received: from albatross.wise.edt.ericsson.se (unknown [194.237.142.116]) by mx-us-hou-1-int.bmc.com (Postfix) with SMTP id D792E20EFEF for ; Mon, 21 Jan 2002 07:38:36 -0600 (CST) Received: from mbb5.ericsson.se (mbb5.ericsson.se [136.225.151.210]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g0L7pVIB000353 for ; Mon, 21 Jan 2002 08:51:31 +0100 (MET) Received: from there (lm6068.lmera.ericsson.se [150.132.106.68]) by mbb1.ericsson.se (PMDF V5.2-29 #39352) with SMTP id <0GQA00KHM35UX8@mbb1.ericsson.se> for disman@dorothy.bmc.com; Mon, 21 Jan 2002 08:51:31 +0100 (MET) Date: Mon, 21 Jan 2002 08:51:46 +0100 From: David Partain Subject: Re: more comments... In-reply-to: <3549C09B853DD5119B540002A52CDD3401766B24@zcard0ka.ca.nortel.com> To: Sharon Chisholm , disman@dorothy.bmc.com, Stefan Wallin Reply-To: David.Partain@ericsson.com Message-id: <0GQA00KHP35VX8@mbb1.ericsson.se> MIME-version: 1.0 X-Mailer: KMail [version 1.3.2] Content-type: text/plain; charset=iso-8859-1 References: <3549C09B853DD5119B540002A52CDD3401766B24@zcard0ka.ca.nortel.com> X-MIME-Autoconverted: from 8bit to quoted-printable by albatross.wise.edt.ericsson.se id g0L7pVIB000353 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by dorothy.bmc.com id XAA15507 Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list Content-Transfer-Encoding: 8bit Hi, > > Comments of editorial art: > > 1) The ITU-ALARM-TC and ITU-IANA-ALARM-TC are missing MODULE-IDENTITY > > > I was hoping to get away without one as not all textual conventions > have them. I've looked, but I don't think I ever found anything > that said they were mandatory. See Page 12, RFC 2578, the last paragraph of section 3: All information modules start with exactly one invocation of the MODULE-IDENTITY macro, which provides contact information as well as revision history to distinguish between versions of the same information module. This invocation must appear immediately after any IMPORTs statements. It must be there. > > 2) The module name starts with ITU which normally should indicate the > enterprise owning the module, I wonder what ITU says... > > > Good question. Study group 4 has certainly seen the MIB but the expectation > is that disman owns the MIB. I too find this rather confusing. Since the ITU isn't really involved, and the module name generally helps (at least me) understand who's responsible for the module, it might be a good idea to have DISMAN-ITU rather than just ITU (or something else to remove any confusion). Cheers, -- David Partain David.Partain@ericsson.com Ericsson Research's LinLab Tel: +46 13 28 41 44 P.O. Box 1248 Fax: +46 13 28 75 67 SE-581 12 Linköping, Sweden #include From owner-disman@dorothy.bmc.com Mon Jan 21 07:25:53 2002 Received: from babbler.bmc.com (firebird.bmc.com [198.207.223.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07052 for ; Mon, 21 Jan 2002 07:25:52 -0500 (EST) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g0LCSBu00010; Mon, 21 Jan 2002 06:28:11 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id EAA27188 for disman-list; Mon, 21 Jan 2002 04:22:39 -0800 (PST) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id EAA27183 for ; Mon, 21 Jan 2002 04:22:33 -0800 (PST) Received: from mx-us-hou-1-int.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id g0LCLBu28483 for ; Mon, 21 Jan 2002 06:21:12 -0600 (CST) Received: from penguin-ext.wise.edt.ericsson.se (unknown [194.237.142.110]) by mx-us-hou-1-int.bmc.com (Postfix) with SMTP id A960620EFAB for ; Mon, 21 Jan 2002 12:10:51 -0600 (CST) Received: from mbb5.ericsson.se (mbb5.ericsson.se [136.225.151.210]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id g0LCNlw15311 for ; Mon, 21 Jan 2002 13:23:48 +0100 (MET) Received: from there (lm6068.lmera.ericsson.se [150.132.106.68]) by mbb1.ericsson.se (PMDF V5.2-29 #39352) with SMTP id <0GQA00NJHFRL28@mbb1.ericsson.se> for disman@dorothy.bmc.com; Mon, 21 Jan 2002 13:23:46 +0100 (MET) Date: Mon, 21 Jan 2002 13:24:01 +0100 From: David Partain Subject: dynamic text string in alarms (was Re: disman alarm mib comments) In-reply-to: To: DISMAN Mailing List Reply-To: David.Partain@ericsson.com Message-id: <0GQA00NJIFRM28@mbb1.ericsson.se> MIME-version: 1.0 X-Mailer: KMail [version 1.3.2] Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8bit References: Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list Content-Transfer-Encoding: 8bit Hi, I've changed the subject line to make it clearer what we're talking about. I've also removed individual addresses. Hope everyone that was there before is a disman subscriber :-) The context for the message is at the end of this message, but it basically comes down to whether to put a dynamic text string in notifications or not. That's what I'm after. On Thursday 17 January 2002 18:34, Romascanu, Dan (Dan) wrote: > This is probably a discussion that started the day the first > notification was sent on the wire. The argument is not about the fact > that users would rather see messages in English (or Swedish, or Hebrew) > rather than OIDs, that might actually include re-directing information. > We should never argue with customers. The question is about how we > implement this. Should we build clear text messages in the agent, or > should we somehow code these messages, use some (quite simple) parsing > SW in the application and refer a text file to present the readable > information to the user. I've spent some time working with Stefan on these questions, and this mail is a result of those conversations... As I see it, an alarm notification is used by automated tools _and_ human operators. The notifications we send must support both uses. Automated tools provide functions such as filtering, sorting, correlation, categorization, etc. Operators must be given enough information quickly in order to respond to the alarm. In a distributed alarm management environment there can be thousands of alarms per day. Information needed by automated tools includes: - Resource identification - Alarm and alarm clear correlation - Severity - Alarm identification In my view, human operators need a short text message telling as much as possible about the source of the alarm. Let me try to be very concrete in this mail so that it's clear what we're trying to change. We want to add a dynamic textual string to the outbound generic alarmRaise notifications. 1. We need model table information, which gives generic information about the alarm. We can either change the indices to accessible-for-notify or send alarmModelDescription. accessible-for-notify seems reasonable to me. 2. We need a pointer the resource raising the alarm. We can have the relatively limited way of doing that as is done now or use an OID. I'll send separate mail on this. 3. We need a dynamic string specific to the alarm that is intended for consumption by the human operator To get (1), we should probably use alarmModelDescription with its static nature. Nothing else is from that table is reasonable. If we want to send the indices, we have to change the MAX-ACCESS to accessible-for-notify To get (2), we should use an OID rather than the current scheme of two integers. That means replacing alarmActiveResourceType and alarmActiveResourceId with alarmActiveResourceOID, which is a pointer to the appropriate resource. To get (3), we should add an object called alarmActiveDynamicDescription with a definition something like: alarmActiveDynamicDescription OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION "This object provides a textual description of the active alarm. This text is generated dynamically by the notification generator to provide useful information to the human operator. This information SHOULD provide information allowing the operator to locate the resource for which this alarm is being generated. This information is not intended for consumption by automated tools." ::= { alarmActiveEntry xxxx } The alarmRaise would then look like this: alarmRaise NOTIFICATION-TYPE OBJECTS { alarmModelIndex, -- now a-f-notify alarmModelState, -- now a-f-notify alarmActiveResourceOID, -- or 2 ints as done now alarmActiveDynamicDescription } STATUS current DESCRIPTION "An instance of the alarm indicated by alarmModelIndex has been raised against the entity indicated by alarmActiveResourceOID. alarmActiveDynamicDescription provides information that can be displayed for the human operator. When a device detects a fault, it shall dynamically generate a text message containing dynamic information, dependancies on other states, etc." ::= { alarmNotifications 1 } > Am I mistaken, or do you suggest a third way to do it - not only have > the agent send clear readable text, but even define the text as part of > the standard? No, not at all. The text should be generated dynamically by the agent. But to be absolutely clear: we should absolutely NOT replace the objects that are useful for tools with text strings. Automated tools shouldn't have to parse text strings to get the information they need. When I'm done with changes, I'll send a pointer to a diff that shows exactly what I've changed. The group can then choose to junk it or not... Cheers, dlp -------------------Context is below-------------------------------- > > -----Original Message----- > > From: David L. Partain [mailto:partain@cs.utk.edu] > > Sent: Thursday, January 17, 2002 7:06 PM > > To: Sharon Chisholm; disman@dorothy.bmc.com; Stefan Wallin > > Subject: Re: disman alarm mib comments > > > > > > Greetings, > > > > I don't believe I have seen an answer to some of the issues > > herein, so I'll give it my 2 eurocents. I've cut out lots of > > things that I think have been discussed elsewhere. I hope I > > haven't whacked too zealously. > > > > > > > > But again, traps are displayed in real-time > > > for end-users and it is critical for them to quickly > > > > identify the resource. > > > > > Example: an ifIndex does not tell the typical alarm > > > > operator that much... > > > > > The alarm should say: "Slot 1, port 17, link is down > > > > administratively." > > > > > My recommendation is that the user-friendly var-bind above has this > > > information > > > embedded. > > > > > > > > > I disagree that this should be done in the agent, > > > > And I agree with Stefan that it should. The point is that > > there are going to be many settings where a human operator is > > sitting in front of a screen watching incoming alarms. Not the > > job I want, but there are people that do this. What Stefan is > > suggesting, and I think it makes great sense, is that the agent > > indeed include some reasonable text string that can be shown to > > this human operator _immediately_ upon receipt of the alarm. > > Whether this is the best way to manage networks or not is > > of course debatable, but there is no question that there are > > definitely users of this technology who would benefit from this. > > > > > especially if it ends up being done somewhere like a text > > > string. The result of this approach can be seen with fields such > > > as ifName and ifDescription. No agent gives either consistent > > > information or consistent format. > > > > That certainly is true, but it doesn't really change the fact > > that this would be useful in many cases. I guarantee that if we > > build boxes that put silliness into such a text string, we'll > > hear about it very quickly from our customers. > > > > > I've even seen systems where > > > it isn't even consistent for its different ifTypes. My approach > > > is that base information should be given in a consistent, hard > > > to mess up format such as an integer, and the manager does the > > > mapping to get physical components or other information it needs > > > and then displays it in a nice consistent format to the user. In > > > my experience, this is the only way this sort of thing works. > > > > I obviously cannot argue with your experience. I can, though, > > make a case for the fact that our customers are definitely going > > to want to have something easily displayable when an alarm > > arrives at the manager. The text string would allow this to > > happen. From owner-disman@dorothy.bmc.com Mon Jan 21 07:49:24 2002 Received: from babbler.bmc.com (firebird.bmc.com [198.207.223.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07547 for ; Mon, 21 Jan 2002 07:49:23 -0500 (EST) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g0LCphB02095; Mon, 21 Jan 2002 06:51:43 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id EAA27265 for disman-list; Mon, 21 Jan 2002 04:46:33 -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 EAA27259 for ; Mon, 21 Jan 2002 04:46:26 -0800 (PST) Received: from mx-us-hou-1-int.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id g0LCj4I03390 for ; Mon, 21 Jan 2002 06:45:04 -0600 (CST) Received: from albatross.wise.edt.ericsson.se (unknown [194.237.142.116]) by mx-us-hou-1-int.bmc.com (Postfix) with SMTP id A97C720F0B0 for ; Mon, 21 Jan 2002 12:34:49 -0600 (CST) Received: from mbb5.ericsson.se (mbb5.ericsson.se [136.225.151.210]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g0LCljIB018267 for ; Mon, 21 Jan 2002 13:47:46 +0100 (MET) Received: from there (lm6068.lmera.ericsson.se [150.132.106.68]) by mbb1.ericsson.se (PMDF V5.2-29 #39352) with SMTP id <0GQA00M1QGVKV4@mbb1.ericsson.se> for disman@dorothy.bmc.com; Mon, 21 Jan 2002 13:47:45 +0100 (MET) Date: Mon, 21 Jan 2002 13:48:01 +0100 From: David Partain Subject: Re: ResourceType & ResourceId In-reply-to: <200112181704.fBIH4Wm24149@haerke.ibr.cs.tu-bs.de> To: Juergen Schoenwaelder , schishol@nortelnetworks.com Cc: disman@dorothy.bmc.com Reply-To: David.Partain@ericsson.com Message-id: <0GQA00M1RGVLV4@mbb1.ericsson.se> MIME-version: 1.0 X-Mailer: KMail [version 1.3.2] Content-type: text/plain; charset=iso-8859-1 References: <3549C09B853DD5119B540002A52CDD3401267E1F@zcard0ka.ca.nortel.com> <200112181704.fBIH4Wm24149@haerke.ibr.cs.tu-bs.de> X-MIME-Autoconverted: from 8bit to quoted-printable by albatross.wise.edt.ericsson.se id g0LCljIB018267 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by dorothy.bmc.com id EAA27261 Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list Content-Transfer-Encoding: 8bit Hi, Regarding use of ResourceType/ResourceId versus using an OID, Jürgen wrote: > We obviously both fail to convince each other of the right solution. > So instead of trying one more time to convince you, I just recognize > that we to disagree on this issue. > > I would be helpful if other folks on this list could share their > thoughts with us. I've only just recently started looking at this document seriously. I completely agree with Jürgen that naming of resources with two integers, one of which is an enumeration and the other an index into a singly-indexed table (correct me if I'm wrong), is very limiting. It disallows pointing at enterprise specific stuff. It disallows pointing at things that are not covered by the enumeration (other doesn't count :-)). I would MUCH prefer to have a OID and I don't believe that it's much more complicated. Cheers, -- David Partain David.Partain@ericsson.com Ericsson Research's LinLab Tel: +46 13 28 41 44 P.O. Box 1248 Fax: +46 13 28 75 67 SE-581 12 Linköping, Sweden #include From owner-disman@dorothy.bmc.com Mon Jan 21 08:03:21 2002 Received: from babbler.bmc.com (camaro.bmc.com [198.207.223.231]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07884 for ; Mon, 21 Jan 2002 08:03:20 -0500 (EST) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g0LD5eB03344; Mon, 21 Jan 2002 07:05:40 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id FAA27336 for disman-list; Mon, 21 Jan 2002 05:00:30 -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 FAA27331 for ; Mon, 21 Jan 2002 05:00:23 -0800 (PST) Received: from mx-us-hou-2-int.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id g0LCx1v06117 for ; Mon, 21 Jan 2002 06:59:02 -0600 (CST) Received: from watcher.dataductus.se (mail.dataductus.se [213.199.99.201]) by mx-us-hou-2-int.bmc.com (Postfix) with SMTP id E368A1FF0BF for ; Mon, 21 Jan 2002 12:50:14 -0600 (CST) Received: (qmail 8138 invoked from network); 21 Jan 2002 13:01:24 -0000 Received: from nsmail.dataductus.se (192.168.100.43) by 0 with SMTP; 21 Jan 2002 13:01:24 -0000 Received: from dataductus.com ([192.168.100.240]) by nsmail.dataductus.se (Netscape Messaging Server 4.15) with SMTP id GQAHIH00.T3E; Mon, 21 Jan 2002 14:01:29 +0100 From: "Stefan Wallin" To: , "Juergen Schoenwaelder" , Cc: Subject: SV: ResourceType & ResourceId Date: Mon, 21 Jan 2002 14:01:04 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-reply-to: <0GQA00M1RGVLV4@mbb1.ericsson.se> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list Content-Transfer-Encoding: 8bit Hi! It is of vital importance to pinpoint the alarming object. Alarm management applications typically have a data dictionary based on MIB compilation. If we send OIDs as resource identification the alarm management app can perform a look-up in the dictionary in order to identify the resource. If we go for integers we have to manually implement the translation from integer value to OID in the manager, this is too much manual work and more seriously; error prone. My agent might refer to a camera as an integer but since it is not an OID another manager interprets as an ifIndex :( So OIDs instead of integers would help us: - support automation - avoid errors cheers Stefan -----Ursprungligt meddelande----- Från: owner-disman@dorothy.bmc.com [mailto:owner-disman@dorothy.bmc.com]För David Partain Skickat: den 21 januari 2002 13:48 Till: Juergen Schoenwaelder; schishol@nortelnetworks.com Kopia: disman@dorothy.bmc.com Ämne: Re: ResourceType & ResourceId Hi, Regarding use of ResourceType/ResourceId versus using an OID, Jürgen wrote: > We obviously both fail to convince each other of the right solution. > So instead of trying one more time to convince you, I just recognize > that we to disagree on this issue. > > I would be helpful if other folks on this list could share their > thoughts with us. I've only just recently started looking at this document seriously. I completely agree with Jürgen that naming of resources with two integers, one of which is an enumeration and the other an index into a singly-indexed table (correct me if I'm wrong), is very limiting. It disallows pointing at enterprise specific stuff. It disallows pointing at things that are not covered by the enumeration (other doesn't count :-)). I would MUCH prefer to have a OID and I don't believe that it's much more complicated. Cheers, -- David Partain David.Partain@ericsson.com Ericsson Research's LinLab Tel: +46 13 28 41 44 P.O. Box 1248 Fax: +46 13 28 75 67 SE-581 12 Linköping, Sweden #include From owner-disman@dorothy.bmc.com Mon Jan 21 08:05:40 2002 Received: from babbler.bmc.com (camaro.bmc.com [198.207.223.231]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07936 for ; Mon, 21 Jan 2002 08:05:40 -0500 (EST) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g0LD80n03559; Mon, 21 Jan 2002 07:08:00 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id FAA27348 for disman-list; Mon, 21 Jan 2002 05:02: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 FAA27343 for ; Mon, 21 Jan 2002 05:02:47 -0800 (PST) Received: from mx-us-hou-1-int.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id g0LD1Pp06824 for ; Mon, 21 Jan 2002 07:01:25 -0600 (CST) Received: from zcars0m9.ca.nortel.com (unknown [47.129.242.157]) by mx-us-hou-1-int.bmc.com (Postfix) with SMTP id DD0BA20F061 for ; Mon, 21 Jan 2002 12:50:38 -0600 (CST) Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57]) by zcars0m9.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g0LD3Xd14566; Mon, 21 Jan 2002 08:03:34 -0500 (EST) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g0LD3Wa05238; Mon, 21 Jan 2002 08:03:32 -0500 (EST) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 21 Jan 2002 08:03:33 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD3401766BF8@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: DISMAN Mailing List , David.Partain@ericsson.com Subject: RE: dynamic text string in alarms (was Re: disman alarm mib comme nts) Date: Mon, 21 Jan 2002 08:03:31 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list hi I agree that simple managers have different requirements than more complicated ones and that it is worth noting the differences. What I'm wondering though, is if managers that are so simple that they can only display the content of the trap, and preferably in a zero-processing format like display strings, are they actually smart enough to do alarm management? Are these simple managers able to process alarm set/raise and clear to maintain proper alarm state? I'm trying to think back to all the notification and alarm handling systems I've seen. I can't remember any that were really simple, but still able to handle alarms. Are there such systems? Also, Is it possible to create such a system? Keep in mind that alarms are cleared on a per-instance basis. This means that the manager needs to know that the alarm clear notification relates specifically to the alarm and resource specified in the alarm set/raise notification. Are these managers using the displayString to match the resources? Sharon -----Original Message----- From: David Partain [mailto:David.Partain@ericsson.com] Sent: Monday, January 21, 2002 7:24 AM To: DISMAN Mailing List Subject: dynamic text string in alarms (was Re: disman alarm mib comments) From owner-disman@dorothy.bmc.com Mon Jan 21 08:13:52 2002 Received: from babbler.bmc.com (firebird.bmc.com [198.207.223.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08206 for ; Mon, 21 Jan 2002 08:13:52 -0500 (EST) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g0LDGCG04363; Mon, 21 Jan 2002 07:16:12 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id FAA27377 for disman-list; Mon, 21 Jan 2002 05:11: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 FAA27370 for ; Mon, 21 Jan 2002 05:10:59 -0800 (PST) Received: from mx-us-hou-2-int.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id g0LD9au08255 for ; Mon, 21 Jan 2002 07:09:36 -0600 (CST) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by mx-us-hou-2-int.bmc.com (Postfix) with SMTP id CEBC31FF027 for ; Mon, 21 Jan 2002 13:00:49 -0600 (CST) Received: from mbb5.ericsson.se (mbb5.ericsson.se [136.225.151.210]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id g0LDC7w06739 for ; Mon, 21 Jan 2002 14:12:07 +0100 (MET) Received: from there (lm6068.lmera.ericsson.se [150.132.106.68]) by mbb1.ericsson.se (PMDF V5.2-29 #39352) with SMTP id <0GQA00O1EI05KA@mbb1.ericsson.se> for disman@dorothy.bmc.com; Mon, 21 Jan 2002 14:12:07 +0100 (MET) Date: Mon, 21 Jan 2002 14:12:22 +0100 From: David Partain Subject: Shared indices between Active and Clear alarm tables in ALARM-MIB To: DISMAN Mailing List Reply-To: David.Partain@ericsson.com Message-id: <0GQA00O1FI07KA@mbb1.ericsson.se> MIME-version: 1.0 X-Mailer: KMail [version 1.3.2] Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8bit Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list Content-Transfer-Encoding: 8bit Hi all, Again, after several rounds of e-mail with Stefan, I have another question. Part of this is based on Stefan's gang trying to build a manager application based on the current draft and finding indexing to be odd. There is a table with active alarms: alarmActiveEntry OBJECT-TYPE SYNTAX AlarmActiveEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Entries appear in this table when alarms are raised. They are removed when the alarm is cleared." INDEX { alarmListName, alarmActiveDateAndTime, alarmActiveIndex } ::= { alarmActiveTable 1 } and there is a table with cleared alarms: alarmClearEntry OBJECT-TYPE SYNTAX AlarmClearEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information on a cleared alarm." INDEX { alarmListName, alarmClearDateAndTime, alarmActiveIndex } Note the shared index of alarmActiveIndex, which is a column of alarmActiveTable. When an alarm clears, it is removed from the alarmActiveTable and an entry is created in alarmClearTable. It seems _very_ odd that you can use alarmActiveIndex from a row that in the alarmActiveTable that no longer exists. A manager cannot use this information to find out anything in the alarmActiveTable, so why the shared index? Shouldn't it just be its own index (i.e., alarmClearIndex)? There's nothing saying that you cannot statute that its value must be the same as the alarmActiveIndex corresponding to the cleared alarm. If I'm just being stupid, I'm sure someone will point this out :-) Cheers, dlp From owner-disman@dorothy.bmc.com Mon Jan 21 08:18:34 2002 Received: from babbler.bmc.com (camaro.bmc.com [198.207.223.231]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08451 for ; Mon, 21 Jan 2002 08:18:33 -0500 (EST) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g0LDKrx04775; Mon, 21 Jan 2002 07:20:54 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id FAA27391 for disman-list; Mon, 21 Jan 2002 05:15: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 FAA27386 for ; Mon, 21 Jan 2002 05:15:42 -0800 (PST) Received: from mx-us-hou-1-int.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id g0LDEKE09216 for ; Mon, 21 Jan 2002 07:14:20 -0600 (CST) Received: from penguin-ext.wise.edt.ericsson.se (unknown [194.237.142.110]) by mx-us-hou-1-int.bmc.com (Postfix) with SMTP id 0F4C320F05A for ; Mon, 21 Jan 2002 13:04:06 -0600 (CST) Received: from mbb5.ericsson.se (mbb5.ericsson.se [136.225.151.210]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id g0LDH2w12083 for ; Mon, 21 Jan 2002 14:17:02 +0100 (MET) Received: from there (lm6068.lmera.ericsson.se [150.132.106.68]) by mbb1.ericsson.se (PMDF V5.2-29 #39352) with SMTP id <0GQA00O6UI8DKA@mbb1.ericsson.se> for disman@dorothy.bmc.com; Mon, 21 Jan 2002 14:17:02 +0100 (MET) Date: Mon, 21 Jan 2002 14:17:18 +0100 From: David Partain Subject: Re: dynamic text string in alarms (was Re: disman alarm mib comme nts) In-reply-to: <3549C09B853DD5119B540002A52CDD3401766BF8@zcard0ka.ca.nortel.com> To: DISMAN Mailing List Reply-To: David.Partain@ericsson.com Message-id: <0GQA00O6VI8EKA@mbb1.ericsson.se> MIME-version: 1.0 X-Mailer: KMail [version 1.3.2] Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8bit References: <3549C09B853DD5119B540002A52CDD3401766BF8@zcard0ka.ca.nortel.com> Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list Content-Transfer-Encoding: 8bit Hi, Sharon wrote: > I agree that simple managers The "simple manager" is a person. > have different requirements > than more complicated ones and that it is worth noting > the differences. What I'm wondering though, is if managers > that are so simple that they can only display the content > of the trap, and preferably in a zero-processing format > like display strings, are they actually smart enough to > do alarm management? Are these simple managers able to > process alarm set/raise and clear to maintain proper > alarm state? > > I'm trying to think back to all the notification and > alarm handling systems I've seen. I can't remember > any that were really simple, but still able to handle > alarms. Are there such systems? > > Also, Is it possible to create such a system? Keep in > mind that alarms are cleared on a per-instance basis. > This means that the manager needs to know that the > alarm clear notification relates specifically to > the alarm and resource specified in the alarm set/raise > notification. Are these managers using the displayString > to match the resources? Again, the text string is not for application or machine consumption. It's for a human sitting in front of a screen. Even if it's not my job of choice, there are people who do just that - sit in front of a machine watching incoming alarms and reacting as a human would. The applications and alarm processing require the other stuff that's already there. The text string is complementary information, not a replacement. Cheers, dlp From owner-disman@dorothy.bmc.com Mon Jan 21 08:32:50 2002 Received: from babbler.bmc.com (firebird.bmc.com [198.207.223.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09075 for ; Mon, 21 Jan 2002 08:32:50 -0500 (EST) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g0LDZA506583; Mon, 21 Jan 2002 07:35:10 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id FAA27432 for disman-list; Mon, 21 Jan 2002 05:29:50 -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 FAA27426 for ; Mon, 21 Jan 2002 05:29:45 -0800 (PST) Received: from mx-us-hou-1-int.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id g0LDSNQ12220 for ; Mon, 21 Jan 2002 07:28:23 -0600 (CST) Received: from penguin-ext.wise.edt.ericsson.se (unknown [194.237.142.110]) by mx-us-hou-1-int.bmc.com (Postfix) with SMTP id 968B620F068 for ; Mon, 21 Jan 2002 13:18:03 -0600 (CST) Received: from mbb5.ericsson.se (mbb5.ericsson.se [136.225.151.210]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id g0LDUxw26801 for ; Mon, 21 Jan 2002 14:31:00 +0100 (MET) Received: from there (lm6068.lmera.ericsson.se [150.132.106.68]) by mbb1.ericsson.se (PMDF V5.2-29 #39352) with SMTP id <0GQA0019XIVLFG@mbb1.ericsson.se> for disman@dorothy.bmc.com; Mon, 21 Jan 2002 14:30:59 +0100 (MET) Date: Mon, 21 Jan 2002 14:31:14 +0100 From: David Partain Subject: ALARM-MIB shared indices and row pointers for alarmModelEntry & ituAlarmEntry To: DISMAN Mailing List Reply-To: David.Partain@ericsson.com Message-id: <0GQA0019YIVMFG@mbb1.ericsson.se> MIME-version: 1.0 X-Mailer: KMail [version 1.3.2] Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8bit Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list Content-Transfer-Encoding: 8bit Hi all, In looking at the indexing and the various RowPointers in the ALARM-MIB, my brain started hurting. I realize that may be based on its capacity... In any case, the alarmModelEntry has: ->Indices: 1: alarmListName 2: alarmModelIndex 3: alarmModelState and alarmModelSpecificPointer, a RowPointer which might be a pointer to an ituAlarmEntry Then we have the ituAlarmEntry, which has: ->Indices 1: alarmListName (shared) 2: alarmModelIndex (shared) 3: ituAlarmPerceivedSeverity and that in turn has ituAlarmGenericModel, a RowPointer to the "corresponding row in the alarmModelTable." So, we not only have shared indices, we also have circular RowPointers. Why do we need the pointer from the ituAlarmTable back to the alarmModelTable? I suggest that ituAlarmGenericModel be removed. Why? 1) In general: maintaining references pointing both ways in an agent system is tricky 2) It is not needed, since a manager should start in the base table alarmModelEntry and follow the pointers to specific tables, not the opposite 3) Fewer OID columns in table retrieval Cheers, dlp From owner-disman@dorothy.bmc.com Mon Jan 21 08:58:04 2002 Received: from babbler.bmc.com (camaro.bmc.com [198.207.223.231]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09868 for ; Mon, 21 Jan 2002 08:58:03 -0500 (EST) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g0LE0NO09033; Mon, 21 Jan 2002 08:00:24 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id FAA27489 for disman-list; Mon, 21 Jan 2002 05:55:12 -0800 (PST) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id FAA27484 for ; Mon, 21 Jan 2002 05:55:09 -0800 (PST) Received: from mx-us-hou-1-int.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id g0LDrk717966 for ; Mon, 21 Jan 2002 07:53:46 -0600 (CST) Received: from zcars0m9.ca.nortel.com (unknown [47.129.242.157]) by mx-us-hou-1-int.bmc.com (Postfix) with SMTP id 4AB6620F055 for ; Mon, 21 Jan 2002 13:43:32 -0600 (CST) Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57]) by zcars0m9.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g0LDuRd03654; Mon, 21 Jan 2002 08:56:27 -0500 (EST) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g0LDuPa07886; Mon, 21 Jan 2002 08:56:25 -0500 (EST) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 21 Jan 2002 08:56:26 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD3401766CAE@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: DISMAN Mailing List , David.Partain@ericsson.com Subject: RE: dynamic text string in alarms (was Re: disman alarm mib comme nts) Date: Mon, 21 Jan 2002 08:56:24 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list hi Dave> Again, the text string is not for application or machine Dave> consumption. It's for a human sitting in front of a screen. Dave> Even if it's not my job of choice, there are people who do just Dave> that - sit in front of a machine watching incoming alarms and Dave> reacting as a human would. Ok. So this human is sitting in front of a simple manager that only displays raw notifications, as appose to one capable of producing meaningful messages? I don't think you are saying that the user is using the CLI. I think in this case we are not talking about the difference between humans and programs, but the complexity of the tools the human is using to view the alarms. You seem to be asking that the alarm notifications be meaningful in simple, notification-based systems? Is that the requirement? I realize you are asking for support of this in addition to something better suited for programs, but I'm trying to better understand the requirement. Sharon From owner-disman@dorothy.bmc.com Mon Jan 21 09:08:13 2002 Received: from babbler.bmc.com (firebird.bmc.com [198.207.223.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10119 for ; Mon, 21 Jan 2002 09:08:12 -0500 (EST) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g0LEAWZ10157; Mon, 21 Jan 2002 08:10:32 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id GAA27516 for disman-list; Mon, 21 Jan 2002 06:05: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 GAA27511 for ; Mon, 21 Jan 2002 06:05:10 -0800 (PST) Received: from mx-us-hou-2-int.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id g0LE3mm20073 for ; Mon, 21 Jan 2002 08:03:48 -0600 (CST) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by mx-us-hou-2-int.bmc.com (Postfix) with SMTP id EAA301FF121 for ; Mon, 21 Jan 2002 13:55:01 -0600 (CST) Received: from mbb5.ericsson.se (mbb5.ericsson.se [136.225.151.210]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id g0LE6Kw07902 for ; Mon, 21 Jan 2002 15:06:20 +0100 (MET) Received: from there (lm6068.lmera.ericsson.se [150.132.106.68]) by mbb1.ericsson.se (PMDF V5.2-29 #39352) with SMTP id <0GQA0002PKIIRZ@mbb1.ericsson.se> for disman@dorothy.bmc.com; Mon, 21 Jan 2002 15:06:19 +0100 (MET) Date: Mon, 21 Jan 2002 15:06:35 +0100 From: David Partain Subject: Re: dynamic text string in alarms (was Re: disman alarm mib comme nts) In-reply-to: <3549C09B853DD5119B540002A52CDD3401766CAE@zcard0ka.ca.nortel.com> To: DISMAN Mailing List Reply-To: David.Partain@ericsson.com Message-id: <0GQA0002QKIJRZ@mbb1.ericsson.se> MIME-version: 1.0 X-Mailer: KMail [version 1.3.2] Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8bit References: <3549C09B853DD5119B540002A52CDD3401766CAE@zcard0ka.ca.nortel.com> Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list Content-Transfer-Encoding: 8bit Hi Sharon, Sharon wrote: > Dave> Again, the text string is not for application or machine > Dave> consumption. It's for a human sitting in front of a screen. > Dave> Even if it's not my job of choice, there are people who do just > Dave> that - sit in front of a machine watching incoming alarms and > Dave> reacting as a human would. > > Ok. So this human is sitting in front of a simple manager that only > displays raw notifications, as appose to one capable of producing > meaningful messages? I guess it is somewhat analogous to doing tail -25f /var/adm/messages on some machines. It's not very interesting, but there are going to be people who do it and it's sometimes the fastest way to know something happened. > I don't think you are saying that the user > is using the CLI. You're correct. > I think in this case we are not talking about > the difference between humans and programs, but the complexity of > the tools the human is using to view the alarms. Perhaps that's true. I realize that the information may be available in other ways by doing various kinds of processing. This is just to short-circuit that. Get it on the screen -- fast. > You seem to be asking > that the alarm notifications be meaningful in simple, notification-based > systems? Is that the requirement? I think so, yes. > I realize you are asking for support of this in addition to something > better suited for programs, but I'm trying to better understand > the requirement. Thanks. I think you understand what I'm after. Cheers, dlp From owner-disman@dorothy.bmc.com Mon Jan 21 09:41:39 2002 Received: from babbler.bmc.com (camaro.bmc.com [198.207.223.231]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10837 for ; Mon, 21 Jan 2002 09:41:39 -0500 (EST) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g0LEhxS14471; Mon, 21 Jan 2002 08:43:59 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id GAA27586 for disman-list; Mon, 21 Jan 2002 06:38: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 GAA27581 for ; Mon, 21 Jan 2002 06:38:29 -0800 (PST) Received: from mx-us-hou-1-int.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id g0LEb7v29573 for ; Mon, 21 Jan 2002 08:37:07 -0600 (CST) Received: from albatross.wise.edt.ericsson.se (unknown [194.237.142.116]) by mx-us-hou-1-int.bmc.com (Postfix) with SMTP id 685E720EFDE for ; Mon, 21 Jan 2002 14:26:52 -0600 (CST) Received: from mbb5.ericsson.se (mbb5.ericsson.se [136.225.151.210]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g0LEdnIB004221 for ; Mon, 21 Jan 2002 15:39:49 +0100 (MET) Received: from there (lm6068.lmera.ericsson.se [150.132.106.68]) by mbb1.ericsson.se (PMDF V5.2-29 #39352) with SMTP id <0GQA008HMM2BDH@mbb1.ericsson.se> for disman@dorothy.bmc.com; Mon, 21 Jan 2002 15:39:49 +0100 (MET) Date: Mon, 21 Jan 2002 15:40:04 +0100 From: David Partain Subject: a question about alarmModelVarbindIndex To: DISMAN Mailing List Reply-To: David.Partain@ericsson.com Message-id: <0GQA008HPM2DDH@mbb1.ericsson.se> MIME-version: 1.0 X-Mailer: KMail [version 1.3.2] Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8bit Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list Content-Transfer-Encoding: 8bit Hi, I'm confused about what to do with alarmModelVarbindIndex. If I'm sending an SNMPv2c or SNMPv3 notification, there are two "built-in" varbinds (sysUpTime.0 and snmpTrapOID.0). If you're sending an SNMPv1 trap, that's not the case. What value does alarmModelVarbindIndex have to point to ifIndex in a linkDown trap? Should it be 1 or 3? In the examples in the current alarm MIB, it is 2. I don't understand that. It looks like (1) I don't understand the semantics of alarmModelVarbindIndex and it's not just an index into the incoming varbind list or (2) we're starting to count at 0 and assuming v2c/v3 notifications. Can someone help me understand? Cheers, dlp From owner-disman@dorothy.bmc.com Mon Jan 21 10:59:53 2002 Received: from babbler.bmc.com (firebird.bmc.com [198.207.223.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13601 for ; Mon, 21 Jan 2002 10:59:53 -0500 (EST) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g0LG2DO26739; Mon, 21 Jan 2002 10:02:13 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id HAA27734 for disman-list; Mon, 21 Jan 2002 07:56:42 -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 HAA27729 for ; Mon, 21 Jan 2002 07:56:38 -0800 (PST) Received: from mx-us-hou-1-int.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id g0LFtHa23051 for ; Mon, 21 Jan 2002 09:55:17 -0600 (CST) Received: from rwcrmhc51.attbi.com (unknown [204.127.198.38]) by mx-us-hou-1-int.bmc.com (Postfix) with SMTP id D57AC20EFE2 for ; Mon, 21 Jan 2002 15:45:01 -0600 (CST) Received: from dperkins-nb2.dsperkins.com ([12.234.130.131]) by rwcrmhc51.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020121155803.JPTO26243.rwcrmhc51.attbi.com@dperkins-nb2.dsperkins.com>; Mon, 21 Jan 2002 15:58:03 +0000 Message-Id: <5.0.2.1.2.20020121073130.02c1e670@mail4.bayarea.net> X-Sender: dperkins@mail4.bayarea.net X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Mon, 21 Jan 2002 07:48:23 -0800 To: David.Partain@ericsson.com, DISMAN Mailing List From: "David T. Perkins" Subject: Re: dynamic text string in alarms (was Re: disman alarm mib comme nts) In-Reply-To: <0GQA0002QKIJRZ@mbb1.ericsson.se> References: <3549C09B853DD5119B540002A52CDD3401766CAE@zcard0ka.ca.nortel.com> <3549C09B853DD5119B540002A52CDD3401766CAE@zcard0ka.ca.nortel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list HI, While I understand that there are organizations that don't support their employees with usable tools, catering to them is something that I don't support. If the model is that the only tool that is available is the basic notification receiver that uses MIB information to translate the OIDs that identify OIDs variables in the varBind list to text, and writes these and associated values to a file, then I say, get some tools that are not 10+ years old. At minimum, you need to move away from MIB tools that only do OID to "descriptor" translation, and upgrade to ones that know how to decode index values of variables. Any tool has at minimal got to be custom written to efficiently monitor the "alarm logs" so that it can efficiently manage the alarm state of the device. Has the team that you are working with ever written a sophisticated alarm management (and device state management) system before? Do they have members with previous SNMP experience? Does the team have a model for alarms? If so, what is it? Does it match the alarm model specified in the documents? Does the team you are working with understand the difference between events and alarms? Do they understand the difference between alarms based on "standing conditions" and "incidence conditions"? This area of "network management" is difficult due to the conflicting requirements, terminology, and models. I wish the best for the team because it is truly difficult to do a good engineering job unless you have a big budget and an engineering team with the right mix of skills and experience. At 03:06 PM 1/21/2002 +0100, David Partain wrote: >Hi Sharon, > >Sharon wrote: > >> Dave> Again, the text string is not for application or machine >> Dave> consumption. It's for a human sitting in front of a screen. >> Dave> Even if it's not my job of choice, there are people who do just >> Dave> that - sit in front of a machine watching incoming alarms and >> Dave> reacting as a human would. >> >> Ok. So this human is sitting in front of a simple manager that only >> displays raw notifications, as appose to one capable of producing >> meaningful messages? > >I guess it is somewhat analogous to doing > > tail -25f /var/adm/messages > >on some machines. It's not very interesting, but there are >going to be people who do it and it's sometimes the fastest >way to know something happened. > >> I don't think you are saying that the user >> is using the CLI. > >You're correct. > >> I think in this case we are not talking about >> the difference between humans and programs, but the complexity of >> the tools the human is using to view the alarms. > >Perhaps that's true. I realize that the information may be >available in other ways by doing various kinds of processing. >This is just to short-circuit that. > >Get it on the screen -- fast. > >> You seem to be asking >> that the alarm notifications be meaningful in simple, notification-based >> systems? Is that the requirement? > >I think so, yes. > >> I realize you are asking for support of this in addition to something >> better suited for programs, but I'm trying to better understand >> the requirement. > >Thanks. I think you understand what I'm after. > >Cheers, > >dlp Regards, /david t. perkins From owner-disman@dorothy.bmc.com Mon Jan 21 11:08:34 2002 Received: from babbler.bmc.com (camaro.bmc.com [198.207.223.231]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14229 for ; Mon, 21 Jan 2002 11:08:33 -0500 (EST) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g0LGAsW28435; Mon, 21 Jan 2002 10:10:54 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id IAA27755 for disman-list; Mon, 21 Jan 2002 08:05: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 IAA27750 for ; Mon, 21 Jan 2002 08:05:44 -0800 (PST) Received: from mx-us-hou-1-int.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id g0LG4LO25669 for ; Mon, 21 Jan 2002 10:04:22 -0600 (CST) Received: from rwcrmhc51.attbi.com (unknown [204.127.198.38]) by mx-us-hou-1-int.bmc.com (Postfix) with SMTP id D265320F05D for ; Mon, 21 Jan 2002 15:54:06 -0600 (CST) Received: from dperkins-nb2.dsperkins.com ([12.234.130.131]) by rwcrmhc51.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020121160708.JVLA26243.rwcrmhc51.attbi.com@dperkins-nb2.dsperkins.com>; Mon, 21 Jan 2002 16:07:08 +0000 Message-Id: <5.0.2.1.2.20020121080127.026ab2f0@mail4.bayarea.net> X-Sender: dperkins@mail4.bayarea.net X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Mon, 21 Jan 2002 08:06:41 -0800 To: David.Partain@ericsson.com, DISMAN Mailing List From: "David T. Perkins" Subject: Re: a question about alarmModelVarbindIndex In-Reply-To: <0GQA008HPM2DDH@mbb1.ericsson.se> 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, To deal with the differences between the format of v1Traps and v2Traps and Informs, I suggest that the software simply translates the v1Traps (using the standard rules in RFC 2576) into the standard form. Many management packages already do this. At 03:40 PM 1/21/2002 +0100, David Partain wrote: >Hi, > >I'm confused about what to do with alarmModelVarbindIndex. > >If I'm sending an SNMPv2c or SNMPv3 notification, there are >two "built-in" varbinds (sysUpTime.0 and snmpTrapOID.0). >If you're sending an SNMPv1 trap, that's not the case. > >What value does alarmModelVarbindIndex have to point to ifIndex >in a linkDown trap? Should it be 1 or 3? In the examples in >the current alarm MIB, it is 2. I don't understand that. > >It looks like (1) I don't understand the semantics of >alarmModelVarbindIndex and it's not just an index into the >incoming varbind list or (2) we're starting to count at 0 and >assuming v2c/v3 notifications. > >Can someone help me understand? > >Cheers, > >dlp Regards, /david t. perkins From owner-disman@dorothy.bmc.com Mon Jan 21 11:15:49 2002 Received: from babbler.bmc.com (firebird.bmc.com [198.207.223.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14570 for ; Mon, 21 Jan 2002 11:15:49 -0500 (EST) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g0LGIAK29921; Mon, 21 Jan 2002 10:18:10 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id IAA27783 for disman-list; Mon, 21 Jan 2002 08:13:02 -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 IAA27776 for ; Mon, 21 Jan 2002 08:12:57 -0800 (PST) Received: from mx-us-hou-2-int.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id g0LGBZb27916 for ; Mon, 21 Jan 2002 10:11:35 -0600 (CST) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by mx-us-hou-2-int.bmc.com (Postfix) with SMTP id 08D5E1FF0C1 for ; Mon, 21 Jan 2002 16:02:43 -0600 (CST) Received: from mbb5.ericsson.se (mbb5.ericsson.se [136.225.151.210]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id g0LGE2w19783 for ; Mon, 21 Jan 2002 17:14:02 +0100 (MET) Received: from there (lm6068.lmera.ericsson.se [150.132.106.68]) by mbb1.ericsson.se (PMDF V5.2-29 #39352) with SMTP id <0GQA0072LQFCR5@mbb1.ericsson.se> for disman@dorothy.bmc.com; Mon, 21 Jan 2002 17:14:01 +0100 (MET) Date: Mon, 21 Jan 2002 17:14:17 +0100 From: David Partain Subject: Re: a question about alarmModelVarbindIndex In-reply-to: <5.0.2.1.2.20020121080127.026ab2f0@mail4.bayarea.net> To: DISMAN Mailing List Reply-To: David.Partain@ericsson.com Message-id: <0GQA0072MQFDR5@mbb1.ericsson.se> MIME-version: 1.0 X-Mailer: KMail [version 1.3.2] Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8bit References: <5.0.2.1.2.20020121080127.026ab2f0@mail4.bayarea.net> Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list Content-Transfer-Encoding: 8bit Hi, On Monday 21 January 2002 17:06, David T. Perkins wrote: > To deal with the differences between the format of v1Traps and > v2Traps and Informs, I suggest that the software simply translates > the v1Traps (using the standard rules in RFC 2576) into the standard form. > Many management packages already do this. That'd be great. I just can't make sense of what's in the document at the moment and would like to understand the intention. I'd be perfectly happy with this resolution. If that's done, then what does a value of 1 for alarmModelVarbindIndex mean? sysUpTime.0? or whatever comes after snmpTrapOID.0? Or are we C programmers and counting from 0 so it's really the _second_ varbind after snmpTrapOID.0 (I sure hope not). I think a good answer is that 1 is the first varbind after snmpTrapOID.0 but that needs to be written somewhere. Cheers, dlp > At 03:40 PM 1/21/2002 +0100, David Partain wrote: > >Hi, > > > >I'm confused about what to do with alarmModelVarbindIndex. > > > >If I'm sending an SNMPv2c or SNMPv3 notification, there are > >two "built-in" varbinds (sysUpTime.0 and snmpTrapOID.0). > >If you're sending an SNMPv1 trap, that's not the case. > > > >What value does alarmModelVarbindIndex have to point to ifIndex > >in a linkDown trap? Should it be 1 or 3? In the examples in > >the current alarm MIB, it is 2. I don't understand that. > > > >It looks like (1) I don't understand the semantics of > >alarmModelVarbindIndex and it's not just an index into the > >incoming varbind list or (2) we're starting to count at 0 and > >assuming v2c/v3 notifications. > > > >Can someone help me understand? > > > >Cheers, > > > >dlp From owner-disman@dorothy.bmc.com Tue Jan 22 02:57:03 2002 Received: from babbler.bmc.com (firebird.bmc.com [198.207.223.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA13390 for ; Tue, 22 Jan 2002 02:57:03 -0500 (EST) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g0M7xL929141; Tue, 22 Jan 2002 01:59:21 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id XAA02612 for disman-list; Mon, 21 Jan 2002 23:52:22 -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 XAA02607 for ; Mon, 21 Jan 2002 23:52:16 -0800 (PST) Received: from mx-us-hou-1-int.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id g0M7os127439 for ; Tue, 22 Jan 2002 01:50:54 -0600 (CST) Received: from penguin-ext.wise.edt.ericsson.se (unknown [194.237.142.110]) by mx-us-hou-1-int.bmc.com (Postfix) with SMTP id 3454820F09F for ; Tue, 22 Jan 2002 07:40:34 -0600 (CST) Received: from mbb5.ericsson.se (mbb5.ericsson.se [136.225.151.210]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id g0M7raw06903 for ; Tue, 22 Jan 2002 08:53:36 +0100 (MET) Received: from there (lm6068.lmera.ericsson.se [150.132.106.68]) by mbb1.ericsson.se (PMDF V5.2-29 #39352) with SMTP id <0GQB00IGIXXA4R@mbb1.ericsson.se> for disman@dorothy.bmc.com; Tue, 22 Jan 2002 08:53:36 +0100 (MET) Date: Tue, 22 Jan 2002 08:53:54 +0100 From: David Partain Subject: Re: dynamic text string in alarms (was Re: disman alarm mib comme nts) In-reply-to: <5.0.2.1.2.20020121073130.02c1e670@mail4.bayarea.net> To: DISMAN Mailing List Reply-To: David.Partain@ericsson.com Message-id: <0GQB00IGJXXC4R@mbb1.ericsson.se> MIME-version: 1.0 X-Mailer: KMail [version 1.3.2] Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8bit References: <3549C09B853DD5119B540002A52CDD3401766CAE@zcard0ka.ca.nortel.com> <5.0.2.1.2.20020121073130.02c1e670@mail4.bayarea.net> Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list Content-Transfer-Encoding: 8bit Hi all, David Perkins wrote: > While I understand that there are organizations that don't support > their employees with usable tools, catering to them is something that > I don't support. I personally don't feel that I am in a position to dictate to customers how they should or should not do things. If people want to configure their boxes using a CLI, I provide the tools. If they want to use COPS, I use the tools. If they want to use SNMP, I provide the tools. If they want to see their traps immediately on the screen in a simplistic way, I provide the tools. If they want a "sophisticated alarm management system", I provide the tools. Whether the working group wants to "cater to them" or not, we'll certainly have to provide the tools. Besides, it's not about simple and stupid managers: - it is about intelligent agents - it is about information loss When an alarm state change occurs in the agent, information about the alarm state change and contextual information must be squeezed into the available objects in the notification. In many cases not all relevant information can be put into the typed information that is targeted at automated tools. After all expensive, automated, fancy alarm correlation, etc. in the alarm mgmt app, sometimes the user wants to see the details about a discrete event, and it is very hard for the mgmt app to infer/guess what really happened within the device if the device did not provide this info when it occurred. No information should get lost anywhere in the chain. Of course, there are other tools/ways to help solve this problem, but this is one way to do so. > If the model is that the only tool that is available is the basic > notification receiver that uses MIB information to translate the OIDs > that identify OIDs variables in the varBind list to text, and > writes these and associated values to a file, then I say, get > some tools that are not 10+ years old. > At minimum, you need to move away from MIB tools that only do > OID to "descriptor" translation, and upgrade to ones that know > how to decode index values of variables. > > Any tool has at minimal got to be custom written to efficiently monitor > the "alarm logs" so that it can efficiently manage the alarm state > of the device. > > Has the team that you are working with ever written a sophisticated > alarm management (and device state management) system before? Do they > have members with previous SNMP experience? Of course. I think it's safe to say that alarms are something that the telco world knows something about. I also think it's safe to say that my employer as well as its customers have built/used sophisticated alarm management systems for a long time. > Does the team have a model for alarms? If so, what is it? Does it > match the alarm model specified in the documents? > > Does the team you are working with understand the difference between > events and alarms? Do they understand the difference between alarms > based on "standing conditions" and "incidence conditions"? I'm asking for a readily-displayable text string _in addition to_ information needed for a "sophisticated alarm management system". Nothing more. I believe this will be useful. If the working group doesn't, that's fine, too. I'll certainly live through the experience. :-) I don't see how that somehow implies that someone doesn't "understand the difference between events and alarms" or doesn't "understand the difference between alarms based on 'standing conditions' and 'incidence conditions'". That seems a stretch. Cheers, dlp > This area of "network management" is difficult due to the > conflicting requirements, terminology, and models. I wish > the best for the team because it is truly difficult to > do a good engineering job unless you have a big budget and > an engineering team with the right mix of skills and > experience. > > At 03:06 PM 1/21/2002 +0100, David Partain wrote: > >Hi Sharon, > > > >Sharon wrote: > >> Dave> Again, the text string is not for application or machine > >> Dave> consumption. It's for a human sitting in front of a screen. > >> Dave> Even if it's not my job of choice, there are people who do just > >> Dave> that - sit in front of a machine watching incoming alarms and > >> Dave> reacting as a human would. > >> > >> Ok. So this human is sitting in front of a simple manager that only > >> displays raw notifications, as appose to one capable of producing > >> meaningful messages? > > > >I guess it is somewhat analogous to doing > > > > tail -25f /var/adm/messages > > > >on some machines. It's not very interesting, but there are > >going to be people who do it and it's sometimes the fastest > >way to know something happened. > > > >> I don't think you are saying that the user > >> is using the CLI. > > > >You're correct. > > > >> I think in this case we are not talking about > >> the difference between humans and programs, but the complexity of > >> the tools the human is using to view the alarms. > > > >Perhaps that's true. I realize that the information may be > >available in other ways by doing various kinds of processing. > >This is just to short-circuit that. > > > >Get it on the screen -- fast. > > > >> You seem to be asking > >> that the alarm notifications be meaningful in simple, notification-based > >> systems? Is that the requirement? > > > >I think so, yes. > > > >> I realize you are asking for support of this in addition to something > >> better suited for programs, but I'm trying to better understand > >> the requirement. > > > >Thanks. I think you understand what I'm after. > > > >Cheers, > > > >dlp > > Regards, > /david t. perkins From owner-disman@dorothy.bmc.com Tue Jan 22 07:53:58 2002 Received: from babbler.bmc.com (firebird.bmc.com [198.207.223.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16581 for ; Tue, 22 Jan 2002 07:53:57 -0500 (EST) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g0MCuGU26503; Tue, 22 Jan 2002 06:56:16 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id EAA14295 for disman-list; Tue, 22 Jan 2002 04:50:56 -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 EAA14290 for ; Tue, 22 Jan 2002 04:50:51 -0800 (PST) Received: from mx-us-hou-1-int.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id g0MCnSd01886 for ; Tue, 22 Jan 2002 06:49:28 -0600 (CST) Received: from zcars0m9.ca.nortel.com (unknown [47.129.242.157]) by mx-us-hou-1-int.bmc.com (Postfix) with SMTP id 7C69A20EFCA for ; Tue, 22 Jan 2002 12:39:07 -0600 (CST) Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57]) by zcars0m9.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g0MCqAS21719; Tue, 22 Jan 2002 07:52:10 -0500 (EST) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g0MCq5S24555; Tue, 22 Jan 2002 07:52:05 -0500 (EST) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 22 Jan 2002 07:52:05 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD34017DF15D@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: David.Partain@ericsson.com, DISMAN Mailing List Subject: RE: ALARM-MIB shared indices and row pointers for alarmModelEntry & ituAlarmEntry Date: Tue, 22 Jan 2002 07:52:04 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list hi The alarmGenericModel pointer was added after someone trying to implement the MIBs asked how you related back to the generic model in the case when the alarm state and the severity are not the same. True, this information could also be obtained by going back to the alarmModelTable and trying to find a matching alarmModelSpecificPointer. But, trying to relate different tables together is a very common management activity, so I thought an object that aided this was a good thing. Your first two arguments against it make sense, but the third argument assumes managers retrieve entire rows of data, which in my experience is not usually the case. Sharon -----Original Message----- From: David Partain [mailto:David.Partain@ericsson.com] Sent: Monday, January 21, 2002 8:31 AM To: DISMAN Mailing List Subject: ALARM-MIB shared indices and row pointers for alarmModelEntry & ituAlarmEntry Hi all, In looking at the indexing and the various RowPointers in the ALARM-MIB, my brain started hurting. I realize that may be based on its capacity... In any case, the alarmModelEntry has: ->Indices: 1: alarmListName 2: alarmModelIndex 3: alarmModelState and alarmModelSpecificPointer, a RowPointer which might be a pointer to an ituAlarmEntry Then we have the ituAlarmEntry, which has: ->Indices 1: alarmListName (shared) 2: alarmModelIndex (shared) 3: ituAlarmPerceivedSeverity and that in turn has ituAlarmGenericModel, a RowPointer to the "corresponding row in the alarmModelTable." So, we not only have shared indices, we also have circular RowPointers. Why do we need the pointer from the ituAlarmTable back to the alarmModelTable? I suggest that ituAlarmGenericModel be removed. Why? 1) In general: maintaining references pointing both ways in an agent system is tricky 2) It is not needed, since a manager should start in the base table alarmModelEntry and follow the pointers to specific tables, not the opposite 3) Fewer OID columns in table retrieval Cheers, dlp From owner-disman@dorothy.bmc.com Wed Jan 23 05:59:12 2002 Received: from babbler.bmc.com (firebird.bmc.com [198.207.223.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05354 for ; Wed, 23 Jan 2002 05:59:11 -0500 (EST) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g0NB1Rf05725; Wed, 23 Jan 2002 05:01:27 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id CAA01203 for disman-list; Wed, 23 Jan 2002 02:54:39 -0800 (PST) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id CAA01198 for ; Wed, 23 Jan 2002 02:54:33 -0800 (PST) Received: from mx-us-hou-2-int.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id g0NArB227228 for ; Wed, 23 Jan 2002 04:53:11 -0600 (CST) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by mx-us-hou-2-int.bmc.com (Postfix) with SMTP id EB9911FF0FA for ; Wed, 23 Jan 2002 10:44:15 -0600 (CST) Received: from mbb5.ericsson.se (mbb5.ericsson.se [136.225.151.210]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id g0NAthw19829 for ; Wed, 23 Jan 2002 11:55:44 +0100 (MET) Received: from there (lm6068.lmera.ericsson.se [150.132.106.68]) by mbb1.ericsson.se (PMDF V5.2-29 #39352) with SMTP id <0GQE00FKM10UZT@mbb1.ericsson.se> for disman@dorothy.bmc.com; Wed, 23 Jan 2002 11:55:43 +0100 (MET) Date: Wed, 23 Jan 2002 11:56:07 +0100 From: David Partain Subject: Re: ALARM-MIB shared indices and row pointers for alarmModelEntry & ituAlarmEntry In-reply-to: <3549C09B853DD5119B540002A52CDD34017DF15D@zcard0ka.ca.nortel.com> To: DISMAN Mailing List Reply-To: David.Partain@ericsson.com Message-id: <0GQE00FKN10VZT@mbb1.ericsson.se> MIME-version: 1.0 X-Mailer: KMail [version 1.3.2] Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8bit References: <3549C09B853DD5119B540002A52CDD34017DF15D@zcard0ka.ca.nortel.com> Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list Content-Transfer-Encoding: 8bit Hi Sharon, On Tuesday 22 January 2002 13:52, Sharon Chisholm wrote: > The alarmGenericModel pointer was added after > someone trying to implement the MIBs asked how > you related back to the generic model in the case > when the alarm state and the severity are not the > same. Ahhh.... I see. They don't share all the indices, they only share two of the three. Now I understand. Chalk this up to me not thinking about what I was asking before asking :-) Cheers, dlp From owner-disman@dorothy.bmc.com Wed Jan 23 12:19:06 2002 Received: from babbler.bmc.com (camaro.bmc.com [198.207.223.231]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16969 for ; Wed, 23 Jan 2002 12:19:01 -0500 (EST) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g0NHLLP00422; Wed, 23 Jan 2002 11:21:21 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id JAA02743 for disman-list; Wed, 23 Jan 2002 09:15:51 -0800 (PST) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id JAA02737 for disman@dorothy.bmc.com; Wed, 23 Jan 2002 09:15:47 -0800 (PST) Date: Wed, 23 Jan 2002 09:15:47 -0800 (PST) From: Randy Presuhn Message-Id: <200201231715.JAA02737@dorothy.bmc.com> To: disman@dorothy.bmc.com Subject: test, please ignore Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list Content-Transfer-Encoding: 7bit #1 From owner-disman@dorothy.bmc.com Fri Jan 25 09:48:51 2002 Received: from babbler.bmc.com (camaro.bmc.com [198.207.223.231]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04011 for ; Fri, 25 Jan 2002 09:48:51 -0500 (EST) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g0PEp4o00339; Fri, 25 Jan 2002 08:51:04 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id GAA02439 for disman-list; Fri, 25 Jan 2002 06:44:57 -0800 (PST) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id GAA02434 for ; Fri, 25 Jan 2002 06:44:52 -0800 (PST) Received: from mx-us-hou-2-int.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id g0PEhSM27886 for ; Fri, 25 Jan 2002 08:43:28 -0600 (CST) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by mx-us-hou-2-int.bmc.com (Postfix) with SMTP id 6138B1FF086 for ; Fri, 25 Jan 2002 14:34:23 -0600 (CST) Received: from mbb5.ericsson.se (mbb5.ericsson.se [136.225.151.210]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id g0PEk2106062 for ; Fri, 25 Jan 2002 15:46:02 +0100 (MET) Received: from there (lm6068.lmera.ericsson.se [150.132.106.68]) by mbb1.ericsson.se (PMDF V5.2-29 #39352) with SMTP id <0GQI005F110GVN@mbb1.ericsson.se> for disman@dorothy.bmc.com; Fri, 25 Jan 2002 15:45:53 +0100 (MET) Date: Fri, 25 Jan 2002 15:46:26 +0100 From: David Partain Subject: summary of issues I've raised with the Alarm MIB To: DISMAN Mailing List Reply-To: David.Partain@ericsson.com Message-id: <0GQI005F210HVN@mbb1.ericsson.se> MIME-version: 1.0 X-Mailer: KMail [version 1.3.2] Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8bit Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list Content-Transfer-Encoding: 8bit Hi, In the interest of collecting everything in one place rather than a bunch of different pieces of e-mail, here is the list of things I've sent in. It's not an attempt to go through the arguments again, just to collect them so they don't get lost. Everything's been brought up in previous mail. * Identification of resources by OIDs (_most_ important) I think it's _very very_ important that we use OIDs for resource naming rather than the current integer/integer pair. * Inclusion of "user-friendly" textual information in the generic traps. * Need to clarify what happens to an alarmModelEntry when it goes notInService. * Change indices to not-accessible or accessible-for-notify as appropriate. This necessitates small changes in object groups, as well. * Add MODULE-IDENTITY macros where needed * How can alarmActiveTable and alarmClearTable share an index from alarmActiveTable given that when an alarm is cleared it is moved to alarmClearTable and the corresponding entry in alarmActiveTable is removed? * Add a SHOULD or MUST to objects that use DateAndTime stating that they agents should provide timezone information. Randy's mail on 10 January 2002 would be great. * Need clarification on how alarmModelVarbindIndex works * Small change: move alarmNotifications from { alarmMIB 2 } to { alarmMIB 0 } do you don't have to have { alarmNotifications 0 1 } but can instead just have { alarmNotifications 1 }. I realize this is cosmetic. In the interest of being concrete about what I'd change, I've put a diff against the current -04 draft as well as my version after the changes at http://www.cs.utk.edu/~partain/disman Much of what's listed above is _not_ in my edits. I'm not particularly married to any of the textual changes I made, so change as you see fit. This list will be at http://www.cs.utk.edu/~partain/disman/issues.txt and will be updated as I come up with new things :-) Cheers, dlp From owner-disman@dorothy.bmc.com Fri Jan 25 13:53:36 2002 Received: from babbler.bmc.com (firebird.bmc.com [198.207.223.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10896 for ; Fri, 25 Jan 2002 13:53:35 -0500 (EST) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g0PItrq18084; Fri, 25 Jan 2002 12:55:54 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id KAA04262 for disman-list; Fri, 25 Jan 2002 10:50:43 -0800 (PST) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id KAA04257 for ; Fri, 25 Jan 2002 10:50:39 -0800 (PST) Received: from mx-us-hou-2-int.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id g0PInFc20925 for ; Fri, 25 Jan 2002 12:49:15 -0600 (CST) Received: from riverstonenet.com (mail.riverstonenet.com [63.113.148.10]) by mx-us-hou-2-int.bmc.com (Postfix) with SMTP id 503EB1FF084 for ; Fri, 25 Jan 2002 18:39:59 -0600 (CST) Received: from dperkins-nb2.dsperkins.com by riverstonenet.com (8.9.3+Sun/SMI-SVR4-Yago) id KAA04469; Fri, 25 Jan 2002 10:51:35 -0800 (PST) Message-Id: <5.0.2.1.2.20020125083533.028de880@mail4.bayarea.net> X-Sender: dperkins@mail4.bayarea.net X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Fri, 25 Jan 2002 08:37:20 -0800 To: David.Partain@ericsson.com, DISMAN Mailing List From: "David T. Perkins" Subject: Re: summary of issues I've raised with the Alarm MIB In-Reply-To: <0GQI005F210HVN@mbb1.ericsson.se> 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, On the following... At 03:46 PM 1/25/2002 +0100, David Partain wrote: > * Change indices to not-accessible or accessible-for-notify as > appropriate. This necessitates small changes in object > groups, as well. It is not legal to have the access of index objects as accessible-for-notify. Regards, /david t. perkins From owner-disman@dorothy.bmc.com Fri Jan 25 14:24:17 2002 Received: from babbler.bmc.com (firebird.bmc.com [198.207.223.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11804 for ; Fri, 25 Jan 2002 14:24:17 -0500 (EST) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g0PJQbZ00238; Fri, 25 Jan 2002 13:26:38 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id LAA04602 for disman-list; Fri, 25 Jan 2002 11:22:04 -0800 (PST) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id LAA04596 for disman@dorothy.bmc.com; Fri, 25 Jan 2002 11:22:00 -0800 (PST) Date: Fri, 25 Jan 2002 11:22:00 -0800 (PST) From: Randy Presuhn Message-Id: <200201251922.LAA04596@dorothy.bmc.com> To: disman@dorothy.bmc.com Subject: Re: summary of issues I've raised with the Alarm MIB Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list Content-Transfer-Encoding: 7bit Hi - > Message-Id: <5.0.2.1.2.20020125083533.028de880@mail4.bayarea.net> > Date: Fri, 25 Jan 2002 08:37:20 -0800 > To: David.Partain@ericsson.com, DISMAN Mailing List > From: "David T. Perkins" > Subject: Re: summary of issues I've raised with the Alarm MIB > In-Reply-To: <0GQI005F210HVN@mbb1.ericsson.se> ... > It is not legal to have the access of index objects as > accessible-for-notify. ... I haven't been able to find such a prohibition in RFC 2578. Could you give a more specific reference to where this is spelled out? ------------------------------------------------------ Randy Presuhn BMC Software, Inc. 1-3141 randy_presuhn@bmc.com 2141 North First Street Tel: +1 408 546-1006 San José, California 95131 USA ------------------------------------------------------ My opinions and BMC's are independent variables. ------------------------------------------------------ From owner-disman@dorothy.bmc.com Fri Jan 25 14:52:27 2002 Received: from babbler.bmc.com (camaro.bmc.com [198.207.223.231]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12553 for ; Fri, 25 Jan 2002 14:52:26 -0500 (EST) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g0PJslx06882; Fri, 25 Jan 2002 13:54:47 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id LAA04751 for disman-list; Fri, 25 Jan 2002 11:50:13 -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 LAA04745; Fri, 25 Jan 2002 11:50:10 -0800 (PST) Received: from mx-us-hou-1-int.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id g0PJmkg09760; Fri, 25 Jan 2002 13:48:46 -0600 (CST) Received: from riverstonenet.com (unknown [63.113.148.10]) by mx-us-hou-1-int.bmc.com (Postfix) with SMTP id 5DA7420F16B; Fri, 25 Jan 2002 19:38:01 -0600 (CST) Received: from dperkins-nb2.dsperkins.com by riverstonenet.com (8.9.3+Sun/SMI-SVR4-Yago) id LAA09137; Fri, 25 Jan 2002 11:51:32 -0800 (PST) Message-Id: <5.0.2.1.2.20020125115019.02cb1a60@mail4.bayarea.net> X-Sender: dperkins@mail4.bayarea.net X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Fri, 25 Jan 2002 11:51:11 -0800 To: Randy Presuhn , disman@dorothy.bmc.com From: "David T. Perkins" Subject: Re: summary of issues I've raised with the Alarm MIB In-Reply-To: <200201251922.LAA04596@dorothy.bmc.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by dorothy.bmc.com id LAA04746 Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list Content-Transfer-Encoding: 8bit HI, Look near the end of section 7.7 in RFC 2578 for rules about max-access for index objects. Regards, /david t. perkins At 11:22 AM 1/25/2002 -0800, Randy Presuhn wrote: >Hi - > >> Message-Id: <5.0.2.1.2.20020125083533.028de880@mail4.bayarea.net> >> Date: Fri, 25 Jan 2002 08:37:20 -0800 >> To: David.Partain@ericsson.com, DISMAN Mailing List >> From: "David T. Perkins" >> Subject: Re: summary of issues I've raised with the Alarm MIB >> In-Reply-To: <0GQI005F210HVN@mbb1.ericsson.se> >... >> It is not legal to have the access of index objects as >> accessible-for-notify. >... > >I haven't been able to find such a prohibition in RFC 2578. >Could you give a more specific reference to where this is >spelled out? > > ------------------------------------------------------ > Randy Presuhn BMC Software, Inc. 1-3141 > randy_presuhn@bmc.com 2141 North First Street > Tel: +1 408 546-1006 San José, California 95131 USA > ------------------------------------------------------ > My opinions and BMC's are independent variables. > ------------------------------------------------------ From owner-disman@dorothy.bmc.com Fri Jan 25 16:54:53 2002 Received: from babbler.bmc.com (firebird.bmc.com [198.207.223.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15415 for ; Fri, 25 Jan 2002 16:54:52 -0500 (EST) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g0PLv5L04314; Fri, 25 Jan 2002 15:57:05 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id NAA05369 for disman-list; Fri, 25 Jan 2002 13:51:47 -0800 (PST) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id NAA05363 for disman@dorothy.bmc.com; Fri, 25 Jan 2002 13:51:44 -0800 (PST) Date: Fri, 25 Jan 2002 13:51:44 -0800 (PST) From: Randy Presuhn Message-Id: <200201252151.NAA05363@dorothy.bmc.com> To: disman@dorothy.bmc.com Subject: Re: summary of issues I've raised with the Alarm MIB Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list Content-Transfer-Encoding: 8bit Hi - > Message-Id: <5.0.2.1.2.20020125115019.02cb1a60@mail4.bayarea.net> > Date: Fri, 25 Jan 2002 11:51:11 -0800 > To: Randy Presuhn , disman@dorothy.bmc.com > From: "David T. Perkins" > Subject: Re: summary of issues I've raised with the Alarm MIB > In-Reply-To: <200201251922.LAA04596@dorothy.bmc.com> ... > Look near the end of section 7.7 in RFC 2578 for rules about max-access > for index objects. ... I still don't see the prohibition. ------------------------------------------------------ Randy Presuhn BMC Software, Inc. 1-3141 randy_presuhn@bmc.com 2141 North First Street Tel: +1 408 546-1006 San José, California 95131 USA ------------------------------------------------------ My opinions and BMC's are independent variables. ------------------------------------------------------ From owner-disman@dorothy.bmc.com Fri Jan 25 17:09:32 2002 Received: from babbler.bmc.com (camaro.bmc.com [198.207.223.231]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15860 for ; Fri, 25 Jan 2002 17:09:32 -0500 (EST) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g0PMBsA09053; Fri, 25 Jan 2002 16:11:54 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id OAA05685 for disman-list; Fri, 25 Jan 2002 14:07: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 OAA05679; Fri, 25 Jan 2002 14:07:11 -0800 (PST) Received: from mx-us-hou-1-int.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id g0PM5lR21509; Fri, 25 Jan 2002 16:05:47 -0600 (CST) Received: from riverstonenet.com (unknown [63.113.148.10]) by mx-us-hou-1-int.bmc.com (Postfix) with SMTP id BB95C20F033; Fri, 25 Jan 2002 21:54:58 -0600 (CST) Received: from dperkins-nb2.dsperkins.com by riverstonenet.com (8.9.3+Sun/SMI-SVR4-Yago) id OAA20173; Fri, 25 Jan 2002 14:08:26 -0800 (PST) Message-Id: <5.0.2.1.2.20020125140542.02af5300@mail4.bayarea.net> X-Sender: dperkins@mail4.bayarea.net X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Fri, 25 Jan 2002 14:08:03 -0800 To: Randy Presuhn , disman@dorothy.bmc.com From: "David T. Perkins" Subject: Re: summary of issues I've raised with the Alarm MIB In-Reply-To: <200201252151.NAA05363@dorothy.bmc.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list HI, At 01:51 PM 1/25/2002 -0800, Randy Presuhn wrote: >I still don't see the prohibition. From RFC 2578, end of section 7.7: Objects which are both specified in the INDEX clause of a conceptual row and also columnar objects of the same conceptual row are termed auxiliary objects. The MAX-ACCESS clause for auxiliary objects is "not-accessible", except in the following circumstances: ^^^^^^^^^^^^^^^^ here (1) within a MIB module originally written to conform to SMIv1, and later converted to conform to SMIv2; or (2) a conceptual row must contain at least one columnar object which is not an auxiliary object. In the event that all of a conceptual row's columnar objects are also specified in its INDEX clause, then one of them must be accessible, i.e., have a MAX-ACCESS clause of "read-only". (Note that this situation does not arise for a conceptual row allowing create access, since such a row will have a status column which will not be an auxiliary object.) Note that objects specified in a conceptual row's INDEX clause need not be columnar objects of that conceptual row. In this situation, the DESCRIPTION clause of the conceptual row must include a textual explanation of how the objects which are included in the INDEX clause but not columnar objects of that conceptual row, are used in uniquely identifying instances of the conceptual row's columnar objects. Regards, /david t. perkins From owner-disman@dorothy.bmc.com Fri Jan 25 18:12:48 2002 Received: from babbler.bmc.com (firebird.bmc.com [198.207.223.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17676 for ; Fri, 25 Jan 2002 18:12:48 -0500 (EST) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g0PNDNb27215; Fri, 25 Jan 2002 17:13:23 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id PAA05876 for disman-list; Fri, 25 Jan 2002 15:08:27 -0800 (PST) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id PAA05870 for disman@dorothy.bmc.com; Fri, 25 Jan 2002 15:08:24 -0800 (PST) Date: Fri, 25 Jan 2002 15:08:24 -0800 (PST) From: Randy Presuhn Message-Id: <200201252308.PAA05870@dorothy.bmc.com> To: disman@dorothy.bmc.com Subject: Re: summary of issues I've raised with the Alarm MIB Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list Content-Transfer-Encoding: 7bit Hi - > Message-Id: <5.0.2.1.2.20020125140542.02af5300@mail4.bayarea.net> > Date: Fri, 25 Jan 2002 14:08:03 -0800 > To: Randy Presuhn , disman@dorothy.bmc.com > From: "David T. Perkins" > Subject: Re: summary of issues I've raised with the Alarm MIB > In-Reply-To: <200201252151.NAA05363@dorothy.bmc.com> ... > From RFC 2578, end of section 7.7: ... > "not-accessible", except in the following circumstances: > ^^^^^^^^^^^^^^^^ here *except* ... > (2) a conceptual row must contain at least one columnar object which is > not an auxiliary object. In the event that all of a conceptual > row's columnar objects are also specified in its INDEX clause, then > one of them must be accessible, i.e., have a MAX-ACCESS clause of > "read-only". (Note that this situation does not arise for a > conceptual row allowing create access, since such a row will have a > status column which will not be an auxiliary object.) ... I had understood exception (2) as potentially permitting an "accessible-for-notify". ------------------------------------------------------ Randy Presuhn BMC Software, Inc. 1-3141 randy_presuhn@bmc.com 2141 North First Street Tel: +1 408 546-1006 San José, California 95131 USA ------------------------------------------------------ My opinions and BMC's are independent variables. ------------------------------------------------------ From owner-disman@dorothy.bmc.com Fri Jan 25 19:38:43 2002 Received: from babbler.bmc.com (camaro.bmc.com [198.207.223.231]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18936 for ; Fri, 25 Jan 2002 19:38:42 -0500 (EST) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g0Q0f3708592; Fri, 25 Jan 2002 18:41:03 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id QAA09689 for disman-list; Fri, 25 Jan 2002 16:36:01 -0800 (PST) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id QAA09681; Fri, 25 Jan 2002 16:35:58 -0800 (PST) Received: from mx-us-hou-2-int.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id g0Q0YXe26858; Fri, 25 Jan 2002 18:34:33 -0600 (CST) Received: from riverstonenet.com (mail.riverstonenet.com [63.113.148.10]) by mx-us-hou-2-int.bmc.com (Postfix) with SMTP id EBD861FF067; Sat, 26 Jan 2002 00:25:21 -0600 (CST) Received: from dperkins-nb2.dsperkins.com by riverstonenet.com (8.9.3+Sun/SMI-SVR4-Yago) id QAA03136; Fri, 25 Jan 2002 16:37:06 -0800 (PST) Message-Id: <5.0.2.1.2.20020125163447.02cfade0@mail4.bayarea.net> X-Sender: dperkins@mail4.bayarea.net X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Fri, 25 Jan 2002 16:36:41 -0800 To: Randy Presuhn , disman@dorothy.bmc.com From: "David T. Perkins" Subject: Re: summary of issues I've raised with the Alarm MIB In-Reply-To: <200201252308.PAA05870@dorothy.bmc.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by dorothy.bmc.com id QAA09682 Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list Content-Transfer-Encoding: 8bit HI, On the below... Exception 2 says that in the special case, you can make the column "read-only". I don't see how you got "accessible-for-notify" out of it. At 03:08 PM 1/25/2002 -0800, Randy Presuhn wrote: >Hi - > >> Message-Id: <5.0.2.1.2.20020125140542.02af5300@mail4.bayarea.net> >> Date: Fri, 25 Jan 2002 14:08:03 -0800 >> To: Randy Presuhn , disman@dorothy.bmc.com >> From: "David T. Perkins" >> Subject: Re: summary of issues I've raised with the Alarm MIB >> In-Reply-To: <200201252151.NAA05363@dorothy.bmc.com> >... >> From RFC 2578, end of section 7.7: >... >> "not-accessible", except in the following circumstances: >> ^^^^^^^^^^^^^^^^ here > >*except* > >... >> (2) a conceptual row must contain at least one columnar object which is >> not an auxiliary object. In the event that all of a conceptual >> row's columnar objects are also specified in its INDEX clause, then >> one of them must be accessible, i.e., have a MAX-ACCESS clause of >> "read-only". (Note that this situation does not arise for a >> conceptual row allowing create access, since such a row will have a >> status column which will not be an auxiliary object.) >... > >I had understood exception (2) as potentially permitting >an "accessible-for-notify". > > ------------------------------------------------------ > Randy Presuhn BMC Software, Inc. 1-3141 > randy_presuhn@bmc.com 2141 North First Street > Tel: +1 408 546-1006 San José, California 95131 USA > ------------------------------------------------------ > My opinions and BMC's are independent variables. > ------------------------------------------------------ Regards, /david t. perkins From owner-disman@dorothy.bmc.com Fri Jan 25 20:39:02 2002 Received: from babbler.bmc.com (firebird.bmc.com [198.207.223.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19573 for ; Fri, 25 Jan 2002 20:39:02 -0500 (EST) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g0Q1fNM15312; Fri, 25 Jan 2002 19:41:24 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id RAA09931 for disman-list; Fri, 25 Jan 2002 17:36:31 -0800 (PST) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id RAA09925 for disman@dorothy.bmc.com; Fri, 25 Jan 2002 17:36:27 -0800 (PST) Date: Fri, 25 Jan 2002 17:36:27 -0800 (PST) From: Randy Presuhn Message-Id: <200201260136.RAA09925@dorothy.bmc.com> To: disman@dorothy.bmc.com Subject: Re: summary of issues I've raised with the Alarm MIB Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list Content-Transfer-Encoding: 8bit Hi - > Message-Id: <5.0.2.1.2.20020125163447.02cfade0@mail4.bayarea.net> > Date: Fri, 25 Jan 2002 16:36:41 -0800 > To: Randy Presuhn , disman@dorothy.bmc.com > From: "David T. Perkins" > Subject: Re: summary of issues I've raised with the Alarm MIB > In-Reply-To: <200201252308.PAA05870@dorothy.bmc.com> ... > Exception 2 says that in the special case, you can make the column > "read-only". I don't see how you got "accessible-for-notify" out > of it. ... I read the "i.e." as an "e.g.", given the history of how accessible-for-notify was added. I understand your argument now, essentially interpreting the "lack of permission" as "prohibition." ------------------------------------------------------ Randy Presuhn BMC Software, Inc. 1-3141 randy_presuhn@bmc.com 2141 North First Street Tel: +1 408 546-1006 San José, California 95131 USA ------------------------------------------------------ My opinions and BMC's are independent variables. ------------------------------------------------------ From owner-disman@dorothy.bmc.com Mon Jan 28 07:38:59 2002 Received: from babbler.bmc.com (camaro.bmc.com [198.207.223.231]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23174 for ; Mon, 28 Jan 2002 07:38:59 -0500 (EST) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g0SCf4O23085; Mon, 28 Jan 2002 06:41:04 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id EAA08116 for disman-list; Mon, 28 Jan 2002 04:34:31 -0800 (PST) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id EAA08111 for ; Mon, 28 Jan 2002 04:34:27 -0800 (PST) Received: from mx-us-hou-2-int.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id g0SCX1T07396 for ; Mon, 28 Jan 2002 06:33:01 -0600 (CST) Received: from zcars0m9.ca.nortel.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by mx-us-hou-2-int.bmc.com (Postfix) with SMTP id 0AFCC1FF062 for ; Mon, 28 Jan 2002 12:23:43 -0600 (CST) Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57]) by zcars0m9.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g0SCZZL08049; Mon, 28 Jan 2002 07:35:36 -0500 (EST) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g0SCZYp15417; Mon, 28 Jan 2002 07:35:34 -0500 (EST) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 28 Jan 2002 07:35:34 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD340191368A@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: DISMAN Mailing List , David.Partain@ericsson.com Subject: RE: summary of issues I've raised with the Alarm MIB Date: Mon, 28 Jan 2002 07:35:45 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list hi Some of this is already covered in the open issues list. I should be sending out an updated version of that later today. I'll add the delta issues and proposed solution at that time David> * Change indices to not-accessible or accessible-for-notify as David> appropriate. This necessitates small changes in object David> groups, as well. New Alarm#16 David> * Add MODULE-IDENTITY macros where needed I'll add them. New Alarm #17 David> * How can alarmActiveTable and alarmClearTable share an index David> from alarmActiveTable given that when an alarm is cleared it David> is moved to alarmClearTable and the corresponding entry in David> alarmActiveTable is removed? New Alarm #18 Well, I guess the alarmActiveIndex does not exist when it is being used in the clear table. I've seen this sort of thing done before, but strictly speaking, should alarmActiveIndex be instantiated to reuse it? If this is the case, then I would suggest creating a duplicate object that shares the same value. Dave> * Need clarification on how alarmModelVarbindIndex works This is the issue of SNMPv1 traps versus SNMPv2 traps. I'll add some clarifying text. New Alarm #19 Dave> * Small change: move alarmNotifications from { alarmMIB 2 } to Dave> { alarmMIB 0 } do you don't have to have { alarmNotifications 0 1 } Dave> but can instead just have { alarmNotifications 1 }. Dave> I realize this is cosmetic. New Alarm #20 thanks for the input, Sharon From owner-disman@dorothy.bmc.com Wed Jan 30 07:49:29 2002 Received: from babbler.bmc.com (firebird.bmc.com [198.207.223.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16589 for ; Wed, 30 Jan 2002 07:49:29 -0500 (EST) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g0UCpiv22969; Wed, 30 Jan 2002 06:51:44 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id EAA09774 for disman-list; Wed, 30 Jan 2002 04:44:52 -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 EAA09769 for ; Wed, 30 Jan 2002 04:44:39 -0800 (PST) Received: from mx-us-hou-1-int.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id g0UChCm26077 for ; Wed, 30 Jan 2002 06:43:12 -0600 (CST) Received: from zcars0m9.ca.nortel.com (unknown [47.129.242.157]) by mx-us-hou-1-int.bmc.com (Postfix) with SMTP id DC39B20F131 for ; Wed, 30 Jan 2002 12:31:58 -0600 (CST) Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56]) by zcars0m9.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g0UCjL816099; Wed, 30 Jan 2002 07:45:22 -0500 (EST) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g0UCjJh25569; Wed, 30 Jan 2002 07:45:19 -0500 (EST) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 30 Jan 2002 07:45:21 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD34019CDA1B@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: disman@dorothy.bmc.com Cc: partain@cs.utk.edu, Juergen Schoenwaelder Subject: RE: resend Re: alarmModelEntry notInService (Alarm Issue #15) Date: Wed, 30 Jan 2002 07:45:19 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list hi I'm trying to close out some of the open issues. I like Juergen's view on this. I'll add some clarifying text on what happens, or rather doesn't happen, before the row is in service, and that alarm suppression is beyond the scope of the Alarm MIB and indicate that putting the row into notInService cannot be used for this purpose. Sharon -----Original Message----- From: Juergen Schoenwaelder [mailto:schoenw@ibr.cs.tu-bs.de] Sent: Thursday, January 17, 2002 12:06 PM To: partain@cs.utk.edu Cc: disman@dorothy.bmc.com Subject: Re: resend Re: alarmModelEntry notInService >>>>> David L Partain writes: >> Note well that the notInService value of the RowStatus textual >> convention is probably NOT appropriate as a "control" value here, >> since the row may disappear due to the provisions at the bottom of >> page 16 of RFC 2579. David> That's true, but it also seems to be the best alternative. David> 2579 also says "It is the responsibility of the DESCRIPTION David> clause of the status column to indicate what an abnormally long David> period of time would be." As such, it would be possible to use David> notInService as this "control" value as long as the DESCRIPTION David> clause clearly states what garbage collection should do. I generally recommend against mixing row creation/deletion machinery details with the actual enabled/disabled status control of a row. If there is a need to disable a row (or better the function represented by a row), then add proper status control objects. This is clear and clean and gives you extensibility in case you find out that the row may need to distinguish additional status values over time. And even implementation wise, I find it simpler to implement additional control objects than tweaking the RowStatus machinery to do additional stuff. Of course, you still have to say what the implications of notInService are - in case this is the original question and there is no requirement to be able to disable things. /js -- Juergen Schoenwaelder University of Osnabrueck Dept. of Mathematics and Computer Science Phone: +49 541 969 2483 Albrechtstr. 28, 49069 Osnabrueck, Germany Fax: +49 541 969 2770 From owner-disman@dorothy.bmc.com Wed Jan 30 08:04:00 2002 Received: from babbler.bmc.com (camaro.bmc.com [198.207.223.231]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16955 for ; Wed, 30 Jan 2002 08:03:59 -0500 (EST) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g0UD6MU24951; Wed, 30 Jan 2002 07:06:22 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id FAA09846 for disman-list; Wed, 30 Jan 2002 05:01:27 -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 FAA09841 for ; Wed, 30 Jan 2002 05:01:19 -0800 (PST) Received: from mx-us-hou-1-int.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id g0UCxsV00907 for ; Wed, 30 Jan 2002 06:59:54 -0600 (CST) Received: from albatross.wise.edt.ericsson.se (unknown [194.237.142.116]) by mx-us-hou-1-int.bmc.com (Postfix) with SMTP id F257420EFA5 for ; Wed, 30 Jan 2002 12:48:39 -0600 (CST) Received: from mbb5.ericsson.se (mbb5.ericsson.se [136.225.151.210]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g0UD2eX4024013 for ; Wed, 30 Jan 2002 14:02:40 +0100 (MET) Received: from there (lm6068.lmera.ericsson.se [150.132.106.68]) by mbb1.ericsson.se (PMDF V5.2-29 #39352) with SMTP id <0GQR0018V5KEBL@mbb1.ericsson.se> for disman@dorothy.bmc.com; Wed, 30 Jan 2002 14:02:40 +0100 (MET) Date: Wed, 30 Jan 2002 14:03:34 +0100 From: David Partain Subject: Re: resend Re: alarmModelEntry notInService (Alarm Issue #15) In-reply-to: <3549C09B853DD5119B540002A52CDD34019CDA1B@zcard0ka.ca.nortel.com> To: DISMAN Mailing List Reply-To: David.Partain@ericsson.com Message-id: <0GQR0018W5KGBL@mbb1.ericsson.se> MIME-version: 1.0 X-Mailer: KMail [version 1.3.2] Content-type: text/plain; charset=iso-8859-1 References: <3549C09B853DD5119B540002A52CDD34019CDA1B@zcard0ka.ca.nortel.com> X-MIME-Autoconverted: from 8bit to quoted-printable by albatross.wise.edt.ericsson.se id g0UD2eX4024013 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by dorothy.bmc.com id FAA09842 Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list Content-Transfer-Encoding: 8bit Hi, > I'm trying to close out some of the open issues. > > I like Juergen's view on this. I'll add some > clarifying text on what happens, or rather > doesn't happen, before the row is in service, > and that alarm suppression is beyond the scope > of the Alarm MIB and indicate that putting the > row into notInService cannot be used for this purpose. I understand. Jürgen's approach is certainly cleaner than mucking around with RowStatus. The important thing, from my perspective, is that the text clearly states what happens with notInService. Specifically, it should address the concerns voiced by Stefan on 16 Jan 2002 in mail with the subject "SV: alarmModelEntry notInService" Thanks! dlp > Sharon > > -----Original Message----- > From: Juergen Schoenwaelder [mailto:schoenw@ibr.cs.tu-bs.de] > Sent: Thursday, January 17, 2002 12:06 PM > To: partain@cs.utk.edu > Cc: disman@dorothy.bmc.com > Subject: Re: resend Re: alarmModelEntry notInService > > >>>>> David L Partain writes: > >> > >> Note well that the notInService value of the RowStatus textual > >> convention is probably NOT appropriate as a "control" value here, > >> since the row may disappear due to the provisions at the bottom of > >> page 16 of RFC 2579. > > David> That's true, but it also seems to be the best alternative. > David> 2579 also says "It is the responsibility of the DESCRIPTION > David> clause of the status column to indicate what an abnormally long > David> period of time would be." As such, it would be possible to use > David> notInService as this "control" value as long as the DESCRIPTION > David> clause clearly states what garbage collection should do. > > I generally recommend against mixing row creation/deletion machinery > details with the actual enabled/disabled status control of a row. If > there is a need to disable a row (or better the function represented > by a row), then add proper status control objects. This is clear and > clean and gives you extensibility in case you find out that the row > may need to distinguish additional status values over time. And even > implementation wise, I find it simpler to implement additional control > objects than tweaking the RowStatus machinery to do additional stuff. > > Of course, you still have to say what the implications of notInService > are - in case this is the original question and there is no > requirement to be able to disable things. From owner-disman@dorothy.bmc.com Wed Jan 30 08:35:54 2002 Received: from babbler.bmc.com (firebird.bmc.com [198.207.223.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17889 for ; Wed, 30 Jan 2002 08:35:53 -0500 (EST) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g0UDcGr29602; Wed, 30 Jan 2002 07:38:16 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id FAA09931 for disman-list; Wed, 30 Jan 2002 05:33:37 -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 FAA09926 for ; Wed, 30 Jan 2002 05:33:34 -0800 (PST) Received: from mx-us-hou-2-int.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id g0UDW8d09678 for ; Wed, 30 Jan 2002 07:32:08 -0600 (CST) Received: from zcars0m9.ca.nortel.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by mx-us-hou-2-int.bmc.com (Postfix) with SMTP id 4DFFC1FF12A for ; Wed, 30 Jan 2002 13:22:40 -0600 (CST) Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56]) by zcars0m9.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g0UDYh822197; Wed, 30 Jan 2002 08:34:43 -0500 (EST) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g0UDYah28658; Wed, 30 Jan 2002 08:34:41 -0500 (EST) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 30 Jan 2002 08:34:38 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD34019CDA8C@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: DISMAN Mailing List , David.Partain@ericsson.com Subject: RE: resend Re: alarmModelEntry notInService (Alarm Issue #15) Date: Wed, 30 Jan 2002 08:34:38 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list hi David> I understand. Jürgen's approach is certainly cleaner than David> mucking around with RowStatus. The important thing, from my David> perspective, is that the text clearly states what happens with David> notInService. Specifically, it should address the concerns David> voiced by Stefan on 16 Jan 2002 in mail with the subject David> "SV: alarmModelEntry notInService" I believe they are all covered. Here is the proposed text: "Control for creating and deleting entries. Entries may be modified while active. Alarms whose alarmModelRowStatus is not active will not appear in either the alarmActiveTable or the alarmClearTable. Setting this object to notInService cannot be used as an alarm suppression mechanism. Entries that are notInService will disappear as described in RFC2579. This row can not be modified or deleted while it is being referenced by a value of alarmActiveModelPointer." Sharon From owner-disman@dorothy.bmc.com Wed Jan 30 08:57:47 2002 Received: from babbler.bmc.com (firebird.bmc.com [198.207.223.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18657 for ; Wed, 30 Jan 2002 08:57:47 -0500 (EST) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g0UE09U03022; Wed, 30 Jan 2002 08:00:09 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id FAA10021 for disman-list; Wed, 30 Jan 2002 05:55:23 -0800 (PST) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id FAA10016 for ; Wed, 30 Jan 2002 05:55:19 -0800 (PST) Received: from mx-us-hou-2-int.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id g0UDrrl15580 for ; Wed, 30 Jan 2002 07:53:53 -0600 (CST) Received: from agitator.ibr.cs.tu-bs.de (agitator.ibr.cs.tu-bs.de [134.169.34.18]) by mx-us-hou-2-int.bmc.com (Postfix) with SMTP id B58951FF1A8 for ; Wed, 30 Jan 2002 13:44:24 -0600 (CST) Received: from haerke.ibr.cs.tu-bs.de (IDENT:root@haerke.ibr.cs.tu-bs.de [134.169.34.84]) by agitator.ibr.cs.tu-bs.de (8.12.1/8.12.1/Debian -2) with ESMTP id g0UDuGPx019303; Wed, 30 Jan 2002 14:56:16 +0100 Received: (from schoenw@localhost) by haerke.ibr.cs.tu-bs.de (8.11.6/8.11.6) id g0UDuG026556; Wed, 30 Jan 2002 14:56:16 +0100 Date: Wed, 30 Jan 2002 14:56:16 +0100 Message-Id: <200201301356.g0UDuG026556@haerke.ibr.cs.tu-bs.de> X-Authentication-Warning: haerke.ibr.cs.tu-bs.de: schoenw set sender to schoenw@ibr.cs.tu-bs.de using -f From: Juergen Schoenwaelder To: schishol@nortelnetworks.com Cc: disman@dorothy.bmc.com In-reply-to: <3549C09B853DD5119B540002A52CDD34019CDA8C@zcard0ka.ca.nortel.com> (schishol@nortelnetworks.com) Subject: Re: resend Re: alarmModelEntry notInService (Alarm Issue #15) References: <3549C09B853DD5119B540002A52CDD34019CDA8C@zcard0ka.ca.nortel.com> Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list >>>>> Sharon Chisholm writes: Sharon> This row can not be modified or deleted while it is being Sharon> referenced by a value of alarmActiveModelPointer." It might be service for implementors and improve interoperability to say precisely which of the RFC 1905 error codes applies in this case. /js From owner-disman@dorothy.bmc.com Wed Jan 30 09:21:49 2002 Received: from babbler.bmc.com (firebird.bmc.com [198.207.223.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19903 for ; Wed, 30 Jan 2002 09:21:49 -0500 (EST) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g0UEOB007280; Wed, 30 Jan 2002 08:24:11 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id GAA10076 for disman-list; Wed, 30 Jan 2002 06:19:32 -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 GAA10071 for ; Wed, 30 Jan 2002 06:19:27 -0800 (PST) Received: from mx-us-hou-1-int.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id g0UEI1023812 for ; Wed, 30 Jan 2002 08:18:01 -0600 (CST) Received: from watcher.dataductus.se (unknown [213.199.99.201]) by mx-us-hou-1-int.bmc.com (Postfix) with SMTP id CFF8920EFFA for ; Wed, 30 Jan 2002 14:06:46 -0600 (CST) Received: (qmail 8424 invoked from network); 30 Jan 2002 14:20:48 -0000 Received: from nsmail.dataductus.se (192.168.100.43) by 0 with SMTP; 30 Jan 2002 14:20:48 -0000 Received: from dataductus.com ([192.168.100.240]) by nsmail.dataductus.se (Netscape Messaging Server 4.15) with SMTP id GQR96V00.R6O for ; Wed, 30 Jan 2002 15:20:55 +0100 From: "Stefan Wallin" To: Subject: SV: resend Re: alarmModelEntry notInService (Alarm Issue #15) Date: Wed, 30 Jan 2002 15:20:50 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: <3549C09B853DD5119B540002A52CDD34019CDA1B@zcard0ka.ca.nortel.com> Sender: owner-disman@dorothy.bmc.com Precedence: bulk List-Id: IETF disman Working Group mailing list Content-Transfer-Encoding: 8bit make sure following is clear: if a row in alarmModelTable is notInService: - will the alarmActiveTable be updated or not, when the corresponding notification occurs? -----Ursprungligt meddelande----- Från: owner-disman@dorothy.bmc.com [mailto:owner-disman@dorothy.bmc.com]För Sharon Chisholm Skickat: den 30 januari 2002 13:45 Till: disman@dorothy.bmc.com Kopia: partain@cs.utk.edu; Juergen Schoenwaelder Ämne: RE: resend Re: alarmModelEntry notInService (Alarm Issue #15) hi I'm trying to close out some of the open issues. I like Juergen's view on this. I'll add some clarifying text on what happens, or rather doesn't happen, before the row is in service, and that alarm suppression is beyond the scope of the Alarm MIB and indicate that putting the row into notInService cannot be used for this purpose. Sharon -----Original Message----- From: Juergen Schoenwaelder [mailto:schoenw@ibr.cs.tu-bs.de] Sent: Thursday, January 17, 2002 12:06 PM To: partain@cs.utk.edu Cc: disman@dorothy.bmc.com Subject: Re: resend Re: alarmModelEntry notInService >>>>> David L Partain writes: >> Note well that the notInService value of the RowStatus textual >> convention is probably NOT appropriate as a "control" value here, >> since the row may disappear due to the provisions at the bottom of >> page 16 of RFC 2579. David> That's true, but it also seems to be the best alternative. David> 2579 also says "It is the responsibility of the DESCRIPTION David> clause of the status column to indicate what an abnormally long David> period of time would be." As such, it would be possible to use David> notInService as this "control" value as long as the DESCRIPTION David> clause clearly states what garbage collection should do. I generally recommend against mixing row creation/deletion machinery details with the actual enabled/disabled status control of a row. If there is a need to disable a row (or better the function represented by a row), then add proper status control objects. This is clear and clean and gives you extensibility in case you find out that the row may need to distinguish additional status values over time. And even implementation wise, I find it simpler to implement additional control objects than tweaking the RowStatus machinery to do additional stuff. Of course, you still have to say what the implications of notInService are - in case this is the original question and there is no requirement to be able to disable things. /js -- Juergen Schoenwaelder University of Osnabrueck Dept. of Mathematics and Computer Science Phone: +49 541 969 2483 Albrechtstr. 28, 49069 Osnabrueck, Germany Fax: +49 541 969 2770