FW: draft-chisholm-disman-activeAlarm-00.txt

From owner-disman@dorothy.peer.com Wed Aug 2 08:45:20 2000 Received: from tattler.bmc.com (fw-us-hou-2.bmc.com [198.207.223.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25652 for ; Wed, 2 Aug 2000 08:45:20 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.8.6) with ESMTP id e72Cg8426160; Wed, 2 Aug 2000 07:42:09 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id FAA29779 for disman-list; Wed, 2 Aug 2000 05:38:25 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id FAA29774 for ; Wed, 2 Aug 2000 05:38:20 -0700 (PDT) From: randy_presuhn@stanfordalumni.org Received: from fw-us-hou1.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.8.6) with SMTP id e72CciH25692 for ; Wed, 2 Aug 2000 07:38:44 -0500 (CDT) Received: (cpmta 21470 invoked from network); 2 Aug 2000 05:39:05 -0700 Date: 2 Aug 2000 05:39:05 -0700 Message-ID: <20000802123905.21469.cpmta@c004.sfo.cp.net> X-Sent: 2 Aug 2000 12:39:05 GMT Received: from [147.73.128.120] by mail.stanfordalumni.org with HTTP; 02 Aug 2000 05:39:05 PDT Content-Type: text/plain Content-Disposition: inline Mime-Version: 1.0 To: bwijnen@lucent.com, randy@psg.com, minutes@ietf.org Cc: disman@dorothy.peer.com X-Mailer: Web Mail 3.6.5.5 Subject: Chair's report on disman WG session at IETF-48 Sender: owner-disman@dorothy.peer.com Precedence: bulk List-Id: IETF disman Working Group mailing list Hi - Here's the mandatory one-paragraph summary: The disman working group held one session at the forty-eighth meeting of the IETF in Pittsburgh, Pennsylvania on Monday, July thirty-first. Approximately eighty people attended. The group reviewed the remaining issues for the script and schedule MIB (RFC 2592 and 2591) revisions, and discussed possible new work. Additional discussion on the mailing list is needed before we can decide whether it makes sense to request charter updates. Randy Presuhn, disman WG chair. ---------------------------------------------- E-mail@stanfordalumni.org is brought to you by the Stanford Alumni Association and Critical Path. From owner-disman@dorothy.peer.com Wed Aug 2 16:28:11 2000 Received: from tattler.bmc.com (fw-us-hou-2.bmc.com [198.207.223.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04961 for ; Wed, 2 Aug 2000 16:28:09 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.8.6) with ESMTP id e72KPfN05795; Wed, 2 Aug 2000 15:25:41 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id NAA01409 for disman-list; Wed, 2 Aug 2000 13:24:15 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id NAA01404 for ; Wed, 2 Aug 2000 13:24:11 -0700 (PDT) Received: from fw-us-hou1.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.8.6) with SMTP id e72KOXS05512 for ; Wed, 2 Aug 2000 15:24:33 -0500 (CDT) Received: from hoemlsrv.firewall.lucent.com (localhost [127.0.0.1]) by hoemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id QAA05229 for ; Wed, 2 Aug 2000 16:24:54 -0400 (EDT) Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by hoemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id QAA05213 for ; Wed, 2 Aug 2000 16:24:53 -0400 (EDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2650.21) id ; Wed, 2 Aug 2000 22:24:47 +0200 Message-ID: <2413FED0DFE6D111B3F90008C7FA61FB087FD18D@nl0006exch002u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: randy_presuhn@stanfordalumni.org Cc: disman@dorothy.peer.com, Randy Bush Subject: RE: Chair's report on disman WG session at IETF-48 Date: Wed, 2 Aug 2000 22:24:47 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-disman@dorothy.peer.com Precedence: bulk List-Id: IETF disman Working Group mailing list Thanks for summary Bert From owner-disman@dorothy.peer.com Mon Aug 7 08:44:31 2000 Received: from tattler.bmc.com (fw-us-hou-2.bmc.com [198.207.223.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07406 for ; Mon, 7 Aug 2000 08:44:30 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.8.6) with ESMTP id e779xoD23329; Mon, 7 Aug 2000 04:59:50 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id CAA19489 for disman-list; Mon, 7 Aug 2000 02:56:02 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id CAA19482 for ; Mon, 7 Aug 2000 02:55:58 -0700 (PDT) Received: from fw-us-hou1.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.8.6) with SMTP id e779uIM22905 for ; Mon, 7 Aug 2000 04:56:18 -0500 (CDT) Received: from henkell.ibr.cs.tu-bs.de (schoenw@henkell [134.169.34.191]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) with ESMTP id LAA01657; Mon, 7 Aug 2000 11:56:28 +0200 (MET DST) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id LAA23613; Mon, 7 Aug 2000 11:56:24 +0200 Date: Mon, 7 Aug 2000 11:56:24 +0200 Message-Id: <200008070956.LAA23613@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: minutes@ietf.org CC: DISMAN Mailing List Subject: disman wg meeting slides Sender: owner-disman@dorothy.peer.com Precedence: bulk List-Id: IETF disman Working Group mailing list You can pick up the slides I used during the DISMAN WG meeting at the Pittsburgh IETF from the following location: http://www.ibr.cs.tu-bs.de/~schoenw/disman-issues.ps /js -- Juergen Schoenwaelder Technical University Braunschweig Dept. Operating Systems & Computer Networks Phone: +49 531 391 3289 Bueltenweg 74/75, 38106 Braunschweig, Germany Fax: +49 531 391 5936 From owner-disman@dorothy.peer.com Tue Aug 8 08:37:16 2000 Received: from tattler.bmc.com (fw-us-hou-1.bmc.com [198.207.223.250]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18335 for ; Tue, 8 Aug 2000 08:37:15 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.8.6) with ESMTP id e781Qxa28612; Mon, 7 Aug 2000 20:26:59 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id SAA25824 for disman-list; Mon, 7 Aug 2000 18:25:59 -0700 (PDT) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id SAA25818; Mon, 7 Aug 2000 18:25:56 -0700 (PDT) Date: Mon, 7 Aug 2000 18:25:56 -0700 (PDT) From: Randy Presuhn Message-Id: <200008080125.SAA25818@dorothy.bmc.com> To: minutes@ietf.org Subject: Disman WG slides from IETF #48 Cc: disman@dorothy.peer.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-disman@dorothy.peer.com Precedence: bulk List-Id: IETF disman Working Group mailing list Content-Transfer-Encoding: 7bit Hi - The four sets of slides for the presentations given at the meeting of the disman working group at IETF #48 in Pittsburgh are available for incorporation in the proceedings: ftp://amethyst.bmc.com/pub/disman/ietf48/ietf48-disman-agenda.ppt ftp://amethyst.bmc.com/pub/disman/ietf48/disman-issues.ps ftp://amethyst.bmc.com/pub/disman/ietf48/sspm_pitts.ppt ftp://amethyst.bmc.com/pub/disman/ietf48/IETF48_DISMAN_presentation.ppt ------------------------------------------------------- Randy Presuhn randy_presuhn@bmc.com Voice: +1 408 546-1006 BMC Software, Inc. 1-3141 Fax: +1 408 965-0359 2141 North First Street http://www.bmc.com/ San José, California 95131 USA ------------------------------------------------------- My opinions and BMC's are independent variables. ------------------------------------------------------- From owner-disman@dorothy.peer.com Tue Aug 8 11:20:39 2000 Received: from tattler.bmc.com (fw-us-hou-2.bmc.com [198.207.223.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14027 for ; Tue, 8 Aug 2000 11:20:35 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.8.6) with ESMTP id e78FCtm17253; Tue, 8 Aug 2000 10:12:55 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id IAA27366 for disman-list; Tue, 8 Aug 2000 08:09:40 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id IAA27361 for ; Tue, 8 Aug 2000 08:09:21 -0700 (PDT) Received: from fw-us-hou1.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.8.6) with SMTP id e78F9a216494 for ; Tue, 8 Aug 2000 10:09:36 -0500 (CDT) Received: from zrchb213.us.nortel.com (actually zrchb213) by smtprch2.nortel.com; Tue, 8 Aug 2000 10:06:18 -0500 Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2652.35) id ; Tue, 8 Aug 2000 10:09:47 -0500 Message-ID: <6DDA62170439D31185750000F80826AC035F5059@zmerd004.ca.nortel.com> From: "Sharon Chisholm" To: disman@dorothy.peer.com Subject: FW: draft-chisholm-disman-activeAlarm-00.txt Date: Tue, 8 Aug 2000 10:09:44 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0014A.AF7D8360" X-Orig: Sender: owner-disman@dorothy.peer.com Precedence: bulk List-Id: IETF disman Working Group mailing list This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C0014A.AF7D8360 Content-Type: text/plain; charset="iso-8859-1" hi This will be published tomorrow with a few minor corrections made by the internet-drafts person. Sharon -----Original Message----- From: Chisholm, Sharon [CAR:5K32:EXCH] Sent: Tuesday, August 08, 2000 10:20 AM To: 'internet-drafts@ietf.org' Subject: draft-chisholm-disman-activeAlarm-00.txt hi I have attached my draft using the naming pattern you suggested. If there are any formatting problems with this, please let me know. Otherwise, please post the attached document as Internet Draft . This document describes a MIB for storing a list of alarms currently active on a device. thanks, Sharon Chisholm Preside Management Nortel Networks Ottawa, Ontario INTERNET-DRAFT S. Chisholm Nortel Networks August 08 2000 Active Alarm MIB Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. 1. Abstract 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 maintaining a list of alarms currently active on a network element. 2. The SNMP Management Framework The SNMP Management Framework presently consists of five major components: o An overall architecture, described in RFC 2571 [RFC2571]. o Mechanisms for describing and naming objects and events for the purpose of management. The first version of this Structure of Management Information (SMI) is called SMIv1 and described in STD 16, RFC 1155 [RFC1155], STD 16, RFC 1212 [RFC1212] and RFC 1215 [RFC1215]. The second version, called SMIv2, is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580]. o Message protocols for transferring management information. The first version of the SNMP message protocol is called SNMPv1 and described in STD 15, RFC 1157 [RFC1157]. A second version of the SNMP message protocol, which is not an Internet standards track protocol, is called SNMPv2c and described in RFC 1901 [RFC1901] and RFC 1906 [RFC1906]. The third version of the message protocol is called SNMPv3 and described in RFC 1906 [RFC1906], RFC 2572 [RFC2572] and RFC 2574 [RFC2574]. o Protocol operations for accessing management information. The first set of protocol operations and associated PDU formats is described in STD 15, RFC 1157 [RFC1157]. A second set of protocol operations and associated PDU formats is described in RFC 1905 [RFC1905]. o A set of fundamental applications described in RFC 2573 [RFC2573] and the view-based access control mechanism described in RFC 2575 [RFC2575]. A more detailed introduction to the current SNMP Management Framework can be found in RFC 2570 [RFC2570]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. Objects in the MIB are defined using the mechanisms defined in the SMI. This memo specifies a MIB module that is compliant to the SMIv2. A MIB conforming to the SMIv1 can be produced through the appropriate translations. The resulting translated MIB must be semantically equivalent, except where objects or events are omitted because no translation is possible (use of Counter64). Some machine readable information in SMIv2 will be converted into textual descriptions in SMIv1 during the translation process. However, this loss of machine readable information is not considered to change the semantics of the MIB. 3. Introduction It is intended that the active alarm table be queried upon device discovery and rediscovery to determine which faults are currently active on the device. This allows the network management station to find out about any faults that may have occurred before it started managing a particular network element, or while it was out of contact with it. Each alarm should have a corresponding clear which removes it from the active alarm table, or is should be aged out. The configuring and querying of alarm age-outs is not covered in this document. The active alarm Table is defined in a manner very similar to the log table in the notification log MIB. This format allows the storage of any NOTIFICATION that can be defined using the ASN.1 syntax. 4. Relation to notification log MIB This MIB is intended to compliment the notification log MIB, but can be used independently. The current MIB syntax does require the importation of the notification log MIB in order to re-use nlmLogName. 5. Definitions ACTIVE-ALARM-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, experimental, Integer32, Unsigned32, TimeTicks, Counter32, Counter64, IpAddress, Opaque FROM SNMPv2-SMI TimeStamp, DateAndTime, StorageType, RowStatus FROM SNMPv2-TC SnmpAdminString, SnmpEngineID FROM SNMP-FRAMEWORK-MIB MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF nlmLogName FROM NOTIFICATION-LOG-MIB; activeAlarm MODULE-IDENTITY LAST-UPDATED "000005290000Z" ORGANIZATION "Active Alarm MIB" CONTACT-INFO " Sharon Chisholm Nortel Networks PO Box 3511 Station C Ottawa, Ont. K1Y 4H7 Canada schishol@nortelnetworks.com" DESCRIPTION "The MIB module describes a generic solution to improve the reliability of SNMP traps by storing the current list of active alarms." ::= { somewhere XX } -- -- Active Alarm Table -- activeAlarmObjects OBJECT IDENTIFIER ::= { activeAlarm 1 } activeAlarmTable OBJECT-TYPE SYNTAX SEQUENCE OF ActiveAlarmEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of Active Alarms entries." ::= { activeAlarmObjects 1 } activeAlarmEntry OBJECT-TYPE SYNTAX ActiveAlarmEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Entries appear in this table when faults are active. They are removed when the fault is not longer occurring." INDEX { nlmLogName, activeAlarmIndex } ::= { activeAlarmTable 1 } ActiveAlarmEntry ::= SEQUENCE { activeAlarmIndex Unsigned32, activeAlarmTime TimeStamp, activeAlarmDateAndTime DateAndTime, activeAlarmEngineID SnmpEngineID, activeAlarmEngineAddress IpAddress, activeAlarmContextEngineID SnmpEngineID, activeAlarmContextName SnmpAdminString, activeAlarmVariables Unsigned32, activeAlarmNotificationID OBJECT IDENTIFIER, activeAlarmLogIndex Unsigned32 } activeAlarmIndex OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS read-only STATUS current DESCRIPTION "A monotonically increasing integer which acts as the index of entries within the named alarm list. It wraps back to 1 after it reaches its maximum value." ::= { activeAlarmEntry 1 } activeAlarmTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime when the alarm occurred. Alarms get cleared and resent if still applicable at reboot, so this value is always a valid sysUptime." ::= { activeAlarmEntry 2 } activeAlarmDateAndTime OBJECT-TYPE SYNTAX DateAndTime MAX-ACCESS read-only STATUS current DESCRIPTION "The local date and time when the alarm occurred, instantiated only by systems that have date and time capability." ::= { activeAlarmEntry 3 } activeAlarmEngineID OBJECT-TYPE SYNTAX SnmpEngineID MAX-ACCESS read-only STATUS current DESCRIPTION "The identification of the SNMP engine at which the alarm originated. If the alarm list can contain Notifications from only one engine or the Trap is from an SNMPv1 system, this object is not instantiated." ::= { activeAlarmEntry 4 } activeAlarmEngineAddress OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS read-only STATUS current DESCRIPTION "The IP Address of the SNMP engine on which the alarm is occurring. This is used to identify the source of an SNMPv1 trap, since an nlmLogEngineId cannot be extracted from the SNMPv1 trap pdu. This object MUST always be instantiated, even if the list can contain alarms from only one engine." ::= { activeAlarmEntry 5 } activeAlarmContextEngineID OBJECT-TYPE SYNTAX SnmpEngineID MAX-ACCESS read-only STATUS current DESCRIPTION "If the alarm is occurring on a device using a protocol which has a contextEngineID element like SNMPv3, this object has that value. Otherwise its value is a zero-length string." ::= { activeAlarmEntry 6 } activeAlarmContextName OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION "The name of the SNMP MIB context from which the alarm came. For SNMPv1 Traps this is the community string from the Trap. If the alarm's source SNMP engine is known not to support multiple contexts, this object is not instantiated." ::= { activeAlarmEntry 5 } activeAlarmVariables OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of variables in activeAlarmVariableTable for this Notification." ::= { activeAlarmEntry 6 } activeAlarmNotificationID OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-only STATUS current DESCRIPTION "The NOTIFICATION-TYPE object identifier of the Notification that occurred." ::= { activeAlarmEntry 7 } activeAlarmLogIndex OBJECT-TYPE SYNTAX Unsigned32 (0..4294967295) MAX-ACCESS read-only STATUS current DESCRIPTION "This number can be considered a sequence number for the trap. It should be the same of the log index in the notification log MIB, if used. If no log index or sequence number applies to the trap, then this object should have the value of 0." ::= { activeAlarmEntry 8 } -- -- Active Alarm Variable Table -- activeAlarmVariableTable OBJECT-TYPE SYNTAX SEQUENCE OF ActiveAlarmVariableEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of variables to go with active alarm entries." ::= { activeAlarmObjects 2 } activeAlarmVariableEntry OBJECT-TYPE SYNTAX ActiveAlarmVariableEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Entries appear in this table when there are variables in the varbind list of a corresponding alarm in activeAlarmTable." INDEX { nlmLogName, activeAlarmIndex, activeAlarmVariableIndex } ::= { activeAlarmVariableTable 1 } ActiveAlarmVariableEntry ::= SEQUENCE { activeAlarmVariableIndex Unsigned32, activeAlarmVariableID OBJECT IDENTIFIER, activeAlarmVariableValueType INTEGER, activeAlarmVariableCounter32Val Counter32, activeAlarmVariableUnsigned32Val Unsigned32, activeAlarmVariableTimeTicksVal TimeTicks, activeAlarmVariableInteger32Val Integer32, activeAlarmVariableOctetStringVal OCTET STRING, activeAlarmVariableIpAddressVal IpAddress, activeAlarmVariableOidVal OBJECT IDENTIFIER, activeAlarmVariableCounter64Val Counter64, activeAlarmVariableOpaqueVal Opaque } activeAlarmVariableIndex OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "A monotonically increasing integer, starting at 1 for a given activeAlarmIndex, for indexing variables within the active alarm list." ::= { activeAlarmVariableEntry 1 } activeAlarmVariableID OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-only STATUS current DESCRIPTION "The variable's object identifier." ::= { activeAlarmVariableEntry 2 } activeAlarmVariableValueType 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 is used, based on this type." ::= { activeAlarmVariableEntry 3 } activeAlarmVariableCounter32Val OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The value when activeAlarmVariableType is 'counter32'." ::= { activeAlarmVariableEntry 4 } activeAlarmVariableUnsigned32Val OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "The value when activeAlarmVariableType is 'unsigned32'." ::= { activeAlarmVariableEntry 5 } activeAlarmVariableTimeTicksVal OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS current DESCRIPTION "The value when activeAlarmVariableType is 'timeTicks'." ::= { activeAlarmVariableEntry 6 } activeAlarmVariableInteger32Val OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "The value when activeAlarmVariableType is 'integer32'." ::= { activeAlarmVariableEntry 7 } activeAlarmVariableOctetStringVal OBJECT-TYPE SYNTAX OCTET STRING MAX-ACCESS read-only STATUS current DESCRIPTION "The value when activeAlarmVariableType is 'octetString'." ::= { activeAlarmVariableEntry 8 } activeAlarmVariableIpAddressVal OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS read-only STATUS current DESCRIPTION "The value when activeAlarmVariableType is 'ipAddress'." ::= { activeAlarmVariableEntry 9 } activeAlarmVariableOidVal OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-only STATUS current DESCRIPTION "The value when activeAlarmVariableType is 'objectId'." ::= { activeAlarmVariableEntry 10 } activeAlarmVariableCounter64Val OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The value when activeAlarmVariableType is 'counter64'." ::= { activeAlarmVariableEntry 11 } activeAlarmVariableOpaqueVal OBJECT-TYPE SYNTAX Opaque MAX-ACCESS read-only STATUS current DESCRIPTION "The value when activeAlarmVariableType is 'opaque'." ::= { activeAlarmVariableEntry 12 } -- -- Statistics -- activeAlarmStatsTable OBJECT-TYPE SYNTAX SEQUENCE OF ActiveAlarmStatsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table represents the alarm statistics type information." ::= { activeAlarmObjects 3 } activeAlarmStatsEntry OBJECT-TYPE SYNTAX ActiveAlarmStatsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Statistics on the current active alarms." INDEX { nlmLogName } ::= { activeAlarmStatsTable 1 } ActiveAlarmStatsEntry ::= SEQUENCE { activeAlarmStatsTotalActive Unsigned32 } activeAlarmStatsTotalActive OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of currently active alarms on the system." ::= { activeAlarmStatsEntry 1 } -- Conformance Stuff activeAlarmConformance OBJECT IDENTIFIER ::= { activeAlarm 2 } activeAlarmListGroup OBJECT-GROUP OBJECTS { activeAlarmIndex, activeAlarmTime, activeAlarmDateAndTime, activeAlarmEngineID, activeAlarmEngineAddress, activeAlarmContextEngineID, activeAlarmContextName, activeAlarmVariables, activeAlarmNotificationID, activeAlarmLogIndex, activeAlarmVariableIndex, activeAlarmVariableID, activeAlarmVariableValueType, activeAlarmVariableCounter32Val, activeAlarmVariableUnsigned32Val, activeAlarmVariableTimeTicksVal, activeAlarmVariableInteger32Val, activeAlarmVariableOctetStringVal, activeAlarmVariableIpAddressVal, activeAlarmVariableOidVal, activeAlarmVariableCounter64Val, activeAlarmVariableOpaqueVal } STATUS current DESCRIPTION "Active Alarm list group." ::= { activeAlarmConformance 2} activeAlarmSummaryGroup OBJECT-GROUP OBJECTS { activeAlarmStatsTotalActive } STATUS current DESCRIPTION " Active alarm summary group." ::= { activeAlarmConformance 3} activeAlarmCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for systems supporting Active Alarm MIB." MODULE -- this module MANDATORY-GROUPS { activeAlarmListGroup } GROUP activeAlarmSummaryGroup DESCRIPTION "The actual active alarms." ::= { activeAlarmConformance 1 } END 6. Example Define the following Object: acmeWidgetIndex OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "A unique number which identifies a particular Widget." ::= { acmeWidgetEntry 1 } Define the following three traps: acmeWidgetTemperatureCritical NOTIFICATION-TYPE OBJECTS { acmeWidgetIndex } STATUS current DESCRIPTION "This trap indicates that the indicated widget has reached a critical temperature." ::= { acmeWidgetTraps 1 } acmeWidgetTemperatureNormal NOTIFICATION-TYPE OBJECTS { acmeWidgetIndex } STATUS current DESCRIPTION "This trap indicates that the indicated widget has reached a normal temperature." ::= { acmeWidgetTraps 2 } bgpBackwardTransition NOTIFICATION-TYPE OBJECTS { bgpPeerLastError, bgpPeerState } STATUS current DESCRIPTION "The BGPBackwardTransition Event is generated when the BGP FSM moves from a higher numbered state to a lower numbered state." ::= { bgpTraps 2 } 0. Active alarm table empty and nothing in notification log ___________________________ _____________________ | activeAlarmTable | | nlmLogTable | |---------------------------| |---------------------| | activeAlarmIndex | alarm | | nlmLogIndex | alarm | |---------------------------| |---------------------| |___________________________| |_____________________| 1. Temperature of widget 2 goes critical __________________________________________________ | activeAlarmTable | |--------------------------------------------------| | activeAlarmIndex | alarm | |--------------------------------------------------| | 1 | acmeWidgetTemperatureCritical | |__________________________________________________| _____________________________________________ | nlmLogTable | |---------------------------------------------| | nlmLogIndex | alarm | |---------------------------------------------| | 1 | acmeWidgetTemperatureCritical | |_____________________________________________| 2. BGP peering session transitions from a state of established to opensent __________________________________________________ | activeAlarmTable | |--------------------------------------------------| | activeAlarmIndex | alarm | |--------------------------------------------------| | 1 | acmeWidgetTemperatureCritical | | 2 | bgpBackwardTransition | |__________________________________________________| _____________________________________________ | nlmLogTable | |---------------------------------------------| | nlmLogIndex | alarm | |---------------------------------------------| | 1 | acmeWidgetTemperatureCritical | | 2 | bgpBackwardTransition | |_____________________________________________| 3. Temperature of widget 2 goes back to normal __________________________________________________ | activeAlarmTable | |--------------------------------------------------| | activeAlarmIndex | alarm | |--------------------------------------------------| | 2 | bgpBackwardTransition | |__________________________________________________| _____________________________________________ | nlmLogTable | |---------------------------------------------| | nlmLogIndex | alarm | |---------------------------------------------| | 1 | acmeWidgetTemperatureCritical | | 2 | bgpBackwardTransition | | 3 | acmeWidgetTemperatureNormal | |_____________________________________________| 4. Time passes .... BGP alarm ages out. __________________________________________________ | activeAlarmTable | |--------------------------------------------------| | activeAlarmIndex | alarm | |--------------------------------------------------| |__________________________________________________| _____________________________________________ | nlmLogTable | |---------------------------------------------| | nlmLogIndex | alarm | |---------------------------------------------| | 1 | acmeWidgetTemperatureCritical | | 2 | bgpBackwardTransition | | 3 | acmeWidgetTemperatureNormal | |_____________________________________________| 7. Security Considerations There are no management objects defined in this MIB that have a MAX- ACCESS clause of read-write and/or read-create. So, if this MIB is implemented correctly, then there is no risk that an intruder can alter or create any management objects of this MIB via direct SNMP SET operations. 8. Author's Address Sharon Chisholm Nortel Networks PO Box 3511, Station C Ottawa, Ontario, K1Y 4H7 Canada Email: schishol@nortelnetworks.com 9. References [1] Stewart, B, "Notification Log MIB, draft 12, October 1999 10. Full Copyright Statement Copyright (C) The Internet Society (2000). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. ------_=_NextPart_001_01C0014A.AF7D8360 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable FW: draft-chisholm-disman-activeAlarm-00.txt

This will be published tomorrow with a few minor = corrections
made by the internet-drafts person.

Sharon

-----Original Message-----
From: Chisholm, Sharon [CAR:5K32:EXCH]
Sent: Tuesday, August 08, 2000 10:20 AM
To: 'internet-drafts@ietf.org'
Subject: = draft-chisholm-disman-activeAlarm-00.txt

I have attached my draft using the naming = pattern
you suggested. If there are any formatting = problems with this,
please let me know. Otherwise, please post the = attached
document as Internet Draft = <draft-chisholm-disman-activeAlarm-00.txt>.
This document describes a MIB for storing a list of = alarms
currently active on a device.

thanks,

Sharon Chisholm
Preside Management
Nortel Networks
Ottawa, Ontario

INTERNET-DRAFT        &= nbsp;           &= nbsp;           &= nbsp;         S. = Chisholm
          &nb= sp;           &nb= sp;           &nb= sp;           &nb= sp;         Nortel = Networks
          &nb= sp;           &nb= sp;           &nb= sp;           &nb= sp;         August 08 = 2000

= = = Active Alarm = MIB =

Status of this Memo

This document is an Internet-Draft and is in full = conformance
with all provisions of Section 10 of RFC2026.

Internet-Drafts are working documents of the Internet = Engineering
Task Force (IETF), its areas, and its working = groups. Note that
other groups may also distribute working documents = as
Internet-Drafts.

Internet-Drafts are draft documents valid for a = maximum of six
months and may be updated, replaced, or obsoleted by = other
documents at any time. It is inappropriate to = use Internet-
Drafts as reference material or to cite them other = than as
"work in progress."

The list of current Internet-Drafts can be accessed = at

http://www.ietf.org/ietf/1id-abstracts.txt

The list of Internet-Draft Shadow Directories can be = accessed at
http://www.ietf.org/shadow.html.

1. Abstract

   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 maintaining
   a list of alarms currently active on a = network element.

2. The SNMP Management Framework

The SNMP Management Framework presently = consists of five major
components:

o An overall = architecture, described in RFC 2571 [RFC2571].

    o   Mechanisms for = describing and naming objects and events for the
        purpose = of management. The first version of this Structure of
        = Management Information (SMI) is called SMIv1 and described in
        STD 16, = RFC 1155 [RFC1155], STD 16, RFC 1212 [RFC1212] and RFC
        1215 = [RFC1215]. The second version, called SMIv2, is described
        in STD = 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and
        STD 58, = RFC 2580 [RFC2580].

    o   Message protocols = for transferring management information. The
        first = version of the SNMP message protocol is called SNMPv1 and
        described = in STD 15, RFC 1157 [RFC1157]. A second version of

        the SNMP = message protocol, which is not an Internet standards
        track = protocol, is called SNMPv2c and described in RFC 1901
        [RFC1901] = and RFC 1906 [RFC1906]. The third version of the
        message = protocol is called SNMPv3 and described in RFC 1906
        = [RFC1906], RFC 2572 [RFC2572] and RFC 2574 [RFC2574].

    o   Protocol operations = for accessing management information. The
        first set = of protocol operations and associated PDU formats is
        described = in STD 15, RFC 1157 [RFC1157]. A second set of
        protocol = operations and associated PDU formats is described in
        RFC 1905 = [RFC1905].

    o   A set of fundamental = applications described in RFC 2573
        [RFC2573] = and the view-based access control mechanism described
        in RFC = 2575 [RFC2575].

A more detailed introduction to the = current SNMP Management Framework
can be found in RFC 2570 = [RFC2570].

   Managed objects are accessed via a = virtual information store, termed
   the Management Information Base or = MIB. Objects in the MIB are
   defined using the mechanisms defined in = the SMI.

   This memo specifies a MIB module that is = compliant to the SMIv2. A
   MIB conforming to the SMIv1 can be = produced through the appropriate
   translations. The resulting = translated MIB must be semantically
   equivalent, except where objects or = events are omitted because no
   translation is possible (use of = Counter64). Some machine readable
   information in SMIv2 will be converted = into textual descriptions in
   SMIv1 during the translation = process. However, this loss of machine
   readable information is not considered = to change the semantics of the
   MIB.

3. Introduction

   It is intended that the active alarm = table be queried upon device
   discovery and rediscovery to determine = which faults are currently
   active on the device. This allows the = network management station to
   find out about any faults that may have = occurred before it started
   managing a particular network element, = or while it was out of contact
   with it.

   Each alarm should have a corresponding = clear which removes it from the
   active alarm table, or is should be = aged out. The configuring and
   querying of alarm age-outs is not = covered in this document.

   The active alarm Table is defined in a = manner very similar to the
   log table in the notification log = MIB. This format allows the
   storage of any NOTIFICATION that can be = defined using the ASN.1
   syntax.

4. Relation to notification log MIB

This MIB is intended to compliment the = notification log MIB, but
can be used independently. The = current MIB syntax does require

the importation of the notification log = MIB in order to re-use

nlmLogName.

=20
5. Definitions
=20
ACTIVE-ALARM-MIB DEFINITIONS ::=3D BEGIN

IMPORTS
    MODULE-IDENTITY, = OBJECT-TYPE,
    experimental, Integer32, = Unsigned32,
    TimeTicks, Counter32, = Counter64,
    IpAddress, = Opaque           =         FROM SNMPv2-SMI
    TimeStamp, DateAndTime,
    StorageType, = RowStatus          &nb= sp;   FROM SNMPv2-TC
    SnmpAdminString, = SnmpEngineID       FROM = SNMP-FRAMEWORK-MIB
    MODULE-COMPLIANCE, = OBJECT-GROUP     FROM SNMPv2-CONF   =
    nlmLogName =         =         =         =         =         =         FROM NOTIFICATION-LOG-MIB; =

   activeAlarm MODULE-IDENTITY
       LAST-UPDATED = "000005290000Z"
       ORGANIZATION = "Active Alarm MIB"
       = CONTACT-INFO
          &nb= sp;    "   Sharon Chisholm
          &nb= sp;        Nortel Networks
          &nb= sp;        PO Box 3511 Station = C
          &nb= sp;        Ottawa, Ont. K1Y = 4H7
          &nb= sp;        Canada

          &nb= sp;        = schishol@nortelnetworks.com"
       = DESCRIPTION
          &nb= sp;    "The MIB module describes a generic = solution
          &nb= sp;    to improve the reliability of SNMP traps by = storing the
          &nb= sp;    current list of active alarms."
       ::=3D { = somewhere XX }

--
-- Active Alarm Table
--

activeAlarmObjects OBJECT IDENTIFIER ::=3D { = activeAlarm 1 }

activeAlarmTable OBJECT-TYPE
    = SYNTAX      SEQUENCE OF = ActiveAlarmEntry
    MAX-ACCESS = not-accessible
    = STATUS      current
    DESCRIPTION
        "A = table of Active Alarms entries."
    ::=3D { activeAlarmObjects 1 = }

activeAlarmEntry OBJECT-TYPE
    = SYNTAX      ActiveAlarmEntry
    MAX-ACCESS = not-accessible
    = STATUS      current
    DESCRIPTION
        = "Entries appear in this table when faults are active. They = are

removed = when the fault is not longer occurring."
= INDEX { nlmLogName, = activeAlarmIndex }

::=3D { activeAlarmTable 1 = }

ActiveAlarmEntry ::=3D SEQUENCE {
    = activeAlarmIndex         &n= bsp;       Unsigned32,
    = activeAlarmTime         &nb= sp;        TimeStamp,
    = activeAlarmDateAndTime        &n= bsp; DateAndTime,
    = activeAlarmEngineID         = ;     SnmpEngineID,
    = activeAlarmEngineAddress        = IpAddress,
    = activeAlarmContextEngineID       = SnmpEngineID,
    = activeAlarmContextName        &n= bsp; SnmpAdminString,
    = activeAlarmVariables        &nbs= p;    Unsigned32,
    = activeAlarmNotificationID        = OBJECT IDENTIFIER,
    activeAlarmLogIndex =             =          Unsigned32
}

activeAlarmIndex OBJECT-TYPE
    SYNTAX     = Unsigned32 (1..4294967295)
    MAX-ACCESS read-only
    STATUS     = current
    DESCRIPTION
        "A = monotonically increasing integer which acts as the
        index of = entries within the named alarm list. It wraps
        back to 1 = after it reaches its maximum value."
    ::=3D { activeAlarmEntry 1 = }

activeAlarmTime OBJECT-TYPE
    = SYNTAX      TimeStamp
    MAX-ACCESS read-only
    = STATUS      current
    DESCRIPTION
        "The = value of sysUpTime when the alarm occurred. Alarms get
        cleared = and resent if still applicable at reboot, so this
        value is = always a valid sysUptime."
    ::=3D { activeAlarmEntry 2 = }

activeAlarmDateAndTime OBJECT-TYPE
    = SYNTAX      DateAndTime
    MAX-ACCESS read-only
    = STATUS      current
    DESCRIPTION
        "The = local date and time when the alarm occurred, instantiated
        only by = systems that have date and time capability."
    ::=3D { activeAlarmEntry 3 = }

activeAlarmEngineID OBJECT-TYPE
    = SYNTAX      SnmpEngineID
    MAX-ACCESS read-only
    = STATUS      current
    DESCRIPTION
        "The = identification of the SNMP engine at which the alarm
        = originated.
        If the = alarm list can contain Notifications from only one
        engine or = the Trap is from an SNMPv1 system, this object is not
        = instantiated."

::=3D { activeAlarmEntry 4 = }

activeAlarmEngineAddress OBJECT-TYPE
= SYNTAX IpAddress

    MAX-ACCESS read-only
    = STATUS      current
    DESCRIPTION
     "The IP Address of the = SNMP engine on which the alarm is
     occurring. This is used to = identify the source of an SNMPv1
     trap, since an = nlmLogEngineId cannot be extracted from the
     SNMPv1 trap pdu.

     This object MUST always be = instantiated, even if the list
     can contain alarms from = only one engine."
    ::=3D { activeAlarmEntry 5 = }

activeAlarmContextEngineID OBJECT-TYPE
    = SYNTAX      SnmpEngineID
    MAX-ACCESS read-only
    = STATUS      current
    DESCRIPTION
     "If the alarm is = occurring on a device using a protocol which
     has a contextEngineID = element like SNMPv3, this object has that
     value. Otherwise its value = is a zero-length string."
    ::=3D { activeAlarmEntry 6 = }

activeAlarmContextName OBJECT-TYPE
    = SYNTAX      SnmpAdminString
    MAX-ACCESS read-only
    = STATUS      current
    DESCRIPTION
        "The = name of the SNMP MIB context from which the alarm came.
        For = SNMPv1 Traps this is the community string from the Trap.
        If the = alarm's source SNMP engine is known not to support
        multiple = contexts, this object is not instantiated."
    ::=3D { activeAlarmEntry 5 = }

activeAlarmVariables OBJECT-TYPE
    = SYNTAX      Unsigned32
    MAX-ACCESS read-only
    = STATUS      current
    DESCRIPTION
        "The = number of variables in activeAlarmVariableTable for this
        = Notification."
    ::=3D { activeAlarmEntry 6 = }

activeAlarmNotificationID OBJECT-TYPE
    = SYNTAX      OBJECT IDENTIFIER
    MAX-ACCESS read-only
    = STATUS      current
    DESCRIPTION
        "The = NOTIFICATION-TYPE object identifier of the Notification that
        = occurred."
    ::=3D { activeAlarmEntry 7 = }

activeAlarmLogIndex OBJECT-TYPE
    SYNTAX     = Unsigned32 (0..4294967295)
    MAX-ACCESS read-only
    STATUS     = current
    DESCRIPTION
        = "This number can be considered a sequence number for the = trap.
        It should = be the same of the log index in the notification log MIB,
        if = used. If no log index or sequence number applies to the = trap,
        then this = object should have the value of 0."
    ::=3D { activeAlarmEntry 8 = }

--
-- Active Alarm Variable Table
--

activeAlarmVariableTable OBJECT-TYPE
    = SYNTAX      SEQUENCE OF = ActiveAlarmVariableEntry
    MAX-ACCESS = not-accessible
    = STATUS      current
    DESCRIPTION
        "A = table of variables to go with active alarm entries."
    ::=3D { activeAlarmObjects 2 = }

activeAlarmVariableEntry OBJECT-TYPE
    = SYNTAX      ActiveAlarmVariableEntry
    MAX-ACCESS = not-accessible
    = STATUS      current
    DESCRIPTION
        = "Entries appear in this table when there are variables in
        the = varbind list of a corresponding alarm in activeAlarmTable."
    INDEX   { = nlmLogName, activeAlarmIndex, activeAlarmVariableIndex }
    ::=3D { activeAlarmVariableTable = 1 }

ActiveAlarmVariableEntry ::=3D SEQUENCE {
    = activeAlarmVariableIndex        =          Unsigned32,
    = activeAlarmVariableID        &nb= sp;           OBJECT = IDENTIFIER,
    = activeAlarmVariableValueType       &n= bsp;     INTEGER,
    = activeAlarmVariableCounter32Val       = ;   Counter32,
    = activeAlarmVariableUnsigned32Val      &nbs= p; Unsigned32,
    = activeAlarmVariableTimeTicksVal       = ;   TimeTicks,
    = activeAlarmVariableInteger32Val       = ;   Integer32,
    = activeAlarmVariableOctetStringVal      &nb= sp; OCTET STRING,
    = activeAlarmVariableIpAddressVal       = ;   IpAddress,
    = activeAlarmVariableOidVal        = ;        OBJECT IDENTIFIER,
    = activeAlarmVariableCounter64Val       = ;   Counter64,
    = activeAlarmVariableOpaqueVal       &n= bsp;     Opaque
}

activeAlarmVariableIndex OBJECT-TYPE
    SYNTAX     = Unsigned32 (1..4294967295)
    MAX-ACCESS not-accessible
    STATUS     = current
    DESCRIPTION
        "A = monotonically increasing integer, starting at 1 for a given
        = activeAlarmIndex, for indexing variables within the active
        alarm = list."
    ::=3D { activeAlarmVariableEntry = 1 }

activeAlarmVariableID OBJECT-TYPE
    SYNTAX     = OBJECT IDENTIFIER
    MAX-ACCESS read-only
    STATUS     = current
    DESCRIPTION
        "The = variable's object identifier."
    ::=3D { activeAlarmVariableEntry = 2 }

activeAlarmVariableValueType OBJECT-TYPE
    = SYNTAX      INTEGER { counter32(1), = unsigned32(2), timeTicks(3),
          &nb= sp;           &nb= sp;   integer32(4), ipAddress(5), octetString(6),
          &nb= sp;           &nb= sp;   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 is used, based on this type."
    ::=3D { activeAlarmVariableEntry = 3 }

activeAlarmVariableCounter32Val OBJECT-TYPE
    = SYNTAX      Counter32
    MAX-ACCESS read-only
    = STATUS      current
    DESCRIPTION
        "The = value when activeAlarmVariableType is 'counter32'."
    ::=3D { activeAlarmVariableEntry = 4 }

activeAlarmVariableUnsigned32Val OBJECT-TYPE
    = SYNTAX      Unsigned32
    MAX-ACCESS read-only
    = STATUS      current
    DESCRIPTION
        "The = value when activeAlarmVariableType is 'unsigned32'."
    ::=3D { activeAlarmVariableEntry = 5 }

activeAlarmVariableTimeTicksVal OBJECT-TYPE
    = SYNTAX      TimeTicks
    MAX-ACCESS read-only
    = STATUS      current
    DESCRIPTION
        "The = value when activeAlarmVariableType is 'timeTicks'."
    ::=3D { activeAlarmVariableEntry = 6 }

activeAlarmVariableInteger32Val OBJECT-TYPE
    = SYNTAX      Integer32
    MAX-ACCESS read-only
    = STATUS      current
    DESCRIPTION
        "The = value when activeAlarmVariableType is 'integer32'."
    ::=3D { activeAlarmVariableEntry = 7 }

activeAlarmVariableOctetStringVal OBJECT-TYPE
    = SYNTAX      OCTET STRING
    MAX-ACCESS read-only
    = STATUS      current
    DESCRIPTION
        "The = value when activeAlarmVariableType is 'octetString'."

::=3D { activeAlarmVariableEntry 8 = }

activeAlarmVariableIpAddressVal OBJECT-TYPE
    = SYNTAX      IpAddress
    MAX-ACCESS read-only
    = STATUS      current
    DESCRIPTION
        "The = value when activeAlarmVariableType is 'ipAddress'."
    ::=3D { activeAlarmVariableEntry = 9 }

activeAlarmVariableOidVal OBJECT-TYPE
    = SYNTAX      OBJECT IDENTIFIER
    MAX-ACCESS read-only
    = STATUS      current
    DESCRIPTION
        "The = value when activeAlarmVariableType is 'objectId'."
    ::=3D { activeAlarmVariableEntry = 10 }

activeAlarmVariableCounter64Val OBJECT-TYPE
    = SYNTAX      Counter64
    MAX-ACCESS read-only
    = STATUS      current
    DESCRIPTION
        "The = value when activeAlarmVariableType is 'counter64'."
    ::=3D { activeAlarmVariableEntry = 11 }

activeAlarmVariableOpaqueVal OBJECT-TYPE
    = SYNTAX      Opaque
    MAX-ACCESS read-only
    = STATUS      current
    DESCRIPTION
        "The = value when activeAlarmVariableType is 'opaque'."
    ::=3D { activeAlarmVariableEntry = 12 }

--
-- Statistics
--
activeAlarmStatsTable OBJECT-TYPE
       SYNTAX = SEQUENCE OF ActiveAlarmStatsEntry
       = MAX-ACCESS not-accessible
       STATUS = current
       = DESCRIPTION
          = "This table represents the alarm statistics type
          = information."
        ::=3D { = activeAlarmObjects 3 }

   activeAlarmStatsEntry OBJECT-TYPE
       SYNTAX = ActiveAlarmStatsEntry
       = MAX-ACCESS not-accessible
       STATUS = current
       = DESCRIPTION
          = "Statistics on the current active alarms."

= INDEX { nlmLogName }

::=3D = { activeAlarmStatsTable 1 }

   ActiveAlarmStatsEntry ::=3D
       SEQUENCE = {
          &nb= sp; activeAlarmStatsTotalActive    Unsigned32
          &nb= sp;      }

activeAlarmStatsTotalActive OBJECT-TYPE
       SYNTAX = Unsigned32
       MAX-ACCESS = read-only
       STATUS = current
       = DESCRIPTION
          = "The total number of currently active alarms on the system." =

::=3D { = activeAlarmStatsEntry 1 }

         =
     -- Conformance Stuff

     activeAlarmConformance = OBJECT IDENTIFIER ::=3D { activeAlarm 2 }

         = activeAlarmListGroup OBJECT-GROUP
         =        OBJECTS {
        =         activeAlarmIndex,
        =         activeAlarmTime,
        =         = activeAlarmDateAndTime,
        =         = activeAlarmEngineID,     =        =
          &nb= sp; activeAlarmEngineAddress,
          &nb= sp; activeAlarmContextEngineID,
        =         = activeAlarmContextName,
        =         activeAlarmVariables,
        =         = activeAlarmNotificationID,
        =         activeAlarmLogIndex,
        =         = activeAlarmVariableIndex,
        =         = activeAlarmVariableID,
        =         = activeAlarmVariableValueType,
        =         = activeAlarmVariableCounter32Val,
        =         = activeAlarmVariableUnsigned32Val,
        =         = activeAlarmVariableTimeTicksVal,
        =         = activeAlarmVariableInteger32Val,
        =         = activeAlarmVariableOctetStringVal,
        =         = activeAlarmVariableIpAddressVal,
        =         = activeAlarmVariableOidVal,
        =         = activeAlarmVariableCounter64Val,
        =         = activeAlarmVariableOpaqueVal        &= nbsp;
         =        =       }
         =           STATUS   = current
           = DESCRIPTION
          &nb= sp;     "Active Alarm list group."
           = ::=3D { activeAlarmConformance 2}

     = activeAlarmSummaryGroup OBJECT-GROUP
           = OBJECTS {
          &nb= sp;         = activeAlarmStatsTotalActive
          &nb= sp;          }

           = STATUS   current
           = DESCRIPTION
          &nb= sp;     " Active alarm summary = group."
           = ::=3D { activeAlarmConformance 3}

activeAlarmCompliance MODULE-COMPLIANCE
       STATUS = current
       = DESCRIPTION
           = "The compliance statement for systems supporting Active
           = Alarm MIB."
       MODULE -- this = module
           = MANDATORY-GROUPS {
          &nb= sp; activeAlarmListGroup
           = }
           = GROUP activeAlarmSummaryGroup
           = DESCRIPTION
           = "The actual active alarms."

::=3D { = activeAlarmConformance 1 }
=20
END
6. Example

        Define the = following Object:
        = acmeWidgetIndex OBJECT-TYPE
            SYNTAX Integer32
            MAX-ACCESS read-only
            STATUS   current
            DESCRIPTION
              "A unique number which = identifies a particular Widget."
        = ::=3D { acmeWidgetEntry 1 }

        Define = the following three traps:
        = acmeWidgetTemperatureCritical NOTIFICATION-TYPE
            OBJECTS { acmeWidgetIndex }
            STATUS      = current
            DESCRIPTION
              "This trap indicates that = the indicated
        =         widget has = reached a critical temperature."
        = ::=3D { acmeWidgetTraps 1 }

        = acmeWidgetTemperatureNormal NOTIFICATION-TYPE
            OBJECTS { acmeWidgetIndex }
            STATUS      = current
            DESCRIPTION
              "This trap indicates that = the indicated widget has
        =         reached a = normal temperature."
        = ::=3D { acmeWidgetTraps 2 }

        = bgpBackwardTransition NOTIFICATION-TYPE
          &nb= sp; OBJECTS { bgpPeerLastError,
          &nb= sp;           = bgpPeerState      }
          &nb= sp; STATUS current
          &nb= sp; DESCRIPTION
          &nb= sp;    "The BGPBackwardTransition Event is = generated
          &nb= sp;    when the BGP FSM moves from a higher = numbered

&nb= sp; state to a lower numbered state."
= ::=3D { bgpTraps 2 }

        0. Active = alarm table empty and nothing in notification log
        =          = ___________________________      = _____________________
        =         | = activeAlarmTable          = |    | = nlmLogTable         |
        =         |---------------------------|    = |---------------------|
        =         | = activeAlarmIndex | alarm |    | nlmLogIndex | = alarm |
        =         |---------------------------|    = |---------------------|
        =         |___________________________|    = |_____________________|

        1. = Temperature of widget 2 goes critical
        =          = __________________________________________________
        =         | = activeAlarmTable         &n= bsp;           &n= bsp;           = |
        =         |--------------------------------------------------|  = ;
        =         | = activeAlarmIndex | = alarm           &= nbsp;            = |
        =         |--------------------------------------------------|  = ;
        =         |        = 1         | = acmeWidgetTemperatureCritical |
        =         |__________________________________________________| =

        =          = _____________________________________________
        =         | = nlmLogTable          &= nbsp;           &= nbsp;          = |
        =         |---------------------------------------------|  &nbs= p;
        =         | nlmLogIndex = | = alarm           &= nbsp;            = |
        =         |---------------------------------------------|  &nbs= p;
        =         |      = 1      | acmeWidgetTemperatureCritical = |
        =         |_____________________________________________|

        2. BGP = peering session transitions from a state of established
         = ; to opensent
        =          = __________________________________________________
        =         | = activeAlarmTable         &n= bsp;           &n= bsp;           = |
        =         |--------------------------------------------------|  = ;
        =         | = activeAlarmIndex | = alarm           &= nbsp;            = |
        =         |--------------------------------------------------|  = ;
        =         |        = 1         | = acmeWidgetTemperatureCritical |
        =         |        = 2         | = bgpBackwardTransition         = |
        =         |__________________________________________________| =

        3. = Temperature of widget 2 goes back to normal
        =          = __________________________________________________
        =         | = activeAlarmTable         &n= bsp;           &n= bsp;           = |
        =         |--------------------------------------------------|  = ;
        =         | = activeAlarmIndex | = alarm           &= nbsp;            = |
        =         |--------------------------------------------------|  = ;
        =         |        = 2         | = bgpBackwardTransition         = |

= |__________________________________________________| =

4. Time = passes .... BGP alarm ages out.

        =          = __________________________________________________
        =         | = activeAlarmTable         &n= bsp;           &n= bsp;           = |
        =         |--------------------------------------------------|  = ;
        =         | = activeAlarmIndex | = alarm           &= nbsp;            = |
        =         |--------------------------------------------------|  = ;
        =         |__________________________________________________| =

7. Security Considerations

   There are no management objects defined = in this MIB that have a MAX-
   ACCESS clause of read-write and/or = read-create. So, if this MIB is
   implemented correctly, then there is no = risk that an intruder can
   alter or create any management objects = of this MIB via direct SNMP
   SET operations.

8. Author's Address

   Sharon Chisholm
   Nortel Networks
   PO Box 3511, Station C
   Ottawa, Ontario, K1Y 4H7
   Canada

Email: = schishol@nortelnetworks.com

9. References
[1] Stewart, = B, "Notification Log MIB, draft 12, October 1999 =
=20
10. Full Copyright Statement

This document and translations of it may be copied = and furnished to
others, and derivative works that comment on or = otherwise explain it or
assist in its implementation may be prepared, = copied, published and
distributed, in whole or in part, without = restriction of any kind,
provided that the above copyright notice and this = paragraph are included
on all such copies and derivative works. = However, this document itself
may not be modified in any way, such as by removing = the copyright notice
or references to the Internet Society or other = Internet organizations,
except as needed for the purpose of developing = Internet standards in
which case the procedures for copyrights defined in = the Internet
Standards process must be followed, or as required = to translate it into
languages other than English.

The limited permissions granted above are perpetual = and will not be
revoked by the Internet Society or its successors or = assigns.

This document and the information contained herein is = provided on an "AS
IS" basis and THE INTERNET SOCIETY AND THE = INTERNET ENGINEERING TASK
FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, = INCLUDING BUT NOT
LIMITED TO ANY WARRANTY THAT THE USE OF THE = INFORMATION HEREIN WILL NOT
INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF = MERCHANTABILITY OR
FITNESS FOR A PARTICULAR PURPOSE.

------_=_NextPart_001_01C0014A.AF7D8360-- From owner-disman@dorothy.peer.com Tue Aug 8 13:59:36 2000 Received: from tattler.bmc.com (fw-us-hou-2.bmc.com [198.207.223.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25951 for ; Tue, 8 Aug 2000 13:59:35 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.8.6) with ESMTP id e78HrEu22387; Tue, 8 Aug 2000 12:53:14 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id KAA28428 for disman-list; Tue, 8 Aug 2000 10:52:10 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id KAA28422; Tue, 8 Aug 2000 10:52:04 -0700 (PDT) Received: from fw-us-hou1.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.8.6) with SMTP id e78HqNl22220; Tue, 8 Aug 2000 12:52:23 -0500 (CDT) Received: from scoya.cnri.reston.va.us (scoya.cnri.reston.va.us [10.27.5.106]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22068; Tue, 8 Aug 2000 13:52:12 -0400 (EDT) Date: Tue, 8 Aug 2000 13:50:44 -0400 (Eastern Daylight Time) From: Steve Coya To: Sharon Chisholm cc: Randy Presuhn , disman@dorothy.peer.com Subject: RE: Distributed Active Alarms In-Reply-To: <6DDA62170439D31185750000F80826AC033BD8D4@zmerd004.ca.nortel.com> Message-ID: X-X-Sender: scoya@odin.cnri.reston.va.us MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id NAA22068 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by dorothy.bmc.com id KAA28423 Sender: owner-disman@dorothy.peer.com Precedence: bulk List-Id: IETF disman Working Group mailing list Content-Transfer-Encoding: 8bit Hi Sharon, I'm not sure where all this left off, other than you were going to submit a document to internet-drafts@ietf.org What _I_ need from you is some sort of statement pertaining to your intentions that can be posted on the IETF's IPR Web page. You may wish to view the statements made by others at http://www.ietf.org/ipr.html. Steve On Mon, 24 Jul 2000, Sharon Chisholm wrote: >>hi >> >>The patent which may apply to this was recently filed, so we don't >>have a number yet. I just have the information that I sent you and Steve >>before. I can clean up the document as per "Guidelines to Authors of >>Internet-Drafts" >>and send it to internetdrafts@ietf.org to get a tangible file name to >>refer to in the web page to comply with RFC 2026 section 10.3.2 (c). Or did >>you want something sooner? >> >>Newby question 1: Is all that is required in the internet draft pertaining >>to intellectual property a statement of compliance with RFC 2026, section >>10? >> >>Newby question 2: Is this an individual submission internet draft or a >>working >>group internet draft? My goal would be for it to be a working group >>internet >>draft, but somehow I feel I would be skipping a step if I called it that. >> >>I think I missed the deadline for getting something sent out before the >>meeting >>next week, but I will try and get something sent out this week anyways. >> >>Sharon >> >>-----Original Message----- >>From: Randy Presuhn [mailto:rpresuhn@dorothy.peer.com] >>Sent: Monday, July 24, 2000 1:27 PM >>To: disman@dorothy.peer.com >>Subject: Re: Distributed Active Alarms >> >> >> >>Hi - >> >>> Message-ID: >><6DDA62170439D31185750000F80826AC032A2F2F@zmerd004.ca.nortel.com> >>> From: "Sharon Chisholm" >>> To: disman@dorothy.bmc.com >>> Subject: Distributed Active Alarms >>> Date: Mon, 17 Jul 2000 14:25:05 -0400 >>... >>> Here is some work I have done which applies the infrastructure used >>> in the Notification Log MIB to a different problem. The problem it >>> is trying to address is the fact there is no standard way to determine >>> device alarm state when you first discover it, or after you regain >>> communication with it after a communication blackout. >>> >>> The format is still a bit rough, but is hopefully readable. I think >>> this work makes sense within this working group, so hopefully this >>> is something you find interesting enough for us to proceed with. >>> >>> Please let me know what you think. >>... >> >>I'll add this to the agenda for the Pittsburgh meeting. >>Will an internet draft be appearing? >> >>Since there are patent claims (could you supply the number >>or a URL for the patent?), please review the requirements of >>RFC 2026, in particular: >> >> clause 4.1.2 first paragraph >> clause 10.3.2 (A) >> clause 10.4 >> >> ------------------------------------------------------- >> Randy Presuhn randy_presuhn@bmc.com >> Voice: +1 408 546-1006 BMC Software, Inc. 1-3141 >> Fax: +1 408 965-0359 2141 North First Street >> http://www.bmc.com/ San José, California 95131 USA >> ------------------------------------------------------- >> My opinions and BMC's are independent variables. >> ------------------------------------------------------- >> From owner-disman@dorothy.peer.com Tue Aug 8 20:44:14 2000 Received: from tattler.bmc.com (fw-us-hou-2.bmc.com [198.207.223.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03660 for ; Tue, 8 Aug 2000 20:44:14 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.8.6) with ESMTP id e790csI28741; Tue, 8 Aug 2000 19:38:54 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id RAA02092 for disman-list; Tue, 8 Aug 2000 17:38:02 -0700 (PDT) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id RAA02084; Tue, 8 Aug 2000 17:37:58 -0700 (PDT) Date: Tue, 8 Aug 2000 17:37:58 -0700 (PDT) From: Randy Presuhn Message-Id: <200008090037.RAA02084@dorothy.bmc.com> To: klerer@nortelnetworks.com Subject: RE: JointNM Cc: disman@dorothy.peer.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-disman@dorothy.peer.com Precedence: bulk List-Id: IETF disman Working Group mailing list Content-Transfer-Encoding: 7bit Hi Mark - > Message-ID: <6DDA62170439D31185750000F80826AC035F4E5F@zmerd004.ca.nortel.com> > From: "Sharon Chisholm" > To: "Wijnen, Bert (Bert)" > Cc: Randy Presuhn , > "Mark Klerer" , > Frank Peeters > Subject: RE: JointNM > Date: Tue, 8 Aug 2000 09:52:30 -0400 ... > I'd love to present my Active Alarm work, but unfortunately > I can't make it to California this week. Mark has volunteered > to present the information for me. I will also be submitting > my internet draft later today. I am actually subscribed to the > joint NM list, so I can forward the draft there and people can > post questions and suggestions there as well. ... If there are any comments, minutes, or whatever from the JointNM meeting that would aid the IETF disman working group in deciding whether to recommend taking this on as a work item, please forward them to the WG mailing list at ------------------------------------------------------- Randy Presuhn randy_presuhn@bmc.com Voice: +1 408 546-1006 BMC Software, Inc. 1-3141 Fax: +1 408 965-0359 2141 North First Street http://www.bmc.com/ San José, California 95131 USA ------------------------------------------------------- My opinions and BMC's are independent variables. ------------------------------------------------------- From owner-disman@dorothy.peer.com Wed Aug 9 09:28:26 2000 Received: from tattler.bmc.com (fw-us-hou-2.bmc.com [198.207.223.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27781 for ; Wed, 9 Aug 2000 09:28:16 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.8.6) with ESMTP id e79DNNS27195; Wed, 9 Aug 2000 08:23:23 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id GAA03239 for disman-list; Wed, 9 Aug 2000 06:21:37 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id GAA03234 for ; Wed, 9 Aug 2000 06:21:31 -0700 (PDT) Received: from fw-us-hou1.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.8.6) with SMTP id e79DLlM26912 for ; Wed, 9 Aug 2000 08:21:48 -0500 (CDT) Received: from aix43.snmp.com (aix43.snmp.com [192.147.142.137]) by seymour39.SNMP.COM (8.9.3/m.000221) with ESMTP id JAA28305 for ; Wed, 9 Aug 2000 09:22:14 -0400 (EDT) Received: from aix43.snmp.com (LOCALHOST [127.0.0.1]) by aix43.snmp.com (8.9.3/snmpclient.mc-990615) with ESMTP id JAA18968 for ; Wed, 9 Aug 2000 09:22:13 -0400 Message-Id: <200008091322.JAA18968@aix43.snmp.com> to: disman@dorothy.peer.com Subject: IETF48 DISMAN Working Group Minutes Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Date: Wed, 09 Aug 2000 09:22:13 -0400 From: Steve Moulton Sender: owner-disman@dorothy.peer.com Precedence: bulk List-Id: IETF disman Working Group mailing list Content-Transfer-Encoding: 8bit The proposed minutes for the meeting of the DISMAN working group at the 48th IETF (Pittsburgh) follow. Please send any corrections to moulton@snmp.com by Tuesday, August 15.. I will submit the minutes with agreed-upon changes by the minutes deadline. --- Steve Moulton SNMP Research, Inc voice: +1 865 573 1434 Sr Software Engineer 3001 Kimberlin Heights Rd. fax: +1 865 573 9197 moulton@snmp.com Knoxville, TN 37920-9716 USA http://www.snmp.com ---------------------------------------------------------------------- The DISMAN (Distributed Management) working group met on Monday, July 31, during the 48th IETF. This working group meeting was chaired by Randy Presuhn. There were approximately 80 people present. The agenda slides are available at ftp://amethyst.bmc.com/pub/disman/ietf48/ietf48-disman-agenda.ppt This working group meeting was reported by Steve Moulton (moulton@snmp.com). The first major item on the agenda was the usual administrivia. Juergen Schoenwaelder was recognized by the chair. Steve Moulton agreed to take minutes. Attendees were asked to sign the blue sheets. The agenda was reviewed, and no changes were requested. During the allocation of time, Sharon Chisholm requested 1/2 hour, Juergen Schoenwaelder requested 1/2 hour and Bob Cole requested some time to make a report from the RMONMIB working group. The second major item on the agenda was the Status of Current Work. There are updates pending to the script and schedule MIBs, which were discussed later in this meeting. The notification/log MIB, event MIB, and expression MIB have completed IETF last call. The remote operations MIB is in the RFC editor's queue. The third major item on the agenda was other work in progress related to DISMAN. There was a brief report on the RPERFMON BOF at the 47th IETF in Adelaide, where the idea of using synthetic sources for performance measurement was discussed. This work is now being examined in the RMONMIB working group. Bob Cole made a presentation (summarized below) on the SSPM framework. The SNMPCONF presentation was omitted; those interested were referred to the SNMPCONF Working Group meeting to take place later in the week. Bob Cole made a presentation on SSPM (slides are available as ftp://amethyst.bmc.com/pub/disman/ietf48/sspm_pitts.ppt). The basic concept revolves around using synthetic data sources for performance measurement. Mention was made of the SSPM framework document (draft-cole-sspm-00.txt) and Carl Kalbfleisch's MIB document discussing how you might set up the probes (draft-kalbfleisch-sspmmib-00.txt). Mention was made (with out explanation of the acronyms) of several activities taking place in the RMONMIB working group, specifically, SSPM, APM/TPM, the use of the schedule MIB, and PMCAPS. Bob presented presented several slides, including a fairly complex slide showing performance measurement architecture. In Adelaide, there were several issues presented using this architecture slide, including measurement and control protocols. The IPPM (IP Performance Metrics) folks will talk about producing a new protocols for measurement and control. No attempt is made to reproduce the slides here. One comment was made, whereby the full protocol stack requirement for SSPM has been declared a non-issue. Dan Romascanu discussed the Indexing and Distributing aggregation issues. The fourth major agenda area was discussions on technical issues. The first item, closing remaining RFC2591 (schedule MIB) and RFC2592 (script MIB) issues, was presented by Juergen Schoenwaelder. The associated documents are draft-ietf-disman-schedule-mib-v2-01.txt and draft-ietf-disman-script-mib-v2-01.txt. The slides are in ftp://amethyst.bmc.com/pub/disman/ietf48/disman-issues.ps. No attempt to replicate the slides is made here. Juergen Schoenwaelder made the presentation. Issue 04 (schedule MIB): the proposal to automatically disable failing schedules. [Names are given when the minute taker recognized the person asking questions. The dialogue has been edited some to reduce length.] Russell Dietz: When does the script get turned back on? Juergen: I don't know, probably never. Russell: Will it be the default behavior to turn off the script after a certain number of failures? Juergen:: No. The default will be to do nothing. David Harrington: My feeling is that it should be a separate piece, as not everyone will want it. This may be a policy issue and therefore belongs in SNMPCONF. Randy Presuhn: You have to appeal to a higher intelligence to both turn stuff off and to turn stuff back on. Any vendors have any comments? Russell: There are a couple of products out there that have some combination of reporting the failure and stopping the script. You should probably report the failure and let a higher authority shut off the script. Randy: is this a major or minor issue? David H: this is a minor issue. Parts can be handled elsewhere. Randy: Lets break this down. Should this capability be in the schedule MIB or in another special MIB? (floor): we could do all of this in the script or event MIBs. The general purpose mechanisms are in place. Do we need to build special purpose mechanisms into the script MIB to do this? David H: There are several issues that will come up on this that have not come up yet. How do you handle various success/failure patterns? There may be a lot more work in this than is apparent. Russ Mundy: are people deploying this with nothing around it that can deal with failure? (no response) randy: Does anyone strongly believe we need to add this to this MIB? (no response) Bert: Should we recycle this document at proposed? Randy: If we do not make this change, we can proceed to draft status. We will ask on the mailing list if there is any support for this. If not, then we will not do it. Issue 05 (script MIB) is to replace the indices on the smLangTable and smExtsnTable with textual indices (by name). This would require the deprecation of these tables. Are the benefits worth the cost of the change? The chair asked if anyone be upset if we did not change? (no response). This validates the consensus from the working group mailing list. Issue 06 (script MIB): Dependencies between scripts and scripts versioning. The MIB does not model inter-script dependencies (script b requires that script a is present and enabled) nor does it provide explicit support for multiple versions of a script. The comment was made that this problem probably belongs in the management station, not in the agent. David Harrington raised the point that some sort of version control can be done in the script naming, i.e. "script_1.1_for_IOS_v2.3". The consensus was to not change the tables. Issue 07 (script MIB): Storage type of script code vs. script meta information. Is there a difference between the script storage type and the storage type of the script meta information? Juergen: This is probably a documentation issue in the MIB. Randy: There may be an association between the script table storage type and the persistence of the script itself. Clear as mud? (yes). Juergen: we don't think this is a problem in the MIB definition, but in the documentation. OK with group? (no response). Consensus is that it is OK. Issue 10 (script MIB): Script editing in the smCodeTable. The script MIB provides basic script editing capabilities via SNMP set operations. Implementation of the feature adds costs while the utility of this feature is questionable. [this is an enumerated value of the smScriptAdminStatus object -ed]. Should we try to simplify by taking this feature out? There are known cases where this prevented implementation of the smCodeTable. Randy: We should make the "editing" enumerated value of this object not necessary to claim conformance in the compliance statement. In other words, we would make the editing function optional. This wording will get set out to the mailing list for comment and approval. Issue 11 (script MIB): Resource consumption indication in smRunTable. It would be nice to have some sort of indication of this (cpu consumption or memory consumption). Is it possible to define metrics that are semantically meaningful and generally implementable. Among other problems, this will require OS support and will be very implementation dependent. In particular, implementations that have all scripts executed by one script engine makes this information not available. All possible solutions can be pursued without requiring modifications to the current document. (floor): are you suggesting we have a script resource MIB later and let this document continue? (there was no disagreement to this proposal). Steve Moulton: When discussing this new MIB, we need to bear in mind that the unit of granularity may be the entire MIB engine. Randy Presuhn: Yes. Issue 16 (script MIB): Suspend/resume on runtime engines that do not support it. The current specification says that the running script remains in the suspending (resuming) state when the runtime is not capable to suspend (resume) a script. This makes it impossible to determine on the manager side whether the suspend (resume) just takes a long time to complete or is not supported. A solution would be to go from transient suspending state back into the running state when the runtime can not suspend a script. Randy Presuhn: The issue is to disambiguate between something that takes a long time to suspend and the case where the script engine just cannot suspend the script. The suspend object needs to have a way to return the "can't suspend" case. Disambiguating into three cases 1) Engine just can't suspend script. Return error value to set. We can do this, no big deal. 2) Script just won't be suspended. Is this a real problem? No. This is a engine debugging issue. 3) Someone else reawakens script. (use access control, multiple manager-type solutions). This item was brought to the working group's attention as the input from the mailing list was inconclusive. The sense of the room is that no action need be taken, but the question needs to be put to the mailing list for any final comment. The next technical discussion item was a discussion of distributed active alarms by Sharon Chisholm. The slides are available as ftp://amethyst.bmc.com/pub/disman/ietf48/IETF48_DISMAN_presentation.ppt. No attempt to summarize the slides has been made here. A draft of this work has been posted to the DISMAN mailing list. One issue driving this work is that due to a trap storm or other events, alarms may be pushed off of the end of the notification/log MIB. The following questions were asked: (floor): Are alarms associated with physical entities? Sharon: Not necessarily. Alarms can come from logical devices, too. An alarm is anything you want to fix. Randy: How do you decide what is interesting? Sharon: There is currently no way to determine/filter. (floor): How do you determine what alarms the device supports, and how do you determine what alarms you register for? Sharon: This depends on the site. There are several questions about deciding what notifications are active alarms. (floor): Why is this in DISMAN? Sharon: There is a industry requirement for this type of functionality, and we need a standard framework to deal with it. The fifth agenda items have to do with working group business. A charter update removing Bob Stewart [who has retired -ed] has been requested, as well as updating target dates for script and schedule MIBs. A working group last call for these MIBs starting September 14, 2000 was proposed without objection. The issue of script MIB extensibility (RFC2593, experimental) was brought to the working group's attention to see if it required any action, such as moving onto the standards track. There were no comments, indicating that no action need be taken. The question was raised about whether we take on alarms (cf. Sharon Chisholm's work). At least on person requests that we do. The issue of intellectual property in this work was raised. Sharon asserted that Nortel is working on releasing IP claims on the alarm MIB. David Harrington asked whether this is a DISMAN or a SNMPv3 issue? Russ Mundy responded that he was not sure, but that it looked like a general SNMP issue. David Perkins observed that there is a CMIP framework model that handles this problem, and, since this problem comes up so often, we ought to look into it. Randy Presuhn stated that this will be taken to the mailing list, and advised Bert Wijnen to be prepared for a charter update for an additional work item. Bert stated that we need to decide whether this should go into DISMAN or SNMPv3. Dan Romascanu expressed interest in taking on this work. Upon request for a list of additional work items Dan Romascanu requested we look into synchronization with remote performance management, and a resource consumption MIB. The final agenda item was Working Group meeting wrap up. A review of action items included: . mailing list: add item regarding self killing schedules. . Sharon Chisholm's work will be discussed as a possible charter update. . mailing list: submit compliance text for smCodeTable, schedule working group last call for September. Randy reminded note takers to follow the guidelines and presenters to submit their slides, and all participants to sign the blue sheets and return them. From owner-disman@dorothy.peer.com Wed Aug 9 10:21:13 2000 Received: from tattler.bmc.com (fw-us-hou-2.bmc.com [198.207.223.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01522 for ; Wed, 9 Aug 2000 10:21:07 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.8.6) with ESMTP id e79DoEb02230; Wed, 9 Aug 2000 08:50:14 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id GAA03284 for disman-list; Wed, 9 Aug 2000 06:49:32 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id GAA03279 for ; Wed, 9 Aug 2000 06:49:29 -0700 (PDT) Received: from fw-us-hou1.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.8.6) with SMTP id e79Dnk902098 for ; Wed, 9 Aug 2000 08:49:46 -0500 (CDT) Received: from aix43.snmp.com (aix43.snmp.com [192.147.142.137]) by seymour39.SNMP.COM (8.9.3/m.000221) with ESMTP id JAA29092 for ; Wed, 9 Aug 2000 09:50:12 -0400 (EDT) Received: (from moulton@localhost) by aix43.snmp.com (8.9.3/snmpclient.mc-990615) id JAA14364 for disman@dorothy.bmc.com; Wed, 9 Aug 2000 09:50:11 -0400 Date: Wed, 9 Aug 2000 09:50:11 -0400 From: Steve Moulton Message-Id: <200008091350.JAA14364@aix43.snmp.com> To: disman@dorothy.peer.com Sender: owner-disman@dorothy.peer.com Precedence: bulk List-Id: IETF disman Working Group mailing list who disman From owner-disman@dorothy.peer.com Wed Aug 9 12:03:39 2000 Received: from tattler.bmc.com (fw-us-hou-2.bmc.com [198.207.223.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10863 for ; Wed, 9 Aug 2000 12:03:38 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.8.6) with ESMTP id e79Fmi429969; Wed, 9 Aug 2000 10:48:44 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id IAA03475 for disman-list; Wed, 9 Aug 2000 08:45:59 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id IAA03470 for ; Wed, 9 Aug 2000 08:45:55 -0700 (PDT) Received: from fw-us-hou1.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.8.6) with SMTP id e79FkEp29447 for ; Wed, 9 Aug 2000 10:46:14 -0500 (CDT) Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id IAA17592 for ; Wed, 9 Aug 2000 08:30:06 -0700 (MST)] Received: [from zei02exm02.cork.cig.mot.com (zei02exm02.cork.cig.mot.com [175.3.80.202]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id IAA07990 for ; Wed, 9 Aug 2000 08:27:19 -0700 (MST)] Received: by zei02exm02.cork.cig.mot.com with Internet Mail Service (5.5.2650.21) id ; Wed, 9 Aug 2000 16:27:18 +0100 Message-ID: <496E31A690F7D311B93C0008C789494C09CE31@zei02exm01.cork.cig.mot.com> From: Corcoran Phil-pcorco01 To: "'disman@dorothy.peer.com'" Date: Wed, 9 Aug 2000 16:27:12 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-disman@dorothy.peer.com Precedence: bulk List-Id: IETF disman Working Group mailing list Who disman regards, Phil Corcoran From owner-disman@dorothy.peer.com Wed Aug 9 16:39:49 2000 Received: from tattler.bmc.com (fw-us-hou-2.bmc.com [198.207.223.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19782 for ; Wed, 9 Aug 2000 16:39:49 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.8.6) with ESMTP id e79KVvM25723; Wed, 9 Aug 2000 15:31:57 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id NAA05701 for disman-list; Wed, 9 Aug 2000 13:30:57 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id NAA05696 for ; Wed, 9 Aug 2000 13:30:53 -0700 (PDT) Received: from fw-us-hou1.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.8.6) with SMTP id e79KVCh25559 for ; Wed, 9 Aug 2000 15:31:12 -0500 (CDT) Received: from alemail1.firewall.lucent.com (localhost [127.0.0.1]) by alemail1.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id QAA27883 for ; Wed, 9 Aug 2000 16:31:33 -0400 (EDT) Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by alemail1.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id QAA27776 for ; Wed, 9 Aug 2000 16:31:29 -0400 (EDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2650.21) id ; Wed, 9 Aug 2000 22:31:23 +0200 Message-ID: <2413FED0DFE6D111B3F90008C7FA61FB089A28C5@nl0006exch002u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Disman@dorothy.peer.com, Steve Moulton Subject: RE: IETF48 DISMAN Working Group Minutes Date: Wed, 9 Aug 2000 22:31:20 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-disman@dorothy.peer.com Precedence: bulk List-Id: IETF disman Working Group mailing list Thanks Steve!!!!! Bert From owner-disman@dorothy.peer.com Thu Aug 10 00:33:57 2000 Received: from tattler.bmc.com (fw-us-hou-2.bmc.com [198.207.223.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA29124 for ; Thu, 10 Aug 2000 00:33:56 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.8.6) with ESMTP id e7A4Vp500081; Wed, 9 Aug 2000 23:31:51 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id VAA10095 for disman-list; Wed, 9 Aug 2000 21:29:46 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id VAA10089; Wed, 9 Aug 2000 21:29:41 -0700 (PDT) Received: from fw-us-hou1.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.8.6) with SMTP id e7A4Tx429894; Wed, 9 Aug 2000 23:29:59 -0500 (CDT) Received: from alemail1.firewall.lucent.com (localhost [127.0.0.1]) by alemail1.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id AAA27050; Thu, 10 Aug 2000 00:30:26 -0400 (EDT) Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by alemail1.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id AAA27027; Thu, 10 Aug 2000 00:30:22 -0400 (EDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2650.21) id ; Thu, 10 Aug 2000 06:30:16 +0200 Message-ID: <2413FED0DFE6D111B3F90008C7FA61FB089A2907@nl0006exch002u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Mark Klerer , Randy Presuhn Cc: Disman@dorothy.peer.com Subject: RE: JointNM Date: Thu, 10 Aug 2000 06:30:15 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) 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 VAA10090 Sender: owner-disman@dorothy.peer.com Precedence: bulk List-Id: IETF disman Working Group mailing list Content-Transfer-Encoding: 8bit We just discussed Sharon's document in the jointNM. There is lots of interest in this work, and since it is a MIB, it seems natural to do this work in the IETF. There are concerns For example there is an ITU doc Q.821 which is very relevant in this area of active alarms, and it seems we should not re-invent the weel in IETF. I believe that the Q.821 also points to some X.7nn documents for mapping of events into alarms. Again, that may be relevant work. I expect that jointNM participants will post to the disman WG mailing list with supportive statements for this work and possibly listing requirements in this area. Now... the only reason why this would be DISMAN work seems to be that maybe it has some relation to notificationLog MIB and/or event mib? Anyway.. the WG needs to decide if they want to pick up this type of work items. Bert > ---------- > From: Randy Presuhn[SMTP:rpresuhn@dorothy.peer.com] > Sent: Wednesday, August 09, 2000 2:37 AM > To: klerer@nortelnetworks.com > Cc: disman@dorothy.peer.com > Subject: RE: JointNM > > > Hi Mark - > > > Message-ID: > <6DDA62170439D31185750000F80826AC035F4E5F@zmerd004.ca.nortel.com> > > From: "Sharon Chisholm" > > To: "Wijnen, Bert (Bert)" > > Cc: Randy Presuhn , > > "Mark Klerer" , > > Frank Peeters > > Subject: RE: JointNM > > Date: Tue, 8 Aug 2000 09:52:30 -0400 > ... > > I'd love to present my Active Alarm work, but unfortunately > > I can't make it to California this week. Mark has volunteered > > to present the information for me. I will also be submitting > > my internet draft later today. I am actually subscribed to the > > joint NM list, so I can forward the draft there and people can > > post questions and suggestions there as well. > ... > > If there are any comments, minutes, or whatever from the > JointNM meeting that would aid the IETF disman working > group in deciding whether to recommend taking this on as > a work item, please forward them to the WG mailing list at > > > ------------------------------------------------------- > Randy Presuhn randy_presuhn@bmc.com > Voice: +1 408 546-1006 BMC Software, Inc. 1-3141 > Fax: +1 408 965-0359 2141 North First Street > http://www.bmc.com/ San José, California 95131 USA > ------------------------------------------------------- > My opinions and BMC's are independent variables. > ------------------------------------------------------- > From owner-disman@dorothy.peer.com Thu Aug 10 07:04:41 2000 Received: from tattler.bmc.com (fw-us-hou-1.bmc.com [198.207.223.250]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14726 for ; Thu, 10 Aug 2000 07:04:40 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.8.6) with ESMTP id e7AB2Ci11899; Thu, 10 Aug 2000 06:02:12 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id EAA10721 for disman-list; Thu, 10 Aug 2000 04:00:45 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id EAA10715; Thu, 10 Aug 2000 04:00:40 -0700 (PDT) Received: from fw-us-hou1.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.8.6) with SMTP id e7AB0vs11768; Thu, 10 Aug 2000 06:00:57 -0500 (CDT) Received: from henkell.ibr.cs.tu-bs.de (schoenw@henkell [134.169.34.191]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) with ESMTP id NAA28530; Thu, 10 Aug 2000 13:01:19 +0200 (MET DST) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id NAA13030; Thu, 10 Aug 2000 13:01:19 +0200 Date: Thu, 10 Aug 2000 13:01:19 +0200 Message-Id: <200008101101.NAA13030@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: bwijnen@lucent.com CC: klerer@nortelnetworks.com, rpresuhn@dorothy.peer.com, Disman@dorothy.peer.com In-reply-to: <2413FED0DFE6D111B3F90008C7FA61FB089A2907@nl0006exch002u.nl.lucent.com> (bwijnen@lucent.com) Subject: Re: JointNM References: <2413FED0DFE6D111B3F90008C7FA61FB089A2907@nl0006exch002u.nl.lucent.com> Sender: owner-disman@dorothy.peer.com Precedence: bulk List-Id: IETF disman Working Group mailing list >>>>> Wijnen, Bert (Bert) writes: Bert> There are concerns For example there is an ITU doc Q.821 which Bert> is very relevant in this area of active alarms, and it seems we Bert> should not re-invent the weel in IETF. I believe that the Q.821 Bert> also points to some X.7nn documents for mapping of events into Bert> alarms. Again, that may be relevant work. I think it is X.733 (which is identical to ISO 10164-4). X.733 is definately relevant. Some management systems are actually based on the X.733 model and they usually interface with SNMP agents by mapping SNMP notifications into X.733 alarm records. This mapping is not always trivial since there is a big conceptual difference between a notification (which just describes an event) and an alarm record. Bert> Now... the only reason why this would be DISMAN work seems to be Bert> that maybe it has some relation to notificationLog MIB and/or Bert> event mib? Anyway.. the WG needs to decide if they want to pick Bert> up this type of work items. I believe the X.733 alarm model (though not perfect) is not too bad and going from there rather than reinventing a different wheel will make convergence of telco management systems and isp management systems much easier. In fact, the real technical issue is how you map notifications into alarm records. In other words: The biggest problem I have with the proposed document (despite several more MIB technical issues) is that it is too close to the SNMP notification logging MIB and ignores to define what the concept of an alarm really is and how they related to existing notifications. /js -- Juergen Schoenwaelder Technical University Braunschweig Dept. Operating Systems & Computer Networks Phone: +49 531 391 3289 Bueltenweg 74/75, 38106 Braunschweig, Germany Fax: +49 531 391 5936 From owner-disman@dorothy.peer.com Thu Aug 10 08:31:04 2000 Received: from tattler.bmc.com (fw-us-hou-2.bmc.com [198.207.223.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18064 for ; Thu, 10 Aug 2000 08:30:59 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.8.6) with ESMTP id e7ACSKE22032; Thu, 10 Aug 2000 07:28:20 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id FAA10906 for disman-list; Thu, 10 Aug 2000 05:27:34 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id FAA10900; Thu, 10 Aug 2000 05:27:30 -0700 (PDT) Received: from fw-us-hou1.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.8.6) with SMTP id e7ACRhl21906; Thu, 10 Aug 2000 07:27:44 -0500 (CDT) Received: from zrchb213.us.nortel.com (actually zrchb213) by smtprch1.nortel.com; Thu, 10 Aug 2000 07:21:14 -0500 Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2652.35) id ; Thu, 10 Aug 2000 07:21:06 -0500 Message-ID: <6DDA62170439D31185750000F80826AC0363111A@zmerd004.ca.nortel.com> From: "Sharon Chisholm" To: Juergen Schoenwaelder , bwijnen@lucent.com Cc: "Mark Klerer" , rpresuhn@dorothy.peer.com, Disman@dorothy.peer.com Subject: RE: JointNM Date: Thu, 10 Aug 2000 07:20:59 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C002C5.70F54930" Sender: owner-disman@dorothy.peer.com Precedence: bulk List-Id: IETF disman Working Group mailing list This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C002C5.70F54930 Content-Type: text/plain; charset="iso-8859-1" hi I intentionally decoupled the active alarm list from the mapping into alarm records since I felt coupling them would hinder the adoption of the MIB. I wanted a MIB which could both be supported on the devices and on the distributed manager. With the format I have used, the device can chose not to take on the issues of mapping notifications into alarm records and properly defining the raise/clear relationship, but I still end up with an active alarm list which I can use to manage my network. The other problems are important and I have no problem with them being addressed, either by me or someone else, but I don't want to see it become an all or nothing solution. I'd be interested in people's feedback on how often this mapping from notifications into alarm records actually gets done. Aside from the instance information, I've never seen it as a very dynamic thing in practise. I'd also be interested in where people think this translation should take place: the device, the distributed manager or the end application. Sharon -----Original Message----- From: Juergen Schoenwaelder [mailto:schoenw@ibr.cs.tu-bs.de] Sent: Thursday, August 10, 2000 7:01 AM To: bwijnen@lucent.com Cc: Klerer, Mark [MTNJ:2217-M:EXCH]; rpresuhn@dorothy.peer.com; Disman@dorothy.peer.com Subject: Re: JointNM >>>>> Wijnen, Bert (Bert) writes: Bert> There are concerns For example there is an ITU doc Q.821 which Bert> is very relevant in this area of active alarms, and it seems we Bert> should not re-invent the weel in IETF. I believe that the Q.821 Bert> also points to some X.7nn documents for mapping of events into Bert> alarms. Again, that may be relevant work. I think it is X.733 (which is identical to ISO 10164-4). X.733 is definately relevant. Some management systems are actually based on the X.733 model and they usually interface with SNMP agents by mapping SNMP notifications into X.733 alarm records. This mapping is not always trivial since there is a big conceptual difference between a notification (which just describes an event) and an alarm record. Bert> Now... the only reason why this would be DISMAN work seems to be Bert> that maybe it has some relation to notificationLog MIB and/or Bert> event mib? Anyway.. the WG needs to decide if they want to pick Bert> up this type of work items. I believe the X.733 alarm model (though not perfect) is not too bad and going from there rather than reinventing a different wheel will make convergence of telco management systems and isp management systems much easier. In fact, the real technical issue is how you map notifications into alarm records. In other words: The biggest problem I have with the proposed document (despite several more MIB technical issues) is that it is too close to the SNMP notification logging MIB and ignores to define what the concept of an alarm really is and how they related to existing notifications. /js -- Juergen Schoenwaelder Technical University Braunschweig Dept. Operating Systems & Computer Networks Phone: +49 531 391 3289 Bueltenweg 74/75, 38106 Braunschweig, Germany Fax: +49 531 391 5936 ------_=_NextPart_001_01C002C5.70F54930 Content-Type: text/html; charset="iso-8859-1" RE: JointNM

I intentionally decoupled the active alarm list from the mapping
into alarm records since I felt coupling them would hinder the
adoption of the MIB. I wanted a MIB which could both be supported
on the devices and on the distributed manager. With the format I
have used, the device can chose not to take on the issues of
mapping notifications into alarm records and properly defining
the raise/clear relationship, but I still end up with an active
alarm list which I can use to manage my network.

The other problems are important and I have no problem with them
being addressed, either by me or someone else, but I don't want to
see it become an all or nothing solution.

I'd be interested in people's feedback on how often this mapping
from notifications into alarm records actually gets done. Aside from
the instance information, I've never seen it as a very dynamic thing
in practise. I'd also be interested in where people think this translation
should take place: the device, the distributed manager or the end application.

Sharon

-----Original Message-----
From: Juergen Schoenwaelder [mailto:schoenw@ibr.cs.tu-bs.de]
Sent: Thursday, August 10, 2000 7:01 AM
To: bwijnen@lucent.com
Cc: Klerer, Mark [MTNJ:2217-M:EXCH]; rpresuhn@dorothy.peer.com;
Disman@dorothy.peer.com
Subject: Re: JointNM

>>>>> Wijnen, Bert (Bert) writes:

Bert> There are concerns For example there is an ITU doc Q.821 which
Bert> is very relevant in this area of active alarms, and it seems we
Bert> should not re-invent the weel in IETF. I believe that the Q.821
Bert> also points to some X.7nn documents for mapping of events into
Bert> alarms. Again, that may be relevant work.

I think it is X.733 (which is identical to ISO 10164-4). X.733 is
definately relevant. Some management systems are actually based on the
X.733 model and they usually interface with SNMP agents by mapping
SNMP notifications into X.733 alarm records. This mapping is not
always trivial since there is a big conceptual difference between a
notification (which just describes an event) and an alarm record.

Bert> Now... the only reason why this would be DISMAN work seems to be
Bert> that maybe it has some relation to notificationLog MIB and/or
Bert> event mib? Anyway.. the WG needs to decide if they want to pick
Bert> up this type of work items.

I believe the X.733 alarm model (though not perfect) is not too bad
and going from there rather than reinventing a different wheel will
make convergence of telco management systems and isp management
systems much easier. In fact, the real technical issue is how you map
notifications into alarm records.

In other words: The biggest problem I have with the proposed document
(despite several more MIB technical issues) is that it is too close to
the SNMP notification logging MIB and ignores to define what the
concept of an alarm really is and how they related to existing
notifications.

/js

--
Juergen Schoenwaelder      Technical University Braunschweig
<schoenw@ibr.cs.tu-bs.de> Dept. Operating Systems & Computer Networks
Phone: +49 531 391 3289    Bueltenweg 74/75, 38106 Braunschweig, Germany
Fax:   +49 531 391 5936    <URL:http://www.ibr.cs.tu-bs.de/~schoenw/>

------_=_NextPart_001_01C002C5.70F54930-- From owner-disman@dorothy.peer.com Thu Aug 10 14:18:08 2000 Received: from tattler.bmc.com (fw-us-hou-2.bmc.com [198.207.223.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09073 for ; Thu, 10 Aug 2000 14:18:07 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.8.6) with ESMTP id e7AIE3g05382; Thu, 10 Aug 2000 13:14:04 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id LAA15970 for disman-list; Thu, 10 Aug 2000 11:10:20 -0700 (PDT) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id LAA15961; Thu, 10 Aug 2000 11:10:15 -0700 (PDT) Date: Thu, 10 Aug 2000 11:10:15 -0700 (PDT) From: Randy Presuhn Message-Id: <200008101810.LAA15961@dorothy.bmc.com> To: bwijnen@lucent.com, klerer@nortelnetworks.com Subject: RE: JointNM Cc: Disman@dorothy.peer.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit Sender: owner-disman@dorothy.peer.com Precedence: bulk List-Id: IETF disman Working Group mailing list Content-Transfer-Encoding: 8bit Hi - > Message-ID: <2413FED0DFE6D111B3F90008C7FA61FB089A2907@nl0006exch002u.nl.lucent.com> > From: "Wijnen, Bert (Bert)" > To: Mark Klerer , > Randy Presuhn > > Cc: Disman@dorothy.bmc.com > Subject: RE: JointNM > Date: Thu, 10 Aug 2000 06:30:15 +0200 ... > There are concerns > For example there is an ITU doc Q.821 which is very relevant in this > area of active alarms, and it seems we should not re-invent the weel in > IETF. I believe that the Q.821 also points to some X.7nn documents > for mapping of events into alarms. Again, that may be relevant work. IS 10164-4 (X.733), IS 10164-5 (X.734), and IS 10164-6 (X.735) come to mind. Though this work is almost ten years old, I agree that it would be really silly to ignore it. There is some later work on "disseminator" objects that is also pertinent, and provides the same capabilities, though it is oriented towards reliable delivery rather than clearing. If I remember correctly, Bob Moore was the project editor. > I expect that jointNM participants will post to the disman WG mailing list > with supportive statements for this work and possibly listing requirements > in this area. > > Now... the only reason why this would be DISMAN work seems to be that > maybe it has some relation to notificationLog MIB and/or event mib? > Anyway.. the WG needs to decide if they want to pick up this type of > work items. ... Much of what this WG has been doing is what I'd consider basic infrastructure, rather than addressing the really interesting problems of large-scale management. I believe the failure to make any progress on the "framework" contributed to this situation. Meanwhile, DMTF and snmpconf have taken up the slack. ------------------------------------------------------- Randy Presuhn randy_presuhn@bmc.com Voice: +1 408 546-1006 BMC Software, Inc. 1-3141 Fax: +1 408 965-0359 2141 North First Street http://www.bmc.com/ San José, California 95131 USA ------------------------------------------------------- My opinions and BMC's are independent variables. ------------------------------------------------------- From owner-disman@dorothy.peer.com Thu Aug 10 15:47:02 2000 Received: from tattler.bmc.com (fw-us-hou-2.bmc.com [198.207.223.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12171 for ; Thu, 10 Aug 2000 15:47:02 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.8.6) with ESMTP id e7AJfbJ22172; Thu, 10 Aug 2000 14:41:37 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id MAA17188 for disman-list; Thu, 10 Aug 2000 12:40:52 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id MAA17182; Thu, 10 Aug 2000 12:40:48 -0700 (PDT) From: remoore@us.ibm.com Received: from fw-us-hou1.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.8.6) with SMTP id e7AJf1C22029; Thu, 10 Aug 2000 14:41:01 -0500 (CDT) Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by e24.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id PAA13928; Thu, 10 Aug 2000 15:43:26 -0500 Received: from d54mta02.raleigh.ibm.com (d54mta02.raleigh.ibm.com [9.67.228.34]) by southrelay02.raleigh.ibm.com (8.8.8m3/NCO v4.92) with SMTP id PAA41974; Thu, 10 Aug 2000 15:41:04 -0400 Received: by d54mta02.raleigh.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 85256937.006C1FEC ; Thu, 10 Aug 2000 15:41:00 -0400 X-Lotus-FromDomain: IBMUS To: Randy Presuhn cc: bwijnen@lucent.com, klerer@nortelnetworks.com, Disman@dorothy.peer.com Message-ID: <85256937.006C1C9B.00@d54mta02.raleigh.ibm.com> Date: Thu, 10 Aug 2000 18:43:46 -0400 Subject: RE: JointNM Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-disman@dorothy.peer.com Precedence: bulk List-Id: IETF disman Working Group mailing list Randy, >There is some later work on "disseminator" objects that is also >pertinent, and provides the same capabilities, though it is >oriented towards reliable delivery rather than clearing. If I >remember correctly, Bob Moore was the project editor. Not guilty! While there was some IBM support for this work, I was never involved as the editor. The one standard I did edit (for a while) is IS 10164-16 (X.???), Management Knowledge Management. By coincidence, my role in editing this document came up in an IETF context for the first time last week, at the ELSE BOF in Pittsburgh. Regards, Bob Bob Moore IBM Networking Software +1-919-254-4436 remoore@us.ibm.com From owner-disman@dorothy.peer.com Thu Aug 10 16:19:08 2000 Received: from tattler.bmc.com (fw-us-hou-2.bmc.com [198.207.223.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13056 for ; Thu, 10 Aug 2000 16:19:05 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.8.6) with ESMTP id e7AKG3028472; Thu, 10 Aug 2000 15:16:03 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id NAA17267 for disman-list; Thu, 10 Aug 2000 13:15:09 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id NAA17262 for ; Thu, 10 Aug 2000 13:15:04 -0700 (PDT) Received: from fw-us-hou1.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.8.6) with SMTP id e7AKFID28343 for ; Thu, 10 Aug 2000 15:15:19 -0500 (CDT) Received: from zrchb213.us.nortel.com (actually zrchb213) by smtprch2.nortel.com; Thu, 10 Aug 2000 15:10:43 -0500 Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2652.35) id ; Thu, 10 Aug 2000 15:13:29 -0500 Message-ID: <6DDA62170439D31185750000F80826AC0366D0E7@zmerd004.ca.nortel.com> From: "Sharon Chisholm" To: disman@dorothy.peer.com Subject: Alarm Information ... Date: Thu, 10 Aug 2000 15:13:26 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C00307.71484530" X-Orig: Sender: owner-disman@dorothy.peer.com Precedence: bulk List-Id: IETF disman Working Group mailing list This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C00307.71484530 Content-Type: text/plain; charset="iso-8859-1" hi I know this work has not found a home yet, but I thought I would summarize the requirements we have seen so far: 1) Mechanism to identify which notifications are alarms 2) Mechanism to identify Raise/Clear relationship between notifications/alarms 3) Mechanism to map from notifications into ITU alarm definitions 4) Mechanism to maintain list of active alarms One possible way to proceed with this would be a new table which covers the first three points. For example: AlarmEntry { alarmNotificationId OBJECT IDENTIFIER, alarmClearNotificationId OBJECT IDENTIFIER, alarmEventType Integer32, (enumerated type relating to X.731 8.1.1) alarmProbableCause Integer32, (enumerated type relating to X.733 section 8.1.2.1 and X.736) alarmSpecificProblem Integer32, alarmPerceivedSeverity Integer32, (enumerated type relating to X.733 section 8.1.2.3) alarmTrendIndication Integer32, (enumerated type relating to X.733 section 8.1.2.6) ... more fields if people find them necessary, } Separate tables makes sense from three perspectives: 1) Some alarm information is fairly static, so should probably be separated from the more dynamic information in the active alarm table 2) A particular alarm could be active on more than one entity, so separating this information out means less duplication 3) The separate tables decouples the active alarm list from the alarm definition, making the active alarm list implementable on systems not ready/willing to support the ITU alarm model. This could either be done in a separate MIB, or the Active Alarm MIB could be renamed to the Alarm MIB. Sharon Chisholm Preside Management Nortel Networks Ottawa, Ontario ------_=_NextPart_001_01C00307.71484530 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Alarm Information ...

I know this work has not found a home yet, but I = thought I would
summarize the requirements we have seen so = far:
        1) = Mechanism to identify which notifications are alarms
        2) = Mechanism to identify Raise/Clear relationship between = notifications/alarms
        3) = Mechanism to map from notifications into ITU alarm definitions
        4) = Mechanism to maintain list of active alarms

One possible way to proceed with this would be a new = table which covers
the first three points.

For example:
AlarmEntry {
        alarmNotificationId OBJECT IDENTIFIER,
      = alarmClearNotificationId OBJECT IDENTIFIER,
        alarmEventType Integer32, (enumerated type relating to = X.731 8.1.1)
      alarmProbableCause = Integer32, (enumerated type relating to X.733 section 8.1.2.1
        =         =         =         =              and X.736)
        alarmSpecificProblem Integer32,
        alarmPerceivedSeverity Integer32, (enumerated type relating to = X.733 section 8.1.2.3)
        alarmTrendIndication Integer32, (enumerated type relating to = X.733 section 8.1.2.6)
      ... more fields if = people find them necessary,
}

Separate tables makes sense from three = perspectives:
        1) Some = alarm information is fairly static, so should probably be separated = from
           the more dynamic information in the active alarm = table
        2) A = particular alarm could be active on more than one entity, so = separating
         = this information out means less duplication
        3) The = separate tables decouples the active alarm list from the alarm = definition,
           making the active alarm list implementable on = systems not ready/willing to
           support the ITU alarm model.

This could either be done in a separate MIB, or the = Active Alarm MIB could be renamed
to the Alarm MIB.

Sharon Chisholm
Preside Management
Nortel Networks
Ottawa, Ontario

------_=_NextPart_001_01C00307.71484530-- From owner-disman@dorothy.peer.com Thu Aug 10 19:25:47 2000 Received: from tattler.bmc.com (fw-us-hou-2.bmc.com [198.207.223.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16016 for ; Thu, 10 Aug 2000 19:25:46 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.8.6) with ESMTP id e7ANMm300179; Thu, 10 Aug 2000 18:22:49 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id QAA19075 for disman-list; Thu, 10 Aug 2000 16:21:45 -0700 (PDT) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id QAA19069; Thu, 10 Aug 2000 16:21:42 -0700 (PDT) Date: Thu, 10 Aug 2000 16:21:42 -0700 (PDT) From: Randy Presuhn Message-Id: <200008102321.QAA19069@dorothy.bmc.com> To: disman@dorothy.peer.com Subject: RE: JointNM Cc: klerer@nortelnetworks.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-disman@dorothy.peer.com Precedence: bulk List-Id: IETF disman Working Group mailing list Content-Transfer-Encoding: 7bit Hi - > From: remoore@us.ibm.com > To: Randy Presuhn > cc: bwijnen@lucent.com, klerer@nortelnetworks.com, Disman@dorothy.bmc.com > Message-ID: <85256937.006C1C9B.00@d54mta02.raleigh.ibm.com> > Date: Thu, 10 Aug 2000 18:43:46 -0400 > Subject: RE: JointNM ... > >There is some later work on "disseminator" objects that is also > >pertinent, and provides the same capabilities, though it is > >oriented towards reliable delivery rather than clearing. If I > >remember correctly, Bob Moore was the project editor. > > Not guilty! While there was some IBM support for this work, I > was never involved as the editor. The one standard I did edit > (for a while) is IS 10164-16 (X.???), Management Knowledge > Management. By coincidence, my role in editing this document > came up in an IETF context for the first time last week, at the > ELSE BOF in Pittsburgh. ... Sorry, I stand corrected. Do you recall where the disseminator work ended up? I thought it was an amendment to the Log Control Function, but my memory is obviously getting fuzzy. It's interesting that MKMF should come up again. Is there any chance that we might get that capability in the SNMP world, even if via LDAP? ------------------------------------------------------- Randy Presuhn randy_presuhn@bmc.com Voice: +1 408 546-1006 BMC Software, Inc. 1-3141 Fax: +1 408 965-0359 2141 North First Street http://www.bmc.com/ San José, California 95131 USA ------------------------------------------------------- My opinions and BMC's are independent variables. ------------------------------------------------------- From owner-disman@dorothy.peer.com Fri Aug 11 07:00:23 2000 Received: from tattler.bmc.com (fw-us-hou-2.bmc.com [198.207.223.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08590 for ; Fri, 11 Aug 2000 07:00:23 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.8.6) with ESMTP id e7BAvtZ15287; Fri, 11 Aug 2000 05:57:55 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id DAA21752 for disman-list; Fri, 11 Aug 2000 03:56:54 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id DAA21747 for ; Fri, 11 Aug 2000 03:56:50 -0700 (PDT) Received: from fw-us-hou1.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.8.6) with SMTP id e7BAv4115191 for ; Fri, 11 Aug 2000 05:57:05 -0500 (CDT) Received: from henkell.ibr.cs.tu-bs.de (schoenw@henkell [134.169.34.191]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) with ESMTP id MAA27493; Fri, 11 Aug 2000 12:57:13 +0200 (MET DST) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id MAA09864; Fri, 11 Aug 2000 12:57:13 +0200 Date: Fri, 11 Aug 2000 12:57:13 +0200 Message-Id: <200008111057.MAA09864@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: schishol@nortelnetworks.com CC: klerer@nortelnetworks.com, Disman@dorothy.peer.com In-reply-to: <6DDA62170439D31185750000F80826AC0363111A@zmerd004.ca.nortel.com> (schishol@nortelnetworks.com) Subject: Re: JointNM References: <6DDA62170439D31185750000F80826AC0363111A@zmerd004.ca.nortel.com> Sender: owner-disman@dorothy.peer.com Precedence: bulk List-Id: IETF disman Working Group mailing list >>>>> Sharon Chisholm writes: Sharon> I intentionally decoupled the active alarm list from the Sharon> mapping into alarm records since I felt coupling them would Sharon> hinder the adoption of the MIB. I wanted a MIB which could Sharon> both be supported on the devices and on the distributed Sharon> manager. With the format I have used, the device can chose Sharon> not to take on the issues of mapping notifications into alarm Sharon> records and properly defining the raise/clear relationship, Sharon> but I still end up with an active alarm list which I can use Sharon> to manage my network. Sharon> The other problems are important and I have no problem with Sharon> them being addressed, either by me or someone else, but I Sharon> don't want to see it become an all or nothing solution. I think it is necessary to first have agreement what the concept of an alarm is and how it relates to notifications before you can define a MIB which holds lists of alarms. Sharon> I'd be interested in people's feedback on how often this Sharon> mapping from notifications into alarm records actually gets Sharon> done. Aside from the instance information, I've never seen it Sharon> as a very dynamic thing in practise. I'd also be interested Sharon> in where people think this translation should take place: the Sharon> device, the distributed manager or the end application. I am familiar with one commercial management system which is used by several mobile phone operators in Germany (and most likely in other countries as well). (So I am not talking about a toy here.) It is based on X.733 alarm concepts and it maps SNMP notifications into X.733 alarms in two slightly different ways: (a) You add magic keywords into the MIB module which defines notifications. These magic keywords are used by the manager to derive statically all the X.733 alarm records information needed but not present in a notification definition (e.g. the severity). (b) You add magic keywords into the MIB module which defines notifications. However, this time the magic keywords are used by the manager to dynamically retrieve some of the X.733 alarm record information from the actual notification which creates or deletes an alarm record. Both approaches are more or less kludges for several reasons - but they seem to work well enough in practice if the notifications are defined in suitable way. (I have seen people who were aware of this mapping strategy and who were defining SMIv2 notifications so that these mappings become easier...) /js -- Juergen Schoenwaelder Technical University Braunschweig Dept. Operating Systems & Computer Networks Phone: +49 531 391 3289 Bueltenweg 74/75, 38106 Braunschweig, Germany Fax: +49 531 391 5936 From owner-disman@dorothy.peer.com Fri Aug 11 10:15:11 2000 Received: from tattler.bmc.com (fw-us-hou-1.bmc.com [198.207.223.250]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18320 for ; Fri, 11 Aug 2000 10:15:11 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.8.6) with ESMTP id e7BE7Qe11598; Fri, 11 Aug 2000 09:07:27 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id HAA22142 for disman-list; Fri, 11 Aug 2000 07:05:36 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id HAA22134 for ; Fri, 11 Aug 2000 07:05:32 -0700 (PDT) Received: from fw-us-hou1.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.8.6) with SMTP id e7BE5n111309 for ; Fri, 11 Aug 2000 09:05:49 -0500 (CDT) Received: from cs.utwente.nl (utip427.cs.utwente.nl [130.89.12.86]) by utrhcs.cs.utwente.nl (8.9.3/8.9.3) with ESMTP id QAA00790; Fri, 11 Aug 2000 16:06:14 +0200 (MET DST) Message-ID: <39940856.E890C2BC@cs.utwente.nl> Date: Fri, 11 Aug 2000 16:06:14 +0200 From: Ron Sprenkels Organization: University of Twente X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: DISMAN Mailing List , jasmin@ibr.cs.tu-bs.de, snmpv3@lists.tislabs.com Subject: GUI application for RFC2592 ScriptMIB agents Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-disman@dorothy.peer.com Precedence: bulk List-Id: IETF disman Working Group mailing list Content-Transfer-Encoding: 7bit Hello, We wrote a small management tool called ScriptMIBControl to facilitate working with the Script MIB (RFC 2592). It provides a GUI that allows you to create and delete entries in the smScriptTable, the smLaunchTable and the smRunTable of a scriptMIB agent. More info (including links to download the source code, compiled code, and some screenshots) can be found here: http://www.simpleweb.org/software/packages/ScriptMibControl/ The program uses the Java 'scriptmib' Client Package by TU Braunschweig (http://www.ibr.cs.tu-bs.de/projects/jasmin/scriptmib.html). This package takes care of interfacing to the Script MIB agent through SNMP. Features of smControl include: o GUI based, written in Java, source included. o Contents of the MIB tables shown in table format on screen, with buttons to add/delete entries. If you have any comments on or questions about this package, don't hesitate to email us at nm@cs.utwente.nl. Ruben Marsman and Ron Sprenkels -------------------------------------------------------------------------- Ron Sprenkels sprenkel@cs.utwente.nl http://www.cs.utwente.nl/~sprenkel University of Twente, Department of Computer Science, TSS Management group P.O. Box 217, 7500 AE Enschede, The Netherlands. (Tel. +31 53 489 4663) From owner-disman@dorothy.peer.com Tue Aug 22 07:56:01 2000 Received: from tattler.bmc.com (fw-us-hou-1.bmc.com [198.207.223.250]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02098 for ; Tue, 22 Aug 2000 07:56:01 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.8.6) with ESMTP id e7MBpl015047; Tue, 22 Aug 2000 06:51:52 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id EAA20997 for disman-list; Tue, 22 Aug 2000 04:46:49 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id EAA20992 for ; Tue, 22 Aug 2000 04:46:45 -0700 (PDT) Received: from fw-us-hou1.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.8.6) with SMTP id e7MBkuf14450 for ; Tue, 22 Aug 2000 06:46:56 -0500 (CDT) Received: from cisco.com ([192.135.247.153]) by jindo.cisco.com (8.8.8/2.5.1/Cisco List Logging/8.8.8) with ESMTP id EAA09716 for ; Tue, 22 Aug 2000 04:47:21 -0700 (PDT) Message-ID: <39A267EE.B948D959@cisco.com> Date: Tue, 22 Aug 2000 17:15:50 +0530 From: Rohit X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: disman@dorothy.peer.com Subject: Notification Log MIB Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-disman@dorothy.peer.com Precedence: bulk List-Id: IETF disman Working Group mailing list Content-Transfer-Encoding: 7bit Hi, I just did a quick scan of the notification log MIB and i noticed that 1. For SNMP Manager to retrieve information about one notification, it has to issue several SNMP Get Requests depending upon the number of varbinds in the notification. This looks like an inefficient mechanism. Instead of this we could have packed up the Varbinds in one object. e.g we could have used an OctetString as follows to pack up the Varbind. OCTET STRING (SIZE (0..65535)) DESCRIPTION "The stringifed value of the VarBinds that were sent as part of the trap generated by this fault. The VarBinds are stringified as follows: (i) The format of the strigified varbind would be, '', where, 'objectname' - is the name of the object (including the instance) and not the entire OID. For ex: ifDescr.3 and not 1.3.6.1.2.1.2.2.1.2.3 'objecttype' - is the type of the object stored as an ASCII string. For ex: 'Integer32', 'SnmpAdminString' 'value' - is the value of the object (ii) The rules for encoding the 'value' in the string are as follows, - Integral types are converted into ASCII string - For OctetString with printable characters, again use ASCII - For OctetString with non-printable characters, they will be stored in HEX - Since we use '>' as the ending delimiter for each varbind in the stringified value, if the 'value' itself has a '>', then that would be escaped with another '>'. For ex: if the value was say 'abcde>>f' then it would be stored as 'abcde>>>>f' in the stringified value." 2. Why don't we have a nlmConfigLogAgeout for each entry in the nlmConfigLogTable ? This could even be used for associating priority to the notification being logged. Thanks Rohit From owner-disman@dorothy.peer.com Tue Aug 22 08:29:29 2000 Received: from tattler.bmc.com (fw-us-hou-2.bmc.com [198.207.223.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03210 for ; Tue, 22 Aug 2000 08:29:28 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.8.6) with ESMTP id e7MCOf019520; Tue, 22 Aug 2000 07:24:42 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id FAA21136 for disman-list; Tue, 22 Aug 2000 05:24:13 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id FAA21131 for ; Tue, 22 Aug 2000 05:24:10 -0700 (PDT) Received: from fw-us-hou1.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.8.6) with SMTP id e7MCOKb19449 for ; Tue, 22 Aug 2000 07:24:20 -0500 (CDT) Received: from henkell.ibr.cs.tu-bs.de (schoenw@henkell [134.169.34.191]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) with ESMTP id OAA10048; Tue, 22 Aug 2000 14:24:53 +0200 (MET DST) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id OAA19443; Tue, 22 Aug 2000 14:24:53 +0200 Date: Tue, 22 Aug 2000 14:24:53 +0200 Message-Id: <200008221224.OAA19443@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: rrohit@cisco.com CC: disman@dorothy.peer.com In-reply-to: <39A267EE.B948D959@cisco.com> (message from Rohit on Tue, 22 Aug 2000 17:15:50 +0530) Subject: Re: Notification Log MIB References: <39A267EE.B948D959@cisco.com> Sender: owner-disman@dorothy.peer.com Precedence: bulk List-Id: IETF disman Working Group mailing list >>>>> Rohit writes: Rohit> 1. For SNMP Manager to retrieve information about one Rohit> notification, it has to issue several SNMP Get Requests Rohit> depending upon the number of varbinds in the notification. Rohit> This looks like an inefficient mechanism. You usually use getnext/getbulks. That is, you can reduce to some extend the number of interactions (if you know a good estimation for max-repetitions - which is another story). Rohit> Instead of this we could have packed up the Varbinds in Rohit> one object. Yes. The point here is that the SMI has no support for structured types and people did not like the idea to put things into something opaque like an OCTET STRING. Rohit> e.g we could have used an OctetString as follows to pack Rohit> up the Varbind. Rohit> OCTET STRING (SIZE (0..65535)) DESCRIPTION "The Rohit> stringifed value of the VarBinds that were sent as part of the Rohit> trap generated by this fault. The VarBinds are stringified as Rohit> follows: (i) The format of the strigified varbind would be, Rohit> '', where, 'objectname' - is the Rohit> name of the object (including the instance) and not the entire Rohit> OID. For ex: ifDescr.3 and not 1.3.6.1.2.1.2.2.1.2.3 Rohit> 'objecttype' - is the type of the object Rohit> stored as an ASCII string. For ex: 'Integer32', Rohit> 'SnmpAdminString' Rohit> 'value' - is the value of the object (ii) Rohit> The rules for encoding the 'value' in the string are as Rohit> follows, - Integral types are converted into ASCII string - For Rohit> OctetString with printable characters, again use ASCII - For Rohit> OctetString with non-printable characters, they will be stored Rohit> in HEX - Since we use '>' as the ending delimiter for each Rohit> varbind in the stringified value, if the 'value' itself has a Rohit> '>', then that would be escaped with another '>'. For ex: if Rohit> the value was say 'abcde>>f' then it would be stored as Rohit> 'abcde>>>>f' in the stringified value." The ASCII representation you are proposing does not work for several reasons. First, the notification logger has not necessarily MIB knowledge. Second, a single descriptor like ifDescr is not guaranteed to be unique. Third, encoding everything (including type names) in pure ASCII can make the OCTET STRING pretty long which can badly interact with SNMP message size constraints. One could however argue that the MIB should export the whole BER encoded notification varbind list instead (or in addition?) to the table we have right now. This of course requires that the application which reads the logging table is capable to decode a BER varbind list - but this is not much harder than decoding yet another ad-hoc ASCII representation, I think. /js -- Juergen Schoenwaelder Technical University Braunschweig Dept. Operating Systems & Computer Networks Phone: +49 531 391 3289 Bueltenweg 74/75, 38106 Braunschweig, Germany Fax: +49 531 391 5936 From owner-disman@dorothy.peer.com Tue Aug 22 09:09:33 2000 Received: from tattler.bmc.com (fw-us-hou-2.bmc.com [198.207.223.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04587 for ; Tue, 22 Aug 2000 09:09:33 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.8.6) with ESMTP id e7MD7GY26020; Tue, 22 Aug 2000 08:07:17 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id GAA21252 for disman-list; Tue, 22 Aug 2000 06:06:26 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id GAA21247 for ; Tue, 22 Aug 2000 06:06:22 -0700 (PDT) Received: from fw-us-hou1.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.8.6) with SMTP id e7MD6Vl25877 for ; Tue, 22 Aug 2000 08:06:31 -0500 (CDT) Received: from cisco.com ([192.135.247.153]) by jindo.cisco.com (8.8.8/2.5.1/Cisco List Logging/8.8.8) with ESMTP id GAA10339; Tue, 22 Aug 2000 06:06:28 -0700 (PDT) Message-ID: <39A27A79.C72708C0@cisco.com> Date: Tue, 22 Aug 2000 18:34:57 +0530 From: Rohit X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Juergen Schoenwaelder CC: disman@dorothy.peer.com Subject: Re: Notification Log MIB References: <39A267EE.B948D959@cisco.com> <200008221224.OAA19443@henkell.ibr.cs.tu-bs.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-disman@dorothy.peer.com Precedence: bulk List-Id: IETF disman Working Group mailing list Content-Transfer-Encoding: 7bit Hi Juergen, My comments are inline :- Juergen Schoenwaelder wrote: > > >>>>> Rohit writes: > > Rohit> 1. For SNMP Manager to retrieve information about one > Rohit> notification, it has to issue several SNMP Get Requests > Rohit> depending upon the number of varbinds in the notification. > > Rohit> This looks like an inefficient mechanism. > > You usually use getnext/getbulks. That is, you can reduce to some > extend the number of interactions (if you know a good estimation for > max-repetitions - which is another story). If we use getnext , we are increasing the traffic on the network. If we are using getbulk , its not a straight forward to estimate the number of max-repititions. With the alternate solution, one get will get you one complete notification. > > Rohit> Instead of this we could have packed up the Varbinds in > Rohit> one object. > > Yes. The point here is that the SMI has no support for structured > types and people did not like the idea to put things into something > opaque like an OCTET STRING. > > Rohit> e.g we could have used an OctetString as follows to pack > Rohit> up the Varbind. > > Rohit> OCTET STRING (SIZE (0..65535)) DESCRIPTION "The > Rohit> stringifed value of the VarBinds that were sent as part of the > Rohit> trap generated by this fault. The VarBinds are stringified as > Rohit> follows: (i) The format of the strigified varbind would be, > Rohit> '', where, 'objectname' - is the > Rohit> name of the object (including the instance) and not the entire > Rohit> OID. For ex: ifDescr.3 and not 1.3.6.1.2.1.2.2.1.2.3 > > Rohit> 'objecttype' - is the type of the object > Rohit> stored as an ASCII string. For ex: 'Integer32', > Rohit> 'SnmpAdminString' > > Rohit> 'value' - is the value of the object (ii) > Rohit> The rules for encoding the 'value' in the string are as > Rohit> follows, - Integral types are converted into ASCII string - For > Rohit> OctetString with printable characters, again use ASCII - For > Rohit> OctetString with non-printable characters, they will be stored > Rohit> in HEX - Since we use '>' as the ending delimiter for each > Rohit> varbind in the stringified value, if the 'value' itself has a > Rohit> '>', then that would be escaped with another '>'. For ex: if > Rohit> the value was say 'abcde>>f' then it would be stored as > Rohit> 'abcde>>>>f' in the stringified value." > > The ASCII representation you are proposing does not work for several > reasons. First, the notification logger has not necessarily MIB > knowledge. Second, a single descriptor like ifDescr is not guaranteed > to be unique. Third, encoding everything (including type names) in > pure ASCII can make the OCTET STRING pretty long which can badly > interact with SNMP message size constraints. > > One could however argue that the MIB should export the whole BER > encoded notification varbind list instead (or in addition?) to the > table we have right now. This of course requires that the application > which reads the logging table is capable to decode a BER varbind list I agree to the fact that suggested representation is not a standard but this can be documented in the MIB. Size of the OctetString will depend on the 'number of Varbinds' and their types which i believe should not not cross SNMP message size. Thanks Rohit > - but this is not much harder than decoding yet another ad-hoc ASCII > representation, I think. > > /js > > -- > Juergen Schoenwaelder Technical University Braunschweig > Dept. Operating Systems & Computer Networks > Phone: +49 531 391 3289 Bueltenweg 74/75, 38106 Braunschweig, Germany > Fax: +49 531 391 5936 From owner-disman@dorothy.peer.com Tue Aug 22 12:29:12 2000 Received: from tattler.bmc.com (fw-us-hou-2.bmc.com [198.207.223.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10137 for ; Tue, 22 Aug 2000 12:29:12 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.8.6) with ESMTP id e7MGPnZ11540; Tue, 22 Aug 2000 11:25:49 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id JAA21568 for disman-list; Tue, 22 Aug 2000 09:24:31 -0700 (PDT) Received: from creeper.bmc.com (creeper.bmc.com [172.17.1.166]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id JAA21563 for ; Tue, 22 Aug 2000 09:24:27 -0700 (PDT) Received: from ec03-hou.bmc.com (ec03-hou.bmc.com [172.20.4.32]) by creeper.bmc.com (8.10.2/8.8.6) with ESMTP id e7MGP7d13749; Tue, 22 Aug 2000 11:25:08 -0500 (CDT) Received: by ec03-hou.bmc.com with Internet Mail Service (5.5.2650.21) id ; Tue, 22 Aug 2000 11:27:05 -0500 Message-ID: From: "Golovinsky, Eugene" To: "'Rohit'" , disman@dorothy.peer.com Subject: RE: Notification Log MIB Date: Tue, 22 Aug 2000 11:25:02 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-disman@dorothy.peer.com Precedence: bulk List-Id: IETF disman Working Group mailing list Hi. Just a few observations from my previous usage experience. I tried to do very similar thing and packed information into single trap OCTET STRING varbind. In fact, they were multiple varbinds separated by something, space for example. While it seems to be a good idea it does not really works for the following reasons. 1. People get really upset when forced to parse long strings without having rules of how to parse it (fields within the varbind are of arbitrary length). 2. A few times we got to the prohibitively long varbind 3. You are forced to represent everything as ASCII string even though it not always a good idea. Integer values would be an example. 4. To have a meaningful separator is not easy, since it always could be part of the varbind itself. So, I think it is not an ideal solution. An though it might seem appealing at first glance, practical reality does not prove it. Thanks, --Gene Eugene Golovinsky eugene_golovinsky@bmc.com -----Original Message----- From: Rohit [mailto:rrohit@cisco.com] Sent: Tuesday, August 22, 2000 6:46 AM To: disman@dorothy.peer.com Subject: Notification Log MIB Hi, I just did a quick scan of the notification log MIB and i noticed that 1. For SNMP Manager to retrieve information about one notification, it has to issue several SNMP Get Requests depending upon the number of varbinds in the notification. This looks like an inefficient mechanism. Instead of this we could have packed up the Varbinds in one object. e.g we could have used an OctetString as follows to pack up the Varbind. OCTET STRING (SIZE (0..65535)) DESCRIPTION "The stringifed value of the VarBinds that were sent as part of the trap generated by this fault. The VarBinds are stringified as follows: (i) The format of the strigified varbind would be, '', where, 'objectname' - is the name of the object (including the instance) and not the entire OID. For ex: ifDescr.3 and not 1.3.6.1.2.1.2.2.1.2.3 'objecttype' - is the type of the object stored as an ASCII string. For ex: 'Integer32', 'SnmpAdminString' 'value' - is the value of the object (ii) The rules for encoding the 'value' in the string are as follows, - Integral types are converted into ASCII string - For OctetString with printable characters, again use ASCII - For OctetString with non-printable characters, they will be stored in HEX - Since we use '>' as the ending delimiter for each varbind in the stringified value, if the 'value' itself has a '>', then that would be escaped with another '>'. For ex: if the value was say 'abcde>>f' then it would be stored as 'abcde>>>>f' in the stringified value." 2. Why don't we have a nlmConfigLogAgeout for each entry in the nlmConfigLogTable ? This could even be used for associating priority to the notification being logged. Thanks Rohit From owner-disman@dorothy.peer.com Tue Aug 22 12:32:51 2000 Received: from tattler.bmc.com (fw-us-hou-2.bmc.com [198.207.223.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10268 for ; Tue, 22 Aug 2000 12:32:51 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.8.6) with ESMTP id e7MGUPF12734; Tue, 22 Aug 2000 11:30:26 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id JAA21591 for disman-list; Tue, 22 Aug 2000 09:30:01 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id JAA21586 for ; Tue, 22 Aug 2000 09:29:57 -0700 (PDT) Received: from fw-us-hou1.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.8.6) with SMTP id e7MGU5112668 for ; Tue, 22 Aug 2000 11:30:05 -0500 (CDT) Received: from cisco.com (dhcp-171-69-66-157.cisco.com [171.69.66.157]) by sigma.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id JAA15841; Tue, 22 Aug 2000 09:29:53 -0700 (PDT) Message-ID: <39A2AA87.9A8ED838@cisco.com> Date: Tue, 22 Aug 2000 09:29:59 -0700 From: Ram Kavasseri Reply-To: ramk@cisco.com Organization: Cisco Systems X-Mailer: Mozilla 4.5 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Rohit CC: Juergen Schoenwaelder , disman@dorothy.peer.com Subject: Re: Notification Log MIB References: <39A267EE.B948D959@cisco.com> <200008221224.OAA19443@henkell.ibr.cs.tu-bs.de> <39A27A79.C72708C0@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-disman@dorothy.peer.com Precedence: bulk List-Id: IETF disman Working Group mailing list Content-Transfer-Encoding: 7bit Rohit wrote: > > Hi Juergen, > > My comments are inline :- > > Juergen Schoenwaelder wrote: > > > > >>>>> Rohit writes: > > > > Rohit> 1. For SNMP Manager to retrieve information about one > > Rohit> notification, it has to issue several SNMP Get Requests > > Rohit> depending upon the number of varbinds in the notification. > > > > Rohit> This looks like an inefficient mechanism. > > > > You usually use getnext/getbulks. That is, you can reduce to some > > extend the number of interactions (if you know a good estimation for > > max-repetitions - which is another story). > > If we use getnext , we are increasing the traffic on the network. > If we are using getbulk , its not a straight forward to estimate the > number of max-repititions. > > With the alternate solution, one get will get you one complete > notification. Parsing values from an encoded OctetString is discouraged. You're trying to solve two problems here: 1. encapsulating all the objects you need into one PDU 2. apply some sort of compression or OID suppression to make the transfer more efficient. The former can be done today using bulk transfer...For the latter, the NMRG (Network Management Research Group) is investigating various bulk-transfer methods with OID suppression (and/or compression)... Inventing ways to do either of the above for a few objects only is wrong and non-standard, IMHO... Ram > > > > Rohit> Instead of this we could have packed up the Varbinds in > > Rohit> one object. > > > > Yes. The point here is that the SMI has no support for structured > > types and people did not like the idea to put things into something > > opaque like an OCTET STRING. > > > > Rohit> e.g we could have used an OctetString as follows to pack > > Rohit> up the Varbind. > > > > Rohit> OCTET STRING (SIZE (0..65535)) DESCRIPTION "The > > Rohit> stringifed value of the VarBinds that were sent as part of the > > Rohit> trap generated by this fault. The VarBinds are stringified as > > Rohit> follows: (i) The format of the strigified varbind would be, > > Rohit> '', where, 'objectname' - is the > > Rohit> name of the object (including the instance) and not the entire > > Rohit> OID. For ex: ifDescr.3 and not 1.3.6.1.2.1.2.2.1.2.3 > > > > Rohit> 'objecttype' - is the type of the object > > Rohit> stored as an ASCII string. For ex: 'Integer32', > > Rohit> 'SnmpAdminString' > > > > Rohit> 'value' - is the value of the object (ii) > > Rohit> The rules for encoding the 'value' in the string are as > > Rohit> follows, - Integral types are converted into ASCII string - For > > Rohit> OctetString with printable characters, again use ASCII - For > > Rohit> OctetString with non-printable characters, they will be stored > > Rohit> in HEX - Since we use '>' as the ending delimiter for each > > Rohit> varbind in the stringified value, if the 'value' itself has a > > Rohit> '>', then that would be escaped with another '>'. For ex: if > > Rohit> the value was say 'abcde>>f' then it would be stored as > > Rohit> 'abcde>>>>f' in the stringified value." > > > > The ASCII representation you are proposing does not work for several > > reasons. First, the notification logger has not necessarily MIB > > knowledge. Second, a single descriptor like ifDescr is not guaranteed > > to be unique. Third, encoding everything (including type names) in > > pure ASCII can make the OCTET STRING pretty long which can badly > > interact with SNMP message size constraints. > > > > One could however argue that the MIB should export the whole BER > > encoded notification varbind list instead (or in addition?) to the > > table we have right now. This of course requires that the application > > which reads the logging table is capable to decode a BER varbind list > > I agree to the fact that suggested representation is not a standard > but this can be documented in the MIB. > Size of the OctetString will depend on the 'number of Varbinds' and > their > types which i believe should not not cross SNMP message size. > > Thanks > Rohit > > > - but this is not much harder than decoding yet another ad-hoc ASCII > > representation, I think. > > > > /js > > > > -- > > Juergen Schoenwaelder Technical University Braunschweig > > Dept. Operating Systems & Computer Networks > > Phone: +49 531 391 3289 Bueltenweg 74/75, 38106 Braunschweig, Germany > > Fax: +49 531 391 5936 From owner-disman@dorothy.peer.com Tue Aug 22 13:05:26 2000 Received: from tattler.bmc.com (fw-us-hou-2.bmc.com [198.207.223.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10949 for ; Tue, 22 Aug 2000 13:05:25 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.8.6) with ESMTP id e7MH0ol19002; Tue, 22 Aug 2000 12:00:55 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id JAA21825 for disman-list; Tue, 22 Aug 2000 09:59:57 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id JAA21820 for ; Tue, 22 Aug 2000 09:59:53 -0700 (PDT) Received: from fw-us-hou1.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.8.6) with SMTP id e7MH01i18750 for ; Tue, 22 Aug 2000 12:00:01 -0500 (CDT) Received: from cisco.com (dhcp-171-69-66-157.cisco.com [171.69.66.157]) by sigma.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id IAA09151; Tue, 22 Aug 2000 08:58:04 -0700 (PDT) Message-ID: <39A2A311.45325BD4@cisco.com> Date: Tue, 22 Aug 2000 08:58:09 -0700 From: Ram Kavasseri Reply-To: ramk@cisco.com Organization: Cisco Systems X-Mailer: Mozilla 4.5 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Rohit CC: disman@dorothy.peer.com Subject: Re: Notification Log MIB References: <39A267EE.B948D959@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-disman@dorothy.peer.com Precedence: bulk List-Id: IETF disman Working Group mailing list Content-Transfer-Encoding: 7bit Rohit wrote: > > Hi, > > I just did a quick scan of the notification log MIB and i noticed > that > > 1. For SNMP Manager to retrieve information about one notification, > it has to issue several SNMP Get Requests depending upon > the number of varbinds in the notification. > > This looks like an inefficient mechanism. > > Instead of this we could have packed up the Varbinds in > one object. > > e.g we could have used an OctetString as follows to > pack up the Varbind. Packing varbinds into an octetstring means: 1. you'll have to parse the octetstring to get the "sum of the parts". Parsing OctetStrings to get individual fields is discouraged. 2. you'll need to come up with some way to delimit each varbind in the OctetString, and represent the datatypes - afaik, there aren't rules to tell you how to do this OctetString packaging (and we shouldn't be inventing ways to encode this into an OctetString). 3. solving the inefficiency of a couple of extra objects by slamming them all into one OctetString is the wrong way, IMHO, to address this problem. The inefficieny you point to is a general handicap for every SNMP transmission (i.e. the number of octets taken up by the non-instance part of the OID, the repeated OID data in multiple packets)... The right way to address this would be to adopt a bulk-transfer method that works for *all* objects, and not hack a few objects in a MIB into an OctetString... Ram > > OCTET STRING (SIZE (0..65535)) > DESCRIPTION > "The stringifed value of the VarBinds that were sent > as part of the trap generated by this fault. The > VarBinds are stringified as follows: > (i) The format of the strigified varbind would be, > '', where, > 'objectname' - is the name of the object > (including the instance) and not > the entire OID. > For ex: ifDescr.3 and not 1.3.6.1.2.1.2.2.1.2.3 > > 'objecttype' - is the type of the object stored as > an ASCII string. > For ex: 'Integer32', 'SnmpAdminString' > > 'value' - is the value of the object > (ii) The rules for encoding the 'value' in the string > are as follows, > - Integral types are converted into ASCII string > - For OctetString with printable characters, > again use ASCII > - For OctetString with non-printable characters, > they will be stored in HEX > - Since we use '>' as the ending delimiter for > each varbind in the stringified value, if the > 'value' itself has a '>', then that would be > escaped with another '>'. > For ex: if the value was say 'abcde>>f' then it > would be stored as 'abcde>>>>f' in the > stringified value." > > 2. Why don't we have a nlmConfigLogAgeout for each entry in the > nlmConfigLogTable ? This could even be used for associating > priority > to the notification being logged. > > > > Thanks > Rohit From owner-disman@dorothy.peer.com Tue Aug 22 13:06:56 2000 Received: from tattler.bmc.com (fw-us-hou-2.bmc.com [198.207.223.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11001 for ; Tue, 22 Aug 2000 13:06:56 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.8.6) with ESMTP id e7MH0oG19003; Tue, 22 Aug 2000 12:00:51 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id KAA21841 for disman-list; Tue, 22 Aug 2000 10:00:04 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id JAA21827 for ; Tue, 22 Aug 2000 09:59:58 -0700 (PDT) Received: from fw-us-hou1.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.8.6) with SMTP id e7MH02x18762 for ; Tue, 22 Aug 2000 12:00:06 -0500 (CDT) Received: from cisco.com (dhcp-171-69-66-157.cisco.com [171.69.66.157]) by sigma.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id JAA11438; Tue, 22 Aug 2000 09:00:10 -0700 (PDT) Message-ID: <39A2A390.B147E644@cisco.com> Date: Tue, 22 Aug 2000 09:00:16 -0700 From: Ram Kavasseri Reply-To: ramk@cisco.com Organization: Cisco Systems X-Mailer: Mozilla 4.5 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Juergen Schoenwaelder CC: rrohit@cisco.com, disman@dorothy.peer.com Subject: Re: Notification Log MIB References: <39A267EE.B948D959@cisco.com> <200008221224.OAA19443@henkell.ibr.cs.tu-bs.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-disman@dorothy.peer.com Precedence: bulk List-Id: IETF disman Working Group mailing list Content-Transfer-Encoding: 7bit Juergen Schoenwaelder wrote: > > >>>>> Rohit writes: > > Rohit> 1. For SNMP Manager to retrieve information about one > Rohit> notification, it has to issue several SNMP Get Requests > Rohit> depending upon the number of varbinds in the notification. > > Rohit> This looks like an inefficient mechanism. > > You usually use getnext/getbulks. That is, you can reduce to some > extend the number of interactions (if you know a good estimation for > max-repetitions - which is another story). > > Rohit> Instead of this we could have packed up the Varbinds in > Rohit> one object. > > Yes. The point here is that the SMI has no support for structured > types and people did not like the idea to put things into something > opaque like an OCTET STRING. > > Rohit> e.g we could have used an OctetString as follows to pack > Rohit> up the Varbind. > > Rohit> OCTET STRING (SIZE (0..65535)) DESCRIPTION "The > Rohit> stringifed value of the VarBinds that were sent as part of the > Rohit> trap generated by this fault. The VarBinds are stringified as > Rohit> follows: (i) The format of the strigified varbind would be, > Rohit> '', where, 'objectname' - is the > Rohit> name of the object (including the instance) and not the entire > Rohit> OID. For ex: ifDescr.3 and not 1.3.6.1.2.1.2.2.1.2.3 > > Rohit> 'objecttype' - is the type of the object > Rohit> stored as an ASCII string. For ex: 'Integer32', > Rohit> 'SnmpAdminString' > > Rohit> 'value' - is the value of the object (ii) > Rohit> The rules for encoding the 'value' in the string are as > Rohit> follows, - Integral types are converted into ASCII string - For > Rohit> OctetString with printable characters, again use ASCII - For > Rohit> OctetString with non-printable characters, they will be stored > Rohit> in HEX - Since we use '>' as the ending delimiter for each > Rohit> varbind in the stringified value, if the 'value' itself has a > Rohit> '>', then that would be escaped with another '>'. For ex: if > Rohit> the value was say 'abcde>>f' then it would be stored as > Rohit> 'abcde>>>>f' in the stringified value." > > The ASCII representation you are proposing does not work for several > reasons. First, the notification logger has not necessarily MIB > knowledge. Second, a single descriptor like ifDescr is not guaranteed > to be unique. Third, encoding everything (including type names) in > pure ASCII can make the OCTET STRING pretty long which can badly > interact with SNMP message size constraints. > > One could however argue that the MIB should export the whole BER > encoded notification varbind list instead (or in addition?) to the > table we have right now. This of course requires that the application > which reads the logging table is capable to decode a BER varbind list > - but this is not much harder than decoding yet another ad-hoc ASCII > representation, I think. Nicely put - I didn't even think of the BER encoded notification varbind list as a possible option. I learn something new everyday :-) Thanks, Ram > /js > > -- > Juergen Schoenwaelder Technical University Braunschweig > Dept. Operating Systems & Computer Networks > Phone: +49 531 391 3289 Bueltenweg 74/75, 38106 Braunschweig, Germany > Fax: +49 531 391 5936 From owner-disman@dorothy.peer.com Tue Aug 22 19:38:13 2000 Received: from tattler.bmc.com (fw-us-hou-2.bmc.com [198.207.223.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17694 for ; Tue, 22 Aug 2000 19:38:12 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.8.6) with ESMTP id e7MNZR501403; Tue, 22 Aug 2000 18:35:27 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id QAA00284 for disman-list; Tue, 22 Aug 2000 16:33:54 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id QAA00254 for ; Tue, 22 Aug 2000 16:33:46 -0700 (PDT) Received: from fw-us-hou1.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.8.6) with SMTP id e7MNXt401206 for ; Tue, 22 Aug 2000 18:33:55 -0500 (CDT) Received: from zrtpd004.us.nortel.com by zrtps06s.us.nortel.com; Tue, 22 Aug 2000 19:34:05 -0400 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2652.35) id ; Tue, 22 Aug 2000 19:34:03 -0400 Message-ID: <6DDA62170439D31185750000F80826AC0382F028@zmerd004.ca.nortel.com> From: "Sharon Chisholm" To: "Golovinsky, Eugene" , "'Rohit'" , disman@dorothy.peer.com Subject: RE: Notification Log MIB Date: Tue, 22 Aug 2000 19:34:01 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C00C91.735CD9B0" X-Orig: Sender: owner-disman@dorothy.peer.com Precedence: bulk List-Id: IETF disman Working Group mailing list This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C00C91.735CD9B0 Content-Type: text/plain; charset="iso-8859-1" > -----Original Message----- > From: Golovinsky, Eugene [mailto:Eugene_Golovinsky@bmc.com] > Sent: Tuesday, August 22, 2000 12:25 PM > To: 'Rohit'; disman@dorothy.peer.com > Subject: RE: Notification Log MIB > > 1. People get really upset when forced to parse long strings without having > rules of how to parse it (fields within the varbind are of arbitrary > length). I have to completely agree with that point and go further and say that I don't care how short it is - I don't want to parse it. I get very nervous with these proposals of putting stuff in Octet strings which I need to parse out. Given 10 devices, I will likely have to managed 11 incompatible interpretations of the parsable object. I'll take the hit on efficiency for a predictable and consistent SMI definition most days of the week. This is one of my major "manager" pet peeves . Sharon ------_=_NextPart_001_01C00C91.735CD9B0 Content-Type: text/html; charset="iso-8859-1" RE: Notification Log MIB

> -----Original Message-----
> From: Golovinsky, Eugene [mailto:Eugene_Golovinsky@bmc.com]
> Sent: Tuesday, August 22, 2000 12:25 PM
> To: 'Rohit'; disman@dorothy.peer.com
> Subject: RE: Notification Log MIB
> <clip>
> 1. People get really upset when forced to parse long strings without having
> rules of how to parse it (fields within the varbind are of arbitrary
> length).

I have to completely agree with that point and go further and say that I
don't care how short it is - I don't want to parse it. I get very nervous
with these proposals of putting stuff in Octet strings which I need to
parse out. Given 10 devices, I will likely have to managed 11 incompatible
interpretations of the parsable object. I'll take the hit on efficiency
for a predictable and consistent SMI definition most days of the week.
This is one of my major "manager" pet peeves .

Sharon

------_=_NextPart_001_01C00C91.735CD9B0-- From owner-disman@dorothy.peer.com Wed Aug 23 01:06:17 2000 Received: from tattler.bmc.com (fw-us-hou-2.bmc.com [198.207.223.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA23089 for ; Wed, 23 Aug 2000 01:06:17 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.8.6) with ESMTP id e7N53Aa05059; Wed, 23 Aug 2000 00:03:11 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id WAA01385 for disman-list; Tue, 22 Aug 2000 22:02:04 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id WAA01380 for ; Tue, 22 Aug 2000 22:01:59 -0700 (PDT) Received: from fw-us-hou1.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.8.6) with SMTP id e7N529e04848 for ; Wed, 23 Aug 2000 00:02:09 -0500 (CDT) Received: from cisco.com ([192.135.247.153]) by jindo.cisco.com (8.8.8/2.5.1/Cisco List Logging/8.8.8) with ESMTP id WAA09616; Tue, 22 Aug 2000 22:01:36 -0700 (PDT) Message-ID: <39A35A54.887F44BE@cisco.com> Date: Wed, 23 Aug 2000 10:30:04 +0530 From: Rohit X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: ramk@cisco.com CC: Juergen Schoenwaelder , disman@dorothy.peer.com Subject: Re: Notification Log MIB References: <39A267EE.B948D959@cisco.com> <200008221224.OAA19443@henkell.ibr.cs.tu-bs.de> <39A27A79.C72708C0@cisco.com> <39A2AA87.9A8ED838@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-disman@dorothy.peer.com Precedence: bulk List-Id: IETF disman Working Group mailing list Content-Transfer-Encoding: 7bit Hi, Ram Kavasseri wrote: > > Rohit wrote: > > > > Hi Juergen, > > > > My comments are inline :- > > > > Juergen Schoenwaelder wrote: > > > > > > >>>>> Rohit writes: > > > > > > Rohit> 1. For SNMP Manager to retrieve information about one > > > Rohit> notification, it has to issue several SNMP Get Requests > > > Rohit> depending upon the number of varbinds in the notification. > > > > > > Rohit> This looks like an inefficient mechanism. > > > > > > You usually use getnext/getbulks. That is, you can reduce to some > > > extend the number of interactions (if you know a good estimation for > > > max-repetitions - which is another story). > > > > If we use getnext , we are increasing the traffic on the network. > > If we are using getbulk , its not a straight forward to estimate the > > number of max-repititions. > > > > With the alternate solution, one get will get you one complete > > notification. > > Parsing values from an encoded OctetString is discouraged. > > You're trying to solve two problems here: > 1. encapsulating all the objects you need into one PDU > 2. apply some sort of compression or OID suppression to make the > transfer > more efficient. > > The former can be done today using bulk transfer...For the latter, the > NMRG > (Network Management Research Group) is investigating various > bulk-transfer > methods with OID suppression (and/or compression)... > > Inventing ways to do either of the above for a few objects only is wrong > and non-standard, IMHO... I think you have a point here. But still i haven't got clarification of my second comment :- Why don't we have a nlmConfigLogAgeout for each entry in the nlmConfigLogTable ? This could even be used for associating priority to the notification being logged. Thanks Rohit > > Ram > > > > > > > Rohit> Instead of this we could have packed up the Varbinds in > > > Rohit> one object. > > > > > > Yes. The point here is that the SMI has no support for structured > > > types and people did not like the idea to put things into something > > > opaque like an OCTET STRING. > > > > > > Rohit> e.g we could have used an OctetString as follows to pack > > > Rohit> up the Varbind. > > > > > > Rohit> OCTET STRING (SIZE (0..65535)) DESCRIPTION "The > > > Rohit> stringifed value of the VarBinds that were sent as part of the > > > Rohit> trap generated by this fault. The VarBinds are stringified as > > > Rohit> follows: (i) The format of the strigified varbind would be, > > > Rohit> '', where, 'objectname' - is the > > > Rohit> name of the object (including the instance) and not the entire > > > Rohit> OID. For ex: ifDescr.3 and not 1.3.6.1.2.1.2.2.1.2.3 > > > > > > Rohit> 'objecttype' - is the type of the object > > > Rohit> stored as an ASCII string. For ex: 'Integer32', > > > Rohit> 'SnmpAdminString' > > > > > > Rohit> 'value' - is the value of the object (ii) > > > Rohit> The rules for encoding the 'value' in the string are as > > > Rohit> follows, - Integral types are converted into ASCII string - For > > > Rohit> OctetString with printable characters, again use ASCII - For > > > Rohit> OctetString with non-printable characters, they will be stored > > > Rohit> in HEX - Since we use '>' as the ending delimiter for each > > > Rohit> varbind in the stringified value, if the 'value' itself has a > > > Rohit> '>', then that would be escaped with another '>'. For ex: if > > > Rohit> the value was say 'abcde>>f' then it would be stored as > > > Rohit> 'abcde>>>>f' in the stringified value." > > > > > > The ASCII representation you are proposing does not work for several > > > reasons. First, the notification logger has not necessarily MIB > > > knowledge. Second, a single descriptor like ifDescr is not guaranteed > > > to be unique. Third, encoding everything (including type names) in > > > pure ASCII can make the OCTET STRING pretty long which can badly > > > interact with SNMP message size constraints. > > > > > > One could however argue that the MIB should export the whole BER > > > encoded notification varbind list instead (or in addition?) to the > > > table we have right now. This of course requires that the application > > > which reads the logging table is capable to decode a BER varbind list > > > > I agree to the fact that suggested representation is not a standard > > but this can be documented in the MIB. > > Size of the OctetString will depend on the 'number of Varbinds' and > > their > > types which i believe should not not cross SNMP message size. > > > > Thanks > > Rohit > > > > > - but this is not much harder than decoding yet another ad-hoc ASCII > > > representation, I think. > > > > > > /js > > > > > > -- > > > Juergen Schoenwaelder Technical University Braunschweig > > > Dept. Operating Systems & Computer Networks > > > Phone: +49 531 391 3289 Bueltenweg 74/75, 38106 Braunschweig, Germany > > > Fax: +49 531 391 5936 From owner-disman@dorothy.peer.com Fri Aug 25 15:54:33 2000 Received: from tattler.bmc.com (fw-us-hou-1.bmc.com [198.207.223.250]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28155 for ; Fri, 25 Aug 2000 15:54:33 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.8.6) with ESMTP id e7PJp1727219; Fri, 25 Aug 2000 14:51:02 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id MAA28284 for disman-list; Fri, 25 Aug 2000 12:46:11 -0700 (PDT) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id MAA28277; Fri, 25 Aug 2000 12:46:07 -0700 (PDT) Date: Fri, 25 Aug 2000 12:46:07 -0700 (PDT) From: Randy Presuhn Message-Id: <200008251946.MAA28277@dorothy.bmc.com> To: ehab@cs.depaul.edu Subject: Re: FW: paper CR Cc: disman@dorothy.peer.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit Sender: owner-disman@dorothy.peer.com Precedence: bulk List-Id: IETF disman Working Group mailing list Content-Transfer-Encoding: 8bit Hi - > Message-ID: > From: "Ehab S. Al-Shaer" > To: "'rpresuhn@dorothy.peer.com'" , > "'rpresuhn@bmc.com'" > Subject: FW: paper CR > Date: Thu, 24 Aug 2000 23:12:10 -0500 ... > I found DISMAN WG is the most appropriate place for presenting and > sharing my work. If you agree, please advise how I would I go forward > with this proposal (getting the community feedback, framework presentation, > and writing an Internet draft)? Attached is the full journal version of > the paper. Thank you for effort. ... Thanks for your interest in sharing your work! Recommendations: (these apply to ANYONE proposing that the disman working group take on a project) 1) subscribe to the disman working group mailing list. instructions are at http://www.ietf.org/html.charters/disman-charter.html (I didn't see your email address among the subscribers) 2) before posting, note well the intellectual property requirements stated in RFC 2026! http://www.ietf.org/rfc/rfc2026.txt 3) make your work available to the working group, preferably as flat ASCII, rather than PostScript text, though PostScript might be ok for gauging initial interest. (Folks are generally more likely to read something if it is available in ASCII.) A URL would suffice. The working group does have an FTP site where, with your permission, your material could be made available. If you can post your material as a personal internet draft, so much the better. The instructions for doing so are at http://www.ietf.org/ietf/1id-guidelines.txt 4) be prepared to address the security considerations inherent in your proposal. The working group is at a point where it is appropriate to consider whether we are interested in taking on new work items, so I suggest moving quickly. ------------------------------------------------------- Randy Presuhn randy_presuhn@bmc.com Voice: +1 408 546-1006 BMC Software, Inc. 1-3141 Fax: +1 408 965-0359 2141 North First Street http://www.bmc.com/ San José, California 95131 USA ------------------------------------------------------- My opinions and BMC's are independent variables. ------------------------------------------------------- From owner-disman@dorothy.peer.com Tue Aug 29 10:01:13 2000 Received: from tattler.bmc.com (fw-us-hou-2.bmc.com [198.207.223.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18229 for ; Tue, 29 Aug 2000 10:01:12 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.8.6) with ESMTP id e7TDuQA08562; Tue, 29 Aug 2000 08:56:27 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id GAA29234 for disman-list; Tue, 29 Aug 2000 06:53:48 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id GAA29229 for ; Tue, 29 Aug 2000 06:53:44 -0700 (PDT) Received: from fw-us-hou2.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.8.6) with SMTP id e7TDrlk07916 for ; Tue, 29 Aug 2000 08:53:47 -0500 (CDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17915; Tue, 29 Aug 2000 09:51:00 -0400 (EDT) Message-Id: <200008291351.JAA17915@ietf.org> To: IETF-Announce: ; Cc: RFC Editor , IANA Cc: Internet Architecture Board Cc: disman@dorothy.peer.com From: The IESG Subject: Protocol Action: Event MIB to Proposed Standard Date: Tue, 29 Aug 2000 09:51:00 -0400 Sender: owner-disman@dorothy.peer.com Precedence: bulk List-Id: IETF disman Working Group mailing list The IESG has approved the Internet-Draft 'Event MIB' as a Proposed Standard. This document is the product of the Distributed Management Working Group. The IESG contact persons are Bert Wijnen and Randy Bush. Technical Summary This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects that can be used to manage and monitor MIB objects and take action through events. The Event MIB provides the ability to monitor MIB objects on the local system or on a remote system and take simple action when a trigger condition is met. Working Group Summary This document incorporates feedback from implementors of an earlier internet-draft. The Working Group has (rough) consensus that this document is ready to be published as Proposed Standard, so that we can start to collect implementation and interoperability experience. Protocol Quality This document was reviewed for the IESG by Jon Saperia and Bert Wijnen. ----------------------- Note To RFC-Editor: - In the abstract on page 2, please remove "experimental". OLD: This memo defines an experimental portion of the Management Information NEW: This memo defines a portion of the Management Information From owner-disman@dorothy.peer.com Tue Aug 29 10:05:28 2000 Received: from tattler.bmc.com (fw-us-hou-2.bmc.com [198.207.223.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18384 for ; Tue, 29 Aug 2000 10:05:28 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.8.6) with ESMTP id e7TE2tr10137; Tue, 29 Aug 2000 09:02:55 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id HAA29254 for disman-list; Tue, 29 Aug 2000 07:02:31 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id HAA29249 for ; Tue, 29 Aug 2000 07:02:28 -0700 (PDT) Received: from fw-us-hou2.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.8.6) with SMTP id e7TE2XM10068 for ; Tue, 29 Aug 2000 09:02:33 -0500 (CDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18138; Tue, 29 Aug 2000 09:59:52 -0400 (EDT) Message-Id: <200008291359.JAA18138@ietf.org> To: IETF-Announce: ; Cc: RFC Editor , IANA Cc: Internet Architecture Board Cc: disman@dorothy.peer.com From: The IESG Subject: Protocol Action: Distributed Management Expression MIB to Proposed Standard Date: Tue, 29 Aug 2000 09:59:52 -0400 Sender: owner-disman@dorothy.peer.com Precedence: bulk List-Id: IETF disman Working Group mailing list The IESG has approved the Internet-Draft 'Distributed Management Expression MIB' as a Proposed Standard. This document is the product of the Distributed Management Working Group. The IESG contact persons are Bert Wijnen and Randy Bush. Technical Summary This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing expressions of MIB objects. The results of these expressions become MIB objects usable like any other MIB object, such as for the test condition for declaring an event. Working Group Summary There was at least one implementation based on an earlier internet-draft version of this work. The Working Group has (rough) consensus that this document is ready for publication as Proposed Standard, so that we can start to collect more implementation experience. Protocol Quality This document has been reviewed for the IESG by David Harrington and Bert Wijnen. From owner-disman@dorothy.peer.com Wed Aug 30 16:29:54 2000 Received: from tattler.bmc.com (fw-us-hou-2.bmc.com [198.207.223.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08507 for ; Wed, 30 Aug 2000 16:29:53 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.8.6) with ESMTP id e7UKMHM27148; Wed, 30 Aug 2000 15:22:18 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id NAA08508 for disman-list; Wed, 30 Aug 2000 13:20:57 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id NAA08502; Wed, 30 Aug 2000 13:20:53 -0700 (PDT) Received: from fw-us-hou1.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.8.6) with SMTP id e7UKKtO26802; Wed, 30 Aug 2000 15:20:55 -0500 (CDT) Received: from cisco.com (sjck-dial-gw5-149.cisco.com [10.19.238.150]) by sigma.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id XAA10131; Tue, 29 Aug 2000 23:19:08 -0700 (PDT) Message-ID: <39ACA7E1.576AEBEB@cisco.com> Date: Tue, 29 Aug 2000 23:21:21 -0700 From: Ramanathan Kavasseri Reply-To: ramk@cisco.com Organization: Cisco Systems X-Mailer: Mozilla 4.5 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: rpresuhn@dorothy.peer.com CC: disman@dorothy.peer.com Subject: Re: Protocol Action: Event MIB to Proposed Standard References: <200008291351.JAA17915@ietf.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-disman@dorothy.peer.com Precedence: bulk List-Id: IETF disman Working Group mailing list Content-Transfer-Encoding: 7bit I've made the change (removing the word "experimental") requested by the IESG. Should I resubmit this to internet-drafts@ief.org as draft-ietf-disman-event-mib-10.txt, or should it be renumbered as draft-ietf-disman-event-mib-11.txt? Any tips on how I should proceed will be greatly appreciated... Thanks, Ram The IESG wrote: > > The IESG has approved the Internet-Draft 'Event MIB' > as a Proposed Standard. This > document is the product of the Distributed Management Working Group. > The IESG contact persons are Bert Wijnen and Randy Bush. > > Technical Summary > > This memo defines a portion of the Management Information Base (MIB) > for use with network management protocols in the Internet community. > In particular, it describes managed objects that can be used to > manage and monitor MIB objects and take action through events. > > The Event MIB provides the ability to monitor MIB objects on the local > system or on a remote system and take simple action when a trigger > condition is met. > > Working Group Summary > > This document incorporates feedback from implementors of > an earlier internet-draft. The Working Group has (rough) > consensus that this document is ready to be published > as Proposed Standard, so that we can start to collect > implementation and interoperability experience. > > Protocol Quality > > This document was reviewed for the IESG by Jon Saperia and > Bert Wijnen. > > ----------------------- > > Note To RFC-Editor: > > - In the abstract on page 2, please remove "experimental". > OLD: > This memo defines an experimental portion of the Management Information > NEW: > This memo defines a portion of the Management Information From owner-disman@dorothy.peer.com Wed Aug 30 16:45:45 2000 Received: from tattler.bmc.com (fw-us-hou-2.bmc.com [198.207.223.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08873 for ; Wed, 30 Aug 2000 16:45:45 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.8.6) with ESMTP id e7UKcfN03181; Wed, 30 Aug 2000 15:38:41 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id NAA08586 for disman-list; Wed, 30 Aug 2000 13:38:11 -0700 (PDT) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id NAA08580; Wed, 30 Aug 2000 13:38:08 -0700 (PDT) Date: Wed, 30 Aug 2000 13:38:08 -0700 (PDT) From: Randy Presuhn Message-Id: <200008302038.NAA08580@dorothy.bmc.com> To: ramk@cisco.com Subject: Re: Protocol Action: Event MIB to Proposed Standard Cc: disman@dorothy.peer.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-disman@dorothy.peer.com Precedence: bulk List-Id: IETF disman Working Group mailing list Content-Transfer-Encoding: 7bit Hi - > Message-ID: <39ACA7E1.576AEBEB@cisco.com> > Date: Tue, 29 Aug 2000 23:21:21 -0700 > From: Ramanathan Kavasseri > Reply-To: ramk@cisco.com > To: rpresuhn@dorothy.bmc.com > CC: disman@dorothy.bmc.com > Subject: Re: Protocol Action: Event MIB to Proposed Standard > References: <200008291351.JAA17915@ietf.org> > > I've made the change (removing the word "experimental") requested by > the IESG. Should I resubmit this to internet-drafts@ief.org as > draft-ietf-disman-event-mib-10.txt, or should it be renumbered > as draft-ietf-disman-event-mib-11.txt? ... I suggest that you just hang on to your nroff. When this gets to the top of the RFC editor's queue, you can work this out with the RFC editor. ------------------------------------------------------- Randy Presuhn randy_presuhn@bmc.com Voice: +1 408 546-1006 BMC Software, Inc. 1-3141 Fax: +1 408 965-0359 2141 North First Street http://www.bmc.com/ San José, California 95131 USA ------------------------------------------------------- My opinions and BMC's are independent variables. ------------------------------------------------------- From owner-disman@dorothy.peer.com Wed Aug 30 18:20:14 2000 Received: from tattler.bmc.com (fw-us-hou-2.bmc.com [198.207.223.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10229 for ; Wed, 30 Aug 2000 18:20:14 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.8.6) with ESMTP id e7UMHYx23253; Wed, 30 Aug 2000 17:17:35 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id PAA09453 for disman-list; Wed, 30 Aug 2000 15:16:46 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id PAA09447; Wed, 30 Aug 2000 15:16:42 -0700 (PDT) Received: from fw-us-hou1.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.8.6) with SMTP id e7UMGiM23143; Wed, 30 Aug 2000 17:16:44 -0500 (CDT) Received: from cisco.com (dhcp-171-69-66-157.cisco.com [171.69.66.157]) by sigma.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id OAA11931; Wed, 30 Aug 2000 14:29:27 -0700 (PDT) Message-ID: <39AD7CBE.E1D1FFAD@cisco.com> Date: Wed, 30 Aug 2000 14:29:34 -0700 From: Ram Kavasseri Reply-To: ramk@cisco.com Organization: Cisco Systems X-Mailer: Mozilla 4.5 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Randy Presuhn CC: disman@dorothy.peer.com Subject: Re: Protocol Action: Event MIB to Proposed Standard References: <200008302038.NAA08580@dorothy.bmc.com> Content-Type: text/plain; charset=iso-8859-1 X-MIME-Autoconverted: from 8bit to quoted-printable by sigma.cisco.com id OAA11931 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by dorothy.bmc.com id PAA09448 Sender: owner-disman@dorothy.peer.com Precedence: bulk List-Id: IETF disman Working Group mailing list Content-Transfer-Encoding: 8bit Randy Presuhn wrote: > > Hi - > > > Message-ID: <39ACA7E1.576AEBEB@cisco.com> > > Date: Tue, 29 Aug 2000 23:21:21 -0700 > > From: Ramanathan Kavasseri > > Reply-To: ramk@cisco.com > > To: rpresuhn@dorothy.bmc.com > > CC: disman@dorothy.bmc.com > > Subject: Re: Protocol Action: Event MIB to Proposed Standard > > References: <200008291351.JAA17915@ietf.org> > > > > I've made the change (removing the word "experimental") requested by > > the IESG. Should I resubmit this to internet-drafts@ief.org as > > draft-ietf-disman-event-mib-10.txt, or should it be renumbered > > as draft-ietf-disman-event-mib-11.txt? > ... > > I suggest that you just hang on to your nroff. When this > gets to the top of the RFC editor's queue, you can work this > out with the RFC editor. Ok. Will do that. Thanks, Ram > ------------------------------------------------------- > Randy Presuhn randy_presuhn@bmc.com > Voice: +1 408 546-1006 BMC Software, Inc. 1-3141 > Fax: +1 408 965-0359 2141 North First Street > http://www.bmc.com/ San José, California 95131 USA > ------------------------------------------------------- > My opinions and BMC's are independent variables. > ------------------------------------------------------- From owner-disman@dorothy.peer.com Wed Aug 30 19:48:50 2000 Received: from tattler.bmc.com (fw-us-hou-1.bmc.com [198.207.223.250]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11107 for ; Wed, 30 Aug 2000 19:48:50 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.8.6) with ESMTP id e7UNkLl06427; Wed, 30 Aug 2000 18:46:22 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id QAA10357 for disman-list; Wed, 30 Aug 2000 16:45:50 -0700 (PDT) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id QAA10351 for disman@dorothy.bmc.com; Wed, 30 Aug 2000 16:45:47 -0700 (PDT) Date: Wed, 30 Aug 2000 16:45:47 -0700 (PDT) From: Randy Presuhn Message-Id: <200008302345.QAA10351@dorothy.bmc.com> To: disman@dorothy.peer.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.peer.com Precedence: bulk List-Id: IETF disman Working Group mailing list Content-Transfer-Encoding: 7bit Hi - > Message-ID: <39A35A54.887F44BE@cisco.com> > Date: Wed, 23 Aug 2000 10:30:04 +0530 > From: Rohit > To: ramk@cisco.com > CC: Juergen Schoenwaelder , disman@dorothy.bmc.com > Subject: Re: Notification Log MIB > References: <39A267EE.B948D959@cisco.com> <200008221224.OAA19443@henkell.ibr.cs.tu-bs.de> <39A27A79.C72708C0@cisco.com> <39A2AA87.9A8ED838@cisco.com> ... > Why don't we have a nlmConfigLogAgeout for each entry in the > nlmConfigLogTable ? This could even be used for associating > priority to the notification being logged. ... Because no one asked for it, and because a major figure from Cisco thought the global one was sufficient. :-) * 0.5 I personally think adding an nlmConfigLogAgeOut is technically worth considering, but as WG chair I must say that it's really too late to make such a change in this iteration. Not only are we past the close of WG last call, the IETF last call ended last month. When the implementation reports start pouring in and it's time to consider advancement to Draft Standard, we'll have to see whether this has been a problem that merits fixing, and whether this solution is the right one. ------------------------------------------------------- Randy Presuhn randy_presuhn@bmc.com Voice: +1 408 546-1006 BMC Software, Inc. 1-3141 Fax: +1 408 965-0359 2141 North First Street http://www.bmc.com/ San José, California 95131 USA ------------------------------------------------------- My opinions and BMC's are independent variables. -------------------------------------------------------